JP2009193583A - 共同ワーキング・セッションを管理する方法、システムおよびコンピュータ・プログラム - Google Patents

Abstract

【課題】共同ワーキング・セッション（例えば会議）を管理するソリューションを提供する。
【解決手段】一連のワーキング・セッションの予定が組まれる（６０６〜６１２）。ワーキング・セッションは、共通する一連のリソース（例えば会議室）を必要とする。通信アドレスまたは追加のもの（例えば移動電話の番号）が、各参加者に関連付けられる（６１５）。現在のワーキング・セッション（未開催のワーキング・セッションのうち最初に開催される予定のもの）への参加者それぞれに関連付けられている通信アドレスが読み出される（６３３）。その結果、現在のワーキング・セッションへの参加者それぞれに関連付けられている通信アドレスへ、メッセージ（現在のワーキング・セッションの開催を示す）を送信すること（６３６）が可能である。
【選択図】図７

Description

本発明は、情報技術の分野に関する。特に、本発明は共同ワーキング・セッションの管理に関する。

チーム内での作業は、現代の組織の中では重要な要素である。このために、複数の参加者間で共同ワーキング・セッションを実施するためにいくつかの選択肢が利用可能である。典型例は、参加者が会議室に集まり共通の関心事である話題について議論する、会議である。より高度なソリューションは、参加者が物理的に集まらなくても、同じ結果を得られるようにもする（その結果交通費が削減される）。これは例えば、各参加者が他の全参加者に聞こえるよう電話で話すことができる電話会議でなされ得る。このために、参加者は、（参加者らの種々の電話回線をつなぐことによって電話会議を実施するサービス・プロバイダの）特別なサービス番号に電話をかける。さらに、現代の電気通信網の急速な発展は、参加者間でマルチメディア・コンテンツを遠隔共有することも可能にする。例えばテレビ会議では、参加者は（電話で話すのに加えて）画像およびビデオを交換して議論をサポートすることができる。テレビ会議は、完全にインターネットで実施することも可能である（この場合はウェブ会議と称される）。

すべてのワーキング・セッションにある問題は、その準備である。実際、このためには、新規のワーキング・セッションの調整役が、まず参加者（または少なくとも、ワーキング・セッションへの出席が必須である者）の空き状況を確認する必要がある。その後、ワーキング・セッションを開催するのに必要なリソース（すなわち、会議室またはサービス・プロバイダ）を予約する必要がある。調整役の仕事を容易にする利用可能なツールがいくつかある。例えば、これらのツールは、参加者の予定表（参加者が既に交わしている約束を示す）を確認すること、ワーキング・セッションへの案内を参加者に送信すること、必要なリソースの日程表（その予約を示す）を確認することなどを可能にする。

しかし、ワーキング・セッションが実際に開催されたときに、セッションのもともと予定されていたとおりの開始または終了、あるいはその両方に合わせることは非常に難しい。

実際、ワーキング・セッションが遅れて終了することは頻繁にある（例えば、ワーキング・セッションが予定よりも後に開始されたこと、または予定よりも長く続いたこと、あるいはその両方が理由で）。この場合、（同じリソースを必要とする）次のワーキング・セッションへの参加者は、付随する待ち時間を経験する。実際には、このワーキング・セッションへの参加者は、会議の開始予定時に会議室に到着、またはサービス番号に電話することになっている。したがって、参加者はそれぞれ、会議室の外で待つかまたはサービス番号に電話をかけ続ける必要がある。さらにこれは、（会議室に入るかまたはサービス番号に電話をかける）次のワーキング・セッションの参加者によってまだ進行中のワーキング・セッションが邪魔されると、気まずい状況をもたらすこともある。

反対に、ワーキング・セッションは早く終了することもある（例えば、ワーキング・セッションが予定されていたほど続かなかったことが理由で）。この場合、関連のリソースは、次のワーキング・セッションが（開始予定時に）開催されるまで使用されないままとなる。

その他任意の予測不可能なイベントが開催予定のワーキング・セッションに影響をおよぼしても（例えば、先行のワーキング・セッションが中止されたことが理由で）、同様の問題が起こる。

本提案は、一般的に、ワーキング・セッションへの参加者に、その開催を通知するという発想に基づく。

さらに具体的には、本発明の態様は、共同ワーキング・セッション（例えば会議）の管理方法を提案する。本方法は、データ処理システムの制御下にある以下のステップを含む。まず、一連のワーキング・セッションの予定が組まれる。各ワーキング・セッションは、複数の参加者により出席されるものである。さらに、ワーキング・セッションは、共通する一連のリソース（例えば会議室）を必要とする。通信アドレスまたは追加のもの（例えば移動電話の番号）が、各参加者に関連付けられる。方法は、リソースの利用可能性を信号で伝えること（例えば、サービス番号に電話をかけて、開始する現在の会議の識別子、または終了したばかりの先行の会議の識別子を入力することによる）で続く。それに応答して、現在のワーキング・セッション（未開催のワーキング・セッションのうち最初に開催される予定のもの）への参加者それぞれに関連付けられている通信アドレスが読み出される。その結果、現在のワーキング・セッションへの参加者それぞれに関連付けられている通信アドレスへ、メッセージ（現在のワーキング・セッションの開催を示す）を送信することが可能である。

