JP7423024B1 - データアクセスのためのシステム及び方法 - Google Patents

Abstract

【課題】ライブストリーミングのネットワーク遅延を多次元的に低減するデータアクセスのためのシステム及び方法を提供する。【解決手段】方法は、ユーザ端末のユーザから要求を取得する工程と、当該要求のタイプと、当該ユーザの要求許容度データを取得する工程と、当該要求のタイプと当該ユーザの当該要求許容度データに基づき、当該要求に対応するバックエンドサーバに当該要求を送信するための遅延時間を決定する工程と、を含む。【選択図】図１３

Description

本発明は、データアクセスに関するものであり、特にサーバによるデータアクセスに関するものである。

ライブストリーミングサービスに代表されるように、インターネット上におけるリアルタイムの交流が私たちの日常生活に浸透している。さまざまなプラットフォームやプロバイダーがライブストリーミングサービスを提供しており、競争も激しい。プラットフォームにとって、ユーザが望むサービスを提供することが重要である。

中国特許出願公開第ＣＮ１１４２６８６３１Ａ号は、ネットワーク遅延の多次元的な低減を開示している。

中国特許出願公開第１１４２６８６３１号明細書

本発明の一実施態様による方法は、１以上のコンピュータによって実行されるデータアクセスのための方法であって、ユーザ端末のユーザから要求を取得する工程と、当該要求に対応するバックエンドサーバのステータスデータを取得する工程と、当該ステータスデータに基づき、当該要求に対応する当該バックエンドサーバに当該要求を送信する工程と、当該バックエンドサーバから当該要求の応答を取得する工程と、当該応答にエラーがあると判断する工程と、当該ステータスデータに基づき、当該バックエンドサーバに対する当該要求送信の再試行の遅延時間を決定する工程と、を含む。

本発明の一実施態様による方法は、１以上のコンピュータによって実行されるデータアクセスのための方法であって、ユーザ端末のユーザから要求を取得する工程と、当該要求のタイプと、当該ユーザの要求許容度データを取得する工程と、当該要求のタイプと当該ユーザの当該要求許容度データに基づき、当該要求に対応するバックエンドサーバに当該要求を送信するための遅延時間を決定する工程と、を含む。

本発明の一実施形態によるシステムは、１以上のプロセッサを含むデータアクセスのためのシステムであって、当該１以上のコンピュータプロセッサが、機械可読命令を実行して、ユーザ端末のユーザから要求を取得する工程と、当該要求に対応するバックエンドサーバのステータスデータを取得する工程と、当該ステータスデータに基づき、当該要求に対応する当該バックエンドサーバに当該要求を送信する工程と、当該バックエンドサーバから当該要求の応答を取得する工程と、当該応答にエラーがあると判断する工程と、当該ステータスデータに基づき、当該バックエンドサーバに対する当該要求送信の再試行の遅延時間を決定する工程と、を実行する。

本発明の一部の実施態様に基づくライブストリーミングシステム１の構成を示す概略図である。 本発明の一部の実施態様に基づく、図１のユーザ端末３０の機能と構成を示すブロック図である。 本発明の一部の実施態様に基づく、図１のサーバの機能と構成を示すブロック図である。 図３のストリームＤＢ３１０の例示的データ構造を示す表である。 図３のユーザＤＢ３１２の例示的データ構造を示す表である。 図３の贈り物ＤＢ３１４の例示的データ構造を示す表である。 本発明の一部の実施態様に基づく、サーバ１０及びユーザ端末３０の機能と構成を示すブロック図である。 要求ＤＢ２５０の例示的データ構造を示す表である。 ユーザ許容度ＤＢ２５２の例示的データ構造を示す表である。 再試行ＤＢ２５４の例示的データ構造を示す表である。 ステータスＤＢ３２０の例示的データ構造を示す表である。 本発明の一部の実施態様に基づく方法を示す例示的なフローチャートである。 本発明の一部の実施態様に基づく方法を示す例示的なフローチャートである。 本発明の一部の実施態様に基づくユーザ許容度データ生成の例である。 エンドポイントステータスデータと再試行数に基づく、送信再試行タイミングの決定の例である。 本発明の一部の実施態様に基づく例示的な時系列図である。 本発明の一部の実施態様に基づく例示的な時系列図である。 本発明の一部の実施態様に基づく例示的なデータアクセスフローである。 本発明の一部の実施態様に基づく情報処理装置のハードウェア構成例を示すブロック図である。

以下、各図面に示す同一または類似の構成要素、部材、手順または信号には、すべての図面において同様の符号を付し、それによって重複する説明は適宜省略される。また、各図面の説明において重要でない一部部材は省略される。

インターネットを介したデータアクセスには、通常、ユーザが使用するユーザ端末（スマートフォン、タブレット、コンピュータなど）、当該ユーザ端末上で動作するアプリケーション（またはライストリーミングアプリケーションソフトウェアなどのアプリケーションソフトウェア）、および当該ユーザ端末と通信する当該アプリケーションのサーバ（またはアプリケーションサーバ）などが関与する。

ユーザは、クリック、タップ、またはスクロールの動作を伴うことがあるアプリケーションのユーザインターフェースを通じて、データ要求を開始することができる。そして当該要求は、当該ユーザ端末から当該サーバに送信される。その後、当該サーバは当該要求に応じた応答を当該ユーザ端末に送信し、データアクセスが完了する。

当該サーバの状態（負荷状態やその他健全性の状態など）によって、データアクセスが成功するか否かが決まる場合がある。当該サーバに過負荷を生じることなく、当該サーバのリソースを効率的かつ動的に利用できるアクセスメカニズムが望まれる。

図１は、本発明の一部の実施態様に基づくライブストリーミングシステム１の構成を示す概略図である。当該ライブストリーミングシステム１は、ストリーミングのストリーマー（ライバー、アンカー、配信者、ライブストリーマーとも呼ばれる）ＬＶと視聴者（オーディエンスとも呼ばれる）ＡＵ（ＡＵ１、ＡＵ２...）に、リアルタイムで交流または通信するためのライブストリーミングサービスを提供する。図１に示すように、当該ライブストリーミングシステム１は、サーバ１０と、ユーザ端末２０と、ユーザ端末３０（３０ａ、３０ｂ...）を含む。一部の実施態様において、当該ストリーマーと視聴者は、集合的にユーザと呼ばれてもよい。当該サーバ１０は、ネットワークＮＷに接続された、１以上の情報処理装置を含むことができる。当該ユーザ端末２０、３０は、例えば、スマートフォン、タブレット、ノートＰＣ、レコーダー、携帯ゲーム機、ウェアラブル端末などのモバイル端末装置、あるいはデスクトップＰＣなどの据え置き型装置であってもよい。当該サーバ１０、当該ユーザ端末２０及び当該ユーザ端末３０は、各種有線または無線ネットワークＮＷを介して相互に通信可能に接続される。

当該ライブストリーミングシステム１には、配信者ＬＶ、視聴者ＡＵ、及び当該サーバ１０を管理する管理者（またはアプリプロバイダー、図示せず）が参加する。当該配信者ＬＶは、自身のユーザ端末２０でコンテンツを記録し、当該サーバ１０に直接または間接的にアップロードすることにより、リアルタイムで当該コンテンツを配信する者である。当該コンテンツの例としては、当該配信者自身の歌、トーク、パフォーマンス、ゲームプレイ、その他あらゆるコンテンツであってもよい。当該管理者は、当該サーバ１０上で当該コンテンツをライブストリーミングするためのプラットフォームを提供するとともに、当該配信者ＬＶと当該視聴者ＡＵ間のリアルタイムの交流を仲介または管理する。当該視聴者ＡＵは、自分のユーザ端末３０で当該プラットフォームにアクセスし、所望のコンテンツを選択して視聴する。当該視聴者ＡＵは、選択したコンテンツのライブストリーミング中に、当該ユーザ端末３０を介してコメントや応援、贈り物の送信などの操作を実行する。当該コンテンツを配信している当該配信者ＬＶは、それらのコメント、応援、または贈り物に対して応答してもよい。当該応答が、映像および（または）音声で当該視聴者ＡＵに送信され、双方向のコミュニケーションが確立される。

