JP2007519081A - オーディオ／ビデオデータを体系化するシステムおよび方法 - Google Patents

Abstract

本発明は、新規ファイル管理手法を提供する。本システムおよび方法は、アプリケーションを構築するための効率的で強力な開発ユーティリティをアプリケーション開発者に提供するために、オペレーティングシステム内部に統合することができる、スキーマベースのファイル管理技術を含む。さらに、本システムおよび方法は、動作環境において異質なデータ（たとえば、オーディオおよびビデオデータ）に渡って統一して利用することができるアプリケーションを提供する。このスキーマは、公知のタイプのデータに関連する基本スキーマと、データの１つまたは複数の特性に関して基本スキーマを拡張する派生スキーマとを含み得る。スキーマは、ユーザおよび／またはアプリケーションによってファイルシステムと情報を交換するのに利用することができるＡＰＩを生成するのに利用することができる。さらに、本システムおよび方法は、アクションを実施し、そして／または決定を下すのに使用することができる構成可能なインテリジェンスを含むことができ、このインテリジェンスにより、プロセスを自動化し、そして／またはデータの格納および／あるいは管理を円滑にすることができる。

Description

（関連出願の相互参照）
本出願は、２００３年１０月２３日に出願した米国特許出願第１０／６９２，２１５号「SYSTEMS AND METHODS THAT SCHEMATIZE AUDIO/VIDEO DATA」の優先権を主張するものであり、全体が参照により本明細書に組み込まれる。

本発明は概して、ファイル管理に関し、より詳細には、豊富なスキーマセットに基づいてオーディオおよびビデオデータを格納し管理するシステムおよび方法に関する。

過去数十年に渡るコンピュータおよび電子関連技術の進歩により、コンピュータ時代への道が開かれた。たとえば、トランジスタ技術の進歩により、年毎に、平方インチ（２．５４ｃｍ）あたりのトランジスタの数（トランジスタ密度）がほぼ２倍の集積回路の製作が可能になった（ムーアの法則）。このような進歩は、処理能力および伝送速度（たとえば、データ、コントロール、およびアドレス）の大幅な増大、ならびにコンポーネント／ボードのサイズ、電力消費、およびコストの削減につながった。さらに、インターネットおよび無線技術の進歩により、ユーザは、ボタンの押下またはマウスのクリックにより、実質的に世界中のあらゆる場所にいつでもアクセスできるようになった。コンピュータの設計者は、このような発展を新世代のたびに利用して、より高性能で、より信頼性が高く、割安な計算機システムを開発し続けている。

上記および他の多くの進歩は、コスト効率が高く、日常の個人的および業務上の活動を円滑にしはかどらせ得る、強力で効率的な機構にコンピュータが発展することに寄与した。たとえば、今日のコンピュータは、通信（たとえば、ｅメール、インスタントメッセージ、チャットルームなどのやりとり）、買い物、販売、情報収集、分析、およびアーカイブ（たとえば、ドキュメンテーション）で日常的に使用される。さらに、今日のコンピュータは一般に、たとえば株式相場に（たとえばリアルタイムに）アクセスし、天気予報を入手し、道順を検索し、ビデオを流し、音楽を聴き、実況によるスポーツのアップデートを入手し、（たとえば、オンラインの）ゲームをするのに使用される。さらに、コンピュータ技術は、自動車、ホームセキュリティ、製造プロセス、携帯電話、パーソナルアシスタント、および調理器具などのシステムに組み込まれて、制御および／または監視を自動化しまたは半自動化するインテリジェントシステムを提供している。

サードパーティベンダは、ユーザフレンドリ性、柔軟性、選択肢、個別設定、信頼性、セキュリティ、および速度が改善されたアプリケーションにより、ユーザ体験を向上させるために、このような技術的躍進を活用してきた。このような向上は一般に、コード（たとえば、実行ファイル、ライブラリなど）の修正および／または追加により達成されるが、一般に、ファイルの追加および／またはアプリケーション（たとえば、ファイルの集約）サイズの増加がもたらされる。したがって、改善をもたらすために最新技術を活かす、サードパーティによるアプリケーション開発には一般に、より多くのディスク空間が必要となる。しかし、メモリおよび他のハードウェアが同時に進歩したことによって、ディスク容量およびシーク時間速度が向上し、アプリケーションサイズの増加および／またはメモリに格納されている、数が増加した異質なファイルの取得に適応することが可能である。

アプリケーション開発には一般に、既存のオペレーティングシステム（ＯＳ）の周辺にアプリケーションを構築し作成するために、時間および資金の大量投資が含まれる。たとえば、開発者は概して、ＯＳと通信しＯＳの計算能力を活かすようなインターフェースを構築するために、ＯＳアーキテクチャの少なくともいくつかの側面を理解しなければならない。さらに、開発者は通常、共通の記憶抽象化（たとえば、人々、場所、時間、およびイベントの表現）用の独自のデータストアを設計し生成する。その結果、複数のサードパーティベンダによる開発は、冗長な、または二重の開発努力という結果に終わる場合があり、複数のデータセットが、対応するアプリケーションの外では共有することも使用することもできなくなる。アプリケーションに関連する情報の多くは、そのアプリケーションにとってのみアクセス可能なファイル中にロックされたままとなり、データのグループは共有不可能となり得る。

オペレーティングシステム周辺のアプリケーションを理解し生成するためにリソースを費やすことに加え、サードパーティ開発者は、ファイルシステムまたはオペレーティングシステムに対する修正（たとえば、改訂、パスなど）、あるいは次世代オペレーティングシステムによって、アプリケーションの互換性がなくなり、したがって非機能的になり得る確率がより高くなる事態に直面する。たとえば、メモリが（たとえば、１６ビットから６４ビットに）アドレス指定されるという技術の変化により、アプリケーションは、オペレーティングシステムと実質的に互換性がなくなる場合がある。影響を受けるサードパーティベンダは、オペレーティングシステムをもう一度改訂しまたは生成すると、さらに１組のアプリケーションがサポートされなくなる可能性があることがわかっているので、オペレーティングシステムの微妙な違いおよび複雑さの理解、ならびに既存のアプリケーションの改良または新しいアプリケーションの作成に、より多くのリソースを投資しなければならなくなる。

以下では、本発明のいくつかの態様の基本的な理解をもたらすために、本発明の簡略な要約を提示する。この要約は、本発明の包括的な概要ではない。本発明の主要な／重大な要素を明らかにすることも、本発明の範囲を詳述することも意図していない。後で提示するより詳細な説明の前置きとして、本発明のいくつかの概念を簡略な形で提示することだけを目的としている。

本発明は、動作環境において、異質な（たとえば、オーディオおよびビデオ）データに渡って統一して利用することができる任意の（たとえば、オーディオおよびビデオ）アプリケーションフロントエンドを効率的に開発するための機構をサードパーティ開発者に提供する、プラットフォームに統合することができる豊かなファイル管理システムのためのシステムおよび方法を提供する。従来、サードパーティベンダは、オペレーティングシステムと通信しその中で動作することができるアプリケーションを構築するために、動作環境の様々な側面を理解するという負担が課せられている。このような努力は、たとえば、アプリケーションフロントエンドの開発のためにより効率的に利用することができる時間およびリソースを消費し得る。さらに、同様の市場（たとえば、音楽プレーヤ）において競合している異なるサードパーティベンダによる努力の結果、共有することができない冗長なまたは二重の作業および／または基本的に関連するアプリケーションとのみ互換性がある多数の異質なファイル形式が生じ得る。本発明は、オペレーティングシステム周辺のアプリケーションを構築するためのＡＰＩをサードパーティに提供することによって、このような努力を緩和することができる。概して、提供されるＡＰＩは通常、オーディオおよびビデオデータなど、異質なデータタイプに対してシームレスな操作をもたらす、豊富な様々なスキーマに基づく。したがって、サードパーティベンダは、ＡＰＩを使用し、ユーザの体験を向上させ得るアプリケーションフロントエンドの構築に専念することができ、新規ファイルシステムは、異質な日付を管理する。

本発明の一態様では、ファイルを管理するシステムが提供される。このシステムは、オーディオおよび／またはビデオファイルなどの情報の格納および取得に適応するコンポーネントを含む。このコンポーネントは、ほぼすべてのタイプのデータに共通のスキーマおよび／または特定のデータに関連づけられた（たとえば派生）スキーマを利用することができる。このようなスキーマを使用することによって、類似記憶媒体における、ビデオ、オーディオ、ドキュメントなど、異質なデータの効率的で構造化された格納および管理が可能になり、データは、シームレスに識別し、区別し、アクセスすることができる。

本発明の別の態様では、データ管理システムが示される。このシステムは、様々な（たとえば、ビデオおよびオーディオ）スキーマを利用して、データベースにおけるデータの格納および／または組織化、データの照会、ならびに／あるいはデータの操作を円滑にする。さらに、このシステムは、それぞれのスキーマおよび／またはその派生スキーマに基づいて、ほぼあらゆるデータを格納することができるファイル管理システムとともに使用することができる。概して、ユーザおよび／またはアプリケーションが、格納のためにデータを与えると、このような格納を円滑にするのに適したスキーマを入手し使用することができ、ユーザおよび／またはアプリケーションがデータを要求すると、要求に円滑に応えるのに適したスキーマを入手することができる。

