JP2006510946A - 音楽ファイルのネットワーク経由ダウンロードの方法及びシステム - Google Patents

Abstract

本発明は、少なくｔも１つの音楽の好みを取得することにより音楽ファイルをネットワーク経由でダウンロードし、少なくとも１つのネットワークベースの音楽ファイルにアクセスする方法を提示し、音楽ファイルは少なくとも１つの音楽属性を含む。音楽属性は、音楽の好みと比較され、音楽ファイルは比較に基づいてダウンロードされる。

Description

概して、本発明は、音楽収集に関連する。より特定的には、本発明は、ネットワーク内の音楽ファイルの選択に関連し、特に、音楽プレーヤの機能として音楽ファイルをネットワーク経由でダウンロードする方法に関連する。

ディジタルカメラ、カムコーダ、ＴｉｖｏといったディジタルＶＣＲ、インターネット・ラジオ、Ｘｂｏｘといったゲーム・コンソール、インターネット接続可能な冷蔵庫、及び、ＭＰ３プレーヤは、近年のインターネット及びコンピュータ技術によって影響を消費者電子機器のうちのいくつかである。より多くの「従来の」装置の機能（例えば音楽及びビデオの再生及び記録）が、情報を与えること及び電子商取引（e-commerce）といったインターネット接続可能なサービスと組み合わされると、新しい種類の用途が可能となる。

ポータブルＭＰ３及び他の音楽再生装置は、それらの可能性をかなり増加させてきた。ハードドライブ（内蔵ディスク記憶装置）は、数千曲もの曲の記憶を可能とする音楽プレーヤにインストールされてきた。更に、音楽ファイルを再生することが可能な多くの装置は、ワイヤレス・モデムを介してインターネット接続の更なる特徴を有する。これは、曲をインターネットから音楽（ＭＰ３）プレーヤに直接ダウンロードする可能性を許す。しかしながら、これらの装置が有する限られたユーザインタフェースにより、ネットワーク（インターネット）接続を介して利用可能な多数の音楽ファイルを集めるのは非常に実際的でなくなる。

現在の、ハードドライブ記憶装置を有するインターネット接続可能な個人用音楽再生装置は、１６６７曲（５Ｇｂ）乃至１００００曲（３０Ｇｂ）の範囲の容量を有する。これらの音楽プレーヤ（など）の問題点はこれらが、消費者（ユーザ）に頼って、消費者の音楽プレーヤにロードされるべき音楽内容をどのようにしてどこから得るかを決定することである。音楽プレーヤに利用可能なユーザインタフェースは限られているため、ユーザは、自分がプレーヤへ転送しようとする各曲の正確な曲名と位置を入力せねばならない。

従って、上述の不利点及び欠点、並びに他の不利点を克服するために、ネットワークを介して音楽ファイルをダウンロードする方法及びシステムが必要である。

本発明の１つの面は、
音楽ファイルをネットワーク経由でダウンロードする方法であって、
少なくとも１つの音楽選好を取得する段階と、
少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスする段階と、
音楽属性を音楽選好と比較する段階と、
音楽ファイルを比較に基づいてダウンロードする段階とを有する方法を提供する。

本発明の１つの面は、
音楽ファイルをネットワーク経由でダウンロードするシステムであって、
少なくとも１つの音楽選好を取得する手段と、
少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスする手段と、
音楽属性を音楽選好と比較する手段と、
音楽ファイルを比較に基づいてダウンロードする手段とを有するシステムを提供する。

本発明の１つの面は、
音楽ファイルをネットワーク経由でダウンロードするコンピュータプログラムを記憶するコンピュータ読み取り可能な媒体であって、
少なくとも１つの音楽選好を取得するコンピュータ読み取り可能なコードと、
少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスするコンピュータ読み取り可能なコードと、
音楽属性を音楽選好と比較するコンピュータ読み取り可能なコードと、
音楽ファイルを比較に基づいてダウンロードするコンピュータ読み取り可能なコードとを有する、コンピュータ読み取り可能な媒体を提供する。

本発明の上述の及び他の特徴及び利点は、現在の望ましい実施例の以下の詳細な説明を、添付の図面と共に読むと更に明らかとなろう。詳細な説明及び図面は、本発明を単に例示したものであって制限するものではなく、本発明の範囲は添付の特許請求の範囲及びその均等のものによって定義される。

図１に、本発明による音楽ファイルのアクセス及びダウンロードが可能なシステム１００の１つの実施例を概略的に示す。システム１００は、ユーザ１１０、音楽再生装置１２０、ネットワーク接続１３０、及び音楽コレクション１４０を含む。

ユーザ１１０は、音楽再生装置１２０を操作する任意の人であり、ユーザ、人、又は消費者と称されうる。音楽再生装置（ＭＰ３プレーヤ、Ｍプレーヤ、音楽プレーヤ、プレーヤ）１２０は、ＭＰ３プレーヤ、パーソナル・コンピュータ、パーソナル・ディジタル・アシスタント（ＰＤＡ）、携帯型コンピュータ、及び、アナログ又はディジタル電話機といったハンドヘルド型通信装置を含み、ネットワークデータ通信を送信及び受信するための適切なハードウエア及びソフトウエアを有しうる。１つの実施例では、音楽再生装置１２０は更に、データを送信及び受信するためのワイヤレスモデムを含む。１つの例では、音楽再生装置１２０は、公称で８００ＭＨｚの指定帯域を通じて動作するアナログ移動電話機でありえ、又は、音楽再生装置１２０は、公称で８００ＭＨｚ、９００ＭＨｚ、１９００ＭＨｚの、又は、移動通信を搬送することが可能な任意の適当な帯域を介して動作するディジタル移動電話機でありうる。

更なる実施例では、プレーヤ１２０は、ネットワーク１３０と通信することが可能な音声認識システム（ＡＳＲ）を含み、単語認識が可能な音声認識エンジン（ＶＲＥ）を含む。プレーヤ１２０の更なる実施例は、上述の実施例の一部又は全部として機能することを可能とする。本発明の他の実施例では、プレーヤ１２０は、データ記憶、及び／又は、データ検索、及び／又は、データクエリーの受信、処理、及び送信を可能とする。更なる他の実施例では、プレーヤ１２０は、オーディオスピーカ、合成音声出力、テレビジョンの音声部分、ディスプレイ装置、オーディオチャンネル等を含む。

ネットワーク１３０は、ワイヤレス又は固定であり、本発明の１つの実施例ではインターネットを含む。他の実施例では、ネットワーク１３０な、ネットワークサーバ、ファイルサーバ、アプリケーションサーバ及び／又はデータベースサーバにアクセス可能な任意のコンピュータネットワークである。音楽ファイルコレクション（音楽データベース）１４０は、本発明の他の実施例ではデータベースであり、データベースサーバ中に存在しうる。本発明の更なる他の実施例では、音楽ファイルコレクション１４０は、音楽ファイル、個人用オーディオコレクション、又は音楽コンパクトディスク（ＣＤ）にアクセスすること又は格納することが可能なシステムでありうる。音楽ファイルは、ネットワーク１３０を通じた伝送、及び、音楽再生装置１２０上での再生に適した任意のフォーマットでありうる。

システム１００は、ユーザ（消費者）１１０が音楽データベース１４０から曲（音楽ファイル）を収集するための方法を与えることが可能であり、音楽ファイルを音楽再生装置１２０上に一時的に又は永久的に格納する。１つのかかる方法は、ユーザ１１０が自分の個人用オーディオコレクション（ＣＤ）をディジタル化し、これらをＭＰ３等の圧縮フォーマットで自分のプレーヤ１２０に入れることを可能とする。他の方法は、音楽データベース１４０から曲を収集するためにインターネット１３０といったネットワーク接続を使用するシステムを提供する。更に、音楽ファイルを共有する方法はかなり人気があり、従ってインターネット・ベースのファイル供給サービスは、音楽再生装置１２０の１つの実施例に埋め込まれる。プレーヤ１２０の更なる実施例は、曲及びアルバム等の音楽項目の存在についての情報が埋め込まれ、ユーザ１１０が望む又はリクエストする音楽の種類を含みうる。ユーザ１１０のプロファイルは、この種類の実施例では少なくとも１つの音楽専攻を与えるのに必要でありうる。このプロファイルは、音楽の面（アーチスト、年、ラベル、タイトル）に関するユーザの選好（preference）に関する情報、ユーザの音楽コレクションに関する情報、及び／又はユーザの再生行動に関する情報を含みうる。プレーヤ１２０の他の実施例は、従来技術で知られているように、音楽項目に関するメタデータの収集、読み込み、書き込み可能性を有する。メタデータは、音楽ファイルに関連ずる属性をプレーヤ１２０に与えてもよく、アーチスト、曲又はアルバムのタイトル又はリリース年、アルバムのトラック情報を含みうる。システム１００の他の実施例は、ネットワーク１３０にアクセス可能なダウンロード・サイト（データベース）１４０に関する情報がプレーヤ１２０内に埋め込まれることを与える。

