JP2015149072A - 分散型デジタルメディア計測および報告システム - Google Patents

Abstract

【課題】デジタル音楽トラック等の、デジタルメディアファイルの使用を計測する、分散型ディジタルメディア計測及び報告システムを提供する。【解決手段】分散型デジタルメディア計測報告システムは、コンピュータベースのインフラストラクチャから複数の消費者向けデバイスに対してデジタルメディアファイルを提供する。消費者向けデバイスは、計測データを生成するために、予め定義された範囲を超えて続くメディアファイルの再生回数を計測し、次にその計測データをコンピュータベースのインフラストラクチャへ自動的に報告する。【選択図】図２

Description

本発明は、分散型デジタルメディア計測および報告システムに関し、当該システムは、デジタル音楽トラック等の、デジタルメディアファイルの使用を計測する。

ｉＴｕｎｅｓ等のオンライン、ウェブベースの音楽ストアは、音楽トラックおよびビデオトラック等のメディアファイルを取得するために消費者にとって有力なメカニズムとなっている。しかし、これらは、一般にトラックダウンロードごとの支払い基準に応じて動作する。すなわち、音楽トラックまたはビデオファイルをダウンロードするために支払いを行うが、その場合望むたびに視聴できる。具体的に言うと、ダウンロードしたトラックが実際に再生されるかどうかに関する、またはそのような再生の程度に関するメディアファイルのあらゆる計測または測定データを供給する、コンピュータベースのインフラストラクチャ（例えば、サーバ）へのフィードバックが存在しない。

本発明は、デジタルメディアファイルの使用を計測する方法であって、
コンピュータベースのインフラストラクチャから複数の消費者向けデバイスに対してデジタルメディアファイルを提供する工程と、
前記消費者向けデバイスが、計測データを生成するために、予め定義された範囲を超えて続くメディアファイルの再生数を計測する工程と、
前記消費者向けデバイスが、自動的に前記計測データを前記コンピュータベースのインフラストラクチャへ報告する工程と、
を備える方法である。

本発明の実施においては、ある範囲を超えて続くメディアファイルの実際の再生を監視し、その情報を、そのメディアファイルを供給したコンピュータベースのインフラストラクチャと自動的に共有する。これが優れている理由は、聴者にとって本当に関心のあるファイルに関してはるかに情報量の多いデータを提供し、従ってダウンロード（例えばメディアファイルの処理および配信）を提供する技術的インフラストラクチャを最適化できるからである。

例えば、トップ２０のチャートが通常はダウンロードに基づいている。仮に、２つの異なるトラックが両方とも週に１００００回ダウンロードされるとする。両者は、週間チャートでは、同じ位置を与えられる。しかし仮に、一方のトラックが他方のトラックの２倍の頻度で再生されたとすると、そのことを測定することができ、従ってより高いサーバ性能およびより優先度の高いダウンロード等の、より多くの技術的リソースを用いてそのトラックをサポートすることができ、その結果、そのトラックの後の消費者が、より良いダウンロード経験を得ることができるようになり、また、音楽ダウンロードインフラストラクチャの技術的リソースをより効率的に活用できるようになる。

リリース直後にダウンロードされるが第一波のリスナーによって大量に再生されるトラックも、それほど大量に再生されないトラックよりもヒットする可能性がある。それゆえ、それらの潜在的なヒットトラックのために、より多くの技術的リソース（例えば、より高いサーバ性能、優先ダウンロード、潜在的なリスナーによって訪問されるオンライン音楽サイトにおいて目立たせること、等）を利用可能にすることができるである。‘トラック再生’情報は、インフラストラクチャ側での課金目的および報告目的のためにも使用され得る。

計測データは、以下のために自動的に使用され得る。
・所定のロケールに対してデジタルメディアサービス上に存在しないトラックを識別する。
・さらなる処理のためにトラックを識別する。ここで前記さらなる処理は、１つ以上のトラックに対する追加のまたは更新されたメタデータの取得の必要性を識別する工程、または、異なるデジタルメディアファイルフォーマットを使用して１つ以上のトラックをユーザに提供する工程を含む。前記異なるデジタルメディアファイルフォーマットはＤＲＭプロテクション形式を利用することができ、またはそのようなＤＲＭプロテクションを利用しないことができる。
・さらなるメディアコンテンツを特定のユーザに推奨する。ここでそのユーザのメディア再生嗜好について収集された評価指標（metrics）が、将来デジタルメディアコンテンツを観る、読む、聴くことに対してユーザの可能性のある嗜好に関する計算を支援するために使用される。

予め定義された再生範囲は設定可能であり、トラックを再生しているユーザとこれまでのトラックをスキップしているユーザとを区別するために、十分長いことがあり得る。

本発明の別の側面は、デジタルメディアファイルの使用を計測するシステムであって、
（ａ）複数の消費者向けデバイスに対してデジタルメディアファイルを提供するコンピュータベースのインフラストラクチャと、
（ｂ）（ｉ）計測データを生成するために、予め定められた範囲を超えて続くメディアファイルの再生回数を計測する、（ｉｉ）次に、前記計測データを前記コンピュータベースのインフラストラクチャに自動的に報告する、ソフトウェアでプログラムされた消費者向けデバイスと、
を含むシステムである。

