JP4308222B2 - 情報通知装置および情報通知方法 - Google Patents

Description

本発明は、ユーザに対して情報の通知を行う情報通知装置に関し、特に状況に応じて、適切なタイミングで受信メールを通知する技術に関するものである。

近年、携帯電話やＰＣ（パーソナルコンピュータ）、情報家電を通じて、ユーザにニュースや広告、生活情報といった文字情報や動画情報をＰＵＳＨ型で提供する装置が多くなってきている。将来的には、ユーザが携帯するモバイル装置が、ユーザに対して自発的にインタラクションを開始し、情報やサービスを提供するようになるだろう。今後、このように装置がユーザに対して自発的に情報を提供するということは、ますます一般的になってくる。

装置がユーザに対して装置の側から情報を提供する際、外部のネットワークや情報発信基地局から受け取った情報を、即座にユーザに通知していては、ユーザに気づいてもらえないことがある。例えば、もしユーザが忙しいときに、装置がショッピング情報の通知を行ったとしても、ユーザは通知に気づかないことが多い。たとえ気づいたとしても、ユーザは嫌な思いをする。例えば、ショッピング情報はユーザが忙しいときではなく、ユーザが家から外に出かけるときなどに通知を行うと、ユーザに好まれることが多い。よって、外部から受け取った情報を即座に通知するのではなく、受け取った情報を一旦装置に記憶し、ユーザにとって通知が好ましいタイミングになったときに情報を通知する必要がある。つまり、ユーザにいつ、どのような情報を告げ知らせるか、つまり情報通知のタイミングが重要となる。

そこで、従来、ユーザの情報閲覧行動から学習を行い、ユーザの場所や時間帯に応じて異なる情報を提供することが提案されている（例えば、非特許文献１参照。）。

また、ユーザの情報参照状況を用いることで、時間帯に応じて提供する情報を変更することも提案されている（例えば、特許文献１参照。）。

さらに、好ましいタイミングに情報を通知するだけではなく、通知する情報の量、例えば、携帯電話などの携帯端末においてユーザに通知するメールの数を調整することも重要である。いくら通知が好ましいタイミングとはいえ、ユーザに非常に多くのメールを一度に送られてもユーザは読みきれない場合がある。しかも読みきれるメールの数は状況によって異なる。

そこで、従来、キーボードのストローク頻度、カーソル移動頻度、脳波から提示する情報の抽象度を変更するということがなされている（例えば、特許文献２参照。）。具体的には状況から推測したユーザの集中度が高いときには、情報の見出しのみを提示するということがなされている。
二瓶克己，茶園篤，伊東紀子：モバイル情報配信プラットフォームＴＰＯＣＡＳＴ−松江観光ＧＩＳ実証実験結果報告−，情報処理学会第６３回全国大会，２Ｒ−３・４，２００１． 特開２０００−０９９５２５号公報 特許２６９７５９０号公報

しかしながら、上記非特許文献１の技術では、情報通知のタイミングに関しては、情報提供者が予め作成したルールやユーザからの情報要求に従っている。そのために、情報提供者やユーザの負担が大きいという問題がある。

たとえば、１２時に飲食店の情報を通知するようにしたとしても、１２時に昼食をとるユーザもいれば、１５時に昼食をとるユーザもいる。また、２３時に寝るユーザもいれば、午前３時に寝るユーザもいる。つまり、ユーザそれぞれにおいて適切な通知タイミングは異なる。情報提供者がユーザそれぞれに対して適切なルールを作成することが考えられるが、ユーザの数は莫大であり、情報提供者が個々のルールを作成することは不可能である。かといってユーザ自身が、いつどのような情報を通知されればよいかといったルールを作成することは、ユーザにとって非常に負担が大きい。

また、上記特許文献１の技術では、状況に応じて情報の内容が変更されるものの、適切なタイミングで情報が提供されるものではないという問題がある。つまり、この従来技術は、新幹線のＬＥＤ広告のように四六時中絶えず情報を表示するものであり、通知という概念が存在しない。つまり、この従来技術は、状況に応じて情報内容を変更しているだけで、装置が通知タイミングを学習し、制御しているわけではない。

ここで、適切なタイミングで情報を提供する方法として、ユーザの履歴データを用いて、いつどのような情報を通知すればよいかを装置が自動的に推定することが考えられる。例えば、ブラウザでユーザが７時にスポーツ情報を閲覧したという履歴があったとき、ユーザが何も操作をしなくても、７時にスポーツ情報を通知すればよい。

しかしながら、ブラウザ閲覧するといったユーザの能動的な情報要求動作の履歴だけでは、テレビの字幕による情報通知など、ユーザが受動的に情報を受け取るようなＰＵＳＨ型情報提供装置の大半において適用することはできないという問題がある。また、情報要求動作が行われた時刻を通知タイミング学習に用いるだけでは、全ての時刻や情報内容を網羅できず、不十分である。例えば、ユーザが７時にスポーツ情報を要求したとすると、装置は７時に情報を通知することしかできず、ユーザからの情報要求動作がない限り、ユーザが情報を欲しがっていたとしても、８時にスポーツ情報を通知することはできない。つまり、通知する時刻や情報内容に偏りを生じてしまう。ユーザが情報を通知されたいと考えている時刻と情報内容を全て装置に学習させるためには、ユーザは全ての時刻において、その時刻で欲する全ての情報内容について、情報要求動作を行わなければならないため、手間も時間もかかる。

また、時刻だけでは、通知すべきか否かを判別できない場合がある。例えば、同じ７時でも家にいるときは情報を通知して欲しいかもしれないが、７時に会社にいるときは仕事中で情報を通知して欲しくないかもしれない。このため、時刻に加えて場所情報も通知タイミング制御に用いる必要がある。また、７時に会社にいるときは仕事中で情報を通知して欲しくないかもしれないが、１２時に会社にいるときは昼休みで情報を通知して欲しいかもしれない。つまり７時である、会社にいるという情報だけでは通知の可否が判断できず、７時に会社にいるという情報、つまり時刻と場所の組み合わせ情報が必要になる。つまり、情報通知のタイミングを装置に学習させるためには、ユーザが通知をして欲しい時刻と場所のそれぞれの組み合わせにおいて、その状況において通知して欲しい全ての情報内容について、情報を要求する必要があり、とても人の手でできるものではない。

さらに、特許文献２では、ユーザのタスクの集中度が高いときに一つの情報について抽象度を上げるということはできているが、情報の数、具体的には、携帯端末におけるメールの数（受信しているが未閲覧の状態で蓄積されているメールの数）には対応していないという問題がある。

実際にユーザがタスクを行っている画面上に一通のメールを提示する場合、タイトルだけ提示するか、本文も含めて提示するかはタスクの集中度によって変化できるかもしれない。しかし、携帯端末に対して一通だけメールを通知されることを好むか、十通のメールを通知されることを好むかはタスクの集中度にはよらない可能性が高い。なぜなら、一通のメールが来ることも、十通のメールが来ることも、携帯端末の振動や音、光などの通知により、ユーザのタスクを妨げられることには変わらないからである。よって、通知回数を減らすために、どこまでメールを同時に通知するか、どのタイミングでメールを同時に通知するかといったことが重要になる。そもそも、携帯端末においては、ユーザがキーボードやカーソルを動かしてなくてもタスクに集中している可能性があるため、集中度を計測することもできない。

そこで、本発明は上記の事情に鑑みてなされたものであり、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置および情報通知方法を提供することを目的とする。

上記目的を達成するため、本発明に係る情報通知装置は、受信した電子メールをユーザに通知する情報通知装置であって、時刻を検知する時刻検知手段と、前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、前記ユーザが送信したメールである送信メール情報を取得する送信メール取得手段と、前記送信メール情報から、前記送信メールに対する返信メールの受信時刻を算出するための規則である呼応受信規則を蓄積する呼応受信規則蓄積手段と、前記送信メール情報と前記呼応受信規則から、現在の時刻以降に外部ネットワーク媒体から受信するであろう返信メールの受信時刻を決定する呼応メール取得手段と、前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記呼応メール取得手段で決定した前記返信メールの受信時刻とを用いて決定する通知タイミング制御手段と、前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段とを備えることを特徴とする。

また、本発明は、このような情報通知装置として実現することができるだけでなく、このような情報通知装置が備える特徴的な手段をステップとする情報通知方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。

本発明に係る情報通知装置および情報通知方法によれば、ユーザが特にルールを定めなくても、ユーザにとって通知が好ましいタイミングになったときに、それまでに蓄積された全てのメールが同時に通知される。

よって、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とが適切に制御され、ユーザは、都合のよいタイミングで、それまで蓄積された受信メールをまとめて閲覧することができる。

また、ユーザの情報要求を用いることができないメディアにおいても、通知に対するユーザの反応履歴に基づくことで、ユーザにとって適切なタイミングに適切な量の情報が通知される。

また、反応履歴を用いることで、いつどのような情報を通知すればよいかという通知タイミングを修正することができる。

また、修正規則と反応履歴を用いることで、学習データが少ないときにおいても、ユーザの嫌がらないタイミングを推測し、装置の側から自発的にユーザに情報を通知することができる。

本発明に係る情報通知装置は、受信した電子メールをユーザに通知する情報通知装置であって、時刻を検知する時刻検知手段と、前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、現在の時刻以降に外部ネットワーク媒体から受信する未来のメールの受信時刻を取得する未来メール取得部を有し、前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記未来のメールの受信時刻とを用いて決定する通知タイミング制御手段と、前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段とを備えることを特徴とする。

これにより、情報通知に対するユーザの反応履歴に基づいて情報通知のタイミングが決定されるとともに、蓄積された複数のメールを同時に通知するのが好ましいか否かも判断されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とが適切に制御される。

ここで、前記通知タイミング制御手段は、前記時刻検知手段で検知された現在の時刻以降の前記通知評価値を用いて、前記通知情報蓄積手段に蓄積されている全てのメールを前記所定の時刻において同時に通知するか否かを決定するのが好ましい。将来の時刻において通知する場合の適切度合が考慮されるからである。

具体的には、前記所定の時刻とは現在時刻であり、前記通知タイミング制御手段は、前記未来のメールの受信時刻が遅いほど現在時刻において通知するように決定したり、前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数が多いほど現在時刻において通知するように決定するのが好ましい。

また、前記情報通知装置は、さらに、前記通知評価値から、前記時刻検知手段で検知された時刻に応じて、同時に通知できるメールの最大数を計算する最大通知数計算手段を備え、前記通知タイミング制御手段は、前記情報蓄積部に蓄積されたメールの数が、前記最大通知数計算手段で計算された前記時刻における前記最大数を上回った場合に、前記通知情報蓄積手段に蓄積されているメールのうち、前記最大数のメールを前記所定の時刻において同時に通知するか否かを決定する構成としてもよい。このとき、前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数と、未来に受信するメールの数と、現在以降における前記最大通知数計算手段が算出した最大数とから、前記通知情報蓄積手段に蓄積されたメールと未来に受信するメールの全てが同時に通知できる通知時刻を算出する通知時刻算出手段を有し、前記通知時刻が遅いほど、現在時刻において通知するように決定するのが好ましい。

これにより、蓄積されたメールが通知可能な最大数を超えた場合にも、通知可能な最大数を超えることなく、適切なタイミングで、まとめて受信メールを閲覧することができる。

また、前記情報通知装置は、さらに、前記ユーザが送信したメールである送信メール情報を取得する送信メール取得手段と、前記送信メール情報から前記未来のメールの受信時刻を算出するための規則である呼応受信規則を蓄積する呼応受信規則蓄積手段とを備え、前記未来メール取得部は、前記呼応受信規則を用いて前記送信メール情報から前記未来のメールの受信時刻を算出してもよい。たとえば、前記送信メール情報には、宛先アドレスと送信時刻が含まれ、前記呼応受信規則には、差出人アドレスと待ち時間が含まれ、前記未来メール取得部は、前記送信メール情報に含まれる宛先アドレスに一致する前記差出人アドレスを持つ呼応受信規則に含まれる待ち時間と前記送信メール情報に含まれる送信時刻とから、前記未来メールの受信時刻を算出する。

また、前記情報通知装置は、さらに、前記ユーザの場所を検知する場所検知手段を備え、前記反応履歴蓄積手段は、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻、前記場所検知手段で検知された場所、および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積し、前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻と前記場所とに応じて計算し、前記通知タイミング制御手段は、前記時刻検知手段で検知された時刻と前記場所検知手段で検知された場所とに応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを決定してもよい。具体的には、前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記通知を行ったときのユーザの反応の確率を示す反応確率を前記通知評価値として計算し、前記通知タイミング制御手段は、前記時刻と前記場所とに対応する通知評価値として前記通知評価値計算手段で計算された反応確率が一定の閾値以上である場合に前記通知をすると決定するとともに、現時点で即座に全てのメールを通知することに対する、前記未来のメールの受信時刻で全てのメールを通知することの利点を計算し、その利点の多いタイミングで前記通知をすると決定する。

これにより、時刻だけでなく、ユーザの場所をも考慮して、通知タイミングの適切度合が判断されるので、よりユーザにとって都合のよい状況で、受信メールがあったことが通知される。

また、前記情報通知装置は、さらに、メールを受信することができるか否かを示すメール受信状況を場所に対応づけたメール受信状況対応表を保持する手段と、前記ユーザの将来の行動を示す時刻および場所を予測する行動予測手段とを備え、前記未来メール取得部は、前記行動予測手段による予測に基づいて、未来のメールの受信時刻におけるユーザの位置が前記メール受信状況対応表でメールを受信することができない場所であると予測された場合に、前記行動予測手段による予測に従って、ユーザがメールを受信できる場所に移動する時刻を、前記未来のメールの受信時刻として修正するのが好ましい。これにより、電波状況の悪い場所にいる等のために、予定された受信時刻にメールができないケースも考慮したうえで、通知タイミングが決定される。

以下、本発明の各実施の形態について、それぞれ図面を参照しながら詳細に説明する。

なお、本願請求項１に係る発明に最も近い実施の形態は、実施の形態１１である。実施の形態１１は、多くの構成要素からなるので、本明細書では、理解を容易にするために、実施の形態１１の一部の構成要素からなる他の実施の形態１〜１０を先に説明する。

（実施の形態１）
まず、本発明の実施の形態１に係る情報通知装置を説明する。

図１は、本発明の実施の形態１に係る情報通知装置の構成を示すブロック図である。

情報通知装置は、例えば携帯電話や情報携帯端末等の機器に備えられてユーザに対して情報の通知を行うための装置であり、図１に示されるように、時刻検知部１００、場所検知部１０１、反応検知部１０２、反応履歴蓄積部１０３、通知評価値計算部１１０、反応確率計算部１０４、修正規則蓄積部１０５、通知評価値修正部１１１、反応確率修正部１０６、通知情報蓄積部１０７、通知タイミング制御部１０８、および情報通知部１０９を備えている。

時刻検知部１００は、情報通知装置内の時計等により、現在の時刻情報を常に検知する。検知された時刻情報は、反応検知部１０２、反応履歴蓄積部１０３、通知タイミング制御部１０８に送られる。

場所検知部１０１は、例えばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）装置またはＩＣタグ等により、ユーザが存在する場所を検知する。ここで、経度、緯度の情報を検知しても良いし、「大阪」「会社」「車内」など、場所を判別するラベルを検知しても良い。また、「大阪」かつ「梅田」かつ「車内」など場所を表すラベルを複数検知しても良い。

反応検知部１０２は、情報の通知に対するユーザの反応をユーザの情報通知装置に対する操作により検知する。例えば、時刻検知部１００により時刻情報を取得することで、情報通知部１０９が通知した時刻から、ユーザが通知モダリティを止める時刻までの反応時間を反応として検知する。ここで、通知モダリティとは、通知音、バイブレーションといったユーザに通知を行う際の手段となるものである。ユーザが通知モダリティを止めなかったときは、反応なしと検知する。なお、ユーザが初めて情報通知装置を手に取る時刻までの反応時間、ユーザが情報内容を確認する時刻までの反応時間を反応として検知しても良い。

反応履歴蓄積部１０３は、情報通知部１０９が情報の通知を行ったときに時刻検知部１００で検知された時刻と、情報の通知を行ったときに場所検知部１０１で検知されたユーザの場所と、反応検知部１０２で検知されたユーザの反応を蓄積する。例えば、図２に示されるように、情報を識別する履歴ＩＤ、この情報に関する通知時刻と通知場所、反応時間の組を反応履歴として蓄積する。

通知評価値計算部１１０は、反応履歴蓄積部１０３に蓄積されている反応履歴から、あるタイミングで通知することが適切かどうかを示す通知評価値、つまり通知タイミングに関する通知評価値を計算する。そして、通知時刻と通知場所とから構成された条件ごとの通知評価値を記録した通知評価値テーブルを作成する。通知評価値計算部１１０の一つとして、反応確率計算部１０４がある。

反応確率計算部１０４は、反応履歴蓄積部１０３に蓄積されている反応履歴から、情報の通知を行ったときのユーザの反応の確率を示す反応確率を計算する。例えば、通知に対する反応時間が通知音、バイブなどの通知モダリティが再生される時間より短い反応履歴を「反応あり」、長い反応履歴を「反応なし」として、反応確率を計算する。つまり、通知モダリティとしてＡ曲が再生され、Ａ曲の再生時間が３分であった場合、反応時間が３分未満ならば「反応あり」、３分以上ならば「反応なし」とする。ここで、反応確率とは、「反応あり」の履歴データ数を全履歴データ数で割ったものである。

図３は反応確率テーブルを作成する例を示す図である。図３（ａ）において横軸は時間、縦軸は場所を示し、○は反応あり、×は反応なしを示している。図３（ａ）に示す例の場合、条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」における「反応あり」の履歴データ数は３個であり、条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」における全履歴データ数は○が３個、×が１個の４個である。よって、条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」における反応確率は０．７５（３／４）になる。反応確率計算部１０４は、このように場所と時刻のＡＮＤ条件ごとに反応確率を計算することで、図３（ｂ）に示されるような反応確率テーブルを作成する。なお、本実施の形態では、通知評価値テーブルとは、反応確率計算部１０４で作成された反応確率テーブルのことである。

修正規則蓄積部１０５は、通知評価値計算部１１０で作成された通知評価値テーブルを更新する修正規則を蓄積する。この修正規則としては、例えば後述する、反応履歴の少ない部分を汎化した反応確率を用いて、反応履歴の少ない部分の反応確率を推定する汎化条件利用規則が存在する。

通知評価値修正部１１１は、修正規則蓄積部１０５の修正規則を利用して、通知評価値計算部１１０で作成された通知評価値テーブルを修正する。通知評価値修正部１１１として、例えば反応確率修正部１０６がある。

反応確率修正部１０６は、修正規則蓄積部１０５の修正規則を利用して、反応確率計算部１０４で作成された反応確率を修正する。

汎化条件利用規則は、例えば履歴データが存在しないか、少ない条件において、条件を汎化し、汎化した条件下における反応確率を用いて、汎化前の条件下における反応確率を更新するという規則である。これにより、履歴が存在しない条件下においても通知の可否を判断することができる。

例えば図４（ａ）に示されるような反応確率テーブルが存在した場合、条件「時刻（１１時〜１３時）かつ場所（会社（会議室））」に適合する状況において、条件を汎化し、条件「場所（会社（会議室））」を作成する。汎化した条件「場所（会議室）」における反応確率「０．０」（場所（会議室）における反応ありデータ数／場所（会議室）における履歴データ数）を用いて、汎化前の条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」下における反応確率を更新する。例えば汎化した条件下の反応確率をそのまま用いて図４（ｂ）に示されるように「０．０」に更新する。

反応確率修正部１０６は、例えば図５（ａ）に示されるような反応確率テーブルに対して、このように修正規則「汎化条件利用規則」を適用して反応確率を更新し、場所に関する条件で汎化した図５（ｂ）に示されるような反応確率テーブルを作成する。

通知情報蓄積部１０７は、ユーザに対して通知する情報を蓄積する。すなわち、通知情報蓄積部１０７は、例えば図６に示されるように、情報を識別する「情報ＩＤ」、当該情報の発信元を表す「配信元（情報発信者）」、例えばタイトルのような当該情報内容を簡単に表す「情報ヘッダ」、当該情報内容の特徴を表す「ジャンル」、実際にユーザに伝えるべき当該情報内容の詳細を表す「情報内容」を蓄積する。情報は例えばインターネットや情報発信基地局などの外部ネットワーク媒体１２０から通知情報蓄積部１０７に提供される。ここで、外部ネットワーク媒体１２０から情報が提供されるのではなく、通知情報蓄積部１０７が予めユーザに通知すべき情報を持っていても良い。

通知タイミング制御部１０８は、反応確率修正部１０６によって修正された反応確率テーブルを記憶する。時刻検知部１００で検知された現在時刻、場所検知部１０１で検知された現在場所と、記憶している反応確率テーブルを用いて、通知情報蓄積部１０７に蓄積された情報の通知タイミングを制御し、当該情報を情報通知部１０９に出力する。

具体的には、通知タイミング制御部１０８は、時刻検知部１００で検知された現在時刻もしくは場所検知部１０１で検知された現在場所が変化したときに、現在の時刻と場所を条件としたときの反応確率に従って、情報を情報通知部１０９に出力する。例えば、図７に示されるように、現在の状況が時刻９時、場所が会社（デスク）であった場合、修正された反応確率テーブル中、条件「時刻（９時〜１１時）かつ場所（会社（デスク））」に対応する反応確率「０．６」に従い、例えば０．６の確率で情報の通知を決定し、通知情報蓄積部１０７に蓄積された情報を情報通知部１０９に出力する。

情報通知部１０９は、通知タイミング制御部１０８から入力された情報をユーザに通知する。例えば、図８に示されるように、情報通知装置を備えた携帯電話１に情報を表示させる場合、通知タイミング制御部１０８によって決定された通知タイミングで、携帯電話から音等によりユーザへ通知を行い、通知タイミング制御部１０８から出力された情報を表示する。

次に、上記のように構成された情報通知装置の動作について説明する。

図９は情報通知装置の動作の流れを示すフローチャートである。ここでは、通知タイミング制御部１０８が記憶する反応確率テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、一般的なユーザの反応履歴から、図１０に示す反応確率テーブル更新フローにより、予め理想的な反応確率テーブルを作成しておいても良い。

通知タイミング制御部１０８は、現在の状況、つまり時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を監視し、現在の状況が変化したか否かを判断する（ステップＳ９０１）。現在の状況が変化しない場合（ステップＳ９０１でＮＯ）は、そのまま監視を続ける。

一方、現在の状況が変化した場合（ステップＳ９０１でＹＥＳ）、すなわち時刻もしくは場所の変化を検知すると、通知情報蓄積部１０７に蓄積された情報について、通知タイミング制御部１０８は、自身が記憶している反応確率テーブルを参照し、時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を条件とした反応確率に従って、通知の可否を判断する（ステップＳ９０２）。

そして、通知タイミング制御部１０８が情報の通知の可否を判断した結果、通知不可であった場合（ステップＳ９０３でＮＯ）は、現在の状況の監視を行う（ステップＳ９０１）。一方、通知タイミング制御部１０８が情報の通知の可否を判断した結果、通知可であった場合（ステップＳ９０３でＹＥＳ）は、通知タイミング制御部１０８は、通知が決定した情報を情報通知部１０９に出力し、情報通知部１０９が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知する（ステップＳ９０４）。

次に、反応確率修正部１０６は、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部１０８が記憶している反応確率テーブルを更新する（ステップＳ９０５）。詳細は後で図１０のフローチャートを用いて述べる。

そして、装置の動作を終了しない場合（ステップＳ９０６でＮＯ）は、現在の状況の監視を行う（ステップＳ９０１）。終了する場合（ステップＳ９０６でＹＥＳ）はフローを終了する。

次に、情報通知後におけるユーザの反応を用いた反応確率テーブル更新動作を図１０のフローチャートを用いて説明する。

反応検知部１０２は、情報を通知したときのユーザの反応を検知する（ステップＳ１００１）。ここで、反応検知部１０２は、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。

次に、反応検知部１０２は、時刻検知部１００で検知された情報の通知を行った時刻から当該通知に対する反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部１０１が検知した場所と共に、反応履歴蓄積部１０３に登録する（ステップＳ１００２）。

反応確率計算部１０４は、反応履歴蓄積部１０３に蓄積されている反応履歴から、反応確率を計算し、反応確率テーブルを生成する（ステップＳ１００３）。次に、反応確率修正部１０６は、修正規則蓄積部１０５に蓄積されている修正規則を用いて、反応確率計算部１０４で生成された反応確率テーブルを修正する（ステップＳ１００４）。そして、反応確率修正部１０６によって修正された反応確率テーブルによって、通知タイミング制御部１０８が記憶している反応確率テーブルを更新する（ステップＳ１００５）。

以上の動作により、ユーザの情報通知の反応履歴から、ユーザが情報を閲覧できるタイミングを制御した情報通知を実現することができるようになる。また、汎化条件利用規則を用いることにより、少ない反応履歴でも、履歴のない条件における反応確率を推定することができるため、学習が早く、局所解に陥らないという利点がある。例えば、ＰＵＳＨ型配信により、店やニュースなどの生活情報がユーザのＧＰＳ付き携帯に配信され、通知される装置があったとする。ユーザは自分から情報を要求しなくても、通知された情報を、都合がいい場合に見るだけで、すぐに装置がユーザの都合のいい時間にだけ通知してくれるようになる。汎化条件利用規則を使わないと、装置が通知した条件における通知の可否しかわからない。このため、装置は局所解に陥り、ユーザがそれほど都合の良くない条件で通知するようになる。例えば、１３時に家にいるときに生活情報をユーザに通知したときに、ユーザの反応があったとする。すると、装置は１３時に家にいるときは通知するが、１２時に家にいるときは通知しない。本当は、同じ家にいるときにでも１３時より１２時に生活情報を通知して欲しいとユーザが思っていたとしても、局所解に陥り、１３時に家にいるときにしか通知しないようになる。しかし、汎化条件利用規則を用いることで、１２時に家にいるときでも装置が反応を推定して通知を行い、１３時に家にいるときよりも反応確率がより高いことを知り、１２時に家にいるときに通知を行うことができる。