本発明の実施例は、図２ａ乃至図２ｄに示されており、音楽収集アプリケーションと共に使用されるグラフィック・ユーザ・インタフェース（ＧＵＩ）の様々なビューを示す。この実施例は、ユーザが、音楽ファイルのダウンロード又は再生によって発生されるイベントに関する全ての詳細を知る必要がないという条件に合致する。ユーザは自分のプレーヤを一目見るとき、音楽収集の進行がどの程度うまくいっているかを大まかに知りたいだけかもしれない。進行がうまくいっていない場合、ユーザは、問題を解決するための行動を起こそうとしうる。図２ａ乃至図２ｄの実施例では、ＧＵＩは音楽収集及びダウンロードの情報複雑性を調整及び概略するために使用される。

全ての４つの図面は、図２ａ、図２ｂ、図２ｃ、及び図２ｄの共有性質を含む共有特徴（全体実施例）を有する。第１の全体実施例では、音楽収集アプリケーション用のインタフェース（ＧＵＩ）が、従来技術で知られている多くのプレーヤについて標準の寸法である、２４０×３２０の画面の寸法へと最適化される。第２の全体実施例は、ユーザが音楽を収集するために行いうるステップを示すタブへとインタフェースが分割されることを与え、本発明の１つの実施例に対するタブは、図２ａ、図２ｂ、図２ｃ、及び図２ｄに対応する。

図２ａ中で強調するサーチタブ２１０は、音楽ファイルについてのネットワークサーチを支援するためにユーザが使用しうる実施例を示す。図２ａの実施例は、ユーザが、自分が収集しようとするアーチスト名２１５、アルバム２２０、又は曲２２５を入力するためのウィンドウ（入力位置）を与える。サーチの結果は、アーチスト、アルバム、及び曲の順序とされる階層木構造２３０の形で表示される。ユーザが、例えば、バンド「Ｇａｌａｘｙ５００」の音楽を探しているとき、結果フィールドは、このバンドのアルバムを表示し、これらの中に各アルバムに属する曲を示す。ユーザは、ここで、従来技術で知られている入力装置を用いて、自分が収集しようとする任意の組合せのアルバム及び曲を選択する。

図２ｂ中に強調する状態タブ２３５は、音楽収集アクションのフィードバック又は現在の状態についての実施例を示す。この状態の様々な面、例えば、利用可能なサーバの数、ダウンロードの速度、チャート情報の利用可能性は、小さい画面寸法が与えられているときは視覚化するには複雑すぎるため、本発明の１つの実施例では漫画のキャラクタの顔（キャラクタ）２４０が用いられる。キャラクタ２４０は、感情的なインタフェースとして作用し、音楽収集アプリケーションの状態をユーザに伝えるために、感情的な顔の表現によりユーザへ自然且つ瞬間的なフィードバックを与える。簡単化されたＯＣＣ感情モデル（Ortony, Clore及びCollinsの感情モデル）は、多くのイベント及びアクションを感情の状態及びそれらの強さへマップするのに使用される。ＯＣＣモデルから選ばれたサブセクションは、人間の種類に注目し、音楽収集アプリケーションの内部感情状態を世界へ伝えるキャラクタ２４０の表情を作成する。人間の種類の感情は、一組の３つの異なった感情表現、即ち、うれしさ、怒り、及び悲しみへマップされる。簡単にいうと、全ての肯定的なイベント及びアクションはうれしさを生じさせ、全ての否定的なイベントは悲しみを生じさせ、全ての否定的なアクションは怒りを生じさせる。

イベントとアクションの区別は、説明責任（accountability）に基づく。インターネット接続の失敗について人のせいにすることはできないが、プレーヤ以外の別のネットワーク接続の特定の人がユーザのダウンロードをキャンセルすると、キャラクタはその人のところで「怒り」でありうる。各感情的な状態の強さは、本発明の１つの実施例では所定の変数に基づくものである。

本発明のこの実施例では、感情の合成に関連する４つのイベントが識別される。第１に、チャート・エージェント（以下説明する）がインターネットから新しいヒット・チャート情報を取得すると、NewChartInfo(新チャート情報)イベントが生成される。新しいチャート情報は、キャラクタ２４０をうれしくさせる。第２のイベントは、NewGoal(新ゴール)イベントである。音楽収集エージェント（以下説明する）は、新しい曲又はアルバムを収集することを決定すると、このイベントを発生する。新しいゴールを作成することも、キャラクタ２４０をうれしくさせる。第３のイベントは、NewOpenNapInfo(新OpenNap情報)イベントである。これは、ＯｐｅｎＮａｐサーバに関する新しい情報が見つかると、ＯｐｅｎＮａｐエージェント（以下説明する）によって発生される。この情報は曲を取得する可能性を高めるため、このイベントが生ずるとキャラクタ２４０は、うれしくなる。最後に、SearchResult(サーチ結果)イベントは、感情を発生するのに関連する音楽収集アプリケーションのこの実施例の第４のイベントである。SearchResultイベントは、特定の曲を共有するユーザをサーチした後にＯｐｅｎＮａｐＡｇｅｎｔによって発生される。選ばれた曲を共有するユーザがいると、キャラクタ２４０はうれしくなる。曲を共有するユーザがいないか、曲が見つからないと、キャラクタ２４０は悲しくなる。

イベントの外に、エージェントのアクションは、感情の合成に関連する。この実施例のユーザは、２種類のアクションを行いうる。ユーザは、特定の曲又はアルバムをダウンロードするよう音楽収集アプリケーションに命令するようUserRequest（ユーザ要求）アクションを実行してもよく、又はユーザは、特定の曲又はアルバムのダウンロードを中止するようCancelUserRequestアクションを実行しうる。キャラクタ２４０は、ユーザが曲又はアルバムをダウンロードすることを要求するとうれしくなり、特にアプリケーションがダウンロードを殆ど完了したときは、ユーザが要求をキャンセルすると、怒る。以下の表は、イベント及び関連する変数によって呼び起こされるキャラクタ２４０の感情の強さを列挙したものである。

次の表は、アクション及びそれらの関連する変数によって呼び起こされるキャラクタ２４０の感情の強さを列挙したものである。

FreeDBエージェント（以下説明する）は、音楽収集エージェントがアルバムに関する情報を要求するときにGetAlbumInformation(アルバム情報取得)アクションを実行する。アクションが成功し、アルバムに関する情報が見つかると、キャラクタ２４０はうれしくなり、そうでなければキャラクタ２４０は怒る。

OpenNapエージェントの１つの実施例は５つのアクションを実行する。ConnectToSpecificServer(特定のサーバへ接続)アクションは、ConnectToAnyServer(任意のサーバへ接続)アクションの部分である。いずれのアクションもOpenNapサーバに接続するのに用いられる。DownloadedSomeBytes(数バイトダウンロードした)アクションは、DownloadFromAnyUser(任意のユーザからダウンロード)アクションの部分であり、それ自体がDownloadFromAnyUser(任意のユーザからダウンロード)アクションの部分である。全ての３つのアクションは、OpenNapエージェントが曲をダウンロードしようとするときに行われる。最後に、DownloadAbortedByPeer(ピアによりダウンロード中止)アクションは、OpenNapエージェントが位置を見つけたファイルのダウンロードを停止又は防止する、ピア（ユーザ）によって実行される任意のアクションである。このアクションは、キャラクタ２４０を怒らせる。

