JP2006003938A - 予定通知方法 - Google Patents

Abstract

【課題】
遅刻や欠席等の問題が生じると思われる予定情報について事前にユーザへ告知する。
【解決手段】
特定ユーザについて通知対象となる第一の予定、該第一の予定とは異なる第二の予定が対応づけて管理される設定テーブルを参照し、該第二の予定を特定するとともに、予定情報とその日時情報が管理される予定テーブルを参照し、前記ユーザについて前記第二の予定が存在するか否かを判定し、判定結果が真である場合、前記第二の予定の日時情報に基づいて前記第一の予定を前記ユーザに通知する。
【選択図】
図１

Description

本発明は、遅刻や欠席等の問題が生じると思われる予定情報について事前にユーザへ告知する予定情報通知方法に関する。

インターネット上のスケジュール管理サービスで、スケジュール登録時に事前通知を設定しておけば、スケジュールの予定時刻の前に携帯電話へメール通知するリマインダー機能は、既にサービス化されている（非特許文献１）。

ところで、スケジュールに遅延、遅刻、欠席等の問題が生じる可能性がある場合に警告する先行技術文献には、次のようなものがある。

例えば、教育機関からの脱落危機状態の生徒を確実に見つけ、迅速に対応できることを目的とする危機生徒ケアシステムは、所定回数遅刻した時点で、その生徒を脱落危険ありと判定し、教師に対して該生徒への連絡を指示する（特許文献１）。
特開２００２−１４９８４０ ｇｏｏカレンダー、３．リマインダ−を使おう 、[online]、[平成１６年６月３日検索]、インターネット ＜ＵＲＬ：http://cal.goo.ne.jp/help/tutorial/ja/calendar%5ftutorial03.htm#03＞

しかし、このような固定的な日時設定をする事前通知は、次のような問題がある。

たとえば、大切な会議予定を登録する際、万が一のことに備えてユーザが事前通知を設定したとしよう。この時、従来技術では、該当スケジュールのどれくらい前に通知するか、予め設定する必要がある。そこで、今「１０分前」に設定したとする。

しかし、その後、この会議の前夜に、アルコールを伴う接待の予定が入り、その接待の席でユーザはアルコールを飲みすぎ、結局、会議当日は会社を休んでしまった。設定通り、会議の１０分前に事前通知は携帯電話に着信するが、これでは、この通知は全く意味をなさない。

本来ならば、接待の予定を登録する際に、翌日の会議に関する事前通知設定をユーザが変更すれば良い。しかし、これでは、ユーザ自身が常に各スケジュール間の関係を把握し、スケジュールを登録する度に、既に設定した事前通知要否や設定時間を変更すべきか否かを判断する、という非常に煩雑な作業をユーザに強いることになる。

また、先行技術文献のような、所定回数遅刻や欠席すると警告する機能を、スケジュール管理サービスに組み込んだとしても、スケジュールを欠席した時点で「スケジュールをキャンセルしたから注意しなさい」と警告されるだけで、欠席してしまったスケジュールに対して、この機能は何の貢献もしない。

本発明の目的は、ユーザに固定的な日時情報を設定させるのではなく、予約通知の要否を判定する通知条件を設定させ、その通知条件に基づいて、より柔軟でより有益な予定通知を提供することである。

より具体的に述べるならば、本発明の目的は、通知対象予定に影響を与える可能性のある他の予定が存在する場合に、影響を与え得る予定が実施される時間帯に、注意を促す情報をユーザに通知し、通知対象予定に問題が生じることを予防することである。

本発明は、特定ユーザについて通知対象となる第一の予定、該第一の予定とは異なる第二の予定が対応づけて管理される設定テーブルを参照し、該第二の予定を特定するとともに、予定情報とその日時情報が管理される予定テーブルを参照し、前記ユーザについて前記第二の予定が存在するか否かを判定し、判定結果が真である場合、前記第二の予定の日時情報に基づいて前記第一の予定を前記ユーザに通知することを特徴とする。

さらに、本発明は、前記設定テーブルに、さらに、前記第一の予定と前記第二の予定に関する日時情報の隔たり期間が含まれ、前記予定テーブルを参照し、前記第一の予定から該隔たり期間内に前記第二の予定が存在するか否かを判定し、その判定結果が真である場合に、前記第二の予定の日時情報に基づいて前記第一の予定を前記ユーザに通知することを特徴とする。

さらに、本発明は、前記設定テーブルに、さらに、前記第二の予定の日時情報を基準にした通知タイミングが含まれ、前記通知タイミングに基づいて、前記第一の予定を通知することを特徴とする。