また、ユーザに情報を通知しても良い条件は本来、数多く存在するものである。しかし、汎化条件利用規則を用いないと、装置は局所解に陥り、装置が過去に情報を通知して反応があった条件のときしか情報を通知しないようになる。図４の反応履歴テーブルを利用して説明する。汎化条件利用規則を用いないと、反応確率が高い条件、例えば反応確率「１．０」の時刻（７時〜９時）かつ場所（家）と、反応確率「０．７５」の時刻（１１〜１３時）かつ場所（デスク）のときしか情報を通知しないようになってしまう。しかし、例えば時刻（７時〜９時）かつ場所（デスク）の場合に情報を通知することがユーザにとって最も都合がいいかもしれない。汎化条件利用規則を用いると、時刻（７時〜９時）かつ場所（デスク）の場合においても反応確率は「０．６」と推定し、通知する。これにより、反応履歴を得て、時刻（７時〜９時）かつ場所（デスク）に通知すると反応が最も良いと学習することができる。ランダム通知により学習を行うことでは、時刻（１７時〜１９時）かつ場所（車）といったユーザにとって通知して欲しくないと思われる場所でも実際に通知を行ってみないと、ユーザにとって都合が悪いことを学習できない。

（変形例１）
上記のように実施の形態１では、通知評価値計算部１１０は反応確率計算部１０４を含み、反応履歴から通知に対する反応確率を計算することにより、反応確率テーブルつまり、通知評価値テーブルを作成したが、通知タイミング制御部１０８が通知の判断に用いる通知評価値は反応確率でなくてもよい。

つまり、ユーザの反応の良さに応じて反応度を計算し、反応度により反応度テーブルを作成しても良い。図１１は、本発明の実施の形態１に係る情報通知装置の変形例１の構成を示すブロック図である。

具体的には、図１１に示されるように、実施の形態１における反応確率計算部１０４と反応確率修正部１０６を、反応度計算部１５０４と反応度修正部１５０６に置き換えることで実現できる。もちろん反応度も通知評価値の一つであり、通知評価値に含まれる。ここでは、通知評価値テーブルとは、反応度計算部１５０４で作成された反応度テーブルのことである。

例えば、ユーザが通知に対して、同じ通知音を止める反応をしたとしても、１０秒で反応したときと１００秒で反応したときでは、通知タイミングの適切さが異なる。よって、反応度計算部１５０４は、例えば反応履歴の反応時間の平均の逆数をとることで、反応度を算出する。そして、反応度計算部１５０４は、時刻と場所の条件ごとに反応度を算出し、反応度テーブルを作成する。反応履歴蓄積部１０３に例えば図１２（ａ）に示されるような反応履歴が蓄積されていた場合、反応度計算部１５０４は、図１２（ｂ）に示されるように、反応度テーブルを作成し、保存する。図１２の場合、条件「時刻（７時〜９時）＆場所（家）」における反応時間の平均は１５秒｛＝（１０＋２０）／２｝である。よって反応時間の平均の逆数である１／１５を反応度とする。

反応がなかった場合は、反応時間を通知モダリティの再生時間とする。例えば、情報通知において通知音が１０００秒再生される場合は、１０００秒を再生時間とする。図１２の場合、条件「時刻（１１時〜１３時）かつ場所（会議室）」における反応時間の反応度は１／１０００｛＝１／１０００｝である。

反応度修正部１５０６は、実施の形態１と同様に修正規則蓄積部１０５に蓄積された規則に従って反応度テーブルを更新する。反応履歴が図１２（ａ）に示されるように蓄積されていた場合、図１３（ａ）に示されるように、条件「時刻（９時〜１１時）かつ場所（家）」における反応度を求めたい場合は、汎化条件利用規則を用いる。汎化した条件「場所（家）」における反応度は、条件「場所（家）」において反応時間が１０秒、２０秒、６０秒の３つの履歴があることから、反応時間の平均３０｛＝（１０＋２０＋６０）／３｝の逆数である１／３０である。汎化した条件「場所（家）」における反応度１／３０であることから、条件「時刻（９時〜１１時）＆場所（家）」における反応度は１／３０となる。反応度修正部１５０６は、上記同様に履歴がない各条件について汎化を行い、図１３（ｂ）に示されるように、反応度テーブルを更新する。

通知タイミング制御部１５０８は、反応度修正部１５０６が更新した反応度テーブルに従って、通知情報蓄積部に蓄積された情報の通知の可否を判断し、通知する情報を情報通知部に出力する。例えば、現在の時刻と場所に対応する反応度が反応度テーブルの反応度の平均以上であった場合、情報を情報通知部１０９に出力する。

例えば、図１４の場合、条件「時刻（７時〜９時）かつ場所（家）」において、反応度は１／１５であり、反応度のテーブルにおける平均値、０．０５９｛＝（１／１５＋７×１／３０＋１／６０＋９×１／６００＋９×１／１０００＋９×１／５）／３６｝以上であることから、通知は可となり、情報を情報通知部１０９に出力する。

これにより、反応時間が６０秒と大きい「時刻（１５時〜１７時）かつ場所（家）」には通知を行わず、より通知タイミングが望ましいと考えられる反応時間が１５秒と小さい「時刻（７時〜９時）かつ場所（家）」において通知を行うことが可能になる。

このように、修正規則による通知評価値テーブルの修正による通知タイミング制御は、反応確率以外を通知評価値としても有効である。

（変形例２）
なお、本実施の形態１および本実施の形態１の変形例１において、反応履歴として蓄積する情報を増やし、それにより、通知評価値テーブルの次元を増やしてもよい。これにより、よりユーザの状況に応じた通知タイミング制御が可能になる。例えば、反応履歴を蓄積する際、時刻情報を詳細化して、「曜日」、「平日ｏｒ休日」、「上旬ｏｒ中旬ｏｒ下旬」、「年」、「月」、「季節」といった情報を用いてもよい。例えば、「曜日」情報を用いて通知評価値テーブルの次元を増やす場合、反応履歴蓄積部１０３は、図１５に示されるように、「曜日」情報を加えて蓄積する。「曜日」情報は時刻検知部１００が装置内のタイマーにより、検知する。通知評価値計算部１１０は、例えば図１６に示されるように、曜日と時刻と場所のＡＮＤ条件ごとに通知評価値を計算し、保存する。例えば図１６（ａ）、（ｂ）に示されるように、通知評価値として反応確率をとるとき、条件「曜日（月曜日）かつ時刻（７時〜９時）かつ場所（家）」における「反応あり」履歴データ数は２個、全履歴データ数は○が２個の計２個であることより、通知評価値は１．０（＝２／２）になる。このように、実施の形態１と同様に条件ごとに通知評価値を計算するとことで、図１６（ｃ）に示されるような通知評価値テーブルを作成する。通知タイミング制御部１０８は、通知評価値テーブルを参照し、現在の曜日と時刻と場所に対応する通知評価値に基づいて、通知の可否を決定する。例えば、条件「曜日（月曜日）かつ時刻（７時〜９時）かつ場所（家）」における通知評価値が１．０であった場合。１．０の確率で情報を情報通知部１０９に出力する。

これにより、例えば図１５、１６に示されるように、会社に行く前に食事をしている月曜日の朝７時の家では反応確率１．０のため情報を通知するが、ユーザが寝ていて通知に反応できない日曜日の朝７時の家では反応確率０．０のため情報を通知しないということが可能になる。

（変形例３）
なお、実施の形態１や実施の形態１の変形例１では、通知のきっかけとなるユーザの状況の変化の種類に係わらず、通知評価値テーブルは共通のものであった。つまり通知のきっかけが時刻変化でも場所変化でも反応履歴は区別せず、通知評価値テーブルも同一のものであった。しかし、これらを区別し、場所変化、時刻変化という通知のきっかけとなった状況変化の種類によって別々に通知評価値テーブルを作成しても良い。これにより、ユーザ状況に時刻しか変化がなかったときは通知しないが、場所変化という何らかのイベントが起こった場合にのみ情報を通知するということが可能になる。今後、通知のきっかけとなったユーザの状況変化を通知開始イベントと呼ぶ。

例えば、時刻（１１時〜１３時）かつ場所（会議室）に情報を通知したときの反応確率が０．５であったとする。しかし、この反応確率０．５には、時刻が１１時になったことをきっかけとして情報を通知したときの反応履歴も、場所が（会議室）になったことをきっかけに情報を通知したときの反応履歴の双方とも含まれている。しかし、もしかするとユーザは会議室に入った直後だけは、会議がまだ始まっていないため情報の通知を好むが、１０時からずっと会議室にいた場合は、１１時にも会議中で通知を好まないかもしれない。こういった場所変化の直後だけ通知を好むといった状況も考えられる。通知開始イベントごとに通知評価値テーブルを作成することによって、会議室に前からいて時刻が１１時になったときは通知しないが、時刻１１時から１３時の間に会議室に入ってきたときは通知をするといった処理が可能になる。

具体的に動作を説明する。反応履歴蓄積部１０３は、例えば図１７に示されるように、「通知開始イベント」情報を加えて履歴を蓄積する。通知評価値計算部１１０は、例えば、図１８に示されるように、「通知開始イベント」と時刻と場所のＡＮＤ条件ごとに通知評価値を計算し、保存する。図１８（ａ）、（ｂ）に示されるように、通知評価値として反応確率をとるとき、条件「通知開始イベント（場所変化）かつ時刻（１１時〜１３時）かつ場所（会議室）」における「反応あり」履歴データ数は１個、全履歴データ数は○が１個の計１個であることより、通知評価値は１．０（＝１／１）になる。このように、実施の形態１と同様に条件ごとに通知評価値を計算するとことで、図１８（ｃ）、（ｄ）に示されるような時刻変化および場所変化ごとに通知評価値テーブルを作成する。通知タイミング制御部１０８は、ステップＳ９０１で述べたように、現在の状況、つまり時刻検知部１００が検知した現在時刻と場所検知部１０１が検知した現在場所を監視する。通知開始イベントである時刻か場所の変化を検知したときに、通知評価値テーブルを参照し、現在の時刻と場所と通知開始イベントに対応する通知評価値に基づいて、通知の可否を決定する。例えば、条件「通知開始イベント（場所変化）かつ時刻（１１時〜１３時）かつ場所（会議室）」における通知評価値が１．０であった場合。１．０の確率で情報を情報通知部１０９に出力する。

これにより、例えば図１７、１８に示されるように、通知評価値テーブルが作成されていた場合、ユーザが会議室に以前からおり、時刻が１１時になったときは反応確率が０．０のため通知しないが、時刻１１時から１３時の間に会議室に入ってきたときは反応確率が１．０のため通知をするといった処理が可能になる。

上記のように実施の形態１では、反応履歴は通知があったときの場所のみを記録し、通知の可否も現在の場所によって判断していた。しかし、特に場所変化を通知開始イベントとしたときの通知反応には、ユーザが以前にいた場所情報も大きく影響する。よって、ユーザが以前にいた場所も反応履歴として蓄積し、以前の場所を追加し次元を増した通知評価値テーブルを作成することで、より場所変化に対応した通知を行うことができる。

例えば、会社から家に帰ったときは疲れているため情報を通知されても見ないが、庭から家に戻るなど余裕があるときは情報を通知されると見るということがある。本手法を用いることで、通知開始イベント（場所変化）かつ前場所（会社）かつ場所（家）の条件の通知評価値から、会社から家に帰ったときは通知しないということが可能である。同時に、通知開始イベント（場所変化）かつ前場所（庭）かつ場所（家）の条件の通知評価値から、庭から家に戻ったときには通知するということが可能である。

なお、ユーザが以前にいた場所は、局所無線などによってラベル付けされた場所情報のうち一番最近のものであっても良い。具体的に言うと、会社から家に帰ったとき、会社という場所情報を検知した後、ラベルの付いた場所情報を何も検知できない状況が続く。その後、家というラベルの付いた場所情報を検知した場合、会社から家に帰ってきたとする。これにより、「検知なし」というノイズを除去することができ、会社から家への場所変化を検知し、それによりタイミングを制御することができる。「検知なし」の情報を以前の場所情報として使っていた場合は、コンビニから家に帰るときも、会社から家に帰るときも前場所（検知なし）かつ場所（家）となり区別ができなくなる。

また、ユーザが現在いる場所は、ラベルの付いた場所情報でなくても良い。具体的に言うと、「検知なし」という場所情報であっても良い。例えば会社から家に帰ったとき、会社という場所情報を検知した後、ラベルの付いた場所情報を何も検知できない状況が続く。その後、家というラベルの付いた場所情報を検知した場合、会社から家に帰ってきたとする。現在の場所情報に「検知なし」の情報を使わなかったとすると、前場所（会社」かつ場所（家）という条件しか検知できないため、もし会社を出た後すぐに通知することが好ましかったとしても、家に着くまで条件を満たさないため通知できない。しかし、現在の場所情報に「検知なし」の情報を使うことで、前場所（会社）かつ場所（検知なし）という条件により、会社を出た後すぐに情報を通知することができる。

また、本実施の形態において、通知が開始されるイベントは時刻変化もしくは場所変化であったが、ユーザのなんらかの状態変化イベントをきっかけとして情報を通知しても良い。ユーザは仕事が終わった直後、移動する直前など、なんらかの作業の区切り、言わば一息つきたいときに情報を通知されることを好む。しかし、作業の区切りを検知することは難しい。よってユーザの状態変化、具体的には姿勢の大幅な変化を検知したときを作業の区切りとし、姿勢変化をきっかけとして、現在の時刻や場所に対応する通知評価値を計算し、通知評価値に従って通知を行う。

これにより、通知評価値が高い時間帯の中でも、より情報通知が好まれやすいタイミング、ユーザの作業に対する集中を邪魔しないタイミングで通知を行うことができる。なお、姿勢の変化は、例えばジャイロなどの位置センサーをユーザの体につけることで入手する。例えば、ユーザに万歩計（登録商標）をつけ、ユーザの移動を検知し、ユーザの移動が止まったことをきっかけとして通知を行っても良い。

なお、本実施の形態では、現在の時刻だけでなく、場所も考慮して通知タイミングを決定したが、本発明は、場所を考慮することを必ずしも必要としない。つまり、本実施の形態における場所検知部１０１等は必ずしも必須の構成要素ではない。現在時刻とユーザの反応を検知することで、適切な通知タイミングを決定することができるからである。ただし、時刻だけでなく、場所をも考慮することで、より状況に即した通知タイミングの決定が可能になるのは言うまでもない。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

（実施の形態２）
次に、本発明の実施の形態２に係る情報通知装置を説明する。

実施の形態１における汎化条件利用規則では、汎化規則が複数適用できる場合のことを考慮していなかった。例えば汎化条件利用規則を用いる際、条件が「時刻（７時〜９時）かつ場所（会議室）」のときに、場所（会議室）という汎化条件における通知評価値は使っても、時刻（７時〜９時）という汎化条件における通知評価値は用いなかった。しかし実際は、汎化条件を複数用いる方が性能は良い。そこで、本実施の形態では、汎化条件を複数用いる場合について説明する。

汎化規則を用いる際、汎化条件の候補が複数ある場合は次のような複数汎化条件利用規則を用いる。複数汎化条件利用規則は修正規則の一種であり、修正規則蓄積部１０５に蓄積される。通知評価値修正部１１１は蓄積された複数汎化条件利用規則も用いて、通知評価値テーブルを修正する。

条件を汎化した場合、汎化条件は通常複数作成できる。複数の汎化条件下の通知評価値から、汎化前の条件下における通知評価値を求める規則が複数汎化条件利用規則である。例えば、図１９（ａ）に示されるように、時刻（１１時〜１３時）かつ場所（会議室）における通知評価値について、汎化条件利用規則を用いて修正したい場合、複数の汎化条件の通知評価値、つまり時刻（１１時〜１３時）の通知評価値「０．４４」と場所（会議室）の通知評価値「０．０」を用いる。例えば、以下に述べる汎化条件選択規則１を用いて、ユーザが会議室にいることがまれなことから、時刻（１１時〜１３時）かつ場所（会議室）における通知評価値を、例えば図１９（ｂ）に示されるように、場所（会議室）の通知評価値である「０．０」に決定する。

複数汎化条件利用規則には、複数の汎化条件下における通知評価値の中から１つだけ選択する複数汎化条件選択規則と、複数の汎化条件下における複数の通知評価値を用いて通知評価値を修正する汎化条件合算規則とがある。

（１）汎化条件選択規則１
汎化を行う際、複数の汎化条件のうち、条件を満たす状況が発生する頻度が低い条件下の通知評価値、例えば発生確率の低い条件下における通知評価値を用いる方が、ユーザの状況をより厳密に表している条件であるため、信頼できる。例えば、家にいることが多いユーザは、家にいるという条件が通知の可否に対してあまり影響しない。家にいるという条件下での通知評価値が高いユーザでも、家にいるからといって午前３時に情報を通知しても、ユーザは寝ていて気づかない可能性が高い。この場合、家という条件より、午前３時という条件の方が発生確率が低く、通知タイミングを決める重要な要因となる。よって、汎化を行う際は、発生確率の低い条件を優先的に用いる必要がある。

また、履歴データ数が多い条件下における通知評価値を用いる方が、ノイズに影響されにくいため、より信頼できる。よって、汎化条件が複数ある場合、条件に対応する反応履歴のデータ数が閾値以上である汎化条件のうち、発生確率の最も低い汎化条件における通知評価値を用いる。

具体的には、図２２（ｂ）に示されるように、通知評価値テーブルの要素となる時刻や場所からなるＡＮＤ条件ごとに、条件の発生確率、つまり、ある時点にユーザが条件を満たしている確率を計算し、条件発生確率テーブルを作成することにより、これを実現する。

条件発生確率テーブルの作成方法について説明する。

図２０は、条件発生確率テーブルを作成する装置の構成を示すブロック図である。条件発生確率テーブルは、図２０に示されるように、行動履歴蓄積部２４０３と条件発生確率計算部２４０４を用いることで作成できる。

行動履歴蓄積部２４０３は、場所検知部１０１で検知されたユーザの場所と時刻検知部１００で検知された時刻と共に行動履歴として蓄積する。例えば、図２１に示されるように、ユーザの場所とユーザがその場所にいた時刻範囲の組を蓄積する。

条件発生確率計算部２４０４は。行動履歴蓄積部２４０３に蓄積された行動履歴から条件発生確率、つまりユーザの状況が、ある時点において、時刻と場所からなる条件を満たしている確率を計算する。例えば、図２２に示されるように、場所と時刻のＡＮＤ条件ごとに条件発生確率を計算し、条件発生確率テーブルとして保存する。例えば、図２２（ａ）に示されるように、条件発生確率テーブルの、条件「時刻（１７時〜１９時）かつ場所（デスク）」における条件発生確率を計算する場合。行動履歴蓄積部２４０３から発生確率を求めたい条件「時刻（１７時〜１９時）かつ場所（デスク）」を満足する履歴を抽出する。抽出した行動履歴の時刻範囲の合計を計算し、全履歴の時刻範囲の合計で割る。図２２（ａ）の場合、全履歴を１０日間とすると、抽出した履歴の時刻範囲の合計が７．２時間（＝２＋１＋２＋０．５＋０．５＋１．２）であるため、０．０３｛＝７．２／（２４＊１０）｝となる。また、条件「時刻（１７時〜１９時）」における条件発生確率は、抽出した行動履歴の時刻範囲２時間＊１０日／全履歴２４時間＊１０日となり、０．０８３となる。このように、条件ごとに条件発生確率を計算することで図２２（ｂ）に示されるような条件発生確率テーブルが作成される。

次に、条件発生確率テーブルを用いた汎化条件の選択について、具体的に説明する。

図２３は、本発明の実施の形態２に係る情報通知装置の構成を示すブロック図である。なお、図１に示す実施の形態１の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。

情報通知装置は、図２３に示されるように、実施の形態１の構成に加えて、上記にて述べた行動履歴蓄積部２４０３、条件発生確率計算部２４０４を備えている。

通知評価値修正部６００１は、修正規則蓄積部１０５に蓄積されている修正規則と条件発生確率計算部２４０４により作成された条件発生確率テーブルを用いて、汎化条件を選択する。例えば、図２４に示されるように、修正規則として汎化条件利用規則を適用し、条件「時刻（１１時〜１３時）かつ場所（会議室）」における通知評価値を修正するとする。このとき汎化条件の候補として、時刻（１１時〜１３時）という汎化条件Ａと場所（会議室）という汎化条件Ｂを比較する。汎化条件Ａ、Ｂ共に履歴データ数は閾値以上であったとする。時刻（１１時〜１３時）という条件Ａの発生確率は図２２（ｂ）の条件発生確率テーブルより、「０．０８３」である。また場所（会議室）という条件Ｂの発生確率は図２２（ｂ）の条件発生確率テーブルにより、「０．０６４」である。よって、場所（会議室）という条件の方が発生確率は低いため、図２４（ｂ）に示されるように、条件「場所（会議室）」の通知評価値、図２４の場合「０．０」が選択され、条件「時刻（１１時〜１３時）かつ場所（会議室）」における通知評価値は「０．０」に修正される。

これにより、条件「時刻（１１時〜１３時）かつ場所（会議室）」における反応履歴が存在しなかったとしても、汎化条件選択規則１を用いることで、場所（会議室）の通知評価値「０．０」を選択し、通知しないことを決定できる。実際、時刻（１１時〜１３時）は発生確率が大きいため、通知可の可能性と通知否の可能性の両方を含んでいる可能性が高い。

また、７時に交通情報の通知をあまり好まない人でも、同じ７時でもガソリンスタンドにいるときには交通情報の通知を好むということも多いであろう。しかし、ガソリンスタンドで働いている人は、ガソリンスタンドにいるからといって交通情報の通知を好まないであろう。むしろ、時刻７時という条件の方が効いてくると考えられる。条件発生確率を用いるのはこのためである。

（２）汎化条件選択規則１−１
なお、汎化条件について、予め優先順位をつけることで、用いる通知評価値を選択しても良い。通知評価値を選択するためには、基本的に通知評価値の前提となる条件の発生確率を基準として選択する方が良い。しかし、発生確率を求めるためには、条件発生確率テーブルを作成する必要があり、装置に負担がかかる。よって、装置の設計者が発生確率を予め予想し、条件に予め優先順位を設け、簡易的に実現しても良い。例えば、時刻の汎化条件と場所の汎化条件では、場所の汎化条件の方が発生確率が低いと考え、優先順位を上げる。

（３）汎化条件選択規則１−２
また、条件発生確率計算部２４０４が条件の要素となる時刻や場所、通知開始イベントにそれぞれ発生確率を一定値と仮定し、時刻や場所の発生確率を掛け合わせることで簡易的に発生確率を求めても良い。これにより、行動履歴蓄積部２４０３を使わなくても、条件発生確率テーブルを作成できるという利点がある。このため、行動履歴が蓄積されてない学習の初期段階でも条件発生確率テーブルを利用できる。また、装置の負担が減り、行動履歴を蓄積しないため、ユーザのプライバシーに配慮できる。

例えば、条件の要素のとりうる値の種類の数の逆数として発生確率を仮定する。例えば、時刻を２時間ごとに離散化していた場合、時刻のとりうる値の種類の数は１２（２時間／２４時間）である。よって１／１２と仮定する。同様に場所の値の種類が４であった場合、発生確率を例えば１／４とする。また、通知開始イベントの値の種類が２であった場合発生確率を例えば１／２とする。

図２５（ａ）に示されるように、このとき条件「時刻（１７時〜１９時）」の発生確率は１７時〜１９時という時刻値に関わらず、１／１２である。また、条件「場所（家）」の発生確率は場所の値に関わらず、１／４である。また、条件「通知開始イベント（場所変化）」の発生確率は通知開始イベントの値に関わらず、１／２である。また、条件「時刻（１７時〜１９時）かつ場所（家）」の発生確率は時刻要素と場所要素の積集合なので、図２５（ｂ）に示されるように、１／４８（＝１／１２×１／４）となる。また、条件「時刻（１７時〜１９時）かつ通知開始イベント（場所変化）」の発生確率は時刻要素と通知開始イベント要素の積集合なので、１／２４（＝１／１２×１／２）となる。また、条件「場所（家）かつ通知開始イベント（場所変化）」の発生確率は場所要素と通知開始イベント要素の積集合なので、１／８（＝１／４×１／２）となる。条件「時刻（１７時〜１９時）かつ場所（家）かつ通知開始イベント（場所変化）」の発生確率は、時刻要素と場所要素と通知開始イベント要素の積集合なので、１／９６（＝１／１２×１／４×１／２）となる。

