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

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

▶ 17LIVE株式会社の特許一覧

<>
  • 特許-コンピュータプログラム、端末及び方法 図1
  • 特許-コンピュータプログラム、端末及び方法 図2
  • 特許-コンピュータプログラム、端末及び方法 図3
  • 特許-コンピュータプログラム、端末及び方法 図4
  • 特許-コンピュータプログラム、端末及び方法 図5
  • 特許-コンピュータプログラム、端末及び方法 図6
  • 特許-コンピュータプログラム、端末及び方法 図7
  • 特許-コンピュータプログラム、端末及び方法 図8
  • 特許-コンピュータプログラム、端末及び方法 図9
  • 特許-コンピュータプログラム、端末及び方法 図10
  • 特許-コンピュータプログラム、端末及び方法 図11
  • 特許-コンピュータプログラム、端末及び方法 図12
  • 特許-コンピュータプログラム、端末及び方法 図13
  • 特許-コンピュータプログラム、端末及び方法 図14
  • 特許-コンピュータプログラム、端末及び方法 図15
  • 特許-コンピュータプログラム、端末及び方法 図16
  • 特許-コンピュータプログラム、端末及び方法 図17
  • 特許-コンピュータプログラム、端末及び方法 図18
  • 特許-コンピュータプログラム、端末及び方法 図19
  • 特許-コンピュータプログラム、端末及び方法 図20
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-04-22
(45)【発行日】2022-05-06
(54)【発明の名称】コンピュータプログラム、端末及び方法
(51)【国際特許分類】
   H04L 65/402 20220101AFI20220425BHJP
   H04L 67/06 20220101ALI20220425BHJP
   H04N 21/431 20110101ALI20220425BHJP
   H04N 21/472 20110101ALI20220425BHJP
