JP2010044762A - 広告目的のためのデータファサード加入フィルタを用いる方法およびシステム - Google Patents

Abstract

【課題】
ターゲットとされたモバイル広告の配信のための方法およびシステムを提供する。
【解決手段】
ターゲットとされたモバイル広告の配信のための方法であって、該方法は、広告クライアントを携帯型デバイス上のデータファサードと関連づけることと、加入フィルタを該広告クライアントから該データファサードに渡すことと、該携帯型デバイスにおいて、該加入フィルタに関連する広告のためのデータを受信することと、広告のためのデータを要求するために、広告アプリケーションと該広告クライアントとの間で通信することと、該広告クライアントにおいて、該広告アプリケーションに対する広告のためのデータを選択することと、該広告データを該広告アプリケーションに戻すこととを包含する、方法。
【選択図】図１

Description

（開示の分野）
本開示は概して、広告コンテンツの配信および表示のためのアーキテクチャに関し、特に、携帯型デバイス上への広告コンテンツの配信および表示に関する。

（背景）
オープンモバイルアライアンス（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ；ＯＭＡ）のモバイル広告（ｍｏｂｉｌｅ ａｄｖｅｒｔｉｓｉｎｇ；ＭｏｂＡｄ）仕様の下で、携帯型デバイス上のアプリケーションは、広告クライアントからの広告を要求する。要求を行うアプリケーションは、「広告アプリ（Ａｄ Ａｐｐ）」と呼ばれ、広告クライアントに対して広告要求を行うデバイス上に常駐する任意のアプリケーションである。広告アプリは、広告選択を容易にするために、広告要求とともに関連情報を渡すことがある。そのような情報は、特に、テキスト、オーディオ、ビデオ、サイズの制限などの広告のフォーマットを含み得る。要求はまた、アプリケーションが、例えば、特にスポーツ、金融に関心があるというトピックについての情報を含み得る。広告要求は、アプリケーションのタイプ自体についての情報をも含み得る。例えば、ウィジットまたはショートメッセージサービス（ＳＭＳ）である。一部の場合において、広告要求は、アプリケーションが捜している特定の広告を識別するための広告識別子を含み得る。

広告クライアントは、デバイス上に常駐するモジュール式のアプリケーションであり、一部の実施形態において、広告を事前にフェッチし、広告プラットホームからの広告を要求し、他のユーザデバイスの情報を潜在的に収集し、広告とのユーザ相互作用を追跡し、かつ／または広告量を報告することが可能である。一部の実施形態において、広告クライアントはまた、ターゲットとされた広告を広告アプリケーションに対して提供するために、広告選択を実行し得る。そのような選択は、アプリケーションタイプ、アプリケーションコンテンツ、ユーザプリファレンスに適切な広告などの基準または他の同様な基準を用い得る。

一般的なデータファサード（ｆａｃａｄｅ）は、集中化されたデータ／コンテンツの処理と、サーバ側から受信されたデータのターゲットアプリケーションへの分配と、アプリケーションデータをサーバ側に送信することとを担うモジュールである。一例としては、オープンモバイルアライアンス（ＯＭＡ）の動的コンテンツ配信（ｄｙｎａｍｉｃ ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ；ＤＣＤ）仕様であり、これは、ターゲットとされたＤＣＤアプリケーションに対するＤＣＤチャネルを用いて、コンテンツを受信することを担い、そしてアプリケーションに代わってコンテンツを管理することを担い得るＤＣＤクライアントを提供する。ＤＣＤ仕様は、一般的なファサードのほんの一例であり、他の一般的なファサードが本開示に適用可能である。データファサードは、ＤＣＤの場合、携帯型デバイスに対するＤＣＤクライアントであり、そしてネットワーク側に対するＤＣＤサーバであり得る。

（概要）
本開示は、ターゲットとされたモバイル広告の配信のための方法を提供し得、該方法は、広告クライアントを携帯型デバイス上のデータファサードと関連づけることと、加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）フィルタを該広告クライアントから該データファサードに渡すことと、該携帯型デバイスにおいて、該加入フィルタに関連する広告を受信することと、広告を要求するために、広告アプリケーションと該広告クライアントとの間で通信することと、該広告クライアントにおいて、該広告アプリケーションに対する広告を選択することと、該広告を該広告アプリケーションに戻すこととを包含し得る。

本開示は、モバイル広告の配信に適した携帯型デバイスをさらに提供し得、該携帯型デバイスは、通信サブシステムと、該通信サブシステムを介してデータ配信サーバと通信するデータファサードと、該データファサードと関連づけ、そして加入フィルタを該データファサードクライアントに渡すことが可能な広告クライアントと、該広告クライアントからの広告を要求し、そして該広告クライアントから広告を受信することが可能な広告アプリケーションとを備え得る。

本発明は、さらに以下の手段を提供する。
（項目１）
ターゲットとされたモバイル広告の配信のための方法であって、該方法は、
広告クライアントを携帯型デバイス上のデータファサードと関連づけることと、
加入フィルタを該広告クライアントから該データファサードに渡すことと、
該携帯型デバイスにおいて、該加入フィルタに関連する広告のためのデータを受信することと、
広告のためのデータを要求するために、広告アプリケーションと該広告クライアントとの間で通信することと、
該広告クライアントにおいて、該広告アプリケーションに対する広告のためのデータを選択することと、
該広告データを該広告アプリケーションに戻すことと
を包含する、方法。
（項目２）
上記広告クライアントは、上記データファサードに加入する、上記項目のうちのいずれか一項目に記載の方法。
（項目３）
上記データファサードは、動的なコンテンツ配信クライアントの一部分である、上記項目のうちのいずれか一項目に記載の方法。
（項目４）
上記加入フィルタは、上記広告クライアントと通信するすべての広告アプリケーション用に統合された加入フィルタである、上記項目のうちのいずれか一項目に記載の方法。
（項目５）
加入識別子が、上記モバイル広告クライアントに提供される、上記項目のうちのいずれか一項目に記載の方法。
（項目６）
上記加入フィルタは、
ユーザの関心と、
ユーザの配信プリファレンスと、
ユーザのコンテキストと、
言語プリファレンスと、
広告のフォーマットプリファレンスと、
デバイス特性と、
コンテンツタイプと、
メディアタイプと
のグループから選択される１つ以上のパラメータを含む、上記項目のうちのいずれか一項目に記載の方法。
（項目７）
上記選択するステップは、広告のためのデータをフィルタリングするステップを包含する、上記項目のうちのいずれか一項目に記載の方法。
（項目８）
上記フィルタリングするステップは、コンテンツタイプに基づいて動的に対応付けるステップに基づく、上記項目のうちのいずれか一項目に記載の方法。
（項目９）
上記動的に対応付けるステップは、上記広告クライアントによって仲介される、上記項目のうちのいずれか一項目に記載の方法。
（項目１０）
上記フィルタリングするステップは、上記広告の要求におけるパラメータに基づく、上記項目のうちのいずれか一項目に記載の方法。
（項目１１）
上記加入フィルタは、パラメータを有するテキストストリングまたはオーバーロードされたユニフォームリソースロケータである、上記項目のうちのいずれか一項目に記載の方法。
（項目１２）
動的条件に基づいてアップデートされた加入フィルタを送信するステップをさらに包含する、上記項目のうちのいずれか一項目に記載の方法。
（項目１３）
上記動的条件は、資源のしきい値、位置による制限またはプレゼンスによる制限を備える、上記項目のうちのいずれか一項目に記載の方法。
（項目１４）
モバイル広告の配信に適した携帯型デバイスであって、該携帯型デバイスは、
通信サブシステムと、
該通信サブシステムを介してデータ配信サーバと通信するデータファサードと、
広告クライアントと、
広告アプリケーションと
を備え、
上記項目のうちのいずれか一項目に記載の方法のステップを実行するように適合されている、
携帯型デバイス。
（項目１５）
ユーザ機器のプロセッサによって実行される場合に、上記項目のうちのいずれかに記載の方法のステップを実行するように該ユーザ機器を適合させる命令を備えるコンピュータ読み取り可能な媒体。

