特開 2023-162202 ストリーミングデータにアクセスするためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023162202

(43)【公開日】2023-11-08

(54)【発明の名称】ストリーミングデータにアクセスするためのシステムおよび方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20231031BHJP

   H04N 21/647 20110101ALI20231031BHJP

   H04N 21/63 20110101ALI20231031BHJP

   H04L 67/1029 20220101ALI20231031BHJP

【ＦＩ】

G06F9/50 150C

H04N21/647

H04N21/63

H04L67/1029

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2023126565

(22)【出願日】2023-08-02

(62)【分割の表示】P 2022187749の分割

【原出願日】2022-11-24

(31)【優先権主張番号】P 2022009905

(32)【優先日】2022-01-26

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】517287224

【氏名又は名称】１７ＬＩＶＥ株式会社

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(72)【発明者】

【氏名】張育銓

(72)【発明者】

【氏名】李昆擇

(72)【発明者】

【氏名】劉哲▲い▼

(57)【要約】      （修正有）

【課題】限られたサーバ台数で多くのクライアントにストリーミングデータを送信するシステム及び方法を提供する。
【解決手段】ロードバランサによってインターネット上でストリーミングデータにアクセスする方法は、視聴者Ａのユーザ端末からネットワークを介してストリーミングデータに対する第１の要求を取得する工程と、当該ストリーミングデータにアクセスするためにプルエッジサーバに当該第１の要求を送信する工程と、当該第１の要求に含まれる識別情報を当該サーバに対応するようにテーブルに記録する工程と、視聴者Ｂの第２のユーザ端末からネットワークを介してストリーミングデータに対する第２の要求を取得する工程と、当該ストリーミングデータにアクセスするために当該サーバに当該第２の要求を送信する工程と、を含む。当該第２の要求に含まれる識別情報が、当該第１の要求に含まれる識別情報と同じである。
【選択図】図２

【特許請求の範囲】

【請求項1】

ロードバランサにより実行される、ストリーミングデータにアクセスするための方法であって、
第１のユーザ端末から、ネットワークを介して、ストリーミングデータに対する第１の要求を取得する工程と、
前記ストリーミングデータにアクセスするために前記第１の要求をサーバに送信する工程と、
前記第１の要求に含まれる識別情報を、前記サーバに対応するものとしてテーブルに記録する工程と、
第２のユーザ端末から、ネットワークを介して、前記ストリーミングデータに対する第２の要求を取得する工程と、
前記ストリーミングデータにアクセスするために前記第２の要求を前記サーバに送信する工程と、
を含み、そのうち、前記第２の要求に含まれる識別情報が、前記第１の要求に含まれる前記識別情報と同じである、ことを特徴とする、ストリーミングデータにアクセスするための方法。

【請求項2】

前記ストリーミングデータがライブストリーミングデータである、ことを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項3】

さらに、前記テーブルを参照することにより、前記第２の要求に含まれる前記識別情報が、前記第１の要求に含まれる前記識別情報と同じであることを判断する工程を含む、ことを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項4】

前記第１のユーザ端末が前記サーバを介して前記ストリーミングデータにアクセスしている間に、前記第２の要求が取得されることを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項5】

前記ストリーミングデータの前記識別情報が、前記ストリーミングデータの配信者を特定する配信者ＩＤであることを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項6】

前記ストリーミングデータの前記識別情報が、前記ストリーミングデータを特定するストリームＩＤであることを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項7】

前記サーバが、オリジンサーバから前記ストリーミングデータを取り込むプルエッジサーバであり、前記オリジンサーバが、前記ストリーミングデータを提供する配信者のユーザ端末から前記ストリーミングデータを受信することを特徴とする、請求項６に記載のストリーミングデータにアクセスするための方法。

【請求項8】

前記ストリーミングデータが、前記第１のユーザ端末に送信される前に、前記サーバでトランスコードされることを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項9】

さらに、前記ストリーミングデータにアクセスするために前記第２の要求を前記サーバに送信する前に、前記サーバに接続されているユーザ端末の数が閾値未満であることを判定する工程を含む、ことを特徴とする、請求項１に記載のストリーミングデータにアクセスするための方法。

【請求項10】

ストリーミングデータにアクセスするためのシステムであって、１以上のプロセッサを含み、そのうち、前記１以上のプロセッサが機械可読命令を実行して、
第１のユーザ端末から、ネットワークを介して、ストリーミングデータに対する第１の要求を取得する工程と、
前記ストリーミングデータにアクセスするために前記第１の要求をサーバに送信する工程と、
前記第１の要求に含まれる識別情報を、前記サーバに対応するものとしてテーブルに記録する工程と、
第２のユーザ端末から、ネットワークを介して、前記ストリーミングデータに対する第２の要求を取得する工程と、
前記ストリーミングデータにアクセスするために前記第２の要求を前記サーバに送信する工程と、
を実行し、そのうち、前記第２の要求に含まれる識別情報が、前記第１の要求に含まれる前記識別情報と同じである、ことを特徴とする、ストリーミングデータにアクセスするためのシステム。

【請求項11】

ライブストリーミングデータのためのロードバランサであって、
現在利用可能なライブストリームを識別するストリームＩＤと、前記現在利用可能なライブストリームを取り扱うサーバを識別する各サーバＩＤとを保存するように構成された保存ユニットと、
ユーザの端末からネットワークを介して第１のストリームＩＤを含む要求を受信するように構成された受信ユニットと、
前記要求の受信に応答して、前記保存ユニットを参照し、前記第１のストリームＩＤによって識別される第１のライブストリームを取り扱う第１のサーバを決定するように構成された決定ユニットと、
決定された前記第１のサーバに、前記第１のライブストリームのライブストリーミングデータを前記ユーザの前記端末に送信させるように構成された接続ユニットと、
を含む、ことを特徴とする、ライブストリーミングデータのためのロードバランサ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネット上のデータアクセスに関し、特に、インターネット上のストリーミングデータにアクセスすることに関する。

【背景技術】

【0002】

ライブストリーミングに代表されるように、インターネット上におけるリアルタイムのデータアクセスが日常生活に浸透している。リアルタイムのデータアクセスを支援または提供するシステムでは、限られた利用可能なインフラストラクチャやサービス、例えばサーバの容量を、潜在的なクライアントとそのクライアントがアクセスを必要とするコンテンツに効率的に分配することが重要である。

【0003】

プルエッジサーバとは、データが保存または受信されるオリジンサーバからのデータプルを容易にするように構成されたサーバである。オリジンサーバは、ストリーマー／配信者から直接または間接的にストリーミングデータを受信することができる。ストリーミングデータアクセスのシナリオでは、ストリーミングデータが格納されるオリジンサーバと、ストリーミングデータにアクセスするクライアントとの間に、複数のプルエッジサーバが展開されてもよい。プルエッジサーバは、オリジンサーバからデータを引き出してクライアントに分配することで、オリジンサーバの負担を軽減し、サービスを受けるクライアントの数を増加させることができる。

【発明の概要】

【0004】

本発明の一実施態様に係る方法は、１以上のコンピュータによって実行されるストリーミングデータにアクセスするための方法であって、当該方法が、第１のユーザ端末からネットワークを介してストリーミングデータに対する第１の要求を取得する工程と、当該ストリーミングデータにアクセスするためにサーバに当該第１の要求を送信する工程と、当該第１の要求に含まれる識別情報を当該サーバに対応するようにテーブルに記録する工程と、第２のユーザ端末からネットワークを介してストリーミングデータに対する第２の要求を取得する工程と、当該ストリーミングデータにアクセスするために当該サーバに当該第２の要求を送信する工程と、を含み、当該第２の要求に含まれる識別情報が、当該第１の要求に含まれる識別情報と同じである。

【0005】

本発明の一実施態様に係るシステムは、１以上のプロセッサを含むストリーミングデータにアクセスするためのシステムであり、当該１以上のコンピュータプロセッサが、機械可読命令を実行して、第１のユーザ端末からネットワークを介してストリーミングデータに対する第１の要求を取得する工程と、当該ストリーミングデータにアクセスするためにサーバに当該第１の要求を送信する工程と、当該第１の要求に含まれる識別情報を当該サーバに対応するようにテーブルに記録する工程と、第２のユーザ端末からネットワークを介してストリーミングデータに対する第２の要求を取得する工程と、当該ストリーミングデータにアクセスするために当該サーバに当該第２の要求を送信する工程と、を実行し、当該第２の要求に含まれる識別情報が、当該第１の要求に含まれる識別情報と同じである。

【0006】

本発明の一実施態様に係るロードバランサは、ストリーミングデータにアクセスするためのロードバランサであって、当該ロードバランサが、現在利用可能なライブストリームを識別するストリームＩＤと、当該現在利用可能なライブストリームを取り扱うサーバを識別するそれぞれのサーバＩＤとを保存するように構成された保存ユニットと、ユーザの端末からネットワークを介して第１のストリームＩＤを含む要求を受信するように構成された受信ユニットと、当該要求の受信に応答して、当該保存ユニットを参照し、当該第１のストリームＩＤによって識別される第１のライブストリームを取り扱う第１のサーバを決定するように構成された決定ユニットと、決定された当該第１のサーバに、当該第１のライブストリームのライブストリーミングデータを当該ユーザの当該端末に送信させるように構成された接続ユニットと、を含む。

【図面の簡単な説明】

【0007】

【図1】従来のインターネット上でのデータアクセスの操作を示す例示的シーケンス図である。

【図2】本発明の一部の実施態様に基づくインターネット上でのデータアクセスの操作を示す例示的シーケンス図である。

【図3】本発明の一部の実施態様に基づくインターネット上でのデータアクセスの操作を示す例示的シーケンス図である。

【図4】本発明の一部の実施態様に基づくプルエッジサーバテーブルの例示的データ構造を示す表である。

