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

Abstract

【課題】ライブ配信を通じて占い配信者が占いで報酬を得ることを容易にする。【解決手段】コンピュータプログラムは、配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データを、サーバからネットワークを介して受信する機能と、配信者と他の視聴者とが閲覧可能な通常情報の、視聴者による入力をライブ配信中に受け付ける機能と、視聴者による対価の支払いまたは支払いの承諾を条件として配信者の端末に送信される限定情報であって他の視聴者は閲覧できない限定情報の、当該視聴者による入力をライブ配信中に受け付ける機能と、を視聴者の端末に実現させる。【選択図】図１

Description

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

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

これまで対面で行われてきたサービスのひとつに占いがある。占い師と顧客とが向かい合って着席し、占い師が顧客と対話しながら占いを行う。この占いをライブ配信で行おうとする試みが、例えば非特許文献１に開示されている。昨今のコロナ禍により、占いライブ配信を行いたい、視聴したいという声も増えてきた。

「ケイブの対面占いライブ配信サービス『占占(sensen)』3月15日よりプレオープン」、株式会社ケイブ、URL:https://prtimes.jp/main/html/rd/p/000000928.000001290.html

顧客との対話を重要な要素の一つとする占いと、配信者と視聴者との双方向コミュニケーションを実現するライブ配信と、の親和性は高いので、占いライブ配信の需要は今後伸びていくことが期待される。しかしながら、従来の複数の視聴者が参加するライブ配信では、占い配信者が占いで報酬を得ることは容易ではない。

本開示はこうした課題に鑑みてなされたものであり、その目的は、ライブ配信を通じて占い配信者が占いで報酬を得ることを容易にすることができる技術の提供にある。

本開示のある態様は、コンピュータプログラムに関する。このコンピュータプログラムは、配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データを、サーバからネットワークを介して受信する機能と、配信者と他の視聴者とが閲覧可能な通常情報の、視聴者による入力をライブ配信中に受け付ける機能と、視聴者による対価の支払いまたは支払いの承諾を条件として配信者の端末に送信される限定情報であって他の視聴者は閲覧できない限定情報の、当該視聴者による入力をライブ配信中に受け付ける機能と、を視聴者の端末に実現させる。

本発明の別の態様は、サーバである。このサーバは、配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データの、当該配信者の端末から当該視聴者の端末への伝送を中継する手段と、視聴者により入力された通常情報を当該視聴者の端末からライブ配信中に受信する手段と、受信された通常情報を配信者の端末および他の視聴者の端末に送信する手段と、視聴者により入力された限定情報を、当該視聴者による対価の支払いまたは支払いの承諾があった場合に、配信者の端末に送信するが他の視聴者の端末には送信しない手段と、を備える。

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

本発明によれば、ライブ配信を通じて占い配信者が占いで報酬を得ることを容易にすることができる。

実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図２のテンプレートＤＢの一例を示すデータ構造図である。 図１のサーバの機能および構成を示すブロック図である。 図４のストリームＤＢの一例を示すデータ構造図である。 図４のユーザＤＢの一例を示すデータ構造図である。 図４のギフトＤＢの一例を示すデータ構造図である。 図４の対価設定ＤＢの一例を示すデータ構造図である。 ライブ配信システムにおける有料ＤＭの使用に係る一連の処理の流れを示すフローチャートである。 視聴者のユーザ端末のディスプレイに表示されるライブ配信選択画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、文字数問い合わせ領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、テンプレート利用問い合わせ領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、有料ＤＭ入力受け付け領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、テンプレート登録領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。 視聴者のユーザ端末のディスプレイに表示される、変形例に係るライブ配信ルーム画面の代表画面図である。 シークレットコメントの送信元の視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。

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

実施の形態に係るライブ配信システムでは、配信者が視聴者に占いを提供する占いライブ配信において、多数の視聴者が同じ占いライブ配信を視聴しているなかで特定の視聴者が他の視聴者に知られずに自己の情報を配信者に伝えるための手段が提供される。さらにこの手段は有料で視聴者に提供されるので、占いを行う配信者が報酬を得る手段としても機能する。これにより、視聴者にとっては自己の情報を安心して配信者に開示することができ、かつ、配信者にとっては報酬を得やすい占いライブ配信の仕組みが実現される。

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

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

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

本明細書において「動画データ」は、ユーザ端末２０、３０の撮像機能により生成される画像データ（ビデオデータともいう）と、ユーザ端末２０、３０の音声入力機能により生成される音声データ（オーディオデータともいう）と、を含むデータである。動画データは、ユーザ端末２０、３０で再生されることで、ユーザによるコンテンツの視聴を可能とする。本実施の形態では、動画データが配信者のユーザ端末で生成されてから視聴者のユーザ端末で再生されるまでの間に、圧縮や伸張や符号化や復号やトランスコーディングなどの、データの形式やサイズや仕様を変更する処理が行われることが想定されている。このような処理の前後で動画データが表す内容（例えば、動画像や音声）は実質的に変わらないので、本実施の形態ではそのような処理が行われた後の動画データはそのような処理が行われる前の動画データと同じであるとして説明する。すなわち、動画データが配信者のユーザ端末で生成されてからサーバ１０を経由して視聴者のユーザ端末で再生される場合、配信者のユーザ端末で生成された動画データと、サーバ１０を通過する動画データと、視聴者のユーザ端末で受信されて再生される動画データと、は全て同じ動画データである。

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

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

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

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

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

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