（摘要）
ターゲットとされたモバイル広告の配信のための方法およびシステムであって、該方法は、広告クライアントを携帯型デバイス上のデータファサードと関連づけることと、加入フィルタを該広告クライアントから該データファサードに渡すことと、該携帯型デバイスにおいて、該加入フィルタに関連する広告を受信することと、広告を要求するために、広告アプリケーションと該広告クライアントとの間で通信することと、該広告クライアントにおいて、該広告アプリケーションに対する広告を選択することと、該広告を該広告アプリケーションに戻すこととを行う。

本開示は、図面を参照することによってよりよく理解される。
図１は、広告目的のためにデータファサード加入フィルタを用いるために必要とされるデバイス側の構成要素のブロック図である。 図２は、データファサードによる加入フィルタの使用を示すデータフロー図である。 図３は、広告クライアントおよび広告サーバに戻される広告のサブセットを示す図である。 図４は、各広告アプリケーションに対してデータファサード加入フィルタを用いるために必要とされるデバイス側の構成要素のブロック図である。 図５は、各広告アプリケーションに対してデータファサード加入フィルタを用いることを示すデータフロー図である。 図６は、広告クライアントおよび広告サーバに戻される広告のサブセットを示す図である。 図７は、本開示の方法およびシステムによって用いられ得る携帯型デバイスのブロック図である。

（好適な実施形態の説明）
ここで図面を参照する。図１において、広告クライアント１１０は、広告アプリケーション１２０および広告アプリケーションＮ １２２として示される複数の広告アプリケーションと通信する。このことは、複数の広告アプリケーションを表すことが意図されており、そして本開示は、広告クライアント１１０と通信する広告アプリケーションの任意の特定の数によって制限はされない。

ＤＣＤクライアント１３０は、一般的なデータファサードに対する例示目的のために図１において用いられる。ＯＭＡ ＤＣＤ仕様において、ＤＣＤクライアント１３０は、ＤＣＤアプリケーションを介して登録するために、ターゲットとされたＤＣＤチャネルを介してコンテンツを受信することを担い、そしてアプリケーションに代わってこのコンテンツを管理するか、またはキャッシュすることを担い得る。ＤＣＤ対応クライアントアプリケーションは、ＤＣＤクライアント１３０にアプリケーションプロフィールを提供し、そしてこのアプリケーションプロフィールは、アプリケーションに対する配信プリファレンスおよびストレージプリファレンスを構成し、アプリケーションのコンテンツプリファレンスを、ＤＣＤ対応クライアントアプリケーションにとって関心があり得る利用可能なチャネルのサブセットに対応付けるように用いられる。

ポイントツーポイント配信の状況において、対応付けることは、一般にＤＣＤサーバ１４０によってサーバ側で実行され、そしてＤＣＤサーバ１４０およびＤＣＤクライアント１３０はともに、「ＤＣＤイネーブラ（ｅｎａｂｌｅｒ）」１４２を形成する。

同報通信のシナリオにおいて、利用可能なチャネルをリストにするチャネルガイドがデバイスに配信され、そして対応付けることは、ＤＣＤクライアント１３０によってクライアント側で行われる。ＤＣＤ対応クライアントアプリケーションは、次いでそれらのチャネルに加入する（ｓｕｂｓｃｒｉｂｅ）ことによってアプリケーションプロフィールをチャネル特性に対応付けることによってサブセットから関心のあるチャネルを選び出し得る。

ＤＣＤ対応クライアントアプリケーションの加入に続き、アプリケーションは、コンテンツプロバイダが、ユーザまたは複数ユーザのグループのチャネルコンテンツをパーソナル化することを可能にする加入フィルタを提供し得る。加入フィルタは、コンテンツのターゲット化およびパーソナル化を保証するために、データファサードに対して不透明な（ｏｐａｑｕｅ）メカニズムをコンテンツプロバイダに提供する。アプリケーションプロフィールは、アプリケーションが関心のあるコンテンツのタイプに対する一般的なタグまたはトークンをリストにするフィールド「コンテンツタイプ」を含み得る。コンテンツプロバイダによって提供されるコンテンツ項目が、コンテンツ項目のコンテンツタイプを記載するメタデータを含むときに、ＤＣＤサーバ１４０および／またはＤＣＤクライアント１３０は、このコンテンツ項目を、チャネルに加入し、そしてコンテンツ項目に関心があり得るＤＣＤ対応クライアントアプリケーションと動的に対応付け得る。対応付けることは、例えば、ＤＣＤ対応クライアントアプリケーションによって提供されるアプリケーションプロフィール内のコンテンツタイプ属性と、コンテンツ項目のメタデータ内のコンテンツタイプ属性との間のパターン対応付けを用いて行われ得る。

本開示においては、ＤＣＤ対応クライアントアプリケーションは、広告クライアント１１０であり、従って、広告アプリケーション１２０から１２２までの加入を要求し、加入フィルタを提供する複雑性を除去し、代わりに広告アプリケーションを広告クライアント１１０に置き代える。

代替の実施形態において、一般的なデータファサードとしてのＤＣＤイネーブラ１４２の代わりに、シンプルオブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ；ＳＯＡＰ）または表示状態転送（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ；ＲＥＳＴ）などのＸＭＬウェブサービス（ＷＳ）がデバイスクライアントとなる。アプリケーションコールおよびメッセージを、出てゆくＳＯＡＰメッセージへと解釈し、そして入ってくるＳＯＡＰメッセージをアプリケーションコール／メッセージへと解釈することによって、デバイスアプリケーションに対してゲートウェイとして役立つＳＯＡＰクライアントはまた、データファサードと考えられ得る。そのようなＳＯＡＰクライアントは、加入フィルタを含む加入モデルをサポートし得る。そのような加入モデルの例は、ＷＳ−イベント化（ＷＳ−Ｅｖｅｎｔｉｎｇ）およびＷＳ−通知（ＷＳ−Ｎｏｔｉｆｉｃａｔｉｏｎ）を含む。

ＲＥＳＴプロトコルを介するサーバ側データへのデバイスアプリケーションのアクセスを容易にするウェブサービスクライアントに対して、ＲＥＳＴクライアントはまた、データファサードとして考えられ得、ＲＥＳＴ／ＨＴＴＰ（ハイパーテキスト転送プロトコル）要求のユニフォームリソースロケータ（ＵＲＬ）属性は、加入フィルタへのパラメータに類似する。

