JP7394250B1 - 情報処理装置、端末、情報処理システムおよび情報処理方法 - Google Patents

Abstract

【課題】ライブ配信に係るサービスに関し、配信者の満足度を向上する。【解決手段】情報処理サーバ３は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの１つをライブ配信の視聴者の端末に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有するサーバ制御部１４を備える。【選択図】図２

Description

本発明は、ライブ配信に関する処理を実行可能な情報処理装置、当該情報処理装置と通信可能な端末、当該情報処理装置と当該端末とを備える情報処理システム、および、当該情報処理装置による情報処理方法に関する。

近年、ライブ配信に係るサービスを利用したライブ配信が広く行われている。ライブ配信の態様は色々とあるものの、１つの態様では、配信者（２人以上の人間が共同して配信者となる場合もある）と不特定の視聴者とが参加し、配信者側の端末（以下「配信者端末」という）で配信者の挙動が撮影されると共に、配信者端末の撮影結果に基づく動画がリアルタイムで視聴者側の端末（以下「視聴者端末」という）に配信される。以下では、単に「ライブ配信」と表現する場合、特に説明がない限り、このような態様のライブ配信であるものとする。そして従来、ライブ配信に係るサービスに関して、種々の技術が提案されている。例えば特許文献１には、ライブ配信中に、視聴者に関する有益な情報を含むアドバイス情報をリアルタイムで配信者に提供し、配信者を支援する技術が記載されている。また例えば特許文献２には、ライブ配信中に視聴者からの投票を受け付けると共に投票について抽選を行い、当選した投票に係る視聴者と配信者とが一対一で会話できるようにした技術が記載されている。

特許２０２２－０７５４０１号公報 特許２０２２－０８４２１４号公報

ライブ配信に係るサービスに関しては、配信者の満足度を向上することが常に求められている。配信者の満足度の向上を実現することにより、配信者となりたいユーザに対して、サービスを利用しようとするインセンティブを与えることができ、サービスを利用する配信者の増加、およびこれに伴う視聴者の増加につながるからである。

本発明は、このような問題を解決するために成されたものであり、ライブ配信に係るサービスに関し、配信者の満足度を向上することを目的とする。

上記した課題を解決するために、本発明は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの１つをライブ配信の視聴者の端末に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する。

上記のように構成した本発明によれば、配信者は、ライブ配信中に、リプライの開始を指示し、当該指示に応じて視聴者の端末に表示されるリクエストにリプライし、リプライの完了後にリプライの終了を指示するという作業を行う。配信者によってこのような作業が行われることによって、配信者によって行われたリプライごとに、リプライを行った期間のライブ配信に係る動画が記録された抽出動画データが生成される。この抽出動画データに記録された動画は、１つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年ではライブ配信だけではなく、ライブ配信の一部を抽出した動画（「切抜き動画」と呼ばれることもある）が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。そして本発明によれば、このような利用価値の高い抽出動画データを生成するために、配信者は、ライブ配信全体の動画が記録された動画データを編集したり、抽出動画データの生成を他人に頼ったりする必要がなく、配信者の満足度を向上できる。すなわち本発明によれば、ライブ配信に係るサービスに関し、配信者の満足度を向上することができる。

本発明の一実施形態に係る情報処理システムの構成例を示す図である。 本発明の一実施形態に係る端末および情報処理サーバの機能構成例を示すブロック図である。 配信者側画面を示す図である。 視聴者側画面を示す図である。 情報処理システムの動作例を示すフローチャートである。 各種データベースのレコードの内容を示す図である。 ライブ配信中の情報処理システムの処理を示す図である。 情報処理システムの動作例を示すフローチャートである。 通常ボックス画面を示す図である。 リクエスト入力画面を示す図である。 配信者側ボックス画面を示す図である。 情報処理システムの動作例を示すフローチャートである。 リプライログデータの内容を示す図である。 視聴者側画面を示す図である。 配信者側画面を示す図である。 情報処理サーバの動作例を示すフローチャートである。 抽出動画データを生成する処理の説明に利用する図である。 情報処理システムの動作例を示すフローチャートである。 特別視聴画面および通常視聴画面を示す図である 通常ボックス画面および追加ポイント入力画面を示す図である。

以下、本発明の一実施形態を図面に基づいて説明する。図１は、本実施形態に係る情報処理システム１の構成例を示す図である。図１で示すように情報処理システム１は、端末２と、情報処理サーバ３（情報処理装置）とを含んで構成されている。図１では、無数に存在する端末２の一部を例示的に示している。端末２および情報処理サーバ３は共に、インターネット、電話網、その他の通信網を含むネットワークＮに接続可能である。端末２と情報処理サーバ３とはネットワークＮを介して通信可能である。

本実施形態に係る情報処理システム１は、ライブ配信を実現する機能を有する。本実施形態においてライブ配信とは、配信者（２人以上の人間が共同して配信者となる場合もある）と不特定の視聴者とが参加し、配信者の端末２で配信者の挙動が撮影されると共に、配信者の端末２の撮影結果に基づく動画がリアルタイムで視聴者の端末２に配信されることを意味する。情報処理サーバ３は、ライブ配信に係るサービスを提供することによって、ライブ配信に係るプラットフォームを提供する。以下、情報処理サーバ３が提供するライブ配信に係るサービスを「本件サービス」という。なお本実施形態では、動画とは、視覚で認識する画像（静止画画像、動画像）と、聴覚で認識する音声との組合せを意味する。以下の説明では、本件サービスを利用し得る者を「ユーザ」という。ユーザは、本件サービスにアカウントを登録しており、自身のログイン情報（例えばログインＩＤとパスワードの組合せ）を利用して本件サービスのアカウントにログインすることができる。

本実施形態ではユーザは、ライブ配信の配信者にも、視聴者にもなることができる。ただし以下では、説明の明確化および単純化のため、ユーザのうち配信者となり得るユーザの一人を「注目配信者」（注目ユーザ）と表現し、注目配信者に注目して配信者に関連する情報処理システム１の動作の説明を行う場合がある。注目配信者の端末２を配信者端末２Ｌとする。配信者端末２Ｌは、注目配信者の端末２を便宜的に示すものであり、配信者が専用的に使用する端末２を意味しない。また以下では、ユーザのうち視聴者となり得るユーザの一人を「注目視聴者」（ユーザ）と表現し、注目視聴者に注目して視聴者に関連する情報処理システム１の動作の説明を行う場合がある。注目視聴者の端末２を視聴者端末２Ａとする。視聴者端末２Ａは、注目視聴者の端末２を便宜的に示すものであり、視聴者が専用的に使用する端末２を意味しない。

端末２は、情報処理機能、収音機能、撮影機能、放音機能、表示機能、入力を受け付ける機能、通信機能、その他のユーザが利用する端末２として必要な機能を備えていればよい。ただし視聴者の端末２については、収音機能および撮影機能は必ずしも必要ない。また端末２は、単一の装置である必要はなく、複数の装置が組み合わされて構成されていてもよい。端末２のタイプは例えば、スマートフォン、スマートフォン以外のタブレット端末、ノートパソコン、または、カメラが接続されたデスクトップパソコンである。

情報処理サーバ３は、端末２をクライアントの１つとするサーバ装置である。上述したように情報処理サーバ３は、本件サービスを提供する。図１および後述する図２では、情報処理サーバ３を１つのブロックで表しているが、情報処理サーバ３は単一のサーバ装置である必要はない。例えば情報処理サーバ３は、複数のサーバ装置により構成されてもよく、また所定のシステムの一部であってもよい。

図２の（Ａ）は、端末２および情報処理サーバ３の機能構成例を示すブロック図である。図２の（Ａ）で示すように端末２は、端末制御装置５を備えている。端末制御装置５は機能構成として、端末制御部６と、端末通信部７とを備えている。また端末制御装置５は記憶手段として、端末記憶部８を備えている。また端末２において、端末制御部６には、収音機能を有するマイク９と、撮影機能を有するカメラ１０と、放音機能を有するスピーカ１１と、表示機能を有する表示装置１２と、入力を受け付ける機能を有する入力装置１３とが接続されている。図２の（Ａ）で示すように情報処理サーバ３は機能構成として、サーバ制御部１４と、サーバ通信部１５とを備えている。また情報処理サーバ３は記憶手段として、サーバ記憶部１６を備えている。

上記機能ブロック６、７、１４、１５は、ハードウェア、ＤＳＰ（Digital signal Processor）、ソフトウェアの何れによっても構成することが可能である。例えばソフトウェアによって構成する場合、上記機能ブロック６、７、１４、１５は、実際にはコンピュータのＣＰＵ、ＲＡＭ、ＲＯＭ等を備えて構成され、ＲＡＭやＲＯＭ、ハードディスクまたは半導体メモリ等の記録媒体に記憶されたプログラムが動作することによって実現される。

端末通信部７は、ネットワークＮに接続された機器と所定のプロトコルに従って通信する。以下の説明では端末２とネットワークＮに接続された機器との間での通信は、端末通信部７により適切に行われるものとして詳細な説明を省略する。サーバ通信部１５は、ネットワークＮに接続された機器と所定のプロトコルに従って通信する。以下の説明では情報処理サーバ３とネットワークＮに接続された機器との間での通信は、サーバ通信部１５により適切に行われるものとして詳細な説明を省略する。

図２の（Ａ）で示すように端末２には、本件サービスに関する専用のアプリケーション１７（以下「専用アプリ１７」という）がインストールされている。専用アプリ１７は、本件サービスに関する画面（以下「本件サービス画面」という）の提供、情報処理サーバ３との各種情報のやり取り、その他の本件サービスに関する処理を実行する機能が実装された専用のアプリケーションである。本件サービスに関連する処理について、端末制御部６は基本的には、専用アプリ１７（端末２のＯＳ、専用アプリ１７が利用可能なＷｅｂアプリ、その他の専用アプリ１７と連携可能な他のプログラムを含む）の機能を利用して処理を実行する。なお特に説明しない場合であっても、端末２の端末制御部６は、何らかの処理を実行する際、必要に応じて情報処理サーバ３のサーバ制御部１４と通信し、サーバ制御部１４から必要な情報の応答を要求して当該情報を取得し、或いはサーバ制御部１４に必要な処理を依頼して処理結果を取得する。情報処理サーバ３には端末制御部６に提供する情報が不足なく記憶されている。またサーバ制御部１４は、端末制御部６からの依頼に応じて処理を実行する機能が実装されている。

図２の（Ｂ）の（Ｂ１）は配信者端末２Ｌの機能構成例を示すブロック図である。図２の（Ｂ）の（Ｂ１）で示すように配信者端末２Ｌは、端末制御装置５Ｌ、マイク９Ｌ、カメラ１０Ｌ、スピーカ１１Ｌ、表示装置１２Ｌおよび入力装置１３Ｌを備えている。端末制御装置５Ｌは、端末制御部６Ｌ、端末通信部７Ｌおよび端末記憶部８Ｌを備えている。図２の（Ｂ）の（Ｂ２）は視聴者端末２Ａの機能構成例を示すブロック図である。図２の（Ｂ）の（Ｂ２）で示すように視聴者端末２Ａは、端末制御装置５Ａ、マイク９Ａ、カメラ１０Ａ、スピーカ１１Ａ、表示装置１２Ａおよび入力装置１３Ａを備えている。端末制御装置５Ａは、端末制御部６Ａ、端末通信部７Ａおよび端末記憶部８Ａを備えている。

次に情報処理システム１の動作についてシーンに分けて説明する。以下では説明の便宜のため、配信者端末２Ｌおよび視聴者端末２Ａのタイプは、スマートフォンであるものとする。スマートフォンは、タブレット型の筐体を備え、当該筐体の前面の広い領域に表示パネルおよびタッチパネルが設けられ、当該筐体内に内蔵マイク、内蔵カメラおよび内蔵スピーカが設けられる。スマートフォンの内臓マイクがマイク９Ｌ、９Ａとして機能し、内蔵カメラがカメラ１０Ｌ、１０Ａとして機能し、内蔵スピーカがスピーカ１１Ｌ、１１Ａとして機能し、表示パネルが表示装置１２Ｌ、１２Ａとして機能し、タッチパネルが入力装置１３Ｌ、１３Ａとして機能する。

＜ライブ配信時の基本的な動作＞
まず注目配信者がライブ配信を行い、注目視聴者がそれを視聴するときの情報処理システム１の基本的な動作について説明する。以下では、まずライブ配信中に配信者端末２Ｌおよび視聴者端末２Ａに表示される画面について説明した後、情報処理システム１の動作について説明する。

図３は、ライブ配信中に配信者端末２Ｌに表示される配信者側画面２０を示す図である。図３で示すように配信者側画面２０には、カメラ１０Ｌの撮影結果に基づく動画像である撮影動画像２１が背景として表示される。配信者側画面２０の中央に対してやや左下の領域には、コメント一覧領域２２が設けられている。後述するようにコメント一覧領域２２には、視聴者が投稿したコメントに対応するコメント個別画像２３がリアルタイムで表示される。コメント一覧領域２２の下方にはリプライ開始ボタン２４が設けられており、リプライ開始ボタン２４の右方にはリクエストボックス確認ボタン２５が設けられている。リプライ開始ボタン２４およびリクエストボックス確認ボタン２５に関連する事項については後述する。また配信者側画面２０の左上部には、配信者プロフィール画像２６が表示される。配信者プロフィール画像２６には、配信者のアイコン画像と配信者のユーザ名とが表示される。配信者プロフィール画像２６の右方には、終了ボタン２７が設けられている。終了ボタン２７は配信者がライブ配信を終了するときに選択されるボタンである。

図４は、ライブ配信中に視聴者端末２Ａに表示される視聴者側画面２９を示す図である。図４で示すように視聴者側画面２９には、配信者側画面２０と同様、背景として撮影動画像２１が表示され、撮影動画像２１上にコメント一覧領域２２、配信者プロフィール画像２６および終了ボタン３０が設けられる。終了ボタン３０は、ライブ配信の視聴を終了するときに選択されるボタンである。一方、視聴者側画面２９には、リプライ開始ボタン２４およびリクエストボックス確認ボタン２５が設けられておらず、代わりにコメント入力欄３１、コメント送信ボタン３２およびリクエスト関連ボタン３３が設けられている。コメント入力欄３１、コメント送信ボタン３２およびリクエスト関連ボタン３３に関連する事項については後述する。なお例示した配信者側画面２０および視聴者側画面２９は単純化したものである。配信者側画面２０および視聴者側画面２９の内容が例示する内容に限定されないことは当然である。

