JP2006270837A - 通信制御装置 - Google Patents

Abstract

【課題】 通信端末のメディア条件及び通信状態を統合管理し、各種イベントに応じて通信端末環境を最適化する通信制御装置を提供する。
【解決手段】 通信制御モジュール１は、一ユーザの利用可能端末群に属する各通信端末装置が取り扱い可能なメディア情報を保持すると共に各通信端末装置との間で呼制御情報を送受信する端末制御部１１と、呼制御情報に基づいて他ユーザの通信端末装置に対する呼を制御することにより、他ユーザに対して単一の仮想的な端末として機能する仮想端末部１２と、イベント発生を検知した時点で、イベントのメディア情報と端末制御部１１のメディア情報とを参照して前記イベントに対応する通信メディア条件を決定し、この条件に合致する通信端末装置を選択する端末環境最適化部１３とを備える。
【選択図】 図１

Description

本発明は、コンピュータ環境を、ユーザ専用の特定機器ではなく、手近にある様々な機器によって提供するユビキタスコンピューティングに関し、特に、端末を柔軟に選択することが可能なユビキタス通信システムを実現するための通信制御装置に関する。

携帯電話やファクシミリ送受信機などの普及により、個人が利用する通信機器の多様化が進んでいる。従来これらの通信機器はそれぞれ独立に動作し、互いに他の通信機器による通信を意識して通信条件を変更するということはなかった。この主な理由は、それぞれの通信機器が、異なる通信事業者により、異なる通信技術を用いて提供されていたため、相互に通信条件を通知しあう機能を装備することが困難であったということにある。

しかしながら、近年のＶｏＩＰ（Voice over Internet Protocol）の普及によって、あらゆる通信がＩＰ技術を用いて制御可能となってきた。このため、上述のような機能を実装することが比較的容易となってきている。

また一方で、個人が利用するコンピュータ環境や、それによって提供される様々なサービス、例えば電子メールの送受信や各種チケットの予約・購買といったサービスを、ユーザ専用の特定機器ではなく、手近にある機器によって提供する、いわゆるユビキタスコンピューティングの検討が進んでいる。

これらの技術的な動向を背景として、ユビキタスコンピューティングの概念を通信環境に適用し、手近にある様々な通信機器を組み合わせてユーザの通信環境を提供（以下、これをユビキタス通信という）しようとした場合、実際に通信システムのどの位置で、どのようなタイミングで、何を根拠として通信環境を提供するかという課題を解決しなければならない。

そのような課題を解決するために、従来、図１１に示すように、通信システム上に複数ユーザの端末およびメディア環境を統合的に管理する端末メディア管理手段９１を設けることが提案されている（例えば特許文献１参照）。端末メディア管理手段９１には、通信メディアに応じて、通信を行わせる端末ペアが予め設定されている。そして、ユーザからの呼設定要求を受け付けると、端末メディア管理手段９１は、要求に含まれる通信メディアを実現可能な端末ペアを指定し、それぞれの端末に対してメディアを指定した接続命令を出す。この接続命令に従っていずれかの端末が発呼を行うことにより、前記端末ペア間で通信が行われる。このようにして、ユーザの利用可能端末群同士において、メディアに応じた端末を用いた通信が実現される。
特開平９−６２５９７号公報

しかし、上述した従来の技術では、通信を行わせる端末ペアを予め決定しておく必要があり、通信メディアやイベントに応じて柔軟に端末を選択することは不可能であった。つまり、上記従来の技術では、通信制御シーケンスの途中のイベント（例えば発呼イベント）を監視してそのイベントに適合する端末を優先して利用することや、着信イベントを監視して着信イベントに適合する端末を優先して利用するといった制御を実現することは難しい。

また、上記従来の技術は、通話条件を常に監視する機能を持たないため、発呼側あるいは着呼側の端末条件が変更された場合、既存の通信に対して通信端末を動的に追加、変更、削除するといった制御を実現することも困難である。

本発明は、上記した問題を鑑み、通信端末間の通信制御路に介在し、通信端末のメディア条件及び通信状態を統合して管理し、各種イベントに応じて通信端末環境を最適化することが可能な通信制御装置を提供することを目的とする。

上記の目的を達成するために、本発明にかかる通信制御装置は、複数ユーザが相互に通信を行う通信システム上で、一ユーザが利用可能な複数の通信端末装置を含む利用可能端末群を一括して管理し、前記通信端末装置による他ユーザとの通信に介在する通信制御装置であって、前記利用可能端末群に属する通信端末装置のそれぞれに対応して設けられ、各通信端末装置が取り扱い可能なメディア情報を保持すると共に、各通信端末装置との間で呼制御情報を送受信する端末制御部と、前記呼制御情報に基づいて他ユーザの通信端末装置に対する呼を制御することにより、他ユーザに対して前記利用可能端末群をとりまとめる単一の仮想的な端末として機能する仮想端末部と、通信制御シーケンスに関するイベントまたは前記通信システム上の端末環境変更に関するイベントが発生したことを検知した時点で、前記イベントに付随するイベント情報に含まれる当該イベントのメディア情報と前記端末制御部のメディア情報とを参照して前記イベントに対応する通信メディア条件を決定し、決定した通信メディア条件に合致する通信端末装置を、呼に組み入れるべき通信端末装置として前記利用可能端末群から選択する端末環境最適化部とを備えたことを特徴とする。