【図5】本発明の一部の実施態様に基づくライブストリーミングシステム１の構成を示す概略図である。

【図6】本発明の一部の実施態様に基づく、図５のユーザ端末３０の機能と構成を示すブロック図である。

【図7】本発明の一部の実施態様に基づく、図１１のコントロールサーバ１００の機能と構成を示すブロック図である。

【図8】ストリームＤＢ３１０の例示的データ構造を示す表である。

【図9】ユーザＤＢ３１２の例示的データ構造を示す表である。

【図10】贈り物ＤＢ３１４の例示的データ構造を示す表である。

【図11】本発明の一部の実施態様に基づく、図５のサーバシステム１０の機能と構成を示すブロック図である。

【図12】本発明の一部の実施態様に基づく、図１１のロードバランサ５０の機能と構成を示すブロック図である。

【図13】ロードバランサ５０に実装される例示的な工程を示すフローチャートである。

【発明を実施するための形態】

【0008】

データアクセスシステム内のサーバ容量を割り当てる際の課題の１つが、限られたサーバ台数でいかに多くのクライアントにサービスを提供するかということである。アクセスされるデータは、ライブビデオデータなどのライブストリーミングデータであってもよい。クライアントは、ユーザや視聴者によって操作され、ライブストリーミングデータを要求するユーザ端末であってもよい。クライアントは、配信者またはストリーマーが操作するユーザ端末であって、ライブストリーミングデータを提供するものであってもよい。サーバは、それらのライブストリーミングデータが提供され、クライアントがアクセスする場所である。

【0009】

図１に、従来のインターネット上でのデータアクセスの操作を示す例示的シーケンス図を示す。視聴者Ａ、視聴者Ｂ、視聴者Ｃは、ストリーミングデータを要求する視聴者が操作するユーザ端末と見なすことができる。ユーザ端末は、スマートフォン、ノートパソコン、パーソナルコンピュータなど、インターネットにアクセス可能な任意の機器とすることができる。当該ロードバランサ５０は、プルエッジサーバを選択し、ストリーミングデータにアクセスするための視聴者からの要求をプルエッジサーバに導く、渡す、送信する、分配する、または割り当てるように構成される。

【0010】

工程Ｓ１００において、視聴者Ａはロードバランサ５０に対して、ストリーミングデータの要求を送信する。

【0011】

工程Ｓ１０２において、当該ロードバランサ５０は、当該プルエッジサーバ６２を選択し、視聴者Ａからの当該要求を当該プルエッジサーバ６２に導く、または送信する。

【0012】

工程Ｓ１０４において、当該プルエッジサーバ６２は当該要求を当該ストリーミングデータが保存または受信される当該オリジンサーバ７０に送信する。

【0013】

工程Ｓ１０６において、当該ストリーミングデータが当該オリジンサーバ７０から当該プルエッジサーバ６２に提供される。

【0014】

工程Ｓ１０８において、当該プルエッジサーバ６２は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、ＷｅｂＲＴＣのアクセスに対応させてもよい。

【0015】

工程Ｓ１１０において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ａに返す、または送信する。

【0016】

工程Ｓ１１２において、視聴者Ｂはロードバランサ５０に対して、ストリーミングデータの要求を送信する。

【0017】

工程Ｓ１１４において、当該ロードバランサ５０は当該プルエッジサーバ６４を選択し、視聴者Ｂからの当該要求を当該プルエッジサーバ６４に導く、または送信する。

【0018】

工程Ｓ１１６において、当該プルエッジサーバ６４は当該要求を当該ストリーミングデータが受信及び（または）保存される当該オリジンサーバ７０に送信する。

【0019】

工程Ｓ１１８において、当該ストリーミングデータが当該オリジンサーバ７０から当該プルエッジサーバ６４に提供される。

【0020】

工程Ｓ１２０において、当該プルエッジサーバ６４は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、視聴者によるＷｅｂＲＴＣのアクセスに対応させてもよい。

【0021】

工程Ｓ１２２において、当該プルエッジサーバ６４はトランスコードされた当該ストリーミングデータを視聴者Ｂに返す、または送信する。

【0022】

工程Ｓ１２４において、視聴者Ｃはロードバランサ５０に対して、ストリーミングデータの要求を送信する。

【0023】

工程Ｓ１２６において、当該ロードバランサ５０は当該プルエッジサーバ６６を選択し、視聴者Ｃからの当該要求を当該プルエッジサーバ６６に導く、または送信する。

【0024】

工程Ｓ１２８において、当該プルエッジサーバ６６は当該要求を当該ストリーミングデータが受信及び（または）保存される当該オリジンサーバ７０に送信する。

【0025】

工程Ｓ１３０において、当該ストリーミングデータが当該オリジンサーバ７０から当該プルエッジサーバ６６に提供される。

【0026】

工程Ｓ１３２において、当該プルエッジサーバ６６は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、ＷｅｂＲＴＣのアクセスに対応させてもよい。

【0027】

工程Ｓ１３４において、当該プルエッジサーバ６４はトランスコードされた当該ストリーミングデータを視聴者Ｃに返す、または送信する。

【0028】

従来、ロードバランサは、視聴者からのストリーミングデータの要求を、プルエッジサーバに公平または均等に分配、送信、または導き、プルエッジサーバの負荷を分散させる。つまり、ロードバランサは、新たに受信した要求を「最も空いている」または「最も占有されていない」サーバに分配し、このサーバは、ＣＰＵ使用率が最も低いサーバ、メモリ使用率が最も低いサーバ、またはアクセスするクライアントが最も少ないサーバであってもよい。従来、ロードバランサは、プルエッジサーバに要求を導く際に、要求されたストリーミングデータのリソースまたはアイデンティティを考慮しない。ストリーミングデータのリソースまたはアイデンティティは、例えば、ストリーミングデータを提供するストリーマーまたは配信者であってもよく、またはこれらを含んでもよい。したがって、同じストリーミングデータ（同じ配信者からのストリーミングデータ）に対する要求が、アクセス用に異なるプルエッジサーバに導かれることがしばしば起こる。

【0029】

例えば、図１において、視聴者Ａ、視聴者Ｂ、視聴者Ｃが同じストリーミングデータ（つまり、同じリソースまたは同じアイデンティティのストリーミングデータ）を要求した場合でも、ロードバランサはやはりそれらの要求をプルエッジサーバ６２、６４、６６に均等に導く／送信する。

【0030】

しかし、この方法では、データアクセスを完了させるために同じストリーミングデータのトランスコーディング処理を３回実行する必要がある。つまり、工程Ｓ１０８、工程Ｓ１２０、工程Ｓ１３２において、同一のストリーミングデータのトランスコーディング処理を、当該プルエッジサーバ６２、当該プルエッジサーバ６４、プルエッジサーバ６６でそれぞれ実行する必要がある。

【0031】

これは、プルエッジサーバ全体のリソース、特にＣＰＵの消費量に無駄が生じる。トランスコーディング処理は、トランスコーディング処理が実行されるサーバのＣＰＵ使用率を一定量消費することになる。トランスコーディング処理に必要なＣＰＵ使用率がＸ％であるとすると、図１中のシステムでは、プルエッジサーバリソース全体に対して３倍のＣＰＵ使用率を消費することになる。プルエッジサーバの構成により、Ｘは１～１０の範囲であってもよい。例えば、Ｘは２であってもよい。

【0032】

ストリーミングデータを視聴者に返すなど、各視聴者またはクライアントへの対応にも、プルエッジサーバのＣＰＵ使用率を消費する。したがって、ストリーミングデータの提供やトランスコーディングにおけるプルエッジサーバのリソース消費を抑えることで、サービスを提供する視聴者の数を増やすことが望ましい。

【0033】

図２に本発明の一部の実施態様に基づくインターネット上でのデータアクセスの操作を示す例示的シーケンス図を示す。

【0034】

まず、視聴者Ａのユーザ端末は、ネットワークを介してコントロールサーバ（後述する）から現在利用可能なライブストリームの一覧を受信する。当該リストには、現在利用可能な各ライブストリームに対応するストリームＩＤのリストが含まれる。当該ユーザ端末は、受信した当該リストをディスプレイに表示する。視聴者Ａが当該ディスプレイ上の当該リストから１つのライブストリームを選択する。その後、当該ユーザ端末は、選択されたライブストリームのストリーミングデータの配信要求を生成する。工程Ｓ２００において、視聴者Ａの当該ユーザ端末は、生成されたストリーミングデータの配信要求を当該ロードバランサ５０に送信する。当該配信要求には、選択されたライブストリームの当該ストリーミングデータの識別情報Ｓ１が含まれる。一部の実施態様において、当該識別情報Ｓ１は、当該ストリーミングデータを提供する配信者またはストリーマーなど、当該ストリーミングデータのリソースに対応する。当該識別情報Ｓ１は、ストリーマーＩＤまたは配信者ＩＤであってもよい。一部の実施態様において、当該識別情報Ｓ１は、当該ストリーミングデータのアイデンティティに対応する。当該識別情報Ｓ１は、当該ストリーミングデータのストリームＩＤであってもよい。一部の実施態様において、当該識別情報Ｓ１は、視聴者Ａからの当該配信要求に含まれるＵＲＬに含まれる。識別情報は、要求される当該ストリーミングデータを示す、または特定するために用いられる。一部の実施態様において、ライブストリーミングデータは、識別情報によって一意に特定される。

【0035】

工程Ｓ２０２において、当該ロードバランサ５０は当該プルエッジサーバ６２を選択し、視聴者Ａからの当該配信要求を当該プルエッジサーバ６２に導く／送信する。当該ロードバランサ５０は、視聴者Ａからの当該配信要求に含まれる当該識別情報Ｓ１を、当該プルエッジサーバ６２に対応するものとしてルックアップテーブルまたはキャッシュテーブル、あるいはプルエッジサーバテーブルに記録する。一部の実施態様において、当該ルックアップテーブルまたはキャッシュテーブル、あるいはプルエッジサーバテーブルは当該ロードバランサ５０に実装され、管理される。

