JP5973519B2 - データ収集と注目対象広告の方法 - Google Patents

Description

著作権の許諾
本特許明細書の開示内容の一部には、著作権保護の対象となるものが含まれる。著作権者は、特許商標庁の特許ファイルあるいは記録への掲載に伴う本特許明細書又は特許開示の何人の複製にも異議は唱えないが、それ以外については、どのようなものであれ、全ての著作権を留保するものである。
関連出願への相互参照

本出願は、２００８年４月３０日出願の米国仮出願第６１／０４９，０３０号と、２００８年６月２３日出願の第６１／０７４，９９５号と、２００８年６月２４日出願の第６１／０７５，３０４号に基づく優先権を請求するものであり、いずれの出願も参照により本願明細書に取り込むものとする。

携帯端末サービスプロバイダは一般に、サーバ側の技法を用いて利用情報を収集する。一つの技法は、携帯電話上での視認用に最適化されたウェブサイトをユーザが訪れる際のＷＡＰポータル／ウェブサーバからのダウンロードを追跡するものである。この技術の欠点は、それがユーザが実際にコンテンツを消費する方法に関してきめ細かな情報を提供しない点にある。この種の情報は、ユーザのニーズに合わせサービスをより上質に適合調整する上で有用となる筈である。利用情報を収集する別の技法は、ＳＭＳ（ショート・メッセージ・サービス）メッセージの配信追跡によるものである。この技法の欠点は、受取人が配信された各ＳＭＳメッセージに目を通すものと決まって仮定する点にある。しかしながら、この仮定は非常に杜撰なものとなることがあり、何故なら多くのユーザがそれらに目を通すことなくスパムＳＭＳメッセージを削除するからである。

信頼の置ける利用情報がない場合、携帯端末広告の一般的形態はＳＭＳスパム送信を介するものとなる。入来ＳＭＳメッセージが無料である多くの地域では、広告主は大量のＳＭＳ送信容量を購入し、ＳＭＳ広告をユーザにスパム送信する。ユーザは、大抵これらの広告を見ないまま削除する。ある証言は、一部の消費者がコンテンツの代価を払いたくなくて、コンテンツの代金を払わないことと引きかえに広告を見る気があることを示唆している。一部の消費者は、広告を眺めて楽しむことすらある。

下記は、本願明細書に説明するシステムならびに方法の一部実施形態の幾つかの発明態様の非限定的概要である。

一実施形態では、携帯端末遠隔通信装置はユーザにコンテンツを表示するディスプレイと、ユーザからの入力を収集する１以上の入力装置と、サーバシステムと通信し注目対象広告をユーザに提示するよう適合させプログラミングした１以上のプロセッサであって、サーバシステムが記憶し、携帯端末遠隔通信装置から先に収集した利用統計に少なくとも一部基づき広告を注目対象とするプロセッサとを備える。

別の実施形態では、利用統計と推奨注目対象広告を収集するサーバシステムは、複数の携帯端末遠隔通信装置から利用統計を受信し、この利用統計を分析し、そこから携帯端末装置のユーザに向け注目対象広告に対する推奨を生成するよう適合させプログラミングした１以上のプロセッサを備え、１以上のプロセッサが、ユーザのアプリケーションおよび／またはコンテンツ利用行為を追跡することでユーザの選好性に関する推定を自動的に行ない、ユーザの選好性に一部基づき、ユーザに製品および／またはサービスを推奨する。

別の実施形態では、携帯端末遠隔通信装置のユーザに注目対象広告を提示する方法は、携帯端末遠隔通信装置から利用統計を収集するステップと、サーバシステムに利用統計を送信するステップと、サーバシステムから推奨注目対象広告を受信するステップであって、収集された利用統計に少なくとも一部基づき広告が推奨されるステップと、１以上の推奨注目対象広告を携帯端末装置を介してユーザに提示するステップとを含む。

別の実施形態では、携帯端末遠隔通信装置のユーザに注目対象広告を推奨する方法は、携帯端末遠隔通信装置から収集された利用統計を受信するステップと、ユーザのアプリケーションおよび／またはコンテンツ転送行為によりユーザの関連性に関し推定をするステップと、ユーザの関連性に一部基づき携帯端末装置のユーザに向け注目対象広告の推奨を生成するステップと、１以上の携帯端末遠隔通信装置に推奨を送信するステップとを含む。

別の実施形態では、利用統計と推奨注目対象広告を収集する目的で携帯端末遠隔通信装置を識別する方法が、携帯端末遠隔通信装置から利用統計を収集するステップと、サーバシステムから携帯端末装置識別子を受信するステップと、サーバシステムが利用統計に携帯端末装置を関連付けられるよう、サーバシステムに対し利用統計を送信するステップと、サーバシステムから推奨注目対象広告を受信するステップであって、送信された利用統計に少なくとも一部基づき広告を注目対象とするステップとを含む。

別の実施形態では、携帯端末遠隔通信装置から利用統計を収集するサーバシステムは、携帯端末遠隔通信装置へ携帯端末装置識別子を送信し、携帯端末遠隔通信装置から利用統計を受信し、携帯端末装置識別子と受信利用統計との関連性に少なくとも一部基づき、受信利用統計が携帯端末装置に由来することを検証するよう適合させプログラミングした１以上のプロセッサを備える。

本願明細書に使用するように、「携帯電話」や「携帯端末装置」は携帯端末の音声またはデータ通信に用いられるあらゆる電子装置を概ね指し、これらに限定はしないが、セルフォンやハンドフォンやセルラーフォンやセルやモバイルやワイヤレスフォンやセルラーテレフォンやモバイルテレフォンやセルテレフォンやスマートフォンやゲーム装置や個人携帯情報端末等の他の名称により知られる装置を含むものである。

本願明細書に記載したシステム及び方法の他の発明の態様は、後述する。一実施形態では、上記の幾つかの発明態様しか含まれないこともあることが理解されよう。これらシステムと方法が、その応用例とここに用いる構成要素やシステムや方法の多くであるが故に新規であることは、理解されよう。ここに記述する本創作の発明本体の実施形態が、プロセスや機器やシステムや装置や方法やコンピュータが読み取り可能な媒体および／またはそれらの組み合わせを含む数多くの仕方で実施できることは、理解されたい。幾つかの例示実施形態を、下記に説明する。
本創作の発明本体は、添付図面と併せ下記の詳細な説明を参照することで即理解されよう。

注目対象とする携帯端末広告の文脈で利用統計のデータ収集ならびに測定用のシステムの各種要素を示す線図である。 一実施形態になる特定のテレビジョン番組に関連する商標付き用途に関するユーザインタフェースの一例を示す。 デッキベースの携帯電話ユーザインタフェースの一例を示す。 コンテンツ素材と関連広告の一例を示す。 一部実施形態による例示データベース模式図における主要エンティティとそれらの関係を示す。 一部実施形態による「ユーザ」エンティティと関連エンティティとを示す。 一部実施形態によるコンテンツ細目と関連エンティティとを表わす「コンテンツ」エンティティを示す。 一部実施形態によるコンテンツ編成に用いるエンティティを示す。 一部実施形態によるエンティティ「広告主」と「広告」と「購入注文」とを示す。 一部実施形態における注文遂行に関与するエンティティを示す。 一部実施形態における優待情報依存広告とロケーション依存広告とに関与するエンティティを示す。 一部実施形態による未処理模式化データの収集の仕方を示す。 一実施形態に用いられる基本的な３面レイアウトを示す。 一部実施形態によりユーザ管理を行なう例示インタフェースを示す。 一部実施形態による広告主用インタフェースを示す。 一部実施形態による広告用インタフェースを示す。 一部実施形態による広告購入注文用インタフェースを示す。 一部実施形態によるコンテンツプロバイダ・インタフェースを示す。 一部実施形態によるチャンネルインタフェース画面を示す。 一部実施形態による配信インタフェース画面を示す。 一部実施形態による予約インタフェース画面を示す。 一部実施形態による割り付けインタフェース画面を示す。 一部実施形態による修正割り付けインタフェース画面を示す。 一部実施形態による優待情報インタフェース画面を示す。 一部実施形態による割り付け広告インタフェース画面を示す。 一部実施形態による携帯端末識別情報を提供する携帯端末コンテンツサービス用のステップを示すフローチャートである。 一部実施形態による利用データを保護／検証する携帯端末コンテンツサービス用のステップを示すフローチャートである。 一部実施形態による携帯端末識別情報を提供し、利用データを保護／検証する携帯端末コンテンツサービス用のステップを示す別のフローチャートである。 一部実施形態による携帯端末消費者の行為を追跡するシステムのレイアウトを示す。 一部実施形態による特定の日時についての注目対象ユーザに関するロケーション依存広告に対応する場所を示す線図である。 推測されたユーザ間の関係を示す線図である。 一部実施形態によるユーザ間の共有もしくは推奨アプリケーションまたはコンテンツのＳＭＳメッセージ経路を示す線図である。

本創作の発明本体の詳細な説明を、下記に提供する。幾つかの実施形態を説明するが、本創作の発明本体はいずれの一実施形態にも限定はされないが、代りに多数の代替例と改変例と均等物とを包含することを理解されたい。例えば、限定はしないが、下記に説明する幾つかの例示実施形態は注目対象携帯端末広告の文脈にあるが、本願明細書に記載するシステムと方法が、限定を伴うことなく、非携帯端末文脈や広告以外のコンテンツの注目対象を含む文脈（例えば、娯楽コンテンツやニュースや情報コンテンツ等）を含む他の文脈にも即適用可能であることは理解されよう。加えて、本創作の発明本体の完全な理解を提供すべく、下記の説明には多数の具体的な細部を記述するが、一部実施形態はこれら細部の一部もしくは全部を用いずとも実施することができる。さらに、明瞭さに配慮し、本創作の発明本体を不要に不明確にすることを回避すべく、関連技術に周知の幾つかの技術的な材料は詳細に説明してはこなかった。

関連性に基づきユーザに対し広告や他のコンテンツを注目対象とすることは、スパムを送信するよりもユーザの注目を得るより効率的な方法である。利用情報および／または他のデータの収集を容易にし、かつ／または注目対象広告および／または他のコンテンツに役立てるシステムならびに方法が提示される。本願明細書では、一部実施形態において、携帯電話ユーザを魅了し、かつ／または注目対象広告および／または聴取測定に対する基盤を提供するよう用いうるシステムならびに方法を説明するが、それらは本発明の譲受人に譲渡された２００６年１０月１８日出願（公開第２００７／０１８０５１９号Ａ１）の同時係属米国特許出願第１１／５８３，６９３号（「第６９３号出願」）に記載されているようなデジタル著作権管理（「ＤＲＭ」）技術および／または本発明の譲受人に譲渡された米国特許出願第１０／８６３，５５１号（公開第２００５／００２７８７１号）（「第５５１出願」）に記載されているＤＲＭ技術および／またはサービス編成技術とを用いるものである（第６９３号出願と第５５１出願の内容は共にここで参照によりその全体を本願明細書に組み込むものとする）。これらのシステムならびに方法が、そこに採用されている多くの構成要素やシステムや方法がそうである如く、新規であることは理解されたい。

利用情報の収集は、信頼の置ける計算処理の使用から大いに恩恵を受ける一つのアプリケーションである。利用統計を収集するシステムは通常、データが正確に収集され信頼できることを保証する必要がある。例えば、広告主は通常、収集情報が収集後に保全性保護されていること（例えば、それが変更されたり改竄されたりしなかったこと）の保証を欲しよう。携帯端末ユーザは自らの守秘権（プライバシー）が保護されていることを欲することがあり、かつ／または一部の地域がユーザの守秘権が保護されていることを要求することがある。

本願明細書に説明する多くの実施形態は、真正かつ正確なクライアント利用データの収集を可能にすることで携帯端末利用データの収集に用いられる現行技法の課題の一部もしくは全部を克服するものである。収集されたデータは、バックエンド・システムにより分析し、注目対象広告や販促提示等をそれらを受信することに興味を抱きそうなユーザに提供するのに用い、それによってシステム効率を増大させ、より満足なユーザ体験に貢献することができる。

一実施形態では、ＰＣおよび／または携帯端末基盤上のクライアントアプリケーションと対応するサービス・バックエンド基盤とを含むシステムが提供される。クライアントアプリケーションは、利用情報を測定し、この情報をサービス・バックエンドへ中継する。収集されたデータは、例えば人口動態データ等の他の情報と相関処理され、注目対象広告あるいは他の情報をユーザへ配信するのに用いられる。クライアントは、例えばＳＭＳあるいはウェブ準拠プロトコル等の適当な帰還チャネルを用いて収集利用データを報告する。注目対象広告は、個別にあるいは関連するコンテンツ素材と共に配信することができる。

一部実施形態では、利用統計の測定と収集は、たとえユーザが携帯端末かあるいはオフラインであっても実行可能である。ＤＲＭエンジンを用い、この種の利用統計を記録するアプリケーションを実行可能状態にすることができる。収集された利用統計に対し符号化および圧縮技法を用いることができ、かつ／または利用統計はそれらが何らかの適用可能なサイズ限界を超える場合に多部分メッセージにて送信することができる。別の選択肢もしくはさらに加えて、一部実施形態では、サービスバックエンドにおいて利用統計を収集し、分析することができる。

本願明細書に説明するシステムおよび方法の一部の好適な実施形態の幾つかの利点は、例えば下記を含む。

（１）サービスプロバイダは、利用統計を用いてコンテンツサービスの有効性を特定し、このフィードバックに基づいてそれらの提示を個別仕様に合わせ調整することができる。例えば、サービスプロバイダは利用統計の分析により特定された人気のあるコンテンツと共に表示される広告について割増料金を課金し得る。

（２）消費者は、より関連性のあるコンテンツおよび提示を手にすることになる。消費者は自らに興味のある広告を示されることになり、そのことがそれらのユーザの体験を改善することになる。消費者はまた、広告のないコンテンツサービスの選択肢の提供を受けることができる。

（３）広告主は、スパムを介してそれらを同報通信するのではなく対象ユーザに広告を届けることによって、節減を実現することができる。一部実施形態では、広告主は収集された利用情報から広告が実際に見られたかどうか判別することが可能となる。

（４）コンテンツプロバイダは、現在効率的に追跡されていない急速に成長中の携帯端末ユーザ基盤内での自らの提示の人気度を追跡することができる。

例示実装の詳細

コンテンツ暗号化

一部実施形態では、コンテンツ暗号化は使用されない。他の実施形態では、コンテンツは第６９３号出願や第５１０号出願に記載されているような任意の適切な技法を用いて暗号化することができる。コンテンツを暗号化しない考えられる理由には、下記が含まれる。

（１）暗号化は、保護コンテンツでは往々にして効果がない。暗号化されたコンテンツの平文バージョンは、当初暗号化が使用されていたかに関係なく、しばしば消費者に利用可能となる。

（２）現在、消費者は装置間で非暗号化コンテンツを転送し、何らの制約も受けずに異なる装置上でコンテンツを再生するのに慣れている。かくして、非暗号化コンテンツの使用が消費者が現在慣れているものよりも劣悪と認められるであろうユーザ体験の創成回避に役立つこともある。

（３）携帯電話製造業者は、第三者のアプリケーション開発業者がコーデック（符復号器）フック処理を用いてアプリケーションを作成するのを困難にすることのできる障壁を、自らのプラットフォームに取り込むよう構築してきた。装置製造業者やシステムインテグレータを介する従来の展開経路が、困難なこともある。暗号化を要求しないことで、従来にはない経路を用い装置製造業者や放送業者の承認を受けずに加入者による直接のダウンロードを介して第三者のアプリケーションを展開することができる。

（４）ユーザに押し付けられるコンテンツがやや短命の価値しかないもの（例えば、通信網経由テレビ番組からの切り抜き画像）である実施形態では、暗号化の必要性は少ない。

一実施形態では、消費者の携帯端末装置は第５５１出願および／または第６９３号出願に記載されているようなＤＲＭエンジンを含み、計量と広告挿入（例えば、第６９３号出願に記載されている種の責務および／または回収を含むライセンス）とに関する制御情報を尊重するようにする。携帯端末装置は、第５５１号出願に記載されているような例えばＳＭＳおよび／またはウェブサービス・プロトコル等の適当な帰還チャネルを用いて収集統計を報告することになる。

一実施形態では、アプリケーションはＰＣおよび／または携帯端末プラットフォーム用に提供される。クイズや競技を呼び物にする通信網経由テレビジョン番組は、非常に多くの支持者層と視聴率とを獲得しており、投票という観点から大量のユーザフィードバックを生成してきた。一実施形態では、アプリケーションは通信網経由テレビジョン番組から埋め込み広告と共にコンテンツクリップをユーザがダウンロードし、これらクリップを彼または彼女の携帯電話（あるいは有線電話機）へ転送したり、あるいはクリップを直接的に電話機（例えば、３Ｇ電話機）へダウンロードできるようにする筈である。

通信網経由テレビジョン番組における関心は、アプリケーションが好ましくは何らかの行為をより簡単に起こさせるという観点からユーザに対し何らかの価値をもたらすユーザの注目に係わりあって維持すべく、ユーザが彼または彼女のＰＣおよび／または携帯電話にアプリケーションをダウンロードさせるよう先ず動機付けし得る要因の一つかも知れない。一実施形態では、アプリケーション用に設定される機能には下記のうちの一部または全部等の能力を含ませうる。（１）ユーザが自動的に番組の新しい挿話的事象から抜粋および／またはクリップをダウンロードできるようになる。（２）消費者がオフラインまたは出先でコンテンツを消費できるようにする。（３）クリップに対応する無料の着信音を提供し、電話機に着信音をセットするのを容易にする。（４）消費者が番組から別の携帯電話（例えば、友人）へ着信音を送ることができるようにする。（５）アプリケーション内から番組上の特定の競演者に対する投票を容易にする。および／または（６）番組に関する雑学や冗談や背景情報を提供する。

一実施形態では、下記の構成要素の一部または全部を含むシステムが提供される。

（１）番組抜粋や切り抜きや広告やライセンスおよび／またはこれらに類するものをダウンロードし、有線接続された装置（例えば、携帯電話）にコンテンツや着信音を転送するメカニズムを提供するＰＣ準拠再生アプリケーションおよびＲＳＳ配信聴取者。例えば、アプリケーションはＳＭＳを用いて携帯端末電話に着信音を送信し得る。

（２）下位機種や中位機種や上位機種の電話機にそれぞれ個別仕様に合わせ調整された携帯電話アプリケーションあるいは一組の携帯電話アプリケーション。

別の選択肢として、一実施形態では、着信音しか受信できない簡単な下位機種電話機については、専用の携帯端末アプリケーションを使用しない。この種の実施形態では、ＳＭＳゲートウェイから取得されるＳＭＳ配信報告を用い、例えば特定のユーザがどの着信音を受信したかを追跡することができる。広告は、着信音ＳＭＳ内へ挿入することができる。

低位機種電話機よりもさらに能力があるものの、低速の通信網接続を有することのある中位機種電話機については、（例えば、Ｊａｖａ（登録商標）対応電話機やＳｙｍｂｉａｎ搭載電話機用に）異なるプラットフォームに対し異なるアプリケーションを提供することができる。Ｊａｖａ（登録商標）対応電話機の場合、一部機能を省いた携帯端末版ＰＣアプリケーションを、どのコンテンツ（例えば、音声や着信音コンテンツ）を副次的にローディングしたかについて提供することができる。このアプリケーションは、事前にパーソナライズされたＤＲＭエンジンが付随していて、安全な記憶装置内に計量データを保存することができる。ＳＭＳアダプタは、このデータを読み取り、ＳＭＳを介してそれを定期的にサービス・バックエンドにアップロードすることができる。類似機能を提供するＳｙｍｂｉａｎ版の携帯電話アプリケーションもまた、提供することができる。

高速通信網接続機能や全機能付き携帯端末版ＰＣアプリケーションを有する３Ｇスマートフォン等の上位機種電話機では、組み込み型ＤＲＭエンジンとサービス編成スタックとを用いて使用することができる。この種のアプリケーションはＰＣアプリケーションと機能的には等価とすることができるが、好ましくは電話機画面形成要因について個別仕様に合わせ調整されたユーザインタフェースを有する。

