JPWO2022211786A5 - - Google Patents

Description

本発明は、情報通信技術に関し、特に、データ通信システム及びデータ通信方法に関するものである。

ユーザ同士のオンライン通信を可能にするための技術が知られている。ユーザがインターネット経由でデータを送信および受信するためには、通信プロトコルが必要である。通信技術の目覚ましい発展に伴い、ビデオ通話やライブストリーミングなどのリアルタイム通信に対する需要が高まっている。

リアルタイム通信のための通信プロトコルは多数存在する。異なる通信プロトコルでは、メリットもデメリットもすべて異なる。低遅延でリアルタイムのやりとりに適した通信プロトコルもあれば、円滑なストリーミングを保証する通信プロトコルもある。

異なるシナリオに応じて、異なる通信プロトコルが要求される。例えば、インタラクティブゲームなど、リアルタイムのインタラクションを所望するユーザには、低遅延の通信プロトコルが必要である。通信プロトコルが適切でないと、ユーザの不満の原因になる可能性がある。そのため、様々なシナリオに対応した適切な通信プロトコルで通信を行うことは、非常に重要な課題である。

本発明の目的は、データ通信システム及びデータ通信方法を提供することにある。

本発明の実施形態は、データ通信システムに関し、当該データ通信システムは、ユーザからの操作に基づいてユーザ端末によって実行される動作を、前記ユーザ端末から受信するように構成された受信ユニットと、当該受信ユニットに接続され、当該動作により要求される指標に基づき、当該ユーザ端末への通信プロトコルを決定するように構成された決定ユニットと、を含み、当該通信プロトコルが当該ユーザ端末に導かれ、当該ユーザ端末が当該通信プロトコルを介してリアルタイムデータを要求する。

本発明の実施形態は、データ通信方法に関し、当該データ通信方法が、ユーザからの操作に基づいてユーザ端末によって実行された動作を、前記ユーザ端末から受信する工程と、当該動作により要求される指標に基づき、当該ユーザ端末への通信プロトコルを決定する工程を含み、当該通信プロトコルが当該ユーザ端末に導かれ、当該ユーザ端末が当該通信プロトコルを介してリアルタイムデータを要求する。

本発明は当該ユーザ端末がシナリオに応じて異なる動作をする際に、異なる通信プロトコルに切り替える。したがって、ユーザがライブストリーミングを視聴する際の満足度を高め、ユーザエクスペリエンスを最適化することもできる。

本発明の一部の実施態様に基づく通信システム１の構成を示す概略図である。 本発明の一部の実施態様に基づくデータ通信システム１００のブロック図である。 動作Ａの例示的な機能構成図である。 動作Ａの例示的な機能構成図である。 動作Ａの例示的な機能構成図である。 動作Ａの例示的な機能構成図である。 動作Ａの例示的な機能構成図である。 通信システム１とデータ通信システム１００の処理を示す例示的なシーケンス図である。

図１に本発明の一部の実施態様に基づく通信システム１の構成を示す概略図を示す。当該通信システム１は、コンテンツを介したインタラクションを伴うライブストリーミングサービスを提供する。ここで言う「コンテンツ」とは、コンピュータ装置で再生可能なデジタルコンテンツを指す。つまり、通信システム１は、ユーザがオンラインで他のユーザとのリアルタイムのインタラクションを行うことを可能にする。当該通信システム１は、複数のユーザ端末１０と、インタラクションサーバ３０と、ストリーミングサーバ４０を含む。当該ユーザ端末１０、当該インタラクションサーバ３０、及び当該ストリーミングサーバ４０は、ネットワーク９０、例えばインターネットを介して接続される。当該インタラクションサーバ３０は、インタラクションのフィードバックを同期するためのサーバである。一部の実施態様において、当該インタラクションサーバ３０は、アプリのバックエンドサーバとしてもよい。当該ストリーミングサーバ４０は、ライブストリーミングを提供するためのサーバである。一部の実施態様において、当該ストリーミングサーバ４０は、ＣＤＮ（コンテンツデリバリネットワーク）プロバイダとしてもよい。一部の実施態様において、当該インタラクションサーバ３０と当該ストリーミングサーバ４０は、１つのサーバに統合してもよい。当該ユーザ端末１０は、ライブストリーミングのためのクライアント装置である。一部の実施態様において、当該ユーザ端末１０は、視聴者、ストリーマ（配信者）、ポッドキャスタ、観衆、リスナなどと呼ばれることがある。当該各ユーザ端末１０、当該インタラクションサーバ３０、及び当該ストリーミングサーバ４０はそれぞれ情報処理装置の一例である。

図２に本発明の一部の実施態様に基づくデータ通信システム１００のブロック図を示す。当該データ通信システム１００は、受信ユニット１１０と、決定ユニット１２０と、転送ユニット１３０を含む。当該受信ユニット１１０は、ユーザ端末１０によって実行される動作Ａを受信するように構成される。一部の実施態様において、当該受信ユニット１１０は、ストレージ要素を含んでもよい。当該ストレージ要素は、当該ユーザ端末１０から収集された当該動作Ａを保存するように構成される。当該決定ユニット１２０は、当該受信ユニット１１０に接続され、当該動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定するように構成される。当該転送ユニット１３０は、当該決定ユニット１２０に接続され、当該通信プロトコルＰを当該インタラクションサーバ３０および（または）当該ストリーミングサーバ４０に導くように構成される。一部の実施態様において、当該インタラクションサーバ３０および（または）当該ストリーミングサーバ４０は、当該動作Ａに基づき、当該ユーザ端末１０に対して当該通信プロトコルＰを介してリアルタイムデータを受信および（または）送信することができる。

