JP2023090606A - コンピュータプログラム、端末及び方法 - Google Patents

Abstract

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

Description

本開示は、コンピュータプログラム、端末及び方法に関する。

ＩＴ技術の発展と共に情報のやりとりの様も移り変わってきた。昭和の時代には新聞やテレビなどの一方通行の情報伝達が主であった。平成になると、ケータイやパソコンが普及し、インターネットの通信速度も大きく改善されたので、チャットサービスなどの即時双方向通信サービスが台頭し、また記憶コストの低減に伴ってオンデマンド型の動画配信サービスが受け入れられていった。そして、現在、令和の時代となり、スマートフォンの高機能化や５Ｇに代表されるネットワークの速度のさらなる向上を受けて、動画によるリアルタイムのコミュニケーションを実現するサービス、特にライブ配信サービスが急速に認知度を高めている。ライブ配信サービスは、離れた場所にいても皆が同じ楽しい時間を共有できるサービスとして、若者を中心に利用者が拡大している。

投げ銭などのギフトのエフェクトはライブ配信を盛り上げる重要な要素である。数多くの種類のギフトを設け、それぞれのギフトのエフェクトに趣向を凝らすことができれば、ライブ配信のよりいっそうの盛り上がりを期待できる。

特許文献１には、ライブ配信中に投銭エフェクト画像を表示することで配信を盛り上げる技術が開示されている。

特開２０２０－０１７８７０号公報

ライブ配信では配信者と視聴者とのインタラクションの即時性が要求される。したがって、通常、ギフトのエフェクトを実現するデータは、ユーザからの指示に応じてすぐに使用できるよう予め全てユーザの端末にダウンロードされる。

しかしながら、ギフトのエフェクトを実現するデータのサイズは、エフェクトが高機能になるほど大きくなる。しかもそのようなギフトの種類を多くするとと、ギフトのデータを保持するために必要なデータ容量が大きくなる。その結果、ライブ配信のアプリケーションをインストールした端末の容量の大きな部分を当該アプリケーションのデータが占めるようになるので、動作が重くなる、他のアプリケーションのインストールが制限されるなどユーザ利便性を損なう虞がある。

本開示はこうした課題に鑑みてなされたものであり、その目的は、ライブ配信においてより高機能なギフトを使用可能としつつ、それによるデータ量の増大を抑えることができる技術の提供にある。

本開示のある態様は、コンピュータプログラムに関する。このコンピュータプログラムは、端末に、ライブ配信に係る動画データの再生中に、第１タイプのギフトを表す第１ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、端末のユーザによる第１ユーザインタフェースオブジェクトの指定を受け付けた場合、端末の保持部に保持されている、第１ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する機能と、動画データの再生中に、第２タイプのギフトを表す第２ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、ユーザによる第２ユーザインタフェースオブジェクトの指定を受け付けた場合、第２ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能と、を実現させる。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本開示の態様によれば、ライブ配信においてより高機能なギフトを使用可能としつつ、それによるデータ量の増大を抑えることができる。

本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のライブ配信システムで実現されるライブ配信の一例を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図３の端末側ギフト保持部の一例を示すデータ構造図である。 図３のダウンロードキュー保持部の一例を示すデータ構造図である。 図１のサーバの機能および構成を示すブロック図である。 図６のギフトダウンロードリストの一例を示すデータ構造図である。 図６のストリームＤＢの一例を示すデータ構造図である。 図６のユーザＤＢの一例を示すデータ構造図である。 図６のギフトＤＢの一例を示すデータ構造図である。 ユーザ端末における一連のアプリ起動処理の流れを示すフローチャートである。 ユーザ端末における一連のダウンロード処理の流れを示すフローチャートである。 ユーザ端末における一連のギフト使用処理の流れを示すフローチャートである。 視聴者のユーザ端末のディスプレイに表示されるライブ配信選択画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

以下、各図面に示される同一または同等の構成要素、部材、処理、信号には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

実施の形態に係るライブ配信システムでは、全てのギフトについてエフェクトを実現するデータ（以下、エフェクトデータという）をユーザ端末にダウンロードさせるのではなく、ギフトを、エフェクトデータを予めダウンロードしておくプレロードタイプとそうでない要ロードタイプとに分ける。視聴者が要ロードタイプのギフトの使用を希望する場合、視聴者が当該ギフトのアイコン（以下、ギフトアイコンという）をタップすることでまずは当該ギフトのエフェクトデータのダウンロードが開始される。ダウンロードが完了すると、視聴者は当該ギフトを使用することができる。使用頻度の低いギフトを要ロードタイプのギフトとすることができる。

これにより、各ギフトのエフェクトデータのサイズが大きくなったとしても、ギフトのプレロードにかかる時間の増大を抑えることができ、またプレロードされたエフェクトデータのトータルサイズの増大も抑えることができる。その結果、サイズの大きなエフェクトデータを用いてより豊かなアニメーションや音声などの表現を可能としつつ、ユーザ端末に要求される通信性能や容量の増大を抑えることができる。加えて、プレロードタイプのギフトは使用時にダウンロードを要しないギフトなので、このプレロードタイプのギフトについては配信者と視聴者とのインタラクションの即時性を担保することができる。

このように、本実施の形態は、ギフトのダウンロードプロセスを最適化することでギフトのダウンロードサイズを低減し、もって良好なユーザ体験および端末への低負荷を両立させることができる。

［ライブ配信システムの構成］
図１は、本開示の実施の形態に係るライブ配信システム１の構成を示す模式図である。ライブ配信システム１は、配信者（ライバー、ストリーマ（Streamer）ともいう）ＬＶと視聴者（オーディエンスともいう）ＡＵ（ＡＵ１、ＡＵ２、…）とがリアルタイムでやりとりできる双方向型のライブ配信サービスを提供する。図１に示すように、ライブ配信システム１は、サーバ１０と、配信者側のユーザ端末２０と、視聴者側のユーザ端末３０（３０ａ、３０ｂ、…）と、を備える。配信者および視聴者をユーザと総称することがある。サーバ１０は、ネットワークＮＷに接続された一または複数の情報処理装置によって構成されてもよい。ユーザ端末２０、３０は例えばスマートフォンやタブレット型端末やラップトップＰＣやレコーダや携帯型ゲーム機やウェアラブル装置などの携帯端末であってもよいし、デスクトップＰＣなどの据え置き型の装置であってもよい。サーバ１０、ユーザ端末２０およびユーザ端末３０は、有線または無線の各種ネットワークＮＷにより互いに通信可能に接続される。

ライブ配信システム１には、配信者ＬＶと、視聴者ＡＵと、サーバ１０を管理する管理者（不図示）と、が関与する。配信者ＬＶは、自分の歌や、トーク、パフォーマンス、占い、ゲーム実況などのコンテンツを自身のユーザ端末２０で録音・録画してそのままサーバ１０にアップロードすることで、リアルタイムにコンテンツを発信する者である。管理者は、サーバ１０においてコンテンツのライブ配信のためのプラットフォームを提供し、また、配信者ＬＶと視聴者ＡＵとのリアルタイムのやりとりを仲介または管理する。視聴者ＡＵは、ユーザ端末３０でプラットフォームにアクセスして所望のコンテンツを選択し、視聴する。このコンテンツのライブ配信中に視聴者ＡＵがユーザ端末３０を介してコメントをしたり応援するための操作を行い、当該コンテンツを提供する配信者ＬＶがそのようなコメントや応援に反応し、当該反応が映像および／または音声で視聴者ＡＵに伝わることで、双方向のコミュニケーションが成立する。