図５は、ライブ配信中の配信者端末２Ｌ、情報処理サーバ３および視聴者端末２Ａによる情報処理方法を示すフローチャートである。フローチャートＦＡは配信者端末２Ｌによる情報処理方法を示し、フローチャートＦＢは情報処理サーバ３による情報処理方法を示し、フローチャートＦＣは視聴者端末２Ａによる情報処理方法を示す。

ライブ配信に際して、注目配信者は、配信者端末２Ｌの専用アプリ１７を起動する。注目配信者は、端末制御部６Ｌが表示装置１２Ｌに表示する本件サービス画面を利用して、本件サービスのアカウントにログインする。ログインがセキュアに自動で行われる構成でもよい。注目配信者は、必要な作業を行って自身が配信者としてライブ配信する準備を整える。フローチャートＦＡで示すように注目配信者は、本件サービス画面を利用してライブ配信の開始を指示する（ステップＳＡ１）。端末制御部６Ｌは、この指示を検出し、サーバ制御部１４に、ライブ配信の開始を通知する（ステップＳＡ２）。以下、ここで開始されたライブ配信を「注目ライブ配信」といい、ライブ配信一般と区別する。

フローチャートＦＢで示すように情報処理サーバ３のサーバ制御部１４は、注目ライブ配信の開始の通知を受信すると、注目ライブ配信が開始されたタイミングを起点とした経過時間の計測を開始する（ステップＳＢ１）。更にサーバ制御部１４は、サーバ記憶部１６に記憶されたライブ配信管理データベース３５に、注目ライブ配信に対応するレコードを追加し、注目ライブ配信の管理を開始する（ステップＳＢ２）。ライブ配信管理データベース３５は、ライブ配信のそれぞれを管理するデータベースであり、ライブ配信ごとにレコードが登録される。図６（Ａ）は、ライブ配信管理データベース３５の１件のレコードの内容を示している。図６（Ａ）で示すように、ライブ配信管理データベース３５の１件のレコードは、フィールドとしてライブ配信ＩＤ＜フィールド＞と、配信者ＩＤ＜フィールド＞と、視聴者ＩＤ＜フィールド＞と、リプライログ＜フィールド＞と、ライブ配信全体動画＜フィールド＞とを含んでいる。

ライブ配信ＩＤ＜フィールド＞には、対応するライブ配信を一意に識別するための識別情報であるライブ配信ＩＤが格納される。配信者ＩＤ＜フィールド＞には、対応するライブ配信の配信者のユーザＩＤが格納される。ユーザＩＤとは、本件サービスのユーザ（アカウント）を一意に識別するための識別情報である。視聴者ＩＤ＜フィールド＞には、対応するライブ配信の視聴者のユーザＩＤが格納される。視聴者が複数いる場合には、複数のそれぞれの視聴者のユーザＩＤが格納される。リプライログ＜フィールド＞には、リプライログデータ３４が記録される。リプライログデータ３４に関する事項ついては後述する。ライブ配信全体動画＜フィールド＞には、対応するライブ配信が完了した後に、ライブ配信全体動画データが格納される。ライブ配信全体動画データは、対応するライブ配信の全体（＝ライブ配信の開始から終了まで）の動画が記録された動画データ（動画ファイル）である。ライブ配信全体動画データに関する事項については後述する。

ステップＳＢ２においてサーバ制御部１４は、一意な値のライブ配信ＩＤを生成し、追加するレコードのライブ配信ＩＤ＜フィールド＞に格納する。またサーバ制御部１４は、配信者ＩＤ＜フィールド＞に注目配信者のユーザＩＤを格納し、視聴者ＩＤ＜フィールド＞にヌル値を格納し、リプライログ＜フィールド＞に初期値のリプライログデータ３４を格納し、ライブ配信全体動画＜フィールド＞にヌル値を格納する。

一方、注目視聴者は、視聴者端末２Ａの専用アプリ１７を起動する。注目視聴者は、端末制御部６Ａが提供する本件サービス画面を利用して、本件サービスのアカウントにログインする。ログインがセキュアに自動で行われる構成でもよい。フローチャートＦＣで示すように注目視聴者は、本件サービス画面を利用して注目ライブ配信の視聴の開始を指示する（ステップＳＣ１）。視聴者端末２Ａの端末制御部６Ａは、この指示を検出し、サーバ制御部１４に、注目ライブ配信の視聴の開始を通知する（ステップＳＣ２）。

フローチャートＦＢで示すようにサーバ制御部１４は、注目ライブ配信の視聴の開始の通知を受信すると、ライブ配信管理データベース３５の注目ライブ配信に対応するレコードの視聴者ＩＤ＜フィールド＞に、注目視聴者のユーザＩＤを追加的に格納する（ステップＳＢ３）。なお注目ライブ配信に係る視聴者ＩＤ＜フィールド＞は、現時点の注目ライブ配信の視聴者を管理するフィールドである。つまり、ある視聴者が注目ライブ配信の視聴を開始すると、その視聴者のユーザＩＤが視聴者ＩＤ＜フィールド＞に格納される。詳細は省略するが、サーバ制御部１４は、ある視聴者が注目ライブ配信の視聴を停止した場合、そのことを検出し、視聴者ＩＤ＜フィールド＞からその視聴者のユーザＩＤを削除する。

なお視聴者によるライブ配信の視聴の開始の指示は、様々な方法で行われ得る。例えば本件サービスでは、一のユーザが別のユーザをフォローすることが可能である。そして当該別のユーザがライブ配信を開始すると、当該一のユーザに対して提供される所定の本件サービス画面に、当該別のユーザがライブ配信を開始したことを明示するボタンが表示される。当該一のユーザ（視聴者）は、このボタンを選択することによって、当該他のユーザ（配信者）によるライブ配信の視聴の開始を指示することができる。また例えば本件サービスでは、視聴者は、実施中のライブ配信の一覧が表示された本件サービス画面を表示装置１２に表示させることができる。そして視聴者は、一覧の中から１つのライブ配信を選択することによって、ライブ配信の視聴の開始を指示することができる。また例えば本件サービスでは、視聴者は、一のライブ配信を視聴中に、画面に対するスクロール操作、その他の所定の操作をすることによって、視聴するライブ配信を当該一のライブ配信から、実施中の他のライブ配信に切り替えることができる。当該他のライブ配信はランダムに決定される構成でもよく、何らかのルールに基づいて決定される構成でもよい。ユーザは、視聴するライブ配信を当該他のライブ配信に切り替える操作を行うことによって、当該他のライブ配信の視聴の開始を指示することができる。以上、視聴者がライブ配信の視聴の開始を指示する方法について複数の例を挙げたが、当該方法が当該複数の例に限られないことは勿論である。

ライブ配信中は、配信者端末２Ｌ、情報処理サーバ３および視聴者端末２Ａにより以下の処理が行われてライブ配信が実現される。図７は、ライブ配信中の情報処理システム１の動作を、各装置の処理に注目して説明に適した態様で示す図である。図７で示すようにライブ配信中は、配信者端末２Ｌのカメラ１０Ｌによる撮影およびマイク９Ｌによる収音が継続して行われる。配信者端末２Ｌの端末制御部６Ｌは、撮影結果に基づく信号をカメラ１０Ｌから入力し、画像データＤ１を生成すると共に、収音結果に基づく信号をマイク９Ｌから入力し、音声データＤ２を生成する（プロセスＰＡ１）。端末制御部６Ｌは、顔加工、フィルタを利用した加工、デコレーション加工、その他の加工を動画像に施すための画像処理を画像データＤ１に施してライブ配信動画像データＤ３を生成する（プロセスＰＡ２）。なお詳細は省略するが、動画像に対してどのような加工を施すかについては事前に注目配信者により指定される。また端末制御部６Ｌは、音声データＤ２に対して必要な音声処理を施してライブ配信音声データＤ４を生成する（プロセスＰＡ２）。

端末制御部６Ｌは、ライブ配信動画像データＤ３およびライブ配信音声データＤ４についてプロトコルに従ってエンコード、圧縮、コンテナへの格納、その他の必要な処理を施してライブ配信データＤ５を生成し、プロトコルに従ってライブ配信データＤ５を情報処理サーバ３に送信する（プロセスＰＡ３）。なお利用されるプロトコルは例えば、「HTTP Live Streaming」または「Real Time Messaging Protocol」である（当然、これら以外のプロトコルであってもよい）。

また端末制御部６Ｌは、ライブ配信動画像データＤ３に対して付加画像を付加する処理を施して配信者側画面データＤ６を生成する（プロセスＰＡ４）。付加画像は、配信者側画面２０において撮影動画像２１に付加される画像である。図３で示すように付加画像は、コメント個別画像２３、リプライ開始ボタン２４、リクエストボックス確認ボタン２５、配信者プロフィール画像２６および終了ボタン２７を含む。端末制御部６Ｌは、生成した配信者側画面データＤ６に基づいて表示装置１２Ｌを駆動し、表示装置１２Ｌに配信者側画面２０を表示する（プロセスＰＡ５）。また端末制御部６Ｌは、ライブ配信音声データＤ４に基づいてスピーカ１１Ｌを駆動し音声を放音する（プロセスＰＡ５）。配信者側画面２０の表示中の撮影動画像２１と音声との同期は、端末制御部６Ｌにより適切に行われる。

ライブ配信中、情報処理サーバ３のサーバ制御部１４は、配信者端末２Ｌからライブ配信データＤ５を継続して受信する（プロセスＰＢ１）。サーバ制御部１４は、必要に応じてライブ配信管理データベース３５およびユーザ管理データベース３６を参照した上で、ライブ配信データＤ５をプロトコルに従って視聴者端末２Ａに送信する（プロセスＰＢ２）。

ユーザ管理データベース３６とは、ユーザ（アカウント）を管理するためのデータベースであり、ユーザごとにレコードが登録されている。図６（Ｂ）は、ユーザ管理データベース３６の１件のレコードの内容を示している。図６（Ｂ）で示すように、ユーザ管理データベース３６の１件のレコードは、フィールドとしてユーザＩＤ＜フィールド＞と、ユーザ名＜フィールド＞と、アイコン＜フィールド＞と、ポイント残高＜フィールド＞と、獲得ポイント合計＜フィールド＞を含んでいる。ユーザＩＤ＜フィールド＞には、対応するユーザのユーザＩＤが格納される。ユーザ名＜フィールド＞には、対応するユーザのユーザ名を示すユーザ名情報が格納される。アイコン＜フィールド＞には、対応するユーザのアイコンの画像データであるアイコン画像データが格納される。ポイント残高＜フィールド＞には、対応するユーザの本件ポイント（ポイント）の残高を示す値（以下「ポイント残高値」という）が格納される。本件ポイントとは、本件サービスにおいて使用可能なポイントである。本件ポイントの単位は「ｐｔ」とする。ユーザは、購入、キャンペーンによる付与、その他の手段によって本件ポイントを取得することができる。獲得ポイント合計＜フィールド＞には獲得ポイント値を合計した獲得ポイント合計値が格納される。獲得ポイント値に関連する事項については後述する。なおユーザ管理データベース３６のレコードの内容は単純化したものである。レコードには、ユーザの連絡先に関する情報（メールアドレス等）、ログイン情報、決済手段に関する情報、その他のユーザに関する各種情報が含まれている。

更にサーバ制御部１４は、受信したライブ配信データＤ５について、プロトコルに従ってコンテナからの取り出し、解凍、デコード、その他の必要な処理を施してライブ配信動画像データＤ３およびライブ配信音声データＤ４を生成する（プロセスＰＢ３）。サーバ制御部１４は、生成したライブ配信動画像データＤ３およびライブ配信音声データＤ４を、累積的にサーバ記憶部１６にバッファリングする（プロセスＰＢ４）。

ライブ配信中、視聴者端末２Ａの端末制御部６Ａは、ライブ配信データＤ５を継続して受信する（プロセスＰＣ１）。端末制御部６Ａは、ライブ配信データＤ５について、プロトコルに従ってコンテナからの取り出し、解凍、デコード、その他の必要な処理を施してライブ配信動画像データＤ３およびライブ配信音声データＤ４を生成する（プロセスＰＣ２）。端末制御部６Ａは、付加画像を付加する処理をライブ配信動画像データＤ３に施して視聴者側画面データＤ７を生成する（プロセスＰＣ３）。付加画像は、視聴者側画面２９において撮影動画像２１に付加される画像である。図４で示すように付加画像は、コメント個別画像２３、コメント入力欄３１、コメント送信ボタン３２、リクエスト関連ボタン３３、配信者プロフィール画像２６および終了ボタン３０を含む。そして端末制御部６Ａは、生成した視聴者側画面データＤ７に基づいて表示装置１２Ａを駆動し、表示装置１２Ａに視聴者側画面２９を表示する（プロセスＰＣ４）。また端末制御部６Ａは、ライブ配信音声データＤ４に基づいてスピーカ１１Ａを駆動し音声を放音する（プロセスＰＣ４）。視聴者側画面２９Ａの表示中の撮影動画像２１と音声との同期は、端末制御部６Ａにより適切に行われる。

以上、ライブ配信を実現する情報処理システム１の動作例を説明したが、情報処理システム１の動作は例示した動作に限られるものではない。すなわちライブ配信が実現されれば情報処理システム１によりどのような動作が行われてもよい。また情報処理システム１の動作にはライブ配信の実現に関する既存の技術を全て利用できる。以下の説明では、ライブ配信中は、図７を用いて説明した方法により適切にライブ配信が実現されているものとし、ライブ配信を実現するための処理については詳細な説明を省略する。

さて図５に戻り、フローチャートＦＡで示すように注目配信者は、ライブ配信を終了する場合、配信者側画面２０の終了ボタン２７を選択する（ステップＳＡ３）。終了ボタン２７が選択されたことを検出すると端末制御部６Ｌは、ライブ配信の終了を情報処理サーバ３に通知する（ステップＳＡ４）。

フローチャートＦＢで示すようにサーバ制御部１４は、ライブ配信の終了の通知を受信すると、経過時間の計測を終了する（ステップＳＢ４）。次いでサーバ制御部１４は、サーバ記憶部１６にバッファリングしたライブ配信動画像データＤ３およびライブ配信音声データＤ４に基づいて、所定のファイル形式のライブ配信全体動画データを生成する（ステップＳＢ５）。ライブ配信全体動画データは、注目ライブ配信の全体（開始から終了まで）の動画が記録された動画データ（動画ファイル）である。次いでサーバ制御部１４は、生成したライブ配信全体動画データを、ライブ配信管理データベース３５の注目ライブ配信に対応するレコードのライブ配信全体動画＜フィールド＞に格納する（ステップＳＢ６）。

以上がライブ配信中の情報処理システム１の基本的な動作である。ただし、説明した情報処理システム１の動作はあくまで単純化した一例であり、目的が達成されるのであれば、情報処理システム１の各装置において異なる処理が行われてもよい。例えば、ライブ配信全体動画データが以下の方法で生成される構成でもよい。すなわち、情報処理サーバ３とは異なる専用の装置によってライブ配信に関するデータを受信し、当該専用の装置によってライブ配信全体動画データが生成される構成でもよい。