「ライブストリーミング」という用語は、当該配信者ＬＶのユーザ端末２０で記録したコンテンツを、当該視聴者ＡＵのユーザ端末３０で実質的にリアルタイムに再生・視聴することを可能にするデータ伝送モードを指しても、そのような伝送モードにより実現されるライブブロードキャストを指してもよい。当該ライブストリーミングは、ＨＴＴＰライブストリーミング、ＣＭＡＦ（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ）、ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ－Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＲＴＭＰ（Ｒｅａｌ―Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＭＰＥＧ ＤＡＳＨなどの既存のライブストリーミング技術を利用して実現されてもよい。ライブストリーミングには、当該配信者ＬＶによるコンテンツの記録と同時に、当該視聴者ＡＵが所定の遅延をもって当該コンテンツを視聴でき伝送モードを含む。当該遅延の長さについては、当該配信者ＬＶと当該視聴者ＡＵの交流が成立可能な程度の遅延であってもよい。なお、当該ライブストリーミングは、当該コンテンツの全記録データを一度当該サーバに格納し、その後ユーザの要求に応じて当該サーバから当該ユーザに提供する、いわゆるオンデマンド配信と区別される。

ここでいう「映像データ」とは、当該ユーザ端末２０または３０の撮像機能を用いて生成された画像データ（映像データとも呼ばれる）と、当該ユーザ端末２０または３０の音声入力機能を用いて生成された音声データとを含むデータを指す。当該映像データは、当該ユーザがコンテンツを視聴できるように、当該ユーザ端末２０、３０で再生される。一部の実施態様において、当該配信者のユーザ端末における映像データの生成と当該視聴者のユーザ端末における映像データの再生との間に、当該映像データに対して圧縮、展開、符号化、復号化、トランスコーディングなど、その形式、サイズ、またはデータの仕様を変更する処理が行われると想定される。しかし、そのような処理の前後で、当該映像データが表す当該コンテンツ（例えば、映像や音声）は実質的に変化しないため、本明細書においては、そのような処理後の当該映像データを、そのような処理前の当該映像データと同一ものと表現している。すなわち、当該配信者のユーザ端末で映像データが生成された後、当該サーバ１０を介して当該視聴者のユーザ端末で再生される場合、当該配信者のユーザ端末で生成された当該映像データ、当該サーバ１０を通過する当該映像データ、および当該視聴者のユーザ端末で受信して再生される当該映像データは、いずれも同一の映像データである。

図１に示す例において、当該配信者ＬＶは、ライブストリーミングデータを提供する。当該配信者ＬＶのユーザ端末２０は、当該配信者ＬＶの映像や音声を記録して当該ストリーミングデータを生成し、生成された当該データは当該ネットワークＮＷを介して当該サーバ１０に送信される。同時に、当該ユーザ端末２０は、当該配信者ＬＶの記録された映像ＶＤを当該ユーザ端末２０のディスプレイに表示し、当該配信者ＬＶが現在行っているライブストリーミングコンテンツを確認できるようにする。

当該プラットフォームに当該配信者ＬＶのライブストリーミングを視聴することを要求した当該視聴者ＡＵ１、ＡＵ２のそれぞれのユーザ端末３０ａ、３０ｂは、当該ネットワークＮＷを介して当該ライブストリーミングに関連する映像データ（以下、「ライブストリーミングの映像データ」と呼ばれてもよい）を受信し、受信した当該映像データを再生して当該映像ＶＤ１、ＶＤ２をディスプレイに表示し、スピーカーから音声を出力する。当該ユーザ端末３０ａ、３０ｂでそれぞれ表示される映像ＶＤ１、ＶＤ２は、当該配信者ＬＶの当該ユーザ端末２０により撮像された映像ＶＤと実質的に同じであり、当該ユーザ端末３０ａ、３０ｂで出力される音声は、当該配信者ＬＶの当該ユーザ端末２０で記録された音声と実質的に同じである。

当該配信者ＬＶの当該ユーザ端末２０での映像・音声の記録と、当該視聴者ＡＵ１、ＡＵ２の当該ユーザ端末３０ａ、３０ｂでの映像データの再生は、実質的に同時に行われる。当該視聴者ＡＵ１が、当該配信者ＬＶにより提供される当該コンテンツに関するコメントを当該ユーザ端末３０ａに入力すると、当該サーバ１０は当該コメントを配信者ＬＶの当該ユーザ端末３０ａにリアルタイムで表示するとともに、当該視聴者ＡＵ１とＡＵ２の当該ユーザ端末３０ａと３０ｂにも当該コメントをそれぞれ表示する。当該配信者ＬＶが当該コメントを読み、当該コメントに対応するトークを展開すると、そのトークの映像と音声が、それぞれ当該視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂに表示される。このインタラクティブな動作は、当該配信者ＬＶと当該視聴者ＡＵ１間で会話が成立していると認識される。これにより、当該ライブストリーミングシステム１では、一方的なコミュニケーションではなく、双方向のコミュニケーションを可能にするライブストリーミングを実現する。

図２は、本発明の一部の実施態様に基づく、図１のユーザ端末３０の機能と構成を示すブロック図である。当該ユーザ端末２０は、当該ユーザ端末３０と同じまたは類似した機能と構成を有する。図２の各ブロックと以降のブロック図は、ハードウェアがコンピュータのＣＰＵや機械装置などの要素によって実現されてもよく、ソフトウェアがコンピュータプログラムなどによって実現されてもよい。機能ブロックは、これらの要素間の連携動作により実現されてもよい。したがって、これらの機能ブロックは、ハードウェアとソフトウェアの組み合わせによる多様な形態で実現され得ることが、当業者には理解されよう。

当該配信者ＬＶ及び当該視聴者ＡＵは、当該ネットワークＮＷを介してダウンロードサイトからライブストリーミングアプリケーションプログラム（以下、ライブストリーミングアプリケーションという）をダウンロードし、当該ユーザ端末２０、３０にインストールしてもよい。あるいは、当該ライブストリーミングアプリケーションは、当該ユーザ端末２０と３０に予めインストールされていてもよい。当該ライブストリーミングアプリケーションが当該ユーザ端末２０、３０上で実行されると、当該ユーザ端末２０、３０は、当該ネットワークＮＷを介して当該サーバ１０と通信し、各種機能を実装または実行する。以下、当該ライブストリーミングアプリケーションが実行されるユーザ端末２０、３０（ＣＰＵなどのプロセッサ）によって実装される機能を、当該ユーザ端末２０、３０の機能として説明する。これらの機能は、実際には、当該ユーザ端末２０、３０上で当該ライブストリーミングアプリケーションにより実現される。一部の実施態様において、これらの機能は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などのプログラミング言語で記述され、当該サーバ１０から当該ネットワークＮＷを介して当該ユーザ端末２０、３０のウェブブラウザに送信され、当該ウェブブラウザにより実行されるコンピュータプログラムによって実現されてもよい。