さらに、本明細書中に用いられるときに、「加入フィルタ」は、任意のフォーマットまたはプロトコルであり得る。一実施形態において、加入フィルタは、プリファレンスのテキストストリングと同じくらい単純であり得る。他の実施形態において、加入フィルタは、ＨＴＴＰ要求におけるオーバーロードされたＵＲＬ（ｏｖｅｒｌｏａｄｅｄ ＵＲＬ）であり得る。「加入」は、サーバから配信されるデータのサブセットに対してプリファレンスを提供することを伴う、データクライアントとデータサーバとの間の任意の相互作用である。加入は、永く（例えば、配信チャネルまたはセッションの継続時間ごと）存続するか、または短く（例えば、ＲＥＳＴの場合におけるような単一の要求ごと）存続し得る。

図１において、広告ストレージ１５０は、広告のための保管場所としてＤＣＤクライアント１３０によって用いられ得、それは次いで、広告クライアント１１０によって取り出され得る。代替の実施形態において、ＤＣＤクライアント１３０は、広告を広告クライアント１１０に直接的に渡し得る。

ここで図２を参照する。図２において、同様な参照数字が、同様な要素を例示するために、図１の参照数字と同じように用いられる。図２の実施形態は、同報通信を含むプッシュベースの広告の配信または広告の利用可能性の通知に対するデータフローを示す例である。以下で示されるように、プルベースのモデルもまた用いられ得る。

図２のデータフローは、メッセージ２１０を用いて、ＤＣＤイネーブラ１４２による広告クライアント１１０の登録によって始動する。この方法において、広告クライアント１１０は、ＤＣＤ対応のクライアントアプリケーションとなる。他の実施形態において、広告クライアント１１０は、データファサードによって登録するのではなくデータファサードと関連し得る。

広告クライアント１１０はさらに、メッセージ２１２を用いて、広告チャネルの選択に加入し、それらの広告チャネルから関心のあるコンテンツを取得するために、メッセージ２１４において加入フィルタを提示する。

メッセージ２１４において提供される「一般的な」または「統合された」加入フィルタは、ＤＣＤイネーブラに対して不透明であり、図１のモバイル広告サーバプラットホーム１６０に渡され、モバイル広告サーバは次いで、加入フィルタ内に含まれる情報に従って広告選択のパーソナル化を実行し得る。メッセージ２１４において提供される一般的な加入フィルタは、広告クライアント１１０が、様々なトピック、カテゴリまたはフォーマットに対応する広告を受信するように十分に広範である。このことは、広告クライアント１１０が、様々な広告アプリケーション１２０または１２２に対して適切な広告を受信することを可能にする。一実施形態において、関心のある広告は、広告チャネル加入および加入フィルタ提示の時点においてインストールすらされていないことが有り得る広告アプリケーションに関連し得る。

メッセージ２１４の一般的な加入フィルタは、様々なパラメータを含み得る。一実施形態において、そのようなパラメータは、ユーザの関心を含み得る。ユーザの関心は、コンテンツの走査から引き出され得、コンテンツタイプまたはカテゴリを含み得る。例えば、ユーザが様々なスポーツに関心があり、スポーツのスコアの供給に加入している場合には、このことがユーザの関心を暗示し得、そしてスポーツ関連広告が携帯型デバイスに提供され得る。ユーザの関心が自動車レースだけに関連する場合には、これはさらに限定され得、自動車レースに関連した広告だけに対してフィルタをかけられたスポーツ広告をもたらす。関心の他の例としては、特に様々なタイプの音楽を含み得る。

用いられ得る第二のパラメータは、ユーザの配信プリファレンスである。このパラメータは、特に、配信の頻度、配信のスケジュール、配信がローミングするときに起こるべきであるか否かに対するプリファレンスを含み得る。例えば、ユーザは、ローミング料金を避けるために、ローミングする間、広告の配信を受けないことを望み得る。さらに、ユーザは、勤務時間の間に、デバイスにプッシュされる広告を受けることによって邪魔されたくないことがあり得、従って、広告が夕方の特定の時間にデバイスにプッシュされるか、またはデバイスからプルされるだけに制限し得る。

第三のパラメータは、動的または擬似動的なユーザのコンテキストを含み得る。そのようなコンテキストは、特に位置情報、プレゼンス（ｐｒｅｓｅｎｃｅ）情報を含む。従って、広告は、ユーザの位置情報とユーザのプレゼンス情報とに関連し得る。プレゼンス情報は、特に可能性として、ユーザが利用可能か、会議中か、忙しいかに関連している。

第四のパラメータは、言語プリファレンスを含み得る。ユーザは、英語ではなくフランス語だけで広告を受信することを望み得る。

第五のパラメータは、広告のフォーマットプリファレンスを含み得る。特定のアプリケーションは、ＪＰＥＧフォーマットだけの広告を必要とし得るのに対して、他は特に、バナー広告、スプラッシュ（ｓｐｌａｓｈ）広告、リッチメディア広告、およびすき間（ｉｎｔｅｒｓｔｉｔｉａｌ）広告を必要とし得る。

さらなるパラメータは、デバイス特性を含み得る。そのような特性は、特に、デバイスの画面サイズまたはデバイスの画面能力、マルチメディア能力、広告を表現するために利用可能なアプリケーションに従ってフォーマットされた広告を含む。

さらなるパラメータは、サポートされるメディアタイプであり得る。従って、ビデオは、特定のデバイス上でサポートされないことがあり得る。

さらなるパラメータは、サポートされるコンテンツタイプであり得る。これらのコンテンツタイプは、アプリケーションが関心のあるコンテンツタイプに対する一般的なタグまたはトークンであり、広告のフォーマットプリファレンスを決定するために用いられ得る。

上記パラメータは、単独または他のパラメータとの組み合わせにおいて用いられ得る。上記パラメータのリストは、網羅的ではなく、他のパラメータが、広告チャネル加入の選択および加入フィルタの提示に対してあり得る。

一旦広告および関連するコンテンツが広告プラットホームによって提供されると、データファサードは、広告および関連するコンテンツを対応する広告クライアント１１０に対して直接的に配信するか、または広告および関連するコンテンツを広告ストレージ１５０内に格納する。このストレージ領域１５０は、広告クライアント１１０またはＤＣＤクライアント１３０などのデータファサードによって管理され得る。ストレージ領域１５０はまた、デバイスのデータベースなどの共有ストレージであり得る。

メッセージ２１６において提供される広告が、データファサードによるプッシュまたは自動的取り出しの結果としてデバイス上に事前にフェッチされるか、または格納され得る関心のあるサブセットを提供し得る一方で、広告クライアント１１０は、広告要求に含まれるパラメータに従って検索結果をさらに限定し得る。そのような広告要求は、メッセージ２２０として受信され、上記パラメータなどのパラメータを含み得る。このことに基づいて、メッセージ２２２によって示されるように、広告選択が広告ストレージ１５０から起こり得、そして広告または複数の広告が、メッセージ２３０として広告アプリケーション１２０に提供される。

上記の利益は、広告の領域と配信の領域との明確な分離である。広告アプリケーションは、データファサードに気づいておらず、インターフェイスを用いて広告クライアント１１０に対して広告要求を行う。広告クライアント１１０は、必要に応じて、一般的な加入フィルタを提供することを含む登録プロセスに関係するものであり、そしてデータアクセスの詳細を広告アプリケーション１２０から隠し得る。広告クライアント１１０は、デバイス上の広告操作機能と広告選択機能とを統合する。

広告クライアント１１０はまた、コンテンツまたは広告の消費パラメータに基づいて、一般的な加入フィルタを動的にアップデートし得る。従って、加入フィルタは、アプリケーションの広告の用い方に依存して、より適切であるように作られ得る。例えば、広告をより頻繁に表示する特定のアプリケーションの使用、アプリケーションによって提供される関心のあるトピック、アプリケーションからの広告要求パラメータ、または他のパラメータが、修正された一般的な加入フィルタを作り出すために用いられ得る。

