(57)【要約】【課題】  ユーザの置かれた状態をユーザの手動入力に頼ることなく、自動的に推測して表示する。【解決手段】  携帯電話などの機器の利用パターンや機器に搭載されたセンサから取得される情報から、その機器を利用または保持するユーザの置かれた状態を推測し、プレゼンス情報として発行する。状態演算部は、機器の利用パターンや機器に搭載されたセンサが取得した情報を受け取ると、演算ルール保存部に保存された演算ルールに基づき、ユーザのプレゼンス情報を演算し、この結果をプレゼンス情報として発行する。【選択図】  図１
2005275890.tif 000002
【特許請求の範囲】
【請求項１】
入力情報を構成する各種パラメータを抽出する手段と、
この抽出する手段により抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、
前記推測する手段により前回推測された状態を保持する手段と、
この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段と
を備えたことを特徴とするプレゼンス情報発行装置。
【請求項２】
前記推測する手段の推測演算ルールを保持する手段を備えた請求項１記載のプレゼンス情報発行装置。
【請求項３】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、
この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段と
を備えた請求項１または２記載のプレゼンス情報発行装置。
【請求項４】
前記入力情報は操作入力情報であり、当該操作入力情報の最終入力時刻を保持する手段と、
この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段と
を備えた請求項１または２記載のプレゼンス情報発行装置。
【請求項５】
入力情報を構成する各種パラメータを抽出する手段と、
この抽出する手段により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする手段と
を備えたユーザ装置と、
前記フィルタリングする手段によりフィルタリングされた前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、
前記推測する手段により前回推測された状態を保持する手段と、
この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段と
を備えたプレゼンスサーバと
を備えたことを特徴とするプレゼンス情報発行システム。
【請求項６】
前記フィルタリングする手段が用いるフィルタリング規則を保持する手段と、
前記推測する手段の推測演算ルールを保持する手段と
を備えた請求項５記載のプレゼント情報発行システム。
【請求項７】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、
この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段と
を備えた請求項５または６記載のプレゼンス情報発行システム。
【請求項８】
前記ユーザ装置に対するユーザの最終操作入力時刻を保持する手段と、
この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段と
を備えた請求項５または６記載のプレゼンス情報発行システム。
【請求項９】
入力情報を構成する各種パラメータを抽出する手段と、
この抽出する手段により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする手段と
を備えたことを特徴とするユーザ装置。
【請求項１０】
前記フィルタリングする手段が用いるフィルタリング規則を保持する手段を備えた請求項９記載のユーザ装置。
【請求項１１】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、
この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段と
を備えた請求項９または１０記載のユーザ装置。
【請求項１２】
自装置に対するユーザの最終操作入力時刻を保持する手段と、
この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段と
を備えた請求項９または１０記載のユーザ装置。
【請求項１３】
入力情報から抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、
前記推測する手段により前回推測された状態を保持する手段と、
この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段と
を備えたことを特徴とするプレゼンスサーバ。
【請求項１４】
前記推測する手段の推測演算ルールを保持する手段を備えた請求項１３記載のプレゼンスサーバ。
【請求項１５】
情報処理装置にインストールすることにより、その情報処理装置に、
入力情報を構成する各種パラメータを抽出する機能と、
この抽出する機能により抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する機能と、
前記推測する機能により前回推測された状態を保持する機能と、
この保持する機能に保持されている前回推測された状態と前記推測する機能により今回推測された状態とを比較して異なる場合には前記推測する機能により今回推測された状態を状態情報として出力する機能と
を備えたプレゼンス情報発行装置に相応する機能を実現させることを特徴とするプログラム。
【請求項１６】
前記推測する機能の推測演算ルールを保持する機能を実現させる請求項１５記載のプログラム。
【請求項１７】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する機能と、
この保持する機能に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する機能と
を実現させる請求項１５または１６記載のプログラム。
【請求項１８】
自装置に対するユーザの最終操作入力時刻を保持する機能と、
この保持する機能に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する機能と
を実現させる請求項１５または１６記載のプログラム。
【請求項１９】
情報処理装置にインストールすることにより、その情報処理装置に、
入力情報を構成する各種パラメータを抽出する機能と、
この抽出する機能により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする機能と
を備えたユーザ装置に相応する機能を実現させることを特徴とするプログラム。
【請求項２０】
前記フィルタリングする機能が用いるフィルタリング規則を保持する機能を実現させる請求項１９記載のプログラム。
【請求項２１】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する機能と、
この保持する機能に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する機能と
を実現させる請求項１９または２０記載のプログラム。
【請求項２２】
自装置に対するユーザの最終操作入力時刻を保持する機能と、
この保持する機能に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する機能と
を実現させる請求項１９または２０記載のプログラム。
【請求項２３】
情報処理装置にインストールすることにより、その情報処理装置に、
入力情報から抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する機能と、
前記推測する機能により前回推測された状態を保持する機能と、
この保持する機能に保持されている前回推測された状態と前記推測する機能により今回推測された状態とを比較して異なる場合には前記推測する機能により今回推測された状態を状態情報として出力する機能と
を備えたプレゼンスサーバに相応する機能を実現させることを特徴とするプログラム。
【請求項２４】
前記推測する機能の推測演算ルールを保持する機能を実現させる請求項２３記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、入力情報の発信元であるユーザの置かれている状態を推測して記録または表示する装置に利用する。特に、音声情報に基づく状態解析に関する。
【背景技術】
【０００２】
プレゼンスシステムとは、人、もの、サービスなどの状態を管理するシステム一般を指し、その基本的なアーキテクチャは、ＲＦＣ２７７８に示されている。プレゼンスシステムは、自分のプレゼンス情報を提供するプレゼンス情報管理手段と、それを観察するウォッチャ、および、プレゼンス情報管理手段からプレゼンス情報を受け取り、これをウォッチャに配信するプレゼンスサービスとからなる。本発明の説明で触れているプレゼンス情報管理ユーザエージェントは、具体的にプレゼンス情報管理手段の機能を提供するプログラムなどである。
従来のプレゼンスサービスにおいては、クライアントとプレゼンスサービスとのコネクションから想定される、オンライン、オフラインといった通信状態以外のプレゼンス値に関しては、ユーザが手動で設定していた。このため、ユーザが状態を変更するのを忘れるなど、ユーザが提供するプレゼンス情報の信頼性が低かった（例えば、特許文献１参照）。
【特許文献１】特開２００３−１６７９００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のプレゼンス情報管理ユーザエージェントを使って、ユーザの状況をプレゼンス情報として通知する場合は、あらかじめ用意された状態記述リストから適当な候補を選び、プレゼンス情報を更新して通知することになる。
【０００４】
この方法は、適当な状況記述をユーザが判断するため、状況記述の種類を増やした場合に、ユーザでは対処ができなくなるという問題がある。ユーザが任意の状況記述を作成することも可能であるが、その場合も入力作業自体に手間がかかっていた。
【０００５】
マイクロソフト株式会社の“Ｗｉｎｄｏｗｓ  Ｍｅｓｓｅｎｇｅｒ”やヤフー株式会社の“Ｙａｈｏｏ！メッセンジャー”などの既存のプレゼンス情報管理ユーザエージェントは、プレゼンス情報の更新のためにキーボードやマウスなどの入力装置を操作しなければならない。しかし、ユーザの状況の変化には、本人の気づかない内に起こるものがある。ユーザがプレゼンス情報を更新することを忘れたために、プレゼンス情報の信頼性が低下するという問題があった。
【０００６】
さらに、人の操作によって動作するプレゼンス情報管理ユーザエージェントは、操作する本人が会話に忙しい場合に、適切なタイミングでプレゼンス情報を通知できないという問題があった。
【０００７】
従来のプレゼンス情報管理ユーザエージェントでも、機器が使用中であることをプログラムが検出して、ユーザが機器を使用していることを表すプレゼンス情報を発行することはできた。しかし、電話に応答できない、メールを読んでいない、コミュニケーションを要求しているなどの、ユーザが置かれている具体的な状況を表すプレゼンス情報をプログラムが自動的に通知する仕組みは提案されていなかった。
【０００８】
本発明は、このような背景に行われたものであって、ユーザの置かれた状態をユーザの手動入力に頼ることなく、自動的に推測して記録または表示することができるプレゼンス情報発行装置およびシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、携帯電話などの機器の利用パターンや機器に搭載されたセンサから取得される情報から、その機器を利用または保持するユーザの置かれた状態を推測し、プレゼンス情報として発行するシステムである。
【００１０】
本発明の状態演算部は、機器の利用パターンや機器に搭載されたセンサが取得した情報を受け取ると、例えば、演算ルール保存部に保存された演算ルールに基づき、ユーザのプレゼンス情報を演算し、この結果をプレゼンス情報として発行する。
【００１１】
すなわち、本発明の第一の観点は、入力情報を構成する各種パラメータを抽出する手段と、この抽出する手段により抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、前記推測する手段により前回推測された状態を保持する手段と、この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段とを備えたことを特徴とするプレゼンス情報発行装置である。前記推測する手段の推測演算ルールを保持する手段を備えることができる。
【００１２】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段とを備えることができる。
【００１３】
これによれば、ユーザに対して会話を促すことにより、ユーザの置かれた状態を把握するための情報を積極的に取得することができる。
【００１４】
あるいは、前記入力情報は操作入力情報であり、当該操作入力情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。
【００１５】
これによれば、ユーザからの操作入力がしばらく無い場合に、ユーザに対して操作入力を促すことができ、ユーザの置かれた状態を把握するための情報を積極的に取得することができる。
【００１６】
本発明の第二の観点は、入力情報を構成する各種パラメータを抽出する手段と、この抽出する手段により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする手段とを備えたユーザ装置と、前記フィルタリングする手段によりフィルタリングされた前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、前記推測する手段により前回推測された状態を保持する手段と、この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段とを備えたプレゼンスサーバとを備えたことを特徴とするプレゼンス情報発行システムである。
【００１７】
前記フィルタリングする手段が用いるフィルタリング規則を保持する手段と、この推測する手段の推測演算ルールを保持する手段とを備えることができる。
【００１８】
これによれば、ユーザ装置とプレゼンスサーバとを別装置として備えることができる。例えば、ユーザ装置は、ユーザが所持する携帯電話である。プレゼンスサーバは、携帯電話サービス業者の設備に設けることができる。
【００１９】
ユーザ装置には、フィルタリングする手段を備え、ユーザが外部に知られたくないプライベートな情報についてはその流出を規制することができる。どのような情報をフィルタリングするかは、ユーザがフィルタリング規則を設定できるようにする。
【００２０】
この場合も、前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段とを備えることができる。
【００２１】
あるいは、前記ユーザ装置に対するユーザの最終操作入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。
【００２２】
本発明の第三の観点は、入力情報を構成する各種パラメータを抽出する手段と、この抽出する手段により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする手段とを備えたことを特徴とするユーザ装置である。前記フィルタリングする手段が用いるフィルタリング規則を保持する手段を備えることができる。
【００２３】
このときに、前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段とを備えることができる。
【００２４】
あるいは、自装置に対するユーザの最終操作入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。
【００２５】
本発明の第四の観点は、入力情報から抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する手段と、前記推測する手段により前回推測された状態を保持する手段と、この保持する手段に保持されている前回推測された状態と前記推測する手段により今回推測された状態とを比較して異なる場合には前記推測する手段により今回推測された状態を状態情報として出力する手段とを備えたことを特徴とするプレゼンスサーバである。前記推測する手段の推測演算ルールを保持する手段を備えることができる。
【００２６】
本発明の第五の観点は、情報処理装置にインストールすることにより、その情報処理装置に、入力情報を構成する各種パラメータを抽出する機能と、この抽出する機能により抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する機能と、前記推測する機能により前回推測された状態を保持する機能と、この保持する機能に保持されている前回推測された状態と前記推測する機能により今回推測された状態とを比較して異なる場合には前記推測する機能により今回推測された状態を状態情報として出力する機能とを備えたプレゼンス情報発行装置に相応する機能を実現させることを特徴とするプログラムである。前記推測する機能の推測演算ルールを保持する機能を実現することができる。
【００２７】
また、前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する機能と、この保持する機能に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する機能とを実現させることができる。
【００２８】
あるいは、自装置に対するユーザの最終操作入力時刻を保持する機能と、この保持する機能に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する機能とを実現させることができる。
【００２９】
あるいは、本発明のプログラムは、情報処理装置にインストールすることにより、その情報処理装置に、入力情報を構成する各種パラメータを抽出する機能と、この抽出する機能により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする機能とを備えたユーザ装置に相応する機能を実現させることを特徴とするプログラムである。前記フィルタリングする機能が用いるフィルタリング規則を保持する機能を実現することができる。
【００３０】
前記入力情報は音声情報であり、当該音声情報の最終入力時刻を保持する機能と、この保持する機能に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する機能とを実現させることができる。
【００３１】
あるいは、自装置に対するユーザの最終操作入力時刻を保持する機能と、この保持する機能に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する機能とを実現させることができる。
【００３２】
また、本発明のプログラムは、情報処理装置にインストールすることにより、その情報処理装置に、入力情報から抽出された前記各種パラメータに基づき前記入力情報の発信元の置かれた状態を推測する機能と、前記推測する機能により前回推測された状態を保持する機能と、この保持する機能に保持されている前回推測された状態と前記推測する機能により今回推測された状態とを比較して異なる場合には前記推測する機能により今回推測された状態を状態情報として出力する機能とを備えたプレゼンスサーバに相応する機能を実現させることを特徴とするプログラムである。前記推測する機能の推測演算ルールを保持する機能を実現させることができる。
【００３３】
本発明のプログラムは記録媒体に記録されることにより、前記情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記情報処理装置に本発明のプログラムをインストールすることもできる。
【００３４】
これにより、汎用の情報処理装置を用いて、ユーザの置かれた状態をユーザの手動入力に頼ることなく、自動的に推測して表示することができるプレゼンス情報発行装置およびシステムを実現することができる。
【発明の効果】
【００３５】
従来のプレゼンス情報管理ユーザエージェントは、人の感情、気分、ストレスの度合いなどの変化を、プレゼンス情報として自動的にウォッチャに通知することができなかった。本発明はこの問題を解決する。
【００３６】
本発明の第一の効果は、人が適当な状態記述の候補を選択する、あるいは、人が任意の状態記述を作成することが不要になることにある。状態演算部が、例えば、演算ルール保存部に保存された演算ルールに従って、会話パラメータから状態記述を導出する。以上の処理はプログラムが実行するため、人が状態記述候補をメニューから選択する負担や、状態記述そのものを作成する負担を取り除くことができる。また、処理にかかる時間もユーザが行う場合に比べて短い。
【００３７】
第二の効果は、本人が気づかないような状態の変化であっても、手入力と比較して確実に、プレゼンス情報として通知できることにある。会話パラメータ抽出部が、人の会話に関する各種のパラメータを自動的に収集することが可能なためである。
【００３８】
第三の効果は、本人が会話で忙しい場合でもプレゼンスサービスに本人の状態を通知できることにある。本発明によるプレゼンス情報管理ユーザエージェントが携帯電話に内蔵されていれば、携帯電話で会話をしているだけで、会話パラメータ抽出部が会話に関するパラメータを抽出することができるためである。
【００３９】
第四の効果は、単に機器にオンラインや使用中であることを表すプレゼンス情報を自動的に発行するだけでなく、ユーザの置かれた具体的な状況を示すプレゼンス情報も自動的に発行できることにある。
【発明を実施するための最良の形態】
【００４０】
第一実施例のプレゼンス情報発行装置であるプレゼンス発行モジュールを図１を参照して説明する。図１は第一実施例のプレゼンス発行モジュール２０のブロック構成図である。
【００４１】
第一実施例のプレゼンス発行モジュール２０は、図１に示すように、入力情報である音声情報を構成する各種パラメータを抽出する会話パラメータ抽出部１と、この会話パラメータ抽出部１により抽出された前記各種パラメータに基づき前記音声情報の発信元であるユーザの置かれた状態を推測する状態演算部２と、この状態演算部２の推測演算ルールを保持する演算ルール保存部３と、状態演算部２により前回推測された状態を保持するプレゼンス情報保存部４と、このプレゼンス情報保存部４に保持されている前回推測された状態と状態演算部２により今回推測された状態とを比較して異なる場合には状態演算部２により今回推測された状態を状態情報として出力するプレゼンス情報発行部５とを備えたことを特徴とする。
【００４２】
第二実施例のプレゼンス発行モジュール２１を図５に示す。さらに、第二実施例では、図５に示すように、発話部７を備える。この発話部７は、入力情報である音声情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終入力時刻から所定時間経過してもなお新たな音声情報の入力がないときには、所定のメッセージを音声信号として送出する手段とを備える。
【００４３】
あるいは、入力情報である操作入力情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備える。これらの保持する手段および実行する手段は、図５に示す発話部７に備えることができる。この場合には、発話部７には、ユーザの音声情報と共に操作入力情報が入力される。
【００４４】
ここで、操作入力情報とは、プレゼンス発行モジュール２１が組み込まれた携帯電話やＰＤＡなどのユーザ装置における操作入力情報である。なお、図５における操作入力情報の入力の図示は省略した。
【００４５】
第三実施例のプレゼンス情報発行システムを図７に示す。第三実施例のプレゼンス情報発行システムは、図７に示すように、入力情報である音声情報を構成する各種パラメータを抽出する会話パラメータ抽出部１と、この会話パラメータ抽出部１により抽出された前記各種パラメータの内から所定のパラメータをフィルタリングする会話パラメータ送信部９と、この会話パラメータ送信部９が用いるフィルタリング規則を保持するポリシ管理部８とを備えたユーザ装置としての携帯電話３０と、会話パラメータ送信部９によりフィルタリングされた前記各種パラメータを会話パラメータ受信部１０を介して受信し、この各種パラメータに基づき前記音声情報の発信元の置かれた状態を推測する状態演算部２と、この状態演算部２の推測演算ルールを保持する演算ルール保存部３と、状態演算部２により前回推測された状態を保持するプレゼンス情報保存部４と、このプレゼンス情報保存部４に保持されている前回推測された状態と状態演算部２により今回推測された状態とを比較して異なる場合には状態演算部２により今回推測された状態を状態情報として出力するプレゼンス情報発行部５とを備えたプレゼンスサーバ３１とを備えたことを特徴とする。図９に示すように、第三実施例でも、第二実施例と同様に、発話部７を携帯電話３０に設けることができる（第四実施例）。
【００４６】
さらに、携帯電話３０に対するユーザの最終操作入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。これらの保持する手段および実行する手段は、図９に示す発話部７に備えることができる。この場合には、発話部７には、ユーザの音声情報と共に操作入力情報が入力される。なお、操作入力情報の入力の図示は省略した。
【００４７】
本実施例は、汎用の情報処理装置にインストールすることにより、その情報処理装置に第一および第二実施例のプレゼンス発行モジュール２０、２１あるいは第三および第四実施例の携帯電話３０およびプレゼンスサーバ３１に相応する機能を実現させるプログラムとして実現することができる。このプログラムは、記録媒体に記録されて情報処理装置にインストールされ、あるいは通信回線を介して情報処理装置にインストールされることにより当該情報処理装置に、会話パラメータ抽出部１、状態演算部２、演算ルール保存部３、プレゼンス情報保存部４、プレゼンス情報発行部５、発話部７、ポリシ管理部８、会話パラメータ送信部９、会話パラメータ受信部１０にそれぞれ相応する機能を実現させることができる。
【００４８】
以下では、本発明実施例をさらに詳細に説明する。
【００４９】
状態演算部２は、機器の利用パターンや機器に搭載されたセンサが取得した情報を受け取ると、演算ルール保存部３に保存された演算ルールに基づき、ユーザのプレゼンス情報を演算し、この結果をプレゼンス情報発行部５は、プレゼンス情報として発行する。
【００５０】
演算ルールとしては、
（１）携帯電話などの機器が、ユーザにアクションを促す操作に対するユーザの反応時間に応じて、ユーザが対応できない状態である（取り込み中や不在）ことを推測するもの
（２）携帯電話などの機器を、ユーザが利用する頻度に応じて、ユーザの状況を推測するもの
（３）携帯電話などの機器に搭載される機能の、いずれの機能をユーザが利用するかによって、ユーザの状況を推測するもの、例えば、ゲームを利用していればユーザは暇であるが、音声通話機能を利用していれば、取り込み中であると推測するもの
（４）携帯電話などの機器への入力情報自体から、ユーザの状況を推測するもの、例えば、音声通信における声の状態から、ユーザの気分を推測するもの
（５）携帯電話などの機器に蓄積されたデータや項目の件数から、ユーザの状況を推測するもの、例えば、未読メールの件数から、ユーザがメールをこまめに読んでいるかどうかを推測するもの
などが挙げられる。また、これらを組み合わせ演算ルールとすることもできる。
【００５１】
本発明を用いて通知するプレゼンス情報としては、
（１）コミュニケーションやトランザクションの手段を他人に選択させるもの、例えば、ユーザが騒音の大きな場所にいて電話ができないことを表すもの
（２）コミュニケーションやトランザクションの開始を他人に促すもの、例えば、ユーザが暇であることを表すもの
などが挙げられる。
【００５２】
また、状態演算部２に入力される情報を取得するために、携帯電話などの機器から、入力を促すアクションを起こすことも可能である。以下、具体的な実施例について、順に説明する。
【００５３】
（第一実施例）
第一実施例の構成を図１により説明する。ユーザの状態の変化は、プレゼンス発行モジュール２０によってプレゼンス情報に変換され、プレゼンスサービス６に発行される。
【００５４】
第一実施例は、携帯電話での音声通話から音声に関するパラメータを抽出し、状態演算部２においてプレゼンス情報を演算する実施例である。音声に関するパラメータとしては、声の大きさ、高さ、会話の速度などがある。
【００５５】
また、音声パラメータから演算されるプレゼンス情報としては、ユーザの感情や忙しさなどがある。音声パラメータからのプレゼンス情報を演算する演算ルールとしては、例えば、「声が大きくて、高い場合は、興奮している」、「声が小さくて、低い場合は、内緒話をしており取り込み中である」といったルールが適用される。
【００５６】
プレゼンス発行モジュール２０は、会話パラメータ抽出部１と、演算ルール保存部３と、状態演算部２と、プレゼンス情報保存部４と、プレゼンス情報発行部５とで構成されている。会話パラメータ抽出部１は、ユーザが行う会話に関係する１種類以上のパラメータを、音声解析や自然言語処理で用いられる手法によって収集する。
【００５７】
演算ルール保存部３は、各種の会話パラメータから、ユーザの状態記述を導出するためのルールを記憶する。状態演算部２は、演算ルール保存部３にある演算ルールに従って、会話パラメータ抽出部１が収集した会話パラメータから状態記述を導出する処理を実行する。
【００５８】
また、導出された状態記述をプレゼンス情報発行部５に渡す機能を持つ。プレゼンス情報保存部４は、前回プレゼンスサービス６に発行されたプレゼンス情報を一時的に保存する機能を持つ。プレゼンス情報発行部５は、状態演算部２から渡された状態記述から新しいプレゼンス情報を作成する機能と、新しいプレゼンス情報をプレゼンス情報保存部４に保存されているプレゼンス情報と比較する機能と、新しいプレゼンス情報をプレゼンス情報保存部４に渡す機能と、新しいプレゼンス情報をプレゼンスサービス６に発行する機能とを持つ。
【００５９】
第一実施例の動作を図４を参照して説明する。図４は第一実施例の動作を示すフローチャートである。
【００６０】
ステップＳ１（音声情報取得）：会話パラメータ抽出部１に音声情報が入力される。
【００６１】
ステップＳ２（パラメータ抽出）：ユーザが会話をすると、会話パラメータ抽出部１が音声解析や自然言語処理で用いられる手法によって会話パラメータを抽出する。この説明では、声の高さ（普通）、声の大きさ（小さい）、会話の速度（速い）がパラメータとして抽出できたとする。会話パラメータ抽出部１は、パラメータ｛声の高さ＝普通，声の大きさ＝普通，会話の速度＝ゆっくり｝を状態演算部２に渡す。
【００６２】
ステップＳ３（状態演算）：状態演算部２は、パラメータに対して、演算ルール保存部３に保存されている以下の演算ルールを適用する。パラメータ｛声の高さ＝普通，声の大きさ＝普通，会話の速度＝ゆっくり｝に対する結果として、状態記述“＜ｆｅｅｌｉｎｇ＞ｒｅｌａｘｅｄ＜／ｆｅｅｌｉｎｇ＞”を導出してプレゼンス情報発行部５に渡す。
Ａ）ｉｆ声の高さ＝普通ａｎｄ声の大きさ＝普通ａｎｄ会話の速度＝ゆっくりｔｈｅｎ状態＝“＜ｆｅｅｌｉｎｇ＞ｒｅｌａｘｅｄ＜／ｆｅｅｌｉｎｇ＞”
Ｂ）ｉｆ声の高さ＝高いａｎｄ声の大きさ＝普通ａｎｄ会話の速度＝速いｔｈｅｎ状態＝“＜ｆｅｅｌｉｎｇ＞ｎｅｒｖｏｕｓ＜／ｆｅｅｌｉｎｇ＞”
Ｃ）ｉｆ声の高さ＝低いａｎｄ声の大きさ＝小さいａｎｄ会話の速度＝速いｔｈｅｎ状態＝“＜ｆｅｅｌｉｎｇ＞ｂｕｓｙ＜／ｆｅｅｌｉｎｇ＞”
Ｄ）ｉｆ声の高さ＝高いａｎｄ声の大きさ＝大きいａｎｄ会話の速度＝速いｔｈｅｎ状態＝“＜ｆｅｅｌｉｎｇ＞ｅｘｃｉｔｅｄ＜／ｆｅｅｌｉｎｇ＞”
ステップＳ４（プレゼンス情報作成）：プレゼンス情報発行部５は、ステップＳ３で受け取った状態記述“＜ｆｅｅｌｉｎｇ＞ｒｅｌａｘｅｄ＜／ｆｅｅｌｉｎｇ＞”を含む図２のプレゼンス情報を作成する。
【００６３】
ステップＳ５（前回プレゼンス情報参照）：プレゼンス情報保存部４には前回プレゼンスサービスに発行した図３のプレゼンス情報が保存されている。
【００６４】
ステップＳ６（比較）：プレゼンス情報発行部５は、ステップＳ４で作成したプレゼンス情報と、プレゼンス情報保存部４に保存されているプレゼンス情報とを比較する。
【００６５】
ステップＳ７（プレゼンス情報発行）：両者は異なっているため、プレゼンス情報発行部５は、新しいプレゼンス情報をプレゼンスサービス６に発行する。
【００６６】
ステップＳ８（新たなプレゼンス情報保存）：プレゼンス情報発行部５で発行したプレゼンス情報は、プレゼンス情報保存部４にも渡される。プレゼンス情報保存部４は、それまで保存していた古いプレゼンス情報を破棄して、プレゼンス情報発行部５から渡された新しいプレゼンス情報を保存する。
【００６７】
ステップ９（プレゼンス情報発行しない）：プレゼンス情報保存部４に保存されている前回プレゼンス情報と今回のプレゼンス情報とが同じ場合には、プレゼンス情報発行部５は、プレゼンス情報を発行しない。
【００６８】
（応用例１）
携帯電話から単位時間あたりの電話の着信回数を取得して、プレゼンス情報を発行する応用例について説明する。着信回数が多いほど、ユーザは忙しく、着信回数が少ないほど暇であると推測される。
【００６９】
演算ルール保存部３には、例えば、演算ルール「ｉｆ１０分間あたりの電話の着信回数≧“３回”ｔｈｅｎ状態＝“取り込み中”」が保存されている。状態演算部２は、１分間あたりの電話の着信回数として“３回”を受け取ると、前記ルールに従って“取り込み中”の状態を出力する。
【００７０】
プレゼンス情報発行部５は、“取り込み中”を表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報としては、“取り込み中”の他に、頻繁にかかる電話の応対に追われていることを表すプレゼンス情報を発行することができる。
【００７１】
本応用例によって、ユーザが電話の応対に追われていることを自動的にウォッチャに伝えることができる。このユーザに電話をかけようとしているウォッチャは、少し待ってから電話をかけることができる。
【００７２】
携帯電話から単位時間あたりの電話の発信回数を取得して、発信回数が多いほど、ユーザは忙しいと推測することができる。また、発信回数が少ないほど、ユーザは暇であると推測することもできる。この場合には、演算ルールは、例えば「ｉｆ１０分間あたりの電話の発信回数≧“３回”ｔｈｅｎ状態＝“取り込み中”」とすることもできる。
【００７３】
なお、ユーザが話し中の時間は除外して、時間あたりの回数のカウントを行ってもよい。例えば、演算ルール「ｉｆ最近の待ち受け時間１０分間の内の電話の着信回数≧“３回”ｔｈｅｎ状態＝“取り込み中”」などとすることもできる。こうすることにより正確に忙しさを推測することができる。この場合に、着信回数を発信回数に替えても同様にユーザの忙しさを推測することができる。
【００７４】
携帯電話から、応答できなかった着信回数を取得して、演算ルール「ｉｆ応答できなかった着信有りｔｈｅｎ状態＝“取り込み中”」を適用することができる。未応答の着信回数が多いほど、より忙しいと推測される。
【００７５】
また、応答できなかった着信回数と着信音やバイブレータによる呼び出し時間とを取得して、演算ルール「ｉｆ一定時間以上呼び出しても応答できなかった着信有りｔｈｅｎ状態＝“取り込み中”」を適用することもできる。
【００７６】
また、携帯電話の電話帳機能と組み合わせることで、詳細なプレゼンス情報を発行することができる。電話の発信回数の他に、電話帳に登録された相手の属性を取得して、演算ルール「ｉｆ１分間あたりの電話の発信回数≧“１回”ａｎｄ相手の属性＝“仕事仲間”ｔｈｅｎ状態＝“仕事中”」を適用することができる。この場合に、発信回数を着信回数に替えても同様にユーザの詳細なプレゼンス情報を発行することができる。
【００７７】
また、携帯電話が内蔵する時刻情報や予定表と組み合わせて、「仕事中に発着信回数が多ければ忙しい」が、「プライベートな時間に発着信回数が多い場合は暇である」と推測することもできる。
【００７８】
（応用例２）
携帯電話から未読メール放置時間を取得して、プレゼンス情報を発行する応用例について説明する。未読メール放置時間が長いほど、ユーザはメールを読む時間もないほど忙しいと推測される。演算ルール保存部には、演算ルール「ｉｆ未読メール放置時間≧“３０分”ｔｈｅｎ状態＝“取り込み中”」が保存されている。状態演算部２は、未読メール放置時間として“４０分”を受け取ると、前記ルールに従って“取り込み中”の状態を出力する。プレゼンス情報発行部５は、“取り込み中”を表すプレゼンス情報をプレゼンスサービスに発行する。本応用例では、“取り込み中”以外にも、すぐにメールを読むことができないことを表すプレゼンス情報を発行することができる
【００７９】
（応用例３）
携帯電話から未読メール件数を取得して、プレゼンス情報を発行する応用例について説明する。未読メールの数が多いほど、長時間にわたってメールを読んでいないということが推測できる。演算ルール保存部は、演算ルール「ｉｆ未読メール件数≧“３０通”ｔｈｅｎ状態＝“メールを読んでいない”」が保存されている。状態演算部２は、未読メール件数として“４０通”を受け取ると、前記ルールに従って“メールを読んでいない”状態を出力する。プレゼンス情報発行部５は、メールを読んでいないことを表すプレゼンス情報をプレゼンスサービス６に発行する。本実施例によって、最近ユーザがメールを読んでいないことを自動的に相手に伝えることができる。このユーザに連絡をとる場合は、事前にメール以外の手段を選ぶことができる。
【００８０】
また、未読メールの数ではなく、着信したメールが、ある一定時間経過後も読まれない場合に、メールを読んでいないという状態を発行することもできる。
【００８１】
（応用例４）
携帯電話から着信応答時間を取得して、プレゼンス情報を発行する応用例について説明する。着信応答時間が長ければ、すぐに電話に出られないほど忙しいと推測される。この場合には、演算ルール保存部３には、例えば、演算ルール「ｉｆ着信応答時間≧“３０秒”ｔｈｅｎ状態＝“取り込み中”」が保存されている。状態演算部２は、着信応答時間として“３５秒”を受け取ると、前記ルールに従って“取り込み中”の状態を出力する。プレゼンス情報発行部５は、“取り込み中”を表すプレゼンス情報をプレゼンスサービス６に発行する。本応用例では、“取り込み中”以外にも、電話に出にくい状況にあることを表すプレゼンス情報を発行することができる。
【００８２】
また、着信応答時間が短ければ、暇であると推測することもできる。この他に、状態演算部２は、着信応答時間として“７秒”を受け取り、上記とは別の演算ルール「ｉｆ着信応答時間＜“３０秒”ｔｈｅｎ状態＝“オンライン”」を適用することも可能である。プレゼンス情報発行部５は、“オンライン”を表すプレゼンス情報をプレゼンスサービス６に発行する。本応用例では、“オンライン”以外にも、すぐに呼び出しに応答できることを表すプレゼンス情報を発行することができる。
【００８３】
（応用例５）
携帯電話から単位時間あたりのメール送信回数を取得して、プレゼンス情報を発行する応用例について説明する。メールの送信回数が多いほど、暇で退屈していると推測することができる。演算ルール保存部３には、演算ルール「ｉｆ１時間あたりのメール送信回数≧“３回”ｔｈｅｎ状態＝“退屈している”」が保存されている。状態演算部２は、１時間あたりのメール送信回数として“５回”を受け取ると、前記ルールに従って“退屈している”状態を出力する。プレゼンス情報発行部５は、“退屈している”ことを表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報は、“退屈している”の他に、コミュニケーションを要求していることを表すプレゼンス情報を発行することができる。本応用例によって、ユーザがコミュニケーションを要求していることがメールの送信相手以外のウォッチャにも通知され、ユーザとウォッチャとの間でもメールのやり取りが促進される。
【００８４】
この場合も、音声通話の発着信の場合と同様、アドレス帳と連携し、メールの送信相手が仕事相手であれば忙しく、プライベートな友人であれば退屈しているという演算をおこなうことも可能である。また、時刻情報やスケジュール帳と連携し、メールの送信相手が仕事相手であれば忙しく、プライベートな友人であれば退屈しているという演算をおこなうことも可能である。
【００８５】
（応用例６）
携帯電話からアラーム作動時間を取得して、プレゼンス情報を発行する応用例について説明する。アラーム作動時間が一定以上の場合には、ユーザが不在など、アラームを消せない状態であることが推測される。演算ルール保存部３には、たとえば、演算ルール「ｉｆアラーム作動時間≧“５分”ｔｈｅｎ状態＝“不在”」が保存されている。状態演算部２は、アラーム作動時間として“１０分”を受け取ると、前記ルールに従って“不在”の状態を出力する。プレゼンス情報発行部５は、“不在”を表すプレゼンス情報をプレゼンスサービス６に発行する。本応用例では、“不在”以外にも、アラームが作動してもユーザが気づかない状態であることを表すプレゼンス情報を発行することができる。
【００８６】
アラーム作動時間の他に、アラームの種別を組み合わせた演算も可能である。たとえば、演算ルール「ｉｆアラーム作動時間≧“１０分”ａｎｄアラーム種別＝“目覚まし”ｔｈｅｎ状態＝“オフライン”」を適用してユーザがまだ寝ていたり、寝起きが悪い状況でかかってくる電話を抑制することができる。また、演算ルール「ｉｆアラーム作動時間＜“１０秒”ａｎｄアラーム種別＝“目覚まし”ｔｈｅｎ状態＝“気分がよい”」を適用して、起きたばかりであっても連絡がとれる状況であることを通知することができる。
【００８７】
携帯電話がユーザによってアラームが停止されず一定時間放置され続けた結果、アラームが自動停止したことを検知して、ユーザが、携帯電話を利用できる状態にいないことを推測できる。この場合、たとえば、演算ルール「ｉｆアラームが自動停止したｔｈｅｎ状態＝“オフライン”」を適用することができる。
【００８８】
（応用例７）
携帯電話から単位時間あたりのボタン押下回数を取得して、プレゼンス情報を発行する応用例について説明する。単位時間あたりのボタン押下回数が多い場合、ユーザは携帯電話の操作に没頭しており、忙しいと推測できる。演算ルール保存部３には、演算ルール「ｉｆ１分間あたりのボタン押下回数≧“１２０回”ｔｈｅｎ状態＝“忙しい”」が保存されている。状態演算部２は、１分間あたりのボタン押下回数として“１３０回”を受け取ると、前記ルールに従って“忙しい”の状態を出力する。プレゼンス情報発行部５は、“忙しい”を表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報は、“忙しい”の他に、携帯電話の操作に没頭していることを表すプレゼンス情報を発行することができる。本応用例によって、ユーザが携帯電話の操作に没頭していることを自動的にウォッチャに伝えることができる。このユーザに電話をかけようとしているウォッチャは、少し待ってから電話をかけることができる。
【００８９】
また、携帯電話からバックライト点灯期間中のボタン押下回数を取得することで、より正確なユーザの忙しさを推測することが考えられる。たとえば、演算ルール「ｉｆバックライト点灯期間中のボタン押下回数≦“５回”ｔｈｅｎ状態＝“退屈している”」などを適用することができる。
【００９０】
（応用例８）
携帯電話から単位時間あたりのふたの開閉回数を取得して、プレゼンス情報を発行する応用例について説明する。ふたの開閉回数が多いほど、暇であると推測される。この場合は、演算ルール保存部３には、たとえば演算ルール「ｉｆ１分間あたりのふたの開閉回数≧“２５回”ｔｈｅｎ状態＝“暇”」が保存されている。状態演算部２は、１分間あたりのふたの開閉回数として“３０回”を受け取ると、前記ルールに従って“暇”の状態を出力する。プレゼンス情報発行部５は、“暇”を表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報は、“暇”の他に、することがないことを表すプレゼンス情報を発行することができる。本応用例によって、ユーザがすることがないことを自動的にウォッチャに伝えることができる。このユーザに電話をかけようとしているウォッチャは、ユーザが電話をかけても支障ない状態であることがわかる。
【００９１】
（応用例９）
携帯電話から単位時間内のパケット通信時間を取得して、プレゼンス情報を発行する応用例について説明する。パケット通信時間が長いほど、忙しいと推測される。
【００９２】
演算ルール保存部３には、演算ルール「ｉｆ６０分あたりのパケット通信時間≧“４０分”ｔｈｅｎ状態＝“取り込み中”」が保存されている。状態演算部２は、６０分間あたりのパケット通信時間として“５０分”を受け取ると、前記ルールに従って“取り込み中”の状態を出力する。プレゼンス情報発行部５は、“取り込み中”を表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報は、“取り込み中”の他に、手が離せないことを表すプレゼンス情報を発行することができる。本応用例によって、ユーザが手が離せないことを自動的にウォッチャに伝えることができる。このユーザに電話をかけようとしているウォッチャは、少し待ってから電話をかけることができる。
【００９３】
（応用例１０）
携帯電話からＷｅｂブラウザで閲覧したコンテンツのＵＲＬを取得して、プレゼンス情報を発行する応用例について説明する。コンテンツの種類によって推測されるユーザの状態をあらかじめ定義しておくことで、コンテンツのＵＲＬからユーザの状態が推測できる。たとえば、演算ルール「ｉｆ閲覧したＵＲＬ＝”懸賞のサイト”ｔｈｅｎ状態＝“退屈している”」を適用して、“退屈している”など懸賞のサイトから推測されるユーザの状態を通知することができる。
【００９４】
他にも、演算ルールとして「ｉｆ閲覧したＵＲＬ＝”乗り換え検索”ｔｈｅｎ状態＝“取り込み中”」や、「ｉｆ閲覧したＵＲＬ＝”グルメ検索”ｔｈｅｎ状態＝“飲みに行きたい”」などがあげられる。
【００９５】
ユーザが、利用している携帯電話のアプリケーションによって、ユーザが退屈しているのか忙しいのかを推測することができる。たとえば、「ｉｆゲームを利用しているｔｈｅｎ状態＝“退屈している”」という演算ルールが適用できる。
【００９６】
携帯電話から単位時間あたりのアンテナの伸縮回数を取得して、ユーザが退屈していることを推測することができる。たとえば、「ｉｆ１分間あたりのアンテナの伸縮回数≧“５回”ｔｈｅｎ状態＝“退屈している”」という演算ルールが適用できる。
【００９７】
（応用例１１）
携帯電話を所有するユーザの認証に失敗したことを検出して、プレゼンス情報を発行する応用例について説明する。認証方式には、パスワード、指紋、顔などがあるが、ここではその方式を限定しない。一定回数を超えてユーザ認証に失敗すると、第三者が携帯電話を利用していると推測される。演算ルール保存部３には、演算ルール「ｉｆ認証に失敗した回数≧“３回”ｔｈｅｎ状態＝“不審者操作中”」が保存されている。状態演算部２は、間違ったパスワードが入力された回数として“４回”を受け取ると、前記ルールに従って“不審者操作中”の状態を出力する。プレゼンス情報発行部５は、“不審者操作中”を表すプレゼンス情報をプレゼンスサービス６に発行する。プレゼンス情報は、“不審者操作中”の他に、第三者が携帯電話の保護データに進入を試みられていることを表すプレゼンス情報を発行することができる。本応用例によって、携帯電話の保護データに進入を試みられていることを自動的にウォッチャに伝えることができる。携帯電話の所有者がウォッチャの場合、携帯電話を物理的に保護する対策を取ることができる。
【００９８】
また、携帯電話の貸し借りの際に、携帯電話の所有者以外の人が使用中であることを推測する次の演算ルール「ｉｆ認証に失敗した回数≧”１回”ｔｈｅｎ状態＝“オフライン”」も考えられる。たとえば、友人などに携帯電話を貸している間は所有者に連絡がとれないことを表すプレゼンス情報を通知することができる。この通知を受けたウォッチャは、友人などが使用中の携帯電話に、電話をかけないでおくことができる。
【００９９】
（応用例１２）
携帯電話から周囲の雑音の音量を取得して、プレゼンス情報を発行する応用例について説明する。演算ルール保存部３には、演算ルール「ｉｆ“８０ｄＢ”≦音量≦“１００ｄＢ”ｔｈｅｎ状態＝“電話ができない”」が保存されている。状態演算部２は、雑音の音量として“８５ｄＢ”を受け取ると、前記ルールに従って“電話ができない”状態を出力する。プレゼンス情報発行部５は、“電話ができない”ことを表すプレゼンス情報をプレゼンスサービス６に発行する。特に、周囲の雑音が８０ｄＢ以上で通話が困難である状況では、プレゼンス情報として、電話に出られないことを表すプレゼンス情報を発行することができる。本応用例によって、ウォッチャは、ユーザが通話困難な状態であるときには、電話以外の連絡手段を事前に選択できる。
【０１００】
（応用例１３）
携帯電話から周囲の雑音を解析して、プレゼンス情報を発行する応用例について説明する。雑音を解析した結果、電車の音であった場合には、ユーザの状態が移動中であると推測することができる。
【０１０１】
上記の応用例においては、周囲の雑音の取得は、携帯電話での通話のタイミングのほか、常にマイクをオンにしておく、あるいは定期的にマイクをオンにする、その他ある決まった条件に一致した場合にマイクをオンにすることによりおこなう。
【０１０２】
（応用例１４）
携帯電話での音声通信における会話内容を音声認識システムを含む会話パラメータ抽出部１が解析して、プレゼンス情報を発行する応用例について説明する。会話パラメータ抽出部１に含まれる音声認識システムは、ユーザの発話内容から、登録されたキーワードを抜きだす。演算ルール保存部３には、各キーワードに対応するユーザのプレゼンス情報を推測する演算ルールが登録されている。演算ルールとしては、たとえば、「ｉｆキーワード“悲しい”が発話された場合ｔｈｅｎ状態＝“気分が落ち込んでいる”」が保存されている。本応用例は、携帯電話と、会話パラメータ抽出部１に音声認識システムを含むプレゼンス発行モジュール２０とで構成することができる。なお、このプレゼンス発行モジュール２０は、プレゼンスサーバとして設けることもできる。
【０１０３】
（第二実施例）
第二実施例のプレゼンス発行モジュール２１を図５を参照して説明する。第二実施例では、発話部７がユーザに元気かどうかを質問し、返事を音声認識システムを含む会話パラメータ抽出部１が解析して、プレゼンス情報を発行する実施例について説明する。演算ルール保存部３には、演算ルール「ｉｆ“調子はどう？”に対する返事＝“ほっといて”ｔｈｅｎ状態＝“気分が落ち込んでいる”」が保存されている。状態演算部２は、“調子はどう？”に対する返事として“ほっといて”という言葉を受け取ると、前記ルールに従って“気分が落ち込んでいる”という状態を出力する。プレゼンス情報発行部５は、“気分が落ち込んでいる”ことを表すプレゼンス情報をプレゼンスサービス６に発行する。特に、発話部７がユーザに話しかけることによって、ユーザが自発的に会話をしない場合であっても、自然に、ユーザの感情、気分、ストレスの度合いなどの変化に応じてプレゼンス情報を発行できる。
【０１０４】
第二実施例によって、ウォッチャからのコミュニケーションを促進する効果が期待できる。第二実施例は、携帯電話と、会話パラメータ抽出部１に音声認識システムを含むプレゼンス発行モジュール２１とで構成することができる。また、プレゼンス発行モジュール２１はプレゼンスサーバとして設けることもできる。
【０１０５】
なお、状態演算部２によって演算されたプレゼンス情報は、一定時間経過後、変更される前のプレゼンス情報に戻したり、別の演算により置き換えられたり、その他ユーザ操作により置き換えられたりする。
【０１０６】
このように、第二実施例のプレゼンス発行モジュール２１は、第一実施例のプレゼンス発行モジュール２０に、新しく発話部７が追加されており、人と会話をするロボットを想定することができる。発話部７がユーザに話しかけることによって、ユーザが自発的に会話をしない場合であっても、自然に、ユーザの感情、気分、ストレスの度合いなどの変化を検出することができる。発話部７には、最終会話時刻を保存する機能と、ユーザとの会話を理解する機能と、ユーザに話しかける機能が含まれる。
【０１０７】
第二実施例の動作を図６を参照して説明する。図６は第二実施例の動作を示すフローチャートである。
【０１０８】
ステップＳ１（音声情報取得）：会話パラメータ抽出部１に音声情報が入力される。
【０１０９】
ステップＳ１０（時刻記録）：ユーザが会話をおこなうと、発話部７は、最終会話時刻を現在時刻に更新する。
【０１１０】
ステップ２〜ステップＳ９は、第一実施例と同じである。
【０１１１】
ステップＳ１１（最終会話時刻から所定時間経過したか？かつ、まだユーザに話しかけいていなか？）：発話部７は、最終会話時刻からの経過時間を監視している。
【０１１２】
ステップＳ１２（ユーザに話しかける）：ユーザとの会話がない状態が一定期間を超えると、再度ユーザの状態を取得するためにユーザに話しかける。
【０１１３】
ステップ１２’（ユーザが発言をしたか？）：ステップＳ１２で会話部７がユーザに話しかけた結果、ユーザが発言をしたか否かを判定し、発言したならばステップＳ１に進み、発言していないならば、再び、ステップＳ１１に戻る。
【０１１４】
さらに高度な自然言語理解能力を持つロボットを用いれば、単語や文脈に関する情報を会話パラメータとして扱うことも考えられる。演算ルールには、高度な推論機能を導入してもよい。単語や文脈に関するパラメータから推論をおこなうことで、多様なプレゼンス情報を発行することができる。
【０１１５】
さらに、発話部７に、入力情報である操作入力情報の最終入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。この場合には、発話部７には、ユーザの音声情報と共に操作入力情報が入力される。
【０１１６】
ここで、操作入力情報とは、プレゼンス発行モジュール２１が組み込まれた携帯電話やＰＤＡなどのユーザ装置における操作入力情報である。なお、図５における操作入力情報の入力の図示は省略した。
【０１１７】
また、図６に示すフローチャートについては、ステップＳ１１は「最終操作入力時刻から所定時間経過したか？かつ、まだ操作入力喚起手順を実行していないか？」となり、ステップ１２は「操作入力喚起手順実行」となり、ステップＳ１２’は「ユーザが操作をしたか？」となり、ステップＳ１は「操作入力情報取得」となる。このような操作入力情報に基づく応用例を以下に応用例１５〜１９として説明する。
【０１１８】
（応用例１５）
ここで、携帯電話などの機器がユーザに対してアクションを起こし、状態演算部２への入力を促す応用例をあげる。
【０１１９】
一定時間メールを受信しない場合に、携帯電話が各種サービスにメールの配信登録をおこなうことで、状態演算部２への入力を促す応用例が考えられる。ユーザにメールを送信する人がいないときでも、未読メールの放置時間を取得して、プレゼンス情報を発行することができる。
【０１２０】
（応用例１６）
一定時間電話の着信がない場合に、携帯電話が各種サービスにコールバックを要求することで、状態演算部２への入力を促す応用例が考えられる。ユーザに電話をかける人がいないときでも、電話の着信応答時間を取得して、プレゼンス情報を発行することができる。
【０１２１】
（応用例１７）
一定時間プレゼンス情報の更新がない場合に、携帯電話が画面にＷｅｂコンテンツへのリンクを表示することで、ユーザに対してＷｅｂコンテンツの閲覧を促すことができる。ユーザが自発的にＷｅｂコンテンツの閲覧をおこなわない場合でも、ユーザが閲覧したＷｅｂコンテンツのＵＲＬを取得して、プレゼンス情報を発行することができる。
【０１２２】
特に、携帯電話が待ち受け状態のときに、リンクを表示することが考えられる。リンク先のコンテンツは、ニュース、天気予報、スポーツ速報、懸賞への応募、着信メロディの試聴サイトなどが考えられる。
【０１２３】
各種コンテンツへのリンクは、企業などからの広告であってもよい。広告を表示していることを、光や音や振動を使ってユーザに気づかせることも考えられる。携帯電話が画面にリンクを表示するときは、バックライトなどの自動点灯をおこない、ユーザが画面を見やすいようにすることも可能である。
【０１２４】
（応用例１８）
一定時間プレゼンス情報の更新がない場合に、携帯電話のアプリケーションを起動して、状態演算部２への入力を促す応用例が考えられる。ユーザが自発的にアプリケーションを起動しない場合でも、ユーザが利用したアプリケーションや、キーの押下回数を取得して、プレゼンス情報を発行することができる。
【０１２５】
特に、ゲームアプリケーションの場合は、ゲームのキャラクターやアバターなどが、ユーザをゲームに誘うことが考えられる。また、ペット育成ゲームのように、定期的なインタラクションを要するアプリケーションを、状態演算部２への入力を促すために起動することも考えられる。
【０１２６】
（応用例１９）
一定時間プレゼンス情報の更新がない場合に、携帯電話のアラームを作動させて、状態演算部２への入力を促す応用例が考えられる。ユーザが自発的にアラームを設定しない場合でも、アラームの作動時間や、キーの押下回数などを取得して、プレゼンス情報を発行することができる。
【０１２７】
また、スケジュールが決まっていない時間帯にさしかかったときに、携帯電話がアラームを作動させて、状態演算部２への入力を促すことも考えられる。この方法は、スケジュールからユーザの状態が推測できない場合に有効である。
【０１２８】
（第三実施例）
第三実施例を図７および図８を参照して説明する。図７は第三実施例のプレゼンス情報発行システムの構成図である。第一および第二実施例は、プレゼンス発行モジュール２０または２１の実施例であり、その音声入力手段として携帯電話を用いて説明したが、その入力手段は限定的なものではなかった。これに対し、第三実施例では、携帯電話３０とプレゼンスサーバ３１とにより構成されたプレゼンス情報発行システムとして説明する。
【０１２９】
第三実施例は、図７に示すように、携帯電話３０とプレゼンスサーバ３１とプレゼンスサービス６とで構成されている。携帯電話３０には、会話パラメータ抽出部１と、会話パラメータ送信部９と、ポリシ管理部８が内蔵されている。会話パラメータ送信部９は、会話パラメータ抽出部１で収集した会話に関するパラメータを、プレゼンスサーバ３１に送信する。携帯電話３０とプレゼンスサーバ３１との間にはネットワークを経由することが考えられる。ネットワーク経由で会話パラメータを送信する場合に、会話パラメータ送信部９は、個人のプライバシに関わる情報をフィルタリングすることができる。ポリシ管理部８は、会話パラメータをフィルタリングして携帯電話外へ送信する際のフィルタリング規則を管理する。プレゼンスサーバ３１は、会話パラメータ受信部１０と、演算ルール保存部３と、状態演算部２と、プレゼンス情報発行部５と、プレゼンス情報保存部４を含む。会話パラメータ受信部１０は、携帯電話３０から送信された会話パラメータを受信することができる。プレゼンスサーバ３１は、携帯電話３０に代わってユーザのプレゼンス情報をプレゼンスサービス６に発行する。
【０１３０】
第三実施例の動作を図８を参照して説明する。図８は第三実施例の動作を示すフローチャートである。
【０１３１】
ステップＳ１３（フィルタリング規則の登録）：ユーザは、声の高さのパラメータをプレゼンスサーバ３１に送信しないようにするために、フィルタリング規則をポリシ管理部８に登録する。
【０１３２】
ステップＳ１（音声情報取得）：会話パラメータ抽出部１に音声情報が入力される。
【０１３３】
ステップＳ２（パラメータ抽出）：第一実施例のステップＳ２と同様にしてパラメータを抽出する。会話パラメータ抽出部１は、パラメータを会話パラメータ送信部９に渡す。
【０１３４】
ステップＳ１４（フィルタリング実施）：会話パラメータ送信部９は、ポリシ管理部８から取得したフィルタリング規則に従ってフィルタリングをおこなう。具体的には、送信すべきでない特定のパラメータ値を、統計的に算出した平均値に置き換える方法などが考えられる。ステップＳ１３で登録したフィルタリング規則を適用すると声の高さ＝“普通”となる。
【０１３５】
会話パラメータ送信部９は、ネットワークを経由して会話パラメータをプレゼンスサーバ３１に送信する。
【０１３６】
会話パラメータ受信部１０は、パラメータを携帯電話３０から受け取り、状態演算部２に渡す。
【０１３７】
ステップＳ３〜ステップＳ９は第一実施例と同じである。
【０１３８】
ステップＳ１５（フィルタリング規則変更あるか？）：フィルタリング規則に変更があれば、再度、フィルタリング規則を登録する（Ｓ１３）。
【０１３９】
なお、本実施例は、携帯電話３０に限らず、固定電話に対しても適用可能である。さらに、プレゼンスサーバ３１が作成したプレゼンス情報を携帯電話３０に返送して、携帯電話３０がプレゼンスサービス６においてプレゼンス情報を発行することも考えられる。その場合には、ユーザは、会話に基づいてプレゼンスサーバ３１が作成したプレゼンス情報を携帯電話３０で確認することができる。
【０１４０】
（第四実施例）
第四実施例を図９および図１０を参照して説明する。図９は第四実施例の携帯電話のブロック構成図である。図１０は第四実施例の動作を示すフローチャートである。第四実施例は、図９に示すように、図７に示す第三実施例の携帯電話３０に、図５に示す第二実施例の発話部７を備えた構成である。第四実施例の動作は図１０に示すように、図６および図８のフローチャートを合わせたものである。すなわち、
ステップＳ１３（フィルタリング規則の登録）：ユーザは、声の高さのパラメータをプレゼンスサーバ３１に送信しないようにするために、フィルタリング規則をポリシ管理部８に登録する。
【０１４１】
ステップＳ１（音声情報取得）：会話パラメータ抽出部１に音声情報が入力される。
【０１４２】
ステップ１０（時刻記録）：ユーザが会話をおこなうと、発話部７は、最終会話時刻を現在時刻に更新する。
【０１４３】
ステップＳ２（パラメータ抽出）：第一実施例のステップＳ２と同様にしてパラメータを抽出する。会話パラメータ抽出部１は、パラメータを会話パラメータ送信部９に渡す。
【０１４４】
ステップＳ１４（フィルタリング実施）：会話パラメータ送信部９は、ポリシ管理部８から取得したフィルタリング規則に従ってフィルタリングをおこなう。具体的には、送信すべきでない特定のパラメータ値を、統計的に算出した平均値に置き換える方法などが考えられる。ステップＳ１３で登録したフィルタリング規則を適用すると、声の高さ＝“普通”となる。
【０１４５】
会話パラメータ送信部９は、ネットワークを経由して会話パラメータをプレゼンスサーバ３１に送信する。
【０１４６】
会話パラメータ受信部１０は、パラメータを携帯電話３０から受け取り、状態演算部２に渡す。
【０１４７】
ステップＳ３〜ステップＳ９は第一実施例と同じである。
【０１４８】
ステップＳ１５（フィルタリング規則変更あるか？）：フィルタリング規則に変更があれば、再度、フィルタリング規則を登録する（Ｓ１３）。
【０１４９】
ステップＳ１１（最終会話時刻から所定時間経過したか？かつ、まだユーザに話しかけていないか？）：発話部７は、最終会話時刻からの経過時間を監視している。
【０１５０】
ステップＳ１２（ユーザに話しかける）：ユーザとの会話がない状態が一定期間を超えると、再度ユーザの状態を取得するためにユーザに話しかける。
【０１５１】
ステップ１２’（ユーザが発言をしたか？）：ステップＳ１２で会話部７がユーザに話しかけた結果、ユーザが発言をしたか否かを判定し、発言したならばステップＳ１に進み、発言していないならば、再び、ステップＳ１１に戻る。図１０では、ステップＳ１２’からステップＳ１１に戻るときにステップＳ１５を経由するが、ステップＳ１２’から直接ステップＳ１１に戻ってもよい。ただし、この場合には、ユーザが発言するまで、フィルタリング規則の変更は不可となる。
【０１５２】
さらに高度な自然言語理解能力を持つロボットを用いれば、単語や文脈に関する情報を会話パラメータとして扱うことも考えられる。演算ルールには、高度な推論機能を導入してもよい。単語や文脈に関するパラメータから推論をおこなうことで、多様なプレゼンス情報を発行することができる。
【０１５３】
なお、本実施例は、携帯電話３０に限らず、固定電話に対しても適用可能である。さらに、プレゼンスサーバ３１が作成したプレゼンス情報を携帯電話３０に返送して、携帯電話３０がプレゼンスサービス６においてプレゼンス情報を発行することも考えられる。その場合には、ユーザは、会話に基づいてプレゼンスサーバ３１が作成したプレゼンス情報を携帯電話３０で確認することができる。
【０１５４】
さらに、発話部７に、携帯電話３０に対するユーザの最終操作入力時刻を保持する手段と、この保持する手段に保持されている最終操作入力時刻から所定時間経過してもなお新たな操作入力がないときには、所定の操作入力喚起手順を実行する手段とを備えることができる。この場合には、発話部７には、ユーザの音声情報と共に操作入力情報が入力される。なお、図９における操作入力情報の入力の図示は省略した。このような操作入力情報に基づく応用例は、前述した第二実施例における応用例１５〜１９と同様である。
【０１５５】
また、図１０に示すフローチャートについては、ステップＳ１１は「最終操作入力時刻から所定時間経過したか？かつ、まだ操作入力喚起手順を実行していないか？」となり、ステップ１２は「操作入力喚起手順実行」となり、ステップＳ１２’は「ユーザが操作をしたか？」となり、ステップＳ１は「操作入力情報取得」となる。
【０１５６】
なお、操作入力情報を用いる場合のフィルタリング規則の例としては、例えば、携帯電話３０の単位時間あたりの発信回数あるいは着信回数によって、ユーザの忙しさを推測することができるが、ユーザは、発信回数または着信回数のパラメータをプレゼンスサーバ３１に送信しないようにするために、フィルタリング規則をポリシ管理部８に登録すると、忙しさ＝“普通”となる。
【産業上の利用可能性】
【０１５７】
本発明によれば、ユーザの置かれた状態をユーザの手動入力に頼ることなく、自動的に推測して表示することができる。よって、子供や痴呆老人など、自力で自己の状態情報を入力困難なユーザの状態を把握するシステムに利用することができる。あるいは、ユーザの状態を把握して動作するロボットに応用することができる。あるいは、電話中にお互いの気持ちや感情を交換するサービスに利用することができる。
【図面の簡単な説明】
【０１５８】
【図１】第一実施例のプレゼンス発行モジュールのブロック構成図。
【図２】プレゼンス情報の一例を示す図。
【図３】前回のプレゼンス情報の一例を示す図。
【図４】第一実施例の動作を示すフローチャート。
【図５】第二実施例のプレゼンス発行モジュールのブロック構成図。
【図６】第二実施例の動作を示すフローチャート。
【図７】第三実施例のプレゼンス情報発行システムの全体構成図。
【図８】第三実施例の動作を示すフローチャート。
【図９】第四実施例の携帯電話のブロック構成図。
【図１０】第四実施例の動作を示すフローチャート。
【符号の説明】
【０１５９】
１  会話パラメータ抽出部
２  状態演算部
３  演算ルール保存部
４  プレゼンス情報保存部
５  プレゼンス情報発行部
６  プレゼンスサービス
７  発話部
８  ポリシ管理部
９  会話パラメータ送信部
１０  会話パラメータ受信部
２０、２１  プレゼンス発行モジュール
３０  携帯電話
３１  プレゼンスサーバ
【図１】
2005275890.tif 000003
【図２】
2005275890.tif 000004
【図３】
2005275890.tif 000005
【図４】
2005275890.tif 000006
【図５】
2005275890.tif 000007
【図６】
2005275890.tif 000008
【図７】
2005275890.tif 000009
【図８】
2005275890.tif 000010
【図９】
2005275890.tif 000011
【図１０】
2005275890.tif 000012