JP5713340B2 - イベントの通知を送信する方法、並びにそのコンピュータ及びコンピュータ・プログラム - Google Patents

Description

本発明は、イベントの通知を送信する技法に関する。特には、本発明は、イベントの通知を当該イベントに対応する変更管理情報の受信者のクライアント（以下、「送信先クライアント」ともいう）に送信する技法に関する。

イベントの発生を伴うアプリケーション、例えばコラボレーションによりソフトウェア開発を行うためのアプリケーションにおいて、例えばチーム・リーダがイベントを発生させると、その都度、当該イベントに対応する通知（例えば、電子メール又はインスタント・メッセージ）が受信者であるチーム・メンバ（例えば、変更管理システムの購読者又はサブスクライバ）に送信される。

図１は、コラボレーションによりソフトウェア開発を行うためのアプリケーションの例であるコラボレーション・ソフトウェアのユーザ画面（１０１）のインタフェースの例を示す。チーム・リーダは、担当プロジェクトについてのユーザ画面（１０１）を起動し、当該ユーザ画面（１０１）中の、当該プロジェクトに関する各種レコード（１０２）にデータを入力することが可能である。

図２は、チーム・リーダによって入力されたデータがメッセージとしてサーバに送信され、当該サーバが受信者であるチーム・メンバに当該メッセージのそれぞれから作成されたイベント・データに対応するメールを送信する態様を示す。
チーム・リーダ（２０１）のコンピュータは、ネットワークを介してサーバ（２０２）に接続されている。サーバ（２０２）は、同様に、ネットワークを介して少なくとも１つのチーム・メンバ（２０３）のコンピュータに接続されている。
チーム・リーダ（２０１）が、何らかのハードウェア的又はソフトウェア的な問題により入力データが損失することを避けるために、１つ又は複数のレコードを編集する毎に又は１つのレコードを繰り返し編集する毎に（例えば、２１１、２１２、２１３及び２１４を参照）、入力データを保存する場合がある。チーム・リーダ（２０１）のコンピュータは、入力データが保存される毎に、当該入力データをメッセージ（２３１、２３２、２３３）としてサーバ（２０２）に送信する（２２１）。サーバ（２０２）は、当該メッセージ（２３１、２３２及び２３３）それぞれに対応するイベント・データ（図示せず）を作成する。そして、サーバ（２０２）は、当該イベント・データそれぞれに対応するメール（２４１、２４２及び２４３）を作成して、当該メール（２４１、２４２及び２４３）を受信者であるチーム・メンバ（２０３）のコンピュータに送信する（２２２）。従って、チーム・メンバ（２０３）のコンピュータは、イベント・データの数に対応する数多くのメールを受け取ることになる。しかし、チーム・メンバ（２０３）にとって、数多くのメールの中から重要なイベントの情報を有するメールを探し出すことは苦痛であり又は困難である場合がある。さらには、数多くのメールをチーム・メンバ（２０３）のコンピュータに送信することは、チーム・メンバ（２０３）がイベント・データのメールを無視することによって又はチーム・メンバ（２０３）の過失によって、重要な情報を含むメールが見過ごされる事態を生じることにつながりかねない。

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

特許文献２は、スケジューラ付き電子メール装置を記載する（請求項１）。当該スケジューラ付き電子メール装置は、スケジュールメールに含まれるスケジュールデータとスケジュールデータ記憶手段に記憶されているスケジュールデータとを比較し、前記両スケジュールデータ間に重複のあることが検出されたときに、電子メール自動送信手段に、前記重複を回避するスケジュールの変更に関する情報を有する電子メールを前記スケジュールメールの送信者へ自動送信させる（請求項１）。

特許文献３は、電子メール受信処理システムを記載する（請求項１）。当該電子メール受信処理システムは、予め定められている仕分けカテゴリであって、受信した電子メールの仕分けのカテゴリを保存するための仕分けカテゴリ保存手段と、前記カテゴリごとに仕分けするための判断基準を保存するための判断基準保存手段と、前記仕分けカテゴリ保存手段と前記判断基準保存手段とに関連付けされ、電子メール受信部が受信した電子メールを前記判断基準に従って前記カテゴリごとに仕分けするメール仕分け処理部とを備える（請求項１）。

特許文献４は、送り手装置から受け手装置への情報の配信を仲介する情報配信装置を記載する（請求項１）。当該情報配信装置は、配信情報の集約度指定を含む配信条件を複数段階に定義した配信ランクのうち、各送り手からの配信情報について各受け手が選択した配信ランクを記憶する配信ランク記憶部と、送り手装置からの配信情報の原文を記憶する配信情報記憶部と、前記送り手装置から送受信制御部を介して情報配信依頼を受けたとき、当該配信情報の受け手が当該送り手からの配信情報について選択した配信ランクを前記配信ランク記憶部から取得し、取得した配信ランクに対応する集約度指定に従って、前記配信情報記憶部に記憶した配信情報の集約処理を行う集約処理部とを備え、配信ランクに応じた配信情報を前記送受信制御部から各受け手装置へ配信する（請求項１）。

特許文献５は、通知処理方法を記載する（請求項１）。当該通知処理方法は、コンテンツ送信者のコンテンツと、当該コンテンツの宛先と、当該コンテンツに関連して生成される通知の通知条件とを受信した場合に、記憶装置に格納するステップと、システムの利用状況を記憶装置に記録するステップと、少なくとも前記利用状況及び前記通知条件に基づき、特定のイベントの発生を検出するステップと、前記特定のイベントが発生したことが検出された場合には、少なくとも前記通知条件及び当該特定のイベントに関連するコンテンツの宛先であるユーザの通知希望条件に基づき、少なくとも通知先及び通知時期に関する通知態様を決定する通知態様決定ステップとを含む。

特開２００７−４７８１号公報 特開平１１−１８４９２９号公報 特開２００３−１８６８０７号公報 特開２００２−２０７６６９号公報 特開２００３−１９８６２７号公報

本発明は、イベントの通知を含むメールの受信において、メール受信者であるチーム・メンバが読むべきメールの数が減少されるようにして、メール受信者のユーザビリティを向上させる技法を提供することを目的とする。また、本発明は、チーム・メンバが重要なイベント内容を上記メール中において容易に認識することを可能にする技法を提供することを目的とする。

本発明は、イベントの通知を送信先クライアントに送信する方法を提供する。当該方法は、
上記受信した通知から生成されるイベント・データが当該イベントに関連付けられたプロファイル中の条件式とマッチする場合に、当該イベント・データを、当該イベントに対応する変更管理情報及び当該変更管理情報の受信者の少なくとも１つに関連付けられたキューに格納するステップであって、当該格納するステップは上記プロファイルに基づいて上記イベント・データに転送時期を設定するステップを含む、上記格納するステップと、
上記キュー内に格納されたイベント・データに設定された転送時期の最も早い時期が到来することに応じて、上記キュー内に格納された全てのイベント・データを１つの通知として上記受信者のクライアント（送信先クライアントである）に送信するステップと
を含む。

本発明の１つの実施態様において、上記送信するステップが、上記キュー内に格納されたイベント・データに個々に設定された転送時期のうち最も早い時期が到来することに応じて、当該キュー内に格納された全てのイベント・データを１つの通知として上記受信者のクライアントに送信するステップを含みうる。

本発明の１つの実施態様において、上記設定するステップが、
上記イベント・データが格納されるキューに転送時期が設定されていない場合、上記イベント・データに設定された転送時期を上記キューに設定するステップと、
上記イベント・データが格納される上記キューに転送時期が設定されている場合において、上記イベント・データに設定された転送時期が上記キューに設定された転送時期よりも早いことに応じて、上記キューに設定された転送時期を上記イベント・データに設定された転送時期に更新するステップと
を含みうる。本発明の１つの実施態様において、上記送信するステップが、上記キューに設定された転送時期に行われうる。

本発明の１つの実施態様において、上記設定するステップが、上記プロファイルに基づいて上記イベント・データに重要度を設定するステップをさらに含みうる。

本発明の１つの実施態様において、上記格納するステップが、上記イベント・データのイベントに対応する変更管理情報のキューがないことに応じて、上記イベント・データのイベントに対応する変更管理情報のキューをメモリ内に用意するステップをさらに含みうる。

本発明の１つの実施態様において、上記格納するステップが、上記プロファイルをサーバ中の記憶装置から読み取るステップをさらに含みうる。

本発明の１つの実施態様において、上記キューが、上記イベントに対応する変更管理情報と少なくとも１の上記受信者とに関連付けられていてもよい。また、本発明の１つの実施態様において、上記格納するステップが、上記イベント・データを、複数のキューに格納するステップをさらに含みうる。また、本発明の１つの実施態様において、上記送信するステップが、上記１つの通知を上記キューに関連付けられた複数の受信者の各クライアントに送信するステップを含みうる。

本発明の１つの実施態様において、上記１つの通知が、（１）高い重要度を設定されたイベント・データのイベント内容と、（２）低い重要度を設定されたイベント・データを格納する場所を示すリンク、低い重要度を設定されたイベント・データのイベント内容を要約した内容、又は、上記低い重要度を設定されたイベント・データのイベント内容と、当該低い重要度を設定されたイベント・データのイベント内容が上記高い重要度を設定されたイベント・データのイベント内容よりも小さく表示されるように設定する属性とを含みうる。また、本発明の１つの実施態様において、上記１つの通知が、高い重要度を設定されたイベント・データのイベント内容と、当該高い重要度を設定されたイベント・データのイベント内容が強調表示されるように設定する属性とを含みうる。また、本発明の１つの実施態様において、上記１つの通知が、複数のイベント・データのイベント内容を要約した内容を含みうる。