本明細書において「ライブ配信」は、配信者ＬＶのユーザ端末２０で録音・録画されたコンテンツが実質的にリアルタイムで視聴者ＡＵのユーザ端末３０で再生され視聴可能となる状態を実現するデータの伝送態様を意味するものであってもよく、またはそのような伝送態様により実現される配信そのものを意味してもよい。ライブ配信は、HTTP Live StreamingやCommon Media Application FormatやWeb Real-Time CommunicationsやReal-Time Messaging ProtocolやMPEG DASHなどの既存のライブストリーミング技術を用いて実現されてもよい。ライブ配信は、配信者ＬＶがコンテンツを録音・録画しているときに、視聴者ＡＵが所定の遅延をもって当該コンテンツを視聴可能な伝送態様を含む。遅延の大きさについて、少なくとも、配信者ＬＶと視聴者ＡＵとのやりとりが成立する程度の大きさの遅延は許される。ただし、ライブ配信は、コンテンツを録音・録画したデータ全体をいったんサーバに保存し、その後の任意のタイミングでユーザからの求めに応じて当該データをユーザに提供するいわゆるオンデマンド型の配信とは区別される。

本明細書において「動画データ」は、ユーザ端末２０、３０の撮像機能により生成される画像データ（ビデオデータともいう）と、ユーザ端末２０、３０の音声入力機能により生成される音声データ（オーディオデータともいう）と、を含むデータである。動画データは、ユーザ端末２０、３０で再生されることで、ユーザによるコンテンツの視聴を可能とする。

図２は、図１のライブ配信システム１で実現されるライブ配信の一例を示す模式図である。図２の例では、配信者ＬＶがトークをライブ配信している。配信者ＬＶのユーザ端末２０はトークを行っている配信者ＬＶの像および音声を録画・録音することで動画データを生成し、ネットワークＮＷを介してサーバ１０（図２では不図示）に送信する。併せてユーザ端末２０は、録画された配信者ＬＶの動画像ＶＤをユーザ端末２０のディスプレイに表示させることで、配信者ＬＶによる配信内容の確認を可能とする。

配信者ＬＶのライブ配信の視聴をプラットフォームに要求した視聴者ＡＵ１、ＡＵ２、ＡＵ３のユーザ端末３０ａ、３０ｂ、３０ｃはそれぞれ、ネットワークＮＷを介してライブ配信に係る動画データを受信し、受信した動画データを再生することでディスプレイに動画像ＶＤ１、ＶＤ２、ＶＤ３を表示させると共にスピーカーから音声を出力する。各ユーザ端末３０ａ、３０ｂ、３０ｃで表示される動画像ＶＤ１、ＶＤ２、ＶＤ３は配信者ＬＶのユーザ端末２０が撮像した動画像ＶＤと実質的に同一であり、各ユーザ端末３０ａ、３０ｂ、３０ｃで出力される音声も配信者ＬＶのユーザ端末２０が録音した音声と実質的に同一である。

配信者ＬＶのユーザ端末２０における録音・録画と、視聴者ＡＵ１、ＡＵ２、ＡＵ３のユーザ端末３０ａ、３０ｂ、３０ｃにおける動画データの再生と、は実質的に同時に行われる。配信者ＬＶのトークの内容についてひとりの視聴者ＡＵ１がコメントをユーザ端末３０ａに入力すると、サーバ１０は当該コメントをリアルタイムで配信者ＬＶのユーザ端末２０に表示させると共に各視聴者ＡＵ１、ＡＵ２、ＡＵ３のユーザ端末３０ａ、３０ｂ、３０ｃにも表示させる。当該コメントを読んだ配信者ＬＶがその内容に被せたトークを展開すると、そのトークの動画像と音声が各視聴者ＡＵ１、ＡＵ２、ＡＵ３のユーザ端末３０ａ、３０ｂ、３０ｃで出力され、これにより配信者ＬＶと視聴者ＡＵ１との会話が成立したと認識される。このように、ライブ配信システム１では、一方通行でない双方向のコミュニケーションを可能とするライブ配信が実現される。

図３は、図１のユーザ端末２０の機能および構成を示すブロック図である。ユーザ端末３０はユーザ端末２０と同様の機能および構成を有する。図３および以後のブロック図に示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

配信者ＬＶおよび視聴者ＡＵは、ダウンロードサイトからネットワークＮＷを介して、本実施の形態に係るライブ配信アプリケーションプログラム（以下、ライブ配信アプリという）をユーザ端末２０、３０にダウンロードし、インストールする。あるいはまた、ライブ配信アプリはユーザ端末２０、３０にプリインストールされていてもよい。ライブ配信アプリがユーザ端末２０、３０により実行されることにより、ユーザ端末２０、３０はネットワークＮＷを介してサーバ１０と通信し、各種機能を実現する。以下、ユーザ端末２０、３０（のＣＰＵなどのプロセッサ）がライブ配信アプリを実行することにより実現する機能をユーザ端末２０、３０の機能として説明する。それらの機能は実際はライブ配信アプリがユーザ端末２０、３０に実現させる機能である。なお、他の実施の形態では、これらの機能は、サーバ１０からユーザ端末２０、３０のウェブブラウザにネットワークＮＷを介して送信され、そのウェブブラウザによって実行される、ＨＴＭＬ（HyperText Markup Language）などのプログラミング言語により記述されたコンピュータプログラムにより実現されてもよい。

ユーザ端末２０は、ユーザの像および音声を記録した動画データを生成してサーバ１０に提供する配信部１００と、サーバ１０から動画データを取得して再生する視聴部２００と、ユーザ端末２０においてギフトの情報を保持する端末側ギフト保持部２５０と、ギフトのダウンロードのキューを保持するダウンロードキュー保持部２５２と、を備える。ユーザは、配信を行う場合は配信部１００を、視聴を行う場合は視聴部２００を、それぞれ起動する。配信部１００がアクティブとなっているユーザ端末は配信者側、つまり動画データの生成側のユーザ端末であり、視聴部２００がアクティブとなっているユーザ端末は視聴者側、つまり動画データの再生側のユーザ端末である。

配信部１００は、撮像制御部１０２と、音声制御部１０４と、動画送信部１０６と、配信側ＵＩ制御部１０８と、を含む。撮像制御部１０２は図３では不図示のカメラと接続され、カメラによる撮像を制御する。撮像制御部１０２はカメラから画像データを取得する。音声制御部１０４は図３では不図示のマイクロフォンと接続され、マイクロフォンによる音声入力を制御する。音声制御部１０４は、マイクロフォンから音声データを取得する。動画送信部１０６は、撮像制御部１０２により取得された画像データおよび音声制御部１０４により取得された音声データを含む動画データを、ネットワークＮＷを介してサーバ１０に送信する。動画送信部１０６による動画データの送信はリアルタイムで行われる。すなわち、撮像制御部１０２および音声制御部１０４による動画データの生成と、生成された動画データの動画送信部１０６による送信と、は実質的に同時に行われる。

配信側ＵＩ制御部１０８は、配信者向けのＵＩを制御する。配信側ＵＩ制御部１０８は、図３では不図示のディスプレイと接続され、動画送信部１０６による送信対象となっている動画データを再生することにより動画像をディスプレイに表示させる。配信側ＵＩ制御部１０８は、ディスプレイに操作用オブジェクトや指示受け付け用のオブジェクトを表示させ、配信者によるタップ入力を受け付ける。