これにより、時刻や場所の変化の履歴を蓄積し、条件発生確率テーブルを計算しなくても、より条件発生確率が低いと思われる汎化条件を選択することができる。これにより、時刻や場所の変化の履歴が十分にたまっていない状況においても適切なタイミングで情報を通知することができる。例えば、学習の初期状態において、時刻や場所の変化の履歴は十分たまっておらず、条件発生確率テーブルが作成できない。そして発生確率１／９６である時刻（１７時〜１９時）かつ場所（家）かつ通知開始イベント（場所変化）のときに、通知の可否を判断したいが、条件「時刻（１７時〜１９時）かつ場所（家）かつ通知開始イベント（場所変化）」における反応履歴がなかったとする。このとき、汎化条件下の通知評価値を用いて、通知の可否を判断する。しかし、汎化条件は「時刻（１７時〜１９時）」、「場所（家）」、「通知開始イベント（場所変化）」、「時刻（１７時〜１９時）かつ場所（家）」、「時刻（１７時〜１９時）かつ通知開始イベント（場所変化）」、「場所（家）かつ通知開始イベント（場所変化）」と複数あるが、条件発生確率は履歴が少ないため求められず、どの条件下の通知評価値を用いればよいのかがわからない。このとき、汎化条件選択規則１−２により、擬似的に条件発生確率を計算することにより、条件「時刻（１７時〜１９時）かつ場所（家）」の発生確率が１／４８と最も低いことが判明し、条件「時刻（１７時〜１９時）かつ場所（家）」下の通知評価値に従い、通知の可否を判断することができる。

（４）汎化条件選択規則２
また、複数の汎化条件のうち、通知評価値が特徴的なものを選択しても良い。例えば通知評価値が反応確率であり値が０から１までしかとらないとき、その中間値０．５から最も離れた通知評価値をもった汎化条件を用いる。理由は、特徴的な通知評価値を持った条件の方が、通知の好ましさに影響しているためである。例えば、「時刻（１５時）」、「場所（車）」における通知の可否を制御したいが、条件「時刻（１５時〜１７時）かつ場所（車）」における反応履歴が存在しなかったとする。「時刻（１５時〜１７時）」における通知評価値が０．６であり、中間値０．５に近い。「場所（車）」における通知評価値は０．０であり、中間値０．５から遠い。このとき、「場所（車）」における通知評価値が０．０であることから通知を行わない。これにより、より通知タイミングの可否が明白である条件を優先することができるため、絶対通知して欲しくない状況では通知しないということが可能になる。

なお、汎化条件選択規則において通知することを優先し、複数の汎化条件のうちより大きな通知評価値を持った汎化条件を選択しても良い。

また、汎化条件選択規則において通知しないことを優先し、複数の汎化条件のうちより小さな通知評価値を持った汎化条件を選択しても良い。

（５）汎化条件合算規則
汎化条件合算規則は、複数の汎化条件の通知評価値を用いて、汎化前の条件下における通知評価値を更新する規則である。具体的には、条件ｎかつｍ下における通知評価値を条件ｎの通知評価値と条件ｍの通知評価値を用いて求める。

特に、条件ｎと条件ｍが互いに独立である場合、条件ｎかつｍの通知評価値には、条件ｎと条件ｍの通知評価値が共に係わる可能性がある。よって、発生確率の低いものを選択するだけでは、現実に適合しない可能性がある。

例えば、条件ｎにおける通知評価値がある程度高く、条件ｍも通知評価値がある程度高い場合、それらの要因が合わさって、条件ｎかつｍではさらに通知評価値が高くなる可能性がある。逆に、条件ｎが通知評価値が低く、条件ｍも通知評価値が低い場合、それらの要因が合わさって、条件ｎかつｍではさらに通知評価値が低くなる可能性もある。

例えば、ｎを条件「時刻（１５時〜１７時）」、ｍを条件「場所（会議室）」とする。条件「時刻（１５時〜１７時）」の通知評価値、条件「場所（会議室）」の通知評価値が共にある程度低かったとする。条件「時刻（１５時〜１７時）」と条件「場所（会議室）」はそれぞれ独立の事象である。

このとき条件「時刻（１５時〜１７時）かつ場所（会議室）」のときには通知評価値がさらに低くなり、絶対に情報を通知しない方が良いという可能性がある。もしかすると、時刻（１５時〜１７時）は仕事中の時間であり、場所（会議室）では会議中である可能性がある。時刻（１５時〜１７時）かつ場所（会議室）では重要な仕事の会議が開かれていて、絶対に通知しない方が良いかもしれない。このように複数の汎化条件の特徴を重ね合わせることで通知評価値を修正する。具体的には、条件の発生確率や履歴データ数によって、重みをかけて、複数汎化条件における通知評価値を足し合わせることで算出する。

例えば、時刻（１５時〜１７時）の発生確率が１／１２、場所（会議室）の発生確率が１／６であった場合、発生確率の比は１：２である。よって、２／３×時刻（１５時）の通知評価値＋１／３×場所（会議室）の通知評価値を時刻（１５時）かつ場所（会議室）の通知評価値とする。

条件「時刻（１５時〜１７時）かつ場所（会議室）」における通知の可否を判断したいが、反応履歴がなかったとする。このとき、条件「時刻（１５時〜１７時）」における通知評価値が０．６であり、条件「時刻（会議室）」における通知評価値が０であったとする。発生確率の低い条件を選択すると、条件「時刻（１５時〜１７時）」であり、通知評価値０．６より通知可となってしまう。しかし、場所（会議室）の通知評価値は０であり、絶対に通知をしないほうがいい可能性が高い。こういった場合、複数の条件から通知評価値を計算することで、通知評価値０．４（２／３×０．６＋１／３×０）となり、通知を行わないようにできる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、汎化規則を複数用いて通知評価値が計算され、そのような通知評価値に基づいて、通知タイミングが決定されるので、より高い精度で通知タイミングが決定される。

（実施の形態３）
次に、本発明の実施の形態３に係る情報通知装置を説明する。

上記のように、実施の形態１〜２における通知評価値修正規則では、より大きな概念を表すように汎化した条件における通知評価値を用いるのみであった。しかし、例えば、条件には時刻（１０時〜１１時）と時刻（１１時〜１２時）というように類似した条件がある。そこで、本実施の形態では、類似した条件における通知評価値を用いて、求める条件の通知評価値を更新する規則として近傍汎化規則、類似汎化規則を用いる場合について説明する。

（１）近傍汎化規則
近傍汎化規則とは、近傍の条件における反応履歴データ数や通知評価値を用いて、元々の条件下における通知評価値を更新する規則である。

近傍の条件同士ではユーザの通知に対する反応が同じようになることが多い。よって、近傍の条件下の反応履歴データを利用して通知評価値を更新する。

例えば、図２６（ａ）の場合、条件「時刻（９時〜１１時）かつ場所（会社（デスク））」に適合する状況において、履歴データは存在せず、通知評価値は不定である。このとき近傍の条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」下における通知評価値「０．７５」を用いて、図２６（ｂ）に示されるように、条件「時刻（９時〜１１時）かつ場所（会社（デスク））」における通知評価値を例えば「０．７５」に更新する。

これにより、例えば条件「時刻（９時〜１１時）かつ場所（会社（デスク））」における反応履歴がわからなくても、条件「時刻（１１時〜１３時）かつ場所（会社（デスク））」における通知評価値が０．７５であれば、時刻（９時〜１１時）かつ場所（会社（デスク））において通知評価値が０．７５に更新され、通知することができる。

条件が近傍であるとは、条件に含まれる要素の値の幾つかが同じであるか似ている、もしくは距離が近いということである。条件が近傍であるとは例えば次のようなものである。

特に、近傍汎化規則は以下に述べる実施の形態８の内容評価値テーブルによる情報内容の選択において有用である。近傍の条件同士では同じ情報内容を持つ情報を求めることが多い。

１）条件を表す要素集合に同じ値をもつ要素が存在する場合
条件Ａ「ｘ１かつｙ１」と条件Ｂ「ｘ１かつｙ３」は近傍である。この場合、条件Ａ、Ｂを表す要素のうちｘ１が共通項として含まれるので、ＡとＢは近傍である。例えば、条件Ａ「時刻（１１時〜１３時）かつ場所（会社）かつ通知開始イベント（場所移動）」、条件Ｂ「時刻（１１時〜１３時）かつ場所（家）かつ通知開始イベント（場所移動）」は時刻（１１時〜１３時）かつ通知開始イベント（場所移動）が共通項として含まれるため近傍である。実際に、条件Ａでも条件Ｂでも情報を通知したときに同じような反応を受けることがある。これは、共通項ｘ１が情報通知の可否を決める重要な要素となっていることが多々あるためである。例えば、家でも会社でも１１時〜１３時に場所移動したときは、食事の情報を欲しがっているかもしれない。

これにより、条件「時刻（１１時〜１３時）かつ場所（会社）かつ通知開始イベント（場所移動）」における反応履歴が存在しなくても条件「時刻（１１時〜１３時）かつ場所（家）かつ通知開始イベント（場所移動）」における通知評価値が１．０であれば、条件「時刻（１１時〜１３時）かつ場所（会社）かつ通知開始イベント（場所移動）」において食事情報を通知することができる。

２）条件を表す要素に、距離が近い値を持つ要素が存在する場合
条件Ａ「ｘ１」と条件Ｂ「ｘ２」（ｘ１とｘ２の距離が近い）は近傍である。この場合、条件Ａ、Ｂを表す要素であるｘ１とｘ２の値の距離が近かった場合、条件Ａ、Ｂは近傍である。

まず、物理的に距離が近い場合がある。つまり要素が距離の概念を持っているものである。特に本来連続値であるものが多い。例えば時刻、場所といったものが上げられる。例えば、時刻７時と時刻８時は距離が近い。実際、時刻７時の情報通知と時刻８時の情報通知は似たものになることが多い。また場所の要素で距離が近いと近傍である。例えば「経度１２３°４５'６７"、緯度１００°１２'３４"」と「経度１２３°４５'６８"、緯度１００°１２'３５"」は距離が物理的に近いので近傍である。

物理的な距離が近いことの判別は、通知評価値テーブルを作成した際、テーブルの要素となる値が直接隣接しているものを近傍とする。例えば、時刻において、２時間ごとに離散化して通知評価値テーブルを作成した際、条件「時刻（７時〜９時）」と「時刻（９時〜１１時）は隣接しているため、近傍である。

場所を「ハチ公前」と「モヤイ像前」、「Ａ町１番地」と「Ａ町２番地」、「日本橋」と「難波」などラベル化したものでも距離が物理的に近いので近傍である。物理的距離が近いものは、ユーザがその場所で行うことも似たものとなることが多いため、物理的距離が近い条件時の情報通知の反応は実際似たものとなることが多い。例えば、ハチ公前もモアイ像前も物理的に近いため、同じ待ち合わせ場所として利用されることが多い。よって、双方とも情報を送ったときに好まれる可能性が高い。また、どのような情報を通知すべきか決定する際、物理的距離が近い場所で好まれる情報をユーザに通知すると好まれることが多い。例えば、ユーザが「日本橋」にいるときに「難波」の飲食店情報を送ったとしても、物理的に歩いて行ける距離にあるために、通知が好まれる。

ラベルにおける物理的近傍は、ラベル自体に経度緯度情報など物理的な値を予め与えておき、その物理的な値の距離が最も近いラベルを近傍とする。例えばラベル「Ａ地点」「Ｂ地点」「Ｃ地点」があったときに、ラベル「Ａ地点」の近傍を知りたいとする。「Ａ地点」と「Ｂ地点」の距離が１、「Ａ地点」と「Ｃ地点」の距離が２だったとすると、一番近い「Ｂ地点」をＡ地点の近傍とする。

３）意味的に距離が近い場合
これはｘ１とｘ２が何らかの概念において共通している、似ているということである。具体的に言うと「サッカー」と「野球」はスポーツという点で共通している。「会社」と「取引先」はユーザの働くところという点で共通している。また、東京の「秋葉原」と大阪の「日本橋」は電気街という点で共通している。「東京駅」と「羽田空港」は乗り物に乗るところという点で共通している。これらは反応履歴も似たものになる可能性が高い。例えば、２１時に「サッカー」のニュースを見る人は２１時に「野球」のニュースも見ることが多い。「会社」で娯楽情報を通知されるのを好まない人は「取引先」でも娯楽情報が通知されるのを好まないことが多い。「秋葉原」にいるときにＰＣ情報を通知されるのを好む人は、「日本橋」にいるときもＰＣ情報を通知されるのを好む。これにより、「秋葉原」でＰＣ情報の通知を好むユーザが、「日本橋」に旅行に行ったとしてもＰＣ情報を通知することができる。

距離的に近いという知識や意味的に近いという知識はユーザや装置設計者、情報発信者などが装置に与えても良い。具体的には、修正規則蓄積部１０５に蓄積された近傍汎化規則が近傍データベースを持つことにより、実現する。近傍データベースは、図２７に示されるように、情報を識別するＩＤと互いに近傍となる要素値を組として蓄積する。例えば、ＩＤ（００１）と場所（会議室）、場所（第二会議室）を組にして保存する。これにより、通知評価値修正部１１１は、近傍データベースを検索し、近傍だと判明した条件を用いて、通知評価値の修正を行う。例えば、図２８（ａ）に示されるように、通知評価値テーブルの条件「時刻（１５時〜１７時）かつ場所（第二会議室）」の反応履歴が存在しなかった場合、近傍データベースを検索し、図２８（ｂ）に示されるように、近傍である場所（会議室）を要素とする条件「時刻（１５時〜１７時）かつ場所（会議室）」の通知評価値「０．０」を用いて、場所（第二会議室）の通知評価値を「０．０」に修正する。

特に共通項による近傍と、距離による近傍の複合である、条件Ａ「ｘ１かつｙ１」と条件Ｂ「ｘ１かつｙ２」（ｙ１とｙ２の距離が近い）は最も近傍であり、影響が大きい。よって、同じ場所（会議室）を要素とする条件の通知評価値を用いるときでも、時刻（１５時〜１７時）の共通する条件「時刻（１５時〜１７時）かつ場所（会議室）」の通知評価値を用いる。

なお、通知評価値はデータ履歴の多い近傍条件下における通知評価値をそのまま用いても良いし、データ数や近傍条件との距離に応じて重みをかけてもよい。また、近傍の通知評価値が閾値以上のものは通知評価値を固定値Ａ、閾値以下のものは固定値Ｂとするように、閾値を用いても良い。複数の近傍条件から通知評価値を算出しても良い。

なお、実施の形態２で記述した複数条件利用規則は近傍汎化規則についても用いることが出来る。例えば、「時刻（１５時〜１７時）かつ場所（第二会議室）」の通知評価値を修正する場合、修正候補として近傍条件「時刻（１５時〜１７時）かつ場所（会議室）」と汎化条件「時刻（１５時〜１７時）」、汎化条件「場所（第二会議室）」が存在する。このときも、それぞれの条件を満たす状況が発生する頻度を用いて修正に用いる条件を選択する。例えば汎化条件選択規則１を利用して通知評価値を修正する。

近傍条件「時刻（１５時〜１７時）かつ場所（会議室）」は正確には条件「時刻（１５時〜１７時）かつ場所（第二会議室）」を条件「時刻（１５時〜１７時）かつ、場所（会議室）もしくは場所（第二会議室）」と汎化したものである。この近傍汎化条件「時刻（１５時〜１７時）かつ、場所（会議室）もしくは場所（第二会議室）」の発生確率が０．０２、汎化条件「時刻（１５時〜１７時）」の発生確率が０．０８３、汎化条件「場所（第二会議室）」の発生確率が０．０４であったとすると、最も発生確率の低い近傍汎化条件「時刻（１５時〜１７時）かつ、場所（会議室）もしくは場所（第二会議室）」下の通知評価値を用いて通知評価値を修正する。

４）他の要素を用いた近傍概念の生成
なお、他のセンサー値など、通知評価値テーブルの構成要素とならない他の要素によって、近傍概念を生成し、反応履歴が十分に存在しない部分について近傍条件を用いて通知評価値を修正しても良い。

例えば平休日「（平日）もしくは（休日）」という要素をユーザのスケジュール情報などから検知できたとする。このとき、「曜日」について近傍概念を生成する。スケジュール情報により、例えば、土曜日における休日の発生確率と平日の発生確率が、日曜日における休日の発生確率と平日の発生確率に非常に近い値であったとする。また、月曜日における休日と平日の発生確率が、火曜日〜金曜日の休日と平日の発生確率に非常に近い値であったとする。このとき土曜日と日曜日は休日という要素が近い値をとるため互いに近傍である。月曜日〜金曜日もまた平日休日という要素においてそれぞれ互いに近傍である。

近傍概念の自動生成を用いた、近傍汎化規則を用いた通知評価値テーブルの修正と通知タイミング制御について詳しく説明する。

図２９に示されるように、実施の形態１の構成に他要素検知部６５０１、行動履歴蓄積部６５０３、他要素発生確率計算部６５０２、近傍データベース生成部６５０４、近傍データベース６５０５、近傍汎化規則６５０６を加えることにより、実現する。

他要素検知部６５０１は通知評価値テーブルの構成要素とならない他の要素を検知する。例えば、図２９に示されるように、平休日検知部６５０７を持つこととする。

平休日検知部６５０７は、装置内のユーザが記録したスケジュール情報やカレンダー情報から、現在が平日もしくは休日であるという情報を検知する。

また、時刻検知部６５００は、時刻と共に曜日情報を装置のタイマー等により検知することとする。

行動履歴蓄積部６５０３は、場所検知部１０１で検知したユーザの場所と時刻検知部６５００で検知した時刻と時刻検知部６５００で検知した曜日と他要素検知部６５０１で検知した情報、例の場合平休日検知部６５０８で検知した平休日情報と共に行動履歴として蓄積する。例えば、図３０に示されるように、ユーザの場所と曜日と平休日とユーザがそれらの条件を満たした時刻範囲の組を蓄積する。

他要素発生確率計算部６５０２は。行動履歴蓄積部６５０３に蓄積された行動履歴から条件付き他要素発生確率、つまりユーザの状況がある条件を満たしている時点において、他要素が起こっている確率を計算する。例えば、図３１に示されるように、場所、曜日、時刻ごとに、他要素（平休日）の発生確率を計算し、条件付き発生確率テーブルとして保存する。曜日（火曜日）の条件付き他要素（休日）発生確率を計算する場合、求めたい条件「曜日（火曜日）」を満たす行動履歴を全て抽出する。抽出した行動履歴から他要素（休日）を満たす行動履歴の時刻範囲の合計（２４時間）を計算し、求めたい条件「曜日（火曜日）」を満たす行動履歴の時刻範囲の合計で割る。図３１（ａ）の場合、条件「曜日（火曜日）」を満たす行動履歴の時刻範囲の合計は２４時間の履歴が１０個あることより、２４０時間である。また、条件「曜日（火曜日）かつ平休日（休日）」を満たす行動履歴の時刻範囲の合計は２４時間の履歴が１個あることにより、２４時間である。よって、条件「場所（火曜日）」を満たすときの他要素「平休日（休日）」の発生確率は０．１（＝２４／２４０）となる。同様に。条件「場所（火曜日）」を満たすときの他要素「平休日（平日）」の発生確率は０．９｛＝（２４×９）／（２４×１０）｝である。このように、条件ごとに条件付き他要素発生確率を計算することで、図３１（ｂ）、（ｃ）、（ｄ）に示されるような他要素発生確率テーブルが作成される。

近傍データベース生成部６５０４は、他要素発生確率計算部６５０２で生成された他要素発生確率テーブルを用いて、他要素発生確率の類似した条件から互いに近傍となる条件の組を発見し、近傍データベース６５０５に格納する。

例えば、他要素発生確率テーブルからそれぞれの発生確率の差の低い条件の組を発見する。図３２に示されるように、火曜日と月曜日において近傍かどうかを判別したいとき、それぞれの発生確率の平均二乗誤差を計算する。火曜日と月曜日における平日の発生確率の二乗誤差が０．６４｛＝（０．１−０．９）２｝であり、休日の発生確率の誤差が０．６４｛＝（０．９−０．１）２｝であることから、平均二乗誤差は０．６４｛＝（０．６４＋０．６４）／２｝となる。この平均二乗誤差を閾値と比較し、閾値より低いと近傍とする。閾値を例えば通知評価値の取りうる値の１／１０である０．１としたとすると、平均二乗誤差０．６４＞＝閾値０．１より、近傍ではない。また、火曜日と日曜日における平休日の発生確率の平均二乗誤差は｛（０．１−０．０５）２＋（０．９−０．９５）２｝／２＝０．００２５＜閾値０．１より、火曜日と日曜日は近傍と判別できる。このとき、火曜日と日曜日の組を近傍として識別するためのＩＤと共に、近傍データベース６５０５に格納する。このように、他要素発生テーブルにおける全ての条件の組について近傍を判別し、近傍と判別された条件の組を近傍データベース６５０５に登録する。近傍汎化規則６５０６は当該近傍データベース６５０５を保持する。

通知評価値修正部１１１は、上記（１−３）と同様に、図３３に示されるように、近傍データベース６５０５を検索し、近傍だと判明した条件を用いて、通知評価値の修正を行う。例えば、通知評価値テーブルの条件「曜日（火曜日）かつ時刻（７時〜９時）かつ場所（家）」の反応履歴が存在しなかった場合、近傍データベース６５０５を検索し、曜日（火曜日）の近傍である曜日（日曜日）を要素とする条件「曜日（日曜日）かつ時刻（７時〜９時）かつ場所（家）」の通知評価値「０．０」を用いて、条件「曜日（火曜日）かつ時刻（７時〜９時）かつ場所（家）」を通知評価値「０．０」に修正する。

これにより、通知タイミング制御部１５０５は、反応履歴が存在しなくても、例えば、条件「曜日（火曜日）かつ時刻（７時〜９時）かつ場所（家）」において通知評価値が０．０であることより、０．０の確率で通知つまり、通知しないことを判断できる。

近傍を自動生成することで、より汎化の精度を高めることができる。例えば、ユーザは平日には７時〜９時に家にいるときに情報通知を好むのだが、休日では、７時〜９時はまだ眠っていて情報通知を好まないとする。図３３（ａ）に示されるように、条件「曜日（火曜日）かつ時刻（７時〜９時）かつ場所（家）」の反応履歴がなかったとき、条件「時刻（７時〜９時）かつ場所（家）」で汎化していては、平日、例えば条件「曜日（月曜日）かつ時刻（７時〜９時）かつ場所（家）」の通知評価値「１．０」に影響されてしまう。しかし、平休日情報から近傍を自動生成することで、「曜日（日曜日）かつ時刻（７時〜９時）かつ場所（家）」の通知評価値「０．０」を用いて通知しないことが判断できる。

土日曜日が休日で月〜金曜日が平日と固定されていると、装置設計者が近傍データベースを与えておけばよいのだが、何曜日が休日になるかはユーザにより異なる。本手法により、ユーザによる平休日の違い、つまり近傍概念の違いに対処できる。

なお、近傍データベースを作成するために、ユーザの周辺状況に関する情報を利用してもよい。具体的には、図３４に示されるように、他要素検知部６５０１として、さらに、周辺音を検知する周辺音検知部７００７を備えることにより実現できる。

周辺音検知部７００７は、ユーザの周辺の音情報について、例えば周囲の音の大きさを検知する。具体的には音の大きさを例えば「大」「小」「なし」と離散化して検知する。
これにより、行動履歴蓄積部７００３においては、他要素として周辺音の項目を加えて行動履歴を蓄積する。例えば、図３５に示されるように、ユーザの場所と周辺音とユーザがそれらの条件を満たした時刻範囲の組を蓄積する。

他要素発生確率計算部７００２は。行動履歴蓄積部７００３に蓄積された行動履歴から条件付き周辺音発生確率、つまりユーザの状況がある条件を満たしている時点において、周辺音の各値が起こっている確率を計算する。

同様に近傍データベース生成部６５０４が、条件付き周辺音発生確率により、近傍を探索することで、時刻や場所の近傍が生成される。

これにより、本実施例においては、例えば、会議が行われ、周辺音が大きい場所「会議室」と場所「第二会議室」が近傍であることを推定し、それにより、汎化を行うことができる。

（２）類似汎化規則
類似汎化規則とは反応履歴が類似した条件を用いて汎化を行う規則である。具体的には、例えば時刻（１２時）と時刻（１９時）において反応履歴が類似していた場合、時刻（１２時）と時刻（１９時）の条件を類似条件とし、類似した条件の反応履歴により修正を行う。

例えば、場所（会議室）の通知評価値と場所（講堂）において、場所（会議室）かつ時刻（１０時）における通知評価値と場所（講堂）かつ時刻（１０時）における通知評価値が類似していたとする。類似とは通知評価値の平均二乗誤差が一定値以下であることを言う。

１０時における反応履歴が類似していることから、場所（会議室）と場所（講堂）は他の時間においても反応履歴が類似していることが推定される。このとき、時刻（１３時）かつ場所（会議室）における通知評価値を時刻（１３時）かつ場所（講堂）の通知評価値を用いて修正する。場所（会議室）と場所（講堂）において反応履歴が類似しているということは、通知に対して共通の要因を持っていると思われる。例えば、会議室、講堂は共に会議を行う場所であり、行う時間帯も似ている可能性が高い。よって、双方とも１０時や１３時に会議が行われ、通知が好まれないかもしれない。こういった場合、反応履歴の類似性から、時刻（１３時）かつ場所（会議室）における通知評価値がわからなくても、時刻（１３時）かつ場所（講堂）の通知評価値が０であり低ければ、時刻（１３時）かつ場所（会議室）においても通知を行わないようにできる。