本発明は、ユーザに固定的な日時情報を設定させるのではなく、予約通知の要否を判定する通知条件を設定させ、その通知条件に基づいて、予約通知の要否を判定するので、従来技術よりも、より柔軟でかつより有益な予定通知方法を実現できる。

本発明は、通知対象予定に影響を与える可能性のある予定が実施される時間帯に、注意を促す情報をユーザに通知するので、通知対象予定に問題が生じることを未然に防ぐことができる。

以下、本発明における一実施形態を示す。尚、本実施例と同等の効果が生じるものであれば、どのような変更を加えても構わない。

本発明における一実施形態のシステム全体の構成を図１に示す。本発明は、サーバ１００、携帯端末２００、勤怠管理システム３００、ネットワーク４００・４１０で構成される。

サーバ１００は、さらに、予定登録手段１１０、通知手段１２０、利用者ＤＢ（データベース）１３０、予定ＤＢ１４０、条件ＤＢ１５０、通知ＤＢ１６０で構成される。

予定登録手段１１０は、携帯端末２００からのスケジュール情報およびスケジュール情報の通知を設定するアラーム情報に従って、予定情報を予定ＤＢ１４０に、アラーム情報を条件ＤＢ１５０あるいは通知ＤＢ１６０に登録する。

通知手段１２０は、通知ＤＢ１６０に登録されたアラーム情報に基づき、設定された通知タイミングで、通知すべき予定を携帯端末２００に電子メールを送信する。

利用者ＤＢ１３０は、利用者の識別情報および連絡先情報が蓄積管理される。予定ＤＢ１４０は、ユーザが携帯端末２００から送信されてくるスケジュール情報が蓄積管理される。条件ＤＢ１５０は、ユーザが携帯端末２００から送信されてくるアラーム通知に関する通知条件が蓄積管理される。通知ＤＢ１６０は、携帯端末２００に送信することが確定しているリマインダー機能によるアラーム通知情報、および、本発明の特徴である通知条件が満されると送信するアラーム通知情報が蓄積管理される。

なお、サーバには、上記以外にも、登録されたスケジュールを表示する予定表示手段が当然含まれるが、該手段は従来技術であり、また、本発明には直接関係しないため、ここでは図示していない。

携帯端末２００は、サーバ１００から送信されるスケジュール管理サービス画面をディスプレイに表示するとともに、ユーザの入力情報をサーバ１００へ送信する閲覧手段２１０、および、サーバ１００からのアラーム通知を受信表示するメール手段２２０を備える。本実施例においては、携帯端末２００は、ユーザ毎に一台づつ存在し、各端末毎にユーザのメールアドレスが登録されている。

携帯端末２００は、パーソナルコンピュータ、ワークステーション、携帯電話、ＰＤＡ(Personal Data Assistance)端末など、ネットワーク４００を介して、サーバ１００とのデジタルコミュニケーションが可能であれば、どのような装置でもかまわない。また、携帯型ではない、いわゆる据え置き型の端末を利用することも可能である。

閲覧手段２１０は、インターネットブラウザを想定しているが、これも、サーバ１００から送信されてきたデータをディスプレイ上に表示する一方、ユーザの入力情報を受付けサーバ１００に送信することが可能であれば、どのようなソフトウェアプログラムでもかまわない。

メール手段２２０は、通常のメーラーソフトなど、インターネット上でメール交換が可能できるのであれば、どのようなソフトウェアプログラムでも構わない。

勤怠管理システム３００には、ユーザが所属する企業組織におけるユーザの勤務実績情報を蓄積管理する勤怠ＤＢ３１０が備わる。いうまでもないが、勤怠管理システム３００には、この他にも、勤怠情報を収集し、かつ、勤怠情報を表示する勤怠処理手段が存在するが、本発明では、サーバ１００が、直接、勤怠ＤＢ３１０に蓄積された情報を参照するようにしているため、図示していない。しかし、サーバ１００が特定のユーザの勤怠情報を取得するため、一旦、図示していない勤怠処理手段に依頼要求を送信し、当該勤怠処理手段から該ユーザの勤怠情報を受信するような実施形態も当然可能である。

本実施例においては、勤怠管理システム３００は、ユーザが所属する企業組織毎に異なるシステムが複数存在することとする。