【0036】

工程Ｓ２０４において、当該プルエッジサーバ６２は視聴者Ａからの当該配信要求を当該ストリーミングデータが受信及び（または）保存される当該オリジンサーバ７０に送信する。

【0037】

工程Ｓ２０６において、当該ストリーミングデータが当該オリジンサーバ７０から当該プルエッジサーバ６２に提供される。

【0038】

工程Ｓ２０８において、当該プルエッジサーバ６２は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、視聴者によるＷｅｂＲＴＣのアクセスに対応させてもよい。

【0039】

工程Ｓ２１０において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ａに返す、または送信する。

【0040】

視聴者Ｂの当該ユーザ端末は、ネットワークを介して当該コントロールサーバから現在利用可能なライブストリームの一覧を受信する。当該ユーザ端末は、受信した当該リストをディスプレイに表示する。視聴者Ｂは、視聴者Ａが選択したものと同じライブストリームを選択する。その後、当該ユーザ端末は、選択されたライブストリームのストリーミングデータの配信要求を生成する。工程Ｓ２１２において、視聴者Ｂの当該ユーザ端末は、ストリーミングデータについて生成された当該配信要求を当該ロードバランサ５０に送信する。視聴者Ｂからの当該配信要求に含まれる当該識別情報は、工程Ｓ２００で視聴者Ａからの当該配信要求に含まれる当該識別情報と同じＳ１であり、これは、視聴者Ｂにより要求された当該ストリーミングデータが、視聴者Ａにより要求された当該ストリーミングデータと同じであることを示す。

【0041】

工程Ｓ２１４において、当該ロードバランサ５０は、当該キャッシュテーブルを検索し、視聴者Ｂからの当該配信要求に含まれる当該識別情報が、すでに当該キャッシュテーブルに記録されているかどうかを確認し、視聴者Ｂからの当該配信要求に含まれる当該識別情報がすでに当該キャッシュテーブルに記録されている場合、対応するプルエッジサーバを検索する。視聴者Ｂからの当該配信要求に含まれる当該識別情報もＳ１であるため、当該キャッシュテーブルにより、当該ロードバランサ５０は視聴者Ｂからの当該配信要求に含まれる当該識別情報が、視聴者Ａからの当該配信要求に含まれる当該識別情報と同じであると判断する。当該ロードバランサ５０は、視聴者Ｂからの当該配信要求に含まれる当該識別情報が当該キャッシュテーブルに存在する（工程Ｓ２０２で記録されている）と判断し、当該キャッシュテーブルに記録されている対応するプルエッジサーバ、つまり当該プルエッジサーバ６２を、視聴者Ｂのストリーミングデータアクセスのためのプルエッジサーバとして選択する。当該ロードバランサ５０は、視聴者Ｂからの当該配信要求を当該プルエッジサーバ６２に導く。

【0042】

工程Ｓ２１６において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ｂに返す、または送信する。当該識別情報Ｓ１に対応する当該ストリーミングデータの（当該プルエッジサーバ６２への）提供処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０６ですでに実行されているため、視聴者Ｂによる同じストリーミングデータへのアクセス中にもう一度提供処理を実行する必要はない。当該識別情報Ｓ１に対応する当該ストリーミングデータのトランスコーディング処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０８ですでに実行されているため、視聴者Ｂによるストリーミングデータへのアクセス中にもう一度トランスコーディング処理を実行する必要はない。

【0043】

視聴者Ｃの当該ユーザ端末は、ネットワークを介してコントロールサーバから現在利用可能なライブストリームの一覧を受信する。当該ユーザ端末は、受信した当該リストをディスプレイに表示する。視聴者Ｃは、視聴者Ａが選択したものと同じライブストリームを選択する。その後、当該ユーザ端末は、選択されたライブストリームのストリーミングデータの配信要求を生成する。工程Ｓ２１８において、視聴者Ｃの当該ユーザ端末は、ストリーミングデータについて生成された配信要求を当該ロードバランサ５０に送信する。視聴者Ｃからの当該配信要求に含まれる当該識別情報は、工程Ｓ２００で視聴者Ａからの当該配信要求に含まれる当該識別情報と同じＳ１であり、これは、視聴者Ｃにより要求された当該ストリーミングデータが、視聴者Ａにより要求された当該ストリーミングデータと同じであることを示す。

【0044】

工程Ｓ２２０において、当該ロードバランサ５０は、当該キャッシュテーブルを検索し、視聴者Ｃからの当該配信要求に含まれる当該識別情報が、すでに当該キャッシュテーブルに記録されているかどうかを確認し、視聴者Ｃからの当該配信要求に含まれる当該識別情報がすでに当該キャッシュテーブルに記録されている場合、対応するプルエッジサーバを検索する。視聴者Ｃからの当該配信要求に含まれる当該識別情報もＳ１であるため、当該キャッシュテーブルにより、当該ロードバランサ５０は視聴者Ｃからの当該配信要求に含まれる当該識別情報が、視聴者Ａからの当該配信要求に含まれる当該識別情報と同じであると判断する。当該ロードバランサ５０は、視聴者Ｃからの当該配信要求に含まれる当該識別情報が当該キャッシュテーブルに存在する（工程Ｓ２０２で記録されている）と判断し、当該キャッシュテーブルに記録されている対応するプルエッジサーバ、つまり当該プルエッジサーバ６２を、視聴者Ｃのストリーミングデータアクセスのためのプルエッジサーバとして選択する。当該ロードバランサ５０は、視聴者Ｃからの当該配信要求を当該プルエッジサーバ６２に導く。

【0045】

工程Ｓ２２２において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ｃに返す、または送信する。当該識別情報Ｓ１に対応する当該ストリーミングデータの（当該プルエッジサーバ６２への）提供処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０６ですでに実行されているため、視聴者Ｃによる同じストリーミングデータへのアクセス中にもう一度提供処理を実行する必要はない。当該識別情報Ｓ１に対応する当該ストリーミングデータのトランスコーディング処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０８ですでに実行されているため、視聴者Ｃによるストリーミングデータへのアクセス中にもう一度トランスコーディング処理を実行する必要はない。

【0046】

従来であれば、当該ロードバランサ５０は、視聴者Ｂからの当該配信要求または視聴者Ｃからの当該配信要求に対して、当該プルエッジサーバ６４または当該プルエッジサーバ６６を選択する。これは、当該プルエッジサーバ６４または当該プルエッジサーバ６６はまだストリーミングデータを提供しておらず、視聴者Ａによるアクセス中にすでにストリーミングデータを提供している当該プルエッジサーバ６２よりも、多くのＣＰＵ、メモリまたは帯域幅リソースを有するためである。しかし、その場合、ストリーミングデータの提供処理とトランスコーディング処理を３回実行することになり、プルエッジサーバプール全体のＣＰＵ、メモリ、時間または帯域幅のリソースを多く消費することになる。さらに、提供処理やトランスコーディング処理で消費されるリソースは、同じストリーミングデータにアクセスする視聴者数が増えるほど増加する。

【0047】

図２に示す実施態様において、当該ロードバランサ５０内のキャッシュテーブル（またはプルエッジサーバテーブル）を利用することで、同じストリーミングデータを要求するすべての視聴者が、同じプルエッジサーバに導かれる。したがって、ストリーミングデータの提供処理とトランスコーディング処理は１回のみ実行されることになり、プルエッジサーバプール全体のＣＰＵ、メモリ、時間または帯域幅のリソースが節約される。さらに、提供処理やトランスコーディング処理で消費されるリソースは、同じストリーミングデータにアクセスする視聴者数が増えても増加しない。したがって、プルエッジサーバプールで節約されるリソースを、より多くの視聴者にサービスを提供するために使用することができる。トランスコーディング、またはリアルタイムトランスコーディングは、オリジンサーバで受信及び（または）保存されたストリーミングデータの形式が、クライアントに送信されるストリーミングデータの形式と異なる場合、あらゆるストリーミングデータアクセスにおいて非常に重要である。一部の実施態様において、ストリーミングデータに含まれるオーディオデータのトランスコーディングは、同じストリーミングデータに含まれるビデオデータのトランスコーディングよりも多くのＣＰＵリソースを消費することがある。

【0048】

本発明は、ロードバランサのキャッシュテーブルを活用することで、ストリーミングデータにアクセスする視聴者に対し、リアルタイムの動的なスケーリング機能も提供する。つまり、視聴者の数がリアルタイムで増加すると、ストリーミングデータがすでにプルエッジサーバを介して前の視聴者によりアクセスされている間に、ストリーミングデータを要求する後の視聴者を正しいプルエッジサーバに導くことができる。

【0049】

本発明の一部の実施態様において、キャッシュテーブルにキャッシュされるデータは、ストリーミングデータそのものではなく、経路またはアクセスである。例えば、ルートは、要求されたストリーミングデータが提供されているプルエッジサーバを参照してもよい。

【0050】

一部の実施態様において、ロードバランサは、Ｔｒａｅｆｉｋなどのリバースプロキシを含んでもよく、またその一部であってもよい。一部の実施態様において、送信中にストリーミングデータの当該識別情報がＵＲＬに含まれるため、ロードバランサに実装されるキャッシュテーブルは、ＵＲＬキャッシュテーブルと呼ばれてもよい。本発明は、ライブストリーミングデータアクセスのためのロードバランサにキャッシュテーブルを実装することにより、ＵＲＬアフィニティ機能を実現する。

【0051】