本発明の実施形態では、現在のワーキング・セッションの開始が信号で伝えられる。

本発明の別の実施形態では、代わりに、先行のワーキング・セッションの終了が信号で伝えられる。

いずれにしても、この結果は、関連のワーキング・セッションに関連付けられている識別子を入力することで得られる。

さらなる改善として、現在のワーキング・セッションの遅延を判断し、次に、それに従って後続の一連のワーキング・セッションを予定変更することが可能である。

この場合、予定変更を示すメッセージが、予定変更された後続のワーキング・セッションへの参加者それぞれに関連付けられている通信アドレスへ送信される。

提案される実装では、遅延は、現在のワーキング・セッションの実際の開始または終了あるいはその両方がないまま、現在のワーキング・セッションの開始予定から、または終了予定から、あるいはその両方から経過した時間に従って計算される。

例えば、予定変更は、後続のワーキング・セッションの延期または短縮あるいはその両方によって実現されればよい。

本発明の別の態様は、上記の方法を遂行するコンピュータ・プログラムを提案する。

本発明の別の態様は、対応するシステムを提案する。

単に非限定的に示すことを目的として与えられ添付の図面と併せて読まれるべき以下の詳細な説明を参照すると、本発明自体、ならびに本発明のさらなる特徴および利点を最もよく理解できる。

図１Ａ〜図２Ｂを詳細に参照すると、本発明の実施形態によるソリューションの例示的な適用の間に実行される一連の動作の図的表現が提供されている。

図１Ａから始まり、会議室１０５内で複数の会議が連続して開催されることが予定されている（その他任意の種類の共通するリソースを１つ以上必要とする一般的なワーキング・セッションに対して、同様の考察が適用される）。各（現在の）会議は、会議室１０５が利用可能になるとすぐに開催されるとよい。これは、会議の調整役１１０が会議室１０５に到着し（て会議室が空いていることを知っ）たとき、または先行の会議の参加者１１５が会議室１０５を去ったときに発生する。どちらの場合も、会議室１０５の利用可能性が、サービス・センタ１２０に信号で伝えられる。これは例えば、対応するサービス番号に電話をかけ、（会議の開始を信号で伝えるために）会議の識別子を、または（先行の会議の終了を信号で伝えるために）先行の会議の識別子を入力することによる。

ここで図１Ｂについて考察すると、サービス・センタ１２０は、会議への参加者リスト１２５を判断する（例えば、識別子によって、会議の定義を格納しているオブジェクトにアクセスすることによって）。

図２Ａに移り、サービス・センタ１２０は、各参加者に関連する通信アドレス１３０を（例えば所定のテーブルから）読み出す。（対応する通信チャネルの）通信アドレスは、移動電話の番号、インスタント・メッセージのアドレス、電子メール・アドレスなどであればよい。次に、サービス・センタ１２０は、各参加者（１３５で表されている）の通信アドレスにメッセージを送信する。メッセージ（ＳＭＳ、インスタント・メッセージまたは電子メールなど）は、会議が開催されようとしていることを示す。

それに応答して、図２Ｂに示されているように、全参加者１３５が会議室１０５へ移動し、その結果、開催される会議に丁度間に合うように会議室に到着する。

提案されるソリューションは、（会議室が既に利用可能なときにしか参加者が会議室に到着しないため）たとえ先行の会議が遅れて終了した場合でも、参加者のあらゆる待ち時間をなくす（または少なくとも削減する）。さらに、これによって、全ての参加者が、誤って会議室に入ることによって（まだ進行中の）先行の会議の邪魔をすることが防止される。

反対に、先行の会議が早く終了すると、会議室をすぐに使用できることさえもあり、それによって会議室の活用が最適化される。

ここで図３Ａ〜３Ｂおよび図４Ａ〜４Ｂを参照すると、サービス・センタはさらに、（各会議の開始および終了についての）同じ情報を使用して、同じ会議室で後から開催される、後続の会議の予定を変更する。このようにして、会議室の利用可能性が完全に動的な形で管理される。

例えば、図３Ａに示されているように、日中４つの会議Ｍ_１、Ｍ_２、Ｍ_３およびＭ_４が連続して予定されていると仮定する。各会議Ｍ_ｉ（ｉ＝１〜４）の予定は、その開始予定Ｓ_ｉおよびその終了予定Ｅ_ｉ（各会議Ｍ_ｉ＋１は先行の会議Ｍ_ｉが終了する前には開始できないため、Ｓ_ｉ＋１＞＝Ｅ_ｉ）によって指定されており、これらの値は、継続予定時間Ｅ_ｉ−Ｓ_ｉを定義する。問題の特定の状況では、会議Ｍ_２が会議Ｍ_１の直後に予定されている（すなわちＳ_２＝Ｅ_１）一方、会議Ｍ_３とＭ_２との間には１０分間の空きがあり（すなわちＳ_３＝Ｅ_２＋１０分）、会議Ｍ_４とＭ_３との間には１５分間の空きがある（すなわちＳ_４＝Ｅ_３＋１５分）。会議Ｍ_１に遅延Ｄ_１＝２０分が生じる。遅延Ｄ_１は、会議Ｍ_１の実際の終了時Ｅ _１ （すなわちＤ_１＝Ｅ _１ −Ｅ_１）に判断されるか、または、会議Ｍ_１の実際の継続時間Ｅ _１ −Ｓ _１ が継続予定時間Ｅ_１−Ｓ_１に等しいと仮定して、会議Ｍ_１の実際の開始時Ｓ _１ に判断されればよい（すなわちＤ_１＝Ｓ _１ −Ｓ_１）。