ネットワーク４００・４１０は、インターネット網を想定しているが、サーバ１００〜携帯端末２００間、あるいは、サーバ１００〜勤怠管理システム３００間において、デジタルコミュニケーションを可能とするのであれば、どのような通信回線でも構わない。また、有線回線か無線回線の区別も必要ない。

さらに、ネットワーク４１０については、社外ネットワークではなく、構内ＬＡＮなどの社内ネットワークであってもよい。なぜなら、同一運営者がサーバ１００と勤怠管理システム３００を稼動させることがあり得るためである。

図２に、サーバ１００の予定登録手段１１０が実行する予定登録処理のフローを示す。この処理フローは、携帯端末２００の閲覧手段２１０を介して、新たな登録スケジュールが送信されてきた時、サーバ１００が該スケジュールを登録するとともに、該スケジュールによって、アラーム通知条件に合致するスケジュール関係が生じたか否かを判定する一連の処理を示している。

Ｓ１で、予定登録手段１１０は、閲覧手段２１０から送信された、スケジュール情報およびアラーム情報を受信する。ただし、アラーム情報がない場合もあり得る。

図９に、閲覧手段２１０に表示される予定登録画面２１００を例示する。この画面は、ユーザが、閲覧手段２１０を介して、自身の識別情報（一般的には、ユーザＩＤとパスワード。本実施例ではユーザＩＤのみ）を入力してインターネット上のスケジュール管理サービスに接続し、さらに、スケジュール登録機能を選択した際に、予定登録手段１１０によって閲覧手段２１０へ送信される。

予定登録画面２１００は、ユーザが登録を希望するスケジュールの各種情報（「予定登録」領域の各項目）とともに、該スケジュールについてアラーム通知を希望する際の各種設定情報（「アラーム設定」領域の各項目）が入力できるようになっている。

スケジュールの通知を希望しない場合は、「アラーム設定」領域の「通常」・「関連付け」方式のいずれも選択しないでおく。一方、アラーム通知希望の場合には、そのいずれかを選択し、対応する各設定情報を入力する。この時、選択されなかった方式に対応する設定情報は入力できないような画面設定を施すことが望ましい。

「通常」を選択すると、従来技術のリマインダー機能と同じように、ユーザは、予定開始日時のどれくらい前にアラーム通知が欲しいのか、例えば、「１０分前」、「２時間前」等、固定的な日時情報を設定する。「分」の部分はプルダウンメニューになっており、例えば「時間」、「日」が設定できるようになっている。

「関連付け」のアラーム設定を選択すると、ユーザは、通知条件および通知タイミングを設定する。サーバ１００は、同一画面で登録されたスケジュールに関連して通知条件を満たすような関連スケジュールが存在する場合に、当該関連スケジュールを基点とする通知タイミングで、予め定められた連絡先へ登録スケジュールを通知する。

「関連付けの予定種別」項目は、プルダウンメニューから、関連スケジュールの種別が設定される。プルダウンメニューには、例えば、「会議」、「接待」、「運動」、「出張」などが設定されていて、これらの項目は、ユーザによってカスタマイズ可能である。

「監視期間」項目は、登録スケジュールと関連スケジュールの時間的な隔たりが設定される。本実施例の場合は、登録スケジュールの日時を起点に、所定日数前の日付に、関連スケジュールの全体あるいは一部が含まれる場合は、この「監視期間」条件に該当するとみなす。尚、これを登録スケジュールの開始日時から正確に所定時間数繰り上げた日時までを範囲と設定することも、もちろん可能である。プルダウンメニューには、例えば、「１日」、「２日」、「３日」、「１週間」、「２週間」などが、設定されている。これらの項目は、ユーザによってカスタマイズ可能である。

「付帯条件」項目は、関連スケジュールの有無の他に、さらに、ユーザの残業時間に関する最低条件を設定する場合に、使用される。プルダウンメニューには、例えば、「前日残業時間」、「１週間の残業時間合計」、「１カ月の残業時間合計」などが設定されている。その後に、具体的な数値が入力できる入力領域がある。

付帯条件を設定しない場合は、プルダウンメニューに最初に示される「−（非設定）」のままにしておく。また、この付帯条件には、この種の勤怠情報以外にも、例えば、天候など、登録スケジュールや関連スケジュールに影響を与えそうな情報に関して条件設定できるように設定してもよい。その場合は、当該情報を有するシステムにアクセスできるような環境を整えておくことが必要である。

「通知」項目は、通知タイミングが設定される。プルダウンメニューには、例えば、「開始後」、「終了前」などが設定されている。その後に、具体的な数値が入力できる入力領域がある。

