特開 2025-9762 端末、方法及びコンピュータプログラム

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

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

(11)【公開番号】P2025009762

(43)【公開日】2025-01-20

(54)【発明の名称】端末、方法及びコンピュータプログラム

(51)【国際特許分類】

   H04N 21/437 20110101AFI20250109BHJP

   H04N 21/435 20110101ALI20250109BHJP

   H04N 21/4722 20110101ALI20250109BHJP

【ＦＩ】

H04N21/437

H04N21/435

H04N21/4722

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2024018181

(22)【出願日】2024-02-08

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

【原出願日】2023-06-28

(71)【出願人】

【識別番号】517287224

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

(74)【代理人】

【識別番号】100199277

【弁理士】

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

(72)【発明者】

【氏名】洪偉翔

(72)【発明者】

【氏名】郭柏逸

(72)【発明者】

【氏名】胡哲維

(72)【発明者】

【氏名】石宗台

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

5C164

【Ｆターム（参考）】

5C164FA06

5C164UB10P

5C164UB26P

5C164UB41S

5C164UD42P

5C164YA21

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

【課題】空白画面を表示するのではなく、リーダーボードデータなどの要求されたデータをネットワークの状態に関わらずユーザ端末に円滑に表示し、ユーザエクスペリエンスを向上する端末、方法及びコンピュータプログラムを提供する。
【解決手段】ライブストリーミングプラットフォームにおいてデータを処理するための端末は、１以上のプロセッサを備え、そのうち、当該１以上のプロセッサが機械可読命令を実行して、データの一部分に関する要求を送信する機能と、当該要求の応答を受信する機能と、当該応答が失敗であって当該データの一部分が第１の部分でないことに対応して再試行回数を設定する機能と、設定された当該再試行回数に基づいて再試行時間を決定する機能と、当該再試行時間の後に当該データの一部分に関する次の要求を送信する機能と、を実行する。
【選択図】図１４

【特許請求の範囲】

【請求項1】

ライブストリーミングプラットフォームにおいてデータを処理するための端末であって、１以上のプロセッサを含み、当該１以上のプロセッサが機械可読命令を実行して、
データの一部分に関する要求を送信する機能と、
前記要求の応答を受信する機能と、
前記応答が失敗であって前記データの一部分が第１の部分でないことに対応して再試行回数を設定する機能と、
設定された前記再試行回数に基づいて再試行時間を決定する機能と、
前記再試行時間の後に前記データの一部分に関する次の要求を送信する機能と、
実行する、ことを特徴とする、端末。

【請求項2】

前記再試行時間が固定値である、または前記再試行回数の増加とともに増加する、ことをさらに特徴とする、請求項１に記載の端末。

【請求項3】

前記要求が失敗であって前記データの一部分が前記第１の部分であることに対応して前記データの一部分と前記データの残り部分のキャッシュデータを取得し、
前記キャッシュデータを前記端末上に表示する、
ことをさらに特徴とする、請求項１に記載の端末。

【請求項4】

前記応答が成功であることに対応して、サーバからの前回応答時間を格納し、
前記前回応答時間に基づいてリフレッシュ時間を決定し、
前記リフレッシュ時間の後に前記データの一部分をリフレッシュする、
ことをさらに特徴とする、請求項１に記載の端末。

【請求項5】

前記リフレッシュ時間が固定値である、または前回応答時間の増加とともに増加する、ことを特徴とする、請求項４に記載の端末。

【請求項6】

前記応答が成功であることに対応して、前記データの一部分をリフレッシュするか否かを決定し、
前記データの一部分をリフレッシュしないことに対応して、前記データの一部分を表示し、
前記応答にカーソルがあることに対応して、データの次の部分に関する要求を送信する、
ことをさらに特徴とする、請求項１に記載の端末。

【請求項7】

前記応答が成功であることに対応して、前記データの一部分をリフレッシュするか否かを決定し、
前記データの一部分のリフレッシュに対応して、前記データの全部分が取得されたか否かを判定し、
前記データの全部分が取得されていないことに対応して、前記データの一部分を表示し、
前記応答にカーソルがあることに対応して、データの次の部分に関する要求を送信する、
ことをさらに特徴とする、請求項１に記載の端末。

【請求項8】

前記応答が成功であることに対応して、前記データの一部分をリフレッシュするか否かを決定し、
前記データの一部分のリフレッシュに対応して、前記データの全部分が取得されたか否かを判定し、
前記データの全部分が取得されており、かつ前記応答にカーソルがないことに対応して、前記データの全部分を表示する、
ことをさらに特徴とする、請求項１に記載の端末。

【請求項9】

