JP2016519380A - 読書速度に基づく情報送信 - Google Patents

Abstract

【解決手段】読む速度に基づいた情報送信が開示されている。この情報送信は、ユーザ識別子を含む情報取得要求をクライアントデバイスから受信し、情報取得要求に含まれるユーザ識別子を決定し、格納されている履歴記録から、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を決定し、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量に少なくとも部分的に基づいて、ユーザ識別子に対応する読む速度を決定し、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて、クライアントデバイスに送信される要求情報の量を決定すること；その量の要求情報をクライアントデバイスに送信すること、を備える。【選択図】図３

Description

他の出願の相互参照
本願は、すべての目的のために参照により本明細書に組み込まれる、２０１３年５月１６日出願の発明の名称を「Ａ ＭＥＴＨＯＤ ＡＮＤ ＤＥＶＩＣＥ ＦＯＲ ＴＲＡＮＳＭＩＴＴＩＮＧ ＩＮＦＯＲＭＡＴＩＯＮ」とする中国特許出願第２０１３１０１８１９２６．０号に基づく優先権を主張する。

本願は、コンピュータ技術の分野に関し、特に、情報を送信するための技術に関する。

現在では、無線ネットワークおよび携帯端末のたゆまぬ発展により、ユーザは、いつでもどこでも、求める情報をサーバから取得できる。

現在、サーバからクライアントデバイスに情報を送信するための一般的な技術は、以下の通りである。クライアントデバイスが、ユーザまたはコンピュータプログラムから情報取得コマンドを受信すると、情報取得要求をサーバに送信する。サーバは、クライアントデバイスが要求した情報を決定し、クライアントデバイスが要求した情報の内の一定量をクライアントデバイスに送り返す。クライアントデバイスは、別の情報取得コマンド（例えば、次頁コマンド）を受信すると、別の情報取得要求をサーバに送信し、サーバは、クライアントデバイスが要求した情報の内の別の一定量をクライアントデバイスに送り返す。

例えば、一定量が１０個の情報であり、クライアントデバイスが１００個の情報を要求したとサービス側が判定したと仮定する。このシナリオ例では、サービス側は、これらの１００個の情報の内の最初の１０個を表示に向けてクライアントデバイスに送り返す。図１は、クライアントデバイスのディスプレイの一例を示す。ディスプレイは、サービス側によって返された要求済みの情報の最初の１０個の内の７個を表示している。各情報は、ラベル「行」および対応する「４」〜「１０」の数字と関連している。これらの１０個の情報を閲覧した後、クライアントデバイスを用いるユーザは、次の情報を閲覧したいと思いうる。次いで、ユーザは、図１の例に示した「さらにロード」ボタンを選択し、次頁コマンドを送信する。別の例において、ユーザは、スクリーンを最後の情報（図１に示した「行１０」）までスクロールさせることによって次頁コマンドを送信してもよい。

クライアントデバイスは、次頁コマンドを受信した後、情報取得要求をサーバに送信する。それに応答して、サーバは、先述の１００個の情報の内の１１〜２０個目までの情報を表示に向けてクライアントデバイスに送り返す。

しかしながら、実際の応用例では、各閲覧者の読む速度は異なる。したがって、一定量の情報を各ユーザに送信するのでは、各ユーザの個々のニーズを満たすことができない場合がある。さらに、より速く読むユーザの場合、かかるユーザは、サーバによって送り返された一定量の情報を毎回すぐに閲覧し終え、別の一定量の情報の閲覧を要求する。情報閲覧のピーク期間中に、比較的多くの速読ユーザが自分のクライアントデバイスでさらなる情報を要求すると、サーバに要求が殺到する。膨大な要求が、サーバの性能低下につながりうる。

以下の詳細な説明と添付の図面において、本発明の様々な実施形態を開示する。

クライアントデバイスのディスプレイの一例を示す図。

サーバからクライアントデバイスに情報を送信するためのシステムの一実施形態を示す図。

サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャート。

サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャート。

サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャート。

クライアントデバイスによって情報を要求するための処理の一実施形態を示すフローチャート。

サーバを実装するサーバの一実施形態を示す図。

サーバに関連するアプリケーションを実行するクライアントデバイスの一実施形態を示す図。

読む速度に基づいて情報を送信するためのサービスを実装するようにプログラムされたコンピュータシステムの一実施形態を示す機能図。

本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。

以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、本発明は、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術事項については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。

読む速度に基づいて情報を送信する実施形態について、本明細書に記載する。いくつかの実施形態において、情報取得要求が、クライアントデバイスから受信される。いくつかの実施形態において、情報取得要求に含まれるユーザ識別子が決定される。いくつかの実施形態において、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量が、格納されている履歴記録から決定される。ユーザ識別子に対応する読む速度が、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量に少なくとも部分的に基づいて決定される。クライアントデバイスに送信される要求情報（要求された情報）の量が、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて決定される。例えば、読む速度が速いほど、決定される要求情報の量は多くなる。その量の要求情報が、クライアントデバイスに送信される。

図２は、サーバからクライアントデバイスに情報を送信するためのシステムの一実施形態を示す図である。この例において、システム２００は、クライアントデバイス２０２、ネットワーク２０３、サーバ２０４、および、データベース２０５を備える。ネットワーク２０３は、高速データネットワークおよび／または遠隔通信ネットワークを含む。データベース２０５は、１または複数のデータベースによって実装されてよい。この図では、クライアントデバイス２０２がスマートフォンとして示されているが、クライアントデバイス２０２のその他の例としては、ラップトップコンピュータ、デスクトップコンピュータ、タブレットデバイス、携帯デバイス、および／または、任意のその他のタイプのコンピュータデバイスが挙げられる。

サーバ２０４は、クライアントデバイス（クライアントデバイス２０２など）から受信した情報取得要求に応答して、或る量の要求情報をクライアントデバイスに送信するサービスを実装するよう構成されている。サービスから取得できる情報のタイプの例は、フォーラム、ニュース、レビュー、マイクロブログ、ブログ、および、掲示板を含む。様々な実施形態において、サーバ２０４は、要求に関連するユーザ識別子に対応する読む速度に少なくとも部分的に基づいて、クライアントデバイス２０２に送信する要求情報の量を決定するよう構成されている。いくつかの実施形態において、ユーザ識別子に対応する読む速度は、データベース２０５に格納されている履歴データに少なくとも部分的に基づいて決定される。データベース２０５は、サーバ２０４によってアクセス可能である。例えば、データベース２０５は、クライアントデバイス２０２を利用したユーザに対応するユーザ識別子によって要求された情報をサーバが送信した履歴時刻（すなわち、履歴情報送信時刻）と、それらの時刻に送信された対応する要求情報の量（すなわち、履歴送信情報量）と、を格納するよう構成されている。

クライアントデバイス２０２は、サーバ２０４によって実装されたサービスに情報取得要求を送信するよう構成されている。いくつかの実施形態において、クライアントデバイス２０２は、サーバへのアクセスを提供するソフトウェアアプリケーションを実行するよう構成されている。いくつかの実施形態において、クライアントデバイス２０２は、（例えば、アプリケーションでのユーザ選択を介して）情報取得コマンドの受信に応答して、情報取得要求をサーバに送信するよう構成されている。例えば、サーバに送信された情報取得要求が要求情報の量を含まない場合、サーバ２０４は、上述のように、この量を決定するよう構成されている。

いくつかの実施形態では、クライアントデバイス２０２自体が、サーバ２０４から要求される要求情報の量を決定し、サーバ２０４に送信する情報取得要求にこの量を含めるよう構成されている。いくつかの実施形態において、クライアントデバイス２０２は、クライアントデバイス２０２を利用したユーザに対応するユーザ識別子によって要求された情報をクライアントデバイス２０２が受信した履歴時刻（すなわち、履歴情報受信時刻）およびそれらの時刻に受信された対応する要求情報量（すなわち、履歴受信情報量）などの履歴データを格納するよう構成されている。いくつかの実施形態において、クライアントデバイス２０２は、クライアントデバイス２０２を利用したユーザに対応するユーザ識別子に対応する読む速度に少なくとも部分的に基づいて、サーバ２０４から取得する要求情報の量を決定するよう構成されている。いくつかの実施形態において、ユーザ識別子に対応する読む速度は、クライアントデバイス２０２によって格納されている履歴データに少なくとも部分的に基づいて決定される。いくつかの実施形態において、クライアントデバイス２０２は、クライアントデバイス２０２によって決定された要求情報量を含む情報取得要求をサーバ２０４に送信するよう構成されている。クライアントデバイス２０２によって決定された要求情報量を含む情報取得要求を受信したことに応答して、サーバ２０４は、その量の要求情報をクライアントデバイス２０２に送り返すよう構成されている。

以下で詳述するように、システム（システム３００など）が、ユーザの読む速度に少なくとも部分的に基づいて、各情報要求当たりユーザに送信する要求情報の量を調整するので、ユーザは、受信した情報をあまりに早く読み終わってしまうことも、あまりに過剰な量の情報を受信することによってシステムリソースを浪費することもない。ユーザに送信する要求情報の量は、サーバ（サーバ２０４など）またはユーザのクライアントデバイス（クライアントデバイス２０２など）によって決定されうる。

図３は、サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理３００は、図２のシステム２００で実行される。具体的には、いくつかの実施形態において、処理３００は、図２のシステム２００のサーバ２０４で実行される。

処理３００は、クライアントデバイスで（例えば、ユーザまたはコンピュータプログラムから）情報取得コマンドが受信されるたびに実行されてよい。処理３００は、クライアントデバイスに送信される要求情報の量を決定するために実行されうる。

工程３０２では、ユーザ識別子を含む情報取得要求が、クライアントデバイスから受信される。