本発明の別の態様では、系統的に情報を格納し情報にアクセスするシステムが提供される。このシステムは、ユーザおよび／またはアプリケーションによって、システムと対話するのに使用することができるＡＰＩを備える。このＡＰＩは通常、データに関連づけられた（たとえば、オーディオおよびビデオ）スキーマに基づいて生成される。しかし、共通ＡＰＩは、複数のタイプのデータと使用できることが理解されよう。このシステムは、データの格納および取得を円滑にするインテリジェンスをさらに備える。

本発明のさらに別の態様では、ファイルの格納および管理に関連してスキーマを利用する方法が提供される。第１の方法は、（たとえば、オーディオおよび／またはビデオ）ファイルを受け取ること、関連する（たとえば、共通およびカスタマイズされた）スキーマを入手すること、ならびにデータベースにファイルを格納するのにそのスキーマを使用することを含む。第２の方法は、１つまたは複数のスキーマに基づいて生成されるＡＰＩを提供する。開発者は、このＡＰＩの周辺にアプリケーションを構築することができ、ユーザおよび／またはアプリケーションは、適切なＡＰＩを介して情報を転送することができる。適切なスキーマの例は、汎用、オーディオ、およびビデオ関連スキーマを含む。

本発明のさらに他の態様では、例示的なスキーマが示される。例示的なスキーマは、メディア、オーディオ、およびビデオスキーマを含む。多くの例において、オーディオおよび／またはビデオスキーマは、メディアスキーマから派生することができる。

上記の目的および関連する目的を達成するために、本発明は、これ以降で十分に説明するとともに特許請求の範囲において具体的に示す特徴を含む。以下の説明および添付の図面では、本発明の特定の例示的な態様および実装形態を詳細に説明する。ただし、こうした態様および実装形態は、本発明の原理を利用することができる様々な方法のごくわずかを示すに過ぎない。本発明の他の目的、利点および新規な特徴は、本発明の以下の詳細な説明を図面と併せ読むことにより、明らかになるであろう。

本発明は、データベースにデータを格納し管理する豊かなファイル管理システムを提供するシステムおよび方法に関する。本システムおよび方法は、オーディオおよびビデオデータなど、異質なデータに渡って統一して作用するアプリケーションを任意に生成するためのインターフェースをアプリケーション開発者に提供するために、オペレーティングシステムとともに利用することができる。本発明は、スキーマを定義しスキーマからＡＰＩを提供することにより、ベンダが、オペレーティングシステムとインターフェースをとり、通信するのに費やす作業を削減させ得る。したがって、サードパーティベンダは、ユーザの体験を向上させ得るアプリケーションフロントエンドの構築に専念することができる。

本出願において使用する「コンポーネント」という用語は、コンピュータ関連のエンティティ、すなわちハードウェア、ハードウェアおよびソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。たとえば、コンポーネントは、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、および／またはコンピュータでよいが、それに限定されない。例として、サーバ上で実行されているアプリケーションおよびそのサーバが両方とも、コンピュータコンポーネントとなり得る。１つまたは複数のコンポーネントが、実行のプロセスおよび／またはスレッド中に存在してよく、コンポーネントは、１台のコンピュータに配置することも、そして／または２台以上のコンピュータの間に分散することもできる。公知のように、スレッドは、スレッドの実行に関連づけられた揮発性データである、関連する「コンテキスト」を有することができる。スレッドのコンテキストは、システムレジスタのコンテンツおよびスレッドのプロセスに属す仮想アドレスを含む。

ここで図面を参照して本発明を説明するが、同じ参照番号は、全体を通して同じ要素を指すのに使用している。以下の記述では、説明の目的で、多くの具体的な詳細を、本発明の完全な理解をもたらすために述べる。ただし、こうした具体的な詳細なしでも本発明を実施できることが明らかであろう。他の例では、本発明の説明を円滑にするために、公知の構造およびデバイスをブロック図の形で示す。

図１は、本発明の態様による、ファイルを管理するシステム１００を示す。システム１００は、ファイル管理コンポーネント１１０、ファイルシステム１１０、およびログ１２０を備える。ファイル管理コンポーネント１１０は、ファイルシステム１２０において、異質なファイル（たとえば、オーディオ、ビデオ、画像、ドキュメントなど）を受け取り、格納し、管理することができる。さらに、ファイル管理コンポーネント１１０は、関係を形成することにより、格納されている情報とのリンクを確立することができる。従来のシステムとは異なり、異質な情報を、独立データではなくエンティティとして管理することができるので、このような関係が可能である。例として、関係は、たとえば作成者、ピクチャ、ロゴなどの情報をオーディオおよび／またはビデオデータにリンクするための機構を提供することができる。これにより、データの内部の構造を知る必要なしに、様々なタイプの（たとえば、異質な）データに渡って、そしてその中で情報共有および効率的なクエリを可能にする。

概して、関係は、１つまたは複数のコンタクトアイテムとともに確立することができる。たとえば、作成者の関係は、幅広いクラスのオーディオおよび／またはビデオ作成者を取り込むように確立し、使用することができる。たとえば、それぞれのミュージシャン（達）、作成者（達）、指揮者（達）、バイオリニスト（達）、関係者（達）、ディレクタ（達）などは、レコードの作成者と見なすことができ、映画のクレジットに列挙されている作成者は、ビデオの作成者と見なすことができ、関係に関連づけられた役割により、異なるタイプの作成者を互いに区別することができる。したがって、オーディオまたはビデオは、「ミュージシャン」と定義される役割をもつコンタクトアイテムを有する関係、「作曲家」と定義される役割をもつ異なるコンタクトアイテムを有する別の関係、「指揮者」と定義される役割をもつ異なるコンタクトアイテムを有する別の関係、などを有し得る。コンタクトアイテムは、たとえば、電話番号、アドレス、およびｅメールへのリンクなど、ある人についての情報をさらに含み得ることを理解されたい。

上述したように、コンタクトアイテムは、データに渡る効率的なクエリを可能にする。たとえば、コンタクトアイテムの利用により、映画／レコードのクレジット一覧を得るための、異質なデータに渡るクエリ（群）が可能になる。別の例では、クエリ（群）は、ある特定のアーティストに関連づけられたすべての作品についてのデータに渡って実施することができる（たとえば、アーティストのコンタクトアイテムを使用し、そのアイテムとのすべての作成者関係を列挙する）。このようなクエリは、そのアーティストによって作られた歌、そのアーティストが歌った歌、アーティストについて書いた、そして／またはアーティストについての本、そのアーティストが出演した映画、などを返すことができる。コンタクトアイテムとの関係が、このような機能を可能にし、オーディオおよび／またはビデオデータは、このような情報を含むことができないことを理解されたい。この利点は、ビデオの監督および俳優が身内および／または友人であり得るホームビデオでも活かすことができる。

ファイル管理コンポーネント１１０は、推奨メタデータをさらに特定し、提供し、ファイルに関連づけることができ、推奨メタデータは、このようなメタデータが実際にファイルに関連づけられる信頼性の程度を示す信頼性レベルを含み得る。たとえば、オーディオトラックが受け取られると、ファイル管理コンポーネント１１０は、様々なレベルの信頼性を有する、推奨メタデータとの関係を確立することができる。たとえば、ファイル管理コンポーネント１１０は、信頼性に基づいてトラックのソースに関連づけられると判断されたレコードメタデータを（たとえば、ローカルおよび／またはリモートソースを介して）入手し、信頼性とともにそのメタデータを提供することができる。本発明の一態様では、トラック用のメタデータを特定し、得るためのアルゴリズムを利用することができる。ユーザおよび／またはシステム１００とともに利用されるインテリジェンスは、推奨データから適切なメタデータを選択することができ、推奨された、そして／または選択されたいずれかまたはすべてのメタデータを、レコードとともに格納することができる。別の例では、トラックを要求し、または聴いているユーザに、トラックに関連する他のメディアを知らせることができる。たとえば、そのトラックを演奏しているアーティストが、テレビに出演する予定であるという特別なことをユーザに知らせることができる。

メタデータの取得および／または計算における異なるステップおよび／または段階に対応する状態を取り込む様々なフィールドを介して、メタデータをライフサイクルに関連づけることができることに留意されたい。たとえば、メタデータは、メタデータの取得が試みられたが失敗した回数を追跡するフィールドに関連づけることができる。このような情報は、メタデータを取得しようとする試みの繰返しを軽減するのに使用することができる。たとえば、試行の閾値は、閾値に達すると、オーバーライド信号が受け取られない限り、および／または信号が受け取られるまで、取得の試みを中止し得るように定めることができる。別の例では、メタデータは、メタデータを取得するのに使用されるリソースに関する制約（たとえば、ネットワーク接続性）およびどれだけ素早くメタデータを入手することができるかを決定する優先順位を定義するフィールドに関連づけることができる。

