JP2006113744A - 情報処理装置および方法、並びにプログラム - Google Patents

Abstract

【課題】ユーザの状況に応じてイベントの通知を行えるようにする。
【解決手段】 スケジュールとして登録されているイベントの開始時刻になり、そのことをユーザに通知する場合、複数のセンサからセンシング情報が取得される。取得されたセンシング情報から、端末（ユーザ）が位置する周りの状況が認識される。例えば、センシング情報として位置情報が取得された場合で、その位置情報から会議室と判断されたようなときで、通知するイベント内容が会議であったようなときには、ユーザは既に会議が行われる会議室に居ると判断され、通知を行う必要はないと判断され、通知は行われない。本発明は、ＰＤＡなどの装置に適用することが可能である。
【選択図】図１５

Description

本発明は、情報処理装置および方法、並びにプログラムに関し、特に、予め設定されている処理を、その処理を実行させる時点で取得される情報に対応して、処理内容を変更するような際に適用して好適な情報処理装置および方法、並びにプログラムに関する。

近年、パーソナルコンピュータやＰＤＡ（Personal Digital Assistant）が普及し、そのような機器を利用してスケジュールを管理しているユーザも増えつつある。ユーザがスケジュール（イベント）を入力すると、そのイベントが発生する時刻に、ユーザに通知する機能を有しているスケジューラアプリケーションもある。（例えば、非特許文献１参照）

また、テレビジョン放送の番組の録画を録画装置に予約するといった操作は、従来から行われていたが、上記したＰＤＡなど録画装置以外の装置からも、その録画装置に対する録画予約の設定を行えるようになってきている。
ソニー株式会社、"製品情報 クリエ"、［オンライン］、平成１６年９月２１日検索、インターネット＜http://www.sony.jp/CLIE/enjoy/index.html＞

従来のスケジューラアプリケーションは、個々のユーザが自己のイベントを、自己のスケジューラに登録していた。その入力するイベントが他のユーザと共有しても良いような場合、例えば、会議などのイベントであり、複数のユーザが同一のイベントに参加するような場合であっても、そのイベントに参加するユーザが、個々に自己のイベントとして自己のスケジューラに登録していた。

また、会社内などで共通のアプリケーションとして用いられているスケジューラなどには、会議などの共有できるイベントは、１人が複数の人のイベントとして登録できる機能を有しているものもある。しかしながら、共通のアプリケーションを用いているため、会社内など、所定の場所に設置されている端末から、専用のサーバにアクセスすることにより、自己のスケジュールを確認できるようになっているだけで、そのサーバにアクセスできない端末で管理されているスケジュール（例えば、個人のＰＤＡで管理されているスケジュール）を、複数のユーザで共有することはできないといった課題があった。

また、ユーザは、テレビジョン放送の番組の録画を予約したにもかからず、その番組をリアルタイムで視聴できる場合がある。このような場合、ユーザは、その録画予約を解除しても良いが、予約を解除するには、ユーザ自身が解除するための操作を行わなくてはならなかった。例えば、ユーザが所定の番組を視聴したい場合、その番組が放送される時点で、ユーザが視聴できる状態であるか否かにかかわらず、ユーザは予め録画予約をしておくか、録画予約をせずに、リアルタイムに視聴するかしなければならなかった。

スケジュールとして、番組の視聴を設定しておいたとしても、番組の視聴といったようなスケジュールは、番組が放送される時点で、視聴できれば視聴すれば良いし、視聴できなければ録画するといったように、その時点での状況に応じて、臨機応変に対応されれば良いスケジュールであるが、そのような状況に応じて、録画などの処理を実行させることは、スケジュールとして設定しておくことはできないといった課題があった。

また、設定されたスケジュールが実行される時間になったときに、ユーザにそのことを通知する機能を有するアプリケーションもあるが、例えば、通知する時点で、ユーザは、既に設定されているスケジュールを実行している（従って、通知する必要がない状況）ときがある。通知するとしても、通知の仕方（例えば、音、光などが用いられた通知）が、通知する時点での状況に適していない（例えば、会議中のときに、音声で通知するなど）ときがある。

しかしながら、ユーザが既にスケジュールを実行していても通知がなされ、音声などで通知するにはふさわしくない状況であっても、音声で通知がされるなど、実際に通知が行われるときの状況に適していない通知が行われてしまうといった課題があった。

本発明はこのような状況に鑑みてなされたものであり、複数のユーザ間で、スケジュールを簡便に共有できるようにすることを目的とする。また、予め設定されているスケジュールを実行する際、そのときの状況に適するように、スケジュールを実行することを目的とする。

本発明の第１の情報処理装置は、第１に、所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定手段と、センシング情報を取得する取得手段と、取得手段により取得されたセンシング情報を用い、条件を満たすか否かを判断する判断手段と、判断手段により条件が満たされると判断された場合、所定のアプリケーションまたはファイルを起動する起動手段とを備えることを要旨とする。

第２に、前記第１の要旨に加え、テレビジョン放送の番組を視聴するイベントが登録された場合、判断手段は、番組を受信してよい状況であるか否かを判断し、判断手段により番組を受信してよい状況であると判断された場合、起動手段は、番組を視聴するためのアプリケーションを起動し、判断手段により番組を受信してよい状況ではないと判断された場合、起動手段は、番組を録画するためのアプリケーションを起動し、判断手段により番組を受信してよいが、ネットワーク経由で番組を受信すると判断された場合、起動手段は、ネットワーク経由で番組を受信するためのアプリケーションを起動することを要旨とする。

本発明の第１の情報処理方法は、所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定ステップと、センシング情報を取得する取得ステップと、取得ステップの処理で取得されたセンシング情報を用い、条件を満たすか否かを判断する判断ステップと、判断ステップの処理で条件が満たされると判断された場合、所定のアプリケーションまたはファイルを起動する起動ステップとを含むことを要旨とする。

本発明の第１のプログラムは、所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定ステップと、センシング情報を取得する取得ステップと、取得ステップの処理で取得されたセンシング情報を用い、条件を満たすか否かを判断する判断ステップと、判断ステップの処理で条件が満たされると判断された場合、所定のアプリケーションまたはファイルを起動する起動ステップとを含むことを要旨とする。

本発明の第２の情報処理装置は、第１に、センシング情報を取得する取得手段と、取得手段により取得されたセンシング情報から周りの状況を判断する判断手段と、判断手段により判断された状況に適した通知方法を選択する選択手段と、選択手段により選択された通知方法で、所定のイベントの発生を通知する通知手段とを備えることを要旨とする。

第２に、前記第１の要旨に加え、センシング情報が位置情報である場合、判断手段は、位置情報から現在地を確定し、選択手段は、判断手段により判断された現在地から、イベントが実行される場所までの地図をユーザに提示する方法を通知方法として選択することを要旨とする。

本発明の第２の情報処理方法は、センシング情報を取得する取得ステップと、取得ステップの処理で取得されたセンシング情報から周りの状況を判断する判断ステップと、判断ステップの処理で判断された状況に適した通知方法を選択する選択ステップと、選択ステップの処理で選択された通知方法で、所定のイベントの発生を通知する通知ステップとを含むことを要旨とする。

本発明の第２のプログラムは、センシング情報を取得する取得ステップと、取得ステップの処理で取得されたセンシング情報から周りの状況を判断する判断ステップと、判断ステップの処理で判断された状況に適した通知方法を選択する選択ステップと、選択ステップの処理で選択された通知方法で、所定のイベントの発生を通知する通知ステップとを含むことを要旨とする。

本発明の第１の情報処理装置および方法、並びにプログラムにおいては、登録されているイベントが実行されるとき、そのイベントに関連付けられて所定のアプリケーションまたはファイルが起動される。設定されている条件が満たされるときだけ、アプリケーションまたはファイルが起動されるように制御される。

本発明の第２の情報処理装置および方法、並びにプログラムにおいては、登録されているイベントの開始時刻が近づいていることをユーザに通知する際、ユーザの周りの状況が判断され、その判断された状況に適した方法で、通知が行われる。

本発明によれば、スケジュールのイベントを登録することが可能となる。