当該ユーザ端末３０は、配信ユニット１００と視聴ユニット２００を含む。当該配信ユニット１００は、当該ユーザ（またはユーザ側）の映像と音声が記録された映像データを生成し、当該映像データを当該サーバ１０に提供する。当該視聴ユニット２００は、当該サーバ１０から映像データを受信し、当該映像データを再生する。当該ユーザは、ライブストリーミングを行う際に、当該配信ユニット１００を起動し、当該ユーザが映像を視聴する際に、当該視聴ユニット２００を起動する。当該配信ユニット１００が起動される当該ユーザ端末は、当該配信者の端末、すなわち、当該映像データを生成する当該ユーザ端末である。当該視聴ユニット２００が起動される当該ユーザ端末は、当該視聴者の端末、即ち、当該映像データが再現され、再生される当該ユーザ端末である。

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

当該視聴ユニット２００は、視聴者側ＵＩコントロールユニット２０２と、重ね合わせ情報生成ユニット２０４と、入力情報送信ユニット２０６を含む。当該視聴ユニット２００は、当該ネットワークＮＷを介して当該サーバ１０から、当該配信者、当該ユーザ端末３０のユーザである視聴者、及び他の視聴者が参加する、ライブストリーミングに関連する映像データを受信する。当該視聴者側ＵＩコントロールユニット２０２は、当該視聴者のＵＩを制御する。当該視聴者側ＵＩコントロールユニット２０２は、ディスプレイとスピーカー（図２に表示せず）に接続され、受信した映像データを再生して、当該ディスプレイに映像を表示し、当該スピーカーから音声を出力する。当該映像が当該ディスプレイに出力され、当該音声が当該スピーカーから出力されている状態を「映像データが再生されている」状態と呼ぶことができる。当該視聴者側ＵＩコントロールユニット２０２は、タッチパネル、キーボード、ディスプレイ等の入力手段（図２に表示せず）にも接続され、当該入力手段を介してユーザの入力を取得する。当該重ね合わせ情報生成ユニット２０４は、当該サーバ１０からの映像データから生成された画像上に、所定のフレーム画像を重ねる。当該フレーム画像には、当該ユーザからの入力を受け付けるためのさまざまなユーザインターフェイスオブジェクト（以下、単に「オブジェクト」という）、当該視聴者により入力されたコメント、及び（または）当該サーバ１０から取得した情報などが含まれる。当該入力情報送信ユニット２０６は、当該ネットワークＮＷを介して、当該視聴者側ＵＩコントロールユニット２０２により取得された当該ユーザ入力を当該サーバ１０に送信する。

図３に、本発明の一部の実施態様に基づく、図１の当該サーバ１０の機能と構成を示すブロック図を示す。当該サーバ１０は、配信情報提供ユニット３０２と、中継ユニット３０４と、贈り物処理ユニット３０６と、支払い処理ユニット３０８と、ストリームＤＢ３１０と、ユーザＤＢ３１２と、贈り物ＤＢ３１４を含む。

当該配信者側の当該ユーザ端末２０から当該ネットワークＮＷを介してライブストリーミングの開始通知または要求を受信すると、当該配信情報提供ユニット３０２は、このライブストリーミングを識別するためのストリームＩＤと当該ライブストリーミングを行う配信者の配信者ＩＤをストリームＤＢ３１０に登録する。

当該配信情報提供ユニット３０２が、当該ネットワークＮＷを介して当該視聴者側の当該ユーザ端末３０の当該視聴ユニット２００からライブストリームに関する情報の提供要求を受信すると、当該配信情報提供ユニット３０２は、当該ストリームＤＢ３１０から現在利用可能なライブストリームを取得または確認し、利用可能なライブストリームのリストを作成する。当該配信情報提供ユニット３０２は、作成したリストを当該ネットワークＮＷ経由で要求元の当該ユーザ端末３０に送信する。要求元の当該ユーザ端末３０の当該視聴者側ＵＩコントロールユニット２０２は、受信したリストに基づいてライブストリーム選択画面を生成し、当該ユーザ端末３０のディスプレイ上に表示する。

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

当該中継ユニット３０４は、当該配信情報提供ユニット３０２により開始された当該ライブストリーミングにおいて、配信者側の当該ユーザ端末２０から視聴者側の当該ユーザ端末３０に当該映像データを中継する。当該中継ユニット３０４は、当該ライブストリーミング中または当該映像データの再生中に、当該入力情報送信ユニット２０６から視聴者によるユーザ入力を表す信号を受信する。当該ユーザ入力を表す信号は、当該ユーザ端末３０のディスプレイに表示されたオブジェクトを指定するオブジェクト指定信号であってもよい。当該オブジェクト指定信号は、当該視聴者の視聴者ＩＤ、当該視聴者が視聴しているライブストリームの配信者の配信者ＩＤ、及び当該オブジェクトを特定するオブジェクトＩＤを含んでもよい。当該オブジェクトが贈り物であるとき、当該オブジェクトＩＤは贈り物ＩＤである。同様に、当該中継ユニット３０４は、当該ユーザ端末２０の当該配信ユニット１００から、当該映像データの再生中（またはライブストリーミング中）に配信者により行われたユーザ入力を表す信号を受信する。当該信号は、オブジェクト指定信号であってもよい。

また、当該ユーザ入力を表す信号は、視聴者が当該ユーザ端末３０に入力したコメントと当該視聴者の視聴者ＩＤを含むコメント入力信号であってもよい。当該コメント入力信号を受信すると、当該中継ユニット３０４は、当該コメントと信号に含まれる当該視聴者ＩＤを、当該配信者の当該ユーザ端末２０と他の視聴者の当該ユーザ端末３０に送信する。これらユーザ端末２０、３０において、当該視聴者側ＵＩコントロールユニット２０２と、当該重ね合わせ情報生成ユニット２０４は、同じく受信した当該視聴者ＩＤと関連付けられたディスプレイ上に受信したコメントを表示する。

当該贈り物処理ユニット３０６は、当該オブジェクト指定信号に含まれる贈り物ＩＤによって特定される贈り物のポイントに基づき、当該配信者のポイントを増加させ、当該ユーザＤＢ３１２を更新する。具体的には、当該贈り物処理ユニット３０６は、当該贈り物ＤＢ３１４を参照して、受信した当該オブジェクト指定信号に含まれる当該贈り物ＩＤに対して付与するポイントを特定する。その後、当該贈り物処理ユニット３０６は、当該ユーザＤＢ３１２を更新し、当該オブジェクト指定信号に含まれる当該配信者ＩＤの（または当該配信者ＩＤに対応する）ポイントに、特定されたポイントを追加する。

当該支払い処理ユニット３０８は、当該オブジェクト指定信号の受信に応答して、視聴者からの贈り物の代金の支払いを処理する。具体的には、当該支払い処理ユニット３０８は、当該贈り物ＤＢ３１４を参照して、当該オブジェクト指定信号に含まれる当該贈り物ＩＤにより特定される当該贈り物の価格ポイントを特定する。その後、当該支払い処理ユニット３０８は、当該ユーザＤＢ３１２を更新し、当該オブジェクト指定信号に含まれる当該視聴者ＩＤにより特定される当該視聴者のポイントから、特定された当該価格ポイントを差し引く。