図３Ｂに移ると、本発明の実施形態において、後続の会議Ｍ_２〜Ｍ_４が、遅延Ｄ_１に従って延期することによって予定変更され、それによって各会議Ｍ_ｊ（ｊ＝２〜４）について、変更された開始予定Ｓ_ｊ’および変更された終了予定Ｅ_ｊ’が得られる。このために、会議Ｍ_ｊの開始予定Ｓ_ｊおよび終了予定Ｅ_ｊに、先行の会議Ｍ_ｊ−１がもたらす残りの遅延（遅延Ｄ_１から始まる）が相次いで加えられる。この遅延は、場合により、会議Ｍ_ｊと会議Ｍ_ｊ−１との間の空きＳ_ｊ−Ｅ_ｊ−１によって軽減される。予定変更は、１日の終わりまで、または遅延Ｄ_１が空きによって完全に吸収されるまで続く。問題の例では、会議Ｍ_２は、会議Ｍ_１の直後に予定されていたため、遅延Ｄ_１＝２０分の延期となる（すなわち、Ｓ_２’＝Ｓ_２＋２０分、およびＥ_２’＝Ｅ_２＋２０分）。代わりに、会議Ｍ_３と会議Ｍ_２との間には空きＳ_３−Ｅ_２＝１０分があったため、会議Ｍ_３は、遅延Ｄ_２＝Ｄ_１−１０分＝１０分の延期となる（すなわち、Ｓ_３’＝Ｓ_３＋１０分、およびＥ_３’＝Ｅ_３＋１０分）。会議Ｍ_４は、会議Ｍ_４と会議Ｍ_３との間に空きＳ_４−Ｅ_３’＝５分がまだ残っているため、延期の必要がない（すなわち、Ｓ_４’＝Ｓ_４およびＥ_４’＝Ｅ_４）。提案されるアルゴリズムは、いかなる遅延にも関係なく、すべての会議が確実にその継続予定時間を維持するようにする。

代わりに、図４Ａを参照して、以下、同じ４つの会議Ｍ_１、Ｍ_２、Ｍ_３およびＭ_４すべてが間に空きのない状態でそれぞれ他とすぐ接して予定されていると仮定する（すなわち、Ｓ_ｉ＋１＝Ｅ_ｉ）。会議Ｍ_１に、遅延Ｄ_１＝１５分が生じる（上記のように、会議Ｍ_１の実際の終了時Ｅ _１ または実際の開始時Ｓ _１ に判断される）。

図４Ｂに移ると、本発明の別の実施形態において、後続の会議Ｍ_２〜Ｍ_４が、遅延Ｄ_１に従って短縮することによって予定変更され、この場合もやはり各会議Ｍ_ｊ（ｊ＝２〜４）について、変更された開始予定Ｓ_ｊ’および変更された終了予定Ｅ_ｊ’が得られる。このために、会議Ｍ_ｊの開始予定Ｓ_ｊに、先行の会議Ｍ_ｊ−１によりもたらされる残りの遅延Ｄ_ｊ−１（遅延Ｄ_１から始まる）が加えられ、その終了予定Ｅ_ｊに、所定量（例えば５〜１５分）削減された残りの遅延Ｄ_ｊ−１が加えられる。予定変更は、１日の終わりまで、または遅延Ｄ_１が削減によって完全に吸収されるまで続く。問題の例では（５分の削減を仮定すると）、会議Ｍ_２の残りの遅延はＤ_１＝１５分に等しく（すなわちＳ_２’＝Ｓ_２＋１５分およびＥ_２’＝Ｅ_２＋１０分）、会議Ｍ_３の残りの遅延はＤ_２＝Ｄ_１−５分＝１０分に等しく（すなわちＳ_３’＝Ｓ_３＋１０分およびＥ_３’＝Ｅ_３＋５分）、会議Ｍ_４の残りの遅延はＤ_３＝Ｄ_２−５分＝５分に等しい（すなわちＳ_４’＝Ｓ_４＋５分およびＥ_４’＝Ｅ_４）。このようにして、会議の継続予定時間に大きな影響を与えずに、会議の予定変更を最小限に抑えることができる。

ここで図５について考察すると、本発明の実施形態によるソリューションを実践するのに使用可能なインフラストラクチャ４００の概略ブロック図が示されている。インフラストラクチャ４００は、各会議室に電話４０５を備えている（図では１つだけ示されている）。任意の会議に参加するよう案内される可能性のある人それぞれに、１つ以上の通信デバイス４１０が提供される（例えば、移動電話、パーソナル・コンピュータなど）。インフラストラクチャ４００の中核は、上記のサービス・センタを実装するサーバ４２０である。