本発明によれば、登録されるイベントを複数のユーザと共有する場合、簡便にその登録を行うことができる。また、イベントを共有することを誘われた側も、簡便な処理で、自己のスケジューラに登録することができる。

また、登録されたイベントを実行する時刻になったときに、ユーザに通知を行うことができる。通知を行う際、通知を行うべきか否かを判断することが可能となる。このような判断が行われることにより、ユーザにとって必要のない通知が行われるようなことを防ぐことができ、ユーザを煩わしてしまうようなことを防ぐことが可能となる。

また、通知が行われる際、ユーザの状況を判断して行うことが可能となり、ユーザにとって適切な方法で、通知が行えるようになる。

また、本発明によれば、イベントが実行される際、ユーザの手を煩わすようなことなく、所定のアプリケーションを起動させることが可能となる。また、アプリケーションを起動させる際に、制限をもたせることが可能となり、不要にアプリケーションが起動されてしまう（アプリケーションが悪用される）ようなことを防ぐことが可能となる。

また、本発明によれば、ユーザが視聴を所望したテレビジョン放送の番組を、ユーザが見逃してしまうようなことを防ぐことが可能となる。

以下に本発明の最良の形態を説明するが、開示される発明と実施の形態との対応関係を例示すると、次のようになる。明細書中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。

さらに、この記載は、明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現し、追加されたりする発明の存在を否定するものではない。

本発明の第１の情報処理装置（例えば、図２の端末３）は、所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定手段（例えば、図５のイベント管理マネージャ２１１）と、センシング情報を取得する取得手段（例えば、図５のセンシングマネージャ２１２）と、取得手段により取得されたセンシング情報を用い、条件を満たすか否かを判断する判断手段（例えば、図５のイベント管理マネージャ２１１）と、判断手段により条件が満たされると判断された場合、所定のアプリケーションまたはファイルを起動する起動手段（例えば、図５のイベント管理マネージャ２１１）とを備えることを要旨とする。

本発明の第２の情報処理装置（例えば、図２の端末３）は、センシング情報を取得する取得手段例えば、図５のセンシングマネージャ２１２）と、取得手段により取得されたセンシング情報から周りの状況を判断する判断手段（例えば、図５のイベント管理マネージャ２１１）と、判断手段により判断された状況に適した通知方法を選択する選択手段（例えば、図５のイベント管理マネージャ２１１）と、選択手段により選択された通知方法で、所定のイベントの発生を通知する通知手段（例えば、図５のイベント管理マネージャ２１１）とを備えることを要旨とする。

以下に、本発明の実施の形態について図面を参照して説明する。

［全体構成］
図１は、本発明を適用したシステムの一実施の形態の構成を示す図である。図１に示したシステムは、スケジュール（イベント）を複数のユーザ間で共有するときに用いられるシステムである。また、設定されたスケジュールは、実行するタイミングに、そのときの状況に適した方法で、ユーザに通知されるようにするためのシステムである。そのスケジュールの１つとして、テレビジョン放送の番組の視聴も設定できるようにするためのシステムである。

ネットワーク１は、インターネットやＬＡＮ（Local Area Network）などから構成されるネットワークである。ネットワーク１には、例えば、家庭内において構築されたネットワーク２が接続される。ネットワーク２には、端末３とホームサーバ４が接続されている。また、ネットワーク１には、端末５と端末６が接続されている。

ここで、端末３，４，５は、それぞれ、ＰＣ（Personal Computer）やＰＤＡ（Personal Digital Assistant）などであり、ネットワーク１やネットワーク２を介して、互いにデータの授受が行えるように構成されている。授受されるデータは、例えば、スケジュールに関するデータである。ホームサーバ４は、例えば、テレビジョン放送の番組を録画するために設けられている。

図１においては、説明の都合上、端末３，４，５しか図示していないが、さらに複数の端末がネットワーク１やネットワーク２に接続され、互いにデータの授受ができるように構成されている。また、端末４や端末５も、家庭内のネットワークに接続できる構成とされている。

［端末の内部構成例］
図２は、端末３の内部構成例を示す図である。端末３のＣＰＵ（Central Processing Unit）２１は、ＲＯＭ（Read Only Memory）２２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Random Access Memory）２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース２５は、キーボードやマウスから構成される入力部２６が接続され、入力部２６に入力された信号をＣＰＵ２１に出力する。また、入出力インタフェース２５には、ディスプレイやスピーカなどから構成される出力部２７も接続されている。

さらに、入出力インタフェース２５には、ハードディスクなどから構成される記憶部２８、および、インターネットなどのネットワークを介して他の装置とデータの授受を行う通信部２９も接続されている。ドライブ３０は、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、半導体メモリ４４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。

なお、端末５や端末６も、端末３と基本的に同様の構成なので、その説明は省略する。

また、ここでは、端末３は、一体型の装置として説明するが、例えば、入力部２６や出力部２７の一部が、本体と別体に構成されているようにしても良い。詳細は後述するが、本実施の形態においては、入力部２６が複数のセンサを有し、そのセンサから取得される情報が用いられ、ユーザの存在位置などが確認され、その確認された情報に応じて、出力部２７として備えられている通知機能によりイベントの通知が行われる。

よって、そのような情報を取得する部分や通知を行う部分は、ユーザが装着できるような装置としても良い。

［入力部、出力部について］
図３は、入力部２６のさらに詳細な構成例を示す図である。入力部２６は、センシング（sensing）部６１と操作部６２を備える。センシング部６１は、位置情報取得部７１、時刻情報取得部７２、音情報取得部７３、画像情報取得部７４、および、天気情報取得部７５から構成される。これらの各部は、それぞれの情報を取得するためのセンサにより構成されている。位置情報取得部７１は、例えば、ＧＰＳ（Global Positioning System）を用いたセンサとされる。時刻情報取得部７２は、パーソナルコンピュータなどが通常備える時計の機能を用いることができる。

音情報取得部７３は、マイクロホンなど、音を集積することができるセンサから構成される。画像情報取得部７４は、カメラなど、画像を撮像することができるセンサから構成される。天気情報取得部７５は、気温や湿度などの天気に関する情報を取得することができるセンサから構成される。

ここでは、これらのセンサがセンシング部６１に備えられているとして説明を続けるが、必ずしも上記した全てのセンサを備える必要はない。また、上記した以外のセンサを設けるようにしても勿論良い。

操作部６２は、キーボード８１とマウス８２から構成される。ここでは図示しないが、タッチパネルなどが操作部６２として備えられても、勿論良い。

図４は、出力部２７の詳細な構成例を示す図である。出力部２７は、ディスプレイなどから構成され、画像や映像などを表示する表示部１０１、音声を出力するスピーカ１０２を有する。また、出力部２７は、スケジュールを実行する時刻になったことを光によりユーザに知らせるための発光部１０３、振動により知らせるための振動部１０４を備える。

［端末が有する機能について］
図５は、端末３が有する機能について説明するための図である。ここでは、図５に示す各機能は、アプリケーション２０１が、ＣＰＵ２１により実行されることにより実現される機能であるとして説明する。

イベント管理マネージャ２１１は、スケジュールとして設定されたイベントを管理する処理を実行する。イベント管理マネージャ２１１が行う処理としては、例えば、イベントをスケジュールの１つとして登録する、そのイベントの実行時刻になったら、ユーザに通知するなどの処理がある。センシングマネージャ２１２は、センシング部６１（図３）の各部を制御し、各センサから得られた情報の解析を行う。センシングマネージャ２１２により得られた情報は、イベント管理マネージャ２１１に供給される。

ビューマネージャ２１３は、表示部１０１（図４）の表示の制御、例えば、ユーザインタフェースの制御を行う。ネットワークマネージャ２１４は、ネットワーク１やネットワーク２を介して授受されるメールやメッセージに関する処理（詳細は後述するが、メールやメッセージは、ここではイベントに関するものである）を制御する。