配信部１００は、撮像制御部１０２と、音声制御部１０４と、動画送信部１０６と、配信側ＵＩ制御部１０８と、を含む。撮像制御部１０２は図２では不図示のカメラと接続され、カメラによる撮像を制御する。撮像制御部１０２はカメラから画像データを取得する。音声制御部１０４は図２では不図示のマイクロフォンと接続され、マイクロフォンによる音声入力を制御する。音声制御部１０４は、マイクロフォンから音声データを取得する。動画送信部１０６は、撮像制御部１０２により取得された画像データおよび音声制御部１０４により取得された音声データを含む動画データを、ネットワークＮＷを介してサーバ１０に送信する。動画送信部１０６による動画データの送信はリアルタイムで行われる。すなわち、撮像制御部１０２および音声制御部１０４による動画データの生成と、生成された動画データの動画送信部１０６による送信と、は実質的に同時に行われる。配信側ＵＩ制御部１０８は、配信者向けのＵＩを制御する。配信側ＵＩ制御部１０８は、図２では不図示のディスプレイと接続され、動画送信部１０６による送信対象となっている動画データを再生することにより動画像をディスプレイに表示させる。配信側ＵＩ制御部１０８は、ディスプレイに操作用オブジェクトや指示受け付け用のオブジェクトを表示させ、配信者によるタップ入力を受け付ける。

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

視聴側ＵＩ制御部２０２は、入力手段を介した視聴者によるコメントの入力をライブ配信中に受け付ける。このコメントは上述のとおり、入力した視聴者および配信者のみならず当該ライブ配信に参加する他の視聴者も閲覧可能な通常情報である。このコメントは無料で、すなわち対価の支払いを必要とせずに、入力および送信が可能である。

ＤＭ受付部２０８は、視聴者による配信者宛の有料ＤＭ（Direct Message、ダイレクトメッセージ）の入力をライブ配信中に受け付ける。有料ＤＭは、視聴者による対価の支払いを条件として入力、送信されるＤＭである。この対価の支払いは占いライブ配信中に行われる。ＤＭは、入力した視聴者の他は宛先の配信者のみ閲覧可能なメッセージである。ＤＭは、入力した視聴者および配信者以外は閲覧できない限定情報であり、特にライブ配信の他の視聴者はＤＭを閲覧することができない。ＤＭ自体を実現する技術は公知であるから本明細書では詳述しない。ＤＭ受付部２０８の機能は後述する。

テンプレート登録部２１０は、視聴者により予め入力された有料ＤＭ用のテキストをテンプレートとしてテンプレートＤＢ１５０に登録する。テンプレート登録部２１０は、視聴者が占いライブ配信に参加する前に、テキストの入力を受け付けるテンプレート登録画面をユーザ端末３０のディスプレイに表示させる。テンプレート登録部２１０は、テンプレート登録画面に入力されたテキストをテンプレートとしてテンプレートＤＢ１５０に登録する。

図３は、図２のテンプレートＤＢ１５０の一例を示すデータ構造図である。テンプレートＤＢ１５０は、テンプレートを特定するテンプレＩＤと、テンプレートのテキストと、を対応付けて保持する。テキストは、視聴者が配信者に占ってもらう際に配信者に提供する情報を含んでもよく、例えば性別、年齢、住所などの情報を含んでもよい。また、テキストは、希望する占い対象（金運、恋愛運等）や占いの種類（タロット占い、占星術等）を含んでもよい。

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

図５は、図４のストリームＤＢ３１４の一例を示すデータ構造図である。ストリームＤＢ３１４は現在行われているライブ配信の情報を保持する。ストリームＤＢ３１４は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定するユーザＩＤである配信者ＩＤと、当該ライブ配信の視聴者を特定するユーザＩＤである視聴者ＩＤと、当該ライブ配信のジャンルと、を対応付けて保持する。本実施の形態に係るライブ配信システム１が提供するライブ配信プラットフォームでは、ユーザがライブ配信を行う場合そのユーザは配信者となり、また同じユーザが他のユーザが配信するライブ配信を視聴する場合は視聴者となる。したがって、配信者・視聴者の別は固定的なものではなく、あるとき配信者ＩＤとして登録されていたユーザＩＤが別のタイミングでは視聴者ＩＤとして登録されることもある。ライブ配信のジャンルは、配信者が配信を開始する際に配信者によって指定されてもよいし、または、サーバ１０において機械学習モデルにより自動的に判別されてもよい。

図６は、図４のユーザＤＢ３１８の一例を示すデータ構造図である。ユーザＤＢ３１８は、ユーザに関する情報を保持する。ユーザＤＢ３１８は、ユーザを特定するユーザＩＤと、ライブ配信プラットフォームにおける当該ユーザの配信者としての評価を表す配信者レベルと、当該ユーザの占い配信者としてのレベルを表す占いレベルと、当該ユーザが有しているポイントと、を対応付けて保持する。ポイントは、ライブ配信プラットフォーム内で流通する電子的価値である。配信者がライブ配信において視聴者からギフトを贈られると、配信者のポイントが当該ギフトに対応する値だけ増加する。ポイントは例えば配信者がライブ配信プラットフォームの管理者から受け取る報酬または金銭の額を決めるために用いられる。あるいはまた、配信者が視聴者からギフトを贈られた場合に、ポイントではなく当該ギフトに対応する金銭の額が配信者に付与される仕組みが採用されてもよい。