図１は、自動コンテンツ取得および準備を実施するシステムの全体構造を概略的に描写する。 図２は、自動コンテンツ取得および準備を実施するシステムのより詳細な概略分解である。 図３は、システムを通じたコンテンツの処理フロー図である。 図４は、この発明によって定義されるような計測構成要素および報告構成要素を含むシステム全体の概観図である。

好ましい実施形態では、高度に拡張可能および適合可能なコンテンツ取得サービスフレームワークを含むコンテンツ取得エンジンが存在する。取得サービスフレームワークは全２バイト文字セットを完全にサポートし、ＡＰＡＣ領域を含むあらゆる文字セットで世界のあらゆる場所のためにコンテンツを取得し、準備することができる。コンテンツは、４つの主要な（音楽）レーベル、世界最大のインディーズのデジタルカタログから、および主要な音楽コンテンツアグリゲータから直接的に取得される。

企業規模のコンテンツ取得サービスフレームワークは、新しいコンテンツソースの高速な統合を可能にし、新しい領域でのサービス展開を直ちに手助けする。そのフレームワークは、複数のトランスポートメカニズム、ハンドシェイク、およびメタデータ形式を処理する新しい取得コネクションの高速の視覚的およびプログラム的な構築をサポートする。付加価値妥当性確認および検証のために、第三者のコンテンツメタデータソース（例えば、Ｍｕｚｅ（商標）、ＡＧＭ（商標）、グレースノート（商標））への統合と共に、コンテンツおよびメタデータの、自動検証、妥当性確認およびロードがサポートされる。

統合監視および警告例外条件が、高い処理の可視性および応答性のために提供されている間、正確な動作およびスケジュール化されたタスクサイクルの完了を保証するために、内蔵された処理監視がサポートされる。

・既存のデータストアでのアーティスト、アルバムおよびトラックの非常に大きな重複を解決する。
・例えば売上を促進するために、画期的なイベントを記念するために、または種々の領域でのリリースのために、音楽レーベルがアルバムを何度も再リリースする。同一のアーティストが種々のリリースを背景に異なって知られている。トラックは、多くのバージョンのシングル、アルバムおよび利用可能な他のリリースから複製される。
・複数のアーティストがリリースに貢献している時に彼らはめったに全て正確に認識されない。このことは、お気に入りのアーティストによってなされた作品を検索するためのオンラインシステムの能力を制限する。
・多くの状況で、消費者を保護するために親への勧告／露骨なメタデータフラグをサポートする必要がある。いくつかのレーベルが合理的な範囲を提供する一方、多くはそうでなく、このデータは、複数のソースから照合され、主体的および受け身的な人間の処理によってサポートされる必要がある。
等、コンテンツ取得および統合の領域で多くの課題がある。

本発明の実施は、一連の高機能データクリーニングツールや人間サポート処理を介して、これらの問題の全てを解決する。

図１は、様々なデータソース１（音楽レーベル、コンテンツアグリゲータ）から、第３者メタデータソース２との統合、ロード／取得領域３を通じて、データクレンジング／初期データ重複排除のためのステージング領域４、次に製品データベース（不図示）を通じた販売に先だってテストするための単一の試作データベース６への様々なソースの統合重複排除（統合ボックス５）といった、データパスの全体を説明する。

複数のソースからの音楽カタログのクレンジングおよび統合の後に、コンテンツファイル自体は準備および管理を必要とし、その結果、サービスによって提供されるコンテンツは、それにアクセスするだろう大量のデバイスに適合し、適切なものとなる。

複数のプラットフォーム上での複数のデバイスへのサービスの配信は、特定のデバイスまたは領域で必要なように、または特定の契約上の義務の結果として、コンテンツが、ＡＡＣ＋、ｅＡＡＣ+、ＷＭＡおよびＭＰ３等の多くの形式で、種々のビットレートで利用可能であることを必要とする。最終的なコンテンツ形式が音楽レーベルから利用可能であることもあり、その形式は高品質なリファレンスバージョンから創出され（トランスコードされ）る必要がある場合もある。

種々のプラットフォームは種々のデジタル権利管理ソリューション（例えば、Ｗｉｎｄｏｗｓ ＤＲＭ（商標）、ＯｍｎｉＰｌａｙ（商標）、ＯＭＡｖ２（商標）、 ＰｌａｙＲｅａｄｙ（商標））を有する。コンテンツファイルも種々のプラットフォームに特有の異なるコンテナ／ラッパを有する。

音楽コンテンツをライブサービスに公開する前に、様々なチェックが実行される必要がある。
・正確なメタデータおよび物理コンテンツリソースが正しく準備されている必要がある。
・リリース前に領域によって出版権が確認される必要がある。
ことを含む。

本発明の実施は、これらの目的の全てを達成するために、および高機能マルチデバイス、マルチプラットフォーム無制限ダウンロード音楽コンテンツサービスを配信するために、必要とされるインフラストラクチャやサービスを提供する。

