IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ベノワ・フレデッテの特許一覧 ▶ ヴェンカタ・ガネサンの特許一覧

<>
  • 特表-仮想会場 図1
  • 特表-仮想会場 図2A
  • 特表-仮想会場 図2B
  • 特表-仮想会場 図3A
  • 特表-仮想会場 図3B
  • 特表-仮想会場 図4
  • 特表-仮想会場 図5
  • 特表-仮想会場 図6
  • 特表-仮想会場 図7
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-09-04
(54)【発明の名称】仮想会場
(51)【国際特許分類】
   H04N 21/2668 20110101AFI20230828BHJP
   H04N 21/472 20110101ALI20230828BHJP
   H04N 5/222 20060101ALI20230828BHJP
【FI】
H04N21/2668
H04N21/472
H04N5/222 400
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022563205
(86)(22)【出願日】2021-04-19
(85)【翻訳文提出日】2022-12-19
(86)【国際出願番号】 CA2021050529
(87)【国際公開番号】W WO2021207859
(87)【国際公開日】2021-10-21
(31)【優先権主張番号】63/011,520
(32)【優先日】2020-04-17
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.FLASH
2.Windows Media
3.Quicktime
4.Real Video
5.Shock Wave
(71)【出願人】
【識別番号】517405415
【氏名又は名称】ベノワ・フレデッテ
(71)【出願人】
【識別番号】522406171
【氏名又は名称】ヴェンカタ・ガネサン
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ベノワ・フレデッテ
(72)【発明者】
【氏名】ヴェンカタ・ガネサン
【テーマコード(参考)】
5C122
5C164
【Fターム(参考)】
5C122DA37
5C122EA59
5C122FA18
5C122FK23
5C122FK24
5C122FK36
5C122FK42
5C122FK43
5C122GC04
5C122GC06
5C122GC14
5C122GC17
5C122GC32
5C122GC41
5C122GC53
5C122GC55
5C122GC77
5C122HB01
5C122HB05
5C164FA06
5C164SA25S
5C164SC05P
5C164UD41P
(57)【要約】
ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求が、通信ネットワークを介して複数のデバイスから受信される。1つまたは複数の要求に基づいて、複数のデバイスの第1のサブセットは、通信ネットワークを介して、ライブマルチメディアコンテンツを備えるストリームへのアクセスを提供され、ストリームはある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される。複数のデバイスの第2のサブセットは、デバイスの第1のサブセットの中から繰り返し選択され、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号は、物理位置において提供される画面上の所与の場所において、リアルタイムでレンダリングされるようにされ、所与の場所に応じて、デバイスの第2のサブセットは、通信ネットワークを介して、複数のカメラのうちの選択された1つからのカメラフィード信号へのアクセスを与えられる。
【特許請求の範囲】
【請求項1】
メモリと、
プロセッサと、
前記メモリに記憶されたアプリケーションとを備え、前記アプリケーションが、
通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信することと、
前記1つまたは複数の要求に基づいて、前記複数のデバイスアクセスの第1のサブセットを、前記通信ネットワークを介して、前記ライブマルチメディアコンテンツを備えるストリームに提供することであって、前記ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、提供することと、
デバイスの前記第1のサブセットの中から、前記複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの前記第2のサブセットの中の各デバイスのウェブカメラフィード信号が、前記物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、前記所与の場所に応じて、デバイスアクセスの前記第2のサブセットを、前記通信ネットワークを介して、前記複数のカメラのうちの選択された1つからのカメラフィード信号に提供すること
のために、前記プロセッサによって実行可能である、システム。
【請求項2】
デバイスの前記第2のサブセットの中の各デバイスに対して、前記アプリケーションが、前記デバイスによって生成されるオーディオおよびビデオ信号が前記物理位置において前記ライブイベントを実行する演者に向けられるようにするために、前記プロセッサによって実行可能であり、前記オーディオおよびビデオ信号が前記所与の場所に応じて前記演者に向けられる、請求項1に記載のシステム。
【請求項3】
前記アプリケーションが、デバイスの前記第2のサブセットの中から少なくとも1つのデバイスを選択することと、前記少なくとも1つのデバイスおよび前記少なくとも1つの画面を通じて、前記少なくとも1つのデバイスのユーザと前記物理位置において前記ライブイベントを実行する演者との間のリアルタイムの交流を可能にすることのために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項4】
前記アプリケーションが、デバイスアクセスの前記第2のサブセットを、前記通信ネットワークを介して、前記複数のカメラのうちの他のカメラからのカメラフィード信号に提供するために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項5】
前記アプリケーションが、デバイスの前記第1のサブセットの中からデバイスの前記第2のサブセットとなるデバイスの新しいサブセットを選択するために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項6】
前記アプリケーションが、所定の期間が経過した後でデバイスの前記新しいサブセットを選択するために、前記プロセッサによって実行可能である、請求項5に記載のシステム。
【請求項7】
前記アプリケーションが、入札手続の間に、ユーザ固有の基準に基づいて前記ライブマルチメディアコンテンツへのアクセスを獲得するための1つまたは複数の応札をリアルタイムで受信することを備える1つまたは複数の要求を受信することと、前記1つまたは複数の応札に基づいて、デバイスの前記第1のサブセットおよびデバイスの前記第2のサブセットを選択し、前記ストリームへのアクセスを提供することのために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項8】
前記アプリケーションが、少なくとも1つのストリーミングサーバに、所定の時間遅延を前記ストリームへ導入させ、前記通信ネットワークを介して、前記所定の時間遅延を有する前記ストリームをデバイスの前記第1のサブセットへ放送させることと、前記少なくとも1つのストリーミングサーバに、前記ストリームから前記所定の時間遅延を取り除かせ、前記通信ネットワークを介して、前記所定の時間遅延が取り除かれた前記ストリームをデバイスの前記第2のサブセットへ放送させることのために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項9】
前記アプリケーションが、前記ライブマルチメディアコンテンツがデバイスの前記第1のサブセットおよびデバイスの前記第2のサブセットの各デバイスに提示されるグラフィカルユーザインターフェースにレンダリングされるようにすることと、デバイスの前記第2のサブセットの中の各デバイスの前記ウェブカメラフィード信号が前記グラフィカルユーザインターフェースにレンダリングされるようにすることのために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項10】
前記アプリケーションが、前記ウェブカメラフィード信号を共有することに対する招待状をデバイスの前記第2のサブセットの中の各デバイスにリアルタイムで送信することと、前記ウェブカメラフィード信号が前記画面上の前記所与の場所にレンダリングされるようにし、前記招待状の受け入れの標示を受信するとデバイスアクセスの前記第2のサブセットを前記カメラフィード信号に提供することのために、前記プロセッサによって実行可能である、請求項1に記載のシステム。
【請求項11】
コンピュータで実施される方法であって、プロセッサにおいて、
通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信するステップと、
前記1つまたは複数の要求に基づいて、前記複数のデバイスアクセスの第1のサブセットを、前記通信ネットワークを介して、前記ライブマルチメディアコンテンツを備えるストリームに提供するステップであって、前記ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、ステップと、
デバイスの前記第1のサブセットの中から、前記複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの前記第2のサブセットの中の各デバイスのウェブカメラフィード信号が、前記物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、前記所与の場所に応じて、デバイスアクセスの前記第2のサブセットを、前記通信ネットワークを介して、前記複数のカメラのうちの選択された1つからのカメラフィード信号に提供するステップとを備える、方法。
【請求項12】
デバイスの前記第2のサブセットの中の各デバイスに対して、前記デバイスによって生成されるオーディオおよびビデオ信号が、前記物理位置において前記ライブイベントを実行する演者に向けられるようにするステップをさらに備え、前記オーディオおよびビデオ信号が、前記所与の場所に応じて前記演者に向けられる、請求項11に記載の方法。
【請求項13】
デバイスの前記第2のサブセットの中から少なくとも1つのデバイスを選択するステップと、前記少なくとも1つのデバイスおよび前記少なくとも1つの画面を通じて、前記少なくとも1つのデバイスのユーザと前記物理位置において前記ライブイベントを実行する演者との間のリアルタイムの交流を可能にするステップとをさらに備える、請求項11に記載の方法。
【請求項14】
デバイスアクセスの前記第2のサブセットを、前記通信ネットワークを介して、前記複数のカメラのうちの他のカメラからのカメラフィード信号に提供するステップをさらに備える、請求項11に記載の方法。
【請求項15】
デバイスの前記第1のサブセットの中から、デバイスの前記第2のサブセットとなるデバイスの新しいサブセットを選択するステップをさらに備える、請求項11に記載の方法。
【請求項16】
デバイスの前記新しいサブセットが、所定の期間が経過した後で選択される、請求項15に記載の方法。
【請求項17】
前記1つまたは複数の要求を受信するステップが、入札手続の間に、ユーザ固有の基準に基づいて前記ライブマルチメディアコンテンツへのアクセスを獲得するための1つまたは複数の応札をリアルタイムで受信するステップを備え、前記1つまたは複数の応札に基づいて、デバイスの前記第1のサブセットおよびデバイスの前記第2のサブセットが選択され、前記ストリームへのアクセスが提供される、請求項11に記載の方法。
【請求項18】
少なくとも1つのストリーミングサーバに、所定の時間遅延を前記ストリームへ導入させ、前記通信ネットワークを介して、前記所定の時間遅延を有する前記ストリームをデバイスの前記第1のサブセットへ放送させるステップと、前記少なくとも1つのストリーミングサーバに、前記ストリームから前記所定の時間遅延を取り除かせ、前記通信ネットワークを介して、前記所定の時間遅延が取り除かれた前記ストリームをデバイスの前記第2のサブセットへ放送させるステップとをさらに備える、請求項11に記載の方法。
【請求項19】
前記ライブマルチメディアコンテンツがデバイスの前記第1のサブセットおよびデバイスの前記第2のサブセットの各デバイスに提示されるグラフィカルユーザインターフェースにレンダリングされるようにするステップと、デバイスの前記第2のサブセットの中の各デバイスの前記ウェブカメラフィード信号が前記グラフィカルユーザインターフェースにレンダリングされるようにするステップとをさらに備える、請求項11に記載の方法。
【請求項20】
前記ウェブカメラフィード信号を共有することに対する招待状をデバイスの前記第2のサブセットの中の各デバイスにリアルタイムで送信するステップと、前記ウェブカメラフィード信号が前記画面上の前記所与の場所にレンダリングされるようにし、前記招待状の受け入れの標示を受信するとデバイスアクセスの前記第2のサブセットを前記カメラフィード信号に提供するステップとをさらに備える、請求項11に記載の方法。
【請求項21】
プログラムコードを記憶したコンピュータ可読媒体であって、前記プログラムコードが、
通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信することと、
前記1つまたは複数の要求に基づいて、前記複数のデバイスアクセスの第1のサブセットを、通信ネットワークを介して、前記ライブマルチメディアコンテンツを備えるストリームに提供することであって、前記ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、提供することと、
デバイスの前記第1のサブセットの中から、前記複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの前記第2のサブセットの中の各デバイスのウェブカメラフィード信号が、前記物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、前記所与の場所に応じて、デバイスアクセスの前記第2のサブセットを、前記通信ネットワークを介して、前記複数のカメラのうちの選択された1つからのカメラフィード信号に提供すること
のためにプロセッサによって実行可能である、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本特許出願は、2020年4月17日に出願された米国仮出願第63/011,520号の優先権を主張し、その内容全体が参照によって本明細書に組み込まれる。
【0002】
本開示は、イベント入場の分野に関し、より具体的には、双方向型のライブイベントをオンラインでストリーミングすることに関する。
【背景技術】
【0003】
コンテンツプロバイダがライブイベントをユーザにオンラインでストリーミングすることを、多数のプラットフォームが可能にしている。しかしながら、既存の技法では、参加者間で、または参加者とコンテンツプロバイダとの間で可能な交流が限られている。実際に、従来のストリーミング技法では、視聴者の反応は一般に、ストリーミングされているライブイベントと同期しておらず、ユーザはライブストリームを見るとき時間遅延(レイテンシまたはラグとも呼ばれる)を感じる。加えて、ユーザにより見られるコンテンツの品質は、ユーザデバイスの構成に応じて変わることがあり、ユーザ満足度の低下につながる。したがって、改善の余地がある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】米国出願第15/575,770号
【特許文献2】PCT出願第PCT/CA2019/051418号
【発明の概要】
【課題を解決するための手段】
【0005】
一態様によれば、メモリと、プロセッサと、メモリに記憶されたアプリケーションとを備えるシステムであって、アプリケーションは、通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信することと、1つまたは複数の要求に基づいて、複数のデバイスアクセスの第1のサブセットを、通信ネットワークを介して、ライブマルチメディアコンテンツを備えるストリームに提供することであって、ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、提供することと、デバイスの第1のサブセットの中から、複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号が、物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、所与の場所に応じて、デバイスアクセスの第2のサブセットを、通信ネットワークを介して、複数のカメラのうちの選択された1つからのカメラフィード信号に提供することのために、プロセッサによって実行可能である。
【0006】
いくつかの実施形態では、デバイスの第2のサブセットの中の各デバイスに対して、アプリケーションは、デバイスによって生成されるオーディオおよびビデオ信号が、物理位置においてライブイベントを実行する演者に向けられるようにするために、プロセッサによって実行可能であり、オーディオおよびビデオ信号は、所与の場所に応じて演者に向けられる。
【0007】
いくつかの実施形態では、アプリケーションは、デバイスの第2のサブセットの中から少なくとも1つのデバイスを選択することと、少なくとも1つのデバイスおよび少なくとも1つの画面を通じて、少なくとも1つのデバイスのユーザと物理位置においてライブイベントを実行する演者との間のリアルタイムの交流を可能にすることのために、プロセッサによって実行可能である。
【0008】
いくつかの実施形態では、アプリケーションは、デバイスアクセスの第2のサブセットを、通信ネットワークを介して、複数のカメラのうちの他のカメラからのカメラフィード信号に提供するために、プロセッサによって実行可能である。
【0009】
いくつかの実施形態では、アプリケーションは、デバイスの第1のサブセットの中から、デバイスの第2のサブセットとなるデバイスの新しいサブセットを選択するために、プロセッサによって実行可能である。
【0010】
いくつかの実施形態では、アプリケーションは、所定の期間が経過した後でデバイスの新しいサブセットを選択するために、プロセッサによって実行可能である。
【0011】
いくつかの実施形態では、アプリケーションは、入札手続の間に、ユーザ固有の基準に基づいてライブマルチメディアコンテンツへのアクセスを獲得するための1つまたは複数の応札をリアルタイムで受信することを備える1つまたは複数の要求を受信することと、1つまたは複数の応札に基づいて、デバイスの第1のサブセットおよびデバイスの第2のサブセットを選択し、ストリームへのアクセスを提供することのために、プロセッサによって実行可能である。
【0012】
いくつかの実施形態では、アプリケーションは、少なくとも1つのストリーミングサーバに、所定の時間遅延をストリームへ導入させ、通信ネットワークを介して、所定の時間遅延を有するストリームをデバイスの第1のサブセットへ放送させることと、少なくとも1つのストリーミングサーバに、ストリームから所定の時間遅延を取り除かせ、通信ネットワークを介して、所定の時間遅延が取り除かれたストリームをデバイスの第2のサブセットへ放送させることのために、プロセッサによって実行可能である。
【0013】
いくつかの実施形態では、アプリケーションは、ライブマルチメディアコンテンツがデバイスの第1のサブセットおよびデバイスの第2のサブセットの各デバイスに提示されるグラフィカルユーザインターフェースにレンダリングされるようにすることと、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号がグラフィカルユーザインターフェースにレンダリングされるようにすることのために、プロセッサによって実行可能である。
【0014】
いくつかの実施形態では、アプリケーションは、ウェブカメラフィード信号を共有することに対する招待状をデバイスの第2のサブセットの中の各デバイスにリアルタイムで送信することと、ウェブカメラフィード信号が画面上の所与の場所にレンダリングされるようにし、招待状の受け入れの標示を受信するとデバイスアクセスの第2のサブセットをカメラフィード信号に提供することのために、プロセッサによって実行可能である。
【0015】
別の態様によれば、コンピュータで実施される方法が提供され、この方法は、プロセッサにおいて、通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信するステップと、1つまたは複数の要求に基づいて、複数のデバイスアクセスの第1のサブセットを、通信ネットワークを介して、ライブマルチメディアコンテンツを備えるストリームに提供するステップであって、ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、ステップと、デバイスの第1のサブセットの中から、複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号が、物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、所与の場所に応じて、デバイスアクセスの第2のサブセットを、通信ネットワークを介して、複数のカメラのうちの選択された1つからのカメラフィード信号に提供するステップとを備える。
【0016】
いくつかの実施形態では、方法はさらに、デバイスの第2のサブセットの中の各デバイスに対して、デバイスによって生成されるオーディオおよびビデオ信号が、物理位置においてライブイベントを実行する演者に向けられるようにするステップを備え、オーディオおよびビデオ信号は、所与の場所に応じて演者に向けられる。
【0017】
いくつかの実施形態では、方法はさらに、デバイスの第2のサブセットの中から少なくとも1つのデバイスを選択するステップと、少なくとも1つのデバイスおよび少なくとも1つの画面を通じて、少なくとも1つのデバイスのユーザと物理位置においてライブイベントを実行する演者との間のリアルタイムの交流を可能にするステップとを備える。
【0018】
いくつかの実施形態では、方法はさらに、デバイスアクセスの第2のサブセットを、通信ネットワークを介して、複数のカメラのうちの他のカメラからのカメラフィード信号に提供するステップを備える。
【0019】
いくつかの実施形態では、方法はさらに、デバイスの第1のサブセットの中から、デバイスの第2のサブセットとなるデバイスの新しいサブセットを選択するステップを備える。
【0020】
いくつかの実施形態では、デバイスの新しいサブセットは、所定の期間が経過した後で選択される。
【0021】
いくつかの実施形態では、1つまたは複数の要求を受信するステップは、入札手続の間に、ユーザ固有の基準に基づいてライブマルチメディアコンテンツへのアクセスを獲得するための1つまたは複数の応札をリアルタイムで受信するステップを備え、1つまたは複数の応札に基づいて、デバイスの第1のサブセットおよびデバイスの第2のサブセットが選択され、ストリームへのアクセスが提供される。
【0022】
いくつかの実施形態では、方法はさらに、少なくとも1つのストリーミングサーバに、所定の時間遅延をストリームへ導入させ、通信ネットワークを介して、所定の時間遅延を有するストリームをデバイスの第1のサブセットへ放送させるステップと、少なくとも1つのストリーミングサーバに、ストリームから所定の時間遅延を取り除かせ、通信ネットワークを介して、所定の時間遅延が取り除かれたストリームをデバイスの第2のサブセットへ放送させるステップとを備える。
【0023】
いくつかの実施形態では、方法はさらに、ライブマルチメディアコンテンツがデバイスの第1のサブセットおよびデバイスの第2のサブセットの各デバイスに提示されるグラフィカルユーザインターフェースにレンダリングされるようにするステップと、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号がグラフィカルユーザインターフェースにレンダリングされるようにするステップとを備える。
【0024】
いくつかの実施形態では、方法はさらに、ウェブカメラフィード信号を共有することに対する招待状をデバイスの第2のサブセットの中の各デバイスにリアルタイムで送信するステップと、ウェブカメラフィード信号が画面上の所与の場所にレンダリングされるようにし、招待状の受け入れの標示を受信するとデバイスアクセスの第2のサブセットをカメラフィード信号に提供するステップとを備える。
【0025】
さらに別の態様によれば、プログラムコードを記憶したコンピュータ可読媒体が提供され、プログラムコードは、通信ネットワークを介して、複数のデバイスから、ライブマルチメディアコンテンツにアクセスするための1つまたは複数の要求を受信することと、1つまたは複数の要求に基づいて、複数のデバイスアクセスの第1のサブセットを、通信ネットワークを介して、ライブマルチメディアコンテンツを備えるストリームに提供することであって、ストリームが、ある物理位置において行われるライブイベントを撮影する複数のカメラによって生成される、提供することと、デバイスの第1のサブセットの中から、複数のデバイスの第2のサブセットを繰り返し選択して、デバイスの第2のサブセットの中の各デバイスのウェブカメラフィード信号が、物理位置において提供される画面上の所与の場所にリアルタイムでレンダリングされるようにし、所与の場所に応じて、デバイスアクセスの第2のサブセットを、通信ネットワークを介して、複数のカメラのうちの選択された1つからのカメラフィード信号に提供することのために、プロセッサによって実行可能である。
【0026】
本発明のさらなる特徴および利点は、添付の図面と組み合わせると、以下の詳細な説明から明らかになる。
【図面の簡単な説明】
【0027】
図1】ある例示的な実施形態による、仮想会場の聴衆にライブマルチメディアコンテンツをストリーミングするためのシステムの概略図である。
図2A】ある例示的な実施形態による、図1のコンテンツプロバイダに関連する放送スタジオの概略図である。
図2B】ある例示的な実施形態による、図2Aの放送スタジオにおける画面とカメラの場所を示す概略図である。
図3A】ある例示的な実施形態による、図1のクライアントデバイスに提示されるグラフィカルユーザインターフェース(GUI)の概略図である。
図3B】ある例示的な実施形態による、ユーザが生で取り上げられるときに図1のクライアントデバイスに提示されるグラフィカルユーザインターフェース(GUI)の概略図である。
図4図1のプロセッサ上で実行されるアプリケーションの概略図である。
図5】ある例示的な実施形態による、仮想会場の聴衆にライブマルチメディアコンテンツをストリーミングするための方法のフローチャートである。
図6】仮想会場およびライブコンテンツへのアクセスを管理する図5のステップのフローチャートである。
図7】仮想会場およびライブコンテンツへのアクセスをユーザに認める図6のステップのフローチャートである。
【発明を実施するための形態】
【0028】
添付の図面全体で、同様の特徴は同様の番号によって識別されることに留意されたい。
【0029】
図1を参照すると、一実施形態による、仮想会場の聴衆にライブマルチメディアコンテンツをストリーミングするためのシステム100がここで説明される。本明細書において使用される場合、「ストリーミング」という用語は、マルチメディアコンテンツ(オーディオおよびビデオなどの異なる形式を単一の表現へと組み合わせるコンテンツ)をリアルタイムかつオンラインで(たとえば、インターネットを介して)エンドユーザに配信する処理を指す。ライブストリーミングされないビデオオンデマンドなどのノンライブメディアとは対照的に、メディアは同時に記録され放送される。示されるシステム100は、インターネット、セルラーネットワーク、Wi-Fi、公衆交換電話網(PSTN)、または当業者に知られている他のものなどのネットワーク106を介して、複数のクライアントデバイス104と通信するように適合された1つまたは複数のサーバ102を備える。
【0030】
以下でさらに論じられるように、クライアントデバイス104は、聴衆(「ユーザ」または「参加者」と本明細書で呼ばれる)のメンバーが、仮想会場へのアクセスを得て、コンテンツプロバイダ108によって放送(またはストリーミング)されるライブマルチメディアコンテンツを見ることを可能にする。クライアントデバイス104は、ネットワーク106を介して通信するように構成される任意のデバイス(モバイルであるかどうかにかかわらず)を備え得る。クライアントデバイス104の例は、限定はされないが、ラップトップコンピュータ、デスクトップパーソナルコンピュータ、ハンドヘルドパーソナルコンピュータまたは携帯情報端末(PDA)、タブレットコンピュータ、スマートテレビジョン、およびスマートフォンを含む。例示として、クライアントデバイス104は、MicrosoftのInternet Explorer(商標)、Mozilla Firefox(商標)、Safari(商標)、スマートフォンの場合のワイヤレスアプリケーションプロトコル(WAP)対応ブラウザ、またはネイティブモバイルアプリケーションを実行する。クライアントデバイス104はまた、ユーザが仮想会場にアクセスするときに各デバイス104に提示されるグラフィカルユーザインターフェース(GUI)と対話するための、キーボード、マウス、タッチスクリーン、ウェブカメラ、および同様のもの(図示せず)などの1つまたは複数のインターフェースデバイスを含み得る。
【0031】
システム100は、ライブマルチメディアコンテンツを大勢の聴衆(たとえば、数千個のクライアントデバイス104)に放送(またはストリーミング)するために使用され得る。この目的で、一実施形態では、ライブイベント(たとえば、ライブコンサートなど)からのオーディオおよびビデオ信号は、屋内の物理位置(たとえば、放送スタジオの中など)において、または屋外の物理位置(たとえば、スタジアム/アリーナ、劇場、コンサートホールなどの娯楽会場)において、記録システムによって記録される(または撮影される)。得られたマルチメディアコンテンツは、クライアントデバイス104にレンダリングされる仮想会場層へとマルチメディアコンテンツをプッシュすることによって、リアルタイムでユーザに放送される。
【0032】
一実施形態では、ライブイベントが記録される物理環境(たとえば、演者の周囲)を表現するように、仮想環境が作成され得る。現実世界の会場に存在するであろう物理的な座席または観客も、仮想的に再現され得る。したがって、仮想会場は、現実の会場の物理的なカウンターパートを仮想的なまたはデジタルの(2次元または3次元)表現であってもよく、仮想会場層は、仮想環境内のユーザの視野を反映するように生成される架空のまたはデジタルの層であり得る。
【0033】
図2Aは、ライブイベントを記録するために用意される放送スタジオ200を示す。シーン202において演じている1人または複数の演者(たとえば、アーティスト、ミュージシャン、俳優、プレゼンタ、コメディアン、弁士、または他のエンターテイナ、図示されない)が、放送スタジオ200の異なる位置に並べられた複数のカメラ204を備える記録システムによってリアルタイムで記録される。演者から見えるいくつかの画面2061、2062、および2063(図2Bにも示されている)は、ライブパフォーマンスをそれが記録されるにつれてレンダリングし、ならびに、クライアントデバイス104によって生成されるフィード(たとえば、ウェブカメラフィード)から取得されるような、パフォーマンスへの聴衆の反応をレンダリングするために構成される。3つの画面2061、2062、および2063図2Aおよび図2Bにおいて図示されているが、これは例示を目的とするものにすぎず、放送スタジオ200は任意の他の数の画面を備え得ることを理解されたい。カメラ204および画面2061、2062、および2063の構成パラメータ(たとえば、数、配置、解像度など)は、システム100の放送スタジオ200の構成に応じて変わり得ることも理解されたい。たとえば、カメラ204および/または画面2061、2062、および2063は、2次元(2D)、3次元(3D)、拡張現実(AR)、仮想現実(VR)などにおいて複数の視聴角度を提供するのが望ましいことがある。
【0034】
ライブイベントを見ている何人かのユーザが、画面2061、2062、および2063で取り上げられ得る(たとえば、自分のウェブカメラフィードを表示させ得る)。一実施形態では、以下でさらに論じられるように、ライブパフォーマンスのユーザの視点(すなわち、仮想環境内でのユーザの視野)は、ユーザが取り上げられる画面2061、2062、および2063(および画面2061、2062、および2063上でのユーザのウェブカメラフィードの場所)に従って、リアルタイムで適合される。この目的で、複数のカメラ208(図2Bに示されている)が各画面2061、2062、および2063に接して並べられてもよく、システム100は、ユーザが取り上げられている画面2061、2062、および2063に接して並べられており画面2061、2062、および2063上のユーザのウェブカメラフィードの場所に最も近い、カメラ208から取得される記録(すなわち、カメラフィード信号)を所与のユーザに放送する(すなわち、それへのアクセスを所与のユーザに提供する)ように構成される。
【0035】
図2Bは、4個のカメラ208が画面2061の上に設けられ、4個のカメラ208が画面2061の下に設けられるような実施形態を示す。これは、例示を目的とするものにすぎず、カメラ208の数と位置は変わり得ることを理解されたい。また、図2Bは画面2061に接して設けられるカメラ208のみを示すが、これはわかりやすくするためのものであり、各画面2061、2062、および2063にカメラ208が設けられてもよいことを理解されたい。いくつかの実施形態では、追加のカメラ208は、各画面2061、2062、および2063の側面に取り付けられてもよいことも理解されたい。他の構成が適用されてもよい。
【0036】
図1に戻ると、図2Aおよび図2Bに加えて、一実施形態では、システム100はさらに、スイッチャユニット118、エンコーダシステム120、および1つまたは複数のストリーミングサーバ122を備え、そのうちの1つまたは複数が、コンテンツプロバイダ108において、またはシステムレベルで制御され得る。スイッチャユニット118は、放送スタジオ200とシステム100との間のリンクとして機能する。一実施形態では、スイッチャユニット118は、コンテンツプロバイダ108に設けられ得る。スイッチャユニット118は1つまたは複数のスイッチを備えてもよく、これは、限定はされないが、Broadcast Pix(商標)スイッチャまたは任意の他の適切なスイッチを含んでもよい。スイッチャユニット118は、コンテンツプロバイダ108によってクライアントデバイス104に放送されるように管理者がシーンを制御することを可能にし得る。この目的で、一実施形態では、スイッチャユニット118は、ライブイベントを記録するカメラ204、208を切り替えるように構成される第1のスイッチ(図示せず)を備え得る。スイッチャユニット118の第1のスイッチは、カメラ204、208の画角を調整するようにも構成され得る。スイッチャユニット118は次いで、ストリームを出力する。
【0037】
一実施形態では、システム100は、ユーザの好みに応じてユーザがライブイベントの異なるビュー(視点または視野とも呼ばれる)を得ることを可能にする。ユーザは実際に、シーン202の所望のビューを選択するための選択肢を与えられ得る。この選択は、ユーザのデバイス104に関連する1つまたは複数のインターフェースデバイスを使用して、ユーザのデバイス104に提示されるGUIに関連する制御要素(たとえば、選択可能なボタン)を操作するユーザによって行われ得る。たとえば、ユーザは、ユーザのデバイス104に関連するタッチスクリーンを使用して、デフォルトの視野(たとえば、仮想会場内のユーザの現在の位置、すなわち、ユーザが取り上げられる画面2061、2062、および2063ならびに画面2061、2062、および2063上でのユーザのウェブカメラフィードの場所からの視聴角度)、仮想会場の後方からのビュー、および仮想会場内の異なる角度からのビューの中から選択し得る。第1のスイッチは次いで、カメラ204、208を切り替えて、ユーザの選択に応じてカメラ204、208の画角を調整するように構成される。
【0038】
一実施形態では、以下でさらに論じられるように、限られた数(たとえば、100個)のクライアントデバイス104が、画面2061、2062、および2063上で生で取り上げられる(たとえば、自分のウェブカメラフィードを表示させることによってウェブカメラ寄与者になる)ように、ライブイベントの全体(たとえば、20000人)の参加者から選択される。したがって、スイッチャユニット118は、画面2061、2062、および2063上での(生で取り上げられるように選択される限られた数のクライアントデバイス104に関連する)ウェブカメラフィードの場所を決定するように構成される第2のスイッチ(図示せず)を備え得る。たとえば、スイッチャユニット118の第2のスイッチは、所与のウェブカメラフィードが画面2061の右上の角(図2Bの位置A)に表示されるべきであると決定し得る。スイッチャユニット118の第1のスイッチは次いで、カメラ208の中で、所与のカメラ208Aが画面2061上のウェブカメラフィードの場所Aに最も近いと決定するように構成され得る。第1のスイッチは次いで、場所Aにおいて取り上げられている所与のウェブカメラフィードに関連するクライアントデバイス104に、カメラ208Aからの記録(すなわち、カメラフィード信号)が放送されるようにし得る。他のカメラ208からのカメラフィード信号は、クライアントデバイス104にも放送され得ることを理解されたい。加えて、そのウェブカメラフィードが画面2061、2062、および2063で取り上げられる各クライアントデバイス104に対して、システム100は、クライアントデバイス104によって生成されるオーディオおよびビデオ信号を、物理位置においてライブイベントを演じている演者に向けるように構成される。オーディオおよびビデオ信号は、画面2061、2062、および2063上でのユーザのウェブカメラフィードの場所(たとえば、位置A)に応じて演者に向けられる。
【0039】
限られた数のクライアントデバイス104の選択、ならびに画面2061、2062、および2063上でのそれらのウェブカメラフィードの配置の決定は、以下でさらに論じられるような様々な基準に基づき得る。たとえば、ウェブカメラフィードの場所の決定は、生で取り上げられるべきユーザの数、ユーザのアクセス権に関連するプロパティ、または任意の他の適切な基準に基づいて、スイッチャユニット118の第2のスイッチによって行われ得る。
【0040】
スイッチャユニット118によって実装される機能は、たとえば機械学習(ML)および/または人工知能(AI)技法を使用して自動化され得ることを理解されたい。本明細書において使用される場合、機械学習および/またはAI技法は、学習する(たとえば、徐々に時間とともに、本明細書において説明されるタスクについて性能を向上させる)能力を本明細書において説明されるシステムおよび方法に与えるために、様々な要因を重み付ける任意の適切なインテリジェント処理技法を指す。
【0041】
ストリームは次いで、(コンテンツプロバイダ108から)エンコーダシステム120に送信され、これは、ネットワーク106を介したクライアントデバイス104への後続の送信のためにストリームをフォーマットする。この目的で、一実施形態では、エンコーダシステム120は、スイッチャユニット118から受信されたストリームをデジタル化して、クライアントデバイス104へのストリーミングに適したデータフォーマットへと符号化し得る。コンテンツは、限定はされないが、Audio Video Interleave(AVI)、Windows Media、MPEG4、Quicktime、Real Video、およびShock Wave/Flashを含む、任意の適切なフォーマットまたは技法を使用して符号化され得る。例示として、エンコーダシステム120は、クライアントデバイス104の各々1つの帯域幅に最適なビットレートをストリーミングサーバ122が選択することを続いて可能にするように、複数のビットレートにおいてストリームを符号化する。以下でさらに論じられるように、一実施形態では、エンコーダシステム120およびストリーミングサーバ122は、ユーザにより生成された最良のコンテンツ(たとえば、ライブチャット、ウェブカメラフィードなど)を、ユーザが仮想会場にアクセスするときに見る最後のストリームへと織り込むように構成され得る。例示として、ストリーミングサーバ122は、104のように複数のタイプのクライアントデバイスにライブマルチメディアコンテンツを同時にストリーミングすることを可能にする、Wowza Media Server(商標)ソフトウェアまたは任意の他の適切なソフトウェアなどのサーバソフトウェアを使用する。ストリーミングサーバ122は、限定はされないが、Hypertext Transfer Protocol(HTTP) Live Streaming、Real Time Streaming Protocol(RTSP)、およびMultimedia Messaging Service(MMS)を含む任意の適切なストリーミングプロトコルを使用して、ネットワーク106を介してライブマルチメディアコンテンツをクライアントデバイス104に放送する。システム100はさらに、たとえば24時間、1日、1週間などの所定の時間の間、生放送の後でマルチメディアコンテンツの記録または再生へのアクセスをクライアントデバイス104が有することを可能にし得る。
【0042】
ストリーミングサーバ122は次いで、各クライアントデバイス104に提示されるGUIにレンダリングするためのストリームを配信し得る。図3AはそのようなGUI300を示し、これは、生放送が提示されるライブイベントフレーム302を備える。GUI300はさらに、複数のクライアントデバイス104からのウェブカメラフィードが提示される複数のウェブカメラフレーム304を備える。クライアントデバイス104の各ユーザは実際に、以下でさらに論じられるように、限定はされないが、仮想会場へのアクセスを得るためにユーザにより購入されるアクセス権を含む様々な選択基準に基づいて、生放送において寄与者になり得る(すなわち、生の交流に移行する)。クライアントデバイス104は次いで、そのウェブカメラに接続して放送し、そのウェブカメラフィードが、ライブイベントと同時に、ライブパフォーマンスまたはイベントを配信する演者によって(画面2061、2062、および2063で)、および他のクライアントデバイス104によって(ウェブカメラフレーム304内で)、リアルタイムで見られるようにし得る。
【0043】
一実施形態では、複数の選択可能なボタン3061、3062、および3063などの複数の制御要素も、GUI300内で提示されているコンテンツをユーザが制御することを可能にするための、GUI300の一部であり得る。たとえば、示される実施形態では、ボタン3061は、ユーザが、そのユーザに関連するユーザ(本明細書では「友人」と呼ばれる)のうちのいずれがやはりライブイベントを見ているかをウェブカメラフレーム304内で視覚化することを可能にする。ユーザの友人は、限定はされないが、家族およびオンラインソーシャルネットワークまたはソーシャルネットワーキングアプリケーションからの友人を含む、ユーザに関連する個人の任意の適切なグループを備え得ることを理解されたい。ユーザの友人はまた、ユーザのプロファイルに関連する識別子に基づいて決定され得る。
【0044】
ボタン3062は、ユーザが、どの他の特定の参加者または参加者のグループ(たとえば、所与のアーティストのファンまたは所与のロイヤルティプログラムのメンバー)がやはりライブイベントを見ているかをウェブカメラフレーム304内で視覚化することを可能にする。ボタン3063は、クライアントデバイス104に提示され得る所与のインタラクティブツールに関連し得る。示される実施形態では、ボタン3063は、ライブイベントの他の参加者(すなわち、システム100のユーザ)とユーザがリアルタイムで通信することを可能にするチャットボックスに関連する。他の実施形態が適用されてもよい。
【0045】
フレーム302、304、ならびにボタン3061、3062、および3063の、場所、形状、およびサイズは、例示のみを目的とし、改変されてもよいことを理解されたい。たとえば、ユーザは、ユーザのクライアントデバイス104のインターフェースデバイスを使用して、所与のフレーム302、304、またはボタン3061、3062、および3063のサイズを減らし得る。代替として、システム100の管理者は、各クライアントデバイス104の画面のサイズと形状に自動的に収まるように、提示されているフレーム302、304、ならびに/またはボタン3061、3062、および3063を伴うGUI300のレイアウトを制御し得る。フレーム302、304、またはボタン3061、3062、および3063の数も、ユーザに提示されるべきデータに応じて変わり得る。
【0046】
生放送の寄与者になるように選択され得るクライアントデバイス104の中から、1つまたは複数のクライアントデバイス104がさらに、以下でさらに論じられるように、演者とともに生で取り上げられる(または「生放送に出る」)ように、すなわち、演者とのリアルタイムの交流を行うように選択され得る。複数のクライアントデバイス104が、演者とともに生で同時に取り上げられてもよく、生で取り上げられるユーザは、演者とリアルタイムで交流することに加えて、互いにリアルタイムで交流してもよいことを理解されたい。図3Bは、クライアントデバイス104のユーザが生で取り上げられるときの、クライアントデバイス104に提示されるGUI300'を示す。図3Bに見られるように、GUI300'は、生放送(すなわち、演者)が提示されるライブイベントフレーム302'と、ユーザが演者とリアルタイムで交流する(たとえば、クライアントデバイス104のウェブカメラを介して演者と会話する)のが示され得る自画像フレーム308とを備える。言い換えると、ユーザは、自画像フレーム308内で自分を見ることができる。GUI300'はさらに、生で取り上げられる他のユーザを表示する1つまたは複数の追加のフレーム(図示せず)を備え得る。前に述べられたように、演者は、画面2061、2062、2063上で、生で取り上げられるユーザのウェブカメラフィードを見る。
【0047】
画面(図2Aおよび図2Bの参照番号2061、2062、2063)は、演者とともに生放送に出るようにそのクライアントデバイス104が選択されるユーザを紹介するためにも使用され得ることを理解されたい。ユーザは、ウェブカメラ寄与者になること、または演者とリアルタイムで交流することについての受入または拒絶の選択肢を、GUI300または300'を通じて与えられ得ることも理解されたい。この目的で、システム100は、生で取り上げられるように選択される限られた数のクライアントデバイス104に、招待状を生成して送信するように構成され得る。招待状は、任意の適切な通信手段(たとえば、ネットワーク106を介して送信されるインスタントプッシュ通知、電子メール、ショートメッセージサービス(SMS)、MMS、インスタントメッセージング(IM)など)を使用して送信され、GUI300を通じてクライアントデバイス104でレンダリングされ得る(たとえば、ポップアップウィンドウ、メッセージ、または他の適切なアイコン)。各ユーザは次いで、招待状を受け入れ、または断り得る。一実施形態では、招待状を受け入れた(すなわち、招待状の受け入れを示すデータがシステム100により受信される)ユーザのみが、ウェブカメラ寄与者になり、または演者とリアルタイムで交流する。
【0048】
図1に戻ると、以下でさらに論じられるように、仮想会場およびライブコンテンツまたは生放送へのアクセスは、ライブマルチメディアコンテンツへのアクセスのためにアクセス権の保有者が支払を行ったことを示す、任意の適切な電子的な購入証明書などのアクセス権によって制御される。いくつかの実施形態では、仮想会場の容量は実際に、所与の数のクライアントデバイス104に制限され得る。他の実施形態では、容量は制限されない。以下でさらに論じられるように、各アクセス権は、アクセス権の保有者により見られるコンテンツをリアルタイムで管理するためにも使用される。たとえば、所与のユーザにより見られるコンテンツ(たとえば、カメラ画角、図3AのGUI300内で提示されるインタラクティブツール)は、限定はされないが、ユーザにより購入されたアクセス権を含む、様々な選択基準に基づいて変わり得る。本明細書において使用される場合、「アクセス権」という用語はしたがって、仮想会場にアクセスして仮想会場内のライブマルチメディアコンテンツを見るために、ユーザにより獲得される権利を指す。一実施形態では、以下でさらに論じられるように、アクセス権は、ユーザの固有のプロファイルに関連する購入証明書に相当する。カテゴリは各アクセス権と関連付けられてもよく、カテゴリはアクセス権に適用され得るあらゆる制約を示す。一実施形態では、アクセス権は、別のユーザに譲渡または販売され得る固有の暗号化されたトークンである。本明細書において使用される場合、「トークン」という用語は、仮想会場にアクセスしてライブマルチメディアコンテンツ見るためのユーザの権利を表現するソフトウェアオブジェクトを指す。トークンは、ユーザを一意に識別する情報を含み、仮想会場にアクセスしてライブマルチメディアコンテンツを見るためのユーザの証明書(たとえば、ユーザのプロファイルに関連するプロパティ)をカプセル化する、様々なフィールドからなる。
【0049】
一実施形態では、仮想会場にアクセスして、コンテンツプロバイダ108によって放送されているライブマルチメディアコンテンツを見るために、システム100は、固有の識別子の使用を通じてまずログインすること、または別様にシステム100への認可されたアクセスを得ることを、ユーザに対して求める。この目的で、例示として、ユーザは、自分のクライアントデバイス104を使用して申請を行うことによってシステム100に登録し、それにより、メモリ112および/またはデータベース116に記憶され得る固有のプロファイルまたはアカウントを作成する。これは、クライアントデバイス104を使用して、ウェブサイトにアクセスすること、モバイルアプリケーション、またはシステム100に関連する他の適切なアクセス手段によって行われ得る。登録が完了すると、例示として、各ユーザは、任意の適切な暗号化方法を使用して暗号化され得る固有の識別子(自分のプロファイルに関連する、電子メールアドレス、ユーザ名、および/またはパスワードなど)を与えられる。いくつかの実施形態では、ユーザの識別子は、ユーザが登録しているオンラインソーシャルネットワークまたはソーシャルネットワーキングアプリケーション(たとえば、Facebook(商標)、Google+(商標)、Twitter(商標)など)と関連付けられ得る。
【0050】
システム100は次いで、ユーザが固有の識別子を介して自分自身を識別すると、クライアントデバイス104によってアクセスされ得る。システム100は、複数のユーザにより同時にアクセスされ得ることを理解されたい。一実施形態では、システム100へのアクセスは、ユーザが、識別子を用いてウェブサイトにログオンすること、モバイルアプリケーションにアクセスすること、顔認識などの認証技法を使用すること、および/または任意の他の適切なアクセス手段を使用することによって果たされ得る。次いで、ユーザがシステム100にアクセスを試みると、ユーザの識別情報を検証するために識別子が使用され得る。たとえば、固有の識別子は、政府のデータベース、または識別を目的に使用される別のデータソースと比較され得る。いくつかの実施形態では、固有の識別子は、セキュリティの目的で、正当性を認められたおよび/または認められていない携帯電話番号のリストと比較される携帯電話番号である。他のセキュリティ対策も、ユーザの識別情報を検証するために適用され得る。
【0051】
一実施形態では、様々なレベルのアクセス権がユーザに与えられてもよく、一部のユーザは、自分のプロファイル情報に基づいて所与のコンテンツにアクセスするのを妨げられてもよい。たとえば、未成年のユーザは、成人向けコンテンツへのアクセスを許可されなくてもよい。一実施形態では、システム100へのアクセスが認められると、ユーザは、仮想会場にアクセスして生放送を見るためのアクセス権を(たとえば、入札手続、受信されたユーザ要求からのランダムな選択、または本明細書において説明されるような他の適切な機構を通じて)獲得し得る。アクセス権が獲得されると、ユーザのクライアントデバイス104で起動されるアプリケーションは、GUI(図3Aの300または図3Bの300')を作成し、生放送に関連するメディアコンテンツをGUIに提示する。いくつかの実施形態では、生放送は、ペイパービュー方式でアクセスされてもよい。月ごとの契約も適用されてもよい。本文書の他の箇所で説明されるように、ユーザはまた、生放送の前、間、または後に、ユーザが選択した価格を支払うことが可能にされてもよい。
【0052】
いくつかの実施形態では、選択されたマルチメディアコンテンツ(たとえば、ライブイベントのボーナス部分)が、アクセス権を獲得するために支払われた額に従って、一部のユーザに対して利用可能にされ得る。言い換えると、選択されたコンテンツへのアクセスは、ユーザのアクセス権に関連するプロパティに依存し得る。たとえば、一部のユーザは、アクセス権を購入するために他のユーザと比較して高い額を支払っていることがある。そうすると、アクセス権のためにより多くを支払ったユーザは、選択されたコンテンツを見ることが許可されてもよいが、残りのユーザは許可されなくてもよい(たとえば、所定の期間の後、選択されたマルチメディアコンテンツが放送される前に、放送が停止する)。
【0053】
一実施形態では、支払情報、デジタルクーポン、使用されたアクセス権の履歴、今後のイベントに対するアクティブなアクセス権、および他の関連情報を含む電子ウォレットが、各ユーザプロファイルと関連付けられ得る。電子ウォレットはまた、たとえば顔認識の目的で使用され得るユーザの写真を備え得る。システム100はまた、(たとえば、ユーザにより購入されるアクセス権の)購入証明書を表現する一時的な固有の暗号化されたトークンと、ユーザのプロファイルを関連付け得る。トークンは、購入されたアクセス権に関連する価格値ならびに仮想会場および/またはイベントを特定する他の関連情報などの、情報(またはプロパティ)を含み得る。各トークンに関連するプロパティは次いで、アクセスが可能なコンテンツを決定する。所与のユーザは複数のアクセス権を購入することがあるので、所与のユーザプロファイルは、たとえば異なる価格値を有する複数のトークンを保持することがあることを理解されたい。
【0054】
さらに図1を参照すると、サーバ102は、ウェブサーバ、アプリケーションサーバ、およびデータベースサーバに対応する一連のサーバを備え得る。これらのサーバはすべて、図1のサーバ102により表現される。サーバ102は、とりわけ、メモリ112に結合され複数のアプリケーション114a、...、114nがその上で実行されるプロセッサ110を備え得る。プロセッサ110は、データを取り出すためにメモリ112にアクセスし得る。プロセッサ110は、データに対して動作を実行できる任意のデバイスであり得る。例は、中央処理装置(CPU)、マイクロプロセッサ、およびフロントエンドプロセッサである。アプリケーション114a、...、114nは、プロセッサ110に結合され、より詳しく以下で説明されるように様々なタスクを実行するように構成される。本明細書において提示されるアプリケーション114a、...、114nは、別々のエンティティとして示され説明されるが、それらは様々な方法で組み合わせられ、または分けられてもよいことを理解されたい。オペレーティングシステム(図示せず)が、プロセッサ110とアプリケーション114a、...、114nの間の仲介物として使用されてもよいことを理解されたい。
【0055】
プロセッサ110によってアクセス可能なメモリ112は、データを受信して記憶し得る。メモリ112は、高速ランダムアクセスメモリ(RAM)などのメインメモリ、またはハードディスクもしくはフラッシュメモリなどの補助記憶ユニットであり得る。メモリ112は、読み取り専用メモリ(ROM)、消去可能プログラム可能読み取り専用メモリ(EPROM)、またはビデオディスクおよびコンパクトディスクなどの光学記憶媒体などの、任意の他のタイプのメモリであり得る。また、システム100は、その上でアプリケーション114a、...、114nが実行されるプロセッサ110を備えるものとして本明細書において説明されるが、クラウドコンピューティングも使用され得ることを理解されたい。したがって、メモリ112はクラウドストレージを備え得る。
【0056】
1つまたは複数のデータベース116は、メモリ112に直接統合されてもよく、または、それとは別に、サーバ102から離れて(図示されるように)提供されてもよい。データベース116へのリモートアクセスの場合、上で示されたように、アクセスは任意のタイプのネットワーク106を介して行われ得る。本明細書において説明されるデータベース116は、コンピュータによる高速な検索および取り出しのために編成された、データまたは情報の集合体として提供され得る。データベース116は、様々なデータ処理動作とともに、データの記憶、取り出し、修正、および削除を容易にするように構築され得る。データベース116は、各々が1つまたは複数のフィールドからなる記録へと分解され得る、ファイルまたはファイルのセットからなり得る。フィールドを高速に検索し、並べ替え、グループ化し、選択するために、キーワードおよび分類コマンドを使用したクエリを通じて、データベース情報が取り出され得る。データベース116は、1つまたは複数のサーバなどのデータ記憶媒体上のデータの任意の編成であり得る。上で論じられたように、システム100はクラウドコンピューティングを使用してもよく、したがって、データベース116はクラウドストレージを備えてもよいことを理解されたい。
【0057】
一実施形態では、データベース116は、セキュアウェブサーバおよびTransport Layer Security(TLS)をサポートすることが可能なHypertext Transport Protocol Secure(HTTPS)であり、これはデータへのアクセスのために使用されるプロトコルである。セキュアウェブサーバとの間の通信は、Secure Sockets Layer(SSL)を使用してセキュアにされ得る。ユーザの識別情報の検証は、すべてのユーザに対するユーザ名およびパスワードを使用して実行され得る。様々なレベルのアクセス許可が、複数のレベルのユーザに与えられ得る。
【0058】
代替として、コンピュータネットワーク内のデバイスが情報を交換することを可能にする任意の既知の通信プロトコルが使用され得る。プロトコルの例は、IP(Internet Protocol)、UDP(User Datagram Protocol)、TCP(Transmission Control Protocol)、DHCP(Dynamic Host Configuration Protocol)、HTTP(Hypertext Transfer Protocol)、FTP(File Transfer Protocol)、Telnet(Telnet Remote Protocol)、SSH(Secure Shell Remote Protocol)である。
【0059】
図4は、プロセッサ110上で実行されるアプリケーション114aの例示的な実施形態である。例示として、アプリケーション114aは、受信モジュール402、プロファイル管理モジュール404、仮想会場管理モジュール406、支払処理モジュール408、および出力モジュール410を備える。
【0060】
例示として、受信モジュール402は、1つまたは複数のクライアントデバイス104および/またはコンテンツプロバイダ108から1つまたは複数の入力信号を受信する。コンテンツプロバイダ108から受信される入力信号は、クライアントデバイス104への放送のために記録されるオーディオおよびビデオ信号(すなわち、カメラフィード信号)、ならびにクライアントデバイス104から受信される信号(たとえば、ウェブカメラフィード信号)を備え得る。コンテンツプロバイダ108から受信される入力信号はまた、アクセス権に対する値付け情報、たとえば、アクセス権の各カテゴリに対する最低価格値、ならびに、限定はされないが、不変のアクセス権の詳細、在庫データ(たとえば、利用可能なアクセス権とそれらの関連するカテゴリについての情報)などを含む他の関連情報を備え得る。
【0061】
各クライアントデバイス104から受信される入力信号は、ユーザを一意に識別するデータ、たとえばシステム100におけるユーザのアカウントと関連付けられるユーザの識別子を備え得る。ユーザ識別子は実際に、システム100へのアクセスをユーザが得ようとすると受信され得る。ユーザ識別子は次いで、システム100の機能へのアクセスをユーザに提供する前に、ユーザを認証するためのプロファイル管理モジュール404に、受信モジュール402によって送信され得る。プロファイル管理モジュール404は、ユーザ識別子を受信すると、ユーザのアカウントに関連する記憶されているユーザ識別子をメモリ112および/またはデータベース116から取り出し得る。プロファイル管理モジュール404は、ユーザまたはシステム100へのユーザのアクセスに対する何らかの制約が存在するかどうかを決定するように構成され得る。プロファイル管理モジュール404は次いで、取り出されたユーザ識別子および受信モジュール402から受信されたユーザ識別子を比較し得る。両方の識別子が一致する場合、プロファイル管理モジュール404は、ユーザの認証に成功し、その効果に対するメッセージを生成し得る。そうではなく、識別子が一致しない場合、プロファイル管理モジュール404は、システム100にアクセスすることを試みるユーザがそうすることを認められるべきではないと決定し、その効果に対するメッセージが生成され得る。プロファイル管理モジュール404によって出力されるメッセージは次いで、クライアントデバイス104とともに提供される適切な出力デバイス、たとえば画面にレンダリングするために、出力モジュール410に送信され得る。出力モジュール412は、ネットワーク106を介して送信されるインスタントプッシュ通知を通じて、データをクライアントデバイス104に送信し得る。当業者に知られている電子メール、SMS、MMS、IM、または他の適切な通信手段も適用され得る。
【0062】
システム100へのアクセスをユーザが許可されると、各クライアントデバイス104から受信モジュール402において受信される入力データは要求データも備えてもよく、これは、リアルタイムで受信され、1人または複数のユーザが仮想会場へのアクセス(すなわち、ライブマルチメディアコンテンツへのアクセス)の許可を要求していることを示す。要求データは、ユーザによって要求されるアクセス権の数の標示を備え得る。要求データは、各ユーザがアクセス権の購入を望むアクセス権カテゴリを特定するユーザ固有の基準、ならびにユーザが入力した基準に従って各ユーザがアクセス権を獲得するために支払う意思のある価格を示す情報を含み得る。以下でさらに論じられるように、要求データは次いで、仮想会場管理モジュール406に送信され、これは、ユーザの要求に基づいてアクセス権をユーザに認める(または拒否する)ように構成され、アクセス権は、獲得されると、ユーザが仮想会場へのアクセスを得てライブマルチメディアコンテンツを見ることを可能にする。
【0063】
アクセス権はまとめられてもよいことを理解されたい。たとえば、複数のライブイベントへの3つのアクセス権の束が、固定価格(たとえば、24.99ドル)で購入されてもよい。いくつかの実施形態では、ユーザは、自分が選択した価格を(ライブイベントの前、間、または後に)支払うことによって、アクセス権を獲得し得る。これは、たとえば、コンテンツプロバイダ108によって慈善目的で開催され放送され得る、生の慈善(またはチャリティ)興行の場合であり得る。いくつかの実施形態では、イベントは、すべてのユーザが仮想会場にアクセスすれば無料で参加できてもよい。しかしながら、ユーザは、(自分で選択した金額の)寄付を行うように勧められてもよい。他の実施形態では、イベントに参加するために(すなわち、仮想会場にアクセスしてマルチメディアコンテンツを見るために)、最低価格(すなわち、寄付)がユーザに求められてもよい。
【0064】
要求データは、受信モジュール402においても受信され得る支払データ(たとえば、クレジットカード情報、金融口座番号、口座引き落としの承認、電子資金移動情報、および他の関連する支払情報)と関連付けられ得る。支払データが受信されると、受信モジュール402は、支払データを支払処理モジュール408に送信し、これは、支払データを処理して支払いに進む。具体的には、支払処理モジュール408は、支払データ通りにユーザのクレジットカードまたは金融口座に課金し得る。代替として、支払データは、プロファイル管理モジュール404から直接受信され得る。これは、たとえば、ユーザが、自分の支払情報を入力するのではなく、自分のプロファイルにおいて提供される記憶されている情報、たとえばクレジットカード情報を使用して支払いに進むことを選ぶ場合であり得る。ユーザはまた、自分のプロファイルに関連する記憶されている支払値を使用することを選んでもよい。したがって、支払情報は、ユーザのプロファイルから取り出されて、ユーザがアクセス権を購入すると支払処理モジュール408に直接送信され得る。次いで、支払処理モジュール408の出力(たとえば、支払完了)が出力モジュール410に送信されてもよく、これは、クライアントデバイス104のインターフェース、たとえば画面にレンダリングされるべきデータを備える出力信号を生成する。
【0065】
一実施形態では、ユーザは、SYSTEM AND METHOD FOR MANAGING EVENT ACCESS RIGHTSという表題の同時係属中の米国出願第15/575,770号、およびSYSTEM AND METHOD FOR EVENT ADMISSIONという表題の特許協力条約(PCT)出願第PCT/CA2019/051418号において記述される方式で、アクセス権を割り振られ、または認められてもよく、これらの出願の開示全体が、参照によって本明細書に組み込まれる。一実施形態では、ユーザがアクセス権を獲得するために応札する、リアルタイム入札手続が適用されてもよい。本明細書において使用される場合、「購入する」という用語は、したがって、所与の金額の支払と引き換えにアクセス権がユーザにより獲得され得る手続(限定はされないが、入札手続を含む)を指す。いくつかの実施形態では、本明細書において上で説明された方式でシステム100によって認証された(および、したがってシステム100に登録された)ユーザのみが、応札することを許可されてもよい。他の実施形態では、登録されていてもいなくても、すべてのユーザが応札することを許可される。したがって、受信モジュール402において取得される要求データは、受信された応札を示す応札データを備えてもよく、支払処理モジュール408は、事前に承認された支払に進み、続いて、成功した(または勝利した)応札についてのみ(仮想会場へのアクセスを要求するすべてのユーザについてではなく)、(たとえば、ユーザのクレジットカード、金融口座などに課金することによって)支払いを処理する。
【0066】
仮想会場管理モジュール406は次いで、マルチメディアコンテンツを見るための仮想会場へのアクセスを成功した応札者に与えるアクセス権を、成功した応札者に認め得る。この目的で、仮想会場管理モジュール406は、各々の勝利した応札者のプロファイルに関連する固有の暗号化されたトークンをアクティブ化する。トークンのアクティブ化は、ユーザの応札が有効であると認識されたことを示す。各トークンは、ユーザの応札に関する制約に従ってアクティブ化される。たとえば、より高額な(たとえば、500ドルを超える)成功した応札は、応札したユーザが、より低額な成功した応札と比較して、より高いオーディオおよびビデオ品質のコンテンツを見ること、よりカメラ角度が良いコンテンツを見ること、所定の(たとえば、より長い)時間コンテンツを見ること、ウェブカメラ寄与者になること、および/または生で取り上げられて演者とリアルタイムで交流すること(図3Aおよび図3Bに関して本明細書において説明されたように)を可能にし得る。異なる価格は、限定はされないが、標準画質(SD)、高画質(HD)、4K、および8Kを含む、異なるコンテンツ視聴品質または解像度とも関連付けられ得る。したがって、異なるユーザは、所望の視聴品質に応じて異なる価格を支払い得る(すなわち、異なる金額の応札を行う)。
【0067】
仮想会場管理モジュール406は次いで、成功したまたは勝利した応札者に対して、応札者のアクセス権に関連する制約に従ってライブコンテンツを見るために仮想会場へのアクセスを得ることを承認する。一実施形態では、承認は、勝利した応札者に固有のアクセスコードを出すことによって与えられてもよく、アクセスコードは、応札者が仮想会場にアクセスすることを可能にする。別の実施形態では、アクセスコードは提供されなくてもよく、仮想会場にアクセスしようとするユーザが実際に成功した応札者のうちの一人であり、したがって生放送を見るための仮想会場へのアクセスを承認されていることを確認するために、各ユーザのプロファイルからの情報(たとえば、トークンアクティブ化情報)が取り出されてもよい。
【0068】
仮想会場管理モジュール406はさらに、購入されたアクセス権に関連する制約に従って、ユーザにより見られるコンテンツをリアルタイムで管理し得る。一実施形態では、これは、それに従って図1のスイッチャユニット118、エンコーダシステム120、およびストリーミングサーバ122を制御することによって達成される。図2Aおよび図2Bを参照して上で論じられたように、例示として、演者は、カメラ204、208、および、ライブイベントを見ている何人かのユーザが取り上げられる複数の画面2061、2062、2063に対面している。ユーザの反応をコンテンツプロバイダ(図1の参照番号108)により放送されるライブパフォーマンスと同期させるために、仮想会場管理モジュール406は、ストリーミングサーバ122(図1の参照番号)に放送のタイミングとビデオ品質をリアルタイムで調整させる。この目的で、仮想会場管理モジュール406は、受信モジュール402を介してコンテンツプロバイダ108から、スタジオ(図2Aの参照番号200)において記録されたオーディオおよびビデオ信号を受信するように構成される。仮想会場管理モジュール406はまた、システム100で承認されたクライアントデバイス104からウェブカメラフィード信号を受信する。受信された信号は次いで、電子的にタイムスタンプを押される(すなわち、信号が受信される時刻を特定する文字列または符号化された情報を割り当てられる)。大勢の聴衆を仮定すると、仮想会場管理モジュール406は、ストリーミングサーバ122(図1の参照番号)に所定の時間遅延(たとえば、人工的な30秒のバッファ)を信号に導入するためにタイムスタンプを使用させ、その後、ストリーミングサーバ122に、その遅延を有するストリームを生成させてクライアントデバイス104へ送信させる。これは、ライブイベントがスタジオにおいて撮影される瞬間と、ストリームがクライアントデバイス104に配信される瞬間との間に遅延をもたらす。このようにして、ストリーミングサーバ122によって配信されるストリームの視聴品質は、クライアントデバイス104の技術仕様(たとえば、帯域幅、接続速度)に基づいて、すべてのクライアントデバイス104の間で同期される。
【0069】
図3Aを参照して上で論じられたように、仮想会場管理モジュール406はさらに、ユーザのアクセス権に従ってユーザをリアルタイムで優先するように構成される。仮想会場管理モジュール406は実際に、様々な選択基準に基づいて、ライブイベントに寄与すべき、自分のウェブカメラフィードを放送する何人かのユーザを選択する(すなわち、放送の間の生の交流のために優先されるクライアントデバイス104のサブセットを選択する)ことができる。具体的には、大勢の聴衆(たとえば、数千人の参加者)およびライブイベントの間の任意の所与の時間に演者に見える限られた数(たとえば、50から100)の画面(図2Aおよび図2Bの参照番号2061、2062、2063)を仮定すると、ウェブカメラ寄与者になることができる限られた数のクライアントデバイス104を選択するのが望ましい。クライアントデバイス104のサブセットは、2061、2062、2063におけるように画面の数に従って選択される。
【0070】
仮想会場管理モジュール406は、複数の選択基準に基づいてクライアントデバイス104のサブセットを選択するように構成され得る。この目的で、システム100は、自分のクライアントデバイス104で放送を現在(たとえば、最後の5秒以内に、または任意の他の適切な期間にわたって)見ているあらゆるユーザを追跡する。仮想会場管理モジュール406は次いで、各ユーザのプロファイル情報をユーザのアクセス権に関連するプロパティとともに使用して、生で取り上げられるべきユーザ(およびしたがって、クライアントデバイス104のサブセット)を選択する。たとえば、仮想会場管理モジュール406は、限定はされないが、年齢、性別、位置、およびアクセス権を購入するために支払われた額を含むパラメータに基づいて、ユーザをフィルタリングし得る。
【0071】
一実施形態では、1つのデバイス104のウェブカメラフィードが各画面で取り上げられるように、サブセットの中のデバイス104の数は2061、2062、2063におけるように画面の数に対応する。別の実施形態では、複数のユーザのウェブカメラフィードが任意の所与の画面で取り上げられるように、2061、2062、2063におけるような画面の数より多くのデバイス104がサブセットを形成するために選択される。たとえば、全体で10000人の参加者がライブイベントを見るために仮想会場へのアクセスを認められ、2061、2062、2063におけるように全体で10個の画面が放送スタジオ200に設置される場合、10人のユーザのウェブカメラフィードが、演者が見るために2061、2062、2063におけるように各画面に提示されるように、仮想会場管理モジュール406は、クライアントデバイス104のサブセットを形成するために100人のユーザを選択し得る。一実施形態では、ウェブカメラ寄与者になるための機会をいくつかのクライアントデバイス104(およびしたがって何人かのユーザ)が有するように、クライアントデバイス104のサブセットはライブイベントの間に交替する。
【0072】
一実施形態では、仮想会場管理モジュール406は、クライアントデバイス104(すなわち、優先されるクライアントデバイス104)のサブセットをランダムに選択する。これは、すべてのユーザが等しい金額でアクセス権を購入した場合であり得る。別の実施形態では、仮想会場管理モジュール406は、(たとえば、コンテンツプロバイダ108からの)手動入力に基づいてクライアントデバイス104のサブセットを選択する。さらに別の実施形態では、ユーザ(すなわち、勝利した応札者)により見られるコンテンツは、各応札に関連する金額および/または制約に基づいてリアルタイムで管理される。この場合、仮想会場管理モジュール406は、ユーザの購入されたアクセス権に関連する金額に従って、クライアントデバイス104のサブセットを選択し得る。たとえば、より高い金額(たとえば、500ドルを超える)の成功した応札は、より優先度の低いユーザに関連するより低い金額(たとえば、500ドル未満)の成功した応札とは異なり、その応札を行ったユーザ(すなわち、より優先度の高いユーザ)がウェブカメラ寄与者になることを可能にし得る。
【0073】
さらに別の実施形態では、仮想会場管理モジュール406は、ユーザにより生成されたコンテンツの品質に基づいて、生放送に寄与すべきウェブカメラフィードを選択するために、MLおよび/またはAI技法を実装する。たとえば、MLおよび/またはAI技法は、クライアントデバイス104から受信されたウェブカメラフィードのうちでオーディオおよびビデオ品質がより低いウェブカメラフィードを除去し、それに従って、クライアントデバイス104のサブセットを形成するためにより高品質なウェブカメラフィードを選択するために使用され得る。MLおよび/またはAI技法はまた、ウェブカメラフィードを分析し、望ましいものとして特定された挙動をユーザが示している(たとえば、ライブイベントに対する熱中を表に出して関与を示す、人気のあるまたは印象的なダンスの動きを演じている、など)ウェブカメラフィードを選択し得る。同様に、MLおよび/またはAI技法は、望ましくないものとして特定される挙動をユーザが示している(たとえば、熱中の欠如または不適切な挙動)ウェブカメラフィードを拒絶するために使用され得る。たとえば、仮想会場管理モジュール406は、望ましくない挙動を示しているユーザを生放送から取り除き、生放送がこれらのユーザの望ましくない行動により悪影響を受けないように、これらのユーザを、遅延を有するストリームへ戻すように構成される。したがって、仮想会場管理モジュール406は、最良のユーザにより生成されたコンテンツ(たとえば、ウェブカメラフィード、ライブチャットなど)をユーザにより見られる最終的なストリームへと織り込むように構成され得る。
【0074】
仮想会場管理モジュール406は次いで、クライアントデバイス104の選択されたサブセットのウェブカメラフィードが生放送と同時に(図2Aおよび図2Bの画面2061、2062、2063に、および図3AのGUI300内に)提示されるようにし得る。この目的で、クライアントデバイス104のサブセットは、演者との完全に生の交流に移行し、クライアントデバイス104のサブセットから受信される入力信号は、ストリーミングサーバ(図1の参照番号122)を通じた消費のために、ストリームとともにインデクシングされ得る。クライアントデバイス104が生の交流に移行するとき、クライアントデバイス104のサブセットのユーザは、遅延を有するストリームから遅延が除去されたストリームへと移行することにより、生放送において所定の遅延だけ時間的に前にスキップする。仮想会場管理モジュール406が、ウェブカメラ寄与者になるように(または所定の期間が経過した後)クライアントデバイス104の別のサブセットを選択する場合、クライアントデバイス104の以前のサブセットは遅延を有するストリームに戻され、クライアントデバイス104の以前のサブセットのユーザは、スキップされた遅延の時間の間、生放送を再び見せられる。たとえば、ユーザは、ユーザがウェブカメラ寄与者であった最後の30秒を見せられる。
【0075】
一実施形態では、ウェブカメラフィードは、ストリームに重畳される(またはそれと別様に組み合わせられる)リアルタイムフィード(すなわち、放送遅延が導入されない)である。たとえば、自分のウェブカメラを生放送に寄与させるユーザは、ライブイベントフレーム(図3Aの参照番号302)内に表示される同様にライブイベントを見ている自分の友人を視覚化して彼らとリアルタイムで(図3Aのウェブカメラフレーム304を介して)交流し得る。言い換えると、クライアントデバイス104のサブセットのユーザは、リアルタイムで互いに交流し得る。別の実施形態では、ウェブカメラ寄与者になるように選択されなかった(または自分のウェブカメラ、ビデオレコーダ、またはボイスレコーダをオンにしなかった)ユーザは、仮想会場管理モジュール406によって選択されるウェブカメラ寄与者を(ウェブカメラフレーム304内で)見ることができ、これらの寄与者のウェブカメラフィードは、(ライブイベントフレーム302内で)ユーザによって見られるストリームとウェブカメラフィードを同期するために表示される。したがって、放送遅延は、ウェブカメラフレーム304内に提示されるウェブカメラフィードへと導入されることもされないこともあることを理解されたい。いくつかの実施形態では、ウェブカメラ寄与者のウェブカメラフィードが生放送とリアルタイムで織り込まれる(すなわち、組み合わせられる)ようにするためにウェブカメラ寄与者が選択され得ることが本明細書において説明されるが、ユーザがウェブカメラ寄与者になるように選択されない場合であっても、ユーザは自分のウェブカメラを使用して他者(たとえば、ユーザの友人)と交流してもよいことも理解されたい。
【0076】
図3Bを参照して上で論じられたように、ユーザのグループがウェブカメラ寄与者になるように選択されるとき、コンテンツプロバイダ108は、グループ内の1人または複数のユーザを選択して、それらのユーザを演者とリアルタイムで交流させることが可能である。このようにして、選択されたユーザと演者との間で(クライアントデバイス104と画面2061、2062、および2063を通じて)双方向通信が確立され得る。選択されたユーザは、上で本明細書において説明されたような選択基準の数に基づいて、クライアントデバイス104のサブセットの中から仮想会場管理モジュール406によって選ばれ得る。
【0077】
一実施形態では、仮想会場管理モジュール406は、生で取り上げられることに対する招待状を生成して選択されたクライアントデバイス104に送信し、生で取り上げられることに対する招待状のステータスへのあらゆる変更をユーザに通知する(たとえば、クライアントデバイス104にpingを送る)ように構成され得る。ウェブカメラ寄与者になるための機会をクライアントデバイス104の新しいサブセットが与えられるように、生で取り上げられるクライアントデバイス104のサブセットが交替すべきであるとき、仮想会場管理モジュール406は、クライアントデバイス104の新しいサブセットのユーザにより見られている放送に中断を引き起こし、生で取り上げられることに対する招待状をクライアントデバイス104の新しいサブセットに送信する。前に述べられたように、クライアントデバイス104の新しいサブセットのユーザは、招待状を受け入れ、または断ることによって(たとえば、GUI300を介して)応答することができる。
【0078】
ユーザ(すなわち、クライアントデバイス104)が生で取り上げられることについて交替させられるべきであるとき、仮想会場管理モジュール406は、画面2061、2062、2063上で交替させられる(すなわち、生で取り上げられる)ユーザが、ユーザがアクセスできるマルチメディアコンテンツを消費する(すなわち、見る)ことしか許可されないことを確実にするように構成される。この目的で、仮想会場管理モジュール406は、放送の特定のセグメント(たとえば、ビデオセグメント)がいつ開始して終了するかを制御するように構成される。セグメントが終了したものとして仮想会場管理モジュール406によってマークされるとき、仮想会場管理モジュール406は、そのセグメントへのアクセスだけを購入したユーザのクライアントデバイス104に表示される放送を、中継モードへ入らせる。仮想会場管理モジュール406はさらに、ユーザが放送のさらなるセグメントへのアクセスを失うようにする。結果として、アーティストと現在アクティブに交流しているあらゆるユーザが、生の交流から自動的に取り除かれ、遅延(生の交流に移行することによりスキップされた)を有するストリームに戻される。仮想会場管理モジュール406は、ストリームの次のセグメントへのアクセスを有する他のユーザが、アーティストとの交流を続けて画面2061、2062、2063上で取り上げられたままになることを可能にする。仮想会場管理モジュール406は、遅延が取り除かれたストリームから取り除かれたユーザにより空いた空間を埋めるのに必要なだけの数の、ストリームの次のセグメントへのアクセスを有する新しいユーザを、自動的に招待するように構成され得ることを理解されたい。
【0079】
ここで図5を参照すると、一実施形態による、仮想会場の聴衆にライブマルチメディアコンテンツをストリーミングするための方法500がここで説明される。例示として、方法500は、ステップ502において、ライブパフォーマンスを記録して、仮想会場内でライブパフォーマンスをオンラインで放送するステップを備える。ステップ504において、仮想会場およびライブコンテンツへのアクセスがリアルタイムで管理される。図6に示されるように、ステップ504は、仮想会場へのアクセスを得るための要求をユーザからリアルタイムで受信するステップ(ステップ602)を備える。次のステップ604は次いで、要求を行ったユーザが認証されたユーザであるかどうかを評価することである。本明細書において使用される場合、「認証されたユーザ」という用語は、システム100の機能へのアクセスを与える目的で図1のシステム100により認証された(たとえば、本明細書において上で論じられたように固有の識別子を通じてシステム100に登録された)ユーザを指す。ユーザが認証されていないとステップ604において決定される場合、方法500はステップ602に戻り得る。そうではなく、ユーザが認証されたユーザであるとステップ604において決定される場合、次のステップ606は、認証されたユーザのうちのある数のユーザに、仮想会場およびライブコンテンツへのアクセスを認めることである。一実施形態では、仮想会場へのアクセスは、購入されたアクセス権に基づいて(本文書の他の箇所で説明されるアクセス権を認め、または割り振るための機構に基づいて)認められるので、ステップ606は、本明細書において上で説明された方式で、認証されたユーザに対する支払いを処理するステップを備え得る。別の実施形態では、仮想会場へのアクセスはランダムに認められるので、認証されたユーザのうちのあるランダムな数のユーザがライブコンテンツへのアクセスを認められる。さらに別の実施形態では、すべての認証されたユーザが仮想会場へのアクセスを認められ得る。限定はされないが、本明細書において説明された仮想会場へのアクセスを認めるための他の方法を含む他の実施形態が、適用されてもよい。
【0080】
図7に示されるように、例示として、ステップ606は、タイムスタンプを使用して、仮想会場へのアクセスを認められたユーザのためのストリームを作成するステップ(ステップ702)を備える。本明細書において上で説明されたように、仮想会場内のライブコンテンツを見ているすべてのユーザの間での視聴品質の同期(たとえば、ストリーミングされているライブイベントとの聴衆の反応の同期)を可能にするために、所定の遅延がストリームに導入される。次のステップ704は、次いで、ウェブカメラ寄与者になるようにユーザのサブセットを選択し、ユーザのサブセットを演者との生の交流に移行することであり、ここで、ユーザのサブセットの入力(たとえば、ウェブカメラフィード信号)が、本明細書において上で説明された方式でストリームとともにインデクシングされ得る。具体的には、ユーザのサブセットについて遅延が取り除かれ、ユーザのサブセットのウェブカメラフィード信号が、物理位置において(たとえば、画面2061、2062、および2063に)レンダリングされる。ステップ706において、演者とのリアルタイムの交流も、サブセットからの所与のユーザに対して可能にされ得る。
【0081】
ステップ704および706において行われる選択は、ランダムであってもよく、または、限定はされないが、本明細書において上で説明されたように、仮想会場へのアクセスを得るために各ユーザによって購入されるアクセス権、およびユーザにより生成されたコンテンツの品質を含む、いくつかの選択基準に基づいてもよい。選択はまた、(たとえば、コンテンツプロバイダ108からの)手動入力に基づいてもよいことを理解されたい。選択はまた、本明細書において上で説明されたように、自分のウェブカメラをオンにしたユーザから受け取られる入力に基づいて、AI/ML技法を使用してもよい。ユーザは、ステップ704および706において行われた選択を受け入れ、もしくは拒否する、すなわち、ウェブカメラ寄与者になることを受け入れ、もしくは拒否するという選択肢、または演者とリアルタイムで交流するという選択肢を与えられ得ることも理解されたい。所定の期間の後、ユーザのサブセットは次いで、遅延を有するストリームに戻される(ステップ708)。次のステップ710は次いで、生のイベントの終わりに達したかどうかを評価することであり得る。達している場合、方法500は終了し得る。そうではない場合、方法500はステップ704に戻り、ウェブカメラ寄与者になるべきユーザの別のサブセットを選択し得る。
【0082】
別々のデータ信号接続を介して互いに通信する個別のコンポーネントのグループとしてブロック図において示されているが、本実施形態は、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せによって提供され、一部のコンポーネントがハードウェアシステムまたはソフトウェアシステムの所与の機能もしくは動作によって実装され、示されるデータパスの多くがコンピュータアプリケーションまたはオペレーティングシステム内のデータ通信によって実装されることが、当業者により理解されるだろう。したがって、示される構造は、本実施形態の教示を効率的にするために与えられるものである。
【0083】
本発明は、方法として実行することができ、システムにおいて、および/またはコンピュータ可読媒体上で具現化できることに留意されたい。上で説明された本発明の実施形態は、例示的であるものとしてのみ意図されている。したがって、本発明の範囲は、添付の特許請求の範囲のみによって限定されることが意図される。
【符号の説明】
【0084】
102 サーバ
104 クライアントデバイス
106 ネットワーク
108 コンテンツプロバイダ
110 プロセッサ
112 メモリ
114 アプリケーション
116 アプリケーション
118 スイッチャユニット
120 エンコーダシステム
122 ストリーミングサーバ
202 シーン
204 カメラ
206 画面
208 カメラ
302 ライブイベントフレーム
304 ウェブカメラフレーム
306 ボタン
308 自画像フレーム
402 受信モジュール
404 プロファイル管理モジュール
406 仮想会場管理モジュール
408 支払処理モジュール
410 出力モジュール
図1
図2A
図2B
図3A
図3B
図4
図5
図6
図7
【国際調査報告】