JP7497001B1 - サーバ及び方法 - Google Patents

Abstract

【課題】ライブ配信における通知を最適化する。【解決手段】サーバは、ライブ配信プラットフォームに係るサーバであって、ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持する保持手段と、ユーザの関心対象配信者を、ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとしてサーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分ける処理手段と、を備える。【選択図】図１

Description

本開示は、サーバ及び方法に関する。

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

特許文献１には、ライブ配信の配信者のフォロワーに、当該配信者の配信スケジュールを通知する技術が開示されている。

特開２０２３－１１５８８４号公報

ライブ配信に関する通知にはユーザにライブ配信の視聴を促す効果がある。しかしながら、であるからといって何でもかんでも通知を送ればよいというものではない。通知は多すぎるとユーザに嫌がられ無視されるようになるので、その意義を失ってしまう。

本開示はこうした課題に鑑みてなされたものであり、その目的は、ライブ配信における通知を最適化することができる技術の提供にある。

本発明のある態様は、サーバに関する。このサーバは、ライブ配信プラットフォームに係るサーバであって、ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持する保持手段と、ユーザの関心対象配信者を、ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとしてサーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分ける処理手段と、を備える。

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

本発明によれば、ライブ配信における通知を最適化することができる。

本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図１のサーバの機能および構成を示すブロック図である。 図３のストリームＤＢの一例を示すデータ構造図である。 図３のユーザＤＢの一例を示すデータ構造図である。 図３のギフトＤＢの一例を示すデータ構造図である。 図１のライブ配信システムにおけるユーザ視点の通知の最適化を示す模式図である。 図３のフォロイー処理部におけるフォロイー分類処理の流れを示すフローチャートである。 図１のサーバにおける配信開始プッシュ通知の送信および再送処理の流れを示すフローチャートである。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 アクティブユーザのユーザ端末のディスプレイに表示される配信開始プッシュ通知を含む画面の代表画面図である。 本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

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

本発明者は独自の検討により以下の知見を得た。
ライブ配信の開始やスケジュール登録などのライブ配信プラットフォームにおける配信者の所定の活動をトリガとして、その配信者をフォローしているユーザにプッシュ通知などの通知を自動的に生成して送信すると、その配信者は手間をかけずにより多くの視聴者を集めることができる。これにより、ライブ配信プラットフォームをより活性化することができる。一方、通知は数が多くなると邪魔なものとして認識される傾向にある。したがって、ライブ配信プラットフォームにおいて自動送信される通知を最適化する必要がある。

通知を最適化するタイミングとしては、まず、通知を自動生成するタイミングが考えられる。通知を自動生成する際に、併せて通知を送るユーザを選ぶのである。具体的には、配信者によるライブ配信の開始を検出すると、当該配信者の各フォロワーについてスコアを算出し、算出されたスコアでフォロワーをソーティングする。そして、スコアの高い方から所定の数のフォロワーのみに通知を送り、残りのフォロワーには通知しない。これにより、配信者にとって無駄となりうる通知を減らしつつ、配信者にとって重要なユーザには通知が行くようにすることができる。

しかしながら、上記の配信者視点の通知の最適化には次に述べる課題がある。配信者視点で重要なユーザを選ぶ場合、高額課金ユーザや投げ銭額の多いユーザ（以下、ＶＩＰと総称する）が集中して選ばれる傾向にある。ＶＩＰに大量の通知が集中した結果、ＶＩＰは通知を見なくなり、通知の意義が減殺される。大量の通知に対するいらだちは、ＶＩＰがライブ配信プラットフォームを離脱する原因にもなりうる。また、ＶＩＰでないユーザ（以下、ｎｏｎＶＩＰという）には通知が行き渡らないので視聴者数の増加も見込めない。

そこで、実施の形態に係るライブ配信システムでは、配信者視点ではなくユーザ視点あるいはフォロワー視点で通知を最適化する。予め、ユーザがフォローしている配信者（以下、フォロイー（followee）という）のそれぞれについて関心スコアを算出し、算出された関心スコアでフォロイーをソーティングする。そして、関心スコアの高いフォロイーを当該フォロワーの通知可能フォロイーとして登録しておく。その後、配信者によるライブ配信の開始を検出すると、当該配信者が通知可能フォロイーとして登録されているフォロワーに通知を送信する。これにより、ＶＩＰであっても重要なフォロイーからの通知は受け取りつつ、通知の数を確実に減らすことができる。その結果、ＶＩＰのライブ配信プラットフォームへの定着度を高めることができる。また、ｎｏｎＶＩＰでもフォローしておけば一定数の通知は届くので、配信者の露出機会も維持または向上することができる。

図７は、実施の形態に係るライブ配信システムにおけるユーザ視点の通知の最適化を示す模式図である。ユーザには、当該ユーザがフォローしている配信者であるフォロイーと、過去にライブ配信を視聴したがフォローはしていない配信者である非フォロイーと、が対応付けられている。システムは、ユーザの各フォロイーについて、当該フォロイーのライブ配信における当該ユーザから当該フォロイーへの貢献の度合いを示すパラメータを算出し、フィーチャとして取得する。フィーチャには、平均視聴レート、平均セッション、平均セッションレート、ユーザインタラクション（ギフト、コメント）などが含まれる。システムは、得られたフィーチャを分類モデルに入力する。分類モデルは、上記フィーチャを入力とし、ユーザによるフォロイーに対する関心の度合いを示す関心スコアを出力とする機械学習モデルである。関心スコアが高いほど、ユーザによるフォロイーに対する関心の度合いは高い。機械学習モデル自体は公知の機械学習技術を用いて実現されてもよい。本実施の形態ではユーザがＶＩＰであるかそうでないかで異なる分類モデルを用いる。ＶＩＰの場合はＶＩＰ分類モデルが用いられ、ｎｏｎＶＩＰの場合はｎｏｎＶＩＰ分類モデルが用いられる。

システムは、分類モデルが出力する関心スコアに関する所定の基準にしたがい、ユーザのフォロイーを通知可能フォロイーとそうでないフォロイーとに分ける。フォロイーの関心スコアがしきい値を上回る場合、当該フォロイーは通知可能フォロイーとして登録される。フォロイーが通知可能フォロイーとして登録されないのであれば、当該フォロイーは通知不可フォロイーとして登録される。あるいはまた、フォロイーの関心スコアがしきい値を下回る場合、当該フォロイーは通知不可フォロイーとして登録される。フォロイーが通知不可フォロイーとして登録されないのであれば、当該フォロイーは通知可能フォロイーとして登録される。いずれにせよ、ユーザによる通知可能フォロイーに対する関心の度合いは、そうでないフォロイーに対する関心の度合いよりも高くなる。