占いレベルは、ライブ配信プラットフォームにおける占い配信者の占いのレベルを表す指標である。占いレベルは、占い配信者に対するレビューやユーザ満足度や配信内のコメントを基に管理者により評価、決定されてもよい。あるいはまた、占いレベルは、所定のルールまたは機械学習モデルにより自動的に決定されてもよい。

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

ギフトＤＢ３２０は、ギフトを特定するギフトＩＤと、当該ギフトを配信者に贈った場合に当該配信者に付与されるポイントである付与ポイントと、当該ギフトを使用する際に支払うべき対価である対価ポイントと、を対応付けて保持する。視聴者は、ライブ配信視聴中に、所望のギフトの対価ポイントを支払うことで配信者に当該ギフトを贈ることができる。この対価ポイントの支払いは適宜の電子的決済手段により行われてもよく、例えば対価ポイントを視聴者が管理者に支払うことで行われてもよい。あるいはまた、銀行振込やクレジットカードによる支払いが用いられてもよい。付与ポイントと対価ポイントとの関係は管理者が任意に設定可能である。例えば、付与ポイント＝対価ポイントに設定してもよい。または付与ポイントに１．２などの所定の係数を乗じて得られるポイントを対価ポイントに設定してもよいし、付与ポイントに所定の手数料ポイントを加算して得られるポイントを対価ポイントに設定してもよい。

図８は、図４の対価設定ＤＢ３２２の一例を示すデータ構造図である。対価設定ＤＢ３２２は、有料ＤＭの対価の設定を保持する。対価設定ＤＢ３２２において対価は、（１）有料ＤＭの上限文字数が多いほど高くなるよう、かつ、（２）占い配信者の占いレベルが高いほど高くなるよう、設定される。図８では例えば占いレベル「３」の配信者に上限文字数１００の有料ＤＭを送る場合、８００ポイントを支払う必要があることが示される。有料ＤＭを送る視聴者によって支払われた対価の少なくとも一部は占い配信者に付与される。対価設定ＤＢ３２２の内容は管理者によって決定、入力されてもよい。あるいはまた、占い配信者ごとに対価設定ＤＢを設け、各占い配信者が自分の対価設定ＤＢの内容を自分で入力、決定できるよう構成してもよい。

図４に戻り、配信情報提供部３０２は、ネットワークＮＷを介して、配信者側のユーザ端末２０からライブ配信を開始する旨の通知を受けると、当該ライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者の配信者ＩＤと、をストリームＤＢ３１４に登録する。配信情報提供部３０２は、ネットワークＮＷを介して、視聴者側のユーザ端末３０の視聴部２００からライブ配信に関する情報の提供要求を受けると、ストリームＤＢ３１４を参照して現在視聴可能なライブ配信のリストを生成する。配信情報提供部３０２は、生成されたリストに含まれる占いライブ配信（ジャンルが占いとなっているライブ配信）のそれぞれについて、ユーザＤＢ３１８を参照し、当該占いライブ配信の配信者の占いレベルを特定する。配信情報提供部３０２は、特定の結果、すなわち各占いライブ配信に対して特定された占いレベルをリストに追加する。配信情報提供部３０２は、ネットワークＮＷを介して、生成されたリストを要求元のユーザ端末３０に送信する。要求元のユーザ端末３０の視聴側ＵＩ制御部２０２は、受信したリストに基づいてライブ配信選択画面を生成し、ユーザ端末３０のディスプレイに表示させる。

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

中継部３０４は、配信情報提供部３０２によって開始されたライブ配信において、配信者側のユーザ端末２０から視聴者側のユーザ端末３０への動画データの伝送を中継する。中継部３０４は、ライブ配信中すなわち動画データの再生中における視聴者によるユーザ入力を示す信号を入力情報送信部２０６から受信する。ユーザ入力を示す信号は、ユーザ端末３０のディスプレに表示されたオブジェクトの指定を示すオブジェクト指定信号であってもよく、当該オブジェクト指定信号は、視聴者の視聴者ＩＤと、視聴者が視聴しているライブ配信を行っている配信者の配信者ＩＤと、オブジェクトを特定するオブジェクトＩＤと、を含む。オブジェクトがギフトである場合、オブジェクトＩＤはギフトＩＤとなる。同様に、中継部３０４は、動画データの再生中における配信者によるユーザ入力を示す信号、例えばオブジェクト指定信号をユーザ端末２０の配信部１００から受信する。あるいはまた、ユーザ入力を示す信号は、視聴者がユーザ端末３０に入力したコメントと当該視聴者の視聴者ＩＤとを含むコメント入力信号であってもよい。中継部３０４は、コメント入力信号を受信すると、当該信号に含まれるコメントおよび視聴者ＩＤを、配信者のユーザ端末２０および他の視聴者のユーザ端末３０に送信する。それらのユーザ端末２０、３０では、視聴側ＵＩ制御部２０２と重畳情報生成部２０４とが協働し、受信したコメントを、同じく受信した視聴者ＩＤと対応付けてディスプレイに表示させる。

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

支払い処理部３１０は、オブジェクト指定信号の受信に応じて、視聴者によるギフトの対価の支払いを処理する。支払い処理部３１０は、ギフトＤＢ３２０を参照し、オブジェクト指定信号に含まれるギフトＩＤで特定されるギフトの対価ポイントを特定する。支払い処理部３１０は、オブジェクト指定信号に含まれる視聴者ＩＤで特定される視聴者のポイントから特定された対価ポイントを差し引くようユーザＤＢ３１８を更新する。