したがって、図９に例示される、ユーザ「Ｕ００１」の予定登録画面２１００に入力された「関連付け」方式の通知条件は、次のように解釈される。

ユーザＩＤ「Ｕ００１」が新規登録する「２００４年５月２６日午前９時」開始予定の「Ｂ社プレゼン検討」というスケジュールに関連して、「２００４年５月２５日」から「２００４年５月２６日９時」までに予定種別「接待」の予定が登録され、かつ、「２００４年５月２４日」の残業時間が「３時間」を超える場合は、「接待」種別の予定の開始日時から５分後に、「Ｂ社プレゼン検討」のスケジュールをユーザＩＤ「Ｕ００１」の連絡先にメール通知することになる。

図２に戻って、Ｓ２で、予約登録手段１１０は、Ｓ１で受信したスケジュールを予定ＤＢ１４０内の予定テーブル１４００へ登録する。

図５に予定テーブル１４００を例示する。予定テーブル１４００は、新規スケジュールが登録される毎に一意に生成される識別情報である「予定ＩＤ」、新規スケジュールに関する「日付」・「開始時刻」・「終了時刻」、新規スケジュールの種類を示す「種別」、そして、新規スケジュールの内容を示す「内容」、という各項目で構成される。

予定テーブル１４００は、スケジュールを１件でも登録したユーザ毎に予約登録手段１１０が生成する。但し、予定テーブル１４００に「ユーザＩＤ」項目を追加して、全ユーザのスケジュールを単一の予約テーブル１４００で管理してもよい。

登録されたスケジュールについては、閲覧手段２１０から明示的に削除要求を受信しない限り、予定登録手段１１０は削除処理を実施せず、予定テーブル１４００に蓄積されていく。

Ｓ３で、予約登録手段１１０は、Ｓ１で受信した情報に、アラーム情報が含まれるか否かを判定し、アラーム情報が含まれる場合はＳ４へ進み、一方、アラーム情報が含まれない場合はＳ７へ進み、各処理を実行する。

Ｓ４で、予約登録手段１１０は、Ｓ１で受信したアラーム情報の種別を判定し、通常のアラーム方式の設定情報ならばＳ６へ進み、一方、関連付け方式の設定情報ならばＳ５へ進み、それぞれの処理を実行する。

Ｓ５で、予約登録手段１１０は、受信した関連付け方式の設定情報を条件ＤＢ１５０内の条件テーブル１５００へ登録する。条件テーブル１５００は、関連付け方式のアラーム設定を行っているユーザ毎に作成される。

本実施例では、設定情報が１件もないユーザの条件テーブル１５００は、予約登録手段１１０によって削除される。したがって、設定情報を登録すべきユーザＩＤに対応する条件テーブル１５００が無い場合は、予約登録手段１１０が、新規に当該ユーザの条件テーブル１５００を作成する。

尚、条件テーブル１５００に「ユーザＩＤ」項目を追加して、全ユーザの設定情報を単一の条件テーブル１５００で管理してもよい。

図６に例示する通り、条件テーブル１５００は、スケジュール毎に一意に発行される「予定ＩＤ」、通知対象となるスケジュールの「開始日時」、関連スケジュールの「予定種別」および、通知対象スケジュールと関連スケジュールの時間的隔たりを示す「監視期間」、付帯条件の「条件種別」および「条件内容」、関連スケジュールを基準とする通知タイミングを示す「通知基準」および「時間」で構成される。

この内、関連予定の「監視期間」および付帯条件の「条件種別」については、通知対象スケジュールの開始日時が具体的に設定されているため、予約登録手段１１０が、具体的な値を算出して、その値を登録することになる。

例えば、図９の例示するような関連付け方式のアラーム設定がなされた場合、予約登録手段１１０は、「監視期間」が１日前に当たる「２００４年５月２５日」であり、また、付帯条件の「条件種別」が関連スケジュールの１日前の「２００４年５月２４日」であることを算出して、図６に例示するようなユーザＩＤ「Ｕ００１」に対応した条件テーブル１５００の該当項目へ算出した値を登録する。

図２のＳ６で、予約登録手段１１０は、受信した「通常」方式のアラーム設定情報を、通知ＤＢ１６０内の通知テーブル１６００へ登録する。「通常」方式のアラーム設定情報は、設定された通知タイミングで必ず対象スケジュールを通知するため、条件テーブル１５００ではなく、直接通知テーブル１６００に登録される。