従来のＴｒａｅｆｉｋは、キャッシュテーブルを備えていない。従来のクッキーアフィニティに基づく負荷分散では、視聴者のＩＤに応じてプルエッジサーバを割り当てるため、同じ視聴者からの要求は同じプルエッジサーバに割り当てられ、プルエッジサーバプールのリソースに無駄を生じる。

【0052】

図３に本発明の一部の実施態様に基づくインターネット上でのデータアクセスの操作を示す例示的シーケンス図を示す。

【0053】

工程Ｓ３００において、視聴者Ａはロードバランサ５０に対して、ストリーミングデータの配信要求を送信する。当該配信要求には、当該ストリーミングデータの識別情報Ｓ１が含まれる。一部の実施態様において、当該識別情報Ｓ１は、当該ストリーミングデータのアイデンティティに対応する。当該識別情報Ｓ１は、当該ストリーミングデータのストリームＩＤであってもよい。一部の実施態様において、当該識別情報Ｓ１は、視聴者Ａからの当該配信要求に含まれるＵＲＬに含まれる。識別情報は、要求される当該ストリーミングデータを示す、または特定するために用いられる。一部の実施態様において、ライブストリーミングデータは、識別情報によって一意に特定される。

【0054】

工程Ｓ３０２において、当該ロードバランサ５０は当該プルエッジサーバ６２を選択し、視聴者Ａからの当該配信要求を当該プルエッジサーバ６２に導く／送信する。当該ロードバランサ５０は、視聴者Ａからの当該配信要求に含まれる当該識別情報Ｓ１を、当該プルエッジサーバ６２に対応するものとしてルックアップテーブルまたはキャッシュテーブルに記録する。一部の実施態様において、当該ルックアップテーブルまたはキャッシュテーブルは当該ロードバランサ５０に実装され、管理される。

【0055】

工程Ｓ３０４において、当該プルエッジサーバ６２は視聴者Ａからの当該配信要求を当該ストリーミングデータが受信及び（または）保存される当該オリジンサーバ７０に送信する。一部の実施態様において、当該オリジンサーバ７０は、当該識別情報Ｓ１（ストリームＩＤであってもよい）により識別されるストリーミングデータを提供しているストリーマーの端末からストリーミングデータを受信するように構成される。

【0056】

工程Ｓ３０６において、当該ストリーミングデータが当該オリジンサーバ７０から当該プルエッジサーバ６２に提供される。

【0057】

工程Ｓ３０８において、当該プルエッジサーバ６２は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、視聴者によるＷｅｂＲＴＣのアクセスに対応させてもよい。

【0058】

工程Ｓ３１０において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ａに返す、または送信する。

【0059】

工程Ｓ３１２において、視聴者Ｂは当該ロードバランサ５０に対して、ストリーミングデータの配信要求を送信する。視聴者Ｂからの当該配信要求に含まれる当該識別情報は、工程Ｓ２００で視聴者Ａからの当該配信要求に含まれる当該識別情報と同じＳ１であり、これは、視聴者Ｂにより要求された当該ストリーミングデータが、視聴者Ａにより要求された当該ストリーミングデータと同じであることを示す。

【0060】

工程Ｓ３１４において、当該ロードバランサ５０は、当該キャッシュテーブルを検索し、視聴者Ｂからの当該配信要求に含まれる当該識別情報が、すでに当該キャッシュテーブルに記録されているかどうかを確認し、視聴者Ｂからの当該配信要求に含まれる当該識別情報がすでに当該キャッシュテーブルに記録されている場合、対応するプルエッジサーバを検索する。視聴者Ｂからの当該配信要求に含まれる当該識別情報もＳ１であるため、当該キャッシュテーブルにより、当該ロードバランサ５０は視聴者Ｂからの当該配信要求に含まれる当該識別情報が、視聴者Ａからの当該配信要求に含まれる当該識別情報と同じであると判断する。当該ロードバランサ５０は、視聴者Ｂからの当該配信要求に含まれる当該識別情報が当該キャッシュテーブルに存在する（工程Ｓ２０２で記録されている）と判断し、当該キャッシュテーブルに記録されている対応するプルエッジサーバ、つまり当該プルエッジサーバ６２を、視聴者Ｂのストリーミングデータアクセスのためのプルエッジサーバとして選択する。当該ロードバランサ５０は、視聴者Ｂからの当該配信要求を当該プルエッジサーバ６２に導く。

【0061】

工程Ｓ３１６において、当該プルエッジサーバ６２はトランスコードされた当該ストリーミングデータを視聴者Ｂに返す、または送信する。当該識別情報Ｓ１に対応する当該ストリーミングデータの（当該プルエッジサーバ６２への）提供処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０６ですでに実行されているため、視聴者Ｂによる同じストリーミングデータへのアクセス中にもう一度提供処理を実行する必要はない。当該識別情報Ｓ１に対応する当該ストリーミングデータのトランスコーディング処理は、視聴者Ａによる当該ストリーミングデータへのアクセス中に工程Ｓ２０８ですでに実行されているため、視聴者Ｂによるストリーミングデータへのアクセス中にもう一度トランスコーディング処理を実行する必要はない。

【0062】

工程Ｓ３１８において、視聴者Ｃはロードバランサ５０に対して、ストリーミングデータの配信要求を送信する。視聴者Ｃからの当該配信要求に含まれる当該識別情報は、工程Ｓ３００で視聴者Ａからの当該配信要求に含まれる当該識別情報Ｓ１と異なるＳ２であり、これは、視聴者Ｃにより要求された当該ストリーミングデータが、視聴者Ａにより要求された当該ストリーミングデータと異なることを示す。

【0063】

工程Ｓ３２０において、当該ロードバランサ５０は、キャッシュテーブルを検索し、視聴者Ｃからの当該配信要求に含まれる当該識別情報が、すでに当該キャッシュテーブルに記録されているかどうかを確認する。視聴者Ｃからの当該配信要求に含まれる当該識別情報Ｓ２は、当該キャッシュテーブルに記録されていないため、当該ロードバランサ５０は、視聴者Ｃからの当該配信要求に含まれる当該識別情報が当該キャッシュテーブルに存在しないと判断する。したがって、当該ロードバランサ５０は、視聴者Ｃのストリーミングデータアクセスに対するプルエッジサーバとして、当該プルエッジサーバ６２よりも多くの利用可能なリソース（ＣＰＵ、メモリ、帯域幅リソースなど）を有する当該プルエッジサーバ６４を選択する。当該ロードバランサ５０は、視聴者Ｃからの当該配信要求を当該プルエッジサーバ６４に導く。当該ロードバランサ５０は、視聴者Ｃからの当該配信要求に含まれる当該識別情報Ｓ２を、当該プルエッジサーバ６４に対応するものとして当該キャッシュテーブルに記録する。

【0064】

工程Ｓ３２２において、当該プルエッジサーバ６４は視聴者Ｃからの当該配信要求を、当該識別情報Ｓ２に対応する当該ストリーミングデータが受信及び（または）保存される当該オリジンサーバ７０に送信する。

【0065】

工程Ｓ３２４において、当該識別情報Ｓ２に対応する当該ストリーミングデータが、当該オリジンサーバ７０から当該プルエッジサーバ６４に提供される。

【0066】

工程Ｓ３２６において、当該プルエッジサーバ６２は当該ストリーミングデータをトランスコードする。例えば、当該ストリーミングデータの音声データをＡＡＣ形式からＯｐｕｓ形式にトランスコードし、視聴者によるＷｅｂＲＴＣのアクセスに対応させてもよい。

【0067】

工程Ｓ３２８において、当該プルエッジサーバ６４はトランスコードされた当該ストリーミングデータを視聴者Ａに返す、または送信する。

【0068】

一部の実施態様において、１つのストリーミングデータのトランスコード処理は、１つのプルエッジサーバのＣＰＵ使用率１％～１０％（例えば、２％）を消費する。一部の実施態様において、ストリーミングデータを要求する各視聴者へのサービス提供は、プルエッジサーバのＣＰＵ使用率０.０５％～１％（たとえば、０.１％）を消費することがある。

【0069】

一部の実施態様において、当該ロードバランサは、上述のように、最初にキャッシュテーブルに従って視聴者からの要求を分配することを試みてもよい。当該要求に含まれる当該識別情報がキャッシュテーブルにない場合、ロードバランサは均等分配モードに切り替え、最も利用可能なリソースを有するプルエッジサーバに当該要求を分配することができる。

【0070】

図４は、本発明の一部の実施態様に基づくプルエッジサーバテーブルの例示的データ構造を示す表である。当該プルエッジサーバテーブルは、当該プルエッジサーバに関する情報を格納する。特に、当該プルエッジサーバテーブルは（または、一部の実施態様において）、ライブストリーミングプラットフォームにおいて現在利用可能なライブストリームを識別するストリームＩＤと、当該利用可能なライブストリームを扱うプルエッジサーバを識別する各サーバＩＤを格納するキャッシュテーブルを含む。当該プルエッジサーバテーブルには、プルエッジサーバを識別するサーバＩＤ、各当該プルエッジサーバが扱っている現在利用可能なライブストリームを識別するストリームＩＤ、各当該プルエッジサーバのＣＰＵ使用率、各当該プルエッジサーバのメモリ使用率、当該プルエッジサーバの接続数などが格納される。当該接続数は、当該プルエッジサーバと当該ユーザ端末との間に確立されたチャネルまたは接続の数を表す。プルエッジサーバの当該接続数は、当該プルエッジサーバに接続されている当該ユーザ端末の数と同じであってもよい。

【0071】