＜注目視聴者によりコメントが投稿される場合の処理＞
次にライブ配信中に注目視聴者によりコメントが投稿されるときの情報処理システム１の動作について簡単に説明する。なお本実施形態において、コメントは、後述するリクエストとは異なる概念であり、これらは明確に区別される。

コメントを投稿する場合、注目視聴者は、視聴者側画面２９（図４）のコメント入力欄３１にコメントを入力し、コメント送信ボタン３２を選択する。なおコメントおよび後述するリクエストは、文字（使用可能なオブジェクトを全て含む概念であり、例えば絵文字を含む）によって構成される。視聴者端末２Ａの端末制御部６Ａは、コメント送信ボタン３２が選択されたことを検出すると、入力されたコメントに関する情報および注目視聴者に関する情報を情報処理サーバ３に送信する。

情報処理サーバ３のサーバ制御部１４は、情報を受信し、注目ライブ配信に対応するコメント管理データベース３７に、コメントおよび注目視聴者に関する各種情報を含むレコードを追加する。なおコメント管理データベース３７は、ライブ配信中に投稿されたコメントを管理するデータベースであり、ライブ配信ごとに存在する。次いでサーバ制御部１４は、ユーザ管理データベース３６、その他のデータを参照し、コメント個別画像２３（図３、４参照）の表示に必要な情報を含むコメント表示情報を生成する。次いでサーバ制御部１４は、配信者端末２Ｌおよび視聴者端末２Ａにコメント表示情報を送信する。なおコメント表示情報は、配信者端末２Ｌおよび視聴者端末２Ａだけでなく、注目ライブ配信を視聴中の全ての視聴者の端末２に送信される。

配信者端末２Ｌの端末制御部６Ｌは、コメント表示情報を受信すると、配信者側画面２０のコメント一覧領域２２に、ルールに従った態様でコメント個別画像２３を追加的に表示する。図３で示すようにコメント個別画像２３には、注目視聴者（本例においてコメントを投稿した視聴者）のユーザ名およびアイコン画像と、コメントの内容とが含まれる。なおルールは、コメント一覧領域２２内で既存のコメント個別画像２３を上方にずらし、コメント一覧領域２２内に入りきらなくなった既存のコメント個別画像２３については削除した上で、コメント一覧領域２２の末尾に新たなコメント個別画像２３を表示する、というルールである。ただしコメント一覧領域２２に入りきらなくなったコメント個別画像２３について、一定量だけ、コメント一覧領域２２に対するスクロール操作によって視聴可能な状態とするようにしてもよい。同様に視聴者端末２Ａの端末制御部６Ａは、コメント表示情報を受信すると、視聴者側画面２９のコメント一覧領域２２に、ルールに従った態様でコメント個別画像２３を追加的に表示する。

このように本実施形態では、視聴者によるコメントの投稿に応じて、リアルタイムで配信者および視聴者の端末２に表示される。

＜注目視聴者によりリクエストが投稿される場合の処理＞
次にライブ配信中に注目視聴者によりリクエストが投稿されるときの情報処理システム１の動作について説明する。図８は、注目視聴者によりリクエストが投稿される場合における情報処理サーバ３および視聴者端末２Ａによる情報処理方法を示すフローチャートである。フローチャートＦＤは情報処理サーバ３による情報処理方法を示し、フローチャートＦＥは視聴者端末２Ａによる情報処理方法を示す。

リクエストとは、配信者によるリプライを期待して行われる要求である。例えばリクエストは、配信者に対する質問であり、また例えば配信者に何らかのアクションを行うことを要望するものである。リプライとは、ユーザからのリクエストに対して配信者が行う応答全般を意味する。例えばリプライは、リクエストに係る質問に対して回答する一連の行為であり、また例えばリクエストに係る要望に対応して行うアクションである。後に明らかとなる通りリクエストは、投稿に応じてリアルタイムで配信者側画面２０に表示されることはなく、この点でコメントと異なっている。また後に明らかとなる通り所定の場合には、１つのリクエストに対して配信者が独占的にリプライすることになる。

フローチャートＦＥで示すようにリクエストを投稿する場合、注目視聴者は、視聴者側画面２９のリクエスト関連ボタン３３を選択する（ステップＳＥ１）。リクエスト関連ボタン３３が選択されると、視聴者端末２Ａの端末制御部６Ａは、情報処理サーバ３のサーバ制御部１４と協働して、表示装置１２Ａに通常ボックス画面３８（図９）をポップアップ表示する（ステップＳＥ２）。以下、ステップＳＥ２の処理について詳述する。

ステップＳＥ２において端末制御部６Ａは、リクエスト関連ボタン３３が選択されたことをサーバ制御部１４に通知する。サーバ制御部１４は、当該通知を受信すると、注目配信者に対応するリクエスト管理データベース４０を参照する。ここで本件サービスでは、各ユーザは、自身以外のユーザに対してリクエストを投稿することができる。そしてリクエスト管理データベース４０は、ユーザごとに存在し、各ユーザに対して投稿されたリクエストを管理する。つま、あるユーザに対応するリクエスト管理データベース４０は、そのユーザに対して投稿されたリクエストを管理する。また、あるユーザに対応するリクエスト管理データベース４０には、そのユーザに対して投稿されたリクエストごとにレコードが登録される。

図６（Ｃ）は、リクエスト管理データベース４０の１件のレコードの内容を示している。図６（Ｃ）で示すようにリクエスト管理データベース４０の１件のレコードはフィールドとして、リクエストＩＤ＜フィールド＞と、投稿者ＩＤ＜フィールド＞と、リクエスト投稿日時＜フィールド＞と、リクエスト内容＜フィールド＞と、付与ポイント＜フィールド＞と、リプライ済フラグ＜フィールド＞と、肯定評価数＜フィールド＞と、肯定評価付与者＜フィールド＞と、リプライ優先順位＜フィールド＞とを含んでいる。

リクエストＩＤ＜フィールド＞には、対応するリクエストを一意に識別するための識別情報であるリクエストＩＤが格納される。投稿者ＩＤ＜フィールド＞には、対応するリクエストを投稿したユーザのユーザＩＤが格納される。以下、リクエストを投稿したユーザを「リクエスト投稿者」という場合がある。リクエスト投稿日時＜フィールド＞には、リクエストが投稿された日時を示すリクエスト投稿日時情報が格納される。リクエスト内容＜フィールド＞には、リクエストの内容を示すリクエスト内容情報が格納される。付与ポイント情報＜フィールド＞には、対応するリクエストに付与された本件ポイントの値を示す付与ポイント値が格納される。付与ポイント値に関する事項については後述する。リプライ済フラグ＜フィールド＞には、対応するリクエストについて、リクエストを受けたユーザがリプライを行ったか否かを示すフラグであるリプライ済フラグが格納される。リプライ済フラグはオン値のときにリプライが既に行われたことを示し、オフ値のときにリプライが未だ行われていないことを示す。肯定評価数＜フィールド＞は、対応するリクエストに付与された肯定評価の個数（累積数）を示す値（以下「肯定評価数」という）が格納される。肯定評価に関する事項については後述する。肯定評価付与者＜フィールド＞には、対応するリクエストについて、肯定評価を付与したユーザ（以下「肯定評価付与者」という）のそれぞれのユーザＩＤが格納される。リプライ優先順位＜フィールド＞には、対応するリクエストのリプライ優先順位を示すリプライ優先順位情報が格納される。

以下、リプライ優先順位に関する事項について説明する。サーバ制御部１４は、適宜、リクエスト管理データベース４０の各レコードのリプライ優先順位情報を以下の方法で更新する。なお本実施形態ではリプライ優先順位は、最上位から順番に、１番、２番、３番・・・というように表現されるものとする。すなわちサーバ制御部１４は、リクエスト管理データベース４０に登録されているレコードのうち、リプライ済フラグがオフ値のレコード（＝リクエストを受けたユーザによるリプライが未だ行われていないリクエストに対応するレコード）を特定する。以下、リプライが行われていないリクエスト（＝リプライ済フラグがオフ値のレコードに対応するリクエスト）を「未応答リクエスト」という。次いでサーバ制御部１４は、未応答リクエストの全てを対象として、付与ポイント値が高いほどリプライ優先順位が高くなり、また付与ポイント値が同じであれば肯定評価数が多いほどリプライ優先順位が高くなり、また付与ポイント値が同じでありかつ肯定評価数が同じであればリクエスト投稿日時が時間的に古いほどリプライ優先順位が高くなるように、リプライ優先順位を設定する。

例えば未応答リクエストＲ１の付与ポイント値が「３，０００ｐｔ」であり、未応答リクエストＲ２の付与ポイント値が「５，０００ｐｔ」であったとする。この場合、サーバ制御部１４は、未応答リクエストＲ２のリプライ優先順位を未応答リクエストＲ１のリプライ優先順位よりも高くする。また例えば、未応答リクエストＲ３と未応答リクエストＲ４との付与ポイントが同じである一方、未応答リクエストＲ３の肯定評価数が、未応答リクエストＲ４の肯定評価数よりも多いとする。この場合、サーバ制御部１４は、未応答リクエストＲ３のリプライ優先順位を未応答リクエストＲ４のリプライ優先順位よりも高くする。サーバ制御部１４は、未応答リクエストを対象として行った優先順位付けに従って、未応答リクエストのそれぞれに対応するレコードのそれぞれについて、リプライ優先順位＜フィールド＞に格納されたリプライ優先順位情報を更新する。サーバ制御部１４は、リプライ済フラグがオン値のレコード（＝リクエストを受けたユーザによるリプライが既に行われたリクエストに対応するレコード）のリプライ優先順位情報についてはヌル値とする。

なおサーバ制御部１４は、リクエスト管理データベース４０の各レコードのリプライ優先順位情報の更新を、リプライ優先順位に変更が生じ得る要因が発生したタイミングで実行する。リプライ優先順位に変更が生じ得る要因が発生したタイミングは例えば、レコードが追加されるタイミング、レコードが削除されるタイミングまたは何れかのレコードについてリプライ済フラグがオフ値からオン値になったタイミングである。

以上の通りサーバ制御部１４（制御部）は、付与ポイント値（付与されたポイント値）が大きいほどリプライ優先順位（優先順位）が高くなるように、未応答リクエストについてリプライ優先順位を設定する機能を備える。またサーバ制御部１４は、付与ポイント値が大きいほど、かつ付与ポイント値が同じであれば付与された肯定評価の個数が多いほどリプライ優先順位が高くなるように、未応答リクエストについてリプライ優先順位を設定する機能を備える。

さてサーバ制御部１４は、注目配信者に対応するリクエスト管理データベース４０を参照し、未応答リクエストのそれぞれについて、表示用リクエスト情報を生成する。一の未応答リクエストに対応する表示用リクエスト情報は、当該一の未応答リクエストの投稿者のユーザ名およびアイコン画像データ、リクエスト内容情報、付与ポイント値、肯定評価数、その他のリクエストカード４４（後述）の表示のために必要な情報を含む。サーバ制御部１４は、未応答リクエストのそれぞれについて、リクエスト管理データベース４０およびユーザ管理データベースに基づいて、これら情報を取得し、表示用リクエスト情報を生成する。次いでサーバ制御部１４は、未応答リクエストのそれぞれの表示用リクエスト情報を、端末制御部６Ａに送信する。端末制御部６Ａは、受信した表示用リクエスト情報を利用して、通常ボックス画面３８をポップアップ表示する。

図９は、通常ボックス画面３８の一例を示す図である。図９で示すように通常ボックス画面３８の上部には、現時点の未応答リクエストの個数を示す未応答リクエスト個数画像４１が表示される。端末制御部６Ａは、サーバ制御部１４から受信した情報に基づいて未応答リクエストの個数をカウントし、未応答リクエスト個数画像４１を表示する。通常ボックス画面３８において未応答リクエスト個数画像４１の下方には、リクエストカード一覧領域４２Ａが設けられ、リクエストカード一覧領域４２Ａの下方にはリクエスト作成ボタン４３が設けられる。リクエストカード一覧領域４２Ａには、未応答リクエストごとに、リクエストカード４４（リクエストに関する情報）が表示される。つまり通常ボックス画面３８の１つのリクエストカード４４は、１つの未応答リクエストに対応する。リクエストカード４４は、対応するリクエスト投稿者のユーザ名を示す画像と、当該リクエスト投稿者のアイコンを示す画像とを含む。またリクエストカード４４は、対応するリクエストの内容を示すリクエスト内容画像４５と、対応するリクエストに付与された付与ポイント値を示す付与ポイント画像４６とを含む。またリクエストカード４４は、肯定評価オブジェクト４７を含む。

肯定評価オブジェクト４７は、肯定評価数を示す情報を含む。上述の通り肯定評価数は、対応する未応答リクエストに対して行われた肯定評価の個数である。また肯定評価オブジェクト４７は、ユーザ（本例では注目視聴者）が、肯定評価を付与しているか否かを示すマーク４８を含む。当該マークは、ハート形であり、ユーザが肯定評価を付与している場合には所定の色で塗り潰され、付与していない場合には白抜きされた状態となる。端末制御部６Ａは、リクエストカード４４のそれぞれについて、ユーザが肯定評価を付与しているか否かをサーバ制御部１４に問い合わせ、問い合わせに対する応答に基づいて、マーク４８の塗り潰し／白抜きを制御する。

また肯定評価オブジェクト４７は、リクエストに対して肯定評価を付与するボタン、および肯定評価が付与されているときにそれを取り消すボタンとしても機能する。注目視聴者は、あるリクエストカード４４に肯定評価を付与していないときに肯定評価オブジェクト４７を選択することによって、そのリクエストカード４４に対応するリクエストに肯定評価を付与することができる。注目視聴者により肯定評価オブジェクト４７が選択されるとサーバ制御部１４は、端末制御部６Ａと協働して、注目配信者に対応するリクエスト管理データベース４０の対応するレコードの肯定評価数をインクリメントする。更にサーバ制御部１４は、対応するレコードの肯定評価付与者＜フィールド＞に注目配信者のユーザＩＤを追加する。また注目視聴者は、あるリクエストカード４４に肯定評価を付与しているときに肯定評価オブジェクト４７を選択することによって、そのリクエストカード４４に対応するリクエストに付与した肯定評価を取り消すことができる。注目視聴者によって肯定評価オブジェクト４７が選択されるとサーバ制御部１４は、端末制御部６Ａと協働して、対応するレコードの肯定評価数をデクリメントする。更にサーバ制御部１４は、対応するレコードの肯定評価付与者＜フィールド＞から注目配信者のユーザＩＤを削除する。

