JP7220880B1 - データアクセスのためのシステム、方法、及びコンピュータ可読媒体 - Google Patents

Abstract

【課題】より効率的なリソース分配してを実現し、サーバダウンを防止することができるデータアクセスのためのシステム、方法及びコンピュータ可読媒体を提供する。【解決手段】データアクセスのための方法は、要求を受信する工程と、当該要求に対応するエンドポイントのステータスパラメータを受信する工程と、期間内に当該要求を受信した回数を受信する工程と、当該エンドポイントの当該ステータスパラメータまたは当該期間内に当該要求を受信した回数に基づき、当該要求を送信するための遅延時間長さを決定する工程と、を含む。【選択図】図４

Description

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

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

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

当該サーバにアクセスする当該ユーザの増加に伴い、当該サーバを安定した状態に保ち、データアクセス中のユーザ体験を維持することが重要となる。

本発明の一実施態様による方法は、１以上のコンピュータによって実行されるデータアクセスのための方法であって、要求を受信する工程と、当該要求に対応するエンドポイントのステータスパラメータを受信する工程と、期間内に当該要求を受信した回数を受信する工程と、当該エンドポイントの当該ステータスパラメータまたは当該期間内に当該要求を受信した回数に基づき、当該要求を送信するための遅延時間長さを決定する工程と、を含む。

本発明の一実施態様によるシステムは、１以上のコンピュータプロセッサを含むデータアクセスのためのシステムであり、当該１以上のコンピュータプロセッサが、機械可読命令を実行して、要求を受信する工程と、当該要求に対応するエンドポイントのステータスパラメータを受信する工程と、期間内に当該要求を受信した回数を受信する工程と、当該エンドポイントの当該ステータスパラメータまたは当該期間内に当該要求を受信した回数に基づき、当該要求を送信するための遅延時間長さを決定する工程と、を実行する。

本発明の一実施態様によるコンピュータ可読媒体は、データアクセスのためのプログラムを含む非一時的なコンピュータ可読媒体であって、当該プログラムが１以上のコンピュータに、要求を受信する工程と、当該要求に対応するエンドポイントのステータスパラメータを受信する工程と、期間内に当該要求を受信した回数を受信する工程と、当該エンドポイントの当該ステータスパラメータまたは当該期間内に当該要求を受信した回数に基づき、当該要求を送信するための遅延時間長さを決定する工程と、を実行させる。

従来のデータアクセス方法を示す例示的なフローチャートである。本発明の一部の実施態様に基づく通信システムの概略図である。本発明の一部の実施態様に基づくユーザ端末の例示的なブロック図である。本発明の一部の実施態様に基づく例示的なフローチャートである。本発明の一部の実施態様に基づく例示的な時系列図である。本発明の一部の実施態様に基づく例示的なフローチャートである。本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフである。本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフである。本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフである。本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフである。要求テーブル１１８の一例である。エンドポイントステータステーブル１１２の一例である。ユーザステータステーブル１１４の一例である。ユーザデータベース３１０の一例である。本発明の一部の実施態様に基づく例示的なフローチャートである。

従来のユーザ端末とサーバ間のデータアクセス方法は、いくつかの解決すべき課題を抱えている。

従来、ユーザ端末がユーザからデータの要求を受け取ると、当該ユーザ端末は直ちにサーバに当該要求を送信してデータを要求する。当該ユーザが短期間内に何度も同じ要求を開始すると、当該ユーザ端末は何度も同じ要求を当該サーバに送信することになり、当該サーバの負担／負荷が増加する。その結果、当該サーバの停止やデータアクセスの重大な遅延につながることがある。例えば、当該ユーザ端末のインターネット接続状態が良くない場合、当該ユーザは当該ユーザ端末での操作に対して応答の遅さを感じることがある。そのため、当該ユーザは更新を待つ間、ユーザインターフェース上の更新ボタンを何度もクリックすることがある。しかし、このような要求が繰り返されると、却ってアクセスプロセスの妨げになり、ユーザ体験の低下を招くことがある。場合によっては、ユーザからの度重なる要求は、当該サーバが他のユーザにデータアクセスを提供する能力または容量を低下させることさえある。

