(57)【要約】【課題】コンピューターの使い方に慣れていないユーザーがグループに属していても、当該グループのスケジュール情報の共有による生産性向上を図ること。【解決手段】サーバーが、当該表示指定１３ｂに応じた期間（月、週、日等）について前記予定関連テーブル２９に格納された前記要請データ及び前記通常予定データを検索し、要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールド１３ｅに記述し、当該期間内の日付のカレンダーフィールド１３ｅを有するカレンダーテーブル１３ｄを生成するカレンダー画面制御部１３を備えた。さらに、カレンダー画面制御部１３は、カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能１８を備えた。【選択図】        図１
2005004307.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、ユーザーに関するデータを格納するユーザーテーブルと、前記各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する予定関連テーブルとを備え、
前記サーバーが、
前記要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索し、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述して、当該期間内の日付のカレンダーフィールドを有するカレンダーテーブルを生成するカレンダー画面制御部とを備え、
このカレンダー画面制御部が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能を備えたことを特徴とするスケジュール管理支援システム。
【請求項２】
前記カレンダー画面制御部は、前記予定関連テーブルから読み出した要請データが複数ある場合には、当該要請データの１以上の項目を使用して、当該複数の要請データを並べ替える要請データソート機能を備えたことを特徴とする請求項１記載のスケジュール管理支援システム。
【請求項３】
前記要請データソート機能が、当該要請データの予定日時データを使用して、現在から未来に向けた順序に従って、当該複数の要請データを並べ替える機能を備えたことを特徴とする請求項２記載のスケジュール管理支援システム。
【請求項４】
前記カレンダー画面制御部は、前記予定関連テーブルから読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、前記オーナーによって第１候補とされた日時を当該要請表示エリアに記述する要請表示エリア内第１候補表示制御機能を備えたことを特徴する請求項１，２又は３記載のスケジュール管理支援システム。
【請求項５】
前記カレンダー画面制御部は、前記予定関連テーブルから読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、当該要請表示エリア内に全ての候補日の日時を記述する要請表示エリア内全候補表示制御機能を備えたことを特徴する請求項１，２又は３記載のスケジュール管理支援システム。
【請求項６】
前記カレンダー画面制御部が、前記要請データに候補日が複数定義されている場合には、一つの要請データについて一つの要請表示エリアを生成し、予め指定されたユーザーの要請表示エリア表示設定に従って、前記カレンダーフィールド又は前記要請表示エリア内の一方にのみ全ての候補日の日時を表示する機能を備えたことを特徴とする請求項１，２又は３記載のスケジュール管理支援システム。
【請求項７】
前記サーバーが、前記アポイントメントへの参加を要請された招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成する調整制御部を備え、
前記カレンダー画面制御部が、前記要請データ毎の要請表示エリアを、前記調整画面の表示指令を当該端末から送信する表示指令ボタンに設定する要請表示エリアボタン化制御機能を備えたことを特徴とする請求項１，２，３，４，５又は６記載のスケジュール管理支援システム。
【請求項８】
複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、ユーザーに関するデータを格納するユーザーテーブルと、アポイントメントのオーナーであるユーザーから参加が要請され当該アポイントメントの日時及び参加者の調整中である要請データと前記各ユーザーの通常予定である通常予定データとを格納する予定関連テーブルとを備え、
前記サーバーが、
前記要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索して当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述するカレンダー画面制御部を備え、
前記カレンダー画面制御部が、前記カレンダーフィールドへの記述の表示形式を、前記要請データと前記予定データとで異なる表示形式に設定する予定種類別表記設定機能を備えたことを特徴とするスケジュール管理支援システム。
【請求項９】
前記表示形式が要請データ及び予定データの時間表示等の色分けであることを特徴とする請求項８記載のスケジュール管理支援システム。
【請求項１０】
前記カレンダー画面制御部が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能を備えたことを特徴とする請求項８又は９記載のスケジュール管理支援システム。
【請求項１１】
前記カレンダー画面制御部が、前記予定関連テーブルから読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、前記オーナーによって第１候補とされた日時で要請データを前記カレンダーフィールドに記述するカレンダー内第１候補表示制御機能を備えたことを特徴とする請求項８又は９記載のスケジュール管理支援システム。
【請求項１２】
前記サーバーが、前記アポイントメントへの参加を要請された招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成し、入力される返信データを前記予定関連テーブルに格納する調整制御部を備え、前記カレンダー内第１候補表示制御機能が、当該返信データの格納後前記オーナーによる確定前の要請データについては、前記返信データにて参加と返信した候補日のうち当該招集ユーザーによって第１候補とされた日時にのみ要請データを前記カレンダーフィールドに記述する機能を備えたことを特徴とする請求項１１記載のスケジュール管理支援システム。
【請求項１３】
前記サーバーが、前記アポイントメントへの参加を要請された招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成し、入力される返信データを前記予定関連テーブルに格納する調整制御部を備え、前記カレンダー画面制御部が、当該返信データの格納後前記オーナーによる確定前の要請データについては前記返信データにて参加と返信した全ての候補日について当該要請データを当該候補日のカレンダーフィールドに記述する参加返信候補日表示制御機能を備えたことを特徴とする請求項８又は９記載のスケジュール管理支援システム。
【請求項１４】
複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、
前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納するユーザーテーブルと、
予定を識別する予定ＩＤ毎に、前記ユーザーＩＤと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データとを格納する予定メインテーブルと、
前記予定ＩＤ毎に、予定開始日時データと、予定終了日時データとを格納する通常予定テーブルと、
候補日順位毎の前記予定ＩＤ毎に、当該予定ＩＤのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーＩＤと、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納するアポイントメント予定テーブルとを備え、
前記サーバーが、
前記オーナーによって使用される端末からアポイントメントの要請を作成するための要請作成画面の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促す要請作成画面を生成する要請作成画面生成部と、
前記要請作成画面が生成されたときに前記オーナーによって使用される端末へ当該要請作成画面を送信し、当該オーナーによって当該要請作成画面に入力される要請データを受信して、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納すると共に、前記要請作成画面の他の各フィールドの内容を前記アポイントメント予定テーブルに格納する要請データ格納制御部と、
前記招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面を生成する調整画面生成部と、
前記調整画面が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面を送信し、当該招集ユーザーによって当該調整画面に入力される返信データを受信して、前記出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する返信データ格納制御部と、
前記オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブルを参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する確定処理制御部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、前記予定メインテーブルに格納された予定種類コードに応じて前記アポイントメント予定テーブルに格納された要請データ及び前記通常予定テーブルに格納された予定データとを当該期間を日毎に区切った各カレンダーフィールドに記述するカレンダー画面制御部を備え、
このカレンダー画面制御部が、
前記表示指定による期間と無関係に、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述させる要請表示制御機能と、
前記カレンダーフィールドへの記述の表示形式を、前記予定メインテーブルに格納された予定種別コード毎に異なる表示形式に設定する予定種類別表記設定機能とを備えたことを特徴とするアポイントメント調整支援システム。
【請求項１５】
前記表示形式が、前記予定種別コード毎の色分けであることを特徴とする請求項１４記載のアポイントメント調整支援システム。
【請求項１６】
前記返信データ格納制御部が、前記オーナーによって使用される端末から調整画面の表示指令を受信した場合には、前記アポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出すると共に、各招集ユーザーの出欠に関して強制調整操作がなされた場合には、当該オーナーによって強制調整操作された招集ユーザーの出欠を参加に確定し、当該招集ユーザーの通常予定テーブルに当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する強制調整制御機能を備えたことを特徴とする請求項１４又は１５記載のアポイントメント調整支援システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、スケジュール管理支援システムに関し、特に、サーバーと端末とを使用して各ユーザーのスケジュールの管理作業を支援するシステムに関する。
【０００２】
【従来の技術】
従来、企業や大学等では、会議や、研修会や、展示会への参加や、旅行などの予定の約束（アポイントメント）を、参加の候補者のスケジュールを調整しつつ、日時を確定する。参加を要請する主催者（オーナー）は、主催者から参加を要請される人（招集ユーザー）に参加を要請し、招集ユーザーからの出欠可否の返答などを参照して、最終的な日時を決定する。招集ユーザーは、自分個人の予定と、参加を要請されるアポイントメントとで日程を調整し、スケジュール管理用のソフトウエアや、手帳などを用いてスケジュールを管理する。
【０００３】
特許文献１では、スケジュール情報の共有を目的として、他のユーザーのスケジュールを参照する仕組みと、会議等の共通するスケジュールの決定を容易とする仕組みとが開示されている。この特許文献１の図７では、太い実線の両矢印で示されたスケジュールは開始時間及び終了時間が確定している個人スケジュールで、太い点線の矢印は開始時間又は終了時間の一方が確定している個人スケジュールで、太い中抜きの矢印は、会議等で確定した共通スケジュールで、太い中抜きの矢印で、“？”マークが付されているものは、会議等の主催者から通知された共通スケジュールで、返信をしていないスケジュールである。“？”マークが付されている未確定状態は、参加又は不参加の返信を行うことで確定する。
【０００４】
特許文献２では、各ユーザー個人のスケジュールと、複数のユーザーに共通する合計スケジュール（グループスケジュール）とをシステム的に管理する仕組みが開示されている。この特許文献２の段落００７３及び段落００７９には、通常のスケジュールと、合計スケジュールと一目で把握できるように、色などの表示属性をスケジュールの種類で変化させる手法が開示されている。
【０００５】
【特許文献１】
特開平５−１６５８３６号公報
【特許文献２】
特開２０００−５７２１７号公報
【特許文献３】
特開２００２−４９７２９号公報
【０００６】
【発明が解決しようとする課題】
上記各従来例では、招集ユーザーは、オーナーからアポイントメントの要請があったことに気がつきにくい、という不都合があった。すなわち、特許文献１及び２では、カレンダーの内部のみにグループスケジュールを表示するため、要請があった日付を含む月や週のカレンダーの表示を行わなければ、カレンダーを用いて要請に気づくことはない。そして、招集される側からすると、アポイントメントの要請を何時受信するかを予測することは困難で、また、その要請の日付が何時であるかを予測することも困難であるため、日常的な自分のスケジュールの確認作業とは別に、要請がないことを定期的に確認するなどの作業が必要となってしまう。
【０００７】
また、特許文献２では、合計スケジュールはオーナーによってすでに確定された予定であるため、元々の日程の調整は別途電子メールや電話等で行わなければならず、従って、この従来例では、日程の調整と日常的な自分のスケジュールの確認作業とは別に行わなければならない。特許文献１では、アポイントメントの要請に対して返信したときに予定が確定する仕組みであるため、複数の候補日を用いたアポイントメントの調整をシステム内で行うことができない。スケジュールの管理としては、複数の候補日が提案された要請が複数ある場合が複雑であり、このようなアポイントメントについて電子メール等を用いて日程調整するのは極めて煩雑な作業となる。
【０００８】
そして、候補日が複数ある要請と、候補日が一つである要請とが混在するような状況では、最終的にどの日付にどの予定が入ったかを管理するためには慎重で精緻な作業が必要となり、特に、コンピューターの使い方になれていないユーザーにとっては、負担の大きい作業となっていた。一方、特許文献１や２のように、グループ共通のスケジュールを個人のスケジュールと一体的に管理できるシステムでは、そのグループ内にコンピューターの使い方になれないユーザーがおり、システムに予定を確実に入力してもらえないと、スケジュール情報の共有による生産性向上の阻害要因となってしまう。
【０００９】
【発明の目的】
本発明は、スケジュールの管理に関して、コンピューターの使い方に慣れていないユーザーがグループに属していても、当該グループのスケジュール情報の共有による生産性向上を図ることができ、また、コンピューターを使い慣れたユーザーにとっても初心者向きのソフトウエアにあるような煩雑さを感じることのないスケジュール管理支援システムを提供することを、その目的とする。
【００１０】
本発明はまた、単一のアポイントメントの要請に複数の候補日が含まれており、最終的な候補日の選定をオーナーが行うようなアポイントメントの調整をもシステム内で実現することのできるスケジュール管理支援システムを提供することを、その目的とする。
【００１１】
【課題を解決するための手段】
本発明の発明者は、スケジュール管理用のソフトウエアは、確定した個人の予定を入力しておき、これを週単位や月単位で確認する、という使い方が初心者についても熟練者についても基本的且つ一般的であり、このスケジュールの確認作業は初心者も熟練者も日常的に行っていることに着目した。そして、この日常的なスケジュールの確認作業中に、アポイントメントの要請や候補日の確定などをユーザーに知らせることができれば、初心者に優しく、熟練者には手間いらずとなるシステムを提供できる、との着想を得た。
【００１２】
そこで、請求項１に係る本発明では、複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備えている。そして、データベースが、ユーザーに関するデータを格納するユーザーテーブルと、前記各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する予定関連テーブルとを備えている。
さらに、サーバーが、要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索し、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述して、当該期間内の日付のカレンダーフィールドを有するカレンダーテーブルを生成するカレンダー画面制御部とを備えている。
しかも、このカレンダー画面制御部が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能を備えている。これにより、前述した課題を解決する。
【００１３】
カレンダー画面制御部は、月表示、週表示等の表示指定に応じて、通常予定データと要請データとをカレンダーフィールドに記述し、表示指定による期間のカレンダーテーブルを生成する。そして、要請表示制御機能は、カレンダーテーブル外の要請表示エリアに要請データを記述する。従って、表示指定の期間と無関係に、必ず要請データがカレンダー画面に表示される。このため、カレンダー画面で表示させる期間外が予定日時である要請データの存在をユーザーに通知することができる。また、日常作業として確認すべき期間内については、要請データが通常予定データを併せてカレンダーフィールド内に表示される。このため、日常的なスケジュールの確認作業中にて、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面にて確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
【００１４】
【発明の実施の形態】
次に、本発明の実施の形態を説明する。
【００１５】
図１は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図であり、図２は本実施形態で使用するデータ構造の一例を示す説明図である。
図１を参照すると、本実施形態によるアポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。
【００１６】
そして、データベース２は、図２に示すように、予定関連テーブル２９と、ユーザーテーブル３０とを備えている。予定関連テーブル２９は、各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する。図２に示す例では、予定関連テーブル２９は、要請データ及び返信状態データを格納するアポイントメント予定テーブル３２と、確定した通常の予定データを格納する通常予定テーブルとを備える。
【００１７】
再度図１を参照すると、サーバー１０は、アポイントメント確定処理部１２と、カレンダー画面制御部１３とを備えている。アポイントメント確定処理部１２は、要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換する。この変換処理は、例えば、アポイントメント予定テーブル３２に格納された返信状態データから通常予定データを生成し、通常予定テーブル３４に格納する処理でもよい。この場合、確定した要請データ及び返信状態データはアポイントメント予定テーブルから削除する。
【００１８】
カレンダー画面制御部１３は、カレンダー画面１３ａ中に、表示指定１３ｂに応じてスケジュールを表示するカレンダーテーブル１３ｄを生成する。具体的には、カレンダー画面制御部１３は、端末１から送信されるカレンダー画面１３ａの表示指令及び表示指定１３ｂ（個人月、グループ週等）を受信したときに、まず、当該表示指定１３ｂに応じた期間（月、週、日等）について前記予定関連テーブル２９に格納された前記要請データ及び前記通常予定データを検索する。カレンダー画面制御部１３は、続けて、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールド１３ｅに記述し、当該期間内の日付のカレンダーフィールド１３ｅを有するカレンダーテーブル１３ｄを生成する。
【００１９】
本実施形態では特に、このカレンダー画面制御部１３が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリア（図３に示す例では、符号１３ｆ，１３ｇ，１３ｈ，１３ｉ及び１３ｊで示す領域）に前記要請データを記述する要請表示制御機能１８を備えている。カレンダー画面制御部１３が、要請データによる未確定の予定を通常予定と同様にカレンダーテーブル１３ｄに表示するため、ユーザーが日常作業として確認すべき期間内については、要請データの有無及び要請されている日付等を通常予定データと一体的に確認することができる。また、要請表示制御機能１８が、表示指定の期間と無関係に、必ず要請データをカレンダー画面に表示するため、毎日のスケジュールの確認を例えば週単位で行っているとしても、カレンダー画面１３ａ内の要請データ表示エリアを参照することで、数週間先や１，２ヶ月先の日付を予定とする要請データの受信の有無を日常的な作業中に確認することができる。
【００２０】
このため、日常的なスケジュールの確認作業中に、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面１３ａのみで確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを日常的に簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
【００２１】
図３に示すカレンダー画面は、Ｂ氏の個人カレンダー画面であり、符号１３ｂで示す表示指定は、個人で、且つ月単位である。Ｂ氏は現在３月として、次月である４月のスケジュールを表示している。Ｂ氏は、アポイントメントの要請を５つ受信しており、３月２４日及び２６日，５月２２日の要請については、４月中を期間としているカレンダーテーブル１３ｄには表示されない。カレンダー画面制御部１３は、４月２日と４月３日の要請データを、カレンダーテーブル１３ｄに表示する。
【００２２】
カレンダー画面制御部１３は、また、金曜日９：３０に毎週繰り返し開催される定例会議や、４月２１，２２日の出張予定などを通常予定テーブル３４から読み出して表示する。要請表示制御機能１８は、Ｂ氏を招集ユーザーとして指定されたアポイントメントの要請データをアポイントメント予定テーブル３２から読み出して、図３に示す例ではカレンダーテーブル１３ｄの図中左側に各要請データに要請データ表示エリアを設定し、各要請データの一部（概要）または全部を表示する。要請表示制御機能１８は、カレンダーテーブル１３ｄの期間（ここでは、月単位で、４月）とは無関係に、全ての要請データを表示する。従って、カレンダー画面を用いてスケジュールの確認作業を行うユーザーは、同一の視界に要請データの数や日付が入るため、スケジュールの確認という日常作業中に新たな要請データを簡単に発見することができる。特に、コンピューターの使用に不慣れなユーザーであっても、特別な操作なしに要請データの一覧がカレンダー画面１３ａ内に表示されるため、容易にスケジュール管理及びグループやメンバーに共通するスケジュール（アポイントメント）を電子的に管理することができる。従って、このアポイントメントの調整やスケジュールの共有に関するコンピュータ・リテラシーの研修等が不要である。
【００２３】
再度図１を参照すると、カレンダー画面制御部１３は、予定関連テーブル２９から読み出した要請データが複数ある場合には、当該要請データの１以上の項目を使用して、当該複数の要請データを並べ替える要請データソート機能１９を備えている。要請データソート機能１９は、好ましくは、要請データが複数ある場合には、当該当該要請データの予定日時データを使用して、現在から未来に向けた順序に従って、当該複数の要請データを並べ替える。図３に示す例では、要請データを受信した順序ではなく、要請データの予定日時が現在に近い順序で図３中上部から下部へと並べられている。一般的に、スケジュールは現在に近い日付の予定から確認するものであるため、この場合、要請データソート機能１９は、要請された順序ではなく、現在から未来に向けた順序に従って、当該複数の要請データを並べ替える。この要請データソート機能１９により、ユーザーは自然な順序で要請データの確認をすることができる。一つの要請データに複数の候補がある場合には、要請データの１以上の項目として、オーナーによって第１候補とされた日付を用いるようにしても良い。また、日時の場合であっても、午前、午後、夕方以降などの時間帯をソートの第１のキーとして、その後に日付でソートすることで、夕方以降のアポイントメント要請に対する返信を後回しなどの使い方をすることもできる。また、招集ユーザーが、企業でフレックスタイムを採用する場合には、招集ユーザーは、自分の出社時間内と、出社時間外の予定とで要請データの扱いを分けるために、定義した時間帯を要請データのソートの第１のキーとしても良い。
また、要請データの１以上の項目としては、ユーザーＩＤや、ユーザーＩＤによって特定できる役職等を採用し、要請データの並べ替えを行うようにしても良い。オーナーのユーザーＩＤ毎に要請データを並べ替えると、同様のアポイントメントが同一のオーナーから要請されることが多いため、アポイントメントの内容、種類で並べ替えることができる。
例えば、図３に示す例では、ユーザーＩＤで要請データのソートを行うと、ユーザーＩＤがＡ氏、Ｃ氏、Ｆ氏の順であると、符号で、１３ｆ，１３ｈ，１３ｇ，１３ｉ，１３ｊとの順序で図中上から下に表示される。すると、招集ユーザーは、例えば、Ｃ氏からの３月２６日と４月３日の要請が、同じＱ社に関することを発見しやすい。
役職等を使用する場合には、例えば、部長、課長等がある場合には、候補日にかかわらず、オーナーの役職の階位を第１のソートのキーとして、第２のソートのキーをユーザーＩＤとして、第３のソートのキーを日時としても良い。この場合、ユーザーテーブル等に役職を指定するコードを格納するか、または、ユーザーの所属を管理する部門テーブルなどで役職の階位等を特定できるコードを使用すると良い。また、単に、ユーザーＩＤの数値を階位に従って定めるようにしてもよい。
後述するプロジェクトの関係では、請データにプロジェクトＩＤを含め、プロジェクトのリーダーであるか否かや、プロジェクトのＩＤ毎のソートとしても良い。
【００２４】
また、カレンダー画面１３は、要請データが複数の候補日を有する場合に、どのようにカレンダー画面に表示するかについて、下記の機能を備える。アポイントメント要請の量や、予定の量などに応じて、ユーザーか下記機能を選択して使用する。
第１に、好ましくは、カレンダー画面制御部１３は、予定関連テーブル２９から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、前記オーナーによって第１候補とされた日時を当該要請表示エリアに記述する要請エリア内第１候補表示制御機能２０を備える。要請エリアでは要請データの有無を表示すれば当面の確認としては十分であり、且つ、要請データが多数ある場合でも、煩雑さの少ない表示とすることができる。具体的な日程の調整では、カレンダーテーブル１３ｄ内については各要請データの全ての候補日を表示する表示指令１３ｂなどの機能を提供することにより、単一の要請データについてどの候補日の都合が良いかどうかの視覚的な判断に寄与できる。
第２に、好ましくは、カレンダー画面制御部１３は、予定関連テーブル２９から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、当該要請表示エリア内に全ての候補日の日時を記述する要請表示エリア内全候補表示制御機能を備えると良い。この例では、一つのアポイントメント毎に、一つの要請表示エリアを生成し、そして、この要請表示エリア内に、全ての候補日の日時を記述する。これにより、アポイントメント要請の数と、各アポイントメントで候補日の調整が必要であるか否かを視覚的に即座に把握することができる。
第３に、好ましくは、カレンダー画面制御部１３が、要請データに候補日が複数定義されている場合には、一つの要請データについて一つの要請表示エリアを生成し、予め指定されたユーザーの要請表示エリア表示設定に従って、前記カレンダーフィールド又は前記要請表示エリア内の一方にのみ全ての候補日の日時を表示する機能を備えると良い。この例では、アポイントメントの要請も予定も多いユーザーに、カレンダー画面１３ａのカレンダー又は要請表示エリアのどちらかで複数の候補日を表示する。従って、複数の候補日という同一の情報を二重に表示することがない。
【００２５】
要請データを受信すると、招集ユーザーは参加の有無等の返信データを作成する。この例では、サーバー１０が、調整制御部１６を備える。調整制御部１６は、アポイントメントへの参加を要請された招集ユーザーによって使用される端末１からアポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成する。本実施形態では、この調整画面の表示指令と関係して、カレンダー画面制御部１３が、前記要請データ毎の要請表示エリア１３ｆ，１３ｇ等を、前記調整画面の表示指令を当該端末から送信する表示指令ボタンに設定する要請表示エリアボタン化制御機能２１を備える。すなわち、要請表示エリアボタン化制御機能２１は、例えば図３に示すＣ氏より４月３日Ｑ社訪問という要請データの一部を表示したテキストを、実行ボタンやリンクとして定義し、この要請表示エリアのクリック操作を調整画面の表示指令とする。要請表示エリアボタン化制御機能２１を備える例では、返信データの作成のための特別な操作が不要となり、カレンダーによるスケジュールの確認作業との一体的な作業で、要請に対する返信データの作成を促すことができる。
【００２６】
次に、予定の種類に応じた表示形式の設定について説明する。本実施形態では、カレンダー画面制御部１３が、カレンダーフィールドへの記述の表示形式１３ｃを、前記要請データと前記予定データとで異なる表示形式に設定する予定種類別表記設定機能２２を備える。表示形式１３ｃは、図３に示す例では、時刻部分への黒丸や白丸の表示である。また、表示形式１３ｃを、要請データ及び予定データの時間表示等の色分けとしても良い。図３に示す例では、アポイントメント調整中の要請データを赤色、通常予定を黒色、図中金曜日の定例会議等の繰り返し予定を水色としている。
【００２７】
アポイントメント確定処理部１２が、オーナーによってアポイントメントの日時等が確定された場合には、要請データを通常予定データに変換するため、カレンダー画面制御部１３は、ユーザーの日常的なスケジュール確認作業で使用するカレンダーテーブル１３ｄのカレンダーフィールド１３ｅ中に、確定した要請データを通常予定として表示する。そして、予定種別表示設定機能２２が、予定の種類に応じて表示形式１３ｃを異なるものとするため、日常的なカレンダー画面の閲覧作業中に、調整中から確定への変化を色等の変化によって把握することができる。
【００２８】
特に、アポイントメントのオーナーによって何時確定されるのかを招集ユーザーが予測することは困難であるため、確定されたか否かを確認するための特別な操作を必要とすると、確定されるまで何度も当該確定の確認操作を行う必要が生じてしまう。本実施形態による確定を予定の表示形式で通知する仕組みは、日常的なスケジュール確認作業にて、特に確認すべき期間内での予定については、確定したことが一目瞭然となるため、初心者にとっても判りやすく、熟練者にとっても手間いらずの仕組みとすることができる。
【００２９】
また、オーナーによって確定処理がなされた時刻が、ユーザーにとってもスケジュールを確認したい時刻であるとは限らないため、ユーザーは、自らがスケジュールを確認する時に、オーナーの確定作業とは非同期に、表示形式１３ｃの変化によって確定されたことを把握することができる。スケジュール管理としては、そのスケジュールがグループの共通のスケジュールであるか、または個人のスケジュールであるかは、必ずしも重要ではなく、確定したスケジュールであるのか、それとも調整中であるかがより重要であり、調整中と確定予定とで表示形式を変更する仕組みは、万人に使い勝手の良いものとなる。
【００３０】
また、例えば、カレンダーの表示指定１３ｂを常に週表示とするユーザーであっても、その週以外の要請については要請表示制御機能１８によって同一画面内に表示され、一方、確定した予定については、通常予定として日常のスケジュール確認作業で自然に把握することができ、従って、個人の通常予定と、アポイントメントの要請と、アポイントメントの調整後の確定した共通予定とを一体的に自然な作業にて管理することができる。
【００３１】
また、カレンダー画面制御部１３は、前記予定関連テーブル２９から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、前記オーナーによって第１候補とされた日時で要請データを前記カレンダーフィールド１３ｅに記述するカレンダー内第１候補表示制御機能２３を備えると良い。
この例では、複数の候補日を有する要請データについて、全ての候補日の予定を個別にカレンダーフィールドに表示すると、日常的な作業を鑑みると、同一の用事（アポイントメント，要請データ）が複数の用事であるとの誤解を招くかもしれないため、第１候補の日時についてのみカレンダーフィールド１３ｅに表示する。
【００３２】
図３に示す例では、アポイントメントの要請データの受信から確定までの表示形式を赤色で、確定したアポイントメント要請を含む通常データを黒色で表示する。要請データを二種類に分け、アポイントメントの要請が極めて活発な場合には、さらに、要請データへの返信を行った後、確定までの予定について別の表示形式（例えば、緑）としても良い。アポイントメントの調整については、調整制御部１６が、アポイントメントへの参加を要請された招集ユーザーによって使用される端末１から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、まず、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成する。そして、調整制御部１６は、この調整画面に入力される返信データを予定関連テーブル２９に格納する。
【００３３】
この例では、好適には、カレンダー画面制御部１３が、参加返信候補日表示制御機能２４を備える。参加返信候補日表示制御機能２４は、当該返信データの格納後前記オーナーによる確定前の要請データについては、前記返信データにて参加と返信した全ての候補日について当該要請データを当該候補日のカレンダーフィールドに記述する。すなわち、複数の候補日のうち、参加すると返信した日時については、他の予定との重なり合いを避けなければならない。要請データのカレンダーテーブル１３ｂへの表示を、候補日すべてや、第１候補のみとすると、返信した候補日を確認するための操作が必要となる。参加返信候補日表示制御機能２４を備える例では、自分が参加するとして返信した日付について要請データをカレンダーテーブル１３ｂへ表示する。
【００３４】
この例では、複数の候補日を有する要請データの受信と、カレンダーテーブル１３ｂへの表示との関係は、まず、受信時には第１候補の日付のみを赤色で表示する。続いて、調整画面を用いて候補日への参加又は不参加を表明した場合には、参加を表明した候補日について、緑色で表示する。続いて、オーナーによってアポイントメントの確定がなされると、アポイントメント確定処理部１２によって要請データが通常予定データへと変換されるため、緑色で表示された予定が消え、黒色となる。この例では、調整画面にて全ての候補日について不参加を表明した場合には、カレンダー画面へは当該要請データは表示されなくなる。
一方、第１候補のみをカレンダーフィールドに表示したい場合には、カレンダー内第１候補表示制御機能が、当該返信データの格納後前記オーナーによる確定前の要請データについては、前記返信データにて参加と返信した候補日のうち当該招集ユーザーによって第１候補とされた日時にのみ要請データを前記カレンダーフィールドに記述する機能を備えると良い。この例では、要請データの受信時には、オーナーによって指定された第１候補（候補日順位が“１”）の日時にのみ要請データを赤色で表示する。続いて、調整画面を用いて候補日への参加又は不参加を表明した場合には、参加を表明した候補日のうち、招集ユーザーによって第１候補とされた日時にのみ要請データを緑色で表示する。その後の確定は上記と同様である。招集ユーザーによって第１候補とされる候補日の特定は、例えば、招集ユーザーが参加を表明した候補日のうち、オーナーによって指定された候補日順位の高い候補日としても良い。
【００３５】
図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。本実施形態によるアポイントメント調整支援処理は、参加の要請の作成及び通知をする要請制御工程（Ａ１，Ｂ１等）と、アポイントメントの出欠や候補日選定を調整する調整制御工程（Ｂ３，Ｂ４等）と、アポイントメントを確定する確定工程（Ａ５，Ｂ５等）とを備える。
【００３６】
要請制御工程では、まず、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促す（ステップＡ１）。そして、要請制御工程では、オーナーによって要請データが入力されると、この入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する（ステップＢ１，Ｂ２）。この要請データの通知は、本実施形態では、カレンダー画面１３ａへの表示である。さらに、電子メールによる通知を付加しても良い。カレンダー画面１３ａへの表示は、カレンダーフィールド１３ｅへの要請データの表示と、カレンダー画面の要請表示エリアへの表示とがある。カレンダー画面１３ａを使用する例では、オーナーの個人カレンダーにも当該要請データを表示する。
【００３７】
調整制御工程では、まず、データベース２と接続し、そして、要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによるアポイントメントの要請への出欠等の返信データの入力を促す（ステップＢ３）。このとき、ステップＢ３は、アポイントメント予定テーブル３２を参照して、全ての招集ユーザーによって使用される端末１に、他の全招集ユーザーの返信状態データを送信すると良い（ステップＢ４）。招集ユーザーの返信状態は、オーナーによって使用される端末でも逐次参照できるようにする（ステップＡ３）。
【００３８】
調整制御工程では、続いて、オーナーによって使用される端末１と通信して、前記アポイントメント予定テーブル３２に格納された返信状態データを当該端末１に表示する（ステップＡ３）。続いて、当該オーナーにアポイントメントの強制調整操作を促し、そして、未返信の招集ユーザーや、不参加と返信した招集ユーザーの出欠について、オーナーが強制的に参加へと強制調整した場合には、当該強制調整操作のなされた返信状態データを最新の返信状態データとして管理する（ステップＡ４）。
【００３９】
確定制御工程では、オーナーによって使用される端末と通信して、前記返信状態データに対して、当該オーナーによってアポイントメントの確定操作がなされた場合には、当該確定された返信状態データを確定予定データとして管理する（ステップＡ５）。すなわち、要請データ及び返信状態データを通常予定データに変換する。確定制御工程は、さらに、確定予定データを、全ての招集ユーザーに通知する（ステップＢ５）。そして、参加が確定した招集ユーザーのカレンダー画面１３ａに確定した予定を通常予定として表示する（ステップＢ６）。また、オーナーの個人カレンダーにも通常予定として表示する（ステップＡ６）。
【００４０】
図１に示す構成や、図４に示す処理工程は、サーバーのＣＰＵが所定のプログラムを実行することで実現することができる。本実施形態によるシステムのＣＰＵ（図示せず）は、所定のプログラム（指令）に従って各種の演算を行う。ＣＰＵは、各種の処理要求に従って、データベース２を駆動して、各種のページ（画面）の生成や送受信などを実行し、その実行結果を端末１に送信する。ＣＰＵがアポイントメント調整支援用のプログラムを実行することで、システムは、調整データの生成や、入力される返信データの管理等を処理する。
【００４１】
＜実施例＞
図５は、本実施例の構成例を示すブロック図であり、図６は、本実施例でのデータ構造の一例を示す説明図である。図６に示す各テーブルのフィールド名の一例を図７に示す。本実施例では、実施例では、Ｗｅｂサーバーと、ＨＴＭＬ等のマークアップランゲージで記述された画面（ページ）を表示するブラウザを備えた端末とを使用する例を開示する。
【００４２】
本実施例では、アポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー（Ｗｅｂサーバー）１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。そして、データベース２は、図６及び図７に示すように、ユーザーテーブル３０と、アポイントメント予定テーブル３２と、通常予定テーブル３４と、予定メインテーブル３６とを備える。本実施例では、図６に示すように、通常予定テーブル３４と、アポイントメント予定テーブル３２とを、予定メインテーブル３６の予定種類コードによって使い分けている。
【００４３】
ユーザーテーブル３０は、前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納する。
予定メインテーブル３６は、予定を識別する予定ＩＤ毎に、前記ユーザーＩＤと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データと、アポイントメント等で予定する場所である予定場所データとを格納する。
通常予定テーブル３４は、前記予定ＩＤ毎に、予定開始日時データと、予定終了日時データとを格納する。
アポイントメント予定テーブル３２は、候補日順位毎の前記予定ＩＤ毎に、当該予定ＩＤのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーＩＤと、当該オーナーと招集ユーザーとを識別すると共に当該招集ユーザーの順序を指定するアポイントメントユーザー順位と、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納する。
予定ＩＤは、オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合には、候補日順位毎に個別のＩＤとすると良い。また、アポイントメントの調整によって確定した予定については、単一の予定ＩＤとし、予定内容データや、予定場所データや、予定開始日時や、予定終了日時については、各ユーザーで共通のデータを使用すると良い。この場合、確定したアポイントメントの予定については、各ユーザーは個別の編集を行うことはできない。また、予定ＩＤをユーザー毎として、確定したアポイントメントの予定を各ユーザーが編集できるようにしても良い。
【００４４】
図７に各テーブル３０，３２，３４，３６の各フィールドの内容を例示する。図７に示すように、予定の種類を示す予定種類コードは、確定している通常予定を“０”、アポイントメントの調整中であるアポイントメント予定を“１”、通常予定のうち毎週同時刻等の繰り返し予定を“２”としている。アポイントメントユーザー順位は、オーナーを“０”とし、招集ユーザーは“１”から順に付番する。アポイントメント候補日順位は、アポイントメントの候補日が複数ある場合に、これを識別する番号となる。本実施例では、出欠フラグは二種類のみとし、参加を“１”、不参加を“０”とし、返信保留を示すデータ構造はない。従って、出欠についてはフラグとしている。
【００４５】
再度図５を参照すると、サーバーは、要請作成画面生成部５０と、要請データ格納制御部５２と、調整画面生成部５６と、返信データ格納制御部５８と、確定処理制御部６０と、カレンダー画面制御部５１とを備える。本実施例による処理は、Ｗｅｂサーバーを用いて、特徴的な画面を使用して、図４に示すアポイントメント調整支援処理をより詳細に開示するものである。本実施例では、「画面」は、端末１のブラウザ等で表示されるＨＴＭＬ等のマークアップ言語によって記載され、端末１のユーザーによって入力される入力フィールドやチェックボックスやポップアップメニューなどの選択肢の定義を含むファイルである。
【００４６】
要請作成画面生成部５０は、オーナーによって使用される端末１からアポイントメントの要請を作成するための要請作成画面４２の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促すための要請作成画面４２（例えば、図９に示す画面）を生成する。図４に示す例では、要請作成画面生成部５０は、ステップＡ１の処理を行う。
【００４７】
要請データ格納制御部５２は、まず、要請作成画面が生成されたときに、前記オーナーによって使用される端末へ当該要請作成画面４２を送信する。そして、当要請データ格納制御部５２は、オーナーによって当該要請作成画面に入力される要請データを受信する。この制御部５２は、さらに、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納し、一方、要請作成画面４２のその他の各フィールドの内容を前記アポイントメント予定テーブルに格納する。要請データ格納制御部５２は、例えば、図１３に示すフローチャートを実行する。図４に示す例では、要請データ格納制御部は、ステップＡ１の処理を行う。すなわち、本実施例では、図１３に示すフローチャートはステップＡ１の詳細処理である。
【００４８】
カレンダー画面制御部５１は、端末１から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、前記予定メインテーブルに格納された予定種類コードに応じて前記アポイントメント予定テーブル３２に格納された要請データ及び前記通常予定テーブル３４に格納された予定データとを当該期間を日毎に区切った各カレンダーフィールドに記述する。これにより、カレンダー画面制御部４１は、ステップＢ１及び／又はＢ２の処理を行う。要請データを招集ユーザーに通知する。カレンダー画面制御部５１は、また、サーバー１０が、要請データの内容または要請データを送信したことを招集ユーザーに知らせる電子メールの送信を制御する要請データ通知制御部５４を備えるようにしてもよい。
【００４９】
調整画面生成部５６は、招集ユーザーによって使用される端末から、アポイントメントの要請に対する返信を作成するための調整画面４６の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面４６（例えば、図１１に示す画面）を生成する。図４に示す例では、調整画面生成部５６は、ステップＢ３の処理を行う。
【００５０】
好ましい例では、調整画面生成部５６が、他ユーザー出欠参照制御機能６２を備えるようにしてもよい。この機能６２は、第１実施形態等の機能１８と同様の作用効果を有する。すなわち、本実施例では、他ユーザー出欠参照制御機能６２は、招集ユーザーによって使用される端末１から調整画面４６の表示指令を受信したときに、予定ＩＤをキーとしてアポイントメント予定テーブル３２を参照する。そして、アポイントメント予定テーブル３２から、他の招集ユーザーのユーザー名、出欠フラグ及び返信コメント読み出して、前記調整画面４６にて合成する。図４に示す例では、他ユーザー出欠参照制御機能６２は、ステップＢ４の処理を行う。
【００５１】
返信データ格納制御部５８は、まず、前記調整画面４６が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面４６を送信する。制御部５８は、続いて、当該招集ユーザーによって当該調整画面に入力される返信データを受信する。さらに、制御部５８は、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する。図４に示す例では、返信データ格納制御部５８は、ステップＢ３の処理を行う。
【００５２】
本実施例では、好適には、調整画面生成部５６が、確定用調整画面生成機能６４を備える。確定用調整画面生成機能６４は、オーナーによって使用される端末１から、確定用調整画面４８の表示指令を受信した場合には、前記予定ＩＤをキーとしてアポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出する。確定用調整画面生成機能６４は、続いて、各招集ユーザーの出欠に関して強制参加チェックボックスを付加した確定用調整画面４８（例えば、図１２に示す画面）を生成する。図４に示す例では、確定用調整画面生成機能６４は、ステップＡ３の処理を行う。
【００５３】
本実施例では特に、カレンダー画面制御部５１は、表示指定による期間と無関係に、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述させる要請表示制御機能７０と、カレンダーフィールドへの記述の表示形式を、前記予定メインテーブルに格納された予定種別コード毎に異なる表示形式に設定する予定種類別表記設定機能７１とを備える。要請表示制御機能７０は、図４のステップＢ２に示す処理を実行する。予定種別表記設定機能７１は、図４に示すステップＢ５の役割を果たす。
【００５４】
そして、調整画面生成部５６は、強制調整制御機能６６を備えるとよい。強制調整制御機能６６は、前記オーナーによって、前記確定用調整画面４８の前記強制参加チェックボックス４９がチェックされた招集ユーザーの出欠について、これを強制的に参加として確定する。強制調整制御機能６６は、当該招集ユーザーの通常予定テーブル３４に当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する。図４に示す例では、強制調整制御機能６６は、ステップＡ４の処理を行う。
【００５５】
確定処理制御部６０は、オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブル３２を参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する。確定処理制御部６０は、例えば、図１４に示すフローチャートを実行する。図４に示す例では、確定処理制御部６０は、ステップＡ５の処理を行う。すなわち、図１４に示すフローチャートは、本実施例でのステップＡ５の詳細処理である。
【００５６】
次に、画面を参照して具体的な使い方を説明する。ここでは、次の状況設定と、登場人物とを設定する。オフィス家具大手Ｋ社の販売課長、阿部氏は、顧客であるＱ社の移転に伴うオフィス家具購入の案件で家具配置プランの提案を行っていた。プロジェクトのリーダー阿部は、メンバーのプレゼンテーションの日程を調整する立場にある。このプロジェクトには、メンバーとして営業マン海老沢、設計担当者山田、和田及び鈴木が属している。
【００５７】
図８は、ユーザー予定データ表示画面の一例を示す説明図である。図８から図１２に示す画面の例は、パーソナルコンピュータ等でブラウザー・アプリケーションを使用してサーバー１０から送信されるデータを画面として表示している状態を示す。図中の下線はリンクであり、他の画面への表示指令となる。
【００５８】
カレンダー画面制御部５１は、アポイントメントのオーナー向けに、プロジェクトや部署に属するユーザーの登録されている予定を表示するユーザー予定画面４０（実際には、カレンダー画面４４）を生成する。阿部氏は、図８に示すユーザー予定画面を表示し、メンバーの空きスケジュールを確認する。すると、木曜日は海老沢氏、山田氏及び和田氏に先約があり、金曜日には全てのメンバーに予定がない。オーナーは、一応両日を候補日として提案することとする。オーナーである阿部氏は、図８のアポイントメントと表記されたアポイントメント・リンク４０ａに対してクリック等の操作をする。アポイントメント・リンク４０ａへの操作は、要請作成画面の表示指令である。
【００５９】
また、阿部氏は、図８の符号４０ｂで示す要請表示エリアに、山田氏から１月２１日を予定日とするアポイントメントの要請が送信されていることを発見する。これは要請データであり、図８に示す例では当該予定日は現に表示しているカレンダー画面の期間内であるため、カレンダー画面制御部５１は、符号４０ｅで示す表示形式（黒丸）で当該要請データをカレンダーフィールド４０ｈに表示する。
【００６０】
図９に、要請作成画面４２の一例を示す。阿部氏は、要請作成画面４２の内容フィールド４２ａにアポイントメントの内容を「Ｑ社訪問」と入力し、同様に場所フィールド４２ｂに「横浜」と場所を入力する。続けて、日付・時間エリア４２ｃのＧＵＩ部品を用いて、候補日と時間とを入力する。阿部氏は、コンボボックスとなっている日時フィールドを使用して日時を特定する。このとき、第１候補を金曜日（２４日）、第２候補を木曜日（２３日）とする。また、招集ユーザー特定用エリア７４を使用して、招集したいユーザーを選択する。
【００６１】
再度図５を参照すると、データベース２が、図６等に示すテーブルの他、ユーザーの一部又は全部が参加するプロジェクトを識別するプロジェクトＩＤ毎に、当該プロジェクトのメンバーとなるユーザーのユーザーＩＤと、当該プロジェクトに属するコンテンツとを格納するプロジェクト関連テーブル３８と、ユーザーの所属部門を識別する部門ＩＤ毎に当該部門に所属するユーザーＩＤを格納する部門テーブル３１とを備えている。
【００６２】
そして、サーバー１０は、プロジェクト関連テーブル３８を参照して、当該プロジェクトのメンバーによって使用される端末と通信して、当該プロジェクトのコンテンツの参照、編集及び登録を促すプロジェクト画面９０を管理するプロジェクト活動支援制御部７２を備えている。
【００６３】
そして、要請作成画面４２は、図９に示すように、当該アポイントメントに招集する招集ユーザーの候補となる候補者リストを抽出すると共に、当該候補者リストからの招集ユーザーの選択を促す招集ユーザー特定用エリア７４を備えている。そして、招集ユーザー特定用エリア７４に、候補対象者一覧を表示する候補者リストボックス７５と、この候補者リストボックス７５から選択された要素であるユーザー名の一覧を表示する招集ユーザーリストボックス７６と、候補者リストのキーとなるプロジェクト名又は部門名の選択を促すポップアップリスト７７とを備えている。オーナーがポップアップリスト７７を使用してプロジェクト名又は部門名を特定すると、要請作成画面生成部５０は、部門テーブル３１又はプロジェクト関連テーブル３８を参照して、部門に属するユーザー名の一覧や、プロジェクトのメンバー一覧を抽出し、候補者リストボックス７５に表示する。オーナーは、この候補者リストボックス７５に表示されたユーザー名を選択して、招集ユーザーリストボックス７６に追加する。
【００６４】
オーナーは、日付・時間や招集したいユーザーの特定が完了すると、要請するボタン４２ｅを押し下し、要請データをオーナーの端末１からサーバー１０へ送信する。また、阿部氏は、山田氏からのアポイントメント要請を受諾し、参加を表明した。
【００６５】
図１０は、要請表示エリア４４ａ，４４ｂを有するカレンダー画面４４の一例を示す説明図である。招集ユーザーである山田氏は、まず、阿部氏からの返信データを受信したため、直ちに１月２１日の予定を確定した。アポイントメントを確定して再表示すると、図１０の符号４４ｄで示すように、表示形式が通常予定となり、ここでは、黒丸が取れた。
【００６６】
そして、自分のカレンダー画面４４を開くと、要請表示エリア４４ｂに阿部氏からの要請が表示されている。このため、自分のスケジュール確認という普段の活動の中でアポイントメント要請に気づくことができる。そして、カレンダーのうち２４日金に、黒丸が付された状態で予定が記入されている。これは、要請データの招集ユーザーへの通知であり、このアポイントメントについては招集ユーザーである山田氏は、個人のカレンダー画面４４を開くだけで、要請表示エリア４４ｂに要請データの概要が表示され、且つ、自分の予定としてカレンダーに表示される。すなわち、カレンダー画面制御部５１は、各個人のカレンダーにアポイントメントの要請データをスケジュールとして表示することで、要請データの通知を行う。要請表示エリア４４ｂは、ボタンとなっており、この領域をクリックする操作は、調整画面４６の表示指令をサーバー１０に送信する。
この図１０に示す例では、要請データに複数の候補日が含まれているため、まず、要請表示エリア内全候補表示制御機能が、要請表示エリア４４ｂに、第１候補の候補日である１月２４日と、第２候補の候補日である１月２３日とを記述する。そして、図１０に示す例では、カレンダー内第１候補表示制御機能２３が、２つの候補日の内、オーナーによって第１候補と指定された１月２４日のカレンダーフィールドにのみ要請データを表示し、第２候補である１月２３日のカレンダーフィールドには要請データを表示していない。
【００６７】
また、要請データ通知制御部５４は、電子メールにてリアルタイムに要請データを送信するようにしてもよい。山田氏、返答を入力するためにひとまず返答画面（調整画面４６）を開いてみた。
【００６８】
図１１は、招集ユーザー用の調整画面４６の一例を示す説明図であり、ここでは招集ユーザーである山田氏用の調整画面である。山田氏は、海老沢氏と鈴木氏はすでに木曜日に×（不参加）、金曜日に○（参加）と回答しており、和田氏は未回答であることを把握する。山田氏は、この返信状態データでは、第１候補での開催だろうと考え、第１候補については○（参加）とし、第２候補については×（不参加）とした。
【００６９】
この状態で阿部氏が確定用調整画面４８を開くと、図１２に示す画面の状態となる。図１２は、オーナー用の調整画面（確定調整画面４８）の一例を示す説明図である。阿部氏は、未回答の和田氏は外出中で返信を書けないのであろうと考え、本人の了解を得ることなく強制的に参加を命ずることとした。このため、阿部氏は、調整画面４６の和田氏の強制チェックボックス４９をチェックし、第１候補の確定ボタン４９ａを押した。この瞬間、全員に金曜日にプレゼンが決定した旨メールが発信され、正式なスケジュール（通常予定）として全メンバーのカレンダーに記入された。すなわち、招集ユーザー全員のスケジュールを同時に確定することができる（同時確定制御機能６７）。
【００７０】
図１３は、要請データ格納制御部による要請データの格納処理の一例を示すフローチャートである。図９に示す必須入力項目が入力され、オーナーによって要請するボタン４２ｅがクリックされると、端末１のブラウザは、入力された要請データにログインユーザーのユーザーＩＤ（ここでは、オーナー）を付加して、当該要請データをサーバー１０に送信する。サーバー１０は、要請データを受信すると、図１３に示す処理を開始する。すなわち、要請データ格納制御部５２は、まず、新しい要請データに対して、新しい予定ＩＤを取得する（ステップＳ１）。ここでは、要請データの候補日順位毎に予定ＩＤを取得する。続いて、アポイントメント候補日順位を“１”とする（ステップＳ２）。さらに、オーナーのアポイントメントユーザー順位を“０”とする。
【００７１】
続いて、アポイントメントユーザー順位を付するため、ｘ＝１とし（ステップＳ４）、招集ユーザーのアポイントメントユーザー順位をｘとする（ステップＳ５）。これを図９に示す「招集したいユーザー」全てについて完了するまで（ステップＳ６）、ｘの値をインクリメントして、アポイントメントユーザー順位を設定する。
【００７２】
アポイントメントユーザー順位を設定すると、続いて、図６に示すデータ構造のアポイントメント予定テーブル３２に、予定ＩＤ、ユーザーＩＤ、アポイントメントユーザー順位、候補日順位、予定開始日時、予定終了日時を格納する（ステップＳ８）。続けて、予定メインテーブル３６に予定ＩＤと、全ユーザーのユーザーＩＤと、予定種類コードと、予定内容データ（Ｑ社訪問）と、予定場所データ（横浜）とを格納する。予定種類コードは、ここではアポイントメント調整中の予定であることを示すコード“１”を格納する。これにより、予定ＩＤをキーとして、第１候補日順位についての要請データを格納した。各種の制御部は、予定ＩＤをキーとして予定メインテーブル３６を参照すると、当該予定ＩＤで識別される予定が通常予定であるのか、それともアポイントメント調整中の予定であるかを特定することができる。
【００７３】
続けて、次の候補日順位のデータがあるか否かを確認し（ステップＳ１０）、ここでは、第２候補日順位のデータがあるため、ステップＳ１に戻り、第２候補日順位用の予定ＩＤを取得する。第２候補日順位についても同様に要請データをアポイントメント調整中の予定データとして格納し、第３候補日順位のデータはないため、処理を終了する。
【００７４】
図１４は、確定処理制御部６０によるアポイントメントの確定処理の一例を示すフローチャートである。端末１のブラウザは、図１２に示す最新の返信状態データの表示中に確定するボタン４９ａがクリックされると、この確定操作によるイベントはサーバーに送信する。また、ブラウザは、強制チェックボックス４９のチェックの有無もサーバー１０に送信する。確定するボタン４９ａは予定ＩＤと、候補日順位と関係しているため、サーバー１０は、端末１から、少なくとも、予定ＩＤと、候補日順位と、強制チェックボックス４９のオン／オフとを受信する。
【００７５】
サーバー１０では、確定処理制御部６０が、この確定操作を受信したときに、図１４に示す処理を開始する。まず、確定された候補日順位以外の順位の予定ＩＤに関するレコードを全て削除する（ステップＳ１１）。
【００７６】
続いて、確定された候補日順位の予定ＩＤからアポイントメント予定テーブル３２を検索して予定開始日時と予定終了日時とを読み出し、当該予定ＩＤと、予定開始日時と、予定終了日時とを新たに通常予定テーブル３４へ格納する（ステップＳ１２）。すなわち、確定した予定に関するデータを、アポイントメント予定テーブル３２から通常予定テーブルへ複写する。
【００７７】
さらに、当該予定ＩＤをキーとして、アポイントメント予定テーブル３２から招集ユーザーの出欠を順に確認する（ステップＳ１３）。招集ユーザーの探索順序は、アポイントメントユーザー順位の順序とし、ここでは、まず、順位“０”のオーナーである阿部氏について確認する。阿部氏の出欠フラグは“１”であるため、当該予定ＩＤと阿部氏のユーザーＩＤとで予定メインテーブルを検索し、その予定種類コードを“１”から“０”に変更する（ステップＳ１５）。すなわち、当該第１候補のアポイントメントを阿部氏の通常予定とする。そして、通常予定とした後に、該当するユーザーＩＤに関するアポイントメント予定テーブル３２のレコードを削除する。ステップＳ１６，Ｓ１３にて次に順位“１”の海老沢氏が特定され、同様に処理する。
【００７８】
和田氏については、ステップＳ１４にて、出欠フラグが格納されておらず、“１”ではないため、ステップＳ１７に進む。ステップＳ１７では、強制チェックボックスがオンであるか否かを確認し、強制チェックボックスがオンであるため、ステップＳ１５にて同様に予定種類コードを通常予定へ更新する。予定種類コードが通常予定となると、各ユーザーの各カレンダー画面４４にて自分のスケジュールとして表示される。
【００７９】
図１５は、カレンダーへの予定表示処理の一例を示すフローチャートである。図８に示すカレンダー画面４４は、図中左上から、表示指定エリア４０ｃと、月／週指定エリア４０ｄと、要請表示エリア４０ｂとを備え、さらに、プロジェクト／部署選択コンボボックス４０ｆと、カレンダーテーブル４０ｇと、カレンダーフィールド４０ｈとを備えている。本実施例では、表示指定として、個人の月表示、部署の週表示及び日表示、プロジェクトの週表示及び日表示とを有する。図８に示す例では、表示指定はプロジェクトの週表示であり、コンボボックス４０ｆによりＰ社新築ビルプロジェクトというプロジェクトが選択されている。表示する週は、月／週指定エリア４０ｄの操作に応じて、２００３年１月１９日からである。
【００８０】
サーバー１０のカレンダー画面制御部５１は、端末１からカレンダー画面の表示指令を受信したときに、図８等に示すカレンダー画面の表示処理を行う。図１５に示すように、カレンダー画面制御部５１は、まず、ユーザーＩＤを参照して、設定情報等を読み出し、カレンダー画面の定型情報を生成する（ステップＳ２１）。ここでは、エリア４０ｃ，４０ｄなどである。続いて、カレンダー画面制御部５１は、表示指定に応じてカレンダーテーブルを生成する（ステップＳ２２）。週表示であれば、日曜から土曜までの列と、プロジェクトのメンバー数に応じた個数の行とを有する空のカレンダーテーブルを生成する。カレンダーテーブルの各フィールドを、カレンダーフィールドという。
【００８１】
続いて、カレンダー画面制御部５１は、カレンダーテーブルの各カレンダーフィールドの表示処理を行う。すなわち、図８に示す例ではユーザーＩＤ毎に、通常予定テーブル３４とアポイントメント予定テーブル３２との予定開始日時を参照する。そして、カレンダーテーブル内の過去の日付から順にカレンダーフィールドを特定する（ステップＳ２３）。まず、阿部氏について１９日のカレンダーフィールドの特定では、両テーブル３２，３４に１９日の予定が格納されているか否かを探索し（ステップＳ２５）、格納されていないため、全日付完了したか否かを確認して（ステップＳ３０）、完了していないため、処理を２０日に移す。
【００８２】
２０日では、通常予定テーブル３４に、「戦略会議」との予定が格納されている。ステップＳ２４でイエスとなるため、予定の種類コード２５を参照して、通常予定であるため、予定日時を黒色に設定する。続けて、同日に他の予定がなければ（ステップＳ２９）、ステップＳ３０，Ｓ２３を介して２１日の処理を開始する。２１日には、山田氏からのアポイントメント要請があり、アポイントメント予定テーブル３２に１月２１日１３：００との予定開始日時が格納されている。ステップＳ２５では、予定種類がアポイントメント予定であるため、予定日時の文字表示を赤色に設定する。図面では、文字を赤色にする処理に変えて、黒丸４０ｅを付した。
【００８３】
図１０に示す例では、山田氏のアポイントメント予定テーブル３２に、Ｑ社訪問という１つの要請データについて、２３日と２４日の２つの候補日がある。第１候補のみをカレンダーテーブルに表示する指定の場合には、図１５に示す例では、ステップＳ３３は、２３日については、アポイントメント予定テーブル３２にアポイントメント予定が格納されているが、このアポイントメント予定の候補日順位を参照すると、第２候補であるため、ステップＳ３３にて表示する候補日と判断せず、表示処理を行わない。２４日については、ステップＳ３３にて候補日順位を確認し、第１候補であるため、ステップＳ２８にて予定日時を赤色に設定し、表示処理を進める。また、このステップＳ３３にて、アポイントメント予定テーブルの候補日毎の出欠フラグを参照して、参加（フラグが“１”）の候補日のうち、候補日順位の最も高い（最も値の小さい）候補日であるか否かを判定することで、カレンダーに表示する候補日であるかを判定するようにしても良い。
さらに、図８及び図１０に示す例では、各ユーザーについて同様に予定を探索する。図１５に示す例では、アポイントメント予定と、通常予定とで表示する文字の色を変化させるため、アポイントメントの要請があったことを一見して把握することができる。
【００８４】
予定データの読み出し及び色の設定が全て完了すると（ステップＳ３１）、カレンダーテーブルをＨＴＭＬ等のマークアップ記述言語で記述する。
【００８５】
さらに、アポイントメント予定テーブル３２を参照して、要請表示エリア４０ｂに要請データを要請の日付順に記述する。この要請表示エリアは、調整画面を表示するためのボタンとする。
【００８６】
上述したように本実施例では、実施形態と同様の効果を奏するほか、例えば、オーナーによる強制調整の機能と、確定後に表示形式を変更（赤から黒へ）する機能との組み合わせにより、オーナーの強制調整による参加命令が通常の予定と同様に招集ユーザーのカレンダーに表示されるため、強制参加をユーザーに指示するために電話を行ったり、電子メールを送信したりするよりも参加への実効性を高めることができ、且つ、オーナーも強制参加する招集ユーザーもほとんど手間を要さない。また、Ｗｅｂ技術を用いて、画面の生成としてアポイントメントの調整及びスケジュール管理を支援するため、電子メールと異なり、双方が作業したいときに作業すれば良い非同期の環境を提供することができる。また、他ユーザー出欠参照制御機能６２と、予定種類別表記設定機能７１との組み合わせでは、全てのユーザーが、アポイント調整中に他の招集ユーザーの状況を知ることができ、さらに、特定の招集ユーザーにどれだけアポイントメントの要請が来ているかをも知ることができる。従って、一つのアポイントメントの調整のみならず、そのユーザーの業務負荷を鑑みて招集や参加の判断を行うことができる。
【００８７】
【発明の効果】
本発明は、その構成によって、カレンダー画面制御部が、月表示、週表示等の表示指定に応じて、通常予定データと要請データとをカレンダーフィールドに記述し、表示指定による期間のカレンダーテーブルを生成する。そして、要請表示制御機能は、カレンダーテーブル外の要請表示エリアに要請データを記述する。従って、表示指定の期間と無関係に、必ず要請データをカレンダー画面に表示することができる。このため、カレンダー画面で表示させる期間外の要請データの存在をユーザーに通知することができる。また、カレンダー画面制御部は、日常作業として確認すべき期間内については、要請データと通常予定データとを併せてカレンダーフィールドに表示する。このため、日常的なスケジュールの確認作業中にて、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面にて確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
このように、本発明では、スケジュールの確認という日常的な作業で通常予定データとアポイントメント予定データとを、すなわち、個人の予定データとグループで調整が必要な予定データとの一体的な管理を促すことができる。これにより、スケジュールの管理に関して、コンピューターの使い方に慣れていないユーザーがグループに属していても、当該グループのスケジュール情報の共有による生産性向上を図ることができる。
【図面の簡単な説明】
【図１】図１は、本実施形態でのスケジュール管理支援システムの構成例を示すブロック図である。
【図２】図２は、本実施形態でのデータ構造の一例を示す説明図である。
【図３】図３は、本実施形態で取り扱うカレンダー画面の一例を示す説明図である。
【図４】図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。
【図５】図５は、本実施例の構成例を示すブロック図である。
【図６】図６は、本実施例でのデータ構造の一例を示す説明図である。
【図７】図７は、本実施例での各テーブルのフィールド名の一例を示す説明図である。
【図８】図８は、ユーザー予定データ表示画面の一例を示す説明図である。
【図９】図９は、要請作成画面の一例を示す説明図である。
【図１０】図１０は、要請表示エリアを有する個人カレンダー画面の一例を示す説明図である。
【図１１】図１１は、招集ユーザー用の調整画面の一例を示す説明図である。
【図１２】図１２は、オーナー用の調整画面（確定画面）の一例を示す説明図である。
【図１３】図１３は、要請データの格納処理の一例を示すフローチャートである。
【図１４】図１４は、確定処理の一例を示すフローチャートである。
【図１５】図１５は、予定表示処理の一例を示すフローチャートである。
【符号の説明】
１  端末
１０  サーバー
１２  アポイントメント確定処理部
１３  カレンダー画面制御部
１６  調整制御部
１８  要請表示制御機能
１９  要請データソート機能
２０  要請エリア内第一候補表示制御機能
２１  要請表示エリアボタン化制御機能
２２  予定種類別表記設定機能
２３  カレンダー内第１候補表示制御機能
２４  参加返信候補日表示制御機能
【図１】
2005004307.tif 000003
【図２】
2005004307.tif 000004
【図３】
2005004307.tif 000005
【図４】
2005004307.tif 000006
【図５】
2005004307.tif 000007
【図６】
2005004307.tif 000008
【図７】
2005004307.tif 000009
【図８】
2005004307.tif 000010
【図９】
2005004307.tif 000011
【図１０】
2005004307.tif 000012
【図１１】
2005004307.tif 000013
【図１２】
2005004307.tif 000014
【図１３】
2005004307.tif 000015
【図１４】
2005004307.tif 000016
【図１５】
2005004307.tif 000017