ＤＢマネージャ２１５は、記憶部２８（図２）に記憶されているデータベースへのデータの書き込みやデータの読み出しを制御する。データベースとして管理されているデータは、イベントに関する情報や、メールアドレスなどのデータである。趣味趣向分析マネージャ２１６は、ユーザの趣味や趣向を、ユーザが入力したデータや、ユーザの指示により取得したデータなどから解析し、データベースとして管理する。

［アプリケーションが起動されたときの画面例］
ユーザにより、このアプリケーション２０１の起動が指示され、ＣＰＵ２１により起動されたときに、表示部１０１に表示される画面について説明する。図６は、表示部１０１に表示される画面の一例を示す図である。図６に示した画面は、アプリケーション２０１が起動されたときの初期画面（メイン画面）である。初期画面には、カレンダー表示部３０１、伝言板表示部３０２、情報表示部３０３が設けられている。

なお、図６に示し、以下に説明を加える画面は、一例であり、限定を示すものではない。また、ユーザにより、表示させる項目や、表示サイズ、画面構成などはカスタマイズできるようになっている。

カレンダー表示部３０１には、カレンダーが表示され、各日付には、イベントが設定されていることを示すマークや、イベントが実行されたときに撮像された写真（好みの写真）などが表示される。また、現時点での日付がわかるように、現時点（図６においては１４日）を含み現時点より前の日付と、後の時点での日付とで、色が分けられて表示される。

伝言板表示部３０２には、現時点に関係があるメールの内容やメッセージの内容などが表示される。情報表示部３０３には、さまざまな情報が表示される。図６に示した例では、電車の情報、天気の情報、および時刻の情報が表示されている。この情報は、ユーザ（端末３）が位置する情報に依存して更新される。例えば、ユーザが駅にいると判断されるときには、図６に示したように、電車の情報が取得され、表示される。また、情報表示部３０３にどのような情報を表示させるかは、ユーザにより予め設定できるように構成されている。

情報表示部３０３に電車に関する情報が表示される場合を例に挙げて、表示させるデータの取得に関して、図７のフローチャートを参照して説明する。まず、ステップＳ１１において、センシングマネージャ２１２が位置情報取得部７１から、位置情報を取得する。ステップＳ１２において、イベント管理マネージャ２１１は、取得された位置情報を、記憶している地図データ（不図示）と照らし合わし、端末３（自己）がどの位置に存在しているのかを検索する。

ここでは、その検索結果が、駅であると判断されたとする。ステップＳ１３において、センシングマネージャ２１２が時刻情報取得部７２から、時刻情報を取得する。取得された時刻情報は、イベント管理マネージャ２１１に供給される。このように、現在位置と時刻が判別された場合、ステップＳ１４において、イベント管理マネージャ２１１は、ネットワークマネージャ２１４に指示を出し、ネットワーク１に接続されている所定のサーバに接続を開始させる。このとき接続されるサーバは、この場合、現在位置が駅であると判別されているため、その駅の時刻表に関する情報を提供しているサーバである。

ステップＳ１５において、位置と時刻に対応した情報、この場合、端末３が位置している駅に対応する時刻表から、その時刻に最も近い後の時刻に発車する電車の情報が取得される。ネットワークマネージャ２１４により取得された情報は、ビューマネージャ２１３に供給され、ビューマネージャ２１３は、供給された情報を、情報表示部３０３の設定されている位置に表示させる。このようにして、ユーザ（端末３）が位置する場所や時刻に対応した情報が取得され、ユーザに提供される。

図６に示した画面例の情報表示部３０３には、天気に関する情報も表示されている。この天気に関する情報も、端末３が位置する場所が特定され、その特定された場所の天気の情報が、予め設定されているサーバから取得される。

このような処理が実行されることによりユーザは、何の操作を実行しなくても、その時点で必要とされる情報を取得することが可能となる。よって、端末３（アプリケーション２０１）の使い勝手を向上させることが可能となる。

次に、スケジュールとして、イベントを登録し、その登録されたイベントを実行（通知）するまでの処理について説明する。

［イベント登録に係わる画面］
まず、イベントの登録に係わる画面について説明する。図８は、イベントを登録するときに、表示部１０１に表示されるウィンドウ３２１の一例を示す図である。このイベントを登録するためのウィンドウ３２１は、例えば、カレンダー表示部３０１（図６）上で、イベントを登録したい日付上にカーソル３０４を位置させた状態で、マウス８２（図３）のダブルクリックなどの所定の操作が行われたときに表示部１０１上に表示される。または、イベントを登録するためのボタンを表示部１０１に表示される画面上に設け、そのボタンが操作されたときに、ウィンドウ３２１が表示されるようにしても勿論良い。

ウィンドウ３２１には、イベントのタイトルが入力されるイベントタイトル欄３３１、イベントが実行される日付が入力される日付欄３３２、イベントが開始される時刻が入力される開始時刻欄３３３、その開始時刻に他のイベントが設定されているときに、ウィンドウ３２１で設定しているイベントが、他のイベントよりも優先して実行されるべきか否かを優先度として設定する優先度欄３３４、イベントの終了時刻が設定される終了時刻欄３３５、および、イベントが実行される場所が入力される場所欄３３６が設けられている。

また、ウィンドウ３２１には、イベントの実行時刻（開始時刻欄３３３で設定された時刻）になったときに、ユーザにそのことを通知する際、どのように通知するかを設定するリマインド欄３３７が設けられている。図８に示したリマインド欄３３７には、“おまかせ”という項目と“手動指定”という項目が設けられている。“おまかせ”という項目が選択された場合、通知を実際に行うときの状況が判断され、その状況に適した方法で通知がなされる。“手動指定”という項目が選択された場合、ユーザが設定した方法で、通知がなされる。

ウィンドウ３２１には、イベントが実行されるときに開かれるファイルを設定できる関連ファイル欄３３８、そのファイルをメールなどで送信する際、または、送信先で許可なくファイルが開かれることがないようにさせる際、暗号化の処理を施すか否かを設定する暗号化欄３３９、実行条件を設定する際に操作される実行条件設定ボタン３４０、適用条件などが入力されるサマリー欄３４１、および、イベント（予定）を複数のユーザと共有するときに操作される共有ボタン３４２が設けられている。

実行条件設定ボタン３４０が操作された場合、図９に示したようなウィンドウ３２２が表示部１０１に表示される。ウィンドウ３２２には、イベントが実行される位置を設定するための位置設定欄３５１が設けられている。この位置設定欄３５１には、直接的に、緯度や経度を入力できるように構成されている。また、“ＭＡＰ”というボタンも設けられており、このＭＡＰボタンが操作されると、地図が別ウィンドウに表示され、その地図から位置を選択できるようにも構成されている。

また、ウィンドウ３２２には、このイベントを実行する場所などを入力する実行シーン欄３５２，３５３や、イベントを実行するときの同伴者を入力するための同伴者欄３５４も設けられている。この同伴者は、“アドレス帳”というボタン３５６が操作されることにより表示されるアドレス帳内から選択することも可能に設定されている。このような各欄により設定された、位置、シーン、同伴者などの条件がそろった状態でなければ、イベントが実行されない（指定されたファイルがオープンされることがない）ようにすることが可能なように構成されている。

さらに、ウィンドウ３２２には、位置、シーン、同伴者などの条件がそろった状態でなければイベントが実行されないようにするか、または、そのような条件が多少そろっていない状態でも、イベントが実行されるようにするかを設定するためのチェック欄３５７（“設定をあいまいにする”というコメントの横に設けられているチェック欄３５７）も設けられている。

ウィンドウ３２２の各欄で設定された条件で良いときに操作される決定ボタン３５８と、設定した条件をキャンセルするときに操作されるキャンセルボタン３５９も設けられている。

図８のウィンドウ３２１の説明に戻り、共有ボタン３４２が操作された場合、図１０Ａまたは図１０Ｂに示したウィンドウが表示される。共有ボタン３４２は、複数のユーザとイベントを共有するときに操作されるボタンであるが、共有するにあたり、そのイベントについて共有する他のユーザに知らせる必要がある。他のユーザに知らせる手段としては、ここでは、メッセンジャーと電子メールの２つがあるとして説明する。