図２に示すように、当該ユーザ端末１０は動作Ａを実行し、当該受信ユニット１１０が当該ユーザ端末１０により実行された当該動作Ａを受信する。一部の実施態様において、当該動作Ａは、サーバからのおよび（または）サーバへのリアルタイムデータの受信および（または）送信を要求することを含んでもよい。その後、当該受信ユニット１１０は、当該動作Ａを当該決定ユニット１２０に送信し、当該決定ユニット１２０が当該動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定する。続いて、当該転送ユニット１３０は当該決定ユニット１２０により決定された当該通信プロトコルＰを受信し、当該通信プロトコルＰを当該インタラクションサーバ３０に導く。その後、当該インタラクションサーバ３０は当該ユーザ端末１０が当該ストリーミングデータを要求するための当該通信プロトコルＰを当該ユーザ端末１０に送信する。一部の実施態様において、当該データ通信システム１００は、当該インタラクションサーバ３０に統合してもよい。より具体的には、当該受信ユニット１１０、当該決定ユニット１２０、当該転送ユニット１３０を当該インタラクションサーバ３０に統合することができる。当該インタラクションサーバ３０は、当該ユーザ端末１０により実行された当該動作Ａを保存するためのストレージを含んでもよい。一部の実施態様において、当該ストレージは、当該ユーザ端末１０により実行された過去の動作Ａを保存するように構成してもよい。当該インタラクションサーバ３０に初めてアクセスする当該ユーザ端末１０に対して、当該決定ユニット１２０は、過去の動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定することができる。当該インタラクションサーバ３０に特定の時間に関与する当該ユーザ端末１０に対して、当該決定ユニット１２０は、リアルタイムの動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定することができる。

当該動作Ａとは、当該ユーザ端末１０がアプリ内で実行する処理とすることができる。当該動作Ａは、クリック、送信、交流、スワイプ、消音、ミュート、展開、最小化など、当該ユーザ端末１０が実行し得る処理、およびそれらの組み合わせを含むことができる。一部の実施態様において、当該動作Ａは、ボタンなどのグラフィカルオブジェクトをクリックすることによって、または音声入力などによって達成されてもよい。例えば、当該ユーザ端末１０は、贈り物をクリックしてストリーマに贈り物を送信することができる。当該ユーザ端末１０は、他のアプリや他のライブストリーミングを同時利用（マルチタスク）しながら、ライブ配信画面を最小化したり、 ピクチャーインピクチャー（ＰｉＰ）モードでライブ配信ルームを表示したりすることができる。当該ユーザ端末１０は、静かな場所でライブストリーミングを視聴しながら、そのライブ配信を消音またはミュートすることができる。当該ユーザ端末１０は、ボタンをクリックしたり、視聴者またはストリーマと音声および（または）ビデオで通信したりすることができる。当該ユーザ端末１０は、アプリ内で視聴者またはストリーマとインタラクティブゲームをプレイすることができる。

リアルタイムデータ通信には、例えばＨＬＳ、ＲＴＰ（ＷｅｂＲＴＣ）、ＲＴＭＰ、ＲＴＳＰ、ＤＡＳＨ、ＭｉｒｒｏｒＯＰなど、多数の通信プロトコルがあり、各通信プロトコルＰは、リアルタイムデータ通信に関してそれぞれメリットとデメリットを有する。本発明においては、ＨＬＳ、ＲＴＣ（ＷｅｂＲＴＣ）、ＲＴＭＰの当該通信プロトコルを例として論じる。表１に、当該通信プロトコルＰの例と、それぞれのメリットおよびデメリットを参考として示す。

リアルタイムのインタラクションに関しては、ビデオ遅延が考慮すべき最も重要な指標の１つであり得る。ここで、「ビデオ遅延」という指標は、一方のユーザ端末からストリーミングデータが導かれ、他方のユーザ端末でストリーミングデータの最初のフレームがレンダリングされるまでの遅延の度合いを指すものとすることができる。ＷｅｂＲＴＣは遅延が０.５秒以下で、ほぼリアルタイムであるため、リアルタイムのインタラクションにはＷｅｂＲＴＣが強く推奨される。同様に、ＲＴＭＰの遅延は５～８秒であることが多いため、ＲＴＭＰもリアルタイムのデータ通信に推奨される。しかし、ＨＬＳはＷｅｂＲＴＣやＲＴＭＰに比べて相対的に遅延が大きいため、リアルタイムのインタラクションには推奨されない。

ライブストリーミングの滑らかさに関しては、バッファリングの低さが考慮すべき重要な指標となり得る。「バッファリング」という指標は、さらに「バッファリング率」と「バッファリング数」に分類されることがある。「バッファリング率」とは、全視聴時間に対するバッファリング時間の比率を指す。「バッファリング回数」という指標は、バッファリングが発生した回数を指す。ＨＬＳ（ＨＴＴＰＬｉｖｅ Ｓｔｒｅａｍｉｎｇ）とは、ＨＴＴＰベースのアダプティブビットレートストリーミング通信プロトコルである。ＨＬＳは、各視聴者が利用可能なインターネット速度を測定し、それに応じて品質を変化させ、ストリーミングデータの滑らかさを確保するものである。したがって、ライブストリーミングの滑らかな配信にはＨＬＳが推奨される。

ＲＴＭＰは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）をベースとした通信プロトコルであり、所定のシーケンスと順序でデータ通信を行い、配信を保証することができる。ＲＴＭＰのメリットとしては、ＷｅｂＲＴＣやＨＬＳと比較して、最初のレンダリングに要する時間が比較的短いことがあげられる。ここで、「最初のレンダリング」という指標は、「表示までの時間」とも呼ばれることがあり、ストリーミングデータを要求してから、そのストリーミングデータの最初のフレームがレンダリングされるまでの時間を指す。したがって、ＲＴＭＰは当該動作Ａが最初のレンダリングまでの時間が短いことを要求する場合に推奨される。

