JPH0950380A - 通信システム - Google Patents

Abstract

(57)【要約】 【課題】通信に必要なリソースが確保できない時、効率
的にリソースを確保できるようにすること。 【解決手段】通信システムにおいて、あるサービスを提
供するサービス制御手段３が必要とするリソース６〜９
が他のサービス制御手段により確保されてしまっていて
利用できない場合に、予約をしてそのリソースが解放さ
れると、当該リソースの使用状況を管理しているリソー
ス管理手段４，５または当該リソースを確保している前
記サービス制御手段が、当該リソースの解放時に当該リ
ソースを要求しているサービス制御手段に解放を通知す
る構成とした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、端末またはネット
ワーク上の資源を使用して各種のサービスを提供する通
信システムに関する。

【０００２】

【従来の技術】コンピュータシステムの技術と通信技
術、そして、マルチメディア技術の発展に伴い、コンピ
ュータ通信の分野でも単なるデータ通信にとどまらず、
音声、画像（動画や静止画）などの様々なメディアを利
用した通信をすることができるようになった。但し、自
己が利用しようとする各メディアを、相手側でも利用可
能である必要があるが、そこで問題になるのは、通信す
るに際して、通信の要求元である自己側が利用しようと
する各メディアの利用を可能にする資源（ハードウエア
資源やそれを稼動させるためのソフトウェア資源など）
を、相手側も有していて、しかもそれが利用可能な状態
になっているか否かが、要求元からは把握できないとい
うことである。

【０００３】従来の通信システムにおけるサービス起動
要求からサービス起動までの処理の流れを図８に示す。

【０００４】コンピュータを利用する通信システムにお
いては、通信網の資源または通信網に接続された機器の
資源を制御してサービスを実現するサービス制御手段
と、網リソースを管理する網リソース管理手段を有す
る。

【０００５】あるサービスを対象としたサービス起動要
求があると（ステップＳ８‐１）、この通信システム内
のサービス制御手段は、そのサービス実現の際に必要な
資源を獲得する必要があるので、網リソース管理手段に
その対象サービスに必要な網リソースの獲得要求を出す
（ステップＳ８‐２）。そして、網リソース管理手段が
その対象サービスに必要な網リソースの獲得ができた
か、否かを調べ（ステップＳ８‐３）、獲得できていれ
ばサービスの起動を行ない（ステップＳ８‐５）、その
サービスを可能にする。しかし、必要な網リソースの獲
得ができていない場合、不可能であればサービス起動不
可を利用者に通知する（ステップＳ８‐６）。

【０００６】つまり、従来の通信システムにおいては、
サービス要求元において、そのサービスを実現するに必
要な網資源についての空塞を知ることしかできないため
に、サービス要求元においては取り敢えず、目的のサー
ビス起動要求を行なってみる。

【０００７】サービス起動要求を行なった結果、必要な
網資源も獲得できない場合には、サービスの起動ができ
ないので、その旨をユーザに通知するなどして知らせ
（ステップＳ８‐６）、これによりユーザは今は目的の
サービスの起動ができないことを知り、一旦、諦める。
そして、ユーザが必要に応じて頃合をみて再度サービス
の起動要求を出すといった具合に、行き当たりばったり
の起動制御を行なうものであった。

【０００８】

【発明が解決しようとする課題】このように、従来の通
信システムにおいてはサービス起動要求時にサービス制
御手段が必要な資源を獲得できない場合には、例えばユ
ーザが必要に応じて時間をおいて再度サービスの起動要
求を出すということが行われていたが、再び起動要求を
出した際に必要な資源を獲得できるとは限らないため、
資源の獲得に成功するまで何度も起動要求を出さねばな
らないこともあるという問題点があった。

【０００９】これは、相手が直接的に見えないだけに、
使い勝手を悪くし、ユーザに対するサービス低下を招く
大きな要因となっている。

【００１０】また従来の通信システムにおいては、サー
ビス起動要求時に、サービス制御手段が必要な資源を獲
得できないという場合に、その獲得できない要因として
その資源を実際にユーザが使用中の状態である場合だけ
でなく、ユーザがその資源の使用を実質的には終えてい
るものの、サービス制御手段が解放処理を行っていない
ために獲得できないという場合も含まれている。これは
事実上、その資源を殺しているに等しい。

【００１１】そのため、たとえ、あるサービス制御手段
が資源の獲得を要求した時点で実際にはユーザがその資
源を使用していない場合でも、その資源を解放していな
いばかりに、そのサービス制御手段はサービス内容を縮
小変更して獲得可能な資源のみによりサービスを実現す
るようにするか、サービスの実現を中止するかしなけれ
ばならず、サービス低下に繋がるという問題点がある。

【００１２】例えばこのようなサービス制御手段が計算
機上のアプリケーションプログラムとして実現されてい
る場合はユーザがそのアプリケーションプログラムの利
用を実質的には終えているがアプリケーションプログラ
ムを終了させていないために、資源が解放されないとい
うことは実際にはよく生じることである。

【００１３】そこで、この発明の目的とするところは、
上述のような、実質的に使用を終え、解放され得る資源
が解放されないことによって当該資源を必要とするサー
ビスの実現を阻害するという問題を解決することができ
る通信システムを提供することにある。

【００１４】

【課題を解決するための手段】上記課題を解決するため
に本発明はつぎのように構成する。

【００１５】すなわち、第１には、各種資源を備えた複
数の端末を通信網に接続し、この通信網の資源または通
信網に接続された端末の各種資源を使用してサービスを
提供する複数のサービス制御手段を有し、サービス制御
手段によるサービス提供にあたっては前記各種資源のう
ち、そのサービス提供に必要な資源を確保して実施する
通信システムにおいて、実施させようとする所望のサー
ビスを提供するサービス制御手段が必要とする資源が、
他のサービス制御手段により確保されて利用できない場
合に、その資源の予約をする手段と、資源の使用状態を
管理する管理手段と、この管理手段の情報をもとに、前
記予約した資源が解放されると、前記実施させようとす
る所望のサービスを提供するサービス制御手段にその解
放を通知する手段とを具備する。

【００１６】この構成によれば、実施させようとする所
望のサービスを提供するサービス制御手段が必要とする
資源が、他のサービス制御手段により確保されて利用で
きない場合に、その資源の予約をし、資源の使用状態を
管理する管理手段の情報をもとに、前記予約した資源が
解放されると、前記実施させようとする所望のサービス
を提供するサービス制御手段にその解放を通知して使用
可能になったことを知らせる。

【００１７】従って、無駄な操作を何度も行なわずに、
条件が整ったところで、所望のサービスを提供するサー
ビス制御手段を起動してそのサービスを利用することが
できるようになる。

【００１８】また、第２には、通信網の資源または通信
網に接続された機器の資源を制御してサービスを実現す
るサービス制御手段を有する通信システム内に通信網の
資源または通信網に接続された機器の資源の使用状況を
管理する資源管理手段と、サービス制御手段間またはサ
ービス制御手段と資源管理手段との間に通信手段とを設
け、サービス制御手段には、要求した資源が割り当てら
れないという通知を受けた場合に、当該資源を占有して
いるサービス制御手段の中のひとつまたは複数のサービ
ス制御手段を、資源の割り当てを要求する要求先として
選択するための資源要求先サービス制御手段決定手段を
設ける構成とする。

【００１９】このような構成において、サービス制御手
段が、前記通信手段を用いて他のサービス制御手段また
は資源管理手段に対してサービスに必要な資源を表す情
報を送信し、該情報を受信したサービス制御手段または
資源管理手段は、要求された資源を前記要求元サービス
制御手段に割り当てるかどうかを判断し、割り当てると
判断した場合には要求された資源を要求元サービス制御
手段に割り当ててその旨を要求元サービス制御手段に通
知し、割り当てないと判断した場合には、要求された資
源を割り当てない旨を要求元サービス制御手段に通知
し、以降当該要求資源を割り当てると判断したときに、
該資源を要求している前記サービス制御手段に該資源の
解放を通知する。

【００２０】また、サービス制御手段は、要求先サービ
ス制御手段から要求した資源が割り当てられないという
通知を受けた場合には、前記資源要求先サービス制御手
段決定手段によりサービス制御手段を選択し、選択され
たサービス制御手段に対して、前記通信手段を用いて資
源を解放する要求を送信する。そして、当該選択された
サービス制御手段にこの解放要求に基づいて資源の解放
をさせる機能を持たせることにより、その資源を解放さ
せて該資源を要求している前記サービス制御手段に該資
源を利用してのサービスを可能にさせる。

【００２１】また第３には、各種資源を備えた複数の端
末を通信網に接続し、この通信網の資源または通信網に
接続された端末の各種資源を使用してサービスを提供す
る複数のサービス制御手段を有し、サービス制御手段に
よるサービス提供にあたっては前記各種資源のうち、そ
のサービス提供に必要な資源を確保して実施する通信シ
ステムにおいて、実施させようとする所望のサービスを
提供するサービス制御手段が必要とする資源を通知する
と共に優先度を通知する手段と、前記実施させようとす
る所望のサービスを提供するサービス制御手段が必要と
する資源を既に確保している他のサービス制御手段があ
るとき、通知されている互いの前記優先度を比較してそ
の資源を既に確保している前記他のサービス制御手段の
優先度が低い場合に、その資源の解放を実施させる手段
とを具備する。

【００２２】実施させようとする所望のサービスを提供
するサービス制御手段が必要とする資源を、優先度と共
に通知して、当該実施させようとする所望のサービスを
提供するサービス制御手段が必要とする資源を既に確保
している他のサービス制御手段があるとき、通知されて
いる互いの前記優先度を比較し、その資源を既に確保し
ている前記他のサービス制御手段の優先度が低い場合
に、その資源の解放させることで、優先度の高いサービ
スの方に資源を利用させることができ、緊急度の高いサ
ービスを確実に利用できるようになる。

【００２３】第４には、通信網の資源または通信網に接
続された機器の資源を制御してサービスを実現するサー
ビス制御手段を有する通信システムにおいて、資源の使
用状態を管理する管理手段と、利用しようとする前記サ
ービス制御手段においてそのサービス制御に必要な資源
を表す情報を要求資源情報として通信コネクション設定
の際のシグナリング・メッセージ内に設定して送信する
手段と、シグナリング・メッセージ内の前記要求資源情
報から要求のある資源を知り、前記利用しようとするサ
ービス制御手段に、この資源を割り当てることの可否を
判断する手段と、前記判断結果が可の場合には前記設定
中の通信コネクションの接続先を前記要求資源として該
通信コネクションの設定手順を引続き実行し、否の場合
には、前記通信コネクションの設定を中止すべく制御す
る手段とを具備する。

【００２４】この場合、利用しようとする前記サービス
制御手段側においてそのサービス制御に必要な資源を表
す情報を要求資源情報として通信コネクション設定の際
のシグナリング・メッセージ内に設定して送信すると、
判断手段はシグナリング・メッセージ内の前記要求資源
情報から要求のある資源を知り、前記利用しようとする
サービス制御手段に、この資源を割り当てることの可否
を判断する。そして、制御段は、前記判断結果が可の場
合には前記設定中の通信コネクションの接続先を前記要
求資源として該通信コネクションの設定手順を引続き実
行し、否の場合には、前記通信コネクションの設定を中
止すべく制御する。

【００２５】従って、あるサービス制御手段を利用しよ
うとする時、そのサービス制御手段が必要とする資源を
知ると共に、資源の使用状態を管理する管理手段の情報
から資源を割り当てることの可否を判断できるので、そ
の判断結果から資源の割り当てを行う結果、実質的に使
用を終え、解放され得る資源が解放されないことによっ
て当該資源を必要とするサービスが実施できないという
ような事態を回避できるようになる。

【００２６】

【発明の実施の形態】本発明は、通信網の資源または通
信網に接続された機器の資源を制御してサービスを実現
する複数のサービス制御手段を有する通信システムにお
いて、前記通信網の資源または前記通信網に接続された
機器の資源の使用状況を管理する資源管理手段と、前記
サービス制御手段間またはサービス制御手段と前記資源
管理手段との間に通信手段とを設け、起動しようとする
サービス制御手段が、前記通信手段を用いて他のサービ
ス制御手段または資源管理手段に対してサービスに必要
な資源を表す情報を送信し、該情報を受信した資源管理
手段は、サービスに必要な資源が既に他のサービス制御
手段に割り当てられているときは、その資源の予約を行
ない、その資源が解放されたときに前記起動しようとす
るサービス制御手段に通知して再起動させ、その資源を
利用してのサービスを実施を可能にする。

