(57)【要約】【課題】複数の端末を用いた会議を行う際の処理負荷を軽減する。【解決手段】応答時間テーブル５２には、複数の音声端末２０それぞれについて、発呼してから応答メッセージを受信するまでの応答時間の履歴が記憶され、電話会議制御部３２は、応答時間テーブル５２に記憶されている応答時間の履歴に基づいて、単位時間に応答する音声端末２０の数が２以下となるように音声端末２０への発呼をスケジューリングしてスケジュール情報を発呼スケジュールテーブル５６に記憶する。そして、電話会議制御部３２は、発呼スケジュールテーブル５６に記憶されているスケジュール情報に基づいて、各音声端末２０への発呼を実行する。【選択図】図３
2017085366.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末それぞれについて、発呼してから応答するまでの応答時間の履歴を記憶する第１記憶部と、
前記第１記憶部に記憶されている前記応答時間の履歴に基づいて、単位時間に応答する端末の数が閾値以下となるように端末への発呼をスケジューリングしてスケジュール情報を第２記憶部に記憶させるスケジューリング機能部と、
前記第２記憶部に記憶されている前記スケジュール情報に基づいて、各端末への発呼を行う発呼部と、
を備える会議管理装置。
【請求項２】
前記スケジューリング機能部は、更に、発呼した端末の全てからの応答があるまでの時間が予め定めた時間内に収まるように端末への発呼をスケジューリングすることを特徴とする請求項１に記載の会議管理装置。
【請求項３】
前記スケジューリング機能部は、更に、同一タイミングで発呼する端末の数が予め定めた許容値を超えないように端末への発呼をスケジューリングすることを特徴とする請求項１又は２に記載の会議管理装置。
【請求項４】
発呼に対する応答があった端末からの音声をミキシングするミキシング部を更に備える、請求項１〜３のいずれか一項に記載の会議管理装置。
【請求項５】
請求項１〜４のいずれか一項に記載の会議管理装置と、
前記会議管理装置と接続された複数の端末と、を備える会議システム。
【請求項６】
複数の端末それぞれについて、発呼してから応答するまでの応答時間の履歴を第１記憶部に記憶し、
前記第１記憶部に記憶されている前記応答時間の履歴に基づいて、単位時間に応答する端末の数が閾値以下となるように端末への発呼をスケジューリングしてスケジュール情報を第２記憶部に記憶し、
前記第２記憶部に記憶されている前記スケジュール情報に基づいて、各端末への発呼を実行する、
処理をコンピュータが実行することを特徴とする会議管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、会議管理装置、会議システム、及び会議管理方法に関する。
【背景技術】
【０００２】
従来、電話回線を介して接続された複数の端末間で電話会議を行う技術について知られている（例えば、特許文献１、２等参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−２０７３３１号公報
【特許文献２】特開２０１０−８７６９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
電話会議を実現するための電話会議システムにおいては、電話会議を統括的に制御する会議管理装置（サーバ等）が、網内から複数の端末に対して発呼処理を行ったり、発呼に対して応答した端末間を接続したりする。
【０００５】
しかしながら、上記特許文献１、２等においては、会議管理装置の処理負荷については考慮されていない。
【０００６】
１つの側面では、本発明は、複数の端末を用いた会議を行う際の処理負荷を軽減することが可能な会議管理装置、会議システム及び会議管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
一つの態様では、会議管理装置は、複数の端末それぞれについて、発呼してから応答するまでの応答時間の履歴を記憶する第１記憶部と、前記第１記憶部に記憶されている前記応答時間の履歴に基づいて、単位時間に応答する端末の数が閾値以下となるように端末への発呼をスケジューリングしてスケジュール情報を第２記憶部に記憶させるスケジューリング機能部と、前記第２記憶部に記憶されている前記スケジュール情報に基づいて、各端末への発呼を行う発呼部と、を備えている。
【発明の効果】
【０００８】
複数の端末を用いた会議を行う際の処理負荷を軽減することができる。
【図面の簡単な説明】
【０００９】
【図１】一実施形態に係る電話会議システムの構成を概略的に示す図である。
【図２】会議管理サーバのハードウェア構成を示す図である。
【図３】会議管理サーバの機能ブロック図である。
【図４】図４（ａ）は、電話会議テーブルのデータ構造を示す図であり、図４（ｂ）は、応答時間テーブルのデータ構造を示す図である。
【図５】図５（ａ）は、作業用テーブルのデータ構造を示す図であり、図５（ｂ）は、発呼スケジュールテーブルのデータ構造を示す図である。
【図６】図６（ａ）は、電話会議テーブル登録処理を示すフローチャートであり、図６（ｂ）は、発呼スケジュールテーブル作成処理を示すフローチャートである。
【図７】図６（ｂ）のステップＳ２２（スケジューリング処理）の具体的な処理を示すフローチャートである。
【図８】図８（ａ）〜図８（ｃ）は、スケジューリング処理について説明するための図（その１）である。
【図９】図９（ａ）〜図９（ｃ）は、スケジューリング処理について説明するための図（その２）である。
【図１０】図１０（ａ）〜図１０（ｃ）は、スケジューリング処理について説明するための図（その３）である。
【図１１】図１１（ａ）〜図１１（ｃ）は、スケジューリング処理について説明するための図（その４）である。
【図１２】図１２（ａ）〜図１２（ｃ）は、スケジューリング処理について説明するための図（その５）である。
【図１３】図１３（ａ）〜図１３（ｃ）は、スケジューリング処理について説明するための図（その６）である。
【図１４】図１４（ａ）〜図１４（ｃ）は、スケジューリング処理について説明するための図（その７）である。
【図１５】図１５（ａ）〜図１５（ｃ）は、スケジューリング処理について説明するための図（その８）である。
【図１６】発呼実行処理を示すフローチャートである。
【図１７】ミキシング処理を示すフローチャートである。
【図１８】図１７のステップＳ７８の具体的処理を示すフローチャートである。
【図１９】比較例１を示す図である。
【図２０】比較例２を示す図である。
【図２１】変形例を示す図である。
【発明を実施するための形態】
【００１０】
以下、電話会議システムの一実施形態について、図１〜図１８に基づいて詳細に説明する。本実施形態の電話会議システムは、例えば、空港のスタッフによる音声端末を用いた電話会議を実現するためのシステムであり、スタッフ間での業務連絡等に利用される。
【００１１】
図１には、電話会議システム１００の構成が概略的に示されている。図１に示すように、電話会議システム１００は、多数の音声端末２０と、携帯基地局１６と、パケットコアノード１４と、音声網ゲートウェイ１２と、会議管理装置としての会議管理サーバ１０と、を備える。
【００１２】
音声端末２０は、他の音声端末２０との間で通話するための端末であり、ＩＰ（Internet Protocol）電話、一般加入電話、携帯電話、スマートフォン、ＰＨＳ（Personal Handy-phone System）などである。音声端末２０は、入力部（タッチパネルやキーボード）、表示部（ディスプレイ）、音声出力部（スピーカ）、制御部等を備える。制御部は、会議管理サーバ１０からの発呼を受信すると、表示部や音声出力部などを介してその旨をユーザに報知する。そして、電話会議の参加者が入力部を介して応答操作を実行すると、制御部は、応答メッセージを会議管理サーバ１０に送信する。応答メッセージを送信した音声端末２０に入力される参加者の音声は、会議管理サーバ１０においてミキシングされ、複数の音声端末２０に送信される。これにより、複数の音声端末２０を利用した電話会議が可能になる。
【００１３】
携帯基地局１６は、例えば空港内の複数箇所に設置され、音声端末２０との間で通信する装置である。携帯基地局１６は、パケットコアノード１４及び音声網ゲートウェイ１２を介して、会議管理サーバ１０と接続されている。なお、パケットコアノード１４及び音声網ゲートウェイ１２は、会議管理サーバ１０と音声端末２０との間の音声パケット通信を実現する装置である。
【００１４】
会議管理サーバ１０は、例えば、マルチメディアサーバであり、複数の音声端末２０間における電話会議を統括的に制御する。図２には、会議管理サーバ１０のハードウェア構成が概略的に示されている。図２に示すように、会議管理サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これら会議管理サーバ１０の構成各部は、バス９８に接続されている。ＣＰＵ９０が、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（会議管理プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（会議管理プログラムを含む）を実行することにより、会議管理サーバ１０を図３に示す各部として機能させる。なお、図３には、会議管理サーバ１０のＨＤＤ９６等に格納されている各種テーブルについても図示されている。
【００１５】
図３には、会議管理サーバ１０の機能ブロック図が示されている。図３に示すように、会議管理サーバ１０は、ＣＰＵ９０がプログラムを実行することで、電話会議情報管理部３０、電話会議制御部３２、応答時間測定部３４、ミキシング部３６、プロトコル処理部３８、通話処理部４０として機能する。
【００１６】
電話会議情報管理部３０は、電話会議の開催情報を管理する。具体的には電話会議情報管理部３０は、管理者等から入力された電話会議の開催情報を電話会議テーブル５０において管理する。電話会議テーブル５０には、図４（ａ）に示すように、電話会議名、グループ、開始時刻、終了時刻、参加者が格納される。図４（ａ）の例では、電話会議名が「TEL Meeting」であり、電話会議を実施するグループ名が「Group1」であり、会議の開始時刻が「毎日９：００」であり、会議の終了時刻が「毎日２３：００」となっている。また、参加者は、「Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ、Ｈ，Ｉ，Ｊ，Ｋ，Ｌ，Ｍ，Ｎ，Ｏ」となっている。なお、会議の終了時刻前に音声端末２０のユーザ等が会議終了の操作を行った場合や、参加者全てが利用する音声端末２０と会議管理サーバ１０との接続が切断された場合には、会議の終了時刻が到来する前に会議は終了する。なお、参加者については、グループと参加者とを紐付ける他のテーブルで管理してもよい。
【００１７】
電話会議制御部３２は、電話会議開始時刻が到来すると、電話会議の参加者の音声端末２０に対して発呼を行う。また、電話会議制御部３２は、音声端末２０から発呼に対する応答メッセージが送信されてきた場合に、その旨を応答時間測定部３４やミキシング部３６に通知する。ここで、電話会議制御部３２は、電話会議開始の所定時間前に、電話会議テーブル５０に格納されている情報や、第１記憶部としての応答時間テーブル５２から生成される作業用テーブル５４に基づいて発呼スケジュールを作成し、第２記憶部としての発呼スケジュールテーブル５６に格納する。そして、電話会議制御部３２は、発呼スケジュールテーブル５６に格納されている発呼スケジュールに基づいて、各音声端末２０に対する発呼を実行する。なお、発呼スケジュールは、単位時間に発呼する音声端末２０の数が閾値以下（例えば１秒間に５つ以下）で、単位時間に応答する音声端末２０の数が許容値以下（例えば１秒間に２つ以下）となるように発呼のタイミングをスケジューリングしたものである。なお、本実施形態では、会議管理サーバ１０が単位時間に応答できる音声端末２０の数（限界数）は、５であるものとする。
【００１８】
ここで、応答時間テーブル５２、作業用テーブル５４、及び発呼スケジュールテーブル５６について説明する。
【００１９】
応答時間テーブル５２は、過去において、各参加者が応答するまでにどの程度の時間を要したかを管理するテーブルである。具体的には、図４（ｂ）に示すように、応答時間テーブル５２は、「参加者」、「平均応答時間（秒）」、「累積会議参加回数」の各フィールドを有する。「参加者」のフィールドには、電話会議の参加者（空港職員）それぞれの識別情報が格納される。「平均応答時間（秒）」のフィールドには、過去において、会議管理サーバ１０からの発呼に対して参加者が応答するまでに要した時間（秒）の平均値が格納される。なお、図４（ｂ）では、平均応答時間（秒）として、実際の平均値の小数点以下を四捨五入した値が格納されている。なお、平均応答時間（秒）は、実際の平均値の小数点以下を切り上げた値又は切り捨てた値であってもよい。「累積会議参加回数」のフィールドには、会議に参加した累積回数（すなわち、会議管理サーバ１０からの発呼に対して応答した回数）が格納される。
【００２０】
作業用テーブル５４は、各グループに属する各参加者が応答に要すると予想される時間（想定応答時間）を格納するテーブルである。具体的には、図５（ａ）に示すように、作業用テーブル５４は、各グループの「参加者」と各参加者の「応答時間（秒）」とを格納する。「参加者」のフィールドには、グループ（図５（ａ）では、Group1）に属する参加者の識別情報が格納される。「応答時間（秒）」のフィールドには、応答時間テーブル５２から読み出した各参加者の平均応答時間（秒）が想定応答時間として格納される。なお、図５（ａ）においては、平均応答時間（秒）の短い順に各参加者を並べ替えた後の状態が示されている。
【００２１】
発呼スケジュールテーブル５６は、各参加者の音声端末２０に対して、何時何分何秒に発呼を実行するかを管理するテーブルである。発呼スケジュールテーブル５６は、図５（ｂ）に示すように、「発呼時刻」と「参加者」のフィールドを有する。「発呼時刻」のフィールドには、会議の開始時刻から１秒ごとの時刻が格納され、「参加者」のフィールドには、各時刻に発呼すべき参加者の識別情報が格納される。
【００２２】
図３に戻り、応答時間測定部３４は、電話会議制御部３２が音声端末２０に対して発呼を実行してから、音声端末２０から応答メッセージが送信されてくるまでの時間を測定し、応答時間テーブル５２を更新する。
【００２３】
ミキシング部３６は、電話会議制御部３２の指示の下、複数の音声端末２０の音声を通話処理部４０（第２受信部４４）を介して受信して、ミキシングする。そして、ミキシング部３６は、ミキシング後の音声を、通話処理部４０（第２送信部４３）を介して各音声端末２０に向けて送信することで、電話会議を実現する。
【００２４】
プロトコル処理部３８は、第１送信部４１と、第１受信部４２とを有する。第１送信部４１は、電話会議制御部３２からの発呼指示に基づいて、発呼処理を実行する。第１受信部４２は、発呼に対して音声端末２０から送信されてきた応答メッセージを受信し、電話会議制御部３２に送信する。また、第１受信部４２は、電話会議のスケジュールの情報を外部から受信すると、電話会議制御部３２を介して電話会議情報管理部３０に送信する。
【００２５】
通話処理部４０は、第２送信部４３と、第２受信部４４とを有する。第２送信部４３は、ミキシング部３６でミキシングされた音声データを音声端末２０に向けて送信する。第２受信部４４は、各音声端末２０から送信されてきた音声データをミキシング部３６に送信する。
【００２６】
（処理について）
以下、図６（ａ）〜図７、図１６〜図１８のフローチャートに沿って、会議管理サーバ１０の処理について詳細に説明する。
【００２７】
（電話会議テーブル登録処理）
図６（ａ）には、電話会議情報管理部３０による電話会議テーブル登録処理がフローチャートにて示されている。本処理は、電話会議テーブル５０に電話会議の開催情報を登録する処理である。
【００２８】
図６（ａ）の処理では、まずステップＳ１０において、電話会議情報管理部３０が、電話会議のスケジュールが管理者等が利用する端末（音声端末２０やＰＣなどのその他の端末）から入力されるまで待機する。入力される電話会議のスケジュールの情報としては、電話会議名、電話会議に参加するグループ名、開始時刻、終了時刻が含まれる。
【００２９】
電話会議のスケジュールが第１受信部４２及び電話会議制御部３２を介して入力され、ステップＳ１２に移行すると、電話会議情報管理部３０は、図４（ａ）に示すように電話会議テーブル５０へスケジュールを登録する。なお、本実施形態では、電話会議のスケジュールの情報が入力される度に、図４（ａ）の電話会議テーブル５０が新たに作成されるようになっている。
【００３０】
以上の処理により、電話会議テーブル登録処理は終了する。
【００３１】
（発呼スケジュールテーブル作成処理）
次に、電話会議制御部３２による、発呼スケジュールテーブル作成処理について、図６（ｂ）のフローチャートに沿って説明する。なお、図６（ｂ）の処理は、図６（ａ）の処理と同時並行的に実行される処理である。
【００３２】
電話会議制御部３２は、まずステップＳ２０において、電話会議開始の所定時間前になるまで待機する。この場合、電話会議制御部３２は、電話会議テーブル５０を参照し、いずれかの電話会議の開始時刻の所定時間前になったか否かを判断する。そして、いずれかの電話会議の開始時刻の所定時間前になると、電話会議制御部３２は、ステップＳ２２に移行する。
【００３３】
ステップＳ２２に移行すると、電話会議制御部３２は、発呼スケジュールを作成するスケジューリング処理のサブルーチンを実行する。以下、図７のフローチャートに沿って、スケジューリング処理のサブルーチンについて詳細に説明する。なお、電話会議制御部３２は、スケジューリング処理を実行する前に、応答時間テーブル５２を参照して、開催される会議の参加者の想定応答時間を短い順に並べた図５（ａ）に示すような作業用テーブル５４を用意しておくものとする。なお、新規の参加者がグループに含まれる場合もある。このような場合には、新規の参加者（応答時間テーブル５２に登録されていない参加者）の想定応答時間を、例えば、グループ内の参加者の平均や中央値、最頻値などに設定し、作業用テーブル５４に含めるようにすればよい。
【００３４】
なお、図７の処理の前提として、電話会議開始時刻からの経過時間ｋを０、電話会議開始時刻からの応答受信時間ｚを１、応答受信時間ｚに対応する時刻の応答受信数Ｒｚを０、経過時間ｋに対応する時刻の発呼数Ｓｋを０に設定しておくものとする。すなわち、ｋ＝０、ｚ＝１、Ｒ１，Ｒ２…＝０、Ｓ０，Ｓ１，Ｓ２…＝０に設定されているものとする。また、本実施形態では、一例として、同時に発呼する音声端末２０の数を５つ以下に制限するとともに、同時に音声端末２０から応答メッセージを受信する数が２以下となるように、スケジューリングを行うものとする。なお、単位時間における応答メッセージを受信する数を、発呼する音声端末２０の数よりも少なくしているのは、応答メッセージを受けた場合に行われるミキシング等の受信処理の処理負荷が大きいためである。なお、以下においては、説明の便宜上、各時点におけるパラメータの値を適宜表記するものとする。
【００３５】
＜現時点のパラメータ：ｋ＝０、ｚ＝１、Ｒ１＝０、Ｓ０＝０＞
ステップＳ３０では、電話会議制御部３２が、図５（ａ）の作業用テーブル５４の先頭の参加者のデータを取得する。本例では、参加者Ａの想定応答時間Ｔｘ＝１秒が取得される。
【００３６】
次いで、ステップＳ３２では、電話会議制御部３２が、データを取得できたか否か、すなわち作業用テーブル５４に参加者のデータが残っているかを判断する。このステップＳ３２の判断が否定された場合には、図７の全処理を終了するとともに、図６（ｂ）の全処理を終了するが、ステップＳ３２の判断が肯定された場合には、ステップＳ３４に移行する。
【００３７】
ステップＳ３４に移行すると、電話会議制御部３２は、応答受信時間ｚに対応する時刻の応答受信数Ｒｚが２でないかを判断する。ここでは、Ｒｚ（＝Ｒ１）は０であるので、ステップＳ３４の判断は肯定され、ステップＳ３８に移行する。
【００３８】
ステップＳ３８に移行すると、電話会議制御部３２は、経過時間ｋに対応する時刻の発呼数Ｓｋが５でないか否かを判断する。ここでは、Ｓｋ（＝Ｓ０）は０であるので、ステップＳ３８の判断は肯定され、ステップＳ４２に移行する。
【００３９】
ステップＳ４２に移行すると、電話会議制御部３２は、加入者ｘ（＝Ａ）の想定応答時間（作業用テーブル５４に格納されている応答時間）Ｔｘが、次式（１）を満足するか否かを判断する。
ｚ−ｋ−０．５＜Ｔｘ≦ｚ−ｋ＋０．５      …（１）
【００４０】
参加者ＡのＴｘは、１である。また、ｚ＝１、ｋ＝０である。したがって、上式（１）は、０．５＜１≦１．５となり、式を満足するため、ステップＳ４２の判断は肯定されることになる。なお、図５（ａ）のように、想定応答時間Ｔｘが整数である場合には、上式（１）は、次式（１）’であってもよい。
Ｔｘ＝ｚ−ｋ          …（１）’
【００４１】
ステップＳ４２の判断が肯定され、ステップＳ５２に移行すると、電話会議制御部３２は、参加者Ａを発呼スケジュールテーブル５６に登録し、参加者Ａのデータ（Ｔｘ）を作業用テーブル５４から削除する。具体的には、図８（ａ）に模式的に示すように、参加者Ａをｋ＝０において発呼し、ｚ＝１において応答する可能性が高い参加者として、図８（ｂ）に示すように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図８（ｃ）のように更新する（参加者Ａを削除する）。なお、図８（ａ）においては、上端の目盛りが会議開始時刻からの時間を示し、下端の数値が各時刻における受信処理数（応答受信数Ｒｚ）を示している。すなわち、図８（ａ）においては、開始時刻から１秒後に１つの受信処理（例えばミキシング処理）を実行する必要があることが示されている。
【００４２】
次いで、ステップＳ５４では、電話会議制御部３２が、ＲｚとＳｋを１インクリメント（Ｒｚ＝Ｒｚ＋１、Ｓｋ＝Ｓｋ＋１）する。具体的には、Ｒ１＝０＋１＝１、Ｓ０＝０＋１＝１となる。その後は、ステップＳ３０に戻る。
【００４３】
＜現時点のパラメータ：ｋ＝０、ｚ＝１、Ｒ１＝１、Ｓ０＝１＞
ステップＳ３０に戻り、電話会議制御部３２は、図８（ｃ）の作業用テーブル５４の先頭に位置する参加者のデータとして、参加者Ｂのデータを取得する。この参加者Ｂに関する処理は、参加者Ａと同様に実行される。すなわち、電話会議制御部３２は、ステップＳ３２：肯定、Ｓ３４：肯定（Ｒｚ＝１のため）、Ｓ３８：肯定（Ｓ０＝１のため）、Ｓ４２：肯定を経て、ステップＳ５２に移行する。ステップＳ５２では、電話会議制御部３２は、図９（ａ）に模式的に示すように、参加者Ｂをｋ＝０において発呼し、ｚ＝１において応答する可能性が高い参加者として、図９（ｂ）に示すように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図９（ｃ）のように更新する（参加者Ｂを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ１をＲ１＝１＋１＝２、Ｓ０をＳ０＝１＋１＝２とし、ステップＳ３０に戻る。
【００４４】
＜現時点のパラメータ：ｋ＝０、ｚ＝１、Ｒ１＝２、Ｓ０＝２＞
ステップＳ３０に戻ると、電話会議制御部３２は、図９（ｃ）の作業用テーブル５４の先頭に位置する参加者Ｃのデータを取得する。次のステップＳ３２の判断が肯定されると、電話会議制御部３２は、ステップＳ３４に移行し、Ｒｚが２でないか否かを判断する。ここでは、Ｒｚは２であるので、ステップＳ３４の判断が否定され、ステップＳ３６へ移行する。
【００４５】
ステップＳ３６へ移行すると、電話会議制御部３２は、ｚを１インクリメント（ｚ＝ｚ＋１）する。ここでは、ｚ＝１＋１＝２となる。なお、この段階におけるＲｚは、Ｒ２＝０である。その後は、ステップＳ３０に戻る。
【００４６】
＜現時点のパラメータ：ｋ＝０、ｚ＝２、Ｒ２＝０、Ｓ０＝２＞
ステップＳ３０に戻ると、電話会議制御部３２は、再度参加者Ｃのデータを取得し、次のステップＳ３２の判断が肯定されると、ステップＳ３４に移行する。ステップＳ３４では、電話会議制御部３２は、Ｒｚ（＝Ｒ２）が２でないか否かを判断する。ここでは、Ｒ２＝０であるので、ステップＳ３４の判断が肯定され、ステップＳ３８に移行する。ステップＳ３８では、電話会議制御部３２は、Ｓｋ（＝Ｓ０）が５でないか否かを判断する。ここでは、Ｓ０＝２であるので、ステップＳ３８の判断は肯定され、ステップＳ４２に移行する。
【００４７】
ステップＳ４２に移行すると、電話会議制御部３２は、参加者ＣのＴｘ（＝１）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝２、ｋ＝０であるので、上式（１）は、１．５＜１≦２．５となり、満足しない。したがって、ステップＳ４２の判断は否定され、ステップＳ４４に移行する。
【００４８】
ステップＳ４４に移行すると、電話会議制御部３２は、ステップＳ３０で取得したデータが作業用テーブル５４の最後のデータであるか否かを判断する。ここでは、最後のデータではないため、ステップＳ４４の判断が否定され、ステップＳ５６において、電話会議制御部３２は、作業用テーブル５４の次の参加者（Ｄ）のデータを取得する。なお、参加者Ｄの想定応答時間Ｔｘは２である。その後は、ステップＳ３４に戻る。
【００４９】
ステップＳ３４に戻ると、電話会議制御部３２は、Ｒｚ（＝Ｒ２）が２でないか否かを判断する。ここでは、Ｒ２＝０であるので、ステップＳ３４の判断が肯定され、ステップＳ３８に移行する。ステップＳ３８では、電話会議制御部３２は、Ｓｋ（＝Ｓ０）が５でないか否かを判断する。ここでは、Ｓ０＝２であるので、ステップＳ３８の判断は肯定され、電話会議制御部３２はステップＳ４２に移行する。ステップＳ４２では、電話会議制御部３２は、Ｔｘ（＝２）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝２、ｋ＝０であるので、上式（１）は、１．５＜２≦２．５となり、満足する。したがって、ステップＳ４２の判断は肯定され、ステップＳ５２に移行する。
【００５０】
ステップＳ５２では、電話会議制御部３２は、図１０（ａ）に模式的に示すように、参加者Ｄをｋ＝０において発呼し、ｚ＝２において応答する可能性が高い参加者として、図１０（ｂ）のように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図１０（ｃ）のように更新する（参加者Ｄを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ２をＲ２＝０＋１＝１、Ｓ０をＳ０＝２＋１＝３とする。その後は、ステップＳ３０に戻る。
【００５１】
＜現時点のパラメータ：ｋ＝０、ｚ＝２、Ｒ２＝１、Ｓ０＝３＞
ステップＳ３０に戻ると、電話会議制御部３２は、再び、作業用テーブル５４（図１０（ｃ））の先頭の参加者Ｃのデータを取得する。この場合、ステップＳ３２：肯定、ステップＳ３４：肯定（Ｒ２＝１のため）、ステップＳ３６：肯定（Ｓ０＝３のため）を経て、ステップＳ４２に移行する。ステップＳ４２では、電話会議制御部３２は、Ｔｘ（＝１）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝２、ｋ＝０であるので、上式（１）は、１．５＜１≦２．５となり、満足しない。したがって、ステップＳ４２の判断は否定され、ステップＳ４４に移行する。
【００５２】
ステップＳ４４に移行すると、電話会議制御部３２は、ステップＳ３０で取得したデータが作業用テーブル５４の最後のデータであるか否かを判断する。ここでは、最後のデータではないため、ステップＳ４４の判断が否定され、電話会議制御部３２は、ステップＳ５６に移行する。ステップＳ５６に移行すると、電話会議制御部３２は、作業用テーブル５４の次の参加者（Ｅ）のデータを取得する。なお、参加者Ｅの想定応答時間Ｔｘは２である。ステップＳ５６の後は、ステップＳ３４に戻る。
【００５３】
その後は、ステップＳ３４：肯定（Ｒ２＝１のため）、ステップＳ３８：肯定（Ｓ０＝３のため）を経て、ステップＳ４２に移行する。ステップＳ４２では、電話会議制御部３２は、参加者ＥのＴｘ（＝２）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝２、ｋ＝０であるので、上式（１）は、１．５＜２≦２．５となり、満足する。したがって、ステップＳ４２の判断は肯定され、電話会議制御部３２は、ステップＳ５２に移行する。
【００５４】
ステップＳ５２では、電話会議制御部３２は、図１１（ａ）に模式的に示すように、参加者Ｅをｋ＝０において発呼し、ｚ＝２において応答する可能性が高い参加者として、図１１（ｂ）のように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図１１（ｃ）のように更新する（参加者Ｅを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ２をＲ２＝１＋１＝２、Ｓ０をＳ０＝３＋１＝４とする。その後は、ステップＳ３０に戻る。
【００５５】
＜現時点のパラメータ：ｋ＝０、ｚ＝２、Ｒ２＝２、Ｓ０＝４＞
ステップＳ３０に戻ると、電話会議制御部３２は、図１１（ｃ）の作業用テーブル５４の先頭に位置する参加者Ｃのデータを取得する。次いで、ステップＳ３２の判断が肯定されると、ステップＳ３４において、Ｒｚが２でないか否かを判断する。ここでは、Ｒｚ（＝Ｒ２）は２であるので、ステップＳ３４の判断が否定され、ステップＳ３６へ移行する。
【００５６】
ステップＳ３６へ移行すると、電話会議制御部３２は、ｚを１インクリメント（ｚ＝ｚ＋１）する。ここでは、ｚ＝２＋１＝３となる。なお、この段階におけるＲｚ，Ｓｋは、Ｒ３＝０、Ｓ０＝４となる。その後は、ステップＳ３０に戻る。
【００５７】
＜現時点のパラメータ：ｋ＝０、ｚ＝３、Ｒ３＝０、Ｓ０＝４＞
ステップＳ３０に戻ると、電話会議制御部３２は、再度参加者Ｃのデータを取得し、ステップＳ３２：肯定、ステップＳ３４：肯定（Ｒ３＝０のため）、ステップＳ３８：肯定（Ｓ０＝４のため）を経て、ステップＳ４２に移行する。ステップＳ４２では、電話会議制御部３２は、参加者ＣのＴｘ（＝１）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝３、ｋ＝０であるので、上式（１）は、２．５＜１≦３．５となり、満足しない。したがって、ステップＳ４２の判断は否定され、ステップＳ４４に移行する。
【００５８】
ステップＳ４４に移行すると、電話会議制御部３２は、ステップＳ３０で取得したデータが作業用テーブル５４の最後のデータであるか否かを判断する。ここでは、最後のデータではないため、ステップＳ４４の判断が否定され、電話会議制御部３２はステップＳ５６に移行する。ステップＳ５６に移行すると、電話会議制御部３２は、図１１（ｃ）の作業用テーブル５４の次の参加者（Ｆ）のデータを取得する。なお、参加者Ｆの想定応答時間Ｔｘは２である。ステップＳ５６の後は、ステップＳ３４に戻る。
【００５９】
その後、ステップＳ３４：肯定（Ｒ３＝０のため）、ステップＳ３８：肯定（Ｓ０＝４のため）、を経て、ステップＳ４２に移行すると、電話会議制御部３２は、参加者ＦのＴｘ（＝２）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝３、ｋ＝０であるので、上式（１）は、２．５＜２≦３．５となり、満足しない。したがって、ステップＳ４２の判断は否定され、ステップＳ４４に移行する。
【００６０】
ステップＳ４４に移行すると、電話会議制御部３２は、ステップＳ３０で取得したデータが作業用テーブル５４の最後のデータであるか否かを判断する。ここでは、最後のデータではないため、ステップＳ４４の判断が否定され、ステップＳ５６において、電話会議制御部３２は、図１１（ｃ）の作業用テーブル５４の次の参加者（Ｇ）のデータを取得する。なお、参加者Ｇの想定応答時間Ｔｘは３である。その後は、ステップＳ３４に戻る。
【００６１】
電話会議制御部３２は、ステップＳ３４：肯定（Ｒ３＝０のため）、ステップＳ３８：肯定（Ｓ０＝４のため）、を経て、ステップＳ４２に移行すると、参加者ＧのＴｘ（＝３）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝３、ｋ＝０であるので、上式（１）は、２．５＜３≦３．５となり、満足する。したがって、ステップＳ４２の判断は肯定され、ステップＳ５２に移行する。
【００６２】
ステップＳ５２では、電話会議制御部３２は、図１２（ａ）に模式的に示すように、参加者Ｇをｋ＝０において発呼し、ｚ＝３において応答する可能性が高い参加者として、図１２（ｂ）のように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図１２（ｃ）のように更新する（参加者Ｇを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ３をＲ３＝０＋１＝１、Ｓ０をＳ０＝４＋１＝５とする。その後は、ステップＳ３０に戻る。
【００６３】
＜現時点のパラメータ：ｋ＝０、ｚ＝３、Ｒ３＝１、Ｓ０＝５＞
ステップＳ３０に戻り、電話会議制御部３２は、再度、参加者Ｃのデータを取得する。そして、電話会議制御部３２は、ステップＳ３２：肯定、ステップＳ３４：肯定（Ｒ３＝１のため）を経て、ステップＳ３８に移行する。ステップＳ３８に移行すると、電話会議制御部３２は、Ｓｋ（＝Ｓ０）が５でないか否かを判断する。ここでは、Ｓ０＝５であるので、ステップＳ３８の判断は否定され、電話会議制御部３２は、ステップＳ４０に移行する。ステップＳ４０に移行すると、電話会議制御部３２は、ｋを１インクリメント（ｋ＝ｋ＋１）するとともに、ｚをｋ＋１とする。ここでは、ｋ＝０＋１＝１となり、ｚ＝１＋１＝２となる。また、この時点では、Ｒｚ（＝Ｒ２）は２であり、Ｓｋ（＝Ｓ１）は、０である。ステップＳ４０の後は、ステップＳ３０に戻る。
【００６４】
＜現時点のパラメータ：ｋ＝１、ｚ＝２、Ｒ２＝２、Ｓ１＝０＞
ステップＳ３０に戻り、電話会議制御部３２は、再度、図１２（ｃ）の作業用テーブル５４の先頭の参加者Ｃのデータ（Ｔｘ＝１）を取得する。そして、その後は、電話会議制御部３２は、ステップＳ３２：肯定、ステップＳ３４：否定（Ｒ２＝２のため）を経て、ステップＳ３６に移行する。ステップＳ３６では、電話会議制御部３２は、ｚを１インクリメント（ｚ＝２＋１＝３）とした後、ステップＳ３０に戻る。なお、この時点のＲｚ（＝Ｒ３）は１である。
【００６５】
＜現時点のパラメータ：ｋ＝１、ｚ＝３、Ｒ３＝１、Ｓ１＝０＞
ステップＳ３０に戻ると、電話会議制御部３２は、参加者Ｃのデータ（Ｔｘ＝１）を取得する。そして、電話会議制御部３２は、ステップＳ３２：肯定、Ｓ３４：肯定（Ｒ３＝１のため）、Ｓ３８：肯定（Ｓ１＝０のため）、Ｓ４２：否定（Ｔｘは１であり、１．５＜Ｔｘ≦２．５でないため）、Ｓ４４：否定を経て、ステップＳ５６に移行する。ステップＳ５６では、電話会議制御部３２は、図１２（ｃ）の作業用テーブル５４の次の参加者Ｆのデータ（Ｔｘ＝２）を取得し、ステップＳ３４に戻る。
【００６６】
その後、電話会議制御部３２は、ステップＳ３４：肯定（Ｒ３＝１のため）、Ｓ３８：肯定（Ｓ１＝０のため）、を経て、ステップＳ４２に移行すると、Ｔｘ（＝２）が上式（１）を満足するか否かを判断する。ここでは、ｚ＝３、ｋ＝１であるので、上式（１）は、１．５＜２≦２．５となり、満足する。したがって、ステップＳ４２の判断は肯定され、ステップＳ５２に移行する。
【００６７】
ステップＳ５２では、電話会議制御部３２は、図１３（ａ）に模式的に示すように、参加者Ｆをｋ＝１において発呼し、ｚ＝３において応答する可能性が高い参加者として、図１３（ｂ）のように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図１３（ｃ）のように更新する（参加者Ｆを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ３をＲ３＝１＋１＝２、Ｓ１をＳ１＝０＋１＝１とする。その後は、ステップＳ３０に戻る。
【００６８】
これ以降は、上述した処理を繰り返すことにより、図１４（ａ）に模式的に示すように、参加者Ｈ〜参加者Ｏまでのスケジューリングを行うことができる。したがって、電話会議制御部３２は、図１４（ｂ）に示すように発呼スケジュールテーブル５６に参加者Ｈ〜Ｏを登録することができる。このとき、作業用テーブル５４には、図１４（ｃ）に示すように、参加者Ｃのみが残ることになる。
【００６９】
作業用テーブル５４が図１４（ｃ）の状態でステップＳ３０に戻ると、電話会議制御部３２は、作業用テーブル５４の先頭のデータとして、参加者Ｃのデータ（Ｔｘ＝１）を取得する。なお、この段階では、ｚ＝８、ｋ＝３、Ｒｚ（＝Ｒ８）＝１、Ｓｋ（＝Ｓ３）＝１となっている。
【００７０】
＜現時点のパラメータ：ｋ＝３、ｚ＝８、Ｒ８＝１、Ｓ３＝１＞
その後、電話会議制御部３２は、ステップＳ３２：肯定、Ｓ３４：肯定、Ｓ３８：肯定を経て、ステップＳ４２に移行するが、参加者ＣのＴｘは１であり、ｚ＝８，ｋ＝３では上式（１）を満足しないため、ステップＳ４２の判断は否定される。ステップＳ４２の判断が否定されると、電話会議制御部３２はステップＳ４４に移行し、参加者Ｃのデータが最後のデータであるか否かを判断する。ここでは、参加者Ｃのデータは最後のデータであるので、ステップＳ４４の判断は肯定され、電話会議制御部３２はステップＳ４６に移行する。
【００７１】
ステップＳ４６に移行すると、電話会議制御部３２は、ｚが電話会議開始時刻からの最大応答受信時間ｚ（ｍａｘ）以上か否かを判断する。なお、ｚ（ｍａｘ）は、一例として、次式（２）で表される。
ｚ（ｍａｘ）＝Ｔｘ＋参加者数÷２    …（２）
【００７２】
本実施形態では、ｚ（ｍａｘ）＝１＋１５／２＝８．５である。したがって、ｚ＝８の時点では、ステップＳ４６の判断が否定され、ステップＳ４８に移行する。ステップＳ４８では、電話会議制御部３２が、ｚを１インクリメント（ｚ＝８＋１＝９）する。なお、この時点では、Ｓｋ（＝Ｓ４）＝０、Ｒｚ（＝Ｒ９）＝０である。その後は、ステップＳ３０に戻る。
【００７３】
＜現時点のパラメータ：ｋ＝４、ｚ＝９、Ｒ９＝０、Ｓ４＝０＞
ステップＳ３０に戻ると、電話会議制御部３２は、図１４（ｃ）の作業用テーブル５４の先頭の参加者Ｃのデータ（Ｔｘ＝１）を再度取得する。その後、電話会議制御部３２は、ステップＳ３２：肯定、Ｓ３４：肯定（Ｒ９＝０のため）、Ｓ３８：肯定（Ｓ４＝０のため）を経て、ステップＳ４２に移行する。この場合、参加者ＣのＴｘ＝１は、ｚ＝９、ｋ＝４では、上式（１）を満足しないため、ステップＳ４４に移行する。ステップＳ４４に移行し、ステップＳ４４の判断が肯定されると、電話会議制御部３２は、ステップＳ４６に移行する。ステップＳ４６に移行すると、電話会議制御部３２は、ｚがｚ（ｍａｘ）以上であるか否かを判断する。ｚ＝９、ｚ（ｍａｘ）＝８．５では、ステップＳ４６の判断は肯定されるため、ステップＳ５０に移行する。ステップＳ５０では、電話会議制御部３２がｋを１インクリメント（ｋ＝４＋１＝５）し、ｚをｋに１を加算した値（ｚ＝５＋１＝６）とする。その後は、ステップＳ３０に戻る。なお、この時点では、Ｓｋ（＝Ｓ５）＝０、Ｒｚ（＝Ｒ６）＝１である。その後は、ステップＳ３０に戻る。
【００７４】
＜現時点のパラメータ：ｋ＝５、ｚ＝６、Ｒ６＝１、Ｓ５＝０＞
ステップＳ３０に戻ると、電話会議制御部３２は、作業用テーブル５４の先頭のデータとして、参加者Ｃのデータ（Ｔｘ＝１）を再度取得する。その後、ステップＳ３２：肯定、Ｓ３４：肯定（Ｒ６＝１のため）、Ｓ３８：肯定（Ｓ５＝０のため）を経て、ステップＳ４２に移行する。ステップＳ４２では、電話会議制御部３２が、Ｔｘが上式（１）を満足するか否かを判断する。参加者ＣのＴｘ＝１は、ｚ＝６、ｋ＝５の条件では、上式（１）を満足する（０．５＜１≦１．５）ため、ステップＳ４２の判断は肯定され、電話会議制御部３２は、ステップＳ５２に移行する。そして、ステップＳ５２に移行すると、電話会議制御部３２は、図１５（ａ）に模式的に示すように、参加者Ｃをｋ＝５において発呼し、ｚ＝６において応答する可能性が高い参加者として、図１５（ｂ）のように発呼スケジュールテーブル５６に登録する。また、電話会議制御部３２は、作業用テーブル５４を図１５（ｃ）のように更新する（参加者Ｃを削除する）。次いで、ステップＳ５４では、電話会議制御部３２は、Ｒ６をＲ６＝１＋１＝２、Ｓ５をＳ５＝０＋１＝１とする。その後は、ステップＳ３０に戻る。
【００７５】
なお、ステップＳ３０に戻った段階では、図１５（ｃ）に示すように作業用テーブル５４が空となっているので、電話会議制御部３２は作業用テーブル５４からデータを取得することはできない。したがって、次のステップＳ３２の判断は否定されるので、図７の全処理、及び図６（ｂ）の全処理が終了することになる。
【００７６】
以上のような、図７の処理の結果、図１５（ａ）に示すように、単位時間に発呼する音声端末２０の数を５つ以下にし、単位時間に応答メッセージを受信する数が２以下となるように、発呼スケジュールを作成することができる。
【００７７】
（発呼実行処理）
次に、図１６に基づいて、発呼実行処理について説明する。図１６には、電話会議制御部３２による発呼実行処理のフローチャートが示されている。なお、図１６の処理は、図６（ａ）や図６（ｂ）の処理と同時並行的に実行される処理である。
【００７８】
図１６の処理では、まず、ステップＳ６０において、電話会議制御部３２が、電話会議の開始時刻になるまで待機する。具体的には、電話会議制御部３２は、電話会議テーブル５０を参照し、いずれかの電話会議の開始時刻になった段階で、ステップＳ６２に移行する。なお、ステップＳ６２に移行する段階では、図６（ｂ）（図７の処理を含む）の処理が所定時間前に行われているので、開催する電話会議に対応する発呼スケジュールテーブル５６が作成されていることになる。
【００７９】
ステップＳ６２に移行すると、電話会議制御部３２は、発呼スケジュールテーブル５６に基づいて発呼を実行する。具体的には、電話会議制御部３２は、開始時刻となった電話会議に対応する発呼スケジュールテーブル５６を参照する。そして、電話会議制御部３２は、発呼スケジュールテーブル５６に従って、各参加者に対する発呼を、プロトコル処理部３８（第１送信部４１）を介して実行する。
【００８０】
以上により、発呼実行処理は終了する。
【００８１】
（ミキシング処理）
次に、図１７、図１８に基づいてミキシング処理について説明する。なお、本処理は、図１６の処理（発呼実行処理）と同時並行的に実行される。
【００８２】
図１７の処理では、まず、ステップＳ７０において、電話会議制御部３２が、電話会議の開始時刻になるまで待機する。電話会議制御部３２は、いずれかの電話会議の開始時刻になった段階で、ステップＳ７２に移行する。
【００８３】
ステップＳ７２に移行すると電話会議制御部３２は、応答メッセージをいずれかの音声端末２０から受信したか否かを判断する。このステップＳ７２の判断が否定された場合には、ステップＳ７４に移行し、電話会議制御部３２は、待機時間が経過したか、又は全参加者の応答メッセージを取得したか否かを判断する。なお、待機時間は、電話会議の開始時刻から予め定められた時間（例えば数十秒）を意味する。なお、待機時間は、前述したｚ（ｍａｘ）と同一時間であってもよい。このステップＳ７４の判断が否定された場合には、ステップＳ７２に戻るが、ステップＳ７４の判断が肯定された場合には、図１７の全処理を終了する。
【００８４】
ステップＳ７２の判断が肯定され、ステップＳ７６に移行すると、電話会議制御部３２は、ミキシング部３６に対して、ミキシングを指示する。
【００８５】
次いで、ステップＳ７８では、電話会議制御部３２は、応答時間測定部３４に対して、応答時間取得処理を実行させる。
【００８６】
ステップＳ７８においては、応答時間測定部３４は、図１８のフローチャートに沿った処理を実行する。図１８の処理では、まず、ステップＳ８０において、応答時間測定部３４が、応答時間を取得する。なお、応答時間は、電話会議制御部３２が応答メッセージを受信した時刻から、図５（ｂ）の発呼スケジュールテーブル５６に定義されている発呼時刻を差し引いた時間である。
【００８７】
次いで、ステップＳ８２では、応答時間測定部３４が、同一参加者の過去のデータが、応答時間テーブル５２に存在しているか否かを判断する。このステップＳ８２の判断が否定された場合には、ステップＳ８６に移行し、応答時間測定部３４は、今回の応答時間を応答時間テーブル５２に登録する。具体的には、応答時間測定部３４は、参加者の識別情報を「参加者」のフィールドに新たに登録する。そして、応答時間測定部３４は、今回の応答時間を「平均応答時間（秒）」のフィールドにそのまま格納し、「累計会議参加回数」のフィールドに「１」を格納する。
【００８８】
一方、ステップＳ８２の判断が肯定された場合には、ステップＳ８４に移行し、応答時間測定部３４は、今回の応答時間（Ｔ）を用いて算出される平均値（Ｔｘ’）を応答時間テーブル５２に登録する。具体的には、次式（３）に基づいて算出される値Ｔｘ’で「平均応答時間（秒）」のフィールドの値を更新するとともに、「累計会議参加回数」のフィールドに「１」を加算する。なお、次式（３）においては、更新前の「平均応答時間（秒）」のフィールドの値をＴｘ、「累計会議参加回数」のフィールドの値をＮとしている。
Ｔｘ’＝（Ｔｘ×Ｎ＋Ｔ）／（Ｎ＋１）          …（３）
【００８９】
ステップＳ８４又はステップＳ８６の処理が行われた後は、図１８の全処理を終了し、図１７のステップＳ７２に戻る。そして、以降においては、上述したステップＳ７２〜Ｓ７８の処理を繰り返し実行し、ステップＳ７４の判断が肯定された段階で、図１７の全処理を終了する。
【００９０】
なお、本実施形態では、参加者が不在の場合や、参加者が応答を行わなかった場合には、応答時間への反映（応答時間テーブル５２の更新）は行わないようになっている。
【００９１】
なお、電話会議制御部３２は、図１６の処理が終了した後は、適宜、電話会議終了か否かを判断する。具体的には、電話会議制御部３２は、電話会議が終了したか否かを、電話会議テーブル５０の終了時刻が到来したこと、ユーザ等から電話会議終了の旨が入力されたこと、全音声端末２０が会議管理サーバ１０との接続を終了したこと、等に基づいて判断する。電話会議制御部３２は、電話会議が終了した時点で会議管理サーバ１０に接続されている音声端末２０が存在する場合には、当該音声端末２０との接続を中止するなどの処理を実行する。
【００９２】
これまでの説明から分かるように、本実施形態では、電話会議制御部３２を含んで、音声端末２０への発呼をスケジューリングしてスケジュール情報を発呼スケジュールテーブル５６に記憶させるスケジューリング機能部としての機能が実現されている。また、電話会議制御部３２を含んで、発呼スケジュールテーブル５６に記憶されているスケジュール情報に基づいて、各音声端末２０への発呼を行う発呼部としての機能が実現されている。
【００９３】
以上、詳細に説明したように、本実施形態によると、応答時間テーブル５２には、複数の音声端末２０それぞれについて、発呼してから応答メッセージを受信するまでの応答時間の履歴が記憶され、電話会議制御部３２は、応答時間テーブル５２に記憶されている応答時間の履歴に基づいて、単位時間に応答する音声端末２０の数が閾値（＝２）以下となるように音声端末２０への発呼をスケジューリングしてスケジュール情報を発呼スケジュールテーブル５６に記憶する。そして、電話会議制御部３２は、発呼スケジュールテーブル５６に記憶されているスケジュール情報に基づいて、各音声端末２０への発呼を実行する。これにより、本実施形態では、会議管理サーバ１０の単位時間あたりの受信処理の処理負荷を平滑化することができる。また、処理負荷の平滑化により、会議管理サーバ１０のダウン等が発生するのを回避することができる。また、処理負荷の平滑化により、会議管理サーバ１０の処理能力を十分に活用することができるため、結果的に、会議開始時刻から実際に電話会議が行われるまでの時間（召集時間）を短縮することが可能となる。更に、受信処理の処理負荷を平滑化することで、受信処理のためにメッセージ受信バッファを小さくできるという利点もある。
【００９４】
ここで、応答時間テーブル５２に記憶されている応答時間の長短は、音声端末２０が呼出音等を発してから参加者が応答操作を行うまでの時間を反映している。すなわち、応答時間の長短は、音声端末２０の携帯の仕方（いつも鞄に入れている、いつも衣服のポケットに入れている、首に掛けているなど）や、呼出音に気づかないことが多い、呼出音がなっても気にしない、などの参加者の特性を反映している。したがって、本実施形態のように、応答時間テーブル５２に記憶されている応答時間の履歴に基づいて、スケジューリングを行うことで、参加者の特性を加味した適切なスケジューリングを行うことが可能となっている。また、本実施形態では、過去の応答時間の平均値を想定応答時間としているので、過去１回の応答時間を想定応答時間とする場合に比べ、参加者の特性をより適切に考慮してスケジューリングを行うことが可能となる。なお、参加者は、実際の電話会議の際に想定応答時間のとおりに応答するとは限らない。しかしながら、Ｒｚの最大値（本実施形態では２）を、会議管理サーバ１０が単位時間に応答できる音声端末２０の数（限界数）よりも小さくしておけば、処理輻輳等の問題はほとんど生じない。
【００９５】
（比較例）
図１９には、単位時間における発呼数が２以下となるように、発呼処理を実行した場合の例（比較例１）が示されている。なお、図１９では、サンプルとして、応答時間の履歴が短い順に発呼した場合について示している。本例では、全ての受信処理が行われるまで、１２秒かかってしまう。
【００９６】
一方、図２０には、サンプルとして応答時間の履歴が長い順に、単位時間における発呼数が２以下となるように、発呼処理を実行した場合の例（比較例２）が示されている。図２０の例では、開始時刻からの経過時間が５秒の時点で、会議管理サーバ１０の処理能力（受信処理数５）を超えて輻輳するため、受信メッセージの再送待ちにより処理が遅延する。このため、全ての受信処理が行われるまで、１１秒かかってしまう。
【００９７】
図１９、図２０の結果からは、単位時間あたりの発呼数を制限することで、サーバの処理能力を十分に活用できず、結果的に、参加者全員を電話会議に召集するまで時間を要してしまうことがわかる。また、図１９、図２０の結果を考慮すると、参加者を２人ずつランダムに選択して順次発呼することとしても、全ての受信処理が行われるまでには図１９、図２０と同等又はそれ以上の時間を要すると考えられる。
【００９８】
これに対し、本実施形態では、図１５のように、全ての受信処理が行われるまでの時間が８秒で済むので、会議開始時刻から実際に電話会議が行われるまでの時間（召集時間）を短縮できていることがわかる。
【００９９】
また、本実施形態では、電話会議制御部３２は、発呼した端末の全てからの応答があるまでの時間が予め定めた時間（ｚ（ｍａｘ））内に収まるように音声端末２０への発呼をスケジューリングしている（図７のＳ４６：肯定、Ｓ５０）。これにより、全ての受信処理が行われるまでの時間を適切な範囲に収めることが可能となる。
【０１００】
また、本実施形態では、同一のタイミングで発呼する端末の数が許容値（例えば５）を超えないようにスケジューリングをするので、発呼時における処理負荷についても低減することができる。
【０１０１】
また、本実施形態では、発呼に対する応答メッセージを受信した場合に、音声端末２０の音声をミキシングするミキシング部３６を備えている。本実施形態では、上述したようにスケジューリングを行うことで、処理負荷の大きいミキシング処理を分散して処理でき、処理の効率化を図ることが可能となる。
【０１０２】
なお、上記実施形態では、原則、想定応答時間Ｔｘが短い順に発呼を行うようにスケジューリングする例について説明したが、これに限られるものではない。例えば、単位時間に発呼する音声端末２０の半数程度をＴｘが短い参加者を優先的に設定し、残りの半数程度をＴｘが長い参加者を優先的に設定するようにしてもよい。このようにしても、図２１に示すように、全ての受信処理が行われるまでの時間を８秒とすることができるので、上記実施形態と同様、会議開始時刻から実際に電話会議が行われるまでの時間（召集時間）を短縮することが可能となる。なお、単位時間に応答する端末の数が所定値以下となるような発呼スケジュールであれば、スケジュールの具体的な内容については上記実施形態や、図２１の例と同一でなくてもよい。
【０１０３】
なお、上記実施形態では、会議開始時刻の所定時間前に電話会議制御部３２が発呼スケジュールテーブル５６を作成する場合について説明したが、これに限られるものではない。例えば、電話会議の開催に備えて、例えば１日一回程度の頻度で、各電話会議の発呼スケジュールテーブル５６を作成しておいてもよい。
【０１０４】
なお、上記実施形態では、会議管理サーバ１０（電話会議制御部３２）が発呼スケジュールテーブル５６を作成する場合について説明したが、これに限られるものではない。例えば、会議管理サーバ１０とは異なるサーバ（クラウドサーバ等）が、応答時間テーブル５２と同様のデータを収集し、発呼スケジュールテーブル５６を作成して、会議管理サーバ１０に提供するようにしてもよい。
【０１０５】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【０１０６】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１０７】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１０８】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【０１０９】
なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１）  複数の端末それぞれについて、発呼してから応答するまでの応答時間の履歴を記憶する第１記憶部と、
前記第１記憶部に記憶されている前記応答時間の履歴に基づいて、単位時間に応答する端末の数が閾値以下となるように端末への発呼をスケジューリングしてスケジュール情報を第２記憶部に記憶させるスケジューリング機能部と、
前記第２記憶部に記憶されている前記スケジュール情報に基づいて、各端末への発呼を行う発呼部と、
を備える会議管理装置。
（付記２）  前記スケジューリング機能部は、更に、発呼した端末の全てからの応答があるまでの時間が予め定めた時間内に収まるように端末への発呼をスケジューリングすることを特徴とする付記１に記載の会議管理装置。
（付記３）  前記スケジューリング機能部は、更に、同一タイミングで発呼する端末の数が予め定めた許容値を超えないように端末への発呼をスケジューリングすることを特徴とする付記１又は２に記載の会議管理装置。
（付記４）  発呼に対する応答があった端末からの音声をミキシングするミキシング部を更に備える、付記１〜３のいずれかに記載の会議管理装置。
（付記５）  付記１〜４のいずれかに記載の会議管理装置と、
前記会議管理装置と接続された複数の端末と、を備える会議システム。
（付記６）  複数の端末それぞれについて、発呼してから応答するまでの応答時間の履歴を第１記憶部に記憶し、
前記第１記憶部に記憶されている前記応答時間の履歴に基づいて、単位時間に応答する端末の数が閾値以下となるように端末への発呼をスケジューリングしてスケジュール情報を第２記憶部に記憶し、
前記第２記憶部に記憶されている前記スケジュール情報に基づいて、各端末への発呼を実行する、
処理をコンピュータが実行することを特徴とする会議管理方法。
（付記７）  前記第２記憶部に記憶する処理では、発呼した端末の全てからの応答があるまでの時間が予め定めた時間内に収まるように端末への発呼をスケジューリングすることを特徴とする付記６に記載の会議管理方法。
（付記８）  前記第２記憶部に記憶する処理では、同一タイミングで発呼する端末の数が予め定めた許容値を超えないように端末への発呼をスケジューリングすることを特徴とする付記６又は７に記載の会議管理方法。
（付記９）  発呼に対する応答があった端末からの音声をミキシングする処理、を前記コンピュータが更に実行することを特徴とする付記６〜８のいずれかに記載の会議管理方法。
【符号の説明】
【０１１０】
１０  会議管理サーバ（会議管理装置）
２０  端末（音声端末）
３２  電話会議制御部（スケジューリング機能部、発呼部）
３６  ミキシング部
５２  応答時間テーブル（第１記憶部）
５６  発呼スケジュールテーブル（第２記憶部）
１００  電話会議システム（会議システム）
【図１】
2017085366.tif 000003
【図２】
2017085366.tif 000004
【図３】
2017085366.tif 000005
【図４】
2017085366.tif 000006
【図５】
2017085366.tif 000007
【図６】
2017085366.tif 000008
【図７】
2017085366.tif 000009
【図８】
2017085366.tif 000010
【図９】
2017085366.tif 000011
【図１０】
2017085366.tif 000012
【図１１】
2017085366.tif 000013
【図１２】
2017085366.tif 000014
【図１３】
2017085366.tif 000015
【図１４】
2017085366.tif 000016
【図１５】
2017085366.tif 000017
【図１６】
2017085366.tif 000018
【図１７】
2017085366.tif 000019
【図１８】
2017085366.tif 000020
【図１９】
2017085366.tif 000021
【図２０】
2017085366.tif 000022
【図２１】
2017085366.tif 000023