上記の構成によれば、この通信制御装置を経由して通信を行うユーザは、通信相手ユーザの通信端末装置を意識することなく、仮想端末部を相手ユーザの仮想的な単一の端末とみなせることとなる。また、端末環境最適部が、前記イベントが発生したことを検知した時点で、当該イベントのメディア情報と前記端末制御部のメディア情報とを参照して前記イベントに対応する通信メディア条件を決定し、決定した通信メディア条件に合致する通信端末装置を、呼に組み入れるべき通信端末装置として利用可能端末群から選択することにより、イベントの種類や内容に応じて端末環境を動的かつ柔軟に再構築することができる。

上記の通信制御装置において、前記端末制御部が、各通信端末装置の優先度をさらに保持し、前記端末環境最適化部が、前記通信メディア条件に合致する通信端末装置が複数あった場合、前記優先度に応じて、前記呼に組み入れるべき通信端末装置を選択することが好ましい。これにより、例えば優先的に呼に組み入れるべき端末の優先度を高く設定しておくこと等により、ユーザの通信端末環境をより好ましい状態に再構築することができる。

上記の通信制御装置は、前記イベントが、他ユーザの通信端末装置からの発呼リクエストの受信である場合、前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記利用可能端末群のうち、少なくとも、前記発呼リクエストに含まれるメディア情報とメディア情報が一致する通信端末装置へ、前記発呼リクエストを送信し、着信操作が行われた通信端末装置からの着信レスポンスを受け取ると、当該着信レスポンスに含まれないメディアを利用可能な通信端末装置を、呼に組み入れるべき通信端末装置として選択することが好ましい。

上記の通信制御装置は、前記イベントが、自ユーザの利用可能端末群に属する通信端末装置からの発呼リクエストの受信である場合、前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記端末制御部のメディア情報に含まれるが前記発呼リクエストには含まれないメディア情報に対応する通信端末装置を、呼に組み入れるべき通信端末装置として選択することが好ましい。

上記の通信制御装置は、前記イベントが、自ユーザの利用可能端末群へ追加される新たな通信端末装置からの登録リクエストの受信であり、前記端末環境最適化部は、他ユーザとの通信中は当該他ユーザのメディア情報を保持し、通信中に前記イベントを検知した場合は、前記他ユーザのメディア情報と前記登録リクエストに含まれるメディア情報とを対比し、前記登録リクエストに含まれるメディア情報が前記他ユーザのメディア情報と一致する場合は、前記新たな通信端末装置を、呼に組み入れるべき通信端末装置として選択することが好ましい。

本発明によれば、通信端末間の通信制御路に介在し、通信端末のメディア条件及び通信状態を統合して管理し、各種イベントに応じて通信端末環境を最適化することが可能な通信制御装置を提供できる。

以下、本発明の実施形態について、図面を参照しながら説明する。

［第１の実施形態］
図２は、本発明の一実施形態にかかるユビキタス通信システムの基本的構成を概略的に示したブロック図である。本実施形態にかかるユビキタス通信システムでは、ユーザ毎に、当該ユーザの利用可能端末群が予め登録されている。そして、一ユーザの利用可能端末群に対して１つの端末制御モジュール１が設けられている。端末制御モジュール１は、利用可能端末群に含まれる種々の通信端末の通信メディア条件や通信状態を統合して管理する機能を有する。すなわち、各ユーザに対して１つの端末制御モジュール１が存在し、当該ユーザの通信端末と他ユーザの通信端末との通信は、全てこの端末制御モジュール１を介して実行される。

端末制御モジュール１は、各ユーザの利用可能端末群に属するいずれかの端末内か、利用可能端末群からアクセス可能な機器（例えば交換機等の通信制御機器や、ホームサーバ等）内に存在する。つまり、端末制御モジュール１が搭載された端末または機器が、本発明の通信制御装置の一実施形態となる。

図１は、本実施形態にかかる端末制御モジュール１の内部構成を示すブロック図である。図１に示すように、端末制御モジュール１は、端末制御部１１、仮想端末部１２、端末環境最適化部１３を有する。端末制御部１１は、当該ユーザの利用可能端末群に含まれる通信端末毎に存在する。図１の例では、図示しない３つの通信端末（ａ〜ｃ）に対応して、３つの端末制御部１１が存在している。言い換えれば、端末制御部１１に情報が登録されている端末が、「利用可能端末」である。端末制御部１１は、端末ＩＤ等の各端末を特定する情報（図示せず）の他に、各端末が取り扱うことのできるメディアの名称および属性等を、「メディア情報」として保持している。

各通信端末において、電源の入／切や、端末の設定変更などのイベントが生じる都度、各通信端末から端末制御部１１へ、各通信端末で取り扱うことができるメディアの名称および属性が通知される。これにより、端末制御部１１のメディア情報は、常に、通信端末の現状に合わせて更新されることとなる。

端末環境最適化部１３は、通信制御イベントを監視し、発生したイベント毎に予め登録された最適化論理に従って、相手ユーザとの通信に用いる端末およびメディアを決定する。端末環境最適化部１３は、必要に応じて、利用可能端末群に対して、端末制御部１１を介して、発呼要求、変更要求、または切断要求等の呼制御情報を送出する機能も備える。

