特開 2023-163118 通知のためのシステム、方法、及びコンピュータ可読媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023163118

(43)【公開日】2023-11-09

(54)【発明の名称】通知のためのシステム、方法、及びコンピュータ可読媒体

(51)【国際特許分類】

   H04N 21/258 20110101AFI20231101BHJP

   H04N 21/235 20110101ALI20231101BHJP

   H04L 67/55 20220101ALI20231101BHJP

   H04L 67/1396 20220101ALI20231101BHJP

【ＦＩ】

H04N21/258

H04N21/235

H04L67/55

H04L67/1396

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022186587

(22)【出願日】2022-11-22

(62)【分割の表示】P 2022073243の分割

【原出願日】2022-04-27

(71)【出願人】

【識別番号】517287224

【氏名又は名称】１７ＬＩＶＥ株式会社

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(72)【発明者】

【氏名】陳宏典

(72)【発明者】

【氏名】蔡幸祐

(72)【発明者】

【氏名】李睿

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164FA06

5C164SA54S

5C164SB08P

5C164SC11P

5C164YA10

5C164YA11

(57)【要約】      （修正有）

【課題】ライブストリーミングプラットフォームの運用をより向上させるライブストリーミング番組の通知のための方法、システム及びコンピュータ可読媒体を提供する。
【解決手段】ライブストリーミングサービスについての通信プロセスは、ライブストリーミング番組に関連するユーザのリストを取得する工程と、ユーザのリストにおける第１のユーザの第１の貢献度スコアを取得する工程と、第１の貢献度スコアに基づき、第１のユーザにライブストリーミング番組について通知するための第１の通知要求を送信する工程と、を含む。第１の貢献度スコアは、第１のユーザの行動に基づいて決定する。
【選択図】図３

【特許請求の範囲】

【請求項1】

ライブストリーミング番組の通知方法であって、
前記ライブストリーミング番組に関連するユーザのリストを取得する工程と、
前記ユーザのリストにおける第１のユーザの第１の貢献度スコアを取得する工程と、
前記第１の貢献度スコアに基づき、前記第１のユーザに前記ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、
を含み、そのうち、前記第１の貢献度スコアが、前記第１のユーザの行動に基づいて決定される、ことを特徴とする、ライブストリーミング番組の通知方法。

【請求項2】

さらに、
前記ユーザのリストにおける第２のユーザの第２の貢献度スコアを取得する工程と、
前記第１の貢献度スコアが前記第２の貢献度スコアより高いと判定する工程と、
前記第２の貢献度スコアに基づき、前記第２のユーザに前記ライブストリーミング番組について通知するための第２の通知要求を送信する工程と、
を含み、そのうち、前記第２の貢献スコアが、前記第２のユーザの行動に基づいて決定され、前記第１の通知要求は、前記第２の通知要求よりも高い優先度で送信される、ことを特徴とする、請求項１に記載のライブストリーミング番組の通知方法。

【請求項3】

前記第１の通知要求が、前記第２の通知要求より早く送信される、ことを特徴とする、請求項２に記載のライブストリーミング番組の通知方法。

【請求項4】

さらに、
前記ライブストリーミング番組を提供するバックエンドサーバのパラメーターを取得する工程と、
前記パラメーターが所定の閾値以下であると判定する工程と、
を含む、ことを特徴とする、請求項２に記載のライブストリーミング番組の通知方法。

【請求項5】

さらに、
前記第１の通知要求と前記第２の通知要求を受信するように構成された通知サーバのパラメーターを取得する工程と、
前記パラメーターが所定の閾値以下であると判定する工程と、
を含む、ことを特徴とする、請求項２に記載のライブストリーミング番組の通知方法。

【請求項6】

さらに、
前記ユーザのリストにおける第２のユーザの第２の貢献度スコアを取得する工程と、
前記第１の貢献度スコアが前記第２の貢献度スコアより高いと判定する工程と、
前記ライブストリーミング番組を提供するバックエンドサーバのパラメーターを取得する工程と、
前記パラメーターが所定の閾値より大きいと判定する工程と、
前記第２のユーザに前記ライブストリーミング番組を通知するための第２の通知要求を所定の期間送信しないことを決定する工程と、
を含み、そのうち、前記第２の貢献度スコアが、前記２のユーザの行動に基づいて決定される、ことを特徴とする、請求項１に記載のライブストリーミング番組の通知方法。

【請求項7】

前記ライブストリーミング番組を提供するプラットフォームにおける前記第１のユーザのコメント行動、贈り物送信行動、購入行動、視聴行動、ログイン行動、または交流行動に基づいて、前記第１の貢献度スコアが決定される、ことを特徴とする、請求項１に記載のライブストリーミング番組の通知方法。

【請求項8】

前記第１の貢献度スコアが、第２のユーザの行動と相関性がある、ことを特徴とする、請求項１に記載のライブストリーミング番組の通知方法。

【請求項9】

さらに、
前記ユーザのリストにおける各ユーザの貢献度スコアを取得する工程と、
各ユーザの貢献度スコアに基づき、前記ユーザの通知優先度データを生成する工程と、
前記ユーザの情報と前記通知優先度データを送信する工程と、
を含む、ことを特徴とする、請求項１に記載のライブストリーミング番組の通知方法。

【請求項10】

ライブストリーミングデータの通知システムであって、１以上のプロセッサを含み、そのうち、前記１以上のプロセッサが機械可読命令を実行して、
前記ライブストリーミング番組に関連するユーザのリストを取得する工程と、
前記ユーザのリストにおける第１のユーザの第１の貢献度スコアを取得する工程と、
前記第１の貢献度スコアに基づき、前記第１のユーザに前記ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、
を実行し、そのうち、前記第１の貢献度スコアが、前記第１のユーザの行動に基づいて決定される、ことを特徴とする、ライブストリーミングデータの通知システム。

【請求項11】

ライブストリーミング番組について通知するためのプログラムを含む非一時的なコンピュータ可読媒体であって、そのうち、前記プログラムが、１以上のコンピュータに、
前記ライブストリーミング番組に関連するユーザのリストを取得する工程と、
前記ユーザのリストにおける第１のユーザの第１の貢献度スコアを取得する工程と、
前記第１の貢献度スコアに基づき、前記第１のユーザに前記ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、
を実行させ、そのうち、前記第１の貢献度スコアが、前記第１のユーザの行動に基づいて決定される、ことを特徴とする、コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストリーミングデータの通知に関し、特に、ライブストリーミングデータの通知に関する。