ファイル管理コンポーネント１１０はさらに、オーディオレコードとそのソースアルバムの間の関連づけの解決を円滑にし得る。概して、オーディオレコードは通常、そのソースアルバムに関する少なくとも何らかの情報（たとえば、名称、タイトル、作成者など）を含む。ただし、多くの例において、この情報は、正当であるが、不正確な場合があり、そして／または同じソースからのオーディオレコードの間で変わり得る。たとえば、情報は、誤字があり、説明が誤っており、そして／または変更される場合がある。ファイル管理コンポーネント１１０は、どのような矛盾も解決するために、実際のアルバム情報（たとえば、名称、タイトル、作成者など）を取得し、元の、すなわち（オーディオレコードからの）認知された情報およびオーディオレコードを有する（アルバムからの）実際の情報を両方とも格納することができる。たとえば、元の情報は、アルバムに関連づけられた関係のプロパティに含めることができる。元の情報は、（たとえば、トラックがコピーされ、または削除されるとき）オーディオトラックに結びつけられたままであり、実際の情報は、どの不一致も解決するために入手され、使用されることに留意されたい。

ファイル管理コンポーネント１１０はさらに、ファイルにレイティングを関連づけることができる。概して、レイティングは、ファイルのタイプ（たとえば、映画、オーディオトラックなど）に基づいて、当局（たとえば、ＭＰＡＡ、ＲＩＡＡ、ＴＶ、ユーザなど）に関連づけ、様々なスケール（たとえば、保護者の指導、品質、ユーザなど）を反映することができる。このようなレイティングは、様々な種類のファイルに渡って使用することができる。たとえば、レイティングは、ユーザの「お気に入り」を照会するのにも、ユーザに基づいて、ユーザに提供されるコンテンツ（たとえば、オーディオ、ビデオ、本、ピクチャなど）を制限するのにも使用することができる。

ファイル管理コンポーネント１１０はさらに、ファイル履歴を維持することができる。ファイル履歴は、ファイルが編集されたかどうか、どのようにファイルが編集されたか、いつファイルが編集されたか、ファイルはｅメールで送られたか、誰にファイルがｅメールで送られたか、などに関する情報を含み得る。このような履歴は、インテリジェントな意思決定を行うために、アルゴリズムとともに使用することができる。たとえば、履歴は、ファイルがアクセスされた回数に基づいて「お気に入り」リストを自動的に構成し、特定の日時に特定の順序でファイルを自動的に実行するために、取得し利用することができる。ユーザがファイルの編集に多くの時間を費やしたという判断は、そのファイルがユーザにとって重要であり、消去されるべきでないということを示し得る。

ファイル管理コンポーネント１１０は、ビデオのサブパートに関する付加情報に名前をつけ、付加情報を格納することができる。このような能力は、たとえば、映画のお気に入りパートを示すのに使用することができる。たとえば、サブパートは、「お気に入りのパート」という名前をつけ、「．．．であるパート」などの記述を含むことができる。別の例では、映画内容を表す映画のパートを識別することができる。サブパートは、対応する映画パートをすぐに再生するのに利用することができる。たとえば、ある特定の俳優を含む映画パートのみを再生するような要求を行うことができる。

上記は例示であり、限定でないことを理解されたい。後で説明する新規の態様を含む他の様々なファイル管理機能は、システム１００とともに実施できることが当業者には理解されよう。

図２は、本発明の態様によるファイルシステム２００を示す。ファイルシステム２００は、データバンク２２０に格納される入力を受け取ることができるデータマネージャ２１０を備える。入力は、オーディオおよび／またはビデオデータを含むが、それに限定されない、ほぼどのタイプの電子データでもよい。適切なオーディオデータの例は、ＣＤからリッピングされたオーディオファイル、オーディオレコーダから生成されたオーディオファイル、オーディオハードウェア（たとえば、サウンドカード）を介して記録されたオーディオ、アルバムおよび／またはテープ（たとえば、カセット、８トラック、オープンリールなど）からのアナログオーディオ、メモリ（たとえば、メモリスティックおよび他のポータブルメモリ）からのオーディオファイル、（たとえば、インターネットを介して）ダウンロードしたオーディオファイルなどを含む。適切なビデオデータの例は、ＤＶＤ、ビデオＣＤ（ＶＣＤ）、カムコーダ、デジタルカムコーダ、デジタルカメラなどからのデータを含む。他のデータは、画像、ドキュメントなどを含み得る。

データマネージャ２１０は、スキーマストア２３０からの入力に関連づけられたスキーマ（たとえば、後で詳しく説明するメディア、ビデオ、およびオーディオスキーマ）を入手することができる。たとえば、オーディオ入力用に、データマネージャ２１０は、スキーマストア２３０から、オーディオデータに関連するスキーマを取得することができる。このようなスキーマは、共通でも、公知のほぼどのタイプの入力（たとえば、ドキュメント、オーディオ、およびビデオ）も表し得る基本スキーマでもよい。別の例では、取得されるスキーマは、入力に関連づけられた少なくとも１つの特性（たとえば、プロパティ）に基づいてカスタマイズされ、そして／または向上される共通スキーマの派生物でよい。このような派生スキーマは、多重定義および／または基本スキーマに対する拡張を含み得る。さらに別の例では、スキーマは、データタイプに合わせてあつらえることができる。

データマネージャ２１０は、豊富なスキーマを使用して、データバンク２２０への、入力の系統的な格納および組織化を円滑にし得る。共通スキーマおよび／または基本スキーマから派生したスキーマを利用することにより、異質なデータ（たとえば、ビデオ、オーディオ、ドキュメントなど）を同様の記憶媒体に格納することが可能になり、データマネージャ２１０は、それぞれの異質なデータをシームレスに識別し、区別し、アクセスすることができる。さらに、異質なデータに渡って関連づけを形成することができる。このような機能は、一般にファイル中でのデータ構造を企図していないので、ファイルは通常、そのファイルを生成したアプリケーションにとってのみアクセス可能である、従来のファイルシステムを向上させる。

データマネージャ２１０はさらに、データバンク２２０に格納されているデータに対する要求に関連する入力を受け取ることができる。たとえば、ユーザは、オーディオプレーヤを実行し、再生するオーディオトラック（群）またはファイル（群）を選択することができる。データマネージャ２１０は、オーディオトラック（群）に関連づけられたスキーマを使用して、選択されたトラック（群）を特定し、トラック（群）へのアクセスを提供することができる。同様に、データバンク２２０に格納されているビデオおよび他のデータには、データマネージャ２１０により、このようなデータに関連づけられたスキーマを介してアクセスすることができる。

ファイルシステム２００は、オペレーティングシステムとともに利用できることを理解されたい。このようなオペレーティングシステムにより、サードパーティベンダは、一般にベンダ間で共有することができない固有スキーマを構築することではなく、ユーザ体験を向上させるマルチメディアアプリケーション用の豊かなフロントエンドを生成すること、およびアプリケーションをオペレーティングシステムとインターフェースさせることに、アプリケーション開発を集中させることができるようになる。したがって、本発明の新規な態様は、異質なデータを利用する任意のアプリケーションを生成するための土台としてベンダ用に使用することができる、拡張可能なプラットフォームを提供する。

図３は、本発明の態様による、データを管理するシステム３００を示す。システム３００は、少なくともビデオスキーマ３３０およびオーディオスキーマ３４０を含むスキーマ３２０に関連づけられたデータベース３１０を備える。ユーザおよび／またはアプリケーションは、データを格納し、そして／または組織化するためにデータベース３１０と対話し、データベース３１０中のデータを照会し、そして／または操作する（たとえば、編集し、移動し、消去する）ことができ、データは、たとえば、異質なオーディオおよび／またはビデオ情報を含み得る。

スキーマ３２０は一般に、基本、またはどのメディアも表し得る汎用スキーマであり、ビデオスキーマ３３０およびオーディオスキーマ３４０は通常、それぞれ、ビデオおよびオーディオデータ用の、ドメイン特有のプロパティを含み得るスキーマ３２０の拡張である。本発明の一態様において、ビデオスキーマ３３０およびオーディオスキーマ３４０は、汎用スキーマ３２０に基づくことができ、他のスキーマ（図示せず）をさらに提供できることに留意されたい。このようなスキーマは、中央ファイルシステムとも、ファイル管理システムとも（たとえば、オペレーティングシステムとともに）使用することができ、ビデオスキーマ３３０およびオーディオスキーマ３４０を含むそれぞれのスキーマおよび／またはその派生物に基づいて、ほぼあらゆるファイルを格納することができる。

概して、ユーザおよび／またはアプリケーションが、データベース３１０に格納されることになるデータをデータベース３１０に伝えると、適切なスキーマを入手することができる。たとえば、１つのトラックまたは一群のトラックなど、オーディオデータが、格納のためにデータベース３１０に伝送されると、構造化方式でのオーディオデータの格納を円滑にするのに、スキーマ３２０またはオーディオスキーマ３４０を取得し、使用することができる。さらに、ユーザおよび／またはアプリケーションは、このような保存されたデータを操作するとき、スキーマを使用することができる。たとえば、ユーザおよび／またはアプリケーションが、編集、消去、移動などを試みる場合、このような操作を円滑にするのに、格納されているオーディオデータ、スキーマ３２０、および／またはオーディオスキーマ３４０を取得し、使用することができる。さらに、ユーザおよび／またはアプリケーションからのクエリに応えるのを円滑にし、たとえば、再生のために音楽トラックを返すのを円滑にするのに、スキーマを取得し、使用することができる。