サーバ４２０は、システム・バス４２５に並列接続されたいくつかのユニットにより形成されている。詳細には、１つ以上のマイクロプロセッサ（μＰ）４３０がサーバ４２０の動作を制御し、ＲＡＭ４３５はマイクロプロセッサ４３０によってワーキング・メモリとして直接使用され、ＲＯＭ４４０は、サーバ４２０のブートストラップ用の基本コードを格納する。いくつかの周辺ユニットが、ローカル・バス４４５の周りに（それぞれのインターフェースを用いて）集められている。特に、大容量メモリは、１つ以上のハード・ディスク４５０およびＤＶＤ‐およびＣＤ‐ＲＯＭ４６０を読み取るドライブ４５５から成る。さらに、サーバ４２０は、入力ユニット４６５（例えばキーボードおよびマウス）、および出力ユニット４７０（例えばモニタ）を含む。シグナリング・アダプタ４７５は、各電話４０５によって（図示されていない地上電話網（ｌａｎｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋ）を介して）、サーバ４２０にアクセスするために使用される。１つ以上の通知アダプタ４８０が、例えば移動電話ネットワーク、インターネットなど、対応する通信ネットワークを介して（図示せず）サーバ４２０が通信デバイス４１０へメッセージを送信できるようにする。ブリッジ・ユニット４８５は、システム・バス４２５と、ローカル・バス４４５とを連結する。各マイクロプロセッサ４３０およびブリッジ・ユニット４８５は、情報を伝送するよう、システム・バス４２５へのアクセスをリクエストするマスタ・エージェントとして動作できる。アービタ４９０は、システム・バス４２５へのアクセスの相互排除での許可を管理する。

図６に移動すると、本発明の実施形態によるソリューションを実装するのに使用できる主要ソフトウェア・コンポーネントが示されている。情報（プログラムおよびデータ）は通常ハード・ディスクに格納されており、プログラムの実行中に、（少なくとも部分的に）サーバのワーキング・メモリにロードされる。プログラムは最初に、例えばＤＶＤ‐ＲＯＭからハード・ディスクにインストールされる。

具体的には、サーバは共同ツール５００を実行する。共同ツール５００は、様々な会議室で開催される会議の予定を組むために関連の調整役によって使用される日程表インターフェース５０５を含む。予定が組まれる新規の会議それぞれについて、日程表インターフェース５０５は、会議の定義を含んだオブジェクトを作成する（すなわち、会議の識別子、会議室のコード、開始予定および終了予定、および各参加者のＵｓｅｒＩｄ）。すべての（未開催の）会議のオブジェクトが、日程表５１０に格納される。

代わりに予定表インターフェース５１５は、会議への参加者（となる可能性のある者）それぞれによって、その約束を整理するために使用される。参加者が交わした約束（出席を引き受けた会議を含む）が、個人の予定表５２０に格納される。予定表インターフェース５１５はさらに、マッピング・テーブル５２５の関連の項目を編集するために参加者により使用される。マッピング・テーブル５２５は、参加者（そのＵｓｅｒＩｄによって）と、対応する通信アドレスまたは追加のもの（これも同じＵｓｅｒＩｄに対応するとよい）とを関連付ける。

シグナリング・インターフェース５３０は、異なる会議室にある電話からの電話を受ける。シグナリング・インターフェース５３０は、電話を介して入った情報（すなわち、対応する会議室で開始する会議、または終了したばかりの会議の識別子）を収集する。日程表モニタ５３５は、開始予定の後にまだ開始されていないこと、または終了予定の後にまだ終了していないことから遅れが見込まれる会議を定期的に発見する。遅れている会議それぞれについて、日程表モニタ５３５は、（開始予定または終了予定から経過した時間に従い）対応する遅延を判断する。シグナリング・インターフェース５３０および日程表モニタ５３５は、会議の開始または終了が（シグナリング・インターフェース５３０によって）信号で伝えられるたびに、または遅れている会議が（日程表モニタ５３５によって）発見されるたびに、イベント記録を生成する。これらのイベント記録は、待ち行列５４０に相次いで入れられる。

待ち行列５４０内のイベント記録は、分析エンジン５４５によって使用される。（最新の）イベント記録が会議室の利用可能性を示すと、分析エンジン５４５は、そこで１番目に開催が予定されている会議への参加者リストを（日程表５１０から）読み出す。次に、この会議への参加者それぞれについて、分析エンジン５４５は、対応する通信アドレスをマッピング・テーブル５２５から読み出す。分析エンジン５４５は、ここで、（会議が開催されようとしていることを示す）メッセージを各参加者の通信アドレスへ送信するよう、通知モジュール５５０を駆動する。このために、通知モジュール５５０は、種々のプラグイン・モジュール５５５と連動する。各プラグイン・モジュール５５５は、（例えば、ＳＭＳ、インスタント・メッセージ、電子メールなどを送信する）対応する通信チャネル用のものである。

反対に、遅れている会議をイベント記録が示すと、分析エンジン５４５はスケジューリング・エンジン５６０を呼び出す。スケジューリング・エンジン５６０は、日程表５１０内にある後続の会議を、延期または短縮することによって（必要であれば）予定変更する。スケジューリング・エンジン５６０は、予定変更された各会議への参加者リストを、日程表５１０から読み出す。次に、それに応じて、これらの会議への各参加者の予定表５２０が更新される。未出席の会議の遅延は、予定表のグラフィック描写（例えばガント・チャート）において、別の色（赤など）で強調表示されることが好ましい。これに加えて、またはこの代わりに、スケジューリング・エンジン５６０は、予定変更を示すメッセージを各参加者へ送信するよう分析エンジン５４５に要求する（上記のように、マッピング・テーブル５２５から対応する通信アドレスを読み出し、次にそれに応じて通知モジュール５５０を駆動することによる）。

