(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2023-11-29
(45)【発行日】2023-12-07
(54)【発明の名称】情報処理装置、端末、情報処理システムおよび情報処理方法
(51)【国際特許分類】
H04N 21/231 20110101AFI20231130BHJP
G06Q 50/10 20120101ALI20231130BHJP
H04N 21/235 20110101ALI20231130BHJP
H04N 21/431 20110101ALI20231130BHJP
【FI】
H04N21/231
G06Q50/10
H04N21/235
H04N21/431
(21)【出願番号】P 2023080613
(22)【出願日】2023-05-16
【審査請求日】2023-09-19
【早期審査対象出願】
(73)【特許権者】
【識別番号】522029604
【氏名又は名称】Replive株式会社
(74)【代理人】
【識別番号】100105784
【氏名又は名称】橘 和之
(72)【発明者】
【氏名】飯野 太治朗
【審査官】鈴木 隆夫
(56)【参考文献】
【文献】特開2022-75401(JP,A)
【文献】特開2017-107305(JP,A)
【文献】特開2021-81882(JP,A)
【文献】特開2018-23003(JP,A)
【文献】米国特許出願公開第2018/0048599(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04N 21/00-21/858
G06Q 50/10
(57)【特許請求の範囲】
【請求項1】
ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、
前記注目ユーザによるライブ配信中に前記リクエストに対するリプライの開始の指示と前記リプライの終了の指示と受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの1つを前記ライブ配信の視聴者の端末に表示させる機能と、
前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する制御部を備える
ことを特徴とする情報処理装置。
【請求項2】
前記制御部は、
前記ライブ配信中に前記リプライの開始の指示があった場合、前記注目ユーザがリプライしていない前記リクエストである未応答リクエストのうち、優先順位が最も高いものを前記視聴者の端末に表示させる機能を備える
ことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記制御部は、
前記リクエストの投稿時に、前記リクエストの投稿者から前記リクエストへのポイント値の付与を受け付ける機能と、
付与された前記ポイント値が大きいほど前記優先順位が高くなるように、前記未応答リクエストについて前記優先順位を設定する機能とを備える
ことを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記制御部は、
前記リクエストが投稿された後に、前記リクエストの投稿者に限られないユーザから前記リクエストへの前記ポイント値の追加を受け付ける機能を備える
ことを特徴とする請求項3に記載の情報処理装置。
【請求項5】
前記制御部は、
前記ユーザから前記リクエストに対する肯定評価の付与を受け付ける機能と、
付与された前記ポイント値が大きいほど、かつ付与された前記ポイント値が同じであれば付与された前記肯定評価の個数が多いほど前記優先順位が高くなるように、前記未応答リクエストについて前記優先順位を設定する機能とを備える
ことを特徴とする請求項3に記載の情報処理装置。
【請求項6】
前記制御部は、
前記抽出動画データの生成に際して、記録される動画の長さが許容範囲を超えて短い場合、または、記録される動画の明るさが許容範囲を超えて暗い場合、前記抽出動画データを破棄する機能を備える
ことを特徴とする請求項1に記載の情報処理装置。
【請求項7】
前記制御部は、
前記抽出動画データを生成した後、生成した前記抽出動画データへのメタ情報の付与を、前記抽出動画データに対応する前記リクエストの投稿者に許可し、前記リクエストの投稿者から前記メタ情報の付与を受け付ける機能を備える
ことを特徴とする請求項1に記載の情報処理装置。
【請求項8】
前記制御部は、
前記抽出動画データに記録された動画を視聴可能な状態を構築する機能と、
当該状態の構築に応じて、前記抽出動画データに対応する前記リクエストの投稿者、および、前記抽出動画データに対応する前記リクエストに前記肯定評価を付与した者に通知を行う機能とを備える
ことを特徴とする請求項5に記載の情報処理装置。
【請求項9】
請求項2から5の何れか1項に記載の情報処理装置と通信可能な端末であって、
前記リクエストに関する情報が前記優先順位に従って並んで配置された画面を提供する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項10】
請求項3に記載の情報処理装置と通信可能な端末であって、
前記リクエストの投稿に際して、前記リクエストに付与する前記ポイント値を入力するオブジェクトと、前記オブジェクトに入力された前記ポイント値が前記リクエストに付与された場合に前記リクエストの前記優先順位が何番目になるかを示す情報とが表示された画面を提供する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項11】
請求項3に記載の情報処理装置と通信可能な端末であって、
前記リクエストの投稿に際して、前記リクエストの前記優先順位が最も高くなる前記ポイント値を入力するボタンが表示された画面を提供する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項12】
請求項3に記載の情報処理装置と通信可能な端末であって、
前記リクエストの投稿に際して、前記リクエストを入力する入力欄、および、前記リクエストに付与する前記ポイント値を入力するオブジェクトが表示された画面を提供する機能と、
前記オブジェクトに入力された前記ポイント値の値が大きいほど前記入力欄に入力可能な文字数の上限を大きくする機能とを有する端末制御部を備える
ことを特徴とする端末。
【請求項13】
請求項4に記載の情報処理装置と通信可能な端末であって、
前記リクエストに関する情報が一覧表示されると共に、前記リクエストに関する情報と関連付けて前記リクエストに追加する追加ポイント値を入力するためのオブジェクトが表示された画面を提供する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項14】
前記端末制御部は、
前記オブジェクトに入力された前記追加ポイント値が前記リクエストに追加された場合に前記リクエストの前記優先順位が何番目になるかを示す情報が表示された画面を提供する機能を備える
ことを特徴とする請求項13に記載の端末。
【請求項15】
前記端末制御部は、
前記リクエストの前記優先順位が最も高くなる前記追加ポイント値を入力するボタンが表示された画面を提供する機能を備える
ことを特徴とする請求項13に記載の端末。
【請求項16】
請求項5に記載の情報処理装置と通信可能な端末であって、
前記リクエストに関する情報が一覧表示されると共に、前記リクエストに関する情報と関連付けて前記肯定評価を付与するためのオブジェクトが表示された画面を提供する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項17】
請求項1から8の何れか1項に記載の情報処理装置と通信可能な端末であって、
前記抽出動画データに記録された動画を、前記抽出動画データに対応する前記リクエストの内容と共に表示する機能を有する端末制御部を備える
ことを特徴とする端末。
【請求項18】
情報処理装置と、前記情報処理装置と通信可能な端末とを備える情報処理システムであって、
ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、
前記注目ユーザによるライブ配信中に前記リクエストに対するリプライの開始の指示と前記リプライの終了の指示とを受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの1つを前記ライブ配信の視聴者の前記端末に表示させる機能と、
前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成する機能とを備える
ことを特徴とする情報処理システム。
【請求項19】
情報処理装置の制御部が、ライブ配信の配信者となり得る注目ユーザによるライブ配信中に、前記注目ユーザに対して投稿されたリクエストへのリプライの開始の指示と前記リプライの終了の指示とを受け付け、前記リプライの開始の指示があった場合、前記リクエストのうちの1つを前記ライブ配信の視聴者の端末に表示させるステップと、
前記情報処理装置の前記制御部が、前記リプライの開始から終了までの期間の前記ライブ配信に係る動画が記録された抽出動画データを生成するステップとを含む
ことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ライブ配信に関する処理を実行可能な情報処理装置、当該情報処理装置と通信可能な端末、当該情報処理装置と当該端末とを備える情報処理システム、および、当該情報処理装置による情報処理方法に関する。
【背景技術】
【0002】
近年、ライブ配信に係るサービスを利用したライブ配信が広く行われている。ライブ配信の態様は色々とあるものの、1つの態様では、配信者(2人以上の人間が共同して配信者となる場合もある)と不特定の視聴者とが参加し、配信者側の端末(以下「配信者端末」という)で配信者の挙動が撮影されると共に、配信者端末の撮影結果に基づく動画がリアルタイムで視聴者側の端末(以下「視聴者端末」という)に配信される。以下では、単に「ライブ配信」と表現する場合、特に説明がない限り、このような態様のライブ配信であるものとする。そして従来、ライブ配信に係るサービスに関して、種々の技術が提案されている。例えば特許文献1には、ライブ配信中に、視聴者に関する有益な情報を含むアドバイス情報をリアルタイムで配信者に提供し、配信者を支援する技術が記載されている。また例えば特許文献2には、ライブ配信中に視聴者からの投票を受け付けると共に投票について抽選を行い、当選した投票に係る視聴者と配信者とが一対一で会話できるようにした技術が記載されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特許2022-075401号公報
【文献】特許2022-084214号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ライブ配信に係るサービスに関しては、配信者の満足度を向上することが常に求められている。配信者の満足度の向上を実現することにより、配信者となりたいユーザに対して、サービスを利用しようとするインセンティブを与えることができ、サービスを利用する配信者の増加、およびこれに伴う視聴者の増加につながるからである。
【0005】
本発明は、このような問題を解決するために成されたものであり、ライブ配信に係るサービスに関し、配信者の満足度を向上することを目的とする。
【課題を解決するための手段】
【0006】
上記した課題を解決するために、本発明は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの1つをライブ配信の視聴者の端末に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する。
【発明の効果】
【0007】
上記のように構成した本発明によれば、配信者は、ライブ配信中に、リプライの開始を指示し、当該指示に応じて視聴者の端末に表示されるリクエストにリプライし、リプライの完了後にリプライの終了を指示するという作業を行う。配信者によってこのような作業が行われることによって、配信者によって行われたリプライごとに、リプライを行った期間のライブ配信に係る動画が記録された抽出動画データが生成される。この抽出動画データに記録された動画は、1つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年ではライブ配信だけではなく、ライブ配信の一部を抽出した動画(「切抜き動画」と呼ばれることもある)が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。そして本発明によれば、このような利用価値の高い抽出動画データを生成するために、配信者は、ライブ配信全体の動画が記録された動画データを編集したり、抽出動画データの生成を他人に頼ったりする必要がなく、配信者の満足度を向上できる。すなわち本発明によれば、ライブ配信に係るサービスに関し、配信者の満足度を向上することができる。
【図面の簡単な説明】
【0008】
【
図1】本発明の一実施形態に係る情報処理システムの構成例を示す図である。
【
図2】本発明の一実施形態に係る端末および情報処理サーバの機能構成例を示すブロック図である。
【
図5】情報処理システムの動作例を示すフローチャートである。
【
図6】各種データベースのレコードの内容を示す図である。
【
図7】ライブ配信中の情報処理システムの処理を示す図である。
【
図8】情報処理システムの動作例を示すフローチャートである。
【
図12】情報処理システムの動作例を示すフローチャートである。
【
図13】リプライログデータの内容を示す図である。
【
図16】情報処理サーバの動作例を示すフローチャートである。
【
図17】抽出動画データを生成する処理の説明に利用する図である。
【
図18】情報処理システムの動作例を示すフローチャートである。
【
図19】特別視聴画面および通常視聴画面を示す図である
【
図20】通常ボックス画面および追加ポイント入力画面を示す図である。
【発明を実施するための形態】
【0009】
以下、本発明の一実施形態を図面に基づいて説明する。
図1は、本実施形態に係る情報処理システム1の構成例を示す図である。
図1で示すように情報処理システム1は、端末2と、情報処理サーバ3(情報処理装置)とを含んで構成されている。
図1では、無数に存在する端末2の一部を例示的に示している。端末2および情報処理サーバ3は共に、インターネット、電話網、その他の通信網を含むネットワークNに接続可能である。端末2と情報処理サーバ3とはネットワークNを介して通信可能である。
【0010】
本実施形態に係る情報処理システム1は、ライブ配信を実現する機能を有する。本実施形態においてライブ配信とは、配信者(2人以上の人間が共同して配信者となる場合もある)と不特定の視聴者とが参加し、配信者の端末2で配信者の挙動が撮影されると共に、配信者の端末2の撮影結果に基づく動画がリアルタイムで視聴者の端末2に配信されることを意味する。情報処理サーバ3は、ライブ配信に係るサービスを提供することによって、ライブ配信に係るプラットフォームを提供する。以下、情報処理サーバ3が提供するライブ配信に係るサービスを「本件サービス」という。なお本実施形態では、動画とは、視覚で認識する画像(静止画画像、動画像)と、聴覚で認識する音声との組合せを意味する。以下の説明では、本件サービスを利用し得る者を「ユーザ」という。ユーザは、本件サービスにアカウントを登録しており、自身のログイン情報(例えばログインIDとパスワードの組合せ)を利用して本件サービスのアカウントにログインすることができる。
【0011】
本実施形態ではユーザは、ライブ配信の配信者にも、視聴者にもなることができる。ただし以下では、説明の明確化および単純化のため、ユーザのうち配信者となり得るユーザの一人を「注目配信者」(注目ユーザ)と表現し、注目配信者に注目して配信者に関連する情報処理システム1の動作の説明を行う場合がある。注目配信者の端末2を配信者端末2Lとする。配信者端末2Lは、注目配信者の端末2を便宜的に示すものであり、配信者が専用的に使用する端末2を意味しない。また以下では、ユーザのうち視聴者となり得るユーザの一人を「注目視聴者」(ユーザ)と表現し、注目視聴者に注目して視聴者に関連する情報処理システム1の動作の説明を行う場合がある。注目視聴者の端末2を視聴者端末2Aとする。視聴者端末2Aは、注目視聴者の端末2を便宜的に示すものであり、視聴者が専用的に使用する端末2を意味しない。
【0012】
端末2は、情報処理機能、収音機能、撮影機能、放音機能、表示機能、入力を受け付ける機能、通信機能、その他のユーザが利用する端末2として必要な機能を備えていればよい。ただし視聴者の端末2については、収音機能および撮影機能は必ずしも必要ない。また端末2は、単一の装置である必要はなく、複数の装置が組み合わされて構成されていてもよい。端末2のタイプは例えば、スマートフォン、スマートフォン以外のタブレット端末、ノートパソコン、または、カメラが接続されたデスクトップパソコンである。
【0013】
情報処理サーバ3は、端末2をクライアントの1つとするサーバ装置である。上述したように情報処理サーバ3は、本件サービスを提供する。
図1および後述する
図2では、情報処理サーバ3を1つのブロックで表しているが、情報処理サーバ3は単一のサーバ装置である必要はない。例えば情報処理サーバ3は、複数のサーバ装置により構成されてもよく、また所定のシステムの一部であってもよい。
【0014】
図2の(A)は、端末2および情報処理サーバ3の機能構成例を示すブロック図である。
図2の(A)で示すように端末2は、端末制御装置5を備えている。端末制御装置5は機能構成として、端末制御部6と、端末通信部7とを備えている。また端末制御装置5は記憶手段として、端末記憶部8を備えている。また端末2において、端末制御部6には、収音機能を有するマイク9と、撮影機能を有するカメラ10と、放音機能を有するスピーカ11と、表示機能を有する表示装置12と、入力を受け付ける機能を有する入力装置13とが接続されている。
図2の(A)で示すように情報処理サーバ3は機能構成として、サーバ制御部14と、サーバ通信部15とを備えている。また情報処理サーバ3は記憶手段として、サーバ記憶部16を備えている。
【0015】
上記機能ブロック6、7、14、15は、ハードウェア、DSP(Digital signal Processor)、ソフトウェアの何れによっても構成することが可能である。例えばソフトウェアによって構成する場合、上記機能ブロック6、7、14、15は、実際にはコンピュータのCPU、RAM、ROM等を備えて構成され、RAMやROM、ハードディスクまたは半導体メモリ等の記録媒体に記憶されたプログラムが動作することによって実現される。
【0016】
端末通信部7は、ネットワークNに接続された機器と所定のプロトコルに従って通信する。以下の説明では端末2とネットワークNに接続された機器との間での通信は、端末通信部7により適切に行われるものとして詳細な説明を省略する。サーバ通信部15は、ネットワークNに接続された機器と所定のプロトコルに従って通信する。以下の説明では情報処理サーバ3とネットワークNに接続された機器との間での通信は、サーバ通信部15により適切に行われるものとして詳細な説明を省略する。
【0017】
図2の(A)で示すように端末2には、本件サービスに関する専用のアプリケーション17(以下「専用アプリ17」という)がインストールされている。専用アプリ17は、本件サービスに関する画面(以下「本件サービス画面」という)の提供、情報処理サーバ3との各種情報のやり取り、その他の本件サービスに関する処理を実行する機能が実装された専用のアプリケーションである。本件サービスに関連する処理について、端末制御部6は基本的には、専用アプリ17(端末2のOS、専用アプリ17が利用可能なWebアプリ、その他の専用アプリ17と連携可能な他のプログラムを含む)の機能を利用して処理を実行する。なお特に説明しない場合であっても、端末2の端末制御部6は、何らかの処理を実行する際、必要に応じて情報処理サーバ3のサーバ制御部14と通信し、サーバ制御部14から必要な情報の応答を要求して当該情報を取得し、或いはサーバ制御部14に必要な処理を依頼して処理結果を取得する。情報処理サーバ3には端末制御部6に提供する情報が不足なく記憶されている。またサーバ制御部14は、端末制御部6からの依頼に応じて処理を実行する機能が実装されている。
【0018】
図2の(B)の(B1)は配信者端末2Lの機能構成例を示すブロック図である。
図2の(B)の(B1)で示すように配信者端末2Lは、端末制御装置5L、マイク9L、カメラ10L、スピーカ11L、表示装置12Lおよび入力装置13Lを備えている。端末制御装置5Lは、端末制御部6L、端末通信部7Lおよび端末記憶部8Lを備えている。
図2の(B)の(B2)は視聴者端末2Aの機能構成例を示すブロック図である。
図2の(B)の(B2)で示すように視聴者端末2Aは、端末制御装置5A、マイク9A、カメラ10A、スピーカ11A、表示装置12Aおよび入力装置13Aを備えている。端末制御装置5Aは、端末制御部6A、端末通信部7Aおよび端末記憶部8Aを備えている。
【0019】
次に情報処理システム1の動作についてシーンに分けて説明する。以下では説明の便宜のため、配信者端末2Lおよび視聴者端末2Aのタイプは、スマートフォンであるものとする。スマートフォンは、タブレット型の筐体を備え、当該筐体の前面の広い領域に表示パネルおよびタッチパネルが設けられ、当該筐体内に内蔵マイク、内蔵カメラおよび内蔵スピーカが設けられる。スマートフォンの内臓マイクがマイク9L、9Aとして機能し、内蔵カメラがカメラ10L、10Aとして機能し、内蔵スピーカがスピーカ11L、11Aとして機能し、表示パネルが表示装置12L、12Aとして機能し、タッチパネルが入力装置13L、13Aとして機能する。
【0020】
<ライブ配信時の基本的な動作>
まず注目配信者がライブ配信を行い、注目視聴者がそれを視聴するときの情報処理システム1の基本的な動作について説明する。以下では、まずライブ配信中に配信者端末2Lおよび視聴者端末2Aに表示される画面について説明した後、情報処理システム1の動作について説明する。
【0021】
図3は、ライブ配信中に配信者端末2Lに表示される配信者側画面20を示す図である。
図3で示すように配信者側画面20には、カメラ10Lの撮影結果に基づく動画像である撮影動画像21が背景として表示される。配信者側画面20の中央に対してやや左下の領域には、コメント一覧領域22が設けられている。後述するようにコメント一覧領域22には、視聴者が投稿したコメントに対応するコメント個別画像23がリアルタイムで表示される。コメント一覧領域22の下方にはリプライ開始ボタン24が設けられており、リプライ開始ボタン24の右方にはリクエストボックス確認ボタン25が設けられている。リプライ開始ボタン24およびリクエストボックス確認ボタン25に関連する事項については後述する。また配信者側画面20の左上部には、配信者プロフィール画像26が表示される。配信者プロフィール画像26には、配信者のアイコン画像と配信者のユーザ名とが表示される。配信者プロフィール画像26の右方には、終了ボタン27が設けられている。終了ボタン27は配信者がライブ配信を終了するときに選択されるボタンである。
【0022】
図4は、ライブ配信中に視聴者端末2Aに表示される視聴者側画面29を示す図である。
図4で示すように視聴者側画面29には、配信者側画面20と同様、背景として撮影動画像21が表示され、撮影動画像21上にコメント一覧領域22、配信者プロフィール画像26および終了ボタン30が設けられる。終了ボタン30は、ライブ配信の視聴を終了するときに選択されるボタンである。一方、視聴者側画面29には、リプライ開始ボタン24およびリクエストボックス確認ボタン25が設けられておらず、代わりにコメント入力欄31、コメント送信ボタン32およびリクエスト関連ボタン33が設けられている。コメント入力欄31、コメント送信ボタン32およびリクエスト関連ボタン33に関連する事項については後述する。なお例示した配信者側画面20および視聴者側画面29は単純化したものである。配信者側画面20および視聴者側画面29の内容が例示する内容に限定されないことは当然である。
【0023】
図5は、ライブ配信中の配信者端末2L、情報処理サーバ3および視聴者端末2Aによる情報処理方法を示すフローチャートである。フローチャートFAは配信者端末2Lによる情報処理方法を示し、フローチャートFBは情報処理サーバ3による情報処理方法を示し、フローチャートFCは視聴者端末2Aによる情報処理方法を示す。
【0024】
ライブ配信に際して、注目配信者は、配信者端末2Lの専用アプリ17を起動する。注目配信者は、端末制御部6Lが表示装置12Lに表示する本件サービス画面を利用して、本件サービスのアカウントにログインする。ログインがセキュアに自動で行われる構成でもよい。注目配信者は、必要な作業を行って自身が配信者としてライブ配信する準備を整える。フローチャートFAで示すように注目配信者は、本件サービス画面を利用してライブ配信の開始を指示する(ステップSA1)。端末制御部6Lは、この指示を検出し、サーバ制御部14に、ライブ配信の開始を通知する(ステップSA2)。以下、ここで開始されたライブ配信を「注目ライブ配信」といい、ライブ配信一般と区別する。
【0025】
フローチャートFBで示すように情報処理サーバ3のサーバ制御部14は、注目ライブ配信の開始の通知を受信すると、注目ライブ配信が開始されたタイミングを起点とした経過時間の計測を開始する(ステップSB1)。更にサーバ制御部14は、サーバ記憶部16に記憶されたライブ配信管理データベース35に、注目ライブ配信に対応するレコードを追加し、注目ライブ配信の管理を開始する(ステップSB2)。ライブ配信管理データベース35は、ライブ配信のそれぞれを管理するデータベースであり、ライブ配信ごとにレコードが登録される。
図6(A)は、ライブ配信管理データベース35の1件のレコードの内容を示している。
図6(A)で示すように、ライブ配信管理データベース35の1件のレコードは、フィールドとしてライブ配信ID<フィールド>と、配信者ID<フィールド>と、視聴者ID<フィールド>と、リプライログ<フィールド>と、ライブ配信全体動画<フィールド>とを含んでいる。
【0026】
ライブ配信ID<フィールド>には、対応するライブ配信を一意に識別するための識別情報であるライブ配信IDが格納される。配信者ID<フィールド>には、対応するライブ配信の配信者のユーザIDが格納される。ユーザIDとは、本件サービスのユーザ(アカウント)を一意に識別するための識別情報である。視聴者ID<フィールド>には、対応するライブ配信の視聴者のユーザIDが格納される。視聴者が複数いる場合には、複数のそれぞれの視聴者のユーザIDが格納される。リプライログ<フィールド>には、リプライログデータ34が記録される。リプライログデータ34に関する事項ついては後述する。ライブ配信全体動画<フィールド>には、対応するライブ配信が完了した後に、ライブ配信全体動画データが格納される。ライブ配信全体動画データは、対応するライブ配信の全体(=ライブ配信の開始から終了まで)の動画が記録された動画データ(動画ファイル)である。ライブ配信全体動画データに関する事項については後述する。
【0027】
ステップSB2においてサーバ制御部14は、一意な値のライブ配信IDを生成し、追加するレコードのライブ配信ID<フィールド>に格納する。またサーバ制御部14は、配信者ID<フィールド>に注目配信者のユーザIDを格納し、視聴者ID<フィールド>にヌル値を格納し、リプライログ<フィールド>に初期値のリプライログデータ34を格納し、ライブ配信全体動画<フィールド>にヌル値を格納する。
【0028】
一方、注目視聴者は、視聴者端末2Aの専用アプリ17を起動する。注目視聴者は、端末制御部6Aが提供する本件サービス画面を利用して、本件サービスのアカウントにログインする。ログインがセキュアに自動で行われる構成でもよい。フローチャートFCで示すように注目視聴者は、本件サービス画面を利用して注目ライブ配信の視聴の開始を指示する(ステップSC1)。視聴者端末2Aの端末制御部6Aは、この指示を検出し、サーバ制御部14に、注目ライブ配信の視聴の開始を通知する(ステップSC2)。
【0029】
フローチャートFBで示すようにサーバ制御部14は、注目ライブ配信の視聴の開始の通知を受信すると、ライブ配信管理データベース35の注目ライブ配信に対応するレコードの視聴者ID<フィールド>に、注目視聴者のユーザIDを追加的に格納する(ステップSB3)。なお注目ライブ配信に係る視聴者ID<フィールド>は、現時点の注目ライブ配信の視聴者を管理するフィールドである。つまり、ある視聴者が注目ライブ配信の視聴を開始すると、その視聴者のユーザIDが視聴者ID<フィールド>に格納される。詳細は省略するが、サーバ制御部14は、ある視聴者が注目ライブ配信の視聴を停止した場合、そのことを検出し、視聴者ID<フィールド>からその視聴者のユーザIDを削除する。
【0030】
なお視聴者によるライブ配信の視聴の開始の指示は、様々な方法で行われ得る。例えば本件サービスでは、一のユーザが別のユーザをフォローすることが可能である。そして当該別のユーザがライブ配信を開始すると、当該一のユーザに対して提供される所定の本件サービス画面に、当該別のユーザがライブ配信を開始したことを明示するボタンが表示される。当該一のユーザ(視聴者)は、このボタンを選択することによって、当該他のユーザ(配信者)によるライブ配信の視聴の開始を指示することができる。また例えば本件サービスでは、視聴者は、実施中のライブ配信の一覧が表示された本件サービス画面を表示装置12に表示させることができる。そして視聴者は、一覧の中から1つのライブ配信を選択することによって、ライブ配信の視聴の開始を指示することができる。また例えば本件サービスでは、視聴者は、一のライブ配信を視聴中に、画面に対するスクロール操作、その他の所定の操作をすることによって、視聴するライブ配信を当該一のライブ配信から、実施中の他のライブ配信に切り替えることができる。当該他のライブ配信はランダムに決定される構成でもよく、何らかのルールに基づいて決定される構成でもよい。ユーザは、視聴するライブ配信を当該他のライブ配信に切り替える操作を行うことによって、当該他のライブ配信の視聴の開始を指示することができる。以上、視聴者がライブ配信の視聴の開始を指示する方法について複数の例を挙げたが、当該方法が当該複数の例に限られないことは勿論である。
【0031】
ライブ配信中は、配信者端末2L、情報処理サーバ3および視聴者端末2Aにより以下の処理が行われてライブ配信が実現される。
図7は、ライブ配信中の情報処理システム1の動作を、各装置の処理に注目して説明に適した態様で示す図である。
図7で示すようにライブ配信中は、配信者端末2Lのカメラ10Lによる撮影およびマイク9Lによる収音が継続して行われる。配信者端末2Lの端末制御部6Lは、撮影結果に基づく信号をカメラ10Lから入力し、画像データD1を生成すると共に、収音結果に基づく信号をマイク9Lから入力し、音声データD2を生成する(プロセスPA1)。端末制御部6Lは、顔加工、フィルタを利用した加工、デコレーション加工、その他の加工を動画像に施すための画像処理を画像データD1に施してライブ配信動画像データD3を生成する(プロセスPA2)。なお詳細は省略するが、動画像に対してどのような加工を施すかについては事前に注目配信者により指定される。また端末制御部6Lは、音声データD2に対して必要な音声処理を施してライブ配信音声データD4を生成する(プロセスPA2)。
【0032】
端末制御部6Lは、ライブ配信動画像データD3およびライブ配信音声データD4についてプロトコルに従ってエンコード、圧縮、コンテナへの格納、その他の必要な処理を施してライブ配信データD5を生成し、プロトコルに従ってライブ配信データD5を情報処理サーバ3に送信する(プロセスPA3)。なお利用されるプロトコルは例えば、「HTTP Live Streaming」または「Real Time Messaging Protocol」である(当然、これら以外のプロトコルであってもよい)。
【0033】
また端末制御部6Lは、ライブ配信動画像データD3に対して付加画像を付加する処理を施して配信者側画面データD6を生成する(プロセスPA4)。付加画像は、配信者側画面20において撮影動画像21に付加される画像である。
図3で示すように付加画像は、コメント個別画像23、リプライ開始ボタン24、リクエストボックス確認ボタン25、配信者プロフィール画像26および終了ボタン27を含む。端末制御部6Lは、生成した配信者側画面データD6に基づいて表示装置12Lを駆動し、表示装置12Lに配信者側画面20を表示する(プロセスPA5)。また端末制御部6Lは、ライブ配信音声データD4に基づいてスピーカ11Lを駆動し音声を放音する(プロセスPA5)。配信者側画面20の表示中の撮影動画像21と音声との同期は、端末制御部6Lにより適切に行われる。
【0034】
ライブ配信中、情報処理サーバ3のサーバ制御部14は、配信者端末2Lからライブ配信データD5を継続して受信する(プロセスPB1)。サーバ制御部14は、必要に応じてライブ配信管理データベース35およびユーザ管理データベース36を参照した上で、ライブ配信データD5をプロトコルに従って視聴者端末2Aに送信する(プロセスPB2)。
【0035】
ユーザ管理データベース36とは、ユーザ(アカウント)を管理するためのデータベースであり、ユーザごとにレコードが登録されている。
図6(B)は、ユーザ管理データベース36の1件のレコードの内容を示している。
図6(B)で示すように、ユーザ管理データベース36の1件のレコードは、フィールドとしてユーザID<フィールド>と、ユーザ名<フィールド>と、アイコン<フィールド>と、ポイント残高<フィールド>と、獲得ポイント合計<フィールド>を含んでいる。ユーザID<フィールド>には、対応するユーザのユーザIDが格納される。ユーザ名<フィールド>には、対応するユーザのユーザ名を示すユーザ名情報が格納される。アイコン<フィールド>には、対応するユーザのアイコンの画像データであるアイコン画像データが格納される。ポイント残高<フィールド>には、対応するユーザの本件ポイント(ポイント)の残高を示す値(以下「ポイント残高値」という)が格納される。本件ポイントとは、本件サービスにおいて使用可能なポイントである。本件ポイントの単位は「pt」とする。ユーザは、購入、キャンペーンによる付与、その他の手段によって本件ポイントを取得することができる。獲得ポイント合計<フィールド>には獲得ポイント値を合計した獲得ポイント合計値が格納される。獲得ポイント値に関連する事項については後述する。なおユーザ管理データベース36のレコードの内容は単純化したものである。レコードには、ユーザの連絡先に関する情報(メールアドレス等)、ログイン情報、決済手段に関する情報、その他のユーザに関する各種情報が含まれている。
【0036】
更にサーバ制御部14は、受信したライブ配信データD5について、プロトコルに従ってコンテナからの取り出し、解凍、デコード、その他の必要な処理を施してライブ配信動画像データD3およびライブ配信音声データD4を生成する(プロセスPB3)。サーバ制御部14は、生成したライブ配信動画像データD3およびライブ配信音声データD4を、累積的にサーバ記憶部16にバッファリングする(プロセスPB4)。
【0037】
ライブ配信中、視聴者端末2Aの端末制御部6Aは、ライブ配信データD5を継続して受信する(プロセスPC1)。端末制御部6Aは、ライブ配信データD5について、プロトコルに従ってコンテナからの取り出し、解凍、デコード、その他の必要な処理を施してライブ配信動画像データD3およびライブ配信音声データD4を生成する(プロセスPC2)。端末制御部6Aは、付加画像を付加する処理をライブ配信動画像データD3に施して視聴者側画面データD7を生成する(プロセスPC3)。付加画像は、視聴者側画面29において撮影動画像21に付加される画像である。
図4で示すように付加画像は、コメント個別画像23、コメント入力欄31、コメント送信ボタン32、リクエスト関連ボタン33、配信者プロフィール画像26および終了ボタン30を含む。そして端末制御部6Aは、生成した視聴者側画面データD7に基づいて表示装置12Aを駆動し、表示装置12Aに視聴者側画面29を表示する(プロセスPC4)。また端末制御部6Aは、ライブ配信音声データD4に基づいてスピーカ11Aを駆動し音声を放音する(プロセスPC4)。視聴者側画面29Aの表示中の撮影動画像21と音声との同期は、端末制御部6Aにより適切に行われる。
【0038】
以上、ライブ配信を実現する情報処理システム1の動作例を説明したが、情報処理システム1の動作は例示した動作に限られるものではない。すなわちライブ配信が実現されれば情報処理システム1によりどのような動作が行われてもよい。また情報処理システム1の動作にはライブ配信の実現に関する既存の技術を全て利用できる。以下の説明では、ライブ配信中は、
図7を用いて説明した方法により適切にライブ配信が実現されているものとし、ライブ配信を実現するための処理については詳細な説明を省略する。
【0039】
さて
図5に戻り、フローチャートFAで示すように注目配信者は、ライブ配信を終了する場合、配信者側画面20の終了ボタン27を選択する(ステップSA3)。終了ボタン27が選択されたことを検出すると端末制御部6Lは、ライブ配信の終了を情報処理サーバ3に通知する(ステップSA4)。
【0040】
フローチャートFBで示すようにサーバ制御部14は、ライブ配信の終了の通知を受信すると、経過時間の計測を終了する(ステップSB4)。次いでサーバ制御部14は、サーバ記憶部16にバッファリングしたライブ配信動画像データD3およびライブ配信音声データD4に基づいて、所定のファイル形式のライブ配信全体動画データを生成する(ステップSB5)。ライブ配信全体動画データは、注目ライブ配信の全体(開始から終了まで)の動画が記録された動画データ(動画ファイル)である。次いでサーバ制御部14は、生成したライブ配信全体動画データを、ライブ配信管理データベース35の注目ライブ配信に対応するレコードのライブ配信全体動画<フィールド>に格納する(ステップSB6)。
【0041】
以上がライブ配信中の情報処理システム1の基本的な動作である。ただし、説明した情報処理システム1の動作はあくまで単純化した一例であり、目的が達成されるのであれば、情報処理システム1の各装置において異なる処理が行われてもよい。例えば、ライブ配信全体動画データが以下の方法で生成される構成でもよい。すなわち、情報処理サーバ3とは異なる専用の装置によってライブ配信に関するデータを受信し、当該専用の装置によってライブ配信全体動画データが生成される構成でもよい。
【0042】
<注目視聴者によりコメントが投稿される場合の処理>
次にライブ配信中に注目視聴者によりコメントが投稿されるときの情報処理システム1の動作について簡単に説明する。なお本実施形態において、コメントは、後述するリクエストとは異なる概念であり、これらは明確に区別される。
【0043】
コメントを投稿する場合、注目視聴者は、視聴者側画面29(
図4)のコメント入力欄31にコメントを入力し、コメント送信ボタン32を選択する。なおコメントおよび後述するリクエストは、文字(使用可能なオブジェクトを全て含む概念であり、例えば絵文字を含む)によって構成される。視聴者端末2Aの端末制御部6Aは、コメント送信ボタン32が選択されたことを検出すると、入力されたコメントに関する情報および注目視聴者に関する情報を情報処理サーバ3に送信する。
【0044】
情報処理サーバ3のサーバ制御部14は、情報を受信し、注目ライブ配信に対応するコメント管理データベース37に、コメントおよび注目視聴者に関する各種情報を含むレコードを追加する。なおコメント管理データベース37は、ライブ配信中に投稿されたコメントを管理するデータベースであり、ライブ配信ごとに存在する。次いでサーバ制御部14は、ユーザ管理データベース36、その他のデータを参照し、コメント個別画像23(
図3、4参照)の表示に必要な情報を含むコメント表示情報を生成する。次いでサーバ制御部14は、配信者端末2Lおよび視聴者端末2Aにコメント表示情報を送信する。なおコメント表示情報は、配信者端末2Lおよび視聴者端末2Aだけでなく、注目ライブ配信を視聴中の全ての視聴者の端末2に送信される。
【0045】
配信者端末2Lの端末制御部6Lは、コメント表示情報を受信すると、配信者側画面20のコメント一覧領域22に、ルールに従った態様でコメント個別画像23を追加的に表示する。
図3で示すようにコメント個別画像23には、注目視聴者(本例においてコメントを投稿した視聴者)のユーザ名およびアイコン画像と、コメントの内容とが含まれる。なおルールは、コメント一覧領域22内で既存のコメント個別画像23を上方にずらし、コメント一覧領域22内に入りきらなくなった既存のコメント個別画像23については削除した上で、コメント一覧領域22の末尾に新たなコメント個別画像23を表示する、というルールである。ただしコメント一覧領域22に入りきらなくなったコメント個別画像23について、一定量だけ、コメント一覧領域22に対するスクロール操作によって視聴可能な状態とするようにしてもよい。同様に視聴者端末2Aの端末制御部6Aは、コメント表示情報を受信すると、視聴者側画面29のコメント一覧領域22に、ルールに従った態様でコメント個別画像23を追加的に表示する。
【0046】
このように本実施形態では、視聴者によるコメントの投稿に応じて、リアルタイムで配信者および視聴者の端末2に表示される。
【0047】
<注目視聴者によりリクエストが投稿される場合の処理>
次にライブ配信中に注目視聴者によりリクエストが投稿されるときの情報処理システム1の動作について説明する。
図8は、注目視聴者によりリクエストが投稿される場合における情報処理サーバ3および視聴者端末2Aによる情報処理方法を示すフローチャートである。フローチャートFDは情報処理サーバ3による情報処理方法を示し、フローチャートFEは視聴者端末2Aによる情報処理方法を示す。
【0048】
リクエストとは、配信者によるリプライを期待して行われる要求である。例えばリクエストは、配信者に対する質問であり、また例えば配信者に何らかのアクションを行うことを要望するものである。リプライとは、ユーザからのリクエストに対して配信者が行う応答全般を意味する。例えばリプライは、リクエストに係る質問に対して回答する一連の行為であり、また例えばリクエストに係る要望に対応して行うアクションである。後に明らかとなる通りリクエストは、投稿に応じてリアルタイムで配信者側画面20に表示されることはなく、この点でコメントと異なっている。また後に明らかとなる通り所定の場合には、1つのリクエストに対して配信者が独占的にリプライすることになる。
【0049】
フローチャートFEで示すようにリクエストを投稿する場合、注目視聴者は、視聴者側画面29のリクエスト関連ボタン33を選択する(ステップSE1)。リクエスト関連ボタン33が選択されると、視聴者端末2Aの端末制御部6Aは、情報処理サーバ3のサーバ制御部14と協働して、表示装置12Aに通常ボックス画面38(
図9)をポップアップ表示する(ステップSE2)。以下、ステップSE2の処理について詳述する。
【0050】
ステップSE2において端末制御部6Aは、リクエスト関連ボタン33が選択されたことをサーバ制御部14に通知する。サーバ制御部14は、当該通知を受信すると、注目配信者に対応するリクエスト管理データベース40を参照する。ここで本件サービスでは、各ユーザは、自身以外のユーザに対してリクエストを投稿することができる。そしてリクエスト管理データベース40は、ユーザごとに存在し、各ユーザに対して投稿されたリクエストを管理する。つま、あるユーザに対応するリクエスト管理データベース40は、そのユーザに対して投稿されたリクエストを管理する。また、あるユーザに対応するリクエスト管理データベース40には、そのユーザに対して投稿されたリクエストごとにレコードが登録される。
【0051】
図6(C)は、リクエスト管理データベース40の1件のレコードの内容を示している。
図6(C)で示すようにリクエスト管理データベース40の1件のレコードはフィールドとして、リクエストID<フィールド>と、投稿者ID<フィールド>と、リクエスト投稿日時<フィールド>と、リクエスト内容<フィールド>と、付与ポイント<フィールド>と、リプライ済フラグ<フィールド>と、肯定評価数<フィールド>と、肯定評価付与者<フィールド>と、リプライ優先順位<フィールド>とを含んでいる。
【0052】
リクエストID<フィールド>には、対応するリクエストを一意に識別するための識別情報であるリクエストIDが格納される。投稿者ID<フィールド>には、対応するリクエストを投稿したユーザのユーザIDが格納される。以下、リクエストを投稿したユーザを「リクエスト投稿者」という場合がある。リクエスト投稿日時<フィールド>には、リクエストが投稿された日時を示すリクエスト投稿日時情報が格納される。リクエスト内容<フィールド>には、リクエストの内容を示すリクエスト内容情報が格納される。付与ポイント情報<フィールド>には、対応するリクエストに付与された本件ポイントの値を示す付与ポイント値が格納される。付与ポイント値に関する事項については後述する。リプライ済フラグ<フィールド>には、対応するリクエストについて、リクエストを受けたユーザがリプライを行ったか否かを示すフラグであるリプライ済フラグが格納される。リプライ済フラグはオン値のときにリプライが既に行われたことを示し、オフ値のときにリプライが未だ行われていないことを示す。肯定評価数<フィールド>は、対応するリクエストに付与された肯定評価の個数(累積数)を示す値(以下「肯定評価数」という)が格納される。肯定評価に関する事項については後述する。肯定評価付与者<フィールド>には、対応するリクエストについて、肯定評価を付与したユーザ(以下「肯定評価付与者」という)のそれぞれのユーザIDが格納される。リプライ優先順位<フィールド>には、対応するリクエストのリプライ優先順位を示すリプライ優先順位情報が格納される。
【0053】
以下、リプライ優先順位に関する事項について説明する。サーバ制御部14は、適宜、リクエスト管理データベース40の各レコードのリプライ優先順位情報を以下の方法で更新する。なお本実施形態ではリプライ優先順位は、最上位から順番に、1番、2番、3番・・・というように表現されるものとする。すなわちサーバ制御部14は、リクエスト管理データベース40に登録されているレコードのうち、リプライ済フラグがオフ値のレコード(=リクエストを受けたユーザによるリプライが未だ行われていないリクエストに対応するレコード)を特定する。以下、リプライが行われていないリクエスト(=リプライ済フラグがオフ値のレコードに対応するリクエスト)を「未応答リクエスト」という。次いでサーバ制御部14は、未応答リクエストの全てを対象として、付与ポイント値が高いほどリプライ優先順位が高くなり、また付与ポイント値が同じであれば肯定評価数が多いほどリプライ優先順位が高くなり、また付与ポイント値が同じでありかつ肯定評価数が同じであればリクエスト投稿日時が時間的に古いほどリプライ優先順位が高くなるように、リプライ優先順位を設定する。
【0054】
例えば未応答リクエストR1の付与ポイント値が「3,000pt」であり、未応答リクエストR2の付与ポイント値が「5,000pt」であったとする。この場合、サーバ制御部14は、未応答リクエストR2のリプライ優先順位を未応答リクエストR1のリプライ優先順位よりも高くする。また例えば、未応答リクエストR3と未応答リクエストR4との付与ポイントが同じである一方、未応答リクエストR3の肯定評価数が、未応答リクエストR4の肯定評価数よりも多いとする。この場合、サーバ制御部14は、未応答リクエストR3のリプライ優先順位を未応答リクエストR4のリプライ優先順位よりも高くする。サーバ制御部14は、未応答リクエストを対象として行った優先順位付けに従って、未応答リクエストのそれぞれに対応するレコードのそれぞれについて、リプライ優先順位<フィールド>に格納されたリプライ優先順位情報を更新する。サーバ制御部14は、リプライ済フラグがオン値のレコード(=リクエストを受けたユーザによるリプライが既に行われたリクエストに対応するレコード)のリプライ優先順位情報についてはヌル値とする。
【0055】
なおサーバ制御部14は、リクエスト管理データベース40の各レコードのリプライ優先順位情報の更新を、リプライ優先順位に変更が生じ得る要因が発生したタイミングで実行する。リプライ優先順位に変更が生じ得る要因が発生したタイミングは例えば、レコードが追加されるタイミング、レコードが削除されるタイミングまたは何れかのレコードについてリプライ済フラグがオフ値からオン値になったタイミングである。
【0056】
以上の通りサーバ制御部14(制御部)は、付与ポイント値(付与されたポイント値)が大きいほどリプライ優先順位(優先順位)が高くなるように、未応答リクエストについてリプライ優先順位を設定する機能を備える。またサーバ制御部14は、付与ポイント値が大きいほど、かつ付与ポイント値が同じであれば付与された肯定評価の個数が多いほどリプライ優先順位が高くなるように、未応答リクエストについてリプライ優先順位を設定する機能を備える。
【0057】
さてサーバ制御部14は、注目配信者に対応するリクエスト管理データベース40を参照し、未応答リクエストのそれぞれについて、表示用リクエスト情報を生成する。一の未応答リクエストに対応する表示用リクエスト情報は、当該一の未応答リクエストの投稿者のユーザ名およびアイコン画像データ、リクエスト内容情報、付与ポイント値、肯定評価数、その他のリクエストカード44(後述)の表示のために必要な情報を含む。サーバ制御部14は、未応答リクエストのそれぞれについて、リクエスト管理データベース40およびユーザ管理データベースに基づいて、これら情報を取得し、表示用リクエスト情報を生成する。次いでサーバ制御部14は、未応答リクエストのそれぞれの表示用リクエスト情報を、端末制御部6Aに送信する。端末制御部6Aは、受信した表示用リクエスト情報を利用して、通常ボックス画面38をポップアップ表示する。
【0058】
図9は、通常ボックス画面38の一例を示す図である。
図9で示すように通常ボックス画面38の上部には、現時点の未応答リクエストの個数を示す未応答リクエスト個数画像41が表示される。端末制御部6Aは、サーバ制御部14から受信した情報に基づいて未応答リクエストの個数をカウントし、未応答リクエスト個数画像41を表示する。通常ボックス画面38において未応答リクエスト個数画像41の下方には、リクエストカード一覧領域42Aが設けられ、リクエストカード一覧領域42Aの下方にはリクエスト作成ボタン43が設けられる。リクエストカード一覧領域42Aには、未応答リクエストごとに、リクエストカード44(リクエストに関する情報)が表示される。つまり通常ボックス画面38の1つのリクエストカード44は、1つの未応答リクエストに対応する。リクエストカード44は、対応するリクエスト投稿者のユーザ名を示す画像と、当該リクエスト投稿者のアイコンを示す画像とを含む。またリクエストカード44は、対応するリクエストの内容を示すリクエスト内容画像45と、対応するリクエストに付与された付与ポイント値を示す付与ポイント画像46とを含む。またリクエストカード44は、肯定評価オブジェクト47を含む。
【0059】
肯定評価オブジェクト47は、肯定評価数を示す情報を含む。上述の通り肯定評価数は、対応する未応答リクエストに対して行われた肯定評価の個数である。また肯定評価オブジェクト47は、ユーザ(本例では注目視聴者)が、肯定評価を付与しているか否かを示すマーク48を含む。当該マークは、ハート形であり、ユーザが肯定評価を付与している場合には所定の色で塗り潰され、付与していない場合には白抜きされた状態となる。端末制御部6Aは、リクエストカード44のそれぞれについて、ユーザが肯定評価を付与しているか否かをサーバ制御部14に問い合わせ、問い合わせに対する応答に基づいて、マーク48の塗り潰し/白抜きを制御する。
【0060】
また肯定評価オブジェクト47は、リクエストに対して肯定評価を付与するボタン、および肯定評価が付与されているときにそれを取り消すボタンとしても機能する。注目視聴者は、あるリクエストカード44に肯定評価を付与していないときに肯定評価オブジェクト47を選択することによって、そのリクエストカード44に対応するリクエストに肯定評価を付与することができる。注目視聴者により肯定評価オブジェクト47が選択されるとサーバ制御部14は、端末制御部6Aと協働して、注目配信者に対応するリクエスト管理データベース40の対応するレコードの肯定評価数をインクリメントする。更にサーバ制御部14は、対応するレコードの肯定評価付与者<フィールド>に注目配信者のユーザIDを追加する。また注目視聴者は、あるリクエストカード44に肯定評価を付与しているときに肯定評価オブジェクト47を選択することによって、そのリクエストカード44に対応するリクエストに付与した肯定評価を取り消すことができる。注目視聴者によって肯定評価オブジェクト47が選択されるとサーバ制御部14は、端末制御部6Aと協働して、対応するレコードの肯定評価数をデクリメントする。更にサーバ制御部14は、対応するレコードの肯定評価付与者<フィールド>から注目配信者のユーザIDを削除する。
【0061】
このようにサーバ制御部14は、ユーザがリクエストに対して肯定評価を付与したときに、そのことを検出すると共に、リクエスト管理データベース40への反映、その他の肯定評価の付与を反映するための処理を実行する機能を備える。当該機能は、リクエストに対する肯定評価の付与を受け付ける機能に相当する。
【0062】
端末制御部6Aは、リクエストカード44を、対応する表示用リクエスト情報に基づいて表示する。また端末制御部6Aは、リクエストカード44のリクエストの内容および付与ポイント値が表示されるブロックについて、背景の色を以下の通り変化させる。すなわち端末制御部6Aは、付与ポイント値が2000pt未満のときは背景の色を「白色」とし、付与ポイント値が2000pt以上5000pt未満のときは背景の色を「黄色」とし、付与ポイント値が5000pt以上のときは背景の色を「赤色」とする。リクエストカード一覧領域42Aは、スクロール可能に構成されている。視聴者は、リクエストカード一覧領域42Aをスクロールすることによって、全てのリクエストカード44を表示させることが可能である。端末制御部6Aは、リクエストカード一覧領域42A内で、リクエストカード44をリプライ優先順位に従って、上から順番に並べて配置する。端末制御部6Aは、リクエストカード44のそれぞれのリプライ優先順位について、サーバ制御部14に問い合わせることによって認識する。このようにリプライ優先順位が高いリクエストカード44ほど、リクエストカード一覧領域42Aにおいて上方に表示される。注目視聴者は、リクエストカード一覧領域42Aを参照することにより、未対応リクエストのそれぞれについて、リクエストの内容、リクエスト投稿者に関する事項、付与ポイント値、肯定評価に関する事項を認識することができる。
【0063】
後に明らかとなるようにリプライ優先順位が高いリクエストほど、つまりリクエストカード一覧領域42A内で上方に表示されたリクエストカード44のリクエストほど、より早い段階でリクエストを受けたユーザによるリプライの対象となる。そして付与ポイント値が高いほどリプライ優先順位が高くなり、付与ポイント値が同じであれば、肯定評価数が多いほどリプライ優先順位が高くなる。これを踏まえ注目視聴者は、リクエストカード44のうち、より早い段階で配信者にリプライして欲しいと考えるものについて肯定評価を付与するインセンティブを持つ。
【0064】
以上の通り端末制御部6Aは、リクエストカード44(リクエストに関する情報)がリプライ優先順位(優先順位)に従って並んで配置された通常ボックス画面38(画面)を提供する機能を備える。また端末制御部6Aは、リクエストカード44が一覧表示されると共に、リクエストカード44と関連付けて肯定評価オブジェクト47(肯定評価を付与するためのオブジェクト)が表示された通常ボックス画面38(画面)を提供する機能を備える。
【0065】
さてフローチャートFEで示すようにリクエストを投稿しようと考える注目視聴者は、通常ボックス画面38を参照した上で、リクエスト作成ボタン43を選択する(ステップSE3)。リクエスト作成ボタン43が選択されたことを検出すると端末制御部6Aはサーバ制御部14と協働し、通常ボックス画面38に代えて、リクエスト入力画面50(
図10)を表示装置12Aにポップアップ表示する(ステップSE4)。
図10は、リクエスト入力画面50の一例を示す図である。
図10で示すように、リクエスト入力画面50の上部には、リクエスト入力欄51が設けられている。リクエスト入力欄51は、文字によって構成されるリクエストが入力される欄である。端末制御部6Aは、リクエスト入力欄51が選択されると、ソフトウェアキーボードを表示する。注目視聴者は、ソフトウェアキーボードを利用して、リクエスト入力欄51にリクエストを入力できる。なおリクエスト入力欄51に限らず、入力欄への入力時には、端末制御部6によりソフトウェアキーボードが表示される。
【0066】
リクエスト入力画面50においてリクエスト入力欄51の下方には、ポイント残高画像52が表示される。端末制御部6Aは、サーバ制御部14に注目視聴者のポイント残高値を問い合わせ、問い合わせに対する応答に基づいてポイント残高画像52を表示する。ポイント残高画像52の右方には、ポイント取得ボタン53が設けられる。ポイント取得ボタン53は、指定した量だけ本件ポイントを取得することによってポイント残高値を増やす場合に選択されるボタンである。ポイント取得ボタン53が選択されると端末制御部6Aは、サーバ制御部14と協働して、本件ポイントを取得するための画面を表示する。本件ポイントの取得は、購入、その他の手段によって行うことができる。注目視聴者は、当該画面を利用して、指定した量だけ本件ポイントを取得する。サーバ制御部14は、ユーザによる本件ポイントの取得に応じて、ユーザ管理データベース36の対応するレコードのポイント残高値を適切に増やす。なお本件ポイントが購入によって取得される場合、決済等は適切に実行される。
【0067】
リクエスト入力画面50においてポイント残高画像52の下方には、付与ポイント入力欄54が設けられ、付与ポイント入力欄54の下方には付与ポイントスライダ55が設けられ、付与ポイントスライダ55の下方には最高ポイント付与ボタン56が設けられている。付与ポイント入力欄54、付与ポイントスライダ55および最高ポイント付与ボタン56はそれぞれ、対応するリクエストに対して付与する付与ポイント値を入力するためのオブジェクトである。以下、これらを総称して「付与ポイント入力オブジェクト」という場合がある。
【0068】
付与ポイント入力欄54は、付与ポイント値をテキスト入力可能な入力欄である。付与ポイントスライダ55は、つまみ部をスライドさせることによって下限値(本実施形態では「0pt」)から上限値(本実施形態では「10,000pt」)の間で付与ポイント値を入力するためのスライダである。付与ポイント入力欄54と、付与ポイントスライダ55とは連動している。すなわち、ある値の付与ポイント値が付与ポイント入力欄54に入力されると、付与ポイントスライダ55のつまみ部がその値に対応する位置に移動する。また付与ポイントスライダ55のつまみ部が移動されることによって、付与ポイント値がある値に設定されると、付与ポイント入力欄54にその値を示すテキストが表示される。
【0069】
最高ポイント付与ボタン56は、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち最も高い付与ポイント値」よりも「1pt」だけ高い付与ポイント値を入力することを指示するボタンである。上述したように、未対応リクエストについて、付与ポイント値が高いほどリプライ優先順位が高くなる。これを踏まえ注目視聴者は、投稿しようとしているリクエストについてリプライ優先順位を最も高くしたいと考えた場合、最高ポイント付与ボタン56を選択することによって、簡易的にリプライ優先順位が最も高くなる付与ポイント値を入力することができる。最高ポイント付与ボタン56が選択されると、端末制御部6Aは、未対応リクエストのそれぞれの付与ポイント値のうち、最も高い付与ポイント値を特定し、当該最も高い付与ポイント値に「1pt」を加算した値を導出する。端末制御部6Aは、導出した値を付与ポイント入力欄54に表示すると共に、付与ポイントスライダ55のつまみ部を導出した値に対応する位置に移動させる。
【0070】
端末制御部6Aは、付与ポイント入力オブジェクトに入力された付与ポイント値に応じて、入力された付与ポイント値が大きいほど、リクエスト入力欄51に入力可能な文字数の上限を大きくする。本実施形態では2000pt未満の場合の上限は100文字であり、2000pt以上5000pt未満の場合の上限は200文字であり、5000pt以上の場合の上限は300文字である。ただしこれらはあくまで一例である。付与ポイント値と文字数の上限との関係は、付与ポイントスライダ55に明示される。また当該関係は、リクエスト入力欄51と対応付けて明示される。この構成のため、リクエストを投稿しようとしているユーザに、より大きな値の付与ポイント値を付与するインセンティブを与えることができる。
【0071】
リクエスト入力画面50において最高ポイント付与ボタン56の下方には、暫定優先順位画像57が表示される。暫定優先順位画像57は、付与ポイント入力オブジェクトに入力された付与ポイント値がリクエストに付与された場合に、リクエストのリプライ優先順位が何番目になるかを示す情報である。端末制御部6Aはサーバ制御部14と協働し、付与ポイント入力オブジェクトにより入力された付与ポイント値に変更がある度に以下の処理を実行する。すなわち端末制御部6Aは、未応答リクエストのそれぞれの付与ポイント値を踏まえて、入力された付与ポイント値が付与されるとしたときのリプライ優先順位を導出する。端末制御部6Aは、導出したリプライ優先順位を示すように暫定優先順位画像57の内容を更新する。注目視聴者は、暫定優先順位画像57が示すリプライ優先順位を参考にして、付与ポイント値を調整することができる。
【0072】
以上の通り端末制御部6Aは、リクエストの投稿に際して、リクエストに付与する付与ポイント値を入力する付与ポイント入力オブジェクトと、当該オブジェクトに入力された付与ポイント値がリクエストに付与された場合にリクエストの優先順位が何番目になるかを示す情報(暫定優先順位画像57)とが表示された画面(リクエスト入力画面50)を提供する機能を備える。また端末制御部6Aは、リクエストの投稿に際して、リクエストのリプライ優先順位(優先順位)が最も高くなる付与ポイント値を入力するための最高ポイント付与ボタン56(ボタン)が表示されたリクエスト入力画面50(画面)を提供する機能を備える。また端末制御部6Aは、リクエストの投稿に際して、リクエストを入力するリクエスト入力欄51(入力欄)、および、リクエストに付与するポイントを入力する付与ポイント入力オブジェクト(オブジェクト)が表示されたリクエスト入力画面50(画面)を提供する機能と、付与ポイント入力オブジェクトに入力された付与ポイント値が大きいほどリクエスト入力欄51に入力可能な文字数の上限を大きくする機能とを有する。
【0073】
暫定優先順位画像57の下方には、リクエスト送信ボタン58が設けられている。リクエスト送信ボタン58は、リクエストを投稿するときに選択されるボタンである。フローチャートFEで示すように注目視聴者は、リクエスト入力欄51へのリクエストの内容の入力、および付与ポイント入力オブジェクトで付与ポイント値を入力し、リクエスト送信ボタン58を選択する(ステップSE5)。これによりリクエストの投稿が完了する。リクエスト送信ボタン58が選択されたことを検出すると端末制御部6Aは、リクエスト入力欄51に入力されたリクエストの内容を示すリクエスト内容情報と、付与ポイント入力オブジェクトに入力された付与ポイント値とを少なくとも含むリクエスト通知情報をサーバ制御部14に送信する(ステップSE6)。
【0074】
なおリクエスト送信ボタン58が選択されたときに、端末制御部6Aは、サーバ制御部14と協働して、付与ポイント入力オブジェクトに入力された付与ポイント値が、ポイント残高値の範囲内であるか否かを判別する。ポイント残高値の範囲内である場合、端末制御部6Aは、リクエスト通知情報を送信する。一方でポイント残高値の範囲内ではない場合、端末制御部6Aは、リクエスト通知情報を送信せずに以下の処理を実行する。すなわち端末制御部6Aは、付与ポイント値がポイント残高値の範囲内ではないためリクエストの投稿ができない旨の警告を表示装置12Aに表示する。なお警告と併せて端末制御部6Aが、付与ポイント値を取得するための画面を表示させるためのボタン、或いは当該画面自体を表示装置12Aに表示する構成でもよい。
【0075】
リクエスト通知情報を受信するとサーバ制御部14は、注目配信者に対応するリクエスト管理データベース40に1件のレコードを追加する(ステップSD1)。ステップSD1においてサーバ制御部14は、追加するレコードのリクエストID<フィールド>に、一意な値のリクエストIDを格納する。またサーバ制御部14は、投稿者ID<フィールド>に、注目視聴者のユーザIDを格納する。またサーバ制御部14は、リクエスト投稿日時<フィールド>に、リクエスト通知情報を受信した日時を示すリクエスト投稿日時情報を格納する。ただしリクエスト通知情報を受信した日時ではなく、リクエストが投稿された日時とみなすことができる他の日時(例えば、リクエスト送信ボタン58が選択された日時)を示すリクエスト投稿日時情報を格納する構成でもよい。またサーバ制御部14は、受信したリクエスト内容情報をリクエスト内容<フィールド>に格納する。またサーバ制御部14は、受信した付与ポイント値を付与ポイント<フィールド>に格納する。またサーバ制御部14は、オフ値のリプライ済フラグをリプライ済フラグ<フィールド>に格納する。またサーバ制御部14は、初期値(ゼロ)を肯定評価数<フィールド>に格納し、ヌル値を肯定評価付与者<フィールド>に格納する。またサーバ制御部14は、リプライ優先順位を導出し、導出したリプライ優先順位を示すリプライ優先順位情報をリクエストリプライ優先順位<フィールド>に格納する。なおサーバ制御部14は、全ての未応答リクエストを対象として、リプライ優先順位情報を更新する。
【0076】
更にサーバ制御部14は、ユーザ管理データベース36の注目視聴者に対応するレコードのポイント残高値について、受信した付与ポイント値に応じて減算する(ステップSD2)。
【0077】
以上のようにサーバ制御部14は、ユーザによってリクエストが投稿されたときに、そのことを検出すると共に、リクエスト管理データベース40への対応するレコードの登録、その他のリクエストの投稿を反映するための処理を実行する機能を備える。当該機能は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能に相当する。またサーバ制御部14は、リクエストに付与ポイント値が付与されたときに、そのことを検出すると共に、リクエスト管理データベース40への反映、その他の付与ポイント値の付与を反映するための処理を実行する機能を備える。当該機能は、リクエストの投稿時に、リクエストの投稿者からリクエストへのポイント値の付与を受け付ける機能に相当する。
【0078】
なお例示した通常ボックス画面38およびリクエスト入力画面50は、単純化したものである。通常ボックス画面38およびリクエスト入力画面50の内容が例示した内容に限定されないことは勿論である。例えば通常ボックス画面38とリクエスト入力画面50とが一体的な画面であってもよい。またQ&A、ヘルプ情報、その他のユーザにとって有益な情報を表示するためのオブジェクトが設けられる構成でもよい。当該オブジェクトが選択された場合、サーバ制御部14は端末制御部6Aと協働して、各種情報を表示する。
【0079】
<リクエストの投稿に関する補足>
図8では、ライブ配信中に注目視聴者がリクエストを投稿する場合の情報処理システム1の動作例を説明した。ただし本件サービスにおいては、一のユーザは、他のユーザに対して、当該他のユーザによるライブ配信が行われている期間だけではなく、ライブ配信が行われていない期間においてもリクエストを投稿することができる。つまり、サーバ制御部14はライブ配信中か否かにかかわらず、注目ユーザに対するリクエストの投稿をユーザから受け付ける。
【0080】
以下、ユーザU1が、ユーザU2がライブ配信を行っていないときに、ユーザU2に対してリクエストを投稿する場合の情報処理システム1の動作について説明する。ユーザU1は、所定の本件サービス画面に対して、ユーザU2についての通常ボックス画面38(
図9)の表示を指示する。当該指示に応じて、ユーザU1の端末2の端末制御部6はサーバ制御部14と協働し、ユーザU2についての通常ボックス画面38を表示装置12に表示する。サーバ制御部14は、ユーザU2に対応するリクエスト管理データベース40に基づいて、適宜、通常ボックス画面38の表示に必要な情報を提供する。以後、ユーザU1は、
図8で例示した作業と同様の作業を行って、ユーザU2に対してリクエストを投稿する。なおサーバ制御部14および端末制御部6は、ユーザU1の作業に応じて、
図8で説明した処理と同様の処理を実行する。なおユーザU1による、ユーザU2についての通常ボックス画面38の表示の指示は、様々な方法で行われ得る。
【0081】
<リクエストボックス確認ボタン25が選択された場合の処理>
次にライブ配信中に注目配信者によりリクエストボックス確認ボタン25が選択されたときの情報処理システム1の動作について説明する。注目配信者がリクエストボックス確認ボタン25を選択したことを検出すると、端末制御部6Lは、サーバ制御部14に未応答リクエストのそれぞれの表示用リクエスト情報の応答を要求する。サーバ制御部14は、リクエスト管理データベース40を参照し、未応答リクエストのそれぞれの表示用リクエスト情報を生成して応答する。表示用リクエスト情報の内容は上述した通りである。未応答リクエストのそれぞれの表示用リクエスト情報を受信すると端末制御部6Lは、表示用リクエスト情報に基づいて、配信者側画面20上に配信者側ボックス画面60をポップアップ表示する。
【0082】
図11は、配信者側ボックス画面60を示す図である。
図11で示すように配信者側ボックス画面60の上部には、未応答リクエスト個数画像41が表示される。未応答リクエスト個数画像41の右方には、現時点の未応答リクエストの全てについて仮にリプライした場合に、獲得できる本件ポイントの値を示す獲得可能ポイント画像61が表示される。後に明らかになる通り注目配信者は、あるリクエストに対してリプライしたときにそのリクエストに付与された付与ポイント値に相当する獲得ポイント値を獲得できる。
【0083】
配信者側ボックス画面60において未応答リクエスト個数画像41の下方には、リクエストカード一覧領域42Lが設けられる。リクエストカード一覧領域42Aには、未応答リクエストごとに、配信者側リクエストカード44L(リクエストに関する情報)が表示される。配信者側ボックス画面60に表示される配信者側リクエストカード44Lは、カード処置ボタン62を備えている点で、通常ボックス画面38に表示されるリクエストカード44と異なっている。カード処置ボタン62が選択されると、端末制御部6Aは、以下の3つのアクションのうちの何れかを選択可能な画面をポップアップ表示する。
【0084】
1つ目のアクションは、配信者側リクエストカード44Lの削除である。配信者側リクエストカード44Lの削除が選択されると端末制御部6Lは、対応する配信者側リクエストカード44Lをリクエストカード一覧領域42Lから削除する。更にサーバ制御部14は端末制御部6Lと協働して、注目配信者に対応するリクエスト管理データベース40の「削除が指示された配信者側リクエストカード44Lに対応するレコード」を削除すると共に、当該レコードを、削除済みのリクエストを管理する他のデータベースに登録する。2つ目のアクションは、リクエストを投稿したユーザのブロックである。ブロックが選択されるとサーバ制御部14は端末制御部6Lと協働して、リクエストを投稿したユーザから注目配信者へのリクエストがブロックされる状態を構築する。3つ目のアクションは、管理者への通報である。通報が選択されるとサーバ制御部14は端末制御部6Lと協働して、リクエストの内容およびリクエスト投稿者に関する情報を管理者へ通報する。
【0085】
端末制御部6Lはサーバ制御部14と協働して、リクエストカード一覧領域42L内で、配信者側リクエストカード44Lをリプライ優先順位に従って並んで配置する。注目配信者は、リクエストカード一覧領域42Lを参照することにより、リプライ優先順位を踏まえつつ、未応答リクエストの内容およびリクエスト投稿者に関する情報を把握することができる。後述するように注目配信者がリプライ開始ボタン24を選択すると、リプライ優先順位が最も高いリクエストに対応する配信者側リクエストカード44L、つまり、配信者側ボックス画面60を表示したときに最上部に表示される配信者側リクエストカード44Lが、リプライの対象となる。これを踏まえ注目配信者は、配信者側ボックス画面60を参照することによって、自身がリプライ開始ボタン24を選択した場合にリプライの対象となるリクエストカード44の内容を確認することができる。
【0086】
<注目配信者によりリプライが行われるときの処理>
次にライブ配信中に注目配信者によりリプライが行われるときの情報処理システム1の動作について説明する。
図12は、注目配信者によりリプライが行われるときの配信者端末2L、情報処理サーバ3および視聴者端末2Aの情報処理方法を示すフローチャートである。フローチャートFFは配信者端末2Lによる情報処理方法を示し、フローチャートFGは情報処理サーバ3による情報処理方法を示し、フローチャートFHは視聴者端末2Aによる情報処理方法を示す。
【0087】
ここで1回のライブ配信において配信者は、リプライを複数回、実行することができる(ただし1回も行わなくてもよい)。例えば配信者が2回のリプライを行うとする。この場合、配信者は、1回目のリプライを行うときにリプライ開始ボタン24を選択し、1回目のリプライが完了するとリプライ終了ボタン63を選択する。その後、配信者は、2回目のリプライを行うときにリプライ開始ボタン24を選択し、2回目のリプライが完了するとリプライ終了ボタン63を選択する。
図12を用いた説明では、注目配信者により1つのリプライが行われるときに着目して情報処理システム1の動作について説明する。
【0088】
フローチャートFFで示すように注目配信者は、リプライ開始ボタン24を選択することによってリプライの開始を指示する(ステップSF1)。リプライ開始ボタン24が選択されたことを検出すると、端末制御部6Lは、リプライの開始をサーバ制御部14に通知する(ステップSF2)。
【0089】
フローチャートFGで示すようにサーバ制御部14は、リプライの開始の通知を受信すると、サーバ制御部14は、注目配信者に対応するリクエスト管理データベース40を参照し、未応答リクエストのうち、リプライ優先順位が最も高い未応答リクエストを特定する(ステップSG1)。以下、リプライ優先順位が最も高い未応答リクエストを「最高位リクエスト」という。
【0090】
次いでライブ配信管理データベース35の注目ライブ配信に対応するレコードのリプライログデータ34に、リプライの開始に関する情報を記録する(ステップSG2)。
図13は、リプライログデータ34の内容を説明に適した態様で模式的に示す図である。リプライログデータ34は、ライブ配信において行われたリプライのそれぞれについて、リプライ実績情報RJが記録される。1つのリプライ実績情報RJは、何回目のリプライであるかを示す情報と、最高位リクエストのリクエストIDと、開始タイミングと、終了タイミングとを含んでいる。なお本実施形態では開始タイミングおよび終了タイミングは、ライブ配信が開始されたタイミングを基点とした経過時間として表される。ただし開始タイミングおよび終了タイミングの表現形式は、本実施形態で例示する形式に限られない。開始タイミングおよび終了タイミングは、後述する抽出動画データの生成に利用可能な情報であればよい。
【0091】
ステップSG2においてサーバ制御部14は、一例として以下の処理を実行する。例えばステップSF1においてリプライ開始ボタン24が選択されることによって開始されたリプライの回目が2回目であったとする。この場合、ステップSG2においてサーバ制御部14は、まず開始タイミングを認識する。例えば、ライブ配信の開始からの経過時間が「5:00」であったとする。この場合、サーバ制御部14は、開始タイミングとして「5:00」を認識する。次いでサーバ制御部14は、2回目のリプライであることを示す情報、最高位リクエストのリクエストID、および、開始タイミングをフォーマットに従ってリプライログデータ34に記録する。
【0092】
次いでサーバ制御部14は、最高位リクエストに付与された付与ポイント値分の獲得ポイントを注目配信者に付与する(ステップSG3)。具体的にはサーバ制御部14は、ユーザ管理データベース36の注目配信者に対応するレコードの獲得ポイント合計値を、最高位リクエストに付与された付与ポイント値分、増加させる。あるユーザについての獲得ポイント合計値は、そのユーザが獲得した獲得ポイント値の累計値である。詳細は省略するが、注目配信者は、獲得ポイントと引き換えに、相応の特典を受けることができる。一例として注目配信者は、獲得ポイントの量に相当する金銭の付与を受けることができる。このようにユーザが獲得ポイントと引き換えに相応の特典を受けることができることは、ユーザがリプライを行うことのインセンティブとなる。
【0093】
次いでサーバ制御部14は、注目配信者に対応するリクエスト管理データベース40の最高位リクエストに対応するレコードに基づいて、最高位リクエストについての表示用リクエスト情報を生成する(ステップSG4)。次いでサーバ制御部14は、リクエスト表示指示情報を配信者端末2Lおよび視聴者端末2Aに送信する(ステップSG5)。リクエスト表示指示情報とは、最高位リクエストに対応する表示用リクエスト情報を含み、最高位リクエストに対応するリクエストカード44の表示を指示する情報である。
【0094】
フローチャートFHで示すように端末制御部6Aは、リクエスト表示指示情報を受信すると、最高位リクエストに対応するリクエストカード44を視聴者側画面29にポップアップ表示する(ステップSH1)。その際、端末制御部6Aは、付与ポイント値に応じて、リクエストカード44の色を変化させる。付与ポイント値と色との関係は、上述した通りである。
図14は、最高位リクエストに対応するリクエストカード44が視聴者側画面29に表示された様子を示している。リプライの開始に応じて、最高位リクエストに対応するリクエストカード44が視聴者側画面29に表示されるため、注目視聴者は、注目配信者によるリプライが行われている間、対応するリクエストの内容を的確に把握できる。
【0095】
フローチャートFFで示すように端末制御部6Lは、リクエスト表示指示情報を受信すると、最高位リクエストに対応するリクエストカード44を配信者側画面20にポップアップ表示する(ステップSF3)。その際、端末制御部6Aは、付与ポイント値に応じて、リクエストカード44の色を変化させる。付与ポイント値と色との関係は、上述した通りである。注目配信者は、リクエストカード44の色を参照することにより、付与ポイント値がどの程度であるかを直感的に把握できる。
【0096】
更にサーバ制御部14は、リプライ開始ボタン24に代えてリプライ終了ボタン63を表示し、リクエストボックス確認ボタン25に代えて破棄ボタン64を表示する(ステップSF4)。
図15は、最高位リクエストに対応するリクエストカード44が配信者側画面20に表示された様子を示している。破棄ボタン64は、実行中のリプライについて、抽出動画データ(後述)の生成を行わないことを指示するボタンである。破棄ボタン64が選択されたことを検出すると端末制御部6Lは、そのことをサーバ制御部14に通知し、サーバ制御部14は、リプライログデータ34から、対応するリプライ実績情報RJを削除する。この場合、サーバ制御部14は、注目配信者によりリプライ終了ボタン63が選択されたときに、終了タイミングを示す情報のリプライログデータ34への記録を行わない。リプライログデータ34に、あるリプライのリプライ実績情報RJが記録されないことにより、そのリプライに対応する抽出動画データは生成されないことになる。
【0097】
以上の通り注目配信者によってリプライの開始が指示されると、配信者端末2Lの表示装置12Lに最高位リクエストに対応する配信者側リクエストカード44Lが表示される。配信者は、配信者側リクエストカード44Lを参照することによってリクエストの内容を把握することができ、リクエストに対してリプライすることができる。注目配信者がリプライを開始すると、注目配信者は、その時点でリプライ優先順位が最も高いリクエストに対して、独占的に対応することになる。つまりリクエストを投稿しようとする者にとっては、自身が投稿しようとするリクエストのリプライ優先順位が高いほど、より優先的にリプライされて、独占的に応答してもらえることになる。このため本件サービスでは、リクエストのリプライ優先順位を高くするインセンティブをユーザに付与できる。
【0098】
注目配信者は、リクエストに対してリプライする。例えば、リクエストが質問である場合には、注目配信者は、質問に対して回答する。フローチャートFFで示すように注目配信者は、リプライが終了するとリプライ終了ボタン63を選択することによって、リプライの終了を指示する(フローチャートSF5)。リプライ終了ボタン63が選択されたことを検出すると端末制御部6Lは、リプライの終了をサーバ制御部14に通知する(ステップSF6)。更に端末制御部6Lは、リクエストカード44の表示を停止し、リプライ終了ボタン63および破棄ボタン64に代えて、リプライ開始ボタン24およびリクエストボックス確認ボタン25を配信者側画面20に表示する(ステップSF7)。
【0099】
フローチャートFGで示すようにサーバ制御部14は、リプライの終了の通知を受信するとライブ配信管理データベース35の注目ライブ配信に対応するレコードのリプライログデータ34に、リプライの終了に関する情報を記録する(ステップSG6)。詳述するとサーバ制御部14は、終了タイミング(ライブ配信の開始からの現時点までの経過時間)を認識し、認識した終了タイミングをフォーマットに従ってリプライログデータ34の今回のリプライ実績情報RJに記録する。更にサーバ制御部14は、リクエストカード44の表示の停止の指示を端末制御部6Aに送信する(ステップSG7)。
【0100】
フローチャートFHで示すように端末制御部6Aは、リクエストカード44の表示の停止の指示を受信すると、視聴者側画面29に表示していたリクエストカード44の表示を停止する(ステップSH2)。
【0101】
以上の通りサーバ制御部14は、注目配信者がリプライの開始を指示したときに、そのことを検出すると共に、リプライログデータへの情報の記録、最高位リクエストについての表示用リクエスト情報の送信、その他のリプライの開始の指示を反映するための処理を実行する機能を備える。当該機能は、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示を受け付ける機能に相当する。またサーバ制御部14は、注目配信者がリプライの終了を指示したときに、そのことを検出すると共に、リプライログデータへの情報の記録、リクエストカードの表示の停止の指示、その他のリプライの終了の指示を反映するための処理を実行する機能を備える。当該機能は、リクエストに対するリプライの終了の指示を受け付ける機能に相当する。これを踏まえサーバ制御部14は、注目配信者によるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの1つをライブ配信の視聴者の端末2に表示させる機能を備える。またサーバ制御部14は、ライブ配信中にリプライの開始の指示があった場合、未応答リクエストのうち、リプライ優先順位(優先順位)が最も高いものを視聴者の端末2に表示させる機能を備える。
【0102】
なお本実施形態では、配信者によってリプライ終了ボタン63が選択されることによってのみリプライが終了する構成であった。この点に関して以下の構成でもよい。すなわちリプライが開始されてから終了するまでの時間に制限が設けられ、制限時間となったら強制的にリプライが終了し、ステップSF6以下の処理が実行される構成でもよい。
【0103】
<抽出動画データを生成するときの動作>
次に抽出動画データを生成するシーンについて説明する。抽出動画データとは、1つのリプライの開始から終了までの期間のライブ配信に係る動画が記録された動画データ(動画ファイル)のことである。上述したように1回のライブ配信において、リプライは複数回、行われる場合がある。本件サービスでは、行われたリプライのそれぞれについて、抽出動画データが自動で生成されることになる。
【0104】
図16のフローチャートFIは、注目ライブ配信に係る抽出動画データを生成するときの情報処理サーバ3の動作を示すフローチャートである。以下の説明では、注目ライブ配信において注目配信者によって複数回のリプライが行われたものとする。なお
図16のフローチャートFIの処理は、注目ライブ配信が終了した後の所定のタイミングで開始される。例えば当該処理は、注目ライブ配信が終了した直後に実行される。また例えば当該処理は、一日の決まった時刻にバッチ処理として開始される。
【0105】
フローチャートFIで示すようにサーバ制御部14は、ライブ配信管理データベース35の注目ライブ配信に対応するレコードを参照し、注目ライブ配信に係るライブ配信全体動画データを取得する(ステップSI1)。ここで取得されたライブ配信全体動画データは、注目ライブ配信の全体が記録された動画データである。次いでサーバ制御部14は、注目ライブ配信に対応するレコードのリプライログデータ34を取得する(ステップSI2)。ここで取得されたリプライログデータ34は、注目ライブ配信で行われたリプライのそれぞれについてリプライ実績情報RJが記録されている。
【0106】
次いでサーバ制御部14は、ライブ配信全体動画データおよびリプライログデータ34に基づいて抽出動画データ生成処理を実行する(ステップSI3)。詳述するとサーバ制御部14は、ライブ配信全体動画データについて、リプライごとに、開始タイミングから終了タイミングまでの部分を抽出した動画データを生成する。ここで生成された1つのリプライに対応する1つの動画データが「抽出動画データ」に相当する。例えばリプライログデータ34の内容が
図17の(A)で示すものであったとする。またライブ配信全体動画データの全体の長さが「10:00」であったとする。この場合、
図17の(B)で示すように、サーバ制御部14は、ライブ配信全体動画データの「1:00~2:01」の部分を抽出して1つの抽出動画データを生成し、「3:30~5:00」の部分を抽出して1つの抽出動画データを生成し、「7:01~9:01」の部分を抽出して1つの抽出動画データを生成する。抽出動画データには、リプライの開始から終了までの期間のライブ配信に係る動画が記録される。以下、抽出動画データに記録された動画を「抽出動画」という。
【0107】
なお詳細は省略するが、サーバ制御部14は、ストリーミング配信に適したフォーマットへ変更するためのエンコード、その他の抽出動画データをストリーミング配信可能な状態とするために必要な処理を既存技術に基づいて適切に実行する。
【0108】
以上の通りサーバ制御部14は、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能を備える。ここで抽出動画データに記録された抽出動画は、1つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年では、ライブ配信だけではなく、ライブ配信の一部を抽出した動画(「切抜き動画」と呼ばれることもある)が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。本実施形態は、このような利用価値の高い抽出動画データが自動で生成される点において、強い優位性を持つ。
【0109】
次いでサーバ制御部14は、適切性判別処理を実行する(ステップSI4)。以下、1つの抽出動画データを対象としてサーバ制御部14がステップSI4で実行する処理を説明する。まずサーバ制御部14は、抽出動画データについて、予め設定された不適切条件を満たすか否かを判別する。本実施形態では、不適切条件の1つは、「抽出動画の長さが許容範囲を超えて短い場合に成立する条件」(以下「時間関連条件」という)である。サーバ制御部14は、抽出動画の長さが予め定められた閾値よりも短い場合、時間関連条件が成立すると判定する。許容範囲を超えて抽出動画の長さが短い場合、注目配信者が非常に短い期間しかリプライに費やさなかったということであり、対応するリクエストが注目配信者にとって望まないものであった可能性、または注目配信者が誤ってリプライ終了ボタン63を選択してしまった可能性がある。
【0110】
また不適切条件の1つは、「抽出動画の明るさが許容範囲を超えて暗い場合に成立する条件」(以下「明度関連条件」という)である。サーバ制御部14は、抽出動画の各フレームの平均輝度を導出し、更に各フレームの平均輝度の平均値を導出し、導出した平均値が予め定められた閾値よりも小さい場合、明度関連条件が成立すると判定する。当該閾値は、抽出動画について真っ暗に近い状態が継続する場合に明度関連条件が成立するような値に設定される。明度関連条件が成立する場合、抽出動画が真っ暗に近い状態で継続するものであるということであり、注目配信者が公開を望まないものと想定される。なお本実施形態で例示する明度関連条件の内容はあくまで一例であり、抽出動画の明るさが許容範囲を超えて暗い場合に成立する条件であればよい。
【0111】
適切性判別処理においてサーバ制御部14は、ある抽出動画データについて、時間関連条件と明度関連条件とのうち少なくとも一方の条件が成立する場合には、その抽出動画データについて不適切条件を満たすと判定する。サーバ制御部14は、不適切条件を満たす抽出動画データについては削除する。抽出動画データを削除する処理は、抽出動画データを破棄する処理に相当する。
【0112】
なお本実施形態では、サーバ制御部14が、抽出動画データを生成した後に、不適切条件を満たす場合には削除する構成である。この点に関し、サーバ制御部14が、抽出動画データの生成時に、不適切条件を満たすか否かを判別し、不適切条件を満たす場合には、抽出動画データを生成しない構成でもよい。抽出動画データを生成しない処理は、抽出動画データを破棄する処理に相当する。
【0113】
以上の通り、サーバ制御部14は、抽出動画データの生成に際して、記録される動画の長さが許容範囲を超えて短い場合、または、記録される動画の明るさが許容範囲を超えて暗い場合、抽出動画データを破棄する機能を備える。
【0114】
次いでサーバ制御部14は、サーバ記憶部16に記憶された抽出動画管理データベース65に、生成した抽出動画データのそれぞれに対応するレコードのそれぞれを登録する(ステップSI5)。抽出動画管理データベース65は、抽出動画データのそれぞれを管理するデータベースであり、抽出動画データごとにレコードが登録される。
図6(D)は、抽出動画管理データベース65の1件のレコードの内容を示している。
図6(D)で示すように抽出動画管理データベース65の1件のレコードはフィールドとして、抽出動画ID<フィールド>と、配信者ID<フィールド>と、投稿者ID<フィールド>と、リクエストID<フィールド>と、抽出動画<フィールド>と、サムネイル画像<フィールド>と、表示用リクエスト<フィールド>と、タイトル<フィールド>と、タグ<フィールド>とを備えている。
【0115】
抽出動画ID<フィールド>には、対応する抽出動画データを一意に識別する識別情報である抽出動画IDが格納される。配信者ID<フィールド>には、対応するライブ配信の配信者のユーザIDが格納される。リクエストID<フィールド>には、対応するリクエスト(=対応する抽出動画データに基づく抽出動画において配信者がリプライしているリクエスト)のリクエストIDが格納される。抽出動画<フィールド>には、対応する抽出動画データが格納される。サムネイル画像<フィールド>には、対応する抽出動画データに基づくサムネイル画像の画像データ(以下「サムネイル画像データ」という)が格納される。表示用リクエスト<フィールド>には、対応するリクエストの表示用リクエスト情報が記録される。上述した通り表示用リクエスト情報には、リクエストカード44を表示するために必要な情報が不足なく含まれている。タイトル<フィールド>には、対応する抽出動画データのタイトルを示す情報が格納される。タグ<フィールド>には、本件タグのタグ情報(本件タグの具体的な値)が格納される。本件タグとは、本件サービスにおいて利用可能なコンテンツにおいて、コンテンツにメタ情報として付与されるタグである。本件タグは、コンテンツの検索や、分類等に使用される。本件タグは、いわゆるハッシュタグと同等の機能を有する。
【0116】
ステップSI5において、ある1つの抽出動画データに対応する1つのレコードの登録に際して、サーバ制御部14は、以下の処理を実行する。サーバ制御部14は、一意な値の抽出動画IDを生成し、抽出動画ID<フィールド>に格納する。またサーバ制御部14は、注目配信者のユーザIDを配信者ID<フィールド>に格納する。またサーバ制御部14は、対応するリクエストのリクエストID(リプライログデータ34の対応するリプライ実績情報RJに記録されているリクエストID)をリクエストID<フィールド>に格納する。またサーバ制御部14は、抽出動画データを抽出動画<フィールド>に格納する。またサーバ制御部14は、抽出動画データに基づいてサムネイル画像を生成し、サムネイル画像<フィールド>に格納する。サーバ制御部14は、抽出動画データを構成するフレームの1つを取得し、対応する表示用リクエスト情報に基づくリクエストカード44を重畳することによってサムネイル画像データを生成する。またサーバ制御部14は、対応するリクエストの表示用リクエスト情報を表示用リクエスト<フィールド>に格納する。またサーバ制御部14は、ルールに従ってタイトルを設定し、タイトルを示す情報をタイトル<フィールド>に格納する。ルールは一例として、ライブ配信を行った日付と、何回目のリプライであるかを示す情報とを所定の態様で組み合わせるというルールである。またサーバ制御部14は、ヌル値をタグ<フィールド>に格納する。
【0117】
次いでサーバ制御部14は、公開処理を実行する(ステップSI6)。なお本実施形態ではサーバ制御部14が、抽出動画データの生成と連続して公開処理を実行する構成であるが、抽出動画データを生成した後に時間をあけて公開処理を実行する構成でもよい。公開処理は、生成した抽出動画データのそれぞれについて、抽出動画を視聴可能な状態を構築する処理である。以下、ある抽出動画データについて、対応する抽出動画を視聴可能な状態とすることを「抽出動画データを公開する」と表現する場合がある。また以下では、ある抽出動画データについて、ユーザが抽出動画データに基づく抽出動画を視聴することを単に、「ユーザが抽出動画データを視聴する」という場合がある。ここで本実施形態では、サーバ制御部14は、抽出動画データをストリーミング配信することによって、抽出動画を提供する。抽出動画データに基づくストリーミング配信は既存の技術を利用して行われる。以下の説明では抽出動画の提供に際して、それを実現するためのストリーミング配信は適切に行われるものとして、ストリーミング配信自体についての詳しい説明は行わない。ただしストリーミング配信以外の手段で抽出動画が提供される構成でもよい。
【0118】
以下、注目配信者によるライブ配信に基づく抽出動画データについて公開処理が行われるものとして、公開処理の複数の例を説明する。本件サービスでは、サーバ制御部14は端末制御部6と協働して、指定された特定のユーザについての抽出動画一覧画面を提供できる。あるユーザについての抽出動画一覧画面は、そのユーザが配信者として行ったライブ配信に基づく抽出動画データのサムネイル画像が付随情報と共に一覧表示された画面である。例えばユーザAは、ユーザBの指定を伴う所定の入力を行うことによって、ユーザBについての抽出動画一覧画面を自身の端末2の表示装置12に表示させることができる。ユーザBについての抽出動画一覧画面は、ユーザBが配信者として行ったライブ配信に基づく抽出動画データのサムネイル画像が一覧表示された画面である。抽出動画一覧画面のサムネイル画像(付随情報或いは関連するオブジェクトでもよい)が選択されると、選択されたサムネイル画像に対応する抽出動画データがストリーミング配信され、抽出動画が提供される。そして公開処理においてサーバ制御部14は、注目配信者に係る抽出動画一覧画面に、生成した抽出動画データのそれぞれに係るサムネイル画像が表示されるようにすると共に、サムネイル画像が選択されたときに対応する抽出動画が提供される状態を構築する。
【0119】
また本件サービスでは、画面をスクロール操作(他の操作でもよい)することによって、視聴する抽出動画を次々と切り替えることができるサービス(以下「特定視聴サービス」という)が提供される。特定視聴サービスにおいて抽出動画の切り替えは、サーバ制御部14と端末制御部6との協働により実行される。切り替えの指示に応じて表示される次の抽出動画に対応する抽出動画データは、プールされた抽出動画データの中から所定の方法でサーバ制御部14によって選択される。当該所定の方法は、例えばランダム、または視聴するユーザの嗜好を反映させるアルゴリズムに従った方法である。そして公開処理においてサーバ制御部14は、生成した抽出動画データのそれぞれを当該プールに追加し、特定視聴サービスにおいて、生成した抽出動画データに基づく抽出動画が提供され得る状態を構築する。
【0120】
また本件サービスでは、タグを利用した抽出動画データの検索が可能となっている。検索の結果、見つかった抽出動画データに基づく抽出動画は、ユーザの選択に応じて提供される。そして公開処理においてサーバ制御部14は、タグによる検索の対象となる状態を構築する。以上、公開処理の複数の例を説明したが、公開処理はこれらに限られない。すなわち公開処理では、本件サービスにおいて、抽出動画データに基づく抽出動画が視聴可能な状態が構築されればよい。
【0121】
ここで抽出動画データは非常に利用価値の高いデータである点は上述した通りである。本実施形態では、抽出動画データの生成および公開は自動で行われることになる。つまり配信者が、ライブ配信を行った上、ライブ配信中にリプライを行うだけで、そのライブ配信に基づく抽出動画データが自動で生成され、公開される。従来、抽出動画データ(抽出動画)は、いわゆる切抜き動画データと呼ばれ、その生成および公開は、配信者自ら作業を行うか、他人に委ねることによって行われていた。本実施形態では、抽出動画データの生成、公開について、自ら作業を行ったり、他人に委ねたりする必要がなく、配信者の利便性が高い。
【0122】
公開処理の後、サーバ制御部14は、通知処理を実行する(ステップSI7)。通知処理は、生成した抽出動画データのそれぞれについて、配信者、リクエスト投稿者および肯定評価付与者に、抽出動画データが公開されたことを通知する処理である。本実施形態では、各ユーザに、本件サービスに関する各種通知を受け取るボックス(以下「通知用ボックス」という)が設定される。各ユーザは、通知用ボックスで受け取った通知が一覧表示された画面を表示装置12に表示させることができ、更に当該画面から1つの通知を選択することによって通知の詳細を表示させることができる。サーバ制御部14は、生成した抽出動画データのそれぞれについて、配信者、投稿者および肯定評価付与者のそれぞれの通知用ボックスに対して、通知を送信する。1つの抽出動画データに対応する通知には、少なくとも配信者のユーザ名、サムネイル画像、タイトルが含まれる。抽出動画データに基づく抽出動画を視聴する画面に遷移するためのリンクが付加されていてもよい。
【0123】
以上の通りサーバ制御部14は、抽出動画データに記録された動画を視聴可能な状態を構築する機能と、当該状態の構築に応じて、抽出動画データに対応するリクエストの投稿者、および、抽出動画データに対応するリクエストに肯定評価を付与したユーザに通知を行う機能とを備える。この構成によれば、リクエスト投稿者および肯定評価付与者のそれぞれは、抽出動画データが公開されたことの通知により、そのことを認識することができ、好きなときにいつでも抽出動画を視聴できる。特に本実施形態では肯定評価付与者に対して通知が行われるため、各ユーザは、気になるリクエストカード44が存在する場合に、そのリクエストカード44に肯定評価を付与しておけば、対応する抽出動画データが公開されたときに、そのことを認識し、都合のよいときに抽出動画を視聴できる。詳述すると、あるユーザ(ユーザU1とする)が、配信者となり得る別のユーザ(ユーザU2とする)の通常ボックス画面38を参照し、ユーザU2がどのような応答をするのか気になるリクエストカード44(リクエスト)を見つけたとする。このときユーザU1は、そのリクエストカード44に肯定評価を付与する。すると、そのリクエストカード44に対してリプライが行われたライブ配信の終了後、そのリクエストカード44に対応する抽出動画データがサーバ制御部14によって自動で生成されて公開され、そのことがユーザU1に通知される。ユーザU1は、仮にライブ配信を見逃した場合であっても、自身が興味を抱いたリクエストカード44に対応する抽出動画データが公開されたことを認識し、都合のよいときに視聴することができる。
【0124】
<ユーザが抽出動画を視聴するときの動作>
次にユーザが抽出動画を視聴するときの情報処理システム1の動作について説明する。上述の通り生成された抽出動画データは公開される。ユーザは、本件サービスを利用して、所望の抽出動画データを視聴することができる。そしてサーバ制御部14は、ユーザが、自身が配信者であったライブ配信に基づく抽出動画データを視聴する場合に、特別な処理を実行する。以下の説明では、ある抽出動画データについて、元となったライブ配信の配信者のことを「該当配信者」という。またサーバ制御部14は、ユーザが、自身が投稿したリクエストに対応する抽出動画データを視聴する場合、特別な処理を実行する。以下の説明では、ある抽出動画データについて、対応するリクエスト投稿者のことを「該当リクエスト投稿者」という。
【0125】
図18は、抽出動画の視聴が開始されるときの情報処理システム1の動作を示すフローチャートである。フローチャートFJは端末2による情報処理方法を示し、フローチャートFKは情報処理サーバ3による情報処理方法を示す。以下の説明では、抽出動画を視聴するユーザを「視聴ユーザ」といい、視聴ユーザにより視聴される抽出動画データを「注目抽出データ」といい、
【0126】
フローチャートFKで示すように情報処理サーバ3のサーバ制御部14は、注目抽出動画データのストリーミング配信を開始する(ステップSK1)。ストリーミング配信の開始と併せてサーバ制御部14は、抽出動画管理データベース65の注目抽出動画データに対応するレコード(以下「注目レコード」という)の表示用リクエスト情報およびタグ情報(複数ある場合には複数のタグ情報)を端末制御部6Lに送信する(ステップSK2)。なおタグ<フィールド>に1つもタグ情報が格納されていない場合には、タグ情報は送信されない。
【0127】
更にサーバ制御部14は、視聴ユーザが、該当配信者または該当リクエスト投稿者であるかを判別する(ステップSK3)。視聴ユーザが該当配信者であるということは、注目抽出動画データが、視聴ユーザが配信者となって行ったライブ配信に基づくものということである。また視聴ユーザが該当リクエスト投稿者であるということは、注目抽出動画データが、視聴者が投稿したリクエストに対応するものということである。サーバ制御部14は、視聴ユーザが、該当配信者または該当リクエスト投稿者であることを以下の方法で判定する。すなわちサーバ制御部14は、視聴ユーザのユーザIDと、注目レコードの配信者ID<フィールド>に格納されたユーザIDまたは投稿者ID<フィールド>に格納されたユーザIDとの一致性に基づいて判定する。
【0128】
視聴ユーザが該当配信者または該当リクエスト投稿者の場合(ステップSK3:YES)、サーバ制御部14は、タグ情報の付与を許可すること通知する許可通知を端末制御部6に送信する(ステップSK4)。一方、視聴ユーザが該当配当者でもなく、該当リクエスト投稿者でもない場合(ステップSK3:NO)、サーバ制御部14は、タグ情報の付与を許可しないことを通知する不許可通知を端末制御部6に送信する(ステップSK5)。
【0129】
フローチャートFJで示すように端末制御部6は、サーバ制御部14が送信した各情報を受信する(ステップSJ1)。次いでサーバ制御部14は、許可通知を受信したか、不許可通知を受信したか判別する(ステップSJ2)。許可通知を受信した場合(ステップSJ2:「許可通知」)、サーバ制御部14は、特別視聴画面66を表示装置12に表示する(ステップSJ3)。一方、不許可通知を受信した場合(ステップSJ2:「不許可通知」)、サーバ制御部14は、通常視聴画面67を表示装置12に表示する(ステップSJ4)。
【0130】
図19の(A)は特別視聴画面66を示し、(B)は通常視聴画面67を示す図である。
図19の(A)の特別視聴画面66は視聴ユーザが該当配信者または該当リクエスト投稿者である場合に表示され、(B)のは視聴ユーザが該当配信者でも該当リクエスト投稿者でもない場合に表示される。
図19で示すように、特別視聴画面66には、背景として配信動画像68が表示される。配信動画像68は、抽出動画データのストリーミング配信に基づいて表示される動画像であり、ライブ配信中の撮影動画像21に対応する。配信動画像68の中央やや下方には、リクエストカード44が表示される。端末制御部6は、受信した表示リクエスト情報にリクエストカード44を表示する。このように端末制御部6は、抽出動画データに記録された動画を、抽出動画データに対応するリクエストの内容(リクエストカード44)と共に表示する機能を備える。
【0131】
特別視聴画面66においてリクエストカード44の下方には、タグ表示領域69が設けられている。タグ表示領域69には、対応する抽出動画データに付与されたタグ情報が表示される。タグ情報のそれぞれは、選択可能なオブジェクトであり、タグ情報が選択されると、そのタグ情報をキーとしたコンテンツ(コンテンツには抽出動画データが含まれる)の検索がサーバ制御部14により行われ、検索結果が提供される。
【0132】
特別視聴画面66においてタグ表示領域69の右方には、タグ追加ボタン70が表示される。タグ追加ボタン70は、タグ情報を追加するためのボタンである。タグ追加ボタン70が選択されると端末制御部6は、サーバ制御部14と協働して、1つ以上のタグ情報の入力、および、入力したタグ情報の追加の指示を行うことが可能なタグ関連画面(不図示)を表示する。タグ関連画面を利用して1つ以上のタグ情報の追加の指示があると、サーバ制御部14は端末制御部6と協働して、注目レコードのタグ<フィールド>に、追加が指示されたタグ情報を追加的に記録する。このように該当配信者または該当リクエスト投稿者は、注目抽出動画データにタグ情報を付加することができる。つまりサーバ制御部14は、注目抽出動画データへのタグ情報(メタ情報)の付与を、該当配信者および該当リクエスト投稿者に許可する。またサーバ制御部14は、該当リクエスト投稿者からタグ情報の付与の指示があったときに、そのことを検出すると共に、抽出動画管理データベース65への反映、その他のタグ情報の付与を反映するための処理を実行する機能を有する。当該機能は、リクエストの投稿者からメタ情報の付与を受け付ける機能に相当する。
【0133】
一方、
図19の(B)で示すように通常視聴画面67には、タグ追加ボタン70が表示されず、この点で特別視聴画面66と相違している。通常視聴画面67を視聴するユーザは、タグ情報を追加する手段がなく、注目抽出動画データにタグ情報を追加することができない。つまり該当配信者でもなく該当リクエスト投稿者でもないユーザは、注目抽出動画データにタグ情報を付加することができない。
【0134】
以上の通りサーバ制御部14は、抽出動画データを生成した後、生成した抽出動画データへのメタ情報の付与を、抽出動画データに対応するリクエストの投稿者に許可し、リクエストの投稿者からメタ情報の付与を受け付ける機能を備える。この構成によれば、ユーザは、リクエストを投稿することによって、そのリクエストに基づく抽出動画データが生成され公開されたときに、タグ情報を付与できるという特権を得ることができる。このため、ユーザにリクエストを投稿しようとするインセンティブを付与できる。また端末制御部6は、抽出動画データに記録された動画を、抽出動画データに対応するリクエストの内容(リクエストカード44)と共に表示する機能を備える。この構成によれば、抽出動画を視聴するユーザは、リクエストの内容を把握しつつ抽出動画を視聴することができ、ユーザの満足度が高い。
【0135】
なお該当配当者および該当リクエスト投稿者がタグ情報を付与する手段は例示したものに限られない。例えばサーバ制御部14は、
図16のフローチャートFIのステップSI7の通知処理で該当配当者および該当リクエスト投稿者に抽出動画データが公開されたことを通知するときに、タグ情報を入力するためのユーザインタフェイスを併せて提供する。そして該当配当者および該当リクエスト投稿者が当該ユーザインタフェイスを利用してタグ情報を付与できる構成でもよい。
【0136】
また付与可能なメタ情報はタグ情報に限られない。一例として抽出動画データのタイトルやサブタイトルでもよい。また端末制御部6がサーバ制御部14と協働して、抽出動画を表示する際に、リクエストカード44に加えて、そのときに投稿されたコメントに関する画像を表示する構成でもよい。また端末制御部6が、抽出動画を視聴するための画面において、配信動画像68に重ねてリクエストカード44を表示するのではなく、配信動画像68を避けた領域にリクエストカード44(或いは同等の内容の情報)を表示する構成でもよい。
【0137】
以上説明したように、サーバ制御部14は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示とを受け付け、リプライの開始の通知があった場合、リクエストのうちの1つをライブ配信の視聴者の端末2に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有する。
【0138】
この構成によれば、配信者がライブ配信中に、リプライの開始を指示し、当該指示に応じて視聴者の端末に表示されるリクエストにリプライし、リプライの完了後にリプライの終了を指示するという作業を行うことによって、配信者によって行われたリプライごとに、リプライを行った期間のライブ配信に係る動画が記録された抽出動画データが生成されることになる。この抽出動画データに記録された動画は、1つのリプライに対応している点で、一貫性およびまとまりのある内容の動画である。近年では、ライブ配信だけではなく、ライブ配信の一部を抽出した動画(いわゆる切抜き動画)が広く提供され、視聴されており、このことを鑑みると抽出動画データは利用価値の高いデータと言える。そして本発明によれば、このような利用価値の高い抽出動画データを生成するために、配信者は、ライブ配信全体の動画が記録された動画データを編集したり、抽出動画データの生成を他人に頼ったりする必要がなく、配信者の満足度を向上できる。すなわち本発明によれば、ライブ配信に係るサービスに関し、配信者の満足度を向上することができる。
【0139】
<変形例>
次に変形例について説明する。なお変形例において、上記実施形態と同等の要素には同じ符号が付されている。上述した実施形態では、あるリクエストに対して付与ポイント値を付与できるのは、そのリクエストについてのリクエスト投稿者のみであった。一方で本実施形態では、各ユーザが、所望のリクエストの付与ポイント値に対して、所望の値だけ追加ポイント値を追加することができる。以下、ユーザU1が、ユーザU2に対して既に投稿されたリクエストについて、追加ポイント値を追加する場合を例にして、変形例に係る情報処理システム1の動作について説明する。
【0140】
ユーザU1は、ユーザU2がライブ配信中か否かにかかわらず、任意のタイミングでユーザU2に対応する通常ボックス画面38Xの表示を指示することができる。当該指示に応じてユーザU1の端末2の端末制御部6はサーバ制御部14と協働して、表示装置12に通常ボックス画面38Xを表示する。
【0141】
図20の(A)は、通常ボックス画面38Xの一例を示す図である。
図9と
図20の(A)との比較で明らかな通り、通常ボックス画面38Xでは、リクエストカード44の付与ポイント画像46と対応付けてポイント追加ボタン72が付加されている。ポイント追加ボタン72は、追加ポイント値を追加する場合に選択されるボタンである。ユーザU1がポイント追加ボタン72を選択すると、端末制御部6はサーバ制御部14と協働して、追加ポイント入力画面73をポップアップ表示する。サーバ制御部14は、ユーザ管理データベース36、リクエスト管理データベース40、その他のデータに基づいて、追加ポイント入力画面73の表示に必要な情報を提供する。
【0142】
図20の(B)は、追加ポイント入力画面73の一例を示す図である。
図20の(B)で示すように、追加ポイント入力画面73の上部には、ユーザU1の本件ポイントの残高を示すポイント残高画像52が表示される。ポイント残高画像52の下方には追加ポイント入力欄74が設けられ、これの下方には追加ポイントスライダ75が設けられている。追加ポイント入力欄74および追加ポイントスライダ75はそれぞれ、リクエスト入力画面50(
図10)の付与ポイント入力欄54および付与ポイントスライダ55と同じ機能を持つものであり、詳細な説明は省略する。
【0143】
追加ポイントスライダ75の下方には、最高ポイント追加ボタン76が設けられる。最高ポイント追加ボタン76は、“合算ポイント値”が、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち、最も高い付与ポイント値」よりも「1pt」だけ高くなるような追加ポイント値を入力することを指示するボタンである。合算ポイント値とは、リクエストの現時点の付与ポイント値と、追加ポイント値とを合算した値を意味する。以下、「未対応リクエストのそれぞれの現時点の付与ポイント値のうち、最も高い付与ポイント値」を「他リクエスト最高値」という。例えば、他リクエスト最高値が3000ptであり、ユーザU1が追加ポイント値を追加しようとしているリクエストの現時点の付与ポイント値が1000ptであったとする。この場合にユーザU1が最高ポイント追加ボタン76を選択すると、追加ポイント値として「2001pt」が入力される。このとき合算ポイント値は「3001pt」(1000pt+2001pt)となり、他リクエスト最高値の「3000pt」よりも「1pt」だけ高くなる。
【0144】
最高ポイント追加ボタン76の下方には、合算ポイント画像77が表示される。合算ポイント画像77は、対応するリクエストの現時点の付与ポイント値と、ユーザU1により入力された追加ポイント値とを合算した値が表示される。合算ポイント画像77の下方には、入力された追加ポイント値が追加された場合にリクエストのリプライ優先順位が何番目になるかを示す暫定優先順位画像78が表示される。暫定優先順位画像78の下方には、入力を確定する確定ボタン79が設けられている。
【0145】
確定ボタン79が選択されると、サーバ制御部14は端末制御部6と協働して、ユーザU2のリクエスト管理データベース40の対応するレコードの付与ポイント<フィールド>の付与ポイント値について、入力された追加ポイント値の分、増加させる。あるリクエストに付与された付与ポイント値が、そのリクエストのリプライ優先順位に影響を与えることは上述した通りである。このようにサーバ制御部14は、ユーザがリクエストに対して追加ポイント値の追加を指示したときに、そのことを検出すると共に、リクエスト管理データベース40への反映、その他の追加ポイント値の追加を反映するための処理を実行する機能を備える。当該機能は、リクエストの投稿者に限られないユーザからリクエストへのポイント値の追加を受け付ける機能に相当する。
【0146】
以上の通りサーバ制御部14は、リクエストが投稿された後に、リクエストの投稿者に限られないユーザからリクエストへの追加ポイント値(ポイント値)の追加を受け付ける機能を備える。また端末制御部6は、リクエストカード44(リクエストに関する情報)が一覧表示されると共に、リクエストカード44と関連付けてポイント追加ボタン72(リクエストに追加する追加ポイント値を入力するためのオブジェクト)が表示された通常ボックス画面38X(画面)を提供する機能を備える。また端末制御部6は、追加ポイント値を入力するためのオブジェクトに入力された追加ポイント値がリクエストに追加された場合にリクエストの優先順位が何番目になるかを示す暫定優先順位画像78(情報)が表示された追加ポイント入力画面73(画面)を提供する機能を備える。また端末制御部6は、リクエストの優先順位が最も高くなる追加ポイント値を入力する最高ポイント追加ボタン76(ボタン)が表示された追加ポイント入力画面73(画面)を提供する機能を備える。
【0147】
本変形例の構成によればユーザは、所望のリクエストについて、所望の値だけ追加ポイント値を追加することができる。このためユーザは、別のユーザに対して既に他人により投稿されたリクエストについて、できるだけ早い段階で当該別のユーザにリプライして欲しい、或いは、当該別のユーザにリプライされる可能性をできるだけ上げたいと考えたときに、そのリクエストに対して追加ポイント値を追加することによって、そのリクエストのリプライ優先順位を上げることができる。
【0148】
なお変形例で示した画面は一例であり、異なる内容の画面が提供される構成でもよい。例えばポイント追加ボタン72が、リクエストカード44内に表示されるのではなく、リクエストカード44の外側でリクエストカード44と対応付けて表示される構成でもよい。また例えば、ポイント追加ボタン72に代えて、追加ポイント入力欄74などの追加ポイント値を直接的に入力するためのオブジェクトが設けられる構成でもよい。
【0149】
以上、本発明の一実施形態(変形例を含む)について説明したが、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【0150】
例えば抽出動画データを生成する処理は、上記実施形態で例示した処理に限定されない。一例としてサーバ制御部14が、ライブ配信中に、リプライの開始の通知を受けてから、リプライの終了の通知を受けるまでの期間に配信される動画をリアルタイムで録画(記録)し、録画結果に基づいて抽出動画データを生成する構成でもよい。すなわちサーバ制御部14の「リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能」について、抽出動画データを生成する具体的な処理は限定されず、どのような処理が行われてもよい。
【0151】
また例えば上述したように情報処理サーバ3は、単一の装置である必要はない。特に情報処理サーバ3は、ライブ配信を実現する1つ以上のサーバ装置と、それ以外の1つ以上のサーバ装置との組合せによって構成されていてもよい。情報処理サーバ3が複数のサーバ装置によって構成されている場合、複数のサーバ装置のサーバ制御部が協働して「制御部」として機能する。
【0152】
また例えば、リクエストに対して有効期限が設けられ、有効期限を超えてリプライされなかった場合、サーバ制御部14が、リクエストを破棄する構成としてもよい。リクエストの破棄は、例えば、破棄されたか否かを管理するフラグの制御によって行われる。
【0153】
また上記実施形態では、サーバ制御部14は、ライブ配信中に視聴者からコメントの投稿を受け付ける機能を備えていたが、この機能はなくてもよい。
【0154】
また例えば上記実施形態において、専用アプリの処理の一部または全部をウェブブラウザが代替して実行する構成でもよい。
【0155】
また例えば上記実施形態ではサーバ制御部14は、リプライの開始の通知に応じて、リプライ優先順位が最も高いリクエスト(リクエストカード44)を視聴者の端末2に表示させる構成であった。この点に関しサーバ制御部14が、表示させるリクエストを他の方法で選択する構成でもよい。例えばサーバ制御部14が、未対応リクエストの中から1つの未対応リクエストをランダムに決定する構成でもよい。また例えばサーバ制御部14が投稿されたタイミングが古いものを優先的に選択する構成でもよい。付与ポイント値がリプライ優先順位に影響を与えない構成の場合には、サーバ制御部14が付与ポイント値の付与を受け付ける機能を有していなくてもよい。また肯定評価数がリプライ優先順位に影響を与えない構成の場合には、サーバ制御部14が肯定評価の付与を受け付ける機能を有していなくてもよい。
【0156】
また本件ポイントは、本件サービスで流通する独自のポイントであった。しかしながら本件ポイントの具体的な内容は、本実施形態で例示した内容に限られない。例えば本件ポイントは、本件サービス以外のサービスで使用されるポイントであってもよい。また例えば本件ポイントは、法定通貨或いは暗号通貨であってもよい。
【0157】
また例えばサーバ制御部14が実行すると説明した処理の一部をサーバ制御部14と、情報処理サーバ3と通信可能な外部装置の情報処理機構とが協働して実行する構成としてもよい。この場合、情報処理サーバ3と外部装置とが協働して「情報処理装置」として機能する。この点は、端末制御部6、6L、6Aについても同様である。
【0158】
また例えば、端末2または情報処理サーバ3のコンピュータが実行するプログラムの提供、または、このプログラムをコンピュータで読み取り可能に記録した記録媒体の提供を実施形態に含めることができる。上記記録媒体としては、磁気的、光学的記録媒体又は半導体メモリーデバイスを用いることができる。具体的には、フレキシブルディスク、HDD(Hard DiSH Drive)、CD-ROM(Compact DiSH Read Only Memory)、DVD(Digital Versatile DiSH)、Blu-ray(登録商標)Disc、光磁気ディスク、フラッシュメモリ、カード型記録媒体等の可搬型の、或いは固定式の記録媒体が挙げられる。
【0159】
また例えば、例示したフローチャートについて、目的を実現でき、処理に矛盾が起こらない限り、処理の順番を変更したり、処理をより細かく分割したり、処理を追加したり、処理を削除したりしてもよい。
【符号の説明】
【0160】
1 情報処理システム
2 端末
3 情報処理サーバ(情報処理装置)
6 端末制御部
14 サーバ制御部(制御部)
【要約】
【課題】ライブ配信に係るサービスに関し、配信者の満足度を向上する。
【解決手段】情報処理サーバ3は、ライブ配信の配信者となり得る注目ユーザに対するリクエストの投稿をユーザから受け付ける機能と、注目ユーザによるライブ配信中にリクエストに対するリプライの開始の指示とリプライの終了の指示と受け付け、リプライの開始の指示があった場合、リクエストのうちの1つをライブ配信の視聴者の端末に表示させる機能と、リプライの開始から終了までの期間のライブ配信に係る動画が記録された抽出動画データを生成する機能とを有するサーバ制御部14を備える。
【選択図】
図2