適切なアプリケーションは、たとえば、様々なメディアプレーヤ、オーディオプレーヤ、およびビデオプレーヤなど、公知のどのオーディオおよび／またはビデオアプリケーションも含み得ることを理解されたい。さらに、複数のアプリケーションが、１つのスキーマ（たとえば、基本スキーマ３２０、ビデオスキーマ３３０、およびオーディオスキーマ３４０）を同時に利用することができ、その結果、効率および性能を向上させ得る。１つまたは複数のシステムから、１人または複数のユーザにより、複数のアプリケーションを実行できることを理解されたい。

図４は、本発明の態様による、情報を系統的に格納しアクセスするのに使用することができるシステム４００を示す。システム４００は、ユーザおよび／またはアプリケーションによってシステム４００と対話するのに使用することができるアプリケーションプログラムインターフェース（ＡＰＩ）４１０を備える。本発明の一態様において、システム４００は、１つまたは複数のスキーマに基づいて様々なＡＰＩを作成することができるＡＰＩジェネレータ４２０を含み得る。たとえば、ＡＰＩジェネレータ４２０は、スキーマジェネレータ４３０によって作成されたオーディオスキーマに基づいて、オーディオＡＰＩを作成することができる。スキーマジェネレータ４３０は、オーディオ構成４４０および／または基本（たとえば、メディア）構成４５０により、このようなスキーマを作成することができる。

別の例では、ＡＰＩジェネレータ４２０は、基本構成４５０および／またはビデオ構成４６０に基づき得るビデオおよび／または汎用スキーマに基づいて、ビデオＡＰＩを作成することができる。さらに別の例では、ＡＰＩジェネレータ４２０は、ほぼどのタイプのデータとも使用することができる共通（たとえば、メディア）ＡＰＩを作成することができる。ユーザおよび／またはアプリケーションは、このようなＡＰＩを利用して、データベース４７０に情報を送信し／データベース４７０から情報を受信することができる。たとえば、ユーザおよび／またはアプリケーションは、適切なＡＰＩを利用して、データベース４７０にオーディオおよび／またはビデオデータを格納し、そして／またはデータベース４７０からそうしたデータを取得することができる。

１つまたは複数のシステムから、１人または複数のユーザにより、複数のアプリケーションを実行できることを理解されたい。したがって、本質的にどのユーザおよび／またはアプリケーションも、ＡＰＩ４１０を介してデータベース４７０と通信することができる。

インテリジェンスコンポーネント４８０は、データの格納および取得、スキーマ生成およびＡＰＩ生成、ならびにアクションの自動化および決定の実行など、他の様々な用途を円滑にするのに利用することができる。たとえば、インテリジェンスコンポーネント４８０は、タイトルとのトラックの関連づけを円滑にし得る。たとえば、ユーザは、いくつかのトラックをデータベース４７０に格納することができ、複数のトラックは、類似したソースから生じ得るが、ソースのタイトルの変化を含む。たとえば、ユーザは、トラックをリッピングした後、タイトル名を書き間違える場合がある。インテリジェンスコンポーネント４８０は、このような問題の解決を円滑にし得る。たとえば、本発明の一態様において、インテリジェンスコンポーネントは、類似の差異を入手し、そして／またはこのような差異を推論し、問題の解決を円滑にするのに使用することができる。本発明の別の態様において、インテリジェンスコンポーネント４８０は、さらに情報を求めて、ユーザおよび／またはアプリケーションに入力を促すことができる。さらに、インテリジェンスコンポーネント４８０は、統計値、確率、分類子、および推論を利用することができる。

ユーザおよび／またはアプリケーションは、インテリジェンスコンポーネント４８０による自動化および意思決定の量（たとえば、ゼロから全部）を決定する設定を定義することができる。さらに、インテリジェンスコンポーネント４８０は、履歴情報を使用して、自動化および意思決定の量を自己定義することができる。たとえば、インテリジェンスコンポーネント４８０は、インテリジェンスコンポーネント４８０によって行われた特定のアクションおよび／または決定をユーザおよび／またはアプリケーションが拒否した回数を利用することができ、この場合、閾値より大きい数は、インテリジェンスコンポーネント４８０が完全な自動化を利用するべきでないことを示し得る。本発明の別の態様において、ユーザおよび／またはアプリケーションは、インテリジェンスコンポーネント４８０がトレーニングセットから学習を行い得るように、インテリジェンスコンポーネント４８０にトレーニングセットを与えることができる。

概して、インテリジェンスコンポーネント４８０の推論は、イベントおよび／またはデータを介して取り込まれた１組の観察結果から、システム、環境、および／またはユーザの状態を類推しまたは推論するプロセスを指す。さらに、推論は、たとえば、特殊なコンテキストまたはアクションを識別するのに利用することもでき、状態に渡る確率分布を生成することもできる。さらに、推論は、確率論的でよく、たとえば、データおよびイベントの考慮に基づく、興味のある状態に渡る確率分布の計算でよい。推論は、１組のイベントおよび／またはデータから、より高いレベルのイベントを組み立てるのに利用される技法も指し得る。このような推論の結果、イベントが、時間的に近接して相関づけられるかどうか、イベントおよびデータが、１つのイベントおよびデータソースからのものであるか、それともいくつかのソースからのものであるかに関わらず、観察された１組のイベントおよび／または格納されているイベントデータから、新しいイベントまたはアクションが構成される。様々な分類方式および／またはシステム（たとえば、サポートベクトルマシン、ニューラルネットワーク、エキスパートシステム、ベイズの信念ネットワーク、ファジー理論、データ融合エンジンなど）は、本発明とともに、自動的および／または推論によるアクションの実施に関連して利用することができる。

図５および６は、本発明の態様による方法を示す。説明を簡単にするために、方法を、一連のアクトとして示し説明するが、本発明はアクトの順序によって限定されないことを理解されたい。というのは、いくつかのアクトは、本発明に従って異なる順序で起こることもでき、そして／または本明細書において示し説明する他のアクトと同時に起こることもできるからである。たとえば、本方法は、状態図でのように、相関する一連の状態またはイベントとしても表すことができることが当業者には理解されよう。さらに、例示するすべてのアクトが、本発明による方法の実装に必要となり得るわけではない。

図５は、本発明の態様による、ファイル管理システムとともに豊富なスキーマセットを利用する方法５００を示す。参照番号５１０に進むと、ファイルが受け取られる。本発明の一態様において、受け取られるファイルは、オーディオおよび／またはビデオデータを含むことができ、たとえば、ユーザ、アプリケーション、または、アプリケーションを介したユーザによって伝えることができる。

参照番号５２０で、ファイルに関連づけられたスキーマが取得される。たとえば、公知のほぼどのタイプのファイルも表し得る共通スキーマを取得することができる。別の例では、取得されるスキーマは、ファイルの形式に対応し得る。たとえば、スキーマは、オーディオファイルの格納を円滑にするのに使用されるオーディオベースのスキーマでも、ビデオファイルの格納を円滑にするのに使用されるビデオベースのスキーマでもよい。このような形式ベースのスキーマは、共通スキーマから派生することができ、ファイル形式に基づいて共通スキーマをカスタマイズし、そして／または向上させるのに使用できることを理解されたい。

適切なスキーマを取得した後、５３０で、スキーマは、データベースにファイルを格納するのに利用することができる。一般に、スキーマは、データベース中の他の情報を参照してファイルを系統的に配置できるようにする。このようなスキーマは、他のスキーマと同様に、ファイルシステムとともに、たとえば、オペレーティングシステムと共同で使用することができ、ほぼどのファイルも、および／またはすべてのファイルを、スキーマおよび／またはその派生物に基づいて格納できることを理解されたい。

図６は、本発明の態様による、データベースにおけるファイル管理を円滑にする方法６００を示す。参照番号６１０で、ユーザおよび／またはアプリケーションとデータベースの間の対話を円滑にするＡＰＩが生成される。このＡＰＩは、ファイルを格納し、操作し、取得し、そして／またはデータベースから削除するのに利用することができる。使用されるＡＰＩは、ファイルから独立していても、依存していてもよい。独立ＡＰＩは、たとえば、ほぼどのタイプのファイルとも使用することができ、依存ＡＰＩは一般に、ファイル形式に基づいて生成され、その後、このような形式を有するファイルを伝達するときに利用される。たとえば、オーディオファイルに基づくＡＰＩは、オーディオファイルを伝えるのに使用することができ、ビデオファイルに基づくＡＰＩは、ビデオファイルを伝えるのに使用することができる。

６２０で、ユーザおよび／またはアプリケーションは、ＡＰＩを呼び出すことができる。たとえば、ユーザ／アプリケーションは、オーディオファイルの格納を望むとき、データベースにファイルを搬送するのに、共通またはオーディオベースのＡＰＩを利用することができる。別の例では、ユーザ／アプリケーションは、格納されているファイルを操作するための要求を送信することができる。たとえば、ユーザは、ファイル名、場所、タイプ、保護などを変更するよう要求し得る。さらに別の例では、ユーザ／アプリケーションは、ファイルがデータベースから削除、すなわち消去されることを要求し得る。さらに別の例では、ユーザ／アプリケーションは、ファイルを取得するためにデータベースを照会することができる。