このようにサーバ制御部１４は、ユーザがリクエストに対して肯定評価を付与したときに、そのことを検出すると共に、リクエスト管理データベース４０への反映、その他の肯定評価の付与を反映するための処理を実行する機能を備える。当該機能は、リクエストに対する肯定評価の付与を受け付ける機能に相当する。

端末制御部６Ａは、リクエストカード４４を、対応する表示用リクエスト情報に基づいて表示する。また端末制御部６Ａは、リクエストカード４４のリクエストの内容および付与ポイント値が表示されるブロックについて、背景の色を以下の通り変化させる。すなわち端末制御部６Ａは、付与ポイント値が２０００ｐｔ未満のときは背景の色を「白色」とし、付与ポイント値が２０００ｐｔ以上５０００ｐｔ未満のときは背景の色を「黄色」とし、付与ポイント値が５０００ｐｔ以上のときは背景の色を「赤色」とする。リクエストカード一覧領域４２Ａは、スクロール可能に構成されている。視聴者は、リクエストカード一覧領域４２Ａをスクロールすることによって、全てのリクエストカード４４を表示させることが可能である。端末制御部６Ａは、リクエストカード一覧領域４２Ａ内で、リクエストカード４４をリプライ優先順位に従って、上から順番に並べて配置する。端末制御部６Ａは、リクエストカード４４のそれぞれのリプライ優先順位について、サーバ制御部１４に問い合わせることによって認識する。このようにリプライ優先順位が高いリクエストカード４４ほど、リクエストカード一覧領域４２Ａにおいて上方に表示される。注目視聴者は、リクエストカード一覧領域４２Ａを参照することにより、未対応リクエストのそれぞれについて、リクエストの内容、リクエスト投稿者に関する事項、付与ポイント値、肯定評価に関する事項を認識することができる。

後に明らかとなるようにリプライ優先順位が高いリクエストほど、つまりリクエストカード一覧領域４２Ａ内で上方に表示されたリクエストカード４４のリクエストほど、より早い段階でリクエストを受けたユーザによるリプライの対象となる。そして付与ポイント値が高いほどリプライ優先順位が高くなり、付与ポイント値が同じであれば、肯定評価数が多いほどリプライ優先順位が高くなる。これを踏まえ注目視聴者は、リクエストカード４４のうち、より早い段階で配信者にリプライして欲しいと考えるものについて肯定評価を付与するインセンティブを持つ。

以上の通り端末制御部６Ａは、リクエストカード４４（リクエストに関する情報）がリプライ優先順位（優先順位）に従って並んで配置された通常ボックス画面３８（画面）を提供する機能を備える。また端末制御部６Ａは、リクエストカード４４が一覧表示されると共に、リクエストカード４４と関連付けて肯定評価オブジェクト４７（肯定評価を付与するためのオブジェクト）が表示された通常ボックス画面３８（画面）を提供する機能を備える。

さてフローチャートＦＥで示すようにリクエストを投稿しようと考える注目視聴者は、通常ボックス画面３８を参照した上で、リクエスト作成ボタン４３を選択する（ステップＳＥ３）。リクエスト作成ボタン４３が選択されたことを検出すると端末制御部６Ａはサーバ制御部１４と協働し、通常ボックス画面３８に代えて、リクエスト入力画面５０（図１０）を表示装置１２Ａにポップアップ表示する（ステップＳＥ４）。図１０は、リクエスト入力画面５０の一例を示す図である。図１０で示すように、リクエスト入力画面５０の上部には、リクエスト入力欄５１が設けられている。リクエスト入力欄５１は、文字によって構成されるリクエストが入力される欄である。端末制御部６Ａは、リクエスト入力欄５１が選択されると、ソフトウェアキーボードを表示する。注目視聴者は、ソフトウェアキーボードを利用して、リクエスト入力欄５１にリクエストを入力できる。なおリクエスト入力欄５１に限らず、入力欄への入力時には、端末制御部６によりソフトウェアキーボードが表示される。

リクエスト入力画面５０においてリクエスト入力欄５１の下方には、ポイント残高画像５２が表示される。端末制御部６Ａは、サーバ制御部１４に注目視聴者のポイント残高値を問い合わせ、問い合わせに対する応答に基づいてポイント残高画像５２を表示する。ポイント残高画像５２の右方には、ポイント取得ボタン５３が設けられる。ポイント取得ボタン５３は、指定した量だけ本件ポイントを取得することによってポイント残高値を増やす場合に選択されるボタンである。ポイント取得ボタン５３が選択されると端末制御部６Ａは、サーバ制御部１４と協働して、本件ポイントを取得するための画面を表示する。本件ポイントの取得は、購入、その他の手段によって行うことができる。注目視聴者は、当該画面を利用して、指定した量だけ本件ポイントを取得する。サーバ制御部１４は、ユーザによる本件ポイントの取得に応じて、ユーザ管理データベース３６の対応するレコードのポイント残高値を適切に増やす。なお本件ポイントが購入によって取得される場合、決済等は適切に実行される。

リクエスト入力画面５０においてポイント残高画像５２の下方には、付与ポイント入力欄５４が設けられ、付与ポイント入力欄５４の下方には付与ポイントスライダ５５が設けられ、付与ポイントスライダ５５の下方には最高ポイント付与ボタン５６が設けられている。付与ポイント入力欄５４、付与ポイントスライダ５５および最高ポイント付与ボタン５６はそれぞれ、対応するリクエストに対して付与する付与ポイント値を入力するためのオブジェクトである。以下、これらを総称して「付与ポイント入力オブジェクト」という場合がある。

付与ポイント入力欄５４は、付与ポイント値をテキスト入力可能な入力欄である。付与ポイントスライダ５５は、つまみ部をスライドさせることによって下限値（本実施形態では「０ｐｔ」）から上限値（本実施形態では「１０，０００ｐｔ」）の間で付与ポイント値を入力するためのスライダである。付与ポイント入力欄５４と、付与ポイントスライダ５５とは連動している。すなわち、ある値の付与ポイント値が付与ポイント入力欄５４に入力されると、付与ポイントスライダ５５のつまみ部がその値に対応する位置に移動する。また付与ポイントスライダ５５のつまみ部が移動されることによって、付与ポイント値がある値に設定されると、付与ポイント入力欄５４にその値を示すテキストが表示される。

最高ポイント付与ボタン５６は、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち最も高い付与ポイント値」よりも「１ｐｔ」だけ高い付与ポイント値を入力することを指示するボタンである。上述したように、未対応リクエストについて、付与ポイント値が高いほどリプライ優先順位が高くなる。これを踏まえ注目視聴者は、投稿しようとしているリクエストについてリプライ優先順位を最も高くしたいと考えた場合、最高ポイント付与ボタン５６を選択することによって、簡易的にリプライ優先順位が最も高くなる付与ポイント値を入力することができる。最高ポイント付与ボタン５６が選択されると、端末制御部６Ａは、未対応リクエストのそれぞれの付与ポイント値のうち、最も高い付与ポイント値を特定し、当該最も高い付与ポイント値に「１ｐｔ」を加算した値を導出する。端末制御部６Ａは、導出した値を付与ポイント入力欄５４に表示すると共に、付与ポイントスライダ５５のつまみ部を導出した値に対応する位置に移動させる。

端末制御部６Ａは、付与ポイント入力オブジェクトに入力された付与ポイント値に応じて、入力された付与ポイント値が大きいほど、リクエスト入力欄５１に入力可能な文字数の上限を大きくする。本実施形態では２０００ｐｔ未満の場合の上限は１００文字であり、２０００ｐｔ以上５０００ｐｔ未満の場合の上限は２００文字であり、５０００ｐｔ以上の場合の上限は３００文字である。ただしこれらはあくまで一例である。付与ポイント値と文字数の上限との関係は、付与ポイントスライダ５５に明示される。また当該関係は、リクエスト入力欄５１と対応付けて明示される。この構成のため、リクエストを投稿しようとしているユーザに、より大きな値の付与ポイント値を付与するインセンティブを与えることができる。

リクエスト入力画面５０において最高ポイント付与ボタン５６の下方には、暫定優先順位画像５７が表示される。暫定優先順位画像５７は、付与ポイント入力オブジェクトに入力された付与ポイント値がリクエストに付与された場合に、リクエストのリプライ優先順位が何番目になるかを示す情報である。端末制御部６Ａはサーバ制御部１４と協働し、付与ポイント入力オブジェクトにより入力された付与ポイント値に変更がある度に以下の処理を実行する。すなわち端末制御部６Ａは、未応答リクエストのそれぞれの付与ポイント値を踏まえて、入力された付与ポイント値が付与されるとしたときのリプライ優先順位を導出する。端末制御部６Ａは、導出したリプライ優先順位を示すように暫定優先順位画像５７の内容を更新する。注目視聴者は、暫定優先順位画像５７が示すリプライ優先順位を参考にして、付与ポイント値を調整することができる。

以上の通り端末制御部６Ａは、リクエストの投稿に際して、リクエストに付与する付与ポイント値を入力する付与ポイント入力オブジェクトと、当該オブジェクトに入力された付与ポイント値がリクエストに付与された場合にリクエストの優先順位が何番目になるかを示す情報（暫定優先順位画像５７）とが表示された画面（リクエスト入力画面５０）を提供する機能を備える。また端末制御部６Ａは、リクエストの投稿に際して、リクエストのリプライ優先順位（優先順位）が最も高くなる付与ポイント値を入力するための最高ポイント付与ボタン５６（ボタン）が表示されたリクエスト入力画面５０（画面）を提供する機能を備える。また端末制御部６Ａは、リクエストの投稿に際して、リクエストを入力するリクエスト入力欄５１（入力欄）、および、リクエストに付与するポイントを入力する付与ポイント入力オブジェクト（オブジェクト）が表示されたリクエスト入力画面５０（画面）を提供する機能と、付与ポイント入力オブジェクトに入力された付与ポイント値が大きいほどリクエスト入力欄５１に入力可能な文字数の上限を大きくする機能とを有する。

暫定優先順位画像５７の下方には、リクエスト送信ボタン５８が設けられている。リクエスト送信ボタン５８は、リクエストを投稿するときに選択されるボタンである。フローチャートＦＥで示すように注目視聴者は、リクエスト入力欄５１へのリクエストの内容の入力、および付与ポイント入力オブジェクトで付与ポイント値を入力し、リクエスト送信ボタン５８を選択する（ステップＳＥ５）。これによりリクエストの投稿が完了する。リクエスト送信ボタン５８が選択されたことを検出すると端末制御部６Ａは、リクエスト入力欄５１に入力されたリクエストの内容を示すリクエスト内容情報と、付与ポイント入力オブジェクトに入力された付与ポイント値とを少なくとも含むリクエスト通知情報をサーバ制御部１４に送信する（ステップＳＥ６）。

なおリクエスト送信ボタン５８が選択されたときに、端末制御部６Ａは、サーバ制御部１４と協働して、付与ポイント入力オブジェクトに入力された付与ポイント値が、ポイント残高値の範囲内であるか否かを判別する。ポイント残高値の範囲内である場合、端末制御部６Ａは、リクエスト通知情報を送信する。一方でポイント残高値の範囲内ではない場合、端末制御部６Ａは、リクエスト通知情報を送信せずに以下の処理を実行する。すなわち端末制御部６Ａは、付与ポイント値がポイント残高値の範囲内ではないためリクエストの投稿ができない旨の警告を表示装置１２Ａに表示する。なお警告と併せて端末制御部６Ａが、付与ポイント値を取得するための画面を表示させるためのボタン、或いは当該画面自体を表示装置１２Ａに表示する構成でもよい。

リクエスト通知情報を受信するとサーバ制御部１４は、注目配信者に対応するリクエスト管理データベース４０に１件のレコードを追加する（ステップＳＤ１）。ステップＳＤ１においてサーバ制御部１４は、追加するレコードのリクエストＩＤ＜フィールド＞に、一意な値のリクエストＩＤを格納する。またサーバ制御部１４は、投稿者ＩＤ＜フィールド＞に、注目視聴者のユーザＩＤを格納する。またサーバ制御部１４は、リクエスト投稿日時＜フィールド＞に、リクエスト通知情報を受信した日時を示すリクエスト投稿日時情報を格納する。ただしリクエスト通知情報を受信した日時ではなく、リクエストが投稿された日時とみなすことができる他の日時（例えば、リクエスト送信ボタン５８が選択された日時）を示すリクエスト投稿日時情報を格納する構成でもよい。またサーバ制御部１４は、受信したリクエスト内容情報をリクエスト内容＜フィールド＞に格納する。またサーバ制御部１４は、受信した付与ポイント値を付与ポイント＜フィールド＞に格納する。またサーバ制御部１４は、オフ値のリプライ済フラグをリプライ済フラグ＜フィールド＞に格納する。またサーバ制御部１４は、初期値（ゼロ）を肯定評価数＜フィールド＞に格納し、ヌル値を肯定評価付与者＜フィールド＞に格納する。またサーバ制御部１４は、リプライ優先順位を導出し、導出したリプライ優先順位を示すリプライ優先順位情報をリクエストリプライ優先順位＜フィールド＞に格納する。なおサーバ制御部１４は、全ての未応答リクエストを対象として、リプライ優先順位情報を更新する。

更にサーバ制御部１４は、ユーザ管理データベース３６の注目視聴者に対応するレコードのポイント残高値について、受信した付与ポイント値に応じて減算する（ステップＳＤ２）。

以上のようにサーバ制御部１４は、ユーザによってリクエストが投稿されたときに、そのことを検出すると共に、リクエスト管理データベース４０への対応するレコードの登録、その他のリクエストの投稿を反映するための処理を実行する機能を備える。当該機能は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能に相当する。またサーバ制御部１４は、リクエストに付与ポイント値が付与されたときに、そのことを検出すると共に、リクエスト管理データベース４０への反映、その他の付与ポイント値の付与を反映するための処理を実行する機能を備える。当該機能は、リクエストの投稿時に、リクエストの投稿者からリクエストへのポイント値の付与を受け付ける機能に相当する。

なお例示した通常ボックス画面３８およびリクエスト入力画面５０は、単純化したものである。通常ボックス画面３８およびリクエスト入力画面５０の内容が例示した内容に限定されないことは勿論である。例えば通常ボックス画面３８とリクエスト入力画面５０とが一体的な画面であってもよい。またＱ＆Ａ、ヘルプ情報、その他のユーザにとって有益な情報を表示するためのオブジェクトが設けられる構成でもよい。当該オブジェクトが選択された場合、サーバ制御部１４は端末制御部６Ａと協働して、各種情報を表示する。