ライブストリーミングプラットフォームにおいてデータを処理するための方法であって、
データの一部分に関する要求を送信する工程と、
前記要求の応答を受信する工程と、
前記応答が失敗であって前記データの一部分が第１の部分でないことに対応して再試行回数を設定する工程と、
設定された前記再試行回数に基づいて再試行時間を決定する工程と、
前記再試行時間の後に前記データの一部分に関する次の要求を送信する工程と、を含むことを特徴とする、方法。

【請求項10】

コンピュータプログラムであって、端末に、
データの一部分に関する要求を送信する機能と、
前記要求の応答を受信する機能と、
前記応答が失敗であって前記データの一部分が第１の部分でないことに対応して再試行回数を設定する機能と、
設定された前記再試行回数に基づいて再試行時間を決定する機能と、
前記再試行時間の後に前記データの一部分に関する次の要求を送信する機能と、
を実現させる、ことを特徴とする、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報通信技術に関し、特に、ライブストリーミングにおける端末、方法、及びコンピュータプログラムに関する。

【背景技術】

【0002】

アプリやプラットフォームの中には、ライブストリーマーと視聴者が交流できるライブストリーミングサービスを提供しているものがある。ライブストリーマーが視聴者を応援するパフォーマンスをしたり、視聴者がライブストリーマーを支援するために贈り物を寄付または送ったりすることもある。また、より多くのライブストリーマーや視聴者をライブストリーミングに参加させるために、様々なキャンペーンやイベントを開催している。

【0003】

ライブストリーマーと視聴者間の交流はリアルタイムであるため、リーダーボードなどのデータの計算と更新は高速かつ正確であることが要求される。特許文献１には、リーダーボードのキャッシュを表示し、サーバ負荷を軽減して、情報の適時性を向上させる方法が開示されている。

【0004】

しかしながら、ユーザ端末のネットワーク状況によって、データの表示にばらつきがある。また、データを要求している間に空白画面が表示されると、ユーザの不満を招き、ユーザエクスペリエンスが低下する可能性がある。したがって、ネットワークやキャッシュからのデータをどのように処理するかは非常に重要な課題である。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】中国特許第１０７２４９１４０号明細書

【発明の概要】

【0006】

本開示の一実施形態によるライブストリーミングプラットフォームにおいてデータを処理するための端末は、１以上のプロセッサを備え、そのうち、当該１以上のプロセッサが機械可読命令を実行して、データの一部分に関する要求を送信する機能と、当該要求の応答を受信する機能と、当該応答が失敗であって当該データの一部分が第１の部分でないことに対応して再試行回数を設定する機能と、設定された当該再試行回数に基づいて再試行時間を決定する機能と、当該再試行時間の後に当該データの一部分に関する次の要求を送信する機能と、を実行する。

【0007】

本開示の別の一実施形態によるライブストリーミングプラットフォームにおいてデータを処理するための方法は、データの一部分に関する要求を送信する工程と、当該要求の応答を受信する工程と、当該応答が失敗であって当該データの一部分が第１の部分でないことに対応して再試行回数を設定する工程と、設定された当該再試行回数に基づいて再試行時間を決定する工程と、当該再試行時間の後に当該データの一部分に関する次の要求を送信する工程と、を含む。

【0008】

本開示の別の一実施形態によるコンピュータプログラムは、端末に、データの一部分に関する要求を送信する機能と、当該要求の応答を受信する機能と、当該応答が失敗であって当該データの一部分が第１の部分でないことに対応して再試行回数を設定する機能と、設定された当該再試行回数に基づいて再試行時間を決定する機能と、当該再試行時間の後に当該データの一部分に関する次の要求を送信する機能と、を実現させる。

【0009】

本開示によれば、空白画面を表示するのではなく、リーダーボードデータなどの要求されたデータをネットワークの状態に関わらずユーザ端末に円滑に表示することができる。したがって、ユーザエクスペリエンスが向上される可能性がある。

【図面の簡単な説明】

【0010】

【図1】本開示の一部の実施態様に基づくライブストリーミングシステム１の構成を示す概略図である。

【図2】本開示の一部の実施態様に基づくユーザ端末２０のブロック図である。

【図3】本開示の一部の実施態様に基づくサーバ１０のブロック図である。

【図4】図３のストリームＤＢ３２０の例示的データ構造を示す表である。

【図5】図３のユーザＤＢ３２２の例示的データ構造を示す表である。

【図6】図３のデータＤＢ３２４の例示的データ構造を示す表である。

【図7】図２のキャッシュＤＢ２５０の例示的データ構造を示す表である。

【図8】図２のデータキューＤＢ２５２の例示的データ構造を示す表である。

【図9】ライブストリーマーのユーザ端末２０または視聴者のユーザ端末３０のディスプレイ上に表示されるライブストリーミングルーム画面６６０の例示的な画面イメージである。

【図10】ライブストリーマーのユーザ端末２０または視聴者のユーザ端末３０のディスプレイ上に表示されるライブストリーミングルーム画面６６０の例示的な画面イメージである。