【背景技術】

【0002】

インターネット上でのリアルタイムのデータ共有は、日常生活にも浸透している。さまざまなプラットフォームやプロバイダーがライブストリーミング番組のサービスを提供しており、競争も激しい。コンテンツプロバイダーにとって重要な機能の１つが、新たに開始されたライブストリーミング番組をユーザに通知するために設定される、通知プッシュサービスである。

【発明の概要】

【0003】

本発明の一実施態様による方法は、１以上のコンピュータによって実行されるライブストリーミング番組の通知方法であって、ライブストリーミング番組に関連するユーザのリストを取得する工程と、当該ユーザのリストにおける第１のユーザの第１の貢献スコアを取得する工程と、当該第１の貢献度スコアに基づき、当該第１のユーザに当該ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、を含む。当該第１の貢献度スコアは、当該第１のユーザの行動に基づいて決定される。

【0004】

本発明の一実施態様によるシステムは、ライブストリーミング番組の通知のためのシステムであって、１以上のコンピュータプロセッサを含み、当該１以上のコンピュータプロセッサは、機械可読命令を実行して、当該ライブストリーミング番組に関連するユーザのリストを取得する工程と、当該ユーザのリストにおける第１のユーザの第１の貢献スコアを取得する工程と、当該第１の貢献度スコアに基づき、当該第１のユーザに当該ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、を実行する。当該第１の貢献度スコアは、当該第１のユーザの行動に基づいて決定される。

【0005】

本発明の一実施態様によるコンピュータ可読媒体は、ライブストリーミング番組の通知のプログラムを含む非一時的なコンピュータ可読媒体であり、当該プログラムが１以上のコンピュータに、当該ライブストリーミング番組に関連するユーザのリストを取得する工程と、当該ユーザのリストにおける第１のユーザの第１の貢献スコアを取得する工程と、当該第１の貢献度スコアに基づき、当該第１のユーザに当該ライブストリーミング番組について通知するための第１の通知要求を送信する工程と、を実行させる。当該第１の貢献度スコアは、当該第１のユーザの行動に基づいて決定される。

【図面の簡単な説明】

【0006】

【図1】従来のライブストリーミングサービスに関する通知プロセスを示す例示的シーケンス図である。

【図2】本発明の一部の実施態様に基づく通信システムの構成を示す概略図である。

【図3】本発明の一部の実施態様に基づくライブストリーミングサービスについての通信プロセスを示す例示的なシーケンス図である。

【図4】本発明の一部の実施態様に基づく通信システムの構成を示す概略図である。

【図5】本発明の一部の実施態様に基づく通知を示す例示的なフローチャートである。

【図6】本発明の一部の実施態様に基づく通知を示す例示的なフローチャートである。

【図7】図４に示す視聴者テーブル３０４の例示的データ構造である。

【図8】図４に示す貢献度テーブル３０６の例示的データ構造である。

【図9】図４に示す優先度テーブル３０８の例示的データ構造である。

【図10】本発明の一部の実施態様に基づく優先度テーブルの例示的データ構造である。

【図11】本発明の一部の実施態様に基づく優先度テーブルの例示的データ構造である。

【図12】本発明の一部の実施態様に基づくライブストリーミングサービスについての通信プロセスを示す例示的なシーケンス図である。

【図13】図４に示すパラメーター閾値テーブル３１０の例示的データ構造である。

【発明を実施するための形態】

【0007】

通知サービスは、適切な視聴者がコンテンツの開始時に適切なコンテンツの通知を受けられるように、適時かつ的確に行われなければならない。具体的には、ライブストリーミングプロバイダーにとっての「適切な視聴者」とは、通常、ライブストリーミングサービスの収益の大部分に貢献する人を指す。そのような「優先度の高い」ユーザが、興味のあるコンテンツについて適時に通知を受け取り、できるだけ長くプラットフォームに滞在するようにすることが重要である。そのためには、ユーザが興味のあるコンテンツを見逃さないようにすることが重要である。

【0008】

従来の通知プッシュの手法やシステムには、いくつかの解決すべき課題がある。課題の１つは、通知処理に関する優先順位の決定ができないことである。通知すべきユーザが多数存在する場合（例えば、多くのフォロワーを持つストリーマーが配信するライブストリーミング番組が開始される場合）、各ユーザに対する通知を完了するまでに多くの時間がかかる可能性がある。ライブストリーミング番組が始まってからすべての通知が完了するまでの時間差や遅延は、５～２０分にも及ぶことがある。この遅延は、ライブストリーミング番組をサポートするバックエンドサーバの処理能力、通知処理を行う通知サーバの処理能力、あるいはインターネットの接続状況など、さまざまな理由による可能性がある。そのため、通知処理に関して優先順位がない場合、収益貢献度の高いユーザが、収益貢献度の低いユーザよりもずっと遅く通知を受ける可能性がある。それにより、収益貢献度の高い可能性のあるユーザがネガティブな体験をして、ライブストリーミングサービスの運営に悪影響を及ぼす可能性がある。

【0009】

また通知処理の遅れの他に、別の課題として、一部の通知が失敗し、ユーザの一部が全く通知を受けられない可能性がある。通知の失敗は、一度に、あるいは短時間内に、通知サーバに送信する必要がある通知要求が多すぎて、通知サーバに（場合によってはバックエンドサーバにも）過大な負荷がかかる場合に起こる可能性がある。収益貢献度の高い可能性のあるユーザに通知が届かないと、ライブストリーミングプロバイダーの収益に大きな影響が生じる可能性がある。

【0010】

図１に、従来のライブストリーミングサービスに関する通知プロセスを示す例示的シーケンス図を示す。

【0011】

工程Ｓ１００において、ストリーマーＡは、バックエンドサーバに、ライブストリーミング（ＬＳ）番組の開始要求を送信する。

【0012】

工程Ｓ１０２において、当該バックエンドサーバは、当該ライブストリーミング要求の受信を確認するＡＰＩ応答を送信する。

【0013】