様々な実施形態において、ユーザは、自分が使用しているクライアントデバイスを介してサーバから情報を取得したい時、クライアントデバイスのインターフェース（例えば、キーパッド、タッチスクリーン）を介して入力または選択を行うことで、サーバによって実装されたサービスに関連する情報取得コマンドを選択できる。例えば、サーバに関連するソフトウェアアプリケーションが、クライアントデバイスで実行されていてよいサーバから取得できる情報のタイプの例は、フォーラム、ニュース、レビュー、マイクロブログ、ブログ、および、掲示板を含む。要求情報は、テキストおよびマルチメディアデータ（画像、オーディオ、および／または、ビデオファイルなど）を含みうる。クライアントデバイスは、ユーザから情報取得コマンドを受信した後、対応する情報を取得するために、情報取得要求をサーバに送信する。情報取得要求（例えば、ＨＴＴＰ ＧＥＴ要求）は、どの情報が要求されているのかを特定するデータを含んでよい。例えば、どの情報が要求されているのかを特定するデータは、掲示板の特定のページの特定の部分をロケートするために用いられるＵＲＬなど、掲示板の特定のページの特定の部分を識別できる。

様々な実施形態において、情報取得要求は、さらに、クライアントデバイスおよび／またはサービスに関連するアプリケーションに現在ログイン中のユーザのユーザ識別子を含んでよい。ユーザ識別子は、英数字の文字列を含みうる。

クライアントデバイスから受信した情報取得要求に応答して、サーバは、要求情報の内のいくつかの情報を送り返し、その後、それらの情報は、クライアントデバイスで表示される。ユーザは、クライアントデバイスでこれらのいくつかの情報を閲覧し終えた後、クライアントデバイスのインターフェースを介して別の情報取得コマンド（例えば、次頁コマンド）を選択してよい。クライアントデバイスは、次頁コマンドを受信した後、要求情報の内のさらなる情報を取得するために、別の情報取得要求をサーバに送信することができる。この後続の情報取得要求は、どの情報が要求されているのかを特定するデータ（例えば、掲示板の次のページに関連付けられたＵＲＬ）と、クライアントデバイスおよび／またはサーバに関連するアプリケーションに現在ログイン中のユーザのユーザ識別子と、を含んでもよい。

工程３０４では、情報取得要求に含まれるユーザ識別子が決定される。

いくつかの実施形態において、サーバは、経時的に様々なユーザ識別子に対応する情報取得要求を処理するので、サービスを実装するサーバは、履歴記録内に、要求情報が各要求ユーザ識別子に送り返された時刻と、各要求ユーザ識別子に送り返された対応する要求情報の量とを格納する。具体的には、例えば、情報取得要求に応答してクライアントデバイスに情報を送信するごとに、サーバは、情報取得要求に含まれるユーザ識別子に対応するデータを履歴記録内に格納できる。格納されているデータは、要求の送信元であるクライアントデバイスに要求情報が送信された時刻（すなわち、情報送信時刻）と、情報送信時刻に送信された情報の量（すなわち、送信情報量）と、を含む。

工程３０６では、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量が、格納されている履歴記録から決定される。

情報取得要求を受信した後、サーバは、情報取得要求に含まれるユーザ識別子を決定し、格納されている履歴記録内で、そのユーザ識別子に対応する履歴情報送信時刻および履歴送信情報量をルックアップできる。

工程３０８では、ユーザ識別子に対応する読む速度が、１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量に少なくとも部分的に基づいて決定される。

ルックアップされた履歴情報送信時刻および履歴送信情報量は、ユーザ識別子に対応する読む速度を決定するために用いられる。

いくつかの実施形態において、サーバは、ユーザ識別子に対応する読む速度を決定する。いくつかの実施形態において、サーバは、すべてのルックアップされた履歴情報送信時刻の中で、（例えば、サーバによって維持された現在時刻から）最も新しい情報送信時刻をＴ１として、最も古い送信時刻をＴ２として特定しうる。さらに、サーバは、最も古い情報送信時刻Ｔ２と、最も新しい情報送信時刻Ｔ１との間の時間間隔を、差（Ｔ１−Ｔ２）として決定できる。次いで、サーバは、すべてのルックアップされた履歴送信情報量の合計ｍを決定できる。例えば、ｍの値は、ユーザ識別子に対して送信された情報の総数または総量を表しうる。最後に、サーバは、すべての送信情報量の合計ｍの、最も古い情報送信時刻と最も新しい情報送信時刻との間の時間間隔Ｔ１−Ｔ２に対する比ｍ／（Ｔ１−Ｔ２）を、ユーザ識別子に対応する読む速度として決定できる。

ユーザの読む速度は、非常に時間依存であると考えることができる。したがって、読む速度の決定の精度を高めるために、いくつかの実施形態では、最新の事前設定された指定時間長内の履歴情報送信時刻および履歴送信情報量だけが、ユーザ識別子に対応する読む速度を決定するために用いられる。指定時間長は、システム管理者によって予め設定されうる。例えば、いくつかの実施形態において、サーバは、履歴記録の中で、最新の事前設定された指定時間長内に収まるユーザ識別子に対応する履歴情報送信時刻、および、最新の事前設定された指定時間長内に収まるユーザ識別子に対応する全情報送信時刻に対応する送信情報量だけをルックアップしうる。したがって、最新の事前設定された指定時間長を用いる場合、ユーザ識別子に対応する読む速度は、最新の事前設定された指定時間長内に収まる全情報送信時刻に対応するルックアップされた履歴送信情報量の合計の、指定時間長に対する比として決定できる。

以下は、最新の事前設定された指定時間長を用いてユーザ識別子に対応する読む速度を決定する一例である。指定時間長が１分であると仮定する。その場合、サーバは、現在時刻（例えば、サーバによって維持されている現在時刻）から最近１分以内のユーザ識別子に対応する履歴情報送信時刻を履歴記録内でルックアップする。ルックアップされた最近１分以内の情報送信時刻が、Ｔ１およびＴ２であるとする。次いで、サーバは、Ｔ１およびＴ２に対応して、それぞれ、ユーザ識別子に対応する履歴送信情報量をルックアップする。現在時刻が１２：００：００ｐｍであるとする。ユーザは、以前、１１：５８：５９ｐｍ、１１：５９：５０ｐｍ、および、１１：５９：５５ｐｍにサーバからのデータを要求した。指定時間長が１分間である場合、この例においては、Ｔ１は１１：５９：５０ｐｍ、Ｔ２は１１：５９：５５ｐｍである。Ｔ１に対応するルックアップされた履歴送信情報量がＭ１であり、Ｔ２に対応する履歴送信情報量がＭ２であるとする。したがって、サーバは、Ｍ１およびＭ２の合計：Ｍ１＋Ｍ２を決定する。最後に、サーバは、Ｍ１＋Ｍ２と指定時間長１分との比を、ユーザ識別子に対応する読む速度として決定する。言い換えると、この例においてユーザ識別子に対応して決定された読む速度は、毎分（Ｍ１＋Ｍ２）個の情報である。

さらに、サーバは、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報送信時刻を履歴記録内で全く見つけられなかった（すなわち、サーバが、最新の事前設定された指定時間長内に、ユーザ識別子に対応するユーザに情報を送信しなかった）場合、事前設定されたデフォルトの読む速度をユーザ識別子に対応する読む速度として決定する。デフォルトの読む速度は、システム管理者によって予め設定されうる。

工程３１０では、クライアントデバイスに送信される要求情報の量が、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて決定される。

様々な実施形態において、クライアントデバイスに送信される要求情報の量は、ユーザ識別子に対応する決定済みの読む速度に少なくとも部分的に基づいて決定される。様々な実施形態において、読む速度が速いほど、クライアントデバイスに送信される要求情報の量は多くなる。要求情報の量とは、情報取得要求に応答してクライアントデバイスに送信される情報取得要求によって特定されたタイプの情報の個数または単位数を意味しうる。例えば、掲示板からの１個の情報が、メッセージを含み、ブログからの１個の情報が、ブログ投稿を含みうる。

いくつかの実施形態において、関数関係（例えば、Ｎ＝Ｆ（ｖ））が、サーバに事前設定されてもよく、ここで、Ｎは、ユーザ識別子に対応して返される要求情報の量であり、ｖは、ユーザ識別子に対応する読む速度であり、Ｆ（ｖ）は、ユーザ識別子に対応する読む速度とユーザ識別子に対応して返される情報の量との間の関数関係である。様々な実施形態において、Ｆ（ｖ）は、ｖが速いほどＮが大きくなるように、任意の増加関数（例えば、単調増加関数）になるよう選択されうる。逆に、ｖが小さいほど、Ｎが小さくなる。Ｆ（ｖ）は、連続関数または離散関数になるよう選択されうる。例えば、Ｎ＝Ｆ（ｖ）＝２ｖである。

工程３１２では、送信されるべき量の要求情報がクライアントデバイスに送信される。クライアントに送信される適切な量が決定されると、情報取得要求において要求された情報の内の決定された適切な量の情報が決定され、クライアントデバイスに送信される。例えば、決定された量が１５個の情報であり、要求情報が掲示板の特定のページ内のメッセージを含む場合、掲示板のそのページから（例えば、クライアントデバイスに以前に送信されていない）１５個のメッセージが、クライアントデバイスに送信され、クライアントデバイスによって表示されうる。

いくつかの実施形態において、要求情報の内、以前にクライアントデバイスに送信されていない情報だけが、クライアントデバイスから受信された各後続の情報取得要求に応答して、クライアントデバイスに送信されると決定される。例えば、クライアントデバイスから受信されたユーザ識別子に対応する第１の情報取得要求に応答して、工程３１０において決定された適切な量が、要求された一連の２００個の情報の内の１２個の情報である場合、要求情報の１から１２個までが、クライアントデバイスに送信される。次いで、同じクライアントデバイスから受信された同じユーザ識別子に対応する第２の情報取得要求に応答して、工程３１０において決定された適切な量が、要求された一連の２００個の情報の内の１４個の情報である場合、要求情報の１３から２７個までが、クライアントデバイスに送信される。