イベント及びアクションの感情の強さは、上記のテーブルに列挙された関連のある変数を用いることによって計算される。例えばNewChartInfoイベントの強さは、このイベントが生ずる確率及び検索された新しいヒットの数に基づく。キャラクタ２４０は、NewChartイベントの確率が低く、新しいヒットの数が大きい場合は、よりうれしくなる。CancelMusicItemアクションの強さは、要求の進行に基づく。例えば、ダウンロードの完了に関して、要求を満たすためになされたより多くの努力があると、供給がキャンセルされればキャラクタ２４０はより怒る。最後に、ConnectToAnyServerアクションは、幾つかのConnectToSpecificServerアクションから構成される。サーバに接続するために、アプリケーションは幾つかの特定のサーバを試さねばならない。ConnectToAnyServerアクションに対するキャラクタ２４０の強さは、アプリケーションが通常はどれだけ素早くサーバに接続しうるか（成功確率）及び接続の前に特定のサーバが試さねばならない回数に依存する。

図２ｃのファイル・タブ２５０は、アプリケーションのダウンロード・ディレクトリ２５５中に現在入っているファイルを表示する。現在処理されているものも含む、ユーザがダウンロードした全ての曲は、階層木として示されている。この木構造は、ユーザが、アーチスト、アルバム、及び曲の任意の組合せを選択すること、及び、選択に対してアクションを行うことを可能とする。ユーザは、例えば、曲の正確さ又は質を調べるよう曲を聴き（再生し）２６０、又は、エラーにより完全にダウンロードされなかった曲をダウンロードすることを再試行する２６２。更に、ユーザは、任意のアーチスト又はアルバムの曲を削除すること２６４、又は、これらをジュークボックス・アプリケーションの音楽ライブラリといったデータベースへ動かすこと２６６ができる。

図２ｄの設定タブ２７０では、ユーザは、システム選好を調整しうる。積極的（proactive）音楽収集は、オン及びオフに切り換えられることができ２８０、ユーザの音楽プロファイルは編集されることができ２８５、ダウンロードされた曲に対する所望の音楽の質は所定のリスト２７５から選択されることができる。

本発明の更なる実施例は、音楽収集アプリケーションの使用可能性を改善するよう音声技術（音声認識）をＧＵＩと組み合わせる。この実施例では、ユーザは、音声を用いて、自分のサーチ・クエリーを入力すること、アクションを選択すること、及び収集の状態をチェックすることが可能である。画面上のキャラクタは、会話的及び感情的な顔の表情を与えることにより、対話の状態の自然なフィードバックを与える。

本発明の更なる実施例（図示せず）は、特定のアーチストの追加的な音楽がクエリーされる（サーチされる）「もっと集める」アクション又はボタンを含む。更に、図２ａ、図２ｂ、図２ｃ、図２ｄのＧＵＩ特徴のキャラクタ２４０は、カスタマイズが可能であり、特徴再配置、グラフィック変更、及びマクロプログラム開発を可能とする。

本発明の他の実施例は、ユーザの既存の音楽収集のメタデータを分析することにより良い初期ユーザプロファイルを生成する。ユーザプロファイルの信頼性は、ＭＰ３ファイルのユーザコレクションが増加するにつれて増加する。最後に、キャラクタ２４０は、ユーザ用のパーソナルＤＪとなる。積極的にダウンロードされた音楽によりサポートされて、パーソナルＤＪは、プレーヤ又はジュークボックス・アプリケーションがユーザ用のラジオ番組シミュレーションを作成するのに使用する個人用再生リストを生成する。パーソナルＤＪは、コンテキストに気づくものであり、誕生日、ロマンチックな夜、又はパーティーのアクティビティ同調再生リストを生成する。他の実施例では、音楽収集アプリケーションのダウンロードされた内容は、音楽に限られず、最新の株式市場情報、交通情報、及びニュースを含む。パーソナルＤＪはまた、ユーザをゲームのような設定に関わらせることにより、アプリケーションのユーザプロファイルの正確さを改善させるのを支援する。アプリケーションは、ユーザの質問を聞くことにより、おもしろい形で、間接的又は直接的にユーザの音楽選好に関するフィードバックを受け取る。

ＧＵＩの更なる実施例は、曲を再生し、一時停止し、停止し、記録し、送り、巻き戻すための機能（ボタン）を含む。本発明の他の実施例では、ボタン又は機能に割り当てられた「完全なアルバム」特徴は、「再生」ボタン、「停止」ボタン、又は「ランダム再生」ボタンに似たオーディオ装置（プレーヤ）のユーザインタフェースの一部として含まれる。いったん押されると、プレーヤは、現在再生されている又は選択された曲が属する完全なアルバムを取得する。これらの曲は、インターネットから、又はラジオ放送から取得されうる。このようにして、ユーザは、完全なアルバムを、当該アルバムの１つのファイル（音楽ファイル）の検索時に容易に聴くことができる。

図３は、本発明による積極的音楽収集の方法３００の１つの実施例を示すブロック図であり、音楽プレーヤ内に埋め込まれている。この音楽収集アプリケーション（アプリケーション）３００の実施例は、ユーザのプロファイルに基づいてインターネットから自動的に音楽を取得する。本発明の１つの実施例では、これは、少なくとも１つの音楽専攻を取得し、音楽属性のうちの１つを読み出すために少なくとも１つのネットワークベースの音楽ファイルにアクセスし、音楽属性を音楽選好と比較するための、特徴、機能、及びプログラムを含みうる。音楽ファイルは、比較に基づいてネットワークを通じてダウンロードされうる。本発明の他の実施例は、ユーザが、キーストローク、グラフィックインタフェース、音声認識システムに関連する音声命令を用いてネットワークを通じて音楽を収集及びダウンロードすることを統合することを可能とする。

音楽収集アプリケーション３００の１つの実施例が正しく機能するために、積極的音楽収集アプリケーションにとって本質的な４片の情報が識別される。第１に、アプリケーション３００は、特定の曲及びアルバムといった音楽アイテムに関する情報を有するべきである。この情報は、一般的にどの音楽アイテムが存在し、ダウンロードされうるかを知るために必要である。第２に、アプリケーション３００は、ユーザがどの種類の音楽を好きであり、ユーザがどの特定の要求を有しうるかを知るべきである。従って、アプリケーションは、ユーザのプロファイルを必要とする。このプロファイルは、特定の音楽の面に関するユーザの選好に関する情報を含みうる。これらの面は、アーチスト名、レコーディング年、分配業者のラベル、曲のタイトル、及びアルバムのタイトルを含みうる。プロファイルは、プレーヤ内の音楽コレクション全体及びユーザの音楽再生行動に関する情報も含みうる。第３に、アプリケーション３００は、検索又は格納する音楽アイテムに関するメタデータを有するべきである。例えば、アプリケーションは、曲又はアルバムのアーチスト、タイトル、又はリリース年についての、並びに、どのトラック及びいくつのトラックが特定のアルバム上にあるかについてのメタデータへのアクセスを有するべきである。メタデータは、どの音楽アイテムがユーザによって好かれているか、又は好かれていないかを判定するのに使用されうる。最後に、第４の情報の必要性は、音楽アイテムをダウンロードすべき場所に関する情報、例えば、インターネット上のダウンロード・サイトに関する情報である。

音楽収集アプリケーション３００が４片の情報を使用するために、情報は正式に何らかの形で表わされねばならない。従って、共有される概念化の公式な、明示的な特定、又はオントロジーが開発される。本発明の１つの実施例についての概念化は、音楽ドメインのモデルを参照し、このドメインが、曲、アルバム、ダウンロード・サイト、アーチスト、ジャンル、ユーザ選好等の概念、並びに、これらの概念の間の関係、例えば曲が或る音楽の面（アーチスト、タイトル、ジャンル）を有すること、及びアルバムがトラックを有すること、を含むという事実を含む。用いられるオントロジー言語は、公知のエージェントシステムについての全体設計方法である、DESIRE法から採用されたものである。