【００２７】また、通信網の資源または通信網に接続さ
れた機器の資源を制御してサービスを実現する複数のサ
ービス制御手段を有する通信システムにおいて、前記通
信網の資源または前記通信網に接続された機器の資源の
使用状況を管理する資源管理手段と、前記サービス制御
手段間またはサービス制御手段と前記資源管理手段との
間に通信手段とを設け、サービス制御手段が、前記通信
手段を用いて他のサービス制御手段または資源管理手段
に対してサービスに必要な資源を表す情報を送信し、該
情報を受信したサービス制御手段または資源管理手段
は、要求された資源を前記要求元サービス制御手段に割
り当てるかどうかを判断し、割り当てると判断した場合
には要求された資源を要求元サービス制御手段に割り当
ててその旨を要求元サービス制御手段に通知し、割り当
てないと判断した場合には、要求された資源を割り当て
ない旨を要求元サービス制御手段に通知し、以降当該要
求資源を割り当てると判断したときに、該資源を要求し
ている前記サービス制御手段に該資源の割り当てを通知
する構成とする。

【００２８】また、サービス制御手段に、要求した資源
が割り当てられないという通知を受けた場合に、当該資
源を占有しているサービス制御手段の中のひとつまたは
複数のサービス制御手段を、資源の割り当てを要求する
要求先として選択するための資源要求先サービス制御手
段決定手段を設け、サービス制御手段は、要求先サービ
ス制御手段から要求した資源が割り当てられないという
通知を受けた場合には、前記資源要求先サービス制御手
段決定手段によりサービス制御手段を選択し、選択され
たサービス制御手段に対して、前記通信手段を用いて資
源を要求する情報を送信するようにする。

【００２９】以下、より具体的に本発明を説明する。以
下の例では、サービス要求元から資源の状態を調べて、
必要により資源を解放させ、利用できるようにして目的
のサービスを円滑に利用できるようにした例を説明す
る。

【００３０】（第１の具体例）図１に本発明の第１の具
体例を示す。ここでは図に示すように、計算機（パーソ
ナルコンピュータやワークステーションなど）１‐１〜
１‐ｎが通信路２を介して相互に接続されており、前記
計算機１‐１〜１‐ｎにはそれぞれ、音声の入出力装置
としてマイクロフォン８とスピーカ９が接続され、ま
た、画像の入出力装置としてカメラ（テレビカメラもし
くは電子スチルカメラなどの撮像装置）６とディスプレ
イ装置７が接続されている。

【００３１】これらの数台の計算機および各種入出力装
置を用いて会議サービスを実現する場合の例について説
明する。

【００３２】前記計算機のうちの一つには、サービス制
御手段３として会議サービスを実現するプログラム（以
降会議アプリケーションと呼ぶ）が実装されており、さ
らに、前記計算機１‐１〜１‐ｎのそれぞれには各種入
出力装置やディスク装置などの資源を管理する端末資源
管理手段４としてのプログラム（以降端末リソースマネ
ージャと呼ぶ）があってこれらが稼働し、前記計算機１
‐１〜１‐ｎのうちのいずれかには網資源管理手段５と
して前記各計算機を結ぶ通信路の帯域の使用状況を管理
するプログラム（以下、これを網リソースマネージャと
呼ぶ）があってこれが稼働している。

【００３３】［リソースマネージャの構成］図２にこれ
らリソースマネージャの構成を示す。リソースマネージ
ャは、リソースの使用状況を管理する資源使用状況管理
手段１３と、どのサービス制御手段からどのようなリソ
ースを要求されたかを記憶する資源要求情報保持手段１
０と、要求されたリソースの空塞を判断するための要求
資源空塞判断手段１１とを持つ。リソースには、端末リ
ソースにおける音声／画像の各入出力装置のようにその
空塞が明確なものもあれば、網リソースにおける帯域の
ように使用量が変動し、空塞（空き／塞がり）が明確で
ないものもある。

【００３４】このように空塞が明確でないリソースの空
塞判断手段（要求資源空塞判断手段１１）の実現方法と
しては、例えば、過去一定期間の空きリソース量の最小
値が、要求リソース量よりあるマージン以上大きい場合
に、“空き”と判断するという方法が考えられる。

【００３５】なお、これらの各種プログラム以外に、前
記計算機上では会議サーバ以外のプログラム（以下、こ
れを他アプリケーションと呼ぶ）も同時に稼働してい
る。これら会議アプリケーションとリソースマネージ
ャ、他アプリケーションは通信路を介して相互に情報を
やりとりすることができる。

【００３６】［会議サービス実現時のリソース確保］こ
のような構成において、会議サービス実現時のリソース
確保の様子を以下に説明する。図３に会議アプリケーシ
ョンがリソースを獲得してサービスを開始するまでの処
理の流れを示す。

【００３７】図３に沿って説明する。通信路２に計算機
１‐１〜１‐ｎが繋がっていてコンピュ−タネットワー
クを構成しており、互いの計算機１‐１〜１‐ｎは相互
に通信可能なシステムとなっている。

【００３８】まず、計算機１‐１〜１‐ｎのうち、いず
れかの計算機（起動要求元計算機）においてサービス制
御手段としての会議アプリケーションが起動される（図
中ステップＳ３‐１）。

【００３９】起動要求元計算機内の起動された会議アプ
リケーションは、通信路２を介して接続された会議に参
加する参加者の計算機（接続対象計算機）を接続するた
めに必要な帯域をもった通信路と、会議に使用する各種
入出力装置とを獲得するために、網リソースマネージャ
に前記通信路の帯域を確保が可能か否かを問い合わせ、
また、各計算機の端末リソースマネージャに前記各種入
出力装置の使用状況を問い合わせる（ステップ３‐
２）。これにより、各リソースマネージャは要求された
リソースが何であるかを資源要求情報記憶手段１０に記
憶し、記憶されたリソースの空塞を要求資源空塞判断手
段１１により判断する。

【００４０】端末リソースマネージャおよび網リソース
マネージャは、要求リソースそれぞれについてその空塞
を判断した結果、すべてのリソースが使用可能であれば
（ステップＳ３‐３でｙｅｓの場合）、前記各種リソー
スマネージャを介してリソースを確保し、確保したリソ
ースを制御して参加計算機の会議アプリケーションを起
動させ、会議サービスを実現し（ステップＳ３‐８）、
会議が終了すれば前記各種リソースマネージャを介して
リソースを解放することにより、会議サービスを終了す
る。

【００４１】ここでは本発明の主眼である、会議アプリ
ケーションが会議サービスに必要なリソースのうちの一
部または全てが他アプリケーションに使用されているな
どの理由で獲得できなかった場合の処理について説明す
る。なお、この第１の具体例においては、会議サービス
に必要なリソースのうち、端末リソースの一部が他アプ
リケーションに使用されていることにより、獲得できな
い場合を例にとって説明する。

【００４２】起動要求元計算機の会議アプリケーション
が起動されると（ステップＳ３‐１）、各参加計算機に
接続された音声および画像の入出力装置間で音声および
画像情報を送受するために必要な帯域を持った通信路を
獲得するために、起動要求元計算機から前記網リソース
マネージャ（網資源管理手段５）に通信路の獲得要求を
送信する（ステップＳ３‐２）。

【００４３】網リソースマネージャは、リソース要求情
報記憶手段（資源要求情報保持手段）１０に要求リソー
ス（この場合、通信路と帯域とを表す情報）を記憶さ
せ、要求資源空塞判断手段１０により、要求された通信
路リソースの空塞を判断させる。

【００４４】その結果、“空き”と判断されれば、網リ
ソースマネージャは、要求した会議アプリケーションの
使用のために、該通信路リソースを確保する。また、起
動要求元計算機の前記会議アプリケーションは、会議に
使用する各計算機に接続された音声および画像の入出力
装置とを獲得するために、各会議参加計算機の端末リソ
ースマネージャに入出力装置の獲得要求を送信する。

【００４５】一方、各会議参加計算機の端末リソースマ
ネージャは、要求された端末リソース（入出力装置）を
資源要求情報記憶手段１０に記憶させ、要求資源空塞判
断手段１１により要求リソースの空塞を判断させる。そ
の結果、要求された端末リソースが“空き”であればそ
の会議参加計算機の端末リソースマネージャは、要求し
た会議アプリケーションの使用のために該端末リソース
を確保するが、ここで端末リソースとして、会議参加計
算機のうちの例えばある計算機に接続されているカメラ
が他のプログラムに使用されているために“塞がり”と
判断されたとする（ステップＳ３‐３でｎｏの場合）。

【００４６】この場合には、当該計算機の端末リソース
マネージャは起動要求元計算機の会議アプリケーション
に対してカメラが塞がっていることを通知する。

【００４７】これに対して、起動要求元計算機の会議ア
プリケーションは端末リソースマネージャに対し、カメ
ラの予約を依頼する（ステップＳ３‐５）。カメラの予
約を依頼された前記端末リソースマネージャはリソース
の使用状況を監視している過程で資源要求情報保持手段
１０に記憶されているカメラが解放されたことを検出す
ると、この解放されたカメラを予約していたサービス制
御手段である会議アプリケーションのために、このカメ
ラの割り当てをし、これによって会議アプリケーション
のためにカメラの獲得をすると共に、当該予約していた
起動要求元計算機の会議アプリケーションに対してその
ことを通知する（これによりステップＳ３‐７でｙｅｓ
に分岐）。

【００４８】これにより、起動要求元計算機の会議アプ
リケーションはこの時点で再び前回の起動要求時点でリ
ソースの確保ができずに会議サービスができなかったそ
の会議参加予定の計算機に対してリンクさせてその計算
機の確保した必要なリソースと会議アプリケーションを
利用しての会議サービスを実現する。

【００４９】このことにより、会議アプリケーションが
無闇にカメラの獲得を試みることを行なったり、ユーザ
がやみくもに会議アプリケーションの起動を試みるとい
った無駄な動作を無くすことができるようになる。

【００５０】以上の第１の具体例は、起動要求されたサ
ービスに対して必要なリソース（資源）を獲得させる際
に、既にこれが他に使用されている時は、予約を行な
い、そのリソースが解放されると、この予約に従って上
記起動要求されているサービスのリソースとして獲得
し、必要なリソースが獲得されたならば、上記起動要求
されているサービスを実施するようにしたものであり、
これによって、アプリケーションが無闇に必要なリソー
スの獲得のための動作を行なったり、必要なリソースが
揃わないのを知らずに、ユーザがやみくもにそのアプリ
ケーションの起動を試みるといった無駄をなくし、ユー
ザに対するサービスの向上を図ることができるようにな
るものである。

【００５１】以上は、リソースの予約を行なってそれが
解放されたなら、その解放されたリソースを予約待ちの
アプリケーションに利用させるように割り付けるもので
あるが、これでは使用中のリソースが空くのを待たねば
ならない。しかし、緊急度の高いサービスの起動要求も
あるので、このような緊急度の高いものについて、リソ
ースが空くのを待たせるわけにはゆかない。このような
場合に即座に対応できるようにした例を第２の具体例と
してつぎに説明する。

【００５２】（第２の具体例）第２の具体例は、獲得要
求対象のリソースが“塞がり”の場合に、そのリソース
を使用しているサービス制御手段（アプリケーションプ
ログラム等）がある場合、もしくはそのリソースを使用
しているサービス制御手段が複数ある場合に、どのサー
ビス制御手段に解放要求を出すかを選択して、その選択
したサービス制御手段に解放要求を出すようにするもの
で、その例を図４のブロック図に従って説明する。

【００５３】図４に示すように、システム構成例として
は、計算機（パーソナルコンピュータやワークステーシ
ョンなど）１‐１〜１‐ｎが通信路２を介して接続さ
れ、各計算機に音声／画像の入出力装置（カメラ６、デ
ィスプレイ装置７、マイクロフォン８、スピーカ９）が
接続された構成であり、これは第１の具体例と同様であ
る。

【００５４】ここに示す例でも、第１の具体例と同様
に、前記複数台の計算機のうちの一つには、サービス制
御手段３の一つとして会議アプリケーションがあってこ
れが稼働し、また、各計算機には端末資源管理手段４と
しての端末リソースマネージャがあってこれがそれぞれ
稼働し、複数台の前記計算機のいずかには網資源管理手
段５としての網リソースマネージャがあってこれが稼働
しているものとする。また、これらリソースマネージャ
の構成は第１の具体例として図２で示したものと同様で
ある。

【００５５】第１の具体例と異なる部分は、本例では、
各計算機にはそれぞれ、要求リソースが“塞がり”の場
合において、そのリソースを使用しているサービス制御
手段（アプリケーションプログラム等）が１つ以上ある
場合に、どのサービス制御手段に解放要求を出すかを決
定する資源要求先サービス制御手段決定手段１２を設け
るようにしている点、およびサービス制御手段３には、
目的のサービスを提供するための制御機能の他に、資源
獲得・解放機能と、資源制御機能とを設けるようにして
いる点である。