システムは、ユーザの通知可能フォロイーによる所定の活動をトリガーとして当該ユーザにプッシュ通知を送信する。その後、所定の再送基準が充たされると、システムは、当該ユーザに同等の内容のプッシュ通知を再送する。システムは、ユーザの通知不可フォロイーによる所定の活動が検出されても当該ユーザにはプッシュ通知を送信しない。

システムは、ユーザの非フォロイーが所定のフォロー推薦基準を充たすと、当該ユーザに当該非フォロイーをフォローするよう薦める通知を送信する。

このように、ユーザがフォローするフォロイーが通知可能フォロイーと通知不可フォロイーとに分けられ、通知不可フォロイーの所定の活動からは通知が届かなくなる。これにより、ユーザ視点で重要でない通知の数を減らしつつ、重要な通知は引き続き送信し続けることで通知を最適化することができる。

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

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

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

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

本明細書において「配信時間」は、ひとつのライブ配信に関連付けられたパラメータであって、当該ライブ配信が継続した期間の長さを指す。配信時間は、当該ライブ配信に視聴者がいるか否かとは無関係に算出される。
本明細書において「総配信時間」は、配信者に関連付けられたパラメータであって、所定の期間において対象の配信者が行ったライブ配信の配信時間を通算することで得られる時間である。
本明細書において「総視聴時間」は、視聴者と配信者とのペアに関連付けられたパラメータであって、所定の期間において当該視聴者が当該配信者のライブ配信を視聴した期間の長さ（view duration）を指す。ライブ配信が複数回に及ぶ場合は期間の長さを通算する。

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

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

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

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

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

ユーザ端末２０は、ユーザの像および音声を記録した動画データを生成してサーバ１０に提供する配信部１００と、サーバ１０から動画データを取得して再生する視聴部２００と、アクティブユーザによる要求を処理する配信外処理部４００と、を備える。ユーザは、配信を行う場合は配信部１００を、視聴を行う場合は視聴部２００を、視たいライブ配信を探したり配信者のプロフィールを視たりアーカイブを視たりする場合は配信外処理部４００を、それぞれ起動する。配信部１００がアクティブとなっているユーザ端末は配信者側、つまり動画データの生成側のユーザ端末であり、視聴部２００がアクティブとなっているユーザ端末は視聴者側、つまり動画データの再生側のユーザ端末であり、配信外処理部４００がアクティブとなっているユーザ端末はアクティブユーザのユーザ端末である。

配信部１００は、撮像制御部１０２と、音声制御部１０４と、動画送信部１０６と、配信側ＵＩ制御部１０８と、配信側通信部１１０と、を含む。撮像制御部１０２は図２では不図示のカメラと接続され、カメラによる撮像を制御する。撮像制御部１０２はカメラから画像データを取得する。音声制御部１０４は図２では不図示のマイクロフォンと接続され、マイクロフォンによる音声入力を制御する。音声制御部１０４は、マイクロフォンから音声データを取得する。動画送信部１０６は、撮像制御部１０２により取得された画像データおよび音声制御部１０４により取得された音声データを含む動画データを、ネットワークＮＷを介してサーバ１０に送信する。動画送信部１０６による動画データの送信はリアルタイムで行われる。すなわち、撮像制御部１０２および音声制御部１０４による動画データの生成と、生成された動画データの動画送信部１０６による送信と、は実質的に同時に行われる。

配信側ＵＩ制御部１０８は、配信者向けのＵＩを制御する。配信側ＵＩ制御部１０８は、図２では不図示のディスプレイと接続され、動画送信部１０６による送信対象となっている動画データを再生することにより動画像をディスプレイに表示させる。配信側ＵＩ制御部１０８は、図２では不図示のタッチパネルやキーボードやディスプレイなどの入力手段と接続され、それら入力手段を介して配信者による入力を取得する。配信側ＵＩ制御部１０８は、動画像に所定のフレーム画像を重畳させる。フレーム画像は、配信者から入力を受け付けるための様々なユーザインタフェースオブジェクト（以下、単にオブジェクトという）と、視聴者により入力されたコメントと、サーバ１０から取得した情報と、を含む。配信側ＵＩ制御部１０８は例えば配信者によるオブジェクトに対するタップ入力を受け付ける。

配信側通信部１１０は、ライブ配信中のサーバ１０との間の通信を制御する。配信側通信部１１０は、配信側ＵＩ制御部１０８が取得した配信者による入力の内容を、サーバ１０にネットワークＮＷを介して送信する。配信側通信部１１０は、ライブ配信に関連付けられた各種の情報をサーバ１０からネットワークＮＷを介して受信する。

視聴部２００は、視聴側ＵＩ制御部２０２と、視聴側通信部２０４と、を含む。視聴側通信部２０４は、ライブ配信中のサーバ１０との間の通信を制御する。視聴側通信部２０４は、ネットワークＮＷを介してサーバ１０から、配信者と視聴者とが参加するライブ配信に係る動画データを受信する。

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

配信外処理部４００は、配信外ＵＩ制御部４０２と、配信外通信部４０４と、を含む。配信外ＵＩ制御部４０２は、アクティブユーザ向けのＵＩを制御する。例えば、配信外ＵＩ制御部４０２は、現在参加可能なライブ配信のリストを表示してアクティブユーザによるライブ配信の選択を受け付けるライブ配信選択画面を生成し、ディスプレイに表示させる。配信外ＵＩ制御部４０２は、任意のユーザのプロフィール画面を生成し、ディスプレイに表示させる。配信外ＵＩ制御部４０２は、過去のライブ配信を録音・録画することにより生成されたアーカイブを再生する。

配信外通信部４０４は、ライブ配信外のサーバ１０との間の通信を制御する。配信外通信部４０４は、ネットワークＮＷを介してサーバ１０から、ライブ配信選択画面を生成するための情報や、プロフィール画面を生成するための情報や、アーカイブのデータを受信する。配信外通信部４０４は、アクティブユーザによる入力の内容を、ネットワークＮＷを介してサーバ１０に送信する。

図３は、図１のサーバ１０の機能および構成を示すブロック図である。サーバ１０は、配信情報提供部３０２と、中継部３０４と、ギフト処理部３０８と、支払い処理部３１０と、フォロー登録部３２２と、フォロイー処理部３２４と、ＶＩＰ分類モデル３２６と、ｎｏｎＶＩＰ分類モデル３２８と、通知制御部３３０と、再送制御部３３２と、推薦制御部３３４と、ストリームＤＢ３１４と、ユーザＤＢ３１８と、ギフトＤＢ３２０と、を備える。