音楽収集アプリケーション３００についてのアーキテクチャは、幾つかの構成原理を適用する。第１に、非エージェント・コンポーネントとエージェント・コンポーネントが区別がなされる。音楽収集アプリケーション３００の非エージェント・コンポーネント及びその関連するシステム・アーキテクチャは、コレクション／データベース及びメディア（ＭＰ３）再生ソフトウエア・コンポーネントといった従来のコンポーネントを反映する。エージェント・コンポーネントは、アクティブに決定を行い、その挙動が、信念、欲求（ゴール）、及び意図をそれらに帰するようにすることにより意図的な姿勢を採用することによって説明されうる。アプリケーション３００に適用される第２の構成原理は、アプリケーション・アーキテクチャ中のサポート・エージェントと共に中央エージェントを用いる。中央エージェントは、「どの音楽項目を得るか」の問題を解決するのに用いられ、アプリケーション・レベルのゴールを設定する。サポート・エージェントは、中央エージェントにインターネットからの関連のある情報を与え、「特定の音楽アイテムをどのように取得するか」に関する問題を扱う役割を担う。最後に、アプリケーション３００は、従来技術で公知のように、外部（インターネット）リソース構成原理のミラリングを用いる。簡単に述べると、インターネット上の各関連のある情報源に対して、任意の必要とされる情報を収集するため、及び情報を、アプリケーション・アーキテクチャの構成要素によって理解される内部的に指定されるフォーマットへ変換するためのプロトコルを含むエージェントが設計される。

図示しない音楽収集アプリケーションの更なる実施例は、アプリケーションを単一のエージェントとして構築する。この実施例では、１つのエージェントが、例えばインターネットから情報を収集すること、どの音楽アイテムを取得するかを決定すること、及びファイルをダウンロードすることといった幾つかのタスクに対する責任を持つ。単一のエージェント・アプリケーション構造は、設計するために高い度合いの内部複雑性を有するただ１つの主コンポーネントからなる。

アプリケーション３００によって用いられるマルチ・エージェント法は、増分的に発展され展開されるモジュール式ソフトウエア・コンポーネントの使用を行わせ、より高いレベルの再利用性を有する。上述のように、音楽収集アプリケーション３００は、２種類のコンポーネント、即ち非エージェント・コンポーネント及びエージェント・コンポーネントからなる。非エージェント・コンポーネントは、アーチスト、ジャンル等といった音楽の面に関するユーザの選好を含むコンポーネントであるユーザ選好コレクション３１５；図２に示すユーザインタフェース又はＧＵＩ３１０；ＭＰ３（又は他の音楽）ファイルを再生するＭＰ３（又は他の音楽ファイル）プレーヤ・コンポーネント；並びに、ユーザの全てのＭＰ３（又は他の音楽）を含むコンポーネントであるプレーヤ・コレクション３７０コンポーネントを含む。これらのコンポーネントは、従来のソフトウエア・エンジニアリング・技術を用いて内部的に構築される。

アプリケーション３００によって使用されるエージェント・コンポーネントは、どの音楽アイテムを取得すべきかを判断する中央エージェントである音楽収集エージェント３２０；インターネット３８０上のＯｐｅｎＮａｐサーバからＭＰ３ファイルをダウンロードする問題を扱うサポート・エージェントであるＯｐｅｎＮａｐエージェント３３０；ヒットチャート情報を含む特定のインターネット・サイトを監視するサポート・エージェントであるチャート・エージェント３４０を含む。新しいチャート情報が利用可能となると、チャート・エージェント３４０はまた、インターネット３８０サイトを解析し、新しい情報を音楽収集エージェント３２０へ送信する。アプリケーション３００によって使用される更なるエージェント・コンポーネントは、ユーザの音楽コレクションに関する情報、及びユーザの再生／視聴行動に基づきユーザのプロファイルを生成するサポートエージェントであるプロファイル・エージェント３５０；並びに、アルバムのトラックに関する情報を取得するためにＦｒｅｅＤＢインターネット３８０サイト（アルバムに関するメタデータを有するオープンソースのオンライン・データベース）にアクセスするサポート・エージェントであるＦｒｅｅＤＢエージェント３６０を含む。

個々のエージェントの内部アーキテクチャは、それらが扱う機能に調和され、従って各エージェントは異なった内部アーキテクチャを有する。第１に、音楽収集エージェント３２０は、ユーザがおそらくは好きであろう音楽アイテムに関する推論を行わねばならない。図３に示す本発明の実施例は、音楽収集エージェントが必要とされる推論を行うことを可能とする信念・欲求・意図（ＢＤＩ）アーキテクチャを採用する。ＢＤＩアーキテクチャは、エージェント理論の分野内で周知であるが、従来技術で知られている他のアーキテクチャが使用されうる。

第２に、ＯｐｅｎＮａｐエージェント３３０は、ＯｐｅｎＮａｐサーバから音楽ファイルを有効にダウンロードする。ＯｐｅｎＮａｐエージェント３３０のアーキテクチャは、ＯｐｅｎＮａｐサーバの問題を扱うために強調学習技術に基づく。これらの問題は、予測できないようなやり方でサーバ及びユーザをネットワークから接続及び切り離すことを含み、幾らかのユーザは、ファイルを共有しておらず、又は許されるアップロードの数に制限があり、各サーバが同じファイルの組を共有していない。

第３に、チャート・エージェント３４０のタスクは、ヒット・チャート情報を有するインターネット・サイト（html文書）を定期的に解析するだけでよいため、以前の２つのエージェントと比較すると比較的簡単である。チャート・エージェント３４０は、このための専用アーキテクチャを有する。

第４に、プロファイル・エージェント３５０のアーキテクチャは、プレーヤ・コレクション３７０及びユーザの再生行動に関する統計量を計算するための統計技術に基づく。

最後に、ＦｒｅｅＤＢエージェント３６０は、チャート・エージェント３４０のように、オンラインＦｒｅｅＤＢ音楽データベースへアクセスするようプロトコルを実施する専用アーキテクチャを有する。

音楽収集アプリケーション３００のソフトウエア・コンポーネントは、機能要件を満たすだけでなく、多数のより微細な非機能的要件を満たす必要がある。非機能要件は、作成の容易性、セキュリティ、相互作用性、統合可能性、操作可能性、応答性、魅力、効率、拡張可能性、及び安定性を含む。非機能要件について、以下詳細に説明する。

作成の容易性は、上述の要件により、音楽収集アプリケーション３００を作成するための努力の度合いとして定義される。

一般的に、セキュリティは、プログラム及びデータへの不当アクセスの防止として定義される。更に、音楽収集アプリケーション３００については、装置の所有者であるユーザにとっては、自分の個人データ及びプロファイルを装置にローカルに維持することが関心となる。本発明の１つの実施例では、ユーザを記述するいかなる情報も１又はそれ以上のサービスプロバイダに対して開示されていないことが要件である。この要件は、数人の顧客のデータが相関され容易にアクセス可能な典型的な推奨システム・アーキテクチャを除外する効果がある。

図３の実施例についての相互作用性は、音楽ファイル及び音楽メタデータを取得するための、例えばOpenNap及びFreeDBサーバといった多数の特定のシステムと相互作用するアプリケーションの可能性を指す。アプリケーション３００は、公式な形で関連のあるプロトコル標準に準拠するだけでなく、ランタイム中に出会うピア及びサーバのタイミング特徴を適応させる。図３のアーキテクチャは、懸念を分離することにより相互作用性をサポートする。例えば、１つの実施例では、OpenNap、ヒットチャートサイト、及びFreeDBのプロトコル詳細及びデータフォーマットは、別のエージェント内に夫々カプセル化される。これらのエージェントは、１つの固定のサーバ又は１つの固定のピアを扱うのではなく、インターネット３８０上のサーバ及びピアを動的に見つけ、評価する。

統合可能性は、アプリケーション３００のコンポーネント及び実施例が容易に統合されうる度合いとして定義される。統合可能性は、共有データ構造を用いることにより本発明の１つの実施例によって達成される。他の実施例は、ユーザ視聴パターンといったパターンに基づいて専用インタフェースを用いることによって統合可能性を達成する。

操作可能性は、ユーザが音楽収集アプリケーション３００を操作及び制御することを可能とするものとして定義される。音楽収集アプリケーション３００の１つの実施例では、操作可能性は、殆どの、そうでなければ全ての認識負荷をユーザから取り去らねばならない。本発明のこの実施例によれば、ユーザは、再生されるべき音楽フラグメントのシーケンスをプログラムする必要はなく、ダウンロード状態を追跡する必要はなく、ピア及びサーバのＩＰアドレス及び他の特徴を覚える必要はない。