従来、当該ユーザ端末は、データアクセスが導かれる先の情報を認識する手段を持たない。例えば、当該ユーザ端末は、当該要求に対応するエンドポイントの情報を知る手段を持たない。当該情報には、当該エンドポイントの負担（または負荷）、健全性、優先度、または重大度に関するステータスが含まれてもよい。このため、異なるエンドポイントに対応する異なる要求に対して、カスタマイズした方法で、または効率的な方法で、データアクセスを処理することができない。

本発明は、当該ユーザ端末から当該サーバに要求を送信するタイミングを決定する方法及びシステムを開示する。当該送信タイミングは、当該ユーザ端末における当該要求の受信頻度によって決定されてもよい。当該送信タイミングは、当該要求に対応する当該エンドポイントのステータスによって決定されてもよい。当該送信タイミングは、当該要求を開始した当該ユーザの貢献度スコア（または貢献レベル）により決定されてもよい。したがって、当該要求を当該サーバに送信するための最適なタイミングを実現することができる。本発明の技術的な効果としては、サーバダウンの防止、データアクセスのカスタマイズした効率的な処理（効率的なリソース配分）などが挙げられる。

図１に、従来のデータアクセス方法を示す例示的なフローチャートを示す。

工程Ｓ１００において、当該ユーザ端末は、機能またはユーザインターフェース（ＵＩ）において、ユーザからの要求を受信する。例えば、当該ユーザは、当該ユーザ端末にインストールされたアプリケーションのＵＩ上のボタンをクリックまたはタップすることにより、当該要求を開始してもよい。

工程Ｓ１０２において、当該ユーザ端末は、当該要求に対応するデータが存在するサーバに当該要求を送信する。

工程Ｓ１０４において、当該サーバは、応答を当該ユーザ端末に送信する。当該応答には、当該ユーザ（または当該ユーザ端末上の当該アプリケーション）が要求したデータが含まれる。

工程Ｓ１０６において、当該アプリケーション（または当該アプリケーションの機能）は、応答データにエラーが含まれているか否か、またはサーバの停止を示しているか否かをチェックする。「いいえ」の場合、フローは工程Ｓ１０８に進む。「はい」の場合、フローは工程Ｓ１１０に進む。

工程Ｓ１０８において、当該ユーザ端末は、応答データに基づいて、要求の結果を（アプリケーションの）ＵＩに表示する。データアクセスが正常に行われる。

工程Ｓ１１０において、当該ユーザ端末は、応答データに基づき、エラー、サーバビジー、またはサーバダウンを示すメッセージを表示する。

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

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

図３に、本発明の一部の実施態様に基づくユーザ端末の例示的なブロック図を示す。

当該ユーザ端末１００は、ユーザインターフェース１０２と、エンドポイントステータスモニター１０４と、ユーザステータスモニター１０６と、信タイミングコントローラ１０８と、送信ユニット１１０と、エンドポイントステータステーブル１１２と、ユーザステータステーブル１１４と、遅延ポリシーテーブル１１６と、要求テーブル１１８を含む。

当該ユーザインターフェース１０２は、当該ユーザ端末１００のユーザと当該ユーザ端末１００間の相互作用を実現するように構成される。当該ユーザインターフェース１０２は、当該ユーザからの視覚、音声、タッチ入力を受け取るための視覚、音声、タッチセンサを含むことができる。当該ユーザインターフェース１０２は、当該ユーザからの指示を受け付けるためのページやアプリケーションの機能と相関していてもよい。当該ユーザ端末１００は、当該ユーザインターフェース１０２を介して当該ユーザから要求を受信することができる。受信した当該要求は、当該要求テーブル１１８に格納されてもよい。当該ユーザから繰り返し要求が送信される場合、その要求の受信回数（例えば、一定期間内）も、当該要求テーブル１１８に記録される。

当該エンドポイントステータスモニター１０４は、エンドポイントのステータスを監視するように構成される。当該エンドポイントは、当該ユーザからの当該要求に対応する、あるいは、当該要求の宛先が当該エンドポイントである。当該エンドポイントは、当該ユーザ端末１００の外部にあるサーバに存在する。当該エンドポイントステータスモニター１０４は、エンドポイントデータベース３００に（例えばインターネット経由で）アクセスし、当該エンドポイントのステータスパラメータを取得することができる。その後、当該エンドポイントの当該ステータスパラメータは、当該エンドポイントステータステーブル１１２に格納される。当該エンドポイントデータベース３００は、当該要求に対応する当該エンドポイントが属する当該サーバ上に存在してもよい。一部の実施態様において、当該エンドポイントデータベース３００は、別のサーバ上に存在してもよい。

