(57)【要約】【課題】通信毎に必要な帯域を申請し、該帯域幅に基づいて通信を行うとともに、該帯域幅に応じた課金レートを制御する仕組みを提案する。【解決手段】管理サーバを介して接続する第１端末と第２端末との間の通信帯域を制御する帯域制御システムにおいて、第１端末は、通信帯域を制御する管理サーバを介して、相手端末と通話およびデータ通信を行う通信部と、電話番号と帯域情報を対応づけた電話番号帯域データを記憶している記憶部と、電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する帯域情報抽出部と、抽出された帯域情報を含む発信要求を、管理サーバに通知する発信要求通知部と、抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知する帯域情報通知部を備えることを特徴とする。【選択図】図３
2009033269.tif 000002
【特許請求の範囲】
【請求項１】
管理サーバを介して接続する第１端末と第２端末との間の通信帯域を制御する帯域制御システムにおいて、
前記第１端末は、通信帯域を制御する管理サーバを介して、相手端末と通話およびデータ通信を行う通信部と、
電話番号と帯域情報を対応づけた電話番号帯域データを記憶している記憶部と、
前記電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する帯域情報抽出部と、
前記抽出された帯域情報を含む発信要求を、前記管理サーバに通知する発信要求通知部と、
前記抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知する帯域情報通知部と
を備えることを特徴とする帯域制御システム。
【請求項２】
前記帯域情報を受信した前記課金サーバが、前記受信した帯域情報、該帯域情報に対する課金レートおよび通信時間に基づいて、前記抽出された帯域情報に基づく前記第１端末と第２端末との通信に係る請求料金を算出する、
ことを特徴とする請求項１に記載の帯域制御システム。
【請求項３】
通信帯域を制御する管理サーバを介して、相手端末と通話およびデータ通信を行う通信部と、
電話番号と帯域情報を対応づけた電話番号帯域データを記憶している記憶部と、
前記電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する帯域情報抽出部と、
前記抽出された帯域情報を含む発信要求を、前記管理サーバに通知する発信要求通知部と、
前記抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知する帯域情報通知部と
を備えることを特徴とする端末装置。
【請求項４】
ダイヤルされたことを検出するステップと、
電話番号と帯域情報を対応づけた電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出するステップと、
前記抽出された帯域情報を含む発信要求を、通信帯域を制御する管理サーバに通知するステップと、
前記抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知するステップと
を備えることを特徴とする帯域制御方法。
【請求項５】
ダイヤルされたことを検出する手順と、
電話番号と帯域情報を対応づけた電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する手順と、
前記抽出された帯域情報を含む発信要求を、通信帯域を制御する管理サーバに通知する手順と、
前記抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知する手順と
を含む帯域制御方法をコンピュータに実行させるためのプログラム。
【請求項６】
管理サーバを介して接続する第１端末と第２端末との間の通信帯域を制御する帯域制御システムにおいて、
前記管理サーバは、発信要求を行うのに必要最低の帯域情報を含む発信要求通知を第１端末から受信し、
電話番号と帯域情報を対応づけた電話番号帯域データから、前記受信した発信要求通知に含まれる電話番号のサービスに必要な帯域量を抽出し、
前記第１端末からの前記発信要求通知に含まれた前記必要最低の帯域情報を更新して、前記発信要求通知を前記第２端末に送信し、
前記通信帯域に応じて課金を行う課金サーバに前記更新後の帯域情報を通知する制御部を備える
ことを特徴とする帯域制御システム。
【請求項７】
前記帯域情報を受信した前記課金サーバが、前記受信した帯域情報、該帯域情報に対する課金レートおよび通信時間に基づいて、前記抽出された帯域情報に基づく前記第１端末と第２端末との通信に係る請求料金を算出する、
ことを特徴とする請求項６に記載の帯域制御システム。
【請求項８】
第１端末と第２端末との間の通信帯域を制御する管理サーバにおいて、
発信要求を行うのに必要最低の帯域情報を含む発信要求通知を第１端末から受信し、
電話番号と帯域情報を対応づけた電話番号帯域データから、前記受信した発信要求通知に含まれる電話番号のサービスに必要な帯域量を抽出し、
前記第１端末からの前記発信要求通知に含まれた前記必要最低の帯域情報を更新して、前記発信要求通知を前記第２端末に送信し、
前記通信帯域に応じて課金を行う課金サーバに前記更新後の帯域情報を通知する制御部を備える
ことを特徴とする管理サーバ。
【請求項９】
第１端末と第２端末との間の通信帯域を制御する管理サーバにおける帯域制御方法において、
発信要求を行うのに必要最低の帯域情報を含む発信要求通知を第１端末から受信するステップと、
電話番号と帯域情報を対応づけた電話番号帯域データから、前記受信した発信要求通知に含まれる電話番号のサービスに必要な帯域量を抽出するステップと、
前記第１端末からの前記発信要求通知に含まれた前記必要最低の帯域情報を更新して、前記発信要求通知を前記第２端末に送信するステップと、
前記通信帯域に応じて課金を行う課金サーバに前記更新後の帯域情報を通知するステップと
を備えることを特徴とする帯域制御方法。
【請求項１０】
管理サーバを介して通信を行う第１端末と第２端末との間の通信帯域を制御するためのプログラムであって、
発信要求を行うのに必要最低の帯域情報を含む発信要求通知を第１端末から受信する手順と、
電話番号と帯域情報を対応づけた電話番号帯域データから、前記受信した発信要求通知に含まれる電話番号のサービスに必要な帯域量を抽出する手順と、
前記第１端末からの前記発信要求通知に含まれた前記必要最低の帯域情報を更新して、前記発信要求通知を前記第２端末に送信する手順と、
前記通信帯域に応じて課金を行う課金サーバに前記更新後の帯域情報を通知する手順と
を含む帯域制御方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、帯域制御システム、端末装置、管理サーバ、帯域制御方法とそのプログラムに関し、例えば、電話サービスのようなリアルタイムコミュニケーションを利用した伝送帯域を制御する技術に係わる。
【背景技術】
【０００２】
従来の電話サービスやインターネットでは、月額の基本料金の他に通信時間やパケット量による従量課金方式が広く使用されている。これに対し、提供されるサービスに対する課金条件を動的に生成して課金を行う課金システムが提案されている。
【０００３】
例えば、特許文献１には、提供されるサービスに対する課金条件を動的に生成し、該課金条件に従って課金できるようにし、かつ、有料サービスに対するネットワーク内の代行課金を可能にする課金システムが開示されている。
【０００４】
【特許文献１】特開２００３−３３８８２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、従来の電話サービスやインターネットでは帯域予約を行うことができず、予約帯域幅に応じて課金を行うことはできなかった。ＮＧＮ（Next Generation Network）網においてはアプリケーションやサービストラフィックとＩＰ（Internet Protocol）電話が共存する必要があり、帯域を保障することでユーザはストレスなくネットワークサービスを利用できる。しかし、結果的にユーザがサービスを保障するために常に大きな帯域を申請してしまうと、帯域が効率的に使用できないといった問題が発生する。そのため、通信毎に必要な帯域を申請し、該帯域幅に応じて課金レートを制御する仕組みが望まれていた。
【０００６】
本発明は斯かる点に鑑みてなされたものであり、通信毎に必要な帯域を申請し、該帯域幅に基づいて通信を行うとともに、該帯域幅に応じた課金レートを制御する仕組みを提案することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明の第１の側面は、管理サーバを介して接続する第１端末と第２端末との間の通信帯域を制御する帯域制御システムにおいて、第１端末は、通信帯域を制御する管理サーバを介して、相手端末と通話およびデータ通信を行う通信部と、電話番号と帯域情報を対応づけた電話番号帯域データを記憶している記憶部と、電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する帯域情報抽出部と、抽出された帯域情報を含む発信要求を、管理サーバに通知する発信要求通知部と、抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバに通知する帯域情報通知部を備えることを特徴とする。
【０００８】
また、本発明の第２の側面は、管理サーバを介して接続する第１端末と第２端末との間の通信帯域を制御する帯域制御システムにおいて、管理サーバは、発信要求を行うのに必要最低の帯域情報を含む発信要求通知を第１端末から受信し、電話番号と帯域情報を対応づけた電話番号帯域データから、受信した発信要求通知に含まれる電話番号のサービスに必要な帯域量を抽出し、第１端末からの発信要求通知に含まれた必要最低の帯域情報を更新して、発信要求通知を第２端末に送信し、通信帯域に応じて課金を行う課金サーバに前記更新後の帯域情報を通知する制御部を備えることを特徴とする。
【０００９】
上記第１および第２の側面による構成によれば、ユーザ端末が呼制御サーバに帯域予約を行う際、同時に課金サーバにも同様の情報を渡すことにより申請された帯域量に応じて課金レートを制御できる。さらに使用する帯域は、ユーザ端末または管理サーバにてダイヤル番号(電話番号)からサービスを確定し、必要な帯域を自動算出することで効率的に帯域を制御することができる。
【発明の効果】
【００１０】
本発明によれば、通信毎に必要な帯域を申請し、該帯域幅に基づいて通信を行うとともに、該帯域幅に応じた課金レートを制御することができる。
【発明を実施するための最良の形態】
【００１１】
以下、図１〜図７を参照しながら、本発明の第１の実施の形態の例を説明する。本実施の形態は、本発明の帯域制御システムを、ＮＧＮ（Next Generation Network）に適用した例としてある。
【００１２】
図１は、本実施の形態によるネットワークの構成図である。図１に示すユーザ端末１およびユーザ端末２は、ＮＧＮ３の呼制御サーバ４（接続管理サーバ）と課金サーバ５に接続することができる。その呼制御サーバ４は、ユーザ端末間で送受信されるコンテンツの課金情報を管理する課金サーバ５と接続している。なお、本例ではユーザ端末１，２の例として、ビデオ会議システムに使用されるビデオ会議装置に適用した例としてある。ユーザ端末１，２はそれぞれリモートコントロール信号を出力するリモコン装置１ａ,１ｂにより、遠隔操作が可能となっている。これらのユーザ端末１，２、呼制御サーバ４および課金サーバ５によるセッションの確立には、ＳＩＰプロトコルが使用される。
【００１３】
図１に示すＮＧＮ３は、ＳＩＰプロトコルを利用したＮＧＮ網である。ＮＧＮは、現在別々に構築されているインターネットサービス用ＩＰネットワークと電話サービス用の電話網を、ＩＰ技術を用いてＱｏＳ（Quality of Service）やセキュリティを向上させたＩＰ通信網として統合し、現行の公衆網を代替する次世代ＩＰネットワークである。電話だけでなくテレビ放送もＩＰネットワークで統一的に提供しようとする動きも進められている。現在、ＩＴＵ−Ｔ（国際電気通信連合 電気通信標準化部門）などを中心にＮＧＮの標準化が進んでおり、日本でも通信事業者各社のＮＧＮ構築へ照準を合わせた動きが活発化している。既に一部の通信事業者はフィールド・トライアルを実施している。
【００１４】
ＩＴＵ−ＴのＹ．２００１勧告では、ＮＧＮが備えるべき様々な特徴を規定している。重要なものとしてはまず、エンド・ツー・エンドＱｏＳ保証の提供が挙げられる。ＮＧＮでは多様なアクセス網(ｘＤＳＬやＷｉＦｉ（Wireless Fidelity）、携帯電話端末など)や端末(電話機やＰＣ、情報家電など)、多様なアプリケーションが使われる。この環境下で端末と網とがＱｏＳをネゴシエーションし、上位アプリケーションに提供できる。次がモビリティのサポートである。一台のＰＣを携帯して例えば家庭内ではｘＤＳＬ、外出先ではＷｉＦｉ、オフィスではＦＴＴＨ（Fiber To The Home）と様々なアクセス網経由で通信したり、オフィス内の移動や出張などにより多数のＰＣから通信したりしてもサービスが受けられることが求められる。詳細な説明は省略するが、この他に、網の転送機能と制御機能の分離、多様なアクセス網のサポート、固定網と移動網の融合（FMC：Fixed Mobile Convergence）、緊急通信や合法的盗聴などの規制への適合などが規定されている。
【００１５】
ＩＴＵ−ＴによるＮＧＮ標準化は、技術的な側面において他の標準化機関との連携が重視されている。ＮＧＮの重要な構成要素の一つであるＩＭＳ（IP Multimedia Subsystem）は、第３世代携帯電話の標準化団体である３ＧＰＰが開発したものであり、そこで使われるＳＩＰ（Session Initiation Protocol）他のプロトコルの多くはＩＥＴＦ（Internet Engineering Task Force）で開発されたものである。
【００１６】
ＮＧＮの標準化において採用された上記ＩＭＳは、固定電話網や移動体通信網など、これまで回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰで統合し、マルチメディア・サービスを実現させる通信方式である。
【００１７】
以下、ＩＭＳの役割・機能を簡単に説明する。第１は、マルチメディア・セッションの確立のサポートである。マルチメディア端末間のエンド・ツー・エンドの通信を確立する技術が、マルチメディア・セッション制御である。ＩＭＳでは、ＩＥＴＦで定義されているＳＩＰなどのセッション制御のためのプロトコルをベースに、ＩＰ伝送網をベアラ（伝達網）として使用し、ＩＰ伝送網内あるいは自ＩＰ網と他ＩＰ網間、他ＩＭＳ網間やＰＳＴＮ（固定電話網）網間においてマルチメディア・セッションを提供する。
【００１８】
第２は、エンド・ツー・エンドの通信において、一定の伝送品質を維持し、必要な伝送帯域を確保した通信を保証・実現する（ＱｏＳ制御）である。ＩＭＳでは、発着信ユーザ端末の契約条件や通信種別（音声、映像、データなど）に応じて、ＩＰパケット伝送網上のネットワーク・ノードを制御し、品質クラスの指定と必要帯域を確保した上で、通信を確立する。
【００１９】
第３は、ＩＰ（パケット）網と回線交換網上のインターワーク（協調動作）のサポートである。ＩＭＳは、ＩＰベースのマルチメディア・サービスを携帯電話や無線ＬＡＮ端末など、アクセス網に依存せずに提供するだけでなく、既存の電話網や他のＩＰパケット伝送網と接続しサービスを提供することも可能である。
【００２０】
その他、ＩＭＳにはローミングのサポート、迅速なアプリケーションサービス作成のサポート、およびＧＰＲＳ（General Packet Radio Service）以外のネットワークからのアクセスに対する新たなサポート等の役割・機能がある。
【００２１】
なお、ＩＭＳ以外でネットワークの伝送帯域を指示できるプロトコルとしては、Ｄｉａｍｅｔｅｒ（ダイアメータ）や従来のＩＰネットワークでＱｏＳに使用されているＲＳＶＰ（Resource reSerVation Protocol）がある。
【００２２】
ＳＩＰのシステムは、大きくユーザ・エージェントとＳＩＰサーバから構成される。ユーザ・エージェントは、ＩＰ電話機能を持つＰＣなどのユーザ端末のことである。ユーザ・エージェントは、リクエストを送信する機能を持つユーザ・エージェント・クライアントと、リクエストに応答する機能を持つユーザ・エージェント・サーバにより構成される。本実施の形態では、ユーザ端末１がユーザ・エージェント・クライアントであり、ユーザ端末２がユーザ・エージェント・サーバに相当する。
【００２３】
ＳＩＰサーバは、プロキシ・サーバ、リダイレクト・サーバ、レジストラ、およびロケーション・サーバを総称したものである。以下、各サーバの機能を簡単に説明する。
【００２４】
プロキシ・サーバは、ユーザ・エージェント・クライアントからのＳＩＰリクエストを、次のサーバに中継するサーバである。プロキシ・サーバでは、認証、許可、ネットワーク・アクセス制御、ルーティング、ＳＩＰリクエスト転送、セキュリティなどの機能も提供する。
【００２５】
またリダイレクト・サーバは、リクエストを受け取り、着信側ユーザ・エージェントの現在のアドレスを発信側ユーザ・エージェントに知らせる役割を持つ。ユーザ・エージェント・クライアントは、リダイレクト・サーバから返された着信側アドレスに発信し直す。プロキシ・サーバとは異なり、ＳＩＰリクエストは転送しない。
【００２６】
またレジストラは、ユーザ・エージェント・クライアントの現在位置を登録するリクエスト（ＲＥＧＩＳＴＥＲリクエスト）を受けるサーバである。レジストラは、通常プロキシ・サーバやリダイレクト・サーバと同じホスト・コンピュータ上で動作する。
【００２７】
さらにロケーション・サーバは、レジストラ・サーバからの登録情報を保管し、リダイレクト・サーバやプロキシ・サーバによる着信ＵＲＩ（Uniform Resource Identifier）の参照要求に応答するサーバである。ロケーション・サーバは、ＳＩＰサーバと同じ場所に設置できる。
【００２８】
これらのサーバ（機能）は必ずしも一台のホスト・コンピュータ上に実装される必要はない。また、必ずしも同じ場所に設置する必要もない。本実施の形態では、これらを一つにまとめ呼制御サーバ４として表現している。
【００２９】
なお、ＩＰネットワーク上では、ＳＩＰによってセッション（接続）制御を行うサーバをＳＩＰサーバと呼ぶが、ＩＭＳではこれをＣＳＣＦ（Call Session Control Function）と呼ぶ。ＣＳＣＦは、ネットワーク内の役割に応じて、Ｐ−ＣＳＣＦ（Proxy- Call Session Control Function）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）、Ｓ−ＣＳＣＦ（Serving- Call Session Control Function）の３つのＣＳＣＦに分けられ、それぞれ異なる機能を提供している。
【００３０】
上述のＳＩＰは、電話ネットワークをＩＰネットワークに統合するために必要な技術として検討されてきた経緯がある。したがって、ＳＩＰのシステムの重要な機能として、ＩＰ電話を始めとする様々なＩＰネットワーク・アプリケーションで従来の電話番号を利用できるＥＮＵＭ（E.164 Number Mapping）がある。
【００３１】
ＥＮＵＭの標準化は、ＩＥＴＦとＩＴＵ−Ｔが共同して作業を進めている。ＥＮＵＭとＳＩＰの連携ということでは、ＳＩＰ端末（ユーザ端末１，２）によるＥＮＵＭ検索と、ＳＩＰサーバ（呼制御サーバ４）によるＥＮＵＭ検索がある。
【００３２】
ＥＮＵＭは、電話番号をネット上のアドレスやサービスと対応づけ、アクセス手段として利用する技術である。ＩＴＵ−Ｔ(国際電気通信連合)が定めた国際的に一意な電話番号体系(「Ｅ１６４」と呼ばれる)と特殊なドメイン領域(「.e164.arpa」のサブドメイン)をＤＮＳ（Domain Name System）で対応させることにより、電話番号とネットワーク上のサービスやアドレスを対応させている。１つの番号に対応させるアドレスなどは複数でもよい。例えば、自分の電話番号をＥＮＵＭで電子メールアドレスやＦＡＸ番号、ＷｅｂサイトのＵＲＬなどと対応させておけば、電話番号が自分へのアクセス手段の統一的な識別番号として利用できるようになる。例えば「03-1234-5678」という電話番号に対応するＥＮＵＭ（Ｅ１６４番号）のドメイン名は、先頭の０を日本の国番号８１で置換して逆順に並べた「8.7.6.5.4.3.2.1.3.1.8.e164.arpa」となる。このＤＮＳレコードに対応するアドレスなどを、ユーザ端末１，２または呼制御サーバ４に保管しておくのである。
【００３３】
このようなＥＮＵＭの機能によって、ユーザは特に意識することなく従来の電話番号を使用して、様々なＩＰネットワーク・アプリケーションを利用することができる。
【００３４】
次に、図１に示すユーザ端末１，２の構成を説明する。図２はユーザ端末１のブロック構成例を示している。ユーザ端末１とユーザ端末２の構成は同一であるので、ユーザ端末１について説明し、ユーザ端末２については説明を省略する。
【００３５】
まず図２に示すユーザ端末１は、上記のとおりユーザ・エージェント・クライアントであり、ユーザの操作に応じてユーザ端末２に通信確立を要求するものである。このユーザ端末１としては、テレビ電話機能を備えたビデオ会議装置の他、パーソナルコンピュータ（ＰＣ）等が適用できる。
【００３６】
このユーザ端末１は、制御手段１１と、操作部１２と、リモコン通信手段１３と、映像データ伸張手段１４と、音声データ伸張手段１５と、映像・音声出力手段１６と、映像データ圧縮手段１９と、音声データ圧縮手段２０と、映像・音声入力手段２１と、外部記憶装置２５から構成される。
【００３７】
ネットワーク通信手段１０は、ＮＧＮ３（図１参照）の規格に基づいたネットワーク１０を通じて、映像データ等のコンテンツや電子メールの送受信を行う通信インターフェースである。
【００３８】
制御手段１１は、各機能部を制御することにより、ユーザ端末１全体を制御するものである。制御手段１１は、後述するようにプログラムに従って動作し、電話番号帯域データからダイヤルされた電話番号に対応する帯域情報を抽出する帯域情報抽出部と、抽出された帯域情報を含む発信要求を、呼制御サーバ４に通知する発信要求通知部と、抽出された帯域情報を、通信帯域に応じて課金を行う課金サーバ５に通知する帯域情報通知部として機能する。この制御手段１１としては、一例として、ＣＰＵ等の演算制御装置が適用され、メモリ手段１１ａをワークエリアとして使用し、メモリ手段１１ａに記録されているプログラムに従って演算および制御を実行する。このメモリ手段１１ａとしては、ＲＡＭやＲＯＭ等が適用される。
【００３９】
操作部１２は、ユーザ端末１の外装に設置されたボタン部などであり、ユーザの操作による入力信号を制御手段１１に入力する。
【００４０】
リモコン通信手段１３は、リモコン送信機１ａからの赤外線等を利用したリモコン信号を受け付けて、制御手段１１に入力する。
【００４１】
映像データ伸張手段１４は、制御手段１１より供給されたコンテンツに含まれる映像データをＨ．３２３等の規格に従って伸張（復号）し、映像・音声出力手段１６に供給するモジュール（デコーダ）である。この映像データ伸張手段１４は、ハードウェア又はソフトウェアにより構成される。
【００４２】
また、音声データ伸張手段１５は、制御手段１１より供給されたコンテンツに含まれる音声データをＨ．３２３等の規格に従って伸張（復号）し、映像・音声出力手段１６に供給するモジュール（デコーダ）である。この音声データ伸張手段１５は、ハードウェア又はソフトウェアにより構成される。
【００４３】
映像・音声出力手段１６は、伸張された映像データを一時的に記憶するフレームメモリ機能と、このフレームメモリに記憶されたフレームデータを表示装置１７に出力するディスプレイコントローラ機能を有する。また、この映像・音声出力手段１６は、伸張されたデジタル音声データをアナログ音声データへ変換・増幅するなどの処理を行い、スピーカ１８に出力するサウンドドライバ機能を有する。
【００４４】
コンテンツが、テキストデータやＷＷＷページなどのエンコードされていないものである場合には、映像データ伸張手段１４および音声データ伸張手段１５でコンテンツの伸張処理を行わずに、コンテンツを映像・音声出力手段１６へ出力する。または、映像データ伸張手段１４および音声データ伸張手段１５を介在させないようにしてもよい。
【００４５】
映像・音声入力手段２１は、カメラ２２から入力された映像信号を処理し、映像データ圧縮手段１９に出力するビデオドライバ機能を有する。また、この映像・音声入力手段２１は、マイクロホン２３で集音されたアナログ音声信号をデジタル音声信号に変換し、音声データ圧縮手段２０に出力する。
【００４６】
映像データ圧縮手段１９は、Ｈ．３２３等の規格に従って映像データを圧縮（符号化）し、制御手段１１に出力する機能を持つモジュール（エンコーダ）である。
【００４７】
また、音声データ圧縮手段２０は、Ｈ．３２３等の規格に従って音声データを圧縮（符号化）し、制御手段１１に出力する機能を持つモジュール（エンコーダ）である。
【００４８】
外部記憶装置２５は、外部記憶装置２５は、ユーザ端末１に内臓のハードディスクや半導体メモリである。光ディスク記録媒体やメモリカードなどのリムーバブルメディアであってもよい。外部記憶装置２５には、音声や映像、データなどの各種コンテンツが記録される。さらに、電話番号対応帯域データも記憶される。
【００４９】
なお、説明の便宜上、ユーザ端末１をユーザ・エージェント・クライアントとし、ユーザ端末２をユーザ・エージェント・サーバとして説明したが、テレビ電話機やテレビ電話機能を備えたビデオ会議装置やＰＣ等では通常、双方の機能を合わせ持っており、ユーザの操作等に応じてその役割・位置づけが切り替わる。
【００５０】
次に、本実施の形態における帯域制御方式について説明する。本実施の形態は、ＮＧＮ網において、ユーザ端末１が受信した電話番号を分析して、サービスを確定し、サービスに応じた帯域要求を行うものである。図３は、第１の実施の形態に係る帯域制御シーケンス図である。この図３について、図４〜図７を参照して説明する。
【００５１】
図３のシーケンスにおいて、まず、ユーザ端末１がユーザによるダイヤル操作があったことを検出する（ステップＳ１）。ユーザ端末１は、ダイヤルされた電話番号より、電話番号対応帯域データ（図６参照）を参照し、サービスに必要な帯域量を抽出し、発信要求メッセージに必要帯域を設定する（ステップＳ２）。そして、ユーザ端末１はＮＧＮ網の呼制御サーバ４に対してユーザ端末２への発信要求を行い（ステップＳ３）、呼制御サーバ４を介してユーザ端末２との通信（セッション）を確立する。呼制御サーバ４はユーザ端末１からの発信要求メッセージをユーザ端末２へ送る（ステップＳ４）。このステップＳ３,Ｓ４に係るセッション確立のシーケンスを、図４に示す。
【００５２】
図４のセッション確立のシーケンスにおいて、まずユーザ端末１の制御手段１１はユーザのダイヤル操作を受け付けて、図５に示すような接続要求を表す「ＩＮＶＩＴＥ」リクエストを呼制御サーバ４に発信する（ステップＳ１１）。
【００５３】
ＳＩＰはＨＴＴＰをベースとしたプロトコルで、図５に示すように、メッセージすなわち通信データをテキスト形式で表現する。ＳＩＰのメッセージは大きく、「スタートライン」「ヘッダ」「ボディ」に分けられる。
【００５４】
スタートラインは、ＳＩＰメッセージの先頭の行であり、そのＳＩＰメッセージがどのようなもの目的のものなのかを表している。ＩＮＶＩＴＥなどのメソッド名は、リクエストとなるＳＩＰメッセージがどのような制御を要求するものであるかを示し、ＲＦＣ３２６１，２９７６，３３１１等の規格で規定されている。このスタートラインは、ユーザ・エージェント・クライアントからのリクエストまたはユーザ・エージェント・サーバからのレスポンスに応じて、それぞれスタートラインまたはリクエストラインと呼ばれる。
【００５５】
ヘッダは、ＳＩＰメッセージの制御内容について詳細を記したものであり、それぞれ予め規定された意味を持つ複数のヘッダ行により構成される。
【００５６】
ボディは、ＳＩＰメッセージによって運ばれるデータである。この例では、セッションを開設する際のメディアの情報が、ＳＤＰ（Session Description Protocol）という形式で表されている。ＳＤＰで記述される各レコードは、セッション記述、時間記述、メディア記述に分類されるタイプによって、その内容と形式が定められている。
【００５７】
例えば、ｍ行はメディア種別、ポート番号、トランスポート・プロトコル、フォーマットを示している。また、ｂ行は帯域情報を示す。図５に示す例では、ｍ行に「video」、ｂ行に「AS:1024」とあり、映像通信で使用する帯域を１０２４ｋｂｐｓで申告している。また、その下の行に記述されているｍ行には「audio」、ｂ行には「AS:64」とあり、音声通信で使用する帯域を６４ｋｂｐｓで申告している。図３のステップ２における発信要求メッセージに必要帯域を設定するとあるのは、この部分の設定・申請である。例えば、ダイヤルした電話番号が映像コンテンツの配信サービスの場合、より帯域量の大きい１０２４ｋｂｐｓの帯域を予約する。また、ダイヤルした電話番号が音楽コンテンツの配信サービスのような場合、映像コンテンツより帯域は小さくてよいので、帯域量の小さい６４ｋｂｐｓの帯域を予約するなどのように設定する。本設定例では、テレビ会議において、映像（１０２４ｋｂｐｓ）と音声（６４ｋｂｐｓ）の２つのストリームに必要な帯域を同時に申請している。
【００５８】
図４のセッション確立のフローチャートの説明に戻る。ユーザ端末１からの「ＩＮＶＩＴＥ」リクエストを受け付けた呼制御サーバ４は、その「ＩＮＶＩＴＥリ」クエストをユーザ端末２に転送する（ステップＳ１２）とともに、試行中を意味する「１００ Ｔｒｙｉｎｇ」のステータスコードを含むレスポンスをユーザ端末１へ送る（ステップＳ１３）。このステップＳ１１，Ｓ１２は、図３のステップＳ３，Ｓ４に対応する。
【００５９】
「ＩＮＶＩＴＥ」リクエストを受け付けたユーザ端末２は、「１００ Ｔｒｙｉｎｇ」のステータスコードを含むレスポンスを呼制御サーバ４へ返信する（ステップＳ１４）。
【００６０】
さらにユーザ端末２は、セッションの進捗状況を示す「１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ１５，Ｓ１６）。
【００６１】
ユーザ端末２からの「１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、暫定応答の確認を意味する「ＰＲＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ１７，Ｓ１８）。
【００６２】
ユーザ端末１からの「ＰＲＡＣＫ」リクエストを受け付けたユーザ端末２は、「ＰＲＡＣＫ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ１９，Ｓ２０）。
【００６３】
ユーザ端末２からの「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、セッションの変更を意味する「ＵＰＤＡＴＥ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ２１，Ｓ２２）。
【００６４】
ユーザ端末１からの「ＵＰＤＡＴＥ」リクエストを受け付けたユーザ端末２は、「ＵＰＤＡＴＥ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ２３，Ｓ２４）。
【００６５】
また、ユーザ端末２は、上記「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを返信した後、ユーザに電話に出るように促している（呼び出しベルを鳴らすなど）ことを意味する「１８０ Ｒｉｎｇｉｎｇ」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ２５，Ｓ２６）。
【００６６】
ユーザ端末２からの「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、暫定応答の確認を意味する「ＰＲＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ２７，Ｓ２８）。
【００６７】
ユーザ端末１からの「ＰＲＡＣＫ」リクエストを受け付けたユーザ端末２は、「ＰＲＡＣＫ」リクエストに対する処理、すなわちユーザの呼び出しが成功したことを意味する「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ２９，Ｓ３０）。
【００６８】
さらに、ユーザ端末２は、上記「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを返信した後、ステップＳ１２の「ＩＮＶＩＴＥ」リクエストに対する処理が成功したこと、すなわちユーザが電話に応答したことを意味する「２００ ＯＫ（ＩＮＶＩＴＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ３１，Ｓ３２）。
【００６９】
これに対し、「２００ ＯＫ（ＩＮＶＩＴＥ）」のステータスコードを含むレスポンスを受けたユーザ端末１は、セッションの確立を最終的に確認したことを示す「ＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ３３，Ｓ３４）。このような一連の処理によりユーザ端末１とユーザ端末２との間のセッションが確立し、ユーザ端末１とユーザ端末２がリアルタイムコミュニケーションの通信を行うことができる。なお、ユーザ端末１とユーザ端末２との間のセッション確立のシーケンスは一例であり、この例に限られない。
【００７０】
また、図４のシーケンス図において、セッションの終了（切断）処理を記載したので、簡単に説明をしておく。ユーザ端末１からセッションの終了を行う場合、ユーザ端末１のユーザが例えばグラフィカル・ユーザ・インタフェース（GUI: Graphical User Interface）上で通信を切断する操作を行う。するとユーザ端末１は、セッションの終了（切断）を示す「ＢＹＥ」リクエストを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ４１，Ｓ４２）。
【００７１】
ユーザ端末１からの「ＢＹＥ」リクエストを受け付けたユーザ端末２は、「ＢＹＥ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＢＹＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ４３，Ｓ４４）。これにより、セッションが終了する。
【００７２】
ここで、図３のシーケンスの説明に戻る。ステップＳ３の処理が終了後、ユーザ端末１は、ステップＳ３の処理と並行して、ＮＧＮ３の課金サーバ５にステップＳ２にて抽出した帯域を通知し（ステップＳ５）、課金サーバ５の図示しない主記憶装置に登録する。ユーザ端末１は、予め呼制御サーバ４および課金サーバ５の宛先アドレスを解決しているというものとし、直接課金サーバ５へアクセスする。
【００７３】
また、上記ステップＳ５の処理と並行して、ユーザ端末２から呼制御サーバ４を介してユーザ端末１へ発信要求メッセージに対する応答メッセージが返信される（ステップＳ６，Ｓ７）。この応答メッセージは、図４のステップＳ３１，Ｓ３２における「２００ ＯＫ（ＩＮＶＩＥ）」のステータスコードを含むレスポンスに相当する。このようにして、予約した帯域による通信が確立する。
【００７４】
この第１の実施形態によれば、ユーザ端末１にてＮＧＮ３における呼制御サーバ４に帯域予約を行い、この際、同時に課金サーバ５にも同様の帯域情報を渡すことによりユーザ端末１が申請した帯域に応じた課金を行うことができる。さらに通信開始のダイヤル番号(電話番号から)サービスを確定し、サービスに必要な帯域を自動で算出することによって、常に効率的な帯域の申請が可能となる。
【００７５】
ここで、図７に示す帯域対応課金データの例を参照して、課金サーバ５による通知された帯域情報に基づく請求料金の計算方法について説明する。課金サーバ５は、ユーザ端末番号（電話番号）と課金データを対応づけて管理している。図７に示す例は、通信ごとに課金データ１〜ｎまでの情報が蓄積されている。一つの課金データは、予約帯域量[ｋｂｐｓ]、課金レート[円／ｋｂｐｓ]、通信時間[ｓ]、請求料金[円]から構成される情報を蓄積している。請求料金は各項目を乗じて算出される。すなわち、請求料金[円]＝（予約帯域量[ｋｂｐｓ]）＊（課金レート[円／ｋｂｐｓ]）＊（通信時間[ｓ]）の計算式により得られる。なお、図７に示した例では、ユーザ端末番号単位で予約帯域によるセッション毎に請求料金を算出して課金データとともに記憶しているが、月極などにより請求料金の総計（通信料金）を計算し、総計と各課金データの小項目をともに課金サーバ５に蓄積するようにしてもよい。
【００７６】
次に、図８を参照して、本発明の第２の実施の形態の例を説明する。本実施の形態は、呼制御サーバ４が、ユーザ端末１から受信した電話番号を分析して、サービスを確定し、解析結果に基づいて要求された帯域を変更し、サービスに応じた帯域を制御するシステムである。つまり、第１の実施の形態では、ユーザ端末１が電話番号対応の帯域データをメッセージに含むものであり、本実施の形態では、呼制御サーバ４が電話番号対応の帯域データからメッセージ内容を更新する点で相違する。
【００７７】
図８は、第２の実施の形態に係る帯域制御シーケンス図である。ユーザ端末１がユーザによるダイヤル操作があったことを検出する（ステップＳ５１）。ユーザ端末１は、ダイヤルされた電話番号に基づいて、呼制御サーバ４を介して発信要求メッセージを送る（ステップＳ５２）。このとき、ユーザ端末１は、発信要求に必要な最低帯域（例えば、Ａｕｄｉｏ，６４ｋｂｐｓをＳＤＰ部に記述したＩＮＶＩＴＥ）を発信要求メッセージとして申請する。
【００７８】
そして、発信要求メッセージを受信した呼制御サーバ４は、受信した発信要求メッセージ内の電話番号より、呼制御サーバ４内の電話番号対応帯域データ（図６参照）を参照し、サービスに必要な帯域量を抽出し（ステップＳ５３）、上記電話番号のサービスに通信に必要な帯域を更新する（ステップＳ５４）。呼制御サーバ４は、ステップＳ５４の処理が終了後、課金サーバ５にステップＳ５３にて抽出したサービスに必要な帯域を通知し（ステップＳ５５）、課金サーバ５の図示しない主記憶装置に登録する。また呼制御サーバ４は、ステップＳ５５の処理と並行して、呼制御サーバ４はユーザ端末１からの発信要求メッセージをユーザ端末２へ送る（ステップＳ５６）。そして、ユーザ端末２から呼制御サーバ４を介してユーザ端末１へ発信要求メッセージに対する応答メッセージが返信される（ステップＳ５７，Ｓ５８）。このようにして、予約した帯域による通信が確立する。
【００７９】
この第２の実施形態によれば、呼制御サーバ４でダイヤル番号(電話番号から)サービスを確定し、サービスに必要な帯域を自動で算出することによって、ユーザの操作によらない常に効率的な帯域の申請が可能となる。その他、この第２の実施の形態は、上記第１の実施の形態と同様の作用効果を奏する。
【００８０】
次に、図９を参照して、本発明の第３の実施の形態の例を説明する。本実施の形態は、要求された帯域量に応じて、呼毎に課金レートを制御するシステムである。
【００８１】
図９は、第３の実施の形態に係る帯域制御シーケンス図である。ユーザ端末１がユーザによるダイヤル操作があったことを検出する（ステップＳ６１）。ユーザ端末１は、ダイヤルされた電話番号より、電話番号対応帯域データ（図６参照）を参照し、サービスに必要な帯域量を抽出し、発信要求メッセージに必要帯域を設定する（ステップＳ６２）。そして、ユーザ端末１はＮＧＮ網の呼制御サーバ４に対してユーザ端末２への発信要求を行い（ステップＳ６３）、呼制御サーバ４を介してユーザ端末２との通信（セッション）を確立する。呼制御サーバ４はユーザ端末１からの発信要求メッセージをユーザ端末２へ送る（ステップＳ６４）。
【００８２】
そして、ユーザ端末２から呼制御サーバ４を介してユーザ端末１へ発信要求メッセージに対する応答メッセージが返信される（ステップＳ６５，Ｓ６６）。このようにして、予約した帯域による通信が確立する。
【００８３】
ユーザ端末１は、ステップＳ６３の処理と並行して、ＮＧＮ３の課金サーバ５にステップＳ６２にて抽出した帯域を通知し（ステップＳ６７）、課金サーバ５の図示しない主記憶装置に登録する（ステップＳ６８）。ユーザ端末１は、予め呼制御サーバ４および課金サーバ５の宛先アドレスを解決しているという前提で、直接課金サーバ５へアクセスする。課金サーバ５は帯域対応課金データに該通信にて申請された帯域量を記録し（ステップＳ６９）、該課金レートより請求料金を算出し、図示しない不揮発性の記憶装置に記録する（ステップＳ７０）。
【００８４】
この第３の実施形態によれば、呼制御サーバ４でダイヤル番号(電話番号から)サービスを確定し、サービスに必要な帯域を自動で算出することによって、ユーザの操作によらない常に効率的な帯域の申請が可能となる。その他、この第３の実施の形態は、上記第１，２の実施の形態と同様の作用効果を奏する。
【００８５】
上記第１〜３の実施の形態により説明した本発明によれば、ユーザ端末が呼制御サーバに帯域予約を行う際、同時に課金サーバにも同様の情報を渡すことにより申請された帯域量に応じて課金レートを制御できる。さらに使用する帯域はダイヤル番号(電話番号)からサービスを確定し、必要な帯域を自動算出することで効率的に帯域を制御することができる。
【００８６】
このように、サービスを実行する毎に自動で算出された帯域を申請することで帯域に応じてユーザ課金を行うこのシステムにより、常にサービスに必要最低限な帯域を要求するようになり、ネットワーク全体の帯域が効率的に使用できる。また所謂ネットワークただ乗り的なユーザアプリケーションの使用を制限することができる。
【００８７】
なお、上記実施の形態では、課金サーバに蓄積された帯域対応課金データに基づく決済処理は、既存の方式を利用して実施することができる。例えば、コンテンツ取得に係る課金データに基づく料金を、銀行等に開設されたユーザの口座から通常の通信料金と一緒にして引き落とすようにしてもよい。あるいは、コンテンツ取得に係る課金データに基づく料金を通常の通信料金と別にして、別途他の口座からの引き落し、オンラインバンキング、振り込み等により決済を行うようにしてもよい。
【００８８】
その他、本発明は、上述した実施の形態の例に限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々の変形、変更が可能であることは勿論である。
【図面の簡単な説明】
【００８９】
【図１】本発明の第１の実施形態に係るネットワーク構成図である。
【図２】本発明の第１の実施形態に係るビデオ会議装置の構成例を示すブロック図である。
【図３】本発明の第１の実施形態に係る伝送帯域制御のシーケンス図である。
【図４】本発明の第１の実施形態に係るセッション確立処理のシーケンス図である。
【図５】本発明の第１の実施形態に係るＩＮＶＩＴＥメッセージの一例を示す説明図である。
【図６】本発明の第１の実施形態に係る電話番号対応帯域データの一例を示す説明図である。
【図７】本発明の第１の実施形態に係る帯域対応課金データの構造を示した説明図である。
【図８】本発明の第２の実施形態に係る伝送帯域制御のシーケンス図である。
【図９】本発明の第３の実施形態に係る伝送帯域制御のシーケンス図である。
【符号の説明】
【００９０】
１，２…ユーザ端末、３…ＮＧＮ、４…呼制御サーバ、５…課金サーバ
【図１】
2009033269.tif 000003
【図２】
2009033269.tif 000004
【図３】
2009033269.tif 000005
【図４】
2009033269.tif 000006
【図５】
2009033269.tif 000007
【図６】
2009033269.tif 000008
【図７】
2009033269.tif 000009
【図８】
2009033269.tif 000010
【図９】
2009033269.tif 000011