本実施態様において、当該識別情報は、ライブストリーム（またはストリーミングデータ）を一意に識別するストリームＩＤである。例えば、サーバＩＤ「ＳＶ１」で識別されるプルエッジサーバ６２は、ストリームＩＤ「Ｓ１」で識別されるライブストリームのストリーミングデータに対応するプルエッジサーバであり、サーバＩＤ「ＳＶ２」で識別されるプルエッジサーバ６４は、ストリームＩＤ「Ｓ５」で識別されるライブストリームのストリーミングデータに対応するプルエッジサーバである。一部の実施態様において、２つの配信要求（ストリーミングデータに対する要求）は、同じストリーミングデータを要求する場合、同じストリームＩＤを有することになる。

【0072】

当該プルエッジサーバテーブル（またはキャッシュテーブル）は、当該ロードバランサ５０（または当該ロードバランサ５０の処理ユニット）が、ストリーミングデータの配信要求に含まれる当該識別情報を記憶／記録するために利用される。当該プルエッジサーバテーブル（またはキャッシュテーブル）は、当該ロードバランサ５０（または当該ロードバランサ５０の処理ユニット）によって、新たな配信要求と対応するプルエッジサーバの識別情報を検索するために利用される。

【0073】

一部の実施態様において、上述の当該キャッシュテーブル割り当て方法は、限られた数のプルエッジサーバで、サービスを提供する視聴者を動的に最大化することができる。プルエッジサーバの数、視聴者の数または予想される視聴者の数、アクセスされる異なるストリーミングデータの数、各プルエッジサーバにおけるストリーミングデータ提供のためのリソースコスト、各プルエッジサーバでストリーミングデータをトランスコードするためのリソースコストなどのパラメータが、動的な最大化処理において考慮される。例えば、上述のパラメータに基づき、システムにおける総視聴者数を最大化するように、各プルエッジサーバに対する最適な視聴者対ストリーマー（または識別情報）比を決定することができる。

【0074】

一部の実施態様において、ユーザ端末は、１以上のプロセッサを含むシステムとみなすことができ、そのうち、当該１以上のプロセッサは、機械可読命令を実行して、上述したデータアクセス処理などの処理を実行する。

【0075】

一部の実施態様において、オリジンサーバ、及び（または）ロードバランサは、ストリーミングサービスを提供するシステムに属する。一部の実施態様において、ストリーミングサービスは、スマートフォンやタブレットなどのユーザ端末上で動作するアプリケーションによってアクセスすることができる。

【0076】

図５に、本発明の一部の実施態様に基づくライブストリーミングシステム１の構成を示す概略図を示す。当該ライブストリーミングシステム１は、ストリーミングのストリーマー（ライバー、アンカー、配信者とも呼ばれる）ＬＶと視聴者（オーディエンスとも呼ばれる）ＡＵ（ＡＵ１、ＡＵ２...）に、リアルタイムで交流または通信するためのライブストリーミングサービスを提供する。図１に示すように、当該ライブストリーミングシステム１は、サーバシステム１０と、ユーザ端末２０と、ユーザ端末３０（３０ａ、３０ｂ...）を含む。一部の実施態様において、当該ストリーマーと視聴者は、集合的にユーザと呼ばれてもよい。当該サーバシステム１０は、ネットワークＮＷに接続された、１以上の情報処理装置を含むことができる。当該ユーザ端末２０、３０は、例えば、スマートフォン、タブレット、ノートＰＣ、レコーダー、携帯ゲーム機、ウェアラブル端末などのモバイル端末装置であってもよいし、デスクトップＰＣなどの据え置き型装置であってもよい。当該サーバシステム１０、当該ユーザ端末２０及び当該ユーザ端末３０は、各種有線または無線ネットワークＮＷを介して相互に通信可能に接続される。

【0077】

当該ライブストリーミングシステム１には、配信者ＬＶ、視聴者ＡＵ、及び当該サーバシステム１０を管理する管理者（またはアプリプロバイダー、図示せず）が参加する。当該配信者ＬＶは、自身のユーザ端末２０でコンテンツを記録し、当該サーバシステム１０に直接アップロードすることにより、リアルタイムで当該コンテンツを配信する者である。当該コンテンツの例としては、当該配信者自身の歌、トーク、パフォーマンス、ゲームプレイ、その他あらゆるコンテンツであってもよい。当該管理者は、当該サーバシステム１０上で当該コンテンツをライブストリーミングするためのプラットフォームを提供するとともに、当該配信者ＬＶと当該視聴者ＡＵ間のリアルタイムの交流を仲介または管理する。当該視聴者ＡＵは、自分のユーザ端末３０で当該プラットフォームにアクセスし、所望のコンテンツを選択して視聴する。当該視聴者ＡＵは、選択したコンテンツのライブストリーミング中に、当該ユーザ端末３０を介してコメントや応援、贈り物の送信などの操作を実行する。当該コンテンツを配信している当該配信者ＬＶは、それらのコメント、応援、または贈り物に対して応答してもよい。当該応答が、映像および（または）音声で当該視聴者ＡＵに送信され、双方向のコミュニケーションが確立される。

【0078】

「ライブストリーミング」という用語は、当該配信者ＬＶのユーザ端末２０で記録したコンテンツを、当該視聴者ＡＵのユーザ端末３０で実質的にリアルタイムに再生・視聴することを可能にするデータ伝送モードを指しても、そのような伝送モードにより実現されるライブブロードキャストを指してもよい。当該ライブストリーミングは、ＨＴＴＰライブストリーミング、ＣＭＡＦ（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ）、ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ―Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＲＴＭＰ（Ｒｅａｌ―Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＭＰＥＧ ＤＡＳＨなどの既存のライブストリーミング技術を利用して実現されてもよい。ライブストリーミングには、当該配信者ＬＶによるコンテンツの記録と同時に、当該視聴者ＡＵが所定の遅延をもって当該コンテンツを視聴でき伝送モードを含む。当該遅延の長さについては、当該配信者ＬＶと当該視聴者ＡＵの交流が成立可能な程度の遅延であってもよい。なお、当該ライブストリーミングは、当該コンテンツの全記録データを一度当該サーバに格納し、その後ユーザの要求に応じて当該サーバから当該ユーザに提供する、いわゆるオンデマンド配信と区別される。

【0079】

ここでいう「映像データ」とは、当該ユーザ端末２０または３０の撮像機能を用いて生成された画像データ（映像データとも呼ばれる）と、当該ユーザ端末２０または３０の音声入力機能を用いて生成された音声データとを含むデータを指す。当該映像データは、当該ユーザがコンテンツを視聴できるように、当該ユーザ端末２０、３０で再生される。一部の実施態様において、当該配信者のユーザ端末における映像データの生成と当該視聴者のユーザ端末における映像データの再生との間に、当該映像データに対して圧縮、展開、符号化、復号化、トランスコーディングなど、その形式、サイズ、またはデータの仕様を変更する処理が行われると想定される。しかし、そのような処理の前後で、当該映像データが表す当該コンテンツ（例えば、映像や音声）は実質的に変化しないため、本明細書においては、そのような処理後の当該映像データを、そのような処理前の当該映像データと同一ものと表現している。すなわち、当該配信者のユーザ端末で映像データが生成された後、当該サーバシステム１０を介して当該視聴者のユーザ端末で再生される場合、当該配信者のユーザ端末で生成された当該映像データ、当該サーバシステム１０を通過する当該映像データ、および当該視聴者のユーザ端末で受信して再生される当該映像データは、いずれも同一の映像データである。

【0080】

図５に示す例において、当該配信者ＬＶは、ライブストリーミングデータを提供する。当該配信者ＬＶのユーザ端末２０は、当該配信者ＬＶの映像や音声を記録して当該ストリーミングデータを生成し、生成された当該データは当該ネットワークＮＷを介して当該サーバシステム１０に送信される。同時に、当該ユーザ端末２０は、当該配信者ＬＶの記録された映像ＶＤを当該ユーザ端末２０のディスプレイに表示し、当該配信者ＬＶが現在行っているライブストリーミングコンテンツを確認できるようにする。

【0081】

当該プラットフォームに当該配信者ＬＶのライブストリーミングを視聴することを要求した当該視聴者ＡＵ１、ＡＵ２のそれぞれのユーザ端末３０ａ、３０ｂは、当該ネットワークＮＷを介して当該ライブストリーミングに関連する映像データ（以下、「ライブストリーミングの映像データ」と呼ばれてもよい）を受信し、受信した当該映像データを再生して当該映像ＶＤ１、ＶＤ２をディスプレイに表示し、スピーカーから音声を出力する。当該ユーザ端末３０ａ、３０ｂでそれぞれ表示される映像ＶＤ１、ＶＤ２は、当該配信者ＬＶの当該ユーザ端末２０により撮像された映像ＶＤと実質的に同じであり、当該ユーザ端末３０ａ、３０ｂで出力される音声は、当該配信者ＬＶの当該ユーザ端末２０で記録された音声と実質的に同じである。

【0082】

当該配信者ＬＶの当該ユーザ端末２０での映像・音声の記録と、当該視聴者ＡＵ１、ＡＵ２の当該ユーザ端末３０ａ、３０ｂでの映像データの再生は、実質的に同時に行われる。当該視聴者ＡＵ１が、当該配信者ＬＶにより提供される当該コンテンツに関するコメントを当該ユーザ端末３０ａに入力すると、当該サーバシステム１０は当該コメントを配信者ＬＶの当該ユーザ端末３０ａにリアルタイムで表示するとともに、当該視聴者ＡＵ１とＡＵ２の当該ユーザ端末３０ａと３０ｂにも当該コメントをそれぞれ表示する。当該配信者ＬＶが当該コメントを読み、当該コメントに対応するトークを展開すると、そのトークの映像と音声が、それぞれ当該視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂに表示される。このインタラクティブな動作は、当該配信者ＬＶと当該視聴者ＡＵ１間で会話が成立していると認識される。これにより、当該ライブストリーミングシステム１では、一方的なコミュニケーションではなく、双方向のコミュニケーションを可能にするライブストリーミングを実現する。

