JP6574293B2 - ハイブリッドクライアントサーバデータプロビジョン - Google Patents

Description

本発明は、ハイブリッドクライアントサーバデータプロビジョンに関する。

発表者は、多数のサードパーティコンテンツプロバイダにコンテンツを要求し得る。これは、たとえば、複数の要求を送信するために多数のネットワーク接続を開く際に使用されるメモリのような、アプリケーションを実行しているクライアントデバイスにおけるコンピューティングリソースの観点から問題となり得る。これはまた、特に、ネットワークが、3Gまたは4Gネットワークのようなモバイルネットワークである場合、レイテンシの観点から問題を引き起こし得る。クライアントデバイスによって多数の要求を送出するステップと、応答を受信するステップとの間の顕著な遅延または遅れが存在し得る。

本明細書に記載された実施は、データを提供するための要求の仲介に関する。本願に記載された方法は、とりわけ、仲介SDKに、複数の要求を、クライアントデバイス上の1つのバッチ要求としてバッチ化させ、サードパーティコンテンツプロバイダのうちの少なくとも1つからコンテンツを取得するために、仲介サーバへ単一のバッチ要求のみを送信させることによって、多数のコンテンツ要求によって提示された問題を改善することを支援し得る。

1つの実施は、ハイブリッドクライアントサーバデータプロビジョンのための方法に関する。この実施では、この方法は、クライアントデバイスによる表示のためのコンテンツのアイテムを、アプリケーションと統合された複数のコンテンツプロバイダソフトウェア開発キット(SDK)に、クライアントデバイスによって実行されるアプリケーションによって要求するステップを備える。この方法はさらに、複数のコンテンツプロバイダサーバへの潜在的な提出のために、コンテンツプロバイダSDKの複数の要求アダプタによって、コンテンツのアイテムを求める要求を処理し、これによって、複数の処理された要求を生成するステップを備える。この方法はさらに、複数のコンテンツプロバイダSDKから、アプリケーションと統合された仲介SDKのインタセプタモジュールによって、複数の処理された要求を受信するステップを備える。この方法はさらに、複数の処理された要求を、仲介SDKのコンソリデータモジュールによって、バッチ要求へバッチ化するステップを備え、このバッチ要求は、コンテンツプロバイダ優先度情報を備える。この方法はさらに、コンテンツプロバイダ優先度情報に基づいて、複数のコンテンツプロバイダサーバへのバッチ要求の仲介のために、仲介SDKによって、仲介サーバへバッチ要求を送信するステップを備える。この方法はさらに、クライアントデバイスによる表示のために、仲介サーバからのコンテンツのうちの少なくとも1つのアイテムを、仲介SDKによって受信するステップを備える。

これらの実施のうちのいくつかでは、複数のコンテンツプロバイダサーバへの潜在的な提出を求める要求を処理するステップは、複数のコンテンツプロバイダサーバのうちの1つのための適切なヘッダ情報を含めるステップを備える。

これらの実施のうちのいくつかでは、コンテンツプロバイダ優先度情報は、コンテンツプロバイダサーバの優先度ランキングを備える。

これらの実施のうちのいくつかでは、コンテンツプロバイダ優先度情報は、アプリケーションによって仲介SDKへ提供される。

これらの実施のうちのいくつかでは、仲介SDKの分析エンジンは、コンテンツプロバイダ優先度情報に基づいて、クライアントデバイスによる表示のために、コンテンツのうちの少なくとも1つのアイテムから、コンテンツの単一のアイテムを選択する。

これらの実施のうちのいくつかでは、仲介サーバから受信された、表示のためのコンテンツのうちの少なくとも1つのアイテムは、仲介サーバから受信された、表示のためのコンテンツの唯一のアイテムであり、表示のためのコンテンツの少なくとも1つのアイテムは、仲介サーバが取得することが可能であったコンテンツプロバイダ優先度情報に基づいて、表示のためのコンテンツの最高優先度のアイテムである。

これらの実施のうちのいくつかでは、バッチ要求はさらに、仲介サーバからの応答のための最大許容時間に関連するタイミング情報を備える。

これらの実施のうちのいくつかでは、バッチ要求の仲介は、タイミング情報に少なくとも部分的に基づく。

これらの実施のうちのいくつかでは、インタセプタモジュールが、処理された要求をインタセプトする。

これらの実施のうちのいくつかでは、処理された要求をインタセプトするインタセプタモジュールは、仲介SDKのコールバックインターフェースを使用するコンテンツプロバイダSDKを備える。

これらの実施のうちのいくつかでは、処理された要求をインタセプトするインタセプタモジュールは、コンテンツプロバイダSDKによって、コンテンツプロバイダサーバへのコールをブロックするステップを備える。

1つの実施は、ハイブリッドクライアントサーバデータプロビジョンのための方法に関する。この実施では、方法は、仲介ソフトウェア開発キット(SDK)から、クライアントデバイスによる表示のためのコンテンツのアイテムを求めるバッチ要求を、仲介サーバによって受信するステップを備える。このバッチ要求は、クライアントデバイス上の複数のコンテンツプロバイダSDKによって処理されたコンテンツのアイテムのための複数の処理された要求に基づいて、仲介SDKのコンソリデータモジュールによって生成され、バッチ要求は、コンテンツプロバイダ優先度情報を備える。この方法はさらに、複数のコンテンツプロバイダ特有要求を生成するために、仲介サーバの脱構築エンジンによって、バッチ要求を処理するステップを備える。この方法はさらに、仲介サーバによって、複数のコンテンツプロバイダサーバへ、複数のコンテンツプロバイダ特有要求を送信するステップを備える。この方法はさらに、コンテンツプロバイダ特有要求のうちの少なくとも1つに応じて、コンテンツのうちの少なくとも1つのアイテムを、仲介サーバによって、コンテンツプロバイダサーバから受信し、仲介サーバの分析モジュールのコンテンツ記憶装置に、コンテンツのアイテムを記憶するステップを備える。この方法はさらに、送信のために、少なくとも1つの記憶されたコンテンツのアイテムを、仲介サーバの分析モジュールによって選択するステップを備える。この方法はさらに、選択されたコンテンツのアイテムを、仲介サーバによって仲介SDKへ送信するステップを備える。

これらの実施のうちのいくつかでは、選択されたコンテンツのアイテムを送信するステップは、あらかじめ決定されたタイムアウト期間後に生じる。

これらの実施のうちのいくつかでは、バッチ要求はさらに、タイミング情報を備える。

これらの実施のうちのいくつかでは、選択されたコンテンツのアイテムを送信するステップは、タイミング情報に基づいて、分析モジュールによって確立されたタイムアウト期間後に生じる。

これらの実施のうちのいくつかでは、送信のために、少なくとも1つの記憶されたコンテンツのアイテムを選択するステップは、送信のために、複数の記憶されたコンテンツのアイテムを選択するステップを含む。

これらの実施のうちのいくつかでは、送信のために、少なくとも1つの記憶されたコンテンツのアイテムを選択するステップは、コンテンツプロバイダ優先度情報に基づく。

これらの実施のうちのいくつかでは、この方法はさらに、複数の処理された要求を、仲介SDKのインタセプタモジュールによってインタセプトするステップを備える。

これら実施のうちのいくつかでは、インタセプタモジュールによるインタセプションは、コンテンツプロバイダSDKによって、仲介SDKのコールバックインターフェースを使用するステップを備える。

