JP2005004307A - Schedule management support system, and appointment adjustment support system - Google Patents
Schedule management support system, and appointment adjustment support system Download PDFInfo
- Publication number
- JP2005004307A JP2005004307A JP2003164685A JP2003164685A JP2005004307A JP 2005004307 A JP2005004307 A JP 2005004307A JP 2003164685 A JP2003164685 A JP 2003164685A JP 2003164685 A JP2003164685 A JP 2003164685A JP 2005004307 A JP2005004307 A JP 2005004307A
- Authority
- JP
- Japan
- Prior art keywords
- schedule
- request
- data
- appointment
- user
- 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
- 238000012790 confirmation Methods 0.000 claims description 53
- 238000007726 management method Methods 0.000 claims description 22
- 238000012545 processing Methods 0.000 claims description 18
- 238000013500 data storage Methods 0.000 claims description 15
- 230000005540 biological transmission Effects 0.000 claims description 8
- 230000006870 function Effects 0.000 description 61
- 238000000034 method Methods 0.000 description 41
- 230000008569 process Effects 0.000 description 40
- 238000010586 diagram Methods 0.000 description 21
- 230000000694 effects Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 238000004886 process control Methods 0.000 description 4
- 239000013643 reference control Substances 0.000 description 4
- 230000003442 weekly effect Effects 0.000 description 4
- 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 3
- 238000004891 communication Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
【0001】
【発明の属する技術分野】
本発明は、スケジュール管理支援システムに関し、特に、サーバーと端末とを使用して各ユーザーのスケジュールの管理作業を支援するシステムに関する。
【0002】
【従来の技術】
従来、企業や大学等では、会議や、研修会や、展示会への参加や、旅行などの予定の約束(アポイントメント)を、参加の候補者のスケジュールを調整しつつ、日時を確定する。参加を要請する主催者(オーナー)は、主催者から参加を要請される人(招集ユーザー)に参加を要請し、招集ユーザーからの出欠可否の返答などを参照して、最終的な日時を決定する。招集ユーザーは、自分個人の予定と、参加を要請されるアポイントメントとで日程を調整し、スケジュール管理用のソフトウエアや、手帳などを用いてスケジュールを管理する。
【0003】
特許文献1では、スケジュール情報の共有を目的として、他のユーザーのスケジュールを参照する仕組みと、会議等の共通するスケジュールの決定を容易とする仕組みとが開示されている。この特許文献1の図7では、太い実線の両矢印で示されたスケジュールは開始時間及び終了時間が確定している個人スケジュールで、太い点線の矢印は開始時間又は終了時間の一方が確定している個人スケジュールで、太い中抜きの矢印は、会議等で確定した共通スケジュールで、太い中抜きの矢印で、“?”マークが付されているものは、会議等の主催者から通知された共通スケジュールで、返信をしていないスケジュールである。“?”マークが付されている未確定状態は、参加又は不参加の返信を行うことで確定する。
【0004】
特許文献2では、各ユーザー個人のスケジュールと、複数のユーザーに共通する合計スケジュール(グループスケジュール)とをシステム的に管理する仕組みが開示されている。この特許文献2の段落0073及び段落0079には、通常のスケジュールと、合計スケジュールと一目で把握できるように、色などの表示属性をスケジュールの種類で変化させる手法が開示されている。
【0005】
【特許文献1】
特開平5−165836号公報
【特許文献2】
特開2000−57217号公報
【特許文献3】
特開2002−49729号公報
【0006】
【発明が解決しようとする課題】
上記各従来例では、招集ユーザーは、オーナーからアポイントメントの要請があったことに気がつきにくい、という不都合があった。すなわち、特許文献1及び2では、カレンダーの内部のみにグループスケジュールを表示するため、要請があった日付を含む月や週のカレンダーの表示を行わなければ、カレンダーを用いて要請に気づくことはない。そして、招集される側からすると、アポイントメントの要請を何時受信するかを予測することは困難で、また、その要請の日付が何時であるかを予測することも困難であるため、日常的な自分のスケジュールの確認作業とは別に、要請がないことを定期的に確認するなどの作業が必要となってしまう。
【0007】
また、特許文献2では、合計スケジュールはオーナーによってすでに確定された予定であるため、元々の日程の調整は別途電子メールや電話等で行わなければならず、従って、この従来例では、日程の調整と日常的な自分のスケジュールの確認作業とは別に行わなければならない。特許文献1では、アポイントメントの要請に対して返信したときに予定が確定する仕組みであるため、複数の候補日を用いたアポイントメントの調整をシステム内で行うことができない。スケジュールの管理としては、複数の候補日が提案された要請が複数ある場合が複雑であり、このようなアポイントメントについて電子メール等を用いて日程調整するのは極めて煩雑な作業となる。
【0008】
そして、候補日が複数ある要請と、候補日が一つである要請とが混在するような状況では、最終的にどの日付にどの予定が入ったかを管理するためには慎重で精緻な作業が必要となり、特に、コンピューターの使い方になれていないユーザーにとっては、負担の大きい作業となっていた。一方、特許文献1や2のように、グループ共通のスケジュールを個人のスケジュールと一体的に管理できるシステムでは、そのグループ内にコンピューターの使い方になれないユーザーがおり、システムに予定を確実に入力してもらえないと、スケジュール情報の共有による生産性向上の阻害要因となってしまう。
【0009】
【発明の目的】
本発明は、スケジュールの管理に関して、コンピューターの使い方に慣れていないユーザーがグループに属していても、当該グループのスケジュール情報の共有による生産性向上を図ることができ、また、コンピューターを使い慣れたユーザーにとっても初心者向きのソフトウエアにあるような煩雑さを感じることのないスケジュール管理支援システムを提供することを、その目的とする。
【0010】
本発明はまた、単一のアポイントメントの要請に複数の候補日が含まれており、最終的な候補日の選定をオーナーが行うようなアポイントメントの調整をもシステム内で実現することのできるスケジュール管理支援システムを提供することを、その目的とする。
【0011】
【課題を解決するための手段】
本発明の発明者は、スケジュール管理用のソフトウエアは、確定した個人の予定を入力しておき、これを週単位や月単位で確認する、という使い方が初心者についても熟練者についても基本的且つ一般的であり、このスケジュールの確認作業は初心者も熟練者も日常的に行っていることに着目した。そして、この日常的なスケジュールの確認作業中に、アポイントメントの要請や候補日の確定などをユーザーに知らせることができれば、初心者に優しく、熟練者には手間いらずとなるシステムを提供できる、との着想を得た。
【0012】
そこで、請求項1に係る本発明では、複数のユーザーによってそれぞれ使用される端末とネットワークを介した各種データの送受信を処理するサーバーと、このサーバーに併設され前記ユーザーの予定に関するデータを管理するデータベースとを備えている。そして、データベースが、ユーザーに関するデータを格納するユーザーテーブルと、前記各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する予定関連テーブルとを備えている。
さらに、サーバーが、要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索し、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述して、当該期間内の日付のカレンダーフィールドを有するカレンダーテーブルを生成するカレンダー画面制御部とを備えている。
しかも、このカレンダー画面制御部が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能を備えている。これにより、前述した課題を解決する。
【0013】
カレンダー画面制御部は、月表示、週表示等の表示指定に応じて、通常予定データと要請データとをカレンダーフィールドに記述し、表示指定による期間のカレンダーテーブルを生成する。そして、要請表示制御機能は、カレンダーテーブル外の要請表示エリアに要請データを記述する。従って、表示指定の期間と無関係に、必ず要請データがカレンダー画面に表示される。このため、カレンダー画面で表示させる期間外が予定日時である要請データの存在をユーザーに通知することができる。また、日常作業として確認すべき期間内については、要請データが通常予定データを併せてカレンダーフィールド内に表示される。このため、日常的なスケジュールの確認作業中にて、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面にて確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
【0014】
【発明の実施の形態】
次に、本発明の実施の形態を説明する。
【0015】
図1は、本実施形態でのアポイントメント調整支援システムの構成例を示すブロック図であり、図2は本実施形態で使用するデータ構造の一例を示す説明図である。
図1を参照すると、本実施形態によるアポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末1とネットワークを介した各種データの送受信を処理するサーバー10と、このサーバー10に併設され前記ユーザーの予定に関するデータを管理するデータベース2とを備えている。
【0016】
そして、データベース2は、図2に示すように、予定関連テーブル29と、ユーザーテーブル30とを備えている。予定関連テーブル29は、各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する。図2に示す例では、予定関連テーブル29は、要請データ及び返信状態データを格納するアポイントメント予定テーブル32と、確定した通常の予定データを格納する通常予定テーブルとを備える。
【0017】
再度図1を参照すると、サーバー10は、アポイントメント確定処理部12と、カレンダー画面制御部13とを備えている。アポイントメント確定処理部12は、要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換する。この変換処理は、例えば、アポイントメント予定テーブル32に格納された返信状態データから通常予定データを生成し、通常予定テーブル34に格納する処理でもよい。この場合、確定した要請データ及び返信状態データはアポイントメント予定テーブルから削除する。
【0018】
カレンダー画面制御部13は、カレンダー画面13a中に、表示指定13bに応じてスケジュールを表示するカレンダーテーブル13dを生成する。具体的には、カレンダー画面制御部13は、端末1から送信されるカレンダー画面13aの表示指令及び表示指定13b(個人月、グループ週等)を受信したときに、まず、当該表示指定13bに応じた期間(月、週、日等)について前記予定関連テーブル29に格納された前記要請データ及び前記通常予定データを検索する。カレンダー画面制御部13は、続けて、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールド13eに記述し、当該期間内の日付のカレンダーフィールド13eを有するカレンダーテーブル13dを生成する。
【0019】
本実施形態では特に、このカレンダー画面制御部13が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリア(図3に示す例では、符号13f,13g,13h,13i及び13jで示す領域)に前記要請データを記述する要請表示制御機能18を備えている。カレンダー画面制御部13が、要請データによる未確定の予定を通常予定と同様にカレンダーテーブル13dに表示するため、ユーザーが日常作業として確認すべき期間内については、要請データの有無及び要請されている日付等を通常予定データと一体的に確認することができる。また、要請表示制御機能18が、表示指定の期間と無関係に、必ず要請データをカレンダー画面に表示するため、毎日のスケジュールの確認を例えば週単位で行っているとしても、カレンダー画面13a内の要請データ表示エリアを参照することで、数週間先や1,2ヶ月先の日付を予定とする要請データの受信の有無を日常的な作業中に確認することができる。
【0020】
このため、日常的なスケジュールの確認作業中に、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面13aのみで確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを日常的に簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
【0021】
図3に示すカレンダー画面は、B氏の個人カレンダー画面であり、符号13bで示す表示指定は、個人で、且つ月単位である。B氏は現在3月として、次月である4月のスケジュールを表示している。B氏は、アポイントメントの要請を5つ受信しており、3月24日及び26日,5月22日の要請については、4月中を期間としているカレンダーテーブル13dには表示されない。カレンダー画面制御部13は、4月2日と4月3日の要請データを、カレンダーテーブル13dに表示する。
【0022】
カレンダー画面制御部13は、また、金曜日9:30に毎週繰り返し開催される定例会議や、4月21,22日の出張予定などを通常予定テーブル34から読み出して表示する。要請表示制御機能18は、B氏を招集ユーザーとして指定されたアポイントメントの要請データをアポイントメント予定テーブル32から読み出して、図3に示す例ではカレンダーテーブル13dの図中左側に各要請データに要請データ表示エリアを設定し、各要請データの一部(概要)または全部を表示する。要請表示制御機能18は、カレンダーテーブル13dの期間(ここでは、月単位で、4月)とは無関係に、全ての要請データを表示する。従って、カレンダー画面を用いてスケジュールの確認作業を行うユーザーは、同一の視界に要請データの数や日付が入るため、スケジュールの確認という日常作業中に新たな要請データを簡単に発見することができる。特に、コンピューターの使用に不慣れなユーザーであっても、特別な操作なしに要請データの一覧がカレンダー画面13a内に表示されるため、容易にスケジュール管理及びグループやメンバーに共通するスケジュール(アポイントメント)を電子的に管理することができる。従って、このアポイントメントの調整やスケジュールの共有に関するコンピュータ・リテラシーの研修等が不要である。
【0023】
再度図1を参照すると、カレンダー画面制御部13は、予定関連テーブル29から読み出した要請データが複数ある場合には、当該要請データの1以上の項目を使用して、当該複数の要請データを並べ替える要請データソート機能19を備えている。要請データソート機能19は、好ましくは、要請データが複数ある場合には、当該当該要請データの予定日時データを使用して、現在から未来に向けた順序に従って、当該複数の要請データを並べ替える。図3に示す例では、要請データを受信した順序ではなく、要請データの予定日時が現在に近い順序で図3中上部から下部へと並べられている。一般的に、スケジュールは現在に近い日付の予定から確認するものであるため、この場合、要請データソート機能19は、要請された順序ではなく、現在から未来に向けた順序に従って、当該複数の要請データを並べ替える。この要請データソート機能19により、ユーザーは自然な順序で要請データの確認をすることができる。一つの要請データに複数の候補がある場合には、要請データの1以上の項目として、オーナーによって第1候補とされた日付を用いるようにしても良い。また、日時の場合であっても、午前、午後、夕方以降などの時間帯をソートの第1のキーとして、その後に日付でソートすることで、夕方以降のアポイントメント要請に対する返信を後回しなどの使い方をすることもできる。また、招集ユーザーが、企業でフレックスタイムを採用する場合には、招集ユーザーは、自分の出社時間内と、出社時間外の予定とで要請データの扱いを分けるために、定義した時間帯を要請データのソートの第1のキーとしても良い。
また、要請データの1以上の項目としては、ユーザーIDや、ユーザーIDによって特定できる役職等を採用し、要請データの並べ替えを行うようにしても良い。オーナーのユーザーID毎に要請データを並べ替えると、同様のアポイントメントが同一のオーナーから要請されることが多いため、アポイントメントの内容、種類で並べ替えることができる。
例えば、図3に示す例では、ユーザーIDで要請データのソートを行うと、ユーザーIDがA氏、C氏、F氏の順であると、符号で、13f,13h,13g,13i,13jとの順序で図中上から下に表示される。すると、招集ユーザーは、例えば、C氏からの3月26日と4月3日の要請が、同じQ社に関することを発見しやすい。
役職等を使用する場合には、例えば、部長、課長等がある場合には、候補日にかかわらず、オーナーの役職の階位を第1のソートのキーとして、第2のソートのキーをユーザーIDとして、第3のソートのキーを日時としても良い。この場合、ユーザーテーブル等に役職を指定するコードを格納するか、または、ユーザーの所属を管理する部門テーブルなどで役職の階位等を特定できるコードを使用すると良い。また、単に、ユーザーIDの数値を階位に従って定めるようにしてもよい。
後述するプロジェクトの関係では、請データにプロジェクトIDを含め、プロジェクトのリーダーであるか否かや、プロジェクトのID毎のソートとしても良い。
【0024】
また、カレンダー画面13は、要請データが複数の候補日を有する場合に、どのようにカレンダー画面に表示するかについて、下記の機能を備える。アポイントメント要請の量や、予定の量などに応じて、ユーザーか下記機能を選択して使用する。
第1に、好ましくは、カレンダー画面制御部13は、予定関連テーブル29から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、前記オーナーによって第1候補とされた日時を当該要請表示エリアに記述する要請エリア内第1候補表示制御機能20を備える。要請エリアでは要請データの有無を表示すれば当面の確認としては十分であり、且つ、要請データが多数ある場合でも、煩雑さの少ない表示とすることができる。具体的な日程の調整では、カレンダーテーブル13d内については各要請データの全ての候補日を表示する表示指令13bなどの機能を提供することにより、単一の要請データについてどの候補日の都合が良いかどうかの視覚的な判断に寄与できる。
第2に、好ましくは、カレンダー画面制御部13は、予定関連テーブル29から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、一つの要請データについて一つの要請表示エリアを生成し、当該要請表示エリア内に全ての候補日の日時を記述する要請表示エリア内全候補表示制御機能を備えると良い。この例では、一つのアポイントメント毎に、一つの要請表示エリアを生成し、そして、この要請表示エリア内に、全ての候補日の日時を記述する。これにより、アポイントメント要請の数と、各アポイントメントで候補日の調整が必要であるか否かを視覚的に即座に把握することができる。
第3に、好ましくは、カレンダー画面制御部13が、要請データに候補日が複数定義されている場合には、一つの要請データについて一つの要請表示エリアを生成し、予め指定されたユーザーの要請表示エリア表示設定に従って、前記カレンダーフィールド又は前記要請表示エリア内の一方にのみ全ての候補日の日時を表示する機能を備えると良い。この例では、アポイントメントの要請も予定も多いユーザーに、カレンダー画面13aのカレンダー又は要請表示エリアのどちらかで複数の候補日を表示する。従って、複数の候補日という同一の情報を二重に表示することがない。
【0025】
要請データを受信すると、招集ユーザーは参加の有無等の返信データを作成する。この例では、サーバー10が、調整制御部16を備える。調整制御部16は、アポイントメントへの参加を要請された招集ユーザーによって使用される端末1からアポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成する。本実施形態では、この調整画面の表示指令と関係して、カレンダー画面制御部13が、前記要請データ毎の要請表示エリア13f,13g等を、前記調整画面の表示指令を当該端末から送信する表示指令ボタンに設定する要請表示エリアボタン化制御機能21を備える。すなわち、要請表示エリアボタン化制御機能21は、例えば図3に示すC氏より4月3日Q社訪問という要請データの一部を表示したテキストを、実行ボタンやリンクとして定義し、この要請表示エリアのクリック操作を調整画面の表示指令とする。要請表示エリアボタン化制御機能21を備える例では、返信データの作成のための特別な操作が不要となり、カレンダーによるスケジュールの確認作業との一体的な作業で、要請に対する返信データの作成を促すことができる。
【0026】
次に、予定の種類に応じた表示形式の設定について説明する。本実施形態では、カレンダー画面制御部13が、カレンダーフィールドへの記述の表示形式13cを、前記要請データと前記予定データとで異なる表示形式に設定する予定種類別表記設定機能22を備える。表示形式13cは、図3に示す例では、時刻部分への黒丸や白丸の表示である。また、表示形式13cを、要請データ及び予定データの時間表示等の色分けとしても良い。図3に示す例では、アポイントメント調整中の要請データを赤色、通常予定を黒色、図中金曜日の定例会議等の繰り返し予定を水色としている。
【0027】
アポイントメント確定処理部12が、オーナーによってアポイントメントの日時等が確定された場合には、要請データを通常予定データに変換するため、カレンダー画面制御部13は、ユーザーの日常的なスケジュール確認作業で使用するカレンダーテーブル13dのカレンダーフィールド13e中に、確定した要請データを通常予定として表示する。そして、予定種別表示設定機能22が、予定の種類に応じて表示形式13cを異なるものとするため、日常的なカレンダー画面の閲覧作業中に、調整中から確定への変化を色等の変化によって把握することができる。
【0028】
特に、アポイントメントのオーナーによって何時確定されるのかを招集ユーザーが予測することは困難であるため、確定されたか否かを確認するための特別な操作を必要とすると、確定されるまで何度も当該確定の確認操作を行う必要が生じてしまう。本実施形態による確定を予定の表示形式で通知する仕組みは、日常的なスケジュール確認作業にて、特に確認すべき期間内での予定については、確定したことが一目瞭然となるため、初心者にとっても判りやすく、熟練者にとっても手間いらずの仕組みとすることができる。
【0029】
また、オーナーによって確定処理がなされた時刻が、ユーザーにとってもスケジュールを確認したい時刻であるとは限らないため、ユーザーは、自らがスケジュールを確認する時に、オーナーの確定作業とは非同期に、表示形式13cの変化によって確定されたことを把握することができる。スケジュール管理としては、そのスケジュールがグループの共通のスケジュールであるか、または個人のスケジュールであるかは、必ずしも重要ではなく、確定したスケジュールであるのか、それとも調整中であるかがより重要であり、調整中と確定予定とで表示形式を変更する仕組みは、万人に使い勝手の良いものとなる。
【0030】
また、例えば、カレンダーの表示指定13bを常に週表示とするユーザーであっても、その週以外の要請については要請表示制御機能18によって同一画面内に表示され、一方、確定した予定については、通常予定として日常のスケジュール確認作業で自然に把握することができ、従って、個人の通常予定と、アポイントメントの要請と、アポイントメントの調整後の確定した共通予定とを一体的に自然な作業にて管理することができる。
【0031】
また、カレンダー画面制御部13は、前記予定関連テーブル29から読み出した要請データが当該アポイントメントについて複数の候補日を有する場合には、前記オーナーによって第1候補とされた日時で要請データを前記カレンダーフィールド13eに記述するカレンダー内第1候補表示制御機能23を備えると良い。
この例では、複数の候補日を有する要請データについて、全ての候補日の予定を個別にカレンダーフィールドに表示すると、日常的な作業を鑑みると、同一の用事(アポイントメント,要請データ)が複数の用事であるとの誤解を招くかもしれないため、第1候補の日時についてのみカレンダーフィールド13eに表示する。
【0032】
図3に示す例では、アポイントメントの要請データの受信から確定までの表示形式を赤色で、確定したアポイントメント要請を含む通常データを黒色で表示する。要請データを二種類に分け、アポイントメントの要請が極めて活発な場合には、さらに、要請データへの返信を行った後、確定までの予定について別の表示形式(例えば、緑)としても良い。アポイントメントの調整については、調整制御部16が、アポイントメントへの参加を要請された招集ユーザーによって使用される端末1から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、まず、当該アポイントメントの要請への返信データの入力を各招集ユーザーに促す調整画面を生成する。そして、調整制御部16は、この調整画面に入力される返信データを予定関連テーブル29に格納する。
【0033】
この例では、好適には、カレンダー画面制御部13が、参加返信候補日表示制御機能24を備える。参加返信候補日表示制御機能24は、当該返信データの格納後前記オーナーによる確定前の要請データについては、前記返信データにて参加と返信した全ての候補日について当該要請データを当該候補日のカレンダーフィールドに記述する。すなわち、複数の候補日のうち、参加すると返信した日時については、他の予定との重なり合いを避けなければならない。要請データのカレンダーテーブル13bへの表示を、候補日すべてや、第1候補のみとすると、返信した候補日を確認するための操作が必要となる。参加返信候補日表示制御機能24を備える例では、自分が参加するとして返信した日付について要請データをカレンダーテーブル13bへ表示する。
【0034】
この例では、複数の候補日を有する要請データの受信と、カレンダーテーブル13bへの表示との関係は、まず、受信時には第1候補の日付のみを赤色で表示する。続いて、調整画面を用いて候補日への参加又は不参加を表明した場合には、参加を表明した候補日について、緑色で表示する。続いて、オーナーによってアポイントメントの確定がなされると、アポイントメント確定処理部12によって要請データが通常予定データへと変換されるため、緑色で表示された予定が消え、黒色となる。この例では、調整画面にて全ての候補日について不参加を表明した場合には、カレンダー画面へは当該要請データは表示されなくなる。
一方、第1候補のみをカレンダーフィールドに表示したい場合には、カレンダー内第1候補表示制御機能が、当該返信データの格納後前記オーナーによる確定前の要請データについては、前記返信データにて参加と返信した候補日のうち当該招集ユーザーによって第1候補とされた日時にのみ要請データを前記カレンダーフィールドに記述する機能を備えると良い。この例では、要請データの受信時には、オーナーによって指定された第1候補(候補日順位が“1”)の日時にのみ要請データを赤色で表示する。続いて、調整画面を用いて候補日への参加又は不参加を表明した場合には、参加を表明した候補日のうち、招集ユーザーによって第1候補とされた日時にのみ要請データを緑色で表示する。その後の確定は上記と同様である。招集ユーザーによって第1候補とされる候補日の特定は、例えば、招集ユーザーが参加を表明した候補日のうち、オーナーによって指定された候補日順位の高い候補日としても良い。
【0035】
図4は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。本実施形態によるアポイントメント調整支援処理は、参加の要請の作成及び通知をする要請制御工程(A1,B1等)と、アポイントメントの出欠や候補日選定を調整する調整制御工程(B3,B4等)と、アポイントメントを確定する確定工程(A5,B5等)とを備える。
【0036】
要請制御工程では、まず、前記データベースへ接続し、前記オーナーによって使用される端末と通信して、アポイントメントの要請に関する要請データの入力を促す(ステップA1)。そして、要請制御工程では、オーナーによって要請データが入力されると、この入力される要請データを当該アポイントメントに招集された招集ユーザーによって使用される端末へ送信する(ステップB1,B2)。この要請データの通知は、本実施形態では、カレンダー画面13aへの表示である。さらに、電子メールによる通知を付加しても良い。カレンダー画面13aへの表示は、カレンダーフィールド13eへの要請データの表示と、カレンダー画面の要請表示エリアへの表示とがある。カレンダー画面13aを使用する例では、オーナーの個人カレンダーにも当該要請データを表示する。
【0037】
調整制御工程では、まず、データベース2と接続し、そして、要請データが送信された招集ユーザーによって使用される端末と通信して、前記要請データによるアポイントメントの要請への出欠等の返信データの入力を促す(ステップB3)。このとき、ステップB3は、アポイントメント予定テーブル32を参照して、全ての招集ユーザーによって使用される端末1に、他の全招集ユーザーの返信状態データを送信すると良い(ステップB4)。招集ユーザーの返信状態は、オーナーによって使用される端末でも逐次参照できるようにする(ステップA3)。
【0038】
調整制御工程では、続いて、オーナーによって使用される端末1と通信して、前記アポイントメント予定テーブル32に格納された返信状態データを当該端末1に表示する(ステップA3)。続いて、当該オーナーにアポイントメントの強制調整操作を促し、そして、未返信の招集ユーザーや、不参加と返信した招集ユーザーの出欠について、オーナーが強制的に参加へと強制調整した場合には、当該強制調整操作のなされた返信状態データを最新の返信状態データとして管理する(ステップA4)。
【0039】
確定制御工程では、オーナーによって使用される端末と通信して、前記返信状態データに対して、当該オーナーによってアポイントメントの確定操作がなされた場合には、当該確定された返信状態データを確定予定データとして管理する(ステップA5)。すなわち、要請データ及び返信状態データを通常予定データに変換する。確定制御工程は、さらに、確定予定データを、全ての招集ユーザーに通知する(ステップB5)。そして、参加が確定した招集ユーザーのカレンダー画面13aに確定した予定を通常予定として表示する(ステップB6)。また、オーナーの個人カレンダーにも通常予定として表示する(ステップA6)。
【0040】
図1に示す構成や、図4に示す処理工程は、サーバーのCPUが所定のプログラムを実行することで実現することができる。本実施形態によるシステムのCPU(図示せず)は、所定のプログラム(指令)に従って各種の演算を行う。CPUは、各種の処理要求に従って、データベース2を駆動して、各種のページ(画面)の生成や送受信などを実行し、その実行結果を端末1に送信する。CPUがアポイントメント調整支援用のプログラムを実行することで、システムは、調整データの生成や、入力される返信データの管理等を処理する。
【0041】
<実施例>
図5は、本実施例の構成例を示すブロック図であり、図6は、本実施例でのデータ構造の一例を示す説明図である。図6に示す各テーブルのフィールド名の一例を図7に示す。本実施例では、実施例では、Webサーバーと、HTML等のマークアップランゲージで記述された画面(ページ)を表示するブラウザを備えた端末とを使用する例を開示する。
【0042】
本実施例では、アポイントメント調整支援システムは、複数のユーザーによってそれぞれ使用される端末1とネットワークを介した各種データの送受信を処理するサーバー(Webサーバー)10と、このサーバー10に併設され前記ユーザーの予定に関するデータを管理するデータベース2とを備えている。そして、データベース2は、図6及び図7に示すように、ユーザーテーブル30と、アポイントメント予定テーブル32と、通常予定テーブル34と、予定メインテーブル36とを備える。本実施例では、図6に示すように、通常予定テーブル34と、アポイントメント予定テーブル32とを、予定メインテーブル36の予定種類コードによって使い分けている。
【0043】
ユーザーテーブル30は、前記ユーザーを識別するユーザーID毎に当該ユーザーの氏名であるユーザー名データを格納する。
予定メインテーブル36は、予定を識別する予定ID毎に、前記ユーザーIDと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データと、アポイントメント等で予定する場所である予定場所データとを格納する。
通常予定テーブル34は、前記予定ID毎に、予定開始日時データと、予定終了日時データとを格納する。
アポイントメント予定テーブル32は、候補日順位毎の前記予定ID毎に、当該予定IDのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーIDと、当該オーナーと招集ユーザーとを識別すると共に当該招集ユーザーの順序を指定するアポイントメントユーザー順位と、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納する。
予定IDは、オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合には、候補日順位毎に個別のIDとすると良い。また、アポイントメントの調整によって確定した予定については、単一の予定IDとし、予定内容データや、予定場所データや、予定開始日時や、予定終了日時については、各ユーザーで共通のデータを使用すると良い。この場合、確定したアポイントメントの予定については、各ユーザーは個別の編集を行うことはできない。また、予定IDをユーザー毎として、確定したアポイントメントの予定を各ユーザーが編集できるようにしても良い。
【0044】
図7に各テーブル30,32,34,36の各フィールドの内容を例示する。図7に示すように、予定の種類を示す予定種類コードは、確定している通常予定を“0”、アポイントメントの調整中であるアポイントメント予定を“1”、通常予定のうち毎週同時刻等の繰り返し予定を“2”としている。アポイントメントユーザー順位は、オーナーを“0”とし、招集ユーザーは“1”から順に付番する。アポイントメント候補日順位は、アポイントメントの候補日が複数ある場合に、これを識別する番号となる。本実施例では、出欠フラグは二種類のみとし、参加を“1”、不参加を“0”とし、返信保留を示すデータ構造はない。従って、出欠についてはフラグとしている。
【0045】
再度図5を参照すると、サーバーは、要請作成画面生成部50と、要請データ格納制御部52と、調整画面生成部56と、返信データ格納制御部58と、確定処理制御部60と、カレンダー画面制御部51とを備える。本実施例による処理は、Webサーバーを用いて、特徴的な画面を使用して、図4に示すアポイントメント調整支援処理をより詳細に開示するものである。本実施例では、「画面」は、端末1のブラウザ等で表示されるHTML等のマークアップ言語によって記載され、端末1のユーザーによって入力される入力フィールドやチェックボックスやポップアップメニューなどの選択肢の定義を含むファイルである。
【0046】
要請作成画面生成部50は、オーナーによって使用される端末1からアポイントメントの要請を作成するための要請作成画面42の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促すための要請作成画面42(例えば、図9に示す画面)を生成する。図4に示す例では、要請作成画面生成部50は、ステップA1の処理を行う。
【0047】
要請データ格納制御部52は、まず、要請作成画面が生成されたときに、前記オーナーによって使用される端末へ当該要請作成画面42を送信する。そして、当要請データ格納制御部52は、オーナーによって当該要請作成画面に入力される要請データを受信する。この制御部52は、さらに、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納し、一方、要請作成画面42のその他の各フィールドの内容を前記アポイントメント予定テーブルに格納する。要請データ格納制御部52は、例えば、図13に示すフローチャートを実行する。図4に示す例では、要請データ格納制御部は、ステップA1の処理を行う。すなわち、本実施例では、図13に示すフローチャートはステップA1の詳細処理である。
【0048】
カレンダー画面制御部51は、端末1から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、前記予定メインテーブルに格納された予定種類コードに応じて前記アポイントメント予定テーブル32に格納された要請データ及び前記通常予定テーブル34に格納された予定データとを当該期間を日毎に区切った各カレンダーフィールドに記述する。これにより、カレンダー画面制御部41は、ステップB1及び/又はB2の処理を行う。要請データを招集ユーザーに通知する。カレンダー画面制御部51は、また、サーバー10が、要請データの内容または要請データを送信したことを招集ユーザーに知らせる電子メールの送信を制御する要請データ通知制御部54を備えるようにしてもよい。
【0049】
調整画面生成部56は、招集ユーザーによって使用される端末から、アポイントメントの要請に対する返信を作成するための調整画面46の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面46(例えば、図11に示す画面)を生成する。図4に示す例では、調整画面生成部56は、ステップB3の処理を行う。
【0050】
好ましい例では、調整画面生成部56が、他ユーザー出欠参照制御機能62を備えるようにしてもよい。この機能62は、第1実施形態等の機能18と同様の作用効果を有する。すなわち、本実施例では、他ユーザー出欠参照制御機能62は、招集ユーザーによって使用される端末1から調整画面46の表示指令を受信したときに、予定IDをキーとしてアポイントメント予定テーブル32を参照する。そして、アポイントメント予定テーブル32から、他の招集ユーザーのユーザー名、出欠フラグ及び返信コメント読み出して、前記調整画面46にて合成する。図4に示す例では、他ユーザー出欠参照制御機能62は、ステップB4の処理を行う。
【0051】
返信データ格納制御部58は、まず、前記調整画面46が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面46を送信する。制御部58は、続いて、当該招集ユーザーによって当該調整画面に入力される返信データを受信する。さらに、制御部58は、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する。図4に示す例では、返信データ格納制御部58は、ステップB3の処理を行う。
【0052】
本実施例では、好適には、調整画面生成部56が、確定用調整画面生成機能64を備える。確定用調整画面生成機能64は、オーナーによって使用される端末1から、確定用調整画面48の表示指令を受信した場合には、前記予定IDをキーとしてアポイントメント予定テーブルを参照して、全ての招集ユーザーのユーザー名と、返信データが格納された招集ユーザーについての出欠フラグの内容及び返信コメントを抽出する。確定用調整画面生成機能64は、続いて、各招集ユーザーの出欠に関して強制参加チェックボックスを付加した確定用調整画面48(例えば、図12に示す画面)を生成する。図4に示す例では、確定用調整画面生成機能64は、ステップA3の処理を行う。
【0053】
本実施例では特に、カレンダー画面制御部51は、表示指定による期間と無関係に、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述させる要請表示制御機能70と、カレンダーフィールドへの記述の表示形式を、前記予定メインテーブルに格納された予定種別コード毎に異なる表示形式に設定する予定種類別表記設定機能71とを備える。要請表示制御機能70は、図4のステップB2に示す処理を実行する。予定種別表記設定機能71は、図4に示すステップB5の役割を果たす。
【0054】
そして、調整画面生成部56は、強制調整制御機能66を備えるとよい。強制調整制御機能66は、前記オーナーによって、前記確定用調整画面48の前記強制参加チェックボックス49がチェックされた招集ユーザーの出欠について、これを強制的に参加として確定する。強制調整制御機能66は、当該招集ユーザーの通常予定テーブル34に当該オーナーによって確定された候補日順位の開始日時及び終了日時を格納する。図4に示す例では、強制調整制御機能66は、ステップA4の処理を行う。
【0055】
確定処理制御部60は、オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブル32を参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する。確定処理制御部60は、例えば、図14に示すフローチャートを実行する。図4に示す例では、確定処理制御部60は、ステップA5の処理を行う。すなわち、図14に示すフローチャートは、本実施例でのステップA5の詳細処理である。
【0056】
次に、画面を参照して具体的な使い方を説明する。ここでは、次の状況設定と、登場人物とを設定する。オフィス家具大手K社の販売課長、阿部氏は、顧客であるQ社の移転に伴うオフィス家具購入の案件で家具配置プランの提案を行っていた。プロジェクトのリーダー阿部は、メンバーのプレゼンテーションの日程を調整する立場にある。このプロジェクトには、メンバーとして営業マン海老沢、設計担当者山田、和田及び鈴木が属している。
【0057】
図8は、ユーザー予定データ表示画面の一例を示す説明図である。図8から図12に示す画面の例は、パーソナルコンピュータ等でブラウザー・アプリケーションを使用してサーバー10から送信されるデータを画面として表示している状態を示す。図中の下線はリンクであり、他の画面への表示指令となる。
【0058】
カレンダー画面制御部51は、アポイントメントのオーナー向けに、プロジェクトや部署に属するユーザーの登録されている予定を表示するユーザー予定画面40(実際には、カレンダー画面44)を生成する。阿部氏は、図8に示すユーザー予定画面を表示し、メンバーの空きスケジュールを確認する。すると、木曜日は海老沢氏、山田氏及び和田氏に先約があり、金曜日には全てのメンバーに予定がない。オーナーは、一応両日を候補日として提案することとする。オーナーである阿部氏は、図8のアポイントメントと表記されたアポイントメント・リンク40aに対してクリック等の操作をする。アポイントメント・リンク40aへの操作は、要請作成画面の表示指令である。
【0059】
また、阿部氏は、図8の符号40bで示す要請表示エリアに、山田氏から1月21日を予定日とするアポイントメントの要請が送信されていることを発見する。これは要請データであり、図8に示す例では当該予定日は現に表示しているカレンダー画面の期間内であるため、カレンダー画面制御部51は、符号40eで示す表示形式(黒丸)で当該要請データをカレンダーフィールド40hに表示する。
【0060】
図9に、要請作成画面42の一例を示す。阿部氏は、要請作成画面42の内容フィールド42aにアポイントメントの内容を「Q社訪問」と入力し、同様に場所フィールド42bに「横浜」と場所を入力する。続けて、日付・時間エリア42cのGUI部品を用いて、候補日と時間とを入力する。阿部氏は、コンボボックスとなっている日時フィールドを使用して日時を特定する。このとき、第1候補を金曜日(24日)、第2候補を木曜日(23日)とする。また、招集ユーザー特定用エリア74を使用して、招集したいユーザーを選択する。
【0061】
再度図5を参照すると、データベース2が、図6等に示すテーブルの他、ユーザーの一部又は全部が参加するプロジェクトを識別するプロジェクトID毎に、当該プロジェクトのメンバーとなるユーザーのユーザーIDと、当該プロジェクトに属するコンテンツとを格納するプロジェクト関連テーブル38と、ユーザーの所属部門を識別する部門ID毎に当該部門に所属するユーザーIDを格納する部門テーブル31とを備えている。
【0062】
そして、サーバー10は、プロジェクト関連テーブル38を参照して、当該プロジェクトのメンバーによって使用される端末と通信して、当該プロジェクトのコンテンツの参照、編集及び登録を促すプロジェクト画面90を管理するプロジェクト活動支援制御部72を備えている。
【0063】
そして、要請作成画面42は、図9に示すように、当該アポイントメントに招集する招集ユーザーの候補となる候補者リストを抽出すると共に、当該候補者リストからの招集ユーザーの選択を促す招集ユーザー特定用エリア74を備えている。そして、招集ユーザー特定用エリア74に、候補対象者一覧を表示する候補者リストボックス75と、この候補者リストボックス75から選択された要素であるユーザー名の一覧を表示する招集ユーザーリストボックス76と、候補者リストのキーとなるプロジェクト名又は部門名の選択を促すポップアップリスト77とを備えている。オーナーがポップアップリスト77を使用してプロジェクト名又は部門名を特定すると、要請作成画面生成部50は、部門テーブル31又はプロジェクト関連テーブル38を参照して、部門に属するユーザー名の一覧や、プロジェクトのメンバー一覧を抽出し、候補者リストボックス75に表示する。オーナーは、この候補者リストボックス75に表示されたユーザー名を選択して、招集ユーザーリストボックス76に追加する。
【0064】
オーナーは、日付・時間や招集したいユーザーの特定が完了すると、要請するボタン42eを押し下し、要請データをオーナーの端末1からサーバー10へ送信する。また、阿部氏は、山田氏からのアポイントメント要請を受諾し、参加を表明した。
【0065】
図10は、要請表示エリア44a,44bを有するカレンダー画面44の一例を示す説明図である。招集ユーザーである山田氏は、まず、阿部氏からの返信データを受信したため、直ちに1月21日の予定を確定した。アポイントメントを確定して再表示すると、図10の符号44dで示すように、表示形式が通常予定となり、ここでは、黒丸が取れた。
【0066】
そして、自分のカレンダー画面44を開くと、要請表示エリア44bに阿部氏からの要請が表示されている。このため、自分のスケジュール確認という普段の活動の中でアポイントメント要請に気づくことができる。そして、カレンダーのうち24日金に、黒丸が付された状態で予定が記入されている。これは、要請データの招集ユーザーへの通知であり、このアポイントメントについては招集ユーザーである山田氏は、個人のカレンダー画面44を開くだけで、要請表示エリア44bに要請データの概要が表示され、且つ、自分の予定としてカレンダーに表示される。すなわち、カレンダー画面制御部51は、各個人のカレンダーにアポイントメントの要請データをスケジュールとして表示することで、要請データの通知を行う。要請表示エリア44bは、ボタンとなっており、この領域をクリックする操作は、調整画面46の表示指令をサーバー10に送信する。
この図10に示す例では、要請データに複数の候補日が含まれているため、まず、要請表示エリア内全候補表示制御機能が、要請表示エリア44bに、第1候補の候補日である1月24日と、第2候補の候補日である1月23日とを記述する。そして、図10に示す例では、カレンダー内第1候補表示制御機能23が、2つの候補日の内、オーナーによって第1候補と指定された1月24日のカレンダーフィールドにのみ要請データを表示し、第2候補である1月23日のカレンダーフィールドには要請データを表示していない。
【0067】
また、要請データ通知制御部54は、電子メールにてリアルタイムに要請データを送信するようにしてもよい。山田氏、返答を入力するためにひとまず返答画面(調整画面46)を開いてみた。
【0068】
図11は、招集ユーザー用の調整画面46の一例を示す説明図であり、ここでは招集ユーザーである山田氏用の調整画面である。山田氏は、海老沢氏と鈴木氏はすでに木曜日に×(不参加)、金曜日に○(参加)と回答しており、和田氏は未回答であることを把握する。山田氏は、この返信状態データでは、第1候補での開催だろうと考え、第1候補については○(参加)とし、第2候補については×(不参加)とした。
【0069】
この状態で阿部氏が確定用調整画面48を開くと、図12に示す画面の状態となる。図12は、オーナー用の調整画面(確定調整画面48)の一例を示す説明図である。阿部氏は、未回答の和田氏は外出中で返信を書けないのであろうと考え、本人の了解を得ることなく強制的に参加を命ずることとした。このため、阿部氏は、調整画面46の和田氏の強制チェックボックス49をチェックし、第1候補の確定ボタン49aを押した。この瞬間、全員に金曜日にプレゼンが決定した旨メールが発信され、正式なスケジュール(通常予定)として全メンバーのカレンダーに記入された。すなわち、招集ユーザー全員のスケジュールを同時に確定することができる(同時確定制御機能67)。
【0070】
図13は、要請データ格納制御部による要請データの格納処理の一例を示すフローチャートである。図9に示す必須入力項目が入力され、オーナーによって要請するボタン42eがクリックされると、端末1のブラウザは、入力された要請データにログインユーザーのユーザーID(ここでは、オーナー)を付加して、当該要請データをサーバー10に送信する。サーバー10は、要請データを受信すると、図13に示す処理を開始する。すなわち、要請データ格納制御部52は、まず、新しい要請データに対して、新しい予定IDを取得する(ステップS1)。ここでは、要請データの候補日順位毎に予定IDを取得する。続いて、アポイントメント候補日順位を“1”とする(ステップS2)。さらに、オーナーのアポイントメントユーザー順位を“0”とする。
【0071】
続いて、アポイントメントユーザー順位を付するため、x=1とし(ステップS4)、招集ユーザーのアポイントメントユーザー順位をxとする(ステップS5)。これを図9に示す「招集したいユーザー」全てについて完了するまで(ステップS6)、xの値をインクリメントして、アポイントメントユーザー順位を設定する。
【0072】
アポイントメントユーザー順位を設定すると、続いて、図6に示すデータ構造のアポイントメント予定テーブル32に、予定ID、ユーザーID、アポイントメントユーザー順位、候補日順位、予定開始日時、予定終了日時を格納する(ステップS8)。続けて、予定メインテーブル36に予定IDと、全ユーザーのユーザーIDと、予定種類コードと、予定内容データ(Q社訪問)と、予定場所データ(横浜)とを格納する。予定種類コードは、ここではアポイントメント調整中の予定であることを示すコード“1”を格納する。これにより、予定IDをキーとして、第1候補日順位についての要請データを格納した。各種の制御部は、予定IDをキーとして予定メインテーブル36を参照すると、当該予定IDで識別される予定が通常予定であるのか、それともアポイントメント調整中の予定であるかを特定することができる。
【0073】
続けて、次の候補日順位のデータがあるか否かを確認し(ステップS10)、ここでは、第2候補日順位のデータがあるため、ステップS1に戻り、第2候補日順位用の予定IDを取得する。第2候補日順位についても同様に要請データをアポイントメント調整中の予定データとして格納し、第3候補日順位のデータはないため、処理を終了する。
【0074】
図14は、確定処理制御部60によるアポイントメントの確定処理の一例を示すフローチャートである。端末1のブラウザは、図12に示す最新の返信状態データの表示中に確定するボタン49aがクリックされると、この確定操作によるイベントはサーバーに送信する。また、ブラウザは、強制チェックボックス49のチェックの有無もサーバー10に送信する。確定するボタン49aは予定IDと、候補日順位と関係しているため、サーバー10は、端末1から、少なくとも、予定IDと、候補日順位と、強制チェックボックス49のオン/オフとを受信する。
【0075】
サーバー10では、確定処理制御部60が、この確定操作を受信したときに、図14に示す処理を開始する。まず、確定された候補日順位以外の順位の予定IDに関するレコードを全て削除する(ステップS11)。
【0076】
続いて、確定された候補日順位の予定IDからアポイントメント予定テーブル32を検索して予定開始日時と予定終了日時とを読み出し、当該予定IDと、予定開始日時と、予定終了日時とを新たに通常予定テーブル34へ格納する(ステップS12)。すなわち、確定した予定に関するデータを、アポイントメント予定テーブル32から通常予定テーブルへ複写する。
【0077】
さらに、当該予定IDをキーとして、アポイントメント予定テーブル32から招集ユーザーの出欠を順に確認する(ステップS13)。招集ユーザーの探索順序は、アポイントメントユーザー順位の順序とし、ここでは、まず、順位“0”のオーナーである阿部氏について確認する。阿部氏の出欠フラグは“1”であるため、当該予定IDと阿部氏のユーザーIDとで予定メインテーブルを検索し、その予定種類コードを“1”から“0”に変更する(ステップS15)。すなわち、当該第1候補のアポイントメントを阿部氏の通常予定とする。そして、通常予定とした後に、該当するユーザーIDに関するアポイントメント予定テーブル32のレコードを削除する。ステップS16,S13にて次に順位“1”の海老沢氏が特定され、同様に処理する。
【0078】
和田氏については、ステップS14にて、出欠フラグが格納されておらず、“1”ではないため、ステップS17に進む。ステップS17では、強制チェックボックスがオンであるか否かを確認し、強制チェックボックスがオンであるため、ステップS15にて同様に予定種類コードを通常予定へ更新する。予定種類コードが通常予定となると、各ユーザーの各カレンダー画面44にて自分のスケジュールとして表示される。
【0079】
図15は、カレンダーへの予定表示処理の一例を示すフローチャートである。図8に示すカレンダー画面44は、図中左上から、表示指定エリア40cと、月/週指定エリア40dと、要請表示エリア40bとを備え、さらに、プロジェクト/部署選択コンボボックス40fと、カレンダーテーブル40gと、カレンダーフィールド40hとを備えている。本実施例では、表示指定として、個人の月表示、部署の週表示及び日表示、プロジェクトの週表示及び日表示とを有する。図8に示す例では、表示指定はプロジェクトの週表示であり、コンボボックス40fによりP社新築ビルプロジェクトというプロジェクトが選択されている。表示する週は、月/週指定エリア40dの操作に応じて、2003年1月19日からである。
【0080】
サーバー10のカレンダー画面制御部51は、端末1からカレンダー画面の表示指令を受信したときに、図8等に示すカレンダー画面の表示処理を行う。図15に示すように、カレンダー画面制御部51は、まず、ユーザーIDを参照して、設定情報等を読み出し、カレンダー画面の定型情報を生成する(ステップS21)。ここでは、エリア40c,40dなどである。続いて、カレンダー画面制御部51は、表示指定に応じてカレンダーテーブルを生成する(ステップS22)。週表示であれば、日曜から土曜までの列と、プロジェクトのメンバー数に応じた個数の行とを有する空のカレンダーテーブルを生成する。カレンダーテーブルの各フィールドを、カレンダーフィールドという。
【0081】
続いて、カレンダー画面制御部51は、カレンダーテーブルの各カレンダーフィールドの表示処理を行う。すなわち、図8に示す例ではユーザーID毎に、通常予定テーブル34とアポイントメント予定テーブル32との予定開始日時を参照する。そして、カレンダーテーブル内の過去の日付から順にカレンダーフィールドを特定する(ステップS23)。まず、阿部氏について19日のカレンダーフィールドの特定では、両テーブル32,34に19日の予定が格納されているか否かを探索し(ステップS25)、格納されていないため、全日付完了したか否かを確認して(ステップS30)、完了していないため、処理を20日に移す。
【0082】
20日では、通常予定テーブル34に、「戦略会議」との予定が格納されている。ステップS24でイエスとなるため、予定の種類コード25を参照して、通常予定であるため、予定日時を黒色に設定する。続けて、同日に他の予定がなければ(ステップS29)、ステップS30,S23を介して21日の処理を開始する。21日には、山田氏からのアポイントメント要請があり、アポイントメント予定テーブル32に1月21日13:00との予定開始日時が格納されている。ステップS25では、予定種類がアポイントメント予定であるため、予定日時の文字表示を赤色に設定する。図面では、文字を赤色にする処理に変えて、黒丸40eを付した。
【0083】
図10に示す例では、山田氏のアポイントメント予定テーブル32に、Q社訪問という1つの要請データについて、23日と24日の2つの候補日がある。第1候補のみをカレンダーテーブルに表示する指定の場合には、図15に示す例では、ステップS33は、23日については、アポイントメント予定テーブル32にアポイントメント予定が格納されているが、このアポイントメント予定の候補日順位を参照すると、第2候補であるため、ステップS33にて表示する候補日と判断せず、表示処理を行わない。24日については、ステップS33にて候補日順位を確認し、第1候補であるため、ステップS28にて予定日時を赤色に設定し、表示処理を進める。また、このステップS33にて、アポイントメント予定テーブルの候補日毎の出欠フラグを参照して、参加(フラグが“1”)の候補日のうち、候補日順位の最も高い(最も値の小さい)候補日であるか否かを判定することで、カレンダーに表示する候補日であるかを判定するようにしても良い。
さらに、図8及び図10に示す例では、各ユーザーについて同様に予定を探索する。図15に示す例では、アポイントメント予定と、通常予定とで表示する文字の色を変化させるため、アポイントメントの要請があったことを一見して把握することができる。
【0084】
予定データの読み出し及び色の設定が全て完了すると(ステップS31)、カレンダーテーブルをHTML等のマークアップ記述言語で記述する。
【0085】
さらに、アポイントメント予定テーブル32を参照して、要請表示エリア40bに要請データを要請の日付順に記述する。この要請表示エリアは、調整画面を表示するためのボタンとする。
【0086】
上述したように本実施例では、実施形態と同様の効果を奏するほか、例えば、オーナーによる強制調整の機能と、確定後に表示形式を変更(赤から黒へ)する機能との組み合わせにより、オーナーの強制調整による参加命令が通常の予定と同様に招集ユーザーのカレンダーに表示されるため、強制参加をユーザーに指示するために電話を行ったり、電子メールを送信したりするよりも参加への実効性を高めることができ、且つ、オーナーも強制参加する招集ユーザーもほとんど手間を要さない。また、Web技術を用いて、画面の生成としてアポイントメントの調整及びスケジュール管理を支援するため、電子メールと異なり、双方が作業したいときに作業すれば良い非同期の環境を提供することができる。また、他ユーザー出欠参照制御機能62と、予定種類別表記設定機能71との組み合わせでは、全てのユーザーが、アポイント調整中に他の招集ユーザーの状況を知ることができ、さらに、特定の招集ユーザーにどれだけアポイントメントの要請が来ているかをも知ることができる。従って、一つのアポイントメントの調整のみならず、そのユーザーの業務負荷を鑑みて招集や参加の判断を行うことができる。
【0087】
【発明の効果】
本発明は、その構成によって、カレンダー画面制御部が、月表示、週表示等の表示指定に応じて、通常予定データと要請データとをカレンダーフィールドに記述し、表示指定による期間のカレンダーテーブルを生成する。そして、要請表示制御機能は、カレンダーテーブル外の要請表示エリアに要請データを記述する。従って、表示指定の期間と無関係に、必ず要請データをカレンダー画面に表示することができる。このため、カレンダー画面で表示させる期間外の要請データの存在をユーザーに通知することができる。また、カレンダー画面制御部は、日常作業として確認すべき期間内については、要請データと通常予定データとを併せてカレンダーフィールドに表示する。このため、日常的なスケジュールの確認作業中にて、確認すべき期間内の要請データの内容と、その他の期間についての要請データの有無とをカレンダー画面にて確認することができる。従って、特別な操作を必要とせずに、初心者であっても、期間内の要請データの内容確認と、期間外の要請データの有無とを簡単に把握することができ、また、熟練者にとっても、単にスケジュールや要請の有無が表示されるだけであるため、煩雑さがない。
このように、本発明では、スケジュールの確認という日常的な作業で通常予定データとアポイントメント予定データとを、すなわち、個人の予定データとグループで調整が必要な予定データとの一体的な管理を促すことができる。これにより、スケジュールの管理に関して、コンピューターの使い方に慣れていないユーザーがグループに属していても、当該グループのスケジュール情報の共有による生産性向上を図ることができる。
【図面の簡単な説明】
【図1】図1は、本実施形態でのスケジュール管理支援システムの構成例を示すブロック図である。
【図2】図2は、本実施形態でのデータ構造の一例を示す説明図である。
【図3】図3は、本実施形態で取り扱うカレンダー画面の一例を示す説明図である。
【図4】図4は、本実施形態でのアポイントメント調整支援処理の一例を示すシーケンス図である。
【図5】図5は、本実施例の構成例を示すブロック図である。
【図6】図6は、本実施例でのデータ構造の一例を示す説明図である。
【図7】図7は、本実施例での各テーブルのフィールド名の一例を示す説明図である。
【図8】図8は、ユーザー予定データ表示画面の一例を示す説明図である。
【図9】図9は、要請作成画面の一例を示す説明図である。
【図10】図10は、要請表示エリアを有する個人カレンダー画面の一例を示す説明図である。
【図11】図11は、招集ユーザー用の調整画面の一例を示す説明図である。
【図12】図12は、オーナー用の調整画面(確定画面)の一例を示す説明図である。
【図13】図13は、要請データの格納処理の一例を示すフローチャートである。
【図14】図14は、確定処理の一例を示すフローチャートである。
【図15】図15は、予定表示処理の一例を示すフローチャートである。
【符号の説明】
1 端末
10 サーバー
12 アポイントメント確定処理部
13 カレンダー画面制御部
16 調整制御部
18 要請表示制御機能
19 要請データソート機能
20 要請エリア内第一候補表示制御機能
21 要請表示エリアボタン化制御機能
22 予定種類別表記設定機能
23 カレンダー内第1候補表示制御機能
24 参加返信候補日表示制御機能[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a schedule management support system, and more particularly to a system for supporting a schedule management operation of each user using a server and a terminal.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, companies, universities, etc., confirm the date and time while adjusting the schedule of candidates for participation in appointments for appointments such as meetings, workshops, exhibitions, and trips. The organizer requesting participation (owner) requests participation from the organizer (conventional user), and decides the final date and time by referring to the response from the invited user. To do. The convened user adjusts the schedule according to his / her own schedule and the appointment requested to participate, and manages the schedule using schedule management software, a notebook, and the like.
[0003]
[0004]
[0005]
[Patent Document 1]
JP-A-5-165836
[Patent Document 2]
JP 2000-57217 A
[Patent Document 3]
JP 2002-49729 A
[0006]
[Problems to be solved by the invention]
In each of the above conventional examples, there is a disadvantage that the convening user is difficult to notice that the owner has requested the appointment. In other words, in
[0007]
In
[0008]
In a situation where requests with multiple candidate dates and requests with a single candidate date coexist, careful and elaborate work is required to manage which date finally entered which schedule. It was necessary, especially for users who were not familiar with how to use computers. On the other hand, in systems such as
[0009]
OBJECT OF THE INVENTION
The present invention can improve productivity by sharing schedule information of a group, even if a user who is not familiar with the use of a computer belongs to a group in terms of schedule management. The purpose is to provide a schedule management support system that does not feel as complicated as software for beginners.
[0010]
The present invention also includes a schedule management in which a plurality of candidate dates are included in a request for a single appointment, and the appointment can be adjusted in the system so that the owner selects a final candidate date. The purpose is to provide a support system.
[0011]
[Means for Solving the Problems]
The inventor of the present invention is basically used for both beginners and experts who use a schedule management software in which a confirmed individual schedule is input and confirmed in units of weeks or months. We focused on the fact that both beginners and skilled workers routinely check this schedule. And if you can inform users about appointment requests and confirmation of candidate dates during this daily schedule check, you can provide a system that is easy for beginners and does not require a lot of time for skilled workers. I got an idea.
[0012]
Therefore, in the present invention according to
In addition, when the appointment of the request data is confirmed by the owner, the server converts an appointment confirmation processing unit of the requested data into the normal schedule data, and a calendar screen transmitted from the terminal. When the display command and the display designation are received, the request data and the normal schedule data stored in the schedule related table are searched for the period according to the display designation, and the period is set for each day for the request data and the schedule data. And a calendar screen control unit for generating a calendar table having a calendar field for dates within the period.
In addition, the calendar screen control unit has a request display control function for describing the request data in a request display area outside the calendar table in the calendar screen. This solves the problem described above.
[0013]
The calendar screen control unit describes the normal schedule data and the request data in the calendar field according to the display designation such as month display or week display, and generates a calendar table for the period specified by the display designation. Then, the request display control function describes request data in a request display area outside the calendar table. Therefore, the request data is always displayed on the calendar screen regardless of the display designation period. Therefore, it is possible to notify the user of the existence of request data whose scheduled date and time is outside the period displayed on the calendar screen. In addition, during the period to be confirmed as daily work, the request data is displayed in the calendar field together with the normal schedule data. For this reason, it is possible to confirm on the calendar screen the contents of the request data within the period to be confirmed and the presence or absence of the request data for other periods during the routine schedule confirmation work. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period without requiring any special operation. Since there is only a display of the schedule and the presence / absence of a request, there is no complication.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Next, an embodiment of the present invention will be described.
[0015]
FIG. 1 is a block diagram illustrating a configuration example of an appointment adjustment support system according to the present embodiment, and FIG. 2 is an explanatory diagram illustrating an example of a data structure used in the present embodiment.
Referring to FIG. 1, the appointment adjustment support system according to the present embodiment includes a terminal 10 that is used by a plurality of users and a
[0016]
The
[0017]
Referring again to FIG. 1, the
[0018]
The calendar
[0019]
Particularly in the present embodiment, the calendar
[0020]
For this reason, it is possible to confirm the contents of the request data within the period to be confirmed and the presence / absence of the request data for other periods only on the calendar screen 13a during the routine schedule confirmation operation. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period on a daily basis without requiring special operations. For the user, only the schedule and the presence / absence of the request are simply displayed, and there is no complication.
[0021]
The calendar screen shown in FIG. 3 is Mr. B's personal calendar screen, and the display designation indicated by
[0022]
The calendar
[0023]
Referring to FIG. 1 again, when there are a plurality of request data read from the schedule related table 29, the calendar
Further, as one or more items of the request data, a user ID, a title that can be specified by the user ID, or the like may be adopted, and the request data may be rearranged. If the request data is rearranged for each user ID of the owner, the same appointment is often requested from the same owner, and therefore, it can be rearranged according to the content and type of the appointment.
For example, in the example shown in FIG. 3, when the request data is sorted by the user ID, the user ID is in the order of Mr. A, Mr. C, and Mr. F, and the codes are 13f, 13h, 13g, 13i, and 13j. Are displayed from top to bottom in the figure. Then, the convened user can easily find out, for example, that the request from Mr. C on March 26 and April 3 relates to the same company Q.
When using titles, for example, when there are general managers, section managers, etc., regardless of the candidate date, the rank of the owner's title is used as the first sort key, and the second sort key is used by the user. As the ID, the third sorting key may be the date and time. In this case, it is preferable to store a code for designating a title in the user table or the like, or use a code that can specify the rank of the title in the department table or the like that manages the user's affiliation. Alternatively, the numerical value of the user ID may be determined according to the rank.
In the relationship of the project described later, the project ID may be included in the contract data, and whether or not the project is a leader of the project, or may be sorted for each project ID.
[0024]
In addition, the
First, preferably, when the request data read from the schedule related table 29 has a plurality of candidate dates for the appointment, the calendar
Secondly, preferably, the calendar
Third, preferably, when a plurality of candidate dates are defined in the request data, the calendar
[0025]
When the request data is received, the convened user creates reply data such as presence / absence of participation. In this example, the
[0026]
Next, the setting of the display format according to the schedule type will be described. In the present embodiment, the calendar
[0027]
When the appointment
[0028]
In particular, it is difficult for the calling user to predict when it will be confirmed by the appointment owner, so if you need a special action to check whether it has been confirmed or not, it will It becomes necessary to perform a confirmation operation for confirmation. The mechanism for notifying the confirmation according to the present embodiment in the display format of the schedule is easy to understand even for beginners because it is clear at a glance that the schedule within the period to be confirmed is confirmed in daily schedule confirmation work. It is easy, and it can be a mechanism that does not require any effort even for the skilled person.
[0029]
In addition, since the time when the confirmation process is performed by the owner is not necessarily the time when the user wants to confirm the schedule, when the user confirms the schedule, the display format is asynchronous to the owner's confirmation work. It can be understood that the change is confirmed by the change of 13c. For schedule management, whether the schedule is a group common schedule or an individual schedule is not necessarily important, it is more important whether it is a confirmed schedule or being adjusted, The mechanism for changing the display format between the adjustment and the fixed schedule is convenient for everyone.
[0030]
Further, for example, even if the user always displays the
[0031]
In addition, when the request data read from the schedule related table 29 has a plurality of candidate dates for the appointment, the calendar
In this example, when request data having a plurality of candidate dates is displayed in the calendar field for each candidate date individually, the same task (appointment, request data) is considered to be a plurality of tasks in view of daily work. Therefore, only the date and time of the first candidate is displayed in the calendar field 13e.
[0032]
In the example shown in FIG. 3, the display format from reception of appointment request data to confirmation is displayed in red, and normal data including the confirmed appointment request is displayed in black. If the request data is divided into two types, and the appointment request is very active, a different display format (for example, green) may be used for the schedule until the decision is made after replying to the request data. Regarding the adjustment of the appointment, when the
[0033]
In this example, preferably, the calendar
[0034]
In this example, the relationship between the reception of the request data having a plurality of candidate dates and the display on the calendar table 13b first displays only the date of the first candidate in red when received. Subsequently, when participation or non-participation on the candidate date is announced using the adjustment screen, the candidate date on which participation is announced is displayed in green. Subsequently, when the appointment is confirmed by the owner, the appointment data is converted into normal schedule data by the appointment
On the other hand, when it is desired to display only the first candidate in the calendar field, the first candidate display control function in the calendar selects the request data before the confirmation by the owner after storing the reply data as participation in the reply data. It is preferable to provide a function for describing the request data in the calendar field only on the date and time when the convened user makes the first candidate among the returned candidate dates. In this example, when request data is received, the request data is displayed in red only on the date and time of the first candidate designated by the owner (candidate date rank is “1”). Subsequently, when participation or non-participation is announced on the adjustment screen using the adjustment screen, the request data is displayed in green only on the date and time selected as the first candidate by the calling user among the candidate dates on which participation was announced. . Subsequent determination is the same as described above. The candidate date specified as the first candidate by the convened user may be, for example, a candidate date with a high candidate date rank designated by the owner among the candidate dates that the convened user has announced to participate.
[0035]
FIG. 4 is a sequence diagram illustrating an example of the appointment adjustment support process in the present embodiment. The appointment adjustment support process according to this embodiment includes a request control process (A1, B1, etc.) for creating and notifying a participation request, and an adjustment control process (B3, B4, etc.) for adjusting appointment attendance and candidate date selection. And a confirmation step (A5, B5, etc.) for confirming the appointment.
[0036]
In the request control step, first, the user connects to the database, communicates with the terminal used by the owner, and prompts input of request data regarding the request for the appointment (step A1). In the request control process, when request data is input by the owner, the input request data is transmitted to a terminal used by the convened user convened for the appointment (steps B1 and B2). The notification of the request data is a display on the calendar screen 13a in the present embodiment. Furthermore, notification by electronic mail may be added. The display on the calendar screen 13a includes the display of request data in the calendar field 13e and the display in the request display area of the calendar screen. In the example using the calendar screen 13a, the request data is also displayed on the owner's personal calendar.
[0037]
In the adjustment control process, first, the
[0038]
In the adjustment control step, subsequently, communication with the
[0039]
In the confirmation control step, when the appointment operation is performed by the owner for the reply status data by communicating with the terminal used by the owner, the confirmed reply status data is set as the scheduled decision data. Manage (step A5). That is, the request data and the reply status data are converted into normal schedule data. In the confirmation control step, the confirmation schedule data is further notified to all the convened users (step B5). Then, the confirmed schedule is displayed as a normal schedule on the calendar screen 13a of the convened user who has confirmed participation (step B6). Further, it is also displayed as a normal schedule on the owner's personal calendar (step A6).
[0040]
The configuration shown in FIG. 1 and the processing steps shown in FIG. 4 can be realized by the CPU of the server executing a predetermined program. A CPU (not shown) of the system according to the present embodiment performs various calculations according to a predetermined program (command). The CPU drives the
[0041]
<Example>
FIG. 5 is a block diagram illustrating a configuration example of the present embodiment, and FIG. 6 is an explanatory diagram illustrating an example of a data structure in the present embodiment. An example of the field name of each table shown in FIG. 6 is shown in FIG. In the present embodiment, in the embodiment, an example is disclosed in which a Web server and a terminal including a browser that displays a screen (page) described in a markup language such as HTML are used.
[0042]
In the present embodiment, the appointment adjustment support system includes a terminal (Web server) 10 that processes transmission and reception of various data via a network with a
[0043]
The user table 30 stores user name data that is the name of the user for each user ID that identifies the user.
The schedule main table 36 includes, for each schedule ID for identifying a schedule, the user ID, a schedule type code for identifying the type or state of a schedule such as normal or during appointment adjustment, schedule content data as schedule contents, and appointments. The planned location data that is the planned location is stored.
The normal schedule table 34 stores schedule start date / time data and schedule end date / time data for each schedule ID.
The appointment schedule table 32 identifies, for each schedule ID for each candidate date rank, a user ID that specifies an owner who is an appointment requester of the schedule ID and a convened user to be convened, and the owner and the convened user. Together with an appointment user order that specifies the order of the convened user, an appointment candidate date order that identifies the candidate date when a plurality of dates and times are specified for adjustment for the same appointment by the owner, a scheduled start date and time, The scheduled end date and time, the attendance flag, and reply comments for each appointment request or candidate date rank are stored.
When a plurality of dates and times are designated for adjustment for the same appointment by the owner, the schedule ID may be an individual ID for each candidate date rank. In addition, it is preferable to use a common schedule ID, schedule location data, schedule start date / time, and schedule end date / time for the schedule confirmed by adjusting the appointment, and to use common data for each user. . In this case, each user cannot edit the confirmed appointment schedule individually. Further, the schedule ID may be set for each user so that each user can edit the schedule of the confirmed appointment.
[0044]
FIG. 7 illustrates the contents of each field of each table 30, 32, 34, 36. As shown in FIG. 7, the schedule type code indicating the type of schedule is “0” for a confirmed normal schedule, “1” for an appointment schedule that is being adjusted, The repeat schedule is “2”. As for the appointment user ranking, the owner is “0”, and the convened user is numbered sequentially from “1”. The appointment candidate date rank is a number for identifying a plurality of appointment candidate dates. In this embodiment, there are only two types of attendance flags, participation is “1”, non-participation is “0”, and there is no data structure indicating reply suspension. Therefore, attendance is flagged.
[0045]
Referring to FIG. 5 again, the server includes a request creation
[0046]
When the request creation
[0047]
The request data
[0048]
When the calendar
[0049]
When the adjustment
[0050]
In a preferred example, the adjustment
[0051]
The reply data
[0052]
In the present embodiment, the adjustment
[0053]
In particular, in this embodiment, the calendar
[0054]
The
[0055]
The confirmation processing control unit 60 refers to the appointment schedule table 32 and receives the confirmed candidate date when receiving the attendance at the appointment by the owner and the confirmation operation for the candidate date from the terminal used by the owner. The start date / time and end date / time of the candidate date for ranking are stored in the normal schedule table of the convened user confirmed to participate by the owner, and the schedule type code of the schedule is updated to the normal schedule. The confirmation process control unit 60 executes, for example, the flowchart shown in FIG. In the example illustrated in FIG. 4, the confirmation process control unit 60 performs the process of step A5. That is, the flowchart shown in FIG. 14 is a detailed process of step A5 in the present embodiment.
[0056]
Next, specific usage will be described with reference to the screen. Here, the following situation settings and characters are set. Mr. Abe, the sales manager of a major office furniture company, K, proposed a furniture layout plan for the purchase of office furniture following the relocation of customer Q. Project leader Abe is in a position to coordinate the presentation schedule for members. Members of this project include salesman Ebizawa, designers Yamada, Wada and Suzuki.
[0057]
FIG. 8 is an explanatory diagram showing an example of a user schedule data display screen. 8 to 12 show a state in which data transmitted from the
[0058]
The calendar
[0059]
In addition, Mr. Abe finds that Mr. Yamada has sent an appointment request with a scheduled date of January 21 to the request display area indicated by
[0060]
FIG. 9 shows an example of the
[0061]
Referring to FIG. 5 again, in addition to the table shown in FIG. 6 and the like, for each project ID that identifies a project in which some or all of the users participate, the user ID of a user who is a member of the project, A project relation table 38 for storing contents belonging to the project, and a department table 31 for storing a user ID belonging to the department for each department ID for identifying the department to which the user belongs.
[0062]
Then, the
[0063]
Then, as shown in FIG. 9, the
[0064]
When the owner specifies the date / time and the user to be convened, the owner pushes down the
[0065]
FIG. 10 is an explanatory diagram showing an example of a
[0066]
When the user's
In the example shown in FIG. 10, since a plurality of candidate dates are included in the request data, first, the all candidate display control function in the request display area is the candidate date of the first candidate in the
[0067]
Further, the request data
[0068]
FIG. 11 is an explanatory diagram showing an example of the
[0069]
When Mr. Abe opens the
[0070]
FIG. 13 is a flowchart illustrating an example of request data storage processing by the request data storage control unit. When the required input items shown in FIG. 9 are input and the
[0071]
Subsequently, in order to assign the appointment user ranking, x = 1 is set (step S4), and the appointment user ranking of the convened user is x (step S5). Until this is completed for all “users to be called” shown in FIG. 9 (step S6), the value of x is incremented to set the appointment user rank.
[0072]
When the appointment user rank is set, the schedule ID, user ID, appointment user rank, candidate date rank, schedule start date and schedule end date and time are stored in the appointment schedule table 32 having the data structure shown in FIG. 6 (step S8). ). Subsequently, the schedule main table 36 stores the schedule ID, the user IDs of all users, the schedule type code, the schedule content data (Q company visit), and the schedule location data (Yokohama). Here, the schedule type code stores a code “1” indicating that the appointment is being adjusted. Thus, the request data for the first candidate date rank is stored using the schedule ID as a key. By referring to the schedule main table 36 using the schedule ID as a key, the various control units can specify whether the schedule identified by the schedule ID is a normal schedule or a schedule that is being adjusted for appointments.
[0073]
Subsequently, it is confirmed whether or not there is data for the next candidate date ranking (step S10). Here, since there is data for the second candidate date ranking, the process returns to step S1 and is scheduled for the second candidate date ranking. Get an ID. Similarly, for the second candidate date ranking, the request data is stored as schedule data during the adjustment of the appointment. Since there is no data for the third candidate date ranking, the processing ends.
[0074]
FIG. 14 is a flowchart showing an example of appointment confirmation processing by the confirmation processing control unit 60. When the
[0075]
In the
[0076]
Subsequently, the appointment schedule table 32 is searched from the schedule IDs of the determined candidate date rankings, and the schedule start date and time and the schedule end date and time are read. The schedule ID, the schedule start date and the schedule end date and time are newly newly set. It stores in the schedule table 34 (step S12). That is, the data regarding the confirmed schedule is copied from the appointment schedule table 32 to the normal schedule table.
[0077]
Further, the attendance user's attendance is confirmed in order from the appointment schedule table 32 using the schedule ID as a key (step S13). The search order of the convened user is the order of the appointment user ranking. Here, first, Mr. Abe who is the owner of the ranking “0” is confirmed. Since Mr. Abe's attendance flag is “1”, the schedule main table is searched with the schedule ID and the user ID of Mr. Abe, and the schedule type code is changed from “1” to “0” (step S15). . That is, the appointment of the first candidate is assumed to be Mr. Abe's normal schedule. Then, after making the normal schedule, the record of the appointment schedule table 32 regarding the corresponding user ID is deleted. Next, in steps S16 and S13, Mr. Ebisawa of rank “1” is specified and processed in the same manner.
[0078]
As for Mr. Wada, since the attendance flag is not stored in step S14 and is not “1”, the process proceeds to step S17. In step S17, it is confirmed whether or not the forced check box is turned on. Since the forced check box is turned on, the schedule type code is similarly updated to the normal schedule in step S15. When the schedule type code is a normal schedule, the schedule type code is displayed on each
[0079]
FIG. 15 is a flowchart illustrating an example of a schedule display process on a calendar. The
[0080]
When receiving a calendar screen display command from the
[0081]
Subsequently, the calendar
[0082]
On the 20th, a schedule for “strategic meeting” is stored in the normal schedule table 34. Since the answer is yes in step S24, the scheduled
[0083]
In the example shown in FIG. 10, Mr. Yamada's appointment schedule table 32 has two candidate days, 23 and 24, for one piece of requested data, visit Q company. In the case where it is specified that only the first candidate is displayed in the calendar table, in the example shown in FIG. 15, in step S33, the appointment schedule is stored in the appointment schedule table 32 for the 23rd. Referring to the candidate date ranking, since it is the second candidate, it is not determined as the candidate date to be displayed in step S33, and the display process is not performed. For the 24th day, the candidate date order is confirmed in step S33, and since it is the first candidate, the scheduled date and time is set to red in step S28 and the display process proceeds. Also, in this step S33, referring to the attendance flag for each candidate date in the appointment schedule table, among the candidate dates for participation (flag is “1”), the candidate date with the highest candidate date ranking (smallest value) It may be determined whether the date is a candidate date to be displayed on the calendar.
Further, in the example shown in FIGS. 8 and 10, the schedule is similarly searched for each user. In the example shown in FIG. 15, since the color of the characters displayed in the appointment schedule and the normal schedule is changed, it is possible to grasp at a glance that the appointment has been requested.
[0084]
When the reading of the schedule data and the color setting are all completed (step S31), the calendar table is described in a markup description language such as HTML.
[0085]
Further, referring to the appointment schedule table 32, the request data is described in the
[0086]
As described above, in this example, in addition to the same effects as the embodiment, for example, by the combination of the function of forced adjustment by the owner and the function of changing the display format after confirmation (from red to black), The participation order by forced adjustment is displayed on the convocation user's calendar in the same way as a normal schedule, so it is more effective to participate than to call or send an e-mail to instruct the user to participate. In addition, the owner and the convened user who compulsorily participates require little effort. Further, since appointment adjustment and schedule management are supported as screen generation using Web technology, an asynchronous environment can be provided in which both parties can work when they want to work, unlike e-mail. In addition, in the combination of the other user attendance
[0087]
【The invention's effect】
According to the present invention, according to the configuration, the calendar screen control unit describes normal schedule data and request data in a calendar field according to display designation such as month display, week display, etc., and generates a calendar table of a period by display designation To do. Then, the request display control function describes request data in a request display area outside the calendar table. Therefore, the request data can always be displayed on the calendar screen regardless of the display designation period. Therefore, it is possible to notify the user of the existence of request data outside the period displayed on the calendar screen. In addition, the calendar screen control unit displays the request data and the normal schedule data together in the calendar field during the period to be confirmed as daily work. For this reason, it is possible to confirm on the calendar screen the contents of the request data within the period to be confirmed and the presence or absence of the request data for other periods during the routine schedule confirmation work. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period without requiring any special operation. Since there is only a display of the schedule and the presence / absence of a request, there is no complication.
As described above, according to the present invention, the normal schedule data and the appointment schedule data are promoted in the daily work of confirming the schedule, that is, the individual schedule data and the schedule data that needs to be adjusted by the group are integratedly managed. be able to. As a result, even if a user who is not used to using a computer belongs to a group regarding schedule management, productivity can be improved by sharing schedule information of the group.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a schedule management support system in the present embodiment.
FIG. 2 is an explanatory diagram showing an example of a data structure in the present embodiment.
FIG. 3 is an explanatory diagram showing an example of a calendar screen handled in the present embodiment.
FIG. 4 is a sequence diagram illustrating an example of an appointment adjustment support process in the present embodiment.
FIG. 5 is a block diagram illustrating a configuration example of the present embodiment.
FIG. 6 is an explanatory diagram showing an example of a data structure in the present embodiment.
FIG. 7 is an explanatory diagram illustrating an example of a field name of each table in the embodiment.
FIG. 8 is an explanatory diagram showing an example of a user schedule data display screen.
FIG. 9 is an explanatory diagram illustrating an example of a request creation screen.
FIG. 10 is an explanatory diagram showing an example of a personal calendar screen having a request display area.
FIG. 11 is an explanatory diagram illustrating an example of an adjustment screen for a convened user.
FIG. 12 is an explanatory diagram showing an example of an adjustment screen (confirmation screen) for the owner.
FIG. 13 is a flowchart illustrating an example of request data storage processing;
FIG. 14 is a flowchart illustrating an example of a confirmation process.
FIG. 15 is a flowchart illustrating an example of a schedule display process.
[Explanation of symbols]
1 terminal
10 servers
12 Appointment confirmation processing section
13 Calendar screen controller
16 Adjustment control unit
18 Request display control function
19 Request data sorting function
20 First candidate display control function in request area
21 Request display area button control function
22 Notation setting function by schedule type
23 First candidate display control function in calendar
24 Participation Reply Date Display Control Function
Claims (16)
前記データベースが、ユーザーに関するデータを格納するユーザーテーブルと、前記各ユーザーの通常予定である通常予定データとアポイントメントのオーナーであるユーザーから参加が要請された要請データとを格納する予定関連テーブルとを備え、
前記サーバーが、
前記要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索し、当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述して、当該期間内の日付のカレンダーフィールドを有するカレンダーテーブルを生成するカレンダー画面制御部とを備え、
このカレンダー画面制御部が、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述する要請表示制御機能を備えたことを特徴とするスケジュール管理支援システム。A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database includes a user table that stores data related to users, and a schedule related table that stores normal schedule data that is a normal schedule of each user and request data that is requested to participate by a user who is the appointment owner. ,
The server is
An appointment confirmation processing unit that converts data about the confirmed date and time of the request data when the appointment of the request data is confirmed by the owner;
When receiving a display instruction and display designation of a calendar screen transmitted from the terminal, the request data and the normal schedule data stored in the schedule related table are searched for a period according to the display designation, and the request A calendar screen control unit that generates a calendar table having a calendar field for dates within the period, describing each period of the data and schedule data in each calendar field divided into days.
A schedule management support system, wherein the calendar screen control unit includes a request display control function for describing the request data in a request display area outside the calendar table in the calendar screen.
前記カレンダー画面制御部が、前記要請データ毎の要請表示エリアを、前記調整画面の表示指令を当該端末から送信する表示指令ボタンに設定する要請表示エリアボタン化制御機能を備えたことを特徴とする請求項1,2,3,4,5又は6記載のスケジュール管理支援システム。When the server receives an instruction to display an adjustment screen for creating a reply to the appointment request from a terminal used by the convened user who is requested to participate in the appointment, a reply to the request for the appointment An adjustment control unit that generates an adjustment screen that prompts each convened user to input data,
The calendar screen control unit includes a request display area button control function for setting a request display area for each of the request data to a display command button for transmitting a display command for the adjustment screen from the terminal. The schedule management support system according to claim 1, 2, 3, 4, 5, or 6.
前記データベースが、ユーザーに関するデータを格納するユーザーテーブルと、アポイントメントのオーナーであるユーザーから参加が要請され当該アポイントメントの日時及び参加者の調整中である要請データと前記各ユーザーの通常予定である通常予定データとを格納する予定関連テーブルとを備え、
前記サーバーが、
前記要請データのアポイントメントが前記オーナーによって確定されたときに当該要請データのうち確定した日時についてのデータを通常予定データに変換するアポイントメント確定処理部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、当該表示指定に応じた期間について前記予定関連テーブルに格納された前記要請データ及び前記通常予定データを検索して当該要請データ及び予定データについて当該期間を日毎に区切った各カレンダーフィールドに記述するカレンダー画面制御部を備え、
前記カレンダー画面制御部が、前記カレンダーフィールドへの記述の表示形式を、前記要請データと前記予定データとで異なる表示形式に設定する予定種類別表記設定機能を備えたことを特徴とするスケジュール管理支援システム。A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database includes a user table for storing data related to users, a request for participation from a user who is the appointment owner, and request data that is being adjusted for the date and time of the appointment, and a normal schedule for each user. And a schedule related table for storing data,
The server is
An appointment confirmation processing unit that converts data about the confirmed date and time of the request data when the appointment of the request data is confirmed by the owner;
When receiving a display instruction and display designation of a calendar screen transmitted from the terminal, the request data and the normal schedule data stored in the schedule related table are searched for a period according to the display designation and the request A calendar screen control unit that describes data and schedule data in each calendar field that divides the period into days,
The calendar screen control unit includes a schedule type notation setting function for setting the display format of the description in the calendar field to a different display format for the request data and the schedule data. system.
前記データベースが、
前記ユーザーを識別するユーザーID毎に当該ユーザーの氏名であるユーザー名データを格納するユーザーテーブルと、
予定を識別する予定ID毎に、前記ユーザーIDと、通常又はアポイントメント調整中等の予定の種類又は状態を識別する予定種類コードと、予定の内容である予定内容データとを格納する予定メインテーブルと、
前記予定ID毎に、予定開始日時データと、予定終了日時データとを格納する通常予定テーブルと、
候補日順位毎の前記予定ID毎に、当該予定IDのアポイントメントの要請者であるオーナー及び招集される招集ユーザーを特定するユーザーIDと、前記オーナーによって同一のアポイントメントについて調整用に複数の日時が指定される場合に当該候補日を識別するアポイントメント候補日順位と、予定開始日時と、予定終了日時と、出欠フラグと、アポイントメント要請毎又は候補日順位毎の返信コメントとを格納するアポイントメント予定テーブルとを備え、
前記サーバーが、
前記オーナーによって使用される端末からアポイントメントの要請を作成するための要請作成画面の表示指令を受信した場合に、前記予定内容データと、前記予定場所データと、前記招集ユーザーのユーザー名と、前記候補日順位毎の予定開始日時及び予定終了日時との入力を当該オーナーに促す要請作成画面を生成する要請作成画面生成部と、
前記要請作成画面が生成されたときに前記オーナーによって使用される端末へ当該要請作成画面を送信し、当該オーナーによって当該要請作成画面に入力される要請データを受信して、前記予定種類コードをアポイントメント調整中として前記予定内容データ及び予定場所データとを前記予定メインテーブルに格納すると共に、前記要請作成画面の他の各フィールドの内容を前記アポイントメント予定テーブルに格納する要請データ格納制御部と、
前記招集ユーザーによって使用される端末から前記アポイントメントの要請に対する返信を作成するための調整画面の表示指令を受信した場合に、出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントとの入力を各招集ユーザーに促す調整画面を生成する調整画面生成部と、
前記調整画面が生成されたときに前記招集ユーザーによって使用される端末へ当該調整画面を送信し、当該招集ユーザーによって当該調整画面に入力される返信データを受信して、前記出欠フラグと、前記アポイントメント要請毎又は候補日順位毎の返信コメントを前記アポイントメント予定テーブルに格納する返信データ格納制御部と、
前記オーナーによって使用される端末から当該オーナーによるアポイントメントへの出欠及び候補日の確定操作を受信したときに、前記アポイントメント予定テーブルを参照して、前記当該確定された候補日順位の候補日の開始日時及び終了日時を、前記オーナーによって参加に確定された招集ユーザーの通常予定テーブルに格納し、当該予定の予定種類コードを通常予定に更新する確定処理制御部と、
前記端末から送信されるカレンダー画面の表示指令及び表示指定を受信したときに、前記予定メインテーブルに格納された予定種類コードに応じて前記アポイントメント予定テーブルに格納された要請データ及び前記通常予定テーブルに格納された予定データとを当該期間を日毎に区切った各カレンダーフィールドに記述するカレンダー画面制御部を備え、
このカレンダー画面制御部が、
前記表示指定による期間と無関係に、前記カレンダー画面中で前記カレンダーテーブル外の要請表示エリアに前記要請データを記述させる要請表示制御機能と、
前記カレンダーフィールドへの記述の表示形式を、前記予定メインテーブルに格納された予定種別コード毎に異なる表示形式に設定する予定種類別表記設定機能とを備えたことを特徴とするアポイントメント調整支援システム。A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database is
A user table storing user name data which is the name of the user for each user ID for identifying the user;
For each schedule ID for identifying a schedule, a schedule main table for storing the user ID, a schedule type code for identifying a schedule type or status such as normal or during appointment adjustment, and schedule content data that is a schedule content;
A normal schedule table storing schedule start date and time data and schedule end date and time data for each schedule ID;
For each schedule ID for each candidate date ranking, a user ID that specifies an owner who is a requester of the appointment of the schedule ID and a convened user to be convened, and a plurality of dates and times are designated by the owner for adjustment for the same appointment An appointment schedule table for storing the appointment candidate date order for identifying the candidate date, the scheduled start date and time, the scheduled end date and time, the attendance flag, and a reply comment for each appointment request or each candidate date order. Prepared,
The server is
When receiving a request creation screen display command for creating an appointment request from a terminal used by the owner, the planned content data, the planned location data, the user name of the convened user, and the candidate A request creation screen generation unit for generating a request creation screen that prompts the owner to input a schedule start date and time and a schedule end date and time for each day order;
When the request creation screen is generated, the request creation screen is transmitted to the terminal used by the owner, the request data input to the request creation screen by the owner is received, and the scheduled type code is appointmented. A request data storage control unit that stores the scheduled content data and the planned location data in the scheduled main table as being adjusted, and stores the contents of other fields of the request creation screen in the appointment scheduled table;
When an instruction to display an adjustment screen for creating a reply to the appointment request is received from the terminal used by the convened user, input of an attendance flag and a reply comment for each appointment request or candidate date rank An adjustment screen generation unit that generates an adjustment screen to prompt each convened user,
When the adjustment screen is generated, the adjustment screen is transmitted to the terminal used by the convened user, the reply data input to the adjustment screen by the convened user is received, the attendance flag, and the appointment A reply data storage control unit for storing reply comments for each request or candidate date ranking in the appointment schedule table;
When the terminal used by the owner receives an attendance to the appointment by the owner and a confirmation operation for the candidate date, the appointment date start date and time of the confirmed candidate date ranking is referred to the appointment schedule table. And an end date and time are stored in the regular schedule table of the convened user confirmed to participate by the owner, and a schedule processing control unit for updating the schedule type code of the schedule to the normal schedule,
When receiving the display instruction and display designation of the calendar screen transmitted from the terminal, the request data stored in the appointment schedule table according to the schedule type code stored in the schedule main table and the normal schedule table A calendar screen control unit that describes stored schedule data in each calendar field that divides the period into days,
This calendar screen control unit
A request display control function that allows the request data to be described in a request display area outside the calendar table in the calendar screen regardless of the display designation period.
An appointment adjustment support system comprising a schedule type notation setting function for setting a display format of the description in the calendar field to a different display format for each schedule type code stored in the schedule main table.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003164685A JP2005004307A (en) | 2003-06-10 | 2003-06-10 | Schedule management support system, and appointment adjustment support system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003164685A JP2005004307A (en) | 2003-06-10 | 2003-06-10 | Schedule management support system, and appointment adjustment support system |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005004307A true JP2005004307A (en) | 2005-01-06 |
Family
ID=34091391
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003164685A Pending JP2005004307A (en) | 2003-06-10 | 2003-06-10 | Schedule management support system, and appointment adjustment support system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005004307A (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006338248A (en) * | 2005-06-01 | 2006-12-14 | Ricoh Co Ltd | Task management apparatus, task management method and task management program |
WO2007072707A1 (en) | 2005-12-19 | 2007-06-28 | Daikin Industries, Ltd. | Electric motor and its rotor, and magnetic core for the rotor |
CN102844795A (en) * | 2010-04-19 | 2012-12-26 | 索尼公司 | Image processing device, image processing method and program |
JP2017033292A (en) * | 2015-07-31 | 2017-02-09 | 株式会社ぐるなび | Server, control method, and control program, for the same |
CN109561272A (en) * | 2017-09-27 | 2019-04-02 | 阿里巴巴集团控股有限公司 | The display methods and device of conferencing information |
JP7142984B1 (en) | 2022-01-11 | 2022-09-28 | 株式会社Spir | Program, information processing device and information processing method |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04133168A (en) * | 1990-09-26 | 1992-05-07 | Hitachi Ltd | Data processor and schedule managing method |
JPH05165836A (en) * | 1991-12-16 | 1993-07-02 | Just Syst Corp | Schedule management system |
JPH06139248A (en) * | 1992-10-27 | 1994-05-20 | Sanyo Electric Co Ltd | Schedule information control system |
JPH09212550A (en) * | 1996-01-31 | 1997-08-15 | Toshiba Corp | Computer system and its schedule managing method |
JP2001306769A (en) * | 2000-04-17 | 2001-11-02 | Hitachi Ltd | Reservation system giving preference to schedule |
JP2002056031A (en) * | 2000-08-11 | 2002-02-20 | Go Fumiko | System for replying attendance/absence to/from event |
JP2002169939A (en) * | 2000-12-01 | 2002-06-14 | Canon Sales Co Inc | Conference system, and server and operational terminal therefor, and control method and storage medium |
-
2003
- 2003-06-10 JP JP2003164685A patent/JP2005004307A/en active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04133168A (en) * | 1990-09-26 | 1992-05-07 | Hitachi Ltd | Data processor and schedule managing method |
JPH05165836A (en) * | 1991-12-16 | 1993-07-02 | Just Syst Corp | Schedule management system |
JPH06139248A (en) * | 1992-10-27 | 1994-05-20 | Sanyo Electric Co Ltd | Schedule information control system |
JPH09212550A (en) * | 1996-01-31 | 1997-08-15 | Toshiba Corp | Computer system and its schedule managing method |
JP2001306769A (en) * | 2000-04-17 | 2001-11-02 | Hitachi Ltd | Reservation system giving preference to schedule |
JP2002056031A (en) * | 2000-08-11 | 2002-02-20 | Go Fumiko | System for replying attendance/absence to/from event |
JP2002169939A (en) * | 2000-12-01 | 2002-06-14 | Canon Sales Co Inc | Conference system, and server and operational terminal therefor, and control method and storage medium |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006338248A (en) * | 2005-06-01 | 2006-12-14 | Ricoh Co Ltd | Task management apparatus, task management method and task management program |
WO2007072707A1 (en) | 2005-12-19 | 2007-06-28 | Daikin Industries, Ltd. | Electric motor and its rotor, and magnetic core for the rotor |
CN102844795A (en) * | 2010-04-19 | 2012-12-26 | 索尼公司 | Image processing device, image processing method and program |
US20130027430A1 (en) * | 2010-04-19 | 2013-01-31 | Kouichi Matsuda | Image processing device, image processing method and program |
JP2017033292A (en) * | 2015-07-31 | 2017-02-09 | 株式会社ぐるなび | Server, control method, and control program, for the same |
CN109561272A (en) * | 2017-09-27 | 2019-04-02 | 阿里巴巴集团控股有限公司 | The display methods and device of conferencing information |
JP7142984B1 (en) | 2022-01-11 | 2022-09-28 | 株式会社Spir | Program, information processing device and information processing method |
WO2023135828A1 (en) * | 2022-01-11 | 2023-07-20 | 株式会社Spir | Program, information processing device, and information processing method |
JP2023101885A (en) * | 2022-01-11 | 2023-07-24 | 株式会社Spir | Program, information transmission device and information processing method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6678671B1 (en) | System for linking a resource management system with an event of a project in a project management system and a method therefor | |
JP2687230B2 (en) | How to support reply creation for meeting notifications by e-mail | |
JP5423444B2 (en) | Network system, server device, and groupware program | |
US7904322B2 (en) | Network based, interactive project management apparatus and method | |
US8768882B2 (en) | Distributed system for interactive collaboration | |
US20070250784A1 (en) | Methods and apparatus to combine data from multiple computer systems for display in a computerized organizer | |
US20070250370A1 (en) | Scheduling application and distribution method | |
JPH0731700B2 (en) | How to relate calendar information maintained in a data processing system | |
US20040220825A1 (en) | Organizational restructuring | |
US20070050228A1 (en) | Schedule management | |
Ehrlich | Social and psychological factors influencing the design of office communications systems | |
JPH07282129A (en) | Schedule management system | |
JP6955724B1 (en) | Accounting business support system | |
JP2005004307A (en) | Schedule management support system, and appointment adjustment support system | |
CA2323268A1 (en) | A system for linking a booking of a resource with events of a project and a method therefor | |
JP2004054799A (en) | Network electronic notebook and schedule reserving method | |
JP2003242310A (en) | System for managing schedule | |
JP2525047B2 (en) | How to create a composite calendar | |
EP1188128A1 (en) | System and method for publishing documents | |
Ott | Conceptual design and implementation of a graphical workflow-modelling editor in the context of distributed groupware-databases | |
JP7015496B1 (en) | Accounting business support system | |
JP2003223535A (en) | Schedule management method, program, and recording media | |
JPH0991339A (en) | Process rearrangement support system | |
Muir | Microsoft Office Project 2007 for Dummies | |
Cicala et al. | Using Project Web App for Tracking |
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: 20080414 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080425 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080819 |