図４は、図３のストリームＤＢ３１４の一例を示すデータ構造図である。ストリームＤＢ３１４は現在行われているライブ配信の情報を保持する。ストリームＤＢ３１４は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定するユーザＩＤである配信者ＩＤと、当該ライブ配信の視聴者を特定するユーザＩＤである視聴者ＩＤと、を対応付けて保持する。

本実施の形態に係るライブ配信システム１が提供するライブ配信プラットフォームでは、ユーザがライブ配信を行う場合そのユーザは配信者となり、また同じユーザが他のユーザが配信するライブ配信を視聴する場合は視聴者となる。したがって、配信者・視聴者の別は固定的なものではなく、あるとき配信者ＩＤとして登録されていたユーザＩＤが別のタイミングでは視聴者ＩＤとして登録されることもある。

図５は、図３のユーザＤＢ３１８の一例を示すデータ構造図である。ユーザＤＢ３１８は、ユーザに関する情報を保持する。ユーザＤＢ３１８は、ユーザを特定するユーザＩＤと、当該ユーザが有しているポイントと、当該ユーザに付与された報酬と、当該ユーザの当月配信回数と、当該ユーザの当月総配信時間と、当該ユーザがＶＩＰか否かを示すＶＩＰフラグと、当該ユーザのフォロイーを特定するフォロイーＩＤと、ライブ配信における当該ユーザから当該フォロイーへの貢献の度合いを示すパラメータと、当該フォロイーが当該ユーザの通知可能フォロイーであるか通知不可フォロイーであるかを示す通知可能フラグと、を対応付けて保持する。ユーザが複数の配信者をフォローしている場合、当該ユーザのユーザＩＤに対応付けて複数のフォロイーＩＤが登録される。

ポイントは、ライブ配信プラットフォーム内で流通する電子的価値である。ユーザはクレジットカードや他の決済手段によりポイントを購入する。報酬はライブ配信プラットフォーム内で定義される電子的価値であり、配信者がライブ配信プラットフォームの管理者から受け取る金銭の額を決めるための指標である。ライブ配信プラットフォームでは、ライブ配信内やライブ配信外で視聴者が配信者にギフトを贈ると、視聴者のポイントが消費され、併せて配信者の報酬が相応分だけ増加する。

当月配信回数は、現在の属する月の始めから現在までの間にユーザが行ったライブ配信の回数である。当月総配信時間は、現在の属する月の始めから現在までの間における総配信時間である。当月配信回数および当月総配信時間は不図示の更新部により更新されてもよい。

本実施の形態に係るライブ配信システム１では、ライブ配信ごとに、誰がいつライブ配信を開始していつ終了したか、そのライブ配信に誰がいつ視聴者として参加していつ退出したか、そのライブ配信において誰がいつどのコメントを投稿したか、誰がいつどのギフトを贈ったか、を示すログデータが取得され、保持される。上述の当月配信回数および当月総配信時間や総ギフトポイント、総コメント数、当月視聴回数、当月総視聴時間、トップスペンダーか否か、トップギフターか否かはこのログデータを参照することで算出または決定される。

ＶＩＰフラグについて、システムが課金額等に基づく所定のアルゴリズムにより自動でＶＩＰフラグを設定してもよいし、ライブ配信プラットフォームの管理者がＶＩＰフラグを設定してもよい。

ライブ配信におけるユーザからフォロイーへの貢献の度合いを示すパラメータは、当該ユーザが当該フォロイーに贈ったギフトのポイントの合計である総ギフトポイントと、当該ユーザが当該フォロイーのライブ配信で投稿したコメントの数の合計である総コメント数と、当該ユーザによる当該フォロイーのライブ配信の当月視聴回数および当月総視聴時間と、トップスペンダーか否かを示すフラグと、トップギフターか否かを示すフラグと、を含む。当月視聴回数は、現在の属する月の始めから現在までの間にユーザが視聴したフォロイーのライブ配信の数である。当月総視聴時間は、現在の属する月の始めから現在までの間にユーザが視聴したフォロイーのライブ配信に係る総視聴時間である。

トップスペンダー（top spender）は、対象のフォロイーに関するランキング（例えば、フォロイーに贈ったギフトの量のランキング）で所定順位（例えば、１０位や２０位）以内にランクインしたユーザを指す。ユーザが対象のフォロイーのトップスペンダーであればフラグはＹとなり、そうでなければＮとなる。

トップギフターは、対象のフォロイーのライブ配信でトップギフトを贈ったユーザを指す。ユーザが対象のフォロイーのトップギフターであればフラグはＹとなり、そうでなければＮとなる。トップギフトは、対象のフォロイーに贈られたギフトを個数でソーティングし、所定順位（例えば、１０位や２０位）以内にランクインしたギフトを指す。ギフトがトップギフトであるか否かにギフトの対価ポイントは関係しない。ギフトが廉価でも配信者に数多く贈られていれば当該ギフトは当該配信者のトップギフトとなり、逆にギフトが高価でも配信者にあまり贈られてなければ当該ギフトはトップギフトとはならない。後述のとおり、トップギフターであるか否かは、ＶＩＰ分類モデル３２６に入力されるフィーチャのひとつであるが、ｎｏｎＶＩＰ分類モデル３２８のフィーチャではない。これは、ＶＩＰは特定のお気に入りの配信者に特定のギフトを繰り返し贈り続ける傾向があるという本発明者の独自の気付きによる。ＶＩＰがフォロイーのトップギフターであれば当該ＶＩＰと当該フォロイーとの絆、つながりは強いと判断できる。

例えば、フォロイー「Ａ」が１００個のギフト「Ｘ」（対価ポイントは１００）、５０個のギフト「Ｙ」（対価ポイントは５００）および１０個のギフト「Ｚ」（対価ポイントは３０００）を受け取っているとする。この場合、ギフト「Ｘ」がトップギフトとなり、ギフト「Ｙ」、「Ｚ」はトップギフトではない。ＶＩＰ「Ｂ」がギフト「Ｚ」をフォロイー「Ａ」に贈り、ＶＩＰ「Ｃ」がギフト「Ｙ」をフォロイー「Ａ」に贈り、ＶＩＰ「Ｄ」がギフト「Ｘ」をフォロイー「Ａ」に贈った場合、ＶＩＰ「Ｄ」はフォロイー「Ａ」のトップギフターであるが、ＶＩＰ「Ｂ」「Ｃ」は、より高価なギフトを贈ったにもかかわらず、トップギフターとはならない。

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

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

