JP2023056436A - プログラム、情報処理方法、情報処理装置 - Google Patents

プログラム、情報処理方法、情報処理装置 Download PDF

Info

Publication number
JP2023056436A
JP2023056436A JP2021165819A JP2021165819A JP2023056436A JP 2023056436 A JP2023056436 A JP 2023056436A JP 2021165819 A JP2021165819 A JP 2021165819A JP 2021165819 A JP2021165819 A JP 2021165819A JP 2023056436 A JP2023056436 A JP 2023056436A
Authority
JP
Japan
Prior art keywords
user
level
terminal
control unit
live
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021165819A
Other languages
English (en)
Inventor
崇史 相羽
Takashi Aiba
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Z Intermediate Global Corp
Original Assignee
Line Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Line Corp filed Critical Line Corp
Priority to JP2021165819A priority Critical patent/JP2023056436A/ja
Publication of JP2023056436A publication Critical patent/JP2023056436A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Figure 2023056436000001
【課題】ライブ配信に関する興趣や利便性等を向上させるプログラムおよび情報処理装置を提供する。
【解決手段】通信システム１において、ライブ動画が配信される端末２０Ａと通信するサーバ１０によって実行されるプログラムは、端末２０Ａにおいて視聴者行動が行われた場合に、端末２０Ａのユーザに第１ポイントを付与する制御と、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御と、ユーザがライブ動画の配信者となる場合に、第１ポイントと第１レベルの少なくとも一方に基づいて、ユーザの第２レベルを決定する制御とを、制御部１１に行わせる。
【選択図】図１－１

Description