工程Ｓ１０４において、当該バックエンドサーバは、関連視聴者の要求をユーザデータベースに対して送信する。ここで、関連視聴者とは、通常、ストリーマーＡのフォロワー、すなわち、ストリーマーＡが配信するストリーミング番組の通知を受ける必要があるユーザである。

【0014】

工程Ｓ１０６において、当該ユーザデータベースは、当該関連視聴者の情報を当該バックエンドサーバに送信する。

【0015】

工程Ｓ１０８において、当該バックエンドサーバは、通知要求を通知サーバに送信する。当該通知要求は、ライブストリーミング番組について通知を受ける必要があるすべての当該関連視聴者についての情報を含む。

【0016】

工程Ｓ１１０において、当該通知サーバは、工程Ｓ１０８で受信した情報に基づき、当該ライブストリーミング番組について当該関連視聴者に通知する。当該通知サーバは、通常、ライブストリーミングサービスを提供する当該バックエンドサーバから分離されている。当該通知サーバは、ライブストリーミングサービスに関する通知処理を実行するように構成されている。

【0017】

工程Ｓ１１２において、当該通知サーバは、当該通知要求の受信確認を当該バックエンドサーバに送信する。

【0018】

従来、ストリーマーＡが人気ストリーマーでフォロワーが多い場合、工程Ｓ１０８及び（または）工程Ｓ１１０において、遅延やクラッシュが発生する可能性があった。例えば、当該通知要求を生成して送信するための当該バックエンドサーバの処理負荷が高すぎ、当該ユーザデータベースにおいて工程Ｓ１０８で深刻な遅延またはシステム障害が起こる可能性がある。例えば、当該通知要求を受信して処理するための当該通知サーバの処理負荷が高すぎ、当該通知サーバにおいて工程Ｓ１１０で深刻な遅延またはシステム障害が起こる可能性がある。いずれの場合も、視聴者の一部に対する通知の深刻な遅延または通知の失敗を生じる可能性がある。

【0019】

図２に、本発明の一部の実施態様に基づく通信システムの構成を示す概略図を示す。

【0020】

通信システム１は、コンテンツを介したインタラクションを伴うライブストリーミングサービスを提供することができる。ここで言う「コンテンツ」とは、コンピュータ装置で再生可能なデジタルコンテンツを指す。つまり、通信システム１は、ユーザがオンラインで他のユーザとのリアルタイムのインタラクションに参加することを可能にする。当該通信システム１は、複数のユーザ端末１０と、バックエンドサーバ３０と、ストリーミングサーバ４０と、通知サーバ５０を含む。当該ユーザ端末１０、当該バックエンドサーバ３０、当該ストリーミングサーバ４０、当該通知サーバ５０は、例えばインターネットなどのネットワーク９０を介して接続される。当該バックエンドサーバ３０は、当該ユーザ端末及び（または）当該ストリーミングサーバ４０との間のインタラクションを同期させるサーバとすることができる。一部の実施態様において、当該バックエンドサーバ３０は、アプリケーション（ＡＰＰ）プロバイダーのサーバとしてもよい。当該ストリーミングサーバ４０は、ストリーミングデータまたはビデオデータを取り扱う、または提供するためのサーバである。一部の実施態様において、当該バックエンドサーバ３０と当該ストリーミングサーバ４０は、独立したサーバとしてもよい。一部の実施態様において、当該バックエンドサーバ３０と当該ストリーミングサーバ４０は、１つのサーバに統合してもよい。一部の実施態様において、当該ユーザ端末１０は、ライブストリーミングサービスのためのクライアント装置である。一部の実施態様において、当該ユーザ端末１０は、視聴者、ストリーマー、アンカー、ポッドキャスター、オーディエンス、リスナーなどと呼ばれることがある。各当該ユーザ端末１０、当該バックエンドサーバ３０、当該ストリーミングサーバ４０、当該通知サーバ５０は、それぞれ情報処理装置の一例である。一部の実施態様において、ストリーミングは、ライブストリーミングまたはビデオ再生とすることができる。一部の実施態様において、ストリーミングは、オーディオストリーミング及び（または）ビデオストリーミングとすることができる。一部の実施態様において、ストリーミングは、オンラインショッピング、トークショー、タレントショー、娯楽イベント、スポーツイベント、音楽ビデオ、映画、コメディ、コンサートなどのコンテンツを含むことができる。

【0021】

図３に、本発明の一部の実施態様に基づくライブストリーミングサービスについての通信プロセスを示す例示的なシーケンス図を示す。

【0022】

工程Ｓ３００において、ストリーマーＡ（またはストリーマーＡのユーザ端末）が、当該バックエンドサーバ３０にライブストリーミング番組の開始要求を送信する。

【0023】

工程Ｓ３０２において、当該バックエンドサーバ３０は、当該ライブストリーミング要求の受信を確認するＡＰＩ応答を送信する。一部の実施態様において、当該ＡＰＩ応答は、当該ライブストリーミング番組に関連するメタデータを含んでもよい。

【0024】

工程Ｓ３０４において、当該バックエンドサーバ３０は、関連視聴者の要求を当該ユーザデータベース３５に対して送信する。当該関連視聴者は、当該ライブストリーミング番組に関する通知を受け取る対象となると判断されたユーザである。一部の実施態様において、当該関連視聴者は、ストリーマーＡのフォロワーを含む。一部の実施態様において、当該関連視聴者は、ストリーマーＡまたは当該ライブストリーミング番組と同一または類似の属性／タグを共有する視聴者を含む。

【0025】

工程Ｓ３０６において、当該ユーザデータベース３５は、当該関連視聴者の情報を当該バックエンドサーバ３０に送信する。一部の実施態様において、当該ユーザデータベース３５の内部または外部に実装された機械学習モデルが利用され、アクセス可能なユーザの属性とストリーマーＡの属性（またはライブストリーミング番組のタグ）に基づいて、対象となる視聴者が決定される。

【0026】

工程Ｓ３０８において、当該バックエンドサーバ３０は、当該関連視聴者の貢献度スコアの要求を貢献度データベース３７に対して送信する。当該貢献度データベース３７は、すべての利用可能なユーザまたは視聴者の貢献度スコアを格納するように構成される。一部の実施態様において、当該貢献度スコアは、当該貢献度データベース３７の内部または外部に実装された貢献度決定ユニットによって計算される。視聴者の貢献スコアは、ライブストリーミングプラットフォームにおける当該視聴者の行動（または行動履歴）に基づいて決定されてもよい。当該貢献度スコアの算出については、後で詳細に説明する。