類似汎化規則により、通知をより効率的に行うだけではなく、通知のタイミングを制御する要因を装置が自律的に見つけ出すことができる。例えば、会議室と講堂は通知に対して共通の特性を持っていることが検知できる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、求める条件の通知評価値を更新する規則として近傍汎化規則、類似汎化規則が使用され、そのような通知評価値に基づいて、通知タイミングが決定されるので、より状況に即した通知タイミングが決定される。

（実施の形態４）
次に、本発明の実施の形態４に係る情報通知装置を説明する。

上記実施の形態１〜３における反応確率修正部では、反応履歴が得られていない条件の部分の通知評価値を反応履歴が得られている部分から推測するものであった。しかし、反応確率が得られている部分でも、履歴データ数の少ないものは信頼性が低く、通知評価値を修正する必要がある。このときに、汎化条件の通知評価値だけでなく、本来の条件下の通知評価値も利用した方が、より信頼できる通知評価値となる。そこで、本実施の形態では、これを実現するために、履歴使用規則を修正規則として用いる場合について説明する。

通知評価値が得られている部分を他の条件についての通知評価値で修正するときに使用する規則が履歴使用規則である。通知評価値が得られている部分の通知評価値を修正する場合は、汎化した条件や近傍の条件を使用するだけでなく、元々の条件自身における通知評価値も利用して、通知評価値を更新する。基本的には、履歴データ数により重み付けを行い、足し合わせる。例えば、条件「場所（車中）かつ時間（２３時）」において、履歴データ数が１であり、通知評価値が１．０であったとする。しかし、近傍汎化規則により条件「場所（車中）かつ時間（２１時）」から通知評価値０が推定されたとする。このとき、履歴データ数に応じて重み付けを行う。

例えば｛条件「場所（車中）かつ時間（２３時）」における履歴データ数１×重み２×通知評価値１．０＋条件「場所（車中）かつ時間（２１時）」における履歴データ数８×通知評価値０｝／｛条件「場所（車中）かつ時間（２３時）」における履歴データ数１×重み２＋条件「場所（車中）かつ時間（２１時）」における履歴データ数８｝の計算の結果、「０．２」の通知評価値とする。この例の場合、条件「場所（車中）かつ時間（２３時）」にたまたま１回だけ通知に反応しただけで、実際は反応しないのが普通だったかもしれない。よって、双方から推定される通知評価値から履歴データ数によって重み付けを行うなどして推定を行う。

これにより、条件「場所（車中）かつ時間（２３時）」に反応しないのが普通だったとしても、安易に条件「場所（車中）かつ時間（２３時）」の通知評価値が１．０であることから通知を行わず、履歴使用規則により、条件「場所（車中）かつ時間（２１時）」における通知評価値も用いて通知評価値を更新し、通知評価値０．２から通知しないということが決定できる。

また、条件「場所（車中）かつ時間（２３時）」はいつもの飲み会帰りで別の人に運転してもらっているため、通知は好ましかったかもしれない。条件「場所（車中）かつ時間（２３時）」における履歴データを用いず、汎化条件における通知評価値のみを用いていたのでは、条件「場所（車中）かつ時間（２３時）」に通知することができない。しかし、本来の「場所（車中）かつ時間（２３時）」における履歴データも用いることで、条件「場所（車中）かつ時間（２３時）」における履歴データ数が５個まで集まり、通知評価値１．０であれば、｛条件「場所（車中）かつ時間（２３時）」における履歴データ数５×重み２×通知評価値１．０＋条件「場所（車中）かつ時間（２１時）」における履歴データ数８×通知評価値０｝／｛条件「場所（車中）かつ時間（２３時）」における履歴データ数５×重み２＋条件「場所（車中）かつ時間（２１時）」における履歴データ数８｝計算結果により、通知評価値０．５６となり通知することができる。

このように履歴データ数が多く信頼できる値に重み付けをすることで、ノイズを除去することができる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、反応履歴が得られていない条件の部分の通知評価値を、汎化条件の通知評価値だけでなく、本来の条件下の通知評価値も利用して決定し、そのような、より信頼できる通知評価値に従って通知タイミングが決定されるので、よりユーザにとって好適なタイミングで情報が通知される。

（実施の形態５）
次に、本発明の実施の形態５に係る情報通知装置を説明する。

ところで、同時または連続的に通知する情報の数が多すぎる場合、ユーザに全部の情報を見てはもらえないという問題がある。例えば、携帯メールの場合、一度に１００件メールが来たとしても、普通ほとんど見てはもらえないが、１件のメールを単独で通知された場合には見てもらえる可能性は高い。また、同じ１０件のメールが来たとしても、ユーザが忙しいときには全く見ないが、暇なときには、１０件のメールを全て見るかもしれない。このように状況に応じて、同時または連続的に見る情報の件数は異なると思われる。そこで、本実施の形態では、通知タイミングに加えて、同時または連続的に通知する情報の数も状況に合わせて制御する場合について説明する。

図３６は、本発明の実施の形態５に係る情報通知装置の構成を示すブロック図である。なお、図１に示す実施の形態１の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。

情報通知装置は、図３６に示されるように、実施の形態１の装置の構成に加えて、連続通知数を検知する連続通知検知部１６１０を備えている。

連続通知検知部１６１０は、現在時点における、同時または連続的に通知された情報の数を検知する。例えば、現在までのある一定時間において通知された数を検知する。一定時間は例えばユーザが通知に反応してから、通知情報の閲覧を終了し、情報表示画面の切り替え操作をするまでにかかる平均時間である。

通知タイミング制御部１６０８は、通知評価値テーブル、例えば反応確率テーブルの反応確率にしたがって、通知する情報の最大数を制御する。例えば、予め定めておいた通知数最大数（固定値）と反応確率の積を連続通知最大数とする。図３７に示されるように、時刻（９時）、場所（会社（デスク））における通知タイミングを制御する場合、条件「時刻（９時）かつ場所（会社（デスク））」における反応確率は０．７５である。通知最大数（固定値）を１０と既定したとき、前記条件下における連続通知最大数は８（１０×０．７５を四捨五入）となる。よって、前記条件下における連続通知を８個までとする。例えば、通知情報蓄積部１０７における通知待ち情報が２０個あったとする。それぞれの情報について前記条件下において通知の可否を反応確率から求めたところ、通知可であったとする。このとき通知待ち情報２０個のうち８個までしか同時に通知しないようにする。このとき、２０個の通知情報の中から、ランダムに８個選んでも良い。また情報発信者が予め情報に重要度を与えておき、情報の重要度が高いものから８個選んでも良い。

なお、連続通知数を反応履歴として蓄積し、連続通知数に応じて通知タイミングを制御してもよい。具体的には、図３８に示されるように、実施の形態１の装置の構成に加えて、連続通知検知部１８１０を備え、その情報を反応履歴蓄積部１８０３に蓄積することにより実現できる。

連続通知検知部１８１０は、現在時点における、同時、または連続的に通知された情報の数を検知する。例えば、現在までのある一定時間において通知された数を検知する。

反応履歴蓄積部１８０３は、図３９に示されるように、反応履歴を蓄積する。

例えば、履歴ＩＤ「００４」のように、７：０９に家で、連続通知検知部が３個の情報を検知しているとき、つまりユーザに既に過去一定時間の間で３個の情報を通知しているときに、さらに情報を通知すると、反応が一定時間なかったとする。このとき、通知時刻「７：０９」、通知場所「家」、連続通知数「３」、反応時間「なし」として履歴を蓄積する。

また、反応確率計算部１８０４は、時刻と場所と連続通知数を条件として、条件ごとに反応確率を計算し、時刻と場所と連続通知数の３次元反応確率テーブルを作成する。反応確率修正部１８０６はこの３次元反応確率テーブルを修正し、この３次元反応確率テーブルに従って、通知タイミング制御部１８０８は情報の通知タイミングを制御する。図３９の例でいえば、条件「時刻（７時〜９時）かつ場所（家）かつ連続通知数（３）」における反応確率は履歴から０と計算される。また、条件「時刻（７時〜９時）かつ場所（家）かつ連続通知数（０）」、条件「時刻（７時〜９時）かつ場所（家）かつ連続通知数（１）」、条件「時刻（７時〜９時）かつ場所（家）かつ連続通知数（２）」における反応確率は履歴から１と計算される。このとき例えば、ユーザが時刻７時に家にいる場合において、３個目までは情報が連続的に、または同時に通知されるが、４個目は通知されない。これは、時刻７時に家にいる場合、ユーザは３個までは情報を見るが、４個目は見ないということが履歴から判断できるからである。

これにより、各状況に応じて、ユーザは連続して何個通知されるのが好ましいかをユーザの連続反応数の履歴から判断し、連続通知数を各状況に応じて、詳細に決定することが可能になる。つまり「時刻（７時〜９時）かつ場所（家）」では３個連続で情報を通知するが、「時刻（１３時〜１５時）かつ場所（会議室）」では２個連続で情報を通知し、３個目は通知しないといった処理を、ユーザが普段連続して閲覧している情報の数に従って行うことが可能になる。ユーザが普段情報を１個しか見ない状況では１個しか情報を通知しないが、ユーザが普段情報を１０個見る状況では１０個の情報を通知するのである。

なお、ユーザの情報閲覧時間の履歴を利用して、連続通知数を制限しても良い。情報閲覧時間は例えば、装置が情報内容の表示した時刻から装置が情報内容の表示を終了した時刻までの時間である。同じ一つのメッセージでも、文章が長く閲覧に時間がかかるものと文章が短く閲覧に時間がかからないものがある。よって、文章の長い情報は連続して通知しない、文章の短い情報は幾つか連続して通知するといった処理を行っても良い。具体的には、情報の文章の長さとユーザの閲覧時間の間の相関関数を履歴から推定し、閲覧時間が均一になるように、情報の文章の長さによって、連続的に通知する数を制限する。これにより、文章の長い情報が同時に来たため、ユーザが読むのに苦労する、文章の短い情報が一個しか来なかったため、ユーザが物足りない気分になるといった状況を回避することができる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、通知タイミングに加えて、同時または連続的に通知する情報の数も状況に合わせて制御され、ユーザは、都合のいいタイミングで、それまで蓄積された複数の受信メールを一度に閲覧することができる。

（実施の形態６）
次に、本発明の実施の形態６に係る情報通知装置を説明する。

上記実施の形態１においては、通知タイミング制御部１０８は、現在の時刻を条件とした反応確率を用いてタイミング制御を行っている。本実施の形態では、現在の時刻以降を条件とした反応確率をタイミング制御に用いる場合について説明する。

図４０は、本発明の実施の形態６に係る情報通知装置の通知タイミング制御部の構成を示すブロック図である。なお、図１に示す実施の形態１の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。

通知タイミング制御部２００１は、図４０に示されるように、場所範囲決定部２００５、時刻範囲決定部２００６、および通知可否判定部２００７を備えている。

場所範囲決定部２００５は、現在の時刻から将来における場所範囲を決定する。つまり、現在の時刻において、どの場所に移動する可能性があるかを決定する。

時刻範囲決定部２００６は、現在の時刻から将来における時刻範囲を決定する。つまり、現在の場所において、どれだけの時間、同じ場所にいる可能性があるかを決定する。

通知可否判定部２００７は、反応確率修正部１０６が更新した反応確率テーブル中、場所範囲決定部２００５及び時刻範囲決定部２００６によって決定された範囲内の反応確率を用いることで現在における通知の可否を判定する。

例えば図４１（ａ）に示されるように、現在ユーザが１１時に会社（デスク）にいたとする。現在時刻１１時〜１３時において、ユーザの未来における移動先と思われる場所範囲が「会議室」、「デスク」であったとする。例えば、場所の通知評価値テーブルにおける隣接値を移動先の候補とする。また、ユーザが移動しないと仮定できる時間を装置設計者が予め一定値として決めて置く。例えば６時間としたとする。このときに現在の反応確率が、範囲内の反応確率のうち最も高いものであったとき通知可と判断する。例えば、図４１（ｂ）に示されるように、１１時かつデスクの反応確率に比べて１３時かつデスクの反応確率の方が高いため、後で情報をまとめて通知した方が良いと考え、現在は通知しないということを判断する。

ここで、場所範囲はユーザの行動履歴において、現在の場所から移動する確率が高い場所を選択しても良い。また、時刻範囲は例えば、ユーザの行動履歴から現在の場所における次に移動するまでの平均時間により決定しても良い。

通知タイミングを決定するに当たって、次のような二つの要求項目がある。
１）できるだけユーザにとって好ましいタイミングで情報を通知したい、２）機を逃さずに情報をできるだけ多く通知したい、である。

１）については当然である。ユーザにとって好ましいタイミングに通知しないと見てもらえない可能性があるし、ユーザに嫌がられる可能性もある。より好ましいタイミングで通知した方が、情報のユーザへの受けが良い。

２）は特にニュースなどリアルタイム情報などが関係する。ニュースなどの情報は時間がたち、鮮度が落ちると、価値がなくなってしまう。よってできるだけ早く通知する必要がある。また、広告情報などについても、広告主はできるだけ情報をユーザに通知したい。最適なタイミングでなくとも、読んでもらえないよりは、通知した方がいい場合がある。また、ユーザにとっても、通知されるはずの情報が通知されなかったということは避けたいのは当然である。例えば、いつも楽しみにしていた短編小説情報の通知において、１１回まで楽しく読んでいたのに、タイミングが合わず、１２回が通知されないままとなり、そのあと１３回が通知され、悔しい思いをするということはユーザにとって明らかに不利益である。

１）と２）はトレードオフの関係にある。１）を重視し、できるだけ好ましいタイミングで通知しようと、情報通知を渋っていても、最適のタイミングの条件を、未来においてユーザが満たすとは限らない。かといって２）を重視し、情報を即時に通知していたのでは、ユーザとタイミングが合わず、見てもらえない可能性が高い。本手法は、このトレードオフの解決法の一つである。本手法により、反応確率を考慮すべき未来の範囲を限定することで、より好ましいタイミングで情報を通知することができ、通知漏れになる可能性も低くできる。本手法により、ユーザがそれほど通知を好まない状況で通知をすることも、通知すべき状況を逃して通知できなくなることも避けることができる。ユーザにより通知が好まれる状況を逃すことなく、通知を好む場所に情報を集中して通知することができる。

なお、図４２に示されるように、実施の形態１の情報通知装置の構成に加えて、ユーザの行動を予測する行動予測部２２１０を備えることにより、未来における時刻と場所の範囲を決定し、現在時刻以降を条件とした反応確率を用いたタイミング制御を行っても良い。

行動予測部２２１０は未来におけるユーザの行動を予測する。具体的には、未来におけるユーザのいる場所の変化を予測する。例えば、図４３（ａ）に示されるように、現在ユーザの状況が、時刻１１時、場所（会社（デスク））であった場合、１３時〜１５時には車中、１５時〜２５時には家にいるというような場所の変化を予測する。

通知タイミング制御部２２０８は、行動予測部２２１０によって予測されたユーザの場所変化し、現在だけでなく予測された未来における反応確率も用いて通知タイミングの制御を行う。例えば図４３（ｂ）の場合、現在１１時にはユーザはデスクにいて反応確率は０．７５である。１３時には車中にいると予測され反応確率は０．０である。１５時には家にいると予測され反応確率は０．７である。１７時には家にいると予測され、反応確率は１．０である。１９時には家にいると予測され、反応確率は０．５である。２１時には家にいると予測され反応確率は０．６である。２３時には、家にいると予測され、反応確率は０．３である。これらのことから、１７時に反応確率が最も高く１．０であるために、情報を１７時に家にいるときに通知する。

なお、行動予測部２２１０は、ユーザの行動の履歴、具体的には時刻と場所の変化の履歴を用いて、時刻と場所からなる条件をユーザが満足する確率をそれぞれ計算し、条件発生確率テーブルを作成することで、行動予測を行っても良い。具体的には、ユーザは未来において条件発生確率テーブル中のそれぞれの時刻において最も確率の高い条件を満たすようにユーザは行動するとする。

また、条件発生確率テーブルの作成法は、実施の形態２で説明したものと同様であり、条件発生確率テーブルは図２０に示されるように、行動履歴蓄積部２４０３と条件発生確率計算部２４０４を用いることで作成できる。

また、実施の形態１では、タイミング制御部は現在における通知の可否を判断していた。しかし未来の時刻の反応確率を考慮することにより、未来における通知の可否も判断できる。よって、通知情報にタイミング条件を付加し、情報通知部は現在の状況が通知情報に付加されたタイミング条件を満たしたときに、ユーザに通知するようにしても良い。このことにより、タイミング制御部の作業をサーバ側で全て行い、端末には情報通知部を持たせることでタイミング制御を簡易的に行うことも可能になる。例えば、ある情報に対して、未来行動を予測し、通知タイミングを自宅のＰＣがユーザの行動履歴から計算したところ、「時刻（１７〜１９時）かつ場所（デスク）」に通知するのが最適だったとする。このとき、情報自体に「時刻（１７〜１９時）かつ場所（デスク）」という通知条件を付加し、モバイル端末に入れておくと、通知タイミング計算を端末側が行うことなく、端末が「時刻（１７〜１９時）かつ場所（デスク）」に情報を通知することができる。このため、計算量やメモリの少ない端末においても、通知タイミングをユーザの状況にあわせて制御することができる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、現在の時刻を条件とした反応確率だけでなく、現在の時刻以降を条件とした反応確率を用いて通知タイミングが制御されるので、より広い範囲で適切な通知タイミングが探索され、ユーザにとっての利便性が向上される。

（実施の形態７）
次に、本発明の実施の形態７に係る情報通知装置を説明する。

上記実施の形態１においては、通知タイミング制御部は、反応確率テーブルをそのまま通知タイミング制御に利用している。つまり、反応確率が０．８であれば、０．８の確率で通知を行っている。しかし、反応確率を、実際に通知を行う確率である通知確率に変換し、通知確率を用いて通知タイミング制御を行っても良い。つまり反応確率が０．８であったとき、例えば１．０に確率を変換し、１．０の確率で通知を行う。本実施の形態では、反応確率を通知確率に変換し、通知確率を用いて通知タイミング制御を行う場合について説明する。

図４４は、本発明の実施の形態７に係る情報通知装置の構成を示すブロック図である。なお、図１に示す実施の形態１の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。

情報通知装置は、図４４に示されるように、実施の形態１の構成に加えて、通知確率変換部２８１０を備えている。

通知確率変換部２８１０は、反応確率修正部２８０６によって出力された反応確率テーブルを通知確率テーブルに変換する。変換は通知確率変換関数を用いて行う。通知確率変換関数ｆは、反応確率テーブル各条件下における反応確率Ｐを通知確率Ｐ'に変換するための関数ｆ（Ｐ'＝ｆ（Ｐ））である。通知タイミング制御部は、反応確率テーブルではなく、通知確率変換部が修正した図４５（ｃ）に示されるような通知確率テーブルに従って、情報を通知する。

例えば、図４５（ｂ）に示されるように、通知確率変換関数ｆを
Ｐ＜０．５のとき、Ｐ'＝０
０．５＜＝Ｐ＜＝０．７のとき、Ｐ'＝Ｐ
０．７＜Ｐのとき、Ｐ'＝１
となるように決定したとする。すると、反応確率テーブルは、この通知確率変換関数ｆに従って変換される。例えば、条件（１１時かつデスク）における通知の可否を判定の場合、図４５（ａ）に示す条件（１１時かつデスク）における反応確率は０．７５であるため、通知確率変換関数ｆにより通知確率は１に変換される。よって、通知確率１、つまり条件（１１時かつデスク）において情報を必ず通知する。

通知確率変換関数ｆは広義の単調増加関数となるように決定する。つまり、Ｐが増加すると、Ｐ'も増加もしくは変化なしとなるようにｆを決定する。これは、反応確率が高いほど、通知に適切なタイミングであるからである。

なお、反応確率Ｐが閾値以下のときは通知確率Ｐ'を０となるように通知確率変換関数ｆを決定しても良い。反応確率が小さいときは、操作ミスや、偶然通知を好んだ場合もあり、ノイズの可能性がある。また、反応確率が小さい条件下では、そもそもユーザはその条件下ではそれほど通知して欲しいとは思っておらず、むしろ通知しない方がユーザに好まれることが多い。通知を行うということはユーザのプライバシーに介入するということであり、ユーザに負担をかけるものである。敢えて通知をしないということも重要なのである。

また、反応確率Ｐが閾値以上のときは、通知確率Ｐ'が１００％となるように通知確率変換関数ｆを決定しても良い。反応確率が１００％となっていなくても、操作ミスや、偶然通知を嫌がった、通知に気づかなかったというノイズの可能性がある。また、中途半端な確率で情報を通知するより、１００％で通知した方が良い場合が多々ある。例えばタイミング制御を行い、朝８時に９０％の確率で連続小説を通知していたとする。ユーザはその情報を見るときもあれば、見ないときもある。しかし、今まで朝８時という条件下で通知されていた連続小説が、残りの１０％のために、たまたま通知されず装置の仕様のために見逃すことがあったら、ユーザには不便である。ある程度以上の反応確率をもったものは１００％で通知した方がユーザにとって便利であると考えられる。

また、時刻や場所からなる条件の発生確率が低いものに対しては、全体的に通知確率Ｐ'を上げるように通知確率変換関数ｆを補正しても良い。発生確率が低い条件に関しては、条件を満たしたときにすぐ通知しないと、その条件自体が発生しにくいため、通知しようとしていた情報を全く通知できない可能性がある。これは上記実施の形態２と同様に条件発生確率テーブルを作成し、条件発生確率が装置作成者が決定した閾値より低いときに通知確率Ｐ'を上げることで回避することができる。

例えば条件「場所変化（スキー場）」のときにスキー情報を通知したときの反応確率が６０％であったとする。反応確率がそれほど高くないため、通知したとしても、ユーザは通知に気づいてくれないかもしれない。しかし、「場所変化（スキー場）」という条件がユーザにとってほとんど発生しないものだとすると、そのタイミングで通知しないとユーザにとって有益な情報である可能性があるスキー情報を永久に通知できない可能性がある。よって、そのイベントの発生確率からバイアスをかける、つまり発生確率の低さから通知確率を例えば１００％にすることで、情報の通知漏れを防ぎ、ユーザに比較的好ましいタイミングで、通知することができる。

また、通知に対して反応を返す度合いが多く、通知をそれほど好まない状況においても反応確率が高いユーザもいれば、通知に対してほとんど反応せず、通知を好む状況においても反応確率が低いユーザもいる。どのようなユーザに関してもＰ'の関数を同じにすると、全体的に反応確率が高いユーザは、どのような状況においても通知されてしまう。逆に、全体的に反応確率が低いユーザは、どのような状況においても通知が行われない。これを回避するために、反応確率テーブルにおける反応確率の最小値が高いユーザに対しては、全体的に反応確率Ｐに対する通知確率Ｐ'の値を低くするように通知確率変換関数ｆを調整しても良い。逆に、反応確率テーブルにおける反応確率の最大値が低いユーザに対しては、全体的に反応確率Ｐに対する通知確率Ｐ'の値を高くするように通知確率変換関数ｆを調整しても良い。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、反応確率テーブルをそのまま通知タイミング制御に利用するのではなく、反応確率を、実際に通知を行う確率である通知確率に変換し、通知確率を用いて通知タイミング制御が行われるので、ユーザの個性を反映した柔軟な情報通知装置が実現される。

（実施の形態８）
次に、本発明の実施の形態８に係る情報通知装置を説明する。

実施の形態１においては、情報端末によって情報が通知された場合に、通知に対するユーザの反応を検知し、履歴として蓄積している。具体的には、音等のメディアを利用して情報の通知を行い、ユーザがその通知音を止める操作により、ユーザの通知に対する反応を検知している。しかしながら、ユーザは、通知された情報の内容に応じて、その時刻、場所等の状況において、情報の内容を確認するか否かを判断する場合がある。

そこで、本実施の形態においては、情報端末による情報の通知から、ユーザの情報の内容を確認・閲覧するまでの操作履歴を、ユーザの情報通知に対する反応履歴として検知し、その内容に応じて情報の通知タイミングを制御する場合について説明する。

最初に、情報通知から、ユーザの情報の閲覧までの操作を図４６のフローを用いて説明する。

まず、通知すべき情報があるかどうかを調べる（ステップＳ３００１）。通知すべき情報がない場合（ステップＳ３００１でＮＯ）は、通知すべき情報ができるまで待つ。一方、通知すべき情報があった場合（ステップＳ３００１でＹＥＳ）は、通知音やバイブレータなどの通知モダリティにより、通知すべき情報があることをユーザに通知する（ステップＳ３００２）。

次に、通知に対して反応があったかどうかを検知する（ステップＳ３００３）。反応とは例えば、ユーザが通知音や通知バイブレータを止める動作である。反応がなかった場合（ステップＳ３００３でＮＯ）、ステップＳ３００１に戻る。一方、反応があった場合（ステップＳ３００３でＹＥＳ）は、情報のヘッダを表示する（ステップＳ３００４）。情報のヘッダとは情報内容の主題を簡単に表しているものであり、具体的に言うとタイトルである。

次に、通知された情報の内容表示の指示がユーザからあったかどうかを検知する（ステップＳ３００５）。例えば、ユーザが通知された情報を選択し、ボタンを押すなどの決定操作をすることで内容表示の指示が行われる。指示がなかった場合（ステップＳ３００５でＮＯ）は、ステップＳ３００１に戻る。一方、指示があった場合（ステップＳ３００５でＹＥＳ）は、通知された情報の内容を表示する（ステップＳ３００６）。