図３に戻り、配信情報提供部３０２は、ネットワークＮＷを介して、配信者のユーザ端末２０からライブ配信の開始を求める開始要求を受け付けると、当該ライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者の配信者ＩＤと、をストリームＤＢ３１４に登録する。配信情報提供部３０２は、ネットワークＮＷを介して、アクティブユーザのユーザ端末の配信外通信部４０４からライブ配信に関する情報の提供要求を受けると、ストリームＤＢ３１４を参照して現在視聴可能なライブ配信のリストを生成する。配信情報提供部３０２は、ネットワークＮＷを介して、生成されたリストを要求元のユーザ端末に送信する。要求元のユーザ端末の配信外ＵＩ制御部４０２は、受信したリストに基づいてライブ配信選択画面を生成し、ユーザ端末のディスプレイに表示させる。

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

ユーザ端末の配信外ＵＩ制御部４０２は、後述の配信開始プッシュ通知を介してアクティブユーザからライブ配信の視聴開始指示を受け付けると、配信開始プッシュ通知に係るライブ配信のストリームＩＤを含む配信要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。配信情報提供部３０２は、受信した配信要求に含まれるストリームＩＤにより特定されるライブ配信の、要求元のユーザ端末への提供を開始する。配信情報提供部３０２は、当該ストリームＩＤの視聴者ＩＤに要求元のユーザ端末のアクティブユーザのユーザＩＤが含まれるようにストリームＤＢ３１４を更新する。これにより、アクティブユーザは選択されたライブ配信の視聴者となる。

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

ギフト処理部３０８は、ギフト使用信号に含まれるギフトＩＤで特定されるギフトの付与報酬に応じて配信者の報酬を増加させるようにユーザＤＢ３１８を更新する。ギフト処理部３０８は、ギフトＤＢ３２０を参照し、受信したギフト使用信号に含まれるギフトＩＤに対応する付与報酬を特定する。ギフト処理部３０８は、ギフト使用信号に含まれる配信者ＩＤに対応する報酬に、特定された付与報酬を加えるようユーザＤＢ３１８を更新する。ギフト処理部３０８は、使用されたギフトの情報を不図示のギフト情報保持部に登録する。ギフト情報保持部に保持される情報は後述のフィーチャの算出の際に使用される。

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

フォロー登録部３２２は、ユーザによる配信者のフォローを制御する。フォロー登録部３２２は、ネットワークＮＷを介してユーザ端末から、フォローを指示したユーザのユーザＩＤとフォローされた配信者の配信者ＩＤとを含むフォロー要求を受信する。視聴者がユーザ端末２０でライブ配信を視聴しているときにそのライブ配信の配信者をフォローする（または登録する）ための指示をユーザ端末２０に入力すると、ユーザ端末２０の視聴側通信部２０４はフォロー要求を生成し、フォロー登録部３２２に送信する。あるいはまた、アクティブユーザが配信者のプロフィール画面を閲覧しているときにその配信者をフォローするための指示をユーザ端末に入力すると、ユーザ端末の配信外通信部４０４はフォロー要求を生成し、フォロー登録部３２２に送信する。

フォロー登録部３２２は、フォローされた配信者がフォローを指示したユーザのフォロイーとして登録されるようユーザＤＢ３１８を更新する。フォロー登録部３２２は、ユーザＤＢ３１８において、フォロー要求に含まれる配信者ＩＤを、フォロー要求に含まれるユーザＩＤに対応するフォロイーＩＤに新規登録または追加する。

フォロイー処理部３２４は定期的に、ユーザのフォロイーごとに総ギフトポイント、総コメント数、当月視聴回数、当月総視聴時間を算出し、算出された値でユーザＤＢ３１８を更新する。フォロイー処理部３２４は、ＶＩＰフラグがＹとなっているユーザについて、各フォロイーがトップスペンダーか否かを判定し、その判定結果でユーザＤＢ３１８を更新する。フォロイー処理部３２４は、ＶＩＰフラグがＹとなっているユーザについて、各フォロイーがトップギフターか否かを判定し、その判定結果でユーザＤＢ３１８を更新する。

フォロイー処理部３２４は、ユーザのフォロイーを、ライブ配信プラットフォームにおけるフォロイーの所定の活動をトリガとしてサーバ１０が当該ユーザに配信開始プッシュ通知を送ることができるフォロイーである通知可能フォロイーと、そうでない通知不可フォロイーとに分ける。フォロイー処理部３２４は、各フォロイーについて機械学習モデルにより算出された関心スコアにしたがい、フォロイーを通知可能フォロイーと通知不可フォロイーとに分ける。フォロイー処理部３２４は、ライブ配信プラットフォームにおけるユーザの課金額に応じて異なる機械学習モデルを用いる。

分け方の一例として、フォロイー処理部３２４は、ユーザのフォロイーのなかから関心スコアに基づいて通知可能フォロイーを選択し、かつ、通知可能フォロイーとして選択されなかったフォロイーを通知不可フォロイーとして選択する。フォロイー処理部３２４は、選択の結果を当該ユーザに対応付けてユーザＤＢ３１８に登録する。フォロイー処理部３２４は、通知可能フォロイーとして選択されたフォロイーに対応する通知可能フラグをＹに設定し、通知不可フォロイーとして選択されたフォロイーに対応する通知可能フラグをＮに設定する。フォロイー処理部３２４における処理は後述する。

ＶＩＰ分類モデル３２６は、ＶＩＰとそのフォロイーとの間のＶＩＰ／非ＶＩＰ共通フィーチャと、ＶＩＰとそのフォロイーとの間のＶＩＰ専用フィーチャと、を入力とし、関心スコアを出力する機械学習モデルである。ＶＩＰ分類モデル３２６は、ＶＩＰに関する過去のデータを訓練データとするトレーニングにより生成される。

ｎｏｎＶＩＰ分類モデル３２８は、ｎｏｎＶＩＰとそのフォロイーとの間のＶＩＰ／非ＶＩＰ共通フィーチャを入力とし、関心スコアを出力する機械学習モデルである。ｎｏｎＶＩＰ分類モデル３２８は、ｎｏｎＶＩＰに関する過去のデータを訓練データとするトレーニングにより生成される。

ＶＩＰ／非ＶＩＰ共通フィーチャを以下に列挙する。
・総ギフトポイント
・総コメント数
・平均視聴レート
・平均セッション
・平均セッションレート
各ＶＩＰ／非ＶＩＰ共通フィーチャについて、その値が高いほどライブ配信におけるＶＩＰからフォロイーへの貢献の度合いも高い。これらの他、例えばＶＳライブ配信で対戦したことがあるか否か、やグループ配信で一緒に配信したことがあるか否か、や相互フォローが存在するか否か、をＶＩＰ／非ＶＩＰ共通フィーチャとして採用してもよい。