応答性は、ユーザの期待に従って十分に高速に反応するためのアプリケーション３００の可能性を指し、また、処理中に十分なフィードバックを与えるためのアプリケーション３００の可能性を指す。アプリケーション３００は、ユーザの期待に従って高速に反応する方法を与え、なぜならばＭＰ３プレーヤ及び音楽収集エージェント３２０は並列スレッドとして実行されるからである。

魅力は、「ユーザによって好かれること」として定義され、本発明のこの実施例については、アプリケーション３００が、ユーザが好きな音楽アイテムを収集し、音楽評価チャート上に列挙された音楽アイテムを収集し、ユーザフィードバック及び音楽入手可能性を考慮に入れるという機能要件へと変換される。操作可能性及び魅力に関して、アプリケーション３００のエージェントは、インターネット３８０へ行き、ユーザ介入の必要性なしに望ましい音楽を収集することにより、殆ど、そうでなければ全ての認識負荷をユーザから取り去らねばならない。

効率は、適切な時間行動及び適切な資源の使用として定義され、音楽収集アプリケーション３００が異なったシステム及びアーキテクチャ・プラットフォームと共に動作することを可能とする。例えば、適切な時間行動及び適切な資源使用である効率は、ＭＰ３（又は同様の音楽形式）再生のリアルタイムな面と、夫々がそれ自身のスレッドを有する別々のコンポーネントによって与えられるインターネット・プロトコル処理によって本発明の１つの実施例で達成される。問題は、音楽コレクタ（収集）エージェント３２０によって１つずつ処理されるとき、夫々がゆっくりであるか、さらには失敗しうる多数の並列タスクを処理するときに生じうる。「アクション実行」機構は、並列動作が、インターネット上のどこかの、アプリケーション外で生ずることを与えることによりこの問題を扱う。更に、OpenNapエージェント３３０は、ゆっくりな且つ信頼性のないサーバ及びクライアントから遠ざかっていることを学習する意味で知的（インテリジェント）であり、これはもちろんアプリケーションをより効率的なものとする。

拡張可能性は、アプリケーションの機能又は性能が新しい必要性に合うよう増加されうる容易性を指す。拡張可能性に近く関連するものは、安定性である。安定性は、アプリケーション３００の変更によって生ずる最小の効果を指す。

音楽収集エージェント３２０は、それがアプリケーションのゴールを設定するように、アプリケーション・アーキテクチャにおける中心的な役割を担う。音楽収集エージェント３２０の１つの実施例は、他のエージェント及びユーザから取得した情報に基づいて、また、選好収集３１５コンポーネント及びＭＰ３（プレーヤ）収集３７０コンポーネントからの情報に基づいて、ユーザに対してどの音楽アイテム（曲／アルバム）をダウンロードすべきかを決定する。音楽収集エージェント３２０は、いったん、どの音楽アイテムがダウンロードされるべきかを決定すると、OpenNapエージェント３３０へ要求を送信する。

音楽収集エージェント３２０は、どの音楽アイテムをダウンロードすべきかを決定するために、受信した情報を分析することが可能でなくてはならない。インターネット３８０といった実際上の問題のドメイン内で動作するのに専用の柔軟な推論機構は、音楽収集エージェント３２０の正しい機能に不可欠である。上述のように、ＢＤＩアーキテクチャは、このために使用されうる。ＢＤＩアーキテクチャは、３組の情報を含む。第１の組は信念であり、これはエージェントの環境及び内部状態に関する情報を含む。アプリケーション３００内では、これは、音楽アイテム及びそれらの面、並びに、ユーザの選好及び要求に関する情報、ＭＰ３コレクション内の曲、並びに、音楽アイテムの面に関する特定の情報に関する情報を含みうるものである。第２の組は、音楽収集エージェント３２０の目的又はゴールに関する情報を含む欲求の組である。アプリケーション３００内では、ゴールは、特定の音楽の面に関する音楽アイテムを取得することを含みうるもの、又は、アルバムのトラックに関する情報を有することを望むものでありうる。第３の組は、エージェントがその欲求を実現するために実行するアクションに関する情報を含む意図の組である。アクションを推論し制御するために、音楽収集エージェント３２０は、アクションの内部表現を有さねばならない。このために、エージェントがそれが実行しているアクションの状態に関して推論しうるよう、オントロジーが設計されている。ＢＤＩアーキテクチャでは、「アクション実行」機能は、アクションの状態が変化すれば、一組の信念を更新する。更に、一組の意図が、アクションを制御するための宣言を含む場合、一組の意図は、「アクション実行」機能によりアクションの実際の制御へ変換されうる。

図４中、柔軟な推論（ＢＤＩ）法４００の１つの実施例についてのブロック図を示す。この図の上部分は、３組の情報、即ち信念４０５、欲求４４５、及び意図４３０を表わす３つのデータベースを含む「論理推論」４０１を示す。信念４０５、欲求４４５、及び意図４３０の組の外に、ＢＤＩアーキテクチャはまた、これらの組に対して動作する３つの機能を含む。GenerateOption（オプション生成）機能４４０は、手段終了推論を実行し、それにより新しい欲求（ゴール）を実行する。これを行っている間、これは、信念４０５、欲求４４５、及び意図４３０の間の一貫性を維持する。例えば、音楽収集エージェントが、特定の音楽アイテムがダウンロード可能でないという信念を有する場合、これはその曲をダウンロードする欲求を作成してはならない。この機能の他の実施例は、音楽収集エージェントの環境における有利な変化を認識することである。例えば、特定の音楽アイテムがダウンロード可能でないという信念が消えれば、その音楽アイテムをダウンロードすることを再び試しうる。

フィルタ機能４２０は、３つのことを行う。第１に、達成可能でない意図をやめる。第２に、達成できなかった意図を維持する。第３に、新しい意図を採用する。

更新機能４１０は、一組の信念を新しい情報で更新する責任がある。これは、例えば、新しい選好又はユーザが追加した音楽ファイルに対するアプリケーションの内部状態に関する状態である。

図４の下の部分は、「アクション実行」４０２を示す。殆どの論理ベースの推論システムは、エージェントがとっているアクションは原子性であり、時間を費やさず、又は少なくともアクションが実行するのにかかる時間が考慮に入れられないことを想定する。アーキテクチャのこの実施例では、想定は、ファイルのダウンロード及びインターネットのサーチといったアクションとされることができず、完了するのに時間がかかる。各アクションが終了するのを待つのは非効率であるため、実施されるＢＤＩアーキテクチャは、アクションが実行されえ、エージェントがアクションの状態に関して推論しうることを与える。アクションは、通常のコンピュータ・オペレーティング・システム中のタスクと比較されうる。本発明の１つの実施例では、アクションは、５つの状態４５０、４６０、４７０、４８０及び４９０のうちの１つでありうる。ＩＤＬＥ状態４５０では、アクションは何もしていない。アクションが作成されると、この状態から開始する。また、イベント休止又はリセットが生ずると、アクションはこの状態に戻る。ＲＵＮＮＩＮＧ状態４６０では、アクションは、そのプログラム又はアルゴリズムを実行しており、例えば、get-infoアクションは、典型的には要求された情報を見つけるためにインターネットへの接続を確立する。ＰＡＵＳＥＤ状態４７０では、アクションは何も行わない。ＰＡＵＳＥＤ状態４７０とＩＤＬＥ状態４５０の相違は、アクションがＰＡＵＳＥＤ状態４７０から再開（resume）すると、アクションのプログラム又はアルゴリズムの内部状態が保存され、回復される。

２つの状態がアクションの終了である。ＳＵＣＣＥＥＤＥＤ状態４９０では、アクションは成功している。ＦＡＩＬＥＤ状態４８０では、アクションは失敗している。状態間の遷移が生じたイベントは、４９５として示されている。エージェントは、実行、休止、一時停止、再開、及びリセットイベント４９５に対する制御を行う。ＳＵＣＣＥＥＤＥＤ４９０状態及びＦＡＩＬＥＤ４８０状態への遷移は、自律的であり、アクションによって実施されるタスクの結果に依存する。

３つの機能、即ち、ＢＤＩアーキテクチャのGenerateOptions（オプション生成）４４０、Filter（フィルタ）４２０、及びUpdate（更新）４１０に含まれる音楽ドメイン知識は、本願の実施においては規則によって表わされる。規則は、前件と後件からなる。前件が真であれば、後件が実行される。例えば、オプション生成４４０機能は、特に以下の規則を含む。