処理全体のステージは、
コンテンツ重複除外
・入力コンテンツのクレンジング
・アーティストの重複除外
・リリースの重複除外
アーティスト割り当て
・アーティストはリリースに正確に起因する
・正確な主アーティスト割り当ておよび副アーティストへのリンクおよびサーチ
・ジャンルメンテナンス
アダルトコンテンツ
・レーベルからの露骨なメタデータを確認
・マニュアル視覚調査
・外部メタデータチェックおよびクロスリファレンス（Ｍｕｚｅ（商標）、ＡＧＭ（商標）およびＧｒａｃｅｎｏｔｅ（商標））
コンテンツ準備
・自動検証およびコンテンツ資産のトランスコード
・最終的な形式のコンテンツファイルがレーベルから配信されたかどうかを確認
・最終形式ファイル構造およびコンテナの妥当性確認
・ソースから利用可能でない最終形式ファイルのトランスコードを実行する
・並列トランスコードクラスタの活用により馬力およびスループットを向上させる
・ＤＲＭエンコーディングおよびコンテンツファイルラッピング／コンテナを管理
・コンテンツ配信サービスへのマーシャルコンテンツ資産
コンテンツ公開
・コンテンツの公開および権利管理
データクレンジングおよび重複除外

統合および公表プロセスのフェーズは以下に分解され、図２で説明される。

図２において、複数のデータソース２１（Ｍｕｚｅ（商標）、２４／７（商標）、ＤＸ３（商標）およびその他等の、音楽レーベル、アグリゲータ）および（ＦＴＰｐｕｓｈ、ＳＯＡＰ ｏｖｅｒ ＨＴＴＰＳ等の）様々な供給／転送メカニズム２２は、どのようにそれらのデータがロード領域２３にロードされるのかを示すために表示される。図２に示されるように、ロード領域２３内には様々な構成要素がある。ステージング領域２４が大容量データベースの左下に示され、データ統合サービスデータベース２５に次に統合されるデータをクレンジングするために、好ましい実施形態で利用される様々なステージング領域を説明する、“ファイル”処理ボックスが示される。クレンジングされたデータは、テストや次のそれぞれの配信のために、次に試作データベース２６にロードされ、および次に製品データベース２７にロードされる。音楽ロードアプリケーションウィンドウ２８は、マニュアル確認／クリーンアップのためにフラグを立てられているデータの処理を説明する。

ステージング領域２４の各ステージは、ツールサポートマニュアル処理から構成され、それによってツールは、様々な利用可能なソースからのメタデータを解析し、可能であれば重複データ（すなわち、デジタルメディアの同一ピースを参照する記述メタデータエントリ）を自動的に認識し、自動化された処理が重複排除および統合を自動的に実行するためにデータソースから利用可能な十分な情報を有していないマニュアル訂正のために、いくつかの項目がフラグを立てられている。

取得されるべき入力データは、（ソースデータホルダの国際標準に従った）種々の形式のＸＭＬ、通常のテキストファイルおよびＥｘｅｌ表計算ソフトを含む、多様な異なる形式で到達してもよい。全てのそのような形式はロード領域２３にロードしており、次に様々なステージング領域２４を通過し、それぞれはそうしたメタデータの標準化を増大させる。続く処理の説明では、配信および使用のための製品データベースへのクレンジングされたデータの取得の前に、まるで単一のステージング領域内で行われるかのように、様々なタイプのメタデータの解析、変換、重複除外が提供される。好ましい実施形態では、それらのアクションは複数のステージング領域に渡って行われ、それぞれは自身のデータストアを利用する。

画像やデジタルメディアファイル等の追加データはメタデータを伴ってもよく、解析される必要があり、必要ならば、適切にトランスコードされる。例えば、好ましい実施形態では、メタデータに定められているトラック継続時間は、メタデータを検証する１つの方法として、実際のデジタルメディアファイルから抽出されたトラック継続時間に対してクロスチェックされる。

入力データは、（米国英語および英国英語等の）転置文字および変形スペル等の、共通の印刷エラー／転写エラーに対してチェックすることによって、および、可能であれば既知のクリーンなデータセットとの比較によって、クレンジングされる。

既知のクリーンなデータセットは、変形アルバムタイトルや、データ重複除外およびクレンジングを手助けするための他のヒントと共に、例えば“Ｇｅｏｒｇｅ Ｓｃｏｔｔ”および“Ｇｅｏｒｇｅ Ｃ. Ｓｃｏｔｔ”が、同一のアーティストを言及する変形アーティスト名称に関して、正確であると知られている情報を含むリファレンスデータベースである。追加の多量のメタデータが取得されクレンジングされるにつれて、リファレンスデータベースは、それに応じてサイズおよび範囲が増加し、以前のデータ取得経験から“学習する”ことをシステムに許可することが不可欠である。

データが複数の異なるソースから提供される場合、ツールは異なるバージョンを比較し、リファレンスデータベースで利用可能な情報に従って重みづけされた、多数決システムに基づいて、“正しい”メタデータ項目を選択する。

例えば、３つのデータソースが所定のトラックについての情報を提供すると仮定すると、入力データは、以下のテーブルに与えられ、「最終」の列はツールによって包含のために選択された最終データを示す。