【0027】

工程Ｓ３１０において、当該貢献度データベース３７は、当該関連視聴者の当該貢献度スコアを当該バックエンドサーバ３０に送信する。

【0028】

工程Ｓ３１２において、当該バックエンドサーバ３０は、各当該関連視聴者について、当該視聴者の貢献度スコアに基づき優先度（または通知優先度）を決定する。一部の実施態様において、より高い貢献度スコアを有する視聴者が、より高い優先度を有すると決定される。一部の実施態様において、当該バックエンドサーバ３０は、当該関連視聴者の当該優先度の情報を含む優先度データ（または優先度テーブル）を生成する。例えば、当該バックエンドサーバ３０が、視聴者Ａの貢献度スコアが視聴者Ｂの貢献度スコアより高いと決定した場合、当該バックエンドサーバ３０は、視聴者Ａの優先度が視聴者Ｂの優先度より高いと決定する。

【0029】

工程Ｓ３１４において、当該バックエンドサーバ３０は、通知要求を通知サーバ５０に送信する。当該通知要求は、ライブストリーミング番組について通知を受ける必要があるすべての当該関連視聴者についての情報を含む。

【0030】

一部の実施態様において、当該通知要求は、当該関連視聴者の優先度に対応した順序で送信される。例えば、視聴者Ａが視聴者Ｂよりも高い優先度を有する場合、視聴者Ａに通知するための通知要求は、視聴者Ｂに通知するための通知要求より早く送信されてもよい。優先度に基づく送信は、一度にまたは非常に短い時間内に送信する通知要求が多すぎることにより、当該バックエンドサーバ３０に過度の負担がかかり、深刻な通知遅延または通知失敗につながる可能性から、当該バックエンドサーバ３０を保護することができる。優先度に基づく送信は、一度にまたは非常に短い時間内に受信する通知要求が多すぎることにより、当該通知サーバ５０に過度の負担がかかり、深刻な通知遅延または通知失敗につながる可能性から、当該通知サーバ５０を保護することができる。

【0031】

一部の実施態様において、当該優先度データは、当該通知要求とともに（または当該通知要求の中に含まれて）当該バックエンドサーバ３０から当該通知サーバ５０に送信される。

【0032】

一部の実施態様において、１つの通知要求は、１人の視聴者に対応してもよい。一部の実施態様において、１つの通知要求は、２人以上の視聴者に対応してもよい。一部の実施態様において、当該優先度データは、１つまたは複数の通知要求に含まれる。

【0033】

一部の実施態様において、より高い貢献度スコアを有する視聴者のための通知要求は、より低い貢献度スコアを有する視聴者のための通知要求よりも高い優先度で送信される。例えば、より高い優先度を有する通知要求は、より安定したインターネットチャネルを介して送信されてもよい。一部の実施態様において、優先度の異なる通知要求は、異なる通知サーバに送信されてもよい。例えば、より高い優先度を有する通知要求は、より高規格で、より信頼できる性能を有する通知サーバに送信されてもよい。

【0034】

工程Ｓ３１６において、当該通知サーバ５０は、工程Ｓ３１４で受信した情報に基づき、当該ライブストリーミング番組について当該関連視聴者に通知する。当該通知サーバ５０は、当該関連視聴者の当該優先度に対応する順序で、当該ライブストリーミング番組について当該関連視聴者に通知する。

【0035】

一部の実施態様において、より高い優先度の視聴者の通知要求は、より低い優先度の視聴者の通知要求よりも早く当該通知サーバ５０で受信され、その後、当該通知サーバ５０は、より高い優先度の視聴者に、低い優先度の視聴者よりも早くライブストリーミング番組について通知する。

【0036】

一部の実施態様において、当該通知サーバ５０は、工程Ｓ３１４で受信した優先度データに基づいて通知順序を決定する。例えば、より高い優先度の視聴者は、より低い優先度の視聴者よりも早く、当該ライブストリーミング番組について通知される。

【0037】

優先度に基づいた通知を行うことで、優先度の高い視聴者（つまり貢献度の高い視聴者）が適時に通知を受けられるように確約することができる。優先度に基づいた通知は、一度にまたは非常に短い時間内に通知する視聴者が多すぎることによって過度の負担がかかることから当該通知サーバ５０を保護することができる。

【0038】

工程Ｓ３１８において、当該通知サーバ５０は、当該通知要求の受信確認を当該バックエンドサーバ３０に送信する。工程Ｓ３１８は、工程Ｓ３１６の前に、後に、または工程Ｓ３１６と同時に発生してもよい。一部の実施態様において、当該通知サーバ５０は、工程Ｓ３１６が行われた後、通知タスク完了の確認を当該バックエンドサーバ３０に送信する。

【0039】

図４に、本発明の一部の実施態様に基づく通信システムの構成を示す概略図を示す。図４に示すように、バックエンドサーバ３０は、優先度決定ユニット３００、パラメーター監視ユニット３０２、視聴者テーブル３０４、貢献度テーブル３０６、優先度テーブル３０８、パラメーター閾値テーブル３１０を含む。当該ユーザデータベース３５、貢献度データベース３７、および貢献度決定ユニット３７０は、当該バックエンドサーバ３０の外部に実装される。

【0040】

当該優先度決定ユニット３００は、各当該関連視聴者について、当該視聴者の貢献度スコアに応じて優先度（または通知優先度）を決定するように構成されている。当該優先度決定ユニット３００は、当該関連視聴者の貢献度スコアについて当該貢献度テーブル３０６を参照し、それに基づき優先度を決定する。一部の実施態様において、図３の工程Ｓ３１２について説明した処理のうちの１つまたは複数が、当該優先度決定ユニット３００により実行される。

【0041】

当該パラメーター監視ユニット３０２は、当該バックエンドサーバ３０の１つ以上のパラメーターを監視するように構成される。監視されるパラメーターは、当該バックエンドサーバ３０のＣＰＵ使用率、メモリ使用率、帯域幅及び（または）ＱＰＳ（１秒あたりのクエリ数）データを含んでもよい。

【0042】