図４は、図３のストリームＤＢ３１０の例示的データ構造を示す表である。当該ストリームＤＢ３１０は、現在行われているライブストリームに関する情報を保持する。当該ストリームＤＢ３１０は、ストリームＩＤ、配信者ＩＤ、視聴者ＩＤを、相互に関連付けて格納する。当該ストリームＩＤは、当該ライブストリーミングシステム１により提供されるライブストリーミングプラットフォームにおけるライブストリームを識別するためのＩＤである。当該配信者ＩＤは、当該ライブストリームを提供する配信者を識別するためのユーザＩＤである。当該視聴者ＩＤは、当該ライブストリームの視聴者を識別するためのユーザＩＤである。一部の実施態様による当該ライブストリーミングシステム１により提供されるライブストリーミングプラットフォームにおいて、ユーザがライブストリームを開始すると、当該ユーザは配信者となり、同じユーザが別のユーザによりブロードキャストされるライブストリームを視聴すると、当該ユーザは視聴者にもなる。したがって、配信者と視聴者の区別は固定されておらず、あるとき配信者ＩＤとして登録されたユーザＩＤが、別のときに視聴者ＩＤとして登録されることもあり得る。

図５は、図３のユーザＤＢ３１２の例示的データ構造を示す表である。当該ユーザＤＢ３１２は、ユーザに関する情報を保持する。当該ユーザＤＢ３１２は、当該ユーザＩＤと当該ポイントを、相互に関連付けて格納する。当該ユーザＩＤは、ユーザを識別する。当該ポイントは、対応する当該ユーザが保持するポイントに相当する。当該ポイントは、当該ライブストリーミングプラットフォーム内で流通する電子的な価値である。一部の実施態様において、配信者がライブ配信中に視聴者から贈り物を受け取ると、当該配信者のポイントは当該贈り物に対応する価値だけ増加する。当該ポイントは、例えば、当該配信者が当該ライブストリーミングプラットフォームの管理者から受け取る報酬（金銭など）の量を決定するために使用される。一部の実施態様において、当該配信者が視聴者から贈り物を受け取る際に、当該ポイントに代えて、当該贈り物に対応する金額を付与してもよい。

図６は、図３の贈り物ＤＢ３１４の例示的データ構造を示す表である。当該贈り物ＤＢ３１４は、当該ライブストリーミング中に当該視聴者が利用できる贈り物についての情報を保持する。贈り物は、電子データである。贈り物は、ポイントまたは金銭で購入するか、無償で提供することができてもよい。贈り物は、視聴者が配信者に贈ることができる。配信者に贈り物を贈ることは、贈り物を使う、贈り物を送る、贈り物を投げるなどとも呼ばれる。贈り物の中には、購入と同時に使用できるものと、購入後、購入した視聴者が後から任意のタイミングで使用できるものとがある。視聴者が配信者に贈り物を贈ると、当該贈り物に対応する量のポイントが当該配信者に付与される。贈り物が使用されると、その使用によって当該贈り物に関連するエフェクトが発生してもよい。例えば、ライブストリーミング画面に当該贈り物に対応したエフェクト（視覚的効果や聴覚的効果など）が表示される。

当該贈り物ＤＢ３１４は、贈り物ＩＤ、付与ポイント、価格ポイントを、相互に関連付けて格納する。当該贈り物ＩＤは、贈り物を識別するためのものである。当該付与ポイントは、配信者に贈り物が贈られたときに当該配信者に付与されるポイントの量である。当該価格ポイントは、贈り物の使用（購入）に対して支払われるポイントの量である。視聴者は、ライブストリームを視聴しているときに、所望の贈り物の当該価格ポイントを支払うことで、配信者に当該所望の贈り物を贈ることができる。当該価格ポイントの支払いは、適宜の電子決済手段により行うことができる。例えば、視聴者が管理者に当該価格ポイントを支払うことにより、支払いが行われてもよい。あるいは、銀行振り込みやクレジットカードによる支払いが利用されてもよい。当該管理者は、当該付与ポイントと当該価格ポイントとの関係を任意に設定することができる。例えば、付与ポイント＝価格ポイントとして設定してもよい。あるいは、当該付与ポイントに１.２などの所定の係数を乗じたポイントを当該価格ポイントとして設定しても、当該付与ポイントに所定の手数料ポイントを加算したポイントを当該価格ポイントとして設定してもよい。

図７に、本発明の一部の実施態様に基づく、サーバ１０及びユーザ端末３０の機能と構成を示すブロック図を示す。

当該ユーザ端末３０は、取得ユニット２２０と、送信ユニット２２２と、決定ユニット２２４と、要求ＤＢ２５０と、ユーザ許容度ＤＢ２５２と、再試行ＤＢ２５４と、を含む。当該サーバ１０は、ステータスＤＢ３２０と、機械学習ＤＢ３２４を含む。一部の実施態様において、当該機械学習ＤＢ３２４は、当該ユーザ端末３０内に実装されてもよい。

当該取得ユニット２２０は、当該ユーザ端末３０のユーザからの要求（またはＡＰＩ要求）を取得するように構成される。当該要求は、当該ユーザ端末３０のユーザインターフェースを介して当該ユーザにより開始されてもよい。当該取得ユニット２２０は、当該要求に対応するバックエンドサーバ（またはバックエンドサーバのエンドポイント）のステータスデータ（またはステータス予測）を取得するように構成される。当該バックエンドサーバは、当該サーバ１０であってもよい。当該ステータスデータは、当該サーバ１０の当該ステータスＤＢから取得されてもよい。

当該送信ユニット２２２は、当該ステータスデータに基づき（または当該ステータスデータに応答して）、当該要求に対応する当該バックエンドサーバ（または当該エンドポイント）に当該要求を送信するように構成される。例えば、当該送信ユニット２２２は、当該バックエンドサーバの健全性状態に基づき、当該要求を直ちに送信するか、一定時間後に送信するかを決定してもよい。

当該取得ユニット２２０は、当該バックエンドサーバから当該要求の応答を取得するように構成される。

当該決定ユニット２２４は、当該応答にエラーがあるか否かを判断するように構成される。当該応答にエラーがある場合、当該決定ユニット２２４は、当該ステータスデータに基づき、当該バックエンドサーバに対する当該要求の送信を再試行するための遅延時間を決定する。

一部の実施態様において、当該決定ユニット２２４は、当該ステータスデータに基づき、当該要求を当該バックエンドサーバに送信する再試行回数の合計数を決定する。

一部の実施態様において、当該遅延時間は、当該ステータスデータと当該再試行の再試行数に基づいて決定される。

一部の実施態様において、当該決定ユニット２２４は、当該遅延時間が当該バックエンドサーバの（当該ステータスＤＢ３２０内の）当該ステータスデータの更新期間よりも長いか否かを判断する。「はい」の場合、当該取得ユニット２２０は、当該バックエンドサーバの更新されたステータスデータを取得し、当該決定ユニット２２４は、当該更新されたステータスデータに基づき、当該再試行の遅延時間を更新する。

一部の実施態様において、当該取得ユニット２２０は、当該ユーザのステータスを取得（または検出）し、当該要求のタイプを取得（または検出）する。当該遅延時間は、当該エンドポイントの当該ステータスデータ、当該ユーザの当該ステータス、及び（または）当該要求の当該タイプに応じて決定されてもよい。当該ユーザの当該ステータスは、当該ユーザＤＢ３１２及び（または）当該要求ＤＢ２５０に格納されていてもよい。当該要求の当該タイプは、当該要求ＤＢ２５０に格納されていてもよい。

一部の実施態様において、当該取得ユニット２２０は、当該ユーザの許容度データを取得し、当該要求のタイプを取得する。当該遅延時間は、さらに当該ユーザの許容度データと当該要求のタイプに基づいて決定されてもよい。当該許容度データは、当該ユーザ許容度ＤＢ２５２に格納されていてもよい。