なお、ここでは、メッセンジャーとは、アプリケーション２０１（図５）により実現される機能であり、同一のアプリケーション２０１を起動させている装置間で、直接的にデータの授受が行える機能であるとし、ネットワークマネージャ２１４が、その通信の制御を行うとする。

共有ボタン３４２が操作されると、メッセンジャーで送信するか、電子メール（以下、メールと記述する）で送信するかを選択するためのメニュー（不図示）が表示される。そのメニューから“メッセンジャー”という項目が選択されると、図１０Ａに示したように、メッセンジャーでイベントに関する情報を送信できるユーザの一覧が表示される。同様に、“メール”という項目が選択されると、図１０Ｂに示したように、メールでイベントに関する情報を送信できるユーザの一覧（この場合、アドレス帳と同様のものとすることができる）が表示される。

図１０Ａに示した一覧には、ユーザ名（例えば、ユーザのフルネームでも良いし、ニックネームなどでも良い）が表示され、各ユーザを選択するためのチェックボタンが設けられている。同様に、図１０Ｂに示した一覧には、ユーザ名とそのユーザ名に対応するメールアドレスが表示され、各ユーザを選択するためのチェックボタンが設けられている。イベントを設定したユーザは、そのイベントを共有したいユーザを、各一覧から、チェックボタンをチェックすることにより選択することができる。

次に、イベントが登録されるときの処理について説明する。

［イベントの登録に係わる処理について］
まず、図１１のフローチャートを参照し、イベントを共有するときに、そのイベントを登録する側（イベントが登録されたことを他のユーザに知らせる側）の処理について説明する。前提とし、図８や図９に示したウィンドウ３２１，３２２により、イベントに関する情報は、既に設定されており、ユーザにより、共有ボタン３４２（図８）が操作されたとする。

イベント管理マネージャ２１１は、ビューマネージャ２１３から、共有ボタン３４２が操作されることにより、イベントが共有されることが指示されたとの情報が供給される。その情報には、イベント内容を他のユーザにメッセンジャーで通知するか、メールで通知するかの情報も含まれている。そこで、イベント管理マネージャ２１１は、ステップＳ３１において、メッセンジャーでイベント内容を送信すると指示が来たか否かを判断する。

ステップ３１において、メッセンジャーでイベント内容（以下、適宜、メッセージと記述する）を他のユーザに送信するという指示が来たと判断された場合、ステップＳ３２に処理が進められ、ネットワーク上の同アプリケーションへの問い合わせが行われる。メッセンジャーによりイベント内容が送付される際、ネットワークに接続され、アプリケーション２０１が起動され、メッセージの授受を行える状態にある端末が存在するか否かが判断される。

ネットワークマネージャ２１４は、他の端末に対して、メッセージを送信できる状態にあるか否かを問い合わす機能と、他の端末から、そのような問い合わせが来たときに応答する機能を有する。

ネットワークマネージャ２１４は、問い合わせに対して応答してきた端末のＩＰアドレスを、ステップＳ３３の処理として受信する。ステップＳ３４において、ビューマネージャ２１３は、ネットワークマネージャ２１４から供給されるＩＰアドレスなどの情報を基に、必要に応じ、ＤＢマネージャ２１５に指示を出し、データベースを参照しながら、接続可能（メッセージの送信が可能）な端末をリスト化する。

リスト化された結果は、例えば、図１０Ａのような一覧として表示部１０１に表示されることにより、ユーザに提供される。その一覧から、ユーザによりメッセージの送信先としてのユーザが選択されると、その情報は、ビューマネージャ２１３から、ネットワークマネージャ２１４に供給される。

ステップＳ３６において、イベント管理マネージャ２１１により、イベントフィルの作成が行われる。イベントファイルは、図８に示したウィンドウ３２１や図９に示したウィンドウ３２２で、ユーザが設定した事項に基づいて作成される。作成されるイベントファイルの一例を図１２に示す。図１２において、図中左側の連番は、説明のために付したものである。

イベントファイルは、例えば、ｉＣａｌｅｎｄｅｒの規格に基づくものとすることができ、図１２に示したイベントファイルは、ｉＣａｌｅｎｄｅｒの規格に基づいたものである。図８に示したウィンドウ３２１と、図１２に示したイベントファイルを参照するに、イベントタイトル欄３３１に入力されたタイトルは、１５行目に記載されている。日付欄３３２に入力された日付、開始時刻欄３３３に入力された開示時刻、および、終了時刻欄３３５に入力された終了時刻は、６行目と７行目に記載されている。

優先度欄３３４に入力（選択）された優先度は、１６行目に記載されている。場所欄３３６に記載された場所に関する情報は、８行目に記載されている。リマインド欄３３７に入力されたリマインドの仕方に関する情報は、１８乃至２２行目に記載されている。関連ファイル欄に入力（選択）された関連ファイル（イベント実行時にオープンされるファイル）に関する情報は、２３乃至２６行目に記載されている。

図１２に示したイベントファイルの一例には、図９において設定された実行条件として設定された事項に関しての記載はされていないが、実行条件として設定された事項に関しても、設定されている場合には、イベントファイル内に、その情報が記載される。その形式は、２３乃至２６行目に記載のある関連ファイルの情報と同様の形式で記載される（すなわち、SENSEINFOとして記載される）。

このようなイベントファイルが、イベント管理マネージャ２１１により作成されると、ステップＳ３７（図１１）において、ネットワークマネージャ２１４の制御により、作成されたイベントファイルが、ステップＳ３５において送信先として選択されたユーザに対して送信される。

このようにして、メッセンジャーにより、イベントを共有したい複数のユーザに対して、メッセージ（イベント内容）が送信される。

一方、ステップＳ３１において、イベント管理マネージャ２１１が、ビューマネージャ２１３から供給された情報が示す内容は、メールでイベント内容を送信するという指示であったと判断した場合、ステップＳ３８に処理が進められる。ステップＳ３８において、送信先の選択が行われる。この選択は、ユーザ側に、図１０Ｂに示したユーザ名やメールアドレスが記載された一覧表が提示され、その提示された一覧表でチェックされた項目に関する情報が取得されることにより行われる。

すなわち、ビューマネージャ２１３は、どの項目（ユーザ名、メールアドレス）が送信先として選択されたかの情報を取得し、その取得した情報を、ネットワークマネージャ２１４に供給する。そして、ネットワークマネージャ２１４は、その取得した情報を基に、イベント内容を送信する送信先を設定する。そしてネットワークマネージャ２１４は、ステップＳ３９において、イベントファイル（ステップＳ３６で作成される）が、添付ファイルとして送信されるように設定する。

そして、ステップＳ３６において、イベント管理マネージャ２１１により、イベントファイルが作成される。この処理については、既に説明したので省略する。イベントファイルが作成されると、ステップＳ３７において、送信先として設定されたユーザ（端末）に対して、作成されたイベントファイルが、添付ファイルとして送信される。

このようにして、メールにより、イベントを共有したい複数のユーザに対して、イベント内容が送信される。

このようにして送信されたイベントファイルを受信した受信側の処理について、図１３のフローチャートを参照して説明する。

ステップＳ６１において、イベントファイルを受信した側の端末は、そのイベントファイルをメールで受信したか否かを判断する。ステップＳ６１において、イベントファイルは、メールで受信されたと判断された場合、ステップＳ６２において、メールに添付されているイベントファイルがオープンされる。

メールでイベントファイルが受信される場合、通常、メーラなどと称されるアプリケーションによる処理で、メールの受信が制御される。そして、メーラによりメールが受信されたときには、イベントファイルが添付されているメール以外のメールも、イベントファイルが添付されているメールと同等に扱われ、受信処理がなされる。

そのような状況のときに、メールに添付されていたイベントファイルが、ユーザの指示に基づいて（または、端末側の判断でユーザの手を煩わすことなく）オープンされることにより、メールに添付されていたファイルはイベントファイルであることが認識される。イベントファイルと認識されることにより、そのイベントファイルを処理するためのアプリケーション、すなわちこの場合、アプリケーション２０１（図５）が起動される（ステップＳ６３）。