仮想端末部１２は、相手ユーザの端末（相手ユーザの端末制御モジュール）とのメッセージ送受信機能を有し、通信に利用する端末（呼に組み入れるべき端末）として利用可能端末群から選択された端末のメディア情報を一つのメッセージに合成し、相手ユーザへ送信する。また、仮想端末部１２は、相手ユーザの仮想端末部１２との間で、呼設定、呼切断、およびメディア変更等の呼制御を行う。これにより、本実施形態のユビキタス通信システムのユーザは、通信相手の端末を意識することなく、仮想端末部１２を相手ユーザの仮想的な単一の端末とみなせることとなる。

図３は、本実施形態にかかる端末環境最適化部１３の基本動作を示したフローチャートである。図３に示すように、端末環境最適化部１３は、通信制御イベントを常時監視している（Ｓ１，Ｓ２）。通信制御イベントとしては、通信制御シーケンスに関するイベントと、通信システム上の端末環境変更に関するイベントとがある。通信制御シーケンスに関するイベントとしては例えば発呼リクエストがある。なお、発呼リクエストは、仮想端末部１２を通じて受信する発呼リクエスト（相手ユーザからの発呼の場合）と、端末制御部１１を通じて受信する発呼リクエスト（自らの利用可能端末群のいずれかからの発呼の場合）との二種類がある。また、通信システム上の端末環境変更に関するイベントとしては、例えばあるユーザの利用可能端末群に新しい端末が追加される場合等に当該端末から発行される「登録リクエスト」や、通信中に相手ユーザから送信される「通信条件変更リクエスト」などがある。

通信制御イベントが検出されると（Ｓ２にてＹＥＳ）、端末環境最適化部１３は、そのイベントに含まれるイベント情報と、各端末制御部１１が保持しているメディア情報とを参照し、予め登録されたイベント処理論理に従い、（１）呼に追加すべき端末の決定、（２）呼に追加済みの端末のうち通信条件の変更が必要な端末の決定、または、（３）呼から削除すべき端末の決定、などの処理を行う（Ｓ３）。そして、Ｓ３の処理結果に従い、（１）発呼リクエストの送信、（２）通信条件変更リクエストの送信、または、（３）呼の削除リクエストの送信、などの処理を行う（Ｓ４）。なお、前記イベントが通信制御シーケンスに関するイベントの場合は、イベント情報としては、呼を構成するメディアの情報等を含む。また、前記イベントが通信システム上の端末環境変更に関するイベントである場合は、イベント情報として、端末で利用可能なメディアの情報等を含む。メディア情報には、ビデオや音声といったメディアの種別を表す情報の他に、例えばＭＰＥＧ４やＧ．７１１といったメディアのコーデック情報、使用帯域、メディアストリームが送受信されるＩＰアドレスおよびポート番号といった情報等が含まれる。

上記のＳ３，Ｓ４の処理を、通信制御イベント発生後の状態に適応した通信環境が構築されたと判断されるまで（Ｓ５にてＹＥＳ）繰り返し、Ｓ５の結果がＹＥＳとなった場合は、再びＳ１のイベント監視状態に戻る。

以上のように、本実施形態によれば、端末環境最適化部１３が、イベントが発生した時点で、イベント情報とメディア情報とに基づいて、呼に追加すべき端末を当該ユーザの利用可能端末群の中から選択したり、呼に追加済みの端末のうち接続条件を変更すべき端末を選択したり、または、呼から削除すべき端末を選択したりする。すなわち、本実施形態にかかるユビキタス通信システムでは、ユーザ毎に端末環境最適化部１３を備えたことにより、発生したイベントに応じた通信端末が自動的に選択される。従って、相手ユーザとの通信に用いる端末ペアを予め決定しておく必要があった従来のユビキタス通信システム（図１１参照）に比較して、柔軟な端末選択が可能なユビキタス通信システムを実現することができる。

なお、上述のＳ３において、端末環境最適化部１３が追加、変更、または削除すべき端末を決定する場合の論理の一例として、予め設定された優先度に従う、という方法が考えられる。この場合、図４に示すように、端末制御部１１において、各端末のメディア情報に加えて、各端末の優先度を保持するようにすれば良い。そして、端末環境最適化部１３が、上述のＳ３の実行時に、前述のイベント情報およびメディア情報に加えて、優先度を勘案すれば良い。つまり、複数の端末が同一のメディアを取り扱い可能な場合には、優先度が高い順に端末が選択される。

このように、端末環境最適化部１３が、追加、変更、または削除すべき端末を決定する際に、イベント情報およびメディア情報に加えて、あらかじめ定められた優先度を勘案すれば、例えば優先的に呼に組み入れるべき端末の優先度を高く設定しておくこと等により、ユーザの通信端末環境をより好ましい状態にすることができる。

ここで、図５を参照し、図３のＳ１，Ｓ２において検出したイベントが他ユーザからの着信イベントであった場合の、端末環境最適化部１３の動作について説明する。

この場合、図５に示すように、相手ユーザの端末からの着呼を検出すると（Ｓ１１）、端末環境最適化部１３は、相手ユーザとの呼制御通信を開始する（Ｓ１２）。