これらの実施のうちのいくつかでは、インタセプタモジュールによるインタセプションは、コンテンツプロバイダSDKによってコンテンツプロバイダサーバへのコールをブロックするステップを備える。

1つまたは複数の実施の詳細は、添付図面および以下の説明において記述される。本開示の他の特徴、態様、および利点が、詳細説明、図面、および特許請求の範囲から明らかになるだろう。

ハイブリッドクライアントサーバデータプロビジョンのための方法の実施において使用され得る一般的なアーキテクチャを描写する概要図である。 ハイブリッドクライアントサーバデータプロビジョンのための方法の実施において使用される構成要素の詳細図である。 ハイブリッドクライアントサーバデータプロビジョンのための方法の実施におけるこれら構成要素間のインタラクションのいくつかの詳細図である。 ハイブリッドクライアントサーバデータプロビジョンのための方法の別の実施におけるこれら構成要素間のインタラクションのいくつかの詳細図である。 仲介サーバの分析モジュールの決定処理を描写するフローチャートである。

これら図面のうちのいくつかまたはすべては、例示の目的のための概要表示であることが認識されるであろう。これら図面は、これらが特許請求の範囲の範囲または意味を限定するために使用されないという明白な理解とともに、1つまたは複数の実施形態を例示する目的のために提供される。

以下は、ハイブリッドクライアントサーバコンテンツプロビジョンの方法に関連するおよびその実施の様々な概念のより詳細な記載である。記載された概念は実施の何れかの特定の方式に限定されないので、上で紹介され、より詳細に以下に議論される様々な概念が、多くの方式のうちの何れかにおいて実施され得る。特定の実施およびアプリケーションの例は、主に例示目的のために提供される。

コンピューティングデバイス(たとえば、クライアントデバイス)は、ウェブページ、ドキュメント、アプリケーション等のようなリソースを見ることができる。いくつかの実施では、コンピューティングデバイスは、ウェブページサーバのように、リソースに対応するサーバと通信することによって、インターネットを介してそのリソースへアクセスし得る。このリソースは、単一のサーバによって提供され得るか、または、多数のサーバによって提供され得る。たとえば、いくつかの実施では、リソースは、複数のサーバから利用可能であり得、コンピューティングデバイスは、これらサーバのうちの2つ以上にリソースを要求し得る。リソースは、たとえば、リソースを求める要求へ応答するために、複数のサーバのうちの第1のサーバによってコンピューティングデバイスへ提供される。それに加えて、または、その代わりに、リソースは、異なるサーバによって提供され得る異なるコンテンツを含み得る。たとえば、リソースのファーストパーティコンテンツが、第1のサーバから提供され得、追加のリソースのサードパーティコンテンツが、複数のさらなるサーバによって提供され得、それにより、あらかじめ決定された基準に基づいて、リソースのファーストパーティコンテンツが第1のサーバから提供され得、リソースのサードパーティコンテンツがさらなるサーバのうちの1つまたは複数によって提供され得る。このような多数のサーバからのコンテンツのプロビジョンによって、たとえば、サーバは、たとえばコンピューティングデバイスへのコンテンツの最速のプロビジョンのような、あらかじめ決定された基準に基づいて、コンテンツのプロビジョンのために選択されることが可能となる。

多数のサーバからのコンテンツのプロビジョンは、それに加えて、モバイルアプリケーションのようなアプリケーションによってデータを視聴または実行しているコンピューティングデバイス(たとえば、クライアントデバイス)へコンテンツを提供するために使用され得る。上に記載されたウェブページのようなリソースを視聴することと同様に、アプリケーションに関連付けられたコンテンツは、多数のサーバから利用可能であり得、コンテンツが、あらかじめ決定された基準に基づいて、サーバのうちの1つによって提供されているアプリケーションに関連付けられたコンテンツとともに多数のサーバにコンピューティングデバイスによって要求され得るか、または、ファーストパーティコンテンツが、ファーストパーティコンテンツプロバイダによって提供され得、追加のサードパーティによって提供されたコンテンツが、あらかじめ決定された基準に基づいて、サードパーティコンテンツプロバイダによって提供されているサードパーティによって提供されたコンテンツとともに、複数のサードパーティコンテンツプロバイダに要求され得る。1つの実施では、アプリケーションの使用に応じて、リソースサーバおよび/またはクライアントデバイスは、コンテンツアイテムが、アプリケーションのユーザインターフェースを用いて、および/または、その他の方式で提示されることを要求するために、コンテンツアイテム選択システムのようなデータ処理システムと通信し得る。コンテンツアイテム選択システムは、クライアントデバイスのディスプレイ上に、アプリケーションを用いてコンテンツアイテムの表示を有効にするために、サードパーティコンテンツアイテムを選択し、データを提供し得る。

いくつかの事例では、デバイス識別子が、クライアントデバイスに関連付けられ得る。デバイス識別子は、リソースおよび/またはコンテンツアイテムのための後続する要求の間に、デバイスを識別するために、クライアントデバイスに関連付けられたランダム化された数であり得る。いくつかの事例では、デバイス識別子は、クライアントデバイスに関連する情報(たとえば、センサデータの値、ウェブブラウザタイプ、オペレーティングシステム、履歴リソース要求、履歴コンテンツアイテム要求等)を、記憶するように、および/または、クライアントデバイスに、コンテンツアイテム選択システムおよび/またはリソースサーバへと送信させるように構成され得る。

本明細書で議論されたシステムがユーザに関する個人情報を収集するか、または、個人情報を活用し得る状況では、ユーザは、プログラムもしくは機能がユーザ情報(たとえば、ユーザのソーシャルネットワークに関する情報、社会貢献または活動、専門、ユーザの嗜好、またはユーザの現在の場所)を収集するか否かを制御するための機会、または、コンテンツサーバからコンテンツを受信するか否か、および/もしくは、どのようにして受信するかを制御するための機会を提供され得る。それに加えて、いくつかのデータは、記憶または使用される前に、1つまたは複数の方式で取り扱われ得、これによって、個人を識別可能な情報が削除されるようになる。たとえば、個人を識別可能な情報が、何らユーザのために判定され得ないように、ユーザの識別情報が取り扱われ得るか、または、ユーザの特定の場所が決定され得ないように、(都市、郵便番号、または州レベルへのような)場所情報が取得されたユーザの地理的場所が、一般化され得る。したがって、ユーザは、ユーザに関する情報がコンテンツサーバによってどのようにして収集され使用されるのかに関する制御を有し得る。

以前に言及されたように、コンピューティングデバイス(たとえば、クライアントデバイス)はまた、モバイルアプリケーションのようなアプリケーションを視聴または実行するために使用され得る。このアプリケーションは、ファーストパーティコンテンツプロバイダからのアプリケーションの主題であるファーストパーティコンテンツを含み得、また、追加のサードパーティ提供コンテンツをも含み得る。1つの実施では、アプリケーションの使用に応じて、リソースサーバおよび/またはクライアントデバイスは、コンテンツアイテムが、アプリケーションのユーザインターフェースを用いて、および/または、その他の方式で提示されることを要求するために、コンテンツアイテム選択システムのようなデータ処理システムと通信し得る。