＜リクエストの投稿に関する補足＞
図８では、ライブ配信中に注目視聴者がリクエストを投稿する場合の情報処理システム１の動作例を説明した。ただし本件サービスにおいては、一のユーザは、他のユーザに対して、当該他のユーザによるライブ配信が行われている期間だけではなく、ライブ配信が行われていない期間においてもリクエストを投稿することができる。つまり、サーバ制御部１４はライブ配信中か否かにかかわらず、注目ユーザに対するリクエストの投稿をユーザから受け付ける。

以下、ユーザＵ１が、ユーザＵ２がライブ配信を行っていないときに、ユーザＵ２に対してリクエストを投稿する場合の情報処理システム１の動作について説明する。ユーザＵ１は、所定の本件サービス画面に対して、ユーザＵ２についての通常ボックス画面３８（図９）の表示を指示する。当該指示に応じて、ユーザＵ１の端末２の端末制御部６はサーバ制御部１４と協働し、ユーザＵ２についての通常ボックス画面３８を表示装置１２に表示する。サーバ制御部１４は、ユーザＵ２に対応するリクエスト管理データベース４０に基づいて、適宜、通常ボックス画面３８の表示に必要な情報を提供する。以後、ユーザＵ１は、図８で例示した作業と同様の作業を行って、ユーザＵ２に対してリクエストを投稿する。なおサーバ制御部１４および端末制御部６は、ユーザＵ１の作業に応じて、図８で説明した処理と同様の処理を実行する。なおユーザＵ１による、ユーザＵ２についての通常ボックス画面３８の表示の指示は、様々な方法で行われ得る。

＜リクエストボックス確認ボタン２５が選択された場合の処理＞
次にライブ配信中に注目配信者によりリクエストボックス確認ボタン２５が選択されたときの情報処理システム１の動作について説明する。注目配信者がリクエストボックス確認ボタン２５を選択したことを検出すると、端末制御部６Ｌは、サーバ制御部１４に未応答リクエストのそれぞれの表示用リクエスト情報の応答を要求する。サーバ制御部１４は、リクエスト管理データベース４０を参照し、未応答リクエストのそれぞれの表示用リクエスト情報を生成して応答する。表示用リクエスト情報の内容は上述した通りである。未応答リクエストのそれぞれの表示用リクエスト情報を受信すると端末制御部６Ｌは、表示用リクエスト情報に基づいて、配信者側画面２０上に配信者側ボックス画面６０をポップアップ表示する。

図１１は、配信者側ボックス画面６０を示す図である。図１１で示すように配信者側ボックス画面６０の上部には、未応答リクエスト個数画像４１が表示される。未応答リクエスト個数画像４１の右方には、現時点の未応答リクエストの全てについて仮にリプライした場合に、獲得できる本件ポイントの値を示す獲得可能ポイント画像６１が表示される。後に明らかになる通り注目配信者は、あるリクエストに対してリプライしたときにそのリクエストに付与された付与ポイント値に相当する獲得ポイント値を獲得できる。

配信者側ボックス画面６０において未応答リクエスト個数画像４１の下方には、リクエストカード一覧領域４２Ｌが設けられる。リクエストカード一覧領域４２Ａには、未応答リクエストごとに、配信者側リクエストカード４４Ｌ（リクエストに関する情報）が表示される。配信者側ボックス画面６０に表示される配信者側リクエストカード４４Ｌは、カード処置ボタン６２を備えている点で、通常ボックス画面３８に表示されるリクエストカード４４と異なっている。カード処置ボタン６２が選択されると、端末制御部６Ａは、以下の３つのアクションのうちの何れかを選択可能な画面をポップアップ表示する。

１つ目のアクションは、配信者側リクエストカード４４Ｌの削除である。配信者側リクエストカード４４Ｌの削除が選択されると端末制御部６Ｌは、対応する配信者側リクエストカード４４Ｌをリクエストカード一覧領域４２Ｌから削除する。更にサーバ制御部１４は端末制御部６Ｌと協働して、注目配信者に対応するリクエスト管理データベース４０の「削除が指示された配信者側リクエストカード４４Ｌに対応するレコード」を削除すると共に、当該レコードを、削除済みのリクエストを管理する他のデータベースに登録する。２つ目のアクションは、リクエストを投稿したユーザのブロックである。ブロックが選択されるとサーバ制御部１４は端末制御部６Ｌと協働して、リクエストを投稿したユーザから注目配信者へのリクエストがブロックされる状態を構築する。３つ目のアクションは、管理者への通報である。通報が選択されるとサーバ制御部１４は端末制御部６Ｌと協働して、リクエストの内容およびリクエスト投稿者に関する情報を管理者へ通報する。

端末制御部６Ｌはサーバ制御部１４と協働して、リクエストカード一覧領域４２Ｌ内で、配信者側リクエストカード４４Ｌをリプライ優先順位に従って並んで配置する。注目配信者は、リクエストカード一覧領域４２Ｌを参照することにより、リプライ優先順位を踏まえつつ、未応答リクエストの内容およびリクエスト投稿者に関する情報を把握することができる。後述するように注目配信者がリプライ開始ボタン２４を選択すると、リプライ優先順位が最も高いリクエストに対応する配信者側リクエストカード４４Ｌ、つまり、配信者側ボックス画面６０を表示したときに最上部に表示される配信者側リクエストカード４４Ｌが、リプライの対象となる。これを踏まえ注目配信者は、配信者側ボックス画面６０を参照することによって、自身がリプライ開始ボタン２４を選択した場合にリプライの対象となるリクエストカード４４の内容を確認することができる。

＜注目配信者によりリプライが行われるときの処理＞
次にライブ配信中に注目配信者によりリプライが行われるときの情報処理システム１の動作について説明する。図１２は、注目配信者によりリプライが行われるときの配信者端末２Ｌ、情報処理サーバ３および視聴者端末２Ａの情報処理方法を示すフローチャートである。フローチャートＦＦは配信者端末２Ｌによる情報処理方法を示し、フローチャートＦＧは情報処理サーバ３による情報処理方法を示し、フローチャートＦＨは視聴者端末２Ａによる情報処理方法を示す。

ここで１回のライブ配信において配信者は、リプライを複数回、実行することができる（ただし１回も行わなくてもよい）。例えば配信者が２回のリプライを行うとする。この場合、配信者は、１回目のリプライを行うときにリプライ開始ボタン２４を選択し、１回目のリプライが完了するとリプライ終了ボタン６３を選択する。その後、配信者は、２回目のリプライを行うときにリプライ開始ボタン２４を選択し、２回目のリプライが完了するとリプライ終了ボタン６３を選択する。図１２を用いた説明では、注目配信者により１つのリプライが行われるときに着目して情報処理システム１の動作について説明する。

フローチャートＦＦで示すように注目配信者は、リプライ開始ボタン２４を選択することによってリプライの開始を指示する（ステップＳＦ１）。リプライ開始ボタン２４が選択されたことを検出すると、端末制御部６Ｌは、リプライの開始をサーバ制御部１４に通知する（ステップＳＦ２）。

フローチャートＦＧで示すようにサーバ制御部１４は、リプライの開始の通知を受信すると、サーバ制御部１４は、注目配信者に対応するリクエスト管理データベース４０を参照し、未応答リクエストのうち、リプライ優先順位が最も高い未応答リクエストを特定する（ステップＳＧ１）。以下、リプライ優先順位が最も高い未応答リクエストを「最高位リクエスト」という。

次いでライブ配信管理データベース３５の注目ライブ配信に対応するレコードのリプライログデータ３４に、リプライの開始に関する情報を記録する（ステップＳＧ２）。図１３は、リプライログデータ３４の内容を説明に適した態様で模式的に示す図である。リプライログデータ３４は、ライブ配信において行われたリプライのそれぞれについて、リプライ実績情報ＲＪが記録される。１つのリプライ実績情報ＲＪは、何回目のリプライであるかを示す情報と、最高位リクエストのリクエストＩＤと、開始タイミングと、終了タイミングとを含んでいる。なお本実施形態では開始タイミングおよび終了タイミングは、ライブ配信が開始されたタイミングを基点とした経過時間として表される。ただし開始タイミングおよび終了タイミングの表現形式は、本実施形態で例示する形式に限られない。開始タイミングおよび終了タイミングは、後述する抽出動画データの生成に利用可能な情報であればよい。

ステップＳＧ２においてサーバ制御部１４は、一例として以下の処理を実行する。例えばステップＳＦ１においてリプライ開始ボタン２４が選択されることによって開始されたリプライの回目が２回目であったとする。この場合、ステップＳＧ２においてサーバ制御部１４は、まず開始タイミングを認識する。例えば、ライブ配信の開始からの経過時間が「５：００」であったとする。この場合、サーバ制御部１４は、開始タイミングとして「５：００」を認識する。次いでサーバ制御部１４は、２回目のリプライであることを示す情報、最高位リクエストのリクエストＩＤ、および、開始タイミングをフォーマットに従ってリプライログデータ３４に記録する。

次いでサーバ制御部１４は、最高位リクエストに付与された付与ポイント値分の獲得ポイントを注目配信者に付与する（ステップＳＧ３）。具体的にはサーバ制御部１４は、ユーザ管理データベース３６の注目配信者に対応するレコードの獲得ポイント合計値を、最高位リクエストに付与された付与ポイント値分、増加させる。あるユーザについての獲得ポイント合計値は、そのユーザが獲得した獲得ポイント値の累計値である。詳細は省略するが、注目配信者は、獲得ポイントと引き換えに、相応の特典を受けることができる。一例として注目配信者は、獲得ポイントの量に相当する金銭の付与を受けることができる。このようにユーザが獲得ポイントと引き換えに相応の特典を受けることができることは、ユーザがリプライを行うことのインセンティブとなる。

次いでサーバ制御部１４は、注目配信者に対応するリクエスト管理データベース４０の最高位リクエストに対応するレコードに基づいて、最高位リクエストについての表示用リクエスト情報を生成する（ステップＳＧ４）。次いでサーバ制御部１４は、リクエスト表示指示情報を配信者端末２Ｌおよび視聴者端末２Ａに送信する（ステップＳＧ５）。リクエスト表示指示情報とは、最高位リクエストに対応する表示用リクエスト情報を含み、最高位リクエストに対応するリクエストカード４４の表示を指示する情報である。

フローチャートＦＨで示すように端末制御部６Ａは、リクエスト表示指示情報を受信すると、最高位リクエストに対応するリクエストカード４４を視聴者側画面２９にポップアップ表示する（ステップＳＨ１）。その際、端末制御部６Ａは、付与ポイント値に応じて、リクエストカード４４の色を変化させる。付与ポイント値と色との関係は、上述した通りである。図１４は、最高位リクエストに対応するリクエストカード４４が視聴者側画面２９に表示された様子を示している。リプライの開始に応じて、最高位リクエストに対応するリクエストカード４４が視聴者側画面２９に表示されるため、注目視聴者は、注目配信者によるリプライが行われている間、対応するリクエストの内容を的確に把握できる。

フローチャートＦＦで示すように端末制御部６Ｌは、リクエスト表示指示情報を受信すると、最高位リクエストに対応するリクエストカード４４を配信者側画面２０にポップアップ表示する（ステップＳＦ３）。その際、端末制御部６Ａは、付与ポイント値に応じて、リクエストカード４４の色を変化させる。付与ポイント値と色との関係は、上述した通りである。注目配信者は、リクエストカード４４の色を参照することにより、付与ポイント値がどの程度であるかを直感的に把握できる。

更にサーバ制御部１４は、リプライ開始ボタン２４に代えてリプライ終了ボタン６３を表示し、リクエストボックス確認ボタン２５に代えて破棄ボタン６４を表示する（ステップＳＦ４）。図１５は、最高位リクエストに対応するリクエストカード４４が配信者側画面２０に表示された様子を示している。破棄ボタン６４は、実行中のリプライについて、抽出動画データ（後述）の生成を行わないことを指示するボタンである。破棄ボタン６４が選択されたことを検出すると端末制御部６Ｌは、そのことをサーバ制御部１４に通知し、サーバ制御部１４は、リプライログデータ３４から、対応するリプライ実績情報ＲＪを削除する。この場合、サーバ制御部１４は、注目配信者によりリプライ終了ボタン６３が選択されたときに、終了タイミングを示す情報のリプライログデータ３４への記録を行わない。リプライログデータ３４に、あるリプライのリプライ実績情報ＲＪが記録されないことにより、そのリプライに対応する抽出動画データは生成されないことになる。

以上の通り注目配信者によってリプライの開始が指示されると、配信者端末２Ｌの表示装置１２Ｌに最高位リクエストに対応する配信者側リクエストカード４４Ｌが表示される。配信者は、配信者側リクエストカード４４Ｌを参照することによってリクエストの内容を把握することができ、リクエストに対してリプライすることができる。注目配信者がリプライを開始すると、注目配信者は、その時点でリプライ優先順位が最も高いリクエストに対して、独占的に対応することになる。つまりリクエストを投稿しようとする者にとっては、自身が投稿しようとするリクエストのリプライ優先順位が高いほど、より優先的にリプライされて、独占的に応答してもらえることになる。このため本件サービスでは、リクエストのリプライ優先順位を高くするインセンティブをユーザに付与できる。

注目配信者は、リクエストに対してリプライする。例えば、リクエストが質問である場合には、注目配信者は、質問に対して回答する。フローチャートＦＦで示すように注目配信者は、リプライが終了するとリプライ終了ボタン６３を選択することによって、リプライの終了を指示する（フローチャートＳＦ５）。リプライ終了ボタン６３が選択されたことを検出すると端末制御部６Ｌは、リプライの終了をサーバ制御部１４に通知する（ステップＳＦ６）。更に端末制御部６Ｌは、リクエストカード４４の表示を停止し、リプライ終了ボタン６３および破棄ボタン６４に代えて、リプライ開始ボタン２４およびリクエストボックス確認ボタン２５を配信者側画面２０に表示する（ステップＳＦ７）。

フローチャートＦＧで示すようにサーバ制御部１４は、リプライの終了の通知を受信するとライブ配信管理データベース３５の注目ライブ配信に対応するレコードのリプライログデータ３４に、リプライの終了に関する情報を記録する（ステップＳＧ６）。詳述するとサーバ制御部１４は、終了タイミング（ライブ配信の開始からの現時点までの経過時間）を認識し、認識した終了タイミングをフォーマットに従ってリプライログデータ３４の今回のリプライ実績情報ＲＪに記録する。更にサーバ制御部１４は、リクエストカード４４の表示の停止の指示を端末制御部６Ａに送信する（ステップＳＧ７）。

フローチャートＦＨで示すように端末制御部６Ａは、リクエストカード４４の表示の停止の指示を受信すると、視聴者側画面２９に表示していたリクエストカード４４の表示を停止する（ステップＳＨ２）。