【００５６】資源獲得・解放機能は、未使用のリソース
を要求に基づいて獲得し、また、要求に基づいて解放す
るように端末資源管理手段（端末リソースマネージャ）
４に指令するための機能手段である。また、資源制御機
能はリソース解放要求を受けたときにそのリソース（資
源）を解放するかどうかを判断し、解放する場合に資源
獲得・解放機能に当該リソースの解放を指示する機能手
段である。

【００５７】なお、サービス制御手段３には目的のサー
ビスを提供するための制御機能の他に、資源獲得・解放
機能と、資源制御機能とを設ける他に、資源要求先サー
ビス制御手段決定手段１２をも設けるようにしてもよ
い。この場合サービス制御手段（アプリケーションプロ
グラム等）３の構成例を図５に示す。すなわち、サービ
ス制御手段３には目的のサービスを提供するための制御
機能の他に、サービス制御資源要求先サービス制御手段
決定手段１２と、資源獲得・解放手段１４と、資源制御
手段１５とがある。

【００５８】これらのうち、資源要求先サービス制御手
段決定手段１２は要求リソースが“塞がり”の場合にお
いて、そのリソースを使用しているサービス制御手段
（アプリケーションプログラム等）が１つ以上ある場合
に、どのサービス制御手段に解放要求を出すかを決定す
る機能手段であり、また、資源獲得・解放手段１４は、
未使用のリソースを要求に基づいて獲得し、また、要求
に基づいて解放するように端末資源管理手段（端末リソ
ースマネージャ）４に指令するための機能手段である。
また、資源制御手段１５はリソース解放要求を受けたと
きにそのリソース（資源）を解放するかどうかを判断
し、解放する場合に資源獲得・解放手段１４に当該リソ
ースの解放を指示する機能手段である。

【００５９】なお、各サービス制御手段３にはリソース
解放の要求を受けた場合に、当該解放要求リソースの解
放を行なうか否かの判断をする機能と、リソースの解放
を行なった場合に、端末リソースマネージャに対して解
放を通知する機能と、リソースの解放を行なわなかった
場合に、端末リソースマネージャに対して解放拒否を通
知する機能とを持たせてある。従って、端末リソースマ
ネージャはこの情報に従って、リソースの解放や確保を
行なうことができる。

【００６０】つぎにこのような構成の本システムの作用
を説明する。

【００６１】ここでも第１の具体例と同様に、会議アプ
リケーションが会議サービスに必要なリソースのうちの
一部が他のアプリケーションに使用されている場合のリ
ソース獲得処理について説明する。

【００６２】図６に本具体例において会議アプリケーシ
ョンがリソースを獲得してサービスを開始するまでの処
理の流れを示す。図６に沿って説明する。会議アプリケ
ーションの起動要求元の計算機では、会議アプリケーシ
ョンが起動されると（ステップＳ６‐１）、まず網リソ
ースマネージャおよび各会議参加計算機の端末リソース
マネージャに対して、当該会議アプリケーションのサー
ビス実施に必要な各種リソースについての獲得要求を、
通信路２を介して送信する（ステップＳ６‐２）。

【００６３】ここで端末リソースとして、例えばある計
算機に接続されているカメラが他のアプリケーションプ
ログラムによって使用されていたために、リソースマネ
ージャの要求資源空塞判断手段１１により“塞がり”と
判断された場合には（ステップＳ６‐３でｎｏの場
合）、要求元の会議アプリケーションは当該カメラを使
用中の他のアプリケーションプログラム（そのリソース
を使用しているサービス制御手段３）を資源要求先サー
ビス制御手段決定手段１２により選択させ、カメラの解
放を要求する。

【００６４】この例の場合、端末リソースマネージャに
問い合わせることにより、そのリソース（この例ではカ
メラ）を使用しているサービス制御手段（アプリケーシ
ョンプログラム等）がどれであるかを知り、当該サービ
ス制御手段を資源要求先サービス制御手段決定手段１２
に決定させることができる。

【００６５】なお、この例ではカメラを占有していたア
プリケーションが一つであるとして、資源要求先サービ
ス制御手段決定手段１２は単にカメラを占有しているア
プリケーションをそのまま解放要求先として選択させる
ようにしたが、要求リソースの占有者が複数ある場合
（網リソースなど）もある。このようなケースでの例に
ついては第３の具体例において説明する。

【００６６】資源（カメラ）の解放を要求されたサービ
ス制御手段（アプリケーションプログラム）は、その資
源（カメラ）を解放するかどうかを判断し、その結果、
解放する場合には、解放処理を行い、端末リソースマネ
ージャに対して解放を通知する。

【００６７】会議アプリケーションは端末リソースマネ
ージャからカメラの解放通知を受けて（ステップＳ６‐
６でｙｅｓの場合）、カメラを獲得し、会議サービスを
実行する。

【００６８】ここで、リソースの解放要求を受けたサー
ビス制御手段３が当該リソースを解放するかしないかの
判断に用いる判断基準としては、 [i] 「要求されたリソースを解放しても、予め（ユー
ザにより）設定されたサービス品質の許容範囲を満たせ
るか否か」というものが一つ考えられる。この基準にお
いては、要求されたリソースを解放しても、予め設定さ
れたサービス品質の許容範囲を満たせると判断される場
合は解放する。

【００６９】また、この基準以外にも例えば、 [ii] ユーザとのインタフェース（計算機の画面上な
ど）にリソース解放の可否を尋ねる情報を示し、ユーザ
からリソース解放の可否を指示させる。 [iii] 予め（ユーザにより）設定されたアプリケーシ
ョン間の起動優先順位に従い、より高い優先順位のアプ
リケーションから開放要求を受けた場合に解放する。 [iv] アプリケーションにおける特定の機能またはリソ
ースに対するアクセスが一定時間無い場合に解放すると
判断する。 [v] 予め（ユーザにより）設定された開放要求を受け
付け可否状態に基づき、受け付け可の状態の場合は解放
する。 などが考えられる。

【００７０】以上は、サービスの要求元より、使用した
いリソースを通知して相手側にそのリソースを確保させ
ると共に、使用したいリソースが塞がっている時は、そ
のリソースを使用しているアプリケーションに解放要求
を出し、この解放要求を受けたアプリケーション側で
は、解放の是非を判断して、解放可能のときにはそのリ
ソースを解放してサービスの要求元に使用させるように
することにより、予約なしで、何時でもサービスが受け
られるようにしたものである。

【００７１】要求リソースの占有者が複数ある場合の例
（例えば、複数のアプリケーションがそれぞれ通信路を
使用していて通信路の帯域の空きが十分でない場合な
ど）をつぎに説明する。

【００７２】（第３の具体例）図７に本発明の第３の具
体例の説明図を示す。システムの構成は第２の具体例と
同一である。図７では、通信路２が多重化されており、
複数の帯域が確保できて、空いている帯域があればこれ
を確保して通信に利用し、サービスを受けることができ
ることを示している。

【００７３】今、このシステム上のいくつかの計算機に
よって、会議アプリケーション（図中では会議１）が実
行されているものとする。

【００７４】この状態で別の計算機の組み合わせにおい
て、第２の会議アプリケーション（図中では会議２）を
実行しようとしたとする。そして、第２の会議アプリケ
ーションのグループでは、端末リソースである音声／画
像情報の各入出力装置は確保できたが、情報を伝送する
のに必要な帯域（網リソース）が確保できなかったとす
る。この場合について、本発明によるリソース確保の方
法を説明する。

【００７５】網リソースマネージャは、要求資源空塞判
断手段１１により、要求された帯域の通信路２が空いて
いるかどうかを判断する。判断の方法としては、例え
ば、第１の具体例において述べたような方法が考えられ
る。

【００７６】判断の結果、“塞がり”と判断された場
合、網リソースマネージャは解放要求先サービス制御手
段決定手段１２により、網リソースを共有しているアプ
リケーションの中から網リソースの解放をさせるに最適
なアプリケーションを選択させる。

【００７７】選択の方法としては、例えば最近一定期間
の網リソースの実際のトラヒック状況をモニタリング
し、トラヒックの無いもの、あるいは少ないものを選択
する（図中では他アプリケーション２）などの方法が考
えられる。

【００７８】このようにして選択されたアプリケーショ
ンに対して、網リソースの解放要求を出す。解放要求を
受信したアプリケーションは自己の持つリソース解放可
否判断機能手段により、要求網リソースを解放するか否
かを判断し、解放または解放拒否する。以降の処理は第
２の具体例と同様である。

【００７９】以上の第１ないし第３の具体例は、要する
に、通信システムにおいて、あるアプリケーションが必
要とするリソースが他のアプリケーションにより確保さ
れてしまっていて利用できない場合に、予約をしてその
リソースが解放されると、当該リソースの使用状況を管
理しているリソース管理手段または、当該リソースを確
保している前記アプリケーションが、当該リソースの解
放時に当該リソースを要求しているアプリケーションに
解放を通知することにより、そのリソースを要求してい
るアプリケーションに直ぐさま、当該リソースを確保さ
せることができるようにしたものであり、やみくもにア
プリケーションの再起動を繰り返さずに済むようにした
ものである。

【００８０】また、本発明はアプリケーションが直接あ
るいはリソース管理手段を経由して、前記リソースを確
保している他のアプリケーションにリソースの解放を要
求し、可能であれば解放させることにより、前記リソー
スを確保している他のアプリケーション自らが当該リソ
ースを解放するまで待つことなしに当該リソースを獲得
する機会を与え、リソースの運用効率を高めることがで
きるようにしたものである。

【００８１】従って、無用な操作を回避できるようにな
り、また、リソースをいたずらに占有して他のアプリケ
ーションの実行を妨げることが少なくなり、ユーザサー
ビスの向上を図ることができるようになる。

【００８２】（第４の具体例）電話システムのような通
信システムは、一つの端末に一つのコールが対応する低
機能な端末のみが存在し、一つのコールに複数のコネク
ションが存在するようなことがない。しかし、マルチメ
ディアでは一つのコールに複数のコネクションが存在す
る。

【００８３】すなわち、従来の電話通信では複数メディ
アを使用しても、例えばＨ１２２では１本のコネクショ
ン上に多重化し、またコールとコネクションは同時に制
御されていた。また、１台の端末は同時には１つのコー
ルのみに関与し、１つのコールで通話中の場合に第２の
コールの要求は話中扱いで拒否されていた。しかし、上
記の従来技術のような端末で利用可能な通信資源や通信
網で利用可能な通信資源を考慮していない通信システム
ではマルチメディアに柔軟に対応できない。

【００８４】また、マルチメディアでは種々の資源（リ
ソース）が利用されるが、端末が利用可能な通信資源や
通信網が利用可能な通信資源を考慮してコールとコネク
ションを制御する通信システムはなく、この場合、コー
ルを行なってみて初めて自己の目指す資源（リソース）
が利用できるか否かがわかる仕組みであり、相手の環境
が掴めない場合は相手環境が不十分なために、通信がで
きないことも多い。そこで、コールとコネクションを相
手環境の範囲で適合させて行なうことができるようにし
た例をつぎに説明する。

【００８５】ここでは、基本的な例として、端末と通信
網で利用可能な通信資源の状態を管理する通信資源管理
手段を設けるようにし、その通信資源管理手段の提供す
る通信資源の状態に基づいてコールやコネクションを制
御するコール・コネクション制御手段を設ける構成とす
る。

【００８６】具体例を用いて詳細を説明する。

【００８７】端末と通信網で利用可能な通信資源の状態
を管理する通信資源管理手段を設けて当該通信資源の状
態を管理するようにし、この通信資源管理手段の提供す
る通信資源の状態に基づいてコール・コントロール制御
手段により、コールやコネクションを制御する例を第４
の具体例として説明する。

【００８８】なお以後、コール・コントロール制御手段
をＣＣ制御手段、またコールコントロールブロックをＣ
ＣＢと略称する。

【００８９】図９は、第４の具体例並びに後述する第５
の具体例におけるシステムのハードウェア構成図であ
る。図中、１０１はネットワーク（通信網）であり、こ
のネットワーク１０１を介してここでは３つの端末（端
末（Ａ），端末（Ｂ），端末（Ｃ））２０１，３０１，
４０１が接続されている。

【００９０】端末（Ａ）２０１は、ディスプレイ２０
２、スピーカ２０３、マイク２０４を入出力装置として
備えている。端末（Ｂ）３０１も端末（Ａ）と同様の構
成であり、ディスプレイ３０２、スピーカ３０３、マイ
ク３０４を備えている。