次に、端末環境最適化部１３は、相手ユーザの発呼リクエストからメディア情報を抽出する（Ｓ１３）。次に、端末環境最適化部１３は、端末制御部１１を介して、端末制御モジュール１に登録されている利用可能端末の全てに対し、前記発呼リクエストを送信する（Ｓ１４）。この場合、全利用可能端末において、着呼を知らせる呼び出し音等が発せられることとなる。前記Ｓ１４で発呼リクエストを送信すると、端末環境最適化部１３は着信レスポンス待ち状態となる（Ｓ１５）。

そして、ユーザがいずれかの端末において着呼動作を行うと、当該端末から、端末制御モジュール１において当該端末に対応する端末制御部１１へ、着信レスポンスが返される。端末環境最適化部１３は、その着信レスポンスを端末制御部１１から受け取る。着信レスポンスには、着信レスポンスを発行した端末が通信に利用することを承諾したメディアおよびその条件が記述されている。従って、端末環境最適化部１３は、Ｓ１３で発呼リクエストから抽出したメディア情報と、着信レスポンスに含まれるメディア情報とを比較する。これにより、利用可能端末の中に、発呼リクエストに含まれているが既着の着信レスポンスには含まれていないメディア（以下、不足メディアと称する）の取り扱いが可能な端末があるか否かを判断する（Ｓ１６）。

Ｓ１６の結果がＹＥＳである場合、不足メディアについての発呼リクエストを再送信し（Ｓ１７）、Ｓ１５の着信レスポンス待ち状態へ戻る。Ｓ１７において、不足メディアの取り扱いが可能でない端末に対して既出の発呼リクエストがあれば、その発呼リクエストをキャンセルすることが好ましい。

以下、Ｓ１５〜Ｓ１７の処理を、Ｓ１６の結果がＮＯとなるまで繰り返す。Ｓ１６の結果がＮＯとなると、全着信レスポンスを合成して相手ユーザへの着信レスポンスを生成し（Ｓ１８）、相手ユーザへ送信する（Ｓ１９）。

以上の手順により、相手ユーザからの着信イベントの受信を契機として、相手ユーザの発呼リクエストに含まれるメディアに適合する端末を選択し、選択された端末と相手ユーザの端末との間に呼を設定することができる。これにより、相手ユーザから着信イベントを受信した際に、そのメディアに応じた通信端末環境を、動的かつ柔軟に構築することができる。

なお、Ｓ１４において、端末制御モジュール１に登録されている利用可能端末の全てに対して発呼リクエストを送信するものとしたが、これは一例に過ぎない。すなわち、利用可能端末群のうち、少なくとも、発呼リクエストに含まれるメディア情報とメディア情報が一致する通信端末装置へ、発呼リクエストを送信すれば良い。

次に、図６を参照し、図３のＳ１，Ｓ２において検出したイベントが自らの利用可能端末のいずれかから受信した発信イベントであった場合の、端末環境最適化部１３の動作について説明する。

この場合、図６に示すように、自らの利用可能端末のいずれかからの発呼を検出すると（Ｓ２１）、端末環境最適化部１３は、相手ユーザとの呼制御通信を開始する（Ｓ２２）。

次に、端末環境最適化部１３は、発呼リクエストからメディア情報を抽出する（Ｓ２３）。そして、端末環境最適化部１３は、Ｓ２３で発呼リクエストから抽出したメディア情報と、端末制御部１１のメディア情報とを比較することにより、利用可能端末の中に、発呼リクエストに含まれているメディア以外のメディア（以下、未追加メディアと称する）の取り扱いが可能な端末があるか否かを判断する（Ｓ２４）。

Ｓ２４の結果がＹＥＳである場合、当該端末に対して未追加メディアについての発呼リクエストを送信し（Ｓ２５）、Ｓ２３へ戻る。

これ以降、Ｓ２３〜Ｓ２５の処理を、Ｓ２４の結果がＮＯとなるまで繰り返す。Ｓ２４の結果がＮＯとなると、全発呼リクエストを合成し（Ｓ２６）、相手ユーザへ送信する（Ｓ２７）。

以上の手順により、自分の利用可能端末からの発信イベントの受信を契機として、自らの利用可能端末群によって取り扱い可能なメディアを選択し、そのメディア情報を含む発呼リクエストを生成して送信することができる。これにより、例えば当初の発呼リクエストが「音声」というメディア情報のみを含むものであり、利用可能端末群の中に「ビデオ」を取り扱い可能な端末が存在した場合、最終的に相手ユーザへ送信する発呼リクエストは「音声」と「ビデオ」の両方のメディア情報を含むこととなる。このように、自らの利用可能端末の状況に応じて、相手ユーザとの通信環境を動的かつ柔軟に構築することができる。

以下、図７（ａ）〜（ｃ）を参照しながら、より具体的な例を用いて、本実施形態のユビキタス通信システムの動作を説明する。なお、図７（ａ）〜（ｃ）では、ユーザＡとユーザＢとの間で通信が行われる例を示し、ユーザＡの端末制御モジュールを１Ａ，ユーザＢの端末制御モジュールを１Ｂと表す。また、各ユーザの端末制御モジュールの構成部材についても、同様に、参照符号の後にユーザの区別を表すＡ，Ｂを付す。