以上の通りサーバ制御部１４は、注目配信者がリプライの開始を指示したときに、そのことを検出すると共に、リプライログデータへの情報の記録、最高位リクエストについての表示用リクエスト情報の送信、その他のリプライの開始の指示を反映するための処理を実行する機能を備える。当該機能は、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示を受け付ける機能に相当する。またサーバ制御部１４は、注目配信者がリプライの終了を指示したときに、そのことを検出すると共に、リプライログデータへの情報の記録、リクエストカードの表示の停止の指示、その他のリプライの終了の指示を反映するための処理を実行する機能を備える。当該機能は、リクエストに対するリプライの終了の指示を受け付ける機能に相当する。これを踏まえサーバ制御部１４は、注目配信者によるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの１つをライブ配信の視聴者の端末２に表示させる機能を備える。またサーバ制御部１４は、ライブ配信中にリプライの開始の指示があった場合、未応答リクエストのうち、リプライ優先順位（優先順位）が最も高いものを視聴者の端末２に表示させる機能を備える。

なお本実施形態では、配信者によってリプライ終了ボタン６３が選択されることによってのみリプライが終了する構成であった。この点に関して以下の構成でもよい。すなわちリプライが開始されてから終了するまでの時間に制限が設けられ、制限時間となったら強制的にリプライが終了し、ステップＳＦ６以下の処理が実行される構成でもよい。

＜抽出動画データを生成するときの動作＞
次に抽出動画データを生成するシーンについて説明する。抽出動画データとは、１つのリプライの開始から終了までの期間のライブ配信に係る動画が記録された動画データ（動画ファイル）のことである。上述したように１回のライブ配信において、リプライは複数回、行われる場合がある。本件サービスでは、行われたリプライのそれぞれについて、抽出動画データが自動で生成されることになる。

図１６のフローチャートＦＩは、注目ライブ配信に係る抽出動画データを生成するときの情報処理サーバ３の動作を示すフローチャートである。以下の説明では、注目ライブ配信において注目配信者によって複数回のリプライが行われたものとする。なお図１６のフローチャートＦＩの処理は、注目ライブ配信が終了した後の所定のタイミングで開始される。例えば当該処理は、注目ライブ配信が終了した直後に実行される。また例えば当該処理は、一日の決まった時刻にバッチ処理として開始される。

フローチャートＦＩで示すようにサーバ制御部１４は、ライブ配信管理データベース３５の注目ライブ配信に対応するレコードを参照し、注目ライブ配信に係るライブ配信全体動画データを取得する（ステップＳＩ１）。ここで取得されたライブ配信全体動画データは、注目ライブ配信の全体が記録された動画データである。次いでサーバ制御部１４は、注目ライブ配信に対応するレコードのリプライログデータ３４を取得する（ステップＳＩ２）。ここで取得されたリプライログデータ３４は、注目ライブ配信で行われたリプライのそれぞれについてリプライ実績情報ＲＪが記録されている。

次いでサーバ制御部１４は、ライブ配信全体動画データおよびリプライログデータ３４に基づいて抽出動画データ生成処理を実行する（ステップＳＩ３）。詳述するとサーバ制御部１４は、ライブ配信全体動画データについて、リプライごとに、開始タイミングから終了タイミングまでの部分を抽出した動画データを生成する。ここで生成された１つのリプライに対応する１つの動画データが「抽出動画データ」に相当する。例えばリプライログデータ３４の内容が図１７の（Ａ）で示すものであったとする。またライブ配信全体動画データの全体の長さが「１０：００」であったとする。この場合、図１７の（Ｂ）で示すように、サーバ制御部１４は、ライブ配信全体動画データの「１：００～２：０１」の部分を抽出して１つの抽出動画データを生成し、「３：３０～５：００」の部分を抽出して１つの抽出動画データを生成し、「７：０１～９：０１」の部分を抽出して１つの抽出動画データを生成する。抽出動画データには、リプライの開始から終了までの期間のライブ配信に係る動画が記録される。以下、抽出動画データに記録された動画を「抽出動画」という。

なお詳細は省略するが、サーバ制御部１４は、ストリーミング配信に適したフォーマットへ変更するためのエンコード、その他の抽出動画データをストリーミング配信可能な状態とするために必要な処理を既存技術に基づいて適切に実行する。

以上の通りサーバ制御部１４は、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能を備える。ここで抽出動画データに記録された抽出動画は、１つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年では、ライブ配信だけではなく、ライブ配信の一部を抽出した動画（「切抜き動画」と呼ばれることもある）が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。本実施形態は、このような利用価値の高い抽出動画データが自動で生成される点において、強い優位性を持つ。

次いでサーバ制御部１４は、適切性判別処理を実行する（ステップＳＩ４）。以下、１つの抽出動画データを対象としてサーバ制御部１４がステップＳＩ４で実行する処理を説明する。まずサーバ制御部１４は、抽出動画データについて、予め設定された不適切条件を満たすか否かを判別する。本実施形態では、不適切条件の１つは、「抽出動画の長さが許容範囲を超えて短い場合に成立する条件」（以下「時間関連条件」という）である。サーバ制御部１４は、抽出動画の長さが予め定められた閾値よりも短い場合、時間関連条件が成立すると判定する。許容範囲を超えて抽出動画の長さが短い場合、注目配信者が非常に短い期間しかリプライに費やさなかったということであり、対応するリクエストが注目配信者にとって望まないものであった可能性、または注目配信者が誤ってリプライ終了ボタン６３を選択してしまった可能性がある。

また不適切条件の１つは、「抽出動画の明るさが許容範囲を超えて暗い場合に成立する条件」（以下「明度関連条件」という）である。サーバ制御部１４は、抽出動画の各フレームの平均輝度を導出し、更に各フレームの平均輝度の平均値を導出し、導出した平均値が予め定められた閾値よりも小さい場合、明度関連条件が成立すると判定する。当該閾値は、抽出動画について真っ暗に近い状態が継続する場合に明度関連条件が成立するような値に設定される。明度関連条件が成立する場合、抽出動画が真っ暗に近い状態で継続するものであるということであり、注目配信者が公開を望まないものと想定される。なお本実施形態で例示する明度関連条件の内容はあくまで一例であり、抽出動画の明るさが許容範囲を超えて暗い場合に成立する条件であればよい。

適切性判別処理においてサーバ制御部１４は、ある抽出動画データについて、時間関連条件と明度関連条件とのうち少なくとも一方の条件が成立する場合には、その抽出動画データについて不適切条件を満たすと判定する。サーバ制御部１４は、不適切条件を満たす抽出動画データについては削除する。抽出動画データを削除する処理は、抽出動画データを破棄する処理に相当する。

なお本実施形態では、サーバ制御部１４が、抽出動画データを生成した後に、不適切条件を満たす場合には削除する構成である。この点に関し、サーバ制御部１４が、抽出動画データの生成時に、不適切条件を満たすか否かを判別し、不適切条件を満たす場合には、抽出動画データを生成しない構成でもよい。抽出動画データを生成しない処理は、抽出動画データを破棄する処理に相当する。

以上の通り、サーバ制御部１４は、抽出動画データの生成に際して、記録される動画の長さが許容範囲を超えて短い場合、または、記録される動画の明るさが許容範囲を超えて暗い場合、抽出動画データを破棄する機能を備える。

次いでサーバ制御部１４は、サーバ記憶部１６に記憶された抽出動画管理データベース６５に、生成した抽出動画データのそれぞれに対応するレコードのそれぞれを登録する（ステップＳＩ５）。抽出動画管理データベース６５は、抽出動画データのそれぞれを管理するデータベースであり、抽出動画データごとにレコードが登録される。図６（Ｄ）は、抽出動画管理データベース６５の１件のレコードの内容を示している。図６（Ｄ）で示すように抽出動画管理データベース６５の１件のレコードはフィールドとして、抽出動画ＩＤ＜フィールド＞と、配信者ＩＤ＜フィールド＞と、投稿者ＩＤ＜フィールド＞と、リクエストＩＤ＜フィールド＞と、抽出動画＜フィールド＞と、サムネイル画像＜フィールド＞と、表示用リクエスト＜フィールド＞と、タイトル＜フィールド＞と、タグ＜フィールド＞とを備えている。

抽出動画ＩＤ＜フィールド＞には、対応する抽出動画データを一意に識別する識別情報である抽出動画ＩＤが格納される。配信者ＩＤ＜フィールド＞には、対応するライブ配信の配信者のユーザＩＤが格納される。リクエストＩＤ＜フィールド＞には、対応するリクエスト（＝対応する抽出動画データに基づく抽出動画において配信者がリプライしているリクエスト）のリクエストＩＤが格納される。抽出動画＜フィールド＞には、対応する抽出動画データが格納される。サムネイル画像＜フィールド＞には、対応する抽出動画データに基づくサムネイル画像の画像データ（以下「サムネイル画像データ」という）が格納される。表示用リクエスト＜フィールド＞には、対応するリクエストの表示用リクエスト情報が記録される。上述した通り表示用リクエスト情報には、リクエストカード４４を表示するために必要な情報が不足なく含まれている。タイトル＜フィールド＞には、対応する抽出動画データのタイトルを示す情報が格納される。タグ＜フィールド＞には、本件タグのタグ情報（本件タグの具体的な値）が格納される。本件タグとは、本件サービスにおいて利用可能なコンテンツにおいて、コンテンツにメタ情報として付与されるタグである。本件タグは、コンテンツの検索や、分類等に使用される。本件タグは、いわゆるハッシュタグと同等の機能を有する。

ステップＳＩ５において、ある１つの抽出動画データに対応する１つのレコードの登録に際して、サーバ制御部１４は、以下の処理を実行する。サーバ制御部１４は、一意な値の抽出動画ＩＤを生成し、抽出動画ＩＤ＜フィールド＞に格納する。またサーバ制御部１４は、注目配信者のユーザＩＤを配信者ＩＤ＜フィールド＞に格納する。またサーバ制御部１４は、対応するリクエストのリクエストＩＤ（リプライログデータ３４の対応するリプライ実績情報ＲＪに記録されているリクエストＩＤ）をリクエストＩＤ＜フィールド＞に格納する。またサーバ制御部１４は、抽出動画データを抽出動画＜フィールド＞に格納する。またサーバ制御部１４は、抽出動画データに基づいてサムネイル画像を生成し、サムネイル画像＜フィールド＞に格納する。サーバ制御部１４は、抽出動画データを構成するフレームの１つを取得し、対応する表示用リクエスト情報に基づくリクエストカード４４を重畳することによってサムネイル画像データを生成する。またサーバ制御部１４は、対応するリクエストの表示用リクエスト情報を表示用リクエスト＜フィールド＞に格納する。またサーバ制御部１４は、ルールに従ってタイトルを設定し、タイトルを示す情報をタイトル＜フィールド＞に格納する。ルールは一例として、ライブ配信を行った日付と、何回目のリプライであるかを示す情報とを所定の態様で組み合わせるというルールである。またサーバ制御部１４は、ヌル値をタグ＜フィールド＞に格納する。

次いでサーバ制御部１４は、公開処理を実行する（ステップＳＩ６）。なお本実施形態ではサーバ制御部１４が、抽出動画データの生成と連続して公開処理を実行する構成であるが、抽出動画データを生成した後に時間をあけて公開処理を実行する構成でもよい。公開処理は、生成した抽出動画データのそれぞれについて、抽出動画を視聴可能な状態を構築する処理である。以下、ある抽出動画データについて、対応する抽出動画を視聴可能な状態とすることを「抽出動画データを公開する」と表現する場合がある。また以下では、ある抽出動画データについて、ユーザが抽出動画データに基づく抽出動画を視聴することを単に、「ユーザが抽出動画データを視聴する」という場合がある。ここで本実施形態では、サーバ制御部１４は、抽出動画データをストリーミング配信することによって、抽出動画を提供する。抽出動画データに基づくストリーミング配信は既存の技術を利用して行われる。以下の説明では抽出動画の提供に際して、それを実現するためのストリーミング配信は適切に行われるものとして、ストリーミング配信自体についての詳しい説明は行わない。ただしストリーミング配信以外の手段で抽出動画が提供される構成でもよい。

以下、注目配信者によるライブ配信に基づく抽出動画データについて公開処理が行われるものとして、公開処理の複数の例を説明する。本件サービスでは、サーバ制御部１４は端末制御部６と協働して、指定された特定のユーザについての抽出動画一覧画面を提供できる。あるユーザについての抽出動画一覧画面は、そのユーザが配信者として行ったライブ配信に基づく抽出動画データのサムネイル画像が付随情報と共に一覧表示された画面である。例えばユーザＡは、ユーザＢの指定を伴う所定の入力を行うことによって、ユーザＢについての抽出動画一覧画面を自身の端末２の表示装置１２に表示させることができる。ユーザＢについての抽出動画一覧画面は、ユーザＢが配信者として行ったライブ配信に基づく抽出動画データのサムネイル画像が一覧表示された画面である。抽出動画一覧画面のサムネイル画像（付随情報或いは関連するオブジェクトでもよい）が選択されると、選択されたサムネイル画像に対応する抽出動画データがストリーミング配信され、抽出動画が提供される。そして公開処理においてサーバ制御部１４は、注目配信者に係る抽出動画一覧画面に、生成した抽出動画データのそれぞれに係るサムネイル画像が表示されるようにすると共に、サムネイル画像が選択されたときに対応する抽出動画が提供される状態を構築する。

また本件サービスでは、画面をスクロール操作（他の操作でもよい）することによって、視聴する抽出動画を次々と切り替えることができるサービス（以下「特定視聴サービス」という）が提供される。特定視聴サービスにおいて抽出動画の切り替えは、サーバ制御部１４と端末制御部６との協働により実行される。切り替えの指示に応じて表示される次の抽出動画に対応する抽出動画データは、プールされた抽出動画データの中から所定の方法でサーバ制御部１４によって選択される。当該所定の方法は、例えばランダム、または視聴するユーザの嗜好を反映させるアルゴリズムに従った方法である。そして公開処理においてサーバ制御部１４は、生成した抽出動画データのそれぞれを当該プールに追加し、特定視聴サービスにおいて、生成した抽出動画データに基づく抽出動画が提供され得る状態を構築する。

また本件サービスでは、タグを利用した抽出動画データの検索が可能となっている。検索の結果、見つかった抽出動画データに基づく抽出動画は、ユーザの選択に応じて提供される。そして公開処理においてサーバ制御部１４は、タグによる検索の対象となる状態を構築する。以上、公開処理の複数の例を説明したが、公開処理はこれらに限られない。すなわち公開処理では、本件サービスにおいて、抽出動画データに基づく抽出動画が視聴可能な状態が構築されればよい。