【００９１】一方、端末（Ｃ）４０１は、ビデオ再生装
置４０２、スピーカ４０３、マイク４０４を備えてい
る。このビデオ再生装置４０２からは、ビデオの再生に
伴い、音声と動画の信号をネットワークに流すことがで
きる。

【００９２】次に図１０は、端末（Ａ）２０１の構成図
である。

【００９３】端末（Ａ）２０１は、通信制御手段２１１
を介してネットワークと接続している。入出力装置制御
手段２１２は、端末（Ａ）２０１が備えている入出力装
置の制御を行う。通信資源管理手段２１３は、入出力装
置制御手段を介して接続している各入出力装置の状態、
および端末（Ａ）２０１で使用可能な通信帯域などの通
信資源を管理する手段で、それらの資源の状態を記述す
る通信資源管理テーブルを有する。

【００９４】ＣＣ制御手段２１４は、端末（Ａ）２０１
に関わるコールとコネクションを制御する手段である。
また、ユーザと端末とのインタフェースを制御するＨＭ
Ｉ（Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃ
ｅ）制御手段２１５も備えている。

【００９５】以上の各手段は、端末（Ａ）２０１内のバ
ス２１６を介して接続されている。また、端末（Ｂ）３
０１、端末（Ｃ）４０１も同様な構成を備えている。

【００９６】次に、フロー図１１に従って各手段の実際
の動きを説明する。本発明の適用環境例として、ここで
はネットワークはＡＴＭ網を想定し、各端末が使用可能
である通信帯域は、一端末あたり送信、受信それぞれ３
Ｍｂｐｓと仮定して話を進める。

【００９７】また、音声に関して必要となる通信帯域
は、送受信それぞれ１Ｍｂｐｓ、動画に関して必要な通
信帯域は、送受信各２．５Ｍｂｐｓと仮定する。そし
て、現在、各端末ともに入出力装置は未使用とし、この
時点での端末（Ａ）２０１，端末（Ｃ）４０１の通信資
源管理手段２１３が備える通信資源管理テーブルは図１
２に示す如きであるものとする。

【００９８】端末（Ｂ）３０１の通信資源管理テーブル
は、端末（Ａ）２０１と同様であるので省略する。

【００９９】〔正常なシーケンス例〕 ［端末間通信のためのコールとコネクション動作］ここ
で、端末（Ａ）２０１の使用者（以後、ユーザＡと記
す。残りの端末（Ｂ），端末（Ｃ）の使用者に関しても
同様）はマイクロフォン（以下、マイクと呼ぶ）、スピ
ーカを使用したユーザＢ（端末（Ｂ）の使用者）との音
声双方向通信をＨＭＩ制御手段２１５に要求したとする
（ステップＳ‐１１）。

【０１００】端末（Ａ）２０１のＨＭＩ制御手段２１５
は、ユーザＡからの要求を受け、端末（Ａ）２０１のＣ
Ｃ制御手段２１４にマイクとスピーカを使用するコール
に関するＣＣＢの生成を要求する。要求を受け取ったＣ
Ｃ制御手段２１４は、要求の内容がマイクとスピーカを
使用するコールの生成であることを判断し、次に端末
（Ａ）２０１の通信資源管理手段２１３に対してマイク
とスピーカの使用が可能であるか否かを問合わせる（ス
テップＳ‐１２）。

【０１０１】例えばこのとき、端末（Ａ）２０１のマイ
クの電源が入っていないと仮定すると、要求した通信資
源が使用できないので、ＣＣ制御手段２１４は通信資源
管理手段２１５からマイクの使用が不可能である旨を通
知される。これを受けたＣＣ制御手段２１４は、ＨＭＩ
制御手段２１５に対して、要求されたコールの生成が出
来ない旨を通知し、これを受けたＨＭＩ制御手段２１５
はユーザＡに対して、マイクが使用できないためにユー
ザＢとの通信ができないことを通知する（ステップＳ‐
１２のＮｏ）。

【０１０２】今の場合、端末（Ａ）２０１ではマイクも
スピーカも未使用であるし、通信帯域も余裕があるの
で、通信資源管理手段２１３は要求された通信資源の使
用が可能である旨をＣＣ制御手段２１４に対して通知す
る（ステップＳ‐１２のＹｅｓ）。

【０１０３】ＣＣ制御手段２１４はこれを受けて、この
コールに関するＣＣＢを作成する（ステップＳ‐１
３）。

【０１０４】ここでＣＣＢ（コールコントロールブロッ
ク）とは、コールを制御するために必要なブロックで、
いくつかのフィールドを有する。図１３にＣＣＢのフォ
ーマットを、図１４に端末（Ａ）２０１に生成されたＣ
ＣＢを示す。但し、ＣＣＢのフォーマットに関しては、
本実施例に係わるフィードのみを記述した。

【０１０５】図１３のＣＣＢ（コールコントロールブロ
ック）の各フィールドを説明する。

【０１０６】図１３における５０１はコールリファレン
スフィールドであり、このコールリファレンスフィール
ド５０１は、ＣＣＢを所有するコールに付けられた番号
であるコールリファレンスを記述するフィールドであ
る。コールリファレンスとは、一般にＵＮＩで一意であ
るコールの識別子のことを指す。ここでは、単にコール
の識別子という意味で使用する。本例では特にコールリ
ファレンスの獲得の仕方には言及せずに、端末間で同じ
コールリファレンス１が割り当てられたものと仮定す
る。

【０１０７】図１３における５０２は通信相手フィール
ドであり、この通信相手フィールド５０２には通信相手
を記述する。５０３は通信資源フィールドであり、この
通信資源フィールド５０３にはその端末で使用する通信
資源を記述する。

【０１０８】次にＣＣ制御手段２１４は、コールリファ
レンス（今の場合、“１”）と、使用する通信相手（今
の場合、端末（Ｂ））とその通信資源（今の場合、スピ
ーカとマイク）と、その資源の使用要求とを通信資源管
理手段２１３に通知する。通知を受けた端末（Ａ）２０
１の通信資源管理手段２１３は、端末（Ａ）２０１の通
信資源管理テーブルを図１５に示す如きに変更し、その
変更完了の旨をＣＣ制御手段２１４に通知する（ステッ
プＳ‐１４）。そして、その通信資源を利用するため
に、確保する。

【０１０９】通信資源管理手段２１３からの変更完了を
受けた端末（Ａ）２０１のＣＣ制御手段２１４は、ＣＣ
Ｂ生成完了をＨＭＩ制御手段２１５に通知する。ＣＣＢ
生成完了の通知を受けたＨＭＩ制御手段２１５は、通信
制御手段２１１へ端末（Ｂ）３０１に対して通信の要求
を出すように指令し、これによって端末（Ａ）２０１の
通信制御手段２１１は端末（Ｂ）３０１に対して通信の
要求を出す（ステップＳ‐１５）。

【０１１０】ここで端末（Ｂ）３０１が何らかの理由で
通信に応じられない状況にあったとする。この場合は、
端末（Ｂ）３０１の通信制御手段２１１は端末（Ａ）２
０１の通信制御手段２１１に対して通信が出来ない旨を
通知する。

【０１１１】すると、端末（Ａ）２０１では、端末
（Ｂ）３０１からの通信不可能である旨の通知を通信制
御手段２１１を介してＨＭＩ制御手段２１５が受ける。
そして、これを受けると、端末（Ａ）２０１のＨＭＩ制
御手段２１５は、ＣＣ制御手段２１４に、先程生成した
ＣＣＢを削除するように要求する。

【０１１２】要求を受けたＣＣ制御手段２１４はＣＣＢ
を削除するとともに、コールリファレンス１とＣＣＢに
記載されている通信資源とその通信資源の解放要求を端
末（Ａ）２０１の通信資源管理手段２１３に通知する。
この通知により、通信資源管理手段２１３は確保してい
た通信資源を解放するが、この解放に成功した場合、通
信資源管理手段２１３はその旨をＣＣ制御手段２１４に
通知する。端末（Ａ）２０１の通信資源管理手段２１３
は、確保していた通信資源の解放にともない、端末
（Ａ）２０１の通信資源管理テーブルを書き替え、マイ
クとスピーカを未使用に戻す。

【０１１３】通信資源管理手段２１３からの解放成功の
通知を受けたことにより、ＣＣ制御手段２１４はＣＣＢ
の削除の成功をＨＭＩ制御手段２１５に通知し、ＨＭＩ
制御手段２１５は、ユーザＡにユーザＢとの通信が不可
能であることを通知する（ステップＳ‐１５のＮｏ）。

【０１１４】ここで（ステップＳ‐１５のＹｅｓ）に戻
る。

【０１１５】端末（Ａ）２０１より通信の要求を受けた
端末（Ｂ）３０１がマイクとスピーカとを用いた通信が
可能な状態にあるときは、つぎのようになる。

【０１１６】端末（Ａ）２０１よりマイクとスピーカと
を用いての通信の要求を受けた端末（Ｂ）３０１では、
上述の手続きと同様にしてコールリファレンス１のＣＣ
Ｂを作成し、通信が可能である旨を端末（Ａ）２０１に
通知する。この通信が可能である旨の通知を端末（Ａ）
２０１の通信制御手段２１１が受け取ると、ユーザＡと
ユーザＢのマイクとスピーカを使用した通信が可能にな
り、これらを用いての通信を始めることができる（ステ
ップＳ‐１６）。

【０１１７】ここまでで一つ注意すべきことは、ＣＣＢ
や通信資源管理テーブルは端末（Ａ）２０１の共有資源
なので、特に排他制御を考慮した操作を行わなければな
らない。具体的には、ＣＣＢや通信資源管理テーブルな
どの共有資源を操作する時には、セマフォなどの排他制
御に必要な機能を利用することが考えられる。ここでも
なんらかのこのような排他制御機能を使用していると仮
定する。

【０１１８】［通信終了動作］次にユーザＡとユーザＢ
の通信が終了する場合を説明する。

【０１１９】ユーザＡが通信を切断する場合には、その
旨を端末（Ａ）２０１のＨＭＩ制御手段２１５に通知す
る（ステップＳ‐１７）。

【０１２０】するとＨＭＩ制御手段２１５は、通信制御
手段２１１を介して端末（Ｂ）３０１に通信切断の要求
をすると同時に、端末（Ａ）２０１のＣＣ制御手段２１
４にコールリファレンス１のＣＣＢの削除を要求する。

【０１２１】端末（Ａ）２０１のＣＣ制御手段２１４は
それを受けて、コールリファレンス１のＣＣＢを削除す
るとともに、通信資源管理手段２１３に対してコールリ
ファレンス１で使用している全通信資源の解放を要求す
る。

【０１２２】コールリファレンス１のコールで使用して
いる通信資源はＣＣＢを参照することより分かる。

【０１２３】次に端末（Ａ）２０１の通信資源管理制御
手段２１３は、通信資源解放を行ない、それに成功する
と通信資源解放の成功をＣＣ制御手段２１４に通知す
る。通知を受けた端末（Ａ）２０１のＣＣ制御手段２１
４は、ＣＣＢ削除成功を通信制御手段２１１に通知し、
これによってユーザＡとユーザＢの通信は終了する（ス
テップＳ‐１８）。

【０１２４】［通信途中におけるユーザ使用の通信資源
の解放動作］通信途中で、ユーザＡが使用している通信
資源を解放する必要が生じた場合を説明する。

【０１２５】この場合も上の手順とほぼ同様である。上
の手順と異る箇所はＣＣ制御手段２１４は、コールリフ
ァレンスと解放すべき通信資源とその通信資源の解放要
求を通信資源管理手段２１３に通知するが、ＣＣＢは削
除しない点である。また、ユーザＡが通信の途中で新た
な通信資源を追加する場合も同様である。

【０１２６】以上が正常なシーケンスであるが、次に障
害があるシーケンス例を説明する。

【０１２７】〔障害があるシーケンス例〕 ［通信中の端末に別端末の割り込みが発生する場合の動
作］現在、ユーザＡとユーザＢは、スピーカとマイクを
利用して双方向の音声通信を行っているとする。この時
点での端末Ａの通信資源管理テーブルは図１５の通りで
ある。

【０１２８】今、ユーザＣ（端末（Ｃ）の使用者）は自
分の使用している端末（Ｃ）４０１でビデオを再生し、
ユーザＡに送信しようと考えている。ユーザＣは、先程
の正常なシーケンスの手順に従ってユーザＡとの通信を
確立しようとし、端末（Ｃ）４０１においてはコールリ
ファレンスの生成、通信管理テーブルの変更に成功した
とする。

