(57)【要約】【課題】経路を構成するリンクの容量が不足する場合でも、すでに確保されているリソースの積極的な解放を待たずに、別のユーザがリソース確保できるようにする。【解決手段】リソース確保要求から評価値を取得するステップＳ３と、リソース確保を要求された経路を構成するリンクを特定するステップＳ６と、特定したリンクのそれぞれにおいて、リンクの総リソース量を超えない範囲内で、評価値が高いリソース確保要求に対しリソース確保が可能と判定するステップＳ８と、すべてのリンクでリソース確保が可能と判定された経路に対し、リソース確保が可能と判定するステップＳ１２とを備える。【選択図】  図１０
2006295461.tif 000002
【特許請求の範囲】
【請求項１】
１以上のリンクとノードとからなる任意の対地間の経路について、ある時刻から所定時間、要求された容量のリソース確保が可能か否かを判定するリソース確保判定方法であって、
前記経路についてリソース確保を要求する個々のリソース確保要求から評価値を取得するステップと、
前記経路を構成するリンクを特定するステップと、
前記リンクのそれぞれにおいて、前記リンクの総リソース量を超えない範囲内で、前記評価値が高いリソース確保要求に対しリソース確保が可能と判定するステップと、
すべてのリンクでリソース確保が可能と判定された経路に対しリソース確保が可能と判定するステップと
を備えることを特徴とするリソース確保判定方法。
【請求項２】
請求項１に記載のリソース確保判定方法において、
リソース確保が可能と判定されたリンクにおいて前記要求された容量のリソース確保を行うステップをさらに備えることを特徴とするリソース確保判定方法。
【請求項３】
請求項２に記載のリソース確保判定方法において、
前記リンクにおいてリソース確保が行われた後で、新たに受信したリソース確保要求によってリソース確保が不可能と判定されたときに、確保されたリソースを解放するステップをさらに備えることを特徴とするリソース確保判定方法。
【請求項４】
請求項１〜３のいずれか１項に記載のリソース確保判定方法において、
取得された前記評価値に所定の係数を乗算して前記評価値を再計算するステップをさらに備え、
前記リンクにおいてリソース確保が可能と判定するステップは、再計算された前記評価値を用いて判定することを特徴とするリソース確保判定方法。
【請求項５】
請求項４に記載のリソース確保判定方法において、
前記係数は、前記要求された容量の逆数に比例する値であることを特徴とするリソース確保判定方法。
【請求項６】
請求項４または５に記載のリソース確保判定方法において、
前記係数は、前記リンクにおいて利用可能な残りのリソース量に応じて変化する値であることを特徴とするリソース確保判定方法。
【請求項７】
請求項１に記載のリソース確保判定方法において、
リソース確保が可能と判定されなかったリンクを含む経路に対し、リソース確保が可能と判定されたリンクにおいて前記要求された容量のリソース確保を行うステップと、
リソースが確保された前記リンクの両端のノードに対し、前記経路を通過するパケットに設定された優先度の変更を指示するステップと
をさらに備えることを特徴とするリソース確保判定方法。
【請求項８】
請求項１〜７のいずれか１項に記載のリソース確保判定方法において、
前記評価値は、リソース確保によって支払われる単位時間あたりの金額であることを特徴とするリソース確保判定方法。
【請求項９】
請求項３に記載のリソース確保判定方法において、
前記新たに受信したリソース確保要求に支払われる料金を、解放されたリソースの確保を要求したユーザに還元するステップをさらに備えることを特徴とするリソース確保判定方法。
【請求項１０】
１以上のリンクとノードとからなる任意の対地間の経路について、ある時刻から所定時間、要求された容量のリソース確保が可能か否かを判定するリソース確保判定装置であって、
前記経路についてリソース確保を要求する個々のリソース確保要求から評価値を取得する評価値取得手段と、
前記経路を構成するリンクを特定するリンク特定手段と、
前記リンクのそれぞれにおいて、前記リンクの総リソース量を超えない範囲内で、前記評価値が高いリソース確保要求に対しリソース確保が可能と判定するリンク別リソース確保判定手段と、
すべてのリンクでリソース確保が可能と判定された経路に対しリソース確保が可能と判定する経路リソース確保判定手段と
を備えることを特徴とするリソース確保判定装置。
【請求項１１】
請求項１０に記載のリソース確保判定装置において、
リソース確保が可能と判定されたリンクにおいて前記要求された容量のリソース確保を行うリソース確保手段をさらに備えることを特徴とするリソース確保判定装置。
【請求項１２】
請求項１１に記載のリソース確保判定装置において、
前記リンクにおいてリソース確保が行われた後で、新たに受信したリソース確保要求によってリソース確保が不可能と判定されたときに、確保されたリソースを解放するリソース解放手段をさらに備えることを特徴とするリソース確保判定装置。
【請求項１３】
請求項１０〜１２のいずれか１項に記載のリソース確保判定装置において、
取得された前記評価値に所定の係数を乗算して前記評価値を再計算する評価値計算手段をさらに備え、
前記リンク別リソース確保判定手段は、再計算された前記評価値を用いて判定することを特徴とするリソース確保判定装置。
【請求項１４】
請求項１３に記載のリソース確保判定装置において、
前記係数は、前記要求された容量の逆数に比例する値であることを特徴とするリソース確保判定装置。
【請求項１５】
請求項１３または１４に記載のリソース確保判定装置において、
前記係数は、前記リンクにおいて利用可能な残りのリソース量に応じて変化する値であることを特徴とするリソース確保判定装置。
【請求項１６】
請求項１０に記載のリソース確保判定装置において、
リソース確保が可能と判定されなかったリンクを含む経路に対し、リソース確保が可能と判定されたリンクにおいて前記要求された容量のリソース確保を行うリソース確保手段と、
リソースが確保された前記リンクの両端のノードに対し、前記経路を通過するパケットに設定された優先度の変更を指示する優先度変更指示手段と
をさらに備えることを特徴とするリソース確保判定装置。
【請求項１７】
請求項１０〜１６のいずれか１項に記載のリソース確保判定装置において、
前記評価値は、リソース確保によって支払われる単位時間あたりの金額であることを特徴とするリソース確保判定装置。
【請求項１８】
請求項１２に記載のリソース確保判定装置において、
前記新たに受信したリソース確保要求に支払われる料金を、解放されたリソースの確保を要求したユーザに還元する料金還元手段をさらに備えることを特徴とするリソース確保判定装置。
【請求項１９】
請求項１〜９のいずれか１項に記載のリソース確保判定方法の各ステップをコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるリソースを管理するリソース管理方法および装置に関し、特に、要求された容量のリソース確保が可能か否かを判定する方法および装置に関する。
【背景技術】
【０００２】
通信ネットワーク、特にＩＰ（Internet  Protocol）ネットワークを利用して音声や映像などのコンテンツを提供する場合には、通信路の容量を超える利用要求によって輻輳が発生すると、パケットの損失等に伴い通信品質が劣化してしまう。このような通信品質の劣化を防ぐことを目的として、ネットワークレイヤにおけるリソース管理が研究されている。この種のリソース管理の一つに、通信ネットワークを構成するルータとは独立したリソース管理装置（リソース管理サーバ）を用いて、通信ネットワークを構成するノード間（リンク）のリソース量とその利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適切なリソースを払い出す方式がある。その従来例を以下に説明する。
【０００３】
通信ネットワークの運用開始前に、まず、その通信ネットワーク内のルーティング情報を収集する。このルーティング情報には、通信ネットワーク中の各リンクのリソース量および接続情報が含まれている。ついで、各リンクの接続情報を基にパケットが通過する経路を計算し、その計算結果を基に経路テーブルを作成する。また、各リンクのリソース量から、リンク情報テーブルを作成する。このリンク情報テーブルによって、各リンクの総リソース量と、利用可能な残リソース量が管理される。
【０００４】
通信ネットワークの運用開始後にあっては、リソース管理サーバにおいてリソース確保要求を受け付けると、要求された通信の発着ＩＰアドレスを基に、経路テーブルから当該通信の経路を構成するリンクを特定する。そして、リンク情報テーブルを参照し、特定されたリンクのそれぞれについて当該通信に必要な容量が利用可能か否かをチェックする。
その結果、特定されたすべてのリンクについて十分な容量が利用可能である場合には、リソース確保が可能であると判定する。そして、リソース確保要求に対して許諾応答するとともに、リンク情報テーブルにおいて、特定されたリンクの残リソース量から当該通信に割り当てられる容量を減算する処理を行う。逆に、いずれかのリンクについて利用可能な容量が不足する場合には、リソース確保が不可能であると判定し、リソース確保要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。
【０００５】
リソース確保要求の許諾応答を受けたユーザ端末は、予め設定されたサービス料金を支払って通信サービスを利用することで、リソースが確保され、通信品質が保証される。
その後、通信サービスの利用終了時には、それまで確保していたリソースを速やかに解放する。
【０００６】
【特許文献１】特開２００３−２５８８５５号公報
【非特許文献１】矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、従来の技術では先着順原理が採用され、経路を構成するリンクの容量が不足する場合には、すでに確保されているリソースの全部または一部が解放されるまで、別のユーザはリソース確保サービスを受けることができないという問題があった。このため、ある時刻にリソース確保サービスを受けたいユーザは、その時刻よりも前からリソースを確保し続ける必要があった。また、リソース確保サービスを多くのユーザに平等に提供するには、リソース管理サーバ側でユーザ一人あたりのサービス提供時間を制限しなければならなかった。
【０００８】
本発明は、このような課題を解決するためになされたものであり、その目的は、経路を構成するリンクの容量が不足する場合でも、すでに確保されているリソースの積極的な解放を待たずに、別のユーザがリソース確保できるようにすることにある。
【課題を解決するための手段】
【０００９】
このような目的を達成するために、本発明にかかるリソース管理方法は、１以上のリンクとノードとからなる任意の対地間の経路について、ある時刻から所定時間、要求された容量のリソース確保が可能か否かを判定するリソース確保判定方法であって、経路についてリソース確保を要求する個々のリソース確保要求から評価値を取得するステップと、経路を構成するリンクを特定するステップと、リンクのそれぞれにおいて、リンクの総リソース量を超えない範囲内で、評価値が高いリソース確保要求に対しリソース確保が可能と判定するステップと、すべてのリンクでリソース確保が可能と判定された経路に対しリソース確保が可能と判定するステップとを備えることを特徴とする。
【００１０】
このリソース確保判定方法は、リソース確保が可能と判定されたリンクにおいて要求された容量のリソース確保を行うステップをさらに備えていてもよい。
また、リンクにおいてリソース確保が行われた後で、新たに受信したリソース確保要求によってリソース確保が不可能と判定されたときに、確保されたリソースを解放するステップをさらに備えていてもよい。
【００１１】
また、上述したリソース確保判定方法は、取得された評価値に所定の係数を乗算して評価値を再計算するステップをさらに備え、リンクにおいてリソース確保が可能と判定するステップは、再計算された評価値を用いて判定するようにしてもよい。
ここで、上記係数として、要求された容量の逆数に比例する値を用いることができる。また、上記係数として、リンクにおいて利用可能な残りのリソース量に応じて変化する値を用いることもできる。
【００１２】
また、上述したリソース確保判定方法は、リソース確保が可能と判定されなかったリンクを含む経路に対し、リソース確保が可能と判定されたリンクにおいて要求された容量のリソース確保を行うステップと、リソースが確保されたリンクの両端のノードに対し、経路を通過するパケットに設定された優先度の変更を指示するステップとをさらに備えていてもよい。
【００１３】
また、リソース確保によって支払われる単位時間あたりの金額を評価値として用いることができる。
また、上述したリソース確保判定方法は、新たに受信したリソース確保要求に支払われる料金を、解放されたリソースの確保を要求したユーザに還元するステップをさらに備えていてもよい。
【００１４】
また、本発明にかかるリソース確保判定装置は、１以上のリンクとノードとからなる任意の対地間の経路について、ある時刻から所定時間、要求された容量のリソース確保が可能か否かを判定するリソース確保判定装置であって、経路についてリソース確保を要求する個々のリソース確保要求から評価値を取得する評価値取得手段と、経路を構成するリンクを特定するリンク特定手段と、リンクのそれぞれにおいて、リンクの総リソース量を超えない範囲内で、評価値が高いリソース確保要求に対しリソース確保が可能と判定するリンク別リソース確保判定手段と、すべてのリンクでリソース確保が可能と判定された経路に対しリソース確保が可能と判定する経路リソース確保判定手段とを備えることを特徴とする。
【００１５】
このリソース確保判定装置は、リソース確保が可能と判定されたリンクにおいて要求された容量のリソース確保を行うリソース確保手段をさらに備えていてもよい。
また、リンクにおいてリソース確保が行われた後で、新たに受信したリソース確保要求によってリソース確保が不可能と判定されたときに、確保されたリソースを解放するリソース解放手段をさらに備えていてもよい。
【００１６】
また、上述したリソース確保判定装置は、取得された評価値に所定の係数を乗算して評価値を再計算する評価値計算手段をさらに備え、リンク別リソース確保判定手段は、再計算された評価値を用いて判定するようにしてもよい。
ここで、上記係数として、要求された容量の逆数に比例する値を用いることができる。また、上記係数として、リンクにおいて利用可能な残りのリソース量に応じて変化する値を用いることもできる。
【００１７】
また、上述したリソース確保判定装置は、リソース確保が可能と判定されなかったリンクを含む経路に対し、リソース確保が可能と判定されたリンクにおいて要求された容量のリソース確保を行うリソース確保手段と、リソースが確保されたリンクの両端のノードに対し、経路を通過するパケットに設定された優先度の変更を指示する優先度変更指示手段とをさらに備えていてもよい。
【００１８】
また、リソース確保によって支払われる単位時間あたりの金額を評価値として用いることができる。
また、上述したリソース確保判定装置は、新たに受信したリソース確保要求に支払われる料金を、解放されたリソースの確保を要求したユーザに還元する料金還元手段をさらに備えていてもよい。
【００１９】
また、本発明にかかるプログラムは、上述したリソース確保判定方法の各ステップをコンピュータに実行させることを特徴とする。
【発明の効果】
【００２０】
本発明では、経路に対する評価値を指標とし、評価値が高い経路から順にリソース確保が可能と判定する。したがって、経路を構成するリンクの容量が不足する場合であっても、ユーザは経路に対する評価値を高く設定することによって、すでに確保されているリソースの積極的な解放を待たずに、リソース確保が可能となる。その結果、ある時刻にリソース確保サービスを受けたい場合に、その時刻よりも前からリソースを確保し続ける必要がなくなる。
このため、ユーザは、リソース確保サービスを受けたい時刻のみ、料金を支払えばよくなる。また、サービス提供側は、ユーザ一人あたりのサービス提供時間を制限する必要がなくなる。さらに、ユーザの競争原理により、リソースの価値を高め、サービス提供側の利益を増大させることもできる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
１  第１の実施の形態
図１は、本発明のリソース確保判定装置の第１の実施の形態にかかるリソース管理サーバが適用されるリソース管理システムの全体構成を示すブロック図である。
図１におけるリソース管理サーバ１は、通信ネットワーク２のリソースを管理するリソース管理装置である。
【００２２】
管理対象となる通信ネットワーク２は、インターネットプロトコル（ＩＰ）に基づく通信ネットワークであり、複数のルータＲ（Ｒ１〜Ｒ７）や端末Ｔ（Ｔ１〜Ｔ６）などから構成される。これらを総称してノードと呼ぶ。ノード間は、リンクと呼ばれる通信回線によって接続されている。通信ネットワーク２のリソースとは、通信を行う２つの端末間の経路を構成するリンクにおいて、課金によって所定時間払い出される容量のことをいう。連続課金によって容量の払い出しを継続することができる。
【００２３】
アプリケーションサーバ３は、端末Ｔとリソース管理サーバ１との間のメッセージのやり取りを中継するサーバである。端末Ｔからリソース管理サーバ１へは、端末Ｔと他の端末との間で行う通信に必要なリソースの確保を要求するリソース確保要求メッセージ、確保されたリソースの解放を要求するリソース解放要求メッセージなどが送信される。リソース管理サーバ１から端末Ｔへは、リソース確保要求を許諾または拒絶する旨の応答メッセージなどが送信される。
【００２４】
それぞれの要求メッセージには、要求メッセージの種類を示すメッセージ番号、通信を行う２つの端末の識別子（例えばＩＰアドレス）、通信に必要なリソース量などの情報が付加される。特に、リソース確保要求メッセージには、ユーザによって設定された端末間の経路に対する評価値が付加される。本実施の形態では、リソース確保の際に支払う単位時間あたりの金額（支払額）をユーザ自ら自由に設定できるようにし、この支払額を評価値として用いる。
【００２５】
１．１  リソース管理サーバの構成
リソース管理サーバ１は、通信機能を有するコンピュータからなる。以下に説明するリソース管理サーバ１の諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現される。
【００２６】
図２は、リソース管理サーバ１の機能ブロック図である。
図２に示すように、リソース管理サーバ１は、送受信部１１と、メッセージ解析部１２と、リソース管理部１３と、応答処理部１４と、データベース１５とを有する。
【００２７】
送受信部１１は、通信インターフェースを備え、アプリケーションサーバ３との間で、各種メッセージの送受信を行う。例えば、アプリケーションサーバ３から送られてくるリソース確保要求および解放要求などのメッセージを受信し、その応答のメッセージをアプリケーションサーバ３に送信する。
【００２８】
メッセージ解析部１２は、送受信部１１で受信されたメッセージから各種情報を抽出して解析し、その解析結果をリソース管理部１３に出力する。なお、メッセージ解析部１２は、リソース確保要求メッセージから経路に対する評価値を抽出するので、評価値取得部としても機能する。
【００２９】
リソース管理部１３は、要求された容量のリソース確保、確保されたリソースの解放などの処理を行う。具体的には、リンク特定部として、発端末から着端末までの経路を構成するリンクを特定する。また、リンク別リソース確保判定部として、特定したそれぞれリンクにおいて、リンクの総リソース量を超えない範囲内で、評価値が高いリソース確保要求に対しリソース確保が可能と判定する。また、経路リソース確保判定部として、すべてのリンクでリソース確保が可能と判定された経路に対し、リソース確保が可能と判定する。また、リソース確保部として、リソース確保が可能と判定したリンクにおいて、要求された容量のリソース確保を行う。また、リソース解放部として、リソース確保が行われた後で、新たなリソース確保要求によってリソース確保が不可能と判定されたときに、確保されたリソースを解放する。
【００３０】
応答処理部１４は、リソース管理部１３による処理結果に応じた応答メッセージを作成し、送受信部１１に出力する。具体的には、リソース確保に成功したときにはリソース確保要求を許諾する応答メッセージを作成し、失敗したときにはリソース確保要求を拒絶する応答メッセージを作成する。
【００３１】
データベース１５は、通信ネットワーク１のリソース管理に必要な各種情報を記憶する。具体的には、アドレスリスト、リンク情報テーブル、経路情報テーブル、リソース確保判定テーブル、その他の情報を記憶する。以下、これらのテーブルについて説明する。
【００３２】
アドレスリストは、通信ネットワーク２内の端末Ｔ１〜Ｔ６およびルータＲ１〜Ｒ７のＩＰアドレスのリストである。例えば図３に示すように、アドレスリストは、端末Ｔ１〜Ｔ６のＩＰアドレス「端末アドレス」、各端末を収容するエッジノード（例えば、端末Ｔ１を収容するルータＲ１）の識別子「収容エッジノードＩＤ」、そのエッジノードのＩＰアドレス「収容エッジノードアドレス」という項目からなる。
【００３３】
リンク情報テーブルは、通信ネットワーク２内のリンクの情報を示すテーブルである。例えば図４に示すように、リンク情報テーブルは、通信ネットワーク２内の全リンクの識別子「リンクＩＤ」、リンクの総リソース量「総リソース量」、リンクの使用可能な残リソース量「残リソース量」という項目からなる。
【００３４】
経路情報テーブルは、通信ネットワーク２内のあるエッジノードから他のエッジノードに至る経路を示すテーブルである。例えば図５に示すように、経路情報テーブルは、通信ネットワーク２内の全経路の識別子「経路ＩＤ」、経路の起点となるエッジノードの識別子「発側エッジノードＩＤ」、経路の終点となるエッジノードの識別子「着側エッジノードＩＤ」、経路を構成する各リンクの識別子「リンクＩＤのリスト」という項目からなる。
【００３５】
リソース確保判定テーブルは、要求されたリソースの確保が可能か否かの判定に用いられるテーブルである。例えば図６に示すように、確保要求された経路のリソースに対して唯一無二に付与された識別子「リソースＩＤ」、確保要求された経路に対してユーザによって設定された評価値「評価値」、確保要求されたリソース量「要求リソース量」、経路を構成するリンク単位でリソース確保が可能か否かが判定された結果「個別判定」、経路全体でリソース確保が可能か否かが判定された結果「総合判定」という項目からなる。
【００３６】
リソースＩＤに対応する要求リソース量等のデータは、評価値が高い方から順番に並べられている。
そして、リンク単位の判定結果は、最上段からの要求リソース量の合計がそのリンクの総リソース量を超えない範囲で「ＯＫ」となり、総リソース量を超えると「ＮＧ」となる。図６の例では、例えば最上段のリソースＩＤ＃１からリソースＩＤ＃４までの要求リソース量の合計がリンクＬ１の総リソース量を超えず「ＯＫ」となり、さらにリソースＩＤ＃５の要求リソース量まで加算するとリンクＬ１の総リソース量を超えて「ＮＧ」となる。
また、経路全体の判定結果は、その経路を構成する全リンクの判定結果が「ＯＫ」の場合に「ＯＫ」となり、いずれか１つでも「ＮＧ」の場合には「ＮＧ」となる。図６の例では、例えばリソースＩＤ＃４については、リンクＬ１が「ＯＫ」であるものの、リンクＬ３が「ＮＧ」であるため、総合判定は「ＮＧ」となる。
【００３７】
なお、図４〜図６に示したテーブルは、図７に示すようにリソース確保が要求されたネットワークを想定して作成されたものである。帯中の数字は評価値を表す。
【００３８】
１．２  端末の構成
端末Ｔは、通信機能を有する汎用パソコン等のコンピュータからなる。以下に説明する端末Ｔの諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現される。
【００３９】
図８は、端末Ｔの一構成例を示すブロック図である。
図８に示す端末Ｔは、制御部４１と、操作部４２と、送受信部４３と、表示部４４とを有する。
【００４０】
制御部４１は、端末Ｔの各部の動作を制御する。
操作部４２は、ユーザによる端末Ｔの操作に用いられる。例えばキーボードや、マウス等のポインティングデバイスの他、リモートコントローラを用いることができる。操作部４２を用いて、リソース確保要求や、リソース確保に対する支払額などが入力される。
送受信部４３は、通信インターフェースを備え、アプリケーションサーバ３との間で各種メッセージの送受信を行う。例えば、アプリケーションサーバ３にリソース確保要求メッセージを送信し、その応答メッセージをアプリケーションサーバ３から受信する。
表示部４４は、各種要求の入力画面、要求に対する応答、その他の情報を表示する。例えば汎用パソコンのモニタを用いることができる。解像度がよければ、リモートコントローラの表示画面で代用することも可能である。
【００４１】
図９は、操作部４２として用いられるリモートコントローラの外観を示す図である。
このリモートコントローラ５は、表示画面５１と、各種の操作キー５２〜５６と、スピーカ５７とを有する。
表示画面５１には、例えば、リソース管理サーバ１によって提供されるリソース確保サービスの現在のランク、サービス利用に対する支払い総額、直近の単位時間あたりの支払額などが表示される。
【００４２】
操作キー５２は、チャンネルキー、再生キー、早送りキー、巻き戻しキー、音量キー、方向キー等からなる。リソース確保要求時の支払額や、その後の追加支払いの自動化（支払額の増額幅および支払限度額を含む）を設定することができる。また、決済を行うことができる。なお、方向キーや数字キーを利用して、リンクの選択が可能である。
操作キー５３は追加支払いキー、操作キー５４は支払額減少キー、操作キー５５はリソース確保要求を行う確保要求キー、操作キー５６は情報更新キーである。
【００４３】
スピーカ５７は、配信映像の視聴中に状態変更が生じた場合などに、アラーム音を発生させ、その旨を通知する。例えば、視聴中にリソース確保ＮＧとなったときに、それをユーザに通知することができる。バイブレータと連動し、またはバイブレータのみで通知するようにしてもよい。ＬＥＤランプと連動して通知するようにしてもよい。
なお、このリモートコントローラ５を端末Ｔの表示部４４にＧＵＩ表示し、ポインティングデバイスを用いて操作することもできる。
【００４４】
１．３  リソース管理サーバの動作
１．３．１  リソースの確保
まず、図１０を参照し、端末Ｔ４が端末（以下「配信サーバ」という）Ｔ１による映像配信サービスを利用する際に、リソース管理サーバ１が通信ネットワーク２において必要なリソースを確保する動作について説明する。
【００４５】
ユーザが配信サーバＴ１による映像配信サービスを利用するにあたって、リモートコントローラ５の操作キー５２を用いてリソース確保に対する支払額を設定し、確保要求キー５５を押下すると、端末Ｔ４からアプリケーション３にリソース確保要求メッセージが送信される。リソース確保メッセージには、このメッセージがリソース確保要求であることを示すメッセージ番号、映像配信を行う発端末としての配信サーバＴ１のＩＰアドレス、映像配信を受ける着端末としての端末Ｔ４のＩＰアドレス、映像配信に必要なリソース量（要求リソース量）が付加されている。さらに、ユーザによって設定された支払額が、配信サーバＴ１と端末Ｔ４との間の経路に対する評価値として付加される。ここでは評価値を「２５０」とする。
【００４６】
アプリケーションサーバ３は、このリソース確保要求メッセージをリソース管理サーバ１に転送する。
【００４７】
このリソース確保要求メッセージを送受信部１１で受信したリソース管理サーバ１では（図１０のステップＳ１，ＹＥＳ）、まずメッセージ解析部１２が、受信したメッセージに付加されているメッセージ番号から、このメッセージが「リソース確保要求」であると判断する（図１０のステップＳ２，ＹＥＳ）。さらに、メッセージに付加されている配信サーバＴ１および端末Ｔ４のＩＰアドレス、要求リソース量、経路に対する評価値を抽出する（図１０のステップＳ３）。
【００４８】
リソース確保要求メッセージにはリソースＩＤが含まれていないので（図１０のステップＳ４，ＹＥＳ）、リソース管理部１３が、確保要求された経路のリソースに対してリソースＩＤ「＃１０」を付与する（図１０のステップＳ５）。そして、リソースＩＤ「＃１０」とともに、抽出した要求リソース量および評価値を、図１１に示したリソース確保判定テーブルに書き込む。リソースＩＤに対応するデータは評価値が高い方から順番に並べられるので、図１１に示すようにリソースＩＤ「＃１０」は「＃３」の下、「＃９」の上に書き込まれる。
【００４９】
続いて、リソース管理部１３が、図３に示したアドレスリストを参照し、メッセージから抽出した配信サーバＴ１および端末Ｔ４のＩＰアドレスをキーにして、配信サーバＴ１および端末Ｔ４をそれぞれ収容するエッジノードを検索し、発側エッジノードがルータＲ１、着側エッジノードがルータＲ３であることを知る。続いて、図５に示した経路テーブルを参照し、ルータＲ１とルータＲ３との間の経路を検索し、その経路はＩＤが「Ｐ２」であり、リンクＬ１とリンクＬ３とからなることを知る（図１０のステップＳ６）。
【００５０】
続いて、リソース管理部１３が、リンクＬ１についてリソース確保が可能か否かを判定する（図１０のステップＳ７，Ｓ８）。その具体的な方法を図１２を参照して説明する。
まず、図４に示したリンク情報テーブルから、リンクＬ１の総リソース量を読み出し、要求リソース量と比較する。要求リソース量が総リソース量よりも大きい場合には（図１２のステップＳ２１，ＮＯ）、リンクＬ１についてリソース確保が不可能と判定し（図１２のステップＳ２５）、リソース確保判定テーブルにおいて、リソースＩＤ＃１０に対応したリンクＬ１のカラムに「ＮＧ」と書き込む。
【００５１】
要求リソース量が総リソース量以下の場合には（図１２のステップＳ２１，ＹＥＳ）、図４に示したリンク情報テーブルから、リンクＬ１の現在の残リソース量を読み出し、要求リソース量と比較する。要求リソース量が残リソース量以下の場合には（図１２のステップＳ２２，ＹＥＳ）、リンクＬ１についてリソース確保が可能と判定し（図１２のステップＳ２３）、リソース確保判定テーブルにおいて、リソースＩＤ＃１０に対応したリンクＬ１のカラムに「ＯＫ」と書き込む。
【００５２】
要求リソース量が残リソース量よりも大きい場合には（図１２のステップＳ２２，ＮＯ）、次のような処理を行う。上述したように、リソース確保判定テーブルには、リソースＩＤに対応するデータが評価値の高い順に並べられている。このテーブルを参照し、リンクＬ１を含む経路に対するリソース確保要求（＃１，＃２，＃３，＃１０，＃４，＃５，＃６）にかかる要求リソース量を、上から順に加算していく。そして、加算値がリンクＬ１の総リソース量を超えない範囲のリソース確保要求に対しリソース確保が可能と判定し（図１２のステップＳ２４，ＹＥＳ、ステップＳ２３）、加算値がリンクＬ１の総リソース量を超えたリソース確保要求に対してはリソース確保が不可能と判定する（図１２のステップＳ２４，ＮＯ、ステップＳ２５）。
【００５３】
例えば、リソースＩＤ＃１０における要求リソース量が、現在リソース確保可能（ＯＫ）と判定されているリソースＩＤ＃４における要求リソース量以下とする。この場合、リソースＩＤ＃１０における評価値がリソースＩＤ＃４における評価値よりも高いから、リンクＬ１についてのリソース確保判定結果はリソースＩＤ＃４で不可能（ＮＧ）となり、それに代わってリソースＩＤ＃１０で可能（ＯＫ）となる。
リソース確保判定の結果が可能（ＯＫ）から不可能（ＮＧ）に変わった経路について、実際にリソースが確保されている場合には、確保されているリソースが解放される。
【００５４】
なお、要求リソース量の加算値がリンクＬの総リソース量を超えない範囲内で最小の評価値と、加算値が総リソース量を超える最大の評価値とが同一の場合には、両方のリソース確保要求に対して確保不可能としてもよいし、後からのリソース確保要求のみを確保不可能としてもよい。
また、リソース確保判定テーブルに列を追加し、各リンクの総リソース量に達するラインを設定しておき、このラインを超えるときに判定をやり直すようにしてもよい。なお、ラインを超えるものが明示的にＯＫ、超えないものがＮＧとなる。
また、図１２のステップＳ２１におけるリンクＬの総リソース量を読み出し、要求リソース量と比較する処理は省略可能である。
【００５５】
リンクＬ１についてのリソース確保判定の処理が終了したら、リソース管理部１３がリンクＬ３についても同様にリソース確保判定の処理を行う（図１０のステップＳ９，ＮＯ、ステップＳ１０、ステップＳ８）。
図１１に示した例では、例えばリソースＩＤ＃１０における要求リソース量が、現在リソース確保可能（ＯＫ）と判定されているリソースＩＤ＃９における要求リソース量以下とすると、リソースＩＤ＃１０における評価値がリソースＩＤ＃９における評価値よりも高いから、リンクＬ３についてのリソース確保判定結果はリソースＩＤ＃９で不可能（ＮＧ）となり、それに代わってリソースＩＤ＃１０で可能（ＯＫ）となる。
【００５６】
リンク毎のリソース確保判定の結果、リンクＬ１およびＬ３の両方についてリソース確保が可能と判定された場合、すなわち図１１におけるリソースＩＤ＃１０のようにリンクＬ１およびＬ３の両方のカラムに「ＯＫ」と書き込まれた場合には（図１０のステップＳ１１，ＹＥＳ）、リソース管理部１３は、配信サーバＴ１と端末Ｔ４との間の経路に対し、リソース確保が可能と判定し（図１０のステップＳ１２）、リソース確保判定テーブルにおけるリソースＩＤ＃１０に対応した総合判定のカラムに「ＯＫ」と書き込む。そして、リンク情報テーブルにおけるリンクＬ１およびＬ３の現在の残リソース量から要求リソース量を減算することによって、リンクＬ１とリンクＬ３とからなる経路についてリソースを確保する（図１０のステップＳ１３）。
【００５７】
さらに、応答処理部１４がリソース確保を許諾する旨の応答メッセージを作成し、送受信部１１からアプリケーションサーバ３を介して端末Ｔ４に送信する（図１０のステップＳ１４）。この応答メッセージには、リソース確保要求を行った端末Ｔ４のＩＰアドレス、発端末である配信サーバＴ１のＩＰアドレス、リソースＩＤが付加される。
【００５８】
リソース確保を許諾する旨の応答メッセージを受信したアプリケーションサーバ３は、配信サーバＴ１を収容する発側エッジルータＲ１に対し、配信サーバＴ１から端末Ｔ４への経路を通過するパケットに設定された優先度を高くさせる、すなわち優先度を「Ｈｉｇｈ（優先）」にさせる指示を行う。ルータＲ１によって優先度が高く設定されたパケットは、経路上のノードを通過するときに、高い優先度で扱われる。したがって、端末Ｔ４のユーザは、経路上のトラフィックが混んでいるときでも、高品質な映像配信を受けることができる。
【００５９】
これに対し、リンクＬ１およびＬ３の少なくとも一方についてリソース確保が不可能と判定された場合、リンクＬ１およびＬ３の少なくとも一方のカラムに「ＮＧ」と書き込まれた場合には（図１０のステップＳ１１，ＮＯ）、リソース管理部１３は、配信サーバＴ１と端末Ｔ４との間の経路に対し、リソース確保が不可能と判定し（図１０のステップＳ１５）、リソース確保判定テーブルにおける当該リソースＩＤに対応した総合判定のカラムに「ＮＧ」と書き込む。
この場合には、応答処理部１４がリソース確保を拒絶する旨の応答メッセージを作成し、送受信部１１からアプリケーションサーバ３を介して端末Ｔ４に送信する（図１０のステップＳ１６）。この応答メッセージには、リソース確保要求を行った端末Ｔ４のＩＰアドレス、リソースＩＤが付加される。
【００６０】
リソース確保を拒絶する旨の応答メッセージを受信したアプリケーションサーバ３は、発側エッジルータＲ１に対し上述した指示を行わない。したがって、配信サーバＴ１から端末Ｔ４への経路を通過するパケットにおける優先度の設定は「Ｌｏｗ（非優先）」のままとなる。このため、このパケットは経路上のノードを通過するときに、低い優先度（例えば、ベストエフォート（Best Effort））で扱われる。したがって、端末Ｔ４のユーザは、経路上のトラフィックがすいているときには映像配信を受けることができるが、トラフィックが混むとパケットの損失等により映像品質が劣化する可能性がある。
【００６１】
なお、経路全体でリソース確保が可能でない場合でも、リソース確保が可能な区間がある場合には、その区間についてリソース確保を認めることもできる。この場合には、図１０のステップＳ１５で経路に対しリソース確保が不可能と判定した後に、ステップＳ８でリソース確保が可能と判定したリンクのみについてリソース確保を行い、一部区間についてリソース確保を許諾する旨の応答メッセージをアプリケーションサーバ３を介して端末Ｔ４に送信する。この応答メッセージには、リソース確保要求を行った端末Ｔ４のＩＰアドレス、リソースＩＤ、リソース確保したリンクの識別子が付加される。
【００６２】
この応答メッセージを受信したアプリケーションサーバ３は、リソースが確保されたリンクの両端のルータに対し、配信サーバＴ１から端末Ｔ４への経路を通過するパケットに設定された優先度を変更させる指示を行う。例えば、図６におけるリソースＩＤ＃４では、リンクＬ１についてはリソースが確保され、リンクＬ３についてはリソーが確保されなかったので、ルータＲ１に対しパケットの優先度を「Ｈｉｇｈ（優先）」にさせ、ルータＲ６に対しパケットの優先度を「Ｌｏｗ（非優先）」にさせる。これにより、リンクＬ１の区間についてのみ、パケットが高い優先度で扱われる。
なお、このようなアプリケーションサーバ３の優先度変更指示機能は、リソース管理サーバ１に持たせてもよい。
【００６３】
１．３．２  支払額増額
リソース確保を拒絶または一部拒絶された端末Ｔ４のユーザは、リソース確保に対する支払額を増額し、再びリソース確保を要求することができる。
具体的には、ユーザが、リモートコントローラ５の追加支払いキー５３を用いて、支払額を増額設定する。そして、確保要求キー５５を押下すると、増額された支払額が評価値として付加されたリソース確保要求メッセージが、端末Ｔ４からアプリケーション３を介してリソース管理サーバ１に送信される。このメッセージには、上述したメッセージ番号等の他に、応答メッセージから抽出したリソースＩＤも付加される。
【００６４】
このリソース確保要求メッセージを受信したリソース管理サーバ１では（図１０のステップＳ１，ＹＥＳ）、前回に端末Ｔ４からリソース確保要求メッセージを受信したときと同様に、メッセージ解析部１２がリソース確保要求であると判断し（図１０のステップＳ２，ＹＥＳ）、リソース確保要求メッセージに付加されている各種情報を抽出する（図１０のステップＳ３）。抽出した情報には、前回の端末Ｔ４からの確保要求によって付与されたリソースＩＤも含まれている（図１０のステップＳ４，ＮＯ）。
リソース管理部１３は、リソースＩＤを図１１に示したリソース確保判定テーブルから検索し、リソースＩＤに対応する評価値を、支払額増額に基づく新しい評価値に書き換える。その後、前回と同じ経路についてリソース確保判定、および、判定結果に基づく応答の処理を行う（図１０のステップＳ７〜Ｓ１６）。
【００６５】
例えば、図１３（ａ）に示すリソースＩＤ＃４のように、当初は支払額すなわち評価値を「２００」としてリソース確保に失敗した場合であっても、図１３（ｂ）に示すリソースＩＤ＃４のように、次に支払額を増額し評価値を「３５０」とすることによって、当初リソース確保されていたリソースＩＤ＃３の評価値「３００」と順位が逆転し、リソースＩＤ＃４についてリソース確保が可能となる。
【００６６】
１．３．３  リソースの解放
次に、図１０および図１４を参照し、配信サーバＴ１から端末Ｔ４への映像配信が終了した後に、リソース管理サーバ１が映像配信のために確保されていたリソースを解放する動作について説明する。
【００６７】
配信サーバＴ１による映像配信が終了し、端末Ｔ４がリソース解放要求メッセージをアプリケーションサーバ３に送信すると、アプリケーションサーバ３は受信したリソース解放要求メッセージをリソース管理サーバ１に転送する。リソース解放要求メッセージには、少なくとも、このメッセージがリソース解放要求であることを示すメッセージ番号、応答メッセージから抽出したリソースＩＤが付加されている。
【００６８】
このリソース解放要求メッセージを送受信部１１で受信したリソース管理サーバ１では（図１０のステップＳ１，ＹＥＳ）、まずメッセージ解析部１２が、受信したメッセージに付加されているメッセージ番号から、このメッセージが「リソース解放要求」であると判断する（図１０のステップＳ２，ＮＯ、図１４のステップＳ３１，ＹＥＳ）。さらに、メッセージに付加されているリソースＩＤを抽出する。
【００６９】
ついで、リソース管理部１３が、リソースＩＤを図１１に示したリソース確保判定テーブルから検索し、リソース確保した経路がリンクＬ１とリンクＬ３とからなることと、映像配信のために確保されていたリソース量（要求リソース量）とを知る。
続いて、図４に示したリンク情報テーブルから、リンクＬ１の現在の残リソース量の値を読み出す。この値から映像配信のために確保されたリソース量の値を加算し、得られた値をリンクＬ１の新たな残リソース量として、リンク情報テーブルに書き込む。リンクＬ３についても同様の処理を行う。これにより、映像配信のために確保されたリソースが解放される（図１４のステップＳ３２）。
【００７０】
なお、本実施の形態では、経路に対する評価値をリソース確保要求メッセージに付加する例を説明したが、通常のリソース確保要求メッセージとは別に評価値通知メッセージを用い、このメッセージに評価値を付加して端末Ｔ４からリソース管理サーバ１に送信することもできる。
【００７１】
１．４  リソースマップ
本実施の形態では、応答メッセージによってリソース確保の許諾または拒絶を端末Ｔ４に通知するとしたが、図７に示したようなリソースマップを端末Ｔ４に表示し、より詳しい情報をユーザに提供することもできる。ここに、「リソースマップ」とは、ルータＲおよびリンクＬ等を簡易図形で表したオブジェクトを、実際の接続関係を表すように配置したものである。オブジェクトの代わりに、またはオブジェクトとともに、ルータＲおよびリンクＬの識別子を用いることもできる。
【００７２】
図７に示したリソースマップには、配信サーバＴ１と端末Ｔ４との間の必要な経路の他に分岐も表示されているが、分岐が表示されないパターンもある。また、自分や他のユーザが設定した評価値が表示されているが、リソース確保の成否のみを表示するパターン、自分の優先順位のみを表示するパターン、リソース確保が可能となるデッドラインまたはその近傍にあるときにその旨を表示するパターン、支払額の相場または平均のみを表示するパターンなどもある。
【００７３】
さらに、リソースマップを用いて、支払額を増額したリソース確保要求を行なうことができる。例えば、発端末（対地Ｐ）と着端末（対地Ｑ）を選択することにより、発端末から着端末までの経路全体に対して支払額を増額したリソース確保要求を行うことができる。また、経路上のリンクのオブジェクトを選択することにより、リンク毎に支払額を増額したリソース確保要求を行うことができる。
【００７４】
１．５  課金処理
ユーザによって設定される支払額は、リソース確保によって支払われる単位時間あたりの金額である。「単位時間」とは、「月」、「時間」、「秒」など様々である。この支払額にリソース確保サービスの利用時間を乗算した額が課金される。
【００７５】
図１５は、課金処理について説明するための図である。帯グラフ中の梨子地模様はリソース確保に成功し優先扱いとなった時間、斜線はリソース確保に失敗し非優先扱いとなった時間を示している。また、帯グラフ中の数字は、リソース確保に対する単位時間あたりの支払額とする。
【００７６】
ユーザ＃１は、４単位時間（０〜ｔ4）、リソースを「５００」で確保した。したがって、ユーザ＃１は、５００×４＝２０００支払うことになる。
ユーザ＃２は、５．５単位時間、リソースを「４００」で確保した。時間の端数を切り上げとすると、ユーザ＃２は、４００×６＝２４００支払うことになる。
ユーザ＃３は、最初の２単位時間（０〜ｔ2）、支払額を「２００」としたが、リソース確保に失敗した。しかし、その後、支払額を増額して「３５０」とし、４単位時間（ｔ2〜ｔ6）、リソースを確保した。したがって、ユーザ＃３は、２００×２＋３５０×４＝１８００支払うことになる。
【００７７】
ユーザ＃４は、６単位時間（０〜ｔ6）、支払額を「３００」とした。最初の２単位時間（０〜ｔ2）はリソース確保の権利を得るが、次の２単位時間（ｔ2〜ｔ4）はユーザ＃３による支払額増額によってその権利を奪われる。さらに次の２単位時間（ｔ4〜ｔ6）はユーザ＃１の権利放棄によって再び権利を得る。他人の支払額増額によってリソース確保の権利が奪われた場合には、当人の支払額に係数α（０≦α≦１）を掛け、課金を軽減することができる。ここでは仮にα＝１として計算すると、ユーザ＃４は、３００×２＋３００×２×α＋３００×２＝１８００支払うことになる。
【００７８】
リソース確保に対する支払額については、増額だけでなく、減額することもできる。この場合には、例えば図９に示したリモートコントローラ５の支払額減少キー５４を用いる。
図１６は、支払額を減額した場合の課金処理について説明するための図である。
ユーザ＃４は、最初の２単位時間（０〜ｔ2）は、支払額を「３００」としてリソース確保の権利を得るが、その後ユーザ＃３による支払額増額によってその権利を奪われる。そこで、時刻ｔ3から支払額を「２００」に減額した。ただし、最後の２単位時間（ｔ4〜ｔ6）はユーザ＃１の権利放棄によって再び権利を得る。上述したケースと同様に係数α＝１として計算すると、ユーザ＃４は、３００×２＋３００×１×α＋２００×１×α＋２００×２＝１５００支払うことになる。
このように支払額の減額を設定することによって、リソース確保を受けられなかったときのユーザ＃４の課金を自ら軽減することができる。
【００７９】
また、端末Ｔに追加支払いの自動化を設定することができる。この場合には、ユーザが操作キー５２を用いて、支払額の増額幅および支払限度額を端末Ｔに予め設定しておく必要がある。このような設定をしておくことによって、リソース確保の権利を他人に奪われたとしても、再びリソース確保の権利が得られるように端末Ｔが自動的に追加支払いを行うことができる。このような端末Ｔの機能を「自動競争機能」と呼ぶ。
【００８０】
図１７は、自動競争機能を利用した場合の課金処理について説明するための図である。
ユーザ＃３は支払増額幅を「２０」、支払限度額を「３５０」に設定し、ユーザ＃４は支払増額幅を「２０」、支払限度額を「３４０」に設定したとする。ユーザ＃３が時刻ｔ2に自動競争機能をＯＮにすると、支払額の増額競争が始まり、支払額がいずれかの支払限度額を超えるまで競争が繰り返される。上述したケースと同様に係数α＝１として計算すると、ユーザ＃３は、２００×２×α＋３１０×１＋３１０×１×α＋３３０×１＋３３０×１×α＋３５０×１＝４００＋１５００＋１３０＝２０３０支払うことになる。一方、ユーザ＃４は、３００×２＋３００×１×α＋３２０×１＋３２０×１×α＋３４０×１＋３４０×１×α＝２２２０支払うことになる。
【００８１】
自動競争を行っている間のユーザ＃３の端末とリソース管理サーバ１との間のメッセージの送受信、ユーザ＃４の端末とリソース管理サーバ１との間のメッセージの送受信を図１８に示す。リソース管理サーバ１は、支払額の増額によって評価値の順位が逆転すると、それまで上位の評価値に対して確保されていたリソースを解放し、その評価値を設定した端末に解放通知メッセージを送信する。この解放通知メッセージを受信した端末は、自動競争機能によって支払額を自動的に増額し、増額した支払額を評価値として付加した評価値通知メッセージをリソース確保要求メッセージ１に送信する。なお、この図において、「Ｍ」はメッセージを表す。
【００８２】
１．６  支払額の還元
ユーザ＃４のように、他人（ユーザ＃３）の支払額増額によってリソース確保の権利が奪われたユーザなどに、対価を支払うようにすることができる。例えば次のような対価支払い方法がある。
（１）一定額を支払う。
（２）支払額を増額した他人の支払額Ａに係数β（０≦β≦１）を掛けた額を、リソース確保の権利が奪われたユーザ（人数ｘ）に均等に還元する。ユーザ一人あたりの還元額は、Ａ×β÷ｘによって求められる。
（３）支払額を増額した他人の支払額Ａに係数γ（０≦γ≦１）を掛けた額を、評価値ランクが落ちたユーザ（人数ｙ）に均等に還元する。ユーザ一人あたりの還元額は、Ａ×γ÷ｙによって求められる。
（４）支払額を増額した他人の支払額Ａに係数δ（０≦δ≦１）を掛けた額を、上記他人に評価値ランクを追い抜かれたがユーザ（人数ｚ）に均等に還元する。ユーザ一人あたりの還元額は、Ａ×δ÷ｚによって求められる。
なお、自ら支払額を減額したユーザには、還元されないようにすることもできる。
【００８３】
２  第２の実施の形態
次に、本発明のリソース確保判定装置の第２の実施の形態について説明する。本実施の形態は、リソース確保を要求された経路に対する評価値を再計算する機能を有する。
より詳しくは、リソース管理サーバのメッセージ解析部が、受信したリソース確保要求メッセージから各種情報を抽出したときに、抽出した評価値に所定の係数を掛けることによって、評価値の再計算を行う評価値計算部として機能する（図１９のステップＳ６１）。
本実施の形態では、再計算された評価値がリソースＩＤ等とともにリソース確保判定テーブルに書き込まれ、リソース確保が可能か否かの判定に用いられる。
評価値の再計算に用いられる係数の例を以下に説明する。
【００８４】
（１）帯域の占有率の逆数に比例する係数
「帯域の占有率」とは、（要求リソース量）／（総リソース量）によって定義される。したがって、「帯域の占有率の逆数」とは、（総リソース量）／（要求リソース量）となる。ここに、「総リソース量」とは、リソース確保型サービスに割り当てられた全リソース量のことである（以下同様）。
評価値に帯域の占有率の逆数を掛けることによって、単位リソースあたりの支払額が大きいユーザのリソース確保要求が優先されることになる。
【００８５】
例えば、総リソース量４０ＭＢｙｔｅに対して、ユーザ＃１が支払額（評価値）「３００」で１０ＭＢｙｔｅを要求した場合、再計算された評価値は３００×（４０／１０）＝１２００となる。一方、ユーザ＃２が支払額（評価値）「４００」で３０ＭＢｙｔｅを要求した場合、再計算された評価値は４００×（４０／３０）＝５３３となる。支払額はユーザ＃２の方が大きいが、ユーザ＃１の方が再計算した評価値が大きいので、ユーザ＃１のリソース確保要求が優先される。したがって、残リソース量が少ない場合には、ユーザ＃１に対してはリソース確保が許諾され、ユーザ＃２に対してはリソース確保が拒絶されることがある。
【００８６】
（２）リソース確保型サービスの利用に応じて決まる係数
サービスの継続利用時間が長いほど、または、サービスの利用回数が多いほど、係数の値を大きくし、リソース確保要求が優先され易くする。
例えば、サービスを２時間継続して利用すると、評価値が１．２倍となるとする。総リソース量４０ＭＢｙｔｅに対して、ユーザ＃１が支払額（評価値）「１５０」で１０ＭＢｙｔｅを２時間継続して要求した場合、再計算された評価値は１５０×（４０／１０）×１．２＝７２０となる。一方、ユーザ＃２が支払額（評価値）「５００」で３０ＭＢｙｔｅを要求した場合、再計算された評価値は５００×（４０／３０）＝６６６となる。支払額はユーザ＃２の方が大きいが、ユーザ＃１の方が再計算した評価値が大きいので、ユーザ＃１のリソース確保要求が優先される。
【００８７】
（３）残リソース量に応じて決まる係数
利用可能な残リソース量が少ないほど価値が高い（または低い）と認定し、リソース確保に通常より高い（または低い）支払額を要求するため、係数の値を小さく（大きく）する。
例えば、総リソース量４０ＭＢｙｔｅに対して、ユーザ＃１が支払額（評価値）「１５０」で１０ＭＢｙｔｅを要求した場合、再計算された評価値は１５０×（４０／１０）＝６００となる。その後、ユーザ＃２が支払額（評価値）「５００」で３０ＭＢｙｔｅを要求した場合、残リソース量が少なく支払額が０．８倍に評価されるとすると、再計算された評価値は５００×（４０／３０）×０．８＝５３３となる。支払額はユーザ＃２の方が大きいが、ユーザ＃１の方が再計算した評価値が大きいので、ユーザ＃１のリソース確保要求が優先される。
【００８８】
３  第３の実施の形態
次に、本発明のリソース確保判定装置の第３の実施の形態について説明する。本実施の形態が適用されるリソース管理システムは、複数のリソース管理サーバを用いて通信ネットワークを分割管理するものである。
図２０は、本実施の形態が適用されるリソース管理システムの全体構成を示すブロック図である。
このリソース管理システムは、複数のリソース管理サーバＡ１，Ｂ１，Ｃ１を有する。リソース管理サーバＡ１，Ｂ１，Ｃ１は、互いに接続された通信ネットワークＡ２，Ｂ２，Ｃ２のリソースをそれぞれ管理する。
【００８９】
リソース管理サーバＡ１，Ｂ１，Ｃ１は、第１の実施の形態におけるリソース管理サーバ１と同様の機能を有する。さらに、複数の通信ネットワークに跨る経路のリソースを管理する必要があるため、隣り合うリソース管理サーバの間で各種メッセージをやり取りする機能も有する。例えば、通信ネットワークＡ２とＢ２とに跨る経路のリソースを確保する場合には、通信ネットワークＡ２を管理するリソース管理サーバＡ１は、自己の管理範囲内におけるリソース確保処理終了後に、通信ネットワークＢ２を管理するリソース管理サーバＢ１に、リソース確保要求メッセージを送信する。
【００９０】
第２の実施の形態で説明した評価値の再計算機能をそれぞれのリソース管理サーバＡ１〜Ｃ１が有する場合に、リソース確保要求メッセージの送信元サーバは、ユーザが設定した支払額を評価値としてメッセージに付加してもよいし、このサーバが独自に再計算した評価値をメッセージに付加してもよい。
【００９１】
なお、上述した実施の形態における評価値を用いたリソース確保の判定方法は、通信を行う際にリアルタイムでリソース確保を要求する場合だけでなく、予め時間を指定してリソース確保を予約する場合にも使用することができる。
【産業上の利用可能性】
【００９２】
本発明は、例えば高品質の通信サービスを提供する分野に利用可能である。
【図面の簡単な説明】
【００９３】
【図１】本発明の第１の実施の形態にかかるリソース管理サーバが適用されるリソース管理システムの全体構成を示すブロック図である。
【図２】リソース管理サーバの機能ブロック図である。
【図３】アドレスリストのデータ構造の一例を示す図である。
【図４】リンク情報テーブルのデータ構造の一例を示す図である。
【図５】経路情報テーブルのデータ構造の一例を示す図である。
【図６】リソース確保判定テーブルのデータ構造の一例を示す図である。
【図７】通信ネットワークにおけるリソース確保状況を表すリソースマップの一例を示す図である。
【図８】端末の一構成例を示すブロック図である。
【図９】操作部として用いられるリモートコントローラの外観を示す図である。
【図１０】通信に必要なリソースを確保する処理の流れを示すフローチャートである。
【図１１】リソース確保判定処理を説明するためのリソース確保判定テーブルを示す図である。
【図１２】リンク毎のソース確保判定処理の流れを示すフローチャートである。
【図１３】支払額を増額したことによるリソース確保状況の変化を概念的に示す図である。
【図１４】確保されたリソースを解放する処理の流れを示すフローチャートである。
【図１５】課金処理について説明するための図である。
【図１６】支払額を減額した場合の課金処理について説明するための図である。
【図１７】自動競争機能を利用した場合の課金処理について説明するための図である。
【図１８】自動競争を行っている間の端末とリソース管理サーバとの間のメッセージの送受信を時系列的に示すシーケンス図である。
【図１９】本発明の第２の実施の形態において、通信に必要なリソースを確保する処理の流れを示すフローチャートである。
【図２０】本発明の第３の実施の形態にかかるリソース管理サーバが適用されるリソース管理システムの全体構成を示すブロック図である。
【符号の説明】
【００９４】
１，Ａ１〜Ｃ１…リソース管理サーバ、２，Ａ２〜Ｃ２…通信ネットワーク、３…アプリケーションサーバ、１１…送受信部、１２…メッセージ解析部、１３…リソース管理部、１４…応答処理部、１５…データベース、４１…制御部、４２…操作部、４３…送受信部、４４…表示部、５…リモートコントローラ、５１…表示画面、５２…操作キー、５７…スピーカ、Ｌ…リンク、Ｒ…ルータ、Ｔ…端末（Ｔ１…配信サーバ）。
【図１】
2006295461.tif 000003
【図２】
2006295461.tif 000004
【図３】
2006295461.tif 000005
【図４】
2006295461.tif 000006
【図５】
2006295461.tif 000007
【図６】
2006295461.tif 000008
【図７】
2006295461.tif 000009
【図８】
2006295461.tif 000010
【図９】
2006295461.tif 000011
【図１０】
2006295461.tif 000012
【図１１】
2006295461.tif 000013
【図１２】
2006295461.tif 000014
【図１３】
2006295461.tif 000015
【図１４】
2006295461.tif 000016
【図１５】
2006295461.tif 000017
【図１６】
2006295461.tif 000018
【図１７】
2006295461.tif 000019
【図１８】
2006295461.tif 000020
【図１９】
2006295461.tif 000021
【図２０】
2006295461.tif 000022