上記の例では、ソースＡはトラック番号を除いた全ての要素に対する訂正情報を含み、一方ソースＢおよびソースＣは他の領域で正しくないまたは不足した情報を含むことが分かり得る。リファレンスデータベースおよび転写エラーアセスメントプロトコルは、ソースＢが同一のトラックおよび他の２つのデータソースを参照することを認識するのを補助し、一方多数決は最終の列がベストな質（すなわち、最も共通の、それ故最も正確である可能性がある）を獲得することを保証する。

ユーザ設定可能な、類似度の閾値（好ましい実施形態では一般に６５%−８５%の類似度）が到達された場合、最終データは、製品使用のためにコアデータベースに移行される前に、マニュアル確認のためにフラグを立てられる。その範囲外の類似度の値を示す項目は、存在するコンテンツの複製であるとして自動的に廃棄され、または、新しいコンテンツであると明確に認識されたものとしてコアデータベースに自動的に移行される。

マニュアル確認の目的は、自動解析が、人間の判断を必要とする十分あいまいなデータに帰結することの追加のチェックを提供するだけでなく、追加のボーナストラックを有するアルバムのリリース等の、類似するが興味深い変形がシステムに保存されることを保証することである。

類似度の閾値は、以下の１つ以上を含むがそれらに限定されず、関連データが利用可能である、様々なファジー理論パターンマッチング技術を使用して、予め開示されたクリーンなリファレンスデータベースを使用することによって、取得された、最終データとソースデータとの関係の統計関数として計算される。
１．ＩＳＲＣ（国際標準レコーディングコード）値のクロスリファレンス
２．ＵＰＣ（統一商品コード）値のクロスリファレンスおよびチェックサム妥当性確認
３．所定のリリースまたはアルバムにおけるトラック番号
４．リリースまたはアルバム内の個々のトラックの継続時間およびそのリリースまたはアルバムの全体継続時間
５．クレンジングされ簡易化されたバージョンのそのようなテキストを使用したアーティスト名称およびトラックおよびアルバム／リリースのタイトルのパターンマッチング

そのクレンジングは、無関係のワード（“ｔｈｅ”“ａｎｄ”等）を取り去ることや、（例えば購入をマッチングするためにｅ−ｇｒａｖｅを単純な“ｅ”に変換する）マッチングのためにアクセント記号付き文字の標準形式への変換や、“ｎｉｎｅｔｅｅｎ”よりはむしろ“１９”（または代替実施形態において逆もまた同じ）等の、汎用標準化データに対してパターンマッチングが実行されることを保証するために、数列を同等のワードへ変換すること、逆もまた同じ、等のあいまいな文字列の標準化、等の処理を含む。クレンジング処理もまた、好ましい実施形態において、バンド名称“Ｔｈｅ Ｔｈｅ”等の珍しい名称が明確に保存されることを保証するために、例外を承知している。

６．種々の領域で種々の日付を許可する、オリジナルリリースの日付

日付クレンジング処理の間、手順は、上述したようなクリーンな“リファレンスデータベース”と、好ましい実施形態において、たとえわずかに異なる目的のためにアクセスされても、同一のデータベースである“コア”コンテンツデータベースと、の両方を利用する。

コアコンテンツデータベースは、新しいデータ−コアコンテンツデータベースに予め存在していないデータ−と、データソースからメタデータを取得する時のデータ更新と、を区別するためにアクセスされる。入力データが現在のメディアコンテンツ記述子に対する更新であることを識別するために類似のファジー理論マッチング技術が使用される。

そのような更新は、アルバムのタイトルの変化等の、メタデータに必要とされる実際の変化、または現在のアルバム、トラックまたは他のデジタルメディアリリースについての追加情報の“埋め戻し”を構成してもよく、それによって新しく取得されたメタデータは現在のメタデータ記録に追加される。

取得処理の間、そのような更新は、新しいメタデータに対して提供されるのと同一のチェックを受ける。

コンテンツ取得データは、好ましい実施形態おいて、次の報告生成のために会計検査データベーステーブルに記録される。記録された詳細は、アーティスト、タイトル、項目に対する取得処理の成功または失敗理由、これが新しい、更新された、埋め戻されたまたは消去された項目を表すかどうかを示す記録、メタデータの（複数の）ソース、および結果としてどのメタデータの項目が修正されたかに関する記録、のうちの１つ以上を含む。

この会計監査は、いつでも利用可能な公開コンテンツに関する報告生成のために、および、例えば現在公開されているコンテンツデータベースでのローカルチャートまたは国際的チャートの人気のある音楽またはコンテンツの範囲を決定するために実行されるべき解析のために、所定の取得のロールバックを提供する。

図３は、全体処理の好ましい実施形態を説明する。十分管理されたＨＡ／２４−７製品制御環境（警告／監視）３１−このブルーボックス内のフローは左から右であり、上のテキストで詳述されるように、処理の主要なステージを説明する。データマネジメントツールパッケージソフト３２−各ボックスは、メタデータを処理する処理全体のために必要とされる特定の種類のメタデータマネジメントを示す。このシステムに直接関連する２つは、重複除外およびリリースバージョニング４１および、計測アクティビティ／報告アクティビティのために、コンテンツトラッキング５５のみである。