【０１２９】次に端末（Ｃ）４０１の通信制御手段２１
３は、端末（Ａ）２０１の通信制御手段２１１に音声と
動画を受信する準備を要求する。要求を受けた端末
（Ａ）２０１の通信制御手段２１１は、端末（Ａ）２０
１のＣＣ制御手段２１４にスピーカとディスプレイを使
用するコールに関するＣＣＢの生成を要求する。

【０１３０】端末（Ａ）２０１のＣＣ制御手段２１４は
端末（Ａ）２０１の通信資源管理手段２１３にスピーカ
とディスプレイの使用が可能であるかを問い合わせる
が、通信資源管理手段は２１３通信資源管理テーブルを
見ることによりスピーカが使用できないことを知り、そ
の旨をＣＣ制御手段２１４に通知する。

【０１３１】この通知により、端末（Ａ）２０１のＣＣ
制御手段２１４はＣＣＢの生成が出来ない旨を通信制御
手段２１１に通知し、端末（Ａ）２０１の通信制御手段
２１１は、端末（Ｃ）４０１に対して端末（Ａ）２０１
側のスピーカが使用できないので、先程の条件（音声と
動画の受信）ではコールを生成することが出来ないこと
を通知する。端末（Ｃ）４０１側ではこれを受けて、先
程の条件による通信はできないことを知る。

【０１３２】そこで、ユーザＣは音声を送信することを
諦めて、動画のみをユーザＡに送信することにしたとす
る。

【０１３３】端末（Ｃ）４０１側では、先程と同じ手順
でＣＣ制御手段２１４に、ディスプレイを使用しての端
末（Ａ）２０１とのコールに関するＣＣＢの生成が要求
される。そして、ディスプレイを使用するコールに関す
るＣＣＢを生成し、端末（Ａ）２０１に送り、ディスプ
レイの使用が可能であるかを問い合わせる。

【０１３４】しかし、本実施例の仮定として、端末の送
受信通信帯域は各３Ｍｂｐｓであり、音声の送受信は各
１Ｍｂｐｓ、動画の送受信は各２．５Ｍｐｂｓである。
現在、端末（Ａ）２０１側では、端末（Ｂ）３０１との
音声に関する両方向通信により、受信通信帯域を１Ｍｂ
ｐｓ使用しているので、端末（Ａ）２０１の受信通信帯
域の残りは２Ｍｐｂｓである。

【０１３５】一方ディスプレイを使用する動画の受信に
は２．５Ｍｂｐｓ必要なので、ディスプレイを使用する
通信に必要な通信帯域を確保することが不可能であるこ
とがわかる。

【０１３６】その結果、端末（Ａ）２０１の通信制御手
段２１１は端末（Ｃ）４０１に対して通信帯域の不足の
ために動画の受信が出来ない旨を通知する。

【０１３７】以上は、端末と通信網で利用可能な通信資
源の状態を管理する通信資源管理手段を設けて当該通信
資源の状態を管理するようにし、要求する通信の必要な
資源を提示してこの提示資源と、通信資源管理手段の提
供する通信資源の状態とを比較し、要求する資源を使用
しての通信が可能な場合にはその資源を利用して通信を
実施し、要求する資源が確保できないときは、通信資源
管理手段の提供する通信資源の状態から代替え資源を探
り、代替え可能な資源があればその代替え可能な資源を
利用して通信を実施するように制御するもので、コール
段階でそれが行なえるようになるので、その時々の資源
状況に応じて合理的に通信ができるようになる。

【０１３８】（第５の具体例）第５の具体例は、優先度
の低い通信の確保している通信資源が、緊急な優先度の
高い通信に要求された場合、その要求に応じて優先度の
低い通信が確保している通信資源を解放することに関わ
る例である。

【０１３９】本例のハードウェア構成（端末（Ａ）、端
末（Ｂ）、端末（Ｃ）とネットワークの構成）は、第４
の具体例と同様とする。また、本例の端末構成図を図１
６に示す。

【０１４０】図１６に示すように、端末は、通信制御手
段６１１を介してネットワークと接続している。入出力
装置制御手段６１３は、端末が備えている入出力装置の
制御を行う。通信資源管理手段６１４は、入出力装置制
御手段６１３を介して接続している各入出力装置の状
態、および端末で使用可能な通信帯域などの通信資源を
管理する手段で、それらの資源の状態を記述する通信資
源管理テーブルを有する。

【０１４１】ＣＣ制御手段６１５は、端末に関わるコー
ルとコネクションを制御する手段である。また、ユーザ
と端末とのインタフェースを制御するＨＭＩ制御手段６
１６も備えている。

【０１４２】ここまでは、第４の具体例と同じである
が、本例では端末には割り当て決定手段６１２を備えて
いる点が異なる。この割り当て決定手段６１２とは、所
定の判定基準に従って２つの通信に対してランク付けを
行ない、それに応じて端末で利用可能な通信資源や通信
網で利用可能な通信資源の割り当てを決定する手段であ
る。

【０１４３】以上の各手段は、端末内のバス６１７を介
して接続されている。端末（Ａ）２０１、端末（Ｂ）３
０１、端末（Ｃ）４０１はいずれも本構成を備える。

【０１４４】本具体例では、ＣＣＢには、新たにコール
の優先度を記述するフィールドを設ける。そして、この
フィールドを利用してコールに対して優先度を付けるこ
とが出来るようにする。優先度は発呼者が任意の値を付
けることが可能であるとする。本例では、特に優先度を
２段階の“０”と“１”にしてある。そして、“０”は
“１”よりも低優先度であるとする。

【０１４５】なお、ここでは便宜的に優先度を２段階に
したが、システムの要求に合わせて任意の段階を設定し
てよいのは言うまでもない。

【０１４６】ここで説明する例において使用するＣＣＢ
のフォーマット図を図１７に示す。第４の具体例におけ
るＣＣＢと異なる箇所は、優先度を記述する優先度フィ
ールド７０４が追加された点である。以下に示す本例で
の「所定の判断基準」とは、この優先度に基づくものと
する。

【０１４７】つぎに作用を説明する。

【０１４８】現在、ユーザＡ、ユーザＢと音声の両方向
通信を行っているとする。互いに使用している通信資源
は、スピーカとマイクであり、この現在行なっている両
方向通信のコールに割り当てた優先度は“０”であった
とする。このコールに関する端末（Ａ）のＣＣＢを図１
８に示す。また、この時点での端末（Ａ）の通信資源管
理テーブルを図１９に示す。

【０１４９】［端末（Ｃ）４０１の動作］ここで、ユー
ザＣからユーザＡに緊急な要件が発生し、ユーザＡと音
声の双方向通信をする必要が出来たと仮定する。このと
き、ユーザＣは端末（Ｃ）４０１のＨＭＩ制御手段６１
６に優先度が“１”で、スピーカとマイクを使用した音
声の双方向通信を要求する。

【０１５０】すると端末（Ｃ）４０１では通信資源の確
保とＣＣＢの生成に成功し、次に端末（Ｃ）の通信制御
手段６１１は端末（Ａ）２０１の通信制御手段６１１に
音声の双方向通信を優先度“１”で要求する。

【０１５１】［端末（Ａ）２０１の動作］要求を受けた
端末（Ａ）２０１の通信制御手段６１１は、スピーカと
マイクを使用する音声の双方向通信で優先度“１”のコ
ールに関するＣＣＢの作成をＣＣ制御手段６１５に要求
する。

【０１５２】ＣＣ制御手段６１５はスピーカとマイクの
使用が可能であるかを通信資源管理手段６１４に問合わ
せる。通信資源管理手段６１４は、通信資源管理テーブ
ル（図１９）を参照することにより、それは既にユーザ
ＡとユーザＢとの間のコールリファレンス１の通信で使
われていることを知る。

【０１５３】そして、通信資源管理手段６１４はＣＣ制
御手段６１１に対して先に要求された通信資源が、コー
ルリファレンス１のコールによって使用されているので
要求された通信資源は解放できない旨を通知する。

【０１５４】すると端末（Ａ）２０１のＣＣ制御手段６
１１は、割り当て決定手段６１２に対して端末（Ａ）２
０１と端末（Ｂ）３０１との間で現在行なわれている通
信と端末（Ｃ）４０１に要求されている通信との間で、
所定の判定基準に従い通信資源を割り当てるように要求
する。

【０１５５】端末（Ａ）２０１の割り当て決定手段６１
２は、コールリファレンス１をキーにしてＣＣＢを探索
し、該当するＣＣＢを発見する。そして端末（Ａ）２０
１と端末（Ｂ）３０１との間で現在行なわれている通信
の優先度が“０”であることを知る。

【０１５６】一方で割り当て決定手段６１２は、端末
（Ｃ）４０１から要求された通信の優先度が“１”であ
ることを端末（Ａ）２０１のＣＣ制御手段６１５に問い
合わせて知ることが出来る。そこで端末（Ａ）２０１の
割り当て決定手段６１２は、現在端末（Ｂ）との間で行
なわれている通信よりも端末（Ｃ）４０１に要求されて
いる通信を優先すべきであると判断し、端末（Ａ）２０
１のＣＣ制御手段６１５に対してコールリファレンス１
の通信（端末（Ａ）と端末（Ｂ）との間の通信）が使用
している通信資源で、端末（Ｃ）４０１から要求されて
いる通信資源と重なるものの解放を要求する。

【０１５７】端末（Ａ）２０１のＣＣ制御手段６１５は
それを受けて通信資源管理手段６１４に対して端末
（Ｃ）４０１との通信で使用する通信資源の解放を要求
する。端末（Ａ）２０１の通信資源管理手段６１４は、
ＣＣ制御手段６１５からの解放要求を受けて、通信資源
管理テーブルから端末（Ｃ）４０１に要求されている通
信資源を一時解放し、解放の成功を端末（Ａ）２０１の
ＣＣ制御手段６１５に通知する。

【０１５８】ＣＣ制御手段６１５は、解放の成功を受け
た後、改めて端末（Ｃ）４０１に要求された通信のため
のＣＣＢを作成する。これ以後、端末（Ａ）２０１での
ＣＣＢの作成と、通信資源を確保する方法は第４の具体
例と同様である。

【０１５９】但し、ＣＣＢの作成時に優先度フィールド
にその通信の優先度を書き込むことが追加される。

【０１６０】このように、この例では、通信の優先度の
情報を新たに付加してコールとコネクションを行ない、
既に確立している通信によって使用されている通信資源
に対して、新たな通信がその通信資源の使用を要求した
場合、その新たな通信の優先度が現在の優先度より上位
であれば、その新たな通信において要求される通信資源
を解放し、その新たな通信の要求を出した側との通信で
の利用に供するようにした。そのため、この例によれ
ば、緊急度の高い通信は優先して必要な資源を確保して
の通信が可能になるなお、優先度によっては所定の判断
基準によって通信資源を比例配分、あるいは案分するよ
うにする構成も考えられる。この場合、要求した通信資
源に対して、一部のみしか割り当てないことになるが、
既にその資源を使用しているアプリケーションも、これ
によってサービスを続行することができることになる。

【０１６１】以上は緊急度の高い通信は優先度に応じて
必要な資源を確保できるようにする例であるが、資源を
解放するか否かをユーザに判断させるようにする具体例
をつぎに説明する。

【０１６２】（第６の具体例）既に確立している通信に
よって使用されている通信資源に対して、新たな通信が
その通信資源の使用を要求した場合、どちらの通信に対
して通信資源を割り当てるかをユーザに判断させるよう
にする具体例が以下に説明する第６の具体例である。

【０１６３】本実施例のハードウェア構成（端末
（Ａ）、端末（Ｂ）、端末（Ｃ）とネットワークの構
成）とＣＣＢのフォーマットは、第４の具体例と同様と
する。また、本実施例の端末構成を図２０に示す。

【０１６４】端末は、通信制御手段８１１を介してネッ
トワークと接続している。入出力装置制御手段８１４
は、端末が備えている入出力装置の制御を行う。通信資
源管理手段８１２は、入出力装置制御手段８１４を介し
て接続している各入出力装置の状態、および端末で使用
可能な通信帯域などの通信資源を管理する手段で、それ
らの資源の状態を記述する通信資源管理テーブルを有す
る。

【０１６５】ＣＣ制御手段８１３は、端末に関わるコー
ルとコネクションを制御する手段である。また、ユーザ
と端末とのインタフェースを制御するＨＭＩ制御手段８
１５も備えている。通信資源表示手段８１６は、現在の
通信資源の種別、使用量と要求されている通信資源の種
別、使用量を表示する手段である。ユーザは、この表示
手段により通信資源の状況を知り、どちらの通信に対し
て通信資源を割り当てるかを判断する。