図７〜８に示されているように、（会議を管理するために）上記のシステムにおいて実装可能な例示的なプロセスの論理の流れが、方法６００を用いて表現されている。

方法は、開始ブロック６０３で開始し、次に、一般的な調整役が新規の会議の予定を組むことを決定すると、すぐにブロック６０６へ移る。このために、調整役は、共同ツールの日程表インターフェースにアクセスする。次に調整役は、（対応する予定期間にまだ取られていないことが日程表に示されている）利用可能な会議室について、所望の開始予定および終了予定を選択する。それに応答して、共同ツールはブロック６０９で、この会議の一意の識別子を生成する。この機能は、当技術分野で既知であるいくつかの共同ツールによって既にサポートされている。しかし、この場合においては、会議の識別子が具現化され調整役へ返される。識別子は短い数字コードから成り（例えば４桁）、それによって、調整役が容易に使用できるようにすることが好ましい。なお、異なる識別子は、対応する会議が終了するまでしか維持される必要がない（識別子はその後再び利用できる）ため、識別子に利用可能な組み合わせが比較的少数であるということは問題ではない。ブロック６１２で調整役のスイムレーンに戻り、会議への参加者が選択される。それに応答して、共同ツールはブロック６１５で、会議の定義（すなわち、識別子、会議室のコード、開始予定および終了予定、ならびに各参加者のＵｓｅｒＩｄ）を用いて、会議の新たなオブジェクトを作成する。このようにして、各参加者のＵｓｅｒＩｄによって、参加者と、対応する通信アドレス（マッピング・テーブルに示されている）とを関連付けることができるようになる。

ここでブロック６１８を参照すると、一般的な会議が開始するとき、または終了したばかりのとき、関連する調整役は、共同ツールのサービス番号に電話をかける。合成音声が、この会議の識別子を含むコマンド・コードの入力を調整役に促す。コマンド・コードは、イベントの種類（会議の開始または終了など）を特定するのに使用される追加の数字を含むことが好ましい。

次に、共同ツールのスイムレーン内のブロック６２１で、信号で伝えられたイベントの種類に従ってアクティビティの流れが分岐する。特に、コマンド・コードが会議の終了を示すと、ブロック６２４で対応するオブジェクトが日程表から削除される（それによって、その識別子は、これから予定が組まれる新たな会議に利用可能となる）。終了したばかりの会議の直後に同じ会議室で開催されることが予定されている１番目の会議の識別子が、ブロック６２７で日程表から読み出される。次に、方法はブロック６３０へと下降する。コマンド・コードが会議の開始を示す場合も、ブロック６２１から直接同じ地点に至る。いずれにしても、（利用可能な）会議室で開催される会議のオブジェクトが、その開始を示すよう更新される。

次に、会議が開催されようとしていることをこの会議への各参加者に通知するために、ループが遂行される（場合によっては、調整役が会議の開始を共同ツールに信号で伝えた場合、調整役は除外される）。ループはブロック６３３で開始し、ここで、現在の参加者のＵｓｅｒＩｄが、（会議のオブジェクトに示されている）最初のものから使用され、対応する通信アドレスが読み出される。ブロック６３６に移り、会議が開催されようとしていることを示すメッセージがこの通信アドレスへ伝送される。ブロック６３９においてループの終了条件について確認される。まだ通知されていない参加者がさらにいれば、方法はブロック６３３へ戻り、次の参加者に対して同じ動作が繰り返される。逆の場合、プロセスはブロック６４２へと下降する。

完全に独立した形で、未開催の会議が、遅れを判断するために監視される。このために、所定のタイムアウトが終了する（例えば５〜１０分ごと）とすぐに、方法はブロック６４２からブロック６４５へ移る。この段階で、共同ツールは、開催が予定されている１番目の会議の開始予定、または、各会議室で進行中の会議の終了予定、あるいはその両方を読み出す。タイムアウトの提案される値は、遅延判断の精度を高める要求（短いタイムアウト）と、後続の会議の予定変更を制限する要求（長いタイムアウト）との、対立する要求間の適切な妥協点である。

次に、ブロック６４８でテストが行われ、この会議の開始予定または終了予定あるいはその両方を既に過ぎているかどうかが確認される。過ぎていれば、会議は遅れており、その遅延がブロック６５４で判断される。詳しくは、会議が開始予定の後にまだ開始されていないことが理由で会議が遅れていると特定されると、遅延は、現在時刻と開始予定との間の差に設定される。一方、会議が終了予定の後にまだ終了していないことが理由で会議が遅れていると特定されると、遅延は現在時刻と終了予定と間の差に設定される。