一部の実施態様において、当該決定ユニット２２４は、当該ユーザの当該許容度データに基づき、当該要求のタイプに関して当該ユーザの許容度が低いと判断された場合に、当該遅延時間を短くするように決定する。一部の実施態様において、当該決定ユニット２２４は、当該ユーザの当該許容度データに基づき、当該要求のタイプに関して当該ユーザの許容度が高いと判断された場合に、当該遅延時間を長くするように決定する。

図８は、要求ＤＢ２５０の例示的データ構造を示す表である。当該要求ＤＢ２５０は、要求ＩＤ、要求タイミング、ユーザＩＤ、ユーザステータス、要求タイプ、ストリームＩＤを相互に関連付けて格納する。

当該ユーザステータスは、当該ユーザから当該要求が行われたときの当該ユーザの状態である。例えば、当該要求Ｒ１（課金する）は、ユーザＵ１がストリームＳ１を視聴する視聴者であるときに、当該ユーザＵ１によって行われる。当該要求Ｒ４（課金する）は、ユーザＵ１がストリームＳ３を配信する配信者であるときに、当該ユーザＵ１によって行われる。当該要求タイプ「課金」は、当該ストリーミングプラットフォームに金銭やポイントを課金する要求であってもよい。当該要求タイプ「贈り物送信」は、当該ストリーミングプラットフォームのチャットルーム（またはストリーム）内で贈り物を送信する要求であってもよい。当該要求タイプ「コメント」は、当該ストリーミングプラットフォームのチャットルーム（またはストリーム）内でコメントを投稿する要求であってもよい。「課金」などの一部の要求タイプは、当該ユーザがストリームを視聴しているとき、またはストリームを配信しているときに、当該ユーザによって実行されてもよい。一部の実施態様において、要求に対する正しい（または成功した）応答は、タスク完了の表示または対応する効果の表示であってもよい。

図９は、ユーザ許容度ＤＢ２５２の例示的データ構造を示す表である。当該ユーザ許容度ＤＢ２５２は、ユーザＩＤ、要求タイプ、最大待機時間（または遅延閾値時間）を相互に関連付けて格納する。

当該最大待機時間は、対応する要求タイプを完了するために、当該ユーザが許容できる最大の時間長さである。例えば、ユーザＵ１は贈り物の送信に６秒より長い待機時間を許容できない。ユーザＵ１は、「フォロー」要求が完了するまで１５秒待つことができる。「フォロー」要求とは、当該配信者のストリームでパフォーマンスを行った配信者をフォローする要求である。当該許容度データは、当該機械学習ＤＢ３２４内の機械学習アルゴリズムによって生成されてもよい。

一部の実施態様において、全体的な応答割り当てのために、各ユーザの当該許容度データが当該サーバ１０に送信され、格納されてもよい。例えば、当該サーバ１０（または当該サーバ１０内の割り当てユニット）は、異なるユーザからの要求に対する応答を返すタイミングを、それぞれの許容度データに基づいて割り当ててもよい。例えば、当該サーバ１０の負荷が高い状況下では、許容度の低いユーザＵ１からの要求Ｒ１は、許容度の高いユーザＵ２からの要求Ｒ２よりも早く応答されてもよい。このメカニズムにより、ユーザの全般的な満足度を最適化し、プラットフォーム全体の収益を向上させることができる。

図１０は、再試行ＤＢ２５４の例示的データ構造を示す表である。当該再試行ＤＢ２５４は、要求についての再試行データ（または再試行プラン、再試行スケジュール）を格納する。当該再試行ＤＢ２５４は、要求ＩＤ、ユーザＩＤ、要求の待機時間（または遅延時間）、現在の再試行数（再試行回数の現在の数字）、最大再試行数（再試行回数の合計数）を相互に関連付けて格納する。

当該再試行データは、当該決定ユニット２２４によって決定される。一部の実施態様において、要求の当該再試行データは、対応するエンドポイントのステータスデータ、当該ユーザのステータス、当該要求のタイプ、及び（または）当該ユーザの許容度データによって決定される。

図１１は、ステータスＤＢ３２０の例示的データ構造を示す表である。当該ステータスＤＢ３２０は、当該エンドポイント（またはＡＰＩエンドポイント）、対応する要求タイプ、健全性スコア（または健全性ステータス）を相互に関連付けて格納する。

当該健全性スコアは、当該エンドポイントのパラメータに基づいて計算されてもよい。当該計算は、実際の運用やストリーミングプラットフォーム運営者の重点に応じて決定されてもよい。当該計算は、当該機械学習ＤＢ３２４内の機械学習アルゴリズムによって実行されてもよい。当該計算において、正規化が実行されてもよい。当該エンドポイントの当該パラメータのいくつかの例としては、過去のＡＰＩ応答時間、過去の応答エラー率、過去のスループット、過去の待機時間、当該エンドポイントをホストするサーバのＣＰＵ使用率、当該エンドポイントをホストするサーバのメモリ使用率、当該エンドポイントをホストするサーバによって処理される同時接続数などがある。

図１２は、本発明の一部の実施態様に基づく方法を示す例示的なフローチャートである。

工程Ｓ１１００において、当該取得ユニット２２０は、例えば、当該ユーザ端末のＵＩを介して、ユーザＵ１からの要求を取得する。

工程Ｓ１１０２において、当該取得ユニット２２０は、当該ステータスＤＢ３２０から、当該要求に対応する当該エンドポイントの当該ステータスデータを取得する。

工程Ｓ１１０４において、当該送信ユニット２２２は、当該要求を当該エンドポイントに送信する。当該要求を送信する前に、当該エンドポイントは当該ステータスデータに基づき十分に健全な状態であると（当該決定ユニット２２４または当該送信ユニット２２２によって）判断されてもよい。

工程Ｓ１１０６において、当該取得ユニット２２０は、当該応答を取得する。当該決定ユニット２２４は、当該応答にエラーがあると判断する。

工程Ｓ１１０８において、当該決定ユニット２２４は、当該ステータスデータに基づき、当該要求送信の再試行回数の合計数を決定する。

工程Ｓ１１１０において、当該決定ユニット２２４は、当該ステータスデータ（または更新されたステータスデータ）及び（または）当該再試行の当該再試行数に基づき、各送信再試行（またはこれから行われる送信再試行）の遅延時間を決定（または更新）する。

工程Ｓ１１１２において、当該決定ユニット２２４は、（工程Ｓ１１１０で決定された）当該遅延時間が、当該ステータスデータのステータス更新期間よりも長いか否かを判断する。「はい」の場合、フローは工程Ｓ１１１４に進む。「いいえ」の場合、フローは工程Ｓ１１１６に進む。一部の実施態様において、工程Ｓ１１１２で、当該決定ユニット２２４は、前回の当該遅延時間の決定から当該エンドポイントのステータスが更新されたか否かを判断する。

工程Ｓ１１１４において、当該取得ユニット２２０は、当該エンドポイントの更新された当該ステータスデータを取得する。その後、フローは工程Ｓ１１１０に戻り、当該決定ユニット２２４は、更新された当該ステータスデータに基づき、各送信再試行（またはこれから行われる送信再試行）の当該遅延時間を更新する。

工程Ｓ１１１６において、当該送信ユニット２２２は、当該要求送信の再試行を実行する。当該取得ユニット２２０は、当該応答を取得する。当該決定ユニット２２４は、当該応答が成功か（エラーで）失敗かを判断する。成功の場合、フローは工程Ｓ１１２０に進み、データアクセスが完了する。「いいえ」の場合、フローは工程Ｓ１１１８に進む。