当該ユーザステータスモニター１０６は、当該ユーザのステータスを監視するように構成される。当該ユーザステータスモニター１０６は、ユーザデータベース３１０に（例えばインターネット経由で）アクセスし、当該ユーザのステータスパラメータを取得することができる。当該ユーザデータベース３１０は、当該要求に対応する当該エンドポイントが属する当該サーバ上に存在してもよい。一部の実施態様において、当該ユーザデータベース３１０は、別のサーバ上に存在してもよい。当該ステータスパラメータは、当該ユーザに対応する貢献度スコアであってもよく、またはそれを含んでいてもよい。当該ステータスパラメータは、当該ユーザに対応するレベルであってもよい。その後、当該ユーザの当該ステータスパラメータは、当該ユーザステータステーブル１１４に格納される。一部の実施態様において、当該貢献度スコア及び（または）当該レベルは、ライブストリーミングプラットフォーム上での当該ユーザのコメント行動、贈り物送信行動、視聴行動、決済・入金行動に基づいて、増加してもよい。

当該送信タイミングコントローラ１０８は、当該要求に対応する当該エンドポイントが存在する当該サーバに当該要求を送信するタイミング（または当該要求を送信するための遅延時間長さ）を決定するように構成される。当該送信タイミングコントローラ１０８は、当該要求テーブル１１８にアクセスして、一定期間内の当該要求の受信回数を受信してもよい。当該送信タイミングコントローラ１０８は、当該エンドポイントステータステーブル１１２にアクセスし、当該要求に対応する当該エンドポイントの当該ステータスパラメータを受信してもよい。当該送信タイミングコントローラ１０８は、当該ユーザステータステーブル１１４ニアクセスし、当該ユーザの当該ステータスパラメータ（貢献度スコアなど）を受信してもよい。当該送信タイミングコントローラ１０８は、その後当該遅延ポリシーテーブル１１６を参照し、当該要求を送信するための当該遅延時間長さを決定する。

当該遅延ポリシーテーブル１１６は、当該要求を送信するための当該遅延時間長さを決定するためのポリシーまたは基準を格納するように構成される。

一部の実施態様において、当該遅延時間長さは、当該期間内に当該要求を受信した回数が多いほど長く決定される。例えば、当該遅延時間長さは、当該期間内の当該要求の受信回数に指数関数的に比例してもよい。ユーザが同じ要求を何度も繰り返し送信する場合、指数関数的な遅延メカニズムは、当該ユーザがサーバリソース（当該サーバの容量、帯域幅、ＣＰＵ使用率及び（または）メモリ使用率など）を浪費／消費／占有しすぎることを防止することができる。一部の実施態様において、遅延ルールは、何度も要求を送信し続ける傾向があるそれらのユーザに対する罰のメカニズムとして機能する。これにより、サーバリソースの効率的な分配して／利用を実現し、当該サーバの過負荷や停止を防止することができる。

一部の実施態様において、当該遅延時間長さは、当該要求に対応する当該エンドポイントの当該ステータスパラメータが、当該エンドポイントの比較的重大な状態を示すとき、より長く決定される。

一部の実施態様において、比較的重大な状態は、当該エンドポイントがより重要であることを示す。例えば、支払いや贈り物の送信などの機能に関するエンドポイントは、コメントなど他の機能に関する当該エンドポイントよりも重大であると判断され、そのステータスパラメータはより高い値を持つ可能性がある。したがって、当該遅延時間長さがより長いと、アクセス成功の信頼性がより高くなることがある。

一部の実施態様において、比較的重大な状態は、当該エンドポイントがより不健全な状態であることを示す。不健全なエンドポイントとは、当該エンドポイントがビジーである、過負荷である、または任意の異常な状態にあることを意味する。例えば、当該エンドポイントを適切に動作させるための当該サーバのリソースが、特定のタイミングで準備ができていなかったり、十分でなかったりすることである。遅延メカニズムは、当該エンドポイント（または当該サーバ）が不健全な状態から回復するために十分な時間を与えることができ、より信頼性の高いデータアクセスを確約することができる。遅延メカニズムは、異なるユーザ端末からの多くの要求が同時に当該エンドポイント（または当該サーバ）に到達する状況を防止することができる。