視聴部２００は、視聴側ＵＩ制御部２０２と、重畳情報生成部２０４と、ギフト情報送受信部２０６と、ギフト判定部２０８と、キュー制御部２１０と、を含む。視聴側ＵＩ制御部２０２は、視聴者向けのＵＩを制御する。視聴側ＵＩ制御部２０２は、図３では不図示のディスプレイおよびスピーカと接続され、受信した動画データを再生することにより動画像をディスプレイに表示させると共に音声をスピーカから出力させる。ディスプレイに画像が出力されると共にスピーカから音声が出力されることを、合わせて「動画データが再生」されていると言うことができる。視聴側ＵＩ制御部２０２は、図３では不図示のタッチパネルやキーボードやディスプレイなどの入力手段と接続され、それら入力手段を介してユーザ入力を取得する。重畳情報生成部２０４は、サーバ１０から取得された動画データの画像に所定のフレーム画像を重畳させる。フレーム画像は、ユーザから入力を受け付けるための様々なユーザインタフェースオブジェクト（以下、単にオブジェクトという）と、視聴者により入力されたコメントと、サーバ１０から取得した情報と、を含む。

視聴側ＵＩ制御部２０２および重畳情報生成部２０４は共同で、ライブ配信に係る動画データの再生中に、プレロードタイプのギフトを表すギフトアイコンと、要ロードタイプのギフトを表すギフトアイコンと、をディスプレイに表示させる。

ギフト情報送受信部２０６は、サーバ１０との間でギフトに関連する情報を送受信する。ギフト判定部２０８は、ギフトのタイプを判定する。キュー制御部２１０は、ダウンロードキュー保持部２５２を制御する。

図４は、図３の端末側ギフト保持部２５０の一例を示すデータ構造図である。端末側ギフト保持部２５０は、ユーザ端末２０がダウンロードしたギフトの情報を保持する。ギフトは、以下の特徴を有する電子データである。
・ポイント（後述）を対価として購入可能、または無料で付与可能。
・視聴者が配信者に贈ることができるもの。配信者にギフトを贈ることを、ギフトを使用する、またはギフトを投げるという。
・ギフトの購入と使用とがセットで同時に発生するタイプのものもあれば、購入または付与された後、視聴者が任意のタイミングで使用可能なタイプのものもある。
・視聴者が配信者にギフトを贈ると、その配信者に相応のポイントが付与され、かつ、ギフトに関連付けられた効果が生じる。例えば、ギフトに対応するエフェクトがライブ配信画面に表れる。

端末側ギフト保持部２５０は、ギフトを特定するギフトＩＤと、当該ギフトを表すオブジェクトであるアイコンのデータ（以下、アイコンデータという）と、当該ギフトに対応するエフェクトを実現するためのデータ（以下、エフェクトデータという）と、当該ギフトが最後に使用された日付である最終更新日と、を対応付けて保持する。視聴者は、ライブ配信視聴中に、所望のギフトに対応する対価を支払うことで配信者に当該ギフトを贈ることができる。この対価の支払いは適宜の電子的決済手段により行われてもよく、例えば対価に相当するポイントを視聴者が管理者に支払うことで行われてもよい。あるいはまた、銀行振込やクレジットカードによる支払いが用いられてもよい。

エフェクトは、ギフトを特徴付ける視覚的効果または聴覚的効果または触覚的効果（例えば、振動）またはそれらの組み合わせである。視覚的効果には、アニメーションと、画像と、点灯・点滅と、がある。聴覚的効果には、効果音と、音声と、がある。エフェクトデータはこのようなエフェクトをユーザ端末２０において実現するためのデータであり、ユーザ端末２０はエフェクトデータを処理することでこのようなエフェクトを実現する。エフェクトデータそのものを実現する技術は公知であるから本明細書では詳述しない。

端末側ギフト保持部２５０には予め全てのギフトのギフトＩＤとアイコンデータとが格納される。ギフト情報送受信部２０６は、サーバ１０からギフトのエフェクトデータをダウンロードし、端末側ギフト保持部２５０に格納する。ギフト情報送受信部２０６がエフェクトデータをサーバ１０からダウンロードしていないギフトも存在する。

図５は、図３のダウンロードキュー保持部２５２の一例を示すデータ構造図である。ダウンロードキュー保持部２５２はギフトのダウンロードのキューを保持する。ダウンロードキュー保持部２５２は、ダウンロードの順番と、ギフトＩＤと、を対応付けて保持する。ギフト情報送受信部２０６はダウンロードキュー保持部２５２を参照し、その順番に従って順次ギフトのエフェクトデータをサーバ１０に要求し、サーバ１０からダウンロードする。

図６は、図１のサーバ１０の機能および構成を示すブロック図である。サーバ１０は、配信情報提供部３０２と、中継部３０４と、ギフト情報提供部３０６と、ギフト処理部３０８と、ギフトダウンロードリスト３１０と、ストリームＤＢ３１２と、ユーザＤＢ３１４と、ギフトＤＢ３１６と、を備える。

図７は、図６のギフトダウンロードリスト３１０の一例を示すデータ構造図である。ギフトダウンロードリスト３１０は、ユーザ端末２０、３０がデフォルトでそのエフェクトデータをダウンロードしなければならないギフトを指定するリストである。ギフトダウンロードリスト３１０に含まれるギフトＩＤのギフトのエフェクトデータは、ユーザ端末２０、３０でライブ配信アプリが起動されると自動で、すなわちユーザによる指示を介さずに、当該ユーザ端末２０、３０にダウンロードされ、端末側ギフト保持部２５０に格納される。ギフトダウンロードリスト３１０には領域が設定されており、各ユーザ端末が属する領域ごとにダウンロードすべきギフトがリストされている。

ギフトダウンロードリスト３１０は、領域と、ダウンロードすべきギフトのギフトＩＤと、を対応付けて保持する。ギフトダウンロードリスト３１０は更新可能に構成される。ライブ配信システムの管理者は、サーバ１０を介してギフトダウンロードリスト３１０の内容を変更することができる。管理者は、使用頻度が高まることが予想されるギフト（イベント関連のギフトなど）を予めギフトダウンロードリスト３１０に登録することができる。また、管理者は、使用頻度が低くなったギフトをギフトダウンロードリスト３１０から除くことができる。

図８は、図６のストリームＤＢ３１２の一例を示すデータ構造図である。ストリームＤＢ３１２は現在行われているライブ配信の情報を保持する。ストリームＤＢ３１２は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定する配信者ＩＤと、当該ライブ配信の視聴者を特定する視聴者ＩＤと、を対応付けて保持する。

図９は、図６のユーザＤＢ３１４の一例を示すデータ構造図である。ユーザＤＢ３１４は、ユーザに関する情報を保持する。ユーザＤＢ３１４は、ユーザを特定するユーザＩＤと、当該ユーザが有しているポイントと、当該ユーザのレベルと、を対応付けて保持する。ポイントは、ライブ配信プラットフォーム内で流通する電子的価値である。配信者がライブ配信において視聴者からギフトを贈られると、配信者のポイントが当該ギフトに対応する値だけ増加する。ポイントは例えば配信者がライブ配信プラットフォームの管理者から受け取る報酬または金銭の額を決めるために用いられる。レベルは、ライブ配信プラットフォームにおけるユーザの活動の量を示す指標である。ユーザが視聴者としてギフトを贈る、配信者としてライブ配信を行う、イベントに参加する、などにより当該ユーザのレベルが上がる。サーバ１０は、ユーザの活動の履歴から当該ユーザのレベルを算出する。

図１０は、図６のギフトＤＢ３１６の一例を示すデータ構造図である。ギフトＤＢ３１６は全てのギフトのアイコンデータとエフェクトデータとを保持する。ギフトＤＢ３１６は、ギフトを特定するギフトＩＤと、当該ギフトを配信者に贈った場合に当該配信者に付与されるポイントである付与ポイントと、当該ギフトのアイコンデータと、当該ギフトのエフェクトデータと、を対応付けて保持する。