％Rule#1: download user requests
IF request-obtain-music-item(I:MUSIC ITEM)
THEN selected-goal(obtain-music-item(I:MUSIC ITEM))
％Rule#2: always download music with aspects the user loves
IF preference(A:MUSIC ASPECT, love it)
THEN selected-goal(acquire-music(A:MUSIC ASPECT))
第１の規則は、音楽収集エージェントが、ユーザが特定の音楽アイテムをダウンロードすることを要求したという信念を有する場合、これは音楽アイテムを取得するための欲求を設定せねばならないことを述べている。第２の規則は、ユーザが特定の面を有する音楽が好きである場合（例えば「マドンナ」の曲）、その面を有する音楽アイテムを取得することに対する欲求を設定する。フィルタ４２０機能からの規則の例は、以下の通りである。
％Rule#: get information about the tracks of an album to download
IF selected-goal(obtain-music-item(A:ALBUM))
AND NOT number-of-tracks(A:ALBUM, N:NUMBER)
AND NOT is-running(get-album-info(A:ALBUM))
AND NOT is-paused(get-album-info(A:ALBUM))
AND NOT is-succeeded(get-album-info(A:ALBUM))
AND NOT is-failed(get-album-info(A:ALBUM))
AND NOT not-available-album-info(A:ALBUM))
THEN to-be-executed(get-album-info(A:ALBUM))
最後に、更新信念機能からの例としての規則は、以下の通りである。
％Rule#: handle result of failed get-album action
IF is-failed(get-album-info(A:ALBUM))
THEN not-available-album-info(A:ALBUM)
AND NOT to-be-executed(get-album-info(A:ALBUM))
AND NOT is-failed(get-album-info(A:ALBUM))
AND NOT selected-goal(obtain-music-item(A:ALBUM))
本発明の他の実施例は、図５に示すように、プロファイル・エージェント５００のブロック図として示される。どの音楽アイテムをダウンロードするかを決定するために、ユーザの音楽関心に関する情報が必要とされる。この実施例では、２種類の情報、即ち選好及びプロファイルが用いられる。選好は、ユーザによって直接設定される。例えば、ユーザは、自分が特定のジャンルが好きであり、特定のアーチストが嫌いであることを入力しうる。音楽ドメインのオントロジーでは、これは、選好（アーチスト「アーチストＸ」、評価HATE IT）又は選好（ジャンル「ロック」、評価LIKE IT）といった記述によって表現されうる。他方のプロファイルは、ユーザを観察することにより自動的に導出されるユーザの音楽関心に関する情報である。

プロファイル・エージェント５００は、ユーザのプロファイルを計算する責任がある。図５は、このエージェントの内部アーキテクチャを示す。プロファイル・エージェント５００は、ユーザのプロファイルを計算するために２つのソースを用いる。第１のソースは、音楽（ＭＰ３）プレーヤ５２８である。このソースは、ユーザの再生／視聴の行動の推定値（統計的分析）５２０を行うのに用いられる。第２のソースは、音楽（ＭＰ３）コレクション５３８である。このソースは、ユーザのより静的な関心、特に音楽の面を推定５２０するのに用いられる。実施例は、ユーザがどのファイルを再生しているかの情報から、ユーザの短期の関心についての印が形成されえ、音楽コレクションから、特に音楽の面のユーザの長期の関心に関する印が作られうることを与える。センサ（エージェントについて従来技術から周知である）は、ＭＰ３プレーヤ５３０及びＭＰ３コレクション５４０を感知するのに用いられる。これらのセンサは、例えば、ユーザが再生ボタンを押したとき、又はＭＰ３コレクションにファイルが追加又は除去されたときに、イベントを受信する。リスニング・プロファイルは、再生ボタンが圧されたというイベントを用いて計算５２０されうる。このイベントが生ずると、ＭＰ３プレーヤセンサ５３０は、再生５２８されているＭＰ３ファイルに関する情報を受信する。このファイルのＩＤ３タグから、アーチスト、ジャンル、アルバム等に関する情報が導出されうる。これらの音楽の面の夫々に対して、この面を有する音楽アイテムがどの程度頻繁に再生されたかの頻度が以下の式によって計算される。

式中、Ｎは過去のＴ時間期間にわたって再生された音楽の面Ａを有する音楽アイテムの数である。この数値的な頻度は、言語的な値NEVER, RARELY, SOMETIMES, OFTEN又はALWAYへ変換される。これは、閾値を用いることによって行われる。以下の頻度間隔が定義される。

収集プロファイルは、ＭＰ３ファイルがＭＰ３コレクションに追加又は除去されたときに、イベントを用いて計算５２０される。ＭＰ３コレクション・センサ５４０は、これらのイベントを検出するのに用いられ、追加又は除去されているＭＰ３ファイル５３８に関する情報を受信する。再び、ＭＰ３ファイルのＩＤ３タグから、アーチスト、タイトル、ジャンル、アルバム等に関する情報が導出されうる。各音楽の面に対してコレクション・プロファイルを計算５２０するために、この面を有する音楽アイテムの数が計算される。この数は、naで示され、aは特定の音楽の面である。最後に、この数値は、言語的な値（量）NONE, SOME, SEVERAL, MANY又はA LOTへ変換される。これは、閾値を用いることによって行われる。以下の量の間隔が定義される。

プロファイル・エージェント５００は、反応性があり、これは、ＭＰ３プレーヤ又はＭＰ３コレクションからイベントを受信した場合にのみプロファイルを計算することを意味する。プロファイルが変化すると、プロファイル・エージェント５００は、通信モード５１０を通じて音楽収集エージェントへ新しいプロファイルを送信する。

図６は、FreeDBエージェント６００の１つの実施例を示すブロック図である。どの音楽アイテムがダウンロードされるかを決定するために、これらのアイテムの音楽的な面に関する情報が必要とされる。例えば、アーチスト及び曲のタイトル、またはそのジャンル又はリリース日といった特定の曲の面が知られていなければならない。この種類の情報は、メタ情報と称される。多くのメタ情報がＭＰ３ファイルに含まれ、ＭＰ３ファイルのＩＤ３タグと称される。第１のバージョンＩＤ３ｖ１は、タイトル、アーチスト、年、ジャンル及びコメントフィールドを含む限られた一組の固定長フィールドであった。後のバージョンのＩＤ３タグは、固定長フィールドの問題を解決し、様々な他の種類のフィールドを可能とする。

ＭＰ３ファイルのＩＤ３タグは、曲の音楽の面に関する情報のソースであるが、これはアルバムをダウンロードするのには十分でない。アルバムをダウンロードするために、その上にどのトラックが載っているかを知ることも必要である。この情報は、インターネット６４０上のデータベース中で見つけられる。１つのかかるデータベース、即ちＣＤＤＢインターネットサービスは、アルバム上のトラックに関する情報といったアルバム情報を含む。ＣＤＤＢインターネットサービスは、しばしば、パーソナルコンピュータ上のメディアプレーヤによって用いられる。実際上、ユーザが自分のＣＤ−ＲＯＭドライブにオーディオＣＤを入れると、メディアプレーヤは、ＣＤＤＢにおいてアルバム情報を探すキーとして用いられる（ほとんど）一意のディスク識別情報（ＩＤ）を計算する。いったん見つかると、メディアプレーヤは、オーディオＣＤに関するトラック情報（アーチスト、タイトル）を表示する。しかしながら、ＣＤＤＢにアクセスするのに必要なライセンスの変化により、FreeＤＢと称される他のデータベースが開発された。FreeＤＢは、オープンソースの、アルバム情報を含むＣＤＤＢのようなデータベースである。

FreeＤＢエージェント６００は、曲及びアルバムに関する情報を得るための要求を扱うエージェントである。図６は、内部アーキテクチャを示す図である。１つの実施例では、通信モジュール６１０は、なんらかの情報を見つけるための音楽収集エージェント６０５からの要求を受信する。受信された要求は、一般的にはget-info(A:ALBUM)の形である。通信モジュール６１０は、FreeＤＢエージェント６００と音楽収集エージェント６０５の間の通信プロトコルを実施する。