ロード領域は、
・特定の領域のための未加工メディアファイルメタデータを取得するために使用されるロード領域である、ローカル取得センター（ＬＩＣ）３３、
・データソース（音楽レーベル、アグリゲータ等）である、権利所持者／アグリゲータ３４も含まれ、
・推薦目的でのトラック間クロスリファレンス等の、情報量が豊富なメタデータを提供するために使用される、追加の専門メタデータソースである、リファレンスメタデータ３５、
・Ｇｒａｃｅｎｏｔｅ（商標）３６−提供されるメタデータの種類を説明するために分解された、リファレンスメタデータプロバイダの特定の具体例、
を含む。

処理全体は、未加工メタデータがロード領域３３、３４、３５および３６から取得され、様々なステージング領域３７に到達することである。そのメタデータは、リファレンスデータベース（ＯＭＮＩデータ保管サービスデータベース４０）を使用した自動クレンジングを含むファジー理論サービス３９を使用して、および、（重複除外およびリリースバージョニング４１）に示されるマニュアルクレンジングを使用して、次にクレンジングされる（妥当性確認および準備３８）。また、あらゆる追加のメディアファイル形式は、必要ならば、リファレンスファイルからトランスコードすることによって生成される（符号化サービス４２）。

チャートデータ等の追加のメタデータは、リファレンス・メタデータ・データソース（チャートリッパー４３）および様々な追加のソース（ボリューム／チャートコンピュータ（Ｃｏｍｐｓ）４５に供給している、ＨＴＴＰ４４）から取得され、また、統合コンテンツユニバース４６を形成するために一般的に取得されたメタデータと共に取得、統合／重複排除される。

クレンジングされたデータは、次に、テストするために試作（ヘッドクォーター４７）データベースに公開され、次に製品データベース（公開サービス４８）に公開され、データセンター４９へ至る。そのデータは、Ｇｒａｃｅｎｏｔｅ（商標）バッチサービス５０等の、様々なサービスを使用してアクセス可能であり、外部の記憶場所（公開者／収集ソサイエティ５１）に公開可能である。

コンテンツ機能強化５２は、計測、報告、およびデータ解析手順（トラック再生ステータス、ユーザ生成および供給者生成されたトラック評価の同期、チャートの生成、等）を示す。会計データベース５３は、その処理に注ぎ込む計測データ／会計データのストレージを示す。最後に、ＤＲＭサービス５４は、ＤＲＭプロテクトされたメディアファイルの公開と、その会計データベース５３のために会計データを生成するメカニズムとの両方である。

計測および報告
主要な実施において、デジタルメディアファイルは、コンピュータベースのインフラストラクチャからの複数の消費者向けデバイスのために、主要製品データベース（図２におけるデータベース２７）から取得可能である。消費者向けデバイスは次に、計測データを生成するために、予め定義された範囲を超えて続くメディアファイルの再生回数を計測する。全てのトラック再生／リスニングは、エンジンおよびインフラストラクチャ全体の最適化のために、消費者向けデバイスからサーバへ報告される。加えて、計測データは、
・所定のロケールに対してデジタルメディアサービス上に存在しないトラックを識別するために、：
・１つ以上のトラックに対する追加メタデータまたは更新メタデータの取得の必要性を識別する、または種々のデジタルメディアファイル形式を使用して１つ以上のトラックをユーザに提供する、等のさらなる処理のためにトラックを識別するために、：
ここで種々のデジタルメディアファイル形式は、ＤＲＭプロテクションの形式を利用してもよく、ＤＲＭプロテクションの形式を利用しなくてもよい。
・さらなるメディアコンテンツを特定のユーザに推奨するために、：
ここでそのユーザのメディア再生嗜好について収集された評価基準は、将来デジタルメディアコンテンツを観る、読む、または聴く、ユーザの可能性のある嗜好に関する計算を補助するために使用される。
使用され得る。

さらに：
・好ましい実施形態において、計測は種々のデバイス上で別に実施され、連結性（ｃｏｎｎｅｃｔｅｄｎｅｓｓ）に基づいて異なる規則性で報告される。
・１以上の種類のデバイス（例えば電話およびＰＣ）を用いた消費者向けデバイスに対する計測データは、典型的な例示的実施形態において、たとえそれが種々のルールおよび形式で種々のプラットフォームに由来するとしても、創出され、収集され、および統合される必要がある。

例示的な実施形態において、システムは、複数の領域で報告を要求する多数の利害関係者へ、複雑な財政および使用量統計を計算し報告することを含むが、それに限定されない、複数のプラットフォームおよび報告設備に渡って、コンテンツ使用量計測ファイルの創出、収集、統合、および管理をサポートする。報告を要求する利害関係者は、主要な音楽レーベル、独立した音楽レーベル、コンテンツアグリゲータ、公開ソサイエティおよびビジネスパートナーを含む。好ましい実施形態において、報告解析は、変動解析および加入者行動報告等の非常に高機能な解析も提供する。