上記の処理３００は、各ユーザに一定量の情報を送り返すのではなく、ユーザの読む速度に少なくとも部分的に基づいて決定された量の情報をユーザに送信するサーバについて記載している。このように、処理３００は、各ユーザの個々のニーズを満たすことができる。サーバが、クライアントデバイスに適切な量の要求情報を送信するので、各ユーザは、おそらく、情報取得要求をサーバに送る頻度が低くなる。したがって、サーバが受信および処理する情報取得要求が少なくなりうるので、サーバおよびネットワークへの全体の負荷を低減できる。

図４は、サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理４００は、図２のシステム２００で実行される。具体的には、いくつかの実施形態において、処理４００は、図２のシステム２００のサーバ２０４で実行される。

いくつかの実施形態では、ユーザの読む速度に加えて、クライアントデバイスが動作しているネットワークに関連する要因も、情報取得要求に応答してクライアントデバイスに送信する要求情報の量に影響を与えうる。処理４００は、ユーザの読む速度に加えて、クライアントデバイスに関連するネットワーク要因に基づいて、クライアントデバイスに送信する要求情報の量を決定する処理の一例を記載する。

工程４０２では、ユーザ識別子を含む情報取得要求が、クライアントデバイスから受信される。工程４０２は、図３の処理３００の工程３０２が実行されるのと同様の方法で実行され得る。

工程４０４では、ネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方が、クライアントデバイスから受信される。

クライアントデバイスが比較的悪いネットワーク環境にある場合、または、クライアントデバイスのネットワークアクセスモードに対応する情報伝送速度が比較的遅い場合、サーバは、クライアントデバイスに送信しようとする要求情報の性質を調節する必要がありうる。したがって、いくつかの実施形態において、サーバは、クライアントに送信する情報の量を決定する前に、クライアントデバイスによって報告されるネットワーク性能重み、ネットワークアクセスモード情報、または、それら両方を受信する必要もある。

クライアントデバイスによって報告されるネットワーク性能重みは、クライアントデバイスが現在位置するネットワーク環境の状態を表す。より大きいネットワーク性能重みは、クライアントが現在位置するネットワーク環境がより良好であることを示しており、したがって、より大きく決定された量の要求情報が、クライアントデバイスに送信されることが好ましいことを示唆する。逆に、より小さいネットワーク性能重みは、クライアントが現在位置するネットワーク環境がより悪いことを示しており、したがって、より小さく決定された量の要求情報が、クライアントデバイスに送信されることが好ましいことを示唆する。

いくつかの実施形態において、クライアントデバイスは、サーバに送信するネットワーク性能重みを決定できる。以下は、クライアントデバイスがネットワーク性能重みを決定できる技術の一例である：クライアントデバイスは、クライアントデバイスが情報取得要求をサーバに送信した各時刻に対応する送信時刻と、対応する要求情報がサーバから受信された時刻に対応する受信時刻とを記録する。クライアントデバイスは、ネットワーク性能重みを決定する時、最新の記録された送信時刻をｔ１として、対応する受信時刻をｔ２として決定する。クライアントデバイスは、受信時刻ｔ２から送信時刻ｔ１を引くことによって、送信時刻と受信時刻との間の時間間隔を決定する。さらに、クライアントデバイスは、事前設定された単位時間Ｔを用いる。クライアントデバイスは、単位時間Ｔと、決定された時間間隔（ｔ１−ｔ２）との比を決定して、Ｔ／（ｔ２−ｔ１）を決定し、これは、クライアントデバイスがサーバに報告するネットワーク性能値を表す。Ｔ／（ｔ２−ｔ１）からわかるように、クライアントデバイスによって送信された情報取得要求の送信時刻と、サーバによって返された情報の受信時刻との間の時間間隔が小さいほど、クライアントデバイスのために高い帯域幅率を有する良好なネットワーク環境であることが示唆される。

いくつかの実施形態において、（例えば、クライアントによって維持されている）現在時刻と最新の記録された送信時刻との間の時間間隔、または、最新の記録された送信時刻とクライアントデバイスによって決定された対応する受信時刻との間の時間間隔のいずれかが、設定閾値（例えば、１０分）を超えた場合、クライアントデバイスは、事前設定されたデフォルトのネットワーク性能重みをネットワーク性能重みとして用いて、サーバに報告することができる。

いくつかの実施形態において、クライアントデバイスは、現在利用中のネットワークアクセスモード情報を決定し、そのネットワークアクセスモード情報をサーバに送信する。例えば、クライアントデバイスがＡｎｄｒｏｉｄ（商標）プラットフォームを実行していた場合、ネットワークアクセスモードは、プラットフォーム固有のＡＰＩ呼び出しによって決定されうる（例えば、ＣｏｎｎｅｃｔｉｖｉｔｙＭａｎａｇｅｒクラスのＮｅｔｗｏｒｋＩｎｆｏおよびｇｅｔＴｙｐｅ（）メソッドになされる呼び出し）。ネットワークアクセスモードの例は、第２世代（２Ｇ）移動通信技術ネットワーク、第３世代（３Ｇ）移動通信技術ネットワーク、ロングタームエボリューションネットワーク（４Ｇ ＬＴＥ）、および、ワイヤレスフィディリティ（Ｗｉ−Ｆｉ）ネットワークを含む。２Ｇネットワーク、３Ｇネットワーク、ロングタームエボリューションネットワーク（４Ｇ ＬＴＥ）、および、Ｗｉ−Ｆｉネットワークの各々に対応する情報伝送速度ｓが、サーバに予め設定されてよい。例えば、ネットワークアクセスモードが２Ｇネットワークであった場合、対応する情報伝送速度ｓ＝０．５であり；ネットワークアクセスモードが３Ｇネットワークであった場合、対応する情報伝送速度ｓ＝１であり；ネットワークアクセスモードがＷｉＦｉネットワークであった場合、対応する情報伝送速度ｓ＝２である。クライアントデバイスによって報告されたネットワークアクセスモード情報に対応する情報伝送速度が速いことは、それに対応して、クライアントデバイスに送り返されることが好ましい情報の量が多くなることに関連する。逆に、クライアントによって報告されたネットワークアクセスモード情報に対応する情報伝送速度が遅いことは、それに対応して、クライアントデバイスに送り返されることが好ましい情報の量が少なくなることに関連する。

工程４０６では、ユーザ識別子に対応する読む速度が決定される。いくつかの実施形態において、ユーザ識別子に対応する読む速度は、図３の処理３００の工程３０４〜３０８に少なくとも部分的に基づいて決定される。

工程４０８では、クライアントデバイスに送信される要求情報の量が、ユーザ識別子に対応する読む速度、ネットワーク性能重み、および、ネットワークアクセスモード情報に少なくとも部分的に基づいて決定される。

いくつかの実施形態において、クライアントデバイスに送信される要求情報の量は、情報取得要求に関連するユーザ識別子に対応する読む速度に加えて、クライアントデバイスから受信したネットワーク性能重み、および、ネットワークアクセスモード情報に対応する情報伝送速度の関数として決定されてよい。いくつかの実施形態では、読む速度（ｖ）、ネットワーク性能重み（ｆ）、および、ネットワークアクセスモード情報（ｓ）に、送り返される情報の量（Ｎ）を関連付ける関数関係（例えば、Ｎ＝Ｆ（ｖ，ｆ，ｓ））が、サーバで予め設定されてよい。Ｆ（ｖ，ｆ，ｓ）は、連続関数または離散関数になるよう選択されうる。例えば、Ｎ＝Ｆ（ｖ，ｆ，ｓ）＝０．２＊ｖ＊ｆ＊ｓである。

工程４１０では、送信されるべき量の要求情報がクライアントデバイスに送信される。

図５は、サーバからクライアントデバイスに情報を送信するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理５００は、図２のシステム２００で実行される。具体的には、いくつかの実施形態において、処理５００は、図２のシステム２００のサーバ２０４で実行される。

いくつかの実施形態において、要求情報は、例えば、グラフィック、オーディオ、および、ビデオなどのマルチメディアデータを含む。各クライアントデバイスがマルチメディアデータを表示する能力は、クライアントデバイスに関連して用いられるハードウェアに応じて様々である。したがって、いくつかの実施形態では、クライアントデバイスに送信される要求情報に含められるマルチメディアデータの品質レーティングが、クライアントデバイスに関連するハードウェア性能重みに少なくとも部分的に基づいて決定される。処理５００は、クライアントデバイスに送信される量の要求情報に含められるマルチメディアデータに関する品質レーティングを決定する処理の一例を記載する。

工程５０２では、ユーザ識別子を含む情報取得要求が、クライアントデバイスから受信される。工程５０２は、図３の処理３００の工程３０２が実行されるのと同様の方法で実行され得る。

工程５０４では、ネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方が、クライアントデバイスから受信される。いくつかの実施形態において、ネットワーク性能重みは、図４の処理４００の工程４０４について記載した方法と同様の方法でクライアントデバイスによって決定されうる。

工程５０６では、クライアントデバイスに送信される要求情報の量が決定される。いくつかの実施形態において、クライアントデバイスに送り返される要求情報の量は、図３の処理３００の工程３０４〜３１０に基づいて決定できる。いくつかの実施形態において、クライアントデバイスに送り返される要求情報の量は、図４の処理４００の工程４０４〜４０８に基づいて決定できる。

例えば、決定された量は、１５個の情報でありえ、要求情報は、掲示板の特定のページ内のメッセージを含む。したがって、掲示板の特定のページから１５個のメッセージが、クライアントに送信される。掲示板のこのページからのメッセージは、以前にクライアントデバイスに送信されていないので、ページに関連する１００個のメッセージの内のメッセージ１〜１５が、クライアントデバイスに送信される。

工程５０８では、ハードウェア情報がクライアントデバイスから受信される。

いくつかの実施形態において、サーバは、決定された量の要求情報をクライアントデバイスに送信する前に、クライアントデバイスによって報告されるハードウェア情報を受信する必要もある。