本発明の１つの実施態様において、上記プロファイルが、上記受信者のユーザ・プロファイル、プロジェクト・プロファイル、又はそれらの組み合わせでありうる。本発明の１つの実施態様において、上記ユーザ・プロファイルが、電子カレンダに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期を含みうる。本発明の１つの実施態様において、上記プロジェクト・プロファイルが、プロジェクトに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期、並びに任意的に当該条件式に関連付けられた重要度を含みうる。また、本発明の他の実施態様において、上記プロジェクト・プロファイルが、電子カレンダに関連付けられた少なくとも１つの条件式、当該条件式に関連付けられた転送時期、及び任意的に当該条件式に関連付けられた重要度を含みうる。

また、本発明は、イベントの通知を送信先クライアントに送信するコンピュータ・プログラムを提供する。本発明の１つの実施態様において、当該コンピュータ・プログラムは、サーバに、上記方法に記載の各ステップを実行させる。

また、本発明は、イベントの通知を送信先クライアントに送信するコンピュータ、特にサーバを提供する。当該サーバは、
イベントの発生に応じて当該イベントに対応する通知を受信する受信手段と、
上記受信した通知から生成されるイベント・データが当該イベントに関連付けられたプロファイル中の条件式とマッチする場合に、当該イベント・データを格納し、且つ当該イベントに対応する変更管理情報及び当該変更管理情報の受信者の少なくとも１つに関連付けられているキューであって、当該キューに格納されたイベント・データは、上記プロファイルに基づいて設定された転送時期を有する、上記キューと、
上記キュー内に格納されたイベント・データに設定された転送時期の最も早い時期が到来することに応じて、上記キュー内に格納された全てのイベント・データを１つの通知として上記受信者のクライアント（送信先クライアントである）に送信する送信手段と
を備えている。

本発明の実施態様に従うと、イベントに対応する通知から生成され、且つサーバにキューイングされたイベント・データが１つまとめられて、１つの通知（以下、「サマリ・メール」ともいう）として、スケジューラによって指定された時間に受信者であるチーム・メンバに送信される。従って、チーム・メンバがサーバから受信する通知の数を減少することが可能である。このことはまた、ネットワークの負荷の低減をもたらしうる。また、本発明の実施態様に従うと、上記サマリ・メールにおいて、重要度の高いイベント・データのイベント内容は強調表示されうる。従って、チーム・メンバは、重要度の高いイベント・データのイベント内容を見過ごす可能性が低減される。

イベントの発生を伴うアプリケーションのユーザ画面のインタフェースの例を示す。 チーム・リーダによって入力されたデータがメッセージとしてサーバに送信され、当該サーバが受信者であるチーム・メンバに当該メッセージのそれぞれから作成されたイベント・データに対応するメールを送信する態様を示す。 本発明の実施態様に従い、チーム・リーダによって入力されたデータがメッセージとしてサーバに送信され、当該サーバが受信者であるチーム・メンバに当該メッセージから作成されたイベント・データに対応する１つの通知を送信する態様を示す。 本発明の実施態様に従い、サーバに用意されたキューにおいて、当該キュー内に格納されたイベント・データに個々に設定された転送時期のうち最も早い時期が到来することに応じて、当該キュー内に格納された全てのイベント・データを１つの通知として、チーム・メンバに送信する態様を示す。 本発明の実施態様に従い、サーバに用意されたキューにおいて、当該キューに設定された転送時期の最も早い時期が到来することに応じて、当該キュー内に格納された全てのイベント・データを１つの通知として、チーム・メンバに送信する態様を示す。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。 本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。 本発明の実施形態におけるコンピュータ・ハードウェアの基本的なブロック図を示す。 図８に示すコンピュータ・ハードウェアの機能を有し、本発明の実施態様に従うサーバ及びクライアントの機能ブロック図、並びにサーバとクライアントとを含むネットワーク環境を示す。 本発明の実施態様に従い、イベントの通知を含むイベント・データをサーバに用意されたキューに格納する処理のフロー・チャートを示す。 本発明の実施態様に従い、キュー中のイベント・データを１つの通知として受信者に送信する処理のフロー・チャートを示す。 本発明の実施態様に従い、図１０のステップのうちのプロファイルを用いてイベント・データを評価する処理の詳細なフロー・チャートを示す。 本発明の実施態様に従い、図１０のステップのうちのプロファイルを用いてイベント・データを評価する処理の詳細なフロー・チャートを示す。 本発明の実施態様に従い、図１０のステップのうちのイベント・データをキューへ追加する処理の詳細なフロー・チャートを示す。 本発明の実施態様に従い、キュー中の複数のイベント・データを１つの通知にまとめる態様を示す。

本発明の実施形態を、以下に図面に従って説明する。以下の図を通して、特に断らない限り、同一の符号は同一の対象を指す。本発明の実施形態は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。

図１は、イベントの発生を伴うアプリケーションのユーザ画面のインタフェースの例を示す。
ユーザ画面（１０１）は、典型的には、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を使用して表示されうる。また、ＧＵＩは、イベントの発生を伴うアプリケーションによるインタフェース、又は、ウェブ・ブラウザ・ベースのインタフェースでありうる。

ユーザ画面（１０１）は、コラボレーションによりソフトウェア開発を行うためのアプリケーションのアイテム編集画面の例である。ユーザ画面は、プロジェクトに関する各種レコード（１０２）、及び入力データを「保存」するための機能を有するボタン（１０３）を備えている。図１に示されている各種レコード（１０２）の内容は例示であって、これらに制限されるものでないことに留意されたい。各種レコードの項目は、イベントの発生を伴うアプリケーションの性質に従い、当業者によって適宜変更されうる。ユーザ、例えばチーム・リーダは、各種レコードに対応するデータを直接入力し又は編集し、又は所定の項目を選択することによって各種レコードに入力することが可能である。

ユーザは、各種レコードにデータを１つ又は複数入力するごとに、「保存」ボタン（１０３）をマウス等でクリックしうる。または、所定の時間経過後に、「保存」ボタン（１０３）がクリックされた場合と同じ命令がコンピュータに入力されるようにしてもよい。

図２は、チーム・リーダによって入力されたデータがメッセージとしてサーバに送信され、当該サーバが受信者であるチーム・メンバに当該メッセージのそれぞれから作成されたイベント・データに対応するメールを送信する態様を示す。当該態様については、上述した通りであるので、その説明を省略する。

図３は、本発明の実施態様に従い、チーム・リーダによって入力されたデータがメッセージとしてサーバに送信され、当該サーバが受信者であるチーム・メンバに当該メッセージから作成されたイベント・データに対応する１つの通知を送信する態様を示す。受信者は、例えばサーバ（３０２）が変更管理システムの場合、購読者又はサブスクライバとも呼ばれる。
チーム・リーダ（３０１）のコンピュータは、ネットワークを介してサーバ（３０２）に接続されている。サーバ（３０２）は、同様に、ネットワークを介して少なくとも１つのチーム・メンバ（３０３）のコンピュータに接続されている。ネットワークは、インターネット及びイントラネットのいずれであってもよい。また、チーム・リーダ（３０１）のコンピュータ及びチーム・メンバ（３０３）のコンピュータは、サーバ（３０２）と無線又は有線のいずれで接続されていてもよい。

チーム・リーダ（３０１）が、何らかのハードウェア的又はソフトウェア的な問題により入力データが損失することを避けるために、１つ又は複数のレコードを編集する毎に、又は、１つのレコードを繰り返し編集する毎に（３１１、３１２、３１３及び３１４）、入力データを保存する場合がある。チーム・リーダ（３０１）のコンピュータは、当該入力データの保存毎に当該入力データを通知、例えばメッセージ（３３１、３３２、３３３）としてサーバ（３０２）に送信する（３２１）。サーバ（３０２）は、当該メッセージ（３３１、３３２及び３３３）に対応するイベント・データをワーク・アイテム毎に又はワーク・アイテムの少なくとも１の受信者毎に用意された少なくとも１つのキュー（例えば、３４１、３４２及び３４３）に格納する。そして、サーバは、当該各キュー（３４１、３４２及び３４３）内に格納された全てのイベント・データを、キュー毎に１つの通知（サマリ・メール）、例えば、１通の電子メール又は１通のインスタント・メッセージにまとめる。そして、サーバ（３０２）は、当該１つのまとめられた通知（３２２）を各キューに関連付けられた少なくとも１つの受信者であるチーム・メンバ（３０３）のコンピュータに送信する。当該１つの通知（３２２）は、メッセージ（３３１、３３２及び３３３）に対応するイベント・データの全ての内容又はその一部を含みうる。チーム・メンバ（３０３）は、図２に示す態様と異なり、メッセージ（３３１、３３２、３３３）毎にメールを受けることがないので、読むべきメールの数が減少される。従って、チーム・メンバのユーザビリティの向上が図られる。

以下の図４〜図７Ｅにおいて、図３に示した態様を実現するための方法をさらに詳細に説明する。

図４は、本発明の実施態様に従い、サーバに用意されたキューにおいて、当該キュー内に格納されたイベント・データに個々に設定された転送時期のうち最も早い時期が到来することに応じて、当該キュー内に格納された全てのイベント・データを１つの通知として、チーム・メンバに送信する態様を示す。