このシステムでのコア計測アクションはトラック再生の記録、または、ムービー、ゲーム、記事またはニュース記事等の、いくつかの他のデジタルメディアファイルの再生の記録である。便宜上、全てのそのようなデジタルメディアコンテンツは、ここでは“トラック”と称され、“トラック”の定義された一群は“アルバム”または“リリース”と称される。

システムは、トラックのいくつかの最小部分が再生された時に、クライアントデバイス上で再生されているものとして、トラックを識別し、その最小部分はメディアの種類に基づいて設定可能であるが、音楽ファイルの場合、一般にトラック長の４％−５％または３０秒のどちらかであるだろう。定義された閾値以下のトラック再生は、そのような簡潔な再生はユーザのこれまでのトラックのスキップによって生成されてもよいので、評価指標または報告目的のために記録されない。

トラック再生のコンテキストもまた評価指標に記録される。コンテキスト情報は、トラックが再生されたクライアントデバイス、そのトラックを再生したユーザ、実際に再生されたトラックの継続時間／割合、および、そのトラックの前または後すぐに再生されたトラック等のトラック再生の内部セッションコンテキスト、のうちの１つ以上を含むがそれらに限定されない基本情報だけでなく、例示的な実施形態において、再生トラックが由来する、アルバム／リリース、再生リスト、チャートまたは他のコンテキストを含む。

計測情報（“評価指標”）がクライアントデバイス上で収集され、サーバに伝達される。評価指標のサーバへの転送の頻度および方法は、デバイスの種類に依存するが、好ましい実施形態において、典型的なシナリオは、以下を含む。
・オンラインのパーソナル・コンピュータ等の、常時接続された高帯域幅デバイスは、一般にできる限り早く評価指標をサーバへ送信する。
・携帯電話機またはローミング車載音楽システム等の、断続的に接続されたまたは低帯域幅デバイスは、一般に、予め定義された間隔で、および／または、“クライアントデバイスが十分な帯域幅が利用可能であることを検出するとすぐに”等の特定のトリガに従って評価指標をサーバへ送信するだろう。

好ましい実施形態において、転送の方法は、推奨要求またはメディアファイル要求またはクライアントデバイスの受信箱に配信されるべきメッセージをサーバに求めるポーリングイベント要求等の、あらゆるイベントにおいてクライアントデバイスがサーバに送信しなければならなかった、現在の通信上に評価指標をピギーバックすることである。別の例示的な実施形態は、評価指標を配信するために特定のメッセージを送信してもよく、そうしたアプローチは、クライアントデバイスが評価指標を有するものの設定可能な期間（一般に６０分）を超えてサーバに送信するためにキューされた他の要求を有しないなら、好ましい実施形態において取られてもよい。

サーバによって受信される評価指標は、好ましい実施形態において、会計データベーステーブルに格納される。そのような評価指標は、ジャンル、アーティスト、年代、音楽公開者、著作権保持者、ユーザについての人口統計情報、ダウンロードまたはストリーミングされたファイルサイズ、その時点でクライアントデバイスにとって利用可能な帯域幅、および報告解析が望まれるあらゆる追加の情報、を含む追加のメタデータのうち、１つ以上の項目を用いて情報量を豊富にされてもよい。好ましい実施形態において、報告目的で格納された評価指標は、ユーザのプライバシを保護するために匿名にされる。

評価指標が記録される第２の主要領域は、ユーザ加入および購入の領域である。特にシステムは、以下のアクション、加入者サービスへの加入、１つ以上のデジタルメディアファイルの購入、加入の修正またはキャンセル、またはトラックのプレビューの再生、のうちの１つ以上をユーザが実行する時が記録されるメカニズムを提供する。サーバに対してなされる全てのそのような要求は、好ましい実施形態において適切に匿名にされて、次の報告生成のために会計データベースに格納される。

会計データベーステーブルは、内部で、および、音楽レーベルまたはムービースタジオ等の第三者のために、の両方で報告を生成するために次に使用されてもよい。

好ましい実施形態において本発明によって生成される典型的な報告は、
・定義された期間においてデジタルメディアサービスへの加入を申し込んだ、または加入をキャンセルしたユーザの数を示す、加入者変動報告、
・加入サービスに対するトラック再生、および／または、何らかのデジタルメディアサービスに対するトラック購入、に基づいて、特定の期間に関して所定のメディア公開者に対して支払うべき使用料を示す、会計報告、
・所定の時間的瞬間に特定のサービス上で着手されているアクティビティを示す、リアルタイム報告、
・例えばデジタルメディアサービスのユーザの音楽リスニング嗜好またはムービーウォッチング嗜好の、所定期間に亘る傾向を示す、傾向報告、
・（例えば、トラック再生、購入、またはユーザ生成されたまたは批評家生成された評価、によって）最も人気のあるデジタルメディアファイルを示す、チャート報告、
・所定期間に亘る加入者によるサービスの使用量を示す、加入者使用量報告、例えば、これは特定のサービス上でダウンロードされたトラックの数またはサイズ等の詳細を含んでもよい、
・メッセージ量、推奨量、およびデジタルメディアサービスの“コミュニティ”側面を通じて送信された他の何らかの通信量を示す、コミュニティアクティビティ報告、
を含む。
報告は、好ましい実施形態において、１つ以上の以下の区分： ジャンル、アダルトコンテンツステータス、年代、公表日または他の日付、アーティスト、公開者、著作権保持者、時間、チャートランキング、ディレクタ、作家／作曲家、クライアントデバイスの種類、デジタルメディアサービス、または他の何らかの格納されたメタデータ、によって分類されることが可能であってもよい。