アプリケーション２０１が起動されると、ステップＳ６４において、イベント管理マネージャ２１１により、イベントファイルのチェックが行われる。ステップＳ６４への処理には、ステップＳ６１において、イベントファイルはメールで受信されたのではないと判断された場合、換言すれば、メッセンジャーでイベントファイルが受信されたと判断された場合もくる。

メッセンジャーによりイベントファイルが受信されたと判断されるときには、すでに、アプリケーション２０１は起動されている状態なので、メールでイベントファイルが受信されたときに行われるステップＳ６２やステップＳ６３の処理は、実行される必要がないのでスキップされ、ステップＳ６４に処理が進められる。ステップＳ６４において、イベントファイルのチェックがイベント管理マネージャ２１１により行われると、ステップＳ６５に処理が進められる。

ステップＳ６４において、イベント管理マネージャ２１１はチェックした内容を、ビューマネージャ２１３に供給する。ビューマネージャ２１３は、供給された内容を基に、イベント内容を示すテキストデータや画像データを生成し、表示部１０１に表示させる。このようにして、イベントファイルの内容が表示部１０１に表示されることにより、イベントファイルが送信された側、換言すれば、イベントを共有するように誘われた側は、その誘われたイベントの内容を確認することができる。

イベントの共有を誘われた側のユーザは、そのイベントを共有するか否かの判断を行う。図示はしないが、例えば、表示されているイベント内容のウィンドウに、“承認”というボタンと、“非承認”というボタンを設け、どちらかのボタンが操作されることにより、ユーザの判断が反映される仕組みが構築されている。

ユーザがイベントの共有を承認するか否かの判断結果として、ボタンが操作されると、その情報は、ビューマネージャ２１３により処理される。ビューマネージャ２１３は、供給された情報を、イベント管理マネージャ２１１に供給する。イベント管理マネージャ２１１は、ステップＳ６６において、供給された情報を参照し、ユーザがイベントの共有を承認したか否かを判断する。

ステップＳ６６において、イベントの共有が承認されたと判断された場合、ステップＳ６７に進み、承認されたイベントの情報が、イベント管理マネージャ２１１からＤＢマネージャ２１５に供給され、ＤＢマネージャ２１５により、新たなイベントがスケジュールＤＢ（データベース）に保存（登録）される。

一方、ステップＳ６６において、イベントは非承認であったと判断された場合、ステップＳ６８に処理が進められ、非承認されたことを、イベントの共有を求めてきたユーザに対して通知する。例えば、メールでイベントファイルが送信されてきたときには、メールで、メッセンジャーでイベントファイルが送信されてきたときには、メッセンジャーで、非承認であることの通知がされる。

このようにして、イベントの共有を求められた側の処理が実行されることにより、イベントを簡単な処理で共有することが可能となる。

ステップＳ６７の処理で、イベントが承認されると、そのイベントがスケジュールＤＢに登録されるが、その登録先であるスケジュールＤＢの一例を図１４に示す。スケジュールＤＢ４０１は、図１４に示すように、イベント内容を一意に識別できるように割り当てられた“イベントNo”、そのイベントの“開始時刻”、イベントが実行される“場所”、イベントの開始時刻になったら、そのことを通知する設定がされているか否かを示す“通知”、イベントの内容を示す“内容”、イベント実行時に開かれる“アプリケーション”といった項目が設けられている。

これらの各項目に記載される情報は、イベントファイルから読み取られる。図１４に示したのは、スケジュールＤＢに設けられている項目のうちの一部であり、他に、イベントの終了時間など、イベントファイルに記載されている情報を記載する項目も設けられ、それぞれの項目に情報が記載される。

次に、このようなスケジュールＤＢ４０１に登録されているイベントの実行に関する処理について説明を加える。

「イベントの実行に係わる処理」
図１５に示したフローチャートを参照し、イベントの実行に係わる処理について説明する。ステップＳ８１において、イベント管理マネージャ２１１は、スケジュールＤＢ４０１に記載されているスケジュール（イベント）を確認する。ステップＳ８２において、通知が設定されているイベントがあるか否かを判断する。この判断は、スケジュールＤＢの“通知”という欄を参照することにより行われる。

例えば、図１４においては、通知が設定されているイベントの対応する欄には“○”が記載され、通知が設定されていないイベントに対応する欄には“×”が記載されている。また、ユーザにより通知の方法が設定されている場合には、その設定されている通知方法が記載される。

ステップＳ８２において、通知が設定されている（通知方法が記載されている）イベントがあると判断された場合、ステップＳ８３に処理が進められ、通知が設定されているイベントはないと判断された場合、ステップＳ８８に処理が進められる。

ステップＳ８３において、イベントの通知時刻まで待機状態が維持される。イベントの通知時刻は、イベントの開始時刻より所定の時間（例えば、５分）だけ前の時刻である。なお、通知時刻は、ユーザにより、イベントの何分前に通知するかなど設定できるような仕組みが設けられており、その設定されている時刻に通知がされる。

通知時刻になると、ステップＳ８４において、センシング情報の取得が行われる。センシングマネージャ２１２（図５）は、センシング部６１（図３）の各部からセンシング情報を取得する。取得されたセンシング情報に基づき、イベント管理マネージャ２１１は、ステップＳ８５において、状態通知が可能な状況であるか否かを判断する。

状態通知が可能な状況であるか否かの判断は、ユーザ（端末）が存在する周りの状況が考慮され、また、イベント内容が考慮されて行われる。まず、イベント内容は、スケジュールＤＢの“内容”の欄に記載されている情報（テキスト）が解析され、内部に備えられている辞書機能とマッチングされることにより認識される。その認識されたイベント内容を、ユーザに通知すべきか否かが判断される。

例えば、認識されたイベント内容が、“会議”であったような場合、通知を実行しようとしたとき（すなわち、ステップＳ８５の処理が実行されるとき）に、既にユーザは会議に出席している、会議室に向かっているなどの状況のときには、ユーザに会議が始まることを通知する必要はない。よって、そのようなときは、イベントの通知は可能な状態ではない（通知する必要はない）と判断される。

この“会議”の例を用いて、さらに説明を加える。イベント内容が“会議”であると判断されたとき、既にユーザが会議に出席しているかなどの状況を判断するために、センシング情報が用いられる。スケジュールＤＢ４０１には、イベントが行われる場所についての情報も記載されている。場所が記載されていることから、その場所の緯度や経度を取得することが可能である。

この場合、“会議室”の緯度や経度が、例えば地図データなどから予め取得されていれば、位置情報取得部７１（図３）により取得される位置情報と照らし合わせることにより、ユーザが会議室に居るか否かを判断することができる。

地図データなどから会議室の位置情報を取得できなくても、過去に、会議というイベントがあり、そのイベントが実行されたときに、位置情報取得部７１により位置情報が取得され、その取得された位置情報を記憶しておき、その記憶された位置情報を、会議室の位置情報として用いるようにしても良い。本実施の形態においては、そのようなことを実現するために、ステップＳ９３において、センシング情報を保存するようにしている。

また、位置情報が取得できない時などには、音情報取得部７３により取得される音情報を用いて会議室にユーザが居るか否かの判断が行われるようにしても良い。例えば、会議室であれば、車や電車などからの発せられる雑音は少なく、会議前であれば、人の話し声も少ないと考えられ、また会議中であれば、人の話し声が中心となっているはずであると考えられるため、このような特徴を見いだし、取得される音情報を解析すれば、音情報からもユーザの位置をある程度の精度で認識できる。

また逆に、“会議”というイベントの内容のときに、取得された音情報から、電車の音がするといったようなとき、少なくとも会議室にはユーザは居ないと判断することができる。よって、“会議”というイベントの内容のときに、ユーザは会議室に居ないことを認識し、ユーザは会議室に居ないので会議の開始時刻が通知すべきであると判断されるようにしても良い。

また、画像情報取得部７４により取得される画像情報を用いて、会議室にユーザが居るか否かの判断が行われるようにしても良い。例えば、会議室には、机があり、椅子があり、ホワイトボードなどがあるといった、ある程度、会議室という状況は一般化でき、その一般化された会議室の画像情報を記憶しておくようにし、その記憶されている画像情報と、取得される画像情報を、画像マッチングすることにより、ある程度の確率でユーザが会議室に居るか否かの判断を行うことができる。