サーバ（３０２）は、第１の変更管理情報（例えば、第１のワーク・アイテム）及び少なくとも１の受信者（例えば、チーム・メンバ（４０５））であるチーム・メンバのいずれか１つに少なくとも関連付けられているキュー（４０３）と、第２の変更管理情報（例えば、第２のワーク・アイテム）及び少なくとも１の受信者であるチーム・メンバ（例えば、チーム・メンバ（４０５））のいずれか１つに関連付けられているキュー（４０４）とをそのメモリ内に用意している。キューは、イベント・データをキューイングする。各イベント・データは、例えば、イベント名、イベント番号、転送時期（送信日時）、到着日時、及び任意的にイベント・データの重要度についての情報を備えうる。

キュー（４０３）は、イベント・データ（４１１、４１２及び４１３）をキューイングしている。イベント・データ（４１１）は、イベント名が「ｅｖ１」であり、転送時期が「午前１０時」（１０ａｍ）であり、及び重要度が「中」（ｍｉｄ）である。イベント・データ（４１２）は、イベント名が「ｅｖ２」であり、転送時期が「午前１１時」（１１ａｍ）であり、及び重要度が「中」（ｍｉｄ）である。イベント・データ（４１３）は、イベント名が「ｅｖ３」であり、転送時期が「午前１２時」（１２ａｍ）であり、及び重要度が「中」（ｍｉｄ）である。よって、キュー（４０３）内に格納されたイベント・データ（４１１、４１２及び４１３）のうち、その転送時期が最も早い時期は「午前１０時」である。従って、サーバ（３０２）は、午前１０時になることに応じて、その時点でキュー（４０３）内に格納されたイベント・データ（４１１、４１２及び４１３）を１つのメール（４５１）にまとめて、チーム・メンバ（４０５）に送信する（４３１）。また、３つのイベント・データ（４１１、４１２及び４１３）の重要度は全て「中」であるので、１つのメール（４５１）中において各イベント・データ（４１１、４１２及び４１３）の内容は同等の大きさで表示されるようにまとめられうる。チーム・メンバ（４０５）は、各イベント・データ（４１１、４１２及び４１３）に対応する３つのメールを受け取る代わりに、１つのメール（４５１）を受け取るだけですむ。従って、チーム・メンバ（４０５）のメールを確認する負担が軽減される。また、サーバ（３０２）からチーム・メンバ（４０５）への通信経路の通信コストが低減される。

キュー（４０４）は、イベント・データ（４２１、４２２及び４２３）をキューイングしている。イベント・データ（４２１）は、イベント名が「ｅｖ４」であり、転送時期が「午後１０時」（１０ｐｍ）であり、及び重要度が「中」（ｍｉｄ）である。イベント・データ（４２２）は、イベント名が「ｅｖ５」であり、転送時期が「午後１１時」（１１ｐｍ）であり、及び重要度が「中」（ｍｉｄ）である。イベント・データ（４２３）は、イベント名が「ｅｖ６」であり、転送時期が「今すぐ」（ｎｏｗ）であり、及び重要度が「高」（ｈｉｇｈ）である。よって、キュー（４０４）内に格納されたイベント・データ（４２１、４２２及び４２３）のうち、その転送時期が最も早い時期は「今すぐ」である。従って、サーバ（３０２）は、イベント・データ（４２３）がキュー（４０４）に格納されることに応じて、キュー（４０４）内に格納されたイベント・データ（４２１、４２２及び４２３）を１つのメール（４５２）にまとめて、チーム・メンバ（４０５）に直ちに送信する（４３２）。イベント・データ（４２１、４２２及び４２３）のうち、イベント・データ（４２１及び４２２）の重要度はいずれも「中」であり、且つイベント・データ（４２３）の重要度は「高」であることから、メール（４５２）においてイベント・データ（４２３）の内容はイベント・データ（４２１及び４２２）の内容よりも強調して（例えば、大きい文字で又は色付けされて）表示されるようにまとめられうる。または、イベント・データ（４２３）の内容は１つのメール（４５２）中に直接表示されているが、イベント・データ（４２１及び４２２）の内容はメール（４５２）中に直接表示されず、イベント・データ（４２１及び４２２）の内容が格納されている場所を示すリンク・データが張られていてもよい。チーム・メンバ（４０５）は、各イベント・データ（４２１、４２２及び４２３）に対応する３つのメールを受け取る代わりに、１つのメール（４５２）を受け取るだけですむ。また、１つのメール（４５２）においてイベント・データ（４２３）の内容が強調表示されているので、チーム・メンバ（４０５）は、イベント・データ（４２１、４２２及び４２３）のうち重要度の高いイベント・データ（４２３）の内容を容易に認識しうる。従って、チーム・メンバ（４０５）のメールを確認する負担が軽減されるとともに、重要度の高いイベント・データ（４２３）の内容を見過ごす危険が軽減される。また、サーバ（３０２）からチーム・メンバ（４０５）への通信経路の通信コストが低減される。

図５は、本発明の実施態様に従い、サーバに用意されたキューにおいて、当該キューに設定された転送時期の最も早い時期が到来することに応じて、当該キュー内に格納された全ての通知を１つの通知として、チーム・メンバに送信する態様を示す。
図５の実施態様は、キューにタイマーが設けられている点において図４に示す実施態様と異なる。
サーバ（３０２）は、第１の変更管理情報（例えば、第１のワーク・アイテム）及び少なくとも１の受信者（例えば、チーム・メンバ（５０５））であるチーム・メンバのいずれか１つに少なくとも関連付けられているキュー（５０３）と、第２の変更管理情報（例えば、第２のワーク・アイテム）及び少なくとも１の受信者であるチーム・メンバ（例えば、チーム・メンバ（５０５））のいずれか１つに関連付けられているキュー（５０４）とをそのメモリ内に用意している。

キュー（５０３）は、イベント・データ（５１１、５１２及び５１３）をキューイングしている。サーバ（３０２）は、イベント・データ（５１１、５１２及び５１３）がキュー（５０３）内に順次到来することに応じて、キュー（５０３）に付随する転送時期を示すタイマー（５０６）の日時を到来するイベント・データの転送時期と比較して、早い方の日時にキューのタイマー（５０６）の日時を更新する。同様に、サーバ（３０２）は、イベント・データ（５２１、５２２及び５２３）がキュー（５０４）内に順次到来することに応じて、キュー（５０４）に付随する転送時期を示すタイマー（５０７）の日時を到来するイベント・データの転送時期と比較して、早い方の日時にキューのタイマー（５０７）の日時を更新する。

イベント・データ（５１１）がキュー（５０３）に最初にキューイングされたイベント・データであるとする。キュー（５０３）では、イベント・データ（５１１）の転送時期（午前１０時）がキュー（５０３）のタイマー（５０６）に設定された後、それよりも早い転送時期を有するイベント・データがキューイングされない。よって、タイマー（５０６）の転送時期は更新されない。従って、サーバ（３０２）は、タイマー（５０６）に設定された転送時期である「午前１０時」になることに応じて、その時点でキュー（５０３）内に格納されたイベント・データ（５１１、５１２及び５１３）を１つのメールにまとめて、当該まとめられた１つのメール（５５１）をチーム・メンバ（５０５）に送信する（５３１）。

イベント・データ（５２１）がキュー（５０４）に最初にキューイングされたイベント・データであるとする。キュー（５０４）では、イベント・データ（５２１）の転送時期（午後１０時）がキュー（５０４）のタイマー（５０７）に設定された後、それよりも遅い転送時期（午後１１時）を有するイベント・データ（５２２）がキューイングされる。そのために、タイマー（５０７）の転送時期は「午後１０時」から変更されない。次に、イベント・データ（５２３）がキューイングされる。当該イベント・データ（５２３）の転送時期は「今すぐ（now）」である。従って、現在時刻は午後１０時より前であるので、タイマー（５０７）の転送時期は「午後１０時」から「今すぐ」に更新される。サーバ（３０２）は、タイマー（５０７）に転送時期が「今すぐ」であることから、イベント・データ（５２３）がキュー（５０４）にキューイングされることに応じてキュー（５０４）内に格納されたイベント・データ（５２１、５２２及び５２３）を１つのメールにまとめて、当該まとめられた1つのメール（５５２）をチーム・メンバ（５０５）に直ちに送信する（５３２）。

図６Ａ〜図６Ｆは、本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されないケースを説明するための図である。

（図６Ａ）
ユーザＡ（６０１）が、イベントの発生を伴うアプリケーション、例えばＲａｔｉｏｎａｌ Ｔｅａｍ Ｃｏｎｃｅｒｔ（以下、ＲＴＣという）（ＩＢＭ（商標）の商標である）の端末ソフトウェアを起動する。そして、ユーザＡ（６０１）は、ワーク・アイテム（タスクＮｏ．２６）を選択し、当該ワーク・アイテム（タスクＮｏ．２６）に対応するユーザ画面（６１１）を画面上に表示させる。ユーザ画面（６１１）の表示直後のレコード「優先順位」は、「割り当てなし」である（６２１）。