ここで、図７（ａ）に示すように、ユーザＡの端末としてＴＶ電話機３１があり、ユーザＢの端末として、ＴＶ電話機３２と、音声のみ通話可能な携帯電話機３３とがあるものとする。ユーザＡがユーザＢに対して発呼動作を行うと、ユーザＡのＴＶ電話機３１からの発呼リクエストは、一旦ユーザＡの端末制御モジュール１Ａの仮想端末部１２Ａを経由して、ユーザＢの端末制御モジュール１Ｂの仮想端末部１２Ｂへ送信される。ここでは、ＴＶ電話機３１からの発呼リクエストには、「ビデオ」と「音声」の二種類のメディアが含まれている。仮想端末部１２Ｂは、発呼リクエストに含まれるメディア（音声、ビデオ）を記憶する。

ユーザＢの端末制御モジュール１Ｂの仮想端末部１２Ｂで着信があると、端末環境最適化部１３Ｂは、前述したように、端末制御部１１Ｂに登録されている全ての端末へ、受信した発呼リクエストを配布する。この場合、ユーザＢの利用可能端末であるＴＶ電話機３２と携帯電話機３３の両方で呼び出し音が鳴ることになる。なおこの際、予め端末制御モジュール１Ｂに登録されているメディア情報に基づき、ユーザＢの利用可能端末で取り扱いが可能でないメディアについては、発呼リクエストから除いてもよい。

ここで、図７（ｂ）に示すように、ユーザＢが、手近にあった携帯電話機３３で「通話」ボタンを押して着呼動作を行ったとする。これを通知する着呼レスポンスは端末制御モジュール１Ｂの仮想端末部１２Ｂに通知される。通常、レスポンスには、端末が通信に利用することを承諾したメディア及びその条件が記述されている。この場合は、携帯電話機３３からのレスポンスには「音声」のメディアが記述されている。仮想端末部１２Ｂでは、上述のとおり、発呼リクエストに含まれるメディア（音声、ビデオ）を記憶しているので、端末環境最適化部１３Ｂは、これをレスポンスに記述されたメディアの情報と比較し、なお「ビデオ」のメディアが不足していることが認知できる。

ここで、図７（ａ）に示したように、ＴＶ電話機３２に対しては、音声とビデオの両方のメディア情報を含む発呼リクエストを送付していたが、「音声」のメディアについては携帯電話機３３からレスポンスが得られた。従って、図７（ｂ）に示すように、当初の発行リクエストを変更し、ＴＶ電話機３２に対して、「ビデオ」のみの発行リクエストを送信する。呼制御プロトコルにＳＩＰ（Session Initiation Protocol）が用いられている場合は、先のリクエストをキャンセルし、改めて、「ビデオ」のみをメディアとして含む発呼リクエストを送信することにより、リクエストの変更ができる。この際、特殊なフラグをリクエスト中に挿入することによって、受信した端末では無条件に通信が開始されるようにしてもよい。

この結果、図７（ｃ）に示すように、ＴＶ電話機３２からの着信レスポンスには「ビデオ」のみが含まれているため、端末制御モジュール１Ｂにおいて、発呼リクエスト中にふくまれていた全てのメディア（音声、ビデオ）について着信が確認できる。その後、端末制御モジュール１Ｂの仮想端末部１２Ｂは、受信した着信レスポンスに含まれるメディア情報を一つのメディア情報として合成し、単一の着信レスポンスとして発呼元ユーザに送信する。

［第２の実施形態］
本発明にかかるユビキタス通信システムの他の実施形態について、図８および図９を参照しながら説明する。なお、本実施形態にかかるユビキタス通信システムの端末制御モジュールの構成は第１の実施形態において図４に示したとおりである。すなわち、利用可能端末群の各端末について、端末制御部１１にメディア情報と優先度が格納されている。

本実施形態にかかるユビキタス通信システムは、ユーザの端末環境に変化があった場合、その時点で他ユーザとの間で呼が存在していたら、変更後の環境に応じて動的に呼を再設定する機能を有する。なお、ユーザの端末環境の変化とは、そのユーザの利用可能端末群に対する、端末の追加、変更、または削除の他に、各端末におけるメディア種別の追加、削除、またはコーデック、使用帯域、メディアストリームが送受信されるＩＰアドレスおよびポート番号といった各メディア種別に関するパラメータの変化を意味する。

図８および図９は、本実施形態にかかる端末制御モジュール１における端末環境最適化部１３の動作を示すフローチャートである。ただし、図８は利用可能端末群に変更があった端末制御モジュール１側の動作を示し、図９は、図８の端末制御モジュール１との間に呼が存在する端末制御モジュール側の動作を示す。

端末環境に変化があった場合、変化の対象となった端末に対応する端末制御部１１から端末環境最適化部１３へ、登録リクエストが送られる。なお、登録リクエストには、端末の追加、変更、または削除に伴うメディア種別の追加、削除、またはコーデック、使用帯域、メディアストリームが送受信されるＩＰアドレスおよびポート番号といった各メディア種別に関するパラメータの変化が記述されている。端末環境最適化部１３は、図８に示すように、この登録リクエストを受信すると（Ｓ３１）、他ユーザの端末との間に呼が存在するか否かを判断する（Ｓ３２）。

