コールシステム
【課題】呼出し時刻になったときに、サーバに予定が登録された複数の相手から、呼出し対象となる相手を抽出して、自動的に呼出し及び再呼出しを行う。
【解決手段】回線通信制御部２５と着信回線通信制御部２６を実装した音声ボード１７を具備したサーバ１５と、サーバ１５に接続された作業者端末１４とを備え、サーバ１５では、スタッフ情報管理部２０は、作業者端末１４からスタッフ情報データベース３１の情報を登録し、運行テーブル作成部２１は、運行テーブル３２を作成する処理を行い、回線割当部２２は、回線毎プロセスカウンタ３３を参照しカウンタ数が最少の回線を選択し、呼出しプロセスと再呼出しプロセスを当該回線用のプロセス管理テーブル３４に同時に登録する。
【解決手段】回線通信制御部２５と着信回線通信制御部２６を実装した音声ボード１７を具備したサーバ１５と、サーバ１５に接続された作業者端末１４とを備え、サーバ１５では、スタッフ情報管理部２０は、作業者端末１４からスタッフ情報データベース３１の情報を登録し、運行テーブル作成部２１は、運行テーブル３２を作成する処理を行い、回線割当部２２は、回線毎プロセスカウンタ３３を参照しカウンタ数が最少の回線を選択し、呼出しプロセスと再呼出しプロセスを当該回線用のプロセス管理テーブル３４に同時に登録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼出し時刻になったときに、自動的に発呼するコールシステムであって、特に、サーバに予定が登録された複数の相手から、呼出し対象となる相手を抽出して、呼出し及び再呼出しを行うコールシステムに関する。
【背景技術】
【０００２】
バス、ハイヤー等のドライバー或いは派遣スタッフ（以下総称して単にスタッフという）の起床確認には、事務所に待機している管理者に電話をかけて起床或いは管理者側からスタッフに電話をかけて起床を確認する。
【０００３】
例えば特許文献１は、インターネット網を介してユーザ端末とサービス提供サーバとが接続されてなるモーニングコールサービスシステムである。
【０００４】
このモーニングコールサービスシステムは、予め記憶されているスケジュールの日時になったときに、相手に電話をかけて音声ガイダンスを流し、相手の音声から相手が完全におきたかどうかを判断する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４０５５３７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の通り、従来のモーニングコールシステムは、予め指定した起床予定時刻に電話機のベル（着信音）を鳴動させることにより起床を促すものであるため、 受話器を持ち上げて直ぐに元の位置に戻してしまった場合には、ユーザが完全に起床したのかどうかを確認できないといった問題点があった。
【０００７】
特許文献１では、その解決策として、相手が電話に応答した際に、相手の音声を認識して起床を確認する手法を採用している。
【０００８】
しかし、目覚まし時計のアラームが鳴ると、そのときはしっかり起きてアラームを止める操作を行うが、それが済むとまた眠ってしまうことがある場合と同様に、呼び出されるなど外部からの刺激に対しては、条件反射のように対応してしまうことがある。
【０００９】
したがって、相手が電話に応答した際の対応を確認しただけでは、その後確実に起床したかを判断することは難しく、電話への対応を完了した後に、相手が何らかの動作を自発的に行ったことを確認することで、確実に起床したと判断することが望ましい。
【００１０】
また、コンピュータ内部での確認のみでは、起床を確認できないままに放置され、支障をきたす場合があり得る。予定作業時間が過ぎたあとにコンピュータの保守者が確認しても意味がないため、呼出し状況をリアルタイムに監視できる機能が必要となる。
【００１１】
さらに、公衆電話網の回線を利用するシステムでは、システムに実装できる回線数は無制限ではないため、限られた回線を効率的に使用して、遅延を最小限にして多くの呼出しができる仕組みが必要となる。
【課題を解決するための手段】
【００１２】
本発明のコールシステムは、スタッフ電話機及び管理者携帯電話機と通信を行うために、電話網に接続された複数の回線通信制御部と着信回線通信制御部を実装した音声ボード、カレンダー、一次メモリ及び二次メモリを具備したサーバと、サーバに接続された作業者端末とを備えたコールシステムである。
【００１３】
本発明のコールシステムのサーバは、作業者端末から、呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースとして二次メモリに登録するためのスタッフ情報管理部と、カレンダーから日時を取得し、当該日時から所定期間内に該当する呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースから抽出し、一次メモリに運行テーブルを作成する運行テーブル作成部と、所定間隔でカレンダーから現時刻を取得し、当該現時刻から呼出し時刻に達するスタッフ情報を検出するとともに、一次メモリの回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択し、発呼処理部の呼出しプロセスを再呼出しプロセスとして、それぞれのプロセス識別子を当該回線用のプロセス管理テーブルに同時に登録し、回線毎プロセスカウンタの当該回線用のカウンタ数に２を加算する回線割当部と、プロセス管理テーブルに登録された呼出しプロセスと再呼出しプロセスを並列して起動し、起動した呼出しプロセスと再呼出しプロセスから受信するイベントが、（１）呼出し前自己申告ありの場合、呼出しプロセスのプロセス識別子と、当該呼出しプロセスに対応する再呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から２を減算し、（２）呼出し終了の場合、呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から１を減算し、（３）再呼出し前自己申告あり及び再呼出し終了の場合、再呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から１を減算するプロセス管理部と、プロセス管理部から起動された呼出しプロセスと再呼出しプロセスのそれぞれのプロセス識別子に含まれるスタッフ番号に該当するスタッフ情報を運行テーブルから読み出し、当該スタッフ情報のスタッフ状況が自己申告ありの場合、呼出し前自己申告ありイベントまたは再呼出し前自己申告ありイベントをプロセス管理部に送信し、当該スタッフ情報のスタッフ状況が自己申告なしの場合、一次メモリの回線使用状況テーブルを参照し、指定回線が空きならば、回線使用状況テーブルを使用に変更し、当該スタッフ情報に設定されたスタッフ電話番号に回線通信制御部から所定回数発呼を繰り返し、所定回数に達した時または応答時に呼出
し終了イベントまたは再呼出し終了イベントをプロセス管理部に送信し、処理によりスタッフ状況に変化が生じると、スタッフ番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する発呼処理部と、着信回線通信制御部から着信呼情報を受信すると、当該着信呼情報内の発信者電話番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する自己申告受信部と、発呼処理部、及び自己申告受信部から、それぞれスタッフ識別情報としてスタッフ番号及び発信者電話番号とともに送信されたスタッフ状況更新要求により、当該スタッフ識別情報に該当する運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、作業者端末にスタッフ状況を通知するスタッフ状況更新部とを含むことを要旨とする。
【発明の効果】
【００１４】
以上のように本発明によれば、相手が自発的に行った自己申告があったことを確認できるまで、呼出しと再呼出しを行うので、確実に起床したことを確認できる。
【００１５】
また、本発明によれば、サーバから呼出し状況（スタッフ状況）をリアルタイムに作業者端末に通知し、画面に表示させるので、常に呼出し状況を監視できる。
【００１６】
さらに、本発明によれば、割り当てられたプロセス数が最少の回線を選択して、呼出しプロセスと再呼出しプロセスを同時に割当てるので、回線を効率的に使用し、遅延を最小限にして多くの呼出しができる。
【図面の簡単な説明】
【００１７】
【図１】実施の最良の形態のコールシステムの概略構成図
【図２】実施の最良の形態のサーバの構成図
【図３】実施の最良の形態のスタッフ情報データベースの構成図
【図４】実施の最良の形態の運行テーブルの構成図
【図５】呼出し前までのシステム全体のシーケンス図
【図６】呼出しにスタッフが全く応答しない場合のシステム全体のシーケンス図
【図７】再呼出しにスタッフが全く応答しない場合のシステム全体のシーケンス図
【図８】呼出しに応答した場合のシステム全体のシーケンス図
【図９】再呼出しに応答した場合のシステム全体のシーケンス図
【図１０】呼出し前に自己申告があった場合のシステム全体のシーケンス図
【図１１】呼出しにスタッフが全く応答しない場合のイメージ図
【図１２】作業者端末に表示される画面のイメージ図
【図１３】スタッフが全く応答しない場合のサーバ内シーケンス図
【図１４】スタッフが全く応答した場合のサーバ内シーケンス図
【図１５】呼出し前に自己申告があった場合のサーバ内シーケンス図
【図１６】呼出しに応答後に自己申告あった場合のサーバ内シーケンス図
【図１７】プロセス間制御シーケンス図
【図１８】運行テーブル作成部のフローチャート
【図１９】回線割当部のフローチャート
【図２０】プロセス管理部のフローチャート
【図２１】プロセス管理部のフローチャート
【図２２】発呼処理部のフローチャート
【図２３】発呼処理部のフローチャート
【図２４】発呼処理部のフローチャート
【図２５】発呼処理部のフローチャート
【図２６】スタッフ状況更新部のフローチャート
【図２７】スタッフ状況更新部のフローチャート
【図２８】第２の実施の形態のコールシステムの概略構成図
【図２９】第２の運行テーブル作成部のフローチャート
【図３０】第３の運行テーブル作成部のフローチャート
【図３１】第２の回線割当部のフローチャート
【発明を実施するための形態】
【００１８】
＜発明の第１の実施の形態＞
本発明の実施の最良の形態のコールシステムは、図１に示すように、電話網１２とインターネット１０に接続され、スタッフ電話機１３及び管理者携帯電話機１１と通信を行うために、電話網１２と接続するための複数の回線通信制御部２５と着信回線通信制御部２６を実装した音声ボード１７と、カレンダー１６と、一次メモリ及び二次メモリとを具備したサーバ１５と、サーバ１５に接続された作業者端末１４とによって構成される。
【００１９】
スタッフ電話機１３は、携帯電話機が望ましいが、固定電話機であっても構わない。
【００２０】
サーバ１５に接続される電話回線は、アナログ電話回線とＩＳＤＮ電話回線のいずれであっても構わず、両方の回線を混在させることも可能であり、それぞれに対応したインターフェースを有する回線通信制御部２５と着信回線通信制御部２６を音声ボード１７に実装する。
【００２１】
回線通信制御部２５は、サーバ１５から指定された電話番号に自動で発呼する機能を有し、相手からの応答信号を検出してサーバ１５に通知し、サーバ１５の指示により通話状態となった電話回線を切断する。
【００２２】
音声ボード１７は、相手からの応答信号を検出した際に、サーバ１５から指定された音声応答情報を再生して相手に聞かせる機能を有する。
【００２３】
着信回線通信制御部２６は、相手からの呼に対して自動応答するとともに、相手の電話番号（発信者電話番号）を受信してサーバ１５に通知する機能を有する。
【００２４】
図２のサーバ１５の構成図において、一次メモリ及び二次メモリを明示していないが、一次メモリには、運行テーブル３２、回線毎プロセスカウンタ３３、プロセス管理テーブル３４、及び回線使用状況テーブル３５が作成される。二次メモリには、スタッフ情報データベース３１が構築される。
【００２５】
さらに、図２に示すように、サーバ１５には、スタッフ情報管理部２０、運行テーブル作成部２１、回線割当部２２、プロセス管理部２３、発呼処理部２４、自己申告受信部２７、電子メール送受信部２８、スタッフ状況更新部２９、設定変更部３０が含まれる。
【００２６】
（データ構成）
スタッフ情報データベース３１には、図３に例示すように、スタッフ基本データ３１１とスタッフ予定データ３１２が含まれる。
【００２７】
スタッフ基本データ３１１には、全スタッフについて、スタッフ識別情報となるスタッフ番号Ｍと、スタッフメールアドレスＳａと、スタッフ電話番号Ｄが登録され、さらに、本コールシステムによって呼び出した時に各スタッフに聞かせるメッセージを、呼出し時音声応答情報Ｃｍ及び再呼出し時音声応答情報Ｒｍとして登録できる。
【００２８】
また、必要時に管理者に電子メールで通知できるように、各スタッフの管理者のメールアドレス（管理者メールアドレスＫａ）をスタッフ基本データ３１１に登録しておく。
【００２９】
スタッフ予定データ３１２には、各スタッフの一定期間（一週間や一ヶ月など）の勤務予定に従い、呼出し日付ｄｄと呼出し時刻Ｔｐ及び再呼出し時刻Ｔｑを登録する。
【００３０】
スタッフ毎に作成されるスタッフ予定データ３１２は、スタッフ番号Ｍをテーブル名に付与するなどして、各スタッフのスタッフ基本データ３１１にリンクさせておく。
【００３１】
なお、再呼出し時刻Ｔｑは、呼出し時刻Ｔｐに近過ぎたり、呼出し時刻Ｔｐから離れ過ぎたりすると効果がないので、呼出し時刻Ｔｐを登録する際に、呼出し時刻Ｔｐから一定時間（例えば１５分）後になるように、システムが自動設定するのが好ましい。
【００３２】
運行テーブル３２には、図４に例示すように、スタッフ情報データベース３１に登録された情報のうち、スタッフ番号Ｍと、スタッフメールアドレスＳａと、スタッフ電話番号Ｄと、呼出し時音声応答情報Ｃｍと、再呼出し時音声応答情報Ｒｍと、管理者メールアドレスＫａと、呼出し当日の呼出し時刻Ｔｐ及び再呼出し時刻Ｔｑが設定される。
【００３３】
さらに、運行テーブル３２には、スタッフの状況を示すスタッフ状況フラグ欄Ｆが設けられ、呼出しフラグＦ１、呼出し応答フラグＦ２、再呼出しフラグＦ３、再呼出し応答フラグＦ４、自己申告フラグＦ５が含まれる。
【００３４】
自己申告フラグＦ５は、スタッフが起床したことを自ら連絡してきたときに１が設定される。呼出しフラグＦ１は、システムが呼出し時刻Ｔｐにスタッフに発呼したときに１が設定され、呼出し応答フラグＦ２は、その呼出しにスタッフが応答したときに１が設定される。
【００３５】
再呼出しフラグＦ３は、システムが再呼出し時刻Ｔｑにスタッフに発呼したときに１が設定され、再呼出し応答フラグＦ４は、その再呼出しにスタッフが応答したときに１が設定される。
【００３６】
回線毎プロセスカウンタ３３には、図２に例示するように、回線番号とその回線に割当てられている発呼処理部２４のプロセスの数を示す回線毎のデータが設定されている。
【００３７】
プロセス管理テーブル３４は、図２に例示するように、回線毎に作成される。プロセス管理テーブル３４には、生成された発呼処理部２４のプロセスを識別するプロセス識別子（ＰＩＤ）が登録される。
【００３８】
プロセス識別子には、呼出しプロセスの呼出しプロセス識別子と、再呼出しプロセスの再呼出しプロセス識別子があり、各プロセスがどのスタッフのためのプロセスであるかが識別できるように、プロセス識別子を生成する。
【００３９】
具体的には、スタッフのスタッフ番号Ｍを利用すると同時に、呼出し用か再呼出し用かを区別できるように、例えばプロセス識別子の最後に、呼出しプロセスには“Ｃ”、また再呼出しプロセスには“Ｒ”を付与する。この作成方法に従って、スタッフ番号０１のスタッフの呼出しプロセス識別子は“０１Ｃ”、再呼出しプロセス識別子は“０１Ｒ”となる。
【００４０】
回線使用状況テーブル３５には、図２に例示するように、回線番号とその回線が空きか使用中かを示す回線毎のデータが設定されている。これは、同一の回線を使用しようとしている複数のプロセス間で排他制御を行うために用いられる。
【００４１】
（各処理部の機能）
スタッフ情報管理部２０は、作業者端末１４からスタッフ情報データベース３１の情報を二次メモリに登録する処理を行う。
【００４２】
運行テーブル作成部２１は、カレンダー１６から現日時を取得し、呼出し日付ｄｄと呼出し時刻Ｔｐが現日時から所定期間内（例えば２４時間）に該当するスタッフの情報をスタッフ情報データベース３１から抽出し、一次メモリに運行テーブル３２を作成する処理を行う。
【００４３】
回線割当部２２は、所定周期（例えば１分）毎に、カレンダー１６から現時刻を取得し、現時刻と比較して、呼出し時刻Ｔｐに達するスタッフ情報を検出するとともに、回線毎プロセスカウンタ３３を参照しカウンタ数が最少の回線を選択し、発呼処理部２４のプロセスとして、呼出しプロセス識別子と再呼出しプロセス識別子を当該回線用のプロセス管理テーブル３４に同時に登録し、回線毎プロセスカウンタ３３の当該回線用のカウンタに２を加算する処理を繰り返し行う。
【００４４】
プロセス管理部２３は、プロセス管理テーブル３４に登録された発呼処理部２４のプロセスを並列して起動する一方、プロセスが終了する際に、プロセスから送信されるイベントの種類に従い、プロセス管理テーブル３４から該当するプロセスを削除するとともに、削除したプロセスの数だけ回線毎プロセスカウンタ３３のカウンタから減算する処理を行う。
【００４５】
発呼処理部２４は、プロセス管理部２３から起動されたプロセスのプロセス識別子に含まれるスタッフ番号Ｍにより、運行テーブル３２から該当するスタッフ情報を読み出し、自己申告フラグＦ５が１の場合はプロセスを終了し、自己申告フラグＦ５が０の場合は、回線使用状況テーブル３５を参照し、指定回線が空きならば、スタッフ情報に設定されたスタッフ電話番号Ｄに回線通信制御部２５から所定回数（例えば３回）発呼を繰り返し、所定回数に達した時または応答時にプロセスを終了する処理を行う。
【００４６】
発呼処理部２４は、プロセスを終了する際に、「待ち状態」、「呼出し前自己申告あり」、「呼出し終了」、「再呼出し前自己申告あり」、及び「再呼出し終了」の終了要因を示すイベントをプロセス管理部２３に送信する処理を行う。
【００４７】
また、発呼処理部２４は、プロセスの処理に伴って、スタッフの状況が変化する際に、「呼出し中」、「呼出し応答」、「呼出し応答なし」、「再呼出し中」、「再呼出し応答」、及び「再呼出し応答なし」のスタッフ状況更新要求を、スタッフ識別情報としてのスタッフ番号Ｍとともにスタッフ状況更新部２９に通知する処理も行う。
【００４８】
自己申告受信部２７は、着信回線通信制御部２６から着信呼情報を受信し、着信呼情報内の発信者電話番号をスタッフ識別情報としてスタッフ状況更新部２９に送信する処理を行う。
【００４９】
電子メール送受信部２８は、インターネット１０経由で受信した電子メールの発信元メールアドレスをスタッフ識別情報としてスタッフ状況更新部２９に送信するとともに、スタッフ状況更新部２９からの要求により管理者携帯電話機１１に督促メールを送信する処理を行う。
【００５０】
スタッフ状況更新部２９は、発呼処理部２４、自己申告受信部２７、及び電子メール送受信部２８からスタッフ識別情報とともに送信させたスタッフ状況更新要求により、当該スタッフ識別情報に該当する運行テーブル３２のスタッフ情報を更新する処理と、更新時に更新したスタッフ情報を作業者端末１４に通知する処理を行う。
【００５１】
また、スタッフ状況更新部２９は、発呼処理部２４から「呼出し応答なし」及び「再呼出し応答なし」のスタッフ状況更新要求を受信した場合は、管理者携帯電話機１１への督促メール送信を電子メール送受信部２８に要求する処理を行う。
【００５２】
設定変更部３０は、作業者端末１４から運行テーブル３２のスタッフ情報を変更する処理を行う。
【００５３】
（システム全体のシーケンス）
図５に示すように、まず、作業者は、作業者端末１４からサーバ１５にアクセスし（ｄ１）、スタッフ情報管理部２０によりスタッフ情報をスタッフ情報データベース３１に登録しておく（ｄ２）。
【００５４】
サーバ１５の運行テーブル作成部２１は、所定時刻（例えば毎日０時）になると、カレンダー１６から現日付を取得し、登録させている呼出し日時と現日付と比較して、該当するスタッフ情報をスタッフ情報データベース３１から抽出する（ｄ３）。
【００５５】
サーバ１５の運行テーブル作成部２１は、抽出したスタッフ情報にスタッフ状況フラグ欄Ｆを付加して運行テーブル３２を作成する（ｄ４）。
【００５６】
サーバ１５の回線割当部２２は、所定周期（例えば１分）毎に、カレンダー１６から現時刻を取得し、登録させている呼出し時刻Ｔｐと現時刻と比較して、運行テーブル３２から呼出し時刻Ｔｐになるスタッフを検出する（ｄ５）。
【００５７】
つづいて、サーバ１５の回線割当部２２は、回線毎プロセスカウンタ３３を参照して、プロセス数が最少の回線を選択し、当該回線のカウンタに２を加算する（ｄ６）。
【００５８】
サーバ１５の回線割当部２２は、発呼処理部２４のプロセスとして、呼出しプロセス識別子と再呼出しプロセス識別子を当該回線用のプロセス管理テーブル３４に同時に登録する（ｄ７）。
【００５９】
サーバ１５の回線割当部２２は、検出したスタッフ全員についてプロセスの登録処理を繰返す（ｄ８）。
【００６０】
さらに、サーバ１５の回線割当部２２は、上記の処理を所定周期（例えば１分）毎に繰返し行う（ｄ９）。
【００６１】
ここで、サーバ１５のプロセス管理部２３は、呼出しプロセスと再呼出しプロセスを区別せずに実行する。しかし、プロセス内で発呼処理を行う時刻に達したか判定するので、同一のスタッフの呼出しプロセスと再呼出しプロセスでは、呼出し時刻Ｔｐが再呼出し時刻Ｔｑより早いため、まず呼出しプロセスが発呼することになる。
【００６２】
一方、再呼出しプロセスは、サーバ１５のプロセス管理部２３によりいったん実行状態に移行されても、再呼出し時刻Ｔｑになっていないため実行待ち状態に戻る。
【００６３】
したがって、同一のスタッフについて、時系列に従って、まず呼出しプロセスが実行され、その後に再呼出しプロセスが実行されるシーケンスを、場合分けしながら説明する。
【００６４】
（ケース１：応答なし）
まず、呼出し及び再呼出しに応答がない場合のシーケンスについて、図６と図７を参照しながら説明する。スタッフから全く応答がない場合の流れのイメージを図１１に例示し、また、作業者端末１４に表示される画面イメージを図１２に例示する。
【００６５】
図１２に例示した作業者端末１４に表示される初期情報は、サーバ１５の運行テーブル作成部２１が、運行テーブル３２の作成が完了した時点で作業者端末１４に送信するなど、運行テーブル３２に従って当日の呼出しが開始される前に作業者端末１４に送信しておく。
【００６６】
図６に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ１０）。
【００６７】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ１１）。
【００６８】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５により、既に自己申告があったかどうかを判定する（ｄ１２）。
【００６９】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ１３）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ１３ａ）。
【００７０】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し」に更新させ、作業者端末１４に通知させる（ｄ１４）。作業者端末１４では、該当スタッフの状況に「呼出し」が表示される（ｄ１４ａ）。
【００７１】
サーバ１５の発呼処理部２４は、一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待つ（ｄ１５）。
【００７２】
サーバ１５の発呼処理部２４は、もし応答がなければ、所定間隔（例えば３０秒）後に、スタッフ電話番号Ｄに回線通信制御部２５によって再度発呼し（ｄ１６）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ１６ａ）。
【００７３】
サーバ１５の発呼処理部２４は、また一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待ち（ｄ１７）、もし応答がなければ、上記の呼出しを所定回数（例えば３回）まで繰り返す（ｄ１８）。
【００７４】
サーバ１５の発呼処理部２４は、所定回数呼出しても応答がない場合、スタッフ状況更新部２９に「呼出し応答なし」を通知し、作業者端末１４に通知させると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信させる（ｄ１９）。作業者端末１４では、該当スタッフの状況に「呼出し応答なし」が表示される（ｄ１９ａ）。
【００７５】
サーバ１５の発呼処理部２４は、「呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ２０）。
【００７６】
以上の呼出しの流れは、図１１の（ａ）に例示したようになり、管理者は、送信されてきた督促メールに記載されたスタッフ電話番号Ｄに発呼し（ｄ１９ｂ）、スタッフを呼出し（ｄ１９ｃ）、起床を確認した場合は、自己申告させるか、督促メールに記載されたＵＲＬにアクセスする。
【００７７】
つぎに、図７に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ２１）。
【００７８】
サーバ１５の発呼処理部２４は、再呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ２２）。
【００７９】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ２３）。
【００８０】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ２４）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ２４ａ）。
【００８１】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し」に更新させ、作業者端末１４に通知させる（ｄ２５）。作業者端末１４では、該当スタッフの状況に「再呼出し」が表示される（ｄ２５ａ）。
【００８２】
サーバ１５の発呼処理部２４は、一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待つ（ｄ２６）。
【００８３】
サーバ１５の発呼処理部２４は、もし応答がなければ、所定間隔（例えば３０秒）後に、スタッフ電話番号Ｄに回線通信制御部２５によって再度発呼し（ｄ２７）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ２７ａ）。
【００８４】
サーバ１５の発呼処理部２４は、また一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待ち（ｄ２８）、もし応答がなければ、上記の呼出しを所定回数（例えば３回）まで繰り返す（ｄ２９）。
【００８５】
サーバ１５の発呼処理部２４は、所定回数呼出しても応答がない場合、スタッフ状況更新部２９に「再呼出し応答なし」を通知し、作業者端末１４に通知させると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信させる（ｄ３０）。作業者端末１４では、該当スタッフの状況に「再呼出し応答なし」が表示される（ｄ３０ａ）。
【００８６】
サーバ１５の発呼処理部２４は、「再呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ３１）。
【００８７】
以上の再呼出しの流れは、図１１の（ｂ）に示したようになり、管理者は、送信されてきた督促メールに記載されたスタッフ電話番号Ｄに発呼し（ｄ３０ｂ）、スタッフを呼出し（ｄ３０ｃ）、起床を確認し、自己申告させる。
【００８８】
なお、督促メールの送信先を管理者携帯電話機１１として説明したが、サーバ１５にインターネットやＬＡＮによって接続できる管理者端末に送信しても構わない。
【００８９】
（ケース２：応答後の自己申告なし）
次に、スタッフから応答がある場合のシーケンスについて、図８と図９を参照しながら説明する。
【００９０】
図８に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ４０）。
【００９１】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ４１）。
【００９２】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ４２）。
【００９３】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ４３）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ４３ａ）。
【００９４】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し」に更新させ、作業者端末１４に通知させる（ｄ４４）。作業者端末１４では、該当スタッフの状況に「呼出し」が表示される（ｄ４４ａ）。
【００９５】
サーバ１５の発呼処理部２４は、一定時間呼出し続けている間に（ｄ４５）、スタッフから応答があると（ｄ４５ａ）、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し応答」に更新させ、作業者端末１４に通知させる（ｄ４６）。作業者端末１４では、該当スタッフの状況に「呼出し応答」が表示される（ｄ４６ａ）。
【００９６】
サーバ１５の発呼処理部２４は、スタッフの予め登録しておいた呼出し時音声応答情報Ｃｍを音声ボード１７に再生させて、スタッフに聞かせた後、回線を切断し、「呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ４７）。
【００９７】
つづいて、図９に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ４８）。
【００９８】
サーバ１５の発呼処理部２４は、再呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ４９）。
【００９９】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ５０）。
【０１００】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ５１）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ５１ａ）。
【０１０１】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し」に更新させ、作業者端末１４に通知させる（ｄ５２）。作業者端末１４では、該当スタッフの状況に「再呼出し」が表示される（ｄ５２ａ）。
【０１０２】
サーバ１５の発呼処理部２４は、一定時間呼出し続けている間に（ｄ５３）、スタッフから応答があると（ｄ５３ａ）、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し応答」に更新させ、作業者端末１４に通知させる（ｄ５４）。作業者端末１４では、該当スタッフの状況に「再呼出し応答」が表示される（ｄ５４ａ）。
【０１０３】
サーバ１５の発呼処理部２４は、スタッフの予め登録しておいた再呼出し時音声応答情報Ｒｍを音声ボード１７に再生させて、スタッフに聞かせた後、回線を切断し、「再呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ５５）。
【０１０４】
一定時間後に、サーバ１５のスタッフ状況更新部２９は、運行テーブル３２のスタッフ状況を「再呼出し応答」に更新したスタッフ情報について、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ５６）。
【０１０５】
サーバ１５のスタッフ状況更新部２９は、もし自己申告がなければ、作業者端末１４にアラームを通知し（ｄ５７）、作業者端末１４では、アラームが表示される（ｄ５７ａ）。
【０１０６】
（ケース３：呼出し前自己申告あり）
最後に、スタッフから自己申告がある場合のシーケンスについて、図１０を参照しながら説明する。
【０１０７】
図１０に示すように、まず、スタッフはスタッフ電話機１３からサーバ１５に接続された着信回線用の電話番号に電話するか、スタッフ電話機１３がＥメール機能を有する携帯電話機であるときは、サーバ１５に割り当てられたメールアドレスにＥメールを送信することで、起床済みであることを自己申告する（ｄ６０）。
【０１０８】
サーバ１５のスタッフ状況更新部２９は、電話の場合、着信回線通信制御部２６から自己申告受信部２７に通知された発信者電話番号を受信し、Ｅメールの場合、電子メール送受信部２８から発信元メールアドレスを受信し、該当のスタッフの運行テーブル３２のスタッフ状況を「自己申告」に更新し、作業者端末１４に通知する（ｄ６１）。作業者端末１４では、該当スタッフの状況に「自己申告」が表示される（ｄ６１ａ）。
【０１０９】
サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ６２）。
【０１１０】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ６３）。
【０１１１】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ６４）。
【０１１２】
サーバ１５の発呼処理部２４は、もし自己申告があれば、「呼出し前自己申告」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から２を減算し、プロセス管理テーブル３４から呼出しプロセスと再呼出しロセスの両方の登録を削除する（ｄ６５）。
【０１１３】
なお、再呼出しプロセスで自己申告があったことを検出した場合は、「再呼出し前自己申告」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス登録を削除する。
【０１１４】
図１２に例示した作業者端末１４の表示画面では、各スタッフの氏名やスタッフ電話番号Ｄの情報とともに、状態を示す丸いサイン（ｋ１、ｋ２、ｋ３、ｋ４、ｋ５、ｋ６、・・・）が表示される。
【０１１５】
例えば、丸いサインは、初期状態では色は付いていないが、スタッフ状況更新部２９から「呼出し」表示の通知を受信すると青色に点滅し始める。このあとスタッフ状況更新部２９から「呼出し応答」表示の通知を受信すると青色に点灯した状態に変わり、もし「呼出し応答なし」表示の通知を受信すると黄色に点灯した状態に変わる。
【０１１６】
さらに、丸いサインは、スタッフ状況更新部２９から「再呼出し」表示の通知を受信すると緑色に点滅し始める。このあとスタッフ状況更新部２９から「再呼出し応答」表示の通知を受信すると緑色に点灯した状態に変わり、もし「再呼出し応答なし」表示の通知を受信するとオレンジ色に点灯した状態に変わる。
【０１１７】
また、丸いサインは、スタッフ状況更新部２９から「自己申告」表示の通知を受信すると黒色に点灯し、アラームを受信すると赤色に点滅する。さらに、作業者端末１４は、アラームを受信した場合は、警告音を鳴らして作業者に注意を促すようにしてもよい。
（サーバ１５内シーケンス）
次に、上記のシステム全体のシーケンスのうち、図６から図１０を参照して説明した発呼処理に関して、サーバ１５内のプロセス管理部２３、発呼処理部２４、及びスタッフ状況更新部２９の間でのシーケンスについて詳細に説明する。
【０１１８】
（ケース１：応答なし）
まず、図６と図７を用いて説明したスタッフが呼出しにも再呼出しにも全く応答しない場合について、図１３を参照しながら、回線１を使用して、スタッフ０１に対する呼出しプロセス識別子が“０１Ｃ”のプロセス（以下、呼出しプロセス０１Ｃという）と、再呼出しプロセス識別子が“０１Ｒ”のプロセス（以下、再呼出しプロセス０１Ｒという）を実行する例を説明する。
【０１１９】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１２０】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１２１】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１２２】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａ（例えば２０秒）の間呼出しを継続する（Ｓ４）。さらに呼出し間隔タイマーＴｂ（例えば３０秒）の間、呼出しをやめ、その後２回目の発呼を行う（Ｓ５）。同様にして、３回目の発呼までを行う（Ｓ６）。
【０１２３】
３回目の発呼によっても、スタッフ０１が応答しないため、呼出しプロセス０１Ｃは、スタッフ状況更新部２９に「呼出し応答なし」を通知し（Ｓ７）、スタッフ状況更新部２９は、作業者端末１４に通知すると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信する（Ｓ７ａ）。
【０１２４】
最後に呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ８）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ８ａ）。
【０１２５】
つづいて、プロセス管理部２３は、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１２６】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１２７】
再呼出しプロセス０１Ｒは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「再呼出し」更新要求を送信し（Ｓ１１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定すると同時に（Ｓ１１ａ）、作業者端末１４に通知する。
【０１２８】
再呼出しプロセス０１Ｒは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ１２）。さらに呼出し間隔タイマーＴｂの間、呼出しをやめ、その後２回目の発呼を行う（Ｓ１３）。同様にして、３回目の発呼までを行う（Ｓ１４）。
【０１２９】
３回目の発呼によっても、スタッフ０１が応答しないため、再呼出しプロセス０１Ｒは、スタッフ状況更新部２９に「再呼出し応答なし」を通知し（Ｓ１５）、スタッフ状況更新部２９は、作業者端末１４に通知すると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信する（ｓ１５ａ）。
【０１３０】
最後に再呼出しプロセス０１Ｒは、プロセス管理部２３に「再呼出し終了」イベントを送信し（Ｓ１６）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ１６ａ）。
【０１３１】
（ケース２：応答後の自己申告なし）
次に、図８と図９を用いて説明した場合であり、スタッフ０１が呼出しに応答したが自己申告がないため、再呼出しが行われ、再呼出しに応答したあとも自己申告がないため、作業者端末１４にアラーム表示される場合について、図１４を参照しながら説明する。
【０１３２】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１３３】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１３４】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１３５】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ４）。
【０１３６】
呼出しプロセス０１Ｃは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２０）、スタッフ状況更新部２９に「呼出し応答」更新要求を送信し（Ｓ２１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定すると同時に（Ｓ２１ａ）、作業者端末１４に通知する。
【０１３７】
最後に呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ２２）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ２２ａ）。
【０１３８】
プロセス管理部２３は、スタッフ０１が応答したかどうかにかかわらず、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１３９】
本発明では、呼出しに応答したスタッフに、電話かＥメールでサーバ１５に自己申告させることで、起床したことを確認する仕組みを採用している。なぜなら、呼出しにいったん応答しても、その後再び眠ってしまうこともあるし、たまたまスタッフ電話機１３が留守番電話モードとなっていて、自動応答してしまっていることも考えられるため、本人に自己申告されることとしている。
【０１４０】
そのため、呼出しに応答があった場合でも、自己申告の有無を確認させるために、再呼出しプロセス０１Ｒを実行させている。
【０１４１】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１４２】
再呼出しプロセス０１Ｒは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「再呼出し」更新要求を送信し（Ｓ１１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定すると同時に（Ｓ１１ａ）、作業者端末１４に通知する。
【０１４３】
再呼出しプロセス０１Ｒは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ１２）。
【０１４４】
再呼出しプロセス０１Ｒは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２３）、スタッフ状況更新部２９に「再呼出し応答」更新要求を送信し（Ｓ２４）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出し応答フラグＦ４に１を設定すると同時に（Ｓ２４ａ）、作業者端末１４に通知する。
【０１４５】
この時、スタッフ状況更新部２９は、再呼出しに応答した後に、スタッフ０１から自己申告があったかを確認する必要があるために、自己申告確認タイマーＴｃ（例えば１０分）を開始させる。
【０１４６】
再呼出しプロセス０１Ｒは、プロセス管理部２３に「再呼出し終了」イベントを送信し（Ｓ２５）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ２５ａ）。
【０１４７】
スタッフ状況更新部２９は、自己申告確認タイマーＴｃがタイムアウトすると、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２６ａ）自己申告の有無を判定し（Ｓ２６）、もし自己申告がなければ、作業者端末１４にアラームを通知する（Ｓ２７）。
【０１４８】
（ケース３：呼出し前自己申告あり）
次に、図１０に示したように、呼出しが行われる前にスタッフから自己申告がある場合について、図１５を参照しながら説明する。
【０１４９】
スタッフ状況更新部２９は、自己申告があった旨の通知を、スタッフ識別情報として発信者電話番号または発信元メールアドレスとともに受信し（Ｓ３０）、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定すると同時に（Ｓ３０ａ）、作業者端末１４に通知する。
【０１５０】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１５１】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１５２】
呼出しプロセス０１Ｃは、自己申告があったならば、プロセス管理部２３に「呼出し前自己申告あり」イベントを送信し（Ｓ３１）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から２を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃと再呼出しプロセス０１Ｒの両方を削除する（Ｓ３１ａ）。
【０１５３】
なぜならば、スタッフ０１からの自己申告が確認できたので、呼出しも再呼出しも不要であるため、この時点で、両方のプロセスを削除してしまう。このように不要となったプロセスを早く削除することで、無駄な回線の捕捉がなくなり、回線を効率的に使用し、遅延を最小限にして多くの呼出しができる。
【０１５４】
（ケース４：呼出し後自己申告あり）
また、スタッフ０１から呼出しに応答した後に自己申告がある場合について、図１６を参照しながら説明する。
【０１５５】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１５６】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１５７】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１５８】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ４）。
【０１５９】
呼出しプロセス０１Ｃは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２０）、スタッフ状況更新部２９に「呼出し応答」更新要求を送信し（Ｓ２１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定すると同時に（Ｓ２１ａ）、作業者端末１４に通知する。
【０１６０】
最後に、呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ２２）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ２２ａ）。
【０１６１】
スタッフ状況更新部２９は、自己申告があった旨の通知を、スタッフ識別情報として発信者電話番号または発信元メールアドレスとともに受信し（Ｓ３０）、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定すると同時に（Ｓ３０ａ）、作業者端末１４に通知する。
【０１６２】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１６３】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１６４】
再呼出しプロセス０１Ｒは、自己申告があったならば、プロセス管理部２３に「再呼出し前自己申告あり」イベントを送信し（Ｓ４０）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ４０ａ）。
【０１６５】
（プロセス間制御シーケンス）
本発明では、プロセス管理テーブル３４に登録された呼出しプロセスも再呼出しプロセスも、プロセス管理部２３により、順次実行状態に移行させるため、複数の呼出しプロセスと再呼出しプロセスが同時に進行することになる。
【０１６６】
そこで、複数の呼出しプロセスと再呼出しプロセス間で、どのように実行制御されるかについて、図１７を参照しながら、例として、同じ呼出し時刻Ｔｐの呼出しプロセス０１Ｃと呼出しプロセス０５Ｃ、同じ再呼出し時刻Ｔｑとなる再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒが回線１用のプロセス管理テーブル３４に登録されている場合について説明する。
【０１６７】
まず、プロセス管理部２３は、発呼処理部２４の呼出しプロセス０１Ｃ、呼出しプロセス０５Ｃ、再呼出しプロセス０１Ｒ、及び再呼出しプロセス０５Ｒを順次実行させる。
【０１６８】
呼出しプロセス０１Ｃは、呼出し時刻Ｔｐになっているか判定し（Ｓ５０）、呼出し時刻Ｔｐになっている場合は、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１６９】
回線が空いている場合、呼出しプロセス０１Ｃは、回線使用状況テーブル３５の回線１のデータを１（使用）に変更し（Ｓ５２）、発呼処理を続行する（Ｓ５３）。
【０１７０】
一方、呼出しプロセス０５Ｃも、同様に、呼出し時刻Ｔｐになっているか判定するが（Ｓ５０）、呼出しプロセス０１Ｃと同じ呼出し時刻Ｔｐであるので、当然呼出し時刻Ｔｐになっているため、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１７１】
しかし、既に呼出しプロセス０１Ｃによって、回線使用状況テーブル３５の回線１のデータは１に変更されているので、呼出しプロセス０５Ｃは回線を使用することができないため、呼出しプロセス０５Ｃの状態を待ち状態に戻す。
【０１７２】
再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒは、再呼出し時刻Ｔｑになっているか判定し（Ｓ６０）、再呼出し時刻Ｔｑになっていないため、それぞれの状態を待ち状態に戻す。
【０１７３】
プロセス管理部２３は、呼出しプロセス０５Ｃ、再呼出しプロセス０１Ｒ、及び再呼出しプロセス０５Ｒを、再び実行させることを繰り返す。
【０１７４】
この間、呼出しプロセス０１Ｃは、発呼処理を終了し、回線使用状況テーブル３５の回線１のデータを０（空）に変更し（Ｓ５４）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する。
【０１７５】
この後に、再び実行された呼出しプロセス０５Ｃは、呼出し時刻Ｔｐになっているか判定し（Ｓ５０）、呼出し時刻Ｔｐになっているため、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１７６】
既に終了した呼出しプロセス０１Ｃによって、回線使用状況テーブル３５の回線１のデータは０に変更されているので、呼出しプロセス０５Ｃは回線を使用することができるようになり、発呼処理を行う（Ｓ５３）。
【０１７７】
呼出しプロセス０５Ｃは、発呼処理を終了し、回線使用状況テーブル３５の回線１のデータを０（空）に変更し（Ｓ５４）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０５Ｃを削除する。
【０１７８】
残っている再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒは、再び再呼出し時刻Ｔｑになっているか判定し（Ｓ６０）、再呼出し時刻Ｔｑになるまで、実行状態と待ち状態を繰り返し、再呼出し時刻Ｔｑになった時点で、上記の呼出しプロセス０１Ｃと呼出しプロセス０５Ｃと同様に排他制御を行いながら、それぞれ発呼処理を実行することになる。
【０１７９】
（各部の詳細処理フロー）
以下に、サーバ１５に含まれるスタッフ情報管理部２０、運行テーブル作成部２１、回線割当部２２、プロセス管理部２３、発呼処理部２４、自己申告受信部２７、電子メール送受信部２８、スタッフ状況更新部２９、設定変更部３０の詳細処理について説明する。
【０１８０】
スタッフ情報管理部２０は、作業者端末１４から入力されるスタッフ情報を、図３に例示したスタッフ情報データベース３１に登録する。また、スタッフ情報データベース３１内のデータの変更、表示も作業者端末１４からの要求により行う。
【０１８１】
図１８に示すように、運行テーブル作成部２１は、サーバ１５に内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ１００）。
【０１８２】
運行テーブル作成部２１は、スタッフ情報データベース３１から、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ１０１）。
【０１８３】
運行テーブル作成部２１は、抽出したスタッフ情報から、図４に例示した運行テーブル３２を作成する（Ｓ１０２）。
【０１８４】
運行テーブル作成部２１は、１日１回、日付が変わる直前に実行することが望ましいが、日付をまたいだ期間（例えば、１月２０日０４時００分から１月２１日０３時５９分まで）の情報を抽出する場合は、カレンダー１６により日付だけではなく日時を取得し、呼出し時刻Ｔｐが現日時から所定期間内（例えば２４時間）と比較するようにすることで対応できる。
【０１８５】
図１９に示すように、回線割当部２２は、スキャン周期α（例えば１分）毎に実行され、カレンダー１６により、現在の時刻（ｔ）を取得する（Ｓ２００）。
【０１８６】
回線割当部２２は、取得した時刻（ｔ）から次回のスキャン時刻（ｔ＋α）までの間に当てはまる呼出し時刻Ｔｐが設定されているスタッフ情報を運行テーブル３２内で検出し、そのスタッフ情報のスタッフ番号Ｍを抽出する（Ｓ２０１）。
【０１８７】
次に、回線割当部２２は、回線毎プロセスカウンタ３３を参照して、割当てられたプロセス数が最少の回線の回線番号Ｌ（以下、回線Ｌという）を取得する（Ｓ２０２）。
【０１８８】
回線割当部２２は、取得した回線Ｌ用の回線毎プロセスカウンタ３３に２を加算し（Ｓ２０３）、発呼処理部２４の呼出しプロセスと再呼出しプロセスとして、呼出しプロセス識別子（例えば０１Ｃ、０３Ｃ、０４Ｃ、・・）と再呼出しプロセス識別子（例えば０１Ｒ、０３Ｒ、０４Ｒ、・・）を当該回線用のプロセス管理テーブル３４に同時に登録する（Ｓ２０４）。
【０１８９】
回線割当部２２は、検索が運行テーブル３２の最後に達したかを判定し、最後に達するまで検索を繰り返す（Ｓ２０５）。
【０１９０】
回線割当部２２は、上記の処理をスキャン周期α毎に繰り返し行う（Ｓ２０６）。
【０１９１】
図２０に示すように、プロセス管理部２３は、プロセス管理テーブル３４に登録された発呼処理部２４の呼出しプロセスと再呼出しプロセスを、各プロセスの識別子と回線Ｌを通知して、並列して起動する（Ｓ３００）。
【０１９２】
例えば、プロセス管理部２３は、プロセス管理テーブル３４の登録に従って、（プロセス０１Ｃ、 回線１）、（プロセス０３Ｃ、 回線２）、（プロセス０１Ｒ、 回線１）という情報を、プロセスを生成する際にプロセスに割り当てられる一次メモリ内のワークエリア（プロセス制御ブロックＰＣＢなど）に設定するとともに、発呼処理部２４のプロセスを実行に移す。
【０１９３】
また、プロセス管理部２３は、プロセスが終了する際に、プロセス識別子と回線Ｌとともに、プロセスから送信されてくるイベントを受信し、そのイベントの種類を判定し、次の処理を行う（Ｓ３０１）。
【０１９４】
待ち状態の場合：
プロセス管理部２３は、現状を維持したまま、該当プロセスを再度実行できるまで待つ（Ｓ３０２）。
【０１９５】
呼出し前自己申告ありの場合：
プロセス管理部２３は、まず、該当呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０３）、さらに対応する再呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除する（Ｓ３０４）。
【０１９６】
例えば、該当呼出しプロセス識別子呼出しがプロセス０１Ｃであったとき、対応する再呼出しプロセス識別子は、同じスタッフ番号０１を含むプロセス０１Ｒとなる。
【０１９７】
プロセス管理部２３は、回線毎プロセスカウンタ３３の回線Ｌのカウンタから２を減算する（Ｓ３０５）。
【０１９８】
呼出し終了の場合：
図２１に示すように、プロセス管理部２３は、該当呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０６）、回線毎プロセスカウンタ３３の回線Ｌのカウンタから１を減算する（Ｓ３０７）。
【０１９９】
再呼出し前自己申告あり、再呼出し終了の場合：
図２１に示すように、プロセス管理部２３は、該当再呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０８）、回線毎プロセスカウンタ３３の回線Ｌのカウンタから１を減算する（Ｓ３０９）。
【０２００】
図２２に示すように、発呼処理部２４は、プロセス管理部２３から起動時に通知されるプロセス識別子と回線Ｌを受信し、プロセス識別子に含まれるスタッフ番号Ｍを取得し（Ｓ４００）、運行テーブル３２からスタッフ番号Ｍのスタッフ情報を読み出す（Ｓ４０１）。
【０２０１】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４０２）。
【０２０２】
発呼処理部２４は、呼出しルートでは、スタッフ情報の自己申告フラグを判定し（Ｓ４０３）、１（自己申告あり）の場合は、「呼出し前自己申告あり」イベントをプロセス管理部２３に送信し、プロセスを終了する（Ｓ４０４）。０（自己申告なし）の場合は、スタッフ情報から呼出し時刻Ｔｐを取得する（Ｓ４０５）。
【０２０３】
発呼処理部２４は、再呼出しルートでは、スタッフ情報の自己申告フラグを判定し、１（自己申告あり）の場合は、「再呼出し前自己申告あり」イベントをプロセス管理部２３に送信し、プロセスを終了する（Ｓ４０７）。０（自己申告なし）の場合は、スタッフ情報から再呼出し時刻Ｔｑを取得する（Ｓ４０８）。
【０２０４】
発呼処理部２４は、カレンダー１６により、現在の時刻（ｔ）を取得し（Ｓ４０９）、現在の時刻（ｔ）が、呼出し時刻Ｔｐか再呼出し時刻Ｔｑ以降かを判定する（Ｓ４１０）。つまり実行しようとしているプロセスが実行時間になっているかを判断する。
【０２０５】
発呼処理部２４は、実行時間になっていないと判定した場合、「待ち状態」イベントをプロセス管理部２３に送信して、実行待ち状態に遷移する（Ｓ４１１）。
【０２０６】
一方、図２３に示すように、発呼処理部２４は、実行時間になっていると判定した場合、回線使用状況テーブル３５から回線Ｌの状況を取得し（Ｓ４１２）、０（空）か判定する（Ｓ４１３）。
【０２０７】
発呼処理部２４は、回線Ｌが使用中である場合、「待ち状態」イベントをプロセス管理部２３に送信して、実行待ち状態に遷移する（Ｓ４１４）。
【０２０８】
発呼処理部２４は、回線Ｌが空いている場合、回線使用状況テーブル３５の回線Ｌの状況を１（使用）に変更し（Ｓ４１５）、スタッフ情報からスタッフ電話番号Ｄを取得する（Ｓ４１６）。
【０２０９】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４１７）。
【０２１０】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「呼出し中」に更新するように要求し（Ｓ４１８）、再呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「再呼出し中」に更新するように要求する（Ｓ４１９）。
【０２１１】
つづいて、図２４に示すように、発呼処理部２４は、回線Ｌ通信制御部２５にスタッフ電話番号Ｄを送信して発呼させるとともに（Ｓ４２０）、呼出しカウンタに１を加算し（Ｓ４２１）、呼出し継続タイマーＴａ（例えば２０秒）を起動し（Ｓ４２２）、応答待ち状態で待機する（Ｓ４２３）。
【０２１２】
ここで、呼出しカウンタは、プロセスを生成する際にプロセスに割り当てられる一次メモリ内のワークエリア（プロセス制御ブロックＰＣＢなど）を使ってカウントするため、図２の構成図には特に明示していない。同様にプロセス中で使用する呼出し継続タイマーＴａ等の各種タイマーも、サーバ１５に内蔵されたソフトウェアタイマーを利用するため、図２の構成図には特に明示していない。
【０２１３】
発呼処理部２４は、呼出し継続タイマーＴａがタイムアウトすると（Ｓ４２４）、呼出しカウンタが所定回数（例えば３回）になったかを判定し（Ｓ４２５）、まだ所定回数に達していない場合、呼出し間隔タイマーＴｂ（例えば３０秒）を起動し（Ｓ４２６）、再発呼を待ち、呼出し間隔タイマーＴｂがタイムアウトした時点で、再び発呼処理を繰り返す（Ｓ４２７）。
【０２１４】
発呼処理部２４は、呼出しカウンタが所定回数に達した場合、回線使用状況テーブル３５の回線Ｌの状況を０に変更する（Ｓ４２８）。
【０２１５】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４２９）。
【０２１６】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９に「呼出し応答なし」を通知し（Ｓ４３０）、「呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４３１）。再呼出しルートでは、スタッフ状況更新部２９に「再呼出し応答なし」を通知し（Ｓ４３２）、「再呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４３３）。
【０２１７】
一方、図２５に示すように、発呼処理部２４は、応答待ち状態で待機しているときに（Ｓ４２３）、スタッフ電話機１３から回線Ｌ通信制御部２５を経由して応答を受信すると（Ｓ４３４）、スタッフ情報から音声応答情報を取得し、音声ボード１７により音声再生し、スタッフに聞かせる（Ｓ４３５）。
【０２１８】
発呼処理部２４は、その後、回線を切断するように回線Ｌ通信制御部に通知し（Ｓ４３６）、回線使用状況テーブル３５の回線Ｌの状況を０に変更する（Ｓ４３７）。
【０２１９】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４３８）。
【０２２０】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「呼出し応答」に更新するように要求し（Ｓ４３９）、「呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４４０）。再呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「再呼出し応答」に更新するように要求し（Ｓ４４１）、「再呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４４２）。
【０２２１】
ここで図示した発呼処理部２４は、呼出しプロセスと再呼出しプロセスを１つの処理ルーチンで実行する構成として説明している。しかし、処理中でプロセス識別子から呼出しプロセスか再呼出しプロセスかを判定している箇所を省き、呼出しルートの処理のみを含む呼出しルーチン部と、再呼出しルートの処理のみを含む再呼出しルーチン部の２つの処理ルーチンを、別々に発呼処理部２４に設ける構成であってもよい。
【０２２２】
自己申告受信部２７は、着信回線通信制御部２６から着信呼情報を受信し、着信呼情報内の発信者電話番号をスタッフ識別情報として、スタッフ状況を「自己申告あり」に更新するようにスタッフ状況更新部２９に要求する。
【０２２３】
電子メール送受信部２８は、インターネット１０経由で受信した電子メールの発信元メールアドレスをスタッフ識別情報として、スタッフ状況を「自己申告あり」に更新するようにスタッフ状況更新部２９に要求する一方、スタッフ状況更新部２９からの要求により管理者携帯電話機１１に督促メールを送信する。
【０２２４】
図２６に示すように、スタッフ状況更新部２９は、上記したように、発呼処理部２４、自己申告受信部２７、及び電子メール送受信部２８からスタッフ識別情報とともに送信されてくる各種のスタッフ状況更新要求を受信する（Ｓ５００）。
【０２２５】
スタッフ状況更新部２９は、受信したスタッフ識別情報を判定し（Ｓ５０１）、発呼処理部２４から送信されてきたスタッフ番号Ｍであれば、スタッフ番号Ｍで運行テーブル３２を検索し（Ｓ５０２）、自己申告受信部２７から送信されてきた発信者電話番号であれば、発信者電話番号で運行テーブル３２を検索し（Ｓ５０３）、電子メール送受信部２８から送信されてきた発信元Ｅメールアドレスであれば、発信元Ｅメールアドレスで運行テーブル３２を検索し（Ｓ５０４）、該当するスタッフのスタッフ情報を読み出す（Ｓ５０５）。
【０２２６】
次に、スタッフ状況更新部２９は、要求されている更新情報を判定し（Ｓ５０６）、「自己申告あり」なら、スタッフ状況フラグ欄Ｆの自己申告フラグに１を設定し（Ｓ５０７）、「呼出し中」なら、スタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定し（Ｓ５０８）、「再呼出し中」なら、スタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定し（Ｓ５０９）、「呼出し応答」なら、スタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定し（Ｓ５１０）、「再呼出し応答」なら、スタッフ状況フラグ欄Ｆの再呼出し応答フラグＦ４に１を設定し（Ｓ５１１）、自己申告確認タイマーＴｃ（例えば１０分）を起動する（Ｓ５１２）。
【０２２７】
スタッフ状況更新部２９は、更新したスタッフ状況を含むスタッフ情報を運行テーブル３２に記録するとともに（Ｓ５１３）、作業者端末１４に通知する（Ｓ５１４）。
【０２２８】
また、図２７に示すように、スタッフ状況更新部２９は、要求されている更新情報が「呼出し応答なし」なら、スタッフ情報から管理者Ｅメールアドレスを取得し（Ｓ５１５）、取得した管理者Ｅメールアドレス宛てに呼出し無応答時の督促メールを送信するように電子メール送受信部２８に要求する（Ｓ５１６）。
【０２２９】
同様に、スタッフ状況更新部２９は、要求されている更新情報が「再呼出し応答なし」なら、スタッフ情報から管理者Ｅメールアドレスを取得し（Ｓ５１７）、取得した管理者Ｅメールアドレス宛てに再呼出し無応答時の督促メールを送信するように電子メール送受信部２８に要求する（Ｓ５１８）。
【０２３０】
スタッフ状況更新部２９は、要求されている更新情報が「再呼出し応答」のときに起動した自己申告確認タイマーＴｃがタイムアウトすると（Ｓ５１９）、要求のあったスタッフ番号Ｍで運行テーブル３２を検索し（Ｓ５２０）、該当スタッフのスタッフ情報を読み出す（Ｓ５２１）。
【０２３１】
スタッフ状況更新部２９は、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５が１か判定し（Ｓ５２２）、もし１でない場合、すなわちスタッフが再呼出しに応答したにもかかわらず、未だに自己申告をしてこないときは、アラームを作業者端末１４に通知し警告する（Ｓ５２３）。
【０２３２】
設定変更部３０は、作業者端末１４から入力された情報により、運行テーブル３２のスタッフ情報を変更する。
【０２３３】
また、設定変更部３０は、管理者Ｅメールアドレス宛てに送信した督促メールに従って、管理者がスタッフを呼出して、起床を確認した場合に、管理者携帯電話機１１からのインターネット１０経由アクセスを受信し、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定することもできる。
【０２３４】
さらに、設定変更部３０は、作業者端末１４からの入力により、各種タイマーの値を変更するようにしてもよい。
【０２３５】
＜発明の第２の実施の形態＞
本発明の第２の実施の形態のコールシステムは、図１に示したサーバ１５に以下に説明する機能を追加したメインサーバ１５ａと、スタッフ情報管理部２０と運行テーブル作成部２１を除いた機能を実装した複数のサブサーバ１５ｂ、１５ｃとを、インターネット１０により接続する構成となる。
【０２３６】
第２の実施の形態のコールシステムは、旅行ツアー参加者に対して、ツアー当日に通知する場合や、バスツアーなどの集合時間に遅れないように、集合時間前に呼出しを行う場合に利用できる。
【０２３７】
旅行ツアーの場合は、全国各地で企画される複数の旅行ツアーの参加者情報を一元管理するため、参加者数が多くなる上に、同じ集合時間となる旅行ツアーも複数あるため、同時に呼出し時刻Ｔｐになる参加者数も増えることになり、図１のような１台のサーバ１５では回線数が十分実装できず、呼出し遅延が発生しやすくなる。
【０２３８】
そこで、メインサーバ１５ａで参加者情報を一元管理する一方で、呼出し処理は各地に配置したサブサーバ１５ｂ、１５ｃに分散して行わせることにより、呼出し遅延を防ぐことが可能となる。
【０２３９】
図１に示したサーバ１５と図２８に示したメインサーバ１５ａの相違点について、以下に説明する。
【０２４０】
（データ構成）
メインサーバ１５ａのスタッフ情報データベース３１ａは、図３に例示したスタッフ情報データベース３１の各スタッフのスタッフ基本データ３１１に地域識別情報を追加したものとする。
【０２４１】
地域識別情報とは、各スタッフの住所や郵便番号であったり、旅行ツアーの集合場所であったりする。
【０２４２】
（第２の運行テーブル作成部２１ａ）
図２９に示すように、第２の運行テーブル作成部２１ａは、メインサーバ１５ａに内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ６００）。
【０２４３】
第２の運行テーブル作成部２１ａは、スタッフ情報データベース３１ａから、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ６０１）。
【０２４４】
第２の運行テーブル作成部２１ａは、抽出したスタッフ情報の地域識別情報により、どのサブサーバ１５ｂ、１５ｃに転送するかを決定する（Ｓ６０２）。
【０２４５】
第２の運行テーブル作成部２１ａは、決定したサブサーバに抽出したスタッフ情報を転送して第２の運行テーブル３２ａを作成する（Ｓ６０３）。
【０２４６】
なお、メインサーバ１５ａも発呼処理を行うことができるので、第２の運行テーブル作成部２１ａは、メインサーバ１５ａが担当する地域については、メインサーバ１５ａ内に第２の運行テーブル３２ａを作成する。
【０２４７】
本発明の第２の実施の形態のコールシステムでは、第２の運行テーブル３２ａが作成されたあとは、メインサーバ１５ａ及びサブサーバ１５ｂ、１５ｃが、各々に作成された第２の運行テーブル３２ａに従って、図１９から図２７に示した処理をそれぞれ独立して実行し、接続した電話網１２ａ、１２ｂ、１２ｃを介して、スタッフ電話機１３ａ、１３ｂ、１３ｃと管理者携帯電話機１１ａ、１１ｂ、１１ｃにアクセスする。
【０２４８】
＜発明の第３の実施の形態＞
人間の習性として、すぐに起床できる人となかなか起床できない人がいる。さらに、なかなか起床できない人は、毎回寝過してしまう傾向にある。
【０２４９】
そこで、本発明の第３の実施の形態のコールシステムでは、こうした傾向を考慮して、起床できなかったスタッフを特定し、回線割当時に通常のスタッフの呼出しプロセスと区別して割り当てることで、回線を効率よく使用する機能をさらに追加する。
【０２５０】
発明の第３の実施の形態では、図１に示した最良の形態のコールシステムと構成は同じであるが、サーバ１５に接続した複数の回線を、再呼出し可能性の高いスタッフ用と通常のスタッフ用にあらかじめ分配しておく。
【０２５１】
例えば、２０回線が接続されている場合、再呼出し可能性の高いスタッフ用には１５回線を割り付け、通常のスタッフ用には残りの５回線を割り付ける。この割り付け回線数の比率は、再呼出し可能性の高いスタッフ数により変更できるものとする。
【０２５２】
前述した最良の形態と第３の実施の形態との相違点に絞って、以下に説明する。その他の部分につては、両者とも同じである。
【０２５３】
（データ構成）
スタッフ情報データベース３１ｂは、図３に例示したスタッフ情報データベース３１の各スタッフのスタッフ基本データ３１１に監視対象フラグを追加したものとする。
【０２５４】
第３の運行テーブル３２ｂには、スタッフ情報データベース３１ｂと同様に、図４に例示した運行テーブル３２に監視対象フラグを追加したものとする。
【０２５５】
（第３の運行テーブル作成部２１ｂ）
図３０に示すように、第３の運行テーブル作成部２１ｂは、当日の第３の運行テーブル３２ｂの作成にかかる前に、前日の第３の運行テーブル３２ｂにスタッフ状況更新部２９によって設定された各スタッフのスタッフ状況を読み出す（Ｓ７００）。
【０２５６】
第３の運行テーブル作成部２１ｂは、スタッフ状況フラグ欄Ｆの再呼出しフラグＦ３の値をスタッフ情報データベース３１ｂの各スタッフの監視対象フラグに設定する（Ｓ７０１）。
【０２５７】
つまり、再呼出しされたスタッフは、再呼出しフラグＦ３が１になっているため、スタッフ情報データベース３１ｂの監視対象フラグに１が設定され、再呼出しされずに自己申告したスタッフは、再呼出しフラグＦ３が０になので、スタッフ情報データベース３１ｂの監視対象フラグに０が設定される。
【０２５８】
第３の運行テーブル作成部２１ｂは、サーバ１５に内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ７０２）。
【０２５９】
第３の運行テーブル作成部２１ｂは、スタッフ情報データベース３１ｂから、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ７０３）。
【０２６０】
したがって、抽出されたスタッフ情報には、先ほど設定した監視対象フラグの値が含まれることになる。
【０２６１】
第３の運行テーブル作成部２１ｂは、抽出したスタッフ情報から当日の第３の運行テーブル３２ｂを作成する（Ｓ７０４）。
【０２６２】
（第２の回線割当部２２ａ）
図３１に示すように、第２の回線割当部２２ａは、スキャン周期α（例えば１分）毎に実行され、カレンダー１６により、現在の時刻（ｔ）を取得する（Ｓ８００）。
【０２６３】
第２の回線割当部２２ａは、取得した時刻（ｔ）から次回のスキャン時刻（ｔ＋α）までの間に当てはまる呼出し時刻Ｔｐが設定されているスタッフ情報を第３の運行テーブル３２ｂ内で検出し、そのスタッフ情報のスタッフ番号Ｍを抽出する（Ｓ８０１）。
【０２６４】
次に、第２の回線割当部２２ａは、スタッフ情報の監視対象フラグを判定し（Ｓ８０２）、監視対象フラグが１ならば、回線毎プロセスカウンタ３３を参照して、再呼出し可能性の高いスタッフ用に割り付けられた複数の回線のうちで、割当てられたプロセス数が最少の回線の回線Ｌを取得する（Ｓ８０３）。
【０２６５】
一方、第２の回線割当部２２ａは、スタッフ情報の監視対象フラグが０ならば、回線毎プロセスカウンタ３３を参照して、通常のスタッフ用に割り付けられた残りの回線のうちで、割当てられたプロセス数が最少の回線の回線Ｌを取得する（Ｓ８０４）。
【０２６６】
第２の回線割当部２２ａは、取得した回線Ｌ用の回線毎プロセスカウンタ３３に２を加算するとともに（Ｓ８０５）、発呼処理部２４の呼出しプロセスと再呼出しプロセスとして、呼出しプロセス識別子（例えば０１Ｃ、０３Ｃ、０４Ｃ、・・）と再呼出しプロセス識別子（例えば０１Ｒ、０３Ｒ、０４Ｒ、・・）を当該回線用のプロセス管理テーブル３４に同時に登録する（Ｓ８０６）。
【０２６７】
第２の回線割当部２２ａは、検索が第３の運行テーブル３２ｂの最後に達したかを判定し、最後に達するまで検索を繰り返す（Ｓ８０７）。
【０２６８】
第２の回線割当部２２ａは、上記の処理をスキャン周期α毎に繰り返し行う（Ｓ８０８）。
【０２６９】
本発明の第３の実施の形態のコールシステムでは、プロセス管理テーブル３４が作成されたあとは、図２０から図２７に示した処理を実行する。
【０２７０】
通常のスタッフの場合は、すぐに応答するため、回線が使用中となった状態は短く、プロセスが素早く実行されていく。その上、通常のスタッフの再呼出しプロセスは、既に自己申告されている可能性が高いので、実際に再呼出し処理を行わずに終了する確率が高い。
【０２７１】
一方、再呼出し可能性の高いスタッフの場合は、呼出しを３回行わなければならない可能性が高く、回線が使用中となった状態が長くなり、多くのプロセスが待ち状態になってしまう。その上、再呼出しプロセスは、実際に再呼出し処理を行うことになるため、ますます回線が使用中となった状態が長くなってしまう。
【０２７２】
そこで、本発明の第３の実施の形態では、再呼出し可能性の高いスタッフ用の回線と通常のスタッフ用の回線とに分けることで、通常のスタッフの場合は、割当てられたプロセス数が多くなっていたとしても、通常のスタッフ用の回線を割当てられるようにしている。
【０２７３】
また、再呼出し可能性の高いスタッフ用の回線を多くすることで、再呼出し可能性の高いスタッフのプロセスが待ち状態になるのを防いでいる。
【符号の説明】
【０２７４】
１０ インターネット
１１ １１ａ、１１ｂ、１１ｃ 管理者携帯電話機
１２、１２ａ、１２ｂ、１２ｃ 電話網
１３、１３ａ、１３ｂ、１３ｃ スタッフ電話機
１４ 作業者端末
１５ サーバ
１５ａ メインサーバ
１５ｂ、１５ｃ サブサーバ
１６ カレンダー
１７ 音声ボード
２０ スタッフ情報管理部
２１ 運行テーブル作成部
２１ａ 第２の運行テーブル作成部
２１ｂ 第３の運行テーブル作成部
２２ 回線割当部
２２ａ 第２の回線割当部
２３ プロセス管理部
２４ 発呼処理部
２５ 回線通信制御部
２６ 着信回線通信制御部
２７ 自己申告受信部
２８ 電子メール送受信部
２９ スタッフ状況更新部
３０ 設定変更部
３１、３１ａ、３１ｂ スタッフ情報データベース
３１１ スタッフ基本データ
３１２ スタッフ予定データ
３２ 運行テーブル
３２ａ 第２の運行テーブル
３２ｂ 第３の運行テーブル
３３ 回線毎プロセスカウンタ
３４ プロセス管理テーブル
３５ 回線使用状況テーブル
【技術分野】
【０００１】
本発明は、呼出し時刻になったときに、自動的に発呼するコールシステムであって、特に、サーバに予定が登録された複数の相手から、呼出し対象となる相手を抽出して、呼出し及び再呼出しを行うコールシステムに関する。
【背景技術】
【０００２】
バス、ハイヤー等のドライバー或いは派遣スタッフ（以下総称して単にスタッフという）の起床確認には、事務所に待機している管理者に電話をかけて起床或いは管理者側からスタッフに電話をかけて起床を確認する。
【０００３】
例えば特許文献１は、インターネット網を介してユーザ端末とサービス提供サーバとが接続されてなるモーニングコールサービスシステムである。
【０００４】
このモーニングコールサービスシステムは、予め記憶されているスケジュールの日時になったときに、相手に電話をかけて音声ガイダンスを流し、相手の音声から相手が完全におきたかどうかを判断する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４０５５３７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の通り、従来のモーニングコールシステムは、予め指定した起床予定時刻に電話機のベル（着信音）を鳴動させることにより起床を促すものであるため、 受話器を持ち上げて直ぐに元の位置に戻してしまった場合には、ユーザが完全に起床したのかどうかを確認できないといった問題点があった。
【０００７】
特許文献１では、その解決策として、相手が電話に応答した際に、相手の音声を認識して起床を確認する手法を採用している。
【０００８】
しかし、目覚まし時計のアラームが鳴ると、そのときはしっかり起きてアラームを止める操作を行うが、それが済むとまた眠ってしまうことがある場合と同様に、呼び出されるなど外部からの刺激に対しては、条件反射のように対応してしまうことがある。
【０００９】
したがって、相手が電話に応答した際の対応を確認しただけでは、その後確実に起床したかを判断することは難しく、電話への対応を完了した後に、相手が何らかの動作を自発的に行ったことを確認することで、確実に起床したと判断することが望ましい。
【００１０】
また、コンピュータ内部での確認のみでは、起床を確認できないままに放置され、支障をきたす場合があり得る。予定作業時間が過ぎたあとにコンピュータの保守者が確認しても意味がないため、呼出し状況をリアルタイムに監視できる機能が必要となる。
【００１１】
さらに、公衆電話網の回線を利用するシステムでは、システムに実装できる回線数は無制限ではないため、限られた回線を効率的に使用して、遅延を最小限にして多くの呼出しができる仕組みが必要となる。
【課題を解決するための手段】
【００１２】
本発明のコールシステムは、スタッフ電話機及び管理者携帯電話機と通信を行うために、電話網に接続された複数の回線通信制御部と着信回線通信制御部を実装した音声ボード、カレンダー、一次メモリ及び二次メモリを具備したサーバと、サーバに接続された作業者端末とを備えたコールシステムである。
【００１３】
本発明のコールシステムのサーバは、作業者端末から、呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースとして二次メモリに登録するためのスタッフ情報管理部と、カレンダーから日時を取得し、当該日時から所定期間内に該当する呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースから抽出し、一次メモリに運行テーブルを作成する運行テーブル作成部と、所定間隔でカレンダーから現時刻を取得し、当該現時刻から呼出し時刻に達するスタッフ情報を検出するとともに、一次メモリの回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択し、発呼処理部の呼出しプロセスを再呼出しプロセスとして、それぞれのプロセス識別子を当該回線用のプロセス管理テーブルに同時に登録し、回線毎プロセスカウンタの当該回線用のカウンタ数に２を加算する回線割当部と、プロセス管理テーブルに登録された呼出しプロセスと再呼出しプロセスを並列して起動し、起動した呼出しプロセスと再呼出しプロセスから受信するイベントが、（１）呼出し前自己申告ありの場合、呼出しプロセスのプロセス識別子と、当該呼出しプロセスに対応する再呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から２を減算し、（２）呼出し終了の場合、呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から１を減算し、（３）再呼出し前自己申告あり及び再呼出し終了の場合、再呼出しプロセスのプロセス識別子をプロセス管理テーブルから削除し、回線毎プロセスカウンタのカウンタ数から１を減算するプロセス管理部と、プロセス管理部から起動された呼出しプロセスと再呼出しプロセスのそれぞれのプロセス識別子に含まれるスタッフ番号に該当するスタッフ情報を運行テーブルから読み出し、当該スタッフ情報のスタッフ状況が自己申告ありの場合、呼出し前自己申告ありイベントまたは再呼出し前自己申告ありイベントをプロセス管理部に送信し、当該スタッフ情報のスタッフ状況が自己申告なしの場合、一次メモリの回線使用状況テーブルを参照し、指定回線が空きならば、回線使用状況テーブルを使用に変更し、当該スタッフ情報に設定されたスタッフ電話番号に回線通信制御部から所定回数発呼を繰り返し、所定回数に達した時または応答時に呼出
し終了イベントまたは再呼出し終了イベントをプロセス管理部に送信し、処理によりスタッフ状況に変化が生じると、スタッフ番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する発呼処理部と、着信回線通信制御部から着信呼情報を受信すると、当該着信呼情報内の発信者電話番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する自己申告受信部と、発呼処理部、及び自己申告受信部から、それぞれスタッフ識別情報としてスタッフ番号及び発信者電話番号とともに送信されたスタッフ状況更新要求により、当該スタッフ識別情報に該当する運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、作業者端末にスタッフ状況を通知するスタッフ状況更新部とを含むことを要旨とする。
【発明の効果】
【００１４】
以上のように本発明によれば、相手が自発的に行った自己申告があったことを確認できるまで、呼出しと再呼出しを行うので、確実に起床したことを確認できる。
【００１５】
また、本発明によれば、サーバから呼出し状況（スタッフ状況）をリアルタイムに作業者端末に通知し、画面に表示させるので、常に呼出し状況を監視できる。
【００１６】
さらに、本発明によれば、割り当てられたプロセス数が最少の回線を選択して、呼出しプロセスと再呼出しプロセスを同時に割当てるので、回線を効率的に使用し、遅延を最小限にして多くの呼出しができる。
【図面の簡単な説明】
【００１７】
【図１】実施の最良の形態のコールシステムの概略構成図
【図２】実施の最良の形態のサーバの構成図
【図３】実施の最良の形態のスタッフ情報データベースの構成図
【図４】実施の最良の形態の運行テーブルの構成図
【図５】呼出し前までのシステム全体のシーケンス図
【図６】呼出しにスタッフが全く応答しない場合のシステム全体のシーケンス図
【図７】再呼出しにスタッフが全く応答しない場合のシステム全体のシーケンス図
【図８】呼出しに応答した場合のシステム全体のシーケンス図
【図９】再呼出しに応答した場合のシステム全体のシーケンス図
【図１０】呼出し前に自己申告があった場合のシステム全体のシーケンス図
【図１１】呼出しにスタッフが全く応答しない場合のイメージ図
【図１２】作業者端末に表示される画面のイメージ図
【図１３】スタッフが全く応答しない場合のサーバ内シーケンス図
【図１４】スタッフが全く応答した場合のサーバ内シーケンス図
【図１５】呼出し前に自己申告があった場合のサーバ内シーケンス図
【図１６】呼出しに応答後に自己申告あった場合のサーバ内シーケンス図
【図１７】プロセス間制御シーケンス図
【図１８】運行テーブル作成部のフローチャート
【図１９】回線割当部のフローチャート
【図２０】プロセス管理部のフローチャート
【図２１】プロセス管理部のフローチャート
【図２２】発呼処理部のフローチャート
【図２３】発呼処理部のフローチャート
【図２４】発呼処理部のフローチャート
【図２５】発呼処理部のフローチャート
【図２６】スタッフ状況更新部のフローチャート
【図２７】スタッフ状況更新部のフローチャート
【図２８】第２の実施の形態のコールシステムの概略構成図
【図２９】第２の運行テーブル作成部のフローチャート
【図３０】第３の運行テーブル作成部のフローチャート
【図３１】第２の回線割当部のフローチャート
【発明を実施するための形態】
【００１８】
＜発明の第１の実施の形態＞
本発明の実施の最良の形態のコールシステムは、図１に示すように、電話網１２とインターネット１０に接続され、スタッフ電話機１３及び管理者携帯電話機１１と通信を行うために、電話網１２と接続するための複数の回線通信制御部２５と着信回線通信制御部２６を実装した音声ボード１７と、カレンダー１６と、一次メモリ及び二次メモリとを具備したサーバ１５と、サーバ１５に接続された作業者端末１４とによって構成される。
【００１９】
スタッフ電話機１３は、携帯電話機が望ましいが、固定電話機であっても構わない。
【００２０】
サーバ１５に接続される電話回線は、アナログ電話回線とＩＳＤＮ電話回線のいずれであっても構わず、両方の回線を混在させることも可能であり、それぞれに対応したインターフェースを有する回線通信制御部２５と着信回線通信制御部２６を音声ボード１７に実装する。
【００２１】
回線通信制御部２５は、サーバ１５から指定された電話番号に自動で発呼する機能を有し、相手からの応答信号を検出してサーバ１５に通知し、サーバ１５の指示により通話状態となった電話回線を切断する。
【００２２】
音声ボード１７は、相手からの応答信号を検出した際に、サーバ１５から指定された音声応答情報を再生して相手に聞かせる機能を有する。
【００２３】
着信回線通信制御部２６は、相手からの呼に対して自動応答するとともに、相手の電話番号（発信者電話番号）を受信してサーバ１５に通知する機能を有する。
【００２４】
図２のサーバ１５の構成図において、一次メモリ及び二次メモリを明示していないが、一次メモリには、運行テーブル３２、回線毎プロセスカウンタ３３、プロセス管理テーブル３４、及び回線使用状況テーブル３５が作成される。二次メモリには、スタッフ情報データベース３１が構築される。
【００２５】
さらに、図２に示すように、サーバ１５には、スタッフ情報管理部２０、運行テーブル作成部２１、回線割当部２２、プロセス管理部２３、発呼処理部２４、自己申告受信部２７、電子メール送受信部２８、スタッフ状況更新部２９、設定変更部３０が含まれる。
【００２６】
（データ構成）
スタッフ情報データベース３１には、図３に例示すように、スタッフ基本データ３１１とスタッフ予定データ３１２が含まれる。
【００２７】
スタッフ基本データ３１１には、全スタッフについて、スタッフ識別情報となるスタッフ番号Ｍと、スタッフメールアドレスＳａと、スタッフ電話番号Ｄが登録され、さらに、本コールシステムによって呼び出した時に各スタッフに聞かせるメッセージを、呼出し時音声応答情報Ｃｍ及び再呼出し時音声応答情報Ｒｍとして登録できる。
【００２８】
また、必要時に管理者に電子メールで通知できるように、各スタッフの管理者のメールアドレス（管理者メールアドレスＫａ）をスタッフ基本データ３１１に登録しておく。
【００２９】
スタッフ予定データ３１２には、各スタッフの一定期間（一週間や一ヶ月など）の勤務予定に従い、呼出し日付ｄｄと呼出し時刻Ｔｐ及び再呼出し時刻Ｔｑを登録する。
【００３０】
スタッフ毎に作成されるスタッフ予定データ３１２は、スタッフ番号Ｍをテーブル名に付与するなどして、各スタッフのスタッフ基本データ３１１にリンクさせておく。
【００３１】
なお、再呼出し時刻Ｔｑは、呼出し時刻Ｔｐに近過ぎたり、呼出し時刻Ｔｐから離れ過ぎたりすると効果がないので、呼出し時刻Ｔｐを登録する際に、呼出し時刻Ｔｐから一定時間（例えば１５分）後になるように、システムが自動設定するのが好ましい。
【００３２】
運行テーブル３２には、図４に例示すように、スタッフ情報データベース３１に登録された情報のうち、スタッフ番号Ｍと、スタッフメールアドレスＳａと、スタッフ電話番号Ｄと、呼出し時音声応答情報Ｃｍと、再呼出し時音声応答情報Ｒｍと、管理者メールアドレスＫａと、呼出し当日の呼出し時刻Ｔｐ及び再呼出し時刻Ｔｑが設定される。
【００３３】
さらに、運行テーブル３２には、スタッフの状況を示すスタッフ状況フラグ欄Ｆが設けられ、呼出しフラグＦ１、呼出し応答フラグＦ２、再呼出しフラグＦ３、再呼出し応答フラグＦ４、自己申告フラグＦ５が含まれる。
【００３４】
自己申告フラグＦ５は、スタッフが起床したことを自ら連絡してきたときに１が設定される。呼出しフラグＦ１は、システムが呼出し時刻Ｔｐにスタッフに発呼したときに１が設定され、呼出し応答フラグＦ２は、その呼出しにスタッフが応答したときに１が設定される。
【００３５】
再呼出しフラグＦ３は、システムが再呼出し時刻Ｔｑにスタッフに発呼したときに１が設定され、再呼出し応答フラグＦ４は、その再呼出しにスタッフが応答したときに１が設定される。
【００３６】
回線毎プロセスカウンタ３３には、図２に例示するように、回線番号とその回線に割当てられている発呼処理部２４のプロセスの数を示す回線毎のデータが設定されている。
【００３７】
プロセス管理テーブル３４は、図２に例示するように、回線毎に作成される。プロセス管理テーブル３４には、生成された発呼処理部２４のプロセスを識別するプロセス識別子（ＰＩＤ）が登録される。
【００３８】
プロセス識別子には、呼出しプロセスの呼出しプロセス識別子と、再呼出しプロセスの再呼出しプロセス識別子があり、各プロセスがどのスタッフのためのプロセスであるかが識別できるように、プロセス識別子を生成する。
【００３９】
具体的には、スタッフのスタッフ番号Ｍを利用すると同時に、呼出し用か再呼出し用かを区別できるように、例えばプロセス識別子の最後に、呼出しプロセスには“Ｃ”、また再呼出しプロセスには“Ｒ”を付与する。この作成方法に従って、スタッフ番号０１のスタッフの呼出しプロセス識別子は“０１Ｃ”、再呼出しプロセス識別子は“０１Ｒ”となる。
【００４０】
回線使用状況テーブル３５には、図２に例示するように、回線番号とその回線が空きか使用中かを示す回線毎のデータが設定されている。これは、同一の回線を使用しようとしている複数のプロセス間で排他制御を行うために用いられる。
【００４１】
（各処理部の機能）
スタッフ情報管理部２０は、作業者端末１４からスタッフ情報データベース３１の情報を二次メモリに登録する処理を行う。
【００４２】
運行テーブル作成部２１は、カレンダー１６から現日時を取得し、呼出し日付ｄｄと呼出し時刻Ｔｐが現日時から所定期間内（例えば２４時間）に該当するスタッフの情報をスタッフ情報データベース３１から抽出し、一次メモリに運行テーブル３２を作成する処理を行う。
【００４３】
回線割当部２２は、所定周期（例えば１分）毎に、カレンダー１６から現時刻を取得し、現時刻と比較して、呼出し時刻Ｔｐに達するスタッフ情報を検出するとともに、回線毎プロセスカウンタ３３を参照しカウンタ数が最少の回線を選択し、発呼処理部２４のプロセスとして、呼出しプロセス識別子と再呼出しプロセス識別子を当該回線用のプロセス管理テーブル３４に同時に登録し、回線毎プロセスカウンタ３３の当該回線用のカウンタに２を加算する処理を繰り返し行う。
【００４４】
プロセス管理部２３は、プロセス管理テーブル３４に登録された発呼処理部２４のプロセスを並列して起動する一方、プロセスが終了する際に、プロセスから送信されるイベントの種類に従い、プロセス管理テーブル３４から該当するプロセスを削除するとともに、削除したプロセスの数だけ回線毎プロセスカウンタ３３のカウンタから減算する処理を行う。
【００４５】
発呼処理部２４は、プロセス管理部２３から起動されたプロセスのプロセス識別子に含まれるスタッフ番号Ｍにより、運行テーブル３２から該当するスタッフ情報を読み出し、自己申告フラグＦ５が１の場合はプロセスを終了し、自己申告フラグＦ５が０の場合は、回線使用状況テーブル３５を参照し、指定回線が空きならば、スタッフ情報に設定されたスタッフ電話番号Ｄに回線通信制御部２５から所定回数（例えば３回）発呼を繰り返し、所定回数に達した時または応答時にプロセスを終了する処理を行う。
【００４６】
発呼処理部２４は、プロセスを終了する際に、「待ち状態」、「呼出し前自己申告あり」、「呼出し終了」、「再呼出し前自己申告あり」、及び「再呼出し終了」の終了要因を示すイベントをプロセス管理部２３に送信する処理を行う。
【００４７】
また、発呼処理部２４は、プロセスの処理に伴って、スタッフの状況が変化する際に、「呼出し中」、「呼出し応答」、「呼出し応答なし」、「再呼出し中」、「再呼出し応答」、及び「再呼出し応答なし」のスタッフ状況更新要求を、スタッフ識別情報としてのスタッフ番号Ｍとともにスタッフ状況更新部２９に通知する処理も行う。
【００４８】
自己申告受信部２７は、着信回線通信制御部２６から着信呼情報を受信し、着信呼情報内の発信者電話番号をスタッフ識別情報としてスタッフ状況更新部２９に送信する処理を行う。
【００４９】
電子メール送受信部２８は、インターネット１０経由で受信した電子メールの発信元メールアドレスをスタッフ識別情報としてスタッフ状況更新部２９に送信するとともに、スタッフ状況更新部２９からの要求により管理者携帯電話機１１に督促メールを送信する処理を行う。
【００５０】
スタッフ状況更新部２９は、発呼処理部２４、自己申告受信部２７、及び電子メール送受信部２８からスタッフ識別情報とともに送信させたスタッフ状況更新要求により、当該スタッフ識別情報に該当する運行テーブル３２のスタッフ情報を更新する処理と、更新時に更新したスタッフ情報を作業者端末１４に通知する処理を行う。
【００５１】
また、スタッフ状況更新部２９は、発呼処理部２４から「呼出し応答なし」及び「再呼出し応答なし」のスタッフ状況更新要求を受信した場合は、管理者携帯電話機１１への督促メール送信を電子メール送受信部２８に要求する処理を行う。
【００５２】
設定変更部３０は、作業者端末１４から運行テーブル３２のスタッフ情報を変更する処理を行う。
【００５３】
（システム全体のシーケンス）
図５に示すように、まず、作業者は、作業者端末１４からサーバ１５にアクセスし（ｄ１）、スタッフ情報管理部２０によりスタッフ情報をスタッフ情報データベース３１に登録しておく（ｄ２）。
【００５４】
サーバ１５の運行テーブル作成部２１は、所定時刻（例えば毎日０時）になると、カレンダー１６から現日付を取得し、登録させている呼出し日時と現日付と比較して、該当するスタッフ情報をスタッフ情報データベース３１から抽出する（ｄ３）。
【００５５】
サーバ１５の運行テーブル作成部２１は、抽出したスタッフ情報にスタッフ状況フラグ欄Ｆを付加して運行テーブル３２を作成する（ｄ４）。
【００５６】
サーバ１５の回線割当部２２は、所定周期（例えば１分）毎に、カレンダー１６から現時刻を取得し、登録させている呼出し時刻Ｔｐと現時刻と比較して、運行テーブル３２から呼出し時刻Ｔｐになるスタッフを検出する（ｄ５）。
【００５７】
つづいて、サーバ１５の回線割当部２２は、回線毎プロセスカウンタ３３を参照して、プロセス数が最少の回線を選択し、当該回線のカウンタに２を加算する（ｄ６）。
【００５８】
サーバ１５の回線割当部２２は、発呼処理部２４のプロセスとして、呼出しプロセス識別子と再呼出しプロセス識別子を当該回線用のプロセス管理テーブル３４に同時に登録する（ｄ７）。
【００５９】
サーバ１５の回線割当部２２は、検出したスタッフ全員についてプロセスの登録処理を繰返す（ｄ８）。
【００６０】
さらに、サーバ１５の回線割当部２２は、上記の処理を所定周期（例えば１分）毎に繰返し行う（ｄ９）。
【００６１】
ここで、サーバ１５のプロセス管理部２３は、呼出しプロセスと再呼出しプロセスを区別せずに実行する。しかし、プロセス内で発呼処理を行う時刻に達したか判定するので、同一のスタッフの呼出しプロセスと再呼出しプロセスでは、呼出し時刻Ｔｐが再呼出し時刻Ｔｑより早いため、まず呼出しプロセスが発呼することになる。
【００６２】
一方、再呼出しプロセスは、サーバ１５のプロセス管理部２３によりいったん実行状態に移行されても、再呼出し時刻Ｔｑになっていないため実行待ち状態に戻る。
【００６３】
したがって、同一のスタッフについて、時系列に従って、まず呼出しプロセスが実行され、その後に再呼出しプロセスが実行されるシーケンスを、場合分けしながら説明する。
【００６４】
（ケース１：応答なし）
まず、呼出し及び再呼出しに応答がない場合のシーケンスについて、図６と図７を参照しながら説明する。スタッフから全く応答がない場合の流れのイメージを図１１に例示し、また、作業者端末１４に表示される画面イメージを図１２に例示する。
【００６５】
図１２に例示した作業者端末１４に表示される初期情報は、サーバ１５の運行テーブル作成部２１が、運行テーブル３２の作成が完了した時点で作業者端末１４に送信するなど、運行テーブル３２に従って当日の呼出しが開始される前に作業者端末１４に送信しておく。
【００６６】
図６に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ１０）。
【００６７】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ１１）。
【００６８】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５により、既に自己申告があったかどうかを判定する（ｄ１２）。
【００６９】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ１３）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ１３ａ）。
【００７０】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し」に更新させ、作業者端末１４に通知させる（ｄ１４）。作業者端末１４では、該当スタッフの状況に「呼出し」が表示される（ｄ１４ａ）。
【００７１】
サーバ１５の発呼処理部２４は、一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待つ（ｄ１５）。
【００７２】
サーバ１５の発呼処理部２４は、もし応答がなければ、所定間隔（例えば３０秒）後に、スタッフ電話番号Ｄに回線通信制御部２５によって再度発呼し（ｄ１６）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ１６ａ）。
【００７３】
サーバ１５の発呼処理部２４は、また一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待ち（ｄ１７）、もし応答がなければ、上記の呼出しを所定回数（例えば３回）まで繰り返す（ｄ１８）。
【００７４】
サーバ１５の発呼処理部２４は、所定回数呼出しても応答がない場合、スタッフ状況更新部２９に「呼出し応答なし」を通知し、作業者端末１４に通知させると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信させる（ｄ１９）。作業者端末１４では、該当スタッフの状況に「呼出し応答なし」が表示される（ｄ１９ａ）。
【００７５】
サーバ１５の発呼処理部２４は、「呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ２０）。
【００７６】
以上の呼出しの流れは、図１１の（ａ）に例示したようになり、管理者は、送信されてきた督促メールに記載されたスタッフ電話番号Ｄに発呼し（ｄ１９ｂ）、スタッフを呼出し（ｄ１９ｃ）、起床を確認した場合は、自己申告させるか、督促メールに記載されたＵＲＬにアクセスする。
【００７７】
つぎに、図７に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ２１）。
【００７８】
サーバ１５の発呼処理部２４は、再呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ２２）。
【００７９】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ２３）。
【００８０】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ２４）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ２４ａ）。
【００８１】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し」に更新させ、作業者端末１４に通知させる（ｄ２５）。作業者端末１４では、該当スタッフの状況に「再呼出し」が表示される（ｄ２５ａ）。
【００８２】
サーバ１５の発呼処理部２４は、一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待つ（ｄ２６）。
【００８３】
サーバ１５の発呼処理部２４は、もし応答がなければ、所定間隔（例えば３０秒）後に、スタッフ電話番号Ｄに回線通信制御部２５によって再度発呼し（ｄ２７）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ２７ａ）。
【００８４】
サーバ１５の発呼処理部２４は、また一定時間（例えば２０秒）呼出し続け、一定時間がタイムアウトするまでスタッフからの応答を待ち（ｄ２８）、もし応答がなければ、上記の呼出しを所定回数（例えば３回）まで繰り返す（ｄ２９）。
【００８５】
サーバ１５の発呼処理部２４は、所定回数呼出しても応答がない場合、スタッフ状況更新部２９に「再呼出し応答なし」を通知し、作業者端末１４に通知させると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信させる（ｄ３０）。作業者端末１４では、該当スタッフの状況に「再呼出し応答なし」が表示される（ｄ３０ａ）。
【００８６】
サーバ１５の発呼処理部２４は、「再呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ３１）。
【００８７】
以上の再呼出しの流れは、図１１の（ｂ）に示したようになり、管理者は、送信されてきた督促メールに記載されたスタッフ電話番号Ｄに発呼し（ｄ３０ｂ）、スタッフを呼出し（ｄ３０ｃ）、起床を確認し、自己申告させる。
【００８８】
なお、督促メールの送信先を管理者携帯電話機１１として説明したが、サーバ１５にインターネットやＬＡＮによって接続できる管理者端末に送信しても構わない。
【００８９】
（ケース２：応答後の自己申告なし）
次に、スタッフから応答がある場合のシーケンスについて、図８と図９を参照しながら説明する。
【００９０】
図８に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ４０）。
【００９１】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ４１）。
【００９２】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ４２）。
【００９３】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ４３）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ４３ａ）。
【００９４】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し」に更新させ、作業者端末１４に通知させる（ｄ４４）。作業者端末１４では、該当スタッフの状況に「呼出し」が表示される（ｄ４４ａ）。
【００９５】
サーバ１５の発呼処理部２４は、一定時間呼出し続けている間に（ｄ４５）、スタッフから応答があると（ｄ４５ａ）、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「呼出し応答」に更新させ、作業者端末１４に通知させる（ｄ４６）。作業者端末１４では、該当スタッフの状況に「呼出し応答」が表示される（ｄ４６ａ）。
【００９６】
サーバ１５の発呼処理部２４は、スタッフの予め登録しておいた呼出し時音声応答情報Ｃｍを音声ボード１７に再生させて、スタッフに聞かせた後、回線を切断し、「呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ４７）。
【００９７】
つづいて、図９に示すように、サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ４８）。
【００９８】
サーバ１５の発呼処理部２４は、再呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ４９）。
【００９９】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ５０）。
【０１００】
サーバ１５の発呼処理部２４は、もし自己申告がなければ、スタッフ情報に登録させたスタッフ電話番号Ｄに回線通信制御部２５によって呼出しを行い（ｄ５１）、スタッフ電話機１３は、電話網１２を介して呼び出される（ｄ５１ａ）。
【０１０１】
サーバ１５の発呼処理部２４は、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し」に更新させ、作業者端末１４に通知させる（ｄ５２）。作業者端末１４では、該当スタッフの状況に「再呼出し」が表示される（ｄ５２ａ）。
【０１０２】
サーバ１５の発呼処理部２４は、一定時間呼出し続けている間に（ｄ５３）、スタッフから応答があると（ｄ５３ａ）、スタッフ状況更新部２９により運行テーブル３２のスタッフ状況を「再呼出し応答」に更新させ、作業者端末１４に通知させる（ｄ５４）。作業者端末１４では、該当スタッフの状況に「再呼出し応答」が表示される（ｄ５４ａ）。
【０１０３】
サーバ１５の発呼処理部２４は、スタッフの予め登録しておいた再呼出し時音声応答情報Ｒｍを音声ボード１７に再生させて、スタッフに聞かせた後、回線を切断し、「再呼出し終了」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４からプロセス登録を削除する（ｄ５５）。
【０１０４】
一定時間後に、サーバ１５のスタッフ状況更新部２９は、運行テーブル３２のスタッフ状況を「再呼出し応答」に更新したスタッフ情報について、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ５６）。
【０１０５】
サーバ１５のスタッフ状況更新部２９は、もし自己申告がなければ、作業者端末１４にアラームを通知し（ｄ５７）、作業者端末１４では、アラームが表示される（ｄ５７ａ）。
【０１０６】
（ケース３：呼出し前自己申告あり）
最後に、スタッフから自己申告がある場合のシーケンスについて、図１０を参照しながら説明する。
【０１０７】
図１０に示すように、まず、スタッフはスタッフ電話機１３からサーバ１５に接続された着信回線用の電話番号に電話するか、スタッフ電話機１３がＥメール機能を有する携帯電話機であるときは、サーバ１５に割り当てられたメールアドレスにＥメールを送信することで、起床済みであることを自己申告する（ｄ６０）。
【０１０８】
サーバ１５のスタッフ状況更新部２９は、電話の場合、着信回線通信制御部２６から自己申告受信部２７に通知された発信者電話番号を受信し、Ｅメールの場合、電子メール送受信部２８から発信元メールアドレスを受信し、該当のスタッフの運行テーブル３２のスタッフ状況を「自己申告」に更新し、作業者端末１４に通知する（ｄ６１）。作業者端末１４では、該当スタッフの状況に「自己申告」が表示される（ｄ６１ａ）。
【０１０９】
サーバ１５のプロセス管理部２３は、サーバ１５のＣＰＵが新たなプロセスを実行できる状態となる毎に、プロセス管理テーブル３４に登録されたプロセスを順次実行していく（ｄ６２）。
【０１１０】
サーバ１５の発呼処理部２４は、呼出しプロセス識別子に含まれるスタッフ番号Ｍによって、運行テーブル３２から該当するスタッフ情報を読み出す（ｄ６３）。
【０１１１】
サーバ１５の発呼処理部２４は、読み出したスタッフ情報のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５から既に自己申告があったかどうかを判定する（ｄ６４）。
【０１１２】
サーバ１５の発呼処理部２４は、もし自己申告があれば、「呼出し前自己申告」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から２を減算し、プロセス管理テーブル３４から呼出しプロセスと再呼出しロセスの両方の登録を削除する（ｄ６５）。
【０１１３】
なお、再呼出しプロセスで自己申告があったことを検出した場合は、「再呼出し前自己申告」イベントをプロセス管理部２３に送信し、プロセス管理部２３では、回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス登録を削除する。
【０１１４】
図１２に例示した作業者端末１４の表示画面では、各スタッフの氏名やスタッフ電話番号Ｄの情報とともに、状態を示す丸いサイン（ｋ１、ｋ２、ｋ３、ｋ４、ｋ５、ｋ６、・・・）が表示される。
【０１１５】
例えば、丸いサインは、初期状態では色は付いていないが、スタッフ状況更新部２９から「呼出し」表示の通知を受信すると青色に点滅し始める。このあとスタッフ状況更新部２９から「呼出し応答」表示の通知を受信すると青色に点灯した状態に変わり、もし「呼出し応答なし」表示の通知を受信すると黄色に点灯した状態に変わる。
【０１１６】
さらに、丸いサインは、スタッフ状況更新部２９から「再呼出し」表示の通知を受信すると緑色に点滅し始める。このあとスタッフ状況更新部２９から「再呼出し応答」表示の通知を受信すると緑色に点灯した状態に変わり、もし「再呼出し応答なし」表示の通知を受信するとオレンジ色に点灯した状態に変わる。
【０１１７】
また、丸いサインは、スタッフ状況更新部２９から「自己申告」表示の通知を受信すると黒色に点灯し、アラームを受信すると赤色に点滅する。さらに、作業者端末１４は、アラームを受信した場合は、警告音を鳴らして作業者に注意を促すようにしてもよい。
（サーバ１５内シーケンス）
次に、上記のシステム全体のシーケンスのうち、図６から図１０を参照して説明した発呼処理に関して、サーバ１５内のプロセス管理部２３、発呼処理部２４、及びスタッフ状況更新部２９の間でのシーケンスについて詳細に説明する。
【０１１８】
（ケース１：応答なし）
まず、図６と図７を用いて説明したスタッフが呼出しにも再呼出しにも全く応答しない場合について、図１３を参照しながら、回線１を使用して、スタッフ０１に対する呼出しプロセス識別子が“０１Ｃ”のプロセス（以下、呼出しプロセス０１Ｃという）と、再呼出しプロセス識別子が“０１Ｒ”のプロセス（以下、再呼出しプロセス０１Ｒという）を実行する例を説明する。
【０１１９】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１２０】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１２１】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１２２】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａ（例えば２０秒）の間呼出しを継続する（Ｓ４）。さらに呼出し間隔タイマーＴｂ（例えば３０秒）の間、呼出しをやめ、その後２回目の発呼を行う（Ｓ５）。同様にして、３回目の発呼までを行う（Ｓ６）。
【０１２３】
３回目の発呼によっても、スタッフ０１が応答しないため、呼出しプロセス０１Ｃは、スタッフ状況更新部２９に「呼出し応答なし」を通知し（Ｓ７）、スタッフ状況更新部２９は、作業者端末１４に通知すると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信する（Ｓ７ａ）。
【０１２４】
最後に呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ８）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ８ａ）。
【０１２５】
つづいて、プロセス管理部２３は、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１２６】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１２７】
再呼出しプロセス０１Ｒは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「再呼出し」更新要求を送信し（Ｓ１１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定すると同時に（Ｓ１１ａ）、作業者端末１４に通知する。
【０１２８】
再呼出しプロセス０１Ｒは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ１２）。さらに呼出し間隔タイマーＴｂの間、呼出しをやめ、その後２回目の発呼を行う（Ｓ１３）。同様にして、３回目の発呼までを行う（Ｓ１４）。
【０１２９】
３回目の発呼によっても、スタッフ０１が応答しないため、再呼出しプロセス０１Ｒは、スタッフ状況更新部２９に「再呼出し応答なし」を通知し（Ｓ１５）、スタッフ状況更新部２９は、作業者端末１４に通知すると同時に、電子メール送受信部２８を介して、管理者携帯電話機１１に督促メールを送信する（ｓ１５ａ）。
【０１３０】
最後に再呼出しプロセス０１Ｒは、プロセス管理部２３に「再呼出し終了」イベントを送信し（Ｓ１６）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ１６ａ）。
【０１３１】
（ケース２：応答後の自己申告なし）
次に、図８と図９を用いて説明した場合であり、スタッフ０１が呼出しに応答したが自己申告がないため、再呼出しが行われ、再呼出しに応答したあとも自己申告がないため、作業者端末１４にアラーム表示される場合について、図１４を参照しながら説明する。
【０１３２】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１３３】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１３４】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１３５】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ４）。
【０１３６】
呼出しプロセス０１Ｃは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２０）、スタッフ状況更新部２９に「呼出し応答」更新要求を送信し（Ｓ２１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定すると同時に（Ｓ２１ａ）、作業者端末１４に通知する。
【０１３７】
最後に呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ２２）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ２２ａ）。
【０１３８】
プロセス管理部２３は、スタッフ０１が応答したかどうかにかかわらず、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１３９】
本発明では、呼出しに応答したスタッフに、電話かＥメールでサーバ１５に自己申告させることで、起床したことを確認する仕組みを採用している。なぜなら、呼出しにいったん応答しても、その後再び眠ってしまうこともあるし、たまたまスタッフ電話機１３が留守番電話モードとなっていて、自動応答してしまっていることも考えられるため、本人に自己申告されることとしている。
【０１４０】
そのため、呼出しに応答があった場合でも、自己申告の有無を確認させるために、再呼出しプロセス０１Ｒを実行させている。
【０１４１】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１４２】
再呼出しプロセス０１Ｒは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「再呼出し」更新要求を送信し（Ｓ１１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定すると同時に（Ｓ１１ａ）、作業者端末１４に通知する。
【０１４３】
再呼出しプロセス０１Ｒは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ１２）。
【０１４４】
再呼出しプロセス０１Ｒは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２３）、スタッフ状況更新部２９に「再呼出し応答」更新要求を送信し（Ｓ２４）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの再呼出し応答フラグＦ４に１を設定すると同時に（Ｓ２４ａ）、作業者端末１４に通知する。
【０１４５】
この時、スタッフ状況更新部２９は、再呼出しに応答した後に、スタッフ０１から自己申告があったかを確認する必要があるために、自己申告確認タイマーＴｃ（例えば１０分）を開始させる。
【０１４６】
再呼出しプロセス０１Ｒは、プロセス管理部２３に「再呼出し終了」イベントを送信し（Ｓ２５）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ２５ａ）。
【０１４７】
スタッフ状況更新部２９は、自己申告確認タイマーＴｃがタイムアウトすると、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２６ａ）自己申告の有無を判定し（Ｓ２６）、もし自己申告がなければ、作業者端末１４にアラームを通知する（Ｓ２７）。
【０１４８】
（ケース３：呼出し前自己申告あり）
次に、図１０に示したように、呼出しが行われる前にスタッフから自己申告がある場合について、図１５を参照しながら説明する。
【０１４９】
スタッフ状況更新部２９は、自己申告があった旨の通知を、スタッフ識別情報として発信者電話番号または発信元メールアドレスとともに受信し（Ｓ３０）、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定すると同時に（Ｓ３０ａ）、作業者端末１４に通知する。
【０１５０】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１５１】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１５２】
呼出しプロセス０１Ｃは、自己申告があったならば、プロセス管理部２３に「呼出し前自己申告あり」イベントを送信し（Ｓ３１）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から２を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃと再呼出しプロセス０１Ｒの両方を削除する（Ｓ３１ａ）。
【０１５３】
なぜならば、スタッフ０１からの自己申告が確認できたので、呼出しも再呼出しも不要であるため、この時点で、両方のプロセスを削除してしまう。このように不要となったプロセスを早く削除することで、無駄な回線の捕捉がなくなり、回線を効率的に使用し、遅延を最小限にして多くの呼出しができる。
【０１５４】
（ケース４：呼出し後自己申告あり）
また、スタッフ０１から呼出しに応答した後に自己申告がある場合について、図１６を参照しながら説明する。
【０１５５】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている呼出しプロセス０１Ｃを実行する（Ｓ１）。
【０１５６】
実行された発呼処理部２４の呼出しプロセス０１Ｃは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ２ａ）、自己申告の有無を判定する（Ｓ２）。
【０１５７】
呼出しプロセス０１Ｃは、自己申告がなく、また回線１を捕捉できれば、スタッフ状況更新部２９に「呼出し」更新要求を送信し（Ｓ３）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定すると同時に（Ｓ３ａ）、作業者端末１４に通知する。
【０１５８】
呼出しプロセス０１Ｃは、つづいて、スタッフ０１に対して１回目の発呼を行い、呼出し継続タイマーＴａの間呼出しを継続する（Ｓ４）。
【０１５９】
呼出しプロセス０１Ｃは、呼出しを継続している間にスタッフ０１が応答すると、回線１通信制御部から応答信号を受信し（Ｓ２０）、スタッフ状況更新部２９に「呼出し応答」更新要求を送信し（Ｓ２１）、スタッフ状況更新部２９は、スタッフ０１のスタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定すると同時に（Ｓ２１ａ）、作業者端末１４に通知する。
【０１６０】
最後に、呼出しプロセス０１Ｃは、プロセス管理部２３に「呼出し終了」イベントを送信し（Ｓ２２）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する（Ｓ２２ａ）。
【０１６１】
スタッフ状況更新部２９は、自己申告があった旨の通知を、スタッフ識別情報として発信者電話番号または発信元メールアドレスとともに受信し（Ｓ３０）、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定すると同時に（Ｓ３０ａ）、作業者端末１４に通知する。
【０１６２】
プロセス管理部２３は、プロセス管理テーブル３４に登録されている再呼出しプロセス０１Ｒを実行する（Ｓ９）。
【０１６３】
実行された発呼処理部２４の再呼出しプロセス０１Ｒは、スタッフ０１のスタッフ状況フラグ欄Ｆの自己申告フラグＦ５を参照し（Ｓ１０ａ）、自己申告の有無を判定する（Ｓ１０）。
【０１６４】
再呼出しプロセス０１Ｒは、自己申告があったならば、プロセス管理部２３に「再呼出し前自己申告あり」イベントを送信し（Ｓ４０）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から再呼出しプロセス０１Ｒを削除する（Ｓ４０ａ）。
【０１６５】
（プロセス間制御シーケンス）
本発明では、プロセス管理テーブル３４に登録された呼出しプロセスも再呼出しプロセスも、プロセス管理部２３により、順次実行状態に移行させるため、複数の呼出しプロセスと再呼出しプロセスが同時に進行することになる。
【０１６６】
そこで、複数の呼出しプロセスと再呼出しプロセス間で、どのように実行制御されるかについて、図１７を参照しながら、例として、同じ呼出し時刻Ｔｐの呼出しプロセス０１Ｃと呼出しプロセス０５Ｃ、同じ再呼出し時刻Ｔｑとなる再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒが回線１用のプロセス管理テーブル３４に登録されている場合について説明する。
【０１６７】
まず、プロセス管理部２３は、発呼処理部２４の呼出しプロセス０１Ｃ、呼出しプロセス０５Ｃ、再呼出しプロセス０１Ｒ、及び再呼出しプロセス０５Ｒを順次実行させる。
【０１６８】
呼出しプロセス０１Ｃは、呼出し時刻Ｔｐになっているか判定し（Ｓ５０）、呼出し時刻Ｔｐになっている場合は、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１６９】
回線が空いている場合、呼出しプロセス０１Ｃは、回線使用状況テーブル３５の回線１のデータを１（使用）に変更し（Ｓ５２）、発呼処理を続行する（Ｓ５３）。
【０１７０】
一方、呼出しプロセス０５Ｃも、同様に、呼出し時刻Ｔｐになっているか判定するが（Ｓ５０）、呼出しプロセス０１Ｃと同じ呼出し時刻Ｔｐであるので、当然呼出し時刻Ｔｐになっているため、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１７１】
しかし、既に呼出しプロセス０１Ｃによって、回線使用状況テーブル３５の回線１のデータは１に変更されているので、呼出しプロセス０５Ｃは回線を使用することができないため、呼出しプロセス０５Ｃの状態を待ち状態に戻す。
【０１７２】
再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒは、再呼出し時刻Ｔｑになっているか判定し（Ｓ６０）、再呼出し時刻Ｔｑになっていないため、それぞれの状態を待ち状態に戻す。
【０１７３】
プロセス管理部２３は、呼出しプロセス０５Ｃ、再呼出しプロセス０１Ｒ、及び再呼出しプロセス０５Ｒを、再び実行させることを繰り返す。
【０１７４】
この間、呼出しプロセス０１Ｃは、発呼処理を終了し、回線使用状況テーブル３５の回線１のデータを０（空）に変更し（Ｓ５４）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０１Ｃを削除する。
【０１７５】
この後に、再び実行された呼出しプロセス０５Ｃは、呼出し時刻Ｔｐになっているか判定し（Ｓ５０）、呼出し時刻Ｔｐになっているため、回線使用状況テーブル３５の回線１のデータを参照し（Ｓ５１ａ）、回線が空きかどうか判定する（Ｓ５１）。
【０１７６】
既に終了した呼出しプロセス０１Ｃによって、回線使用状況テーブル３５の回線１のデータは０に変更されているので、呼出しプロセス０５Ｃは回線を使用することができるようになり、発呼処理を行う（Ｓ５３）。
【０１７７】
呼出しプロセス０５Ｃは、発呼処理を終了し、回線使用状況テーブル３５の回線１のデータを０（空）に変更し（Ｓ５４）、プロセス管理部２３は、回線１の回線毎プロセスカウンタ３３から１を減算し、プロセス管理テーブル３４から呼出しプロセス０５Ｃを削除する。
【０１７８】
残っている再呼出しプロセス０１Ｒと再呼出しプロセス０５Ｒは、再び再呼出し時刻Ｔｑになっているか判定し（Ｓ６０）、再呼出し時刻Ｔｑになるまで、実行状態と待ち状態を繰り返し、再呼出し時刻Ｔｑになった時点で、上記の呼出しプロセス０１Ｃと呼出しプロセス０５Ｃと同様に排他制御を行いながら、それぞれ発呼処理を実行することになる。
【０１７９】
（各部の詳細処理フロー）
以下に、サーバ１５に含まれるスタッフ情報管理部２０、運行テーブル作成部２１、回線割当部２２、プロセス管理部２３、発呼処理部２４、自己申告受信部２７、電子メール送受信部２８、スタッフ状況更新部２９、設定変更部３０の詳細処理について説明する。
【０１８０】
スタッフ情報管理部２０は、作業者端末１４から入力されるスタッフ情報を、図３に例示したスタッフ情報データベース３１に登録する。また、スタッフ情報データベース３１内のデータの変更、表示も作業者端末１４からの要求により行う。
【０１８１】
図１８に示すように、運行テーブル作成部２１は、サーバ１５に内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ１００）。
【０１８２】
運行テーブル作成部２１は、スタッフ情報データベース３１から、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ１０１）。
【０１８３】
運行テーブル作成部２１は、抽出したスタッフ情報から、図４に例示した運行テーブル３２を作成する（Ｓ１０２）。
【０１８４】
運行テーブル作成部２１は、１日１回、日付が変わる直前に実行することが望ましいが、日付をまたいだ期間（例えば、１月２０日０４時００分から１月２１日０３時５９分まで）の情報を抽出する場合は、カレンダー１６により日付だけではなく日時を取得し、呼出し時刻Ｔｐが現日時から所定期間内（例えば２４時間）と比較するようにすることで対応できる。
【０１８５】
図１９に示すように、回線割当部２２は、スキャン周期α（例えば１分）毎に実行され、カレンダー１６により、現在の時刻（ｔ）を取得する（Ｓ２００）。
【０１８６】
回線割当部２２は、取得した時刻（ｔ）から次回のスキャン時刻（ｔ＋α）までの間に当てはまる呼出し時刻Ｔｐが設定されているスタッフ情報を運行テーブル３２内で検出し、そのスタッフ情報のスタッフ番号Ｍを抽出する（Ｓ２０１）。
【０１８７】
次に、回線割当部２２は、回線毎プロセスカウンタ３３を参照して、割当てられたプロセス数が最少の回線の回線番号Ｌ（以下、回線Ｌという）を取得する（Ｓ２０２）。
【０１８８】
回線割当部２２は、取得した回線Ｌ用の回線毎プロセスカウンタ３３に２を加算し（Ｓ２０３）、発呼処理部２４の呼出しプロセスと再呼出しプロセスとして、呼出しプロセス識別子（例えば０１Ｃ、０３Ｃ、０４Ｃ、・・）と再呼出しプロセス識別子（例えば０１Ｒ、０３Ｒ、０４Ｒ、・・）を当該回線用のプロセス管理テーブル３４に同時に登録する（Ｓ２０４）。
【０１８９】
回線割当部２２は、検索が運行テーブル３２の最後に達したかを判定し、最後に達するまで検索を繰り返す（Ｓ２０５）。
【０１９０】
回線割当部２２は、上記の処理をスキャン周期α毎に繰り返し行う（Ｓ２０６）。
【０１９１】
図２０に示すように、プロセス管理部２３は、プロセス管理テーブル３４に登録された発呼処理部２４の呼出しプロセスと再呼出しプロセスを、各プロセスの識別子と回線Ｌを通知して、並列して起動する（Ｓ３００）。
【０１９２】
例えば、プロセス管理部２３は、プロセス管理テーブル３４の登録に従って、（プロセス０１Ｃ、 回線１）、（プロセス０３Ｃ、 回線２）、（プロセス０１Ｒ、 回線１）という情報を、プロセスを生成する際にプロセスに割り当てられる一次メモリ内のワークエリア（プロセス制御ブロックＰＣＢなど）に設定するとともに、発呼処理部２４のプロセスを実行に移す。
【０１９３】
また、プロセス管理部２３は、プロセスが終了する際に、プロセス識別子と回線Ｌとともに、プロセスから送信されてくるイベントを受信し、そのイベントの種類を判定し、次の処理を行う（Ｓ３０１）。
【０１９４】
待ち状態の場合：
プロセス管理部２３は、現状を維持したまま、該当プロセスを再度実行できるまで待つ（Ｓ３０２）。
【０１９５】
呼出し前自己申告ありの場合：
プロセス管理部２３は、まず、該当呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０３）、さらに対応する再呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除する（Ｓ３０４）。
【０１９６】
例えば、該当呼出しプロセス識別子呼出しがプロセス０１Ｃであったとき、対応する再呼出しプロセス識別子は、同じスタッフ番号０１を含むプロセス０１Ｒとなる。
【０１９７】
プロセス管理部２３は、回線毎プロセスカウンタ３３の回線Ｌのカウンタから２を減算する（Ｓ３０５）。
【０１９８】
呼出し終了の場合：
図２１に示すように、プロセス管理部２３は、該当呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０６）、回線毎プロセスカウンタ３３の回線Ｌのカウンタから１を減算する（Ｓ３０７）。
【０１９９】
再呼出し前自己申告あり、再呼出し終了の場合：
図２１に示すように、プロセス管理部２３は、該当再呼出しプロセス識別子を回線Ｌ用のプロセス管理テーブル３４から削除し（Ｓ３０８）、回線毎プロセスカウンタ３３の回線Ｌのカウンタから１を減算する（Ｓ３０９）。
【０２００】
図２２に示すように、発呼処理部２４は、プロセス管理部２３から起動時に通知されるプロセス識別子と回線Ｌを受信し、プロセス識別子に含まれるスタッフ番号Ｍを取得し（Ｓ４００）、運行テーブル３２からスタッフ番号Ｍのスタッフ情報を読み出す（Ｓ４０１）。
【０２０１】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４０２）。
【０２０２】
発呼処理部２４は、呼出しルートでは、スタッフ情報の自己申告フラグを判定し（Ｓ４０３）、１（自己申告あり）の場合は、「呼出し前自己申告あり」イベントをプロセス管理部２３に送信し、プロセスを終了する（Ｓ４０４）。０（自己申告なし）の場合は、スタッフ情報から呼出し時刻Ｔｐを取得する（Ｓ４０５）。
【０２０３】
発呼処理部２４は、再呼出しルートでは、スタッフ情報の自己申告フラグを判定し、１（自己申告あり）の場合は、「再呼出し前自己申告あり」イベントをプロセス管理部２３に送信し、プロセスを終了する（Ｓ４０７）。０（自己申告なし）の場合は、スタッフ情報から再呼出し時刻Ｔｑを取得する（Ｓ４０８）。
【０２０４】
発呼処理部２４は、カレンダー１６により、現在の時刻（ｔ）を取得し（Ｓ４０９）、現在の時刻（ｔ）が、呼出し時刻Ｔｐか再呼出し時刻Ｔｑ以降かを判定する（Ｓ４１０）。つまり実行しようとしているプロセスが実行時間になっているかを判断する。
【０２０５】
発呼処理部２４は、実行時間になっていないと判定した場合、「待ち状態」イベントをプロセス管理部２３に送信して、実行待ち状態に遷移する（Ｓ４１１）。
【０２０６】
一方、図２３に示すように、発呼処理部２４は、実行時間になっていると判定した場合、回線使用状況テーブル３５から回線Ｌの状況を取得し（Ｓ４１２）、０（空）か判定する（Ｓ４１３）。
【０２０７】
発呼処理部２４は、回線Ｌが使用中である場合、「待ち状態」イベントをプロセス管理部２３に送信して、実行待ち状態に遷移する（Ｓ４１４）。
【０２０８】
発呼処理部２４は、回線Ｌが空いている場合、回線使用状況テーブル３５の回線Ｌの状況を１（使用）に変更し（Ｓ４１５）、スタッフ情報からスタッフ電話番号Ｄを取得する（Ｓ４１６）。
【０２０９】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４１７）。
【０２１０】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「呼出し中」に更新するように要求し（Ｓ４１８）、再呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「再呼出し中」に更新するように要求する（Ｓ４１９）。
【０２１１】
つづいて、図２４に示すように、発呼処理部２４は、回線Ｌ通信制御部２５にスタッフ電話番号Ｄを送信して発呼させるとともに（Ｓ４２０）、呼出しカウンタに１を加算し（Ｓ４２１）、呼出し継続タイマーＴａ（例えば２０秒）を起動し（Ｓ４２２）、応答待ち状態で待機する（Ｓ４２３）。
【０２１２】
ここで、呼出しカウンタは、プロセスを生成する際にプロセスに割り当てられる一次メモリ内のワークエリア（プロセス制御ブロックＰＣＢなど）を使ってカウントするため、図２の構成図には特に明示していない。同様にプロセス中で使用する呼出し継続タイマーＴａ等の各種タイマーも、サーバ１５に内蔵されたソフトウェアタイマーを利用するため、図２の構成図には特に明示していない。
【０２１３】
発呼処理部２４は、呼出し継続タイマーＴａがタイムアウトすると（Ｓ４２４）、呼出しカウンタが所定回数（例えば３回）になったかを判定し（Ｓ４２５）、まだ所定回数に達していない場合、呼出し間隔タイマーＴｂ（例えば３０秒）を起動し（Ｓ４２６）、再発呼を待ち、呼出し間隔タイマーＴｂがタイムアウトした時点で、再び発呼処理を繰り返す（Ｓ４２７）。
【０２１４】
発呼処理部２４は、呼出しカウンタが所定回数に達した場合、回線使用状況テーブル３５の回線Ｌの状況を０に変更する（Ｓ４２８）。
【０２１５】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４２９）。
【０２１６】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９に「呼出し応答なし」を通知し（Ｓ４３０）、「呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４３１）。再呼出しルートでは、スタッフ状況更新部２９に「再呼出し応答なし」を通知し（Ｓ４３２）、「再呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４３３）。
【０２１７】
一方、図２５に示すように、発呼処理部２４は、応答待ち状態で待機しているときに（Ｓ４２３）、スタッフ電話機１３から回線Ｌ通信制御部２５を経由して応答を受信すると（Ｓ４３４）、スタッフ情報から音声応答情報を取得し、音声ボード１７により音声再生し、スタッフに聞かせる（Ｓ４３５）。
【０２１８】
発呼処理部２４は、その後、回線を切断するように回線Ｌ通信制御部に通知し（Ｓ４３６）、回線使用状況テーブル３５の回線Ｌの状況を０に変更する（Ｓ４３７）。
【０２１９】
発呼処理部２４は、プロセス識別子から呼出しプロセスか再呼出しプロセスかを判定し、呼出しルートと再呼出しルートに分かれる（Ｓ４３８）。
【０２２０】
発呼処理部２４は、呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「呼出し応答」に更新するように要求し（Ｓ４３９）、「呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４４０）。再呼出しルートでは、スタッフ状況更新部２９にスタッフ状況を「再呼出し応答」に更新するように要求し（Ｓ４４１）、「再呼出し終了」イベントをプロセス管理部２３に送信する（Ｓ４４２）。
【０２２１】
ここで図示した発呼処理部２４は、呼出しプロセスと再呼出しプロセスを１つの処理ルーチンで実行する構成として説明している。しかし、処理中でプロセス識別子から呼出しプロセスか再呼出しプロセスかを判定している箇所を省き、呼出しルートの処理のみを含む呼出しルーチン部と、再呼出しルートの処理のみを含む再呼出しルーチン部の２つの処理ルーチンを、別々に発呼処理部２４に設ける構成であってもよい。
【０２２２】
自己申告受信部２７は、着信回線通信制御部２６から着信呼情報を受信し、着信呼情報内の発信者電話番号をスタッフ識別情報として、スタッフ状況を「自己申告あり」に更新するようにスタッフ状況更新部２９に要求する。
【０２２３】
電子メール送受信部２８は、インターネット１０経由で受信した電子メールの発信元メールアドレスをスタッフ識別情報として、スタッフ状況を「自己申告あり」に更新するようにスタッフ状況更新部２９に要求する一方、スタッフ状況更新部２９からの要求により管理者携帯電話機１１に督促メールを送信する。
【０２２４】
図２６に示すように、スタッフ状況更新部２９は、上記したように、発呼処理部２４、自己申告受信部２７、及び電子メール送受信部２８からスタッフ識別情報とともに送信されてくる各種のスタッフ状況更新要求を受信する（Ｓ５００）。
【０２２５】
スタッフ状況更新部２９は、受信したスタッフ識別情報を判定し（Ｓ５０１）、発呼処理部２４から送信されてきたスタッフ番号Ｍであれば、スタッフ番号Ｍで運行テーブル３２を検索し（Ｓ５０２）、自己申告受信部２７から送信されてきた発信者電話番号であれば、発信者電話番号で運行テーブル３２を検索し（Ｓ５０３）、電子メール送受信部２８から送信されてきた発信元Ｅメールアドレスであれば、発信元Ｅメールアドレスで運行テーブル３２を検索し（Ｓ５０４）、該当するスタッフのスタッフ情報を読み出す（Ｓ５０５）。
【０２２６】
次に、スタッフ状況更新部２９は、要求されている更新情報を判定し（Ｓ５０６）、「自己申告あり」なら、スタッフ状況フラグ欄Ｆの自己申告フラグに１を設定し（Ｓ５０７）、「呼出し中」なら、スタッフ状況フラグ欄Ｆの呼出しフラグＦ１に１を設定し（Ｓ５０８）、「再呼出し中」なら、スタッフ状況フラグ欄Ｆの再呼出しフラグＦ３に１を設定し（Ｓ５０９）、「呼出し応答」なら、スタッフ状況フラグ欄Ｆの呼出し応答フラグＦ２に１を設定し（Ｓ５１０）、「再呼出し応答」なら、スタッフ状況フラグ欄Ｆの再呼出し応答フラグＦ４に１を設定し（Ｓ５１１）、自己申告確認タイマーＴｃ（例えば１０分）を起動する（Ｓ５１２）。
【０２２７】
スタッフ状況更新部２９は、更新したスタッフ状況を含むスタッフ情報を運行テーブル３２に記録するとともに（Ｓ５１３）、作業者端末１４に通知する（Ｓ５１４）。
【０２２８】
また、図２７に示すように、スタッフ状況更新部２９は、要求されている更新情報が「呼出し応答なし」なら、スタッフ情報から管理者Ｅメールアドレスを取得し（Ｓ５１５）、取得した管理者Ｅメールアドレス宛てに呼出し無応答時の督促メールを送信するように電子メール送受信部２８に要求する（Ｓ５１６）。
【０２２９】
同様に、スタッフ状況更新部２９は、要求されている更新情報が「再呼出し応答なし」なら、スタッフ情報から管理者Ｅメールアドレスを取得し（Ｓ５１７）、取得した管理者Ｅメールアドレス宛てに再呼出し無応答時の督促メールを送信するように電子メール送受信部２８に要求する（Ｓ５１８）。
【０２３０】
スタッフ状況更新部２９は、要求されている更新情報が「再呼出し応答」のときに起動した自己申告確認タイマーＴｃがタイムアウトすると（Ｓ５１９）、要求のあったスタッフ番号Ｍで運行テーブル３２を検索し（Ｓ５２０）、該当スタッフのスタッフ情報を読み出す（Ｓ５２１）。
【０２３１】
スタッフ状況更新部２９は、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５が１か判定し（Ｓ５２２）、もし１でない場合、すなわちスタッフが再呼出しに応答したにもかかわらず、未だに自己申告をしてこないときは、アラームを作業者端末１４に通知し警告する（Ｓ５２３）。
【０２３２】
設定変更部３０は、作業者端末１４から入力された情報により、運行テーブル３２のスタッフ情報を変更する。
【０２３３】
また、設定変更部３０は、管理者Ｅメールアドレス宛てに送信した督促メールに従って、管理者がスタッフを呼出して、起床を確認した場合に、管理者携帯電話機１１からのインターネット１０経由アクセスを受信し、スタッフ状況フラグ欄Ｆの自己申告フラグＦ５に１を設定することもできる。
【０２３４】
さらに、設定変更部３０は、作業者端末１４からの入力により、各種タイマーの値を変更するようにしてもよい。
【０２３５】
＜発明の第２の実施の形態＞
本発明の第２の実施の形態のコールシステムは、図１に示したサーバ１５に以下に説明する機能を追加したメインサーバ１５ａと、スタッフ情報管理部２０と運行テーブル作成部２１を除いた機能を実装した複数のサブサーバ１５ｂ、１５ｃとを、インターネット１０により接続する構成となる。
【０２３６】
第２の実施の形態のコールシステムは、旅行ツアー参加者に対して、ツアー当日に通知する場合や、バスツアーなどの集合時間に遅れないように、集合時間前に呼出しを行う場合に利用できる。
【０２３７】
旅行ツアーの場合は、全国各地で企画される複数の旅行ツアーの参加者情報を一元管理するため、参加者数が多くなる上に、同じ集合時間となる旅行ツアーも複数あるため、同時に呼出し時刻Ｔｐになる参加者数も増えることになり、図１のような１台のサーバ１５では回線数が十分実装できず、呼出し遅延が発生しやすくなる。
【０２３８】
そこで、メインサーバ１５ａで参加者情報を一元管理する一方で、呼出し処理は各地に配置したサブサーバ１５ｂ、１５ｃに分散して行わせることにより、呼出し遅延を防ぐことが可能となる。
【０２３９】
図１に示したサーバ１５と図２８に示したメインサーバ１５ａの相違点について、以下に説明する。
【０２４０】
（データ構成）
メインサーバ１５ａのスタッフ情報データベース３１ａは、図３に例示したスタッフ情報データベース３１の各スタッフのスタッフ基本データ３１１に地域識別情報を追加したものとする。
【０２４１】
地域識別情報とは、各スタッフの住所や郵便番号であったり、旅行ツアーの集合場所であったりする。
【０２４２】
（第２の運行テーブル作成部２１ａ）
図２９に示すように、第２の運行テーブル作成部２１ａは、メインサーバ１５ａに内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ６００）。
【０２４３】
第２の運行テーブル作成部２１ａは、スタッフ情報データベース３１ａから、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ６０１）。
【０２４４】
第２の運行テーブル作成部２１ａは、抽出したスタッフ情報の地域識別情報により、どのサブサーバ１５ｂ、１５ｃに転送するかを決定する（Ｓ６０２）。
【０２４５】
第２の運行テーブル作成部２１ａは、決定したサブサーバに抽出したスタッフ情報を転送して第２の運行テーブル３２ａを作成する（Ｓ６０３）。
【０２４６】
なお、メインサーバ１５ａも発呼処理を行うことができるので、第２の運行テーブル作成部２１ａは、メインサーバ１５ａが担当する地域については、メインサーバ１５ａ内に第２の運行テーブル３２ａを作成する。
【０２４７】
本発明の第２の実施の形態のコールシステムでは、第２の運行テーブル３２ａが作成されたあとは、メインサーバ１５ａ及びサブサーバ１５ｂ、１５ｃが、各々に作成された第２の運行テーブル３２ａに従って、図１９から図２７に示した処理をそれぞれ独立して実行し、接続した電話網１２ａ、１２ｂ、１２ｃを介して、スタッフ電話機１３ａ、１３ｂ、１３ｃと管理者携帯電話機１１ａ、１１ｂ、１１ｃにアクセスする。
【０２４８】
＜発明の第３の実施の形態＞
人間の習性として、すぐに起床できる人となかなか起床できない人がいる。さらに、なかなか起床できない人は、毎回寝過してしまう傾向にある。
【０２４９】
そこで、本発明の第３の実施の形態のコールシステムでは、こうした傾向を考慮して、起床できなかったスタッフを特定し、回線割当時に通常のスタッフの呼出しプロセスと区別して割り当てることで、回線を効率よく使用する機能をさらに追加する。
【０２５０】
発明の第３の実施の形態では、図１に示した最良の形態のコールシステムと構成は同じであるが、サーバ１５に接続した複数の回線を、再呼出し可能性の高いスタッフ用と通常のスタッフ用にあらかじめ分配しておく。
【０２５１】
例えば、２０回線が接続されている場合、再呼出し可能性の高いスタッフ用には１５回線を割り付け、通常のスタッフ用には残りの５回線を割り付ける。この割り付け回線数の比率は、再呼出し可能性の高いスタッフ数により変更できるものとする。
【０２５２】
前述した最良の形態と第３の実施の形態との相違点に絞って、以下に説明する。その他の部分につては、両者とも同じである。
【０２５３】
（データ構成）
スタッフ情報データベース３１ｂは、図３に例示したスタッフ情報データベース３１の各スタッフのスタッフ基本データ３１１に監視対象フラグを追加したものとする。
【０２５４】
第３の運行テーブル３２ｂには、スタッフ情報データベース３１ｂと同様に、図４に例示した運行テーブル３２に監視対象フラグを追加したものとする。
【０２５５】
（第３の運行テーブル作成部２１ｂ）
図３０に示すように、第３の運行テーブル作成部２１ｂは、当日の第３の運行テーブル３２ｂの作成にかかる前に、前日の第３の運行テーブル３２ｂにスタッフ状況更新部２９によって設定された各スタッフのスタッフ状況を読み出す（Ｓ７００）。
【０２５６】
第３の運行テーブル作成部２１ｂは、スタッフ状況フラグ欄Ｆの再呼出しフラグＦ３の値をスタッフ情報データベース３１ｂの各スタッフの監視対象フラグに設定する（Ｓ７０１）。
【０２５７】
つまり、再呼出しされたスタッフは、再呼出しフラグＦ３が１になっているため、スタッフ情報データベース３１ｂの監視対象フラグに１が設定され、再呼出しされずに自己申告したスタッフは、再呼出しフラグＦ３が０になので、スタッフ情報データベース３１ｂの監視対象フラグに０が設定される。
【０２５８】
第３の運行テーブル作成部２１ｂは、サーバ１５に内蔵されたカレンダー１６により、当日の日付を取得する（Ｓ７０２）。
【０２５９】
第３の運行テーブル作成部２１ｂは、スタッフ情報データベース３１ｂから、取得した日付と一致する呼出し日付ｄｄを有するスタッフ情報を抽出する（Ｓ７０３）。
【０２６０】
したがって、抽出されたスタッフ情報には、先ほど設定した監視対象フラグの値が含まれることになる。
【０２６１】
第３の運行テーブル作成部２１ｂは、抽出したスタッフ情報から当日の第３の運行テーブル３２ｂを作成する（Ｓ７０４）。
【０２６２】
（第２の回線割当部２２ａ）
図３１に示すように、第２の回線割当部２２ａは、スキャン周期α（例えば１分）毎に実行され、カレンダー１６により、現在の時刻（ｔ）を取得する（Ｓ８００）。
【０２６３】
第２の回線割当部２２ａは、取得した時刻（ｔ）から次回のスキャン時刻（ｔ＋α）までの間に当てはまる呼出し時刻Ｔｐが設定されているスタッフ情報を第３の運行テーブル３２ｂ内で検出し、そのスタッフ情報のスタッフ番号Ｍを抽出する（Ｓ８０１）。
【０２６４】
次に、第２の回線割当部２２ａは、スタッフ情報の監視対象フラグを判定し（Ｓ８０２）、監視対象フラグが１ならば、回線毎プロセスカウンタ３３を参照して、再呼出し可能性の高いスタッフ用に割り付けられた複数の回線のうちで、割当てられたプロセス数が最少の回線の回線Ｌを取得する（Ｓ８０３）。
【０２６５】
一方、第２の回線割当部２２ａは、スタッフ情報の監視対象フラグが０ならば、回線毎プロセスカウンタ３３を参照して、通常のスタッフ用に割り付けられた残りの回線のうちで、割当てられたプロセス数が最少の回線の回線Ｌを取得する（Ｓ８０４）。
【０２６６】
第２の回線割当部２２ａは、取得した回線Ｌ用の回線毎プロセスカウンタ３３に２を加算するとともに（Ｓ８０５）、発呼処理部２４の呼出しプロセスと再呼出しプロセスとして、呼出しプロセス識別子（例えば０１Ｃ、０３Ｃ、０４Ｃ、・・）と再呼出しプロセス識別子（例えば０１Ｒ、０３Ｒ、０４Ｒ、・・）を当該回線用のプロセス管理テーブル３４に同時に登録する（Ｓ８０６）。
【０２６７】
第２の回線割当部２２ａは、検索が第３の運行テーブル３２ｂの最後に達したかを判定し、最後に達するまで検索を繰り返す（Ｓ８０７）。
【０２６８】
第２の回線割当部２２ａは、上記の処理をスキャン周期α毎に繰り返し行う（Ｓ８０８）。
【０２６９】
本発明の第３の実施の形態のコールシステムでは、プロセス管理テーブル３４が作成されたあとは、図２０から図２７に示した処理を実行する。
【０２７０】
通常のスタッフの場合は、すぐに応答するため、回線が使用中となった状態は短く、プロセスが素早く実行されていく。その上、通常のスタッフの再呼出しプロセスは、既に自己申告されている可能性が高いので、実際に再呼出し処理を行わずに終了する確率が高い。
【０２７１】
一方、再呼出し可能性の高いスタッフの場合は、呼出しを３回行わなければならない可能性が高く、回線が使用中となった状態が長くなり、多くのプロセスが待ち状態になってしまう。その上、再呼出しプロセスは、実際に再呼出し処理を行うことになるため、ますます回線が使用中となった状態が長くなってしまう。
【０２７２】
そこで、本発明の第３の実施の形態では、再呼出し可能性の高いスタッフ用の回線と通常のスタッフ用の回線とに分けることで、通常のスタッフの場合は、割当てられたプロセス数が多くなっていたとしても、通常のスタッフ用の回線を割当てられるようにしている。
【０２７３】
また、再呼出し可能性の高いスタッフ用の回線を多くすることで、再呼出し可能性の高いスタッフのプロセスが待ち状態になるのを防いでいる。
【符号の説明】
【０２７４】
１０ インターネット
１１ １１ａ、１１ｂ、１１ｃ 管理者携帯電話機
１２、１２ａ、１２ｂ、１２ｃ 電話網
１３、１３ａ、１３ｂ、１３ｃ スタッフ電話機
１４ 作業者端末
１５ サーバ
１５ａ メインサーバ
１５ｂ、１５ｃ サブサーバ
１６ カレンダー
１７ 音声ボード
２０ スタッフ情報管理部
２１ 運行テーブル作成部
２１ａ 第２の運行テーブル作成部
２１ｂ 第３の運行テーブル作成部
２２ 回線割当部
２２ａ 第２の回線割当部
２３ プロセス管理部
２４ 発呼処理部
２５ 回線通信制御部
２６ 着信回線通信制御部
２７ 自己申告受信部
２８ 電子メール送受信部
２９ スタッフ状況更新部
３０ 設定変更部
３１、３１ａ、３１ｂ スタッフ情報データベース
３１１ スタッフ基本データ
３１２ スタッフ予定データ
３２ 運行テーブル
３２ａ 第２の運行テーブル
３２ｂ 第３の運行テーブル
３３ 回線毎プロセスカウンタ
３４ プロセス管理テーブル
３５ 回線使用状況テーブル
【特許請求の範囲】
【請求項１】
スタッフ電話機及び管理者携帯電話機と通信を行うために、電話網に接続された複数の回線通信制御部と着信回線通信制御部を実装した音声ボード、カレンダー、一次メモリ及び二次メモリを具備したサーバと、前記サーバに接続された作業者端末とを備えたコールシステムであって、
前記サーバは、
前記作業者端末から、呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースとして前記二次メモリに登録するためのスタッフ情報管理部と、
前記カレンダーから日時を取得し、当該日時から所定期間内に該当する前記呼出し日付と前記呼出し時刻を含む前記スタッフ情報を前記スタッフ情報ベータベースから抽出し、前記一次メモリに運行テーブルを作成する運行テーブル作成部と、
所定間隔で前記カレンダーから現時刻を取得し、当該現時刻から前記呼出し時刻に達する前記スタッフ情報を検出するとともに、前記一次メモリの回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択し、発呼処理部の呼出しプロセスを再呼出しプロセスとして、それぞれのプロセス識別子を当該回線用のプロセス管理テーブルに同時に登録し、前記回線毎プロセスカウンタの当該回線用のカウンタ数に２を加算する回線割当部と、
前記プロセス管理テーブルに登録された前記呼出しプロセスと前記再呼出しプロセスを並列して起動し、起動した前記呼出しプロセスと前記再呼出しプロセスから受信するイベントが、
呼出し前自己申告ありの場合、前記呼出しプロセスのプロセス識別子と、当該呼出しプロセスに対応する再呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から２を減算し、
呼出し終了の場合、前記呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から１を減算し、
再呼出し前自己申告あり及び再呼出し終了の場合、前記再呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から１を減算するプロセス管理部と、
前記プロセス管理部から起動された前記呼出しプロセスと前記再呼出しプロセスのそれぞれのプロセス識別子に含まれるスタッフ番号に該当する前記スタッフ情報を前記運行テーブルから読み出し、当該スタッフ情報のスタッフ状況が自己申告ありの場合、前記呼出し前自己申告ありイベントまたは前記再呼出し前自己申告ありイベントを前記プロセス管理部に送信し、
当該スタッフ情報のスタッフ状況が自己申告なしの場合、前記一次メモリの回線使用状況テーブルを参照し、指定回線が空きならば、前記回線使用状況テーブルを使用に変更し、当該スタッフ情報に設定されたスタッフ電話番号に前記回線通信制御部から所定回数発呼を繰り返し、前記所定回数に達した時または応答時に呼出し終了イベントまたは再呼出し終了イベントを前記プロセス管理部に送信し、
処理によりスタッフ状況に変化が生じると、前記スタッフ番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する発呼処理部と、
前記着信回線通信制御部から着信呼情報を受信すると、当該着信呼情報内の発信者電話番号とともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信する自己申告受信部と、
前記発呼処理部、及び前記自己申告受信部から、それぞれスタッフ識別情報として前記スタッフ番号及び前記発信者電話番号とともに送信された前記スタッフ状況更新要求により、当該スタッフ識別情報に該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する前記スタッフ状況更新部
とを含むことを特徴とするコールシステム。
【請求項２】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項１に記載のコールシステム。
【請求項３】
前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項１または２に記載のコールシステム。
【請求項４】
前記電子メール送受信部は、インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項３に記載のコールシステム。
【請求項５】
前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項１ないし４のいずれか１項に記載のコールシステム。
【請求項６】
前記サーバとインターネットを介して接続した前記回線割当部と、前記プロセス管理部と、前記発呼処理部と、前記自己申告受信部と、前記スタッフ状況更新部とを具備した複数のサブサーバをさらに含み、
前記スタッフ情報管理部は、地域識別情報をさらに含む前記スタッフ情報を前記スタッフ情報ベータベースに登録し、
前記運行テーブル作成部は、前記スタッフ情報ベータベースから抽出した前記スタッフ情報に含まれる前記地域識別情報により、該当する前記サブサーバに前記スタッフ情報を転送して前記運行テーブルを作成することを特徴とする請求項１に記載のコールシステム。
【請求項７】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項６に記載のコールシステム。
【請求項８】
前記サーバ及び前記サブサーバは、前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項６または７に記載のコールシステム。
【請求項９】
前記電子メール送受信部は、前記インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項８に記載のコールシステム。
【請求項１０】
前記サーバは、前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項６ないし９のいずれか１項に記載のコールシステム。
【請求項１１】
前記運行テーブル作成部は、前日の前記運行テーブルのスタッフ情報のスタッフ状況フラグ欄に含まれる再呼出しフラグの値を、前記スタッフ情報ベータベースの前記スタッフ情報の監視対象フラグに設定し、前記監視対象フラグを含む前記スタッフ情報の当日の前記運行テーブルを作成し、
前記回線割当部は、前記回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択する際に、前記スタッフ情報の前記監視対象フラグが０の場合、通常のスタッフ用に割り付けられた複数の回線のうちから選択し、前記スタッフ情報の前記監視対象フラグが１の場合、再呼出し可能性の高いスタッフ用に割り付けられた複数の回線のうちから選択することを特徴とする請求項１に記載のコールシステム。
【請求項１２】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項１１に記載のコールシステム。
【請求項１３】
前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項１１または１２に記載のコールシステム。
【請求項１４】
前記電子メール送受信部は、インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項１３に記載のコールシステム。
【請求項１５】
前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項１１ないし１４のいずれか１項に記載のコールシステム。
【請求項１】
スタッフ電話機及び管理者携帯電話機と通信を行うために、電話網に接続された複数の回線通信制御部と着信回線通信制御部を実装した音声ボード、カレンダー、一次メモリ及び二次メモリを具備したサーバと、前記サーバに接続された作業者端末とを備えたコールシステムであって、
前記サーバは、
前記作業者端末から、呼出し日付と呼出し時刻を含むスタッフ情報をスタッフ情報ベータベースとして前記二次メモリに登録するためのスタッフ情報管理部と、
前記カレンダーから日時を取得し、当該日時から所定期間内に該当する前記呼出し日付と前記呼出し時刻を含む前記スタッフ情報を前記スタッフ情報ベータベースから抽出し、前記一次メモリに運行テーブルを作成する運行テーブル作成部と、
所定間隔で前記カレンダーから現時刻を取得し、当該現時刻から前記呼出し時刻に達する前記スタッフ情報を検出するとともに、前記一次メモリの回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択し、発呼処理部の呼出しプロセスを再呼出しプロセスとして、それぞれのプロセス識別子を当該回線用のプロセス管理テーブルに同時に登録し、前記回線毎プロセスカウンタの当該回線用のカウンタ数に２を加算する回線割当部と、
前記プロセス管理テーブルに登録された前記呼出しプロセスと前記再呼出しプロセスを並列して起動し、起動した前記呼出しプロセスと前記再呼出しプロセスから受信するイベントが、
呼出し前自己申告ありの場合、前記呼出しプロセスのプロセス識別子と、当該呼出しプロセスに対応する再呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から２を減算し、
呼出し終了の場合、前記呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から１を減算し、
再呼出し前自己申告あり及び再呼出し終了の場合、前記再呼出しプロセスのプロセス識別子を前記プロセス管理テーブルから削除し、前記回線毎プロセスカウンタのカウンタ数から１を減算するプロセス管理部と、
前記プロセス管理部から起動された前記呼出しプロセスと前記再呼出しプロセスのそれぞれのプロセス識別子に含まれるスタッフ番号に該当する前記スタッフ情報を前記運行テーブルから読み出し、当該スタッフ情報のスタッフ状況が自己申告ありの場合、前記呼出し前自己申告ありイベントまたは前記再呼出し前自己申告ありイベントを前記プロセス管理部に送信し、
当該スタッフ情報のスタッフ状況が自己申告なしの場合、前記一次メモリの回線使用状況テーブルを参照し、指定回線が空きならば、前記回線使用状況テーブルを使用に変更し、当該スタッフ情報に設定されたスタッフ電話番号に前記回線通信制御部から所定回数発呼を繰り返し、前記所定回数に達した時または応答時に呼出し終了イベントまたは再呼出し終了イベントを前記プロセス管理部に送信し、
処理によりスタッフ状況に変化が生じると、前記スタッフ番号とともにスタッフ状況更新要求をスタッフ状況更新部に送信する発呼処理部と、
前記着信回線通信制御部から着信呼情報を受信すると、当該着信呼情報内の発信者電話番号とともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信する自己申告受信部と、
前記発呼処理部、及び前記自己申告受信部から、それぞれスタッフ識別情報として前記スタッフ番号及び前記発信者電話番号とともに送信された前記スタッフ状況更新要求により、当該スタッフ識別情報に該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する前記スタッフ状況更新部
とを含むことを特徴とするコールシステム。
【請求項２】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項１に記載のコールシステム。
【請求項３】
前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項１または２に記載のコールシステム。
【請求項４】
前記電子メール送受信部は、インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項３に記載のコールシステム。
【請求項５】
前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項１ないし４のいずれか１項に記載のコールシステム。
【請求項６】
前記サーバとインターネットを介して接続した前記回線割当部と、前記プロセス管理部と、前記発呼処理部と、前記自己申告受信部と、前記スタッフ状況更新部とを具備した複数のサブサーバをさらに含み、
前記スタッフ情報管理部は、地域識別情報をさらに含む前記スタッフ情報を前記スタッフ情報ベータベースに登録し、
前記運行テーブル作成部は、前記スタッフ情報ベータベースから抽出した前記スタッフ情報に含まれる前記地域識別情報により、該当する前記サブサーバに前記スタッフ情報を転送して前記運行テーブルを作成することを特徴とする請求項１に記載のコールシステム。
【請求項７】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項６に記載のコールシステム。
【請求項８】
前記サーバ及び前記サブサーバは、前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項６または７に記載のコールシステム。
【請求項９】
前記電子メール送受信部は、前記インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項８に記載のコールシステム。
【請求項１０】
前記サーバは、前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項６ないし９のいずれか１項に記載のコールシステム。
【請求項１１】
前記運行テーブル作成部は、前日の前記運行テーブルのスタッフ情報のスタッフ状況フラグ欄に含まれる再呼出しフラグの値を、前記スタッフ情報ベータベースの前記スタッフ情報の監視対象フラグに設定し、前記監視対象フラグを含む前記スタッフ情報の当日の前記運行テーブルを作成し、
前記回線割当部は、前記回線毎プロセスカウンタを参照しカウンタ数が最少の回線を選択する際に、前記スタッフ情報の前記監視対象フラグが０の場合、通常のスタッフ用に割り付けられた複数の回線のうちから選択し、前記スタッフ情報の前記監視対象フラグが１の場合、再呼出し可能性の高いスタッフ用に割り付けられた複数の回線のうちから選択することを特徴とする請求項１に記載のコールシステム。
【請求項１２】
前記発呼処理部は、前記呼出しプロセスのための呼出しルーチン部と、前記再呼出しプロセスのための再呼出しルーチン部とを含む請求項１１に記載のコールシステム。
【請求項１３】
前記発呼処理部が、前記スタッフ電話番号に前記回線通信制御部から前記所定回数発呼をしても応答がない場合、前記スタッフ情報に設定された管理者メールアドレス宛てに督促メールを送信する電子メール送受信部をさらに含む請求項１１または１２に記載のコールシステム。
【請求項１４】
前記電子メール送受信部は、インターネット経由で受信した電子メールの発信元メールアドレスとともに前記スタッフ状況更新要求を前記スタッフ状況更新部に送信し、
前記スタッフ状況更新部は、前記電子メール送受信部から送信された前記スタッフ状況更新要求により、前記発信元メールアドレスに該当する前記運行テーブルのスタッフ情報のスタッフ状況を更新するとともに、前記作業者端末に当該スタッフ状況を通知する請求項１３に記載のコールシステム。
【請求項１５】
前記作業者端末から前記運行テーブルのスタッフ情報を変更する設定変更部をさらに含む請求項１１ないし１４のいずれか１項に記載のコールシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１１−１７２０８７（Ｐ２０１１−１７２０８７Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−３５００４（Ｐ２０１０−３５００４）
【出願日】平成２２年２月１９日（２０１０．２．１９）
【特許番号】特許第４６８８９５９号（Ｐ４６８８９５９）
【特許公報発行日】平成２３年５月２５日（２０１１．５．２５）
【出願人】（５０８２５９３１９）進栄電気工業株式会社 (2)
【出願人】（５０８３０８５８１）ブロードバンドジャパン株式会社 (3)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２２年２月１９日（２０１０．２．１９）
【特許番号】特許第４６８８９５９号（Ｐ４６８８９５９）
【特許公報発行日】平成２３年５月２５日（２０１１．５．２５）
【出願人】（５０８２５９３１９）進栄電気工業株式会社 (2)
【出願人】（５０８３０８５８１）ブロードバンドジャパン株式会社 (3)
【Ｆターム（参考）】
[ Back to top ]