グラフィックデータであるマルチメディアを一例として用いると、高い解像度を有するグラフィックが、比較的高いスクリーンピクセル密度を有するクライアントデバイスで表示されるのに適しうる。クライアントデバイスに送信する要求情報に含まれるグラフィックの解像度が、クライアントデバイスのスクリーンピクセル密度に比べて低すぎる場合、グラフィックは、クライアントデバイスでピクセレートされて現れるため、それは、ユーザ体験に悪影響を与える。逆に、スクリーンピクセル密度が比較的低いクライアントデバイスは、解像度が高いグラフィックの表示には適さない。クライアントデバイスに送信する要求情報に含まれるグラフィックの解像度が高すぎる場合、そのグラフィックの高品質は、クライアントデバイスのディスプレイには現れず、要求情報のサイズが大きいためにネットワークリソースの浪費につながりうる。

クライアントデバイスによって報告されるハードウェア情報のパラメータの例は、クライアントのＣＰＵ型番、ＣＰＵ周波数、合計メモリ、使用可能メモリ、空きメモリ、スクリーン解像度、および、スクリーンピクセル密度を含むが、これらに限定されない。例えば、クライアントのＣＰＵ型番およびＣＰＵ周波数は、クライアントデバイスがｐｒｏｃファイルシステム内のＣＰＵｉｎｆｏファイルを構文解析することによって取得できる。例えば、合計メモリは、クライアントデバイスがｐｒｏｃファイルシステム内のｍｅｍｉｎｆｏファイルを構文解析することによって取得できる。例えば、使用可能メモリおよび空きメモリは、クライアントデバイスがＡｃｔｉｖｉｔｙＭａｎａｇｅｒ．ＭｅｍｏｒｙＩｎｆｏを用いてＡＰＩ呼び出しを行うことによって取得できる。例えば、スクリーン解像度は、クライアントデバイスがｇｅｔＷｉｎｄｏｗＭａｎａｇｅｒ（）．ＧｅｔＤｅｆａｕｌｔＤｉｓｐｌａｙ（）を用いてＡＰＩ呼び出しを行うことによって取得できる。例えば、スクリーン密度は、クライアントデバイスがＤｉｓｐｌａｙＭｅｔｒｉｃｓと「Ｄｅｎｓｉｔｙ」のプロパティとを用いてＡＰＩ呼び出しを行うことによって取得できる。サーバは、クライアントによって報告されたハードウェア情報を受信した後、受信したハードウェア情報のパラメータ、および、ハードウェア情報のパラメータと所定のハードウェア性能重みとの所定の対応付けに少なくとも部分的に基づいて、クライアントデバイスに対応するハードウェア性能重みを決定できる。例えば、ハードウェア性能重みｈ＝（ＣＰＵ周波数）＊（使用可能メモリのサイズ）である。ハードウェア性能重みが高いほど、クライアントデバイスのハードウェア性能が高く、クライアントデバイスに送信されるマルチメディアデータの品質レーティングが高いことが好ましいことを示唆する。逆に、ハードウェア性能重みが低いほど、クライアントデバイスのハードウェア性能が低く、クライアントデバイスに送信されるマルチメディアデータの品質レーティングが低いことが好ましいことを示唆する。

さらに、クライアントデバイスが現在位置するネットワークの性能重みが比較的低い場合、または、クライアントデバイスによって現在利用されているネットワークアクセスモードに対応する情報伝送速度が比較的遅い場合、サーバは、より低い品質のマルチメディアデータをクライアントデバイスに送り返すことが好ましい。

工程５１０では、クライアントデバイスに送信される量の要求情報に含められるマルチメディアデータの品質レーティングが、ハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報に少なくとも部分的に基づいて決定される。

いくつかの実施形態において、クライアントデバイスに送信される量の要求情報は、少なくとも１つのマルチメディアデータを含むと決定される。その量の要求情報が少なくとも１つのマルチメディアデータを含む場合、サーバは、さらに、クライアントデバイスに送信される量の要求情報に含められるマルチメディアデータの特定の品質レーティングを決定するよう構成されている。例えば、マルチメディアデータに関する品質レーティングは、データがクライアントデバイスでレンダリング／表示／再生されうるサイズおよび品質に関連する。高い品質レーティングに関連するバージョンのマルチメディアデータは、低い品質レーティングに関連するバージョンの同じマルチメディアデータよりも、クライアントデバイスで高品質にレンダリングされうる。しかしながら、高い品質レーティングに関連するバージョンのマルチメディアデータは、低い品質レーティングに関連するバージョンの同じマルチメディアデータよりも大きいファイルサイズを有する。品質レーティングのタイプは、マルチメディアデータのタイプに依存しうる。例えば、グラフィック／画像について、品質レーティングは解像度に関連してよく、オーディオについて、品質レーティングはビットレートに関連してよく、ビデオについて、品質レーティングはシャープネスまたはビットレートに関連してよい。

サーバは、クライアントデバイスによって報告された受信済みのハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報に少なくとも部分的に基づいて、クライアントデバイスに送信される要求情報に含められる少なくとも１つのマルチメディアデータに関する品質レーティングを決定できる。次いで、サーバは、決定した品質レーティングに対応するバージョンのマルチメディアデータを含む、決定した量の要求情報を、クライアントデバイスに送り返す。

いくつかの実施形態において、クライアントデバイスによって報告されたハードウェア情報に基づいてサーバによって決定されたハードウェア性能重みが高いほど、クライアントデバイスに送信される要求情報に含められるマルチメディアデータの品質レーティングが高くなる。逆に、決定されたハードウェア性能重みが低いほど、クライアントデバイスに送信される要求情報に含められるマルチメディアデータの品質レーティングが低くなる。

いくつかの実施形態において、クライアントデバイスによって報告されたネットワーク性能重みが高いほど、サーバから送り返される要求情報に含められるマルチメディアデータの品質レーティングが高くなる。

いくつかの実施形態において、クライアントによって報告されたネットワークアクセスモード情報に対応する伝送速度が大きいほど、クライアントデバイスに送信される要求情報に含められるマルチメディアデータの品質レーティングが高くなる。

いくつかの実施形態において、ハードウェア性能重み（ｈ）、ネットワーク性能重み（ｆ）、および、ネットワークアクセスモード情報（ｓ）に、品質レーティング（Ｐ）を関連付ける関数関係（例えば、Ｐ＝Ｇ（ｈ，ｆ，ｓ））が、サーバで予め設定されてよい。Ｇ（ｈ，ｆ，ｓ）は、ｈ、ｆ、および、ｓに関連するので、増加関数になるよう選択されてよい。Ｇ（ｈ，ｆ，ｓ）は、連続関数または離散関数になるよう選択されうる。いくつかの実施形態において、関数Ｇ（ｈ，ｆ，ｓ）は、Ｐの様々な所定値の１つを生じうる。Ｐ＝Ｇ（ｈ，ｆ，ｓ）＝２０＊ｈ＊ｆ＊ｓ。

いくつかの実施形態において、クライアントデバイスに送信する要求情報に含められるマルチメディアデータの品質レーティングが決定された後、決定された品質レーティングに関連するバージョンのマルチメディアデータが取得される。以下は、決定された品質レーティングに関連するバージョンのマルチメディアデータを取得できる技術の２つの例である。

Ａ）第１の技術：処理５００の実行前に、サーバは、各マルチメディアデータのいくつかのバージョンを生成および格納でき、各バージョンは、異なる所定の品質レーティングに対応する。マルチメディアデータの品質レーティングが、工程５１０を用いて決定された後、サーバは、マルチメディアデータに対して決定された品質レーティングに対応するバージョンのマルチメディアデータを、格納済みの様々なバージョンのマルチメディアデータの中からルックアップできる。例えば、処理５００の実行前に、サーバは、特定のグラフ（グラフィックＡ）の４つの異なる解像度に対応する４つのバージョンを予め生成できる。例えば、グラフィックＡの４つのバージョンは、以下の４つの解像度に対応してよい。１２８ピクセル・パー・インチ（ｐｐｉ）、２５６ｐｐｉ、５１２ｐｐｉ、および、１０２４ｐｐｉ。４つのバージョンのグラフィックＡは、それぞれ、“Ａ＿１２８”、“Ａ＿２５６”、“Ａ＿５１２”、および、“Ａ＿１０２４”とラベルを付されて、格納されてよい。例えば、各バージョンのグラフィックＡは、最高解像度に関連する元バージョンのグラフィックＡから生成できる。例えば、要求情報に含められるグラフィックＡの品質レーティングが（ユーザが報告したハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報に従ってサーバによって決定されたように）１２８ｐｐｉであると仮定すると、サーバは、”Ａ＿１２８”のラベルの付いたグラフィックをルックアップし、クライアントデバイスに送信される要求情報の中に含めることができる。別の例において、クライアントデバイスに送信する要求情報に含められるグラフィックＡに対して決定された品質レーティングが、予め生成されたどのバージョンのマルチメディアデータの品質レーティングにも一致しない解像度であると仮定する。完全一致しないこの場合には、決定された品質レーティングに最も近い品質レーティングを有する格納済みのバージョンのマルチメディアデータが選択される。このように、第１の技術は、予め生成された様々なバージョンから１つの適切な予め生成されたバージョンのマルチメディアデータを単に選択するだけで、決定された品質レーティングに対応する適切なバージョンのマルチメディアデータを効率的に取得することを可能にする。

Ｂ）第２の技術：処理５００の実行前に、サーバは、元バージョンの各マルチメディアデータを格納できる。例えば、各元バージョンのマルチメディアデータは、高品質レーティングに対応するバージョンのマルチメディアデータを含む。マルチメディアデータの品質レーティングが工程５１０を用いて決定された後、サーバは、決定された品質レーティングに対応するバージョンのマルチメディアデータを動的に生成できる。例えば、サーバは、（決定された品質レーティングが、元バージョンのマルチメディアデータの品質レーティングよりも低いと仮定して）、決定された品質レーティングに対応するバージョンのマルチメディアデータを、元バージョンのマルチメディアデータから生成できる。このように、第２の技術では、決定された品質レーティングに対応する適切なバージョンのマルチメディアデータを必要に応じて動的に生成できるので、各マルチメディアデータの複数のバージョンを格納するために用いる記憶空間を必要としない。