Ｓ３２の結果がＮＯであれば、端末制御モジュール１にその端末に該当する端末制御部を登録して処理を終了する（Ｓ３９）。一方、Ｓ３２の結果がＹＥＳであれば、端末環境最適化部１３は、新規メディアの追加があったか否かを判断する（Ｓ３３）。Ｓ３３の結果がＹＥＳであれば、その新規メディアに対応する端末に対して、当該端末に対応する端末制御部１１を介して、現時点での不足メディアについての発呼リクエストを送信する（Ｓ３４）。そして、その端末からのレスポンスを受信すると（Ｓ３５）、相手ユーザに対して通信条件の変更リクエストを送出する（Ｓ３６）。この変更リクエストには、変更されたメディアの情報が記述されている。

一方、Ｓ３３の結果がＮＯであった場合は、変更があった端末の優先度と、呼が設定されている端末の優先度とを比較し（Ｓ３７）、前者の優先度の方が高ければ（Ｓ３７にてＹＥＳ）、呼が設定されている端末の該当メディアの切断要求を送信すると共に、優先度が高い端末（前記の変更があった端末）でそのメディアについて呼を設定する（Ｓ３８）。

以上が、利用可能端末群に変更があったユーザの端末制御モジュール１における端末環境最適化部１３の動作である。一方、利用可能端末群に変更があったユーザと通信中であったユーザの端末制御モジュール１における端末環境最適化部１３の動作は、以下のとおりである。

図９に示すように、端末環境最適化部１３は、相手ユーザ（利用可能端末群に変更があったユーザ）から、通信条件変更リクエストを受信する（Ｓ４１）と、そのリクエスト中に指定されたメディアの情報を参照し、自分の利用可能端末群の中に、そのメディアを取り扱い可能な端末があるか否かを判断する（Ｓ４２）。Ｓ４２の結果がＹＥＳであれば、そのメディアが新規メディアか否かを判断する（Ｓ４３）。Ｓ４３の結果がＹＥＳであれば、端末環境最適化部１３は、Ｓ４２において前記メディアを取り扱い可能と判断された端末に、新規メディアで着信させる（Ｓ４４）。そして、端末環境最適化部１３は、その端末からレスポンスを取得し（Ｓ４５）、取得したレスポンスを相手ユーザへ返送する（Ｓ４６）。

一方、Ｓ４３の結果がＮＯであった場合は、端末環境最適化部１３は、そのメディアを利用可能な端末へ、端末制御部１１を介して、通信条件変更リクエストを送信する（Ｓ４７）。そして、その端末からレスポンスを取得し（Ｓ４６）、取得したレスポンスを相手ユーザへ返送する（Ｓ４９）。

以上のとおり、本実施形態のユビキタス通信システムでは、利用可能端末群に変更があった場合は、それを契機として、利用可能端末群に変更があったユーザと、当該ユーザと通信中であったユーザの両方において、端末環境が最適化される。つまり、呼が存在する状態においていずれかのユーザの端末環境に変化が生じた場合でも、変化後の端末環境に適合するように、自動的に呼が設定しなおされる。これにより、端末環境の変化に応じて、動的かつ柔軟な端末選択が可能となる。

以下、図１０（ａ）〜（ｃ）を参照しながら、より具体的な例を用いて、本実施形態のユビキタス通信システムの動作を説明する。なお、図１０（ａ）〜（ｃ）では、ユーザＡとユーザＢとの間で通信が行われる例を示し、ユーザＡの端末制御モジュールを１Ａ，ユーザＢの端末制御モジュールを１Ｂと表す。また、各ユーザの端末制御モジュールの構成部材についても、同様に、参照符号の後にユーザの区別を表すＡ，Ｂを付す。

ここでは、図１０（ａ）に示すように、ユーザＡの利用可能端末としてＴＶ電話機３１が登録されており、ユーザＢの利用可能端末としてＴＶ電話機３２が登録されているものとする。また、ユーザＡとユーザＢが、ＴＶ電話機３１とＴＶ電話機３２で互いに通話している状況であるとする。図１０（ａ）において太線で示した経路Ｐは、実際の音声およびビデオパケットが送受信される経路である。通常のＩＰ電話システムでは、音声およびビデオパケットは、この経路Ｐで示したように、端末間で直接やりとりされる。端末制御モジュール１Ａ，１Ｂを経由するのは、これらのパケットがどのようなメディアであって、どこに送付されるのかという情報（メディア情報）である。

上記の状態で、ユーザＢが新たに携帯電話機３３を自らの利用可能端末として新規に登録したものとする。この登録動作は、例えばＲＦＩＤのような接近感知システムを用いて実現することが可能である。例えば、既存端末（ここではＴＶ電話機３２）にＲＦＩＤリーダを装備しておき、新たな端末（ここでは携帯電話機３３）にＲＦＩＤタグを装備し、そのタグに新たな端末に関する情報を記憶させておく。そして、既存端末へ新たな端末を接近させたとき、前記タグの情報を既存端末のＲＦＩＤリーダが読み取ることで、既存端末の端末環境最適化部１３によって新たな端末の登録リクエストを受け取ったと判断するように構成すれば良い。

このように新たな端末の登録リクエストを受信した端末管理モジュール１Ｂは、現通話メディアテーブルを参照し、「音声」がこの現通話メディアテーブルに含まれているか否かを判定する。なお、現通話メディアテーブルは、現在通話中のメディアに関する情報を記憶するテーブルであり、端末制御モジュール１の仮想端末部１２内に設けられる（図示省略）。