図６に戻り、配信情報提供部３０２は、ネットワークＮＷを介して、配信者側のユーザ端末２０からライブ配信を開始する旨の通知を受けると、当該ライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者の配信者ＩＤと、をストリームＤＢ３１２に登録する。配信情報提供部３０２は、ネットワークＮＷを介して、視聴者側のユーザ端末３０の視聴部２００からライブ配信に関する情報の提供要求を受けると、ストリームＤＢ３１２を参照して現在視聴可能なライブ配信のリストを生成する。配信情報提供部３０２は、ネットワークＮＷを介して、生成されたリストを要求元のユーザ端末３０に送信する。要求元のユーザ端末３０の視聴側ＵＩ制御部２０２は、受信したリストに基づいてライブ配信選択画面を生成し、ユーザ端末３０のディスプレイに表示させる。

ユーザ端末３０の視聴側ＵＩ制御部２０２は、ライブ配信選択画面における視聴者によるライブ配信の選択を受け付けると、選択されたライブ配信のストリームＩＤを含む配信要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。配信情報提供部３０２は、受信した配信要求に含まれるストリームＩＤにより特定されるライブ配信の、要求元のユーザ端末３０への提供を開始する。配信情報提供部３０２は、当該ストリームＩＤの視聴者ＩＤに要求元のユーザ端末３０の視聴者の視聴者ＩＤが含まれるようにストリームＤＢ３１２を更新する。

中継部３０４は、配信情報提供部３０２によって開始されたライブ配信において、配信者側のユーザ端末２０から視聴者側のユーザ端末３０への動画データの伝送を中継する。中継部３０４は、視聴者側のユーザ端末３０における動画データの再生中における視聴者によるユーザ入力を示す信号を視聴側ＵＩ制御部２０２から受信する。ユーザ入力を示す信号はギフトのエフェクトデータのダウンロードを要求するギフトＤＬ要求信号と、ギフトの使用を示すギフト使用信号と、を含む。ギフトＤＬ要求信号は、ダウンロード対象のギフトのギフトＩＤを含む。ギフト使用信号は、視聴者の視聴者ＩＤと、贈り先の配信者の配信者ＩＤ（＝アイテムを贈った視聴者が視聴しているライブ配信を行っている配信者の配信者ＩＤ）と、ギフトのギフトＩＤと、を含む。

ギフト情報提供部３０６は、ギフトに関する情報をユーザ端末２０、３０に提供する。ギフト情報提供部３０６は、ユーザ端末からの要求に応じて端末用ギフトダウンロードリストをユーザ端末に送信する。ギフト情報提供部３０６は、中継部３０４が受信したギフトＤＬ要求信号に含まれるギフトＩＤに対応するエフェクトデータをギフトＤＢ３１６から取得する。ギフト情報提供部３０６は、取得されたエフェクトデータをギフトＤＬ要求信号への応答として要求元のユーザ端末に送信する。

ギフト処理部３０８は、ギフト使用信号に含まれるギフトＩＤで特定されるギフトの付与ポイントに応じて配信者のポイントを増加させるようにユーザＤＢ３１４を更新する。ギフト処理部３０８は、ギフトＤＢ３１６を参照し、受信したギフト使用信号に含まれるギフトＩＤに対応する付与ポイントを特定する。ギフト処理部３０８は、ギフト使用信号に含まれる配信者ＩＤに対応するポイントに、特定された付与ポイントを加えるようユーザＤＢ３１４を更新する。

以上の構成によるライブ配信システム１の動作を説明する。
図１１は、ユーザ端末２０、３０における一連のアプリ起動処理の流れを示すフローチャートである。ユーザがライブ配信アプリのアイコンをタップすると、ユーザ端末においてライブ配信アプリが起動する（Ｓ５０２）。ユーザ端末は、軽量モードがＯＮになっているか否かを判定する（Ｓ５０４）。軽量モードは、起動時に端末側ギフト保持部２５０にエフェクトデータが保持されていない全てのギフトを要ロードタイプとするモードである。ユーザ端末は不図示のモード保持部にて軽量モードのＯＮ・ＯＦＦの別を保持する。ユーザ端末はユーザからの指示に応じて軽量モードのＯＮ・ＯＦＦを切り替える。軽量モードがＯＮになっている場合（Ｓ５０４のＹＥＳ）、ユーザ端末はダウンロードキューを更新することなくアプリ起動処理を終了する。

軽量モードがＯＦＦになっている場合（Ｓ５０４のＮＯ）、ギフト情報送受信部２０６はサーバ１０にギフトダウンロードリストを要求する（Ｓ５０６）。ギフト情報送受信部２０６は、ユーザ端末のユーザのユーザＩＤと、当該ユーザ端末が属する領域と、を含むリスト要求信号を生成し、ネットワークＮＷを介してサーバ１０に送信する。ギフト情報提供部３０６は、受信されたリスト要求信号に含まれるユーザＩＤのユーザの属性が所定の基準を満たすか否かを判定する。ギフト情報提供部３０６は、基準が満たされる場合、ギフトＤＢ３１６に登録される全てのギフトＩＤが含まれるように端末用ギフトダウンロードリストを生成する。具体的には、ギフト情報提供部３０６は、ユーザＤＢ３１４を参照し、受信されたリスト要求信号に含まれるユーザＩＤに対応するレベルを特定する。ギフト情報提供部３０６は、特定されたレベルが閾値を上回る場合、ギフトＤＢ３１６に登録される全てのギフトＩＤが含まれるように端末用ギフトダウンロードリストを生成する。ギフト情報提供部３０６は、基準が満たされない場合、ギフトダウンロードリスト３１０を参照し、受信されたリスト要求信号に含まれる領域に対応するギフトＩＤが含まれるように端末用ギフトダウンロードリストを生成する。ギフト情報提供部３０６は、生成された端末用ギフトダウンロードリストをユーザ端末にネットワークＮＷを介して送信する。ユーザ端末２０のギフト情報送受信部２０６はその端末用ギフトダウンロードリストを受信する（Ｓ５０８）。

ギフト判定部２０８は、受信した端末用ギフトダウンロードリストと各ギフトの最終更新日とに基づいて、期限切れのエフェクトデータを端末側ギフト保持部２５０から削除する（Ｓ５０９）。ギフト判定部２０８は、端末側ギフト保持部２５０を参照し、最終更新日と現在の日付との差が閾値（例えば、１４日）を上回るギフトＩＤを特定する。ギフト判定部２０８は、特定されたギフトＩＤが、受信した端末用ギフトダウンロードリストに含まれるか否かを判定する。ギフト判定部２０８は、特定されたギフトＩＤが端末用ギフトダウンロードリストに含まれていない場合、当該ギフトＩＤに対応するエフェクトデータを端末側ギフト保持部２５０から削除する。ギフト判定部２０８は、特定されたギフトＩＤが端末用ギフトダウンロードリストに含まれている場合は削除を行わない。これは、ギフト判定部２０８が、所定の削除基準を満たし、かつ、端末用ギフトダウンロードリストに含まれないギフトのエフェクトデータを削除しているといえる。これにより、プレロードタイプのギフトのエフェクトデータを維持することでインタラクションの即時性を担保しつつ、端末側ギフト保持部２５０のサイズの増大を抑えることができる。