この要求は、サードパーティコンテンツプロバイダの少なくとも1つまたは複数に、コンテンツアイテムの少なくとも1つまたは複数を提供させるという目標を有する、多数のサードパーティコンテンツプロバイダを求める要求であり得、そのうちの少なくとも1つまたは複数は、アプリケーションのユーザインターフェースにおいてユーザへ提示され得る。これらの要求は、サードパーティコンテンツプロバイダにおいてサービス提供される前に処理される必要があり得る。たとえば、この要求は、HTTP GET要求であり得、この要求は、サードパーティコンテンツプロバイダにおいてサービス提供され得る前に、たとえば適切なIPヘッダ、適切なクエリパラメータの設定、または他の要件を必要とし得る。そのような処理は、アプリケーションとともに統合されたSDKを使用して取り扱われ得る。SDKは、アプリケーションの開発者による使用のために、サードパーティコンテンツプロバイダによって提供され得るが、必ずしもその必要はない。

いくつかの事例では、上述されたように、アプリケーションは、たとえば、コンテンツを最も迅速に提供することができるサードパーティコンテンツプロバイダのような、あらかじめ決定された基準を満足するサードパーティコンテンツプロバイダのうちの1つからコンテンツを取得するために、多数のサードパーティコンテンツプロバイダにコンテンツを要求し得る。

たとえば、多数のサーバにコンテンツを要求するアプリケーションによって、極めて多数の要求が送出される必要があり得ることが認識されるであろう。これは、たとえば、複数の要求を送信するために多数のネットワーク接続を開く際に使用されるメモリのような、アプリケーションを実行しているクライアントデバイスにおけるコンピューティングリソースの観点から問題となり得る。それはまた、特に、ネットワークが、たとえば3Gまたは4Gネットワークのようなモバイルネットワークである場合、レイテンシの観点から問題を引き起こし得る。クライアントデバイスによって多数の要求を送出するステップと、応答を受信するステップとの間の顕著な遅延または遅れが存在し得る。本願に記載された方法は、とりわけ、仲介SDKに対して、複数の要求を、クライアントデバイス上の1つのバッチ要求としてバッチ化させ、クライアントデバイスへのコンテンツのプロビジョンを実証するために、仲介サーバへ、単一のバッチ要求のみを送信させることによって、少なくともこの問題を改善することを支援し得る。このように、コンテンツは、クライアントデバイス上のコンピューティングリソースに関連付けられた問題と、上記で議論されたレイテンシとを回避しながら、コンテンツをより効果的に受信するように、複数のコンテンツソースのうちの1つからクライアントデバイスへ提供され得る。

図1は、ハイブリッドクライアントサーバコンテンツプロビジョンのための方法の実施において使用され得るシステム100の一般的なアーキテクチャを描写する概要図である。コンピュータ、ラップトップ、デスクトップ、スマートフォン、タブレット、携帯情報端末、テレビセットのためのセットトップボックス、スマートテレビ、またはサーバデバイスのような1つまたは複数のデバイスを含み得るクライアントデバイス102は、たとえばネットワーク108を介して他のデバイスと通信するように構成される。クライアントデバイスは、以下により詳細に記載されるように、コンテンツプロバイダSDK1およびコンテンツプロバイダSDKnのみならず、仲介SDKのようなコンテンツプロバイダSDKのうちの1つまたは複数を含み得る。

実施では、システム100は、各々がローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、ワイヤレスリンク、イントラネット、インターネット、またはこれらの組合せを含み得るネットワーク108およびネットワーク110を含む。システム100はさらに、以下により詳細に記載されるように、仲介サーバ104およびコンテンツプロバイダサーバ106を含む。

図2は、ハイブリッドクライアントサーバデータプロビジョンのための方法の実施において使用され得るシステム100において使用され得る構成要素、デバイス、およびネットワークのうちのいくつかを図示する。

システム100は、クライアントデバイス102を含み得る。クライアントデバイス102は、たとえばネットワーク108を介して他のデバイスと通信するように構成された、コンピュータ、ラップトップ、デスクトップ、スマートフォン、タブレット、携帯情報端末、テレビのためのセットトップボックス、スマートテレビ、またはサーバデバイスのような1つまたは複数のデバイスを含み得る。デバイスは、データプロセッサおよびメモリを含むポータブル電子デバイスの任意の形態であり得る。メモリは、プロセッサによって実行された場合、プロセッサに対して、本明細書に記載される動作のうちの1つまたは複数を実行させるマシン命令を記憶し得る。メモリはまた、1つまたは複数のリソース、コンテンツアイテム等の、コンピューティングデバイスにおける提示を有効にするためのデータを記憶し得る。プロセッサは、マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)等、またはこれらの組合せを含み得る。メモリは、限定される訳ではないが、電子、光、磁気、または、プロセッサにプログラム命令を提供することが可能な他の任意の記憶または送信デバイスを含み得る。メモリは、プロセッサが命令を読み取ることができるフロッピーディスク、コンパクトディスク読取専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)、磁気ディスク、メモリチップ、読取専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、電子的消去可能プログラマブル読取専用メモリ(EEPROM)、消去可能プログラマブル読取専用メモリ(EPROM)、フラッシュメモリ、光学媒体、または他の任意の適切なメモリを含み得る。これら命令は、限定される訳ではないが、ActionScript、C、C++、C#、HTML、Java(登録商標)、JavaScript(登録商標)、Perl、Python、Visual BasicおよびXMLのような任意の適切なコンピュータプログラミング言語からのコードを含み得る。

クライアントデバイス102は、ネットワーク108を介して他のコンピューティングデバイスからコンテンツを取得するために、ソフトウェアアプリケーション206(たとえば、ウェブブラウザまたは他のアプリケーション)を実行し得る。いくつかのケースでは、クライアントデバイス102上で実行しているアプリケーションは、たとえば、ゲーム、メディアプレーヤ等であり得る。1つの実施では、クライアントデバイス102は、クライアントデバイスのディスプレイ上にブラウザウィンドウを提供するウェブブラウザアプリケーションを実行し得る。ブラウザウィンドウを提供するウェブブラウザアプリケーションは、ウェブアドレスのようなユニフォームリソースロケータ(URL)の入力を、入力デバイス(たとえば、ポインティングデバイス、キーボード、タッチスクリーン、または、別の形式の入力デバイス)から受信することによって動作し得る。これに応じて、ウェブブラウザアプリケーションからの命令を実行しているクライアントデバイスの1つまたは複数のプロセッサ200は、URLアドレスによって参照されるネットワーク108へ接続された別のデバイス(たとえば、仲介サーバ104)にデータを要求し得る。その別のデバイスは、その後、クライアントデバイス102へウェブページデータおよび/または他のデータを提供し得る。これは、ビジュアルなしるし(visual indicia)をクライアントデバイス102のディスプレイ204によって表示させる。