決定された品質レーティングに対応する適切なバージョンマルチメディアデータを取得するための上述の２つの技術は、実際の応用シナリオに従って実行されてよい。いくつかの実施形態において、２つの技術は、併用されてもよい。例えば、特定のマルチメディアデータが比較的頻繁に取得される場合（例えば、設定された時間長内の取得回数が指定の閾値を超える場合）、それらのマルチメディアデータの各々の異なるバージョンが予め保存されてよい（すなわち、上述の第１の技術を用いる）。特定のマルチメディアデータがそれほど頻繁に取得されない場合（例えば、設定された時間長内の取得回数が指定の閾値を超えない場合）、元バージョンのマルチメディアデータだけが保存される（すなわち、上述の第２の技術を用いる）。

工程５１２では、品質レーティングに対応するバージョンのマルチメディアデータを含む上記量の要求情報が、クライアントデバイスに送信される。

以前の例に戻ると、決定された量の要求情報は、掲示板の特定のページに関連する１００個のメッセージの内のメッセージ１〜１５を含む。少なくともメッセージ３が、画像（画像ＡＢＣ）を含むと決定される。工程５０６〜５１０を適用すると、画像ＡＢＣの解像度１２８ｐｐｉが決定される。したがって、画像ＡＢＣを含むメッセージ１〜１５の中の１メッセージについては、１２８ｐｐｉバージョンの画像ＡＢＣが、サーバからクライアントデバイスに送信される。

図３の処理３００、図４の処理４００、および、図５の処理５００は、サービスを実装するサーバが、クライアントデバイスに送信される要求情報の適切な量を決定するため、および／または、クライアントデバイスに送信される決定量の要求情報に含められるマルチメディアデータの適切な品質レーティングを決定するためのロジックを格納する実施形態を記載している。したがって、かかる量および／または品質レーティングの決定に関連するロジックが変わる場合、そのような変更は、サーバに集中して行われるだけでよい。

いくつかの実施形態において、クライアントデバイスは、クライアントデバイスに送信される要求情報の適切な量を決定するため、および／または、クライアントデバイスに送信される決定量の要求情報に含められるマルチメディアデータの適切な品質レーティングを決定するためのロジックの少なくとも一部を格納できる。処理６００は、かかる決定の少なくとも一部をクライアントデバイスが行う処理の一例を記載する。

図６は、クライアントデバイスによって情報を要求するための処理の一実施形態を示すフローチャートである。いくつかの実施形態において、処理６００は、図２のシステム２００で実行される。具体的には、いくつかの実施形態において、処理６００は、図２のシステム２００のクライアントデバイス２０２で実行される。

処理６００は、クライアントデバイスが、各ユーザ識別子に対応する履歴情報受信時刻および履歴受信情報量を含む履歴記録を格納する一実施形態を記載する。また、処理６００は、クライアントデバイスがユーザ識別子に対応する読む速度を決定する一実施形態を記載する。いくつかの実施形態において、処理６００は、サービスを実装するサーバでの計算負荷を低減することが望ましい時に実行されうる。

工程６０２では、情報取得コマンドがクライアントデバイスで受信される。例えば、情報取得コマンドは、ソフトウェアアプリケーションでのユーザ選択（例えば、「さらにロード」ボタンまたは「次のページ」ボタンのユーザ選択）に応答して生成される。いくつかの実施形態において、情報取得コマンドは、どの情報が要求されているのかを特定するデータに関連付けられる。

工程６０４では、現在ログイン中のユーザに関連付けられたユーザ識別子が決定される。クライアントデバイスは、サービスに関連する実行中のアプリケーションに現在ログインしているユーザのユーザ識別子を決定できる。

工程６０６では、ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量が、クライアントデバイスに格納されている履歴記録から決定される。

図３の処理３００は、サービスを実装するサーバが、履歴情報送信時刻および履歴受信情報量に関する履歴記録を格納することを記載している。処理６００では、クライアントデバイスが、同様の記録を保持できる。処理６００において、クライアントデバイスは、要求情報がクライアントデバイスで受信されるたびに、クライアントデバイスでアプリケーションにログインしているユーザに対応するユーザ識別子の履歴データを格納できる。格納されているデータは、要求情報がサーバから受信された時刻（すなわち、情報受信時刻）と、その情報受信時刻に受信された情報の伝送量（すなわち、受信情報量）と、を含む。

工程６０８では、ユーザ識別子に対応する読む速度が、１または複数の履歴情報受信時刻ならびに１または複数の格納されている履歴受信情報量に少なくとも部分的に基づいて、クライアントデバイスによって決定される。

ルックアップされた履歴情報送信時刻および履歴送信情報量は、ユーザ識別子に対応する読む速度を決定するために用いられる。いくつかの実施形態において、工程６０８は、決定がサーバではなくクライアントデバイスで実行され、工程３０８の「履歴情報送信時刻」の代わりに「履歴情報受信時刻」を利用でき、工程３０８の「履歴送信情報量」の代わりに「履歴受信情報量」を利用できることを除いて、図３の処理３００の工程３０８と同様の方法で実行できる。

工程６１０では、サーバから取得される要求情報の量が、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて決定される。

クライアントデバイスは、どれだけの量の所望の情報をサーバから要求するのかを決定できる。いくつかの実施形態において、サーバから取得される要求情報の量は、ユーザ識別子に対応する読む速度を用いて決定される。かかる実施形態において、工程６１０は、図３の処理３００の工程３１０と同様の方法で実行されてよく、決定はクライアントデバイスで実行される。

いくつかの実施形態において、サーバから取得される要求情報の量は、ユーザ識別子に対応する読む速度に加えて、ネットワーク性能重みおよびネットワークアクセスモード情報を用いて決定される。例えば、ネットワーク性能重みおよびネットワークアクセスモード情報は、クライアントデバイスで決定されうる。かかる実施形態において、工程６１０は、決定がサーバではなくクライアントデバイスで実行されることを除いて、図４の処理４００の工程４０８と同様の方法で実行できる。

工程６１２では、要求情報の量を含む情報取得要求が、サーバに送信される。サーバは、その要求から要求情報の量を決定し、かかる情報をクライアントデバイスに送信できる。

いくつかの実施形態において、情報取得要求は、さらに、どのタイプのデータがサーバから要求されるのかを特定するデータを含む。いくつかの実施形態において、クライアントデバイスは、情報取得要求を送信する前に、その量の要求情報に含まれうるマルチメディアデータに対応する品質レーティングをさらに決定する。いくつかの実施形態において、その量の要求情報に含まれうるマルチメディアデータに対応する品質レーティングは、クライアントデバイスに関連するハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報を用いて決定される。かかる実施形態において、品質レーティングは、決定がサーバではなくクライアントデバイスで実行されることを除いて、図５の処理５００の工程５１０と同様の方法で決定できる。次いで、マルチメディアデータに対応する決定済みの品質レーティングも、決定された量に加えて情報取得要求に含められる。

サーバは、要求情報の量（および、いくつかの実施形態においては、マルチメディアデータに対応する決定済みの品質レーティング）を要求から決定した後、その量の要求情報をクライアントデバイスに送信できる（いくつかの実施形態においては、要求情報は、品質レーティングに対応する少なくとも１つのマルチメディアデータを含む）。

図７は、サービスを実装するサーバの一実施形態を示す図である。この例において、システム７００は、送信モジュール７０４、速度決定モジュール７０３、ルックアップモジュール７０２、および、受信モジュール７０１を備える。

モジュールは、１または複数のプロセッサ上で実行されるソフトウェアコンポーネントとして、設計されたプログラム可能論理デバイスおよび／または特定用途向け集積回路などのハードウェアとして実装されてよく、要素は、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワーク装置など）に本発明の実施形態に記載された方法を実行させるための複数の命令など、不揮発性記憶媒体（光学ディスク、フラッシュ記憶装置、携帯用ハードディスクなど）に格納することができるソフトウェア製品の形態で具現化されてよい。モジュールは、単一のデバイス上に実装されてもよいし、複数のデバイスにわたって分散されてもよい。

受信モジュール７０１は、ユーザ識別子を含む情報取得要求をクライアントデバイスから受信するよう構成されている。いくつかの実施形態において、受信モジュール７１０は、さらに、クライアントデバイスによって報告されるネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を受信するよう構成されている。いくつかの実施形態において、受信モジュール７０１は、クライアントデバイスからハードウェア情報を受信するよう構成されている。

ルックアップモジュール７０２は、情報取得要求に含まれるユーザ識別子を決定するよう構成されている。ルックアップモジュール７０２は、さらに、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を、格納されている履歴記録から決定するよう構成されている。いくつかの実施形態において、ルックアップモジュール７０２は、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報送信時刻および対応する履歴送信情報量をルックアップするよう構成されている。

速度決定モジュール７０３は、ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量に少なくとも部分的に基づいて、ユーザ識別子に対応する読む速度を決定するよう構成されている。例えば、読む速度は、すべての送信情報量の合計と、最も古い情報送信時刻および最も新しい情報送信時刻の間の時間間隔との比として決定できる。いくつかの実施形態において、読む速度は、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報送信時刻および対応する履歴送信情報量に少なくとも部分的に基づいて決定される。例えば、読む速度は、最新の事前設定された指定時間内の送信情報量の合計と、指定時間長との比として決定できる。