広告クライアントはまた、特定の動的条件の下で広告配信を修正するために、加入フィルタを動的にアップデートし得る。このことは、事前に規定された基準に基づくか、またはなんらかのしきい値が満たされるときに行われ得る。例えば、デバイスのメモリが特定のしきい値を下回る場合には、デバイスは、広告がデバイスにプッシュされること、そして広告ストレージ１５０内に格納されることを望まないことがあり得る。この場合において、一般的な加入フィルタが、メッセージ２４０において、受信される広告を制限するようにアップデートされ得る。

動的条件の他の例は、デバイス資源のしきい値を含み得る。例えば、デバイスのバッテリレベルがしきい値を下回り、従って広告を提供するためのデータ交換がバッテリを消耗させ得、悪いユーザ経験をもたらすことになり、広告者は、このことを望まないことがあり得、従って広告のプッシュまたはプルを制限する。

アップデートされた加入フィルタをもたらし得るさらなる動的条件は、プレゼンスステータスである。例えば、ユーザが会議に入り、ユーザのプレゼンスが忙しいとして示される場合に、広告は、ダウンロードされることから制限され得る。

アップデートされた加入フィルタをもたらし得るさらなる動的条件は、位置の変化である。ユーザがローミングするときに、このことは、ユーザが負担することを望まないことがあり得る追加料金をもたらし得、そして広告は、ローミングするときに制限され得る。

上記は網羅的ではなく、一般的な加入フィルタの変更を可能にする他の動的条件が存在し得る。

上記の図１および図２に基づき、加入フィルタは、ユーザ、デバイスまたは広告アプリケーションのプリファレンスに従って、加入された広告チャネルから受信される広告コンテンツをパーソナル化するために用いられる。これらの場合において、データファサードは、コンテンツ加入と、従って関心のある広告チャネルとを維持する。さらに、モバイル広告サーバは、広告を提供するときに加入フィルタを処理し得る。

プルモデルにおいては、図１および図２のデータフローは、適切な広告を戻すために、以前に提示された加入フィルタをＤＣＤイネーブラ１４２に適用させることによって変化する。

ここで、広告空間の図を示す図３を参照する。外側の円３１０は、サーバ側において利用可能なすべての広告を示す。

これのサブセットが円３１２によって示され、該サブセットは、広告クライアント１１０によって提供された加入フィルタのパラメータに対応する広告を例示する。

円３１４は、広告アプリケーション１２０からの広告要求のパラメータに対応付けられる広告のサブセットを示す。円３１４内の広告は、広告応答として広告アプリケーション１２０に戻される広告である。あるいは、円３１４における広告は、リンクまたは参照として広告アプリケーション１２０に提供され得、その時点において、広告アプリケーション１２０は、ストレージ１５０から広告を取り出し得る。

上記の使用の例は、複数のアプリケーションを含む携帯型デバイスであり得る。そのようなアプリケーションは、例えば、投資のポートフォリオマネージャ、音楽プレーヤ、ウェブブラウザおよびＥメールアプリケーションを含み得る。これらのアプリケーションのそれぞれは、広告を表示することを可能にされる。

アプリケーションは、特定のアプリケーションに対する広告を取得するために、携帯型デバイス上の広告クライアントと通信する。例えば、音楽プレーヤアプリケーションは、音楽の選択を再生する前に挿入される、オーディオフォーマットだけの広告を要求し得る。逆に、投資ポートフォリオマネージャは、画面の最下部においてＪＰＥＧフォーマットのバナー広告を配置するためのスペースを有し得る。ウェブブラウザは、短いビデオクリップが広告として再生されることを可能にし得る。

図１および図２のアーキテクチャおよびデータフローを利用して、広告クライアントは、データファサードによって登録するか、またはデータファサードと関連する。データファサードがＤＣＤクライアントである場合において、広告クライアントは、ＤＣＤ対応アプリケーションとなる。広告アプリケーションは次いで、一般的な加入フィルタを用いて、ＤＣＤイネーブラに対する様々な広告チャネルに加入し得る。

特に、一般的な加入フィルタは、金融サービス、音楽サービスそしておそらくスポーツ関連広告に関する広告などの広告チャネルの選択を含み得る。一般的な加入フィルタはまた、ＪＰＥＧ、オーディオまたはビデオフォーマットを含むいくつかのフォーマットのうちの１つにおいて広告が要求されることを提供し得る。

一般的な加入フィルタに基づいて、広告サーバは、フィルタ内の基準に対応付けられる広告を戻す。

ユーザがアプリケーションのうちの１つを始動するときに、広告要求が広告クライアントに提供される。従って、音楽プレーヤが始動されるときに、音楽プレーヤは広告を要求し得る。広告クライアントは次いで、動的に広告を要求するか、または音楽プレーヤに対する基準を満たす広告のためのストレージ位置において閲覧し得る。

動的なフィルタリングもまた起こり得る。例えば、音楽プレーヤに適切な広告の一部が、音楽を販売する店舗に関連する場合には、広告クライアントは、携帯型デバイスの位置とそれが店舗に近いこととに基づいて、広告を選択し得る。

広告クライアントは、広告応答という形で適切な広告を音楽プレーヤに戻し、そしてある時点において、音楽プレーヤは、ユーザに対して広告を再生することによって広告を消費する。広告クライアントはまた、広告の消費を追跡し、そして請求目的のために、広告サーバに戻す量を提供し得る。

（個別化された加入（Ｉｎｄｉｖｉｄｕａｌｉｚｅｄ Ｓｕｂｓｃｒｉｐｔｉｏｎｓ））
代替の実施形態において、広告クライアントは、各広告アプリケーションに対して加入フィルタを要求し得る。ここで図４を参照する。図１の実施形態と同様に、図４の実施形態において、広告アプリケーションは、データファサードに気づいておらず、広告要求を広告クライアント４１０に送信する。広告クライアント４１０は、広告を取得するために、データファサードとともに作業する。図４の例において、データファサードは、ＤＣＤクライアント４２２またはＤＣＤサーバ４２４である。ＤＣＤクライアント４２２およびＤＣＤサーバ４２４は、ＤＣＤイネーブラ４２０を形成する。ＳＯＡＰまたはＲＥＳＴデバイスクライアントなどの他のデータファサードが同様に用いられ得る。

広告アプリケーション４３０、４３２および４３４としてラベルを付けられた複数の広告アプリケーションは、広告クライアント４１０に広告要求を提供し、応答において、広告応答を受信し得る。

図４の実施形態において、各広告アプリケーション４３０、４３２、４３４に対して広告クライアントは、対応する加入フィルタをさらに規定し、加入フィルタをデータファサードに提供する。ここでまた、本明細書中に用いられるときに、「加入フィルタ」は、任意のフォーマットまたはプロトコルであり得る。一実施形態において、加入フィルタは、プリファレンスのテキストストリングと同じくらい単純であり得る。他の実施形態において、加入フィルタは、ＨＴＴＰ要求におけるオーバーロードされたＵＲＬであり得る。「加入」は、サーバから配信されるデータのサブセットに対してプリファレンスを提供することを伴う、データクライアントとデータサーバとの間の任意の相互作用である。加入は、永く（例えば、配信チャネルまたはセッションの継続時間ごと）存続するか、または短く（例えば、ＲＥＳＴの場合におけるような単一の要求ごと）存続し得る。