【0083】

図６は、本発明の一部の実施態様に基づく、図５のユーザ端末３０の機能と構成を示すブロック図である。当該ユーザ端末２０は、当該ユーザ端末３０と同じまたは類似した機能と構成を有する。図６の各ブロックと以降のブロック図は、ハードウェアがコンピュータのＣＰＵや機械装置などの要素によって実現されてもよく、ソフトウェアがコンピュータプログラムなどによって実現されてもよい。機能ブロックは、これらの要素間の連携動作により実現されてもよい。したがって、これらの機能ブロックは、ハードウェアとソフトウェアの組み合わせによる多様な形態で実現され得ることが、当業者には理解されよう。

【0084】

当該配信者ＬＶ及び当該視聴者ＡＵは、当該ネットワークＮＷを介してダウンロードサイトからライブストリーミングアプリケーションプログラム（以下、ライブストリーミングアプリケーションという）をダウンロードし、当該ユーザ端末２０、３０にインストールしてもよい。あるいは、当該ライブストリーミングアプリケーションは、当該ユーザ端末２０と３０に予めインストールされていてもよい。当該ライブストリーミングアプリケーションが当該ユーザ端末２０、３０上で実行されると、当該ユーザ端末２０、３０は、当該ネットワークＮＷを介して当該サーバシステム１０と通信し、各種機能を実装または実行する。以下、当該ライブストリーミングアプリケーションが実行されるユーザ端末２０、３０（ＣＰＵなどのプロセッサ）によって実装される機能を、当該ユーザ端末２０、３０の機能として説明する。これらの機能は、実際には、当該ユーザ端末２０、３０上で当該ライブストリーミングアプリケーションにより実現される。一部の実施態様において、これらの機能は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などのプログラミング言語で記述され、当該サーバシステム１０から当該ネットワークＮＷを介して当該ユーザ端末２０、３０のウェブブラウザに送信され、当該ウェブブラウザにより実行されるコンピュータプログラムによって実現されてもよい。

【0085】

当該ユーザ端末３０は、配信ユニット１００と視聴ユニット２００を含む。当該配信ユニット１００は、当該ユーザの映像と音声が記録された映像データを生成し、当該映像データを当該サーバシステム１０に提供する。当該視聴ユニット２００は、当該サーバシステム１０から映像データを受信し、当該映像データを再生する。当該ユーザは、ライブストリーミングを行う際に、当該配信ユニット１００を起動し、当該ユーザが映像を視聴する際に、当該視聴ユニット２００を起動する。当該配信ユニット１００が起動される当該ユーザ端末は、当該配信者の端末、すなわち、当該映像データを生成する当該ユーザ端末である。当該視聴ユニット２００が起動される当該ユーザ端末は、当該視聴者の端末、即ち、当該映像データが再現され、再生される当該ユーザ端末である。

【0086】

当該配信ユニット１００は、撮像コントロールユニット１０２と、オーディオコントロールユニット１０４と、映像送信ユニット１０６と、配信者側ＵＩコントロールユニット１０８を含む。当該撮像コントロールユニット１０２は、カメラ（図２に表示せず）に接続され、当該カメラで実行される撮像を制御する。当該撮像コントロールユニット１０２は、当該カメラからの画像データを取得する。当該オーディオコントロールユニット１０４は、マイク（図２に表示せず）に接続され、当該マイクからの音声入力を制御する。当該オーディオコントロールユニット１０４は、当該マイクから当該オーディオデータを取得する。当該映像送信ユニット１０６は、当該撮像コントロールユニット１０２により取得された当該画像データと、当該オーディオコントロールユニット１０４により取得された当該オーディオデータを含む映像データを、当該ネットワークＮＷを介して当該サーバシステム１０に送信する。当該映像データは、当該映像送信ユニット１０６によりリアルタイムに送信される。すなわち、当該撮像コントロールユニット１０２と当該オーディオコントロールユニット１０４による当該映像データの生成と、生成された当該映像データの当該映像送信ユニット１０６による送信とは、実質的に同時に実行される。当該配信者側ＵＩコントロールユニット１０８は、当該配信者のＵＩ（ユーザインターフェイス）をコントロールする。当該配信者側ＵＩコントロールユニット１０８は、ディスプレイ（表示せず）に接続され、当該映像送信ユニット１０６により送信される当該映像データを再生することにより、当該ディスプレイに映像を表示する。当該配信者側ＵＩコントロールユニット１０８は、操作オブジェクトや指示許諾オブジェクトを当該ディスプレイに表示し、当該オブジェクトをタップした当該配信者からの入力を受け付けてもよい。

【0087】

当該視聴ユニット２００は、視聴者側ＵＩコントロールユニット２０２と、重ね合わせ情報生成ユニット２０４と、入力情報送信ユニット２０６を含む。当該視聴ユニット２００は、当該ネットワークＮＷを介して当該サーバシステム１０から、配信者、当該ユーザ端末３０のユーザである視聴者、及び他の視聴者が参加する、ライブストリーミングに関連する映像データを受信する。当該視聴者側ＵＩコントロールユニット２０２は、当該視聴者のＵＩを制御する。当該視聴者側ＵＩコントロールユニット２０２は、ディスプレイとスピーカー（表示せず）に接続され、受信した映像データを再生して、当該ディスプレイに映像を表示し、当該スピーカーから音声を出力する。当該映像が当該ディスプレイに出力され、当該音声が当該スピーカーから出力されている状態を「映像データが再生されている」状態と呼ぶことができる。当該視聴者側ＵＩコントロールユニット２０２は、タッチパネル、キーボード、ディスプレイ等の入力手段（表示せず）にも接続され、当該入力手段を介してユーザの入力を取得する。当該重ね合わせ情報生成ユニット２０４は、当該サーバシステム１０からの映像データから生成された画像上に、所定のフレーム画像を重ねる。当該フレーム画像には、当該ユーザからの入力を受け付けるためのさまざまなユーザインターフェイスオブジェクト（以下、単に「オブジェクト」という）、当該視聴者により入力されたコメント、当該サーバシステム１０から取得した情報などが含まれる。当該入力情報送信ユニット２０６は、当該ネットワークＮＷを介して、当該視聴者側ＵＩコントロールユニット２０２により取得された当該ユーザ入力を当該サーバシステム１０に送信する。

【0088】

図１１は、本発明の一部の実施態様に基づく、図５のサーバシステム１０の機能と構成を示すブロック図である。当該サーバシステム１０は、オリジンサーバ７０と、３つのプルエッジサーバ６２、６４、６６と、ロードバランサ５０と、コントロールサーバ１００とを含む。図１１に示すサーバの構成及び台数は、例示のためのものであり、本発明はこの構成に限定されるものではない。当該オリジンサーバ７０は、現在ストリーマーによって行われているライブストリームのライブストリーミングデータを生成している複数のストリーマーのユーザ端末に接続されている。当該オリジンサーバ７０は、ネットワークＮＷを介して、当該ストリーマーのユーザ端末から、当該ライブストリームのライブストリーミングデータを受信する。当該オリジンサーバ７０は、当該サーバシステム１０内の当該３つのプルエッジサーバ６２、６４、６８と接続されている。当該ロードバランサ５０は、当該３つのプルエッジサーバ６２、６４、６６に接続され、これらを制御する。当該ロードバランサ５０は、ネットワークＮＷを介して複数の視聴者のユーザ端末に接続され、当該視聴者のユーザ端末から配信要求を受信する。当該ロードバランサ５０は、当該プルエッジサーバ６２、６４、６６と当該視聴者端末との間に確立された当該接続を制御または管理する。当該プルエッジサーバ６２、６４、６６は、当該ネットワークＮＷを介して、当該視聴者のユーザ端末に接続されてもよい。

【0089】

当該オリジンサーバ７０と当該プルエッジサーバ６２、６４、６６は、当該ストリーマーのユーザ端末からの映像データをライブストリーミングで当該視聴者のユーザ端末に集合的に中継する。図２または図３に示す実施態様と同様に、配信要求（ストリームＩＤを含む）が、当該視聴者のユーザ端末から当該ロードバランサ５０に送信される。その後、当該ロードバランサ５０が、当該オリジンサーバ７０から当該ライブストリーム（当該ストリームＩＤで指定される）を取り込むプルエッジサーバとして、１つのプルエッジサーバを割り当てる、または指定する。具体的に、当該ロードバランサ５０は、当該プルエッジサーバに当該配信要求を送信する。当該プルエッジサーバは、当該オリジンサーバ７０に当該ライブストリーミングデータを要求する。その後、当該プルエッジサーバが、要求元の当該視聴者のユーザ端末に当該ライブストリーミングデータを提供する。図１１に、図３に対応する例示的な接続を示す。視聴者Ａの端末及び視聴者Ｂの端末は、当該オリジンサーバ７０及び当該プルエッジサーバ６２を介して、ストリーマーＸのライブストリーミングのライブストリーミングデータを受信する。視聴者Ｃの端末は、当該オリジンサーバ７０及び当該プルエッジサーバ６４を通じて、ストリーマーＹのライブストリーミングのライブストリーミングデータを受信する。

【0090】

図７に、本発明の一部の実施態様に基づく、図１１のコントロールサーバ１００の機能と構成を示すブロック図を示す。当該コントロールサーバ１００は、配信情報提供ユニット３０２と、中継ユニット３０４と、贈り物処理ユニット３０６と、支払い処理ユニット３０８と、ストリームＤＢ３１０と、ユーザＤＢ３１２と、贈り物ＤＢ３１４を含む。

【0091】

当該配信者側の当該ユーザ端末２０から当該ネットワークＮＷを介してライブストリーミング（またはライブストリーミング番組）の開始通知または要求を受信すると、当該配信情報提供ユニット３０２は、このライブストリーミングを識別するためのストリームＩＤと当該ライブストリーミングを行う配信者の配信者ＩＤをストリームＤＢ３１０に登録する。