（図６Ｂ）
ユーザＡ（６０１）が、２０１０年１１月１９日２０時３５分５秒に、ユーザ画面（６１１）を介して「優先順位」を「割り当てなし」（６２１）から「中」（６２２）に変更して保存したとする。当該保存に応じて、ユーザＡ（６０１）のコンピュータは、当該編集に対応するメッセージをサーバ（６０２）（例えば、ＲＴＣサーバ）に送信する。サーバ（６０２）は、ユーザＡ（６０１）のコンピュータから当該メッセージを受信する。サーバ（６０２）は、当該受信したメッセージに基づいて、対応するイベント・データ（６４１）を作成する。イベント・データ（６４１）のデータ構造（６６１）は、例えば図６Ｂに示す通りである。イベント・データ（６４１）のデータ構造（６６１）は、ワーク・アイテムの更新情報、及び更新後情報を有する。更新情報は、ユーザによって変更された属性の名前、並びに更新前及び更新後の属性値でありうる。イベント・データ（６４１）の例では、更新情報は、優先順位が「割り当てなし」から「中」に変更されたという情報である。また、更新後情報は、一般的に、更新後の全てのワーク・アイテムの全ての属性の名前と値（属性値ともいう）とのペアを含みうる。イベント・データ（６４１）の例では、更新後情報は、ワーク・アイテムの更新時間、ワーク・アイテムＩＤ、チーム・エリア、所有者（サブスクライバのうちの一人でもある）、及び優先順位である。サーバ（６０２）は、イベント・データ（６４１）中のワーク・アイテムＩＤに対応するキューがなければ、各受信者の数（人数分）に対応するキューをメモリ中に用意する。図６Ｂでは、ユーザＢ（user_b）用のキュー（６３１）がサーバ（６０２）内に用意されている。受信者は、ユーザＡ（６０１）が、例えば画面（６１１）を通じて指定又は追加可能でありうる。

（図６Ｃ）
サーバ（６０２）は、イベント・データ（６４１）を、サーバ（６０２）の記憶装置に格納されたユーザ・プロファイル（６７１）及びプロジェクト・プロファイル（６７２）のいずれか又はその両方を参照し、イベント・データ（６４１）のデータ構造（６６１）にプロファイル情報を追加する。プロファイル情報を追加されたイベント・データ（６４１）のデータ構造（６６２）は、プロファイル情報として、当該イベント・データの受信者への転送時期及び任意的に重要度を有する。

イベント・データ（６６１）へのプロファイル情報の追加は、下記のようにして行われる。サーバ（６０２）は、プロファイル（６７１又は６７２）を参照して、当該プロファイルの条件式中にイベント・データ（６４１）がマッチする条件を見つける。プロファイルは、ユーザ・プロファイル（６７１）及びプロジェクト・プロファイル（６７２）のいずれか又はその両方でありうる。いずれの又は両方のプロファイルを使用するかどうかは、例えば、各受信者によって指定されうる。図６Ｃでは、イベント・データ（６４１）のうちの所有者「user_b」が、プロジェクト・プロファイル（６７２）の条件式Ｐ２とマッチする。従って、サーバ（６０２）は、条件式Ｐ２において定義されている転送時期「１時間毎」（基準時間を毎時０分に設定している）及び任意的に重要度「中」をプロファイル情報としてイベント・データ（６４１）のデータ構造（６６１）に追加して、データ構造（６６２）を生成する。

（図６Ｄ）
サーバ（６０２）は、イベント・データ（６４１）のデータ構造（６６２）中のプロファイル情報を参照して、当該プロファイル情報にある転送時期を、キュー（６３１）のタイマーに設定された転送時期と比較する。キュー（６３１）のタイマーに転送時期が設定されていなければ、サーバ（６０２）は、イベント・データ（６４１）のプロファイル情報である転送時期をタイマーの転送時期に設定する。一方、キュー（６３１）のタイマーに転送時期がすでに設定されていれば、サーバ（６０２）は、イベント・データ（６４１）の上記転送時期とタイマーの転送時期とを比較する。そして、サーバ（６０２）は、イベント・データ（６４１）の上記転送時期がタイマーの転送時期よりも早く到来する場合は、タイマーの転送時期を、イベント・データ（６４１）の上記転送時期に更新し、イベント・データ（６４１）の上記転送時期がタイマーの転送時期よりも早く到来しない場合は、タイマーの転送時期を更新しない。サーバ（６０２）は、転送時期の上記比較が終わることに応じて、イベント・データ（６４１）を、キュー（６３１）に格納する。図６Ｄでは、イベント・データ（６４１）のデータ構造（６６２）において更新時間が２０１０年１１月１９日２０時３５分０５秒であり、転送時期は１時間毎である。そして、キュー（６３１）のタイマーは初期状態であり、すなわち転送時期が設定されていない。よって、サーバ（６０２）は、更新されたイベント・データ（６４１）の上記転送時期をキュー（６３１）のタイマーに設定する。従って、キュー（６３１）のタイマーのデータ構造（６８１）は、送信日時が上記２０時３５分０５秒の直後の「午後９時」であることを示す。

（図６Ｅ）
ユーザＡ（６０１）が、２０１０年１１月１９日２０時４０分から同２０時５５分までの間に、ユーザ画面（６１１）を通じて、各レコードの編集及び保存を繰り返したとする。その結果、サーバ（６０２）にイベント・データ（６４２）及びイベント・データ（６４３）が順にキューイングされたとする。イベント・データ（６４２）は、ユーザ画面（６１１）中の「説明」のレコードに「通常通り進めてください。」という文字（６２３）が追加されたというイベントに対応して生成されたイベント・データである。イベント・データ（６４３）は、ユーザ画面（６１１）中の「見積もり」に「２日」というデータ（６２４）が入力されたというイベントに対応して生成されたイベント・データである。

イベント・データ（６４２）のうちの所有者「user_b」が、プロジェクト・プロファイル（下記図６Ｃの６７２）の条件式Ｐ２とマッチする。従って、サーバ（６０２）は、条件式Ｐ２において定義されている転送時期「１時間毎」（基準時間を毎時０分に設定している）及び任意的に重要度「中」をプロファイル情報としてイベント・データ（６４２）のデータ構造に追加し、データ構造（６６３）に更新する。

同様に、イベント・データ（６４３）のうちの所有者「user_b」が、プロジェクト・プロファイル（６７２）の条件式Ｐ２とマッチする。従って、サーバ（６０２）は、条件式Ｐ２において定義されている転送時期「１時間毎」（基準時間を毎時０分に設定している）及び任意的に重要度「中」をプロファイル情報としてイベント・データ（６４３）のデータ構造に追加し、データ構造（６６４）に更新する。

サーバ（６０２）は、イベント・データ（６４２）がキュー（６３１）にキューイングされることに応じて、イベント・データ（６４２）のデータ構造（６６３）中のプロファイル情報を参照する。当該プロファイル情報にある転送時期は「１時間毎」であるので、イベント・データ（６４２）の送信時間は、当該イベント・データ（６４２）に対応するイベントが発生した時間（２０１０年１１月１９日２０時４０分から同２０時５５分）の直後の午後９時である。サーバ（６０２）は、キュー（６３１）に設定された送信時間「午後９時」がイベント・データ（６４２）の送信時間「午後９時」と同じであることから、キュー（６３１）に設定された送信時間を更新しない。従って、キュー（６３１）に設定された送信時間は、「午後９時」のままである。

サーバ（６０２）は、次に、イベント・データ（６４３）がキュー（６３１）にキューイングされることに応じて、イベント・データ（６４３）のデータ構造（６６４）中のプロファイル情報を参照する。当該プロファイル情報にある転送時期は「１時間毎」であるので、イベント・データ（６４３）の送信時間は、午後９時である。サーバ（６０２）は、キュー（６３１）に設定された送信時間「午後９時」がイベント・データ（６４３）の送信時間「午後９時」と同じであることから、キュー（６３１）に設定された送信時間を更新しない。従って、キュー（６３１）に設定された送信時間は、「午後９時」のままである。

（図６Ｆ）
サーバ（６０２）は、キュー（６３１）に設定された送信時間「２０１０年１１月１９日午後９時」と現在時刻とを比較して、当該送信時間が到来することに応じて、キュー（６３１）内にある全てのイベント・データ（６４１、６４２及び６４３）を１つの通知にまとめて、当該１つの通知（例えば、メール）をユーザＢ（６０３）（user_b）のコンピュータに送信する（６９０）。当該１つの通知の内容は、例えば、イベント・データ（６４１、６４２及び６４３）のうちの各更新情報のみを要約として列挙した内容でありうる（６９１）。

図７Ａ〜図７Ｅは、本発明の実施態様に従い、サーバに用意されたキューにおいて、後続のイベント・データによって送信時期が更新されるケースを説明するための図である。

（図７Ａ）
ユーザＡ（７０１）が、２０１０年１１月１９日２１時００分から同２１時５５分までの間に、ユーザ画面（７１１）を通じて、各レコードへの編集及び保存を繰り返したとする。その結果、サーバ（７０２）にイベント・データ（７４１）及びイベント・データ（７４２）が順にキューイングされたとする。イベント・データ（７４１）は、ユーザ画面（７１１）中の「ディスカッション」のレコードに「急遽、方針Ｘに変わりました。」という文字（７２２）が追加されたというイベントに対応して生成されたイベント・データである。イベント・データ（７４２）は、ユーザ画面（７１１）中の「優先順位」を「中」から「高」に変更した（７２１）というイベントに対応して生成されたイベント・データである。

イベント・データ（７４１）のうちの所有者「user_b」が、プロジェクト・プロファイル（下記図７Ｃの７７２）の条件式Ｐ２とマッチする。従って、サーバ（７０２）は、条件式Ｐ２において定義されている転送時期「１時間毎」（基準時間を毎時０分に設定している）及び任意的に重要度「中」をプロファイル情報としてイベント・データ（７４１）のデータ構造に追加し、データ構造（７６３）に更新する。

同様に、イベント・データ（７４２）のうちの所有者「user_b」が、プロジェクト・プロファイル（７７２）の条件式Ｐ２とマッチする。従って、サーバ（７０２）は、条件式Ｐ２において定義されている転送時期「１時間毎」（基準時間を毎時０分に設定している）及び任意的に重要度「中」をプロファイル情報としてイベント・データ（７４２）のデータ構造に追加し、データ構造（７６４）に更新する。