【０１６６】割当の判断結果を指示する手段が割り当て
指示手段８１７である。割り当て指示手段は、その指示
を割り当て決定手段８１８に通知して最終的に通信資源
の割り当てが決定する。以上の各手段は、端末内のバス
８１９を介して接続されている。端末（Ａ）２０１，端
末（Ｂ）３０１，端末（Ｃ）４０１はいずれも本構成を
備える。

【０１６７】現在、ユーザＡは、ユーザＢと音声の両方
向通信を行っているとする。互いに使っている通信資源
は、スピーカとマイクである。このコールの端末（Ａ）
２０１でのＣＣＢを図２１に示す。また、この時点での
端末（Ａ）２０１の通信資源管理テーブルを図２２に示
す。

【０１６８】ここで、ユーザＣからユーザＡに緊急な要
件が発生し、ユーザＡと音声の双方向通信をする必要が
出来たと仮定する。このとき、ユーザＣは端末（Ｃ）４
０１のＨＭＩ制御手段８１５にスピーカとマイクを使用
した音声の双方向通信を要求する。これにより端末
（Ｃ）４０１では通信資源の確保とＣＣＢの生成を行な
い、当該通信資源の確保とＣＣＢの生成に成功したなら
ば、次に端末（Ｃ）４０１の通信制御手段８１１は端末
（Ａ）２０１の通信制御手段８１１に音声の双方向通信
を要求することになる。

【０１６９】この要求を受けた端末（Ａ）２０１の通信
制御手段８１１は、スピーカとマイクを使用する音声の
双方向通信のコールに関するＣＣＢの作成を端末（Ａ）
２０１のＣＣ制御手段８１３に要求する。この要求によ
り端末（Ａ）２０１のＣＣ制御手段８１３はスピーカと
マイクの使用が可能であるかを端末（Ａ）２０１の通信
資源管理手段８１２に問合わせる。

【０１７０】端末（Ａ）２０１の通信資源管理手段８１
２は、通信資源管理テーブル（図２１）を参照すること
により、それは既にユーザＡとユーザＢとの間のコール
リファレンス１の通信で使われていることを知る。そし
て、当該通信資源管理手段８１２は端末（Ａ）２０１の
ＣＣ制御手段８１３に対して、先に要求された通信資源
が、コールリファレンス１のコールによって使用されて
いるので要求された通信資源は解放できない旨を通知す
る。

【０１７１】すると端末（Ａ）２０１のＣＣ制御手段８
１３は、端末（Ａ）２０１の通信資源表示手段８１２に
現在の通信資源の種別、使用量と要求されている通信資
源の種別、使用量を表示するように要求する。通信資源
表示手段８１２の表示例を図２３に示す。

【０１７２】図２３の表示をユーザＡは端末（Ａ）２０
１の通信資源表示手段８１２に表示された現在の通信資
源の種別、使用量、要求されている通信資源の種別、使
用量を見ることで、通信資源の割り当てを決定する。

【０１７３】ここでは、ユーザＡは、ユーザＣとの通信
に要求された通信資源を全てユーザＣとの通信に割り当
てることに決めたと仮定する。するとユーザＡは、その
決定内容を端末（Ａ）２０１の割り当て指示手段８１７
に指示する。

【０１７４】割り当て指示手段８１７のヒューマン‐マ
シンインタフェース部を図２４に示す。９０１は、割り
当て指示手段インタフェース部全体である。９０２は、
競合している通信資源の名前を表示するパネルである。

【０１７５】今の場合、スピーカとマイクが端末（Ｃ）
４０１から要求されているので、この二つの入出力装置
がパネル９０２に表示される。９０３は、選択ボタンを
表し、選択したい端末のボタンを押すことで、その端末
に通信資源を割り当てることができる。

【０１７６】９０４は、割り当ての対象になる端末を表
示するパネルである。今の場合は２つの端末間での通信
資源の割り当てを問題にしているが、選択ボタン９０３
と端末表示パネル９０４との組を複数組にすれば、その
数分の端末間での通信資源の割り当てを解決することが
できる。また、本例では端末（Ｃ）４０１から要求され
る通信に通信資源を全て割り当てたが、９０１の割り当
て指示手段インタフェース部に通信資源をどのくらいの
割合で割り当てるかを指示するパネルを付加すれば、任
意の割合で通信資源を通信に割り当てることもできる。

【０１７７】ここでは、端末（Ｃ）４０１に割り当てる
ことにしたので、端末（Ｃ）４０１とパネルに表示され
ている図２４の選択ボタン９０３をユーザＡは押す。す
ると割り当て指示手段８１７はその結果をバス８１９を
経由して割り当て決定手段８１８に通知する。このあと
の流れは、第５の具体例と同様である。

【０１７８】但し、ＣＣＢの作成においては、本例では
優先度の設定は行なわれない。

【０１７９】このように、既に確立している通信によっ
て使用されている通信資源に対して、新たな通信がその
通信資源の使用を要求した場合、どちらの通信に対して
通信資源を割り当てるかをユーザに判断させて指定さ
せ、その指定に基づいて、通信資源を割り当てるように
したので、ユーザサイドに立っての通信ができるように
なり、ユーザの意図しないままに、不意に現在の通信が
切られて新たな通信に切り換えられてしまうといったこ
とを防止できる。

【０１８０】以上、第４ないし第６の具体例は、端末と
通信網で利用可能な通信資源の状態を管理する通信資源
管理手段を設けるようにし、その通信資源管理手段の提
供する通信資源の状態に基づいてコールやコネクション
を制御するコール・コネクション制御手段を設ける構成
としたものである。

【０１８１】また、第１の通信により通信資源の一部又
は全てが確保され使用されている際に、第２の通信の要
求が発生し、第１の通信により確保されている通信資源
の一部、もしくは全部が要求された場合、所定の判定基
準に従って、第１と第２の通信に割り当てる通信資源を
決定する割り当て決定手段を備え、前記割り当て決定手
段の結果に基づき第１と第２の通信を制御するようにし
たものである。

【０１８２】また、上記の割り当て決定手段を備える通
信システムにおいて、現在の通信資源の種別、使用量と
第２の通信により要求されている通信資源の種別、使用
量を表示する手段と、前記表示手段により表示された情
報をもとに端末使用者が通信資源の割り当て量の指示を
前記割り当て決定手段に与える割り当て指示手段とを備
えるようにしたものである。

【０１８３】そしてこのような構成によれば、通信資源
管理手段は端末と通信網で利用可能な通信資源の状態を
管理しており、この通信資源管理手段の提供する通信資
源の状態に基づいて、コール・コネクション制御手段が
通信装置内でコールやコネクションの制御を行なうこと
ができる。これにより端末と通信網で利用可能な通信資
源の状態を考慮したコールやコネクションの制御を行う
ことができ、マルチメディアに対しても柔軟に対応でき
る。また、第１の通信により通信資源の一部又は全部が
確保され使用されている際に、第２の通信の要求が発生
し、第１の通信により確保されている通信資源の一部、
もしくは全部が要求された場合、所定の判定基準に従っ
て、第１と第２の通信に割り当てる通信資源を決定する
割り当て決定手段を通信システム内に設けることによ
り、より重要な通信を優先することができるようにな
る。

【０１８４】また、上記通信システムで現在の通信資源
の種別、使用量と第２の通信に要求されている通信資源
の種別、使用量を表示する表示手段と、前記表示手段の
表示をもとに端末使用者が通信資源の割り当て量の指示
を前記割り当て決定手段に与える割り当て指示手段とを
備えることにより、上記所定の判定基準が特に端末使用
者の意志である場合に対応できるようになる。

【０１８５】ゆえに、第４ないし第６の具体例によれ
ば、端末で利用可能な通信資源や通信網で利用可能な通
信資源を考慮してコールやコネクションを制御できるの
で、ユーザは通信相手の端末で使用可能な資源などを知
らなくても発呼することが出来る。もし相手端末の能力
が低く、発呼の要求に応えられない場合は、その旨が通
知される。また、コール同士で通信資源の競合が起こっ
た時に、何らかの判定基準に従い通信資源の割当を行な
うことにより、重要な、また緊急なコールを優先するこ
とが可能となる。

【０１８６】（第７の具体例）既に説明しているよう
に、あるサービス制御手段（アプリケーション）が、そ
のサービスを実行する際に、他の端末上の資源を必要と
する場合には、当該他の端末において当該資源が他のサ
ービス制御手段等によって占有されていることがある
が、従来の通信システムにおいては、端末資源の空塞は
サービス制御手段にとっては回線の空塞として認識され
るのみであり、端末が保有する個々の資源の空塞状況を
認識することはできなかった。

【０１８７】そこで本件の発明者らは、サービス制御手
段がサービス制御に先だって、他の端末上の資源を制御
しているサービス制御手段または当該資源を管理してい
る資源管理手段に対して資源獲得を要求するための情報
を送信してネゴシエーション（折衝；端末の使用条件を
折衝し、変更する等の処理）を行なう方式を提案した。

【０１８８】図３３にこの提案技術における資源獲得の
手順の一つの例を示す。

【０１８９】サービス制御手段はまず、資源獲得のため
のネゴシエーションを行なうためのコネクションを要求
資源を管理する資源管理手段などとの間に設定し（図３
３中ステップＳ９‐２）、該コネクションを使用して前
記資源管理手段とネゴシエーションを行なう（ステップ
Ｓ９‐３）。ネゴシエーションの結果、要求資源が獲得
できたならば（ステップＳ９‐４でＹＥＳの場合）、ネ
ゴシエーション用のコネクションを解放し（ステップＳ
９‐５）、獲得資源との間に改めて通信コネクションを
設定するなどの手順を行ない（ステップＳ９‐６）、サ
ービスを開始する（ステップＳ９‐７）。ネゴシエーシ
ョンの結果、要求資源が獲得できないならば（ステップ
Ｓ９‐４でＮＯの場合）、ネゴシエーション用のコネク
ションを解放し（ステップＳ９‐８）、サービスを中止
する（ステップＳ９‐９）。

【０１９０】このように、ネゴシエーションにより端末
資源の使用状況を把握し、それに基づいて資源の獲得を
行なうようにすることで、それ以前の通信システムに比
べてより効率的に資源の獲得を行なうことが可能となっ
たが、資源獲得のネゴシエーションを行なうためにネゴ
シエーション用通信コネクションの設定、解放の処理が
必要であった。

【０１９１】また、この技術による資源獲得の手順とし
て、ネゴシエーション用のコネクションを設けずに（コ
ネクションレス通信で）資源を要求する方式も考えられ
るが、その場合でもネゴシエーションの結果設定される
コネクションの設定手順以外に、ネゴシエーションのた
めのメッセージの送受が必要である。

【０１９２】また、例えばレイヤ３のＵＮＩプロトコル
に、ＩＴＵ‐Ｔ（旧ＣＣＩＴＴ）の勧告Ｑ‐２９３１の
手順を用いる従来の通信システムにおいては、通信コネ
クション設定のためのシグナリング・メッセージ中に接
続先端末まで透過的に送達される情報要素として、Broa
dband hign layer情報要素が設けられており、本情報要
素は通信コネクションの設定要素を受けた受信側端末に
おいて当該通信コネクションの接続可否を判定する判断
基準の一つに用いられている。

【０１９３】しかし、その場合の接続可否の判定は、送
受信端末間の整合性の有無という観点でなされるもので
あり、その時々の資源の空塞に基づいてなされるわけで
はない。

【０１９４】このように、計算機端末であるパーソナル
コンピュータやＥＷＳに代表される端末の高機能化、サ
ービスのマルチメディア化が進むにつれ、サービス制御
において音声／画像入出力装置などの端末資源を使用す
る必要性が高まるが、これらの端末資源は、通信サービ
スを提供するサービス制御手段だけでなく、端末上で稼
働する種々のアプリケーションによっても使用されるた
め、サービス制御手段は必ずしもサービスに必要な資源
が使用できるとは限らないため、サービス制御に先だっ
て当該資源の獲得のためのネゴシエーションを行なう必
要がある。

【０１９５】しかし、従来の通信システムにおいてはサ
ービス制御で使用する通信コネクションとは別にネゴシ
エーション用のコネクションを設定する必要があり、ま
た、このようにして設定したコネクションを利用してネ
ゴシエーションを行なった際に資源が獲得できなかった
場合には、後に資源が獲得できるようになった際に、通
知を受けるということにより、無駄に資源の獲得を試み
ることを避けることができるようになるが、この通知を
受けるためにもコネクションを設定する必要があった。