アプリケーション206は、コンテンツプロバイダ106のような多数のコンテンツプロバイダからの、コンテンツのアイテムを求める要求を開始し得る。これは、コンテンツプロバイダ1,2,…,nによって提供されるコンテンツのアイテムを求める要求1,2,…,nを含み得る。この要求は、上記で議論されたように、コンテンツプロバイダ上においてサービス提供され得る前に処理する必要があり得る。実施では、この要求は、各々がアプリケーションと統合され得るコンテンツプロバイダSDK1、コンテンツプロバイダSDK2…乃至コンテンツプロバイダSDKnのような多くのコンテンツプロバイダSDKの各々へ送信される。SDKは、たとえば、ライブラリ、API、および/または、ハードウェアプラットフォームのようなソフトウェア開発ツールのセットを備え得る。コンテンツプロバイダSDK1は、コンテンツプロバイダ1においてサービス提供され得るように、コンテンツのアイテムを求める要求を少なくとも処理することができるように、コンテンツプロバイダ1に関連付けられる。同様に、コンテンツプロバイダSDKnは、コンテンツプロバイダnにおいてサービス提供され得るように、コンテンツのアイテムを求める要求を少なくとも処理することができるように、コンテンツプロバイダnに関連付けられる。この処理は、たとえば、コンテンツプロバイダSDK1のアダプタ1のような、コンテンツプロバイダSDKのアダプタによって取り扱われ得る。アダプタは、たとえば、この要求が、特定のコンテンツプロバイダへの提出のための適切なヘッダを有することを保証し得る。

実施では、上記で記載されたような処理要求の後、コンテンツプロバイダSDKは、処理された要求を、コンテンツプロバイダへ送信しない。そうではなく、上述したように要求を処理した後、処理された要求は、インタセプタモジュール222を介して仲介SDK216によってインタセプトされる。実施では、インタセプタモジュール222が、良好に定義されたコールバックインターフェースを提供し、コンテンツプロバイダSDKが、各々のコンテンツプロバイダサーバとのコンタクトを開始する代わりに、処理された要求が、たとえば、最終的なバッチ化のために、インタセプタモジュールへ渡されるように、インタセプタモジュール222が、コンテンツプロバイダSDKと統合され得る。実施では、インタセプションは、それに加えて、または、その代わりに、コンテンツプロバイダSDKからコンテンツプロバイダサーバへのHTTPコールがブロックされるように、より低いネットワークレベルにおいて実施され得る。たとえば、それらは、パケット検査フィルタリングを使用してブロックされ得る。仲介SDK216は、たとえば、ライブラリ、API、および/または、ハードウェアプラットフォームのようなソフトウェア開発ツールのセットを備え得る。実施では、仲介SDK216は、コンテンツ優先度情報記憶装置220を含むメモリ218を含む。仲介SDK216はまた、実施において、コンソリデータモジュール224を含む。仲介は、アプリケーション206と、および/または、コンテンツプロバイダSDK1乃至nの何れかまたはすべてと統合され得る。

コンテンツプロバイダ優先度情報記憶装置は、たとえば、優先度ランキング、または、異なるコンテンツプロバイダがどれくらい効果的にコンテンツを提供するのかを判定するために役立つ他の情報のような、たとえば、コンテンツプロバイダ優先度情報を記憶し得る。たとえば、データは、各コンテンツプロバイダのための平均接続速度またはレイテンシ、または、各コンテンツプロバイダから提供されたコンテンツの圧縮比のような提供されたコンテンツの品質を示すデータを示し得る。

実施では、インタセプタモジュール222は、上述されたように、コンテンツプロバイダSDKが、上記の処理された要求を、インタセプタモジュール222へ送信するように、たとえば、アプリケーションにおけるのみならず、個々のコンテンツプロバイダSDK1乃至nにおけるコードを介して統合され得る。実施では、コンソリデータモジュール224がその後、任意のおよびすべての処理された要求を処理し、単一のバッチ要求を生成する。バッチ要求は、コンテンツプロバイダSDK1乃至nによって処理された処理された要求を再構築するために、仲介サーバ104のために必要ないくつかのまたはすべての情報を備える。それはまた、コンテンツプロバイダ優先度情報記憶装置220に記憶されたコンテンツプロバイダ優先度情報を備える。

実施では、バッチ要求は、仲介SDK216のネットワークインターフェースを経由して仲介サーバ104へネットワーク108を介して送信される。ネットワーク108は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、ワイヤレスリンク、イントラネット、インターネット、またはこれらの組合せを含み得る。単一の要求のみがネットワーク108を介して送信されるという事実によって、仲介SDK216のネットワークインターフェース上の負荷はそれほどなく、ネットワーク108上の負荷もそれほどないので、コンテンツを求める多数の要求の仲介を試みるステップが大きく改善された場合、しばしばレイテンシ問題が見られる。

実施では、バッチ要求が、仲介サーバ104のネットワークインターフェースによって受信される。仲介サーバ104は、ウェブページまたは他のリソース(たとえば、記事、コメントスレッド、音楽、ビデオ、グラフィック、検索結果、情報フィード等)のようなリソースをホストするように構成された、サーバのようなコンピューティングデバイスを含み得る。仲介サーバ104は、コンピュータサーバ(たとえば、ファイル転送プロトコル(FTP)サーバ、ファイル共有サーバ、ウェブサーバ等)または、サーバの組合せ(たとえば、データセンタ、クラウドコンピューティングプラットフォーム等)であり得る。仲介サーバ104は、クライアントデバイス102へリソースデータまたは他のコンテンツ(たとえば、テキストドキュメント、PDFファイル、および他の形式の電子ドキュメント)を提供し得る。

実施では、バッチ要求は、仲介サーバのメモリ228に記憶された、仲介サーバ104の脱構築エンジン230によって処理される。脱構築エンジンは、仲介SDK216によって生成されたバッチ要求を、コンテンツプロバイダSDK1乃至nによって処理された処理された要求に対応する複数の処理された要求へ脱構築することができるように事前設定される。上記で議論されたように、複数の処理された要求の各々は、コンテンツプロバイダへの提出のために適切である。

実施では、仲介サーバはまた、メモリ228に記憶された分析モジュール232を有する。分析モジュールは、以下に議論されるコンテンツ記憶装置234、カウンタ236、およびコンテンツプロバイダ優先度情報記憶装置238を有する。

仲介サーバは、ネットワークインターフェースによって処理された要求を、ネットワーク110を介して特定のコンテンツプロバイダサーバへ送信し得る(ネットワーク110は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、ワイヤレスリンク、イントラネット、インターネット、またはこれらの組合せを含み得る)。たとえば、コンテンツプロバイダSDK1によって処理された要求に対応する処理された要求は、コンテンツプロバイダサーバ1へ送信され得る。コンテンツプロバイダSDK2によって処理された要求に対応する処理された要求は、コンテンツプロバイダサーバ2へ送信され得るという具合に、コンテンツプロバイダSDKnによって処理された要求に対応する処理された要求は、コンテンツプロバイダサーバnへ送信され得るまでなされる。このように、クライアントデバイス102上のアプリケーション206によってなされる初期要求に対応する要求は、適切に処理され、適切なコンテンツプロバイダサーバにおいてサービス提供され得る。