ＶＩＰとそのフォロイーとの間の平均視聴レートは、当該ＶＩＰによる当該フォロイーのライブ配信の当月視聴回数を、当該フォロイーの当月配信回数で除した値である。ＶＩＰとそのフォロイーとの間の平均セッションは、当該ＶＩＰによる当該フォロイーのライブ配信の当月総視聴時間を、当該ＶＩＰによる当該フォロイーのライブ配信の当月視聴回数で除した値である。ＶＩＰとそのフォロイーとの間の平均セッションレートは、当該ＶＩＰによる当該フォロイーのライブ配信の当月総視聴時間を、当該フォロイーの当月総配信時間で除した値である。

ＶＩＰ専用フィーチャを以下に列挙する。
・トップスペンダーか否か
・トップギフターか否か
各ＶＩＰ専用フィーチャについて、その値がＹであればライブ配信におけるＶＩＰからフォロイーへの貢献の度合いは比較的高く、Ｎであれば貢献の度合いは比較的低い。

図５の例で説明すると、ユーザ「ＵＳＲ１」とそのフォロイー「ＡＢＣ」との間のＶＩＰ／非ＶＩＰ共通フィーチャ、ＶＩＰ専用フィーチャは以下のとおりとなる。
・総ギフトポイント ＝ １００００
・総コメント数 ＝ １００
・平均視聴レート ＝ １０／１５ ＝ ０．６７
・平均セッション ＝ ３／１０ ＝ ０．３
・平均セッションレート ＝ ３／４ ＝ ０．７５
・トップスペンダーか否か ＝ Ｙ
・トップギフターか否か ＝ Ｙ

ユーザ「ＵＳＲ１」とそのフォロイー「ＤＥＦ」との間のＶＩＰ／非ＶＩＰ共通フィーチャ、ＶＩＰ専用フィーチャは以下のとおりとなる。
・総ギフトポイント ＝ ５０００
・総コメント数 ＝ ５０
・平均視聴レート ＝ ５／２０ ＝ ０．２５
・平均セッション ＝ １／５ ＝ ０．２
・平均セッションレート ＝ １／５ ＝ ０．２
・トップスペンダーか否か ＝ Ｎ
・トップギフターか否か ＝ Ｎ

フォロイー処理部３２４はユーザＤＢ３１８のＶＩＰフラグを参照し、ユーザ「ＵＳＲ１」がＶＩＰであると判定する。フォロイー処理部３２４は判定結果にしたがい、ＶＩＰ分類モデル３２６、ｎｏｎＶＩＰ分類モデル３２８のうちＶＩＰ分類モデル３２６を選択する。フォロイー処理部３２４は、フォロイー「ＡＢＣ」について上記のように算出されたＶＩＰ／非ＶＩＰ共通フィーチャおよびＶＩＰ専用フィーチャを、選択されたＶＩＰ分類モデル３２６に入力する。ＶＩＰ分類モデル３２６は、入力されたフィーチャに対応する関心スコアを出力する。例えばＶＩＰ分類モデル３２６はフォロイー「ＡＢＣ」のＶＩＰ／非ＶＩＰ共通フィーチャおよびＶＩＰ専用フィーチャの値に対応して関心スコア＝０．９を出力する。関心スコアは、０から１の範囲で変化し、大きいほど関心の度合いが大きくなるよう設定される。同様に、フォロイー処理部３２４は、フォロイー「ＤＥＦ」について上記のように算出されたＶＩＰ／非ＶＩＰ共通フィーチャおよびＶＩＰ専用フィーチャを、選択されたＶＩＰ分類モデル３２６に入力する。例えばＶＩＰ分類モデル３２６はフォロイー「ＤＥＦ」のＶＩＰ／非ＶＩＰ共通フィーチャおよびＶＩＰ専用フィーチャの値に対応して関心スコア＝０．２を出力する。

フォロイー処理部３２４では通知可能・通知不可の判定基準として関心スコアのしきい値＝０．５が設定されている。フォロイー処理部３２４は、フォロイー「ＡＢＣ」について、関心スコア＝０．９がしきい値を上回るので通知可能フォロイーであると判定する。フォロイー処理部３２４は、ユーザ「ＵＳＲ１」のフォロイー「ＡＢＣ」の通知可能フラグが「Ｙ」となるようユーザＤＢ３１８を更新する。フォロイー処理部３２４は、フォロイー「ＤＥＦ」について、関心スコア＝０．２がしきい値を下回るので通知不可フォロイーであると判定する。フォロイー処理部３２４は、ユーザ「ＵＳＲ１」のフォロイー「ＤＥＦ」の通知可能フラグが「Ｎ」となるようユーザＤＢ３１８を更新する。

ユーザ「ＵＳＲ２」とそのフォロイー「ＡＢＣ」との間のＶＩＰ／非ＶＩＰ共通フィーチャは以下のとおりとなる。
・総ギフトポイント ＝ １０００
・総コメント数 ＝ １０
・平均視聴レート ＝ ２／１５ ＝ ０．１３
・平均セッション ＝ ０．５／２ ＝ ０．２５
・平均セッションレート ＝ ０．５／４ ＝ ０．１３

ユーザ「ＵＳＲ２」とそのフォロイー「ＤＥＦ」との間のＶＩＰ／非ＶＩＰ共通フィーチャは以下のとおりとなる。
・総ギフトポイント ＝ ３０００
・総コメント数 ＝ ３０
・平均視聴レート ＝ ５／２０ ＝ ０．２５
・平均セッション ＝ ２／５ ＝ ０．４
・平均セッションレート ＝ ２／５ ＝ ０．４

フォロイー処理部３２４はユーザＤＢ３１８のＶＩＰフラグを参照し、ユーザ「ＵＳＲ２」がｎｏｎＶＩＰであると判定する。フォロイー処理部３２４は判定結果にしたがい、ＶＩＰ分類モデル３２６、ｎｏｎＶＩＰ分類モデル３２８のうちｎｏｎＶＩＰ分類モデル３２８を選択する。フォロイー処理部３２４は、フォロイー「ＡＢＣ」について上記のように算出されたＶＩＰ／非ＶＩＰ共通フィーチャを、選択されたｎｏｎＶＩＰ分類モデル３２８に入力する。ｎｏｎＶＩＰ分類モデル３２８は、入力されたフィーチャに対応する関心スコアを出力する。例えばｎｏｎＶＩＰ分類モデル３２８はフォロイー「ＡＢＣ」のＶＩＰ／非ＶＩＰ共通フィーチャに対応して関心スコア＝０．２を出力する。同様に、フォロイー処理部３２４は、フォロイー「ＤＥＦ」について上記のように算出されたＶＩＰ／非ＶＩＰ共通フィーチャを、選択されたｎｏｎＶＩＰ分類モデル３２８に入力する。例えばｎｏｎＶＩＰ分類モデル３２８はフォロイー「ＤＥＦ」のＶＩＰ／非ＶＩＰ共通フィーチャの値に対応して関心スコア＝０．６を出力する。