当該エンドポイントの当該ステータスパラメータは、当該エンドポイントのステータスの予測を含んでもよい。例えば、当該ステータスパラメータは、未来のある時点において、当該エンドポイントがビジー状態、過負荷状態、または何らかの異常状態になるか否かを示すものであってもよい。したがって、当該エンドポイントの予測されたステータスに応じて当該遅延時間長さを決定し、データアクセスを最適化することができる。当該エンドポイントのステータスの予測は、当該エンドポイントデータベース３００に実装され得る機械学習モデルによって実行されてもよい。

一部の実施態様において、当該遅延時間長さは、（要求を開始した当該ユーザの）当該貢献スコアがより高い場合に、より短くなるように決定される。一部の実施態様において、当該遅延時間長さは、（要求を開始した当該ユーザの）当該貢献度スコアがより低いときに、より長くなるように決定される。貢献度スコアが高いほど、対応する当該ユーザがライブストリーミングプラットフォーム上でより多くのコメント行動、贈り物送信行動、視聴行動、決済・入金行動を有することを示すことができる。つまり、貢献度スコアが高い当該ユーザは、当該プラットフォームへの貢献度が「高い」ことになる。したがって、貢献度の高い当該ユーザほど、より良いデータアクセス体験ができることが期待される。当該貢献度スコアに従って当該遅延時間長さを決定することは、利用可能なリソースが制限されている場合に、異なるユーザに対してデータアクセスを最適化することができる。一部の実施態様において、当該インターネット及び（または）サーバ（エンドポイント）が劣悪な状態にある場合、逆の戦略が適用されてもよい。例えば、サーバ／エンドポイントの状態が悪いことが検出された場合、より貢献度の高いユーザからの要求に対する当該遅延時間長さが、当該ユーザのデータアクセス成功を保証するために十分長くなるように決定されてもよい。

当該要求テーブル１１８は、当該サーバへの送信が予定されている要求を格納するように構成される。当該要求テーブル１１８は、要求キューを参照または含んでもよい。当該要求テーブル１１８は、受信した要求と、当該要求に関連する情報とを格納するように構成される。一部の実施態様において、要求の受信回数が、当該要求とともに格納される。一部の実施態様において、当該遅延時間長さ（または送信タイミング）が、当該要求とともに格納される。

当該送信ユニット１１０は、例えば、インターネットを介して、当該サーバに当該要求を送信するように構成される。当該送信ユニット１１０は、決定された送信タイミング（または、決定された遅延時間長さ）について、当該要求テーブル１１８にアクセスしてもよい。

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

工程Ｓ３００において、当該ユーザ端末（例えば、ユーザ端末１００）は、ユーザから要求を受信する。当該要求は、当該ユーザ端末にインストールされたアプリケーションの機能またはＵＩ（ユーザインターフェース）を介して受信されてもよい。例えば、当該ユーザは、ＵＩ上のボタン（更新ボタンなど）またはアプリケーションの機能をクリックまたはタップすることにより、当該要求を開始することができる。当該機能は、リーダーボード機能であってもよく、当該ユーザは、最新のリーダーボードデータを取得する要求を開始することができる。

工程Ｓ３０２は、工程Ｓ３０２０と、工程Ｓ３０２２と、工程Ｓ３０２４を含む。

工程Ｓ３０２０において、例えば、当該ユーザの当該貢献度スコアが、当該ユーザステータスモニター１０６により受信される。

工程Ｓ３０２２において、例えば、当該ユーザインターフェース１０２により、当該要求の受信回数が検出される。

工程Ｓ３０２４において、例えば、当該エンドポイントステータスモニター１０４により、当該要求に対応する当該エンドポイントの当該ステータスパラメータが受信される。当該ステータスパラメータは、当該エンドポイントのステータスまたはステータス予測を示してもよい。

工程Ｓ３０４において、例えば、当該送信タイミングコントローラ１０８により、当該要求送信のための当該遅延時間長さが決定される。当該遅延時間長さは、当該要求の（一定期間内の）受信回数、当該エンドポイントの当該ステータスパラメータ、及び（または）当該ユーザの当該貢献度スコアに基づいて決定されてもよい。

工程Ｓ３０６において、当該要求は、当該要求テーブル１１８などの要求テーブルまたは要求キューに入力または更新される。決定された当該要求送信のための当該時間遅延長さも、当該要求と共に当該要求テーブルに格納される。

