以下、本開示を具体化したスケジュール� ��整装置の実施の形態について、図面を参照� ��て説明する。なお、これらの図面は、採用� ��うる技術的特徴を説明するために用いられ� ��ものであり、記載されている装置の構成、� ��種処理のフローチャートなどは、それのみ� ��限定する趣旨ではなく、単なる説明例であ� ��。

 まず、図1~図14を参照して、本開示の1つ� �実施の形態について説明する。最初に、図1~ 図7を参照して、本実施形態に係るスケジュ� �ル調整システム1の構成について説明する。� ��1に示すように、スケジュール調整システム 1は、サーバ10と、サーバ10にネットワークを� ��して接続されたユーザ端末21、22を含む複数 のユーザ端末20を備えている。スケジュール� ��整システム1では、ユーザ端末20のユーザ200� ��操作により、ユーザ端末20がネットワーク� �介してサーバ10にアクセスし、必要なデータ を入手して、後述するスケジュール調整処理 を行う。図中のユーザ端末21、22・・・他は� �べて同じ構成を有する。よって、これ以降� �「ユーザ端末20」という場合には、複数のユ ーザ端末21、22を含むすべてのユーザ端末を� �称するか、または不特定のユーザ端末を指� �。「ユーザ端末21」という場合には、ある特 定の「ユーザ端末21」を指す。各ユーザ端末2 0は、それぞれについてユーザが特定されて� �る。よって、「ユーザ200」という場合には� �不特定のユーザ端末20のユーザを指す。「ユ ーザ210」、「ユーザ220」等という場合には、 それぞれ「ユーザ端末21のユーザ210」、「ユ� ��ザ端末22のユーザ220」等を指す。

 次に、図2のブロック図を参照して、サー バ10の電気的構成について説明する。サーバ1 0は、所謂パーソナルコンピュータであり、� �用型の装置である。図2に示すように、サー� ��10には、サーバ10の制御を司るCPU1011、BIOS等� ��記憶したROM1012および各種データを一時的に 記憶する記憶エリアを有するRAM1013を備えた� �御部101が設けられている。ROM1012およびRAM1013 は、それぞれCPU1011に接続されている。CPU1011� ��はさらに、バス109を介して、記憶装置102、� ��種データの入力を行うためのキーボード103� ��各種データを表示するディスプレイ104、ネ� ��トワークを介して行われるユーザ端末20と� �通信を制御する通信制御部105、CD-ROM等の記� �媒体を駆動する記憶媒体駆動装置106、およ� �データの受け渡しの仲介を行う入出力イン� �ーフェース(I/F)107が接続されている。

 サーバ10の記憶装置102には、複数の記憶� �リアが設けられている。これらの記憶エリ� �には、個人スケジュールデータベース(以下� ��個人スケジュールDBという)1022、会議室スケ ジュールデータベース(以下、会議室DBという )1023、パーソナルデータデータベース(以下、 パーソナルDBという)1024、必須属性データベ� �ス(以下、必須属性DBという)1025、およびCPU101 1により実行される各種プログラム(図示外)等 がそれぞれ記憶されている。個人スケジュー ルDB1022には、すべてのユーザ端末20のユーザ2 00毎に、識別コード、氏名、および、ユーザ2 00のスケジュールを含むスケジュール情報が� ��憶されている。スケジュールとは、例えば� ��すでに調整が行われて登録されたイベント� ��区分、内容、日時、場所、参加者等である� ��会議室DB1023には、サーバ10の管理する会議� �毎に、例えば、会議室の名称、場所、予約� �日時、予約の登録者、イベントの区分、イ� �ント参加者を含む会議室予約情報が記憶さ� �ている。

 図3を参照して、パーソナルDB1024に登録さ れたパーソナルデータについて説明する。パ ーソナルDB1024には、すべてのユーザ端末20の� ��ーザ200毎に、そのユーザ200の個人情報が、� ��ーソナルデータとして記憶されている。具� ��的には、例えば、ユーザ200の識別コード、� ��名、会社、部署、役職、役職レベル、住所� ��電話番号、Eメールアドレス、職種が記憶さ れている。例えば、図3に示すように、ユー� �端末21のユーザ210(AA)のパーソナルデータと� �ては、識別コードとしてユーザ210の社員コ� �ドである「210」、氏名としてユーザ210の氏� �である「AA」、会社として「A社」、部署と� �て「開発部」が記憶されている。役職とし� �は、AAは役職者ではないため、データは記憶 されていない。役職は、会社や部署によって 名称が異なり、例えばある会社の「マネージ ャー」が他の会社の「主任」に相当したりす る。よって、役職レベルには、こういった役 職名の相違に関係なく、すべての役職の上下 関係を比較できるように、1~5までのいずれか の数字が記憶されている。本実施形態では、 役職レベルは、小さい数字ほど上位の役職を 示している。AAのように、ユーザ200が役職者� ��ない場合には、図3に示すように、役職レベ ルとして最下位の「5」が記憶される。また� �ユーザ210の住所、電話番号、Eメールアドレ� ��として、それぞれ「○○県△△市◇◇町」� ��「00-0000-0000」、「Aaaa@a.co.jp」が記憶されて� ��る。さらに、職種として「開発(ハード)」� �記憶されている。職種は、ユーザ200の現在� �業務に対応する内容が登録される。図3の例� ��、ユーザ210(AA)は、現在、A社においてハー� �ウェアの開発に携わっていることを示して� �る。

 次に、図4を参照して、必須属性DB1025に記 憶された必須属性データについて説明する。 必須属性DB1025には、必須属性データとして、 各イベントの「内容」に対応づけて、その内 容のイベントへの参加者の少なくとも1名が� �えるべき必須の属性が記憶されている。例� �ば、イベントが会議である場合には、図4に� ��すように、「定例会」、「戦略会議」、「� ��許面談」、「予算会議」等の会議の名称が� ��イベントの内容として記憶されている。そ� ��て、各会議に対応して、参加者の属性の具� ��例である「部署」、「役職」、「職種」に� ��いて、必須の条件が登録されている。

 図4の例は、イベントの内容が「定例会」 であれば、その定例会には、部署および職種 が「入力者と同じ」である任意のユーザ200の 参加が必須であることを示している。役職レ ベルに関する条件は「何でもよい」であるか ら、そのユーザ200は役職者であってもなくて もよい。同様に、例えばイベントの内容が「 予算会議」の場合は、役職レベルは何でもよ いが、部署が「財務部」で職種が「経理」の 任意のユーザ200と、職種は何でもよいが、部 署が「入力者と同じ」で役職レベルが部長ク ラスである「1」の任意のユーザ200の2名の参� ��が必須である。これらの条件は、予算を決� ��するための予算会議には、会社全体の予算� ��管理する財務部で経理を担当する人物と、� ��の部署の予算について決裁権限を有する部� ��クラスの人物の参加が必須であることを示� ��ている。このように、本実施形態では、各� ��ベント(会議)の内容に応じて、そのイベン� �に参加が必須とされる必須参加者の属性に� �する条件(以下、必須参加者条件という)が定 められている。この必須参加者条件は、後で 詳述するように、入力時に指定された参加者 のみでイベントを開催してよいか否か、すな わち、他に参加者を追加すべきか否かの判断 に利用される。本実施形態では、説明の簡略 化のため、イベントの内容が会議の場合のみ を想定して必須属性データが例示されている 。しかし、必須属性DB1025には、研修、展示会 等、会議以外の他のイベントについても、内 容に応じて同様に必須の属性との対応関係が 登録されていてもよい。また、必須参加者条 件として定められる属性については、「部署 」、「役職」、「職種」に限られず、他に「 保有資格」、「知識レベル」等を用いてもよ いし、「部署」、「役職」、「職種」のうち 1つまたは2つのみを用いることもできる。

 次に、図5のブロック図を参照して、ユー ザ端末20の電気的構成について説明する。ユ� ��ザ端末20は、所謂パーソナルコンピュータ� �あり、汎用型の装置である。図5に示すよう� ��、ユーザ端末20には、サーバ10と同様、ユー ザ端末20の制御を司るCPU2011、BIOS等を記憶し� �ROM2012および各種データを一時的に記憶するR AM2013を備えた制御部201が設けられている。ROM 2012およびRAM2013は、それぞれCPU2011に接続され ている。RAM2013の詳細については後述する。CP U2011にはさらに、バス209を介して、記憶装置2 02、各種データの入力を行うためのキーボー� ��203、各種データを表示するディスプレイ204� ��ネットワークを介して行われるサーバ10お� �び他のユーザ端末20との通信を制御する通信 制御部205、CD-ROM等の記憶媒体を駆動する記憶 媒体駆動装置206、およびデータの受け渡しの 仲介を行う入出力インターフェース(I/F)207が� ��続されている。記憶装置202には、複数の記� ��エリアが設けられている。これらの記憶エ� ��アの1つには、キーボード203を用いたユーザ 200からの入力を受けて、スケジュール調整処 理を行うスケジュール調整プログラム2021が� �憶されている。スケジュール調整プログラ� �による処理については、後で詳述する。ま� �、図示しないが、他の記憶エリアには、CPU20 11で実行されるその他のプログラム等が記憶� ��れている。

 図6を参照して、RAM2013の詳細について説� �する。図6に示すように、各種データを一時� ��に記憶するRAM2013には、新規イベント情報記 憶エリア231、必須参加者条件記憶エリア232、 参加者情報記憶エリア233、不足条件記憶エリ ア234、追加参加者候補記憶エリア235、参加者 スケジュール記憶エリア236、会議室情報記憶 エリア237、候補日程記憶エリア238、処理対象 日程記憶エリア239、追加参加者スケジュール 記憶エリア240、選択候補記憶エリア241、およ びエラーフラグ記憶エリア242を含む複数の記 憶エリアが設けられている。

 新規イベント情報記憶エリア231には、ユ� ��ザ200が、新たにスケジュールの登録を希望� ��る新規イベントに関する情報を入力した場� ��に、入力された新規イベント情報が記憶さ� ��る。必須参加者条件記憶エリア232には、前� ��の必須属性DB1025から取得された、新規イベ� ��トの内容に対応する必須参加者条件が記憶� ��れる。参加者情報記憶エリア233には、前述� ��パーソナルDB1024から取得された、新規イベ� ��トの参加者のパーソナルデータが記憶され� ��。不足条件記憶エリア234には、入力された� ��加者のみでは満たされていない必須参加者� ��件である不足条件が記憶される。追加参加� ��候補記憶エリア235には、不足条件を満たす� ��とができるユーザ200のパーソナルデータが� ��追加参加者候補として記憶される。参加者� ��ケジュール記憶エリア236には、前述の個人� ��ケジュールDB1022から取得された、新規イベ� ��トの参加者のスケジュール情報が記憶され� ��。会議室情報記憶エリア237には、前述の会� ��室DB1023から取得された会議室予約情報が記� ��される。候補日程記憶エリア238には、新規� ��ベントのスケジュール調整の過程で、新規� ��ベントの開催日時および場所の候補として� ��択された候補日程が記憶される。処理対象� ��程記憶エリア239には、候補日程のすべてに� ��いて、登録が可能か否かを判断する処理を� ��に1つずつ行うために、処理対象として選択 される1つの候補日程が記憶される。追加参� �者スケジュール記憶エリア240には、前述の� �人スケジュールDB1022から取得された、新規� �ベントの追加参加者候補のスケジュール情� �が記憶される。選択候補記憶エリア241には� �追加参加者候補のうち、1つの必須参加者条� ��に対して最終的な候補として選択される1名 の選択候補のパーソナルデータが記憶される 。エラーフラグ記憶エリア242には、エラーの 有無を示すエラーフラグが記憶される。

 次に、図7~図14を参照して、各ユーザ端末 20で行われるスケジュール調整処理について� ��明する。説明の便宜上、以下では、ユーザ� ��末21においてユーザ210(AA)が新規イベント情� ��の入力を行ったものとして説明するが、他� ��ユーザ端末22、23等で処理が行われる場合も 同様である。図7~図10の各処理は、記憶装置20 2に記憶されたスケジュール調整プログラム20 21(図5参照)に従って、CPU2011が実行する。

 ユーザ端末21でスケジュール調整プログ� �ム2021(図5参照)が起動され、図7に示すメイン 処理が開始されると、CPU2011はまず、新規イ� �ントに関する情報を入力するための新規ス� �ジュール入力画面51(図12参照)をユーザ端末21 のディスプレイ204に表示させる(S11)。

 図12の新規スケジュール入力画面51を参照 して、このとき入力される新規イベント情報 について説明する。なお、新規スケジュール 入力画面51を介して入力される新規イベント� ��情報を総称して、「新規イベント情報」と� ��うものとする。図12に示すように、新規ス� �ジュール入力画面51には、区分欄511、内容欄 512、日時欄513、所要時間欄514、場所欄515、お よび参加者欄516が設けられている。区分欄511 には、「会議」、「外出」、「出張」の3区� �に対応するチェックボックスが設けられて� �り、ユーザ200は、これらのいずれか1つをチ� ��ックすることにより、新規イベントの区分� ��選択を行うことができる。内容欄512には、� ��規イベントの内容が入力される。本実施形� ��では、「内容」として会議の名称が入力さ� ��る場合を例として説明する。日時欄513では� ��新規イベントの開催希望日時が指定される� ��日時欄513には、特定の開始日時を指定する� ��めの指定日時欄5131と、日時を特定できない 場合に、一定の幅をもたせて、「この期間内 ならばよい」という期間を特定するための指 定期間欄5132が設けられている。所要時間欄51 4には、新規イベントの所要時間が入力され� �。場所欄515には、開催希望場所が入力され� �。参加者欄516には、新規イベントへの参加� �要請するユーザ200の氏名が入力される。参� �者欄516は、複数の氏名を入力できるように� �複数の入力欄5161~5166にそれぞれ分けられて� �る。図12の入力例では、区分欄511に「会議」 が、内容欄512に「予算会議」が、指定日時欄 5131に「2007年04月16日 10:00」が、所要時間欄51 4に「1時間」が、参加者欄5161~5163に「AA」お� �び「CC」が、それぞれ入力されている。なお 、参加者欄5161に入力された「AA」は入力者の 「ユーザ210」である。また、場所欄515には入 力されたデータがなく、会議の開催場所は特 に指定されていない状態である。

 さらに、新規スケジュール入力画面51の� �下には、「設定」ボタン517および「キャン� �ル」ボタン518が設けられている。「設定」� �タン517がクリックされると、入力した情報� �確定され(S12:YES)、RAM2013の新規イベント情報� ��憶エリア231に記憶される(S13)。本実施形態� �は、所要時間欄514および参加者欄516は必須� �力項目とされている。よって、これらの項� �のいずれかに入力がされないまま「設定」� �タン517がクリックされると、エラー音が発� �られ、次の処理には進むことはできない。� �方、「キャンセル」ボタン518がクリックさ� �た場合には(S12:NO)、入力された新規イベント 情報は無効とされ、ディスプレイ204の表示が 、未入力状態の新規スケジュール入力画面51� ��戻る(S11)。

 新規イベント情報の入力が確定され(図7� �S12:YES)、新規イベント情報記憶エリア231に記 憶されると(S13)、CPU2011は、新規イベント情報 に内容、すなわち、会議の名称が含まれてい るか否かを判断する(S14)。内容が含まれてい� ��ければ(S14:NO)、新規イベントの内容に応じ� �追加参加者の要否判断を行うことができな� �。よって、CPU2011は、追加参加者はないと決� ��して(S16)、後述するスケジュール決定処理(S 30)に移る。一方、例えば、図12に示すように� ��規イベント情報が入力された場合には、新� ��イベント情報記憶エリア231に記憶された新� ��イベント情報には、内容として「予算会議� ��が含まれている(S14:YES)。このような場合に� ��、CPU2011は参加者確認処理(S20)に移る。

 図8を参照して、参加者確認処理(S20)の詳� ��について説明する。参加者確認処理では、� ��力時に指定された参加者のみで、新規イベ� ��トの内容に対応する必須参加者条件(図4参� �)が満たされているか否かが判断され、満た� ��れてない場合には、追加参加者候補が抽出� ��れる。

 図8に示す処理が開始されると、CPU2011は� �ず、サーバ10の記憶装置102に記憶された必須 属性DB1025にアクセスし、必須属性DB1025に、新 規イベント情報の内容に対応する必須参加者 条件が記憶されているか否かを判断する(S21)� ��例えば、新規イベント情報記憶エリア231に� ��規イベントの内容として「予算会議」が記� ��されている場合、必須属性DB1025には、図4に 示すように「予算会議」に対応する必須参加 者条件が記憶されている(S21:YES)。したがって 、この場合、CPU2011は、必須属性DB1025から「� �算会議」に対応する必須参加者条件を取得� �、RAM2013の必須参加者条件記憶エリア232に記� ��させる(S22)。具体的には、「部署:財務部、� ��職レベル:何でもよい、職種:経理」および� �部署:入力者と同じ、役職レベル:1、職種:何� ��もよい」の2つの必須参加者条件が、このと き必須参加者条件記憶エリア232に取得される 。

 その後、CPU2011は、サーバ10の記憶装置102� ��記憶されたパーソナルDB1024にアクセスし、� ��規イベント情報記憶エリア231に記憶された� ��規イベントの参加者のパーソナルデータを� ��得して、RAM2013の参加者情報記憶エリア233に 記憶させる(S23)。例えば、図12に示すように� �規イベント情報が入力された場合には、参� �者である「AA」および「CC」のパーソナルデ� ��タが、参加者情報記憶エリア233に取得され� ��。なお、AAのパーソナルデータは前述した� �うに図3の通りであり、CCのパーソナルデー� �は図14の通りであるものとする。すなわち、 CCは、A社の財務部のマネージャー(役職レベ� �:3)であり、職種は経理である。

 次いでCPU2011は、必須参加者条件記憶エリ ア232および参加者情報記憶エリア233にそれぞ れ取得された必須参加者条件および参加者の パーソナルデータを参照して、入力時に指定 された参加者の属性が、必須参加者条件をす べて満たしているか否かを判断する(S24)。な� ��、以下では入力者の属性については考慮し� ��いものとして説明するが、入力者の属性に� ��いて考慮してもよい。この例では、AAは入� �者(ユーザ210)であるため、CCの属性である部� ��、役職レベルおよび職種のみが、「部署:財 務部、役職レベル:何でもよい、職種:経理」� ��よび「部署:入力者と同じ、役職レベル:1、� ��種:何でもよい」を満たすか否かの判断に用 いられる。RAM2013に記憶されているCCの部署、 役職レベルおよび職種は、図14に示すように� ��それぞれ「財務部」、「3」、「経理」であ る。よって、CCの属性は、前述した2つの必須 参加者条件のうちの1つである「部署:財務部� ��役職レベル:何でもよい、職種:経理」を満� �している。しかし、CC以外に考慮される参加 者がないため、もう1つの必須参加者条件で� �る「部署:入力者と同じ、役職レベル:1、職� �:何でもよい」は満たされていない。したが� ��て、このような場合、CPU2011は、必須参加者 条件がすべて満たされてはいないと判断し(S2 4:NO)、後述するように、必須参加者条件を満� ��す他のユーザ200を追加参加者として選択す� ��処理を行う。一方、入力時の参加者のみで� ��その新規イベントの内容に対応する必須参� ��者条件が満たされている場合には(S24:YES)、� ��加者を追加する必要はない。よって、CPU2011 は、追加参加者はないと決定し(S29)、図7のメ イン処理に戻る。

 S24において、必須参加者条件がすべて満� ��されてはいないと判断した場合(S24:NO)、CPU20 11は、不足している(満たされていない)必須� �加者条件を特定する(S25)。前述の例では、「 部署:入力者と同じ、役職レベル:1、職種:何� �もよい」が不足している必須参加者条件と� �て特定され、RAM2013の不足条件記憶エリア234� ��記憶される。次いでCPU2011は、サーバ10の記� ��装置102のパーソナルDB1024にアクセスし、S25� ��特定された必須参加者条件を満たす任意の� ��ーザ200を選択し(S26)、追加参加者候補に決� �して、RAM2013の追加参加者候補記憶エリア235� ��記憶させる(S27)。前述の例では、入力者で� �るAA(ユーザ210)の部署は、図3に示す通り「開 発部」であり、この情報がS23で取得され、参 加者情報記憶エリア233に記憶されている。よ って、CPU2011は、パーソナルDB1024に記憶され� �パーソナルデータの中から、「部署:開発部� ��役職レベル:1」を満たすデータを選択し、� �のパーソナルデータを有するユーザ200を特� �する。なお、この例では、職種に関する必� �参加者条件は「何でもよい」なので、職種� �選択条件には含まれない。例えば、図13に示 すBB(ユーザ220)のパーソナルデータによれば� �BBの部署は「開発部」、役職レベルは部長ク ラスを示す「1」であるから、BBの属性は「部 署:開発部、役職レベル:1」を満たしている。 よって、このような場合には、BBが追加参加� ��候補として選択され(S26)、BBのパーソナルデ ータが追加参加者候補記憶エリア235に記憶さ れる(S27)。なお、S26において、不足している� ��件を満たすユーザ200が複数いる場合には、� ��れらの複数のユーザ200がすべて追加参加者� ��補として選択され(S26)、そのパーソナルデ� �タが追加参加者候補記憶エリア235に記憶さ� �る(S27)。その後、CPU2011は、図7のメイン処理� ��戻る。

 図7のS16において「追加参加者なし」と決 定されるか、またはS20において参加者確認処 理(図8参照)が行われた後、図7のメイン処理� �は、スケジュール決定処理が行われる(S30)。 その後、CPU2011は、スケジュール決定処理(S30) において決定された結果をディスプレイ204に 表示させ(S18)、メイン処理を終了する。以下� ��、スケジュール決定処理の詳細について、� ��9および図10を参照して説明する。スケジュ� ��ル決定処理では、新規イベント情報入力時� ��指定された参加者、および参加者確認処理( S20、図8)で選択された追加参加者候補のスケ� ��ュール情報に基づいて、新規イベントの開� ��日時および場所が決定される。

 図9に示すスケジュール決定処理が開始さ れると、CPU2011はまず、新規イベント情報記� �エリア231に記憶された新規イベント情報を� �照し、スケジュール調整の対象とする期間� �参加者を特定する。ここでいう「期間」と� �、具体的には、新規イベント入力時に、新� �スケジュール入力画面51の指定日時欄5131に� �いて特定の開始日時が入力されている場合� �は、開始日時に所要時間欄514で入力された� �要時間を加算した時間帯をいう。例えば、� �12の入力例では、開始日時として「2007年4月1 6日 10:00」が入力され、所要時間として「1時 間」が入力されているので、「2007年4月16日  10:00~11:00」が期間として特定される。また、� ��始日時はなく、指定期間欄5132で入力された 指定期間が新規イベント情報記憶エリア231に 記憶されている場合には、「期間」とは、そ の指定期間をいう。一方、開始日時も指定期 間も記憶されていない場合には、例えば、「 処理日から1週間」など、所定の期間を定め� �ばよい。CPU2011は、サーバ10の記憶装置102に� �憶された個人スケジュールDB1022にアクセス� �、前述のように特定された期間内の全参加� �のスケジュール情報を取得し、RAM2013の参加� ��スケジュール記憶エリア236に記憶させる(S31 )。例えば、図12の入力例では、「2007年4月16� � 10:00~11:00」の、AAおよびCCのスケジュール情 報が取得される。

 CPU2011は、サーバ10の記憶装置102に記憶さ� ��た会議室DB1023にアクセスし、前述のように� ��定された期間内の会議室予約情報をRAM2013の 会議室情報記憶エリア237に取得し、記憶させ る(S32)。ここで取得される会議室予約情報は� ��新規イベント情報入力時に特定の会議室が� ��所として入力され、新規イベント情報記憶� ��リア231に記憶されていれば、その会議室の� ��報である。一方、1つの会議室が特定されて おらず、例えば、場所として「本社」のみが 記憶されているような場合は、会議室DB1023か ら、場所に「本社」が含まれる会議室の情報 が取得される。また、図12の入力例のように� ��何ら場所が入力されなかった場合は、新規� ��ベント情報記憶エリア231には場所は記憶さ� ��ていないため、全会議室の情報が取得され� ��。

 続いて、CPU2011は、新規イベントの開始日 時および所要時間と、S31で参加者スケジュー ル記憶エリア236に取得した参加者のスケジュ ール情報とを参照して、全参加者に新規イベ ントの所要時間分の共通の空きがあるか否か を判断する。取得したスケジュール情報中、 共通の空きがまったくない場合には(S33)、入� ��された条件では、新規イベントは登録不可� ��である。よって、後で入力者であるAA(ユー� ��210)にその旨を知らせるために、エラーフラ グをONとしてRAM2013のエラーフラグ記憶エリア 242に記憶させる(S39)。そして、続くS37におい� ��、CPU2011はエラーフラグがONであると判断し( S37:YES)、図7のメイン処理に戻ってディスプレ イ204にエラーメッセージを表示させてから(S1 8)、処理を終了する。

 一方、参加者に所要時間分の共通の空き� ��あれば(S33:YES)、S32で会議室情報記憶エリア2 37に取得された会議室予約情報を参照して、� ��の時間帯に会議室に空きがあるか否かを判� ��する(S34)。会議室にまったく空きがない場� �には(S34:NO)、前述の場合と同様に、エラーフ ラグをONとしてエラーフラグ記憶エリア242に� ��憶させる(S39)。そして、続くS37において、CP U2011はエラーフラグがONであると判断し(S37:YES )、図7のメイン処理に戻ってディスプレイ204� ��エラーメッセージを表示させてから(S18)、� �理を終了する。一方、会議室に空きがある� �判断した場合には(S34:YES)、CPU2011は、新規イ� ��ントを登録可能な日時と場所の組合せであ� ��候補日程を選定し、RAM2013の候補日程記憶エ リア238に記憶させる(S35)。このとき、新規イ� ��ントを登録可能な日時と場所の組合せが複� ��あれば、例えば「4月16日 10:00~11:00 会議室1 」および「4月17日 14:00~15:00 会議室3」のよ� �に、複数の候補日程が選定されることにな� �。候補日程を選定した後(S35)、CPU2011は、追� �参加者決定処理(S70)に移る。

 図10および図11を参照して、追加参加者決 定処理(図9、S70)の詳細について説明する。追 加参加者決定処理では、前述の参加者確認処 理(図7、S20および図8)において選択された追� �参加者候補のスケジュール情報も考慮して� �追加参加者1名が決定されるとともに、新規� ��ベントの開催日程が決定される。

 図10に示す追加参加者決定処理が開始さ� �ると、CPU2011はまず、前述のように選択され( 図9、S35)、候補日程記憶エリア238に記憶され� ��いる候補日程のうち、最も早い日時の候補� ��程を処理対象日程として選択し、RAM2013の処 理対象日程記憶エリア239に記憶させる(S71)。� ��補日程記憶エリア238に候補日程が1つしか記 憶されていない場合には、その候補日程が選 択される。また、最も早い日時の候補日程が 複数ある場合には、例えば、場所とされてい る会議室が会議室DB1023で最先に登録されてい る候補日程を選択すればよい。

 次いで、CPU2011は、追加参加者候補記憶エ リア235を参照して、追加参加者候補が記憶さ れているか否かを判断する(S72)。追加参加者� ��補が記憶されていなければ(S72:NO)、これ以� �他のユーザ200のスケジュールを考慮する必� �はないため、CPU2011は、図9のスケジュール決 定処理に戻る。この場合、エラーフラグはON� ��して記憶されていない(図9、S37:NO)。よって� ��CPU2011は、図10のS71で選択され、処理対象日� ��記憶エリア239に記憶された処理対象日程の� ��時と場所を新規イベントの開催日時および� ��所としてスケジュールを決定する(S38)。さ� �に、CPU2011は、サーバ10の個人スケジュールDB 1022にアクセスする。処理対象日程記憶エリ� �239に記憶されている日時と場所、および新� �イベント情報記憶エリア231に記憶されてい� �新規イベント情報の区分、参加者、内容等� �、新規イベントの各参加者のスケジュール� �報として新たに個人スケジュールDB1022に登� �される(S39)。例えば、図12の入力例の場合、� ��加者であるAA(ユーザ210)およびCC(ユーザ230)� �スケジュール情報が、個人スケジュールDB102 2に登録される。また、CPU2011は、サーバ10の� �議室DB1023にもアクセスし、同様にして、決� �された日程の会議室予約情報を新たに登録� �る(S39)。その後、CPU2011は、図9のスケジュー� ��決定処理を終了し、図7のメイン処理に戻っ てディスプレイ204に決定したスケジュールを 表示させてから(S18)、メイン処理を終了する� ��

 一方、図10のS72において、追加参加者候� �記憶エリア235に追加参加者候補が記憶され� �いると判断した場合には(S72:YES)、CPU2011は、� ��ーバ10の記憶装置102の個人スケジュールDB102 2にアクセスする。処理対象日程の日時およ� �その前後(例えば、前後1時間)の追加参加者� �補のスケジュール情報が個人スケジュールDB 1022から取得され、RAM2013の追加参加者スケジ� ��ール記憶エリア240に記憶される(S73)。追加� �加者候補が複数記憶されている場合には、� �べての追加参加者候補のスケジュール情報� �取得される。

 次いでCPU2011は、追加参加者スケジュール 記憶エリア240を参照して、追加参加者候補の いずれかのスケジュールが処理対象日程の日 時に空いているか否かを判断する(S76)。これ� ��、追加参加者として選択された場合に、ス� ��ジュールの変更が必要なく、特に支障がな� ��ユーザ200を優先的に選択するための判断で� ��る。追加参加者候補のいずれにも空きがな� ��場合には(S76:NO)、追加参加者候補記憶エリ� �235に記憶された追加参加者候補のパーソナ� �データが参照される。役職レベルが最下位� �追加参加者候補が1名選択され、選択候補と� ��てRAM2013の選択候補記憶エリア241に記憶され る(S93)。役職レベルが最下位の追加参加者候� ��を選択するのは、役職レベルが高いユーザ2 00ほど多忙であることが多いため、新たにス� ��ジュールが追加された場合に、より支障が� ��ないと思われる候補を選択する趣旨である� ��前述したように、本実施形態では、役職レ� ��ルは、小さい数字ほど上位の役職を示す1~5� ��での数字である。よって、例えば役職レベ� ��が「5」の追加参加者候補がいれば、その追 加参加者が選択される。役職レベルが最下位 の追加参加者候補が複数いる場合には、例え ば、識別コード(社員コード)が最も小さい追� ��参加者候補を選定すればよい。もともと追� ��参加者候補が1名しか記憶されていない場合 には、その追加参加者候補が選択される。こ のようにして、追加参加者候補のうち1名の� �を選択候補として選択した後(S93)、CPU2011は� �選択候補の利用するユーザ端末20に対して、 処理対象日時にすでに登録されている別のイ ベントである登録イベントを、他の日時に移 動するように依頼する(S94)。

 登録イベントの移動依頼に対して、選択� ��補の利用するユーザ端末20から、了承でき� �い旨の返答を受けた場合には(S95:NO)、CPU2011� �、追加参加者スケジュール記憶エリア240か� �、選択候補のスケジュール情報を消去して� �候補から除外する(S96)。その後、可能であれ ば他の追加参加者候補に登録イベントの移動 依頼を行うために、CPU2011は、追加参加者ス� �ジュール記憶エリア240を参照して、すべて� �追加参加者候補について、登録イベント移� �可否の確認が済んだか否かを判断する(S97)。 具体的には、追加参加者スケジュール記憶エ リア240に記憶されているスケジュール情報が まだあれば、まだすべての追加参加者候補に ついて確認が完了していないと判断される(S9 7:NO)。よって、この場合、CPU2011は、S93に戻り 、この時点でまだ記憶されている追加参加者 候補のうち、役職レベルが最下位の候補を新 たに選択候補として選択し、前述のS93~S97の� �理を繰り返す。

 その後、すべての追加参加者候補につい� ��確認が済み、追加参加者スケジュール記憶� ��リア240に記憶されているスケジュール情報� ��なくなると(S97:YES)、現在の処理対象日時で� ��、新規イベントを登録可能な追加参加者候� ��がいない状態となる。そこで、CPU2011は、日 時の変更が可能か否かを判断する(S98)。具体� ��には、CPU2011は、候補日程記憶エリア238に、 現在の処理対象日程の日時と異なる日時の候 補日程が記憶されていれば、日時変更は可能 であると判断する(S98:YES)。この場合CPU2011は� �S71に戻り、日時が異なる候補日程のうち最� �早い日時のものを選択して処理対象日程と� �、前述の処理を繰り返す。その結果、いず� �の候補日程についても追加参加者候補の調� �がつかないと、最終的にS98においてそれ以� �の日時変更は不可能と判断され(S98:NO)、エラ ーフラグがONとされて、エラーフラグ記憶エ� ��ア242に記憶される(S99)。CPU2011は、図10の追� �参加者決定処理を終了して図9のスケジュー� ��決定処理に戻り、S37において、エラーフラ� ��がONであると判断する(S37:YES)。よって、CPU20 11は、そのまま図9のスケジュール決定処理も 終了し、図7のメイン処理に戻ってディスプ� �イ204にエラーメッセージを表示させてから(� ��7、S18)、メイン処理を終了する。

 一方、初回または何度目かの処理におい� ��、処理対象日程の日時に空きのある追加参� ��者候補がいると判断した場合(S76:YES)、CPU2011 は、それが複数か否かを判断する(S77)。追加� ��加者候補が複数いる場合には(S77:YES)、CPU2011 は、追加参加者スケジュール記憶エリア240を 参照し、処理対象日程前後のスケジュールが 空いている候補を選択候補として選択し、選 択候補記憶エリア241に記憶させる(S78)。これ� ��、自動的に追加参加者を設定する場合に、� ��るべく多忙でないユーザ200を選択するため� ��ある。前後のスケジュールが空いている候� ��が複数ある場合には、例えば、識別コード( 社員コード)が最も小さい追加参加者候補を� �択すればよい。続いて、CPU2011は、S78で選択� ��た選択候補をディスプレイ204に表示させて� ��ユーザ210(AA)の確認を促す(S79)。このときデ� ��スプレイ204には、選択候補とともに、「了� ��」、「変更」、および「削除」の3つのボタ ンが合わせて表示される。一方、処理対象日 程の日時に空きのある追加参加者候補が1名� �った場合は(S77:NO)、CPU2011は、その候補を選� �候補として選択候補記憶エリア241に記憶さ� �、ディスプレイ204に表示させる(S79)。また、 処理対象日程の日時に空きのある候補がなく (S76:NO)、前述のように、役職レベルが最下位� ��候補に対して登録イベントの移動を依頼し� ��結果、了承が得られた場合には(S93、S94、S95 :YES)、同様に、その候補が表示される(S79)。� �実施形態では、選択候補は、各必須参加者� �件について1名が選択される。すなわち、必� ��参加者条件が複数ある場合には、複数名の� ��択候補が選択されることになる。1名だけで はなく、追加参加者候補をすべて参加者とし て追加するのが適切な場合には、S77およびS78 の処理は省略し、すべての追加参加者候補を 複数の選択候補としてS79で表示させてもよい 。

 選択候補がディスプレイ204に表示された� ��(S79)、入力者確認処理(S80、図11)が行われる� ��図11を参照して、入力者確認処理について� �明する。図11に示す入力者確認処理では、ま ず、ユーザ210(AA)がディスプレイ204に表示さ� �た選択候補を確認し、この候補を参加者と� �て追加することを了承する「了承」ボタン� �選択したか否かが判断される(S81)。ユーザ210 (AA)が「了承」ボタンを選択した場合(S81:YES)� �CPU2011は、選択候補記憶エリア241に記憶され� ��いる選択候補を追加参加者として決定する( S82)。その後、CPU2011は図9のスケジュール決定 処理に戻り、エラーフラグ記憶エリア242にエ ラーフラグがONとして記憶されているか否か� ��判断する。この場合、エラーフラグはONと� �れていないため(S37:NO)、CPU2011は、図10のS71で 選択され、処理対象日程記憶エリア239に記憶 されている処理対象日程の日時と場所を新規 イベントの開催日時および場所としてスケジ ュールを決定する(S38)。さらに、CPU2011は、サ ーバ10の記憶装置102の個人スケジュールDB1022� ��アクセスする。処理対象日程記憶エリア239� ��記憶されている日時と場所、新規イベント� ��報記憶エリア231に記憶されている新規イベ� ��ト情報の区分、参加者、および内容等、さ� ��に選択候補記憶エリア241に記憶されている� ��択候補に基づいて、スケジュール情報が新� ��に登録される(S39)。具体的には、例えば、� �12の例のように新規イベントの参加者として AA(ユーザ210)およびCC(ユーザ230)が入力され、� ��の後の処理で追加参加者としてBB(ユーザ220) が決定された場合、AA、BB、およびCCのスケジ ュール情報が新たに登録される(S39)。また、C PU2011は、サーバ10の会議室DB1023にもアクセス� ��、同様にして、会議室予約情報を新たに登� ��する(S39)。その後、CPU2011は、図9のスケジュ ール決定処理は終了し、図7のメイン処理に� �ってディスプレイ204に決定したスケジュー� �を表示させてから(S18)、メイン処理を終了す る。

 一方、S79においてディスプレイ204に表示� ��れた選択候補を確認した結果、ユーザ210(AA) が、追加参加者を他のユーザ200に変更するよ うに指示する「変更」ボタンを選択する場合 がある。このような場合、例えば、CPU2011は� �ディスプレイ204に、必須参加者条件を満た� �その他の追加参加者候補をリスト表示させ� �。ユーザ210は、リストから所望の追加参加� �候補を選択することにより、変更入力を行� �。変更入力を受け付けると(S81:NO→S86:YES)、CP U2011は、選択候補記憶エリア241に変更後の追� ��参加者候補を選択候補として記憶させる。� ��らに、CPU2011は、追加参加者スケジュール記 憶エリア240に記憶されている変更後の選択候 補のスケジュール情報を参照して、現在の処 理対象日程の日時にスケジュールの空きがあ るか否かを判断する(S87)。変更後の選択候補� ��スケジュールに空きがあれば(S87:YES)、CPU2011 はこの候補を追加参加者として決定し(S82)、� ��のまま図10の追加参加者決定処理に戻り、� �らに図9のスケジュール決定処理に戻る。一� ��、変更後の選択候補のスケジュールに空き� ��なければ(S87:NO)、この候補の利用するユー� �端末20に対して、この日時にすでに登録され ている別のイベントである登録イベントを、 他の日時に移動するように依頼する(S88)。了� ��する旨の返答を受けた場合には(S89:YES)、そ� ��まま図10の追加参加者決定処理に戻り、さ� �にCPU2011はこの候補を追加参加者として決定� ��(S82)、図9のスケジュール決定処理に戻る。� ��承できない旨の返答を受けた場合には(S89:NO )、ユーザ210の希望する変更は不可能である� �よって、CPU2011はエラーフラグをONとしてエ� �ーフラグ記憶エリア242に記憶させてから(S90) 、そのまま図10の追加参加者決定処理に戻り� ��さらに図9のスケジュール決定処理に戻る。

 また、S79においてディスプレイ204に表示� ��れた選択候補を確認した結果、ユーザ210(AA) が「削除」ボタンを選択した場合には(S91:YES) 、CPU2011は、追加参加者を決定することなく� �そのまま図10の追加参加者決定処理に戻り、 さらに図9のスケジュール決定処理に戻る。� �れは、例えば、必須参加者条件として入力� �と同じ部署の部長クラス(役職レベル1)が要� �される場合であっても、このときに限って� �長に会議での決裁が一任されている場合の� �うに、追加参加者が不要な場合もある。そ� �で、このような場合には自動的に追加参加� �を決定せず、臨機応変な対応を可能とする� �めである。追加参加者候補を変更(S86:YES)ま� �は削除し(S91:YES)、図9のスケジュール決定処� ��に戻った後は、いずれの場合も前述と同様� ��処理が行われる。選択候補の了承、変更、� ��よび削除のいずれも指示入力がされない間� ��(S81:NO、S86:NO、S91:NO)、CPU2011は、何らかの指� ��入力がされるまで監視を続ける。

 以上に説明したように、本実施形態では� ��イベントの内容毎に、参加者の属性として� ��須とされる必須参加者条件が予め定められ� ��その対応関係が必須属性DB1025に記憶されて� ��る。また、スケジュール調整システム1を利 用する全ユーザ200の属性は、パーソナルDB1024 に記憶されている。新規イベント情報が入力 されると、入力された新規イベントの内容に 対応する必須参加者条件が必須属性DB1025から 取得される。入力された参加者だけではこの 条件を満たすことができないと判断されると 、パーソナルDB1024を参照して、条件を満たす 属性を有する追加参加者が自動的に選択され る。したがって、新規イベント情報の入力者 が、本来新規イベントへの出席が必要なユー ザ200を参加者として入力し忘れた場合でも、 適切な参加者を含めたスケジュール調整を行 うことができる。また、入力時に新規イベン トの内容さえ入力すれば、細かい条件設定を 行わなくても、適切な参加者を追加すること ができる。

 また、必須参加者条件として要求される� ��加者の属性には、所属、役職(役職レベル)� �または職種に関する情報が含まれている。� �たがって、イベントの内容に応じて、適切� �所属の担当者、決裁権限を有する責任者に� �当する役職、または専門の職種等を考慮し� �、必須参加者条件を予め定めておくことが� �きる。また、これらの属性に関する情報は� �特に企業等では通常管理されている情報な� �で、新たな情報としてパーソナルDB1024登録� �る手間も必要なく、データ量が徒に増大す� �虞がない。

 次に、図15~図17を参照して、前述の実施� �態と異なる点を主として、別の実施形態に� �いて説明する。なお、図15および図16の処理� ��、前述の実施形態と同様、記憶装置202に記� ��されたスケジュール調整プログラム2021(図5� ��照)に従って、CPU2011が実行する。

 前述の実施形態では、予めイベントの内� ��毎に定められた必須参加者条件を記憶する� ��須属性DB1025のみを参照して、新規イベント� ��報入力時に指定された参加者が必須参加者� ��件を満たしているか否かが判断されていた� ��本実施形態は、新規イベント情報の入力時� ��、ユーザ200が必須参加者条件を適宜変更入� ��できるように構成されている点に特徴を有� ��る。本実施形態に係るスケジュール調整シ� ��テム1、およびその構成要素であるサーバ10� ��よびユーザ端末20の構成は、前述の実施形� �と同一であるため、説明を省略し、以下に� �本実施形態においてユーザ端末20で行われる スケジュール調整処理について説明する。

 ユーザ端末20においてスケジュール調整� �ログラム2021が起動され、図15に示す本実施� �態に係るメイン処理が開始されると、CPU2011� ��まず、ディスプレイ204に新規スケジュール� ��力画面52(図17参照)を表示させる(S40)。図17に 示すように、本実施形態でディスプレイ204に 表示される新規スケジュール入力画面52には� ��前述の実施形態に係る新規スケジュール入� ��画面51(図12参照)の各種の入力欄511~516の他、 必須属性欄521が設けられている。必須属性欄 521は、入力者であるユーザ210(AA)が、入力中� �新規イベントに参加が必須とされる必須参� �者の属性(必須参加者条件)を、必要に応じて 指定するための欄である。必須属性欄521は、 さらに部署欄5211、役職欄5212、および職種5213 に区分されている。各欄には、「何でもよい 」、「入力者と同じ」、および「指定」の3� �類のチェックボックスが設けられている。� �指定」チェックボックスの横には、具体的� �指定内容を入力する入力ボックスも設けら� �ている。

 必須属性欄521から入力が可能な必須参加� ��条件である部署、役職、および職種は、前� ��の実施形態で説明した、必須属性DB1025(図2� �照)に登録された必須参加者条件(図4参照)に� ��応している。新規スケジュール入力画面52� �表示された時点では、必須属性欄521のチェ� �クボックスはすべて「何でもよい」がチェ� �クされた状態で表示される。しかしその後� �ユーザ210により内容欄512に内容が入力され� �と(S41:YES)、サーバ10の必須属性DB1025が参照さ れ、入力された内容に対応する必須参加者条 件の有無が判断される(S42)。対応する必須参� ��者条件が必須属性DB1025に記憶されていれば( S42:YES)、CPU2011はその条件をRAM2013に読み出し� �(S43)、新規スケジュール入力画面52の部署欄5 211、役職欄5212、および職種5213に表示させる( S44)。

 例えば、内容欄512において、内容として� ��定例会」が入力されると、必須属性DB1025(図 4参照)から、「定例会」に対応する必須参加� ��条件、すなわち、部署として「入力者と同� ��」、役職レベルとして「何でもよい」、職� ��として「入力者と同じ」が読み出される(S43 )。そして、新規スケジュール入力画面52の部 署欄5211、役職欄5212、および職種5213において 、それぞれ「入力者と同じ」、「何でもよい 」、「入力者と同じ」のチェックボックスが チェックされた状態となる(S44)。一方、例え� ��「事務担当者打合せ」等のように、必須属� ��DB1025(図4参照)に必須参加者条件が登録され� ��いない内容が内容欄512に入力された場合に� ��(S42:NO)、必須属性欄521はすべて「何でもよ� �」が表示された状態のままとなる。ユーザ21 0は、必須属性欄521が初期表示(すべて「何で� ��よい」)の場合、および前述のように自動入 力がされた場合、いずれの場合にも、必須属 性欄521において、所望の属性を入力すること ができる。例えば、図17の例では、内容とし� ��「戦略会議」が入力されている。よって、� ��力時には、必須属性DB1025(図4参照)から読み� ��した「戦略会議」に対応する必須参加者条� ��である部署、役職レベル、職種として「入� ��者と同じ」、「指定:2以上」、「何でもよ� �」のチェックボックスがチェックされた状� �となる。その後、ユーザ210が、役職レベル� �「レベル2:上級職」に変更し、職種を「企画 」に変更すると、図17のような状態となる。� ��のように、本実施形態では、入力された新� ��イベントの内容が必須属性DB1025(図4参照)に� ��録されているものであれば、対応する必須� ��加者条件が表示されるが、その都度、ユー� ��210の所望の条件を設定することもできる。

 前述の実施形態の場合と同様に、新規ス� ��ジュール入力画面52においてユーザ210によ� �入力が完了し、「設定」ボタン517が選択さ� �て入力が確定されると(S45:YES)、入力された� �規イベント情報がRAM2013の新規イベント情報� ��憶エリア231に記憶される(S46)。本実施形態� �は、必須参加者条件は、ここで新規スケジ� �ール入力画面52を介して入力された他の情報 とともに新規イベント情報として確定され、 記憶される。続いてCPU2011は、新規イベント� �報記憶エリア231を参照して、必須参加者条� �が指定されているか否かを判断する(S47)。具 体的には、必須参加者条件の部署、役職、お よび職種がいずれも「何でもよい」として記 憶されている場合以外は、新規イベントの内 容に対応する必須参加者条件が必須属性DB1025 から読み出されたか、またはユーザ210によっ て所望の条件が入力されている。したがって 、CPU2011は、このような場合、必須参加者条� �が指定されていると判断して(S47:YES)後述す� �参加者確認処理を行う(S50)。一方、必須参加 者条件の部署、役職、および職種がいずれも 「何でもよい」として記憶されている場合、 すなわち、必須参加者条件が指定されていな い場合には(S47:NO)、CPU2011は、「追加参加者な し」と決定する(S48)。いずれの場合も、CPU2011 は続いてスケジュール決定処理(S30、図9)を行 い、結果をディスプレイ204に表示させてから (S49)、図15のメイン処理を終了する。スケジ� �ール決定処理については、前述の実施形態� �処理(図9参照)と同様のため、ここでは説明� �省略する。

 本実施形態に係る参加者確認処理(S50)に� �いて、図16を参照して以下に説明する。本実 施形態では、前述したように、メイン処理に おいて新規イベント情報の入力が確定された 段階で、必須参加者条件が新規イベント情報 の一部としてすでに新規イベント情報記憶エ リア231に記憶されている。そこで、図16の参� ��者確認処理が開始されると、CPU2011はまず、 サーバ10のパーソナルDB1024にアクセスし、新� ��イベント情報記憶エリア231に記憶された新� ��イベントの参加者のパーソナルデータを、� ��加者情報記憶エリア233に記憶させる(S51)。� �の後のS52~S56の処理は、前述の実施形態の参� ��者確認処理(図8参照)のS24~S29の処理と同様で あるため、説明を省略する。参加者確認処理 を通じて、前述の実施形態と同様、必須属性 DB1025から読み出された、またはユーザ210によ って入力された必須参加者条件が入力された 参加者だけでは満たされない場合、不足して いる条件を満たす適切な追加参加者が自動的 に選択される。

 以上に説明したように、本実施形態では� ��前述の実施形態と同様、イベントの内容毎� ��参加者の属性として必須とされる必須参加� ��条件が予め定められ、その対応関係が必須� ��性DB1025に記憶されている。入力された新規� ��ベントの内容に対応する必須参加者条件が� ��須属性DB1025から取得され、新規スケジュー� ��入力画面52に表示された後、入力者である� �ーザ200は、必須参加者条件を構成する各属� �について、所望の条件に変更することがで� �る。したがって、新規イベント情報を入力� �る際、新規イベント参加者条件を臨機応変� �設定することができる。

 なお、本開示に係るスケジュール調整装� ��およびスケジュール調整プログラムは、前� ��した2つの実施形態に限定されるものではな く、各種の変形が可能なことは言うまでもな い。

 例えば、前述の実施形態では、ネットワ� ��クを介して接続されたサーバ10とユーザ端� �20のうち、ユーザ端末20の記憶装置202にスケ� ��ュール調整プログラム2021が記憶されており 、ユーザ端末20が主なスケジュール調整機能� ��有している。しかしながら、サーバ10の記� �装置102に、スケジュール調整プログラム2021� ��記憶され、サーバ10においてスケジュール� �整処理が行われる構成であってもよい。こ� �場合、ユーザ端末20においてキーボード203等 を介して入力された新規イベント情報はサー バ10に送信され、サーバ10において、受信さ� �た新規イベント情報を基に、図7のS13以降の� ��理が行われる。S18において、スケジュール� ��定処理(図7、S30)の結果がディスプレイ104に� ��示される代わりに、結果を示す情報が入力� ��のユーザ端末20に送信されればよい。