フォロイー処理部３２４は、フォロイー「ＡＢＣ」について、関心スコア＝０．２がしきい値を下回るので通知不可フォロイーであると判定する。フォロイー処理部３２４は、ユーザ「ＵＳＲ２」のフォロイー「ＡＢＣ」の通知可能フラグが「Ｎ」となるようユーザＤＢ３１８を更新する。フォロイー処理部３２４は、フォロイー「ＤＥＦ」について、関心スコア＝０．６がしきい値を上回るので通知可能フォロイーであると判定する。フォロイー処理部３２４は、ユーザ「ＵＳＲ２」のフォロイー「ＤＥＦ」の通知可能フラグが「Ｙ」となるようユーザＤＢ３１８を更新する。

通知制御部３３０は、ライブ配信プラットフォームにおける配信者の所定の活動を検出すると、当該配信者が通知可能フォロイーとして登録されているユーザにプッシュ通知を送信し、かつ、当該配信者がフォロイーとして登録されているが通知可能フォロイーとしては登録されていないユーザにはプッシュ通知を送信しない。本実施の形態では所定の活動はライブ配信の開始であるが、これに限られず、所定の活動は例えば配信者によるライブ配信の予定の登録であってもよいし、配信者による投稿であってもよいし、ライブ配信プラットフォームにおけるライブ配信に関する活動であってもよい。所定の活動は、配信者自身による通知の送信とは異なる。

通知制御部３３０は、ネットワークＮＷを介して、配信者のユーザ端末２０から開始要求を受け付けると、ユーザＤＢ３１８を参照し、開始要求に係る配信者の配信者ＩＤと一致するフォロイーＩＤに対応する通知可能フラグおよびユーザＩＤを特定する。すなわち、通知制御部３３０は、開始要求に係る配信者のフォロワーのユーザＩＤを特定する。通知制御部３３０は、特定された通知可能フラグが「Ｙ」の場合、特定されたユーザＩＤを通知対象のユーザのユーザＩＤに含め、特定された通知可能フラグが「Ｎ」の場合、特定されたユーザＩＤを通知対象のユーザのユーザＩＤに含めない。通知制御部３３０は、通知対象のユーザのユーザ端末に、開始要求に係る配信者のライブ配信の開始を知らせる配信開始プッシュ通知を送信するための処理を行う。配信開始プッシュ通知は通知制御部３３０やサーバ１０が直接ユーザ端末に送信してもよいし、サーバ１０とは異なるプッシュ通知サーバに依頼し、当該プッシュ通知サーバがユーザ端末に送信するようにしてもよい。

図５の例で、配信者「ＡＢＣ」がライブ配信を開始した場合、通知制御部３３０は、通知可能フラグとユーザＩＤの組として（「Ｙ」、「ＵＳＲ１」）、（「Ｎ」、「ＵＳＲ５」）、（「Ｎ」、「ＵＳＲ２」）、（「Ｙ」、「ＵＳＲ６」）を特定する。通知制御部３３０は、「ＵＳＲ１」および「ＵＳＲ６」を通知対象のユーザのユーザＩＤに含める。通知制御部３３０は、ユーザ「ＵＳＲ１」、「ＵＳＲ６」のユーザ端末に、配信者「ＡＢＣ」のライブ配信の開始を知らせる配信開始ブッシュ通知を送信するための処理を行う。この場合、ユーザ「ＵＳＲ１」、「ＵＳＲ５」、「ＵＳＲ２」、「ＵＳＲ６」はいずれも配信者「ＡＢＣ」をフォローしているが、これら４名のフォロワーのうち「ＵＳＲ１」、「ＵＳＲ６」には配信開始プッシュ通知が送信され、「ＵＳＲ２」、「ＵＳＲ５」には配信開始プッシュ通知が送信されない。

再送制御部３３２は、ユーザの通知可能フォロイーがライブ配信を開始した後、当該ユーザが当該ライブ配信に参加せずに所定の期間（例えば、５分間、１５分間または１時間）が経過した場合、当該ユーザに再度配信開始プッシュ通知を送信する。これにより、フォロワーは、重要なフォロイーのライブ配信をより確実に視聴できるようになり、見逃す確率を低減できる。

推薦制御部３３４は、ユーザのフォロイーとして登録されていない配信者が所定の推薦基準を充たすと、当該ユーザに当該配信者をフォローするよう薦める通知を送信する。

以上の構成によるライブ配信システム１の動作を説明する。
図８は、フォロイー処理部３２４におけるフォロイー分類処理の流れを示すフローチャートである。フォロイー処理部３２４は定期的に、例えば１日１回や１時間に１回の頻度で、ユーザＤＢ３１８に登録されている全てのユーザＩＤを対象にフォロイー分類処理を行う。フォロイー処理部３２４はユーザＤＢ３１８を参照し、フォロイー分類処理の対象となるユーザを選択する（Ｓ２０２）。フォロイー処理部３２４は、ユーザＤＢ３１８に登録されているユーザＩＤを上から順番に選択していってもよいし、前回選択されてから所定期間が経過したユーザＩＤを選択してもよい。

フォロイー処理部３２４は、処理対象のユーザにフォロイーが存在するか否かを判定する（Ｓ２０４）。フォロイー処理部３２４はユーザＤＢ３１８を参照し、処理対象のユーザＩＤに対応してフォロイーＩＤが登録されていなければフォロイーが存在しないと判定し（Ｓ２０４のＮ）、処理をステップＳ２０２に戻す。フォロイー処理部３２４は、処理対象のユーザＩＤに対応してフォロイーＩＤが登録されていれば（Ｓ２０４のＹ）、全てのフォロイーが処理されるまで以下の処理を繰り返す。フォロイー処理部３２４は、処理対象のユーザＩＤに対応して登録されているフォロイーのなかから処理対象のフォロイーを選択する（Ｓ２０６）。フォロイー処理部３２４は、処理対象のユーザＩＤに対応して登録されているフォロイーＩＤを順番に選択していってもよい。フォロイー処理部３２４は、ステップＳ２０６で選択された処理対象のフォロイーが除外条件を充たすか否かを判定する（Ｓ２０８）。除外条件は、通知可能・通知不可の分類から除外すべきユーザまたはフォロイーを規定する条件である。除外条件は、（１）処理対象のユーザが処理対象のフォロイーをフォローしてから所定期間が経過していない、または（２）処理対象のユーザがライブ配信プラットフォームに登録されてから所定期間が経過していない、ときに充たされる。フォロイー処理部３２４は、除外条件が充たされる場合（Ｓ２０８のＹ）、処理対象のフォロイーを通知可能フォロイーとしてユーザＤＢ３１８に登録する（Ｓ２２０）。このように除外条件を設けることで、ユーザが配信者をフォローしてから所定期間内は当該ユーザに当該配信者の配信開始プッシュ通知を確実に届けることができる。また、ユーザがライブ配信プラットフォームに登録してから所定期間内は当該ユーザに確実に配信開始プッシュ通知を届けることができる。また、このような所定期間を設けることでフィーチャ算出の元となるログデータを十分に集めることができ、出力される関心スコアの精度を高めることができる。