ギフト判定部２０８は、受信した端末側ギフトダウンロードリストと端末側ギフト保持部２５０の内容とに基づいて、エフェクトデータをダウンロードするギフトを特定する（Ｓ５１０）。ギフト判定部２０８は、端末側ギフトダウンロードリストに含まれる各ギフトＩＤについて、端末側ギフト保持部２５０に対応するエフェクトデータが保持されていない場合、当該ギフトＩＤをダウンロード対象のギフトのギフトＩＤとして特定する。ギフト判定部２０８は、特定されたギフトＩＤをダウンロードキュー保持部２５２に任意の順番で登録する（Ｓ５１２）。ギフト情報送受信部２０６は、ダウンロードキュー保持部２５２に登録されている順番に従いエフェクトデータのダウンロードを開始する（Ｓ５１４）。

上記のフローにおいて、ギフト情報送受信部２０６は、プレロードタイプのギフト、すなわち端末用ギフトダウンロードリストに含まれるギフトに対応するエフェクトデータのダウンロードを、当該ギフトのアイコンが指定される前に、ユーザによる指示を介さずに開始する。ギフト判定部２０８は、端末用ギフトダウンロードリストを参照することでプレロードタイプのギフトを特定する。

ステップＳ５０６においてユーザの属性が所定の基準を満たす場合、端末用ギフトダウンロードリストは全てのギフトのギフトＩＤを含むから、ギフト情報送受信部２０６は、ギフトのタイプに依らずに、当該ギフトに対応するエフェクトデータのダウンロードを、ユーザによる指示を介さずに開始する。

上記のフローにおいて、要ロードタイプのギフトのギフトＩＤは端末用ギフトダウンロードリストに含まれないので、要ロードタイプのギフトのエフェクトデータのダウンロードは、ユーザによって当該ギフトが指定される前には開始されない。ただし、後述するように当該ギフトを他のユーザが使用した場合を除く。

図１２は、ユーザ端末２０、３０における一連のダウンロード処理の流れを示すフローチャートである。ユーザ端末のギフト情報送受信部２０６は、ダウンロードキュー保持部２５２の一番上にあるギフトＩＤで特定されるギフトのエフェクトデータのダウンロードを開始する（Ｓ５２０）。ギフト情報送受信部２０６は、ダウンロードキュー保持部２５２に保持されているギフトＩＤのうち最上位すなわち１番のギフトＩＤを含むギフトＤＬ要求信号を生成し、ネットワークＮＷを介してサーバ１０に送信する。

キュー制御部２１０は、ダウンロードキュー保持部２５２の一番上にあるギフトＩＤを削除し、残りのギフトＩＤの順番を一つ減らすようダウンロードキュー保持部２５２を更新する（Ｓ５２２）。例えば、ダウンロードキュー保持部２５２において、順番が２であったギフトＩＤの順番は１となり、順番が３であったギフトＩＤの順番は２となる。

ギフト情報送受信部２０６は、ダウンロードが完了したか否かを判定する（Ｓ５２４）。完了した場合（Ｓ５２４のＹＥＳ）、ギフト情報送受信部２０６はダウンロードされたエフェクトデータを端末側ギフト保持部２５０に登録し、処理をステップＳ５２０に戻す。完了していない場合（Ｓ５２４のＮＯ）、キュー制御部２１０はキュー変更事由が発生したか否かを判定する（Ｓ５２６）。キュー変更事由は少なくとも以下の二つを含む。
（事由１）要ロードタイプのギフトやプレロードタイプであってまだダウンロードされていないギフトに対してユーザが使用の意思を示したこと。具体的には、そのようなギフトのアイコンがユーザによってタップされたこと。
（事由２）同じライブ配信の動画データが配信されている他のユーザ端末の他の視聴者により、要ロードタイプのギフトやプレロードタイプであってまだダウンロードされていないギフトが使用されたこと。

キュー変更事由が発生していない場合（Ｓ５２６のＮＯ）、処理はステップＳ５２４に戻る。キュー変更事由が発生した場合（Ｓ５２６のＹＥＳ）、キュー制御部２１０は、キュー変更事由に従いダウンロードキュー保持部２５２を更新する（Ｓ５２８）。その後、処理はステップＳ５２４に戻る。

ステップＳ５２８を詳述する。事由１については図１３にて後述する。事由２について、図２の例を用いて説明する。配信者ＬＶがライブ配信を配信し、視聴者ＡＵ１と視聴者ＡＵ２とがその同じライブ配信を視聴している。ここで、視聴者ＡＵ２がギフトを使用すると、当該ギフトのギフトＩＤを含むギフト使用信号がユーザ端末３０ｂによって生成され、ネットワークＮＷを介してサーバ１０に送信される。併せてユーザ端末３０ｂは当該ギフトに対応するエフェクトデータを処理することでエフェクトを動画像ＶＤ２に重畳表示させる。サーバ１０は、ストリームＤＢ３１２を参照することで、視聴者ＡＵ２が視聴しているライブ配信と同じライブ配信を視聴している他の視聴者を特定する。サーバ１０は、受信したギフト使用信号に含まれるギフトＩＤを含むギフト通知信号を生成し、ネットワークＮＷを介して特定された他の視聴者（ここでは視聴者ＡＵ１）のユーザ端末３０ａに送信する。ユーザ端末３０ａは、受信したギフト通知信号に含まれるギフトＩＤに対応するエフェクトデータが端末側ギフト保持部２５０に保持されているか判定する。ユーザ端末３０ａは、保持されていればそのエフェクトデータを処理することでユーザ端末３０ｂのエフェクトと同じエフェクトを動画像ＶＤ１に重畳表示させる。保持されていない場合、ユーザ端末３０ｂは事由２が発生したと判定する。

キュー制御部２１０は、ギフトのダウンロードについて、以下の優先関係が成立するようダウンロードキュー保持部２５２を制御する。
優先順位１：事由１に係るギフトに対応するエフェクトデータのダウンロード。
優先順位２：事由２に係るギフトに対応するエフェクトデータのダウンロード。
優先順位３：ライブ配信アプリの起動時にダウンロードキュー保持部２５２に登録されたギフトに対応するエフェクトデータのダウンロード。

キュー制御部２１０は、事由１が発生した場合、ダウンロードキュー保持部２５２に保持されている全てのギフトＩＤの順番を一つ増加させ、かつ、事由１に係るギフトのギフトＩＤを順番１のエントリに挿入する。すなわち、キュー制御部２１０は、事由１に係るギフトのギフトＩＤをダウンロードキューの一番上に割り込ませる。例えば、ダウンロードキュー保持部２５２において、順番が１であったギフトＩＤの順番は２となり、順番が２であったギフトＩＤの順番は３となり、事由１に係るギフトのギフトＩＤの順番は１として登録される。これにより、事由１に係るギフトのエフェクトデータのダウンロードが現在進行中のダウンロードの次に開始されることとなる。

キュー制御部２１０は、事由２が発生した場合、ダウンロードキュー保持部２５２に保持されているギフトＩＤのうち、事由１に係るギフトのギフトＩＤ以外の全てのギフトＩＤの順番を一つ増加させ、かつ、事由２に係るギフトのギフトＩＤを事由１に係るギフトのギフトＩＤの直下のエントリに挿入する。すなわち、キュー制御部２１０は、ダウンロードキューにおいて、事由２に係るギフトのギフトＩＤを事由１に係るギフトのギフトＩＤとそれ以外のギフトＩＤとの間に割り込ませる。例えば、ダウンロードキュー保持部２５２において、順番が１であった事由１に係るギフトＩＤの順番は１のままであり、順番が２であったギフトＩＤの順番は３となり、事由２に係るギフトのギフトＩＤの順番は２として登録される。