送信モジュール７０４は、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて、クライアントデバイスに送信される要求情報の量を決定するよう構成されている。いくつかの実施形態において、読む速度が速いほど、多くの量の要求情報がクライアントデバイスに送信されるように決定される。いくつかの実施形態において、送信モジュール７０４は、受信されたネットワークアクセスモード情報を用いて、対応する情報伝送速度を決定するよう構成されている。次いで、送信モジュール７０４は、読む速度に加えて、受信されたネットワーク性能重みおよび対応する情報伝送速度を用いて、クライアントデバイスに送信される要求情報の量を決定するよう構成されている。例えば、ネットワーク性能重みが大きいほど、要求情報の決定された量は大きくなり、情報伝送速度が速いほど、要求情報の決定された量は大きくなる。いくつかの実施形態において、送信モジュール７０４は、クライアントデバイスによって報告されたハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報に少なくとも部分的に基づいて、クライアントデバイスに送り返される決定された量の要求情報に含められるマルチメディアデータの量を決定するよう構成されている。いくつかの実施形態において、送信モジュール７０４は、受信されたハードウェア情報を用いて、対応するハードウェア性能重みを決定するよう構成されている。例えば、ハードウェア性能重みが高いほど、マルチメディアデータの品質レーティングが良くなる。

図８は、サーバに関連するアプリケーションを実行するクライアントデバイスの一実施形態を示す図である。例において、システム８００は、要求モジュール８０１、速度決定モジュール８０２、ルックアップモジュール８０３、受信モジュール８０４、および、状態決定モジュール８０５を備える。

受信モジュール８０４は、情報取得コマンドを受信するよう構成されている。例えば、受信モジュール８０４は、サーバに関連するアプリケーションでのユーザ選択に応答して、情報取得コマンドを受信する。

ルックアップモジュール８０３は、現在ログイン中のユーザに関連付けられたユーザ識別子を決定するよう構成されている。ルックアップモジュール８０３は、さらに、ユーザ識別子に対応する１または複数の履歴情報受信時刻および１または複数の履歴受信情報量を、クライアントデバイスに格納されている履歴記録から決定するよう構成されている。いくつかの実施形態において、ルックアップモジュール８０３は、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報受信時刻および対応する履歴送信情報量をルックアップするよう構成されている。

速度決定モジュール８０２は、ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量に少なくとも部分的に基づいて、ユーザ識別子に対応する読む速度を決定するよう構成されている。例えば、読む速度は、すべての受信情報量の合計と、最も古い情報受信時刻および最も新しい情報受信時刻の間の時間間隔との比として決定できる。いくつかの実施形態において、読む速度は、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報受信時刻および対応する履歴受信情報量に少なくとも部分的に基づいて決定される。例えば、読む速度は、最新の事前設定された指定時間内の受信情報量の合計と、指定時間長との比として決定できる。

要求モジュール８０１は、ユーザ識別子に対応する読む速度に少なくとも部分的に基づいて、サーバから取得される要求情報の量を決定するよう構成されている。いくつかの実施形態において、読む速度が速いほど、多くの量の要求情報がサーバから取得されるように決定される。要求モジュール８０１は、決定された要求情報量を含む情報取得要求をサーバに送信するよう構成されている。いくつかの実施形態において、要求モジュール８０１は、状態決定モジュール８０５によって決定されたネットワークアクセスモード情報を用いて、対応する情報伝送速度を決定するよう構成されている。次いで、要求モジュール８０１は、読む速度に加えて、状態決定モジュール８０５によって決定されたネットワーク性能重みと、対応する情報伝送速度とを用いて、サーバから取得される要求情報の量を決定するよう構成されている。例えば、ネットワーク性能重みが大きいほど、要求情報の決定された量は大きくなり、情報伝送速度が速いほど、要求情報の決定された量は大きくなる。いくつかの実施形態において、要求モジュール８０１は、状態決定モジュール８０５によって決定されたハードウェア情報、ネットワーク性能重み、および、ネットワークアクセスモード情報に少なくとも部分的に基づいて、サーバから取得される決定された量の要求情報に含められるマルチメディアデータの量を決定するよう構成されている。

状態決定モジュール８０５は、要求モジュール８０１が、サーバから取得される要求情報の量を決定する前に、クライアントデバイスのネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を決定するよう構成されている。いくつかの実施形態において、状態決定モジュール８０５は、さらに、クライアントデバイスのハードウェア情報を決定するよう構成されている。

上述の技術により、サーバは、各ユーザの読む速度に従って、適切な量の情報を送り返すことができる。デバイスユーザの個別のニーズに基づいて、クライアントデバイスに送信する情報の量を調整した結果として、サーバが受信および処理する情報取得要求が少なくなる可能性があり、これにより、サービスを実装するサーバへの負荷を削減できる。

図９は、読む速度に基づいて情報を送信するためのサービスを実装するようにプログラムされたコンピュータシステムの一実施形態を示す機能図である。明らかに、読む速度に基づいて情報を送信するために、他のコンピュータシステムアーキテクチャおよび構成を用いることも可能である。以下に述べるような様々なサブシステムを備えるコンピュータシステム９００は、少なくとも１つのマイクロプロセッササブシステム（プロセッサまたは中央処理装置（ＣＰＵ）とも呼ばれる）９０２を備える。例えば、プロセッサ９０２は、シングルチッププロセッサまたはマルチプロセッサによって実装できる。いくつかの実施形態において、プロセッサ９０２は、コンピュータシステム９００の動作を制御する汎用デジタルプロセッサである。メモリ９１０から読み出された命令を用いて、プロセッサ９０２は、入力データの受信および操作、ならびに、出力デバイス（例えば、ディスプレイ９１８）上でのデータの出力および表示を制御する。いくつかの実施形態において、プロセッサ９０２は、読む速度に基づいた情報の送信を含む、および／または、提供するために用いられる。

プロセッサ９０２は、メモリ９１０と双方向的に接続されており、メモリ１１０は、第１のプライマリストレージ領域（通例は、ランダムアクセスメモリ（ＲＡＭ））および第２のプライマリストレージ領域（通例は、リードオンリーメモリ（ＲＯＭ））を含みうる。当業者に周知のように、プライマリストレージは、一般的な記憶領域として、および、スクラッチパッドメモリとして利用可能であり、また、入力データおよび処理済みデータを格納するために利用可能である。プライマリストレージは、さらに、プロセッサ９０２上で実行される処理のための他のデータおよび命令に加えて、データオブジェクトおよびテキストオブジェクトの形態で、プログラミング命令およびデータを格納できる。また、当業者に周知のように、プライマリストレージは、通例、機能（例えば、プログラムされた命令）を実行するためにプロセッサ１０２によって用いられる基本的な動作命令、プログラムコード、データ、および、オブジェクトを備える。例えば、メモリ９１０は、例えば、データアクセスが双方向である必要があるか、単方向である必要があるかに応じて、後述する任意の適切なコンピュータ読み取り可能な記憶媒体を含みうる。例えば、プロセッサ９０２は、頻繁に必要になるデータをキャッシュメモリ（図示せず）に直接的かつ非常に迅速に格納し取り出すことができる。

着脱可能マスストレージデバイス９１２が、コンピュータシステム９００にさらなるデータ記憶容量を提供しており、プロセッサ９０２に対して双方向（読み出し／書き込み）または単方向（読み出しのみ）に接続されている。例えば、ストレージ９１２は、磁気テープ、フラッシュメモリ、ＰＣカード、携帯型マスストレージデバイス、ホログラフィックストレージデバイス、および、その他のストレージデバイスなどのコンピュータ読み取り可能な媒体も含みうる。固定マスストレージ９２０も、例えば、さらなるデータ記憶容量を提供しうる。固定マスストレージ９２０の最も一般的な例は、ハードディスクドライブである。マスストレージ９１２、９２０は、一般に、プロセッサ９０２によって通例はあまり利用されないさらなるプログラミング命令、データなどを格納する。マスストレージ９１２および９２０に保持された情報は、必要であれば、仮想メモリとしてのメモリ９１０（例えば、ＲＡＭ）の一部に標準的な方式で組み込まれてよいことが理解される。

プロセッサ９０２がストレージサブシステムにアクセスできるようにすることに加えて、バス９１４は、その他のサブシステムおよびデバイスへのアクセスを可能にするために用いられてもよい。図に示すように、これらは、ディスプレイ９１８、ネットワークインターフェース９１６、キーボード９０４、および、ポインティングデバイス９０６、ならびに、必要に応じて、補助入力／出力デバイスインターフェース、サウンドカード、スピーカ、および、その他のサブシステムを含みうる。例えば、ポインティングデバイス９０６は、マウス、スタイラス、トラックボール、または、タブレットであってよく、グラフィカルユーザインターフェースと相互作用するのに有用である。

ネットワークインターフェース９１６は、図に示すように、ネットワーク接続を用いて、別のコンピュータ、コンピュータネットワーク、または、遠隔通信ネットワークにプロセッサ９０２を接続することを可能にする。例えば、ネットワークインターフェース９１６を通して、プロセッサ９０２は、方法／処理ステップを実行する過程で、別のネットワークから情報（例えば、データオブジェクトまたはプログラム命令）を受信したり、別のネットワークに情報を出力したりすることができる。情報は、しばしば、プロセッサ上で実行される一連の命令として表され、別のネットワークから受信されたり、別のネットワークへ出力されたりしうる。インターフェースカード（または同様のデバイス）と、プロセッサ９０２によって実装（例えば、実行／実施）される適切なソフトウェアとを用いて、コンピュータシステム９００を外部ネットワークに接続し、標準プロトコルに従ってデータを転送することができる。例えば、本明細書に開示された様々な処理の実施形態は、プロセッサ９０２上で実行されてもよいし、処理の一部を共有するリモートプロセッサと共に、ネットワーク（インターネット、イントラネットワーク、または、ローカルエリアネットワークなど）上で実行されてもよい。さらなるマスストレージデバイス（図示せず）が、ネットワークインターフェース９１６を通してプロセッサ１０２に接続されてもよい。

補助Ｉ／Ｏデバイスインターフェース（図示せず）が、コンピュータシステム９００と共に用いられてよい。補助Ｉ／Ｏデバイスインターフェースは、プロセッサ９０２がデータを送信すること、ならびに、より典型的には、他のデバイス（マイクロホン、タッチセンサ方式ディスプレイ、トランスデューサカードリーダ、テープリーダ、音声または手書き認識装置、バイオメトリクスリーダ、カメラ、携帯型マスストレージデバイス、および、他のコンピュータなど）からデータを受信することを可能にする汎用インターフェースおよびカスタマイズされたインターフェースを含みうる。