【０１９６】このように、資源獲得のための通信コネク
ションをサービス制御のために使用する通信コネクショ
ン以外に設ける必要があり、資源獲得のための処理が多
くなるという問題点があったが、これを解決し、端末資
源の獲得処理を効率的に実現する例をつぎに述べる。

【０１９７】第７の具体例に係る通信システムのハード
ウェアの構成を図２５に示す。

【０１９８】図２５に示すように、計算機端末１００１
‐１００１〜１‐ｎは通信網１００２を介して相互に接
続されている。前記計算機端末１００１‐１〜１００１
‐ｎには、音声の入出力装置としてマイクロフォン１０
０５、スピーカ１００６が、画像の入出力装置としてカ
メラ１００３、ディスプレイ装置１００４がそれぞれ接
続されている。これらの計算機および各種入出力装置を
用いて、遠隔会議サービスを実現するという場合を例に
とって説明する。

【０１９９】まず、本システム内のソフトウェアの構成
について説明する。

【０２００】図２６に本システム内のソフトウェアの構
成を示す。会議の参加者各自が使用する前記各計算機端
末１００１‐１〜１００１‐ｎはサービス制御手段１０
０７として、会議サービスを実現するプログラム（以降
会議アプリケーションと呼ぶ）が実装されている。これ
らの各種プログラム以外に前記計算機端末１００１‐１
〜１００１‐ｎ上では会議アプリケーション以外のプロ
グラム（以降、これを他アプリケーションと呼ぶ）１０
０８も同時に稼働している。

【０２０１】さらに、前記計算機端末１００１‐１〜１
００１‐ｎのそれぞれには、各種入出力装置やディスク
装置などの資源を管理する端末資源管理手段１００９と
してのプログラム（以降リソースマネージャと呼ぶ）が
稼働している。

【０２０２】図２７にリソースマネージャの構成を示
す。リソースマネージャは、端末資源の使用状況を管理
する機能を有し、リソース使用状況管理手段１０１０
と、どのサービス制御手段からどのようなリソースを要
求されたかを記憶するリソース要求情報記憶手段１０１
１と、要求されたリソースの空塞を判断するための要求
リソース空塞判断手段１０１２とを持つ。

【０２０３】次に、このような構成において、本発明の
主眼であるリソース確保の様子を以下に説明する。図２
９〜図３０に会議アプリケーションがリソースを獲得し
てサービスを開始するまでの処理の流れを示す。図２９
は会議アプリケーションの処理の流れを示す図であり、
図３０はリソースマネージャの処理の流れを示す図であ
る。

【０２０４】まず、計算機端末１００１‐１〜１００１
‐ｎのうちのいずれかの計算機端末において会議アプリ
ケーションが起動される（図２９中ステップＳ５‐
１）。起動された会議アプリケーションは、通信路（ネ
ットワーク１００２）を介して接続された会議に参加す
る参加者の計算機端末を接続するための通信コネクショ
ンと、会議に使用する各種入出力装置とを獲得しようと
する。

【０２０５】ここでは、ある計算機端末上の会議アプリ
ケーションが他計算機端末上の資源、例えばスピーカに
対してコネクションを設定する場合を例にとって説明す
る。

【０２０６】遠隔会議に必要な他の端末資源との接続に
関しても手順は同様であり、各計算機端末間に音声、画
像それぞれの入出力装置間（マイクロフォンとスピー
カ、カメラとディスプレイ装置）にコネクションを設定
することにより遠隔会議サービスに必要な通信環境を設
定する。

【０２０７】また、遠隔会議サービスの実現には端末資
源だけでなく、網資源（帯域など）も必要であるが、こ
こでは端末資源の獲得に関する側面のみについて説明す
る。網資源に関しても例えば網資源の制御が可能な計算
機端末上に網資源の管理を行なうリソースマネージャを
設けることにより、同様の手順を適用して資源獲得を行
なうことが可能である。

【０２０８】なお、ここでは、コネクションを設定する
ためのシグナリング・プロトコルとしてＩＴＵ‐Ｔ（旧
ＣＣＩＴＴ）のレイヤ３ＵＮＩに関する勧告Ｑ‐２９３
１を仮定する。

【０２０９】（１）［要求資源が空きの場合］ 図３１に会議アプリケーションが資源を要求する場合の
シグナリング・シーケンスを示す。シグナリング・メッ
セージを実際に送受するのは送受信端末上およびネット
ワーク内にそれぞれ存在するシクナリング・エンティテ
ィであるが、図３１ではシグナリング・メッセージ中の
ネゴシエーション情報の送受に主眼をおいて説明するた
め、シグナリング・メッセージの送受する主体を会議ア
プリケーション、ネットワーク、リソースマネージャと
表示している。図３２に示すシグナリング・シーケンス
に関しても同様である。

【０２１０】会議アプリケーションは、会議相手端末お
よびその上の音声、画像などの入出力装置の一つ（ここ
ではスピーカ）を選び、まず自計算機端末上のシクナリ
ング・エンティティに依頼して、前記会議相手端末上の
リソースマネージャに宛てて必要な帯域をもったコネク
ションの設定を開始するためのシグナリング・メッセー
ジＳＥＴＵＰを送信する（図３２中メッセージｍ８‐
１、図２９中ステップＳ５‐２）。ＳＥＴＵＰメッセー
ジ中のBroadband high layer information情報要素に設
定された情報は網内のシクナリング・エンティティを介
して通信相手端末のエンティティにまで透過的に送達さ
れるので、本フィールドを必要資源獲得のためのネゴシ
エーションに用いる。ここでは、Broadband high layer
information情報要素（以降Ｂ‐ＨＬＩ情報要素と記
す）に次の各情報を設定する。

【０２１１】・要求ｉｄ ：同一サービス制御手段にも
たらされる複数の資源要求を識別するための識別子 ・要求資源ｉｄ ：当該コネクションを介して接続する
相手端末上の資源を表す識別子 ・空き待ち要求スイッチ ：要求資源が塞がりの場合に
空き待ちを希望するか否かを示す２値的な値（ＯＮ／Ｏ
ＦＦ） 上述の要求ｉｄは、サービス要求元のサービス制御手段
（会議アプリケーション）とリソースマネージャとの間
で一意に識別できるような識別子であればよく、例えば
会議アプリケーションの識別子と要求を発した時刻とを
組み合わせた値などとする方法が考えられる。また、こ
こでは要求資源ｉｄには音声出力装置（スピーカ）を表
す”audio-out ”を、空き待ち要求スイッチには空き待
ちを要求することを表す”ＯＮ”をそれぞれ設定するも
のとする。

【０２１２】相手端末上のリソースマネージャはシグナ
リング・エンティティから、前記Ｂ‐ＨＬＩ情報要素に
設定された情報を受けとり（図３０中ステップＳ６‐
１）、要求ｉｄ、要求資源ｉｄおよび空き待ち要求スイ
ッチの値をリソース要求情報記憶手段に記憶し（ステッ
プＳ６‐２）、記憶されたリソースの空塞を要求リソー
ス空塞判断手段により判断する（ステップＳ６‐３）。

【０２１３】リソース要求情報記憶手段は、要求された
リソースが塞がりの場合に、空き待ちを行なう際に使用
するテーブルであり、その構成を図２８に示す。要求リ
ソース空塞判断手段は、要求された資源（スピーカ）が
他アプリケーションなどによって占有されていないかど
うかを調べ、その結果、当該資源（スピーカ）が使用可
能であれば（ステップＳ６‐３で空きの場合）、以降の
コネクション設定手順において当該資源（スピーカを駆
動するためのプログラム）と接続するコネクションの設
定を行なう（図３０中ステップＳ６‐４、図３１中メッ
セージｍ７‐２およびそれ以降、図２９中ステップＳ５
‐４およびＳ５‐５）。

【０２１４】（２）［要求資源が塞がりの場合］ 次に、要求した資源が塞がりであった場合の処理につい
て説明する。上述の要求資源が空きの場合と同様に、ま
ず会議アプリケーションは自計算機端末上のシグナリン
グ・エンティティに依頼して、会議相手端末上のスピー
カ（を駆動するプログラム）に対して必要な帯域を持っ
たコネクションの設定を開始するためのシグナリング・
メッセージＳＥＴＵＰを、相手端末上のスピーカを管理
するリソースマネージャに宛てて送信する（図２９中ス
テップＳ５‐２、図３２中メッセージｍ８‐１）。

【０２１５】メッセージＳＥＴＵＰのＢ‐ＨＬＩ情報要
素には先の説明と同様に要求する資源を表す情報が設定
される。相手端末上のリソースマネージャはシグナリン
グ・エンティティから前記Ｂ‐ＨＬＩ情報要素に設定さ
れた情報を受けとり（図３０中ステップＳ６‐１）、要
求ｉｄ、要求資源および空き待ちスイッチの値をリソー
ス要求情報記憶手段に記憶し（ステップＳ６‐２）、記
憶されたリソースの空塞を要求リソース空塞判断手段に
より判断する（ステップＳ６‐３）。

【０２１６】要求リソース空塞判断手段が要求資源（ス
ピーカ）の空塞を判断した結果、当該資源が使用不可能
な場合（ステップＳ６‐３で塞がりの場合）、リソース
マネージャはシグナリング・エンティティに依頼して、
当該コネクション設定手順を中止すべく、ＲＥＬＥＡＳ
Ｅ ＣＯＭＰＬＥＴＥメッセージを送信し、以降当該コ
ネクションの解消手順を実行する（ステップＳ６‐５、
メッセージｍ８‐２）。

【０２１７】この際、資源要求元サービス制御手順から
のＳＥＴＵＰメッセージにおける空き待ち要求スイッチ
の値が”ＯＦＦ”である場合には（ステップＳ６‐６で
ＯＦＦの場合）、リソース要求情報記憶手段の該当資源
のエントリを削除し（ステップＳ６‐１０）、本要求資
源に関する処理を終了する（ステップＳ６‐１１）。

【０２１８】リソースマネージャは前記リソース要求情
報記憶手段に削除されずに残っている資源（本実施例の
場合のスピーカ）については空き待ちを行ない（ステッ
プＳ６‐７）、これらの資源の空きを検知した場合（ス
テップＳ６‐８でＹＥＳの場合）には、シグナリング・
エンティティに依頼してシグナリング・メッセージＳＥ
ＴＵＰを用いて前記要求元サービス制御手段に資源の空
きを通知する（ステップＳ６‐９、メッセージｍ８‐
３）。

【０２１９】この場合のＳＥＴＵＰメッセージ中のＢ‐
ＨＬＩ情報要求フィールドには、前記リソース要求情報
記憶手段から得た要求ｉｄ、資源ｉｄおよび空き待ち応
答であることを表す値を設定する。

【０２２０】この後、リソースマネージャは、リソース
要求情報記憶手段中の当該リソースに関するエントリを
削除した後（ステップＳ６‐１０）、当該資源に関する
処理を終了する（ステップＳ６‐１１）。

【０２２１】一方、リソースマネージャから要求資源の
空きを自計算機端末のシクナリング・エンティティを介
して受信した資源要求元の会議アプリケーションは、Ｂ
‐ＨＬＩ情報要素の空き待ち応答を表す値および要求ｉ
ｄを参照することにより、空き待ちを要求していた資源
（スピーカ）に対する空き通知を受信したことを認識し
（ステップＳ５‐９でＹＥＳの場合）、シグナリング・
エンティティに依頼して一旦そのＳＥＴＵＰに対しては
ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッセージで応答し
た後、改めてＳＥＴＵＰメッセージによりコネクション
の設定を開始する（ステップＳ５‐２）。

【０２２２】このコネクションの設定開始以降の手順は
会議アプリケーション起動時と同様の手順である。

【０２２３】以上のようにしてサービス制御に使用する
端末資源の要求をシグナリング手順を実施する中で行な
えるので（図２９中のステップＳ５‐１０）、資源獲得
のネゴシエーションのために別途コネクションを設定す
ることなく、端末資源個別にその空塞状況を知ることが
できる。また、要求資源が塞がりの場合には空き待ちも
行なうこともできるため、端末資源を利用率の向上が期
待できる。