（３）バックエンド基盤。好適な実施形態では、バックエンド基盤に下記の機能の一部または全てを含めることができる。配信生成と、静的および／または動的広告の挿入と、抜き取り音声からの着信音（例えば、ノキア社プラットフォーム用のＴｒｕｅｔｏｎｅ着信音）の生成と、計量および／または広告挿入を要求するコンテンツおよび関連する単数または複数のライセンスを（例えば、第６９３号出願に記載されている責務および／または回収メカニズムを介して）パッケージ化するパッケージ化ツールと、ＰＣベースのアプリケーションがＳＭＳを介して電話に着信音を送信できるようにするＳＭＳゲートウェイとウェブ準拠フロントエンド／ウェブサービス・インタフェースと、ＳＭＳを介して送信される計量データを収集し、分析用データベース内でそれを編成するメカニズムと、ユーザの行為に関しより効率的に推定を抽出すべく受信した計量および利用情報の分析と他データとの相関処理のためのオフラインツールとである。例えば、広告視認選好性を示す利用データは人口動態データ（例えば、年齢や収入等）と相関処理し、特定製品に関する集団の注目対象部分の識別に役立てうる。

より詳細な例示実施形態を図１に関連して下記に説明するが、同図は例えば注目対象とする携帯端末広告に使用する聴取者利用統計のデータ収集と測定のための例示システムの各種要素を示す線図である。サービス・バックエンド１１０は、報告書作成プログラム１１８と、データベース１１６とパッケージ化器１２０とＳＭＳゲートウェイ１２２とＨＴＴＰサーバ／ＲＳＳ配信生成器１１２とを含む。一実施例では、サービス・バックエンド１１０で実行中のＰＣアプリケーションは、ＰＣ１１４と携帯電話を有するユーザを注目対象としており、この携帯電話は例えばＰＣに対しＵＳＢ大量記憶モードにて装着することでデータケーブルを介してユーザがコンテンツを複製する。

多くの通信網経由テレビジョン番組は現在公式ウェブサイトを有するが、それらは往々にして通信網経由でのローディングがやや遅いものである。このことが、特に一部世帯が低速ダイヤルアップ・リンクおよび／または比較的低速の共有インターネット接続を有するとの事実に鑑み、それらをより使いにくくしている。従って、一実施形態では、ＰＣアプリケーションはユーザのＰＣ１１４（例えば、マイクロソフト社製ウインドウズ準拠ＰＣ）上に局所的にインストールすることができ、通信網帯域を用いＲＳＳを介してコンテンツ／メタデータをダウンロードし、特に非接続モードにおいてより良質なユーザ体験を提供することができる。

好適な実施形態では、ＤＲＭクライアントはＰＣおよび／または携帯電話上に含まれていて、第６９３号出願に記載された種別のパーソナリティ情報および／または固定されたユーザノードを用いて事前にパーソナライズ化し得る。

図２は、一実施形態により特定のテレビジョン番組に関連する商標付きのアプリケーション（例えば、「Ｓａ Ｒｅ Ｇａ Ｍａ Ｐａ」アプリケーション）に対するユーザインタフェース２１０の一例を示す。例えば、アプリケーションは、図１のＰＣ１１４等のユーザのＰＣ上で実行させうる。

コンテンツ／メタデータ・ダウンロード

一実施形態では、図１のＰＣ １１４等の稼働中のＰＣアプリケーションは、図２のユーザインタフェース２１０等のユーザインタフェースとコンテンツダウンロードＵＲＬおよびコンテンツに関するメタデータとを提供するＲＳＳ配信聴取者とを有する。一実施形態では、アプリケーションは周期的に配信を聴取し、例えば図１のデータベース１１６からコンテンツおよびメタデータを自動的にダウンロードする。一部実施形態では、ＰＣアプリケーションはまた、この種の操作を「オンデマンド」で遂行すべくボタン／メニュー細目を含めうる。これは、「常時」インターネット接続を持たない消費者にとって有用とし得る。

一部実施形態では、ＰＣアプリケーションは下記のうちの幾つか又は全部をサポートし得る。すなわち、

（１） ユーザがシステムをもっと使用するよう奨励すべく、番組に関連したニュース細目や雑学を自動的にダウンロードする。

（２）例えば基本的検索方式（例えば言語、言語リスト、「＊」を用いたワイルドカード等）を使用してコンテンツの簡単な検索をサポートする。

（３）有線接続された装置へのコンテンツの転送をサポートする。別の選択肢として、あるいはこれに加え、ユーザは、ＵＳＢ大量記憶装置として携帯電話を直接装着し、まさにファイルエクスプローラを使用してファイルを複製し得る。有線接続された装置として転送できるようにすることで提供される便宜は、コンテンツとメタデータが電話機に対し正規の場所に正規のディレクトリ構造（例えば、携帯端末アプリケーションが参照を期待する場所およびディレクトリ構造）をもって複製される筈である点にある。

（４）電話への着信音の送信をサポートする。一実施形態では、アプリケーションはユーザが電話機へ着信音を送信できるようにするインタフェース（恐らくは自動化ボットに対する何らかの保護を用いる）を含む。ユーザは電話機種（例えば、銘柄／型番）を選択し、電話番号を入力し、パーソナライズ化されたメッセージと共に着信音を送信する。一実施形態では、静的広告文字／図形もまたバックエンドによって自動的に挿入し得る。

携帯端末アプリケーション

好適な実施形態では、携帯用途のうちの少なくとも２つのカテゴリーがサポートされる。

１）有線接続された装置用への限定された機能群の適用

２）全機能付き携帯端末アプリケーション（例えば前記したＰＣアプリケーションに対し機能において等価であるアプリケーション）。

一部実施形態では、携帯端末アプリケーションのユーザインタフェースは、メニューとサブメニューを誘導案内する下部ボタンを有する「デッキ」ベースとし得る。

図３は、デッキベースの携帯電話ユーザインタフェースの一例を示す。図３に示す如く、携帯電話３１０上のインタフェースはそれぞれ左矢印ボタン３１２と右矢印ボタン３１４とを備え、それらはコンテンツ細目間の誘導案内に用いられ、「再生」ボタン３１６と「投票」ボタン３１８は改めて説明するまでもないものであり、「呼び鈴」アイコン３２０は現在選択されているコンテンツ細目に対応する着信音を設定するためのものである。

一実施形態では、限定された機能群の携帯端末アプリケーションは下記の具体的特徴を有する。（１）所与のユーザに対し事前にパーソナライズ化し事前登録したＤＲＭエンジンと、（２）計量データをアップロードするＳＭＳアダプタと、（３）平文コンテンツを再生し、ＤＣＦ／ＰＤＣＦファイルを解析し、ライセンスを評価し、責務と回収等のＤＲＭ機能をサポートすることのできるメディア再生アプリケーションとである。

一実施形態では、全機能付きアプリケーションは機能群限定アプリケーションの全ての機能に第５５１号出願に記載されているもののような完全サービス編成スタック（例えば、ＮＥＭＯスタック）とＭａｒｌｉｎ Ｂｒｏａｄｂａｎｄエコシステム等のシステムに一クライアントとして完全参加する能力とを有する。

バックエンド基盤

一実施形態では、図１のバックエンド基盤１１０の機能には、配信生成と広告挿入と、コンテンツのパッケージ化と、ＳＭＳゲートウェイと、利用データの計量およびアップロードと、データ分析と、相関処理とが含まれる。

配信生成。クライアントが消費することになるＲＳＳ配信を、生成する。一実施形態では、この配信にクライアントが自動的にコンテンツをダウンロードできるようにする情報を含ませることができる。

広告挿入。一実施形態では、広告挿入用に２つの要諦が存在する。（１）コンテンツ内への挿入（例えば、静的にかつ／または動的に）と、（２）帯域外配信（例えば、ＳＭＳを介する）とである。帯域外配信の例には、着信音の一部としての配信と正規の広告としての配信とが含まれる。

コンテンツのパッケージ化。一部実施形態では、比較的簡単なライセンスが用いられる。別の実施形態では、第６９３号出願および／または２００８年７月２８日出願の米国特許出願第１２／１７８，５４３号、「Ｄｙｎａｍｉｃ Ｍｅｄｉａ Ｚｏｎｅｓ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ（動的媒体領域システムおよび方法）」（公開番号第２００９／００３１４３１Ａ１号、その内容をここでは参照により組み込む）に記載されたような比較的価値あるライセンスを用い、例えば動的広告挿入を可能にすることができる。一実施形態では、ＤＣＦ／ＰＤＣＦをコンテナ規格として用いることができる。

計量／利用データアップロード。一実施形態では、ＳＭＳは帰還チャネル（ＲＣ）として用いられ、バックエンド基盤へ利用データをアップロードする。一部実施形態では、効率のためデータをエンコードし圧縮することができる。

データ解析および相関処理。アップロードされたデータはＳＭＳゲートウェイからに抽出され、圧縮解除され、デコードされ、続いてさらなる分析用にデータベースにローディングされる。アップロードされたデータと他のデータソース、例えば人口動態学上のデータとの相関処理は、強力なものとすることができる。一例が、下記に提供される。

収集した計量／利用データの分析。図４は、コンテンツ４１２の一素材の一例および関連する広告４１０（例えば、自動車に関する広告）を示す。例示目的に合わせ、データ分析が下記を示したものと仮定する。（１）ユーザが広告４１０を複数回再生した。（２）ユーザが広告４１０の一部セグメントを複数回巻き戻し再生した。（３）ユーザが、コンテンツ４１２を最初に視認してから数日して広告４１０を再生した。本例では、ユーザの行為はユーザがこの広告が興味深いことを見出したことを意味する。ユーザがコンテンツ細目に戻ってきて、広告を再び再生するという事実は、それが束の間の興味でなかったことを恐らく意味する。再生された広告の一部が、恐らく格別の興味がある何かを示す。これらの種別の分析は、特定の製品に興味を有するユーザの特定に役立てることができる。

人口動態および／または他のデータとの相関処理。上記データを、人口動態データあるいはユーザに関する先に収集されたデータ等の他のデータで相関処理することで、計量データ分析のさらなる実証をもたらし得る。例えば、上記の実施例の人口動態データがユーザが子供のいる中程度の収入の家庭、すなわち自家用車を所有しないかあるいは１台所有する家庭の誰かであることを示した場合、そのときはユーザが車の購入を考えていることの強い指標となりうる。販売呼び込み等の他の手段により注目対象とされた広告は、この場合に広告宣伝担当者に良好な成果をもたらし得る。おそらく、自動車ローン会社はその広告資料のユーザへの送付に興味を抱くこともある。あるいは、恐らく自動車のディーラーはユーザの古い車を下取りに提供し得る。収集したデータは、分析と相関処理の後、この情報の潜在的な消費者に販売し得る貴重な情報を生み出すことができる。

ライセンス生成ツール。一実施形態では、ダウンロードされたコンテンツはライセンスが関連付けられているが、コンテンツ自体は暗号化はできない。第６９３号出願に記載されているようなライセンスを用いる実施形態では、アプリケーションは計量義務（存在する場合）を収容するＥＳＢを入手すべく、ライセンスを評価する。一実施形態では、まさしく計量義務のある固定ライセンスを挿入し得る。他の実施態様では、より洗練された制御を用いうる。純粋に計量データから多くの情報を得ることができ、洗練された広告サポートは別料金となる。例えば、データ計量時のタイムスタンプは、ユーザが広告を見ているかどうか、ユーザがそのコンテンツ細目を何回見たか等を特定するのに用いることができる。

改竄耐性。一部実施形態では、コンテンツが暗号化されることはないため、システムのソフトウェアおよび／またはハードウェアをハッキングする強烈な誘因は存在しないかも知れない。その結果、洗練された改竄耐性は一部実施形態では不要とすることができる。一部実施形態では、ＰＣアプリケーションに対する任意の適当な形のコード不明化の適用（例えば、Ｔｈｅｍｉｄａを使用）および／または携帯端末アプリケーションに対する適用で、充分であろう。

着信音フォーマットおよび変換。携帯電話が必要とする着信音（例えば、単声的や多声的あるいは真正音）は通常、携帯端末セットのハードウェアに依存する。着信音は、データケーブルあるいはより一般的にはＳＭＳのいずれかを介して電話へ配信することができる。着信音用のＳＭＳコード化フォーマットは、電話製造業者ごとに異なっており、当業者には周知である。

ＳＭＳアダプタ。一部の携帯電話に利用できる唯一の帰還チャネルは、ＳＭＳチャネルである。中位機種の電話機（例えば、低速ネットワーク接続を有するＪａｖａ（登録商標）対応電話機）では、ＳＭＳアダプタを提供し、ＤＲＭクライアントから計量データを引き出し、ＳＭＳを介してそれをバックエンドにアップロードし得る。

ＳＭＳゲートウェイ選択。好適な実施形態では、選択されるＳＭＳゲートウェイ・アプリケーション／サービスプロバイダは大きなＳＭＳ負荷に拡張可能な筈である。

ＳＭＳに対する課金。一部状況では、帰還チャネルとしてＳＭＳを使用することは、それと関連するコストを有する（例えば、一部の場所では、入来ＳＭＳは無料であるのに対し、送出呼には料金がかかる）。それ故、これらの状況では、より低頻度にあるいは異なるメカニズムを介してデータをアップロードすることはより有利である。

広告の割り付け

一部実施形態では、競売ベースのメカニズムを用いて広告スロットを埋めることができる。一実施形態では、広告スロットは競り下げ競売を介して販売される。競売準拠メカニズムにより、サービスは広告掲載面積ごとにより有利な価格を取得することができ、それは価格設定モデルが十分に開発されていない確立された配信チャネルにおける新規コンテンツチャネルに関連する携帯端末広告や広告等の新規に出現する広告配信チャネルでは、上記メカニズムがない場合に値付けが困難となりうるものである。好適な実施形態では、システムはまた待機／バックアップ広告を使用する筈である。待機広告は、底値近くの割り引きで広告スロットが販売されるも、単数または複数の主割り付けメカニズムを介して何らの広告スロットもさもなくば履行されない場合に、条件次第で実行されるだけの広告である。

広告スロット割り付けに関する制約は、注目対象設定制約と隣接性制約とを含む。隣接性制約は、（ａ）距離制約（例えば、広告間の最大もしくは最小の許容距離）と、（ｂ）相互排除制約（例えば、特定種あるいは特定の製品や製造業者や広告主の広告は、特定種の製品や製造業者や広告主の別の広告とは出現させることができない）とに分解することができる。

一部実施形態では、単純な標識付け機構により単純なワイルドカードを用いて相互排除制約が特定できるようになる。相互排除制約は、その広告を見せられているとき競合製品についての広告を排除するよう使いたいと広告主が願う種の制約である。例えば、その清涼飲料の広告が流される間、清涼飲料製造業者はその競争者の製品に関するバナー広告を排除したいと欲することがある。

広告割り付け問題は、目的関数（例えば、生成収益）と幾つかの制約の観点からＡＭＰＬ等の数学的プログラミング言語を用いてモデル化することができる。広告割り付け問題は通常、現在のところそれを解く良好な数学的方法を持たない非線形離散最適化問題となる。非線形離散最適化問題は、一部変数をパラメータに変換し、これらパラメータの一定範囲の値について問題を解くことで、一連の線形離散最適化問題に分解することができる。線形離散最適化問題は、分岐−切断および分岐−結合カテゴリーのアルゴリズム等の標準的アルゴリズムを用いて解くことができる。最後に、各下位問題のための極大値は目的関数のための包括的最大値に到達するよう比較することができる。

広告用バックエンド、すなわちサポートされたコンテンツ配信プラットフォーム

一部実施形態によれば、本願明細書に記載するシステムと方法を、広告サポートされたコンテンツ配信プラットフォームのバックエンド・システムに用いる。幾つかの実施形態では、下記の機能性の一部または全てをサポートすることができる。（１）コンテンツのアップロードと、（２）コンテンツのパッケージ化と、（３）広告のアップロードと、（４）広告主の登録と、（５）広告単位（例えば、広告スロット）への購入注文配置と、（６）注文遂行（例えば、広告主用の広告スロットの予約と特定のスロットへの個々の広告の割り付けとを含む）と、（７） ＲＳＳ配信生成と、（８）販促および優待情報管理と、（９）調査準拠広告および／または（１０）報告生成である。

本願明細書に記載するシステムおよび方法の実施形態は、広告の配置を管理し、聴取者の測定を行ない、広告を注目対象とする基盤の提供に用いることができる。

下記の考察では、下記の用語は概ね下記の意味を有する。

本願明細書に記載するシステムならびに方法の実施形態は、携帯端末ユーザ用に広告サポートコンテンツ配信システムの開発を目指しており、人気のある通信網経由番組が生成するような短命のコンテンツ（例えば、歌唱競技会や舞踏競技会やクイズ番組や迫真のテレビ番組コンペ等）に対処すべく使用することができる。

これらの番組の時間依存特性が故に、視聴率にとっては相当の「突発的一局集中問題」が存在する。ＣＰＭやＣＴＲ等の広告に関する従来モデルは、これらの種別の事象を分解する傾向がある。（ファンが送信する投票等の）聴取者応答の突発的性格が相当の影響力を有しており、突発的負荷に処すべくシステムのアーキテクチャによって対処する必要がある。

これらの番組には夥しい視聴者の関心が存在し、携帯電話ユーザの数の驚異的な成長が故に、コンテンツの消費パターンは劇的に変化しつつある。消費者の行為におけるこの遷移が多数の課題を課し、コンテンツ配信や聴取測定値や注目対象広告に対し唯一無二の機会を提供している。本願明細書に記載するシステムならびに方法の実施形態は、消費者のこれら現在の進化する必要性に対処するよう試行するものである。

広告。図３を再度参照するに、例示クライアントアプリケーションの画面レイアウトが図示してある。底部のボタンバー３４０は、コンテンツを介する誘導案内用のボタン（それぞれ左右ボタン３１２，３１４）と、コンテンツ表示画面上での投票とユーザのクリック（例えば、調査準拠広告の説明において下記に説明する）を記録するのに用いる投票ボタン３１８とを有する。図３に示す例示実施形態にも含まれるのが、ロゴアイコン３３０やティッカー広告場３３２や映像／コンテンツアイコン３３４や情報ティッカー３３６や動画化ＧＩＦ広告バナー３３８である。

一実施形態では、クライアントは下記の種別の市場調査メッセージを提示可能とすることができる。（１）テキスト準拠広告と、（２）グラフ、アニメーションのＧＩＦバナー広告と、（３）調査準拠広告と、（４）市場調査探査と、（５）ロケーション依存広告と、（６）ＯＯＢ（ＳＭＳ経由で送信された）広告とである。

文字準拠広告。これらの例には、上部ティッカー等の簡単な文字ティッカーが含まれる。上部ティッカーは動画ティッカーの一例であり、それらは概して平文広告や静止文字広告よりも効果的である。

図形動画ＧＩＦバナー広告。これらは、よく知られているインターネットバナー広告に類似するものである。

調査準拠広告。これらは、時折コンテンツ細目間に配置される広告（例えば、これらはユーザがＮｅｘｔボタン３１４を押して次のコンテンツ細目へ行ったときに示すことができる）である。調査質問が厄介なこともあるため、好適な実施形態では、それらをあまり頻繁に使用すべきではない。また、一実施形態では、ユーザは中央ボタンを押すことなく、代りに「Ｎｅｘｔ（次）」を押して次のコンテンツ細目へ行くことで、調査質問に応答しない選択肢を有することになる。調査準拠広告は有用となることがあり、何故ならそれらはより価値のあるクリック媒介（ＣＴ）広告を実現する手段をもたらすからである。

調査広告には、例えば下記の如き質問をする細目を含めうる。（１）先のコンテンツ細目内の可視広告に関する質問（例えば、「製品Ｘに関しもっと知りたいと興味をお持ちでないでしょうか？」）と、（２）「先の広告の製品を１〜５の尺度で格付け（マウス中央ボタンのクリックが続くラジオボタンの選択）」と、（３）あるいは、「あなたは製品Ｘが好きですか？Ｙｅｓ／Ｎｏ」。調査画面はまた先の画面とは無関係とし、純粋な市場分析調査とし得る。