６３０で、データベースは、関連づけられた、共通および／または拡張（たとえば、オーディオベースの）スキーマを入手して、ユーザ／アプリケーションへのサービス提供を円滑にすることができる。たとえば、スキーマは、データベースへのファイルの体系的な格納を円滑にするのに利用することができる。別の例では、スキーマは、ファイルのどの操作の範囲も定義するのに使用することができる。さらに別の例では、スキーマは、どのようにしてファイルを削除することができるか、および削除することができるかどうかを決定することができる。さらに別の例では、スキーマは、ファイルを求めるデータベースの検索に関連して利用することができる。このようなスキーマは、どのメディアも表し、任意選択で、ドメイン特有のプロパティ、たとえばビデオおよびオーディオデータを含み得る拡張を含むことができる汎用スキーマでよい。

ユーザ／アプリケーションの要求を満たすと、ＡＰＩは、データベースによって、ユーザ／アプリケーションに通知を行うのに利用することができる。たとえば、データベースは、肯定応答またはエラーコードを送信することができる。さらに、データベースは、ＡＰＩを使用して、ユーザ／アプリケーションにファイルを返すことができる。適切なアプリケーションは、公知のどのアプリケーション（たとえば、メディアプレーヤ、オーディオプレーヤ、およびビデオプレーヤ）も含むことができ、１つまたは複数のアプリケーションが、１つのスキーマを同時に利用できることを理解されたい。さらに、１つまたは複数のシステムから、１人または複数のユーザにより１つまたは複数のアプリケーションを実行することができる。

（スキーマ）
以下のセクションでは、本発明の態様に従って（たとえば、システム１００〜４００および方法５００〜６００とともに）利用することができる、例示的なメディア、ビデオ、およびオーディオスキーマを記述する。メディアスキーマは、Ｃｏｒｅスキーマ（たとえば、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔ）から派生することができ、ビデオおよび／またはオーディオスキーマは、Ｍｅｄｉａスキーマ（たとえば、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔ）および／またはＩｔｅｍ（たとえば、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍ）スキーマから派生できることを理解されたい。さらに、このようなスキーマは、たとえば、ドキュメント、画像、写真など、公知のどの種類のデータとも利用することができる。

（メディアスキーマ）
メディアスキーマは、Ｓｙｓｔｅｍ．ＳｔｏｒａｇｅおよびＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅのスキーマを使用する。さらに、メディアスキーマは、アイテムタイプ、拡張タイプ、関係タイプ、ネストしたタイプを含む。上記のタイプは、後で詳しく説明する。

（アイテムタイプ）
以下のテーブルは、例示的なドキュメントタイプを規定する。概して、このタイプは、たとえばトラック、アルバムなどのオーディオドキュメントを表し得る。このタイプは通常、ドキュメントに共通の１つまたは複数のフィールドを含む。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔから派生することができる。

（拡張タイプ）
以下のテーブルは、例示的なＭｅｔａｄａｔａＬｉｆｅｃｙｃｌｅタイプを規定する。概して、このタイプは、ライフサイクルおよび他の状態追跡を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｅｘｔｅｎｓｉｏｎから派生することができる。

（関係タイプ）
以下のテーブルは、例示的なＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒタイプを規定する。概して、このタイプは、コンテンツ（たとえば、ＰｒｅｓｓＰｌａｙ）のディストリビュータを指す。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅａｌｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｃｏｎｔａｃｔである。

ＥｆｆｅｃｔｉｖｅＢａｃｋＣｏｖｅｒＡｒｔタイプは、メディアドキュメントの裏表紙のピクチャへのリンクを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔである。

ＥｆｆｅｃｔｉｖｅＦｒｏｎｔＣｏｖｅｒＡｒｔタイプは、メディアドキュメントの前表紙のピクチャへのリンクを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔである。

ＭｅｔａｄａｔａＰｒｏｖｉｄｅｒＬｏｇｏタイプは、メタデータのオリジナルの提供元（たとえば、ＡＭＧ）に関連づけられたロゴを表し得る。上記のテーブルに加え、以下のテーブルは、本発明の態様に従って利用することができる例示的なタイプを規定する。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔである。

（ネストしたタイプ）
以下のテーブルは、例示的なＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒＤａｔａタイプを規定する。概して、このタイプは、Ｍｅｄｉａ情報のＣｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｏｒ用のＣｏｎｔａｃｔアイテムへのリンクを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＨｉｓｔｏｒｙタイプを規定する。概して、このタイプは、メディアドキュメントの履歴（たとえば、いつ編集されたか、どのように編集されたか、誰にメールを送ったか、回転されたか、フィルタが適用されたか、関連づけられた再生カウントなど）を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＲａｔｉｎｇタイプを規定する。概して、このタイプは、当局によってメディアドキュメントに与えられるレイティングを表し得る。たとえば、このような当局は、映像用のＭＰＡＡレイティング（たとえば、ＰＧ−１３、ＮＲ、Ｒ、Ｘ、およびＮＣ−１７）、オーディオ用のＲＩＡＡレイティング（たとえば、露骨な歌詞）、ＴＶレイティング、ならびに／またはユーザカスタムレイティングを含み得る。さらに、レイティングは、保護者の指導、品質、ユーザカスタムなどによって定めることができる。一般に、文字列レイティングおよび数値レイティングという、２つのタイプのレイティングがある。概して、このタイプは抽象タイプであり、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＣｕｓｔｏｍＲａｔｉｎｇタイプを規定する。概して、このタイプは、何らかの当局によって、メディアドキュメントに与えられる自由形式の文字列レイティングを表し得る。このタイプは、上述した抽象タイプＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｒａｔｉｎｇから派生することができる。

以下のテーブルは、例示的なＳｔａｒＲａｔｉｎｇタイプを規定する。概して、このタイプは、何らかの当局によって、メディアドキュメントに与えられる数値レイティングを表し得る。このタイプは、上述した抽象タイプＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｒａｔｉｎｇから派生することができる。

以下のテーブルは、例示的なＵＲＬＲｅｆｅｒｅｎｃｅタイプを規定する。概して、このタイプは、ＵＲＬおよびそのＵＲＬタイプを示すカテゴリを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＭＶＳｔｒｉｎｇ１２８タイプを規定する。概して、このタイプは、多値文字列ラッパーを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＭＶＳｔｒｉｎｇ２５６タイプを規定する。概して、このタイプは、多値文字列ラッパーを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

（ビデオスキーマ）
ビデオスキーマは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ、およびＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅのスキーマを使用する。さらに、メディアスキーマは、アイテムタイプ、拡張タイプ、関係タイプ、ネストしたタイプを含む。上記のタイプは、後で詳しく説明する。

（アイテムタイプ）
以下のテーブルは、例示的なＶｉｄｅｏＲｅｃｏｒｄタイプを規定する。概して、このタイプは、ビデオ録画を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔから派生することができる。

以下のテーブルは、例示的なＲｅｃｏｒｄｅｄＴＶタイプを規定する。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｖｉｄｅｏ．ＶｉｄｅｏＲｅｃｏｒｄから派生することができる。

以下のテーブルは、例示的なＶｉｄｅｏＣｌｉｐタイプを規定する。概して、このタイプは、ビデオクリップを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍから派生することができる。

（関係タイプ）
Ｃｌｉｐｓタイプは、ビデオレコード用の１組のクリップを指し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｖｉｄｅｏ．ＶｉｄｅｏＲｅｃｏｒｄであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｖｉｄｅｏ．ＶｉｄｅｏＣｌｉｐである。

（ネストしたタイプ）
以下のテーブルは、例示的なＶｉｄｅｏＳｕｂＳｈｏｔタイプを規定する。概して、このタイプは、ビデオレコード用のサブショットを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

（オーディオスキーマ）
オーディオスキーマは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ、およびＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｍａｇｅのスキーマを使用する。さらに、メディアスキーマは、アイテムタイプ、拡張タイプ、関係タイプ、ネストしたタイプを含む。上記のタイプは、後で詳しく説明する。

（アイテムタイプ）
以下のテーブルは、例示的なＣａｃｈｅｄＡｌｂｕｍタイプを規定する。概して、このタイプは、いくつかのトラックを含み得るオーディオを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔから派生することができる。

以下のテーブルは、例示的なＡｕｄｉｏＲｅｃｏｒｄタイプを規定する。概して、このタイプは、オーディオレコードに関連づけられたメタデータを表し得る。メタデータは、たとえば、ファイルサイズ、ファイル形式、使用される圧縮のタイプなどの情報を含み得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔから派生することができる。

以下のテーブルは、例示的なトラックタイプを規定する。概して、このタイプは、音楽データを含むオーディオトラックを表し得る。たとえば、このタイプは、ＣＤからリッピングされている、またはファイルシステムに格納されているトラックに対応し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄから派生することができる。