従って、例えば、広告アプリケーション４３０が携帯型デバイスにインストールされた投資ポートフォリオである場合には、広告クライアント４１０は、特に、株式相場または株式監視（ａｌｅｒｔ）、金融ニュース、金融ツールまたはセミナーに関連した広告への関心を表現する加入フィルタを提示する。

逆に、広告アプリケーション４３２が音楽プレーヤアプリケーションである場合には、広告アプリケーション４３２は、特に、新しいＣＤ、地元のコンサート、フェスティバルの広告に対する加入フィルタをもたらし得る。

一実施形態において、加入フィルタはまた、アプリケーションによって消費されたコンテンツおよび／または要求された広告に基づき、動的にカスタマイズされ得る。本明細書中に用いられるときに、アプリケーションによるコンテンツ消費は、アプリケーションによるデータの使用を意味する。従って、例えば、投資ポートフォリオの管理アプリケーションに対するコンテンツ消費は、株価チッカー（ｔｉｃｋｅｒ）または株式相場の表示であり得、また音楽プレーヤに対するコンテンツ消費は、音楽ファイルのオーディオ出力であり得る。動的なカスタマイズは、音楽の特定のタイプ、携帯型デバイスのユーザの位置に近い音楽店舗、または近いファイナンシャルプランナーなどに対する広告をもたらし得る。

広告クライアント４１０は、広告アプリケーション４３０などの広告アプリケーションを、アプリケーション４３０に対する加入フィルタからの広告プリファレンスに対応する加入識別子にマッピングする。広告クライアント４１０は、広告アプリケーション対加入識別子の双方向のマッピングを維持する。

広告が、広告サーバ４５０によって加入フィルタに対応付けられ、そして携帯型デバイスに利用可能にされるときに、広告は、データファサードによって広告クライアント４１０に提供され、そして適切な加入識別子を含む。広告クライアント４１０は次いで、広告のグループに対し、その広告に対するターゲットアプリケーションを識別するために、広告アプリケーション４３０に対する加入識別子のマッピングを用いる。

次に、広告クライアント４１０は、携帯型デバイス上の、アプリケーション提供の基準またはユーザ提供の基準または事前に構成された基準などの基準に従い、追加のフィルタリングによって広告に対する選択をさらに改良し得る。

ストレージ４４０がデバイス上に提供され、そしてＤＣＤクライアント４２２は、広告をストレージ領域４４０に書き込み得、広告は、広告クライアント４１０によって取り出され得る。他の実施形態において、ＤＣＤクライアント４２２は、広告を直接的に広告クライアント４１０に提供し得る。さらなる代替の実施形態において、アプリケーション４３４などの高機能な広告アプリケーションは、例えば、広告クライアント４１０によってリンクを提供される場合には、広告を直接的に共有ストレージから取り出し得る。広告の直接取り出しは、ストレージ領域へのリンクを伴う、またはストレージ領域４４０内の広告に対する識別子を伴う広告応答を有することによって容易にされる。他の実施形態において、パーティションが、加入識別子に対してストレージ領域４４０内に存在し得、加入識別子に対応する広告アプリケーションは、そのパーティションを通知される。

ここで図５を参照する。図５は、図４の構成基盤に対するデータフロー図を提供する。特に、広告アプリケーション４３０は、広告クライアント４１０と通信する。さらに、ストレージ４４０は、広告クライアント４１０からか、またはＤＣＤイネーブラ４２０などのデータファサードによってアクセス可能である。

メッセージ５１０において、広告クライアント４１０は、ＤＣＤイネーブラ４２０によって登録するか、またはＤＣＤイネーブラ４２０と関連する。このプロセスは、図２のメッセージ２１０の登録に類似している。

広告クライアント４１０は次いで、メッセージ５１２において、ＤＣＤイネーブラ４２０によって加入する。

１つ以上の広告アプリケーションが、広告クライアント４１０と通信する。本開示は、特定の数の広告アプリケーションに制限されることを意図されない。

メッセージ５２０において、広告クライアント４１０は、登録されたかまたは広告クライアント４１０と通信する各広告アプリケーション４３０のための加入フィルタを提供する。このことは、単一のメッセージにおいて行われ得る。あるいは、複数のメッセージ５２０が、各広告アプリケーションに対する加入フィルタを提供するために、広告クライアント４１０とＤＣＤイネーブラ４２０との間に提供され得る。一実施形態において、別個のメッセージ５２０が、広告クライアント４１０と通信する各広告アプリケーションのために送信され得る。

ＤＣＤイネーブラ４２０は、各広告アプリケーションに対する加入フィルタを受信し、そしてメッセージ５２２において、各広告アプリケーションに対する加入識別子を広告クライアント４１０に戻るように提供する。ここでまた、メッセージ５２２は、広告アプリケーションに対するすべての加入識別子を有する単一のメッセージであり得るか、または複数のメッセージに分割され得る。

ある時点において、広告クライアント４１０からの要求に基づいてか、または広告サーバ（図示されない）からの情報に基づいて、ＤＣＤイネーブラ４２０は、加入識別子に対する広告を提供する。その広告は、図５の例示的な実施形態において、メッセージ５３０によって示されるようにストレージ４４０に書き込まれる。

広告アプリケーション４３０が、続いて作動し、メッセージ５４０において、広告クライアント４１０からの広告を要求する。広告クライアント４１０は、メッセージ５４２によって示されるように、広告ストレージ４４０から広告を選択する。

メッセージ４４２による広告の選択は、広告ストレージ４４０内にある広告の動的なフィルタリングを含み得る。例えば、どのような広告を提供するかなどの動的な規則は、特に、デバイス資源、デバイスのローミングステータス、デバイスのプレゼンス情報に基づいており、特定の加入識別子に対して提供される広告を介してフィルタするために利用され得る。

メッセージ５４４において、広告は、広告アプリケーション４３０に戻るように提供される。あるいは、ストレージ領域へのリンクが、メッセージ５４４を介して提供され得る。広告アプリケーション４３０は次いで、広告を取り出すために、ストレージ４４０に直接的に向かい得る。

図４および図５のモデルは、データファサードと広告クライアント４１０との間で広告をプッシュするか、またはプルするために用いられ得る。本明細書中におけるプッシュおよびプルのシナリオの使用は、図４のＤＣＤクライアント４２２とＤＣＤサーバ４２４との間ではなく、イネーブラ４２０と広告クライアント４１０との間でプッシュまたはプルすることを表す。従って、例えば、ＤＣＤクライアント４２２は、スケジューリングされた広告のプルをＤＣＤサーバ４２４から行い得るけれども、デバイス上で、ＤＣＤクライアント４２２は、広告を広告クライアント４１０にプッシュし得る。本開示において、このことは、プッシュシナリオであると考えられる。プルシナリオのために、広告アプリケーション４３０は、広告クライアント４１０に広告要求を行う。広告クライアント４１０は、広告アプリケーションに対応する加入識別子を捜し、そしてその加入識別子をデータファサードに対する広告要求に挿入する。あるいは、そのような要求は、広告アプリケーション４３０からの事前の広告要求を伴うことなく、広告クライアント４１０自体によって起動され得る。このことは、例えば、事前に規定されたスケジュールの結果としてもたらされ得る。