この場合も音情報のときと同様に、取得される画像情報から、ユーザは、会議室には居ないことが認識できれば、通知を行うようにしても良い。

位置情報と同じく、以前、会議が行われたときに会議室の画像を取得し、記憶しておけば、その画像情報を用いてマッチング処理を実行することができる。そのようにすれば、会議室であるか否かの判断をより精度良く行うことが可能である。

さらに、天気情報取得部７５により取得される天候に関する情報も用いられるようにしても良い。会議室であれば、空調があるため、２５度などの気温に保たれていることが多い。そこで、そのような情報を利用することにより、ユーザの居場所を判断するようにしても良い。

このように、センシング情報を用いれば、ユーザが居る場所を特定することができる。１つのセンシング情報だけを用いるよりも、複数のセンシング情報を用いて判断するようにすれば、より精度良く、ユーザが居る場所を特定することができるようになる。

このようにして、ユーザの居る場所を特定し、その特定された場所で、イベントの開始時刻になったことを通知すべきか否かが、ステップＳ８５の処理として実行される。ステップＳ８５において、通知をすると判断された場合、ステップＳ８６に処理が進められ、通知はしないと判断された場合、ステップＳ８８に処理が進められる。

ステップＳ８６において、通知の方法が選択される。ユーザが通知の方法を設定していた場合、すなわち上述したように、図８に示したようなイベントを登録するためのウィンドウ３２１のリマインド欄３３７において、“手動指定”という項目が選択されていたときには、ユーザが通知の方法を設定していると判断され、その設定されている方法に、通知方法が決定される。

一方、リマインド欄３３７において、“おまかせ”という項目が選択されたときには、そのときの状況に適した通知方法が選択される。例えば、音情報取得部７３により取得された音情報が、静穏な状況（音が少ない状況）を示しているような場合、音で通知を行うと、周りの人々に迷惑がかかると考えられるので、光や振動で通知が行われるようにする。また、音情報から、ノイズ音量の大小を判断し、ノイズが多いときには公共の場に居ると判断し、ノイズが少ないときにはプライベートの場に居ると判断するようにし、公共の場に適したまたはプライベートの場に適した通知方法が選択されるようにする。

また、音で通知をすると決定された場合も、取得される音情報に基づき、通知する際の音量を変化させる（調整される）ようにしても良い。

また、画像情報取得部７４により取得された画像情報が、暗い状況（例えば、映画館）を示しているような場合、光で通知すると、周りの人々に迷惑がかかるので、振動で通知が行われるようにする。

また、天気情報取得部７５により取得される気温や湿度の情報から、屋内に居るのか屋外に居るのかが判断されるようにし、屋内であれば音で、屋外であれば、振動で通知が行われるようにしても良い。

このように、センシング部６１の各部から取得される情報を用い、ユーザの周りの状況を判断し、その状況に応じた通知方法が選択される。なお、センシング情報を複数用い、その判断結果を利用することにより、より正確な状況判断、および、より適切な通知方法の選択が行えるようになる。

通知方法として、音で通知すると決定された場合、スピーカ１０２（図４）から音が発せられることにより通知が行われる。通知方法として、光で通知すると決定された場合、発光部１０３（図４）から光が発せられることにより通知が行われる。通知方法として、振動で通知すると決定された場合、振動部１０４（図４）により振動が発せられることにより通知が行われる。これらの通知と併せて、または、単独で、表示部１０１により、ユーザに“イベントが開始される時刻です”といったメッセージが表示されることにより通知がなされるようにしても良い。

また、イベントの開始を通知するだけでなく、例えば、通知する時点で、ユーザがイベントが開始される場所（目的地）に存在せず、別の場所（現在地）に居ると判断されるような場合、現在地から目的地までの道順を示す地図を表示させるようにしても良い。

また、通知の方法が決定される際、ユーザの過去の操作履歴を考慮して決定されるようにしても良い。例えば、過去にユーザが、通知方法を指定していたような場合には、その指定していた通知方法を保存するようにする。また、実際に通知が行われた際にユーザが行った処理も保存するようにする。通知が行われた際にユーザが行った処理とは、例えば、音量を下げた、振動を中止した、発光を中止した、表示部１０１に表示されていた画面を閉じたなどである。このような、ユーザが指定したこと、ユーザが行った処理を保存することにより、学習し、より適切にユーザの好みにあった通知方法が決定されるようにしても良い。

このような複数のセンシング情報を用いて所定の結果を取得する手法や学習の手法としては、クラスタリングやBaysian Networkといった確率モデルを利用したアルゴリズムを利用することで、よりニーズにあった通知を行うことができる。

このようにして、通知方法が決定されると、ステップＳ８７に処理が進められ、決定された通知方法で、ユーザに対して、イベントの開始時刻になった（開始時刻が近づいた）ことが通知される。そして、ステップＳ８８に処理が進められる。

ステップＳ８８において、アプリケーションが必要なイベントであるか否かが判断される。スケジュールＤＢが参照され、アプリケーションという欄に記載があるか否かが判断されることにより、ステップＳ８８における処理が実行される。ステップＳ８８において、アプリケーションが必要なイベントであると判断された場合、ステップＳ８９に処理が進められ、アプリケーションは必要ないイベントであると判断された場合、ステップＳ９３に処理が進められる。

ステップＳ８９において、イベント実行時間まで待機状態が維持される。そして、イベント実行時間になったと判断された場合、ステップＳ９０において、センシング情報が取得される。このセンシング情報の取得は、基本的に、ステップＳ８４において行われるセンシング情報の取得と同様に行われる。ただし、ステップＳ９０において取得されるセンシング情報は、アプリケーションを起動させる際の条件（状況）として、例えば、図９のウィンドウ３２２で設定されたことを確認するために取得される情報である。

すなわち、ステップＳ９１において、取得されたセンシング情報が用いられ、アプリケーションの起動が可能な状況（許可される状況）であるか否かが判断される。このような判断が行えるようにするための情報が、ステップＳ９０において取得される。

図９を再度参照するに、実行条件として、まず、位置に関する設定がある。位置に関する設定がされていた場合、位置情報取得部７１（図３）により取得される位置情報が用いられ、その設定されている位置に関する条件を満たすか否かが判断される。また、実行シーンが設定されていた場合も、同様に、位置情報が取得され、その位置情報による判断結果が用いられ、実行条件を満たすか否かが判断される。

また、同伴者に関する設定がされていた場合、所定の範囲内に存在する他の端末と通信を行い、ＩＰアドレスなどが取得されることにより、その端末（ユーザ）が判断され、その判断結果を参照し、同伴者に関する設定が満たされているか否かが判断される。

または、音情報取得部７３により取得される音情報を解析し、同伴者として設定されているユーザの声であるか否かを判断することにより、条件が満たされているか否かが判断されるようにしても良い。同様に、画像情報取得部７４により取得される画像情報と、既に記憶されているユーザの画像情報をマッチング処理することにより、同伴者を判断し、条件が満たされているか否かを判断するようにしても良い。

このように、実行条件として設定されている条件が満たされているか否かを判断するために、センシング情報が取得される。ステップＳ９１において、センシング情報が取得され、設定されている実行条件が満たされていると判断されたときには、ステップＳ９２に処理が進められ、アプリケーションが起動されるが、設定されている実行条件が満たされていないと判断されたときには、アプリケーションが起動されることなく、ステップＳ９３に処理が進められる。

このように、イベント実行時にアプリケーションが起動される際、その起動に制限を持たせることが可能となる。このことにより、設定条件が満たされたときには、ユーザの手を煩わせることなく所定のアプリケーションが起動されるため、利便性が向上する。また、設定条件が満たされないときには、アプリケーションが起動されないように制限することができるので、例えば会議に出席しなかったユーザが、会議の資料（アプリケーション）を閲覧するといったようなことを防ぐことが可能となる。このようなことをさらに強化するために、アプリケーション自体を暗号化することができるように構成されていることは既に説明した。