ＤＭ処理部３１２は、ユーザ端末２０、３０のＤＭ受付部２０８と協働して有料ＤＭに関する処理を行う。ＤＭ処理部３１２の機能は後述する。

以上の構成によるライブ配信システム１の動作を説明する。
図９は、ライブ配信システム１における有料ＤＭの使用に係る一連の処理の流れを示すフローチャートである。図９では、所定の視聴者が自己のユーザ端末３０で、占い配信者の占いライブ配信を視聴していることを前提する。ユーザ端末３０のＤＭ受付部２０８は、ライブ配信ルーム画面に表示されている有料ＤＭオブジェクトがタップされるまで待機する（Ｓ２０２）。ＤＭ受付部２０８は、有料ＤＭオブジェクトへのタップを検出すると（Ｓ２０２のＹ）、上限文字数ごとに対応する対価を提示して視聴者に希望の上限文字数を問い合わせる（Ｓ２０４）。ＤＭ受付部２０８は、視聴者による希望の上限文字数の指定を受け付ける（Ｓ２０６）。ＤＭ受付部２０８はサーバ１０のＤＭ処理部３１２と協働することにより対価の支払い処理を行う（Ｓ２０８）。ＤＭ受付部２０８は、有料ＤＭの入力受け付けに先立ち、入力にテンプレートを利用するか否かを視聴者に問い合わせる（Ｓ２１０）。例えばＤＭ受付部２０８は使用可能なテンプレートテキストのリストをテンプレートＤＢ１５０から読み出し、視聴者に提示する。

視聴者からテンプレート利用指示を受け付けた場合（Ｓ２１０のＹ）、ＤＭ受付部２０８は、指示されたテンプレートを有料ＤＭとして入力する（Ｓ２１２）。その後、処理はステップＳ２１６に進む。ステップＳ２１０において視聴者がテンプレート利用を拒否した場合、ＤＭ受付部２０８は視聴者による有料ＤＭの入力を受け付ける（Ｓ２１４）。ＤＭ受付部２０８は、ネットワークＮＷを介してサーバ１０のＤＭ処理部３１２に、入力された有料ＤＭを送信する（Ｓ２１６）。ＤＭ処理部３１２は、受信した有料ＤＭを占い配信者のユーザ端末２０にのみ送信する。占い配信者のユーザ端末２０の視聴側ＵＩ制御部２０２は、受信した有料ＤＭをディスプレイに表示させる。

図１０は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信選択画面６００の代表画面図である。ライブ配信選択画面６００は、サーバ１０から受信した現在視聴可能なライブ配信のリストにある各ライブ配信を示すサムネイル６０２、６０４を含む。視聴側ＵＩ制御部２０２は、サーバ１０から取得したライブ配信のリストに基づいてライブ配信選択画面６００を生成し、ディスプレイに表示させる。視聴側ＵＩ制御部２０２は、リストに含まれる占いレベルに応じたバッジ６０６を、対応する占いライブ配信のサムネイル６０２に付加する。例えば、本実施の形態では占いレベルは低い方から１、２、３、４、５の５段階に設定されており、そのそれぞれのレベルに対応するバッジが設定されている。このようにバッジを示すことで、視聴者は自分の求める占いレベルの占い配信者を見つけやすくなる。加えて、占い配信者は提供する占いの質をアピールすることが可能となる。

ライブ配信選択画面６００では、高い占いレベルの占い配信者の占いライブ配信のサムネイルは、より低い占いレベルの占い配信者の占いライブ配信のサムネイルよりも目立つ位置、例えば画面の上部、に配置される。これにより、ライブ配信プラットフォームにおいて、占いの質の高い占い配信者の占いライブ配信をプロモートすることができる。

図１１は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８の代表画面図である。ライブ配信ルーム画面６０８は、サーバ１０から受信した動画データを再生することにより得られる占い配信者の画像６１０と、ギフトオブジェクト６１２と、有料ＤＭオブジェクト６１４と、コメント入力領域６１６と、コメント表示領域６１８と、バッジ６２０と、を有する。

視聴者がギフトオブジェクト６１２をタップすると、重畳情報生成部２０４はギフトの選択を受け付けるためのギフトタブを生成し、視聴側ＵＩ制御部２０２が生成されたギフトタブをライブ配信ルーム画面６０８に表示させる。

コメント表示領域６１８は、視聴者により入力されたコメントと、他の視聴者により入力されたコメントと、を含みうる。重畳情報生成部２０４はサーバ１０から受信した他の視聴者のコメントを含むコメント表示領域６１８を生成し、視聴側ＵＩ制御部２０２は生成されたコメント表示領域６１８をライブ配信ルーム画面６０８に含める。

コメント入力領域６１６は視聴者によるコメントの入力を受け付ける。入力情報送信部２０６は、コメント入力領域６１６に入力されたコメントを含むコメント入力信号を生成し、ネットワークＮＷを介してサーバ１０に送信する。併せて重畳情報生成部２０４は、コメント入力領域６１６に入力されたコメントを表示するようにコメント表示領域６１８を更新する。

バッジ６２０は上述のバッジ６０６に対応し、ライブ配信プラットフォームにおける占い配信者のレベルを示す。