図１３は、ユーザ端末２０、３０における一連のギフト使用処理の流れを示すフローチャートである。前提として、視聴者がユーザ端末３０からライブ配信プラットフォームにアクセスし、ライブ配信選択画面から所望のライブ配信を選択して視聴を開始したとする。視聴者がライブ配信を視聴している間、配信者のユーザ端末２０からサーバ１０（の中継部３０４）を介して視聴者のユーザ端末３０へと継続的に動画データが伝送される。

この動画データの再生中に、視聴者はユーザ端末３０の入力手段を介してアイテムの表示を要求するためのユーザ入力を行う。ユーザ端末３０の視聴側ＵＩ制御部２０２はこのユーザ入力を受けると、端末側ギフト保持部２５０を参照し、各ギフトのダウンロードステータスを取得する（Ｓ２８０）。ダウンロードステータスは、エフェクトデータが端末側ギフト保持部２５０に保持されている場合は「ＤＬ済み」、エフェクトデータが端末側ギフト保持部２５０に保持されていない場合は「未ＤＬ」、エフェクトデータのダウンロードが現在進行中の場合は「ＤＬ中」、となる。

視聴側ＵＩ制御部２０２および重畳情報生成部２０４は、ステップＳ２８０で取得されたダウンロードステータスに応じた態様で各ギフトアイコンを表示させる（Ｓ２８２）。重畳情報生成部２０４は、各ギフトについて、端末側ギフト保持部２５０からアイコンデータを取得して処理することでギフトアイコンを生成する。重畳情報生成部２０４は、生成されたギフトアイコンに、ステップＳ２８０で取得されたダウンロードステータスに応じた視覚的効果を付与する。例えば、重畳情報生成部２０４は、ダウンロードステータスが「ＤＬ中」の場合は、対応するギフトアイコンにダウンロードのステータスを示すインジケータを関連付ける。例えば重畳情報生成部２０４は、ギフトアイコンにダウンロードの進捗を示すプログレスバーを付与する。重畳情報生成部２０４は、ダウンロードステータスが「未ＤＬ」の場合、ダウンロードキュー保持部２５２を参照することで当該ギフトがダウンロードキューに入っているか否かを判定する。重畳情報生成部２０４は、ダウンロードキューに入っている場合は、対応するギフトアイコンにダウンロード待ちであることを示す視覚的効果（シェーディングなど）を付与する。重畳情報生成部２０４は、ダウンロードキューに入っていない場合は、対応するギフトアイコンにダウンロードが必要であることを示すマークを付与する。重畳情報生成部２０４は、ダウンロードステータスが「ＤＬ済み」の場合、視覚的効果の付与は行わない。重畳情報生成部２０４は、そのように生成された加工済みまたは加工無しのギフトアイコンを、サーバ１０から取得された動画データの画像に重畳させる。視聴側ＵＩ制御部２０２は、ギフトアイコンが重畳された画像をディスプレイに表示させる。

視聴側ＵＩ制御部２０２は、ステップＳ２８２でディスプレイに表示されたギフトアイコンへのタップを検出するまで待機する（Ｓ２８４）。待機中にダウンロードステータスが変更された場合（例えば、「ＤＬ中」が「ＤＬ済み」になる、キューに入っていた「未ＤＬ」が「ＤＬ中」となり「ＤＬ済み」になる）、対応するギフトアイコンの視覚的効果もダウンロードステータスの変更に応じて変更される。ギフトアイコンへのタップが検出されると（Ｓ２８４のＹＥＳ）、ギフト判定部２０８はタップにより指定されたギフトアイコンに対応するギフトのダウンロードステータスが「未ＤＬ」、「ＤＬ済み」、「ＤＬ中」のいずれであるかを判定する（Ｓ２８６）。

ダウンロードステータスが「未ＤＬ」である場合、キュー制御部２１０はタップにより指定されたギフトのギフトＩＤをダウンロードキュー保持部２５２の一番上に挿入する（Ｓ２８８）。これは、上記の事由１が発生した場合に相当する。その後、処理はステップＳ２８０に戻る。この結果、タップにより指定されたギフトのエフェクトデータのダウンロードが最優先で開始される。

ダウンロードステータスが「ＤＬ中」である場合、視聴側ＵＩ制御部２０２はタップにより指定されたギフトのエフェクトデータがダウンロード中であることを示すテキストを含むポップアップをディスプレイに表示させる。テキストは例えば「ロード中です。ロードが完了いたしましたら、タップしてギフトを贈ってください」であってもよい。その後、処理はステップＳ２８０に戻る。

ダウンロードステータスが「ＤＬ済み」である場合、ギフト情報送受信部２０６は、タップにより指定されたギフトのギフトＩＤを含むギフト使用信号を生成し、ネットワークＮＷを介してサーバ１０に送信する（Ｓ２９２）。重畳情報生成部２０４および視聴側ＵＩ制御部２０２は、タップにより指定されたギフトのエフェクトデータを端末側ギフト保持部２５０から読み出して処理することでギフトのエフェクトを出力する（Ｓ２９４）。ギフト判定部２０８は、端末側ギフト保持部２５０にアクセスし、タップにより指定されたギフトの最終更新日を現在の日付となるよう更新する（Ｓ２９６）。その後、処理はステップＳ２８０に戻る。

図１４は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信選択画面６０２の代表画面図である。ライブ配信選択画面６０２は、現在視聴可能なライブ配信のリストにある各ライブ配信を示すサムネイル６０４を含む。視聴側ＵＩ制御部２０２は、サーバ１０から取得したライブ配信のリストに基づいてライブ配信選択画面６０２を生成し、ディスプレイに表示させる。

図１５は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６１０の代表画面図である。図１４のライブ配信選択画面６０２において視聴者がサムネイルをタップし、かつギフトの表示を要求すると、図１５のライブ配信ルーム画面６１０がディスプレイに表示される。ライブ配信ルーム画面６１０は、動画データを再生することにより得られる配信者の画像６１２と、ギフトアイコン６１４、６１６、６１８と、を有する。

ギフトアイコン６１４は、ダウンロードステータスが「未ＤＬ」でありかつダウンロードキュー保持部２５２に登録されていないギフトのギフトアイコンである。ギフトアイコン６１４は、ダウンロードが必要であることを示すマーク６２０を有する。このギフトアイコン６１４で表されるギフトは要ロードタイプのギフトである。

ギフトアイコン６１６は、ダウンロードステータスが「未ＤＬ」でありかつダウンロードキュー保持部２５２に登録されているギフトのギフトアイコンである。ギフトアイコン６１６には、ダウンロードの待機中であることを示すシェーディングが施されている。このギフトアイコン６１６で表されるギフトは基本的に、プレロードタイプのギフトであってまだダウンロードの順番が回ってきていないギフトである。

ギフトアイコン６１８は、ダウンロードステータスが「ＤＬ済み」であるギフトのギフトアイコンである。このギフトアイコン６１８で表されるギフトは、（１）プレロードタイプのギフトであってエフェクトデータのダウンロードが完了したギフト、（２）要ロードタイプのギフトであったものがユーザによる指定もしくは他のユーザによる使用によりエフェクトデータのダウンロードが完了したギフト、のいずれかである。（２）のギフトは既にエフェクトデータのダウンロードが完了しているので、もはや要ロードタイプのギフトとは言えない。ただし、当該エフェクトデータが期限切れで端末側ギフト保持部２５０から削除されると、当該ギフトは要ロードタイプのギフトに戻る。