さらに、本明細書に開示された様々な実施形態は、さらに、様々なコンピュータ実装された動作を実行するためのプログラムコードを備えた持続性のコンピュータ読み取り可能な媒体を含むコンピュータストレージ製品に関する。コンピュータ読み取り可能な媒体は、データを格納できる任意のデータストレージデバイスであり、そのデータは、後にコンピュータシステムによって読み出されうる。持続性のコンピュータ読み取り可能な媒体の例は、上記の媒体すべてを含むがそれらに限定されない。ハードディスク、フロッピーディスク（登録商標）、および、磁気テープなどの磁気媒体、ＣＤ−ＲＯＭディスクなどの光学媒体、光学ディスクなどの磁気光学媒体、ならびに、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、および、ＲＯＭ／ＲＡＭデバイスなど、特別に構成されたハードウェアデバイス。プログラムコードの例としては、例えば、コンパイラによって生成されるマシンコード、または、インタープリタを用いて実行できる高水準コード（例えば、スクリプト）を含むファイルが挙げられる。

図９に示したコンピュータシステムは、本明細書に開示された様々な実施形態と共に利用するのに適切なコンピュータシステムの一例にすぎない。かかる利用に適した他のコンピュータシステムは、より多いまたは少ないサブシステムを含みうる。さらに、バス９１４は、サブシステムをつなぐよう機能する任意の相互接続スキームの例である。異なる構成のサブシステムを有する他のコンピュータアーキテクチャが利用されてもよい。

当業者は、本願の実施形態が、方法、システム、または、コンピュータソフトウェア製品として提供されうることを理解されたい。したがって、本願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、もしくは、ソフトウェアおよびハードウェアを組み合わせた実施形態を取りうる。さらに、本願は、コンピュータ動作可能なプログラムコードを含む１または複数のコンピュータ動作可能な記憶媒体（磁気ディスク記憶デバイス、ＣＤ−ＲＯＭ、および、光学記憶デバイスを含むがこれらに限定されない）上に実装されたコンピュータプログラム製品の形態を取りうる。

本願は、方法、装置（システム）、および、コンピュータプログラム製品に基づいたフローチャートおよび／またはブロック図を参照して記載されている。フローチャートおよび／またはブロック図内の各フローチャートおよび／またはブロック図、ならびに、フローチャートおよび／またはブロック図内のフローチャートおよび／またはブロック図の組み合わせは、コンピュータ命令によって実現されうることに注意されたい。これらのコンピュータ命令は、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または、その他のプログラム可能なデータ処理装置のプロセッサに供給されてよく、その結果、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサによって命令が実行されることで、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現するために用いられるデバイスが生成される。

これらのコンピュータプログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置を導くことができる専用のコンピュータ読み取り可能な記憶デバイス上に格納されてもよく、その結果、これらのコンピュータ読み取り可能なデバイス上に命令が格納されることで、命令デバイスを備える製品が生成される。これらの命令デバイスは、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現する。

これらのコンピュータプログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置上にロードされてもよく、その結果、一連の動作工程が、コンピュータまたはその他のプログラム可能な装置上で実行され、コンピュータ処理が行われる。このように、コンピュータまたはその他のプログラム可能な装置上で実行された命令は、フローチャートの１または複数の処理および／またはブロック図の１または複数のブロックに記載された機能を実現するための工程を提供する。

上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。

サービスを実装するサーバの一実施形態を示す図。

図３の処理３００は、サービスを実装するサーバが、履歴情報送信時刻および履歴送信情報量に関する履歴記録を格納することを記載している。処理６００では、クライアントデバイスが、同様の記録を保持できる。処理６００において、クライアントデバイスは、要求情報がクライアントデバイスで受信されるたびに、クライアントデバイスでアプリケーションにログインしているユーザに対応するユーザ識別子の履歴データを格納できる。格納されているデータは、要求情報がサーバから受信された時刻（すなわち、情報受信時刻）と、その情報受信時刻に受信された情報の伝送量（すなわち、受信情報量）と、を含む。

ルックアップモジュール８０３は、現在ログイン中のユーザに関連付けられたユーザ識別子を決定するよう構成されている。ルックアップモジュール８０３は、さらに、ユーザ識別子に対応する１または複数の履歴情報受信時刻および１または複数の履歴受信情報量を、クライアントデバイスに格納されている履歴記録から決定するよう構成されている。いくつかの実施形態において、ルックアップモジュール８０３は、最新の事前設定された指定時間長内のユーザ識別子に対応する履歴情報受信時刻および対応する履歴受信情報量をルックアップするよう構成されている。

プロセッサ９０２は、メモリ９１０と双方向的に接続されており、メモリ１１０は、第１のプライマリストレージ領域（通例は、ランダムアクセスメモリ（ＲＡＭ））および第２のプライマリストレージ領域（通例は、リードオンリーメモリ（ＲＯＭ））を含みうる。当業者に周知のように、プライマリストレージは、一般的な記憶領域として、および、スクラッチパッドメモリとして利用可能であり、また、入力データおよび処理済みデータを格納するために利用可能である。プライマリストレージは、さらに、プロセッサ９０２上で実行される処理のための他のデータおよび命令に加えて、データオブジェクトおよびテキストオブジェクトの形態で、プログラミング命令およびデータを格納できる。また、当業者に周知のように、プライマリストレージは、通例、機能（例えば、プログラムされた命令）を実行するためにプロセッサ９０２によって用いられる基本的な動作命令、プログラムコード、データ、および、オブジェクトを備える。例えば、メモリ９１０は、例えば、データアクセスが双方向である必要があるか、単方向である必要があるかに応じて、後述する任意の適切なコンピュータ読み取り可能な記憶媒体を含みうる。例えば、プロセッサ９０２は、頻繁に必要になるデータをキャッシュメモリ（図示せず）に直接的かつ非常に迅速に格納し取り出すことができる。

ネットワークインターフェース９１６は、図に示すように、ネットワーク接続を用いて、別のコンピュータ、コンピュータネットワーク、または、遠隔通信ネットワークにプロセッサ９０２を接続することを可能にする。例えば、ネットワークインターフェース９１６を通して、プロセッサ９０２は、方法／処理ステップを実行する過程で、別のネットワークから情報（例えば、データオブジェクトまたはプログラム命令）を受信したり、別のネットワークに情報を出力したりすることができる。情報は、しばしば、プロセッサ上で実行される一連の命令として表され、別のネットワークから受信されたり、別のネットワークへ出力されたりしうる。インターフェースカード（または同様のデバイス）と、プロセッサ９０２によって実装（例えば、実行／実施）される適切なソフトウェアとを用いて、コンピュータシステム９００を外部ネットワークに接続し、標準プロトコルに従ってデータを転送することができる。例えば、本明細書に開示された様々な処理の実施形態は、プロセッサ９０２上で実行されてもよいし、処理の一部を共有するリモートプロセッサと共に、ネットワーク（インターネット、イントラネットワーク、または、ローカルエリアネットワークなど）上で実行されてもよい。さらなるマスストレージデバイス（図示せず）が、ネットワークインターフェース９１６を通してプロセッサ９０２に接続されてもよい。