以下のテーブルは、例示的なＣａｃｈｅｄＴｒａｃｋタイプを規定する。概して、このタイプは、キャッシュされたオーディオトラック用のメタデータを表し得る。本発明の一態様において、ＣａｃｈｅｄＴｒａｃｋタイプは、データの識別を円滑にするのに利用することができる。たとえば、ユーザは、ＣＤを挿入することができるが、１つまたは複数の候補トラックが、自動的にＣａｃｈｅｄＴｒａｃｋに格納され、ユーザに与えられる。ユーザは、ＣＤに対応するリストからトラックを選択する（または異なるトラックを与える）ことができる。次いで、他のトラックをＣａｃｈｅｄＴｒａｃｋから削除することができ、選択したトラックをＡｕｄｉｏ．ＴｒａｃｋまたはＡｕｄｉｏ．ＰｌａｔｔｅｒＴｒａｃｋに提供することができる。したがって、ＣａｃｈｅｄＴｒａｃｋは、潜在的なトラック情報の一時的な格納場所を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄから派生することができる。

以下のテーブルは、例示的なＰｌａｔｔｅｒＴｒａｃｋタイプを規定する。概して、このタイプは、オーディオトラック用のメタデータを表し得る。このようなメタデータは、データとともに維持することができ、たとえば、トラックがＣＤからリッピングされるとき、メタデータを、リッピングされたトラックに含めることができる。さらに、メタデータは、データを認識するのに使用することができる。たとえば、ある特定のＣＤを要求することができる。メタデータにより判定されたように、誤ったＣＤが提供された場合、誤ったＣＤが挿入されたことをユーザに通知することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄから派生することができる。

以下のテーブルは、例示的なＰｌａｙＬｉｓｔタイプを規定する。概して、このタイプは、オーディオプレイリストを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔから派生することができる。

以下のテーブルは、例示的なＲａｄｉｏＳｔａｔｉｏｎタイプを規定する。概して、このタイプは、ラジオのストリームを提供することができるラジオ局を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍから派生することができる。

以下のテーブルは、例示的なＲａｄｉｏＳｔｒｅａｍタイプを規定する。概して、このタイプは、ラジオ局によって提供されるラジオストリームを表し得る。たとえば、このタイプは、ＲａｄｉｏＳｔａｔｉｏｎアイテムに組み込むことができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍから派生することができる。

以下のテーブルは、例示的なＬｉｓｔｅｎｉｎｇＨａｂｉｔｓタイプを規定する。概して、このタイプは、トラックに関して、ユーザに関連づけることができる。たとえば、このアイテムは、ユーザの音楽再生体験をカスタマイズするのに使用することができる。このアイテムは、ユーザ単位およびメディア単位のデータに対して利用することができ、「所有者」用の各レコード上にＡＣＬがある。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍから派生することができる。

以下のテーブルは、例示的なＬｉｓｔｅｎｉｎｇＨａｂｉｔｓｌｏｇタイプを規定する。概して、このタイプは、トラックに関して、ユーザに関連づけることができる。たとえば、このアイテムは、ユーザ単位およびメディア単位のデータに対して、ユーザの音楽再生体験をカスタマイズするのに使用することができ、「所有者」用の各レコード上にＡＣＬがある。このアイテムは、メディア再生に関連する（たとえば、何か月にも及ぶ）複数のインスタンスを含み得る。さらに、アプリケーションは、データを処理し、そして／またはクリーンアップし、メディアを聴く習慣の、時間経過に伴う自然減衰を受ける要約テーブルを生成することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍから派生することができる。

（拡張タイプ）
以下のテーブルは、例示的なＡｒｔｉｓｔＩｎｆｏｒｍａｔｉｏｎタイプを規定する。このタイプは、インテリジェントなグループ化を可能にし得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｅｘｔｅｎｓｉｏｎから派生することができる。

（関係タイプ）
以下のテーブルは、例示的なＴｒａｃｋＡｌｂｕｍタイプを規定する。概して、このタイプは、トラックから、関連づけられたアルバムへのリンクを表し得る。たとえば、トラックは通常、そのソースに関する情報を含む。トラックが受け取られると、トラックとともに含まれる情報は、そのソースを識別する認知された関係を作成するのに使用することができる。実際のソースが識別されると、認知された関係を使用し、実際のソースに関連づけることができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＣａｃｈｅｄＡｌｂｕｍである。

以下のテーブルは、例示的なＳｕｇｇｅｓｔｅｄＭｅｔａｄａｔａタイプを規定する。概して、このタイプは、メタデータを追跡するための１組のリンクを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＣａｃｈｅｄＴｒａｃｋである。

以下のテーブルは、例示的なＲａｄｉｏＳｔａｔｉｏｎＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒタイプを規定する。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＲａｄｉｏＳｔａｔｉｏｎであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｃｏｎｔａｃｔである。

以下のテーブルは、例示的なＲａｄｉｏＳｔａｔｉｏｎＬｏｃａｔｉｏｎタイプを規定する。概して、このタイプは、プログラミング元の場所を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＲａｄｉｏＳｔａｔｉｏｎであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｌｏｃａｔｉｏｎである。

ＲａｄｉｏＳｔａｔｉｏｎＬｏｇｏタイプは、ラジオ局のロゴの画像を含む画像へのリンクを表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＲａｄｉｏＳｔａｔｉｏｎであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔである。

ＲａｄｉｏＳｔａｔｉｏｎＳｔｒｅａｍｓタイプは、ラジオ局が提供し得るストリームの集合体を表し得る。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＲａｄｉｏＳｔａｔｉｏｎであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＲａｄｉｏＳｔｒｅａｍである。

Ｌｉｓｔｅｎｅｒｓタイプは、リスナーとの関係を提供することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＬｉｓｔｅｎｉｎｇＨａｂｉｔｓであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｒｅ．Ｃｏｎｔａｃｔである。

ＬｉｓｔｅｎｅｄＴｒａｃｋタイプは、聴取されるトラックとの関係を提供することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐから派生することができる。ソースタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．ＬｉｓｔｅｎｉｎｇＨａｂｉｔｓであり、ターゲットタイプはＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ａｕｄｉｏ．Ｔｒａｃｋである。

（ネストしたタイプ）
以下のテーブルは、例示的なＡｕｔｏＤＪタイプを規定する。概して、このタイプは、トラックの分析を介して、１つまたは複数のプレイリストを作成するために、アルゴリズムとともに使用することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

以下のテーブルは、例示的なＰｌａｙＣｏｕｎｔｅｒタイプを規定する。概して、このタイプは、トラックが再生される回数（たとえば、毎時間、毎日など）を追跡するのに使用することができる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＮｅｓｔｅｄＴｙｐｅから派生することができる。

図７は、上述したスキーマの間のいくつかの例示的な関係を示す。他の関係を形成することもできるが、簡潔にするために図示していないことに留意されたい。図に示すように、ＷＩＮＦＳ Ｉｔｅｍタイプ７０５が、基本タイプでよい。Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔタイプ７１０、Ａｕｄｉｏ．ＲａｄｉｏＳｔａｔｉｏｎタイプ７１５、Ａｕｄｉｏ．ＲａｄｉｏＳｔｒｅａｍタイプ７２０、およびＶｉｄｅｏ．ＶｉｄｅｏＣｌｉｐタイプ７２５は、ＷＩＮＦＳ Ｉｔｅｍタイプ７０５から派生することができる。Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔタイプ７３０は、Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔタイプ７１０から派生することができる。

Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄタイプ７３５は、Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔタイプ７３０から派生することができる。Ａｕｄｉｏ．ＡｕｄｉｏＲｅｃｏｒｄタイプ７３５は、Ａｕｄｉｏ．ＣａｃｈｅｄＡｌｂｕｍタイプ７４０、Ａｕｄｉｏ．Ｔｒａｃｋタイプ７４５、Ａｕｄｉｏ．ＰｌａｔｔｅｒＴｒａｃｋタイプ７５０、およびＡｕｄｉｏ．ＣａｃｈｅｄＴｒａｃｋタイプ７５５を派生するのに使用することができる。概して、Ａｕｄｉｏ．Ｔｒａｃｋタイプ７４５は、リッピングされたオーディオファイル用のメタデータに対応し、Ａｕｄｉｏ．ＰｌａｔｔｅｒＴｒａｃｋタイプ７５０は、オーディオＣＤ上のトラックに対応し、Ａｕｄｉｏ．ＣａｃｈｅｄＴｒａｃｋタイプ７５５は、ダウンロードされたメタデータに対応する。Ａｕｄｉｏ．Ｔｒａｃｋタイプ７４５またはＡｕｄｉｏ．ＰｌａｔｔｅｒＴｒａｃｋタイプ７５０をＡｕｄｉｏ．ＣａｃｈｅｄＴｒａｃｋタイプ７５５のメタデータに関連づけるＳｕｇｇｅｓｔｅｄＭｅｔａｄａｔａ関係を確立することができる。

さらに、Ｈｉｓｔｏｒｙタイプ７６０およびＲａｔｉｎｇｓタイプ７６５は、Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔタイプ７３０から派生することができる。さらに、Ｖｉｄｅｏ．ＶｉｄｅｏＲｅｃｏｒｄタイプ７７０は、Ｍｅｄｉａ．Ｄｏｃｕｍｅｎｔタイプ７３０から派生することができ、Ｖｉｄｅｏ．ＲｅｃｏｒｄｅｄＴＶタイプ７７５は、Ｖｉｄｅｏ．ＶｉｄｅｏＲｅｃｏｒｄタイプ７７０から派生することができる。

