JP2004362477A - アポイントメント調整支援システム及びプロジェクト活動支援システム - Google Patents
アポイントメント調整支援システム及びプロジェクト活動支援システム Download PDFInfo
- Publication number
- JP2004362477A JP2004362477A JP2003162905A JP2003162905A JP2004362477A JP 2004362477 A JP2004362477 A JP 2004362477A JP 2003162905 A JP2003162905 A JP 2003162905A JP 2003162905 A JP2003162905 A JP 2003162905A JP 2004362477 A JP2004362477 A JP 2004362477A
- Authority
- JP
- Japan
- Prior art keywords
- user
- data
- appointment
- request
- schedule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000000694 effects Effects 0.000 title claims description 27
- 230000006870 function Effects 0.000 claims description 115
- 238000000034 method Methods 0.000 claims description 43
- 238000012790 confirmation Methods 0.000 claims description 38
- 230000008569 process Effects 0.000 claims description 37
- 238000012545 processing Methods 0.000 claims description 31
- 239000013643 reference control Substances 0.000 claims description 31
- 230000005540 biological transmission Effects 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 18
- 238000007726 management method Methods 0.000 claims description 17
- 238000013500 data storage Methods 0.000 claims description 14
- 239000000284 extract Substances 0.000 claims description 3
- 238000004886 process control Methods 0.000 claims description 2
- 238000003672 processing method Methods 0.000 claims 3
- 238000010586 diagram Methods 0.000 description 35
- 230000007246 mechanism Effects 0.000 description 11
- 238000004891 communication Methods 0.000 description 6
- 230000003111 delayed effect Effects 0.000 description 5
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 239000000725 suspension Substances 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000002747 voluntary effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000035622 drinking Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012467 final product Substances 0.000 description 1
- 239000000314 lubricant Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000008925 spontaneous activity Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】アポイントメントの調整に関して、オーナーの手間を削減しつつ、その調整や実際の会議等の生産性を高めること。
【解決手段】アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブル３２を有するデータベースを備えている。さらに、要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する要請制御部１４と、アポイントメント予定テーブル３２を参照して、全ての招集ユーザー及びオーナーによって使用される各端末１に全ての招集ユーザーについての前記返信状態データを送信する他ユーザー出欠参照制御機能を備えた。
【選択図】 図１
【解決手段】アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブル３２を有するデータベースを備えている。さらに、要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する要請制御部１４と、アポイントメント予定テーブル３２を参照して、全ての招集ユーザー及びオーナーによって使用される各端末１に全ての招集ユーザーについての前記返信状態データを送信する他ユーザー出欠参照制御機能を備えた。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、アポイントメント調整支援システムに関し、特に、サーバーと端末とを使用してユーザー間のアポイントメントの調整作業を支援するシステムに関する。
【０００２】
【従来の技術】
従来、企業や大学等では、会議や、研修会や、展示会への参加や、旅行などの予定の約束（アポイントメント）を、参加の候補者のスケジュールを調整しつつ、日時を確定する。参加を要請する主催者（オーナー）は、主催者から参加を要請される人（招集ユーザー）に参加を要請し、招集ユーザーからの出欠可否の返答などを参照して、最終的な日時を決定する。
【０００３】
特に、会議については、一定の事項の決定や、連絡や、業務の分配などの役割が与えられているため、参加すべき人が参加できないと、その後の活動の生産性が低下する恐れもあり、主催者（オーナー）は、活動に支障のないよう、アポイントメントの日時を慎重に提案し、また、各招集ユーザーへの個別連絡などを行う。
【０００４】
特許文献１には、会議を行うためのスケジュール調整を簡便なものとし、会議の主催者にかかる負荷を軽減することを目的として、会議開催期間と、会議参加者とを会議システムに登録すると、会議サーバーが、社員スケジュールＤＢと、会議室スケジュールＤＢとを検索して、候補日を自動的に特定し、さらに、参加者からの出欠の返答に基づいて自動的に開催の可否を特定する仕組みが開示されている。
【０００５】
この特許文献１の図２及び図３では、主催者は、参加者氏名に、必須、順必須、任意との出席者区分を定め、さらに、個々の参加者の代理参加者を特定する必要がある。そして、特許文献１の図５にある電子メールを自動的に送信し、参加の候補者からの電子メールの返信を自動的に解析して、図６に回答集計結果を生成する。この回答集計結果は、会議データを登録した際の会議開催の条件を満たした日時にＯＫと表示される。会議主催者は、この回答集計結果を参照して、最終的に会議開催の有無と、開催日とを確定する。
【０００６】
特許文献２では、グループ内の各端末ユーザーのスケジュールを定型の電子メールを用いて一括して管理することを目的として、会議通知の送信メールの送信者（会議開催者）として記述されている送信元のメールアドレスに対応付けて、個人別予定表メモリーに会議スケジュールを登録する。また、会議通知の電子メールへの返信があると、当該返信メールに参加の意味を示す項目が選択されている場合には、返信者のメールアドレスと対応付けて個人別予定表メモリーに会議スケジュールを登録する。この特許文献２では、会議開催者が、全員に強制参加を命ずる手法が開示されている。
【０００７】
特許文献３では、スケジュール情報の共有を目的として、他のユーザーのスケジュールを参照する仕組みと、会議等の共通するスケジュールの決定を容易とする仕組みとが開示されている。この特許文献３の図７では、太い実線の両矢印で示されたスケジュールは開始時間及び終了時間が確定している個人スケジュールで、太い点線の矢印は開始時間又は終了時間の一方が確定している個人スケジュールで、太い中抜きの矢印は、会議等で確定した共通スケジュールで、太い中抜きの矢印で、“？”マークが付されているものは、会議等の主催者から通知された共通スケジュールで、返信をしていないスケジュールである。“？”マークが付されている未確定状態は、参加又は不参加の返信を行うことで確定する。
【０００８】
【特許文献１】
特開２００２−１６９９３９号公報
【特許文献２】
特開２００１−１４７８７２号公報
【特許文献３】
特開平５−１６５８３６号公報
【特許文献４】
特開２００２−４９７２９号公報
【０００９】
【発明が解決しようとする課題】
上記各従来例では、第１に、会議の参加メンバーに依存する会議の成功の程度についての事務的及び心理的負担が、すべて会議主催者となるオーナーにもたらされてしまう、という不都合があった。すなわち、特許文献１では、会議参加の要請時に、招集ユーザー（参加者）について、会議との関係で、必須、準必須、任意等の参加者区分の指定を全て判断しなければならない。また、オーナーは、必須の招集ユーザーと判断した人の不参加をも見越して、代理参加者まで指定しなければならない。
【００１０】
第２に、特許文献２の全員強制参加の会議であれば、返信を待たずに予定を確定することができるが、その他の従来例では、オーナーは、出欠の有無の返信を待機し続けなければならず、スケジュールに不確定要素を含めたまま、他のスケジュールの調整などを行わなければならない。
【００１１】
第３に、特許文献２及び３の手法では、オーナーが複数の候補日を提案し、招集ユーザーの出欠の返答状況に応じて会議の趣旨に応じて、望ましい参加者が得られる候補日を開催日と決定することができない。特許文献１の手法では、複数の候補日を取り扱うことができるものの、参加者区分の指定を要請時に行うなど、オーナーの心理的・事務的な作業負荷が大きい。このように、従来例では、オーナーの心理的・事務的な作業負荷を小さくしつつ、複数の候補日の提案に応じたアポイントメントの調整を支援することができない。
【００１２】
第４に、上記各従来例及びその組み合わせでは、会議参加者の重要性判断の基準時を、オーナーの意思によって、スケジュールの確定時とすることは、できない。すなわち、アポイントメント自体の重要性と、各メンバー出欠の重要性とは、予定発生から、予定確定及び実施までの間で変化することがあり、このような場合には調整に関するオーナーの心理的・事務作業的負荷がより増大してしまう。予定の重要性の変化は、予定の発生時であるアポイントメントの要請時には十分に想定することができないため、簡単なアポイントメントと複雑なアポイントメントとの両方に自然に対応できるシステム開発が望ましい。
【００１３】
【発明の目的】
本発明は、アポイントメントの調整に関して、オーナーの手間を削減しつつ、アポイントメントの調整及び実際の会議等の開催に関して生産性を高めることのできるアポイントメント調整支援システムを提供することを、その目的とする。
【００１４】
本発明はまた、各ユーザーの予定やアポイントメントの重要性が刻々と変化する状況にあっても、オーナーの手間を増加させずに柔軟にアポイントメントの調整を行うことのできるアポイントメント調整支援システムを提供することを、その目的とする。
【００１５】
【課題を解決するための手段】
本発明の発明者は、アポイントメント調整は心理戦であり、人の取り合い、競争、予定の重複時の判断、変化への柔軟な対応などが必要となる点に着目した。すなわち、上記従来例は画一的で、定例的な会議等では役立つものの、残念ながら、柔軟性に欠け、定例から外れるような調整については、オーナー及びメンバーの作業負荷がかえって大きくなってしまう。
アポイントメント調整は、一般的に、要請、返答、確定の手順を取る。調整を何時行うかは、システムや組織によって異なる。
【００１６】
本発明の発明者は、第１に、電話や通常の電子メールの送受信によるアポイントメントの調整では、オーナーに心理戦のすべての負荷がかかってしまい、且つ、単純な手数を考察しても、オーナーの作業負荷が大きい点に着目した。
第２に、アポイントメント自体や、メンバー各自の出欠の重要性が、アポイントメント調整中に変化する点に着目し、心理戦をさらに複雑としている点を解決すべきであるとの着想に至った。
第３に、上記分析により、各ユーザーの出欠の重要性が、他のメンバーの出欠によっても変化することに着目した。
【００１７】
そこで、請求項１に係る本発明では、複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備えている。
そして、データベースが、ユーザーテーブルと、アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備えている。
本発明では特に、サーバーが、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、当該アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御部と、前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを前記返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御部とを備えている。
そして、この調整制御部が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する他ユーザー出欠参照制御機能を備えている。本発明は、これにより、前述した課題を解決する。
【００１８】
請求項１等に係る本発明では、要請制御部が、オーナーによって入力されるアポイントメントの要請データを招集ユーザーに送信し、調整制御部が、招集ユーザーからの返信の有無及び内容を返信状態データとして管理する。そして、他ユーザー出欠参照制御機能が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する。従って、それぞれの招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知する。すると、それぞれの招集ユーザーは、自らが返信する際に、他の招集ユーザーの出欠を参照することができ、すると、当該アポイントメントについての招集ユーザー自身の必要性を自ら判断することができる。招集ユーザー自らが自分の出欠の重要性を判断し、その上で出欠の返答を行うため、招集（人繰り）に関するオーナーの心理的な負担や判断作業の負荷を軽減することができる。
【００１９】
請求項３等に係る本発明では、さらに、前記調整制御部が、前記オーナーによって使用される端末に前記返信状態データを送信すると共に、当該返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する強制調整制御機能を備えている。本発明は、これにより、前述した課題を解決する。
請求項３等に係る本発明では、強制調整制御機能が、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データ（請求項２の引用では返信コメントを含む）と、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。すなわち、要請時に強制的に招集ユーザーの参加を命ずるのではなく、オーナーが判断の判断によるオーナーの意思に基づいたアポイントメントの確定時に、招集ユーザーの出欠を強制的に調整することができる。
【００２０】
【発明の実施の形態】
次に、本発明の実施の形態を説明する。
＜第１実施形態＞
第１実施形態では、アポイントメントの調整に関して、オーナーの手間を削減するという課題に対して、他ユーザーの出欠を参照する機能や、オーナーによる強制調整制御機能の構成と有用性とを開示する。
【００２１】
図１は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図であり、図２は本実施形態で使用するデータ構造の一例を示す説明図である。
図１を参照すると、本実施形態によるアポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。
【００２２】
そして、データベース２は、図２に示すように、ユーザーテーブル３０と、アポイントメント予定テーブル３２とを備えている。アポイントメント予定テーブル３２は、アポイントメントのオーナーとなるユーザーから、当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントに関して、そのアポイントメントの内容、場所及び日時などを含む要請データを格納する。アポイントメント予定テーブル３２は、この要請に対する招集ユーザーからの返信データの有無と、返信の内容（出欠等）とを返信状態データとして格納する。
【００２３】
再度図１を参照すると、サーバー１０は、要請制御部１４と、調整制御部１６とを備えている。要請制御部１４は、まず、前記データベース２と接続し、前記オーナーによって使用される端末１と通信して、当該アポイントメントの要請に関する要請データの入力を促す。要請制御部１４は、続いて、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する。
【００２４】
調整制御部１６は、前記データベース２と接続し、まず、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促す。調整制御部１６は、続いて、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを前記返信状態データとして前記アポイントメント予定テーブル３２を用いて管理する。
【００２５】
そして、本実施形態では特に、この調整制御部１６が、他ユーザー出欠参照制御機能１８を備えている。他ユーザー出欠参照制御機能１８は、前記アポイントメント予定テーブル３２を参照して、全ての招集ユーザー及びオーナーによって使用される各端末１に全ての招集ユーザーについての前記返信状態データを送信する。
【００２６】
他ユーザー出欠参照制御機能１８は、アポイントメント予定テーブルを参照して、招集ユーザーによって使用される端末や、オーナーによって使用される端末に、招集ユーザー全員の返信状態データを送信する。従って、各招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知することができ、それぞれの招集ユーザーは、他の招集ユーザーの出欠を参照することで、当該アポイントメントについての招集ユーザー自身の必要性を判断することができる。すると、招集に関するオーナーの心理的な負担や判断に必要な時間を軽減することができる。
【００２７】
本実施形態では、好ましくは、調整制御部１６が、返信コメント制御機能２０を備える。返信コメント制御機能２０は、招集ユーザーに当該要請についての返信コメントの入力を促し、続いて、当該招集ユーザーによって入力される返信コメントを前記返信データに合成する。返信コメント制御機能２０が、招集ユーザーの返信コメントを返信データに合成すると、返信データに返信コメントが含まれるため、他ユーザー出欠参照制御機能１８は、この返信コメントを含む返信データを他の招集ユーザーに通知する。すると、招集ユーザーは、アポイントメントの要請への返信である返信データの作成時に、他の招集ユーザーの返信コメントを参照することができる。従って、招集された招集ユーザーは、他の招集ユーザーの返信コメントによる各自の状況等を鑑みて、自らの出欠を判断することができる。これは、アポイントメントに関して、各招集ユーザーの積極的な判断を促し、これにより、参加者の調整のためのオーナーの連絡や判断等の負荷を減少させることができる。
【００２８】
図３を参照すると、図３（Ａ）に示す要請データ１４ａでは、オーナーによって候補日が２つ提案されている。アポイントメントの内容は販売店支援であり、場所は販売店のある○○○地区である。招集ユーザーは、ユーザーＢからユーザーＥまでの４人である。図３では、要請データ及び調整データは、電子メールとしても良いし、Ｗｅｂページ（画面）としてもよい。
【００２９】
図３（Ｂ）に示す調整データ１６ａは、招集ユーザーＢ用である。招集ユーザーＢが返信を試みた時点で、招集ユーザーＤ及びＥが返信を完了しており、招集ユーザーＣは返信待ちとなっている。他ユーザー出欠参照制御機能１６は、図３（Ｂ）に示すように、招集ユーザーＢ向けの調整データに、他の招集ユーザーである招集ユーザーＤ及びＥの返信データの内容（出欠）と、招集ユーザーＢが未返信であることが含まれる。
【００３０】
招集ユーザーＢは、図３（Ｂ）の返信状態データ１６ａ（調整データ）を参照する。ユーザーＢは、第１候補日には所要が入っていたため、第１候補日となった場合には、ユーザーＡに任せることとして、欠席を表明することとした。また、招集ユーザーＢは、新人教育に関して招集ユーザーＣが積極的に盛り上げ役を引き受けてくれることを知っており、この点、オーナーはまだ知らないかもしれない、と考え、次の返信コメントを記載する。「新人参加の販売店支援ですね。またＣさんの盛り上げを期待しています。第１候補日は、所用ありです」。
【００３１】
本実施形態では、オーナーによる招集ユーザーの出欠の強制調整制御機能をシステム的に実現する。この例では、調整制御部１６が、強制調整制御機能２２を備える。強制調整制御機能２２は、まず、オーナーによって使用される端末１に返信状態データを送信する。この機能２２は、続いて、この返信状態データを参照するオーナーに、前記招集ユーザーの出欠の強制調整操作を促す。そして、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。
【００３２】
強制調整操作は、返信データの有無や内容にかかわらず、オーナーの判断で、各招集ユーザーの参加を強制するための操作である。例えば、図３（Ｃ）に示す例では、招集ユーザーＣは未返信であるが、オーナーの判断として招集ユーザーＣに参加を命ずることとし、調整データ中の招集ユーザーＣについて強制参加を選択した。すなわち、強制調整操作として符号２２ａのチェックボックスをチェックした。オーナーによる強制調整は、招集ユーザーの返信データの強制的な上書きである。オーナーによって強制調整され、確定された場合には、強制調整された返信状態データは確定予定データとなる。例えば、符号２２ｂの確定ボタンをクリックし、第２候補日で確定すると、第１候補日のアポイントメントは取り消しとなり、また、第２候補日に参加と返信した招集ユーザーと、強制調整によって参加とされた招集ユーザーについては、第２候補日での予定が確定する。
【００３３】
このように、強制調整制御機能２２は、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合に、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データ（返信コメント制御機能２０を有する場合には、返信コメントを含む）と、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。これにより、アポイントメントを早期に確定することができる。さらに、各招集ユーザーの重要性の判断を、オーナーによる確定時まで遅らせるこができる。これにより、実際のニーズにあった柔軟なアポイントメント調整を実現することができる。そして、システムの機能としてオーナーに出欠の強制的な調整の権能を付加することで、オーナーがリーダーシップを発揮しやすい仕組みを導入することができる。
【００３４】
強制調整制御機能２２と関連して、調整制御部１６が、同時確定制御機能２４を備えると良い。この例では、同時確定制御機能２４は、オーナーによって前記各招集ユーザーの出欠について強制調整操作なされた後、一回の確定操作で、当該強制調整操作された返信状態データを前記確定予定データとして、全招集ユーザーについて当該アポイントメントを同時に確定させる。図３（Ｃ）に示す例では、強制調整操作と、候補日の確定とにより、全招集ユーザーの予定が確定する。
【００３５】
この同時確定制御機能２４により、オーナーは、招集ユーザーに対する相談の順序などを考慮せずに、オーナーの全員への一体的な命令としてアポイントメント調整を完了させることができる。また、同時確定制御を標準的な仕組みとすることで、招集ユーザーの自発的で積極的な判断を促すことができ、さらに、招集ユーザーの人間関係に沿った順序で個別に相談するという心理的、事務的な負荷からオーナーを解放することができる。
【００３６】
本実施形態による強制調整は、代行的使い方と、強制参加的使い方とがある。代行的使い方では、強制調整制御機能２２は、前記強制調整操作があった返信データを、前記返信状態データによって返信待ちである招集ユーザーの返信データの作成を当該オーナーが代行した代行返信データとして管理する機能を備える。たとえば、オーナーが、端末１を使用した連絡が困難な招集ユーザーについて、アポイントメントの確定時に、電話などの他のコミュニケーション手段によって出欠等の確認をとれた場合に、オーナーは、当該招集ユーザーの代わりに端末を操作して、当該招集ユーザーの返信データを生成することができる。これにより、出欠等を確認しているのに、それを連絡するための端末の操作が遅れることで、全員へのアポイントメントの確定が遅れてしまうような事態の発生を防止することができる。このように、オーナーが強制的に返信データを作成することができると、オーナーの意思と作業とによって、実際の電話等を含めたアポイントメントの調整の状態と、システム的な状態とを一致させ、オーナーの意思のみで確定することができる。このため、オーナーは、一定の時期に集中的にアポイントメントに関するすべての問題の解決に取り組むことができる。例えば、図３（Ｃ）に示す場合で、オーナーは、招集ユーザーＣが第２候補日で参加できるのであれば第２候補日とし、参加できなければ、第１候補日と考えていたとする。オーナーは、招集ユーザーＣの携帯電話や個人メールアドレスなどに連絡し、第２候補日での参加の了解を得られたとする。この場合に、オーナーは、招集ユーザーＣの代わりに返信データを作成するように、チェックボックス２２ａをチェックすることで、強制調整操作を行う。
【００３７】
また、強制調整操作を、強制参加命令とすることもできる。この場合、強制調整制御機能２２は、前記返信状態データによって返信待ち又は不参加である招集ユーザーに当該オーナーの判断で強制的に参加が命じられた場合に、当該強制参加対象の招集ユーザーの返信データを強制的に参加に設定した強制参加返信データとして管理する機能を備えると良い。この例では、招集ユーザーに対して強制参加を命じる機能をオーナーに与えることで、オーナーは、招集ユーザーからの返信状況にかかわらずアポイントメント調整を完了させることができる。また、アポイントメントの要請後に事情が変化したときには、オーナーがアポイントメントを確定させようとした時点の事情に基づいて、招集ユーザーやその人数を一時期に集中して判断することができる。逆に、招集ユーザーは、参加してもしなくてもよいアポイントメントに対しては、返信を行わなくとも、事後的にオーナーの判断で出欠が確定されるため、判断の難しいアポイントメントへの参加の有無について判断する作業から解放される。
【００３８】
そして、他ユーザー出欠参照制御機能によって招集ユーザー間の自主的で自発的なアポイントメントの調整がなされ、そして、招集ユーザーの自発的な調整が不首尾であった点については、オーナーの権限による強制的な調整がなされる。このように、アポイントメントの調整について、招集ユーザー間の自発的な調整と、オーナーの強制的な調整との組み合わせをシステム的に実現することで、招集ユーザー自身の積極性を向上させ、オーナーの心理的負担を軽減し、招集ユーザー及びオーナーの事務的な連絡回数等を減少させることができ、これにより、アポイントメントの調整が必要な作業について生産性を向上させることができる。
【００３９】
強制調整制御機能２２による強制参加命令の仕組みを前提とすると、返信データは、出欠に関しては、返信を保留することを示す保留コードを有さずに参加コード（○）及び不参加コード（×）のみを有すると良い。すなわち、返信データが、出欠に関して、参加（○）または不参加（×）のみであり、返信保留（△）を有さない仕組みでは、返信保留を伝えるための返信データの作成及び送受信等の操作を行う必要性が無く、返信を保留する招集ユーザーは、単に返信データの作成を行わない、とする仕組みを実現できる。そして、オーナーによる強制調整の機能を前提とすると、返信保留を伝えるために返信データを作成し送信する必要性はほとんどなく、従って、返信保留の返信という不要なデータの送受信を無くすことができる。
【００４０】
また、返信保留という返信を無くすことで、オーナーは、返信待機の状態を返信保留の一種であると判断することができる。特に、日程等が合わない招集ユーザーは、返信コメントなどで早期にその旨を主張することで、代わりの招集ユーザーの参加を促すことができるため、返信待機は、オーナーによる強制参加命令を受けることができる状態の消極的意思表示ともなる。従って、返信保留を無くし、参加又は不参加のみの返信とすると、要請があった場合に、早期に返信データを入力し送信しないと、強制参加命令を受ける消極的意思表示であるとオーナーによって判断される可能性が高まり、逆に、各招集ユーザーに早めの返信を促すこととなる。すなわち、返信保留の返信を無くすことで、早期の判断が促され、アポイントメント調整時間を短くし、これにより、オーナーの負荷を軽減することができる。
【００４１】
好まし実施形態では、アポイントメントの調整のみならず、各ユーザーの予定の管理を行う。この場合、図２に示すように、データベース２は、各ユーザーの予定データを格納する通常予定テーブル３４を備える。
【００４２】
再度図１を参照すると、この例では、サーバー１０が、データベース２に接続し、ユーザーによって使用される端末１と通信し、前記通常予定テーブル３４に格納された各ユーザーの予定データを当該端末１へ送信するユーザースケジュール送信部１２を備えている。各ユーザーの予定データは、例えば個人のスケジュール管理に用いる予定データであり、内容や開始時刻などのフィールドを有する。ユーザースケジュール送信部１２は、アポイントメントの要請を行うオーナーに招集候補者となるユーザーの予定データを送信する。また、返信データを作成する招集ユーザーに、他の招集ユーザーの確定している予定データを送信するようにしても良い。
【００４３】
ユーザースケジュール送信部１２が、各ユーザーの予定データを端末１に送信するため、ユーザーであるオーナーは、アポイントメントの日程の提案に際して事前に各招集ユーザーの予定を参照することができる。要請データを受信した招集ユーザーも、ユーザースケジュール送信部１２によって送信される他の招集ユーザーの予定データを参照することができる。そして、他ユーザー出欠参照制御機能１８による制御によって、招集ユーザーは、他のユーザーの出欠状況及び当該要請以外の予定とを参照して、自らの出欠を判断することができる。さらに、各招集ユーザーが、他のユーザーの出欠と、要請以外の予定とを参照しつつ、出欠を決定した前提で、なお残存している調整については、強制調整制御機能２２によってオーナーの権限と作業とで調整がなされる。
【００４４】
サーバー１０は、さらに、オーナーによって確定された返信状態データである確定予定データを通常予定テーブル３４での各ユーザーの予定データとして格納する確定予定データ制御部２６を備えるとよい。確定予定データ制御部２６は、オーナーによって確定された確定予定データをオーナー及び参加する招集ユーザーの予定データとして、通常予定テーブル３４に格納する。すなわち、例えば、第１のオーナーによって第１のアポイントメントが確定されると、この第１の確定した予定データを各招集ユーザーの予定データとして格納する。従って、第２のアポイントメントを調整する第２のオーナーは、この確定した第１の予定データを参照しつつ、第２のアポイントメントの要請を作成することができる。これにより、複数のアポイントメントの調整で日程が重なり合う状況にあっても、確定した予定についてはすべての招集ユーザーについて確定とほぼ同時に予定データとすることができ、アポイントメントの調整における人の取り合いという面からは、早期にアポイントメントを確定することで、早期に人材の確保を行うことができる。
【００４５】
図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。本実施形態によるアポイントメント調整支援処理は、参加の要請の作成及び通知をする要請制御工程（Ａ１，Ｂ１等）と、アポイントメントの出欠や候補日選定を調整する調整制御工程（Ｂ３，Ｂ４等）と、アポイントメントを確定する確定工程（Ａ５，Ｂ５等）とを備える。
【００４６】
要請制御工程では、まず、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促す（ステップＡ１）。そして、要請制御工程では、オーナーによって要請データが入力されると、この入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する（ステップＢ１，Ｂ２）。この要請データの送信は、電子メールによる通知でもよいし、個人カレンダーを使用する例では、個人カレンダーのカレンダー内又は個人カレンダー画面のエリアへの表示処理としてもよい。個人カレンダーを使用する例では、オーナーの個人カレンダーにも当該要請データを表示する。
【００４７】
調整制御工程では、まず、データベース２と接続し、そして、要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによるアポイントメントの要請への出欠等の返信データの入力を促す（ステップＢ３）。このとき、ステップＢ３は、アポイントメント予定テーブル３２を参照して、全ての招集ユーザーによって使用される端末に、他の全招集ユーザーの返信状態データを送信する（ステップＢ４，他ユーザー出欠参照制御工程）。招集ユーザーの返信状態は、オーナーによって使用される端末でも逐次参照できる（ステップＡ３）。
【００４８】
調整制御工程では、続いて、オーナーによって使用される端末１と通信して、前記アポイントメント予定テーブル３２に格納された返信状態データを当該端末１に表示する（ステップＡ３）。続いて、当該オーナーにアポイントメントの強制調整操作を促し、そして、未返信の招集ユーザーや、不参加と返信した招集ユーザーの出欠について、オーナーが強制的に参加へと強制調整した場合には、当該強制調整操作のなされた返信状態データを最新の返信状態データとして管理する（ステップＡ４）。
【００４９】
確定制御工程では、オーナーによって使用される端末と通信して、前記返信状態データに対して、当該オーナーによってアポイントメントの確定操作がなされた場合には、当該確定された返信状態データを確定予定データとして管理する（ステップＡ５）。確定制御工程は、さらに、確定予定データを、全ての招集ユーザーに通知する（ステップＢ５）。そして、参加が確定した招集ユーザーの個人カレンダーに確定した予定を通常予定として表示する（ステップＢ６）。また、オーナーの個人カレンダーにも通常予定として表示する（ステップＡ６）。
【００５０】
図１に示す構成や、図４に示す処理工程は、サーバーのＣＰＵが所定のプログラムを実行することで実現することができる。本実施形態によるシステム（アポイントメント調整支援システム）のＣＰＵ（図示せず）は、所定のプログラム（指令）に従って各種の演算を行う。ＣＰＵは、各種の処理要求に従って、データベース２を駆動して、各種のページ（画面）の生成や、電子メールの送信・解析などを実行し、その実行結果を端末１に送信する。ＣＰＵがアポイントメント調整支援用のプログラムを実行することで、システムは、調整データの生成や、入力される返信データの管理等を処理する。
【００５１】
本実施形態では特に、アポイントメント調整支援処理用プログラムは、各ユーザー間のアポイントメントの調整作業を支援するための各種の指令を備える。このプログラムは、サーバーを動作させる指令として、例えば、他ユーザー出欠参照制御指令を備える。本実施形態によるシステムのＣＰＵは、この他ユーザー出欠参照制御指令を実行することで、図４に示すステップＢ４の処理を実行し、また、図１に示す他ユーザー出欠参照制御機能１８として動作する。その他、このプログラムが、本実施形態によるシステムにて実現すべき各部，各機能や、フローチャートの各工程に応じた指令を備えることで、ＣＰＵは対応する処理を行う。
【００５２】
本実施形態では、アポイントメント調整支援処理用プログラムが、サーバーのＣＰＵを動作させる指令として、下記の指令を備える。
前記データベース２へ接続し、前記オーナーによって使用される端末１と通信して、アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信するための要請制御指令（ステップＡ１及びＢ１，要請制御部１４に対応）。
前記データベース２へ接続し、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブル３２を用いて管理するための調整制御指令（ステップＢ３，調整制御部１６に対応）。
前記データベース２へ接続し、前記オーナーによって使用される端末１と通信して、前記アポイントメント予定テーブル３２に格納された返信状態データを当該端末１に表示して、当該オーナーによってアポイントメントの確定操作がなされた場合には当該確定された返信状態データを確定予定データとして管理するための確定制御指令（ステップＡ５及びＢ５，確定予定データ制御部２６）。
調整制御指令の一部として、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信するための他ユーザー出欠参照制御指令（ステップＢ４，機能１８に対応）。
調整制御指令の一部として、返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによって各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを最新の返信状態データとして管理する強制調整制御指令（ステップＡ４，機能２２に対応）。
【００５３】
さらに、このプログラムが、同時確定制御指令を備えることで、ＣＰＵは、同時確定制御機能２４として動作することができる。同時確定制御指令は、オーナーによって前記各招集ユーザーの出欠について強制調整操作なされた後の処理について、ボタンへのクリックなどの一回の確定操作があったときに、当該強制調整操作された返信状態データを前記確定予定データとして、全招集ユーザーについて当該アポイントメントを同時に確定させる。同時に確定というのは、例えば、調整中として扱っていた要請データや返信状態データを、通常の確定した予定データに変換する処理である。
【００５４】
このプログラムは、ディスクや磁気テープ（ＭＴ）等の記録媒体１１Ａに格納されて搬送され、ディスクドライブ１１によって読み取られる。記録媒体１１Ａに格納されていたプログラムは、ディスクドライブ１１にて読み取られた後、プログラム記憶部１１Ｂに格納される。また、他のホスト装置から通信回線を経由してプログラム記憶部１１Ｂに当該プログラムを提供することもできる。
【００５５】
プログラムについて、ＣＰＵを「動作させる指令」というときには、各指令のみでＣＰＵを動作させる指令と、プログラム記憶部１１Ｂに予め格納されているオペレーティングシステム等の他のプログラムに依存して当該ＣＰＵを動作させる指令とのいずれかまたは双方を含む。ここでは、「オペレーティングシステム」は広義に解釈している。データベースマネージャーや、トランザクションマネージャー等を含む。
【００５６】
上記他ユーザー出欠参照制御指令は、実際には、データベースマネージャーに予定ＩＤをキーとするＳＱＬ文を発行し、検索結果をＨＴＭＬのページゼネレーターに引き渡す指令のみのみとして、テーブルからの検索処理や抽出処理は実際に指は指令そのものの実行ではなく、データベースマネージャーが行うようにしても良い。このように、プログラムを記憶する記録媒体１１Ａであって、当該プログラムをユーザーへ搬送する用途の記録媒体１１Ａには、例えば「所定のデータベースマネージャーにＳＱＬ文を引き渡す指令」のみが格納され、実際のデータの検索はオペレーティングシステム等の実行環境によって行われる場合がある。これは、動作させようとするコンピュータのオペレーティングシステムやデータベースマネージャー等との関係で定まる。この点、通信回線を介してプログラム（指令）を提供する場合も同様である。
【００５７】
このプログラムとシステムの部，機能又は方法の工程との関係や、媒体等に関する説明は後述する実施形態、実施例においても同様である。特に、同一の名前が付されている機能、工程、指令のそれぞれが対応する点は、各実施形態においても同様である。例えば、アポイントメント調整支援処理用プログラムは、実施例の確定処理制御部６０の機能実現するには、その機能を実現するための確定処理制御指令を備える。確定処理制御指令は、図１４に示す各工程に対応する指令を備える。
【００５８】
＜実施例＞
図５は、本実施例の構成例を示すブロック図であり、図６は、本実施例でのデータ構造の一例を示す説明図である。図６に示す各テーブルのフィールド名の一例を図７に示す。本実施例では、実施例では、Ｗｅｂサーバーと、ＨＴＭＬ等のマークアップランゲージで記述された画面（ページ）を表示するブラウザを備えた端末とを使用する例を開示する。
【００５９】
本実施例では、アポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー（Ｗｅｂサーバー）１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。そして、データベース２は、図６及び図７に示すように、ユーザーテーブル３０と、アポイントメント予定テーブル３２と、通常予定テーブル３４と、予定メインテーブル３６とを備える。本実施例では、図６に示すように、通常予定テーブル３４と、アポイントメント予定テーブル３２とを、予定メインテーブル３６の予定種類コードによって使い分けている。
【００６０】
ユーザーテーブル３０は、前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納する。
予定メインテーブル３６は、予定を識別する予定ＩＤ毎に、前記ユーザーＩＤと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データと、アポイントメント等で予定する場所である予定場所データとを格納する。
通常予定テーブル３４は、前記予定ＩＤ毎に、予定開始日時データと、予定終了日時データとを格納する。
アポイントメント予定テーブル３２は、候補日順位毎の前記予定ＩＤ毎に、当該予定ＩＤのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーＩＤと、当該オーナーと招集ユーザーとを識別すると共に当該招集ユーザーの順序を指定するアポイントメントユーザー順位と、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納する。
予定ＩＤは、オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合には、候補日順位毎に個別のＩＤとすると良い。また、アポイントメントの調整によって確定した予定については、単一の予定ＩＤとし、予定内容データや、予定場所データや、予定開始日時や、予定終了日時については、各ユーザーで共通のデータを使用すると良い。この場合、確定したアポイントメントの予定については、各ユーザーは個別の編集を行うことはできない。また、予定ＩＤをユーザー毎として、確定したアポイントメントの予定を各ユーザーが編集できるようにしても良い。
【００６１】
図７に各テーブル３０，３２，３４，３６の各フィールドの内容を例示する。図７に示すように、予定の種類を示す予定種類コードは、確定している通常予定を“０”、アポイントメントの調整中であるアポイントメント予定を“１”、通常予定のうち毎週同時刻等の繰り返し予定を“２”としている。アポイントメントユーザー順位は、オーナーを“０”とし、招集ユーザーは“１”から順に付番する。アポイントメント候補日順位は、アポイントメントの候補日が複数ある場合に、これを識別する番号となる。本実施例では、出欠フラグは二種類のみとし、参加を“１”、不参加を“０”とし、返信保留を示すデータ構造はない。従って、出欠についてはフラグとしている。
【００６２】
再度図５を参照すると、サーバーは、要請作成画面生成部５０と、要請データ格納制御部５２と、要請データ通知制御部５４と、調整画面生成部５６と、返信データ格納制御部５８と、確定処理制御部６０とを備える。また、図８に示す招集候補となるユーザーの予定を表示するカレンダー画面制御部５１を備えるようにしても良い。本実施例による処理は、Ｗｅｂサーバーを用いて、特徴的な画面を使用して、図４に示すアポイントメント調整支援処理をより詳細に開示するものである。本実施例では、「画面」は、端末１のブラウザ等で表示されるＨＴＭＬ等のマークアップ言語によって記載され、端末１のユーザーによって入力される入力フィールドやチェックボックスやポップアップメニューなどの選択肢の定義を含むファイルである。
【００６３】
要請作成画面生成部５０は、オーナーによって使用される端末１からアポイントメントの要請を作成するための要請作成画面４２の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促すための要請作成画面４２（例えば、図９に示す画面）を生成する。図４に示す例では、要請作成画面生成部５０は、ステップＡ１の処理を行う。
【００６４】
要請データ格納制御部５２は、まず、要請作成画面が生成されたときに、前記オーナーによって使用される端末へ当該要請作成画面４２を送信する。そして、当要請データ格納制御部５２は、オーナーによって当該要請作成画面に入力される要請データを受信する。この制御部５２は、さらに、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納し、一方、要請作成画面４２のその他の各フィールドの内容を前記アポイントメント予定テーブルに格納する。要請データ格納制御部５２は、例えば、図１３に示すフローチャートを実行する。図４に示す例では、要請データ格納制御部は、ステップＡ１の処理を行う。すなわち、本実施例では、図１３に示すフローチャートはステップＡ１の詳細処理である。
【００６５】
要請データ通知制御部５４は、前記招集ユーザーによって使用される端末に、前記各テーブルに格納された当該要請データを通知する。この通知には、電子メールを使用しても良いし、各招集ユーザーが日常的に使用する画面（例えば、図１０のカレンダー画面４４）に新しい未返信の要請データを表示することで通知しても良い。図４に示す例では、要請データ通知制御部５４は、ステップＢ１及び／又はＢ２の処理を行う。
【００６６】
調整画面生成部５６は、招集ユーザーによって使用される端末から、アポイントメントの要請に対する返信を作成するための調整画面４６の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面４６（例えば、図１１に示す画面）を生成する。図４に示す例では、調整画面生成部５６は、ステップＢ３の処理を行う。
【００６７】
本実施例では、調整画面生成部５６が、他ユーザー出欠参照制御機能６２を備えている。この機能６２は、第１実施形態等の機能１８と同様の作用効果を有する。すなわち、本実施例では、他ユーザー出欠参照制御機能６２は、招集ユーザーによって使用される端末１から調整画面４６の表示指令を受信したときに、予定ＩＤをキーとしてアポイントメント予定テーブル３２を参照する。そして、アポイントメント予定テーブル３２から、他の招集ユーザーのユーザー名、出欠フラグ及び返信コメント読み出して、前記調整画面４６にて合成する。図４に示す例では、他ユーザー出欠参照制御機能６２は、ステップＢ４の処理を行う。
【００６８】
返信データ格納制御部５８は、まず、前記調整画面４６が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面４６を送信する。制御部５８は、続いて、当該招集ユーザーによって当該調整画面に入力される返信データを受信する。さらに、制御部５８は、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する。図４に示す例では、返信データ格納制御部５８は、ステップＢ３の処理を行う。
【００６９】
本実施例では、調整画面生成部５６が、確定用調整画面生成機能６４を備える。確定用調整画面生成機能６４は、オーナーによって使用される端末１から、確定用調整画面４８の表示指令を受信した場合には、前記予定ＩＤをキーとしてアポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出する。確定用調整画面生成機能６４は、続いて、各招集ユーザーの出欠に関して強制参加チェックボックスを付加した確定用調整画面４８（例えば、図１２に示す画面）を生成する。図４に示す例では、確定用調整画面生成機能６４は、ステップＡ３の処理を行う。
【００７０】
調整画面生成部５６は、さらに、強制調整制御機能６６を備える。強制調整制御機能６６は、第１実施形態等の強制調整制御機能２２と同様の作用効果を奏する。すなわち、強制調整制御機能６６は、前記オーナーによって、前記確定用調整画面４８の前記強制参加チェックボックス４９がチェックされた招集ユーザーの出欠について、これを強制的に参加として確定する。強制調整制御機能６６は、当該招集ユーザーの通常予定テーブル３４に当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する。図４に示す例では、強制調整制御機能６６は、ステップＡ４の処理を行う。
【００７１】
確定処理制御部６０は、オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブル３２を参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する。確定処理制御部６０は、例えば、図１４に示すフローチャートを実行する。図４に示す例では、確定処理制御部６０は、ステップＡ５の処理を行う。すなわち、図１４に示すフローチャートは、本実施例でのステップＡ５の詳細処理である。
【００７２】
カレンダー画面制御部５１は、図８及び図１０に示すカレンダー画面の生成を制御する。このとき、カレンダーフィールドへの予定の表示については、図１５に示すフローチャートを実行し、予定メインテーブルの予定種類コードに応じた色分け等の処理をしてもよい。
【００７３】
＜事例１＞
次に、画面を参照して具体的な使い方を説明する。ここでは、次の状況設定と、登場人物とを設定する。
【００７４】
状況設定： オフィス家具大手Ｋ社の販売課長、阿部氏は、顧客であるＰ社の自社ビル新築に伴うオフィス家具購入の案件で家具配置プランの提案を行っていた。コンセプトを提案するプレゼンテーションを数回行い、Ｐ社の要望をインタヴューし、次回はこのＰ社の要望を反映した実施プランの提案を持ち込むことになっていた。ビルの着工は来期ということもあり、当面Ｐ社の意思決定はないものと思われた。次回プレゼンテーションの候補日として、Ｐ社からは翌週の木曜日と金曜日がＯＫとの回答を得ていた。早急に社内のメンバーのアポイントメントを取り、調整をすることとなった。
【００７５】
登場人物： プロジェクトのリーダー阿部は、メンバーのプレゼンテーションの日程を調整する立場にある。営業マン海老沢、設計担当者山田、和田、鈴木。
アポイントメントの内容は、Ｐ社実施プラン提案、オーナーは阿部、招集ユーザーは海老沢、山田、和田、鈴木である。
【００７６】
図８は、ユーザー予定データ表示画面の一例を示す説明図である。図８から図１２に示す画面の例は、パーソナルコンピュータ等でブラウザー・アプリケーションを使用してサーバー１０から送信されるデータを画面として表示している状態を示す。図中の下線はリンクであり、他の画面への表示指令となる。
【００７７】
カレンダー画面制御部５１は、アポイントメントのオーナー向けにプロジェクトや部署に属するユーザーの登録されている予定を表示するユーザー予定画面４０（実際には、カレンダー画面４４）を生成する。阿部氏は、図８に示すユーザー予定画面を表示し、メンバーの空きスケジュールを確認する。すると、木曜日は海老沢氏、山田氏及び和田氏に先約があり、金曜日には全てのメンバーに予定がない。オーナーは、一応両日を候補日として提案することとする。オーナーである阿部氏は、図８のアポイントメントと表記されたアポイントメント・リンク４０ａに対してクリック等の操作をする。アポイントメント・リンク４０ａへの操作は、要請作成画面の表示指令である。
【００７８】
図９に、要請作成画面４２の一例を示す。阿部氏は、要請作成画面４２の内容フィールド４２ａにアポイントメントの内容を「Ｐ社訪問」と入力し、同様に場所フィールド４２ｂに「横浜」と場所を入力する。続けて、日付・時間エリア４２ｃのＧＵＩ部品を用いて、候補日と時間とを入力する。阿部氏は、コンボボックスとなっている日時フィールドを使用して日時を特定する。このとき、第１候補を金曜日（２４日）、第２候補を木曜日（２３日）とする。また、招集ユーザー特定用エリア７４を使用して、招集したいユーザーを選択する。この招集ユーザー特定用エリア７４については、第２実施形態で再度説明する。そして、要請するボタン４２ｅへの押下操作により、入力した要請データをサーバー１０に送信する。サーバー１０は、要請データ格納制御部５２が、図１３等に示す処理を行う。
【００７９】
図１０は、要請通知エリア４４ａ，４４ｂを有する個人カレンダー画面の一例を示す説明図である。招集ユーザーである山田氏は、自分のカレンダー画面４４を開くと、要請通知エリア４４ｂに阿部氏からの要請が表示されている。自分のスケジュール確認という普段の活動の中でアポイントメント要請に気づくことができるため、すぐに返信作業に移ることができる。そして、カレンダーのうち２４日金に、黒丸が付された状態で予定が記入されている。これは、要請データの招集ユーザーへの通知であり、招集ユーザーである山田氏は、個人のカレンダー画面４４を開くだけで、要請通知エリア４４ａに要請データの概要が表示され、且つ、自分の予定としてカレンダーに表示される。すなわち、要請データ通知制御部５４は、カレンダー画面制御部５１と協調して、各個人のカレンダーにアポイントメントの要請データをスケジュールとして表示することで、要請データの通知を行う。要請通知エリア４４ｂは、ボタンとなっており、この領域をクリックする操作は、調整画面４６の表示指令をサーバー１０に送信する。
【００８０】
また、要請データ通知制御部５４は、電子メールにてリアルタイムに要請データを送信するようにしてもよい。山田氏、返答を入力するためにひとまず返答画面（調整画面４６）を開いてみた。
【００８１】
図１１は、招集ユーザー用の調整画面４６の一例を示す説明図であり、ここでは招集ユーザーである山田氏用の調整画面である。山田氏は、海老沢氏と鈴木氏はすでに木曜日に×（不参加）、金曜日に○（参加）と回答しており、和田氏は未回答であることを把握する。山田氏は、木曜日にはすでに約束が入っている。さらに、このシステムには入力していないが、実は金曜日の該当時間は自己啓発のため毎週英会話学校に通っていた。今回が第一回のプレゼンであることと、鈴木氏が参加することが判ったので、彼に代表して説明してもらうこととした。木曜、金曜とも×（不参加）回答を記入する。参加又は不参加の入力は、コンボボックス４６ａ，４６ｂからの選択としている。また、調整画面４６の返信コメント入力フィールド４６ｃは、通常のテキスト入力を促す。
【００８２】
一方、和田氏は、別件で外出中につき、要請が来ていることにまだ気づいていない。偶然にも、外出先の顧客と金曜日に接待ゴルフの約束をしてしまった。オーナーである阿部氏が各メンバーの予定を参照したときには、和田氏は金曜日は空いていたが、このアポの手続き中に状況が変化した。
【００８３】
翌日、Ｐ社から阿部氏に突然連絡が入り、次回を最終のプレゼンテーションとして、これをもってオフィス家具購入決定の判断を行うと通告された。さらに、本日中に回答しないと、金曜日にＰ社側に他の用事が入ってしまう可能性があるとの連絡を受けた。
阿部氏は、このプレゼンの重要性が一気に上がったため、万全の説明体制と誠意をみせるため、できるだけ多くのメンバーを出席させ、さらに今日中に期日を確定してＰ社に返答する必要が生じた。阿部氏は、確定用調整画面４８を開く。
【００８４】
図１２は、オーナー用の調整画面（確定調整画面４８）の一例を示す説明図である。阿部氏は、×（不参加）回答の山田氏と、未回答の和田氏とをなんとしてでも参加させようと、両名の携帯に電話をした。両名とも外出中であったが、山田には英会話の中止、和田には先方とのゴルフの予定を変更してもらい、プレゼン参加の了解を取ることができた。しかし、両名ともパソコンを持ち歩いていないので、返信の入力とスケジュール記入ができないと主張した。
【００８５】
ここでメンバーへの確定の連絡が遅れると、○（参加）回答している海老沢氏や鈴木氏も重要度に変化があったことを知らせていないので、他のプロジェクトの予定とのブッキング発生の危険性がある。また、外出中の山田や和田もスケジュールへの記入忘れの懸念が残った。一方、阿部はすぐにでも期日を確定して、Ｐ社に連絡をいれ、全招集ユーザーに他の予定を入れないよう連絡する必要があった。
【００８６】
そこで、阿部氏は、山田氏と和田氏の調整画面４６の強制チェックボックス４９をチェックし、第１候補の確定ボタン４９ａを押した。この瞬間、全員に金曜日にプレゼンが決定した旨メールが発信され、正式なスケジュールとして全メンバーのカレンダーに記入された。幸い、Ｐ社担当者の金曜日の予定が埋まってしまう前に約束の連絡を取ることができた。図１２に示す例では、強制テックボックス４９へのチェックが、オーナーによる確定調整操作である。なお、オーナーは一旦要請したアポイントメントをその後の事情変化や参加者数などに応じてこの確定調整画面４８を用いて中止することもできる。中止を確定するには、符号４８ｂで示す中止ボタンをクリックする。中止指令を受信する確定処理制御部６０は、中止されたアポイントメントに関するレコードをすべて削除する。
【００８７】
図１３は、要請データ格納制御部による要請データの格納処理の一例を示すフローチャートである。図９に示す必須入力項目が入力され、オーナーによって要請するボタン４２ｅがクリックされると、端末１のブラウザは、入力された要請データにログインユーザーのユーザーＩＤ（ここでは、オーナー）を付加して、当該要請データをサーバー１０に送信する。サーバー１０は、要請データを受信すると、図１３に示す処理を開始する。すなわち、要請データ格納制御部５２は、まず、新しい要請データに対して、新しい予定ＩＤを取得する（ステップＳ１）。ここでは、要請データの候補日順位毎に予定ＩＤを取得する。続いて、アポイントメント候補日順位を“１”とする（ステップＳ２）。さらに、オーナーのアポイントメントユーザー順位を“０”とする。
【００８８】
続いて、アポイントメントユーザー順位を付するため、ｘ＝１とし（ステップＳ４）、招集ユーザーのアポイントメントユーザー順位をｘとする（ステップＳ５）。これを図９に示す「招集したいユーザー」全てについて完了するまで（ステップＳ６）、ｘの値をインクリメントして、アポイントメントユーザー順位を設定する。
【００８９】
アポイントメントユーザー順位を設定すると、続いて、図６に示すデータ構造のアポイントメント予定テーブル３２に、予定ＩＤ、ユーザーＩＤ、アポイントメントユーザー順位、候補日順位、予定開始日時、予定終了日時を格納する（ステップＳ８）。続けて、予定メインテーブル３６に予定ＩＤと、全ユーザーのユーザーＩＤと、予定種類コードと、予定内容データ（Ｐ社訪問）と、予定場所データ（横浜）とを格納する。予定種類コードは、ここではアポイントメント調整中の予定であることを示すコード“１”を格納する。これにより、予定ＩＤをキーとして、第１候補日順位についての要請データを格納した。各種の制御部は、予定ＩＤをキーとして予定メインテーブル３６を参照すると、当該予定ＩＤで識別される予定が通常予定であるのか、それともアポイントメント調整中の予定であるかを特定することができる。
【００９０】
続けて、次の候補日順位のデータがあるか否かを確認し（ステップＳ１０）、ここでは、第２候補日順位のデータがあるため、ステップＳ１に戻り、第２候補日順位用の予定ＩＤを取得する。第２候補日順位についても同様に要請データをアポイントメント調整中の予定データとして格納し、第３候補日順位のデータはないため、処理を終了する。
【００９１】
図１４は、確定処理制御部６０によるアポイントメントの確定処理の一例を示すフローチャートである。端末１のブラウザは、図１２に示す最新の返信状態データの表示中に確定するボタン４９ａがクリックされると、この確定操作によるイベントはサーバーに送信する。また、ブラウザは、強制チェックボックス４９のチェックの有無もサーバー１０に送信する。確定するボタン４９ａは予定ＩＤと、候補日順位と関係しているため、サーバー１０は、端末１から、少なくとも、予定ＩＤと、候補日順位と、強制チェックボックス４９のオン／オフとを受信する。
【００９２】
サーバー１０では、確定処理制御部６０が、この確定操作を受信したときに、図１４に示す処理を開始する。まず、確定された候補日順位以外の順位の予定ＩＤに関するレコードを全て削除する（ステップＳ１１）。
【００９３】
続いて、確定された候補日順位の予定ＩＤからアポイントメント予定テーブル３２を検索して予定開始日時と予定終了日時とを読み出し、当該予定ＩＤと、予定開始日時と、予定終了日時とを新たに通常予定テーブル３４へ格納する（ステップＳ１２）。すなわち、確定した予定に関するデータを、アポイントメント予定テーブル３２から通常予定テーブルへ複写する。
【００９４】
さらに、当該予定ＩＤをキーとして、アポイントメント予定テーブル３２から招集ユーザーの出欠を順に確認する（ステップＳ１３）。招集ユーザーの探索順序は、アポイントメントユーザー順位の順序とし、ここでは、まず、順位“０”のオーナーである阿部氏について確認する。阿部氏の出欠フラグは“１”であるため、当該予定ＩＤと阿部氏のユーザーＩＤとで予定メインテーブルを検索し、その予定種類コードを“１”から“０”に変更する（ステップＳ１５）。すなわち、当該第１候補のアポイントメントを阿部氏の通常予定とする。そして、通常予定とした後に、該当するユーザーＩＤに関するアポイントメント予定テーブル３２のレコードを削除する。ステップＳ１６，Ｓ１３にて次に順位“１”の海老沢氏が特定され、同様に処理する。
【００９５】
山田氏については、ステップＳ１４にて、出欠フラグは“０”であるため、ステップＳ１７に進む。ステップＳ１７では、強制チェックボックスがオンであるか否かを確認し、強制チェックボックスがオンであるため、ステップＳ１５にて同様に予定種類コードを通常予定へ更新する。出欠フラグが格納されていない和田氏についても、強制チェックボックスがオンであるため、予定種類コードを通常予定とする。
【００９６】
予定種類コードが通常予定となると、各ユーザーの各カレンダー画面にて自分のスケジュールとして表示される。
【００９７】
図１５は、カレンダーへの予定表示処理の一例を示すフローチャートである。図８に示す個人カレンダー画面４４は、図中左上から、表示指定エリア４０ｃと、月／週指定エリア４０ｄと、要請通知エリア４０ｂとを備え、さらに、プロジェクト／部署選択コンボボックス４０ｆと、カレンダーテーブル４０ｇと、カレンダーフィールド４０ｈとを備えている。本実施例では、表示指定として、個人の月表示、部署の週表示及び日表示、プロジェクトの週表示及び日表示とを有する。図８に示す例では、表示指定はプロジェクトの週表示であり、コンボボックス４０ｆによりＰ社新築ビルプロジェクトというプロジェクトが選択されている。表示する週は、月／週指定エリア４０ｄの操作に応じて、２００３年１月１９日からである。
【００９８】
サーバー１０のカレンダー画面制御部５１は、端末１からカレンダー画面の表示指令を受信したときに、図８等に示すカレンダー画面の表示処理を行う。図１５に示すように、カレンダー画面制御部５１は、まず、ユーザーＩＤを参照して、設定情報等を読み出し、カレンダー画面の定型情報を生成する（ステップＳ２１）。ここでは、エリア４０ｃ，４０ｄなどである。続いて、カレンダー画面制御部５１は、表示指定に応じてカレンダーテーブルを生成する（ステップＳ２２）。週表示であれば、日曜から土曜までの列と、プロジェクトのメンバー数に応じた個数の行とを有する空のカレンダーテーブルを生成する。カレンダーテーブルの各フィールドを、ここではカレンダーフィールドという。
【００９９】
続いて、カレンダー画面制御部５１は、カレンダーテーブルの各カレンダーフィールドの表示処理を行う。すなわち、図８に示す例ではユーザーＩＤ毎に、通常予定テーブル３４とアポイントメント予定テーブル３２との予定開始日時を参照する。そして、カレンダーテーブル内の過去の日付から順にカレンダーフィールドを特定する（ステップＳ２３）。まず、阿部氏について１９日のカレンダーフィールドの特定では、両テーブル３２，３４に１９日の予定が格納されているか否かを探索し（ステップＳ２５）、格納されていないため、全日付完了したか否かを確認して（ステップＳ３０）、完了していないため、処理を２０日に移す。
【０１００】
２０日では、通常予定テーブル３４に、「戦略会議」との予定が格納されている。ステップＳ２４でイエスとなるため、予定の種類コード２５を参照して、通常予定であるため、予定日時を黒色に設定する。続けて、同日に他の予定がなければ（ステップＳ２９）、ステップＳ３０，Ｓ２３を介して２１日の処理を開始する。２１日には、山田氏からのアポイントメント要請があり、アポイントメント予定テーブル３２に１月２１日１３：００との予定開始日時が格納されている。ステップＳ２５では、予定種類がアポイントメント予定であるため、予定日時の文字表示を赤色に設定する。図面では、文字を赤色にする処理に変えて、黒丸４０ｅを付した。
【０１０１】
同様に２５日までの処理を行い、さらに、各ユーザーについて同様に予定を探索する。図１５に示す例では、アポイントメント予定と、通常予定とで表示する文字の色を変化させるため、アポイントメントの要請があったことを一見して把握することができる。
【０１０２】
予定データの読み出し及び色の設定が全て完了すると（ステップＳ３１）、カレンダーテーブルをＨＴＭＬ等のマークアップ記述言語で記述する。
【０１０３】
さらに、アポイントメント予定テーブル３２を参照して、要請通知エリア４０ｂに要請データを要請の日付順に記述する。この要請通知エリアは、調整画面を表示するためのボタンとする。
【０１０４】
＜事例２＞
上述した事例１では、企業活動を支援するための本実施例によるシステムの使い方を例示したが、企業のみならず、大学の研究室などでも活用できる。アポイントメントとしては、ゼミやセミナーなどのアポイントメントの外、実験設備の部品買い出しの約束や、コンパなどの約束形成にも使用することができる。本実施形態では、他ユーザー出欠参照制御機能６２を有するため、例えば、男性５人女性３人のグループでの飲み会の企画で、１人では参加できないと考える女性がいたとすると、他の女性の参加を確認してから参加の返信を行うこともできる。また、買い出しとコンパとを続けて行う場合に、コンパにのみ参加表明した招集ユーザーに対して、オーナーが強制的に買い物へも強制参加させるなど、オーナーのリーダーシップを引き出し、気持ちと情報の共有とに寄与することができる。
【０１０５】
＜事例３＞
我が国では、適度な控えめさが人間関係の潤滑油として機能している。そのような控えめさは、例えば、ある活動について、自分は立場的、経験的に未熟であるとして、参加しない行為を生む。本実施例のオーナーによる強制調整制御機能は、控えめな招集ユーザーに、参加を促す仕組みとなる。あるアポイントメントについて、控えめな招集ユーザーは、日程的な不都合はないが、控えめに不参加を表明する。これに対し、オーナーが強制参加命令を行う。そうすると、控えめな招集ユーザーは、自分が一旦は不参加を表明したこと、それにもかかわらずオーナーからの命令があったことを、なんら積極的な連絡のための作業をすることなく、他のユーザーに知っておいてもらうことができる（他ユーザー出欠参照制御機能）。
【０１０６】
図１６は、本実施形態及び本実施例による生産性向上を招集ユーザーの数との関係で説明する説明図であり、図１６（Ａ）はオーナーに必要な連絡回数を示す図で、図１６（Ｂ）は招集ユーザーに必要な連絡回数を示す図である。
一般的に、アポイントメントを取るには、電話や電子メールが利用されている。電子メールによるアポイントメントでは、オーナーは、候補日の問い合わせの発信を全員同報とすると、１回の作業で、電話では、（人数）回必要となる。本実施例では、要請データの入力は１回であるため、作業数は１回である。オーナーは、返信の受信について、電子メールの場合には（人数）回、電話では問い合わせと返信とを同時にできるとして、０回、本実施例では確定用調整画面に全員の返信が表示されるため、１回である。候補日の確定を連絡するには、電子メールでは全員同報で１回、電話では（人数）回、本実施例では１回である。予定が確定したとして、スケジューラーへの入力が電子メールでも電話でも１回必要となる。図１６（Ａ）は、このオーナーの連絡回数の相違を招集ユーザーの人数とグラフとして表したものである。図１６（Ａ）に示すように、本実施例によるシステムでは、招集ユーザーの人数が増加しても、連絡回数は３回のみである。電話による場合、候補日の連絡及び予定確認に人数分、候補日の決定で人数分の電話連絡が必要となる。電子メールの場合には、返信の受信が個別となるため、また、返信の時期が一定でなく、オーナーには、電子メール及び内容整理の作業負荷がかかってしまう。このように、本実施例によるシステムでは、オーナーの作業負荷を電話や電子メールと比較して大幅に軽減することができる。
【０１０７】
次に、招集ユーザーの延べ連絡回数を検討する。アポイントメントの要請の受信では、電子メール、電話及び本実施例によるシステムでは共に招集ユーザー一人当たり１回である。返信の送信は、電子メールでは招集ユーザー一人当たり１回で、電話は０回、本実施例では１回である。電子メールでは、招集ユーザーが相互に返信の受信を行うと、（人数−１）回必要で、電話では他の招集ユーザーの返信状況を各招集ユーザーが把握することは難しい。本実施例では、招集ユーザーは自ら返信する際に他のユーザーの返信状況を把握するため、返信の受信に必要な回数は０回である。確定の通知受信は、それぞれ同じく１回である。本実施例では、メンバーについても、スケジューラーへの入力は不要である。
【０１０８】
図１６（Ｂ）に示すように、招集ユーザー全員で必要とする延べ連絡回数を集計すると、他の招集ユーザーの返信状況を招集ユーザー全員が把握するには、膨大な電子メールの送受信が必要となってしまう。一方、電話では他ユーザー出欠参照は難しい。この点、本実施例では、自ら返信する画面にて他のユーザーの返信状況を表示する仕組みを採用したことにより、連絡回数を少なくしつつ、各招集ユーザーの状況を鑑みた返信を促すことができる。また、アポイントメントの要請の通知を各ユーザーのカレンダー画面に対して行い、また、確定によりアポイントメント予定テーブルから通常予定テーブルへと管理を移し、さらに、カレンダーにて通常予定を表示する仕組みでは、日常的なスケジュールの確認作業中に要請の受信と確定の受信とを行うことができるため、招集ユーザーの実質的な作業は返信のみとすることができる。
【０１０９】
＜第２実施形態＞
第２実施形態では、同一出願人による特許文献４の開示を前提として、プロジェクト活動の支援を行うシステムでのアポイントメント調整支援機能を開示する。すなわち、第２実施形態では、上記第１実施形態及び実施例に開示した手法をプロジェクト活動支援システムにて有効に機能させ、プロジェクトの生産性を向上させるための仕組みを開示する。
【０１１０】
図１７は、第２実施形態の構成例を示すブロック図である。第２実施形態によるプロジェクト活動支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー（Ｗｅｂサーバー）１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。
【０１１１】
そして、データベース２が、図１又は図６等に示すテーブルの他、ユーザーの一部又は全部が参加するプロジェクトを識別するプロジェクトＩＤ毎に、当該プロジェクトのメンバーとなるユーザーのユーザーＩＤと、当該プロジェクトに属するコンテンツとを格納するプロジェクト関連テーブル３８を備えている。
【０１１２】
また、サーバー１０は、本実施形態では、プロジェクト関連テーブル３８を参照して、当該プロジェクトのメンバーによって使用される端末と通信して、当該プロジェクトのコンテンツの参照、編集及び登録を促すプロジェクト画面９０を管理するプロジェクト活動支援制御部７２を備えている。
【０１１３】
図１８はプロジェクト画面９０の一例を示す説明図である。図１８に示すように、プロジェクト画面９０は、そのコンテンツとして、プロジェクトの内容１００や、プロジェクトのメンバーリスト１０１や、電子会議室（掲示板，ＢＢＳ）や、文書管理にて管理される各種ファイルや、アポイントメント履歴１０４を含む。アポイントメント履歴１０４は、プロジェクトと関連して要請されたアポイントメントに関するデータのうち、確定した予定データをアポイントメントの履歴として管理するものである。アポイントメント履歴データは、予定内容データや、予定場所データや、オーナー、招集ユーザー、予定開始時刻、予定終了時刻を有すると良い。また、返信コメントや強制チェックボックスのチェックなどをアポイントメント履歴として管理するようにしてもよい。
【０１１４】
本実施形態では、アポイントメントの調整支援処理に関して、第１実施形態や実施例とほぼ同様に、要請制御部１４と、調整制御部１６とを備える。図８から図１２の画面例は、第２実施形態の画面例として援用する。同一の符号を付した同一の構成要件については、第２実施形態と第１実施形態及び実施例とで共通する。
【０１１５】
要請制御部１４は、データベース２へ接続し、前記オーナーによって使用される端末１と通信して、アポイントメントの要請に関する要請データの入力を促す要請作成画面４２（例えば、図９に示す画面）を送信すると共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する。
【０１１６】
調整制御部１６は、前記データベース２へ接続し、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促す調整画面４６（例えば、図１０に示す画面）を送信すると共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブル３２を用いて管理する。
【０１１７】
そして、要請作成画面４２は、図９に示すように、当該アポイントメントに招集する招集ユーザーの候補となる候補者リストを抽出すると共に、当該候補者リストからの招集ユーザーの選択を促す招集ユーザー特定用エリア７４を備えている。
また、本実施形態では特に、要請制御部１４が、前記オーナーが要請作成画面４２の表示を要求した際の表示画面のプロジェクトＩＤから前記プロジェクト関連テーブル３８を参照して、当該プロジェクトのメンバーであるユーザーＩＤの一覧から候補者リストを抽出する操作画面別候補者リスト生成機能７８を備えている。例えば、図１８に示すプロジェクト画面９０が「Ｐ社新築ビルプロジェクト」であって、そのメンバーが阿部氏、海老沢氏、山田氏、和田氏、鈴木氏であるとする。そして、図１８に示すプロジェクト画面９０から要請作成画面４２の表示を要求した場合には、操作画面別候補者リスト生成機能７８は、「Ｐ社新築ビルプロジェクト」のプロジェクトＩＤから、そのプロジェクトのメンバーをプロジェクト関連テーブル３８から読み出してそのメンバーを招集ユーザーの候補者とする。このため、オーナーは、自然な操作で、プロジェクト毎のメンバーを記憶しておくことなく、また、調べることなく、各プロジェクトのメンバーから招集ユーザーを特定することができる。
【０１１８】
再度図１７を参照すると、本実施形態では、好ましくは、サーバー１０は、前記各ユーザー個人の情報管理を促す個人画面８０を管理する個人情報管理支援制御部８２を備える。そして、データベースが、前記ユーザーの所属部門を識別する部門ＩＤ毎に当該部門に所属するユーザーＩＤを格納する部門テーブル３１を備える。この部門テーブル３１を有する例では、操作画面別候補者リスト生成機能７８は、前記オーナーによって要請作成画面４２の表示が要求された際の表示画面が個人画面８０である場合には、当該オーナーの所属する部門ＩＤから前記部門テーブル３１を参照して、当該部門に所属するユーザーのユーザーＩＤの一覧から候補者リストを抽出する機能を備える。このように、プロジェクトに関連する画面から要請作成画面が呼び出された場合には招集ユーザーの候補をプロジェクトメンバーとし、一方、個人画面８０から要請作成画面が呼び出された場合には、オーナーと同一の部門に所属するユーザーを候補者とする。
【０１１９】
図９に示すように、要求画面９は、招集ユーザー特定用エリア７４に、候補対象者一覧を表示する候補者リストボックス７５と、この候補者リストボックス７５から選択された要素であるユーザー名の一覧を表示する招集ユーザーリストボックス７６と、候補者リストのキーとなるプロジェクト名又は部門名の選択を促すポップアップリスト７７とを備えている。この例では、要請データの作成に際してユーザー名を直接入力せずに、プロジェクト名や部門名からユーザー名を表示させ、そのユーザー名データそのものをＧＵＩ部品として招集したいユーザーの特定操作を促す。従って、ユーザー名を完全にユーザーＩＤで管理することができる。また、オーナーは、プロジェクトや部門などの自然なグループ分けで招集ユーザーを特定することができる。
【０１２０】
本実施形態によるプロジェクト活動支援システムは、第１実施形態と同様に、調整制御部１６が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信する他ユーザー出欠参照制御機能１８を備える。そして、本実施形態では、要請制御部１４が、前記候補者リストボックスから選択されるユーザーの順位を前記アポイントメント予定テーブルにアポイントメントユーザー順位として格納し、他ユーザー出欠参照制御機能１８が、ユーザー順位に指定された順位で返信状態データを生成する機能を備える。
【０１２１】
次に、アポイントメント履歴の管理について説明する。本実施形態では、図１７に示すように、プロジェクト活動支援制御部７２が、プロジェクトＩＤで識別されるプロジェクトに関係するコンテンツ・データを単一のプロジェクト・デスクトップ画面に表示するプロジェクト・デスクトップ画面管理機能８４と、コンテンツ・データとして前記確定された予定データを前記プロジェクト・コンテンツとして登録する確定予定コンテンツ管理機能８６と、ユーザーによって使用される端末１に入力されるデータと一致するデータを含むコンテンツを検索すると共に、当該検索の検索結果として当該検索されたコンテンツを含むプロジェクトの一覧を前記端末に送信する検索制御機能８８とを備える。
【０１２２】
プロジェクト・デスクトップ画面管理機能８４は、図１８に示すように、複数種類のコンテンツを単一の画面に表示する。この単一の画面を、プロジェクト・デスクトップという。そして、確定予定コンテンツ管理機能８６は、確定された予定データをプロジェクト・デスクトップのコンテンツとして登録する。すなわち、プロジェクトに関する過去のアポイントメントについての情報が、プロジェクト・デスクトップのコンテンツとして登録される。アポイントメントについての情報は、予定の内容、場所、時間、参加者、オーナー等である。
【０１２３】
検索制御機能８８は、ユーザーによって使用される端末１に入力されるデータと一致するデータを含むコンテンツを検索すると共に、当該検索の検索結果として当該検索されたコンテンツを含むプロジェクトの一覧を前記端末１に送信する。検索画面９１の一例を図１９に示す。検索制御機能８８は、コンテンツの検索結果から、そのコンテンツの所属するプロジェクトＩＤを特定し、検索結果としてプロジェクト・デスクトップへのリンク９１ａを表示する。そして、そのコンテンツとしてアポイントメント履歴が含まれるため、多数のプロジェクトが並行している場合や、記憶の薄れた時期のプロジェクトについて、アポイントメントの参加者の氏名や、地名（アポイントメントの場所）などで検索することができる。
【０１２４】
再度図１７を参照すると、プロジェクト活動支援制御部７２が、前記プロジェクトの完了後に当該プロジェクトのプロジェクト・デスクトップ画面をＨＴＭＬ等のページ記述言語に変換するホームページ作成支援機能８９を備える。ホームページ作成支援機能８９は、図１８に示すプロジェクト・デスクトップの各コンテンツ等のデータを確定し、静止状態にして、ＨＴＭＬファイルと、このＨＴＭＬファイル中にてリンクされた画像や文書ファイル等に変換する。プロジェクト・デスクトップには、プロジェクトの初期から完了までの作業に応じた種々の重要なデータが集約されているため、プロジェクト活動に関する記録となる。また、本実施形態では、会議の履歴などをコンテンツとして管理できるため、一定の研究会などで社内、学内又は外部に情報公開する必要がある場合にも、ホームページ作成支援機能８９により簡単に閲覧しやすいデータに変換することができる。そして、アポイントメント履歴に、文書管理コーナー等を用いて会議等の議事録ファイルを関連させると、さらに情報公開や記録に有用である。
【０１２５】
【発明の効果】
本発明は、その構成によって、要請制御部が、オーナーによって入力されるアポイントメントの要請データを招集ユーザーに送信し、調整制御部が、招集ユーザーからの返信の有無及び内容を返信状態データとして管理する。そして、他ユーザー出欠参照制御機能が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する。従って、それぞれの招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知することができる。すなわち、すでに返信をしている第１の招集ユーザーがいる場合には、その第１の招集ユーザーの出欠を、返信データを作成中の第２の招集ユーザーが参照することができる。すると、当該アポイントメントについての招集ユーザー自身の必要性を自ら判断することができる。
すなわち、会議の目的が２つのグループ（技術と営業など）の意思疎通である場合には、第２の招集ユーザーと第１の招集ユーザーとが同一のグループであるとき、第２の招集ユーザーは、業務の生産性向上のために他のアポイントメントを優先すると判断することもできる。逆に、会議の目的が対立する２つの概念のうち、どちらを選択するかについての検討（製品の最終デザインの決定など）であれば、第１の招集ユーザーが第２の招集ユーザーとは反対意見の持ち主で、且つ、今まで議論してきた経過からカウンターパートは自分であるとの第２の招集ユーザーが判断するのであれば、オーナーの指示を要さず、第２の招集ユーザーは自ら参加すべきとの判断を行うことができる。
また、アポイントメントが懇親会などであって、あの人が参加するのなら、私も参加しよう、という考えの持ち主は、調整画面を何度も表示して、あの人の参加を確認してから、返信データを作成することができる。また、最初に返信する招集ユーザーも、他の招集ユーザー名を確認してから返信データを作成できるため、そのメンバーによっては自らがリーダーシップを発揮すべきと招集ユーザー自身が判断するのであれば、積極的な参加や、他の招集ユーザーへの参加の働きかけなどが期待される。
このように、ユーザー出欠参照制御機能が、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての返信状態データを送信することで、各招集ユーザーの自発的な活動を促し、また、招集ユーザー間の参加の調整などについて個々のオーナーの作業を必要とせず、また、各招集ユーザーがアポイントメントと自らの役割との関係を考慮した上でアポイントメントへの出欠を決定できるため、オーナーの招集に関する能力に過度に依存することなく、会議の生産性を向上させることができる。
上記のように、本発明によると、オーナーの手間を削減しつつ、アポイントメントの調整及び実際の会議等の開催に関して生産性を高めることができる。
【０１２６】
さらに、本発明が強制調整制御機能を備える構成では、当該機能が、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データと、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。すなわち、要請時に強制的に招集ユーザーの参加を命ずるのではなく、オーナーの判断によるオーナーの意思に基づいたアポイントメントの確定時に、招集ユーザーの出欠を強制的に調整することができる。これにより、第１に、アポイントメントの調整を早期に確定することができる。第２に、各招集ユーザーの重要性の判断を、オーナーによる確定時まで遅らせるこができる。これらにより、実際のニーズにあった柔軟なアポイントメント調整を実現することができる。そして、システムの機能としてオーナーに出欠の強制的な調整の権能を付加することで、オーナーがリーダーシップを発揮しやすい仕組みを導入することができる。
このように、強制調整制御機能を備えた構成では、各ユーザーの予定やアポイントメントの重要性が刻々と変化する状況にあっても、オーナーの手間を増加させずに柔軟にアポイントメントの調整を行うことができる。
【図面の簡単な説明】
【図１】図１は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図である。
【図２】図２は、本実施形態でのデータ構造の一例を示す説明図である。
【図３】図３は、本実施形態で取り扱うデータの一例を示す図で、図３（Ａ）は要請データの一例を示す図で、図３（Ｂ）は返信状態データの一例を示す図で、図３（Ｃ）はオーナー用の調整データの一例を示す図である。
【図４】図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。
【図５】図５は、本実施例の構成例を示すブロック図である。
【図６】図６は、本実施例でのデータ構造の一例を示す説明図である。
【図７】図７は、本実施例での各テーブルのフィールド名の一例を示す説明図である。
【図８】図８は、ユーザー予定データ表示画面の一例を示す説明図である。
【図９】図９は、要請作成画面の一例を示す説明図である。
【図１０】図１０は、要請通知エリアを有する個人カレンダー画面の一例を示す説明図である。
【図１１】図１１は、招集ユーザー用の調整画面の一例を示す説明図である。
【図１２】図１２は、オーナー用の調整画面（確定画面）の一例を示す説明図である。
【図１３】図１３は、要請データの格納処理の一例を示すフローチャートである。
【図１４】図１４は、確定処理の一例を示すフローチャートである。
【図１５】図１５は、予定表示処理の一例を示すフローチャートである。
【図１６】図１６は、本実施形態及び本実施例による生産性向上を招集ユーザーの数との関係で説明する説明図であり、図１６（Ａ）はオーナーに必要な連絡回数を示す図で、図１６（Ｂ）は招集ユーザーに必要な連絡回数を示す図である。
【図１７】図１７は、第２実施形態の構成例を示すブロック図である。
【図１８】図１８は、プロジェクト・デスクトップ画面の一例を示す説明図である。
【図１９】図１９は、本実施形態による検索結果の一例を示す説明図である。
【符号の説明】
１ 端末
１０ サーバー
１２ ユーザースケジュール送信部
１４ 要請制御部
１６ 調整制御部
１８ 他ユーザー出欠参照制御機能
２０ 返信コメント制御機能
２２ 強制調整制御機能
２４ 同時確定制御機能
２６ 確定予定データ制御部
【発明の属する技術分野】
本発明は、アポイントメント調整支援システムに関し、特に、サーバーと端末とを使用してユーザー間のアポイントメントの調整作業を支援するシステムに関する。
【０００２】
【従来の技術】
従来、企業や大学等では、会議や、研修会や、展示会への参加や、旅行などの予定の約束（アポイントメント）を、参加の候補者のスケジュールを調整しつつ、日時を確定する。参加を要請する主催者（オーナー）は、主催者から参加を要請される人（招集ユーザー）に参加を要請し、招集ユーザーからの出欠可否の返答などを参照して、最終的な日時を決定する。
【０００３】
特に、会議については、一定の事項の決定や、連絡や、業務の分配などの役割が与えられているため、参加すべき人が参加できないと、その後の活動の生産性が低下する恐れもあり、主催者（オーナー）は、活動に支障のないよう、アポイントメントの日時を慎重に提案し、また、各招集ユーザーへの個別連絡などを行う。
【０００４】
特許文献１には、会議を行うためのスケジュール調整を簡便なものとし、会議の主催者にかかる負荷を軽減することを目的として、会議開催期間と、会議参加者とを会議システムに登録すると、会議サーバーが、社員スケジュールＤＢと、会議室スケジュールＤＢとを検索して、候補日を自動的に特定し、さらに、参加者からの出欠の返答に基づいて自動的に開催の可否を特定する仕組みが開示されている。
【０００５】
この特許文献１の図２及び図３では、主催者は、参加者氏名に、必須、順必須、任意との出席者区分を定め、さらに、個々の参加者の代理参加者を特定する必要がある。そして、特許文献１の図５にある電子メールを自動的に送信し、参加の候補者からの電子メールの返信を自動的に解析して、図６に回答集計結果を生成する。この回答集計結果は、会議データを登録した際の会議開催の条件を満たした日時にＯＫと表示される。会議主催者は、この回答集計結果を参照して、最終的に会議開催の有無と、開催日とを確定する。
【０００６】
特許文献２では、グループ内の各端末ユーザーのスケジュールを定型の電子メールを用いて一括して管理することを目的として、会議通知の送信メールの送信者（会議開催者）として記述されている送信元のメールアドレスに対応付けて、個人別予定表メモリーに会議スケジュールを登録する。また、会議通知の電子メールへの返信があると、当該返信メールに参加の意味を示す項目が選択されている場合には、返信者のメールアドレスと対応付けて個人別予定表メモリーに会議スケジュールを登録する。この特許文献２では、会議開催者が、全員に強制参加を命ずる手法が開示されている。
【０００７】
特許文献３では、スケジュール情報の共有を目的として、他のユーザーのスケジュールを参照する仕組みと、会議等の共通するスケジュールの決定を容易とする仕組みとが開示されている。この特許文献３の図７では、太い実線の両矢印で示されたスケジュールは開始時間及び終了時間が確定している個人スケジュールで、太い点線の矢印は開始時間又は終了時間の一方が確定している個人スケジュールで、太い中抜きの矢印は、会議等で確定した共通スケジュールで、太い中抜きの矢印で、“？”マークが付されているものは、会議等の主催者から通知された共通スケジュールで、返信をしていないスケジュールである。“？”マークが付されている未確定状態は、参加又は不参加の返信を行うことで確定する。
【０００８】
【特許文献１】
特開２００２−１６９９３９号公報
【特許文献２】
特開２００１−１４７８７２号公報
【特許文献３】
特開平５−１６５８３６号公報
【特許文献４】
特開２００２−４９７２９号公報
【０００９】
【発明が解決しようとする課題】
上記各従来例では、第１に、会議の参加メンバーに依存する会議の成功の程度についての事務的及び心理的負担が、すべて会議主催者となるオーナーにもたらされてしまう、という不都合があった。すなわち、特許文献１では、会議参加の要請時に、招集ユーザー（参加者）について、会議との関係で、必須、準必須、任意等の参加者区分の指定を全て判断しなければならない。また、オーナーは、必須の招集ユーザーと判断した人の不参加をも見越して、代理参加者まで指定しなければならない。
【００１０】
第２に、特許文献２の全員強制参加の会議であれば、返信を待たずに予定を確定することができるが、その他の従来例では、オーナーは、出欠の有無の返信を待機し続けなければならず、スケジュールに不確定要素を含めたまま、他のスケジュールの調整などを行わなければならない。
【００１１】
第３に、特許文献２及び３の手法では、オーナーが複数の候補日を提案し、招集ユーザーの出欠の返答状況に応じて会議の趣旨に応じて、望ましい参加者が得られる候補日を開催日と決定することができない。特許文献１の手法では、複数の候補日を取り扱うことができるものの、参加者区分の指定を要請時に行うなど、オーナーの心理的・事務的な作業負荷が大きい。このように、従来例では、オーナーの心理的・事務的な作業負荷を小さくしつつ、複数の候補日の提案に応じたアポイントメントの調整を支援することができない。
【００１２】
第４に、上記各従来例及びその組み合わせでは、会議参加者の重要性判断の基準時を、オーナーの意思によって、スケジュールの確定時とすることは、できない。すなわち、アポイントメント自体の重要性と、各メンバー出欠の重要性とは、予定発生から、予定確定及び実施までの間で変化することがあり、このような場合には調整に関するオーナーの心理的・事務作業的負荷がより増大してしまう。予定の重要性の変化は、予定の発生時であるアポイントメントの要請時には十分に想定することができないため、簡単なアポイントメントと複雑なアポイントメントとの両方に自然に対応できるシステム開発が望ましい。
【００１３】
【発明の目的】
本発明は、アポイントメントの調整に関して、オーナーの手間を削減しつつ、アポイントメントの調整及び実際の会議等の開催に関して生産性を高めることのできるアポイントメント調整支援システムを提供することを、その目的とする。
【００１４】
本発明はまた、各ユーザーの予定やアポイントメントの重要性が刻々と変化する状況にあっても、オーナーの手間を増加させずに柔軟にアポイントメントの調整を行うことのできるアポイントメント調整支援システムを提供することを、その目的とする。
【００１５】
【課題を解決するための手段】
本発明の発明者は、アポイントメント調整は心理戦であり、人の取り合い、競争、予定の重複時の判断、変化への柔軟な対応などが必要となる点に着目した。すなわち、上記従来例は画一的で、定例的な会議等では役立つものの、残念ながら、柔軟性に欠け、定例から外れるような調整については、オーナー及びメンバーの作業負荷がかえって大きくなってしまう。
アポイントメント調整は、一般的に、要請、返答、確定の手順を取る。調整を何時行うかは、システムや組織によって異なる。
【００１６】
本発明の発明者は、第１に、電話や通常の電子メールの送受信によるアポイントメントの調整では、オーナーに心理戦のすべての負荷がかかってしまい、且つ、単純な手数を考察しても、オーナーの作業負荷が大きい点に着目した。
第２に、アポイントメント自体や、メンバー各自の出欠の重要性が、アポイントメント調整中に変化する点に着目し、心理戦をさらに複雑としている点を解決すべきであるとの着想に至った。
第３に、上記分析により、各ユーザーの出欠の重要性が、他のメンバーの出欠によっても変化することに着目した。
【００１７】
そこで、請求項１に係る本発明では、複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備えている。
そして、データベースが、ユーザーテーブルと、アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備えている。
本発明では特に、サーバーが、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、当該アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御部と、前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを前記返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御部とを備えている。
そして、この調整制御部が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する他ユーザー出欠参照制御機能を備えている。本発明は、これにより、前述した課題を解決する。
【００１８】
請求項１等に係る本発明では、要請制御部が、オーナーによって入力されるアポイントメントの要請データを招集ユーザーに送信し、調整制御部が、招集ユーザーからの返信の有無及び内容を返信状態データとして管理する。そして、他ユーザー出欠参照制御機能が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する。従って、それぞれの招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知する。すると、それぞれの招集ユーザーは、自らが返信する際に、他の招集ユーザーの出欠を参照することができ、すると、当該アポイントメントについての招集ユーザー自身の必要性を自ら判断することができる。招集ユーザー自らが自分の出欠の重要性を判断し、その上で出欠の返答を行うため、招集（人繰り）に関するオーナーの心理的な負担や判断作業の負荷を軽減することができる。
【００１９】
請求項３等に係る本発明では、さらに、前記調整制御部が、前記オーナーによって使用される端末に前記返信状態データを送信すると共に、当該返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する強制調整制御機能を備えている。本発明は、これにより、前述した課題を解決する。
請求項３等に係る本発明では、強制調整制御機能が、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データ（請求項２の引用では返信コメントを含む）と、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。すなわち、要請時に強制的に招集ユーザーの参加を命ずるのではなく、オーナーが判断の判断によるオーナーの意思に基づいたアポイントメントの確定時に、招集ユーザーの出欠を強制的に調整することができる。
【００２０】
【発明の実施の形態】
次に、本発明の実施の形態を説明する。
＜第１実施形態＞
第１実施形態では、アポイントメントの調整に関して、オーナーの手間を削減するという課題に対して、他ユーザーの出欠を参照する機能や、オーナーによる強制調整制御機能の構成と有用性とを開示する。
【００２１】
図１は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図であり、図２は本実施形態で使用するデータ構造の一例を示す説明図である。
図１を参照すると、本実施形態によるアポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。
【００２２】
そして、データベース２は、図２に示すように、ユーザーテーブル３０と、アポイントメント予定テーブル３２とを備えている。アポイントメント予定テーブル３２は、アポイントメントのオーナーとなるユーザーから、当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントに関して、そのアポイントメントの内容、場所及び日時などを含む要請データを格納する。アポイントメント予定テーブル３２は、この要請に対する招集ユーザーからの返信データの有無と、返信の内容（出欠等）とを返信状態データとして格納する。
【００２３】
再度図１を参照すると、サーバー１０は、要請制御部１４と、調整制御部１６とを備えている。要請制御部１４は、まず、前記データベース２と接続し、前記オーナーによって使用される端末１と通信して、当該アポイントメントの要請に関する要請データの入力を促す。要請制御部１４は、続いて、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する。
【００２４】
調整制御部１６は、前記データベース２と接続し、まず、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促す。調整制御部１６は、続いて、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを前記返信状態データとして前記アポイントメント予定テーブル３２を用いて管理する。
【００２５】
そして、本実施形態では特に、この調整制御部１６が、他ユーザー出欠参照制御機能１８を備えている。他ユーザー出欠参照制御機能１８は、前記アポイントメント予定テーブル３２を参照して、全ての招集ユーザー及びオーナーによって使用される各端末１に全ての招集ユーザーについての前記返信状態データを送信する。
【００２６】
他ユーザー出欠参照制御機能１８は、アポイントメント予定テーブルを参照して、招集ユーザーによって使用される端末や、オーナーによって使用される端末に、招集ユーザー全員の返信状態データを送信する。従って、各招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知することができ、それぞれの招集ユーザーは、他の招集ユーザーの出欠を参照することで、当該アポイントメントについての招集ユーザー自身の必要性を判断することができる。すると、招集に関するオーナーの心理的な負担や判断に必要な時間を軽減することができる。
【００２７】
本実施形態では、好ましくは、調整制御部１６が、返信コメント制御機能２０を備える。返信コメント制御機能２０は、招集ユーザーに当該要請についての返信コメントの入力を促し、続いて、当該招集ユーザーによって入力される返信コメントを前記返信データに合成する。返信コメント制御機能２０が、招集ユーザーの返信コメントを返信データに合成すると、返信データに返信コメントが含まれるため、他ユーザー出欠参照制御機能１８は、この返信コメントを含む返信データを他の招集ユーザーに通知する。すると、招集ユーザーは、アポイントメントの要請への返信である返信データの作成時に、他の招集ユーザーの返信コメントを参照することができる。従って、招集された招集ユーザーは、他の招集ユーザーの返信コメントによる各自の状況等を鑑みて、自らの出欠を判断することができる。これは、アポイントメントに関して、各招集ユーザーの積極的な判断を促し、これにより、参加者の調整のためのオーナーの連絡や判断等の負荷を減少させることができる。
【００２８】
図３を参照すると、図３（Ａ）に示す要請データ１４ａでは、オーナーによって候補日が２つ提案されている。アポイントメントの内容は販売店支援であり、場所は販売店のある○○○地区である。招集ユーザーは、ユーザーＢからユーザーＥまでの４人である。図３では、要請データ及び調整データは、電子メールとしても良いし、Ｗｅｂページ（画面）としてもよい。
【００２９】
図３（Ｂ）に示す調整データ１６ａは、招集ユーザーＢ用である。招集ユーザーＢが返信を試みた時点で、招集ユーザーＤ及びＥが返信を完了しており、招集ユーザーＣは返信待ちとなっている。他ユーザー出欠参照制御機能１６は、図３（Ｂ）に示すように、招集ユーザーＢ向けの調整データに、他の招集ユーザーである招集ユーザーＤ及びＥの返信データの内容（出欠）と、招集ユーザーＢが未返信であることが含まれる。
【００３０】
招集ユーザーＢは、図３（Ｂ）の返信状態データ１６ａ（調整データ）を参照する。ユーザーＢは、第１候補日には所要が入っていたため、第１候補日となった場合には、ユーザーＡに任せることとして、欠席を表明することとした。また、招集ユーザーＢは、新人教育に関して招集ユーザーＣが積極的に盛り上げ役を引き受けてくれることを知っており、この点、オーナーはまだ知らないかもしれない、と考え、次の返信コメントを記載する。「新人参加の販売店支援ですね。またＣさんの盛り上げを期待しています。第１候補日は、所用ありです」。
【００３１】
本実施形態では、オーナーによる招集ユーザーの出欠の強制調整制御機能をシステム的に実現する。この例では、調整制御部１６が、強制調整制御機能２２を備える。強制調整制御機能２２は、まず、オーナーによって使用される端末１に返信状態データを送信する。この機能２２は、続いて、この返信状態データを参照するオーナーに、前記招集ユーザーの出欠の強制調整操作を促す。そして、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。
【００３２】
強制調整操作は、返信データの有無や内容にかかわらず、オーナーの判断で、各招集ユーザーの参加を強制するための操作である。例えば、図３（Ｃ）に示す例では、招集ユーザーＣは未返信であるが、オーナーの判断として招集ユーザーＣに参加を命ずることとし、調整データ中の招集ユーザーＣについて強制参加を選択した。すなわち、強制調整操作として符号２２ａのチェックボックスをチェックした。オーナーによる強制調整は、招集ユーザーの返信データの強制的な上書きである。オーナーによって強制調整され、確定された場合には、強制調整された返信状態データは確定予定データとなる。例えば、符号２２ｂの確定ボタンをクリックし、第２候補日で確定すると、第１候補日のアポイントメントは取り消しとなり、また、第２候補日に参加と返信した招集ユーザーと、強制調整によって参加とされた招集ユーザーについては、第２候補日での予定が確定する。
【００３３】
このように、強制調整制御機能２２は、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合に、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データ（返信コメント制御機能２０を有する場合には、返信コメントを含む）と、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。これにより、アポイントメントを早期に確定することができる。さらに、各招集ユーザーの重要性の判断を、オーナーによる確定時まで遅らせるこができる。これにより、実際のニーズにあった柔軟なアポイントメント調整を実現することができる。そして、システムの機能としてオーナーに出欠の強制的な調整の権能を付加することで、オーナーがリーダーシップを発揮しやすい仕組みを導入することができる。
【００３４】
強制調整制御機能２２と関連して、調整制御部１６が、同時確定制御機能２４を備えると良い。この例では、同時確定制御機能２４は、オーナーによって前記各招集ユーザーの出欠について強制調整操作なされた後、一回の確定操作で、当該強制調整操作された返信状態データを前記確定予定データとして、全招集ユーザーについて当該アポイントメントを同時に確定させる。図３（Ｃ）に示す例では、強制調整操作と、候補日の確定とにより、全招集ユーザーの予定が確定する。
【００３５】
この同時確定制御機能２４により、オーナーは、招集ユーザーに対する相談の順序などを考慮せずに、オーナーの全員への一体的な命令としてアポイントメント調整を完了させることができる。また、同時確定制御を標準的な仕組みとすることで、招集ユーザーの自発的で積極的な判断を促すことができ、さらに、招集ユーザーの人間関係に沿った順序で個別に相談するという心理的、事務的な負荷からオーナーを解放することができる。
【００３６】
本実施形態による強制調整は、代行的使い方と、強制参加的使い方とがある。代行的使い方では、強制調整制御機能２２は、前記強制調整操作があった返信データを、前記返信状態データによって返信待ちである招集ユーザーの返信データの作成を当該オーナーが代行した代行返信データとして管理する機能を備える。たとえば、オーナーが、端末１を使用した連絡が困難な招集ユーザーについて、アポイントメントの確定時に、電話などの他のコミュニケーション手段によって出欠等の確認をとれた場合に、オーナーは、当該招集ユーザーの代わりに端末を操作して、当該招集ユーザーの返信データを生成することができる。これにより、出欠等を確認しているのに、それを連絡するための端末の操作が遅れることで、全員へのアポイントメントの確定が遅れてしまうような事態の発生を防止することができる。このように、オーナーが強制的に返信データを作成することができると、オーナーの意思と作業とによって、実際の電話等を含めたアポイントメントの調整の状態と、システム的な状態とを一致させ、オーナーの意思のみで確定することができる。このため、オーナーは、一定の時期に集中的にアポイントメントに関するすべての問題の解決に取り組むことができる。例えば、図３（Ｃ）に示す場合で、オーナーは、招集ユーザーＣが第２候補日で参加できるのであれば第２候補日とし、参加できなければ、第１候補日と考えていたとする。オーナーは、招集ユーザーＣの携帯電話や個人メールアドレスなどに連絡し、第２候補日での参加の了解を得られたとする。この場合に、オーナーは、招集ユーザーＣの代わりに返信データを作成するように、チェックボックス２２ａをチェックすることで、強制調整操作を行う。
【００３７】
また、強制調整操作を、強制参加命令とすることもできる。この場合、強制調整制御機能２２は、前記返信状態データによって返信待ち又は不参加である招集ユーザーに当該オーナーの判断で強制的に参加が命じられた場合に、当該強制参加対象の招集ユーザーの返信データを強制的に参加に設定した強制参加返信データとして管理する機能を備えると良い。この例では、招集ユーザーに対して強制参加を命じる機能をオーナーに与えることで、オーナーは、招集ユーザーからの返信状況にかかわらずアポイントメント調整を完了させることができる。また、アポイントメントの要請後に事情が変化したときには、オーナーがアポイントメントを確定させようとした時点の事情に基づいて、招集ユーザーやその人数を一時期に集中して判断することができる。逆に、招集ユーザーは、参加してもしなくてもよいアポイントメントに対しては、返信を行わなくとも、事後的にオーナーの判断で出欠が確定されるため、判断の難しいアポイントメントへの参加の有無について判断する作業から解放される。
【００３８】
そして、他ユーザー出欠参照制御機能によって招集ユーザー間の自主的で自発的なアポイントメントの調整がなされ、そして、招集ユーザーの自発的な調整が不首尾であった点については、オーナーの権限による強制的な調整がなされる。このように、アポイントメントの調整について、招集ユーザー間の自発的な調整と、オーナーの強制的な調整との組み合わせをシステム的に実現することで、招集ユーザー自身の積極性を向上させ、オーナーの心理的負担を軽減し、招集ユーザー及びオーナーの事務的な連絡回数等を減少させることができ、これにより、アポイントメントの調整が必要な作業について生産性を向上させることができる。
【００３９】
強制調整制御機能２２による強制参加命令の仕組みを前提とすると、返信データは、出欠に関しては、返信を保留することを示す保留コードを有さずに参加コード（○）及び不参加コード（×）のみを有すると良い。すなわち、返信データが、出欠に関して、参加（○）または不参加（×）のみであり、返信保留（△）を有さない仕組みでは、返信保留を伝えるための返信データの作成及び送受信等の操作を行う必要性が無く、返信を保留する招集ユーザーは、単に返信データの作成を行わない、とする仕組みを実現できる。そして、オーナーによる強制調整の機能を前提とすると、返信保留を伝えるために返信データを作成し送信する必要性はほとんどなく、従って、返信保留の返信という不要なデータの送受信を無くすことができる。
【００４０】
また、返信保留という返信を無くすことで、オーナーは、返信待機の状態を返信保留の一種であると判断することができる。特に、日程等が合わない招集ユーザーは、返信コメントなどで早期にその旨を主張することで、代わりの招集ユーザーの参加を促すことができるため、返信待機は、オーナーによる強制参加命令を受けることができる状態の消極的意思表示ともなる。従って、返信保留を無くし、参加又は不参加のみの返信とすると、要請があった場合に、早期に返信データを入力し送信しないと、強制参加命令を受ける消極的意思表示であるとオーナーによって判断される可能性が高まり、逆に、各招集ユーザーに早めの返信を促すこととなる。すなわち、返信保留の返信を無くすことで、早期の判断が促され、アポイントメント調整時間を短くし、これにより、オーナーの負荷を軽減することができる。
【００４１】
好まし実施形態では、アポイントメントの調整のみならず、各ユーザーの予定の管理を行う。この場合、図２に示すように、データベース２は、各ユーザーの予定データを格納する通常予定テーブル３４を備える。
【００４２】
再度図１を参照すると、この例では、サーバー１０が、データベース２に接続し、ユーザーによって使用される端末１と通信し、前記通常予定テーブル３４に格納された各ユーザーの予定データを当該端末１へ送信するユーザースケジュール送信部１２を備えている。各ユーザーの予定データは、例えば個人のスケジュール管理に用いる予定データであり、内容や開始時刻などのフィールドを有する。ユーザースケジュール送信部１２は、アポイントメントの要請を行うオーナーに招集候補者となるユーザーの予定データを送信する。また、返信データを作成する招集ユーザーに、他の招集ユーザーの確定している予定データを送信するようにしても良い。
【００４３】
ユーザースケジュール送信部１２が、各ユーザーの予定データを端末１に送信するため、ユーザーであるオーナーは、アポイントメントの日程の提案に際して事前に各招集ユーザーの予定を参照することができる。要請データを受信した招集ユーザーも、ユーザースケジュール送信部１２によって送信される他の招集ユーザーの予定データを参照することができる。そして、他ユーザー出欠参照制御機能１８による制御によって、招集ユーザーは、他のユーザーの出欠状況及び当該要請以外の予定とを参照して、自らの出欠を判断することができる。さらに、各招集ユーザーが、他のユーザーの出欠と、要請以外の予定とを参照しつつ、出欠を決定した前提で、なお残存している調整については、強制調整制御機能２２によってオーナーの権限と作業とで調整がなされる。
【００４４】
サーバー１０は、さらに、オーナーによって確定された返信状態データである確定予定データを通常予定テーブル３４での各ユーザーの予定データとして格納する確定予定データ制御部２６を備えるとよい。確定予定データ制御部２６は、オーナーによって確定された確定予定データをオーナー及び参加する招集ユーザーの予定データとして、通常予定テーブル３４に格納する。すなわち、例えば、第１のオーナーによって第１のアポイントメントが確定されると、この第１の確定した予定データを各招集ユーザーの予定データとして格納する。従って、第２のアポイントメントを調整する第２のオーナーは、この確定した第１の予定データを参照しつつ、第２のアポイントメントの要請を作成することができる。これにより、複数のアポイントメントの調整で日程が重なり合う状況にあっても、確定した予定についてはすべての招集ユーザーについて確定とほぼ同時に予定データとすることができ、アポイントメントの調整における人の取り合いという面からは、早期にアポイントメントを確定することで、早期に人材の確保を行うことができる。
【００４５】
図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。本実施形態によるアポイントメント調整支援処理は、参加の要請の作成及び通知をする要請制御工程（Ａ１，Ｂ１等）と、アポイントメントの出欠や候補日選定を調整する調整制御工程（Ｂ３，Ｂ４等）と、アポイントメントを確定する確定工程（Ａ５，Ｂ５等）とを備える。
【００４６】
要請制御工程では、まず、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促す（ステップＡ１）。そして、要請制御工程では、オーナーによって要請データが入力されると、この入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する（ステップＢ１，Ｂ２）。この要請データの送信は、電子メールによる通知でもよいし、個人カレンダーを使用する例では、個人カレンダーのカレンダー内又は個人カレンダー画面のエリアへの表示処理としてもよい。個人カレンダーを使用する例では、オーナーの個人カレンダーにも当該要請データを表示する。
【００４７】
調整制御工程では、まず、データベース２と接続し、そして、要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによるアポイントメントの要請への出欠等の返信データの入力を促す（ステップＢ３）。このとき、ステップＢ３は、アポイントメント予定テーブル３２を参照して、全ての招集ユーザーによって使用される端末に、他の全招集ユーザーの返信状態データを送信する（ステップＢ４，他ユーザー出欠参照制御工程）。招集ユーザーの返信状態は、オーナーによって使用される端末でも逐次参照できる（ステップＡ３）。
【００４８】
調整制御工程では、続いて、オーナーによって使用される端末１と通信して、前記アポイントメント予定テーブル３２に格納された返信状態データを当該端末１に表示する（ステップＡ３）。続いて、当該オーナーにアポイントメントの強制調整操作を促し、そして、未返信の招集ユーザーや、不参加と返信した招集ユーザーの出欠について、オーナーが強制的に参加へと強制調整した場合には、当該強制調整操作のなされた返信状態データを最新の返信状態データとして管理する（ステップＡ４）。
【００４９】
確定制御工程では、オーナーによって使用される端末と通信して、前記返信状態データに対して、当該オーナーによってアポイントメントの確定操作がなされた場合には、当該確定された返信状態データを確定予定データとして管理する（ステップＡ５）。確定制御工程は、さらに、確定予定データを、全ての招集ユーザーに通知する（ステップＢ５）。そして、参加が確定した招集ユーザーの個人カレンダーに確定した予定を通常予定として表示する（ステップＢ６）。また、オーナーの個人カレンダーにも通常予定として表示する（ステップＡ６）。
【００５０】
図１に示す構成や、図４に示す処理工程は、サーバーのＣＰＵが所定のプログラムを実行することで実現することができる。本実施形態によるシステム（アポイントメント調整支援システム）のＣＰＵ（図示せず）は、所定のプログラム（指令）に従って各種の演算を行う。ＣＰＵは、各種の処理要求に従って、データベース２を駆動して、各種のページ（画面）の生成や、電子メールの送信・解析などを実行し、その実行結果を端末１に送信する。ＣＰＵがアポイントメント調整支援用のプログラムを実行することで、システムは、調整データの生成や、入力される返信データの管理等を処理する。
【００５１】
本実施形態では特に、アポイントメント調整支援処理用プログラムは、各ユーザー間のアポイントメントの調整作業を支援するための各種の指令を備える。このプログラムは、サーバーを動作させる指令として、例えば、他ユーザー出欠参照制御指令を備える。本実施形態によるシステムのＣＰＵは、この他ユーザー出欠参照制御指令を実行することで、図４に示すステップＢ４の処理を実行し、また、図１に示す他ユーザー出欠参照制御機能１８として動作する。その他、このプログラムが、本実施形態によるシステムにて実現すべき各部，各機能や、フローチャートの各工程に応じた指令を備えることで、ＣＰＵは対応する処理を行う。
【００５２】
本実施形態では、アポイントメント調整支援処理用プログラムが、サーバーのＣＰＵを動作させる指令として、下記の指令を備える。
前記データベース２へ接続し、前記オーナーによって使用される端末１と通信して、アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信するための要請制御指令（ステップＡ１及びＢ１，要請制御部１４に対応）。
前記データベース２へ接続し、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブル３２を用いて管理するための調整制御指令（ステップＢ３，調整制御部１６に対応）。
前記データベース２へ接続し、前記オーナーによって使用される端末１と通信して、前記アポイントメント予定テーブル３２に格納された返信状態データを当該端末１に表示して、当該オーナーによってアポイントメントの確定操作がなされた場合には当該確定された返信状態データを確定予定データとして管理するための確定制御指令（ステップＡ５及びＢ５，確定予定データ制御部２６）。
調整制御指令の一部として、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信するための他ユーザー出欠参照制御指令（ステップＢ４，機能１８に対応）。
調整制御指令の一部として、返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによって各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを最新の返信状態データとして管理する強制調整制御指令（ステップＡ４，機能２２に対応）。
【００５３】
さらに、このプログラムが、同時確定制御指令を備えることで、ＣＰＵは、同時確定制御機能２４として動作することができる。同時確定制御指令は、オーナーによって前記各招集ユーザーの出欠について強制調整操作なされた後の処理について、ボタンへのクリックなどの一回の確定操作があったときに、当該強制調整操作された返信状態データを前記確定予定データとして、全招集ユーザーについて当該アポイントメントを同時に確定させる。同時に確定というのは、例えば、調整中として扱っていた要請データや返信状態データを、通常の確定した予定データに変換する処理である。
【００５４】
このプログラムは、ディスクや磁気テープ（ＭＴ）等の記録媒体１１Ａに格納されて搬送され、ディスクドライブ１１によって読み取られる。記録媒体１１Ａに格納されていたプログラムは、ディスクドライブ１１にて読み取られた後、プログラム記憶部１１Ｂに格納される。また、他のホスト装置から通信回線を経由してプログラム記憶部１１Ｂに当該プログラムを提供することもできる。
【００５５】
プログラムについて、ＣＰＵを「動作させる指令」というときには、各指令のみでＣＰＵを動作させる指令と、プログラム記憶部１１Ｂに予め格納されているオペレーティングシステム等の他のプログラムに依存して当該ＣＰＵを動作させる指令とのいずれかまたは双方を含む。ここでは、「オペレーティングシステム」は広義に解釈している。データベースマネージャーや、トランザクションマネージャー等を含む。
【００５６】
上記他ユーザー出欠参照制御指令は、実際には、データベースマネージャーに予定ＩＤをキーとするＳＱＬ文を発行し、検索結果をＨＴＭＬのページゼネレーターに引き渡す指令のみのみとして、テーブルからの検索処理や抽出処理は実際に指は指令そのものの実行ではなく、データベースマネージャーが行うようにしても良い。このように、プログラムを記憶する記録媒体１１Ａであって、当該プログラムをユーザーへ搬送する用途の記録媒体１１Ａには、例えば「所定のデータベースマネージャーにＳＱＬ文を引き渡す指令」のみが格納され、実際のデータの検索はオペレーティングシステム等の実行環境によって行われる場合がある。これは、動作させようとするコンピュータのオペレーティングシステムやデータベースマネージャー等との関係で定まる。この点、通信回線を介してプログラム（指令）を提供する場合も同様である。
【００５７】
このプログラムとシステムの部，機能又は方法の工程との関係や、媒体等に関する説明は後述する実施形態、実施例においても同様である。特に、同一の名前が付されている機能、工程、指令のそれぞれが対応する点は、各実施形態においても同様である。例えば、アポイントメント調整支援処理用プログラムは、実施例の確定処理制御部６０の機能実現するには、その機能を実現するための確定処理制御指令を備える。確定処理制御指令は、図１４に示す各工程に対応する指令を備える。
【００５８】
＜実施例＞
図５は、本実施例の構成例を示すブロック図であり、図６は、本実施例でのデータ構造の一例を示す説明図である。図６に示す各テーブルのフィールド名の一例を図７に示す。本実施例では、実施例では、Ｗｅｂサーバーと、ＨＴＭＬ等のマークアップランゲージで記述された画面（ページ）を表示するブラウザを備えた端末とを使用する例を開示する。
【００５９】
本実施例では、アポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー（Ｗｅｂサーバー）１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。そして、データベース２は、図６及び図７に示すように、ユーザーテーブル３０と、アポイントメント予定テーブル３２と、通常予定テーブル３４と、予定メインテーブル３６とを備える。本実施例では、図６に示すように、通常予定テーブル３４と、アポイントメント予定テーブル３２とを、予定メインテーブル３６の予定種類コードによって使い分けている。
【００６０】
ユーザーテーブル３０は、前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納する。
予定メインテーブル３６は、予定を識別する予定ＩＤ毎に、前記ユーザーＩＤと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データと、アポイントメント等で予定する場所である予定場所データとを格納する。
通常予定テーブル３４は、前記予定ＩＤ毎に、予定開始日時データと、予定終了日時データとを格納する。
アポイントメント予定テーブル３２は、候補日順位毎の前記予定ＩＤ毎に、当該予定ＩＤのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーＩＤと、当該オーナーと招集ユーザーとを識別すると共に当該招集ユーザーの順序を指定するアポイントメントユーザー順位と、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納する。
予定ＩＤは、オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合には、候補日順位毎に個別のＩＤとすると良い。また、アポイントメントの調整によって確定した予定については、単一の予定ＩＤとし、予定内容データや、予定場所データや、予定開始日時や、予定終了日時については、各ユーザーで共通のデータを使用すると良い。この場合、確定したアポイントメントの予定については、各ユーザーは個別の編集を行うことはできない。また、予定ＩＤをユーザー毎として、確定したアポイントメントの予定を各ユーザーが編集できるようにしても良い。
【００６１】
図７に各テーブル３０，３２，３４，３６の各フィールドの内容を例示する。図７に示すように、予定の種類を示す予定種類コードは、確定している通常予定を“０”、アポイントメントの調整中であるアポイントメント予定を“１”、通常予定のうち毎週同時刻等の繰り返し予定を“２”としている。アポイントメントユーザー順位は、オーナーを“０”とし、招集ユーザーは“１”から順に付番する。アポイントメント候補日順位は、アポイントメントの候補日が複数ある場合に、これを識別する番号となる。本実施例では、出欠フラグは二種類のみとし、参加を“１”、不参加を“０”とし、返信保留を示すデータ構造はない。従って、出欠についてはフラグとしている。
【００６２】
再度図５を参照すると、サーバーは、要請作成画面生成部５０と、要請データ格納制御部５２と、要請データ通知制御部５４と、調整画面生成部５６と、返信データ格納制御部５８と、確定処理制御部６０とを備える。また、図８に示す招集候補となるユーザーの予定を表示するカレンダー画面制御部５１を備えるようにしても良い。本実施例による処理は、Ｗｅｂサーバーを用いて、特徴的な画面を使用して、図４に示すアポイントメント調整支援処理をより詳細に開示するものである。本実施例では、「画面」は、端末１のブラウザ等で表示されるＨＴＭＬ等のマークアップ言語によって記載され、端末１のユーザーによって入力される入力フィールドやチェックボックスやポップアップメニューなどの選択肢の定義を含むファイルである。
【００６３】
要請作成画面生成部５０は、オーナーによって使用される端末１からアポイントメントの要請を作成するための要請作成画面４２の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促すための要請作成画面４２（例えば、図９に示す画面）を生成する。図４に示す例では、要請作成画面生成部５０は、ステップＡ１の処理を行う。
【００６４】
要請データ格納制御部５２は、まず、要請作成画面が生成されたときに、前記オーナーによって使用される端末へ当該要請作成画面４２を送信する。そして、当要請データ格納制御部５２は、オーナーによって当該要請作成画面に入力される要請データを受信する。この制御部５２は、さらに、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納し、一方、要請作成画面４２のその他の各フィールドの内容を前記アポイントメント予定テーブルに格納する。要請データ格納制御部５２は、例えば、図１３に示すフローチャートを実行する。図４に示す例では、要請データ格納制御部は、ステップＡ１の処理を行う。すなわち、本実施例では、図１３に示すフローチャートはステップＡ１の詳細処理である。
【００６５】
要請データ通知制御部５４は、前記招集ユーザーによって使用される端末に、前記各テーブルに格納された当該要請データを通知する。この通知には、電子メールを使用しても良いし、各招集ユーザーが日常的に使用する画面（例えば、図１０のカレンダー画面４４）に新しい未返信の要請データを表示することで通知しても良い。図４に示す例では、要請データ通知制御部５４は、ステップＢ１及び／又はＢ２の処理を行う。
【００６６】
調整画面生成部５６は、招集ユーザーによって使用される端末から、アポイントメントの要請に対する返信を作成するための調整画面４６の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面４６（例えば、図１１に示す画面）を生成する。図４に示す例では、調整画面生成部５６は、ステップＢ３の処理を行う。
【００６７】
本実施例では、調整画面生成部５６が、他ユーザー出欠参照制御機能６２を備えている。この機能６２は、第１実施形態等の機能１８と同様の作用効果を有する。すなわち、本実施例では、他ユーザー出欠参照制御機能６２は、招集ユーザーによって使用される端末１から調整画面４６の表示指令を受信したときに、予定ＩＤをキーとしてアポイントメント予定テーブル３２を参照する。そして、アポイントメント予定テーブル３２から、他の招集ユーザーのユーザー名、出欠フラグ及び返信コメント読み出して、前記調整画面４６にて合成する。図４に示す例では、他ユーザー出欠参照制御機能６２は、ステップＢ４の処理を行う。
【００６８】
返信データ格納制御部５８は、まず、前記調整画面４６が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面４６を送信する。制御部５８は、続いて、当該招集ユーザーによって当該調整画面に入力される返信データを受信する。さらに、制御部５８は、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する。図４に示す例では、返信データ格納制御部５８は、ステップＢ３の処理を行う。
【００６９】
本実施例では、調整画面生成部５６が、確定用調整画面生成機能６４を備える。確定用調整画面生成機能６４は、オーナーによって使用される端末１から、確定用調整画面４８の表示指令を受信した場合には、前記予定ＩＤをキーとしてアポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出する。確定用調整画面生成機能６４は、続いて、各招集ユーザーの出欠に関して強制参加チェックボックスを付加した確定用調整画面４８（例えば、図１２に示す画面）を生成する。図４に示す例では、確定用調整画面生成機能６４は、ステップＡ３の処理を行う。
【００７０】
調整画面生成部５６は、さらに、強制調整制御機能６６を備える。強制調整制御機能６６は、第１実施形態等の強制調整制御機能２２と同様の作用効果を奏する。すなわち、強制調整制御機能６６は、前記オーナーによって、前記確定用調整画面４８の前記強制参加チェックボックス４９がチェックされた招集ユーザーの出欠について、これを強制的に参加として確定する。強制調整制御機能６６は、当該招集ユーザーの通常予定テーブル３４に当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する。図４に示す例では、強制調整制御機能６６は、ステップＡ４の処理を行う。
【００７１】
確定処理制御部６０は、オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブル３２を参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する。確定処理制御部６０は、例えば、図１４に示すフローチャートを実行する。図４に示す例では、確定処理制御部６０は、ステップＡ５の処理を行う。すなわち、図１４に示すフローチャートは、本実施例でのステップＡ５の詳細処理である。
【００７２】
カレンダー画面制御部５１は、図８及び図１０に示すカレンダー画面の生成を制御する。このとき、カレンダーフィールドへの予定の表示については、図１５に示すフローチャートを実行し、予定メインテーブルの予定種類コードに応じた色分け等の処理をしてもよい。
【００７３】
＜事例１＞
次に、画面を参照して具体的な使い方を説明する。ここでは、次の状況設定と、登場人物とを設定する。
【００７４】
状況設定： オフィス家具大手Ｋ社の販売課長、阿部氏は、顧客であるＰ社の自社ビル新築に伴うオフィス家具購入の案件で家具配置プランの提案を行っていた。コンセプトを提案するプレゼンテーションを数回行い、Ｐ社の要望をインタヴューし、次回はこのＰ社の要望を反映した実施プランの提案を持ち込むことになっていた。ビルの着工は来期ということもあり、当面Ｐ社の意思決定はないものと思われた。次回プレゼンテーションの候補日として、Ｐ社からは翌週の木曜日と金曜日がＯＫとの回答を得ていた。早急に社内のメンバーのアポイントメントを取り、調整をすることとなった。
【００７５】
登場人物： プロジェクトのリーダー阿部は、メンバーのプレゼンテーションの日程を調整する立場にある。営業マン海老沢、設計担当者山田、和田、鈴木。
アポイントメントの内容は、Ｐ社実施プラン提案、オーナーは阿部、招集ユーザーは海老沢、山田、和田、鈴木である。
【００７６】
図８は、ユーザー予定データ表示画面の一例を示す説明図である。図８から図１２に示す画面の例は、パーソナルコンピュータ等でブラウザー・アプリケーションを使用してサーバー１０から送信されるデータを画面として表示している状態を示す。図中の下線はリンクであり、他の画面への表示指令となる。
【００７７】
カレンダー画面制御部５１は、アポイントメントのオーナー向けにプロジェクトや部署に属するユーザーの登録されている予定を表示するユーザー予定画面４０（実際には、カレンダー画面４４）を生成する。阿部氏は、図８に示すユーザー予定画面を表示し、メンバーの空きスケジュールを確認する。すると、木曜日は海老沢氏、山田氏及び和田氏に先約があり、金曜日には全てのメンバーに予定がない。オーナーは、一応両日を候補日として提案することとする。オーナーである阿部氏は、図８のアポイントメントと表記されたアポイントメント・リンク４０ａに対してクリック等の操作をする。アポイントメント・リンク４０ａへの操作は、要請作成画面の表示指令である。
【００７８】
図９に、要請作成画面４２の一例を示す。阿部氏は、要請作成画面４２の内容フィールド４２ａにアポイントメントの内容を「Ｐ社訪問」と入力し、同様に場所フィールド４２ｂに「横浜」と場所を入力する。続けて、日付・時間エリア４２ｃのＧＵＩ部品を用いて、候補日と時間とを入力する。阿部氏は、コンボボックスとなっている日時フィールドを使用して日時を特定する。このとき、第１候補を金曜日（２４日）、第２候補を木曜日（２３日）とする。また、招集ユーザー特定用エリア７４を使用して、招集したいユーザーを選択する。この招集ユーザー特定用エリア７４については、第２実施形態で再度説明する。そして、要請するボタン４２ｅへの押下操作により、入力した要請データをサーバー１０に送信する。サーバー１０は、要請データ格納制御部５２が、図１３等に示す処理を行う。
【００７９】
図１０は、要請通知エリア４４ａ，４４ｂを有する個人カレンダー画面の一例を示す説明図である。招集ユーザーである山田氏は、自分のカレンダー画面４４を開くと、要請通知エリア４４ｂに阿部氏からの要請が表示されている。自分のスケジュール確認という普段の活動の中でアポイントメント要請に気づくことができるため、すぐに返信作業に移ることができる。そして、カレンダーのうち２４日金に、黒丸が付された状態で予定が記入されている。これは、要請データの招集ユーザーへの通知であり、招集ユーザーである山田氏は、個人のカレンダー画面４４を開くだけで、要請通知エリア４４ａに要請データの概要が表示され、且つ、自分の予定としてカレンダーに表示される。すなわち、要請データ通知制御部５４は、カレンダー画面制御部５１と協調して、各個人のカレンダーにアポイントメントの要請データをスケジュールとして表示することで、要請データの通知を行う。要請通知エリア４４ｂは、ボタンとなっており、この領域をクリックする操作は、調整画面４６の表示指令をサーバー１０に送信する。
【００８０】
また、要請データ通知制御部５４は、電子メールにてリアルタイムに要請データを送信するようにしてもよい。山田氏、返答を入力するためにひとまず返答画面（調整画面４６）を開いてみた。
【００８１】
図１１は、招集ユーザー用の調整画面４６の一例を示す説明図であり、ここでは招集ユーザーである山田氏用の調整画面である。山田氏は、海老沢氏と鈴木氏はすでに木曜日に×（不参加）、金曜日に○（参加）と回答しており、和田氏は未回答であることを把握する。山田氏は、木曜日にはすでに約束が入っている。さらに、このシステムには入力していないが、実は金曜日の該当時間は自己啓発のため毎週英会話学校に通っていた。今回が第一回のプレゼンであることと、鈴木氏が参加することが判ったので、彼に代表して説明してもらうこととした。木曜、金曜とも×（不参加）回答を記入する。参加又は不参加の入力は、コンボボックス４６ａ，４６ｂからの選択としている。また、調整画面４６の返信コメント入力フィールド４６ｃは、通常のテキスト入力を促す。
【００８２】
一方、和田氏は、別件で外出中につき、要請が来ていることにまだ気づいていない。偶然にも、外出先の顧客と金曜日に接待ゴルフの約束をしてしまった。オーナーである阿部氏が各メンバーの予定を参照したときには、和田氏は金曜日は空いていたが、このアポの手続き中に状況が変化した。
【００８３】
翌日、Ｐ社から阿部氏に突然連絡が入り、次回を最終のプレゼンテーションとして、これをもってオフィス家具購入決定の判断を行うと通告された。さらに、本日中に回答しないと、金曜日にＰ社側に他の用事が入ってしまう可能性があるとの連絡を受けた。
阿部氏は、このプレゼンの重要性が一気に上がったため、万全の説明体制と誠意をみせるため、できるだけ多くのメンバーを出席させ、さらに今日中に期日を確定してＰ社に返答する必要が生じた。阿部氏は、確定用調整画面４８を開く。
【００８４】
図１２は、オーナー用の調整画面（確定調整画面４８）の一例を示す説明図である。阿部氏は、×（不参加）回答の山田氏と、未回答の和田氏とをなんとしてでも参加させようと、両名の携帯に電話をした。両名とも外出中であったが、山田には英会話の中止、和田には先方とのゴルフの予定を変更してもらい、プレゼン参加の了解を取ることができた。しかし、両名ともパソコンを持ち歩いていないので、返信の入力とスケジュール記入ができないと主張した。
【００８５】
ここでメンバーへの確定の連絡が遅れると、○（参加）回答している海老沢氏や鈴木氏も重要度に変化があったことを知らせていないので、他のプロジェクトの予定とのブッキング発生の危険性がある。また、外出中の山田や和田もスケジュールへの記入忘れの懸念が残った。一方、阿部はすぐにでも期日を確定して、Ｐ社に連絡をいれ、全招集ユーザーに他の予定を入れないよう連絡する必要があった。
【００８６】
そこで、阿部氏は、山田氏と和田氏の調整画面４６の強制チェックボックス４９をチェックし、第１候補の確定ボタン４９ａを押した。この瞬間、全員に金曜日にプレゼンが決定した旨メールが発信され、正式なスケジュールとして全メンバーのカレンダーに記入された。幸い、Ｐ社担当者の金曜日の予定が埋まってしまう前に約束の連絡を取ることができた。図１２に示す例では、強制テックボックス４９へのチェックが、オーナーによる確定調整操作である。なお、オーナーは一旦要請したアポイントメントをその後の事情変化や参加者数などに応じてこの確定調整画面４８を用いて中止することもできる。中止を確定するには、符号４８ｂで示す中止ボタンをクリックする。中止指令を受信する確定処理制御部６０は、中止されたアポイントメントに関するレコードをすべて削除する。
【００８７】
図１３は、要請データ格納制御部による要請データの格納処理の一例を示すフローチャートである。図９に示す必須入力項目が入力され、オーナーによって要請するボタン４２ｅがクリックされると、端末１のブラウザは、入力された要請データにログインユーザーのユーザーＩＤ（ここでは、オーナー）を付加して、当該要請データをサーバー１０に送信する。サーバー１０は、要請データを受信すると、図１３に示す処理を開始する。すなわち、要請データ格納制御部５２は、まず、新しい要請データに対して、新しい予定ＩＤを取得する（ステップＳ１）。ここでは、要請データの候補日順位毎に予定ＩＤを取得する。続いて、アポイントメント候補日順位を“１”とする（ステップＳ２）。さらに、オーナーのアポイントメントユーザー順位を“０”とする。
【００８８】
続いて、アポイントメントユーザー順位を付するため、ｘ＝１とし（ステップＳ４）、招集ユーザーのアポイントメントユーザー順位をｘとする（ステップＳ５）。これを図９に示す「招集したいユーザー」全てについて完了するまで（ステップＳ６）、ｘの値をインクリメントして、アポイントメントユーザー順位を設定する。
【００８９】
アポイントメントユーザー順位を設定すると、続いて、図６に示すデータ構造のアポイントメント予定テーブル３２に、予定ＩＤ、ユーザーＩＤ、アポイントメントユーザー順位、候補日順位、予定開始日時、予定終了日時を格納する（ステップＳ８）。続けて、予定メインテーブル３６に予定ＩＤと、全ユーザーのユーザーＩＤと、予定種類コードと、予定内容データ（Ｐ社訪問）と、予定場所データ（横浜）とを格納する。予定種類コードは、ここではアポイントメント調整中の予定であることを示すコード“１”を格納する。これにより、予定ＩＤをキーとして、第１候補日順位についての要請データを格納した。各種の制御部は、予定ＩＤをキーとして予定メインテーブル３６を参照すると、当該予定ＩＤで識別される予定が通常予定であるのか、それともアポイントメント調整中の予定であるかを特定することができる。
【００９０】
続けて、次の候補日順位のデータがあるか否かを確認し（ステップＳ１０）、ここでは、第２候補日順位のデータがあるため、ステップＳ１に戻り、第２候補日順位用の予定ＩＤを取得する。第２候補日順位についても同様に要請データをアポイントメント調整中の予定データとして格納し、第３候補日順位のデータはないため、処理を終了する。
【００９１】
図１４は、確定処理制御部６０によるアポイントメントの確定処理の一例を示すフローチャートである。端末１のブラウザは、図１２に示す最新の返信状態データの表示中に確定するボタン４９ａがクリックされると、この確定操作によるイベントはサーバーに送信する。また、ブラウザは、強制チェックボックス４９のチェックの有無もサーバー１０に送信する。確定するボタン４９ａは予定ＩＤと、候補日順位と関係しているため、サーバー１０は、端末１から、少なくとも、予定ＩＤと、候補日順位と、強制チェックボックス４９のオン／オフとを受信する。
【００９２】
サーバー１０では、確定処理制御部６０が、この確定操作を受信したときに、図１４に示す処理を開始する。まず、確定された候補日順位以外の順位の予定ＩＤに関するレコードを全て削除する（ステップＳ１１）。
【００９３】
続いて、確定された候補日順位の予定ＩＤからアポイントメント予定テーブル３２を検索して予定開始日時と予定終了日時とを読み出し、当該予定ＩＤと、予定開始日時と、予定終了日時とを新たに通常予定テーブル３４へ格納する（ステップＳ１２）。すなわち、確定した予定に関するデータを、アポイントメント予定テーブル３２から通常予定テーブルへ複写する。
【００９４】
さらに、当該予定ＩＤをキーとして、アポイントメント予定テーブル３２から招集ユーザーの出欠を順に確認する（ステップＳ１３）。招集ユーザーの探索順序は、アポイントメントユーザー順位の順序とし、ここでは、まず、順位“０”のオーナーである阿部氏について確認する。阿部氏の出欠フラグは“１”であるため、当該予定ＩＤと阿部氏のユーザーＩＤとで予定メインテーブルを検索し、その予定種類コードを“１”から“０”に変更する（ステップＳ１５）。すなわち、当該第１候補のアポイントメントを阿部氏の通常予定とする。そして、通常予定とした後に、該当するユーザーＩＤに関するアポイントメント予定テーブル３２のレコードを削除する。ステップＳ１６，Ｓ１３にて次に順位“１”の海老沢氏が特定され、同様に処理する。
【００９５】
山田氏については、ステップＳ１４にて、出欠フラグは“０”であるため、ステップＳ１７に進む。ステップＳ１７では、強制チェックボックスがオンであるか否かを確認し、強制チェックボックスがオンであるため、ステップＳ１５にて同様に予定種類コードを通常予定へ更新する。出欠フラグが格納されていない和田氏についても、強制チェックボックスがオンであるため、予定種類コードを通常予定とする。
【００９６】
予定種類コードが通常予定となると、各ユーザーの各カレンダー画面にて自分のスケジュールとして表示される。
【００９７】
図１５は、カレンダーへの予定表示処理の一例を示すフローチャートである。図８に示す個人カレンダー画面４４は、図中左上から、表示指定エリア４０ｃと、月／週指定エリア４０ｄと、要請通知エリア４０ｂとを備え、さらに、プロジェクト／部署選択コンボボックス４０ｆと、カレンダーテーブル４０ｇと、カレンダーフィールド４０ｈとを備えている。本実施例では、表示指定として、個人の月表示、部署の週表示及び日表示、プロジェクトの週表示及び日表示とを有する。図８に示す例では、表示指定はプロジェクトの週表示であり、コンボボックス４０ｆによりＰ社新築ビルプロジェクトというプロジェクトが選択されている。表示する週は、月／週指定エリア４０ｄの操作に応じて、２００３年１月１９日からである。
【００９８】
サーバー１０のカレンダー画面制御部５１は、端末１からカレンダー画面の表示指令を受信したときに、図８等に示すカレンダー画面の表示処理を行う。図１５に示すように、カレンダー画面制御部５１は、まず、ユーザーＩＤを参照して、設定情報等を読み出し、カレンダー画面の定型情報を生成する（ステップＳ２１）。ここでは、エリア４０ｃ，４０ｄなどである。続いて、カレンダー画面制御部５１は、表示指定に応じてカレンダーテーブルを生成する（ステップＳ２２）。週表示であれば、日曜から土曜までの列と、プロジェクトのメンバー数に応じた個数の行とを有する空のカレンダーテーブルを生成する。カレンダーテーブルの各フィールドを、ここではカレンダーフィールドという。
【００９９】
続いて、カレンダー画面制御部５１は、カレンダーテーブルの各カレンダーフィールドの表示処理を行う。すなわち、図８に示す例ではユーザーＩＤ毎に、通常予定テーブル３４とアポイントメント予定テーブル３２との予定開始日時を参照する。そして、カレンダーテーブル内の過去の日付から順にカレンダーフィールドを特定する（ステップＳ２３）。まず、阿部氏について１９日のカレンダーフィールドの特定では、両テーブル３２，３４に１９日の予定が格納されているか否かを探索し（ステップＳ２５）、格納されていないため、全日付完了したか否かを確認して（ステップＳ３０）、完了していないため、処理を２０日に移す。
【０１００】
２０日では、通常予定テーブル３４に、「戦略会議」との予定が格納されている。ステップＳ２４でイエスとなるため、予定の種類コード２５を参照して、通常予定であるため、予定日時を黒色に設定する。続けて、同日に他の予定がなければ（ステップＳ２９）、ステップＳ３０，Ｓ２３を介して２１日の処理を開始する。２１日には、山田氏からのアポイントメント要請があり、アポイントメント予定テーブル３２に１月２１日１３：００との予定開始日時が格納されている。ステップＳ２５では、予定種類がアポイントメント予定であるため、予定日時の文字表示を赤色に設定する。図面では、文字を赤色にする処理に変えて、黒丸４０ｅを付した。
【０１０１】
同様に２５日までの処理を行い、さらに、各ユーザーについて同様に予定を探索する。図１５に示す例では、アポイントメント予定と、通常予定とで表示する文字の色を変化させるため、アポイントメントの要請があったことを一見して把握することができる。
【０１０２】
予定データの読み出し及び色の設定が全て完了すると（ステップＳ３１）、カレンダーテーブルをＨＴＭＬ等のマークアップ記述言語で記述する。
【０１０３】
さらに、アポイントメント予定テーブル３２を参照して、要請通知エリア４０ｂに要請データを要請の日付順に記述する。この要請通知エリアは、調整画面を表示するためのボタンとする。
【０１０４】
＜事例２＞
上述した事例１では、企業活動を支援するための本実施例によるシステムの使い方を例示したが、企業のみならず、大学の研究室などでも活用できる。アポイントメントとしては、ゼミやセミナーなどのアポイントメントの外、実験設備の部品買い出しの約束や、コンパなどの約束形成にも使用することができる。本実施形態では、他ユーザー出欠参照制御機能６２を有するため、例えば、男性５人女性３人のグループでの飲み会の企画で、１人では参加できないと考える女性がいたとすると、他の女性の参加を確認してから参加の返信を行うこともできる。また、買い出しとコンパとを続けて行う場合に、コンパにのみ参加表明した招集ユーザーに対して、オーナーが強制的に買い物へも強制参加させるなど、オーナーのリーダーシップを引き出し、気持ちと情報の共有とに寄与することができる。
【０１０５】
＜事例３＞
我が国では、適度な控えめさが人間関係の潤滑油として機能している。そのような控えめさは、例えば、ある活動について、自分は立場的、経験的に未熟であるとして、参加しない行為を生む。本実施例のオーナーによる強制調整制御機能は、控えめな招集ユーザーに、参加を促す仕組みとなる。あるアポイントメントについて、控えめな招集ユーザーは、日程的な不都合はないが、控えめに不参加を表明する。これに対し、オーナーが強制参加命令を行う。そうすると、控えめな招集ユーザーは、自分が一旦は不参加を表明したこと、それにもかかわらずオーナーからの命令があったことを、なんら積極的な連絡のための作業をすることなく、他のユーザーに知っておいてもらうことができる（他ユーザー出欠参照制御機能）。
【０１０６】
図１６は、本実施形態及び本実施例による生産性向上を招集ユーザーの数との関係で説明する説明図であり、図１６（Ａ）はオーナーに必要な連絡回数を示す図で、図１６（Ｂ）は招集ユーザーに必要な連絡回数を示す図である。
一般的に、アポイントメントを取るには、電話や電子メールが利用されている。電子メールによるアポイントメントでは、オーナーは、候補日の問い合わせの発信を全員同報とすると、１回の作業で、電話では、（人数）回必要となる。本実施例では、要請データの入力は１回であるため、作業数は１回である。オーナーは、返信の受信について、電子メールの場合には（人数）回、電話では問い合わせと返信とを同時にできるとして、０回、本実施例では確定用調整画面に全員の返信が表示されるため、１回である。候補日の確定を連絡するには、電子メールでは全員同報で１回、電話では（人数）回、本実施例では１回である。予定が確定したとして、スケジューラーへの入力が電子メールでも電話でも１回必要となる。図１６（Ａ）は、このオーナーの連絡回数の相違を招集ユーザーの人数とグラフとして表したものである。図１６（Ａ）に示すように、本実施例によるシステムでは、招集ユーザーの人数が増加しても、連絡回数は３回のみである。電話による場合、候補日の連絡及び予定確認に人数分、候補日の決定で人数分の電話連絡が必要となる。電子メールの場合には、返信の受信が個別となるため、また、返信の時期が一定でなく、オーナーには、電子メール及び内容整理の作業負荷がかかってしまう。このように、本実施例によるシステムでは、オーナーの作業負荷を電話や電子メールと比較して大幅に軽減することができる。
【０１０７】
次に、招集ユーザーの延べ連絡回数を検討する。アポイントメントの要請の受信では、電子メール、電話及び本実施例によるシステムでは共に招集ユーザー一人当たり１回である。返信の送信は、電子メールでは招集ユーザー一人当たり１回で、電話は０回、本実施例では１回である。電子メールでは、招集ユーザーが相互に返信の受信を行うと、（人数−１）回必要で、電話では他の招集ユーザーの返信状況を各招集ユーザーが把握することは難しい。本実施例では、招集ユーザーは自ら返信する際に他のユーザーの返信状況を把握するため、返信の受信に必要な回数は０回である。確定の通知受信は、それぞれ同じく１回である。本実施例では、メンバーについても、スケジューラーへの入力は不要である。
【０１０８】
図１６（Ｂ）に示すように、招集ユーザー全員で必要とする延べ連絡回数を集計すると、他の招集ユーザーの返信状況を招集ユーザー全員が把握するには、膨大な電子メールの送受信が必要となってしまう。一方、電話では他ユーザー出欠参照は難しい。この点、本実施例では、自ら返信する画面にて他のユーザーの返信状況を表示する仕組みを採用したことにより、連絡回数を少なくしつつ、各招集ユーザーの状況を鑑みた返信を促すことができる。また、アポイントメントの要請の通知を各ユーザーのカレンダー画面に対して行い、また、確定によりアポイントメント予定テーブルから通常予定テーブルへと管理を移し、さらに、カレンダーにて通常予定を表示する仕組みでは、日常的なスケジュールの確認作業中に要請の受信と確定の受信とを行うことができるため、招集ユーザーの実質的な作業は返信のみとすることができる。
【０１０９】
＜第２実施形態＞
第２実施形態では、同一出願人による特許文献４の開示を前提として、プロジェクト活動の支援を行うシステムでのアポイントメント調整支援機能を開示する。すなわち、第２実施形態では、上記第１実施形態及び実施例に開示した手法をプロジェクト活動支援システムにて有効に機能させ、プロジェクトの生産性を向上させるための仕組みを開示する。
【０１１０】
図１７は、第２実施形態の構成例を示すブロック図である。第２実施形態によるプロジェクト活動支援システムは、複数のユーザーによってそれぞれ使用される端末１とネットワークを介した各種データの送受信を処理するサーバー（Ｗｅｂサーバー）１０と、このサーバー１０に併設され前記ユーザーの予定に関するデータを管理するデータベース２とを備えている。
【０１１１】
そして、データベース２が、図１又は図６等に示すテーブルの他、ユーザーの一部又は全部が参加するプロジェクトを識別するプロジェクトＩＤ毎に、当該プロジェクトのメンバーとなるユーザーのユーザーＩＤと、当該プロジェクトに属するコンテンツとを格納するプロジェクト関連テーブル３８を備えている。
【０１１２】
また、サーバー１０は、本実施形態では、プロジェクト関連テーブル３８を参照して、当該プロジェクトのメンバーによって使用される端末と通信して、当該プロジェクトのコンテンツの参照、編集及び登録を促すプロジェクト画面９０を管理するプロジェクト活動支援制御部７２を備えている。
【０１１３】
図１８はプロジェクト画面９０の一例を示す説明図である。図１８に示すように、プロジェクト画面９０は、そのコンテンツとして、プロジェクトの内容１００や、プロジェクトのメンバーリスト１０１や、電子会議室（掲示板，ＢＢＳ）や、文書管理にて管理される各種ファイルや、アポイントメント履歴１０４を含む。アポイントメント履歴１０４は、プロジェクトと関連して要請されたアポイントメントに関するデータのうち、確定した予定データをアポイントメントの履歴として管理するものである。アポイントメント履歴データは、予定内容データや、予定場所データや、オーナー、招集ユーザー、予定開始時刻、予定終了時刻を有すると良い。また、返信コメントや強制チェックボックスのチェックなどをアポイントメント履歴として管理するようにしてもよい。
【０１１４】
本実施形態では、アポイントメントの調整支援処理に関して、第１実施形態や実施例とほぼ同様に、要請制御部１４と、調整制御部１６とを備える。図８から図１２の画面例は、第２実施形態の画面例として援用する。同一の符号を付した同一の構成要件については、第２実施形態と第１実施形態及び実施例とで共通する。
【０１１５】
要請制御部１４は、データベース２へ接続し、前記オーナーによって使用される端末１と通信して、アポイントメントの要請に関する要請データの入力を促す要請作成画面４２（例えば、図９に示す画面）を送信すると共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末１へ送信する。
【０１１６】
調整制御部１６は、前記データベース２へ接続し、前記要請データが送信された招集ユーザーによって使用される端末１と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促す調整画面４６（例えば、図１０に示す画面）を送信すると共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブル３２を用いて管理する。
【０１１７】
そして、要請作成画面４２は、図９に示すように、当該アポイントメントに招集する招集ユーザーの候補となる候補者リストを抽出すると共に、当該候補者リストからの招集ユーザーの選択を促す招集ユーザー特定用エリア７４を備えている。
また、本実施形態では特に、要請制御部１４が、前記オーナーが要請作成画面４２の表示を要求した際の表示画面のプロジェクトＩＤから前記プロジェクト関連テーブル３８を参照して、当該プロジェクトのメンバーであるユーザーＩＤの一覧から候補者リストを抽出する操作画面別候補者リスト生成機能７８を備えている。例えば、図１８に示すプロジェクト画面９０が「Ｐ社新築ビルプロジェクト」であって、そのメンバーが阿部氏、海老沢氏、山田氏、和田氏、鈴木氏であるとする。そして、図１８に示すプロジェクト画面９０から要請作成画面４２の表示を要求した場合には、操作画面別候補者リスト生成機能７８は、「Ｐ社新築ビルプロジェクト」のプロジェクトＩＤから、そのプロジェクトのメンバーをプロジェクト関連テーブル３８から読み出してそのメンバーを招集ユーザーの候補者とする。このため、オーナーは、自然な操作で、プロジェクト毎のメンバーを記憶しておくことなく、また、調べることなく、各プロジェクトのメンバーから招集ユーザーを特定することができる。
【０１１８】
再度図１７を参照すると、本実施形態では、好ましくは、サーバー１０は、前記各ユーザー個人の情報管理を促す個人画面８０を管理する個人情報管理支援制御部８２を備える。そして、データベースが、前記ユーザーの所属部門を識別する部門ＩＤ毎に当該部門に所属するユーザーＩＤを格納する部門テーブル３１を備える。この部門テーブル３１を有する例では、操作画面別候補者リスト生成機能７８は、前記オーナーによって要請作成画面４２の表示が要求された際の表示画面が個人画面８０である場合には、当該オーナーの所属する部門ＩＤから前記部門テーブル３１を参照して、当該部門に所属するユーザーのユーザーＩＤの一覧から候補者リストを抽出する機能を備える。このように、プロジェクトに関連する画面から要請作成画面が呼び出された場合には招集ユーザーの候補をプロジェクトメンバーとし、一方、個人画面８０から要請作成画面が呼び出された場合には、オーナーと同一の部門に所属するユーザーを候補者とする。
【０１１９】
図９に示すように、要求画面９は、招集ユーザー特定用エリア７４に、候補対象者一覧を表示する候補者リストボックス７５と、この候補者リストボックス７５から選択された要素であるユーザー名の一覧を表示する招集ユーザーリストボックス７６と、候補者リストのキーとなるプロジェクト名又は部門名の選択を促すポップアップリスト７７とを備えている。この例では、要請データの作成に際してユーザー名を直接入力せずに、プロジェクト名や部門名からユーザー名を表示させ、そのユーザー名データそのものをＧＵＩ部品として招集したいユーザーの特定操作を促す。従って、ユーザー名を完全にユーザーＩＤで管理することができる。また、オーナーは、プロジェクトや部門などの自然なグループ分けで招集ユーザーを特定することができる。
【０１２０】
本実施形態によるプロジェクト活動支援システムは、第１実施形態と同様に、調整制御部１６が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信する他ユーザー出欠参照制御機能１８を備える。そして、本実施形態では、要請制御部１４が、前記候補者リストボックスから選択されるユーザーの順位を前記アポイントメント予定テーブルにアポイントメントユーザー順位として格納し、他ユーザー出欠参照制御機能１８が、ユーザー順位に指定された順位で返信状態データを生成する機能を備える。
【０１２１】
次に、アポイントメント履歴の管理について説明する。本実施形態では、図１７に示すように、プロジェクト活動支援制御部７２が、プロジェクトＩＤで識別されるプロジェクトに関係するコンテンツ・データを単一のプロジェクト・デスクトップ画面に表示するプロジェクト・デスクトップ画面管理機能８４と、コンテンツ・データとして前記確定された予定データを前記プロジェクト・コンテンツとして登録する確定予定コンテンツ管理機能８６と、ユーザーによって使用される端末１に入力されるデータと一致するデータを含むコンテンツを検索すると共に、当該検索の検索結果として当該検索されたコンテンツを含むプロジェクトの一覧を前記端末に送信する検索制御機能８８とを備える。
【０１２２】
プロジェクト・デスクトップ画面管理機能８４は、図１８に示すように、複数種類のコンテンツを単一の画面に表示する。この単一の画面を、プロジェクト・デスクトップという。そして、確定予定コンテンツ管理機能８６は、確定された予定データをプロジェクト・デスクトップのコンテンツとして登録する。すなわち、プロジェクトに関する過去のアポイントメントについての情報が、プロジェクト・デスクトップのコンテンツとして登録される。アポイントメントについての情報は、予定の内容、場所、時間、参加者、オーナー等である。
【０１２３】
検索制御機能８８は、ユーザーによって使用される端末１に入力されるデータと一致するデータを含むコンテンツを検索すると共に、当該検索の検索結果として当該検索されたコンテンツを含むプロジェクトの一覧を前記端末１に送信する。検索画面９１の一例を図１９に示す。検索制御機能８８は、コンテンツの検索結果から、そのコンテンツの所属するプロジェクトＩＤを特定し、検索結果としてプロジェクト・デスクトップへのリンク９１ａを表示する。そして、そのコンテンツとしてアポイントメント履歴が含まれるため、多数のプロジェクトが並行している場合や、記憶の薄れた時期のプロジェクトについて、アポイントメントの参加者の氏名や、地名（アポイントメントの場所）などで検索することができる。
【０１２４】
再度図１７を参照すると、プロジェクト活動支援制御部７２が、前記プロジェクトの完了後に当該プロジェクトのプロジェクト・デスクトップ画面をＨＴＭＬ等のページ記述言語に変換するホームページ作成支援機能８９を備える。ホームページ作成支援機能８９は、図１８に示すプロジェクト・デスクトップの各コンテンツ等のデータを確定し、静止状態にして、ＨＴＭＬファイルと、このＨＴＭＬファイル中にてリンクされた画像や文書ファイル等に変換する。プロジェクト・デスクトップには、プロジェクトの初期から完了までの作業に応じた種々の重要なデータが集約されているため、プロジェクト活動に関する記録となる。また、本実施形態では、会議の履歴などをコンテンツとして管理できるため、一定の研究会などで社内、学内又は外部に情報公開する必要がある場合にも、ホームページ作成支援機能８９により簡単に閲覧しやすいデータに変換することができる。そして、アポイントメント履歴に、文書管理コーナー等を用いて会議等の議事録ファイルを関連させると、さらに情報公開や記録に有用である。
【０１２５】
【発明の効果】
本発明は、その構成によって、要請制御部が、オーナーによって入力されるアポイントメントの要請データを招集ユーザーに送信し、調整制御部が、招集ユーザーからの返信の有無及び内容を返信状態データとして管理する。そして、他ユーザー出欠参照制御機能が、アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する。従って、それぞれの招集ユーザーに対して、他の招集ユーザーの返信有無と、返信の内容とを通知することができる。すなわち、すでに返信をしている第１の招集ユーザーがいる場合には、その第１の招集ユーザーの出欠を、返信データを作成中の第２の招集ユーザーが参照することができる。すると、当該アポイントメントについての招集ユーザー自身の必要性を自ら判断することができる。
すなわち、会議の目的が２つのグループ（技術と営業など）の意思疎通である場合には、第２の招集ユーザーと第１の招集ユーザーとが同一のグループであるとき、第２の招集ユーザーは、業務の生産性向上のために他のアポイントメントを優先すると判断することもできる。逆に、会議の目的が対立する２つの概念のうち、どちらを選択するかについての検討（製品の最終デザインの決定など）であれば、第１の招集ユーザーが第２の招集ユーザーとは反対意見の持ち主で、且つ、今まで議論してきた経過からカウンターパートは自分であるとの第２の招集ユーザーが判断するのであれば、オーナーの指示を要さず、第２の招集ユーザーは自ら参加すべきとの判断を行うことができる。
また、アポイントメントが懇親会などであって、あの人が参加するのなら、私も参加しよう、という考えの持ち主は、調整画面を何度も表示して、あの人の参加を確認してから、返信データを作成することができる。また、最初に返信する招集ユーザーも、他の招集ユーザー名を確認してから返信データを作成できるため、そのメンバーによっては自らがリーダーシップを発揮すべきと招集ユーザー自身が判断するのであれば、積極的な参加や、他の招集ユーザーへの参加の働きかけなどが期待される。
このように、ユーザー出欠参照制御機能が、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての返信状態データを送信することで、各招集ユーザーの自発的な活動を促し、また、招集ユーザー間の参加の調整などについて個々のオーナーの作業を必要とせず、また、各招集ユーザーがアポイントメントと自らの役割との関係を考慮した上でアポイントメントへの出欠を決定できるため、オーナーの招集に関する能力に過度に依存することなく、会議の生産性を向上させることができる。
上記のように、本発明によると、オーナーの手間を削減しつつ、アポイントメントの調整及び実際の会議等の開催に関して生産性を高めることができる。
【０１２６】
さらに、本発明が強制調整制御機能を備える構成では、当該機能が、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する。このため、オーナーは、出欠の返信データと、返信待ちの状態とを参照して、強制的に招集ユーザーの出欠をシステム的に命令し、確定させることができる。すなわち、要請時に強制的に招集ユーザーの参加を命ずるのではなく、オーナーの判断によるオーナーの意思に基づいたアポイントメントの確定時に、招集ユーザーの出欠を強制的に調整することができる。これにより、第１に、アポイントメントの調整を早期に確定することができる。第２に、各招集ユーザーの重要性の判断を、オーナーによる確定時まで遅らせるこができる。これらにより、実際のニーズにあった柔軟なアポイントメント調整を実現することができる。そして、システムの機能としてオーナーに出欠の強制的な調整の権能を付加することで、オーナーがリーダーシップを発揮しやすい仕組みを導入することができる。
このように、強制調整制御機能を備えた構成では、各ユーザーの予定やアポイントメントの重要性が刻々と変化する状況にあっても、オーナーの手間を増加させずに柔軟にアポイントメントの調整を行うことができる。
【図面の簡単な説明】
【図１】図１は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図である。
【図２】図２は、本実施形態でのデータ構造の一例を示す説明図である。
【図３】図３は、本実施形態で取り扱うデータの一例を示す図で、図３（Ａ）は要請データの一例を示す図で、図３（Ｂ）は返信状態データの一例を示す図で、図３（Ｃ）はオーナー用の調整データの一例を示す図である。
【図４】図４は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。
【図５】図５は、本実施例の構成例を示すブロック図である。
【図６】図６は、本実施例でのデータ構造の一例を示す説明図である。
【図７】図７は、本実施例での各テーブルのフィールド名の一例を示す説明図である。
【図８】図８は、ユーザー予定データ表示画面の一例を示す説明図である。
【図９】図９は、要請作成画面の一例を示す説明図である。
【図１０】図１０は、要請通知エリアを有する個人カレンダー画面の一例を示す説明図である。
【図１１】図１１は、招集ユーザー用の調整画面の一例を示す説明図である。
【図１２】図１２は、オーナー用の調整画面（確定画面）の一例を示す説明図である。
【図１３】図１３は、要請データの格納処理の一例を示すフローチャートである。
【図１４】図１４は、確定処理の一例を示すフローチャートである。
【図１５】図１５は、予定表示処理の一例を示すフローチャートである。
【図１６】図１６は、本実施形態及び本実施例による生産性向上を招集ユーザーの数との関係で説明する説明図であり、図１６（Ａ）はオーナーに必要な連絡回数を示す図で、図１６（Ｂ）は招集ユーザーに必要な連絡回数を示す図である。
【図１７】図１７は、第２実施形態の構成例を示すブロック図である。
【図１８】図１８は、プロジェクト・デスクトップ画面の一例を示す説明図である。
【図１９】図１９は、本実施形態による検索結果の一例を示す説明図である。
【符号の説明】
１ 端末
１０ サーバー
１２ ユーザースケジュール送信部
１４ 要請制御部
１６ 調整制御部
１８ 他ユーザー出欠参照制御機能
２０ 返信コメント制御機能
２２ 強制調整制御機能
２４ 同時確定制御機能
２６ 確定予定データ制御部
Claims (20)
- 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、ユーザーテーブルと、アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備え、
前記サーバーが、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、当該アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御部と、
前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを前記返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御部とを備え、
この調整制御部が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーについての前記返信状態データを送信する他ユーザー出欠参照制御機能を備えたことを特徴とするアポイントメント調整支援システム。 - 前記調整制御部が、前記招集ユーザーに当該要請についての返信コメントの入力を促すと共に、当該招集ユーザーによって入力される返信コメントを前記返信データに合成する返信コメント制御機能を備えたことを特徴とする請求項１記載のアポイントメント調整支援システム。
- 前記調整制御部が、前記オーナーによって使用される端末に前記返信状態データを送信すると共に、当該返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する強制調整制御機能を備えたことを特徴とする請求項１又は２記載のアポイントメント調整支援システム。
- 前記調整制御部が、前記オーナーによって前記各招集ユーザーの出欠について強制調整操作なされた後、一回の確定操作で、当該強制調整操作された返信状態データを前記確定予定データとして、全招集ユーザーについて当該アポイントメントを同時に確定させる同時確定制御機能を備えたことを特徴とする請求項３記載のアポイントメント調整支援システム。
- 前記強制調整制御機能が、前記強制調整操作があった返信データを、前記返信状態データによって返信待ちである招集ユーザーの返信データの作成を当該オーナーが代行した代行返信データとして管理する機能を備えたことを特徴とする請求項３又は４記載のアポイントメント調整支援システム。
- 前記強制調整制御機能が、前記返信状態データによって返信待ち又は不参加である招集ユーザーに対して、当該オーナーの判断で強制的に参加が命じられた場合に、当該強制参加対象の招集ユーザーの返信データを強制的に参加に設定した強制参加返信データとして管理する機能を備えたことを特徴とする請求項３，４又は５記載のアポイントメント調整支援システム。
- 前記返信データが、出欠に関して、返信を保留することを示す保留コードを有さずに参加コード及び不参加コードのみを備えたことを特徴とする請求項６記載のアポイントメント調整支援システム。
- 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、
前記ユーザーに関するデータを格納するユーザーテーブルと、
アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルと、
各ユーザーの予定データを格納する通常予定テーブルとを備え、
前記サーバーが、前記データベースに接続し、前記ユーザーによって使用される端末と通信し、前記通常予定テーブルに格納された各ユーザーの予定データを当該端末へ送信するユーザースケジュール送信部と、
前記サーバーが、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御部と、
前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御部とを備え、
この調整制御部が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信する他ユーザー出欠参照制御機能と、
前記オーナーによって使用される端末に前記返信状態データを送信すると共に、当該返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによる各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを確定予定データとして管理する強制調整制御機能を備え、
前記サーバーが、当該確定予定データを前記通常予定テーブルでの各ユーザーの予定データとして格納する確定予定データ制御部とを備えたことを特徴とするアポイントメント調整支援システム。 - 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、このデータベースが、前記ユーザーに関するデータを格納するユーザーテーブルと、アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備えたアポイントメント調整支援システムの前記サーバーを使用してアポイントメントの調整を支援する処理を行うアポイントメント調整支援処理方法であって、
前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御工程と、
前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御工程と、
前記データベースへ接続し、前記オーナーによって使用される端末と通信して、前記アポイントメント予定テーブルに格納された返信状態データを当該端末に表示して、当該オーナーによってアポイントメントの確定操作がなされた場合には当該確定された返信状態データを確定予定データとして管理する確定制御工程とを備え、
前記調整制御工程が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信する他ユーザー出欠参照制御工程を備えたことを特徴とするアポイントメント調整支援処理方法。 - 前記調整制御工程が、前記返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによって各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを最新の返信状態データとして管理する強制調整制御工程を備えたことを特徴とする請求項９記載のアポイントメント調整支援処理方法。
- 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、このデータベースが、前記ユーザーに関するデータを格納するユーザーテーブルと、アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備えたアポイントメント調整支援システムの前記サーバーを使用してアポイントメントの調整を支援する処理を行うためのアポイントメント調整支援処理用プログラムであって、
当該アポイントメント調整支援処理用プログラムは、前記サーバーを動作させる指令として、
前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促すと共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信するための要請制御指令と、
前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促すと共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブルを用いて管理するための調整制御指令と、
前記データベースへ接続し、前記オーナーによって使用される端末と通信して、前記アポイントメント予定テーブルに格納された返信状態データを当該端末に表示して、当該オーナーによってアポイントメントの確定操作がなされた場合には当該確定された返信状態データを確定予定データとして管理するための確定制御指令とを備え、
前記調整制御指令が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信するための他ユーザー出欠参照制御指令を備え、
前記調整制御指令が、前記返信状態データを参照するオーナーに前記招集ユーザーの出欠の強制調整操作を促し、当該オーナーによって各招集ユーザーの出欠の強制調整操作があった場合には、当該オーナーによって強制調整操作された返信状態データを最新の返信状態データとして管理する強制調整制御指令を備えたことを特徴とするアポイントメント調整支援処理用プログラム。 - 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、
前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納するユーザーテーブルと、
予定を識別する予定ＩＤ毎に、前記ユーザーＩＤと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データと、アポイントメント等で予定する場所である予定場所データとを格納する予定メインテーブルと、
前記予定ＩＤ毎に、予定開始日時データと、予定終了日時データとを格納する通常予定テーブルと、
候補日順位毎の前記予定ＩＤ毎に、当該予定ＩＤのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーＩＤと、当該オーナーと招集ユーザーとを識別すると共に当該招集ユーザーの順位を指定するアポイントメントユーザー順位と、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納するアポイントメント予定テーブルとを備え、
前記サーバーが、
前記オーナーによって使用される端末からアポイントメントの要請を作成するための要請作成画面の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促す要請作成画面を生成する要請作成画面生成部と、
前記要請作成画面が生成されたときに前記オーナーによって使用される端末へ当該要請作成画面を送信し、当該オーナーによって当該要請作成画面に入力される要請データを受信して、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納すると共に、前記要請作成画面の他の各フィールドの内容を前記アポイントメント予定テーブルに格納する要請データ格納制御部と、
前記招集ユーザーによって使用される端末に、前記各テーブルに格納された当該要請データを通知する要請データ通知制御部と、
前記招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面を生成する調整画面生成部と、
前記調整画面が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面を送信し、当該招集ユーザーによって当該調整画面に入力される返信データを受信して、前記出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する返信データ格納制御部と、
前記オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブルを参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する確定処理制御部とを備え、
前記調整画面生成部が、前記招集ユーザーによって使用される端末から前記調整画面の表示指令を受信したときに、前記アポイントメント予定テーブルを参照して、前記調整画面に、他の招集ユーザーのユーザー名、出欠フラグ及び返信コメントを合成する他ユーザー出欠参照制御機能を備えたことを特徴とするアポイントメント調整支援システム。 - 前記調整画面生成部が、前記オーナーによって使用される端末から調整画面の表示指令を受信した場合には、前記アポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出すると共に、各招集ユーザーの出欠に関して強制参加チェックボックスを付加した確定用調整画面を生成する確定用調整画面生成機能と、
前記オーナーによって、前記確定用調整画面の前記強制参加チェックボックスがチェックされた招集ユーザーを強制的に参加に確定し、当該招集ユーザーの通常予定テーブルに当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する強制調整制御機能とを備えたことを特徴とする請求項１２記載のアポイントメント調整支援システム。 - 複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備え、
前記データベースが、
前記ユーザーを識別するユーザーＩＤ毎に当該ユーザーの氏名であるユーザー名データを格納するユーザーテーブルと、
前記ユーザーの一部又は全部が参加するプロジェクトを識別するプロジェクトＩＤ毎に、当該プロジェクトのメンバーとなるユーザーのユーザーＩＤと、当該プロジェクトに属するコンテンツとを格納するプロジェクト関連テーブルと、
アポイントメントのオーナーとなるユーザーから当該アポイントメントに招集される招集ユーザーへ要請されるアポイントメントの内容等の要請データ及び当該要請に対する招集ユーザーからの返信データの有無及び内容を返信状態データとして格納するアポイントメント予定テーブルとを備え、
前記サーバーが、
前記プロジェクト関連テーブルを参照して、当該プロジェクトのメンバーによって使用される端末と通信して、当該プロジェクトのコンテンツの参照、編集及び登録を促すプロジェクト画面を管理するプロジェクト活動支援制御部と、
前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促す要請作成画面を送信すると共に、当該オーナーによって入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する要請制御部と、
前記データベースへ接続し、前記要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによる前記アポイントメントの要請への出欠等の返信データの入力を促す調整画面を送信すると共に、当該招集ユーザーによって入力される返信データの有無と当該返信データの内容とを返信状態データとして前記アポイントメント予定テーブルを用いて管理する調整制御部とを備え、
前記要請作成画面が、当該アポイントメントに招集する招集ユーザーの候補となる候補者リストを抽出すると共に、当該候補者リストからの招集ユーザーの選択を促す招集ユーザー特定用エリアを備え、
前記要請制御部が、前記オーナーが要請作成画面の表示を要求した際の表示画面のプロジェクトＩＤから前記プロジェクト関連テーブルを参照して、当該プロジェクトのメンバーであるユーザーＩＤの一覧から候補者リストを抽出する操作画面別候補者リスト生成機能を備えたことを特徴とするプロジェクト活動支援システム。 - 前記サーバーが、前記各ユーザー個人の情報管理を促す個人画面を管理する個人情報管理支援制御部を備え、
前記データベースが、前記ユーザーの所属部門を識別する部門ＩＤ毎に当該部門に所属するユーザーＩＤを格納する部門テーブルを備え、
前記操作画面別候補者リスト生成機能が、前記オーナーによって要請作成画面の表示が要求された際の表示画面が前記個人画面である場合には、当該オーナーの所属する部門ＩＤから前記部門テーブルを参照して、当該部門に所属するユーザーのユーザーＩＤの一覧から候補者リストを抽出する機能を備えたことを特徴とする請求項１４記載のプロジェクト活動支援システム。 - 前記要請作成画面が、前記招集ユーザー特定用エリアとして、候補対象者一覧を表示する候補者リストボックスと、この候補者リストボックスから選択された要素であるユーザー名の一覧を表示する招集ユーザーリストボックスと、前記候補者リストのキーとなるプロジェクト名又は部門名の選択を促すポップアップリストとを備えたことを特徴とする請求項１５記載のプロジェクト活動支援システム。
- 前記調整制御部が、前記アポイントメント予定テーブルを参照して、全ての招集ユーザー及びオーナーによって使用される各端末に全ての招集ユーザーの前記返信状態データを送信する他ユーザー出欠参照制御機能を備えたことを特徴とする請求項１４，１５又は１６記載のプロジェクト活動支援システム。
- 前記要請制御部が、前記候補者リストボックスから選択されるユーザーの順位を前記アポイントメント予定テーブルにアポイントメントユーザー順位として格納し、
前記他ユーザー出欠参照制御機能が、前記ユーザー順位に指定された順位で前記返信状態データを生成する機能を備えたことを特徴とする請求項１７記載のプロジェクト活動支援システム。 - プロジェクト活動支援制御部が、プロジェクトＩＤで識別されるプロジェクトに関係するコンテンツ・データを単一のプロジェクト・デスクトップ画面に表示するプロジェクト・デスクトップ画面管理機能と、
前記コンテンツ・データとして前記確定された予定データを前記プロジェクト・コンテンツとして登録する確定予定コンテンツ管理機能と、
前記ユーザーによって使用される端末に入力されるデータと一致するデータを含むコンテンツを検索すると共に、当該検索の検索結果として当該検索されたコンテンツを含むプロジェクトの一覧を前記端末に送信する検索制御機能とを備えたことを特徴とする請求項１４記載のプロジェクト活動支援システム。 - 前記プロジェクト活動支援制御部が、前記プロジェクトの完了後に当該プロジェクトのプロジェクト・デスクトップ画面をＨＴＭＬ等のページ記述言語に変換するホームページ作成支援機能を備えたことを特徴とする請求項１９記載のプロジェクト活動支援システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162905A JP2004362477A (ja) | 2003-06-06 | 2003-06-06 | アポイントメント調整支援システム及びプロジェクト活動支援システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162905A JP2004362477A (ja) | 2003-06-06 | 2003-06-06 | アポイントメント調整支援システム及びプロジェクト活動支援システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004362477A true JP2004362477A (ja) | 2004-12-24 |
Family
ID=34054914
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003162905A Pending JP2004362477A (ja) | 2003-06-06 | 2003-06-06 | アポイントメント調整支援システム及びプロジェクト活動支援システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004362477A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2016081220A (ja) * | 2014-10-15 | 2016-05-16 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | メッセージの共有を支援する装置及び方法 |
| JP2020112313A (ja) * | 2019-01-11 | 2020-07-27 | 株式会社富士通ゼネラル | サービス提案時期調整装置および空気調和システム |
| JP2021002255A (ja) * | 2019-06-24 | 2021-01-07 | 株式会社Ｎｐコンサルティング | スケジュール調整システム及びプログラム |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1115874A (ja) * | 1997-06-20 | 1999-01-22 | Nec Corp | スケジュール調整方法およびその装置 |
| JP2001306769A (ja) * | 2000-04-17 | 2001-11-02 | Hitachi Ltd | スケジュール優先予約システム |
| JP2002049729A (ja) * | 2000-08-01 | 2002-02-15 | Kokuyo Co Ltd | プロジェクト活動支援システム及び方法 |
| JP2002056031A (ja) * | 2000-08-11 | 2002-02-20 | Go Fumiko | イベントへの出欠回答システム |
| JP2002169939A (ja) * | 2000-12-01 | 2002-06-14 | Canon Sales Co Inc | 会議システム、及び、会議システム用サーバ並びに操作端末、及び制御方法及び記憶媒体 |
-
2003
- 2003-06-06 JP JP2003162905A patent/JP2004362477A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1115874A (ja) * | 1997-06-20 | 1999-01-22 | Nec Corp | スケジュール調整方法およびその装置 |
| JP2001306769A (ja) * | 2000-04-17 | 2001-11-02 | Hitachi Ltd | スケジュール優先予約システム |
| JP2002049729A (ja) * | 2000-08-01 | 2002-02-15 | Kokuyo Co Ltd | プロジェクト活動支援システム及び方法 |
| JP2002056031A (ja) * | 2000-08-11 | 2002-02-20 | Go Fumiko | イベントへの出欠回答システム |
| JP2002169939A (ja) * | 2000-12-01 | 2002-06-14 | Canon Sales Co Inc | 会議システム、及び、会議システム用サーバ並びに操作端末、及び制御方法及び記憶媒体 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2016081220A (ja) * | 2014-10-15 | 2016-05-16 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | メッセージの共有を支援する装置及び方法 |
| US9819625B2 (en) | 2014-10-15 | 2017-11-14 | International Business Machines Corporation | Supporting message sharing |
| US10257144B2 (en) | 2014-10-15 | 2019-04-09 | International Business Machines Corporation | Supporting message sharing |
| JP2020112313A (ja) * | 2019-01-11 | 2020-07-27 | 株式会社富士通ゼネラル | サービス提案時期調整装置および空気調和システム |
| JP7439381B2 (ja) | 2019-01-11 | 2024-02-28 | 株式会社富士通ゼネラル | サービス提案時期調整装置および空気調和システム |
| JP2021002255A (ja) * | 2019-06-24 | 2021-01-07 | 株式会社Ｎｐコンサルティング | スケジュール調整システム及びプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Bafoutsou et al. | Review and functional classification of collaborative systems | |
| Bellotti et al. | Walking away from the desktop computer: distributed collaboration and mobility in a product design team | |
| KR101204880B1 (ko) | 소셜 네트워크 서비스 기반 문화관광산업 전문 콘텐츠 플랫폼 서비스 시스템 및 방법 | |
| US20140025598A1 (en) | Electronic sourcing management system | |
| US20060015376A1 (en) | Method and system for employee reservation of meeting rooms | |
| US20070174104A1 (en) | Method and system for rotating roles in calendar events | |
| US20120150577A1 (en) | Meeting lifecycle management | |
| US20060122861A1 (en) | Corporate introduction system and method | |
| US20220198384A1 (en) | Gift sending platform for business contacts | |
| US20080177611A1 (en) | Means and methods to coordinate meetings and generation of related documents | |
| JP2002169939A (ja) | 会議システム、及び、会議システム用サーバ並びに操作端末、及び制御方法及び記憶媒体 | |
| CA2518724A1 (en) | Systems or methods for processing group orders | |
| KR20140086549A (ko) | 메신저 프로그램을 이용한 모임 진행 방법 | |
| US20050055264A1 (en) | Method and system for recruiting for, organizing, and managing a volunteer group program | |
| JP2022068796A (ja) | 会計業務支援システム | |
| JP7562063B2 (ja) | 会議管理システム、会議管理方法、文書作成システム及び文書作成方法 | |
| JP7568284B2 (ja) | 日程調整システム、及び日程調整方法 | |
| JP2004362477A (ja) | アポイントメント調整支援システム及びプロジェクト活動支援システム | |
| Harrison et al. | Supporting interviews with technology: how software integration can benefit participants and interviewers | |
| JP2005004307A (ja) | スケジュール管理支援システム及びアポイントメント調整支援システム | |
| JPH10207953A (ja) | スケジュール交渉システムおよびスケジュール交渉エージェントプログラムを記録した記録媒体 | |
| JP2003223535A (ja) | スケジュール管理方法、プログラム及び記録媒体 | |
| JP2003169148A (ja) | 会議管理システム | |
| KR20000059261A (ko) | 인터넷상에서 오프라인기업체 연계에 의한 이벤트 참여시스템 및 방법 | |
| Rockey | Video Round Table, Executive Board Meeting Minutes, January, April, and May, 2018 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051014 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060421 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080407 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080410 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080730 |