【図11】ライブストリーマーのユーザ端末２０または視聴者のユーザ端末３０のディスプレイ上に表示されるライブストリーミングルーム画面６６０の例示的な画面イメージである。

【図12】当該ユーザ端末２０、３０におけるアプリケーション起動処理の工程を示すフローチャートである。

【図13】当該ユーザ端末２０、３０におけるアプリケーション起動処理の工程を示すフローチャートである。

【図14】当該ユーザ端末２０、３０におけるアプリケーション起動処理の工程を示すフローチャートである。

【図15】当該ユーザ端末２０、３０におけるアプリケーション起動処理の工程を示すフローチャートである。

【図16】再試行時間の決定工程を示すフローチャートである。

【図17】図２の再試行時間ルックアップテーブル２５４の例示的データ構造を示す表である。

【図18】リフレッシュ時間の決定工程を示すフローチャートである。

【図19】図２のリフレッシュ時間ルックアップテーブル２５６の例示的データ構造を示す表である。

【図20】本開示の一部の実施態様に基づく情報処理装置の例示的なハードウェア構成である。

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

【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】

一部の実施態様において、Ｓ５２４においてすべてのキャッシュデータが当該ユーザ端末に表示された後、当該キューユニット２１０はさらに、当該データをリフレッシュするか否かを決定してもよい（Ｓ５５２）。当該データをリフレッシュする必要がない場合（Ｓ５５２で「いいえ」）、フローは終了されてもよい。当該データのリフレッシュが必要な場合（Ｓ５３２で「はい」）、当該キューユニット２１０は、データリフレッシュの準備のために、例えば、ネットワークデータとキャッシュデータを空に設定し、「１回目の読込み」のパラメータを「はい」（True）に再設定することなどにより、一時的に格納されている当該ネットワークデータ及び当該キャッシュデータを消去してもよい（Ｓ５５４）。一部の実施態様において、当該リフレッシュ時間は、固定された、または固定されていない時間間隔であってもよい。一部の実施態様において、当該フローは図１２または図１４の最初に戻ってもよく、当該サーバ１０からデータをリフレッシュするために要求リストが収集されてもよい（Ｓ５０２）。一部の実施態様において、また当該キューユニット２１０は、図１５に示すように、当該データのリフレッシュを開始する前に、リフレッシュ時間待機してもよい（Ｓ５５１）。

【0090】

一部の実施態様において、複数のリーダーボードデータが同時に当該ユーザ端末から要求されてもよい。フローが工程Ｓ５０２に戻ると、要求リストが収集される２つのシナリオがある。１つ目は、それが１回目のデータ要求であり、これには「１回目の読込み」のパラメータがリセットされた後の要求も含まれる。２つ目は、データ要求が完全に完了されておらず、返されたカーソルがある。それ以外の場合は、要求リストの収集は必要なく、ｎｕｌｌを返し、最終的にフィルタリングされる。

【0091】

上述の実施態様によれば、当該再試行時間とリフレッシュ時間の決定は、サーバ側ではなく端末側であってもよい。当該端末は、当該サーバ１０からの応答と応答時間に応じて、当該再試行時間とリフレッシュ時間を決定してもよい。つまり、決定はすべてサーバ側ではなく、端末側となる。従って、データを要求及び表示するタイミングを最適化し、当該サーバの負荷を軽減することができる。

【0092】

本実施態様によれば、サーバ１０にデータを要求するタイミングを最適化することができる。例えば、バックエンドの問題に遭遇し、データを取得できない場合、再試行時間を設定し、当該端末は当該再試行時間待機してから、次回のデータ取得を試みてもよい。さらに、バックエンドの問題に遭遇したときは、常に正常なデータ取得に問題があることを示す。当該バックエンドへの問い合わせを繰り返すと、当該バックエンドの負担がさらに蓄積される可能性がある。したがって、再試行回数に応じて再試行時間を設定することで、当該バックエンドの負担を軽減させることができる。

【0093】

本実施態様によれば、サーバ１０からのデータをリフレッシュするタイミングを最適化することもできる。例えば、当該バックエンドからの当該前回応答時間に基づいてリフレッシュ時間が設定されてもよく、そして当該端末は当該リフレッシュ時間待機してから次回のデータリフレッシュを試みてもよい。さらに、当該前回応答時間を考慮せずに当該バックエンドからのデータリフレッシュを繰り返すと、当該バックエンドの負担がさらに蓄積される可能性がある。したがって、当該前回応答時間に基づいてリフレッシュ時間を設定することでも、当該バックエンドの負担を軽減することができる。

【0094】

本開示によれば、空白画面を表示するのではなく、リーダーボードデータなどの要求されたデータをネットワークの状態に関わらずユーザ端末に円滑に表示することができる。したがって、ユーザエクスペリエンスが向上される可能性がある。

