(57)【要約】      （修正有）【課題】多者通話から受信したメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器へ配信する、ローカルメディアレンダリングを提供する。【解決手段】メディアは、多者通話の各話者によって符号化され、メディアストリームとしてメディアサーバ１に送信される。メディアサーバ１は、各クライアントユーザ機器２からメディアストリームの要求を受信し、要求内の各メディアストリームは、クライアント優先度に関連付けられている。メディアサーバ１は各クライアントユーザ機器２に送信するメディアストリームを、要求に基づき、ストリームの数が利用可能な帯域幅に基づいて決定された最大数を超えないように選択する。【選択図】図１
2015216646.tif 000002
【特許請求の範囲】
【請求項１】
多者通話から受信するメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器へ配信する、電気通信ネットワークにおけるメディアサーバ(1)のための方法であって、
同時に配信すべきメディアストリームの最大数を、前記クライアントユーザ機器とのネゴシエーションに基づいて決定するステップ(25)と、
前記クライアントユーザ機器から、各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求を定期的に受信するステップ(26)と、
前記要求されたメディアストリームの前記クライアント優先度と、選択されたメディアストリームの数が前記決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて、前記要求からメディアストリームを選択するステップ(27)と、
前記選択されたメディアストリームを前記多者通話のローカルレンダリングのために前記クライアントユーザ機器に送信するステップ(28)と、を有することを特徴とする方法。
【請求項２】
前記メディアサーバが、メディア優先度を各メディアストリームに関連付けるステップをさらに有し、前記メディアストリームを選択する前記ステップ(27)が、前記メディア優先度にも基づくことを特徴とする請求項１記載のメディアサーバのための方法。
【請求項３】
前記メディアストリームに関連付けられる前記メディア優先度が、受信するメディアストリームの少なくとも１つの特性に基づくことを特徴とする請求項２記載のメディアサーバのための方法。
【請求項４】
前記メディアストリームの最大数を決定する前記ステップが、利用可能な帯域幅に基づくことを特徴とする請求項１乃至請求項３のいずれか１項に記載のメディアサーバのための方法。
【請求項５】
前記メディアストリームの最大数を決定する前記ステップが、前記クライアントユーザ機器の能力に基づくことを特徴とする請求項１乃至請求項４のいずれか１項に記載のメディアサーバのための方法。
【請求項６】
前記クライアント優先度が、位置情報、アプリケーション固有情報、およびエンドユーザの選択の少なくとも１つに基づくことを特徴とする請求項１乃至請求項５のいずれか１項に記載のメディアサーバのための方法。
【請求項７】
多者通話の音声又は映像のローカルレンダリングのためにメディアストリームをメディアサーバ(1)から受信する、電気通信ネットワークにおけるクライアントユーザ機器(2)のための方法であって、
各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求を、前記メディアサーバに定期的に送信するステップ(34)と、
要求されたメディアストリームのクライアント優先度と、メディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて前記メディアサーバが選択したメディアストリームを、前記メディアサーバから受信するステップ(35)と、を有することを特徴とする、クライアントユーザ機器のための方法。
【請求項８】
前記クライアントユーザ機器が、前記多者通話のメディアを前記メディアストリームとは別個に受信するレンダリング情報に基づいてローカルレンダリングするステップ(36)をさらに有することを特徴とする請求項７記載のクライアントユーザ機器のための方法。
【請求項９】
前記受信するメディアストリームが、前記メディアサーバによって決定され、前記メディアストリームに関連付けされたメディア優先度にさらに基づいて前記メディアサーバによって選択されていることを特徴とする請求項７または請求項８に記載のクライアントユーザ機器のための方法。
【請求項１０】
前記メディアストリームの最大数が、利用可能な帯域幅に基づいて、前記メディアサーバとのネゴシエーション(33)において決定されることを特徴とする請求項７乃至請求項９のいずれか１項に記載のクライアントユーザ機器のための方法。
【請求項１１】
前記メディアストリームの最大数が、前記クライアントユーザ機器の能力に基づいて、前記メディアサーバとのネゴシエーション(33)において決定されることを特徴とする請求項７乃至請求項１０のいずれか１項に記載のクライアントユーザ機器のための方法。
【請求項１２】
前記クライアント優先度が、位置情報、アプリケーション固有情報、およびエンドユーザの選択の少なくとも１つに基づくことを特徴とする請求項７乃至請求項１１のいずれか１項に記載のクライアントユーザ機器のための方法。
【請求項１３】
多者通話から受信するメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器(2)へ配信するように構成された、電気通信ネットワークに接続可能なメディアサーバ(1)であって、
同時に配信されるメディアストリームの最大数を、前記クライアントユーザ機器とのネゴシエーションに基づいて決定する決定手段(41)と、
前記クライアントユーザ機器から、各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求を定期的に受信する受信手段(42)と、
前記要求されたメディアストリームの前記クライアント優先度と、選択されたメディアストリームの数が前記決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて、受信した要求からメディアストリームを選択する選択手段(43)と、
前記選択されたメディアストリームを多者通話のローカルレンダリングのために前記クライアントユーザ機器に送信する送信手段(44)と、を有することを特徴とするメディアサーバ。
【請求項１４】
前記選択手段がさらに、前記メディアサーバによって決定されて各メディアストリームに関連付けられたメディア優先度に基づいてメディアストリームを選択するように構成されること特徴とする請求項１３記載のメディアサーバ。
【請求項１５】
前記メディア優先度が、受信するメディアストリームの少なくとも１つの特性に基づくことを特徴とする請求項１４記載のメディアサーバ。
【請求項１６】
前記決定手段が、利用可能な帯域幅に基づいて前記メディアストリームの最大数を決定するように構成されることを特徴とする請求項１３乃至請求項１５のいずれか１項に記載のメディアサーバ。
【請求項１７】
前記決定手段が、前記クライアントユーザ機器の能力に基づいて前記メディアストリームの最大数を決定するように構成されることを特徴とする請求項１３乃至請求項１６のいずれか１項に記載のメディアサーバ。
【請求項１８】
多者通話の音声又は映像のローカルレンダリングのためにメディアストリームをメディアサーバ(1)から受信するように構成された、電気通信ネットワークに接続可能なクライアントユーザ機器(2)であって、
各メディアストリームについてのクライアント優先度を示すメディアストリームの要求を生成する生成手段(64)と、
更新された要求を前記メディアサーバに定期的に送信する送信手段(62)と、
前記要求されたメディアストリームの前記クライアント優先度と、メディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて前記メディアサーバが選択したメディアストリームを、前記メディアサーバから受信する第１の受信手段(65)と、を有することを特徴とするクライアントユーザ機器。
【請求項１９】
前記多者通話のメディアを、前記メディアストリームとは別個に受信するレンダリング情報に基づいてローカルレンダリングするレンダリング手段(66)をさらに有することを特徴とする請求項１８記載のクライアントユーザ機器。
【請求項２０】
メタデータをデータサーバ(3)から受信する第２の受信手段(63)を有することを特徴とする請求項１９記載のクライアントユーザ機器。
【請求項２１】
前記クライアントユーザ機器におけるメディア入力を符号化する符号化手段(61)をさらに有することを特徴とする請求項１８乃至請求項２０のいずれか１項に記載のクライアントユーザ機器。
【請求項２２】
前記要求手段(64)が、位置情報、アプリケーション固有情報、およびエンドユーザの選択の少なくとも１つに基づいて前記クライアント優先度を決定するように構成されることを特徴とする請求項１８乃至請求項２１のいずれか１項に記載のクライアントユーザ機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はローカルレンダリングのための、メディアサーバが実施するクライアントユーザ機器へのメディアストリーム配信方法ならびに、クライアントユーザ機器が実行する、メディアサーバからローカルレンダリング用メディアストリームを受信する方法に関する。本発明はさらに、メディアサーバおよびクライアントユーザ機器に関する。
【背景技術】
【０００２】
従前、例えば音声会議のような多者通話の技術的実装は、会議の参加者から発せられる複数のメディアストリームを、各参加者に配信するための１つのメディアストリームに混合するための集中ミキシング機器を有するのが一般的であった。音声会議に関しては、これは１つのモノメディアストリームまたは１つの人工ステレオメディアストリームに対応する。１つのメディアストリームのみを配信する理由の１つは、アクセス帯域幅が限られることであった。
【０００３】
しかし、例えばVDSL2(超高速デジタル加入者線2)のような近年の技術では、少なくとも例えば音声会議のような帯域幅の要求が低いもしくは中程度の用途においては帯域幅の制限を解除するような、ずっと大きなアクセス帯域幅が利用可能である。
【０００４】
本物のステレオまたは３Ｄ（三次元）位置オーディオを多者通話の各参加者に提供するため、クライアントの向きおよび位置、並びに他の参加者の位置及び向きに基づく固有のメディアストリームを各クライアント用にレンダリングする必要がある。そのため、集中レンダリングフレームワークは各参加者の位置及び向きに関する情報を必要とするほか、各クライアント用に１つのレンダリングエンジンを実装しなければならない。さらに、これらのレンダリングエンジンは各参加者についての位置及び向きによって絶えず更新されなければならない。これは仮想空間でのゲームのような、大規模で極めて動的な会議通話において特に困難になる。会議通話に多数の参加者が関与する、このような進んだ音声ミキシングを行う状況で集中音声ミキシングを行うと、集中音声ミキシング装置に極めて大きな処理能力が必要になり、メディアレンダリングのためのシステムアーキテクチャが複雑になるであろう。
【０００５】
従前の集中レンダリングにおいては、音声処理、３Ｄ位置音声のレンダリング、各クライアントについて生成された３Ｄ位置音声信号の符号化を含む全てをメディアサーバ、典型的にはミキサを備えるカンファレンスブリッジが処理している。各参加者が有するクライアントユーザ機器は、それぞれの個別の符号化信号を復号するのみであり、場合によってはユーザにＧＵＩ（グラフィカルユーザインタフェース）を提示する。参加しているクライアントユーザ機器のそれぞれについて、カンファレンスブリッジは３Ｄ位置音声信号を生成するが、それには全ての参加者からの入来音声信号の３Ｄ位置音声レンダリングが必要である。各参加者について固有の３Ｄ位置音声信号が生成されるため、符号化する出力信号数は参加者の数に等しい。
【０００６】
さらに、従前の集中レンダリングでは、極めてインタラクティブなアプリケーションにおける位置情報のレイテンシが正確な音声レンダリングを不可能にする場合があり、それによってユーザ体験の質が低下する。
【０００７】
その反面、ローカルレンダリングにおいて、集中メディアサーバの主なタスクは、例えば全ての参加者からのメディアストリームや、実際に話している２，３の参加者からだけのメディアストリームのような多者通話のメディアストリームのうち、どのストリームをローカルレンダリングのためにどのクライアントユーザ機器に宛てるかを決定することである。メディアサーバから選択されたメディアストリームを受信すると、各参加者のクライアントユーザ機器はローカルメディアレンダリングを実行するであろう。メディアサーバでトランスコーディングが不要な場合、すなわち全てのクライアントユーザ機器が他の全てのクライアントユーザ機器のコーデックをサポートしている場合には、メディアサーバは入来メディアストリームをリダイレクトするだけで良く、符号化や音声レンダリングは一切行わない。
【０００８】
国際公開第WO2009/092060号は、クライアントで局所的にメディアをレンダリングするためのシステムを記載している。３Ｄ位置音声のローカルレンダリングは、集中機器、すなわちメディアサーバの処理能力への要求を軽減し、位置情報のレイテンシを削減する。WO2009/092060号に記載されたシステムにおいて、各メディアストリームはメディアデータ（すなわち音声）および位置情報（すなわちメディア構成要素の位置及びエネルギー）とを含んでいる。さらに、WO2009/092060号は、参加者に関するローカル情報のみならず、全参加者の位置情報およびメディアストリームにアクセスする、参加者ごとの「フィルタ要素」（例えば図１の１１１を参照）。しかし、システムの実装は比較的複雑である。
【発明の概要】
【０００９】
以下に説明する実施形態の位置目的は、上述したような問題の少なくともいくつかを解決することであり、この目的並びに他の目的は、添付した独立請求項に係る方法および装置、ならびに従属請求項に係る実施形態によって達成される。
【００１０】
第１の見地によれば、多者通話から受信したメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器へ配信する、電気通信ネットワークにおけるメディアサーバのための方法が提供される。この方法は、同時に配信すべきメディアストリームの最大数を、クライアントユーザ機器とのネゴシエーションによってメディアサーバが決定するステップを有する。さらに、メディアサーバは、クライアントユーザ機器から、各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求を定期的に受信するであろう。メディアサーバは要求されたメディアストリームのクライアント優先度と、選択されるメディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて、要求からメディアストリームを選択し、選択されたメディアストリームを多者通話のローカルレンダリングのためにクライアントユーザ機器に送信するであろう。
【００１１】
第２の見地によれば、多者通話の音声又は映像のローカルレンダリングのためにメディアストリームをメディアサーバから受信する、電気通信ネットワークにおけるクライアントユーザ機器のための方法が提供される。この方法はクライアントユーザ機器が、各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求をメディアサーバに定期的に送信するステップを有する。さらにクライアントユーザ機器は、メディアサーバが、要求されたメディアストリームのクライアント優先度と、メディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて選択したメディアストリームをメディアサーバから受信するであろう。
【００１２】
第３の見地によれば、多者通話から受信したメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器へ配信するように構成された、電気通信ネットワークに接続可能なメディアサーバが提供される。メディアサーバは同時に配信すべきメディアストリームの最大数を、クライアントユーザ機器とのネゴシエーションに基づいて決定する決定手段と、要求されたメディアストリームの各々についてのクライアント優先度を示す、更新されたメディアストリーム要求をクライアントユーザ機器から定期的に受信する受信手段とを有する。さらにメディアサーバは、要求されたメディアストリームのクライアント優先度と、選択されるメディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて、受信した要求からメディアストリームを選択する選択手段を有する。メディアサーバはさらに、選択されたメディアストリームを多者通話のローカルレンダリングのためにクライアントユーザ機器に送信する送信手段を有する。
【００１３】
第４の見地によれば、多者通話の音声又は映像のローカルレンダリングのためにメディアストリームをメディアサーバから受信するように構成された、電気通信ネットワークに接続可能なクライアントユーザ機器が提供される。クライアントユーザ機器は各メディアストリームについてのクライアント優先度を示すメディアストリーム要求を生成する要求手段と、更新された要求をメディアサーバに定期的に送信する送信手段とを有する。さらにクライアントユーザ機器は、メディアサーバが、要求されたメディアストリームのクライアント優先度と、受信されるメディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて選択したメディアストリームをメディアサーバから受信する第１の受信手段を有する。
【００１４】
例示的な実施形態による利点は、低コストおよび十分に活用されていないクライアントリソースを、コストの掛かる集中リソースの代わりに用い、メディアストリームを他の情報と別個に送信することにより、大規模かつ極めて動的な会議の、比較的複雑でないローカルレンダリングを提供することである。
【図面の簡単な説明】
【００１５】
【図１】ローカルメディアレンダリングのための例示的なアーキテクチャを模式的に示す図である。
【図２】メディアサーバのための例示的な方法を模式的に示すフローチャートである。
【図３】クライアントユーザ機器のための例示的な方法を模式的に示すフローチャートである。
【図４】例示的なメディアサーバを模式的に示す図である。
【図５】例示的なメディアサーバを模式的に示す図である。
【図６】例示的なクライアントユーザ機器を模式的に示す図である。
【図７】例示的なクライアントユーザ機器を模式的に示す図である。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照して、本発明の例示的な実施形態をより詳細に説明する。
以下の記載においては、本発明を所定の実施形態ならびに添付図面に関してより詳細に説明する。限定ではなく説明を目的とし、本発明の完全な理解を提供するために特定のシナリオ、技術など具体的な詳細を述べる。しかし、本技術分野の当業者には、本発明がそれら具体的な詳細とは離れた他の実施形態において実施されうることが明らかであろう。
【００１７】
さらに、本技術分野に属する当業者は、以下に説明する機能および手段が、プログラムされたマイクロプロセッサまたは汎用コンピュータとともにソフトウェア機能を用いて、および／または特定用途向け集積回路(ASIC)を用いて実施されうることを理解するであろう。さらに、本発明を方法及および装置の形態で主に説明するが、本発明はコンピュータプログラムや、コンピュータプロセッサと、ここで説明する機能を実行しうる１つ以上のプログラムがコード化されている、プロセッサに接続されたメモリとを有するシステムにおいても実施することができることが理解されるであろう。
【００１８】
以下で説明する例示的な実施形態に係るコンセプトは、メディアストリームとは別個に送信されているレンダリング情報を用いて、多者通話の極めて動的なローカルメディアレンダリングを提供することである。ある例示的な実施形態によれば、参加クライアントユーザ機器は近くに位置する他の参加クライアントユーザ機器に関するレンダリング情報、例えば地理的な特性(property)を、データサーバ内のメディアアプリケーションから受信する。それにより、メディアサーバがこの情報を有する必要が無い。
【００１９】
代わりに、参加クライアントユーザ機器の各々がメディアサーバに、選択されたメディアストリーム、典型的には合理的な距離内に位置する他の参加クライアントユーザ機器からのメディアストリームの配信を要求する。この要求はさらに、以下ではクライアント優先度と称する、各メディアストリームについての優先度を含んでおり、クライアント優先度は例えば、メディアストリームの「ソース」の位置に基づくことができる。ここで、「ソース」の各々は、他の参加クライアントユーザ機器に対応する。メディアサーバは、どのメディアストリームを各クライアントユーザ機器に配信すべきかを、例えば要求されたメディアストリームのクライアント優先度に基づいて決定するが、メディアストリームはさらに、メディアサーバによって重み付けされたり優先度が与えられたりしてもよい。この優先度はメディアストリームの１つ以上の特性、例えば信号強度に基づくものであってよく、以下ではメディア優先度と称する。さらに、メディアストリームの数は、クライアントユーザ機器に同時に送信可能なメディアストリームの最大数を超えてはならない。この最大数は通常、セッションの開始時に、クライアントユーザ機器とのネゴシエーションで決定される。
【００２０】
図１は、上述したローカルレンダリングのための例示的なアーキテクチャを模式的に示しており、データサーバ３によって制御される、メディアアプリケーションを実行する複数のクライアントユーザ機器を有している。しかし、図１では１つのクライアントユーザ機器２のみを示している。クライアントユーザ機器２にはさらに、エンドユーザによってクライアントユーザ機器へ入力されたメディアを符号化するステップ２１と、エンドユーザに出力するためのメディアをレンダリングするステップ２２と、メディアサーバ１にメディアストリームを要求するステップ２３とが示され、この要求は信号Ｓ１５においてメディアサーバに通信されている。メディアアプリケーションは、リアルタイム音声または映像のようなメディアを含み、メディアはメディアサーバ１によってクライアントに供給される。メディアアプリケーションに含まれるメディアは、信号Ｓ１６においてデータサーバから受信するレンダリング情報に従い、ステップ２２においてクライアントユーザ機器でローカルレンダリングされる。レンダリング情報は例えば３Ｄレンダリングに必要となるかもしれない、参加クライアントユーザ機器の地理的特性を有してよい。
【００２１】
上述の通り、クライアントユーザ機器２およびメディアサーバ１は、メディアサーバからクライアントユーザ機器に同時に転送されうるメディアストリームの最大数を決定するため、セッション確立時にネゴシエートする。このメディアストリームの最大数は、例えば、利用可能な帯域幅および／またはクライアントユーザ機器が受信したメディアストリームを処理する能力に基づいて決定される。しかし、メディアサーバまたはクライアントユーザ機器が必要とする場合には、決定されたメディアストリーム数がセッション中に再ネゴシエーションされてもよい。
【００２２】
セッション中、クライアントユーザ機器は要求ステップ２３において、利用可能なメディアストリーム上でどのメディアストリームをメディアサーバから受信したいかを、メディアストリーム（すなわち、各メディアストリームのソースクライアントユーザ機器）に関する要求情報（メタデータ）に基づいて継続的に決定する。メタデータ３１は信号Ｓ１６においてデータサーバ３によってクライアントユーザ機器２に提供されるが、エンドユーザ（図１には示されていない）からも提供されてよい。従って、要求情報は例えば、データサーバによって提供されるようなソースクライアントユーザ機器に関する位置情報、エンドユーザによって手動入力される情報、データサーバによって提供されるアプリケーション固有情報、および／またはデータサーバによって提供される各参加クライアントユーザ機器に関する優先度を有してよい。選択されたメディアストリームを受信するため、クライアントユーザ機器は、メディアストリームのソースである他の参加クライアントユーザ機器の各々に関するメタデータに基づき、更新された要求をメディアサーバに信号Ｓ１５で定期的に送信する。メディアストリームは、例えばクライアントユーザ機器がローカルレンダリングのために受信したいメディアストリームのソース（すなわちクライアントユーザ機器）のＩＤのリストとして要求内に示されてよい。さらに、このリストは各メディアストリームに関し、メディアストリームの重みを示すクライアント優先度を有する。クライアント優先度は、上述した要求情報（メタデータ）に基づいている。
【００２３】
図１では１つのクライアントおよび１つの信号しか示していないが、メディアサーバは多者通話の参加クライアントユーザ機器全てから、符号化されたメディアストリームを信号Ｓ１４で受信する。クライアントユーザ機器からの要求に基づき、メディアサーバ１はメディア選択ステップ１１において、各クライアントユーザ機器にどのメディアストリームを配信すべきか、およびメディアサーバとクライアントユーザ機器との間で利用可能なメディアストリーム上でユーザクライアント機器２に信号Ｓ１３でどのメディアストリームを送信するかを継続的に決定する。メディアサーバによるこの決定は、クライアントユーザ機器から信号Ｓ１５で受信する要求に示されるクライアント優先度に基づくが、さらに、メディア重み付けステップ１２でメディアサーバが決定するメディア優先度にも基づいてもよい。このメディア重み付けはメディアストリームの１つ以上の特性、例えば信号強度に基づくこともありうる。さらに、配信すべきストリームの選択もまた、決定された、クライアントユーザ機器に同時に送信可能なメディアストリームの最大数に基づく。
【００２４】
従って、図１では、メディアストリームがメディアのレンダリングに必要な情報とは別個に送信されていることを強調するため、メディアストリームＳ１３およびＳ１４は実線で示される一方、情報信号Ｓ１５およびＳ１６は破線で示されている。
【００２５】
例示的な実施形態によれば、このメディアサーバは、各メディアストリームについてのメディア優先度をクライアントユーザ機器から受信した要求内の対応するクライアント優先度に加算し、最も高い合計優先度を有するメディアストリームを選択するとともに、メディアストリームの数を決定されたメディアストリームの最大数を超えないように定めることによって選択を実施してよい。
【００２６】
ソースクライアントユーザ機器は要求内で、クライアントユーザ機器に既知である任意のグローバルＩＤ、例えばＲＴＰ（リアルタイムプロトコル）のＳＳＲＣ、によって特定されてよく、要求はクライアントユーザ機器からメディアサーバに、例えばＢＦＣＰ（バイナリフロア制御プロトコル）の拡張のような、適切なプロトコルを通じて通信される。
【００２７】
個々のクライアントユーザ機器間でのグローバルＩＤの通信は、データサーバ３によって実施されるのが一般的である。
【００２８】
図２は、多者通話からのメディアストリームをローカルレンダリングのためにクライアントユーザ機器２に配信する、メディアサーバ１のための方法の例示的な実施形態を示すフローチャートである。ステップ２４でのセッション開始後、ステップ２５でメディアサーバは、クライアントユーザ機器へ同時に送信可能なメディアストリームの最大数を決定する。この決定はクライアントユーザ機器とのネゴシエーションにおいて実行され、例えば利用可能な帯域幅およびクライアントユーザ機器の能力に基づくことができる。
【００２９】
ステップ２６でメディアサーバは、クライアントユーザ機器から、クライアントユーザ機器が受信を希望するメディアストリームを示す要求を受信する。より高い優先度に関連付けられたメディアストリームがより低い優先度に関連付けられたメディアストリームより先にクライアントユーザ機器へ送信されるために選択されるよう、要求内の各メディアストリームはメディアストリームの重みを示すクライアント優先度に関連付けられている。要求内に示されるクライアント優先度は例えば、ソースクライアントユーザ機器の地理的特性、データサーバから受信した優先度、アプリケーション固有情報、および／またはエンドユーザによる選択に基づくものであってよい。
【００３０】
ステップ２７でメディアサーバは、要求から複数のストリームを選択することにより、どのメディアストリームをクライアントユーザ機器に送信するかを決定する。この選択は要求内に示されるクライアント優先度と、メディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件とに基づく。別の実施形態によれば、メディアサーバはメディアストリームの重み付けを例えば信号強度に基づいて実施し、その重みが決定に含まれるようにメディア優先度として各メディアストリームに関連付ける。次に、ステップ２８でメディアサーバは、選択されたメディアストリームをクライアントユーザ機器に送信する。
【００３１】
クライアントユーザ機器は更新された要求を定期的にメディアサーバに送信するので、ステップ２６〜２８はステップ２９でセッションが終了するまで繰り返される。
【００３２】
図３は、ローカルレンダリングのためにメディアサーバからメディアストリームを受信する、クライアントユーザ機器のための方法の例示的な実施形態を示すフローチャートである。
【００３３】
ステップ３２でのセッション開始後、ステップ３３でクライアントユーザ機器は、例えば利用可能な帯域幅およびクライアントユーザ機器の能力に基づいて、メディアサーバから同時に受信可能なメディアストリームの最大数を決定するためにメディアサーバとネゴシエーションする。
【００３４】
ステップ３４でクライアントユーザ機器は、受信を希望するメディアストリームを示す要求をメディアサーバに送信する。より高い優先度を有するメディアストリームをより低い優先度を有するメディアストリームより先に受信することをクライアントユーザ機器が好むよう、要求内の各メディアストリームはメディアストリームの重みを示すクライアント優先度に関連付けられている。要求内に示される優先度は例えば、ソースクライアントユーザ機器の地理的特性、データサーバから受信した優先度、アプリケーション固有情報、および／またはエンドユーザによる選択に基づくものであってよい。
【００３５】
ステップ３５でクライアントユーザ機器は、要求からのメディアサーバによる選択に従い、メディアサーバからメディアストリームを受信する。この選択は要求内に示されるメディアストリームのクライアント優先度と、決定されたクライアントユーザ機器に同時に送信可能なメディアストリームの最大数をメディアストリームの数が超えてはならないという条件とに基づく。別の実施形態によれば、メディアサーバはメディアストリームの重み付けを例えば信号強度に基づいて実施し、その重みを決定においてメディア優先度として含める。
【００３６】
メディアストリームを受信するとクライアントユーザ機器は、多者通話のメディアのローカルレンダリングを、メディアストリームとは別個にメタデータとしてデータサーバ３から受信する、ソースクライアントユーザ機器の地理的特性のような適切なレンダリング情報に基づいて実行する。
【００３７】
クライアントユーザ機器はセッション中、更新された要求を定期的にメディアサーバに送信し、ステップ３７でセッションが終了するまでステップ３４〜３６が繰り返される。
【００３８】
図４は、例示的な実施形態に係るメディアサーバ１を模式的に示す図である。メディアサーバは、クライアントユーザ機器に同時に配信可能なメディアストリームの最大数を決定するための決定部４１を有する。この決定はクライアントユーザ機器とのネゴシエーションにおいて実行され、例えば利用可能な帯域幅および／またはクライアントユーザ機器の能力に基づく。
【００３９】
さらに、メディアサーバはクライアントユーザ機器と通信するための通信部を有し、通信部はクライアントユーザ機器から定期的に要求を受信するための受信部４２を有している。この要求はクライアントユーザ機器が受信を希望するメディアストリームの表示を有しており、各メディアストリームはメディアストリームの重みを示すクライアント優先度に関連付けされている。受信部４２はまた、参加クライアントユーザ機器から符号化されたメディアストリームを受信するように構成されてもよい。しかし、メディアストリームは要求と別個に受信されるため、メディアストリームは（不図示の）別の受信部で受信することが好ましい。
【００４０】
さらに、メディアサーバは要求から、クライアントユーザ機器に送信するメディアストリームを選択するための選択部４３を有し、この選択は要求内に示されたクライアント優先度に基づくほか、送信されたメディアストリームの数が決定されたメディアストリームの最大数を超えてはならないという条件を考慮して行われる。上述の通信部はさらに、選択されたメディアストリームをクライアントユーザ機器に送信するための送信部４４を有する。
【００４１】
別の実施形態によれば、選択部はさらに、メディアストリームの特性、例えば信号強度に基づいてメディアサーバが実行し、メディア優先度として各メディアストリームに関連付けされたメディアストリームの重み付けに基づいてメディアストリームの選択を行うように構成される。
【００４２】
図５は、図４に示した実施形態の開示の代替方法であるメディアサーバの実施形態を模式的に示す図である。メディアサーバ１は１つまたは複数のユニットであってよい処理部５１を有する。さらに、メディアサーバ１は不揮発性メモリ、例えばＥＥＰＲＯＭ（電気的消去可能読み出し専用メモリ）、フラッシュメモリ（登録商標）、またはディスクドライブの形態を有する少なくとも１つのコンピュータプログラム製品５２を有している。コンピュータプログラム製品５２は、メディアサーバ１で実行された際、図２とともに上述した手続のステップをメディアサーバの処理部５１に実行させるコード手段を有するコンピュータプログラム５３を有している。
【００４３】
従って、図５に示す実施形態において、メディアサーバ１のコンピュータプログラム５３内のコード手段は決定モジュール５３ａ、受信モジュール５３ｂ、選択モジュール５３ｃ、および送信モジュール５３ｄを有している。モジュール５３ａ〜５３ｄは図４に記載したメディアサーバをエミュレートするため、図２のフローチャートにおけるステップを本質的に実行する。すなわち、異なるモジュール５３ａ〜５３ｄが処理部５１で実行される際、それらのモジュールは図４に付随する説明文とともに先に説明した図４の４１、４２、４３、および４４の各部に対応する。
【００４４】
図５とともに上述した実施形態におけるコード手段は、メディアサーバ上で実行された際に図２にとともに上述したステップをノードに実行させるコンピュータプログラムモジュールとして実装されているが、別の実施形態ではコード手段の１つ以上がその少なくとも一部をハードウェア回路として実装されてもよい。
【００４５】
図６は、例示的な実施形態に係るクライアントユーザ機器を模式的に示す図である。クライアントユーザ機器はメディア、例えばローカルユーザからの音声を符号化するための符号化部６１と、例えばメディアサーバ１から受信したメディアストリームとメディアストリームとは別個に受信したレンダリング情報とを用いて多者通話をレンダリングするためのレンダリング部６６とを有している。そのため、クライアントユーザ機器は、レンダリング用のメディアストリームをメディアサーバから受信するための第１の受信部６５を有している。また、このメディアストリームは、メディアサーバがクライアントユーザ機器から受信した要求から選択したものである。従って、クライアントユーザ機器は、メディアサーバへの要求を生成するための要求部６４をさらに有している。この要求は、クライアントユーザ機器が受信を希望するメディアストリームを示し、各メディアストリームはそのメディアストリームのためのクライアント優先度に関連付けられている。各ストリームに対するクライアント優先度は、例えばデータサーバ３から受信するような位置情報やアプリケーション固有情報だけでなく、エンドユーザによる選択にも基づくことができる。更新された要求は送信部６２によって定期的にメディアサーバに送信される。送信部６２はまた、符号化されたメディアをメディアサーバに送信するために用いられてもよい。しかし、メディアストリームは要求と別個に送信されるため、クライアントユーザ機器はメディアストリームを送信するための別個の送信部（不図示）を有することが好ましい。
【００４６】
さらなる例示的な実施形態によれば、クライアントユーザ機器は、例えば多者通話に参加している他のクライアントユーザ機器に関する地理的特性といったメタデータをメディアストリームとは別個にデータサーバから受信するための第２の受信部６３を有する。メタデータは要求を生成するため、また要求されるメディアストリームのクライアント優先度を決定するために要求部６４によって用いられるほか、メディアレンダリングを実行するためにレンダリング部６６にも用いられる。従って、データサーバから受信するメタデータは、要求情報としても、レンダリング情報としても用いられうる。
【００４７】
図７は、図６に示した実施形態の開示の代替方法であるクライアントユーザ機器２の実施形態を模式的に示す図である。クライアントユーザ機器２は１つまたは複数のユニットであってよい処理部７１を有する。さらに、クライアントユーザ機器２は不揮発性メモリ、例えばＥＥＰＲＯＭ（電気的消去可能読み出し専用メモリ）、フラッシュメモリ（登録商標）、またはディスクドライブの形態を有する少なくとも１つのコンピュータプログラム製品７２を有している。コンピュータプログラム製品７２は、クライアントユーザ機器２で実行された際、図３とともに上述した手続のステップを処理部７１に実行させるコード手段を有するコンピュータプログラム７３を有している。
【００４８】
従って、図７に示した実施形態において、クライアントユーザ機器２のコンピュータプログラム７３内のコード手段は符号化モジュール７３ａ、送信モジュール７３ｂ、第２の受信モジュール７３ｃ、要求モジュール７３ｄ、第１の受信モジュール７３ｅ、およびレンダリングモジュール７３ｆを有する。コード手段は、コンピュータプログラムモジュール内に構築されたコンピュータプログラムコードとして実装されてよい。モジュール７３ａ〜５ｆｄは図６に記載したクライアントユーザ機器２をエミュレートするため、図３のフローチャートにおけるステップを本質的に実行する。すなわち、異なるモジュール７３ａ〜７３ｆが処理部７１で実行される際、それらのモジュールは図６に付随する説明文とともに先に説明した図６の６１、６２、６３、６４、６５、および６６の各部に対応する。
【００４９】
図７とともに上述した実施形態におけるコード手段は、クライアントユーザ機器２上で実行された際に図３にとともに上述したステップをノードに実行させるコンピュータプログラムモジュールとして実装されているが、別の実施形態ではコード手段の１つ以上がその少なくとも一部をハードウェア回路として実装されてもよい。
【００５０】
従って、既に暗に述べたように、図４および図５に示したようなメディアサーバ１、および図６および図７に示したようなクライアントユーザ機器２は、ソフトウェア機能を、プログラムされたマイクロプロセッサまたは汎用コンピュータとともに用いたり、および／または特定用途向け集積回路(ASIC)を用いたりする物理または論理エンティティによって実施されてよい。それらは適切な内部および外部記憶装置のみならず、必要な変調、符号化、フィルタ処理などを実施するだけでなく、それらの信号を適切に処理するために復調および復号する能力を有するハードウェアおよびソフトウェアを含んだ適切な通信インタフェースを有してよい。
【００５１】
上述した実施形態は単なる例とした与えられるものであり、本発明を限定するものではない。添付の特許請求の範囲に請求された発明の範囲内に含まれる他の方法、利用、目的、および機能は本技術分野に属する当業者にとって明らかであろう。
【図１】
2015216646.tif 000003
【図２】
2015216646.tif 000004
【図３】
2015216646.tif 000005
【図４】
2015216646.tif 000006
【図５】
2015216646.tif 000007
【図６】
2015216646.tif 000008
【図７】
2015216646.tif 000009
【手続補正書】
【提出日】平成27年7月15日(2015.7.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
多者通話から受信するメディアストリームをローカル音声又は映像メディアレンダリングのために参加クライアントユーザ機器へ配信する、電気通信ネットワークにおけるメディアサーバ(1)のための方法であって、
同時に配信すべきメディアストリームの最大数を、前記クライアントユーザ機器とのネゴシエーションに基づいて決定するステップ(25)と、
前記クライアントユーザ機器から、各メディアストリームについてのクライアント優先度を示す、更新されたメディアストリーム要求を定期的に受信するステップ(26)と、
前記要求されたメディアストリームの前記クライアント優先度と、選択されたメディアストリームの数が前記決定されたメディアストリームの最大数を超えてはならないという条件とに基づいて、前記要求からメディアストリームを選択するステップ(27)と、
前記選択されたメディアストリームを前記多者通話のローカルレンダリングのために前記クライアントユーザ機器に送信するステップ(28)と、を有することを特徴とする方法。
【外国語明細書】
2015216646000001.pdf