本開示は、プログラム、情報処理方法、情報処理装置等に関する。
ライブストリーミング等を利用して、ユーザが動画配信を行うことを可能にするサービスがある（例えば、特許文献１，特許文献２）。
特開２０２０－２１４６４号公報 特開２０２１－１２０９００号公報
本発明の第１の態様によると、ライブ動画が配信される端末と通信する情報処理装置によって実行されるプログラムは、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を情報処理装置の制御部によって行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を制御部によって行うことと、ユーザがライブ動画の配信者となる場合に、第１ポイントと第１レベルの少なくとも一方に基づいて、ユーザの第２レベルを決定する制御を制御部によって行うことと、を含む。
本発明の第２の態様によると、ライブ動画が配信される端末と通信する情報処理装置によって実行されるプログラムは、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を情報処理装置の制御部によって行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を制御部によって行うことと、ユーザがライブ動画を配信した場合に、少なくとも配信実績に基づいて、第１ポイントとは異なる第２ポイントをユーザに付与する制御を制御部によって行うことと、第２ポイントの増加に基づいて、ユーザの第２レベルを向上させる制御を制御部によって行うことと、を含み、第２ポイントは、配信実績と、第１ポイントと第１レベルの少なくとも一方と、に基づく。
本発明の第３の態様によると、ライブ動画が配信される端末と通信する情報処理装置の情報処理方法は、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を情報処理装置の制御部によって行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を制御部によって行うことと、ユーザがライブ動画の配信者となる場合に、第１ポイントと第１レベルの少なくとも一方に基づいて、ユーザの第２レベルを決定する制御を制御部によって行うことと、を含む。
本発明の第４の態様によると、ライブ動画が配信される端末と通信する情報処理装置の情報処理方法は、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を情報処理装置の制御部によって行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を制御部によって行うことと、ユーザがライブ動画を配信した場合に、少なくとも配信実績に基づいて、第１ポイントとは異なる第２ポイントをユーザに付与する制御を制御部によって行うことと、第２ポイントの増加に基づいて、ユーザの第２レベルを向上させる制御を制御部によって行うことと、を含み、第２ポイントは、配信実績と、第１ポイントと第１レベルの少なくとも一方と、に基づく。
本発明の第５の態様によると、ライブ動画が配信される端末と通信する情報処理装置は、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御と、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御と、ユーザがライブ動画の配信者となる場合に、第１ポイントと第１レベルの少なくとも一方に基づいて、ユーザの第２レベルを決定する制御と、を行う制御部を備える。
本発明の第６の態様によると、ライブ動画が配信される端末と通信する情報処理装置は、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御と、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御と、ユーザがライブ動画を配信した場合に、少なくとも配信実績に基づいて、第１ポイントとは異なる第２ポイントをユーザに付与する制御と、第２ポイントの増加に基づいて、ユーザの第２レベルを向上させる制御と、を行う制御部を備え、第２ポイントは、配信実績と、第１ポイントと第１レベルの少なくとも一方と、に基づく。
本発明の第７の態様によると、ライブ動画が配信される端末と通信する情報処理装置は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を行うことと、ユーザがライブ動画の配信者となる場合に、第１ポイントと第１レベルの少なくとも一方に基づいて、ユーザの第２レベルを決定する制御を行うことと、を実行する。
本発明の第８の態様によると、ライブ動画が配信される端末と通信する情報処理装置は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与する制御を行うことと、第１ポイントの増加に基づいて、ユーザの第１レベルを向上させる制御を行うことと、ユーザがライブ動画を配信した場合に、少なくとも配信実績に基づいて、第１ポイントとは異なる第２ポイントをユーザに付与する制御を行うことと、第２ポイントの増加に基づいて、ユーザの第２レベルを向上させる制御を行うことと、を実行し、第２ポイントは、配信実績と、第１ポイントと第１レベルの少なくとも一方と、に基づく。
実施形態に係る通信システムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。 第１実施例に係るアカウント登録データのデータ構成の一例を示す図。 第１実施例に係るアカウント管理データベースのデータ構成の一例を示す図。 第１実施例に係る端末の制御部によって実現される機能の一例を示す図。 第１実施例に係る端末の記憶部に記憶される情報の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１実施例に係るライブ視聴処理の流れの一例を示すフローチャート。 第１実施例に係るユーザレベルと、ユーザレベルアップ判定の方法とを説明するためのテーブルの一例を示す図。 第１実施例に係るライブ配信処理の流れの一例を示すフローチャート。 第１実施例に係るライバーレベルと、ライバーレベルアップ判定の方法とを説明するためのテーブルの一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係るシーズンレベル報酬および次シーズンのライバーレベルの決定方法を説明するためのテーブルの一例を示す図。 第２実施例に係るシーズン結果のうちのシーズンランキング報酬の決定方法を説明するためのテーブルの一例を示す図。 第２変形例に係るシーズンレベル報酬および次シーズンのライバーレベルの決定方法を説明するためのテーブルの一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係るライバーボーナスの算出方法を説明するためのテーブルの一例を示す図。 他の実施例に係るユーザに関するアイコンの表示態様を説明するためのテーブルの一例を示す図。
＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
＜実施形態＞
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。
システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末
（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。
サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。
具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。
また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。
また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。
（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。
サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース（登録商標）等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。
なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。
以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、クライアントサーバシステム）を例示する。
なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。
また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。
また、本明細書において「関する」、「関連する」と記載された用語について、「Ａに関するＢ」や「Ａに関連するＢ」という場合、限定ではなく例として、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。
また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。
ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例として、メッセージングサービス（Messaging Service）を例示することができる。
また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにしてもよいし、しなくてもよい。
なお、メッセージングサービス：ＭＳ（インスタントメッセージサービス：ＩＭＳを含む。）は、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。
また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置（限定ではなく例として、端末）間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにしてもよいし、しなくてもよい。
チャットルーム（限定ではなく例として、トークルーム）とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）とすることができる。
また、トークルームには、一対一のユーザのトークルーム（以下、「一対一トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、公式アカウントのユーザとのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。
なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、２名のユーザや２つのアカウントで構成されるグループのトークルームとして管理してもよい。
公式アカウントは、一般のユーザではなく事業者のアカウント（事業者のユーザのアカウント）であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ（メッセージ）の送受信を行うことができるようにすることができる。
本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、１または複数のコンテンツであってもよい。
コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報（限定ではなく例として、ＵＲＩ（Uniform Resource Identifier）等を含む。）などのリンクコンテンツを含めてもよいものとする。
テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。
画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。
また、以下の実施例では、ユーザが動画像・音声等のライブコンテンツをライブ配信したり、ライブ配信されたライブコンテンツを視聴するためのサービスの一例として、ライブ配信サービスを例示する。また、ライブ配信サービスを実現するためのアプリケーションを「ライブ配信アプリケーション」と称する。また、ライブ配信アプリケーションの名称を「Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ Ａｐｐ」と称して図示する。
ライブ配信サービスを実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ）ライブ配信アプリケーションを単体として構成する形態
（Ｂ）メッセージングアプリケーションの一機能としてライブ配信サービスの機能を持たせる形態
（Ｃ）ライブ配信サービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｄ）ライブ配信アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｂ）や（Ｃ）の形態では、限定ではなく例として、ライブ配信サービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。
（Ｄ）の形態では、限定ではなく例として、ライブ配信サービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、（Ｄ）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。
なお、上記とは異なり、ライブ配信アプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。
また、本実施形態では、ユーザ間で情報が送受信されるという表現や、端末間で情報が送受信されるという表現を用いる場合があり得るが、これらは実質的に同義としてよいものとする。
また、クライアントサーバシステムを適用する場合、サーバを介して端末間で情報が送受信されるように構成することが可能であるが、これをユーザ間や端末間での情報の送受信と表現してもよいものとする。また、前述したように、クライアントサーバシステムを適用せずに端末間で情報を送受信してもよいものとする。
また、以下の実施例では、ライブ配信として、配信者（ライバー）のユーザがライブ動画を配信し、視聴者のユーザがそのライブ動画を視聴する場合を例示する。そして、ライブコンテンツのライブ配信を単に「ライブ配信」と称する場合がある。また、ライブコンテンツをライブ配信するユーザのことを「ライバー」と称し、ライブ配信されたライブコンテンツを視聴するユーザのことを「視聴者」と称する場合がある。
また、以下の実施例では、ライブコンテンツをただ単に「ライブ」と称する場合がある。
また、ライブ配信サービスを実現するための形態として、前述した（Ａ）～（Ｄ）のいずれの形態を適用してもよいが、以下の実施例では、限定ではなく例として、主として（Ａ）ライブ配信アプリケーションを単体として構成する形態を適用する場合を例示する。
＜第１実施例＞
第１実施例は、ライバーや視聴者に経験値を付与したり、ライバーや視聴者をレベルアップさせることに関する実施例である。本実施例では、限定ではなく例として、経験値の付与やレベルアップがライブ配信中に、いわばリアルタイムに行われるようにする。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜システム構成＞
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。
サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、ライブ配信サービス、メッセージングサービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、ライブ配信サーバ、メッセージングサーバ等のように表現することもできる。
本実施形態では、ライブ配信サービス事業者（運営者）やメッセージングサービス事業者（運営者）を、サーバ１０のユーザとする。
なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。
端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。
表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。
入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。
制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。
出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。
表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。
記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
＜機能構成＞
（１）サーバの機能構成
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。
図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、制御部１１によってアプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。
アカウント登録データ１５３は、アプリケーション（限定ではなく例として、ライブ配信アプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。
ユーザ名は、このアプリケーションを利用する端末２０のアカウントの名称であり、限定ではなく例として、端末２０のユーザがアプリケーションを利用する際に登録する名称が記憶される。
アプリケーションＩＤは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。
端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤや公式ユーザ用のアプリケーションＩＤとすることができる。
なお、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。
また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、１つのアプリケーションＩＤを識別（ログイン）対象として、複数の端末２０においてアプリケーションを並行して（並列に）起動できるようにしてもよいし、そのようにしなくてもよい。
また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。なお、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報に代えず、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
アカウント登録可能なユーザは、限定ではなく例として、一般のユーザ（一般ユーザ）とすることができ、芸能人など、いわゆる公式アカウント（オフィシャルアカウント）によってプロのライバーとして活動することが想定されるユーザ（公式ユーザ）は除外することができる。
なお、公式ユーザもアカウント登録可能としてもよいが、限定ではなく例として、以下の実施例で説明するルールは、公式ユーザには適用しないようにしてもよい。
アカウント管理データベース１５５は、アカウント登録データ１５３に記憶されているアカウントに関する情報を管理するためのデータベースであり、そのデータ構成の一例を図１－５に示す。
アカウント管理データベース１５５には、アカウントごとのデータとして、アカウント管理データが記憶される。
各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、ユーザ経験値と、ユーザレベルと、ライバー経験値と、ライバーレベルとが記憶される。
アプリケーションＩＤには、アカウント登録データ１５３に記憶されて登録されているアプリケーションＩＤが記憶される。
ユーザ経験値は、このアプリケーションＩＤのユーザにサーバ１０によって付与されるユーザとしての経験値とすることができる。詳細は後述する。
ユーザレベルは、このアプリケーションＩＤのユーザのユーザ経験値に基づくレベルであり、限定ではなく例として、ユーザ経験値に基づいてサーバ１０によって記憶・更新されるようにすることができる。詳細は後述する。
ライバー経験値は、限定ではなく例として、このアプリケーションＩＤのユーザにサーバ１０によって付与されるライバーとしての経験値とすることができる。詳細は後述する。
ライバーレベルは、このアプリケーションＩＤのユーザのライバー経験値に基づくレベルであり、限定ではなく例として、ライバーとしてのランクであるライバーランクと、そのライバーランク内でのレベル（ランク内レベル）とを包括したものとすることができる。ライバーレベルは、限定ではなく例として、ライバー経験値に基づいてサーバ１０によって記憶・更新されるようにすることができる。詳細は後述する。
ユーザ経験値とユーザレベルとは、ユーザに関する情報の一例とすることができる。
ライバー経験値とライバーレベルとは、ライバーに関する情報の一例とすることができる。
限定ではなく例として、ライブ配信アプリケーションにおいてライバーとして活動することを希望するユーザは、サーバ１０に対して登録を行うようにすることができる。未登録のユーザについては、アカウント管理データのうちのライバー経験値とライバーレベルとをＮ／Ａ（Not Applicapable）とすることができる。
上記のように、本実施例では、１つのアカウント（共通のアカウント）に対して、ユーザに関する情報と、ライバーに関する情報とが関連付けて記憶される。
また、視聴者としての活動もライバーとしての活動も、共通のアカウントを用いて行われる。
（２）端末の機能構成
図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。
図１－７は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
記憶部２８には、限定ではなく例として、制御部２１によってアプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、またはこの端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
＜表示画面＞
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
以下では、タップ操作（単に「タップ」と言う場合がある。）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作とすることができる。
また、スクロール操作とは、限定ではなく例として、表示されている情報をスクロールさせるための操作（動作）とすることができる。限定ではなく例として、スクロール操作は、入力が指やタッチペン等である場合は「スワイプ操作」とし、入力がマウス等である場合は「ホイール操作」としてもよいものとする。
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
図１－８は、本実施例において端末２０の表示部２４に表示されるライブ配信アプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面を例示する。
図１－８左側は、ライブ配信アプリケーションのマイページ画面であり、画面最上部には、ライブ配信アプリケーションの名称が表示されている。その下には、ライブ配信アプリケーション内で現在表示されているページ等を示す領域（以下、「アプリ内位置表示領域」と称する。）が構成され、この画面はマイページ画面であるため、「マイページ」と表示されている。
その下には、ライブ配信アプリケーションにおける各種の情報が表示される領域が構成されている。
この領域の最上部には、ユーザＡ．Ａのプロフィールに関するプロフィール領域が設けられており、限定ではなく例として、アカウント登録時、またはその後のどこかのタイミングで、ユーザＡ．Ａによって設定された自身のベースとなる画像（以下、「ベース画像」と称する。）が、ユーザＡ．ＡのプロフィールアイコンＰＩ１としてプロフィール領域に表示されている。また、プロフィール領域には、同様にユーザＡ．Ａによって設定された背景画像としてのマイページ背景ＢＧ１が設定されている。
ベース画像は、プロフィールアイコンの他にも、自身を示す画像として種々の場面で用いられるようにすることができる。限定ではなく例として、コメント発信時に自分のコメントであることを認識させるためにコメントと関連付けて表示させたり、ユーザレベルアップ時やライバーレベルアップ時の表示等に用いられるようにすることができる。
なお、ベース画像やマイページ背景は、後からユーザが変更可能としてもよい。
また、マイページ背景は、限定ではなく例として、ライバー登録しなければ設定できないようにしてもよい。
限定ではなく例として、ユーザＡ．Ａのアイコン画像と、ユーザＡ．Ａがフォローしているユーザ（以下、適宜「フォロー」と称する。）の総数と、ユーザＡ．Ａをフォローしているユーザ（以下、適宜「フォロワー」と称する。）の総数とが表示されている。
また、この領域の右上部には、ランキング情報を表示するためのアイコン画像であるランキングアイコンＩＣ１が表示されている。ランキングについては、後の実施例で説明する。
また、その下には、ユーザＡ．Ａのユーザレベル情報を表示するユーザレベル情報表示領域ＵＬＲと、ユーザＡ．Ａのライバーレベル情報を表示するライバーレベル情報表示領域ＬＬＲとが、それぞれ枠によって構成されている。
以下では、ライバーレベルには、限定ではなく例として、ライバーランクと、そのライバーランク内でのレベルを示すランク内レベルとが含まれるものとする。
この例では、ユーザレベル情報表示領域ＵＬＲには、ユーザレベルが５０台であることを示すバッジ（星５つ）のアイコン画像とともに、ユーザＡ．Ａのユーザレベルとして「ユーザ Ｌｖ５９」が表示されている。
また、この例では、ライバーレベル情報表示領域ＬＬＲには、ライバーランク「レジェンド」に対応するキャラクタ（ウサギのキャラクタ）のアイコン画像とともに、ユーザＡ．Ａのライバーレベルとして「レジェンド Ｌｖ１０」が表示されている。
また、これらの領域の下には、ライブ配信を視聴するための情報が表示されている。
具体的には、ビデオカメラの画像および「配信をみる」の文字とともに、限定ではなく例として、配信中のライブに関する配信ライブ情報として、現在ライブ配信を行っているユーザのアイコン画像と、配信されているライブの名称とが、左右方向に一覧表示されている。限定ではなく例として、ユーザは、左右方向のスクロール操作を行うことで、画面内に表示されていない配信ライブ情報を表示させることが可能に構成されている。
また、その下には、自分でライブ配信を行うための「配信する」ボタン、自分のライブ配信の履歴を確認するための「配信履歴」ボタン、自分のライブ配信の予定を確認するための「配信予定」ボタン、自分が視聴したライブの履歴を確認するための「視聴履歴」ボタン、といった複数の機能に対応して、各々の情報を表示するためのボタンが設けられている。
図１－８左側の画面において、限定ではなく例として、ライバーレベル情報表示領域ＬＬＲがタップされると、限定ではなく例として、図１－８中央の画面が表示される。
この画面は、ユーザＡ．Ａのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示されている。
また、その下には、ライブステータスに関する情報が表示される領域が構成されている。
具体的には、ユーザレベル／ライバーランク（ライバーレベル）の表示を切り替えるための表示切替タブが最上部に表示され、この例では、ライバーランクが選択された状態が示されている。ライバーランクが選択されたことで、表示切替タブの「ライバーランク」の文字が強調表示（この例では、太字の文字で表示、下線付き）されている。
ライバーランクが選択されたことに基づき、その下には、ユーザＡ．Ａのライバーレベルの詳細情報を表示するためのライバーレベル詳細情報表示領域ＬＬＤＲが構成されている。ライバーレベル詳細情報表示領域ＬＬＤＲには、限定ではなく例として、ライバーランク（またはライバーランク＆ランク内レベル）に応じて変化するキャラクタのアイコン画像と、ライバーレベル（ライバーランク＆ランク内レベル）と、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値（ライバーＥＸＰ）とが表示されている。
この例では、ユーザＡ．Ａのライバーレベルとして、ライバーランク「レジェンド」、ランク内レベル「Ｌｖ１０」が表示され、このライバーレベルに対応するキャラクタのアイコン画像としてウサギのキャラクタのアイコン画像が表示されている。
また、ライバーランクおよびランク内レベルの表示の下には、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値が、ゲージ（ライバー経験値ゲージＬＧ１）および文字によって表示されている。この例では、次のランク内レベルにレベルアップするまでにライバー経験値が「２，９８７ライバーＥＸＰ」必要であることが表示されている。
なお、この例では、限定ではなく例として、ライバー経験値が「１４，０００」増加するごとに、ライバーランク「レジェンド」のランク内レベルがアップする。
ライバーレベル詳細情報表示領域ＬＬＤＲの下には、ライバーランクが左右方向にカルーセル形式で表示されており、この例では、ライバーレベル詳細情報表示領域ＬＬＤＲの中央真下の位置に現在のライバーランクが吹き出しで表示され、このライバーランクより１つ下のランクのライバーランクと、このライバーランクより１つ上のランクのライバーランクとが、それぞれ現在のライバーランクの吹き出しの左右に位置するように表示されている。
この例では、ユーザＡ．Ａのライバーランクが「レジェンド」であるため、ライバーレベル詳細情報表示領域ＬＬＤＲの下には、ウサギのキャラクタのアイコン画像および「レジェンドライバー」の文字を含む吹き出しが表示されている。また、その左には１つ下のライバーランクとして「スーパースター」が、その右には１つ上のライバーランクとして「神ライバー」がそれぞれ表示されている。
なお、１つ上のライバーランク「神ライバー」のアイコンには、まだこのライバーランクがアンロックされていないことを示す鍵アイコンが付与され、アイコンが反転表示されている。
その下には、ライバー経験値の取得方法等を示すライバー経験値取得情報表示領域ＬＥＲが構成されている。この例では、ライバー経験値の取得方法として、限定ではなく例として、ライブ配信の時間（時間の長さ）に関する「配信時間」、ライブ配信の視聴数に関する「視聴数」、ライブ配信中に視聴者から取得した応援ポイントに関する「応援ポイント」、ライブ配信中にライバーが視聴者に対してつんつん機能を利用してつんつんを行った回数に関する「つんつんの回数」が表示されている。
「つんつん機能」とは、限定ではなく例として、ライバーが自分のファンを増やすなどの目的で、ライブ配信中に視聴者を「つんつん」と突っつく演出を行うことで、視聴者とコミュニケーションをとる機能とすることができる。
具体的には、この例では、配信時間については「１分」あたり「１ライバー経験値（ライバーＥＸＰ）」を取得することが可能であり、視聴数については「視聴時間×視聴数×０．０１」のライバー経験値を取得することが可能であり、応援ポイントについては「１ＰＴ」あたり「１ライバー経験値」を取得することが可能であり、つんつんの回数については「１回」あたり「１ライバー経験値」を取得することが可能であることが示されている。
また、その下には、ユーザＡ．Ａの現在のライバーランクに応じて付与された特典に関する情報が表示されている。この例では、ライバーランク「レジェンド」に関連する特典として、限定ではなく例として、ランクバッジＲＢ、フレームＦＭ、マイページ背景ＢＧの３つが付与されていることが示されている。これらは、ライバーレベルに基づき付与される特典としての「オブジェクト（アイテム）」と称することもできる。。
ランクバッジＲＢは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域のプロフィールアイコンと関連付けて表示させるなどして、自身のランクをアピールするために用いられるようにすることができる。
フレームＦＭは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域のプロフィールアイコンを囲うフレームとして設定することで、プロフィールアイコンを目立たせるために用いられるようにすることができる。
マイページ背景ＢＧは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域の背景画像として設定することで、プロフィール領域を目立たせるために用いられるようにすることができる。
図１－８左側の画面においてユーザレベル情報表示領域ＵＬＲがタップされる、または、図１－８中央の画面において表示切替タブの「ユーザレベル」がタップされると、限定ではなく例として、図１－８右側の画面が表示される。
この画面は、図１－８中央の画面と同様に、ユーザＡ．Ａのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示され、ユーザレベルが選択されたことで、表示切替タブの「ユーザレベル」が強調表示（この例では、太字の文字で表示、下線付き）されている。
ユーザレベルが選択されたことに基づき、その下には、ユーザＡ．Ａのユーザレベルの詳細情報を表示するためのユーザレベル詳細情報表示領域ＵＬＤＲが構成されている。ユーザレベル詳細情報表示領域ＵＬＤＲには、限定ではなく例として、後述する図１－１４のテーブル等に示されるユーザレベル（達成ユーザ経験値）に応じたユーザ称号としてのバッジ（前述した「ランクバッジ」とは異なる。）のアイコン画像と、ユーザレベルと、次のユーザレベルにレベルアップするまでに必要とされるユーザ経験値（ユーザＥＸＰ）とが表示されている。ユーザ称号としてのバッジも、前述したランクバッジと同様に、特典としてのオブジェクトと捉えることもできる。
この例では、ユーザＡ．Ａのユーザレベルとして「Ｌｖ５９」が表示され、このユーザレベルに対応するバッジのアイコン画像として星の数が「５」（星５つ）のバッジのアイコン画像が表示されている。限定ではなく例として、ユーザレベルの十の桁の数字に対応する数の星を有するバッジのアイコン画像が構成されるようにすることができる。
なお、「１００以上」のレベルを許容する場合は、限定ではなく例として、星の数を上二桁と同数とするなどすることができる。
また、ユーザレベルの下には、次のユーザレベルにレベルアップするまでに必要とされるユーザ経験値が、ゲージ（ユーザ経験値ゲージＵＧ１）および文字によって表示されている。この例では、次のユーザレベルにレベルアップするまでにユーザ経験値が「６７ユーザＥＸＰ」必要であることが表示されている。
ユーザレベル詳細情報表示領域ＵＬＤＲの下には、ユーザレベルが左右方向にカルーセル形式で表示されており、この例では、ユーザレベル詳細情報表示領域ＵＬＤＲの中央真下の位置に現在のユーザレベルが属するレベル帯（この例では「Ｌｖ５０～」）が吹き出しで表示されている。また、この例では、このレベル帯よりも２０レベル下のレベル帯（この例では「Ｌｖ３０～」）と、このレベル帯よりも２０レベル上のレベル帯（この例では「Ｌｖ７０～」）とが、それぞれ現在のユーザレベルが属するレベル帯の吹き出しの左右に位置するように表示されている。
なお、１つ上のレベル帯のアイコンは、限定ではなく例として、ライバーランクの表示態様と同様にアンロックされていない態様で表示されている。
その下には、ユーザ経験値の取得方法を示すユーザ経験値取得情報表示領域ＵＥＲが構成されている。この例では、ユーザ経験値の取得方法として、限定ではなく例として、ライブの視聴時間に関する「視聴時間」、ライブ中に自分が発信したコメントに関する「コメント数」、ライブで自分がライバーに送信した応援ポイントに関する「応援ポイント」、ライブで自分がライバーに送信したハートに関する「ハート」、ライブ配信アプリケーションへの自分のサインイン（またはログイン）に関する「サインイン」、自分が登録しているチャンネルに関する「チャンネル登録」が表示されている。
具体的には、この例では、視聴時間については「１０分」あたり「１ユーザ経験値（ユーザＥＸＰ）」を取得することが可能であり、コメント数については「１回」あたり「１ユーザ経験値」を取得することが可能であり（ただし、１日１００回までの制限付き）、応援ポイントについては「１応援ポイント」あたり「２ユーザ経験値」を取得することが可能であることが示されている。また、ハートについては「１０個」あたり「１ユーザ経験値」を取得することが可能であり、サインインについては「１回」あたり「５０ユーザ経験値」を取得することが可能であり（ただし、１日１回までの制限付き）、チャンネル登録については「１登録」あたり「１ユーザ経験値」を取得することが可能であることが示されている。
なお、ここでは、主として視聴者としての行動（視聴者行動）に基づいてユーザ経験値が付与される条件を図示しているが、詳細後述するように、配信者としての行動（配信者行動）に基づいてもユーザ経験値が付与されるようにすることができる。このため、これらの条件についてもユーザ経験値取得情報表示領域ＵＥＲに表示してもよい。
図１－９は、図１－８の画面に示した端末２０ＡのユーザＡ．Ａが視聴者となってライブを視聴する場合の表示画面の一例を示す図である。
図１－９左側の画面は、図１－８左側のマイページ画面に対応しており、配信ライブ情報のうちユーザＢ．Ｂによって配信されている「ＢＢ’ｓ ｋｉｔｃｈｅｎ」が視聴するライブとして選択された状態が示されている。この場合、限定ではなく例として、図１－９中央の配信ライブ画面が表示される。
この配信ライブ画面には、画面最上部のライブ配信アプリケーションの名称が表示される領域の下の領域に、ユーザＢ．Ｂによって配信されているライブの映像が表示されている。具体的には、ライバーであるユーザＢ．Ｂの映像が映し出されている。
ライブの映像が表示される領域の左上部には、ライバーであるユーザＢ．Ｂの名称や、このライブの配信開始からの経過時間、このライブを視聴している視聴者数等の情報が表示されている。また、その下には、ユーザＢ．Ｂの現在のライバーレベル（ライバーランク＆ランク内レベル）を示す領域が構成されており、この領域では、ライバー経験値がゲージ（ライバー経験値ゲージＬＧ２）によって表示されるように構成されている。この例では、ユーザＢ．Ｂは、ライバーランクが「スター」であり、ランク内レベルが「Ｌｖ８」であることが示されている。
また、ライブの映像が表示される領域の左下部には、視聴者のユーザやライバーのユーザから発信されたコメントが表示されるコメント表示領域ＣＤＲが構成されている。このコメント表示領域ＣＤＲには、限定ではなく例として、発信されたコメントが、そのユーザのアイコン画像およびユーザ名と関連付けて表示されるように構成されている。
なお、コメントは、前述したコンテンツとしてよい。また、コンテンツの一態様をコメントとしてもよい。
コメント表示領域ＣＤＲは、限定ではなく例として、設定行数（限定ではなく例として、４行～５行程度）のコメントが表示される領域として構成することができる。この場合、限定ではなく例として、コメントが発信される毎に下からコメントが表示されて日時が古いコメントが上に押し上げられ、最上位の行に表示されているコメントは、非表示とされるようにすることができる。
また、ライブの映像が表示される領域の最下部には、自分が発信するコメントを入力するためのコメント入力領域ＣＩＲが設けられている。限定ではなく例として、コメント入力領域ＣＩＲがタップされると不図示のキーボードが画面下部から表示され、このキーボードによってコメントを入力可能とすることができる。そして、入力されたコメントで確定し、不図示のコメント送信ボタンがタップされることで、入力されたコメントがサーバ１０を介して、ライバーの端末２０と、各々の視聴者の端末２０とに送信されるようにすることができる。
なお、コメント発信元の端末２０が、コメント送信ボタンがタップされたことに基づいて、自己の端末２０のユーザのコメントがコメント表示領域ＣＤＲの最新のコメントの下に位置するようにコメントを表示する制御を行ってもよい。
また、サーバ１０が、コメント発信元の端末２０に対しても、その端末２０で入力されたコメントを送信するようにする。そして、コメント発信元の端末２０が、サーバ１０からコメントを受信したことに基づいて、自己の端末２０のユーザのコメントがコメント表示領域ＣＤＲの最新のコメントの下に位置するようにコメントを表示する制御を行ってもよい。
図１－９中央の画面では、自己の端末２０ＡのユーザＡ．Ａが発信した「もうすぐスターＬｖ９だね」というコメントがコメント表示領域ＣＤＲに表示されている。限定ではなく例として、このコメントの発信に伴い、ユーザＡ．Ａがユーザ経験値を取得し、これに伴い、ユーザＡ．Ａのユーザレベルがアップしたとする。この場合、限定ではなく例として、図１－９右側の画面が表示される。
この画面において、コメント表示領域ＣＤＲには、ユーザＡ．Ａを発信元とするコメントとして、ユーザＡ．Ａのアイコン画像およびユーザ名と関連付けて「レベルが上がりました！ おめでとう！」のテキストと、レベルアップ後のユーザレベル「ユーザＬｖ６０」のアイコンとを含むコメントＣＭ１が表示されている。コメントＣＭ１は、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ユーザレベルがアップしたと判定したサーバ１０によって生成されて各々の端末２０に送信されるコメントとすることができる。つまり、このコメントは、いわばシステムメッセージとしてのコメントとすることができる。
また、コメントＣＭ１は、他のコメントとは異なる表示態様で表示されている。この例では、ユーザＡ．Ａのアイコン画像およびユーザ名を含むコメント全体が枠で囲われて表示されている。このような表示を行うことで、ユーザ入力に基づく通常のコメントとは異なるコメントであることを各々の端末２０のユーザに認識させることができる。
コメント表示領域ＣＤＲにおいて、コメントＣＭ１の下には、このコメントを見た視聴者のユーザＥ．Ｅによって発信された、ユーザＡ．Ａのレベルアップを祝福するコメント「Ａ．Ａさんおめでとう～」が表示されている。
また、コメント表示領域ＣＤＲの上方には、ユーザレベルがアップしたことを示すユーザレベルアップ情報ＵＵＩが表示されている。具体的には、この例では、「ユーザレベルアップ！」の文字と、ユーザレベルが「Ｌｖ５９」から「Ｌｖ６０」にアップしたことを示す情報とが表示されている。
なお、ユーザレベルアップ情報ＵＵＩは、ユーザレベルがアップしたユーザの端末２０（この場合、端末２０Ａ）のみに表示されるようにしてもよいし、その他の端末２０にも表示されるようにしてもよい。
図１－１０は、図１－８の画面に示した端末２０ＡのユーザＡ．Ａがライバーとなってライブを配信する場合の表示画面の一例を示す図である。
図１－１０左側の画面は、図１－８左側のマイページ画面に対応しており、画面下部の「配信する」ボタンがタップされた状態が示されている。この場合、限定ではなく例として、図１－１０中央の配信ライブ画面が表示される。
この配信ライブ画面には、画面最上部のライブ配信アプリケーションの名称が表示される領域の下の領域に、ユーザＡ．Ａが配信するライブの映像が表示されている。具体的には、ライバーであるユーザＡ．Ａの映像が映し出されている。ユーザＡ．Ａのライバーレベルとして、ライバーランク「レジェンド」、ランク内レベル「Ｌｖ１０」が表示されている。
また、ライブの映像が表示される領域の左上部には、ライバーであるユーザＡ．Ａの名称等の情報に加えて、ライブ配信中の端末であることを示す、カメラアイコン内に「Ｌｉｖｅ」の文字で示されるライブアイコン情報が表示されている。
他の構成は、図１－９中央、図１－１０右側に示した画面と同様である。
ユーザＡ．Ａによるライブ配信に伴い、ユーザＡ．Ａがライバー経験値を取得し、これに伴い、ユーザＡ．Ａのランク内レベルがアップし、ランク内レベルが最大レベルに達したことで、ライバーランクがランクアップしたとする。この場合、限定ではなく例として、図１－１０右側の画面が表示される。
この画面において、コメント表示領域ＣＤＲには、ユーザＡ．Ａを発信元とするコメントとして、ユーザＡ．Ａのアイコン画像およびユーザ名と関連付けて「ランクが上がりました！ おめでとう！」のテキストと、ランクアップ後のライバーランク「神」およびランク内レベル「Ｌｖ１」を示すアイコンとを含むコメントＣＭ２が表示されている。コメントＣＭ２は、前述したコメントＣＭ１と同様に、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ライバーランクやランク内レベルがアップしたと判定したサーバ１０によって生成されて各々の端末２０に送信されるコメントとすることができる。
また、コメントＣＭ２は、他のコメントとは異なる表示態様で表示されている。この例では、ユーザＡ．Ａのアイコン画像およびユーザ名を含むコメント全体が枠で囲われて表示されている。このような表示を行うことで、ユーザ入力に基づく通常のコメントとは異なるコメントであることを各々の端末２０のユーザに認識させることができる。
コメント表示領域ＣＤＲにおいて、コメントＣＭ２の下には、このコメントを見た視聴者のユーザＦ．Ｆや視聴者のユーザＥ．Ｅによって発信された、ユーザＡ．Ａのランクアップを祝福するコメント「神降臨！！！！！」や「Ａ．Ａさんすごい～～～」が表示されている。
また、その下には、ライバーであるユーザＡ．Ａによってコメント入力領域ＣＩＲに入力されて送信された、お礼を述べるコメント「みんな応援ありがと～」が表示されている。
また、コメント表示領域ＣＤＲの上には、ライバーレベルがアップしたことを示すライバーレベルアップ情報ＬＵＩが表示されている。具体的には、この例では、「ライバーランクアップ！」の文字と、ライバーランクが「レジェンド（Ｌｖ１０）」から「神（Ｌｖ１）」にアップしたことを示すキャラクタのアイコン画像および文字とを含む情報が表示されている。この情報は、ライバーランクがアップしたことを示す情報とも言えるため、ライバーランクアップ情報と称してもよい。
また、ライバーレベルアップ情報ＬＵＩは、限定ではなく例として、図１－９右側の画面に示したユーザレベルアップ情報ＵＵＩよりも派手な態様で表示されている。
なお、ライバーレベルアップ情報ＬＵＩは、ライバーランクがアップしたユーザの端末２０（この場合、端末２０Ａ）にのみ表示されるようにしてもよいし、その他の端末２０にも表示されるようにしてもよい。
図１－１１は、本実施例において端末２０Ａの表示部２４に表示されるライブ配信アプリケーションの画面の一例を示す図であり、図１－１０のライブ配信が終了した場合に表示される画面の一例を示す図である。
図１－１１左側，中央には、ライブ配信が終了したことに基づき、ライブ配信をねぎらうメッセージ等とともに、このライブ配信でユーザＡ．Ａが取得したライバー経験値に関する情報（この例では「配信お疲れさまでした！」のメッセージ）が表示されている。
また、その下には、ライバー経験値ゲージＬＧ１等を含む情報が表示されている。図１－１１左側→図１－１１中央の流れで、ライバー経験値ゲージＬＧ１が、取得したライバー経験値分だけ増加し、ユーザＡ．Ａのライバーレベルが「レジェンド（Ｌｖ１０）」から「神（Ｌｖ１）」にレベルアップしたことが示される。また、図１－１１中央の画面において、ライバー経験値ゲージＬＧ１等を含む情報の下には、ライバーレベルがアップしたことに基づきユーザＡ．Ａが取得した特典の内容、この例では、「獲得アイテム：ライバーランク「神」のうちのランク内レベル「Ｌｖ１」となったことによる特典（オブジェクト）としてのランクバッジＲＢ１」が表示されている。
また、その下には、今回のライブ配信の結果（配信結果）に関する情報として、限定ではなく例として、ライブの配信時間「配信時間」と、ライブの視聴数「視聴者」と、新規のフォロワー数「新規フォロワー」とが表示されている。
さらに、その下には、ライブの視聴者のユーザに対してお礼のメッセージを送信するための「お礼メッセージ」ボタンと、ライブをもう一度配信するための「もう一度配信」ボタンとが表示されている。
図１－１１右側は、ライブ配信アプリケーションのマイページ画面であり、図１－１１中央の画面が表示された後、マイページに戻った場合に表示される画面の一例を示す図である。
この画面の構成は、図１－８左側の画面と同様であるが、表示内容が一部異なっている。
具体的には、図１－１１中央の画面に示したように、ランクバッジＲＢ１を獲得したことに基づき、プロフィール領域のプロフィールアイコンと関連付けてランクバッジＲＢ１が表示されている。
また、図１－１１中央の画面に示したように、ライブ配信によって新規フォロワー数が「１０２」増加したため、図１－８左側の画面におけるフォロワー数「２，８３１」に「１０２」が加算され、「２，９３３」と表示されている。
また、ライブ配信によってユーザレベルが「Ｌｖ６０」にアップしたことに伴い、ユーザレベル情報表示領域ＵＬＲには、レベルが６０台であることを示すバッジ（星６つ）のアイコン画像とともに、ユーザＡ．Ａのユーザレベルとして「ユーザ Ｌｖ６０」が表示されている。
また、ライブ配信によってライバーレベルが「神Ｌｖ１」にアップしたことに伴い、ライバーレベル情報表示領域ＬＬＲには、ライバーランク「神」に対応するキャラクタ（くまのキャラクタ）のアイコン画像とともに、ユーザＡ．Ａのライバーレベルとして「神 Ｌｖ１」が表示されている。
＜処理＞
図１－１２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理では、配信されるライブを視聴する視聴者のユーザの一人であるユーザＡ．Ａの端末２０Ａの制御部２１が実行する処理を左側に、サーバ１０の制御部１１が実行する処理を右側にそれぞれ示している。
ここでは、ユーザＢ．Ｂがライバーとなってライブ配信を行う場合を例示する。
なお、ユーザＡ．Ａ以外で視聴者となるユーザの端末２０の制御部２１が実行する処理は、端末２０Ａと同様であるため、図示を省略する。
なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。
本明細書で説明する各種の処理について同様である。
最初に、端末２０Ａの制御部２１は、入出力部２３を介してユーザＡ．Ａによってライブを視聴する要求がなされたか否か等に基づいて、ライブを視聴するか否かを判定する（Ａ１１０）。ライブを視聴しないと判定したならば（Ａ１１０：ＮＯ）：端末２０Ａの制御部２１は、Ａ１４０に処理を進める。
一方、ライブを視聴すると判定したならば（Ａ１１０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、自己の端末２０のアプリケーションＩＤ２８３等を含むライブ視聴要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからライブ視聴要求情報を受信したか否かを判定し（Ｓ１１０）、受信しなかったと判定したならば（Ｓ１１０：ＮＯ）、Ｓ１３０に処理を進める。
一方、ライブ視聴要求情報を受信したと判定したならば（Ｓ１１０：ＹＥＳ）、サーバ１０の制御部１１は、端末２０Ａとの間で、ライブ視聴処理を実行する（Ａ１３０，Ｓ１２０）。
図１－１３は、ライブ視聴処理の流れの一例を示すフローチャートである。図の見方は、図１－１２と同様である。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によってライバーであるユーザＢ．Ｂの端末２０Ｂからライブ配信情報を受信したことに基づいて、そのライブ配信情報に基づくライブ情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２１０）。
通信Ｉ／Ｆ２２によってサーバ１０からライブ情報を受信すると、端末２０Ａの制御部２１は、受信したライブ情報を表示部２４に表示させる（Ａ１３１０）。
Ｓ１２１０の後、サーバ１０の制御部１１は、ユーザ経験値算出処理を行う（Ｓ１２２０）。具体的には、限定ではなく例として、図１－８右側の画面例に示したような以下の条件のうちの少なくともいずれか１つの条件（視聴者行動、視聴実績）と、各々に設定されたユーザ経験値の付与値（単位付与値）とに基づいて、ユーザＡ．Ａのユーザ経験値を算出するようにすることができる。
（Ａ１）ライブ視聴中：自分のライブ視聴時間
（Ａ２）ライブ視聴中：自分が発信したコメント数
（Ａ３）ライブ視聴中： 自分からライバーへの応援ポイント（応援アイテム）の送信
（Ａ４）ライブ視聴中：自分からライバーへのハートの送信
（Ａ５）ライブ視聴中：ライバーのフォロー（チャンネル登録）
（Ａ６）ライブ視聴中以外：ライブ配信アプリケーションのサインイン（またはログイン）
（Ａ７）ライブ視聴中以外：自分のチャンネル登録数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
限定ではなく例として、応援ポイントとハートの少なくともいずれか一方は「課金アイテム」とすることができる。そして、限定ではなく例として、ライブ配信サービス事業者がユーザに金銭の負担を負わせ、ライブ配信サービス事業者に対して金銭の支払いが行われることで、ユーザが応援ポイントやハートをライバーに送信可能とすることができる。
限定ではなく例として、応援ポイントの送信やハートの送信、チャンネル登録等は、限定ではなく例として、ライブ動画に関する評価と捉えることもできる。
そして、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのユーザ経験値を更新する。
次いで、サーバ１０の制御部１１は、ユーザＡ．Ａのユーザレベルをアップさせるか否かに関する判定（以下、「ユーザレベルアップ判定」と称する。）を行う（Ｓ１２３０）。
図１－１４は、ユーザレベルと、ユーザレベルアップ判定の方法とを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ユーザレベルと、達成ユーザ経験値と、ユーザ称号とが関連付けて記憶されている。
ユーザレベルは、レベルが低い順に「ＬＶ１」、「ＬＶ２」、「ＬＶ３」、・・・、といった複数のレベルに細分化されており、各々のユーザレベルと関連付けて、そのユーザレベルにレベルアップするために必要とされるユーザ経験値が「達成ユーザ経験値」として設定されている。
また、この例では、ユーザレベルのうちの一部のレベルについて、そのユーザレベルに対応する称号（以下、「ユーザ称号」と称する。）が設定されている。具体的には、限定ではなく例として、ユーザレベル「ＬＶ３」にはユーザ称号「ブロンズリスナーバッジ」が、ユーザレベル「ＬＶ７」にはユーザ称号「ブロンズリスナーフレーム」が、ユーザレベル「ＬＶ１０」にはユーザ称号「シルバーリスナーバッジ」がそれぞれ設定されている。
Ｓ１２３０において、サーバ１０の制御部１１は、ユーザＡ．Ａの最新のユーザ経験値と、図１－１４のテーブルの達成ユーザ経験値とに基づいて、ユーザＡ．Ａのユーザレベルを現在のユーザレベルからレベルアップさせるか否かを判定する（Ｓ１２３０）。つまり、本実施例では、ライブ配信中に、そのライブの視聴者にユーザ経験値が付与され、ユーザレベルが向上する場合がある。
レベルアップさせないと判定したならば（Ｓ１２３０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１２５０に処理を進める。
一方、レベルアップさせると判定したならば（Ｓ１２３０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ１０の制御部１１は、ユーザレベルがアップしたことに関する情報（限定ではなく例として、ユーザレベルがアップした旨、ユーザレベル、ユーザ称号等）をユーザレベルアップ情報として、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２４０）。
なお、サーバ１０の制御部１１は、ユーザレベルアップ情報を各々の視聴者の端末２０に対して送信するようにしてもよいし、そうしなくてもよい。
また、ユーザレベルアップ情報として、配信中のコメント内に表示させるためのユーザレベルアップコメント情報を各々の視聴者・配信者の端末２０に対して送信し、ユーザレベルアップ情報は端末２０Ａのみに送信するようにしてもよい。
Ａ１３１０の後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からユーザレベルアップ情報を受信したか否かを判定し（Ａ１３２０）、受信しなかったと判定したならば（Ａ１３２０：ＮＯ）、Ａ１３４０に処理を進める。
一方、ユーザレベルアップ情報を受信したと判定したならば（Ａ１３２０：ＹＥＳ）、端末２０Ａの制御部２１は、受信したユーザレベルアップ情報を表示部２４に表示させる（Ａ１３３０）。
Ｓ１２４０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂからライブ配信終了要求情報を受信したか否かを判定し（Ｓ１２５０）、受信しなかったと判定したならば（Ｓ１２５０：ＮＯ）、Ｓ１２１０に処理を戻す。
一方、受信したと判定したならば（Ｓ１２５０：ＹＥＳ）、サーバ１０の制御部１１は、ライブ配信終了情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２６０）。
そして、サーバ１０の制御部１１は、ライブ視聴処理を終了する。
Ａ１３３０の後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からライブ配信終了情報を受信したか否かを判定し（Ａ１３４０）、受信しなかったと判定したならば（Ｓ１３４０：ＮＯ）、Ａ１３１０に処理を戻す。
一方、受信したと判定したならば（Ａ１３４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信したライブ配信終了情報を表示部２４に表示させる（Ａ１３５０）。そして、端末２０Ａの制御部２１は、ライブ視聴処理を終了する。
なお、Ａ１３５０において、端末２０Ａの制御部２１が、限定ではなく例として、視聴したライブに関して自分が取得したユーザ経験値やユーザレベルに関する情報を表示してもよい。限定ではなく例として、図１－１１に示したライバーの端末２０の表示部２４に表示されるライブ配信終了情報に倣って、ユーザＡ．Ａがライブの視聴によって取得したユーザ経験値やユーザレベルの変化等を表示してもよい。
図１－１２に戻り、ライブ視聴処理（Ａ１３０）を行った後、端末２０Ａの制御部２１は、入出力部２３を介してユーザＡ．Ａによってライブ配信を行うための入力がなされたか否か等に基づいて、ライブ配信を行うか否かを判定する（Ａ１４０）。ライブ配信を行わないと判定したならば（Ａ１４０：ＮＯ）、端末２０Ａの制御部２１は、Ａ１７０に処理を進める。
一方、ライブ配信を行うと判定したならば（Ａ１４０：ＹＥＳ）、端末２０Ａの制御部２１は、ライブ配信要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５０）。
ライブ視聴処理（Ｓ１２０）を行った後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからライブ配信要求情報を受信したか否かを判定し（Ｓ１３０）、受信しなかったと判定したならば（Ｓ１３０：ＮＯ）、Ｓ１５０に処理を進める。
一方、ライブ配信要求情報を受信したと判定したならば（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、端末２０Ａとの間で、ライブ配信処理を行う（Ａ１６０，Ｓ１４０）。
図１－１５は、ライブ配信処理の流れの一例を示すフローチャートである。図の見方は、図１－１２と同様である。
端末２０Ａの制御部２１は、ライブ配信情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１６１０）。
通信Ｉ／Ｆ１４によって端末２０Ａからライブ配信情報を受信すると、サーバ１０の制御部１１は、受信したライブ配信情報に基づくライブ情報を、通信Ｉ／Ｆ１４によって端末２０Ａと、各々の視聴者の端末２０とに送信する（Ｓ１４１０）。
通信Ｉ／Ｆ２２によってサーバ１０からライブ情報を受信すると、端末２０Ａの制御部２１は、受信したライブ情報を表示部２４に表示させる（Ａ１６２０）。
なお、図示は省略しているが、各々の視聴者の端末２０は、受信したライブ情報を表示部２４に表示させる。
Ｓ１４２０の後、サーバ１０の制御部１１は、ユーザ経験値算出処理を行う（Ｓ１４２０）。
ここでは、ユーザＡ．Ａがライバーとなってライブ配信を行っているが、限定ではなく例として、ライバー経験値がユーザＡ．Ａに付与されるようにするばかりでなく、ユーザ経験値もユーザＡ．Ａに付与されるようにすることができる。
この場合、限定ではなく例として、少なくとも以下のいずれか１つの条件（配信実績、配信者行動）と、各々に設定されたユーザ経験値の付与値（単位付与値）とに基づいて、ユーザＡ．Ａのユーザ経験値を算出するようにすることができる。
（Ｂ１）ライブ配信中：自分が配信するライブ配信時間
（Ｂ２）ライブ配信中：自分が受け取った応援ポイント数
（Ｂ３）ライブ配信中：自分が受け取ったハート数
（Ｂ４）ライブ配信中：自分のライブの視聴数
（Ｂ５）ライブ配信中：自分に対するコメント数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
あくまでも１つの例であるが、上記の（Ｂ１）～（Ｂ５）等の条件に基づくユーザ経験値の付与値は、限定ではなく例として、前述した（Ａ１）～（Ａ７）等の条件に基づくユーザ経験値の付与値よりも相対的に小さくなるように設定しておくことができる。つまり、ユーザ経験値（ユーザレベル）は、ユーザが視聴者行動を行う方が配信者行動を行うよりも上がり易くなるようにすることができる（視聴者行動の方が配信者行動よりも強い）。
なお、限定ではなく例として、後述するライバー経験値算出処理で用いられる条件のうち、上記の条件に含まれない条件を適用してもよい。また、後述するライバー経験値算出処理で用いられる条件と全く同じ条件を適用してもよい。
また、限定ではなく例として、（Ｂ１）ライブ配信時間に基づいて付与するユーザ経験値と、前述した（Ａ１）ライブ視聴時間に基づいて付与するユーザ経験値との関係について、限定ではなく例として、同じ時間（時間の長さ）に対して同じ値のユーザ経験値を付与するようにしてもよい。また、同じ時間に対してライブ配信時間の方がライブ視聴時間よりも大きいユーザ経験値を付与するようにしてもよい。つまり、限定ではなく例として、端末のユーザがライブ動画の配信を所定時間行った場合に、ライブ動画の視聴を所定時間行う場合と少なくとも同じ第１ポイントがユーザに付与されるようにしてもよい。
なお、これとは異なり、同じ時間に対してライブ視聴時間の方がライブ配信時間よりも大きいユーザ経験値を付与するようにしてもよい。
そして、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのユーザ経験値を更新する。
次いで、サーバ１０の制御部１１は、ユーザＡ．Ａのユーザレベルアップ判定を行う（Ｓ１４３０）。具体的には、ユーザＡ．Ａの最新のユーザ経験値と、図１－１４のテーブルの達成ユーザ経験値とに基づいて、ユーザＡ．Ａのユーザレベルを現在のユーザレベルからレベルアップさせるか否かを判定する。つまり、本実施例では、ライブ配信中に、そのライブの配信者にユーザ経験値が付与され、ユーザレベルが向上する場合がある。
レベルアップさせないと判定したならば（Ｓ１４３０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１４５０に処理を進める。
一方、レベルアップさせると判定したならば（Ｓ１４３０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ１０の制御部１１は、ユーザレベルがアップしたことに関する情報をユーザレベルアップ情報として、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１４４０）。
Ａ１６２０の後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からユーザレベルアップ情報を受信したか否かを判定し（Ａ１６３０）、受信したと判定したならば（Ａ１６３０：ＹＥＳ）、受信したユーザレベルアップ情報を表示部２４に表示させる（Ａ１６４０）。
Ｓ１４４０の後、サーバ１０の制御部１１は、ライバー経験値算出処理を行う（Ｓ１４５０）。具体的には、限定ではなく例として、図１－８中央の画面例に示したような以下の条件のうちの少なくともいずれか１つの条件（配信実績、配信者行動）と、各々に設定されたライバー経験値の付与値（単位付与値）とに基づいて、ユーザＡ．Ａのライバー経験値を算出する。
（Ｃ１）ライブ配信中：自分のライブ配信時間
（Ｃ２）ライブ配信中：自分のライブの視聴数
（Ｃ３）ライブ配信中：自分が受け取った応援ポイント数
（Ｃ４）ライブ配信中：自分が行ったつんつんの回数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。限定ではなく例として、以下の条件等を含めてもよい。
（Ｃ５）ライブ配信中：自分へのコメント数
（Ｃ６）ライブ配信中：自分が受け取ったハート数
そして、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのライバー経験値を更新する。
次いで、サーバ１０の制御部１１は、ユーザＡ．Ａのライバーランクやランク内レベル（以下、包括的に「ライバーレベル」と称する。）をアップさせるか否かに関する判定（以下、「ライバーレベルアップ判定」と称する。）を行う（Ｓ１４６０）。
図１－１６は、ライバーレベルと、ライバーレベルアップ判定の方法とを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ライバーランクと、達成ライバー経験値と、ランク内レベルとが関連付けて記憶されている。
ライバーランクは、ランクが低い順に、限定ではなく例として、「ルーキー」、「レギュラー」、「スター」、「スーパースター」、「レジェンド」、「神」といった複数のランクに細分化されており、各々のライバーランクと関連付けて、そのライバーランクに対応するライバー経験値の数値範囲が「達成ライバー経験値」として設定されている。最上位のライバーランクは「神」である。
達成ライバー経験値の数値範囲の下限の値が、そのライバーランクとなるために必要とされるライバー経験値を示し、達成ライバー経験値の数値範囲の上限の値が、そのライバーランク内での最大のライバー経験値を示している。
また、この例では、各々のライバーランクには、そのライバーランク内のレベルが設定されている。具体的には、限定ではなく例として、ライバーランクのうちの「ルーキー」、「レギュラー」、「スター」、「スーパースター」、「レジェンド」については、ランク内レベルの下限として「１」が、ランク内レベルの上限として「１０」がそれぞれ設定され、ランク内レベルが「１～１０」の数値範囲のいずれかとなるように設定されている。
のいずれかの値が設定されるように構成されている。
最上位のライバーランク「神」よりも下位のライバーランクについては、限定ではなく例として、対応する達成ライバー経験値の欄の数値範囲が示す幅の値を「１０」で除算した値のライバー経験値ごとに、ランク内レベルがアップするようにすることができる。
また、最上位のライバーランク「神」については、限定ではなく例として、設定値（限定ではなく例として、「２０，０００」ライバー経験値）ごとに、ランク内レベルが「１」アップするようにすることができる。
なお、ライバーランクやランク内レベルと関連付けて、前述したライバーに付与する特典をこのテーブルに設定しておき、サーバ１０の制御部１１が、これに基づいて、ライバーに特典を付与するようにしてもよい。
Ｓ１４６０において、サーバ１０の制御部１１は、ユーザＡ．Ａの最新のライバー経験値と、図１－１６のテーブルの達成ライバー経験値とに基づいて、ユーザＡ．Ａのライバーランクやランク内レベルを現在のライバーランクやランク内レベルからレベルアップさせるか否かを判定する（Ｓ１４６０）。つまり、本実施例では、ライブ配信中に、そのライブの配信者にライバー経験値が付与され、ライバーレベルが向上する場合がある。
レベルアップさせないと判定したならば（Ｓ１４６０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１４８０に処理を進める。
一方、レベルアップさせると判定したならば（Ｓ１４６０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント管理データベース１５５のうち、ユーザＡ．ＡのアプリケーションＩＤに対応するアカウント管理データのライバーランク等を更新する。そして、サーバ１０の制御部１１は、ライバーレベルがアップしたことに関する情報（限定ではなく例として、ライバーランクがアップした旨、ランク内レベルがアップした旨、ライバーランク、ランク内レベル等）をライバーレベルアップ情報として、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１４７０）。
なお、サーバ１０の制御部１１は、ライバーレベルアップ情報を各々の視聴者の端末２０に対しても送信するようにしてもよいし、そうしなくてもよい。
また、ライバーレベルアップ情報として、配信中のコメント内に表示させるためのライバーレベルアップコメント情報を各々の視聴者・配信者の端末２０に対して送信し、ライバーレベルアップ情報は端末２０Ａのみに送信するようにしてもよい。
Ａ１６４０の後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からライバーレベルアップ情報を受信したか否かを判定し（Ａ１６５０）、受信しなかったと判定したならば（Ａ１６５０：ＮＯ）、Ａ１６７０に処理を進める。
一方、ライバーレベルアップ情報を受信したと判定したならば（Ａ１６５０：ＹＥＳ）、端末２０Ａの制御部２１は、受信したライバーレベルアップ情報を表示部２４に表示させる（Ａ１６６０）。
Ａ１６６０の後、端末２０Ａの制御部２１は、入出力部２３を介したユーザ入力に基づいて、ライブ配信を終了するか否かを判定し（Ａ１６７０）、終了しないと判定したならば（Ａ１６７０：ＮＯ）、Ａ１６１０に処理を戻す。
一方、ライブ配信を終了すると判定したならば（Ａ１６７０：ＹＥＳ）、端末２０Ａの制御部２１は、ライブ配信終了要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１６８０）。
Ｓ１４７０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからライブ配信終了要求情報を受信したか否かを判定し（Ｓ１４８０）、受信しなかったと判定したならば（Ｓ１４８０：ＮＯ）、Ｓ１４１０に処理を戻す。
一方、受信したと判定したならば（Ｓ１４８０；ＹＥＳ）、サーバ１０の制御部１１は、ライブ配信終了情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１４９０）。
そして、サーバ１０の制御部１１は、ライブ配信処理を終了する。
Ａ１６８０の後、通信Ｉ／Ｆ２２によってサーバ１０からライブ配信終了情報を受信すると、端末２０Ａの制御部２１は、受信したライブ終了情報を表示部２４に表示させる（Ａ１６９０）。具体的には、限定ではなく例として、図１－１１に示したような画面を表示部２４に表示させる。
そして、端末２０Ａの制御部２１は、ライブ配信処理を終了する。
図１－１２に戻り、ライブ配信処理（Ａ１６０）を行った後、端末２０Ａの制御部２１は、処理を終了するか否かを判定し（Ａ１７０）、終了しないと判定したならば（Ａ１７０：ＮＯ）、Ａ１１０に処理を戻す。
一方、処理を終了すると判定したならば（Ａ１７０：ＹＥＳ）、端末２０Ａの制御部２１は、処理を終了する。
同様に、ライブ配信処理（Ｓ１４０）を行った後、サーバ１０の制御部１１は、処理を終了するか否かを判定し（Ｓ１５０）、終了しないと判定したならば（Ｓ１５０：ＮＯ）、Ｓ１１０に処理を戻す。
一方、処理を終了すると判定したならば（Ｓ１５０：ＹＥＳ）、サーバ１０の制御部１１は、処理を終了する。
本処理で示したように、ユーザがライブ配信を行っている間は、ライバー経験値ばかりでなく、ユーザ経験値も算出される。そして、ライバーレベルがレベルアップするのみならず、ユーザレベルがレベルアップする場合もある。
＜第１実施例の効果＞
本実施例は、ライブ動画を配信する配信者の端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、端末２０において視聴者行動が行われた場合に、端末２０のユーザにユーザ経験値（限定ではなく、第１ポイントの一例）を付与する制御を制御部１１によって行う。そして、サーバ１０は、ユーザ経験値の増加に基づいて、端末２０のユーザのユーザレベル（限定ではなく、第１レベルの一例）を向上させる制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末において視聴者行動が行われた場合に、端末のユーザに第１ポイントを付与するとともに、端末のユーザの第１レベルを向上させることができる。
また、この場合、ユーザ経験値を付与する制御は、ライブ動画の視聴中に制御部１１によって行われ、ユーザレベルを向上させる制御は、ライブ動画の視聴中に制御部１１によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の視聴中に、端末のユーザにポイントを付与したり、レベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
本実施例は、ライブ動画を配信する配信者の端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、ライブ動画の配信実績に基づいて配信者にライバー経験値（限定ではなく、第２ポイントの一例）を付与する制御を制御部１１によって行う。そして、サーバ１０は、配信者に付与されたライバー経験値の増加に基づいて、配信者のライバーレベル（限定ではなく、第２レベルの一例）を向上させる制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、端末のユーザに第２ポイントを付与するとともに、端末のユーザの第２レベルを向上させることができる。
また、この場合、ライバー経験値を付与する制御は、ライブ動画の配信中に制御部１１によって行われ、ライバーレベルを向上させる制御は、ライブ動画の配信中に制御部１１によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができる。
＜第２実施例＞
第２実施例は、所定条件が成立した場合に、限定ではなく例として、ユーザのライバー経験値を減少させたり、ライバーに対して特典の付与や報酬の支払い等を行うことを可能にする実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
所定条件の成立は、限定ではなく例として、所定期間の経過（所定期間の終了）とすることができる。所定条件は、限定ではなく例として、サーバ１０が設定するようにすることができ、所定期間も、サーバ１０が設定するようにすることができる。
本実施例では、上記の所定期間を、１シーズンごとの期間として「シーズン期間」や単に「シーズン」と称する。シーズン期間はどのように設定してもよいが、限定ではなく例として、毎月のひと月の期間（１日から月末日までの期間）とすることができる。つまり、ひと月を単位として連続的にシーズン期間が設定されるようにすることができる。
なお、所定条件の別例については後述する。
図１－１６に示したように、ライバーランクには「ルーキー」～「神」等を設けることができる。あくまでも一例であるが、ライバーランク「ルーキー」から「レジェンド」まではユーザがライバー経験値を稼いでライバーランクを上げていき、ライバーランク「神」を目指すようにすることができる。言ってみれば、より上位のライバーランクを目指して自分を成長させる遊びとすることができる。
その一方で、最上位のライバーランク「神」については、ランク内レベルに上限を設けず（図１－１６に示したように「Ｌｖ１～上限なし」）、どこまでライバー経験値やランク内レベルを伸ばせるかユーザが追い求める遊びとすることができる。本実施例では、これに加えて、限定ではなく例として、所定期間ごとに、ライバーランクが「神」であるユーザ同士でランキングを競わせる。また、本実施例では、ライバーランクが「神」であるユーザには、所定期間ごとに、その所定期間における成績に応じた報酬を支払うようにする。さらに、本実施例では、所定期間ごとに、その所定期間が終了した場合に、ライバーランクが「神」であるユーザのライバー経験値を減少させ、ライバーレベルを低下させることで、ライバーレベルのレベルアップのスピードを緩やかにする。
＜表示画面＞
図２－１は、本実施例において端末２０Ａの表示部２４に表示されるライブ配信アプリケーションの画面の一例を示す図である。
図２－１左側は、ライブ配信アプリケーションのマイページ画面であり、図１－１１に引き続き、ユーザＡ．Ａが視聴者やライバーとなってライブを視聴したりライブを配信し、シーズン２の期間が終了した場合のマイページ画面の一例を示す図である。
この画面では、ユーザレベル情報表示領域ＵＬＲにユーザレベルとして「Ｌｖ６９」が表示され、ライバーレベル情報表示領域ＬＬＲにライバーレベルとして「神 Ｌｖ１２」（ライバーランク「神」、ランク内レベル「Ｌｖ１２」）が表示されている。
以下では、ライバーランク「神」におけるランク内レベルのことを、便宜的に「神レベル」と称する場合がある。
また、ユーザＡ．Ａがライバーランク「神」になってからライバー活動を続けてランク内レベルが向上したことに基づき（現在は「Ｌｖ１２」）、ユーザＡ．Ａは、図１－１１中央、右側の画面に示したランクバッジＲＢ１よりも位の高いランクバッジＲＢ２を獲得し、さらにフレームＦＭ２、マイページ背景ＢＧ２を獲得している。そして、これに伴い、プロフィール領域には、プロフィールアイコンと関連付けてランクバッジＲＢ２が表示され、プロフィールアイコンにフレームＦＭ２が設定され、背景画像にマイページ背景ＢＧ２が設定されている。
また、シーズン２の期間が終了したことに伴い、アプリ内位置表示領域の下に構成される領域の最上部右のランキングアイコンＩＣ１から、シーズン期間が終了したことを示す情報が吹き出しで表示されている。この例では、「シーズン２」の期間が終了したことに基づいて「シーズン２が終了しました」の文字を含む吹き出しが表示されている。
この場合、ランキングを示すアイコン画像がタップされると、限定ではなく例として、図２－１中央の画面が表示される。
この画面は、各々のシーズン期間におけるユーザのランキングを示すシーズンランキング画面の一例であり、アプリ内位置表示領域には「シーズンランキング」の文字が表示されている。
また、その下の領域の最上部には、終了した直近のシーズン期間（この例では「シーズン２」）を示す情報（この例では「シーズン２終了」の文字を含む枠）が表示され、その左には、過去のシーズン期間におけるランキングを表示させるためのボタンが表示されている。
この例では、「シーズン２」におけるユーザのランキングとして、１位が「ユーザＤ．Ｄ」であり、２位が「ユーザＡ．Ａ」であり、３位が「ユーザＣ．Ｃ」であり、４位が「ユーザＢ．Ｂ」であることが示されている。また、各々の順位について、その順位のユーザのアイコン画像およびユーザ名が表示され、これらと関連付けて、そのユーザがシーズンランキング報酬として獲得したトロフィーの数と、そのユーザの現在のライバーレベルとが表示されている。
なお、ユーザのランキングは、限定ではなく例として、各々の配信者がシーズン期間中に獲得したライバー経験値の総量や、各々の配信者のシーズン終了時点でのライバー経験値（今シーズン最終ライバー経験値）に基づいて決定することができる。
図２－１中央の画面において、限定ではなく例として、「ゲット」ボタンＢＴ１がタップされると、限定ではなく例として、図２－１右側の画面が表示される。この画面には、そのシーズンにおいてユーザＡ．Ａが獲得したシーズン報酬に関する情報が表示されている。
シーズン報酬は、限定ではなく例として、シーズンレベル報酬とシーズンランキング報酬とを合算した報酬（シーズンレベル報酬＋シーズンランキング報酬）とすることができる。
具体的には、上部には、ユーザＡ．Ａの神レベル「Ｌｖ１２」に基づいて付与されたシーズンレベル報酬に関する情報が表示されている。具体的には、神レベルに応じたシーズンレベル報酬が、神レベル帯ごとに区分されたピラミッドによって表示されている。ユーザＡ．Ａの神レベルは「Ｌｖ１２」であるため、ピラミッドのうちの「Ｌｖ１１～Ｌｖ２０」の神レベル帯が色付けて表示されており、対応するシーズンレベル報酬「１０，０００」トロフィーが付与されたことが示されている。
また、その下には、ユーザＡ．Ａのシーズンランキング「２位」に基づいて付与されたシーズンランキング報酬に関する情報が表示されている。具体的には、ユーザＡ．Ａのシーズンランキングが「２位」であることに基づき、対応するシーズンランキング報酬「５０，０００」トロフィーが付与されたことが示されている。
さらに、この例では、シーズンランキングが「２位」であることに基づき、シーズンランキング称号（獲得称号）「万年二位！」を獲得したことが示されている。
さらに、その下には、ユーザＡ．Ａのシーズン報酬に関する情報が表示されている。具体的には、上記のシーズンレベル報酬「１０，０００」トロフィーと、シーズンランキング報酬「５０，０００」トロフィーとを合算し、シーズン報酬として「６０，０００」トロフィーを獲得したことが示されている。
ここで、上記のトロフィーは、限定ではなく例として、ライバーランクのうちの最上位のランクである「神」となったユーザに付与される特典（報酬と捉えてもよい。）とすることができる。
トロフィーは、１つの考え方としては、前述した「ランクバッジ」、「フレーム」、「マイページ背景」等のオブジェクトと同様の特典としてのオブジェクトと捉えることもできる。
また、これとは別に、トロフィーは、限定ではなく例として、所定のポイントや現金など、有価価値のある報酬に変換可能な特典とすることができる。
ライバーの活動により、前述した視聴者からの課金アイテムによって、ライブ配信サービス事業者が収益を得ることを可能とすることができる。そして、その収益の一部を、シーズン報酬に基づいてライバーに還元するようにすることができる。
ポイントは、限定ではなく例として、ライブ配信サービス事業者と提携している事業者が提供する各種のサービスや、ライブ配信サービス事業者自体が提供する各種のサービス等において有価価値として利用可能なポイントとすることができる。
ここで言うポイントは、限定ではなく例として、法定通貨とは異なる企業通貨の一種と捉えてもよい。
なお、電子マネーも企業通貨の一種と捉えてもよく、ポイントに代えて電子マネーを付与してもよい。
ポイントは、限定ではなく例として、電子マネーを使用した支払い（決済）を行うための支払いアプリケーション（支払いアプリケーションを含む包括的なアプリケーションとしてウォレットアプリケーションを構成してもよい。）における支払いに充当したり、メッセージングアプリケーションにおいてスタンプや着せ替えの購入に利用したり、音楽配信アプリケーションにおいて音楽の購入やクーポンへの交換に利用したりするなどの用途で用いられるようにすることができる。また、この他にも、上記のサービスの事業者が提携している店舗（加盟店）で商品やサービスの交換に用いることを可能としてもよい。
ポイントの付与は、限定ではなく例として、サーバ１０が、端末２０でダウンロードされて端末２０で実行される支払いアプリケーションやウォレットアプリケーションにおいて、端末２０のユーザに対して付与するようにすることができる。
また、現金の支払いは、限定ではなく例として、サーバ１０が、ユーザが登録している金融機関の口座にその金融機関のサーバと通信して振込によって支払うようにすることもできる。なお、端末２０でダウンロードされて端末２０で実行される支払いアプリケーションやウォレットアプリケーションにおいて、電子マネーの形態で支払いを行うようにしてもよい。
また、上記の各種のアプリケーションを統合的なアプリケーションとして構成し、この統合的なアプリケーション内で完結させるようにしてもよい。
また、限定ではなく例として、メッセージングアプリケーションに上記の各種のアプリケーションの機能を持たせて、このメッセージングアプリケーション内で完結させるようにしてもよい。
この場合、サーバ１０に全ての機能を持たせてもよいし、機能ごとにサーバを分けてもよい。
限定ではなく例として、ライブ配信アプリケーションに一般ユーザとしてアカウント登録し、さらにライバー登録したユーザは、限定ではなく例として、大きく以下の２つのユーザに分類することができる。
（ａ）無所属のユーザ（事務所に所属していないユーザ）
（ｂ）ライバー事務所に所属しているユーザ
また、（ｂ）のユーザは、限定ではなく例として、大きく以下の２つに分けることができる。
（ｂ１）ライブ配信サービス事業者が運営するライバー事務所に所属するユーザ
（ｂ２）ライブ配信サービス事業者以外の外部のライバー事務所に所属するユーザ
サーバ１０は、限定ではなく例として、上記のユーザの区分に基づいて、ユーザに支払う報酬の種別や、支払う報酬の割合（支払い率）を異ならせるようにすることができる。
限定ではなく例として、（ａ）のユーザには報酬としてポイントを支払い、（ｂ）のユーザには報酬として現金を支払うようにするなどすることができる。
サーバ１０は、限定ではなく例として、（ａ）のユーザは支払い率を「２０％」とし、シーズン報酬の「２０％」分のポイントを報酬として支払うようにするなどすることができる。
また、サーバ１０は、限定ではなく例として、（ｂ１）のユーザと（ｂ２）のユーザとで支払い率を異ならせることができる。
限定ではなく例として、（ｂ１）のユーザは支払い率を「４０％」とし、シーズン報酬の「４０％」に相当する金額を現金で支払うようにする。それに対し、（ｂ２）のユーザは支払い率を「５０％」とし、シーズン報酬の「５０％」に相当する金額を現金で支払うなどするようにすることができる。この例は、限定ではなく例として、（ｂ２）のユーザの方が（ｂ１）のユーザよりも支払い率を高くする例である。
ただし、支払い率の関係を逆にしてもよい。
なお、（ａ）のユーザと（ｂ）のユーザとを区別せず、両者にポイントや電子マネー等の企業通貨を付与したり、両者に現金を支払うようにしてもよい。
また、（ｂ１）のユーザと（ｂ２）のユーザとを区別せず、両者の支払い率を同じとしてもよい。
また、上記の例とは支払い率を異ならせてもよい。
図２－２左側は、図２－１右側の画面において「ＯＫ」ボタンＢＴ２がタップされた場合に表示される画面の一例を示す図である。
この画面は、シーズンランキング画面の一例であり、この例では、シーズン２終了に伴い、ユーザＡ．Ａの神レベルが低下したことを示す情報が表示されている。
具体的には、シーズン３の初期のユーザＡ．Ａのライバー経験値が、シーズン２終了時の「４４３，２９７」から「３２１，６４９」に低下することが示されている。この計算方法については詳細に後述する。
また、ライバー経験値の減少に伴い、シーズン３の初期のユーザＡ．Ａの神レベルが、シーズン２終了時の「Ｌｖ１２」から「Ｌｖ７」に低下することが示されている。
図２－２左側の画面において「ＯＫ」ボタンＢＴ３がタップされると、限定ではなく例として、図２－２右側の画面が表示される。
この画面は、前述したマイページ画面であり、プロフィール領域には、前述したランクバッジＲＢ２、フレームＦＭ２、マイページ背景ＢＧ２の他、限定ではなく例として、図２－１右側の画面に示した「万年二位！」のシーズンランキング称号ＡＴ２（前述したオブジェクトと捉えてもよい。）がシーズン期間（この例では「シーズン２」）と関連付けて表示されている。
また、ライバーレベル情報表示領域ＬＬＲには、ライバーランク「神」に対応するキャラクタ（くまのキャラクタ）のアイコン画像とともに、上記のように神レベルが「ＬＶ１２」から「ＬＶ７」に低下したことに伴い「神 Ｌｖ７」と表示されている。
＜処理＞
図２－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、図１－１２と同様である。
Ｓ１４０の後、またはＳ１３０において端末２０Ａからライブ配信要求情報を受信しなかったと判定した場合（Ｓ１３０：ＮＯ）、サーバ１０の制御部１１は、シーズンが終了したか否かを判定する（Ｓ２１０）。シーズンの終了は、限定ではなく例として、時計部１９の計時情報に基づいて判定することができる。
シーズンが終了していないと判定したならば（Ｓ２１０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１１０に処理を戻す。
一方、シーズンが終了したと判定したならば（Ｓ２１０：ＹＥＳ）、サーバ１０の制御部１１は、シーズン結果算出処理を行う（Ｓ２２０）。
図２－４は、シーズン結果算出処理で算出されるシーズン結果のうちのシーズンレベル報酬および次シーズンのライバーレベルの決定方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されている。
このテーブルにおいて、神レベルは、今シーズン終了時におけるライバーランク「神」のユーザのランク内レベルであり、この例では、一定の幅を持たせた神レベル帯が定められている。
このテーブルにおいて、シーズンレベル報酬は、限定ではなく例として、今シーズン終了時におけるユーザの神レベルが属する神レベル帯に応じてそのユーザに付与される報酬とすることができる。シーズンレベル報酬の一例は、前述したトロフィーとすることができる。
このテーブルにおいて、シーズンリセット経験値損失率は、次シーズンの初期ライバー経験値（以下、「次シーズン初期ライバー経験値」と称する。）を算出するために用いられる値である。
次シーズン初期ライバー経験値は、限定ではなく例として、以下の式（１）に従って算出するようにすることができる。
次シーズン初期ライバー経験値＝今シーズン最終ライバー経験値－（今シーズン最終ライバー経験値－神レベルＬｖ１に対応する達成ライバー経験値）×シーズンリセット経験値損失率 ・・・（１）
今シーズン最終ライバー経験値は、限定ではなく例として、今シーズン終了時におけるライバー経験値とすることができる。
神レベルＬｖ１に対応する達成ライバー経験値は、限定ではなく例として、図１－１６に示したテーブルにおいてライバーランク「神」に関連付けられた達成ライバー経験値の下限の値（図１－１６の例では「２００，０００」）とすることができる。
式（１）によれば、次シーズン初期ライバー経験値が神レベルＬｖ１に対応する達成ライバー経験値を下回らないため、ライバーランクが「神」から落ちることはない。これは、ライバーランクが「神」から落ちるようにするとユーザにとって酷である可能性があるためである。
なお、本実施例とは異なり、ライバーランクが「神」から落ちる場合があるように式（１）を改変してもよい。
また、限定ではなく例として、今シーズンにライバーの神レベルがアップしていた場合のシーズンリセット経験値損失率を、上記のテーブルに設定されている割合よりも低くしてもよい。
シーズンレベル報酬は、神レベル（神レベル帯）が高くなるほど、値が大きくなるように設定されている。つまり、今シーズン終了時におけるユーザの神レベルが高いほど、多くのシーズンレベル報酬が付与されるように値が設定されている。
また、この例では、シーズンリセット経験値損失率は、総体的には、神レベル（神レベル帯）が高くなるほど小さくなるように値が設定されている。つまり、今シーズン終了時におけるユーザの神レベルが高いほど、ライバー経験値の減少割合が小さくなる（損失率が低くなる）ように値が設定されている。ただし、図２－４の例では、異なる神レベル帯であっても同じ値が設定される場合があることとしている。
限定ではなく例として、図２－２左側の画面に示した例では、ユーザＡ．Ａのシーズン２における神レベルが「Ｌｖ１２」であり、今シーズン最終ライバー経験値が「４４３，２９７」である。
また、図２－４において、神レベル「Ｌｖ１２」に対応するシーズンリセット経験値損失率は「５０％」である。
また、図１－１６において、神レベル達成ライバー経験値は「２００，０００」である。
この場合、式（１）に従ってユーザＡ．Ａの次シーズン初期ライバー経験値を算出すると、
次シーズン初期ライバー経験値＝４４３，２９７－（４４３，２９７－２００，０００）×５０％＝３２１，６４９
と算出される。そして、これに対応する神レベルは「Ｌｖ７」となる。
なお、減少後のライバー経験値が、経験値減少前の神レベルの範囲内であれば、神レベルは変化しない。
図２－５は、シーズン結果算出処理で算出されるシーズン結果のうちのシーズンランキング報酬の決定方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、神ランキングと、シーズンランキング報酬とが関連付けて設定されている。
神ランキングは、限定ではなく例として、今シーズンにおけるユーザのランキングであり、ライバーランクが「神」であるユーザのランキング（順位）として集計される。
シーズンランキング報酬は、限定ではなく例として、今シーズンにおけるユーザの神ランキングに応じてそのユーザに付与される報酬とすることができる。シーズンランキング報酬も、限定ではなく例として、前述したトロフィーとすることができる。
シーズンランキング報酬は、神ランキング（シーズンランキング）が高くなるほど、値が大きくなるように設定されている。つまり、ランキングの上位者ほど、より多くのシーズンランキング報酬が付与されるように設定されている。
また、この例では、ある程度上位の神ランキング（限定ではなく例として「１位～３位」）については、そのシーズンランキング報酬として、図２－４に設定されている平均的なシーズンレベル報酬に対して、相対的に大きめの値が設定されている。つまり、この例では、シーズンランキングで上位を目指す方が、神レベルのアップを目指すよりも多くの報酬を得やすくなっている。
このようにすることで、ユーザのシーズンランキング報酬に対する獲得意欲を高めることができる。シーズン終了時の神レベルは、シーズン期間によらない長期的な配信者としての実績に左右されるのに対して、シーズンランキングは、シーズン期間内におけるより短期的な配信者としての実績に左右される。そのため、新規の配信者にとって、シーズンランキング報酬はシーズンレベル報酬よりもより獲得が狙いやすい。シーズンランキング報酬をより高く設定することで、結果的に、ライブ配信コミュニティ内の活動が活発化し、ライブ配信サービス内のライブ配信数やライブのクオリティ向上が期待される。
なお、ある程度上位の神レベル（限定ではなく例として「Ｌｖ５１～」）については、そのシーズンレベル報酬として、図２－５に設定されている平均的なシーズンランキング報酬と比べて、相対的に大きめの値を設定するようにしてもよい。
また、神ランキングに関連付けて前述したシーズンランキング称号をこのテーブルに設定しておき、サーバ１０の制御部１１が、これに基づいて、ライバーにシーズンランキング称号を与えるようにしてもよい。
本実施例では、上記のようにシーズンランキング報酬を設け、シーズンにおけるランキングに応じて、付加的な報酬を与えるようにしている。このようにすることで、最上位のライバーランクまで昇り詰めたユーザに対して、上位の順位を目指すように努力するモチベーションを与えることができる。
サーバ１０の制御部１１は、ユーザＡ．Ａのライバーレベルが「神」である場合において、シーズン終了時におけるユーザＡ．Ａの神レベルに基づき、図２－４のテーブルを参照して、この神レベルに対応するシーズンレベル報酬を決定する。また、サーバ１０の制御部１１は、その神レベルに対応するシーズンリセット経験値損失率に基づき、限定ではなく例として、式（１）に従ってユーザＡ．Ａの次シーズン初期ライバー経験値を算出する。
さらに、サーバ１０の制御部１１は、各々の端末２０のユーザの神レベルに基づいて、ユーザＡ．Ａのシーズンランキングを特定する。そして、サーバ１０の制御部１１は、図２－５のテーブルを参照して、特定したシーズンランキングに応じたユーザＡ．Ａのランキング報酬を決定する。そして、サーバ１０の制御部１１は、「シーズンレベル報酬＋シーズンランキング報酬」を、ユーザＡ．Ａに付与するシーズン報酬に決定する。
Ｓ２２０の後、サーバ１０の制御部１１は、シーズン結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２３０）。シーズン結果情報には、限定ではなく例として、上記のようにしてＳ２２０で算出した今シーズンのライバーレベル（ライバーランクが「神」である場合は神レベル）、シーズンランキング（ライバーランクが「神」である場合）、シーズン報酬（ライバーランクが「神」である場合）、次シーズン神レベル（ライバーランクが「神」である場合）等を含めることができる。そして、サーバ１０の制御部１１は、処理を終了する。
Ａ２１０においてシーズンが終了したと判定した場合（Ａ２１０：ＹＥＳ）、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から受信したシーズン結果情報を表示部２４に表示させる（Ａ２２０）。そして、端末２０Ａの制御部２１は、処理を終了する。
シーズンが終了した後、サーバ１０の制御部１１は、前述した各種の手法に基づいて、シーズン報酬に応じたポイントや現金をユーザに支払う支払い処理を行う。限定ではなく例として、月末日を集計の締め日とするのであれば、その翌日（月初日）に支払い処理を行い、シーズン報酬をリセットする。このようにして、シーズン報酬（トロフィー）をユーザが引き続き持てないようにする。
なお、図２－５のテーブルにおいて、限定ではなく例として、神ランキングが所定順位よりも上のライバーに対してのみシーズンランキング報酬が付与されるようにテーブルを構成してもよい。限定ではなく例として、シーズンランキングの上位５名のユーザに対してのみ、シーズンランキング報酬が付与されるようにしてもよい。
また、前述したシーズンレベル報酬やシーズンランキング報酬は、前述したように、特典と捉えてもよい。
また、前述したように、ライバーに応じて、上記の特典に関連付けられた報酬（ポイント、現金など）を異ならせてもよい。
＜第２実施例の効果＞
本実施例は、ライブ動画を配信する配信者の端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、ライブ動画の配信実績に基づいて配信者にライバー経験値（限定ではなく、ポイントの一例）を付与する制御を制御部１１によって行う。また、サーバ１０は、配信者に付与されたライバー経験値の増加に基づいて、配信者のライバーレベル（限定ではなく、レベルの一例）を向上させる制御を制御部１１によって行う。また、サーバ１０は、所定条件が成立した場合に、配信者に付与されたライバー経験値を減少させる制御を制御部１１によって行う。そして、サーバ１０は、ライバー経験値の減少に基づいて、配信者のライバーレベルを低下させる制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、配信者に付与されたポイントの増加に基づいて配信者のレベルを向上させる一方で、所定条件が成立した場合に、配信者に付与されたポイントを減少させ、そのポイントの減少に基づいて配信者のレベルを低下させることで、レベルが低下し得る危機感を配信者に持たせることができるとともに、ライブ配信を努力するモチベーションを配信者に持たせることができる。また、レベルの向上のスピードを緩やかにすることができる。さらに、新たな興趣を与えることができる。
また、この場合、ライバー経験値を付与する制御は、ライブ動画の配信中に制御部１１によって行われ、ライバーレベルを向上させる制御は、ライブ動画の配信中に制御部１１によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
また、この場合、サーバ１０は、配信者のライバーレベルが設定されたレベル（限定ではなく、所定レベルの一例）を超えている場合に、その設定されたレベルを超えていない場合よりも、配信者に付与されたライバー経験値の減少幅を少なくするようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者のレベルが所定レベルを超えている場合は、所定レベルを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、ハイレベルの配信者がモチベーションを失いにくくすることができる。
また、この場合、所定条件の成立は、シーズン期間（限定ではなく、所定期間の一例）の経過を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、所定期間が経過した場合に、配信者に付与されたポイントを減少させるため、配信者にとって分かり易い条件の成立に基づいてポイントを減少させることができる。
また、この場合、サーバ１０は、シーズン期間内に配信者に付与されたライバー経験値に基づくシーズンランキング（限定ではなく、所定期間内に配信者に付与されたポイントに基づく順位の一例）が所定順位よりも上である場合に、配信者にシーズンランキング報酬（限定ではなく、特典の一例）を付与する制御を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、所定期間内に配信者に付与されたポイントに基づく順位が所定順位より上である場合に、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
また、この場合、サーバ１０は、シーズンランキングが所定順位よりも上である場合と、所定順位よりも上ではない場合とのいずれの場合も、通算のライバー経験値（または神レベル）（限定ではなく、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計の一例）に基づいて、配信者にシーズンレベル報酬を付与する制御を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の順位が所定順位より上であろうとなかろうと、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
また、この場合、シーズンランキングが所定順位より上である場合に付与されるシーズンランキング報酬は、シーズン期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて配信者に付与されるシーズンレベル報酬よりも大きくなるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、配信者の順位が上位であればあるほど、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて配信者に付与される特典よりも多くの特典を配信者に付与することができる。その結果、仮に合計が低くても、順位の上位を目指すように配信者に努力させるきっかけを作ることができる。
また、本実施例は、配信者のライバーランク（限定ではなく、ランクの一例）として、少なくとも、神ランクより下位のランク（限定ではなく、第１ランクの一例）と、神ランク（限定ではなく、第１ランクよりも上位の第２ランクの一例）とを含む複数のライバーランクが設けられ、複数のライバーランクに対応した複数のランク内レベルが設けられ、配信者に付与されたライバー経験値が神ランクよりも下位のランクにおける最高のランク内レベルに対応する達成ライバー経験値を超過したことに基づいて、配信者のライバーランクが神ランクに向上する。そして、配信者のライバーランクが神ランクである場合に、配信者に付与されたライバー経験値に基づいて、神ランクにおける神レベルが向上する構成を示している。
このような構成により得られる実施例の効果の一例として、第１ランクから第２ランクに到達するまでの目標を設定し易くすることができる。
また、この場合、サーバ１０は、配信者のライバーランクが神ランクより下位のランクである場合に、所定条件の成立に基づく、配信者に付与されたライバー経験値を減少させる制御を行わず、配信者のライバーランクが神ランクである場合に、所定条件の成立に基づく、配信者に付与されたライバー経験値を減少させる制御と、このライバー経験値の減少に基づく、配信者の神レベルを低下させる制御とを行うようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者のランクが第２ランクよりも下位の第１ランクであれば、付与されたポイントを減少させる制御を行わないことで、第２ランクを目指すモチベーションを配信者に与えることができる。その一方で、配信者のランクが第２ランクに到達した後は、付与されたポイントを減少させる制御と、それに伴いレベルを低下させる制御とを行うことで、配信者に危機感を与えることができる。
また、この場合、所定条件が成立した場合に、配信者のライバーランクが神ランクから神ランクよりも下位のランクに低下しないようにすることができる。
このような構成により得られる実施例の効果の一例として、所定条件が成立した場合であっても、配信者のランクが第２ランクから第１ランクに低下しないようにすることで、配信者に安心感を与えることができる。
また、本実施例は、サーバ１０が、配信者にシリーズを付与する制御を制御部１１によって行う。この場合、配信者に応じて、特典に関連付けられた報酬が異なるようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者に特典を付与することができるとともに、配信者に応じて、特典に関連付けられた報酬を異ならせることができる。
＜第２変形例（１）＞
上記の実施例では、ユーザのライバー経験値やライバーレベルを減少させる条件（限定ではなく、所定条件の一例）を、シーズン期間（限定ではなく、所定期間の一例）の経過としたが、これに限定されない。
限定ではなく例として、前シーズンのシーズンランキングが１位であったユーザが今シーズンに入ってから獲得したライバー経験値が設定値以上（または設定値超）となったことや、前シーズンのシーズンランキングが１位であったユーザのライバー経験値が今シーズンのスタート時におけるライバー経験値から設定割合以上（または設定割合超）増加したことなどを、所定条件の成立としてもよい。これは、限定ではなく例として、今シーズンに入ってから特定のユーザが独走状態となったような場合である。
なお、任意のユーザのライバー経験値が設定値以上（または設定値超）となったことを、所定条件の成立としてもよい。これは、限定ではなく例として、シーズンのゴールとなるライバー経験値の到達値が予め設定される場合である。
所定条件は、限定ではなく例として、サーバ１０側で自由に設定可能とすることができる。
＜第２変形例（２）＞
上記の実施例では、所定期間として連続的なシーズン期間を例示したが、これに限定されない。
上記に限らず、離散的な期間を所定期間として設定してもよい。つまり、一定の時間間隔を置いてシーズン期間を設定するなどしてもよい。
また、連続的な期間であるか離散的な期間であるかに関わらず、期間の長さを可変にしてもよい。
限定ではなく例として、式（１）に従って算出される次シーズンライバー経験値の値が最も大きいユーザと、次シーズンライバー経験値が２番目に大きいユーザとの次シーズンライバー経験値の差が設定値以上（または設定値超）である場合は、今シーズンよりも短い期間を次シーズンの期間として設定するなどしてもよい。つまり、ランキングトップのユーザのライバー経験値が突出しているような場合に、さらに大きな差がつくことを防止するために、次シーズンの期間を短くしてもよい。
また、逆に、差が設定値未満（または設定値以下）である場合は、今シーズンよりも長い期間を次シーズンの期間として設定するなどしてもよい。
所定期間は、所定条件と同様に、限定ではなく例として、サーバ１０側で自由に設定可能とすることができる。
＜第２変形例（３）＞
上記の実施例で説明したライバー経験値を減少させる手法はあくまでも一例に過ぎず、これに限定されない。
図２－６は、図２－４のテーブルの別例を示す図である。
このテーブルには、図２－４のテーブルと同様に、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されているが、主としてシーズンリセット経験値損失率の欄が異なる。
シーズンリセット経験値損失率の欄は、限定ではなく例として、今シーズンが新記録ではない場合と、今シーズンが新記録である場合とに分けられている。
今シーズンが新記録である場合とは、各々のユーザについて、限定ではなく例として、そのユーザが今シーズンに獲得したライバー経験値が過去最高の値となったこととすることができる。それに対し、今シーズンが新記録ではない場合とは、上記以外の場合とすることができる。
なお、上記とは異なり、ユーザの今シーズンにおけるシーズンランキングが過去最高の順位となったことを、今シーズンが新記録となった場合としてもよい。
今シーズンが新記録ではない場合と今シーズが新記録の場合とのいずれについても、総体的には、神レベルが高くなるほど、シーズンリセット経験値損失率が小さくなるように値が設定されている。ただし、図２－６の例では、異なる神レベル帯であっても同じ値が設定される場合があることとしている。
その一方で、同じ神レベル（神レベル帯）に着目した場合、今シーズンが新記録の場合のシーズンリセット経験値損失率は、今シーズンが新記録ではない場合のシーズンリセット経験値損失率と比べて相対的に小さくなるように値が設定されている。つまり、今シーズが新記録であったライバーは、その実績を考慮して、ライバー経験値の減少割合を小さくしている。
なお、上記はあくまでも一例であり、これに限定されない。
神レベル（神レベル帯）に依らず、今シーズンが新記録の場合のシーズンリセット経験値損失率を一律の値（限定ではなく例として「３０％」）としてもよい。
また、新記録を履歴として残すことができるようにシーズンリセット経験値損失率を「０％」としてもよい。
本変形例は、サーバ１０が、シーズン期間（限定ではなく、所定期間）内に配信者に付与されたライバー経験値が設定された値（限定ではなく、所定ポイントの一例）を超えている場合に、設定された値を超えていない場合よりも、配信者に付与されたライバー経験値の減少幅を少なくする構成を示している。
このような構成により得られる変形例の効果の一例として、所定期間内に配信者に付与されたポイントが所定ポイントを超えている場合に、所定ポイントを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、所定期間内に配信者が多くのポイントを獲得したような場合に、その配信者のポイントがあまり減少しないようにすることができる。
＜第２変形例（４）＞
上記の実施例では、シーズン報酬（シーズンレベル報酬＋シーズンランキング報酬）に基づいてポイントや現金をユーザに支払うこととしたが、これに限定されない。
限定ではなく例として、シーズンレベル報酬に基づいてポイントや現金をユーザに支払うようにしてもよい。また、この場合、オブジェクトを異ならせ、限定ではなく例として、シーズンレベル報酬のオブジェクトは「トロフィー」とし、「シーズンランキング報酬」のオブジェクトは「メダル」とするなどしてもよい。このようにすることで、シーズンレベル報酬がポイントや現金に変換可能であることをユーザに認識させることができる。
なお、これとは逆に、シーズンランキング報酬に基づいてポイントや現金をユーザに支払うようにしてもよい。
＜第３実施例＞
第３実施例は、限定ではなく例として、視聴者としてライブ配信アプリケーションを利用していたユーザが、配信者（ライバー）としてデビューすることに関する実施例である。
ライブの視聴者の中には熱心な視聴者がいると考えられ、このような視聴者は、配信者としても成功する可能性があると考えられる。しかし、視聴者になることよりも配信者になることの方がハードルが高い場合がある。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図３－１は、本実施例において端末２０の表示部２４に表示されるライブ配信アプリケーション画面の一例を示す図である。ここでは、前述したユーザＡ．Ａとは異なるユーザとして、ユーザＦ．Ｆがライバーとしてデビューする場合を例示する。
以下説明する画面は、このユーザＦ．Ｆの端末２０Ｆの表示部２４に表示される画面である。
図３－１左側は、ライブ配信アプリケーションのマイページ画面であり、この例では、ユーザＦ．Ｆが視聴者としてライブ配信アプリケーションを利用しているのみで、未だライバーデビューしていない（ライバー登録していない）状態を示している。
プロフィール領域には、ユーザＦ．Ｆが設定したベース画像がプロフィールアイコンＰＩ３として表示されている。
また、ユーザＦ．Ｆが自ら背景を設定していない、またはライバー登録していないため背景を設定できないようになっている、などの理由で、この例では、マイページ背景ＢＧ３は無地（未設定）となっている。
また、ユーザＦ．Ｆはライバー登録していないため、図１－８左側に示した画面と同様に構成されたライバーレベル情報表示領域ＬＬＲには、ライバー登録するための情報として「ライバーになる」の文字が示されている。ライバーレベル情報表示領域ＬＬＲがタップされると、限定ではなく例として、図３－１中央の画面が表示される。
この画面は、限定ではなく例として図１－８中央に示した画面と同様に構成されたライブステータス画面であり、ライバーレベル詳細情報表示領域ＬＬＤＲには、ユーザＦ．Ｆがライバーデビューしたことに伴い、ライバーランク「ルーキー」、ランク内レベル「Ｌｖ１」が表示され、このライバーレベルに対応するキャラクタのアイコン画像としてカエルのキャラクタのアイコン画像が表示されている。
また、ライバーランクおよびランク内レベルの表示の下には、図１－８中央に示した画面と同様に、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値ゲージおよび文字が表示されている。しかし、この例では、本実施例に関連する表示として、ユーザＦ．Ｆがライバーデビューしたことに伴いユーザＦ．Ｆが取得したライバーボーナスに関する情報が表示されている。
詳細は後述するが、ユーザＦ．Ｆが視聴者として行動していた際に獲得したユーザ経験値とユーザレベルの少なくとも一方に基づくライバーボーナスとしてライバー経験値が付与され、この例では、「ライバーＥＸＰボーナス中！」の文字を含む吹き出しとともに、ライバーボーナスとして付与されたライバー経験値分だけ、ライバー経験値ゲージＬＧ１が増加する様子が示されている。この例では、このライバー経験値ゲージＬＧ１の増加は図３－１右側の画面まで続く。
最終的に、図３－１右側の画面が表示される。この例では、ライバーボーナスによって、結果的に、ユーザＦ．Ｆのライバーランクが下から２つ目の「レギュラー」、そのランク内レベルが「Ｌｖ２」までレベルアップした状態が示されている。
このように、本実施例では、ライバーデビューによってライバーボーナスが付与され、ライバーデビューした時点で、ライバーボーナス分だけライバーレベルが上がった状態でユーザＡ．Ａはライバーとしての活動が開始することができる。
図３－２は、図３－１とは異なり、ユーザＦ．Ｆがライバーデビューした後、ライブ配信を行う場合に表示される画面の一例を示す図である。
なお、ここでは、ユーザＦ．Ｆのライバーデビュー時にライバーボーナスは付与されておらず、ライバーランクが最下位の「ルーキー」、そのランク内レベル「Ｌｖ１」からスタートした場合を例示する。
図３－２左側のマイページ画面において、「ライバーになる」の文字を含むライバーレベル情報表示領域ＬＬＲがタップされ、サーバ１０によってライバー登録された後、ライブの配信がユーザＦ．Ｆによって開始されると、限定ではなく例として、図３－２中央の画面が表示される。
この画面は、ユーザＦ．Ｆによるライブ配信画面であり、図１－１０に示したユーザＡ．Ａがライブ配信を行う画面とほぼ同様の構成となっている。しかし、この例では、ユーザＦ．Ｆがライバーデビュー前に視聴者として行動していた際に獲得したユーザ経験値とユーザレベルの少なくとも一方に基づくライバーボーナスが、ユーザＦ．Ｆがライブ配信中に獲得したライバー経験値に上乗せされる。これを示すための表示として、ライバー経験値ゲージＬＧ２（「ルーキー Ｌｖ１」の文字を含むゲージ）の下には、「ライバーＥＸＰ１９０％ボーナス中！」の文字を含む吹き出しが表示されている。
ユーザＦ．Ｆがライバー経験値を取得すると、ライバーボーナス分だけ多くライバー経験値が溜まる。ユーザＦ．Ｆのライバーレベルがアップすると、限定ではなく例として、図３－２右側の画面が表示される。
ライバー経験値の取得に基づきランク内レベルが「Ｌｖ１」から「Ｌｖ２」にレベルアップしたことに基づき、ライバー経験値ゲージＬＧ２には、ライバーランク「ルーキー」の横にランク内レベル「Ｌｖ２」が表示されている。また、ライバー経験値ゲージＬＧ２のゲージ量が、ランク内レベル「Ｌｖ２」の対応する位置まで増加して表示されている。
また、ランク内レベルが「Ｌｖ２」にレベルアップしたことに基づき、ライバーレベルアップ情報ＬＵＩが画面中央部にポップアップ表示されている。このライバーレベルアップ情報ＬＵＩは、ランク内レベルがアップしたことを示す情報であるため、ライバーランク内レベルアップ情報と称してもよい。
また、コメント表示領域ＣＤＲには、ユーザＦ．Ｆを発信元とするコメントとして、ユーザＦ．Ｆのアイコン画像およびユーザ名と関連付けて「ランク内レベルが上がりました！」のテキストと、レベルアップ後のライバーレベル「ルーキー Ｌｖ２」のアイコンとを含むコメントＣＭ３が表示されている。コメントＣＭ３は、前述したコメントＣＭ１やコメントＣＭ２と同様に、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ライバーランクやランク内レベルがアップしたと判定したサーバ１０によって生成されて各々の端末２０に送信されるコメントとすることができる。
＜処理＞
図３－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は前述した通りである。
なお、前述したフローチャートに合わせて、端末２０Ａの制御部２１が実行する処理として図示・説明する。
Ａ１３０の後、端末２０Ａの制御部２１は、自己の端末２０ＡのユーザＡ．Ａがライバーデビューするか否かを判定する（Ａ３１０）。ライバーデビューしないと判定したならば（Ａ３１０：ＮＯ）、端末２０Ａの制御部２１は、Ａ２１０に処理を進める。
一方、ライバーデビューすると判定したならば（Ａ３１０：ＹＥＳ）、端末２０Ａの制御部２１は、ライバーとして参加することを要求するライバー参加要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３２０）。
Ｓ１２０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからライバー参加要求情報を受信したか否かを判定し（Ｓ３１０）、受信しなかったと判定したならば（Ｓ３１０：ＮＯ）、Ｓ１３０に処理を進める。
一方、ライバー参加要求情報を受信したと判定したならば（Ｓ３１０：ＹＥＳ）、サーバ１０の制御部１１は、ライバーボーナス算出処理を行う（Ｓ３２０）。
次いで、サーバ１０の制御部１１は、ライバーボーナス算出処理の算出結果に基づいて、ライバーボーナス情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ３３０）。そして、サーバ１０の制御部１１は、Ｓ１３０に処理を進める。
Ａ３２０の後、通信Ｉ／Ｆ２２によってサーバ１０からライバーボーナス情報を受信すると、端末２０Ａの制御部２１は、受信したライバーボーナス情報を表示部２４に表示させる（Ａ３３０）。そして、端末２０Ａの制御部２１は、Ａ１４０に処理を進める。
図３－４は、ライバーボーナスの算出方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ボーナス付与機会（ボーナス付与タイミング）と、ライバーボーナスと、第１の例と、第２の例と、第３の例とが関連付けて設定されている。
ボーナス付与機会は、そのライバーボーナスが付与される機会（タイミング）であり、この例では、「ライバー登録時」（ライブを配信する前の状態）と、「ライブ配信時」（ライブの配信中または配信後）とが定められている。
ライバーボーナスは、対応するボーナス付与機会にそのライバーに付与されるボーナスである。
ボーナス付与機会「ライバー登録時」には、限定ではなく例として、ライバーボーナスとして「［ユーザレベル×５０］のライバー経験値を初期値として設定」が定められている。これは、視聴者のユーザがライバーとなることを希望してサーバ１０が登録を行う場合に、そのユーザのライバー経験値の初期値を「０」とするのではなく、そのユーザの最新のユーザレベルに設定された倍率（この例では５０倍）を乗算した値をライバー経験値の初期値として設定することを示している。このようにすることで、ユーザレベルに応じた分のライバー経験値を取得した状態でライバーとしてデビューすることを可能とすることができる。
ボーナス付与機会「ライブ配信時」には、限定ではなく例として、ライバーボーナスとして「［配信実績に応じたライバー経験値］に（１００＋［ユーザレベル］）％を乗算」が定められている。これは、視聴者がライバーとして登録した後、ライブ配信を行っている最中、またはライブ配信を終了した後、ライバーボーナスとして、そのユーザがライブ配信の実績に応じて取得したライバー経験値に、ユーザレベルに応じたボーナス経験値を上乗せすることを示している。
第１の例～第３の例は、上記を適用する組合せ（パターン）を示している。
第１の例は、「ライバー登録時のライバーボーナス」は適用するが、「ライブ配信時のライバーボーナス」は適用しない例である。
第２の例は、「ライバー登録時のライバーボーナス」は適用しないが、「ライブ配信時のライバーボーナス」は適用する例である。
第３の例は、「ライバー登録時のライバーボーナス」と「ライブ配信時のライバーボーナス」とをいずれも適用する例である。
どの組合せを適用するかは、サーバ１０側で自由に設定可能とすることができる。
なお、課金等によってユーザ側（端末２０側）でどの組合せを適用するかを設定可能としてもよい。
「ライバー登録時のライバーボーナス」を適用する場合、サーバ１０の制御部１１は、図３－３のＳ３２０のライバーボーナス算出処理において、上記の計算式に基づいてライバーボーナスを算出し、その値をユーザＡ．Ａのライバー経験値の初期値として設定するようにすることができる。
また、サーバ１０の制御部１１は、上記のユーザＡ．Ａのライバー経験値の初期値に基づいて、限定ではなく例として、図１－１６に示したテーブルに基づいて、ユーザＡ．Ａのライバーレベルを決定し、それをユーザＡ．Ａのライバーレベルの初期値として設定するようにすることができる。
「ライブ配信時のライバーボーナス」を適用する場合、サーバ１０の制御部１１は、限定ではなく例として、図３－３のＳ１４０のステップで実行されるライブ配信処理（図１－１５）のＳ１４５０のステップにおいて、上記の計算式に基づいてライバーボーナスを算出し、その値でユーザＡ．Ａのライバー経験値を更新することができる。
なお、ライブ配信後にライバーボーナスを算出する場合は、サーバ１０の制御部１１は、限定ではなく例として、図３－３のＳ１４０のステップの後、上記の計算式に基づいてライバーボーナスを算出し、その値でユーザＡ．Ａのライバー経験値を更新することができる。
＜第３実施例の効果＞
本実施例は、ライブ動画が配信される端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、端末２０において視聴者行動が行われた場合に、端末２０のユーザにユーザ経験値（限定ではなく、第１ポイントの一例）を付与する制御を制御部１１によって行う。また、サーバ１０は、ユーザ経験値の増加に基づいて、端末２０のユーザのユーザレベル（限定ではなく、第１レベルの一例）を向上させる制御を制御部１１によって行う。そして、サーバ１０は、端末２０のユーザがライブ動画の配信者となる場合に、ユーザレベルに基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を決定する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、視聴者行動が行われたことに基づいて端末のユーザに付与された第１ポイントの増加に基づく第１レベルに基づいて、端末のユーザがライブ動画の配信者となる場合の第２レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、この場合、サーバ１０は、端末２０のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値（限定ではなく、第２ポイントの一例）を端末２０のユーザに付与する制御を制御部１１によって行う。また、サーバ１０は、ライバー経験値の増加に基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を向上させる制御を制御部１１によって行う。この場合、ライバー経験値は、ライブ動画の配信実績と、ユーザレベル（限定ではなく、第１レベル）とに基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第１ポイントとは異なる第２ポイントを端末のユーザに付与するとともに、第２ポイントの増加に基づいて、端末のユーザの第２レベルを向上させることができる。その一方で、第２ポイントは、ライブ動画の配信実績と第１レベルとに基づくため、ライブ動画の配信実績ばかりでなく、第１レベルも考慮されて第２ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
また、この場合、端末２０のユーザがライブ動画の配信者となる場合に決定されたライバーレベルが上位レベルである場合に、下位レベルに対応するライバーレベルが充足されたことが、限定ではなく例として、端末２０の表示部２４に表示されるライバー経験値ゲージが上位レベルまで増加する演出等によって端末２０のユーザに報知されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザが配信者となってから未だライブ動画の配信を開始していない段階で、既に下位のレベルを脱却していること端末のユーザに意識させることができる。また、配信者としてのモチベーションを向上させて端末のユーザの活動を支援することができる。
本実施例は、ライブ動画が配信される端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、端末２０において視聴者行動が行われた場合に、端末２０のユーザにユーザ経験値（限定ではなく、第１ポイントの一例）を付与する制御を制御部１１によって行う。また、サーバ１０は、ユーザ経験値の増加に基づいて、端末２０のユーザのユーザレベル（限定ではなく、第１レベルの一例）を向上させる制御を制御部１１によって行う。また、サーバ１０は、端末２０のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値（限定ではなく、第２ポイントの一例）を端末２０のユーザに付与する制御を制御部１１によって行う。また、サーバ１０は、ライバー経験値の増加に基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を向上させる制御を制御部１１によって行う。この場合、ライバー経験値（限定ではなく、第２ポイントの一例）は、ライブ動画の配信実績と、ユーザレベル（限定ではなく、第１レベル）とに基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、この場合、サーバ１０は、端末２０のユーザがライブ動画の配信者となる場合に、ユーザレベル（限定ではなく、第１レベルの一例）に基づいて、ライバーレベル（限定ではなく、第２レベルの一例）を決定する制御を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者となる場合に、端末のユーザの第１レベルに基づいて、端末のユーザの第２レベルを適切に決定することができる。
また、この場合、上記の視聴者行動は、ライブ動画の視聴を含み、そのライブ動画の視聴時間に応じて、付与されるユーザ経験値が異なるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、ライブ動画の視聴時間が長いほど多くの第１ポイントを端末のユーザに付与するといったことが可能となる。
また、この場合、視聴者行動は、ライブ動画に関する評価またはコメントを含むようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画に関する評価またはコメントが視聴者行動として行われたことに基づいて、端末のユーザに第１ポイントを付与することができる。
また、この場合、視聴者行動は、ライブ配信アプリケーションのサインインやログイン（限定ではなく、ライブ動画を視聴するためのユーザの認証の一例）を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画を視聴するためのユーザ認証が行われたことに基づいて、端末のユーザに第１ポイントを付与することができる。
また、この場合、サーバ１０は、端末２０のユーザがライブ動画を配信した場合に、ユーザ経験値を端末のユーザに付与する制御を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者として活動した場合でも、端末のユーザに第１ポイントを付与することができる。
また、この場合、サーバ１０は、端末２０のユーザがライブ動画の配信を所定時間行った場合に、ライブ動画の視聴を所定時間行う場合と少なくとも同じユーザ経験値を端末２０のユーザに付与するようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信を所定時間行った場合に、これと同じ所定時間ライブ動画を視聴する場合と同じかそれよりも大きい第１ポイントを端末のユーザに付与することができる。
＜第３変形例（１）＞
図３－４のテーブルでは、ユーザレベルに基づいてライバーボーナスが付与される例を示したが、これに限定されない。
具体的には、限定ではなく例として、ユーザ経験値に基づいてライバーボーナスが付与されるようにしてもよい。この場合は、限定ではなく例として、図３－４のテーブルにおける「ユーザレベル」を「ユーザ経験値」として倍率や割合を適宜設定して、ライバーボーナスが付与されるようにすることができる。
また、ユーザ経験値とユーザレベルとの両方に基づいてライバーボーナスが付与されるようにしてもよい。この場合は、限定ではなく例として、図３－４のテーブルにおいて、ボーナス付与機会「ライバー登録時」には、ライバーボーナス「［ユーザレベル×Ｃ１＋ユーザ経験値×Ｃ２］のライバー経験値を初期値として設定」（ただし、Ｃ１とＣ２は無次元化パラメータ）を関連付けておく。また、ボーナス付与機会「ライブ配信時」には、ライバーボーナス「［配信実績に応じたライバー経験値］に（１００＋［ユーザレベル］＋［ユーザ経験値］×Ｃ３）％を乗算」（ただし、Ｃ３はユーザ経験値のユーザレベルの次元に合わせるパラメータ）を関連付けておくなどすることができる。
ただし、これらはあくまでも一例に過ぎず、これらの計算式に限定されるわけではない。
また、ボーナス付与機会「ライバー登録時」について、ユーザレベルに基づいてライバーレベルを直接的に決定するようにしてもよい。限定ではなく例として、ユーザレベルが「Ｌｖ３０」であれば、ライバーレベルの初期値をライバーランク「ルーキー」のランク内レベル「Ｌｖ１０」とし、ユーザレベルが「Ｌｖ６０」であれば、ライバーレベルの初期値をライバーランク「レギュラー」の「Ｌｖ１０」とするなどしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
同様に、ボーナス付与機会「ライブ配信時」についても、ユーザレベルに基づいてライバーレベルを直接的に決定するようにしてもよい。限定ではなく例として、ユーザレベルが「Ｌｖ１００以上」であれば、ライブ配信時にライバーレベル（ランク内レベル）がアップする場合にライバーレベルを「１」上乗せしてレベルアップさせ、「Ｌｖ２００以上」であれば、ライブ配信時にライバーレベルがアップする場合にライバーレベルを「２」上乗せしてレベルアップさせるなどしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
上記の実施例および本変形例によれば、ライブ動画が配信される端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、端末２０において視聴者行動が行われた場合に、端末２０のユーザにユーザ経験値（限定ではなく、第１ポイントの一例）を付与する制御を制御部１１によって行う。また、サーバ１０は、ユーザ経験値の増加に基づいて、端末２０のユーザのユーザレベル（限定ではなく、第１レベルの一例）を向上させる制御を制御部１１によって行う。そして、サーバ１０は、端末２０のユーザがライブ動画の配信者となる場合に、ユーザ経験値（限定ではなく、第１ポイントの一例）とユーザレベル（限定ではなく、第１レベルの一例）の少なくとも一方に基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を決定する制御を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ポイントと第１レベルの少なくとも一方に基づいて、端末のユーザがライブ動画の配信者となる場合の第２レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、上記の実施例および本変形例によれば、サーバ１０は、端末２０のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値（限定ではなく、第２ポイントの一例）を端末２０のユーザに付与する制御を制御部１１によって行う。また、サーバ１０は、ライバー経験値の増加に基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を向上させる制御を制御部１１によって行う。そして、ライバー経験値は、ライブ動画の配信実績と、ユーザ経験値（限定ではなく、第１ポイントの一例）とユーザレベル（限定ではなく、第１レベル）の少なくとも一方と、に基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第１ポイントとは異なる第２ポイントを端末のユーザに付与するとともに、第２ポイントの増加に基づいて、端末のユーザの第２レベルを向上させることができる。その一方で、第２ポイントは、ライブ動画の配信実績と、第１ポイントと第１レベルの少なくとも一方と、に基づくため、ライブ動画の配信実績ばかりでなく、第１ポイントや第１レベルも考慮されて第２ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
また、上記の実施例および本変形例によれば、ライブ動画が配信される端末２０と通信するサーバ１０（限定ではなく、情報処理装置の一例）は、端末２０において視聴者行動が行われた場合に、端末２０のユーザにユーザ経験値（限定ではなく、第１ポイントの一例）を付与する制御を制御部１１によって行う。また、サーバ１０は、ユーザ経験値の増加に基づいて、端末２０のユーザのユーザレベル（限定ではなく、第１レベルの一例）を向上させる制御を制御部１１によって行う。また、サーバ１０は、端末２０のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値（限定ではなく、第２ポイントの一例）を端末２０のユーザに付与する制御を制御部１１によって行う。また、サーバ１０は、ライバー経験値の増加に基づいて、端末２０のユーザのライバーレベル（限定ではなく、第２レベルの一例）を向上させる制御を制御部１１によって行う。この場合、ライバー経験値は、ライブ動画の配信実績と、ユーザ経験値（限定ではなく、第１ポイントの一例）とユーザレベル（限定ではなく、第１レベル）の少なくとも一方と、に基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
本実施例および本変形例によれば、ライバー経験値やライバーレベルとは別に構成されたユーザ経験値やユーザレベルを、視聴者からライバーへの転換に活用することができる。つまり、ユーザ経験値やユーザレベルに基づくライバーボーナスを付与することによって、ライバーに転換したユーザのライバーレベルを向上し易くすることができる。
＜他の実施例＞
（１）情報処理装置
上記の実施例では、本開示における情報処理装置をサーバ１０として説明したが、これに限定されない。
サーバ１０を１つとするのではなく、サーバ１０を複数のサーバに分け、これら各々のサーバを本開示における情報処理装置としてもよい。
また、サーバではなく、ライブ配信を行う端末（ライブ配信を行うユーザの端末）と通信する管理用のコンピュータ等の端末や管理用のスマートフォン等の端末を、本開示における情報処理装置としてもよい。
また、複数の情報処理装置を含むシステムを構成し、このシステムが、上記の実施例で説明したサーバ１０の各種の処理を行うようにしてもよい。
（２）特典・報酬
ライバー経験値やライバーレベルに基づきユーザに付与される特典と同様に、ユーザ経験値やユーザレベルに基づき、ユーザに特典や報酬が付与されるようにしてもよい。
限定ではなく例として、前述したユーザ称号としてのバッジの他、フレームやマイページ背景等のオブジェクトを同様に付与するようにしてもよい。
また、最上位のライバーランク「神」よりも下のライバーランクについても、前述したシーズンランキング等を同様に構成して、ユーザにシーズン報酬を付与するようにしてもよい。
また、ユーザレベルについても同様に、シーズンランキング等を構成して、ユーザにシーズン報酬を付与するようにしてもよい。
また、ユーザ経験値やユーザレベルに基づきユーザに付与される特典や報酬は、ライバーに付与される特典や報酬と比べて相対的に少なくしてもよい。
（３）アイコンの表示態様
図４－１は、ユーザに関するアイコンの表示態様を説明するためのテーブルの一例を示す図である。
なお、ここで図示する組合せは、一部を例示したものである。
このテーブルには、限定ではなく例として、組合せと、プロフィールアイコンと、ユーザアイコンと、ライバーアイコンとが関連付けて設定されている。この例では、組合せとして「１」～「９」の９通りの組合せが含まれる。
プロフィールアイコンについては、前述した通りである。
このテーブルにおける「ユーザアイコン」は、限定ではなく例として、ユーザ経験値やユーザレベルに関連する活動に伴い表示されるそのユーザのアイコンや、ユーザレベルのレベルアップ時に表示されるそのユーザのアイコンとすることができる。限定ではなく例として、以下の少なくともいずれか１つをこれに含めることができる。
・ユーザが視聴者としてライブを視聴中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザレベルアップ時のユーザレベルアップ画面に表示されるアイコン
このテーブルにおける「ライバーアイコン」は、限定ではなく例として、ライバーとしての活動に伴い表示されるそのユーザ（そのライバー）のアイコンや、ライバーレベルのレベルアップ時に表示されるそのユーザ（そのライバー）のアイコンとすることができる。限定ではなく例として、以下の少なくともいずれか１つをこれに含めることができる。
・ユーザがライバーとしてライブを配信中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザがライバーとしてライブを配信中にライブ画面に表示される自身のアイコン
・ライバーレベルアップ時のライバーレベルアップ画面に表示されるアイコン
そして、このテーブルでは、各々の組合せについて、プロフィールアイコンと、ユーザアイコンと、ライバーアイコンとして表示する各々の画像等の組合せが設定されている。
なお、テーブル中の「ベース画像」については、前述した通りである。
組合せ「１」のライバーアイコンに設定されている「ベース画像（ライバー経験値が基準以下）」は、ライバー経験値が基準以下である場合は、ライバーとしての配信実績が乏しいため、ライバーアイコンとして「ベース画像」を表示することを意味する。
この例において、「ユーザ経験値に応じたオブジェクト」は、ユーザ経験値（またはユーザレベル）に基づきユーザに付与される特典としてのオブジェクトであって、限定ではなく例として、前述した「ユーザ称号としてのバッジ」（前述した「ランクバッジ」とは異なる。）等をこれに含めることができる。
また、この例において、「ライバー経験値に応じたオブジェクト」は、ライバー経験値（またはライバーレベル）に基づきユーザに付与される特典としてのオブジェクトであって、限定ではなく例として、前述した「ランクバッジ」、「フレーム」、「マイページ背景」、「獲得称号」、「トロフィー」等をこれに含めることができる。
なお、ユーザアイコンに「ベース画像」とあるのは、ユーザ経験値に応じたオブジェクト自体が仕様として設けられていない場合と、ユーザ経験値に応じたオブジェクトが仕様として設けられてはいるもののユーザ経験値が基準以下であることによりオブジェクトが付加されない場合と、のいずれの場合であってもよい。
また、前述したように、ユーザがライバー活動を行っている際に、ユーザレベルがレベルアップする場合がある。この場合は、図４－１のテーブルの「ユーザアイコン」の欄に示したユーザアイコンの表示を行うようにすることができる。
また、上記のプロフィールアイコン、ユーザアイコン、ライバーアイコンのいずれもが変更されない（すべてをベース画像のままとする）としてもよい。
（４）ライブ配信に基づく経験値
上記の実施例において、端末のユーザがライブ配信を行う場合には、ユーザ経験値を付与しないようにしてもよい。
（５）ユーザランク
上記の実施例において、ライバーランクと同様に、ユーザランクを設けてもよい。
また、各々のユーザランクの中に、対応するランク内レベルを設けてもよい。
（６）レベルの低下
上記の実施例において、情報処理装置が、所定条件が成立した場合に、配信者のレベルを低下させる制御を行うようにしてもよい。そして、低下させたレベルに応じて、配信者のポイントを減少させるようにしてもよい。つまり、ポイントを減少させることと、レベルを低下させることと、のいずれを先に行うこととしてもよいし、同時に行うようにしてもよい。
なお、配信者のレベルを低下させた場合に、配信者のポイントを減少させないようにしてもよい。
また、配信者のポイントを減少させることと、配信者のレベルを低下させることとの少なくともいずれか一方を行うようにしてもよい。
（７）ポイント
上記の実施例では、ポイントの一例として経験値を例示したが、他の単位としてもよい。つまり、配信や視聴に基づいて端末のユーザに付与される価値であればよく、必ずしも経験値という単位の価値である必要はない。
（８）その他
前述したように、上記の各々の実施例、各々の変形例、その他の実施例等で説明した内容は、それぞれ組み合わせて適用することが可能である。
１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク

Claims (16)

  1. ライブ動画が配信される端末と通信する情報処理装置によって実行されるプログラムであって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を前記制御部によって行うことと、
    前記ユーザが前記ライブ動画の配信者となる場合に、前記第１ポイントと前記第１レベルの少なくとも一方に基づいて、前記ユーザの第２レベルを決定する制御を前記制御部によって行うことと、
    を含むプログラム。
  2. 請求項１に記載のプログラムであって、
    前記ユーザが前記ライブ動画を配信した場合に、少なくとも配信実績に基づいて、前記第１ポイントとは異なる第２ポイントを前記ユーザに付与する制御を前記制御部によって行うことと、
    前記第２ポイントの増加に基づいて、前記第２レベルを向上させる制御を前記制御部によって行うことと、を含み、
    前記第２ポイントは、前記配信実績と、前記第１ポイントと前記第１レベルの少なくとも一方と、に基づく、
    プログラム。
  3. 請求項２に記載のプログラムであって、
    前記ユーザが前記ライブ動画の配信者となる場合に決定された前記第２レベルが上位レベルである場合に、下位レベルに対応する前記第２ポイントが充足されたことが前記端末の表示部において報知されるプログラム。
  4. ライブ動画が配信される端末と通信する情報処理装置によって実行されるプログラムであって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を前記制御部によって行うことと、
    前記ユーザが前記ライブ動画を配信した場合に、少なくとも配信実績に基づいて、前記第１ポイントとは異なる第２ポイントを前記ユーザに付与する制御を前記制御部によって行うことと、
    前記第２ポイントの増加に基づいて、前記ユーザの第２レベルを向上させる制御を前記制御部によって行うことと、を含み、
    前記第２ポイントは、前記配信実績と、前記第１ポイントと前記第１レベルの少なくとも一方と、に基づく、
    プログラム。
  5. 請求項４に記載のプログラムであって、
    前記ユーザが前記ライブ動画の配信者となる場合に、前記第１ポイントと前記第１レベルの少なくとも一方に基づいて、前記第２レベルを決定する制御を前記制御部によって行うことを含む、
    プログラム。
  6. 請求項１から請求項５のいずれか一項に記載のプログラムであって、
    前記視聴者行動は、前記ライブ動画の視聴を含み、
    視聴時間に応じて付与される前記第１ポイントが異なる
    プログラム。
  7. 請求項１から請求項６のいずれか一項に記載のプログラムであって、
    前記視聴者行動は、前記ライブ動画に関する評価またはコメントを含む
    プログラム。
  8. 請求項１から請求項７のいずれか一項に記載のプログラムであって、
    前記視聴者行動は、前記ライブ動画を視聴するための前記ユーザの認証を含む
    プログラム。
  9. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記ユーザが前記ライブ動画を配信した場合に、前記第１ポイントを前記ユーザに付与する制御を前記制御部によって行うことを含む
    プログラム。
  10. 請求項９に記載のプログラムであって、
    前記ユーザが前記ライブ動画の配信を所定時間行った場合に、前記ライブ動画の視聴を前記所定時間行う場合と少なくとも同じ前記第１ポイントが前記ユーザに付与されるプログラム。
  11. ライブ動画が配信される端末と通信する情報処理装置の情報処理方法であって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を前記制御部によって行うことと、
    前記ユーザが前記ライブ動画の配信者となる場合に、前記第１ポイントと前記第１レベルの少なくとも一方に基づいて、前記ユーザの第２レベルを決定する制御を前記制御部によって行うことと、
    を含む情報処理方法。
  12. ライブ動画が配信される端末と通信する情報処理装置の情報処理方法であって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を前記制御部によって行うことと、
    前記ユーザが前記ライブ動画を配信した場合に、少なくとも配信実績に基づいて、前記第１ポイントとは異なる第２ポイントを前記ユーザに付与する制御を前記制御部によって行うことと、
    前記第２ポイントの増加に基づいて、前記ユーザの第２レベルを向上させる制御を前記制御部によって行うことと、を含み、
    前記第２ポイントは、前記配信実績と、前記第１ポイントと前記第１レベルの少なくとも一方と、に基づく、
    情報処理方法。
  13. ライブ動画が配信される端末と通信する情報処理装置であって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御と、前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御と、前記ユーザが前記ライブ動画の配信者となる場合に、前記第１ポイントと前記第１レベルの少なくとも一方に基づいて、前記ユーザの第２レベルを決定する制御と、を行う制御部を備える情報処理装置。
  14. ライブ動画が配信される端末と通信する情報処理装置であって、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御と、前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御と、前記ユーザが前記ライブ動画を配信した場合に、少なくとも配信実績に基づいて、前記第１ポイントとは異なる第２ポイントを前記ユーザに付与する制御と、前記第２ポイントの増加に基づいて、前記ユーザの第２レベルを向上させる制御と、を行う制御部を備え、前記第２ポイントは、前記配信実績と、前記第１ポイントと前記第１レベルの少なくとも一方と、に基づく、情報処理装置。
  15. ライブ動画が配信される端末と通信する情報処理装置であって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
    前記プロセッサは、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を行うことと、
    前記ユーザが前記ライブ動画の配信者となる場合に、前記第１ポイントと前記第１レベルの少なくとも一方に基づいて、前記ユーザの第２レベルを決定する制御を行うことと、
    を実行する情報処理装置。
  16. ライブ動画が配信される端末と通信する情報処理装置であって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
    前記プロセッサは、
    前記端末において視聴者行動が行われた場合に、前記端末のユーザに第１ポイントを付与する制御を行うことと、
    前記第１ポイントの増加に基づいて、前記ユーザの第１レベルを向上させる制御を行うことと、
    前記ユーザが前記ライブ動画を配信した場合に、少なくとも配信実績に基づいて、前記第１ポイントとは異なる第２ポイントを前記ユーザに付与する制御を行うことと、
    前記第２ポイントの増加に基づいて、前記ユーザの第２レベルを向上させる制御を行うことと、を実行し、
    前記第２ポイントは、前記配信実績と、前記第１ポイントと前記第１レベルの少なくとも一方と、に基づく、情報処理装置。