ここで抽出動画データは非常に利用価値の高いデータである点は上述した通りである。本実施形態では、抽出動画データの生成および公開は自動で行われることになる。つまり配信者が、ライブ配信を行った上、ライブ配信中にリプライを行うだけで、そのライブ配信に基づく抽出動画データが自動で生成され、公開される。従来、抽出動画データ（抽出動画）は、いわゆる切抜き動画データと呼ばれ、その生成および公開は、配信者自ら作業を行うか、他人に委ねることによって行われていた。本実施形態では、抽出動画データの生成、公開について、自ら作業を行ったり、他人に委ねたりする必要がなく、配信者の利便性が高い。

公開処理の後、サーバ制御部１４は、通知処理を実行する（ステップＳＩ７）。通知処理は、生成した抽出動画データのそれぞれについて、配信者、リクエスト投稿者および肯定評価付与者に、抽出動画データが公開されたことを通知する処理である。本実施形態では、各ユーザに、本件サービスに関する各種通知を受け取るボックス（以下「通知用ボックス」という）が設定される。各ユーザは、通知用ボックスで受け取った通知が一覧表示された画面を表示装置１２に表示させることができ、更に当該画面から１つの通知を選択することによって通知の詳細を表示させることができる。サーバ制御部１４は、生成した抽出動画データのそれぞれについて、配信者、投稿者および肯定評価付与者のそれぞれの通知用ボックスに対して、通知を送信する。１つの抽出動画データに対応する通知には、少なくとも配信者のユーザ名、サムネイル画像、タイトルが含まれる。抽出動画データに基づく抽出動画を視聴する画面に遷移するためのリンクが付加されていてもよい。

以上の通りサーバ制御部１４は、抽出動画データに記録された動画を視聴可能な状態を構築する機能と、当該状態の構築に応じて、抽出動画データに対応するリクエストの投稿者、および、抽出動画データに対応するリクエストに肯定評価を付与したユーザに通知を行う機能とを備える。この構成によれば、リクエスト投稿者および肯定評価付与者のそれぞれは、抽出動画データが公開されたことの通知により、そのことを認識することができ、好きなときにいつでも抽出動画を視聴できる。特に本実施形態では肯定評価付与者に対して通知が行われるため、各ユーザは、気になるリクエストカード４４が存在する場合に、そのリクエストカード４４に肯定評価を付与しておけば、対応する抽出動画データが公開されたときに、そのことを認識し、都合のよいときに抽出動画を視聴できる。詳述すると、あるユーザ（ユーザＵ１とする）が、配信者となり得る別のユーザ（ユーザＵ２とする）の通常ボックス画面３８を参照し、ユーザＵ２がどのような応答をするのか気になるリクエストカード４４（リクエスト）を見つけたとする。このときユーザＵ１は、そのリクエストカード４４に肯定評価を付与する。すると、そのリクエストカード４４に対してリプライが行われたライブ配信の終了後、そのリクエストカード４４に対応する抽出動画データがサーバ制御部１４によって自動で生成されて公開され、そのことがユーザＵ１に通知される。ユーザＵ１は、仮にライブ配信を見逃した場合であっても、自身が興味を抱いたリクエストカード４４に対応する抽出動画データが公開されたことを認識し、都合のよいときに視聴することができる。

＜ユーザが抽出動画を視聴するときの動作＞
次にユーザが抽出動画を視聴するときの情報処理システム１の動作について説明する。上述の通り生成された抽出動画データは公開される。ユーザは、本件サービスを利用して、所望の抽出動画データを視聴することができる。そしてサーバ制御部１４は、ユーザが、自身が配信者であったライブ配信に基づく抽出動画データを視聴する場合に、特別な処理を実行する。以下の説明では、ある抽出動画データについて、元となったライブ配信の配信者のことを「該当配信者」という。またサーバ制御部１４は、ユーザが、自身が投稿したリクエストに対応する抽出動画データを視聴する場合、特別な処理を実行する。以下の説明では、ある抽出動画データについて、対応するリクエスト投稿者のことを「該当リクエスト投稿者」という。

図１８は、抽出動画の視聴が開始されるときの情報処理システム１の動作を示すフローチャートである。フローチャートＦＪは端末２による情報処理方法を示し、フローチャートＦＫは情報処理サーバ３による情報処理方法を示す。以下の説明では、抽出動画を視聴するユーザを「視聴ユーザ」といい、視聴ユーザにより視聴される抽出動画データを「注目抽出データ」といい、

フローチャートＦＫで示すように情報処理サーバ３のサーバ制御部１４は、注目抽出動画データのストリーミング配信を開始する（ステップＳＫ１）。ストリーミング配信の開始と併せてサーバ制御部１４は、抽出動画管理データベース６５の注目抽出動画データに対応するレコード（以下「注目レコード」という）の表示用リクエスト情報およびタグ情報（複数ある場合には複数のタグ情報）を端末制御部６Ｌに送信する（ステップＳＫ２）。なおタグ＜フィールド＞に１つもタグ情報が格納されていない場合には、タグ情報は送信されない。

更にサーバ制御部１４は、視聴ユーザが、該当配信者または該当リクエスト投稿者であるかを判別する（ステップＳＫ３）。視聴ユーザが該当配信者であるということは、注目抽出動画データが、視聴ユーザが配信者となって行ったライブ配信に基づくものということである。また視聴ユーザが該当リクエスト投稿者であるということは、注目抽出動画データが、視聴者が投稿したリクエストに対応するものということである。サーバ制御部１４は、視聴ユーザが、該当配信者または該当リクエスト投稿者であることを以下の方法で判定する。すなわちサーバ制御部１４は、視聴ユーザのユーザＩＤと、注目レコードの配信者ＩＤ＜フィールド＞に格納されたユーザＩＤまたは投稿者ＩＤ＜フィールド＞に格納されたユーザＩＤとの一致性に基づいて判定する。

視聴ユーザが該当配信者または該当リクエスト投稿者の場合（ステップＳＫ３：ＹＥＳ）、サーバ制御部１４は、タグ情報の付与を許可すること通知する許可通知を端末制御部６に送信する（ステップＳＫ４）。一方、視聴ユーザが該当配当者でもなく、該当リクエスト投稿者でもない場合（ステップＳＫ３：ＮＯ）、サーバ制御部１４は、タグ情報の付与を許可しないことを通知する不許可通知を端末制御部６に送信する（ステップＳＫ５）。

フローチャートＦＪで示すように端末制御部６は、サーバ制御部１４が送信した各情報を受信する（ステップＳＪ１）。次いでサーバ制御部１４は、許可通知を受信したか、不許可通知を受信したか判別する（ステップＳＪ２）。許可通知を受信した場合（ステップＳＪ２：「許可通知」）、サーバ制御部１４は、特別視聴画面６６を表示装置１２に表示する（ステップＳＪ３）。一方、不許可通知を受信した場合（ステップＳＪ２：「不許可通知」）、サーバ制御部１４は、通常視聴画面６７を表示装置１２に表示する（ステップＳＪ４）。

図１９の（Ａ）は特別視聴画面６６を示し、（Ｂ）は通常視聴画面６７を示す図である。図１９の（Ａ）の特別視聴画面６６は視聴ユーザが該当配信者または該当リクエスト投稿者である場合に表示され、（Ｂ）のは視聴ユーザが該当配信者でも該当リクエスト投稿者でもない場合に表示される。図１９で示すように、特別視聴画面６６には、背景として配信動画像６８が表示される。配信動画像６８は、抽出動画データのストリーミング配信に基づいて表示される動画像であり、ライブ配信中の撮影動画像２１に対応する。配信動画像６８の中央やや下方には、リクエストカード４４が表示される。端末制御部６は、受信した表示リクエスト情報にリクエストカード４４を表示する。このように端末制御部６は、抽出動画データに記録された動画を、抽出動画データに対応するリクエストの内容（リクエストカード４４）と共に表示する機能を備える。

特別視聴画面６６においてリクエストカード４４の下方には、タグ表示領域６９が設けられている。タグ表示領域６９には、対応する抽出動画データに付与されたタグ情報が表示される。タグ情報のそれぞれは、選択可能なオブジェクトであり、タグ情報が選択されると、そのタグ情報をキーとしたコンテンツ（コンテンツには抽出動画データが含まれる）の検索がサーバ制御部１４により行われ、検索結果が提供される。

特別視聴画面６６においてタグ表示領域６９の右方には、タグ追加ボタン７０が表示される。タグ追加ボタン７０は、タグ情報を追加するためのボタンである。タグ追加ボタン７０が選択されると端末制御部６は、サーバ制御部１４と協働して、１つ以上のタグ情報の入力、および、入力したタグ情報の追加の指示を行うことが可能なタグ関連画面（不図示）を表示する。タグ関連画面を利用して１つ以上のタグ情報の追加の指示があると、サーバ制御部１４は端末制御部６と協働して、注目レコードのタグ＜フィールド＞に、追加が指示されたタグ情報を追加的に記録する。このように該当配信者または該当リクエスト投稿者は、注目抽出動画データにタグ情報を付加することができる。つまりサーバ制御部１４は、注目抽出動画データへのタグ情報（メタ情報）の付与を、該当配信者および該当リクエスト投稿者に許可する。またサーバ制御部１４は、該当リクエスト投稿者からタグ情報の付与の指示があったときに、そのことを検出すると共に、抽出動画管理データベース６５への反映、その他のタグ情報の付与を反映するための処理を実行する機能を有する。当該機能は、リクエストの投稿者からメタ情報の付与を受け付ける機能に相当する。

一方、図１９の（Ｂ）で示すように通常視聴画面６７には、タグ追加ボタン７０が表示されず、この点で特別視聴画面６６と相違している。通常視聴画面６７を視聴するユーザは、タグ情報を追加する手段がなく、注目抽出動画データにタグ情報を追加することができない。つまり該当配信者でもなく該当リクエスト投稿者でもないユーザは、注目抽出動画データにタグ情報を付加することができない。

以上の通りサーバ制御部１４は、抽出動画データを生成した後、生成した抽出動画データへのメタ情報の付与を、抽出動画データに対応するリクエストの投稿者に許可し、リクエストの投稿者からメタ情報の付与を受け付ける機能を備える。この構成によれば、ユーザは、リクエストを投稿することによって、そのリクエストに基づく抽出動画データが生成され公開されたときに、タグ情報を付与できるという特権を得ることができる。このため、ユーザにリクエストを投稿しようとするインセンティブを付与できる。また端末制御部６は、抽出動画データに記録された動画を、抽出動画データに対応するリクエストの内容（リクエストカード４４）と共に表示する機能を備える。この構成によれば、抽出動画を視聴するユーザは、リクエストの内容を把握しつつ抽出動画を視聴することができ、ユーザの満足度が高い。

なお該当配当者および該当リクエスト投稿者がタグ情報を付与する手段は例示したものに限られない。例えばサーバ制御部１４は、図１６のフローチャートＦＩのステップＳＩ７の通知処理で該当配当者および該当リクエスト投稿者に抽出動画データが公開されたことを通知するときに、タグ情報を入力するためのユーザインタフェイスを併せて提供する。そして該当配当者および該当リクエスト投稿者が当該ユーザインタフェイスを利用してタグ情報を付与できる構成でもよい。

また付与可能なメタ情報はタグ情報に限られない。一例として抽出動画データのタイトルやサブタイトルでもよい。また端末制御部６がサーバ制御部１４と協働して、抽出動画を表示する際に、リクエストカード４４に加えて、そのときに投稿されたコメントに関する画像を表示する構成でもよい。また端末制御部６が、抽出動画を視聴するための画面において、配信動画像６８に重ねてリクエストカード４４を表示するのではなく、配信動画像６８を避けた領域にリクエストカード４４（或いは同等の内容の情報）を表示する構成でもよい。

以上説明したように、サーバ制御部１４は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示とを受け付け、リプライの開始の通知があった場合、リクエストのうちの１つをライブ配信の視聴者の端末２に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する。

この構成によれば、配信者がライブ配信中に、リプライの開始を指示し、当該指示に応じて視聴者の端末に表示されるリクエストにリプライし、リプライの完了後にリプライの終了を指示するという作業を行うことによって、配信者によって行われたリプライごとに、リプライを行った期間のライブ配信に係る動画が記録された抽出動画データが生成されることになる。この抽出動画データに記録された動画は、１つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年では、ライブ配信だけではなく、ライブ配信の一部を抽出した動画（いわゆる切抜き動画）が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。そして本発明によれば、このような利用価値の高い抽出動画データを生成するために、配信者は、ライブ配信全体の動画が記録された動画データを編集したり、抽出動画データの生成を他人に頼ったりする必要がなく、配信者の満足度を向上できる。すなわち本発明によれば、ライブ配信に係るサービスに関し、配信者の満足度を向上することができる。

＜変形例＞
次に変形例について説明する。なお変形例において、上記実施形態と同等の要素には同じ符号が付されている。上述した実施形態では、あるリクエストに対して付与ポイント値を付与できるのは、そのリクエストについてのリクエスト投稿者のみであった。一方で本実施形態では、各ユーザが、所望のリクエストの付与ポイント値に対して、所望の値だけ追加ポイント値を追加することができる。以下、ユーザＵ１が、ユーザＵ２に対して既に投稿されたリクエストについて、追加ポイント値を追加する場合を例にして、変形例に係る情報処理システム１の動作について説明する。

ユーザＵ１は、ユーザＵ２がライブ配信中か否かにかかわらず、任意のタイミングでユーザＵ２に対応する通常ボックス画面３８Ｘの表示を指示することができる。当該指示に応じてユーザＵ１の端末２の端末制御部６はサーバ制御部１４と協働して、表示装置１２に通常ボックス画面３８Ｘを表示する。

図２０の（Ａ）は、通常ボックス画面３８Ｘの一例を示す図である。図９と図２０の（Ａ）との比較で明らかな通り、通常ボックス画面３８Ｘでは、リクエストカード４４の付与ポイント画像４６と対応付けてポイント追加ボタン７２が付加されている。ポイント追加ボタン７２は、追加ポイント値を追加する場合に選択されるボタンである。ユーザＵ１がポイント追加ボタン７２を選択すると、端末制御部６はサーバ制御部１４と協働して、追加ポイント入力画面７３をポップアップ表示する。サーバ制御部１４は、ユーザ管理データベース３６、リクエスト管理データベース４０、その他のデータに基づいて、追加ポイント入力画面７３の表示に必要な情報を提供する。