通知テーブル１６００も、本実施例では、ユーザ毎に予定登録手段１１０が生成するが、通知テーブル１６００に「ユーザＩＤ」項目を追加して、全ユーザの通知情報を単一の通知テーブル１６００で管理してもよい。

図７に通知テーブル１６００を例示する。通知テーブル１６００は、通知対象のスケジュールを一意に識別する「予定ＩＤ」、関連スケジュールを一意に識別する「関連ＩＤ」、条件テーブル１５００で説明した付帯条件の「条件種別」・「条件内容」、付帯条件を満たしているか否かを示す「状態」、および、通知タイミングの「日付」および「時刻」で構成される。

これらの項目のうち、「通常」方式の設定情報が登録される場合は、「関連ＩＤ」、「付帯条件」は登録されない。そして、「状態」は、Ｓ６の段階で「確定」が登録される。また、「通知設定」は、通知対象スケジュールの開始日時から、図９で入力された時間数分だけ繰り上げた具体的な日時を、予定登録手段１１０が算出し、その算出結果を登録する。

以上Ｓ１〜Ｓ６は、予約登録手段１１０が、新規スケジュールを登録するとともに、アラーム設定の有無を確かめ、有る場合は、アラーム設定の方式に応じて、その設定情報を登録する処理である。

一方、Ｓ７以降は、予約登録手段１１０が、Ｓ２で新たに登録したスケジュールが、条件ＤＢ１５０に管理される「関連付け」アラーム設定の各通知条件に該当する関連付けスケジュールに相当するか否かを判定する処理となる。

Ｓ７で、予約登録手段１１０は、条件ＤＢ１５０内の条件テーブル１５００の第１レコードを読み込み、Ｓ８で、Ｓ１で受信したスケジュール情報が、条件テーブル１５００の「関連予定」項目に格納されたスケジュールに該当するか否かを判定する。

因みに、条件テーブル１５００は、既に説明した通り、ユーザ毎に作成されるので、例えば、ユーザＩＤの昇順に、予約登録手段１１０は条件テーブル１５００を判定していくようにする。

Ｓ８の判定の結果、受信したスケジュールが該当する場合は、予約登録手段１１０はＳ９へ進み、一方、該当しない場合はＳ１０へ進み、それぞれの処理を実行する。

Ｓ９で、予約登録手段１１０は、Ｓ１で受信したスケジュールが通知対象スケジュールの関連スケジュールに相当すると判断し、通知ＤＢ１６０内の通知テーブル１６００に、設定情報を登録する。すなわち、「予定ＩＤ」項目には、条件テーブル１５００の該当レコードの「予定ＩＤ」の値を引き継ぎ、「関連ＩＤ」項目には、Ｓ２で予定テーブル１４００に登録したレコードの「予定ＩＤ」の値を引き継ぐ。そして、「通知設定」項目には、条件テーブル１５００の「通知設定」項目内容および予定テーブル１４００に登録した「開始時刻」または「終了時刻」に基づき、具体的な算出値を登録する。

この際、条件テーブル１５００の「付帯条件」項目が設定されていない場合は、通知テーブル１６００の「付帯条件」項目は空白のまま残し、「状態」項目には「確定」を設定する。一方、「付帯条件」項目が設定されている場合は、通知テーブル１６００の「付帯条件」項目に引き継ぎ、「状態」項目には「未定」を設定する。

Ｓ１０で、予約登録手段１１０は、読み込んでいる条件テーブル１５００の当該レコードの「開始日時」項目の日時情報の値にシステム日時が達しているか否かを判定し、達している場合は、当該通知条件は不要とみなし、Ｓ１１へ進み当該レコードを削除し、一方、達していない場合は、この通知条件をまだ必要とみなし、削除せずＳ１２へと進む。

Ｓ１２で、予約登録手段１１０は、条件ＤＢ１５０内の全条件テーブル１５００の全レコードを確認し終えたか否かを判定し、全て判定した場合は一連の処理を終了し、未だ完了していない場合はＳ１３に進み、次のレコード、あるいは、新たに次ユーザの条件テーブル１５００の先頭レコードを読み込んで、Ｓ８の処理へ戻る。

尚、全て判定して一連の処理を終了しても、サーバ１００の運用時間内であれば、再びＳ１からの処理を繰り返すことになる。

図３に、サーバ１００の通知手段１２０が処理する通知処理フローを示す。この処理フローは、通知手段１２０が通知ＤＢ１６００の通知テーブル１６００に蓄積管理されたアラーム通知を設定された通知タイミングでユーザに通知する処理である。但し、関連付けアラーム設定の場合は、付帯条件を満たしているか否かが、判定される。