一部の実施態様において、当該リアルタイムデータは、ストリーミングデータとインタラクションデータを含んでもよい。当該ストリーミングデータは、オーディオコンテンツおよび（または）ビデオコンテンツを指す。当該オーディオコンテンツとビデオコンテンツは、当該ユーザ端末１０のマイクやカメラから収集されてもよい。当該インタラクションデータは、当該ユーザ端末１０とのインタラクションを示すデータを指す。例えば、当該インタラクションデータは、当該ユーザ端末１０が他のユーザ端末１０と交流するために実行する処理を指してもよい。例えば、当該ユーザ端末１０は、贈り物をクリックしてストリーマに贈り物を送信することができる。当該ユーザ端末１０は、Ｅｎｔｅｒボタンをクリックしてストリーマにメッセージを送信することができる。当該ユーザ端末１０は、ゲームボタンをクリックしてストリーマとインタラクティブゲームをすることができる。

図３から図７は当該動作Ａの例示的な機能構成図である。図３から図７に、当該ユーザ端末１０、当該インタラクションサーバ３０、当該ストリーミングサーバ４０が示されている。当該インタラクションサーバ３０は、インタラクションデータの送信および受信を行い、当該ストリーミングサーバ４０は、ストリーミングデータの送信および受信を行う。当該ユーザ端末１０は、インタラクションユニット１１と、デコーダー１２と、ディスプレイ１３と、ストリーミング入力１４と、エンコーダー１５を含む。当該インタラクションユニット１１は、当該インタラクションサーバ３０からインタラクションデータを受信および（または）当該インタラクションサーバ３０へインタラクションデータを送信する。当該デコーダー１２は、当該ストリーミングサーバ４０からの当該ストリーミングデータをデコードし、当該ディスプレイ１３が当該ストリーミングデータを表示する。当該ストリーミング入力１４は、ユーザ端末１０からストリーミングデータを収集する。当該エンコーダー１５は、当該ストリーミング入力１４から収集されたストリーミングデータをエンコードし、当該ストリーミングデータを当該ストリーミングサーバ４０に送信する。一部の実施態様において、当該ストリーミング入力１４は、当該ユーザ端末１０からオーディオコンテンツとビデオコンテンツを収集するためのマイクやカメラとすることができる。

一部の実施態様において、当該動作Ａはさらに、インタラクション動作Ａｉと、非インタラクション動作Ａｎｉを含むことができる。当該決定ユニット１２０は、当該インタラクション動作Ａｉと当該非インタラクション動作Ａｎｉに基づき、当該ユーザ端末１０への当該通信プロトコルＰを決定することができる。

一部の実施態様において、当該インタラクション動作Ａｉとは、インタラクションデータを送信および（または）受信する動作Ａを指してもよい。例えば、当該ユーザ端末１０において贈り物ボタンをクリックしてストリーマに贈り物を送る場合、当該ユーザ端末１０は当該ストリーマにインタラクションデータを送信する。この場合、贈り物を送るための当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。当該ユーザ端末１０においてゲームボタンをクリックして、当該ストリーマとインタラクティブゲーム（モンスターを一緒に射撃するなど）をする場合、当該ユーザ端末１０は当該ストリーマにインタラクションデータを送信し、当該ストリーマからインタラクションデータを受信する。この場合、インタラクティブゲームをする当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。

一部の実施態様において、当該インタラクション動作Ａｉは、ストリーミングデータを送信および受信する動作を指すこともできる。例えば、視聴者が音声通話ボタンまたはビデオ通話ボタンをクリックして、ストリーマを音声チャットまたはビデオチャットに招待することができる。この場合、当該ストリーマを音声チャットまたはビデオチャットに招待する当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。

当該非インタラクション動作Ａｎｉとは、ストリーミングデータを送信することなく受信する、またはストリーミングデータを受信することなく送信する動作Ａを指してもよい。例えば、当該ユーザ端末１０が何もせずにストリーマを視聴する場合、当該ユーザ端末１０はストリーミングデータまたはインタラクションデータを当該ストリーマに送信することなく、当該ストリーマからストリーミングデータを受信する。この場合、当該ストリーマを視聴する当該動作Ａは、非インタラクション動作Ａｎｉと呼ぶことができる。当該ユーザ端末１０が他のユーザ端末１０と交流することなく、ライブブロードキャストを行う場合、当該ユーザ端末１０はいかなるストリーミングデータまたはインタラクションデータも受信することなく、ストリーミングデータを送信する。この場合、ライブブロードキャストを行う当該動作Ａは、非インタラクション動作Ａｎｉと呼ぶことができる。

図３に、当該非インタラクション動作Ａｎｉの例示的な機能構成図を示す。一部の実施態様において、当該ユーザ端末１０は、視聴者、リスナ、観衆などと呼ばれることがある。当該ユーザ端末１０は、当該ストリーミングサーバ４０からのストリーミングデータの受信を要求する。当該ストリーミングデータは、ストリーマからのオーディオコンテンツとビデオコンテンツを含むことができる。図３に示すように、当該ユーザ端末１０は当該ストリーミングサーバ４０からストリーミングデータを受信し、当該デコーダー１２が当該ストリーミングデータをデコードして、当該ストリーミングデータをディスプレイ１３に表示する。

当該動作Ａに基づき、当該ユーザ端末１０はストリーミングデータの受信を要求し、それにより当該ユーザ端末１０がストリーマを視聴したいことを示す。従って、当該動作Ａは、非インタラクション動作Ａｎｉと呼ぶことができる。当該非インタラクション動作Ａｎｉへの応答では、当該ストリーミングデータのバッファリングと最初のレンダリングがユーザ満足度を満たすための第一優先事項となる。従って、当該決定ユニット１２０は、当該動作Ａに基づく当該ユーザ端末１０への当該通信プロトコルＰをＨＬＳまたはＲＴＭＰに決定することができる。一部の実施態様において、当該ユーザ端末１０がストリーマをクリックし、ストリーミングルームに入るとき、最初のレンダリングが短いことが好ましい。従って、当該通信プロトコルＰはＲＴＭＰが推奨される。一部の実施態様において、当該ストリーミングルームに入った後は、低バッファリングが好ましい。従って、当該通信プロトコルＰはＨＬＳが推奨される。