視聴者は占い配信者に占ってもらうために、有料ＤＭオブジェクト６１４を指定またはタップする。ＤＭ受付部２０８は、視聴者による有料ＤＭオブジェクト６１４の指定を受け付けると、占いライブ配信を行っている占い配信者の配信者ＩＤを含む対価情報要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０のＤＭ処理部３１２は、受信した対価情報要求に含まれる配信者ＩＤに対応する占いレベルを、ユーザＤＢ３１８を参照して特定する。ＤＭ処理部３１２は、特定された占いレベルに対応する対価の設定を、対価設定ＤＢ３２２から取得する。ＤＭ処理部３１２は、取得された対価の設定を、ネットワークＮＷを介して要求元のユーザ端末３０に送信する。ユーザ端末３０のＤＭ受付部２０８は、受信した対価の設定に基づいて文字数問い合わせ領域６２２を生成し、生成された文字数問い合わせ領域６２２をライブ配信ルーム画面６０８に重畳表示させる。

図１２は、視聴者のユーザ端末３０のディスプレイに表示される、文字数問い合わせ領域６２２が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。文字数問い合わせ領域６２２は、上限文字数ごとに対応する対価を提示して視聴者に希望の上限文字数を問い合わせるための領域である。ＤＭ受付部２０８は、上限文字数と対価との組を文字数問い合わせ領域６２２に選択可能な形態で含める。文字数問い合わせ領域６２２において視聴者は、「上限文字数＝１０、対価＝２００ポイント」、「上限文字数＝５０、対価＝４００ポイント」、「上限文字数＝１００、対価＝８００ポイント」の３つのオプションのなかから希望のオプションをラジオボタンにより選択する。視聴者が文字数問い合わせ領域６２２内の「有料ＤＭを送る」ボタンをタップすると、ＤＭ受付部２０８はラジオボタンにより選択されたオプションに対応する上限文字数を希望の上限文字数として受け付ける。ＤＭ受付部２０８は、占い配信者の配信者ＩＤと視聴者の視聴者ＩＤとラジオボタンにより選択されたオプションに対応する対価とを含むＤＭ清算要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０のＤＭ処理部３１２は、受信したＤＭ清算要求に含まれる対価を、ＤＭ清算要求に含まれる視聴者ＩＤで特定される視聴者のポイントから差し引くようユーザＤＢ３１８を更新する。併せてＤＭ処理部３１２は、ＤＭ清算要求に含まれる配信者ＩＤに対応するポイントに、受信したＤＭ清算要求に含まれる対価に応じたポイントを加えるようユーザＤＢ３１８を更新する。加えるポイントの量は、対価と同じに設定されてもよいし、対価に所定の係数、例えば０．９等を乗じることで得られるポイントに設定されてもよい。ＤＭ処理部３１２は、これらの対価の清算が完了すると、清算完了応答を生成し、ネットワークＮＷを介して要求元のユーザ端末３０に送信する。ユーザ端末３０のＤＭ受付部２０８は、清算完了応答を受信すると、テンプレート利用問い合わせ領域６２４を生成し、生成されたテンプレート利用問い合わせ領域６２４をライブ配信ルーム画面６０８に重畳表示させる。

図１３は、視聴者のユーザ端末３０のディスプレイに表示される、テンプレート利用問い合わせ領域６２４が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。テンプレート利用問い合わせ領域６２４は、有料ＤＭの入力受け付けに先立ち、入力にテンプレートを利用するか否かを視聴者に問い合わせるための領域である。ＤＭ受付部２０８はテンプレートＤＢ１５０に保持されているテンプレートを読み出し、読み出された各テンプレートをテンプレート利用問い合わせ領域６２４に選択可能な形態で含める。この際、ＤＭ受付部２０８は指定された上限文字数を超えるテンプレートは読み出さないか、指定された上限文字数まで読み出す（すなわち、文章は途中で切れる）ようにしてもよい。テンプレート利用問い合わせ領域６２４において視聴者は、提示されたテンプレートのなかから希望のテンプレートをラジオボタンにより選択する。視聴者がテンプレート利用問い合わせ領域６２４内の「利用する」ボタンをタップすると、ＤＭ受付部２０８はラジオボタンにより選択されたテンプレートを希望のテンプレートとして受け付ける。ＤＭ受付部２０８は、受け付けた希望のテンプレートが事前入力された有料ＤＭ入力受け付け領域６２６を生成し、生成された有料ＤＭ入力受け付け領域６２６をライブ配信ルーム画面６０８に重畳表示させる。

あるいはまた、テンプレート利用を希望しない視聴者は、テンプレート利用問い合わせ領域６２４内の「利用しない」ボタンをタップする。ＤＭ受付部２０８は、当該ボタンへのタップを検出すると、事前入力のない有料ＤＭ入力受け付け領域６２６を生成し、生成された有料ＤＭ入力受け付け領域６２６をライブ配信ルーム画面６０８に重畳表示させる。