サーバ（７０２）は、イベント・データ（７４１）がキュー（７３１）にキューイングされることに応じて、イベント・データ（７４１）のデータ構造（７６３）中のプロファイル情報を参照する。当該プロファイル情報にある転送時期は「１時間毎」であるので、イベント・データ（７４１）の送信時間は、当該イベント・データ（７４１）に対応するイベントが発生した時間（２０１０年１１月１９日２１時００分から同２１時５５分）の直後の「午後１０時」である。サーバ（７０２）は、キュー（７３１）のタイマーに転送時期が設定されていなければ、更新されたイベント・データ（７４１）の転送時期「午後１０時」をタイマーの転送時期に設定する。

サーバ（７０２）は、次に、イベント・データ（７４２）がキュー（７３１）にキューイングされることに応じて、イベント・データ（７４２）のデータ構造（７６４）中のプロファイル情報を参照する。当該プロファイル情報にある転送時期は「１時間毎」であるので、イベント・データ（７４２）の送信時間は、当該イベント・データ（７４２）に対応するイベントが発生した時間（２０１０年１１月１９日２１時００分から同２１時５５分）の直後の午後１０時である。サーバ（７０２）は、キュー（７３１）に設定された送信時間「午後１０時」がイベント・データ（７４２）の送信時間「午後１０時」と同じであることから、キュー（７３１）に設定された送信時間を更新しない。すなわち、キュー（７３１）に設定された送信時間は、「午後１０時」のままである。

（図７Ｂ）
ユーザＡ（７０１）が、２０１０年１１月１９日２１時３２分４４秒に、ユーザ画面（７１１）を介して「期限」を「２０１０年１１月１９日」（今日）（７２３）に編集して保存したとする。当該保存に応じて、ユーザＡ（７０１）のコンピュータは、当該編集に対応するメッセージをサーバ（７０２）に送信する。サーバ（７０２）は、ユーザＡ（７０１）のコンピュータから当該メッセージを受信する。サーバ（７０２）は、当該受信したメッセージに基づいて、対応するイベント・データ（７４３）を作成する。イベント・データ（７４３）のデータ構造（７６５）は、例えば図７Ｂに示す通りである。イベント・データ（７４３）のデータ構造（７６５）は、ワーク・アイテムの更新情報及び更新後情報を有する。イベント・データ（７６５）の例では、更新情報は、期限が「なし」から「２０１０／１１／１９」に変更されたという情報である。サーバ（７０２）は、イベント・データ（７６５）中のワーク・アイテムＩＤに対応するキューがなければ、各受信者の数（人数分）に対応するキューをメモリ中に用意する。図７Ｂでは、ユーザＢ（user_b）用のキュー（７３１）がサーバ（７０２）内に用意されている。受信者は、ユーザＡ（７０１）が、例えば画面（７１１）を通じて指定又は追加可能でありうる。

（図７Ｃ）
サーバ（７０２）は、イベント・データ（７４３）を、サーバ（７０２）の記憶装置に格納されたユーザ・プロファイル（７７１）及びプロジェクト・プロファイル（７７２）のいずれか又はその両方を参照して、イベント・データ（７４３）のデータ構造（７６５）にプロファイル情報を追加する。プロファイル情報を追加されたイベント・データ（７４３）のデータ構造（７６６）は、プロファイル情報として、当該イベント・データの転送時期及び任意的に重要度を有する。

イベント・データ（７４３）へのプロファイル情報の追加は、下記のようにして行われる。サーバ（７０２）はプロファイルを参照して、当該プロファイルの条件式中にイベント・データ（７４３）がマッチする条件を見つける。プロファイルは、ユーザ・プロファイル（７７１）及びプロジェクト・プロファイル（７７２）のいずれか又はその両方でありうる。いずれの又は両方のプロファイルを使用するかどうかは、例えば、受信者によって指定されうる。図７Ｃでは、イベント・データ（７４３）のうちの期限「2010/11/19」が、プロジェクト・プロファイル（７７２）の条件式Ｐ１「期限＝今日」とマッチする。従って、サーバ（７０２）は、条件式Ｐ１において定義されている転送時期「今すぐ」及び重要度「高」をプロファイル情報としてイベント・データ（７４３）のデータ構造（７６５）に追加し、データ構造（７６６）を生成する。

（図７Ｄ）
サーバ（７０２）は、イベント・データ（７４３）のデータ構造（７６６）中のプロファイル情報を参照して、当該プロファイル情報にある転送時期を、キュー（７３１）のタイマーに設定された転送時期と比較する。図７Ｄでは、イベント・データ（７４３）のデータ構造（７６６）において更新時間が「今すぐ」である。一方、キュー（７３１）のタイマーの転送時期は、「午後１０時」である。よって、サーバ（７０２）は、キュー（７３１）のタイマーの転送時期を、イベント・データ（７４３）のデータ構造（７６６）中の転送時期「今すぐ」に更新する。従って、サーバ（７０２）は、キュー（７３１）のタイマーのデータ構造（７８１）を、送信日時「2010/11/19 21:32:44」（今すぐ）に更新する（７８２）。

（図７Ｅ）
サーバ（７０２）は、現在時刻が、キュー（７３１）に設定された送信時間「今すぐ」（2010/11/19 21:32:44）であること（又はそれよりも過ぎていること）に応じて、キュー（７３１）内にある全てのイベント・データ（７４１、７４２及び７４３）を１つの通知にまとめて、当該１つの通知（７９０）をユーザＢ（７０３）（user_b）のコンピュータに送信する。イベント・データ（７４３）のデータ構造（７６６）のプロファイル情報において、イベント・データ（７４３）の重要度が「高」になっている。一方、イベント・データ（７４１）及びイベント・データ（７４２）の各データ構造（７６３及び７６４）のプロファイル情報において、各イベント・データ（７４１及び７４２）の重要度が「中」になっている。従って、上記１つの通知（７９０）の内容は、例えば、イベント・データ（７４３）の内容をイベント・データ（７４１及び７４２）の内容よりも強調して表示した内容でありうる（７９１）。または、上記１つの通知（７９０）の内容は、例えば、イベント・データ（７４１）の重要度が「中」であるので、イベント・データ（７４１）及び必要に応じてイベント・データ（７４２）の内容を格納したサーバ（７０２）の場所を示すリンクを有するようにしてもよい（７９２）。

図８は、本発明の実施形態におけるコンピュータ・ハードウェアの基本的なブロック図を示す。
コンピュータ（８０１）は、ＣＰＵ（８０２）とメイン・メモリ（８０３）とを備えており、これらはバス（８０４）に接続されている。ＣＰＵ（８０２）は好ましくは、３２ビット又は６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＣｏｒｅ ｉ（商標）シリーズ、Ｃｏｒｅ ２（商標）シリーズ、Ａｔｏｍ（商標）シリーズ、Ｘｅｏｎ（商標）シリーズ、Ｐｅｎｔｉｕｍ（登録商標）シリーズ、Ｃｅｌｅｒｏｎ（登録商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズ、Ｔｕｒｉｏｎ（商標）シリーズ又はＳｅｍｐｒｏｎ（商標）が使用されうる。バス（８０４）には、ディスプレイ・コントローラ（８０５）を介して、ディスプレイ（８０６）、例えば液晶ディスプレイ（ＬＣＤ）が接続されうる。ディスプレイ（８０６）は、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インタフェースで表示するために使用される。バス（８０４）にはまた、ＳＡＴＡ又はＩＤＥコントローラ（８０７）を介して、ディスク（８０８）、例えばハードディスク又はシリコン・ディスクと、ドライブ（８０９）、例えばＣＤ、ＤＶＤ又はＢＤドライブとが接続されうる。バス（８０４）にはさらに、キーボード・マウスコントローラ（８１０）又はＵＳＢバス（図示せず）を介して、キーボード（８１１）及びマウス（８１２）が接続されうる。

ディスク（８０８）には、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ（登録商標）処理環境、Ｊａｖａ（登録商標）アプリケーション、Ｊａｖａ（登録商標）仮想マシン（ＶＭ）、Ｊａｖａ（登録商標）実行時（ＪＩＴ）コンパイラを提供するプログラム、その他のプログラム、及びデータが、メイン・メモリにロード可能に記憶されている。
ドライブ（８０９）は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをディスク（８０８）にインストールするために使用される。

通信インタフェース（８１４）は、例えばイーサネット（登録商標）・プロトコルに従う。通信インタフェース（８１４）は、通信コントローラ（８１３）を介してバス（８０４）に接続され、コンピュータ（８０１）を通信回線（８１５）に物理的に接続する役割を担い、コンピュータ（８０１）のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境、又は例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。

図９は、図８に示すコンピュータ（８０１）のハードウェア機能を有し、本発明の実施態様に従うサーバ（９０２）並びにクライアント（９０１−１〜９０１−ｎ、及び９０３−１〜９０３−ｎ）の機能ブロック図、及びサーバ（９０２）とクライアント（９０１−１〜９０１−ｎ、及び９０３−１〜９０３−ｎ）とのネットワーク環境を示す。
サーバ（９０２）は、イベントの発生を伴うアプリケーションからイベントを受け取り、受信者に通知を送る機能を備えているものであれば特には限定されない。サーバ（９０２）は、例えば、変更管理システム、タスク管理システム、プロジェクト管理システム、品質管理システム、バグ管理システム、障害管理システム、又はトラック管理システムのサーバでありうる。上記アプリケーションとして、例えば、ＩＢＭ（商標）製品として、Rational Team Concert（商標）（http://www-06.ibm.com/software/jp/rational/products/scm/rtc/）、及びRational Clear Quest（商標）（http://www-06.ibm.com/software/jp/rational/products/scm/cq/）があり、その他に、Ｍｉｃｒｏｓｏｆｔ（商品）製品として、Team Foundation Server（商標）（http://www.microsoft.com/japan/visualstudio/products/2010-editions/team-foundation-server）があり、その他に、オープンソースとして、Bugzilla（http://www.bugzilla.org/）、Trac（http://trac.edgewall.org/）及び影舞（http://www.daifukuya.com/kagemai/）がある。また、クライアント（９０１−１〜９０１−ｎ、及び９０３−１〜９０３−ｎ）は、上記変更管理システム、タスク管理システム、プロジェクト管理システム、品質管理システム、バグ管理システム、障害管理システム、又はトラック管理システムにおける対応するクライアントでありうる。