一部の実施態様において、当該決定ユニット１２０はさらに、当該ユーザ端末１０のインターネット品質に基づき、当該ユーザ端末１０に向けて当該通信プロトコルＰを決定する。例えば、当該ユーザ端末１０のインターネット品質が良好な場合、当該通信プロトコルＰはＲＴＭＰが推奨される。一方で、当該ユーザ端末１０のインターネット品質が劣悪な場合、当該通信プロトコルＰはＨＬＳが推奨される。一部の実施態様において、当該インターネット品質の良し悪しは、遅延、バッファリング、最初のレンダリング等の指標に基づき評価される。例えば、バッファリングが高い場合、当該ユーザ端末のインターネット品質が劣悪であることを示す。一方で、バッファリングが低い場合、当該ユーザ端末のインターネット品質が良好であることを示す。当該決定ユニット１２０はさらに、当該ユーザ端末１０のインターネット品質に基づき、当該通信プロトコルＰを決定することができる。

一部の実施態様において、当該ストリーミングデータはオーディオコンテンツのみとしてもよい。当該決定ユニット１２０は、オーディオコンテンツのみの当該ストリーミングデータを受信する当該ユーザ端末１０への当該通信プロトコルＰを決定することができる。例えば、当該ユーザ端末１０は、ライブ配信を最小化してストリーマの音声のみを聴くことができ、あるいは当該ユーザ端末１０はポッドキャスタをクリックしてライブポッドキャストを聴くこともできる。オーディオコンテンツのみのストリーミングデータをプルする当該動作Ａに応答して、当該通信プロトコルＰは、例えばＲＴＭＰが推奨される。このため、当該決定ユニット１２０はＲＴＭＰを当該ユーザ端末１０への当該通信プロトコルＰに決定する。ＲＴＭＰの当該通信プロトコルＰは、オーディオコンテンツのみでストリーミングデータをプルしてネットワークトラフィックを低下させ、オーディオコンテンツを滑らかに再生することができる。

一部の実施態様において、当該ストリーミングデータはビデオコンテンツのみとしてもよい。当該決定ユニット１２０は、ビデオコンテンツのみの当該ストリーミングデータを受信する当該ユーザ端末１０への当該通信プロトコルＰを決定することができる。例えば、当該ユーザ端末１０は、当該ユーザ端末１０が図書館などの静かな場所にあるとき、ライブ配信を消音またはミュートして、ストリーマのビデオのみを見ることができる。ビデオコンテンツのみのストリーミングデータをプルする当該動作Ａに応答して、当該通信プロトコルＰはＲＴＭＰとＨＬＳが推奨される。このため、当該決定ユニット１２０はＲＴＭＰまたはＨＬＳなどを当該ユーザ端末１０への当該通信プロトコルＰに決定する。

一部の実施態様において、当該ユーザ端末１０は、異なるユーザ端末１０から短時間に連続的にストリーミングデータを受信する動作Ａを実行することができる。ここで、「短時間」とは、当該ユーザ端末１０が最初のストリーマからストリーミングデータを受信し、当該最初のストリーマからの当該ストリーミングデータが視聴用のディスプレイ上にレンダリングされると、第２のストリーマから別のストリーミングデータを受信するまでの時間を指す。当該決定ユニット１２０は、当該動作Ａに基づき当該通信プロトコルＰを決定することができる。例えば、当該ユーザ端末１０は、ライブストリーミングルームをスワイプして、当該ユーザ端末１０が関心を持つストリーマがいないかすばやくチェックすることができる。つまり、当該ユーザ端末１０は、異なるユーザ端末１０からのストリーミングデータの受信を、例えば各要求につき１～３秒というように、 迅速に要求する。この場合、異なるストリーマをできるだけ早くチェックするためには、映像の最初のレンダリングまでの時間の長さが短いほうが良いことになる。当該動作Ａへの応答において、当該通信プロトコルＰは、ＲＴＭＰを推奨することができる。このため、当該決定ユニット１２０はＲＴＭＰを当該ユーザ端末１０への当該通信プロトコルＰに決定することができる。

一部の実施態様において、当該ユーザ端末１０は、異なるストリーマから同時にストリーミングデータを受信する動作Ａを実行することができる。当該決定ユニット１２０は、当該動作Ａに基づき、各ストリーマからの各ストリーミングデータについて、ユーザ端末１０への異なる通信プロトコルＰを決定することができる。例えば、当該ユーザ端末１０は、異なるストリーマを異なるウィンドウで同時に視聴することができる。つまり、当該ユーザ端末１０は、異なるユーザ端末１０からストリーミングデータを同時に受信するように要求する。この場合、各ストリーミングデータが異なる通信プロトコルＰを推奨する。例えば、当該ユーザ端末１０はたくさんのストリーマを同時に視聴することができる。当該ユーザ端末１０は、他の配信を交流なしでブロードキャストしておきながら、お気に入りのストリーマと交流する。この場合、お気に入りのストリーマとのリアルタイムでの交流を最優先とし、それ以外のストリーマのストリーミングは、映像の滑らかさを重視することを推奨することができる。従って、当該ユーザ端末１０がストリーマと交流するための当該通信プロトコルＰには、ＷｅｂＲＴＣを推奨することができる。残りのライブストリーミングを滑らかにブロードキャストするための当該通信プロトコルＰには、低解像度ストリーミングデータのＨＬＳが推奨される。

図４に、当該非インタラクション動作Ａｎｉの別の例示的な機能構成図を示す。一部の実施態様において、当該ユーザ端末１０は、ストリーマ、ポッドキャスタなどと呼ぶことができる。当該ユーザ端末１０は、ストリーミングデータを当該ストリーミングサーバ４０に送信することを要求する。当該ストリーミングデータは、当該ユーザ端末１０からのオーディオコンテンツとビデオコンテンツを含むことができる。図４に示すように、当該ユーザ端末１０は、マイクやカメラなどの当該ストリーミング入力１４からストリーミングデータを収集し、当該エンコーダー１５が当該ストリーミングデータをエンコードして当該ストリーミングデータを当該ストリーミングサーバ４０に送信する。

