(57)【要約】【課題】マルチメディアによるオンラインコミュニケーションを実現するシステムにおいて、複数の端末を使い分けるユーザへの発信があったとき、それらの複数端末のなかから最適な端末を選択して着信させる。【解決手段】マルチメディア通信が可能な二つ以上の端末と、端末を使用するユーザの情報を記憶するユーザ情報記憶手段と、端末に関する情報を記憶する端末情報記憶手段と、端末にて利用可能な１以上のコミュニケーションメディアの空塞状態を記憶するメディア情報記憶手段からなるマルチメディアコミュニケーションシステムにおいて、メディア情報記憶手段から、指定されたユーザに関わる全てのコミュニケーションメディアの空塞状態を読み出し、ユーザ情報記憶手段からユーザの動的な状況を読み出し、動的状況に対する条件と空塞状態への変更内容からなる１以上の規則に従って、読み出した空塞状態を変更する。【選択図】  図１
2004153352.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア通信が可能な一つ以上の端末と、
前記端末を使用するユーザの当該端末に関するプレゼンスと、前記ユーザが使用する前記端末の優先度と、前記端末にて利用可能な一つ以上のコミュニケーションメディアの空塞状態とを記憶する制御サーバとからなり、
前記制御サーバは、指定された一人の着信ユーザに関わる全てのコミュニケーションメディアの空塞状態と、
前記着信ユーザのプレゼンスと、
前記プレゼンスに応じた前記空塞状態の変更動作内容からなる１以上のポリシーに従って、前記空塞状態を変更する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項２】
請求項１において、
前記制御サーバは、前記空塞状態を変更した後、
前記着信ユーザの各端末について、あらかじめ割り当てられた優先度の高い順に、あらかじめ指定された１以上のメディアの空塞状態を調べ、
前記メディアが全て空状態である端末を優先着信端末として選択する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項３】
請求項２において、
前記制御サーバは、発信端末から前記着信ユーザとの通信において、指定する一以上のメディアのＩＤを受信した後、
当該指定されたメディアの空塞状態を最初に調べる
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項４】
請求項３において、
前記制御サーバは、発信端末から前記着信ユーザとの通信において、指定する一以上のメディアのＩＤを伴うセッション開始要求を受信した後、
選択した前記優先着信端末へ前記セッション開始要求を転送する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項５】
請求項１において、
さらにメディア変換サーバを備え、
前記制御サーバは、前記空塞状態の変更において、
前記メディア変換サーバによるメディア変換後のメディアが空状態になるのであればメディア変換前のメディアも空状態とする
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項６】
請求項１において、
前記制御サーバは、発信側のユーザに対する条件と前記空塞状態の変更内容からなる一以上のポリシーに従って、前記読み出した空塞状態を変更する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項７】
請求項１において、
前記制御サーバは、時間に対する条件と前記空塞状態の変更内容からなる一以上のポリシーに従って、前記読み出した空塞状態を変更する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項８】
請求項１において、
前記制御サーバは、前記空塞状態を変更した後、
前記着信ユーザのあらかじめ最も高い優先度を割り当てられた端末の、空状態である全てのメディアを選択する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項９】
請求項８記載において、
前記制御サーバは、発信端末から前記着信ユーザとの通信において、
前記選択した空状態である全てのメディアのＩＤを前記発信端末へ送信する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項１０】
請求項９において、
前記発信端末は、
前記制御サーバから前記メディアのＩＤを受信し、
前記メディアのＩＤに対応するメディア名称を当該発信端末の前記ユーザに提示し、
前記ユーザによって選択されたメディアによるマルチメディアコミュニケーションを実行する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項１１】
請求項８において、
前記制御サーバは、前記メディアの選択において、
前記着信ユーザが複数である場合、全ての前記着信ユーザが共通に使用できるメディアを選択する
ことを特徴とするマルチメディアコミュニケーションシステム。
【請求項１２】
請求項１１において、
前記制御サーバは、選択した前記共通に使用できるメディアを用いたセッション開始要求を、
複数の前記着信ユーザのそれぞれの優先着信端末へ送信する
ことを特徴とするマルチメディアコミュニケーションシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークに接続された複数の情報処理装置から成るマルチメディアコミュニケーションシステムに関する。
【０００２】
【従来の技術】
ＩＥＥＥ８０２．１１ｂなどの無線ＬＡＮ技術とＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）などの安価な高速アクセス回線技術の進歩により、駅や喫茶店などの公共スペースからインターネットへ接続するサービスが普及しつつある。また、第三世代携帯電話の商用化により移動体通信サービスの広帯域化も進んでいる。これらのサービスを利用することにより、時間や場所を問わず、ノートＰＣやＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などの携帯性に優れた端末を使ってインターネットに接続し、テキスト、音声、及びビデオなどのマルチメディアによるオンラインコミュニケーションを行うことが可能になりつつある。
【０００３】
このような環境下では、同一ユーザが、場所に応じて使用する端末を変えることが一般的になる、と考えられる。例えば、オフィスではデスクトップ型ＰＣを使用する一方、電車での移動中にはＰＤＡを使用し、駅などの公共スペースではノート型ＰＣを使用する、という使い分けが考えられる。そのため、マルチメディアコミュニケーションサービスでは、発信側のユーザ（以下、発信ユーザという）がマルチメディアコミュニケーションの発信を行った時、着信側のユーザ（以下、着信ユーザという）のどの端末に着信させるかを選択する技術が重要になる。
【０００４】
着信させる端末を選択する技術は、たとえば特許文献１に記載されている。当該技術では、交換機に接続された中央制御装置が、端末のグループとグループ内での各端末の優先度と各端末のコミュニケーションメディア（例えば、テキスト、音声、ビデオ。以下、メディアという）ごとに使用中（塞状態）か使用中でない（空状態）かという空塞状態を記憶し、端末グループに対する着信があった時、端末グループ内の各端末について、メディアの空塞状態を優先度に従って調べ、指定されたメディアが空状態であれば着信させる。
【０００５】
【特許文献１】
特開平５−２２７３０３号公報
【０００６】
【発明が解決しようとする課題】
上記技術において、同一ユーザの端末が同一グループに所属するように端末グループを設定することにより、複数の端末を使い分けるユーザが、自身の端末の中で一番優先度の高い端末で着信できるようになる。しかし、上記従来技術は、各端末にあらかじめ優先度を割り当てておくものであるため、ユーザの動的な状況を反映して着信端末を選択できない。また、上記従来技術には、着信ユーザがその時点で使用できるメディアを、発信ユーザが事前に把握できないため、使用中により通信できないことがある。
【０００７】
したがって、改善されたマルチメディアコミュニケーション制御技術が求められている。
【０００８】
【課題を解決するための手段】
本発明は、端末ごとに割り当てられた優先度と共に、着信ユーザの動的な状況に基づき、マルチメディアコミュニケーションの着信端末を選択する方法を提供する。
【０００９】
また、本発明は、発信ユーザが、着信ユーザが使用できるメディアを事前に把握し、それらのメディアの中から実際に使用するメディアを選択できる技術を提供する。
【００１０】
具体的に、本発明は、マルチメディア通信が可能な一つ以上の端末と、上記端末を使用するユーザの当該端末に関するプレゼンスと、上記ユーザが使用する上記端末の優先度と、上記端末にて利用可能な一つ以上のコミュニケーションメディアの空塞状態とを記憶する制御サーバとからなり、上記制御サーバは、指定された一人の着信ユーザに関わる全てのコミュニケーションメディアの空塞状態と、上記着信ユーザのプレゼンスと、上記プレゼンスに応じた上記空塞状態の変更動作内容からなる１以上のポリシーに従って、上記空塞状態を変更することを特徴とする。
【００１１】
さらに、上記制御サーバは、上記空塞状態を変更した後、上記着信ユーザの各端末について、あらかじめ割り当てられた優先度の高い順に、あらかじめ指定された１以上のメディアの空塞状態を調べ、上記メディアが全て空状態である端末を優先着信端末として選択することを特徴とする。
【００１２】
上記態様によれば、たとえば、デスクトップ型ＰＣの優先度をＰＤＡの優先度より高く設定しているユーザが、デスクトップ型ＰＣの電源をオンにしたまま、ＰＤＡを携帯して外出した場合、従来のようにデスクトップ型ＰＣを着信端末として選択してしまうことなく、ユーザが「離席」している、という状況を反映してＰＤＡを優先させることが可能になる。
【００１３】
また、重要な書類を作成している時や会議中など、ユーザが邪魔されたくない「多忙」な状況下では、全ての端末への着信を拒否することが可能になる。
【００１４】
また、ユーザが、音声を使ったマルチメディアコミュニケーションを実施中である場合、「電話中」という状況を反映し、全ての端末への音声による着信を拒否することが可能になる。さらに、一般に、電話を掛けながらでも、テキストによるコミュニケーションは可能なため、テキストによる着信を許可することが可能になる。
【００１５】
【発明の実施の形態】
以下、本発明の実施例について図面を用いて説明する。以下の図中、同一の部分には同一の符号を付加する。
【００１６】
第一の実施例では、図１に示すような、マルチメディアコミュニケーション制御サーバ（以下、制御サーバという）１、及び従来の端末３が、ＬＡＮなどのネットワーク２０により接続されるマルチメディアコミュニケーションシステムについて説明する。
【００１７】
制御サーバ１は、中央演算装置（以下、ＣＰＵという）２４、ハードディスク等の２次記憶装置（以下、磁気ディスクという）２３、主記憶装置メモリ（以下、主メモリという）２１、バスなどの通信線２２、表示装置などの出力装置（以下、ディスプレイという）２５、キーボードなどの文字入力装置２７、マウス、タッチパネル、或いはスタイラスなどのポインティング装置２６から構成され、ＬＡＮなどのネットワーク２０によって他装置と接続される。
【００１８】
主メモリ２１には、他装置とのネットワーク２０経由の通信を制御する通信制御プログラム１０、マルチメディアコミュニケーションサービスに関わる通信プロトコルの解析を行うプロトコル解析プログラム１１、ユーザの着信端末を選択する着信端末選択プログラム１２、各種テーブルへの読み書きを実行するテーブル管理プログラム１３、システム管理者にグラフィカルなユーザインターフェースを提供するＧＵＩ制御プログラム１４が格納される。
【００１９】
これらのプログラムは、あらかじめ、または可搬型記録媒体からの読み込み、または他のサーバからのネットワーク経由のダウンロードにより、磁気ディスク２３に格納され、必要に応じて主メモリ２１に転送された後、ＣＰＵ２４で実行される。
【００２０】
磁気ディスク２３には、各ユーザの端末とその優先度を記憶する端末管理テーブル１５、各端末にて使用できるメディアの種類を記憶するメディア状態管理テーブル１６、ユーザの動的な状況（以下、プレゼンスという）を記憶するプレゼンス管理テーブル１７、プレゼンスなどの条件に基づき着信端末を選択するときの規則（以下、ポリシーという）を記憶するポリシー管理テーブル１８が格納される。
【００２１】
プレゼンスとは、主にＩＭ（Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サービスが使用する情報であり、本実施例においては、ネットワークに接続しているか否かという接続状況だけでなく、離席や多忙などの連絡可否状況や話中などのユーザの活動状況を含む。
【００２２】
端末管理テーブル１５、メディア状態管理テーブル１６、及びプレゼンス管理テーブル１７は、配列構造を成し１以上のレコードを格納可能である。端末管理テーブル１５の各レコードは、図１２（ａ）に示すように、ユーザを一意に識別するユーザＩＤ２０１、当該ユーザの端末を一意に識別する端末ＩＤ１５０２、その端末の優先度１５０３、及び通信に必要なＩＰアドレスなどの通信情報１５０４から構成される。メディア状態管理テーブル１６の各レコードは、図１２（ｂ）に示すように、端末ＩＤ１５０２、その端末から利用できる一つ以上のメディアを識別するメディアＩＤ１６０３、各メディアの空塞状態１６０４から構成される。プレゼンス管理テーブル１７の各レコードは、図１２（ｃ）に示すように、ユーザＩＤ２０１、一つ以上の端末ＩＤ１５０２、当該ユーザの各端末に関するプレゼンス１７０３から構成される。
【００２３】
プレゼンス１７０３は、例えば、端末３がネットワークに接続していることを示す「オンライン」、端末３がネットワークに接続していないことを示す「オフライン」、端末３はネットワークに接続しているがユーザがその端末３から離れていることを示す「離席」、端末３はネットワークに接続しているがユーザが多忙であることを示す「多忙」、ユーザが電話中であることを示す「話中」といった値をとる。
【００２４】
「オンライン」や「オフライン」といった接続状況を表す値は、例えば、端末３が電源オン、オフ時に、制御サーバ１へその旨を通知し、制御サーバ１のテーブル管理プログラム１３がプレゼンス管理テーブル１７の当該端末を表すレコードのプレゼンス１７０３に書き込めばよい。
【００２５】
「離席」、「多忙」といった連絡可否状況を表す値は、例えば、端末３がユーザのプレゼンス選択操作を受けて、制御サーバ１へその旨を通知し、制御サーバ１のテーブル管理プログラム１３がプレゼンス管理テーブル１７の当該端末を表すレコードのプレゼンス１７０３に書き込めばよい。或いは、ユーザが端末３に対する操作を一定時間行わない時に、端末３が「離席」と判断し、制御サーバ１へその旨を通知してもよい。
【００２６】
「話中」といったユーザの活動を表す値は、例えば、ユーザが電話を掛ける操作を端末３に対して行った時に、端末３が制御サーバ１へその旨を通知し、制御サーバ１のテーブル管理プログラム１３がプレゼンス管理テーブル１７の当該端末を表すレコードのプレゼンス１７０３に書き込めばよい。
【００２７】
図２は、本実施例の、ポリシーを記憶するポリシー管理テーブル１８のデータ構造である。ポリシー管理テーブル１８は、配列構造を成し１以上のレコードを格納可能である。ポリシー管理テーブル１８の各レコードは、ユーザＩＤ２０１、着信端末を選択するときの条件２０２、条件に合致したときの動作２０３から構成される。条件２０２の左辺の「＄ｐｒｅｓｅｎｃｅ」は、ユーザＩＤ２０１によって識別されるユーザのプレゼンスを表し、右辺はプレゼンスの値を表す。
【００２８】
例えばレコード２０４の条件２０２は、ユーザ「ａ」のプレゼンスが「多忙」である、という条件を表す。動作２０３の左辺は「端末．メディア」という形式をとり、右辺は左辺で指定された端末、及びメディアの空塞状態を表す。例えばレコード２０４の動作２０３は、全ての端末の音声を塞状態にすることを表し、レコード２０５の動作２０３は、条件に合致する端末の全てのメディアを塞状態にすることを表す。
【００２９】
ユーザＩＤ２０１に、例えば＊などの予め定めた文字列が格納されている場合、全てのユーザに適用される規則であるとみなしてもよい。また、条件２０２の左辺に、「＄ｃａｌｌｅｒ」という文字列が格納されている場合、発信ユーザに対する条件を表すことにしてもよい。さらに、条件２０２に、「ａｎｄ」、「ｏｒ」、及び「ｎｏｔ」などの論理式を使用できるものとしてもよい。
【００３０】
例えばレコード２０６は、発信ユーザが「ａ」以外の場合、全ての端末の全てのメディアを塞状態にすることを表す。これにより、ユーザ単位のアクセス制御を実現できる。このほか、条件２０２の左辺に「＄ｔｉｍｅ」という文字列が格納されている場合、時間に対する条件を表すことにしてもよい。例えば、時間に対する条件は、１０時から１７時までは会社が従業員に配付した端末を着信端末に加える、といった利用方法が考えられる。
【００３１】
なお、条件２０２や動作２０３を、図２で示した方法以外の方法で表記してもよい。
【００３２】
次に、本実施例に関わるグラフィカルユーザインタフェース（ＧＵＩ）について説明する。
【００３３】
図３は、ユーザ、またはシステム管理者が、ポリシーを登録するためのポリシー登録画面３００の表示例を示す。ポリシー登録画面３００は、制御サーバ１のＧＵＩ制御プログラム１４によってディスプレイ２５に表示され、ユーザ、またはシステム管理者は、文字入力装置２７、ポインティング装置２６などを用いて各パラメータを設定する。
【００３４】
ポリシー登録画面３００は、当該ポリシーを適用する対象となるユーザのユーザＩＤを入力する領域３０１、条件を指定する領域３０２、動作を指定する領域３０３、これらのパラメータで指定されたポリシーを登録するボタン３０４、ポリシーの登録を取り消すボタン３０５から構成される。さらに、領域３０２は、プレゼンスの値を入力する領域３０６、着信ユーザのユーザＩＤを入力する領域３０７、領域３０７で入力したユーザＩＤ以外であることを指定するためのチェックボックス３０８、時間を指定する領域３０９、３１０から構成される。また、領域３０３は、動作の対象として全ての端末を指定するボタン３１１、領域３０２で指定された条件に合致する端末のみを指定するボタン３１２、メディアの種類を入力する領域３１３から構成される。
【００３５】
登録ボタン３０４が押下されると、制御サーバ１のテーブル管理プログラム１３が、設定されたパラメータに従って、ポリシー管理テーブル１８に、新規レコードを追加する。制御サーバ１以外の装置がポリシー登録画面３００を表示し、ユーザ、またはシステム管理者が、その装置を使用してポリシーを登録できるようにしてもよい。
【００３６】
次に、本実施例に関わる通信シーケンス、及び処理シーケンスについて説明する。
【００３７】
図４は、ユーザａが端末ａ１を使用して、ユーザｂへのマルチメディアコミュニケーションを発信するときの通信シーケンスである。最初に、端末ａ１が、制御サーバ１に対して、ユーザｂへのマルチメディアコミュニケーションのセッション開始要求を発行する（Ｓ４０１）。このセッション開始要求には、発信ユーザと着信ユーザのユーザＩＤ、発信ユーザが要求する１以上のメディアのメディアＩＤ、及び端末ａ１と通信を行うための情報（例えば、ＩＰアドレスやポート番号）が含まれる。
【００３８】
制御サーバ１の通信制御プログラム１０がセッション開始要求を受信すると、プロトコル解析プログラム１１が発信ユーザと着信ユーザのユーザＩＤなどの前記セッション開始要求に含まれる情報を取り出した後、着信端末選択処理を実行し（Ｓ４０２）、その結果得られた端末（図４ではｂ１）に対して通信制御プログラム１０がセッション開始要求を転送する（Ｓ４０３）。着信端末選択処理については、図５で説明する。
【００３９】
端末ｂ１は、セッション開始要求を受信すると、セッション開始応答を返信し、それを制御サーバ１の通信制御プログラム１０が端末ａ１に転送する（Ｓ４０４、Ｓ４０５）。最後に、端末ａ１は、上記セッション開始応答に含まれる端末ｂ１と通信を行うための情報（例えば、ＩＰアドレスやポート番号）を用いて端末ｂ１とコネクションを確立した後、そのコネクションの上で、マルチメディアデータを送受信する（Ｓ４０６）。
【００４０】
なお、Ｓ４０６で、端末同士が、マルチメディアデータを送受信するためのコネクションを確立したが、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）装置の通過や集中的なログ収集などの目的のために、マルチメディアデータの中継を行うサーバ経由（図示していない）でコネクションを確立してもよい。
【００４１】
次に、図５を用いて、制御サーバ１の着信端末選択処理（Ｓ４０２）に関わる処理シーケンスを説明する。着信端末選択処理は二つのフェーズに分かれており、第一のフェーズでは、着信ユーザの端末を調べ、それらの端末の各メディアの空塞状態を、ポリシーに基づいて一時的に変更する。第二のフェーズでは、変更されたメディアの空塞状態に基づいて、着信ユーザの各端末について、優先度の高い順から指定されたメディアで着信可能か否かを判定する。
【００４２】
第一のフェーズでは、テーブル管理プログラム１３が、端末管理テーブル１５から、指定された着信ユーザに関わる全てのレコードを読み出す（ステップＳ５０１）。さらに、メディア状態管理テーブル１６から、上記着信ユーザの端末に関わるレコードを全て読み出す（ステップＳ５０２）。ステップＳ５０２にて読み出したレコードは、後の処理に備えて、端末優先度と共に主メモリ２１に待避しておく。そして、プレゼンス管理テーブル１７から、上記着信ユーザに関わる全てのレコードを読み出す（ステップＳ５０３）。次に、ポリシー管理テーブル１８から、上記着信ユーザに関わる先頭レコードを読み出す（ステップＳ５０４）。Ｓ５０１〜Ｓ５０４の実行順序は変更しても良い。
【００４３】
着信端末選択プログラム１２は、ステップＳ５０３で読み出した着信ユーザのプレゼンスの先頭レコードについて、ステップＳ５０４で読み出したポリシーの条件２０２に合致するか調べ（ステップＳ５０５）、合致する場合、ステップＳ５０４で読み出したレコードの動作２０３に従って、ステップＳ５０２にて主メモリ２１に待避したメディア状態の管理レコードの空塞状態を更新する（ステップＳ５０６）。一方、合致しない場合、ステップＳ５０７以降を実行する。
【００４４】
次に、着信端末選択プログラム１２は、ステップＳ５０５、Ｓ５０６の処理を、ステップＳ５０３にて読み出した着信ユーザのプレゼンスの全てのレコードに対して実行する（ステップＳ５０７）。そして、テーブル管理プログラム１３が、ポリシー管理テーブル１８に、着信ユーザに関わるポリシーを記録したレコードがまだ存在するか調べ（ステップＳ５０８）、存在する場合、そのレコードを読み出し（ステップＳ５０９）、ステップＳ５０５からＳ５０７までの処理を繰り返す。
【００４５】
第二のフェーズでは、テーブル管理プログラム１３が、主メモリ２１に待避したメディア状態管理テーブル１６のレコードから、優先度の最も高い端末に関わる全てのレコードを読み出す（ステップＳ５１０）。着信端末選択プログラム１２が、それらのレコードのメディア種別と空塞状態から、当該端末にて使用可能なメディアを導出し、それとセッション開始要求にて指定されたメディアとが合致するか否かを判定する（ステップＳ５１１）。
【００４６】
合致する場合、当該端末を着信端末に決定する（ステップＳ５１２）。合致しない場合、そのほかの端末について、優先度の高い順にステップＳ５１０からステップＳ５１２までの処理を繰り返す（ステップＳ５１３、Ｓ５１４）。全てのレコードを処理しても合致しない場合、指定されたメディアに合致する端末が存在しないことを表すエラーを返信する（ステップＳ５１５）。
【００４７】
本実施例では、各端末のマルチメディアコミュニケーションのクライアントプログラムが、制御サーバ１と通信を行なうことで、起動時には、メディア状態管理テーブル１６に当該端末が使用できるメディアのレコードを空状態として登録し、停止時には、メディア状態管理テーブル１６から当該端末に関わるレコードを削除するものとしている。ただし、端末が、停止処理を正常に実行せずに電源断される場合もあるため、端末が定期的に制御サーバ１と通信するようにした上で、制御サーバ１のテーブル管理プログラム１３が一定時間以上通信のない端末に関わるレコードを、メディア状態管理テーブル１６から削除するようにしてもよい。
【００４８】
また、磁気ディスク２３に格納される各種テーブルを、ネットワーク２０で接続される大容量ストレージ管理装置の磁気ディスクに格納し、テーブル管理プログラム１３がネットワーク２０経由で読み書きしてもよい。特に、制御サーバ１が、複数のドメインに分散配置されている場合、各種テーブルを一つの大容量ストレージ管理装置に格納することにより、制御サーバ１同士が相互に通信するかわりに、発信側の制御サーバ１が直接大容量ストレージ管理装置に格納された着信側のドメインの各種テーブルを参照できるため、ドメインをまたがるマルチメディアコミュニケーションが容易になる。
【００４９】
以上で説明した第一の実施例では、制御サーバ１が、ポリシーを考慮した上で着信端末を選択することにより、ユーザの動的な状況を考慮した上で、マルチメディアコミュニケーションのセッションを着信させる端末を選択することができる。
【００５０】
次に、第二の実施例を説明する。本実施例では、制御サーバ１と端末４、及び既存のセッション制御データ中継サーバ（以下、中継サーバという）２が、ＬＡＮなどのネットワーク２０により接続され、マルチメディアコミュニケーションシステムを構成する。
【００５１】
図６は、本実施例における端末４のシステム構成例である。端末４は、ＣＰＵ２４、磁気ディスク２３、主メモリ２１、バスなどの通信線２２、ディスプレイ２５、文字入力装置２７、ポインティング装置２６、マイク２８、スピーカ２９、ビデオカメラ３０から構成され、ネットワーク２０によって他装置と接続される。
【００５２】
主メモリ２１には、通信制御プログラム１０、プロトコル制御プログラム３１、ポリシーの更新要求を制御サーバ１に発行するポリシー更新プログラム３２、着信ユーザが現時点で使用できるメディアを制御サーバ１に問い合わせるメディア問い合わせプログラム３３、プレゼンスの更新要求を制御サーバ１に発行するプレゼンス更新プログラム３４、マルチメディアコミュニケーションのセッション制御、及びマルチメディアデータ送受信を実行するコミュニケーション制御プログラム３５、およびユーザにグラフィカルなユーザインターフェースを提供するＧＵＩ制御プログラム３６が格納される。
【００５３】
これらのプログラムは、あらかじめ、または可搬型記録媒体からの読み込み、または他のサーバからのダウンロードにより、磁気ディスク２３に格納され、必要に応じて主メモリ２１に転送された後、ＣＰＵ２４で実行される。ただし、端末の種類に従って、マイク２８、スピーカ２９、またはビデオカメラ３０はなくてもよい。
【００５４】
本実施例における中継サーバ２は、端末間でやり取りされるセッション制御データを中継する役割を担う。中継サーバ２は、例えば、ＲＦＣ３２６１にて規定されているＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）プロキシに相当する。
【００５５】
図７を用いて、ユーザａが端末ａ１を使用して、ユーザｂへのマルチメディアコミュニケーションのセッションを発信するときの通信シーケンスを説明する。
【００５６】
最初に、端末ａ１のメディア問い合わせプログラム３３が、制御サーバ１へ、ユーザｂの着信端末とその着信端末が使用できるメディアを問い合わせる（ステップＳ７０１）。制御サーバ１の通信制御プログラム１０が、メディアの問い合わせを受信すると、プロトコル解析プログラム１１が前記メディア問い合わせを解析し、発信ユーザと着信ユーザのユーザＩＤを取り出した後、着信端末選択プログラム１２が着信端末選択処理を実行し（ステップＳ７０２）、その結果得られたユーザｂの着信端末の端末ＩＤ（図７ではｂ１）と、その着信端末が使用できる１以上のメディアのメディアＩＤを基に、プロトコル解析プログラム１１が問い合わせ応答を組み立て、通信制御プログラム１０が返信する（ステップＳ７０３）。本実施例における着信端末選択処理については後述する。
【００５７】
端末ａ１の通信制御プログラム１０が問い合わせ応答を受信すると、プロトコル解析プログラム３１が前記応答を解析した後、ＧＵＩ制御プログラム３６が、ユーザａが使用するメディアを選択するためのメディア選択画面８００をディスプレイ２５に表示する（ステップＳ７０４）。このメディア選択画面８００については、図８を用いて説明する。ユーザａがメディアを選択すると、端末ａ１のプロトコル解析プログラム３１が、端末ｂ１に対するセッション開始要求を組み立て、通信制御プログラム１０が中継サーバ２に対して前記セッション開始要求を発行する（ステップＳ７０５）。
【００５８】
このセッション開始要求には、付加情報として、ステップＳ７０３で得た端末ＩＤ（図７ではｂ１）と、ユーザａがメディア選択画面８００を用いて選択した１以上のメディアのメディアＩＤを加える。中継サーバ２は、セッション開始要求を受信すると、その要求を端末ｂ１へ転送する（ステップＳ７０６）。その後のシーケンス（ステップＳ７０７からＳ７０９）は、図４のステップＳ４０４からＳ４０６と同様である。
【００５９】
本実施例の着信端末選択処理について説明する。まず、図５のステップＳ５０１からＳ５１０までを実行する。次に、優先度の最も高い端末（ユーザｂが持つ端末が一つの場合は、当該端末が「優先度の最も高い端末」となる）について、空状態のメディアが１以上存在するか否か判定する。存在する場合、問い合わせ応答として、当該端末の端末ＩＤと、その端末において空状態の全てのメディアのメディアＩＤを返信し、着信端末選択処理を終了する。存在しない場合、次に優先度の高い端末について同様の処理を繰り返す。全ての端末について処理が終了したら、使用できるメディアが存在しないことを表すエラーを返信する。
【００６０】
本実施例では、第一の実施例と異なり、ユーザｂの着信端末が利用可能なメディアを、発信前に問い合わせすることができる。これにより、着信成功率を向上させることが可能となる。
【００６１】
図８は、メディア選択画面８００の表示例である。メディア選択画面８００は、端末４のＧＵＩ制御プログラム３６によってディスプレイ２５に表示され、ユーザは、文字入力装置２７、ポインティング装置２６などを用いて各パラメータを設定する。
【００６２】
メディア選択画面８００は、マルチメディアコミュニケーションにおいて使用するメディアを選択するボタン８０１、マルチメディアコミュニケーションを開始するボタン８０２、メディア選択を取り消すボタン８０３から構成される。
【００６３】
図８の画面例は、着信ユーザの優先着信端末が、テキスト、音声、及びビデオを使用できる一方、発信ユーザはこれらのうち、音声とビデオを選択していることを表す。
【００６４】
以上説明した第二の実施例では、端末４が、着信ユーザの着信端末が使用できるメディアを制御サーバ１へ問い合わせることにより、着信ユーザが使用できるメディアを発信ユーザが事前に把握できるようになり、着信成功率が向上する、という特徴がある。
【００６５】
なお、中継サーバ２が、制御サーバ１の機能を併せ持ってもよい。
【００６６】
次に、第三の実施例を説明する。本実施例では、制御サーバ１、及び既存の中継サーバ２と端末３が、ＬＡＮなどのネットワーク２０により接続され、マルチメディアコミュニケーションシステムを構成する。
【００６７】
本実施例におけるマルチメディアコミュニケーションシステムでは、中継サーバ２と端末３との間の通信を、制御サーバ１が中継する。これにより、端末３と中継サーバ２には設定変更が不要となり、既存の装置を使うことが出来る。
【００６８】
図９を用いて、ユーザａが端末ａ１を使用して、ユーザｂへのマルチメディアコミュニケーションを発信するときの通信シーケンスを説明する。最初に、端末ａ１が、制御サーバ１へ、ユーザｂへのマルチメディアコミュニケーションのセッション開始要求を発行すると、制御サーバ１の通信制御プログラム１０がそのセッション開始要求を中継サーバ２へ転送する（ステップＳ９０１、Ｓ９０２）。さらに、中継サーバ２が、制御サーバ１へ、そのセッション開始要求を転送する（ステップＳ９０３）。
【００６９】
制御サーバ１の通信制御プログラム１０が、中継サーバ２からのセッション開始要求を受信すると、プロトコル解析プログラム１１が前記セッション開始要求に含まれる情報を取り出した後、第一の実施例で説明した着信端末選択処理を実行する（ステップＳ４０２）。そして、制御サーバ１の通信制御プログラム１０は、その結果得られた着信端末（図９では端末ｂ１）にセッション開始要求を転送する（ステップＳ９０４）。そのセッション開始要求を受けて、端末ｂ１は、制御サーバ１へ、セッション開始応答を返信し、制御サーバ１の通信制御プログラム１０がそれを中継サーバ２へ転送する（ステップＳ９０５、Ｓ９０６）。さらに、そのセッション開始応答を、中継サーバ２が制御サーバ１へ転送し、制御サーバ１の通信制御プログラム１０が端末ａ１へ転送する（ステップＳ９０７、Ｓ９０８）。最後に、端末ａ１と端末ｂ１が、直接コネクションを確立した後、そのコネクションの上で、マルチメディアデータを送受信する（ステップＳ９０９）。
【００７０】
以上説明した第三の実施例では、端末と中継サーバ２との間の通信を、制御サーバ１が中継することにより、従来の端末と中継サーバ２を変更することなく、第一の実施例と同様の効果が得られる。
【００７１】
次に、第四の実施例を説明する。本実施例では、第一の実施例のシステムに、テキスト−音声間などのメディア変換を行うメディア変換サーバ５が加わり、発信ユーザと着信ユーザの使用可能メディアの不一致に起因する着信失敗を削減する。
【００７２】
図１０を用いて、ユーザａが端末ａ１を使用して、ユーザｂへのマルチメディアコミュニケーションのセッションを発信するときの通信シーケンスを説明する。ステップＳ１００１からＳ１００５は、図４のステップＳ４０１からＳ４０５と同様である。ただし、ステップＳ１００２にて着信端末選択プログラム１２が実行する着信端末選択処理は、図５と比較して、ステップＳ５０７の前に、メディア変換サーバ５の機能を考慮して空塞状態を変更する点が異なる。例えば、メディア変換サーバ５が、テキストから音声への変換機能を備えている場合、音声が空状態であれば、空状態であるテキストのレコードを追加する（既に、テキストのレコードが存在すれば、空塞状態を空状態に変更する）。また、メディア変換サーバ５が、音声からテキストへの変換機能を備えている場合、テキストが空状態であれば、空状態である音声のレコードを追加する（既に、音声のレコードが存在すれば、空塞状態を空状態に変更する）。
【００７３】
以上の処理の後、端末ａ１が、メディア変換が必要なマルチメディアデータを端末ｂ１に対して送信する場合、まず、端末ａ１は、メディア変換サーバ５へマルチメディアデータを送信する（ステップＳ１００６）。メディア変換サーバ５は、メディア変換処理を実行し（ステップＳ１００７）、変換後のデータを返信する（ステップＳ１００８）。メディア変換サーバ５の性能により、メディア変換後のデータが、ユーザの意図にそぐわない場合もあるため、変換後のデータを受信した端末ａ１は、ユーザａに、変換後のデータを送信してもよいか確認した上で、端末ｂ１へそのデータを送信する（ステップＳ１００９）。なお、このような確認を行わず、端末ｂ１へ送信してもよい。
【００７４】
以上説明した第四の実施例では、メディア変換を考慮した着信端末選択処理を行うことにより、発信ユーザと着信ユーザの使用可能メディアの不一致に起因する着信失敗を削減することができる。なお、本実施例を第二の実施例と組み合わせることにより、メディア選択画面８００にてメディア変換を考慮したメディアを表示するようにしてもよい。
【００７５】
次に、第五の実施例を説明する。本実施例では、三人以上のユーザ間でマルチメディア会議を実施するための会議サーバ６が加わる。
【００７６】
図１１を用いて、ユーザａ、ｂ、及びｃが参加するマルチメディア会議を実施するときの通信シーケンスを説明する。最初に、ユーザａが端末ａ１を使用して、会議サーバ６に対して会議予約を発行する（ステップＳ１１０１）。この会議予約には、付加情報として、会議への参加者のユーザＩＤ（図１１では、ａ、ｂ、及びｃ）、及び会議を開始する日時が加えられる。その後、上記会議予約にて指定された日時に到達すると、会議サーバ６は、制御サーバ１に対して、メディア問い合わせを発行する（ステップＳ１１０２）。この問い合わせには、会議への参加者のユーザＩＤ（図１１では、ａ、ｂ、及びｃ）が含められる。次に、制御サーバ１のプロトコル解析プログラム１１が前記メディア問い合わせを解析し参加者のユーザＩＤを取り出した後、着信端末選択プログラム１２が、メディア選択処理を実行する（ステップＳ１１０３）。本実施例におけるメディア選択処理では、最初に、上記問い合わせにて指定された各ユーザについて、第二の実施例で説明したメディア選択処理を実行する。次に、会議に参加する全てのユーザに共通のメディアを選択し、そのメディアのメディアＩＤと各ユーザの着信端末の端末ＩＤを、会議サーバ６へ問い合わせ応答として返信する（ステップＳ１１０４）。ここで、共通のメディアが存在しない場合は、会議サーバ６へ、メディアが一致しなかったことを表すエラーを返信する。会議サーバ６がこのエラーを受信した場合、会議を予約したユーザの着信端末（図１１では、ａ１）に、メディアが一致しなかったため会議が開始できなかったことを表すエラーを送信する。一方、会議サーバ６が、各ユーザの着信端末のＩＤとメディアＩＤを受信した場合、各ユーザの着信端末にセッション開始要求を発行する（ステップＳ１１０５）。そして、各端末がセッション開始応答を返信した後（ステップＳ１１０６）、マルチメディアデータの送受信を行う（ステップＳ１１０７）。このステップＳ１１０７において、会議サーバ６は、各端末から受信するマルチメディアデータを合成して、他端末へ送信する役割を担う。
【００７７】
なお、会議予約に会議を開始する日時を含めずに、会議サーバ６が会議予約を受信したら、即座に、ステップＳ１１０２以降の処理を実行するようにしてもよい。
【００７８】
以上説明した第五の実施例により、三人以上のユーザ間でのマルチメディア会議において、参加するユーザの動的な状況に応じて、会議に使用する端末とメディアを選択した会議が可能になる。なお、本実施例を第四の実施例と組み合わせることにより、マルチメディア会議にて使用するメディアを増やすことも可能である。
【００７９】
【発明の効果】
本発明により、場所によって複数の端末を使い分けるユーザへのマルチメディアコミュニケーションを、当該ユーザの動的な状況に応じて、適切な端末を選択して着信させることができる。
【図面の簡単な説明】
【図１】各実施例におけるマルチメディアコミュニケーション制御サーバのシステム構成である。
【図２】ポリシー管理テーブルのデータ構造である。
【図３】ポリシー登録画面の表示例である。
【図４】第一の実施例における通信シーケンスである。
【図５】第一の実施例における着信端末選択処理の処理シーケンスである。
【図６】端末のシステム構成である。
【図７】第二の実施例における通信シーケンスである。
【図８】第二の実施例におけるメディア選択画面の表示例である。
【図９】第三の実施例における通信シーケンスである。
【図１０】第四の実施例における通信シーケンスである。
【図１１】第五の実施例における通信シーケンスである。
【図１２】端末管理テーブル、メディア状態管理テーブル、プレゼンス管理テーブルの構成例である。
【符号の説明】
１…マルチメディアコミュニケーション制御サーバ、２…セッション制御データ中継サーバ、３…端末、４…端末、５…メディア変換サーバ、６…会議サーバ、１０…通信制御プログラム、１１…プロトコル解析プログラム、１２…着信端末選択プログラム、１３…テーブル管理プログラム、１４…ＧＵＩ制御プログラム、１５…端末管理テーブル、１６…メディア状態管理テーブル、１７…プレゼンス管理テーブル、１８…ポリシー管理テーブル、２０…ネットワーク、２１…主メモリ、２２…通信線、２３…磁気ディスク、２４…ＣＰＵ、２５…ディスプレイ、２６…ポインティング装置、２７…文字入力装置、２８…マイク、２９…スピーカ、３０…ビデオカメラ、３１…プロトコル解析プログラム、３２…ポリシー更新プログラム、３３…メディア問い合わせプログラム、３４…プレゼンス更新プログラム、３５…コミュニケーション制御プログラム、３６…ＧＵＩ制御プログラム。
【図１】
2004153352.tif 000003
【図２】
2004153352.tif 000004
【図３】
2004153352.tif 000005
【図４】
2004153352.tif 000006
【図５】
2004153352.tif 000007
【図６】
2004153352.tif 000008
【図７】
2004153352.tif 000009
【図８】
2004153352.tif 000010
【図９】
2004153352.tif 000011
【図１０】
2004153352.tif 000012
【図１１】
2004153352.tif 000013
【図１２】
2004153352.tif 000014