Ｓ２１で、通知手段１２０は、通知ＤＢ１６０内の通知テーブル１６００の第１レコードを読み込む。通知テーブル１６００は、既に説明した通り、ユーザ毎に作成されるので、例えば、ユーザＩＤの昇順に、該当する通知テーブル１６００を特定し、その第１レコードを読み込むようにすればよい。

Ｓ２２で、通知手段１２０は、読み込んだ通知テーブル１６００のレコードの「付帯条件」項目に値が登録されているか否かを判定する。判定の結果、何も設定されていなければ、当該レコードに関しては、通知タイミングに達しているか否かを判定すればよいので、通知手段１２０は、Ｓ２７へ進む。一方、「付帯条件」項目が設定されていれば、通知手段１２０は、Ｓ２３へ進む。

Ｓ２３で、通知手段１２０は、読み込んだレコードの「状態」項目を判定し、「確定」が設定されている場合はＳ２７へ進み、一方、「未定」が設定されている場合はＳ２４へ進む。

Ｓ２４で、通知手段１２０は、「付帯条件」項目に設定されている残業条件内容を特定し、該当ユーザの勤怠情報が管理される勤怠ＤＢ３１０を参照する。

例えば、図７に例示するユーザＩＤ「Ｕ００１」の通知テーブル１６００の第１レコードを参照すると、「付帯条件」項目には、「２００４年５月２４日」の残業時間の最低時間が「３時間」と設定されている。

これに基づき、通知手段１２０は、利用者ＤＢ１３０内の利用者テーブル１３００を参照し、ユーザＩＤ「Ｕ００１」に該当する会社ＩＤ「Ｃ００１」と従業員ＩＤ「JYU００１」を特定し、この情報から、会社ＩＤに該当する勤怠管理システム３００が管理する勤怠ＤＢ３１０へアクセスする。

図４に利用者テーブル１３００を例示する。利用者テーブル１３００は、「ユーザＩＤ」、「会社ＩＤ」、「従業員ＩＤ」、通知先情報である「通知先」で構成される。「ユーザＩＤ」が「従業員ＩＤ」と同一、あるいは、「会社ＩＤ」と「従業員ＩＤ」を組み合わせたものと同一であれば、「ユーザＩＤ」項目は不要となる。また、「通知先」は電子メールアドレスが設定されているが、別の通信手段、例えば、電話番号、ＦＡＸ番号とすることも可能である。

Ｓ２５で、通知手段１２０は、アクセスした勤怠ＤＢ３１０内の勤怠テーブル３１００を参照して、該当従業員ＩＤの残業時間が「付帯条件」に設定される残業条件に一致するか否かを判定する。

判定の結果、「付帯条件」の残業条件に一致する場合、通知手段１２０は、Ｓ２６へ進み、読み込んだ通知テーブル１６００のレコードの「状態」項目を「未定」から「確定」へ変更する。一方、残業条件に一致しない場合、通知手段１２０は、「状態」項目を変更しないまま、Ｓ２７へ進む。

図８に勤怠テーブル３１００を例示する。勤怠テーブル３１００は、「日付」、「勤務種別」（非出勤日の場合は「休日」）、「出勤時刻」、「退勤時刻」、「残業時間」で構成される。

例えば、図７に例示するユーザＩＤ「Ｕ００１」の通知テーブル１６００の「付帯条件」項目を参照すると、「２００４年５月２４日」の残業時間の最低時間が「３時間」となっている。したがって、通知手段１２０は、図８の勤怠テーブル３１００の日付が「２００４年５月２４日」の「残業時間」項目を参照する。すると、該当日の残業時間が「４時間」となっている。このため、通知手段１２０は、図７に例示する通知テーブル１６００の「状態」項目を「確定」へ変更することになる。

次にＳ２７で、通知手段１２０は、読み込んだ通知テーブル１６００のレコードの「通知設定」項目に設定された日時情報にサーバ１００のシステム日時が達したか否かを判定する。そして、設定された日時情報に達したと判定した場合、通知手段１２０は、Ｓ２８へ進む。一方、達していないと判定した場合、通知手段１２０はＳ３１へと進む。

Ｓ２８で、設定された日時情報にシステム日時が達したと判定した通知手段１２０は、読み込んだ通知テーブル１６００のレコードの「状態」項目が「確定」であるか否かを判定する。そして、「確定」であれば、通知手段１２０はＳ２９へ進み、「未定」であればＳ３０へ進む。