フォロイー処理部３２４は、除外条件が充たされない場合（Ｓ２０８のＮ）、処理対象のユーザがＶＩＰか否かを判定する（Ｓ２１０）。フォロイー処理部３２４はユーザＤＢ３１８に登録されている処理対象のユーザＩＤのＶＩＰフラグが「Ｙ」の場合（Ｓ２１０のＶＩＰ）、処理対象のフォロイーのフィーチャをＶＩＰ分類モデル３２６に入力する（Ｓ２１２）。フォロイー処理部３２４はユーザＤＢ３１８に登録されている処理対象のユーザＩＤのＶＩＰフラグが「Ｎ」の場合（Ｓ２１０の非ＶＩＰ）、処理対象のフォロイーのフィーチャをｎｏｎＶＩＰ分類モデル３２８に入力する（Ｓ２１４）。

フォロイー処理部３２４は、ＶＩＰ分類モデル３２６（Ｓ２１２の場合）またはｎｏｎＶＩＰ分類モデル３２８（Ｓ２１４の場合）が出力する関心スコアがしきい値を上回るか否かを判定する（Ｓ２１６）。上回る場合（Ｓ２１６のＹ）、処理はステップＳ２２０に進む。上回らない場合（Ｓ２１６のＮ）、フォロイー処理部３２４は処理対象のフォロイーを通知不可フォロイーとしてユーザＤＢ３１８に登録する（Ｓ２１８）。処理対象のユーザの全てのフォロイーが処理された後、処理はステップＳ２０２に戻る。

図９は、サーバ１０における配信開始プッシュ通知の送信および再送処理の流れを示すフローチャートである。通知制御部３３０は、配信者によるライブ配信の開始を検出する（Ｓ２３０）。通知制御部３３０は、配信者のユーザ端末２０から開始要求を受け付けるとライブ配信の開始を検出する。通知制御部３３０は、ユーザＤＢ３１８のフォロイーＩＤおよび通知可能フラグを参照することで、ライブ配信を開始した配信者が通知可能フォロイーとして登録されているユーザを特定する（Ｓ２３２）。通知制御部３３０は、ステップＳ２３２で特定されたユーザのユーザ端末にネットワークＮＷを介して、ライブ配信の開始に係る配信開始プッシュ通知を送信する（Ｓ２３４）。

再送制御部３３２は、ステップＳ２３２で特定されたユーザが配信開始プッシュ通知に係るライブ配信に参加したか否かを判定する（Ｓ２３６）。参加した場合（Ｓ２３６のＹ）、処理は終了する。参加していない場合（Ｓ２３６のＮ）、再送制御部３３２は、配信開始プッシュ通知に係るライブ配信の開始から所定の期間が経過したか否かを判定する（Ｓ２３８）。経過していない場合（Ｓ２３８のＮ）、処理はステップＳ２３６に戻る。経過した場合（Ｓ２３８のＹ）、再送制御部３３２は、ステップＳ２３２で特定されたユーザのユーザ端末にネットワークＮＷを介して、配信開始プッシュ通知を再送する（Ｓ２４０）。

図１０は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８の代表画面図である。ライブ配信ルーム画面６０８は、配信者のユーザ端末２０で生成された動画像をリアルタイムで表示する。ライブ配信ルーム画面６０８は、サーバ１０から受信した動画データを再生することにより得られる配信者の動画像６１０と、ギフトオブジェクト６１２と、コメント入力領域６１６と、コメント表示領域６１８と、視聴終了ボタン６２０と、フォローボタン６２２と、を有する。視聴側ＵＩ制御部２０２は、動画データを再生することにより得られる動画像６１０に、他のオブジェクト、すなわちギフトオブジェクト６１２、コメント入力領域６１６、コメント表示領域６１８、視聴終了ボタン６２０、フォローボタン６２２を重畳表示することによりライブ配信ルーム画面６０８を生成する。

コメント表示領域６１８は、視聴者により入力されたコメントと、他の視聴者により入力されたコメントと、システムからの通知と、を含みうる。システムからの通知は、配信者に誰がどのギフトを贈ったかを示す情報を含むことができる。視聴側ＵＩ制御部２０２はサーバ１０から受信した他の視聴者のコメントおよびシステムからの通知を含むコメント表示領域６１８を生成し、生成されたコメント表示領域６１８をライブ配信ルーム画面６０８に含める。

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

視聴終了ボタン６２０は、ライブ配信の視聴を止めるための指示を視聴者から受け付けるためのオブジェクトである。

ユーザ端末３０の視聴側ＵＩ制御部２０２は、フォローボタン６２２へのタップを検出すると、それを視聴者が配信者をフォローするための指示として受け付ける。視聴側通信部２０４は、指示を受け付けると、フォローを指示した視聴者の視聴者ＩＤとフォローされた配信者の配信者ＩＤとを含むフォロー要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０においてフォロー要求に係るフォローの登録処理が完了すると、フォローボタン６２２は「フォロー中」というテキストを表示するオブジェクトに置き換えられてもよい。

図１１は、アクティブユーザのユーザ端末のディスプレイに表示される配信開始プッシュ通知６５２を含む画面６５０の代表画面図である。配信開始プッシュ通知６５２は、アクティブユーザがフォローしている配信者がライブ配信を開始した旨を示すテキストと、参加ボタン６５４と、を有する。配信外ＵＩ制御部４０２は、参加ボタン６５４へのタップを検出すると、それをアクティブユーザによるライブ配信の視聴開始指示として受け付ける。配信外通信部４０４は、視聴開始指示を受け付けると、配信開始プッシュ通知６５２に係るライブ配信のストリームＩＤを含む配信要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。

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

本実施の形態に係るライブ配信システム１によると、フォロワーにとって重要な配信開始プッシュ通知の受領継続を可能としつつ、当該フォロワーが受け取る配信開始プッシュ通知の数を抑制することができる。これにより、フォロワーはより快適にライブ配信プラットフォームを利用できるようになる。