図１４は、視聴者のユーザ端末３０のディスプレイに表示される、有料ＤＭ入力受け付け領域６２６が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。有料ＤＭ入力受け付け領域６２６は、視聴者による有料ＤＭの入力を受け付けるための領域である。有料ＤＭ入力受け付け領域６２６は、図１２において視聴者により指定された上限文字数を表示する上限文字数表示領域６２８と、テキストの入力を受け付けるテキスト入力領域６３０と、送信ボタン６３２と、を有する。図１３においてテンプレートの利用が指示されている場合、ＤＭ受付部２０８はテキスト入力領域６３０に指示されたテンプレートを事前入力する。有料ＤＭ入力受け付け領域６２６において視聴者は、所望のテキストをテキスト入力領域６３０に入力し、送信ボタン６３２をタップする。ＤＭ受付部２０８は、送信ボタン６３２へのタップを検出すると、テキスト入力領域６３０に入力されているテキストを取得する。ＤＭ受付部２０８は、ネットワークＮＷを介してサーバ１０のＤＭ処理部３１２に、取得されたテキストを送信する。ＤＭ処理部３１２は、受信したテキストを占い配信者のユーザ端末２０にのみ送信する。ＤＭ処理部３１２は、占いライブ配信の他の視聴者のユーザ端末には当該テキストを送信しない。ＤＭ受付部２０８は、送信ボタン６３２へのタップを検出すると、テンプレート登録領域６３４を生成し、生成されたテンプレート登録領域６３４をライブ配信ルーム画面６０８に重畳表示させる。

図１５は、視聴者のユーザ端末３０のディスプレイに表示される、テンプレート登録領域６３４が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。テンプレート登録領域６３４は、図１４において入力、送信された有料ＤＭのテキストを表示する送信済みＤＭ表示領域６３６と、図１３においてテンプレートを利用しないことを選択した場合に表示されるテンプレート登録問い合わせ領域６３８と、を有する。視聴者は、図１４において入力、送信された有料ＤＭのテキストを、次回以降再利用するためのテンプレートとして保存したい場合、テンプレート登録問い合わせ領域６３８内の「はい」ボタンをタップする。テンプレート登録部２１０は、当該ボタンへのタップを検出すると、送信済みの有料ＤＭのテキストをテンプレートＤＢ１５０にテンプレートとして登録する。

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

本実施の形態に係るライブ配信システム１によると、占いライブ配信の視聴者には他の視聴者に見られることなく安全に自己の情報を占い配信者に届ける仕組みが提供される。したがって、占いライブ配信で占ってもらうことに対するハードルが下がり、占いライブ配信をより普及させることができる。また、占い配信者には自分の占いへの対価を視聴者から直接受け取ることができる仕組みが提供される。したがって、占い配信者は占いに対する報酬をより確実および／またはスムーズに得ることができる。そして、メッセージの秘匿と対価の支払いとの二つを一つのアクションで完了することを可能としたので、ユーザ利便性を高めることができる。

また、配信者へのＤＭを有料とすることで、配信者へのＤＭを用いた嫌がらせを軽減することができる。

また、本実施の形態に係るライブ配信システム１では、占いレベルを導入し、当該レベルに応じて占いの対価を設定する。したがって、占いの技量を正しく評価し、その評価が報酬という形で還元される仕組みが提供される。これにより、高い占いの技量を持った占い配信者にとって魅力のあるライブ配信プラットフォームを実現できる。

また、本実施の形態に係るライブ配信システム１では、「占い師としての技量」が評価される場を作ることで、配信者間、視聴者間共に占い文化の醸成を図ることができる。

また、本実施の形態に係るライブ配信システム１では、有料ＤＭの入力時に予め作成しておいたテンプレートを利用することを可能とした。これにより、基本的にリアルタイムのレスポンスが要求されるライブ配信中に、比較的長文の有料ＤＭを迅速に入力することができる。その結果、視聴者は、占いライブ配信の流れを邪魔することなく有料ＤＭにより占いを依頼することができる。

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

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

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

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

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

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

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

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

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

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

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

実施の形態では、有料ＤＭを他の視聴者は閲覧できない限定情報として用いる場合を説明したが、これに限られない。例えば、通常のコメントの他に送信元の視聴者および配信者以外には表示されないシークレットコメントを設け、当該シークレットコメントを有料で入力できるように構成してもよい。

図１７は、視聴者のユーザ端末３０のディスプレイに表示される、変形例に係るライブ配信ルーム画面６４０の代表画面図である。ライブ配信ルーム画面６４０は、サーバ１０から受信した動画データを再生することにより得られる占い配信者の画像６１０と、ギフトの選択を受け付けるためのギフトタブ６４４と、コメント表示領域６１８と、バッジ６２０と、を有する。図１７のライブ配信ルーム画面６４０は、図１１のライブ配信ルーム画面６０８においてギフトオブジェクト６１２へのタップが検出されたときの遷移先の画面に対応する。

変形例に係るユーザ端末３０は、ライブ配信ルーム画面においてギフトオブジェクトへのタップが検出されると、ライブ配信のストリームＩＤを含むギフト情報要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０は、ギフト情報要求を受信すると、ギフトＤＢ３２０を参照して使用可能なギフトのギフトＩＤを特定する。この際、サーバ１０はストリームＤＢ３１４を参照し、受信されたギフト情報要求に含まれるストリームＩＤで特定されるライブ配信のジャンルを特定する。

本変形例に係るギフトＤＢ３２０は、どのジャンルのライブ配信でも使用可能な通常のギフトのギフトＩＤ（例えば、図７の「ＴＴ０１」、「ＴＥ０１」）と、特定のジャンルのライブ配信でのみ使用可能な特別ギフトのギフトＩＤ（例えば、図７の「ＷＴＳ１０」、「ＷＴＳ５０」、「ＷＴＳ１００」）と、を保持する。本例では特定のジャンルは占いであり、特別ギフトはシークレットコメントの送信を可能とするシークレットコメントギフトである。

