(57)【特許請求の範囲】
【請求項１】
電子メールの送受信に関するイベントを検出するメールイベント検出部と、
前記電子メールに含まれる情報又は添付ファイルから当該電子メールに関連するリソー
ス、又はリソースにアクセスするための情報を含むリソース情報を取得するリソース取得
部と、
前記電子メールに関連する複数のユーザのユーザ情報を取得する関連ユーザ取得部と、
前記関連ユーザ取得部が取得した複数のユーザのユーザ情報に基づいて、電子メールの
ユーザと当該ユーザのスケジュールとを関連付けたスケジュール情報を参照して、当該複
数のユーザの共通なスケジュールを抽出する共通スケジュール抽出部と、
前記リソース取得部が取得したリソース情報と前記共通スケジュール抽出部が抽出した
共通なスケジュールとを関連付けてリソース格納部に格納するリソース管理部とを備える
、情報処理装置。
【請求項２】
ユーザが現在いる場所を検出する場所検出部と、
前記場所検出部が検出した場所と前記共通スケジュール抽出部が抽出した共通なスケジ
ュールの実施される場所とが一致したときに、前記リソース格納部が関連付けて格納する
リソース情報を提示する提示部とを更に備える、請求項１に記載の情報処理装置。
【請求項３】
前記共通スケジュール抽出部は、前記スケジュール情報を参照して、複数のユーザのス
ケジュールの共通度スコアを算出し、算出した共通度スコアが所定値を超えるスケジュー
ルを、共通なスケジュールとして抽出する、請求項１又は２に記載の情報処理装置。
【請求項４】
前記リソース取得部は、前記電子メールに関連するリソースの存在の有無を判定し、リ
ソースが存在すると判定した場合に、前記共通スケジュール抽出部と前記リソース管理部
の処理を実行する、請求項１〜３のいずれかに記載の情報処理装置。
【請求項５】
前記リソース管理部は、前記電子メールをグループ化したスレッド毎に、リソース情報
をリソース格納部に格納する、請求項１〜４のいずれかに記載の情報処理装置。
【請求項６】
前記リソース管理部がリソース格納部に格納したリソース情報の利用状況、又は変更状
況を監視するリソース監視部を更に備え、
前記リソース管理部は、前記リソース監視部がリソース情報の利用、又は変更を検出し
たときに、対応するリソースの情報を更新する、請求項１〜５のいずれかに記載の情報処
理装置。
【請求項７】
ユーザのスケジュール情報の更新を検出するスケジュール情報更新監視部を更に備え、
前記共通スケジュール抽出部は、前記スケジュール情報更新監視部がスケジュール情報
の更新を検出したときに、共通度スコアの再計算を行い、再度共通なスケジュールを抽出
する、請求項３に記載の情報処理装置。
【請求項８】
前記共通スケジュール抽出部が抽出した共通なスケジュールに関連するユーザの場所状
況を取得する関連ユーザ状況取得部を更に備え、
前記提示部は、前記関連ユーザ状況取得部がユーザの場所状況変化を取得したときに、
ユーザの場所状況に対応するようにリソース情報の提示優先度を変更して提示する、請求
項２に記載の情報処理装置。
【請求項９】
ユーザから時間の入力を受付ける時間入力部を更に備え、
前記提示部は、前記時間入力部が入力を受付けた時間に対応するスケジュールに関連す
るリソース情報を提示する、請求項２に記載の情報処理装置。
【請求項１０】
前記リソース格納部を備えた端末で構成された情報処理装置であって、
他ユーザ端末と情報を送受信する他端末情報送受信部を更に備え、
前記他端末情報送受信部は、他ユーザの端末の存在を検出すると、自身の端末のリソー
ス格納部を参照してリソース情報を所有しているかどうかを判定し、所有していない場合
には、他ユーザの端末に対して、リソース情報を送信するように要求する、請求項１〜９
のいずれかに記載の情報処理装置。
【請求項１１】
コンピュータが、
電子メールの送受信に関するイベントを検出するメールイベント検出ステップと、
前記電子メールに含まれる情報又は添付ファイルから前記電子メールに関連するリ
ソース、又はリソースにアクセスするための情報を含むリソース情報を取得するリソース
取得ステップと、
前記電子メールに関連する複数のユーザのユーザ情報を取得する関連ユーザ取得ステッ
プと、
前記関連ユーザ取得ステップで取得した複数のユーザのユーザ情報に基づいて、電子メ
ールのユーザと当該ユーザのスケジュールとを関連付けたスケジュール情報を参照して、
当該複数のユーザの共通なスケジュールを抽出する共通スケジュール抽出ステップと、
前記リソース取得ステップで取得したリソース情報と前記共通スケジュール抽出ステッ
プで抽出した共通なスケジュールとを関連付けてリソース格納部に格納するリソース管理
ステップとを備える、情報処理方法。
【請求項１２】
コンピュータに、
電子メールの送受信に関するイベントを検出するメールイベント検出ステップと、
前記電子メールに含まれる情報又は添付ファイルから前記電子メールに関連するリ
ソース、又はリソースにアクセスするための情報を含むリソース情報を取得するリソース
取得ステップと、
前記電子メールに関連する複数のユーザのユーザ情報を取得する関連ユーザ取得ステッ
プと、
前記関連ユーザ取得ステップで取得した複数のユーザのユーザ情報に基づいて、電子メ
ールのユーザと当該ユーザのスケジュールとを関連付けたスケジュール情報を参照して、
当該複数のユーザの共通なスケジュールを抽出する共通スケジュール抽出ステップと、
前記リソース取得ステップで取得したリソース情報と前記共通スケジュール抽出ステッ
プで抽出した共通なスケジュールとを関連付けてリソース格納部に格納するリソース管理
ステップとを実行させる、情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールを用いた情報処理技術に関する。
【背景技術】
【０００２】
近年、紙の資料を配付せず、電子メールやファイルサーバを利用して事前に資料を電子的に配布し、会議室で参加者が自分のノートパソコンなどで参照するスタイルが定着してきた。ところが、通常、ユーザは様々な会議に出席する必要があり、それぞれの会議に関連したドキュメントを会議室で即座に探すことは困難である。
【０００３】
特に、ノートパソコンを始めとする携帯端末は画面が小さく、操作性も高くないため、必要なファイルを探し出す作業は面倒である。また、会議資料は直前まで更新される可能性があり、会議が始まる前に配布された全ての資料の最新版を整理、準備しておくことは困難である。
【０００４】
上記のような問題を解決するための技術として、電子メール受信時にその電子メールの内容を解析して会議開催通知かどうかを判定し、会議開催通知の場合には内容から日時、場所、参加者を抽出して、場所に対応するファイルサーバなどの共有リソースに対して、日時と参加者を含んだアクセス制御を設定する方法が開示されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−５３８２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の技術は、会議に関連する共有リソースへのアクセス制御を設定しているのみであり、ユーザが会議室で共有リソースにアクセスし、ファイルを探すという操作の面倒さが持つ課題は何ら解決していない。また、ユーザが自らどの会議に関係あるかを判断し、その資料を自ら共有フォルダにコピーしなければ会議資料と会議との対応付けは不可能なため、事前の操作が必要となり、新たな操作の面倒さが生じる。
【０００７】
そこで、本発明では、電子メールの送受信先のユーザのスケジュール情報から共通する会議を抽出し、その会議の日時と場所に関連するリソースを対応付けて管理して、通常の電子メールのやりとりのみで会議とリソースとを対応付けることができるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、以下に開示する情報処理装置は、電子メールの送受信に関するイベントを検出するメールイベント検出部と、電子メールに関連するリソース、又はリソースにアクセスするための情報を含むリソース情報を取得するリソース取得部と、電子メールに関連する複数のユーザのユーザ情報を取得するユーザ情報取得部と、ユーザ情報取得部が取得した複数のユーザのユーザ情報に基づいて、電子メールのユーザと当該ユーザのスケジュールとを関連付けたスケジュール情報を参照して、当該複数のユーザの共通なスケジュールを抽出する共通スケジュール抽出部と、リソース取得部が取得したリソース情報と共通スケジュール抽出部が抽出した共通なスケジュールとを関連付けてリソース格納部に格納するリソース管理部とを備える。
【発明の効果】
【０００９】
上記の構成によれば、通常の電子メールのやりとりのみで会議とリソースを対応付けることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係る情報処理システムの構成を示す概略図
【図２】本発明の実施形態１に係る情報処理システムの構成の一例を示すブロック図
【図３】ユーザ情報テーブルの一例を示す図
【図４】スケジュール情報テーブルの一例を示す図
【図５】本発明の実施形態１に係る情報処理システムの動作の一例を示す図
【図６】リソース管理テーブルの一例を示す図
【図７】本発明の実施形態１に係る情報処理システムの動作の一例を示す図
【図８】場所紐付けテーブルの一例を示す図
【図９】関連リソースリスト画面の一例を示す図
【図１０】本発明の実施形態１に係る情報処理システムの動作の一例を示す図
【図１１】メールのヘッダ情報の一例を示す図
【図１２】リソース管理テーブルの一例を示す図
【図１３】本発明の実施形態１に係る情報処理システムの動作の一例を示す図
【図１４】関連リソースリスト画面の一例を示す図
【図１５】本発明の実施形態２に係る情報処理システムの構成の一例を示すブロック図
【図１６】リソース管理テーブルの一例を示す図
【図１７】本発明の実施形態２に係る情報処理システムの動作の一例を示す図
【図１８】リソース管理テーブルの一例を示す図
【図１９】本発明の実施形態２に係る情報処理システムの動作の一例を示す図
【図２０】本発明の実施形態３に係る情報処理システムの構成の一例を示すブロック図
【図２１】本発明の実施形態３に係る情報処理システムの動作の一例を示すフロー図
【図２２】再評価イベント管理テーブルの一例を示す図
【図２３】本発明の実施形態４に係る情報処理システムの構成の一例を示すブロック図
【図２４】本発明の実施形態４に係る情報処理システムの動作の一例を示すフロー図
【図２５】リソース管理テーブルの一例を示す図
【図２６】関連リソースリスト画面の一例を示す図
【図２７】本発明の実施形態４に係る情報処理システムの動作の一例を示すフロー図
【図２８】会議履歴テーブルの一例を示す図
【図２９】リソース管理テーブルの一例を示す図
【図３０】関連リソースリスト画面の一例を示す図
【図３１】本発明の実施形態４に係る情報処理システムの動作の一例を示すフロー図
【図３２】本発明の実施形態５に係る情報処理システムの構成の一例を示すブロック図
【図３３】本発明の実施形態５に係る情報処理システムの動作の一例を示すフロー図
【図３４】本発明の実施形態５に係る情報処理システムの動作の一例を示すフロー図
【図３５】本発明の実施形態６に係る情報処理システムの構成の一例を示すブロック図
【図３６】関連リソースリスト画面の一例を示す図
【図３７】本発明の実施形態７に係る情報処理システムの構成の一例を示すブロック図
【図３８】本発明の実施形態７に係る情報処理システムの動作の一例を示すフロー図
【発明を実施するための形態】
【００１１】
[実施形態１]
次に、本発明の実施形態について、図面を用いて詳細に説明する。
【００１２】
図１は、本発明の実施形態に係る情報処理装置を含むシステム全体の構成を示す概略図である。図１において、ユーザの所有するノートＰＣ１１０がネットワーク１２０を介してメールサーバ１３０、ディレクトリサーバ１４０、及びスケジュールサーバ１５０と接続されている。また、会議室Ａ〜Ｘにはそれぞれ、ユーザがネットワーク１２０を介して、各サーバや他のＷｅｂサーバにアクセスするための無線ＬＡＮアクセスポイントＡ〜Ｘが設定されたシステムの構成を示している。本実施形態では、ノートＰＣ１１０が情報処理装置として機能する場合について説明する。なお、本発明の情報処理装置は、１台のコンピュータで構成される場合に限られず、複数のコンピュータで構成されていてもよい。
【００１３】
ノートＰＣ１１０は、本実施形態を実施するためのメールプログラムによって、メールクライアントとして動作している。メールプログラムによる詳細な動作については後述する。なお、本実施形態ではユーザはノートＰＣ１１０を使うことを想定しているが、メールクライアントとして動作する端末は、これに限られない。例えば、携帯電話やスマートフォンなどの小型携帯端末を利用してもよい。
【００１４】
また、本実施形態ではネットワーク１２０は社内ネットワークを想定しているが、通常のインターネットやその他のネットワークでも良い。ただし、その場合には、メールクライアントが、メールサーバ１３０、ディレクトリサーバ１４０、スケジュールサーバ１５０などに、そのネットワーク１２０を介してアクセスできるようにする。
【００１５】
メールサーバ１３０は、メール配送プログラムによって動作している。メールサーバ１３０は、電子メールの受信時にメールを蓄積し、ユーザからの要求に応じて、そのユーザの電子メールに関する情報を返却する。また、メールサーバ１３０は、ユーザからの要求に応じて、他のメール配送プログラムに対して、電子メールの配送を依頼する。本実施形態では、メール配送プログラムは、既存のプログラムを用いることができる。
【００１６】
ディレクトリサーバ１４０は、ユーザ情報管理プログラムによって動作している。ディレクトリサーバ１４０は、例えば図３に示すように、ユーザのＩＤ、氏名、電話番号、所属、メールアドレス、及びスケジューラＩＤのユーザ情報を、ユーザ情報テーブル３００で管理しており、ユーザからの要求に応じて該当ユーザの情報を返却する。本実施形態では、ユーザ情報管理プログラムは、既存のプログラムを用いることができる。
【００１７】
スケジュールサーバ１５０は、スケジュール管理プログラムによって動作している。スケジュールサーバ１５０は、例えば図４に示すように、スケジュールＩＤ、日付、時間、場所、及び内容のユーザのスケジュール情報を、スケジュールテーブル４００で管理しており、ユーザからの要求に応じて該当ユーザのスケジュール情報を返却する。また、ユーザからの要求に応じて、新しいスケジュールの登録や、既存のスケジュールの内容の更新を実行する。本実施形態では、スケジュール管理プログラムは、既存のプログラムを用いることができる。
【００１８】
なお、本実施形態ではメールサーバ１３０、ディレクトリサーバ１４０、スケジュールサーバ１５０は社内に設置されていると想定しているが、メールクライアントからアクセスできるならば、社外に設置されていてもよい。
【００１９】
無線ＬＡＮアクセスポイントＡ〜Ｘは、ユーザが会議室にノートＰＣ１１０を持って移動した場合に、前述のネットワーク１２０に接続するために利用する。また、無線ＬＡＮアクセスポイントＡ〜Ｘには、一意のＩＤ（ＢＳＳＩＤ）が振られており、この値に対して会議室情報を紐付けて管理しておくことによって、ユーザがどの会議室にいるかを判定することができる。この会議室判定機能及び紐付け情報は前述のメールプログラムが実装している。
[実施形態１]
図２は、本発明の実施形態１に係る情報処理装置の構成の一例を示すブロック図である。図２において、ノートＰＣ１１０で実現される情報処理装置は、メールイベント検出部２０１、リソース取得部２０２、関連ユーザ取得部２０３、共通スケジュール抽出部２０４、リソース管理部２０５、場所検出部２０６、及び提示部２０７を備える。本実施形態では、ノートＰＣ１１０は、通常のメール機能に、これらの機能を更に付加したものである。なお、ノートＰＣ１１０が備えるこれらの情報処理装置の機能は、外部の少なくとも１つのコンピュータに分散して備えられてもよい。また、情報処理装置の各機能は、メールクライアントとして動作するノートＰＣ１１０に設けられているが、メールサーバ１３０又はその他のサーバに設けられてもよい。
【００２０】
メールイベント検出部２０１は少なくとも、電子メール送信時、電子メール受信時、電子メールに添付されたファイル保存時のいずれかの電子メールに関するイベントを検出する。メールイベント検出部２０１は、メールクライアントにおけるメール送受信、添付ファイルの保存処理をイベントとしてもよいし、メールサーバ１３０におけるメール送受信をイベントとして検出することができる。
【００２１】
リソース取得部２０２は、電子メールに関連するリソース情報を取得する。電子メールに関連するリソースは、例えば、電子メールの送信者、受信者の双方が、後にアクセスする必要が生じうる１まとまりのデータである。例えば、電子メールに関連するユーザが後の会議で使用するデータを、リソースと識別することができる。例えば、電子メールの本文、添付ファイル、双方のユーザがアクセス可能なサーバに記録された共有ファイル等がリソースになり得る。リソース情報には、リソースそのもの、リソースへアクセスするための情報の少なくともいずれかが含まれる。リソース取得部２０２では、電子メールに含まれる情報、又は添付ファイルからリソース情報を取得する。リソース情報の取得方法の詳細については、後述する。リソース取得部２０２は、少なくとも、電子メール、電子メールに添付されたファイル、電子メール本文に記載されたリソース場所情報のいずれかをリソース情報として取得できる。リソース取得部２０２は、電子メールに関連するリソースが存在すると判定した場合のみ、リソース情報の取得処理を実行することができる。
【００２２】
関連ユーザ取得部２０３は、電子メールの送受信者のユーザ情報を取得する。関連ユーザ取得部２０３は、例えば、電子メールのヘッダ情報を参照し、送信元ユーザ(Ｆｒｏｍヘッダを参照)、送信先ユーザ(Ｔｏヘッダを参照)、写し送信先ユーザ(Ｃｃヘッダを参照)して、送受信者のユーザ情報を取得することができる。
【００２３】
共通スケジュール抽出部２０４は、関連ユーザ取得部２０３が取得した電子メールの送受信者のユーザ情報に基づいて、各ユーザの共通なスケジュールを抽出する。共通スケジュール抽出部２０４は、取得した送受信者のユーザ情報に基づいて、全てのユーザのスケジュールの時間と場所が共通するスケジュール情報を検索して、共通イベントを抽出する。なお、スケジュール情報は、スケジュールサーバ１５０に記録されている構成で説明したが、情報処理装置自身が備える構成であってもよい。
【００２４】
リソース管理部２０５は、リソース取得部２０２が取得したリソース情報と共通スケジュール抽出部２０４が抽出した共通イベントとを関連付けてリソース格納部に格納する。
【００２５】
場所検出部２０６は、ユーザのいる場所を検出する。例えば、ユーザがどの会議室にいるかを判定する、例えば無線ＬＡＮアクセスポイントからの情報をもとに、ユーザのいる場所を検出することができる。なお、本実施形態では無線ＬＡＮアクセスポイントＡ〜Ｘによって、ユーザの位置を判定しているが、ＩＣカードを利用した入室管理システムやその他の位置測位システムを利用しても構わない。
【００２６】
提示部２０７は、場所検出部２０６が検出した場所と共通スケジュール抽出部２０４が抽出した共通なスケジュールの実施される場所とが一致したときに、リソース情報のリストを生成し、生成したリソース情報のリストをユーザに提示する。提示部２０７は、ユーザが現在いる場所に基づいて提示する場合に限られない。例えば、ユーザから共通なスケジュール、時間、場所、送受信者等の指示を受付けて、指示に基づいて提示してもよい。
【００２７】
以下、電子メールを受信した場合の本発明の実施形態１に係る情報処理システム１００の動作について、図５のフロー図に従って説明する。
【００２８】
メールイベント検出部２０１は、メールプログラムが起動している場合、イベント待ち状態になる。イベント待ち状態において、メールイベント検出部２０１は、一定時間毎にメールサーバ１２０にアクセスし、新しいメールが存在する場合にはそのメール情報を取得して、ユーザに対して新着メールがあることを通知する（ステップＳ５０１→Ｓ５０２）。
【００２９】
新着メールを受信すると、メールイベント検出部２０１は、電子メールにファイルが添付されているかどうかを確認する（ステップＳ５０３）。これは電子メールのヘッダ情報を参照することによって実行可能である。
【００３０】
あるいは、メールイベント検出部２０１は、メールクライアント側でメール送信時にイベントを検出することもできる。メールクライアントにおいてユーザが、電子メールにファイルを添付するためには、電子メールに添付するファイルをドラッグ＆ドロップしたり、ダイアログボックスから添付するファイルを選択したりする必要がある。そのため、メールイベント検出部２０１は、容易に電子メールにファイルが添付されているかどうかを確認できる。
【００３１】
次に、リソース取得部２０２は、電子メールの本文を参照して、共有サーバのディレクトリ情報やＵＲＬなど、リソースに関する情報が記述されているかどうかを確認する。これはディレクトリやＵＲＬは特定のパターンを有していることから、文字列の簡単なパターンマッチングにより実行可能である。この時点で、電子メールにファイルが添付されておらず、さらにリソースに関する情報が記述されていない場合、リソースがないと判定し、後述の処理を実行しない。
【００３２】
リソース取得部２０２は、電子メールにファイルが添付されている、あるいはリソースに関する情報が記述されている場合には、リソースがあると判定し、電子メールのヘッダ情報に記述されている電子メールを一意に識別するためのメッセージＩＤを取得する（ステップＳ５０４）。
【００３３】
さらに、関連ユーザ取得部２０３は、電子メールのヘッダ情報を参照し、送信元ユーザ(Ｆｒｏｍヘッダを参照)、送信先ユーザ(Ｔｏヘッダを参照)、写し送信先ユーザ(Ｃｃヘッダを参照)のメールアドレスを取得する（ステップＳ５０５）。
【００３４】
関連ユーザ取得部２０３は、ディレクトリサーバ１４０から個々のメールアドレスを所有するユーザのユーザＩＤを取得する（ステップＳ５０６）。ユーザＩＤは、ユーザのスケジュール情報をスケジュールサーバ１５０で検索するために用いられる。スケジュールサーバ１５０がメールアドレスでユーザのスケジュールを管理している場合（例えば、図３参照）には、「ディレクトリサーバ」を利用した本ユーザＩＤ取得処理は不要である。
【００３５】
次に、共通スケジュール抽出部２０４は、スケジュールサーバ１５０から前述の処理で取得した送信元ユーザ、送信先ユーザ、写し送信先ユーザのスケジュール情報を取得する（ステップＳ５０７）。
【００３６】
次に、共通スケジュール抽出部２０４は、取得した全てのユーザのスケジュール情報から時間と場所が共通するスケジュール情報を検索する（ステップＳ５０８）。例えば、スケジュール情報の時間情報と場所情報が一致している場合には共通、時間情報が一致しているが、場所情報が異なる場合には非共通、時間情報に共通する時間帯があり、場所情報が一致する場合には共通と判断することができる。これ以外の共通の判定方法については後述する。
【００３７】
次に、共通スケジュール抽出部２０４は、共通するスケジュールがあったか否かを判定する（ステップＳ５０９）。ステップＳ５０９において、共通するスケジュール情報が見つかった場合には、リソース管理部２０５は、そのスケジュールを共通の会議として、例えば、図６に示すリソース管理テーブル６００を更新する（ステップＳ５１０）。一方、ステップＳ５０９において、共通するスケジュールが見つからなかった場合には、リソース管理部２０５は、ステップＳ５０１に処理を戻す。
【００３８】
図６のリソース管理テーブル６００について説明する。「日時」フィールドは、会議の日時情報を格納するフィールドである。「場所」フィールドは、会議の場所情報を格納するフィールドである。「リソース」フィールドは、会議の見つかった電子メールに関連するリソース情報を格納するフィールドで、接頭辞の"ｍ"は"-"デリミタ以降の値が電子メールのメッセージＩＤであること、"ｓ"は共有サーバのディレクトリであること、"ｌ"はローカルに保存したディレクトリであることを示している。「送信者」「受信者」「写し受信者」フィールドはそれぞれ、電子メールの送信者情報、受信者情報、写し受信者情報を格納するフィールドである。「利用フラグ」は対応付けられたリソースが会議で利用されたかどうかを示すフラグであり、図６に示す例では、会議時間前のため、何も記載されていない。このように、これまでの処理によって得られた情報から、図６のリソース管理テーブル６００を作成することができる。
【００３９】
また、メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出する（ステップＳ５１１）。ステップＳ５１１において、保存する動作を行った場合、メールイベント検出部２０１は、メールのメッセージＩＤをキーにして「リソース」フィールドを検索する（ステップＳ５１２）。
【００４０】
次に、リソース管理部２０５は、見つかった「リソース」フィールドにファイルの保存場所及びファイル名を追加する（ステップＳ５１３）。このとき、リソースが関連づけられていた元の電子メールのメッセージＩＤを「リソース」フィールドから削除してもよい。
【００４１】
次に、ユーザが会議室に移動した場合の処理について、図７のフロー図に従って説明する。
【００４２】
ユーザが会議室に移動すると、ユーザのノートＰＣ１１０が会議室に設置された無線ＬＡＮアクセスポイントに接続し、場所検出部２０６は、無線ＬＡＮアクセスポイントのＢＳＳＩＤを取得する（ステップＳ７０１→Ｓ７０２）。
【００４３】
ＢＳＳＩＤを取得すると、場所検出部２０６は、例えば図８に示す場所紐付けテーブル８００を利用して、ＢＳＳＩＤの示す場所情報を取得する（ステップＳ７０３）。これにより、ユーザが現在どこにいるかを判定することができる
図８の場所紐付けテーブル８００ついて説明する。「ＢＳＳＩＤ」フィールドは無線ＬＡＮアクセスポイントのＢＳＳＩＤを格納するためのフィールドである。「場所」フィールドは、ＢＳＳＩＤに対応する場所情報を格納するフィールドである。本実施形態では場所紐付けテーブル８００をメールクライアントが保持していると想定しているが、サーバに場所紐付けテーブルを保持しておき、ＢＳＳＩＤをキーにしておき、場所情報を取得できるような構成でもよい。
【００４４】
次に、場所検出部２０６は、会議室の無線ＬＡＮアクセスポイントに接続することで場所を判定すると、今までの場所から移動したか否か判定する（ステップＳ７０４）。ステップＳ７０４において、移動していない場合は、場所検出部２０６は、ステップＳ７０１に処理を戻す。一方、移動している場合は、場所検出部２０６は、現在の時刻を取得する（ステップＳ７０５）。
【００４５】
次に、提示部２０７は、時刻情報と場所情報をキーにして、該当する会議をリソース管理テーブル６００から検索する（ステップＳ７０６）。
【００４６】
次に、提示部２０７は、リソース管理テーブル６００に、該当する会議があるか否かを判定する（ステップＳ７０７）。ステップＳ７０７において、リソース管理テーブル６００に、該当する会議がない場合、提示部２０７は、ステップＳ７０１に処理を戻す。一方、ステップＳ７０７において、該当する会議がある場合には、提示部２０７は、対応するリソース情報をリソース管理テーブル６００から取得して、例えば、図９に示す関連リソースリスト画面９００によって関連リソースの一覧を表示する（ステップＳ７０８）。なお、リソース管理テーブル６００を検索する際に利用する時刻情報は前後に既定のマージン(例えば１０分)を付加した上で検索されてもよい。
【００４７】
図９の関連リソースリスト画面９００について説明する。リソースリストは、リソース管理テーブル６００から取得したリソース情報をリソースの種別毎に表示したものである。本実施形態ではメールについてメッセージＩＤのみを表示しているが、メッセージＩＤをキーにして送信者やメールの題名を取得し、これらをリスト内に表示してもよい。「開く」ボタンは、「リソース」リスト内のリソースを選択している場合にのみクリックできる状態となり、ボタンをクリックすると選択したリソースが開くようになっている。「閉じる」ボタンをクリックすると、関連リソースリスト画面９００が閉じるようになっている。
【００４８】
なお、会議に対応付けられた関連リソースの数が既定数(例えば、１以下)の場合には、関連リソースリスト画面９００を表示する代わりに、直接ファイルや関連メールを開いてもよい。
【００４９】
（スレッド化）
以下、電子メールをスレッド化する場合について、図１０のフロー図に従って説明する。スレッド化とは、電子メールをグループ化することである。電子メールに含まれる関連する他の電子メールを示す情報に基づいて、関連ある電子メールをグループ化することができる。
【００５０】
例えば、電子メールをグループ化することによって、当該メールに添付されたファイル、当該メールに添付されたファイルの場所情報をグループ化することができる。リソース管理部２０５は、電子メールをグループ化したスレッド毎に、リソース情報をリソース格納部に格納することができる。
【００５１】
メールイベント検出部２０１は、メールを受信する（ステップＳ１００１〜Ｓ１００２）。メールイベント検出部２０１は、受信メールにリソースが含まれているか否か判定する（ステップＳ１００３）。ステップＳ１００３において、含まれていないと判定された場合、メールイベント検出部２０１は、ステップＳ１００１に処理を戻す。一方、ステップＳ１００３において、含まれていると判定された場合、メールイベント検出部２０１は、受信メールのヘッダ情報に、Ｒｅｆｅｒｅｎｃｅｓヘッダが含まれているか否か判定する（ステップＳ１００４）。
【００５２】
ステップＳ１００４において、含まれていないと判定された場合、リソース管理部２０５は、通常どおり、会議とリソースとの関連付けを行う（ステップＳ１００４→Ｓ１００７）。一方、含まれていると判定された場合、メールイベント検出部２０１は、この受信メールのＲｅｆｅｒｅｎｃｅｓヘッダを含むスレッドを検索する。
【００５３】
そして、メールイベント検出部２０１は、この受信メールとこの受信メールのＲｅｆｅｒｅｎｃｅｓヘッダに記述されたメッセージＩＤの電子メールと関連があると判定し、このヘッダ情報を利用することで、電子メールのメッセージをスレッド化する。メールのヘッダ情報は、例えば図１１に示す送信元ユーザ(Ｆｒｏｍヘッダ)、送信先ユーザ(Ｔｏヘッダ)、写し送信先ユーザ(Ｃｃヘッダ)、及びメッセージＩＤを含む。
【００５４】
具体的には、ユーザＡが最初に会議用資料を添付したメールを送信し、この場合のメッセージＩＤが"ｕｓｅｒＡ:０００００"であったとする。次に、ユーザＢがユーザＡのメールに対して他の会議用資料を添付したメールを送信する。この場合のメッセージＩＤはユーザＡのメッセージＩＤとは異なり、例えば"ｕｓｅｒＢ:０００００"となるが、ＲｅｆｅｒｅｎｃｅｓヘッダにはユーザＡの最初のメールのメッセージＩＤ"ｕｓｅｒＡ:０００００"が含まれる。
【００５５】
さらに、ユーザＣがユーザＢのメールに対して他の会議用資料を添付したメールを送信すると、メッセージＩＤにはユニークな"ｕｓｅｒＣ:０００００"が割り当てられるが、ＲｅｆｅｒｅｎｃｅｓヘッダにはユーザＡとユーザＢのメールのメッセージＩＤ"ｕｓｅｒＡ:０００００"と"ｕｓｅｒＢ:０００００"が含まれる。したがって、Ｒｅｆｅｒｅｎｃｅｓヘッダを持たない最初の電子メールのメッセージＩＤを保存しておくことによって、他の返信メール及びメールに関連するリソースをスレッド化することができる。
【００５６】
次に、リソース管理部２０５は、該当するスレッドの「リソース」フィールドにリソース情報を追加する（ステップＳ１００６）。
【００５７】
また、メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を行ったか否かを判定する（ステップＳ１００１→Ｓ１００８）。ステップＳ１００８において、保存する動作を行った場合、メールイベント検出部２０１は、メールのメッセージＩＤをキーにして「リソース」フィールドを検索する（ステップＳ１００９）。
【００５８】
次に、リソース管理部２０５は、見つかった「リソース」フィールドにファイルの保存場所及びファイル名を追加する（ステップＳ１０１０）。
【００５９】
図１２にスレッド化したリソースを管理するためのリソース管理テーブル１２００の例を示す。「スレッド」フィールドはスレッドを識別するためのＩＤ情報を格納するためのフィールドであり、本例では、Ｒｅｆｅｒｅｎｃｅｓヘッダを持たない電子メールのメッセージＩＤを格納する。
【００６０】
「リソース」フィールドは、「スレッド」フィールドで識別されるスレッドに属するリソース情報を格納するためのフィールドである。その他のフィールドは図６のリソース管理テーブル６００と同じため、説明は省略する。
【００６１】
図１２に示すリソース管理テーブル１２００の場合、スレッド"ｕｓｅｒＢ:１２３４５６"には"ｕｓｅｒＢ:１２３４５６"のメッセージＩＤを持つ電子メールと"\共有\資料.ｄｏｃ"というリソースが割り当てられ、スレッド"ｕｓｅｒＡ:９８７６５"には"ｕｓｅｒＡ:９８７６５"と"ｕｓｅｒＢ:１１１１１"のメッセージＩＤを持つ電子メールが割り当てられていることになる。
【００６２】
次に、ユーザが会議室に移動した場合の処理について、図１３のフロー図に従って説明する。
【００６３】
ユーザが会議室に移動すると、ユーザのノートＰＣ１１０が会議室に設置された無線ＬＡＮアクセスポイントに接続し、場所検出部２０６は、無線ＬＡＮアクセスポイントのＢＳＳＩＤを取得する（ステップＳ１３０１→Ｓ１３０２）。
【００６４】
ＢＳＳＩＤを取得すると、場所検出部２０６は、例えば図８に示す場所紐付けテーブル８００を利用して、ＢＳＳＩＤの示す場所情報を取得する（ステップＳ１３０３）。これにより、ユーザが現在どこにいるかを判定することができる。
【００６５】
図８の場所紐付けテーブル８００ついて説明する。「ＢＳＳＩＤ」フィールドは無線ＬＡＮアクセスポイントのＢＳＳＩＤを格納するためのフィールドである。「場所」フィールドは、ＢＳＳＩＤに対応する場所情報を格納するフィールドである。本実施形態では場所紐付けテーブル８００をメールプログラムが保持していると想定しているが、サーバに場所紐付けテーブルを保持しておき、ＢＳＳＩＤをキーにしておき、場所情報を取得できるような構成でもよい。
【００６６】
次に、場所検出部２０６は、会議室の無線ＬＡＮアクセスポイントに接続することで場所を判定すると、今までの場所から移動したか否か判定する（ステップＳ１３０４）。ステップＳ１３０４において、移動していない場合は、場所検出部２０６は、ステップＳ７０１に処理を戻す。一方、ステップＳ１３０４において、移動している場合は、場所検出部２０６は、現在の時刻を取得する（ステップＳ１３０５）。
【００６７】
次に、提示部２０７は、時刻情報と場所情報をキーにして、該当する会議をリソース管理テーブル６００から検索する（ステップＳ１３０６）。
【００６８】
次に、提示部２０７は、該当する会議があるか否かを判定する（ステップＳ１３０７）。ステップＳ１３０７において、該当する会議がない場合、提示部２０７は、ステップＳ１３０１に処理を戻す。一方、ステップＳ１３０７において、該当する会議がある場合には、提示部２０７は、対応するスレッド毎のリソースを取得して、例えば、図１４に示す関連リソースリスト画面１４００によって関連リソースの一覧を表示する（ステップＳ１３０８）。
【００６９】
図１４にはスレッド名としてスレッドの元になったメールのメッセージＩＤが表示されているが、メッセージＩＤをキーにして送信者名やメールの題名を取得し、これらの情報からスレッド名を生成し、「リソース」リストに表示してもよい。このようにリソースをスレッド化することで、ある関連を持ったリソースをまとめてリスト化できるため、ユーザのリソース参照の利便性を向上させることができる。
[実施形態２]
図１５は、本発明の実施形態２に係る情報処理装置の構成の一例を示すブロック図である。図１５において、情報処理装置は、実施形態１の構成に対して、リソース利用監視部２０８を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。
【００７０】
情報処理装置は、リソース管理部２０５がリソース格納部に格納したリソースの利用状況を監視するリソース利用監視部２０８を更に備える。リソース管理部２０５は、リソース利用監視部２０８がリソースの利用を検出したときに、対応するリソースの情報を更新することができる。
【００７１】
例えば、リソース利用監視部２０８は、リソース管理部２０５が管理するリソースが開かれたことを検出する。リソース管理部２０５は、当該リソースと当該リソースを開いたことが検出された会議以外の会議との関連付けを削除する。
【００７２】
リソース管理部２０５は、会議とリソースを関連付ける際に、抽出した全ての会議（複数の会議）に対してリソースを対応付け、その後その会議に対応する時間と場所において、リソース利用監視部２０８は、関連リソースリスト画面からリソースを開いたかどうかを監視し、開いた場合には、リソース管理部２０５は、そのリソースと他の会議の関連付けを削除する。
【００７３】
これによって、一度会議で利用した資料は次回以降の同一ユーザが参加する会議では関連リソースとして扱わず、ユーザのリソースの選択の利便性を高めることができる。
【００７４】
図１６に関連リソースリスト画面からリソースを開いた後のリソース管理テーブル１６００の例を示す。図１６のリソース管理テーブル１６００は、日時「９／３０  １０：００−１２：００」、場所「５Ａ会議室」の会議に対応付けられたリソースの内、メールリソースは利用されたため「利用フラグ」エントリに"ｕｓｅｄ"が設定され、共有サーバ上の「資料.ｄｏｃ」というファイルリソースも利用されたため、「利用フラグ」エントリ"ｕｓｅｄ"が設定されている。
【００７５】
以下、上記の場合のユーザが会議室から移動したときの処理について、図１７のフロー図に従って説明する。
【００７６】
ユーザが会議室に移動すると、ユーザのノートＰＣ１１０が会議室に設置された無線ＬＡＮアクセスポイントに接続し、場所検出部２０６は、無線ＬＡＮアクセスポイントのＢＳＳＩＤを取得する（ステップＳ１７０１→Ｓ１７０２）。
【００７７】
ＢＳＳＩＤを取得すると、場所検出部２０６は、例えば図８に示す場所紐付けテーブル８００を利用して、ＢＳＳＩＤの示す場所情報を取得する（ステップＳ１７０３）。これにより、ユーザが現在どこにいるかを判定することができる。
【００７８】
次に、場所検出部２０６は、会議室の無線ＬＡＮアクセスポイントに接続することで場所を判定すると、今までの場所から移動したか否か判定する（ステップＳ１７０４）。ステップＳ１７０４において、移動していない場合は、場所検出部２０６は、ステップＳ１７０１に処理を戻す。一方、移動している場合は、リソース利用監視部２０８は、直前の会議で利用済みのリソースを取得する（ステップＳ１７０５）。
【００７９】
次に、リソース利用監視部２０８は、直前の会議で利用済みのリソースが他の会議に対応付けられているかどうかを判定する（ステップＳ１７０６）。ステップＳ１７０６において、対応付けられていない場合は、リソース利用監視部２０８は、ステップＳ１７０１に処理を戻す。一方、ステップＳ１７０６において、対応付けられている場合には、リソース管理部２０５は、その対応付けを解除する（ステップＳ１７０７）。
【００８０】
例えば、図１６の場合には、日時「９／３０  ９：３０−１２：００」、場所「５Ａ会議室」の会議に対応付けられたリソースの内、"ｍ−ｕｓｅｒＢ：１２３４５６"、"ｓ−￥共有￥資料.ｄｏｃ"のリソースは利用済みのため、その対応付けを削除する（ステップＳ１７０１〜Ｓ１７０７）。
【００８１】
図１８に、関連リソースリスト画面からリソースを利用した後のリソース管理テーブル１８００の例を示す。日時「９／３０  ９：３０−１２：００」、場所「５Ａ会議室」の会議に対応付けられたリソース"ｍ−ｕｓｅｒＢ：１２３４５６"および“ｓ−￥共有￥資料.ｄｏｃ"は、全て利用済みであるため、日時「９／３０  ９：３０−１２：００」、場所「５Ａ会議室」の会議に関するデータが、削除されている。また、日時「９／３０  ９：３０−１２：００」、場所「５Ａ会議室」の会議に対応付けられ利用済であるリソース"ｍ−ｕｓｅｒＢ：１２３４５６" および“ｓ−￥共有￥資料.ｄｏｃ"については、日時「１０／１  ９：３０−１１：００」、場所「５Ｂ会議室」の会議にも対応づけられていたため、日時「１０／１  ９：３０−１１：００」、場所「５Ｂ会議室」の会議のリソースから削除されている。
【００８２】
また、会議とリソースを対応付ける際に、最初に抽出された会議（１つの会議）に対してリソースを対応付け、その後その会議に対応する時間と場所において、関連リソースリスト画面からリソースが開いたかどうかを監視し、開かれなかった場合にそのリソースの他の会議を再抽出し、見つかった会議とリソースを対応付けて管理してもよい。
【００８３】
これによって、会議検索の負荷を抑制しながら、会議で利用されなかった資料を自動的に他の会議に対応付けて管理することができるため、ユーザのリソースの選択の利便性を高めることができる。
【００８４】
以下、上記の場合のユーザが会議室から移動したときの処理について、図１９のフロー図に従って説明する。
【００８５】
ユーザが会議室に移動すると、ユーザのノートＰＣ１１０が会議室に設置された無線ＬＡＮアクセスポイントに接続し、場所検出部２０６は、無線ＬＡＮアクセスポイントのＢＳＳＩＤを取得する（ステップＳ１９０１→Ｓ１９０２）。
【００８６】
ＢＳＳＩＤを取得すると、場所検出部２０６は、例えば図８に示す場所紐付けテーブル８００を利用して、ＢＳＳＩＤの示す場所情報を取得する（ステップＳ１９０３）。これにより、ユーザが現在どこにいるかを判定することができる。
【００８７】
次に、場所検出部２０６は、会議室の無線ＬＡＮアクセスポイントに接続することで場所を判定すると、今までの場所から移動したか否か判定する（ステップＳ１９０４）。ステップＳ１９０４において、移動していない場合は、場所検出部２０６は、ステップＳ１９０１に処理を戻す。一方、移動している場合は、リソース利用監視部２０８は、直前の会議で未利用のリソースを取得する（ステップＳ１９０５）。
【００８８】
次に、リソース利用監視部２０８は、直前の会議で未利用のリソースが他の会議に対応付けられているかどうかを判定する（ステップＳ１９０６）。ステップＳ１９０６において、対応付けられていない場合は、リソース利用監視部２０８は、ステップＳ１９０１に処理を戻す。一方、ステップＳ１９０６において、対応付けられている場合には、リソース管理部２０５は、新たに抽出した最初の会議にリソースを対応付ける（ステップＳ１９０６〜Ｓ１９０７）。
【００８９】
例えば、図１８の場合には、リソース利用監視部２０８は、リソース管理テーブル１８００の「送信者」「受信者」「写し受信者」フィールドの情報を利用して、現在時刻以降の最初の会議を抽出し、見つかった場合にはその会議のエントリを作成し、リソースとして"ｍ−ｕｓｅｒＡ：９８７６５"、"ｌ−ｃ：￥会議０９３０．ｐｐｔ"、"ｌ−ｃ：￥資料０９３０ａ．ｔｘｔ"を対応付けて管理する（ステップ１９０１〜Ｓ１９０７）。
【００９０】
なお、本実施形態では関連リソースリスト画面からリソースを開いたかどうかを監視したが、オペレーティングシステムのイベントなどを監視して、他の手段でリソースを開いたかどうかを監視してもよい。
[実施形態３]
図２０は、本発明の実施形態３に係る情報処理装置の構成の一例を示すブロック図である。図２０において、情報処理装置は、実施形態１の構成に対して、予定情報更新監視部２０９を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。予定情報更新監視部２０９は、イベントに関連しているユーザのスケジュール情報の更新を監視する。
【００９１】
実施形態１では、送信者、受信者、写し受信者の全員のスケジュール情報が共通するものを共通の会議として抽出したが、例えば、次のような方法でもよい。全員のスケジュール情報を含まない場合でも、少なくとも２人の時間と場所が一致しているイベントを共通の会議候補として取得し、その会議候補それぞれに対して共通の度合いを示すスコアを計算する。
【００９２】
具体的には、１人のユーザを含む毎に１０ポイントを加算し、さらに送信者の場合には２倍の重み、写し受信者の場合には０．５倍の重みを付けて合計得点を計算し、それを送信者、受信者、写し送信者の合計人数で割ったポイントを共通度スコアとし、その共通度スコアが既定値(例えば５)を超えた場合に共通の会議として、会議とリソースの対応付けを実行する。
【００９３】
例えば、送信者ｕｓｅｒＡ、受信者ｕｓｅｒＢ、ｕｓｅｒＣ、ｕｓｅｒＤ、写し受信者ｕｓｅｒＥ、ｕｓｅｒＦのメールが送信された場合に抽出された共通の会議候補に対して、ｕｓｅｒＡ、ｕｓｅｒＢ、ｕｓｅｒＣ、ｕｓｅｒＦが同じ時間帯と場所のスケジュールを設定している場合、共通度スコアは（２×１０＋１０＋１０＋０．５×１０）／６＝７．５であるので共通の会議と判定される。また、ｕｓｅｒＢ、ｕｓｅｒＣ、ｕｓｅｒＦが同じ時間帯と場所のスケジュールを設定している場合、共通度スコアは(１０＋１０＋０．５×１０)／６＝４．２であるので共通の会議とは判定されない。
【００９４】
なお、上記の共通度スコア算出方法は一例であり、もちろん、これ以外の方法でもよい。例えば、写し受信者のスコアを考慮しなかったり、スケジュール情報の信憑性の高いユーザの重みを大きく取って共通度スコアを算出したりしてもよい。
【００９５】
また、共通度スコアが一定の範囲(例えば４から５の間)の場合には、スケジュール情報を未入力のユーザがいることも考慮して、共通スケジュール抽出部２０４は、図２２に示す再評価イベント管理テーブル２２００に情報を一旦退避させる。再評価イベント管理テーブル２２００の各フィールドには共通度スコアを計算した場合の情報が格納される。
【００９６】
情報処理装置は、ユーザのスケジュール情報の更新を検出する予定情報更新監視部２０９を更に備える。共通スケジュール抽出部２０４は、予定情報更新監視部２０９がスケジュール情報の更新を検出したときに、共通度スコアの再計算を行い、再度共通なスケジュールを抽出することができる。
【００９７】
例えば、予定情報更新監視部２０９は、イベントに関連しているユーザのスケジュール情報の更新を監視する。更新があった場合には、共通スケジュール抽出部２０４は、該当ユーザのスケジュールを取得して、再度共通度スコアを再計算し、再計算の結果得られる共通なスケジュールを抽出する。
【００９８】
以下、図２１のフロー図に従って説明する。
【００９９】
メールイベント検出部２０１は、メールプログラムが起動している場合、一定時間毎にメールサーバ１２０にアクセスし、新しいメールが存在する場合にはそのメール情報を取得して、ユーザに対して新着メールがあることを通知する（ステップＳ２１０１→Ｓ２１０２）。
【０１００】
新着メールを受信すると（ステップ２１０２で、Ｙｅｓ）、メールイベント検出部２０１は、電子メールにファイルが添付されているかどうかを確認する（ステップＳ２１０３）。これは電子メールのヘッダ情報を参照することによって実行可能である。
【０１０１】
次に、リソース取得部２０２は、電子メールの本文を参照して、共有サーバのディレクトリ情報やＵＲＬなど、リソースに関する情報が記述されているかどうかを確認する。これはディレクトリやＵＲＬは特定のパターンを有していることから、文字列の簡単なパターンマッチングにより実行可能である。この時点で、電子メールにファイルが添付されておらず、さらにリソースに関する情報が記述されていない場合、後述の処理を実行しない。
【０１０２】
リソース取得部２０２は、電子メールにファイルが添付されている、あるいはリソースに関する情報が記述されている場合には、電子メールのヘッダ情報に記述されている電子メールを一意に識別するためのメッセージＩＤを取得する（ステップＳ２１０４）。
【０１０３】
さらに、関連ユーザ取得部２０３は、電子メールのヘッダ情報を参照し、送信元ユーザ(Ｆｒｏｍヘッダを参照)、送信先ユーザ(Ｔｏヘッダを参照)、写し送信先ユーザ(Ｃｃヘッダを参照)のメールアドレスを取得する（ステップＳ２１０５）。
【０１０４】
関連ユーザ取得部２０３は、ディレクトリサーバ１４０から個々のメールアドレスを所有するユーザのスケジュール情報をスケジュールサーバ１５０で検索するためのユーザＩＤを取得する（ステップＳ２１０６）。スケジュールサーバ１５０がメールアドレスでユーザのスケジュールを管理している場合には、「ディレクトリサーバ」を利用した本ユーザＩＤ取得処理は不要である。
【０１０５】
次に、共通スケジュール抽出部２０４は、スケジュールサーバ１５０から前述の処理で取得した送信元ユーザ、送信先ユーザ、写し送信先ユーザのスケジュール情報を取得する（ステップＳ２１０７）。
【０１０６】
次に、共通スケジュール抽出部２０４は、共通の会議候補を抽出し、それらの共通度スコアを算出して、一旦再評価イベント管理テーブル２２００に退避する（ステップＳ２１０８）。
【０１０７】
次に、共通度イベント抽出部２０４は、算出した共通度スコアが既定値をクリアしているか否かを判定する（ステップＳ２１０９）。
【０１０８】
ステップＳ２１０９において、既定値をクリアしている場合、リソース管理部２０５は、その共通の会議候補を共通の会議と判定し、再評価イベント管理テーブル２２００のフィールドから必要な情報を取得し、リソース管理テーブルを更新する（ステップＳ２１１０）。その後、リソース管理部２０７は、リソース管理テーブルに登録した共通の会議候補に関する情報を再評価イベント管理テーブル２２００から削除する。
【０１０９】
一方、ステップＳ２１０９において、既定値をクリアしていない場合、共通スケジュール抽出部２０４は、算出した共通度スコアが既定範囲内か否か判定する（ステップＳ２１１１）。ステップＳ２１１１において、既定範囲内でない場合、共通スケジュール抽出部２０４は、ステップＳ２１０１に処理を戻す。一方、既定範囲内である場合、予定情報更新監視部２０９は、再評価イベント管理テーブル２２００の「送信者」「受信者」「写し受信者」の該当日時及び場所のスケジュールを取得し、スケジュールに更新がある場合、共通スケジュール抽出部２０４は、再度共通度スコアを計算し、再評価イベント管理テーブル２２００の共通の会議候補に関する情報を更新する（ステップ２１１２）。
【０１１０】
次に、予定情報更新監視部２０９は、その共通の会議候補に関連しているユーザのスケジュール情報の更新を監視する（ステップＳ２１１３）。
【０１１１】
また、新着メールを受信していない場合（ステップ２１０２で、Ｎｏ）、メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出したか否かを監視する（ステップＳ２１１４）。メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出すると（ステップＳ２１１４で、Ｙｅｓ）、メールのメッセージＩＤをキーにして「リソース」フィールドを検索する（ステップＳ２１１５）。リソース管理部２０５は、見つかった「リソース」フィールドにファイルの保存場所及びファイル名を追加する（ステップＳ２１１６）。
[実施形態４]
図２３は、本発明の実施形態４に係る情報処理装置の構成の一例を示すブロック図である。図２３において、情報処理装置は、実施形態１の構成に対して、関連リソース変更監視部２１０を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。関連リソース変更監視部２１０は、同じ会議に対してリソース名が類似しているものは同一リソースのバージョン違いと判定する。
【０１１２】
情報処理装置は、リソース管理部２０５がリソース格納部に格納したリソースの変更状況を監視する関連リソース変更監視部２１０を更に備える。リソース管理部２０５は、関連リソース変更監視部２１０がリソースの変更を検出したときに、対応するリソースの情報を更新することができる。
【０１１３】
例えば、関連リソース変更監視部２１０は、リソースがバージョン違いであることを検出する。リソース管理部２０５は、検出されたバージョン違いのリソースを追加更新する。
【０１１４】
以下、図２４のフロー図に従って説明する。
【０１１５】
メールイベント検出部２０１は、メールプログラムが起動している場合、一定時間毎にメールサーバ１２０にアクセスし、新しいメールが存在する場合にはそのメール情報を取得して、ユーザに対して新着メールがあることを通知する（ステップＳ２４０１→Ｓ２４０２）。
【０１１６】
ステップＳ２４０２において、新着メールが存在しない場合（ステップＳ２４０２で、Ｎｏ）、メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出したか否かを監視する（ステップＳ２４１３）。メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出すると（ステップＳ２４１３で、Ｙｅｓ）、メールのメッセージＩＤをキーにして「リソース」フィールドを検索する（ステップＳ２４１４）。リソース管理部２０５は、見つかった「リソース」フィールドにファイルの保存場所及びファイル名を追加する（ステップＳ２４１５）。
【０１１７】
一方、ステップＳ２４０２において、新着メールを受信すると、メールイベント検出部２０１は、電子メールにファイルが添付されているかどうかを確認する（ステップＳ２４０３）。これは電子メールのヘッダ情報を参照することによって実行可能である。
【０１１８】
次に、リソース取得部２０２は、電子メールの本文を参照して、共有サーバのディレクトリ情報やＵＲＬなど、リソースに関する情報が記述されているかどうかを確認する。これはディレクトリやＵＲＬは特定のパターンを有していることから、文字列の簡単なパターンマッチングにより実行可能である。この時点で、電子メールにファイルが添付されておらず、さらにリソースに関する情報が記述されていない場合、後述の処理を実行しない。
【０１１９】
リソース取得部２０２は、電子メールにファイルが添付されている、あるいはリソースに関する情報が記述されている場合には、電子メールのヘッダ情報に記述されている電子メールを一意に識別するためのメッセージＩＤを取得する（ステップＳ２４０４）。
【０１２０】
さらに、関連ユーザ取得部２０３は、電子メールのヘッダ情報を参照し、送信元ユーザ(Ｆｒｏｍヘッダを参照)、送信先ユーザ(Ｔｏヘッダを参照)、写し送信先ユーザ(Ｃｃヘッダを参照)のメールアドレスを取得する（ステップＳ２４０５）。
【０１２１】
関連ユーザ取得部２０３は、ディレクトリサーバ１４０から個々のメールアドレスを所有するユーザのスケジュール情報をスケジュールサーバ１５０で検索するためのユーザＩＤを取得する（ステップＳ２４０６）。スケジュールサーバ１５０がメールアドレスでユーザのスケジュールを管理している場合には、「ディレクトリサーバ」を利用した本ユーザＩＤ取得処理は不要である。
【０１２２】
次に、共通スケジュール抽出部２０４は、スケジュールサーバ１５０から前述の処理で取得した送信元ユーザ、送信先ユーザ、写し送信先ユーザのスケジュール情報を取得する（ステップＳ２４０７）。
【０１２３】
次に、共通スケジュール抽出部２０４は、取得した全てのユーザのスケジュール情報から時間と場所が共通する会議を検索する（ステップＳ２４０８）。ステップＳ２４０８において、共通する会議がない場合、共通スケジュール抽出部２０４は、ステップＳ２４０１に処理を戻す。一方、ステップＳ２４０８において、共通する会議がある場合（ステップＳ２４０９でＹＥＳ）、関連リソース変更監視部２１０は、会議とリソースを対応付ける際に、同じ会議に対してリソース名が類似しているか否かを判定する（ステップＳ２４１０）。
【０１２４】
ステップＳ２４１０において、類似していない場合、リソース管理部２０５は、リソース管理テーブルの「リソース」フィールドに、当該リソースを追加する（ステップＳ２４１１）。
【０１２５】
一方、ステップＳ２４１０において、類似している場合、関連リソース変更監視部２１０は、同一リソースのバージョン違いとみなし、リソース管理部２０５は、リソース管理テーブルの現在の「リソース」フィールドの情報を、前バージョンの「リソース」フィールドの先頭に追加する（ステップＳ２４１２）。
【０１２６】
例えば、"資料２００９０９３０．ｄｏｃ"と"資料２００９０９３０−２．ｄｏｃ"は日付に相当する部分以外のファイル名が共通しているため、同じリソースと見なし、時間順にバージョン違いのリソースとして管理する。もちろん、上記の判定方法は一例であり、これ以外の判定方法を利用して、類似を判定してもよい。このときのリソース管理テーブル２５００を図２５に、関連リソースリスト画面２６００を図２６に示す。
【０１２７】
図２５は、通常のリソース管理テーブルに、「リソース前バージョン」フィールドが追加されており、リソース追加時にバージョン違いであると判定された場合には、リソース管理部２０７は、「リソース」フィールドのリソース情報を「リソース前バージョン」フィールドの先頭に追加し、「リソース」フィールドには新たなリソース情報を設定する例である。
【０１２８】
図２６は、関連リソースリスト画面２６００の「リソース」リスト中のリソースを選択し、「前バージョン」ボタンをクリックしたときに表示される「他バージョン」ウインドウを示している。「前バージョン」ボタンは複数のバージョンを持ったリソースを選択した場合にのみクリック可能な状態となる。「他バージョン」ウインドウには、図２５のリソース管理テーブル２５００の「リソース前バージョン」フィールドに格納されているリソース情報が表示される。
【０１２９】
「他バージョン」ウインドウでリソースを選択して、「開く」ボタンをクリックすると該当するリソースが開く。「開く」ボタンは「他バージョン」ウインドウのリソースを選択した場合にのみクリック可能な状態となる。「閉じる」ボタンをクリックすると、「他バージョン」ウインドウが閉じる。
【０１３０】
また、会議にリソースを対応付ける際に、その会議の元になった「送信者」「受信者」「写し受信者」が関係する以前の会議を対応付けて管理してもよい。図２８に会議履歴テーブル２８００、図２９に関連する会議を対応付けて管理するためのリソース管理テーブル２９００、図３０に関連リソースリスト画面３０００を示す。
【０１３１】
図２８に示す会議履歴テーブル２８００には、会議日時が過ぎた会議情報が格納されている。会議を識別するための「会議ＩＤ」フィールド以外は、リソース管理テーブル２９００のフィールドの値が格納される。但し、「利用フラグ」フィールドは格納しない。メールプログラム上に日時が過ぎた共通イベントを全て蓄積、管理することはメモリの制約上困難であるため、会議履歴テーブル２８００はデータベースサーバ上に保存してもよい。また、既定期間の間の情報のみを保存しておいてもよい。
【０１３２】
図２９に、通常のリソース管理テーブルに「関連会議ＩＤ」フィールドが追加されたリソース管理テーブル２９００を示す。このフィールドは、会議履歴テーブル２８００を検索して、「送信者」「受信者」「写し受信者」の情報が今回抽出した会議と一致する会議ＩＤを格納するフィールドである。なお、過去の会議は「送信者」「受信者」のみで検索するなど、他の方法で行っても構わない。
【０１３３】
図３０に、関連リソースリスト画面３０００の「関連会議」ボタンをクリックしたときに表示される「関連会議」ウインドウを示す。「関連会議」ボタンは、関連会議のある会議の関連リソースリスト画面３０００表示時のみクリック可能な状態となる。「関連会議」ウインドウには図２９の「関連会議」フィールドに格納されているＩＤに対応する情報が表示される。
【０１３４】
以下、上記の例を図２７のフロー図に従って説明する。
【０１３５】
メールイベント検出部２０１は、メールプログラムが起動している場合、一定時間毎にメールサーバ１２０にアクセスし、新しいメールが存在する場合にはそのメール情報を取得して、ユーザに対して新着メールがあることを通知する（ステップＳ２７０１→Ｓ２７０２）。
【０１３６】
新着メールが存在しない場合（ステップＳ２７０２で、Ｎｏ）、メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出したか否かを監視する。メールイベント検出部２０１は、受信メールに添付されたファイルをローカルのハードディスクに保存する動作を検出すると（ステップＳ２７１２で、Ｙｅｓ）、メールのメッセージＩＤをキーにして「リソース」フィールドを検索する（ステップＳ２７１３）。リソース管理部２０５は、見つかった「リソース」フィールドにファイルの保存場所及びファイル名を追加する（ステップＳ２７１４）。
【０１３７】
一方、新着メールを受信すると（ステップＳ２７０２で、Ｙｅｓ）、メールイベント検出部２０１は、電子メールにファイルが添付されているかどうかを確認する（ステップＳ２７０３）。これは電子メールのヘッダ情報を参照することによって実行可能である。
【０１３８】
次に、リソース取得部２０２は、電子メールの本文を参照して、共有サーバのディレクトリ情報やＵＲＬなど、リソースに関する情報が記述されているかどうかを確認する。これはディレクトリやＵＲＬは特定のパターンを有していることから、文字列の簡単なパターンマッチングにより実行可能である。この時点で、電子メールにファイルが添付されておらず、さらにリソースに関する情報が記述されていない場合、後述の処理を実行しない。
【０１３９】
リソース取得部２０２は、電子メールにファイルが添付されている、あるいはリソースに関する情報が記述されている場合には、電子メールのヘッダ情報に記述されている電子メールを一意に識別するためのメッセージＩＤを取得する（ステップＳ２７０４）。
【０１４０】
さらに、関連ユーザ取得部２０３は、電子メールのヘッダ情報を参照し、送信元ユーザ(Ｆｒｏｍヘッダを参照)、送信先ユーザ(Ｔｏヘッダを参照)、写し送信先ユーザ(Ｃｃヘッダを参照)のメールアドレスを取得する（ステップＳ２７０５）。
【０１４１】
関連ユーザ取得部２０３は、ディレクトリサーバ１４０から個々のメールアドレスを所有するユーザのスケジュール情報をスケジュールサーバ１５０で検索するためのユーザＩＤを取得する（ステップＳ２７０６）。スケジュールサーバ１５０がメールアドレスでユーザのスケジュールを管理している場合には、「ディレクトリサーバ」を利用した本ユーザＩＤ取得処理は不要である。
【０１４２】
次に、共通スケジュール抽出部２０４は、スケジュールサーバ１５０から前述の処理で取得した送信元ユーザ、送信先ユーザ、写し送信先ユーザのスケジュール情報を取得する（ステップＳ２７０７）。
【０１４３】
次に、共通スケジュール抽出部２０４は、取得した全てのユーザのスケジュール情報から時間と場所が共通する会議を検索する（ステップＳ２７０８）。ステップＳ２７０８において、共通する会議がない場合、共通スケジュール抽出部２０４は、ステップＳ２７０１に処理を戻す。一方、ステップＳ２７０８において、共通する会議がある場合（ステップＳ２７０９でＹＥＳ）、関連リソース変更監視部２１０は、会議履歴テーブル２８００を参照し、その会議の元になった「送信者」「受信者」「写し受信者」が関係する以前の会議である関連会議を取得する（ステップＳ２７１０）。
【０１４４】
次に、リソース管理部２０５は、リソース管理テーブルにおいて、取得した関連会議に対応するリソースに更新する（ステップＳ２７１１）。
【０１４５】
なお、このとき、「関連会議」フィールドの会議ＩＤをキーにして、該当会議の「日時」「場所」「リソース」の情報を取得し、リストとして表示する。「関連会議」ウインドウでリソースを選択して、「開く」ボタンをクリックすると該当するリソースが開く。「開く」ボタンは「関連会議」ウインドウのリソースを選択した場合にのみクリック可能な状態となる。「閉じる」ボタンをクリックすると、「関連会議」ウインドウが閉じる。
【０１４６】
なお、関連リソース変更監視部２１０は、リソースのファイル名や保存場所の変更操作を監視し、変更があった場合には変更前のリソース情報をキーにして、リソース管理テーブルの変更すべきエントリを特定し、変更後のリソース情報に置き換える。
【０１４７】
以下、上記の場合について、図３１のフロー図に従って説明する。
【０１４８】
まず、メールイベント検出部２０１は、リソース変更イベントを受信したか否かを判定する（ステップＳ３１０１→Ｓ３１０２）。ステップＳ３１０２において、受信しなかった場合、メールイベント検出部２０１は、ステップＳ３１０１に処理を戻す。一方、ステップＳ３１０２において、受信した場合、リソース変更監視部２１０は、リソース変更イベントの情報に基づいて、変更前のリソース情報を取得する（ステップＳ３１０３）。
【０１４９】
次に、リソース変更監視部２１０は、リソース管理テーブルから変更対象リソースを検索する（ステップＳ３１０４）。変更対象リソースがある場合（ステップＳ３１０５でＹＥＳ）、リソース管理部２０５は、リソース管理テーブルを更新する。
【０１５０】
リソース変更操作の監視は、例えばオペレーティングシステムのイベントを監視することによって実行可能である。これによって、ユーザがリソースのファイル名や保存場所を変更した場合にも、関連リソースリスト画面から正しいリソースを開くことができる。
[実施形態５]
図３２は、本発明の実施形態５に係る情報処理装置の構成の一例を示すブロック図である。図３２において、情報処理装置は、実施形態１の構成に対して、関連ユーザ状況取得部２１１を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。関連ユーザ状況取得部２１１は、会議に関連するユーザの現在の状況や操作の情報を取得する。
【０１５１】
情報処理装置は、共通スケジュール抽出部２０４が抽出した共通なスケジュールに関連するユーザの場所状況を取得する関連ユーザ状況取得部２１１を更に備える。提示部は、関連ユーザ状況取得部２１１がユーザの場所状況変化を取得したときに、場所状況に対応するようにリソースの提示優先度を変更して提示する。
【０１５２】
例えば、関連ユーザ状況取得部２１１は、ユーザの場所変更状況を取得する。提示部２０７は、場所変更のあったユーザが該当する場所にいる場合には、リソースの優先度を上げて提示し、該当する場所にいない場合にはリソースの優先度を下げて提示する。
【０１５３】
関連ユーザ状況取得部２１１は会議に関連するユーザの現在の状況や操作を互いに送受し、その情報を利用してリソースの優先度を変更する。例えば、プレゼンスシステムを利用することによって、リアルタイムで情報を送受信できる。
【０１５４】
具体的には、関連ユーザ状況取得部２１１が会議を抽出した時点で、自分自身以外の他のユーザのプレゼンス情報を購読する処理を実行することによって、それ以降他のユーザのプレゼンス情報が変わったとき、リアルタイムで情報を受信することができる。
【０１５５】
例えば、ユーザの場所変更時にそのユーザの場所情報を他のユーザに送信することによって、そのユーザが会議場所にいる場合にはそのユーザが送信元であるリソースの優先度を上げ、会議場所にいない場合にはそのユーザが送信元であるリソースの優先度を下げる。優先度の上げ下げは、リソース管理テーブルの「リソース」フィールドの順番を並び替えることによって実現できる。これによって、会議の場所にいない(出席していない)ユーザが送信した資料は、関連リソースリスト画面に表示されない、あるいはリストの下の方に表示することができ、ユーザのリソースへのアクセスの利便性が高まる。
【０１５６】
以下、上記の例について、図３３のフロー図に従って説明する。
【０１５７】
ユーザが会議室に移動すると、ユーザのノートＰＣ１１０が会議室に設置された無線ＬＡＮアクセスポイントに接続し、場所検出部２０６は、無線ＬＡＮアクセスポイントのＢＳＳＩＤを取得する（ステップＳ３３０１→Ｓ３３０２）。
【０１５８】
ＢＳＳＩＤを取得すると、場所検出部２０６は、例えば図８に示す場所紐付けテーブル８００を利用して、ＢＳＳＩＤの示す場所情報を取得する（ステップＳ３３０３）。これにより、ユーザが現在どこにいるかを判定することができる。
【０１５９】
次に、場所検出部２０６は、会議室の無線ＬＡＮアクセスポイントに接続することで場所を判定すると、今までの場所から移動したか否か判定する（ステップＳ３３０４）。ステップＳ３３０４において、移動していない場合は、場所検出部２０６は、ステップＳ３３０１に処理を戻す。一方、移動している場合は、関連ユーザ状況取得部２１１は、プレゼンスに場所情報を設定する（ステップＳ３３０５）。
【０１６０】
次に、提示部２０７は、プレゼンスに設定された場所に対応する関連リソースリストを表示する（ステップＳ３３０６）。
【０１６１】
また、ＢＳＳＩＤを取得できなかった場合、関連ユーザ状況取得部２１１は、場所情報を受信したか否かを判定する（ステップＳ３３０７）。ステップＳ３３０７において、受信しなかった場合、関連ユーザ状況取得部２１１は、ステップＳ３３０１に処理を戻す。一方、受信した場合、リソース取得部２０２は、該当ユーザが場所情報の送信元であるリソースを取得する（ステップＳ３３０８）。
【０１６２】
リソースが存在しない場合（ステップＳ３３０９でＮＯ）、リソース取得部２０２は、ステップＳ３３０１に処理を戻す。一方、リソースが存在する場合（ステップＳ３３０９でＹＥＳ）、提示部２０７は、関連リソースリストを表示中か否か判定する（ステップＳ３３１０）。
【０１６３】
ステップＳ３３１０で、表示中でない場合は、提示部２０７は、リソース管理テーブルの「リソース」フィールドの順序を変更する（ステップＳ３３１１）。一方、ステップＳ３３１０で、表示中である場合は、提示部２０７は、該当リソースの表示位置を変更し、リソース管理テーブルの「リソース」フィールドの順序を変更する（ステップＳ３３１１→Ｓ３３１２）。
【０１６４】
また、ユーザが関連リソースを開いた場合にそのリソースの送信元が自分自身である場合にファイルオープンコマンド及び開いたリソース名をプレゼンス情報として設定することで、他のユーザにコマンドとリソース名が通知され、他のユーザの関連リソースリスト画面で該当リソースの表示優先度を上げることができる。
【０１６５】
これによって、リソース送信元のユーザが内容の説明をするためにリソースを開くと、他のユーザはリソースをリスト中から容易に探し出すことができる。また、表示の優先度を高めるだけではなく、自動的にリソースをオープンしてもよい。この場合、ユーザが他のリソースを参照していない場合にのみ、自動的にリソースをオープンしてもよい。また、リソースのオープンは、リソースがスレッド形式である場合、最終更新時刻が直近のスレッドを選択して、リソースをオープンする構成としてもよい。
【０１６６】
上記の例について、図３４のフロー図に従って説明する。
【０１６７】
まず、関連ユーザ状況取得部２１１は、リソースリストからリソースがオープンされたか否かを判定する（ステップ３４０１→Ｓ３４０２）。
【０１６８】
ステップＳ３４０２において、オープンされた場合、関連ユーザ状況取得部２１１は、リソース管理テーブルからリソースの送信者の情報を取得する（ステップＳ３４０３）。
【０１６９】
リソースの送信者が自分でない場合（ステップＳ３３０４でＮＯ）、提示部２０７は、自分の端末でファイルをオープンする（ステップＳ３４０４→ステップＳ３４０６）。一方、リソースの送信者が自分である場合（ステップＳ３４０４でＹＥＳ）、関連ユーザ状況取得部２１１は、プレゼンスに、ファイルオープンしたこと、当該ファイル名を設定し、自分の端末でファイルをオープンする（ステップＳ３４０４→S３４０５→S３４０５）。
【０１７０】
ステップＳ３４０２において、オープンされなかった場合、関連ユーザ状況取得部２１１は、ファイルオープンコマンドを受信したか否か判定する（ステップＳ３４０７）。
【０１７１】
ステップＳ３４０７において、受信しなかった場合、関連ユーザ状況取得部２１１は、ステップＳ３４０１に処理を戻す。一方、ステップＳ３４０７において、受信した場合、提示部２０７は、関連リソースリストを表示中か否か判定する（ステップＳ３４０８）。
【０１７２】
ステップＳ３４０８において、関連リソースリストを表示中である場合、提示部２０７は、該当リソースを上位に表示し、リソース管理部２０５は、リソース管理テーブルのリソースフィールドの順序を変更する（ステップＳ３４０９→Ｓ３４１０）。一方、ステップＳ３４０８において、関連リソースリストを表示中でない場合、リソース管理部２０５は、リソース管理テーブルのリソースフィールドの順序を変更する（ステップＳ３４０８→Ｓ３４１０）。
[実施形態６]
図３５は、本発明の実施形態６に係る情報処理装置の構成の一例を示すブロック図である。図３５において、情報処理装置は、実施形態１の構成に対して、時間入力部２１２を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。時間入力部２１２は、ユーザから日時の入力を受付ける。
【０１７３】
情報処理装置は、ユーザから時間情報の入力を受付ける時間入力部２１２を更に備える。リソースリスト生成部２０６は、時間入力部２１２が入力を受付けた時間に対応するスケジュールに関連するリソース情報を提示することができる。
【０１７４】
例えば、時間入力部２１２は、ユーザから時間情報の入力を受付ける。リソースリスト生成部２０６は、入力を受付けた時間以降の会議に関連付けられたリソースをユーザに提示する。
【０１７５】
時間入力部２１２は、ユーザからの時間情報の入力を受け付け、入力された時間以降の会議の関連リソースを表示する。これによって、会議が始まる前であっても会議に対応付けられた関連リソースを容易に参照することができ、ユーザの利便性が高まる。
【０１７６】
図３６に関連リソースリスト画面３６００の「日時指定」ボタンをクリックしたときに表示される「会議表示」ウインドウ」を示す。「会議表示」ウインドウの「日時指定」フィールドに日時を入力して「検索」ボタンをクリックすると、共通スケジュール抽出部２０４は、リソース管理テーブルを参照し、入力された時間以降の最初の会議を抽出し、対応付けられたリソース情報を表示する。
【０１７７】
なお、「日時指定」フィールドに日時を入力せずに、「検索」ボタンをクリックすると、現在時刻以降の最初の会議を抽出し、対応付けられたリソース情報を表示する。また、「前」ボタン、「次」ボタンをクリックすると、現在表示されている会議の前あるいは後の会議に対応付けられたリソースが表示される。
【０１７８】
「会議表示」ウインドウでリソースを選択して、「開く」ボタンをクリックすると該当するリソースが開く。「開く」ボタンは「会議表示」ウインドウのリソースを選択した場合にのみクリック可能な状態となる。「閉じる」ボタンをクリックすると、「会議表示」ウインドウが閉じる。
【０１７９】
なお、本実施形態では日時のみを指定したが、場所を合わせて検索したり、場所のみで検索したりしてもよい。
[実施形態７]
図３７は、本発明の実施形態７に係る情報処理装置の構成の一例を示すブロック図である。図３７において、情報処理装置は、実施形態１の構成に対して、他端末情報送受信部２１３を更に備える。なお、実施形態１と同様の構成については同一の符号を付している。他端末情報送受信部２１３は、ネットワーク上に存在する他端末の検出情報を送受信する。
【０１８０】
情報処理装置は、リソース格納部を備えた端末で構成されている。情報処理装置は、他ユーザの端末の存在を検出し、当該他ユーザ端末と情報を送受信する他端末情報送受信部２１３を更に備える。他端末情報送受信部２１３は、他ユーザの端末の存在を検出すると、自身の端末のリソース格納部を参照してリソースを所有しているかどうかを判定し、所有していない場合には他ユーザの端末に対して、リソースを送信するように要求することができる。
【０１８１】
例えば、他端末情報送受信部２１３は、他ユーザの端末の存在を検出する。他端末情報送受信部２１３は、他ユーザの端末の存在を検出すると、自身の端末に、現在のスケジュールに関するリソースがあるか否かを判定する。他端末情報送受信部２１３は、自身の端末に、現在のスケジュールに関するリソースがないと判定した場合、他端末に対して、現在のスケジュールに関するリソースを要求する。
【０１８２】
以下、上記の例を図３８のフロー図に従って説明する。
【０１８３】
まず、他端末情報送受信部２１３は、他の端末を検出したか否かを判定する（ステップS３８０１→Ｓ３８０２）。ステップＳ３８０２において、他端末を検出した場合（ステップＳＳ３８０２でＹＥＳ）、現在の場所情報と時刻情報をキーにして、自身の端末のリソース管理テーブルを検索し（ステップＳ３８０３）、現在の会議に対応付けられているリソースを所有しているかどうかを判定する（ステップＳ３８０４）。
【０１８４】
ステップＳ３８０４において、自身の端末がリソースを所有していない場合には、他端末情報送受信部２１３は、他端末で動作しているメールプログラムに対して、リソースリスト及びリソースの送信を要求する（ステップＳ３８０５）。一方、自身の端末がリソースを所有している場合には、他端末情報送受信部２１３は、ステップＳ３８０１に処理を戻す。
【０１８５】
また、要求コマンドを受信した他端末は、場所と時刻情報に基づいて、リソース管理テーブルを検索する（ステップＳ３８０６ＹＥＳ→Ｓ３８０７）。
【０１８６】
リソースがない場合（Ｓ３８０８でＮＯ）、提示部２０７は、空のリソースリストを生成する（ステップＳ３８１１）。一方、リソースがある場合（Ｓ３８０８でＹＥＳ）、提示部２０７は、現在の会議に対応付けられているリソースリストを生成する（ステップＳ３８０９）、リソースが電子メールやローカルに保存しているファイルの場合には、それらの実体を含めて送信する（ステップＳ３８１０）。
【０１８７】
また、要求コマンドを受信しなかった場合（ステップＳ３８０６でＮＯ）、他端末情報送受信部２１３は、要求応答を受信したか否かを判定する（ステップＳ３８１２）。ステップＳ３８１２において、受信しなかった場合、他端末情報送受信部２１３は、ステップＳ３０１に処理を戻す。一方、受信した場合、提示部２０７は、リソースリストが空か否かを判定する（ステップＳ３８１３）。
【０１８８】
ステップＳ３８１３において、空でない場合、提示部２０７は、ステップＳ３８０１に処理を戻す。一方、空である場合、提示部２０７は、リソースを既定のフォルダにコピーする（Ｓ３８１４）。そして、提示部２０７は、リソースリスト内の「リソース」フィールドの内容を実際の保存場所に書き換える（ステップＳ３８１５）。そして、提示部２０７は、リソースリストを自身のリソース管理テーブルにマージする（ステップＳ３８１６）。
【０１８９】
これによって、急遽会議に参加したユーザも周囲のユーザから必要なリソースを受信することができる。なお、近傍の他端末の検出や実際のデータ送受信は、Ｂｌｕｅｔｏｏｔｈなどの近接無線技術を利用することによって実現可能である。もちろん、Ｂｌｕｅｔｏｏｔｈ以外の通信技術によって実現してもよい。また、上記では、自身の端末に関連リソースが全く存在しない場合にリソースリストとリソースを要求したが、自身のリソースリストを要求コマンドに付与して送信し、要求コマンドを受信した側で差分のリソースリスト及びリソースの実体を応答して返してもよい。
【０１９０】
上記の実施形態では、リソース管理テーブルをノートＰＣで保持している例を示したが、リソース管理テーブルをサーバに設置し、メールイベント検出部が必要になった場合にネットワークを介してリソース管理テーブルを参照する構成でもよい。これによって、オフィスの自席ではデスクトップＰＣ、会議ではノートＰＣというように、場所によって異なるＰＣを利用していても容易に会議に関連するリソースにアクセスすることが可能となる。
【０１９１】
以上説明したように、本発明によれば、会議に関連するリソース(会議資料など)の参照手順の煩雑さを改善できる。具体的には、ユーザが特別な操作をする必要がないため、イベントとファイルを容易に関連づけることができる。更に、時間と検出した場所がイベントにヒットすると自動的に関連づけたファイルリストが自動表示あるいはファイルがオープンされるため、ユーザが関連ファイルを探す必要がなく、利便性が高い。
【０１９２】
上記実施形態で説明した構成は、単に具体例を示すものであり、本発明の技術的範囲を制限するものではない。本発明の効果を奏する範囲において、任意の構成を採用することが可能である。
【０１９３】
なお、本発明の実施形態は、上述した実施形態を実現するソフトウェアのプログラム（実施の形態では図に示すフロー図に対応したプログラム）が装置に供給され、その装置のコンピュータが、供給されたプログラムを読出して、実行することによっても達成せれる場合を含む。したがって、本実施形態で説明した機能処理をコンピュータで実現するために、コンピュータにインストールされるプログラム自体も本発明の一実施形態である。つまり、本発明の機能処理を実現させるためのプログラムも、実施形態の一側面に含まれる。また、本発明の機能処理を実現させるためのプログラムを記録した媒体も、実施形態の一側面に含まれる。
【符号の説明】
【０１９４】
１００  情報処理システム
１１０  ノートＰＣ
１２０  ネットワーク
１３０  メールサーバ
１４０  ディレクトリサーバ
１５０  スケジュールサーバ
２０１  メールイベント検出部
２０２  リソース取得部
２０３  関連ユーザ取得部
２０４  共通スケジュール抽出部
２０５  リソース管理部
２０６  場所検出部
２０７  提示部
２０８  リソース利用監視部
２０９  予定情報変更監視部
２１０  関連リソース変更監視部
２１１  関連ユーザ状況取得部
２１２  時間入力部
２１３  他端末情報送受信部
【図１】
0005556271.tif 000002
【図２】
0005556271.tif 000003
【図３】
0005556271.tif 000004
【図４】
0005556271.tif 000005
【図５】
0005556271.tif 000006
【図６】
0005556271.tif 000007
【図７】
0005556271.tif 000008
【図８】
0005556271.tif 000009
【図９】
0005556271.tif 000010
【図１０】
0005556271.tif 000011
【図１１】
0005556271.tif 000012
【図１２】
0005556271.tif 000013
【図１３】
0005556271.tif 000014
【図１４】
0005556271.tif 000015
【図１５】
0005556271.tif 000016
【図１６】
0005556271.tif 000017
【図１７】
0005556271.tif 000018
【図１８】
0005556271.tif 000019
【図１９】
0005556271.tif 000020
【図２０】
0005556271.tif 000021
【図２１】
0005556271.tif 000022
【図２２】
0005556271.tif 000023
【図２３】
0005556271.tif 000024
【図２４】
0005556271.tif 000025
【図２５】
0005556271.tif 000026
【図２６】
0005556271.tif 000027
【図２７】
0005556271.tif 000028
【図２８】
0005556271.tif 000029
【図２９】
0005556271.tif 000030
【図３０】
0005556271.tif 000031
【図３１】
0005556271.tif 000032
【図３２】
0005556271.tif 000033
【図３３】
0005556271.tif 000034
【図３４】
0005556271.tif 000035
【図３５】
0005556271.tif 000036
【図３６】
0005556271.tif 000037
【図３７】
0005556271.tif 000038
【図３８】
0005556271.tif 000039