JP7302806B1 - サーバ、コンピュータプログラム及び端末 - Google Patents

Abstract

【課題】予期しない理由でライブ配信が終了した場合でもそれによる損失を低減する。【解決手段】サーバは、ライブ配信の配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、ライブ配信が予期しない理由で終了したか否かを判定する手段と、終了したと判定された場合、ライブ配信の状態を維持する手段と、終了したと判定されてから所定の期間内に配信者の端末からライブ配信の再開の指示を受信した場合、ライブ配信を維持されている状態で再開させる手段と、を備える。【選択図】図１

Description

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

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

ライブ配信の配信側の機材には、リアルタイムで高品質の動画を生成するために比較的高いスペックが要求される。したがって、従来は高スペックの据え置き型のＰＣに専用のソフトウエアを導入することで配信端末を構成していた。しかしながら、昨今のスマートフォンなどの携帯端末の性能の向上により、スマートフォン一台でライブ配信を行うことも現実的になってきた（例えば、非特許文献１参照）。

「iPhone/Androidだけでゲーム配信・生配信するなら、知っておくべき7つのこと」、 新・VIPで初心者がゲーム実況するには、URL:https://vip-jikkyo.net/live-stream-from-a-smartphone

スマートフォンでライブ配信を行う場合、スマートフォンの性能には大きな幅があり、また接続も比較的不安定なので、予期しない理由によりライブ配信が突然終了するという事象が起こりやすい。オンライン会議などとは違い、ライブ配信では配信者が創意工夫し努力してスコアや獲得ギフトや人気度や盛り上がりなどを高めていく。ライブ配信が意図せず終了すると、配信者はそれらの積み上げたものを一瞬で失うこととなる。これは配信者をいらだたせ、ライブ配信を続けようという意欲を削ぐ原因となりうる。

本開示はこうした課題に鑑みてなされたものであり、その目的は、予期しない理由でライブ配信が終了した場合でもそれによる損失を低減することができる技術の提供にある。

本発明のある態様は、サーバに関する。このサーバは、ライブ配信の配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、ライブ配信が予期しない理由で終了したか否かを判定する手段と、終了したと判定された場合、ライブ配信の状態を維持する手段と、終了したと判定されてから所定の期間内に配信者の端末からライブ配信の再開の指示を受信した場合、ライブ配信を維持されている状態で再開させる手段と、を備える。

本発明の別の態様は、コンピュータプログラムである。このコンピュータプログラムは、ライブ配信の配信者の端末に、ネットワークを介してサーバに、ライブ配信に係る動画データを送信する機能と、ライブ配信が予期しない理由で終了した場合、ライブ配信を再開するか否かを配信者に問い合わせるための画面をディスプレイに表示させる機能と、を実現させる。

本発明のさらに別の態様は、コンピュータプログラムである。このコンピュータプログラムは、ライブ配信の視聴者の端末に、ネットワークを介してサーバから、ライブ配信に係る動画データを受信する機能と、ライブ配信の配信者の端末においてライブ配信が予期しない理由で終了した場合、視聴者の端末においてライブ配信を終了させずに待機要請画面をディスプレイに表示させる機能と、待機要請画面に残り時間を表示させる機能と、ライブ配信が再開されないまま残り時間が無くなると視聴者の端末においてライブ配信を終了させる機能と、を実現させる。

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

本発明によれば、予期しない理由でライブ配信が終了した場合でもそれによる損失を低減することができる。

本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図１のサーバの機能および構成を示すブロック図である。 図３のストリームＤＢの一例を示すデータ構造図である。 ライブ配信のステータス遷移図である。 図３のユーザＤＢの一例を示すデータ構造図である。 図３のギフトＤＢの一例を示すデータ構造図である。 ライブ配信が予期しない理由で終了したときのサーバにおける一連の処理の流れを示すフローチャートである。 ライブ配信アプリを起動したときのユーザ端末における一連の処理の流れを示すフローチャートである。 配信者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される再開問い合わせ画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される、再開成功メッセージ表示領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される、終了メッセージ表示領域が重畳表示されたライブ配信選択画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される、再起動問い合わせ領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される待機要請画面の代表画面図である。 アクティブユーザのユーザ端末のディスプレイに表示されるプッシュ通知画面の代表画面図である。 本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

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

