JP2023056435A - プログラム、情報処理方法、情報処理装置 - Google Patents
プログラム、情報処理方法、情報処理装置 Download PDFInfo
- Publication number
- JP2023056435A JP2023056435A JP2021165818A JP2021165818A JP2023056435A JP 2023056435 A JP2023056435 A JP 2023056435A JP 2021165818 A JP2021165818 A JP 2021165818A JP 2021165818 A JP2021165818 A JP 2021165818A JP 2023056435 A JP2023056435 A JP 2023056435A
- Authority
- JP
- Japan
- Prior art keywords
- user
- distributor
- level
- rank
- terminal
- 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
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 40
- 238000003672 processing method Methods 0.000 title claims description 5
- 238000009826 distribution Methods 0.000 claims abstract description 183
- 230000009467 reduction Effects 0.000 claims abstract description 10
- 238000012545 processing Methods 0.000 claims description 72
- 230000008901 benefit Effects 0.000 claims description 17
- 238000004891 communication Methods 0.000 abstract description 82
- 238000000034 method Methods 0.000 description 72
- 230000008569 process Effects 0.000 description 52
- 230000000694 effects Effects 0.000 description 42
- 230000006870 function Effects 0.000 description 37
- 210000004185 liver Anatomy 0.000 description 33
- 238000010586 diagram Methods 0.000 description 31
- 238000004364 calculation method Methods 0.000 description 26
- 238000007726 management method Methods 0.000 description 22
- 238000012384 transportation and delivery Methods 0.000 description 19
- 230000006399 behavior Effects 0.000 description 13
- 230000004048 modification Effects 0.000 description 13
- 238000012986 modification Methods 0.000 description 13
- 230000008450 motivation Effects 0.000 description 8
- 238000001514 detection method Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 238000005259 measurement Methods 0.000 description 4
- 241000283973 Oryctolagus cuniculus Species 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000003384 imaging method Methods 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 238000013215 result calculation Methods 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 229910000906 Bronze Inorganic materials 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 2
- 239000010974 bronze Substances 0.000 description 2
- KUNSUQLRTQLHQQ-UHFFFAOYSA-N copper tin Chemical compound [Cu].[Sn] KUNSUQLRTQLHQQ-UHFFFAOYSA-N 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000010079 rubber tapping Methods 0.000 description 2
- 230000001932 seasonal effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 229920001690 polydopamine Polymers 0.000 description 1
- 230000003578 releasing effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 229910052709 silver Inorganic materials 0.000 description 1
- 239000004332 silver Substances 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】ライブ配信に関する興趣や利便性等を向上させるプログラムおよび情報処理装置を提供する。【解決手段】通信システム1において、ライブ動画を配信する配信者の端末20Aと通信するサーバ10によって実行されるプログラムは、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御と、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御と、所定条件が成立した場合に、配信者に付与されたポイントを減少させる制御と、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御とを、制御部11に行わせる。【選択図】図1-1
Description
本開示は、プログラム、情報処理方法、情報処理装置等に関する。
ライブストリーミング等を利用して、ユーザが動画配信を行うことを可能にするサービスがある(例えば、特許文献1,特許文献2)。
本発明の第1の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置によって実行されるプログラムは、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御を情報処理装置の制御部によって行うことと、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御を制御部によって行うことと、所定条件が成立した場合に、配信者に付与されたポイントを減少させる制御を制御部によって行うことと、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御を制御部によって行うことと、を含む。
本発明の第2の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置の情報処理方法は、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御を情報処理装置の制御部によって行うことと、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御を制御部によって行うことと、所定期間が経過した場合に、配信者に付与されたポイントを減少させる制御を制御部によって行うことと、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御を制御部によって行うことと、を含む。
本発明の第3の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置は、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御と、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御と、所定期間が経過した場合に、配信者に付与されたポイントを減少させる制御と、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御と、を行う制御部を備える。
本発明の第4の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御を行うことと、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御を行うことと、所定条件が成立した場合に、配信者に付与されたポイントを減少させる制御を行うことと、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御を行うことと、を実行する。
本発明の第2の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置の情報処理方法は、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御を情報処理装置の制御部によって行うことと、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御を制御部によって行うことと、所定期間が経過した場合に、配信者に付与されたポイントを減少させる制御を制御部によって行うことと、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御を制御部によって行うことと、を含む。
本発明の第3の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置は、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御と、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御と、所定期間が経過した場合に、配信者に付与されたポイントを減少させる制御と、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御と、を行う制御部を備える。
本発明の第4の態様によると、ライブ動画を配信する配信者の端末と通信する情報処理装置は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、ライブ動画の配信実績に基づいて配信者にポイントを付与する制御を行うことと、配信者に付与されたポイントの増加に基づいて、配信者のレベルを向上させる制御を行うことと、所定条件が成立した場合に、配信者に付与されたポイントを減少させる制御を行うことと、配信者に付与されたポイントの減少に基づいて、配信者のレベルを低下させる制御を行うことと、を実行する。
<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
<実施形態>
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。
システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
また、クライアント(クライアント装置)とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
(1)端末&サーバ
(2)サーバ
(3)端末
(1)端末&サーバ
(2)サーバ
(3)端末
(1)は、限定ではなく例として、少なくとも1つの端末と、少なくとも1つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。
サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。
具体的には、サーバは、限定ではなく例として、少なくとも1つのプロセッサー(限定ではなく例として、CPU:Central Processing Unit、GPU:Graphics Processing Unit、APU:Accelerated Processing Unit、DSP:Digital Signal Processor(限定ではなく例として、ASIC:Application Specific Integrated Circuit、FPGA:Field Programmable Gate Array)等)、コンピュータ装置(プロセッサー+メモリ)、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか1つの装置の同種を複数備える構成(限定ではなく例として、CPU+CPU、ホモジニアスマルチコアプロセッサー等)や、いずれか1つの装置の異種を複数備える構成(限定ではなく例として、CPU+DSP、ヘテロジニアスマルチコアプロセッサー等)としてもよいし、複数の装置の組み合わせ(限定ではなく例として、プロセッサー+コンピュータ装置、プロセッサー+演算装置、複数の装置をヘテロジニアス化したもの等)であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。
また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第1処理をプロセッサーが実行し、第2処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるPaaSやIaaS、SaaSの形態で提供されるようにしてもよい。
また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、(1A)端末の制御部のみ、(1B)サーバの制御部のみ、(1C)端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
また、システムの制御部が行う制御や処理(以下、包括的に「制御等」と称する。)は、(1A)端末の制御部のみによって行うようにしてもよいし、(1B)サーバの制御部のみによって行うようにしてもよいし、(1C)端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第1装置と第2装置とを備え、第1装置は第1通信部を有し、第2装置は第2通信部を有する場合、サーバの通信部は、第1通信部と第2通信部とを含む概念としてもよい。
限定ではなく例として、サーバは、第1装置と第2装置とを備え、第1装置は第1通信部を有し、第2装置は第2通信部を有する場合、サーバの通信部は、第1通信部と第2通信部とを含む概念としてもよい。
(2)は、限定ではなく例として、複数のサーバによって構成されるシステム(以下、「サーバシステム」と称する。)とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。
サーバシステムが行う制御等は、複数のサーバのうち、(2A)一のサーバのみによって行うようにしてもよいし、(2B)他のサーバのみによって行うようにしてもよいし、(2C)一のサーバと他のサーバとが行うようにしてもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
(3)は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース(登録商標)等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース(登録商標)等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。
以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム(限定ではなく例として、クライアントサーバシステム)を例示する。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記(3)のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
また、本明細書では、適宜「通信I/Fによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部(プロセッサー等)の制御に基づいて、通信I/Fを介して(通信部を介して)、各種の情報やデータを送受信することを示してもよいものとする。
また、本明細書において「関する」、「関連する」と記載された用語について、「Aに関するB」や「Aに関連するB」という場合、限定ではなく例として、「A」と何らかの関係性を有する「B」を意味してよいものとする。この具体例については後述する。
また、本明細書において、「AとBとを送信する」、「AとBとを受信する」といったように、装置が2以上のものを対象として処理を行うことには、「A」と「B」とをタイミングを合わせて行うもの(以下、「同時」という。)と、「A」と「B」とをタイミングをずらして行うもの(以下、「非同時」という。)とを含めてよいものとする。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
なお、「A」と「B」とをタイミングをずらして行うといっても、これはあくまでも「A」と「B」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
ユーザがチャットを行うためのサービス(以下、「チャットサービス」と称する。)の一例として、メッセージングサービス(Messaging Service)を例示することができる。
また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにしてもよいし、しなくてもよい。
また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにしてもよいし、しなくてもよい。
なお、メッセージングサービス:MS(インスタントメッセージサービス:IMSを含む。)は、ソーシャルネットワーキングサービス:SNSの1つの形態(一形態)と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。
また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置(限定ではなく例として、端末)間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス:IMS(Instant Messaging Service)を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにしてもよいし、しなくてもよい。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにしてもよいし、しなくてもよい。
チャットルーム(限定ではなく例として、トークルーム)とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるUI(User Interface)やGUI(Graphical User Interface)とすることができる。
また、トークルームには、一対一のユーザのトークルーム(以下、「一対一トークルーム」と称する。)、複数のユーザを含むグループのトークルーム(以下、「グループトークルーム」と称する。)、公式アカウントのユーザとのトークルーム(以下、「OAトークルーム」と称する。)等を含めることができる。
なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、2名のユーザや2つのアカウントで構成されるグループのトークルームとして管理してもよい。
公式アカウントは、一般のユーザではなく事業者のアカウント(事業者のユーザのアカウント)であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ(メッセージ)の送受信を行うことができるようにすることができる。
本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、1または複数のコンテンツであってもよい。
コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像(静止画像、動画像の少なくともいずれか一方を含む。)形式の画像コンテンツ、音(音声を含む。)形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報(限定ではなく例として、URI(Uniform Resource Identifier)等を含む。)などのリンクコンテンツを含めてもよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報(限定ではなく例として、URI(Uniform Resource Identifier)等を含む。)などのリンクコンテンツを含めてもよいものとする。
テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか1つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか1つを含めることができる。
また、以下の実施例では、ユーザが動画像・音声等のライブコンテンツをライブ配信したり、ライブ配信されたライブコンテンツを視聴するためのサービスの一例として、ライブ配信サービスを例示する。また、ライブ配信サービスを実現するためのアプリケーションを「ライブ配信アプリケーション」と称する。また、ライブ配信アプリケーションの名称を「Live Streaming App」と称して図示する。
ライブ配信サービスを実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
(A)ライブ配信アプリケーションを単体として構成する形態
(B)メッセージングアプリケーションの一機能としてライブ配信サービスの機能を持たせる形態
(C)ライブ配信サービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(D)ライブ配信アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
(A)ライブ配信アプリケーションを単体として構成する形態
(B)メッセージングアプリケーションの一機能としてライブ配信サービスの機能を持たせる形態
(C)ライブ配信サービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(D)ライブ配信アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
(B)や(C)の形態では、限定ではなく例として、ライブ配信サービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、1つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる(連携される)ようにすることができる。
また、この場合、1つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる(連携される)ようにすることができる。
(D)の形態では、限定ではなく例として、ライブ配信サービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、(D)の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを関連付ける処理(連携する処理)を行うようにすることができる。
また、(D)の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、ライブ配信アプリケーションにおけるユーザのアカウントとを関連付ける処理(連携する処理)を行うようにすることができる。
なお、上記とは異なり、ライブ配信アプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。
また、本実施形態では、ユーザ間で情報が送受信されるという表現や、端末間で情報が送受信されるという表現を用いる場合があり得るが、これらは実質的に同義としてよいものとする。
また、クライアントサーバシステムを適用する場合、サーバを介して端末間で情報が送受信されるように構成することが可能であるが、これをユーザ間や端末間での情報の送受信と表現してもよいものとする。また、前述したように、クライアントサーバシステムを適用せずに端末間で情報を送受信してもよいものとする。
また、クライアントサーバシステムを適用する場合、サーバを介して端末間で情報が送受信されるように構成することが可能であるが、これをユーザ間や端末間での情報の送受信と表現してもよいものとする。また、前述したように、クライアントサーバシステムを適用せずに端末間で情報を送受信してもよいものとする。
また、以下の実施例では、ライブ配信として、配信者(ライバー)のユーザがライブ動画を配信し、視聴者のユーザがそのライブ動画を視聴する場合を例示する。そして、ライブコンテンツのライブ配信を単に「ライブ配信」と称する場合がある。また、ライブコンテンツをライブ配信するユーザのことを「ライバー」と称し、ライブ配信されたライブコンテンツを視聴するユーザのことを「視聴者」と称する場合がある。
また、以下の実施例では、ライブコンテンツをただ単に「ライブ」と称する場合がある。
また、以下の実施例では、ライブコンテンツをただ単に「ライブ」と称する場合がある。
また、ライブ配信サービスを実現するための形態として、前述した(A)~(D)のいずれの形態を適用してもよいが、以下の実施例では、限定ではなく例として、主として(A)ライブ配信アプリケーションを単体として構成する形態を適用する場合を例示する。
<第1実施例>
第1実施例は、ライバーや視聴者に経験値を付与したり、ライバーや視聴者をレベルアップさせることに関する実施例である。本実施例では、限定ではなく例として、経験値の付与やレベルアップがライブ配信中に、いわばリアルタイムに行われるようにする。
第1実施例は、ライバーや視聴者に経験値を付与したり、ライバーや視聴者をレベルアップさせることに関する実施例である。本実施例では、限定ではなく例として、経験値の付与やレベルアップがライブ配信中に、いわばリアルタイムに行われるようにする。
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<システム構成>
図1-1は、本開示の実施形態における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
図1-1は、本開示の実施形態における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
サーバ10は、ネットワーク30を介して、ユーザが所有する端末20に、所定のサービス(限定ではなく例として、ライブ配信サービス、メッセージングサービス等)を提供する機能を有する。サーバ10は、限定ではなく例として、ライブ配信サーバ、メッセージングサーバ等のように表現することもできる。
本実施形態では、ライブ配信サービス事業者(運営者)やメッセージングサービス事業者(運営者)を、サーバ10のユーザとする。
本実施形態では、ライブ配信サービス事業者(運営者)やメッセージングサービス事業者(運営者)を、サーバ10のユーザとする。
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
端末20(端末20A,端末20B,端末20C、・・・)は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、VR(Virtual Reality)端末、スマートスピーカ(音声認識用デバイス)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
端末20A、端末20Bおよび端末20Cの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザXが利用する端末を端末20Xと表現し、ユーザXまたは端末20Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定ではなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10等の各種装置との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10等の各種装置に送信する。また、通信I/F22は、サーバ10等の各種装置から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部23は、端末20に対する各種操作を入力する装置や、端末20で処理された処理結果を出力する装置等を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含む。
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ(音声出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
あくまでも一例であるが、入出力部23は、限定ではなく例として、表示部24、音入力部25、音出力部26、撮像部27を備える。
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
音入力部25は、音データ(音声データを含む。以下同様。)の入力に利用される。音入力部25は、マイクなどを含む。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部29Aは、端末20の内蔵時計であり、時刻情報(計時情報)を出力する。時計部29Aは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部29Aは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部29Aは、NITZ(Network Identity and Time Zone)規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部29Bは、制御部21が自己の端末20の位置を算出(測定)するために必要な情報(以下、「位置算出用情報」と称する。)を検出(計測)する機能部である。位置算出用情報検出部29Bは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部29Bは、限定ではなく例として、GPS(Global Positioning System)等の衛星測位システムを利用して端末20の位置を算出するためのセンサやユニットである衛星測位センサ(衛星測位ユニット)や、慣性航法システムを利用して端末20の位置を算出するためのセンサやユニットである慣性計測センサ(慣性計測ユニット(IMU(Inertial Measurement Unit)))、UWB(超広帯域無線:Ultra Wide Band)を利用して端末20の位置を算出するためのセンサやユニットであるUWB測位センサ(UWB測位ユニット)等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むRF(Radio Frequency)信号をデジタル信号に変換するRF受信回路や、RF受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末20の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、3軸の加速度センサや3軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
UWB測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域RF(Radio Frequency)信号をデジタル信号に変換する超広帯域RF受信回路や、超広帯域RF受信回路から出力されるデジタル信号に基づいて端末20と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
制御部21は、限定ではなく例として、位置算出用情報検出部29Bによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末20の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部21は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部28に記憶させるようにしてもよいし、そうしなくてもよい。
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
制御部21は、限定ではなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定ではなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
(2)サーバのHW構成
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20等の各種装置に送信する。また、通信I/F14は、端末20等の各種装置から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部12は、サーバ10に対する各種操作を入力する装置や、サーバ10で処理された処理結果を出力する装置等を含む。入出力部12は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。
出力部は、制御部11で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ(音出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
あくまでも一例であるが、入出力部12は、限定ではなく例として、表示部13を備える。
表示部13は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
時計部19は、サーバ10の内蔵時計であり、時刻情報(計時情報)を出力する。時計部19は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部19は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
(3)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
(3)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末20および/またはサーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
また、本開示の各実施形態のプログラムP(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
また、システムのプログラム(システムによって実行されるプログラム)という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをP1とすると、システムのプログラムP1は、端末に保存されたプログラムP2と、サーバに保存されたプログラムP3とで構成され、P2とP3とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムP2は、第1の処理を実行し、第1の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムP3は、受信した第1の処理をした結果に対して第2の処理を行い、第2の処理を行った結果を端末に送信するプログラムであってもよい。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをP1とすると、システムのプログラムP1は、端末に保存されたプログラムP2と、サーバに保存されたプログラムP3とで構成され、P2とP3とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムP2は、第1の処理を実行し、第1の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムP3は、受信した第1の処理をした結果に対して第2の処理を行い、第2の処理を行った結果を端末に送信するプログラムであってもよい。
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
また、本開示のプログラムPは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
<機能構成>
(1)サーバの機能構成
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたアプリケーション管理処理プログラム151に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部111を機能部として含む。
(1)サーバの機能構成
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたアプリケーション管理処理プログラム151に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部111を機能部として含む。
図1-3は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、制御部11によってアプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とが記憶される。
記憶部15には、限定ではなく例として、制御部11によってアプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とが記憶される。
アカウント登録データ153は、アプリケーション(限定ではなく例として、ライブ配信アプリケーション)のアカウントに関する登録データであり、そのデータ構成の一例を図1-4に示す。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
ユーザ名は、このアプリケーションを利用する端末20のアカウントの名称であり、限定ではなく例として、端末20のユーザがアプリケーションを利用する際に登録する名称が記憶される。
アプリケーションIDは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
その他登録情報には、限定ではなく例として、端末20を識別するための識別情報、端末20の電話番号(端末電話番号)、メールアドレス(端末メールアドレス)、アプリケーションにおける各種の認証に利用されるパスワード(ログインパスワード、認証パスワード等)等の認証情報といった各種の情報を含めるようにすることができる。
端末20を識別するための識別情報は、限定ではなく例として、端末ID(限定ではなく例として、IMEI(International Mobile Equipment Identity))とすることができる。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションIDや公式ユーザ用のアプリケーションIDとすることができる。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションIDや公式ユーザ用のアプリケーションIDとすることができる。
なお、アプリケーションIDに代えて「ユーザID」としてもよいし、しなくてもよい。
また、1つの端末20につき1つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」とすることができる。
また、1つの端末20につき1つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」とすることができる。
また、限定ではなく例として、1つのアプリケーションIDに、複数の端末IDを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、1つのアプリケーションIDを識別(ログイン)対象として、複数の端末20においてアプリケーションを並行して(並列に)起動できるようにしてもよいし、そのようにしなくてもよい。
また、アプリケーションID等の各種のIDに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。なお、アプリケーションID等のIDの情報を端末電話番号等の情報に代えず、アプリケーションID等のIDの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。なお、アプリケーションID等のIDの情報を端末電話番号等の情報に代えず、アプリケーションID等のIDの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
なお、以下の各種の実施例では、説明の簡明化のため、1つの端末20につき1つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」であるため、「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
また、この場合、上記のように「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」であるため、「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
アカウント登録可能なユーザは、限定ではなく例として、一般のユーザ(一般ユーザ)とすることができ、芸能人など、いわゆる公式アカウント(オフィシャルアカウント)によってプロのライバーとして活動することが想定されるユーザ(公式ユーザ)は除外することができる。
なお、公式ユーザもアカウント登録可能としてもよいが、限定ではなく例として、以下の実施例で説明するルールは、公式ユーザには適用しないようにしてもよい。
なお、公式ユーザもアカウント登録可能としてもよいが、限定ではなく例として、以下の実施例で説明するルールは、公式ユーザには適用しないようにしてもよい。
アカウント管理データベース155は、アカウント登録データ153に記憶されているアカウントに関する情報を管理するためのデータベースであり、そのデータ構成の一例を図1-5に示す。
アカウント管理データベース155には、アカウントごとのデータとして、アカウント管理データが記憶される。
アカウント管理データベース155には、アカウントごとのデータとして、アカウント管理データが記憶される。
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、ユーザ経験値と、ユーザレベルと、ライバー経験値と、ライバーレベルとが記憶される。
アプリケーションIDには、アカウント登録データ153に記憶されて登録されているアプリケーションIDが記憶される。
ユーザ経験値は、このアプリケーションIDのユーザにサーバ10によって付与されるユーザとしての経験値とすることができる。詳細は後述する。
ユーザレベルは、このアプリケーションIDのユーザのユーザ経験値に基づくレベルであり、限定ではなく例として、ユーザ経験値に基づいてサーバ10によって記憶・更新されるようにすることができる。詳細は後述する。
ライバー経験値は、限定ではなく例として、このアプリケーションIDのユーザにサーバ10によって付与されるライバーとしての経験値とすることができる。詳細は後述する。
ライバーレベルは、このアプリケーションIDのユーザのライバー経験値に基づくレベルであり、限定ではなく例として、ライバーとしてのランクであるライバーランクと、そのライバーランク内でのレベル(ランク内レベル)とを包括したものとすることができる。ライバーレベルは、限定ではなく例として、ライバー経験値に基づいてサーバ10によって記憶・更新されるようにすることができる。詳細は後述する。
ユーザ経験値とユーザレベルとは、ユーザに関する情報の一例とすることができる。
ライバー経験値とライバーレベルとは、ライバーに関する情報の一例とすることができる。
ライバー経験値とライバーレベルとは、ライバーに関する情報の一例とすることができる。
限定ではなく例として、ライブ配信アプリケーションにおいてライバーとして活動することを希望するユーザは、サーバ10に対して登録を行うようにすることができる。未登録のユーザについては、アカウント管理データのうちのライバー経験値とライバーレベルとをN/A(Not Applicapable)とすることができる。
上記のように、本実施例では、1つのアカウント(共通のアカウント)に対して、ユーザに関する情報と、ライバーに関する情報とが関連付けて記憶される。
また、視聴者としての活動もライバーとしての活動も、共通のアカウントを用いて行われる。
また、視聴者としての活動もライバーとしての活動も、共通のアカウントを用いて行われる。
(2)端末の機能構成
図1-6は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されたアプリケーション処理プログラム281に従ってアプリケーション処理を実行するためのアプリケーション処理部211を機能部として含む。
図1-6は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されたアプリケーション処理プログラム281に従ってアプリケーション処理を実行するためのアプリケーション処理部211を機能部として含む。
図1-7は、本実施例において端末20の記憶部28に記憶されるデータ等の一例を示す図である。
記憶部28には、限定ではなく例として、制御部21によってアプリケーション処理として実行されるアプリケーション処理プログラム281と、この端末20、またはこの端末20のユーザのアカウントに対応するアプリケーションID283とが記憶される。
記憶部28には、限定ではなく例として、制御部21によってアプリケーション処理として実行されるアプリケーション処理プログラム281と、この端末20、またはこの端末20のユーザのアカウントに対応するアプリケーションID283とが記憶される。
<表示画面>
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
以下では、タップ操作(単に「タップ」と言う場合がある。)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作とすることができる。
また、スクロール操作とは、限定ではなく例として、表示されている情報をスクロールさせるための操作(動作)とすることができる。限定ではなく例として、スクロール操作は、入力が指やタッチペン等である場合は「スワイプ操作」とし、入力がマウス等である場合は「ホイール操作」としてもよいものとする。
また、スクロール操作とは、限定ではなく例として、表示されている情報をスクロールさせるための操作(動作)とすることができる。限定ではなく例として、スクロール操作は、入力が指やタッチペン等である場合は「スワイプ操作」とし、入力がマウス等である場合は「ホイール操作」としてもよいものとする。
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
図1-8は、本実施例において端末20の表示部24に表示されるライブ配信アプリケーションの画面の一例を示す図である。ここでは、ユーザA.Aの端末20Aの表示部24に表示される画面を例示する。
図1-8左側は、ライブ配信アプリケーションのマイページ画面であり、画面最上部には、ライブ配信アプリケーションの名称が表示されている。その下には、ライブ配信アプリケーション内で現在表示されているページ等を示す領域(以下、「アプリ内位置表示領域」と称する。)が構成され、この画面はマイページ画面であるため、「マイページ」と表示されている。
その下には、ライブ配信アプリケーションにおける各種の情報が表示される領域が構成されている。
この領域の最上部には、ユーザA.Aのプロフィールに関するプロフィール領域が設けられており、限定ではなく例として、アカウント登録時、またはその後のどこかのタイミングで、ユーザA.Aによって設定された自身のベースとなる画像(以下、「ベース画像」と称する。)が、ユーザA.AのプロフィールアイコンPI1としてプロフィール領域に表示されている。また、プロフィール領域には、同様にユーザA.Aによって設定された背景画像としてのマイページ背景BG1が設定されている。
ベース画像は、プロフィールアイコンの他にも、自身を示す画像として種々の場面で用いられるようにすることができる。限定ではなく例として、コメント発信時に自分のコメントであることを認識させるためにコメントと関連付けて表示させたり、ユーザレベルアップ時やライバーレベルアップ時の表示等に用いられるようにすることができる。
なお、ベース画像やマイページ背景は、後からユーザが変更可能としてもよい。
また、マイページ背景は、限定ではなく例として、ライバー登録しなければ設定できないようにしてもよい。
また、マイページ背景は、限定ではなく例として、ライバー登録しなければ設定できないようにしてもよい。
限定ではなく例として、ユーザA.Aのアイコン画像と、ユーザA.Aがフォローしているユーザ(以下、適宜「フォロー」と称する。)の総数と、ユーザA.Aをフォローしているユーザ(以下、適宜「フォロワー」と称する。)の総数とが表示されている。
また、この領域の右上部には、ランキング情報を表示するためのアイコン画像であるランキングアイコンIC1が表示されている。ランキングについては、後の実施例で説明する。
また、その下には、ユーザA.Aのユーザレベル情報を表示するユーザレベル情報表示領域ULRと、ユーザA.Aのライバーレベル情報を表示するライバーレベル情報表示領域LLRとが、それぞれ枠によって構成されている。
以下では、ライバーレベルには、限定ではなく例として、ライバーランクと、そのライバーランク内でのレベルを示すランク内レベルとが含まれるものとする。
以下では、ライバーレベルには、限定ではなく例として、ライバーランクと、そのライバーランク内でのレベルを示すランク内レベルとが含まれるものとする。
この例では、ユーザレベル情報表示領域ULRには、ユーザレベルが50台であることを示すバッジ(星5つ)のアイコン画像とともに、ユーザA.Aのユーザレベルとして「ユーザ Lv59」が表示されている。
また、この例では、ライバーレベル情報表示領域LLRには、ライバーランク「レジェンド」に対応するキャラクタ(ウサギのキャラクタ)のアイコン画像とともに、ユーザA.Aのライバーレベルとして「レジェンド Lv10」が表示されている。
また、この例では、ライバーレベル情報表示領域LLRには、ライバーランク「レジェンド」に対応するキャラクタ(ウサギのキャラクタ)のアイコン画像とともに、ユーザA.Aのライバーレベルとして「レジェンド Lv10」が表示されている。
また、これらの領域の下には、ライブ配信を視聴するための情報が表示されている。
具体的には、ビデオカメラの画像および「配信をみる」の文字とともに、限定ではなく例として、配信中のライブに関する配信ライブ情報として、現在ライブ配信を行っているユーザのアイコン画像と、配信されているライブの名称とが、左右方向に一覧表示されている。限定ではなく例として、ユーザは、左右方向のスクロール操作を行うことで、画面内に表示されていない配信ライブ情報を表示させることが可能に構成されている。
具体的には、ビデオカメラの画像および「配信をみる」の文字とともに、限定ではなく例として、配信中のライブに関する配信ライブ情報として、現在ライブ配信を行っているユーザのアイコン画像と、配信されているライブの名称とが、左右方向に一覧表示されている。限定ではなく例として、ユーザは、左右方向のスクロール操作を行うことで、画面内に表示されていない配信ライブ情報を表示させることが可能に構成されている。
また、その下には、自分でライブ配信を行うための「配信する」ボタン、自分のライブ配信の履歴を確認するための「配信履歴」ボタン、自分のライブ配信の予定を確認するための「配信予定」ボタン、自分が視聴したライブの履歴を確認するための「視聴履歴」ボタン、といった複数の機能に対応して、各々の情報を表示するためのボタンが設けられている。
図1-8左側の画面において、限定ではなく例として、ライバーレベル情報表示領域LLRがタップされると、限定ではなく例として、図1-8中央の画面が表示される。
この画面は、ユーザA.Aのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示されている。
この画面は、ユーザA.Aのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示されている。
また、その下には、ライブステータスに関する情報が表示される領域が構成されている。
具体的には、ユーザレベル/ライバーランク(ライバーレベル)の表示を切り替えるための表示切替タブが最上部に表示され、この例では、ライバーランクが選択された状態が示されている。ライバーランクが選択されたことで、表示切替タブの「ライバーランク」の文字が強調表示(この例では、太字の文字で表示、下線付き)されている。
具体的には、ユーザレベル/ライバーランク(ライバーレベル)の表示を切り替えるための表示切替タブが最上部に表示され、この例では、ライバーランクが選択された状態が示されている。ライバーランクが選択されたことで、表示切替タブの「ライバーランク」の文字が強調表示(この例では、太字の文字で表示、下線付き)されている。
ライバーランクが選択されたことに基づき、その下には、ユーザA.Aのライバーレベルの詳細情報を表示するためのライバーレベル詳細情報表示領域LLDRが構成されている。ライバーレベル詳細情報表示領域LLDRには、限定ではなく例として、ライバーランク(またはライバーランク&ランク内レベル)に応じて変化するキャラクタのアイコン画像と、ライバーレベル(ライバーランク&ランク内レベル)と、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値(ライバーEXP)とが表示されている。
この例では、ユーザA.Aのライバーレベルとして、ライバーランク「レジェンド」、ランク内レベル「Lv10」が表示され、このライバーレベルに対応するキャラクタのアイコン画像としてウサギのキャラクタのアイコン画像が表示されている。
また、ライバーランクおよびランク内レベルの表示の下には、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値が、ゲージ(ライバー経験値ゲージLG1)および文字によって表示されている。この例では、次のランク内レベルにレベルアップするまでにライバー経験値が「2,987ライバーEXP」必要であることが表示されている。
なお、この例では、限定ではなく例として、ライバー経験値が「14,000」増加するごとに、ライバーランク「レジェンド」のランク内レベルがアップする。
なお、この例では、限定ではなく例として、ライバー経験値が「14,000」増加するごとに、ライバーランク「レジェンド」のランク内レベルがアップする。
ライバーレベル詳細情報表示領域LLDRの下には、ライバーランクが左右方向にカルーセル形式で表示されており、この例では、ライバーレベル詳細情報表示領域LLDRの中央真下の位置に現在のライバーランクが吹き出しで表示され、このライバーランクより1つ下のランクのライバーランクと、このライバーランクより1つ上のランクのライバーランクとが、それぞれ現在のライバーランクの吹き出しの左右に位置するように表示されている。
この例では、ユーザA.Aのライバーランクが「レジェンド」であるため、ライバーレベル詳細情報表示領域LLDRの下には、ウサギのキャラクタのアイコン画像および「レジェンドライバー」の文字を含む吹き出しが表示されている。また、その左には1つ下のライバーランクとして「スーパースター」が、その右には1つ上のライバーランクとして「神ライバー」がそれぞれ表示されている。
なお、1つ上のライバーランク「神ライバー」のアイコンには、まだこのライバーランクがアンロックされていないことを示す鍵アイコンが付与され、アイコンが反転表示されている。
なお、1つ上のライバーランク「神ライバー」のアイコンには、まだこのライバーランクがアンロックされていないことを示す鍵アイコンが付与され、アイコンが反転表示されている。
その下には、ライバー経験値の取得方法等を示すライバー経験値取得情報表示領域LERが構成されている。この例では、ライバー経験値の取得方法として、限定ではなく例として、ライブ配信の時間(時間の長さ)に関する「配信時間」、ライブ配信の視聴数に関する「視聴数」、ライブ配信中に視聴者から取得した応援ポイントに関する「応援ポイント」、ライブ配信中にライバーが視聴者に対してつんつん機能を利用してつんつんを行った回数に関する「つんつんの回数」が表示されている。
「つんつん機能」とは、限定ではなく例として、ライバーが自分のファンを増やすなどの目的で、ライブ配信中に視聴者を「つんつん」と突っつく演出を行うことで、視聴者とコミュニケーションをとる機能とすることができる。
具体的には、この例では、配信時間については「1分」あたり「1ライバー経験値(ライバーEXP)」を取得することが可能であり、視聴数については「視聴時間×視聴数×0.01」のライバー経験値を取得することが可能であり、応援ポイントについては「1PT」あたり「1ライバー経験値」を取得することが可能であり、つんつんの回数については「1回」あたり「1ライバー経験値」を取得することが可能であることが示されている。
また、その下には、ユーザA.Aの現在のライバーランクに応じて付与された特典に関する情報が表示されている。この例では、ライバーランク「レジェンド」に関連する特典として、限定ではなく例として、ランクバッジRB、フレームFM、マイページ背景BGの3つが付与されていることが示されている。これらは、ライバーレベルに基づき付与される特典としての「オブジェクト(アイテム)」と称することもできる。。
ランクバッジRBは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域のプロフィールアイコンと関連付けて表示させるなどして、自身のランクをアピールするために用いられるようにすることができる。
フレームFMは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域のプロフィールアイコンを囲うフレームとして設定することで、プロフィールアイコンを目立たせるために用いられるようにすることができる。
マイページ背景BGは、オブジェクトの一例であって、限定ではなく例として、マイページ画面のプロフィール領域の背景画像として設定することで、プロフィール領域を目立たせるために用いられるようにすることができる。
図1-8左側の画面においてユーザレベル情報表示領域ULRがタップされる、または、図1-8中央の画面において表示切替タブの「ユーザレベル」がタップされると、限定ではなく例として、図1-8右側の画面が表示される。
この画面は、図1-8中央の画面と同様に、ユーザA.Aのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示され、ユーザレベルが選択されたことで、表示切替タブの「ユーザレベル」が強調表示(この例では、太字の文字で表示、下線付き)されている。
この画面は、図1-8中央の画面と同様に、ユーザA.Aのライブステータスを示すライブステータス画面であり、アプリ内位置表示領域には「ライブステータス」の文字が表示され、ユーザレベルが選択されたことで、表示切替タブの「ユーザレベル」が強調表示(この例では、太字の文字で表示、下線付き)されている。
ユーザレベルが選択されたことに基づき、その下には、ユーザA.Aのユーザレベルの詳細情報を表示するためのユーザレベル詳細情報表示領域ULDRが構成されている。ユーザレベル詳細情報表示領域ULDRには、限定ではなく例として、後述する図1-14のテーブル等に示されるユーザレベル(達成ユーザ経験値)に応じたユーザ称号としてのバッジ(前述した「ランクバッジ」とは異なる。)のアイコン画像と、ユーザレベルと、次のユーザレベルにレベルアップするまでに必要とされるユーザ経験値(ユーザEXP)とが表示されている。ユーザ称号としてのバッジも、前述したランクバッジと同様に、特典としてのオブジェクトと捉えることもできる。
この例では、ユーザA.Aのユーザレベルとして「Lv59」が表示され、このユーザレベルに対応するバッジのアイコン画像として星の数が「5」(星5つ)のバッジのアイコン画像が表示されている。限定ではなく例として、ユーザレベルの十の桁の数字に対応する数の星を有するバッジのアイコン画像が構成されるようにすることができる。
なお、「100以上」のレベルを許容する場合は、限定ではなく例として、星の数を上二桁と同数とするなどすることができる。
なお、「100以上」のレベルを許容する場合は、限定ではなく例として、星の数を上二桁と同数とするなどすることができる。
また、ユーザレベルの下には、次のユーザレベルにレベルアップするまでに必要とされるユーザ経験値が、ゲージ(ユーザ経験値ゲージUG1)および文字によって表示されている。この例では、次のユーザレベルにレベルアップするまでにユーザ経験値が「67ユーザEXP」必要であることが表示されている。
ユーザレベル詳細情報表示領域ULDRの下には、ユーザレベルが左右方向にカルーセル形式で表示されており、この例では、ユーザレベル詳細情報表示領域ULDRの中央真下の位置に現在のユーザレベルが属するレベル帯(この例では「Lv50~」)が吹き出しで表示されている。また、この例では、このレベル帯よりも20レベル下のレベル帯(この例では「Lv30~」)と、このレベル帯よりも20レベル上のレベル帯(この例では「Lv70~」)とが、それぞれ現在のユーザレベルが属するレベル帯の吹き出しの左右に位置するように表示されている。
なお、1つ上のレベル帯のアイコンは、限定ではなく例として、ライバーランクの表示態様と同様にアンロックされていない態様で表示されている。
なお、1つ上のレベル帯のアイコンは、限定ではなく例として、ライバーランクの表示態様と同様にアンロックされていない態様で表示されている。
その下には、ユーザ経験値の取得方法を示すユーザ経験値取得情報表示領域UERが構成されている。この例では、ユーザ経験値の取得方法として、限定ではなく例として、ライブの視聴時間に関する「視聴時間」、ライブ中に自分が発信したコメントに関する「コメント数」、ライブで自分がライバーに送信した応援ポイントに関する「応援ポイント」、ライブで自分がライバーに送信したハートに関する「ハート」、ライブ配信アプリケーションへの自分のサインイン(またはログイン)に関する「サインイン」、自分が登録しているチャンネルに関する「チャンネル登録」が表示されている。
具体的には、この例では、視聴時間については「10分」あたり「1ユーザ経験値(ユーザEXP)」を取得することが可能であり、コメント数については「1回」あたり「1ユーザ経験値」を取得することが可能であり(ただし、1日100回までの制限付き)、応援ポイントについては「1応援ポイント」あたり「2ユーザ経験値」を取得することが可能であることが示されている。また、ハートについては「10個」あたり「1ユーザ経験値」を取得することが可能であり、サインインについては「1回」あたり「50ユーザ経験値」を取得することが可能であり(ただし、1日1回までの制限付き)、チャンネル登録については「1登録」あたり「1ユーザ経験値」を取得することが可能であることが示されている。
なお、ここでは、主として視聴者としての行動(視聴者行動)に基づいてユーザ経験値が付与される条件を図示しているが、詳細後述するように、配信者としての行動(配信者行動)に基づいてもユーザ経験値が付与されるようにすることができる。このため、これらの条件についてもユーザ経験値取得情報表示領域UERに表示してもよい。
図1-9は、図1-8の画面に示した端末20AのユーザA.Aが視聴者となってライブを視聴する場合の表示画面の一例を示す図である。
図1-9左側の画面は、図1-8左側のマイページ画面に対応しており、配信ライブ情報のうちユーザB.Bによって配信されている「BB’s kitchen」が視聴するライブとして選択された状態が示されている。この場合、限定ではなく例として、図1-9中央の配信ライブ画面が表示される。
図1-9左側の画面は、図1-8左側のマイページ画面に対応しており、配信ライブ情報のうちユーザB.Bによって配信されている「BB’s kitchen」が視聴するライブとして選択された状態が示されている。この場合、限定ではなく例として、図1-9中央の配信ライブ画面が表示される。
この配信ライブ画面には、画面最上部のライブ配信アプリケーションの名称が表示される領域の下の領域に、ユーザB.Bによって配信されているライブの映像が表示されている。具体的には、ライバーであるユーザB.Bの映像が映し出されている。
ライブの映像が表示される領域の左上部には、ライバーであるユーザB.Bの名称や、このライブの配信開始からの経過時間、このライブを視聴している視聴者数等の情報が表示されている。また、その下には、ユーザB.Bの現在のライバーレベル(ライバーランク&ランク内レベル)を示す領域が構成されており、この領域では、ライバー経験値がゲージ(ライバー経験値ゲージLG2)によって表示されるように構成されている。この例では、ユーザB.Bは、ライバーランクが「スター」であり、ランク内レベルが「Lv8」であることが示されている。
また、ライブの映像が表示される領域の左下部には、視聴者のユーザやライバーのユーザから発信されたコメントが表示されるコメント表示領域CDRが構成されている。このコメント表示領域CDRには、限定ではなく例として、発信されたコメントが、そのユーザのアイコン画像およびユーザ名と関連付けて表示されるように構成されている。
なお、コメントは、前述したコンテンツとしてよい。また、コンテンツの一態様をコメントとしてもよい。
コメント表示領域CDRは、限定ではなく例として、設定行数(限定ではなく例として、4行~5行程度)のコメントが表示される領域として構成することができる。この場合、限定ではなく例として、コメントが発信される毎に下からコメントが表示されて日時が古いコメントが上に押し上げられ、最上位の行に表示されているコメントは、非表示とされるようにすることができる。
また、ライブの映像が表示される領域の最下部には、自分が発信するコメントを入力するためのコメント入力領域CIRが設けられている。限定ではなく例として、コメント入力領域CIRがタップされると不図示のキーボードが画面下部から表示され、このキーボードによってコメントを入力可能とすることができる。そして、入力されたコメントで確定し、不図示のコメント送信ボタンがタップされることで、入力されたコメントがサーバ10を介して、ライバーの端末20と、各々の視聴者の端末20とに送信されるようにすることができる。
なお、コメント発信元の端末20が、コメント送信ボタンがタップされたことに基づいて、自己の端末20のユーザのコメントがコメント表示領域CDRの最新のコメントの下に位置するようにコメントを表示する制御を行ってもよい。
また、サーバ10が、コメント発信元の端末20に対しても、その端末20で入力されたコメントを送信するようにする。そして、コメント発信元の端末20が、サーバ10からコメントを受信したことに基づいて、自己の端末20のユーザのコメントがコメント表示領域CDRの最新のコメントの下に位置するようにコメントを表示する制御を行ってもよい。
また、サーバ10が、コメント発信元の端末20に対しても、その端末20で入力されたコメントを送信するようにする。そして、コメント発信元の端末20が、サーバ10からコメントを受信したことに基づいて、自己の端末20のユーザのコメントがコメント表示領域CDRの最新のコメントの下に位置するようにコメントを表示する制御を行ってもよい。
図1-9中央の画面では、自己の端末20AのユーザA.Aが発信した「もうすぐスターLv9だね」というコメントがコメント表示領域CDRに表示されている。限定ではなく例として、このコメントの発信に伴い、ユーザA.Aがユーザ経験値を取得し、これに伴い、ユーザA.Aのユーザレベルがアップしたとする。この場合、限定ではなく例として、図1-9右側の画面が表示される。
この画面において、コメント表示領域CDRには、ユーザA.Aを発信元とするコメントとして、ユーザA.Aのアイコン画像およびユーザ名と関連付けて「レベルが上がりました! おめでとう!」のテキストと、レベルアップ後のユーザレベル「ユーザLv60」のアイコンとを含むコメントCM1が表示されている。コメントCM1は、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ユーザレベルがアップしたと判定したサーバ10によって生成されて各々の端末20に送信されるコメントとすることができる。つまり、このコメントは、いわばシステムメッセージとしてのコメントとすることができる。
また、コメントCM1は、他のコメントとは異なる表示態様で表示されている。この例では、ユーザA.Aのアイコン画像およびユーザ名を含むコメント全体が枠で囲われて表示されている。このような表示を行うことで、ユーザ入力に基づく通常のコメントとは異なるコメントであることを各々の端末20のユーザに認識させることができる。
コメント表示領域CDRにおいて、コメントCM1の下には、このコメントを見た視聴者のユーザE.Eによって発信された、ユーザA.Aのレベルアップを祝福するコメント「A.Aさんおめでとう~」が表示されている。
また、コメント表示領域CDRの上方には、ユーザレベルがアップしたことを示すユーザレベルアップ情報UUIが表示されている。具体的には、この例では、「ユーザレベルアップ!」の文字と、ユーザレベルが「Lv59」から「Lv60」にアップしたことを示す情報とが表示されている。
なお、ユーザレベルアップ情報UUIは、ユーザレベルがアップしたユーザの端末20(この場合、端末20A)のみに表示されるようにしてもよいし、その他の端末20にも表示されるようにしてもよい。
なお、ユーザレベルアップ情報UUIは、ユーザレベルがアップしたユーザの端末20(この場合、端末20A)のみに表示されるようにしてもよいし、その他の端末20にも表示されるようにしてもよい。
図1-10は、図1-8の画面に示した端末20AのユーザA.Aがライバーとなってライブを配信する場合の表示画面の一例を示す図である。
図1-10左側の画面は、図1-8左側のマイページ画面に対応しており、画面下部の「配信する」ボタンがタップされた状態が示されている。この場合、限定ではなく例として、図1-10中央の配信ライブ画面が表示される。
図1-10左側の画面は、図1-8左側のマイページ画面に対応しており、画面下部の「配信する」ボタンがタップされた状態が示されている。この場合、限定ではなく例として、図1-10中央の配信ライブ画面が表示される。
この配信ライブ画面には、画面最上部のライブ配信アプリケーションの名称が表示される領域の下の領域に、ユーザA.Aが配信するライブの映像が表示されている。具体的には、ライバーであるユーザA.Aの映像が映し出されている。ユーザA.Aのライバーレベルとして、ライバーランク「レジェンド」、ランク内レベル「Lv10」が表示されている。
また、ライブの映像が表示される領域の左上部には、ライバーであるユーザA.Aの名称等の情報に加えて、ライブ配信中の端末であることを示す、カメラアイコン内に「Live」の文字で示されるライブアイコン情報が表示されている。
他の構成は、図1-9中央、図1-10右側に示した画面と同様である。
また、ライブの映像が表示される領域の左上部には、ライバーであるユーザA.Aの名称等の情報に加えて、ライブ配信中の端末であることを示す、カメラアイコン内に「Live」の文字で示されるライブアイコン情報が表示されている。
他の構成は、図1-9中央、図1-10右側に示した画面と同様である。
ユーザA.Aによるライブ配信に伴い、ユーザA.Aがライバー経験値を取得し、これに伴い、ユーザA.Aのランク内レベルがアップし、ランク内レベルが最大レベルに達したことで、ライバーランクがランクアップしたとする。この場合、限定ではなく例として、図1-10右側の画面が表示される。
この画面において、コメント表示領域CDRには、ユーザA.Aを発信元とするコメントとして、ユーザA.Aのアイコン画像およびユーザ名と関連付けて「ランクが上がりました! おめでとう!」のテキストと、ランクアップ後のライバーランク「神」およびランク内レベル「Lv1」を示すアイコンとを含むコメントCM2が表示されている。コメントCM2は、前述したコメントCM1と同様に、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ライバーランクやランク内レベルがアップしたと判定したサーバ10によって生成されて各々の端末20に送信されるコメントとすることができる。
また、コメントCM2は、他のコメントとは異なる表示態様で表示されている。この例では、ユーザA.Aのアイコン画像およびユーザ名を含むコメント全体が枠で囲われて表示されている。このような表示を行うことで、ユーザ入力に基づく通常のコメントとは異なるコメントであることを各々の端末20のユーザに認識させることができる。
コメント表示領域CDRにおいて、コメントCM2の下には、このコメントを見た視聴者のユーザF.Fや視聴者のユーザE.Eによって発信された、ユーザA.Aのランクアップを祝福するコメント「神降臨!!!!!」や「A.Aさんすごい~~~」が表示されている。
また、その下には、ライバーであるユーザA.Aによってコメント入力領域CIRに入力されて送信された、お礼を述べるコメント「みんな応援ありがと~」が表示されている。
また、その下には、ライバーであるユーザA.Aによってコメント入力領域CIRに入力されて送信された、お礼を述べるコメント「みんな応援ありがと~」が表示されている。
また、コメント表示領域CDRの上には、ライバーレベルがアップしたことを示すライバーレベルアップ情報LUIが表示されている。具体的には、この例では、「ライバーランクアップ!」の文字と、ライバーランクが「レジェンド(Lv10)」から「神(Lv1)」にアップしたことを示すキャラクタのアイコン画像および文字とを含む情報が表示されている。この情報は、ライバーランクがアップしたことを示す情報とも言えるため、ライバーランクアップ情報と称してもよい。
また、ライバーレベルアップ情報LUIは、限定ではなく例として、図1-9右側の画面に示したユーザレベルアップ情報UUIよりも派手な態様で表示されている。
なお、ライバーレベルアップ情報LUIは、ライバーランクがアップしたユーザの端末20(この場合、端末20A)にのみ表示されるようにしてもよいし、その他の端末20にも表示されるようにしてもよい。
なお、ライバーレベルアップ情報LUIは、ライバーランクがアップしたユーザの端末20(この場合、端末20A)にのみ表示されるようにしてもよいし、その他の端末20にも表示されるようにしてもよい。
図1-11は、本実施例において端末20Aの表示部24に表示されるライブ配信アプリケーションの画面の一例を示す図であり、図1-10のライブ配信が終了した場合に表示される画面の一例を示す図である。
図1-11左側,中央には、ライブ配信が終了したことに基づき、ライブ配信をねぎらうメッセージ等とともに、このライブ配信でユーザA.Aが取得したライバー経験値に関する情報(この例では「配信お疲れさまでした!」のメッセージ)が表示されている。
図1-11左側,中央には、ライブ配信が終了したことに基づき、ライブ配信をねぎらうメッセージ等とともに、このライブ配信でユーザA.Aが取得したライバー経験値に関する情報(この例では「配信お疲れさまでした!」のメッセージ)が表示されている。
また、その下には、ライバー経験値ゲージLG1等を含む情報が表示されている。図1-11左側→図1-11中央の流れで、ライバー経験値ゲージLG1が、取得したライバー経験値分だけ増加し、ユーザA.Aのライバーレベルが「レジェンド(Lv10)」から「神(Lv1)」にレベルアップしたことが示される。また、図1-11中央の画面において、ライバー経験値ゲージLG1等を含む情報の下には、ライバーレベルがアップしたことに基づきユーザA.Aが取得した特典の内容、この例では、「獲得アイテム:ライバーランク「神」のうちのランク内レベル「Lv1」となったことによる特典(オブジェクト)としてのランクバッジRB1」が表示されている。
また、その下には、今回のライブ配信の結果(配信結果)に関する情報として、限定ではなく例として、ライブの配信時間「配信時間」と、ライブの視聴数「視聴者」と、新規のフォロワー数「新規フォロワー」とが表示されている。
さらに、その下には、ライブの視聴者のユーザに対してお礼のメッセージを送信するための「お礼メッセージ」ボタンと、ライブをもう一度配信するための「もう一度配信」ボタンとが表示されている。
図1-11右側は、ライブ配信アプリケーションのマイページ画面であり、図1-11中央の画面が表示された後、マイページに戻った場合に表示される画面の一例を示す図である。
この画面の構成は、図1-8左側の画面と同様であるが、表示内容が一部異なっている。
この画面の構成は、図1-8左側の画面と同様であるが、表示内容が一部異なっている。
具体的には、図1-11中央の画面に示したように、ランクバッジRB1を獲得したことに基づき、プロフィール領域のプロフィールアイコンと関連付けてランクバッジRB1が表示されている。
また、図1-11中央の画面に示したように、ライブ配信によって新規フォロワー数が「102」増加したため、図1-8左側の画面におけるフォロワー数「2,831」に「102」が加算され、「2,933」と表示されている。
また、図1-11中央の画面に示したように、ライブ配信によって新規フォロワー数が「102」増加したため、図1-8左側の画面におけるフォロワー数「2,831」に「102」が加算され、「2,933」と表示されている。
また、ライブ配信によってユーザレベルが「Lv60」にアップしたことに伴い、ユーザレベル情報表示領域ULRには、レベルが60台であることを示すバッジ(星6つ)のアイコン画像とともに、ユーザA.Aのユーザレベルとして「ユーザ Lv60」が表示されている。
また、ライブ配信によってライバーレベルが「神Lv1」にアップしたことに伴い、ライバーレベル情報表示領域LLRには、ライバーランク「神」に対応するキャラクタ(くまのキャラクタ)のアイコン画像とともに、ユーザA.Aのライバーレベルとして「神 Lv1」が表示されている。
また、ライブ配信によってライバーレベルが「神Lv1」にアップしたことに伴い、ライバーレベル情報表示領域LLRには、ライバーランク「神」に対応するキャラクタ(くまのキャラクタ)のアイコン画像とともに、ユーザA.Aのライバーレベルとして「神 Lv1」が表示されている。
<処理>
図1-12は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理では、配信されるライブを視聴する視聴者のユーザの一人であるユーザA.Aの端末20Aの制御部21が実行する処理を左側に、サーバ10の制御部11が実行する処理を右側にそれぞれ示している。
図1-12は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理では、配信されるライブを視聴する視聴者のユーザの一人であるユーザA.Aの端末20Aの制御部21が実行する処理を左側に、サーバ10の制御部11が実行する処理を右側にそれぞれ示している。
ここでは、ユーザB.Bがライバーとなってライブ配信を行う場合を例示する。
なお、ユーザA.A以外で視聴者となるユーザの端末20の制御部21が実行する処理は、端末20Aと同様であるため、図示を省略する。
なお、ユーザA.A以外で視聴者となるユーザの端末20の制御部21が実行する処理は、端末20Aと同様であるため、図示を省略する。
なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略(削除)してもよい。
本明細書で説明する各種の処理について同様である。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略(削除)してもよい。
本明細書で説明する各種の処理について同様である。
最初に、端末20Aの制御部21は、入出力部23を介してユーザA.Aによってライブを視聴する要求がなされたか否か等に基づいて、ライブを視聴するか否かを判定する(A110)。ライブを視聴しないと判定したならば(A110:NO):端末20Aの制御部21は、A140に処理を進める。
一方、ライブを視聴すると判定したならば(A110:YES)、端末20Aの制御部21は、限定ではなく例として、自己の端末20のアプリケーションID283等を含むライブ視聴要求情報を、通信I/F22によってサーバ10に送信する(A120)。
サーバ10の制御部11は、通信I/F14によって端末20Aからライブ視聴要求情報を受信したか否かを判定し(S110)、受信しなかったと判定したならば(S110:NO)、S130に処理を進める。
一方、ライブ視聴要求情報を受信したと判定したならば(S110:YES)、サーバ10の制御部11は、端末20Aとの間で、ライブ視聴処理を実行する(A130,S120)。
図1-13は、ライブ視聴処理の流れの一例を示すフローチャートである。図の見方は、図1-12と同様である。
サーバ10の制御部11は、通信I/F14によってライバーであるユーザB.Bの端末20Bからライブ配信情報を受信したことに基づいて、そのライブ配信情報に基づくライブ情報を、通信I/F14によって端末20Aに送信する(S1210)。
サーバ10の制御部11は、通信I/F14によってライバーであるユーザB.Bの端末20Bからライブ配信情報を受信したことに基づいて、そのライブ配信情報に基づくライブ情報を、通信I/F14によって端末20Aに送信する(S1210)。
通信I/F22によってサーバ10からライブ情報を受信すると、端末20Aの制御部21は、受信したライブ情報を表示部24に表示させる(A1310)。
S1210の後、サーバ10の制御部11は、ユーザ経験値算出処理を行う(S1220)。具体的には、限定ではなく例として、図1-8右側の画面例に示したような以下の条件のうちの少なくともいずれか1つの条件(視聴者行動、視聴実績)と、各々に設定されたユーザ経験値の付与値(単位付与値)とに基づいて、ユーザA.Aのユーザ経験値を算出するようにすることができる。
(A1)ライブ視聴中:自分のライブ視聴時間
(A2)ライブ視聴中:自分が発信したコメント数
(A3)ライブ視聴中: 自分からライバーへの応援ポイント(応援アイテム)の送信
(A4)ライブ視聴中:自分からライバーへのハートの送信
(A5)ライブ視聴中:ライバーのフォロー(チャンネル登録)
(A6)ライブ視聴中以外:ライブ配信アプリケーションのサインイン(またはログイン)
(A7)ライブ視聴中以外:自分のチャンネル登録数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
(A1)ライブ視聴中:自分のライブ視聴時間
(A2)ライブ視聴中:自分が発信したコメント数
(A3)ライブ視聴中: 自分からライバーへの応援ポイント(応援アイテム)の送信
(A4)ライブ視聴中:自分からライバーへのハートの送信
(A5)ライブ視聴中:ライバーのフォロー(チャンネル登録)
(A6)ライブ視聴中以外:ライブ配信アプリケーションのサインイン(またはログイン)
(A7)ライブ視聴中以外:自分のチャンネル登録数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
限定ではなく例として、応援ポイントとハートの少なくともいずれか一方は「課金アイテム」とすることができる。そして、限定ではなく例として、ライブ配信サービス事業者がユーザに金銭の負担を負わせ、ライブ配信サービス事業者に対して金銭の支払いが行われることで、ユーザが応援ポイントやハートをライバーに送信可能とすることができる。
限定ではなく例として、応援ポイントの送信やハートの送信、チャンネル登録等は、限定ではなく例として、ライブ動画に関する評価と捉えることもできる。
そして、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザ経験値を更新する。
次いで、サーバ10の制御部11は、ユーザA.Aのユーザレベルをアップさせるか否かに関する判定(以下、「ユーザレベルアップ判定」と称する。)を行う(S1230)。
図1-14は、ユーザレベルと、ユーザレベルアップ判定の方法とを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ユーザレベルと、達成ユーザ経験値と、ユーザ称号とが関連付けて記憶されている。
このテーブルには、限定ではなく例として、ユーザレベルと、達成ユーザ経験値と、ユーザ称号とが関連付けて記憶されている。
ユーザレベルは、レベルが低い順に「LV1」、「LV2」、「LV3」、・・・、といった複数のレベルに細分化されており、各々のユーザレベルと関連付けて、そのユーザレベルにレベルアップするために必要とされるユーザ経験値が「達成ユーザ経験値」として設定されている。
また、この例では、ユーザレベルのうちの一部のレベルについて、そのユーザレベルに対応する称号(以下、「ユーザ称号」と称する。)が設定されている。具体的には、限定ではなく例として、ユーザレベル「LV3」にはユーザ称号「ブロンズリスナーバッジ」が、ユーザレベル「LV7」にはユーザ称号「ブロンズリスナーフレーム」が、ユーザレベル「LV10」にはユーザ称号「シルバーリスナーバッジ」がそれぞれ設定されている。
S1230において、サーバ10の制御部11は、ユーザA.Aの最新のユーザ経験値と、図1-14のテーブルの達成ユーザ経験値とに基づいて、ユーザA.Aのユーザレベルを現在のユーザレベルからレベルアップさせるか否かを判定する(S1230)。つまり、本実施例では、ライブ配信中に、そのライブの視聴者にユーザ経験値が付与され、ユーザレベルが向上する場合がある。
レベルアップさせないと判定したならば(S1230:NO)、サーバ10の制御部11は、S1250に処理を進める。
一方、レベルアップさせると判定したならば(S1230:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ10の制御部11は、ユーザレベルがアップしたことに関する情報(限定ではなく例として、ユーザレベルがアップした旨、ユーザレベル、ユーザ称号等)をユーザレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1240)。
一方、レベルアップさせると判定したならば(S1230:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ10の制御部11は、ユーザレベルがアップしたことに関する情報(限定ではなく例として、ユーザレベルがアップした旨、ユーザレベル、ユーザ称号等)をユーザレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1240)。
なお、サーバ10の制御部11は、ユーザレベルアップ情報を各々の視聴者の端末20に対して送信するようにしてもよいし、そうしなくてもよい。
また、ユーザレベルアップ情報として、配信中のコメント内に表示させるためのユーザレベルアップコメント情報を各々の視聴者・配信者の端末20に対して送信し、ユーザレベルアップ情報は端末20Aのみに送信するようにしてもよい。
また、ユーザレベルアップ情報として、配信中のコメント内に表示させるためのユーザレベルアップコメント情報を各々の視聴者・配信者の端末20に対して送信し、ユーザレベルアップ情報は端末20Aのみに送信するようにしてもよい。
A1310の後、端末20Aの制御部21は、通信I/F22によってサーバ10からユーザレベルアップ情報を受信したか否かを判定し(A1320)、受信しなかったと判定したならば(A1320:NO)、A1340に処理を進める。
一方、ユーザレベルアップ情報を受信したと判定したならば(A1320:YES)、端末20Aの制御部21は、受信したユーザレベルアップ情報を表示部24に表示させる(A1330)。
S1240の後、サーバ10の制御部11は、通信I/F14によって端末20Bからライブ配信終了要求情報を受信したか否かを判定し(S1250)、受信しなかったと判定したならば(S1250:NO)、S1210に処理を戻す。
一方、受信したと判定したならば(S1250:YES)、サーバ10の制御部11は、ライブ配信終了情報を通信I/F14によって端末20Aに送信する(S1260)。
そして、サーバ10の制御部11は、ライブ視聴処理を終了する。
一方、受信したと判定したならば(S1250:YES)、サーバ10の制御部11は、ライブ配信終了情報を通信I/F14によって端末20Aに送信する(S1260)。
そして、サーバ10の制御部11は、ライブ視聴処理を終了する。
A1330の後、端末20Aの制御部21は、通信I/F22によってサーバ10からライブ配信終了情報を受信したか否かを判定し(A1340)、受信しなかったと判定したならば(S1340:NO)、A1310に処理を戻す。
一方、受信したと判定したならば(A1340:YES)、端末20Aの制御部21は、受信したライブ配信終了情報を表示部24に表示させる(A1350)。そして、端末20Aの制御部21は、ライブ視聴処理を終了する。
一方、受信したと判定したならば(A1340:YES)、端末20Aの制御部21は、受信したライブ配信終了情報を表示部24に表示させる(A1350)。そして、端末20Aの制御部21は、ライブ視聴処理を終了する。
なお、A1350において、端末20Aの制御部21が、限定ではなく例として、視聴したライブに関して自分が取得したユーザ経験値やユーザレベルに関する情報を表示してもよい。限定ではなく例として、図1-11に示したライバーの端末20の表示部24に表示されるライブ配信終了情報に倣って、ユーザA.Aがライブの視聴によって取得したユーザ経験値やユーザレベルの変化等を表示してもよい。
図1-12に戻り、ライブ視聴処理(A130)を行った後、端末20Aの制御部21は、入出力部23を介してユーザA.Aによってライブ配信を行うための入力がなされたか否か等に基づいて、ライブ配信を行うか否かを判定する(A140)。ライブ配信を行わないと判定したならば(A140:NO)、端末20Aの制御部21は、A170に処理を進める。
一方、ライブ配信を行うと判定したならば(A140:YES)、端末20Aの制御部21は、ライブ配信要求情報を、通信I/F22によってサーバ10に送信する(A150)。
ライブ視聴処理(S120)を行った後、サーバ10の制御部11は、通信I/F14によって端末20Aからライブ配信要求情報を受信したか否かを判定し(S130)、受信しなかったと判定したならば(S130:NO)、S150に処理を進める。
一方、ライブ配信要求情報を受信したと判定したならば(S130:YES)、サーバ10の制御部11は、端末20Aとの間で、ライブ配信処理を行う(A160,S140)。
図1-15は、ライブ配信処理の流れの一例を示すフローチャートである。図の見方は、図1-12と同様である。
端末20Aの制御部21は、ライブ配信情報を、通信I/F22によってサーバ10に送信する(A1610)。
端末20Aの制御部21は、ライブ配信情報を、通信I/F22によってサーバ10に送信する(A1610)。
通信I/F14によって端末20Aからライブ配信情報を受信すると、サーバ10の制御部11は、受信したライブ配信情報に基づくライブ情報を、通信I/F14によって端末20Aと、各々の視聴者の端末20とに送信する(S1410)。
通信I/F22によってサーバ10からライブ情報を受信すると、端末20Aの制御部21は、受信したライブ情報を表示部24に表示させる(A1620)。
なお、図示は省略しているが、各々の視聴者の端末20は、受信したライブ情報を表示部24に表示させる。
なお、図示は省略しているが、各々の視聴者の端末20は、受信したライブ情報を表示部24に表示させる。
S1420の後、サーバ10の制御部11は、ユーザ経験値算出処理を行う(S1420)。
ここでは、ユーザA.Aがライバーとなってライブ配信を行っているが、限定ではなく例として、ライバー経験値がユーザA.Aに付与されるようにするばかりでなく、ユーザ経験値もユーザA.Aに付与されるようにすることができる。
ここでは、ユーザA.Aがライバーとなってライブ配信を行っているが、限定ではなく例として、ライバー経験値がユーザA.Aに付与されるようにするばかりでなく、ユーザ経験値もユーザA.Aに付与されるようにすることができる。
この場合、限定ではなく例として、少なくとも以下のいずれか1つの条件(配信実績、配信者行動)と、各々に設定されたユーザ経験値の付与値(単位付与値)とに基づいて、ユーザA.Aのユーザ経験値を算出するようにすることができる。
(B1)ライブ配信中:自分が配信するライブ配信時間
(B2)ライブ配信中:自分が受け取った応援ポイント数
(B3)ライブ配信中:自分が受け取ったハート数
(B4)ライブ配信中:自分のライブの視聴数
(B5)ライブ配信中:自分に対するコメント数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
(B1)ライブ配信中:自分が配信するライブ配信時間
(B2)ライブ配信中:自分が受け取った応援ポイント数
(B3)ライブ配信中:自分が受け取ったハート数
(B4)ライブ配信中:自分のライブの視聴数
(B5)ライブ配信中:自分に対するコメント数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。
あくまでも1つの例であるが、上記の(B1)~(B5)等の条件に基づくユーザ経験値の付与値は、限定ではなく例として、前述した(A1)~(A7)等の条件に基づくユーザ経験値の付与値よりも相対的に小さくなるように設定しておくことができる。つまり、ユーザ経験値(ユーザレベル)は、ユーザが視聴者行動を行う方が配信者行動を行うよりも上がり易くなるようにすることができる(視聴者行動の方が配信者行動よりも強い)。
なお、限定ではなく例として、後述するライバー経験値算出処理で用いられる条件のうち、上記の条件に含まれない条件を適用してもよい。また、後述するライバー経験値算出処理で用いられる条件と全く同じ条件を適用してもよい。
また、限定ではなく例として、(B1)ライブ配信時間に基づいて付与するユーザ経験値と、前述した(A1)ライブ視聴時間に基づいて付与するユーザ経験値との関係について、限定ではなく例として、同じ時間(時間の長さ)に対して同じ値のユーザ経験値を付与するようにしてもよい。また、同じ時間に対してライブ配信時間の方がライブ視聴時間よりも大きいユーザ経験値を付与するようにしてもよい。つまり、限定ではなく例として、端末のユーザがライブ動画の配信を所定時間行った場合に、ライブ動画の視聴を所定時間行う場合と少なくとも同じ第1ポイントがユーザに付与されるようにしてもよい。
なお、これとは異なり、同じ時間に対してライブ視聴時間の方がライブ配信時間よりも大きいユーザ経験値を付与するようにしてもよい。
そして、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザ経験値を更新する。
次いで、サーバ10の制御部11は、ユーザA.Aのユーザレベルアップ判定を行う(S1430)。具体的には、ユーザA.Aの最新のユーザ経験値と、図1-14のテーブルの達成ユーザ経験値とに基づいて、ユーザA.Aのユーザレベルを現在のユーザレベルからレベルアップさせるか否かを判定する。つまり、本実施例では、ライブ配信中に、そのライブの配信者にユーザ経験値が付与され、ユーザレベルが向上する場合がある。
レベルアップさせないと判定したならば(S1430:NO)、サーバ10の制御部11は、S1450に処理を進める。
一方、レベルアップさせると判定したならば(S1430:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ10の制御部11は、ユーザレベルがアップしたことに関する情報をユーザレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1440)。
一方、レベルアップさせると判定したならば(S1430:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのユーザレベルを更新する。そして、サーバ10の制御部11は、ユーザレベルがアップしたことに関する情報をユーザレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1440)。
A1620の後、端末20Aの制御部21は、通信I/F22によってサーバ10からユーザレベルアップ情報を受信したか否かを判定し(A1630)、受信したと判定したならば(A1630:YES)、受信したユーザレベルアップ情報を表示部24に表示させる(A1640)。
S1440の後、サーバ10の制御部11は、ライバー経験値算出処理を行う(S1450)。具体的には、限定ではなく例として、図1-8中央の画面例に示したような以下の条件のうちの少なくともいずれか1つの条件(配信実績、配信者行動)と、各々に設定されたライバー経験値の付与値(単位付与値)とに基づいて、ユーザA.Aのライバー経験値を算出する。
(C1)ライブ配信中:自分のライブ配信時間
(C2)ライブ配信中:自分のライブの視聴数
(C3)ライブ配信中:自分が受け取った応援ポイント数
(C4)ライブ配信中:自分が行ったつんつんの回数
(C1)ライブ配信中:自分のライブ配信時間
(C2)ライブ配信中:自分のライブの視聴数
(C3)ライブ配信中:自分が受け取った応援ポイント数
(C4)ライブ配信中:自分が行ったつんつんの回数
ただし、これらの条件に限定されるわけではなく、他の条件を含めてもよい。限定ではなく例として、以下の条件等を含めてもよい。
(C5)ライブ配信中:自分へのコメント数
(C6)ライブ配信中:自分が受け取ったハート数
(C5)ライブ配信中:自分へのコメント数
(C6)ライブ配信中:自分が受け取ったハート数
そして、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのライバー経験値を更新する。
次いで、サーバ10の制御部11は、ユーザA.Aのライバーランクやランク内レベル(以下、包括的に「ライバーレベル」と称する。)をアップさせるか否かに関する判定(以下、「ライバーレベルアップ判定」と称する。)を行う(S1460)。
次いで、サーバ10の制御部11は、ユーザA.Aのライバーランクやランク内レベル(以下、包括的に「ライバーレベル」と称する。)をアップさせるか否かに関する判定(以下、「ライバーレベルアップ判定」と称する。)を行う(S1460)。
図1-16は、ライバーレベルと、ライバーレベルアップ判定の方法とを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ライバーランクと、達成ライバー経験値と、ランク内レベルとが関連付けて記憶されている。
このテーブルには、限定ではなく例として、ライバーランクと、達成ライバー経験値と、ランク内レベルとが関連付けて記憶されている。
ライバーランクは、ランクが低い順に、限定ではなく例として、「ルーキー」、「レギュラー」、「スター」、「スーパースター」、「レジェンド」、「神」といった複数のランクに細分化されており、各々のライバーランクと関連付けて、そのライバーランクに対応するライバー経験値の数値範囲が「達成ライバー経験値」として設定されている。最上位のライバーランクは「神」である。
達成ライバー経験値の数値範囲の下限の値が、そのライバーランクとなるために必要とされるライバー経験値を示し、達成ライバー経験値の数値範囲の上限の値が、そのライバーランク内での最大のライバー経験値を示している。
また、この例では、各々のライバーランクには、そのライバーランク内のレベルが設定されている。具体的には、限定ではなく例として、ライバーランクのうちの「ルーキー」、「レギュラー」、「スター」、「スーパースター」、「レジェンド」については、ランク内レベルの下限として「1」が、ランク内レベルの上限として「10」がそれぞれ設定され、ランク内レベルが「1~10」の数値範囲のいずれかとなるように設定されている。
のいずれかの値が設定されるように構成されている。
のいずれかの値が設定されるように構成されている。
最上位のライバーランク「神」よりも下位のライバーランクについては、限定ではなく例として、対応する達成ライバー経験値の欄の数値範囲が示す幅の値を「10」で除算した値のライバー経験値ごとに、ランク内レベルがアップするようにすることができる。
また、最上位のライバーランク「神」については、限定ではなく例として、設定値(限定ではなく例として、「20,000」ライバー経験値)ごとに、ランク内レベルが「1」アップするようにすることができる。
また、最上位のライバーランク「神」については、限定ではなく例として、設定値(限定ではなく例として、「20,000」ライバー経験値)ごとに、ランク内レベルが「1」アップするようにすることができる。
なお、ライバーランクやランク内レベルと関連付けて、前述したライバーに付与する特典をこのテーブルに設定しておき、サーバ10の制御部11が、これに基づいて、ライバーに特典を付与するようにしてもよい。
S1460において、サーバ10の制御部11は、ユーザA.Aの最新のライバー経験値と、図1-16のテーブルの達成ライバー経験値とに基づいて、ユーザA.Aのライバーランクやランク内レベルを現在のライバーランクやランク内レベルからレベルアップさせるか否かを判定する(S1460)。つまり、本実施例では、ライブ配信中に、そのライブの配信者にライバー経験値が付与され、ライバーレベルが向上する場合がある。
レベルアップさせないと判定したならば(S1460:NO)、サーバ10の制御部11は、S1480に処理を進める。
一方、レベルアップさせると判定したならば(S1460:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのライバーランク等を更新する。そして、サーバ10の制御部11は、ライバーレベルがアップしたことに関する情報(限定ではなく例として、ライバーランクがアップした旨、ランク内レベルがアップした旨、ライバーランク、ランク内レベル等)をライバーレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1470)。
一方、レベルアップさせると判定したならば(S1460:YES)、サーバ10の制御部11は、アカウント管理データベース155のうち、ユーザA.AのアプリケーションIDに対応するアカウント管理データのライバーランク等を更新する。そして、サーバ10の制御部11は、ライバーレベルがアップしたことに関する情報(限定ではなく例として、ライバーランクがアップした旨、ランク内レベルがアップした旨、ライバーランク、ランク内レベル等)をライバーレベルアップ情報として、通信I/F14によって端末20Aに送信する(S1470)。
なお、サーバ10の制御部11は、ライバーレベルアップ情報を各々の視聴者の端末20に対しても送信するようにしてもよいし、そうしなくてもよい。
また、ライバーレベルアップ情報として、配信中のコメント内に表示させるためのライバーレベルアップコメント情報を各々の視聴者・配信者の端末20に対して送信し、ライバーレベルアップ情報は端末20Aのみに送信するようにしてもよい。
また、ライバーレベルアップ情報として、配信中のコメント内に表示させるためのライバーレベルアップコメント情報を各々の視聴者・配信者の端末20に対して送信し、ライバーレベルアップ情報は端末20Aのみに送信するようにしてもよい。
A1640の後、端末20Aの制御部21は、通信I/F22によってサーバ10からライバーレベルアップ情報を受信したか否かを判定し(A1650)、受信しなかったと判定したならば(A1650:NO)、A1670に処理を進める。
一方、ライバーレベルアップ情報を受信したと判定したならば(A1650:YES)、端末20Aの制御部21は、受信したライバーレベルアップ情報を表示部24に表示させる(A1660)。
A1660の後、端末20Aの制御部21は、入出力部23を介したユーザ入力に基づいて、ライブ配信を終了するか否かを判定し(A1670)、終了しないと判定したならば(A1670:NO)、A1610に処理を戻す。
一方、ライブ配信を終了すると判定したならば(A1670:YES)、端末20Aの制御部21は、ライブ配信終了要求情報を、通信I/F22によってサーバ10に送信する(A1680)。
一方、ライブ配信を終了すると判定したならば(A1670:YES)、端末20Aの制御部21は、ライブ配信終了要求情報を、通信I/F22によってサーバ10に送信する(A1680)。
S1470の後、サーバ10の制御部11は、通信I/F14によって端末20Aからライブ配信終了要求情報を受信したか否かを判定し(S1480)、受信しなかったと判定したならば(S1480:NO)、S1410に処理を戻す。
一方、受信したと判定したならば(S1480;YES)、サーバ10の制御部11は、ライブ配信終了情報を、通信I/F14によって端末20Aに送信する(S1490)。
そして、サーバ10の制御部11は、ライブ配信処理を終了する。
一方、受信したと判定したならば(S1480;YES)、サーバ10の制御部11は、ライブ配信終了情報を、通信I/F14によって端末20Aに送信する(S1490)。
そして、サーバ10の制御部11は、ライブ配信処理を終了する。
A1680の後、通信I/F22によってサーバ10からライブ配信終了情報を受信すると、端末20Aの制御部21は、受信したライブ終了情報を表示部24に表示させる(A1690)。具体的には、限定ではなく例として、図1-11に示したような画面を表示部24に表示させる。
そして、端末20Aの制御部21は、ライブ配信処理を終了する。
そして、端末20Aの制御部21は、ライブ配信処理を終了する。
図1-12に戻り、ライブ配信処理(A160)を行った後、端末20Aの制御部21は、処理を終了するか否かを判定し(A170)、終了しないと判定したならば(A170:NO)、A110に処理を戻す。
一方、処理を終了すると判定したならば(A170:YES)、端末20Aの制御部21は、処理を終了する。
一方、処理を終了すると判定したならば(A170:YES)、端末20Aの制御部21は、処理を終了する。
同様に、ライブ配信処理(S140)を行った後、サーバ10の制御部11は、処理を終了するか否かを判定し(S150)、終了しないと判定したならば(S150:NO)、S110に処理を戻す。
一方、処理を終了すると判定したならば(S150:YES)、サーバ10の制御部11は、処理を終了する。
一方、処理を終了すると判定したならば(S150:YES)、サーバ10の制御部11は、処理を終了する。
本処理で示したように、ユーザがライブ配信を行っている間は、ライバー経験値ばかりでなく、ユーザ経験値も算出される。そして、ライバーレベルがレベルアップするのみならず、ユーザレベルがレベルアップする場合もある。
<第1実施例の効果>
本実施例は、ライブ動画を配信する配信者の端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。そして、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末において視聴者行動が行われた場合に、端末のユーザに第1ポイントを付与するとともに、端末のユーザの第1レベルを向上させることができる。
本実施例は、ライブ動画を配信する配信者の端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。そして、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末において視聴者行動が行われた場合に、端末のユーザに第1ポイントを付与するとともに、端末のユーザの第1レベルを向上させることができる。
また、この場合、ユーザ経験値を付与する制御は、ライブ動画の視聴中に制御部11によって行われ、ユーザレベルを向上させる制御は、ライブ動画の視聴中に制御部11によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の視聴中に、端末のユーザにポイントを付与したり、レベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の視聴中に、端末のユーザにポイントを付与したり、レベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
本実施例は、ライブ動画を配信する配信者の端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、ライブ動画の配信実績に基づいて配信者にライバー経験値(限定ではなく、第2ポイントの一例)を付与する制御を制御部11によって行う。そして、サーバ10は、配信者に付与されたライバー経験値の増加に基づいて、配信者のライバーレベル(限定ではなく、第2レベルの一例)を向上させる制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、端末のユーザに第2ポイントを付与するとともに、端末のユーザの第2レベルを向上させることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、端末のユーザに第2ポイントを付与するとともに、端末のユーザの第2レベルを向上させることができる。
また、この場合、ライバー経験値を付与する制御は、ライブ動画の配信中に制御部11によって行われ、ライバーレベルを向上させる制御は、ライブ動画の配信中に制御部11によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができる。
<第2実施例>
第2実施例は、所定条件が成立した場合に、限定ではなく例として、ユーザのライバー経験値を減少させたり、ライバーに対して特典の付与や報酬の支払い等を行うことを可能にする実施例である。
第2実施例は、所定条件が成立した場合に、限定ではなく例として、ユーザのライバー経験値を減少させたり、ライバーに対して特典の付与や報酬の支払い等を行うことを可能にする実施例である。
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
所定条件の成立は、限定ではなく例として、所定期間の経過(所定期間の終了)とすることができる。所定条件は、限定ではなく例として、サーバ10が設定するようにすることができ、所定期間も、サーバ10が設定するようにすることができる。
本実施例では、上記の所定期間を、1シーズンごとの期間として「シーズン期間」や単に「シーズン」と称する。シーズン期間はどのように設定してもよいが、限定ではなく例として、毎月のひと月の期間(1日から月末日までの期間)とすることができる。つまり、ひと月を単位として連続的にシーズン期間が設定されるようにすることができる。
なお、所定条件の別例については後述する。
なお、所定条件の別例については後述する。
図1-16に示したように、ライバーランクには「ルーキー」~「神」等を設けることができる。あくまでも一例であるが、ライバーランク「ルーキー」から「レジェンド」まではユーザがライバー経験値を稼いでライバーランクを上げていき、ライバーランク「神」を目指すようにすることができる。言ってみれば、より上位のライバーランクを目指して自分を成長させる遊びとすることができる。
その一方で、最上位のライバーランク「神」については、ランク内レベルに上限を設けず(図1-16に示したように「Lv1~上限なし」)、どこまでライバー経験値やランク内レベルを伸ばせるかユーザが追い求める遊びとすることができる。本実施例では、これに加えて、限定ではなく例として、所定期間ごとに、ライバーランクが「神」であるユーザ同士でランキングを競わせる。また、本実施例では、ライバーランクが「神」であるユーザには、所定期間ごとに、その所定期間における成績に応じた報酬を支払うようにする。さらに、本実施例では、所定期間ごとに、その所定期間が終了した場合に、ライバーランクが「神」であるユーザのライバー経験値を減少させ、ライバーレベルを低下させることで、ライバーレベルのレベルアップのスピードを緩やかにする。
<表示画面>
図2-1は、本実施例において端末20Aの表示部24に表示されるライブ配信アプリケーションの画面の一例を示す図である。
図2-1左側は、ライブ配信アプリケーションのマイページ画面であり、図1-11に引き続き、ユーザA.Aが視聴者やライバーとなってライブを視聴したりライブを配信し、シーズン2の期間が終了した場合のマイページ画面の一例を示す図である。
図2-1は、本実施例において端末20Aの表示部24に表示されるライブ配信アプリケーションの画面の一例を示す図である。
図2-1左側は、ライブ配信アプリケーションのマイページ画面であり、図1-11に引き続き、ユーザA.Aが視聴者やライバーとなってライブを視聴したりライブを配信し、シーズン2の期間が終了した場合のマイページ画面の一例を示す図である。
この画面では、ユーザレベル情報表示領域ULRにユーザレベルとして「Lv69」が表示され、ライバーレベル情報表示領域LLRにライバーレベルとして「神 Lv12」(ライバーランク「神」、ランク内レベル「Lv12」)が表示されている。
以下では、ライバーランク「神」におけるランク内レベルのことを、便宜的に「神レベル」と称する場合がある。
以下では、ライバーランク「神」におけるランク内レベルのことを、便宜的に「神レベル」と称する場合がある。
また、ユーザA.Aがライバーランク「神」になってからライバー活動を続けてランク内レベルが向上したことに基づき(現在は「Lv12」)、ユーザA.Aは、図1-11中央、右側の画面に示したランクバッジRB1よりも位の高いランクバッジRB2を獲得し、さらにフレームFM2、マイページ背景BG2を獲得している。そして、これに伴い、プロフィール領域には、プロフィールアイコンと関連付けてランクバッジRB2が表示され、プロフィールアイコンにフレームFM2が設定され、背景画像にマイページ背景BG2が設定されている。
また、シーズン2の期間が終了したことに伴い、アプリ内位置表示領域の下に構成される領域の最上部右のランキングアイコンIC1から、シーズン期間が終了したことを示す情報が吹き出しで表示されている。この例では、「シーズン2」の期間が終了したことに基づいて「シーズン2が終了しました」の文字を含む吹き出しが表示されている。
この場合、ランキングを示すアイコン画像がタップされると、限定ではなく例として、図2-1中央の画面が表示される。
この画面は、各々のシーズン期間におけるユーザのランキングを示すシーズンランキング画面の一例であり、アプリ内位置表示領域には「シーズンランキング」の文字が表示されている。
この画面は、各々のシーズン期間におけるユーザのランキングを示すシーズンランキング画面の一例であり、アプリ内位置表示領域には「シーズンランキング」の文字が表示されている。
また、その下の領域の最上部には、終了した直近のシーズン期間(この例では「シーズン2」)を示す情報(この例では「シーズン2終了」の文字を含む枠)が表示され、その左には、過去のシーズン期間におけるランキングを表示させるためのボタンが表示されている。
この例では、「シーズン2」におけるユーザのランキングとして、1位が「ユーザD.D」であり、2位が「ユーザA.A」であり、3位が「ユーザC.C」であり、4位が「ユーザB.B」であることが示されている。また、各々の順位について、その順位のユーザのアイコン画像およびユーザ名が表示され、これらと関連付けて、そのユーザがシーズンランキング報酬として獲得したトロフィーの数と、そのユーザの現在のライバーレベルとが表示されている。
なお、ユーザのランキングは、限定ではなく例として、各々の配信者がシーズン期間中に獲得したライバー経験値の総量や、各々の配信者のシーズン終了時点でのライバー経験値(今シーズン最終ライバー経験値)に基づいて決定することができる。
図2-1中央の画面において、限定ではなく例として、「ゲット」ボタンBT1がタップされると、限定ではなく例として、図2-1右側の画面が表示される。この画面には、そのシーズンにおいてユーザA.Aが獲得したシーズン報酬に関する情報が表示されている。
シーズン報酬は、限定ではなく例として、シーズンレベル報酬とシーズンランキング報酬とを合算した報酬(シーズンレベル報酬+シーズンランキング報酬)とすることができる。
シーズン報酬は、限定ではなく例として、シーズンレベル報酬とシーズンランキング報酬とを合算した報酬(シーズンレベル報酬+シーズンランキング報酬)とすることができる。
具体的には、上部には、ユーザA.Aの神レベル「Lv12」に基づいて付与されたシーズンレベル報酬に関する情報が表示されている。具体的には、神レベルに応じたシーズンレベル報酬が、神レベル帯ごとに区分されたピラミッドによって表示されている。ユーザA.Aの神レベルは「Lv12」であるため、ピラミッドのうちの「Lv11~Lv20」の神レベル帯が色付けて表示されており、対応するシーズンレベル報酬「10,000」トロフィーが付与されたことが示されている。
また、その下には、ユーザA.Aのシーズンランキング「2位」に基づいて付与されたシーズンランキング報酬に関する情報が表示されている。具体的には、ユーザA.Aのシーズンランキングが「2位」であることに基づき、対応するシーズンランキング報酬「50,000」トロフィーが付与されたことが示されている。
さらに、この例では、シーズンランキングが「2位」であることに基づき、シーズンランキング称号(獲得称号)「万年二位!」を獲得したことが示されている。
さらに、この例では、シーズンランキングが「2位」であることに基づき、シーズンランキング称号(獲得称号)「万年二位!」を獲得したことが示されている。
さらに、その下には、ユーザA.Aのシーズン報酬に関する情報が表示されている。具体的には、上記のシーズンレベル報酬「10,000」トロフィーと、シーズンランキング報酬「50,000」トロフィーとを合算し、シーズン報酬として「60,000」トロフィーを獲得したことが示されている。
ここで、上記のトロフィーは、限定ではなく例として、ライバーランクのうちの最上位のランクである「神」となったユーザに付与される特典(報酬と捉えてもよい。)とすることができる。
トロフィーは、1つの考え方としては、前述した「ランクバッジ」、「フレーム」、「マイページ背景」等のオブジェクトと同様の特典としてのオブジェクトと捉えることもできる。
また、これとは別に、トロフィーは、限定ではなく例として、所定のポイントや現金など、有価価値のある報酬に変換可能な特典とすることができる。
ライバーの活動により、前述した視聴者からの課金アイテムによって、ライブ配信サービス事業者が収益を得ることを可能とすることができる。そして、その収益の一部を、シーズン報酬に基づいてライバーに還元するようにすることができる。
ライバーの活動により、前述した視聴者からの課金アイテムによって、ライブ配信サービス事業者が収益を得ることを可能とすることができる。そして、その収益の一部を、シーズン報酬に基づいてライバーに還元するようにすることができる。
ポイントは、限定ではなく例として、ライブ配信サービス事業者と提携している事業者が提供する各種のサービスや、ライブ配信サービス事業者自体が提供する各種のサービス等において有価価値として利用可能なポイントとすることができる。
ここで言うポイントは、限定ではなく例として、法定通貨とは異なる企業通貨の一種と捉えてもよい。
なお、電子マネーも企業通貨の一種と捉えてもよく、ポイントに代えて電子マネーを付与してもよい。
なお、電子マネーも企業通貨の一種と捉えてもよく、ポイントに代えて電子マネーを付与してもよい。
ポイントは、限定ではなく例として、電子マネーを使用した支払い(決済)を行うための支払いアプリケーション(支払いアプリケーションを含む包括的なアプリケーションとしてウォレットアプリケーションを構成してもよい。)における支払いに充当したり、メッセージングアプリケーションにおいてスタンプや着せ替えの購入に利用したり、音楽配信アプリケーションにおいて音楽の購入やクーポンへの交換に利用したりするなどの用途で用いられるようにすることができる。また、この他にも、上記のサービスの事業者が提携している店舗(加盟店)で商品やサービスの交換に用いることを可能としてもよい。
ポイントの付与は、限定ではなく例として、サーバ10が、端末20でダウンロードされて端末20で実行される支払いアプリケーションやウォレットアプリケーションにおいて、端末20のユーザに対して付与するようにすることができる。
また、現金の支払いは、限定ではなく例として、サーバ10が、ユーザが登録している金融機関の口座にその金融機関のサーバと通信して振込によって支払うようにすることもできる。なお、端末20でダウンロードされて端末20で実行される支払いアプリケーションやウォレットアプリケーションにおいて、電子マネーの形態で支払いを行うようにしてもよい。
また、上記の各種のアプリケーションを統合的なアプリケーションとして構成し、この統合的なアプリケーション内で完結させるようにしてもよい。
また、限定ではなく例として、メッセージングアプリケーションに上記の各種のアプリケーションの機能を持たせて、このメッセージングアプリケーション内で完結させるようにしてもよい。
この場合、サーバ10に全ての機能を持たせてもよいし、機能ごとにサーバを分けてもよい。
また、限定ではなく例として、メッセージングアプリケーションに上記の各種のアプリケーションの機能を持たせて、このメッセージングアプリケーション内で完結させるようにしてもよい。
この場合、サーバ10に全ての機能を持たせてもよいし、機能ごとにサーバを分けてもよい。
限定ではなく例として、ライブ配信アプリケーションに一般ユーザとしてアカウント登録し、さらにライバー登録したユーザは、限定ではなく例として、大きく以下の2つのユーザに分類することができる。
(a)無所属のユーザ(事務所に所属していないユーザ)
(b)ライバー事務所に所属しているユーザ
(a)無所属のユーザ(事務所に所属していないユーザ)
(b)ライバー事務所に所属しているユーザ
また、(b)のユーザは、限定ではなく例として、大きく以下の2つに分けることができる。
(b1)ライブ配信サービス事業者が運営するライバー事務所に所属するユーザ
(b2)ライブ配信サービス事業者以外の外部のライバー事務所に所属するユーザ
(b1)ライブ配信サービス事業者が運営するライバー事務所に所属するユーザ
(b2)ライブ配信サービス事業者以外の外部のライバー事務所に所属するユーザ
サーバ10は、限定ではなく例として、上記のユーザの区分に基づいて、ユーザに支払う報酬の種別や、支払う報酬の割合(支払い率)を異ならせるようにすることができる。
限定ではなく例として、(a)のユーザには報酬としてポイントを支払い、(b)のユーザには報酬として現金を支払うようにするなどすることができる。
サーバ10は、限定ではなく例として、(a)のユーザは支払い率を「20%」とし、シーズン報酬の「20%」分のポイントを報酬として支払うようにするなどすることができる。
また、サーバ10は、限定ではなく例として、(b1)のユーザと(b2)のユーザとで支払い率を異ならせることができる。
限定ではなく例として、(b1)のユーザは支払い率を「40%」とし、シーズン報酬の「40%」に相当する金額を現金で支払うようにする。それに対し、(b2)のユーザは支払い率を「50%」とし、シーズン報酬の「50%」に相当する金額を現金で支払うなどするようにすることができる。この例は、限定ではなく例として、(b2)のユーザの方が(b1)のユーザよりも支払い率を高くする例である。
ただし、支払い率の関係を逆にしてもよい。
限定ではなく例として、(b1)のユーザは支払い率を「40%」とし、シーズン報酬の「40%」に相当する金額を現金で支払うようにする。それに対し、(b2)のユーザは支払い率を「50%」とし、シーズン報酬の「50%」に相当する金額を現金で支払うなどするようにすることができる。この例は、限定ではなく例として、(b2)のユーザの方が(b1)のユーザよりも支払い率を高くする例である。
ただし、支払い率の関係を逆にしてもよい。
なお、(a)のユーザと(b)のユーザとを区別せず、両者にポイントや電子マネー等の企業通貨を付与したり、両者に現金を支払うようにしてもよい。
また、(b1)のユーザと(b2)のユーザとを区別せず、両者の支払い率を同じとしてもよい。
また、上記の例とは支払い率を異ならせてもよい。
また、(b1)のユーザと(b2)のユーザとを区別せず、両者の支払い率を同じとしてもよい。
また、上記の例とは支払い率を異ならせてもよい。
図2-2左側は、図2-1右側の画面において「OK」ボタンBT2がタップされた場合に表示される画面の一例を示す図である。
この画面は、シーズンランキング画面の一例であり、この例では、シーズン2終了に伴い、ユーザA.Aの神レベルが低下したことを示す情報が表示されている。
この画面は、シーズンランキング画面の一例であり、この例では、シーズン2終了に伴い、ユーザA.Aの神レベルが低下したことを示す情報が表示されている。
具体的には、シーズン3の初期のユーザA.Aのライバー経験値が、シーズン2終了時の「443,297」から「321,649」に低下することが示されている。この計算方法については詳細に後述する。
また、ライバー経験値の減少に伴い、シーズン3の初期のユーザA.Aの神レベルが、シーズン2終了時の「Lv12」から「Lv7」に低下することが示されている。
また、ライバー経験値の減少に伴い、シーズン3の初期のユーザA.Aの神レベルが、シーズン2終了時の「Lv12」から「Lv7」に低下することが示されている。
図2-2左側の画面において「OK」ボタンBT3がタップされると、限定ではなく例として、図2-2右側の画面が表示される。
この画面は、前述したマイページ画面であり、プロフィール領域には、前述したランクバッジRB2、フレームFM2、マイページ背景BG2の他、限定ではなく例として、図2-1右側の画面に示した「万年二位!」のシーズンランキング称号AT2(前述したオブジェクトと捉えてもよい。)がシーズン期間(この例では「シーズン2」)と関連付けて表示されている。
この画面は、前述したマイページ画面であり、プロフィール領域には、前述したランクバッジRB2、フレームFM2、マイページ背景BG2の他、限定ではなく例として、図2-1右側の画面に示した「万年二位!」のシーズンランキング称号AT2(前述したオブジェクトと捉えてもよい。)がシーズン期間(この例では「シーズン2」)と関連付けて表示されている。
また、ライバーレベル情報表示領域LLRには、ライバーランク「神」に対応するキャラクタ(くまのキャラクタ)のアイコン画像とともに、上記のように神レベルが「LV12」から「LV7」に低下したことに伴い「神 Lv7」と表示されている。
<処理>
図2-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、図1-12と同様である。
図2-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、図1-12と同様である。
S140の後、またはS130において端末20Aからライブ配信要求情報を受信しなかったと判定した場合(S130:NO)、サーバ10の制御部11は、シーズンが終了したか否かを判定する(S210)。シーズンの終了は、限定ではなく例として、時計部19の計時情報に基づいて判定することができる。
シーズンが終了していないと判定したならば(S210:NO)、サーバ10の制御部11は、S110に処理を戻す。
シーズンが終了していないと判定したならば(S210:NO)、サーバ10の制御部11は、S110に処理を戻す。
一方、シーズンが終了したと判定したならば(S210:YES)、サーバ10の制御部11は、シーズン結果算出処理を行う(S220)。
図2-4は、シーズン結果算出処理で算出されるシーズン結果のうちのシーズンレベル報酬および次シーズンのライバーレベルの決定方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されている。
このテーブルには、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されている。
このテーブルにおいて、神レベルは、今シーズン終了時におけるライバーランク「神」のユーザのランク内レベルであり、この例では、一定の幅を持たせた神レベル帯が定められている。
このテーブルにおいて、シーズンレベル報酬は、限定ではなく例として、今シーズン終了時におけるユーザの神レベルが属する神レベル帯に応じてそのユーザに付与される報酬とすることができる。シーズンレベル報酬の一例は、前述したトロフィーとすることができる。
このテーブルにおいて、シーズンリセット経験値損失率は、次シーズンの初期ライバー経験値(以下、「次シーズン初期ライバー経験値」と称する。)を算出するために用いられる値である。
次シーズン初期ライバー経験値は、限定ではなく例として、以下の式(1)に従って算出するようにすることができる。
次シーズン初期ライバー経験値=今シーズン最終ライバー経験値-(今シーズン最終ライバー経験値-神レベルLv1に対応する達成ライバー経験値)×シーズンリセット経験値損失率 ・・・(1)
次シーズン初期ライバー経験値=今シーズン最終ライバー経験値-(今シーズン最終ライバー経験値-神レベルLv1に対応する達成ライバー経験値)×シーズンリセット経験値損失率 ・・・(1)
今シーズン最終ライバー経験値は、限定ではなく例として、今シーズン終了時におけるライバー経験値とすることができる。
神レベルLv1に対応する達成ライバー経験値は、限定ではなく例として、図1-16に示したテーブルにおいてライバーランク「神」に関連付けられた達成ライバー経験値の下限の値(図1-16の例では「200,000」)とすることができる。
神レベルLv1に対応する達成ライバー経験値は、限定ではなく例として、図1-16に示したテーブルにおいてライバーランク「神」に関連付けられた達成ライバー経験値の下限の値(図1-16の例では「200,000」)とすることができる。
式(1)によれば、次シーズン初期ライバー経験値が神レベルLv1に対応する達成ライバー経験値を下回らないため、ライバーランクが「神」から落ちることはない。これは、ライバーランクが「神」から落ちるようにするとユーザにとって酷である可能性があるためである。
なお、本実施例とは異なり、ライバーランクが「神」から落ちる場合があるように式(1)を改変してもよい。
なお、本実施例とは異なり、ライバーランクが「神」から落ちる場合があるように式(1)を改変してもよい。
また、限定ではなく例として、今シーズンにライバーの神レベルがアップしていた場合のシーズンリセット経験値損失率を、上記のテーブルに設定されている割合よりも低くしてもよい。
シーズンレベル報酬は、神レベル(神レベル帯)が高くなるほど、値が大きくなるように設定されている。つまり、今シーズン終了時におけるユーザの神レベルが高いほど、多くのシーズンレベル報酬が付与されるように値が設定されている。
また、この例では、シーズンリセット経験値損失率は、総体的には、神レベル(神レベル帯)が高くなるほど小さくなるように値が設定されている。つまり、今シーズン終了時におけるユーザの神レベルが高いほど、ライバー経験値の減少割合が小さくなる(損失率が低くなる)ように値が設定されている。ただし、図2-4の例では、異なる神レベル帯であっても同じ値が設定される場合があることとしている。
限定ではなく例として、図2-2左側の画面に示した例では、ユーザA.Aのシーズン2における神レベルが「Lv12」であり、今シーズン最終ライバー経験値が「443,297」である。
また、図2-4において、神レベル「Lv12」に対応するシーズンリセット経験値損失率は「50%」である。
また、図1-16において、神レベル達成ライバー経験値は「200,000」である。
この場合、式(1)に従ってユーザA.Aの次シーズン初期ライバー経験値を算出すると、
次シーズン初期ライバー経験値=443,297-(443,297-200,000)×50%=321,649
と算出される。そして、これに対応する神レベルは「Lv7」となる。
また、図2-4において、神レベル「Lv12」に対応するシーズンリセット経験値損失率は「50%」である。
また、図1-16において、神レベル達成ライバー経験値は「200,000」である。
この場合、式(1)に従ってユーザA.Aの次シーズン初期ライバー経験値を算出すると、
次シーズン初期ライバー経験値=443,297-(443,297-200,000)×50%=321,649
と算出される。そして、これに対応する神レベルは「Lv7」となる。
なお、減少後のライバー経験値が、経験値減少前の神レベルの範囲内であれば、神レベルは変化しない。
図2-5は、シーズン結果算出処理で算出されるシーズン結果のうちのシーズンランキング報酬の決定方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、神ランキングと、シーズンランキング報酬とが関連付けて設定されている。
このテーブルには、限定ではなく例として、神ランキングと、シーズンランキング報酬とが関連付けて設定されている。
神ランキングは、限定ではなく例として、今シーズンにおけるユーザのランキングであり、ライバーランクが「神」であるユーザのランキング(順位)として集計される。
シーズンランキング報酬は、限定ではなく例として、今シーズンにおけるユーザの神ランキングに応じてそのユーザに付与される報酬とすることができる。シーズンランキング報酬も、限定ではなく例として、前述したトロフィーとすることができる。
シーズンランキング報酬は、神ランキング(シーズンランキング)が高くなるほど、値が大きくなるように設定されている。つまり、ランキングの上位者ほど、より多くのシーズンランキング報酬が付与されるように設定されている。
また、この例では、ある程度上位の神ランキング(限定ではなく例として「1位~3位」)については、そのシーズンランキング報酬として、図2-4に設定されている平均的なシーズンレベル報酬に対して、相対的に大きめの値が設定されている。つまり、この例では、シーズンランキングで上位を目指す方が、神レベルのアップを目指すよりも多くの報酬を得やすくなっている。
このようにすることで、ユーザのシーズンランキング報酬に対する獲得意欲を高めることができる。シーズン終了時の神レベルは、シーズン期間によらない長期的な配信者としての実績に左右されるのに対して、シーズンランキングは、シーズン期間内におけるより短期的な配信者としての実績に左右される。そのため、新規の配信者にとって、シーズンランキング報酬はシーズンレベル報酬よりもより獲得が狙いやすい。シーズンランキング報酬をより高く設定することで、結果的に、ライブ配信コミュニティ内の活動が活発化し、ライブ配信サービス内のライブ配信数やライブのクオリティ向上が期待される。
このようにすることで、ユーザのシーズンランキング報酬に対する獲得意欲を高めることができる。シーズン終了時の神レベルは、シーズン期間によらない長期的な配信者としての実績に左右されるのに対して、シーズンランキングは、シーズン期間内におけるより短期的な配信者としての実績に左右される。そのため、新規の配信者にとって、シーズンランキング報酬はシーズンレベル報酬よりもより獲得が狙いやすい。シーズンランキング報酬をより高く設定することで、結果的に、ライブ配信コミュニティ内の活動が活発化し、ライブ配信サービス内のライブ配信数やライブのクオリティ向上が期待される。
なお、ある程度上位の神レベル(限定ではなく例として「Lv51~」)については、そのシーズンレベル報酬として、図2-5に設定されている平均的なシーズンランキング報酬と比べて、相対的に大きめの値を設定するようにしてもよい。
また、神ランキングに関連付けて前述したシーズンランキング称号をこのテーブルに設定しておき、サーバ10の制御部11が、これに基づいて、ライバーにシーズンランキング称号を与えるようにしてもよい。
本実施例では、上記のようにシーズンランキング報酬を設け、シーズンにおけるランキングに応じて、付加的な報酬を与えるようにしている。このようにすることで、最上位のライバーランクまで昇り詰めたユーザに対して、上位の順位を目指すように努力するモチベーションを与えることができる。
サーバ10の制御部11は、ユーザA.Aのライバーレベルが「神」である場合において、シーズン終了時におけるユーザA.Aの神レベルに基づき、図2-4のテーブルを参照して、この神レベルに対応するシーズンレベル報酬を決定する。また、サーバ10の制御部11は、その神レベルに対応するシーズンリセット経験値損失率に基づき、限定ではなく例として、式(1)に従ってユーザA.Aの次シーズン初期ライバー経験値を算出する。
さらに、サーバ10の制御部11は、各々の端末20のユーザの神レベルに基づいて、ユーザA.Aのシーズンランキングを特定する。そして、サーバ10の制御部11は、図2-5のテーブルを参照して、特定したシーズンランキングに応じたユーザA.Aのランキング報酬を決定する。そして、サーバ10の制御部11は、「シーズンレベル報酬+シーズンランキング報酬」を、ユーザA.Aに付与するシーズン報酬に決定する。
S220の後、サーバ10の制御部11は、シーズン結果情報を、通信I/F14によって端末20Aに送信する(S230)。シーズン結果情報には、限定ではなく例として、上記のようにしてS220で算出した今シーズンのライバーレベル(ライバーランクが「神」である場合は神レベル)、シーズンランキング(ライバーランクが「神」である場合)、シーズン報酬(ライバーランクが「神」である場合)、次シーズン神レベル(ライバーランクが「神」である場合)等を含めることができる。そして、サーバ10の制御部11は、処理を終了する。
A210においてシーズンが終了したと判定した場合(A210:YES)、端末20Aの制御部21は、通信I/F22によってサーバ10から受信したシーズン結果情報を表示部24に表示させる(A220)。そして、端末20Aの制御部21は、処理を終了する。
シーズンが終了した後、サーバ10の制御部11は、前述した各種の手法に基づいて、シーズン報酬に応じたポイントや現金をユーザに支払う支払い処理を行う。限定ではなく例として、月末日を集計の締め日とするのであれば、その翌日(月初日)に支払い処理を行い、シーズン報酬をリセットする。このようにして、シーズン報酬(トロフィー)をユーザが引き続き持てないようにする。
なお、図2-5のテーブルにおいて、限定ではなく例として、神ランキングが所定順位よりも上のライバーに対してのみシーズンランキング報酬が付与されるようにテーブルを構成してもよい。限定ではなく例として、シーズンランキングの上位5名のユーザに対してのみ、シーズンランキング報酬が付与されるようにしてもよい。
また、前述したシーズンレベル報酬やシーズンランキング報酬は、前述したように、特典と捉えてもよい。
また、前述したように、ライバーに応じて、上記の特典に関連付けられた報酬(ポイント、現金など)を異ならせてもよい。
また、前述したように、ライバーに応じて、上記の特典に関連付けられた報酬(ポイント、現金など)を異ならせてもよい。
<第2実施例の効果>
本実施例は、ライブ動画を配信する配信者の端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、ライブ動画の配信実績に基づいて配信者にライバー経験値(限定ではなく、ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、配信者に付与されたライバー経験値の増加に基づいて、配信者のライバーレベル(限定ではなく、レベルの一例)を向上させる制御を制御部11によって行う。また、サーバ10は、所定条件が成立した場合に、配信者に付与されたライバー経験値を減少させる制御を制御部11によって行う。そして、サーバ10は、ライバー経験値の減少に基づいて、配信者のライバーレベルを低下させる制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、配信者に付与されたポイントの増加に基づいて配信者のレベルを向上させる一方で、所定条件が成立した場合に、配信者に付与されたポイントを減少させ、そのポイントの減少に基づいて配信者のレベルを低下させることで、レベルが低下し得る危機感を配信者に持たせることができるとともに、ライブ配信を努力するモチベーションを配信者に持たせることができる。また、レベルの向上のスピードを緩やかにすることができる。さらに、新たな興趣を与えることができる。
本実施例は、ライブ動画を配信する配信者の端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、ライブ動画の配信実績に基づいて配信者にライバー経験値(限定ではなく、ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、配信者に付与されたライバー経験値の増加に基づいて、配信者のライバーレベル(限定ではなく、レベルの一例)を向上させる制御を制御部11によって行う。また、サーバ10は、所定条件が成立した場合に、配信者に付与されたライバー経験値を減少させる制御を制御部11によって行う。そして、サーバ10は、ライバー経験値の減少に基づいて、配信者のライバーレベルを低下させる制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、配信者に付与されたポイントの増加に基づいて配信者のレベルを向上させる一方で、所定条件が成立した場合に、配信者に付与されたポイントを減少させ、そのポイントの減少に基づいて配信者のレベルを低下させることで、レベルが低下し得る危機感を配信者に持たせることができるとともに、ライブ配信を努力するモチベーションを配信者に持たせることができる。また、レベルの向上のスピードを緩やかにすることができる。さらに、新たな興趣を与えることができる。
また、この場合、ライバー経験値を付与する制御は、ライブ動画の配信中に制御部11によって行われ、ライバーレベルを向上させる制御は、ライブ動画の配信中に制御部11によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信中に、配信者にポイントを付与したり、配信者のレベルを向上させることができ、いわばリアルタイムにポイントの付与やレベルの向上を行うことができるため、新たな興趣を与えることができる。
また、この場合、サーバ10は、配信者のライバーレベルが設定されたレベル(限定ではなく、所定レベルの一例)を超えている場合に、その設定されたレベルを超えていない場合よりも、配信者に付与されたライバー経験値の減少幅を少なくするようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者のレベルが所定レベルを超えている場合は、所定レベルを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、ハイレベルの配信者がモチベーションを失いにくくすることができる。
このような構成により得られる実施例の効果の一例として、配信者のレベルが所定レベルを超えている場合は、所定レベルを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、ハイレベルの配信者がモチベーションを失いにくくすることができる。
また、この場合、所定条件の成立は、シーズン期間(限定ではなく、所定期間の一例)の経過を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、所定期間が経過した場合に、配信者に付与されたポイントを減少させるため、配信者にとって分かり易い条件の成立に基づいてポイントを減少させることができる。
このような構成により得られる実施例の効果の一例として、所定期間が経過した場合に、配信者に付与されたポイントを減少させるため、配信者にとって分かり易い条件の成立に基づいてポイントを減少させることができる。
また、この場合、サーバ10は、シーズン期間内に配信者に付与されたライバー経験値に基づくシーズンランキング(限定ではなく、所定期間内に配信者に付与されたポイントに基づく順位の一例)が所定順位よりも上である場合に、配信者にシーズンランキング報酬(限定ではなく、特典の一例)を付与する制御を制御部11によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、所定期間内に配信者に付与されたポイントに基づく順位が所定順位より上である場合に、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
このような構成により得られる実施例の効果の一例として、所定期間内に配信者に付与されたポイントに基づく順位が所定順位より上である場合に、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
また、この場合、サーバ10は、シーズンランキングが所定順位よりも上である場合と、所定順位よりも上ではない場合とのいずれの場合も、通算のライバー経験値(または神レベル)(限定ではなく、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計の一例)に基づいて、配信者にシーズンレベル報酬を付与する制御を制御部21によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の順位が所定順位より上であろうとなかろうと、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
このような構成により得られる実施例の効果の一例として、上記の順位が所定順位より上であろうとなかろうと、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて、配信者に特典を付与することで、配信者のモチベーションを向上させることができる。
また、この場合、シーズンランキングが所定順位より上である場合に付与されるシーズンランキング報酬は、シーズン期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて配信者に付与されるシーズンレベル報酬よりも大きくなるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、配信者の順位が上位であればあるほど、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて配信者に付与される特典よりも多くの特典を配信者に付与することができる。その結果、仮に合計が低くても、順位の上位を目指すように配信者に努力させるきっかけを作ることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、配信者の順位が上位であればあるほど、所定期間内に配信者に付与されたポイントと所定期間外に配信者に付与されたポイントとの合計に基づいて配信者に付与される特典よりも多くの特典を配信者に付与することができる。その結果、仮に合計が低くても、順位の上位を目指すように配信者に努力させるきっかけを作ることができる。
また、本実施例は、配信者のライバーランク(限定ではなく、ランクの一例)として、少なくとも、神ランクより下位のランク(限定ではなく、第1ランクの一例)と、神ランク(限定ではなく、第1ランクよりも上位の第2ランクの一例)とを含む複数のライバーランクが設けられ、複数のライバーランクに対応した複数のランク内レベルが設けられ、配信者に付与されたライバー経験値が神ランクよりも下位のランクにおける最高のランク内レベルに対応する達成ライバー経験値を超過したことに基づいて、配信者のライバーランクが神ランクに向上する。そして、配信者のライバーランクが神ランクである場合に、配信者に付与されたライバー経験値に基づいて、神ランクにおける神レベルが向上する構成を示している。
このような構成により得られる実施例の効果の一例として、第1ランクから第2ランクに到達するまでの目標を設定し易くすることができる。
このような構成により得られる実施例の効果の一例として、第1ランクから第2ランクに到達するまでの目標を設定し易くすることができる。
また、この場合、サーバ10は、配信者のライバーランクが神ランクより下位のランクである場合に、所定条件の成立に基づく、配信者に付与されたライバー経験値を減少させる制御を行わず、配信者のライバーランクが神ランクである場合に、所定条件の成立に基づく、配信者に付与されたライバー経験値を減少させる制御と、このライバー経験値の減少に基づく、配信者の神レベルを低下させる制御とを行うようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者のランクが第2ランクよりも下位の第1ランクであれば、付与されたポイントを減少させる制御を行わないことで、第2ランクを目指すモチベーションを配信者に与えることができる。その一方で、配信者のランクが第2ランクに到達した後は、付与されたポイントを減少させる制御と、それに伴いレベルを低下させる制御とを行うことで、配信者に危機感を与えることができる。
このような構成により得られる実施例の効果の一例として、配信者のランクが第2ランクよりも下位の第1ランクであれば、付与されたポイントを減少させる制御を行わないことで、第2ランクを目指すモチベーションを配信者に与えることができる。その一方で、配信者のランクが第2ランクに到達した後は、付与されたポイントを減少させる制御と、それに伴いレベルを低下させる制御とを行うことで、配信者に危機感を与えることができる。
また、この場合、所定条件が成立した場合に、配信者のライバーランクが神ランクから神ランクよりも下位のランクに低下しないようにすることができる。
このような構成により得られる実施例の効果の一例として、所定条件が成立した場合であっても、配信者のランクが第2ランクから第1ランクに低下しないようにすることで、配信者に安心感を与えることができる。
このような構成により得られる実施例の効果の一例として、所定条件が成立した場合であっても、配信者のランクが第2ランクから第1ランクに低下しないようにすることで、配信者に安心感を与えることができる。
また、本実施例は、サーバ10が、配信者にシリーズを付与する制御を制御部11によって行う。この場合、配信者に応じて、特典に関連付けられた報酬が異なるようにすることができる。
このような構成により得られる実施例の効果の一例として、配信者に特典を付与することができるとともに、配信者に応じて、特典に関連付けられた報酬を異ならせることができる。
このような構成により得られる実施例の効果の一例として、配信者に特典を付与することができるとともに、配信者に応じて、特典に関連付けられた報酬を異ならせることができる。
<第2変形例(1)>
上記の実施例では、ユーザのライバー経験値やライバーレベルを減少させる条件(限定ではなく、所定条件の一例)を、シーズン期間(限定ではなく、所定期間の一例)の経過としたが、これに限定されない。
上記の実施例では、ユーザのライバー経験値やライバーレベルを減少させる条件(限定ではなく、所定条件の一例)を、シーズン期間(限定ではなく、所定期間の一例)の経過としたが、これに限定されない。
限定ではなく例として、前シーズンのシーズンランキングが1位であったユーザが今シーズンに入ってから獲得したライバー経験値が設定値以上(または設定値超)となったことや、前シーズンのシーズンランキングが1位であったユーザのライバー経験値が今シーズンのスタート時におけるライバー経験値から設定割合以上(または設定割合超)増加したことなどを、所定条件の成立としてもよい。これは、限定ではなく例として、今シーズンに入ってから特定のユーザが独走状態となったような場合である。
なお、任意のユーザのライバー経験値が設定値以上(または設定値超)となったことを、所定条件の成立としてもよい。これは、限定ではなく例として、シーズンのゴールとなるライバー経験値の到達値が予め設定される場合である。
所定条件は、限定ではなく例として、サーバ10側で自由に設定可能とすることができる。
所定条件は、限定ではなく例として、サーバ10側で自由に設定可能とすることができる。
<第2変形例(2)>
上記の実施例では、所定期間として連続的なシーズン期間を例示したが、これに限定されない。
上記に限らず、離散的な期間を所定期間として設定してもよい。つまり、一定の時間間隔を置いてシーズン期間を設定するなどしてもよい。
上記の実施例では、所定期間として連続的なシーズン期間を例示したが、これに限定されない。
上記に限らず、離散的な期間を所定期間として設定してもよい。つまり、一定の時間間隔を置いてシーズン期間を設定するなどしてもよい。
また、連続的な期間であるか離散的な期間であるかに関わらず、期間の長さを可変にしてもよい。
限定ではなく例として、式(1)に従って算出される次シーズンライバー経験値の値が最も大きいユーザと、次シーズンライバー経験値が2番目に大きいユーザとの次シーズンライバー経験値の差が設定値以上(または設定値超)である場合は、今シーズンよりも短い期間を次シーズンの期間として設定するなどしてもよい。つまり、ランキングトップのユーザのライバー経験値が突出しているような場合に、さらに大きな差がつくことを防止するために、次シーズンの期間を短くしてもよい。
また、逆に、差が設定値未満(または設定値以下)である場合は、今シーズンよりも長い期間を次シーズンの期間として設定するなどしてもよい。
限定ではなく例として、式(1)に従って算出される次シーズンライバー経験値の値が最も大きいユーザと、次シーズンライバー経験値が2番目に大きいユーザとの次シーズンライバー経験値の差が設定値以上(または設定値超)である場合は、今シーズンよりも短い期間を次シーズンの期間として設定するなどしてもよい。つまり、ランキングトップのユーザのライバー経験値が突出しているような場合に、さらに大きな差がつくことを防止するために、次シーズンの期間を短くしてもよい。
また、逆に、差が設定値未満(または設定値以下)である場合は、今シーズンよりも長い期間を次シーズンの期間として設定するなどしてもよい。
所定期間は、所定条件と同様に、限定ではなく例として、サーバ10側で自由に設定可能とすることができる。
<第2変形例(3)>
上記の実施例で説明したライバー経験値を減少させる手法はあくまでも一例に過ぎず、これに限定されない。
上記の実施例で説明したライバー経験値を減少させる手法はあくまでも一例に過ぎず、これに限定されない。
図2-6は、図2-4のテーブルの別例を示す図である。
このテーブルには、図2-4のテーブルと同様に、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されているが、主としてシーズンリセット経験値損失率の欄が異なる。
このテーブルには、図2-4のテーブルと同様に、限定ではなく例として、神レベルと、シーズンレベル報酬と、シーズンリセット経験値損失率とが関連付けて設定されているが、主としてシーズンリセット経験値損失率の欄が異なる。
シーズンリセット経験値損失率の欄は、限定ではなく例として、今シーズンが新記録ではない場合と、今シーズンが新記録である場合とに分けられている。
今シーズンが新記録である場合とは、各々のユーザについて、限定ではなく例として、そのユーザが今シーズンに獲得したライバー経験値が過去最高の値となったこととすることができる。それに対し、今シーズンが新記録ではない場合とは、上記以外の場合とすることができる。
今シーズンが新記録である場合とは、各々のユーザについて、限定ではなく例として、そのユーザが今シーズンに獲得したライバー経験値が過去最高の値となったこととすることができる。それに対し、今シーズンが新記録ではない場合とは、上記以外の場合とすることができる。
なお、上記とは異なり、ユーザの今シーズンにおけるシーズンランキングが過去最高の順位となったことを、今シーズンが新記録となった場合としてもよい。
今シーズンが新記録ではない場合と今シーズが新記録の場合とのいずれについても、総体的には、神レベルが高くなるほど、シーズンリセット経験値損失率が小さくなるように値が設定されている。ただし、図2-6の例では、異なる神レベル帯であっても同じ値が設定される場合があることとしている。
その一方で、同じ神レベル(神レベル帯)に着目した場合、今シーズンが新記録の場合のシーズンリセット経験値損失率は、今シーズンが新記録ではない場合のシーズンリセット経験値損失率と比べて相対的に小さくなるように値が設定されている。つまり、今シーズが新記録であったライバーは、その実績を考慮して、ライバー経験値の減少割合を小さくしている。
その一方で、同じ神レベル(神レベル帯)に着目した場合、今シーズンが新記録の場合のシーズンリセット経験値損失率は、今シーズンが新記録ではない場合のシーズンリセット経験値損失率と比べて相対的に小さくなるように値が設定されている。つまり、今シーズが新記録であったライバーは、その実績を考慮して、ライバー経験値の減少割合を小さくしている。
なお、上記はあくまでも一例であり、これに限定されない。
神レベル(神レベル帯)に依らず、今シーズンが新記録の場合のシーズンリセット経験値損失率を一律の値(限定ではなく例として「30%」)としてもよい。
また、新記録を履歴として残すことができるようにシーズンリセット経験値損失率を「0%」としてもよい。
神レベル(神レベル帯)に依らず、今シーズンが新記録の場合のシーズンリセット経験値損失率を一律の値(限定ではなく例として「30%」)としてもよい。
また、新記録を履歴として残すことができるようにシーズンリセット経験値損失率を「0%」としてもよい。
本変形例は、サーバ10が、シーズン期間(限定ではなく、所定期間)内に配信者に付与されたライバー経験値が設定された値(限定ではなく、所定ポイントの一例)を超えている場合に、設定された値を超えていない場合よりも、配信者に付与されたライバー経験値の減少幅を少なくする構成を示している。
このような構成により得られる変形例の効果の一例として、所定期間内に配信者に付与されたポイントが所定ポイントを超えている場合に、所定ポイントを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、所定期間内に配信者が多くのポイントを獲得したような場合に、その配信者のポイントがあまり減少しないようにすることができる。
このような構成により得られる変形例の効果の一例として、所定期間内に配信者に付与されたポイントが所定ポイントを超えている場合に、所定ポイントを超えていない場合よりも、配信者に付与されたポイントの減少幅を少なくすることで、所定期間内に配信者が多くのポイントを獲得したような場合に、その配信者のポイントがあまり減少しないようにすることができる。
<第2変形例(4)>
上記の実施例では、シーズン報酬(シーズンレベル報酬+シーズンランキング報酬)に基づいてポイントや現金をユーザに支払うこととしたが、これに限定されない。
上記の実施例では、シーズン報酬(シーズンレベル報酬+シーズンランキング報酬)に基づいてポイントや現金をユーザに支払うこととしたが、これに限定されない。
限定ではなく例として、シーズンレベル報酬に基づいてポイントや現金をユーザに支払うようにしてもよい。また、この場合、オブジェクトを異ならせ、限定ではなく例として、シーズンレベル報酬のオブジェクトは「トロフィー」とし、「シーズンランキング報酬」のオブジェクトは「メダル」とするなどしてもよい。このようにすることで、シーズンレベル報酬がポイントや現金に変換可能であることをユーザに認識させることができる。
なお、これとは逆に、シーズンランキング報酬に基づいてポイントや現金をユーザに支払うようにしてもよい。
<第3実施例>
第3実施例は、限定ではなく例として、視聴者としてライブ配信アプリケーションを利用していたユーザが、配信者(ライバー)としてデビューすることに関する実施例である。
ライブの視聴者の中には熱心な視聴者がいると考えられ、このような視聴者は、配信者としても成功する可能性があると考えられる。しかし、視聴者になることよりも配信者になることの方がハードルが高い場合がある。
第3実施例は、限定ではなく例として、視聴者としてライブ配信アプリケーションを利用していたユーザが、配信者(ライバー)としてデビューすることに関する実施例である。
ライブの視聴者の中には熱心な視聴者がいると考えられ、このような視聴者は、配信者としても成功する可能性があると考えられる。しかし、視聴者になることよりも配信者になることの方がハードルが高い場合がある。
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面>
図3-1は、本実施例において端末20の表示部24に表示されるライブ配信アプリケーション画面の一例を示す図である。ここでは、前述したユーザA.Aとは異なるユーザとして、ユーザF.Fがライバーとしてデビューする場合を例示する。
以下説明する画面は、このユーザF.Fの端末20Fの表示部24に表示される画面である。
図3-1は、本実施例において端末20の表示部24に表示されるライブ配信アプリケーション画面の一例を示す図である。ここでは、前述したユーザA.Aとは異なるユーザとして、ユーザF.Fがライバーとしてデビューする場合を例示する。
以下説明する画面は、このユーザF.Fの端末20Fの表示部24に表示される画面である。
図3-1左側は、ライブ配信アプリケーションのマイページ画面であり、この例では、ユーザF.Fが視聴者としてライブ配信アプリケーションを利用しているのみで、未だライバーデビューしていない(ライバー登録していない)状態を示している。
プロフィール領域には、ユーザF.Fが設定したベース画像がプロフィールアイコンPI3として表示されている。
また、ユーザF.Fが自ら背景を設定していない、またはライバー登録していないため背景を設定できないようになっている、などの理由で、この例では、マイページ背景BG3は無地(未設定)となっている。
また、ユーザF.Fが自ら背景を設定していない、またはライバー登録していないため背景を設定できないようになっている、などの理由で、この例では、マイページ背景BG3は無地(未設定)となっている。
また、ユーザF.Fはライバー登録していないため、図1-8左側に示した画面と同様に構成されたライバーレベル情報表示領域LLRには、ライバー登録するための情報として「ライバーになる」の文字が示されている。ライバーレベル情報表示領域LLRがタップされると、限定ではなく例として、図3-1中央の画面が表示される。
この画面は、限定ではなく例として図1-8中央に示した画面と同様に構成されたライブステータス画面であり、ライバーレベル詳細情報表示領域LLDRには、ユーザF.Fがライバーデビューしたことに伴い、ライバーランク「ルーキー」、ランク内レベル「Lv1」が表示され、このライバーレベルに対応するキャラクタのアイコン画像としてカエルのキャラクタのアイコン画像が表示されている。
また、ライバーランクおよびランク内レベルの表示の下には、図1-8中央に示した画面と同様に、次のランク内レベルにレベルアップするまでに必要とされるライバー経験値ゲージおよび文字が表示されている。しかし、この例では、本実施例に関連する表示として、ユーザF.Fがライバーデビューしたことに伴いユーザF.Fが取得したライバーボーナスに関する情報が表示されている。
詳細は後述するが、ユーザF.Fが視聴者として行動していた際に獲得したユーザ経験値とユーザレベルの少なくとも一方に基づくライバーボーナスとしてライバー経験値が付与され、この例では、「ライバーEXPボーナス中!」の文字を含む吹き出しとともに、ライバーボーナスとして付与されたライバー経験値分だけ、ライバー経験値ゲージLG1が増加する様子が示されている。この例では、このライバー経験値ゲージLG1の増加は図3-1右側の画面まで続く。
最終的に、図3-1右側の画面が表示される。この例では、ライバーボーナスによって、結果的に、ユーザF.Fのライバーランクが下から2つ目の「レギュラー」、そのランク内レベルが「Lv2」までレベルアップした状態が示されている。
このように、本実施例では、ライバーデビューによってライバーボーナスが付与され、ライバーデビューした時点で、ライバーボーナス分だけライバーレベルが上がった状態でユーザA.Aはライバーとしての活動が開始することができる。
このように、本実施例では、ライバーデビューによってライバーボーナスが付与され、ライバーデビューした時点で、ライバーボーナス分だけライバーレベルが上がった状態でユーザA.Aはライバーとしての活動が開始することができる。
図3-2は、図3-1とは異なり、ユーザF.Fがライバーデビューした後、ライブ配信を行う場合に表示される画面の一例を示す図である。
なお、ここでは、ユーザF.Fのライバーデビュー時にライバーボーナスは付与されておらず、ライバーランクが最下位の「ルーキー」、そのランク内レベル「Lv1」からスタートした場合を例示する。
なお、ここでは、ユーザF.Fのライバーデビュー時にライバーボーナスは付与されておらず、ライバーランクが最下位の「ルーキー」、そのランク内レベル「Lv1」からスタートした場合を例示する。
図3-2左側のマイページ画面において、「ライバーになる」の文字を含むライバーレベル情報表示領域LLRがタップされ、サーバ10によってライバー登録された後、ライブの配信がユーザF.Fによって開始されると、限定ではなく例として、図3-2中央の画面が表示される。
この画面は、ユーザF.Fによるライブ配信画面であり、図1-10に示したユーザA.Aがライブ配信を行う画面とほぼ同様の構成となっている。しかし、この例では、ユーザF.Fがライバーデビュー前に視聴者として行動していた際に獲得したユーザ経験値とユーザレベルの少なくとも一方に基づくライバーボーナスが、ユーザF.Fがライブ配信中に獲得したライバー経験値に上乗せされる。これを示すための表示として、ライバー経験値ゲージLG2(「ルーキー Lv1」の文字を含むゲージ)の下には、「ライバーEXP190%ボーナス中!」の文字を含む吹き出しが表示されている。
ユーザF.Fがライバー経験値を取得すると、ライバーボーナス分だけ多くライバー経験値が溜まる。ユーザF.Fのライバーレベルがアップすると、限定ではなく例として、図3-2右側の画面が表示される。
ライバー経験値の取得に基づきランク内レベルが「Lv1」から「Lv2」にレベルアップしたことに基づき、ライバー経験値ゲージLG2には、ライバーランク「ルーキー」の横にランク内レベル「Lv2」が表示されている。また、ライバー経験値ゲージLG2のゲージ量が、ランク内レベル「Lv2」の対応する位置まで増加して表示されている。
また、ランク内レベルが「Lv2」にレベルアップしたことに基づき、ライバーレベルアップ情報LUIが画面中央部にポップアップ表示されている。このライバーレベルアップ情報LUIは、ランク内レベルがアップしたことを示す情報であるため、ライバーランク内レベルアップ情報と称してもよい。
また、コメント表示領域CDRには、ユーザF.Fを発信元とするコメントとして、ユーザF.Fのアイコン画像およびユーザ名と関連付けて「ランク内レベルが上がりました!」のテキストと、レベルアップ後のライバーレベル「ルーキー Lv2」のアイコンとを含むコメントCM3が表示されている。コメントCM3は、前述したコメントCM1やコメントCM2と同様に、ユーザ入力に基づく通常のコメントとは異なるコメントであり、限定ではなく例として、ライバーランクやランク内レベルがアップしたと判定したサーバ10によって生成されて各々の端末20に送信されるコメントとすることができる。
<処理>
図3-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は前述した通りである。
なお、前述したフローチャートに合わせて、端末20Aの制御部21が実行する処理として図示・説明する。
図3-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は前述した通りである。
なお、前述したフローチャートに合わせて、端末20Aの制御部21が実行する処理として図示・説明する。
A130の後、端末20Aの制御部21は、自己の端末20AのユーザA.Aがライバーデビューするか否かを判定する(A310)。ライバーデビューしないと判定したならば(A310:NO)、端末20Aの制御部21は、A210に処理を進める。
一方、ライバーデビューすると判定したならば(A310:YES)、端末20Aの制御部21は、ライバーとして参加することを要求するライバー参加要求情報を、通信I/F22によってサーバ10に送信する(A320)。
S120の後、サーバ10の制御部11は、通信I/F14によって端末20Aからライバー参加要求情報を受信したか否かを判定し(S310)、受信しなかったと判定したならば(S310:NO)、S130に処理を進める。
一方、ライバー参加要求情報を受信したと判定したならば(S310:YES)、サーバ10の制御部11は、ライバーボーナス算出処理を行う(S320)。
次いで、サーバ10の制御部11は、ライバーボーナス算出処理の算出結果に基づいて、ライバーボーナス情報を、通信I/F14によって端末20Aに送信する(S330)。そして、サーバ10の制御部11は、S130に処理を進める。
A320の後、通信I/F22によってサーバ10からライバーボーナス情報を受信すると、端末20Aの制御部21は、受信したライバーボーナス情報を表示部24に表示させる(A330)。そして、端末20Aの制御部21は、A140に処理を進める。
図3-4は、ライバーボーナスの算出方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、ボーナス付与機会(ボーナス付与タイミング)と、ライバーボーナスと、第1の例と、第2の例と、第3の例とが関連付けて設定されている。
このテーブルには、限定ではなく例として、ボーナス付与機会(ボーナス付与タイミング)と、ライバーボーナスと、第1の例と、第2の例と、第3の例とが関連付けて設定されている。
ボーナス付与機会は、そのライバーボーナスが付与される機会(タイミング)であり、この例では、「ライバー登録時」(ライブを配信する前の状態)と、「ライブ配信時」(ライブの配信中または配信後)とが定められている。
ライバーボーナスは、対応するボーナス付与機会にそのライバーに付与されるボーナスである。
ボーナス付与機会「ライバー登録時」には、限定ではなく例として、ライバーボーナスとして「[ユーザレベル×50]のライバー経験値を初期値として設定」が定められている。これは、視聴者のユーザがライバーとなることを希望してサーバ10が登録を行う場合に、そのユーザのライバー経験値の初期値を「0」とするのではなく、そのユーザの最新のユーザレベルに設定された倍率(この例では50倍)を乗算した値をライバー経験値の初期値として設定することを示している。このようにすることで、ユーザレベルに応じた分のライバー経験値を取得した状態でライバーとしてデビューすることを可能とすることができる。
ボーナス付与機会「ライブ配信時」には、限定ではなく例として、ライバーボーナスとして「[配信実績に応じたライバー経験値]に(100+[ユーザレベル])%を乗算」が定められている。これは、視聴者がライバーとして登録した後、ライブ配信を行っている最中、またはライブ配信を終了した後、ライバーボーナスとして、そのユーザがライブ配信の実績に応じて取得したライバー経験値に、ユーザレベルに応じたボーナス経験値を上乗せすることを示している。
第1の例~第3の例は、上記を適用する組合せ(パターン)を示している。
第1の例は、「ライバー登録時のライバーボーナス」は適用するが、「ライブ配信時のライバーボーナス」は適用しない例である。
第2の例は、「ライバー登録時のライバーボーナス」は適用しないが、「ライブ配信時のライバーボーナス」は適用する例である。
第3の例は、「ライバー登録時のライバーボーナス」と「ライブ配信時のライバーボーナス」とをいずれも適用する例である。
どの組合せを適用するかは、サーバ10側で自由に設定可能とすることができる。
なお、課金等によってユーザ側(端末20側)でどの組合せを適用するかを設定可能としてもよい。
第1の例は、「ライバー登録時のライバーボーナス」は適用するが、「ライブ配信時のライバーボーナス」は適用しない例である。
第2の例は、「ライバー登録時のライバーボーナス」は適用しないが、「ライブ配信時のライバーボーナス」は適用する例である。
第3の例は、「ライバー登録時のライバーボーナス」と「ライブ配信時のライバーボーナス」とをいずれも適用する例である。
どの組合せを適用するかは、サーバ10側で自由に設定可能とすることができる。
なお、課金等によってユーザ側(端末20側)でどの組合せを適用するかを設定可能としてもよい。
「ライバー登録時のライバーボーナス」を適用する場合、サーバ10の制御部11は、図3-3のS320のライバーボーナス算出処理において、上記の計算式に基づいてライバーボーナスを算出し、その値をユーザA.Aのライバー経験値の初期値として設定するようにすることができる。
また、サーバ10の制御部11は、上記のユーザA.Aのライバー経験値の初期値に基づいて、限定ではなく例として、図1-16に示したテーブルに基づいて、ユーザA.Aのライバーレベルを決定し、それをユーザA.Aのライバーレベルの初期値として設定するようにすることができる。
また、サーバ10の制御部11は、上記のユーザA.Aのライバー経験値の初期値に基づいて、限定ではなく例として、図1-16に示したテーブルに基づいて、ユーザA.Aのライバーレベルを決定し、それをユーザA.Aのライバーレベルの初期値として設定するようにすることができる。
「ライブ配信時のライバーボーナス」を適用する場合、サーバ10の制御部11は、限定ではなく例として、図3-3のS140のステップで実行されるライブ配信処理(図1-15)のS1450のステップにおいて、上記の計算式に基づいてライバーボーナスを算出し、その値でユーザA.Aのライバー経験値を更新することができる。
なお、ライブ配信後にライバーボーナスを算出する場合は、サーバ10の制御部11は、限定ではなく例として、図3-3のS140のステップの後、上記の計算式に基づいてライバーボーナスを算出し、その値でユーザA.Aのライバー経験値を更新することができる。
なお、ライブ配信後にライバーボーナスを算出する場合は、サーバ10の制御部11は、限定ではなく例として、図3-3のS140のステップの後、上記の計算式に基づいてライバーボーナスを算出し、その値でユーザA.Aのライバー経験値を更新することができる。
<第3実施例の効果>
本実施例は、ライブ動画が配信される端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う。そして、サーバ10は、端末20のユーザがライブ動画の配信者となる場合に、ユーザレベルに基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を決定する制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、視聴者行動が行われたことに基づいて端末のユーザに付与された第1ポイントの増加に基づく第1レベルに基づいて、端末のユーザがライブ動画の配信者となる場合の第2レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
本実施例は、ライブ動画が配信される端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う。そして、サーバ10は、端末20のユーザがライブ動画の配信者となる場合に、ユーザレベルに基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を決定する制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、視聴者行動が行われたことに基づいて端末のユーザに付与された第1ポイントの増加に基づく第1レベルに基づいて、端末のユーザがライブ動画の配信者となる場合の第2レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、この場合、サーバ10は、端末20のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値(限定ではなく、第2ポイントの一例)を端末20のユーザに付与する制御を制御部11によって行う。また、サーバ10は、ライバー経験値の増加に基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を向上させる制御を制御部11によって行う。この場合、ライバー経験値は、ライブ動画の配信実績と、ユーザレベル(限定ではなく、第1レベル)とに基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第1ポイントとは異なる第2ポイントを端末のユーザに付与するとともに、第2ポイントの増加に基づいて、端末のユーザの第2レベルを向上させることができる。その一方で、第2ポイントは、ライブ動画の配信実績と第1レベルとに基づくため、ライブ動画の配信実績ばかりでなく、第1レベルも考慮されて第2ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第1ポイントとは異なる第2ポイントを端末のユーザに付与するとともに、第2ポイントの増加に基づいて、端末のユーザの第2レベルを向上させることができる。その一方で、第2ポイントは、ライブ動画の配信実績と第1レベルとに基づくため、ライブ動画の配信実績ばかりでなく、第1レベルも考慮されて第2ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
また、この場合、端末20のユーザがライブ動画の配信者となる場合に決定されたライバーレベルが上位レベルである場合に、下位レベルに対応するライバーレベルが充足されたことが、限定ではなく例として、端末20の表示部24に表示されるライバー経験値ゲージが上位レベルまで増加する演出等によって端末20のユーザに報知されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザが配信者となってから未だライブ動画の配信を開始していない段階で、既に下位のレベルを脱却していること端末のユーザに意識させることができる。また、配信者としてのモチベーションを向上させて端末のユーザの活動を支援することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザが配信者となってから未だライブ動画の配信を開始していない段階で、既に下位のレベルを脱却していること端末のユーザに意識させることができる。また、配信者としてのモチベーションを向上させて端末のユーザの活動を支援することができる。
本実施例は、ライブ動画が配信される端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う。また、サーバ10は、端末20のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値(限定ではなく、第2ポイントの一例)を端末20のユーザに付与する制御を制御部11によって行う。また、サーバ10は、ライバー経験値の増加に基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を向上させる制御を制御部11によって行う。この場合、ライバー経験値(限定ではなく、第2ポイントの一例)は、ライブ動画の配信実績と、ユーザレベル(限定ではなく、第1レベル)とに基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、この場合、サーバ10は、端末20のユーザがライブ動画の配信者となる場合に、ユーザレベル(限定ではなく、第1レベルの一例)に基づいて、ライバーレベル(限定ではなく、第2レベルの一例)を決定する制御を制御部11によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者となる場合に、端末のユーザの第1レベルに基づいて、端末のユーザの第2レベルを適切に決定することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者となる場合に、端末のユーザの第1レベルに基づいて、端末のユーザの第2レベルを適切に決定することができる。
また、この場合、上記の視聴者行動は、ライブ動画の視聴を含み、そのライブ動画の視聴時間に応じて、付与されるユーザ経験値が異なるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、ライブ動画の視聴時間が長いほど多くの第1ポイントを端末のユーザに付与するといったことが可能となる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、ライブ動画の視聴時間が長いほど多くの第1ポイントを端末のユーザに付与するといったことが可能となる。
また、この場合、視聴者行動は、ライブ動画に関する評価またはコメントを含むようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画に関する評価またはコメントが視聴者行動として行われたことに基づいて、端末のユーザに第1ポイントを付与することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画に関する評価またはコメントが視聴者行動として行われたことに基づいて、端末のユーザに第1ポイントを付与することができる。
また、この場合、視聴者行動は、ライブ配信アプリケーションのサインインやログイン(限定ではなく、ライブ動画を視聴するためのユーザの認証の一例)を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画を視聴するためのユーザ認証が行われたことに基づいて、端末のユーザに第1ポイントを付与することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによってライブ動画を視聴するためのユーザ認証が行われたことに基づいて、端末のユーザに第1ポイントを付与することができる。
また、この場合、サーバ10は、端末20のユーザがライブ動画を配信した場合に、ユーザ経験値を端末のユーザに付与する制御を制御部11によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者として活動した場合でも、端末のユーザに第1ポイントを付与することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信者として活動した場合でも、端末のユーザに第1ポイントを付与することができる。
また、この場合、サーバ10は、端末20のユーザがライブ動画の配信を所定時間行った場合に、ライブ動画の視聴を所定時間行う場合と少なくとも同じユーザ経験値を端末20のユーザに付与するようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信を所定時間行った場合に、これと同じ所定時間ライブ動画を視聴する場合と同じかそれよりも大きい第1ポイントを端末のユーザに付与することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがライブ動画の配信を所定時間行った場合に、これと同じ所定時間ライブ動画を視聴する場合と同じかそれよりも大きい第1ポイントを端末のユーザに付与することができる。
<第3変形例(1)>
図3-4のテーブルでは、ユーザレベルに基づいてライバーボーナスが付与される例を示したが、これに限定されない。
図3-4のテーブルでは、ユーザレベルに基づいてライバーボーナスが付与される例を示したが、これに限定されない。
具体的には、限定ではなく例として、ユーザ経験値に基づいてライバーボーナスが付与されるようにしてもよい。この場合は、限定ではなく例として、図3-4のテーブルにおける「ユーザレベル」を「ユーザ経験値」として倍率や割合を適宜設定して、ライバーボーナスが付与されるようにすることができる。
また、ユーザ経験値とユーザレベルとの両方に基づいてライバーボーナスが付与されるようにしてもよい。この場合は、限定ではなく例として、図3-4のテーブルにおいて、ボーナス付与機会「ライバー登録時」には、ライバーボーナス「[ユーザレベル×C1+ユーザ経験値×C2]のライバー経験値を初期値として設定」(ただし、C1とC2は無次元化パラメータ)を関連付けておく。また、ボーナス付与機会「ライブ配信時」には、ライバーボーナス「[配信実績に応じたライバー経験値]に(100+[ユーザレベル]+[ユーザ経験値]×C3)%を乗算」(ただし、C3はユーザ経験値のユーザレベルの次元に合わせるパラメータ)を関連付けておくなどすることができる。
ただし、これらはあくまでも一例に過ぎず、これらの計算式に限定されるわけではない。
ただし、これらはあくまでも一例に過ぎず、これらの計算式に限定されるわけではない。
また、ボーナス付与機会「ライバー登録時」について、ユーザレベルに基づいてライバーレベルを直接的に決定するようにしてもよい。限定ではなく例として、ユーザレベルが「Lv30」であれば、ライバーレベルの初期値をライバーランク「ルーキー」のランク内レベル「Lv10」とし、ユーザレベルが「Lv60」であれば、ライバーレベルの初期値をライバーランク「レギュラー」の「Lv10」とするなどしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
同様に、ボーナス付与機会「ライブ配信時」についても、ユーザレベルに基づいてライバーレベルを直接的に決定するようにしてもよい。限定ではなく例として、ユーザレベルが「Lv100以上」であれば、ライブ配信時にライバーレベル(ランク内レベル)がアップする場合にライバーレベルを「1」上乗せしてレベルアップさせ、「Lv200以上」であれば、ライブ配信時にライバーレベルがアップする場合にライバーレベルを「2」上乗せしてレベルアップさせるなどしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
また、この場合、決定したライバーレベルに応じたライバー経験値をユーザに付与するようにしてもよい。
上記の実施例および本変形例によれば、ライブ動画が配信される端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う。そして、サーバ10は、端末20のユーザがライブ動画の配信者となる場合に、ユーザ経験値(限定ではなく、第1ポイントの一例)とユーザレベル(限定ではなく、第1レベルの一例)の少なくとも一方に基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を決定する制御を制御部11によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第1ポイントと第1レベルの少なくとも一方に基づいて、端末のユーザがライブ動画の配信者となる場合の第2レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
このような構成により得られる実施例の効果の一例として、第1ポイントと第1レベルの少なくとも一方に基づいて、端末のユーザがライブ動画の配信者となる場合の第2レベルが決定されるため、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
また、上記の実施例および本変形例によれば、サーバ10は、端末20のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値(限定ではなく、第2ポイントの一例)を端末20のユーザに付与する制御を制御部11によって行う。また、サーバ10は、ライバー経験値の増加に基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を向上させる制御を制御部11によって行う。そして、ライバー経験値は、ライブ動画の配信実績と、ユーザ経験値(限定ではなく、第1ポイントの一例)とユーザレベル(限定ではなく、第1レベル)の少なくとも一方と、に基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第1ポイントとは異なる第2ポイントを端末のユーザに付与するとともに、第2ポイントの増加に基づいて、端末のユーザの第2レベルを向上させることができる。その一方で、第2ポイントは、ライブ動画の配信実績と、第1ポイントと第1レベルの少なくとも一方と、に基づくため、ライブ動画の配信実績ばかりでなく、第1ポイントや第1レベルも考慮されて第2ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
このような構成により得られる実施例の効果の一例として、ライブ動画の配信実績に基づいて、第1ポイントとは異なる第2ポイントを端末のユーザに付与するとともに、第2ポイントの増加に基づいて、端末のユーザの第2レベルを向上させることができる。その一方で、第2ポイントは、ライブ動画の配信実績と、第1ポイントと第1レベルの少なくとも一方と、に基づくため、ライブ動画の配信実績ばかりでなく、第1ポイントや第1レベルも考慮されて第2ポイントが付与されるため、端末のユーザを視聴者から配信者に転換させる動機付けをより効果的に与えることができる。
また、上記の実施例および本変形例によれば、ライブ動画が配信される端末20と通信するサーバ10(限定ではなく、情報処理装置の一例)は、端末20において視聴者行動が行われた場合に、端末20のユーザにユーザ経験値(限定ではなく、第1ポイントの一例)を付与する制御を制御部11によって行う。また、サーバ10は、ユーザ経験値の増加に基づいて、端末20のユーザのユーザレベル(限定ではなく、第1レベルの一例)を向上させる制御を制御部11によって行う。また、サーバ10は、端末20のユーザがライブ動画を配信した場合に、少なくともライブ動画の配信実績に基づいて、ユーザ経験値とは異なるライバー経験値(限定ではなく、第2ポイントの一例)を端末20のユーザに付与する制御を制御部11によって行う。また、サーバ10は、ライバー経験値の増加に基づいて、端末20のユーザのライバーレベル(限定ではなく、第2レベルの一例)を向上させる制御を制御部11によって行う。この場合、ライバー経験値は、ライブ動画の配信実績と、ユーザ経験値(限定ではなく、第1ポイントの一例)とユーザレベル(限定ではなく、第1レベル)の少なくとも一方と、に基づくようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザを視聴者から配信者に転換させる動機付けを効果的に与えることができる。
本実施例および本変形例によれば、ライバー経験値やライバーレベルとは別に構成されたユーザ経験値やユーザレベルを、視聴者からライバーへの転換に活用することができる。つまり、ユーザ経験値やユーザレベルに基づくライバーボーナスを付与することによって、ライバーに転換したユーザのライバーレベルを向上し易くすることができる。
<他の実施例>
(1)情報処理装置
上記の実施例では、本開示における情報処理装置をサーバ10として説明したが、これに限定されない。
(1)情報処理装置
上記の実施例では、本開示における情報処理装置をサーバ10として説明したが、これに限定されない。
サーバ10を1つとするのではなく、サーバ10を複数のサーバに分け、これら各々のサーバを本開示における情報処理装置としてもよい。
また、サーバではなく、ライブ配信を行う端末(ライブ配信を行うユーザの端末)と通信する管理用のコンピュータ等の端末や管理用のスマートフォン等の端末を、本開示における情報処理装置としてもよい。
また、複数の情報処理装置を含むシステムを構成し、このシステムが、上記の実施例で説明したサーバ10の各種の処理を行うようにしてもよい。
(2)特典・報酬
ライバー経験値やライバーレベルに基づきユーザに付与される特典と同様に、ユーザ経験値やユーザレベルに基づき、ユーザに特典や報酬が付与されるようにしてもよい。
ライバー経験値やライバーレベルに基づきユーザに付与される特典と同様に、ユーザ経験値やユーザレベルに基づき、ユーザに特典や報酬が付与されるようにしてもよい。
限定ではなく例として、前述したユーザ称号としてのバッジの他、フレームやマイページ背景等のオブジェクトを同様に付与するようにしてもよい。
また、最上位のライバーランク「神」よりも下のライバーランクについても、前述したシーズンランキング等を同様に構成して、ユーザにシーズン報酬を付与するようにしてもよい。
また、ユーザレベルについても同様に、シーズンランキング等を構成して、ユーザにシーズン報酬を付与するようにしてもよい。
また、ユーザ経験値やユーザレベルに基づきユーザに付与される特典や報酬は、ライバーに付与される特典や報酬と比べて相対的に少なくしてもよい。
(3)アイコンの表示態様
図4-1は、ユーザに関するアイコンの表示態様を説明するためのテーブルの一例を示す図である。
なお、ここで図示する組合せは、一部を例示したものである。
図4-1は、ユーザに関するアイコンの表示態様を説明するためのテーブルの一例を示す図である。
なお、ここで図示する組合せは、一部を例示したものである。
このテーブルには、限定ではなく例として、組合せと、プロフィールアイコンと、ユーザアイコンと、ライバーアイコンとが関連付けて設定されている。この例では、組合せとして「1」~「9」の9通りの組合せが含まれる。
プロフィールアイコンについては、前述した通りである。
このテーブルにおける「ユーザアイコン」は、限定ではなく例として、ユーザ経験値やユーザレベルに関連する活動に伴い表示されるそのユーザのアイコンや、ユーザレベルのレベルアップ時に表示されるそのユーザのアイコンとすることができる。限定ではなく例として、以下の少なくともいずれか1つをこれに含めることができる。
・ユーザが視聴者としてライブを視聴中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザレベルアップ時のユーザレベルアップ画面に表示されるアイコン
・ユーザが視聴者としてライブを視聴中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザレベルアップ時のユーザレベルアップ画面に表示されるアイコン
このテーブルにおける「ライバーアイコン」は、限定ではなく例として、ライバーとしての活動に伴い表示されるそのユーザ(そのライバー)のアイコンや、ライバーレベルのレベルアップ時に表示されるそのユーザ(そのライバー)のアイコンとすることができる。限定ではなく例として、以下の少なくともいずれか1つをこれに含めることができる。
・ユーザがライバーとしてライブを配信中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザがライバーとしてライブを配信中にライブ画面に表示される自身のアイコン
・ライバーレベルアップ時のライバーレベルアップ画面に表示されるアイコン
・ユーザがライバーとしてライブを配信中にコメントを送信する場合に自身のコメントと関連付けて表示されるアイコン
・ユーザがライバーとしてライブを配信中にライブ画面に表示される自身のアイコン
・ライバーレベルアップ時のライバーレベルアップ画面に表示されるアイコン
そして、このテーブルでは、各々の組合せについて、プロフィールアイコンと、ユーザアイコンと、ライバーアイコンとして表示する各々の画像等の組合せが設定されている。
なお、テーブル中の「ベース画像」については、前述した通りである。
なお、テーブル中の「ベース画像」については、前述した通りである。
組合せ「1」のライバーアイコンに設定されている「ベース画像(ライバー経験値が基準以下)」は、ライバー経験値が基準以下である場合は、ライバーとしての配信実績が乏しいため、ライバーアイコンとして「ベース画像」を表示することを意味する。
この例において、「ユーザ経験値に応じたオブジェクト」は、ユーザ経験値(またはユーザレベル)に基づきユーザに付与される特典としてのオブジェクトであって、限定ではなく例として、前述した「ユーザ称号としてのバッジ」(前述した「ランクバッジ」とは異なる。)等をこれに含めることができる。
また、この例において、「ライバー経験値に応じたオブジェクト」は、ライバー経験値(またはライバーレベル)に基づきユーザに付与される特典としてのオブジェクトであって、限定ではなく例として、前述した「ランクバッジ」、「フレーム」、「マイページ背景」、「獲得称号」、「トロフィー」等をこれに含めることができる。
なお、ユーザアイコンに「ベース画像」とあるのは、ユーザ経験値に応じたオブジェクト自体が仕様として設けられていない場合と、ユーザ経験値に応じたオブジェクトが仕様として設けられてはいるもののユーザ経験値が基準以下であることによりオブジェクトが付加されない場合と、のいずれの場合であってもよい。
また、前述したように、ユーザがライバー活動を行っている際に、ユーザレベルがレベルアップする場合がある。この場合は、図4-1のテーブルの「ユーザアイコン」の欄に示したユーザアイコンの表示を行うようにすることができる。
また、上記のプロフィールアイコン、ユーザアイコン、ライバーアイコンのいずれもが変更されない(すべてをベース画像のままとする)としてもよい。
(4)ライブ配信に基づく経験値
上記の実施例において、端末のユーザがライブ配信を行う場合には、ユーザ経験値を付与しないようにしてもよい。
上記の実施例において、端末のユーザがライブ配信を行う場合には、ユーザ経験値を付与しないようにしてもよい。
(5)ユーザランク
上記の実施例において、ライバーランクと同様に、ユーザランクを設けてもよい。
また、各々のユーザランクの中に、対応するランク内レベルを設けてもよい。
上記の実施例において、ライバーランクと同様に、ユーザランクを設けてもよい。
また、各々のユーザランクの中に、対応するランク内レベルを設けてもよい。
(6)レベルの低下
上記の実施例において、情報処理装置が、所定条件が成立した場合に、配信者のレベルを低下させる制御を行うようにしてもよい。そして、低下させたレベルに応じて、配信者のポイントを減少させるようにしてもよい。つまり、ポイントを減少させることと、レベルを低下させることと、のいずれを先に行うこととしてもよいし、同時に行うようにしてもよい。
上記の実施例において、情報処理装置が、所定条件が成立した場合に、配信者のレベルを低下させる制御を行うようにしてもよい。そして、低下させたレベルに応じて、配信者のポイントを減少させるようにしてもよい。つまり、ポイントを減少させることと、レベルを低下させることと、のいずれを先に行うこととしてもよいし、同時に行うようにしてもよい。
なお、配信者のレベルを低下させた場合に、配信者のポイントを減少させないようにしてもよい。
また、配信者のポイントを減少させることと、配信者のレベルを低下させることとの少なくともいずれか一方を行うようにしてもよい。
(7)ポイント
上記の実施例では、ポイントの一例として経験値を例示したが、他の単位としてもよい。つまり、配信や視聴に基づいて端末のユーザに付与される価値であればよく、必ずしも経験値という単位の価値である必要はない。
上記の実施例では、ポイントの一例として経験値を例示したが、他の単位としてもよい。つまり、配信や視聴に基づいて端末のユーザに付与される価値であればよく、必ずしも経験値という単位の価値である必要はない。
(8)その他
前述したように、上記の各々の実施例、各々の変形例、その他の実施例等で説明した内容は、それぞれ組み合わせて適用することが可能である。
前述したように、上記の各々の実施例、各々の変形例、その他の実施例等で説明した内容は、それぞれ組み合わせて適用することが可能である。
1 通信システム
10 サーバ
20 端末
30 ネットワーク
10 サーバ
20 端末
30 ネットワーク
Claims (15)
- ライブ動画を配信する配信者の端末と通信する情報処理装置によって実行されるプログラムであって、
前記ライブ動画の配信実績に基づいて前記配信者にポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
前記配信者に付与されたポイントの増加に基づいて、前記配信者のレベルを向上させる制御を前記制御部によって行うことと、
所定条件が成立した場合に、前記配信者に付与されたポイントを減少させる制御を前記制御部によって行うことと、
前記配信者に付与されたポイントの減少に基づいて、前記配信者のレベルを低下させる制御を前記制御部によって行うことと、
を含むプログラム。 - 請求項1に記載のプログラムであって、
前記ポイントを付与する制御は、前記ライブ動画の配信中に前記制御部によって行われ、
前記レベルを向上させる制御は、前記ライブ動画の配信中に前記制御部によって行われる、
プログラム。 - 請求項1または請求項2に記載のプログラムであって、
前記配信者のレベルが所定レベルを超えている場合に、前記所定レベルを超えていない場合よりも、前記配信者に付与されたポイントの減少幅を少なくする、
プログラム。 - 請求項1から請求項3のいずれか一項に記載のプログラムであって、
前記所定条件の成立は、所定期間の経過を含む、
プログラム。 - 請求項4に記載のプログラムであって、
前記所定期間内に前記配信者に付与されたポイントが所定ポイントを超えている場合に、前記所定ポイントを超えていない場合よりも、前記配信者に付与されたポイントの減少幅を少なくする、
プログラム。 - 請求項4または請求項5に記載のプログラムであって、
前記所定期間内に前記配信者に付与されたポイントに基づく順位が所定順位より上である場合に、前記配信者に特典を付与する制御を前記制御部によって行うことを含む、
プログラム。 - 請求項6に記載のプログラムであって、
前記順位が前記所定順位より上である場合と、前記所定順位より上ではない場合とのいずれの場合も、前記所定期間内に前記配信者に付与されたポイントと前記所定期間外に前記配信者に付与されたポイントとの合計に基づいて前記配信者に前記特典を付与する制御を前記制御部によって行うことを含む、
プログラム。 - 請求項7に記載のプログラムであって、
前記順位が前記所定順位より上である場合に付与される前記特典は、前記合計に基づいて前記配信者に付与される前記特典よりも大きい、
プログラム。 - 請求項1から請求項8のいずれか一項に記載のプログラムであって、
前記配信者のランクとして、少なくとも、第1ランクと、前記第1ランクよりも上位の第2ランクとを含む複数のランクが設けられ、前記複数のランクのそれぞれに対応した複数のレベルが設けられ、
前記配信者に付与されたポイントが前記第1ランクにおける最高レベルに対応するポイントを超過したことに基づいて、前記配信者のランクが前記第2ランクに向上し、
前記配信者のランクが前記第2ランクである場合に、前記配信者に付与されたポイントの増加に基づいて、前記第2ランクにおける前記配信者のレベルが向上する、
プログラム。 - 請求項9に記載のプログラムであって、
前記配信者のランクが前記第1ランクである場合に、前記所定条件の成立に基づく、前記配信者に付与されたポイントを減少させる制御が行われず、
前記配信者のランクが前記第2ランクである場合に、前記所定条件の成立に基づく、前記配信者に付与されたポイントを減少させる制御と、前記配信者に付与されたポイントの減少に基づく、前記配信者のレベルを低下させる制御とが行われる、
プログラム。 - 請求項10に記載のプログラムであって、
前記所定条件が成立した場合に、前記配信者のランクが前記第2ランクから第1ランクに低下しない、
プログラム。 - 請求項1から請求項11のいずれか一項に記載のプログラムであって、
前記配信者に特典を付与する制御を前記制御部によって行うことを含み、
前記配信者に応じて前記特典に関連付けられた報酬が異なる、
プログラム。 - ライブ動画を配信する配信者の端末と通信する情報処理装置の情報処理方法であって、
前記ライブ動画の配信実績に基づいて前記配信者にポイントを付与する制御を前記情報処理装置の制御部によって行うことと、
前記配信者に付与されたポイントの増加に基づいて、前記配信者のレベルを向上させる制御を前記制御部によって行うことと、
所定期間が経過した場合に、前記配信者に付与されたポイントを減少させる制御を前記制御部によって行うことと、
前記配信者に付与されたポイントの減少に基づいて、前記配信者のレベルを低下させる制御を前記制御部によって行うことと、
を含む情報処理方法。 - ライブ動画を配信する配信者の端末と通信する情報処理装置であって、
前記ライブ動画の配信実績に基づいて前記配信者にポイントを付与する制御と、前記配信者に付与されたポイントの増加に基づいて、前記配信者のレベルを向上させる制御と、所定期間が経過した場合に、前記配信者に付与されたポイントを減少させる制御と、前記配信者に付与されたポイントの減少に基づいて、前記配信者のレベルを低下させる制御と、を行う制御部を備える情報処理装置。 - ライブ動画を配信する配信者の端末と通信する情報処理装置であって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
前記プロセッサは、
前記ライブ動画の配信実績に基づいて前記配信者にポイントを付与する制御を行うことと、
前記配信者に付与されたポイントの増加に基づいて、前記配信者のレベルを向上させる制御を行うことと、
所定条件が成立した場合に、前記配信者に付与されたポイントを減少させる制御を行うことと、
前記配信者に付与されたポイントの減少に基づいて、前記配信者のレベルを低下させる制御を行うことと、
を実行する情報処理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021165818A JP2023056435A (ja) | 2021-10-07 | 2021-10-07 | プログラム、情報処理方法、情報処理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021165818A JP2023056435A (ja) | 2021-10-07 | 2021-10-07 | プログラム、情報処理方法、情報処理装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023056435A true JP2023056435A (ja) | 2023-04-19 |
Family
ID=86004670
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021165818A Pending JP2023056435A (ja) | 2021-10-07 | 2021-10-07 | プログラム、情報処理方法、情報処理装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2023056435A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7368038B1 (ja) * | 2023-07-18 | 2023-10-24 | 株式会社ミラティブ | ゲームのライブ配信サーバ及びプログラム |
-
2021
- 2021-10-07 JP JP2021165818A patent/JP2023056435A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7368038B1 (ja) * | 2023-07-18 | 2023-10-24 | 株式会社ミラティブ | ゲームのライブ配信サーバ及びプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11413549B2 (en) | Gameplay threads in messaging applications | |
US9576434B2 (en) | Implementing computer activity-based challenges | |
AU2015363667B2 (en) | A method and system for gaming revenue | |
US11531918B2 (en) | Interactive live event outcome selection and prediction | |
US20130268479A1 (en) | System and method for presenting and managing social media | |
JP2023056436A (ja) | プログラム、情報処理方法、情報処理装置 | |
US20130053142A1 (en) | Computer-implemented real-time reality based data game and methods | |
CN109428910B (zh) | 一种数据处理方法、装置及系统 | |
US20140172505A1 (en) | Methods and systems for online support and promotion of authors | |
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 | |
JP3216098U (ja) | インタラクティブ環境における広告の提供システム | |
CN108235041A (zh) | 视频直播播放器抽奖方法及装置 | |
US12014604B2 (en) | Tournament system for memes and other interactive media | |
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 | |
JP2023056435A (ja) | プログラム、情報処理方法、情報処理装置 | |
US9390581B2 (en) | Information generation device, information provision system, and information storage medium | |
WO2014190421A1 (en) | System and method for event promotion and fund raising | |
JP2015195998A (ja) | クイズ生成処理システム、ゲーム提供装置、クイズ生成処理プログラム及びゲーム提供装置 | |
CN109561050A (zh) | 一种识别批量账号的方法和装置 | |
US9202201B2 (en) | Approval based economy | |
CN109146436B (zh) | 一种电子红包生成方法及装置 | |
KR20130082595A (ko) | 온라인 게임에서의 소셜 네트워크 서비스 제공 방법 및 이를 수행하는 서버 | |
US9674663B2 (en) | Proximity-enabled digital gesture tracking | |
KR20240056023A (ko) | 사용자를 위한 위치 기반의 맞춤형 컨텐츠 제공 방법 |
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 |