一部の実施態様において、当該バックエンドサーバ３０は、当該バックエンドサーバ３０外部の当該通知サーバの１つ以上のパラメーターを監視するように構成された別のパラメーター監視ユニットを含んでもよい。監視されるパラメーターは、当該通知サーバのＣＰＵ使用率、メモリ使用率、帯域幅及び（または）ＱＰＳ（１秒あたりのクエリ数）データを含んでもよい。監視されるパラメーターの用途については後述する。

【0043】

当該視聴者テーブル３０４は、視聴者データを格納するように構成される。例えば、当該ユーザデータベース３５から受信した関連視聴者の情報を当該視聴者テーブル３０４に格納することができる。

【0044】

当該貢献度テーブル３０６は、当該視聴者の貢献度データまたは貢献度スコアを格納するように構成される。例えば、当該貢献度データベース３７から受信した当該関連視聴者の貢献度スコアを当該貢献度テーブル３０６に格納することができる。

【0045】

当該優先度テーブル３０８は、当該優先度決定ユニット３００によって決定された優先度データを格納するように構成される。

【0046】

当該パラメーター閾値テーブル３１０は、当該パラメーター監視ユニット３０２が監視するパラメーターの閾値を格納するように構成される。

【0047】

当該ユーザデータベース３５は、すべての利用可能なユーザの情報を格納するように構成される。当該情報は、通知処理に必要なＩＤ情報を含む。当該ユーザは、ライブストリーミングプラットフォーム上のストリーマー及び（または）視聴者を含んでもよい。当該ユーザデータベース３５は、ライブストリーミングプロバイダーのためのユーザ情報の監視および格納を担当するクラウドサービスの一部であってもよい。一部の実施態様において、ユーザデータベースは、バックエンドサーバ内に実装されてもよい。

【0048】

当該貢献度データベース３７は、ユーザの貢献度データまたは貢献度スコアを格納するように構成される。当該貢献度スコアは、当該貢献度決定ユニット３７０により、当該ユーザの行動に基づいて計算または決定される。当該貢献度スコアは、当該貢献度決定ユニット３７０により、常時または定期的に更新されてもよい。

【0049】

当該貢献度決定ユニット３７０は、ライブストリーミングプラットフォーム上でのコメント行動、贈り物送信行動、購入行動、視聴行動、ログイン行動、または交流行動などのユーザの行動に基づいて、ユーザの当該貢献度スコアを決定してもよい。当該貢献度スコアは、コメント量またはコメント頻度が増加するにつれて増加してもよい。当該貢献スコアは、贈り物送信量または贈り物送信頻度が増加するにつれて、増加してもよい。当該貢献スコアは、購入金額または購入頻度が増加するにつれて増加してもよい。当該貢献スコアは、視聴時間または視聴頻度が増加するにつれて、増加してもよい。当該貢献スコアは、ログイン回数またはログイン頻度が高くなるにつれて増加してもよい。当該貢献スコアは、ユーザが他のユーザと積極的に交流していると判断される場合に、増加してもよい。当該積極的な交流には、他のユーザをライブストリーミング番組に招待すること、他のユーザがライブストリーミング番組に長く滞在するように促すこと、ストリーマーが他のユーザからより多くの贈り物を得るように支援することが含まれてもよい。当該貢献度スコアは、当該ユーザと他のユーザの交流がネガティブであると判定された場合に、減少してもよい。ネガティブな交流は、他のユーザ（ストリーマーまたは視聴者を含む）に対するいじめや失礼なコメント、またはライブストリーミングプラットフォームの収益に悪影響を及ぼすと判断される任意の行動を含んでもよい。

【0050】

一部の実施態様において、当該貢献度データベース及び（または）当該貢献度決定ユニットは、バックエンドサーバ内に実装されてもよい。

【0051】

図５に、本発明の一部の実施態様に基づく通知を示す例示的なフローチャートを示す。

【0052】

工程Ｓ５００において、当該ライブストリーミング番組に関連するユーザまたは視聴者のリストを取得する。この処理は、当該バックエンドサーバ３０によって実行されてもよい。当該関連視聴者の情報は、当該視聴者テーブル３０４に格納されてもよい。

【0053】

工程Ｓ５０２において、当該リストに含まれる各ユーザの貢献度スコアを取得する。例えば、当該リスト内の各ユーザの貢献度スコアは、当該バックエンドサーバ３０により、当該貢献度データベース３７から取得される。当該貢献度スコアは、当該貢献度テーブル３０６に格納されてもよい。

【0054】

工程Ｓ５０４において、当該関連ユーザに対する通知要求が、それぞれの貢献度スコアに基づいて優先順位付けされる。この処理は、当該優先度決定ユニット３００によって実行されてもよい。決定された優先度データは、当該優先度テーブル３０８に格納されてもよい。

【0055】

工程Ｓ５０６において、サブグループのユーザに対する通知要求が送信される。例えば、優先度が最も高い視聴者のサブグループに対する通知要求が、当該バックエンドサーバ３０から当該通知サーバ５０に送信され、通知処理が行われる。

【0056】

工程Ｓ５０８において、当該バックエンドサーバ３０の環境パラメーターが監視または取得される。この処理は、当該パラメーター監視ユニット３０２によって実行されてもよい。監視されるパラメーターは、当該バックエンドサーバ３０のＣＰＵ使用率、メモリ使用率、帯域幅及び（または）ＱＰＳ（１秒あたりのクエリ数）データを含んでもよい。

【0057】

工程Ｓ５１０において、監視されたパラメーターがその閾値と比較される。この比較処理は、パラメーター監視ユニット３０２が実行しても、当該バックエンドサーバ３０内の別の比較ユニットが実行してもよい。当該閾値は、パラメーター閾値テーブル３１０に格納されてもよい。

【0058】

当該閾値は、ライブストリーミングプラットフォームのシステムオペレーターによって決定されてもよい。各パラメーターの当該閾値は、その閾値よりも高いことが判明したパラメーターが、当該バックエンドサーバ３０の過負荷状態を示すように決定されてもよい。当該バックエンドサーバ３０の過負荷状態は、深刻な通知遅延または通知失敗につながる可能性がある。例えば、履歴データ解析により、当該バックエンドサーバ３０のＣＰＵ使用率が７０％より高い場合に、深刻な通知遅延または通知失敗が起こりやすいことが分かる。あるいは、「深刻な通知遅延または通知失敗」と「ＣＰＵ使用率＞７０％」との間に高い相関関係が存在することが判明する。その場合、ＣＰＵ使用率の閾値を７０％以下に決定してもよい。