JP2021165819A 2021-10-07 2021-10-07 プログラム、情報処理方法、情報処理装置 Pending JP2023056436A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2021165819A JP2023056436A (ja) 2021-10-07 2021-10-07 プログラム、情報処理方法、情報処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2021165819A JP2023056436A (ja) 2021-10-07 2021-10-07 プログラム、情報処理方法、情報処理装置

Publications (1)

Publication Number Publication Date
JP2023056436A true JP2023056436A (ja) 2023-04-19

Family

ID=86004703

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021165819A Pending JP2023056436A (ja) 2021-10-07 2021-10-07 プログラム、情報処理方法、情報処理装置

Country Status (1)

Country Link
JP (1) JP2023056436A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7376030B1 (ja) * 2022-09-22 2023-11-08 グリー株式会社 情報処理システム、情報処理方法およびコンピュータプログラム
JP7506243B1 (ja) 2023-11-01 2024-06-25 株式会社 ディー・エヌ・エー コンテンツ配信サービスを提供するためのシステム、方法、及びプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7376030B1 (ja) * 2022-09-22 2023-11-08 グリー株式会社 情報処理システム、情報処理方法およびコンピュータプログラム
JP7506243B1 (ja) 2023-11-01 2024-06-25 株式会社 ディー・エヌ・エー コンテンツ配信サービスを提供するためのシステム、方法、及びプログラム