ロケーション依存広告。ロケーション依存広告は、ユーザがその時に位置するロケーションに基づいてユーザに配信することができる。例えば、近くのストアや、販促コードを含む近くのレストランおよび／またはそれに類似するものに関する広告である。これらの脈絡依存広告はユーザ構成可能とし得る（例えば、ユーザは登録時に随意選択的な入出力に対するか、あるいは進行中のアカウント管理の一部としての選好性を示すことができる）。

広告配信／ダウンロード。一部実施形態では、広告はコンテンツと共に配信される。無線ネットワークのインターネット速度が比較的遅くなるほど、有線接続されたモデルは恐らく今日のコンテンツと広告の送出用に最も実用的なモデルとなる。これは、３Ｇ周波帯域がまだ開設されていない一部市場（例えば、インド）では特に当てはまることである。また、無線インターネット接続は一般的に比較的高価であり、一部のユーザは自らの携帯電話プランの一部としてはそれを持っていない。この理由から、下記は有用となろう。（１）ユーザが音楽および／または他のコンテンツをダウンロードすることのできるインターネットカフェや、（２）同調コンテンツに対する特別な携帯電話キオスク（例えば、バス停や通勤列車駅や空港等の所定場所の携帯電話充電ステーション）である。キオスクは、ユーザが彼らの携帯電話にコンテンツをダウンロードできるようにするこれらの場所にセットアップし得る。キオスクはまた、独立したオペレータ（例えば、喫茶店や野外大学キャンパス、ＳＴＤ−ＩＳＤセンター（例えば、有人電話ブース）等）を介して主要都市の戦略拠点に配置し得る。

ウィルス性アプリケーション配信。携帯電話アプリケーションの幅広い配信を容易にすべく、例えば下記の如く、ウイルス性配信を推奨することができる。（１）ユーザは、アプリケーションを実行しながら、「送信」ボタンを押し、（２）ユーザには、画面の底部に彼の友人の携帯電話番号を入力するテキストボックスが示され、（３）ユーザは、番号を入力して、ＯＫを押し、（４）アプリケーションは、ＳＭＳを友人の番号と共にバックエンドへ送信し、（５）バックエンドは、アプリケーションをダウンロードし、それを友人へ送信するためのリンクを含むＳＭＳを含んでおり、（５）友人はリンクをクリックし、アプリケーションをダウンロードしてインストールし、（６）ダウンロードされたアプリケーションには、ユーザがアプリケーションが果す内容の感触が得られるよう「冒頭ハイライト」コンテンツと広告（例えば、コンテンツと広告のごく小さな切り抜き）を含ませ、また最新のコンテンツ、例えば通信網を介するかあるいは最も近いインターネットカフェあるいはキオスクを介して電話機を同調させるリクエストを含めうる。

一実施形態では、バックエンドがアプリケーションごとに転送要求を追跡し、それによってユーザ間の関係に関する情報を学習し、その関係はそのデータベースに保存することができる。この情報は、例えば、友人および家族の注目対象設定（下記により詳細に説明）に用いることができる。

広告配置。好適な実施形態では、携帯端末アプリケーションは広告を表示する掲載面積を有しており、この掲載面積は広告主が手配しない場合には無駄となるものである。測定と広告注目対象は、広告ごとにより有利な価格設定を獲得するのに用いることのできる付加価値サービスである。

今日、ダイヤル発信の群発的性質が故に、ＳＭＳメッセージの相当部分が失われている。これらのメッセージを配信し得る場合、それは持ち主にとって価値あるものとなる筈である。一実施形態では、リクエストはタイムスタンプを押され、ネットワークが混雑している場合、蓄積転送はメッセージの送信の遅延に用いうる。

広告価格設定

最低広告単位価格（ＭＡＰ）。一実施形態では、システムは広告掲載面積が無駄にならないよう（すなわち、所与のスロットに広告を載せるよう手配された誰かが存在するよう）保証すべく試みる。システムは、単一の広告単位ごとの最低価格を有することでこれを可能にする。システムのオペレータは可能性のある広告主に話を持ちかけ、条件次第リストに彼等を掲載できるよう要請する。広告主は、値引き価格についてなにがしかの量の広告単位を購入するよう委託する場合にそのリスト上に載せることができる。利用できるスポットがある場合にだけ、広告主の広告が配置されよう。最低価格は、価格に対し値引きを適用した状態で、類似サービスの市場価格に依拠させうる。一部実施形態では、特定の一部の広告単位は無料の公共サービス表明用に予約し得る。

小売価格（ＲＰ）。これは、スポットを無条件で購入したいと願う場合に顧客が支払う正規のリスト価格である。小売価格は、広告単位ごとに設定する固定価格とし得る。実際の販売価格は、広告単位や販促および値引きや価格引き下げ（例えば、公益サービス広告）等に対する要求等の要因に応じて小売価格を上回るかあるいは下回るものとし得る。

競り下げ競売。一実施形態では、しかるべき行事の前の所定時刻（例えば、人気のあるテレビジョン番組の放送２週間前）に何らかの広告単位が売れ残っている場合、これらの広告単位は競り下げ競売にて販売し得る。一実施形態では、当初の価格範囲をＲＰ〜ＭＡＰとし得る。全ての売れ残り広告単位が販売されるまで、入札は受け付けられる。一実施形態では、何人も最低入札価格（競り勝った最低入札）を支払う。一つの広告単位が多数の要請を受ける場合、実際の販売価格は小売価格を上回るものとし得る。

注目対象広告。一実施形態では、注目対象広告（例えば、特定の人口動態を注目対象とする広告）はより高い即決購入価格を有する。それらが購入された場合、それらは続いて販売するものから取り除かれ、残りが競売に回されるか最低価格にて販売される。

人口動態注目対象化。一実施形態では、このシステムは人口動態グループ（例えば、若年専門職、子供のいない家族、年齢４０〜６０歳の成人労働者、６０歳を上回る成人等）により、広告主が聴取者を注目対象にできるようにしよう。

地理学的注目対象化。一実施形態では、システムは地理学上の領域（例えば、西海岸、北西部、中西部、南、東海岸、北東部、南東部等）により広告主が聴取者を注目対象化できるようにする。

地方注目対象化。地方注目対象化は、下記の如く行ないうる。（１）携帯電話アプリケーションは、ユーザのロケーションを定期的に記録し、（２）携帯電話アプリケーションは、この情報をバックエンドへ（例えば、それが利用データをアップロードする際）送信し、（３）バックエンドがユーザが旅する領域を含むデータを受信すると、それは地方注目対象プールからの広告を用い、それらをユーザが次回同調する際にユーザへ送信し、（４）ユーザがロケーションのｘマイル以内に到来すると、それは対応するその地方広告をポップアップさせ（例えば、その中の優待情報を用いたピザ屋の広告、一実施形態では、その土地の食堂に利用可能な優待券が利用可能であると言う１行メッセージが表示されることになり、ポップアップ表示は、好ましくはやや控えめとされる。）（５）ユーザは広告に対するクリックする選択肢を有することになり（例えば、ユーザが優待情報をクリックすると、アプリケーションはこのクリックを記録し、この情報は広告主に勘定を請求するのに用いられる）、（６）ユーザがポップアップ広告を無視した場合、何らかの適当に規定された時間枠内（例えば、２０秒後）にそこから立ち去る（時間切れする）ことになる。

収集されたデータが第三者により共有されるという加入者の懸念に対処すべく、一実施形態では、法律が要求することを除き、サービスが識別可能なユーザ情報を第三者へは開示しないという守秘権方針にてサービスは保証を提供し得る。

友人および家族の注目対象化。一実施形態では、広告主には「人口動態プラス」注目対象の選択肢を与えることができ、それは特定の人口動態と、同様にまた例えばその人口動態内の人々の友人（例えば、関係乖離度２あるいは他の任意の適当な度数）とを注目対象とする。

利用度測定

好適な実施形態では、下記の一部又は全部に関し携帯電話クライアントのアプリケーションによって利用データが収集される。（１）コンテンツ細目の視認回数（例えば、バナー広告や文字広告あるいは映像広告について広告視認回数を推定するのに用いることができる）と、（２）地方広告や調査広告等に対するユーザのクリックと、（３）ユーザのロケーションデータと、（４）動的に挿入される広告に関する広告視認データとである。

コンテンツ識別

透かし入れ。一部実施形態では、コンテンツを識別するため、コンテンツに透かしを入れる方式を用いることができる。例えば、透かしは３２ビット幅とし得、８ビットをコンテンツバージョン用に確保し、２４ビットをＩＤ用に確保する。透かしは、携帯端末クライアントのアプリケーションを用いて好ましくは数値計算により簡単に読み取られ、しかも隠匿され、ユーザが除外しかつ／または変更するのを困難にする。

コンテンツＩＤ。ＧＩＦバナー広告と文字ティッカーデータはそれらの関連コンテンツと共にパッケージ化することができ、何故ならそれらは通常はかなり小さい（例えば、動画ＧＩＦバナーについて５〜６キロバイト）からである。例えば、３ｇｐ等のＭＰＥＧ−４準拠フォーマットを用いる場合、簡単な広告をｕｄａｔａ（ユーザデータ）アトム内に載せうる。このことで、広告の配信と管理とが容易になり、ユーザが広告を除外するのが若干難しくなる筈である。ｕｄａｔａアトムには、第１の広告を表示するよう指示するバイトと、次の広告をディスプレイに指示するカウンタ（再生者が更新可能）とを持たせうる。

一実施形態では、バージョンの異なる同じコンテンツが、異なる開始広告数を有するよう作成される。これは、全てのバナー／文字広告の公平な処置を確実にすべく行なわれる。

一実施形態によれば、映像広告はコンテンツの一部でもあるが、一部実施形態ではこの広告の大きさは一部コンテンツ細目において広告が反復されるが故に比較的小さなものとすべきである。一実施形態では、１本の映像広告は映像トラックに静的にエンコードされる筈であるが、その他はどれも個別の最上位アトムに含められる筈である。

循環広告の計数。一実施形態では、広告は循環させる（例えば、ユーザが頁を変えた際に異なる広告を表示したり、タイマーに基づいて異なる広告を表示する）。携帯電話アプリケーションは、ユーザがコンテンツ細目を見た回数を計数し、この情報をバックエンドへ報告する。バックエンドはそこでコンテンツのバージョンとカウンタとを用い、各広告が何回表示されたかを導き出すことができる。

システムアーキテクチャ

ユーザ管理。一実施形態では、会員権の３つの階層をサポートするシステムが提供され、それらは（１）匿名ユーザと（２）加入済みユーザと（３）支払い中の加入者である。

匿名ユーザ。ユーザがインターネットカフェあるいはキオスクからコンテンツをダウンロードする場合、彼あるいは彼女は下記のいずれかを選択する。（１）彼あるいは彼女が加入している場合は、ユーザ名またはパスワードを用いる。あるいは、（２）固定のユーザ名とパスワード（例えば、各カフェロケーションごとに個別のものを作成し得る）を用いる。これにより、人々は加入せずに（例えば、誰かが加入を手間暇かけて遣り遂げたいと思わない場合）コンテンツをダウンロードすることが容易となる。一実施形態では、匿名ユーザは加入済みユーザが入手する幾つかの余得を入手はしないが、コンテンツと広告はダウンロードすることができる。別の実施形態では、匿名あるいは加入済みの全てのユーザについて測定を行ない、ＳＭＳを介してバックエンドへ送信する。例えば、ユーザ番号（例えば、ＴＯＮやＮＰＩや番号タプル）を用いてユーザを識別し得る。

加入済みユーザ。一実施形態では、ユーザは例えば電子メールや携帯電話番号をもってサービスに加入できるようになる。これは、例えば下記の如く行われる。（１）ユーザが細目（例えば、名前、苗字、電子メールアドレス、居所、性別、年齢、婚姻の有無、子供の数、携帯電話番号および／またはその他）を入力する。ユーザ名は携帯電話番号とし得、各携帯電話番号ごとに別個のパスワードを作成し得る。（２）ユーザは、リンクを含む電子メール確認応答を取得するが、彼又は彼女がクリックして電子メールアドレスを確認し、そのことが携帯電話へのＳＭＳの送信に帰結する。（３）ユーザはＳＭＳメッセージに登録を完了するよう要請する。一実施形態では、加入時に制限を課し得る（例えば、携帯電話は、１日最大１０個まで所定の電子メールアドレスをもって登録し得る）。一実施形態によれば、加入したユーザは番組からその携帯電話へ着信音を送信する能力や、舞台裏情報や雑学や失態等を受信する能力等の一部余得を入手する。

加入者の誘導。一部実施形態によれば、一部加入者は割増金付きコンテンツについて弁済する。この場合、ＤＲＭ保護されたＰＣクライアントもまた用いることができる。

広告枠販売

一実施形態では、システムは広告枠（例えば、一実施形態の非注目対象広告）に入札をするメカニズムを提供する。一実施形態では、システムは最高の入札を選択し、それらに競り勝ったか競り負けたかを入札者に知らせ、価格を（誰もが見られるよう公開し）公表する。

広告選択

非注目対象広告。一実施形態では、一旦競り落としが選択されると、最低価格で販売された全ての追加の広告と共にこれらの広告はプール内に置かれる（例えば、文字とバナーと映像のそれぞれに１個の広告）。一実施形態では、広告は無作為に選択され、広告誌内に配置される（例えば、コンテンツ細目ごとに１個）。選択された広告は、プールから除外される。全ての広告が雑誌に割り当てられるまで、この処理は続けられる。

注目対象広告。一実施形態では、注目対象広告（例えば、特定のユーザグループを注目対象とする広告）については、広告枠が一部販売済みである場合、残りの広告は優先順位に従って広告を注文すべく、入札価格を用いて予定に組み入れることにする。一実施形態では、注目対象ユーザが満たす残る枠は総数（注目対象グループについて）から販売済み広告を差し引き、公益サービス広告を差し引いたものに等しい。広告に優先順位を付すべく、入札価格を用いて広告に優先順位が付けられよう（最低価格の広告は最後にくる）。

コンテンツのパッケージ化。一実施形態では、一旦広告誌にコンテンツ細目を関連付けると、文字広告やバナー広告や映像広告について異なる開始番号を用いて異なるバージョンのコンテンツがパッケージ化される。注目対象とされたユーザは、コンテンツと広告について異なる分類を形成する。

広告とコンテンツ配信。一実施形態では、バージョンの異なる各コンテンツ細目が総当たり様式にて分配され、広告を均一に配信する。

システム設計

好適な実施形態では、バックエンドは広告配置に利用可能な掲載面積の最大利用を保証するよう努める。本願明細書に説明するシステムならびに方法の幾つかの実施形態の利点は、ユーザから収集することのできるコンテンツ消費と広告視聴者層に関する情報にある。このデータはそれ自体貴重であり、一定の時間期間に亙るユーザの行為と選好性に関する推論の展開に用いることもできる。これらの推論は、そこでより良質なものに広告を調整するかまたは注目対象とするために用いうる。

一部実施形態では、下記の設計思想の一部または全てが適用可能である。

１． オペレータは、バックエンドの主使用者である。システムの一部は外部団体に呈示し得る（例えば、コンテンツ管理機能はコンテンツプロバイダに呈示し得、広告管理および配置機能は広告主に呈示し得る）。しかしながら、システムがそのコンテンツおよび／または広告を配信する多数のチャネルの一つに過ぎないが故に外部団体は恐らくシステムの使用法を習得すると仮定することはできない。これらの外部団体は通常、従来からの手段を介してサービスに接すると予想される。例えば、（１）コンテンツプロバイダは通常、メタデータだけでなく共通形式でのコンテンツに対する単純なＦＴＰ低下を想定している筈である。サービスは、このコンテンツを取り込んで、これとあらゆるメタデータとをフォーマット化し、携帯端末基盤に適したものとする筈である。（２）広告主は通常、電話あるいはファックスにより広告枠に対し購入注文を送信する。（３）オペレータあるいは一部の他種のユーザは通常、各コンテンツ細目と広告とを手動で点検し、コンテンツと広告に対し編集制御できるよう保証したいと欲することになろう。

２．広告視聴率は、インターネットモデルよりもテレビジョンモデルに近い。本願明細書に説明するシステムと方法の好適な実施形態は、テレビジョンゲーム番組に関連するもの等の短命で時間に依存するコンテンツを扱う。この種のコンテンツにおけるユーザの関心は番組の放送時間とその前後では高いが、番組から数時間が経過すると殆ど完全に失せるものである。コンテンツ自体は、行事後には極めて貴重というわけではない。携帯端末アプリケーション上でのこの種のコンテンツに関するユーザの関心と対応する広告視聴者層は、テレビジョン聴取者に密接に追随する。対照的に、周知のウェブサイトについてのインターネットの広告視認は、多少とも均一な率で発生する。インターネット広告は、コスト当り訴求力モデルに追随することがある。テレビジョンの場合、広告枠は訴求力数を直接計数することなく、全体として販売される。Ｎｉｅｌｓｅｎによるテレビジョン用の評価システムは、広告スロットの価格を特定するのに広告主が使用する聴取者の間接的測定である。

３．コンテンツ細目は、広告販売時には利用可能ではない。一部番組のコンテンツは、その番組の放送日付に密接させて記録される。広告主は、厳密なコンテンツが如何なるものとなるかを前以て知ることはない。彼等は、番組ジャンルと過去に放送されたコンテンツ種別しか知らない。

４．広告は、広告販売時には利用可能に出来ない。広告主は通常、一旦広告枠を確認すると、広告をアップロード／付託する筈である。広告主はまた、様々な広告配信に使用できるようストック広告群をシステムにアップロードするよう選択する。

５．広告枠に対する制約は、広告枠注文の申し込み時に利用可能とされる。広告はずっと後になって付託されることになるが、一実施形態では、広告配置に対し広告主が載せる必要のあるあらゆる制約は概ね広告枠予約時点で利用可能とする必要がある。

６．バックエンドは、バックオフィス・システムである。バックエンド・システムは、広告枠用の注文を記録し、それらを処理するのに用いられる。注文処理の最終結果は、ＲＳＳ配信とパッケージ化されたコンテンツとこれら配信が引用する広告の集合である。配信とパッケージ化コンテンツと広告が一旦生成されると、これらはＨＴＴＰサーバ上のデータセンターに受け入れさせるか、あるいはエッジサーバに配送し得る。データセンターからのダウンロード統計は定期的に持ち帰られ、分析と報告用にバックエンドシステムへアップロードされることになる。

システムユーザ。システムユーザは一般に、下記を含む。（１）オペレータ、すなわちコンテンツおよび広告をシステムへ配信するユーザ。（２）システムアドミニストレータ、すなわちサーバを構成して維持するユーザ。さらに広告主、すなわち通常システムへのアクセスを持たず、通常電話もしくはファックスを介して広告スロット用に購入注文を入れるユーザ（あるいは、一実施形態では、一部のシステムインタフェースをこれら遠隔地のユーザが使用できるよう呈示し得る）。（３）コンテンツプロバイダ、すなわち通常コンテンツプロバイダはコンテンツの付託に極めて簡単なインタフェース（例えば、コンテンツをアップロードするｆｔｐメカニズム）を必要とするユーザ。システムオペレータは、このアップロードされたコンテンツを取り込み、適当なチェックの後、システムを用いてコンテンツをパッケージ化する。（４）エンドユーザ（例えば、コンテンツの消費者）、すなわち通常公衆インターネット基盤からコンテンツとＲＳＳ配信とをダウンロードするユーザ。

図５は、一部実施形態による例示的なデータベース略図におけるエンティティとそれらの関係を示す。システムの主要エンティティは、下記の通りである。（１）ユーザ（例えば消費者／エンドユーザ）と、（２）コンテンツ（コンテンツ、タグおよびコンテンツ種別、チャネル、チャネルカテゴリー、コンテンツプロバイダを含む）と、（３）広告主（例えば、広告主と広告−購入注文とを含む）と、（４）注文遂行エンティティ（例えば、広告、広告スポット、予約および広告割り当てを含む）と、（５）グループ広告およびロケーション広告と、（６）未処理統計データとである。