次に、文字数により、通知された情報の内容が一画面で表示できるかどうかを調べる（ステップＳ３００７）。表示できない場合（ステップＳ３００７でＮＯ）は、表示した情報内容に次のページがあることをユーザに知らせる（ステップＳ３００８）。例えば、次ページ指示ボタンを表示する。そして、通知された情報内容の次ページ表示指示があったかどうかを検知する（ステップＳ３００９）。なかった場合（ステップＳ３００９でＮＯ）は、ステップＳ３００９に戻る。一方、指示があった場合（ステップＳ３００９でＹＥＳ）、通知された情報内容について、次ページの情報内容を表示する（ステップＳ３０１０）。その後ステップＳ３００７に戻る。

一方、通知された情報の内容が一画面で表示できる場合（ステップＳ３００７でＹＥＳ）は、ユーザが内容表示終了を指示したかどうかを検知する（ステップＳ３０１１）。入力がなかった場合（ステップＳ３０１１でＮＯ）、ステップＳ３０１１に戻る。指示があった場合は、通知された情報の内容表示を終了し、フローを終了する。

図４６のフローを時系列の操作のイベントで表現したものを図４７に示す。図４７において、まず、装置の動作として「情報通知イベント（符号Ａ）」が発生する。これは図４６のステップＳ３００２に対応する。その後、ユーザ操作として「通知に反応イベント」が発生する。これは図４６のステップＳ３００３に対応する。その後、装置の動作として「情報ヘッダの表示イベント」が発生する。これは図４６のステップＳ３００４に対応する。その後、ユーザ操作として、「詳細内容を表示指示イベント」が発生する。これは図４６のステップＳ３００５に対応する。その後、装置の動作として、「情報の内容を表示イベント」が発生する。これは図４６のステップＳ３００６に対応する。その後、ユーザ操作として、「詳細内容の表示終了指示イベント」が発生する。これは図４６のステップＳ３０１１に対応する。その後、装置の動作として「詳細内容の表示終了」イベントが発生する。これは図４６のステップＳ１２に対応する。

図４７に示されるように、情報の通知から情報の閲覧までには、様々なイベントがあり、そのイベントの発生状況、イベント間の時間によって、情報の通知の良否と、情報の内容の良否を共に考慮した情報の通知が実現できる。

「情報通知イベント」から「通知に反応イベント」までの反応時間を、通知評価値計算部１１０が使うことで、通知の良否判定に用いることができる。また「情報ヘッダの表示イベント」から「詳細内容表示指示イベント」までの反応時間を通知評価値計算部１１０が使うことで、通知内容の良否判定に用いることができる。通知した状況において通知内容が悪かった場合、ユーザは通知に反応したとしても、情報ヘッダを閲覧するだけで、詳細内容表示指示は行わないか、行っても反応時間が長いであろう。しかし、通知した状況において通知内容が良かった場合、ユーザは情報ヘッダを閲覧した後、詳細内容表示指示を行い、詳細内容を閲覧する。「情報ヘッダの表示イベント」から「詳細内容表示指示イベント」までの反応時間を通知内容の良否判定に用いることで、内容について評価させるなどユーザの負担をかけずに、状況に応じて通知内容を変更することができる。

図４８は、本発明の実施の形態８に係る情報通知装置の構成を示すブロック図である。

情報通知装置は、時刻検知部１００、場所検知部１０１、反応検知部３２０２、反応履歴蓄積部３２０３、通知評価値計算部１１０、内容評価値計算部３２０５、通知情報蓄積部１０７、通知タイミング制御部３２０８、および情報通知部１０９を備えている。なお、時刻検知部１００、場所検知部１０１、通知情報蓄積部１０７、情報通知部１０９は、実施の形態１と同様の動作を行うものであるので、説明を省略する。

反応検知部３２０２は、情報の通知に対する一連のユーザの反応をユーザの通知機器に対する操作により検知する。具体的には、図４６のフローに示すイベントの有無と各イベント間の時間である。

反応履歴蓄積部３２０３は、情報通知部１０９が情報の通知を行ったときに時刻検知部１００で検知された時刻と、情報の通知を行ったときに場所検知部１０１で検知されたユーザの場所と、反応検知部３２０２で検知されたユーザの反応を蓄積する。実施の形態１においては、図２に示されるように、通知に対して最初に反応するまでの時間、例えば情報通知イベントから通知に反応イベントまでの時間を反応履歴として蓄積していたのに対して、本実施の形態においては、さらに、情報ヘッダの表示イベントから詳細内容表示指示イベントまでの反応時間という履歴を蓄積している。蓄積している情報の例を図４９に示す。

通知評価値計算部１１０は、通知に対する評価を計算する。つまり、通知を行った時刻と場所が適切であったかどうかを表す通知評価値を条件ごとに計算し、通知評価値テーブルを作成する。例えば、実施の形態１の反応確率計算部１０４と同様に、反応確率計算部３２０４が反応履歴蓄積部３２０３に蓄積されている反応履歴からユーザの情報通知に対する反応確率を計算し、反応確率テーブルを作成する。

内容評価値計算部３２０５では、通知した情報内容に対する評価を計算する。つまり、通知を行った時刻と場所において、通知した情報内容が適切であったか否かを示す内容評価値を条件ごとに計算し、図５０（ｂ）に示されるような内容評価値テーブルを作成する。例えば、反応履歴蓄積部３２０３に蓄積されている反応履歴から、ユーザの情報内容に対する反応確率を計算する。例えば、情報ヘッダの表示イベントから詳細内容表示指示イベントまでの反応時間が閾値より短い反応履歴を反応あり、長い反応履歴を反応なしとして、反応確率を計算する。例えば閾値はヘッダ情報を閲覧するのにかかる最大時間として６０秒とする。そして条件ごとに反応確率を計算し、内容評価値テーブルを作成する。図５０は、内容評価値テーブルの作成法を表したものである。例えば、図５０（ａ）に示されるように、通知内容がジャンル「スポーツ」である場合において、時刻（１１時〜１３時）かつ場所（家）において、反応あり履歴が４個あり、反応なし履歴が１個あることから、反応確率つまり内容評価値は０．８である。よって、内容評価値テーブルのジャンル「スポーツ」かつ時刻（１１時〜１３時）かつ場所（家）における内容評価値は０．８となる。

通知タイミング制御部３２０８は、通知評価値計算部１１０で作成された通知評価値テーブルと内容評価値計算部３２０５で作成された内容評価値テーブルを記憶する。通知タイミング制御部３２０８は、時刻検知部１００で検知された現在時刻、場所検知部１０１で検知された現在場所と、記憶している通知評価値テーブルおよび内容評価値テーブルを用いて、通知情報蓄積部１０７に蓄積された情報の通知タイミングを制御し、当該情報を情報通知部１０９に出力する。

具体的には、まず現在の時刻と場所において、通知すべきかどうかについて通知評価値テーブルを用いて判断する。例えば、実施の形態１と同様に、現在の時刻と場所に対応する通知評価値つまり通知反応確率に従って、現在における情報の通知の可否を決定する。通知しないことが決定された場合、情報通知は行わない。通知することが決定された場合、現在の時刻と場所に対応する内容評価値と通知情報蓄積部１０７に蓄積された情報の情報内容に従って、通知する情報を決定する。例えば、通知情報蓄積部１０７に蓄積された情報のうち、内容評価値が最も高い情報について、内容評価値が閾値以上であるならばその情報を通知する。通知することが決定された場合における通知情報の決定法を図５１を用いて説明する。図５１（ａ）、（ｂ）に示されるように、現在の状況が時刻（１１時）、場所（家）であり、通知情報蓄積部１０７にジャンル「スポーツ」「経済」「食事」の情報が蓄積されていたとする。このとき、内容評価値テーブルから時刻（１１時〜１３時）かつ場所（家）におけるジャンル「スポーツ」「経済」「食事」の内容評価値を参照する。この場合、図５１（ｃ）に示されるように、「スポーツ」が０．８、「経済」が０．３、「食事」が０．７である。よって最も内容評価値の高い「スポーツ」の情報を通知する。

以上のように構成された情報通知装置の動作フローを図５２のフローチャートを用いて説明する。ここでは、通知タイミング制御部３２０８が記憶する評価値テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、一般的なユーザの反応履歴から、図５３に示す評価値テーブル更新フローにより、予め理想的な評価値テーブルを作成しておいても良い。

通知タイミング制御部３２０８は、現在の状況、つまり時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を監視し、現在の状況が変化したか否かを判断する（ステップＳ７２０１）。現在の状況が変化しない場合（ステップＳ９０１でＮＯ）は、そのまま監視を続ける。

一方、現在の状況が変化した場合（ステップＳ７２０１でＹＥＳ）、すなわち時刻または場所の変化を検知すると、通知情報蓄積部１０７に蓄積されている情報について、通知タイミング制御部３２０８は、自身が記憶している通知評価値テーブルを参照し、時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を条件とした通知評価値に従って、通知の可否を判断する（ステップＳ７２０２）。

そして、通知タイミング制御部３２０８が情報の通知の可否を判断した結果、通知不可であった場合（ステップＳ７２０３でＮＯ）は、現在の状況の監視を行う（ステップＳ７２０１）。一方、通知タイミング制御部１０８が情報の通知の可否を判断した結果、通知可であった場合（ステップＳ７２０３でＹＥＳ）は、通知情報蓄積部１０７に蓄積されている情報について、通知タイミング制御部３２０８が、自身が記憶している内容評価値テーブルを参照し、時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を条件とした内容評価値に従って、通知情報蓄積部１０７に蓄積された情報のうち、どの情報を通知するかを決定する（ステップＳ７２０４）。そして、通知タイミング制御部３２０８は、通知が決定した情報を情報通知部１０９に出力し、情報通知部１０９が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知する（ステップＳ７２０５）。

次に、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部３２０８が記憶している評価値テーブルを更新する（ステップＳ７２０６）。詳細は図５３のフローチャートにて述べる。

そして、装置の動作を終了しない場合（ステップＳ２７０７でＮＯ）は、現在の状況の監視を行う（ステップＳ７２０１）。終了する場合（ステップＳ７２０７でＹＥＳ）はフローを終了する。

次に、情報通知後におけるユーザの反応を用いた評価値テーブル更新動作を図５３のフローチャートを用いて説明する。

反応検知部３２０２は、情報を通知したときのユーザの反応を検知する（ステップＳ７３０１）。ここで、反応検知部３２０２は、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。

次に、反応検知部３２０２は、時刻検知部１００で検知された情報の通知を行った時刻から当該通知に対する反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部１０１で検知された場所と共に、反応履歴蓄積部１０３に登録する（ステップＳ７３０２）。

次に、情報通知部１０９が通知情報のヘッダ表示を行い、反応検知部３２０２は、通知情報のヘッダ表示に対するユーザの詳細内容表示指示反応を検知する（ステップＳ７３０３）。ここで、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。なお、ステップＳ７３０１にて、一定時間反応がなかった場合は、通知情報のヘッダ表示を行わず、何も検知しなかったこととしてステップＳ７３０５に進んでよい。

ユーザの反応を検知すると、反応検知部３２０２は、時刻検知部１００で検知された通知情報のヘッダ表示を行った時刻から当該通知に対する詳細内容表示指示反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部１０１で検知された場所と共に、反応履歴蓄積部１０３に登録する（ステップＳ７３０４）。

通知評価値計算部１１０は、反応履歴蓄積部３２０３に蓄積されている反応履歴から、通知評価値を計算し、通知評価値テーブルを生成する（ステップＳ７３０５）。次に、内容評価値計算部３２０５は、反応履歴蓄積部３２０３に蓄積されている反応履歴から、内容評価値を計算し、内容評価値テーブルを生成する（ステップＳ７３０６）。

そして、通知評価値計算部１１０によって作成された通知評価値テーブルと内容評価値計算部３２０５によって作成された内容評価値テーブルに従って、通知タイミング制御部３２０８が記憶している通知評価値テーブルと内容評価値テーブルを更新する（ステップＳ７３０７）。

以上の動作の結果、情報通知に対するユーザの一連の反応履歴から。ユーザが情報を閲覧できるタイミングと情報内容を制御した情報通知を実現することができるようになる。

なお、本実施の形態８においては評価値テーブルの修正を行っていないが、実施の形態１のように通知評価値テーブルと内容評価値評価値テーブルを修正規則により修正しても良い。具体的には図５４に示されるように、実施の形態８の構成に、通知評価値修正部１１１、反応確率修正部１０６、内容評価値修正部３７１１、修正規則蓄積部１０５を追加することで実現できる。これにより、履歴の得られていない条件においても他の条件から推定を行い、通知する内容を適切に決定することができる。

内容評価値修正部３７１１は、修正規則蓄積部１０５に蓄積された修正規則により、内容評価値計算部３２０５にて作成された内容評価値テーブルを修正する。修正規則については、通知評価値テーブルを修正する場合と同様に、実施の形態１、２、３、４で述べた汎化規則、履歴使用規則といった修正規則を用いることが出来る。

例えば図５５（ａ）に示されるような内容評価値テーブルが存在した場合、条件「時刻（９時〜１１時）かつ場所（家）」に適合する状況において、条件を汎化し、図５５（ｂ）に示されるような条件「場所（家））」を作成する。汎化した条件「場所（家）」における内容評価値「０．８５」（図５０（ａ）における場所（家）の反応ありデータ数１１／場所（家）における履歴データ数１３）を用いて、汎化前の条件「時刻（９時〜１１時）かつ場所（家）」下における内容評価値を更新する。例えば汎化した条件下の反応確率をそのまま用いて「０．８５」に更新する。

また、本実施の形態８においては、通知評価値テーブルと内容評価値テーブルの間に直接的な関連はなかったが、内容評価値テーブルの評価値によって、通知評価値テーブルの評価値を更新しても良い。具体的には、ある条件における内容評価値がある閾値以上、例えば内容評価値のとりうる値の最大値以上であった場合、その条件における通知評価値を高くする、例えば通知評価値の最大値とする。例えば、時刻（８時）かつ場所（家）において通知を行った際に通知に対する反応時間は長く、通知評価値が低かったとする。しかし、時刻（８時）かつ場所（家）におけるジャンル（天気）情報の内容評価値は非常に高かったとする。こういった場合、ユーザは忙しく通知に対してあまり良い反応はしないが、天気情報であれば閲覧するということが考えられる。しかし、通知評価値が低いため、実施の形態２では通知できなくなってしまう。内容評価値によって通知評価値を最大値とすることで時刻（８時）かつ場所（家）において天気情報を通知することができる。

また、本実施の形態８においては、情報ヘッダ表示イベントから情報内容詳細指示イベントまでの時間によって通知内容評価値を決定している。しかし、ユーザの情報内容の閲覧時間により通知内容評価値を決定してもよい。例えば、ユーザがスポーツの情報を欲していたときは、熱心に見るため閲覧時間も長くなるであろうし、欲していないときは閲覧もおざなりになり閲覧時間は短くなる。具体的には、閲覧時間が長いものを反応あり、短いものを反応なしとして反応確率を計算する。

これにより、情報内容のヘッダ表示と詳細表示がないメディアにおいても、情報の閲覧開始から閲覧終了までの時間を用いることにより通知内容評価値を決定でき、状況において通知内容を変更することができる。閲覧時間は例えば、図４７における情報内容を表示イベント（符号Ｅ）から情報の内容表示を終了イベント（符号Ｇ）までの時間として、反応検知部３２０２が検知する。

また、内容の良否に関わらず閲覧内容によって情報閲覧時間は異なると考えられる。例えば通知情報に動画や音声情報を含んでいた場合は、時間がかかり、再生時間に依存する。よって、通知情報に付随した動画や音声情報の再生時間情報によって情報閲覧時間からの通知内容評価値計算を変更しても良い。例えば、閲覧時間が再生時間以上であった場合、最後まで動画や音声を閲覧したと考え、内容評価値を上げる。逆に閲覧時間が再生時間未満であった場合、途中で閲覧をやめたか、早送りをしたと考えられるため、内容評価値を下げる。これにより、動画や音声情報が閲覧に時間がかかるため、内容評価値が高くなってしまい、ユーザが閲覧したくもないのに通知されてしまうことを防ぐことができる。

また、情報内容によって閲覧時間は異なると考えられる。例えば、あるユーザはニュース情報を閲覧するのは１０分程度かかるが、スポーツ情報を閲覧するには見出しだけ閲覧するので２分程度しかかからないかもしれない。しかし別のユーザはニュース情報を閲覧するのに１０分程度かかるが、スポーツ情報を閲覧するには詳細をじっくり見るので１５分程度かかるかもしれない。よって、ユーザのある情報内容についての閲覧時間履歴からピーク値を抽出し、基本閲覧時間としてもよい。例えば、ユーザのスポーツ情報の閲覧時間の履歴が１０分程度に集中しており、ピーク値が１０分であったとする。このとき基本閲覧時間は１０分であり、閲覧時間が１０分以上のときの内容評価値を上げ、１０分未満のときの内容評価値を下げる。これにより、ユーザがスポーツの情報がニュースの情報より読む時間が長いからといって、毎回スポーツの情報が通知され、ニュースの情報が通知されないということを防ぎ、状況に応じて適切な内容のコンテンツが通知されるようになる。

また、本実施の形態８においては、図４７に示されるようなイベントを用いて、情報内容の詳細情報を閲覧するまでの反応時間により、内容評価値を計算している。しかしユーザは情報の詳細内容を見たあとで、内容が悪いと判断することもあるだろう。よって、図５６に示されるように、情報の詳細内容を表示（符号Ｅ）し、ユーザに評価ボタンにより情報の良否を入力（符合Ｆ）させることで内容評価値を得ても良い。この場合、図５７に示されるようなフローになり、ステップＳ３００１からステップＳ３０１０までは図４６と同様であり、ステップＳ３０１１、ステップＳ３０１２に換えてステップＳ３９１１のようにユーザが評価ボタンを入力したのかを判断するステップとなる。

この場合、内容評価値計算部３２０５は、例えば、良ボタンが押された数を良ボタンもしくは否ボタンが押された数で割った値を内容評価値として計算する。

また、本実施の形態８においては、図４７に示されるようなイベントを用いて通知に反応するまでの時間により、通知評価値を計算している。しかし、ユーザにとって邪魔な通知音を止めるだけで情報は全く閲覧するつもりはない、つまり通知に反応はしても情報のヘッダすら閲覧しないことがある。このようなときには、通知すべきではないが、本実施の形態８ではヘッダ情報すらユーザが閲覧していないことを検知することができない。よって、図５８に示されるように、「情報ヘッダの表示指示イベント（符号Ｉ）」と「情報ヘッダの表示イベント（符号Ｃ）」を導入することで。これを検知することができる。情報ヘッダの表示指示イベントの有無や通知イベントから情報ヘッダ表示指示イベントまでの時間履歴を用いることによって、通知すべきでないときを、より詳細に検知することが可能になる。具体的には、情報通知（符号Ａ）後、情報ヘッダの表示指示イベント（符号Ｉ）がなかった場合、通知評価値を下げる。情報通知（符号Ａ）後、情報ヘッダの表示指示イベント（符号Ｉ）があった場合、通知イベント（符号Ａ）から情報ヘッダ指示イベント（符合Ｉ）までの時間が閾値より短かった場合は通知評価値を上げ、閾値より長かった場合は下げる。例えば、時刻（７時）かつ場所（家）で通知したときに、ユーザが通知音を止め、通知に反応したとしても、ユーザからの情報ヘッダの表示指示イベント（符号Ｉ）がなかった場合、情報を閲覧するつもりはないと推測されるため、時刻（７時）かつ場所（家）における通知評価値を下げる、具体的には反応なしとして反応確率を計算する。また、時刻（９時）かつ場所（家）で通知したときに、ユーザが通知音を止め、通知に反応し、ある時間以内にユーザからの情報ヘッダの表示指示イベント（符号Ｉ）があった場合、時刻（９時）かつ場所（家）における通知評価値を上げる、具体的には反応ありとして反応確率を計算する。これにより、同じように通知に反応したとしても、ユーザが情報を閲覧するつもりのある時刻（９時）かつ場所（家）に通知を行い、ユーザが情報を閲覧するつもりのない時刻（７時）かつ場所（家）に通知を行うことを防ぐことができる。

また、情報通知イベント後、ユーザの情報内容閲覧イベント以前のユーザ反応を通知評価値に影響する反応、ユーザの情報内容閲覧イベント後のユーザ反応を通知内容評価値に影響するものとしても良い。例えば、情報通知イベント後、ユーザの情報内容閲覧イベント以前に、情報通知装置の電源を切った場合は、通知評価値を小さくするが、ユーザの情報内容閲覧イベント後に情報通知装置の電源を切った場合は通知内容評価値を小さくする。

ここで、情報内容閲覧イベントとは、ヘッダ情報が閲覧できる場合は、情報のヘッダ表示イベント（符号Ｃ）であり、閲覧できない場合は情報の内容を表示イベント（符号Ｅ）である。

例えば、９時にスポーツ情報をユーザに通知した直後にユーザが電源を切ったとする。このときスポーツという情報内容に関わらず、ユーザは情報を通知して欲しくない状況であったと考えられる。会議情報という情報内容であっても、ユーザは情報を通知して欲しくなかったであろう。通知直後であり内容閲覧前の反応から９時という状況に対しては、タイミングが悪いという評価情報が生成できる。また、１１時にスポーツ情報をユーザに通知した際に、ユーザは内容を閲覧した後に電源を切ったとする。このとき、内容を閲覧したことから、情報を通知してもよい状況であったかもしれない。しかし、閲覧後電源を切ったことから、少なくともスポーツという情報を通知するには悪い状況であったと考えられる。しかし、内容閲覧を行ったことから、ユーザはその状況において何らかの内容の情報を求めており、もしかすると会議のスケジュールという内容の情報を通知するには適切な状況であった可能性もある。内容閲覧の前後の反応に分割することで、効率的に学習を進めることが可能になる。

また、本実施の形態８においては、情報ヘッダ表示から情報内容詳細表示指示までの反応時間によって通知内容評価値を計算している。しかし、内容閲覧中のユーザの行動によって通知内容評価値を計算しても良い。例えば、情報内容が一画面で表示できなかった場合、次ページをスクロールバーや次ページ表示ボタンにより表示させる。ユーザによってスクロールバーが情報の最後まで閲覧できるように移動されてなかった場合、ユーザは情報を最後まで閲覧する意思がないと推定できるため、通知内容評価値を下げる。同様に、次ページボタンが情報の最後のページが表示されるまで押されていなかったときも、通知内容評価値を下げる。また、１ページあたりの閲覧時間が閾値より短い場合も、内容を読まずに飛ばしたと推定できるため、通知内容評価値を下げる。

また、情報内容が動画であった場合、動画再生を途中で止めたときに通知内容評価値を下げる。また、情報内容が音声であった場合、音声の再生を途中で止めたときに通知内容評価値を下げる。

ユーザが情報ヘッダを閲覧した後、情報内容詳細指示をすぐに行ったとしても、実際に内容を読んでみるとユーザの欲しい情報ではなく、すぐに閲覧をやめてしまうことがある。しかし、これらの技術を用いることで、より厳密に通知内容評価値を決定することができる。

また、実施の形態１において反応履歴蓄積部にジャンル情報も蓄積し、ジャンルの次元も加えて反応確率テーブルを作成し、ジャンルと時刻と場所に対応する反応確率に従って通知を行うことで、情報内容を考慮したタイミング制御を行っても良い。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、情報端末による情報の通知からユーザの情報の内容を確認・閲覧するまでの操作履歴をユーザの情報通知に対する反応履歴として検知し、その内容に応じて情報の通知タイミングが制御されるので、反応履歴がきめ細かくなり、より高い精度で、通知タイミングが決定される。

（実施の形態９）
次に、本発明の実施の形態９に係る情報通知装置を説明する。

上記各実施の形態においては、反応履歴から通知してもよい状況を推測し、その状況において通知を行っているだけである。しかしながら、効率的に通知タイミングを学習するためには、どのような状況における反応履歴が必要なのかを計算し、意図的に通知を行う必要がある。

タイミング制御において学習の目的とするところは次の二点である。１）通知評価値テーブル、内容評価値テーブルといった評価値テーブルの評価値の空欄を埋めることと、２）評価値テーブルの評価値をより特徴的な値、つまり偏りがある値にすることである。意図的に学習するとは、この２点を目的として、装置の側から自律的に通知し、履歴を得ることである。

本実施の形態では、どのような状況における反応履歴が必要なのかを計算し、意図的に通知を行う場合について説明する。

具体的には、図５９に示されるように、学習有効値計算部４６０４と学習有効値計算規則蓄積部４６０５を加えることで実現できる。

学習有効値計算部４６０４は、反応履歴蓄積部１０３に蓄積された履歴から、時刻や場所によって構成される条件について、どの条件下において通知するのが学習にとって有効であるかを示す学習有効値テーブルを、学習有効値計算規則蓄積部４６０５に蓄積された規則に従って作成する。

学習有効値計算規則蓄積部４６０５は、学習有効値テーブルを作成するための規則を蓄積する。規則には、例えば、履歴数依存規則と汎化条件履歴数依存規則が存在する。

（１）履歴数依存規則
履歴数依存規則とは、反応履歴蓄積部１０３に蓄積された、各条件下における反応履歴の履歴数に応じて学習有効値を変化させる規則である。基本的に履歴数の少ない条件下の学習有効値を高く、履歴数の多い条件下の学習有効値を低くする。例えば、図６０の場合、時刻（１１時〜１３時）かつ場所（会議室）における履歴データ数は０であり閾値より少ない。このとき時刻（１１時〜１３時）かつ場所（会議室）における学習有効値に装置設計者が決定した規定値例えば０．３を足す。この規則により、評価値テーブルにおいて履歴が少なくて反応確率が満足に得られない条件下において優先的に通知を行い、学習を促すことができる。