なお、会議が開始予定の後にまだ開始していないことが理由で遅れていると特定されると、後続の会議を前もって予定変更することができる（少なくとも、遅れている会議の継続予定時間によって）。こうすることで、予定変更された会議への参加者に、それに合わせて準備するだけの十分な時間ができる。しかし、会議が実際にいつ終了するのかを先に知ることはできないため、遅延は実際の値の推定にすぎない。したがって、会議は過度に予定変更されることも、または無駄に予定変更されることさえもある（遅れると見なされた会議が、逆に継続予定時間よりも短い時間しか続かず、その結果、より短い遅延で終了した場合、またはさらに言えば時間通りに終了した場合）。逆に、会議が終了予定の後にまだ終了していないことが理由で遅れていると特定されれば、その遅延を正確に測定することができる。しかし、今度は、後続の会議の予定を、間際になってしか変更することができない。特に、遅れている会議の直後に開催が予定されている会議について利用可能な時間は、長くてもこれら会議の間の空き（あれば）に等しい。

次にアクティビティの流れは、共同ツールの構成に従って、ブロック６５７で分岐する。共同ツールが、継続予定時間を維持して（遅れている会議の後に同じ会議室で開催されるよう予定されている）後続の会議の予定を変更するよう設定されていれば、プロセスはブロック６６０へ続く。この場合は、後続の会議は遅延に従って延期される（一日の終わりまでか、または場合によってはある空きによって遅延が完全に吸収されるまで）。逆に、後続の会議への影響を最小限に抑えることによってそれらの予定を変更するよう共同ツールが設定されていれば、プロセスはブロック６６３へと続く。この場合は、後続の会議は遅延に従って短縮される（一日の終わりまでか、後続の会議の継続予定時間の削減によって遅延が完全に吸収されるまで）。

続いて、上記のようなさらなるループが遂行され、予定変更された会議への参加者それぞれに対し通知が行われる。ループはブロック６６６で開始し、ここで、現在の参加者のＵｓｅｒＩｄが（最初のものから）使用され、対応する通信アドレスが読み出される。ブロック６６９に移ると、会議の予定変更を示すメッセージが、この通信アドレスへ伝送される。ブロック６７２においてループの終了条件について確認される。まだ通知されていない参加者がさらにいれば、方法はブロック６６６へ戻り、次の参加者に対して同じ動作が繰り返される。逆の場合、プロセスは白／黒の同心円６７５で終了する。遅れている会議が無ければ、ブロック６４８から直接同じ地点に至る。

当然ながら、その場での特有の要件を満たすために、当業者は、上述のソリューションに対して多数の論理的または物理的あるいはその両方の修正および改変を適用してよい。さらに具体的には、本発明は、ある程度の詳しさでその好適な実施形態（単数または複数）を参照して説明されてきたが、当然のことながら、形態および細部における様々な省略、代用および変更が可能であり、さらに、他の実施形態も可能である。具体的には、提案されたソリューションは、前述の説明においてソリューションをさらによく理解できるよう示された特定の詳細（数に関する例など）なしでも実践することができる。逆に、不要な詳細で説明が分かりにくくならないよう、周知の機能は省略または簡素化されている場合もある。さらに、本発明の開示された任意の実施形態に関連して説明した特定の構成要素または方法ステップあるいはその両方は、一般的な設計上の選択の理由から、他の任意の実施形態に組み込まれてもよいということが、明確に意図されている。

例えば、提案されているソリューションは、（類似のステップを使用すること、必須ではない一部のステップを除くこと、またはさらなる任意選択のステップを追加することによって）等価な方法で実装するのに適している。さらに、ステップは異なる順序で遂行されても、同時に遂行されても、交互の形で遂行されてもよい（少なくとも部分的に）。

どのような共同ワーキング・セッション（例えばセミナー、講座、電話会議、テレビ会議、ウェブ会議など）の管理にも、同様の考察が適用される。さらに、ワーキング・セッションは、他の任意の数または種類あるいはその両方の、共通のリソース（例えば重要な参加者、発表者、プロジェクタ、デモＰＣ、ホワイト・ボードなど）を必要とし得る。上記の通信チャネル（参加者に通知するために使用される）は、単に実例となるものである。例えば、その他の考えられる通信チャネルは、電話での音声メッセージまたは特別な着信音、ポケットベルなどに基づく。さらに、必要なリソースの利用可能性は、いくつかの異なる手段（例えばウェブ・ブラウザ、クライアント・プログラム、ＳＭＳ、ハンドヘルド・デバイスなど）で（共同ツールに）信号で伝えることができる。各参加者に、２つ以上の通信アドレスを関連付けることを妨げるものはない。（例えば、一日の異なる時間に）異なる通信アドレスが代わりに使用されても、または異なる通信アドレスが一緒に使用されてもよく、あるいはその両方も可能である。

会議室（または任意の等価なリソース）の利用可能性を信号で伝えるための上記の手順は、単に実例となるものである。例えば、会議の開始のみを信号で伝えること、会議の終了のみを信号で伝えること、またはその両方が可能である。さらに、会議終了の信号伝達は、会議の中止を表すためにも使用されてよい。あるいは、各会議室の利用可能性を定期的に確認するプロセスが実装されてもよい。より広く、会議室を利用可能にする他の任意のイベント（例えば、先行の会議が別の会議室へ移動したこと）を信号で伝えることが可能である。各ワーキング・セッションが複数のリソースを必要とし得るより高度な実装では、１つ以上のリソースを解放する各イベント（リソースを確保していた会議の終了など）を信号で伝えることが可能である。共同ツールは、各リソースの状態を追跡し、必要なリソースすべてが利用可能になるとすぐに各会議の開催が可能であると判断する。