サーバ１０は、特定されたジャンルが占いである場合、シークレットコメントギフトを使用可能なギフトとして特定し、特定されたジャンルが占いでない場合、シークレットコメントギフトを使用可能なギフトとして特定しない。サーバ１０は、特定されたギフトＩＤを含むギフト情報を生成し、要求元のユーザ端末３０に送信する。ユーザ端末３０は、ギフト情報に含まれるギフトＩＤで特定されるギフトのギフトオブジェクトをギフトタブ６４４に表示する。

図１７において、ギフトタブ６４４は、３つのシークレットコメントギフトオブジェクト６４６、６４８、６５０と、通常のギフトに対応する通常ギフトオブジェクト６５２と、を含む。シークレットコメントギフトオブジェクト６４６は、図７のギフトＩＤ「ＷＴＳ１０」で特定されるシークレットコメントギフトに対応する。当該ギフトは、対価５０ポイントを支払って上限１０文字のシークレットコメントを占い配信者に送信する権利を得ることを可能とするギフトである。他のシークレットコメントギフトオブジェクト６４８、６５０についても同様である。

図１７のライブ配信ルーム画面６４０において視聴者が希望の文字数のシークレットコメントギフトオブジェクトをタップすると、図９および図１２、図１３、図１４を参照して上述した対価支払い処理、テンプレート利用問い合わせ処理、限定情報入力・送信処理と同様の処理が実行され、送信元の視聴者および配信者のみが閲覧可能なシークレットコメントが配信者のユーザ端末２０および送信元の視聴者のユーザ端末３０に表示される。特にサーバ１０は、シークレットコメントを占い配信者のユーザ端末２０に送信し、他の視聴者のユーザ端末には送信しない。

図１８は、シークレットコメントの送信元の視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６６０の代表画面図である。ライブ配信ルーム画面６６０は、占い配信者の画像６１０と、図１７の状態から更新されたコメント表示領域６５４と、シークレットコメントギフトに対応するエフェクト６５８と、を有する。ユーザ端末３０は、シークレットコメントギフトが使用され、シークレットコメントが入力・送信されると、シークレットコメント６５６を表示するようにコメント表示領域６５４を更新する。シークレットコメント６５６は通常のコメントとは異なる態様で表示される。図１８の例では、通常のコメントの枠は実線で表示されるのに対し、シークレットコメント６５６の枠は破線で表示され、かつ、シークレットコメントであることを示す鍵のマークが付与される。ユーザ端末３０はまた、シークレットコメントギフトが使用されると、当該ギフトに対応するエフェクト６５８を占いライブ配信中にライブ配信ルーム画面６６０に表示させる。このエフェクト６５８は、配信者のユーザ端末２０のディスプレイにも表示される。このエフェクト６５８は、他の視聴者のユーザ端末のディスプレイに表示されてもよいし、されなくてもよい。表示される場合は、他の視聴者はシークレットコメントが送信されたことを知ることはできるが、その内容を知ることはできない。

シークレットコメントギフトの対価について、上記の例では管理者が決定してギフトＤＢ３２０に登録する。他の例では実施の形態と同様に占い配信者の占いレベルに応じて動的に対価を設定してもよい。

実施の形態では、占いレベルに応じて対価の額を設定する場合を説明したが、これに限られず、他の指標、例えば配信者レベルに応じて対価の額を設定してもよい。

実施の形態では、占いレベルおよび上限文字数に応じて対価の額を設定する場合を説明したが、これに限られず、例えば占いレベルに依らず上限文字数に応じて対価の額を設定してもよいし、上限文字数に依らず占いレベルに応じて対価の額を設定してもよいし、あるいは対価の額を固定値としてもよい。

実施の形態では、視聴者が予めテンプレートを作成して保存する場合を説明したが、これに限られず、例えばユーザ端末３０が視聴者のプロフィール情報からテンプレートを自動的に作成してもよい。あるいはまた、プロフィール情報をテンプレートとして選択できるよう構成してもよい。あるいはまた、ユーザ端末３０は、管理者により設定された少なくともひとつの質問を視聴者に提示し、当該質問への回答をそのまま有料ＤＭとしてサーバ１０に送信してもよいし、当該質問への回答から、事前入力する有料ＤＭのテキストを自動的に作成してもよい。あるいはまた、この少なくともひとつの質問は占い配信者が個別に設定できるように構成されてもよい。

実施の形態では、占いライブ配信において視聴者が対価を支払って限定情報を送信する場合を説明したが、これに限られない。占い以外の、他人に見せたくない情報を配信者のみに届けることに価値があるサービスに本実施の形態に係る技術的思想を適用できる。

実施の形態では、視聴者による対価の支払いを条件として、他の視聴者は閲覧できない限定情報（有料ＤＭ）の、視聴者による入力をライブ配信中に受け付ける場合を説明したが、これに限られず、例えば、先に限定情報の入力を受け付けておいて、対価の支払いを条件として当該限定情報をサーバに送信するようにしてもよい。あるいはまた、先に限定情報の入力を受け付け、入力された限定情報をサーバに送信し、当該サーバにおいて対価の支払いを条件として当該限定情報を配信者のユーザ端末に送信するようにしてもよい。いずれの場合でも、限定情報は入力した視聴者以外の他の視聴者は閲覧できない情報であると共に、視聴者による対価の支払いを条件として配信者の端末に送信される情報であるといえる。