【0059】

すべてのパラメーターが対応する閾値以下であることが確認された場合、フローは工程Ｓ５０６に進む。その場合、バックエンドサーバ３０が過負荷になっておらず、さらなる処理のための容量があると判断され、その後の通知処理のために、２番目（または次）に高い優先度を有する視聴者のサブグループに対する通知要求が当該バックエンドサーバ３０から当該通知サーバ５０に送信される。

【0060】

１つ以上のパラメーターが対応する閾値より高いことが確認された場合、フローは工程Ｓ５１２に進む。

【0061】

工程Ｓ５１２において、当該バックエンドサーバ３０は、当該通知サーバ５０への通知要求の送信を所定時間停止（または、一時停止）する。当該停止後、フローは後続のパラメーター監視のために工程Ｓ５０８に進む。一部の実施態様において、当該停止により、監視されるパラメーターが閾値未満に低下するようにしてもよい。つまり、当該停止は、当該バックエンドサーバ３０の負荷を軽減し、当該バックエンドサーバ３０を過負荷ではない健全な状態に戻すことができる。

【0062】

図６に、本発明の一部の実施態様に基づく通知を示す例示的なフローチャートを示す。図６に示すフローは、図５のフローと同様であり、工程Ｓ６０８と工程プＳ６１０においてのみ相違する。

【0063】

工程Ｓ６０８において、当該通知サーバ５０の環境パラメーターが監視または取得される。この処理は、当該バックエンドサーバ３０内のパラメーター監視ユニットによって実行されてもよい。監視されるパラメーターは、当該通知サーバ５０のＣＰＵ使用率、メモリ使用率、帯域幅及び（または）ＱＰＳ（１秒あたりのクエリ数）データを含んでもよい。

【0064】

工程Ｓ６１０において、（当該通知サーバ５０の）監視されたパラメーターがその閾値と比較される。この比較処理は、パラメーター監視ユニットが実行しても、当該バックエンドサーバ３０内の別の比較ユニットが実行してもよい。当該閾値は、パラメーター閾値テーブル３１０に格納されてもよい。

【0065】

当該閾値は、ライブストリーミングプラットフォームのシステムオペレーターまたは当該通知サーバ５０のシステムオペレーターによって決定されてもよい。各パラメーターの当該閾値は、その閾値よりも高いことが判明したパラメーターが、当該通知サーバ５０の過負荷状態を示すように決定されてもよい。当該通知サーバ５０の過負荷状態は、深刻な通知遅延または通知失敗につながる可能性がある。例えば、履歴データ解析により、当該通知サーバ５０のメモリ使用率が８０％より高い場合に、深刻な通知遅延または通知失敗が起こりやすいことが分かる。あるいは、「深刻な通知遅延または通知失敗」と「メモリ使用率＞８０％」との間に高い相関関係が存在することが判明する。その場合、メモリ使用率の閾値を８０％以下に決定してもよい。

【0066】

すべてのパラメーターが対応する閾値以下であることが確認された場合、フローは工程Ｓ５０６に進む。その場合、通知サーバ５０が過負荷になっておらず、さらなる処理のための容量があると判断され、その後の通知処理のために、２番目（または次）に高い優先度を有する視聴者のサブグループに対する通知要求が当該バックエンドサーバ３０から当該通知サーバ５０に送信される。

【0067】

１つ以上のパラメーターが対応する閾値より高いことが確認された場合、フローは工程Ｓ５１２に進む。

【0068】

工程Ｓ５１２において、当該バックエンドサーバ３０は、当該通知サーバ５０への通知要求の送信を所定時間停止（または、一時停止）する。当該停止後、フローは後続のパラメーター監視のために工程Ｓ６０８に進む。一部の実施態様において、当該停止により、監視されるパラメーターが閾値未満に低下するようにしてもよい。つまり、当該停止は、当該通知サーバ５０の負荷を軽減し、当該通知サーバ５０を過負荷ではない健全な状態に戻すことができる。

【0069】

図７に、図４に示す視聴者テーブル３０４の例示的データ構造を示す。当該視聴者テーブルには、当該関連視聴者のＩＰアドレスや対応する通知サーバなどの情報が格納される。

【0070】

図８に、図４に示す貢献度テーブル３０６の例示的データ構造を示す。当該貢献度テーブルには、当該貢献度データベース３７から受信した貢献度情報が格納される。

【0071】

図９に、図４に示す優先度テーブル３０８の例示的データ構造を示す。視聴者は、その貢献度スコアに基づいて異なる優先度に分類される。各優先度には、Ｎ人の視聴者が含まれる。例えば、優先度１は、貢献度スコアが上位Ｎ位に含まれる視聴者に対応する。

【0072】

一部の実施態様において、各優先度は、１人の視聴者のみに対応してもよい。一部の実施態様において、Ｎは、バックエンドサーバまたは通知サーバの健全性またはキャパシティ状態に基づいて決定されてもよい。例えば、バックエンドサーバまたは通知サーバの健全性またはキャパシティ状態が良好である場合、より多くの通知要求をバックエンドサーバから通知サーバに一度に送信できるように、Ｎがより大きく決定されてもよい。例えば、バックエンドサーバまたは通知サーバの健全性またはキャパシティ状態が悪い場合、バックエンドサーバから通知サーバに一度に送信できる通知要求の数がより少なくなるように、Ｎがより小さく決定されてもよい。それにより、通知の粒度を高め、信頼性を向上させることができる。

【0073】

図１０に、本発明の一部の実施態様に基づく優先度テーブルの例示的データ構造を示す。

【0074】

この実施態様において、ストリーマーの貢献度情報も判定かつ活用される。ストリーマーは、当該ストリーマーの過去の記録に基づき、当該ストリーマーがライブストリーミングプラットフォームにより多くの収益をもたらす可能性が高い場合、高貢献者として分類される。ストリーマーは、当該ストリーマーの過去の記録に基づき、当該ストリーマーがライブストリーミングプラットフォームにあまり収益をもたらさない可能性が高い場合、低貢献者として分類される。