一部の実施態様において、当該ストリーミングデータは、オーディオコンテンツおよび（または）ビデオコンテンツを含んでもよい。当該決定ユニット１２０は、オーディオコンテンツおよび（または）ビデオコンテンツを備えたストリーミングデータを送信するための当該ユーザ端末１０への当該通信プロトコルＰを決定することができる。例えば、当該ストリーマはビデオ、ショートビデオ、ライブ配信、ポッドキャスティングなどを送信することができる。上述の当該動作Ａに応答して、当該決定ユニット１２０は、当該ユーザ端末１０への通信プロトコルＰを決定することができる。

図５に、当該インタラクション動作Ａｉの例示的な機能構成図を示す。一部の実施態様において、当該ユーザ端末１０は、視聴者、ストリーマ、観衆、リスナ、ポッドキャスタなどと呼ばれることがある。当該ユーザ端末１０は、ストリーミングデータを当該ストリーミングサーバ４０に送信することと、ストリーミングデータを当該ストリーミングサーバ４０から受信することを要求する。図５に示すように、当該ユーザ端末１０は当該ストリーミングサーバ４０からストリーミングデータを受信し、当該デコーダー１２が当該ストリーミングデータをデコードして、当該ストリーミングデータをディスプレイ１３に表示する。同時に、当該ユーザ端末１０が当該ストリーミング入力１４からのストリーミングデータを収集し、当該エンコーダー１５が当該ストリーミングデータをエンコードして、当該ストリーミングデータを当該ストリーミングサーバ４０に送信する。同様に、当該ストリーミングデータは、オーディオコンテンツおよび（または）ビデオコンテンツを含むことができる。例えば、視聴者が音声通話ボタンまたはビデオ通話ボタンをクリックして、ストリーマを音声チャットまたはビデオチャットに招待することができる。当該ストリーマはボタンをクリックして音声チャットまたはビデオチャットを受け入れることができる。音声チャットまたはビデオチャットの招待または受け入れの当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。従って、当該通信プロトコルＰは、例えば、ＷｅｂＲＴＣが推奨される。

図６に、当該インタラクション動作Ａｉの別の例示的な機能構成図を示す。一部の実施態様において、当該ユーザ端末１０は、視聴者、ストリーマ、観衆、リスナ、ポッドキャスタなどと呼ばれることもある。当該ユーザ端末１０は、当該ストリーミングサーバ４０からストリーミングデータを受信し、当該インタラクションサーバ３０にインタラクションデータを送信することを要求する。図６に示すように、当該ユーザ端末１０は当該ストリーミングサーバ４０からストリーミングデータを受信し、当該デコーダー１２が当該ストリーミングデータをデコードして、当該ストリーミングデータをディスプレイ１３に表示する。同時に、当該ユーザ端末１０は当該インタラクションサーバ３０にインタラクションデータを送信する。例えば、視聴者はストリーマやポッドキャスタを見ながら、または聴きながら、贈り物ボタンをクリックして当該ストリーマに贈り物を送信することができる。インタラクションデータをトリガーとして、ストリーマの画面に動態ステッカーを表示し、当該ストリーマが当該ユーザ端末１０からのイ当該ンタラクションデータに応答して音声やジェスチャーで感謝の気持ちを表現してもよい。従って、当該通信プロトコルＰは、例えば、ＷｅｂＲＴＣが推奨される。

図７に、当該インタラクション動作Ａｉの別の例示的な機能構成図を示す。一部の実施態様において、当該ユーザ端末１０は、視聴者、ストリーマ、観衆、リスナ、ポッドキャスタなどと呼ばれることもある。当該ユーザ端末１０は、インタラクションデータを当該インタラクションサーバに送信することと、インタラクションデータを当該インタラクションサーバ３０から受信することを要求する。一部の実施態様において、当該ユーザ端末１０はさらに、ストリーミングデータを当該ストリーミングサーバ４０に送信し、ストリーミングデータを当該ストリーミングサーバ４０から受信することができる。図７に示すように、当該ユーザ端末１０は、当該インタラクションサーバ３０との間でインタラクションデータを同時に送信および受信する。当該ユーザ端末１０はさらに、当該ストリーミングサーバ４０との間でストリーミングデータを同時に受信および（または）送信することができる。例えば、視聴者はインタラクションボタンをクリックしてストリーマとインタラクティブゲームをすることができる。従って、当該通信プロトコルＰは、例えば、ＷｅｂＲＴＣが推奨される。

図８に通信システム１とデータ通信システム１００の処理を示す例示的なシーケンス図を示す。工程Ｓ１０１において、ストリーマなどの当該ユーザ端末１０’による指示に応答して、当該ユーザ端末１０’（図示しない）内のクライアントアプリケーションアプリが、当該ストリーミングサーバ４０にライブストリーミングデータをアップロードする。ここで、当該ライブ配信は、マイクおよび（または）カメラから収集されたストリーミングデータを含む。多くの場合、当該ストリーミングデータは、当該ストリーマのオーディオコンテンツとビデオコンテンツを含む。