（２）汎化条件履歴数依存規則
汎化条件履歴数依存規則とは、履歴数依存規則を、学習有効値を求めたい条件における履歴数ではなく、その条件を汎化した汎化条件下における履歴数に応じて学習有効値を変化させる規則である。例えば、図６１の場合、時刻（１１時〜１３時）かつ場所（会議室）における学習有効値を求めたい。このとき、汎化した条件、場所（会議室）における履歴数が２であり、閾値より少ない。よって、時刻（１１時〜１３時）かつ場所（会議室）における学習有効値に規定値に例えば０．３を足す。これにより、時刻（１１時〜１３時）かつ場所（会議室）において通知を行うことで、時刻（１１時〜１３時）かつ場所（会議室）だけでなく、場所（会議室）における履歴も得られるため、双方の評価値テーブルを埋めることができる。図６１の場合、時刻（１３時〜１５時）かつ場所（車中）における履歴データ数はないが、場所（車中）における履歴データは十分に存在する。このため、時刻（１３時〜１５時）かつ場所（車中）において通知を行ったとしても時刻（１３時〜１５時）かつ場所（車中）の評価値テーブルしか埋めることができない。汎化条件履歴数依存規則を用いることで、時刻（１１時〜１３時）かつ場所（会議室）における通知を優先することができる。

通知タイミング制御部４６０７は、学習有効値計算部４６０４が作成した学習有効値テーブルに従って、通知タイミングを制御し、通知情報を情報通知部に出力する。例えば、現在の時刻と場所を条件としたときの学習有効値に依存した確率により、通知の可否を決定する。例えば、時刻（１１時〜１３時）かつ場所（会議室）における学習有効値が０．３であった場合、０．３の確率で情報を通知する。

以上のように構成された情報通知装置の動作フローを図６２のフローチャートを用いて説明する。ここでは、通知タイミング制御部４６０７が記憶する学習有効値テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、実施の形態１と同時に用いる場合は、一般的なユーザの反応履歴から、図１０の反応確率テーブル更新フローにより、予め理想的な反応確率テーブルを作成し、それを学習有効値テーブルとしてもよい。

ステップＳ９０１、ステップＳ９０３、ステップＳ９０４およびステップＳ９０６に関しては、実施の形態１と同様なので省略する。

現在の状況が変化した場合（ステップＳ９０１でＹＥＳ）に、すなわち時刻もしくは場所の変化を検知すると、通知情報蓄積部１０７に蓄積された情報について、通知タイミング制御部４６０７は、自身が記憶している学習有効値テーブルを参照し、時刻検知部１００で検知された現在時刻と場所検知部１０１で検知された現在場所を条件とした学習有効値に従って、通知の可否を判断する（ステップＳ７５０２）。

また、情報通知部１０９が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知（ステップＳ９０４）した後、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部４６０７が記憶している学習有効値テーブルを更新する（ステップＳ７５０５）。詳細は図６３のフローチャートにて述べる。

情報通知後におけるユーザの反応を用いた学習有効値テーブル更新動作を図６３のフローチャートを用いて説明する。

ここで、ステップＳ１００１、ステップＳ１００２に関しては実施の形態１と同様なので省略する。

反応検知部１０２における登録処理（ステップＳ１００２）の後、学習有効値計算部４６０４は、反応履歴蓄積部１０３に蓄積されている反応履歴から、履歴数を計算し、履歴数テーブルを生成する（ステップＳ７６０３）。次に、学習有効値計算部４６０４は、学習有効値計算規則蓄積部４６０５に蓄積されている汎化条件履歴数依存規則により、履歴数テーブルから各汎化条件における履歴数を計算し、履歴数に応じて学習有効値を計算し、学習有効値テーブルを作成する（ステップＳ７６０４）。そして、学習有効値計算部４６０４は、学習有効値計算規則蓄積部４６０５に蓄積されている履歴数依存規則により、履歴数テーブルの各条件下における履歴数に応じて学習有効値を修正し、学習有効値テーブルを変更する（ステップＳ７６０５）。次に、学習有効値計算部４６０４によって作成された学習有効値テーブルによって、通知タイミング制御部４６０７が記憶している学習有効値テーブルを更新する（ステップＳ７６０６）。

以上の動作により、ユーザの情報通知の反応履歴を意図的に得られるような情報通知を実現することができるようになる。

なお、本実施の形態９における学習有効値計算規則蓄積部は、次に示す特化規則を持っていても良い。

特化規則は、ある条件の複数の汎化条件下における評価値が中間値（０．５）など、非特徴的な値であった場合、元の条件下における学習有効値を高くする規則である。例えば図６４に示されるように、時刻（１１時〜１３時）かつ場所（会議室）の条件下において、履歴数がほとんどなかったとする。汎化条件時刻（１１時〜１３時）における反応確率は０．４４、汎化条件場所（会議室）における反応確率は０．５５であり、反応確率の中間値０．５との差が閾値０．１以下であり非特徴的な値であるため、通知の可否がわからない。よって、より評価値テーブルを特徴的にするために、時刻（１１時〜１３時）かつ場所（会議室）において反応履歴を得たい。よって時刻（１１時〜１３時）かつ場所（会議室）における学習有効値を高くする、例えば設計者が決定した規定値０．５を加える。時刻（１１時〜１３時）かつ場所（会議室）において通知を行うことで、通知評価値を埋めることができるため、汎化条件では通知の可否がわからないところでも、今後判断できるようになる。

また、本実施の形態９における学習有効値計算規則蓄積部は、次に示す条件発生確率依存規則を持っていても良い。

条件発生確率依存規則とは、学習有効値を求めたい条件の条件自体の発生確率に応じて学習有効値を変化させる規則である。例えば場所（家）という条件の発生確率とは、情報通知装置が稼動している全時間において、ユーザが家にいる確率である。例えば時刻（９時〜１１時）という条件の発生確率は２／２４である。発生確率の低い条件における通知の可否は重要であり、直ちに埋めるべきである。例えば、場所（病院）における薬情報の通知の可否は重要であるが、場所（病院）という条件はほとんど発生しない。また、場所（スキー場）におけるスキー情報の通知の可否は重要であるが、場所（スキー）という条件はほとんど発生しない。その上、発生確率の低い条件は条件を満たしたときに通知を直ちに行わないと、条件を満たす状況がほとんど起こらないため、評価値テーブルをなかなか埋められなくなってしまう。

条件発生確率依存規則では、条件発生確率が高いものは学習有効値を低く、条件発生確率が低いものは学習有効値を高くする。これにより、発生しにくい条件時に優先的に通知することになり、評価値テーブルを効率的に埋めることができる。

具体的に図６５を用いて説明する。例えば時刻８時には出社しているため、時刻（９時〜１１時）かつ場所（家）という条件において条件発生確率は０．０５となり、閾値より低かったとする。しかし、時刻（９時〜１１時）に場所（家）にいるということは遅刻寸前であり、直ちに会社情報を通知すべきであるかもしれない。よって、通知の可否を判断すべく、直ちに履歴を得る必要がある。このため、学習有効値を高くする必要がある。
具体的には、時刻（９時〜１１時）かつ場所（家）における学習有効値に規定値、例えば０．３を加える。

これにより、条件「時刻（９時〜１１時）かつ場所（家）」が発生したときに直ちに通知を行うことができるため、発生確率が低さからいつまでも「時刻（９時〜１１時）かつ場所（家）」の評価値が埋まらないという現象を防ぐことができるため、次に条件「時刻（９時〜１１時）かつ場所（家）」を満たしたときには会社情報を通知できるようになる。

この規則を用いるためには、各条件における条件発生確率を計算した条件発生確率テーブルが必要である。これは、上記実施の形態２に述べたように、ユーザの行動履歴、例えば時刻と場所の変化の履歴を保存することにより、計算できる。

また、本実施の形態９における学習有効値計算規則蓄積部は、次に示す要因推定規則を持っていても良い。

要因推定規則とは、ある条件下における反応確率が中間値（０．５）など、非特徴的な値であった場合、その条件下において発生確率の高いイベントを通知開始イベントとするときの反応確率を高くする規則である。具体的には、各条件における場所変化、ユーザの状態変化といったイベントの発生確率テーブルを行動履歴から計算することで実現できる。

例えば、図６６に示されるように、時刻（１１時〜１３時）かつ場所（会議室）において反応確率が０．５であり、通知の可否がわからなかったとする。こういった場合、条件の要素である時刻や場所とは別の要因が通知に対する反応の違いに現れていると考えられる。例えば、時刻（１１時〜１３時）かつ場所（会議室）の間に起こったイベントよっても反応は異なると考えられる。よって、その条件時に起こったイベントを探索し、そのイベントが起こったときにのみ通知すると反応確率により特徴が出るのではないかと考えられる。つまり、その条件時における発生確率の高いイベントを通知開始イベントとして通知するように、学習有効値を高くする。図６６の場合会議室に入るという場所変化イベントの起こる確率が高いことから、場所変化イベントを通知開始イベントとする学習有効値テーブルの時刻（１１時〜１３時）かつ場所（会議室）における学習有効値を高くする。

これにより、会議室に入った直後は通知を好むが、その後は通知を好まないユーザがいたとしても、反応履歴から会議室に入った直後にのみ通知を行うことができる。

通知開始イベントによって、反応確率テーブルを分割する方が反応確率はより特徴的になる。しかし、通知開始イベントそれぞれに対する反応確率テーブルを埋めるためには学習データが大量に必要になる。通知開始イベントを限定しない反応確率テーブルから、要因推定規則を用いて、学習に必要な条件を推定することで、反応確率が非特徴的な部分を効率的に特徴的な値にし、通知の可否を判断できる。

また、本実施の形態９における学習有効値による通知タイミング制御は、上記各実施の形態と同時に用いて、通知評価値テーブルを作成する補助的な役割として用いてよい。このとき履歴数が少ない間は、学習有効値及び通知評価値によって情報が通知されるが、履歴数が増えるに従って、学習有効値が下がるため、通知評価値のみによって情報が通知されるようになる。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、どのような状況における反応履歴が必要なのかを計算し、その結果に依存して意図的に通知が行われるので、必要性の高い場合にだけ情報が通知され、利便性の高い情報通知装置が実現される。

（実施の形態１０）
次に、本発明の実施の形態１０に係る情報通知装置を説明する。

実施の形態５においては、特に携帯電話などの携帯端末におけるメールの数の制御において、より好ましいタイミングで同時に通知するメールの数を増やすように制御していた。タイミングについては、時刻や場所が変化したときのみに、通知評価値を参照し、メールを通知していた。しかし、携帯端末におけるメールにおいては、友達から食事への誘いのメールや家族からの送迎の依頼メールなど、緊急性をもったメールが多く、できるだけ早く通知することが望まれる。このため、メールを閲覧してもらえる確率の高い時刻や場所では、時刻や場所が変化したとき以外にも受信したメールをユーザに通知する必要がある。

しかし、いくら読んでもらえるメールの数が多いからといって、メールを受信したタイミングで通知しては、メールの通知回数が多くなり、ユーザにメールを１通通知した後、ほとんど時間も経たないのに、また別の新規メールをユーザに通知してしまうといった自体を引き起こしてしまう。このように携帯端末におけるメールの通知は、音や光、振動により、ユーザのタスクを妨げてしまうため、通知回数を減らすことも必要とされる。つまりできるだけ早く通知するということと、できるだけ他のメールと同時に通知することにより、通知回数を減らすということの両方が求められる。

これを実現するにあたって、メールを受信した後、一定時間待ち、その間に来たメールと同時にまとめて通知するという手法が考えられる。しかし、最初のメールを受信した後、必ず一定時間待たなくてはならないという問題がある。また、一定時間後は、ユーザに対してメールを通知してはいけない状況になっている可能性もある。

よって本実施の形態では、現在以降における通知評価値及びメールの受信スケジュールを取得する。これらを取得することで、どのタイミングで、メールをまとめて同時に通知することが最適であるかを判断できるため、通知回数を減らしながら、できるだけ早くメールを通知することができる。

図６７は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部１００、場所検知部１０１、反応検知部１０２、反応履歴蓄積部１０３、通知評価値計算部１１０、通知情報蓄積部６７０７、通知タイミング制御部６７０８、情報通知部６７０９、メール蓄積部６７１０および受信規則蓄積部６７１１を備える。なお、前記実施の形態１で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図６７、図６８を用いて説明し、後に本装置の動作について説明する。

通知情報蓄積部６７０７は、ユーザに対して通知するメール情報を蓄積する。すなわち、通知情報蓄積部６７０７は、例えば図６に示されるように、情報を識別する「情報ＩＤ」、当該情報の発信元のメールアドレスを表す「差出人アドレス」、情報の宛先のメールアドレスを表す「宛先アドレス」、端末の情報受信日時を表す「受信日時」、受信日時例えばタイトルのような当該情報内容を簡単に表す「件名」、実際にユーザに伝えるべき当該情報内容の詳細を表す「情報内容」を蓄積する。情報は、例えば、インターネットや情報発信基地局などの外部ネットワーク媒体１２０から通知情報蓄積部６７０７に提供される。ユーザに対して通知したメール情報は、通知情報蓄積部６７０７から削除される。

受信規則蓄積部６７１１は、メールの受信スケジュールを蓄積する。メールの受信スケジュールとは、日常的に規則的に受信するメールの受信時刻のスケジュールであり、図７０に示されるように、スケジュール識別のための「ＩＤ」、メールの発信元のメールアドレスを表す「差出人アドレス」、メールを受信する曜日を表す「受信曜日」、メールの主な受信時刻を表す「受信時刻」により構成されている。スケジュールは受信時刻順に並べられている。例えば、ＩＤ「００１」は差出人アドレス「ｍａｉｌｉｎｇ＿ｌｉｓｔ＠ｍａｉｌｉｎｇ＿ｌｉｓｔ．ｐａｎａｓｏｎｉｃ．ｊｐ」から受信曜日「毎日」、受信時刻「１０：００」にメールを受信することを示している。特にメールマガジンなどは、そのメールを受信する曜日、時刻が決まっていることが多い。また、夜寝る前にメールを送信する人や、会社の昼休みにメールを送信する人など、メールの送信時刻が同じ時刻に決まっている人も多い。このため、規則的に受信するメールが数多く存在する。よって、予めユーザやメール配信者の手により、このようなメールの受信スケジュールを作成しておくことができる。

通知タイミング制御部６７０８は、時刻検知部１００で検知された現在時刻、場所検知部１０１で検知された現在場所と、反応確率計算部１０４によって計算された反応確率を用いて、通知情報蓄積部１０７に蓄積された情報の通知タイミングを制御し、当該情報をメール蓄積部６７１０に出力し、情報通知部６７０９に情報の到着をユーザに知らせるようにする。また、このとき、通知情報蓄積部６７０７に蓄積された情報を削除する。通知タイミング制御部は、図６８のように、通知可能判定部６７１２、次メール取得部６７１３、次通知時刻計算部６７１４、利点計算部６７１６、通知判定部６７１７から構成されている。以下、それぞれについて説明する。

通知可能判定部６７１２は、反応確率計算部１０４が計算した反応確率テーブルから、時刻検知部１００、場所検知部１０１、次通知時刻計算部６７１４によって指定された時刻、場所において通知を行うことが可能であるか否かを判定する。具体的には、指定された時刻、場所における反応確率が閾値以上であった場合に通知可能、閾値未満であった場合に通知不可と判定する。閾値は、例えば０．５とする。

次メール取得部６７１３は、受信規則蓄積部６７１１に蓄積されたメールの受信スケジュールと時刻検知部１００が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻を取得する未来メール取得部の一例である。例えば、図７０に示されるように、メールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「１１：２０」であった場合、土曜日が受信曜日に含まれるＩＤ「００１」、「００３」、「００４」「００５」…の中で、メールの受信時刻が、現在時刻「１１：２０」以降であり、最も現在時刻に近傍にあるＩＤ「００３」の受信時刻「１１：３０」を次メール受信時刻として取得する。

次通知時刻計算部６７１４は、次メール取得部６７１３が取得した次メール受信時刻から、場所検知部１０１が検知した現在場所において、次メール受信時刻以降で最も早く通知可能となる時刻を、通知可能判定部６７１２を用いて計算する。例えば、図７１に示されるように、次メール受信時刻が「１１：３０」であり、現在の場所は「家」であり、「１１：３０〜１１：５９」まで通知不可能であり、「１２：００〜１２：４４」まで通知可能であったとすると、次メール受信時刻以降で、最も早く通知可能となる時刻は「１２：００」となる。よって、次通知可能時刻は「１２：００」である。

利点計算部６７１６は、次通知時刻計算部６７１４が算出した次通知可能時刻から、現時点で即座に全てのメールを通知することに対する、次通知可能時刻で次メールも含めて通知することの利点を計算する。ただ、各メールの受信時刻に応じて、メールが遅延することにより失われる利点は異なると思われる。そのため、通知情報蓄積部６７０７に蓄えられた各メール情報の受信時刻も利点計算に用いる。例えば、次通知可能時刻で次メールも含めて通知することの利点をＭとし、次メールも含めて通知することにより、通知回数が一回減るために得られる利点をＴとし、メールを通知するのが遅れることにより失われる利点を一通、一分につきＤとし、通知情報蓄積部６７０７に蓄えられた各メールの受信時刻をｔ（分）、次通知可能時刻をＮ（分）とすると、具体的にＭは次の式で表される。

つまり、利点とは、通知回数が減ることによって得られるメリットから通知情報蓄積部６７０７に蓄えられた全てのメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図７２に示されるように、通知回数減による利点Ｔが１００、通知遅延により失われる利点Ｄが１、次通知可能時刻Ｎが「１２：００」、通知情報蓄積部６７０７に蓄積されたメールが３通で、受信時刻がそれぞれ「１１：００」「１１：１０」「１１：１９」だったとする。すると利点Ｍは、「１００−１｛（１２：００−１１：００）＋（１２：００−１１：１０）＋（１２：００−１１：１９）｝＝−５１」となり、「−５１」である。

通知判定部６７１７は、利点計算部６７１６が算出した利点から、通知情報蓄積部６７０７に蓄積された全メールを通知するか否かを判定する。具体的には、利点が閾値０より大きいならば、全メールを通知しないと判定し、メールを出力しない。閾値０以下ならば全メールを通知すると判定し、通知情報蓄積部のメールを全てメール蓄積部６７１０に出力し、情報通知部６７０９にメールの到着を知らせるようにする。このとき、通知情報蓄積部６７０７のメールを全て削除する。

情報通知部６７０９は、通知判定部６７１７が情報を通知すると判定した場合、メールの到着をユーザに光、振動、音などで通知する。例えば、携帯端末がメール着信音を鳴らすことによりメールの到着をユーザに知らせる。

メール蓄積部６７１０は、通知判定部６７１７が情報を通知すると判定したメールを、ユーザがいつでも閲覧可能な状態として端末内に蓄積する。例えば、メーラーの受信フォルダである。

以下、本実施の形態１０のフローチャートを、図７３を用いて説明する。前記実施の形態１で示した構成要素には同様の符号を付与し、説明を省略する。まず、通知可能判定部６７１２が、時刻検知部１００が検知した現在時刻と、場所検知部１０１が検知した現在場所から現在の通知可否を判定する（ステップＳ７３０１）。情報通知が不可能であった場合、ステップＳ７３０１に戻る（ステップＳ７３０２のＮｏ）。情報通知が可能であった場合、ステップＳ７３０３に進む（ステップＳ７３０２のＹｅｓ）。

情報通知が可能であった場合、次メール取得部６７１３が、時刻検知部１００が検知した現在時刻と受信規則蓄積部６７１１に蓄積された受信スケジュールに従って、次メールの受信時刻を取得する（ステップＳ７３０３）。通知可能判定部６７１２が、場所検知部１０１における次メール取得部６７１３が取得した次メール受信時刻以降の通知可否を判定し、その結果から、次通知時刻計算部６７１４は、次メール受信時刻以降の最も早い通知可能時刻を取得する（ステップＳ７３０４）。利点計算部６７１６は、次通知時刻計算部が算出した次メールの通知可能時刻と、通知情報蓄積部６７０７に蓄積されたメール情報の受信時刻から、次メールを受信した後、蓄積されたメール情報を一度に通知することの利点を算出する（ステップＳ７３０５）。

通知判定部６７１７は、利点計算部６７１６が算出した利点から現在、通知を行うか否かを判定する（ステップＳ７３０６）。通知を行わないと判定したとき、ステップＳ７３０１に戻る（ステップＳ７３０７のＮｏ）。通知を行うと判定したとき、ステップＳ７３０８に進む（ステップＳ７３０７のＹｅｓ）。

通知を行うと判定したとき、通知判定部６７１７は、通知情報蓄積部６７０７に蓄積された全てのメール情報をメール蓄積部６７１０に蓄積する（ステップＳ７３０８）。通知判定部６７１７は、通知情報蓄積部６７０７に蓄積された全てのメール情報を削除する（ステップＳ７３０９）。情報通知部６７０９は、メールの到着をユーザに音や光、振動などで通知する（ステップＳ７３１０）。以下実施の形態１と同様である。

なお、本実施の形態１０では、メールの受信スケジュールの受信時刻には、ばらつきが存在しなかった。しかし、実際のメールではネットワークの配送遅延や、人間の行動の不確定性により、受信時刻にばらつきがある場合が存在する。例えば、１０：００〜１０：３０の間のどれかの時間に来るというメールも存在する。また、受信スケジュールにないメールが来る場合ももちろん存在する。こういった場合、新たにメールを受信したときに、そのメールが受信スケジュールに存在するメールであるか否か、受信スケジュールにあるメールだったとしてもどのメールなのかを特定する必要がある。図７４のように、現在時刻が「１１：２０」であり、「１１：１６」にメールを一通受信していたとする。このとき、このメールが受信スケジュールＩＤ００３のメールであったならば、「１１：４５」までにメールを受信することは予定されず、次メール受信時刻は「１２：１５〜２０」となる。しかし、受信スケジュールＩＤ００３のメールでなかったならば、「１１：４５」までにメールを受信する可能性が大いにあるため、次メール受信時刻は「１１：２０〜１１：４５」となる。よって受信したメールを受信スケジュールのメールと対応させることが必要である。例えば、実際受信したメールと受信スケジュールのメールで「差出人アドレス」が同一であること、メールの「件名」の文字列の一致性が高さから対応させる。

また、本実施の形態１０では、情報の内容に関わらず、次のメールと同時に出すか即時に出すかを判断していた。しかし、携帯電話の場合、友達や家族からの食事などの誘いのメールや待ち合わせのときのメールなど即座の返信を求めるいわば即時性の高い情報も存在する。よってメールの内容により、次のメールと同時に出すか即時に出すかを判断してもよい。例えば、差出人アドレスが携帯電話のアドレスになっているもの、ユーザの返信率の高い差出人アドレスからのメールについては、無条件で即時に出すようにしてもよい。また、実施の形態８と同様に内容評価値を計算し、内容評価値の高いメールについては、無条件で即時に出すようにしてもよい。

また、本実施の形態１０では、ユーザのいる場所は変化しないものとして、未来の反応確率を予測していた。しかし、場所は変化する場合があり、その変化は予測できる。よって、実施の形態６の変形例と同様に行動予測部を備えることにより場所変化を予測し、現在以降の反応確率を用いて、未来の通知の可不可を判断しても良い。

また、本実施の形態１０では、場所に関わらず端末のメール受信スケジュールは一定とした。しかし、端末の場所により、電波状況や端末の電源のＯＮ、ＯＦＦは異なり、メールを受信できない場所も存在する。よって、受信スケジュールの受信時刻にメールを受信できないこともある。そこで、携帯電話などの端末の電波状況を監視することにより、各場所に対するメール受信可能か不可能であるかの対応付けを行う。そして、実施の形態６の変形例と同様に行動予測部を備えることにより場所変化を予測し、その場所変化に対応したメール受信可能、不可能の時間区間も予測する。メール受信不可能の場合は受信スケジュールの受信時刻を次に受信可能になる時刻に変更する。

例えば、図７５に示されるように、受信スケジュールが存在し、電波状況測定などにより、場所とメールの受信状況対応表が作成されていたとする。行動予測部による予測結果は「１１：００〜１２：２０」までユーザが会議室にいることが予測され、「１２：２０〜１３：００」までユーザがデスクにいることが予測されていたとする。このとき、場所とメールの受信状況対応表から会議室ではメール受信不可であり、デスクでは受信可能であるため、図７５に示されるように、「１１：００〜１２：２０」まで「メール受信不可能」、「１２：２０〜１３：００」まで「メール受信可能」と予測される。よって、受信スケジュールの「１１：３０」のメールと「１２：１５」のメールは受信不可能であると推測されるため、それぞれの受信時刻を受信可能となる「１２：２０」に補正する。これにより、メールを受信できない場所があったとしても、メールの受信時刻を予測することができる。

また、本実施の形態１０では、全てのメールを同時に出すか、次のメールを待つかの判定を、通知評価値を用いて、次のメールを通知できる時刻を算出することにより、判定していた。しかし、例えば、未来においても通知できることがわかっている場合、もしくは、反応履歴がないときなどは、通知評価値を計算せず、未来のメールの受信時刻のみを用いて通知するか否かを判定しても良い。このとき、受信時刻が遅いときに通知をするようにする。例えば、現在時刻と次に受信する予定のメールの受信時刻の差が閾値以上であるときに、現在蓄積されている全てのメールを通知すると判定する。