図８を参照すると、本発明の様々な態様を実装する例示的な環境８１０は、コンピュータ８１２を含む。コンピュータ８１２は、処理ユニット８１４、システムメモリ８１６、およびシステムバス８１８を含む。システムバス８１８は、システムメモリ８１６を含むがそれに限定されないシステムコンポーネントを、処理ユニット８１４に結合する。処理ユニット８１４は、市販されている様々なプロセッサのいずれでもよい。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理ユニット８１４として利用することができる。

システムバス８１８は、市販されている様々などのバスアーキテクチャも用いるメモリバスもしくはメモリコントローラ、周辺バスもしくは外部バス、および／またはローカルバスを含むいくつかのタイプのバス構造（群）のどれでもよく、こうしたバス構造は、８ビットバス、ＩＳＡ（業界標準アーキテクチャ）、ＭＳＡ（マイクロチャネルアーキテクチャ）、ＥＩＳＡ（拡張ＩＳＡ）、ＩＤＥ（インテリジェントドライブエレクトロニクス）、ＶＬＢ（ＶＥＳＡローカルバス）、ＰＣＩ（周辺装置相互接続）、ＵＳＢ（ユニバーサルシリアルバス）、ＡＧＰ（拡張グラフィックスポート）、ＰＣＭＣＩＡ（ＰＣカードアダプタ）、およびＳＣＳＩ（小型コンピュータシステムインターフェース）を含むが、それに限定されない。

システムメモリ８１６は、揮発性メモリ８２０および不揮発性メモリ８２２を含む。たとえば起動中に、コンピュータ８１２内部の要素の間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）が、不揮発性メモリ８２２に格納される。限定ではなく例として、不揮発性メモリ８２２は、ＲＯＭ（読出し専用メモリ）、ＰＲＯＭ（プログラム可能ＲＯＭ）、ＥＰＲＯＭ（電気的プログラム可能ＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能ＲＯＭ）、またはフラッシュメモリを含み得る。揮発性メモリ８２０は、外部キャッシュメモリとして作用するＲＡＭ（ランダムアクセスメモリ）を含む。限定ではなく例として、ＲＡＭは、ＳＲＡＭ（同期ＲＡＭ）、ＤＲＡＭ（ダイナミックＲＡＭ）、ＳＤＲＡＭ（シンクロナスＤＲＡＭ）、ＤＤＲ ＳＤＲＡＭ（ダブルデータレート方式ＳＤＲＡＭ）、ＥＳＤＲＡＭ（拡張ＳＤＲＡＭ）、ＳＬＤＲＡＭ（シンクリンクＤＲＡＭ）、およびＤＲＲＡＭ（ダイレクトランバスＲＡＭ）など、多くの形で市販されている。

コンピュータ８１２は、取外し可能／固定式、揮発性／不揮発性コンピュータ記憶媒体も含む。図８は、たとえばディスク記憶装置８２４を示す。ディスク記憶装置８２４は、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスを含むが、それに限定されない。さらに、ディスク記憶装置８２４は、記憶媒体を、別個に含むことも、ＣＤ−ＲＯＭ（コンパクトディスクＲＯＭデバイス）、ＣＤ−Ｒドライブ（書込み可能ＣＤドライブ）、ＣＤ−ＲＷドライブ（書換え可能ＣＤドライブ）、またはＤＶＤ−ＲＯＭ（デジタルビデオディスクＲＯＭドライブ）などの光ディスクドライブを含むがそれに限定されない他の記憶媒体と組み合わせて含むこともできる。システムバス８１８へのディスク記憶装置８２４の接続を容易にするために、取外し可能または固定式インターフェースは通常、インターフェース８２６などとして使われる。

図８は、適切な動作環境８１０において述べる、ユーザと基本的なコンピュータリソースとの間の媒介として作用するソフトウェアを示すことを理解されたい。このようなソフトウェアは、オペレーティングシステム８２８を含む。オペレーティングシステム８２８は、ディスク記憶装置８２４に格納することができ、コンピュータシステム８１２のリソースを制御し割り振るように作用する。システムアプリケーション８３０は、システムメモリ８１６またはディスク記憶装置８２４のどちらかに格納された、プログラムモジュール８３２およびプログラムデータ８３４を介して、オペレーティングシステム８２８によるリソース管理を活用する。本発明は、様々なオペレーティングシステム、またはオペレーティングシステムの組合せを用いて実装できることを理解されたい。

ユーザは、入力デバイス（群）を介して、コマンドまたは情報をコンピュータ８１２に入力する。入力デバイス８３６は、ポインティングデバイス、たとえばマウス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含むが、それに限定されない。こうしたおよび他の入力デバイスは、インターフェースポート（群）８３８を介して、システムバス８１８によって処理ユニット８１４に接続される。インターフェースポート（群）８３８は、たとえば、シリアルポート、パラレルポート、ゲームポート、およびＵＳＢ（ユニバーサルシリアルバス）を含む。出力デバイス（群）８４０は、入力デバイス（群）８３６と同じタイプのポートの一部を使う。したがって、たとえば、ＵＳＢポートは、コンピュータ８１２への入力を可能にし、コンピュータ８１２から出力デバイス８４０に情報を出力するのに用いることができる。出力アダプタ８４２は、他の出力デバイス８４０の中でも、専用アダプタを必要とする、モニタ、スピーカ、およびプリンタのようないくつかの出力デバイス８４０があることを示すために図示してある。出力アダプタ８４２は、限定ではなく例として、出力デバイス８４０とシステムバス８１８の間の接続手段を提供するビデオカードおよびサウンドカードを含む。リモートコンピュータ（群）８４４など、他のデバイスおよび／またはデバイスからなるシステムは、入力および出力機能を提供することに留意されたい。

コンピュータ８１２は、１つまたは複数のリモートコンピュータ、たとえばリモートコンピュータ（群）８４４への論理接続を使用してネットワーク接続された環境において動作することができる。リモートコンピュータ（群）８４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の共通ネットワークノードなどでよく、通常、コンピュータ８１２に関連して説明した要素の多くまたはすべてを含む。簡潔にするために、メモリ記憶デバイス８４６のみをリモートコンピュータ（群）８４４とともに示してある。リモートコンピュータ（群）８４４は、ネットワークインターフェース８４８を介してコンピュータ８１２に論理的に接続され、さらに通信接続８５０を介して物理的に接続される。ネットワークインターフェース８４８は、ＬＡＮ（ローカルエリアネットワーク）およびＷＡＮ（ワイドエリアネットワーク）などの通信ネットワークを包含する。ＬＡＮ技術は、ＦＤＤＩ（光ファイバ分散データインターフェース）、ＣＤＤＩ（銅線配線データインターフェース）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５などを含む。ＷＡＮ技術は、二地点間リンク、ＩＳＤＮ（統合サービスデジタルネットワーク）のような回路交換ネットワークおよびその変形、パケット交換ネットワーク、ならびにＤＳＬ（デジタル加入者線）を含むが、それに限定されない。

通信接続（群）８５０は、ネットワークインターフェース８４８をバス８１８に接続するのに利用されるハードウェア／ソフトウェアを指す。通信接続８５０は、説明をわかりやすくするためにコンピュータ８１２内部に示されているが、コンピュータ８１２の外部にあってもよい。ネットワークインターフェース８４８への接続に必要なハードウェア／ソフトウェアは、単なる例として、標準的な電話レベルのモデム、ケーブルモデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードなど、内部および外部技術を含む。

上で説明した内容は、本発明のいくつかの例を含む。当然ながら、本発明を説明するためのコンポーネントまたは方法のあらゆる組合せを説明することはできないが、本発明のさらに多くの組合せおよび入替えが可能であることが当業者には理解されよう。したがって、本発明は、添付の特許請求の範囲の精神および範囲内であるこのようなすべての変更形態、修正形態および変形形態を包含することを意図している。さらに、本発明のある特定の特徴を、いくつかの実装形態のただ１つに関して開示したが、このような特徴は、所与のまたは特定のどのアプリケーションにとっても望ましく、有利であるように、他の実装形態の１つまたは複数の他の特徴と組み合わせることができる。さらに、詳細な説明または特許請求の範囲において「含む」という用語およびその変形が使われている限りでは、そうした用語は、「備える」という用語と同様に包括的であることを意図している。

特に、上述したコンポーネント、デバイス、回路、システムなどによって実施される様々な機能に関して、このようなコンポーネントを説明するのに用いた用語（「手段」への言及も含む）は、特に示さない限り、説明した（たとえば、機能的に等価な）コンポーネントの指定された機能を実施するとともに、開示した構造と構造的に等価でないとしても、本明細書において示した本発明の例示的な態様においてそうした機能を実施する、どのコンポーネントにも対応することを意図している。この点に関して、本発明は、システム、ならびに本発明の様々な方法の動作および／またはイベントを実施するコンピュータ実行可能命令を有するコンピュータ可読媒体を含むことも理解されよう。