Similar Documents

Publication Publication Date Title
US11413549B2 (en) Gameplay threads in messaging applications
AU2015363667B2 (en) A method and system for gaming revenue
US9576434B2 (en) Implementing computer activity-based challenges
US20130268479A1 (en) System and method for presenting and managing social media
US10318879B2 (en) Interactive live event outcome selection and prediction
CN104379225A (zh) 游戏控制装置、游戏控制方法、程序、记录介质、游戏系统
US20140179412A1 (en) Allowing Interactive Post of an Online Game within a Social Network
CN109428910B (zh) 一种数据处理方法、装置及系统
WO2016110797A1 (en) Device, system, and method of online betting and playing
JP2019118596A (ja) 抽選を提供するためのシステム、方法、及びプログラム
US20140068659A1 (en) Computer-implemented methods and computer systems for combining multichannel content presentation within interactive lottery/gaming environment in an interactive presentation device of a lottery/game operator
WO2012177787A1 (en) System and method for determining the relative ranking of a network resource
WO2019190648A1 (en) System and method for updating an application client
US11224816B2 (en) Computer-executable game on a graphical user interface with validity periods for game content
JP3216098U (ja) インタラクティブ環境における広告の提供システム
JP2023056436A (ja) プログラム、情報処理方法、情報処理装置
JP2023056435A (ja) プログラム、情報処理方法、情報処理装置
KR20120029980A (ko) 이동통신단말기를 이용한 이벤트 제공 방법 및 이를 위한 시스템
US9390581B2 (en) Information generation device, information provision system, and information storage medium
WO2014190421A1 (en) System and method for event promotion and fund raising
US20160012665A1 (en) Method and system is disclosed for delivering advertisements in a multi-gaming environment
JP2015195998A (ja) クイズ生成処理システム、ゲーム提供装置、クイズ生成処理プログラム及びゲーム提供装置
US9202201B2 (en) Approval based economy
KR20130082595A (ko) 온라인 게임에서의 소셜 네트워크 서비스 제공 방법 및 이를 수행하는 서버
CN109146436B (zh) 一种电子红包生成方法及装置

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20231027

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20231102