図１５のライブ配信ルーム画面６１０において視聴者がギフトアイコン６１８をタップすると、ユーザ端末３０は当該視聴者による当該ギフトアイコン６１８の指定を受け付ける。ユーザ端末３０は、指定されたギフトアイコン６１８が表すギフトに対応するエフェクトデータを端末側ギフト保持部２５０から読み出して処理することで、ギフトアイコン６１８に対応するエフェクトを実現する。

図１６は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６２２の代表画面図である。図１５のライブ配信ルーム画面６１０において視聴者がギフトアイコン６１４をタップすると、ユーザ端末３０は当該視聴者による当該ギフトアイコン６１４の指定を受け付ける。ユーザ端末３０は、指定されたギフトアイコン６１４が表すギフト（以下、ユーザ指定ギフトという）に対応するエフェクトデータのダウンロードを開始する。図１６のライブルーム配信画面６２２において、図１５のギフトアイコン６１４は、マーク６２０の代わりにダウンロードの進捗を示すプログレスバー６２４を含むギフトアイコン６２６に変化している。

図１７は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６２８の代表画面図である。図１５の状態から時間が経過し、ユーザ指定ギフトのエフェクトデータのダウンロードが完了したので、図１６のライブルーム配信画面６２８では、ユーザ指定ギフトのギフトアイコン６３０はダウンロードステータスが「ＤＬ済み」のギフトアイコンの表示態様で表示されている。図１５のライブ配信ルーム画面６１０においてギフトアイコン６１６で表されていたギフトのエフェクトデータのダウンロードが進行中となったので、当該ギフトのギフトアイコン６３２はプログレスバーを含む。

図１８は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６３４の代表画面図である。図１７のライブ配信ルーム画面６２８において視聴者がギフトアイコン６３０をタップすると、ユーザ端末３０はユーザ指定ギフトのエフェクトが重畳された配信者の画像６３６を含むライブルーム配信画面６３４をディスプレイに表示させる。

図１９は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６３８の代表画面図である。ライブルーム配信画面６３８では軽量モードがＯＮになっている。軽量モードではプレロードタイプのギフトは存在しないので、ライブルーム配信画面６３８に表示されるギフトアイコン６４０、６４２、６４４はいずれもダウンロードステータスが「未ＤＬ」でありかつダウンロードキュー保持部２５２に登録されていないギフトのギフトアイコンである。これらのギフトアイコンはそれぞれ、ダウンロードが必要であることを示すマークを有する。これらのギフトアイコンで表されるギフトは要ロードタイプのギフトである。

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

本実施の形態に係るライブ配信システム１では、全てのギフトのエフェクトデータを予めダウンロードしておくのではなく、指定されたプレロードタイプのギフトのエフェクトデータを予めダウンロードすると共に残りの要ロードタイプのギフトについてはユーザによる指定をトリガとしてダウンロードを開始するよう構成される。これにより、大きなサイズのエフェクトデータを用いてより豊かなエフェクトを実現しつつ、ダウンロードによる通信量の増大を抑えると共にライブ配信アプリのインストールに必要な容量の増大を抑えることができる。

また、本実施の形態に係るライブ配信システム１では、プレロードタイプのギフトについては視聴者がタップすると、配信者の画面にも当該視聴者の画面にも他の視聴者の画面にも即座にエフェクトが出力される。したがって、配信者と視聴者とのインタラクションの即時性を維持することができる。

一例では、エフェクトデータの総量は数十ＧＢにもなる。本実施の形態に係る技術的思想を適用することで、ユーザ端末が保持するエフェクトデータの量を数ＧＢ～数百ＭＢまで低減することができる。また、代表的なエフェクトデータ一つを代表的な通信環境でダウンロードするのにかかる時間は数十ミリ秒～数秒であるが、この程度の遅延によるユーザ体験への悪影響は限定的である。したがって、多くの場合において、要ロードタイプを設けることによるメリットはデメリットを上回る。

また、本実施の形態に係るライブ配信システム１では、ＤＬ済みのギフトと未ＤＬのギフトとを異なる態様で表示する。したがって、ユーザはどのギフトのダウンロードの状態を一目で理解することができるので、ユーザ利便性が向上する。特に、ライブ配信の特性としてその場ですぐにギフトを贈りたいという状況が頻繁に生じるのであるが、そのような状況でユーザは未ＤＬのギフトを避けてＤＬ済みのギフトを容易に選択できる。これによりユーザの満足度が向上する。

また、本実施の形態に係るライブ配信システム１では、ユーザにより指定されたギフトのエフェクトデータのダウンロードが、プレロードタイプのギフトの自動ダウンロードよりも優先される。これにより、ギフト使用のためにユーザが待たなければならない時間を低減することができるので、ユーザの満足度を高めることができる。

また、本実施の形態に係るライブ配信システム１では、他のユーザが使用したギフトのエフェクトデータのダウンロードが、プレロードタイプのギフトの自動ダウンロードよりも優先される。これにより、エフェクト出力の遅延を抑えることができるので、例えば配信者の感謝の言葉とエフェクト出力タイミングとがずれることによる違和感を軽減できる。

また、本実施の形態に係るライブ配信システム１では、属性が所定の基準を満たしたユーザについては全てのギフトをプレロードする。これにより、例えばライブ配信プラットフォームの利用年数が長い、および／または、課金総額が高いユーザについては全てのギフトをプレロードすることで、そのようなユーザのユーザ体験を最大化することができる。あるいはまた、いわゆるヘビーユーザの有するユーザ端末は高機能・大容量である確率が高いので、そのようなユーザには全てのギフトをプレロードすることでユーザ体験を最大化することができる。

［ハードウェア構成例］
図２０を参照して、本実施の形態に係る情報処理装置のハードウェア構成について説明する。図２０は、本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。図示された情報処理装置９００は、例えば、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれを実現しうる。

情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（Read Only Memory）９０３、およびＲＡＭ（Random Access Memory）９０５を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インタフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２５、通信装置９２９を含んでもよい。さらに、情報処理装置９００は、カメラなどの撮像装置（不図示）を含む。また、情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital Signal Processor）またはＡＳＩＣ（Application Specific Integrated Circuit）と呼ばれるような処理回路を有してもよい。

ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９、またはリムーバブル記録媒体９２３に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。例えば、ＣＰＵ９０１は、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれに含まれる各機能部の動作全般を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３、およびＲＡＭ９０５は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral Component Interconnect/Interface）バスなどの外部バス９１１に接続されている。

入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置であってもよいし、マイクロフォンなどの音センサ、加速度センサ、傾きセンサ、赤外線センサ、深度センサ、温度センサ、湿度センサなど物理量を電気信号に変換する装置であってもよい。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２７であってもよい。入力装置９１５は、ユーザが入力した情報または感知した物理量に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。

出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ、ＰＤＰ、ＯＥＬＤなどのディスプレイ、スピーカおよびヘッドホンなどの音響出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音響などの音として出力したりする。

ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard Disk Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２３のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録を書き込む。

接続ポート９２５は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２５は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）ポートなどでありうる。また、接続ポート９２５は、ＲＳ－２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）ポートなどであってもよい。接続ポート９２５に外部接続機器９２７を接続することで、情報処理装置９００と外部接続機器９２７との間で各種のデータが交換されうる。

通信装置９２９は、例えば、ネットワークＮＷに接続するための通信デバイスなどで構成された通信インタフェースである。通信装置９２９は、例えば、有線または無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless USB）用の通信カードなどでありうる。また、通信装置９２９は、光通信用のルータ、ＡＤＳＬ（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２９は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２９に接続される通信ネットワークＮＷは、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。なお、通信装置９２９は、通信部としての機能を実現する。