なお、昔のメールが何時までたっても通知できなくなる可能性があるため、現在時刻ではなく、通知情報蓄積部に蓄積されたメールの受信時刻を用いても良い。例えば、通知情報蓄積部に蓄積されたメールの受信時刻と未来のメールの受信時刻の差が閾値以上のときに、現在蓄積されている全てのメールを通知すると判定する。

また、通知情報蓄積部に蓄積されたメール数を考慮しない場合には、ユーザにメールを通知したときに、同時に大量のメールが通知される可能性がある。このため、ユーザが読みきれない場合がある。よって、通知情報蓄積部に蓄積されたメールの数を判定に用いても良い。例えば、通知情報蓄積部に蓄積されたメールの数が閾値以上のときに、現在蓄積されている全てのメールを通知すると判定する。

また、実施の形態１０では、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連に関わらず、現在メールを通知するか、次のメールを待つかを判断していた。しかし、実際は、同内容のメール、同一送信者からのメールなど関連するメールが同時にまとめて通知される方が、別の内容のメールが同時にまとめて通知されるより、好まれやすい。さらに、内容が関連した複数のメールについて時間を空けて通知されると、関連するメールを思い出さなければならないため、非常に読みづらくなる。よって、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連性を用いて、現在通知の是非を判定してもよい。関連性が高いときには、現在通知を行わず、次メール受信まで待つことで、関連するメールをまとめて通知することができる。

図７６は、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連性を用いて現在通知の是非を判定する変形例に係る情報通知装置の構成（ここでは、特徴的な構成要素である通知タイミング制御部８８０８の構成）を示すブロック図である。通知タイミング制御部８８０８以外の構成については、実施の形態１０と同様である。実施の形態１０で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図７６を用いて説明し、後に本装置の動作について説明する。

次メール取得部８８１３は、受信規則蓄積部６７１１に蓄積されたメールの受信スケジュールと時刻検知部１００が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻と差出人アドレスを取得する。例えば、図７０のようにメールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「１１：２０」であった場合、土曜日が受信曜日に含まれるＩＤ「００１」、「００３」、「００４」「００５」…の中で、メールの受信時刻が、現在時刻「１１：２０」以降であり、最も現在時刻に近傍にあるＩＤ「００３」の受信時刻「１１：３０」及び差出人アドレス「ｓｙｏｋｕｂａｎｏ＿ｒｅｎｒａｋｕ＠ｊｐ．ｐａｎａｓｏｎｉｃ．ｃｏｍ」を次メール受信時刻として取得する。

関連性判定部８８２１は、通知情報蓄積部６７０７に蓄積されたメールの情報と次メール取得部８８１３が取得したメールの情報を比較し、関連性の有無を判定する。具体的には、次メールの差出人アドレスが蓄積されたメールの差出人アドレスと一つでも一致する場合は、関連性有と判定する。例えば、図７７のように通知情報蓄積部６７０７にメールが蓄積されており、次メール取得部８８１３が取得したメールの差出人アドレスが、「ｔｕｕｔｉ＿ｔａｉｍｉｎｇ＠ｊｐ．ｐａｎａｓｏｎｉｃ．ｃｏｍ」であったとする。この差出人アドレスと通知情報蓄積部６７０７に蓄積されたメールの差出人アドレスを比較すると、ＩＤ「００３」のメールの差出人アドレスが「ｔｕｕｔｉ＿ｔａｉｍｉｎｇ＠ｊｐ．ｐａｎａｓｏｎｉｃ．ｃｏｍ」であり、一致するため、関係性有と判定する。実際、差出人アドレスが同じメールは、内容も関連することが多く、まとめて読んだほうがユーザにとって都合が良い場合が多い。例えば、ＩＤ００３のように、「寝過ごして、見たかったテレビ見逃した・・・撮ってない？」というメールの次に同じ送信者から「ついでに、食事に行かない？」というメールが来た場合、まとめて読んだほうが、ユーザは差出人に対して返信メールをわざわざ２通出す必要はなく、１通だけ出せば良くなる。

利点計算部８８１６は、次通知時刻計算部６７１４が算出した次通知可能時刻から、現時点で即座に全てのメールを通知することに対する、次通知可能時刻で次メールも含めて通知することの利点を計算する。通知情報蓄積部６７０７に蓄えられた各メール情報の受信時刻も利点計算に用いる。また、次メールが蓄積されていたメールに関連がある場合、次メールとまとめて通知することに利点が存在するため、関連性判定部８８２１の関連性判定結果も用いる。例えば、次通知可能時刻で次メールも含めて通知することの利点をＭとし、関連性のあるメールをまとめて通知することにより得られる利点をＲとし、関連性判定部８８２１の判定結果をｒ（関連性有ｒ＝１、関連性無ｒ＝０）とし、次メールも含めて通知することにより、通知回数が一回減るために得られる利点をＴとし、メールを通知するのが遅れることにより、失われる利点を一通、一分につきＤとし、通知情報蓄積部６７０７に蓄えられた各メールの受信時刻をｔ（分）、次通知可能時刻をＮ（分）とすると、具体的には、Ｍは次の式で表される。

つまり、利点とは、関連性のあるメールをまとめて通知すること、通知回数が減ることによって得られるメリットから通知情報蓄積部６７０７に蓄えられた全てのメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図７８のように、関連性の有るメールをまとめて通知することにより得られる利点Ｒが１００、通知回数減による利点Ｔが１００、通知遅延により失われる利点Ｄが１、次通知可能時刻Ｎが「１２：００」、通知情報蓄積部６７０７に蓄積されたメールが３通で、受信時刻がそれぞれ「１１：００」「１１：１０」「１１：１９」であり、次メールと関連性があったとする。すると利点Ｍは、「１＊１００＋１００ − １｛（１２：００−１１：００）＋（ １２：００−１１：１０）＋（ １２：００−１１：１９）｝＝−５１」となり、「４９」である。

このような変形例に係る情報通知装置の動作を示すフローチャートを、図７９を用いて説明する。実施の形態１０で示した構成要素には同様の符号を付与し、説明を省略する。本変形例の情報通知装置では、実施の形態１０と同様に情報通知が可能であると判定を行った後、情報通知が可能であった場合、次メール取得部８８１３が、時刻検知部１０１が検知した現在時刻と受信規則蓄積部６７１１に蓄積された受信スケジュールに従って、次メールの受信時刻と差出人アドレスを取得する（ステップＳ８９０３）。通知可能判定部６７１２が、場所検知部１０１における次メール取得部８８１３が取得した次メール受信時刻以降の通知可否を判定し、その結果から次通知時刻計算部６７１４は、次メール受信時刻以降の最も早い通知可能時刻を取得する（ステップＳ７３０４）。関連性判定部８８２１は、通知情報蓄積部６７０７に蓄積されたメールの差出人アドレスと次メール取得部８８１３が取得したメールの差出人アドレスの情報を比較し、関連性の有無を判定する（ステップＳ８９０４）。利点計算部８８１６は、次通知時刻計算部が算出した次メールの通知可能時刻と、通知情報蓄積部６７０７に蓄積されたメール情報の受信時刻、関連性判定部８８２１が判定したメールの関連性から、次メールを受信した後、蓄積されたメール情報を一度に通知することの利点を算出する（ステップＳ８９０５）。以下実施の形態１０と同様である。

なお、この変形例の情報通知装置では、関連性判定部８８２１は、差出人アドレスの一致判定により、関連性を判定していた。しかし、差出人アドレスが違ってもメールのない様に関連性がある場合が存在する。具体的には、メンバーの誰もがメールを送信できるコミュニティのメーリングリストなどにおいて、同じメーリングリストに対するメールの場合は差出人アドレスが異なっても内容に関連性が有る場合が多い。このとき、返信先も同一であることが多く、複数のメールを受け取ったとしても一通のメールでまとめて返信をすることができる。具体的には、関連性判定部８８２１は、メールの返信先アドレスつまり「Ｒｅｐｌｙ−ｔｏアドレス」を次メールと通知情報蓄積部に蓄積されたメールで比較し、「Ｒｅｐｌｙ−ｔｏアドレス」が一致するときは、関係性有と判定してもよい。

また、メールをまとめて通知する際に同内容のメールはソートして通知しても良い。つまり、差出人アドレスの順にソートをしてユーザに通知する。これにより、ユーザは同内容のメールをまとめて続けて読むことができる。

また、メールをまとめて通知する際に、ユーザが返信を要するメールと返信を要しないメールに分類した上で通知しても良い。これにより、ユーザは返信を要しないメールをまとめて続けて読むことができる。例えば、差出人がメーリングリストの主催者のメールは返信を要しないメールだと考えられるため、差出人が友達のメールなど返信を要するメールと分類ソートした上で、通知してもよい。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置が実現される。

つまり、本実施の形態では、現在以降における通知評価値及びメールの受信スケジュールを取得し、どのタイミングで、メールをまとめて同時に通知することが最適であるかを判断しているため、通知回数を減らしながら、できるだけ早くメールを通知することができる。

（実施の形態１１）
次に、本発明の実施の形態１１に係る情報通知装置を説明する。

本実施の形態１０では、状況による通知の可不可と受信スケジュールにあわせて、受信したメールを全て通知するか、次のメールが来るまで待つかを制御していた。しかし、実際は同じ通知が可能な状況でも、通知の好ましさは異なる。このため、実施の形態５では、状況に応じて同時に通知できるメールの最大数を制限していた。よって、通知の好ましさ、つまり同時に通知できるメールの最大数も考慮したうえで、複数のメールについて通知のタイミングと数を制御してもよい。このとき、現在受信しているメールの数が、現在通知できる最大数のメール数以下である場合は実施の形態１０とほぼ同様である。しかし、現在受信しているメールの数が、現在通知できる最大数のメール数を上回る場合は問題となる。このとき、通知待ちメールを同時に全て通知できない。よって、通知回数を増やしてでも、通知できる最大数のメールを即座に通知するのか、それとも状況変化を待ち、全てのメールを通知できるタイミングで通知するのかの判断が重要となる。現在受信しているメールを全て通知できるタイミングで通知しようとしても、現在受信しているメールを全て通知できるタイミングになるまでに、さらに新しいメールを受信することもある。すると、通知待ちメール数が増加するため、結局全てのメールを同時に通知できなくなってしまう可能性もある。こういった問題には、現在受信している全てのメールについて、未来において受信するメールも含めて、全て同時に通知できるタイミングを現在時刻以降から算出し、現在通知できる最大数まで即時に通知したときに対する利点を算出することにより対処する。

図８０は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部１００、場所検知部１０１、通知評価値計算部１１０、通知情報蓄積部６７０７、情報通知部６７０９、メール蓄積部６７１０、受信規則蓄積部６７１１、反応検知部７４０２、反応履歴蓄積部１８０３、通知タイミング制御部７４０８および連続通知検知部７４２０を備える。前記実施の形態１、５、１０で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図８０、図８１を用いて説明し、後に本装置の動作について説明する。

反応検知部７４０２は、情報の通知に対するユーザの反応をユーザの情報通知装置に対する操作により検知する。例えば、通知されたメール全てについてユーザが詳細内容まで閲覧したかどうかを検知する。

連続通知検知部７４２０は、現在時点における、同時に通知されたメールの数を検知する。

最大通知数計算部７４１９は、反応確率計算部１８０４が作成した時刻と場所と連続通知数に対する３次元反応確率テーブルから時刻と場所に対する最大通知数のテーブルを作成する。最大通知数は、同時に通知することがユーザに好まれる最大のメール数であり、反応確率が閾値以上となる通知数の中で最も小さいものから１を引いた値である。つまり、「ｎ＝１，２，・・・，Ｎ」に対して「通知数ｎの反応確率＞＝閾値」がなりたつ整数Ｎのうち最大の数である。閾値は例えば０．５とする。図８２の場合、時刻「７時〜９時」場所「家」に対する反応確率は、連続通知数「１」のとき「０．９」、連続通知数「２」のとき「１．０」、連続通知数「３」のとき「０．３」となる。初めて反応確率が閾値未満となるのは連続通知数「３」のときなので、時刻「７時〜９時」場所「家」に対する最大通知数は「２」となる。

通知タイミング制御部７４０８は、時刻検知部１００で検知された現在時刻、場所検知部１０１で検知された現在場所と、最大通知数計算部７４１９によって計算された最大通知数を用いて、通知情報蓄積部６７０７に蓄積された情報の通知タイミングと通知する情報の数を制御し、当該情報をメール蓄積部６７１０に出力し、情報通知部６７０９に情報の到着をユーザに知らせるようにする。また、このとき、通知情報蓄積部６７０７に蓄積された情報を削除する。通知タイミング制御部は、図８１に示されるように、全通知可能判定部７４１２、未来メール取得部７４１３、全通知時刻計算部７４１４、利点計算部７４１６、通知判定部７４１７から構成されている。以下、それぞれについて説明する。

全通知可能判定部７４１２は、最大通知数計算部が作成した最大通知数テーブルから、時刻検知部１００、場所検知部１０１、全通知時刻計算部７４１４によって指定された時刻、場所において、通知情報蓄積部６７０７に蓄積されたメール及び未来メール取得部７４１３で取得したメールの全てについて同時通知を行うことが可能であるか否かを判定する。具体的には、指定された時刻、場所における通知最大数が、通知情報蓄積部６７０７に蓄積されたメールと未来メール取得部７４１３で取得したメールの数の合計以上であった場合に通知可能、合計未満であった場合に通知不可と判定する。

未来メール取得部７４１３は、受信規則蓄積部６７１１に蓄積されたメールの受信スケジュールと時刻検知部１００が検知した現在時刻、及び全通知時刻計算部７４１４が算出した全通知可能時刻を用いて、現在時刻から全通知可能時刻までの間に未来メール取得部が取得するメールの数を取得する。例えば、図７０に示されるように、メールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「１１：２０」であり、全通知可能時刻が「１２：３０」の場合、土曜日が受信曜日に含まれるＩＤ「００１」、「００３」、「００４」「００５」…の中で、メールの受信時刻が、現在時刻「１１：２０」から「１２：３０」の間にあるメールの合計数３を取得する。

全通知時刻計算部７４１４は、時刻検知部１００が検知した現在時刻から、場所検知部１０１が検知した現在場所において、現在時刻以降、未来メール取得部７４１３が取得したメールの数と通知情報蓄積部６７０７が取得したメールの数の合計が最も早く通知可能となる時刻を、全通知可能判定部７４１２を用いて計算する。通知可能時刻を一旦計算しても、通知可能時刻までに新たに受信するメールが存在する可能性があるため、未来メール取得部７４１３が取得したメールの数と通知情報蓄積部６７０７が取得したメールの数の合計が変化しなくなるまで、通知可能時刻算出を繰り返す。未来メール取得部７４１３が取得したメールの数と通知情報蓄積部６７０７が取得したメールの数とはその時点において通知情報蓄積部６７０７に蓄積されることが予想される待機メールの数である。

例えば、図８３に示されるように、最大通知数テーブルが作成されており、次メール受信時刻が「１１：３０」であり、現在の場所は「家」であり、通知情報蓄積部６７０７に３通のメールが蓄積されていたとする。現在時刻以降で３通全て通知できる最も早い時刻は「１１：３０」であるが、図８３に示される受信スケジュールでは、「１１：３０」までに１通のメールを受信するため、待機メールは４通なる。このため、「１１：３０」には、最大通知数は３通であるため、全てのメールを通知できない。同様に「１２：１５」にも待機メールは５通となるため全てのメールを通知できない。よって、６通の待機メールを全て通知できる「１２：３０」が全通知可能時刻となる。

利点計算部７４１６は、全通知時刻計算部７４１４が算出した全通知可能時刻から、現時点で即座に最大通知数のメールを通知することに対する、全通知可能時刻で全メールまとめて通知することの利点を計算する。ただ、各メールの受信時刻に応じて、メールが遅延することにより失われる利点は異なると思われる。そのため、通知情報蓄積部６７０７に蓄えられた各メール情報の受信時刻も利点計算に用いる。また、即座に通知したとしても最大通知数（現時点での最大通知数とは、最大通知数計算部７４１９が算出した最大通知数テーブルのうち、現在時刻と現在場所に対応する通知数をいう）までのメールの数しか通知できないため、利点計算には、最も古いメールから最大通知数だけのメールを利点計算に用いる。

例えば、全通知可能時刻で通知情報蓄積部６７０７に蓄積された全メールまとめて通知することの利点をＭとし、全メールまとめて通知することにより、通知回数が減るために得られる利点をＴとし、メールを通知するのが遅れることにより、失われる利点を一通、一分につきＤとし、通知情報蓄積部６７０７に蓄えられた各メールの受信時刻をｔｎ（分）（ｎが小さいほど受信時刻は早い）、現時点での最大通知数をＸ、全通知可能時刻をＮ（分）とすると、具体的にＭは次の式で表される。

つまり、利点とは、通知回数が減ることによって得られるメリットから通知情報蓄積部６７０７に蓄えられたメールのうち即座に通知できるメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図８４のように、通知回数減による利点Ｔが１００、通知遅延により失われる利点Ｄが１、全通知可能時刻Ｎが「１２：３０」、現時点での最大通知数を２、通知情報蓄積部６７０７に蓄積されたメールが３通で、受信時刻がそれぞれ「１１：００」「１１：１０」「１１：１９」だったとする。すると利点Ｍは、「１００−１｛（１２：３０−１１：００）＋（１２：３０−１１：１０）＝−７０」となり、「−７０」である。

通知判定部７４１７は、利点計算部７４１６が算出した利点から、通知情報蓄積部６７０７に蓄積されたメールのうち、現時点での最大通知数だけのメールを通知するか否かを判定する。現時点での最大通知数とは最大通知数計算部７４１９が算出した最大通知数テーブルのうち、現在時刻と現在場所に対応する通知数である。

具体的には、利点が閾値０より大きいならば、通知しないと判定し、メールを出力しない。閾値０以下ならば最大通知数の数だけメールを通知すると判定し、通知情報蓄積部のメールのうち、受信時刻が最も早いものから最大通知数のメールをメール蓄積部６７１０に出力し、情報通知部６７０９にメールの到着を知らせるようにする。このとき、出力した通知情報蓄積部６７０７のメールを削除する。

以下、本実施の形態１１のフローチャートを、図８５を用いて説明する。前記実施の形態１０で示した構成要素には同様の符号を付与し、説明を省略する。まず、全通知可能判定部７４１２が、時刻検知部１００が検知した現在時刻と、場所検知部１０１が検知した現在場所、通知情報蓄積部６７０７に蓄積されたメールの数、最大通知数計算部７４１９が作成した最大通知数テーブルから現在の全通知可否を判定する（ステップＳ７９０１）。情報通知が全く不可能であった場合、ステップＳ７９０１に戻る（ステップＳ７９０２のＮｏ）。情報通知が１通でも可能であった場合、ステップＳ７９０３に進む（ステップＳ７９０２のＹｅｓ）。全メール通知が可能であった場合、実施の形態１０と同様にステップＳ７３０３に進む（ステップＳ７９０３のＹｅｓ）。全メール通知が不可能であった場合、ステップＳ７９０４に進む（ステップＳ７９０３のＮｏ）。

全通知時刻計算部７４１４は、通知情報蓄積部６７０７が蓄積しているメールの数と未来メール取得部７４１３が取得したメールの数の合計である待機メール数に対する、仮の全通知可能時刻を現在時刻、現在場所と最大通知数計算部７４１９が算出した最大通知数テーブルから算出する（ステップＳ７９０４）。未来メール取得部７４１３は、全通知時刻計算部７４１４が指定した仮の全通知可能時刻までに受信する予定であるメールの数を受信規則蓄積部６７１１から取得し、通知情報蓄積部６７０７に蓄積されたメールの数に加えて、待機メールの数とする（ステップＳ７９０５）。

全通知時刻計算部７４１４は、待機メール数に変化があるかどうかを判定し（ステップＳ７９０６）、変化があった場合はステップＳ７９０４に戻る（ステップＳ７９０６のＹｅｓ）。変化がなかった場合は、仮の全通知可能時刻を全通知可能時刻と確定し、ステップＳ７９０７に進む（ステップＳ７９０６のＮｏ）。利点計算部７４１６は、通知情報蓄積部６７０７に蓄積されたメール情報の受信時刻と現在時刻、現在場所における最大通知数、全通知時刻計算部７４１４が算出した全通知可能時刻から、状況変化を待ち、蓄積されたメール情報を同時に通知することの利点を算出する（ステップＳ７９０７）。

通知判定部７４１７は、利点計算部７４１６が算出した利点から最大通知数のメールについて、現在通知を行うか否かを判定する（ステップＳ７９０８）。通知を行わないと判定したとき、ステップＳ７９０１に戻る（ステップＳ７９０９のＮｏ）。通知を行うと判定したとき、ステップＳ７９１０に進む（ステップＳ７９０９のＹｅｓ）。通知を行うと判定したとき、通知判定部７４１７は、通知情報蓄積部６７０７に蓄積されたメールのうち、現在の最大通知数だけのメールをメール蓄積部６７１０に蓄積する（ステップＳ７９１０）。

通知判定部７４１７は、通知情報蓄積部６７０７に蓄積されたメールのうち、メール蓄積部６７１０に蓄積したメール情報を削除する（ステップＳ７９１１）。情報通知部６７０９は、メールの到着をユーザに音や光、振動などで通知する（ステップＳ７９１２）。

反応検知部１０２は、情報を通知したときのユーザのメールの詳細内容閲覧反応を検知する（ステップＳ７９１３）。連続通知検知部７４２０は、同時に通知されたメールの数（連続通知数）を検知する（ステップＳ７９１４）。反応検知部１０２は、時刻検知部１００で検知された情報の通知を行った時刻から当該通知に対する閲覧反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部１０１が検知した場所、連続通知検知部７４２０が検知した連続通知数と共に、反応履歴蓄積部１８０３に登録する（ステップＳ７９１５）。

反応確率計算部１８０４は、反応履歴蓄積部１８０３に蓄積されている反応履歴から、反応確率を計算し、反応確率テーブルを生成する（ステップＳ７９１６）。最大通知数計算部７４１９は、反応確率計算部が算出した反応確率テーブルから最大通知数テーブルを作成する（ステップＳ７９１７）。装置の動作を終了しない場合は、ステップＳ７９０１に戻る（ステップＳ７９１８でＮＯ）。終了する場合はフローを終了する（ステップＳ７９１８でＹＥＳ）。

なお、実施の形態１０、１１の通知判定処理のフローは、毎時もしくは一定時間ごとに繰り返し行っていた。しかし、毎時判定処理を行うと、電源の消費量が大きくなるという問題がある。単純に時刻や場所が変化した時やメールを受信したときに通知判定を処理を行ったのでは、不適切な処理を生じる場合がある。なぜなら、メールの場合、受信スケジュールに記述できないランダムな受信が多く、予定外のメールを受信することもある。また、受信スケジュール通りのメールが来ないこともある。そこで、時刻や場所が変化し、通知評価値が変化したときだけではなく、メールの受信時及び、メールを受信しなかったとしても受信スケジュールによるメールの受信予定時刻に通知判定処理のフローを行ってもよい。これにより、通知判定処理を毎時行わなくても良くなるため、電源の消費量を削減することができる。

また、実施の形態１０、１１の通知タイミングの処理はユーザの所持する端末が行っていた。しかし、サーバが通知判定処理を行っても良い。このとき、サーバが受信したメールを蓄積しておき、通知判定処理を行い、通知すべきであると判定したときに、ユーザに複数のメールを同時に配送する。端末は受け取った複数のメールを同時に通知する。

また、サーバが、現在時刻と、次のメールと同時に蓄積されたメールを全て通知できる通知時刻と、もしくは、全てのメールを同時に通知できる通知時刻における通知タイミングについて、実施の形態１０、１１と同様に比較処理を行った後、メールに通知タイミングを記述して即座に通知しても良い。端末は記述された通知タイミングでメールをユーザに通知する。記述される通知タイミングは、通知判定部が通知すると判定したときは、現在時刻である。通知判定部が通知しないと判定したときは、実施の形態１０では、次のメールと同時に蓄積されたメールを全て通知できる通知時刻とである。実施の形態１１では、全てのメールを同時に通知できる通知時刻である。これにより、万一、端末がサーバからのメールを受信できない電波状況の悪い状況になったとしても、ユーザにメールの受信タイミングを適切に制御できる。

また、実施の形態１１において、メールを通知するときは、受信時刻の古いメールから通知していた。しかし、差出人アドレスが一致するなど、同内容のメールはまとめて通知する方がユーザにとって都合が良い。よって、同内容のメールをまとめて通知出来るように、優先して通知しても良い。例えば、同内容のメールが存在する場合、同内容のメールの数が通知最大数を下回るときは、優先的に同内容のメール群を全て通知し、逆に上回るときは、同内容のメール群を通知せず、別のメール群のみを通知してもよい。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、現在受信しているメールの数が現在通知できる最大数のメール数を上回る場合に、現在受信している全てのメールについて、未来において受信するメールも含めて、全て同時に通知できるタイミングを現在時刻以降から算出し、現在通知できる最大数まで即時に通知したときに対する利点を算出することにより、通知できる最大数のメールを即座に通知するのか、それとも状況変化を待ち、全てのメールを通知できるタイミングで通知するのかの判断が行われてユーザに通知されるので、ユーザは、都合のよいタイミングで、複数の受信メールをまとめて閲覧することができる。