数値的詳細は、数値全体、平均値、中央値、いくつかの他の統計的基準、またはその組み合わせ、として提供可能であってもよい。報告期間、生成された報告の形式、およびそれらが生成される頻度は、好ましい実施形態において、設定可能でもある。

報告形式は、頻繁に更新されてもよく、一般に、秒またはその一部ごとに定義された間隔で更新してもよいリアルタイム報告のために使用されてもよく、コンピュータ上での観察のために、またはプリントするために意図されるドキュメントとして生成されてもよい。

図４は全体フローを概略的に描写する。コンテンツ取得エンジンが示されており、権利所持者４１（権利ホルダ４１）（例えば、音楽レーベル）や、および、エラー、不一致および複製を取り除き、配信サーバ４４に対してメディアファイルを準備するコンテンツ取得エンジンに、メディアファイルおよび関連するメタデータを提供する第三者メタデータソース４２、からのコンテンツを伴って、上述したように動作する。メタデータ範囲およびトラック利用可能性評価指標４５は、配信サーバによって上述した報告を生成する報告サービスエンジン４６に対して提供される。デジタルメディア再生データは、クライアント（すなわち、消費者）デバイス５０上で動作するソフトウェアアプリケーションによって収集される。これは、どのトラックが予め定義された範囲を超えて消費者によって実際に再生されたかを記録する、上述したトラック／再生計測データを含む。この計測データは、アプリケーションサーバ４７に供給され、それは順にその計測データを報告サービスエンジン４６へ供給する。計測データはまた配信サーバ４４に送信され、配信インフラストラクチャおよび取得サービスエンジン４３を最適化するために、および上述したように、
・所定のロケールに対してデジタルメディアサービス上に現れていないトラックを識別するために、
・さらなる処理のために、または異なるデジタルメディアファイル形式を使用して１つ以上のトラックをユーザに提供するために、トラックを識別するために、
・さらなるメディアコンテンツを特定のユーザへ推奨するために、
計測データの使用を概略的に表す。

アプリケーションサーバ４７は、使用量報告をサポートサービス４８へ提供するために計測データを使用する。ユーザ推奨は、コンテンツチームツール４９を使用して、収集された再生評価指標に基づいてもなされる。

Claims (31)

1. デジタルメディアファイルの使用を計測する方法であって、
   （ａ）コンピュータベースのインフラストラクチャから複数の消費者向けデバイスに対してデジタルメディアファイルを利用可能にする工程と、
   （ｂ）消費者向けデバイスが、計測データを生成するために、予め定義された範囲を超えて続くメディアファイルの再生回数を計測する工程と、
   （ｃ）前記消費者向けデバイスが、その後、前記計測データを前記コンピュータベースのインフラストラクチャへ自動的に報告する工程と、
   を備えることを特徴とする方法。