【0092】

当該配信情報提供ユニット３０２が、当該ネットワークＮＷを介して当該視聴者側の当該ユーザ端末３０の当該視聴ユニット２００からライブストリームに関する情報の提供要求を受信すると、当該配信情報提供ユニット３０２は、当該ストリームＤＢ３１０から現在利用可能なライブストリームを取得または確認し、利用可能なライブストリームのリストを作成する。当該配信情報提供ユニット３０２は、作成したリストを当該ネットワークＮＷ経由で要求元の当該ユーザ端末３０に送信する。要求元の当該ユーザ端末３０の当該視聴者側ＵＩコントロールユニット２０２は、受信したリストに基づいてライブストリーム選択画面を生成し、当該ユーザ端末３０のディスプレイ上に表示する。

【0093】

一部の実施態様において、ユーザ端末３０は、当該配信情報提供部３０２が生成したリストから、利用可能なライブストリームの識別情報（ストリームＩＤなど）を受信する。

【0094】

当該ユーザ端末３０の当該入力情報送信ユニット２０６が、当該ライブストリーム選択画面上で当該視聴者の選択結果を受信すると、当該入力情報送信ユニット２０６は、選択されたライブストリームのストリームＩＤを含む配信要求を生成し、当該ネットワークＮＷを介して当該サーバシステム１０の当該ロードバランサ５０に当該配信要求を送信する。当該ロードバランサ５０は、要求元の当該ユーザ端末３０にプルエッジサーバを割り当てる。割り当てられた当該プルエッジサーバは、要求元の当該ユーザ端末３０に対して、受信した当該配信要求に含まれる当該ストリームＩＤで指定されるライブストリームの提供を開始する。当該配信情報提供ユニット３０２は、当該ストリームＩＤの（または対応する）視聴者ＩＤに、要求元の当該ユーザ端末３０の当該視聴者のユーザＩＤを含めるように当該ストリームＤＢ３１０を更新する。

【0095】

当該中継ユニット３０４は、当該ライブストリーミング中または当該映像データの再生中に、当該入力情報送信ユニット２０６から視聴者によるユーザ入力を表す信号を受信する。当該ユーザ入力を表す信号は、当該ユーザ端末３０のディスプレイに表示されたオブジェクトを指定するオブジェクト指定信号であってもよく、当該オブジェクト指定信号は、当該視聴者の視聴者ＩＤ、当該視聴者が視聴するライブストリームの配信者ＩＤ、及び当該オブジェクトを識別するオブジェクトＩＤを含む。当該オブジェクトが贈り物であるとき、当該オブジェクトＩＤは贈り物ＩＤである。同様に、当該中継ユニット３０４、当該ユーザ端末２０の配信ユニット１００から、オブジェクト指定信号のように、当該映像データの再生中に配信者により行われたユーザ入力を表す信号（オブジェクト指定信号など）を受信する。

【0096】

また、当該ユーザ入力を表す信号は、視聴者が当該ユーザ端末３０に入力したコメントと当該視聴者の視聴者ＩＤを含むコメント入力信号であってもよい。当該コメント入力信号を受信すると、当該中継ユニット３０４は、当該コメントと信号に含まれる当該視聴者ＩＤを、当該配信者の当該ユーザ端末２０と他の視聴者の当該ユーザ端末３０に送信する。これらユーザ端末２０、３０において、当該視聴者側ＵＩコントロールユニット２０２と、当該重ね合わせ情報生成ユニット２０４は、同じく受信した当該視聴者ＩＤと関連付けられたディスプレイ上に受信したコメントを表示する。

【0097】

当該贈り物処理ユニット３０６は、当該オブジェクト指定信号に含まれる贈り物ＩＤによって特定される贈り物のポイントに基づき、当該配信者のポイントを増加させ、当該ユーザＤＢ３１２を更新する。具体的には、当該贈り物処理ユニット３０６は、当該贈り物ＤＢ３１４を参照して、受信した当該オブジェクト指定信号に含まれる当該贈り物ＩＤに対して付与するポイントを特定する。その後、当該贈り物処理ユニット３０６は、当該ユーザＤＢ３１２を更新し、当該オブジェクト指定信号に含まれる当該配信者ＩＤのポイントに、特定されたポイントを追加する。

【0098】

当該支払い処理ユニット３０８は、当該オブジェクト指定信号の受信に応答して、視聴者による贈り物の代金の支払いを処理する。具体的には、当該支払い処理ユニット３０８は、当該贈り物ＤＢ３１４を参照して、当該オブジェクト指定信号に含まれる当該贈り物ＩＤにより特定される当該贈り物の価格ポイントを特定する。その後、当該支払い処理ユニット３０８は、当該ユーザＤＢ３１２を更新し、当該オブジェクト指定信号に含まれる当該視聴者ＩＤにより特定される当該視聴者のポイントから、特定された当該価格ポイントを差し引く。

【0099】

図８は、ストリームＤＢ３１０の例示的データ構造を示す表である。当該ストリームＤＢ３１０は、現在行われているライブストリーム（またはライブストリーミング番組）に関する情報を保持する。当該ストリームＤＢ３１０は、ストリームＩＤ、配信者ＩＤ、および視聴者ＩＤを、相互に関連付けて格納する。当該ストリームＩＤは、当該ライブストリーミングシステム１により提供されるライブストリーミングプラットフォームにおけるライブストリームを識別するためのＩＤである。当該配信者ＩＤは、当該ライブストリームを提供する配信者を識別するためのユーザＩＤである。当該視聴者ＩＤは、当該ライブストリームの視聴者を識別するためのユーザＩＤである。一部の実施態様による当該ライブストリーミングシステム１により提供されるライブストリーミングプラットフォームにおいて、ユーザがライブストリームを開始すると、当該ユーザは配信者となり、同じユーザが別のユーザによりブロードキャストされるライブストリームを視聴すると、当該ユーザは視聴者にもなる。したがって、配信者と視聴者の区別は固定されておらず、あるとき配信者ＩＤとして登録されたユーザＩＤが、別のときに視聴者ＩＤとして登録されることもあり得る。

【0100】

図９は、ユーザＤＢ３１２の例示的データ構造を示す表である。当該ユーザＤＢ３１２は、ユーザに関する情報を保持する。当該ユーザＤＢ３１２は、ユーザＩＤおよびポイントを、相互に関連付けて格納する。または、当該ユーザＤＢ３１２は、ユーザＩＤとポイントの組を相互に対応させて格納する。当該ユーザＩＤは、ユーザを識別する。当該ポイントは、対応する当該ユーザが有するポイントに相当する。当該ポイントは、当該ライブストリーミングプラットフォーム内で流通する電子的な価値である。一部の実施態様において、配信者がライブストリーム中に視聴者から贈り物を受け取ると、当該配信者のポイントは当該贈り物に対応する価値だけ増加する。当該ポイントは、例えば、当該配信者が当該ライブストリーミングプラットフォームの管理者から受け取る報酬（金銭など）の量を決定するために使用される。あるいは、当該配信者が視聴者から贈り物を受け取る際に、当該ポイントに代えて、当該贈り物に対応する金額を付与してもよい。

【0101】

図１０は、贈り物ＤＢ３１４の例示的データ構造を示す表である。当該贈り物ＤＢ３１４は、当該ライブストリーミング中に当該視聴者が利用できる贈り物についての情報を保持する。贈り物は、電子データである。贈り物は、ポイントまたは金銭で購入するか、無償で提供することができてもよい。贈り物は、視聴者が配信者に贈ることができる。配信者に贈り物を贈ることは、贈り物を使う、贈り物を送る、贈り物を投げるなどとも呼ばれる。贈り物の中には、購入と同時に使用できるものと、購入後、購入した視聴者が後から任意のタイミングで使用できるものとがある。視聴者が配信者に贈り物を贈ると、当該贈り物に対応する量のポイントが当該配信者に付与される。贈り物が使用されると、その使用によって当該贈り物に関連するエフェクトが発生してもよい。例えば、ライブストリーミング画面に当該贈り物に対応したエフェクト（視覚的効果や聴覚的効果など）が表示される。

【0102】

当該贈り物ＤＢ３１４は、贈り物ＩＤ、付与ポイント、価格ポイントを、相互に関連付けて格納する。当該贈り物ＩＤは、贈り物を識別するためのものである。当該付与ポイントは、配信者に贈り物が贈られたときに当該配信者に付与されるポイントの量である。当該価格ポイントは、贈り物の使用（購入）に対して支払われるポイントの量である。視聴者は、ライブストリームを視聴しているときに、所望の贈り物の当該価格ポイントを支払うことで、配信者に当該所望の贈り物を贈ることができる。当該価格ポイントの支払いは、適宜の電子決済手段により行うことができる。例えば、視聴者が管理者に当該価格ポイントを支払うことにより、支払いが行われてもよい。あるいは、銀行振り込みやクレジットカードによる支払いが利用されてもよい。当該管理者は、当該付与ポイントと当該価格ポイントとの関係を任意に設定することができる。例えば、付与ポイント＝価格ポイントとして設定してもよい。あるいは、当該付与ポイントに１.２などの所定の係数を乗じたポイントを当該価格ポイントとして設定しても、当該付与ポイントに所定の手数料ポイントを加算したポイントを当該価格ポイントとして設定してもよい。

【0103】