図１０（ａ）の場合は、ＴＶ電話機３２のメディアとして「音声」が当初から存在するので、次に、端末制御部１１Ｂに記憶されている各端末の優先度を参照し、既存端末の優先度に比べて新規端末の優先度が高いかどうかを判定する。この場合、「音声」については、既存端末であるＴＶ電話機３２よりも携帯電話機３３の方が、優先度が高く設定されているものとする。この場合、図１０（ｂ）に示すように、ＴＶ電話機３２の音声を切断し、新たに携帯電話機３３へ、音声による呼の発呼リクエスト（音声接続要求）を送信する。

携帯電話機３３からのレスポンスを受信した端末制御モジュール１Ｂは、既存のメディア情報（ビデオ）とこのレスポンスに含まれるメディア情報（音声）とを合成して、単一の（音声、ビデオ）をメディア情報として含む、単一の変更発呼リクエストを生成し、相手側に送信する。

変更発呼リクエストを受信したユーザＡの端末制御モジュール１Ａは、現状のメディア情報と比較し、異なる点があれば、端末（ここではＴＶ電話機３１）に対して変更発呼リクエストを送信する。この場合、音声の端末アドレス情報が当初と異なっているので、端末制御モジュール１Ａの端末環境最適化部１３Ａは、変更リクエストをＴＶ電話端末３１へ送信する。変更リクエストは、変更後のメディア情報を全て記述する形式で行う。変更リクエストを受信した端末は、現状のメディア情報と変更リクエストに含まれるメディア情報とを比較して、異なるメディアについては一旦セッションを切断し、リクエストに含まれるメディア情報でセッションを開始する。メディア情報が同一か否かの判断手法は、実装に依存するため任意である。ただし、メディアのアドレス情報が異なる場合は、既存の接続を切断し、新たなアドレスとの間で音声セッションを開始する必要がある。

以上、本発明にかかるユビキタス通信システムの実施形態を例示したが、本発明は、上記した二つの実施形態に限定されるものではなく、発明の技術的範囲内で種々の変更が可能である。

また、上記の実施形態に関し、以下の付記を開示する。
（付記１）
複数ユーザが相互に通信を行う通信システム上で、一ユーザが利用可能な複数の通信端末装置を含む利用可能端末群を一括して管理し、前記通信端末装置による他ユーザとの通信に介在する通信制御装置であって、
前記利用可能端末群に属する通信端末装置のそれぞれに対応して設けられ、各通信端末装置が取り扱い可能なメディア情報を保持すると共に、各通信端末装置との間で呼制御情報を送受信する端末制御部と、
前記呼制御情報に基づいて他ユーザの通信端末装置に対する呼を制御することにより、他ユーザに対して前記利用可能端末群をとりまとめる単一の仮想的な端末として機能する仮想端末部と、
通信制御シーケンスに関するイベントまたは前記通信システム上の端末環境変更に関するイベントが発生したことを検知した時点で、前記イベントに付随するイベント情報に含まれる当該イベントのメディア情報と前記端末制御部のメディア情報とを参照して前記イベントに対応する通信メディア条件を決定し、決定した通信メディア条件に合致する通信端末装置を、呼に組み入れるべき通信端末装置として前記利用可能端末群から選択する端末環境最適化部とを備えたことを特徴とする通信制御装置。
（付記２）
前記端末制御部が、各通信端末装置の優先度をさらに保持し、
前記端末環境最適化部が、前記通信メディア条件に合致する通信端末装置が複数あった場合、前記優先度に応じて、前記呼に組み入れるべき通信端末装置を選択する、付記１に記載の通信制御装置。
（付記３）
前記イベントが、他ユーザの通信端末装置からの発呼リクエストの受信であり、
前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記利用可能端末群のうち、少なくとも、前記発呼リクエストに含まれるメディア情報とメディア情報が一致する通信端末装置へ、前記発呼リクエストを送信し、着信操作が行われた通信端末装置からの着信レスポンスを受け取ると、当該着信レスポンスに含まれないメディアを利用可能な通信端末装置を、呼に組み入れるべき通信端末装置として選択する、付記１または２に記載の通信制御装置。
（付記４）
前記イベントが、自ユーザの利用可能端末群に属する通信端末装置からの発呼リクエストの受信であり、
前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記端末制御部のメディア情報に含まれるが前記発呼リクエストには含まれないメディア情報に対応する通信端末装置を、呼に組み入れるべき通信端末装置として選択する、付記１または２に記載の通信制御装置。
（付記５）
前記イベントが、自ユーザの利用可能端末群へ追加される新たな通信端末装置からの登録リクエストの受信であり、
前記端末環境最適化部は、他ユーザとの通信中は当該他ユーザのメディア情報を保持し、通信中に前記イベントを検知した場合は、前記他ユーザのメディア情報と前記登録リクエストに含まれるメディア情報とを対比し、前記登録リクエストに含まれるメディア情報が前記他ユーザのメディア情報と一致する場合は、前記新たな通信端末装置を、呼に組み入れるべき通信端末装置として選択する、付記１または２に記載の通信制御装置。
（付記６）
前記イベントが、相手ユーザからの通信条件変更リクエストの受信であり、
前記通信条件変更リクエストは、相手ユーザのメディアの変更に関するメディア変更情報を含み、
前記端末環境最適化部は、他ユーザとの通信中は当該他ユーザのメディア情報を保持し、通信中に前記イベントを検知した場合は、前記メディア変更情報と前記端末制御部のメディア情報とを対比することにより、呼に組み入れるべき通信端末装置を選択する、付記１または２に記載の通信制御装置。