【0075】

図１０に示すように、視聴者への通知優先度の決定においては、ストリーマーと視聴者間の相関性や相互効果が考慮される。高貢献度の視聴者と高貢献度のストリーマーの組み合わせは、高い通知優先度につながる。例えば、視聴者Ｖａ、Ｖｃ、Ｖｄは、高貢献度（貢献度１）の視聴者であり、高貢献度のストリーマーＡが配信するライブストリーミング番組の通知対象受信者である。したがって、視聴者Ｖａ、Ｖｃ、Ｖｄは、ストリーマーＡのライブストリーミング番組の通知に関して優先度１（最高優先度）に分類される。例えば、視聴者ＶｋとＶｌは、低貢献度（貢献度３）の視聴者であり、中貢献度のストリーマーＢが配信するライブストリーミング番組の通知対象受信者である。したがって、視聴者ＶｋとＶｌは、ストリーマーＢのライブストリーミング番組の通知に関して優先度８に分類される。

【0076】

図１１に、本発明の一部の実施態様に基づく優先度テーブルの例示的データ構造を示す。

【0077】

本実施態様において、通知の優先度を決定する際に、ストリーマーの貢献度により大きな重みが与えられる。したがって、ストリーマーＡのライブストリーミング番組に関する通知は、ストリーマーＢのライブストリーミング番組に関する通知よりも高い優先度を有する。

【0078】

一部の実施態様において、視聴者Ｖａは、ストリーマーＡとストリーマーＢ両方のフォロワーであり、ストリーマーＡに関する視聴者Ｖａの貢献スコアは、ストリーマーＢに関する視聴者Ｖａの貢献スコアより高い。ストリーマーＡとストリーマーＢの両方がライブストリーミング番組の配信を開始する場合、ストリーマーＡのライブストリーミング番組に関する通知要求（視聴者Ｖａへの通知）に、ストリーマーＢのライブストリーミング番組に関する通知要求（視聴者Ｖａへの通知）より高い優先度を付与してもよい。

【0079】

図３において、シーケンス図に示されるストリーマーＡは１人だけである。一部の実施態様において、当該バックエンドサーバ３０にライブストリーミング番組の開始要求を送信するストリーマーが複数存在する。その場合、当該関連視聴者は、それらのライブストリーミング番組に関する通知を受け取る対象となると判断されたユーザである。一部の実施態様において、当該関連視聴者は、当該複数のストリーマーのフォロワーを含む。一部の実施態様において、当該関連視聴者は、１人以上のストリーマーまたは当該ライブストリーミング番組と同一または類似の属性／タグを共有する視聴者を含む。

【0080】

図１２に、本発明の一部の実施態様に基づくライブストリーミングサービスについての通信プロセスを示す例示的なシーケンス図を示す。ストリーマーＡ、Ｂ、Ｃは複数存在する。

【0081】

工程Ｓ１２００において、ストリーマーＡ、Ｂ、Ｃは、当該バックエンドサーバ３０に対して、ライブストリーミング番組の開始要求を行う。

【0082】

工程Ｓ１２０２において、当該バックエンドサーバ３０は、ストリーマーＡ、Ｂ、ＣにＡＰＩ応答を送信し、ライブストリーミング要求の受信を確認する。一部の実施態様において、当該ＡＰＩ応答は、当該ライブストリーミング番組に関連するメタデータを含んでもよい。

【0083】

工程Ｓ１２０４において、当該バックエンドサーバ３０は、関連視聴者の要求を当該ユーザデータベース３５に対して送信する。当該関連視聴者は、当該ライブストリーミング番組に関する通知を受け取る対象となると判断されたユーザである。一部の実施態様において、当該関連視聴者は、ストリーマーＡ、Ｂ、Ｃのフォロワーを含む。一部の実施態様において、当該関連視聴者は、ストリーマーＡ、Ｂ、Ｃまたはそれらのライブストリーミング番組と同一または類似の属性／タグを共有する視聴者を含む。

【0084】

工程Ｓ１２０６において、当該ユーザデータベース３５は、当該関連視聴者の情報を当該バックエンドサーバ３０に送信する。一部の実施態様において、当該ユーザデータベース３５の内部または外部に実装された機械学習モデルが利用され、アクセス可能なユーザの属性とストリーマーＡ、Ｂ、Ｃの属性（または彼らのライブストリーミング番組のタグ）に基づいて、対象となる視聴者が決定される。

【0085】

工程Ｓ１２０８において、当該バックエンドサーバ３０は、当該関連視聴者の貢献度スコアの要求を貢献度データベース３７に対して送信する。当該貢献度データは、各ストリーマーに関する当該関連視聴者の貢献度スコアを含んでもよい。一部の実施態様において、当該バックエンドサーバ３０は、当該ストリーマーの貢献度スコアも要求する。

【0086】

工程Ｓ１２１０において、当該貢献度データベース３７は、当該関連視聴者の当該貢献度スコアを当該バックエンドサーバ３０に送信する。一部の実施態様において、当該貢献度データベース３７は、当該ストリーマーの当該貢献度スコアも当該バックエンドサーバ３０に送信する。

【0087】

工程Ｓ１２１２において、当該バックエンドサーバ３０は、各当該関連視聴者について、当該視聴者の貢献度スコアに基づき優先度（または通知優先度）を決定する。一部の実施態様において、優先度は視聴者とストリーマーのペアごとに決定される。一部の実施態様において、ストリーマーの貢献度も優先度の決定において考慮される。一部の実施態様において、当該決定された優先度データは、図１０と図１１に示すデータ構造と同様のマトリックス形式であってもよい。

【0088】

工程Ｓ１２１４において、当該バックエンドサーバ３０は、通知要求及び（または）当該優先度データを通知サーバ５０に送信する。一部の実施態様において、より高い優先度に対応する通知要求は、より低い優先度に対応する通知要求より早く送信されてもよい。一部の実施態様において、より高い優先度に対応する通知要求は、より信頼性の高いチャネルで送信されてもよい。

【0089】

工程Ｓ１２１６において、当該通知サーバ５０は、工程Ｓ１２１４で受信した情報に基づき、当該ライブストリーミング番組について当該関連視聴者に通知する。当該通知サーバ５０は、当該関連視聴者の当該優先度（または視聴者とストリーマーのペアの優先度）に対応する順序で、当該ライブストリーミング番組について当該関連視聴者に通知する。