工程Ｓ１１１８において、再試行回数の数字が、例えば、当該ユーザ端末内のカウンターによって、更新される。その後、フローは工程Ｓ１１１０に戻り、当該決定ユニット２２４は、当該ステータスデータと更新された当該再試行の再試行数に基づき、各送信再試行（またはこれから行われる送信再試行）の当該遅延時間を更新する。

図１３は、本発明の一部の実施態様に基づく方法を示す例示的なフローチャートである。

工程Ｓ１３０において、当該取得ユニット２２０は、ユーザＵ１から要求を取得する。

工程Ｓ１３２において、当該取得ユニット２２０は、当該ステータスＤＢ３２０から、当該要求に対応する当該エンドポイントの当該ステータスデータを取得する。

工程Ｓ１３４は、Ｓ１３４０、Ｓ１３４２、Ｓ１３４４の３つの工程を含む。

工程Ｓ１３４０において、当該取得ユニット２２０は、例えば、当該要求ＤＢ２５０から、ユーザＵ１のユーザステータスデータを取得する。

工程Ｓ１３４２において、当該取得ユニット２２０は、例えば、当該ユーザ許容度ＤＢ２５２から、ユーザＵ１のユーザ許容度データを取得する。

工程Ｓ１３４４において、当該取得ユニット２２０は、当該要求の当該要求タイプを取得または検出する。

工程Ｓ１３６において、当該決定ユニット２２４は、当該エンドポイントの当該ステータスデータ、当該ユーザステータス、当該ユーザ許容度データ、及び（または）当該要求タイプに基づいて、当該要求送信（初回または再試行）の当該遅延時間を決定する。

図１４は、本発明の一部の実施態様に基づくユーザ許容度データ生成の例である。

当該機械学習ＤＢ３２４に入力される特徴量データとしては、各ユーザの要求タイプシーケンス、各ユーザの待機時間シーケンス、各ユーザの退出行動データ（ストリーミングプラットフォームからの退出やストリームチャットからの退出の時間シーケンスなど）、各ユーザからのフィードバックデータ（苦情データなど）などがある。その後、当該機械学習ＤＢ３２４は、異なる要求タイプに関する各ユーザの許容度（または閾値）を示す当該ユーザ許容度データを生成する。当該ユーザ許容度データは、図９に示す例のようなものであってもよい。当該許容度は、当該ユーザにとっての要求許容度データと呼ばれてもよい。

例えば、当該機械学習ＤＢ３２４は、特徴量データの相関分析を実行し、各ユーザについて、どの要求タイプの待機時間が退出行動（及び（または）苦情行動）と最も相関しているかを判断し、関連の閾値を見出してもよい。当該閾値は、当該ユーザがチャットルーム（またはプラットフォーム）を出るまで待つことができる最大待機時間であってもよく、したがって当該遅延時間の最大値として設定することができる。異なるユーザは、異なる要求タイプに関して異なる許容度を有することができる。本発明は、ユーザごとに要求送信の遅延時間を決定するためのカスタマイズされたメカニズムを提供する。

一部の実施態様において、当該決定ユニット２２２は、当該エンドポイントの当該ステータスデータが、そのエンドポイントにとってより良い状態を示す場合、当該再試行回数の合計数が多くなるように決定する。一部の実施態様において、当該決定ユニット２２２は、当該エンドポイントの当該ステータスデータが、そのエンドポイントにとってより悪い状態を示す場合、当該再試行回数の合計数が少なくなるように決定する。より良い状態は、当該エンドポイント（またはサーバ）が当該要求を処理するために利用可能な処理能力がより多いことを意味してもよい。より悪い状態は、当該エンドポイントの負担が大きく、再試行回数が多いとクラッシュのリスクが高まり得ることを意味してもよい。

図１５に、エンドポイントステータスデータと再試行数に基づく、送信再試行タイミングの決定の例を示す。

本実施態様において、再試行の当該遅延時間は、遅延時間＝ｋ（ｎ*ｎ）＋ｙに基づいて決定される。ｋは、当該エンドポイントの健全性スコア（ステータスデータ）である。ｎは、ＡＰＩ呼び出しの失敗時間である。ｙは、要求の送信と応答の受信に要する時間である。図１５に示す数字は、［健全性スコア＝０.８、ｙ＝１秒］と仮定して計算される。健全性スコアｋは正規化されており、０から１の間である。本実施態様において、スコアが大きいほどエンドポイントの状態が悪いことを示す。状態が悪いと、当該サーバが要求のフローを処理し、バランス化するためにより多くの時間を必要とするため、当該遅延時間は当該健全性スコアとともに増加する。当該遅延時間は、再試行数（再試行回数の数字）が多いほど増加する。これは、再試行失敗の回数が多いほどサーバの状態が悪化し、当該サーバが回復や処理に長い時間を必要とするためである。この増加は直線的な増加よりも急激であり、当該サーバのより効率的な救済を達成することができる。

一部の実施態様において、当該決定ユニット２２４は、当該要求の潜在的な収益貢献度に基づいて、要求送信または再試行の当該遅延時間を決定する。当該潜在的な収益貢献度は、当該ユーザのステータスや当該要求タイプに関連していてもよい。例えば、ストリームを配信しているユーザからの要求タイプが「課金」である場合と比較して、ストリームを視聴しているユーザからの要求タイプが「課金」である場合、送信（または再試行）の遅延時間を短く（または送信優先度を高く）してもよい。当該ユーザがストリームを視聴しているとき、「課金」操作は、その後プラットフォームへの貢献度がより高い「贈り物」の操作につながる可能性がある。一部の実施態様において、ストリームを視聴しているユーザからの要求タイプが「ポーク」（ｐｏｋｉｎｇ）である場合と比較して、ストリームを配信しているユーザからの要求タイプが「ポーク」である場合、送信（または再試行）の遅延時間を短く（または送信優先度を高く）してもよい。配信者は、ポーク操作を使用して、視聴者にもっと交流するように、あるいはチャットルームでもっと貢献するように注意を喚起することができる。

一部の実施態様において、当該機械学習ＤＢ３２４は、異なる要求タイプ、異なるユーザステータス、およびその結果としての貢献度データに関する履歴データを利用して、それら３つの間の相関関係を判断し、要求送信（または送信再試行）の遅延時間（または優先度）を決定してもよい。

一部の実施態様において、潜在的貢献度の計算は、異なる要求タイプ間の依存関係や関係性に依存してもよい。例えば、視聴者からの贈り物リスト取得要求は、その後の贈り物要求につながる可能性があり、したがって、贈り物リストを取得する要求は、潜在的貢献度が高いとみなされてもよい。例えば、配信者からの視聴者リスト取得要求は、その後のポーク要求につながる可能性があり、それが視聴者の贈り物意欲を高める可能性があるため、当該視聴者リスト取得要求は貢献度が高いとみなされてもよい。一部の実施態様において、当該取得ユニット２２０は、異なる要求タイプ間の依存関係データを（例えば、当該サーバ１０内の要求ＤＢから）取得し、当該決定ユニット２２４はそれに基づいて、送信（または再送信）の遅延時間（または優先度）を決定する。例えば、貢献度の高い要求ほど、遅延時間を短く（または優先度を高く）することができる。

図１６は、本発明の一部の実施態様に基づく例示的な時系列図である。