工程Ｓ３０８において、当該ユーザ端末は、当該ユーザが要求を開始した当該ユーザインターフェースまたは機能にまだ留まっているか否かを判断する。「いいえ」の場合、フローは工程Ｓ３１０に進む。「はい」の場合、フローは工程Ｓ３１２に進む。一部の実施態様において、当該判断は、当該ユーザインターフェース１０２または当該アプリケーションにより実行されてもよい。

工程Ｓ３１０において、当該要求が当該要求テーブルから削除される。当該ユーザは当該要求が開始された当該機能または当該ユーザインターフェースから離脱したと判断されるため、該当するデータへのアクセスを継続する必要はない。このメカニズムにより、不要なリソースの浪費を防止することができる。

工程Ｓ３１２において、当該ユーザ端末は、例えば、当該送信ユニット１１０により、当該サーバに当該要求を送信する。当該要求は、決定された送信タイミングで（または決定された遅延時間長さ後に）送信される。当該ユーザ端末内に、当該遅延時間長さが経過したことを判定するように構成された時計ユニットが存在してもよい。

工程Ｓ３１４において、当該サーバは、応答を当該ユーザ端末に送信する。当該応答は、リーダーボード情報など、当該ユーザが要求したデータを含む。

工程Ｓ３１６において、当該アプリケーション（または当該アプリケーションの当該機能）は、当該応答データにエラーが含まれているか否か、またはサーバの停止を示しているか否かをチェックする。「いいえ」の場合、フローは工程Ｓ３１８に進む。「はい」の場合、フローは工程Ｓ３２０に進む。

工程Ｓ３１８において、当該ユーザ端末は、応答データに基づいて、要求の結果を（アプリケーションの）ＵＩに表示する。データアクセスが正常に行われる。

工程Ｓ３２０において、当該ユーザ端末は、当該応答データに基づき、エラー、サーバビジー、またはサーバダウンを示すメッセージを表示する。

図４に示す実施態様において、工程Ｓ３０２４から工程Ｓ３２０へのルートがあることに留意する。この実施態様において、工程Ｓ３０２４で受信した当該ステータスパラメータが、当該サーバ／エンドポイントが停止状態などの非常に悪い状態であることを示す場合、フローは直接工程Ｓ３２０に進む。したがって、当該サーバ／エンドポイントが停止状態である場合、工程Ｓ３０４～Ｓ３１６をスキップすることにより、不必要なリソース消費やデータ送信を防止することができる。このメカニズムは、当該ユーザ端末と当該サーバの両方にとって有益である。

図５に、本発明の一部の実施態様に基づく例示的な時系列図を示す。

工程Ｓ５００において、当該ユーザ端末は要求を受信し、当該要求の回数（または当該要求の受信回数）を検出する。

工程Ｓ５０２において、当該ユーザ端末は当該エンドポイントデータベースにアクセスして、当該要求に対応する当該エンドポイントの当該エンドポイント（ＥＰ）ステータス（またはステータス予測）を要求する。

工程Ｓ５０４において、当該エンドポイントデータベースが当該エンドポイントステータスを当該ユーザ端末に返す。

工程Ｓ５０６において、当該ユーザ端末が当該ユーザデータベースにアクセスして、ユーザ貢献度データなどのユーザステータスデータを要求する。当該ユーザステータスデータは当該要求を開始した当該ユーザに対応する。

工程Ｓ５０８において、当該ユーザデータベースが当該ユーザステータスデータを当該ユーザ端末に返す。

工程Ｓ５１０において、当該ユーザ端末は、当該遅延ポリシーデータベース（当該ユーザ端末に存在してもしなくてもよい）にアクセスし、当該要求をサーバに送信するための当該遅延ポリシーを確認する。当該遅延ポリシーは、要求回数、当該エンドポイントステータス（またはステータス予測）、及び（または）当該ユーザステータスデータに依存または相関していてもよい。

工程Ｓ５１２において、当該ユーザ端末は、工程Ｓ５１０でアクセスされた当該遅延ポリシーに基づき、当該サーバに当該要求を送信するタイミング（または当該遅延時間長さ）を決定する。当該ユーザ端末は、当該要求キューに情報を更新する。

工程Ｓ５１４において、当該ユーザ端末は、当該ユーザが当該要求を開始したＵＩにまだ留まっていると判断し、当該遅延時間長さが経過したと判断する。