サーバ（９０２）は、図８に示す例えばＣＰＵ（８０２）、メイン・メモリ（８０３）及びディスク（８０８）に加えて、受信手段（９１１）、イベント・データ生成手段（９１２）、プロファイル判定手段（９１３）、プロファイル記憶手段（９１４）、キュー処理手段（９１５）、及び送信手段（９１７）を備えうる。また、サーバ（９０２）は、クライアント（９０１−１〜９０１−ｎ、又は９０３−１）から、イベント・データに対応するメッセージを受信し、イベントに対応する変更管理情報のキューがないことに応じて、当該イベントに対応する変更管理情報のキュー（９１６−１〜９１６−ｎ）をメイン・メモリ（８０３）内に用意する。従って、サーバ（９０２）において、キュー（９１６−１〜９１６−ｎ）は動的にメモリ内に作成されうる。

受信手段（９１１）は、少なくとも１つのクライアント（９０１−１〜９０１−ｎ）から、イベントの発生に応じて送信される通知（例えば、メッセージ）を受け取り、例えばメモリのバッファ内に格納する。当該通知は、１つのイベントに対応して、クライアントによって１つ生成される。当該通知は、例えば、レコードの属性の、ユーザによって変更又は入力された値（以下、属性値ともいう）を含みうる。当該通知は、例えば、メール、メッセージ又はメタ・データの送信によって行われうる。

受信手段（９１１）は、当該通知からイベント・データを生成するために、当該通知をイベント・データ生成手段（９１２）に渡す。

イベント・データ生成手段（９１２）は、当該通知に基づいて、イベント・データを生成する。イベント・データは、例えば更新情報、及び更新後情報を含む。更新情報は、例えば、イベントにおいて、クライアント（９０１−１〜９０１−ｎ）のユーザによって変更された属性の名前、並びに更新前及び更新後の属性値でありうる。更新後情報はプロファイル中の各条件式とのマッチのために用いられる情報であって、更新情報を除く情報を保持しており、更新後の全てのワーク・アイテムの全ての属性の名前と値とのペアを含みうる。なお、プロファイル中の各条件式とのマッチにおいて、更新情報に関連付けられた属性の条件マッチには、更新情報中の更新後部分の情報が参照されうる。更新後情報は、例えば、属性値の更新時間（イベントの発生時間でもある）、変更管理情報の識別子、チーム・エリア、所有者（サブスクライバのうちの一人でもある）、及び優先順位でありうる。変更管理情報は、チェンジング・リクエストともいう。変更管理情報は、例えばワーク・アイテムである。

また、イベント・データ生成手段（９１２）は、上記イベント・データにプロファイル情報を追加するために、当該イベント・データをプロファイル判定手段（９１３）に渡す。

プロファイル判定手段（９１３）は、イベント・データ生成手段（９１２）からイベント・データを受け取る。そして、プロファイル判定手段（９１３）は、イベント・データ生成手段（９１２）からの上記イベント・データが、当該イベント・データのイベントに関連付けられたプロファイル中の条件式とマッチするかどうかを判定する。プロファイル判定手段（９１３）は、上記イベント・データが当該条件式とマッチする場合に、マッチする当該条件式に設定された転送時期（イベント・データの受信者への転送時期である）及び任意的に重要度（イベント・データの重要度である）をプロファイル情報としてイベント・データ生成手段（９１２）に渡す。イベント・データ生成手段（９１２）は当該プロファイル情報（例えば、転送時期、重要度又はそれらの組み合わせを含む）を受信して、当該受信したプロファイル情報をイベント・データに追加する。なお、イベント・データ生成手段（９１２）が、プロファイル判定手段（９１３）の機能を兼ね備えていてもよい。

プロファイル記憶手段（９１４）は、プロファイル判定手段（９１３）で使用されるプロファイルを記憶する。プロファイルは、例えば、ユーザ・プロファイル及びプロジェクト・プロファイルのいずれか又はその両方でありうる。プロファイルは、受信者毎に用意される。従って、例えば、ユーザＢには、ユーザＢ用のユーザ・プロファイル及びプロジェクト・プロファイルが用意される。受信者毎にプロファイルが用意される理由は、転送時期及び重要度がそれぞれ、受信者によって異なるケースがあるためである。ただし、各受信者を１つのチームとしてまとめ、当該まとめたチーム名を１つのユーザとして取り扱うことも可能である。

ユーザ・プロファイルは、電子カレンダに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期を含みうる。電子カレンダは、例えばサーバ（９０２）に格納されており、例えばスケジュール管理ソフトウェア、例えばＬｏｔｕｓ Ｎｏｔｅｓ（商標）のＬｏｔｕｓ Ｎｏｔｅｓ（商標）カンンダでありうる。条件式は、例えば、早朝、午前、午後、夜間、会議中、出張中、又は休暇中であり、例えば、デフォルトで又は受信者によって各条件式に対応する時間帯が予め登録されている。転送時期は、例えば、各条件式の終了時点であり、例えば、デフォルトで又は受信者によって各条件式に対応する転送時期が予め登録されている。

プロジェクト・プロファイルは、プロジェクトに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期、並びに任意的に上記条件式に関連付けられた重要度を含みうる。条件式は、例えば、チーム・エリア名、ワーク・アイテムＩＤ、又は変更管理情報の全属性及び属性値のペアであり、例えば、デフォルトで又は受信者によって各条件式に対応する期間又は時間帯が予め登録されている。転送時期は、例えば、各条件式の終了時点であり、例えば、デフォルトで又は受信者によって各条件式に対応する転送時期が予め登録されている。重要度は、重要度に応じてイベント・データの内容をどのように１つの通知にまとめるかを決定するための尺度である。重要度は、例えば、「高」、「中」及び「低」の３段階に設定されうる。

または、プロジェクト・プロファイルは、電子カレンダに関連付けられた少なくとも１つの条件式、当該条件式に関連付けられた転送時期、及び当該条件式に関連付けられた重要度を含みうる。条件式は、例えば、開発段階、試験段階、又は実用段階であり、例えば、デフォルトで又は受信者によって各条件式に対応する期間又は時間帯が予め登録されている。プロジェクト・プロファイルの電子カレンダに関連付けられた条件式がユーザ・プロファイルの電子カレンダに関連付けられた条件式と異なる点は、プロジェクト・プロファイルの電子カレンダに関連付けられた条件式が仕事に関連するスケジュールである点である。なお、プロジェクト・プロファイルの電子カレンダに関連付けられた条件式とユーザ・プロファイルの電子カレンダに関連付けられた条件式とが厳密に区別されなくともよい。転送時期は、例えば、各条件式の終了時点であり、例えば、デフォルトで又は受信者によって各条件式に対応する転送時期が予め登録されている。

キュー処理手段（９１５）は、イベント・データのイベントに対応する変更管理情報（例えば、ワーク・アイテム）のキューがないことに応じて、当該キューをメモリ内に用意する。キュー（９１６−１〜９１６−ｎ）は、イベント・データを一時的にキューイングするために使用される。当該キュー（９１６−１〜９１６−ｎ）は、イベントに対応する変更管理情報、当該変更管理情報の受信者、又はそれらの組み合わせに関連付けられている。例えば、キューは、ワーク・アイテムの識別子と、ワーク・アイテムの属性である受信者とをキーとして生成されうる。ワーク・アイテムの同じ識別子について複数の受信者が存在する場合があるので、キュー処理手段（９１５）は、ワーク・アイテムの同じ識別子に対応付けられた複数のキューを生成しうる。

キュー処理手段（９１５）は、キューをキュー集合により管理する。キュー処理手段（９１５）は、イベント・データが格納されるキューに転送時期が設定されていない場合、イベント・データに設定された転送時期をキューに設定する。また、キュー処理手段（９１５）は、イベント・データが格納されるキューに転送時期が設定されている場合において、当該イベント・データに設定された転送時期が上記キューに設定された転送時期よりも早いことに応じて、上記キューに設定された転送時期を当該イベント・データに設定された転送時期に更新する。

キュー処理手段（９１５）は、送信手段（９１７）が上記１つの通知をクライアント（９０１−１〜９０１−ｎ、及び９０３−１〜９０３−ｎ）に送信することに応じて、空になったキューをメモリから消去しうる。メモリ・コストの節約のためである。

送信手段（９１７）は、キュー内に格納されたイベント・データ通知に設定された転送時期の最も早い時期が到来することに応じて、キュー内に格納された全てのイベント・データを１つの通知として受信者である少なくとも１つのクライアント（９０３−１〜９０３−ｎ）に送信する。送信手段（９１７）は、例えば、キューに設定された転送時期に、当該キュー内に格納された全てのイベント・データを１つの通知として、キューに関連付けられた少なくとも１の受信者のクライアント（９０３−１〜９０３−ｎ）に送信しうる。または、送信手段（９１７）は、例えば、キュー内に格納されたイベント・データに個々に設定された転送時期のうち最も早い時期が到来することに応じて、当該キュー内に格納された全てのイベント・データを１つの通知として、キューに関連付けられた少なくとも１の受信者のクライアント（９０３−１〜９０３−ｎ）に送信しうる。