たとえば図2において見られるようなコンテンツプロバイダサーバ106のようなコンテンツプロバイダサーバは、上記で議論した要求のような要求に対して応答し得、コンテンツのアイテムを、ネットワーク110を通じて仲介サーバ104へ送信し得る。その後、このコンテンツのアイテムは、コンテンツ記憶装置234に記憶され得る。1つの実施では、仲介サーバ104の分析モジュール232は、受信されたコンテンツのアイテムを処理する。分析モジュールは、記憶されたデータを有し、これによって分析モジュールは、どれだけ多くの応答が期待されているのかを判定できるようになる。このデータは、たとえば、バッチ要求を処理した後に脱構築エンジンによって提供され得る。仲介サーバが、コンテンツプロバイダからコンテンツのアイテムを受信すると、コンテンツが、コンテンツを求める要求と、コンテンツのデバイスへのプロビジョンとの間の時間が最小化されて、クライアントデバイスへ提供され得るように、コンテンツが受信されると、アイテムが仲介SDK216へ送信され得る。あるいは、上記で議論されたように、コンテンツがコンテンツ記憶装置234に記憶され得、カウンタ236が、記憶されたコンテンツの各アイテムについてインクリメントされ得る。仲介サーバが、たとえば、コンテンツプロバイダからの、コンテンツのアイテムを提供することができない、または、提供することを好まないという通知を受信した場合も、カウンタ236がインクリメントされ得る。いくつかの実施では、カウンタ236は、たとえば、期待されたすべての応答が考慮されている場合を決定するために、分析モジュール232によって使用され得る。分析モジュール232は、その後、記憶されたコンテンツのアイテムを、ネットワーク108を介して仲介SDK216へと送信し得るか、または、仲介サーバ104に送信させ得るか、または、仲介サーバの任意の構成要素またはモジュールに送信させ得る。あるいは、または、それに加えて、記憶されたコンテンツのアイテムは、クライアントデバイス102へ、または、クライアントデバイス102の任意の構成要素もしくはモジュールへ送信され得る。クライアントデバイスへ転送されると、仲介サーバSDK216、またはアプリケーション206、またはクライアントデバイス、または、クライアントデバイスの任意の構成要素もしくはモジュールは、組み合わされて、または、他の方式で、コンテンツのどのアイテムを表示するのかを決定し得る。この決定は、コンテンツプロバイダ優先度情報に基づき得る。たとえば、最高品質のコンテンツであると判定され、コンテンツプロバイダによって提供されたコンテンツのアイテムが選択され得る。

分析モジュール232は、すべての記憶されたコンテンツのアイテムを送信する代わりに、コンテンツのうちのどの単一のアイテムが表示されるべきであるかを決定し、コンテンツのそのアイテムのみを、たとえば仲介SDKへ送信し得る。この決定は、コンテンツプロバイダ優先度情報記憶装置238に記憶されたコンテンツプロバイダ優先度情報に基づき得る。たとえば、提供されたコンテンツの品質は、優先度情報、たとえば、コンテンツプロバイダによって提供された品質に関する履歴データに基づいて、決定され得、分析モジュールは、この品質が、あらかじめ決定された基準を満足しないのであれば、あらかじめ決定された時間、追加のデータを待ち得る。あらかじめ決定された時間が超えられているのであれば、分析モジュールは、最高品質を有する受信されたコンテンツを送信し得る。

1つの実施では、分析モジュール232は、上述した方式で、送信されたすべての要求が考慮されるのを待つことなく、コンテンツ全体の最高優先度のアイテムを、これがコンテンツ記憶装置234に記憶されると動的に選択し、送信する。これは、分析モジュールに対して、コンテンツプロバイダ優先度情報に基づいて、全体の最高優先度のコンテンツプロバイダを判定させることによって実施され得る。このコンテンツプロバイダから受信されたコンテンツ記憶装置234に記憶されたコンテンツのアイテムは、分析モジュール232によって、コンテンツ全体の最高優先度のアイテムとしてタグ付けされる。実施では、コンテンツのアイテムがそのようにタグ付けされると、それは直ちに、たとえば、仲介SDK216へ送信され、仲介SDK216は、それを表示し得る。これは、分析モジュール232が、コンテンツの最高優先度のアイテムを提供する全体処理を短縮することを可能にする。なぜなら、分析モジュール232は、コンテンツ全体の最高優先度のアイテムよりも低い優先度のコンテンツのアイテムを受信および記憶することを待つ必要がないからである。

別の実施では、分析モジュール232は、コンテンツプロバイダからのコンテンツのアイテムが受信され得る時間の最大長さを設定するためにタイムアウト期間を使用する。タイムアウト期間は、たとえば、仲介サーバ104からの応答のための最大許容時間に関連するタイミング情報に基づき得る。仲介SDK216によって送信されたバッチ要求は、このタイミング情報を備え得る。たとえば、分析モジュール232は、コンテンツプロバイダSDKnによって処理された処理された要求に対応するコンテンツプロバイダnへ第1の処理された要求を送信した場合、タイマを起動し得る。このタイマは、タイミング情報に基づいて、分析モジュール232によって決定されたタイムアウト期間と連続的に比較される。あるいは、タイムアウト期間は、仲介サーバに記憶されたあらかじめ決定された値に対応し得る。タイムアウト期間は、任意の時間の長さであり得るが、好適には、1秒よりも長くはない。

実施では、タイマが、固定されたタイムアウト期間を超える時間の長さをカウントすると、分析モジュール232は、記憶されたコンテンツのアイテムを、ネットワーク108を介して仲介SDK216へ送信する。分析モジュールはまた、上に記載された方式で、コンテンツ記憶装置234に記憶されたコンテンツのアイテムのうち、最高優先度のコンテンツのアイテムであると決定した単一のコンテンツのアイテムを送信する。

図3は、ハイブリッドクライアントサーバデータプロビジョンのための方法の実施におけるシステム100の構成要素間のインタラクションのいくつかを図示する。この図において、矢印は一般に、処理済み、未処理、バッチされた、または他の状態のうちの何れかであるコンテンツのアイテムを求める要求を示す。実施では、1つはコンテンツプロバイダSDK1へ向かい、他はコンテンツプロバイダSDKnへ向かう2つの要求が、アプリケーション206から始まる。アダプタ1およびアダプタnは各々、それぞれが受信した要求を処理し、コンテンツプロバイダサーバへの提出のために適切なフォーマットである処理された要求を出力する。たとえば、アダプタ1によって処理された処理された要求は、コンテンツプロバイダ1への提出のために適切なヘッダ情報を有し、アダプタnによって処理された処理された要求は、コンテンツプロバイダnへの提出のために適切なヘッダ情報を有する。

実施では、アプリケーション、またはコンテンツプロバイダSDK、またはその両方と統合されたインタセプタモジュール222が、これら2つの処理された要求を受信する。コンソリデータモジュール224は、これら要求を、コンテンツプロバイダ優先度情報を備える単一のバッチ要求としてともにバッチ化し、(単一矢印によって表される)この単一のバッチ要求を、ネットワーク108を介して仲介サーバ104へ送信する。仲介サーバ104は、その後、コンテンツプロバイダ優先度情報に基づいて、このバッチ要求を、2つのコンテンツプロバイダサーバへ仲介する。その後、仲介サーバ104は、コンテンツの単一の最高優先度のアイテムを、ネットワーク108を介して仲介SDK216へ返送し、仲介SDK216は、コンテンツの単一の最高優先度のアイテムを表示し得るか、または、表示されるようにし得る。

図4は、ハイブリッドクライアントサーバデータプロビジョンのための方法の実施において、システム100の構成要素間の他のいくつかのインタラクションを図示する。実施では、仲介サーバ104は、単一の矢印によって描写される単一のバッチ要求を、ネットワーク108を介して仲介SDK216から受信する。バッチ要求は、分析モジュール232の脱構築エンジン230によって処理される。脱構築エンジン230は、コンテンツ優先度情報を、コンテンツ優先度情報記憶装置238に記憶し、2つの矢印によって描写される2つの要求、すなわち、コンテンツプロバイダSDK1によって処理された処理された要求に対応する、コンテンツプロバイダサーバ1へ向かう1つの要求と、コンテンツプロバイダSDKnによって処理された処理された要求に対応する、コンテンツプロバイダサーバnへ向かう1つの要求とをネットワーク110を介して送信する。コンテンツプロバイダサーバは、コンテンツ記憶装置234に記憶されたコンテンツの2つのアイテムを返す。その後、仲介サーバの分析モジュール232は、コンテンツ記憶装置234からのコンテンツの両方のアイテムを選択し、ネットワーク108を介して仲介SDK216へ送信する。仲介SDK216は、コンテンツプロバイダ優先度情報に基づいて、単一の最高優先度のコンテンツのアイテムを表示し得るか、または、表示されるようにし得る。

