(57)【要約】【課題】会議リソースのさらなる有効活用を図った会議システムを提供すること。【解決手段】ビデオ送受信機能のオン／オフ、あるいは話者の減少といったイベントが検出された場合でも、空きとなったＭＣＵ５０のリソースを盲目的に解放することをしない。すなわち、ＶＣＳサーバ３０は余剰分のリソースが生じた際の処理の設定を設定条件情報７０ｂにより確認し、その設定に応じた条件化での処理を行う。例えば、処理条件が”３０秒の経過ののちリソースを開放する”と設定されていれば、ＶＣＳサーバ３０は、ソフトウェアタイマ４０ｆがイベントの発生から３０秒をカウントしてから余剰分リソースを開放する。【選択図】      図１
2009016907.tif 000002
【特許請求の範囲】
【請求項１】
通信網に接続される複数のクライアント端末と、これらの複数のクライアント端末間で前記通信網を介して実施される会議を支援する会議ユニットとを具備する会議システムにおいて、
前記会議を支援するために消費される前記会議ユニットのリソースを、前記会議を個別に開催するグループごとに、当該グループに属するクライアント端末の状態の変化を示すイベントの発生に応じて動的に割り当てるリソース制御部と、
会議の開催中に前記イベントを生じたグループに割り当てられた前記リソースの少なくとも一部を、予め設定される条件のもとで開放する開放制御部とを具備することを特徴とする会議システム。
【請求項２】
前記イベントは、前記グループ内での前記クライアント端末の数の変化であることを特徴とする請求項１に記載の会議システム。
【請求項３】
前記条件は、前記イベントの発生から規定の時間が経過することであることを特徴とする請求項１に記載の会議システム。
【請求項４】
前記複数のクライアント端末は前記通信網にビジュアルデータを送出するビデオ送受信機能を備え、
前記イベントは、前記クライアント端末の前記ビデオ送受信機能がオンからオフへと変化することであることを特徴とする請求項１に記載の会議システム。
【請求項５】
前記イベントは、前記会議に参加するユーザの切り替えのための、前記クライアント端末の数の一時的な変化であることを特徴とする請求項１に記載の会議システム。
【請求項６】
前記イベントは、前記グループ内でセッションを形成するクライアント端末間の呼状態の変化であることを特徴とする請求項１に記載の会議システム。
【請求項７】
さらに、前記条件を設定するための設定用ユニットを具備することを特徴とする請求項１に記載の会議システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えばＩＰ（Internet Protocol）技術を用いて形成される電話システムの一つのアプリケーションとして実現される会議システムに関する。
【背景技術】
【０００２】
インターネットなどのベストエフォート型通信網を介して音声通話を実現するシステムが知られている。この種のシステムはＩＰ電話システム、あるいはＶｏＩＰ（Voice over IP）と称され、広域電話網だけでなく構内電話網などのローカル通信網にも応用されている。以下、この種のシステムにおける電話端末を、固定電話機およびソフトフォンを含めＩＰ電話機と称する。
【０００３】
この種のシステムを利用して近年、ビジュアルコミュニケーションシステムとも称する会議システムが広く提供され初めている（例えば特許文献１を参照）。特許文献１には、従来から普及している電話交換機（以下、交換機と略称する）による音声通信と、ビジュアルコミュニケーションサーバ（ＶＣＳサーバ）によるビデオ通信とを連動させたシステムが開示される。
【０００４】
ビジュアルコミュニケーションシステムの制御形態は一般的に以下のようである。すなわち、交換機に接続される内線端末間の呼状態が変化すると交換機から呼情報イベント（発側デバイス情報、着側デバイス情報）が送出される。これをＶＣＳサーバが受信し、ＶＣＳサーバは受信したイベントに基づき内線端末間の接続状態を解釈する。この接続状態に応じてＶＣＳサーバは、ビジュアルコミュニケーションの開始／終了を、内線端末と関連づけされるビジュアルクライアントに指示する。
【０００５】
ところで近年、会議の参加者（以下、ビデオメンバと称する）数が多い場合には、ＭＣＵ（Multi-Point Control Unit:多地点制御装置）と称する装置で会議を合成するという技術が検討されており、例えば特願２００６−０８３３１３号（２００６年３月２４日出願）として出願されている。会議を合成するためにＭＣＵを用いると、クライアントとＭＣＵとの間でビデオストリームが確立される。これに関連して、ユーザ要望に応じてビデオメンバを選択できるようにして会議リソースの有効活用を図ったシステムも検討されており、特願２００６−３３０９４３号（２００６年１２月７日出願）として出願されている。
【特許文献１】特開２００６−２７０１６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
会議に参加するクライアント端末のほとんどはビデオ送受信機能を備えており、そのオン／オフ状態が会議リソースの消費量を大きく左右する。既存の技術ではＭＣＵを用いた会議が行われている最中にクライアントがビデオ送受信機能をオフにしても、クライアント自身が会議を抜けるまでＭＣＵの会議リソースが確保され続ける。またビデオカメラが接続されていないクライアントが会議に参加した場合や、ビデオ送受信機能がオフであるクライアントが会議に参加した場合でも、ＭＣＵの会議リソースが使用される。このためＭＣＵの会議リソースを最大限に有効利用できていないという不具合がある。
【０００７】
このほか次のような不具合もある。すなわち会議への参加人数によってはＭＣＵを必要とせず、クライアント間のピア・ツー・ピア通信で足りる場合がある。例えば４人がその境目となり、３者であればピア・ツー・ピア、４者以上でＭＣＵを利用するといった形態がある。この形態では、４者で会議中に他の話者に切り替える際に、転送機能を使うことで一時的に３者の状態になり、ピア・ツー・ピア通信となってＭＣＵのリソースが開放されてしまう。この状態で他の会議にリソースを取られてしまうと、転送の完了したもとの会議ではＭＣＵを利用することができなくなり、４者によるビジュアルコミュニケーションに戻ることができないことになる。
【０００８】
このように既存の技術には、会議リソースの利用に際して更なる改善の余地があり、何らかの技術開発が待たれている。この発明は以上のような事情によりなされたもので、その目的は、会議リソースのさらなる有効活用を図った会議システムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するためにこの発明の一態様によれば、通信網に接続される複数のクライアント端末と、これらの複数のクライアント端末間で前記通信網を介して実施される会議を支援する会議ユニットとを具備する会議システムにおいて、前記会議を支援するために消費される前記会議ユニットのリソースを、前記会議を個別に開催するグループごとに、当該グループに属するクライアント端末の状態の変化を示すイベントの発生に応じて動的に割り当てるリソース制御部と、会議の開催中に前記イベントを生じたグループに割り当てられた前記リソースの少なくとも一部を、予め設定される条件のもとで開放する開放制御部とを具備することを特徴とする会議システムが提供される。
【００１０】
このような手段を講じることにより、例えば話者切り替えによる呼転送イベントが生じたとしても、そのイベントを生じた呼グループに割り当てられた会議リソースが、盲目的に開放されることが無くなる。つまり予め設定された条件に合致した場合（規定時間の経過など）にのみ、リソースが開放されることになる。従ってこの時間内に呼を再設定できれば転送の完了後にもとの会議リソースを継続して利用することができ、上記の不具合を解消することが可能になる。すなわち会議リソースをさらに有効に活用することが可能になる。  
なおリソース制御部、および開放制御部は、専用のサーバ装置の処理機能として設けることができる。
【発明の効果】
【００１１】
この発明によれば、会議リソースのさらなる有効活用を図った会議システムを提供することができる。
【発明を実施するための最良の形態】
【００１２】
図１は、この発明に係る会議システムの一実施の形態を示すシステム図である。図１において、複数のＩＰ電話機１１〜１ｎがＩＰネットワーク１００を介して交換機２０に接続される。ＩＰ電話機１１〜１ｎは専用電話端末、あるいはソフトフォンなどである。このＩＰネットワーク１００にはビジュアルコミュニケーションサーバ（ＶＣＳサーバ）３０、およびＭＣＵ５０も接続される。ＶＣＳサーバ３０は各種データ設定などを行うための、設定用ユニットとしての保守端末ＭＴに接続される場合もある。
【００１３】
ＶＣＳサーバ３０は、ＩＰネットワーク１００を介して、ＭＣＵ５０と、複数のビジュアルクライアント（ＶＣ）６１〜６６とを管理する。ビジュアルクライアント６１〜６６は、会議メンバとなり得る参加者、に相当するオブジェクトであり、例えばＩＰ電話機１１〜１ｎに個別に連動して機能するコンピュータ端末である。よってビジュアルクライアント６１〜６６の数は６に限るものではない。
【００１４】
ビジュアルクライアント６１〜６６は、話者（ユーザ）のビジュアルデータを取得してＩＰネットワーク１００に送出するビデオカメラＶＣを備える。このビデオカメラＶＣにより話者のボイスデータをも併せて取得するようにしても良い。このビデオカメラＶＣ自体の有無、あるいはその機能のオン／オフにより、ビジュアルコミュニケーション会議に要するリソースの量が大きく左右される。
【００１５】
ビジュアルコミュニケーションは、その規模、数などに対してＶＣＳサーバ３０の処理能力が十分であればクライアント端末間のピア・ツー・ピア通信で実現されるが、必ずしもそのような状況ばかりではない。その意味で、ＭＣＵ５０は、ビジュアルコミュニケーションを実施するための支援装置としての役割を担う。また、ＭＣＵ５０それ自体のリソースにも限りがある。
【００１６】
ＭＣＵ５０は合成処理部５０ａを備える。合成処理部５０ａはＩＰネットワーク１００を介して伝送されるビデオデータおよびボイスデータを合成し、複数のメンバによる複数のビジュアルコミュニケーションを実現する。ＭＣＵ５０のリソースが十分に足りている状態では、図１に示すように総てのビジュアルクライアント６１〜６６とＭＣＵ５０との間にセッションが確立され、この会議は会議メンバの全員で構成される。各ビジュアルクライアント６１〜６６には会議のメンバが通知されクライアント端末に参加メンバ名が表示されるとともに、参加メンバ全員のビデオ映像が表示される。
【００１７】
ＶＣＳサーバ３０は、制御部４０およびデータベース部（ＤＢ）７０を備える。制御部４０はその処理機能として呼制御部４０ａ、クライアント特定部４０ｂ、会議制御部４０ｃ、リソース制御部４０ｄ、開放制御部４０ｅ、およびソフトウェアタイマ４０ｆを備える。  
このうち呼制御部４０ａは、各種の呼制御に係わる呼情報イベントを交換機２０から取得し、交換機２０と共同でＩＰ電話機１１〜１ｎ、ビジュアルクライアント６１〜６６に係わる呼接続、セッション制御などの処理を実行する。クライアント特定部４０ｂは、会議に参加するメンバ（クライアント）を与えられた設定条件のもとで特定する。特定されたメンバ情報は制御部４０によるセッション制御などのために用いられる。
【００１８】
会議制御部４０ｃは、会議を支援するためのＭＣＵ５０のリソースの残量を検出し、データベース部７０のＭＣＵ会議リソース情報７０ａに記録する。また会議制御部４０ｃは、リソース残量に応じて、会議に参加するメンバを構成する。このメンバはクライアントからの要求に応じた形態で選択され、その旨はビジュアルクライアント６１〜６６に通知される。会議の開始時には、ＭＣＵ５０は、メンバ構成を反映するセッション制御情報を会議制御部４０ｃから受け、選択されたメンバ間にのみセッションを形成する。
【００１９】
リソース制御部４０ｄは、会議を支援するために消費されるＭＣＵ５０の会議リソースを、会議を個別に開催する呼グループごとに割り当てる。呼グループの規模、会議の規模などは会議の開催中にも変化するのが普通であり、これに応じてリソース制御部４０ｄは、呼グループごとのリソースの割り当て量を動的に変化させる。リソースの割り当て量を変化させるための要因のひとつには、呼グループに属するビジュアルクライアントの状態が変化することが挙げられ、これはイベントの発生としてシステムに認識される。
【００２０】
開放制御部４０ｅは、システム内にリソース割り当てに関わるイベントが生じ、余剰となったリソースを生じたことを検知すると、この余剰リソースを、予め設定される条件のもとで開放する。つまり開放制御部４０ｅは、会議の開催中に参加クライアント数の減少（または増加）、話者の切り替え、ビデオカメラＶＣのオン／オフなどといったイベント、を生じたグループに割り当てられたリソースの少なくとも一部を、予め設定される条件のもとで開放する。  
ソフトウェアタイマ４０ｆは、リソース開放に係わる規定時間をカウントするために用いられる。
【００２１】
データベース部７０は、その記憶領域にＭＣＵ会議リソース情報７０ａと、設定条件情報７０ｂと、タイマ設定値情報７０ｃとを記憶する。このうちＭＣＵ会議リソース情報７０ａは、ビジュアルコミュニケーションを支援するために消費されるＭＣＵ５０リソースをデータベース化した情報である。このデータベースは、例えば個別の呼グループごとに、現時点でどの程度のリソースが割り当てられているかを管理するために用いられる。会議構成メンバの変化やシステムのバージョンアップなどに伴い、ＭＣＵ会議リソース情報７０ａは変化する。
【００２２】
図２は、設定条件情報７０ｂの一例を示す図である。設定条件情報７０ｂは、開放制御部４０ｅによりＭＣＵ５０のリソースを開放する際の条件を、定めたテーブルである。図２には、”タイマ期間の経過後にリソースを開放する”という条件にフラグがセットされており、開放制御部４０ｅはこの条件に沿って余剰リソースを開放する。この条件は呼グループごと、あるいはビジュアルクライアントごとにさらに細分化して設定することもできる。
【００２３】
図３は、タイマ設定値情報７０ｃの一例を示す図である。これは図２の”タイマ期間の経過後にリソースを開放する”という条件に関連するもので、この条件が設定されたときに用いられる。図３に示すように、各ビジュアルクライアント端末（ＰＣ１〜ＰＣｎ）ごとに、ソフトウェアタイマ４０ｆでカウントされるタイマ設定値が記録される。このテーブルを用いれば、ビジュアルクライアント端末の状態が変化して余剰リソースが生じた時点から、例えば３０秒後にそのリソースが開放される。この時間が経過する前にさらに状態変化イベントを生じて余剰リソースが無くなれば、もちろん、このリソースは開放されないままになる。
【００２４】
図４は、タイマ設定値情報７０ｃの他の例を示す図である。図４は、それぞれ会議を個別に形成する呼グループごとに、ソフトウェアタイマ４０ｆでカウントされるタイマ設定値を記録したものである。このテーブルを用いれば、呼グループごとに余剰リソースの変化を管理し、変化が生じた時点から例えば３０秒後に余剰リソースを開放するといった制御を実現できる。呼グループにおける状態の変化は、例えば話者切り替えのために呼転送イベントが生じて話者数が一時的に変化するなどといったケースで生じる。
【００２５】
図５は、ＭＣＵ５０のリソースを使用するか否か、そのものを設定するために用いられる管理テーブルの一例を示す図である。このテーブルは例えば呼グループごとに、グループ内のビジュアルクライアントのビデオカメラ機能がオフである状態で、ＭＣＵ５０のリソースを使用するか否かを決めるために用いられる。図５ではリソースを使用するという設定になっているので、ビデオカメラ機能がオフ（リソース消費の少ない状態）であっても、ビデオ会議開始時にＭＣＵの会議リソースがデフォルトで使用される。このほか会議への参加クライアント数によりＭＣＵの会議リソースの使用の如何を決めるという形態もある。例えば参加クライアント数が３以下の会議では会議リソースを使用せず、４以上になって初めて会議リソースを使用するという形態である。  
図２〜図５に示す各テーブルの設定データは、保守端末ＭＴを用いた管理者の設定操作により予め容易される。システムの稼働中においてもこの設定を変更することが可能である。なお図３、図４において、タイマ設定値が０秒であれば余剰リソースは直ちに開放され、図２の”リソースの即開放”にフラグがセットされたのと同じ状態になる。またタイマ設定値を無限大（∞）にすれば、少なくとも会議の終了（解散）まで余剰リソースは開放されないことになる。次に、リソースの開放の手順につき図６〜図９を参照して説明する。リソースの開放のきっかけとなるイベントは、ビデオ送受信機能のオン／オフ、あるいは話者数の減少などがある。
【００２６】
図６は、ＭＣＵ５０の会議リソースを用いたビデオ会議の実施中での処理手順の一例を示すフローチャートである。このフローチャートでは、処理の開始時にビジュアルクライアント端末のビデオ送受信機能がオンである状態を想定する。
【００２７】
図６において、いずれかのクライアント端末においてビデオ送受信機能がオフされると、（ステップＳ９０１でＹｅｓ）、このイベントがクライアント情報通知としてＶＣＳサーバ３０に通知される。これに応じてＶＣＳサーバ３０は図２のテーブルの設定を確認する（ステップＳ９０２）。
【００２８】
ステップＳ９０２にて設定が「即リソース解放」であれば、処理手順はステップＳ９０９に移って当該クライアントのリソースが即開放される。設定が「リソースを解放しない」であれば、ＶＣＳサーバ３０はＭＣＵ会議リソースを解放することなくビデオ会議を継続する（ステップＳ９０８）。
【００２９】
テーブルの設定が「タイマ期間の経過後にリソースを解放」であれば、ＶＣＳサーバ３０はタイマ設定値を図３または図４のテーブルから読み出す。そして、ＶＣＳサーバ３０はビデオ送受信機能をオフされたクライアント端末に対応するタイマをスタートする（ステップＳ９０３）。こののちタイマのタイムアウトが継続的にチェックされる（ステップＳ９０４）。
【００３０】
ソフトウェアタイマ４０ｆがタイムアウトしていない状態では、ＶＣＳサーバ３０はカウント処理（タイマ動作）を継続し（ステップＳ９０５）、併せてクライアントがビデオ送受信機能を再度オンにしたか否かをチェックする（ステップＳ９０６）。ビデオ送受信機能がオンされなければ処理手順はステップＳ９０４に戻る。ビデオ送受信機能がオンされれば（ステップＳ９０６でＹｅｓ）、ＶＣＳサーバ３０はタイマ動作を停止し、ＭＣＵ会議リソースを解放することなくビデオ会議を継続する（ステップＳ９０７）。  
ステップＳ９０４でタイマがタイムアウトすれば、ＶＣＳサーバ３０は、ビデオ送受信機能をオフしたクライアント端末に割り当てられていたＭＣＵ会議リソースを解放し（ステップＳ９０９）、会議話者数の条件に応じた会議制御を行う（ステップＳ９１０）。
【００３１】
図７は、ＭＣＵ５０の会議リソースを用いないビデオ会議の実施中での処理手順の一例を示すフローチャートである。このフローチャートでは、処理の開始時にビジュアルクライアント端末のビデオ送受信機能がオフである状態を想定する。  
図７において、いずれかのクライアント端末においてビデオ送受信機能がオンされると、（ステップＳ１００１でＹｅｓ）、このイベントがクライアント情報通知としてＶＣＳサーバ３０に通知される。これに応じてＶＣＳサーバ３０は、会議話者数がＭＣＵ５０を用いる会議の条件に合致するか否かをチェックする（ステップＳ１００２）。ここでは、つまり、会議話者数が例えば３以下であるか（ＭＣＵ５０を使用しない）、４以上であるか（ＭＣＵ５０を使用する）がチェックされる。
【００３２】
会議話者数が、ＭＣＵ５０を用いる会議の条件に合致しなければ、ＶＣＳサーバ３０はＭＣＵ５０を用いない会議制御を継続する（ステップＳ１００５）。逆に、会議話者数がＭＣＵ５０を用いる会議の条件に合致すれば、ＶＣＳサーバ３０は、ＭＣＵ会議リソースに余剰（空き）があるか否かをチェックする（ステップＳ１００３）。ＭＣＵ会議リソースに空きが無ければ処理手順はステップＳ１００５に移る。ＭＣＵ会議リソースに空きがあれば、ＶＣＳサーバ３０はセッションを再設定して、ＭＣＵ５０を用いる形態で会議を制御する（ステップＳ１００４）。
【００３３】
図８は、クライアントがビデオ会議を開始する際の処理手順の一例を示すフローチャートである。図８において、クライアントがビデオ会議を開始すると（ステップＳ１１０１）、ＶＣＳサーバ３０はクライアントにビデオカメラＶＣが接続されているか否かをチェックする（ステップＳ１１０２）。ビデオカメラＶＣが接続されていなければ、ＶＣＳサーバ３０は、そのクライアントをＭＣＵ会議リソースの使用対象としてカウントせずに会議制御を行う（ステップＳ１１０６）。
【００３４】
クライアントにビデオカメラＶＣが接続されていれば、ＶＣＳサーバ３０はそのビデオ送受信機能がオンかオフかをチェックする（ステップＳ１１０３）。ビデオ送受信機能がオフであれば、ＶＣＳサーバ３０は、”ビデオ送受信オフでビデオ会議を開始する”という条件下で図５のテーブルの設定を確認する（ステップＳ１１０５）。設定が「リソースを使用する」であれば、処理手順はステップＳ１１０４に移行する。設定が「リソースを使用しない」であれば、処理手順はステップＳ１１０６に移行する。
【００３５】
一方、ステップＳ１１０３でビデオ送受信機能がオンであれば、ＶＣＳサーバ３０は、そのクライアントをＭＣＵ会議リソースの使用対象としてカウントし、会議制御を行う（ステップＳ１１０４）。
【００３６】
図９は、ＭＣＵ５０の会議リソースを用いた多者会議の開催中に、話者数が減少する際の処理手順の一例を示すフローチャートである。このフローチャートでは特に、話者を切り替えるために、会議主催者の呼の転送操作によって一時的に話者数が減少する際の手順が示される。
【００３７】
会議主催者が自己のＩＰ電話機（またはクライアント端末）の会議転送キーを押下すると、転送処理が起動して呼が一時的に切断されて話者数が減少する（ステップＳ１２０１でＹｅｓ）。そうすると呼状態が変化したことを示す呼情報イベントが交換機２０からＶＣＳサーバ３０に通知される。これを受けてＶＣＳサーバ３０は、ＭＣＵ会議リソース情報７０ａをチェックし、その時点で呼グループが存在するか否かを判定する（ステップＳ１２０２）。 
呼グループが存在しなければ、現時点で呼グループに割り当てられているＭＣＵ会議リソースが全て解放される（ステップＳ１２０３）。呼グループが存在すれば、ＶＣＳサーバ３０は図２のテーブルを確認する（ステップＳ１２０４）。設定が「解放しない」であれば、ＶＣＳサーバ３０は話者数減少分のＭＣＵ会議リソースを解放することなく、ビデオ会議を継続する（ステップＳ１２０５）。
【００３８】
設定が「タイマ期間の経過後にリソースを解放」であれば、ＶＣＳサーバ３０はタイマ設定値を図３または図４のテーブルから読み出す。そして、ＶＣＳサーバ３０は話者数の減少した呼グループに対応するタイマをスタートする（ステップＳ１２０６）。こののちタイマのタイムアウトが継続的にチェックされる（ステップＳ１２０７）。
【００３９】
ソフトウェアタイマ４０ｆがタイムアウトしていない状態では、ＶＣＳサーバ３０はカウント処理（タイマ動作）を続け、話者数減少分のＭＣＵ会議リソースが解放されない状態が継続する（ステップＳ１２０８）。ステップＳ１２０７でタイマがタイムアウトすれば、ＶＣＳサーバ３０は、話者数減少分のＭＣＵ会議リソースを解放し（ステップＳ１２０９）、会議話者数の条件に応じた会議制御を行う（ステップＳ１２１０）。一方、ステップＳ１２０４で確認された設定が「即リソース解放」であれば、処理手順はそのままステップＳ１２０９へと進む。
【００４０】
以上説明したようにこの実施形態では、ビデオ送受信機能のオン／オフ、あるいは話者の減少といったイベントが検出された場合でも、空きとなったＭＣＵ５０のリソースを盲目的に解放することをしない。すなわち、ＶＣＳサーバ３０は余剰分のリソースが生じた際の処理の設定を設定条件情報７０ｂにより確認し、その設定に応じた条件化での処理を行う。例えば、処理条件が”３０秒の経過ののちリソースを開放する”と設定されていれば、ＶＣＳサーバ３０は、ソフトウェアタイマ４０ｆがイベントの発生から３０秒をカウントしてから余剰分リソースを開放する。
【００４１】
ＭＣＵ５０の会議リソースを使用した４者会議中、会議主催者が他の話者に転送操作を行い別の４者会議へと移行したい場合、会議主催者は、まず会議を保留して呼を転送する操作を行い、これにより一時的にビデオ会議は会議主催者を除く３者会議となる。このケースでは、ＭＣＵ５０の会議リソースを直ちに開放すると、３者それぞれのピア・ツー・ピア通信環境が形成されてしまう。
【００４２】
そして転送先が応答することを待って４者会議状態が再設定されるが、その間に他のユーザによりＭＣＵ５０の会議リソースが取得されてしまうと、再び４者によるビジュアルコミュニケーションを行うための会議リソースに空きが無くなることになる。つまり会議主催者が他の話者に呼を転送する前はＭＣＵ５０の会議リソースを用いる４者会議を実現できていたにも関わらず、転送操作終了時にはＭＣＵ５０の会議リソースを用いる４者会議を実施できない場合があった。
【００４３】
これに対しこの実施形態では、会議リソースの制御方式を選択することが可能であるので、ＭＣＵ５０の会議リソースを使用した多者会議中、呼状態の変化により話者数が減少しても上記のような状況は起こらない。また、呼の実施形態では、ＭＣＵ５０の会議リソースを用いた多者会議中にクライアントがビデオ送受信機能をオフとした場合でも、ＭＣＵ５０の会議リソース制御方式を選択することが可能である。いずれの場合でも、特にタイマ期間のカウントを待ってリソースを開放するという設定条件化では、タイマのカウント値を任意に設定することもできる。
【００４４】
もちろん、設定条件によって、会議中の呼グループにＭＣＵ５０の会議リソースは、一旦割り当てられた後は、その呼グループが存在する間は解放しないようにすることもできる。また、ＭＣＵ５０の会議リソースを用いないビデオ会議の開催中にいずれかのクライアントがビデオ送受信機能をオンにすると、ＭＣＵ５０の会議リソースを使用するための会議話者数の条件に合致し、かつＭＣＵ５０の会議リソースに空きがあれば、ＭＣＵ５０の会議リソースを使用するようにすることもできる。
【００４５】
また、ビデオ会議開始時にクライアント端末にビデオカメラＶＣが接続されていない場合には、ＭＣＵ５０の会議リソースを使用しないようにすることも可能である。さらに、クライアントのビデオ送受信機能がオフの状態でビデオ会議を開始する際、ＭＣＵ５０の会議リソースを使用するための会議話者数の条件に合致し、かつＭＣＵ５０の会議リソースに空きがある場合に、ＭＣＵ５０の会議リソースを如何に割り当てるかを設定により選択することも可能である。
【００４６】
このように、ＭＣＵ５０の会議リソースを使用するか否か、また、余剰となったリソースをどのようにして開放するかといった条件を、この実施形態によれば、きめ細かく設定することが可能になる。これらのことから、会議リソースのさらなる有効活用を図った会議システムを提供することが可能になる。
【００４７】
なお、この発明はこの実施の形態に限定されるものではない。例えばこの実施形態ではリソース開放の条件、タイマのカウント値などを保守端末ＭＴから設定できるようにしているが、ＩＰ電話機１１〜１ｎ、あるいはビジュアルクライアント６１〜６６からこの設定を実施できるようにしても良い。また各種設定を、クライアントごと、あるいは呼グループごとに個別にセットできるようにしても良い。
【００４８】
また図９のフローチャートでは、話者数が減少する要因として多者会議中の転送操作を例とした。このほか、会議に参加中の話者が会議から単純に抜けるというケースも、会議話者数が減少する要因として挙げられるこのように、本発明の主旨を逸脱しない範囲の状況下において、本発明によるＭＣＵ５０の会議リソース制御が可能である。
【００４９】
さらに、この発明は実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【００５０】
【図１】この発明に係る会議システムの一実施の形態を示すシステム図。
【図２】図１の設定条件情報７０ｂの一例を示す図。
【図３】図１のタイマ設定値情報７０ｃの一例を示す図。
【図４】図１のタイマ設定値情報７０ｃの他の例を示す図。
【図５】ＭＣＵ５０のリソースを使用するか否かを設定するために用いられる管理テーブルの一例を示す図。
【図６】ＭＣＵ５０の会議リソースを用いたビデオ会議の実施中での処理手順の一例を示すフローチャート。
【図７】ＭＣＵ５０の会議リソースを用いないビデオ会議の実施中での処理手順の一例を示すフローチャート。
【図８】クライアントがビデオ会議を開始する際の処理手順の一例を示すフローチャート。
【図９】ＭＣＵ５０の会議リソースを用いた多者会議の開催中に、話者数が減少する際の処理手順の一例を示すフローチャート。
【符号の説明】
【００５１】
１１〜１ｎ…ＩＰ電話機、２０…交換機、３０…ＶＣＳサーバ３０、４０…制御部、４０ａ…呼制御部、４０ｂ…クライアント特定部、４０ｃ…会議制御部、４０ｄ…リソース制御部、４０ｅ…開放制御部、４０ｆ…ソフトウェアタイマ、５０…ＭＣＵ、５０ａ…合成処理部、６１〜６６…ビジュアルクライアント（ＶＣ）、７０…データベース部（ＤＢ）、７０ａ…ＭＣＵ会議リソース情報、７０ｂ…設定条件情報、７０ｃ…タイマ設定値情報、１００…ＩＰネットワーク、ＭＴ…保守端末、ＶＣ…ビデオカメラ
【図１】
2009016907.tif 000003
【図２】
2009016907.tif 000004
【図３】
2009016907.tif 000005
【図４】
2009016907.tif 000006
【図５】
2009016907.tif 000007
【図６】
2009016907.tif 000008
【図７】
2009016907.tif 000009
【図８】
2009016907.tif 000010
【図９】
2009016907.tif 000011