アルバム情報は、特定のアルバムに関する情報についての要求を含む正しいＵＲＬを構築することによりFreeＤＢサイトにおいて見つけられ得る。通信モジュールは、get-info(A:ALBUM)宣言をＵＲＬへ変換し、これをＵＲＬセンサ６３０へ送信する。

ＵＲＬセンサ６３０は、インターネット６４０へのソケット・コネクションを作り、ＵＲＬによって示されるｈｔｍｌテキストをダウンロードする。ｈｔｍｌテキストは、FreeＤＢhtmlパーサ６３０へ送信される。このモジュールは、テキストを解析し、アルバム情報を抽出し、情報を何らかの内部的に定義されたデータ構造に入れる。このデータ構造は、通信モジュール６１０へ送信される。最後に、通信モジュール６１０は、データ構造を我々の音楽ドメイン言語の宣言へ変換する。典型的な宣言は、以下のフォーマット、即ち、number-of-tracks(A:ALBUM, N:NUMBER)及びis-track(A:ALBUM, S:SONG, N:NUMBER)である。

FreeＤＢエージェント６００のアーキテクチャは、反応性のアーキテクチャである。エージェントは、要求を受信し、特別な推論が必要でなければ、アクションを引き受けるのみである。情報を見つける問題がより困難となるとき、例えば、異なるソースが利用可能であり、夫々が利用可能性、信頼性、又は質といったそれ自身の性質を有するとき、推論が必要とされうる。この状況では、より慎重なアーキテクチャが必要である。

図７中、チャート・エージェント７００の１つの実施例のブロック図を示す。チャート・エージェント７００は、どの音楽アイテムがダウンロードされるべきであるかを決定するよう、音楽収集エージェント７０５のために有用なヒットチャート情報を与える。ヒットチャートは、存在する音楽アイテムに関する情報のソースである。特に、これらは、存在する任意の新しい音楽アイテムのソースである。ヒットチャートは、アーチストの名前と曲のタイトルを与える。チャート・エージェント７００は、インターネット７４５から各週のトップ・ヒット・チャートを得る役割を有する。図７は、チャート・エージェント７００の１つの実施例についての内部アーキテクチャを図示する。スケジューラ・モジュール５０は、インターネット７４５から「音楽トップ・ヒット」を得るようＵＲＬセンサ７４０を毎週トリガする。ＵＲＬセンサ７４０は、受信したｈｔｍｌテキストを「音楽トップ・ヒット」（ＴＯＰ５０）ｈｔｍｌパーサ７３０へ送信する。

このコンポーネントは、必要なヒットチャート情報を得るためにテキストを解析する。ＴＯＰ５０ｈｔｍｌパーサ７３０は、テキストをチャート収集７２０データ構造へ送信する。最後に、チャート収集７２０データ構造は、ヒットチャート情報を、内部的に構造化されたデータオブジェクトとして通信モジュール７１０へ送信する。このモジュールは、情報を音楽収集エージェント７０５へ送信する。メッセージの内容は、典型的には次のフォーマット、即ち、is-hit(S:SONG), has-aspect(S;SONG, M:MUSIC ASPECT)である。

チャート・エージェント７００は、積極的（proactive）エージェントである。これは、毎週、新しいヒットチャート情報を得るためにインターネットサイトをチェックする。

図８は、OpenNapエージェント８００の１つの実施例についてのブロック図である。OpenNapエージェント８００は、要求された音楽ファイルをダウンロードする責任を担う。用いられるOpenNapプロトコルは、Napsterプロトコルの拡張である。Napsterプロトコルでは、全てのファイルはクライアント側に存在する。中央サーバは、ファイルをサーチし、ファイルの転送を開始するのに用いられる。OpenNapサーバは、非常に不確実な、ダイナミックな、非エピソード的なエージェント環境であるとして特徴付けられる。OpenNapサーバへのコネクションは、ソケットを用いてなされる。しかしながら、特定のOpenNapサーバが、特定の時点において起動中であるか停止しているかは予測不可能である。いったんソケット・コネクションがなされると、OpenNapエージェント８００は、OpenNapサーバへログインせねばならない。全てのOpenNapサーバが全員にログインすることを可能とするわけではなく（プライベートOpenNapサーバ）、殆どのサーバが制限を設定している（例えば、接続されたユーザの数は、通常は幾つかの最大に制限され、各ユーザは特定の量のファイルを共有せねばならない）。クライアントは、ログインしていれば、ファイルについてのサーチを開始しうる。サーチ要求の結果は、他者によって共有されている内容に依存する。サーチクエリーは、特定のファイルを共有するクライアントのリストを戻し、これらのリストは空でありうる。リストが空でなければ、クライアントは他のクライアントにファイル転送を開始することを要求しうる。ファイル転送もまた問題を有しうる。例えば、殆どのクライアントは、それらが与えるアップロードの数に制限を課し、これは、アップロードを試みている割り当てられた数を超えたユーザ又はアプリケーションが拒否されることを生じさせる。更に、両方のクライアントがファイアウォールの向こうであるとき、ファイル転送は開始できない。

OpenNap環境で何をすべきかの合理的な決定を行うために、OpenNapエージェント８００は、OpenNap環境のモデルを維持せねばならない。このモデルは、オンラインOpenNapサーバのIPアドレスの最新リスト、最後にログインが失敗したとき及び成功したログインの数からなる質の尺度を示す各OpenNapサーバのプロファイル、このサーバからの成功したファイルダウンロードの数、ダウンロードが失敗した最後のときを示す各クライアントのプロファイル、及び成功したダウンロードの確率の推定を含むべきである。

図８は、OpenNapエージェント８００の内部アーキテクチャを示す。通信モジュール８１０は、特定のプロファイルをダウンロードするよう音楽収集エージェント８０５からの要求を受信する。通信モジュール８１０は、計画モジュール８２０へ情報を送信する。計画モジュール８２０は、どのアクションを起こすべきかを決定する。計画モジュール８２０が選びうるアクションは、最新OpenNapサーバリストのダウンロード、サーバへの接続、ファイルのサーチ、ファイルのダウンロード、又はサーバ・コネクションを閉じることを含みうる。

計画モジュール８２０が、インターネットから最新OpenNapサーバをダウンロードすることを決定すると、これはＵＲＬセンサ８７０へトリガ信号を送信する。続いて、ＵＲＬセンサ８７０は、オンラインOpenNapサーバに関する情報を含む、例えばZeropaid.com ウェブサイトといったウェブサイト８６５からｈｔｍｌ文書をダウンロードし始める。この文書は、サーバ情報を取得するためにｈｔｍｌ文書を解析するOpenNapサーバ・リスト・パーサ８６０へ送信される。全てのサーバ情報は、計画モジュール８２０へ送信されるデータオブジェクトに入れられる。

計画モジュール８２０は、アクションとして、ＭＰ３ファイルをダウンロードすることを選びうる。音楽ファイルがダウンロードされうる前に、なんらかのOpenNapサーバへの接続が確立されねばならない。従って、計画モジュール８２０は、OpenNapクライアント・モジュール８３０への接続要求を、それらのアドレスがインターネットから以前に得られている特定のサーバのアドレスと共に送信する。OpenNapクライアント・モジュール８３０は、インターネット８３２を通じて実際のOpenNapプロトコルを実施する。コネクションが失敗すると、OpenNapクライアント・モジュール８３０は、計画モジュール８２０へメッセージを送信する。計画モジュール８２０は、再接続をするか、他のOpenNapサーバを試すことを決定しうる。

音楽（ＭＰ３）ファイルをOpenNapサーバからダウンロードする手順は、サーチ・アクションから開始する。計画モジュール８２０は、OpenNapサーバを特定のファイルについてサーチするようOpenNapクライアント・モジュール８３０に要求を送信する。OpenNapクライアント８３０がOpenNapサーバ上にサーチ要求を発行すると、そのファイルを共有するクライアントのリストを受信する。このリストは、どのクライアントからファイルをダウンロードするかを決定する計画モジュール８２０へ渡される。しばしば、ダウンロード要求は受け入れられない。計画モジュール８２０は、ファイルを他のクライアントからダウンロードすることを決定する。本発明の他の実施例は、特定のダウンロード時間が過ぎた後、又は、特定の数のクライアントが要求を受け入れないとき、要求が失敗し、計画モジュール８２０が全てのオープン・コネクションから切り離されうる。いったん全てのファイルがダウンロードされると、計画モジュール８２０は、コネクションを閉じることを要求する。