工程Ｓ１０２において、当該ユーザ端末１０内のクライアントアプリケーションアプリがアプリ内またはプラットフォーム内で動作Ａを実行する。一部の実施態様において、当該動作Ａは、アプリにログインしてライブストリーミングを視聴するためにストリーマをクリックする動作とすることができる。工程Ｓ１０３において、当該ユーザ端末１０が、当該動作Ａに応答して、当該インタラクションサーバ３０にライブストリーミングデータ情報の要求を送信する。工程Ｓ１０４において、当該受信ユニット１１０が、当該ユーザ端末１０により実行された当該動作Ａを受信する。一部の実施態様において、当該受信ユニット１１０はストレージ要素に当該動作Ａを保存する。工程Ｓ１０５において、当該受信ユニット１１０は当該ユーザ端末１０により実行された当該動作Ａを当該決定ユニット１２０に送信する。工程Ｓ１０６において、当該決定ユニット１２０は、当該動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定する。工程Ｓ１０７において、当該決定ユニット１２０は、当該インタラクションサーバ３０に当該通信プロトコルＰを送信する。工程Ｓ１０８において、当該インタラクションサーバ３０は当該ユーザ端末１０に当該通信プロトコルＰを送信する。工程Ｓ１０９において、当該ユーザ端末１０は、当該通信プロトコルＰを介して、ストリーミングデータを要求する。工程Ｓ１１０において、当該ストリーミングサーバ４０は、当該ユーザ端末１０からの当該要求に応答し、当該通信プロトコルＰを介して当該ストリーミングデータを送信する。

一部の実施態様において、当該受信ユニット１１０、当該決定ユニット１２０、当該転送ユニット１３０は、１つのサーバに統合されてもよい。一部の実施態様において、当該受信ユニット１１０、当該決定ユニット１２０、当該転送ユニット１３０を当該インタラクションサーバ３０に統合することができる。一部の実施態様において、当該受信ユニット１１０と当該転送ユニット１３０は、当該インタラクションサーバ３０の受信手段と送信手段で置換されてもよい。

一部の実施態様において、当該ユーザ端末１０が工程Ｓ１０２において実行する当該動作Ａは、インタラクション動作Ａｉとすることができる。より具体的に、工程Ｓ１０２において、当該ユーザ端末１０は、動作Ａを実行することができる。例えば、当該動作Ａは、ストリーマを視聴し、贈り物ボタンをクリックして当該ストリーマに贈り物を送ることを含むことができる。工程Ｓ１０３において、当該ユーザ端末１０が、当該動作Ａに応答して、当該インタラクションサーバ３０にインタラクションデータを送信することと、当該ストリーミングサーバ４０からストリーミングデータを受信することを要求する。工程Ｓ１０４において、当該受信ユニット１１０が、当該ユーザ端末１０により実行された当該動作Ａを受信する。工程Ｓ１０５において、当該受信ユニット１１０は当該ユーザ端末１０により実行された当該動作Ａを当該決定ユニット１２０に送信する。工程Ｓ１０６において、当該決定ユニット１２０は、当該動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定する。より具体的に、当該ユーザ端末１０は、当該動作Ａに基づき、インタラクションデータの送信とストリーミングデータの受信を要求し、それにより当該ユーザ端末１０が当該ストリーマを視聴し、贈り物を送ることにより当該ストリーマと交流したいことを示す。従って、当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。当該インタラクション動作Ａｉへの応答では、リアルタイムのインタラクションがユーザ満足度を満たすための第一優先事項となる。従って、当該決定ユニット１２０は、当該動作Ａに基づく当該ユーザ端末１０への当該通信プロトコルＰをＷｅｂＲＴＣまたはＲＴＭＰに決定する。

一部の実施態様において、当該動作Ａは、ストリーマを視聴し、インタラクションゲームボタンをクリックして当該ストリーマとインタラクティブゲームをすることを含むことができる。工程Ｓ１０３において、当該ユーザ端末１０が、当該動作Ａに応答して、当該インタラクションサーバ３０にインタラクションデータを送信することと、当該インタラクションサーバ３０からインタラクションデータを受信することを要求する。工程Ｓ１０６において、当該決定ユニット１２０は、当該動作Ａに基づき、当該ユーザ端末１０への通信プロトコルＰを決定する。当該動作Ａに基づき、当該ユーザ端末１０はインタラクションデータの送信および受信を要求し、それにより当該ユーザ端末１０がインタラクティブゲーム（モンスターを一緒に射撃するなど）をプレイすることで当該ストリーマと交流したいことを示す。従って、当該動作Ａは、インタラクション動作Ａｉと呼ぶことができる。当該動作Ａへの応答では、リアルタイムのインタラクション、特に低遅延であることがユーザ満足度を満たすための第一優先事項となる。このため、当該決定ユニット１２０はＷｅｂＲＴＣなどを当該ユーザ端末１０への当該通信プロトコルＰに決定する。

一部の実施態様において、当該決定ユニットはさらに予測要素を含むことができる。当該予測要素は、当該動作Ａに基づき、後続の動作Ａを予測するように構成される。当該予測要素は、当該動作Ａを分析して関連動作を特定し、当該関連動作に基づいて当該後続の動作Ａを予測する。例えば、当該ユーザ端末１０が入力ボックスをクリックすると、それは当該ユーザ端末１０がストリーマとチャットを開始したいことを示唆する。当該ユーザ端末１０が贈り物ボックスをクリックすると、ユーザ端末１０がストリーマに贈り物を送ろうとしていると予測することができる。一部の実施態様において、当該予測要素はさらに、当該ユーザ端末１０が残したメッセージを分析し、当該メッセージに基づいて当該後続の動作Ａを予測することができる。当該ユーザ端末１０が残すメッセージには、テキスト、音声、絵文字などが含まれてもよい。例えば、当該ユーザ端末１０がテキストを入力し、ストリーマにインタラクティブゲームをするかを尋ねることができ、これにより当該ユーザ端末１０が当該ストリーマとインタラクティブゲームをすることを予測することができる。当該ユーザ端末１０からのインタラクティブゲームの要求に応答し、当該ストリーマが例えばマイクを介した音声メッセージでOKと応答した場合、これは当該ユーザ端末１０と当該ストリーマがインタラクティブゲームをすることを示唆することができる。このため、当該予測要素は、当該ユーザ端末１０が残したメッセージと当該ストリーマが話した音声メッセージを分析して、当該ユーザ端末１０が当該ストリーマとインタラクティブゲームをすることを予測することができる。一部の実施態様において、当該決定ユニット１２０はさらに、当該後続の動作Ａに基づいて、当該通信プロトコルＰを決定することができる。