Ｓ２９で、設定された日時情報に達し、しかも、通知条件を満していると判定された通知テーブル１６００のレコードに関して、通知手段１２０は、当該レコードに対応するユーザの連絡先へ、該当するスケジュールを電子メールで連絡する。

すなわち、通知手段１２０は、利用者テーブル１３００を参照し、現在読み込み中のレコードに対応するユーザのレコードを「ユーザＩＤ」から識別し、そのレコードの「通知先」から当該ユーザのメールアドレスを特定する。

さらに、通知手段１２０は、現在読み込んでいる通知テーブル１６００のレコードの「予定ＩＤ」に基づき、予定テーブル１４００の該当レコードからスケジュール内容を特定する。

このように、通知手段１２０は、通知先と通知対象であるスケジュールを把握した上で、通知メールを作成し、通知先である携帯端末２００のメール手段２２０に向けて通知メールを送信する。

図１０に、通知手段１２０が作成する通知メール例を示す。関連付けアラーム設定の通知メール３１００と、通常のアラーム設定の通知メール３２００とでは、その内容を区別することが望ましい。通知手段１２０が、両者のアラーム設定を区別するには、通知テーブル１６００の「関連ＩＤ」にスケジュール識別子が格納されるか否かで識別する。

関連付けアラーム設定の通知メール３１００では、通知対象のスケジュールとともに、現在実施中のスケジュール（図１０の例では「接待」）に触れているが、これは、通知手段１２０が、現在読み込み中レコードの「関連ＩＤ」に基づき、予定テーブル１４００内の「予定ＩＤ」が同一の値を有するレコードの「種別」項目を特定することで表示可能である。また、「内容」項目、つまり、具体的なスケジュール内容を通知しても良い。

通常のアラーム設定の通知メール３２００では、通知対象のスケジュールとともに、現在日時から当該スケジュールの開始日時までの差分時間を示す。これは、通知手段１２０が現在読み込み中レコードの「予定ＩＤ」項目に格納される値と同一のレコードを、予定テーブル１４００の「予定ＩＤ」から特定し、当該レコードから「日付」項目および「開始時刻」項目の日時とシステム日時の差分から算出することで表示可能である。

図３に戻って、Ｓ３０で、通知手段１２０は、現在読み込でいるレコードを通知テーブル１６００から削除する。これは、Ｓ２７の段階で、現在既に「通知設定」日時に達しているため、付帯条件が満されたか否かに拘らず、これ以上必要ないレコードだからである。但し、この時、ログ情報として別ファイルに削除対象レコードを保存してもよい。

Ｓ３１で、通知手段１２０は、通知ＤＢ１６０内の全通知テーブル１６００の全レコードについて処理を終了したか否かを判定し、まだ終了していない場合は、Ｓ３２へ進み、次レコード、もしくは、まだ処理していない他ユーザＩＤの通知テーブル１６００の先頭レコードを読み込み、Ｓ２２以降の判定処理を繰り返す。

一方、全て終了した場合は、通知手段１２０は、一連の通知処理を終了することになる。但し、この時、まだサーバ１００の稼動時間中であれば、通知手段１２０は、再び、最初に処理したユーザＩＤの通知テーブル１６００の先頭レコードに戻って、通知処理を続行することになる。

尚、一旦登録したスケジュールを変更される場合は、予定登録手段１１０が、変更されるべきスケジュールについて、予定ＤＢ１４０、条件ＤＢ１５０、通知ＤＢ１６０から「予定ＩＤ」項目が変更されるべきスケジュール識別子であるレコードを一旦削除した上で、変更された内容のスケジュールを改めて新規に登録する。

また、削除要求のあるスケジュールについても、予定登録手段１１０が、該当スケジュールに関するレコードを削除する。また、変更されるべきスケジュールあるいは削除されるべきスケジュールが、通知ＤＢ１６０の「関連ＩＤ」に設定されているレコードも削除される。

本実施例では、付帯条件を１項目としたが、複数の付帯条件を設定することも可能である。この時は、全ての付帯条件が条件を満たした場合に、通知手段１２０が通知テーブル１６００の「状態」項目を「確定」に変更するようにすればよい。

また、本実施例では、付帯条件をユーザの残業時間としたが、例えば、気象条件とするなど、これ以外の内容でも構わない。