図5は、分析モジュール232による送信決定処理を描写するフローチャートを図示する。実施では、分析モジュール232は、あらかじめ決定されたタイムアウト期間を有する。仲介サーバ104は、400において、複数のコンテンツプロバイダサーバに、コンテンツのアイテムを要求する。402において、仲介サーバは、(あらかじめ決定されたタイムアウト期間に基づいて)タイムアウト、または、新たな応答、すなわち、コンテンツプロバイダサーバによって提供された新たなコンテンツのアイテムまたは失敗通知を待つ。タイムアウトが生じた場合、416において、分析モジュール232は、コンテンツ記憶装置234に記憶された何れかのコンテンツのアイテムが存在するか否かを判定する。存在しないのであれば、418において、仲介サーバ104は、ネットワーク108を介して仲介SDK216へ失敗応答を送信する。たとえば、仲介サーバ104は、たとえば、クライアントデバイス102に記憶されたあらかじめ決定されたコンテンツのアイテムを表示する、コンテンツのアイテムを取得するための失敗の手順を開始するように仲介をトリガするために、あらかじめ決定された失敗信号を仲介SDK216へ送信し得る。

416において、分析モジュール232が、コンテンツ記憶装置234に少なくとも1つの記憶されたコンテンツのアイテムが存在すると判定すると、420において、分析モジュール232は、コンテンツプロバイダ優先度情報に基づいて、記憶されている任意のコンテンツのアイテムのうち、最高優先度のコンテンツのアイテムを判定し、選択する。その後、422において、選択されたコンテンツは、仲介サーバ104によって、ネットワーク108を介して仲介SDK216へ送信される。

402に戻って、コンテンツプロバイダからの新たな応答が、仲介サーバ104によって受信されると、すなわち、新たなコンテンツのアイテムが、コンテンツプロバイダサーバまたは失敗通知によって提供されると、分析モジュール232は、この応答が、コンテンツのアイテムであるか、または、失敗応答であるかを判定する。この応答が失敗応答であれば、カウンタ236が、410においてインクリメントされ、412において、分析モジュール232は、期待されたすべての応答が考慮されているか否かを、脱構築エンジン230によって提供された期待された応答情報の数に基づいて判定する。考慮されていなければ、我々は、402へ戻って待つ。期待されたすべての応答が考慮されているのであれば、我々は、420へ進み、上記で記載されたように進める。

404へ戻って、新たな応答が、分析モジュール232によって、コンテンツのアイテムであると判定されると、コンテンツのアイテムが、コンテンツ記憶装置234に記憶される。408において、分析モジュール232は、それがコンテンツ全体の最高優先度のアイテムであるか否か、すなわち、それが、コンテンツプロバイダ優先度情報記憶装置238に記憶されたコンテンツプロバイダ優先度情報から、分析モジュール232によって決定されたような最高優先度コンテンツプロバイダに対応するか否かを判定する。それが、コンテンツ全体の最高優先度のアイテムであれば、このコンテンツのアイテムが、414において、分析モジュール232によって選択され、422において、選択されたコンテンツのアイテムが、仲介サーバ104によって、ネットワーク108を介して仲介SDK216へ送信される。408において、分析モジュール232が、このコンテンツのアイテムが、コンテンツ全体の最高優先度のアイテムではないと判定すると、我々は410へ進み、上記で記載されたように、ここから進める。

上記で議論されたように、コンテンツを求める極めて多数の要求が、多数のサーバにコンテンツを要求するアプリケーションによって送信された場合、多くの問題が生じ得る。たとえば、複数の要求を送信するために多数のネットワーク接続を開く際に使用されるメモリのように、アプリケーションを実行しているクライアントデバイス上のコンピューティングリソースの観点から問題が存在し得る。アプリケーションを実行しているクライアントデバイスが、多数の要求の仲介、および、これら要求に対する応答を実行することはまた、コンピューティングリソースを大量に使用し得る。たとえば、コンテンツを求める要求に対するどの応答が、たとえば、アプリケーションの開発者など、提供されたコンテンツの選択を制御するパーティに対して最も好適であるか決定するための分析を実行することは、コンピューティングリソースを大量に使用し得る。これは、開発者が、アプリケーションに対して、たとえば、コンテンツの品質、印象機会を満たす好機のためにサードパーティコンテンツプロバイダによって提供された入札額、または、サードパーティコンテンツプロバイダとの接続のレイテンシのような複数の要因に基づいてこの選択をさせるのであれば、特に困難であり得る。ネットワークを介して多数の要求の送信を試みるアプリケーションはまた、特に、ネットワークが、たとえば3Gまたは4Gネットワークのようなモバイルネットワークである場合、レイテンシの観点から問題に出くわし得る。アプリケーションが実行されるクライアントデバイスによって多数の要求を送出するステップと、応答を受信するステップとの間に、顕著な遅延または遅れが存在し得る。本願において議論されたハイブリッドクライアントサーバデータプロビジョンの方法は、とりわけ、たとえば、サーバに対して、コンテンツを求める多数の要求のコンピューティングリソースを大量に使用する仲介を取り扱わせることによって、または、レイテンシ問題を改善するために、サーバツーサーバネットワーク接続を利用することによって、または、これらの方法を使用することによって提供される他の利点のうちの何れかによってこれらの問題を改善することを支援し得る。

例として、これらの方法のうちの1つの実施は、ニュースアイテムを表示することを試みているクライアントデバイスにおいて実行されるニュースアプリケーションを含み得る。ニュースアプリケーションは、表示するためのニュースアイテムを求める多数の要求を、ニュースコンテンツプロバイダへ行い得る。たとえば、これら要求は、たとえば、CNN、NBCニュース、およびFOXニュースのような様々なニュースコンテンツプロバイダへ送信され得る。これら要求は、コンテンツプロバイダサーバへの提出のための要求を処理するアプリケーションと統合されたクライアントデバイスにおいて、コンテンツプロバイダSDKを介して送信され得る。たとえば、ニュースアプリケーションと統合されたCNNニュースSDKは、コンテンツのニュースアイテムを提供するCNNニュースサーバへの提出のために意図された要求を処理し得、ニュースアプリケーションと統合されたNBCニュースSDKは、コンテンツのニュースアイテムを提供するNBCニュースサーバへの提出のために意図された要求を処理し得る等である。処理された要求は、その後、アプリケーションと統合され、ともにバッチ化された仲介SDKによってインタセプトされ得る。仲介SDKは、その後、バッチ化された要求を、仲介サーバへ送信し得る。バッチ要求は、コンテンツプロバイダ優先度情報を含み得る。たとえば、バッチ要求は、ユーザが、提供されたコンテンツに対して過去にどれだけの頻度でクリックしたかに基づいて、ニュースプロバイダサーバをランク付けるニュースプロバイダの「品質」ランキングを含み得る。バッチ要求は、その代わりに、または、それに加えて、提供されたコンテンツにおけるニュースプロバイダサーバの過去の圧縮効率に基づいて、「圧縮」情報を含み得る。仲介SDKは、コンテンツを求める多数の要求の仲介において、このコンテンツプロバイダ優先度情報を使用し得る。