一部の実施態様において、当該予測要素は当該ユーザ端末１０から複数の履歴データを収集することができる。当該履歴データは、当該ユーザ端末１０からの過去の動作Ａと過去の後続の動作Ａを含むことができる。当該予測要素は、当該過去の動作Ａと過去の後続の動作Ａに基づき、当該後続の動作Ａを予測することができる。例えば、当該ユーザ端末１０は、ストリーマのライブ配信に入った後、特定のストリーマとビデオ・音声チャットを行うことが習慣となっているため、当該ユーザ端末１０が当該ストリーマのルームに入ると、当該ストリーマとビデオ・音声チャットを行う可能性があると予測することができる。

一部の実施態様において、当該受信ユニット１１０はさらに、当該ユーザ端末１０から利用可能な通信プロトコルを受信する。当該利用可能な通信プロトコルとは、当該ユーザ端末１０と当該サーバ３０／４０に相互に適用可能な当該通信プロトコルＰを指す。一部の実施態様において、当該決定ユニット１２０は、当該利用可能な通信プロトコルから当該通信プロトコルＰを選択することができ、さらに当該動作Ａに基づいて、当該通信プロトコルＰを決定する。

一部の実施態様において、当該データ通信システム１００は、さらにフィードバック収集ユニットを含むことができる。当該フィードバック収集ユニットは、当該ユーザ端末１０からフィードバックを収集し、当該フィードバックを当該決定ユニット１２０に送信するように構成される。一部の実施態様において、当該決定ユニット１２０は、当該フィードバックに基づいて、当該通信プロトコルＰを決定する。例えば、当該ユーザ端末１０は、リアルタイムデータ通信に対してフィードバックを有することがある。当該フィードバックは、通信に対する満足感または不満であり得る。当該決定ユニット１２０は、当該フィードバックを参考として取り入れ、当該通信プロトコルＰを決定することができる。

一部の実施態様において、当該受信ユニット１１０は、当該ユーザ端末１０のインターネット品質を受信することができる。当該決定ユニット１２０は、当該インターネット品質に基づいて、当該ユーザ端末１０への通信プロトコルＰを決定することができる。当該インターネット品質は、最初のレンダリング（表示までの時間）、ビデオ遅延、バッファリング率、またはバッファリング回数などの指標に基づいて評価されてもよい。

一部の実施態様において、当該決定ユニット１２０は、これら４つの指標を評価して、当該４つの指標に基づき、当該通信プロトコルＰを決定することができる。より具体的に、当該決定ユニット１２０は、当該ユーザ端末１０のインターネット品質に基づき、ビデオ遅延などいずれかの指標を分析し、どの通信プロトコルＰのビデオ遅延が最短かをチェックして、当該ユーザ端末１０へのビデオ遅延が最短の当該通信プロトコルＰを決定する。例えば、当該ユーザ端末１０が当該インタラクションサーバ３０に要求を送信した場合、当該受信ユニット１１０は当該ユーザ端末１０のインターネット品質を受信することができる。当該決定ユニット１２０は、各通信プロトコルＰを介して通信している間にバッファリングを評価し、当該ユーザ端末１０へのバッファリングが最低の当該通信プロトコルＰを決定することができる。

一部の実施態様において、当該ユーザ端末１０は、異なるストリーミングサーバ４０との間でリアルタイムデータを受信および送信することができる。当該決定ユニット１２０は、インターネット品質に基づき、当該ユーザ端末１０へのストリーミングサーバ４０を決定することができる。一部の実施態様において、当該ストリーミングサーバ４０は、ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）プロバイダとしてもよい。図８に示すように、当該決定ユニット１２０はさらに、工程Ｓ１０６における当該インターネット品質に基づいて、当該ユーザ端末１０へのストリーミングサーバ４０を決定することができる。より具体的に、当該決定ユニット１２０は、異なるストリーミングサーバ４０を介して当該ユーザ端末１０のインターネット品質を評価することができる。例えば、当該決定ユニット１２０は、当該ユーザ端末１０が異なるストリーミングサーバ４０と通信する間、当該ストリーミングデータのバッファリングを評価し、当該ユーザ端末１０へのバッファリングが最短のストリーミングサーバ４０を決定する。工程Ｓ１０８において、当該インタラクションサーバ３０は、当該ストリーミングサーバ４０の情報を当該ユーザ端末１０に送信する。一部の実施態様において、当該ストリーミングサーバ４０の当該情報は、当該ストリーミングサーバ４０のＵＲＬとすることができる。工程Ｓ１０９において、当該ユーザ端末１０は、当該ストリーミングサーバ４０を介してストリーミングデータを要求する。工程Ｓ１１０において、当該ストリーミングサーバ４０は、当該ユーザ端末１０からの要求に応答して、当該ストリーミングデータを送信する。従って、当該データ通信システム１００では、当該ユーザ端末１０が適したストリーミングサーバ４０にアクセスし、ユーザエクスペリエンスを向上する。

一部の実施態様において、当該受信ユニット１１０はさらに、当該ユーザ端末１０から履歴データを受信することができる。当該履歴データはさらに、当該ユーザ端末１０の過去のインターネット品質、地理的位置情報および時間情報を含むことができる。当該決定ユニット１２０は、当該履歴データを評価して、当該ユーザ端末１０への当該ストリーミングサーバ４０を事前に決定することができる。例えば、当該履歴データに基づき、特定の時間に特定の場所にいるユーザが、特定のストリーミングサーバ４０を介して最短のビデオ遅延を有することが示される場合、当該決定ユニット１２０は、当該特定の時間に当該特定の場所にいるユーザへの当該ストリーミングサーバ４０を事前に決定することができる。