会議の識別子は、他の任意の形式を有してもよい（例えば、より短いものまたはより長いもの）。さらに、ニーモニック・コードを使用することも可能である（例えば調整役のＵｓｅｒＩｄまたは調整役が入力する空想の名前など）。他の任意のコマンド・コード（会議の識別子を含む）が、共同ツールへ伝送されてもよい。さらに、共同ツールが単一のイベント（すなわち、会議の開始または終了）の信号伝達をサポートする場合、会議の識別子のみを（追加の数字なしで）使用することが可能である。いずれにせよ、本発明の非常に簡素化された実装では、会議室の利用可能性が、会議についての情報を何も含まない単純なコマンドを用いて信号で伝えられてもよい（例えば、会議室内で開催されるあらゆる会議の開始または終了あるいはその両方を信号で伝えるために会議室内のボタンを押すことによって）。

遅れている会議に後続する会議の予定を変更する機能は、必ず必要というわけではなく、本発明の特定の実施形態において省略されてもよい。この場合、後続の会議の考えられるあらゆる予定変更についての決定は、遅れている会議の調整役に委ねられる。

上記に似た考察が、会議の予定変更についての参加者への通知に適用される。なお、開催されようとしている会議および予定変更された会議の通知用に異なる通信チャネルを使用することを妨げるものはない。いずれにせよ、明確な通知を送信せずに、予定変更された会議への参加者の予定表を単に修正することも可能である。

各会議の遅延を判断するための上記のアルゴリズムは、単に実例となるものである。例えば、会議がその開始予定の後にまだ開始されていないときだけ遅延を推定すること、会議がその終了予定の後にまだ終了していないときだけ遅延を測定すること、またはその両方が可能である。さらに、遅延は、監視なしで、会議が実際に開始したときまたは終了したとき、あるいはその両方のときに計算されることも同じく可能である（それぞれ開始予定または終了予定あるいはその両方に対して）。

いずれにせよ、他の任意のポリシーに従い会議の予定が変更されてもよい。例えば、会議の延期のみをすること、会議の短縮のみをすること、または２つのアクションを組み合わせること（すなわち、あらゆる空きを削除することによって会議を詰め、ひいては必要であれば会議を短縮する）が可能である。さらに、より高度なポリシーは、何らかの優先方式に基づいてもよい（それによって、最も重要な会議に対する予定変更の影響が最小現に抑えられる）。

提案されたソリューションは、（上述のとおり）共同ツール内に直接実装されても、既存の共同ツールのプラグインとして実装されてもよく、またはスタンドアロン・モジュールとしても実装されてよい。同じソリューションを、ネットワーク（インターネットなど）を介してアクセスされるサービスとして展開することも可能であるということがすぐに分かる。

プログラム（本発明の各実施形態を実装するのに使用される）は、異なる形で構築されていても、または追加のモジュールもしくは機能が提供されていても、同様の考察が適用される。同じく、メモリの構造も他の種類のものであってもよく、または等価なエンティティ（必ずしも物理的なストレージ媒体から成るとは限らない）に置き換えられてもよい。いずれにせよ、プログラムは、任意の処理システムによって、または任意の処理システムと関連して使用されるのに適した任意の形をとればよい（例えば仮想マシン内）。特に、プログラムは、外部もしくは常駐ソフトウェア、ファームウェアまたはマイクロコードの形（例えば、コンパイルまたは解釈実行されるべき、オブジェクト・コードまたはソース・コード）であればよい。さらに、任意のコンピュータ使用可能媒体上にプログラムを提供することが可能である。媒体は、プログラムを含むこと、格納すること、伝達すること、伝播させることまたは転送することに適した任意の構成要素であればよい。例えば、媒体は、電子、磁気、光学、電磁気、赤外線または半導体形式のものであればよい。このような媒体の例は、固定ディスク（プログラムがプレインストールされている場合もある）、取外し可能ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波などである。いずれにせよ、本発明の実施形態によるソリューションは、ハードウェア構造を用いての実装（例えば半導体材料のチップに統合されて）、またはソフトウェアとハードウェアとの組み合わせを用いての実装に適している。

さらに、提案される方法は、異なるアーキテクチャを有するシステム上、または等価なユニットを複数含んだシステム（例えばローカル・ネットワークに基づく）上で行われてもよい。さらに、サーバは別の構造を有してもよく、または類似の構成要素（プログラムまたはその一部を一時的に格納するキャッシュ・メモリなど）を含んでもよい。いずれにせよ、サーバを、１つ以上のデータ処理エンティティまたはそれらの組み合わせ（例えば、多層構成アーキテクチャ（ｍｕｌｔｉ−ｔｉｅｒ ａｒｃｈｉｔｅｃｔｕｒｅ）、グリッド・コンピューティング・インフラストラクチャなど）に置き換えることが可能である。