2. 前記コンピュータベースのインフラストラクチャは、メディアファイルの処理および配信を最適化するために前記計測データを使用することを特徴とする請求項１に記載の方法。
3. 前記計測データは、所定のロケールに対してデジタルメディアサービス上に存在しないトラックを特定するために使用されることを特徴とする請求項１または２に記載の方法。
4. 前記計測データは、さらなる処理のためにトラックを特定するために使用されることを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 前記さらなる処理は、１つ以上のトラックに対して追加のメタデータまたは更新されたメタデータの取得の必要性を特定することを含むことを特徴とする請求項４に記載の方法。
6. 前記さらなる処理は、異なるデジタルメディアファイル形式を使用してユーザに１つ以上のトラックを供給することを含むことを特徴とする請求項４に記載の方法。
7. 前記異なるデジタルメディアファイル形式はＤＲＭプロテクション形式を利用することを特徴とする請求項６に記載の方法。
8. 前記異なるデジタルメディアファイル形式はＤＲＭプロテクションを利用しないことを特徴とする請求項６に記載の方法。
9. 前記計測データは特定のユーザに対してさらなるメディアコンテンツを推奨するために使用され、前記ユーザのメディア再生嗜好について収集された評価指標は、将来デジタルメディアコンテンツを観る、読む、または聴くことに対するユーザの可能性のある嗜好に関する計算を補助するために使用されることを特徴とする請求項１乃至８の何れか１項に記載の方法。
10. 前記予め定義された再生の範囲は、設定可能であることを特徴とする請求項１乃至９の何れか１項に記載の方法。
11. 前記予め定義された再生の範囲は、トラックを再生するユーザと、これまでのトラックをスキップするユーザとを区別するために十分長いように選択されることを特徴とする請求項１０に記載の方法。
12. 前記コンピュータベースのインフラストラクチャは、前記メディアファイルの権利所持者またはそのエージェントに対して前記計測データを報告することを特徴とする請求項１乃至１１の何れか１項に記載の方法。
13. 前記コンピュータベースのインフラストラクチャは、報告を生成するために前記計測データを使用することを特徴とする請求項１乃至１２の何れか１項に記載の方法。
14. 前記報告は、定義された期間においてデジタルメディアサービスへの加入に申し込んだ、または加入をキャンセルしたユーザの数を示す、加入者変動報告であることを特徴とする請求項１３に記載の方法。
15. 前記報告は、加入サービスに対するトラック再生、および／または何らかのデジタルメディアサービスに対するトラック購入、に基づいて、特定の期間に関して所定のメディア公開者に対して支払うべき使用料を示す、会計報告であることを特徴とする請求項１３に記載の方法。
16. 前記報告は、所定の時間的瞬間に特定のサービス上で着手されているアクティビティを示す、リアルタイム報告であることを特徴とする請求項１３に記載の方法。
17. 前記報告は、例えばデジタルメディアサービスのユーザの音楽リスニング嗜好またはムービーウォッチング嗜好の、所定期間に亘る傾向を示す、傾向報告であることを特徴とする請求項１３に記載の方法。
18. 前記報告は、最も人気のあるデジタルメディアファイルを示す、チャート報告であることを特徴とする請求項１３に記載の方法。
19. 前記報告は、所定期間に亘る加入者によるサービスの使用量を示す、加入者使用量報告であることを特徴とする請求項１３に記載の方法。
20. 前記報告は、メッセージ量、推奨量、およびデジタルメディアサービスの“コミュニティ”側面を通じて送信されたあらゆる他の通信量を示す、コミュニティアクティビティ報告であることを特徴とする請求項１３に記載の方法。
21. 前記報告は、１つ以上の以下の区分：ジャンル、アダルトコンテンツステータス、年代、公表日または他の日付、アーティスト、公開者、著作権保持者、時間、チャートランキング、ディレクタ、作家／作曲家、クライアントデバイスの種類、デジタルメディアサービス、または他の何らかの格納されたメタデータ、によって分類されることを特徴とする請求項１３乃至２０の何れか１項に記載の方法。
22. 前記計測データは、ファイルの再生に関するコンテキスト情報も含むことを特徴とする請求項１乃至２１の何れか１項に記載の方法。
23. 前記コンテキスト情報は、再生トラックが起源であるアルバム／リリース、再生リスト、チャートまたは他のコンテキスト、のうち１つ以上を含むことを特徴とする請求項２２に記載の方法。
24. 前記コンテキスト情報は、トラックが再生されたクライアントデバイス、トラックを再生したユーザ、実際に再生されたトラックの継続時間／割合、トラックより前またはトラックの後にすぐ再生されたトラック等の、トラック再生の内部セッションコンテキスト、のうち１つ以上を含むことを特徴とする請求項２２または２３に記載の方法。
25. 前記インフラストラクチャへの計測データの転送の頻度および方法は、消費者向けデバイスの種類に依存することを特徴とする請求項１乃至２４の何れか１項に記載の方法。
26. 常時接続された高帯域幅消費者向けデバイスは前記計測データをできるだけ早くサーバに送信することを特徴とする請求項２５に記載の方法。
27. 断続的に接続されたまたは低帯域幅消費者向けデバイスは、予め定義された間隔で、または特定のトリガに従って、とのうちの少なくとも何れかで、計測データをサーバに送信することを特徴とする請求項２５に記載の方法。
28. 前記インフラストラクチャに格納されたデータは、ジャンル、アーティスト、年代、音楽公開者、著作権所持者、ユーザについての人口統計情報、ダウンロードまたはストリーミングされたファイルサイズ、その時点でクライアントデバイスにとって利用可能な帯域幅、のリストから選択された１つ以上の追加のメタデータの項目を用いて情報量を豊富にされることを特徴とする請求項１乃至２７の何れか１項に記載の方法。
29. 前記計測データは、ユーザが１つ以上の以下のアクション：加入者サービスへ申し込む、１つ以上のデジタルメディアファイルを購入する、加入を修正またはキャンセルする、またはトラックのプレビューを再生する、を実行する時を含むことを特徴とする請求項１乃至２８の何れか１項に記載の方法。
30. デジタルメディアファイルの使用を計測するシステムであって、
    （ａ）複数の消費者向けデバイスのためにデジタルメディアファイルを利用可能にするコンピュータベースのインフラストラクチャと、
    （ｂ）（ｉ）計測データを生成するために、予め定義された範囲を超えて続くメディアファイルの再生回数を計測し、その後（ｉｉ）前記コンピュータベースのインフラストラクチャへ前記計測データを自動的に報告する、ソフトウェアでプログラムされた消費者向けデバイスと、
    を含むことを特徴とするシステム。
31. 請求項１乃至２９の何れか１項に記載の方法を実行するようにさらに構成されることを特徴とする請求項３０に記載のシステム。

Images