特許 7526411 端末、方法及びコンピュータプログラム

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

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-07-24

(45)【発行日】2024-08-01

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

(51)【国際特許分類】

   H04N 21/435 20110101AFI20240725BHJP

   H04N 21/4722 20110101ALI20240725BHJP

【ＦＩ】

H04N21/435

H04N21/4722

【請求項の数】 10

【外国語出願】

(21)【出願番号】P 2023202236

(22)【出願日】2023-11-29

【審査請求日】2024-02-08

【早期審査対象出願】

(73)【特許権者】

【識別番号】517287224

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

(74)【代理人】

【識別番号】100199277

【弁理士】

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

(72)【発明者】

【氏名】洪偉翔

(72)【発明者】

【氏名】郭柏逸

(72)【発明者】

【氏名】胡哲維

(72)【発明者】

【氏名】石宗台

【審査官】大西 宏

(56)【参考文献】

【文献】特開２００７－３３６５６７（ＪＰ，Ａ）

【文献】米国特許出願公開第２００９／０１１９７３４（ＵＳ，Ａ１）

【文献】韓国公開特許第１０－２０２１－００２８８０５（ＫＲ，Ａ）

【文献】中国特許出願公開第１０１５６７８７５（ＣＮ，Ａ）

【文献】中国特許出願公開第１１２８２２２７０（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００ －２１／８５８

(57)【特許請求の範囲】

【請求項1】

端末であって、１以上のプロセッサを含み、前記１以上のプロセッサが機械可読命令を実行して、
ライブストリーミングプラットフォーム内のイベントに関連するデータを要求する機能と、
前記イベントの発生タイミングに基づいてキャッシュ戦略を決定する機能と、
を実行することを特徴とする、端末。

【請求項2】

前記イベントが進行中ではないことに対する応答において、前記データに対応するキャッシュがあるか否かを判断する機能と、
前記データに対応する利用可能なキャッシュがあることに応答し、キャッシュのみの前記キャッシュ戦略を適用する機能と、
をさらに含むことを特徴とする、請求項１に記載の端末。

【請求項3】

前記イベントが進行中ではないことに対する応答において、前記データに対応するキャッシュがあるか否かを判断する機能と、
前記データに対応する利用可能なキャッシュがないことに応答し、キャッシュの後ネットワークの前記キャッシュ戦略を適用する機能と、
をさらに含むことを特徴とする、請求項１に記載の端末。

【請求項4】

前記決定する機能は、前記イベントの開始時刻前であるか、終了時刻後であるか、または前記イベントが進行中であるかに基づいて前記キャッシュ戦略を決定する機能を含む、
ことを特徴とする、請求項１に記載の端末。

【請求項5】

前記イベントが進行中であることに対する応答において、前記データの要求が１回目の読込みであるか否かを判断する機能と、
前記要求されたデータが１回目の読込みであることに対する応答において、ネットワーク接続の品質を判断する機能と、
前記ネットワーク接続の品質が良好であることに対する応答において、ネットワーク優先の前記キャッシュ戦略を適用する機能と、
をさらに含む、ことを特徴とする、請求項１に記載の端末。

【請求項6】

前記イベントが進行中であることに対する応答において、前記データの要求が１回目の読込みであるか否かを判断する機能と、
前記要求されたデータが１回目の読込みであることに対する応答において、ネットワーク接続の品質を判断する機能と、
前記ネットワーク接続の品質が不良であることに対する応答において、キャッシュの後ネットワークの前記キャッシュ戦略を適用する機能と、
をさらに含む、ことを特徴とする、請求項１に記載の端末。

【請求項7】

前記イベントが進行中であることに対する応答において、それが前記データの１回目の読込みであるか否かを判断する機能と、
前記要求されたデータが１回目の読込みではないことに対する応答において、前記端末のユーザからトリガーされた更新があるか否かを判断する機能と、
前記端末の前記ユーザからトリガーされた前記更新に対する応答において、ネットワーク優先の前記キャッシュ戦略を適用する機能と、
をさらに含むことを特徴とする、請求項１に記載の端末。

【請求項8】

前記イベントが進行中であり、かつ前記要求されたデータが１回目の読込みではないことに対する応答において、自動更新メカニズムが適用されているか否かを判断する機能と、
自動更新メカニズムが適用されていることに対する応答において、ネットワーク優先の前記キャッシュ戦略を適用する機能と、
をさらに含むことを特徴とする、請求項１に記載の端末。

【請求項9】

方法であって、
ライブストリーミングプラットフォーム内のイベントに関連するデータを要求する工程と、
前記イベントの発生タイミングに基づいてキャッシュ戦略を決定する工程と、
を含むことを特徴とする、方法。

【請求項10】

コンピュータプログラムであって、端末に、
ライブストリーミングプラットフォーム内のイベントに関連するデータを要求する機能と、
前記イベントの発生タイミングに基づいてキャッシュ戦略を決定する機能と、
を実現させることを特徴とする、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【先行技術文献】

【特許文献】

【0005】

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

【発明の概要】

【0006】

本開示の一実施態様によるライブストリーミングプラットフォームにおいてデータを処理するための端末は、１以上のプロセッサを備え、当該１以上のプロセッサが機械可読命令を実行して、 当該ライブストリーミングプラットフォームにデータを要求する工程と、当該データのタイミングに基づきキャッシュ戦略を決定する工程と、を実行する。

【0007】

本開示の別の一実施態様によるライブストリーミングプラットフォームにおいてデータを処理するための方法は、当該ライブストリーミングプラットフォームにデータを要求する工程と、当該データのタイミングに基づきキャッシュ戦略を決定する工程と、を含む。

【0008】

本開示の別の一実施態様によるライブストリーミングプラットフォームにおいてデータを処理するためのコンピュータプログラムは、端末に、当該ライブストリーミングプラットフォームにデータを要求する機能と、当該データのタイミングに基づきキャッシュ戦略を決定する機能と、を実行させる。

【0009】

上述の実施態様によれば、当該キャッシュ戦略が、イベント前、イベント中、イベント後に動的に決定されてもよい。サーバ負荷が低減され、ユーザ端末の応答性が向上される可能性がある。また、キャッシュ戦略の自動切替えにより、ユーザの誤解を最小限に抑えられる可能性がある。したがって、ユーザエクスペリエンスが向上される可能性がある。

【図面の簡単な説明】

【0010】

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

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

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

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

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

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

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

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

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

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

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

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

【図13】キャッシュ方法の決定工程を示すフローチャートである。

【図14】図２のキャッシュ方法ルックアップテーブル２５４の例示的データ構造を示す表である。

【図15】ライブストリーミングプラットフォームにおけるイベントの例示的な機能的構造である。

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

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

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

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

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【符号の説明】

【0107】

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

【要約】      （修正有）

【課題】ネットワークやキャッシュからのデータ処理に対するキャッシュ戦略を動的に決定することにより、サーバ負荷を低減してユーザ端末の応答性を向上し、また、ユーザの誤解を最小限に抑え、ユーザエクスペリエンスを向上する端末、方法及びコンピュータプログラムを提供する。
【解決手段】ライブストリーミングプラットフォームにおいてデータを処理するための端末は、１以上のプロセッサを備え、当該１以上のプロセッサが機械可読命令を実行して、当該ライブストリーミングプラットフォームにデータを要求する工程と、当該データのタイミングに基づきキャッシュ戦略を決定する工程と、を実行する。当該キャッシュ戦略は、イベント前、イベント中、イベント後に動的に決定してよい。
【選択図】図１６

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】