図４の広告サーバ４６０は、広告の加入フィルタに従って、加入識別子に対して広告選択を行い、ＤＣＤイネーブラ４２０などのデータファサードを介して選択された広告を戻す。広告クライアント４１０は次いで、これらの広告を適切な広告アプリケーションに戻すか、または共有メモリまたはストレージ内に広告を格納する。広告は、広告クライアント４１０によってさらにフィルタをかけられ得る。

プッシュシナリオにおいて、広告クライアント４１０は、加入識別子と関連づけられる広告をデータファサードから取得する。この場合において、データファサードと配信サーバとの間の配信メカニズムは関連性がなく、プッシュ、プルまたは同報通信であり得る。

広告クライアント４１０は、加入識別子を対応する広告アプリケーションに対応付け、そして広告クライアント４１０は次いで、広告を広告アプリケーションにプッシュしたり、広告を広告アプリケーションに通知したり、広告アプリケーションが広告を要求することを待機したり、広告を共有ストレージ４４０内に格納したりする。格納された広告は、次いで広告アプリケーションによってアクセスされ得る。

広告クライアント４１０は、所与の広告アプリケーションに対する加入フィルタのパラメータを様々な手段によって決定し得る。情報は、広告アプリケーション自体によってか、または広告アプリケーションに代わり作用するなんらかの他の作用子によって提供され得る。このことは、導入、構成または登録のときに行われ得る。あるいは、特定の広告アプリケーションのための加入フィルタに対する情報は、広告アプリケーションのデータをスクリーニングすることによって引き出され得る。

さらに、広告アプリケーションと加入識別子との間で一対一に対応付ける代わりに、複数の広告アプリケーションが、同様な加入フィルタの作成につながる同一または同様な特性を有する場合には、広告クライアント４１０は、２つ以上の広告アプリケーションを単一の加入識別子にマッピングすることを決定し得る。従って、２つ以上の広告アプリケーションが加入識別子を共有し得る一方で、他の広告アプリケーションは、異なる加入識別子を有し得、これは、広告アプリケーションと加入フィルタとの間の「Ｍ対Ｎ」マッピングと呼ばれる。

広告のためのストレージは、加入識別子に関してパーティション化され得る。従って、データファサードが特定の加入識別子に対する広告を受信したときには、データファサードは、その広告をその加入識別子のための領域に格納する。広告クライアント４１０は、加入識別子に対する広告を取り出し、必要に応じて、広告を適切なアプリケーションに提供し得る。あるいは、広告アプリケーションは、適切な広告を選択するために、加入識別子に基づいてストレージを閲覧し得る。広告アプリケーションに対応する加入識別子のためのストレージ領域のアドレスは、広告クライアント４１０によって提供され得るか、あるいは広告アプリケーションまたはデータファサードによって事前に割り当てられるかまたは管理され得る。

さらに、図４および図５の実施形態において、加入フィルタの動的なアップデートおよび加入フィルタのパラメータの動的なアップデートもまた適用可能である。従って、広告アプリケーションが、１つの目的のために用いられる傾向があり、別の目的ではない場合には、広告アプリケーションに対する加入フィルタまたはその加入フィルタ内のパラメータは、動的に修正され得、その加入識別子に対する修正された加入フィルタを提供する新しいメッセージが、イネーブラ４２０または任意の他のデータファサードに提供され得る。上記に基づいて、図４および図５の実施形態は、広告サーバ４６０において広告選択のための加入フィルタを作り出すために、アプリケーションプリファレンスを用いる広告クライアント４１０を提供する。加入識別子は、各加入フィルタに対して作り出され、そして広告アプリケーションは、加入識別子と関連づけられる。広告クライアント４１０は、広告アプリケーションと加入識別子とのマッピングを維持する。

ここで図６を参照する。図６は、広告空間を例示する図を示す。

図６において、サーバ側において利用可能なすべての広告が、円６１０によって表示される。

特定の加入フィルタに対応する様々な広告のサブセットが示される。図６の例において、特定の加入フィルタに対応する広告のサブセットが、第一の加入フィルタに対する円６１２と、第二の加入フィルタに対する円６１４として示される。

円６２０によって示されるように、円６１２の第一の加入フィルタに対する広告のサブセットが、円６２０によって示される。この広告のサブセットは、広告アプリケーションからの広告要求のパラメータに対応し、従って、広告自体としてかまたは携帯型デバイス上のストレージ領域へのリンクとして広告アプリケーションに戻される。

上記の例は、音楽プレーヤ、ポートフォリオマネージャ、ブラウザおよびＥメールアプリケーションを有する携帯型デバイスの使用例である。これらのアプリケーションのそれぞれは、広告を消費することが可能であり、広告クライアントに対して広告要求を行う。

広告クライアントは、ＤＣＤイネーブラなどのデータファサードによって登録するか、またはデータファサードと関連する。ＤＣＤイネーブラの場合において、広告クライアントは、ＤＣＤ対応アプリケーションとなる。

広告クライアントは、ＤＣＤイネーブラに加入し、さらに、加入フィルタを音楽プレーヤ、ポートフォリオマネージャ、ブラウザおよびＥメールアプリケーションのそれぞれに対して提供する。各加入フィルタは、特定のアプリケーションに対してカスタマイズされる。従って、音楽プレーヤに対する加入フィルタは、音楽関連の広告のための広告チャネルに加入し得る。広告をオーディオの広告に制限するなどのパラメータがまた、加入フィルタにおいて提供され得る。

加入識別子は、各アプリケーションに対して戻される。従って、音楽プレーヤは、ブラウザアプリケーションと別個の加入識別子を有する。マッピングが、加入識別子を特定のアプリケーションとマッピングするために、広告クライアント上で行われ得る。

その後、広告が携帯型デバイスに提供されるときに、データファサードは、加入識別子を広告に付加し得る。広告クライアントは次いで、広告を特定のアプリケーションにマッピングし、それから広告を特定のメモリ位置において格納し得る。

例えば、音楽アプリケーションが広告を要求するときには、広告クライアントは、広告の動的なフィルタリングをさらに提供し、広告を音楽プレーヤアプリケーションに提供し得る。あるいは、広告クライアントは、広告または共有ストレージスペースへのリンクを提供し得る。さらなる実施形態において、音楽プレーヤアプリケーションは、アプリケーションのためのパーティション化されたストレージ領域を提供され得、そこにおいて音楽プレーヤアプリケーションは、適切な広告を見出し得る。

広告クライアントはさらに、ストレージ領域における広告が失効していないことを保証することによって、そして失効したそれらの広告を削除することによって、このストレージ領域を管理し得る。

一例示的な携帯型デバイスが、図７に関して以下に記載される。このことは、制限することを意図されないけれども、例示目的のために提供される。

図７は、本願の装置および方法の好適な実施形態によって用いられることが適切な携帯型デバイスを例示するブロック図である。携帯型デバイス７００は好ましくは、少なくとも音声およびデータ通信能力を有する双方向の無線通信デバイスである。携帯型デバイス７００は好ましくは、インターネット上の他のコンピュータシステムと通信する能力を有する。提供される正確な機能性に依存して、無線デバイスは、例として、データメッセージングデバイス、双方向ポケットベル、無線Ｅメールデバイス、データメッセージング機能を有するセルラ電話、無線インターネット家電、またはデータ通信デバイスと呼ばれ得る。

