JP4086259B2 - 通信システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、端末またはネットワーク上の資源を使用して各種のサービスを提供する通信システムに関する。
【０００２】
【従来の技術】
コンピュータシステムの技術と通信技術、そして、マルチメディア技術の発展に伴い、コンピュータ通信の分野でも単なるデータ通信にとどまらず、音声、画像（動画や静止画）などの様々なメディアを利用した通信をすることができるようになった。但し、自己が利用しようとする各メディアを、相手側でも利用可能である必要があるが、そこで問題になるのは、通信するに際して、通信の要求元である自己側が利用しようとする各メディアの利用を可能にする資源（ハードウエア資源やそれを稼動させるためのソフトウェア資源など）を、相手側も有していて、しかもそれが利用可能な状態になっているか否かが、要求元からは把握できないということである。
【０００３】
従来の通信システムにおけるサービス起動要求からサービス起動までの処理の流れを図８に示す。
【０００４】
コンピュータを利用する通信システムにおいては、通信網の資源または通信網に接続された機器の資源を制御してサービスを実現するサービス制御手段と、網リソースを管理する網リソース管理手段を有する。
【０００５】
あるサービスを対象としたサービス起動要求があると（ステップＳ８‐１）、この通信システム内のサービス制御手段は、そのサービス実現の際に必要な資源を獲得する必要があるので、網リソース管理手段にその対象サービスに必要な網リソースの獲得要求を出す（ステップＳ８‐２）。そして、網リソース管理手段がその対象サービスに必要な網リソースの獲得ができたか、否かを調べ（ステップＳ８‐３）、獲得できていればサービスの起動を行ない（ステップＳ８‐５）、そのサービスを可能にする。しかし、必要な網リソースの獲得ができていない場合、不可能であればサービス起動不可を利用者に通知する（ステップＳ８‐６）。
【０００６】
つまり、従来の通信システムにおいては、サービス要求元において、そのサービスを実現するに必要な網資源についての空塞を知ることしかできないために、サービス要求元においては取り敢えず、目的のサービス起動要求を行なってみる。
【０００７】
サービス起動要求を行なった結果、必要な網資源も獲得できない場合には、サービスの起動ができないので、その旨をユーザに通知するなどして知らせ（ステップＳ８‐６）、これによりユーザは今は目的のサービスの起動ができないことを知り、一旦、諦める。そして、ユーザが必要に応じて頃合をみて再度サービスの起動要求を出すといった具合に、行き当たりばったりの起動制御を行なうものであった。
【０００８】
【発明が解決しようとする課題】
このように、従来の通信システムにおいてはサービス起動要求時にサービス制御手段が必要な資源を獲得できない場合には、例えばユーザが必要に応じて時間をおいて再度サービスの起動要求を出すということが行われていたが、再び起動要求を出した際に必要な資源を獲得できるとは限らないため、資源の獲得に成功するまで何度も起動要求を出さねばならないこともあるという問題点があった。
【０００９】
これは、相手が直接的に見えないだけに、使い勝手を悪くし、ユーザに対するサービス低下を招く大きな要因となっている。
【００１０】
また従来の通信システムにおいては、サービス起動要求時に、サービス制御手段が必要な資源を獲得できないという場合に、その獲得できない要因としてその資源を実際にユーザが使用中の状態である場合だけでなく、ユーザがその資源の使用を実質的には終えているものの、サービス制御手段が解放処理を行っていないために獲得できないという場合も含まれている。これは事実上、その資源を殺しているに等しい。
【００１１】
そのため、たとえ、あるサービス制御手段が資源の獲得を要求した時点で実際にはユーザがその資源を使用していない場合でも、その資源を解放していないばかりに、そのサービス制御手段はサービス内容を縮小変更して獲得可能な資源のみによりサービスを実現するようにするか、サービスの実現を中止するかしなければならず、サービス低下に繋がるという問題点がある。
【００１２】
例えばこのようなサービス制御手段が計算機上のアプリケーションプログラムとして実現されている場合はユーザがそのアプリケーションプログラムの利用を実質的には終えているがアプリケーションプログラムを終了させていないために、資源が解放されないということは実際にはよく生じることである。
【００１３】
そこで、この発明の目的とするところは、上述のような、実質的に使用を終え、解放され得る資源が解放されないことによって当該資源を必要とするサービスの実現を阻害するという問題を解決することができる通信システムを提供することにある。
【００１４】
【課題を解決するための手段】
本発明は、通信網の帯域及び当該通信網に接続された複数の端末のそれぞれが有する各種資源を使用して異なる複数のサービスをそれぞれ提供する複数のサービス制御手段と、前記帯域の使用状況を管理する網資源管理手段とを備えた通信システムにおいて、前記複数のサービス制御手段のそれぞれは、当該サービス制御手段が確保している前記帯域及び前記端末資源に対し、他のサービス制御手段のための前記帯域及び端末資源の解放要求を受けたとき、（１）要求された帯域・端末資源を解放しても予め設定されたサービス品質の許容範囲を満たす場合、（２）要求された帯域・端末資源の解放の可否をユーザに尋ねる情報を表示し、ユーザからの当該帯域・端末資源の解放が許可された場合、（３）前記他のサービス制御手段の優先順位が当該サービス制御手段の優先順位よりも高い場合、（４）要求された帯域・端末資源を一定時間使用していない場合、（５）ユーザにより予め解放要求の受付を受け付ける旨の設定がされている場合、のうちのいずれか１つに該当するときには、要求された前記帯域及び前記端末資源を解放して前記他のサービス制御手段のために割り当てられる状態にする資源解放手段を備え、前記網資源管理手段は、前記他のサービス制御手段から、そのサービスを提供するために必要とする前記帯域の獲得要求を受けて、前記通信網の使用状況から、要求された前記帯域を確保できるか否かを判定する手段と、要求された前記帯域を確保できるときは、確保要求元のサービス制御手段のために、前記帯域を確保し、前記他のサービス制御手段に端末資源の獲得要求を送信する手段と、要求された前記帯域を確保できないときは、前記通信網を現在確保しているサービス制御手段のなかから、最近一定期間の前記通信網上でのトラヒックの無いサービス制御手段を選択して、選択されたサービス制御手段に対し前記通信網上の帯域の解放要求を送信する手段と、を備えたことを特徴とする。
【００２６】
【発明の実施の形態】
本発明は、通信網の資源または通信網に接続された機器の資源を制御してサービスを実現する複数のサービス制御手段を有する通信システムにおいて、前記通信網の資源または前記通信網に接続された機器の資源の使用状況を管理する資源管理手段と、前記サービス制御手段間またはサービス制御手段と前記資源管理手段との間に通信手段とを設け、起動しようとするサービス制御手段が、前記通信手段を用いて他のサービス制御手段または資源管理手段に対してサービスに必要な資源を表す情報を送信し、該情報を受信した資源管理手段は、サービスに必要な資源が既に他のサービス制御手段に割り当てられているときは、その資源の予約を行ない、その資源が解放されたときに前記起動しようとするサービス制御手段に通知して再起動させ、その資源を利用してのサービスを実施を可能にする。
【００２７】
また、通信網の資源または通信網に接続された機器の資源を制御してサービスを実現する複数のサービス制御手段を有する通信システムにおいて、前記通信網の資源または前記通信網に接続された機器の資源の使用状況を管理する資源管理手段と、前記サービス制御手段間またはサービス制御手段と前記資源管理手段との間に通信手段とを設け、サービス制御手段が、前記通信手段を用いて他のサービス制御手段または資源管理手段に対してサービスに必要な資源を表す情報を送信し、該情報を受信したサービス制御手段または資源管理手段は、要求された資源を前記要求元サービス制御手段に割り当てるかどうかを判断し、割り当てると判断した場合には要求された資源を要求元サービス制御手段に割り当ててその旨を要求元サービス制御手段に通知し、割り当てないと判断した場合には、要求された資源を割り当てない旨を要求元サービス制御手段に通知し、以降当該要求資源を割り当てると判断したときに、該資源を要求している前記サービス制御手段に該資源の割り当てを通知する構成とする。
【００２８】
また、サービス制御手段に、要求した資源が割り当てられないという通知を受けた場合に、当該資源を占有しているサービス制御手段の中のひとつまたは複数のサービス制御手段を、資源の割り当てを要求する要求先として選択するための資源要求先サービス制御手段決定手段を設け、サービス制御手段は、要求先サービス制御手段から要求した資源が割り当てられないという通知を受けた場合には、前記資源要求先サービス制御手段決定手段によりサービス制御手段を選択し、選択されたサービス制御手段に対して、前記通信手段を用いて資源を要求する情報を送信するようにする。
【００２９】
以下、より具体的に本発明を説明する。以下の例では、サービス要求元から資源の状態を調べて、必要により資源を解放させ、利用できるようにして目的のサービスを円滑に利用できるようにした例を説明する。
【００３０】
（第１の具体例）
図１に本発明の第１の具体例を示す。ここでは図に示すように、計算機（パーソナルコンピュータやワークステーションなど）１‐１〜１‐ｎが通信路２を介して相互に接続されており、前記計算機１‐１〜１‐ｎにはそれぞれ、音声の入出力装置としてマイクロフォン８とスピーカ９が接続され、また、画像の入出力装置としてカメラ（テレビカメラもしくは電子スチルカメラなどの撮像装置）６とディスプレイ装置７が接続されている。
【００３１】
これらの数台の計算機および各種入出力装置を用いて会議サービスを実現する場合の例について説明する。
【００３２】
前記計算機のうちの一つには、サービス制御手段３として会議サービスを実現するプログラム（以降会議アプリケーションと呼ぶ）が実装されており、さらに、前記計算機１‐１〜１‐ｎのそれぞれには各種入出力装置やディスク装置などの資源を管理する端末資源管理手段４としてのプログラム（以降端末リソースマネージャと呼ぶ）があってこれらが稼働し、前記計算機１‐１〜１‐ｎのうちのいずれかには網資源管理手段５として前記各計算機を結ぶ通信路の帯域の使用状況を管理するプログラム（以下、これを網リソースマネージャと呼ぶ）があってこれが稼働している。
【００３３】
［リソースマネージャの構成］
図２にこれらリソースマネージャの構成を示す。
リソースマネージャは、リソースの使用状況を管理する資源使用状況管理手段１３と、どのサービス制御手段からどのようなリソースを要求されたかを記憶する資源要求情報保持手段１０と、要求されたリソースの空塞を判断するための要求資源空塞判断手段１１とを持つ。リソースには、端末リソースにおける音声／画像の各入出力装置のようにその空塞が明確なものもあれば、網リソースにおける帯域のように使用量が変動し、空塞（空き／塞がり）が明確でないものもある。
【００３４】
このように空塞が明確でないリソースの空塞判断手段（要求資源空塞判断手段１１）の実現方法としては、例えば、過去一定期間の空きリソース量の最小値が、要求リソース量よりあるマージン以上大きい場合に、“空き”と判断するという方法が考えられる。
【００３５】
なお、これらの各種プログラム以外に、前記計算機上では会議サーバ以外のプログラム（以下、これを他アプリケーションと呼ぶ）も同時に稼働している。これら会議アプリケーションとリソースマネージャ、他アプリケーションは通信路を介して相互に情報をやりとりすることができる。
【００３６】
［会議サービス実現時のリソース確保］
このような構成において、会議サービス実現時のリソース確保の様子を以下に説明する。図３に会議アプリケーションがリソースを獲得してサービスを開始するまでの処理の流れを示す。
【００３７】
図３に沿って説明する。通信路２に計算機１‐１〜１‐ｎが繋がっていてコンピュ−タネットワークを構成しており、互いの計算機１‐１〜１‐ｎは相互に通信可能なシステムとなっている。
【００３８】
まず、計算機１‐１〜１‐ｎのうち、いずれかの計算機（起動要求元計算機）においてサービス制御手段としての会議アプリケーションが起動される（図中ステップＳ３‐１）。
【００３９】
起動要求元計算機内の起動された会議アプリケーションは、通信路２を介して接続された会議に参加する参加者の計算機（接続対象計算機）を接続するために必要な帯域をもった通信路と、会議に使用する各種入出力装置とを獲得するために、網リソースマネージャに前記通信路の帯域を確保が可能か否かを問い合わせ、また、各計算機の端末リソースマネージャに前記各種入出力装置の使用状況を問い合わせる（ステップ３‐２）。これにより、各リソースマネージャは要求されたリソースが何であるかを資源要求情報記憶手段１０に記憶し、記憶されたリソースの空塞を要求資源空塞判断手段１１により判断する。
【００４０】
端末リソースマネージャおよび網リソースマネージャは、要求リソースそれぞれについてその空塞を判断した結果、すべてのリソースが使用可能であれば（ステップＳ３‐３でｙｅｓの場合）、前記各種リソースマネージャを介してリソースを確保し、確保したリソースを制御して参加計算機の会議アプリケーションを起動させ、会議サービスを実現し（ステップＳ３‐８）、会議が終了すれば前記各種リソースマネージャを介してリソースを解放することにより、会議サービスを終了する。
【００４１】
ここでは本発明の主眼である、会議アプリケーションが会議サービスに必要なリソースのうちの一部または全てが他アプリケーションに使用されているなどの理由で獲得できなかった場合の処理について説明する。なお、この第１の具体例においては、会議サービスに必要なリソースのうち、端末リソースの一部が他アプリケーションに使用されていることにより、獲得できない場合を例にとって説明する。
【００４２】
起動要求元計算機の会議アプリケーションが起動されると（ステップＳ３‐１）、各参加計算機に接続された音声および画像の入出力装置間で音声および画像情報を送受するために必要な帯域を持った通信路を獲得するために、起動要求元計算機から前記網リソースマネージャ（網資源管理手段５）に通信路の獲得要求を送信する（ステップＳ３‐２）。
【００４３】
網リソースマネージャは、リソース要求情報記憶手段（資源要求情報保持手段）１０に要求リソース（この場合、通信路と帯域とを表す情報）を記憶させ、要求資源空塞判断手段１０により、要求された通信路リソースの空塞を判断させる。
【００４４】
その結果、“空き”と判断されれば、網リソースマネージャは、要求した会議アプリケーションの使用のために、該通信路リソースを確保する。また、起動要求元計算機の前記会議アプリケーションは、会議に使用する各計算機に接続された音声および画像の入出力装置とを獲得するために、各会議参加計算機の端末リソースマネージャに入出力装置の獲得要求を送信する。
【００４５】
一方、各会議参加計算機の端末リソースマネージャは、要求された端末リソース（入出力装置）を資源要求情報記憶手段１０に記憶させ、要求資源空塞判断手段１１により要求リソースの空塞を判断させる。その結果、要求された端末リソースが“空き”であればその会議参加計算機の端末リソースマネージャは、要求した会議アプリケーションの使用のために該端末リソースを確保するが、ここで端末リソースとして、会議参加計算機のうちの例えばある計算機に接続されているカメラが他のプログラムに使用されているために“塞がり”と判断されたとする（ステップＳ３‐３でｎｏの場合）。
【００４６】
この場合には、当該計算機の端末リソースマネージャは起動要求元計算機の会議アプリケーションに対してカメラが塞がっていることを通知する。
【００４７】
これに対して、起動要求元計算機の会議アプリケーションは端末リソースマネージャに対し、カメラの予約を依頼する（ステップＳ３‐５）。カメラの予約を依頼された前記端末リソースマネージャはリソースの使用状況を監視している過程で資源要求情報保持手段１０に記憶されているカメラが解放されたことを検出すると、この解放されたカメラを予約していたサービス制御手段である会議アプリケーションのために、このカメラの割り当てをし、これによって会議アプリケーションのためにカメラの獲得をすると共に、当該予約していた起動要求元計算機の会議アプリケーションに対してそのことを通知する（これによりステップＳ３‐７でｙｅｓに分岐）。
【００４８】
これにより、起動要求元計算機の会議アプリケーションはこの時点で再び前回の起動要求時点でリソースの確保ができずに会議サービスができなかったその会議参加予定の計算機に対してリンクさせてその計算機の確保した必要なリソースと会議アプリケーションを利用しての会議サービスを実現する。
【００４９】
このことにより、会議アプリケーションが無闇にカメラの獲得を試みることを行なったり、ユーザがやみくもに会議アプリケーションの起動を試みるといった無駄な動作を無くすことができるようになる。
【００５０】
以上の第１の具体例は、起動要求されたサービスに対して必要なリソース（資源）を獲得させる際に、既にこれが他に使用されている時は、予約を行ない、そのリソースが解放されると、この予約に従って上記起動要求されているサービスのリソースとして獲得し、必要なリソースが獲得されたならば、上記起動要求されているサービスを実施するようにしたものであり、これによって、アプリケーションが無闇に必要なリソースの獲得のための動作を行なったり、必要なリソースが揃わないのを知らずに、ユーザがやみくもにそのアプリケーションの起動を試みるといった無駄をなくし、ユーザに対するサービスの向上を図ることができるようになるものである。
【００５１】
以上は、リソースの予約を行なってそれが解放されたなら、その解放されたリソースを予約待ちのアプリケーションに利用させるように割り付けるものであるが、これでは使用中のリソースが空くのを待たねばならない。しかし、緊急度の高いサービスの起動要求もあるので、このような緊急度の高いものについて、リソースが空くのを待たせるわけにはゆかない。このような場合に即座に対応できるようにした例を第２の具体例としてつぎに説明する。
【００５２】
（第２の具体例）
第２の具体例は、獲得要求対象のリソースが“塞がり”の場合に、そのリソースを使用しているサービス制御手段（アプリケーションプログラム等）がある場合、もしくはそのリソースを使用しているサービス制御手段が複数ある場合に、どのサービス制御手段に解放要求を出すかを選択して、その選択したサービス制御手段に解放要求を出すようにするもので、その例を図４のブロック図に従って説明する。
【００５３】
図４に示すように、システム構成例としては、計算機（パーソナルコンピュータやワークステーションなど）１‐１〜１‐ｎが通信路２を介して接続され、各計算機に音声／画像の入出力装置（カメラ６、ディスプレイ装置７、マイクロフォン８、スピーカ９）が接続された構成であり、これは第１の具体例と同様である。
【００５４】
ここに示す例でも、第１の具体例と同様に、前記複数台の計算機のうちの一つには、サービス制御手段３の一つとして会議アプリケーションがあってこれが稼働し、また、各計算機には端末資源管理手段４としての端末リソースマネージャがあってこれがそれぞれ稼働し、複数台の前記計算機のいずかには網資源管理手段５としての網リソースマネージャがあってこれが稼働しているものとする。また、これらリソースマネージャの構成は第１の具体例として図２で示したものと同様である。
【００５５】
第１の具体例と異なる部分は、本例では、各計算機にはそれぞれ、要求リソースが“塞がり”の場合において、そのリソースを使用しているサービス制御手段（アプリケーションプログラム等）が１つ以上ある場合に、どのサービス制御手段に解放要求を出すかを決定する資源要求先サービス制御手段決定手段１２を設けるようにしている点、およびサービス制御手段３には、目的のサービスを提供するための制御機能の他に、資源獲得・解放機能と、資源制御機能とを設けるようにしている点である。
【００５６】
資源獲得・解放機能は、未使用のリソースを要求に基づいて獲得し、また、要求に基づいて解放するように端末資源管理手段（端末リソースマネージャ）４に指令するための機能手段である。また、資源制御機能はリソース解放要求を受けたときにそのリソース（資源）を解放するかどうかを判断し、解放する場合に資源獲得・解放機能に当該リソースの解放を指示する機能手段である。
【００５７】
なお、サービス制御手段３には目的のサービスを提供するための制御機能の他に、資源獲得・解放機能と、資源制御機能とを設ける他に、資源要求先サービス制御手段決定手段１２をも設けるようにしてもよい。この場合サービス制御手段（アプリケーションプログラム等）３の構成例を図５に示す。すなわち、サービス制御手段３には目的のサービスを提供するための制御機能の他に、サービス制御資源要求先サービス制御手段決定手段１２と、資源獲得・解放手段１４と、資源制御手段１５とがある。
【００５８】
これらのうち、資源要求先サービス制御手段決定手段１２は要求リソースが“塞がり”の場合において、そのリソースを使用しているサービス制御手段（アプリケーションプログラム等）が１つ以上ある場合に、どのサービス制御手段に解放要求を出すかを決定する機能手段であり、また、資源獲得・解放手段１４は、未使用のリソースを要求に基づいて獲得し、また、要求に基づいて解放するように端末資源管理手段（端末リソースマネージャ）４に指令するための機能手段である。また、資源制御手段１５はリソース解放要求を受けたときにそのリソース（資源）を解放するかどうかを判断し、解放する場合に資源獲得・解放手段１４に当該リソースの解放を指示する機能手段である。
【００５９】
なお、各サービス制御手段３にはリソース解放の要求を受けた場合に、当該解放要求リソースの解放を行なうか否かの判断をする機能と、リソースの解放を行なった場合に、端末リソースマネージャに対して解放を通知する機能と、リソースの解放を行なわなかった場合に、端末リソースマネージャに対して解放拒否を通知する機能とを持たせてある。従って、端末リソースマネージャはこの情報に従って、リソースの解放や確保を行なうことができる。
【００６０】
つぎにこのような構成の本システムの作用を説明する。
【００６１】
ここでも第１の具体例と同様に、会議アプリケーションが会議サービスに必要なリソースのうちの一部が他のアプリケーションに使用されている場合のリソース獲得処理について説明する。
【００６２】
図６に本具体例において会議アプリケーションがリソースを獲得してサービスを開始するまでの処理の流れを示す。
図６に沿って説明する。会議アプリケーションの起動要求元の計算機では、会議アプリケーションが起動されると（ステップＳ６‐１）、まず網リソースマネージャおよび各会議参加計算機の端末リソースマネージャに対して、当該会議アプリケーションのサービス実施に必要な各種リソースについての獲得要求を、通信路２を介して送信する（ステップＳ６‐２）。
【００６３】
ここで端末リソースとして、例えばある計算機に接続されているカメラが他のアプリケーションプログラムによって使用されていたために、リソースマネージャの要求資源空塞判断手段１１により“塞がり”と判断された場合には（ステップＳ６‐３でｎｏの場合）、要求元の会議アプリケーションは当該カメラを使用中の他のアプリケーションプログラム（そのリソースを使用しているサービス制御手段３）を資源要求先サービス制御手段決定手段１２により選択させ、カメラの解放を要求する。
【００６４】
この例の場合、端末リソースマネージャに問い合わせることにより、そのリソース（この例ではカメラ）を使用しているサービス制御手段（アプリケーションプログラム等）がどれであるかを知り、当該サービス制御手段を資源要求先サービス制御手段決定手段１２に決定させることができる。
【００６５】
なお、この例ではカメラを占有していたアプリケーションが一つであるとして、資源要求先サービス制御手段決定手段１２は単にカメラを占有しているアプリケーションをそのまま解放要求先として選択させるようにしたが、要求リソースの占有者が複数ある場合（網リソースなど）もある。このようなケースでの例については第３の具体例において説明する。
【００６６】
資源（カメラ）の解放を要求されたサービス制御手段（アプリケーションプログラム）は、その資源（カメラ）を解放するかどうかを判断し、その結果、解放する場合には、解放処理を行い、端末リソースマネージャに対して解放を通知する。
【００６７】
会議アプリケーションは端末リソースマネージャからカメラの解放通知を受けて（ステップＳ６‐６でｙｅｓの場合）、カメラを獲得し、会議サービスを実行する。
【００６８】
ここで、リソースの解放要求を受けたサービス制御手段３が当該リソースを解放するかしないかの判断に用いる判断基準としては、
[i] 「要求されたリソースを解放しても、予め（ユーザにより）設定されたサービス品質の許容範囲を満たせるか否か」
というものが一つ考えられる。この基準においては、要求されたリソースを解放しても、予め設定されたサービス品質の許容範囲を満たせると判断される場合は解放する。
【００６９】
また、この基準以外にも例えば、
[ii] ユーザとのインタフェース（計算機の画面上など）にリソース解放の可否を尋ねる情報を示し、ユーザからリソース解放の可否を指示させる。
[iii] 予め（ユーザにより）設定されたアプリケーション間の起動優先順位に従い、より高い優先順位のアプリケーションから開放要求を受けた場合に解放する。
[iv] アプリケーションにおける特定の機能またはリソースに対するアクセスが一定時間無い場合に解放すると判断する。
[v] 予め（ユーザにより）設定された開放要求を受け付け可否状態に基づき、受け付け可の状態の場合は解放する。
などが考えられる。
【００７０】
以上は、サービスの要求元より、使用したいリソースを通知して相手側にそのリソースを確保させると共に、使用したいリソースが塞がっている時は、そのリソースを使用しているアプリケーションに解放要求を出し、この解放要求を受けたアプリケーション側では、解放の是非を判断して、解放可能のときにはそのリソースを解放してサービスの要求元に使用させるようにすることにより、予約なしで、何時でもサービスが受けられるようにしたものである。
【００７１】
要求リソースの占有者が複数ある場合の例（例えば、複数のアプリケーションがそれぞれ通信路を使用していて通信路の帯域の空きが十分でない場合など）をつぎに説明する。
【００７２】
（第３の具体例）
図７に本発明の第３の具体例の説明図を示す。システムの構成は第２の具体例と同一である。図７では、通信路２が多重化されており、複数の帯域が確保できて、空いている帯域があればこれを確保して通信に利用し、サービスを受けることができることを示している。
【００７３】
今、このシステム上のいくつかの計算機によって、会議アプリケーション（図中では会議１）が実行されているものとする。
【００７４】
この状態で別の計算機の組み合わせにおいて、第２の会議アプリケーション（図中では会議２）を実行しようとしたとする。そして、第２の会議アプリケーションのグループでは、端末リソースである音声／画像情報の各入出力装置は確保できたが、情報を伝送するのに必要な帯域（網リソース）が確保できなかったとする。この場合について、本発明によるリソース確保の方法を説明する。
【００７５】
網リソースマネージャは、要求資源空塞判断手段１１により、要求された帯域の通信路２が空いているかどうかを判断する。判断の方法としては、例えば、第１の具体例において述べたような方法が考えられる。
【００７６】
判断の結果、“塞がり”と判断された場合、網リソースマネージャは解放要求先サービス制御手段決定手段１２により、網リソースを共有しているアプリケーションの中から網リソースの解放をさせるに最適なアプリケーションを選択させる。
【００７７】
選択の方法としては、例えば最近一定期間の網リソースの実際のトラヒック状況をモニタリングし、トラヒックの無いもの、あるいは少ないものを選択する（図中では他アプリケーション２）などの方法が考えられる。
【００７８】
このようにして選択されたアプリケーションに対して、網リソースの解放要求を出す。解放要求を受信したアプリケーションは自己の持つリソース解放可否判断機能手段により、要求網リソースを解放するか否かを判断し、解放または解放拒否する。以降の処理は第２の具体例と同様である。
【００７９】
以上の第１ないし第３の具体例は、要するに、通信システムにおいて、あるアプリケーションが必要とするリソースが他のアプリケーションにより確保されてしまっていて利用できない場合に、予約をしてそのリソースが解放されると、当該リソースの使用状況を管理しているリソース管理手段または、当該リソースを確保している前記アプリケーションが、当該リソースの解放時に当該リソースを要求しているアプリケーションに解放を通知することにより、そのリソースを要求しているアプリケーションに直ぐさま、当該リソースを確保させることができるようにしたものであり、やみくもにアプリケーションの再起動を繰り返さずに済むようにしたものである。
【００８０】
また、本発明はアプリケーションが直接あるいはリソース管理手段を経由して、前記リソースを確保している他のアプリケーションにリソースの解放を要求し、可能であれば解放させることにより、前記リソースを確保している他のアプリケーション自らが当該リソースを解放するまで待つことなしに当該リソースを獲得する機会を与え、リソースの運用効率を高めることができるようにしたものである。
【００８１】
従って、無用な操作を回避できるようになり、また、リソースをいたずらに占有して他のアプリケーションの実行を妨げることが少なくなり、ユーザサービスの向上を図ることができるようになる。
【００８２】
（第４の具体例）
電話システムのような通信システムは、一つの端末に一つのコールが対応する低機能な端末のみが存在し、一つのコールに複数のコネクションが存在するようなことがない。しかし、マルチメディアでは一つのコールに複数のコネクションが存在する。
【００８３】
すなわち、従来の電話通信では複数メディアを使用しても、例えばＨ１２２では１本のコネクション上に多重化し、またコールとコネクションは同時に制御されていた。また、１台の端末は同時には１つのコールのみに関与し、１つのコールで通話中の場合に第２のコールの要求は話中扱いで拒否されていた。しかし、上記の従来技術のような端末で利用可能な通信資源や通信網で利用可能な通信資源を考慮していない通信システムではマルチメディアに柔軟に対応できない。
【００８４】
また、マルチメディアでは種々の資源（リソース）が利用されるが、端末が利用可能な通信資源や通信網が利用可能な通信資源を考慮してコールとコネクションを制御する通信システムはなく、この場合、コールを行なってみて初めて自己の目指す資源（リソース）が利用できるか否かがわかる仕組みであり、相手の環境が掴めない場合は相手環境が不十分なために、通信ができないことも多い。そこで、コールとコネクションを相手環境の範囲で適合させて行なうことができるようにした例をつぎに説明する。
【００８５】
ここでは、基本的な例として、端末と通信網で利用可能な通信資源の状態を管理する通信資源管理手段を設けるようにし、その通信資源管理手段の提供する通信資源の状態に基づいてコールやコネクションを制御するコール・コネクション制御手段を設ける構成とする。
【００８６】
具体例を用いて詳細を説明する。
【００８７】
端末と通信網で利用可能な通信資源の状態を管理する通信資源管理手段を設けて当該通信資源の状態を管理するようにし、この通信資源管理手段の提供する通信資源の状態に基づいてコール・コントロール制御手段により、コールやコネクションを制御する例を第４の具体例として説明する。
【００８８】
なお以後、コール・コントロール制御手段をＣＣ制御手段、またコールコントロールブロックをＣＣＢと略称する。
【００８９】
図９は、第４の具体例並びに後述する第５の具体例におけるシステムのハードウェア構成図である。図中、１０１はネットワーク（通信網）であり、このネットワーク１０１を介してここでは３つの端末（端末（Ａ），端末（Ｂ），端末（Ｃ））２０１，３０１，４０１が接続されている。
【００９０】
端末（Ａ）２０１は、ディスプレイ２０２、スピーカ２０３、マイク２０４を入出力装置として備えている。端末（Ｂ）３０１も端末（Ａ）と同様の構成であり、ディスプレイ３０２、スピーカ３０３、マイク３０４を備えている。
【００９１】
一方、端末（Ｃ）４０１は、ビデオ再生装置４０２、スピーカ４０３、マイク４０４を備えている。このビデオ再生装置４０２からは、ビデオの再生に伴い、音声と動画の信号をネットワークに流すことができる。
【００９２】
次に図１０は、端末（Ａ）２０１の構成図である。
【００９３】
端末（Ａ）２０１は、通信制御手段２１１を介してネットワークと接続している。入出力装置制御手段２１２は、端末（Ａ）２０１が備えている入出力装置の制御を行う。通信資源管理手段２１３は、入出力装置制御手段を介して接続している各入出力装置の状態、および端末（Ａ）２０１で使用可能な通信帯域などの通信資源を管理する手段で、それらの資源の状態を記述する通信資源管理テーブルを有する。
【００９４】
ＣＣ制御手段２１４は、端末（Ａ）２０１に関わるコールとコネクションを制御する手段である。また、ユーザと端末とのインタフェースを制御するＨＭＩ（Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ）制御手段２１５も備えている。
【００９５】
以上の各手段は、端末（Ａ）２０１内のバス２１６を介して接続されている。また、端末（Ｂ）３０１、端末（Ｃ）４０１も同様な構成を備えている。
【００９６】
次に、フロー図１１に従って各手段の実際の動きを説明する。本発明の適用環境例として、ここではネットワークはＡＴＭ網を想定し、各端末が使用可能である通信帯域は、一端末あたり送信、受信それぞれ３Ｍｂｐｓと仮定して話を進める。
【００９７】
また、音声に関して必要となる通信帯域は、送受信それぞれ１Ｍｂｐｓ、動画に関して必要な通信帯域は、送受信各２．５Ｍｂｐｓと仮定する。そして、現在、各端末ともに入出力装置は未使用とし、この時点での端末（Ａ）２０１，端末（Ｃ）４０１の通信資源管理手段２１３が備える通信資源管理テーブルは図１２に示す如きであるものとする。
【００９８】
端末（Ｂ）３０１の通信資源管理テーブルは、端末（Ａ）２０１と同様であるので省略する。
【００９９】
〔正常なシーケンス例〕
［端末間通信のためのコールとコネクション動作］
ここで、端末（Ａ）２０１の使用者（以後、ユーザＡと記す。残りの端末（Ｂ），端末（Ｃ）の使用者に関しても同様）はマイクロフォン（以下、マイクと呼ぶ）、スピーカを使用したユーザＢ（端末（Ｂ）の使用者）との音声双方向通信をＨＭＩ制御手段２１５に要求したとする（ステップＳ‐１１）。
【０１００】
端末（Ａ）２０１のＨＭＩ制御手段２１５は、ユーザＡからの要求を受け、端末（Ａ）２０１のＣＣ制御手段２１４にマイクとスピーカを使用するコールに関するＣＣＢの生成を要求する。要求を受け取ったＣＣ制御手段２１４は、要求の内容がマイクとスピーカを使用するコールの生成であることを判断し、次に端末（Ａ）２０１の通信資源管理手段２１３に対してマイクとスピーカの使用が可能であるか否かを問合わせる（ステップＳ‐１２）。
【０１０１】
例えばこのとき、端末（Ａ）２０１のマイクの電源が入っていないと仮定すると、要求した通信資源が使用できないので、ＣＣ制御手段２１４は通信資源管理手段２１５からマイクの使用が不可能である旨を通知される。これを受けたＣＣ制御手段２１４は、ＨＭＩ制御手段２１５に対して、要求されたコールの生成が出来ない旨を通知し、これを受けたＨＭＩ制御手段２１５はユーザＡに対して、マイクが使用できないためにユーザＢとの通信ができないことを通知する（ステップＳ‐１２のＮｏ）。
【０１０２】
今の場合、端末（Ａ）２０１ではマイクもスピーカも未使用であるし、通信帯域も余裕があるので、通信資源管理手段２１３は要求された通信資源の使用が可能である旨をＣＣ制御手段２１４に対して通知する（ステップＳ‐１２のＹｅｓ）。
【０１０３】
ＣＣ制御手段２１４はこれを受けて、このコールに関するＣＣＢを作成する（ステップＳ‐１３）。
【０１０４】
ここでＣＣＢ（コールコントロールブロック）とは、コールを制御するために必要なブロックで、いくつかのフィールドを有する。図１３にＣＣＢのフォーマットを、図１４に端末（Ａ）２０１に生成されたＣＣＢを示す。但し、ＣＣＢのフォーマットに関しては、本実施例に係わるフィードのみを記述した。
【０１０５】
図１３のＣＣＢ（コールコントロールブロック）の各フィールドを説明する。
【０１０６】
図１３における５０１はコールリファレンスフィールドであり、このコールリファレンスフィールド５０１は、ＣＣＢを所有するコールに付けられた番号であるコールリファレンスを記述するフィールドである。コールリファレンスとは、一般にＵＮＩで一意であるコールの識別子のことを指す。ここでは、単にコールの識別子という意味で使用する。本例では特にコールリファレンスの獲得の仕方には言及せずに、端末間で同じコールリファレンス１が割り当てられたものと仮定する。
【０１０７】
図１３における５０２は通信相手フィールドであり、この通信相手フィールド５０２には通信相手を記述する。５０３は通信資源フィールドであり、この通信資源フィールド５０３にはその端末で使用する通信資源を記述する。
【０１０８】
次にＣＣ制御手段２１４は、コールリファレンス（今の場合、“１”）と、使用する通信相手（今の場合、端末（Ｂ））とその通信資源（今の場合、スピーカとマイク）と、その資源の使用要求とを通信資源管理手段２１３に通知する。通知を受けた端末（Ａ）２０１の通信資源管理手段２１３は、端末（Ａ）２０１の通信資源管理テーブルを図１５に示す如きに変更し、その変更完了の旨をＣＣ制御手段２１４に通知する（ステップＳ‐１４）。そして、その通信資源を利用するために、確保する。
【０１０９】
通信資源管理手段２１３からの変更完了を受けた端末（Ａ）２０１のＣＣ制御手段２１４は、ＣＣＢ生成完了をＨＭＩ制御手段２１５に通知する。ＣＣＢ生成完了の通知を受けたＨＭＩ制御手段２１５は、通信制御手段２１１へ端末（Ｂ）３０１に対して通信の要求を出すように指令し、これによって端末（Ａ）２０１の通信制御手段２１１は端末（Ｂ）３０１に対して通信の要求を出す（ステップＳ‐１５）。
【０１１０】
ここで端末（Ｂ）３０１が何らかの理由で通信に応じられない状況にあったとする。この場合は、端末（Ｂ）３０１の通信制御手段２１１は端末（Ａ）２０１の通信制御手段２１１に対して通信が出来ない旨を通知する。
【０１１１】
すると、端末（Ａ）２０１では、端末（Ｂ）３０１からの通信不可能である旨の通知を通信制御手段２１１を介してＨＭＩ制御手段２１５が受ける。そして、これを受けると、端末（Ａ）２０１のＨＭＩ制御手段２１５は、ＣＣ制御手段２１４に、先程生成したＣＣＢを削除するように要求する。
【０１１２】
要求を受けたＣＣ制御手段２１４はＣＣＢを削除するとともに、コールリファレンス１とＣＣＢに記載されている通信資源とその通信資源の解放要求を端末（Ａ）２０１の通信資源管理手段２１３に通知する。この通知により、通信資源管理手段２１３は確保していた通信資源を解放するが、この解放に成功した場合、通信資源管理手段２１３はその旨をＣＣ制御手段２１４に通知する。端末（Ａ）２０１の通信資源管理手段２１３は、確保していた通信資源の解放にともない、端末（Ａ）２０１の通信資源管理テーブルを書き替え、マイクとスピーカを未使用に戻す。
【０１１３】
通信資源管理手段２１３からの解放成功の通知を受けたことにより、ＣＣ制御手段２１４はＣＣＢの削除の成功をＨＭＩ制御手段２１５に通知し、ＨＭＩ制御手段２１５は、ユーザＡにユーザＢとの通信が不可能であることを通知する（ステップＳ‐１５のＮｏ）。
【０１１４】
ここで（ステップＳ‐１５のＹｅｓ）に戻る。
【０１１５】
端末（Ａ）２０１より通信の要求を受けた端末（Ｂ）３０１がマイクとスピーカとを用いた通信が可能な状態にあるときは、つぎのようになる。
【０１１６】
端末（Ａ）２０１よりマイクとスピーカとを用いての通信の要求を受けた端末（Ｂ）３０１では、上述の手続きと同様にしてコールリファレンス１のＣＣＢを作成し、通信が可能である旨を端末（Ａ）２０１に通知する。この通信が可能である旨の通知を端末（Ａ）２０１の通信制御手段２１１が受け取ると、ユーザＡとユーザＢのマイクとスピーカを使用した通信が可能になり、これらを用いての通信を始めることができる（ステップＳ‐１６）。
【０１１７】
ここまでで一つ注意すべきことは、ＣＣＢや通信資源管理テーブルは端末（Ａ）２０１の共有資源なので、特に排他制御を考慮した操作を行わなければならない。具体的には、ＣＣＢや通信資源管理テーブルなどの共有資源を操作する時には、セマフォなどの排他制御に必要な機能を利用することが考えられる。ここでもなんらかのこのような排他制御機能を使用していると仮定する。
【０１１８】
［通信終了動作］
次にユーザＡとユーザＢの通信が終了する場合を説明する。
【０１１９】
ユーザＡが通信を切断する場合には、その旨を端末（Ａ）２０１のＨＭＩ制御手段２１５に通知する（ステップＳ‐１７）。
【０１２０】
するとＨＭＩ制御手段２１５は、通信制御手段２１１を介して端末（Ｂ）３０１に通信切断の要求をすると同時に、端末（Ａ）２０１のＣＣ制御手段２１４にコールリファレンス１のＣＣＢの削除を要求する。
【０１２１】
端末（Ａ）２０１のＣＣ制御手段２１４はそれを受けて、コールリファレンス１のＣＣＢを削除するとともに、通信資源管理手段２１３に対してコールリファレンス１で使用している全通信資源の解放を要求する。
【０１２２】
コールリファレンス１のコールで使用している通信資源はＣＣＢを参照することより分かる。
【０１２３】
次に端末（Ａ）２０１の通信資源管理制御手段２１３は、通信資源解放を行ない、それに成功すると通信資源解放の成功をＣＣ制御手段２１４に通知する。通知を受けた端末（Ａ）２０１のＣＣ制御手段２１４は、ＣＣＢ削除成功を通信制御手段２１１に通知し、これによってユーザＡとユーザＢの通信は終了する（ステップＳ‐１８）。
【０１２４】
［通信途中におけるユーザ使用の通信資源の解放動作］
通信途中で、ユーザＡが使用している通信資源を解放する必要が生じた場合を説明する。
【０１２５】
この場合も上の手順とほぼ同様である。上の手順と異る箇所はＣＣ制御手段２１４は、コールリファレンスと解放すべき通信資源とその通信資源の解放要求を通信資源管理手段２１３に通知するが、ＣＣＢは削除しない点である。また、ユーザＡが通信の途中で新たな通信資源を追加する場合も同様である。
【０１２６】
以上が正常なシーケンスであるが、次に障害があるシーケンス例を説明する。
【０１２７】
〔障害があるシーケンス例〕
［通信中の端末に別端末の割り込みが発生する場合の動作］
現在、ユーザＡとユーザＢは、スピーカとマイクを利用して双方向の音声通信を行っているとする。この時点での端末Ａの通信資源管理テーブルは図１５の通りである。
【０１２８】
今、ユーザＣ（端末（Ｃ）の使用者）は自分の使用している端末（Ｃ）４０１でビデオを再生し、ユーザＡに送信しようと考えている。ユーザＣは、先程の正常なシーケンスの手順に従ってユーザＡとの通信を確立しようとし、端末（Ｃ）４０１においてはコールリファレンスの生成、通信管理テーブルの変更に成功したとする。
【０１２９】
次に端末（Ｃ）４０１の通信制御手段２１３は、端末（Ａ）２０１の通信制御手段２１１に音声と動画を受信する準備を要求する。要求を受けた端末（Ａ）２０１の通信制御手段２１１は、端末（Ａ）２０１のＣＣ制御手段２１４にスピーカとディスプレイを使用するコールに関するＣＣＢの生成を要求する。
【０１３０】
端末（Ａ）２０１のＣＣ制御手段２１４は端末（Ａ）２０１の通信資源管理手段２１３にスピーカとディスプレイの使用が可能であるかを問い合わせるが、通信資源管理手段は２１３通信資源管理テーブルを見ることによりスピーカが使用できないことを知り、その旨をＣＣ制御手段２１４に通知する。
【０１３１】
この通知により、端末（Ａ）２０１のＣＣ制御手段２１４はＣＣＢの生成が出来ない旨を通信制御手段２１１に通知し、端末（Ａ）２０１の通信制御手段２１１は、端末（Ｃ）４０１に対して端末（Ａ）２０１側のスピーカが使用できないので、先程の条件（音声と動画の受信）ではコールを生成することが出来ないことを通知する。端末（Ｃ）４０１側ではこれを受けて、先程の条件による通信はできないことを知る。
【０１３２】
そこで、ユーザＣは音声を送信することを諦めて、動画のみをユーザＡに送信することにしたとする。
【０１３３】
端末（Ｃ）４０１側では、先程と同じ手順でＣＣ制御手段２１４に、ディスプレイを使用しての端末（Ａ）２０１とのコールに関するＣＣＢの生成が要求される。そして、ディスプレイを使用するコールに関するＣＣＢを生成し、端末（Ａ）２０１に送り、ディスプレイの使用が可能であるかを問い合わせる。
【０１３４】
しかし、本実施例の仮定として、端末の送受信通信帯域は各３Ｍｂｐｓであり、音声の送受信は各１Ｍｂｐｓ、動画の送受信は各２．５Ｍｐｂｓである。現在、端末（Ａ）２０１側では、端末（Ｂ）３０１との音声に関する両方向通信により、受信通信帯域を１Ｍｂｐｓ使用しているので、端末（Ａ）２０１の受信通信帯域の残りは２Ｍｐｂｓである。
【０１３５】
一方ディスプレイを使用する動画の受信には２．５Ｍｂｐｓ必要なので、ディスプレイを使用する通信に必要な通信帯域を確保することが不可能であることがわかる。
【０１３６】
その結果、端末（Ａ）２０１の通信制御手段２１１は端末（Ｃ）４０１に対して通信帯域の不足のために動画の受信が出来ない旨を通知する。
【０１３７】
以上は、端末と通信網で利用可能な通信資源の状態を管理する通信資源管理手段を設けて当該通信資源の状態を管理するようにし、要求する通信の必要な資源を提示してこの提示資源と、通信資源管理手段の提供する通信資源の状態とを比較し、要求する資源を使用しての通信が可能な場合にはその資源を利用して通信を実施し、要求する資源が確保できないときは、通信資源管理手段の提供する通信資源の状態から代替え資源を探り、代替え可能な資源があればその代替え可能な資源を利用して通信を実施するように制御するもので、コール段階でそれが行なえるようになるので、その時々の資源状況に応じて合理的に通信ができるようになる。
【０１３８】
（第５の具体例）
第５の具体例は、優先度の低い通信の確保している通信資源が、緊急な優先度の高い通信に要求された場合、その要求に応じて優先度の低い通信が確保している通信資源を解放することに関わる例である。
【０１３９】
本例のハードウェア構成（端末（Ａ）、端末（Ｂ）、端末（Ｃ）とネットワークの構成）は、第４の具体例と同様とする。また、本例の端末構成図を図１６に示す。
【０１４０】
図１６に示すように、端末は、通信制御手段６１１を介してネットワークと接続している。入出力装置制御手段６１３は、端末が備えている入出力装置の制御を行う。通信資源管理手段６１４は、入出力装置制御手段６１３を介して接続している各入出力装置の状態、および端末で使用可能な通信帯域などの通信資源を管理する手段で、それらの資源の状態を記述する通信資源管理テーブルを有する。
【０１４１】
ＣＣ制御手段６１５は、端末に関わるコールとコネクションを制御する手段である。また、ユーザと端末とのインタフェースを制御するＨＭＩ制御手段６１６も備えている。
【０１４２】
ここまでは、第４の具体例と同じであるが、本例では端末には割り当て決定手段６１２を備えている点が異なる。この割り当て決定手段６１２とは、所定の判定基準に従って２つの通信に対してランク付けを行ない、それに応じて端末で利用可能な通信資源や通信網で利用可能な通信資源の割り当てを決定する手段である。
【０１４３】
以上の各手段は、端末内のバス６１７を介して接続されている。端末（Ａ）２０１、端末（Ｂ）３０１、端末（Ｃ）４０１はいずれも本構成を備える。
【０１４４】
本具体例では、ＣＣＢには、新たにコールの優先度を記述するフィールドを設ける。そして、このフィールドを利用してコールに対して優先度を付けることが出来るようにする。優先度は発呼者が任意の値を付けることが可能であるとする。本例では、特に優先度を２段階の“０”と“１”にしてある。そして、“０”は“１”よりも低優先度であるとする。
【０１４５】
なお、ここでは便宜的に優先度を２段階にしたが、システムの要求に合わせて任意の段階を設定してよいのは言うまでもない。
【０１４６】
ここで説明する例において使用するＣＣＢのフォーマット図を図１７に示す。第４の具体例におけるＣＣＢと異なる箇所は、優先度を記述する優先度フィールド７０４が追加された点である。以下に示す本例での「所定の判断基準」とは、この優先度に基づくものとする。
【０１４７】
つぎに作用を説明する。
【０１４８】
現在、ユーザＡ、ユーザＢと音声の両方向通信を行っているとする。互いに使用している通信資源は、スピーカとマイクであり、この現在行なっている両方向通信のコールに割り当てた優先度は“０”であったとする。このコールに関する端末（Ａ）のＣＣＢを図１８に示す。また、この時点での端末（Ａ）の通信資源管理テーブルを図１９に示す。
【０１４９】
［端末（Ｃ）４０１の動作］
ここで、ユーザＣからユーザＡに緊急な要件が発生し、ユーザＡと音声の双方向通信をする必要が出来たと仮定する。このとき、ユーザＣは端末（Ｃ）４０１のＨＭＩ制御手段６１６に優先度が“１”で、スピーカとマイクを使用した音声の双方向通信を要求する。
【０１５０】
すると端末（Ｃ）４０１では通信資源の確保とＣＣＢの生成に成功し、次に端末（Ｃ）の通信制御手段６１１は端末（Ａ）２０１の通信制御手段６１１に音声の双方向通信を優先度“１”で要求する。
【０１５１】
［端末（Ａ）２０１の動作］
要求を受けた端末（Ａ）２０１の通信制御手段６１１は、スピーカとマイクを使用する音声の双方向通信で優先度“１”のコールに関するＣＣＢの作成をＣＣ制御手段６１５に要求する。
【０１５２】
ＣＣ制御手段６１５はスピーカとマイクの使用が可能であるかを通信資源管理手段６１４に問合わせる。通信資源管理手段６１４は、通信資源管理テーブル（図１９）を参照することにより、それは既にユーザＡとユーザＢとの間のコールリファレンス１の通信で使われていることを知る。
【０１５３】
そして、通信資源管理手段６１４はＣＣ制御手段６１１に対して先に要求された通信資源が、コールリファレンス１のコールによって使用されているので要求された通信資源は解放できない旨を通知する。
【０１５４】
すると端末（Ａ）２０１のＣＣ制御手段６１１は、割り当て決定手段６１２に対して端末（Ａ）２０１と端末（Ｂ）３０１との間で現在行なわれている通信と端末（Ｃ）４０１に要求されている通信との間で、所定の判定基準に従い通信資源を割り当てるように要求する。
【０１５５】
端末（Ａ）２０１の割り当て決定手段６１２は、コールリファレンス１をキーにしてＣＣＢを探索し、該当するＣＣＢを発見する。そして端末（Ａ）２０１と端末（Ｂ）３０１との間で現在行なわれている通信の優先度が“０”であることを知る。
【０１５６】
一方で割り当て決定手段６１２は、端末（Ｃ）４０１から要求された通信の優先度が“１”であることを端末（Ａ）２０１のＣＣ制御手段６１５に問い合わせて知ることが出来る。そこで端末（Ａ）２０１の割り当て決定手段６１２は、現在端末（Ｂ）との間で行なわれている通信よりも端末（Ｃ）４０１に要求されている通信を優先すべきであると判断し、端末（Ａ）２０１のＣＣ制御手段６１５に対してコールリファレンス１の通信（端末（Ａ）と端末（Ｂ）との間の通信）が使用している通信資源で、端末（Ｃ）４０１から要求されている通信資源と重なるものの解放を要求する。
【０１５７】
端末（Ａ）２０１のＣＣ制御手段６１５はそれを受けて通信資源管理手段６１４に対して端末（Ｃ）４０１との通信で使用する通信資源の解放を要求する。端末（Ａ）２０１の通信資源管理手段６１４は、ＣＣ制御手段６１５からの解放要求を受けて、通信資源管理テーブルから端末（Ｃ）４０１に要求されている通信資源を一時解放し、解放の成功を端末（Ａ）２０１のＣＣ制御手段６１５に通知する。
【０１５８】
ＣＣ制御手段６１５は、解放の成功を受けた後、改めて端末（Ｃ）４０１に要求された通信のためのＣＣＢを作成する。これ以後、端末（Ａ）２０１でのＣＣＢの作成と、通信資源を確保する方法は第４の具体例と同様である。
【０１５９】
但し、ＣＣＢの作成時に優先度フィールドにその通信の優先度を書き込むことが追加される。
【０１６０】
このように、この例では、通信の優先度の情報を新たに付加してコールとコネクションを行ない、既に確立している通信によって使用されている通信資源に対して、新たな通信がその通信資源の使用を要求した場合、その新たな通信の優先度が現在の優先度より上位であれば、その新たな通信において要求される通信資源を解放し、その新たな通信の要求を出した側との通信での利用に供するようにした。そのため、この例によれば、緊急度の高い通信は優先して必要な資源を確保しての通信が可能になる
なお、優先度によっては所定の判断基準によって通信資源を比例配分、あるいは案分するようにする構成も考えられる。この場合、要求した通信資源に対して、一部のみしか割り当てないことになるが、既にその資源を使用しているアプリケーションも、これによってサービスを続行することができることになる。
【０１６１】
以上は緊急度の高い通信は優先度に応じて必要な資源を確保できるようにする例であるが、資源を解放するか否かをユーザに判断させるようにする具体例をつぎに説明する。
【０１６２】
（第６の具体例）
既に確立している通信によって使用されている通信資源に対して、新たな通信がその通信資源の使用を要求した場合、どちらの通信に対して通信資源を割り当てるかをユーザに判断させるようにする具体例が以下に説明する第６の具体例である。
【０１６３】
本実施例のハードウェア構成（端末（Ａ）、端末（Ｂ）、端末（Ｃ）とネットワークの構成）とＣＣＢのフォーマットは、第４の具体例と同様とする。また、本実施例の端末構成を図２０に示す。
【０１６４】
端末は、通信制御手段８１１を介してネットワークと接続している。入出力装置制御手段８１４は、端末が備えている入出力装置の制御を行う。通信資源管理手段８１２は、入出力装置制御手段８１４を介して接続している各入出力装置の状態、および端末で使用可能な通信帯域などの通信資源を管理する手段で、それらの資源の状態を記述する通信資源管理テーブルを有する。
【０１６５】
ＣＣ制御手段８１３は、端末に関わるコールとコネクションを制御する手段である。また、ユーザと端末とのインタフェースを制御するＨＭＩ制御手段８１５も備えている。通信資源表示手段８１６は、現在の通信資源の種別、使用量と要求されている通信資源の種別、使用量を表示する手段である。ユーザは、この表示手段により通信資源の状況を知り、どちらの通信に対して通信資源を割り当てるかを判断する。
【０１６６】
割当の判断結果を指示する手段が割り当て指示手段８１７である。割り当て指示手段は、その指示を割り当て決定手段８１８に通知して最終的に通信資源の割り当てが決定する。以上の各手段は、端末内のバス８１９を介して接続されている。端末（Ａ）２０１，端末（Ｂ）３０１，端末（Ｃ）４０１はいずれも本構成を備える。
【０１６７】
現在、ユーザＡは、ユーザＢと音声の両方向通信を行っているとする。互いに使っている通信資源は、スピーカとマイクである。このコールの端末（Ａ）２０１でのＣＣＢを図２１に示す。また、この時点での端末（Ａ）２０１の通信資源管理テーブルを図２２に示す。
【０１６８】
ここで、ユーザＣからユーザＡに緊急な要件が発生し、ユーザＡと音声の双方向通信をする必要が出来たと仮定する。このとき、ユーザＣは端末（Ｃ）４０１のＨＭＩ制御手段８１５にスピーカとマイクを使用した音声の双方向通信を要求する。これにより端末（Ｃ）４０１では通信資源の確保とＣＣＢの生成を行ない、当該通信資源の確保とＣＣＢの生成に成功したならば、次に端末（Ｃ）４０１の通信制御手段８１１は端末（Ａ）２０１の通信制御手段８１１に音声の双方向通信を要求することになる。
【０１６９】
この要求を受けた端末（Ａ）２０１の通信制御手段８１１は、スピーカとマイクを使用する音声の双方向通信のコールに関するＣＣＢの作成を端末（Ａ）２０１のＣＣ制御手段８１３に要求する。この要求により端末（Ａ）２０１のＣＣ制御手段８１３はスピーカとマイクの使用が可能であるかを端末（Ａ）２０１の通信資源管理手段８１２に問合わせる。
【０１７０】
端末（Ａ）２０１の通信資源管理手段８１２は、通信資源管理テーブル（図２１）を参照することにより、それは既にユーザＡとユーザＢとの間のコールリファレンス１の通信で使われていることを知る。そして、当該通信資源管理手段８１２は端末（Ａ）２０１のＣＣ制御手段８１３に対して、先に要求された通信資源が、コールリファレンス１のコールによって使用されているので要求された通信資源は解放できない旨を通知する。
【０１７１】
すると端末（Ａ）２０１のＣＣ制御手段８１３は、端末（Ａ）２０１の通信資源表示手段８１２に現在の通信資源の種別、使用量と要求されている通信資源の種別、使用量を表示するように要求する。通信資源表示手段８１２の表示例を図２３に示す。
【０１７２】
図２３の表示をユーザＡは端末（Ａ）２０１の通信資源表示手段８１２に表示された現在の通信資源の種別、使用量、要求されている通信資源の種別、使用量を見ることで、通信資源の割り当てを決定する。
【０１７３】
ここでは、ユーザＡは、ユーザＣとの通信に要求された通信資源を全てユーザＣとの通信に割り当てることに決めたと仮定する。するとユーザＡは、その決定内容を端末（Ａ）２０１の割り当て指示手段８１７に指示する。
【０１７４】
割り当て指示手段８１７のヒューマン‐マシンインタフェース部を図２４に示す。９０１は、割り当て指示手段インタフェース部全体である。９０２は、競合している通信資源の名前を表示するパネルである。
【０１７５】
今の場合、スピーカとマイクが端末（Ｃ）４０１から要求されているので、この二つの入出力装置がパネル９０２に表示される。９０３は、選択ボタンを表し、選択したい端末のボタンを押すことで、その端末に通信資源を割り当てることができる。
【０１７６】
９０４は、割り当ての対象になる端末を表示するパネルである。今の場合は２つの端末間での通信資源の割り当てを問題にしているが、選択ボタン９０３と端末表示パネル９０４との組を複数組にすれば、その数分の端末間での通信資源の割り当てを解決することができる。また、本例では端末（Ｃ）４０１から要求される通信に通信資源を全て割り当てたが、９０１の割り当て指示手段インタフェース部に通信資源をどのくらいの割合で割り当てるかを指示するパネルを付加すれば、任意の割合で通信資源を通信に割り当てることもできる。
【０１７７】
ここでは、端末（Ｃ）４０１に割り当てることにしたので、端末（Ｃ）４０１とパネルに表示されている図２４の選択ボタン９０３をユーザＡは押す。すると割り当て指示手段８１７はその結果をバス８１９を経由して割り当て決定手段８１８に通知する。このあとの流れは、第５の具体例と同様である。
【０１７８】
但し、ＣＣＢの作成においては、本例では優先度の設定は行なわれない。
【０１７９】
このように、既に確立している通信によって使用されている通信資源に対して、新たな通信がその通信資源の使用を要求した場合、どちらの通信に対して通信資源を割り当てるかをユーザに判断させて指定させ、その指定に基づいて、通信資源を割り当てるようにしたので、ユーザサイドに立っての通信ができるようになり、ユーザの意図しないままに、不意に現在の通信が切られて新たな通信に切り換えられてしまうといったことを防止できる。
【０１８０】
以上、第４ないし第６の具体例は、端末と通信網で利用可能な通信資源の状態を管理する通信資源管理手段を設けるようにし、その通信資源管理手段の提供する通信資源の状態に基づいてコールやコネクションを制御するコール・コネクション制御手段を設ける構成としたものである。
【０１８１】
また、第１の通信により通信資源の一部又は全てが確保され使用されている際に、第２の通信の要求が発生し、第１の通信により確保されている通信資源の一部、もしくは全部が要求された場合、所定の判定基準に従って、第１と第２の通信に割り当てる通信資源を決定する割り当て決定手段を備え、前記割り当て決定手段の結果に基づき第１と第２の通信を制御するようにしたものである。
【０１８２】
また、上記の割り当て決定手段を備える通信システムにおいて、現在の通信資源の種別、使用量と第２の通信により要求されている通信資源の種別、使用量を表示する手段と、前記表示手段により表示された情報をもとに端末使用者が通信資源の割り当て量の指示を前記割り当て決定手段に与える割り当て指示手段とを備えるようにしたものである。
【０１８３】
そしてこのような構成によれば、通信資源管理手段は端末と通信網で利用可能な通信資源の状態を管理しており、この通信資源管理手段の提供する通信資源の状態に基づいて、コール・コネクション制御手段が通信装置内でコールやコネクションの制御を行なうことができる。これにより端末と通信網で利用可能な通信資源の状態を考慮したコールやコネクションの制御を行うことができ、マルチメディアに対しても柔軟に対応できる。また、第１の通信により通信資源の一部又は全部が確保され使用されている際に、第２の通信の要求が発生し、第１の通信により確保されている通信資源の一部、もしくは全部が要求された場合、所定の判定基準に従って、第１と第２の通信に割り当てる通信資源を決定する割り当て決定手段を通信システム内に設けることにより、より重要な通信を優先することができるようになる。
【０１８４】
また、上記通信システムで現在の通信資源の種別、使用量と第２の通信に要求されている通信資源の種別、使用量を表示する表示手段と、前記表示手段の表示をもとに端末使用者が通信資源の割り当て量の指示を前記割り当て決定手段に与える割り当て指示手段とを備えることにより、上記所定の判定基準が特に端末使用者の意志である場合に対応できるようになる。
【０１８５】
ゆえに、第４ないし第６の具体例によれば、端末で利用可能な通信資源や通信網で利用可能な通信資源を考慮してコールやコネクションを制御できるので、ユーザは通信相手の端末で使用可能な資源などを知らなくても発呼することが出来る。もし相手端末の能力が低く、発呼の要求に応えられない場合は、その旨が通知される。また、コール同士で通信資源の競合が起こった時に、何らかの判定基準に従い通信資源の割当を行なうことにより、重要な、また緊急なコールを優先することが可能となる。
【０１８６】
（第７の具体例）
既に説明しているように、あるサービス制御手段（アプリケーション）が、そのサービスを実行する際に、他の端末上の資源を必要とする場合には、当該他の端末において当該資源が他のサービス制御手段等によって占有されていることがあるが、従来の通信システムにおいては、端末資源の空塞はサービス制御手段にとっては回線の空塞として認識されるのみであり、端末が保有する個々の資源の空塞状況を認識することはできなかった。
【０１８７】
そこで本件の発明者らは、サービス制御手段がサービス制御に先だって、他の端末上の資源を制御しているサービス制御手段または当該資源を管理している資源管理手段に対して資源獲得を要求するための情報を送信してネゴシエーション（折衝；端末の使用条件を折衝し、変更する等の処理）を行なう方式を提案した。
【０１８８】
図３３にこの提案技術における資源獲得の手順の一つの例を示す。
【０１８９】
サービス制御手段はまず、資源獲得のためのネゴシエーションを行なうためのコネクションを要求資源を管理する資源管理手段などとの間に設定し（図３３中ステップＳ９‐２）、該コネクションを使用して前記資源管理手段とネゴシエーションを行なう（ステップＳ９‐３）。ネゴシエーションの結果、要求資源が獲得できたならば（ステップＳ９‐４でＹＥＳの場合）、ネゴシエーション用のコネクションを解放し（ステップＳ９‐５）、獲得資源との間に改めて通信コネクションを設定するなどの手順を行ない（ステップＳ９‐６）、サービスを開始する（ステップＳ９‐７）。ネゴシエーションの結果、要求資源が獲得できないならば（ステップＳ９‐４でＮＯの場合）、ネゴシエーション用のコネクションを解放し（ステップＳ９‐８）、サービスを中止する（ステップＳ９‐９）。
【０１９０】
このように、ネゴシエーションにより端末資源の使用状況を把握し、それに基づいて資源の獲得を行なうようにすることで、それ以前の通信システムに比べてより効率的に資源の獲得を行なうことが可能となったが、資源獲得のネゴシエーションを行なうためにネゴシエーション用通信コネクションの設定、解放の処理が必要であった。
【０１９１】
また、この技術による資源獲得の手順として、ネゴシエーション用のコネクションを設けずに（コネクションレス通信で）資源を要求する方式も考えられるが、その場合でもネゴシエーションの結果設定されるコネクションの設定手順以外に、ネゴシエーションのためのメッセージの送受が必要である。
【０１９２】
また、例えばレイヤ３のＵＮＩプロトコルに、ＩＴＵ‐Ｔ（旧ＣＣＩＴＴ）の勧告Ｑ‐２９３１の手順を用いる従来の通信システムにおいては、通信コネクション設定のためのシグナリング・メッセージ中に接続先端末まで透過的に送達される情報要素として、Broadband hign layer情報要素が設けられており、本情報要素は通信コネクションの設定要素を受けた受信側端末において当該通信コネクションの接続可否を判定する判断基準の一つに用いられている。
【０１９３】
しかし、その場合の接続可否の判定は、送受信端末間の整合性の有無という観点でなされるものであり、その時々の資源の空塞に基づいてなされるわけではない。
【０１９４】
このように、計算機端末であるパーソナルコンピュータやＥＷＳに代表される端末の高機能化、サービスのマルチメディア化が進むにつれ、サービス制御において音声／画像入出力装置などの端末資源を使用する必要性が高まるが、これらの端末資源は、通信サービスを提供するサービス制御手段だけでなく、端末上で稼働する種々のアプリケーションによっても使用されるため、サービス制御手段は必ずしもサービスに必要な資源が使用できるとは限らないため、サービス制御に先だって当該資源の獲得のためのネゴシエーションを行なう必要がある。
【０１９５】
しかし、従来の通信システムにおいてはサービス制御で使用する通信コネクションとは別にネゴシエーション用のコネクションを設定する必要があり、また、このようにして設定したコネクションを利用してネゴシエーションを行なった際に資源が獲得できなかった場合には、後に資源が獲得できるようになった際に、通知を受けるということにより、無駄に資源の獲得を試みることを避けることができるようになるが、この通知を受けるためにもコネクションを設定する必要があった。
【０１９６】
このように、資源獲得のための通信コネクションをサービス制御のために使用する通信コネクション以外に設ける必要があり、資源獲得のための処理が多くなるという問題点があったが、これを解決し、端末資源の獲得処理を効率的に実現する例をつぎに述べる。
【０１９７】
第７の具体例に係る通信システムのハードウェアの構成を図２５に示す。
【０１９８】
図２５に示すように、計算機端末１００１‐１００１〜１‐ｎは通信網１００２を介して相互に接続されている。前記計算機端末１００１‐１〜１００１‐ｎには、音声の入出力装置としてマイクロフォン１００５、スピーカ１００６が、画像の入出力装置としてカメラ１００３、ディスプレイ装置１００４がそれぞれ接続されている。これらの計算機および各種入出力装置を用いて、遠隔会議サービスを実現するという場合を例にとって説明する。
【０１９９】
まず、本システム内のソフトウェアの構成について説明する。
【０２００】
図２６に本システム内のソフトウェアの構成を示す。会議の参加者各自が使用する前記各計算機端末１００１‐１〜１００１‐ｎはサービス制御手段１００７として、会議サービスを実現するプログラム（以降会議アプリケーションと呼ぶ）が実装されている。これらの各種プログラム以外に前記計算機端末１００１‐１〜１００１‐ｎ上では会議アプリケーション以外のプログラム（以降、これを他アプリケーションと呼ぶ）１００８も同時に稼働している。
【０２０１】
さらに、前記計算機端末１００１‐１〜１００１‐ｎのそれぞれには、各種入出力装置やディスク装置などの資源を管理する端末資源管理手段１００９としてのプログラム（以降リソースマネージャと呼ぶ）が稼働している。
【０２０２】
図２７にリソースマネージャの構成を示す。
リソースマネージャは、端末資源の使用状況を管理する機能を有し、リソース使用状況管理手段１０１０と、どのサービス制御手段からどのようなリソースを要求されたかを記憶するリソース要求情報記憶手段１０１１と、要求されたリソースの空塞を判断するための要求リソース空塞判断手段１０１２とを持つ。
【０２０３】
次に、このような構成において、本発明の主眼であるリソース確保の様子を以下に説明する。図２９〜図３０に会議アプリケーションがリソースを獲得してサービスを開始するまでの処理の流れを示す。図２９は会議アプリケーションの処理の流れを示す図であり、図３０はリソースマネージャの処理の流れを示す図である。
【０２０４】
まず、計算機端末１００１‐１〜１００１‐ｎのうちのいずれかの計算機端末において会議アプリケーションが起動される（図２９中ステップＳ５‐１）。起動された会議アプリケーションは、通信路（ネットワーク１００２）を介して接続された会議に参加する参加者の計算機端末を接続するための通信コネクションと、会議に使用する各種入出力装置とを獲得しようとする。
【０２０５】
ここでは、ある計算機端末上の会議アプリケーションが他計算機端末上の資源、例えばスピーカに対してコネクションを設定する場合を例にとって説明する。
【０２０６】
遠隔会議に必要な他の端末資源との接続に関しても手順は同様であり、各計算機端末間に音声、画像それぞれの入出力装置間（マイクロフォンとスピーカ、カメラとディスプレイ装置）にコネクションを設定することにより遠隔会議サービスに必要な通信環境を設定する。
【０２０７】
また、遠隔会議サービスの実現には端末資源だけでなく、網資源（帯域など）も必要であるが、ここでは端末資源の獲得に関する側面のみについて説明する。網資源に関しても例えば網資源の制御が可能な計算機端末上に網資源の管理を行なうリソースマネージャを設けることにより、同様の手順を適用して資源獲得を行なうことが可能である。
【０２０８】
なお、ここでは、コネクションを設定するためのシグナリング・プロトコルとしてＩＴＵ‐Ｔ（旧ＣＣＩＴＴ）のレイヤ３ＵＮＩに関する勧告Ｑ‐２９３１を仮定する。
【０２０９】
（１）［要求資源が空きの場合］
図３１に会議アプリケーションが資源を要求する場合のシグナリング・シーケンスを示す。シグナリング・メッセージを実際に送受するのは送受信端末上およびネットワーク内にそれぞれ存在するシクナリング・エンティティであるが、図３１ではシグナリング・メッセージ中のネゴシエーション情報の送受に主眼をおいて説明するため、シグナリング・メッセージの送受する主体を会議アプリケーション、ネットワーク、リソースマネージャと表示している。図３２に示すシグナリング・シーケンスに関しても同様である。
【０２１０】
会議アプリケーションは、会議相手端末およびその上の音声、画像などの入出力装置の一つ（ここではスピーカ）を選び、まず自計算機端末上のシクナリング・エンティティに依頼して、前記会議相手端末上のリソースマネージャに宛てて必要な帯域をもったコネクションの設定を開始するためのシグナリング・メッセージＳＥＴＵＰを送信する（図３２中メッセージｍ８‐１、図２９中ステップＳ５‐２）。ＳＥＴＵＰメッセージ中のBroadband high layer information情報要素に設定された情報は網内のシクナリング・エンティティを介して通信相手端末のエンティティにまで透過的に送達されるので、本フィールドを必要資源獲得のためのネゴシエーションに用いる。ここでは、Broadband high layer information情報要素（以降Ｂ‐ＨＬＩ情報要素と記す）に次の各情報を設定する。
【０２１１】
・要求ｉｄ ：同一サービス制御手段にもたらされる複数の資源要求を識別するための識別子
・要求資源ｉｄ ：当該コネクションを介して接続する相手端末上の資源を表す識別子
・空き待ち要求スイッチ ：要求資源が塞がりの場合に空き待ちを希望するか否かを示す２値的な値（ＯＮ／ＯＦＦ）
上述の要求ｉｄは、サービス要求元のサービス制御手段（会議アプリケーション）とリソースマネージャとの間で一意に識別できるような識別子であればよく、例えば会議アプリケーションの識別子と要求を発した時刻とを組み合わせた値などとする方法が考えられる。また、ここでは要求資源ｉｄには音声出力装置（スピーカ）を表す”audio-out ”を、空き待ち要求スイッチには空き待ちを要求することを表す”ＯＮ”をそれぞれ設定するものとする。
【０２１２】
相手端末上のリソースマネージャはシグナリング・エンティティから、前記Ｂ‐ＨＬＩ情報要素に設定された情報を受けとり（図３０中ステップＳ６‐１）、要求ｉｄ、要求資源ｉｄおよび空き待ち要求スイッチの値をリソース要求情報記憶手段に記憶し（ステップＳ６‐２）、記憶されたリソースの空塞を要求リソース空塞判断手段により判断する（ステップＳ６‐３）。
【０２１３】
リソース要求情報記憶手段は、要求されたリソースが塞がりの場合に、空き待ちを行なう際に使用するテーブルであり、その構成を図２８に示す。要求リソース空塞判断手段は、要求された資源（スピーカ）が他アプリケーションなどによって占有されていないかどうかを調べ、その結果、当該資源（スピーカ）が使用可能であれば（ステップＳ６‐３で空きの場合）、以降のコネクション設定手順において当該資源（スピーカを駆動するためのプログラム）と接続するコネクションの設定を行なう（図３０中ステップＳ６‐４、図３１中メッセージｍ７‐２およびそれ以降、図２９中ステップＳ５‐４およびＳ５‐５）。
【０２１４】
（２）［要求資源が塞がりの場合］
次に、要求した資源が塞がりであった場合の処理について説明する。上述の要求資源が空きの場合と同様に、まず会議アプリケーションは自計算機端末上のシグナリング・エンティティに依頼して、会議相手端末上のスピーカ（を駆動するプログラム）に対して必要な帯域を持ったコネクションの設定を開始するためのシグナリング・メッセージＳＥＴＵＰを、相手端末上のスピーカを管理するリソースマネージャに宛てて送信する（図２９中ステップＳ５‐２、図３２中メッセージｍ８‐１）。
【０２１５】
メッセージＳＥＴＵＰのＢ‐ＨＬＩ情報要素には先の説明と同様に要求する資源を表す情報が設定される。相手端末上のリソースマネージャはシグナリング・エンティティから前記Ｂ‐ＨＬＩ情報要素に設定された情報を受けとり（図３０中ステップＳ６‐１）、要求ｉｄ、要求資源および空き待ちスイッチの値をリソース要求情報記憶手段に記憶し（ステップＳ６‐２）、記憶されたリソースの空塞を要求リソース空塞判断手段により判断する（ステップＳ６‐３）。
【０２１６】
要求リソース空塞判断手段が要求資源（スピーカ）の空塞を判断した結果、当該資源が使用不可能な場合（ステップＳ６‐３で塞がりの場合）、リソースマネージャはシグナリング・エンティティに依頼して、当該コネクション設定手順を中止すべく、ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッセージを送信し、以降当該コネクションの解消手順を実行する（ステップＳ６‐５、メッセージｍ８‐２）。
【０２１７】
この際、資源要求元サービス制御手順からのＳＥＴＵＰメッセージにおける空き待ち要求スイッチの値が”ＯＦＦ”である場合には（ステップＳ６‐６でＯＦＦの場合）、リソース要求情報記憶手段の該当資源のエントリを削除し（ステップＳ６‐１０）、本要求資源に関する処理を終了する（ステップＳ６‐１１）。
【０２１８】
リソースマネージャは前記リソース要求情報記憶手段に削除されずに残っている資源（本実施例の場合のスピーカ）については空き待ちを行ない（ステップＳ６‐７）、これらの資源の空きを検知した場合（ステップＳ６‐８でＹＥＳの場合）には、シグナリング・エンティティに依頼してシグナリング・メッセージＳＥＴＵＰを用いて前記要求元サービス制御手段に資源の空きを通知する（ステップＳ６‐９、メッセージｍ８‐３）。
【０２１９】
この場合のＳＥＴＵＰメッセージ中のＢ‐ＨＬＩ情報要求フィールドには、前記リソース要求情報記憶手段から得た要求ｉｄ、資源ｉｄおよび空き待ち応答であることを表す値を設定する。
【０２２０】
この後、リソースマネージャは、リソース要求情報記憶手段中の当該リソースに関するエントリを削除した後（ステップＳ６‐１０）、当該資源に関する処理を終了する（ステップＳ６‐１１）。
【０２２１】
一方、リソースマネージャから要求資源の空きを自計算機端末のシクナリング・エンティティを介して受信した資源要求元の会議アプリケーションは、Ｂ‐ＨＬＩ情報要素の空き待ち応答を表す値および要求ｉｄを参照することにより、空き待ちを要求していた資源（スピーカ）に対する空き通知を受信したことを認識し（ステップＳ５‐９でＹＥＳの場合）、シグナリング・エンティティに依頼して一旦そのＳＥＴＵＰに対してはＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッセージで応答した後、改めてＳＥＴＵＰメッセージによりコネクションの設定を開始する（ステップＳ５‐２）。
【０２２２】
このコネクションの設定開始以降の手順は会議アプリケーション起動時と同様の手順である。
【０２２３】
以上のようにしてサービス制御に使用する端末資源の要求をシグナリング手順を実施する中で行なえるので（図２９中のステップＳ５‐１０）、資源獲得のネゴシエーションのために別途コネクションを設定することなく、端末資源個別にその空塞状況を知ることができる。また、要求資源が塞がりの場合には空き待ちも行なうこともできるため、端末資源を利用率の向上が期待できる。
【０２２４】
このように、第７の具体例は、通信網の資源または通信網に接続された機器の資源を制御してサービスを実現するサービス制御手段を有する通信システムにおいて、サービス制御手段が、サービス制御に必要な資源を表す情報を、通信コネクション設定の際のシグナリング・メッセージ内に設定することにより、他のサービス制御手段または資源管理手段に宛てて送信し、該情報を受信したサービス制御手段または資源管理手段は、要求された資源を前記要求元サービス制御手段に割り当てるかどうかを判断し、割り当てると判断した場合には要求された資源を要求元ービス制御手段に割り当てて前記通信コネクション設定手順を引続き行ない、割り当てないと判断した場合は、前記通信コネクションの設定を中止するようにしたものであり、また、更には資源要求元サービス制御手段から要求された資源を割り当てないと判断した場合にはサービス制御手段または資源管理手段はその後、前記要求資源を割り当てると判断したときに、割り当て可能であることを前記要求元サービス制御手段との通信コネクション設定のためのシグナリング・メッセージに設定することにより要求元サービス制御手段に通知するようにしたものである。
【０２２５】
そして、このようなシステムにおいては、サービス制御に必要な資源を表す情報を、通信コネクション設定の際のシグナリング・メッセージ内に設定して他のサービス制御手段または資源管理手段に宛てて要求し、該情報を受信したサービス制御手段または資源管理手段が、前記要求資源を前記要求元サービス制御手段に割り当てるかどうかを判断し、その判断結果を通信コネクション設定のためのシグナリング・メッセージ内に設定して応答することにより、資源要求元サービス手段が他端末上の資源の空塞状況を効率的に把握することを可能としたものである。
【０２２６】
また、サービス制御手段からの要求資源が塞がりであった場合に、必要に応じて、当該資源の要求を受けた前記サービス制御手段または資源管理手段が当該資源の空きを、シグナリング・メッセージを用いて前記要求元サービス制御手段に通知することにより、通信コネクションを確立することなく空き通知が行なうことができるため、一度資源の獲得に失敗したサービス制御手段が効率的に資源を獲得することが可能となって、資源の利用効率の向上が期待できるものである。
【０２２７】
特に本例によれば、通信システムにおいて、あるアプリケーションが必要とする他端末リソースが他のアプリケーションにより確保されているかどうかを、当該リソースへのコネクション設定時点で検知することができ、リソース獲得のための手順を網リソース獲得のためのシグナリング手順の中で行なうことができ、また、要求資源の塞がり時には空き待ちを行なうこともできるため、従来のようにネゴシエーションや空き通知のために別途コネクションを設ける必要がなく、効率的にリソースの獲得処理を実現することができる。
【０２２８】
【発明の効果】
以上、詳述したように本発明によれば、実質的に使用を終え、解放され得る資源が解放されないことによって当該資源を必要とする別のサービスの実現を阻害するという問題を解決することができるようになる。
【０２２９】
また、通信システムにおいて、あるアプリケーションが必要とする他端末リソースが他のアプリケーションにより確保されているかどうかを、当該リソースへのコネクション設定時点で検知することができ、リソース獲得のための手順を網リソース獲得のためのシグナリング手順の中で行なうことができ、また、要求資源の塞がり時には空き待ちを行なうこともできるため、従来のようにネゴシエーションや空き通知のために別途コネクションを設ける必要がなく、効率的にリソースの獲得処理を実現することができるようになる。
【図面の簡単な説明】
【図１】本発明の説明をするための図であって、本発明の第１の具体例を示す図。
【図２】本発明の説明をするための図であって、本発明の第１の具体例における資源管理手段の構成を表す図。
【図３】本発明の説明をするための図であって、本発明の第１の具体例におけるサービス制御手段の処理を表す図。
【図４】本発明の説明をするための図であって、本発明の第２の具体例を表す図。
【図５】本発明の説明をするための図であって、本発明の第２の具体例におけるサービス制御手段の構成を表す図。
【図６】本発明の説明をするための図であって、本発明の第２の具体例におけるサービス制御手段の処理を表す図。
【図７】本発明の説明をするための図であって、本発明の第３の具体例を表す図。
【図８】従来の通信システムにおける資源獲得のための処理を表す図。
【図９】本発明の説明をするための図であって、本発明の第４の具体例を説明するためのシステム構成図。
【図１０】本発明の説明をするための図であって、本発明における端末（Ａ）の構成例を示す図。
【図１１】本発明の説明をするための図であって、本発明の作用を説明するためのフロー図。
【図１２】本発明の説明をするための図であって、本発明において使用する通信資源管理テーブル例を示す図。
【図１３】本発明の説明をするための図であって、本発明の第４の具体例において使用するＣＣＢフォーマット図。
【図１４】本発明の説明をするための図であって、本発明の第４の具体例において使用する端末（Ａ）のＣＣＢの例を示す図。
【図１５】本発明の説明をするための図であって、変更後の通信資源管理テーブルの例を示す図。
【図１６】本発明の説明をするための図であって、本発明の第５の具体例において使用する端末の構成例を示す図。
【図１７】本発明の説明をするための図であって、本発明の第５の具体例において使用するＣＣＢのフォーマット例を示す図。
【図１８】本発明の説明をするための図であって、本発明の第５の具体例において使用する端末（Ａ）のＣＣＢの例を示す図。
【図１９】本発明の説明をするための図であって、本発明の第５の具体例において使用する端末（Ａ）の通信資源管理テーブルの例を示す図。
【図２０】本発明の説明をするための図であって、本発明の第６の具体例において使用する端末の構成例を示す図。
【図２１】本発明の説明をするための図であって、本発明の第６の具体例において使用する端末（Ａ）の通信資源管理テーブル例を示す図。
【図２２】本発明の説明をするための図であって、本発明の第６の具体例において使用する端末（Ａ）のＣＣＢの例を示す図。
【図２３】本発明の説明をするための図であって、本発明の第６の具体例において使用する通信資源表示例。
【図２４】本発明の説明をするための図であって、本発明の第６の具体例において使用する割り当て指示手段インタフェース例を示す図。
【図２５】本発明の説明をするための図であって、本発明の第７の具体例における通信システムのハードウェア構成例を示す図。
【図２６】本発明の説明をするための図であって、本発明の第７の具体例における通信システムのソフトウェア構成を表す図。
【図２７】本発明の説明をするための図であって、本発明の第７の具体例におけるリソースマネージャの構成を表す図。
【図２８】本発明の説明をするための図であって、本発明の第７の具体例におけるリソース要求情報記憶手段を示す図。
【図２９】本発明の説明をするための図であって、本発明の第７の具体例における会議アプリケーションの資源獲得処理の流れを表す図。
【図３０】本発明の説明をするための図であって、本発明の第７の具体例におけるリソースマネージャの処理の流れを表す図。
【図３１】本発明の説明をするための図であって、本発明の第７の具体例におけるシグナリング・メッセージの送信シーケンスを表す図（資源が空きの場合）。
【図３２】本発明の説明をするための図であって、本発明の第７の具体例におけるシグナリング・メッセージの送信シーケンスを表す図（資源が塞がりの場合）。
【図３３】従来技術を説明をするための図であって、第７の具体例における前提となる従来方式でのサービス制御手段の資源獲得処理の流れを表す図。
【符号の説明】
１‐１〜１‐ｎ…計算機
２…通信路
３…サービス制御手段
４…端末資源管理手段
５…網資源管理手段
６…画像入力手段
７…画像出力手段
８…音声入力手段
９…音声出力手段
１０…資源要求情報保持手段
１１…要求資源空塞判断手段
１２…解放要求先サービス制御手段決定手段
１３…資源使用状況管理手段
１４…資源獲得・解放手段
１５…資源制御手段
１０１…ネットワーク、
２０１…端末（Ａ）
２０２，３０２…ディスプレイ
２０３，３０３，４０３…スピーカ
２０４，３０４，４０４…マイクロフォン
３０１…端末（Ｂ）
４０１…端末（Ｃ）
４０２…ビデオ再生装置
２１１…通信制御手段
２１２…入出力装置制御手段
２１３，６１４，８１３…通信資源管理手段
２１４，６１５，８１２…ＣＣ制御手段（コール・コントロール制御手段）
２１５…ＨＭＩ制御手段
２１６，６１７，８１９…バス
５０１…コールリファレンス書き込みフィールド
５０２…通信相手書き込みフィールド
５０３…通信資源書き込みフィールド
６１１，８１１…通信制御手段
６１２…割り当て決定手段
６１３…入出力装置制御手段
６１６，８１５…ＨＭＩ制御手段
７０１…コールリファレンス書き込みフィールド
７０２…通信相手書き込みフィールド
７０３…通信資源書き込みフィールド
７０４…優先度書き込みフィールド
８１４…入出力装置制御手段
８１６…通信資源表示手段
８１７…割り当て指示手段
８１８…割り当て決定手段
９０１…割り当て指示手段インタフェース
９０２…競合通信資源表示パネル
９０３…選択ボタン
９０４…端末表示パネル。
１００１‐１〜‐１００１‐ｎ…計算機
１００２…通信路（ネットワーク）
１００３…画像入力装置
１００４…画像出力装置
１００５…音声入力装置
１００６…音声出力装置
１００７…会議アプリケーション
１００８…他アプリケーション
１００９…リソースマネージャ
１０１０…リソース使用状況管理手段
１０１１…リソース要求情報記憶手段
１０１２…要求リソース空塞判断手段