図１Ａ〜図１Ｂは、本発明の実施形態によるソリューションの例示的な適用の図的表現を提供する。 図２Ａ〜図２Ｂは、本発明の実施形態によるソリューションの例示的な適用の図的表現を提供する。 図３Ａ〜図３Ｂは、本発明のさらなる実施形態によるソリューションの適用例を示す。 図４Ａ〜図４Ｂは、本発明のさらなる実施形態によるソリューションの適用例を示す。 本発明の実施形態によるソリューションを実践するのに使用可能なインフラストラクチャの概略ブロック図である。 本発明の実施形態によるソリューションを実装するのに使用されるとよい主要ソフトウェア・コンポーネントを示す。 本発明の実施形態によるソリューションの実装に関するアクティビティの流れを表現する図を示す。 本発明の実施形態によるソリューションの実装に関するアクティビティの流れを表現する図を示す。

１２５ 参加者リスト
１３０ 通信アドレス

Claims (10)

1. 共同ワーキング・セッションを管理する方法（６００）であって、データ処理システム（４２０）の制御下にある以下のステップ：
   共通する一連のリソースを必要とし、複数の参加者によってそれぞれ参加される一連のワーキング・セッションの予定を組むステップ（６０６〜６１２）と、
   少なくとも１つの通信アドレスと、各参加者とを関連付けるステップ（６１５）と、
   前記リソースの利用可能性を信号で伝えるステップ（６１８〜６３０）と、
   現在のワーキング・セッションへの参加者それぞれに関連付けられている前記少なくとも１つの通信アドレスを読み出すステップ（６３３）であって、前記現在のワーキング・セッションは、未開催のワーキング・セッションのうち最初に開催される予定のものである、前記ステップ（６３３）と、
   前記現在のワーキング・セッションの開催を示すメッセージを、前記現在のワーキング・セッションへの参加者それぞれに関連付けられている前記少なくとも１つの通信アドレスへ送信するステップ（６３６）と、
   を含む方法。
2. 前記リソースの前記利用可能性を信号で伝える前記ステップ（６１８〜６３０）は、
   前記現在のワーキング・セッションの開始を信号で伝えること（６１８、６３０）
   を含む、請求項１に記載の方法（６００）。
3. 前記リソースの前記利用可能性を信号で伝える前記ステップ（６１８〜６３０）は、
   前記現在のワーキング・セッションの直前に予定されている先行のワーキング・セッションの終了を信号で伝えること（６１８、６２４〜６３０）
   を含む、請求項１または２に記載の方法（６００）。
4. 前記ワーキング・セッションの予定を組む前記ステップ（６０６〜６１２）は、
   識別子と、各ワーキング・セッションとを関連付けること（６０９）
   を含み、前記リソースの前記利用可能性を信号で伝える前記ステップ（６１８〜６３０）は、
   前記現在のワーキング・セッションの前記開始を信号で伝えるために前記現在のワーキング・セッションの前記識別子を、または前記先行のワーキング・セッションの前記終了を信号で伝えるために前記先行のワーキング・セッションの前記識別子を、あるいはその両方を入力すること（６１８）
   を含む、請求項２または３に記載の方法（６００）。
5. 前記現在のワーキング・セッションの遅延を判断するステップ（６４２〜６５４）と、
   前記遅延に従って、前記現在のワーキング・セッションの後に予定されている、後続の一連のワーキング・セッションの予定を変更するステップ（６５７〜６６３）と、
   をさらに含む、請求項１〜４いずれかに記載の方法（６００）。
6. 後続のワーキング・セッションそれぞれについて、
   前記後続のワーキング・セッションへの参加者それぞれに関連付けられている前記少なくとも１つの通信アドレスを読み出すステップ（６６６）と、
   前記後続のワーキング・セッションの前記予定変更を示すメッセージを、前記後続のワーキング・セッションへの参加者それぞれに関連付けられている前記少なくとも１つの通信アドレスへ送信するステップ（６６９）と、
   をさらに含む、請求項５に記載の方法（６００）。
7. 前記ワーキング・セッションの予定を組む前記ステップ（６０６〜６１２）は、
   各ワーキング・セッションの開始予定および終了予定を指定すること（６１８）
   を含み、前記現在のワーキング・セッションの前記遅延を判断する前記ステップ（６４２〜６５４）は、
   前記現在のワーキング・セッションの実際の開始または実際の終了あるいはその両方を監視すること（６４２）と、
   前記現在のワーキング・セッションの前記実際の開始がないまま、前記現在のワーキング・セッションの前記開始予定から経過した時間、または、前記現在のワーキング・セッションの前記実際の終了がないまま、前記現在のワーキング・セッションの前記終了予定から経過した時間、あるいはその両方に従い、前記遅延を計算すること（６５４）と、
   を含む、請求項５または６に記載の方法（６００）。
8. 前記後続のワーキング・セッションの予定を変更する前記ステップ（６５７〜６６３）は、
   前記遅延に従い、前記後続のワーキング・セッションを延期すること（６６０）または短縮すること（６６３）、あるいはその両方
   を含む、請求項５〜７いずれかに記載の方法（６００）。
9. データ処理システム（４２０）上で実行された場合に、請求項１〜８いずれかに記載の方法（６００）を遂行するための、コンピュータ・プログラム（５００）。
10. 請求項１〜８いずれかに記載の方法（６００）の前記ステップを遂行する手段（５００）を含むシステム（４００）。

Images