実施では、バッチ要求は、単一のネットワーク接続しか開かれる必要がないという点において、コンテンツを求める多数の要求を行うアプリケーションよりも顕著な利点を、ニュースプロバイダサーバへ提供し、したがって、クライアントデバイスにおけるコンピューティングリソースを節約する。さらに、多数の要求の仲介、および、これら要求に対する応答が、仲介サーバに対してなされ得、クライアントデバイスにおけるコンピューティングリソースをさらに節約する。仲介サーバはまた、コンテンツプロバイダと通信するためにサーバツーサーバネットワーク接続を利用し得る。これは、しばしば、特に、その接続が3Gまたは4Gのようなモバイルネットワークを介してなされた場合、クライアントデバイスツーサーバネットワーク接続よりも、レイテンシおよび応答の速度の観点から利点を提供し得る。

これらの方法の別の実施は、印象機会を満たすために、アプリケーションによって要求されているサードパーティコンテンツを含み得る。印象機会は、デバイス上に、あるコンテンツを表示する機会であり得る。いくつかの実施では、サードパーティは、コンテンツに印象機会を満たさせるために料金を支払い得る。そのような実施では、オークション処理が、たとえば、アプリケーションによって直接的に、または、たとえば、アプリケーションを実行するオペレーティングシステムにおいて実行されるプログラムによって、または、アプリケーションと通信しているサーバによって、または、他の任意の適切な方式で間接的に、アプリケーションによって実施され得る。そのようなオークションでは、入札は、多数のサードパーティコンテンツプロバイダから請求され得、競売人の基準に基づいて1つの入札が選択され得る。そのような基準は、たとえば、コンテンツプロバイダへの接続の期待されるレイテンシ、提供されるコンテンツの期待される品質、実際に入札した通貨額、予想されるクリックスルーレート(pCTR)、予想される転換レート(pCVR)、または、競売人が考慮することを所望し得る他の任意の要因に基づき得る。

いくつかの事例では、アプリケーションは、仲介ウォータフォールを確立する処理の一部として印象機会を満たすために、多数のサードパーティコンテンツプロバイダにコンテンツを要求し得る。仲介ウォータフォールは、印象機会を有する発表者または誰かが、その機会をコンテンツプロバイダへ販売する場合に得る金額を最大化することを助けるコンテンツアイテムを求める要求を体系化する方式である。異なるコンテンツプロバイダは、印象機会のために別の額を喜んで支払い得る。仲介ウォータフォールでは、複数の要求が、コンテンツプロバイダへ送出される。仲介ウォータフォールを開始する競売人は、要求が送信されたコンテンツプロバイダのグループのうち、最高の支払いを行うコンテンツプロバイダであると推定されたコンテンツプロバイダを優先し得る。より高い支払いを行うコンテンツプロバイダが、要求された価格の代わりにコンテンツのアイテムを提供することに合意しないのであれば、これらコンテンツプロバイダの提供したコンテンツのアイテムを受諾する意図で、他のコンテンツプロバイダへ他の要求も送信される。常ではないが、典型的には、2番目に高い支払いを行うコンテンツプロバイダであると推定されたコンテンツプロバイダが優先され、そのコンテンツプロバイダとの合意に達しないのであれば、3番目に高い支払いを行うコンテンツプロバイダであると推定されたコンテンツプロバイダが優先されるという具合である。

アプリケーションが、仲介ウォータフォールを確立する意図で、コンテンツを求める多数の要求を行う実施では、バッチ要求は、単一のネットワーク接続しか開かれる必要がないという点において、コンテンツを求める多数の要求を行うアプリケーションよりも顕著な利点を、コンテンツプロバイダへ提供し、したがって、クライアントデバイスにおけるコンピューティングリソースを節約する。さらに、仲介サーバにオークションを実行させることを含む多数の要求の仲介、および、これら要求に対する応答が、仲介サーバに対してなされ得、クライアントデバイスにおけるコンピューティングリソースをさらに節約する。仲介サーバはまた、コンテンツプロバイダと通信するためにサーバツーサーバネットワーク接続を利用し得る。これは、しばしば、特に、その接続が3Gまたは4Gのようなモバイルネットワークを介してなされた場合、クライアントデバイスツーサーバネットワーク接続よりも、レイテンシおよび応答の速度の観点から利点を提供し得る。

本明細書は多くの具体的な実施詳細を含むが、これらは、特許請求され得る範囲に対する限定としてではなく、特定の実施に特有の特徴の記載として解釈されるべきである。個別の実施のコンテキストにおいて本明細書において記載されたいくつかの特徴はまた、単一の実施における組合せにおいて実施され得る。逆に、単一の実施のコンテキストにおいて記載されている様々な特徴はまた、多数の実施において個別に、または、任意の適切な部分組合せにおいて実施され得る。さらに、特徴は、いくつかの組合せにおいて動作するものとして上に記載され得、そのようなものとして最初に特許請求されているが、特許請求された組合せからの1つまたは複数の特徴が、いくつかのケースでは、部分集合から削除され得、特許請求された組合せは、部分集合または部分集合の変形を対象とされ得る。

同様に、動作は、図面において特定の順序で描写されているが、これは、そのような動作が、望ましい結果を達成するために、図示された特定の順序で、または、シーケンシャルな順序で実行されること、または、例示されたすべての動作が実行されるべきであることを必要としているとは理解されるべきではない。いくつかの状況では、マルチタスクおよび並列処理が有利であり得る。さらに、上で記載された実施における様々なシステム構成要素の分離は、すべての実施におけるそのような分離を必要とするものとして理解されるべきではなく、記載されたプログラム構成要素およびシステムは一般に、単一のソフトウェア製品へ統合され得るか、または、有形の媒体に具体化された多数のソフトウェア製品へパッケージされ得ることが理解されるべきである。「または」に対する参照は、「または」を使用して記載された任意の用語が、記載された用語のうちの1つ、1つよりも多く、およびすべてのうちの何れをも示し得るように、包括的であると解釈され得る。

このように、本主題の特定の実施が記載された。他の実施は、以下の特許請求の範囲の範囲内にある。いくつかのケースでは、特許請求の範囲において記載された動作は、異なる順序で実行され、依然として望ましい結果を達成し得る。それに加えて、添付図面に描写された処理は、望ましい結果を達成するために、必ずしも図示された特定の順序または連続した順序を必要とする訳ではない。いくつかの実施では、マルチタスクおよび並列処理が有利であり得る。

特許請求の範囲は、そのような趣旨で述べられていない限り、記載された順序または要素に対する限定として解釈されるべきではない。形式および詳細における様々な変化が、添付された特許請求の範囲の趣旨および範囲から逸脱することなく当業者によってなされ得ることが理解されるべきである。以下の特許請求の範囲およびその均等物の趣旨および範囲内に生じるすべての実施が、特許請求される。