本発明は、ユーザの様々な端末によって通信環境を提供するユビキタス通信システムおよびそのシステム上で利用される通信制御装置として利用可能である。

本発明の第１の実施形態にかかるユビキタス通信システムが備える端末制御モジュールの概略構成を示すブロック図である。 第１の実施形態にかかるユビキタス通信システムの基本的構成を概略的に示したブロック図である。 第１の実施形態にかかる端末環境最適化部の動作の一例を示すフローチャートである。 第１の実施形態にかかる端末制御モジュールの他の例の概略構成を示すブロック図である。 検出したイベントが他ユーザからの着信イベントであった場合の、端末環境最適化部の動作を示すフローチャートである。 検出したイベントが自らの発信イベントであった場合の、端末環境最適化部の動作を示すフローチャートである。 （ａ）〜（ｃ）は、第１の実施形態のユビキタス通信システムの動作をより具体的に説明するための図である。 本発明の第２の実施形態において、利用可能端末群に変更があった端末制御モジュール側の端末環境最適化部の動作を示すフローチャートである。 本発明の第２の実施形態において、図８の端末制御モジュールとの間に呼が存在する端末制御モジュールの端末環境最適化部の動作を示すフローチャートである。 （ａ）〜（ｃ）は、第２の実施形態のユビキタス通信システムの動作をより具体的に説明するための図である。 従来のユビキタス通信システムの基本的構成を概略的に示すブロック図である。

符号の説明

１ 端末制御モジュール
１１ 端末制御部
１２ 仮想端末部
１３ 端末環境最適化部
３１ ＴＶ電話機
３２ ＴＶ電話機
３３ 携帯電話機
９１ 端末メディア管理手段

Claims (5)

1. 複数ユーザが相互に通信を行う通信システム上で、一ユーザが利用可能な複数の通信端末装置を含む利用可能端末群を一括して管理し、前記通信端末装置による他ユーザとの通信に介在する通信制御装置であって、
   前記利用可能端末群に属する通信端末装置のそれぞれに対応して設けられ、各通信端末装置が取り扱い可能なメディア情報を保持すると共に、各通信端末装置との間で呼制御情報を送受信する端末制御部と、
   前記呼制御情報に基づいて他ユーザの通信端末装置に対する呼を制御することにより、他ユーザに対して前記利用可能端末群をとりまとめる単一の仮想的な端末として機能する仮想端末部と、
   通信制御シーケンスに関するイベントまたは前記通信システム上の端末環境変更に関するイベントが発生したことを検知した時点で、前記イベントに付随するイベント情報に含まれる当該イベントのメディア情報と前記端末制御部のメディア情報とを参照して前記イベントに対応する通信メディア条件を決定し、決定した通信メディア条件に合致する通信端末装置を、呼に組み入れるべき通信端末装置として前記利用可能端末群から選択する端末環境最適化部とを備えたことを特徴とする通信制御装置。
2. 前記端末制御部が、各通信端末装置の優先度をさらに保持し、
   前記端末環境最適化部が、前記通信メディア条件に合致する通信端末装置が複数あった場合、前記優先度に応じて、前記呼に組み入れるべき通信端末装置を選択する、請求項１に記載の通信制御装置。
3. 前記イベントが、他ユーザの通信端末装置からの発呼リクエストの受信であり、
   前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記利用可能端末群のうち、少なくとも、前記発呼リクエストに含まれるメディア情報とメディア情報が一致する通信端末装置へ、前記発呼リクエストを送信し、着信操作が行われた通信端末装置からの着信レスポンスを受け取ると、当該着信レスポンスに含まれないメディアを利用可能な通信端末装置を、呼に組み入れるべき通信端末装置として選択する、請求項１または２に記載の通信制御装置。
4. 前記イベントが、自ユーザの利用可能端末群に属する通信端末装置からの発呼リクエストの受信であり、
   前記端末環境最適化部は、前記発呼リクエストに含まれるメディア情報と前記端末制御部のメディア情報とを対比し、前記端末制御部のメディア情報に含まれるが前記発呼リクエストには含まれないメディア情報に対応する通信端末装置を、呼に組み入れるべき通信端末装置として選択する、請求項１または２に記載の通信制御装置。
5. 前記イベントが、自ユーザの利用可能端末群へ追加される新たな通信端末装置からの登録リクエストの受信であり、
   前記端末環境最適化部は、他ユーザとの通信中は当該他ユーザのメディア情報を保持し、通信中に前記イベントを検知した場合は、前記他ユーザのメディア情報と前記登録リクエストに含まれるメディア情報とを対比し、前記登録リクエストに含まれるメディア情報が前記他ユーザのメディア情報と一致する場合は、前記新たな通信端末装置を、呼に組み入れるべき通信端末装置として選択する、請求項１または２に記載の通信制御装置。

Images