下記の説明はシステム内の各主要エンティティに絞り込み、それらの互いの関係についての詳細を提供し、これらエンティティに影響を及ぼす事例を用いる。

ユーザ

図６は、一部実施形態になる「ユーザ」および関連情報を示す。一実施形態では、ユーザエンティティは下記の属性により追跡する。
・ユーザ名
・パスワード
・名前
・名字
・電話番号
・ＧＵＩＤ（汎用一意識別子）

ユーザは、余分の人口動態および地理的情報を（例えば、加入時に空欄を書き込む用紙を介し）随意選択的に提供することができる。
・年齢
・性別
・婚姻の有無
・子供の数
・所得水準−世帯所得範囲
・職業
・電子メール
・郵送住所
・地理学上のロケーション、すなわちこれはアドレスから推定できるが、地理学上のロケーションはアドレスの地域カテゴリに関連する。

システムの匿名ユーザにとっては、随意選択的な追跡属性の多くが、当初は利用可能にはできない。しかしながら、この情報は時間の経過とともに（例えば、調査を通じて収集された情報を介し）あるいは他チャネルを介して（例えば、人口動態情報を含むオペレータが供給する顧客データ等の人口動態データの外部ソース）を補充し得る。

ユーザの追跡。一実施形態では、ユーザは少なくとも２つの方法にてシステムに記録することができる。（１）加入済みユーザ、すなわちこの場合、ユーザは所定の用紙にそれらの細部の全てあるいは一部を記入し、加入時にこの用紙を提出する。（２）匿名ユーザ、すなわちこれらは、友人がアプリケーションを転送する場合に携帯端末クライアントに直接ダウンロードするかあるいはクライアントを獲得するかいずれかをするユーザである。彼等は、そこでインターネットカフェへ行き、彼等の携帯電話にコンテンツを「匿名」で同調させる。ＰＣアプリケーションはＧＵＩＤを生成し、それを携帯電話に配置する。続いて、電話が「自宅呼び出しメッセージ」をバックエンドへ送信し、これがＧＵＩＤに携帯電話番号を関連付ける。

ユーザの更新。一実施形態では、オペレータは、ユーザデータを更新（例えば、紛失／盗難パスワードを管理しかつ／またはさもなくばユーザ記録を更新）することが可能である。

人口動態データのインポート。一実施形態では、人口動態データ（外部ソースから入手可能とされた場合）はフォーマット化され、例えばデータベース更新スクリプトを介してシステムに入力される。

動的カテゴリー。一実施形態では、ユーザの行為および選好性データが絶えず収集され、分析される。一定の時間期間に亙り、このデータはユーザを動的定義カテゴリーに分類する際の手助けとすることができる。これらカテゴリーは、より効果的に広告に的を絞るのに用いることができる。一部の動的カテゴリーの例は、頻繁なスポーツコンテンツの消費者、調査に対する頻繁な回答者、販促／優待情報の頻繁な消費者、細目の頻繁な購入者、その他これに類するものである。

一実施形態では、ユーザは、分析データからの推定に基づきこれらの動的カテゴリーに対する付属物として分類することができる。カテゴリー自体は動的となることがあり、動的に追加し、修正し、かつ／または削除し得る。システムがデータを収集する際に行なわれる所定量の微調整が存在し、それは店の立ち上げに類似するものであって、時間の経過と共に貴方の顧客を実によく知るようになる。貴方が顧客を知ると、店はそれらが顧客が好むのではないかと考える製品をもって顧客に推奨したりあるいは注目対象とすることができる。

コンテンツ

コンテンツ、タグおよびコンテンツ種別。図７は「コンテンツ」エンティティを示し、これは一部実施形態によればコンテンツ細目と関連細目とを表す。一実施形態では、コンテンツ細目はコンテンツ細目の検索に用いることのできる０〜Ｎ個のタグに関連付けられる。コンテンツ細目は、特定のＭＩＭＥ形式種（例えばオーディオ／Ｍｐ３、ビデオ／３ｇｐ等）からなる。一実施形態では、コンテンツ細目に下記の属性を持たせることができる。
・ＩＤ、すなわち固有ＩＤ
・コンテンツプロバイダＩＤ、すなわちこのコンテンツを提出したコンテンツプロバイダのＩＤ
・プロバイダ生成ＩＤ、すなわちこのコンテンツ細目を識別するのにプロバイダが使用するＩＤ
・名前、すなわちコンテンツ細目に合わせたユーザ本位の名前
・説明、すなわち文字による詳細な説明
・継続期間
・コンテンツ種別
・画像ＵＲＬ、すなわちコンテンツ細目用アートワーク
・画像ＵＲＬ、すなわち携帯電話プラットフォーム用に作成されたアートワーク

一実施形態では、バックエンド・オペレータはコンテンツの取り込み時刻にコンテンツ細目データを試験／検証し入力／更新する（例えば、コンテンツプロバイダにより例えばｆｔｐサイトへアップロードされたコンテンツを追加する）ことにする。オペレータはまた、下記により詳しく説明するように、コンテンツをチャネル内へ編成し、配信する等することができる。

チャネル、配信、細目およびカテゴリー。図８は、一部実施形態によるコンテンツ編成用に用いるエンティティを示す。図８に示す実施例では、エンティティは下記であり、すなわち、チャネル８１０、配信８１２、配信細目８１４、チャネルカテゴリー８１６である。一実施形態では、コンテンツ細目はゼロ以上の配信として出現することがあり、チャネルはそれに関連するゼロ以上の配信を有することがある（例えば、チャネルは「舞踏競技」とし得、このチャネルに関連する配信は「第１週」、「第２週」、「第Ｎ週」とし得る）。一実施形態では、チャネルは、０以上チャネルカテゴリーに帰属させることができ、チャネルカテゴリーはＰＣアプリケーションを用いるチャネルの検索に用いられる。

広告主

広告主、広告および購入注文。図９は、一部実施形態による文脈にあるエンティティである「広告主」、「広告」および「購入注文」を示す。図９に示す例では、「購入注文」はたとえそれが通常はそれを（例えば、システムに対する販売注文として）入力するであろうオペレータであるにしても、広告主に関連するものである。他の実施形態では、図５〜図１２に示すエンティティ間の他の関係を用いうる。

一部実施形態では、広告主に関する情報は通常オペレータによりシステムに入力される。一部実施形態では、インタフェースは、遠隔広告主に公開してシステム内に自らを登録し得る。広告主は、特定配信に合わせＮ個の広告スロット（多種）の購入注文を出すことができる。実際のコンテンツ細目は、広告主がその注文を広告スロットに載せたとき、通常は未知である（例えば、広告スロットは往々にして番組の記録に先んじて販売される）。広告主は通常、人気度や価格設定やそのチャネルが提供している一般的なコンテンツ種別に基づき特定チャネルに対し広告を決定する。一実施形態では、広告スロットごとの販売価格は当初は空白設定され、注文遂行が起きたときに補充される。

図９を参照するに、一実施形態では、広告主は下記の属性を有する。（１）ＩＤ（例えば、固有ＩＤ）と、（２）名前と、（３）アドレスと、（４）支払い請求アドレスおよび／または（５）１回以上の交渉についての交渉情報である。広告エンティティは異種の広告を表わす（例えば、効率に配慮した一部非正規化を用いる）。広告は通常、販売および注文遂行の予約ステップが行なわれた後にアップロードされる（例えば、広告が特定の番組／行事に合わせ特別に行なわれる場合）。ただし、広告主は前もって在庫広告をアップロードするほうを選択することができる。かくして、一実施形態では、広告のアップローディングの過程は注文遂行期間中に注文の配置および予約ステップからリンクを外すことができる。入力広告は、注文遂行過程の広告割り当てステップへ入力される。広告割り当てステップは、このように各広告主の既存の広告目録を用いる。

一実施形態では、広告９１４は下記属性を有する。（１）ＩＤ（例えば、固有ＩＤ）と、（２）広告主ｉｄ、すなわちこの広告を付託した広告主のｉｄと、（３）広告種別ｉｄ、すなわち広告種別（例えば、文字、映像、映像＋調査、バナー、純粋な調査等）と、（４）広告の詳細、すなわち（例えば、文字、バナーファイルＵＲＬ、あるいは映像広告ファイルＵＲＬ）と、（５）広告が待機広告であるかどうかに関する情報（例えば、枠が利用可能である場合に載せられる広告）とである。

注文遂行エンティティ

広告予約と広告割り付け（割り当て）。図１０は、一実施形態における注文遂行に関係するエンティティを示す。各配信細目には固定された数（例えば、最大５個）の広告スロット１０１０が関連付けてあり、それは特定種の広告の配信細目についての広告誌を構成する。例えば、配信細目「アーチストＸＹＺの歌＃２」は１個の文字広告誌メッセージと１個のバナー広告誌と１個の映像広告誌とを関連付けることができる。この例示実施形態では、各広告誌は５個の広告用に５個のスロットを有する。広告スロットは、各配信細目ごとの広告用掲載面積を表す。各広告誌内の広告は循環させられ、最初の広告は広告誌内の何らかの特定の広告を贔屓しないよう、配信中に総当たり様式で循環させる。広告スロットは、注文遂行手順を経て広告で埋められる。一実施形態では、注文遂行は２ステップにて行われる。（１）予約−広告主のための単数又は複数の予約広告スロットと、（２）割り付け（または割り当て）−予約広告スロットに対する広告の実際のマッピングである。

一実施形態では、広告購入注文は、「新規」状態にて開始され、「予約」、「割り付け」、「確認」、「取り消し」を経て行く。一実施形態では、購入注文は販売が確認されるまで、すなわちそれが「確認」状態にたどり着く時点までは、いつでも取り消すことができる。一実施形態では、この機能は手動により（例えば、購入を相互に確認）、あるいは自動的に（例えば、締め切り日を過ぎた後注文は自動的に確認され、配信前の締め切り日は生き続け、それは事業規約に基づきシステム内に付きまとい得る）呼び出すことができる。

広告スロット予約

注文選択。予約フェーズ中は、広告スロットが予約を受ける。１以上の購入注文を選択し、注文遂行することができる。複数の注文は通常、入札過程の最後に選択される。この場合、注文遂行過程は価格（高価から安価）により指値を仕分け、続いて全ての利用可能なスロットが予約されるまで上から下にかけて注文を遂行する。単一の注文はまた、注文遂行に向け選択することができ、これに関する使用事例は完全な小売価格に対する広告枠を直接購入する広告主となる。

広告スロット予約。予約用の非常に簡単な方式は、それらの注文が満たされるまで総当たり様式にて特定配信の資格を有する全ての広告主にスロットを割り付けうる（未予約のスロットは待機広告プールから後程埋められることになる。）予約に対しより多数の制約が存在する場合は、問題は最適化の一つとなり、最適化の全体的な最終目標は広告収入を最大化する（例えば、出来る限り未予約スロットを少なく残すようにする）ことにある。

予約制約。一実施形態では、予約のための制約は、２つのカテゴリーに分類され、すなわちユーザに関連するものと広告自体に関連するものとである。本明細書では、第１種の制約を「注目対象制約」と呼び、第２種の制約を「隣接性制約」と呼ぶ。

注目対象制約の幾つかの例には、下記が含まれうる。（１）一般集団ではなく、しかるべき地理学上の人口動態あるいは動的なユーザグループを注目対象とする予約広告枠と、（２）一般集団ではなく、しかるべき年齢層グループもしくは所得水準を注目対象とする予約広告枠とである。

隣接性制約には、下記の条件が含まれうる。（１）特定の広告主についての広告が少なくともＸ個のコンテンツ細目を離して出現させることの要求（例えば、ユーザの疲労を回避するため）と、（２）一人の広告主についての広告がせいぜいＸ個のコンテンツ細目を離して出現させることの要求（広告の印象がユーザの脳裏で薄まらないことを保証するため）と、（３）一人の広告主についてのバナー広告が決して他人（例えば、競合他社）の映像広告と一緒に出現しないことの要求と、（４）幾つかのバナー広告と文字広告を相互に補強しあうよう一緒に出現させることの要求とである。特定の広告自体が後日アップロードできる点に、留意されたい。ただし、制約は、一実施形態では、予約時刻での特定の前払いであり、何故ならそれらは広告割り付け時間において即斟酌することができないからである。

制約の特定。ユーザは、システムを効率的に使用できるよう制約を明確かつ簡単な方法で特定できるようにすべきである。単純にワイルドカードを可能にする簡単なタグ付けメカニズムを用い、制約を特定し得る。例えば、広告が若干の固有のタグを付加されると仮定しよう。

例えば、広告代理店ＡＢＣからの広告主ＸＹＺについてｋＶ−ＡＢＣ−ＸＹＺ−Ａｄ２３、すなわち映像Ａｄ＃２３や、広告代理店ＥＦＧからの広告主ＪＫＬについてのＢ−ＥＦＧ−ＪＫＬ− Ａｄ３５、すなわちバナーＡｄ＃３５である。ＡＢＣ−ＸＹＺ映像広告について広告枠注文線上に載せる場合、このコンテンツ細目についてのバナー広告誌が広告主ＪＫＬからの広告を含めることができないことを意味するよう、制約は「＊−＊−！ＪＫＬ−＊」として特定し得る。

ユーザプール。システムが随意選択的情報を利用可能にするエンドユーザは、幾つかのプールあるいは注目対象グループ内に包含される。他の全てのユーザは、注目対象ではないプールのユーザの一部であると見なされる。広告主が注目対象でない広告枠を購入する場合、彼は注目対象とされていないプールに到達するよう試行する。注目対象プール内に広告枠が残っている場合、これらのユーザの一部（通常、その後にもっと見出される）は注目対象ではない広告も供されるが、それは保証はされていない。注目対象広告枠は、他方で特にそれが届けようとする注目対象聴取者に届けることを意図するものである。好適な実施形態では、注目対象グループ内のユーザは注目対象広告が供されるよう保証される。

広告スロット割り付け。広告スロット割り付けは、広告主からの特定の広告が広告主に予約されたスロットへマッピングすることを指す。好適な実施形態では、システムは広告スロットの割り付けに下記の方法を可能とすべきである。（１）自動的な広告スロット割り付けシステムは、割り付けを自動的に生成できるようにしなければならない。（２）割り付け表の相互編集は許容すべきであり、すなわちこれはオペレータが割り付けを手動で微調整しあるいは精密調整できるようにすることになる。（３）割り付け表のインポートは許容すべきである。これにより、外部ツール（例えば、この目的に合わせ設計された数学的ライブラリ）を用いて割り付け予定が可能とされ、結果はシステム内にインポートし得る。

広告選択。広告主は、幾つかのチャネルについてプール内の広告の一部を選択することができ、幾つかの他チャネルについてはできない。これは、比較的より少数の広告に影響を及ぼすと予想される。例えば、一部の広告は、普通のエピソードではなく、番組における目玉もしくは大団円だけに合わせ使用されることを意味する。

優待情報とロケーションに依存する広告

図１１は、優待情報とロケーションとに依存する広告に含まれるエンティティを示す。優待情報１１１０は、種別（例えば「食品」、「スポーツ」、「履物」、「贈答品」等）により分類することができる。座標と有効半径とを提供することで、特定の地理学上のロケーションに合わせ、優待券を提供する局所的広告を作成することができる。ロケーション依存広告に関する記述属性は、ポップアップ内でユーザに表示される文字に関連し、一方でロケーション依存広告の表示を呈示する。ユーザが彼がこの広告を見ることを望むと主張する場合、対応する優待情報がアプリケーションにより示される。そうでない場合、ロケーション依存広告ポップアップは取り消される。

未処理統計データ

図１２は、一部実施形態に従って未処理統計データが如何に収集されるかを示すものである。異なる事象種別（例えば、再生、停止、スキップ、投票、調査、広告循環）に関する事象記録１２１０と関連する事象データ（例えば、検索付託事象内で選択された細目）が、事象データの一部として記録される。コンテンツダウンロード事象もまた記録され、このデータは収集されてデータベースにアップロードされる。未処理統計データは、分析され、人口動態データと相関処理され、ユーザの行為と選好性に関する結論を引き出す。現在、コンテンツサービスは通常、サーバ側からのダウンロード数を計数することで広告の訴求力を測定するに過ぎない。本願明細書に記載するシステムならびに方法の実施形態は、クライアントによる広告の実際の視認を測定することにより、より良好な測定基準を提供することができる。例えば、配信細目に対する広告が５本の広告と共に広告誌内のＡｄ＃３から始まっていて、広告循環事象が６回の循環を計数している場合、そのときは我々はＡｄ＃３が２回表示され、他の全ての広告が１回表示されたと伝えることができる。

例示的なユーザインタフェース画面

基本的な画面レイアウト。図１３は、一実施形態になる基本的な３面レイアウトを示す。左側（ツリー）パネル１３１０は、主要機能に対するアクセスをもたらす。各ツリーノードは、そのカテゴリー内の個々の細目を示すべく開く。機能グループ／細目の選択が、検索パネルと詳細パネルのコンテンツを変える。検索パネル１３２０のコンテンツは、詳細パネル上に現在表示しようとしている内容に基づいて変化する。詳細パネル１３３０は、選択された機能細目／機能群を実行するための形態を示す。

ユーザ管理。図１４は、一部実施形態に従いユーザ管理を遂行するインタフェース１４１０を示す。

広告管理

広告管理下位細目。図１５，１６，１７は、幾つかの実施形態により広告主と広告と広告購入注文とにそれぞれ関する例示的インタフェースを示すものである。一実施形態では、図１３のツリーパネル内の「広告管理」ノードは下記の子ノードを有する。広告主（例えば、図１５のインタフェース１５１０参照）と、広告（例えば、図１６のインタフェース１６１０参照）と、広告購入注文（例えば、図１７のインタフェース１７１０参照）とである。

広告。図１６に示す例示実施形態を参照するに、広告詳細枠１６２０のコンテンツは広告種を選択するラジオボタンを用いて変えられる。「待機広告」ボックス１６３０は、何らかの広告スロットが埋められないまま残っている（広告に最低広告枠価格が支払われる）場合に広告遂行用に１件の広告が用いられたときにチェックを記入される。（３）「タグ」ボックス１６４０は広告用（例えば、それが調査広告の場合の必須事項）か広告枠予約／割り付けにおける制約の強制に使用するユーザ提供固有ＩＤである。（４）「文字広告」ラジオボタンが選択された場合、枠は文字広告を入力する文字領域を示す。（５）映像広告については、この枠は下記を示す。映像ＵＲＬを入力するテキストボックスと、それに隣接するファイル選択ボタン（例えば、ファイル選択対話を示すボタン）と、調査広告を選択してこの映像広告を関連付けるドロップダウン・ボックスである。 （６）バナー広告については、枠は下記を示す。すなわち、ＵＲＬを入力するテキストボックスとそれに隣接するファイル選択ボタン（例えば、ファイル選択対話を示すボタン）である。（７）調査広告については、枠は下記を表示する。すなわち、調査質問を入力するテキストボックスと、調査の種別を選択する選択肢をもったラジオボタン（例えば、ラジオボタン準拠あるいはチェックボックス準拠）と、調査細目を入力する方眼とである。

広告購入注文。図１７を参照するに、購入注文画面１７１０により広告主（あるいは広告主に対しデータを入力するオペレータ）が広告スロットごとに購入注文を入れられるようになる。購入注文は、単一チャネルあるいは複数チャネル内の１以上の配信ごとに載せることができる。注目対象枠１７２０により、ユーザは注目対象種別を選択することができる。隣接性制約枠１７３０は、隣接性制約（例えば、広告主がどの程度その広告を離したいか）の特定に用いることができる。購入注文リストグリッド１７４０により、購入者は複数の細目をもって注文を出せるようになる。購入注文リスト１７４０内の補助タグ列は、２件の広告を一緒に保つ制約を特定するのに使用することができる（例えば、文字広告とバナー広告を一緒に表示し、すなわちそれらを同じ広告誌内の同じ位置に入れる）。一実施形態では、例えば文字広告とバナー広告は映像広告よりも高速で循環させ、かくして文字広告に対する映像広告のリンクがそれらが同一の配信細目に行くことしか保証しないようにする）。しかしながら、広告は必ずしも一緒に示されるとは限らない。