実施の形態に係るライブ配信システムでは、ライブ配信が予期しない理由で終了した場合、サーバはそのライブ配信の状態を再開可能期間の間、維持する。配信者のユーザ端末は配信者に、終了したライブ配信を再開させるか否かを問い合わせる。再開可能期間内に再開の指示があると、終了したライブ配信は終了直前の状態から再開される。これにより、配信者は視聴者の流出を抑制することができ、また、それまで蓄積されたスコアや他のライブ配信のパラメータや盛り上がりの度合いを維持した状態でライブ配信を続けることができる。

予期しない理由には例えば、配信者のユーザ端末における障害（ライブ配信アプリの強制終了（クラッシュ）、意図しないまたは操作ミスによるライブ配信アプリの終了など）や、ネットワークにおける障害（ネットワーク遅延、ネットワーク切断、無線接続の不良など）や、サーバにおける障害（サーバエラー、過負荷、停電、監視員の誤認識による強制終了など）がある。本実施の形態では主に配信者のユーザ端末においてライブ配信アプリの強制終了が発生した場合を説明する。他のタイプの理由についても本実施の形態に係る技術的思想を適用できることは、本明細書に触れた当業者には理解される。配信者からライブ配信を止めるための指示を受け付けたことは、予期しない理由に含まれない。

図１は、本開示の実施の形態に係るライブ配信システム１の構成を示す模式図である。ライブ配信システム１は、配信者（ライバー、ストリーマ（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 (11)

1. ライブ配信の配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、
   前記ライブ配信が予期しない理由で終了したか否かを判定する手段と、
   終了したと判定された場合、前記ライブ配信の状態を維持する手段と、
   終了したと判定されてから所定の期間内に前記配信者の端末から前記ライブ配信の再開の指示を受信した場合、前記ライブ配信を維持されている状態で再開させる手段と、を備えるサーバ。
2. 前記所定の期間内に再開の指示を受信しなかった場合、または、非再開の指示を受信した場合、維持されている前記ライブ配信の状態を破棄する手段をさらに備える請求項１に記載のサーバ。
3. 前記ライブ配信が予期しない理由で終了したと判定された場合、待機要請画面を表示させるための通知を前記ライブ配信の視聴者の端末に送信する手段をさらに備える請求項１に記載のサーバ。
4. 前記ライブ配信が再開された場合、前記ライブ配信が予期しない理由で終了したと判定されてから前記ライブ配信が再開されるまでの間に前記ライブ配信から退出した視聴者の端末に、前記ライブ配信が再開されたことを知らせるための通知を送信する手段をさらに備える請求項１に記載のサーバ。
5. ライブ配信の配信者の端末に、
   ネットワークを介してサーバに、前記ライブ配信に係る動画データを送信する機能と、
   前記ライブ配信が予期しない理由で終了した場合、前記ライブ配信を再開するか否かを前記配信者に問い合わせるための画面をディスプレイに表示させる機能と、を実現させるためのコンピュータプログラム。
6. 前記表示させる機能は、前記ライブ配信が予期しない理由で終了してから所定の期間内に限り前記画面を前記ディスプレイに表示させる請求項５に記載のコンピュータプログラム。
7. 前記画面は前記所定の期間に係る残り時間を表示する請求項６に記載のコンピュータプログラム。
8. 前記理由は、前記端末における障害または前記ネットワークにおける障害または前記サーバにおける障害である請求項５に記載のコンピュータプログラム。
9. 前記ライブ配信を止めるための指示を前記配信者から受け付ける機能をさらに前記端末に実現させ、
   前記指示を受け付けたことは前記理由に含まれない請求項５に記載のコンピュータプログラム。
10. ライブ配信の配信者の端末であって、
    ネットワークを介してサーバに、前記ライブ配信に係る動画データを送信する手段と、
    前記ライブ配信が予期しない理由で終了した場合、前記ライブ配信を再開するか否かを前記配信者に問い合わせるための画面をディスプレイに表示させる手段と、を備える端末。
11. ライブ配信の視聴者の端末に、
    ネットワークを介してサーバから、前記ライブ配信に係る動画データを受信する機能と、
    前記ライブ配信の配信者の端末において前記ライブ配信が予期しない理由で終了した場合、前記視聴者の端末において前記ライブ配信を終了させずに待機要請画面をディスプレイに表示させる機能と、
    前記待機要請画面に残り時間を表示させる機能と、
    前記ライブ配信が再開されないまま前記残り時間が無くなると前記視聴者の端末において前記ライブ配信を終了させる機能と、を実現させるためのコンピュータプログラム。

Images