ユーザは配信者をいったんフォローしてしまうと、当該配信者への興味・関心が薄れてもフォロー自体は外しにくく感じるものである。したがって、ライブ配信プラットフォームを長く使うほどフォロイーが増えていき、それに比例して配信開始プッシュ通知の数も増えていく。配信開始プッシュ通知が増えすぎると邪魔に感じられるようになり、見られないまま放置または消去されることも増える。本実施の形態では興味・関心が薄れたフォロイーからの配信開始プッシュ通知が自然に無くなっていくので、ユーザがプッシュ通知増大に関して感じるストレスを軽減または除去できる。加えて、ユーザ、特にＶＩＰはフォロー数の増加によるプッシュ通知の増加を気にしなくてもよくなるので、配信者をより気軽にフォローできるようになる。その結果、ライブ配信プラットフォームにおいてフォローしやすい環境が醸成され、フォロー数の増大は配信者のモチベーション向上に寄与する。

本実施の形態に係るライブ配信システム１では、ＶＩＰ用のＶＩＰ分類モデル３２６とｎｏｎＶＩＰ用のｎｏｎＶＩＰ分類モデル３２８とが用いられる。ＶＩＰとｎｏｎＶＩＰとで異なるモデルを用いることで、ライブ配信プラットフォームにおいて異なる振る舞いを見せるＶＩＰ、ｎｏｎＶＩＰのそれぞれに適したモデルを構築することができる。

本実施の形態に係るライブ配信システム１では、通知不可フォロイーを設けることでプッシュ通知の総数を低減することができ、プッシュ通知のリソース（サーバ、外部サービスなど）をより有効に活用することができる。また、プッシュ通知が閲覧される可能性を高めることができ、それにより再視聴確率を高め、ユーザのリテンション向上を図ることができる。

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

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

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

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

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

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

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

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

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

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

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

実施の形態では、ユーザが関心対象として登録した配信者である関心対象配信者の例としてユーザがフォローした配信者であるフォロイーを採用したが、これに限られず、関心対象配信者をユーザがお気に入り登録した配信者やユーザがお友達登録した配信者とする場合にも本実施の形態に係る技術的思想を適用可能である。

実施の形態では、機械学習モデルを用いて関心スコアを算出する場合を説明したが、これに限られず、所定の数式を用いて関心スコアを算出してもよいし、ルールベースで関心スコアを算出してもよい。

実施の形態では、通知可能フォロイーか通知不可フォロイーかを分ける基準として関心スコアとしきい値との大小関係を用いたが、これに限られず、例えば算出された関心スコアでフォロイーをソーティングし、上位Ｎ人（Ｎは自然数）を通知可能フォロイーとし、残りを通知不可フォロイーとしてもよい。

実施の形態では、通知可能フォロイーに配信開始プッシュ通知を再送する場合を説明したが、これに限られず、例えば通知可能フォロイーのうち関心スコアのより高い一部にのみ配信開始プッシュ通知を再送するよう構成してもよい。

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

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

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

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

Claims (9)

1. ライブ配信プラットフォームに係るサーバであって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持する保持手段と、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分ける処理手段と、を備え、
   前記処理手段は、ライブ配信におけるユーザから関心対象配信者への貢献の度合いを示すパラメータを入力とする機械学習モデルが出力するスコアに基づいて通知可能関心対象配信者を選択し、
   前記処理手段は、前記ライブ配信プラットフォームにおけるユーザの課金額に応じて異なる機械学習モデルを用いるサーバ。
2. 前記処理手段は、ユーザの関心対象配信者のなかから通知可能関心対象配信者を選択し、かつ、選択の結果を当該ユーザに対応付けて前記保持手段に登録し、
   前記サーバはさらに、
   前記ライブ配信プラットフォームにおける配信者の前記所定の活動を検出すると、当該配信者が通知可能関心対象配信者として登録されているユーザに通知を送信し、かつ、当該配信者が関心対象配信者として登録されているが通知可能関心対象配信者としては登録されていないユーザには通知を送信しない送信手段を備える請求項１に記載のサーバ。
3. 前記処理手段は、所定の基準にしたがい、ユーザの関心対象配信者を通知可能関心対象配信者とそうでない関心対象配信者とに分け、
   前記所定の基準は、ユーザによる通知可能関心対象配信者に対する関心の度合いが、そうでない関心対象配信者に対する関心の度合いよりも高くなるよう設定される請求項１に記載のサーバ。
4. 前記所定の活動はライブ配信の開始である請求項１に記載のサーバ。
5. ライブ配信プラットフォームに係るサーバであって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持する保持手段と、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分ける処理手段と、
   ユーザの関心対象配信者として登録されていない配信者が所定の推薦基準を充たすと、当該ユーザに当該配信者を関心対象として登録するよう薦める通知を送信する手段と、を備えるサーバ。
6. ライブ配信プラットフォームに係るサーバであって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持する保持手段と、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分ける処理手段と、
   ユーザの通知可能関心対象配信者がライブ配信を開始した後、当該ユーザが当該ライブ配信に参加せずに所定の期間が経過した場合、当該ユーザに再度通知を送信する再送手段と、を備えるサーバ。
7. ライブ配信プラットフォームに係るサーバで実行される方法あって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持手段に保持することと、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分けることと、を含み、
   前記分けることは、ライブ配信におけるユーザから関心対象配信者への貢献の度合いを示すパラメータを入力とする機械学習モデルが出力するスコアに基づいて通知可能関心対象配信者を選択することを含み、
   前記分けることは、前記ライブ配信プラットフォームにおけるユーザの課金額に応じて異なる機械学習モデルを用いることを含む方法。
8. ライブ配信プラットフォームに係るサーバで実行される方法あって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持手段に保持することと、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分けることと、
   ユーザの関心対象配信者として登録されていない配信者が所定の推薦基準を充たすと、当該ユーザに当該配信者を関心対象として登録するよう薦める通知を送信することと、を含む方法。
9. ライブ配信プラットフォームに係るサーバで実行される方法あって、
   前記ライブ配信プラットフォームのユーザを特定するユーザＩＤと、当該ユーザが関心対象として登録した配信者である関心対象配信者を特定する関心対象配信者ＩＤと、を対応付けて保持手段に保持することと、
   ユーザの関心対象配信者を、前記ライブ配信プラットフォームにおける関心対象配信者の所定の活動をトリガとして前記サーバが当該ユーザに通知を送ることができる関心対象配信者である通知可能関心対象配信者と、そうでない関心対象配信者とに分けることと、 ユーザの通知可能関心対象配信者がライブ配信を開始した後、当該ユーザが当該ライブ配信に参加せずに所定の期間が経過した場合、当該ユーザに再度通知を送信することと、を含む方法。

Images