(57)【要約】【課題】ＭＣＵにより会議通信を実現する通信システムにて、ＭＣＵや会議端末に障害が発生した場合には、その障害の発生を各会議参加者に確実に伝達し、適切な対応を行えるようにする。【解決手段】ＭＣＵとの間に通信セッションを確立し会議通信を行う複数の会議端末と、プライマリＭＣＵおよび障害発生時の代替機であるセカンダリＭＣＵを含む会議通信システムに、プライマリＭＣＵおよび各会議端末の稼動監視を行う監視装置を設ける。そして、プライマリＭＣＵの障害を検知した場合には、各会議端末に対してその旨を通知し、通信セッションの接続先をセカンダリＭＣＵへ切り換えることを指示する一方、何れかの会議端末の障害を検知した場合には、他の会議端末に対してその旨を通知し、稼動中のＭＣＵに対しては、障害の発生した会議端末との間の通信セッションの切断を指示する処理を上記監視装置に実行させる。【選択図】図６
2009232015.tif 000002
【特許請求の範囲】
【請求項１】
複数の会議端末の各々との間に通信セッションを確立し、各会議端末から送信されてくる音声データを受信する一方、各会議端末に対して、当該会議端末以外の会議端末から受信した音声データをミキシングして得られる音声データを送信する処理を各々実行する複数の多地点接続装置と、
前記複数の多地点接続装置のうちの予め定められたものとの間に通信セッションを確立し、各々利用者の音声を収音しその音声を示す音声データを送信する一方、前記通信セッションの接続先から受信した音声データの表す音声を出力する複数の会議端末と、
前記通信セッションを確立して同一の会議へ参加している会議端末、および当該会議端末との間に通信セッションを確立して会議通信を仲介している多地点接続装置の稼動監視を行う監視装置と、
を備え、
前記複数の多地点接続装置および前記複数の会議端末の各々は、前記監視装置からの指示にしたがってその指示内容に則した処理を実行し、
前記監視装置は、
（Ａ）監視対象の多地点接続装置に障害が発生した場合には、
前記同一の会議へ参加している会議端末の各々に、多地点接続装置側に障害が発生した旨を利用者に報知する処理の実行を指示する第１の処理と、
前記複数の多地点接続装置のうち障害の発生していないもののなかから前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立し直す多地点接続装置を選択し、当該会議端末の各々との間に通信セッションを確立して会議通信を再開する処理の実行を当該選択した多地点接続装置に指示する第２の処理と、
前記稼動監視の対象を前記障害の発生した多地点接続装置から当該選択した多地点接続装置に切り換える第３の処理と、を実行し、
（Ｂ）前記同一の会議へ参加している会議端末の何れかに障害が発生した場合には、
前記同一の会議へ参加している会議端末の各々に、会議端末側で障害が発生した旨を利用者に報知する処理の実行を指示する第４の処理と、
前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立している多地点接続装置に、前記障害の発生した会議端末との間の通信セッションを切断する処理の実行を指示する第５の処理と、を実行する
ことを特徴とする会議通信システム。
【請求項２】
前記複数の会議端末の各々は、利用者に障害復旧操作を行わせるための操作子を有し、前記監視装置から、多地点接続装置側で障害が発生したことを通知された場合には、その通知後、前記操作子が操作されるまでは、前記新たに選択された多地点接続装置から接続要請が送信されてきても、その接続要請には応じない
ことを特徴とする請求項１に記載の会議通信システム。
【請求項３】
複数の会議端末の各々との間に通信セッションを確立し、各会議端末から送信されてくる音声データを受信する一方、各会議端末に対して当該会議端末以外の会議端末から受信した音声データをミキシングして得られる音声データを送信する処理を各々実行する複数の多地点接続装置の何れかとの間に通信セッションを確立し同一の会議へ参加している会議端末の各々、および前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立している多地点接続装置の稼動監視を行う監視手段と、
監視対象の多地点接続装置に障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、多地点接続装置側に障害が発生した旨を利用者に報知する処理の実行を指示する一方、前記複数の多地点接続装置のうち障害の発生していないもののなかから前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立し直す多地点接続装置を選択し、当該会議端末の各々との間に通信セッションを確立し直して会議通信を再開する処理の実行を当該選択した多地点接続装置に指示し、前記稼動監視の対象を前記障害の発生した多地点接続装置から当該選択した多地点接続装置に切り換える処理を実行する第１の障害復旧手段と、
前記同一の会議へ参加している会議端末の何れかに障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、会議端末側で障害が発生した旨を利用者に報知する処理の実行を指示する一方、それら会議端末の各々との間に通信セッションを確立している多地点接続装置に対して前記障害の発生した会議端末との間の通信セッションを切断する処理の実行を指示する第２の障害復旧手段と
を有することを特徴とする監視装置。
【請求項４】
コンピュータ装置を、
複数の会議端末の各々との間に通信セッションを確立し、各会議端末から送信されてくる音声データを受信する一方、各会議端末に対して当該会議端末以外の会議端末から受信した音声データをミキシングして得られる音声データを送信する処理を各々実行する複数の多地点接続装置の何れかとの間に通信セッションを確立し同一の会議へ参加している会議端末の各々、および前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立している多地点接続装置の稼動監視を行う監視手段と、
監視対象の多地点接続装置に障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、多地点接続装置側に障害が発生した旨を利用者に報知する処理の実行を指示する一方、前記複数の多地点接続装置のうち障害の発生していないもののなかから前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立し直す多地点接続装置を選択し、当該会議端末の各々との間に通信セッションを確立し直して会議通信を再開する処理の実行を当該選択した多地点接続装置に指示し、前記稼動監視の対象を前記障害の発生した多地点接続装置から当該選択した多地点接続装置に切り換える処理を実行する第１の障害復旧手段と、
前記同一の会議へ参加している会議端末の何れかに障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、会議端末側で障害が発生した旨を利用者に報知する処理の実行を指示する一方、当該会議端末の各々との間に通信セッションを確立している多地点接続装置に対して前記障害の発生した会議端末との間の通信セッションを切断する処理の実行を指示する第２の障害復旧手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多地点接続装置を利用して遠隔会議を行う技術に関し、特に、通信障害時の復旧を行う技術に関する。
【背景技術】
【０００２】
ＡＤＳＬ（Asymmetric Digital
Subscriber Line）などの高速データ通信技術の普及に伴い、インターネットなどの通信網を介してテレビ電話通信や会議通信を行うことが可能になってきている。この種の通信は、多地点接続装置（Multipoint Control Unit、以下、ＭＣＵ）と、各会議参加者の利用する通信装置（以下、会議端末）との間に通信セッションを確立し（以下、「呼接続」とも呼ぶ）、音声データ通信を行わせることで実現される。具体的には、各会議端末は、自端末の利用者の音声を収音してその音声を示す音声データをＭＣＵへ送信するとともに、ＭＣＵから送信されてくる音声データを受信しその音声データの表す音声を放音する。一方、ＭＣＵは、複数の会議端末の各々から送信されてくる音声データを受信し、その各々に対して、他の会議端末から受信した各音声データをミキシングして得られる音声データを送信する。これにより、複数の会議参加者の各々に対して他の会議参加者の音声（すなわち、会議における発言を表す音声）が伝達され、会議が遂行されるのである。
【０００３】
以上説明した会議通信においては、各会議参加者が地理的に離れた場所に居る場合であっても、手軽に会議を行うことができるといった利点はあるものの、会議端末に何らかの障害が発生した場合には、会議の開催や開催中の会議の継続が不可能になるといった問題がある。従来、会議端末に何らかの障害が発生した場合には、その会議端末の利用者は、サービス・センタやヘルプデスクなどの保守担当部署に連絡し、保守担当者による障害復旧を待つ必要があった。この種の障害復旧作業においては、保守担当者は障害の発生状況の説明を受けてその発生原因を推測する必要がある。しかし、会議端末の利用者が障害の発生状況を的確に説明できることは稀であり、障害の発生原因の特定に手間取って障害復旧に遅れが生じるといった問題があった。そこで、このような問題を解決するための技術が従来より種々提案されており、その一例としては、特許文献１に開示された技術が挙げられる。
【０００４】
特許文献１に開示された技術は、会議端末の各部（例えば、スピーカやマイクロホン、通信機能を司る本体等）および通信回線を監視し障害検知を行う障害検知装置と、この障害検知装置により検知された障害の内容を示す障害情報を記憶する障害情報記憶装置とを会議端末に設けることで上記問題を解決する。より詳細に説明すると、障害検知装置により検知された障害が、会議通信に支障を来たさない軽度のものである場合には、その内容を示す障害情報の障害情報記憶装置への記憶のみにとどめ、会議通信に支障を来たすほどの重度の障害が検知された場合には、障害情報の記憶と所定の連絡先（例えば、上記保守担当部署）へ通知を発する処理を障害検知装置に実行させるのである。かかる通知を受けて障害復旧に赴いた保守担当者は、障害情報記憶装置に記憶されている障害情報から障害の発生原因を的確に把握することができ、障害復旧作業を迅速に行うことができる。また、この特許文献１には、上記障害検知装置および障害情報記憶装置をＭＣＵにも設け、ＭＣＵ側の障害復旧を迅速に行うことも開示されている。
【特許文献１】特開平７−１６２８２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、遠隔会議の開催中に何れかの会議参加者の会議端末に障害が発生すると、その発生時点から上記会議参加者の音声は他の会議参加者へ送り届けられなくなり、あたかも、上記会議参加者が会議から離脱したかのような印象を他の会議参加者へ与える場合がある。このような印象を他の会議参加者へ与えることは、「誰かの発言に不満があって退席したのではないか？」といった憶測を抱かせかねず好ましくない。また、ＭＣＵ側で障害が発生した場合には、その障害の復旧が完了するまでの間は会議の開催や継続が不可能であり、障害発生からその復旧までの間、各会議参加者は「いったい何が起こったのか、また、自分は、どういしたら良いのか」を把握することができず、不安や不満を抱く場合があった。また、特許文献１に開示された技術では、障害検知装置や障害情報記憶装置は会議端末やＭＣＵに装着されるため、会議端末やＭＣＵをインターネットなどの通信網に接続する通信経路上のネットワーク機器に障害が発生した場合には、その通信網を介したデータ通信が不能になるためサービス・センタ等への通知を行えず、障害復旧に遅れが生じるといった問題もある。
本発明は、上記課題に鑑みて為されたものであり、ＭＣＵにより会議通信を実現する通信システムにて、ＭＣＵや会議端末の障害、または通信障害が発生した場合に、その障害の発生を各会議参加者へ確実に伝達し、各会議参加者が適切な対処を行えるようにする技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために本発明は、複数の会議端末の各々との間に通信セッションを確立し、各会議端末から送信されてくる音声データを受信する一方、各会議端末に対して、当該会議端末以外の会議端末から受信した音声データをミキシングして得られる音声データを送信する処理を各々実行する複数の多地点接続装置と、前記複数の多地点接続装置のうちの予め定められたものとの間に通信セッションを確立し、各々利用者の音声を収音しその音声を示す音声データを送信する一方、前記通信セッションの接続先から受信した音声データの表す音声を出力する複数の会議端末と、前記通信セッションを確立して同一の会議へ参加している会議端末、および当該会議端末との間に通信セッションを確立して会議通信を仲介している多地点接続装置の稼動監視を行う監視装置と、を備え、前記複数の多地点接続装置および前記複数の会議端末の各々は、前記監視装置からの指示にしたがってその指示内容に則した処理を実行し、前記監視装置は、（Ａ）監視対象の多地点接続装置に障害が発生した場合には、前記同一の会議へ参加している会議端末の各々に、多地点接続装置側に障害が発生した旨を利用者に報知する処理の実行を指示する第１の処理と、前記複数の多地点接続装置のうち障害の発生していないもののなかから前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立し直す多地点接続装置を選択し、当該会議端末の各々との間に通信セッションを確立して会議通信を再開する処理の実行を当該選択した多地点接続装置に指示する第２の処理と、前記稼動監視の対象を前記障害の発生した多地点接続装置から当該選択した多地点接続装置に切り換える第３の処理と、を実行し、（Ｂ）前記同一の会議へ参加している会議端末の何れかに障害が発生した場合には、前記同一の会議へ参加している会議端末の各々に、会議端末側で障害が発生した旨を利用者に報知する処理の実行を指示する第４の処理と、前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立している多地点接続装置に、前記障害の発生した会議端末との間の通信セッションを切断する処理の実行を指示する第５の処理と、を実行することを特徴とする会議通信システム、を提供する。
【０００７】
このような会議通信システムにおいては、（Ａ）多地点接続装置側に障害が発生した場合には、監視装置からの指示に応じて、その旨を利用者に報知する処理がその多地点接続装置と通信セッションを確立していた各会議端末で実行される一方、その監視装置によって新たに選択された多地点接続装置によって、上記各会議端末との間に通信セッションを確立し直し会議通信を再開する処理が実行される。各会議参加者は、通信セッションの接続先の切り換えが完了するまでは、会議通信を再開することはできないのであるが、上記報知により、多地点接続装置側の障害により、かかる事態が生じていることを把握することができ、それら会議参加者の抱く不安や不満を和らげることが可能になる。また、（Ｂ）同一の会議へ参加している会議端末の何れかに障害が発生した場合には、監視装置からの指示に応じて、その旨を利用者に報知する処理が、障害の発生していない各会議端末で実行される。これにより、障害の発生していない会議端末の各利用者は、会議端末の障害が復旧するまでは、上記障害の発生した会議端末の利用者の会議参加は不可能であることを把握することができ、無用な誤解や憶測を招く虞はない。また、会議端末側で障害が発生した場合には、障害の発生した会議端末との間の通信セッションを切断する旨の指示が監視装置から多地点接続装置に与えられ、この指示を受信した多地点接続装置は、その指示に応じて通信セッションを切断する処理を実行する。多地点接続装置が同時に接続可能な通信セッションの数には制限があることが一般的であり、何らかの障害が発生し音声データの送受信が不可能になった会議端末との間の通信セッションを確立したままにしておくことは、限りあるリソースの無駄遣いであって好ましくないが、本発明によれば、かかるリソースの無駄遣いが回避される。また、本発明では、上記監視装置を多地点接続装置や会議端末とは別個に設けているため、特許文献１に開示された技術に比較してシステム全体の信頼性が向上するといった効果もある。
【０００８】
より好ましい態様においては、前記会議通信システムの複数の会議端末の各々は、利用者に障害復旧操作を行わせるための操作子を有し、前記監視装置から、多地点接続装置側で障害が発生したことを通知された場合には、その通知後、前記操作子が操作されるまでは、前記新たに選択された多地点接続装置から接続要請が送信されてきても、その接続要請には応じないことを特徴とする。
【０００９】
また、上記課題を解決するために本発明は、複数の会議端末の各々との間に通信セッションを確立し、各会議端末から送信されてくる音声データを受信する一方、各会議端末に対して当該会議端末以外の会議端末から受信した音声データをミキシングして得られる音声データを送信する処理を各々実行する複数の多地点接続装置の何れかとの間に通信セッションを確立し同一の会議へ参加している会議端末の各々、および前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立している多地点接続装置の稼動監視を行う監視手段と、監視対象の多地点接続装置に障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、多地点接続装置側に障害が発生した旨を利用者に報知する処理の実行を指示する一方、前記複数の多地点接続装置のうち障害の発生していないもののなかから前記同一の会議へ参加している会議端末の各々との間に通信セッションを確立し直す多地点接続装置を選択し、当該会議端末の各々との間に通信セッションを確立し直して会議通信を再開する処理の実行を当該選択した多地点接続装置に指示し、前記稼動監視の対象を前記障害の発生した多地点接続装置から当該選択した多地点接続装置に切り換える処理を実行する第１の障害復旧手段と、前記同一の会議へ参加している会議端末の何れかに障害が発生した場合に、前記同一の会議へ参加している会議端末の各々に、会議端末側で障害が発生した旨を利用者に報知する処理の実行を指示する一方、それら会議端末の各々との間に通信セッションを確立している多地点接続装置に対して前記障害の発生した会議端末との間の通信セッションを切断する処理の実行を指示する第２の障害復旧手段とを有することを特徴とする監視装置、およびコンピュータ装置を上記各手段として機能させることを特徴とするプログラム、を提供する。
【発明を実施するための最良の形態】
【００１０】
以下、本発明を実施するための最良の形態を図面を参照しつつ説明する。
（Ａ：構成）
図１は、本発明の一実施形態に係る監視装置４０を含む会議通信システム１の構成例を示す図である。図１に示すように、会議通信システム１には、会議参加者Ａ、Ｂ、ＣおよびＤの各々に利用される４台の会議端末（会議端末２０Ａ〜２０Ｄ）と、２台のＭＣＵ（ＭＣＵ３０Ｐおよび３０Ｓ）と、監視装置４０とが含まれる。図１に示すように、上記各装置は通信網１０に接続される。以下では、上記４台の会議端末の各々を区別する必要がない場合には「会議端末２０」と表記し、上記２台のＭＣＵの各々を区別する必要がない場合には「ＭＣＵ３０」と表記する。
【００１１】
通信網１０は、例えばインターネットなどの電気通信回線であり、所定の通信プロトコルにしたがって行われるデータ通信を仲介するためのものである。上記通信プロトコルとしては、プロトコル階層毎に種々のものを用いることが考えられる。例えば、本実施形態では、ネットワーク層についてはＩＰ（Internet Protocol）が、トランスポート層についてはＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）が、アプリケーション層についてはＴＥＬＮＥＴやＲＴＰ（Real-time Transport Protocol）が用いられる。この通信網１０は、会議端末２０とＭＣＵ３０との間で行われる音声データ通信を仲介するとともに、監視装置４０と会議端末２０との間、または、監視装置４０とＭＣＵ３０との間で行われる各種制御コマンドの通信を仲介する役割を果たす。
【００１２】
会議端末２０は、音声入出力機能およびデータ通信機能を備えた電子機器である。前述した４人の会議参加者は、各々の会議端末２０を使用して通信網１０を介して提供される会議通信サービスを利用すること（すなわち、遠隔会議に参加すること）ができる。より詳細に説明すると、会議端末２０は、ＳＩＰ（Session Initiation Protocol）などの所定の通信プロトコルにしたがってＭＣＵ３０との間に通信セッションを確立する。そして、会議端末２０は、自装置の利用者の音声を収音してその音声を表す音声データをＭＣＵ３０へ送信する一方、ＭＣＵ３０から送信されてくる音声データの表す音声を放音する。図２は、会議端末２０の外観を示す図である。図２の２１０はマイクロホンおよびスピーカを含む音声入出力部、２２０は液晶ディスプレイなどの表示部、２３０は障害復旧ボタンである。音声入出力部２１０は、会議端末２０の利用者の音声の収音およびＭＣＵ３０から受信した音声データの表す音の放音を行うためのものである。表示部２２０は、各種メッセージ（例えば、会議端末２０の利用操作を促すメッセージ等）を表示するためのものである。そして、障害復旧ボタン２３０は、ＭＣＵ側に何らかの障害が発生した場合に、その障害に対処する操作を会議参加者に行わせるための操作子である。
【００１３】
ＭＣＵ３０は、複数の会議端末２０の各々との間に通信セッションを確立し会議通信を仲介する電子機器である。ここで、会議通信を仲介するとは、自装置と通信セッションを確立している会議端末２０の各々から送信されてくる音声データを受信し、これら会議端末２０の各々に対して、他の会議端末２０から受信した音声データをミキシングして得られる音声データを送信することである。例えば、図３には、会議端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄの各々との間に通信セッションを１本ずつ確立し、会議通信の仲介を行っているＭＣＵ３０の様子が示されている。この図３に示す例では、会議端末２０Ａに対しては、会議端末２０Ｂ、２０Ｃおよび２０Ｄから受信した音声データ（音声データＢ、音声データＣおよび音声データＤ）をミキシングして得られる音声データＡ＊（音声データＡ＊＝音声データＢ＋音声データＣ＋音声データＤ）がＭＣＵ３０から送信される。このようにＭＣＵ３０から送信される音声データＡ＊の表す音声が会議端末２０Ａの音声入出力部２１０から放音されることによって、会議参加者Ａは、他の会議参加者（すなわち、会議参加者Ｂ、ＣおよびＤ）の発言を聴くことができるのである。
【００１４】
図１に示すように会議通信システム１には、ＭＣＵ３０Ｐおよび３０Ｓの２台のＭＣＵが含まれている。これら２台のＭＣＵは、何れも会議通信を仲介する機能を有する点で同一であるが、本実施形態では、各々異なる役割を担っている。具体的には、本実施形態では、原則、ＭＣＵ３０Ｐによって会議通信サービスの提供が行われ、ＭＣＵ３０Ｓは、ＭＣＵ３０Ｐに何らかの障害が発生した場合に、ＭＣＵ３０Ｐに代わって会議通信サービスの提供を行えるようにスタンバイ状態で運用される。以下、ＭＣＵ３０Ｐのように原則的に通信サービスの提供に用いられる装置のことを「プライマリ装置」と呼び、ＭＣＵ３０Ｓのようにスタンバイ状態でう運用され、プライマリ装置に障害が発生した場合にそのプライマリ装置に換えて通信サービスの提供に用いられる装置のことを「セカンダリ装置」と呼ぶ。
【００１５】
上記のようにＭＣＵ３０ＰとＭＣＵ３０Ｓは、各々異なる役割を担うため、各々の構成も異なっている。より詳細に説明すると、ＭＣＵ３０Ｐには、図４（Ａ）に示す会議情報が予め格納されている。図４（Ａ）に示す会議情報には、ＭＣＵ３０Ｐを利用して開催される遠隔会議を一意に識別する会議識別子（例えば、会議名を示す文字列データ）、その会議の開始予定日時および終了予定日時を示すデータ、その会議への参加予定者の各々が利用する会議端末２０を一意に識別する識別子（例えば、会議端末２０の通信アドレス）のリスト（以下、参加予定端末リスト）が含まれる。ＭＣＵ３０Ｐの制御部（図示省略）は、自装置に格納されている会議情報を参照し、直近に開催予定の会議（会議情報を参照した時点から所定時間（例えば、５分）内に開催が予定されている会議）が有るか否かを判定し、該当する会議があると判定した場合には、その参加予定の会議端末２０へ宛てて通信セッションの確立を要請する旨の通信メッセージ（以下、接続要請）を送信する処理を実行する。そして、ＭＣＵ３０Ｐの制御部は、通信セッションの確立を要求する旨の通信メッセージ（以下、接続要求）が返信されてくると、各接続要求の送信元アドレスのリスト（以下、参加端末リスト）と上記会議識別子とを対応付けて図４（Ｂ）に示す拠点情報を生成して記憶する。以降、ＭＣＵ３０Ｐは、前述した会議通信の仲介を行うのである。一方、ＭＣＵ３０Ｓには、その起動開始時点では会議情報（図４（Ａ）参照）は格納されておらず、ＭＣＵ３０Ｐに何らかの障害が発生したことを契機として監視装置４０経由で送信されてくる会議情報および拠点情報を受信し、記憶する。このようにして会議情報および拠点情報を記憶したＭＣＵ３０Ｓは、前述した接続要請の送信等の処理を実行して各会議端末２０との間に通信セッションを確立し、会議通信の仲介を開始するのである。
【００１６】
監視装置４０は、会議通信の仲介を行っているＭＣＵ３０（本実施形態では、原則、ＭＣＵ３０Ｐ）や、そのＭＣＵ３０との間に通信セッションを確立して会議通信を行っている会議端末２０の稼動状況を監視し、会議通信サービスの継続に何らかの支障を与える障害が発生した場合にはその障害を復旧するための処理の実行指示を各装置に与える。より詳細に説明すると、監視装置４０は、その監視対象である各装置に対して、稼動状況確認用の通信メッセージ（以下、稼動確認メッセージ）を定期的に送信し、その稼動確認メッセージに対する応答が返信されてくる場合には、監視対象の各装置は支障なく稼動していると判定する。逆に、監視対象の装置の何れかから上記応答を受信しなかった場合には、監視装置４０は、上記応答を返信してこなかった装置について何らかの障害が発生したと判定し、その装置の種類（ＭＣＵ３０であるか会議端末２０であるか）に応じた障害復旧指示を各装置に与える。本実施形態の特徴は、かかる監視装置４０を設けたことにある。
以下、本実施形態の特徴を顕著に示す監視装置４０の構成および動作を中心に説明する。
【００１７】
図５は、監視装置４０の構成例を示すブロック図である。図５に示すように、監視装置４０は、制御部４１０、通信インタフェース（以下、「Ｉ／Ｆ」と表記する）部４２０、記憶部４３０、およびこれら各構成要素間のデータ授受を仲介するバス４４０を有する。
【００１８】
制御部４１０は、例えばＣＰＵ（Central Processing Unit）である。制御部４１０は、記憶部４３０に格納されている監視プログラム４３２ａにしたがって作動し監視装置４０の制御中枢として機能する。制御部４１０が監視プログラム４３２ａにしたがって実行する動作（図６参照）については後に明らかにする。
【００１９】
通信Ｉ／Ｆ部４２０は、例えばＮＩＣ（Network
Interface Card）であり、通信網１０に接続されている。通信Ｉ／Ｆ部４２０は、通信網１０を介してパケット単位で送信されてくるデータを受信し、そのデータを制御部４１０へ引渡す一方、制御部４１０から引渡されるデータを通信網１０へと送出する。
【００２０】
記憶部４３０は、揮発性記憶部４３１と不揮発性記憶部４３２とを含んでいる。揮発性記憶部４３１は、例えばＲＡＭ（Random Access Memory）であり、監視プログラム４３２ａを実行する際のワークエリアとして制御部４１０によって利用される。また、揮発性記憶部４３１には、監視対象とするＭＣＵを一意に識別する識別子（例えば、監視対象のＭＣＵの通信アドレス：以下、監視対象識別子）と、そのＭＣＵに障害が発生した場合にバックアップを行うＭＣＵの識別子（例えば、バックアップ用ＭＣＵの通信アドレス、以下、バックアップ機識別子）が、運用管理者による初期設定作業で書き込まれる。本実施形態では、監視対象識別子としてはＭＣＵ３０Ｐの通信アドレスが、バックアップ機識別子としてはＭＣＵ３０Ｓの通信アドレスが上記初期設定作業にて揮発性記憶部４３１に書き込まれる。
【００２１】
一方、不揮発性記憶部４３２は、例えばハードディスクやＦｌａｓｈＲＯＭ（Flash Read Only Memory）などの不揮発性メモリである。不揮発性記憶部４３２には、前述した監視プログラム４３２ａが格納されている他、管理テーブル４３２ｂが格納されている。管理テーブル４３２ｂは、監視対象識別子の示すＭＣＵ３０に記憶されている会議情報（図４（Ａ）参照）および拠点情報（図４（Ｂ）参照）を格納するためのテーブルである。詳細については後述するが、本実施形態では、監視対象識別子の示すＭＣＵの稼動監視の開始に先立って、そのＭＣＵから会議情報および拠点情報を収集し管理テーブル４３２ｂへ書き込む処理が制御部４１０によって実行される。そして、上記稼動監視の実行中に監視対象のＭＣＵに何らかの障害が発生したことが検知された場合には、管理テーブル４３２ｂに格納されている会議情報および拠点情報を、バックアップ機識別子の示すＭＣＵへ送信し、それら情報を当該ＭＣＵに記憶させる処理が制御部４１０によって実行される。
以上が監視装置４０の構成である。
【００２２】
（Ｂ：動作）
次いで、会議端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄの各々がＭＣＵ３０Ｐとの間に通信セッションを確立して会議通信を行っている場合（図３参照）を例にとって、監視装置４０および会議端末２０の各々が実行する処理について図６および図７を参照しつつ説明する。
【００２３】
図６は、制御部４１０が監視プログラム４３２ａにしたがって実行する監視処理の流れを示すフローチャートである。図６に示すように、制御部４１０は、まず、監視対象識別子の示すＭＣＵ（本実施形態では、ＭＣＵ３０Ｐ）から会議情報および拠点情報を取得する処理を実行する（ステップＳＡ０１０）。より詳細に説明すると、制御部４１０は、会議情報および拠点情報の返信を指示する旨の制御コマンドを内包した通信メッセージを生成し、その通信メッセージを監視対象識別子の示すＭＣＵへＴＥＬＮＥＴにしたがって送信する。以下、ＭＣＵ３０や会議端末２０に対して何らかの処理の実行を指示する制御コマンドが書き込まれた通信メッセージのことを「指示メッセージ」と呼ぶ。
上記のようにして監視装置４０から送信されてくる指示メッセージを受信したＭＣＵ３０Ｐは、その指示メッセージに含まれている制御コマンドを実行し、会議情報および拠点情報を監視端末４０へ返信する。制御部４１０は、このようにして返信されてくる会議情報および拠点情報を受信して管理テーブル４３２ｂに書き込むことで、上記ステップＳＡ０１０の処理を実現するのである。
【００２４】
次いで、制御部４１０は、ステップＳＡ０１０にて取得した会議情報を参照し、開催中の会議があるか否かを判定し（ステップＳＡ０２０）、その判定結果が“Ｙｅｓ”である場合には、後続のステップＳＡ０３０の処理を実行する。逆に、ステップＳＡ０２０の判定結果が“Ｎｏ”である場合には、制御部４１０は、本監視処理を終了する。ここで、開催中の会議があるか否かの判定は、会議情報の参照を行った時点の時刻が、開始予定時刻よりも後で、終了予定時刻よりも前である会議の会議識別子が会議情報に含まれているか否かにより判定すれば良い。
【００２５】
ステップＳＡ０３０では、ステップＳＡ０２０にて開催中であると判定された会議へ参加している各会議端末２０（その会議の会議識別子に対応付けて拠点情報に含まれている参加端末リストの示す各会議端末２０）およびその会議を開催中のＭＣＵ（監視対象識別子の示すＭＣＵ、本動作の開始時点では、ＭＣＵ３０Ｐ）に対して、稼動確認メッセージを送信する処理が実行される。ステップＳＡ０３０で送信する稼動確認メッセージとしては種々のものを用いることが考えられるが、その一例としてはＰＩＮＧ（Packet INternet Groper）メッセージを用いることが挙げられる。ＰＩＮＧとは、他の通信装置との通信網を介した通信が可能であるか否か（つまり、ネットワーク疎通に異常があるか否か）を確認するためのソフトウェアである。ＰＩＮＧを用いたネットワーク疎通の確認では、ＩＣＭＰ（Internet Control Message
Protocol）の“echo message”をその確認対象である通信装置へ送信し、”echo
reply message”が返信されてくる場合は、ネットワーク疎通は正常であると判定され、”echo reply
message”が返信されない場合は、ネットワーク疎通に異常があると判定される。
【００２６】
そして、制御部４１０は、ステップＳＡ０３０にて送信した稼動確認メッセージに対する各装置の応答状況から、それら装置との間のネットワーク疎通に異常が生じたか否かを判定する（ステップＳＡ０４０）。制御部４１０は、ステップＳＡ０４０の判定結果が“Ｎｏ”である場合（すなわち、異常なしと判定した場合）には、ステップＳＡ０１０以降の処理を繰り返し実行し、逆に、ステップＳＡ０４０の判定結果が“Ｙｅｓ”である場合（すなわち、異常ありと判定した場合）には、ステップＳＡ０５０以降の処理を実行する。ここで、ネットワーク疎通に異常が発生したと判断される場合の一例としては、ネットワーク疎通の確認対象である通信装置に何らかの故障が発生し稼動確認メッセージの受信または応答を行うことができなかった場合や、ネットワーク疎通の確認対象である通信装置へ至る通信経路上のネットワーク機器に故障が発生し稼動確認メッセージがその宛先へと到達しなかった場合が考えられる。以下では、ＭＣＵ３０Ｐに関してネットワーク疎通に異常が発生した場合と、会議端末２０Ａに関してネットワーク疎通に異常が発生した場合とに場合分けして、監視装置４０および会議端末２０が実行する処理について説明する。
【００２７】
（Ｂ−１：ＭＣＵ３０Ｐとのネットワーク疎通に異常が発生した場合の動作）
図６に示すように、何れかの装置についてネットワーク疎通に異常が発生したと判定された場合に実行されるステップＳＡ０５０においては、障害の発生およびその発生箇所（ＭＣＵ側であるのか、端末側であるのか）を報知する処理の実行を指示する指示メッセージ（以下、障害通知）にステップＳ０４０にて異常ありと判定された通信装置を示す識別子（例えば通信アドレス）書き込んで各会議端末２０へ送信する処理が実行される。このステップＳＡ０５０は、ネットワーク疎通の異常により会議の継続に支障が生じることとなった場合に、障害の発生およびその発生箇所を各会議端末２０に報知させ、適切な対処の実行を促すために実行される処理である。なお、上記障害通知を受信した場合に各会議端末２０が実行する処理については後に詳細に説明することとし、制御部４１０が実行する監視処理の説明を続ける。
【００２８】
ステップＳＡ０５０に後続するステップＳＡ０６０では、障害の発生箇所がＭＣＵ側であるのか否かの判定が行われる。そして、ステップＳＡ０６０の判定結果が“Ｙｅｓ”である場合には、制御部４１０は、バックアップ用ＭＣＵ（すなわち、バックアップ機識別子の示すＭＣＵ，本実施形態では、ＭＣＵ３０Ｓ）に対して、管理テーブル４３２ｂに格納されている会議情報および拠点情報を送信するとともに、会議通信サービスの提供を開始すべきことを指示する指示メッセージを送信し（ステップＳＡ０８０）、監視対象をバックアップ用ＭＣＵに変更する処理（すなわち、監視対象識別子をバックアップ機識別子で上書きする処理：ステップＳＡ０９０）を実行する。以降、制御部４１０は、ステップＳＡ０１０以降の処理を繰り返す。
このように、会議通信システム１にてプライマリ装置の役割を果たすＭＣＵ３０Ｐに何らかの障害が発生し会議通信サービスの提供が不可能になった場合には、予めＭＣＵ３０Ｐから取得しておいた会議情報および拠点情報が監視装置４０からセカンダリ装置であるＭＣＵ３０Ｓに配信される。そして、ＭＣＵ３０Ｓは、実際に会議へ参加していた会議端末２０を、これら会議情報および拠点情報を参照して特定し、それら会議端末２０へ接続要請を送信する処理を実行してそれら会議端末２０との間に通信セッションを確立し会議通信の仲介を開始するのである。
以上が、ＭＣＵ側で障害が発生した場合に監視装置４０の制御部４１０が実行する処理である。
【００２９】
次いで、障害通知を受信した会議端末２０が実行する処理について説明する。図７は、障害通知を受信した会議端末２０が実行する処理の流れを示すフローチャートである。図７に示すように、会議端末２０は、障害通知を受信すると、その障害通知を解析して障害の発生箇所がＭＣＵ側であるのか否かを判定する（ステップＳＢ０１０）。そして、その判定結果が“Ｙｅｓ”である場合（すなわち、障害の発生箇所はＭＣＵ側であると判定した場合）は、ステップＳＢ０２０以降の処理を実行する。
【００３０】
ステップＳＢ０２０では、ＭＣＵとの呼接続を切断する処理が実行される。なお、ＭＣＵ側に何らかの障害が発生した場合には、その障害の発生時点でそのＭＣＵとの呼接続が既に切断されている場合もあるから、このステップＳＢ０２０の処理は、ＭＣＵとの呼接続が維持されている場合にのみ実行するようにすれば良い。
【００３１】
次いで、会議端末２０は、ステップＳＢ０１０で受信した障害通知にしたがって、障害の発生およびその発生箇所を利用者に報知する処理（ステップＳＢ０３０）を実行する。一般に、ＭＣＵ側に何らかの障害が発生すると、その発生時点から他の会議参加者の音声が聴こえなくなり、利用者に不安や不満を感じさせるのであるが、本実施形態では、上記報知によって、このような不安や不満を和らげることが可能になる。ここで、障害の発生およびその発生箇所の報知態様としては、種々のものが考えられる。例えば、「ＭＣＵ側に障害が発生しました。障害復旧ボタンを押下して下さい。」といったガイドメッセージを音声入出力部２１０に放音させる態様や、同ガイドメッセージを表示部２２０に表示させる態様が考えられる。また、障害復旧ボタン２３０の近傍にＬＥＤを設け、その明滅により報知する態様であっても良い。このような報知を行うことによって、障害復旧のための適切な操作（本実施形態では、障害復旧ボタン２３０の押下）を各会議参加者に把握させ、その操作の実行を促すことが可能になる。
【００３２】
次いで、会議端末２０は、障害復旧ボタン２３０が押下されたか否かを判定し（ステップＳＢ０４０）、その判定結果が“Ｙｅｓ”である場合は、監視装置４０により新たに選択されたＭＣＵ（本実施形態では、ＭＣＵ３０Ｓ）から接続要請が送信されてくることを待ち受け、接続要請が送信されてきた場合にはそのＭＣＵへ接続（すなわち、通信セッションを確立）し（ステップＳＢ０５０）、本障害復旧処理を完了する。会議端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄの各々がＭＣＵ３０Ｓへの接続を完了し、これら４台の会議端末とＭＣＵ３０Ｓとの間に通信セッションが確立されると（図３参照）、会議通信の再開が可能になる。
【００３３】
これに対して、ステップＳＢ０４０の判定結果が“Ｎｏ”である場合には、会議端末２０は、ガイドメッセージの出力回数（または出力時間）が所定の閾値に達したか否かを判定し（ステップＳＢ０６０）、その判定結果が“Ｎｏ”である場合には、ステップＳＢ０３０以降の処理を繰り返し、逆に、その判定結果が“Ｙｅｓ”である場合には、本障害復旧処理を終了する。ガイドメッセージの出力回数（または出力時間）が所定の閾値に達しても障害復旧ボタン２３０の押下が検出されない場合には、当該会議端末の利用者については、会議への参加継続の意思を失ったものとみなして会議通信サービスの利用を終了するものである。
【００３４】
このように、本実施形態によれば、会議の開催中にＭＣＵ側に何らかの障害（ＭＣＵの故障や通信障害）が発生したとしても、障害の発生およびその発生箇所を各会議参加者に的確に把握させ、適切な対処の実行を促すことが可能になる。また、本実施形態では、各会議参加者は障害復旧ボタン２３０を押下するだけで、新たなＭＣＵを利用した会議通信の再開が可能であるため、手軽に障害を復旧させることが可能である。
【００３５】
（Ｂ−２：会議端末２０Ａとのネットワーク疎通に異常が発生した場合の動作）
次いで、会議端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄの各々がＭＣＵ３０Ｓとの間に通信セッションを確立し直して会議通信を行っている状況下で、会議端末２０Ａについてネットワーク疎通に異常が発生した場合に、監視装置４０および会議端末２０Ｂ、２０Ｃおよび２０Ｄが実行する処理について説明する。
【００３６】
図６に示すように、会議端末２０Ａについてのネットワーク疎通の異常が検出された場合（ステップＳＡ０４０：Ｙｅｓ）も、制御部４１０は、前述したステップＳＡ０５０およびステップＳＡ０６０の処理を実行する。ただし、ステップＳＡ０５０の処理においては、ネットワーク疎通の異常が検出された会議端末（本動作例では、会議端末２０Ａ）に対しては障害通知を送信しない点と、ステップＳＡ０６０の判定結果が“Ｎｏ”になる点が、前述したＭＣＵ側で障害が発生した場合と異なる。ここで、ネットワーク疎通の異常が検出された会議端末に対して障害通知を送信しないのは、ネットワーク疎通が発生している会議端末へ障害通知を送信しても、その障害通知がその宛先まで到達するとはないと考えられるからである。なお、障害の発生を通知された場合に会議端末２０Ｂ、２０Ｃおよび２０Ｄの各々が実行する処理については後に詳細に説明する。
【００３７】
ステップＳＡ０６０の判定結果が“Ｎｏ”である場合、制御部４１０は、監視対象のＭＣＵ（すなわち、ＭＣＵ３０Ｓ）に対して、ネットワーク疎通に異常が検知された会議端末との間の通信セッションを切断することを指示する指示メッセージを送信し（ステップＳＡ０７０）、以降、ステップＳＡ０１０以降の処理を繰り返し実行する。このようにして監視装置４０から送信される指示メッセージを受信したＭＣＵ３０Ｓは、その指示メッセージに含まれている制御コマンドを実行し、ネットワーク疎通に異常が検知された会議端末との間の通信セッションを切断する。ここで、上記のような通信セッションの切断を指示する理由は以下の通りである。一般にＭＣＵにおいては同時に接続可能な通信セッションの数に制限があるため、上記のように不要になった通信セッションをそのままにしておくことは、開催中の会議に対して途中参加しようとする際の障害（すなわち、ＭＣＵ３０Ｓが確立している通信セッションの数が上記制限値に達しているため、新たな通信セッションを確立できないこと）となる可能性があるからである。
【００３８】
一方、会議端末２０（本動作例では、会議端末２０Ｂ、２０Ｃおよび２０Ｄ）が実行する動作についても、障害通知の受信を契機として障害の発生箇所の判定（ステップＳＢ０１０）を行う点は、前述したＭＣＵ側で障害が発生した場合の動作と同様である。しかし、本動作例では、ステップＳＢ０１０の判定結果が“Ｎｏ”になり、ステップＳＢ０７０以降の処理が実行される点が異なる（図７参照）。
【００３９】
ステップＳＢ０７０では、他の会議参加者の会議端末に障害が発生した旨を報知する処理が実行される。具体的には、「他の会議参加者の会議端末に障害が発生しました。よって、この会議参加者は会議から離脱いたします。」といったガイドメッセージを音声入出力部２１０に放音させたり、同ガイドメッセージを表示部２２０に表示させる処理である。次いで、会議端末２０は、上記ガイドメッセージの出力回数（あるいは出力時間）が所定の閾値に達したか否かを判定し（ステップＳＢ０８０）、その判定結果が“Ｎｏ”である間は、ステップＳＢ０７０の処理を繰り返し実行し、逆に、ステップＳＢ０８０の判定結果が“Ｙｅｓ”になると、本障害復旧処理を終了する。
【００４０】
以上説明したように本実施形態によれば、会議通信を仲介するＭＣＵや複数の会議端末の何れかに障害（或いはこれら各装置へ至る通信経路の障害）が発生した場合に、その会議通信サービスの各利用者に、どのような事態が生じたのか、また、どのように対処すれば良いのかを確実に把握させ、適切な対処の実行を促すことが可能になる。
【００４１】
（Ｃ：変形）
以上、本発明の一実施形態について説明したが、かかる実施形態に以下に述べる変形を加えても良いことは勿論である。
（１）上述した実施形態では、障害復旧ボタン２３０が押下されたことを検知した場合に、新たに選択されたＭＣＵから送信された接続要請に応じる処理を会議端末２０に実行させた。しかし、ＭＣＵ側に障害が発生したことを示す障害通知を受信した場合には、その後に送信されてくる接続要請に無条件に応じる処理を会議端末２０に実行させても良い。このような態様によれば、ユーザに特段の操作を行わせることなく通信セッションの確立先を変更して会議通信を継続することが可能になる。また、より好ましい態様においては、ＭＣＵ側に障害が発生したことを示す障害通知を受信してから、新たに選択されたＭＣＵとの通信セッションの確立が完了するまでの間は、「ＭＣＵとの通信が不能になっています。他のＭＣＵへ接続し直しますので、しばらくお待ち下さい」といったガイドメッセージを出力する処理を会議端末２０に実行させ、新たなＭＣＵとの通信セッションの確立が完了した時点で「新たなＭＣＵへの接続が完了いたしました。会議の再開が可能です。」といったガイドメッセージを出力する処理を会議端末２０に実行させても良い。
【００４２】
（２）上述した実施形態では、ＭＣＵ３０ＳをＭＣＵ３０Ｐのバックアップ用のセカンダリ装置として待機状態で運用した。しかし、セカンダリ装置については通常は電源を切断しておき、プライマリ装置に障害が発生したことを契機としてセカンダリ装置の電源を投入し、その後、セカンダリ装置の初期化等を行ってプライマリ装置の代わりに処理を開始させても良い。また、上述した実施形態では、ＭＣＵ３０Ｐと３０Ｓに各々異なる役割を担わせたが、ＭＣＵ３０ＰとＭＣＵ３０Ｓとに対等の役割を担わせる態様、すなわち、ＭＣＵ３０ＰおよびＭＣＵ３０Ｓの各々に会議通信サービスを提供させ、一方に障害（あるいは通信障害）が発生した場合には、他方にそのバックアップを行わせる態様であっても良い。また、会議通信システム１に３台以上のＭＣＵが含まれても良い。それら複数のＭＣＵのうちの何れかに障害が発生した場合には、他のＭＣＵのうちからそのバックアップを行うものを選択する処理を監視装置４０に実行させるようにすれば良い。ここで、新たなＭＣＵの選択方法としては、例えば、障害の発生していないＭＣＵのうち、かかっている処理負荷が最も軽いものを選択することが考えられる。このようなことを実現するためには、例えば上記複数のＭＣＵの各々に、稼動確認通知に対する応答の際にその時点で自装置にかかっている処理負荷を示すデータを返信させるようにすれば良い。
【００４３】
また、複数のＭＣＵのうちから、各ＭＣＵにかかっている処理負荷に応じてバックアップ用のＭＣＵを選択する態様においては、かかっている処理負荷の軽いものから順に複数のＭＣＵを選択し、これら複数のＭＣＵを連携させて、障害の発生したＭＣＵの代わりに各会議端末２０との間に通信セッションを確立し直して会議通信を再開させるようにしても良い。例えば、図８（Ａ）に示すように、４台の会議端末（会議端末２０−１〜２０−４）の各々との間に通信セッションを確立し会議通信を仲介していたＭＣＵ３０−１に障害が発生し、ＭＣＵ３０−２および３０−３の２台がバックアップ機として選択される場合、ＭＣＵ３０−２にかかっている処理負荷がＭＣＵ３０−３にかかっている処理負荷よりも高い場合には、図８（Ｂ）に示すネットワークトポロジとなるように通信セッションを確立させるようにすれば良い。図８（Ｂ）に示すネットワークトポロジでは、ＭＣＵ３０−２には、会議端末２０−１とＭＣＵ３０−３が接続される一方、ＭＣＵ３０−３にはＭＣＵ３０−２、会議端末２０−２、会議端末２０−３および会議端末２０−４の４台の通信装置が接続される。なお、図８（Ｂ）に示すネットワークトポロジを実現するには、ＭＣＵ３０−２に対しては、ＭＣＵ３０−３および会議端末２０−１へ接続要請を送信する旨の指示を、ＭＣＵ３０−３に対しては、会議端末２０−２、会議端末２０−３および会議端末２０−４へ接続要請を送信し、かつ、ＭＣＵ３０−２にからの接続要請に応じる旨の指示を与える処理を監視装置４０に実行させるようにすれば良い。
【００４４】
（３）上述した実施形態では、プライマリＭＣＵ（ＭＣＵ３０Ｐ）の障害に備えて、そのプライマリＭＣＵに格納されている会議情報および拠点情報を監視装置４０に取得させ、プライマリＭＣＵに何らかの障害が発生した場合には、監視装置４０からセカンダリＭＣＵ（ＭＣＵ３０Ｓ）へ上記会議情報および拠点情報を送信して記憶させ、その会議情報および拠点情報にしたがって接続要請を送信し会議通信を再開する処理をセカンダリＭＣＵに実行させた。しかし、プライマリＭＣＵとセカンダリＭＣＵが１台の記憶装置（例えばハードディスク）を共有し、その記憶装置に会議情報および拠点情報が格納される態様や、プライマリＭＣＵとセカンダリＭＣＵとが各々別個に記憶装置を有するものの、それら記憶装置のミラーリング（一方の記憶装置へデータの書き込みを行う際には、同一のデータを他方の記憶装置にも書き込む処理）を行う態様においては、監視装置４０経由で会議情報および拠点情報の転送を行う必要はない。これらの態様においては、プライマリＭＣＵの障害を検知したことを契機として、接続要請の送信を指示する旨の制御コマンドが書き込まれた制御メッセージをセカンダリＭＣＵへ送信する処理を監視装置４０に実行するだけで良い。
【００４５】
（４）上述した実施形態では、本発明の特徴を顕著に示す監視処理を制御部４１０に実行させる監視プログラム４３２ａが不揮発性記憶部４３２に予め格納されていた。しかし、例えばＣＤ−ＲＯＭ（Compact Disk Read Only Memory）などのコンピュータ装置読み取り可能な記録媒体に監視プログラム４３２ａを書き込んで配布しても良く、また、インターネットなどの電気通信回線経由のダウンロードにより監視プログラム４３２ａを配布しても良い。このようにして配布される監視プログラム４３２ａを一般的なコンピュータ装置に記憶させ、その監視プログラム４３２ａにしたがってそのコンピュータ装置の制御部（ＣＰＵ）を作動させることによって、そのコンピュータ装置に監視装置４０と同一の機能を付与することが可能になる。また、上述した実施形態では、本発明に係る監視装置に特徴的な機能をソフトウェアモジュールで実現したが、ハードウェアモジュール（例えば、電子回路）で実現しても勿論良い。
【図面の簡単な説明】
【００４６】
【図１】本発明の一実施形態に監視装置４０を含む会議通信システム１の構成例を示す図である。
【図２】会議通信システム１に含まれる会議端末２０の外観を示す図である。
【図３】同ＭＣＵ３０のミキシング機能を説明するための図である。
【図４】同ＭＣＵ３０Ｐに記憶されている会議情報および拠点情報の一例を示す図である。
【図５】同監視装置４０の構成例を示す図である。
【図６】同監視装置４０の制御部４１０が監視プログラム４３２ａにしたがって実行する監視処理の流れを示すフローチャートである。
【図７】会議端末２０が実行する処理の流れを示すフローチャートである。
【図８】変形例（２）を説明するための図である。
【符号の説明】
【００４７】
１…会議通信システム、１０…通信網、２０，２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ…会議端末、３０，３０Ｐ、３０Ｓ…ＭＣＵ、４０…監視装置、４１０…制御部、４２０…通信Ｉ／Ｆ部、４３０…記憶部、４３１…揮発性記憶部、４３２…不揮発性記憶部、４３２ａ…監視プログラム、４３２ｂ…管理テーブル、４４０…バス。
【図１】
2009232015.tif 000003
【図２】
2009232015.tif 000004
【図３】
2009232015.tif 000005
【図４】
2009232015.tif 000006
【図５】
2009232015.tif 000007
【図６】
2009232015.tif 000008
【図７】
2009232015.tif 000009
【図８】
2009232015.tif 000010