工程Ｓ５１６において、当該ユーザ端末は、決定された送信タイミングで当該サーバに当該要求を送信し、当該要求に対応するデータの送信を要求する。

工程にＳ５１８おいて、当該サーバは、要求されたデータを含む応答を当該ユーザ端末に返す。これにより、データアクセスが正常に完了する。

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

工程Ｓ６００において、当該サーバが複数の異なるユーザ端末から要求を受信する。

工程Ｓ６０２は、工程Ｓ６０２０と工程Ｓ６０２２を含む。

工程Ｓ６０２０において、当該サーバは、ユーザデータベース（当該サーバに存在してもしなくてもよい）にアクセスし、当該要求を開始した当該ユーザの貢献度スコアを要求する。

工程Ｓ６０２２において、当該サーバは、エンドポイントデータベース（当該サーバに存在してもしなくてもよい）にアクセスし、当該要求に対応する当該エンドポイントのステータス（またはステータス予測）を要求する。

工程Ｓ６０４において、当該サーバは、各要求の応答送信タイミングを決定する。応答送信タイミングとは、要求に対応する応答を対応する当該ユーザ端末に送信するタイミングである。

一部の実施態様において、要求に対応する当該応答送信タイミングは、当該要求を開始した当該ユーザの当該貢献度スコアに応じて決定されてもよい。例えば、対応する当該要求が貢献度スコアの高いユーザによって開始された場合、当該応答送信タイミングを早く／速くするように決定してもよい。例えば、対応する当該要求が貢献度スコアの低いユーザによって開始された場合、当該応答送信タイミングを後に／遅くするように決定してもよい。このメカニズムは、貢献度の高いユーザが要求したデータをより早く取得できるように、リソースを効率的に分配してる。

一部の実施態様において、要求に対応する当該応答送信タイミングは、当該要求に対応する当該エンドポイントのステータスに基づいて決定されてもよい。例えば、対応する当該要求の当該エンドポイントがより健全であることを当該ステータスデータが示している場合、当該応答送信タイミングはより早く／より速くなるように決定されてもよい。例えば、対応する当該要求の当該エンドポイントがより不健全であることを当該ステータスデータが示している場合、当該応答送信タイミングはより後に／遅くなるように決定されてもよい。このメカニズムは、異なるエンドポイントに対する負荷または処理を動的に調整し、すべてのデータアクセスが信頼性の高い方法で行われるように確約する。

工程Ｓ６０６において、当該サーバは、工程Ｓ６０４で決定されたタイミングで当該応答を当該ユーザ端末に送信し、これによりデータアクセスが終了する。

図７に、本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフを示す。

当該遅延時間長さは、（一定期間内の）当該要求の受信回数に基づいて決定される。当該遅延時間長さと当該要求の受信回数の間には指数関数的な関係がある。当該遅延時間長さには、最大遅延時間が設定される。図７は、当該遅延ポリシーテーブル１１６に格納された基準に対応してもよい。

図８に、本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフを示す。

当該遅延時間長さは、（一定期間内の）当該要求の受信回数に基づいて決定される。当該遅延時間長さと当該要求の受信回数の間には線形の関係がある。当該遅延時間長さには、最大遅延時間が設定される。図８は、当該遅延ポリシーテーブル１１６に格納された基準に対応してもよい。

図９に、本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフを示す。

当該遅延時間長さは、（一定期間内の）当該要求の受信回数に基づいて決定される。当該遅延時間長さと当該要求の受信回数の間には対数的な関係がある。当該遅延時間長さには、最大遅延時間が設定される。図９は、当該遅延ポリシーテーブル１１６に格納された基準に対応してもよい。

本発明の一実施態様において、当該ユーザ端末は、当該要求が初めて受信されたか否かを判定してもよい。当該要求が初めて受信された場合、当該ユーザ端末は、当該要求にいかなる遅延も適用しない。当該要求が初めて受信されたのではない場合、当該ユーザ端末は、本明細書で開示される遅延を当該要求に適用する。例えば、初回の要求は通常モード（遅延なし）で処理され、繰り返しの要求は指数関数的遅延モードで処理される。

図１０に、本発明の一部の実施態様に基づくユーザ端末からサーバに要求を送信するための遅延時間長さを決定する例示的な基準を示すグラフを示す。