Claims (1)

1. 通信網の帯域及び当該通信網に接続された複数の端末のそれぞれが有する各種資源を使用して異なる複数のサービスをそれぞれ提供する複数のサービス制御手段と、前記帯域の使用状況を管理する網資源管理手段とを備えた通信システムにおいて、
   前記複数のサービス制御手段のそれぞれは、
   当該サービス制御手段が確保している前記帯域及び前記端末資源に対し、他のサービス制御手段のための前記帯域及び端末資源の解放要求を受けたとき、（１）要求された帯域・端末資源を解放しても予め設定されたサービス品質の許容範囲を満たす場合、（２）要求された帯域・端末資源の解放の可否をユーザに尋ねる情報を表示し、ユーザからの当該帯域・端末資源の解放が許可された場合、（３）前記他のサービス制御手段の優先順位が当該サービス制御手段の優先順位よりも高い場合、（４）要求された帯域・端末資源を一定時間使用していない場合、（５）ユーザにより予め解放要求の受付を受け付ける旨の設定がされている場合、のうちのいずれか１つに該当するときには、要求された前記帯域及び前記端末資源を解放して前記他のサービス制御手段のために割り当てられる状態にする資源解放手段を備え、
   前記網資源管理手段は、
   前記他のサービス制御手段から、そのサービスを提供するために必要とする前記帯域の獲得要求を受けて、前記通信網の使用状況から、要求された前記帯域を確保できるか否かを判定する手段と、
   要求された前記帯域を確保できるときは、確保要求元のサービス制御手段のために、前記帯域を確保し、前記他のサービス制御手段に端末資源の獲得要求を送信する手段と、
   要求された前記帯域を確保できないときは、前記通信網を現在確保しているサービス制御手段のなかから、最近一定期間の前記通信網上でのトラヒックの無いサービス制御手段を選択して、選択されたサービス制御手段に対し前記通信網上の帯域の解放要求を送信する手段と、
   を備えたことを特徴とする通信システム。

Images