図１２に、本発明の一部の実施態様に基づく、図１１のロードバランサ５０の機能と構成を示すブロック図を示す。当該ロードバランサ５０は、受信ユニット５０２と、決定ユニット５０４と、接続ユニット５０６と、プルエッジサーバテーブルを含む。当該受信ユニット５０２は、当該視聴者のユーザ端末から、ネットワークＮＷを介して、当該視聴者が選択したライブストリームのストリームＩＤを含む当該配信要求を受信するように構成されている。当該決定ユニットは、当該配信要求の受信に応答して、当該プルエッジサーバテーブルを参照し、受信した当該配信要求に含まれるストリームＩＤによって特定されるライブストリームを取り扱うプルエッジサーバを決定するように構成されている。当該接続ユニットは、決定された当該プルエッジサーバに、要求元の当該視聴者のユーザ端末に対して、当該ライブストリームのライブストリーミングデータを送信させるように構成されている。

【0104】

図１３に、当該ロードバランサ５０に実装される例示的な工程を示すフローチャートを示す。工程Ｓ１３０２において、当該受信ユニット５０２が要求元のユーザ端末からの配信要求を受信する。工程Ｓ１３０４において、当該決定ユニット５０４が受信した当該配信要求からストリームＩＤを抽出する。工程Ｓ１３０６において、当該決定ユニット５０４は、当該プルエッジサーバテーブルを参照し、抽出された当該ストリームＩＤが当該プルエッジサーバテーブルに格納されているか否かを判定する。抽出された当該ストリームＩＤがテーブルに格納されている場合（工程Ｓ１３０６で「はい」）、工程Ｓ１３０８において、決定ユニット５０４が、抽出された当該ストリームＩＤのライブストリームを取り扱うプルエッジサーバを特定する。具体的に、決定ユニット５０４は、当該プルエッジサーバテーブルで、抽出された当該ストリームＩＤに対応するプルエッジサーバを特定する。例えば、図４に示す例において抽出された当該ストリームＩＤが「Ｓ１」である場合、当該決定ユニット５０４は、抽出された当該ストリームＩＤ「Ｓ１」のライブストリームを取り扱うプルエッジサーバとして、「ＳＶ１」を特定する。工程Ｓ１３１０において、当該接続ユニット５０６は、ネットワークＮＷを介して、特定された当該プルエッジサーバおよび要求元の当該ユーザ端末と通信することにより、特定された当該プルエッジサーバと要求元の当該ユーザ端末の間の接続を確立させる。その後、特定された当該プルエッジサーバが、確立された当該接続を通じて、要求されたライブストリームのライブストリーミングデータを要求元の当該ユーザ端末に送信し始める。

【0105】

抽出された当該ストリームＩＤがテーブルに格納されていない場合（工程Ｓ１３０６で「いいえ」）、工程Ｓ１３１２で、当該決定ユニット５０４は、当該プルエッジサーバテーブルを参照し、負荷分散アルゴリズムに従って、複数のプルエッジサーバから１つのプルエッジサーバを選択する。当該アルゴリズムは、上述したように、ＣＰＵ使用率またはメモリ使用率、あるいは接続数に基づいてもよい。工程Ｓ１３１４において、当該決定ユニット５０４は、選択された当該プルエッジサーバと抽出された当該ストリームＩＤを当該プルエッジサーバテーブルに登録する。例えば、図４に示す例において、工程Ｓ１３１２で、抽出された当該ストリームＩＤが「Ｓ１２」で、プルエッジサーバ「ＳＶ２」が選択された場合、当該決定ユニット５０４は、当該プルエッジサーバテーブルのサーバＩＤ「ＳＶ２」に対応するストリームＩＤのセルに、抽出された当該ストリームＩＤ「Ｓ１２」を追加する。

【0106】

工程Ｓ１３１０において、当該接続ユニット５０６は、ネットワークＮＷを介して、選択された当該プルエッジサーバおよび要求元の当該ユーザ端末と通信することにより、選択された当該プルエッジサーバと要求元の当該ユーザ端末の間の接続を確立させる。その後、選択された当該プルエッジサーバは、当該オリジンサーバ７０に要求された当該ライブストリームのライブストリーミングデータを要求する。当該オリジンサーバ７０は、選択された当該プルエッジサーバに、当該ライブストリーミングデータを提供する。その後、選択された当該プルエッジサーバは、確立された当該接続を通じて、要求された当該ライブストリームのライブストリーミングデータを、要求元の当該ユーザ端末に送信し始める。

【0107】

図１３に示す例において、工程Ｓ１３０８での当該プルエッジサーバの特定は、ＣＰＵ使用率やメモリ使用率などの他のサーバステータスに無関係に行われる。しかし、別の実施態様において、当該決定ユニットは、プルエッジサーバを特定する際に、抽出された当該ストリームＩＤに加えて、サーバステータスを考慮に入れてもよい。例えば、当該決定ユニットは、抽出された当該ストリームＩＤのライブストリームを取り扱うプルエッジサーバを最初に特定してもよい。その後、当該決定ユニットは、特定した当該プルエッジサーバの接続数が閾値を超えるか否かを判断する。超えている場合、当該決定ユニットは特定をキャンセルし、工程Ｓ１３１２に進んでもよい。超えていない場合は、工程Ｓ１３１０に進んでもよい。この変化例は、有名なストリーマーのライブストリームが行われ、膨大な数の視聴者が同時にライブストリームのアクセスを要求する場合に有益である。各プルエッジサーバの接続数が閾値より低く抑えられるため、プルエッジサーバが過負荷になるリスクが少ない。

【0108】

上記実施態様によれば、特定のライブストリーミングのためのユーザ端末との接続が、特定のプルエッジサーバに集中される。したがって、当該オリジンサーバ７０と当該プルエッジサーバ間の特定のライブストリーミングのための接続数をできるだけ少なくすることができ、当該オリジンサーバ７０の過負荷を防止するために有益である。

【0109】

一部の実施態様において、図２と図３に示す視聴者Ａ、Ｂ、Ｃは、図５に示すユーザ端末３０に対応する。一部の実施態様において、当該ロードバランサ５０は、図１１に示す当該オリジンサーバ７０または当該プルエッジサーバ６２、６４または６６、あるいは当該コントロールサーバの一部として実装されてもよい。一部の実施態様において、図１１に示す当該プルエッジサーバ６２、６４、６６は、図１１に示す当該オリジンサーバ７０または当該コントロールサーバ１００の一部として実装されてもよい。

【0110】

一部の実施態様において、ストリーマーがライブストリーミングを終了すると、当該オリジンサーバ７０は、当該ライブストリーミングの終了を検出してもよい。当該オリジンサーバ７０は、終了した当該ライブストリーミングのストリームＩＤを含む終了要求を当該ロードバランサ５０に送信してもよい。当該ロードバランサ５０は、当該終了要求の受信に応答し、当該プルエッジサーバテーブルを更新して、当該終了要求に含まれる当該ストリームＩＤを当該テーブルから削除してもよい。

【0111】

本発明で説明した処理及び手順は、明示的に説明したものに加えて、ソフトウェア、ハードウェア、またはそれらの任意の組み合わせにより実現することができる。例えば、本明細書で説明した処理および手順は、その処理および手順に対応するロジックを集積回路、揮発性メモリ、不揮発性メモリ、非一過性のコンピュータ可読媒体、磁気ディスクなどの媒体に実装することにより実現することができる。さらに、本明細書に記載された処理および手順は、その処理および手順に対応するコンピュータプログラムとして実現することができ、各種のコンピュータにより実行することができる。

【0112】

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

【0113】

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

【符号の説明】

【0114】

１ 通信システム
１０ サーバシステム
２０ ユーザ端末
３０、３０ａ、３０ｂ ユーザ端末
ＬＶ 配信者
ＡＵ１、ＡＵ２ 視聴者
ＶＤ、ＶＤ１、ＶＤ２ 映像
ＮＷ ネットワーク
３０ ユーザ端末
１００ 配信ユニット
１０２ 撮像コントロールユニット
１０４ オーディオコントロールユニット
１０６ 映像送信ユニット
１０８ 配信者側ＵＩコントロールユニット
２００ 視聴ユニット
２０２ 視聴者側ＵＩコントロールユニット
２０４ 重ね合わせ情報生成ユニット
２０６ 入力情報送信ユニット
３０２ 配信情報提供ユニット
３０４ 中継ユニット
３０６ 贈り物処理ユニット
３０８ 支払い処理ユニット
３１０ ストリームＤＢ
３１２ ユーザＤＢ
３１４ 贈り物ＤＢ
５０ ロードバランサ
５０２ 受信ユニット
５０４ 決定ユニット
５０６ 接続ユニット
７０ オリジンサーバ
９０ ネットワーク
６２、６４、６６ プルエッジサーバ
１００ コントロールサーバ
Ｓ１００、Ｓ１０２、Ｓ１０４、Ｓ１０６、Ｓ１０８、Ｓ１１０、Ｓ１１２、Ｓ１１４ 工程
Ｓ１１６、Ｓ１１８、Ｓ１２０、Ｓ１２２、Ｓ１２４、Ｓ１２６、Ｓ１２８、Ｓ１３０、Ｓ１３２、Ｓ１３４ 工程
Ｓ２００、Ｓ２０２、Ｓ２０４、Ｓ２０６、Ｓ２０８、Ｓ２１０ 工程
Ｓ２１２、Ｓ２１４、Ｓ２１６、Ｓ２１８、Ｓ２２０、Ｓ２２２ 工程
Ｓ３００、Ｓ３０２、Ｓ３０４、Ｓ３０６、Ｓ３０８、Ｓ３１０、Ｓ３１２、Ｓ３１４ 工程
Ｓ３１６、Ｓ３１８、Ｓ３２０、Ｓ３２２、Ｓ３２４、Ｓ３２６、Ｓ３２８ 工程
Ｓ１３００、Ｓ１３０２、Ｓ１３０４、Ｓ１３０６、Ｓ１３０８、Ｓ１３１０、Ｓ１３１２、Ｓ１３１４ 工程

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】