バックエンド（ＢＥ）側のＡＰＩスコアサービス（またはステータスＤＢ）は、ＢＥ側のＡＩシステムに対してポーリング処理を実行し、エンドポイントのスコアを取得する。当該ＡＩシステムは、エンドポイントのスコアを計算及び（または）監視する。クライアント側のＵＩは、当該クライアント側のＡＰＩサービスにＡＰＩ要求を送信する。当該ＡＰＩサービスは対応するエンドポイントのステータスを当該ＡＰＩスコアサービスでチェックする。当該ステータスが問題なければ、当該ＡＰＩサービスは当該ＢＥ側の対応するエンドポイントに当該ＡＰＩ要求を送信する。当該クライアント側で受信した応答にエラーがあった場合、当該クライアント側のカウンターは再試行回数を１回増加させ、当該クライアント側のタイマーは送信再試行を行うための遅延時間をカウントする。当該遅延時間は、上述した方法に基づき、決定ユニットによって計算されてもよい。当該再試行後、正しいデータが当該クライアント側で受信され、当該ＵＩに提示される。

図１７は、本発明の一部の実施態様に基づく例示的な時系列図である。

バックエンド（ＢＥ）側のＡＰＩスコアサービス（またはステータスＤＢ）は、ＢＥ側のＡＩシステムに対してポーリング処理を実行し、エンドポイントのスコアを取得する。当該ＡＩシステムは、エンドポイントのスコアを計算及び（または）監視する。クライアント側のＵＩは、当該クライアント側のＡＰＩサービスにＡＰＩ要求を送信する。当該ＡＰＩサービスは対応するエンドポイントのステータスを当該ＡＰＩスコアサービスでチェックする。当該応答が、エンドポイントが要求を受信できる状態ではないことを示す。当該クライアントは当該要求を保留する。当該タイマーは遅延時間待ってから、当該要求を当該エンドポイントに送信する。当該遅延時間は、上述した方法に基づき、決定ユニットによって計算されてもよい。当該クライアント側で受信した応答にエラーがあった場合、当該クライアント側のカウンターは再試行回数を１回増加させ、当該タイマーは送信再試行を行うための遅延時間をカウントする。当該遅延時間は、上述した方法に基づき、当該決定ユニットによって計算されてもよい。当該再試行後、正しいデータが当該クライアント側で受信され、当該ＵＩに提示される。

図１８は、本発明の一部の実施態様に基づく例示的なデータアクセスフローである。一部の工程は図１６と図１７の説明と同じである。

当該クライアントは当該ＡＰＩサービスに対してＡＰＩ要求を呼び出す。当該ＡＰＩサービスは、当該ＡＰＩ要求に対応する当該エンドポイントの当該ステータスデータを当該ＡＰＩスコアサービスで確認する。

工程Ｓ１８０において、当該決定ユニット２２４は、当該ステータスデータに基づき、当該エンドポイントの状態が良好であるか否かを判断する。「はい」の場合、当該要求が当該エンドポイントに送信される。「いいえ」の場合、フローは工程Ｓ１８２に進む。

工程Ｓ１８２において、当該決定ユニット２２４は、当該エンドポイントの深刻度の状態に基づき、遅延時間待ってから当該要求を当該エンドポイントに送信するか否かを判断する。当該エンドポイントの状態が深刻ではなく、待つ必要がない場合、当該要求が当該エンドポイントに送信される。状態が深刻な場合、当該エンドポイントに当該要求を送信する前に、タイマーを使用して当該遅延時間がカウントされる。当該遅延時間は、上述した方法に基づき、決定されてもよい。

工程Ｓ１８４において、当該決定ユニット２２４は、当該エンドポイントからの当該応答が正しいか否かを判断する。当該応答が正しければ、当該正しいデータが当該ＡＰＩサービスに送信され、当該ＡＰＩサービスはそのデータをクライアントに送信する。当該応答にエラーが含まれている場合、フローは工程Ｓ１８６に進む。

工程Ｓ１８６において、当該決定ユニット２２４は、当該ＡＰＩ要求の送信に再試行を適用できるか否かを判断する。「はい」の場合、フローは工程Ｓ１８８に進む。「いいえ」の場合、エラーメッセージが当該ＡＰＩサービスに送信され、当該ＡＰＩサービスは当該エラーメッセージを当該クライアントに渡す。

工程Ｓ１８８において、当該決定ユニット２２４は、再試行回数が決定された最大再試行回数（上述の方法に従って決定されてもよいる）を超過したか否かを判断する。「いいえ」の場合、フローは工程Ｓ１９０に進む。「はい」の場合、エラーメッセージが当該ＡＰＩサービスに送信され、当該ＡＰＩサービスは当該エラーメッセージを当該クライアントに渡す。

工程Ｓ１９０において、カウンターが当該再試行回数を１増加させ、フローは工程Ｓ１８２に戻り、当該エンドポイントの更新されたステータスデータが、当該要求送信の再試行待機プロセスを決定するために使用される。

図１９を参照しながら、当該情報処理装置のハードウェア構成について説明する。図１９は、本発明の一部の実施態様に基づく情報処理装置のハードウェア構成例を示すブロック図である。図に示された情報処理装置９００は、例えば、一部の実施態様における、当該サーバ１０及び（または）当該ユーザ端末２０、３０を実現することができる。

当該情報処理装置９００は、ＣＰＵ９０１と、ＲＯＭ（リードオンリーメモリ）９０３と、ＲＡＭ（ランダムアクセスメモリ）９０５を含む。また、当該情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェイス９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２５、通信装置９２９を含んでもよい。さらに、当該情報処理装置９００は、カメラ（図示せず）などの撮像装置を含む。また、当該情報処理装置９００は、当該ＣＰＵ９０１に加えて、あるいは当該ＣＰＵ９０１の代わりに、ＤＳＰ（デジタルシグナルプロセッサ）やＡＳＩＣ（特定用途向け集積回路）を含んでもよい。

当該ＣＰＵ９０１は、演算処理装置および制御装置として機能し、当該ＲＯＭ９０３、当該ＲＡＭ９０５、当該ストレージ装置９１９、または当該リムーバブル記録媒体９２３に格納された各種プログラムに従って、当該情報処理装置９００のすべてまたは一部の動作を制御する。例えば、当該ＣＰＵ９０１は、一部の実施態様における当該サーバ１０及び当該ユーザ端末２０、３０に含まれる各機能ユニットの動作全般を制御する。当該ＲＯＭ９０３は、当該ＣＰＵ９０１が使用するプログラムや演算パラメータなどを格納する。当該ＲＡＭ９０５は、当該ＣＰＵ９０１の実行時に使用されるプログラムや、実行時に適宜変化するパラメータなどを格納する主記憶装置として機能する。当該ＣＰＵ９０１、ＲＯＭ９０３、ＲＡＭ９０５は、ホストバス９０７によって相互接続され、当該ホストバス９０７は、ＣＰＵバスなどの内部バスであってもよい。さらに、当該ホストバス９０７は、ブリッジ９０９を介してＰＣＩ（ペリフェラルコンポーネントインターコネクト／インターフェイス）バスなどの外部バス９１１に接続される。

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

当該出力装置９１７は、取得した情報を視覚的または聴覚的に当該ユーザに通知することができる装置である。当該出力装置９１７は、例えば、ＬＣＤ、ＰＤＰ、ＯＬＥＤ等のディスプレイ、スピーカーやヘッドフォン等の音声出力装置、プリンタなどであってもよい。当該出力装置９１７は、当該情報処理装置９００による処理結果を、テキスト、画像などの映像、または音声などのオーディオとして出力する。

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

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

当該接続ポート９２５は、当該情報処理装置９００に機器を直接接続するためのポートである。当該接続ポート９２５は、例えば、ＵＳＢ（ユニバーサルシリアルバス）ポート、ＩＥＥＥ１３９４ポート、またはＳＣＳＩ（小型計算機システムインターフェイス）ポートなどであってもよい。さらに、当該接続ポート９２５は、ＲＳ－２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（登録商標）（高精細度マルチメディアインターフェイス）ポートなどであってもよい。当該接続ポート９２５に当該外部接続装置９２７を接続することにより、当該情報処理装置９００と当該外部接続装置９２７との間で様々なデータのやり取りを行うことができる。