先に限定情報の入力を受け付ける場合、従量課金制が採用されてもよい。例えば、ユーザ端末３０は視聴者による有料ＤＭのテキストの入力を受け付ける。ユーザ端末３０は、所定のレート（例えば、１文字１ポイント）を用いて、入力されたテキストの対価を算出する。ユーザ端末３０は、算出された対価を視聴者に提示し、対価の支払いに同意するか否かを視聴者に問い合わせる。ユーザ端末３０は、対価の支払いへの同意を受け付けると、入力されたテキストをサーバ１０に送信する。所定のレートは、占い配信者の占いレベルに応じたレートであってもよく、例えば占いレベルが高いほど高いレートが設定されてもよい。この場合、視聴者は文字数を気にせずに自由に有料ＤＭを入力することができる。

実施の形態では、有料ＤＭオブジェクト６１４をタップすることで有料ＤＭの入力が可能となる場合を説明したが、これに限られない。例えばユーザ端末３０はライブ配信ルーム画面に対する左向きまたは右向きのフリック／スワイプを検出すると、ライブ配信ルーム画面をダークモードに遷移させてもよい。ユーザ端末３０は、ダークモードのライブ配信ルーム画面で受け付けるコメントをシークレットコメントとして処理する。

実施の形態では、視聴者による対価の支払いの処理をサーバ１０において完了してから有料ＤＭの入力を可能とする場合を説明したが、これに限られず、視聴者による対価の支払いの承諾を受け付けると有料ＤＭの入力を可能とするようにしてもよい。この場合、実際の対価の支払い処理は有料ＤＭの入力や送信と並行して、またはその後で行われてもよい。

実施の形態におけるギフトの対価ポイントから付与ポイントへの換算率は一例であって、これらは例えばライブ配信システムの管理者により適宜設定されてもよい。

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

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

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

Claims (9)

1. 配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データを、サーバからネットワークを介して受信する機能と、
   配信者と他の視聴者とが閲覧可能な通常情報の、視聴者による入力をライブ配信中に受け付ける機能と、
   視聴者による対価の支払いまたは支払いの承諾を条件として配信者の端末に送信される限定情報であって他の視聴者は閲覧できない限定情報の、当該視聴者による入力をライブ配信中に受け付ける機能と、を視聴者の端末に実現させ、
   対価は、限定情報の文字数が多いほど高くなるよう設定されるコンピュータプログラム。
2. 視聴者によって支払われた対価の少なくとも一部は配信者に付与される請求項１に記載のコンピュータプログラム。
3. 予め入力された限定情報を保持部に登録する機能をさらに前記端末に実現させ、
   前記限定情報の入力を受け付ける機能は、前記保持部に保持されている限定情報を読み出す機能を含む請求項１に記載のコンピュータプログラム。
4. 入力された限定情報に対応するエフェクトをライブ配信中にディスプレイに表示させる機能をさらに前記端末に実現させ、
   当該エフェクトは他の視聴者の端末のディスプレイにも表示される請求項１に記載のコンピュータプログラム。
5. ライブ配信は占いジャンルのライブ配信である請求項１に記載のコンピュータプログラム。
6. 配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データを、サーバからネットワークを介して受信する手段と、
   配信者と他の視聴者とが閲覧可能な通常情報の、視聴者による入力をライブ配信中に受け付ける手段と、
   視聴者による対価の支払いまたは支払いの承諾を条件として配信者の端末に送信される限定情報であって他の視聴者は閲覧できない限定情報の、当該視聴者による入力をライブ配信中に受け付ける手段と、を備え、
   対価は、限定情報の文字数が多いほど高くなるよう設定される端末。
7. 配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データの、当該配信者の端末から当該視聴者の端末への伝送を中継する手段と、
   視聴者により入力された通常情報を当該視聴者の端末からライブ配信中に受信する手段と、
   受信された通常情報を配信者の端末および他の視聴者の端末に送信する手段と、
   視聴者により入力された限定情報を、当該視聴者による対価の支払いまたは支払いの承諾があった場合に、配信者の端末に送信するが他の視聴者の端末には送信しない手段と、を備え、
   対価は、限定情報の文字数が多いほど高くなるよう設定されるサーバ。
8. 配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データを、サーバからネットワークを介して受信する機能と、
   配信者と他の視聴者とが閲覧可能な通常情報の、視聴者による入力をライブ配信中に受け付ける機能と、
   視聴者による対価の支払いまたは支払いの承諾を条件として配信者の端末に送信される限定情報であって他の視聴者は閲覧できない限定情報の、当該視聴者による入力をライブ配信中に受け付ける機能と、を視聴者の端末に実現させ、
   対価は、ライブ配信プラットフォームにおける配信者のレベルに対応するよう設定されるコンピュータプログラム。
9. 配信者と視聴者と他の視聴者とが参加するライブ配信に係る動画データの、当該配信者の端末から当該視聴者の端末への伝送を中継する手段と、
   視聴者により入力された通常情報を当該視聴者の端末からライブ配信中に受信する手段と、
   受信された通常情報を配信者の端末および他の視聴者の端末に送信する手段と、
   視聴者により入力された限定情報を、当該視聴者による対価の支払いまたは支払いの承諾があった場合に、配信者の端末に送信するが他の視聴者の端末には送信しない手段と、を備え、
   対価は、ライブ配信プラットフォームにおける配信者のレベルに対応するよう設定されるサーバ。

Images