100 システム
102 クライアントデバイス
104 仲介サーバ
106 コンテンツプロバイダサーバ
108 ネットワーク
110 ネットワーク
200 プロセッサ
202 メモリ
204 ディスプレイ
206 アプリケーション
216 仲介SDK
218 メモリ
220 コンテンツプロバイダ優先度情報記憶装置
222 インタセプタモジュール
224 コンソリデータモジュール
226 プロセッサ
228 メモリ
230 脱構築エンジン
232 分析モジュール
234 コンテンツ記憶装置
236 カウンタ
238 コンテンツプロバイダ優先度情報記憶装置
240 プロセッサ
242 メモリ
244 プロセッサ
246 メモリ

Claims (20)

1. ハイブリッドクライアントサーバデータプロビジョンのための方法であって、
   クライアントデバイスによる表示のためのコンテンツのアイテムを求める要求を、アプリケーションと統合された複数のコンテンツプロバイダソフトウェア開発キット(SDK)の各々に、前記クライアントデバイスによって実行される前記アプリケーションによって送信するステップと、
   複数のコンテンツプロバイダサーバへの潜在的な提出のために、前記コンテンツプロバイダSDKの複数の要求アダプタによって、コンテンツの前記アイテムを求める前記要求をそれぞれ処理し、これによって、複数の処理された要求を生成するステップと、
   前記複数のコンテンツプロバイダSDKから、前記アプリケーションと統合された仲介SDKのインタセプタモジュールによって、前記複数の処理された要求を受信するステップと、
   前記複数の処理された要求を、前記仲介SDKのコンソリデータモジュールによって、バッチ要求へバッチ化するステップであって、前記バッチ要求は、コンテンツプロバイダ優先度情報および前記バッチ要求を仲介するためのタイミング情報を備える、バッチ化するステップと、
   前記コンテンツプロバイダ優先度情報および前記タイミング情報に基づいて、前記複数のコンテンツプロバイダサーバへの前記バッチ要求の仲介のために、前記仲介SDKによって、仲介サーバへ前記バッチ要求を送信するステップと、
   前記クライアントデバイスによる表示のために、前記仲介サーバからのコンテンツのうちの少なくとも1つのアイテムを、前記仲介SDKによって受信するステップと
   を備える方法。
2. 複数のコンテンツプロバイダサーバへの潜在的な提出を求める前記要求を前記処理するステップはさらに、前記複数のコンテンツプロバイダサーバのうちの1つのための適切なヘッダ情報を含めるステップを備える、請求項1に記載の方法。
3. 前記コンテンツプロバイダ優先度情報はさらに、コンテンツプロバイダサーバの優先度ランキングを備える、請求項1に記載の方法。
4. 前記コンテンツプロバイダ優先度情報は、前記アプリケーションによって前記仲介SDKへ提供される、請求項1に記載の方法。
5. 前記仲介SDKの分析エンジンによって、前記コンテンツプロバイダ優先度情報に基づいて、前記クライアントデバイスによる表示のために、前記コンテンツのうちの少なくとも1つのアイテムから、コンテンツの単一のアイテムを選択するステップをさらに備える、請求項4に記載の方法。
6. 前記仲介サーバから受信された、表示のための前記コンテンツのうちの少なくとも1つのアイテムは、前記仲介サーバから受信された、表示のためのコンテンツの唯一のアイテムであり、表示のための前記コンテンツのうちの少なくとも1つのアイテムは、前記仲介サーバが取得することが可能であったコンテンツプロバイダ優先度情報に基づく、表示のためのコンテンツの最高優先度のアイテムである、請求項1に記載の方法。
7. 前記タイミング情報は、前記仲介サーバからの応答のための最大許容時間を特定する、請求項1に記載の方法。
8. 前記タイミング情報は、前記コンテンツプロバイダサーバからの応答のための最大許容時間を特定する、請求項7に記載の方法。
9. 前記インタセプタモジュールが、前記処理された要求をインタセプトする、請求項1に記載の方法。
10. 前記処理された要求をインタセプトする前記インタセプタモジュールは、前記仲介SDKのコールバックインターフェースを使用する前記コンテンツプロバイダSDKを備える、請求項9に記載の方法。
11. 前記処理された要求をインタセプトする前記インタセプタモジュールは、前記コンテンツプロバイダSDKによって、前記コンテンツプロバイダサーバへのコールをブロックするステップを備える、請求項9に記載の方法。
12. ハイブリッドクライアントサーバデータプロビジョンのための方法であって、
    仲介ソフトウェア開発キット(SDK)から、クライアントデバイスによる表示のためのコンテンツのアイテムを求めるバッチ要求を、仲介サーバによって受信するステップであって、前記バッチ要求は、前記クライアントデバイス上の複数のコンテンツプロバイダSDKによって処理されたコンテンツのアイテムのための複数の処理された要求に基づいて、前記仲介SDKのコンソリデータモジュールによって生成される、受信するステップと、
    複数のコンテンツプロバイダ特有要求を生成するために、前記仲介サーバの脱構築エンジンによって、前記バッチ要求を処理するステップと、
    前記仲介サーバによって、複数のコンテンツプロバイダサーバへ、前記複数のコンテンツプロバイダ特有要求を送信するステップと、
    前記コンテンツプロバイダ特有要求のうちの少なくとも1つに応じて、コンテンツのうちの少なくとも1つのアイテムを、前記仲介サーバによって、前記コンテンツプロバイダサーバから受信し、前記仲介サーバの分析モジュールのコンテンツ記憶装置に、前記コンテンツの少なくとも1つのアイテムを記憶するステップと、
    送信のために、少なくとも1つの記憶されたコンテンツのアイテムのうちのコンテンツの単一のアイテムを、前記仲介サーバの前記分析モジュールによって選択するステップと、
    前記バッチ要求に対する応答として前記選択されたコンテンツの単一のアイテムを、前記仲介サーバによって前記仲介SDKへ送信するステップと
    を備える方法。
13. 前記選択されたコンテンツのアイテムを前記送信するステップは、あらかじめ決定されたタイムアウト期間後に生じる、請求項12に記載の方法。
14. 前記バッチ要求はさらに、タイミング情報を備える、請求項12に記載の方法。
15. 前記選択されたコンテンツのアイテムを前記送信するステップは、前記タイミング情報に基づいて、前記分析モジュールによって確立されたタイムアウト期間後に生じる、請求項14に記載の方法。
16. 前記コンテンツの少なくとも1つのアイテムは、コンテンツの複数のアイテムを含む、請求項12に記載の方法。
17. 前記仲介サーバによって前記仲介SDKからコンテンツプロバイダ優先度情報を受信するステップを更に備えていて、送信のために、コンテンツの前記単一のアイテムを選択するステップは、前記コンテンツプロバイダ優先度情報に基づく、請求項12に記載の方法。
18. コンテンツプロバイダ優先度情報は、コンテンツプロバイダの優先度ランキングを含む、請求項12に記載の方法。
19. 前記コンテンツのアイテムを求める複数の処理された要求は、異なるコンテンツプロバイダサーバを特定するそれぞれのヘッダを含む、請求項18に記載の方法。
20. コンテンツの単一のアイテムが、前記コンテンツプロバイダ優先度情報に基づく最高優先度コンテンツプロバイダからであることを決定するステップと、コンテンツの選択された単一のアイテムを、複数のコンテンツプロバイダサーバのいずれかから追加のコンテンツアイテムを受信するために待つことなく、応答的に送信するステップとを更に備えている、請求項18に記載の方法。

Images