【FI】
H04L65/402
H04L67/06
H04N21/431
H04N21/472
【請求項の数】 10
(21)【出願番号】P 2021205415
(22)【出願日】2021-12-17
【審査請求日】2022-01-25
【早期審査対象出願】
(73)【特許権者】
【識別番号】517287224
【氏名又は名称】17LIVE株式会社
(74)【代理人】
【識別番号】100199277
【弁理士】
【氏名又は名称】西守 有人
(72)【発明者】
【氏名】江良澤
(72)【発明者】
【氏名】宋竹凱
【審査官】今川 悟
(56)【参考文献】
【文献】特開2021-077388(JP,A)
【文献】特開2018-049669(JP,A)
【文献】特開2009-071699(JP,A)
【文献】中国特許出願公開第112287848(CN,A)
【文献】特開2020-101902(JP,A)
【文献】特開2015-115057(JP,A)
【文献】特開2012-120098(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 65/402
H04L 67/06
H04N 21/431
H04N 21/472
(57)【特許請求の範囲】
【請求項1】
端末に、
ライブ配信に係る動画データの再生中に、第1タイプのギフトを表す第1ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、
前記端末のユーザによる前記第1ユーザインタフェースオブジェクトの指定を受け付けた場合、前記端末の保持部に保持されている、前記第1ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する機能と、
前記動画データの再生中に、第2タイプのギフトを表す第2ユーザインタフェースオブジェクトを前記ディスプレイに表示させる機能と、
ユーザによる前記第2ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第2ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能と、を実現させるためのコンピュータプログラム。
【請求項2】
前記ダウンロードのステータスを示すインジケータを前記第2ユーザインタフェースオブジェクトに関連付けて前記ディスプレイに表示させる機能をさらに前記端末に実現させる請求項1に記載のコンピュータプログラム。
【請求項3】
前記第1タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記第1ユーザインタフェースオブジェクトが指定される前に、ユーザによる指示を介さずに開始する機能をさらに前記端末に実現させる請求項1または2に記載のコンピュータプログラム。
【請求項4】
前記ユーザによる指示を介さずに開始する機能は、リストを参照することで特定された前記第1タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記第1ユーザインタフェースオブジェクトが指定される前に、ユーザによる指示を介さずに開始する機能を含み、
前記リストは更新可能に構成される請求項3に記載のコンピュータプログラム。
【請求項5】
前記第2タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第2ユーザインタフェースオブジェクトが指定される前には開始されない請求項1から4のいずれか一項に記載のコンピュータプログラム。
【請求項6】
前記第2タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第1タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先される請求項1から5のいずれか一項に記載のコンピュータプログラム。
【請求項7】
前記動画データが配信されている他の端末の他のユーザにより使用されたギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能をさらに前記端末に実現させ、
当該ギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第1タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先され、
前記第2タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、当該ギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先される請求項1から6のいずれか一項に記載のコンピュータプログラム。
【請求項8】
前記ユーザの属性が所定の基準を満たす場合、ギフトのタイプに依らずに、当該ギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記ユーザによる指示を介さずに開始する機能をさらに前記端末に実現させる請求項1から7のいずれか一項に記載のコンピュータプログラム。
【請求項9】
保持手段と、
ライブ配信に係る動画データの再生中に、第1タイプのギフトを表す第1ユーザインタフェースオブジェクトをディスプレイに表示させる手段と、
前記端末のユーザによる前記第1ユーザインタフェースオブジェクトの指定を受け付けた場合、前記保持手段に保持されている、前記第1ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する手段と、
前記動画データの再生中に、第2タイプのギフトを表す第2ユーザインタフェースオブジェクトを前記ディスプレイに表示させる手段と、
ユーザによる前記第2ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第2ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する手段と、を備える端末。
【請求項10】
端末において実行される方法であって、
ライブ配信に係る動画データの再生中に、第1タイプのギフトを表す第1ユーザインタフェースオブジェクトをディスプレイに表示させることと、
前記端末のユーザによる前記第1ユーザインタフェースオブジェクトの指定を受け付けた場合、前記端末の保持部に保持されている、前記第1ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理することと、
前記動画データの再生中に、第2タイプのギフトを表す第2ユーザインタフェースオブジェクトを前記ディスプレイに表示させることと、
ユーザによる前記第2ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第2ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始することと、を含む方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、コンピュータプログラム、端末及び方法に関する。
【背景技術】
【0002】
IT技術の発展と共に情報のやりとりの様も移り変わってきた。昭和の時代には新聞やテレビなどの一方通行の情報伝達が主であった。平成になると、ケータイやパソコンが普及し、インターネットの通信速度も大きく改善されたので、チャットサービスなどの即時双方向通信サービスが台頭し、また記憶コストの低減に伴ってオンデマンド型の動画配信サービスが受け入れられていった。そして、現在、令和の時代となり、スマートフォンの高機能化や5Gに代表されるネットワークの速度のさらなる向上を受けて、動画によるリアルタイムのコミュニケーションを実現するサービス、特にライブ配信サービスが急速に認知度を高めている。ライブ配信サービスは、離れた場所にいても皆が同じ楽しい時間を共有できるサービスとして、若者を中心に利用者が拡大している。
【0003】
投げ銭などのギフトのエフェクトはライブ配信を盛り上げる重要な要素である。数多くの種類のギフトを設け、それぞれのギフトのエフェクトに趣向を凝らすことができれば、ライブ配信のよりいっそうの盛り上がりを期待できる。
【0004】
特許文献1には、ライブ配信中に投銭エフェクト画像を表示することで配信を盛り上げる技術が開示されている。
【先行技術文献】
【特許文献】
【0005】
【文献】特開2020-017870号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ライブ配信では配信者と視聴者とのインタラクションの即時性が要求される。したがって、通常、ギフトのエフェクトを実現するデータは、ユーザからの指示に応じてすぐに使用できるよう予め全てユーザの端末にダウンロードされる。
【0007】
しかしながら、ギフトのエフェクトを実現するデータのサイズは、エフェクトが高機能になるほど大きくなる。しかもそのようなギフトの種類を多くするとと、ギフトのデータを保持するために必要なデータ容量が大きくなる。その結果、ライブ配信のアプリケーションをインストールした端末の容量の大きな部分を当該アプリケーションのデータが占めるようになるので、動作が重くなる、他のアプリケーションのインストールが制限されるなどユーザ利便性を損なう虞がある。
【0008】
本開示はこうした課題に鑑みてなされたものであり、その目的は、ライブ配信においてより高機能なギフトを使用可能としつつ、それによるデータ量の増大を抑えることができる技術の提供にある。
【課題を解決するための手段】
【0009】
本開示のある態様は、コンピュータプログラムに関する。このコンピュータプログラムは、端末に、ライブ配信に係る動画データの再生中に、第1タイプのギフトを表す第1ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、端末のユーザによる第1ユーザインタフェースオブジェクトの指定を受け付けた場合、端末の保持部に保持されている、第1ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する機能と、動画データの再生中に、第2タイプのギフトを表す第2ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、ユーザによる第2ユーザインタフェースオブジェクトの指定を受け付けた場合、第2ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能と、を実現させる。
【0010】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【0011】
本開示の態様によれば、ライブ配信においてより高機能なギフトを使用可能としつつ、それによるデータ量の増大を抑えることができる。
【図面の簡単な説明】
【0012】
図1】本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。
図2図1のライブ配信システムで実現されるライブ配信の一例を示す模式図である。
図3図1のユーザ端末の機能および構成を示すブロック図である。
図4図3の端末側ギフト保持部の一例を示すデータ構造図である。
図5図3のダウンロードキュー保持部の一例を示すデータ構造図である。
図6図1のサーバの機能および構成を示すブロック図である。
図7図6のギフトダウンロードリストの一例を示すデータ構造図である。
図8図6のストリームDBの一例を示すデータ構造図である。
図9図6のユーザDBの一例を示すデータ構造図である。
図10図6のギフトDBの一例を示すデータ構造図である。
図11】ユーザ端末における一連のアプリ起動処理の流れを示すフローチャートである。
図12】ユーザ端末における一連のダウンロード処理の流れを示すフローチャートである。
図13】ユーザ端末における一連のギフト使用処理の流れを示すフローチャートである。
図14】視聴者のユーザ端末のディスプレイに表示されるライブ配信選択画面の代表画面図である。
図15】視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。
図16】視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。
図17】視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。
図18】視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。
図19】視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。
図20】実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。
【発明を実施するための形態】
【0013】
以下、各図面に示される同一または同等の構成要素、部材、処理、信号には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。
【0014】
実施の形態に係るライブ配信システムでは、全てのギフトについてエフェクトを実現するデータ(以下、エフェクトデータという)をユーザ端末にダウンロードさせるのではなく、ギフトを、エフェクトデータを予めダウンロードしておくプレロードタイプとそうでない要ロードタイプとに分ける。視聴者が要ロードタイプのギフトの使用を希望する場合、視聴者が当該ギフトのアイコン(以下、ギフトアイコンという)をタップすることでまずは当該ギフトのエフェクトデータのダウンロードが開始される。ダウンロードが完了すると、視聴者は当該ギフトを使用することができる。使用頻度の低いギフトを要ロードタイプのギフトとすることができる。
【0015】
これにより、各ギフトのエフェクトデータのサイズが大きくなったとしても、ギフトのプレロードにかかる時間の増大を抑えることができ、またプレロードされたエフェクトデータのトータルサイズの増大も抑えることができる。その結果、サイズの大きなエフェクトデータを用いてより豊かなアニメーションや音声などの表現を可能としつつ、ユーザ端末に要求される通信性能や容量の増大を抑えることができる。加えて、プレロードタイプのギフトは使用時にダウンロードを要しないギフトなので、このプレロードタイプのギフトについては配信者と視聴者とのインタラクションの即時性を担保することができる。
【0016】
このように、本実施の形態は、ギフトのダウンロードプロセスを最適化することでギフトのダウンロードサイズを低減し、もって良好なユーザ体験および端末への低負荷を両立させることができる。
【0017】
[ライブ配信システムの構成]
図1は、本開示の実施の形態に係るライブ配信システム1の構成を示す模式図である。ライブ配信システム1は、配信者(ライバー、ストリーマ(Streamer)ともいう)LVと視聴者(オーディエンスともいう)AU(AU1、AU2、…)とがリアルタイムでやりとりできる双方向型のライブ配信サービスを提供する。図1に示すように、ライブ配信システム1は、サーバ10と、配信者側のユーザ端末20と、視聴者側のユーザ端末30(30a、30b、…)と、を備える。配信者および視聴者をユーザと総称することがある。サーバ10は、ネットワークNWに接続された一または複数の情報処理装置によって構成されてもよい。ユーザ端末20、30は例えばスマートフォンやタブレット型端末やラップトップPCやレコーダや携帯型ゲーム機やウェアラブル装置などの携帯端末であってもよいし、デスクトップPCなどの据え置き型の装置であってもよい。サーバ10、ユーザ端末20およびユーザ端末30は、有線または無線の各種ネットワークNWにより互いに通信可能に接続される。
【0018】
ライブ配信システム1には、配信者LVと、視聴者AUと、サーバ10を管理する管理者(不図示)と、が関与する。配信者LVは、自分の歌や、トーク、パフォーマンス、占い、ゲーム実況などのコンテンツを自身のユーザ端末20で録音・録画してそのままサーバ10にアップロードすることで、リアルタイムにコンテンツを発信する者である。管理者は、サーバ10においてコンテンツのライブ配信のためのプラットフォームを提供し、また、配信者LVと視聴者AUとのリアルタイムのやりとりを仲介または管理する。視聴者AUは、ユーザ端末30でプラットフォームにアクセスして所望のコンテンツを選択し、視聴する。このコンテンツのライブ配信中に視聴者AUがユーザ端末30を介してコメントをしたり応援するための操作を行い、当該コンテンツを提供する配信者LVがそのようなコメントや応援に反応し、当該反応が映像および/または音声で視聴者AUに伝わることで、双方向のコミュニケーションが成立する。
【0019】
本明細書において「ライブ配信」は、配信者LVのユーザ端末20で録音・録画されたコンテンツが実質的にリアルタイムで視聴者AUのユーザ端末30で再生され視聴可能となる状態を実現するデータの伝送態様を意味するものであってもよく、またはそのような伝送態様により実現される配信そのものを意味してもよい。ライブ配信は、HTTP Live StreamingやCommon Media Application FormatやWeb Real-Time CommunicationsやReal-Time Messaging ProtocolやMPEG DASHなどの既存のライブストリーミング技術を用いて実現されてもよい。ライブ配信は、配信者LVがコンテンツを録音・録画しているときに、視聴者AUが所定の遅延をもって当該コンテンツを視聴可能な伝送態様を含む。遅延の大きさについて、少なくとも、配信者LVと視聴者AUとのやりとりが成立する程度の大きさの遅延は許される。ただし、ライブ配信は、コンテンツを録音・録画したデータ全体をいったんサーバに保存し、その後の任意のタイミングでユーザからの求めに応じて当該データをユーザに提供するいわゆるオンデマンド型の配信とは区別される。
【0020】
本明細書において「動画データ」は、ユーザ端末20、30の撮像機能により生成される画像データ(ビデオデータともいう)と、ユーザ端末20、30の音声入力機能により生成される音声データ(オーディオデータともいう)と、を含むデータである。動画データは、ユーザ端末20、30で再生されることで、ユーザによるコンテンツの視聴を可能とする。
【0021】
図2は、図1のライブ配信システム1で実現されるライブ配信の一例を示す模式図である。図2の例では、配信者LVがトークをライブ配信している。配信者LVのユーザ端末20はトークを行っている配信者LVの像および音声を録画・録音することで動画データを生成し、ネットワークNWを介してサーバ10(図2では不図示)に送信する。併せてユーザ端末20は、録画された配信者LVの動画像VDをユーザ端末20のディスプレイに表示させることで、配信者LVによる配信内容の確認を可能とする。
【0022】
配信者LVのライブ配信の視聴をプラットフォームに要求した視聴者AU1、AU2、AU3のユーザ端末30a、30b、30cはそれぞれ、ネットワークNWを介してライブ配信に係る動画データを受信し、受信した動画データを再生することでディスプレイに動画像VD1、VD2、VD3を表示させると共にスピーカーから音声を出力する。各ユーザ端末30a、30b、30cで表示される動画像VD1、VD2、VD3は配信者LVのユーザ端末20が撮像した動画像VDと実質的に同一であり、各ユーザ端末30a、30b、30cで出力される音声も配信者LVのユーザ端末20が録音した音声と実質的に同一である。
【0023】
配信者LVのユーザ端末20における録音・録画と、視聴者AU1、AU2、AU3のユーザ端末30a、30b、30cにおける動画データの再生と、は実質的に同時に行われる。配信者LVのトークの内容についてひとりの視聴者AU1がコメントをユーザ端末30aに入力すると、サーバ10は当該コメントをリアルタイムで配信者LVのユーザ端末20に表示させると共に各視聴者AU1、AU2、AU3のユーザ端末30a、30b、30cにも表示させる。当該コメントを読んだ配信者LVがその内容に被せたトークを展開すると、そのトークの動画像と音声が各視聴者AU1、AU2、AU3のユーザ端末30a、30b、30cで出力され、これにより配信者LVと視聴者AU1との会話が成立したと認識される。このように、ライブ配信システム1では、一方通行でない双方向のコミュニケーションを可能とするライブ配信が実現される。
【0024】
図3は、図1のユーザ端末20の機能および構成を示すブロック図である。ユーザ端末30はユーザ端末20と同様の機能および構成を有する。図3および以後のブロック図に示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【0025】
配信者LVおよび視聴者AUは、ダウンロードサイトからネットワークNWを介して、本実施の形態に係るライブ配信アプリケーションプログラム(以下、ライブ配信アプリという)をユーザ端末20、30にダウンロードし、インストールする。あるいはまた、ライブ配信アプリはユーザ端末20、30にプリインストールされていてもよい。ライブ配信アプリがユーザ端末20、30により実行されることにより、ユーザ端末20、30はネットワークNWを介してサーバ10と通信し、各種機能を実現する。以下、ユーザ端末20、30(のCPUなどのプロセッサ)がライブ配信アプリを実行することにより実現する機能をユーザ端末20、30の機能として説明する。それらの機能は実際はライブ配信アプリがユーザ端末20、30に実現させる機能である。なお、他の実施の形態では、これらの機能は、サーバ10からユーザ端末20、30のウェブブラウザにネットワークNWを介して送信され、そのウェブブラウザによって実行される、HTML(HyperText Markup Language)などのプログラミング言語により記述されたコンピュータプログラムにより実現されてもよい。
【0026】
ユーザ端末20は、ユーザの像および音声を記録した動画データを生成してサーバ10に提供する配信部100と、サーバ10から動画データを取得して再生する視聴部200と、ユーザ端末20においてギフトの情報を保持する端末側ギフト保持部250と、ギフトのダウンロードのキューを保持するダウンロードキュー保持部252と、を備える。ユーザは、配信を行う場合は配信部100を、視聴を行う場合は視聴部200を、それぞれ起動する。配信部100がアクティブとなっているユーザ端末は配信者側、つまり動画データの生成側のユーザ端末であり、視聴部200がアクティブとなっているユーザ端末は視聴者側、つまり動画データの再生側のユーザ端末である。
【0027】
配信部100は、撮像制御部102と、音声制御部104と、動画送信部106と、配信側UI制御部108と、を含む。撮像制御部102は図3では不図示のカメラと接続され、カメラによる撮像を制御する。撮像制御部102はカメラから画像データを取得する。音声制御部104は図3では不図示のマイクロフォンと接続され、マイクロフォンによる音声入力を制御する。音声制御部104は、マイクロフォンから音声データを取得する。動画送信部106は、撮像制御部102により取得された画像データおよび音声制御部104により取得された音声データを含む動画データを、ネットワークNWを介してサーバ10に送信する。動画送信部106による動画データの送信はリアルタイムで行われる。すなわち、撮像制御部102および音声制御部104による動画データの生成と、生成された動画データの動画送信部106による送信と、は実質的に同時に行われる。
【0028】
配信側UI制御部108は、配信者向けのUIを制御する。配信側UI制御部108は、図3では不図示のディスプレイと接続され、動画送信部106による送信対象となっている動画データを再生することにより動画像をディスプレイに表示させる。配信側UI制御部108は、ディスプレイに操作用オブジェクトや指示受け付け用のオブジェクトを表示させ、配信者によるタップ入力を受け付ける。
【0029】
視聴部200は、視聴側UI制御部202と、重畳情報生成部204と、ギフト情報送受信部206と、ギフト判定部208と、キュー制御部210と、を含む。視聴側UI制御部202は、視聴者向けのUIを制御する。視聴側UI制御部202は、図3では不図示のディスプレイおよびスピーカと接続され、受信した動画データを再生することにより動画像をディスプレイに表示させると共に音声をスピーカから出力させる。ディスプレイに画像が出力されると共にスピーカから音声が出力されることを、合わせて「動画データが再生」されていると言うことができる。視聴側UI制御部202は、図3では不図示のタッチパネルやキーボードやディスプレイなどの入力手段と接続され、それら入力手段を介してユーザ入力を取得する。重畳情報生成部204は、サーバ10から取得された動画データの画像に所定のフレーム画像を重畳させる。フレーム画像は、ユーザから入力を受け付けるための様々なユーザインタフェースオブジェクト(以下、単にオブジェクトという)と、視聴者により入力されたコメントと、サーバ10から取得した情報と、を含む。
【0030】
視聴側UI制御部202および重畳情報生成部204は共同で、ライブ配信に係る動画データの再生中に、プレロードタイプのギフトを表すギフトアイコンと、要ロードタイプのギフトを表すギフトアイコンと、をディスプレイに表示させる。
【0031】
ギフト情報送受信部206は、サーバ10との間でギフトに関連する情報を送受信する。ギフト判定部208は、ギフトのタイプを判定する。キュー制御部210は、ダウンロードキュー保持部252を制御する。
【0032】
図4は、図3の端末側ギフト保持部250の一例を示すデータ構造図である。端末側ギフト保持部250は、ユーザ端末20がダウンロードしたギフトの情報を保持する。ギフトは、以下の特徴を有する電子データである。
・ポイント(後述)を対価として購入可能、または無料で付与可能。
・視聴者が配信者に贈ることができるもの。配信者にギフトを贈ることを、ギフトを使用する、またはギフトを投げるという。
・ギフトの購入と使用とがセットで同時に発生するタイプのものもあれば、購入または付与された後、視聴者が任意のタイミングで使用可能なタイプのものもある。
・視聴者が配信者にギフトを贈ると、その配信者に相応のポイントが付与され、かつ、ギフトに関連付けられた効果が生じる。例えば、ギフトに対応するエフェクトがライブ配信画面に表れる。
【0033】
端末側ギフト保持部250は、ギフトを特定するギフトIDと、当該ギフトを表すオブジェクトであるアイコンのデータ(以下、アイコンデータという)と、当該ギフトに対応するエフェクトを実現するためのデータ(以下、エフェクトデータという)と、当該ギフトが最後に使用された日付である最終更新日と、を対応付けて保持する。視聴者は、ライブ配信視聴中に、所望のギフトに対応する対価を支払うことで配信者に当該ギフトを贈ることができる。この対価の支払いは適宜の電子的決済手段により行われてもよく、例えば対価に相当するポイントを視聴者が管理者に支払うことで行われてもよい。あるいはまた、銀行振込やクレジットカードによる支払いが用いられてもよい。
【0034】
エフェクトは、ギフトを特徴付ける視覚的効果または聴覚的効果または触覚的効果(例えば、振動)またはそれらの組み合わせである。視覚的効果には、アニメーションと、画像と、点灯・点滅と、がある。聴覚的効果には、効果音と、音声と、がある。エフェクトデータはこのようなエフェクトをユーザ端末20において実現するためのデータであり、ユーザ端末20はエフェクトデータを処理することでこのようなエフェクトを実現する。エフェクトデータそのものを実現する技術は公知であるから本明細書では詳述しない。
【0035】
端末側ギフト保持部250には予め全てのギフトのギフトIDとアイコンデータとが格納される。ギフト情報送受信部206は、サーバ10からギフトのエフェクトデータをダウンロードし、端末側ギフト保持部250に格納する。ギフト情報送受信部206がエフェクトデータをサーバ10からダウンロードしていないギフトも存在する。
【0036】
図5は、図3のダウンロードキュー保持部252の一例を示すデータ構造図である。ダウンロードキュー保持部252はギフトのダウンロードのキューを保持する。ダウンロードキュー保持部252は、ダウンロードの順番と、ギフトIDと、を対応付けて保持する。ギフト情報送受信部206はダウンロードキュー保持部252を参照し、その順番に従って順次ギフトのエフェクトデータをサーバ10に要求し、サーバ10からダウンロードする。
【0037】
図6は、図1のサーバ10の機能および構成を示すブロック図である。サーバ10は、配信情報提供部302と、中継部304と、ギフト情報提供部306と、ギフト処理部308と、ギフトダウンロードリスト310と、ストリームDB312と、ユーザDB314と、ギフトDB316と、を備える。
【0038】
図7は、図6のギフトダウンロードリスト310の一例を示すデータ構造図である。ギフトダウンロードリスト310は、ユーザ端末20、30がデフォルトでそのエフェクトデータをダウンロードしなければならないギフトを指定するリストである。ギフトダウンロードリスト310に含まれるギフトIDのギフトのエフェクトデータは、ユーザ端末20、30でライブ配信アプリが起動されると自動で、すなわちユーザによる指示を介さずに、当該ユーザ端末20、30にダウンロードされ、端末側ギフト保持部250に格納される。ギフトダウンロードリスト310には領域が設定されており、各ユーザ端末が属する領域ごとにダウンロードすべきギフトがリストされている。
【0039】
ギフトダウンロードリスト310は、領域と、ダウンロードすべきギフトのギフトIDと、を対応付けて保持する。ギフトダウンロードリスト310は更新可能に構成される。ライブ配信システムの管理者は、サーバ10を介してギフトダウンロードリスト310の内容を変更することができる。管理者は、使用頻度が高まることが予想されるギフト(イベント関連のギフトなど)を予めギフトダウンロードリスト310に登録することができる。また、管理者は、使用頻度が低くなったギフトをギフトダウンロードリスト310から除くことができる。
【0040】
図8は、図6のストリームDB312の一例を示すデータ構造図である。ストリームDB312は現在行われているライブ配信の情報を保持する。ストリームDB312は、ライブ配信システム1が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームIDと、当該ライブ配信の配信者を特定する配信者IDと、当該ライブ配信の視聴者を特定する視聴者IDと、を対応付けて保持する。
【0041】
図9は、図6のユーザDB314の一例を示すデータ構造図である。ユーザDB314は、ユーザに関する情報を保持する。ユーザDB314は、ユーザを特定するユーザIDと、当該ユーザが有しているポイントと、当該ユーザのレベルと、を対応付けて保持する。ポイントは、ライブ配信プラットフォーム内で流通する電子的価値である。配信者がライブ配信において視聴者からギフトを贈られると、配信者のポイントが当該ギフトに対応する値だけ増加する。ポイントは例えば配信者がライブ配信プラットフォームの管理者から受け取る報酬または金銭の額を決めるために用いられる。レベルは、ライブ配信プラットフォームにおけるユーザの活動の量を示す指標である。ユーザが視聴者としてギフトを贈る、配信者としてライブ配信を行う、イベントに参加する、などにより当該ユーザのレベルが上がる。サーバ10は、ユーザの活動の履歴から当該ユーザのレベルを算出する。
【0042】
図10は、図6のギフトDB316の一例を示すデータ構造図である。ギフトDB316は全てのギフトのアイコンデータとエフェクトデータとを保持する。ギフトDB316は、ギフトを特定するギフトIDと、当該ギフトを配信者に贈った場合に当該配信者に付与されるポイントである付与ポイントと、当該ギフトのアイコンデータと、当該ギフトのエフェクトデータと、を対応付けて保持する。
【0043】
図6に戻り、配信情報提供部302は、ネットワークNWを介して、配信者側のユーザ端末20からライブ配信を開始する旨の通知を受けると、当該ライブ配信を特定するストリームIDと、当該ライブ配信の配信者の配信者IDと、をストリームDB312に登録する。配信情報提供部302は、ネットワークNWを介して、視聴者側のユーザ端末30の視聴部200からライブ配信に関する情報の提供要求を受けると、ストリームDB312を参照して現在視聴可能なライブ配信のリストを生成する。配信情報提供部302は、ネットワークNWを介して、生成されたリストを要求元のユーザ端末30に送信する。要求元のユーザ端末30の視聴側UI制御部202は、受信したリストに基づいてライブ配信選択画面を生成し、ユーザ端末30のディスプレイに表示させる。
【0044】
ユーザ端末30の視聴側UI制御部202は、ライブ配信選択画面における視聴者によるライブ配信の選択を受け付けると、選択されたライブ配信のストリームIDを含む配信要求を生成し、ネットワークNWを介してサーバ10に送信する。配信情報提供部302は、受信した配信要求に含まれるストリームIDにより特定されるライブ配信の、要求元のユーザ端末30への提供を開始する。配信情報提供部302は、当該ストリームIDの視聴者IDに要求元のユーザ端末30の視聴者の視聴者IDが含まれるようにストリームDB312を更新する。
【0045】
中継部304は、配信情報提供部302によって開始されたライブ配信において、配信者側のユーザ端末20から視聴者側のユーザ端末30への動画データの伝送を中継する。中継部304は、視聴者側のユーザ端末30における動画データの再生中における視聴者によるユーザ入力を示す信号を視聴側UI制御部202から受信する。ユーザ入力を示す信号はギフトのエフェクトデータのダウンロードを要求するギフトDL要求信号と、ギフトの使用を示すギフト使用信号と、を含む。ギフトDL要求信号は、ダウンロード対象のギフトのギフトIDを含む。ギフト使用信号は、視聴者の視聴者IDと、贈り先の配信者の配信者ID(=アイテムを贈った視聴者が視聴しているライブ配信を行っている配信者の配信者ID)と、ギフトのギフトIDと、を含む。
【0046】
ギフト情報提供部306は、ギフトに関する情報をユーザ端末20、30に提供する。ギフト情報提供部306は、ユーザ端末からの要求に応じて端末用ギフトダウンロードリストをユーザ端末に送信する。ギフト情報提供部306は、中継部304が受信したギフトDL要求信号に含まれるギフトIDに対応するエフェクトデータをギフトDB316から取得する。ギフト情報提供部306は、取得されたエフェクトデータをギフトDL要求信号への応答として要求元のユーザ端末に送信する。
【0047】
ギフト処理部308は、ギフト使用信号に含まれるギフトIDで特定されるギフトの付与ポイントに応じて配信者のポイントを増加させるようにユーザDB314を更新する。ギフト処理部308は、ギフトDB316を参照し、受信したギフト使用信号に含まれるギフトIDに対応する付与ポイントを特定する。ギフト処理部308は、ギフト使用信号に含まれる配信者IDに対応するポイントに、特定された付与ポイントを加えるようユーザDB314を更新する。
【0048】
以上の構成によるライブ配信システム1の動作を説明する。
図11は、ユーザ端末20、30における一連のアプリ起動処理の流れを示すフローチャートである。ユーザがライブ配信アプリのアイコンをタップすると、ユーザ端末においてライブ配信アプリが起動する(S502)。ユーザ端末は、軽量モードがONになっているか否かを判定する(S504)。軽量モードは、起動時に端末側ギフト保持部250にエフェクトデータが保持されていない全てのギフトを要ロードタイプとするモードである。ユーザ端末は不図示のモード保持部にて軽量モードのON・OFFの別を保持する。ユーザ端末はユーザからの指示に応じて軽量モードのON・OFFを切り替える。軽量モードがONになっている場合(S504のYES)、ユーザ端末はダウンロードキューを更新することなくアプリ起動処理を終了する。
【0049】
軽量モードがOFFになっている場合(S504のNO)、ギフト情報送受信部206はサーバ10にギフトダウンロードリストを要求する(S506)。ギフト情報送受信部206は、ユーザ端末のユーザのユーザIDと、当該ユーザ端末が属する領域と、を含むリスト要求信号を生成し、ネットワークNWを介してサーバ10に送信する。ギフト情報提供部306は、受信されたリスト要求信号に含まれるユーザIDのユーザの属性が所定の基準を満たすか否かを判定する。ギフト情報提供部306は、基準が満たされる場合、ギフトDB316に登録される全てのギフトIDが含まれるように端末用ギフトダウンロードリストを生成する。具体的には、ギフト情報提供部306は、ユーザDB314を参照し、受信されたリスト要求信号に含まれるユーザIDに対応するレベルを特定する。ギフト情報提供部306は、特定されたレベルが閾値を上回る場合、ギフトDB316に登録される全てのギフトIDが含まれるように端末用ギフトダウンロードリストを生成する。ギフト情報提供部306は、基準が満たされない場合、ギフトダウンロードリスト310を参照し、受信されたリスト要求信号に含まれる領域に対応するギフトIDが含まれるように端末用ギフトダウンロードリストを生成する。ギフト情報提供部306は、生成された端末用ギフトダウンロードリストをユーザ端末にネットワークNWを介して送信する。ユーザ端末20のギフト情報送受信部206はその端末用ギフトダウンロードリストを受信する(S508)。
【0050】
ギフト判定部208は、受信した端末用ギフトダウンロードリストと各ギフトの最終更新日とに基づいて、期限切れのエフェクトデータを端末側ギフト保持部250から削除する(S509)。ギフト判定部208は、端末側ギフト保持部250を参照し、最終更新日と現在の日付との差が閾値(例えば、14日)を上回るギフトIDを特定する。ギフト判定部208は、特定されたギフトIDが、受信した端末用ギフトダウンロードリストに含まれるか否かを判定する。ギフト判定部208は、特定されたギフトIDが端末用ギフトダウンロードリストに含まれていない場合、当該ギフトIDに対応するエフェクトデータを端末側ギフト保持部250から削除する。ギフト判定部208は、特定されたギフトIDが端末用ギフトダウンロードリストに含まれている場合は削除を行わない。これは、ギフト判定部208が、所定の削除基準を満たし、かつ、端末用ギフトダウンロードリストに含まれないギフトのエフェクトデータを削除しているといえる。これにより、プレロードタイプのギフトのエフェクトデータを維持することでインタラクションの即時性を担保しつつ、端末側ギフト保持部250のサイズの増大を抑えることができる。
【0051】
ギフト判定部208は、受信した端末側ギフトダウンロードリストと端末側ギフト保持部250の内容とに基づいて、エフェクトデータをダウンロードするギフトを特定する(S510)。ギフト判定部208は、端末側ギフトダウンロードリストに含まれる各ギフトIDについて、端末側ギフト保持部250に対応するエフェクトデータが保持されていない場合、当該ギフトIDをダウンロード対象のギフトのギフトIDとして特定する。ギフト判定部208は、特定されたギフトIDをダウンロードキュー保持部252に任意の順番で登録する(S512)。ギフト情報送受信部206は、ダウンロードキュー保持部252に登録されている順番に従いエフェクトデータのダウンロードを開始する(S514)。
【0052】
上記のフローにおいて、ギフト情報送受信部206は、プレロードタイプのギフト、すなわち端末用ギフトダウンロードリストに含まれるギフトに対応するエフェクトデータのダウンロードを、当該ギフトのアイコンが指定される前に、ユーザによる指示を介さずに開始する。ギフト判定部208は、端末用ギフトダウンロードリストを参照することでプレロードタイプのギフトを特定する。
【0053】
ステップS506においてユーザの属性が所定の基準を満たす場合、端末用ギフトダウンロードリストは全てのギフトのギフトIDを含むから、ギフト情報送受信部206は、ギフトのタイプに依らずに、当該ギフトに対応するエフェクトデータのダウンロードを、ユーザによる指示を介さずに開始する。
【0054】
上記のフローにおいて、要ロードタイプのギフトのギフトIDは端末用ギフトダウンロードリストに含まれないので、要ロードタイプのギフトのエフェクトデータのダウンロードは、ユーザによって当該ギフトが指定される前には開始されない。ただし、後述するように当該ギフトを他のユーザが使用した場合を除く。
【0055】
図12は、ユーザ端末20、30における一連のダウンロード処理の流れを示すフローチャートである。ユーザ端末のギフト情報送受信部206は、ダウンロードキュー保持部252の一番上にあるギフトIDで特定されるギフトのエフェクトデータのダウンロードを開始する(S520)。ギフト情報送受信部206は、ダウンロードキュー保持部252に保持されているギフトIDのうち最上位すなわち1番のギフトIDを含むギフトDL要求信号を生成し、ネットワークNWを介してサーバ10に送信する。
【0056】
キュー制御部210は、ダウンロードキュー保持部252の一番上にあるギフトIDを削除し、残りのギフトIDの順番を一つ減らすようダウンロードキュー保持部252を更新する(S522)。例えば、ダウンロードキュー保持部252において、順番が2であったギフトIDの順番は1となり、順番が3であったギフトIDの順番は2となる。
【0057】
ギフト情報送受信部206は、ダウンロードが完了したか否かを判定する(S524)。完了した場合(S524のYES)、ギフト情報送受信部206はダウンロードされたエフェクトデータを端末側ギフト保持部250に登録し、処理をステップS520に戻す。完了していない場合(S524のNO)、キュー制御部210はキュー変更事由が発生したか否かを判定する(S526)。キュー変更事由は少なくとも以下の二つを含む。
(事由1)要ロードタイプのギフトやプレロードタイプであってまだダウンロードされていないギフトに対してユーザが使用の意思を示したこと。具体的には、そのようなギフトのアイコンがユーザによってタップされたこと。
(事由2)同じライブ配信の動画データが配信されている他のユーザ端末の他の視聴者により、要ロードタイプのギフトやプレロードタイプであってまだダウンロードされていないギフトが使用されたこと。
【0058】
キュー変更事由が発生していない場合(S526のNO)、処理はステップS524に戻る。キュー変更事由が発生した場合(S526のYES)、キュー制御部210は、キュー変更事由に従いダウンロードキュー保持部252を更新する(S528)。その後、処理はステップS524に戻る。
【0059】
ステップS528を詳述する。事由1については図13にて後述する。事由2について、図2の例を用いて説明する。配信者LVがライブ配信を配信し、視聴者AU1と視聴者AU2とがその同じライブ配信を視聴している。ここで、視聴者AU2がギフトを使用すると、当該ギフトのギフトIDを含むギフト使用信号がユーザ端末30bによって生成され、ネットワークNWを介してサーバ10に送信される。併せてユーザ端末30bは当該ギフトに対応するエフェクトデータを処理することでエフェクトを動画像VD2に重畳表示させる。サーバ10は、ストリームDB312を参照することで、視聴者AU2が視聴しているライブ配信と同じライブ配信を視聴している他の視聴者を特定する。サーバ10は、受信したギフト使用信号に含まれるギフトIDを含むギフト通知信号を生成し、ネットワークNWを介して特定された他の視聴者(ここでは視聴者AU1)のユーザ端末30aに送信する。ユーザ端末30aは、受信したギフト通知信号に含まれるギフトIDに対応するエフェクトデータが端末側ギフト保持部250に保持されているか判定する。ユーザ端末30aは、保持されていればそのエフェクトデータを処理することでユーザ端末30bのエフェクトと同じエフェクトを動画像VD1に重畳表示させる。保持されていない場合、ユーザ端末30bは事由2が発生したと判定する。
【0060】
キュー制御部210は、ギフトのダウンロードについて、以下の優先関係が成立するようダウンロードキュー保持部252を制御する。
優先順位1:事由1に係るギフトに対応するエフェクトデータのダウンロード。
優先順位2:事由2に係るギフトに対応するエフェクトデータのダウンロード。
優先順位3:ライブ配信アプリの起動時にダウンロードキュー保持部252に登録されたギフトに対応するエフェクトデータのダウンロード。
【0061】
キュー制御部210は、事由1が発生した場合、ダウンロードキュー保持部252に保持されている全てのギフトIDの順番を一つ増加させ、かつ、事由1に係るギフトのギフトIDを順番1のエントリに挿入する。すなわち、キュー制御部210は、事由1に係るギフトのギフトIDをダウンロードキューの一番上に割り込ませる。例えば、ダウンロードキュー保持部252において、順番が1であったギフトIDの順番は2となり、順番が2であったギフトIDの順番は3となり、事由1に係るギフトのギフトIDの順番は1として登録される。これにより、事由1に係るギフトのエフェクトデータのダウンロードが現在進行中のダウンロードの次に開始されることとなる。
【0062】
キュー制御部210は、事由2が発生した場合、ダウンロードキュー保持部252に保持されているギフトIDのうち、事由1に係るギフトのギフトID以外の全てのギフトIDの順番を一つ増加させ、かつ、事由2に係るギフトのギフトIDを事由1に係るギフトのギフトIDの直下のエントリに挿入する。すなわち、キュー制御部210は、ダウンロードキューにおいて、事由2に係るギフトのギフトIDを事由1に係るギフトのギフトIDとそれ以外のギフトIDとの間に割り込ませる。例えば、ダウンロードキュー保持部252において、順番が1であった事由1に係るギフトIDの順番は1のままであり、順番が2であったギフトIDの順番は3となり、事由2に係るギフトのギフトIDの順番は2として登録される。
【0063】
図13は、ユーザ端末20、30における一連のギフト使用処理の流れを示すフローチャートである。前提として、視聴者がユーザ端末30からライブ配信プラットフォームにアクセスし、ライブ配信選択画面から所望のライブ配信を選択して視聴を開始したとする。視聴者がライブ配信を視聴している間、配信者のユーザ端末20からサーバ10(の中継部304)を介して視聴者のユーザ端末30へと継続的に動画データが伝送される。
【0064】
この動画データの再生中に、視聴者はユーザ端末30の入力手段を介してアイテムの表示を要求するためのユーザ入力を行う。ユーザ端末30の視聴側UI制御部202はこのユーザ入力を受けると、端末側ギフト保持部250を参照し、各ギフトのダウンロードステータスを取得する(S280)。ダウンロードステータスは、エフェクトデータが端末側ギフト保持部250に保持されている場合は「DL済み」、エフェクトデータが端末側ギフト保持部250に保持されていない場合は「未DL」、エフェクトデータのダウンロードが現在進行中の場合は「DL中」、となる。
【0065】
視聴側UI制御部202および重畳情報生成部204は、ステップS280で取得されたダウンロードステータスに応じた態様で各ギフトアイコンを表示させる(S282)。重畳情報生成部204は、各ギフトについて、端末側ギフト保持部250からアイコンデータを取得して処理することでギフトアイコンを生成する。重畳情報生成部204は、生成されたギフトアイコンに、ステップS280で取得されたダウンロードステータスに応じた視覚的効果を付与する。例えば、重畳情報生成部204は、ダウンロードステータスが「DL中」の場合は、対応するギフトアイコンにダウンロードのステータスを示すインジケータを関連付ける。例えば重畳情報生成部204は、ギフトアイコンにダウンロードの進捗を示すプログレスバーを付与する。重畳情報生成部204は、ダウンロードステータスが「未DL」の場合、ダウンロードキュー保持部252を参照することで当該ギフトがダウンロードキューに入っているか否かを判定する。重畳情報生成部204は、ダウンロードキューに入っている場合は、対応するギフトアイコンにダウンロード待ちであることを示す視覚的効果(シェーディングなど)を付与する。重畳情報生成部204は、ダウンロードキューに入っていない場合は、対応するギフトアイコンにダウンロードが必要であることを示すマークを付与する。重畳情報生成部204は、ダウンロードステータスが「DL済み」の場合、視覚的効果の付与は行わない。重畳情報生成部204は、そのように生成された加工済みまたは加工無しのギフトアイコンを、サーバ10から取得された動画データの画像に重畳させる。視聴側UI制御部202は、ギフトアイコンが重畳された画像をディスプレイに表示させる。
【0066】
視聴側UI制御部202は、ステップS282でディスプレイに表示されたギフトアイコンへのタップを検出するまで待機する(S284)。待機中にダウンロードステータスが変更された場合(例えば、「DL中」が「DL済み」になる、キューに入っていた「未DL」が「DL中」となり「DL済み」になる)、対応するギフトアイコンの視覚的効果もダウンロードステータスの変更に応じて変更される。ギフトアイコンへのタップが検出されると(S284のYES)、ギフト判定部208はタップにより指定されたギフトアイコンに対応するギフトのダウンロードステータスが「未DL」、「DL済み」、「DL中」のいずれであるかを判定する(S286)。
【0067】
ダウンロードステータスが「未DL」である場合、キュー制御部210はタップにより指定されたギフトのギフトIDをダウンロードキュー保持部252の一番上に挿入する(S288)。これは、上記の事由1が発生した場合に相当する。その後、処理はステップS280に戻る。この結果、タップにより指定されたギフトのエフェクトデータのダウンロードが最優先で開始される。
【0068】
ダウンロードステータスが「DL中」である場合、視聴側UI制御部202はタップにより指定されたギフトのエフェクトデータがダウンロード中であることを示すテキストを含むポップアップをディスプレイに表示させる。テキストは例えば「ロード中です。ロードが完了いたしましたら、タップしてギフトを贈ってください」であってもよい。その後、処理はステップS280に戻る。
【0069】
ダウンロードステータスが「DL済み」である場合、ギフト情報送受信部206は、タップにより指定されたギフトのギフトIDを含むギフト使用信号を生成し、ネットワークNWを介してサーバ10に送信する(S292)。重畳情報生成部204および視聴側UI制御部202は、タップにより指定されたギフトのエフェクトデータを端末側ギフト保持部250から読み出して処理することでギフトのエフェクトを出力する(S294)。ギフト判定部208は、端末側ギフト保持部250にアクセスし、タップにより指定されたギフトの最終更新日を現在の日付となるよう更新する(S296)。その後、処理はステップS280に戻る。
【0070】
図14は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信選択画面602の代表画面図である。ライブ配信選択画面602は、現在視聴可能なライブ配信のリストにある各ライブ配信を示すサムネイル604を含む。視聴側UI制御部202は、サーバ10から取得したライブ配信のリストに基づいてライブ配信選択画面602を生成し、ディスプレイに表示させる。
【0071】
図15は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信ルーム画面610の代表画面図である。図14のライブ配信選択画面602において視聴者がサムネイルをタップし、かつギフトの表示を要求すると、図15のライブ配信ルーム画面610がディスプレイに表示される。ライブ配信ルーム画面610は、動画データを再生することにより得られる配信者の画像612と、ギフトアイコン614、616、618と、を有する。
【0072】
ギフトアイコン614は、ダウンロードステータスが「未DL」でありかつダウンロードキュー保持部252に登録されていないギフトのギフトアイコンである。ギフトアイコン614は、ダウンロードが必要であることを示すマーク620を有する。このギフトアイコン614で表されるギフトは要ロードタイプのギフトである。
【0073】
ギフトアイコン616は、ダウンロードステータスが「未DL」でありかつダウンロードキュー保持部252に登録されているギフトのギフトアイコンである。ギフトアイコン616には、ダウンロードの待機中であることを示すシェーディングが施されている。このギフトアイコン616で表されるギフトは基本的に、プレロードタイプのギフトであってまだダウンロードの順番が回ってきていないギフトである。
【0074】
ギフトアイコン618は、ダウンロードステータスが「DL済み」であるギフトのギフトアイコンである。このギフトアイコン618で表されるギフトは、(1)プレロードタイプのギフトであってエフェクトデータのダウンロードが完了したギフト、(2)要ロードタイプのギフトであったものがユーザによる指定もしくは他のユーザによる使用によりエフェクトデータのダウンロードが完了したギフト、のいずれかである。(2)のギフトは既にエフェクトデータのダウンロードが完了しているので、もはや要ロードタイプのギフトとは言えない。ただし、当該エフェクトデータが期限切れで端末側ギフト保持部250から削除されると、当該ギフトは要ロードタイプのギフトに戻る。
【0075】
図15のライブ配信ルーム画面610において視聴者がギフトアイコン618をタップすると、ユーザ端末30は当該視聴者による当該ギフトアイコン618の指定を受け付ける。ユーザ端末30は、指定されたギフトアイコン618が表すギフトに対応するエフェクトデータを端末側ギフト保持部250から読み出して処理することで、ギフトアイコン618に対応するエフェクトを実現する。
【0076】
図16は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信ルーム画面622の代表画面図である。図15のライブ配信ルーム画面610において視聴者がギフトアイコン614をタップすると、ユーザ端末30は当該視聴者による当該ギフトアイコン614の指定を受け付ける。ユーザ端末30は、指定されたギフトアイコン614が表すギフト(以下、ユーザ指定ギフトという)に対応するエフェクトデータのダウンロードを開始する。図16のライブルーム配信画面622において、図15のギフトアイコン614は、マーク620の代わりにダウンロードの進捗を示すプログレスバー624を含むギフトアイコン626に変化している。
【0077】
図17は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信ルーム画面628の代表画面図である。図15の状態から時間が経過し、ユーザ指定ギフトのエフェクトデータのダウンロードが完了したので、図16のライブルーム配信画面628では、ユーザ指定ギフトのギフトアイコン630はダウンロードステータスが「DL済み」のギフトアイコンの表示態様で表示されている。図15のライブ配信ルーム画面610においてギフトアイコン616で表されていたギフトのエフェクトデータのダウンロードが進行中となったので、当該ギフトのギフトアイコン632はプログレスバーを含む。
【0078】
図18は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信ルーム画面634の代表画面図である。図17のライブ配信ルーム画面628において視聴者がギフトアイコン630をタップすると、ユーザ端末30はユーザ指定ギフトのエフェクトが重畳された配信者の画像636を含むライブルーム配信画面634をディスプレイに表示させる。
【0079】
図19は、視聴者のユーザ端末30のディスプレイに表示されるライブ配信ルーム画面638の代表画面図である。ライブルーム配信画面638では軽量モードがONになっている。軽量モードではプレロードタイプのギフトは存在しないので、ライブルーム配信画面638に表示されるギフトアイコン640、642、644はいずれもダウンロードステータスが「未DL」でありかつダウンロードキュー保持部252に登録されていないギフトのギフトアイコンである。これらのギフトアイコンはそれぞれ、ダウンロードが必要であることを示すマークを有する。これらのギフトアイコンで表されるギフトは要ロードタイプのギフトである。
【0080】
上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。
【0081】
本実施の形態に係るライブ配信システム1では、全てのギフトのエフェクトデータを予めダウンロードしておくのではなく、指定されたプレロードタイプのギフトのエフェクトデータを予めダウンロードすると共に残りの要ロードタイプのギフトについてはユーザによる指定をトリガとしてダウンロードを開始するよう構成される。これにより、大きなサイズのエフェクトデータを用いてより豊かなエフェクトを実現しつつ、ダウンロードによる通信量の増大を抑えると共にライブ配信アプリのインストールに必要な容量の増大を抑えることができる。
【0082】
また、本実施の形態に係るライブ配信システム1では、プレロードタイプのギフトについては視聴者がタップすると、配信者の画面にも当該視聴者の画面にも他の視聴者の画面にも即座にエフェクトが出力される。したがって、配信者と視聴者とのインタラクションの即時性を維持することができる。
【0083】
一例では、エフェクトデータの総量は数十GBにもなる。本実施の形態に係る技術的思想を適用することで、ユーザ端末が保持するエフェクトデータの量を数GB~数百MBまで低減することができる。また、代表的なエフェクトデータ一つを代表的な通信環境でダウンロードするのにかかる時間は数十ミリ秒~数秒であるが、この程度の遅延によるユーザ体験への悪影響は限定的である。したがって、多くの場合において、要ロードタイプを設けることによるメリットはデメリットを上回る。
【0084】
また、本実施の形態に係るライブ配信システム1では、DL済みのギフトと未DLのギフトとを異なる態様で表示する。したがって、ユーザはどのギフトのダウンロードの状態を一目で理解することができるので、ユーザ利便性が向上する。特に、ライブ配信の特性としてその場ですぐにギフトを贈りたいという状況が頻繁に生じるのであるが、そのような状況でユーザは未DLのギフトを避けてDL済みのギフトを容易に選択できる。これによりユーザの満足度が向上する。
【0085】
また、本実施の形態に係るライブ配信システム1では、ユーザにより指定されたギフトのエフェクトデータのダウンロードが、プレロードタイプのギフトの自動ダウンロードよりも優先される。これにより、ギフト使用のためにユーザが待たなければならない時間を低減することができるので、ユーザの満足度を高めることができる。
【0086】
また、本実施の形態に係るライブ配信システム1では、他のユーザが使用したギフトのエフェクトデータのダウンロードが、プレロードタイプのギフトの自動ダウンロードよりも優先される。これにより、エフェクト出力の遅延を抑えることができるので、例えば配信者の感謝の言葉とエフェクト出力タイミングとがずれることによる違和感を軽減できる。
【0087】
また、本実施の形態に係るライブ配信システム1では、属性が所定の基準を満たしたユーザについては全てのギフトをプレロードする。これにより、例えばライブ配信プラットフォームの利用年数が長い、および/または、課金総額が高いユーザについては全てのギフトをプレロードすることで、そのようなユーザのユーザ体験を最大化することができる。あるいはまた、いわゆるヘビーユーザの有するユーザ端末は高機能・大容量である確率が高いので、そのようなユーザには全てのギフトをプレロードすることでユーザ体験を最大化することができる。
【0088】
[ハードウェア構成例]
図20を参照して、本実施の形態に係る情報処理装置のハードウェア構成について説明する。図20は、本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。図示された情報処理装置900は、例えば、本実施の形態におけるサーバ10およびユーザ端末20、30のそれぞれを実現しうる。
【0089】
情報処理装置900は、CPU901、ROM(Read Only Memory)903、およびRAM(Random Access Memory)905を含む。また、情報処理装置900は、ホストバス907、ブリッジ909、外部バス911、インタフェース913、入力装置915、出力装置917、ストレージ装置919、ドライブ921、接続ポート925、通信装置929を含んでもよい。さらに、情報処理装置900は、カメラなどの撮像装置(不図示)を含む。また、情報処理装置900は、CPU901に代えて、またはこれとともに、DSP(Digital Signal Processor)またはASIC(Application Specific Integrated Circuit)と呼ばれるような処理回路を有してもよい。
【0090】
CPU901は、演算処理装置および制御装置として機能し、ROM903、RAM905、ストレージ装置919、またはリムーバブル記録媒体923に記録された各種プログラムに従って、情報処理装置900内の動作全般またはその一部を制御する。例えば、CPU901は、本実施の形態におけるサーバ10およびユーザ端末20、30のそれぞれに含まれる各機能部の動作全般を制御する。ROM903は、CPU901が使用するプログラムや演算パラメータなどを記憶する。RAM905は、CPU901の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。CPU901、ROM903、およびRAM905は、CPUバスなどの内部バスにより構成されるホストバス907により相互に接続されている。さらに、ホストバス907は、ブリッジ909を介して、PCI(Peripheral Component Interconnect/Interface)バスなどの外部バス911に接続されている。
【0091】
入力装置915は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置であってもよいし、マイクロフォンなどの音センサ、加速度センサ、傾きセンサ、赤外線センサ、深度センサ、温度センサ、湿度センサなど物理量を電気信号に変換する装置であってもよい。入力装置915は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置900の操作に対応した携帯電話などの外部接続機器927であってもよい。入力装置915は、ユーザが入力した情報または感知した物理量に基づいて入力信号を生成してCPU901に出力する入力制御回路を含む。ユーザは、この入力装置915を操作することによって、情報処理装置900に対して各種のデータを入力したり処理動作を指示したりする。
【0092】
出力装置917は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置917は、例えば、LCD、PDP、OELDなどのディスプレイ、スピーカおよびヘッドホンなどの音響出力装置、ならびにプリンタ装置などでありうる。出力装置917は、情報処理装置900の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音響などの音として出力したりする。
【0093】
ストレージ装置919は、情報処理装置900の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置919は、例えば、HDD(Hard Disk Drive)などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置919は、CPU901が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。
【0094】
ドライブ921は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体923のためのリーダライタであり、情報処理装置900に内蔵、あるいは外付けされる。ドライブ921は、装着されているリムーバブル記録媒体923に記録されている情報を読み出して、RAM905に出力する。また、ドライブ921は、装着されているリムーバブル記録媒体923に記録を書き込む。
【0095】
接続ポート925は、機器を情報処理装置900に直接接続するためのポートである。接続ポート925は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)ポートなどでありうる。また、接続ポート925は、RS-232Cポート、光オーディオ端子、HDMI(登録商標)(High-Definition Multimedia Interface)ポートなどであってもよい。接続ポート925に外部接続機器927を接続することで、情報処理装置900と外部接続機器927との間で各種のデータが交換されうる。
【0096】
通信装置929は、例えば、ネットワークNWに接続するための通信デバイスなどで構成された通信インタフェースである。通信装置929は、例えば、有線または無線LAN(Local Area Network)、Bluetooth(登録商標)、またはWUSB(Wireless USB)用の通信カードなどでありうる。また、通信装置929は、光通信用のルータ、ADSL(Asymmetric Digital Subscriber Line)用のルータ、または、各種通信用のモデムなどであってもよい。通信装置929は、例えば、インターネットや他の通信機器との間で、TCP/IPなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置929に接続される通信ネットワークNWは、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内LAN、赤外線通信、ラジオ波通信または衛星通信などである。なお、通信装置929は、通信部としての機能を実現する。
【0097】
カメラなどの撮像装置(不図示)は、例えばCCD(Charge Coupled Device)またはCMOS(Complementary Metal Oxide Semiconductor)などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。当該撮像装置は、静止画を撮像するものであってもよいし、または動画を撮像するものであってもよい。
【0098】
以上、実施の形態に係るライブ配信システム1の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解される。
【0099】
実施の形態に係る技術的思想を、配信者の画像の代わりに配信者の動きと同期した動きをするアバターを用いるバーチャルライブ配信や、ライブコマースに適用してもよい。
【0100】
実施の形態では、要ロードタイプのギフトを使用する際、まず当該ギフトのギフトアイコンをタップすることでエフェクトデータのダウンロードを開始し、ダウンロードが完了した後に改めてギフトアイコンをタップすることでギフトを使用する場合を説明したが、これに限られない。例えば、ユーザ端末は、要ロードタイプのギフトアイコンに対するタップを検出すると、そのギフトアイコンが表すギフトのエフェクトデータのダウンロードを開始し、ダウンロードが完了すると、ユーザからさらなる指示を受けることなく自動で当該ギフトを使用するための処理を行ってもよい。この場合、ギフトを使用するためのタップの回数が減るので、ユーザの手間を削減できる。
【0101】
実施の形態では、要ロードタイプのギフトのギフトアイコンに対するタップを検出した場合に当該ギフトのエフェクトデータのダウンロードを開始する場合を説明したが、これに限られない。例えば、ユーザ端末は、ユーザから入力手段を介して、要ロードタイプのギフトのギフトアイコンを表示するための要求を受け付けると、当該ギフトのエフェクトデータのダウンロードを開始してもよい。
【0102】
実施の形態において、ユーザがユーザ端末の属する領域を変更した場合、ユーザ端末は変更後の領域のギフトダウンロードリストに含まれないギフトのエフェクトデータを、端末側ギフト保持部250から削除してもよい。
【0103】
実施の形態では、ユーザ端末がギフトダウンロードリストと端末側ギフト保持部250の内容とを比較する場合を説明したが、これに限られない。例えば、ライブ配信アプリの起動時、ユーザ端末は端末側ギフト保持部250を参照してエフェクトデータが存在するギフトのギフトIDのリストを生成し、サーバ10に送信する。サーバ10は受信したリストとギフトダウンロードリストとを比較して、ユーザ端末にダウンロードすべきエフェクトデータを特定する。サーバ10は特定されたエフェクトデータのギフトIDをユーザ端末に送信する。ユーザ端末は、受信したギフトIDをダウンロードキュー保持部252に登録し、ダウンロードを開始する。
【0104】
実施の形態では、事由1や事由2が発生した場合、現在進行中のダウンロードが完了してからそれらの事由に係るギフトのエフェクトデータのダウンロードを開始する場合を説明したが、これに限られない。例えば、事由1や事由2が発生した場合、ユーザ端末は現在進行中のダウンロードを一時停止またはキャンセルし、それらの事由に係るギフトのエフェクトデータのダウンロードを開始してもよい。
【0105】
本明細書において説明された処理手順、特にフロー図、フローチャートを用いて説明された処理手順においては、その処理手順を構成する工程(ステップ)の一部を省略すること、その処理手順を構成する工程として明示されていない工程を追加すること、及び/又は当該工程の順序を入れ替えることが可能であり、このような省略、追加、順序の変更がなされた処理手順も本開示の趣旨を逸脱しない限り本開示の範囲に含まれる。
【0106】
サーバ10により実現される機能の少なくとも一部は、サーバ10以外の装置、例えばユーザ端末20、30により実現されてもよい。ユーザ端末20、30により実現される機能の少なくとも一部は、ユーザ端末20、30以外の装置、例えば、サーバ10により実現されてもよい。例えば、再生側のユーザ端末で行われる動画データの画像への所定のフレーム画像の重畳は、サーバ10で行われてもよいし、生成側のユーザ端末で行われてもよい。
【要約】

【課題】ライブ配信においてより高機能なギフトを使用可能としつつ、それによるデータ量の増大を抑える。
【解決手段】コンピュータプログラムは、端末に、ライブ配信に係る動画データの再生中に、第1タイプのギフトを表す第1ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、端末のユーザによる第1ユーザインタフェースオブジェクトの指定を受け付けた場合、端末の保持部に保持されている、第1ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する機能と、動画データの再生中に、第2タイプのギフトを表す第2ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、ユーザによる第2ユーザインタフェースオブジェクトの指定を受け付けた場合、第2ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能と、を実現させる。
【選択図】図1
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20