クライアント（９０１−１〜９０１−ｎ）は、サーバ（９０２）とネットワークを介して接続されうる。クライアント（９０１−１〜９０１−ｎ）は、イベントの発生を伴うアプリケーションを実装することが可能であり、当該イベントの発生に応じて、サーバ（９０２）に当該イベントに対応する通知を送信する。ただし、クライアント（９０１−１〜９０１−ｎ）が、クライアント（９０３−１〜９０３−ｎ）の機能を兼ね備えることもありうる。クライアント（９０１−１〜９０１−ｎ）のユーザは、アジャイル開発において、例えば、チーム・リーダ又はスクラム・マスタとも呼ばれうる。

クライアント（９０３−１〜９０３−ｎ）は、サーバ（９０２）とネットワークを介して接続されうる。クライアント（９０３−１〜９０３−ｎ）は、サーバ（９０２）から、イベント・データについての１つの通知を受信する。ただし、クライアント（９０３−１〜９０３−ｎ）が、クライアント（９０１−１〜９０１−ｎ）の機能を兼ね備えることもありうる。クライアント（９０３−１〜９０３−ｎ）のユーザは、アジャイル開発において、例えば、チーム・メンバ又はスクラム・メンバとも呼ばれうる。

図１０は、本発明の実施態様に従い、イベントの通知を含むイベント・データをサーバに用意されたキューに格納する処理のフロー・チャートを示す。
ステップ１００１では、サーバ（９０２）は、イベント・データをサーバに用意されたキューに格納する処理を開始する。

ステップ１００２では、受信手段（９１１）は、クライアント（９０１−１〜９０１−ｎ）からの入力を検知する。当該入力の検知は、クライアント（９０１−１〜９０１−ｎ）から、イベントに対応する通知を受信手段（９１１）が受信することによって行われうる。当該通知は、イベント情報（例えば、ユーザによって編集されたレコードの属性の名前の及びその値）を含む。受信手段（９１１）は、当該通知をイベント・データ生成手段（９１２）に渡す。

ステップ１００３では、イベント・データ生成手段（９１２）は、イベント情報に対応するワーク・アイテムＩＤを格納するリポジトリから、当該通知に対応するワーク・アイテムＩＤを取得する。そして、イベント・データ生成手段（９１２）は、当該ワーク・アイテムＩＤに対応し且つサーバ（９０２）のリポジトリに格納されているレコードに前記通知による変更が加わる際の当該レコードと変更との差分を検出して、前記通知に対応するイベント・データを作成する。

ステップ１００４では、イベント・データ生成手段（９１２）は、キュー集合（９１６−１〜９１６−ｎ）に、上記取得されたワーク・アイテムＩＤに関連付けられた、受信者のキューが存在するかどうかを確認する。上記キューが存在する場合、イベント・データ生成手段（９１２）は、プロファイル判定手段（９１３）に処理を渡し、ステップ１００５に進める。一方、上記キューが存在しない場合、イベント・データ生成手段（９１２）は、キュー処理手段（９１５）に処理を渡し、ステップ１００６に進める。

ステップ１００５では、イベント・データ生成手段（９１２）は、プロファイルを用いて、イベント・データを評価する。すなわち、イベント・データ生成手段（９１２）は、イベント・データが当該イベント・データのイベントに関連付けられたプロファイル中の条件式とマッチするかどうかを判定する。マッチする場合、イベント・データ生成手段（９１２）は、当該マッチした条件に関連付けられた転送時期及び任意的に重要度をイベント・データ生成手段（９１２）に渡す。そして、イベント・データ生成手段（９１２）は、当該転送時期及び任意的に重要度をイベント・データに追加して、当該イベント・データを更新する。イベント・データ生成手段（９１２）は、当該更新したイベント・データをキュー処理手段（９１５）に渡す。なお、ステップ１００５の詳細を、図１２Ａ及び図１２Ｂにおいて更に説明する。

ステップ１００６では、キュー処理手段（９１５）は、上記取得されたワーク・アイテムＩＤに関連付けられた、受信者のキューを作成する。そして、キュー処理手段（９１５）は、当該作成されたキューをキュー集合に追加する。キューをキュー集合に追加後に、キュー処理手段（９１５）は、イベント・データ生成手段（９１２）に処理を渡し、ステップ１００５に進める。なお、ステップ１００６の詳細を、図１３において更に説明する。

ステップ１００７では、キュー処理手段（９１５）は、イベント・データを当該イベントに対応するキューに格納する。

ステップ１００８では、サーバ（９０２）は、イベント・データをキューに格納する処理を終了する。

図１１は、本発明の実施態様に従い、キュー中のイベント・データを１つの通知として受信者に送信する処理のフロー・チャートを示す。
図１１Ａは、上記処理の全体フローを示す。
ステップ１１０１では、送信手段（９１７）は、キュー内に格納されたイベント・データに設定された転送時期の最も早い時期が到来するまで待機する。
ステップ１１０２では、送信手段（９１７）は、キュー内に格納されたイベント・データに設定された転送時期の最も早い時期が到来することに応じて、キュー内のイベント・データを１つの通知にまとめて、当該１つの通知をキューに関連付けられた受信者のクライアントに送信する。ステップ１１０２の詳細は、図１１Ｂにおいてさらに説明する。
ステップ１１０３では、送信手段（９１７）は、上記１つの通知を送信したことに応じて、キューに設定されたタイマーを初期状態にセットする。

図１１Ｂは、図１１Ａのステップ１１０２の詳細なフローを示す。
ステップ１１１１では、送信手段（９１７）は、キュー中のイベント・データを送信するための処理を開始する。
ステップ１１１２では、送信手段（９１７）は、キュー集合に選択されていないキューが存在するかどうかを確認する。キュー集合に選択されていないキューが存在する場合、送信手段（９１７）は、処理をステップ１１１３に進める。一方、キュー集合に選択されていないキューが存在しない場合、送信手段（９１７）は、処理をステップ１１１６（終了操作）に進める。
ステップ１１１３では、送信手段（９１７）は、選択されていないキューをキュー集合から選択する。
ステップ１１１４では、送信手段（９１７）は、現在時刻が、ステップ１１１３で選択されたキューに設定された転送時期よりも後であるかどうかを判定する。現在時刻が上記キューに設定された転送時期よりも後である場合、送信手段（９１７）は、処理をステップ１１１５に進める。一方、現在時刻が上記キューに設定された転送時期よりも後でない場合、送信手段（９１７）は、処理をステップ１１１２に戻す。
ステップ１１１５では、送信手段（９１７）は、キュー内に格納されたイベント・データに設定された転送時期の最も早い時期が到来することに応じて、キュー内のイベント・データを１つの通知にまとめて、当該１つの通知をキューに関連付けられたクライアント（受信者）に送信する。１つの通知を送信後に、送信手段（９１７）は、処理をステップ１１１２に戻す。
ステップ１１１６では、送信手段（９１７）は、選択されていないキューが存在しないために、キュー中のイベント・データを送信するための処理を終了する。

図１２Ａは、図１０のステップ１００５において、プロファイルを用いてイベント・データを評価する処理の詳細なフロー・チャートを示す。
ステップ１２０１では、プロファイル判定手段（９１３）は、プロファイルを使用してイベント・データを評価する処理を開始する。
ステップ１２０２では、プロファイル判定手段（９１３）は、イベント・データ生成手段（９１２）からイベント・データを受け取り、イベント・データが、当該イベント・データのイベントに関連付けられたユーザ・プロファイル中の条件式とマッチするかどうかを判定するために、プロファイル記憶手段（９１４）からユーザ・プロファイルを取り出し参照する。
ステップ１２０３では、プロファイル判定手段（９１３）は、上記イベント・データにマッチする条件式が上記取り出したユーザ・プロファイル中に存在するかどうかを判定する。プロファイル判定手段（９１３）は、マッチする条件式がユーザ・プロファイル中に存在する場合、処理をステップ１２０６に進める。一方、マッチする条件式がユーザ・プロファイル中に存在しない場合、別のプロファイルを参照するために、処理をステップ１２０４に進める。
ステップ１２０４では、プロファイル判定手段（９１３）は、イベント・データが、当該イベント・データのイベントに関連付けられたプロジェクト・プロファイル中の条件式とマッチするかどうかを判定するために、プロファイル記憶手段（９１４）からプロジェクト・プロファイルを取り出し参照する。
ステップ１２０５では、プロファイル判定手段（９１３）は、上記イベント・データにマッチする条件式が上記取り出したプロジェクト・プロファイル中に存在するかどうかを判定する。プロファイル判定手段（９１３）は、マッチする条件式がプロジェクト・プロファイル中に存在する場合、処理をステップ１２０６に進める。一方、マッチする条件式がユーザ・プロファイル中に存在しない場合、処理をステップ１２０７に進める。
ステップ１２０６では、プロファイル判定手段（９１３）は、マッチする条件式に対応するプロファイル情報（転送時期、及び任意的に重要度）をイベント・データに追加する。
ステップ１２０７では、プロファイル判定手段（９１３）は、マッチする条件式がプロジェクト・プロファイル中に存在しないので、デフォルトのプロファイル情報をイベント・データに追加する。デフォルトのプロファイル情報は当業者が適宜設定しうる。デフォルトのプロファイル情報は、例えば、転送時期が「毎朝８時」であり、重要度は「低い」である。
ステップ１２０８では、プロファイル判定手段（９１３）は、プロファイルを使用してイベント・データを評価する処理を終了する。