アプリケーションが起動された場合（ステップＳ９１においてＹＥＳと判断された場合）、条件が満たされないためにアプリケーションが起動されなかった場合（ステップＳ９１においてＮＯと判断された場合）、または、アプリケーションの起動自体が必要とされていない場合（ステップＳ８８においてＮＯと判断された場合、）、ステップＳ９３に処理が進められる。

ステップＳ９３において、センシング情報が保存される。これは、上述したように、後の時点で状況判断などの処理を実行する際に用いることができるようにするためである。このように、センシング情報を保存（学習）することにより、ユーザの居る場所などの判断を、より精度良く行うことが可能となる。

このようにして、設定されているイベントがユーザに通知され、実行される。

スケジュールのイベントの１つとして、テレビジョン放送の所望の番組を視聴するといったようなことを登録することも可能である。次に、テレビジョン放送の番組の視聴に関するイベントの処理について、説明を加える。

［番組の視聴に関するイベントの登録、実行について］
番組の視聴をイベントとして登録する場合、図１６に示したようなウィンドウ３２４により、その番組の情報が入力される。ウィンドウ３２４は、イベントの内容が設定されるウィンドウ３２１（図８）とタブを切り替えることにより表示される構成とされている。ウィンドウ３２４には、番組のタイトルを入力する番組タイトル欄４０１が設けられており、直接的に番組のタイトルを入力できるように構成されている。

また、番組タイトル欄４０１の右側には、ＥＰＧ取込ボタン４０２が設けられている。ＥＰＧとは、Electric Program Guideの略であり、電子的に扱われるテレビジョン放送の番組表であり、端末２などで扱える番組表である。ＥＰＧ取込ボタン４０２が操作されると、所定のサーバに接続され、そのサーバからＥＰＧデータが取得され、その取得されたＥＰＧデータに基づく番組表が、ユーザに提示される。

ユーザは、提示された番組表から視聴したい番組を選択できるように構成されている。ユーザが視聴したい番組を選択すると、その情報が、ウィンドウ３２４の各欄に書き込まれる。例えば、ユーザが選択した番組の番組名は、番組タイトル欄４０１に記載される。ＥＰＧから、ユーザにより視聴したい番組が選択された場合、ＥＰＧデータから、番組名や放送時間などの詳細な情報を取得できるため、取得された情報を、ユーザの手を煩わすことなく、ウィンドウ３２４の各欄に記載することが可能であるが、ユーザ自身により入力する（または、ＥＰＧの取得により設定された事項を変更する）ことも可能とされている。

ウィンドウ３２４には、番組が放送される日時を入力するための日付欄４０３、開始時刻を入力するための開始時刻欄４０４、終了時刻を入力するための終了時刻欄４０５、および、番組が放送されるチャンネルを入力するチャンネル欄４０６が設けられている。

またウィンドウ３２４には、番組が放送される時刻になったときに、テレビジョン放送の番組を視聴できるソフトウェア（アプリケーション）を起動させるか否かを選択するための起動ソフトウェア欄４０７も設けられている。図１６に示したウィンドウ３２４の起動ソフトウェア欄４０７には、“おまかせセンシング”という項目と、“詳細”という項目が設けられている。“おまかせセンシング”という項目は、番組が放送される時点でのユーザの状況が判断されて、ソフトウェアの起動がされるようにするときに選択される項目であり、“詳細”という項目は、ユーザによりソフトウェアの起動の仕方が設定されるときに選択される項目である。

ウィンドウ３２４には、必要に応じ、ユーザが情報を書き込めるサマリー欄４０８も設けられている。さらに、ウィンドウ３２４には、この番組の情報を共有するときに操作される共有ボタン４０９も設けられている。この共有ボタン４０９は、共有ボタン３４２（図８）と同様の機能を有する。すなわち、共有ボタン４０９が操作されると、メールまたはメッセンジャーで、複数のユーザに対して番組情報が送信される。また、その際、番組情報は、図１２に示したようなイベントファイルと同様なデータ構成のファイルとして各ユーザ（端末）に対して送信される。

番組情報が共有される場合の処理については、イベントが共有される場合の処理と、基本的に同様に行われるため、ここでは、その説明は省略する。

次に、このようなウィンドウ３２４で設定された番組が、スケジュールのイベントとして実行される際の処理について説明する。

［番組視聴に関する処理］
図１７のフローチャートを参照して、イベントとして登録された番組の視聴に係わる処理について説明する。ステップＳ１１１において、ウィンドウ３２４が参照されながら、ユーザにより番組情報が入力されると、その情報は、ビューマネージャ２１３からイベント管理マネージャ２１１に供給される。

イベント管理マネージャ２１１は、ステップＳ１１２において、スケジュールＤＢ４０１を参照して、重複するイベントが既に登録されているか否かを判断する。ステップＳ１１２において、重複するイベントはないと判断された場合、ステップＳ１１３に処理が進められ、イベントの登録処理が実行される。すなわち、スケジュールＤＢ４０１に、新たなイベントとして登録される。

一方、ステップＳ１１２において、重複するイベントがあると判断された場合、ステップＳ１１４に処理が進められる。ステップＳ１１４において、録画予約の処理が実行される。ここでは、重複するイベントがあると判断されたときに、録画予約の処理が実行されるとして説明するが、重複するイベントがあるか否かにかかわらず、ユーザにより録画予約が指示されているときには、ステップＳ１１４に処理が進められ、録画予約の処理が実行される。

ウィンドウ３２４が参照されることにより、番組の視聴が、１つのイベントとして登録されるわけだが、このウィンドウ３２４が表示された装置（この場合、端末３とする）に、番組が録画されても良いし、その他の装置、例えば、ホームサーバ４（図１）に録画されても良い。ステップＳ１１４において録画予約がされるのが、ホームサーバ４である場合、ネットワークマネージャ２１４の制御でネットワーク１やネットワーク２（図１）を介して、ホームサーバ４と接続され、ホームサーバ４に対して番組情報と録画予約の指示がだされる。

また、ホームサーバ４に対して録画予約したときであっても、イベントとして、スケジュールＤＢ４０１に登録される。

ステップＳ１１５において、イベントの実行時刻になるまで、待機状態が維持され、実行時刻に達すると、ステップＳ１１６に処理が進められる。ステップＳ１１６において、センシング部６１の各部から、センシング情報が取得される。そして、ステップＳ１１７において、録画が設定されているか否かが判断される。視聴対象となっている番組に対して録画が設定されている場合、ステップＳ１１８に処理が進められ、録画が開始される。ホームサーバ４に対して録画予約がされていた場合には、単に、録画が開始されたことをユーザに通知するなどの処理がされるか、または、何の処理も実行されないようにしても良い。

一方、ステップＳ１１７において、視聴対象となっている番組に対して録画は設定されていないと判断された場合、ステップＳ１１９に処理が進められ、実行中のイベントはないか否かが判断される。番組情報が入力された時点で、重複するイベントがあるか否かは判断されている（ステップＳ１１１，Ｓ１１２の処理）が、その後、新たなイベントが登録され、そのイベントが実行されている可能性があるため、また、重複はしていなかったが、イベントの終了時刻が遅れ、結果として、実行中であると判断されるイベントがある可能性があるため、ステップＳ１１９において、実行中のイベントがあるか否かが判断される。

ステップＳ１１９において、実行中のイベントはないと判断された場合、ステップＳ１２０に処理が進められる。ステップＳ１２０において、ユーザは自宅に居るか否かが判断される。この判断は、ステップＳ１１６において取得されたセンシング情報が用いられて行われる。また、この判断は、図１５のステップＳ８５の処理（センシング情報を取得し、そのセンシング情報からユーザの周りの状況（位置など）を判断し、イベント発生に関すする通知を行うか否かの判断）と同様に行われる。よって、ここでは、ステップＳ１２０において行われる処理についての詳細な説明は省略する。

ステップＳ１２０において、ユーザは、自宅に居る（端末は自宅にある）と判断された場合、ステップＳ１２１に処理が進められ、番組を視聴するためのアプリケーションが起動される。ユーザは、番組を視聴するためのアプリケーションが起動され、番組が表示されれば、その番組を視聴したいとして登録していたことを思い出し、視聴を開始する。よって、視聴したいと所望していた番組を見逃してしまうような不都合が発生することを防ぐことが可能となる。