当該遅延時間長さは、当該要求に対応する当該エンドポイントの重要度レベルによって決定される。当該遅延時間長さと当該重要度レベルの間には指数関数的な関係がある。当該遅延時間長さには、最大遅延時間が設定される。図１０は、当該遅延ポリシーテーブル１１６に格納された基準に対応してもよい。

図１１に、要求テーブル１１８の一例を示す。

この例では、受信された各要求について、当該要求を開始した対応する当該ユーザ（または当該ユーザ端末）、対応する当該エンドポイント、当該受信回数、当該遅延時間長さがテーブルに記録される。当該受信回数は、ユーザインターフェースからの情報によって更新されてもよい。当該遅延時間長さは、当該遅延ポリシーテーブル１１６を参照して更新されてもよい。一部の実施態様において、当該要求回数または当該エンドポイント重要度レベルが更新されるたびに、対応する当該遅延時間長さもそれに基づいて更新される。

図１２に、当該エンドポイントステータステーブル１１２の一例を示す。

この例において、各エンドポイントの当該重要度レベルまたは不健全性レベルがテーブルに記録される。

図１３に、当該ユーザステータステーブル１１４の一例を示す。

この例では、当該ユーザＵ１（当該ユーザ端末のユーザ）のステータスパラメータ（当該貢献度スコアやレベルなど）がテーブルに記録される。

図１４に、当該ユーザデータベース３１０の一例を示す。

図に示すように、当該ユーザデータベース３１０は、ユーザごとに異なるさまざまなパラメータを含んでいる。

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

工程Ｓ１５００において、ユーザ端末がユーザからの要求を検出する。

工程Ｓ１５０２において、当該ユーザ端末は、当該要要求を当該サーバに送信するための遅延時間を決定する。一部の実施態様において、当該遅延時間は、当該要求に対応するエンドポイントのステータスに基づき、及び（または）当該ユーザの貢献度スコアに基づき、決定されてもよい。

工程Ｓ１５０４において、当該要求は、要求キューまたは要求テーブルに入力またはスケジュールされる。

工程Ｓ１５０６において、当該ユーザ端末は、所定の期間内に再び同じ要求を検出または受信する。これは、当該ユーザが結果の表示を待ちきれず、再度同じボタンをタップするといったシナリオが考えられる。

工程Ｓ１５０８において、当該要求の受信回数に基づき、当該要求を当該サーバに送信するための遅延時間が更新される。工程Ｓ１５０６と工程Ｓ１５０８は、所定の期間内に当該ユーザから繰り返し当該要求が送信された場合に繰り返される。例えば、図７、図８または図８に示すように、当該要求の受信回数が増加するにつれ、当該遅延時間が延長される。一部の実施態様において、それは、アプリケーション上のページまたは機能を繰り返しリフレッシュする傾向があるそれらのユーザに対する罰のメカニズムとして機能してもよい。

工程Ｓ１５１０において、当該所定の期間が経過した後、及び当該遅延時間が経過した後、当該ユーザ端末は、当該ユーザが当該要求を開始したＵＩにまだ留まっていると判断する。

工程Ｓ１５１２において、当該ユーザ端末は、要求されたデータを要求するために、当該サーバに当該要求を送信する。

本発明は、データアクセスのための改良された方法及びシステムを開示する。要求回数、エンドポイントステータス、及び（または）貢献度スコアに基づいて、ユーザ端末からサーバに要求を送信するための遅延時間を導入することにより、利用可能な限られたリソースをより良く配分し、サーバ／エンドポイントの停止を防止することができる。

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

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

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

１ 通信システム
１０ ユーザ端末
３０ バックエンドサーバ
４０ ストリーミングサーバ
９０ ネットワーク
１００ ユーザ端末
１０２ ユーザインターフェース
１０４ エンドポイントステータスモニター
１０６ ユーザステータスモニター
１０８ 送信タイミングコントローラ
１１０ 送信ユニット
１１２ エンドポイントステータステーブル
１１４ ユーザステータステーブル
１１６ 遅延ポリシーテーブル
１１８ 要求テーブル
３００ エンドポイントデータベース
３１０ ユーザデータベース
Ｓ１００、Ｓ１０２、Ｓ１０４、Ｓ１０６、Ｓ１０８、Ｓ１１０ 工程
Ｓ３００、Ｓ３０２、Ｓ３０４、Ｓ３０６、Ｓ３０８、Ｓ３１０、Ｓ３１２、Ｓ３１４、Ｓ３１６、Ｓ３１８、Ｓ３２０、Ｓ３０２０、Ｓ３０２２、Ｓ３０２４ 工程
Ｓ５００、Ｓ５０２、Ｓ５０４、Ｓ５０６、Ｓ５０８、Ｓ５１０、Ｓ５１２、Ｓ５１４、Ｓ５１６、Ｓ５１８ 工程
Ｓ６００、Ｓ６０２、Ｓ６０４、Ｓ６０６、Ｓ６０２０、Ｓ６０２２ 工程
Ｓ１５００、Ｓ１５０２、Ｓ１５０４、Ｓ１５０６、Ｓ１５０８、Ｓ１５１０、Ｓ１５１２ 工程
Ｒ１、Ｒ２、Ｒ３ 要求
Ｕ１、Ｕ２、Ｕ３ ユーザ
ＥＰ１、ＥＰ２、ＥＰ３ エンドポイント
Ｔ１、Ｔ２、Ｔ３ 遅延時間長さ