上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
適用例１：サーバであって、
１または複数のプロセッサであって、
ユーザ識別子を含む情報取得要求をクライアントデバイスから受信し、
前記情報取得要求に含まれる前記ユーザ識別子を決定し、
格納されている履歴記録に基づき、前記ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を決定し、
前記ユーザ識別子に対応する前記１または複数の履歴情報送信時刻ならびに前記１または複数の履歴送信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信すべき要求情報の量を決定し、
前記量の要求情報を前記クライアントデバイスに送信するよう構成されている、１または複数のプロセッサと、
前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するように構成されている１または複数のメモリと、
を備える、サーバ。
適用例２：適用例１に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度を決定するために、前記１または複数のプロセッサは、
前記格納されている履歴記録の中で、前記ユーザ識別子に対応する最も新しい情報送信時刻をＴ１として特定し、前記ユーザ識別子に対応する最も古い情報送信時刻をＴ２として特定し、
前記格納されている履歴記録の中で、前記ユーザ識別子に対応する履歴送信情報量の合計ｍを決定し、
ｍ／（Ｔ１−Ｔ２）を、前記ユーザ識別子に対応する前記読む速度として決定するよう構成されている、サーバ。
適用例３：適用例１に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度を決定するために、前記１または複数のプロセッサは、
前記格納されている履歴記録の中で、最新の事前設定された指定時間長内の前記ユーザ識別子に対応する１または複数の履歴情報送信時刻を特定し、
前記最新の事前設定された指定時間長内の前記１または複数の履歴情報送信時刻に対応する履歴送信情報量の合計を決定し、
前記合計と前記事前設定された指定時間長との比を、前記ユーザ識別子に対応する前記読む速度として決定するよう構成されている、サーバ。
適用例４：適用例１に記載のサーバであって、要求情報の量は、前記読む速度の単調増加関数になるように決定される、サーバ。
適用例５：適用例１に記載のサーバであって、前記１または複数のプロセッサは、さらに、ネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を前記クライアントデバイスから受信するよう構成されている、サーバ。
適用例６：適用例５に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することは、前記ユーザ識別子に対応する前記読む速度、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することを含む、サーバ。
適用例７：適用例６に記載のサーバであって、前記要求情報の量は、前記ネットワーク性能重みの単調増加関数になるように決定される、サーバ。
適用例８：適用例６に記載のサーバであって、前記要求情報の量は、前記ネットワークアクセスモード情報に対応する伝送速度の単調増加関数になるように決定される、サーバ。
適用例９：適用例５に記載のサーバであって、前記１または複数のプロセッサは、さらに、前記量の要求情報が少なくとも１つのマルチメディアデータを含むことを決定するよう構成されている、サーバ。
適用例１０：適用例９に記載のサーバであって、前記１または複数のプロセッサは、さらに、ハードウェア情報を前記クライアントデバイスから受信するよう構成されている、サーバ。
適用例１１：適用例１０に記載のサーバであって、前記１または複数のプロセッサは、さらに、前記ハードウェア情報、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記少なくとも１つのマルチメディアデータに対応する品質レーティングを決定するよう構成されている、サーバ。
適用例１２：適用例１１に記載のサーバであって、前記少なくとも１つのマルチメディアデータに対応する前記品質レーティングは、前記ハードウェア情報の単調増加関数になるように決定される、サーバ。
適用例１３：適用例１１に記載のサーバであって、前記クライアントデバイスに送信する前記量の要求情報は、前記品質レーティングに対応するバージョンの前記少なくとも１つのマルチメディアデータを含む、サーバ。
適用例１４：方法であって、
ユーザ識別子を含む情報取得要求をクライアントデバイスから受信し、
前記情報取得要求に含まれる前記ユーザ識別子を決定し、
格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を決定し、
１または複数のプロセッサを用いて、前記ユーザ識別子に対応する前記１または複数の履歴情報送信時刻ならびに前記１または複数の履歴送信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される要求情報の量を決定し、
前記量の要求情報を前記クライアントデバイスに送信すること、
を備える、方法。
適用例１５：適用例１４に記載の方法であって、さらに、前記クライアントデバイスからのネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を含む、方法。
適用例１６：適用例１５に記載の方法であって、前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することは、前記ユーザ識別子に対応する前記読む速度、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することを含む、方法。
適用例１７：適用例１５に記載の方法であって、さらに、前記量の要求情報が少なくとも１つのマルチメディアデータを含むことを決定することを備える、方法。
適用例１８：適用例１７に記載の方法であって、さらに、ハードウェア情報を前記クライアントデバイスから受信することを備える、方法。
適用例１９：適用例１８に記載の方法であって、さらに、前記ハードウェア情報、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記少なくとも１つのマルチメディアデータに対応する品質レーティングを決定することを備える、方法。
適用例２０：適用例１８に記載の方法であって、前記クライアントデバイスに送信する前記量の要求情報は、前記品質レーティングに対応するバージョンの前記少なくとも１つのマルチメディアデータを含む、方法。
適用例２１：クライアントデバイスであって、
１または複数のプロセッサであって、
情報取得コマンドを受信し、
現在ログイン中のユーザに関連付けられたユーザ識別子を決定し、
格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量を決定し、
前記ユーザ識別子に対応する前記１または複数の履歴情報受信時刻ならびに前記１または複数の履歴受信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、サーバから取得される要求情報の量を決定し、
要求情報の前記量を含む情報取得要求をサーバに送信するよう構成されている、１または複数のプロセッサと、
前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成されている１または複数のメモリと、
を備える、クライアントデバイス。
適用例２２：方法であって、
情報取得コマンドを受信し、
現在ログイン中のユーザに関連付けられたユーザ識別子を決定し、
格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量を決定し、
前記ユーザ識別子に対応する前記１または複数の履歴情報受信時刻ならびに前記１または複数の履歴受信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、サーバから取得される要求情報の量を決定し、
要求情報の前記量を含む情報取得要求をサーバに送信すること、
を備える、方法。

Claims (22)

1. サーバであって、
   １または複数のプロセッサであって、
   ユーザ識別子を含む情報取得要求をクライアントデバイスから受信し、
   前記情報取得要求に含まれる前記ユーザ識別子を決定し、
   格納されている履歴記録に基づき、前記ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を決定し、
   前記ユーザ識別子に対応する前記１または複数の履歴情報送信時刻ならびに前記１または複数の履歴送信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
   前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信すべき要求情報の量を決定し、
   前記量の要求情報を前記クライアントデバイスに送信するよう構成されている、１または複数のプロセッサと、
   前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するように構成されている１または複数のメモリと、
   を備える、サーバ。
2. 請求項１に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度を決定するために、前記１または複数のプロセッサは、
   前記格納されている履歴記録の中で、前記ユーザ識別子に対応する最も新しい情報送信時刻をＴ１として特定し、前記ユーザ識別子に対応する最も古い情報送信時刻をＴ２として特定し、
   前記格納されている履歴記録の中で、前記ユーザ識別子に対応する履歴送信情報量の合計ｍを決定し、
   ｍ／（Ｔ１−Ｔ２）を、前記ユーザ識別子に対応する前記読む速度として決定するよう構成されている、サーバ。
3. 請求項１に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度を決定するために、前記１または複数のプロセッサは、
   前記格納されている履歴記録の中で、最新の事前設定された指定時間長内の前記ユーザ識別子に対応する１または複数の履歴情報送信時刻を特定し、
   前記最新の事前設定された指定時間長内の前記１または複数の履歴情報送信時刻に対応する履歴送信情報量の合計を決定し、
   前記合計と前記事前設定された指定時間長との比を、前記ユーザ識別子に対応する前記読む速度として決定するよう構成されている、サーバ。
4. 請求項１に記載のサーバであって、要求情報の量は、前記読む速度の単調増加関数になるように決定される、サーバ。
5. 請求項１に記載のサーバであって、前記１または複数のプロセッサは、さらに、ネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を前記クライアントデバイスから受信するよう構成されている、サーバ。
6. 請求項５に記載のサーバであって、前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することは、前記ユーザ識別子に対応する前記読む速度、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することを含む、サーバ。
7. 請求項６に記載のサーバであって、前記要求情報の量は、前記ネットワーク性能重みの単調増加関数になるように決定される、サーバ。
8. 請求項６に記載のサーバであって、前記要求情報の量は、前記ネットワークアクセスモード情報に対応する伝送速度の単調増加関数になるように決定される、サーバ。
9. 請求項５に記載のサーバであって、前記１または複数のプロセッサは、さらに、前記量の要求情報が少なくとも１つのマルチメディアデータを含むことを決定するよう構成されている、サーバ。
10. 請求項９に記載のサーバであって、前記１または複数のプロセッサは、さらに、ハードウェア情報を前記クライアントデバイスから受信するよう構成されている、サーバ。
11. 請求項１０に記載のサーバであって、前記１または複数のプロセッサは、さらに、前記ハードウェア情報、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記少なくとも１つのマルチメディアデータに対応する品質レーティングを決定するよう構成されている、サーバ。
12. 請求項１１に記載のサーバであって、前記少なくとも１つのマルチメディアデータに対応する前記品質レーティングは、前記ハードウェア情報の単調増加関数になるように決定される、サーバ。
13. 請求項１１に記載のサーバであって、前記クライアントデバイスに送信する前記量の要求情報は、前記品質レーティングに対応するバージョンの前記少なくとも１つのマルチメディアデータを含む、サーバ。
14. 方法であって、
    ユーザ識別子を含む情報取得要求をクライアントデバイスから受信し、
    前記情報取得要求に含まれる前記ユーザ識別子を決定し、
    格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報送信時刻ならびに１または複数の履歴送信情報量を決定し、
    １または複数のプロセッサを用いて、前記ユーザ識別子に対応する前記１または複数の履歴情報送信時刻ならびに前記１または複数の履歴送信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
    前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される要求情報の量を決定し、
    前記量の要求情報を前記クライアントデバイスに送信すること、
    を備える、方法。
15. 請求項１４に記載の方法であって、さらに、前記クライアントデバイスからのネットワーク性能重みおよびネットワークアクセスモード情報の少なくとも一方を含む、方法。
16. 請求項１５に記載の方法であって、前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することは、前記ユーザ識別子に対応する前記読む速度、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記クライアントデバイスに送信される前記要求情報の量を決定することを含む、方法。
17. 請求項１５に記載の方法であって、さらに、前記量の要求情報が少なくとも１つのマルチメディアデータを含むことを決定することを備える、方法。
18. 請求項１７に記載の方法であって、さらに、ハードウェア情報を前記クライアントデバイスから受信することを備える、方法。
19. 請求項１８に記載の方法であって、さらに、前記ハードウェア情報、前記ネットワーク性能重み、および、前記ネットワークアクセスモード情報に少なくとも部分的に基づいて、前記少なくとも１つのマルチメディアデータに対応する品質レーティングを決定することを備える、方法。
20. 請求項１８に記載の方法であって、前記クライアントデバイスに送信する前記量の要求情報は、前記品質レーティングに対応するバージョンの前記少なくとも１つのマルチメディアデータを含む、方法。
21. クライアントデバイスであって、
    １または複数のプロセッサであって、
    情報取得コマンドを受信し、
    現在ログイン中のユーザに関連付けられたユーザ識別子を決定し、
    格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量を決定し、
    前記ユーザ識別子に対応する前記１または複数の履歴情報受信時刻ならびに前記１または複数の履歴受信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
    前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、サーバから取得される要求情報の量を決定し、
    要求情報の前記量を含む情報取得要求をサーバに送信するよう構成されている、１または複数のプロセッサと、
    前記１または複数のプロセッサに接続され、前記１または複数のプロセッサに命令を提供するよう構成されている１または複数のメモリと、
    を備える、クライアントデバイス。
22. 方法であって、
    情報取得コマンドを受信し、
    現在ログイン中のユーザに関連付けられたユーザ識別子を決定し、
    格納されている履歴記録から、前記ユーザ識別子に対応する１または複数の履歴情報受信時刻ならびに１または複数の履歴受信情報量を決定し、
    前記ユーザ識別子に対応する前記１または複数の履歴情報受信時刻ならびに前記１または複数の履歴受信情報量に少なくとも部分的に基づいて、前記ユーザ識別子に対応する読む速度を決定し、
    前記ユーザ識別子に対応する前記読む速度に少なくとも部分的に基づいて、サーバから取得される要求情報の量を決定し、
    要求情報の前記量を含む情報取得要求をサーバに送信すること、
    を備える、方法。

Images