コンテンツ管理

コンテンツ管理下位細目。一実施形態では、図１３のツリーパネル内の「コンテンツ管理」ノードは下記の子ノードを有する。（１） コンテンツプロバイダと、（２）コンテンツと、（３）チャネルと、（４）配信とである。

コンテンツプロバイダ。図１８は、例示的なコンテンツプロバイダ画面１８１０を示す。

図１９は、一部実施形態によるチャネルインタフェース画面１９１０を示す。

図２０は、一部実施形態になる配信インタフェース画面２０１０を示す。

注文遂行

図２１は、一部実施形態になる予約インタフェース画面２１１０を示す。１以上の購入注文が予約用に選択できることに、留意されたい。一実施形態では、１以上の購入注文が選択された場合、注文は買値により仕分けられ、そのシーケンスにおいて遂行される。

図２２は、一部実施形態になる割り付けインタフェース画面２２１０を示す。広告排除パネル２２１２により、一部広告は割り付けを排除することができる（例えば、特別番組やシーズン最終章にのみ使用する広告を排除する）。画面のレイアウト２２１０は、その要件が割り付けに対し広告を排除するのではなく広告を選択するという場合に変更し得る。割り付けは一回のパスあるいは複数回のパスにて行なうことができる（例えば、広告主ごとに１回のパス、購入注文ごとに１回のパス等）。予約が存在する限り、それは多数のパスにて埋めることができる。最終パスが行われると（例えば、それが最終の割り付けであることを示すチェックボックスにチェックが書き込まれた場合）、残る全てのスロットが待機広告を用いて埋められることになる。

図２３は、一部実施形態による修正割り付けインタフェース画面２３１０を示す。画面２３１０により、ユーザは広告割り付けを手動で微調整できるようになる。ユーザは、割り付けを無視できるようになる。ユーザによる変更が予約に用いられる制約に違反する場合は、警告を示されることになるが、依然としてその先へ進んで変更を保存する選択肢を貰える筈である。

一部実施形態によれば、広告枠割り付けは外部の数学的ライブラリを用いて計算処理し得、割り付け結果はそこで直接システム内にインポートし得る。

図２４は、一部実施形態による優待情報インタフェース画面２４１０を示す。

図２５は、一部実施形態によるロケーション広告インタフェース２５１０を示す。

報告および分析

広告主のための報告。下記は、一部実施形態による広告主のための報告の種別例である。（１）広告の訴求度（例えば、視認回数）（例えば、広告が何回ユーザに対し実際に表示されたか）。特徴は、年齢や性別や収入や地理学上のロケーションや婚姻の有無等により分解し得る。（２）ダウンロード回数、すなわち広告が実際にダウンロードされた回数。（３）広告の１０００回の視認ごとの調査回答数、すなわち視認者のうち何人が調査に応答したか。（４）調査応答頻度ヒストグラム、すなわち回答者が調査質問Ｘに回答する仕方。（５）ロケーション依存広告視認、すなわちロケーション依存広告視聴率データ（例えば、性別や所得水準や年齢等により分解した数を用いる）。

データ解析報告。下記は、一部実施形態による一種のデータ分析報告の実例である。（１）ユーザの賦活度、すなわち一実施形態では、これは年齢や性別や所得水準やロケーションや動的グループにより分解された能動的ユーザのグラフをもたらすことになる。ユーザの賦活度は、ユーザが視認する配信の百分比として測定される。例えば、一実施形態では、５０％賦活度のユーザは、彼がその携帯電話へダウンロードした配信の半分に目を通したユーザである。これらの例には、年齢や性別や所得水準や地域および動的グループによる賦活性と、（２）視聴率測定、すなわち特定のチャネルや配信やコンテンツ細目を視認したユーザの数とが含まれる。これらの例には、チャネルや配信やコンテンツ細目やコンテンツタグによる視聴率と、（３）視認者の癖、すなわち例えば、如何なるユーザが現在視認中かとが含まれる。これらの例には、各チャネルのユーザや地域や年齢や性別による百分比が含まれる。

広告予約例

一部実施形態をさらに説明すべく、所与のエピソードに関する広告スロットの予約についての外部数学的ライブラリの使用についての一例を挙げることにする。本例では、チャネルに関する典型的なエピソードに関する予約問題を説明する。ＡＭＰＬを用いた問題に関する数学モデルの構築の説明が、与えられる。問題を解決する適切な解決策と結果の簡潔な解釈の使用が、もたらされる。

問題説明。特定チャネル向けの配信（毎週のエピソード）が、１０個のコンテンツ細目を有すると仮定する。各コンテンツ細目には各種の広告（例えば、文字広告、バナー広告、映像広告）のうち５個が関連しており、それによって５０件の文字広告と５０件のバナー広告と５０件の映像広告のための枠が生み出される。

表２〜４は、注目対象とされなかった広告に関するデータを示す。注文は、価格によって仕分けられる。

注目対象とされた広告枠注文については、記述及び解決のメカニズムは基本的に類似する。注目対象とされた注文の場合、注文は先ず同じ注目対象グループを有する注文を含むリスト内へ仕分けられる筈である。この時点以降、割り付け処理は同じままである。

また、映像広告とバナー広告と文字広告についての待機広告料金がそれぞれ１スロット当り１０００ドルと２００ドルと１００ドルであると仮定しよう。

表２に示す如く、ＡＢＣ社はＡＢＣ−ＺＺＺ映像広告用の５個のスロットについて入札していて、ＴＵＶ社の広告が一緒に登場しない場合にだけ、そのスロットを所有したいようである。ＡＢＣ社は、ＡＢＣ−Ｆ広告について３個のスロットに対する別の注文を有する。その制約条件は、その広告にＴ社用の文字広告あるいはバナー広告を対にしてはいけないというものである。ＥＦＧが、最低広告距離２をもって２０個のスロットについて注文を有する。ＥＦＧが、制約無しで１０個のスロットについて別の注文を有する。ＸＹＺとＱＲＳとが、それぞれ７個と１５個のスロットに対し無制約の注文を入れている。

バナー広告

表３に示す如く、ＡＢＣ社が、ＡＢＣ−ＴＵＶバナー広告に対し２０個のスロットについて指値を入れていて、これらがＺＺＺ社用の映像広告とは決して対にされないよう保証することを希望する筈である。ＥＦＧ社が、ＴＭ社向けの１０個のスロットに対し指値を入れている。制約のないバナー広告ＥＦＧとＸＹＺとＱＲＳは、制約されていないバナー広告について他の指値を入れている。

表４に示す如く、ＡＢＣ社は、ＰＥＰ文字広告用の３０スロットとＴＭ文字用の１０スロットについて指値を指定しており、（２）ＥＦＧ社とＸＹＺ社とＱＲＳ社は、制約のない文字広告用に入札を有する。

割り付けの最終目標は、全３種類の広告から広告総収入を最大化することにある。

モデル構築。下記はこの課題の例示的な説明であり、その表現形式は「Ａ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ ｆｏｒ Ｍａｔｈｅｍａｔｉｃａｌ Ｐｒｏｇｒａｍｍｉｎｇ（数学的プログラミングのためのモデル形成言語）」（ＡＭＰＬ）として周知のモデル形成言語である。この例示的な広告枠予約例のモデル形成にあっては、説明に表現形式群とパラメータと変数と目的関数と制約とが含まれる。

集合。広告枠内には、２つの集合が存在する。（１）（特定の種別の）広告誌が関係するコンテンツ細目群と、（２）広告誌中のＮ個のスロット群とである。これは、下記の如くＡＭＰＬ表記にて書き表わすことができる。
set CONTENT_ITEMS; # set of content items
set AD_MAGAZINE_ITEMS; # set of items in the ad-magazine

パラメータ。問題に登場するパラメータは、下記の通りである。
＃−広告枠予約用のパラメータ−
param VIDEOAD_STANDBY_RATE;
param BANNERAD_STANDBY_RATE;
param TEXTAD_STANDBY_RATE;

変数。各映像／バナー／文字広告用の広告枠割り付けは、２進数からなる１０行５列のマトリクスを用いてモデル化、すなわち割り付け図を作ることができる。そのエレメントの数値が１である場合、スロットはその映像／バナー／文字広告用に割り当てられる。それ以外の場合は、その広告用にスロットは割り当てられない。これらは、割り付け課題における変数である。
＃−映像広告用の割り付け図−
var ABC_VID_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var ABC_VID_AD_2 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_VID_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_VID_AD_2 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var XYZ_VID_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var QRS_VID_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
＃−バナー広告用の割り付け図−
var ABC_BAN_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_BAN_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_BAN_AD_2 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_BAN_AD_3 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var XYZ_BAN_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var QRS_BAN_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
＃−文字広告用の割り付け図−
var ABC_TXT_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var ABC_TXT_AD_2 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var EFG_TXT_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var XYZ_TXT_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var XYZ_TXT_AD_2 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;
var QRS_TXT_AD_1 ｛CONTENT_ITEMS, AD_MAGAZINE_ITEMS ｝ binary;

他の変数群は、割り付けの結果として特定されるスロットに関する販売価格である。しかしながら、この変数は固定された変数群（例えば、販売価格は受け入れられた最低価格入札に関する入札価格となる）しかとることができない。

これらの変数をパラメータに変換した場合、問題を解決することはずっと簡単になる。課題は、そこで一組のより単純な課題に細分化することができ、パラメータの組み合わせが最大の広告収入を与える課題を選択することで、包括的な最大値を得ることができる。
＃−スロット当りの価格（スロットへの入札評価結果として評価）
param VID_SLOT_SALE_PRICE;
param BAN_SLOT_SALE_PRICE;
param TXT_SLOT_SALE_PRICE;

映像／バナー／文字広告用の売れ残りスロット数は、問題の別の変数となる。それには、制約もありうる（例えば、一定数のスロットは公益サービス広告用に解放状態に保たねばならない）。本例では、売れ残りスロット数は数値ゼロを有するパラメータとすると仮定する。
＃−売れ残りスロット−
param VID_UNSOLD_SLOT_NBS;
param BAN_UNSOLD_SLOT_NBS;
param TXT_UNSOLD_SLOT_NBS;

目的関数。本方法の最終目標は、全３種類の広告枠販売からの広告総収益を最大にすることである。これが、我々の目的関数である。これは、下記の如く表わすことができる。
＃−目的関数−
maximize TOTAL_AD_REVENUE : (sum ｛i in CONTENT_ITEMS,
j in AD_MAGAZINE_ITEMS｝
(ABC_VID_AD_l[i, j] +
ABC_VID_AD_2[i, j] +
EFG_VID_AD_l[i, j] +
EFG_VID_AD_2[i, j] +
XYZ_VID_AD_l[i, j] +
QRS_VID_AD_l [i, j]) *
VID_SLOT_SALE_PRICE)
+
(sum ｛i in CONTENT_ITEMS,
j in AD_MAGAZINE_ITEMS｝
(ABC_BAN_AD_l[i, j] +
EFG_BAN_AD_l[i, j] +
EFG_BAN_AD_2[i, j] +
EFG_BAN_AD_3[i, j] +
XYZ_BAN_AD_l[i, j] +
QRS_BAN_AD_l[i, j]) *
BAN_SLOT_SALE_PRICE) +
(sum ｛i in CONTENT_ITEMS,
j in AD_MAGAZINE_ITEMS｝
(ABC_TXT_AD_1[i, j] +
ABC_TXT_AD_2[i, j] +
EFG_TXT_AD_l[i, j] +
XYZ_TXT_AD_l[i, j] +
XYZ_TXT_AD_2[i, j] +
QRS_TXT_AD_l[i, j]) *
TXT_SLOT_SALE_PRICE)
+
(VID_UNSOLD_SLOT_NBS* VIDEOAD_STANDBY_RATE)
+ (BAN_UNSOLD_SLOT_NBS*
BANNERAD_STANDBY_RATE)
+ (TXT_UNSOLD_SLOT_NBS* TEXTAD_STANDBY_RATE)

制約。解決策は、下記の制約によって拘束される。

１．広告誌内のスロットは、１回の注文に限り予約することができる。
＃−二重割り付け禁止−
subject to
VIDEOAD-ALLOC-CONSTRAINT-ONCE ｛i in CONTENT_ITEMS,
j in AD_MAGAZINE_ITEMS｝
:
0 <=
(ABC_VID_AD_l[i, j] +
ABC_VID_AD_2[i, j] +
EFG_VID_AD_1[i, j] +
EFG_VID_AD_2[i, j] +
XYZ_VID_AD_l[i, j] +
QRS_VID_AD_1[i, J]) <= 1
;
subject to
BANNERAD_ALLOC_CONSTRAINT_ONCE ｛ i i n CONTENT_ITEMS,
j in AD_MAGAZINE_ITEMS｝
:
0 <=
(ABC_BAN_AD_1[i, j] +
EFG_BAN_AD_l[i, j] +
EFG_BAN_AD_2[i, j] +
EFG_BAN_AD_3[i, j] +
XYZ_BAN_AD_l[i, j] +
QRS_BAN_AD_1[i, j]) <= 1
;
subject to
TEXTAD_ALLOC_CONSTRAINT_ONCE ｛i in CONTENT _ITEMS,
j in AD_MAGAZINE_ITEMS ｝
;
0 <=
(ABC_TXT_AD_1[i, j] +
ABC_TXT_AD_2[i, j] +
EFG_TXT_AD_l[i, j] +
XYZ_TXT_AD_1[i, j] +
XYZ_TXT_AD_2[i, j] +
QRS_TXT_AD_l[i, j]) <= 1
;

２．広告どうしの相互排除のための制約
＃−隣接性（相互排除）制約−
subject to
MUTEX_TUV_ZZZ_ADS ｛i in CONTENT_ITEMS, j in
AD_MAGAZINE_ITEMS, k in AD_MAGAZINE_ITEMS ｝
:
0 <= (ABC_VID_AD_1 [i, j] + ABC_BAN_AD_1 [i, k]) <= 1
;

３．距離制約−距離制約は距離を適用する広告に対する割り当てマップを用いて同様に特定される。
＃−隣接性（距離）制約−
＃−最小距離について（広告は少なくとも２個の配信細目を分けなければならない）−subject to
MIN_DIST_EFG_VIDEO_ADS_1 ｛i in 2..9, j in AD_MAGAZINE_ITEMS ｝
:
EFG_VID_AD_l[i, j] <= 1 - sum｛i0 in
DISTANCE_1_OFFSETS｝ (sum｛j0 in AD_MAGAZINE_ITEMS ｝
(EFG_VID_AD_1 [i-i0, j0]))

４．発注量−各種の広告枠ごとの発注量による割り付けに対し制限が課される。これらの制約は、下記の通りにモデル化される。
＃−割り付けスロットの最大数−
＃−映像−
subject to ABC_VID_AD_1_QTY
:
0 <= sum ｛i in CONTENT_ITEMS, j in
AD_MAGAZINE_ITEMS｝ (ABC_VID_AD_l[i, j]) <=
ABC_VID_AD_1_MAX_QTY
;

問題の解決。利用可能なツール、すなわち前記した如き整数変数を含む問題については、「分岐および結合」カテゴリー内の数値処理法が最も有効である。非線形制約／非線形目的関数を用いて整数問題に対する数値処理技法は十分に開発はされていないため、目的関数と制約を線形制約として定式化することは重要である。線形問題に関する数値処理技法は十分に開発されており、これらのアルゴリズムはしかるべく高速で収束する。

非線形問題については、使用する大半の技術が基本的なニュートン法の変形例で構成される。これらの方法は導関数を用いるため、ソルバは計算中に変数の保全性を緩和しなければならない。得られた結果は、それ故に実数空間内にあり、解釈用に若干の後処理（丸め等）を必要としよう。後処理が、計算による最適解から解を非常に遠ざけることがある。これが故に、解決に向け感度分析を行なわねばならない。これら全ての困難が故に、線形制約を用いて問題を定式化することは有用である。