当該通信装置９２９は、例えば、当該ネットワークＮＷに接続するための通信装置で形成された通信インターフェイスである。当該通信装置９２９は、例えば、有線または無線のローカルエリアネットワーク（ＬＡＮ）、Ｂｌｕｅｔｏｏｔｈ（商標）、または、無線ＵＳＢ（ＷＵＳＢ）用の通信カードであってもよい。さらに、当該通信装置９２９は、光通信用のルータ、ＡＤＳＬ（非対称デジタル加入者線）用のルータ、または、各種通信用のモデムなどであってもよい。当該通信装置９２９は、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて、インターネット上や他の通信装置との間で信号等の送受信を行う。当該通信装置９２９に接続される当該通信ネットワークＮＷは、有線または無線で接続されるネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、電波通信、衛星通信などである。当該通信装置９２９は、通信装置としての機能を実現する。

当該撮像装置（図示せず）は、ＣＣＤ（電荷結合デバイス）やＣＭＯＳ（相補型金属酸化膜半導体）などの撮像素子と、当該撮像素子上の被写体像の結像を制御するためのレンズなど各種部材を用いて現実空間の画像を撮像し、撮像画像を生成する装置である。当該撮像装置は、静止画を撮像しても、動画を撮像してもよい。

以上、本実施態様に係る当該ライブストリーミングシステム１の構成及び動作について説明した。本実施態様は単なる一例であり、各構成要素や各処理の組み合わせについてさまざまな変更が可能であり、それらの変更も本発明の範囲内であることは当業者には理解されるところである。

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

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

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

１ 通信システム
１０ サーバ
２０ ユーザ端末
３０、３０ａ、３０ｂ ユーザ端末
ＬＶ 配信者
ＡＵ１、ＡＵ２ 視聴者
ＶＤ、ＶＤ１、ＶＤ２ 映像
ＮＷ ネットワーク
３０ ユーザ端末
１００ 配信ユニット
１０２ 撮像コントロールユニット
１０４ オーディオコントロールユニット
１０６ 映像送信ユニット
１０８ 配信者側ＵＩコントロールユニット
２００ 視聴ユニット
２０２ 視聴者側ＵＩコントロールユニット
２０４ 重ね合わせ情報生成ユニット
２０６ 入力情報送信ユニット
３０２ 配信情報提供ユニット
３０４ 中継ユニット
３０６ 贈り物処理ユニット
３０８ 支払い処理ユニット
３１０ ストリームＤＢ
３１２ ユーザＤＢ
３１４ 贈り物ＤＢ
２２０ 取得ユニット
２２２ 送信ユニット
２２４ 決定ユニット
２５０ 要求ＤＢ
２５２ ユーザ許容度ＤＢ
２５４ 再試行ＤＢ
３２０ ステータスＤＢ
３２４ 機械学習ＤＢ
Ｓ１１００、Ｓ１１０２、Ｓ１１０４、Ｓ１１０６、Ｓ１１０８、Ｓ１１１０、Ｓ１１１２、Ｓ１１１４、Ｓ１１１６、Ｓ１１１８、Ｓ１１２０ 工程
Ｓ１３０、Ｓ１３２、Ｓ１３４、Ｓ１３６、Ｓ１３４０、Ｓ１３４２、Ｓ１３４４ 工程
Ｓ１８０、Ｓ１８２、Ｓ１８４、Ｓ１８６、Ｓ１８８、Ｓ１９０ 工程
９００ 情報処理装置
９０１ ＣＰＵ
９０３ ＲＯＭ
９０５ ＲＡＭ
９０７ ホストバス
９０９ ブリッジ
９１１ 外部バス
９１３ インターフェイス
９１５ 入力装置
９１７ 出力装置
９１９ ストレージ装置
９２１ ドライブ
９２３ リムーバブル記録媒体
９２５ 接続ポート
９２７ 外部接続装置
９２９ 通信装置

Claims (9)

1. ユーザ端末により実行されるデータアクセスの方法であって、
   ユーザ端末のユーザから要求を取得する工程と、
   前記要求に対応するバックエンドサーバのステータスデータを取得する工程と、
   前記ステータスデータに基づき、前記要求に対応する前記バックエンドサーバに前記要求を送信する工程と、
   前記バックエンドサーバから前記要求の応答を取得する工程と、
   前記応答にエラーがあると判断する工程と、
   前記ステータスデータに基づき、前記要求を前記バックエンドサーバに送信する再試行のための遅延時間を決定する工程と、
   を含むことを特徴とする、データアクセスの方法。
2. さらに、前記ステータスデータに基づき、前記要求を前記バックエンドサーバに送信する再試行回数の合計数を決定する工程を含むことを特徴とする、請求項１に記載のデータアクセスの方法。
3. 前記遅延時間が、前記ステータスデータと前記再試行の再試行数に基づいて決定される、ことを特徴とする、請求項１に記載のデータアクセスの方法。
4. さらに、
   前記遅延時間が、前記ステータスデータの更新期間よりも長いと判断する工程と、
   更新されたステータスデータを取得する工程と、
   前記更新されたステータスデータに基づき、前記再試行の前記遅延時間を更新する工程と、
   を含むことを特徴とする、請求項１に記載のデータアクセスの方法。
5. さらに、
   前記ユーザのステータスを取得する工程と、
   前記要求のタイプを取得する工程と、
   を含み、前記遅延時間が、前記ステータスデータ、前記ユーザの前記ステータス、及び前記要求のタイプに基づいて決定される、ことを特徴とする、請求項１に記載のデータアクセスの方法。
6. さらに、
   前記ユーザの許容度データを取得する工程と、
   前記要求のタイプを取得する工程と、
   を含み、前記遅延時間が、さらに前記ユーザの前記許容度データと前記要求の前記タイプに基づいて決定される、ことを特徴とする、請求項１に記載のデータアクセスの方法。
7. さらに、
   前記ユーザの前記許容度データに基づき、前記要求のタイプに関して前記ユーザの許容度が低いと判断された場合に、前記遅延時間を短くするように決定する工程と、
   前記ユーザの前記許容度データに基づき、前記要求のタイプに関して前記ユーザの許容度が高いと判断された場合に、前記遅延時間を長くするように決定する工程と、
   を含むことを特徴とする、請求項６に記載のデータアクセスの方法。
8. 前記要求が、ライブストリーミングチャットルームにおける前記ユーザの操作に関連付けられ、前記許容度データが、異なる要求のタイプに対する当該ユーザの異なる許容度レベルの依存性を示す、ことを特徴とする、請求項７に記載のデータアクセスの方法。
9. 配信者分析のためのシステムであって、１以上のプロセッサを備え、そのうち、前記１以上のプロセッサが機械可読命令を実行して、
   ユーザ端末のユーザから要求を取得する工程と、
   前記要求に対応するバックエンドサーバのステータスデータを取得する工程と、
   前記ステータスデータに基づき、前記要求に対応する前記バックエンドサーバに前記要求を送信する工程と、
   前記バックエンドサーバから前記要求の応答を取得する工程と、
   前記応答にエラーがあると判断する工程と、
   前記ステータスデータに基づき、前記要求を前記バックエンドサーバに送信する再試行のための遅延時間を決定する工程と、
   を実行することを特徴とする、システム。

Images