また、ここでは、ステップＳ１２１において、テレビジョン放送の番組を視聴するためのアプリケーションが起動されるとして説明したが、ユーザに対して通知するだけでも良い。ユーザが自宅に居ると判断されているので、自宅に設置されているテレビジョン受像機で番組を視聴することも可能であり、そのように仕向けるだけでも、ユーザが視聴したいと所望していた番組を見逃してしまうような不都合が発生することを防ぐことは、可能である。

一方、ステップＳ１２０において、ユーザは自宅に居ないと判断された場合、ステップＳ１２２に処理が進められる。ステップＳ１２２において、ネットワークに接続可能であるか否かが判断される。ステップＳ１２２においてネットワークに接続可能であると判断された場合、ステップＳ１２３に処理が進められる。ステップＳ１２３において、ネットワーク経由で、テレビジョン放送を視聴するためのアプリケーションが起動される。このように、ネットワークに接続できる状態であれば、自宅にいなくても（例えば、帰宅途中）、視聴を所望していた番組を見逃してしまうような不都合が発生することを防ぐことが可能となる。

一方、ステップＳ１９において、実行中のイベントがあると判断された場合、ステップＳ１１８に処理が進められる。この場合、ステップＳ１１７において、録画設定されていないと判断された番組であり、実行中のイベントがあるという状況であると考えられる。よって、ユーザは、その時点で番組を視聴することができないが、録画予約もしていないため、結果として、視聴を所望した番組を視聴できない可能性がある。そこで、ステップＳ１１８において、録画を開始する。

このステップＳ１１８における録画は、ステップＳ１１４において録画予約の処理が実行されるときと同様な処理が実行されることにより行われる。すなわち、録画自体を端末３で行う場合には、番組を受信し、録画を開始するといった処理が行われ、録画自体はホームサーバ４で実行させるという場合には、ホームサーバ４に対して番組情報と、録画を開始させる指示を出すといった処理が行われる。

このようにすれば、ユーザが視聴したい番組を視聴できない状態になったときでも、その番組を録画することができるため、結果として、ユーザが視聴を所望した番組を視聴できないといったような不都合が発生するようなことを防ぐことが可能となる。

なお、ここでは、テレビジョン放送の番組を視聴することを例に挙げて説明したが、テレビジョン放送の番組の視聴以外にも、本発明を適用すれば、イベントとして設定されていることをユーザがし忘れてしまうといったようなことを防ぐことが可能となる。

このように、本発明によれば、予め登録しておいたイベントが実際に実行される際、そのときの状況に応じた処理を適切に行えるようにすることができる。

［記録媒体について］
上述した一連の処理、例えば、イベントの登録や通知の処理などは、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。

記録媒体は、図２に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フレキシブルディスクを含む）、光ディスク４２（CD-ROM（Compact Disc-Read Only Memory），DVD（Digital Versatile Disc）を含む）、光磁気ディスク４３（MD（Mini-Disc）（登録商標）を含む）、若しくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ２２や記憶部２８が含まれるハードディスクなどで構成される。

なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

本発明を適用したシステムの一実施の形態の構成を示す図である。 端末の内部構成例を示す図である。 入力部の詳細な構成例を示す図である。 出力部の詳細な構成例を示す図である。 端末の機能を示す図である。 表示部に表示される画面の一例を示す図である。 情報の取得に係わる処理について説明するためのフローチャートである。 表示部に表示される画面の一例を示す図である。 表示部に表示される画面の一例を示す図である。 表示部に表示される画面の一例を示す図である。 イベントの登録について説明するためのフローチャートである。 イベントファイルについて説明するための図である。 イベントの登録について説明するためのフローチャートである。 スケジュールＤＢについて説明するための図である。 イベントの実行の処理について説明するためのフローチャートである。 表示部に表示される画面の一例を示す図である。 番組視聴に係わる処理について説明するフローチャートである。

符号の説明

１，２ ネットワーク， ３ 端末， ４ ホームサーバ， ６１ センシング部， ６２ 操作部， ７１ 位置情報取得部， ７２ 時刻情報取得部， ７３ 音情報取得部， ７４ 画像情報取得部， ７５ 天気情報取得部， ８１ キーボード， ８２ マウス， １０１ 表示部， １０２ スピーカ， １０３ 発光部， １０４ 振動部， ２０１ アプリケーション， ２１１ イベント管理マネージャ， ２１２ センシングマネージャ ２１３ ビューマネージャ， ２１４ ネットワークマネージャ， ２１５ ＤＢマネージャ， ２１６ 趣味趣向分析マネージャ， ４０１ スケジュールＤＢ

Claims (8)

1. 所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定手段と、
   センシング情報を取得する取得手段と、
   前記取得手段により取得されたセンシング情報を用い、前記条件を満たすか否かを判断する判断手段と、
   前記判断手段により前記条件が満たされると判断された場合、前記所定のアプリケーションまたはファイルを起動する起動手段と
   を備えることを特徴とする情報処理装置。
2. テレビジョン放送の番組を視聴するイベントが登録された場合、前記判断手段は、前記番組を受信してよい状況であるか否かを判断し、
   前記判断手段により前記番組を受信してよい状況であると判断された場合、前記起動手段は、前記番組を視聴するためのアプリケーションを起動し、
   前記判断手段により前記番組を受信してよい状況ではないと判断された場合、前記起動手段は、前記番組を録画するためのアプリケーションを起動し、
   前記判断手段により前記番組を受信してよいが、ネットワーク経由で前記番組を受信すると判断された場合、前記起動手段は、ネットワーク経由で番組を受信するためのアプリケーションを起動する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定ステップと、
   センシング情報を取得する取得ステップと、
   前記取得ステップの処理で取得されたセンシング情報を用い、前記条件を満たすか否かを判断する判断ステップと、
   前記判断ステップの処理で前記条件が満たされると判断された場合、前記所定のアプリケーションまたはファイルを起動する起動ステップと
   を含むことを特徴とする情報処理方法。
4. 所定のアプリケーションまたはファイルが起動されるときの条件を設定する設定ステップと、
   センシング情報を取得する取得ステップと、
   前記取得ステップの処理で取得されたセンシング情報を用い、前記条件を満たすか否かを判断する判断ステップと、
   前記判断ステップの処理で前記条件が満たされると判断された場合、前記所定のアプリケーションまたはファイルを起動する起動ステップと
   を含むことを特徴とするコンピュータが読み取り可能なプログラム。
5. センシング情報を取得する取得手段と、
   前記取得手段により取得された前記センシング情報から周りの状況を判断する判断手段と、
   前記判断手段により判断された前記状況に適した通知方法を選択する選択手段と、
   前記選択手段により選択された前記通知方法で、所定のイベントの発生を通知する通知手段と
   を備えることを特徴とする情報処理装置。
6. 前記センシング情報が位置情報である場合、前記判断手段は、前記位置情報から現在地を確定し、
   前記選択手段は、前記判断手段により判断された前記現在地から、イベントが実行される場所までの地図をユーザに提示する方法を通知方法として選択する
   ことを特徴とする請求項５に記載の情報処理装置。
7. センシング情報を取得する取得ステップと、
   前記取得ステップの処理で取得された前記センシング情報から周りの状況を判断する判断ステップと、
   前記判断ステップの処理で判断された前記状況に適した通知方法を選択する選択ステップと、
   前記選択ステップの処理で選択された前記通知方法で、所定のイベントの発生を通知する通知ステップと
   を含むことを特徴とする情報処理方法。
8. センシング情報を取得する取得ステップと、
   前記取得ステップの処理で取得された前記センシング情報から周りの状況を判断する判断ステップと、
   前記判断ステップの処理で判断された前記状況に適した通知方法を選択する選択ステップと、
   前記選択ステップの処理で選択された前記通知方法で、所定のイベントの発生を通知する通知ステップと
   を含むことを特徴とするコンピュータが読み取り可能なプログラム。

Images