（実施の形態１２）
次に、本発明の実施の形態１２に係る情報通知装置を説明する。

実施の形態１０では、メールの受信スケジュールは絶対時刻によって指定されていた。しかし、特に携帯電話のメールの場合、ユーザのメールの送信に呼応して返信メールを受信する可能性が高い。よって、ユーザがメールを送信した後、別人からメールが来たとしても、送信先から返信メールが来ることがわかっていれば、その返信メールが来たときにメールを同時に通知することができる。これにより、短い時間間隔で何度もメールの通知を受けることを防ぐことが出来る。これを実現するためには、ユーザの送信メールに呼応したメールの受信スケジュールを作成し、ユーザの送信メールを監視することによるメールの受信予測が必要である。

図８６は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部１００、場所検知部１０１、反応検知部１０２、反応履歴蓄積部１０３、通知評価値計算部１１０、通知情報蓄積部６７０７、情報通知部６７０９、メール蓄積部６７１０、通知タイミング制御部８００８、呼応受信規則蓄積部８０１８および送信メール取得部８０１９を備える。なお、前記実施の形態１、５、１０で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図８６を用いて説明し、後に本装置の動作について説明する。

呼応受信規則蓄積部８０１８は、ユーザのメール送信に呼応したメールの受信スケジュールを蓄積する。一般的には送信したメールの返信メールである。図８７に示されるように、スケジュール識別のための「ＩＤ」、メールの発信元のメールアドレスを表す「差出人アドレス」、送信時刻から呼応したメールの受信時刻までの相対時間を表す「返信待ち時間」により構成されている。例えば、ＩＤ「００１」は差出人アドレス「ｆｒｉｅｎｄ１＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」にメールを送信したときに、「３」分後に返信メールを受信することを示している。この受信スケジュールに関しては予めユーザやメール配信者の手により、作成しておく。

通知タイミング制御部８００８は、時刻検知部１００で検知された現在時刻、場所検知部１０１で検知された現在場所と、呼応受信規則蓄積部８０１８に蓄積された呼応受信規則と送信メール取得部８０１９から取得した送信メール情報を用いて、通知情報蓄積部６７０７に蓄積された情報の通知タイミングと通知する情報の数を制御し、当該情報をメール蓄積部６７１０に出力し、情報通知部６７０９に情報の到着をユーザに知らせるようにする。このとき、通知情報蓄積部６７０７に蓄積された情報を削除する。通知タイミング制御部は、通知可能判定部６７１２、呼応メール取得部８０２０、次メール取得部８０１３、次通知時刻計算部６７１４、利点計算部６７１６、通知判定部６７１７から構成されている。以下、それぞれについて説明する。以下、それぞれについて説明する。

送信メール取得部８０１９は、メーラーの送信フォルダや、ユーザのメールサーバへの接続状況を監視することにより、ユーザが送信したメール情報を取得する。例えば、図８８に示されるように、メールの送信先の宛先アドレス「ｆｒｉｅｎｄ１＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」とメールの送信日時「１１：１５」などを取得する。

呼応メール取得部８０２０は、呼応受信規則蓄積部８０１８に蓄積された呼応メールの受信スケジュールと送信メール取得部８０１９から取得した送信メール情報から呼応したメールの受信日時を予測する。具体的には、送信メールの「宛先アドレス」と受信スケジュールの「差出人アドレス」が一致する受信スケジュールを呼応受信規則蓄積部８０１８から探索し、一致するアドレスがあれば、そのＩＤの「返信待ち時間」を、送信メールの送信日時に加えて、呼応メールの受信日時とする。例えば、図８９に示されるように、呼応受信規則蓄積部８０１８に受信スケジュールが蓄積され、送信メール取得部８０１９から宛先アドレス「ｆｒｉｅｎｄ１＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」、送信日時「１１：１５」のメールと宛先アドレス「ｆｒｉｅｎｄ２＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」、送信日時「１１：１６」のメールを取得したとする。

このとき、宛先アドレス「ｆｒｉｅｎｄ１＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」とアドレスが一致するスケジュールは、ＩＤ「００１」であり、返信待ち時間は「３分」である。よって、差出人アドレス「ｆｒｉｅｎｄ１＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」から「１１：１８」（１１：１５＋３分）にメールを受信すると予測する。また、宛先アドレス「ｆｒｉｅｎｄ２＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」とアドレスが一致するスケジュールは、ＩＤ「００２」であり、返信待ち時間は「１０分」である。よって、差出人アドレス「ｆｒｉｅｎｄ２＠ｋｅｉｔａｉｄｅｎｗａ．ｎｏ．ａｄｄｒｅｓｓ．ｊｐ」から「１１：２６」（１１：１６＋１０分）にもメールを受信すると予測する。

次メール取得部８０１３は、呼応メール取得部８０２０が予測した単数または複数の呼応メールの受信日時と時刻検知部１００が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻を取得する。具体的にはメールの受信時刻が、現在時刻以降であり、最も現在時刻の近傍にある呼応メールの受信日時を次メール受信時刻として取得する。

以下、本実施の形態１２のフローチャートを、図９０を用いて説明する。前記実施の形態１、１０で示した構成要素には同様の符号を付与し、説明を省略する。まず、通知可能判定部６７１２が、時刻検知部１００が検知した現在時刻と、場所検知部１０１が検知した現在場所から現在の通知可否を判定する（ステップＳ７３０１）。情報通知が不可能であった場合、ステップＳ７３０１に戻る（ステップＳ７３０２のＮｏ）。情報通知が可能であった場合、ステップＳ８４０１に進む（ステップＳ７３０２のＹｅｓ）。

情報通知が可能であった場合、送信メール取得部８０１９が、メーラーの送信フォルダ等からユーザが送信したメールの情報を取得する（ステップＳ８４０１）。呼応メール取得部８０２０は、呼応受信規則蓄積部８０１８に蓄積された呼応メールの受信スケジュールと送信メール取得部８０１９から取得した送信メール情報から呼応したメールの受信日時を予測する（ステップＳ８４０２）。次メール取得部８０１３は、時刻検知部１００が検知した現在時刻と呼応メール取得部８０２０が取得したメールの受信日時に従って、次メールの受信時刻を取得する（ステップＳ８４０３）。以下実施の形態１０と同様である。

なお、本実施の形態１２における呼応メールの受信スケジュールでは、差出人アドレスによって返信待ち時間が一意に決まっていた。しかし、送信から呼応メールの受信にまでにかかる返信待ち時間は状況により異なる場合がある。例えば、差出人が寝ている間に送ったメールと、起きている間に送ったメールとでは返信待ち時間は異なる。また、メールで会話をするように、相手のメールに返信を繰り返している状況では、返信待ち時間は通常より短くなる。よって、差出人アドレスだけではなく、時刻や件名によって、受信スケジュールの返信待ち時間を変更しても良い。例えば、時刻の範囲を「１２：００〜１３：００」と指定し、この間の返信待ち時間を例えば「５分」とする。「件名」の場合、相手のメールに対する返信を表す「Ｒｅ：」が、ユーザの送信メールの「件名」の冒頭に入っている場合は、返信待ち時間を例えば「３分」とするような受信スケジュールを作成する。

また、呼応メールの返信待ち時間に対してもばらつきが存在することが多い。よって実施の形態１０の変形例１と同様に、受信メールを監視し、受信したメールの件名や差出人アドレスの一致性により、呼応メールを受信したのか、呼応メール以外のメールを受信したのかを判断しても良い。例えば、ユーザが送信したメールと受信したメールの件名が冒頭の「Ｒｅ：」を除いて完全に一致したときは送信メールに対する呼応メールを受信したとする。

また、実施の形態１０、１１と同様に、絶対時間による受信スケジュールの受信予測を行っても良い。このとき、新たに受信したメールが呼応メールであるか、絶対時間により予測したメールであるのか、それとも予測されなかったメールであるのかを判断し、今後の受信スケジュールを修正する必要がある。これも実施の形態１０の変形例、実施の形態１２の変形例と同様に差出人アドレスや件名によってメールの種類を判断する。

また、本実施の形態１２では、呼応メールはユーザの送信メールに呼応して受信していた。しかし、ユーザの送信メール以外に呼応して受信するメールも存在する。例えば、一通メールを送信したあと、連続でメールを送信する人もいる。例えば、ユーザ宛に会議の連絡メールを送信したあと、そのユーザも所属しているメーリングリストに同じ内容のメールを送信する人もいる。また、メールを書くときは連続で書くことが多いため、メールを送信した後、また別の内容のメールをすぐに送信する人もいる。また、ユーザ自身がメーリングリストから受信されたメールに返信しなくても、メーリングリストの他の加入者が返信メールを呼応して送信することもある。よって、受信メールを監視し、規則と送信先アドレスや差出人アドレスが一致したときに呼応メールの受信を予測しても良い。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、ユーザがメールを送信した後、別人からメールが来たとしても、送信先からの返信メールが来たときにそのメールが同時に通知されるので、短い時間間隔で何度もメールの通知を受けるという煩わしさが回避される。

（実施の形態１３）
次に、本発明の実施の形態１３に係る情報通知装置を説明する。

実施の形態１０、１１、１２では、メールの受信スケジュールは予め人の手で作成していた。しかし、端末が受信メールと送信メールの履歴から自動的に作成しても良い。

受信メールの中には、実施の形態１０、１１のように絶対時間によるスケジュールにより受信すると考えられるメール、実施の形態１２のように、送信メール、もしくは、別の受信メールに呼応して相対時間によるスケジュールにより受信すると考えられるメール、また、それら以外の無規則で受信しているメールの３種類のメールが存在する。よって、予めそれらを分類し、それぞれについてスケジュールを作成する必要がある。

例えば、受信したメールが「Ｉｎ−ｒｅｐｌｙ−ｔｏ」ヘッダや件名の冒頭に「Ｒｅ：」がついている場合は呼応受信スケジュールに対応したメールに分類する。メーリングリストからのメールでｆｒｏｍ欄の差出人アドレスが一つに固定されていたら絶対時間による受信スケジュールに対応したメールに分類する。逆にｆｒｏｍ欄の差出人アドレスは複数ある場合は、複数人で議論できるようなメーリングリストと想定されるため、呼応受信スケジュールに対応したメールに分類するといったことが考えられる。分類した後は、履歴を探索し、高頻度に受信する可能性がある時刻をスケジュールの受信時刻とすればよい。

以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。

さらに、本実施の形態では、メールの受信スケジュールについては、端末が受信メールと送信メールの履歴から自動的に作成されるので、ユーザは、受信スケジュールを作成する煩わしい作業から解放される。

以上、本発明に係る情報通知装置について、実施の形態１〜１３に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではない。実施の形態１〜１３における構成要素を任意に組み合わせて実現される実施の形態や、各実施の形態に対して当業者が思いつく各種変更を施すことによって実現される実施の形態も本発明に含まれる。

たとえば、実施の形態１〜１０、１２〜１３における通知タイミング制御部に代えて実施の形態１１の通知タイミング制御部７４０８を用いてもよい。これにより、いずれの実施の形態のおいても、通知評価値と未来メールの受信時刻とを用いて通知タイミングを決定する情報通知装置が実現され、広い範囲で適切な通知タイミングが探索される。

本発明に係わる情報通知装置は、情報端末に対するユーザのインタラクション履歴により、適切なタイミングで情報を通知することが可能になり、例えば、携帯電話やＰＤＡ等の情報を提供する装置において有用である。

本発明の実施の形態１における情報通知装置の構成を示すブロック図である。 反応履歴蓄積部に蓄積された反応履歴の例を示す図である。 反応確率計算部による、反応確率テーブルを作成する例を示す図である。 反応確率修正部が修正規則蓄積部による反応確率テーブルを修正する例を示す図である。 反応確率修正部が修正規則蓄積部に蓄積された汎化条件利用規則により反応確率計算部が作成した反応確率テーブルを修正する例を示す図である。 通知情報蓄積部に蓄積された情報の例を示す図である。 通知タイミング制御部が現在の状況から通知情報蓄積部に蓄積された情報の通知の可否を判断し、情報を出力する例を示す図である。 情報通知部が携帯電話であった場合に、情報を通知する例を示す図である。 本発明の実施の形態１における情報通知装置の反応確率テーブル更新手順を示すフローチャートである。 本発明の実施の形態１における情報通知装置の情報通知手順を示すフローチャートである。 通知評価値により評価値テーブルを作成した本発明の実施の形態１の変形例における情報通知装置の構成を示すブロック図である。 通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。 通知評価値修正部が修正規則蓄積部による通知評価値テーブルを修正する例を示す図である。 通知タイミング制御部が通知評価値テーブルから通知情報蓄積部に蓄積された情報の通知の可否を判断する例を示す図である。 曜日情報を追加した本発明の実施の形態１の変形例２における通知情報蓄積部に蓄積された情報の例を示す図である。 曜日情報を追加した本発明の実施の形態１の変形例２における通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。 通知開始イベント情報を追加した本発明の実施の形態１の変形例３における通知情報蓄積部に蓄積された情報の例を示す図である。 通知開始イベント情報を追加した本発明の実施の形態１の変形例３における通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。 通知評価値修正部が修正規則蓄積部に蓄積された複数汎化条件利用規則により評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。 条件発生確率テーブルを作成する装置の構成を示すブロック図である。 行動履歴蓄積部に蓄積された行動履歴の例を示す図である。 行動履歴蓄積部に蓄積された行動履歴から条件発生確率計算部が条件発生確率テーブルを作成する例を示す図である。 条件発生確率テーブルによる修正規則の選択を行う本発明の実施の形態２における情報通知装置の構成を示すブロック図である。 通知評価値修正部が条件発生確率テーブルと修正規則蓄積部に蓄積された汎化条件選択規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。 簡易的に条件発生確率テーブルを作成する例を示すブロック図である。 本発明の実施の形態３において、通知評価値修正部が修正規則蓄積部に蓄積された近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。 近傍汎化規則の使用に用いる近傍データベースの例を示す例を示す図である。 通知評価値修正部が近傍データベースと近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。 近傍データベースを作成し、近傍汎化規則によって修正した通知評価値により情報通知のタイミングを制御する本発明の実施の形態３のブロック図である。 行動履歴蓄積部に蓄積された行動履歴の例を示す図である。 行動履歴蓄積部に蓄積された行動履歴から他要素発生確率計算部が条件発生確率テーブルを作成する例を示す図である。 他要素発生確率計算部によって作成された他要素発生確率テーブルから近傍データベースが近傍データベースを作成する例を示す図である。 評価値修正部が近傍データベースと近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。 周辺音を用いて近傍データベースを作成し、近傍汎化規則によって修正した通知評価値により情報通知のタイミングを制御する本発明の実施の形態３の変形例におけるブロック図である。 周辺音を追加した行動履歴蓄積部に蓄積された行動履歴の例を示す図である。 連続通知検知部を追加した本発明の実施の形態５における情報通知装置の構成を示すブロック図である。 本発明の実施の形態５における通知タイミング制御部による連続通知数制御の例を示す図である。 連続通知数を履歴として蓄積した本発明の実施の形態５における情報通知装置の構成を示すブロック図である。 連続通知数を履歴として蓄積した本発明の実施の形態５における履歴蓄積部に蓄積された反応履歴の例を示す図である。 未来における状況も考慮して通知を行う実施の形態６における通知タイミング制御部の構成を示すブロック図である。 実施の形態６における通知タイミング制御部の動作の例を示す図である。 行動予測部により、未来における状況も考慮して通知を行う実施の形態６における情報通知装置の構成を示すブロック図である。 行動予測部を備えた実施の形態６における通知タイミング制御部の動作の例を示す図である。 通知確率変換部を追加した実施の形態７における情報通知装置の構成を示すブロック図である。 実施の形態７における通知確率変換部が反応確率テーブルから通知確率テーブルを作成する例を示すブロック図である。 実施の形態８における情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のフローの例を示すフローチャートである。 実施の形態２における情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。 実施の形態８における情報通知装置の構成を示すブロック図である。 実施の形態８における履歴蓄積部に蓄積された反応履歴の例を示す図である。 実施の形態８における内容評価値計算部が履歴蓄積部に蓄積された反応履歴から、内容評価値テーブルを作成する例を示す図である。 実施の形態８における通知タイミング制御部が現在の状況と内容評価値テーブルから情報の通知の可否を判断し、情報を出力する例を示す図である。 本発明の実施の形態８における情報通知装置の評価値テーブル更新手順を示すフローチャートである。 本発明の実施の形態８における情報通知装置の情報通知手順を示すフローチャートである。 実施の形態１のように評価値修正部を追加した実施の形態８における情報通知装置の構成を示すブロック図である。 内容評価値修正部が修正規則蓄積部に蓄積された汎化条件利用規則により内容評価値計算部が作成した内容評価値テーブルを修正する例を示す図である。 ユーザが内容の良否を入力するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。 ユーザが内容の良否を入力するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のフローの例を示すフローチャートである。 ユーザが情報ヘッダを表示指示するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。 学習を効率的に行うための通知タイミングを考慮した実施の形態９における情報通知装置の構成を示すブロック図である。 学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された履歴数依存規則により学習有効値テーブルを作成する例を示す図である。 学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された汎化条件履歴数依存規則により学習有効値テーブルを作成する例を示す図である。 本発明の実施の形態９における情報通知装置の学習有効値テーブル更新手順を示すフローチャートである。 本発明の実施の形態９における情報通知装置の情報通知手順を示すフローチャートである。 学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された特化規則により学習有効値テーブルを作成する例を示す図である。 学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された条件発生確率依存規則により学習有効値テーブルを作成する例を示す図である。 学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された要因推定規則により学習有効値テーブルを作成する例を示す図である。 本発明の実施の形態１０における情報通知装置の構成を示すブロック図である。 本発明の実施の形態１０における通知タイミング制御部の構成を示すブロック図である。 通知情報蓄積部に蓄積された情報の例を示す図である。 受信規則蓄積部に蓄積されたメールの受信スケジュールの例を示す図である。 次通知時刻算出部が次通知可能時刻を算出する例を示す図である。 利点計算部が利点を算出する例を示す図である。 本発明の実施の形態１０における情報通知装置の動作手順を示すフローチャートである。 次通知時刻算出部が次通知可能時刻を算出する例を示す図である。 メールの受信状況を予測することにより、受信スケジュールを補正する例を示す図である。 実施の形態１０の変形例における情報通知装置の通知タイミング制御部の構成を示すブロック図である。 関連性判定部が関連性を判定する例を示す図である。 利点計算部が利点を算出する例を示す図である。 実施の形態１０の変形例における情報通知装置の動作手順を示すフローチャートである。 本発明の実施の形態１１における情報通知装置の構成を示すブロック図である。 本発明の実施の形態１１における通知タイミング制御部の構成を示すブロック図である。 最大通知数計算部が最大通知数テーブルを作成する例を示す図である。 全通知時刻算出部が全通知可能時刻を算出する例を示す図である。 利点計算部が利点を算出する例を示す図である。 本発明の実施の形態１１における情報通知装置の動作手順を示すフローチャートである。 本発明の実施の形態１２における情報通知装置の構成を示すブロック図である。 呼応受信規則蓄積部に蓄積されたメールの受信スケジュールの例を示す図である。 送信メール取得部が取得する送信メールの例を示す図である。 呼応メール取得部が呼応メールを取得する例を示す図である。 本発明の実施の形態１２における情報通知装置の動作手順を示すフローチャートである。

符号の説明

１００、６５００ 時刻検知部
１０１ 場所検知部
１０２、３２０２、７４０２ 反応検知部
１０３、１８０３、３２０３ 反応履歴蓄積部
１０４、１８０４、３２０４ 反応確率計算部
１０５ 修正規則蓄積部
１０６、１８０６ 反応確率修正部
１０７、６７０７ 通知情報蓄積部
１０８、１５０８、１６０８、２００１、２２０８、２８０８、３２０８、４６０７、６７０８、７４０８、８００８、８８０８ 通知タイミング制御部
１０９、６７０９ 情報通知部
１１０ 通知評価値計算部
１１１、６００１、６００６ 通知評価値修正部
１５０４ 反応度計算部
１５０６ 反応度修正部
２４０３、６５０３、７００３ 行動履歴蓄積部
２４０４ 条件発生確率計算部
６５０１ 他要素検知部
６５０２、７００２ 他要素発生確率計算部
６５０４ 近傍データベース生成部
６５０５ 近傍データベース
６５０６ 近傍汎化規則
６５０７ 平休日検知部
７００７ 周辺音検知部
１６１０、１８１０ 連続通知検知部
２００５ 場所範囲決定部
２００６ 時刻範囲決定部
２００７ 通知可否判定部
２２１０ 行動予測部
２８１０ 通知確率変換部
３２０５ 内容評価値計算部
３７１１ 内容評価値修正部
４６０４ 学習有効値計算部
４６０５ 学習有効値計算規則蓄積部
６７１０ メール蓄積部
６７１１ 受信規則蓄積部
６７１２ 通知可能判定部
６７１３、８０１３、８８１３ 次メール取得部
６７１４ 次通知時刻計算部
６７１６、７４１６、８８１６ 利点計算部
６７１７、７４１７ 通知判定部
７４１２ 全通知可能判定部
７４１３ 未来メール取得部
７４１４ 全通知時刻計算部
７４１９ 最大通知数計算部
８０１８ 呼応受信規則蓄積部
８０１９ 送信メール取得部
８０２０ 呼応メール予測部
８８２１ 関連性判定部

Claims (7)

1. 受信した電子メールをユーザに通知する情報通知装置であって、
   時刻を検知する時刻検知手段と、
   前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、
   前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、
   前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、
   前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、
   前記ユーザが送信したメールである送信メール情報を取得する送信メール取得手段と、
   前記送信メール情報から、前記送信メールに対する返信メールの受信時刻を算出するための規則である呼応受信規則を蓄積する呼応受信規則蓄積手段と、
   前記送信メール情報と前記呼応受信規則から、現在の時刻以降に外部ネットワーク媒体から受信するであろう返信メールの受信時刻を決定する呼応メール取得手段と、
   前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記呼応メール取得手段で決定した前記返信メールの受信時刻とを用いて決定する通知タイミング制御手段と、
   前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段と
   を備えることを特徴とする情報通知装置。
2. 前記送信メール情報には、宛先アドレスと送信時刻が含まれ、
   前記呼応受信規則には、差出人アドレスと、前記送信メールの送信時刻から返信メールの受信時刻までの時間を示す返信待ち時間が含まれ、
   前記呼応メール取得手段は、前記送信メール情報に含まれる宛先アドレスに一致する前記差出人アドレスを持つ呼応受信規則に含まれる返信待ち時間を、前記送信メール情報に含まれる送信時刻に加えることで、前記返信メールの受信時刻を決定する
   ことを特徴とする請求項１記載の情報通知装置。
3. 前記情報通知手段は、さらに、前記返信メールの内容と、前記通知情報蓄積手段に蓄積されているメールの内容の関連性の有無を判定する関連性判定手段を備え、
   前記通知タイミング制御手段は、前記関連性判定手段が、関連性が有ると判定したときは、前記返信メールを受信する以降の時刻において、前記通知情報蓄積手段に蓄積されているメールと前記返信メールを同時に通知する
   ことを特徴とする請求項１記載の情報通知装置。
4. 前記関連性判定手段は、前記返信メールの差出人アドレスが、前記通知情報蓄積手段に蓄積されているいずれかのメールの差出人アドレスと一致するときに、関連性が有ると判定する
   ことを特徴とする請求項３記載の情報通知装置。
5. 前記関連性判定手段は、前記返信メールのＲｅｐｌａｙ−ｔｏアドレスが、前記通知情報蓄積手段に蓄積されているいずれかのメールのＲｅｐｌａｙ−ｔｏアドレスと一致するときに、関連性が有ると判定する
   ことを特徴とする請求項３記載の情報通知装置。
6. 受信した電子メールをユーザに通知する情報通知装置による情報通知方法であって、
   前記情報通知装置が、時刻を検知する時刻検知ステップと、
   前記情報通知装置が、前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知ステップと、
   前記情報通知装置が、前記メールの通知を行ったときの前記時刻検知ステップで検知された時刻および前記反応検知ステップで検知された前記ユーザの反応を反応履歴として第１蓄積手段に蓄積する反応履歴蓄積ステップと、
   前記情報通知装置が、前記第１蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算ステップと、
   前記情報通知装置が、前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを第２蓄積手段に複数蓄積する通知情報蓄積ステップと、
   前記情報通知装置が、前記ユーザが送信したメールである送信メール情報を取得する送信メール取得ステップと、
   前記情報通知装置が、前記送信メール情報から、前記送信メールに対する返信メールの受信時刻を算出するための規則である呼応受信規則を蓄積する第３蓄積手段を参照することで、前記送信メール情報と前記呼応受信規則から、現在の時刻以降に外部ネットワーク媒体から受信するであろう返信メールの受信時刻を決定する呼応メール取得ステップと、
   前記情報通知装置が、前記時刻検知ステップで検知された時刻に応じて、前記第２蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算ステップで計算された前記通知評価値と前記呼応メール取得ステップで決定した前記返信メールの受信時刻とを用いて決定する通知タイミング制御ステップと、
   前記通知タイミング制御ステップにおいて、前記第２蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記情報通知装置が、前記所定の時刻において、前記第２蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知ステップと
   を含むことを特徴とする情報通知方法。
7. ユーザに対して電子メールの通知を行う情報通知装置のためのプログラムであって、
   請求項６記載の情報通知方法に含まれるステップをコンピュータに実行させる
   ことを特徴とするプログラム。

Images