図１２Ｂは、図１０のステップ１００５において、プロファイルを用いてイベント・データを評価する処理の詳細なフロー・チャートを示す。
図１２Ｂに示すフロー・チャートは、図１２Ａのステップ１２０２とステップ１２０４とが逆になっている点以外は、同じである。従って、図１２Ｂの各ステップの説明は省略する。
なお、プロファイル判定手段（９１３）は、ステップ１２１２とステップ１２１４とを同時に実行しうる。この場合、プロファイル判定手段（９１３）は、ステップ１２１３とステップ１２１５とをまた同時に実行しうる。

図１３は、図１０のステップ１００６において、イベント・データをキューへ追加する処理の詳細なフロー・チャートを示す。
ステップ１３０１では、キュー処理手段（９１５）は、キュー中にイベント・データを追加する処理を開始する。
ステップ１３０２では、キュー処理手段（９１５）は、イベント・データのプロファイル情報から転送時期を取得する。
ステップ１３０３では、キュー処理手段（９１５）は、イベント・データの転送時期が、キューに設定された転送時期よりも早いかどうかを判定する。イベント・データの転送時期がキューに設定された転送時期よりも早い場合、キュー処理手段（９１５）は、処理をステップ１３０４に進める。一方、イベント・データの転送時期がキューに設定された転送時期よりも早くない場合、キュー処理手段（９１５）は、処理をステップ１３０５に進める。
ステップ１３０４では、キュー処理手段（９１５）は、イベント・データの転送時期がキューに設定された転送時期よりも早いことに応じて、キューの転送時期を、イベント・データの転送時期で更新する。
ステップ１３０５では、キュー処理手段（９１５）は、ステップ１３０４の処理に応じて、イベント・データを当該イベントに対応するキューに格納する。
ステップ１３０６では、キュー処理手段（９１５）は、キュー中にイベント・データを追加する処理を終了する。

図１４は、本発明の実施態様に従い、キュー中の複数のイベント・データを１つの通知（サマリ・メール）にまとめる態様を示す。
１つの通知（１４０１）では、重要度の高いイベント・データのイベント内容（１４０３）が重要度の低いイベント・データのイベント内容（１４０２）よりも強調（大きいフォント）されて表示されている。強調表示の方法は、フォント・サイズの大小だけでなく、異なる色若しくはフォントによる強調、リッチ・テキストによる強調、又はタグ・クラウドによる強調方法を採用しうる。

１つの通知（１４１１）では、重要度の高いイベント・データのイベント内容（１４０４）が重要度の低いイベント・データのイベント内容（１４１２及び１４１３）よりも強調（大きいフォント）されて表示されている。また、重要度の低いイベント・データのイベント内容（１４１２及び１４１３）のうち、イベント内容（１４１２）は当該通知（１４１１）内に表示されていず、その代わりに、内容を格納した場所を示すリンクが当該通知（１４１１）内に張られている。リンクを採用することで、オリジナルのイベント・データは例えばサーバに格納して確保しておき、一方メール転送量の削減を図ることが可能である。

１つの通知（１４２４）では、イベント・データ１（Ｅｖ１）のイベント内容（状態遷移を示す）（１４２２）及びイベント・データ（Ｅｖ２）のイベント内容（状態遷移を示す）（１４２３）がまとめられて表示されている。このように状態遷移をまとめることで、中間情報を除き、チーム・メンバに必要な、例えば最初と最後の情報のみを送信することが可能になる。

Claims (20)

1. サーバ・コンピュータ（以下、「サーバ」という）と当該サーバにネットワークを介して接続された複数のクライアント・コンピュータ（以下、「クライアント」という）とを含むネットワーク環境において、イベントの通知を送信する方法であって、前記サーバが、
   イベントの発生に応じて当該イベントに対応する通知を記憶装置内に受信するステップと、
   前記受信した通知から生成されるイベント・データが前記イベントに関連付けられたプロファイル中の条件式とマッチする場合に、当該イベント・データを、当該イベントに対応する変更管理情報及び当該変更管理情報の受信者の少なくとも１つに関連付けられたキューに格納するステップであって、前記プロファイルに基づいて前記イベント・データに転送時期を設定するステップを含む、前記格納するステップと、
   前記キュー内に格納されたイベント・データに個々に設定された転送時期の最も早い時期が到来することに応じて、前記キュー内に格納された全てのイベント・データを１つの通知として前記受信者のクライアントに送信するステップと
   を実行することを含み、
   前記設定するステップが、
   前記イベント・データが格納される前記キューに転送時期が設定されている場合において、前記イベント・データに設定された転送時期が前記キューに設定された転送時期よりも早いことに応じて、前記キューに設定された転送時期を前記イベント・データに設定された転送時期に更新するステップ
   を含む、
   前記方法。
2. 前記設定するステップが、
   前記イベント・データが格納されるキューに転送時期が設定されていない場合、前記イベント・データに設定された転送時期を前記キューに設定するステップ
   を含む、請求項１に記載の方法。
3. 前記送信するステップが、前記キューに設定された転送時期に行われる、請求項２に記載の方法。
4. 前記設定するステップが、前記プロファイルに基づいて前記イベント・データに重要度を設定するステップをさらに含む、請求項１〜３のいずれか一項に記載の方法。
5. 前記１つの通知が、（１）高い重要度を設定されたイベント・データのイベント内容と、（２）低い重要度を設定されたイベント・データを格納する場所を示すリンク、低い重要度を設定されたイベント・データのイベント内容を要約した内容、又は、前記低い重要度を設定されたイベント・データのイベント内容と、当該低い重要度を設定されたイベント・データのイベント内容が前記高い重要度を設定されたイベント・データのイベント内容よりも小さく表示されるように設定する属性とを含む、請求項１〜４のいずれか一項に記載の方法。
6. 前記１つの通知が、高い重要度を設定されたイベント・データのイベント内容と、当該高い重要度を設定されたイベント・データのイベント内容が強調表示されるように設定する属性とを含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記１つの通知が、複数のイベント・データのイベント内容を要約した内容を含む、請求項１〜６のいずれか一項に記載の方法。
8. 前記キューが、前記イベントに対応する変更管理情報と少なくとも１の前記受信者とに関連付けられている、請求項１〜７のいずれか一項に記載の方法。
9. 前記格納するステップが、前記イベント・データを、複数のキューに格納するステップをさらに含む、請求項１〜８のいずれか一項に記載の方法。
10. 前記送信するステップが、前記１つの通知を前記キューに関連付けられた複数の受信者の各クライアントに送信するステップを含む、請求項１〜９のいずれか一項に記載の方法。
11. 前記格納するステップが、
    前記イベントに対応する変更管理情報のキューがないことに応じて、当該イベントに対応する変更管理情報のキューをメモリ内に用意するステップ
    をさらに含む、請求項１〜１０のいずれか一項に記載の方法。
12. 前記プロファイルが、前記受信者のユーザ・プロファイル、プロジェクト・プロファイル、又はそれらの組み合わせである、請求項１〜１１のいずれか一項に記載の方法。
13. 前記プロファイルが前記受信者のユーザ・プロファイルであり、当該ユーザ・プロファイルが、電子カレンダに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期を含む、請求項１〜１１のいずれか一項に記載の方法。
14. 前記プロファイルがプロジェクト・プロファイルであり、当該プロジェクト・プロファイルが、プロジェクトに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期を含む、請求項１〜１１のいずれか一項に記載の方法。
15. 前記プロファイルがプロジェクト・プロファイルであり、当該プロジェクト・プロファイルが、電子カレンダに関連付けられた少なくとも１つの条件式、及び当該条件式に関連付けられた転送時期を含む、請求項１〜１１のいずれか一項に記載の方法。
16. 前記プロジェクト・プロファイルが、前記条件式に関連付けられた重要度をさらに含む、請求項１４又は１５に記載の方法。
17. イベントの通知を送信するサーバ・コンピュータ（以下、「サーバ」という）であって、当該サーバは、ネットワークを介して複数のクライアント・コンピュータ（以下、「クライアント」という）に接続されることができ、前記サーバが、
    イベントの発生に応じて当該イベントに対応する通知を受信する受信手段と、
    前記受信した通知から生成されるイベント・データが前記イベントに関連付けられたプロファイル中の条件式とマッチする場合に当該イベント・データを格納し、且つ当該イベントに対応する変更管理情報及び当該変更管理情報の受信者の少なくとも１つに関連付けられているキューであって、当該キューに格納されたイベント・データは、前記プロファイルに基づいて設定された転送時期を有する、前記キューと、
    前記キュー内に格納されたイベント・データに個々に設定された転送時期の最も早い時期が到来することに応じて、前記キュー内に格納された全てのイベント・データを１つの通知として前記受信者のクライアントに送信する送信手段と
    を備えており、
    前記設定することが、
    前記イベント・データが格納される前記キューに転送時期が設定されている場合において、前記イベント・データに設定された転送時期が前記キューに設定された転送時期よりも早いことに応じて、前記キューに設定された転送時期を前記イベント・データに設定された転送時期に更新すること
    を含む、
    前記サーバ。
18. 前記設定することが、
    前記イベント・データが格納されるキューに転送時期が設定されていない場合、前記イベント・データに設定された転送時期を前記キューに設定すること
    を含む、請求項１７に記載のサーバ。
19. 前記サーバが、変更管理システム、タスク管理システム、プロジェクト管理システム、品質管理システム、バグ管理システム、障害管理システム、又はトラック管理システムのサーバである、請求項１７又は１８に記載のサーバ。
20. コンピュータに、請求項１〜１６のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images