この例示問題用に用いられるソルバは、ＣＰＬ下で利用可能なＣＢＣソルバ(http://www.coin-or.org/Cbc/cbcuserguide.html)である。ＣＢＣソルバはＮＥＯＳ(http://neos.mcs.anl.gOv/neos/solvers/milp:Cbc/ampl.html)によりホスト処理される。このソルバが、例示問題の解決に用いられる。

結果。以下の表５〜７は、本例の映像広告とバナー広告と文字広告についての結果を要約したものである。

映像広告について、下記の結果が得られた。（ＡＢＣ１） ＝＝ ５； ｓｕｍ（ＡＢＣ２） ＝＝ ３； ｓｕｍ（ＥＦＧ１） ＝＝ ４であり、４だけが距離制約が故に留保されるスポットである。ｓｕｍ（ＥＦＧ２） ＝＝ １０； ｓｕｍ（ＸＹＺ１） ＝＝ ７；ｓｕｍ （ＱＲＳ１） ＝＝ １５である。（制約に従い）全ての購入注文が埋まったが故に、一部スロットが埋まらないまま残ることに留意されたい。これらは、好適な実施形態では「待機」映像広告によって充たされることになる。

ＺＺＺ映像広告を伴うＴＵＶバナーの排他性は、上記表から見てとることができる。本例では、より低価格の付け値に対しより高価格の付け値を好む制約は一切置かれない。これ故、ＡＢＣ１は他のバナー広告上にてより多くのスロットを与えられない。これは、モデル内により厳密な制約を追加することで固定することができる。

携帯端末識別システムおよび方法

広告に裏打ちされた携帯端末コンテンツサービスは通常、利用統計をバックエンド・サービスへアップロードする間に携帯端末サービスを識別する必要がある。携帯端末アプリケーションにとっての一つの方法は、携帯端末装置自体を精査して特性を識別することである。しかしながら、携帯端末装置識別子は全ての携帯端末装置上のアプリケーションに一様に利用可能ではなく、多くの場合その番号（利用可能な場合）は唯一無二とすることはできない。

例えば、携帯電話上には携帯電話用のＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）やＭＥＩＤ（Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ）等の識別特性が存在する。しかしながら、これらの特性は全ての携帯端末装置について一様に利用可能ではない。さらにまた、携帯端末装置内の異なるＩＭＥＩ番号を焼却することが可能である。ＩＭＥＩは本来が盗難に会った携帯端末装置を識別し要注意リストに掲載するよう設計されたものであるため、盗難に会った装置には通常適法な電話機のＩＭＥＩを盗まれた装置への複製を免れない。一部の工業予測によれば、ＩＭＥＩ番号の約１０％が唯一無二ではない。携帯電話の場合、ＩＭＳＩ（国際携帯端末加入者識別番号）は携帯端末消費者にとって、より「粘着質」の識別子であり、何故ならそれはたとえ加入者が自らの携帯端末装置を変更／更新する場合にでも加入者に追随するからである。しかしながら、ＩＭＳＩは概して携帯端末アプリケーションにとっては利用不能であり、他の携帯端末装置には存在しないものである。

これ故、携帯端末装置ごとに携帯端末識別情報を設ける必要性が存在する。携帯電話の場合、携帯端末識別子を携帯電話用のＩＭＳＩ番号と関連付けることができる場合が好ましく、何故ならＩＭＳＩは携帯端末消費者にもっと密接に繋がっているからである。しかしながら、携帯端末識別情報に対する必要性と消費者の守秘権を保護する必要性との間には好ましくは一定の釣り合いを設けねばならない。或る範囲までは、携帯端末識別情報に対する要件は地域の文化的慣習により決定される。例えば、一部文化にあっては、固有の識別子が実在の人物をもって直接識別されない限り、携帯端末装置に対し固有識別子を割り当てることは容認可能にできる。一部事例では、それが全ての集約あるいは非集約情報を外部の第三者に開示してその事業を遂行するとき（例えば、利用統計用の集約報告や、ユーザのカテゴリーによって分解された統計等）、サービスがデータを匿名扱いするよう注意を払う限り、バックエンド・サービスにとって消費者を個人的に識別することは容認可能であろう。他の一部地域では、それは携帯端末装置へ固有識別子を割り当てることは容認することができない。識別子は、或る種のグループ識別子（例えば、ユーザが地理学上の領域とユーザのカテゴリーと所定の年齢層等に所属すると識別する識別子）とする必要があるかも知れない。ユーザの分類は、実際のデータ（例えば、ＩＰアドレスによる地理学上の領域の推定）やユーザが提供した情報（例えば、ユーザが提供した調査質問への回答や、加入時にユーザが自発的に提供したユーザ情報等）を用いて行ないうる。このユーザ分類は動的に行ない得、潜在的には調査質問に対するユーザの応答に基づき時間の経過とともに変え得るものである。

一実施形態では、バックエンド・サービスはその消費者（広告主やコンテンツプロバイダやコンテンツアグレゲータ）にそれが収集し報告する利用データが真正かつ正確であるとの保証を提供する。これは、例えば非公開鍵を用いて利用データに署名することで達成することができる。携帯端末クライアントに非公開鍵を与える簡単なメカニズムは、焼成（例えば、アプリケーション製造業者にて恒久的あるいは半恒久的にインストール、もしくはダウンロード／インストール）機密事項を持たせることである。しかしながら、焼成機密事項は必ずしも唯一無二とは限らず、何故ならユーザはしばしば装置から装置へ携帯端末アプリケーションを複製するからである。また、焼成機密事項に依存するのではなく非公開鍵に対し同意することは、バックエンド・サービスや携帯端末装置にとっては好ましく、何故なら時間の経過とともに最善の改竄耐性は破られることがあり、非公開鍵が知られることになるからである。多様化は、この文脈において若干の助けをもたらす。クライアントアプリケーションの多様化は、いかなる他の要素とも無関係に貴重である。しかしながら、実用的な配慮はしばしば多様な携帯端末用途二進数の総数を制限する。

多くの携帯端末装置向け制約は、それらが公衆網に断続的にしか接続されない点にある。ネットワーク接続が存在しない場合、バックエンドから固有の個人／識別情報を得る上でネットワーク接続に依存するＴＬＳ等の従来のプロトコルを使用することができない。

本願明細書に記載するシステムおよび方法の実施形態は、これらの問題の一部あるいは全てに対処する。

図２６ａと図２６ｂは、一部実施形態に従い携帯端末コンテンツサービスが適当な携帯端末識別情報を提供し、利用データを保護／検証するステップを示すフローチャートである。携帯端末クライアントは、通信網に断続的にしか接続されない。ステップ２６１０において、携帯端末クライアントはＵＳＢ大量記憶装置モードのＰＣに有線接続するか、あるいはそれを接続した時点で通信網に直接接続することができる。ステップ２６１４では、携帯端末装置が大量記憶装置モードのＰＣに有線接続された場合に、そのときは携帯端末アプリケーションはネットワーク上のサーバに向かって直接会話することはできない。この状況にあっては、携帯端末アプリケーションは携帯端末装置ファイルシステム内の周知の場所に被創作メッセージを格納する。ステップ２６１６において、ＰＣ同調処理が行なわれる次回のＰＣ有線接続時に実行されるＰＣ同調アプリケーションにより、携帯端末装置に代わってバックエンド・サービスへメッセージが配信される。サーバの応答は、携帯端末装置のファイルシステム内に同様に保存される筈である。携帯端末装置が次回それを実行する際、それはサーバの応答を読み取り、メッセージを作成し、それを（次回それが行なわれたときにＰＣ同調アプリケーションにより配信するよう）サーバ用のファイルシステム内に保存する。携帯端末装置上のファイルシステム場所は、かくしてドロップボックスの如く作用する。ステップ２６１２において、携帯端末装置にその能力があって通信網に直接接続された場合、そのときは携帯端末クライアントとサーバとの間でプロトコルメッセージを直接交換し得る。ステップ２６１８において、携帯端末クライアントは利用データの署名／暗号化に新規の鍵であるＫｓ−ｕｓａｇｅを生成し、焼成共有機密事項であるＫｓ−ｓｈａｒｅを用いて暗号化形式にてそれを局所記憶させる。携帯端末装置内の焼成機密事項を保護するのに、改竄耐性が用いられる。ステップ２６２０において、携帯端末クライアントはｐ，ｇを選択し、乱数「ａ」を選択する。それは、それ自体の安全な記憶装置に暗号化形式にて保存することで「ａ」を記憶する。ステップ２６２２において、携帯端末クライアントはA = g^Λa mod pを算出し、さらに下記を含む最初のメッセージＭ１ （Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ）を作成する。
Ml = Enc(Ks-share, nonce | p | g | A | Ks-share-ED | "ml.dat" )
Ｋｓ−ｓｈａｒｅ−ＩＤ ＝Ｋｓ−ｓｈａｒｅ用のｉｄ
Ｎｏｎｃｅ ＝３２ビットの臨時語
ｐ ＝携帯端末クライアント内に焼成した個特化情報の公衆鍵
ｇ ＝一般には５に選ばれる
ａ ＝少なくとも１００桁の長さの乱数

ステップ２６２４において、携帯端末クライアントがＵＳＢ大量記憶モードを用いて通信網に接続された場合、それは独力でメッセージを送信することはできない。この場合、作成されたメッセージは携帯端末装置のファイルシステム上の周知の場所に保存することにする。携帯端末クライアントが通信網に直接接続された場合、それはこのメッセージをバックエンド・サービスへ直接送信する。ステップ２６２６において、携帯端末装置を通信網に接続すると、Ｍ１が（装置自体あるいは有線接続されたＰＣいずれかにより）サーバ側へ送信される。ステップ２６３０において、サーバ側は、非公開整数ｂを選択し、B = g^Λb mod pを計算する。それは、Ｄｉｆｆｉｅ Ｈｅｌｌｍａｎ（「ＤＨ」）非公開鍵を、Kdh = A^Λb mod p = (g^Λa mod p) ^Λb mod p = g^Λab mod pを用いて算出する。それは、固有識別子あるいはグループ識別子のいずれかである携帯端末識別子携帯端末ＩＤを生成し、続いてステップ２６３１においてクライアントへ送信される下記の応答Ｓ２を計算する。
data = data-length | mobile-identifier | Enc(Ks-share, nonce | B | "s2.dat")
S2 = data | Enc(Kpriv, HMAC(Kdh, data))

サーバはまた、（携帯端末識別子、Ｋｄｈ、臨時語）を将来の使用に備え局所的に記憶する。利用データ（それが在る場合）はまたこの時点でアップロードされ、データは署名されかつ／またはＫｓ−ｕｓａｇｅをもって暗号化される。Ｋｓ−ｕｓａｇｅは、この時点でサーバには未知であり、サーバはただこのデータを携帯端末識別子から由来したものとして記憶することにする。

ステップ２６３２において、携帯端末アプリがサーバに直接繋がった場合、そのときはそれはＭ２でもってメッセージに応答することができる。ステップ２６２４において、携帯端末装置が通信網に直接繋がらないものの大量記憶モードにある被接続ＰＣへ有線接続されることを通じてのみ繋げられる場合、それはサーバに直ちに応答することができないが、次回携帯端末アプリを実行する際にそうすることになる。この時点で、それはＫｄｈを計算し、ステップＳ２においてデータを検証することができる。データが検証されない場合、それは処理を中止し、方法は最初からもう一度再開させる。データが検証された場合、そのときはそれがサーバ側とＫｄｈについて同意したことを知る。それは、下記のデータを用いて第３の最終メッセージＭ３を作成する。
M3 = Enc(Kdh, nonce | Ks-usage | mobile-identifier | "m3.dat")

ステップ２６３６において、それがＭ３を受信すると、サーバ側はＭ１とＳ２（それが有線接続装置であった場合）を再検証し、記憶する値（携帯端末識別子，Ｋｄｈ，臨時語）が一致することを照合する。次に、それはＫｄｈを用いてＭ３を解読し、Ｋｓ−ｕｓａｇｅを得る。ステップ２６２８において、それはそこでＫｓ−ｕｓａｇｅをタプル内に局所的に記憶することにする。すなわち、
（携帯端末識別子、Ｋｄｈ、臨時語、Ｋｓ−ｕｓａｇｅ）

この時点で、携帯端末識別情報を提供するトランザクションが完了する。ステップ２６４０においては、プロセスがある時点で故障した場合、いずれの側もトランザクションを中止することができる。トランザクションは、携帯端末クライアントが接続する次回に再開させることができる。ステップ２６４２において、携帯端末クライアントがトランザクションを打ち切った場合、それは、ファイルを（有線接続携帯端末装置の場合の如く、メッセージがファイルとして記憶されている場合）削除し、処理を再開する。ステップ２６４４において、サーバ側がトランザクションを打ち切った場合、それはファイルを（有線接続携帯端末装置の場合の如く、メッセージがファイルとして記憶されているか、あるいはクライアントが直接それに接続されている場合に、トランザクションを中止してクライアントに対し携帯端末識別情報を供給したことを示す場合）削除し、データのアップロードをスキップ／失敗する。携帯端末クライアントはそこで、それがそうする機会を得る次回に処理を開始する。

バックエンド・サーバは、その地方の文化的要件に応じて固有識別子に代えてグループ識別子を使用するよう選択することができる。グループ識別子は実際のデータ（例えば、同調ＰＣ／携帯端末クライアントのＩＰアドレスに基づいて選択された地理学上の領域グループ）に基づいて選択することができ、あるいは（調査質問に対するユーザの回答あるいは加入時にユーザが提供したデータに基づき直接あるいは間接に）ユーザ選択することができる。

ユーザのグループ識別子は、彼の調査、すなわち彼がサービスに対し返信する回答に基づき、時間の経過とともに変更し得る。サーバは一定の時間期間に亙るユーザの回答をサンプリングした後、グループ識別子を固有識別子から「格下げ」し、ユーザの分類グループを推定することができる。別の筋書きは、携帯端末装置がサービスの有効なクライアントであり続ける保証を取得する携帯端末識別情報の「更新」の定期的処理である。これらの場合、サーバはクライアントを強制して新たな携帯端末識別子を取得するトランザクションを再実行させることができる。携帯端末クライアントは、新旧の携帯端末識別子を利用データの一部としてサーバへ返信報告し、旧識別子と新規識別子とを相関処理させることになる。携帯端末装置が携帯電話である場合、それはＳＭＳチャネルを介してサービスバックエンドに新／旧識別子を返信することもでき、そのことがまたこれら２個の識別子の相関処理に加え、その地域に相応しい場合はバックエンド・サービスがＩＭＳＩ番号に携帯端末識別子を関連付けられるようにする。

かくして、前記した如きプロトコルは、たとえ携帯端末クライアントアプリケーションがバックエンド・サービスに直接接続されていないときでも、間欠的に接続される携帯端末装置の制約内で作動させることができる。

クライアントは、利用データに署名する非公開鍵を生成する。一実施形態では、非公開鍵はそのまま記憶することは決してないが、焼成された非公開鍵を用いて暗号化形式にて記憶させてある。携帯端末アプリケーションは、焼成非公開鍵を保護すべくそれに適用された改竄耐性を有する。

クライアントとバックエンド・サービス基盤はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を行ない、利用データを携帯端末クライアントからバックエンド・サービスへ署名利用データに関する非公開鍵を送信する鍵に同意する。ＤＨの使用時に同意された非公開鍵は、それをバックエンド・サービスへ送信しながら非公開鍵の暗号化に用いられる。一実施形態では、この鍵が再び用いられることは決してない。

サーバは、装置上の携帯端末装置識別子をプロトコルの一部として供給する。サーバが供給する識別子は、バックエンド・サービスの非公開鍵を用いてＰＫＩ署名をもって署名される。

携帯端末クライアントは、サーバが供給する識別子上のＰＫＩ署名を検証し、それが信頼されるサービスから識別子を取得したことを保証する。

サーバは、それがＤｉｆｆｉｅ Ｈｅｌｌｍａｎ鍵交換時に係合させるのと同時に携帯端末識別情報を供給する。これが、３回のメッセージステップを交換することで携帯端末識別情報を取得することができるようにする。(Mobile->Server [Ml], Server->Mobile[S2], Mobile- >Server[M3])

携帯端末クライアントに関する識別情報／個別化に用いる手法を、ここに説明する。本願明細書に上記した如きシステムならびに方法の文脈では、携帯端末クライアントはサーバ側で個別化し、固有の識別情報を具備させる必要があろう。携帯端末クライアントは、この識別子を用いてサーバへ利用統計を送出することができる。例えば、広告によりサポートされた携帯端末コンテンツサービスはその消費者（広告主、コンテンツプロバイダ、アグレゲータ）に対し、それが提供するユーザ統計が正確で真正であるとする保証を提供する必要があることもあり、コンテンツサービスは適当な携帯端末識別子を用いて利用データを収集する必要があることもあり、データは携帯端末クライアントアプリケーションにより署名（随意選択的には暗号化）する必要もあろう。携帯端末識別子は、文化的慣習やその地方の要件に基づく固有識別子あるいはグループ識別子とし得る。本願明細書に説明するシステムならびに方法の実施形態により、携帯端末コンテンツサービスは適切な携帯端末識別情報を提供し、これらの最終目的に応えるべく利用データを保護／検証できるようになる。

下記の説明は、下記の如く構成されている。（１）携帯端末クライアント識別情報、すなわちこの節は、携帯端末クライアント識別情報用に用いることのできる属性を説明する。（２）個別化要件と制約、すなわちこの節は、様々な実施形態における携帯送受話器に現存する個別化と制約に対する要件に対処する。（３）個別化手法、すなわちこの節は、一部実施形態における個別化に使用する手法を説明する。

表８は、この詳細な説明において使用する様々な省略記号を示す。

この詳細な説明に使用する如く、用語「個別化（Ｉｎｄｉｖｉｄｕａｌｉｚａｔｉｏｎ）」は携帯受話器に固有の識別子を割り当てる方法を指すものであり、用語「パーソナライズ化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）」は、第６９３号特許に記載されているように、ＤＲＭシステム内の装置に固有のＤＲＭ個特化情報を割り当てる方法を指す。

携帯端末クライアント識別情報

好適な実施形態では、各固有の送受話器に関する利用統計を記録すべくサーバ側は携帯送受話器を一意に識別する必要がある。一実施形態では、必要条件はサーバ側で各送受話器を一意に識別可能とするという点だけである。この固有識別子は、クライアントを精査することにより得ることができる。この識別情報はまた、サーバ側が送受話器に割り当て得、あるいはクライアントおよびサーバからの入力を用いて生成し得る。識別子に（下記に説明する如く）ＩＭＳＩ番号を関連付けることもまた、望ましい。

ＩＭＥＩ

固有識別子を探す最先の場所は、携帯電話自体の筈である。この節は、携帯端末クライアント上で利用可能な環境から精査することができ、かつ送受話器の識別に用いうる属性を説明する。

ＧＳＭ通信網とＵＭＴＳ通信網ＩＭＥＩあるいはその最新の変形版では、送受話器ハードウェアの一意的な識別にＩＭＥＩ／ＳＶが用いられる。ＩＭＥＩは、表９に示す如く単数字Ｌｕｈｎチェックコード（検査数字）が続く１４桁の数字からなる。

ＩＭＥＩ／ＳＶは、１４桁ＩＭＥＩに加えて２桁のソフトウェアバージョンを使用する。ＥＭＥＩを持たせる元々の目的は、盗まれた送受話器を追跡し、要注意リストに掲載することにあった。しかしながら、盗難送受話器の異なるＩＭＥＩ番号を焼却することは可能である。若干の推定によれば、ＩＭＥＩ番号の約１０％はこの結果として唯一無二とはならない。

ＭＥＩＤ

ＣＤＭＡ通信網は、１４桁ＩＭＥＩに類似（その桁が１６進数であ場合を除く）のＭＥＥＤと呼ぶ識別子を使用している。ＭＥＩＤは、枯渇間近である３２ビットＦＣＣ・ＥＳＮコードに置き換えるべく、創成されたものである。

Ｊ２ＭＥを介するＩＭＥＩ／ＭＥＩＤの打診

ＩＭＥＩ ／ ＭＥＩＤ番号は、システム属性を用いて携帯電話上で打診することができる。残念ながら、全ての電話機が属性をサポートするとは限らず、属性の名称は異なる製造業者が製造する送受話器ごとに変わる。実例は、表１０に示される。

Ｎｏｋｉａ社は、この特定をサポートするのが遅い。Ｓ４０プラットフォーム上では、この特性はアプリケーションが製造業者／オペレータにより署名されている場合にだけ利用可能である。Ｓ６０上で署名は一切要求されないが、特性はＳ６０の第３版の装置上でサポートされるに過ぎない。例えば、下記を参照されたい。http://wiki.forum.nokia.com/index.php/How_to_get_IMEI_in_Java（登録商標）_ME.

結論として、ＩＭＥＩ／ＭＥＩＤは一様に利用可能ではなく、一意であるとは保証されない。それ故、携帯電話クライアントは携帯端末クライアント識別情報向けにＩＭＥＩ／ＭＥＩＤの使用に依存することはできないが、それは「曖昧な識別子」の一部となりうる。

ＩＭＳＩ

ＩＭＳＩは、識別情報にとって有用とすることができ、何故ならそれは携帯端末消費者を最も隙なく識別するからである。ＩＭＳＩは、（１）携帯端末国別コード（ＭＣＣ）と、（２）携帯端末通信網コード（ＭＮＣ）と、（３）携帯端末加入者識別番号（ＭＳＩＮ）とから構成される。

ＧＳＭ通信網では、送受話器が変えられたときでも、ＩＭＳＩはＳＩＭカードに繋がれ、加入者に付いていく。携帯電話の番号ポータビリティを用いることで、ＩＭＳＩ番号は携帯端末消費者を極めて隙なく識別するより「粘着性のある」識別子となっている。

反例は、前払いＳＩＭカードの使用である。これらＳＩＭカードのユーザは、一旦時間を使い果たすとＳＩＭカードを廃棄し、新規ＳＩＭカードを起動させがちである。この種の使用の筋書きでは、ユーザは電話番号を変更する不便さを気にはしない。この種の使用はずっと頻度が低いものと考えられており、ＩＭＳＩは概して携帯端末消費者にとって極めて良質な識別子となる。

個別化要件と制約

さらなる詳細をここで、携帯端末クライアントの個別化と携帯電話プラットフォーム上で遭遇することのある一部制約について提供することにある。

制限された／依存不能の通信網接続性

定義により、ＣＬＤＣは制限された接続性を意味する。実際には、通信網接続性はさらにより難題である。現在、携帯電話に関するインターネット接続性は制限されていて、低速であり、依存不能であって、往々にして費用が嵩むものである。

電気放送事業者の無線通信網を介するデータ接続性

電気通信事業者の無線通信網を介するデータ接続性は往々にして低速（通常、ＧＰＲＳで５６Ｋｂｐｓ）であり、これはＥＤＧＥでは２３６．８Ｋｂｐｓまで上昇させることができる（ただし、殆どの送受話器がＥＤＧＥをサポートしてない）。

放送業者の無線通信網によるデータ接続性は、高価なことがある。多くの消費者は、この理由が故にデータプランを持っていない。競合が少なく、加入者の活動がサービス契約が故に制限されている場合、市場では価格はさほど下落していなかった。別の要因は、インターネットへのアクセスがそれを効果的に壁付き庭園とする電気通信事業者のＷＡＰゲートウェイを介するものとなる点にある。

高速３Ｇ通信網は、インドのような市場では現在のところ１年または２年先である。これらの理由から、電気通信事業者の無線通信網を介するデータ接続性は携帯端末装置に存在すると仮定することはできない。存在する場合、それは極めて低速となりそうであり、電気通信事業者によりある程度制御される。

ＷＬＡＮ接続性

無線の通信要求集中箇所間のＷｉ−ＦｉもしくはＷｉ−ＭＡＸ相互接続性を有するＷｉ−Ｆｉを介するＷＬＡＮ接続性は、無線装置用の別の選択肢とし得る。携帯電話に対するＷＬＡＮ接続性に付随する問題は、それが何処でも利用可能ではなく、送受話器が全てＷＬＡＮ接続性をサポートする無線受信機を有するわけでない点にある。ＷＬＡＮ接続の使用は通常、ユーザがパスキー／パスコードを入力する必要があり、これは通常の電話機のキーパッド上では困難なことがあるが、多数の電話機が接続情報を記憶できるようにし、人がそれを反復入力する必要がないようにしてある。しかしながら、携帯端末で多くのホットスポット間を移動している場合、全地域を何処も同一のパスキーでもって配下に収める市営Ｗｉ−Ｆｉ通信網が存在しない限り、これは使用が煩わしいことがある。

個別化／パーソナライズ化に対する影響

要約するに、現行技術であれば、携帯端末通信網の接続性が極めて制限されている／依存不能であるが故に、携帯端末クライアントがＰＣに有線接続されたときに、好ましくは携帯端末クライアントのパーソナライズ化を行なう必要がある。

一部ＤＲＭシステムでは、クライアントは事前にパーソナライズ化／事前登録されるが、それはそれが通信網に直接接続されることが決してないからである。これは通常、クライアントアプリケーションに焼成されるパーソナリティノード（Ｐ）＋サービス・ユーザ・ノード（Ｕ）＋ Ｐ−＞Ｕリンクを用いて行なわれる。ＤＲＭライセンスは結合され、サービス・ユーザノードに有線接続される。ライセンスアプリケーションがインストールされた後、それを個別化する必要がある。

安全性に限界のある記憶装置

安全な記憶装置は通常、ＤＲＭクライアントの要件のうちの一つである。ＤＲＭクライアントは、しばしば機密を保存する安全な記憶装置を必要とする。

記憶装置は、（特にそれが公設場所に保存してある場合）それを暗号化することで安全確保することができる。アプリケーションに対してのみアクセス可能な非公開の記憶場所を有することはより好ましく、何故ならそれはデバッグ装置あるいは仮想マシン内でコードをランさせることで得ることはできないからである。非公開の場所が、バグ取りが不可能である装置および装置上での物理的な改竄なしでアクセスすることが出来ない場合、そのときはこれはしかるべき安全な解決策となる。

Ｊ２ＭＥアプリケーションクライアント用の安全な記憶装置の２つの可能性は、下記の通りである。

１．ファイルシステム内の非公開の場所で、各ＭＩＤＰアプリケーションがシステム特性、すなわち「ｆｉｌｅｃｏｎｎ．ｄｉｒ．ｐｒｉｖａｔｅ」が指摘するファイルシステム内の非公開の場所へのアクセスを有する。しかしながら、この特性があらゆる装置について一様にサポートされることはない。例えば、Ｓ６０デバイスはこの特性をサポートするが、Ｓ４０デバイスはそれをサポートしない。この特性に関するベンダーサポートは、製造業者／モデルによる識別が必要である。また、幾つかの電話機（例えば、Ｓｏｎｙ Ｅｒｉｃｓｓｏｎ製）ではファイルシステムの場所は「非公開」ではなく、携帯電話をＵＳＢ大量記憶モードにて装着したときに、ＵＳＢホストにより見てとれる。これ故、これは携帯電話に関するあまり現実的な選択肢とはならないようである。

２．ＲＭＳ（記録管理システム）を用いた非公開記録記憶装置で、ＲＭＳは現在全てのＭＩＤＰ電話でサポートされていると考えられる。記録は、各製造業者が専有する２進数形式にて保存される。Ｊ２ＭＥアプリは署名がなされており、それらは各アプリケーションごとに固有の（署名付き）ハッシュにより識別される。Ｊ２ＭＥ ＪＶＭは、Ｊ２ＭＥアプリが作成し非公開として記号付けする記録ストアに対しＪ２ＭＥがアクセスできるようにするに過ぎない。ＲＭＳ内へ割り込むには、攻撃側はＪＶＭ防護手段を迂回しかつ／または２進ＲＭＳデータを捜し出し解読する必要がある筈である。これ故、非公開記録記憶装置の使用はしかるべく安全にしなければならない。ＲＭＳは広く利用可能であり、安全な記憶装置としての使用に適したものとし得る。しかしながら、ＭＩＤＰ仕様実装の準拠には最低８キロバイトのＲＭＳ記憶装置の配設しか必要ない。かくして、ＲＭＳ記憶装置は幾つかの装置については極めて制限される可能性がある。

多様な（包括的に一意ではない）クライアント

個別化に対処する一つの手法は、インストールされた各アプリケーションの２進数に固有のパーソナリティノードを割り当てることともし得る。このことは多くの状況において実用的でないかも知れないが、何故ならそれは通常サーバ側に非常に大量のクライアントアプリケーションの２進数の編集を要求する筈だからである。また、ユーザは大抵送受話器から送受話器へ２進数を複製し、固有識別子に関する個特化情報の焼成に依存することは不十分かも知れない。かくして、一部の好適な実施形態では、クライアントアプリケーションは多様化されるものの、包括的に一意とはならない。

ＳＭＳは安全であるが、不足している。

ＳＭＳ帰還チャネルは、（幾つかの制限の中で）保証された配信を伴う安全な経路である。しかしながら、ＳＭＳＰＤＵに関するペイロードサイズは極めて不足している（８ビット１バイトで、１４０バイト）。複数の部分メッセージは可能であるが、ＳＭＳはユーザにコスト負担を招来し、好ましくはやや倹約して使用すべきである。

クライアント同調もしくはアプリ実行のいずれかが、先ず行なわれる。

携帯端末クライアントは、最初のＰＣ同調操作の前または後のいずれかに稼働させることができる。これが意味する内容は、最初にどの事象が発生したかに関係なく個別化プロトコルを機能させねばならないということである。この手順は、下記のいずれかとし得る。
１）
−携帯端末クライアントを稼働させる
−第１のＰＣを同調させる
−携帯端末クライアントを稼働させる
…
もしくは
２）
−第１のＰＣを同調させる
−携帯端末クライアントを稼働させる
−第２のＰＣを同調させる
…

利用データ報告要件

クライアントアプリケーションは通常、サーバへ返信報告される利用データが真正かつ正確であることを保証する必要がある。一実施形態では、クライアントは事前にパーソナライズ化される。しかしながら、好適な実施形態では、利用データの暗号化あるいは署名にこれらの焼成パーソナリティ情報だけを用いることはない。

個別化手法

一実施形態では、各クライアントには焼成済み共有パーソナライズ化機密情報が付随する。共有パーソナライズ化機密情報は、クライアントをパーソナライズ化クライアントに編成するのに用いられる。一旦パーソナライズ化が行なわれると、クライアントは固有のパーソナリティ情報を取得する。各クライアントは、そこでノードとリンクとライセンスとを取得することができる。ライセンスは、取得したパーソナリティ情報／ユーザノードに対し結合および／または注目対象とされる。

パーソナライズ化プロトコルはセッションキーを用いるとともに、平文と暗号文攻撃を最小化して非公開鍵を取得することにだけ非公開鍵を用いる。それはまた、臨時語を用いてメッセージ変更攻撃を阻止する。共有された機密事項は、クライアントの分解模倣によって全てのクライアントがパーソナライズ化を阻止されないよう、多様化される（クライアントのグループだけが「要注意リスト掲載」を理由に影響を受ける）。ただし実際には、特に共有された機密事項がクライアントの分解模倣が故に機密漏洩したことの検出は通常特定が極めて難しく、一部の未パーソナライズ化クライアントの要注意リスト掲載は困難な筈である。

本願明細書に上記したクライアントアプリケーションの好適な実施形態は通常、固定した（ただし多様化した）パーソナリティ情報ノード群と単一の共通ユーザノード（サービスノード）とを用いて事前にパーソナライズ化する必要がある。コンテンツのライセンスは結合され、サービスノードに対し注目対象とされる。ＤＲＭライセンス内のコントローラは、ライセンスサーバによりＰＫＩを用いて署名される。クライアントアプリケーションはこの署名を検証し、ライセンス内の計量義務を用いて利用を計量する。ＰＫＩ署名は、サーバが計量を要請する内容をクライアントが計量することを保証する。

クライアントアプリケーションはまた、通常、それが返信報告する利用データが真正かつ正確であることを保証する必要がある。例えば、好適な実施形態では、それは従来のパーソナライズ化では共有機密事項に対し同様に所定位置にあるものに焼成されたものとは異なる鍵を用いてデータを署名／暗号化する必要がある。

好適な実施形態では、個別化プロトコル用のこの手法は、下記による。（１）利用データの署名／暗号化用に焼成機密事項を使用しない。（２）クライアントに対し署名鍵を生成し、それを安全な記憶装置内に保存する（装置外部でアプリを実行することは非公開鍵へのアクセスを持たないであろう）。（３）サーバに署名鍵を送信するのに用いられる非公開ＤＨ鍵に対する同意用のサーバ認証を用いるＤＨ鍵交換を使用する。（４）サーバがＧＵＩＤを生成し、それをＤＨ交換の一部としてクライアントに移植する。

サーバ認証を用いたＤＨ鍵交換

クライアントアプリケーションとサーバ側は、Ｄｉｆｆｉｅ Ｈｅｌｌｍａｎ鍵交換を介して共有非公開鍵に対し同意することが可能になろう。

携帯端末クライアントを先ず稼働させる

図２７は、一部実施形態により携帯端末クライアントサービスが適切な携帯端末識別情報を供給するとともに利用データを保護／検証するステップを示すフローチャートである。特に、図２７は初回の同調前に携帯端末クライアントが実行する場合に下記を行なうステップを示すものである。ステップ２７１０において、携帯端末クライアントは利用データに署名し／暗号化し、安全に記憶装置に下記を保存するための新規鍵Ｋｓ−ｕｓａｇｅを生成する。
Enc(Ks-share, 4 bytes to store random-length | random-bytes | Ks-usage)
ここで、ＥｎｃはＡＥＳ ＣＢＣコードを用いた暗号化を意味する。
Ｋｓ−ｓｈａｒｅは、蛸足パーソナリティ情報ノードについてのＳｃｕｂａ Ｓｈａｒｉｎｇ Ｓｙｍｍｅｔｒｉｃ鍵である。
ｒａｎｄｏｍ−ｌｅｎｇｔｈは、無作為バイトの長さ（０〜１６バイト）である。
ｒａｎｄｏｍ−ｂｙｔｅｓは、無作為バイト列の無作為長さである。

一部の場合では、曖昧な指紋パラメータをここに保存することが有用かも知れないことに留意されたい。一実施形態によれば、ハッシュ（ＦＰパラメータ）がサーバへ移送され、それを利用データ向け署名計算処理に含める。これを用い、パーソナライズ化に係わった同一クライアントが利用データを生成した人であることの何らかの保証を提供する。

ステップ２７１２において、携帯端末クライアントはｐ，ｇを選択し、非公開のａを選択する。ステップ２７１４において、携帯端末クライアントは、A = g^Λa mod pを計算し、ｐ，ｇ，Ａを下記を含むファイルシステム内の固定場所に保存する。
Enc(Ks-share, nonce | p | g | A | Ks-share-ED | "ml.dat" )
Ｋｓ−ｓｈａｒｅ−ＩＤ は、Ｋｓ−ｓｈａｒｅのｉｄである
Ｎｏｎｃｅ＝３２ビット臨時語

それはまた、同じ値を安全な記憶装置内に保存する。ステップ２７１６では、ＰＣ同調において、ＰＣクライアントがｍ１データをサーバ側へ送信する。ステップ２７１８において、サーバ側は非公開整数ｂを選択し、B = g^Λb mod pを計算処理する。Kdh = A^Λb mod p = (g^Λa mod p) ^Λb mod p = g^Λab mod pを用い、それはＤＨ非公開鍵を計算処理する。ステップ２７２０では、サーバ側がＧＵＩＤ汎用一意識別子を生成し、続いて下記を算出し、これをステップ２７２１においてＳ２としてクライアントへ送信する。
data = data-length | guid | Enc(Ks-share, nonce | B | "s2.dat")
ｓ２データ内に下記を保存する。
data | Enc(Kpriv, HMAC(Kdh, data))

サーバは、将来の使用に備え（汎用一意識別子、Ｋｄｈ、臨時語）もまた保存することにする。ステップ２７２２において、利用データ（それが在る場合）はアップロードされ、すなわちデータは署名されかつ／またはＫｓ−ｕｓａｇｅをもって暗号化される。Ｋｓ−ｕｓａｇｅはこの時点でサーバには既知であるが、それはそのデータをただ汎用一意識別子用に保存することにする。携帯端末アプリが次回実行される際に、それはＫｄｈを算出し、ｓ２データ内のデータを検証する。データがそれを検証しない場合、それはｍ１データとｓ２データを削除し、処理は再び最初から開始する。データが検証されない場合、そのときはそれはサーバ側でもってＫｄｈに対し同意がなされたことを知る。それは、下記データと共にｍ３データを保存することにする。
Enc(Kdh, nonce | Ks-usage | guid | "m3.dat")

次回のＰＣ同調時点で、ステップ２７２４において、サーバ側はｍ１データとｓ２データとを再検証し、保存されている値（汎用一意識別子、Ｋｄｈ，臨時語）が一致するか照合することができる。次に、ステップ２７２６において、それはＫｄｈを用いてｍ２データを解読し、Ｋｓ−ｕｓａｇｅを取得する。それは、そこでタプル内にＫｓ−ｕｓａｇｅを保存することになる。すなわち、
（汎用一意識別子、Ｋｄｈ、臨時語、Ｋｓ−ｕｓａｇｅ）

この時点で、パーソナライズ化処理が完了する。処理がある時点で失敗した場合、下記が行なわれる。（１）携帯端末クライアントがトランザクションを中断する場合、それは、ファイルを削除し、処理を再開し、（２）サーバ側が、トランザクションを中断する場合、それはファイルを削除し、データのアップロードをスキップする。携帯端末クライアントは、それが次回稼働する際に処理を開始する。

先ず、ＰＣ同調が行なわれる。

ＰＣ同調が最初に行なわれると、アップロードすべき利用データは皆無となり、何事も起こらない。この処理は、携帯端末アプリの初回実行時に開始される。

利用データ署名／暗号化

利用データはＫｓ−ｕｓａｇｅを用いて署名される筈であり、署名は各データペイロード内でＫｓ−ｓｈａｒｅを用いて暗号化される筈である。同調期間中、ＰＣクライアントは（ｍ１データ、ｓ２データ、ｍ２データ、利用データ）を掲示する。このデータは、検証し、検証後に受容し得る（データのアップロード期間中に非同調的オフラインで）。一実施形態では、利用データは暗号化することができる。

更新

サーバは、ＫｄｈあるいはＫｓ−ｓｈａｒｅが何らかの理由であるいはまさに標準的な操作手順の一部として定期的に漏洩した場合、クッキー（ｍ１データ、ｓ２データ、ｍ３データ）を削除することで再個別化を強制し得る。

一部実施形態では、更新時にホーム呼び出しメッセージを強制し得る。他の実施形態では、旧汎用一意識別子が新規のものにリンクされていて、更新が定期的な更新であった（鍵が機密漏洩されたという理由からでなく）場合、我々はホーム呼び出しメッセージをスキップし得る。

クライアントの分解模倣

クライアントの分解模倣と非公開鍵の開示は、検出が相当困難になることがある。

機密漏洩クライアントは、サーバ側へ屑データを提出するクライアントの複製に用い得る。この可能性に対し防衛するには、アップロードされたデータに対し健全さの点検を行ない得、機密漏洩クライアントは更新を強制しかつ／またはデータを無視するか、いずれかとし得る。機密漏洩クライアントは、遠ざけることもできる（例えば、機密漏洩クライアントに対してはコンテンツ更新は一切与えない）。

ＧＵＩＤに対するＩＭＳＩの相関処理（ホーム呼び出しメッセージ）

個別化手順が完了した後、クライアントアプリケーションはＧＵＩＤと恐らくは曖昧な指紋パラメータのハッシュとを含むＳＭＳメッセージ（ホーム呼び出しメッセージ）をサーバ側へ送信し得る。ＳＭＳメッセージの封筒情報は、ＩＭＳＩ番号をＧＵＩＤに相関処理するのに用いうる。

加入者がＥＭＳＩを用いて識別されたいと思う筈の他のソースからの加入者に関する人口動態もしくは他のデータを我々が入手すると、そのときは我々はＩＭＳＩとＧＵＩＤとの間の相関関係を用い、利用データに人口動態データを相関処理し、より良質の推定／注目対象広告をより上手に抽出し得る。

統治モデル

統治モデルに関し、一例をここで説明することにする。コンテンツ細目は、どのような利用データを収集すべきかを特定する使用規則を含むＤＲＭライセンスを含んでいる。例えば、使用規則には下記を含めることができる。すなわち、（１）どのような事象を記録しなければならないかと、（２）ユーザに調査を示すかどうかと、（３）データをどの程度の頻度で返信させねばならないかとである。

クライアントは統治モデルに従い、すなわちＤＲＭライセンス内で特定された権利と義務とを念頭に置くようにする。携帯端末クライアントは、収集した利用データに署名し、このデータの保全性を保護する。このデータは、最も早い機会に返信される。このことは、２つの態様にて起きうる。すなわち、（１）ＰＣ同調時間帯、すなわちユーザが彼の携帯電話をＰＣと同調させるときに、この利用データがサービス・バックエンドへ送信される。このデータは、非公開とすべく随意選択的に暗号化し得る。（２）別の選択肢として、ＳＭＳチャネルを通じてデータを返送することができる（ユーザが利用データを報告し戻す義務において特定されている期間よりも長い期間に亙ってオフラインのままでいる場合）。ＳＭＳチャネルは非公開チャネルと見なし得、暗号化を必要としないであろう。

図２８は、一部実施形態に従い携帯端末利用者の行為を追跡するシステムのレイアウトを示す。ＷＡＰプロトコル準拠データ収集と異なり、前記システムは携帯端末消費者の行為を彼等がコンテンツを消費し続けるのに合わせ追跡する。ＳＭＳスパム送信とは異なり、クライアントについて実際に測定された正確かつ真正な利用データが供給される。

システムは、ユーザのコンテンツ細目との相互作用を捕捉する事象を記録する。計量システムは、再生／停止事象を測定し、ユーザのコンテンツ消費データを計量する。従来の計量アプリケーションは、計量されたコンテンツ利用に基づきユーザに課金するサービスである。他方で、本システムはコンテンツの消費だけでなくコンテンツ細目におけるユーザの関心も測定して追跡することに関係する。ユーザのコンテンツ細目との交互作用は、ユーザの関心のうちの最良の指標の1つである。

ユーザの興味と行為を追跡すべく、よりレベルの高い再生事象が携帯端末クライアントによって記録される。これらの事象の幾つかの例は、下記の通りである。（１）ユーザがバナー広告に対しクリックした。（２）ユーザがコンテンツ/広告の一部を転送／スキップバックした。（３）ユーザがコンテンツ細目について投票した。（４）ユーザが、コンテンツ細目あるいは広告に関連する調査に対し、応答ＸＪを用いて応答した／ユーザが完全に調査をスキップした。（５）メディア終了（ユーザがコンテンツ細目全体を見終わった）。

ＥＳＢ構造。本発明は、クライアントがどの事象を記録しなければならないか特定すべく、第６９３号出願に記載されたような責務枠組みを用いる。クライアントは、コンテンツ細目２８３２内に埋め込まれたライセンス２８３０を評価する際にＥＳＢ（エクステンデッド・ステータス・ブロック）の一部としてこれらの責務を受信する。擬似コード中のＥＳＢの例
extendedStatusBlock EsbOK =
esb｛
globalFlags = 0;
esbCategory = ACTION_GRANTED;
esbSubCategory = 0;
localFlags = OBLIGATION_NOTICE | ...
cacheDuration
valueList = ｛
Obligations = valueList ｛
｝

データの収集と配信の枠組み

ＨＴＴＰチャネル−図２８を参照するに、携帯端末クライアント２８１２は、携帯送受器上のローカル・ファイルシステムに、利用データを記録する。このデータは、携帯端末クライアントによって暗号により署名される（保全性の保護）。ＰＣ同調を介するかあるいは直接ＯＴＡ（空中線を）介するかのいずれかのダウンロードで携帯端末クライアントに対しコンテンツがダウンロードされるときに、このデータはＨＴＴＰ ＰＯＳＴを介してサービス・バックエンド２８２０へ送信される。携帯端末クライアント２８１２（または携帯端末クライアントに代わって作動しているＰＣ）は、移送中にデータの守秘権を保護すべく、このデータを随意選択的に暗号化することができる。

ＳＭＳチャネル。別の選択肢として、データはＳＭＳを介してサービス・バックエンド２８２０へ送ることができる。ＳＭＳは同時偏在するものであり、携帯端末クライアント２８１２は常時ＳＭＳを使用することができるが、ＳＭＳメッセージの送信にはしばしばコストが付随する。これ故、携帯端末クライアントは可能であるときは必ずＨＴＴＰを使用しようと努めるが、ライセンス２８３０に特定されたデータ収集責務に特定された報告間隔を上回る期間に亙りクライアントがオフラインのままである（無線インターネットに接続されず、ＰＣと同調していない）場合は、ＳＭＳを使用することになる。ＳＭＳは、メッセージサイズに制限を有しており、すなわちＳＭＳＰＤＵは１４０バイトを超えることはできない。利用データは、それが限界を上回る場合、分割することができる。データは、ＳＭＳ使用を減らすためにＳＭＳチャネルを介してそれを送る前に圧縮する。

注目対象広告に対するサービス・バックエンドの使用。システムが収集した利用データは、統計的データ採掘と分析技術とを用いてオフラインで分析する。携帯端末ユーザは、分析を用いてカテゴリーに分類することができる。ユーザは、２以上のカテゴリーに帰属させることができ、それが帰属する各カテゴリーに対する程度の異なる有縁性を持たせることができる。ユーザはまた、一部の自己選択カテゴリー内に包含すべきシステムに対し人口動態データを付託することができる。（公益ソースからかあるいは共同事業会社からのいずれかからの）人口動態データはまた、広告した製品とサービスに興味を有し得るユーザに対し広告をより良好に注目対象とすべく、サービス・バックエンド２８２０に付託することができる。サービス・バックエンド２８２０は推定されたカテゴリーと人口動態データを利用し、そのカテゴリーと人口動態グループ／に対し注目対象とされた広告に役立てる。

ロケーション依存／日時依存の注目対象地方広告配信。説明しているシステムにより、広告主はロケーション依存広告を打てるようになる。図２９は、一部実施形態により特定の日時について注目対象ユーザにとってのロケーション依存広告に対応するロケーションを示す線図である。ロケーション依存広告、例えばＬ４は、地理学上のロケーション（ＧＰＳ座標）と賦活領域（ＧＰＳ座標からの半径が例えばＲ４）に添付される。広告は、携帯端末ユーザが賦活領域内、例えば半径Ｒ４を有するＬ４に関する２９３０内に到来したときに、携帯端末ユーザ２９１０に提示される。矢印２９２０は、携帯端末ユーザ２９１０の経路を表す。図２９に示す例では、それぞれ半径Ｒ１，Ｒ２，Ｒ３，Ｒ５を有すロケーション依存広告Ｌ１，Ｌ２，Ｌ３，Ｌ５に関連する賦活領域もまた存在する。

ユーザが賦活領域内にいるときにユーザにロケーション依存広告を提示することは、極めて時宜に適うもので有効であり、何故ならユーザはこの情報をそれが提示された時点で彼のすぐ近くで活用できるからである。

ロケーション依存広告の一例として、前記したシステムを用いて販促広告（優待情報等）を載せたいと思っている広告主を考える。このシステムにより、広告主は販促広告材料を提出し、それに１以上の地理学上のロケーション（これらは、店舗のロケーションとし得る）を関連付けられるようにする。一部実施形態によれば、システムはまた広告がプレゼンテーション（時刻）のための時間ウインドウと関係していることができる。広告はまた、説明したシステムにおいて全ての広告がそうであるように、特定の注目対象グループに対する注目対象とすることができる。

注目対象グループ内の（販促広告に興味を示しそうな）ユーザは、販促広告がポップアップ表示にてユーザに提示される時間窓枠期間中は賦活領域内にある。広告の適時性とそのロケーション依存性と注目対象ユーザに対する販促メッセージの関連性とが合わさり、広告の有効性の増大を生み出す。

本例の広告は、ユーザ周辺のピザ屋ロケーションのＧＰＳ座標に連結された昼食時間帯に提示するピザ屋の優待情報とし得る。注目対象ユーザが賦活領域内に到来すると、ユーザは彼にとって極めて関連性のありそうな販促広告を示され、販売するより大きな機会（これを広告にとって貴重なメカニズムとする広告用のより良質な広告−販売実現率）に帰結させることができる。

異なる携帯電話プラットフォームが、携帯端末装置がそのロケーションの所定半径内にあるときにシステムがアプリケーションを呼び戻せるようアプリケーションにアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供する。例えば、Ｊ２ＭＥプラットフォームはＡＰＩ用にＪａｖａ（登録商標）結合を提供する。ＡＰＩの使用の一例は、下記コードにて与えられる。
１．付加情報は、場所に取り付けられた各広告ごとに特定される。すなわち、
public LocationAdEntry(double lattitude,
double longitude,
float accuracy,
int adNumber,
int timeOfDay,
String adFeed,
String adlnfo) ｛
this.lattitude = latitude;
this.longitude = longitude;
this.accuracy = accuracy;
this.timeOfDay = timeOfDay
this.adNumber = adNumber;
this.adFeed = adFeed;
this.adlnfo = adlnfo;
this.doNotShow = false;
｝
２．各ロケーションごとのユーザロケーション事象を聴取するよう、ロケーション聴取者が追加される。
private void addLocationAdProximityListener(LocationProvider Ip,
LocationAdEntry entry) ｛
if (null != Ip) ｛
Coordinates coords = new Coordinates(entry.lattitude,
entry. longitude,
Float.NaN);
try ｛
LocationProvider.addProximityListener(this, coords, entry.accuracy);
｝ catch (Exception ex) ｛
TraceLogger.out.println("adding proximity listener failed! -" + ex.getMessage());
ex .prints tackTrace() ;
｝
｝
｝
３．その場所でのイベントが起こると、アプリケーションはロケーション依存広告を示す。
private void handleProximityEvent(Coordinates coords) ｛
double lattitude = coords.getLatitude();
double longitude = coords.getLongitude();
TraceLogger.out.println("PE: Lattitude =" + lattitude);
TraceLogger.out.println("PE: Longitude =" + longitude);
LocationAdEntry entry = getLocationAdEntry(lattitude, longitude);
if (isTimeOfDayForAdvertisement(entry)) ｛
displayLocationSensitiveAd();
｝
｝

携帯端末ユーザの関連性追跡。携帯端末クライアントアプリケーションにより、彼等がＳＭＳを介してそれを使用する間にアプリケーションを転送することで、ユーザが携帯端末クライアントアプリケーションを彼等の友人と共有できるようにする。ユーザはまた、彼等がこの機構の使用を好むコンテンツ細目を共有し推奨することができる。友人や仲間とコンテンツ細目を共有して享受する能力は、ユーザ体験をユーザにとって双方向に享受可能とする。

ユーザからユーザへのコンテンツのウィルス性配布は、それらのコンテンツの広域流布を達成したいと願うコンテンツプロバイダのための魅力的な機構となる。この形の配布はまた広告主に役立つが、それは彼等がこのメカニズムを介してより幅広い聴取者に対し自らの市場調査メッセージを潜在的に到達させることができるからである。

ユーザがこの機能を使用する間、システムは転送行為の追跡を維持し、彼等のアプリケーション／コンテンツ転送行為に基づきユーザの関連性を推定する。これらの推定は、自らが消費するコンテンツに関し類似の興味と選好性を共有するユーザに同じく広告を注目対象とさせるだけでなくユーザに興味を持たせることもできるコンテンツ細目を推奨するのに用いられる。

ユーザの推定された関係は、彼等が共有し推奨するコンテンツ細目のカテゴリーによってさらに分類され、限定される。システムは、推定された関係の強さを定量化する数値測度である「ユーザ有縁性」と呼ばれる測度まで被推定関係を低減する。ますます多くの同一形式のコンテンツをユーザが同じ受取人に転送するにつれ、有縁性はより強くなる。転送事象からより多くの時間が経過するにつれ、ユーザ間の有縁性はより弱くなる。

例えば、有縁性の単純な測度は、下記の如く算出される。未処理有縁性値＝細目数×効果指数／（１日の転送事象間の平均経過時間）

一部実施形態によれば、未処理有縁性値は、簡単に比較対照できるよう、特定カテゴリーのコンテンツに関する値範囲に基づき、０〜１００の間の範囲へ正規化する。一部実施形態によれば、有縁性測定値は、転送行為について転送事象間での経過時間の分布、すなわち転送行為に関する当日の時間経過等のより多くの変数を考慮することによってさらに純化される。

有効性指数は、推定された関係が注目対象化広告においてどの程度効果的だったかの（ユーザの応答の統計データ解析から類似広告まで間接的に測定される）測度となる。有縁性のより良好な測度は、より長い時限に亙り収集されたデータに対する統計データ分析技術により展開させることができる。

図３０は、推定されたユーザ間の関係を示す線図である。ユーザ、例えばユーザ３０１０，３０１２，３０１４が円で示してある。推定されたユーザ間の関係は、接続線により表わされる。接続線の太さは、関係の有縁性を示す。例えば、ユーザ３０１０と３０１４と間の関係の有縁性は比較的強く、ユーザ３０１２と３０１４との関係の有縁性は比較的弱い。

アプリケーションおよびコンテンツ転送行為の追跡維持は有用であり、それはシステムがユーザベースの嗜好性と選好性とをより良く理解できるようにするからである。それは、ユーザ選好性をユーザ関連性と相関処理することで、システムが広告と推奨とをより良く注目対象化できるようにする。

図３１は、一部実施形態によるユーザ間で共用あるいは推奨されたアプリケーションまたはコンテンツのＳＭＳメッセージ経路を示す線図である。ユーザ３１１０は、前記携帯端末クライアントアプリケーションを通じてＳＭＳを経てアプリケーションおよび／またはコンテンツを彼の友人ユーザ３１１２のうちの一人と共有／推奨する。ＳＭＳメッセージは、前後関係情報（アプリケーションのバージョン、送受話器から探索されるクライアント属性、仲間の電話番号、コンテンツＩＤ等）と共にアプリケーションによってサービス・バックエンド向けの短いコードに合わせ送信される。

ＳＭＳメッセージは、ＳＭＳデータ通信網３１１６とＳＭＳゲートウェイ３１１８によりサービスバックエンド３１１４へ送られる。バックエンド３１１４は、彼の友人がアプリケーション／コンテンツ細目を彼に推薦したと彼に知らせるＳＭＳメッセージを作成して意図する受取人に送出する前にコンテンツを誰が誰へ転送したかとコンテンツ情報とを記録する。ＳＭＳメッセージは、ＳＭＳゲートウェイ３１１８とＳＭＳデータ通信網３１１６とを経由して受け取りユーザ３１１２まで伝わる。

一部実施形態によれば、ＳＭＳメッセージはまた携帯端末クライアントのＯＴＡ（空中線経由）ダウンロード用のＵＲＬを含む。受取人はこのＵＲＬをクリックすることができ、彼の送受話器に携帯端末クライアントをダウンロードすることができる。アプリケーションはまた、ハイライトシーンすなわち推奨されたコンテンツ細目の短縮バージョンを含めることができる。

前述の内容は明確さを目的に若干の詳細に説明したが、その原理から逸脱することなく幾つかの変形と改変が可能であることは明白であろう。本願明細書に記載した方法と装置の両方を実施する多数の代替的な方法が存在することに、留意されたい。従って、本実施形態は例示であって限定的でないと考えるべきであり、本創作の発明本体は本願明細書に記載した細部、すなわち添付特許請求の範囲の範囲と均等物内で改変することができるものに限定すべきではない。

Claims (18)

1. 携帯端末遠隔通信装置のユーザに注目対象の広告を提示する方法であって、
   前記携帯端末遠隔通信装置の１つ以上のプロセッサが、利用統計を収集するステップと、
   前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記利用統計をサーバシステムへ送信するステップと、
   前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記サーバシステムから推奨注目対象の広告を受信するステップであって、前記広告は、前記収集した利用統計に少なくとも一部基づき、前記サーバシステムにより推奨される、ステップと、
   前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記携帯端末遠隔通信装置を介して前記ユーザに１以上の推奨注目対象の広告を提示するステップと、
   を実行する、方法であり、
   前記利用統計は、前記携帯端末遠隔通信装置の前記ユーザのアプリケーションおよび／またはコンテンツ利用行為を追跡することにより入手した追跡情報を含み、
   前記追跡は、電子コンテンツの少なくとも１片に結びついたライセンスに従って実行され、
   前記ライセンスは、前記携帯端末遠隔通信装置の上で動作するデジタル権利管理エンジンにより実行されるように構成されている、
   方法。
2. 前記携帯端末遠隔通信装置は、前記サーバシステムとは間欠的にしか通信せず、前記携帯端末遠隔通信装置が前記サーバシステムと通信状態にないときを含め、前記利用統計が折に触れ収集される、請求項１に記載の方法。
3. 前記広告を、前記携帯端末遠隔通信装置の地理学上のロケーションと日時と前記ユーザの人口動態情報とからなるグループから選択される１以上の規範に基づき注目対象とする、請求項１に記載の方法。
4. 前記利用統計を、ＳＭＳ技術を用いて前記サーバシステムへ送信する、請求項１に記載の方法。
5. 利用統計は、広告の再生回数、再生／停止事象、ユーザの広告クリック、コンテンツ細目または広告の一部のユーザによる前方スキップおよび／または後方スキップ、コンテンツ細目に対するユーザの投票、コンテンツ細目または広告に関連する調査に対する所定の応答を伴ったユーザの応答、前記ユーザによる完全な調査のスキップ、コンテンツ細目のその全体提示、前記ユーザのアプリケーションおよび／またはコンテンツの転送行為とからなるグループから選択された１以上の種別の事象を含む、請求項１に記載の方法。
6. 前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記サーバシステムから携帯端末装置識別子を受信するステップをさらに含み、前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記利用統計を前記サーバシステムが前記携帯端末遠隔通信装置に関連付けられるよう前記利用統計を前記サーバシステムへ送信する、請求項１に記載の方法。
7. 携帯端末遠隔通信装置のユーザに注目対象の広告を推奨するサーバシステムの方法であって、
   前記サーバシステムの１つ以上のプロセッサが、前記ユーザのアプリケーションおよび／またはコンテンツ利用行為の利用統計を受信するステップと、
   前記サーバシステムの１つ以上のプロセッサが、前記ユーザの選好性に関し推定を行なうステップと、
   前記サーバシステムの１つ以上のプロセッサが、前記ユーザの選好性に一部基づき、前記ユーザに向け注目対象の広告の推奨を生成するステップと、
   前記サーバシステムの１つ以上のプロセッサが、１以上の前記携帯端末遠隔通信装置に前記推奨を送信するステップと、
   を実行する、方法であり、
   前記利用統計は、前記携帯端末遠隔通信装置の前記ユーザのアプリケーションおよび／またはコンテンツ利用行為を追跡することにより入手した追跡情報を含み、
   前記追跡は、電子コンテンツの少なくとも１片に結びついたライセンスに従って実行され、
   前記ライセンスは、前記携帯端末遠隔通信装置の上で動作するデジタル権利管理エンジンにより実行されるように構成されている、
   方法。
8. 前記推奨はさらに、前記携帯端末遠隔通信装置の地理学上のロケーションと日時と前記ユーザの人口動態情報とからなるグループから選択される１以上の規範に少なくとも一部基づく、請求項７に記載の方法。
9. 前記利用統計は、広告の再生回数、再生／停止事象、ユーザの広告クリック、コンテンツ細目または広告の一部のユーザによる前方スキップおよび／または後方スキップ、コンテンツ細目に対するユーザの投票、コンテンツ細目または広告に関連する調査に対する所定の応答を伴ったユーザの応答、前記ユーザによる完全な調査のスキップ、コンテンツ細目のその全体提示、前記ユーザのアプリケーションおよび／またはコンテンツの転送行為とからなるグループから選択された１以上の種別の事象を含む、請求項７に記載の方法。
10. 携帯端末装置識別子を第１の携帯端末遠隔通信装置へ送信するステップと、前記携帯端末装置識別子と幾つかの受信した前記利用統計との関連性に少なくとも一部基づき、幾つかの受信した利用統計が前記第１の携帯端末遠隔通信装置に由来することを検証するステップとをさらに含む、請求項７に記載の方法。
11. 前記携帯端末遠隔通信装置はサーバシステムと断続的にしか通信しない、請求項７に記載の方法。
12. 利用統計を収集し注目対象の広告を推奨する目的で、携帯端末遠隔通信装置を識別する方法であって、
    サーバシステムの１つ以上のプロセッサが、前記携帯端末遠隔通信装置から利用統計を収集するステップと、
    前記携帯端末遠隔通信装置の１つ以上のプロセッサが、サーバシステムから携帯端末装置識別子を受信するステップと、
    前記携帯端末遠隔通信装置の１つ以上のプロセッサが、サーバシステムが前記利用統計に前記携帯端末遠隔通信装置を関連付けることができるよう、前記サーバシステムに前記利用統計を送信するステップと、
    前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記サーバシステムから推奨注目対象の広告を受信するステップであって、前記送信された利用統計に少なくとも一部基づき前記広告を注目対象とするステップとを含む、方法であり、
    前記利用統計は、前記携帯端末遠隔通信装置のユーザのアプリケーションおよび／またはコンテンツ利用行為を追跡することにより入手した追跡情報を含み、
    前記追跡は、電子コンテンツの少なくとも１片に結びついたライセンスに従って実行され、
    前記ライセンスは、前記携帯端末遠隔通信装置の上で動作するデジタル権利管理エンジンにより実行されるように構成されている、
    方法。
13. 前記携帯端末遠隔通信装置は前記サーバシステムと断続的にしか通信しない、請求項１２に記載の方法。
14. 前記携帯端末遠隔通信装置の１つ以上のプロセッサが、非公開鍵を用いて前記利用統計に署名するステップをさらに含む、請求項１２に記載の方法。
15. 前記利用統計の送信に関し、前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記サーバシステムと折衝するステップをさらに含む、請求項１２に記載の方法。
16. 前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記携帯端末装置識別子が信頼の置けるソースから受信されたことを検証するステップをさらに含む、請求項１２に記載の方法。
17. 前記携帯端末遠隔通信装置の１つ以上のプロセッサが、前記携帯端末装置識別子を、前記携帯端末遠隔通信装置と前記サーバシステムとの間の３回以下の交換ステップを用いて取得する、請求項１２に記載の方法。
18. 利用統計を収集し、注目対象の広告を推奨する目的で携帯端末遠隔通信装置を識別する方法であって、
    サーバシステムの１つ以上のプロセッサが、該サーバシステムから前記携帯端末遠隔通信装置へ携帯端末装置識別子を送信するステップと、
    前記サーバシステムの１つ以上のプロセッサが、前記携帯端末遠隔通信装置から利用統計を受信するステップと、
    前記サーバシステムの１つ以上のプロセッサが、前記携帯端末装置識別子と前記受信した利用統計の関連性に少なくとも一部基づき、前記受信した利用統計が前記携帯端末遠隔通信装置に由来することを検証するステップとを含む、方法であり、
    前記利用統計は、前記携帯端末遠隔通信装置のユーザのアプリケーションおよび／またはコンテンツ利用行為を追跡することにより入手した追跡情報を含み、
    前記追跡は、電子コンテンツの少なくとも１片に結びついたライセンスに従って実行され、
    前記ライセンスは、前記携帯端末遠隔通信装置の上で動作するデジタル権利管理エンジンにより実行されるように構成されており、
    前記携帯端末遠隔通信装置は、前記サーバシステムと間欠的にしか通信しない、方法。

Images