カメラなどの撮像装置（不図示）は、例えばＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。当該撮像装置は、静止画を撮像するものであってもよいし、または動画を撮像するものであってもよい。

以上、実施の形態に係るライブ配信システム１の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解される。

実施の形態に係る技術的思想を、配信者の画像の代わりに配信者の動きと同期した動きをするアバターを用いるバーチャルライブ配信や、ライブコマースに適用してもよい。

実施の形態では、要ロードタイプのギフトを使用する際、まず当該ギフトのギフトアイコンをタップすることでエフェクトデータのダウンロードを開始し、ダウンロードが完了した後に改めてギフトアイコンをタップすることでギフトを使用する場合を説明したが、これに限られない。例えば、ユーザ端末は、要ロードタイプのギフトアイコンに対するタップを検出すると、そのギフトアイコンが表すギフトのエフェクトデータのダウンロードを開始し、ダウンロードが完了すると、ユーザからさらなる指示を受けることなく自動で当該ギフトを使用するための処理を行ってもよい。この場合、ギフトを使用するためのタップの回数が減るので、ユーザの手間を削減できる。

実施の形態では、要ロードタイプのギフトのギフトアイコンに対するタップを検出した場合に当該ギフトのエフェクトデータのダウンロードを開始する場合を説明したが、これに限られない。例えば、ユーザ端末は、ユーザから入力手段を介して、要ロードタイプのギフトのギフトアイコンを表示するための要求を受け付けると、当該ギフトのエフェクトデータのダウンロードを開始してもよい。

実施の形態において、ユーザがユーザ端末の属する領域を変更した場合、ユーザ端末は変更後の領域のギフトダウンロードリストに含まれないギフトのエフェクトデータを、端末側ギフト保持部２５０から削除してもよい。

実施の形態では、ユーザ端末がギフトダウンロードリストと端末側ギフト保持部２５０の内容とを比較する場合を説明したが、これに限られない。例えば、ライブ配信アプリの起動時、ユーザ端末は端末側ギフト保持部２５０を参照してエフェクトデータが存在するギフトのギフトＩＤのリストを生成し、サーバ１０に送信する。サーバ１０は受信したリストとギフトダウンロードリストとを比較して、ユーザ端末にダウンロードすべきエフェクトデータを特定する。サーバ１０は特定されたエフェクトデータのギフトＩＤをユーザ端末に送信する。ユーザ端末は、受信したギフトＩＤをダウンロードキュー保持部２５２に登録し、ダウンロードを開始する。

実施の形態では、事由１や事由２が発生した場合、現在進行中のダウンロードが完了してからそれらの事由に係るギフトのエフェクトデータのダウンロードを開始する場合を説明したが、これに限られない。例えば、事由１や事由２が発生した場合、ユーザ端末は現在進行中のダウンロードを一時停止またはキャンセルし、それらの事由に係るギフトのエフェクトデータのダウンロードを開始してもよい。

本明細書において説明された処理手順、特にフロー図、フローチャートを用いて説明された処理手順においては、その処理手順を構成する工程（ステップ）の一部を省略すること、その処理手順を構成する工程として明示されていない工程を追加すること、及び／又は当該工程の順序を入れ替えることが可能であり、このような省略、追加、順序の変更がなされた処理手順も本開示の趣旨を逸脱しない限り本開示の範囲に含まれる。

サーバ１０により実現される機能の少なくとも一部は、サーバ１０以外の装置、例えばユーザ端末２０、３０により実現されてもよい。ユーザ端末２０、３０により実現される機能の少なくとも一部は、ユーザ端末２０、３０以外の装置、例えば、サーバ１０により実現されてもよい。例えば、再生側のユーザ端末で行われる動画データの画像への所定のフレーム画像の重畳は、サーバ１０で行われてもよいし、生成側のユーザ端末で行われてもよい。

Claims (10)

1. 端末に、
   ライブ配信に係る動画データの再生中に、第１タイプのギフトを表す第１ユーザインタフェースオブジェクトをディスプレイに表示させる機能と、
   前記端末のユーザによる前記第１ユーザインタフェースオブジェクトの指定を受け付けた場合、前記端末の保持部に保持されている、前記第１ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する機能と、
   前記動画データの再生中に、第２タイプのギフトを表す第２ユーザインタフェースオブジェクトを前記ディスプレイに表示させる機能と、
   ユーザによる前記第２ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第２ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能と、を実現させるためのコンピュータプログラム。
2. 前記ダウンロードのステータスを示すインジケータを前記第２ユーザインタフェースオブジェクトに関連付けて前記ディスプレイに表示させる機能をさらに前記端末に実現させる請求項１に記載のコンピュータプログラム。
3. 前記第１タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記第１ユーザインタフェースオブジェクトが指定される前に、ユーザによる指示を介さずに開始する機能をさらに前記端末に実現させる請求項１または２に記載のコンピュータプログラム。
4. 前記ユーザによる指示を介さずに開始する機能は、リストを参照することで特定された前記第１タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記第１ユーザインタフェースオブジェクトが指定される前に、ユーザによる指示を介さずに開始する機能を含み、
   前記リストは更新可能に構成される請求項３に記載のコンピュータプログラム。
5. 前記第２タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第２ユーザインタフェースオブジェクトが指定される前には開始されない請求項１から４のいずれか一項に記載のコンピュータプログラム。
6. 前記第２タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第１タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先される請求項１から５のいずれか一項に記載のコンピュータプログラム。
7. 前記動画データが配信されている他の端末の他のユーザにより使用されたギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する機能をさらに前記端末に実現させ、
   当該ギフトに対応するエフェクトを実現するためのデータのダウンロードは、前記第１タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先され、
   前記第２タイプのギフトに対応するエフェクトを実現するためのデータのダウンロードは、当該ギフトに対応するエフェクトを実現するためのデータのダウンロードよりも優先される請求項１から６のいずれか一項に記載のコンピュータプログラム。
8. 前記ユーザの属性が所定の基準を満たす場合、ギフトのタイプに依らずに、当該ギフトに対応するエフェクトを実現するためのデータのダウンロードを、前記ユーザによる指示を介さずに開始する機能をさらに前記端末に実現させる請求項１から７のいずれか一項に記載のコンピュータプログラム。
9. 保持手段と、
   ライブ配信に係る動画データの再生中に、第１タイプのギフトを表す第１ユーザインタフェースオブジェクトをディスプレイに表示させる手段と、
   前記端末のユーザによる前記第１ユーザインタフェースオブジェクトの指定を受け付けた場合、前記保持手段に保持されている、前記第１ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理する手段と、
   前記動画データの再生中に、第２タイプのギフトを表す第２ユーザインタフェースオブジェクトを前記ディスプレイに表示させる手段と、
   ユーザによる前記第２ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第２ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始する手段と、を備える端末。
10. 端末において実行される方法であって、
    ライブ配信に係る動画データの再生中に、第１タイプのギフトを表す第１ユーザインタフェースオブジェクトをディスプレイに表示させることと、
    前記端末のユーザによる前記第１ユーザインタフェースオブジェクトの指定を受け付けた場合、前記端末の保持部に保持されている、前記第１ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータを処理することと、
    前記動画データの再生中に、第２タイプのギフトを表す第２ユーザインタフェースオブジェクトを前記ディスプレイに表示させることと、
    ユーザによる前記第２ユーザインタフェースオブジェクトの指定を受け付けた場合、前記第２ユーザインタフェースオブジェクトが表すギフトに対応するエフェクトを実現するためのデータのダウンロードを開始することと、を含む方法。

Images