(57)【要約】【課題】新規イベントのスケジュール登録者から開始されるスケジュール調整を、無限ループに陥ることなく合理的に完結させることが可能なスケジュール調整装置、スケジュール調整プログラムおよびスケジュール調整エージェントを提供する。【解決手段】他のスケジュール調整装置から、すでに登録されている登録イベントを他の日時に移動するように依頼する移動依頼通知を受信した場合に、自己の端末ＩＤが移動依頼通知に含まれていれば（Ｓ２７２：ＹＥＳ）、移動は不可能と回答する（Ｓ２７３）。端末ＩＤが移動依頼通知に含まれておらず（Ｓ２７２：ＮＯ）、移動先日時に他の登録イベントがなければ（Ｓ２７８：ＮＯ）、移動は可能と回答する（Ｓ２８０）。それ以外の場合には、移動させる登録イベントを特定し（Ｓ２８１またはＳ２８５）、登録イベントの参加者にも、同様に登録イベントを移動するように依頼する（Ｓ３００）。【選択図】図１７
2008269417.tif 000002
【特許請求の範囲】
【請求項１】
他のスケジュール調整装置との間で通信を行ってイベントのスケジュールを調整するスケジュール調整装置であって、
自己以外のスケジュール調整装置である外部装置から、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に自己の識別情報が含まれているか否かを判断する識別情報判断手段と、
前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段と、
前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他の登録イベントである移動先イベントがあるか否かを判断する移動先登録判断手段と、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていると判断された場合に、前記外部装置に対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段と、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部装置に対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段と、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段と、
前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記自己の識別情報を付加した前記移動依頼通知を作成する移動依頼通知作成手段と、
前記移動対象イベントの参加者のスケジュール調整装置である参加者装置に対して、前記移動依頼通知を送信する移動依頼送信手段と
を備えたことを特徴とするスケジュール調整装置。
【請求項２】
前記参加者装置のすべてから前記移動可能通知を受信した場合に、前記外部装置に対して、前記移動可能通知を送信する第２の移動可能通知送信手段と、
前記参加者装置のうち少なくとも１つから前記移動不可通知を受信した場合に、前記外部装置に対して、前記移動不可通知を送信する第２の移動不可通知送信手段と
をさらに備えたことを特徴とする請求項１に記載のスケジュール調整装置。
【請求項３】
前記移動依頼通知に含まれる重要度が前記移動対象イベントの重要度よりも高いか否かを判断する重要度判断手段と、
前記重要度判断手段によって、前記移動依頼通知に含まれる重要度が前記移動対象イベントの重要度よりも高いと判断された場合には、前記外部装置に対して、前記移動不可通知を送信する第３の移動不可送信手段とをさらに備えたことを特徴とする請求項１または２に記載のスケジュール調整装置。
【請求項４】
前記移動依頼作成手段は、
前記移動対象イベントの開催日時の変更が許容される時間帯として予め設定された猶予期間内で前記移動先日時を設定することを特徴とする請求項１〜３のいずれかに記載のスケジュール調整装置。
【請求項５】
前記移動依頼通知には、前記登録イベントの参加者に関する情報を含まないことを特徴とする請求項１〜４のいずれかに記載のスケジュール調整装置。
【請求項６】
他のスケジュール調整装置との間で通信を行ってイベントのスケジュールを調整するスケジュール調整装置であって、
自己以外のスケジュール調整装置である外部装置から、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に含まれる伝播回数が規定値を超えているか否かを判断する伝播回数判断手段と、
前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段と、
前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段と、
前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていると判断された場合に、前記外部装置に対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段と、
前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部装置に対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段と、
前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段と、
前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記伝播回数に１を加算した前記移動依頼通知を作成する移動依頼通知作成手段と、
前記移動対象イベントの参加者のスケジュール調整装置である参加者装置に対して、前記移動依頼通知を送信する移動依頼送信手段と
を備えたことを特徴とするスケジュール調整装置。
【請求項７】
請求項１〜６のいずれかに記載のスケジュール調整装置の各種処理手段としてコンピュータを機能させるためのスケジュール調整プログラム。
【請求項８】
他のスケジュール調整エージェントとの間で通信を行ってイベントのスケジュールを調整する、コンピュータ上で起動されるプログラムであるスケジュール調整エージェントであって、
自己以外のスケジュール調整エージェントである外部エージェントから、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に自己の識別情報が含まれているか否かを判断する識別情報判断手段、
前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段、
前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていると判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段、
前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段、
前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記自己の識別情報を付加した前記移動依頼通知を作成する移動依頼通知作成手段、および
前記移動対象イベントの参加者のスケジュール調整エージェントである参加者エージェントに対して、前記移動依頼通知を送信する移動依頼送信手段
としてコンピュータを機能させることを特徴とするスケジュール調整エージェント。
【請求項９】
他のスケジュール調整エージェントとの間で通信を行ってイベントのスケジュールを調整する、コンピュータ上で起動されるプログラムであるスケジュール調整エージェントであって、
自己以外のスケジュール調整エージェントである外部エージェントから、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に含まれる伝播回数の値が規定値を超えているか否かを判断する伝播回数判断手段、
前記移動依頼通知に、前記登録イベントの移動先の日時である移動先に日時が含まれているか否かを判断する移動先有無判断手段、
前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段、
前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていると判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段、
前記伝播回数判断手段によって前記伝播回数が規定値を超えていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段、
前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段、
前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記伝播回数に１を加算した前記移動依頼通知を作成する前記移動依頼通知を作成する移動依頼通知作成手段、および
前記移動対象イベントの参加者のスケジュール調整エージェントである参加者エージェントに対して、前記移動依頼通知を送信する移動依頼送信手段
としてコンピュータを機能させることを特徴とするスケジュール調整エージェント。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケジュール調整装置、スケジュール調整プログラムおよびスケジュール調整エージェントに関し、より具体的には、他のスケジュール調整装置のエージェントとの間で通信を行ってイベントのスケジュールを調整するエージェントを備えたスケジュール調整装置、スケジュール調整プログラムおよびスケジュール調整エージェントに関する。
【背景技術】
【０００２】
従来から、ユーザの必要最小限の介在のもとに、ユーザの意図を理解して自律的な判断に基づいた処理を実行するエージェントが、会議等のイベント参加者のスケジュールを自動的に調整するシステムが知られている。例えば特許文献１に記載の発明のスケジュール調整システムでは、スケジュールとして登録される各イベントについて、イベントおよび参加者の重み付けを表す重要度が入力されており、新規スケジュールの登録の際には、必要に応じて既存スケジュールが強制的に移動される。例えば、新規スケジュールと重複する日時に登録された既存スケジュールが存在する場合、新規スケジュールの重要度の方が高く、かつ既存スケジュールに変更を許容する許容変更日が設定されていれば、強制的に既存スケジュールを許容変更日に変更する。
【特許文献１】特開２００４−２９５７８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に記載されているスケジュール調整システムでは、既存スケジュールが強制的に許容変更日の他の日時に移動される場合、移動対象となる既存スケジュールの他の参加者のスケジュールは考慮されていない。すなわち、既存スケジュールを移動させるためには、他の参加者も同様に既存スケジュールを移動させなければならないことが考慮されていない。移動先である許容変更日の他の日時に、さらに別の既存スケジュールが登録されている参加者がいる場合には、さらにその別の既存スケジュールの参加者のスケジュールも調整しなければならない。このような場合、複数の階層にわたってスケジュール調整が行われた結果、自己の新規イベントの登録のために再び自己のスケジュールの変更を強いられるという不合理な結果をもたらす虞があった。また、下位の階層へのスケジュール調整が延々と継続して完結しない状態、すなわち無限ループに陥る虞もあった。
【０００４】
本発明は、上記問題点を解決するためになされたものであり、新規イベントのスケジュール登録者から開始されるスケジュール調整を、無限ループに陥ることなく合理的に完結させることが可能なスケジュール調整装置、スケジュール調整プログラムおよびスケジュール調整エージェントを提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するために、請求項１に係る発明のスケジュール調整装置は、他のスケジュール調整装置との間で通信を行ってイベントのスケジュールを調整するスケジュール調整装置であって、自己以外のスケジュール調整装置である外部装置から、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に自己の識別情報が含まれているか否かを判断する識別情報判断手段と、前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段と、前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他の登録イベントである移動先イベントがあるか否かを判断する移動先登録判断手段と、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていると判断された場合に、前記外部装置に対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段と、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部装置に対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段と、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段と、前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記自己の識別情報を付加した前記移動依頼通知を作成する移動依頼通知作成手段と、前記移動対象イベントの参加者のスケジュール調整装置である参加者装置に対して、前記移動依頼通知を送信する移動依頼送信手段とを備えている。
【０００６】
請求項２に係る発明のスケジュール調整装置は、請求項１に記載の発明の構成に加えて、前記参加者装置のすべてから前記移動可能通知を受信した場合に、前記外部装置に対して、前記移動可能通知を送信する第２の移動可能通知送信手段と、前記参加者装置のうち少なくとも１つから前記移動不可通知を受信した場合に、前記外部装置に対して、前記移動不可通知を送信する第２の移動不可通知送信手段とをさらに備えている。
【０００７】
請求項３に係る発明のスケジュール調整装置は、請求項１または２に記載の発明の構成に加えて、前記移動依頼通知に含まれる重要度が前記移動対象イベントの重要度よりも高いか否かを判断する重要度判断手段と、前記重要度判断手段によって、前記移動依頼通知に含まれる重要度が前記移動対象イベントの重要度よりも高いと判断された場合には、前記外部装置に対して、前記移動不可通知を送信する第３の移動不可送信手段とをさらに備えている。
【０００８】
請求項４に係る発明のスケジュール調整装置は、請求項１〜３のいずれかに記載の発明の構成に加えて、前記移動依頼作成手段は、前記移動対象イベントの開催日時の変更が許容される時間帯として予め設定された猶予期間内で前記移動先日時を設定することを特徴とする。
【０００９】
請求項５に係る発明のスケジュール調整装置は、請求項１〜４のいずれかに記載の発明の構成に加えて、前記移動依頼通知には、前記登録イベントの参加者に関する情報を含まないことを特徴とする。
【００１０】
請求項６に係る発明のスケジュール調整装置は、他のスケジュール調整装置との間で通信を行ってイベントのスケジュールを調整するスケジュール調整装置であって、自己以外のスケジュール調整装置である外部装置から、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に含まれる伝播回数が規定値を超えているか否かを判断する伝播回数判断手段と、前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段と、前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段と、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていると判断された場合に、前記外部装置に対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段と、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部装置に対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段と、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段と、前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記伝播回数に１を加算した前記移動依頼通知を作成する移動依頼通知作成手段と、前記移動対象イベントの参加者のスケジュール調整装置である参加者装置に対して、前記移動依頼通知を送信する移動依頼送信手段とを備えている。
【００１１】
請求項７に係る発明のスケジュール調整プログラムは、請求項１〜６のいずれかに記載のスケジュール調整装置の各種処理手段としてコンピュータを機能させる。
【００１２】
請求項８に係る発明のスケジュール調整エージェントは、他のスケジュール調整エージェントとの間で通信を行ってイベントのスケジュールを調整する、コンピュータ上で起動されるプログラムであるスケジュール調整エージェントであって、自己以外のスケジュール調整エージェントである外部エージェントから、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に自己の識別情報が含まれているか否かを判断する識別情報判断手段、前記移動依頼通知に、前記登録イベントの移動先の日時である移動先日時が含まれているか否かを判断する移動先有無判断手段、前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていると判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記識別情報判断手段によって前記移動依頼通知に自己の識別情報が含まれていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段、前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記自己の識別情報を付加した前記移動依頼通知を作成する移動依頼通知作成手段、および前記移動対象イベントの参加者のスケジュール調整エージェントである参加者エージェントに対して、前記移動依頼通知を送信する移動依頼送信手段としてコンピュータを機能させる。
【００１３】
請求項９に係る発明のスケジュール調整エージェントは、他のスケジュール調整エージェントとの間で通信を行ってイベントのスケジュールを調整する、コンピュータ上で起動されるプログラムであるスケジュール調整エージェントであって、自己以外のスケジュール調整エージェントである外部エージェントから、すでに登録されているイベントである登録イベントを他の日時に移動するように依頼する移動依頼通知を受けた場合に、前記移動依頼通知に含まれる伝播回数の値が規定値を超えているか否かを判断する伝播回数判断手段、前記移動依頼通知に、前記登録イベントの移動先の日時である移動先に日時が含まれているか否かを判断する移動先有無判断手段、前記移動先有無判断手段によって、前記移動依頼通知に前記移動先日時が含まれていると判断された場合に、前記移動先日時にすでに登録されている他のイベントである移動先イベントがあるか否かを判断する移動先登録判断手段、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていると判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が不可能であるという移動不可通知を送信する第１の移動不可通知送信手段、前記伝播回数判断手段によって前記伝播回数が規定値を超えていないと判断された場合であって、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントはないと判断された場合に、前記外部エージェントに対して、前記登録イベントの移動が可能であるという移動可能通知を送信する第１の移動可能通知送信手段、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記移動先有無判断手段によって前記移動依頼通知に前記移動先日時が含まれていないと判断された場合には、前記登録イベントを移動対象イベントとして特定し、前記伝播回数判断手段によって前記伝播回数が前記規定値を超えていないと判断され、且つ、前記登録判断手段によって前記移動先日時に前記移動先イベントがあると判断された場合には、前記移動先イベントを移動対象イベントとして特定する移動対象イベント特定手段、前記移動対象イベントを新たな前記登録イベントとして前記移動先日時を新たに設定し、前記伝播回数に１を加算した前記移動依頼通知を作成する前記移動依頼通知を作成する移動依頼通知作成手段、および前記移動対象イベントの参加者のスケジュール調整エージェントである参加者エージェントに対して、前記移動依頼通知を送信する移動依頼送信手段としてコンピュータを機能させる。
【発明の効果】
【００１４】
請求項１に係る発明のスケジュール調整装置によれば、移動依頼通知に自己の識別情報を付加することにより、自己の移動依頼から派生した移動依頼によって自己の登録イベントを移動させなければならないという不合理なスケジュール調整が行われる事態を回避することができる。
【００１５】
請求項２に係る発明のスケジュール調整装置によれば、請求項１に記載の発明の効果に加えて、最初の移動依頼通知の発信元である外部装置は、移動依頼通知の送信先である参加者装置からの移動可否の返答に応じて、新規イベントの登録の可否の最終判断をすることができる。
【００１６】
請求項３に係る発明のスケジュール調整装置によれば、請求項１または２に記載の発明の効果に加えて、重要度の高い登録イベントが、重要度の低いイベントを登録させるために移動をさせられるという不合理な処理が行われるのを回避することができる。
【００１７】
請求項４に係る発明のスケジュール調整装置によれば、請求項１〜３のいずれかに記載の発明の効果に加えて、元々変更が想定される範囲内で、ユーザにとって不都合のないスケジュール変更を行うことができる。
【００１８】
請求項５に係る発明のスケジュール調整装置によれば、請求項１〜４のいずれかに記載の発明の効果に加えて、移動依頼通知を受信するユーザに直接関係のないユーザの情報まで伝播していく危険を回避することができる。
【００１９】
請求項６に係る発明のスケジュール調整装置によれば、移動依頼通知に依頼の伝播回数に関する情報を付加することにより、移動依頼が際限なく続けられる非効率的なスケジュール調整を行わないようにすることができる。
【００２０】
請求項７に係る発明のスケジュール調整プログラムによれば、請求項１〜６のいずれかに記載の発明の効果を奏することができる。
【００２１】
請求項８に係る発明のスケジュール調整エージェントによれば、移動依頼通知に自己の識別情報を付加することにより、自己の移動依頼から派生した移動依頼によって自己の登録イベントを移動させなければならないという不合理な処理を回避しながら、自律的にスケジュール調整処理を行うことができる。
【００２２】
請求項９に係る発明のスケジュール調整エージェントによれば、移動依頼通知に依頼の伝播回数に関する情報を付加することにより、移動依頼が際限なく続けられる非効率的な処理を回避しながら、自律的にスケジュール調整処理を行うことができる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明を具体化した実施の形態について、図面を参照して説明する。なお、参照する図面は、本発明が採用しうる技術的特徴を説明するために用いられるものであり、記載されている装置の構成、各種処理のフローチャートなどは、特に特定的な記載がない限り、それのみに限定する趣旨ではなく、単なる説明例である。
【００２４】
<第１の実施形態>
以下に、図１〜図１９を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、本実施形態に係るスケジュール調整システム１の構成について説明する。図１は、スケジュール調整システム１の全体構成図である。図１に示すように、スケジュール調整システム１は、管理サーバ１０と、本発明の「スケジュール調整装置」である複数のユーザ端末２０とがＬＡＮ２によって相互に接続された構成を有する。そして、スケジュール調整システム１では、ユーザ端末２０のユーザ２００がユーザ端末２０からネットワークを介して管理サーバ１０にアクセスして必要なデータを入手し、他のユーザ端末２０との間で、後述するスケジュール調整処理を行う。なお、図中のユーザ端末２１〜２５はすべて同じ構成を有するため、これ以降、「ユーザ端末２０」という場合には、複数のユーザ端末２１、２２・・・他のすべてのユーザ端末を総称するか、または不特定のユーザ端末を指し、「ユーザ端末２１」という場合には、ある特定の「ユーザ端末２１」を指すものとする。また、各ユーザ端末２０は、それぞれについてユーザが特定されており、「ユーザ２００」という場合には、不特定のユーザ端末２０のユーザを指し、「ユーザ２０１」、「ユーザ２０２」等という場合には、それぞれ「ユーザ端末２１のユーザ２０１」、「ユーザ端末２２の２０２」等を指すものとする。なお、図１では、説明の便宜のため、ユーザ端末２０は５台しか図示していないが、台数には特に限定はなく、１台であっても、５台以外の複数であってもよい。
【００２５】
次に、図２〜図４を参照して、管理サーバ１０およびユーザ端末２０の構成について説明する。図２は、管理サーバ１０の電気的構成を示すブロック図である。図３は、ユーザ端末２０の電気的構成を示すブロック図である。図４は、ユーザ端末２０のＲＡＭ２３０の説明図である。
【００２６】
まず、図２を参照して、管理サーバ１０の構成について説明する。管理サーバ１０は、所謂パーソナルコンピュータであり、汎用型の装置である。図２に示すように、管理サーバ１０は、管理サーバ１０の制御を司るＣＰＵ１１０を備え、ＣＰＵ１１０には、ＢＩＯＳ等を記憶したＲＯＭ１２０と、各種のデータを一時的に記憶するＲＡＭ１３０が接続されている。さらにＣＰＵ１１０には、データの受け渡しの仲介を行うＩ／Ｏインタフェイス１４０が接続されている。Ｉ／Ｏインタフェイス１４０には、マウス１６１、ビデオコントローラ１６２、キーコントローラ１６４、通信装置１７０、およびハードディスク装置１５０が接続されている。ビデオコントローラ１６２には、ディスプレイ１６３が接続されており、ビデオコントローラ１６２によって制御されている。キーコントローラ１６４には、キーボード１６５が接続されており、キーコントローラ１６４によって制御されている。通信装置１７０はＬＡＮ２に接続されており、管理サーバ１０は、この通信装置１７０を介してユーザ端末２０との通信を行うことができる。
【００２７】
記憶装置であるハードディスク装置１５０は、個人情報データベース（個人情報ＤＢ）記憶エリア１５１、プログラム記憶エリア１５２、その他の情報記憶エリア１５３を含む複数の記憶エリアを備えている。個人情報ＤＢ記憶エリア１５１には、各ユーザ端末２０のＩＰアドレス、端末の識別コード、ユーザ２００の識別コード、氏名、部署、役職、電話番号、電子メールアドレス等の個人情報が格納された個人情報ＤＢが記憶されている。プログラム記憶エリア１５２には、管理サーバ１０の動作を制御する各種のプログラムが記憶されている。また、その他の情報記憶エリア１５３には、前述の記憶エリアに記憶されている以外の各種の情報が記憶される。
【００２８】
次に、図３および図４を参照して、ユーザ端末２０について説明する。ユーザ端末２０は、所謂パーソナルコンピュータであり、汎用型の装置である。図３に示すように、ユーザ端末２０は、ユーザ端末２０の制御を司るＣＰＵ２１０を備え、ＣＰＵ２１０には、ＢＩＯＳ等を記憶したＲＯＭ２２０と、各種のデータを一時的に記憶するＲＡＭ２３０が接続されている。なお、ＲＡＭ２３０の詳細については後述する。さらにＣＰＵ２１０には、データの受け渡しの仲介を行うＩ／Ｏインタフェイス２６０が接続されている。Ｉ／Ｏインタフェイス２６０には、マウス２６１、ビデオコントローラ２６２、キーコントローラ２６４、通信装置２７０、およびハードディスク装置２５０が接続されている。ビデオコントローラ２６２には、ディスプレイ２６３が接続されており、ビデオコントローラ２６２によって制御されている。キーコントローラ２６４には、キーボード２６５が接続されており、キーコントローラ２６４によって制御されている。通信装置２７０はＬＡＮ２に接続されており、ユーザ端末２０は、この通信装置２７０を介して管理サーバ１０や他のユーザ端末２０との通信を行うことができる。
【００２９】
記憶装置であるハードディスク装置２５０は、管理エージェント記憶エリア２５１、交渉エージェント記憶エリア２５２、移動エージェント記憶エリア２５３、スケジュール管理エージェント記憶エリア２５４、基本情報記憶エリア２５５、スケジュールデータベース（ＤＢ）記憶エリア２５６、プログラム記憶エリア２５７、その他の情報記憶エリア２５８を含む複数の記憶エリアを備えている。
【００３０】
管理エージェント記憶エリア２５１には、管理エージェントが記憶されている。なお、「エージェント」とは、ユーザの逐次の入力を必要とすることなく、いずれかの装置内で自律的に動作し、所定の処理を実行するプログラムおよび関連するデータから構成されるソフトウェアである。本実施形態の管理エージェントは、適宜、他のエージェントを動作させて、ユーザ端末２０におけるスケジュール調整処理を管理統括する。交渉エージェント記憶エリア２５２には、交渉エージェントが記憶されている。交渉エージェントは、管理エージェントからの指示に従って起動される。そして、他のユーザ端末２０の交渉エージェントにスケジュールの空きを問合せたり、他のユーザ端末２０の交渉エージェントからの問合せに応じて自己のユーザ２００のスケジュールの空きを確認したりする。移動エージェント記憶エリア２５３には、移動エージェントが記憶されている。移動エージェントは、交渉エージェントによる交渉だけでスケジュールが調整できなかった場合に、管理エージェントからの指示に従って起動される。そして、他のユーザ端末２０の移動エージェントに、すでに登録されているイベントの移動を依頼したり、他のユーザ端末２０の移動エージェントからの依頼に応じてイベントの移動の可否を判断したりする。スケジュール管理エージェント記憶エリア２５４には、スケジュール管理エージェントが記憶されている。スケジュール管理エージェントは、管理エージェントによって起動され、他のエージェントからの指示に従って、後述するスケジュールＤＢに記憶された、ユーザ端末２０のユーザ２００のスケジュールの読み出しや書込みを行う。本実施形態では、管理エージェント、交渉エージェント、移動エージェント、およびスケジュール管理エージェントの４種類のエージェントが協働して、スケジュール調整処理が行われる。なお、これらのエージェントによる処理の詳細については後述する。
【００３１】
基本情報記憶エリア２５５には、各ユーザ端末２０に固有の識別コードである、端末ＩＤ等、ユーザ端末２０の基本情報が記憶されている。端末ＩＤは、後述する移動エージェントによる移動交渉処理において、他のユーザ端末２０へ移動依頼通知を送信する毎に、通知の送信者を識別するために付加されるものである。スケジュールＤＢ記憶エリア２５６には、スケジュールＤＢが記憶されている。スケジュールＤＢには、ユーザ端末２０のユーザ２００の「識別コード」、「氏名」が登録されるとともに、すでにスケジュール調整が行われて登録されたイベントの「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」等のスケジュール情報が登録されている。プログラム記憶エリア２５７には、ユーザ端末２０の動作を制御する各種のプログラムが記憶されている。その他の情報記憶エリア２５８には、前述した記憶エリアに記憶されている以外の各種の情報が記憶されている。
【００３２】
ここで、図４を参照して、ユーザ端末２０のＲＡＭ２３０の詳細について説明する。図４に示すように、ＲＡＭ２３０には、新規イベント情報記憶エリア２３１、参加者情報記憶エリア２３２、端末ＩＤ記憶エリア２３３、スケジュール情報記憶エリア２３４、初期設定情報記憶エリア２３５、空き確認日時記憶エリア２３６、空き確認応答記憶エリア２３７、空き判断日時記憶エリア２３８、移動対象日時記憶エリア２３９、移動対象者情報記憶エリア２４０、移動先日時記憶エリア２４１、移動可否応答記憶エリア２４２、移動依頼情報記憶エリア２４３、仮決定移動先日時記憶エリア２４４、決定イベント情報記憶エリア２４５、移動対象イベント情報記憶エリア２４６等が設けられている。
【００３３】
新規イベント情報記憶エリア２３１には、ユーザ端末２０においてユーザ２００により入力された、スケジュールＤＢへの新規登録を希望するイベントの情報（「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」等）が記憶される。参加者情報記憶エリア２３２には、イベントの参加者の利用するユーザ端末２０である参加者端末２０のＩＰアドレスおよび識別コード、参加者の識別コード等が記憶される。端末ＩＤ記憶エリア２３３には、ハードディスク装置２５０の基本情報記憶エリア２５５（図３参照）から読み出されたユーザ端末２０の識別コードである端末ＩＤが記憶される。スケジュール情報記憶エリア２３４には、スケジュール管理エージェントによってハードディスク装置２５０のスケジュールＤＢ（図３参照）から読み出されたスケジュール情報（「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」等）が記憶される。初期設定情報記憶エリア２３５には、管理エージェントが保持する各種の初期値が記憶される。例えば、スケジュール調整の際、考慮されるべき時間として、ユーザ２００の就業時間等が記憶される。
【００３４】
空き確認日時記憶エリア２３６には、交渉エージェントによって他のユーザ端末２０に対してスケジュールの空き確認が依頼される場合に、空き確認の対象日時である空き確認日時が記憶される。空き確認応答記憶エリア２３７には、交渉エージェントによって他のユーザ端末２０に対してスケジュールの空き確認が依頼された場合に、他のユーザ端末２０から受信した空き確認に対する応答が記憶される。空き判断日時記憶エリア２３８には、他のユーザ端末２０の交渉エージェントからスケジュールの空き確認を依頼された場合に、自ユーザのスケジュールの空き判断の対象日時となる空き判断日時が記憶される。移動対象日時記憶エリア２３９には、新規イベントを登録したい日時であって、すでにスケジュールとして登録されている登録イベントをその日時から移動させたい場合に移動エージェントによって特定される移動対象日時が記憶される。移動対象者情報記憶エリア２４０には、すでにスケジュールＤＢに登録されている登録イベントを移動させたい場合に、その登録イベントの参加者が移動エージェントによって移動対象者として特定され、移動対象者の利用するユーザ端末２０の情報（ＩＰアドレスおよび識別コード、参加者の識別コード等）が記憶される。移動先日時記憶エリア２４１には、すでにスケジュールＤＢに登録されている登録イベントを移動させたい場合に、移動エージェントによって設定されるその登録イベントの移動先日時が記憶される。移動可否応答記憶エリア２４２には、移動エージェントによって登録イベントの移動が依頼された場合に、依頼先のユーザ端末２０から受信した移動の可否に関する応答が記憶される。移動依頼情報記憶エリア２４３には、他のユーザ端末２０から受信した移動依頼通知が記憶される。具体的には、移動依頼通知に含まれる発信元のユーザ端末２０の端末ＩＤと、ある特定の日時に登録されている登録イベントを移動させるように依頼する内容のテキストデータが記憶される。仮決定移動先日時記憶エリア２４４には、他のユーザ端末２０からの登録イベントの移動依頼を受けて、さらに他のユーザ端末２０に対して登録イベントの移動を依頼した場合に、全参加者端末２０から移動可能の応答を受けて、登録イベントの移動先の日時として仮決定した仮決定日時が記憶される。決定イベント情報記憶エリア２４５は、スケジュール調整の結果、登録が決定した新規イベント情報が記憶される。移動対象イベント情報記憶エリア２４６には、他のユーザ端末２０から受けた移動依頼によって、移動させる対象となった登録イベントのイベント情報（「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」等）が記憶される。
【００３５】
次に、図５〜図１９を参照して、各ユーザ端末２０で行われるスケジュール調整処理について説明する。ユーザ端末２０におけるスケジュール調整処理は、前述した管理エージェント、交渉エージェント、移動エージェント、およびスケジュール管理エージェントの各プログラムに従って、ＣＰＵ２１０が実行するものである。ただし、以下では、便宜上、各エージェントを処理の主体として説明する。
【００３６】
まず、図５を参照して、スケジュール調整の基礎となる新規イベント情報について説明する。図５は、ディスプレイ２６３に表示される新規スケジュール入力画面５の模式図である。新規スケジュール入力画面５は、ディスプレイ２６３に表示され、ユーザ２００が、ユーザ端末２０のマウス２６１およびキーボード２６５を用いて新規イベントに関する情報を入力する画面である。なお、新規スケジュール入力画面５を介して入力される新規イベントの情報を総称して、「新規イベント情報」というものとする。図５に示すように、新規スケジュール入力画面５には、「タイトル」欄５１、「開始日時」欄５２、「猶予期間」欄５３、「所要時間」欄５４、「場所」欄５５、および「参加者」欄５６が設けられている。「タイトル」欄５１には、会議や展示会の名称等、新規イベントのタイトルが入力される。「開始日時」欄５２には、新規イベントを開始する日時が入力される。「猶予期間」欄５３には、新規イベントの開催猶予期間が入力される。開催猶予期間とは、新規イベントの開始日時を特定の日時に絞り込めない場合や、希望の開始日時はあるが、もしその開始日時に新規イベントを登録できなくても、「この期間内ならばよい」という一定の幅を持たせた期間である。「所要時間」欄５４には、新規イベントの所要時間が入力される。「場所」欄５５には、新規イベントの開催希望場所が入力される。「参加者」欄５６には、新規イベントへの参加を要請する他のユーザ端末２０のユーザ２００が入力される。ここに入力されたユーザ２００のユーザ端末２０のエージェントとの間で、後述するスケジュール調整が開始される。
【００３７】
さらに、新規スケジュール入力画面５の右下には、「設定」ボタン５８および「キャンセル」ボタン５９が設けられている。「設定」ボタン５８がクリックされると、入力した情報が確定され、ＲＡＭ２３０の新規イベント情報記憶エリア２３１（図４参照）に記憶される。図５の入力例では、タイトルとして「新規開発会議」が、開始日時として「２００７年３月５日１４時００分」が、開催猶予期間として「２００７年３月５日０９時００分〜２００７年３月５日１８時００分」が、所要時間として「１時間」が、場所として「本社第１会議室」が、参加者として「２０２、２０３」が記憶される。なお、本実施形態では、「開始日時」欄５２または「猶予期間」欄５３のいずれか、「所要時間」欄５４、および「参加者」欄５６は必須入力項目とされており、入力がされないまま「設定」ボタン５８がクリックされると、エラー音が発せられ、次の処理には進めないように構成されている。一方、「キャンセル」ボタン５９がクリックされた場合には、入力された新規イベント情報はＲＡＭ２３０の新規イベント情報記憶エリア２３１（図４参照）に記憶されずに、新規スケジュール入力画面５から、メニュー画面等の他の画面（図示外）へ移行する。
【００３８】
次に、図６および図７を参照して、管理エージェントによる全体処理について説明する。図６および図７は、管理エージェントによる全体処理のフローチャートである。なお、以下では、便宜上、ユーザ２０１が利用するユーザ端末２１において処理が行われているものとして説明するが、他のユーザ端末２２、２３等で処理が行われる場合でも、処理は同じである。
【００３９】
ハードディスク装置２５０の管理エージェント記憶エリア２５１（図３参照）に記憶された管理エージェントプログラムが起動され、図６に示す全体処理が開始されると、管理エージェントはまず、ハードディスク装置２５０のスケジュール管理エージェント記憶エリア２５４（図３参照）に記憶された、スケジュール管理エージェントを起動する（Ｓ１）。なお、スケジュール管理エージェントによる処理については、後述する。その後、管理エージェントは初期設定値を読み出し、ＲＡＭ２３０の初期設定情報記憶エリア２３５に記憶させる（Ｓ２）。具体的には、本実施形態の管理エージェントは、スケジュール調整に関する各種の初期設定値のデータを保持しており、このデータが初期設定情報記憶エリア２３５に取得される。例えば、イベントを登録可能な時間帯のデータとして、ユーザ２００の標準就業時間である９：００〜１８：００等が記憶される。その後、管理エージェントは、何らかの入力がされるまで待機し（Ｓ３：ＮＯ→Ｓ３）、何らかの入力がされると（Ｓ３：ＹＥＳ）、それが自ユーザ、すなわちユーザ２０１によるユーザ端末２１での新規イベント情報の入力か否かを判断する（Ｓ４）。ユーザ端末２１で、例えば、図５のように新規イベント情報が入力され、新規イベント情報がＲＡＭ２３０の新規イベント情報記憶エリア２３１に記憶された場合は、新規イベントの入力があったと判断される（Ｓ４：ＹＥＳ）。この場合、管理エージェントは、通信装置１７０を介してＬＡＮ２に接続し、管理サーバ１０のハードディスク装置１５０（図２参照）にアクセスする。そして、個人情報ＤＢ記憶エリア１５１に記憶されている個人情報ＤＢから、新規イベント情報記憶エリア２３１に記憶されている新規イベントの参加者の個人情報を読み出し、ＲＡＭ２３０の参加者情報記憶エリア２３２に記憶させる（Ｓ５）。具体的には、参加者の利用する他のユーザ端末２０（以下、単に参加者端末２０という）と通信を行うために、参加者端末２０のＩＰアドレス、参加者端末２０の識別コード、参加者の識別コード等が取得される。
【００４０】
その後、管理エージェントは、入力された新規イベントの開始日時に他の参加者のスケジュールに空きがあるか否かを確認するために、参加者端末２０の管理エージェントに対して、交渉エージェントの起動を依頼する（Ｓ６）。そして、全参加者端末２０の管理エージェントから、交渉エージェントの起動を完了したいう応答があったか否かを判断する（Ｓ１１）。全参加者端末２０で交渉エージェントが起動完了した場合には（Ｓ１１：ＹＥＳ）、自己のユーザ端末２１のハードディスク装置２５０の交渉エージェント記憶エリア２５２（図３参照）に記憶されている交渉エージェントを起動し（Ｓ１２）、交渉開始を指示する（Ｓ１３）。その後、入力があったか否かの判断に戻る（Ｓ２）。なお、交渉開始後の交渉エージェントの動作については、後で詳述する。一方、いずれかの参加者端末２０の管理エージェントから、交渉エージェントが起動できたという応答がない場合は（Ｓ１１：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ１４）。通信エラーで応答が完了しない場合には（Ｓ１４：ＹＥＳ）、ディスプレイ２６３にその旨のエラーメッセージを表示させて、自ユーザ（ユーザ２０１）に通知し（Ｓ１５）、入力があったか否かの判断に戻る（Ｓ２）。通信エラーでない場合は（Ｓ１４：ＮＯ）、Ｓ１１に戻り、全参加者端末２０で交渉エージェントの起動が完了するまで待機する（Ｓ１１：ＮＯ→Ｓ１４：ＮＯ→Ｓ１１）。
【００４１】
何らかの入力がされたが（Ｓ３：ＹＥＳ）、自ユーザからの新規イベント情報の入力ではなかった場合（Ｓ４：ＮＯ）、管理エージェントは、その入力が他のユーザ端末２０の管理エージェントからの交渉エージェント起動依頼か否かを判断する（Ｓ２１）。交渉エージェントの起動依頼であれば（Ｓ２１：ＹＥＳ）、自ユーザ端末２１のハードディスク装置２５０に記憶されている交渉エージェントを起動する（Ｓ２２）。そして、交渉エージェントを起動するよう依頼した依頼元のユーザ端末２０の管理エージェントに対して、交渉エージェントの起動が完了したという応答を送信し（Ｓ２３）、交渉エージェントに交渉開始を指示する（Ｓ２４）。その後、入力があったか否かの判断に戻る（Ｓ３）。
【００４２】
一方、入力が自ユーザからの新規イベント情報の入力でも、他のユーザ端末２０の管理エージェントからの交渉エージェント起動依頼でもなかった場合には（Ｓ４：ＮＯ→Ｓ２１：ＮＯ）、その入力が、自ユーザ端末２１の交渉エージェントからの移動エージェントの起動依頼であるか否かを判断する（Ｓ３１）。詳細は後述するが、交渉エージェントによる空き確認の結果、新規イベントの日時には参加者のスケジュールに空きがないと判明した場合に、移動エージェントの起動が依頼される（Ｓ３１：ＹＥＳ）。この場合、管理エージェントは、ハードディスク装置２５０の基本情報記憶エリア２５５（図３参照）に記憶されている自己の端末ＩＤを読み出して、ＲＡＭ２３０の端末ＩＤ記憶エリア２３３（図４参照）に記憶させる（Ｓ３３）。これは、後に移動エージェントにより生成される移動依頼通知に付加するためである。その後、管理エージェントは、参加者端末２０に新規イベントの日時にすでに登録されている登録イベントを移動するよう依頼するために、ハードディスク装置２５０の移動エージェント記憶エリア２５３（図３参照）に記憶されている移動エージェントを起動する（Ｓ３４）。そして、移動エージェントに、移動交渉開始を指示し（Ｓ３５）、入力があったか否かの判断に戻る（Ｓ３）。なお、移動交渉開始後の移動エージェントの動作については、後で詳述する。
【００４３】
入力が、自ユーザからの新規イベント情報の入力でも、他のユーザ端末２０の管理エージェントからの交渉エージェント起動依頼でも、自ユーザ端末２１からの移動エージェントの起動依頼でもなかった場合には（図６、Ｓ４：ＮＯ→Ｓ２１：ＮＯ→Ｓ３１：ＮＯ）、管理エージェントは、その入力が他のユーザ端末２０の管理エージェントからの移動エージェント起動依頼か否かを判断する（図７、Ｓ４１）。他のユーザ端末２０からの移動エージェントの起動依頼であれば（Ｓ４１：ＹＥＳ）、管理エージェントは、ハードディスク装置２５０の基本情報記憶エリア２５５（図３参照）に記憶されている自己の端末ＩＤを読み出して、ＲＡＭ２３０の端末ＩＤ記憶エリア２３３（図４参照）に記憶させる（Ｓ４２）。これは、自ユーザからの起動依頼の場合と同様、後で移動エージェントが生成する移動依頼通知に付加するためである。そして、自己のユーザ端末２１のハードディスク装置２５０の移動エージェント記憶エリア２５３（図３参照）に記憶されている移動エージェントを起動し（Ｓ４３）、移動エージェントを起動するよう依頼した依頼元のユーザ端末２０の管理エージェントに対して、移動エージェントの起動が完了したという応答を送信する（Ｓ４５）。その後、管理エージェントは、移動エージェントに移動交渉開始を指示し（Ｓ４６）、入力があったか否かの判断に戻る（Ｓ３）。
【００４４】
入力が、自ユーザからの新規イベント情報の入力でも、他のユーザ端末２０の管理エージェントからの交渉エージェント起動依頼でも、自ユーザまたは他のユーザ端末２０からの移動エージェントの起動依頼でもなかった場合には（図６、Ｓ４：ＮＯ→Ｓ２１：ＮＯ→Ｓ３１：ＮＯ→図７、Ｓ４１：ＮＯ）、管理エージェントは、その入力が自ユーザ端末２１の移動エージェントからの、新規イベントの登録指示依頼であるか否かを判断する（Ｓ５１）。登録指示依頼を受けた場合（Ｓ５１：ＹＥＳ）、移動交渉の結果、新規イベントの登録が決定されているので、新規イベントのすべての参加者の参加者端末２０の管理エージェントに対して、新規イベントの登録決定を指示し（Ｓ５２）、入力があったか否かの判断に戻る（Ｓ３）。入力が、自ユーザ端末２１の移動エージェントからの登録指示依頼でもなく、他のユーザ端末２１の管理エージェントからの登録指示の場合には（図６、Ｓ４：ＮＯ→Ｓ２１：ＮＯ→Ｓ３１：ＮＯ→図７、Ｓ４１：ＮＯ→Ｓ５１：Ｎｏ→Ｓ６１：ＹＥＳ）、後述するスケジュール管理エージェントに対して、ハードディスク装置２５０のスケジュールＤＢ（図３参照）に登録指示のあった新規イベント情報を書き込むように指示して（Ｓ６２）、入力があったか否かの判断に戻る（Ｓ３）。
【００４５】
入力が、自ユーザからの新規イベント情報の入力でも、他のユーザ端末２０の管理エージェントからの交渉エージェント起動依頼でも、自ユーザまたは他のユーザ端末２０からの移動エージェントの起動依頼でも登録指示でもない場合は（図６、Ｓ４：ＮＯ→Ｓ２１：ＮＯ→Ｓ３１：ＮＯ→図７、Ｓ４１：ＮＯ→Ｓ５１：ＮＯ→Ｓ６１：ＮＯ）、管理エージェントは、その入力がエラー報告であるか否かを判断する（Ｓ６４）。エラー報告である場合は（Ｓ６４：ＹＥＳ）、通信エラー等の理由で、空き確認の交渉や移動交渉に障害が発生した旨をディスプレイ２６３に表示させて通知し（Ｓ６５）、入力があったか否かの判断に戻る（Ｓ２）。入力が、エラー報告でもない場合は（Ｓ６４：ＮＯ）、管理エージェントは、その入力が終了指示であるか否かを判断する（Ｓ６７）。終了指示である場合は（Ｓ６７：ＹＥＳ）、管理エージェントは、スケジュール管理エージェント（図８参照）に処理の終了を指示してから（Ｓ６８）、図６および図７に示す（Ｓ６５）全体処理を終了し、終了指示でなければ（Ｓ６７：ＮＯ）入力があったか否かの判断に戻る（Ｓ３）。
【００４６】
次に、図８を参照して、スケジュール管理エージェントによって行われる処理について説明する。図８は、スケジュール管理エージェントによるスケジュール管理処理のフローチャートである。スケジュール管理エージェントは、他のエージェントからの指示に基づき、自ユーザ（ユーザ端末２１のユーザ２０１）のスケジュール情報の読み出しや書込みを行うエージェントである。図８に示す処理は、管理エージェントによってスケジュール管理エージェントが起動されることにより開始される（図６、Ｓ１）。処理が開始されると、スケジュール管理エージェントはまず、他のエージェントからスケジュール情報の読出し指示があったか否かを判断する（Ｓ４０１）。スケジュール情報の読出しが指示された場合には（Ｓ４０１：ＹＥＳ）、ハードディスク装置２５０のスケジュールＤＢ記憶エリア２５６に記憶されているスケジュールＤＢ（図３参照）から、指示のあった日時のユーザ２０１のスケジュール情報を読み出す。そして、ＲＡＭ２３０のスケジュール情報記憶エリア２３４（図４参照）に上書きする（Ｓ４０２）。例えば、「２００７年３月５日１４時００分〜１５時００分」のスケジュール情報の読出しの指示を受けた場合には、この日時にすでに登録されているイベント（以下、登録イベントという）があれば、スケジュール管理エージェントは、そのイベントの「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」を含むスケジュール情報を読出し、スケジュール情報記憶エリア２３４に記憶させる。なお、指示のあった日時に登録イベントがなければ、「Ｎｕｌｌ」を記憶させる。その後、スケジュール管理エージェントは、読出し指示があったか否かの判断に戻る（Ｓ４０１）。
【００４７】
一方、他のエージェントからの読出し指示はなく（Ｓ４０１：ＮＯ）、書込み指示を受けた場合は（Ｓ４０３：ＹＥＳ）、スケジュール管理エージェントは、書込みが指示されたイベントのイベント情報を、ハードディスク装置２５０のスケジュールＤＢ記憶エリア２５６に記憶されているスケジュールＤＢ（図３参照）に書き込む（Ｓ４０４）。例えば、新規イベントの登録が決定され、管理エージェントの指示を受けて（図７、Ｓ６２）書込みを行う場合には、新規イベントの「タイトル」、「日時」、「猶予期間」、「所要時間」、「場所」、「参加者」、「重要度」等の情報がスケジュールＤＢに新たに登録される。また、登録イベントの移動が決定され、移動エージェントの指示を受けて（図１４、Ｓ２１５）書込みを行う場合には、指示された登録イベントの日時を移動先の日時に書き換えてスケジュールＤＢに登録する。その後、スケジュール管理エージェントは、読出し指示があったか否かの判断に戻る（Ｓ４０１）。読出し指示も書き込み指示もない場合には（Ｓ４０１：ＮＯ→Ｓ４０３：ＮＯ）、管理エージェントから終了指示があったか否かを判断する（Ｓ４０５）。前述のように、管理エージェントにおいて終了が指示されると（図７、Ｓ６７：ＹＥＳ）、管理エージェントはスケジュール管理エージェントに対して終了を指示する（図７、Ｓ６８）。この指示を受けた場合には（Ｓ４０５：ＹＥＳ）、スケジュール管理エージェントは処理を終了し、指示がなければ（４０５：ＮＯ）、読出し指示があったか否かの判断に戻る（Ｓ４０１）。
【００４８】
次に、図９〜図１１を参照して、交渉エージェントによって行われる処理について説明する。図９は、交渉エージェントによるメイン処理のフローチャートである。交渉エージェントは、管理エージェントにより起動され（図６、Ｓ１２またはＳ２２）、他のユーザ端末２０の交渉エージェントとの間で、新規イベントの開催日時にすでに他のイベントが登録されているか否かの確認を行うエージェントである。図９は、交渉エージェントによるメイン処理のフローチャートである。図１０は、交渉エージェントのメイン処理で行われる空き確認処理のフローチャートである。図１１は、交渉エージェントのメイン処理の中で行われる空き判断処理のフローチャートである。
【００４９】
管理エージェントにより交渉エージェントが起動され（図６、Ｓ１２またはＳ２２）、図９に示すメイン処理が開始されると、交渉エージェントは、管理エージェントからの交渉開始指示（図６、Ｓ１３またはＳ２４）があるまで待機する（Ｓ１０１：ＮＯ→Ｓ１０１）。交渉開始指示があったと判断すると（Ｓ１０１：ＹＥＳ）、交渉エージェントは、交渉の開始が自ユーザから（ユーザ端末２１において）依頼されたものか否かを判断する（Ｓ１０２）。具体的には、交渉開始指示として管理エージェントから渡される引数の相違によって判断する。例えば、自ユーザからの交渉依頼であれば「１」、他のユーザ端末２０からの交渉依頼であれば「２」が渡される。渡された引数が自ユーザからの交渉依頼に対応するものである場合には（Ｓ１０２：ＹＥＳ）、交渉エージェントは、空き確認処理（Ｓ１２０）を行う。
【００５０】
ここで、空き確認処理（Ｓ１２０）の詳細について、図１０を参照して説明する。図１０に示す処理が開始されると、交渉エージェントはまず、自ユーザによって入力され、ＲＡＭ２３０の新規イベント情報記憶エリア２３１（図４参照）に記憶されている新規イベント情報を読み出す（Ｓ１２１）。そして、新規イベント情報に含まれる「開始日時」、「開催猶予期間」および「所要時間」に基づいて空き確認日時を設定し、ＲＡＭ２３０の空き確認日時記憶エリア２３６（図４参照）に記憶させる（Ｓ１２２）。具体的には、新規イベント情報記憶エリア２３１に「開始日時」の情報が記憶されている場合には、記憶された開始日時に「所要時間」を加算した時間帯が、空き確認日時として設定される。例えば、図５の新規スケジュール入力画面５の入力例であれば、「開始日時」として「２００７年３月５日１４時００分」、「所要時間」として「１時間」が記憶されているので、空き確認日時は、「２００７年３月５日１４時００分〜１５時００分」となる。一方、「開始日時」として、特定の日時が記憶されていない場合には、「開催猶予期間」の始期に「所要時間」を加算した時間帯が、空き確認日時として設定される。すなわち、例えば、「開催猶予期間」として「２００７年３月５日０９時００分〜２００７年３月５日１８時００分」が記憶されていれば、「２００７年３月５日０９時００分〜１０時００分」が空き確認日時として設定される。また、図５の例のように、「開始日時」および「開催猶予期間」がいずれも記憶されている場合には、「開始日時」が優先される。なお、前述したように、本実施形態では、「開始日時」および「開催猶予期間」のいずれかの入力がないと、新規イベント情報の入力が確定されないように構成されているため、必ず空き確認日時を設定することができる。
【００５１】
空き確認日時が設定されると（Ｓ１２２）、交渉エージェントは、前述のスケジュール管理エージェント（図８参照）に対して、ハードディスク装置２５０に記憶されているスケジュールＤＢ（図３参照）から、自ユーザの空き確認日時のスケジュール情報を読み出すよう指示する（Ｓ１２３）。そして、指示を受けたスケジュール管理エージェントにより、例えば、空き確認日時「２００７年３月５日１４時００分〜１５時００分」のスケジュール情報が読み出され、ＲＡＭ２３０のスケジュール情報記憶エリア２３４（図４参照）に記憶される（Ｓ１２４）。交渉エージェントは、このスケジュール情報を参照して、空き確認に日時に自ユーザのスケジュールが空いている（ＯＫ）か否かを判断する（Ｓ１３１）。スケジュール情報記憶エリア２３４に記憶されているのが「Ｎｕｌｌ」でなければ、空き確認日時には、すでに他の登録イベントが存在しており、空き確認日時には自ユーザのスケジュールは空いていない（Ｓ１３１：ＮＯ）。そこで交渉エージェントは、新規イベント情報記憶エリア２３１（図４参照）を参照して、「開催猶予期間」が記憶されているか否かを確認し、「開催猶予期間」があれば、開催猶予期間内の他の時間帯に空き確認日時をずらせるか判断する（Ｓ１６１）。例えば、空き確認日時の「２００７年３月５日１４時００分〜１５時００分」に自ユーザの空きがない場合（Ｓ１３１：ＮＯ）、開催猶予期間として「２００７年３月５日０９時００分〜２００７年３月５日１８時００分」、所要時間として「１時間」が記憶されていれば、空き確認日時を他にずらすことができる（Ｓ１６１：ＹＥＳ）。このような場合、交渉エージェントは、開催猶予期間内で最も早い時間帯を、新たに空き確認日時として設定し、空き確認日時記憶エリア２３６に上書きする（Ｓ１２２）。例えば、前述の例では、「２００７年３月５日０９時００分〜１０時００分」が空き確認日時として設定される。そして、再びＳ１２３〜Ｓ１３１の処理を行う。新たに設定された空き確認日時でも、自ユーザのスケジュールが空いていない場合には（Ｓ１３１：ＮＯ）、開催猶予期間内で空き確認日時をずらせる間は（Ｓ１６１：ＹＥＳ）、同様の処理を繰り返す。なお、開催猶予期間がまったく入力されていない場合には、最初から空き確認日時はずらせないと判断される（Ｓ１６１：ＮＯ）。また、開催猶予期間内で空き確認日時を何度かずらし、それ以上ずらせなくなった場合も（Ｓ１６１：ＮＯ）、交渉エージェントは、自ユーザ端末２１の管理エージェントに移動エージェントの起動を依頼する（Ｓ１６２）。これは、後述するように、移動エージェントにより、新規イベントの開催日時に他の登録イベントがすでにある参加者に対して、その登録イベントを移動させるように依頼するためである。そして、交渉エージェント同士の空き確認交渉を終了するために、参加者端末２０の交渉エージェントに処理の終了を指示してから（Ｓ１６３）、図９のメイン処理に戻る。
【００５２】
一方、Ｓ１３１において、スケジュール情報記憶エリア２３４（図４参照）に記憶されているのが「Ｎｕｌｌ」であると判断されれば、空き確認日時には他に登録イベントはなく、自ユーザのスケジュールは空いている（Ｓ１３１：ＹＥＳ）。そこで、交渉エージェントは、参加者端末２０の交渉エージェントに対して、空き確認日時を通知し、この日時に参加者のスケジュールが空いているか否かの確認を依頼する空き確認依頼を送信する（Ｓ１３２）。例えば、図５の入力例であれば、参加者であるユーザ２０２および２０３の利用するユーザ端末２２および２３に対して、「２００７年３月５日１４時００分〜１５時００分」の空きの有無を確認する空き確認通知が送信される。そして、交渉エージェントは、参加者端末２０からの応答があるまで待機し（Ｓ１３５：ＮＯ→Ｓ１３５）、応答を受信すると（Ｓ１３５：ＹＥＳ）、受信した応答を、空き確認日時および応答発信元の参加者端末２０の識別コードとともに、ＲＡＭ２３０の空き確認応答記憶エリア２３７（図４参照）に取得して記憶させる（Ｓ１３６）。そして、すでに全員から応答があったか否かを確認し（Ｓ１４１）、全参加者端末２０からの応答を受信していなければ（Ｓ１４１：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ１４２）。通信エラーにより応答が完了していない場合には（Ｓ１４２：ＹＥＳ）、管理エージェントにエラー報告をして（Ｓ１５３）、図９のメイン処理に戻る。通信エラーでない場合は（Ｓ１４２：ＮＯ）、Ｓ１３５に戻り、全参加者端末２０から応答を受信するまで、Ｓ１３５〜Ｓ１４２の処理を繰り返す。
【００５３】
全員から応答を受信すると（Ｓ１４１：ＹＥＳ）、交渉エージェントは、空き確認応答記憶エリア２３７（図４参照）を参照して、参加者端末２０からの応答がすべて空きがある（ＯＫ）との応答か否かを確認する（Ｓ１４５）。１つでも空きがない（ＮＧ）との応答があった場合（Ｓ１４５：ＮＯ）、交渉エージェントは、前述の自ユーザに空きがなかった場合（Ｓ１３１：ＮＯ）と同様にして、開催猶予期間内の他の時間帯に空き確認日時をずらせるか判断する（Ｓ１６１）。空き確認日時をずらすことができる場合には（Ｓ１６１：ＹＥＳ）、交渉エージェントは、開催猶予期間内で最も早い時間帯を、新たに空き確認日時として設定し、空き確認日時記憶エリア２３６に上書きする（Ｓ１２２）。そして、新たに設定された空き確認日時では、自ユーザのスケジュールが空いていない場合や（Ｓ１３１：ＮＯ）、全参加者端末２０からＯＫの応答が得られない場合には（Ｓ１４５：ＮＯ）、開催猶予期間内で空き確認日時をずらせる間は（Ｓ１６１：ＹＥＳ）、同様の処理を繰り返す。そして、開催猶予期間内で全参加者端末２０からＯＫが得られないまま（Ｓ１４５：ＮＯ）、空き確認日時をずらせなくなると（Ｓ１６１：ＮＯ）、交渉エージェントは、自ユーザ端末２１の管理エージェントに移動エージェントの起動を依頼する（Ｓ１６２）。そして、交渉エージェント同士の空き確認交渉を終了するために、参加者端末２０の交渉エージェントに処理の終了を指示してから（Ｓ１６３）、図９のメイン処理に戻る。
【００５４】
一方、最初または何度目かの参加者端末２０への空き確認（Ｓ１３２）の結果、全参加者端末２０からＯＫの応答が得られた場合には（Ｓ１４５：ＹＥＳ）、このときの空き確認日時で新規イベントの登録が決定される（Ｓ１４６）。このとき、交渉エージェントは、新規イベント情報記憶エリア２３１（図４参照）に記憶されている新規イベント情報の「開始日時」を空き確認日時記憶エリア２３６（図４参照）に記憶されている空き確認日時の開始日時に変更し、変更後の情報を、決定イベント情報として決定イベント情報記憶エリア２４５に記憶させる。その後、交渉エージェントは、参加者端末２０の交渉エージェントに対して、決定イベント情報記憶エリア２４５に記憶された決定イベント情報を通知し、各参加者端末２０において、新たにスケジュールＤＢ（図３参照）に登録するように指示する（Ｓ１４７）。なお、指示を受けたときの交渉エージェントの動作については後述する。その後、交渉エージェントは、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、決定された新規イベントをハードディスク装置２５０に記憶されているスケジュールＤＢに登録するよう指示し（Ｓ１５５）、図９のメイン処理に戻る。メイン処理に戻った場合はいずれも、そのまま交渉エージェントによる処理は終了する。
【００５５】
一方、図９のメイン処理において、管理エージェントから渡された引数に基づき、交渉の開始が自ユーザから（ユーザ端末２１において）依頼されたものではないと判断された場合には（Ｓ１０２：ＮＯ）、他のユーザ端末２０からの交渉依頼があったことを意味する。そこで交渉エージェントは、まず、他のユーザ端末２０の交渉エージェントから前述の空き確認処理（Ｓ１２０および図１０）において発信された空き確認依頼（図１０、Ｓ１３２）を受信したか否かを判断する（Ｓ１０５）。そして、空き確認依頼を受信した場合には（Ｓ１０５：ＹＥＳ）、空き判断処理を行う（Ｓ１７０）。
【００５６】
ここで、空き判断処理（Ｓ１７０）の詳細について、図１１を参照して説明する。図１１に示す処理が開始されると、交渉エージェントはまず、他のユーザ端末２０から空き確認依頼で通知された空き確認日時を、ＲＡＭ２３０の空き判断日時記憶エリア２３８に空き判断日時として記憶させる。そして、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、ハードディスク装置２５０のスケジュールＤＢ記憶エリア２５６（図３参照）に記憶されているスケジュールＤＢから、空き判断日時の自ユーザのスケジュール情報を読み出すように指示する（Ｓ１７２）。そして、指示を受けたスケジュール管理エージェントによって、空き判断日時のスケジュール情報が読み出され、ＲＡＭ２３０のスケジュール情報記憶エリア２３４に取得される（Ｓ１７３）。すなわち、登録イベントがあれば、その登録イベントのスケジュール情報が記憶され、登録イベントがなければ「Ｎｕｌｌ」が記憶される。よって、交渉エージェントは、スケジュール情報記憶エリア２３４に「Ｎｕｌｌ」が記憶されている場合には、空き判断日時に自ユーザのスケジュールは空いていると判断する（Ｓ１７６：ＹＥＳ）。そして、空き確認依頼の発信元のユーザ端末２０に対して、空き確認日時に空きがある（ＯＫ）と回答を発信する（Ｓ１７８）。一方、スケジュール情報記憶エリア２３４に「Ｎｕｌｌ」ではなく、何らかの登録イベントのスケジュール情報が記憶されている場合には、自ユーザのスケジュールに空きはない（Ｓ１７６：ＮＯ）。したがって、交渉エージェントは、空き確認依頼の発信元のユーザ端末２０に対して、空き確認日時に空きはない（ＮＧ）との回答を発信する（Ｓ１７７）。いずれの回答の場合も、回答後は、図９のメイン処理に戻り、他ユーザ端末２０からの空き確認依頼受信の有無の判断（Ｓ１０５）に戻る。
【００５７】
前述のように空き判断処理（Ｓ１７０）が行われた後、他のユーザ端末２０から空き確認依頼を受信していない場合には（Ｓ１０５：ＮＯ）、他のユーザ端末２０から、新規イベントの登録指示を受信したか否かを判断する（Ｓ１０６）。新規イベントの登録指示は、前述したように、空き確認処理（Ｓ１２０および図１０）において、空き確認を行った結果、参加者端末２０のすべてからＯＫの返答を得た結果、新規イベントの登録が決定された場合に参加者端末２０に送信されるものである（図１０、Ｓ１４７）。登録指示を受信した場合（Ｓ１０６：ＹＥＳ）、交渉エージェントは、登録指示で通知される決定イベント情報をＲＡＭ２３０の決定イベント情報記憶エリア２４５（図４参照）に記憶させる。そして、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、この決定イベント情報をハードディスク装置２５０のスケジュールＤＢ記憶エリア２５６（図３参照）に記憶されたスケジュールＤＢに書き込む（登録する）ように指示してから（Ｓ１０７）、処理を終了する。
【００５８】
他のユーザ端末２０から、空き確認依頼も登録指示も受信していないと判断した場合は（Ｓ１０５：ＮＯ→Ｓ１０６：ＮＯ）、交渉エージェントは、他のユーザ端末２０から終了指示があったか否かを判断する（Ｓ１１１）。終了指示は、前述したように、空き確認処理（Ｓ１２０および図１０）において、開催猶予期間内に参加者全員に共通の空きがないために新規イベントの登録ができず、交渉処理を終了させるために参加者端末２０に送信されるものである（図１０、Ｓ１６３）。そこで、終了指示を受けた場合（Ｓ１１１：ＹＥＳ）、交渉エージェントは処理を終了する。終了指示がない場合には（Ｓ１１１：ＮＯ）、Ｓ１０５に戻って、再び前述の処理を繰り返す。
【００５９】
次に、図１２〜図１８を参照して、移動エージェントによって行われる処理について説明する。移動エージェントは、交渉エージェントによる空き確認の結果、新規イベントの開催猶予期間内では参加者の空きが一致しなかった場合に、交渉エージェントの依頼（図１０、Ｓ１６２）により管理エージェントにより起動される（図６、Ｓ３４または図７、Ｓ４３）。そして、他のユーザ端末２０の移動エージェントとの間で、登録イベントを他の日時に移動できれば移動させる移動交渉を行うエージェントである。図１２は、移動依頼通知の説明図である。図１３は、派生移動依頼通知の説明図である。図１４は、移動エージェントによるメイン処理のフローチャートである。図１５は、移動エージェントによるメイン処理の中で行われる第１の移動処理のフローチャートである。図１６は、第１の移動処理の中で行われる応答判断処理のフローチャートである。図１７は、移動エージェントによるメイン処理の中で行われる移動依頼受入れ判断処理のフローチャートである。図１８は、移動依頼受入れ判断処理の中で行われる第２の移動依頼処理のフローチャートである。
【００６０】
まず、図１２および図１３を参照して、移動エージェントによって生成され、移動交渉に使用される移動依頼通知について説明する。図１２に示すように、移動依頼通知には、端末ＩＤ欄７３およびデータ欄７４が設けられている。端末ＩＤ欄７３には、移動通知の発信元のユーザ端末２０が付加する端末ＩＤである「ＩＤ＿Ｘ」が記憶されている。データ欄７４には、依頼内容のデータが記憶されている。例えば、最初に、端末ＩＤが「ＩＤ＿２０１」のユーザ端末２１の移動エージェントが、「２００７年３月５日１４時００分〜１５時００分」に登録された登録イベントの移動を依頼すると想定する。この場合、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」というテキストデータがそれぞれ記憶された移動依頼通知が生成されることになる。そして、詳細は後述するが、移動依頼通知が一旦送信されると、その移動依頼通知を受けたユーザ端末２０が、自己の登録イベントを移動させるために、他のユーザ端末２０にも派生的に登録イベントの移動を依頼しなければならなくなる場合がある。なお、以下の説明では、このような派生的な移動の依頼に用いられる移動依頼通知を「派生移動依頼通知」というものとする。派生移動依頼通知を送信する場合、移動エージェントは、自己が受信した移動依頼通知の端末ＩＤ欄７３に自己の端末ＩＤを付加し、さらにデータ欄７４に記憶されたデータを自己の依頼内容のデータに書き換えて転送する。例えば、端末ＩＤが「ＩＤ＿２０３」のユーザ端末２３が前述の例の移動依頼通知を受信し、さらに他のユーザ端末２０に対して「２００７年３月５日１７時００分〜１７時３０分」の登録イベントを「２００７年３月５日１０時００分〜１０時３０分」に移動させるように依頼する場合を想定する。この場合、図１３のように、派生移動依頼通知の端末ＩＤ欄７３には、元の移動依頼通知に含まれていた第１の端末ＩＤ７３１として「ＩＤ＿２０１」が記憶され、その後に、新たに第２の端末ＩＤ７３２として「ＩＤ＿２０３」が追加で記憶される。さらに、データ欄７４は「２００７年３月５日１７時００分〜１７時３０分に登録された登録イベントを、２００７年３月５日１０時００分〜１０時３０分に移動してください。」に書き換えられる。このような構成とすることにより、移動依頼通知に含まれる端末ＩＤ（ＩＤ＿Ｘ）によって、移動依頼通知が派生的に次々に転送され、伝播していった場合でも、その伝播過程にあったユーザ端末２０をすべて特定することができる。
【００６１】
管理エージェントにより移動エージェントが起動され（図６、Ｓ３４または図７、Ｓ４３）、図１４に示すメイン処理が開始されると、移動エージェントは、管理エージェントからの移動交渉開始指示（図６、Ｓ３５または図７、Ｓ４６）があるまで待機する（Ｓ２０１：ＮＯ→Ｓ２０１）。交渉開始指示があったと判断すると（Ｓ２０１：ＹＥＳ）、移動エージェントは、移動交渉の開始が自ユーザから（ユーザ端末２１において）依頼されたものか否かを判断する（Ｓ２０２）。具体的には、交渉エージェントと同様に、交渉開始指示として管理エージェントから渡される引数の相違によって判断する。渡された引数が自ユーザからの交渉依頼に対応するものである場合には（Ｓ２０２：ＹＥＳ）、移動エージェントは、第１の移動依頼処理を行う（Ｓ２３０）。
【００６２】
ここで、図１５および図１６を参照して、第１の移動処理（Ｓ２３０）の詳細について説明する。図１５に示す第１の移動処理が開始されると、移動エージェントはまず、ＲＡＭ２３０の新規イベント情報記憶エリア２３１に記憶されている新規イベント情報を読み出す（Ｓ２２１）。そして、自ユーザ２１が登録を希望している新規イベントの日時を「移動対象日時」として設定し、ＲＡＭ２３０の移動対象日時記憶エリア２３９に記憶させる（Ｓ２２２）。移動エージェントは、後述するように、この移動対象日時にすでに登録された登録イベントがある参加者端末２０に対して、その登録イベントの移動を依頼することになる。移動エージェントは、前述した交渉エージェントによる空き確認処理（図１０参照）の場合と同様に、新規イベント情報に「開始日時」が含まれていれば、記憶された日時に「所要時間」を加算した時間帯を、移動対象日時として設定する。一方、「開始日時」として、特定の日時が記憶されていない場合には、「開催猶予期間」の始期に「所要時間」を加算した時間帯を、移動対象日時として設定する。また、「開始日時」および「開催猶予期間」がいずれも記憶されている場合には、「開始日時」が優先される。
【００６３】
移動対象日時が設定されると（Ｓ２２２）、移動エージェントは、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、ハードディスク装置２５０のスケジュールＤＢ記憶エリア２５６（図３参照）に記憶されたスケジュールＤＢから、移動対象日時の自ユーザのスケジュール情報を読み出すように指示する（Ｓ２２３）。そして、指示を受けたスケジュール管理エージェントにより、移動対象日時のスケジュール情報が読み出され、ＲＡＭ２３０のスケジュール情報記憶エリア２３４（図４参照）に取得される（Ｓ２２４）。移動エージェントは、このスケジュール情報を参照して、移動対象日時に自ユーザのスケジュールが空いているか否かを判断する（Ｓ２２６）。スケジュール情報記憶エリア２３４に記憶されているのが「Ｎｕｌｌ」でなければ、移動対象日時には自ユーザのスケジュールは空いていない（Ｓ２２６：ＮＯ）。そこで移動エージェントは、交渉エージェントによる空き確認処理（図１０参照）の場合と同様に、開催猶予期間内の他の時間帯に移動対象日時をずらせるか否かを判断する（Ｓ２４１）。ずらせると判断した場合（Ｓ２４１：ＹＥＳ）、開催猶予期間内で最も早い時間帯を、新たに移動対象日時として設定し、移動対象日時記憶エリア２３９に上書きする（Ｓ２２２）。そして、前述のようにＳ２２３〜Ｓ２２６の処理を行う。新たに設定された移動対象日時でも自ユーザのスケジュールが空いていない場合には（Ｓ２２６：ＮＯ）、開催猶予期間内で移動対象日時をずらせる間は（Ｓ２４１：ＹＥＳ）、同様の処理を繰り返す。そして、開催猶予期間内で移動対象日時をずらせなくなると（Ｓ２４１：ＮＯ）、移動エージェントは、入力された条件では新規イベントの登録は不可能であると決定し（Ｓ２４２）、ディスプレイ２６３にその旨を表示させて自ユーザに通知する（Ｓ２４３）。そして、移動エージェント同士の移動交渉を終了するために、参加者端末２０の移動エージェントに処理の終了を指示してから（Ｓ２４４）、図１４のメイン処理に戻る。
【００６４】
一方、最初または何度目かの処理でＳ２２２において設定された移動対象日時に自ユーザのスケジュールが空いていると判断されると（Ｓ２２６：ＹＥＳ）、移動エージェントは次に、空き確認応答記憶エリア２３７（図３参照）を参照して、移動対象者を特定する（Ｓ２２７）。前述したように、空き確認応答記憶エリア２３７には、空き確認処理（図１０参照）で受信した参加者端末２０からの応答が、空き確認日時、応答発信元の参加者端末２０の識別コードとともに記憶されている。そこで移動エージェントは、移動対象日時と一致する空き確認日時に、スケジュールが空いていない（ＮＧ）との応答をした参加者端末２０を、移動対象者端末２０として特定する（Ｓ２２７）。次に、移動エージェントは、通信装置１７０を介してＬＡＮ２に接続し、管理サーバ１０のハードディスク装置１５０にアクセスする。そして、個人情報ＤＢ記憶エリア１５１（図２参照）に記憶されている個人情報ＤＢから、特定された移動対象者端末２０の情報を読み出し、ＲＡＭ２３０の移動対象者情報記憶エリア２４０に記憶させる（Ｓ２２８）。具体的には、移動対象者端末２０と通信を行うための移動対象者端末２０のＩＰアドレス、識別コード等が取得される。
【００６５】
その後、移動エージェントは、移動対象日時の登録イベントの移動を依頼するために、移動対象者端末２０の管理エージェントに対して、移動エージェントの起動を依頼する（Ｓ２２９）。そして、全移動対象者端末２０の管理エージェントから、移動エージェントの起動完了通知があったか否かを確認する（Ｓ２３１）。いずれかの移動対象者端末２０の管理エージェントから、移動エージェントが起動できたという応答がない場合は（Ｓ２３１：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ２３２）。通信エラーで応答が完了しない場合には（Ｓ２３２：ＹＥＳ）、管理エージェントにエラー報告をしてから（Ｓ２３３）、図１４のメイン処理に戻って、処理を終了する。通信エラーでない場合は（Ｓ２３２：ＮＯ）、Ｓ２３１に戻り、全移動対象者端末２０で移動エージェントの起動が完了するまで待機する（Ｓ２３１：ＮＯ→Ｓ２３２：ＮＯ→Ｓ２３１）。
【００６６】
全移動対象者端末２０の管理エージェントから、移動エージェントの起動完了通知を受信した場合には（Ｓ２３１：ＹＥＳ）、移動エージェントは、自ユーザ端末２１の端末ＩＤおよび移動依頼内容のテキストデータを含む移動依頼通知を生成する（Ｓ２３６）。ここで生成される移動依頼通知は初回のものである。したがって、例えば、前述した図１２の移動依頼通知のように、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「移動対象日時（例えば、２００７年３月５日１４時００分〜１５時００分）に登録された登録イベントを、他の日時に移動してください。」がそれぞれ記憶された移動依頼通知が生成されることになる。そして、移動エージェントは、生成した移動依頼通知を移動対象者端末２０に送信する（Ｓ２３７）。その後は、移動対象者端末２０からの応答判断処理（Ｓ２５０）に進む。
【００６７】
ここで、図１６を参照して、応答判断処理（Ｓ２５０）の詳細について説明する。図１６に示す処理が開始されると、移動エージェントはまず、移動依頼通知の発信先である移動対象者端末２０からの応答があるまで待機する（Ｓ２５１：ＮＯ→Ｓ２５１）。そして、応答を受信すると（Ｓ２５１：ＹＥＳ）、受信した応答を、応答の発信元の移動対象者端末２０の端末ＩＤとともに、ＲＡＭ２３０の移動可否応答記憶エリア２４２（図４参照）に記憶させる（Ｓ２５２）。その後、移動エージェントは、全移動対象者端末２０の管理エージェントから、応答があったか否かを判断する（Ｓ２５３）。全移動対象者端末２０の管理エージェントからの応答受信が完了していない場合は（Ｓ２５３：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ２５４）。通信エラーで受信が完了しない場合には（Ｓ２５４：ＹＥＳ）、管理エージェントにエラー報告をしてから（Ｓ２６３）、図１５の第１の移動処理に戻り、さらに図１４のメイン処理に戻って処理を終了する。通信エラーでない場合は（Ｓ２５４：ＮＯ）、Ｓ２５１に戻り、全移動対象者端末２０からの応答が完了するまで、応答を受信して移動可否応答記憶エリア２４２に記憶させる（Ｓ２５１：ＹＥＳ→Ｓ２５２）処理を繰り返す。全移動対象者端末２０からの応答を受信したら（Ｓ２５３：ＹＥＳ）、移動エージェントは、移動可否応答記憶エリア２４２に記憶された応答を参照して、移動対象者端末２０からの応答がすべて移動可能（ＯＫ）との応答であるか否かを判断する（Ｓ２５６）。すべてＯＫの応答であれば（Ｓ２５６：ＹＥＳ）、移動エージェントは、移動対象者端末２０に対して、移動対象日時にある登録イベントの移動を決定し、ハードディスク装置２５０に記憶されたスケジュールＤＢ（図３参照）に登録するように指示する（Ｓ２５７）。また、移動が決定されたので、ここで、図１５のＳ２２２で設定された移動対象日時に新規イベントを登録することが決定される（Ｓ２５８）。このとき、移動エージェントは、新規イベント情報記憶エリア２３１に記憶されている新規イベント情報の「開始日時」を移動対象日時記憶エリア２３９に記憶されている移動対象日時の開始日時に変更して、変更した情報を、決定イベント情報として決定イベント情報記憶エリア２４５（図４参照）に記憶させる。また、移動エージェントは、新規イベントの全参加者の参加者端末２０に対して、登録が決定した新規イベントを登録させるために、自ユーザ端末２１の管理エージェントに対して、新規イベントの参加者の参加者端末２０への登録指示を依頼する（Ｓ２６１）。さらに、移動エージェントは、自ユーザ端末２１のスケジュール管理エージェントに、決定イベント情報記憶エリア２４５に記憶されている決定イベント情報を、新規イベントとしてハードディスク装置２５０に記憶されているスケジュールＤＢに登録するよう指示してから（Ｓ２６５）、図１５の第１の移動依頼処理に戻り、さらに図１４のメイン処理に戻って処理を終了する。
【００６８】
一方、Ｓ２５６において、移動可否応答記憶エリア２４２に、１つでも移動不可能（ＮＧ）との応答が記憶されていた場合には（Ｓ２５６：ＮＯ）、図１５のＳ２４１に戻り、新規イベント情報記憶エリア２３１（図４参照）を参照して、開催猶予期間内の他の時間帯に移動対象日時をずらせるか判断する。ずらせると判断した場合（Ｓ２４１：ＹＥＳ）、開催猶予期間内で最も早い時間帯を、新たに移動対象日時として設定し、移動対象日時記憶エリア２３９に上書きする（Ｓ２２２）。そして、前述のようにＳ２２３〜Ｓ２５０の処理を行う。新たに設定された移動対象日時に自ユーザのスケジュールが空いていない場合や（Ｓ２４１：ＮＯ）、全参加者端末２０からＯＫの応答が得られない場合には（図１６、Ｓ２５６：ＮＯ）、開催猶予期間内で移動対象日時をずらせる間は（Ｓ２４１：ＹＥＳ）、同様の処理を繰り返す。そして、開催猶予期間内で移動対象日時をずらせなくなると（Ｓ２４１：ＮＯ）、移動エージェントは、入力された条件では新規イベントの登録は不可能であると決定し（Ｓ２４２）、ディスプレイ２６３にその旨を表示させて自ユーザに通知する（Ｓ２４３）。そして、移動エージェント同士の移動交渉を終了するために、参加者端末２０の移動エージェントに処理の終了を指示してから（Ｓ２４４）、図１４のメイン処理に戻って処理を終了する。
【００６９】
一方、開催猶予期間内で移動対象日時をずらした結果、最終的に全移動対象者端末２０からＯＫの応答が得られれば（図１６、Ｓ２５６：ＹＥＳ）、移動エージェントは、前述のように、移動対象者端末２０に移動の決定指示を通知し（Ｓ２５７）、新規イベントの登録を決定する（Ｓ２５８）。その後、移動エージェントは、他の参加者端末２０に新規イベントの登録指示を出すよう管理エージェントに依頼し（Ｓ２６１）、スケジュール管理エージェントに新規イベントをスケジュールＤＢに登録するように指示してから（Ｓ２６５）、図１５の第１の移動依頼処理に戻り、さらに図１４のメイン処理に戻って処理を終了する。
【００７０】
図１４の移動エージェントによるメイン処理において、交渉開始の指示が自ユーザからのものではなかった場合には（Ｓ２０１：ＹＥＳ→Ｓ２０２：ＮＯ）、移動エージェントは、他のユーザ端末２０から、移動依頼があったか否かを判断する（Ｓ２０９）。具体的には、他のユーザ端末２０から、前述の移動依頼通知を受信した場合に、移動依頼があったと判断され（Ｓ２０９：ＹＥＳ）、移動依頼受入れ判断処理に進む（Ｓ２７０）。
【００７１】
ここで、図１７および図１８を参照して、移動依頼受入れ判断処理（Ｓ２７０）について説明する。図１７の移動依頼受入れ処理が開始されると、移動エージェントはまず、受信した移動依頼通知をＲＡＭ２３０の移動依頼情報記憶エリア２４３（図４参照）に取得して記憶させる（Ｓ２７１）。そして、取得した移動依頼通知に、自己の端末ＩＤが含まれているか否かを判断する（Ｓ２７２）。前述したように、移動依頼通知（図１３参照）の端末ＩＤ欄７３には、移動依頼通知を最初に発信したユーザ端末２０の端末ＩＤと、その後、この移動依頼通知に派生して発信された派生移動依頼通知がある場合には、その発信者のユーザ端末２０の端末ＩＤとが含まれている。したがって、移動依頼通知に自己の端末ＩＤ（ユーザ端末２１の場合は「ＩＤ＿２０１」）が含まれている場合（Ｓ２７２：ＹＥＳ）、自己が発信した移動依頼が伝播して、自ユーザの登録イベントを移動させる依頼となって戻ってきたことを意味する。そこで移動エージェントは、この場合、移動依頼がループ状に伝播するのを回避するために、移動依頼の発信元のユーザ端末２０に、移動対象日時にすでに登録されている登録イベントの移動は不可能（ＮＧ）の回答を送信し（Ｓ２７３）、図１４のメイン処理に戻る。
【００７２】
一方、移動依頼情報記憶エリア２４３に記憶された移動依頼通知に、自己の端末ＩＤが含まれていない場合には（Ｓ２７２：ＮＯ）、移動エージェントは、移動依頼通知に移動先日時が特定されているか否かを判断する（Ｓ２７５）。前述したように、移動依頼通知が最初に発信されるのは、交渉エージェントによる空き確認処理（図１０参照）の結果、開催猶予期間内で全参加者に共通の空きがない場合である。よって、最初の移動依頼では、例えば、「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」というように、単に、新規イベントの開催希望日時である移動対象日時に登録された登録イベントを、他の任意の日時に移動するように求められる。しかし、この移動依頼を受けたユーザ２００が、派生移動依頼通知によって登録イベントを移動させる場合は、この登録イベントの参加者にも、この登録イベントを同じ日時に移動させてもらわねばならない。したがって、例えば、「２００７年３月５日１６時００分〜１７時００分に登録された登録イベントを、２００７年３月５日１０時００分〜１０時３０分に移動してください。」というように、自己の都合のよい特定の移動先日時を指定して、同時に移動するように依頼することになる。すなわち、最初に発信された移動依頼通知には移動先日時は含まれていないが、派生移動依頼通知には移動先日時が含まれている。移動エージェントは、移動依頼通知に移動先日時が含まれていると判断した場合（Ｓ２７５：ＹＥＳ）、自ユーザ端末２１のスケジュール管理エージェントに、ハードディスク装置２５０（図３参照）に記憶されたスケジュールＤＢから、移動先日時のスケジュール情報を読み出すように指示する（Ｓ２７６）。そして、ＲＡＭ２３０のスケジュール情報記憶エリア２３４（図４参照）に、読み出された移動先日時のスケジュール情報が取得されると（Ｓ２７７）、移動エージェントは、移動先日時にすでに登録された登録イベントがあるか否かを判断する（Ｓ２７８）。スケジュール情報記憶エリア２３４に「Ｎｕｌｌ」が記憶されている場合は、登録イベントはない（Ｓ２７８：ＮＯ）。したがって、移動エージェントは、移動対象日時に登録されていた登録イベントを移動先日時に移動できると判断し、移動可能（ＯＫ）の回答を移動依頼の発信元のユーザ端末２０に発信し（Ｓ２８０）、図１４のメイン処理に戻る。
【００７３】
Ｓ２７７で取得されたスケジュール情報から、移動依頼通知に含まれる移動先日時に、すでに登録されている別の登録イベントがある場合（Ｓ２７８：ＹＥＳ）、この別の登録イベントを他の日時に移動させなければ、移動依頼通知によって依頼された登録イベントの移動を行うことができない。そこで、移動エージェントは、移動先日時の登録イベントをさらに移動させるべく、移動対象イベントとして特定し、移動対象イベントのスケジュール情報を、ＲＡＭ２３０の移動対象イベント情報記憶エリア２４６に記憶させる（Ｓ２８１）。このときスケジュール情報として取得される情報には、移動対象イベントの「タイトル」、「日時」、「開催猶予期間」、「所要時間」、「場所」、「参加者」等が含まれている。その後、移動エージェントは、管理サーバ１０のハードディスク装置１５０（図２参照）に記憶されている個人情報ＤＢにアクセスする。そして、移動対象イベントのスケジュール情報に含まれる参加者の参加者端末２０のＩＰアドレス、参加者端末２０の識別コード、参加者の識別コード等を取得し、ＲＡＭ２３０の移動対象者情報記憶エリア２４０に記憶させる（Ｓ２８７）。そして、取得した情報を基に、移動対象イベントの参加者端末２０の管理エージェントに対して、参加者端末２０の移動エージェントを起動するように依頼し（Ｓ２８８）、第２の移動処理に進む（Ｓ３００）。
【００７４】
また、Ｓ２７５において、移動依頼通知に移動先日時が含まれていないと判断された場合には（Ｓ２７５：ＮＯ）、移動依頼日時にすでに登録されている登録イベントを、まだ特定されていない他の日時に移動させることになる。そこで移動エージェントは、自ユーザ端末２１のスケジュール管理エージェントに、ハードディスク装置２５０に記憶されたスケジュールＤＢから、移動依頼通知に含まれる移動依頼日時のスケジュール情報を読み出すように指示し（Ｓ２８３）、ＲＡＭ２３０のスケジュール情報記憶エリア２３４に、移動依頼日時のスケジュール情報を取得する（Ｓ２８４）。そして、取得された登録イベントのスケジュール情報を、移動対象イベント情報として、ＲＡＭ２３０の移動対象イベント情報記憶エリア２４６に記憶させる（Ｓ２８５）。その後、移動エージェントは、管理サーバ１０の個人情報ＤＢから、移動対象イベントのスケジュール情報に含まれる参加者の参加者端末２０のＩＰアドレス、参加者端末２０の識別コード、参加者の識別コード等を取得する（Ｓ２８７）。そして、取得した情報を基に、参加者端末２０の管理エージェントに対して、参加者端末２０の移動エージェントを起動するように依頼し（Ｓ２８８）、第２の移動処理に進む（Ｓ３００）。
【００７５】
ここで、図１８を参照して、第２の移動依頼処理（Ｓ３００）の詳細について説明する。図１８に示す処理が開始されると、移動エージェントはまず、参加者端末２０のすべてで移動エージェントの起動が完了したか否かを確認する（Ｓ３０１）。いずれかの参加者端末２０の管理エージェントから、移動エージェントが起動できたという応答がない場合は（Ｓ３０１：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ３０２）。通信エラーで応答が完了しない場合には（Ｓ３０２：ＹＥＳ）、移動対象イベントの参加者端末２０への移動の可否確認が不可能なので、自己が受信した移動依頼通知の発信元のユーザ端末２０に移動不可能（ＮＧ）の回答をしてから（Ｓ３２１）、図１７の移動依頼受入れ判断処理に戻り、さらに、図１４のメイン処理に戻る。通信エラーでない場合は（Ｓ３０２：ＮＯ）、Ｓ３０１に戻り、全参加者端末２０で移動エージェントの起動が完了するまで待機する（Ｓ３０１：ＮＯ→Ｓ３０２：ＮＯ→Ｓ３０１）。
【００７６】
全移動対象者端末２０の管理エージェントから、移動エージェントの起動完了通知を受信した場合には（Ｓ３０１：ＹＥＳ）、移動対象イベント情報記憶エリア２４６に記憶された「開催猶予期間」および「所要時間」を参照して、移動対象イベントを移動させられる最も早い時間帯を移動先日時として設定し、ＲＡＭ２３０の移動先日時記憶エリア２４１に記憶させる（Ｓ３０３）。具体的には、移動対象イベントの「開催猶予期間（ただし、移動対象イベントがすでに登録されている日時は除く）」の開始日時に「所要時間」を加算した時間帯が、移動先日時として設定される。すなわち、例えば、「開催猶予期間」として「２００７年３月５日０９時００分〜２００７年３月５日１８時００分」が記憶され、「所要時間」として「１時間」が記憶されていれば、「２００７年３月５日０９時００分〜１０時００分」が移動先日時として設定される。移動先日時を設定すると（Ｓ３０３）、移動エージェントは、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、ハードディスク装置２５０に記憶されたスケジュールＤＢから、移動先日時のスケジュール情報を読み出すように指示する（Ｓ３０５）。そして、ＲＡＭ２３０のスケジュール情報記憶エリア２３４（図３参照）に、読み出された移動先日時のスケジュール情報が取得されると（Ｓ３０６）、移動エージェントは、移動先日時に自ユーザのスケジュールが空いているか否かを判断する（Ｓ３０７）。スケジュール情報記憶エリア２３４に何らかのスケジュール情報が記憶されていれば、すでに別の登録イベントがあるので（Ｓ３０７：ＮＯ）、移動エージェントは、開催猶予期間内の他の時間帯に移動先日時をずらせるか否かを判断する（Ｓ３２２）。ずらせると判断した場合（Ｓ３２２：ＹＥＳ）、開催猶予期間内で最も早い別の時間帯を、新たに移動先日時として設定し、移動先日時記憶エリア２４１に上書きする（Ｓ３０３）。そして、前述のようにＳ３０５〜Ｓ３０７の処理を行う。新たに設定された移動先日時でも、自ユーザのスケジュールが空いていない場合には（Ｓ３０７：ＮＯ）、開催猶予期間内で移動先日時をずらせる間は（Ｓ３２２：ＹＥＳ）、同様の処理を繰り返す。そして、開催猶予期間内で移動先日時をずらせなくなると（Ｓ３２２：ＮＯ）、移動エージェントは、自己が受信した移動依頼通知の発信元のユーザ端末２０に、移動対象イベントは移動不可能（ＮＧ）の回答を送信する（Ｓ３２３）。その後、図１７の移動依頼受入れ判断処理に戻り、さらに、図１４のメイン処理に戻る。
【００７７】
一方、最初または何度目かの処理でＳ３０３において設定された移動先日時に自ユーザのスケジュールが空いていると判断されると（Ｓ３０７：ＹＥＳ）、移動エージェントは次に、移動依頼通知を生成する（Ｓ３０８）。ここで生成される移動通知は、他のユーザ端末２０からの移動依頼通知から派生的に移動を依頼するものなので、移動エージェントは、移動依頼通知（図１２参照）のデータ欄７４に記憶されたデータを自己の依頼内容のデータ、例えば、「２００７年３月５日１７時００分〜１７時３０分に登録された登録イベントを、２００７年３月５日１０時００分〜１０時３０分に移動してください。」に書き換える。そして、移動依頼通知の端末ＩＤ欄７３に、端末ＩＤ記憶エリア２３３に記憶された自己の端末ＩＤを追加する。例えば、ユーザ端末２１からの移動依頼通知を受けたユーザ端末２３では、図１３のような派生移動依頼通知が生成される。そして、生成された派生移動依頼通知を、移動対象イベント情報記憶エリア２４６（図３参照）に記憶されている移動対象イベントの参加者の参加者端末２０に対して送信する（Ｓ３０９）。その後、移動エージェントは、参加者端末２０からの応答があるまで待機し（Ｓ３１１：ＮＯ→Ｓ３１１）、応答を受信すると（Ｓ３１１：ＹＥＳ）、応答の発信元の参加者端末２０の端末ＩＤおよび応答内容をＲＡＭ２３０の移動可否応答記憶エリア２４２に記憶させる（Ｓ３１２）。そして、移動エージェントは、移動可否応答記憶エリア２４２と移動対象者情報記憶エリア２４０にそれぞれ記憶された端末ＩＤを対比して、すべての参加者端末２０から応答があったか否かを判断する（Ｓ３１３）。いずれかの参加者端末２０からの応答がない場合は（Ｓ３１３：ＮＯ）、通信エラーが生じたか否かを確認する（Ｓ３１４）。通信エラーで応答が完了しない場合には（Ｓ３１４：ＹＥＳ）、参加者端末２０への移動の可否確認が不可能なので、元の移動依頼通知の発信元のユーザ端末２０に移動不可能（ＮＧ）の回答をしてから（Ｓ３２１）、図１７の移動依頼受入れ判断処理に戻り、さらに、図１４のメイン処理に戻る。通信エラーでない場合は（Ｓ３１４：ＮＯ）、Ｓ３１１に戻り、全参加者端末２０から応答があるまで、Ｓ３１１〜Ｓ３１４の処理を繰り返す。
【００７８】
全参加者端末２０からの応答を受信すると（Ｓ３１３：ＹＥＳ）、移動エージェントは、移動可否応答記憶エリア２４２に記憶された応答を読み出し、全参加者端末２０から移動可能（ＯＫ）の応答を得たか否かを判断する（Ｓ３１６）。いずれかの参加者端末２０から、移動不可能（ＮＧ）の応答があった場合には（Ｓ３１６：ＮＯ）、開催猶予期間内の他の時間帯に移動先日時をずらせるか判断する（Ｓ３２２）。ずらせると判断した場合（Ｓ３２２：ＹＥＳ）、開催猶予期間内で最も早い別の時間帯を、新たに移動先日時として設定し、移動先日時記憶エリア２４１に上書きする（Ｓ３０３）。そして、前述のようにＳ３０５〜Ｓ３１６の処理を行う。新たに設定された移動先日時でも、自ユーザのスケジュールが空いていない場合や（Ｓ３０７：ＮＯ）、全参加者端末２０からＯＫの応答が得られない場合には（Ｓ３１６：ＮＯ）、開催猶予期間内で移動先日時をずらせる間は（Ｓ３２２：ＹＥＳ）、同様の処理を繰り返す。そして、開催猶予期間内で移動先日時をずらせなくなると（Ｓ３２２：ＮＯ）、移動エージェントは、自己が受信した移動依頼通知の発信元のユーザ端末２０に、移動対象イベントは移動不可能（ＮＧ）の回答を送信する（Ｓ３２３）。その後、図１７の移動依頼受入れ判断処理に戻り、さらに、図１４のメイン処理に戻る。一方、最初または何度目かの処理のＳ３１６において、全参加者端末２０から移動可能（ＯＫ）の応答を得られた場合には（Ｓ３１６：ＹＥＳ）、このとき移動先日時記憶エリア２４１に記憶されている移動先日時を仮決定移動先日時として、仮決定移動先日時記憶エリア２４４に記憶させる（３１７）。なお、ここで移動先日時を一旦仮決定するのは、後に自己が受信した元の移動依頼通知の発信元のユーザ端末２０から移動の正式決定指示を受けたときに、自己が送信した派生移動依頼通知の送信先の参加者端末２０にも、移動の決定指示をするためである。その後、移動エージェントは、自己が受信した移動依頼通知の発信元のユーザ端末２０に、移動対象イベントは移動可能（ＯＫ）の回答を送信してから（Ｓ３１８）、図１７の移動依頼受入れ判断処理に戻り、さらに、図１４のメイン処理に戻る。図１４に示すように、移動依頼受入れ判断処理（Ｓ２７０）が終了してメイン処理に戻った後は、いずれの場合も、再び他のユーザ端末２０から移動依頼があったか否かの判断に戻る（Ｓ２０９）。
【００７９】
図１４の移動エージェントによるメイン処理において、交渉開始の指示が他のユーザ端末２０からのものであり、その後、移動依頼がない場合には（Ｓ２０１：ＹＥＳ→Ｓ２０２：ＮＯ→Ｓ２０９：ＮＯ）、移動エージェントは、他のユーザ端末２０から、移動の決定指示を受信したか否かを判断する（Ｓ２１１）。なお、移動の決定指示は、前述の第１の移動依頼処理（Ｓ２３０）の応答判断処理（図１６参照）において、すべての移動対象者端末２０のＯＫが得られ、登録イベントの移動が決定されたときに送信される（図１６、Ｓ２５７）。これを受信した場合（Ｓ２１１：ＹＥＳ）、移動エージェントは、ＲＡＭ２３０の仮決定移動先日時記憶エリア２４４を参照して、ここに記憶されている仮決定移動先日時があるか否かを判断する（Ｓ２１２）。前述したように、仮決定移動先日時記憶エリア２４４に仮決定移動先日時が記憶されているのは、自己が受信した移動依頼通知に従って自己の登録イベントを移動させるために、派生的に他のユーザ端末２０にも登録イベントの移動を依頼した結果、すべてから移動可能（ＯＫ）の応答を受けて移動先日時を仮決めした場合である。したがって、移動エージェントは、仮決定移動先日時記憶エリア２４４に記憶された仮決定移動先日時があれば（Ｓ２１２：ＹＥＳ）、派生移動依頼通知で依頼した移動対象イベントを仮決定移動先日時に移動すると決定する（Ｓ２１３）。そして、派生移動依頼通知の送信先である移動対象イベントの参加者の参加者端末２０にも、移動の決定指示を送信する（Ｓ２１４）。その後、移動エージェントは、自ユーザ端末２１のスケジュール管理エージェント（図８参照）に、移動が決定された登録イベントの移動の登録を指示して（Ｓ２１５）、図１４のメイン処理を終了する。一方、Ｓ２１２において、仮決定移動先日時が記憶されていないと判断された場合には（Ｓ２１２：ＮＯ）、自己がさらに他のユーザ端末２０に移動を指示する必要はない。よって、移動エージェントは、そのままスケジュール管理エージェントに移動の書込みを指示して（Ｓ２１５）、図１４のメイン処理を終了する。
【００８０】
図１４のメイン処理において、交渉開始の指示が自ユーザからのものではなく（Ｓ２０１：ＹＥＳ→Ｓ２０２：ＮＯ）、他のユーザ端末２０から、移動依頼も決定指示も受信していない場合には（Ｓ２０９：ＮＯ→２１１：ＮＯ）、移動エージェントは、他のユーザ端末２０から、終了の指示を受信したか否かを判断する（Ｓ２２１）。なお、終了指示は、前述の第１の移動依頼処理（Ｓ２３０）において、開催猶予期間内では、新規イベントの登録が不可能だと判断されたときに送信されるものである。よって、これを受けた場合（Ｓ２２１：ＹＥＳ）、移動エージェントは図１４のメイン処理を終了する。一方、終了指示も受けていない場合には（Ｓ２２１：ＮＯ）、移動エージェントは、移動依頼を受信したか否かの判断に戻る（Ｓ２０９）。
【００８１】
ここで、図１９の具体例において、以上に説明した本実施形態のスケジュール調整処理がどのように行われるかを説明する。図１９は、ユーザ端末２１〜２５におけるスケジュール調整処理の具体例の説明図である。なお、以下の説明では、ユーザ端末２１において、図５に示すように新規イベント情報が入力され、ユーザ端末２１〜２５の各ユーザ２０１〜２０５の「２００７年３月５日」の一日のスケジュールには、図１９に斜線等で示すように、登録イベントがすでに存在する場合を想定する。
【００８２】
まず、ユーザ端末２１において、図５のように新規イベント情報の入力が行われると、ユーザ端末２１の管理エージェントによって、交渉エージェントが起動され、新規イベントの参加者である２０２および２０３の利用するユーザ端末２２およびユーザ端末２３の交渉エージェントとの空き確認交渉が指示される（図６、Ｓ４：ＹＥＳ〜Ｓ１３）。すると、ユーザ端末２１では、交渉エージェントにより、図１０の空き確認処理が開始される。ユーザ端末２１の交渉エージェントは、図５の新規スケジュール入力画面５の「開始日時」欄５２で入力された開始日時に所要時間「１時間」を加算した時間帯である「２００７年３月５日１４時００分〜１５時００分」を空き確認日時として設定し（図１０、Ｓ１２２）、この日時にユーザ端末２１のユーザ２０１には登録イベントはないので（図１０、Ｓ１３１：ＹＥＳ）、空き確認依頼をユーザ端末２２および２３に発信する（図１０、Ｓ１３２）。一方、ユーザ端末２２およびユーザ端末２３では、図１１の空き判断処理が開始される。図１９に示すように、この日時には、ユーザ端末２２のユーザ２０２には登録イベントはないが（図１１、Ｓ１７６：ＹＥＳ）、ユーザ端末２３のユーザ２０３には登録イベント３０１がある（図１１、Ｓ１７６：ＮＯ）。したがって、ユーザ端末２２の交渉エージェントは、ユーザ端末２１に対してＯＫの応答を送信し（図１１、Ｓ１７８）、ユーザ端末２３の交渉エージェントは、ユーザ端末２１に対してＮＧの応答を送信する（図１１、Ｓ１７７）。ユーザ端末２３からＮＧの応答を受けた（図１０、Ｓ１４５：ＮＯ）ユーザ端末２１の交渉エージェントは、開催猶予期間内の「２００７年３月５日０９時００分〜２００７年３月５日１８時００分」で空き確認日時をずらせるので（Ｓ１６１：ＹＥＳ）、「２００７年３月５日０９時００分〜１０時００分」に設定する（図１０、Ｓ１２２）。しかし、この日時では、自ユーザ２０１のスケジュールが空いていないので（図１０、Ｓ１３１：ＮＯ）、順に１時間ずつ空き確認日時をずらし、自ユーザ２０１が空いている「２００７年３月５日１１時００分〜１２時００分」に設定して、再度空き確認依頼をユーザ端末２２および２３に発信する（図１０、Ｓ１６１：ＹＥＳ→Ｓ１２２→Ｓ１３１：ＹＥＳ→Ｓ１３２）。この空き確認依頼を受けたユーザ端末２２およびユーザ端末２３の交渉エージェントがスケジュールを確認すると、図１９に示すように、今度は、ユーザ端末２２のユーザ２０２のスケジュールが空いていない（図１１、Ｓ７６：ＮＯおよび図１０、Ｓ１４５：ＮＯ）。よって、ユーザ端末２１の交渉エージェントは、同様にして、空き確認日時を順にずらして空き確認を行うが、図１９に示すように、ユーザ２０１、２０２および２０３のすべてに共通する空きはないため、ユーザ端末２１では開催猶予期間内で空き確認日時をずらせなくなって、移動エージェントの起動が依頼される（図１０、Ｓ１６１：ＮＯ→Ｓ１６２）。
【００８３】
その後、ユーザ端末２１で移動エージェントが起動されると、図１５の第１の移動処理が開始される。ユーザ端末２１の移動エージェントは、移動対象日時として、図５の新規スケジュール入力画面５の「日時」欄５２で入力された日時である「２００７年３月５日１４時００分〜１５時００分」を設定する（Ｓ２２２）。図１９に示すように、この日時にユーザ２０１のスケジュールは空いているので（Ｓ２２６：ＹＥＳ）、ＲＡＭ２３０の空き確認応答記憶エリア２３７（図４参照）を参照して、移動依頼通知の送信先である移動対象者を特定する（Ｓ２２７）。具体的には、移動対象日時である「２００７年３月５日１４時００分〜１５時００分」を空き確認日時とした空き確認通知に対して、ＮＧの応答を返信したユーザ端末２０を特定する。この具体例では、前述のように、ユーザ端末２３からＮＧの応答が返信されているので、ユーザ端末２１の移動エージェントは、ユーザ端末２３を移動対象者として特定し（Ｓ２２７）、ユーザ端末２３で移動エージェントが起動されると（Ｓ２３１：ＹＥＳ）、移動依頼通知を生成する（Ｓ２３６）。具体的には、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」というテキストデータがそれぞれ記憶された移動依頼通知（図１２参照）が生成され、ユーザ端末２３に送信される（Ｓ２３７）。
【００８４】
ユーザ端末２１の移動エージェントからの依頼を受けたユーザ端末２３の管理エージェントによって、移動エージェントが起動され、ユーザ端末２１からの移動依頼通知を受信すると（図１４、Ｓ２０９：ＹＥＳ）、ユーザ端末２３では、図１７の移動依頼受入れ判断処理が開始される。ユーザ端末２３の移動エージェントは、受信した移動依頼通知の端末ＩＤ欄７３には自己の端末ＩＤである「ＩＤ＿２０３」は含まれていないので（Ｓ２７２：ＮＯ）、データ欄７４の依頼内容のデータを確認する。前述のように、ユーザ端末２３が受信した移動依頼通知は初回のものなので、依頼内容には、登録イベントの移動先日時は含まれていない（Ｓ２７５：ＮＯ）。したがって、ユーザ端末２３の移動エージェントは、移動依頼通知に含まれる移動対象日時である「２００７年３月５日１４時００分〜１５時００分」のスケジュール情報を取得して、この日時に登録されている登録イベント３０１を移動対象イベントとして特定する（Ｓ２８３〜Ｓ２８５）。なお、登録イベント３０１のスケジュール情報には、「開催猶予期間」として「２００７年３月５日１４時００分〜１８時００分」が、「所要時間」として「１時間」が、「参加者」として「２０４、２０５」がそれぞれ含まれているものとする。そこで、ユーザ端末２３の移動エージェントは、参加者２０４および２０５の利用するユーザ端末２４および２５に対して移動エージェントの起動を依頼し（Ｓ２８８）、第２の移動依頼処理（Ｓ３００、図１８）に移る。
【００８５】
図１８の処理に移り、ユーザ端末２４および２５で移動エージェントの起動が完了すると（Ｓ３０１：ＹＥＳ）、ユーザ端末２３の移動エージェントは、移動対象イベントである登録イベント３０１の移動先日時を設定する（Ｓ３０３）。この場合、登録イベント３０１の開催猶予期間である「２００７年３月５日１４時００分〜１８時００分」から登録イベント３０１が登録されている日時である「２００７年３月５日１４時００分〜１５時００分」を除いた期間で最も早い時間帯を選択する。すなわち、「２００７年３月５日１５時００分〜１６時００分」を移動先日時として設定するが（Ｓ３０３）、図１９に示すように、ユーザ２０３のスケジュールには、「２００７年３月５日１５時３０分〜１６時３０分」に登録イベント３０２がある（Ｓ３０７：ＮＯ）。したがって、ユーザ端末２３の移動エージェントは、まだ移動先日時をずらせるので（Ｓ３２２：ＹＥＳ）、次に「２００７年３月５日１７時００分〜１８時００分」を移動先日時として設定しなおす（Ｓ３０３）。この場合は、図１９に示すように、ユーザ２０３には登録イベントはないので（Ｓ３０７：ＹＥＳ）、ユーザ端末２３がユーザ端末２１から受信した移動依頼通知を基にした派生移動依頼通知を生成する（Ｓ３０８）。すなわち、端末ＩＤ欄７３において、ユーザ端末２１の「ＩＤ＿２０１」の後に、新たにユーザ端末２３の「ＩＤ＿２０３」が追加され、さらに、データ欄７４が「２００７年３月５日１４時００分〜１５時００分に登録された登録イベント３０１を、２００７年３月５日１７時００分〜１８時００分に移動してください。」というテキストデータに書き換えられる。その後、ユーザ端末２３の移動エージェントは、生成した派生移動依頼通知を、ユーザ端末２４および２５に送信する（Ｓ３０９）。
【００８６】
一方、ユーザ端末２４および２５でも移動エージェントが起動され、ユーザ端末２３からの派生移動依頼通知を受信すると（図１４、Ｓ２０９：ＹＥＳ）、ユーザ端末２４および２５でも、図１７の移動依頼受入れ判断処理が開始される。ユーザ端末２４の移動エージェントは、受信した移動依頼通知の端末ＩＤ欄７３には「ＩＤ＿２０１」および「ＩＤ＿２０３」は含まれているが、自己の端末ＩＤである「ＩＤ＿２０４」は含まれていないので（Ｓ２７２：ＮＯ）、データ欄７４の依頼内容のデータを確認する。ユーザ端末２４が受信したのは「２００７年３月５日１４時００分〜１５時００分に登録された登録イベント３０１を、２００７年３月５日１７時００分〜１８時００分に移動してください。」という派生移動依頼通知なので、移動先日時として「２００７年３月５日１７時００分〜１８時００分」が含まれている（Ｓ２７５：ＹＥＳ）。したがって、ユーザ端末２４の移動エージェントは、移動先日時である「２００７年３月５日１７時００分〜１８時００分」のスケジュールを確認すると、この日時に登録イベントはない（Ｓ２７８：ＮＯ）。したがって、ユーザ端末２４の移動エージェントは、ユーザ端末２３に対して、登録イベント３０１は移動可能（ＯＫ）の応答を送信する（Ｓ２８０）。一方、ユーザ端末２５の移動エージェントも同様の処理を行う。ユーザ端末２５では、ユーザ端末２４と同様に、自己の端末ＩＤは含まれていないと判断されるが（Ｓ２７２：ＮＯ）、移動先日時の「２００７年３月５日１７時００分〜１８時００分」のスケジュール情報を取得すると、この日時にかかる「２００７年３月５日１７時００分〜１７時３０分」にすでに登録されている登録イベント３０３がある（Ｓ２７７→Ｓ２７８：ＮＯ）。したがって、ユーザ端末２５では、登録イベント３０３をさらに移動させるべく、移動先日時にかかる登録イベント３０３を移動対象イベントとして特定する（Ｓ３０２）。なお、登録イベント３０３のスケジュール情報には、「開催猶予期間」として「２００７年３月５日１０時００分〜１８時００分」が、「所要時間」として「３０分」が、「参加者」として「２０１」がそれぞれ含まれているものとする。そこで、ユーザ端末２５の移動エージェントは、参加者２０１の利用するユーザ端末２１に対して移動エージェントの起動を依頼し（Ｓ２８８）、第２の移動依頼処理（Ｓ３００、図１８）に移る。
【００８７】
図１８の処理に移り、ユーザ端末２１で移動エージェントの起動が完了すると（Ｓ３０１：ＹＥＳ）、ユーザ端末２５の移動エージェントは、移動対象イベントである登録イベント３０３の移動先日時を設定する（Ｓ３０３）。この場合、登録イベント３０３の開催猶予期間である「２００７年３月５日１０時００分〜１８時００分」から移動対象イベントである登録イベント３０３の登録日時「２００７年３月５日１７時００分〜１７時３０分」を除いた期間で最も早い時間帯を選択する。すなわち、「２００７年３月５日１０時００分〜１０時３０分」を移動先日時として設定する（Ｓ３０３）。図１９に示すように、この日時にユーザ２０５には登録イベントはないので（Ｓ３０７：ＹＥＳ）、ユーザ端末２５がユーザ端末２３から受信した移動依頼通知を基にした派生移動依頼通知を生成する（Ｓ３０８）。すなわち、端末ＩＤ欄７３において、ユーザ端末２１の「ＩＤ＿２０１」およびユーザ端末２３の「ＩＤ＿２０３」の後に新たにユーザ端末２５の「ＩＤ＿２０５」が追加され、さらに、データ欄７４が「２００７年３月５日１７時００分〜１７時３０分に登録された登録イベント３０３を、２００７年３月５日１０時００分〜１０時３０分に移動してください。」というテキストデータに書き換えられる。その後、ユーザ端末２５の移動エージェントは、生成した派生移動依頼通知を、ユーザ端末２１に送信する（Ｓ３０９）。
【００８８】
ユーザ端末２１の移動エージェントがユーザ端末２５からの派生移動依頼通知を受信すると（図１４、Ｓ２０９：ＹＥＳ）、ユーザ端末２１において、図１７の移動依頼受入れ判断処理が開始される。ユーザ端末２１の移動エージェントは、受信した移動依頼通知の端末ＩＤ欄７３には「ＩＤ＿２０１」、「ＩＤ＿２０３」および「ＩＤ＿２０５」が含まれているので、自己の端末ＩＤである「ＩＤ＿２０１」が含まれていると判断する（Ｓ２７２：ＹＥＳ）。すなわち、ユーザ端末２１から発信された移動依頼通知が伝播されて自己に戻ってきたものなので、これ以上登録イベントの移動可否を判断することなく、受信した派生移動依頼通知の発信元であるユーザ端末２５に対して、登録イベント３０３の移動は不可能（ＮＧ）の応答を送信する（Ｓ２７３）。この結果、ユーザ端末２５の移動エージェントは、ユーザ端末２１からＮＧの応答を受信する（Ｓ３１６：ＮＯ）。そこで、その後も開催猶予期間内で移動先日時をずらして移動依頼を行い、ユーザ端末２１からの応答を得るが（Ｓ３２２：ＹＥＳ→Ｓ３０３〜Ｓ３１６）、ユーザ端末２１は、前述のように、自己の端末ＩＤを含むユーザ端末２５からの派生移動依頼通知に対してすべてＮＧの応答を返信する（Ｓ３１６：ＮＯ）。最終的には、ユーザ端末２５では開催猶予期間内で移動先日時をずらすことができなくなり（Ｓ３２２：ＮＯ）、自己がもともと受信した派生移動依頼通知の発信元であるユーザ端末２３に対して、登録イベント３０１の移動は不可能（ＮＧ）の応答を送信する（Ｓ３２３）。
【００８９】
ユーザ端末２３では、前述のようにユーザ端末２４からはＯＫの応答を受信しているが、ユーザ端末２５からの応答はＮＧである（Ｓ３１６：ＮＯ）。このとき、ユーザ端末２３の移動エージェントは、これ以上、登録イベント３０１の開催猶予期間「２００７年３月５日１４時００分〜１８時００分」で移動先日時をずらすことはできないため（Ｓ３２２：ＮＯ）、自己がもともと受信した移動依頼通知の発信元であるユーザ端末２１に対して、登録イベント３０１の移動は不可能（ＮＧ）の応答を送信する（Ｓ３２３）。
【００９０】
ユーザ端末２３から、ＮＧの応答を受けたユーザ端末２１の移動エージェントは、図１６の応答判断処理において、移動対象日時の「２００７年３月５日１４時００分〜１５時００分」では、移動対象者端末２０であるユーザ端末２３〜２５のすべてで登録イベントの移動ができなかったので（Ｓ２５６）、図１５の第１の移動依頼処理に戻り、「２００７年３月５日１５時００分〜１８時００分」の間で移動対象日時の変更を試みる（Ｓ２４１：ＹＥＳ→Ｓ２２２）。しかし、順に移動対象日時をずらしても、図１９に示すように、自ユーザのスケジュールに空きがないので（Ｓ２２６：ＮＯ）、最終的には開催猶予期間内で移動対象日時をずらせなくなり（Ｓ２４１：ＮＯ）、図５に示すように新規スケジュール入力画面５で入力された条件では、新規イベントは登録できないと決定される（Ｓ２４２）。
【００９１】
以上に説明したように、本実施形態のスケジュール調整システム１では、すでにスケジュールに登録された登録イベントを移動させる移動依頼通知に自己の端末ＩＤを付加して送信し、一方、自己の端末ＩＤを含む移動依頼通知を受信した場合には、一律に移動は不可能であると回答する。これによって、自己の移動依頼から派生した移動依頼によって自己の登録イベントを移動させなければならないという矛盾した状況に陥ることを回避することができる。また、登録イベントを移動させる場合には、予め設定されている開催猶予期間内で移動先日時が設定されるので、ユーザにとって不都合のないスケジュール変更を行うことができる。さらに、移動依頼通知には、発信元の端末ＩＤと日時の情報しか含まれていないので、移動依頼通知を受信するユーザに直接関係のない他のユーザの情報まで伝播していく危険を回避することができる。
【００９２】
本実施形態では、ユーザ端末２０が、本発明に係る「スケジュール調整装置」に相当する。また、図１７のＳ２７２において、移動依頼通知に自己の端末ＩＤが含まれるか否かを判断するＣＰＵ２１０が、「識別情報判断手段」に相当する。また、図１７のＳ２７５において、移動依頼通知に、移動先日時が含まれているか否かを判断するＣＰＵ２１０が、「移動先有無判断手段」に相当する。また、図１７のＳ２７８において、移動先日時に他の登録イベントがあるか否かを判断するＣＰＵ２１０が、「移動先登録判断手段」に相当する。また、図１７のＳ２７３において、移動依頼通知の送信元に移動不可通知を送信するＣＰＵ２１０が、「第１の移動不可通知送信手段」に相当する。また、図１７のＳ２８０において、移動依頼通知の送信元に移動可能通知を送信するＣＰＵ２１０が、「第１の移動可能通知送信手段」に相当する。また、図１７のＳ２８１またはＳ２８５にいおいて、移動対象イベントを特定するＣＰＵ２１０が、「移動対象イベント特定手段」に相当する。また、図１８のＳ３０３〜Ｓ３０８において、移動先日時を新たに設定し、自己の識別情報を付加した移動依頼通知を作成するＣＰＵ２１０が、「移動依頼通知作成手段」に相当する。また、図１８のＳ３０９において、参加者端末へ移動依頼通知を送信するＣＰＵ２１０が、「移動依頼送信手段」に相当する。また、図１８のＳ３１８において、移動依頼通知の送信元に移動可能通知を送信するＣＰＵ２１０が、「第２の移動可能通知送信手段」に相当する。また、図１８のＳ３２３において、移動依頼通知の送信元に移動不可通知を送信するＣＰＵ２１０が、「第２の移動不可通知送信手段」に相当する。
【００９３】
<第２の実施形態>
次に、図２０〜図２３を参照して、本発明の第２の実施形態について説明する。図２０は、第２の実施形態における新規スケジュール入力画面５１の模式図である。図２１は、第２の実施形態における移動依頼通知の説明図である。図２２は、第２の実施形態における派生移動依頼通知の説明図である。図２３は、第２の実施形態における移動依頼受入れ判断処理のフローチャートである。
【００９４】
前述の第１実施形態では、ユーザ端末２０は、移動依頼通知に自己の端末ＩＤを付加することで、自己の移動依頼から派生した移動依頼によって自己の登録イベントが移動させられる事態を回避していた。本実施形態では、以下に詳述するように、移動依頼通知に依頼の伝播回数に関する情報を付加することで、移動依頼が際限なく続けられる非効率的なスケジュール調整を行わないようにすることを特徴とする。
【００９５】
本実施形態のスケジュール調整システム１を構成する管理サーバ１０およびユーザ端末２０の構成は、第１実施形態（図１〜図４参照）と同一であるため、説明を省略する。また、各エージェントによって行われる処理についても、移動エージェントによって行われる処理以外は、第１の実施形態と同一である。よって、同一の処理については説明を省略し、第１の実施形態と異なる処理についてのみ説明する。なお、第１実施形態と同様、ユーザ端末２１において処理が行われているものとして説明する。
【００９６】
まず、図２０を参照して、本実施形態で入力される新規イベント情報について説明する。図２０に示す新規スケジュール入力画面５１は、入力欄として、「重要度」欄５７が含まれる点が、第１実施形態の図５の新規スケジュール入力画面５とは異なっている。「重要度」欄５７には、新規イベントの重要度が５段階で入力される。なお、重要度は数字が大きくなるほど高く、「５」が最高である。また、詳細は後述するが、重要度は、他のユーザ端末２０から、すでに登録されているイベントを移動させるように依頼された場合に、移動エージェントによる移動可否の判断に用いられるものである。
【００９７】
次に、図２１および図２２を参照して、本実施形態において、移動エージェントによって生成され、移動交渉に使用される移動依頼通知について説明する。図２１に示すように、本実施形態の移動依頼通知には、第１の実施形態と同じ端末ＩＤ欄７３およびデータ欄７４に加え、伝播回数欄７１、伝播番号欄７２、および重要度欄７５が設けられている。伝播回数欄７１には、移動依頼通知に含まれる端末ＩＤの個数である「Ｎ」が記憶される。伝播番号欄７２には、移動依頼通知の伝播番号である「Ｐｎ」が記憶される。重要度欄７５には、移動依頼通知によって移動させられる登録イベントの代わりに新たに登録されるイベント（以下、交代イベントという）の重要度が記憶される。例えば、最初に、端末ＩＤが「２０１」のユーザ端末２１の移動エージェントが、図２０の入力例に示す新規イベントを登録するために、「２００７年３月５日１４時００分〜１５時００分」に登録された登録イベントの移動を依頼すると想定する。この場合、図２１の移動依頼通知において、伝播回数欄７１に「１」、伝播番号欄７２に「Ｐ１」、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」、重要度欄７５に「５」がそれぞれ記憶された移動依頼通知が生成されることになる。そして、移動依頼通知を受けたユーザ端末２１が、派生的に他のユーザ端末２０に登録イベントの移動を依頼する派生移動依頼通知を生成する場合には、移動エージェントは、第１の実施形態の場合と同様に、データ欄７４に記憶されたデータを自己の依頼内容のデータに書き換え、端末ＩＤ欄７３に端末ＩＤを追加する。さらに、本実施形態では、自己の伝播回数欄７１の伝播回数Ｎを１増加させ、伝播番号欄７２にも自己の伝播番号Ｐｎを追加する。また、重要度欄７５を登録イベントに代わって登録される交代イベントの重要度によって書き換える。例えば、前述の例の移動依頼通知を受信した、端末ＩＤが「２０３」のユーザ端末２３が、さらに「２００７年３月５日１７時００分〜１７時３０分」の登録イベント（重要度＝３）を「２００７年３月５日１０時００分〜１０時３０分」に移動させる場合を想定する。この場合には、図２２のように、伝播回数欄７１が「２」とされ、元の移動依頼通知の伝播番号欄７２１「Ｐ１」と端末ＩＤ欄７３１「ＩＤ＿２０１」の後に、新たに伝播番号欄７２２「Ｐ２」と端末ＩＤ欄７３２「ＩＤ＿２０３」が追加され、データ欄７４および重要度欄７５がそれぞれ「２００７年３月５日１６時００分〜１７時００分に登録された登録イベントを、２００７年３月５日１０時００分〜１０時３０分に移動してください。」および「３」に書き換えられた移動依頼通知が生成されることになる。このような構成とすることにより、移動依頼通知に含まれる端末ＩＤ（ＩＤ＿Ｘ）によって、第１の実施形態と同様に、移動依頼の伝播過程にあったユーザ端末２０をすべて特定することができる。さらに、伝播回数（Ｎ）によって、最初の移動依頼通知に派生して、移動依頼が何回行われたかを特定することができる。また、交代イベントの重要度が通知されることにより、登録イベントを移動させる妥当性がより適切に判断できるようになる。
【００９８】
次に、前述のような移動依頼通知を用いて移動エージェントによって行われる処理について説明する。本実施形態でも、新規イベント情報が入力されると、第１の実施形態と同様に、まず交渉エージェントによって参加者の空き確認が行われ（図１０参照）、共通の空きがないと確認されると移動エージェントが起動される。そして、移動エージェントによって、他のユーザ端末２０に対して、登録イベントの移動を依頼する第１の移動依頼処理（図１４、Ｓ２３０および図１５）が行われる。図１５に示す第１の移動依頼処理の流れは、第１の実施形態と同一である。ただし、Ｓ２３６において生成される移動依頼通知の内容のみ、第１実施形態とは異なっている。すなわち、第１実施形態で生成される移動依頼通知は、端末ＩＤ欄７３とデータ欄７４のみから構成されていたが、本実施形態では、前述したように、伝播回数欄７１、伝播番号欄７２、重要度欄７５が追加されている（図２１参照）。したがって、本実施形態では、例えば、伝播回数欄７１に「１」、伝播番号欄７２に「Ｐ１」、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」、重要度欄７５に新規イベントの重要度である「５」がそれぞれ記憶された移動依頼通知が作成されることになる。
【００９９】
一方、ユーザ端末２１において、他のユーザ端末２０からの移動依頼通知を受信した場合には、移動エージェントによって、移動依頼受入れ判断処理（図１４、Ｓ２７０）が行われる。本実施形態では、第１の実施形態の移動依頼受入れ判断処理（図１７）とは異なる処理が行われるため、図２３を参照して、以下に詳細を説明する。図２３の移動依頼受入れ判断処理が開始されると、移動エージェントはまず、受信した移動依頼通知をＲＡＭ２３０の移動依頼情報記憶エリア２４３（図４参照）に取得して記憶させる（Ｓ５００）。そして、取得した移動依頼通知に、自己の端末ＩＤが含まれているか否かを判断する（Ｓ５０１）。前述したように、移動依頼通知（図２２参照）の端末ＩＤ欄７３には、移動依頼通知を最初に発信したユーザ端末２０の端末ＩＤと、その後、この移動依頼通知に派生して発信された派生移動依頼通知がある場合には、その発信者のユーザ端末２０の端末ＩＤとが含まれている。したがって、移動依頼通知に自己の端末ＩＤ（ユーザ端末２１の場合は「ＩＤ＿２０１」）が含まれている場合（Ｓ５０１：ＮＯ）、自己の端末ＩＤを含む移動依頼を拒否するか否かの情報である自己依頼許否情報を確認する（Ｓ５０２）。本実施形態では、ハードディスク装置２５０の基本情報記憶エリア２５５（図３参照）に記憶されているユーザ端末２１の基本情報として、端末ＩＤの他に、自己依頼許否情報が記憶されている。これは、自ユーザが発信した移動依頼が伝播して、自己の登録イベントを移動させる依頼となって戻ってきた場合に、移動依頼のループを回避するためにこの移動依頼を拒否するか否かを選択することができるようにするためである。よって、移動依頼通知に自己の端末ＩＤが含まれており（Ｓ５０１：ＮＯ）、基本情報記憶エリア２５５に自己依頼許否情報として「拒否」が記憶されている場合には（Ｓ５０２：ＹＥＳ）、移動エージェントは移動可否の判断は行わなず、移動依頼通知の発信元のユーザ端末２０に対して移動不可能（ＮＧ）の回答を送信する（Ｓ５３１）。そして、回答を送信すると、図１４の移動エージェントのメイン処理に戻る。なお、基本情報記憶エリア２５５に記憶される自己依頼許否情報は、ユーザ端末２１のユーザ２０１が任意に設定することができる。
【０１００】
一方、基本情報記憶エリア２５５に自己依頼許否情報として「許可」が記憶されている場合には（Ｓ５０２：ＮＯ）、移動依頼通知に自己の端末ＩＤが含まれていてもそのまま処理を継続する。よって、この場合と（Ｓ５０１：ＹＥＳ→Ｓ５０２：ＮＯ）、移動依頼通知に自己の端末ＩＤが含まれていない場合には（Ｓ５０１：ＮＯ）、移動エージェントは、移動依頼通知の伝播回数欄７１（図２２参照）に含まれる伝播回数Ｎが、規定値を超えているか否かを判断する（Ｓ５０５）。本実施形態では、ハードディスク装置２５０の基本情報記憶エリア２５５（図３参照）に記憶されているユーザ端末２１の基本情報に、移動依頼の伝播回数として許容する上限値である規定値が含まれている。これは、あるイベントの登録のために他の登録イベントを移動させる依頼が際限なく続けられるのは非効率的であるため、ある程度移動依頼が伝播した時点で、これ以上の調整は不可能であると見切りをつけるためである。よって、移動エージェントは、移動依頼通知に含まれている伝播回数がこの規定値を超えていると判断すると（Ｓ５０５：ＹＥＳ）、移動可否の判断は行わなず、移動依頼通知の発信元のユーザ端末２０に対して移動不可能（ＮＧ）の回答を送信する（Ｓ５３１）。そして、回答を送信すると、図１４の移動エージェントのメイン処理に戻る。なお、規定値は、ユーザ端末２１のユーザ２０１が任意に設定することができ、例えば「２」が記憶される。
【０１０１】
一方、移動依頼通知に含まれる伝播回数Ｎが規定値以下の場合には（Ｓ５０５：ＮＯ）移動エージェントは、移動依頼通知に移動先日時が特定されているか否かを判断する（Ｓ５０８）。その後、第１の実施形態と同様に、移動先日時が含まれていると判断した場合（Ｓ５０８：ＹＥＳ）、スケジュール管理エージェントに、移動先日時のスケジュール情報を読み出すように指示し（Ｓ５１５）、スケジュール情報記憶エリア２３４（図４参照）に、移動先日時のスケジュール情報を取得する（Ｓ５１６）。そして、移動先日時にすでに登録された登録イベントがなければ（Ｓ５１８：ＮＯ）、移動エージェントは、移動対象日時に登録されていた登録イベントを移動先日時に移動できると判断する。よって、移動可能（ＯＫ）の回答を移動依頼の発信元のユーザ端末２０に発信してから（Ｓ５１９）、図１４のメイン処理に戻る。
【０１０２】
移動先日時にすでに登録されている別の登録イベントがある場合は（Ｓ５１８：ＹＥＳ）、この別の登録イベントを他の日時に移動させなければ、移動依頼通知によって依頼された移動を行うことができない。そこで、移動エージェントは、移動先日時の登録イベントをさらに移動させるべく、移動対象イベントとして特定し、移動対象イベントのスケジュール情報を、ＲＡＭ２３０の移動対象イベント情報記憶エリア２４６に記憶させる（Ｓ５２１）。このときスケジュール情報として取得される情報には、移動対象イベントの重要度が含まれている。一方、ＲＡＭ２３０の移動依頼情報記憶エリア２４３に記憶された移動依頼通知には、移動対象イベントに代えて登録したい交代イベントの重要度が含まれている。そこで、移動エージェントは、これらの重要度を比較し、交代イベントの重要度の方が移動対象イベントの重要度よりも高いか否かを判断する（Ｓ５２２）。交代イベントの重要度の方が高ければ（Ｓ５２２：ＹＥＳ）、より重要な交代イベントのために移動対象イベントを移動させるのは妥当であるから、移動エージェントは、移動対象イベントの参加者に移動の可否を確認する処理に進む。すなわち、管理サーバ１０の個人情報ＤＢ（図２参照）から移動対象イベントの参加者の情報を取得し（Ｓ５２５）、参加者端末２０の管理エージェントに対して、参加者端末２０の移動エージェントを起動するように依頼し（Ｓ５２６）、第２の移動処理に進む（Ｓ３００）。一方、交代イベントの重要度が移動対象イベントの重要度以下であれば（Ｓ５２２：ＮＯ）、移動対象イベントを移動させてまで交代イベントを登録するのは妥当でない。よって、移動エージェントは、移動依頼通知の発信元のユーザ端末２０に対して移動不可能（ＮＧ）の回答を送信する（Ｓ５３１）。そして、回答を送信すると、図１４の移動エージェントのメイン処理に戻る。
【０１０３】
また、Ｓ５０８において、移動依頼通知に移動先日時が含まれていないと判断された場合には（Ｓ５０８：ＮＯ）、移動依頼日時にすでに登録されている登録イベントを、まだ特定されていない他の日時に移動させることになる。そこで移動エージェントは、スケジュール管理エージェントに、ハードディスク装置２５０のスケジュールＤＢ（図３参照）から、移動依頼通知に含まれる移動依頼日時のスケジュール情報を読み出すように指示し（Ｓ５１０）、ＲＡＭ２３０のスケジュール情報記憶エリア２３４に取得する（Ｓ５１１）。そして、取得された登録イベント情報を移動対象イベント情報として、ＲＡＭ２３０の移動対象イベント情報記憶エリア２４６に記憶させる（Ｓ５１２）。Ｓ５１１で取得された移動対象イベントのスケジュール情報には、移動対象イベントの重要度が含まれている。一方、ＲＡＭ２３０の移動依頼情報記憶エリア２４３に記憶された移動依頼通知には、移動対象イベントに代えて登録したい交代イベントの重要度が含まれている。そこで、移動エージェントは、これらの重要度を比較し、交代イベントの重要度の方が移動対象イベントの重要度よりも高いか否かを判断する（Ｓ５２２）。この後の処理は、前述した移動先に登録イベントがあった場合（Ｓ５１８：ＹＥＳ）の処理と同様である。
【０１０４】
ここで、図１８を参照して、本実施形態における第２の移動依頼処理（Ｓ３００）について説明する。本実施形態でも、図１８の第２の移動依頼処理の流れは第１の実施形態と同一である。ただし、Ｓ３０８において生成される移動依頼通知の内容のみ、第１実施形態とは異なっている。すなわち、ここで生成されるのは派生移動依頼通知であるから、移動エージェントは、第１の実施形態の場合と同様に、データ欄７４に記憶されたデータを自己の依頼内容のデータに書き換え、端末ＩＤ欄７３に端末ＩＤを追加する。さらに、自己の伝播回数欄７１の伝播回数Ｎを１増加させ、伝播番号欄７２にも自己の伝播番号Ｐｎを追加する。また、重要度欄７５を登録イベントに代わって登録される交代イベントの重要度によって書き換える。例えば、図２２に示すような派生移動依頼通知が生成される。
【０１０５】
ここで、第１の実施形態で説明した図１９の具体例が、本実施形態ではどのように処理されるかを説明する。なお、以下の説明では、ユーザ端末２１で図２０に示すように新規イベント情報が入力されたものとし、いずれのユーザ端末２０でも、自己依頼許否情報は「許可」、伝播回数の上限値である規定値は「２」に設定されているものとする。また、登録イベント３０１、３０３の重要度はそれぞれ「４」、「３」とする。その他の情報については、特に他の説明を行わない限り、第１の実施形態で説明したのと同じである。
【０１０６】
ユーザ端末２１において図２０に示すように新規イベント情報が入力された後、ユーザ端末２１の交渉エージェントによって空き確認処理が行われるが、第１の実施形態と同様、交渉は成立しない。よって、移動エージェントによる移動交渉が開始され、図１５の第１の移動依頼処理において、ユーザ端末２１の移動エージェントは移動依頼通知を生成し（Ｓ２３６）、ユーザ端末２３に対して送信する（Ｓ２３７）。このとき生成される移動依頼通知（図２１参照）には、伝播回数欄７１に「１」、伝播番号欄７２に「Ｐ１」、端末ＩＤ欄７３に「ＩＤ＿２０１」、データ欄７４に「２００７年３月５日１４時００分〜１５時００分に登録された登録イベントを、他の日時に移動してください。」というテキストデータ、重要度欄７５に「５」がそれぞれ記憶されている。
【０１０７】
ユーザ端末２１からの移動依頼通知を受信したユーザ端末２３では、本実施形態に係る図２３の移動依頼受入れ判断処理が開始される。ユーザ端末２３の移動エージェントは、受信した移動依頼通知には自己の端末ＩＤは含まれていないので（Ｓ５０１：ＮＯ）、伝播回数を確認する。伝播回数欄７１の「１」は規定値の「２」を超えていないので（Ｓ５０５：ＮＯ）、移動先日時の有無を確認すると、移動先日時は含まれていない（Ｓ５０８：ＮＯ）。よって、移動対象日時である「２００７年３月５日１４時００分〜１５時００分」の登録イベント３０１を移動対象イベントとして特定し（Ｓ５１２）、交代イベントである新規イベントの重要度「５」と、移動対象イベントである登録イベント３０１の重要度を比較する（Ｓ５２２）。登録イベント３０１の重要度は「４」であり、交代イベントの重要度の方が高い（Ｓ５２２：ＹＥＳ）。よって、ユーザ端末２３の移動エージェントは、第２の移動依頼処理（Ｓ３００、図１８）に移る。
【０１０８】
図１８の処理に移ると、第１実施形態で説明したように、ユーザ端末２３の移動エージェントは、移動先日時を「２００７年３月５日１７時００分〜１８時００分」を移動先日時として設定し（Ｓ３０３）、派生移動依頼通知を生成する（Ｓ３０８）。ここでは、図２２に示すように、伝播回数欄７１が「２」とされ、第１の移動依頼通知の伝播番号欄７２１の「Ｐ１」と端末ＩＤ欄７３１の「ＩＤ＿２０１」の後に、新たに第２の伝播番号欄７２２の「Ｐ２」と端末ＩＤ欄７３２の「ＩＤ＿２０３」が追加され、データ欄７４および重要度欄７５がそれぞれ「２００７年３月５日１４時００分〜１５時００分に登録された登録イベント３０１を、２００７年３月５日１７時００分〜１８時００分に移動してください。」および「４」に書き換えられた派生移動依頼通知が生成される（Ｓ３０８）。その後、ユーザ端末２３の移動エージェントは、生成した派生移動依頼通知を、ユーザ端末２４および２５に送信する（Ｓ３０９）。
【０１０９】
ユーザ端末２４および２５の移動エージェントがユーザ端末２３からの派生移動依頼通知を受信すると、ユーザ端末２４および２５でも、図２３の移動依頼受入れ判断処理が開始される。ユーザ端末２４の移動エージェントは、受信した移動依頼通知には自己の端末ＩＤは含まれていないので（Ｓ５０１：ＮＯ）、伝播回数を確認する。伝播回数欄７１の「２」は規定値の「２」をまだ超えていないので（Ｓ５０５：ＮＯ）、移動先日時の有無を確認すると、移動先日時「２００７年３月５日１７時００分〜１８時００分」がある（Ｓ５０８：ＹＥＳ）。しかし、ユーザ２０４にはこの日時に登録イベントはないので（Ｓ５１８：ＮＯ）ユーザ端末２４の移動エージェントは、ユーザ端末２３に対して、登録イベント３０１は移動可能（ＯＫ）の応答を送信する（Ｓ５１９）。
【０１１０】
一方、ユーザ端末２５の移動エージェントも同様の処理を行う。ユーザ端末２５では、自己の端末ＩＤおよび伝播回数についてはユーザ端末２４と同様の判断がされるが（Ｓ５０１：ＮＯ→Ｓ５０５：ＮＯ）、移動先日時にかかる「２００７年３月５日１７時００分〜１７時３０分」には、すでに登録されている登録イベント３０３がある（Ｓ５１８：ＮＯ）。ここで、移動対象イベントとされる登録イベント３０３の重要度は「３」である。移動依頼通知には、登録イベント３０３の代わりに登録される交代イベント（登録イベント３０１）の重要度「４」が含まれるので、移動エージェントは両者を比較する。すると、登録イベント３０１の重要度の方が高いので（Ｓ５２２：ＹＥＳ）、ユーザ端末２５の移動エージェントは、第２の移動依頼処理（Ｓ３００、図１８）に移る。そして、移動対象イベントである登録イベント３０３の移動先日時を「２００７年３月５日１０時００分〜１０時３０分」に設定し、派生移動依頼通知を生成する（Ｓ３０８）。ここでは、伝播回数欄７１が「３」とされ、第１の伝播番号欄７２１の「Ｐ１」と端末ＩＤ欄７３１の「ＩＤ＿２０１」、第２の伝播番号欄７２２の「Ｐ２」と端末ＩＤ欄７３２の「ＩＤ＿２０３」の後に、新たに第３の伝播番号欄７２３の「Ｐ３」と端末ＩＤ欄７３３の「ＩＤ＿２０５」が追加され、データ欄７４および重要度欄７５がそれぞれ「２００７年３月５日１７時００分〜１７時３０分に登録された登録イベント３０３を、２００７年３月５日１０時００分〜１０時３０分に移動してください。」および「３」に書き換えられた派生移動依頼通知が生成される（Ｓ３０８）。その後、ユーザ端末２５の移動エージェントは、生成した派生移動依頼通知を、ユーザ端末２１に送信する（Ｓ３０９）。
【０１１１】
ユーザ端末２５からの派生移動依頼通知を受信したユーザ端末２１の移動エージェントは、図２３の移動依頼受入れ判断処理を開始する。ユーザ端末２１の移動エージェントは、受信した移動依頼通知に自己の端末ＩＤである「ＩＤ＿２０１」が含まれていると判断する（Ｓ５０１：ＹＥＳ）。しかし、前述の通り、ユーザ端末２１の自己依頼許否情報は「許可」なので（Ｓ５０２：ＮＯ）、伝播回数を確認する。前述の通り、ユーザ端末２１で設定されている規定値は「２」なので、移動依頼通知に含まれる伝播回数「３」は、規定値を超えている（Ｓ５０５：ＮＯ）。そこで、ユーザ端末２１は、移動依頼の連鎖をここで断つために、ユーザ端末２５に対して移動不可能（ＮＧ）の回答をして（Ｓ５３１）。図１４のメイン処理に戻る。この後、第１実施形態で説明したように、ユーザ端末２１で、新規イベントの登録は不可能であると最終的に結論される。
【０１１２】
このようにして、自己の端末ＩＤが含まれる移動依頼通知を受け付ける場合であっても、伝播回数の上限値を規定することで、移動依頼が際限なく続けられる非効率的な処理を回避することができる。
【０１１３】
なお、前述の例で、例えば、登録イベント３０３の重要度が「３」ではなく「５」だったとする。この場合、ユーザ端末２５では、移動受入れ判断処理の重要度判断（図２３、Ｓ５２２）において、交代イベントである登録イベント３０１の重要度「４」の方が、移動対象イベントである登録イベント３０３の重要度「５」よりも低いと判断される（Ｓ５２２：ＮＯ）。この結果、ユーザ端末２５は、これ以上移動の可否判断をすることなく、ユーザ端末２３にＮＧの回答をする（Ｓ５３１）。すなわち、重要度に応じて移動の可否を判断する処理を取り入れることで、不合理な移動をさせられる可能性を低減することができる。
【０１１４】
本実施形態では、図２３のＳ５２２において、イベントの重要度の比較判断を行うＣＰＵ２１０が、「重要度判断手段」に相当する。また、図２３のＳ５３１において、移動依頼通知の発信元に移動不可通知を送信するＣＰＵ２１０が、「第３の移動不可送信手段」に相当する。また、図２３のＳ５０５において、移動依頼通知に含まれる伝播回数が規定値を超えているか否かを判断するＣＰＵ２１０が、「伝播回数判断手段」に相当する。また、図２３のＳ５０８において、移動依頼通知に移動先日時が含まれているか否かを判断するＣＰＵ２１０が、「移動先有無判断手段」に相当する。また、図２３のＳ５１８において、移動先日時に他の登録イベントがあるか否かを判断するＣＰＵ２１０が、「移動先登録判断手段」に相当する。また、図２３のＳ５３１において、移動依頼通知の送信元に移動不可通知を送信するＣＰＵ２１０が、「第１の移動不可通知送信手段」に相当する。また、図２３のＳ５１９において、移動依頼通知の送信元に移動可能通知を送信するＣＰＵ２１０が、「第１の移動可能通知送信手段」に相当する。また、図２３のＳ５１２およびＳ５２１において、移動対象イベントを特定するＣＰＵ２１０が、「移動対象イベント特定手段」に相当する。また、図１８のＳ３０８において、伝播回数に１を加算した移動依頼通知を作成するＣＰＵ２１０が、「移動依頼通知作成手段」に相当する。また、図１８のＳ３０９において、参加者端末へ移動依頼通知を送信するＣＰＵ２１０が、「移動依頼送信手段」に相当する。
【０１１５】
なお、本発明は、前述した第１の実施形態および第２の実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において各種の変形が可能なことは言うまでもない。例えば、第１の実施形態では、移動依頼通知に自己の識別情報が含まれていない場合には、移動先日時に登録イベントがない場合（図１７のＳ２８０でＯＫの回答をする場合）以外は、すべて一律でさらなる移動依頼を行っていた。しかし、第２の実施形態と同様に、交代イベントと移動対象イベントの重要度の比較を行い、交代イベントの重要度が高い場合にのみ、さらなる移動依頼を行うようにしてもよい。また、第２の実施形態では、まず移動依頼通知に自己の識別情報が含まれているか否か、および伝播回数が規定値を超えているか否かの判断を行い、さらに重要度の比較を行っていた。しかし、これ以外に、移動依頼通知に自己の識別情報が含まれているか否か、および伝播回数が規定値を超えているか否かの判断は行うが、第１の実施形態と同様に、重要度の比較は行わないようにしてもよい。あるいは、伝播回数が規定値を超えているか否かの判断のみを行い、伝播回数が規定値を超えていない場合には、移動先日時に登録イベントがない場合（図２３のＳ５１９でＯＫの回答をする場合）以外は、第１の実施形態と同様に、すべて一律でさらなる移動依頼を行ってもよい。
【図面の簡単な説明】
【０１１６】
【図１】スケジュール調整システム１の全体構成図である。
【図２】管理サーバ１０の電気的構成を示すブロック図である。
【図３】ユーザ端末２０の電気的構成を示すブロック図である。
【図４】ユーザ端末２０のＲＡＭ２３０の説明図である。
【図５】ディスプレイ２６３に表示される新規スケジュール入力画面５の模式図である。
【図６】管理エージェントによる全体処理のフローチャートである。
【図７】管理エージェントによる全体処理のフローチャートであって、図６の続きである。
【図８】スケジュール管理エージェントによるスケジュール管理処理のフローチャートである。
【図９】交渉エージェントによるメイン処理のフローチャートである。
【図１０】交渉エージェントのメイン処理で行われる空き確認処理のフローチャートである。
【図１１】交渉エージェントのメイン処理の中で行われる空き判断処理のフローチャートである。
【図１２】移動依頼通知の説明図である。
【図１３】派生移動依頼通知の説明図である。
【図１４】移動エージェントによるメイン処理のフローチャートである。
【図１５】移動エージェントによるメイン処理の中で行われる第１の移動処理のフローチャートである。
【図１６】第１の移動処理の中で行われる応答判断処理のフローチャートである。
【図１７】移動エージェントによるメイン処理の中で行われる移動依頼受入れ判断処理のフローチャートである。
【図１８】移動依頼受入れ判断処理の中で行われる第２の移動依頼処理のフローチャートである。
【図１９】ユーザ端末２１〜２５におけるスケジュール調整処理の具体例の説明図である。
【図２０】第２の実施形態における新規スケジュール入力画面５１の模式図である。
【図２１】第２の実施形態における移動依頼通知の説明図である。
【図２２】第２の実施形態における派生移動依頼通知の説明図である。
【図２３】第２の実施形態における移動依頼受入れ判断処理のフローチャートである。
【符号の説明】
【０１１７】
１  スケジュール調整システム
１０  管理サーバ
２０、２１、２２、２３、２４、２５  ユーザ端末
２１０  ＣＰＵ
【図１】
2008269417.tif 000003
【図２】
2008269417.tif 000004
【図３】
2008269417.tif 000005
【図４】
2008269417.tif 000006
【図５】
2008269417.tif 000007
【図６】
2008269417.tif 000008
【図７】
2008269417.tif 000009
【図８】
2008269417.tif 000010
【図９】
2008269417.tif 000011
【図１０】
2008269417.tif 000012
【図１１】
2008269417.tif 000013
【図１２】
2008269417.tif 000014
【図１３】
2008269417.tif 000015
【図１４】
2008269417.tif 000016
【図１５】
2008269417.tif 000017
【図１６】
2008269417.tif 000018
【図１７】
2008269417.tif 000019
【図１８】
2008269417.tif 000020
【図１９】
2008269417.tif 000021
【図２０】
2008269417.tif 000022
【図２１】
2008269417.tif 000023
【図２２】
2008269417.tif 000024
【図２３】
2008269417.tif 000025