【0095】

図２０は、本開示の一部の実施態様に基づくシステム構成および処理を実行するためのコンピュータハードウェアの概略ブロック図である。図２０の情報処理装置９００は、例えば、本開示の一部の実施態様に基づく当該サーバ１０と当該ユーザ端末２０、３０をそれぞれ実現するように構成される。

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

当該通信ユニット９２９は、例えば、通信ネットワークＮＷに接続するための通信装置を含む通信インターフェイスである。当該通信ユニット９２９は、例えば、有線または無線のローカルエリアネットワーク（ＬＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、または、無線ＵＳＢ（ＷＵＳＢ）用の通信カードであってもよい。

【0104】

当該通信ユニット９２９は、例えば、光通信用のルータ、ＡＤＳＬ（非対称デジタル加入者線）用のルータ、または、各種通信用のモデムであってもよい。例えば、当該通信ユニット９２９は、ＴＣＰ／ＩＰ等の所定のプロトコルを用いて、インターネットにおける信号の送受信や、他の通信装置との信号の送受信を行う。当該通信ユニット９２９が接続する当該通信ネットワークＮＷは、有線接続または無線接続により確立されたネットワークである。当該通信ネットワークＮＷは、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、電波通信、または衛星通信である。

【0105】

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

【0106】

以上、本開示のライブストリーミングシステム１について、実施形態を参照しながら説明した。上述の実施態様は、単に説明のために記載されたものである。むしろ、実施態様の上述した構成要素や処理を多様に組み合わせ、さまざまな変更がなされ得ることは、当業者であれば容易に想到し得ることであり、これらも本開示の技術的範囲に包含される。

【0107】

本明細書に記載された工程、特にフローチャートやフローチャートを用いて説明された工程は、工程を構成する工程の一部の省略、工程を構成する工程に明示的に含まれない工程の追加、及び（または）工程順序の並べ替えが可能である。このような省略、追加、並べ替えの対象となった工程も、本開示の要旨を逸脱しない限り、本開示の範囲に含まれる。

【0108】

一部の実施態様において、当該サーバ１０が実行する機能の少なくとも一部は、当該サーバ１０以外が実行してもよく、例えば、当該ユーザ端末２０または３０が実行するようにしてもよい。一部の実施態様において、当該ユーザ端末２０または３０が実行する機能の少なくとも一部を、当該ユーザ端末２０または３０以外が実行してもよく、例えば、当該サーバ１０が実行するようにしてもよい。一部の実施態様において、フレーム画像のレンダリングは、視聴者、サーバ、ライブストリーマー等の当該ユーザ端末が実行するようにしてもよい。

【0109】

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

【0110】

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

【符号の説明】

【0111】

１ ライブストリーミングシステム
１０ サーバ
２０ ユーザ端末
１００ ストリーミングユニット
１０２ ビデオコントロールユニット
１０４ オーディオコントロールユニット
１０６ 配信ユニット
１０８ ＵＩコントロールユニット
２００ 視聴ユニット
２０２ ＵＩコントロールユニット
２０４ レンダリングユニット
２０６ 入力送信ユニット
２０８ キャッシュユニット
２１０ キューユニット
２５０ キャッシュＤＢ
２５２ データキューＤＢ
２５４ 再試行時間ルックアップテーブル
２５６ リフレッシュ時間ルックアップテーブル
３０、３０ａ、３０ｂ ユーザ端末
３０２ ストリーミング情報ユニット
３０４ 中継ユニット
３０６ 処理ユニット
３２０ ストリームＤＢ
３２２ ユーザＤＢ
３２４ データＤＢ
３３４ イベントページ
３３６ タイトル
３３８ バナー
３４０ 説明
３４２ ランキング
３４４ タブ
３４６ リーダーボードページ
９００ 情報処理装置
９０１ ＣＰＵ
９０３ ＲＯＭ
９０５ ＲＡＭ
９０７ ホストバス
９０９ ブリッジ
９１１ 外部バス
９１３ インターフェイス
９１５ 入力ユニット
９１７ 出力ユニット
９１９ ストレージユニット
９２１ ドライブ
９２３ リムーバブル記録媒体
９２５ 接続ポート
９２７ 外部接続端末
９２９ 通信ユニット
ＬＳ ライブストリーミング
ＬＶ ライブストリーマー
ＮＷ ネットワーク
ＳＰ 特定の部分
ＡＵ１、ＡＵ２ 視聴者
Ｓ５０２、Ｓ５０４、Ｓ５０６、Ｓ５０８、Ｓ５１０、… 工程
Ｓ６０２、Ｓ６０４、Ｓ６０６、Ｓ６１２、Ｓ６１４、… 工程
ＶＤ、ＶＤ１、ＶＤ２ 映像

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】