また、本実施例では、通知対象予定および関連予定をユーザ自身が登録したが、ユーザが欠席・遅刻をした予定についてその実績を入力するようにしておき、予定登録手段１１０が、所定回数以上欠席・遅刻が生じた予定の前に頻繁に存在する別の予定を関連予定として自動的に識別し、欠席・遅刻が多い予定とこれに対応する関連予定がある所定期間内に共に存在するスケジュール関係を監視し、自動的に関連予定の実施日時にアラーム通知するようにしてもよい。
（付記１）
ユーザに予定情報を通知する予定通知方法において、
コンピュータが、
前記ユーザについて通知対象となる予定情報である第一の予定、該第一の予定とは異なる第二の予定が対応づけて管理される設定テーブルを参照し、該第二の予定を特定する識別ステップと、
予定情報とその日時情報が管理される予定テーブルを参照し、前記ユーザについて前記第二の予定が存在するか否かを判定する判定ステップと、
前記判定ステップの判定結果が真の場合、前記第二の予定の日時情報に基づいて前記第一の予定を前記ユーザに通知する通知ステップと
を備えることを特徴とする予定通知方法。
（付記２）
前記設定テーブルには、さらに、前記第一の予定と前記第二の予定に関する日時情報の隔たり期間が含まれ、
前記判定ステップは、前記予定テーブルを参照し、前記第一の予定から該隔たり期間内に前記第二の予定が存在するか否かを判定する
ことを特徴とする付記１記載の予定通知方法。
（付記３）
前記設定テーブルには、さらに、前記第二の予定の日時情報を基準にした通知タイミングが含まれ、
前記通知ステップは、前記通知タイミングに基づいて、前記第一の予定を通知する
ことを特徴とする付記１乃至２のいずれかに記載の予定通知方法。
（付記４）
前記設定テーブルには、さらに、前記予定テーブルに管理された予定情報以外の情報に基づいた通知条件が含まれ、
前記判定ステップは、さらに、前記第二の予定の存在有無とともに前記通知条件も満たしているか否かを判定する
ことを特徴とする付記１乃至３のいずれかに記載の予定通知方法。

本発明の実施例における、システム構成例を示す図である。 本発明の実施例における、予定登録処理フローを示す図である。 本発明の実施例における、通知処理フローを示す図である。 本発明の実施例における、利用者テーブルを示す図である。 本発明の実施例における、予定テーブルを示す図である。 本発明の実施例における、条件テーブルを示す図である。 本発明の実施例における、通知テーブルを示す図である。 本発明の実施例における、勤怠テーブルを示す図である。 本発明の実施例における、予定登録画面を示す図である。 本発明の実施例における、通知画面を示す図である。

符号の説明

１００ サーバ
１１０ 予定登録手段
１２０ 通知手段
１３０ 利用者ＤＢ（データベース）
１４０ 予定ＤＢ（データベース）
１５０ 条件ＤＢ（データベース）
１６０ 通知ＤＢ（データベース）
２００ 携帯端末
２１０ 閲覧手段
２１０ メール手段
３００ 勤怠管理システム
３１０ 勤怠ＤＢ（データベース）
４００・４１０ ネットワーク
１３００ 利用者テーブル
１４００ 予定テーブル
１５００ 条件テーブル
１６００ 通知テーブル
３１００ 勤怠テーブル
２１００ 予定登録画面
３１００、３２００ 通知画面

Claims (3)

1. ユーザに予定情報を通知する予定通知方法において、
   コンピュータが、
   前記ユーザについて通知対象となる予定情報である第一の予定、該第一の予定とは異なる第二の予定が対応づけて管理される設定テーブルを参照し、該第二の予定を特定する識別ステップと、
   予定情報とその日時情報が管理される予定テーブルを参照し、前記ユーザについて前記第二の予定が存在するか否かを判定する判定ステップと、
   前記判定ステップの判定結果が真である場合、前記第二の予定の日時情報に基づいて前記第一の予定を前記ユーザに通知する通知ステップと
   を備えることを特徴とする予定通知方法。
2. 前記設定テーブルには、さらに、前記第一の予定と前記第二の予定に関する日時情報の隔たり期間が含まれ、
   前記判定ステップは、前記予定テーブルを参照し、前記第一の予定から該隔たり期間内に前記第二の予定が存在するか否かを判定する
   ことを特徴とする請求項１記載の予定通知方法。
3. 前記設定テーブルには、さらに、前記第二の予定の日時情報を基準にした通知タイミングが含まれ、
   前記通知ステップは、前記通知タイミングに基づいて、前記第一の予定を通知する
   ことを特徴とする請求項１乃至２のいずれかに記載の予定通知方法。
   
   
   

Images