携帯型デバイス７００が双方向通信に対して可能にされる場合には、携帯型デバイス７００は、受信器７１２と送信器７１４との両方を含む通信サブシステム７１１、および１つ以上の、好ましくは埋め込み型または内部型であるアンテナ要素７１６および７１８、局部発振器（ＬＯ）７１３、そしてデジタルシグナルプロセッサ（ＤＳＰ）７２０などの処理モジュールなどの関連する構成要素を組み込む。通信分野の当業者に明らかであるように、通信サブシステム７１１の特定の設計は、デバイスが動作することを意図される通信ネットワークに依存する。

ネットワークアクセスの要件もまた、ネットワーク７１９の種類によって変わる。一部のＣＤＭＡネットワークにおいて、ネットワークアクセスは、携帯型デバイス７００の加入者またはユーザと関連づけられる。ＣＤＭＡ携帯型デバイスは、ＣＤＭＡネットワーク上で動作するために、取り外し可能なユーザ識別モジュール（ＲＵＩＭ）または加入者識別モジュール（ＳＩＭ）カードを必要とし得る。ＳＩＭ／ＲＵＩＭインターフェイス７４４は通常、ＳＩＭ／ＲＵＩＭカードがディスケットまたはＰＣＭＣＩＡカードのように挿入され、そして取り出され得るカードスロットに類似している。ＳＩＭ／ＲＵＩＭカードは、約６４Ｋのメモリを有し、多くの重要な構成７５１と、識別および加入者関連の情報などの他の情報７５３とを保持し得る。

必要とされるネットワーク登録または起動手順が完了されると、携帯型デバイス７００は、ネットワーク７１９を介して通信信号を送信および受信し得る。図７に例示されるように、ネットワーク７１９は、携帯型デバイスと通信する複数の基地（ｂａｓｅ）デバイスからなり得る。例えば、ハイブリッドＣＤＭＡ １ｘ ＥＶＤＯシステムにおいて、ＣＤＭＡ基地デバイスおよびＥＶＤＯ基地デバイスは、携帯型デバイスと通信し、そして携帯型デバイスは、両方に対して同時に接続される。ＥＶＤＯおよびＣＤＭＡ １ｘ基地局は、携帯型デバイスと通信するために、異なるページングスロットを用いる。

通信ネットワーク７１９を介してアンテナ７１６によって受信された信号は、受信器７１２に入力され、受信器７１２は、信号増幅、周波数ダウンコンバージョン、フィルタリング、チャネル選択などのような共通の受信器機能、および図７において示されたシステム例においては、アナログ−デジタル（Ａ／Ｄ）変換を実行し得る。受信された信号のＡ／Ｄ変換は、復調および復号化などのより複雑な通信機能が、ＤＳＰ７２０において実行されることを可能にする。同様な方法で、送信される信号は、ＤＳＰ７２０によって、例えば、変調および符号化を含む処理が行われ、デジタル−アナログ変換、周波数アップコンバージョン、フィルタリング、増幅、そしてアンテナ７１８を介して通信ネットワーク７１９上に送信するために送信器７１４に入力される。ＤＳＰ７２０は、通信信号を処理するだけでなく、受信器および送信器の制御を提供する。例えば、受信器７１２および送信器７１４内の通信信号に適用される利得は、ＤＳＰ７２０内に実装された自動利得制御アルゴリズムを介して適応的に制御され得る。

携帯型デバイス７００は好ましくは、デバイス全体の動作を制御するマイクロプロセッサ７３８を含む。少なくともデータおよび音声通信を含む通信機能は、通信サブシステム７１１を介して実行される。マイクロプロセッサ７３８はまた、ディスプレイ７２２、フラッシュメモリ７２４、ランダムアクセスメモリ（ＲＡＭ）７２６、補助の入力／出力（Ｉ／Ｏ）サブシステム７２８、シリアルポート７３０、１つ以上のキーボードまたはキーパッド７３２、スピーカ７３４、マイクロホン７３６、短距離の通信サブシステムなどの他の通信サブシステム７４０、および概して７４２と呼ばれるすべての他のデバイスサブシステムなどの、さらなるデバイスサブシステムと相互作用する。シリアルポート７３０は、ＵＳＢポートまたは当業者に公知の他のポートを含み得る。

図７に示されたサブシステムの一部が、通信関連の機能を実行するのに対して、他のサブシステムは、「常駐」またはオンデバイスの機能を提供し得る。例えば、キーボード７３２およびディスプレイ７２２などの、特に一部のサブシステムは、通信ネットワークを介する送信のためのテキストメッセージを入力することなどの通信関連の機能と、計算器またはタスクリストなどのデバイス常駐機能との両方のために用いられ得る。

マイクロプロセッサ７３８によって用いられるオペレーティングシステムソフトウェアは好ましくは、フラッシュメモリ７２４などの永続性のストア（ｓｔｏｒｅ）において格納され、フラッシュメモリは、代わりに、読み出し専用メモリ（ＲＯＭ）または同様なストレージ要素（図示されない）であり得る。当業者は、オペレーティングシステム、特定のデバイスアプリケーション、またはそれらの一部分が、ＲＡＭ７２６などの揮発性メモリへと一時的にロードされ得ることを理解する。受信された通信信号もまた、ＲＡＭ７２６において格納され得る。

示されるように、フラッシュメモリ７２４は、コンピュータプログラム７５８と、プログラムデータストレージ７５０、７５２、７５４および７５６との両方に対して、異なる領域へと分離され得る。これらの様々なストレージタイプは、各プログラムがフラッシュメモリ７２４の一部分を、プログラム自体のデータのストレージ要件に対して割り当て得ることを示している。マイクロプロセッサ７３８は、そのオペレーティングシステム機能に加えて、好ましくは携帯型デバイス上のソフトウェアアプリケーションの実行を可能にする。例えば、少なくともデータおよび音声通信アプリケーションを含む基本の動作を制御するアプリケーションの所定の組は、製造の間に携帯型デバイス７００上に通常はインストールされる。他のアプリケーションは、後でインストールされるかまたは動的にインストールされ得る。

好適なソフトウェアアプリケーションは、携帯型デバイスのユーザに関連するデータ項目を組織し、そして管理する能力を有する個人情報マネージャ（ＰＩＭ）アプリケーション（例えば、これらに限定はされないが、Ｅメール、カレンダイベント、ボイスメール、アポイントメント、およびタスク項目）であり得る。もちろん、１つ以上のメモリストアが、ＰＩＭデータ項目のストレージを容易にするために、携帯型デバイス上において利用可能である。そのようなＰＩＭアプリケーションは好ましくは、無線ネットワーク７１９を介してデータ項目を送信および受信する能力を有する。好適な実施形態において、ＰＩＭデータ項目は、無線ネットワーク７１９を介して、ホストコンピュータシステムに格納されるかまたはそれと関連づけられる、携帯型デバイスユーザの対応するデータ項目とシームレスに統合され、同期され、そしてアップデートされる。さらなるアプリケーションもまた、ネットワーク７１９、補助のＩ／Ｏサブシステム７２８、シリアルポート７３０、短距離の通信サブシステム７４０または任意の他の適切なサブシステム７４２を介して携帯型デバイス７００上にロードされ、マイクロプロセッサ７３８による実行のために、ＲＡＭ７２６または好ましくは不揮発性のストア（図示されない）内にユーザによってインストールされ得る。アプリケーション導入におけるそのような柔軟性は、デバイスの機能性を増大させ、向上されたオンデバイスの機能、通信関連の機能、またはそれらの両方を提供し得る。例えば、セキュアな通信アプリケーションは、電子商取引機能および他のそのような金融取引が、携帯型デバイス７００を用いて実行されることを可能にし得る。