【0090】

工程Ｓ１２１８において、当該通知サーバ５０は、当該通知要求の受信確認を当該バックエンドサーバ３０に送信する。工程Ｓ１２１８は、工程Ｓ１２１６の前に、後に、または工程Ｓ１２１６と同時に発生してもよい。一部の実施態様において、当該通知サーバ５０は、工程Ｓ１２１６が行われた後、通知タスク完了の確認を当該バックエンドサーバ３０に送信する。

【0091】

一部の実施態様において、視聴者の当該貢献度スコアは、イベント情報に基づいて決定されてもよい。例えば、当該バックエンドサーバは、ライブストリーミング番組のイベント情報を受信し、貢献度スコアを要求する際に、当該イベント情報を貢献度データベースまたは貢献度決定ユニットに送信してもよい。視聴者の過去の行動が、より高い貢献確率とライブストリーミング番組に関連するイベントとの間の相関を示唆する場合、当該視聴者は当該ライブストリーミング番組に関してより高い貢献度スコアを付与されてもよい。

【0092】

一部の実施態様において、視聴者の当該貢献度スコアは、別の視聴者に基づいて決定されてもよい。視聴者の当該貢献度スコアは、別の視聴者の行動または存在と相関していてもよい。例えば、データ分析により、視聴者Ｖａは、視聴者Ｖｃの貢献度にプラスの影響を与え、視聴者Ｖｂは、視聴者Ｖｃの貢献度にマイナスの影響を与えることが示される（例えば、視聴者Ｖａは視聴者Ｖｃとうまく交流し、視聴者Ｖｃにもっと贈り物を送るように促すが、視聴者Ｖｂは視聴者Ｖｃをいじめたり、邪魔したりする傾向がある）。その場合、当該関連視聴者に視聴者Ｖａが含まれる場合、視聴者Ｖｃの貢献度スコアはより高く判定されてもよく、関連視聴者に視聴者Ｖｂが含まれる場合、視聴者Ｖｃの貢献度スコアはより低く判定されてもよい。一部の実施態様において、ある視聴者が他の視聴者の貢献度またはユーザ体験にマイナスの影響を与えると判断された場合、その視聴者に対応する通知要求は、バックエンドサーバから通知サーバに送信されなくてもよい。

【0093】

図１３に、図４に示すパラメーター閾値テーブル３１０の例示的データ構造を示す。図１３に示すように、監視するパラメーターの閾値が決定され、パラメーター閾値テーブルに格納される。本実施態様において、ＣＰＵ使用率の閾値は７０％、メモリ使用率の閾値は７５％、帯域幅使用率の閾値は８０％、ＱＰＳの閾値は１０Ｋにそれぞれ設定される。

【0094】

本発明は、ライブストリーミング番組について視聴者に通知するための改良された方法及びシステムを開示する。したがって、より信頼性の高い通知を実現することができ、これにより、ライブストリーミングプラットフォームの運営をさらに向上させることができる。

【0095】

本発明で説明した処理及び手順は、明示的に説明したものに加えて、ソフトウェア、ハードウェア、またはそれらの任意の組み合わせにより実現することができる。例えば、本明細書で説明した処理および手順は、その処理および手順に対応するロジックを集積回路、揮発性メモリ、不揮発性メモリ、非一時的なコンピュータ可読媒体、磁気ディスクなどの媒体に実装することにより実現することができる。さらに、本明細書に記載された処理および手順は、その処理および手順に対応するコンピュータプログラムとして実現することができ、各種のコンピュータにより実行することができる。

【0096】

さらに、上記実施態様で説明したシステムまたは方法は、固体記憶装置、光ディスク記憶装置、磁気ディスク記憶装置などの非一時的なコンピュータ可読媒体に格納されたプログラムに統合されてもよい。あるいは、プログラムは、インターネットを介してサーバからダウンロードされ、プロセッサにより実行されるものとしてもよい。

【0097】

以上、本発明の技術的内容及び特徴を説明したが、本発明の属する技術分野において通常の知識を有する者であれば、本発明の教示及び開示から逸脱することなく、なお多くの変形及び修正を行うことができる。したがって、本発明の範囲は、既に開示された実施態様に限定されず、本発明から逸脱しない別の変形や修正を含み、特許請求の範囲に含まれる範囲である。

【符号の説明】

【0098】

１ 通信システム
１０ ユーザ端末
３０ バックエンドサーバ
４０ ストリーミングサーバ
５０ 通知サーバ
９０ ネットワーク
３０ サーバ
３５ ユーザデータベース
３７ 貢献度データベース
３７０ 貢献度決定ユニット
３００ 優先度決定ユニット
３０２ パラメーター監視ユニット
３０４ 視聴者テーブル
３０６ 貢献度テーブル
３０８ 優先度テーブル
３１０ パラメーター閾値テーブル
Ｓ１００、Ｓ１０２、Ｓ１０４、Ｓ１０６、Ｓ１０８、Ｓ１１０、Ｓ１１２ 工程
Ｓ３００、Ｓ３０２、Ｓ３０４、Ｓ３０６、Ｓ３０８、Ｓ３１０、Ｓ３１２、Ｓ１４、Ｓ３１６、Ｓ３１８ 工程
Ｓ５００、Ｓ５０２、Ｓ５０４、Ｓ５０６、Ｓ５０８、Ｓ５１０、Ｓ５１２工程
Ｓ６０８、Ｓ６１０ 工程
Ｓ１２００、Ｓ１２０２、Ｓ１２０４、Ｓ１２０６、Ｓ１２０８ 工程
Ｓ１２１０、Ｓ１２１２、Ｓ１２１４、Ｓ１２１６、Ｓ１２１８ 工程
Ｖａ、Ｖｂ、Ｖｃ、Ｖｄ、Ｖｅ、Ｖｆ、Ｖｇ、Ｖｈ、Ｖｉ、Ｖｊ、Ｖｋ、Ｖｌ、Ｖｍ 視聴者
Ｖ１、Ｖ２、Ｖ３、Ｖ４、Ｖ５、Ｖ６、Ｖ７、Ｖ８、Ｖ９ 視聴者
ＮＳ１ 通知サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】