受信されたファイルは、OpenNapクライアント・モジュール８３０によりＭＰ３コレクション８３４に追加される。デフォルトにより、ＭＰ３コレクション８３４は、ファイルが追加又は除去されたときは全てのリスナーにイベントを送信し、音楽収集エージェント８０５が、コレクションの中に新しいファイルがあることに気づくようにする。計画モジュール８２０は、特定のＭＰ３ファイルのダウンロード要求が成功又は失敗したたびに、音楽収集エージェント８０５へ通知メッセージを送り返す。

OpenNapエージェント８００の他の実施例は、OpenNapエージェント８００が、従来技術で知られている強化学習技術を用いることによって、クライアント及びサーバの質を学習するようにする。強化学習技術の１つの実施例では、サーバ又はユーザの質（Ｑ）の値は、夫々、Ｑ（server）及びＱ（client）によって示される。これらの質の値は、要求されたファイルをダウンロードしようとしている間に受信される「報酬」から計算される。報酬は、音楽ファイルサーバへのログオンが成功するたびに指される点である。サーバの質の値は、ログインへの試みの後に、当該サーバのダウンロード・セッションの後に、受信された報酬から計算される。ユーザの値は、当該ユーザからファイルをダウンロードしようと試みた後に受信された計算された報酬である。

OpenNapサーバを接続及び切り離すための計画モジュール８２０のアルゴリズムの一部を、以下に列挙する。サーバを選ぶ方法は、従来技術で知られているようなε貪欲法である。小さい量（ε％）の試行に対してのみ、ランダムサーバが選択される。他の試行中、最善のサーバが選択され、即ち、最高のＱ値を有するサーバが選択される。アルゴリズムのライン５−１０がこの方法を実施する。成功しなかったサーバログインの後の試行を回避するための保護が内蔵されている。ログインアクションが失敗すると、このイベントの時間が記憶される。或る量の時間が経ってからのみ、サーバは再び選択されうる。

サーバのＱ値の更新は、ログイン報酬について、ライン１５乃至２１において行なわれる。

音楽ファイルのネットワーク経由のダウンロードのための上述の方法及びシステムは、例としての方法及びシステムである。これらの方法及びシステムは、音楽ファイルをダウロードする１つの可能なアプローチを示す。実際の実施は、説明する方法とは異なりうる。更に、本発明の様々な他の改善及び変更は当業者が思いつきうるものであり、これらの改善及び変更は以下の本発明の範囲内にある。

本発明は、その趣旨及び本質的な特徴を逸脱することなく他の特定の形で具現化されうる。上述の実施例は、全ての面において単に例示的なものであって制限的なものでないと考えられる。

本発明による、音楽ファイルのアクセス及びダウンロードのシステムの１つの実施例を概略的に示す図である。 本発明による、図１のシステムを用いたグラフィック・ユーザ・インタフェースの１つの実施例を示す図である。 本発明による、図１のシステムを用いたグラフィック・ユーザ・インタフェースの１つの実施例を示す図である。 本発明による、図１のシステムを用いたグラフィック・ユーザ・インタフェースの１つの実施例を示す図である。 本発明による、図１のシステムを用いたグラフィック・ユーザ・インタフェースの１つの実施例を示す図である。 本発明による、図１及び図２ａ乃至図２ｄのシステムを用いた積極的音楽収集方法の１つを実施例を示す図である。 本発明による、図１及び図２ａ乃至図２ｄのシステム、並びに、図３の方法を用いた柔軟な理由付け方法の１つの実施例を示すブロック図である。 本発明による、図１及び図２ａ乃至図２ｄのシステム、並びに、図３及び図４の方法を用いたプロファイル・エージェントの１つの実施例を示すブロック図である。 本発明による、図１及び図２ａ乃至図２ｄのシステム、並びに、図３及び図４の方法を用いたプロファイル・エージェントの１つの実施例を示すブロック図である。 本発明による、図１及び図２ａ乃至図２ｄのシステム、並びに、図３及び図４の方法を用いたチャート・エージェントの１つの実施例を示すブロック図である。 本発明による、図１及び図２ａ乃至図２ｄのシステム、並びに、図３及び図４の方法を用いたＯｐｅｎＮａｐエージェントの１つの実施例を示すブロック図である。

Claims (20)

1. 音楽ファイルをネットワーク経由でダウンロードする方法であって、
   少なくとも１つの音楽選好を取得する段階と、
   少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスする段階と、
   前記音楽属性を前記音楽選好と比較する段階と、
   前記音楽ファイルを前記比較に基づいてダウンロードする段階とを有する、方法。
2. 感情的インタフェースの機能として音楽ファイルのネットワーク経由のダウンロードの進行を観察する段階を更に有する、請求項１記載の方法。
3. 完全なアルバム特徴の機能として前記第１の音楽ファイルに基づき第２の音楽ファイルのダウンロードする段階を更に有する、請求項１記載の方法。
4. グラフィック・ユーザ・インタフェースの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与える段階を更に有する、請求項１記載の方法。
5. 音声コマンドの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与える段階を更に有する、請求項１記載の方法。
6. 前記音楽選好は、アーチスト名、レコーディング年、流通業者のラベル、曲のタイトル、及びアルバムのタイトルからなる群から選択される、請求項１記載の方法。
7. 前記音楽選好はユーザ選好集合から取得される、請求項１記載の方法。
8. 前記音楽属性を前記アルバム選好と比較することは音楽収集エージェントの機能である、請求項１記載の方法。
9. 前記ネットワーク・ベースの音楽ファイルへのアクセスは、ｆｒｅｅＤＢエージェント、チャート・エージェント、及びＯｐｅｎＮａｐエージェントからなる群から選択されたエージェントの機能である、請求項１記載の方法。
10. 前記音楽ファイルは音楽再生装置へダウンロードされる、請求項１記載の方法。
11. 音楽ファイルをネットワーク経由でダウンロードするシステムであって、
    少なくとも１つの音楽選好を取得する手段と、
    少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスする手段と、
    前記音楽属性を前記音楽選好と比較する手段と、
    前記音楽ファイルを前記比較に基づいてダウンロードする手段とを有する、システム。
12. 音楽ファイルのネットワーク経由のダウンロードの進行を観察する手段を更に有する、請求項１１記載のシステム。
13. 完全なアルバム特徴の機能として前記第１の音楽ファイルに基づき第２の音楽ファイルのダウンロードする手段を更に有する、請求項１１記載のシステム。
14. 音声コマンドの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与える手段を更に有する、請求項１１記載のシステム。
15. 音声コマンドの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与える手段を更に有する、請求項１１記載のシステム。
16. 音楽ファイルをネットワーク経由でダウンロードするコンピュータプログラムを記憶するコンピュータ読み取り可能な媒体であって、
    少なくとも１つの音楽選好を取得するコンピュータ読み取り可能なコードと、
    少なくとも１つの音楽属性を夫々が含む少なくとも１つのネットワーク・ベースの音楽ファイルにアクセスするコンピュータ読み取り可能なコードと、
    前記音楽属性を前記音楽選好と比較するコンピュータ読み取り可能なコードと、
    前記音楽ファイルを前記比較に基づいてダウンロードするコンピュータ読み取り可能なコードとを有する、コンピュータ読み取り可能な媒体。
17. 感情的インタフェースの機能として音楽ファイルのネットワーク経由のダウンロードの進行を観察するコンピュータ読み取り可能なコードを更に有する、請求項１６記載のコンピュータ読み取り可能な媒体。
18. 完全なアルバム特徴の機能として前記第１の音楽ファイルに基づき第２の音楽ファイルのダウンロードするコンピュータ読み取り可能なコードを更に有する、請求項１６記載のコンピュータ読み取り可能な媒体。
19. グラフィック・ユーザ・インタフェースの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与えるコンピュータ読み取り可能なコードを更に有する、請求項１６記載のコンピュータ読み取り可能な媒体。
20. 音声コマンドの機能として音楽ファイルのネットワーク経由のダウンロードとの相互作用を与えるコンピュータ読み取り可能なコードを更に有する、請求項１６記載のコンピュータ読み取り可能な媒体。

Images