図２０の（Ｂ）は、追加ポイント入力画面７３の一例を示す図である。図２０の（Ｂ）で示すように、追加ポイント入力画面７３の上部には、ユーザＵ１の本件ポイントの残高を示すポイント残高画像５２が表示される。ポイント残高画像５２の下方には追加ポイント入力欄７４が設けられ、これの下方には追加ポイントスライダ７５が設けられている。追加ポイント入力欄７４および追加ポイントスライダ７５はそれぞれ、リクエスト入力画面５０（図１０）の付与ポイント入力欄５４および付与ポイントスライダ５５と同じ機能を持つものであり、詳細な説明は省略する。

追加ポイントスライダ７５の下方には、最高ポイント追加ボタン７６が設けられる。最高ポイント追加ボタン７６は、“合算ポイント値”が、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち、最も高い付与ポイント値」よりも「１ｐｔ」だけ高くなるような追加ポイント値を入力することを指示するボタンである。合算ポイント値とは、リクエストの現時点の付与ポイント値と、追加ポイント値とを合算した値を意味する。以下、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち、最も高い付与ポイント値」を「他リクエスト最高値」という。例えば、他リクエスト最高値が３０００ｐｔであり、ユーザＵ１が追加ポイント値を追加しようとしているリクエストの現時点の付与ポイント値が１０００ｐｔであったとする。この場合にユーザＵ１が最高ポイント追加ボタン７６を選択すると、追加ポイント値として「２００１ｐｔ」が入力される。このとき合算ポイント値は「３００１ｐｔ」（１０００ｐｔ＋２００１ｐｔ）となり、他リクエスト最高値の「３０００ｐｔ」よりも「１ｐｔ」だけ高くなる。

最高ポイント追加ボタン７６の下方には、合算ポイント画像７７が表示される。合算ポイント画像７７は、対応するリクエストの現時点の付与ポイント値と、ユーザＵ１により入力された追加ポイント値とを合算した値が表示される。合算ポイント画像７７の下方には、入力された追加ポイント値が追加された場合にリクエストのリプライ優先順位が何番目になるかを示す暫定優先順位画像７８が表示される。暫定優先順位画像７８の下方には、入力を確定する確定ボタン７９が設けられている。

確定ボタン７９が選択されると、サーバ制御部１４は端末制御部６と協働して、ユーザＵ２のリクエスト管理データベース４０の対応するレコードの付与ポイント＜フィールド＞の付与ポイント値について、入力された追加ポイント値の分、増加させる。あるリクエストに付与された付与ポイント値が、そのリクエストのリプライ優先順位に影響を与えることは上述した通りである。このようにサーバ制御部１４は、ユーザがリクエストに対して追加ポイント値の追加を指示したときに、そのことを検出すると共に、リクエスト管理データベース４０への反映、その他の追加ポイント値の追加を反映するための処理を実行する機能を備える。当該機能は、リクエストの投稿者に限られないユーザからリクエストへのポイント値の追加を受け付ける機能に相当する。

以上の通りサーバ制御部１４は、リクエストが投稿された後に、リクエストの投稿者に限られないユーザからリクエストへの追加ポイント値（ポイント値）の追加を受け付ける機能を備える。また端末制御部６は、リクエストカード４４（リクエストに関する情報）が一覧表示されると共に、リクエストカード４４と関連付けてポイント追加ボタン７２（リクエストに追加する追加ポイント値を入力するためのオブジェクト）が表示された通常ボックス画面３８Ｘ（画面）を提供する機能を備える。また端末制御部６は、追加ポイント値を入力するためのオブジェクトに入力された追加ポイント値がリクエストに追加された場合にリクエストの優先順位が何番目になるかを示す暫定優先順位画像７８（情報）が表示された追加ポイント入力画面７３（画面）を提供する機能を備える。また端末制御部６は、リクエストの優先順位が最も高くなる追加ポイント値を入力する最高ポイント追加ボタン７６（ボタン）が表示された追加ポイント入力画面７３（画面）を提供する機能を備える。

本変形例の構成によればユーザは、所望のリクエストについて、所望の値だけ追加ポイント値を追加することができる。このためユーザは、別のユーザに対して既に他人により投稿されたリクエストについて、できるだけ早い段階で当該別のユーザにリプライして欲しい、或いは、当該別のユーザにリプライされる可能性をできるだけ上げたいと考えたときに、そのリクエストに対して追加ポイント値を追加することによって、そのリクエストのリプライ優先順位を上げることができる。

なお変形例で示した画面は一例であり、異なる内容の画面が提供される構成でもよい。例えばポイント追加ボタン７２が、リクエストカード４４内に表示されるのではなく、リクエストカード４４の外側でリクエストカード４４と対応付けて表示される構成でもよい。また例えば、ポイント追加ボタン７２に代えて、追加ポイント入力欄７４などの追加ポイント値を直接的に入力するためのオブジェクトが設けられる構成でもよい。

以上、本発明の一実施形態（変形例を含む）について説明したが、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

例えば抽出動画データを生成する処理は、上記実施形態で例示した処理に限定されない。一例としてサーバ制御部１４が、ライブ配信中に、リプライの開始の通知を受けてから、リプライの終了の通知を受けるまでの期間に配信される動画をリアルタイムで録画（記録）し、録画結果に基づいて抽出動画データを生成する構成でもよい。すなわちサーバ制御部１４の「リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能」について、抽出動画データを生成する具体的な処理は限定されず、どのような処理が行われてもよい。

また例えば上述したように情報処理サーバ３は、単一の装置である必要はない。特に情報処理サーバ３は、ライブ配信を実現する１つ以上のサーバ装置と、それ以外の１つ以上のサーバ装置との組合せによって構成されていてもよい。情報処理サーバ３が複数のサーバ装置によって構成されている場合、複数のサーバ装置のサーバ制御部が協働して「制御部」として機能する。

また例えば、リクエストに対して有効期限が設けられ、有効期限を超えてリプライされなかった場合、サーバ制御部１４が、リクエストを破棄する構成としてもよい。リクエストの破棄は、例えば、破棄されたか否かを管理するフラグの制御によって行われる。

また上記実施形態では、サーバ制御部１４は、ライブ配信中に視聴者からコメントの投稿を受け付ける機能を備えていたが、この機能はなくてもよい。

また例えば上記実施形態において、専用アプリの処理の一部または全部をウェブブラウザが代替して実行する構成でもよい。

また例えば上記実施形態ではサーバ制御部１４は、リプライの開始の通知に応じて、リプライ優先順位が最も高いリクエスト（リクエストカード４４）を視聴者の端末２に表示させる構成であった。この点に関しサーバ制御部１４が、表示させるリクエストを他の方法で選択する構成でもよい。例えばサーバ制御部１４が、未対応リクエストの中から１つの未対応リクエストをランダムに決定する構成でもよい。また例えばサーバ制御部１４が投稿されたタイミングが古いものを優先的に選択する構成でもよい。付与ポイント値がリプライ優先順位に影響を与えない構成の場合には、サーバ制御部１４が付与ポイント値の付与を受け付ける機能を有していなくてもよい。また肯定評価数がリプライ優先順位に影響を与えない構成の場合には、サーバ制御部１４が肯定評価の付与を受け付ける機能を有していなくてもよい。

また本件ポイントは、本件サービスで流通する独自のポイントであった。しかしながら本件ポイントの具体的な内容は、本実施形態で例示した内容に限られない。例えば本件ポイントは、本件サービス以外のサービスで使用されるポイントであってもよい。また例えば本件ポイントは、法定通貨或いは暗号通貨であってもよい。

また例えばサーバ制御部１４が実行すると説明した処理の一部をサーバ制御部１４と、情報処理サーバ３と通信可能な外部装置の情報処理機構とが協働して実行する構成としてもよい。この場合、情報処理サーバ３と外部装置とが協働して「情報処理装置」として機能する。この点は、端末制御部６、６Ｌ、６Ａについても同様である。

また例えば、端末２または情報処理サーバ３のコンピュータが実行するプログラムの提供、または、このプログラムをコンピュータで読み取り可能に記録した記録媒体の提供を実施形態に含めることができる。上記記録媒体としては、磁気的、光学的記録媒体又は半導体メモリーデバイスを用いることができる。具体的には、フレキシブルディスク、ＨＤＤ（Hard DiＳＨ Drive）、ＣＤ－ＲＯＭ（Compact DiＳＨ Read Only Memory）、ＤＶＤ（Digital Versatile DiＳＨ）、Ｂｌｕ－ｒａｙ（登録商標）Ｄｉｓｃ、光磁気ディスク、フラッシュメモリ、カード型記録媒体等の可搬型の、或いは固定式の記録媒体が挙げられる。

また例えば、例示したフローチャートについて、目的を実現でき、処理に矛盾が起こらない限り、処理の順番を変更したり、処理をより細かく分割したり、処理を追加したり、処理を削除したりしてもよい。

１ 情報処理システム
２ 端末
３ 情報処理サーバ（情報処理装置）
６ 端末制御部
１４ サーバ制御部（制御部）

Claims (19)

1. ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、
   前記注目ユーザによるライブ配信中に前記リクエストに対するリプライの開始の指示と前記リプライの終了の指示と受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの１つを前記ライブ配信の視聴者の端末に表示させる機能と、
   前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する制御部を備える
   ことを特徴とする情報処理装置。
2. 前記制御部は、
   前記ライブ配信中に前記リプライの開始の指示があった場合、前記注目ユーザがリプライしていない前記リクエストである未応答リクエストのうち、優先順位が最も高いものを前記視聴者の端末に表示させる機能を備える
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記リクエストの投稿時に、前記リクエストの投稿者から前記リクエストへのポイント値の付与を受け付ける機能と、
   付与された前記ポイント値が大きいほど前記優先順位が高くなるように、前記未応答リクエストについて前記優先順位を設定する機能とを備える
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記制御部は、
   前記リクエストが投稿された後に、前記リクエストの投稿者に限られないユーザから前記リクエストへの前記ポイント値の追加を受け付ける機能を備える
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記制御部は、
   前記ユーザから前記リクエストに対する肯定評価の付与を受け付ける機能と、
   付与された前記ポイント値が大きいほど、かつ付与された前記ポイント値が同じであれば付与された前記肯定評価の個数が多いほど前記優先順位が高くなるように、前記未応答リクエストについて前記優先順位を設定する機能とを備える
   ことを特徴とする請求項３に記載の情報処理装置。
6. 前記制御部は、
   前記抽出動画データの生成に際して、記録される動画の長さが許容範囲を超えて短い場合、または、記録される動画の明るさが許容範囲を超えて暗い場合、前記抽出動画データを破棄する機能を備える
   ことを特徴とする請求項１に記載の情報処理装置。
7. 前記制御部は、
   前記抽出動画データを生成した後、生成した前記抽出動画データへのメタ情報の付与を、前記抽出動画データに対応する前記リクエストの投稿者に許可し、前記リクエストの投稿者から前記メタ情報の付与を受け付ける機能を備える
   ことを特徴とする請求項１に記載の情報処理装置。
8. 前記制御部は、
   前記抽出動画データに記録された動画を視聴可能な状態を構築する機能と、
   当該状態の構築に応じて、前記抽出動画データに対応する前記リクエストの投稿者、および、前記抽出動画データに対応する前記リクエストに前記肯定評価を付与した者に通知を行う機能とを備える
   ことを特徴とする請求項５に記載の情報処理装置。
9. 請求項２から５の何れか１項に記載の情報処理装置と通信可能な端末であって、
   前記リクエストに関する情報が前記優先順位に従って並んで配置された画面を提供する機能を有する端末制御部を備える
   ことを特徴とする端末。
10. 請求項３に記載の情報処理装置と通信可能な端末であって、
    前記リクエストの投稿に際して、前記リクエストに付与する前記ポイント値を入力するオブジェクトと、前記オブジェクトに入力された前記ポイント値が前記リクエストに付与された場合に前記リクエストの前記優先順位が何番目になるかを示す情報とが表示された画面を提供する機能を有する端末制御部を備える
    ことを特徴とする端末。
11. 請求項３に記載の情報処理装置と通信可能な端末であって、
    前記リクエストの投稿に際して、前記リクエストの前記優先順位が最も高くなる前記ポイント値を入力するボタンが表示された画面を提供する機能を有する端末制御部を備える
    ことを特徴とする端末。
12. 請求項３に記載の情報処理装置と通信可能な端末であって、
    前記リクエストの投稿に際して、前記リクエストを入力する入力欄、および、前記リクエストに付与する前記ポイント値を入力するオブジェクトが表示された画面を提供する機能と、
    前記オブジェクトに入力された前記ポイント値の値が大きいほど前記入力欄に入力可能な文字数の上限を大きくする機能とを有する端末制御部を備える
    ことを特徴とする端末。
13. 請求項４に記載の情報処理装置と通信可能な端末であって、
    前記リクエストに関する情報が一覧表示されると共に、前記リクエストに関する情報と関連付けて前記リクエストに追加する追加ポイント値を入力するためのオブジェクトが表示された画面を提供する機能を有する端末制御部を備える
    ことを特徴とする端末。
14. 前記端末制御部は、
    前記オブジェクトに入力された前記追加ポイント値が前記リクエストに追加された場合に前記リクエストの前記優先順位が何番目になるかを示す情報が表示された画面を提供する機能を備える
    ことを特徴とする請求項１３に記載の端末。
15. 前記端末制御部は、
    前記リクエストの前記優先順位が最も高くなる前記追加ポイント値を入力するボタンが表示された画面を提供する機能を備える
    ことを特徴とする請求項１３に記載の端末。
16. 請求項５に記載の情報処理装置と通信可能な端末であって、
    前記リクエストに関する情報が一覧表示されると共に、前記リクエストに関する情報と関連付けて前記肯定評価を付与するためのオブジェクトが表示された画面を提供する機能を有する端末制御部を備える
    ことを特徴とする端末。
17. 請求項１から８の何れか１項に記載の情報処理装置と通信可能な端末であって、
    前記抽出動画データに記録された動画を、前記抽出動画データに対応する前記リクエストの内容と共に表示する機能を有する端末制御部を備える
    ことを特徴とする端末。
18. 情報処理装置と、前記情報処理装置と通信可能な端末とを備える情報処理システムであって、
    ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、
    前記注目ユーザによるライブ配信中に前記リクエストに対するリプライの開始の指示と前記リプライの終了の指示とを受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの１つを前記ライブ配信の視聴者の前記端末に表示させる機能と、
    前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成する機能とを備える
    ことを特徴とする情報処理システム。
19. 情報処理装置の制御部が、ライブ配信の配信者となり得る注目ユーザによるライブ配信中に、前記注目ユーザに対して投稿されたリクエストへのリプライの開始の指示と前記リプライの終了の指示とを受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの１つを前記ライブ配信の視聴者の端末に表示させるステップと、
    前記情報処理装置の前記制御部が、前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成するステップとを含む
    ことを特徴とする情報処理方法。