【０２２４】このように、第７の具体例は、通信網の資
源または通信網に接続された機器の資源を制御してサー
ビスを実現するサービス制御手段を有する通信システム
において、サービス制御手段が、サービス制御に必要な
資源を表す情報を、通信コネクション設定の際のシグナ
リング・メッセージ内に設定することにより、他のサー
ビス制御手段または資源管理手段に宛てて送信し、該情
報を受信したサービス制御手段または資源管理手段は、
要求された資源を前記要求元サービス制御手段に割り当
てるかどうかを判断し、割り当てると判断した場合には
要求された資源を要求元ービス制御手段に割り当てて前
記通信コネクション設定手順を引続き行ない、割り当て
ないと判断した場合は、前記通信コネクションの設定を
中止するようにしたものであり、また、更には資源要求
元サービス制御手段から要求された資源を割り当てない
と判断した場合にはサービス制御手段または資源管理手
段はその後、前記要求資源を割り当てると判断したとき
に、割り当て可能であることを前記要求元サービス制御
手段との通信コネクション設定のためのシグナリング・
メッセージに設定することにより要求元サービス制御手
段に通知するようにしたものである。

【０２２５】そして、このようなシステムにおいては、
サービス制御に必要な資源を表す情報を、通信コネクシ
ョン設定の際のシグナリング・メッセージ内に設定して
他のサービス制御手段または資源管理手段に宛てて要求
し、該情報を受信したサービス制御手段または資源管理
手段が、前記要求資源を前記要求元サービス制御手段に
割り当てるかどうかを判断し、その判断結果を通信コネ
クション設定のためのシグナリング・メッセージ内に設
定して応答することにより、資源要求元サービス手段が
他端末上の資源の空塞状況を効率的に把握することを可
能としたものである。

【０２２６】また、サービス制御手段からの要求資源が
塞がりであった場合に、必要に応じて、当該資源の要求
を受けた前記サービス制御手段または資源管理手段が当
該資源の空きを、シグナリング・メッセージを用いて前
記要求元サービス制御手段に通知することにより、通信
コネクションを確立することなく空き通知が行なうこと
ができるため、一度資源の獲得に失敗したサービス制御
手段が効率的に資源を獲得することが可能となって、資
源の利用効率の向上が期待できるものである。

【０２２７】特に本例によれば、通信システムにおい
て、あるアプリケーションが必要とする他端末リソース
が他のアプリケーションにより確保されているかどうか
を、当該リソースへのコネクション設定時点で検知する
ことができ、リソース獲得のための手順を網リソース獲
得のためのシグナリング手順の中で行なうことができ、
また、要求資源の塞がり時には空き待ちを行なうことも
できるため、従来のようにネゴシエーションや空き通知
のために別途コネクションを設ける必要がなく、効率的
にリソースの獲得処理を実現することができる。

【０２２８】

【発明の効果】以上、詳述したように本発明によれば、
実質的に使用を終え、解放され得る資源が解放されない
ことによって当該資源を必要とする別のサービスの実現
を阻害するという問題を解決することができるようにな
る。

【０２２９】また、通信システムにおいて、あるアプリ
ケーションが必要とする他端末リソースが他のアプリケ
ーションにより確保されているかどうかを、当該リソー
スへのコネクション設定時点で検知することができ、リ
ソース獲得のための手順を網リソース獲得のためのシグ
ナリング手順の中で行なうことができ、また、要求資源
の塞がり時には空き待ちを行なうこともできるため、従
来のようにネゴシエーションや空き通知のために別途コ
ネクションを設ける必要がなく、効率的にリソースの獲
得処理を実現することができるようになる。

【図面の簡単な説明】

【図１】本発明の説明をするための図であって、本発明
の第１の具体例を示す図。

【図２】本発明の説明をするための図であって、本発明
の第１の具体例における資源管理手段の構成を表す図。

【図３】本発明の説明をするための図であって、本発明
の第１の具体例におけるサービス制御手段の処理を表す
図。

【図４】本発明の説明をするための図であって、本発明
の第２の具体例を表す図。

【図５】本発明の説明をするための図であって、本発明
の第２の具体例におけるサービス制御手段の構成を表す
図。

【図６】本発明の説明をするための図であって、本発明
の第２の具体例におけるサービス制御手段の処理を表す
図。

【図７】本発明の説明をするための図であって、本発明
の第３の具体例を表す図。

【図８】従来の通信システムにおける資源獲得のための
処理を表す図。

【図９】本発明の説明をするための図であって、本発明
の第４の具体例を説明するためのシステム構成図。

【図１０】本発明の説明をするための図であって、本発
明における端末（Ａ）の構成例を示す図。

【図１１】本発明の説明をするための図であって、本発
明の作用を説明するためのフロー図。

【図１２】本発明の説明をするための図であって、本発
明において使用する通信資源管理テーブル例を示す図。

【図１３】本発明の説明をするための図であって、本発
明の第４の具体例において使用するＣＣＢフォーマット
図。

【図１４】本発明の説明をするための図であって、本発
明の第４の具体例において使用する端末（Ａ）のＣＣＢ
の例を示す図。

【図１５】本発明の説明をするための図であって、変更
後の通信資源管理テーブルの例を示す図。

【図１６】本発明の説明をするための図であって、本発
明の第５の具体例において使用する端末の構成例を示す
図。

【図１７】本発明の説明をするための図であって、本発
明の第５の具体例において使用するＣＣＢのフォーマッ
ト例を示す図。

【図１８】本発明の説明をするための図であって、本発
明の第５の具体例において使用する端末（Ａ）のＣＣＢ
の例を示す図。

【図１９】本発明の説明をするための図であって、本発
明の第５の具体例において使用する端末（Ａ）の通信資
源管理テーブルの例を示す図。

【図２０】本発明の説明をするための図であって、本発
明の第６の具体例において使用する端末の構成例を示す
図。

【図２１】本発明の説明をするための図であって、本発
明の第６の具体例において使用する端末（Ａ）の通信資
源管理テーブル例を示す図。

【図２２】本発明の説明をするための図であって、本発
明の第６の具体例において使用する端末（Ａ）のＣＣＢ
の例を示す図。

【図２３】本発明の説明をするための図であって、本発
明の第６の具体例において使用する通信資源表示例。

【図２４】本発明の説明をするための図であって、本発
明の第６の具体例において使用する割り当て指示手段イ
ンタフェース例を示す図。

【図２５】本発明の説明をするための図であって、本発
明の第７の具体例における通信システムのハードウェア
構成例を示す図。

【図２６】本発明の説明をするための図であって、本発
明の第７の具体例における通信システムのソフトウェア
構成を表す図。

【図２７】本発明の説明をするための図であって、本発
明の第７の具体例におけるリソースマネージャの構成を
表す図。

【図２８】本発明の説明をするための図であって、本発
明の第７の具体例におけるリソース要求情報記憶手段を
示す図。

【図２９】本発明の説明をするための図であって、本発
明の第７の具体例における会議アプリケーションの資源
獲得処理の流れを表す図。

【図３０】本発明の説明をするための図であって、本発
明の第７の具体例におけるリソースマネージャの処理の
流れを表す図。

【図３１】本発明の説明をするための図であって、本発
明の第７の具体例におけるシグナリング・メッセージの
送信シーケンスを表す図（資源が空きの場合）。

【図３２】本発明の説明をするための図であって、本発
明の第７の具体例におけるシグナリング・メッセージの
送信シーケンスを表す図（資源が塞がりの場合）。

【図３３】従来技術を説明をするための図であって、第
７の具体例における前提となる従来方式でのサービス制
御手段の資源獲得処理の流れを表す図。

【符号の説明】

１‐１〜１‐ｎ…計算機 ２…通信路 ３…サービス制御手段 ４…端末資源管理手段 ５…網資源管理手段 ６…画像入力手段 ７…画像出力手段 ８…音声入力手段 ９…音声出力手段 １０…資源要求情報保持手段 １１…要求資源空塞判断手段 １２…解放要求先サービス制御手段決定手段 １３…資源使用状況管理手段 １４…資源獲得・解放手段 １５…資源制御手段 １０１…ネットワーク、 ２０１…端末（Ａ） ２０２，３０２…ディスプレイ ２０３，３０３，４０３…スピーカ ２０４，３０４，４０４…マイクロフォン ３０１…端末（Ｂ） ４０１…端末（Ｃ） ４０２…ビデオ再生装置 ２１１…通信制御手段 ２１２…入出力装置制御手段 ２１３，６１４，８１３…通信資源管理手段 ２１４，６１５，８１２…ＣＣ制御手段（コール・コン
トロール制御手段） ２１５…ＨＭＩ制御手段 ２１６，６１７，８１９…バス ５０１…コールリファレンス書き込みフィールド ５０２…通信相手書き込みフィールド ５０３…通信資源書き込みフィールド ６１１，８１１…通信制御手段 ６１２…割り当て決定手段 ６１３…入出力装置制御手段 ６１６，８１５…ＨＭＩ制御手段 ７０１…コールリファレンス書き込みフィールド ７０２…通信相手書き込みフィールド ７０３…通信資源書き込みフィールド ７０４…優先度書き込みフィールド ８１４…入出力装置制御手段 ８１６…通信資源表示手段 ８１７…割り当て指示手段 ８１８…割り当て決定手段 ９０１…割り当て指示手段インタフェース ９０２…競合通信資源表示パネル ９０３…選択ボタン ９０４…端末表示パネル。 １００１‐１〜‐１００１‐ｎ…計算機 １００２…通信路（ネットワーク） １００３…画像入力装置 １００４…画像出力装置 １００５…音声入力装置 １００６…音声出力装置 １００７…会議アプリケーション １００８…他アプリケーション １００９…リソースマネージャ １０１０…リソース使用状況管理手段 １０１１…リソース要求情報記憶手段 １０１２…要求リソース空塞判断手段

───────────────────────────────────────────────────── フロントページの続き (72)発明者 木村 成人 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 伊藤 隆治 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内

Claims (4)

【特許請求の範囲】
1. 【請求項１】 各種資源を備えた複数の端末を通信網に
   接続し、この通信網の資源または通信網に接続された端
   末の各種資源を使用してサービスを提供する複数のサー
   ビス制御手段を有し、サービス制御手段によるサービス
   提供にあたっては前記各種資源のうち、そのサービス提
   供に必要な資源を確保して実施する通信システムにおい
   て、 実施させようとする所望のサービスを提供するサービス
   制御手段が必要とする資源が、他のサービス制御手段に
   より確保されて利用できない場合に、その資源の予約を
   する手段と、 資源の使用状態を管理する管理手段と、 この管理手段の情報をもとに、前記予約した資源が解放
   されると、前記実施させようとする所望のサービスを提
   供するサービス制御手段にその解放を通知する手段と、
   を具備したことを特徴とする通信システム。
2. 【請求項２】 各種資源を備えた複数の端末を通信網に
   接続し、この通信網の資源または通信網に接続された端
   末の各種資源を使用してサービスを提供する複数のサー
   ビス制御手段を有し、サービス制御手段によるサービス
   提供にあたっては前記各種資源のうち、そのサービス提
   供に必要な資源を確保して実施する通信システムにおい
   て、 実施させようとする所望のサービスを提供するサービス
   制御手段が必要とする資源が、他のサービス制御手段に
   より確保されて利用できない場合に、その資源の解放を
   要求する手段と、 この要求に応じて資源を解放する手段と、を具備したこ
   とを特徴とする通信システム。
3. 【請求項３】 各種資源を備えた複数の端末を通信網に
   接続し、この通信網の資源または通信網に接続された端
   末の各種資源を使用してサービスを提供する複数のサー
   ビス制御手段を有し、サービス制御手段によるサービス
   提供にあたっては前記各種資源のうち、そのサービス提
   供に必要な資源を確保して実施する通信システムにおい
   て、 実施させようとする所望のサービスを提供するサービス
   制御手段が必要とする資源を通知すると共に優先度を通
   知する手段と、 前記実施させようとする所望のサービスを提供するサー
   ビス制御手段が必要とする資源を既に確保している他の
   サービス制御手段があるとき、通知されている互いの前
   記優先度を比較してその資源を既に確保している前記他
   のサービス制御手段の優先度が低い場合に、その資源の
   解放を実施させる手段と、を具備したことを特徴とする
   通信システム。
4. 【請求項４】 通信網の資源または通信網に接続された
   機器の資源を制御してサービスを実現するサービス制御
   手段を有する通信システムにおいて、 資源の使用状態を管理する管理手段と、 利用しようとする前記サービス制御手段において、その
   サービス制御に必要な資源を表す情報を要求資源情報と
   して通信コネクション設定の際のシグナリング・メッセ
   ージ内に設定して送信する手段と、 シグナリング・メッセージ内の前記要求資源情報から要
   求のある資源を知り、前記利用しようとするサービス制
   御手段に、この資源を割り当てることの可否を判断する
   手段と、 前記判断結果が可の場合には前記設定中の通信コネクシ
   ョンの接続先を前記要求資源として該通信コネクション
   の設定手順を引続き実行し、否の場合には、前記通信コ
   ネクションの設定を中止すべく制御する手段と、を具備
   することを特徴とする通信システム。