本発明の態様による例示的なファイル管理システムを示す図である。 本発明の態様による、例示的なスキーマベースのファイルシステムを示す図である。 本発明の態様による例示的なデータ管理システムを示す図である。 本発明の態様による、情報を系統的に格納し情報にアクセスする例示的なシステムを示す図である。 本発明の態様による、データベース中のファイルの管理に関連してスキーマを利用する例示的な方法を示す図である。 本発明の態様による、データベースとのユーザ対話を円滑にする例示的な方法を示す図である。 本発明の態様による、スキーマの間の例示的な関連づけを示す図である。 本発明の新規な態様を利用することができる、例示的な環境を示す図である。

Claims (50)

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. オーディオおよびビデオファイルを体系化する方法であって、
    オーディオまたはビデオファイルを受け取ることと、
    ファイルのタイプを判定することと、
    前記識別されたタイプに関連づけられたスキーマを入手することと、
    前記スキーマに基づいて、前記ファイルをファイルシステムに格納することと
    を備えることを特徴とする方法。
32. 格納されたファイルに対する要求を受け取ることと、前記スキーマを使用して、前記ファイルを特定し、返すこととをさらに備えることを特徴とする請求項３１に記載の方法。
33. 豊富なマルチメディアスキーマに基づくシステムであって、
    スキーマセットと、
    前記スキーマセットを使用して、データベース内の異質なオーディオおよびビデオデータを管理するコンポーネントと
    を備えることを特徴とするシステム。
34. 前記スキーマセットは、ＥｆｆｅｃｔｉｖｅＢａｃｋＣｏｖｅｒＡｒｔ、ＥｆｆｅｃｔｉｖｅＦｒｏｎｔＣｏｖｅｒＡｒｔ、ＭｅｔａｄａｔａＰｒｏｖｉｄｅｒＬｏｇｏ、Ｄｏｃｕｍｅｎｔ、ＭｅｔａｄａｔａＬｉｆｅｃｙｃｌｅ、ＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒ、ＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒＤａｔａ、Ｈｉｓｔｏｒｙ、Ｒａｔｉｎｇ、ＣｕｓｔｏｍＲａｔｉｎｇ、ＳｔａｒＲａｔｉｎｇ、ＵＲＬＲｅｆｅｒｅｎｃｅ、ＭＶＳｔｒｉｎｇ１２８、およびＭＶＳｔｒｉｎｇ２５６というタイプの１つまたは複数を備えるメディアスキーマを備えたことを特徴とする請求項３３に記載のシステム。
35. 前記Ｄｏｃｕｍｅｎｔタイプは、アイテムタイプであることを特徴とする請求項３４に記載のシステム。
36. 前記ＭｅｔａｄａｔａＬｉｆｅｃｙｃｌｅタイプは、拡張タイプであることを特徴とする請求項３４に記載のシステム。
37. 前記ＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒ、ＥｆｆｅｃｔｉｖｅＢａｃｋＣｏｖｅｒＡｒｔ、ＥｆｆｅｃｔｉｖｅＦｒｏｎｔＣｏｖｅｒＡｒｔ、およびＭｅｔａｄａｔａＰｒｏｖｉｄｅｒＬｏｇｏタイプは、関係タイプであることを特徴とする請求項３４に記載のシステム。
38. 前記ＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒＤａｔａ、Ｈｉｓｔｏｒｙ、Ｒａｔｉｎｇ、ＣｕｓｔｏｍＲａｔｉｎｇ、ＳｔａｒＲａｔｉｎｇ、ＵＲＬＲｅｆｅｒｅｎｃｅ、ＭＶＳｔｒｉｎｇ１２８、およびＭＶＳｔｒｉｎｇ２５６タイプは、ネストしたタイプであることを特徴とする請求項３４に記載のシステム。
39. 前記スキーマセットは、Ｃｌｉｐｓ、ＶｉｄｅｏＲｅｃｏｒｄ、ＲｅｃｏｒｄｅｄＴＶ、ＶｉｄｅｏＣｌｉｐ、およびＶｉｄｅｏＳｕｂＳｈｏｔというタイプの１つまたは複数を備えるビデオスキーマを備えたことを特徴とする請求項３３に記載のシステム。
40. 前記ＶｉｄｅｏＲｅｃｏｒｄ、ＲｅｃｏｒｄｅｄＴＶ、およびＶｉｄｅｏＣｌｉｐタイプは、アイテムタイプであることを特徴とする請求項３９に記載のシステム。
41. 前記Ｃｌｉｐｓタイプは、関係タイプであることを特徴とする請求項３９に記載のシステム。
42. 前記ＶｉｄｅｏＳｕｂＳｈｏｔタイプは、ネストしたタイプであることを特徴とする請求項３９に記載のシステム。
43. 前記スキーマセットは、ＲａｄｉｏＳｔａｔｉｏｎＬｏｇｏ、ＲａｄｉｏＳｔａｔｉｏｎＳｔｒｅａｍｓ、Ｌｉｓｔｅｎｅｒｓ、ＬｉｓｔｅｎｅｄＴｒａｃｋ、ＣａｃｈｅｄＡｌｂｕｍ、ＡｕｄｉｏＲｅｃｏｒｄ、Ｔｒａｃｋ、ＣａｃｈｅｄＴｒａｃｋ、ＰｌａｔｔｅｒＴｒａｃｋ、ＰｌａｙＬｉｓｔ、ＲａｄｉｏＳｔａｔｉｏｎ、ＲａｄｉｏＳｔｒｅａｍ、ＬｉｓｔｅｎｉｎｇＨａｂｉｔｓ、Ｌｉｓｔｅｎｉｎｇｈａｂｉｔｓｌｏｇ、ＡｒｔｉｓｔＩｎｆｏｒｍａｔｉｏｎ、ＴｒａｃｋＡｌｂｕｍ、ＳｕｇｇｅｓｔｅｄＭｅｔａｄａｔａ、ＲａｄｉｏＳｔａｔｉｏｎＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒ、ＲａｄｉｏＳｔａｔｉｏｎＬｏｃａｔｉｏｎ、ＡｕｔｏＤＪ、およびＰｌａｙＣｏｕｎｔｅｒというタイプの１つまたは複数を備えるオーディオスキーマを備えたことを特徴とする請求項３３に記載のシステム。
44. 前記ＣａｃｈｅｄＡｌｂｕｍ、ＡｕｄｉｏＲｅｃｏｒｄ、Ｔｒａｃｋ、ＣａｃｈｅｄＴｒａｃｋ、ＰｌａｔｔｅｒＴｒａｃｋ、ＰｌａｙＬｉｓｔ、ＲａｄｉｏＳｔａｔｉｏｎ、ＲａｄｉｏＳｔｒｅａｍ、ＬｉｓｔｅｎｉｎｇＨａｂｉｔｓ、およびＬｉｓｔｅｎｉｎｇｈａｂｉｔｓｌｏｇタイプは、アイテムタイプであることを特徴とする請求項４３に記載のシステム。
45. 前記ＡｒｔｉｓｔＩｎｆｏｒｍａｔｉｏｎタイプは、拡張タイプであることを特徴とする請求項４３に記載のシステム。
46. 前記ＴｒａｃｋＡｌｂｕｍ、ＳｕｇｇｅｓｔｅｄＭｅｔａｄａｔａ、ＲａｄｉｏＳｔａｔｉｏｎＣｏｎｔｅｎｔＤｉｓｔｒｉｂｕｔｏｒ、ＲａｄｉｏＳｔａｔｉｏｎＬｏｃａｔｉｏｎ、ＲａｄｉｏＳｔａｔｉｏｎＬｏｇｏ、ＲａｄｉｏＳｔａｔｉｏｎＳｔｒｅａｍｓ、Ｌｉｓｔｅｎｅｒｓ、およびＬｉｓｔｅｎｅｄＴｒａｃｋタイプは、関係タイプであることを特徴とする請求項４３に記載のシステム。
47. 前記ＡｕｔｏＤＪおよびＰｌａｙＣｏｕｎｔｅｒタイプは、ネストしたタイプであることを特徴とする請求項４３に記載のシステム。
48. ファイルシステム内での異質なオーディオおよびビデオデータの管理を円滑にする、２つ以上のコンピュータコンポーネントの間を伝送されるデータパケットであって、
    オーディオまたはビデオデータを受け取るコンポーネントと、前記受け取ったデータに関連づけられたスキーマを入手するコンポーネントと、前記スキーマを使用して、前記データを系統的に格納するコンポーネントと、前記スキーマを使用して、前記格納されたデータを管理するコンポーネントとを備えたことを特徴とするデータパケット。
49. ファイル管理システムのコンピュータ実行可能コンポーネントを格納するコンピュータ可読媒体であって、
    豊富なオーディオおよびビデオベースのスキーマセットを格納するスキーマバンクと、
    インターフェースと、
    前記インターフェースを介してオーディオおよびビデオデータの少なくとも１つを受け取り、前記スキーマバンクから関連するスキーマを入手して、前記受け取ったデータを管理するコンポーネントと
    を備えたことを特徴とするコンピュータ可読媒体。
50. オーディオ／ビデオスキーマに基づいて、オーディオおよびビデオファイルを格納し、取得するオーディオ／ビデオ管理システムであって、
    オーディオおよびビデオファイルを受け入れる手段と、
    前記オーディオおよびビデオファイルに関連するスキーマを入手する手段と、
    前記スキーマを使用して、データベース内の前記オーディオおよびビデオファイルを管理する手段と
    を備えたことを特徴とするシステム。
    

Images