さらに、上記実施態様で説明したシステムまたは方法は、固体記憶装置、光ディスク記憶装置、磁気ディスク記憶装置などの非一時的なコンピュータ可読ストレージ装置で提供されてもよい。あるいは、プログラムは、インターネットを介してサーバからダウンロードされるものとしてもよい。

以上、本発明の技術的内容及び特徴を説明したが、本発明の属する技術分野において通常の知識を有する者であれば、本発明の教示及び開示から逸脱することなく、なお多くの変形及び修正を行うことができる。したがって、本発明の範囲は、既に開示された実施態様に限定されず、本発明から逸脱しない別の変形や修正を含み、後付の特許請求の範囲に含まれる範囲である。

１ 通信システム
１０ ユーザ端末
１１ インタラクションユニット
１２ デコーダー
１３ ディスプレイ
１４ ストリーミング入力
１５ エンコーダー
３０ インタラクションサーバ
４０ ストリーミングサーバ
１００ データ通信システム
１１０ 受信ユニット
１２０ 決定ユニット
１３０ 転送ユニット
Ｐ 通信プロトコル
Ａ 動作
Ａｉ インタラクション動作
Ａｎｉ 非インタラクション動作

Claims (21)

1. データ通信システムであって、
   ユーザからの操作に基づいてユーザ端末によって実行される動作を、前記ユーザ端末から受信するように構成された受信ユニットと、
   前記受信ユニットに接続され、前記動作により要求される指標に基づき、前記ユーザ端末への通信プロトコルを決定するように構成された決定ユニットと、
   を含み、決定された前記通信プロトコルが前記ユーザ端末に通知され、前記ユーザ端末が前記通信プロトコルを介してリアルタイムデータを要求する、ことを特徴とする、データ通信システム。
2. 前記受信ユニットがさらに、前記ユーザ端末とサーバの相互間に利用可能な通信プロトコルを受信し、前記決定ユニットが前記利用可能な通信プロトコルから前記通信プロトコルを選択し、かつさらに前記動作に基づき、前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
3. 前記決定ユニットがさらに、予測要素を含み、前記予測要素が、前記動作に基づいて後続の動作を予測するように構成され、前記決定ユニットが、前記後続の動作に基づき前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
4. 前記予測要素が、前記ユーザ端末から複数の履歴データを収集し、前記後続の動作を予測する、ことを特徴とする、請求項３に記載のデータ通信システム。
5. 前記動作がさらに、インタラクション動作を含み、前記インタラクション動作によって、インタラクションデータを送信および（または）受信、またはストリーミングデータを送信および（または）受信し、前記決定ユニットが、前記インタラクション動作に基づいて前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
6. 前記動作がさらに、非インタラクション動作を含み、前記非インタラクション動作によって、ストリーミングデータを送信することなく受信、またはストリーミングデータを受信することなく送信し、前記決定ユニットが、前記非インタラクション動作に基づいて前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
7. 前記決定ユニットが、前記ユーザ端末がオーディオコンテンツのみのストリーミングデータを受信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
8. 前記決定ユニットが、前記ユーザ端末がビデオコンテンツのみのストリーミングデータを受信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
9. 前記決定ユニットが、前記ユーザ端末がオーディオコンテンツおよび（または）ビデオコンテンツを備えたストリーミングデータを送信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
10. 前記決定ユニットが、前記ユーザ端末がインタラクションデータを受信または送信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
11. 前記決定ユニットが、前記ユーザ端末がインタラクションデータを受信および送信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
12. 前記決定ユニットが、前記ユーザ端末が異なるユーザ端末から短時間内に連続してストリーミングデータを受信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
13. 前記決定ユニットが、前記ユーザ端末が異なるユーザ端末から同時にストリーミングデータを受信するための前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
14. フィードバック収集ユニットをさらに含み、前記フィードバック収集ユニットが、前記ユーザ端末からフィードバックを収集し、前記フィードバックを前記決定ユニットに送信するものであり、前記決定ユニットが、前記フィードバックに基づいて前記通信プロトコルを決定する、ことを特徴とする、請求項１に記載のデータ通信システム。
15. 前記決定ユニットが、インターネット品質に基づいて前記通信プロトコルを決定し、前記インターネット品質が、最初のレンダリング、ビデオ遅延、バッファリング率、またはバッファリング回数の指標によって評価される、ことを特徴とする、請求項１に記載のデータ通信システム。
16. データ通信方法であって、
    ユーザからの操作に基づいてユーザ端末により実行される動作を、前記ユーザ端末から受信する工程と、
    前記動作により要求される指標に基づいて、前記ユーザ端末への通信プロトコルを決定する工程と、
    を含み、決定された前記通信プロトコルが前記ユーザ端末に通知され、前記ユーザ端末が前記通信プロトコルを介してリアルタイムデータを要求する、ことを特徴とする、データ通信方法。
17. 前記動作がさらに、インタラクション動作を含み、前記インタラクション動作によって、インタラクションデータを送信および（または）受信、またはストリーミングデータを送信および（または）受信し、前記通信プロトコルが、前記インタラクション動作に基づいて決定される、ことを特徴とする、請求項１６に記載のデータ通信方法。
18. 前記動作がさらに、非インタラクション動作を含み、前記非インタラクション動作によって、ストリーミングデータを送信することなく受信、またはストリーミングデータを受信することなく送信し、前記通信プロトコルが、前記非インタラクション動作に基づいて決定される、ことを特徴とする、請求項１６に記載のデータ通信方法。
19. 前記通信プロトコルが、前記ユーザ端末が異なるユーザ端末から短時間内に連続してストリーミングデータを受信するように決定される、ことを特徴とする、請求項１６に記載のデータ通信方法。
20. 前記通信プロトコルが、前記ユーザ端末が異なるユーザ端末から同時にストリーミングデータを受信するように決定される、ことを特徴とする、請求項１６に記載のデータ通信方法。
21. 前記指標は、最初のレンダリング、ビデオ遅延、バッファリング率、またはバッファリング回数である、請求項１に記載のデータ通信システム。