データ通信モードにおいて、テキストメッセージまたはダウンロードされたウェブページなどの受信された信号は、通信サブシステム７１１によって処理され、マイクロプロセッサ７３８に入力される。マイクロプロセッサ７３８は好ましくは、ディスプレイ７２２または代わりに補助のＩ／Ｏデバイス７２８に出力するために受信された信号をさらに処理する。

携帯型デバイス７００のユーザはまた、例えば、Ｅメールメッセージなどのデータ項目を、キーボード７３２を用いて作り出し得る。キーボード７３２は好ましくは、ディスプレイ７２２および可能性としては補助のＩ／Ｏデバイス７２８と連携する、完全な英数字キーボードまたは電話タイプのキーパッドである。そのような作り出された項目は次いで、通信サブシステム７１１を介して通信ネットワーク上に送信され得る。

広告クライアント１１０または４１０と等価であり得る広告クライアント７６０が、携帯型デバイス７００上の広告を管理するために用いられ得る。

音声通信に対して、携帯型デバイス７００の全体の動作は、受信された信号が好ましくはスピーカ７３４に出力され、送信のための信号がマイクロホン７３６によって生成されることを除いて、同様である。音声メッセージ記録サブシステムなどの代替の音声またはオーディオＩ／Ｏサブシステムもまた、携帯型デバイス７００上に実装され得る。音声またはオーディオ信号出力は好ましくは、主としてスピーカ７３４を介して遂行されるけれども、ディスプレイ７２２もまた、例えば、発呼者の識別、音声通話の継続時間、または他の音声通話関連の情報の指示を提供するために用いられ得る。

図７のシリアルポート７３０は、ユーザのデスクトップコンピュータ（図示されない）との同期が望ましくあり得る携帯情報端末（ＰＤＡ）タイプの携帯型デバイスにおいて実装されるけれども、オプションのデバイス構成要素である。そのようなポート７３０は、無線通信ネットワークを介する以外に、ユーザが外部のデバイスまたはソフトウェアアプリケーションを介してプリファレンスを設定することを可能にし、そして情報またはソフトウェアのダウンロードを携帯型デバイス７００に提供することによって、携帯型デバイス７００の能力を拡張する。代替のダウンロード経路は、直接的であり、従って確実な信頼できる接続を介して、例えば、暗号化キーをデバイス上にロードするために用いられ得、それによってセキュアなデバイス通信を可能にする。当業者によって認識されるように、シリアルポート７３０はさらに、携帯型デバイスをモデムとして機能するコンピュータに接続するために用いられ得る。

短距離の通信サブシステムなどの他の通信サブシステム７４０はさらに、携帯型デバイス７００と、必ずしも同様なデバイスである必要がない様々なシステムまたはデバイスとの間の通信を提供し得るオプションの構成要素である。例えば、サブシステム７４０は、赤外線デバイスならびに関連する回路および構成要素、またはＢｌｕｅｔｏｏｔｈ^ＴＭ通信モジュールを含み得ることにより、同様にイネーブルにされたシステムおよびデバイスとの通信を提供する。

本明細書中に記載された実施形態は、本願の技術の要素に対応する要素を有する構造、システムまたは方法の例である。この記載された説明は、当業者が、同様に本願の技術の要素に対応する代替の要素を有する実施形態を作り出し、そして用いることを可能にし得る。従って、本願の技術の意図された範囲は、本明細書中に記載されたような本願の技術と異ならない他の構造、システムまたは方法を含み、さらに、本明細書中に記載されたような本願の技術からわずかに異なる他の構造、システムまたは方法を含んでいる。

１１０ 広告クライアント
１２０ 広告アプリケーション１
１２２ 広告アプリケーションＮ
１３０ ＤＣＤクライアント
１４０ ＤＣＤサーバ
１４２ ＤＣＤイネーブラ
１５０ 広告ストレージ
１６０ 広告サーバ
４１０ 広告クライアント
４２０ ＤＣＤイネーブラ
４２２ ＤＣＤクライアント
４２４ ＤＣＤサーバ
４３０ 広告アプリケーション１
４３２ 広告アプリケーション２
４３４ 広告アプリケーションＮ
４４０ 広告ストレージ
４５０ 広告サーバ

Claims (15)

1. ターゲットとされたモバイル広告の配信のための方法であって、該方法は、
   広告クライアントを携帯型デバイス上のデータファサードと関連づけることと、
   加入フィルタを該広告クライアントから該データファサードに渡すことと、
   該携帯型デバイスにおいて、該加入フィルタに関連する広告のためのデータを受信することと、
   広告のためのデータを要求するために、広告アプリケーションと該広告クライアントとの間で通信することと、
   該広告クライアントにおいて、該広告アプリケーションに対する広告のためのデータを選択することと、
   該広告データを該広告アプリケーションに戻すことと
   を包含する、方法。
2. 前記広告クライアントは、前記データファサードに加入する、請求項１に記載の方法。
3. 前記データファサードは、動的なコンテンツ配信クライアントの一部分である、請求項１または請求項２に記載の方法。
4. 前記加入フィルタは、前記広告クライアントと通信するすべての広告アプリケーション用に統合された加入フィルタである、請求項１に記載の方法。
5. 加入識別子が、前記モバイル広告クライアントに提供される、請求項１〜請求項４のうちのいずれか一項に記載の方法。
6. 前記加入フィルタは、
   ユーザの関心と、
   ユーザの配信プリファレンスと、
   ユーザのコンテキストと、
   言語プリファレンスと、
   広告のフォーマットプリファレンスと、
   デバイス特性と、
   コンテンツタイプと、
   メディアタイプと
   のグループから選択される１つ以上のパラメータを含む、請求項４に記載の方法。
7. 前記選択するステップは、広告のためのデータをフィルタリングするステップを包含する、請求項１〜請求項６のうちのいずれか一項に記載の方法。
8. 前記フィルタリングするステップは、コンテンツタイプに基づいて動的に対応付けるステップに基づく、請求項７に記載の方法。
9. 前記動的に対応付けるステップは、前記広告クライアントによって仲介される、請求項８に記載の方法。
10. 前記フィルタリングするステップは、前記広告の要求におけるパラメータに基づく、請求項７に記載の方法。
11. 前記加入フィルタは、パラメータを有するテキストストリングまたはオーバーロードされたユニフォームリソースロケータである、請求項１〜請求項１０のうちのいずれか一項に記載の方法。
12. 動的条件に基づいてアップデートされた加入フィルタを送信するステップをさらに包含する、請求項１〜請求項１１のうちのいずれか一項に記載の方法。
13. 前記動的条件は、資源のしきい値、位置による制限またはプレゼンスによる制限を備える、請求項１２に記載の方法。
14. モバイル広告の配信に適した携帯型デバイスであって、該携帯型デバイスは、
    通信サブシステムと、
    該通信サブシステムを介してデータ配信サーバと通信するデータファサードと、
    広告クライアントと、
    広告アプリケーションと
    を備え、
    請求項１〜請求項１３のうちのいずれか一項に記載の方法のステップを実行するように適合されている、
    携帯型デバイス。
15. ユーザ機器のプロセッサによって実行される場合に、請求項１〜請求項１３のうちのいずれかに記載の方法のステップを実行するように該ユーザ機器を適合させる命令を備えるコンピュータ読み取り可能な媒体。

Images