Claims (8)

1. データアクセスのための方法であって、
   要求を受信する工程と、
   一定期間内に前記要求を受信した回数を受信する工程と、
   前記期間内の前記要求の受信回数に基づき、前記要求を送信するための遅延時間長さを決定する工程と、
   ユーザインターフェースでユーザから前記要求を受信する工程と、
   前記要求を要求キューに格納する工程と、
   前記ユーザが前記ユーザインターフェースから離脱したと判断する工程と、
   前記要求を前記要求キューから削除する工程と、
   を含むことを特徴とする、データアクセスのための方法。
2. 前記遅延時間長さが、前記期間内に前記要求を受信した回数が多いほど長く決定されることを特徴とする、請求項１に記載のデータアクセスのための方法。
3. さらに、
   前記要求に対応するエンドポイントのステータスパラメータを受信する工程を含み、
   前記決定する工程は、前記エンドポイントの前記ステータスパラメータおよび前記期間内の前記要求の受信回数に基づき、前記要求を送信するための遅延時間長さを決定する工程を含み、
   前記遅延時間長さが、前記要求に対応する前記エンドポイントの前記ステータスパラメータが、前記エンドポイントの比較的重大な状態を示すとき、より長く決定される、ことを特徴とする、請求項１に記載のデータアクセスのための方法。
4. さらに、
   前記ユーザが前記ユーザインターフェースに留まっていると判断する工程と、
   前記遅延時間長さが経過したと判断する工程と、
   前記要求を前記要求に対応するエンドポイントに対応するサーバに送信する工程と、
   を含むことを特徴とする、請求項１に記載のデータアクセスのための方法。
5. 前記遅延時間長さが、前記期間内の前記要求の受信回数に指数関数的に増大する、ことを特徴とする、請求項２に記載のデータアクセスのための方法。
6. さらに、
   前記ユーザに対応する貢献度スコアを受信する工程と、
   前記貢献度スコアに基づき、前記遅延時間長さを決定する工程と、
   を含むことを特徴とする、請求項１に記載のデータアクセスのための方法。
7. データアクセスのためのシステムであって、１以上のプロセッサを備え、そのうち、前記１以上のプロセッサが機械可読命令を実行して、
   要求を受信する工程と、
   一定期間内に前記要求を受信した回数を受信する工程と、
   前記期間内の前記要求の受信回数に基づき、前記要求を送信するための遅延時間長さを決定する工程と、
   ユーザインターフェースでユーザから前記要求を受信する工程と、
   前記要求を要求キューに格納する工程と、
   前記ユーザが前記ユーザインターフェースから離脱したと判断する工程と、
   前記要求を前記要求キューから削除する工程と、
   を実行することを特徴とする、データアクセスのためのシステム。
8. データアクセスのためのプログラムを含む非一時的なコンピュータ可読媒体であって、そのうち、前記プログラムが、１以上のコンピュータに、
   要求を受信する工程と、
   一定期間内に前記要求を受信した回数を受信する工程と、
   前記期間内の前記要求の受信回数に基づき、前記要求を送信するための遅延時間長さを決定する工程と、
   ユーザインターフェースでユーザから前記要求を受信する工程と、
   前記要求を要求キューに格納する工程と、
   前記ユーザが前記ユーザインターフェースから離脱したと判断する工程と、
   前記要求を前記要求キューから削除する工程と、
   を実行させることを特徴とする、コンピュータ可読媒体。

Images