(57)【要約】  ソースからシンクへコンテンツを提供するための保護されたメディアパスにおいて、ソースの代わりにソース信頼権限（ＳＯＴＡ）が、コンテンツに対応するポリシーに対して、コンテンツでの特定タイプのアクションが拒絶されることを判定し、アプリケーションに特定のイネーブラを提供する。提供されたイネーブラは、拒絶に応答するために必要なデータを取得するために、アプリケーションに必要な情報と方法を含んでいる。アプリケーションは、そのインターフェースでイネーブラを受信し、インターフェースは共通の相互処理手法を適用して、拒絶に応答するために必要なデータをイネーブラに取得させる。
2007509419.tif 000002
【特許請求の範囲】
【請求項１】
演算装置を通してソースからシンクにコンテンツを供給する方法であって、この方法が：
演算装置上のメディアベースに対して、コンテンツ、ソース、シンクの定義を呼び出す演算装置上のアプリケーションと；
定義されたコンテンツ、ソース、シンクに基づいて、そのような供給を行う保護されたメディアパスを確立するメディアベースであって、確立された保護されたメディアパスが：
メディアベースと；
ソースに関連付けられ、それに対応するソース信頼権限（ＳＯＴＡ）であって、各ＳＯＴＡが、ソースとメディアベースをつなぐセキュアロックボックスとして機能し、保護されたメディアパスにおけるソースを代行するソース信頼権限と；
シンクに関連付けられ、それに対応するシンク信頼権限（ＳＩＴＡ）であって、ＳＩＴＡが、シンクとメディアベースをつなぐセキュアロックボックスとして機能し、保護されたメディアパスにおけるシンクを代行するシンク信頼権限とを含むメディアベースと；
保護されたメディアパスに関連して信頼を確立するソースに代わるＳＯＴＡと；
コンテンツに対応するポリシーを保護されたメディアパスに供給するよう伝播する保護されたメディアパスに関して信頼を確立するＳＯＴＡと；
保護されたメディアパスを通して供給されるコンテンツに対して実行される特定タイプのアクションを決定するＳＯＴＡと；
伝播されたポリシーに対して、保護されたメディアパスを介して提供されたコンテンツで特定タイプのアクションが実施できないことを決定して、メディアベースにアクションの実施に対する拒絶を通知するＳＯＴＡと；、
アプリケーションアクションの実施に対する拒絶を通知するメディアベースと；
当該ＳＯＴＡが利用可能な特定のイネーブラによって拒絶が取り除かれる場合があることを認識し、ＳＯＴＡはメディアベースにより特定のイネーブラをアプリケーションに提供し、提供されたイネーブラは、拒絶に応答するために必要なデータを取得するために、アプリケーションに必要な情報と方法を含むＳＯＴＡと；
メディアベースによりそのインターフェースでイネーブラを受信し、インターフェースは共通の相互処理手法を適用して、イネーブラを実行して、拒絶に応答するために必要なデータを取得するアプリケーションと；
取得したデータをメディアベースに提供し、メディアベースは提供されたデータを利用して、拒絶に応答するアプリケーションと；
伝播されたポリシーに対し、また少なくとも部分的に応答された拒絶に基づいて、保護されたメディアパスを介して提供されたコンテンツで特定タイプのアクションが実施できることを決定して、メディアベースにその旨通知するＳＯＴＡと；
特定タイプのアクションが実施できることをアプリケーションに通知して、メディアベースにこのようなタイプのアクションを実施するよう命令することによって、アプリケーションが継続されるメディアベースとを備えることを特徴とする方法。
【請求項２】
特定のイネーブラを基準としてアプリケーションを提供するメディアベースによって、特定のイネーブラをアプリケーションに提供するＳＯＴＡから成ることを特徴とする請求項１に記載の方法。
【請求項３】
アプリケーションのユーザから必要なデータを取得しようとするイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項４】
アプリケーションの演算装置とアプリケーションの演算装置に連結された他の演算装置の一つから必要なデータを取得しようとするイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項５】
コンテンツに対応した適切なライセンスが不十分なためにアクションの実行を拒絶するＳＯＴＡと、適切なライセンスを取得するためにイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項６】
保護されたメディアパスのエレメントの現状のバージョンが不十分なためにアクションの実行を拒絶するＳＯＴＡと、エレメントの現状のバージョンを取得しインストールするためにイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項７】
コンテンツに対してＳＩＴＡが許容されていないアクションを実施できるように設定されているためにアクションの実施を拒絶するＳＯＴＡと、許容されていないアクションを実施できないようにＳＩＴＡを設定するためにイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項８】
ＳＯＴＡ、アプリケーション、メディアベースとアプリケーションのユーザの少なくとも一つに、定期的に進行状況の通知を提供するアプリケーションのインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項９】
特定の拒絶に応答するために、各々の複数のイネーブラ間からアプリケーションに特定のイネーブラを提供するＳＯＴＡと、共通の相互処理手法を適用して、共通の相互処理手法が複数のイネーブラのうちのいずれかを実行可能な場合に、特定のイネーブラを実行するインターフェースから成ることを特徴とする請求項１に記載の方法。
【請求項１０】
演算装置によってソースからシンクへコンテンツを提供する方法であって、演算装置のメディアベースに対して、演算装置上のアプリケーションがコンテンツ、ソースとシンクを定義し、メディアベースは定義されたコンテンツ、ソースとシンクに基づいて保護されたメディアパスを確立して、当該提供を実行し、確立された保護メディアパスはメディアベース、ソースに関連し対応するソース信頼権限（ＳＯＴＡ）を含み、ＳＯＴＡはソースをメディアベースに接続し、保護されたメディアパス内においてソースを表示するセキュアロックボックスとして作動し、さらに保護されたメディアパスはシンクに関連し対応するシンク信頼権限（ＳＩＴＡ）を含み、ＳＩＴＡはシンクをメディアベースに接続し、保護されたメディアパス内にシンクを表示するセキュアロックボックスとして作動する場合の方法において、
ＳＯＴＡは、
保護されたメディアパスに対してトラストを確立し、メディアパスに対してトラストが確立されると、保護されたメディアパスに提供されるコンテンツに対応したポリシーを伝播し、
保護されたメディアパスを介して提供されるコンテンツで実施される特定タイプのアクションを決定し、
伝播されたポリシーに対して、保護されたメディアパスを介して提供されるコンテンツで特定タイプのアクションが実施できないことを決定し、メディアベースがアプリケーションにアクションの実施に対する拒絶を通知する場合に、メディアベースにアクションの実施に対する拒絶を通知して、
当該ＳＯＴＡが利用可能な特定のイネーブラによって拒絶が取り除かれる場合があることを認識し、メディアベースによって特定イネーブラをアプリケーションへ提供し、提供されたイネーブラは拒絶に応答するために必要なデータを取得するために、アプリケーションに必要な情報と方法を含み、ここで、アプリケーションはメディアベースによりそのインターフェースでイネーブラを受信し、インターフェースは共通の相互処理方法を適用して、イネーブラを実行して拒絶に応答するために必要なデータを取得し、さらに、アプリケーションは取得したデータをメディアベースに提供し、メディアベースは拒絶に応答するために提供されたデータを利用し、
伝播されたポリシーに対し、また少なくとも部分的に応答された拒絶に基づいて、保護されたメディアパスを介して提供されるコンテンツで特定タイプのアクションが行えることを決定しその旨メディアベースに通知し、ここで、メディアベースはアプリケーションに特定タイプのアクションが行えることを通知し、メディアベースに命令することによってアプリケーションはこのようなタイプのアクションの実施を進めることを特徴とする方法。
【請求項１１】
特定のイネーブラを基準とするアプリケーションを提供するメディアベースによって、特定のイネーブラをアプリケーションへ提供するＳＯＴＡから成ることを特徴とする請求項１０に記載の方法。
【請求項１２】
コンテンツに対応する適切なライセンスが不十分なために、アクションの実施を拒絶するＳＯＴＡと適切なライセンスを取得するためにイネーブラを実行するインターフェースから成ることを特徴とする請求項１０に記載の方法。
【請求項１３】
保護されたメディアパスのエレメントの現状のバージョンが不十分なために、アクションの実施を拒絶するＳＯＴＡと、エレメントの現状のバージョンを取得しインストールためにイネーブラを実行するインターフェースとから成ることを特徴とする請求項１０に記載の方法。
【請求項１４】
コンテンツに対して許容できないアクションを実施することができるようにＳＩＴＡが設定されているために、アクションの実施を拒絶するＳＯＴＡと、許容できないアクションを実施することができないようにＳＩＴＡを設定するイネーブラを実行するインターフェースとから成ることを特徴とする請求項１０に記載の方法。
【請求項１５】
アプリケーションのインターフェースから定期的に進行状況の通知を受信するＳＯＴＡから成ることを特徴とする請求項１０に記載の方法。
【請求項１６】
インターフェースは共通の相互処理手法を適用して、共通の相互処理手順が複数のイネーブラのうちのいずれかを実行可能となるように特定のイネーブラを実行する場合に、特定の拒絶に応答するために、各々の複数のイネーブラからアプリケーションに特定のイネーブラを提供するＳＯＴＡから成ることを特徴とする請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２００３年１０月２３日に米国申請連続番号６０／５１３，８３１の利益を請求する２００４年４月８日に申請された米国申請連続番号１０／８２０，６６６に対する優先権を請求するものであり、その開示内容はここでは全て参照によって組み込まれている。
【０００２】
本発明は、さまざまなソースのあるソースからさまざまなシンクのあるシンクに共通ベースにより信頼しうる様式でコンテンツを供給するための保護されたメディアパスを構築するための構成および方法に関する。特に、本発明は、パスが信頼しうるものとして構築されるとともにそのコンテンツに対応するポリシーを満たすようになった場合のみコンテンツが供給されるような構成および方法に関する。
【背景技術】
【０００３】
知られているとおり、さらに、ここで図１に示すとおり、権利管理（ＲＭ）実施システムは、デジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディア等のデジタルコンテンツ１２のユーザに配布されるデジタルコンテンツ１２との接続において大いに望まれているものである。ユーザにより受信される際、ユーザは、パソコン１４上のメディアプレーヤ、携帯式再生装置等の適当なレンダリング装置の助けを借りてそのデジタルコンテンツのレンダリング、すなわち「プレイ」を行う。
【０００４】
典型的には、このようなデジタルコンテンツ１２の配布を行うコンテンツ所有者は、そのようにして配布されたデジタルコンテンツ１２を用いてユーザが実施することに対して制限を加えることを望む。例えば、コンテンツ所有者は、ユーザがそのコンテンツ１２を第２ユーザに対してコピーしたり再配布したりすることに制限を加えることを望む、あるいは、制限された回数だけ、ある合計時間だけ、あるタイプの機械だけ、あるタイプのメディアプレーヤだけ、あるタイプのユーザだけに、配布されたデジタルコンテンツ１２のプレイができるようにすることを望む。
【０００５】
しかし、配布が行われた後、そのコンテンツ所有者がデジタルコンテンツ１２に対して管理を行うことができるとしても、それはごくわずかである。そのため、ＲＭシステム１０を用いれば、デジタルコンテンツ１２を任意の形態で制御したレンダリングあるいはプレイが可能になるが、このような制御は柔軟性をもったものであり、そのデジタルコンテンツのコンテンツ所有者が定義可能である。典型的には、コンテンツ１２は、適当な配布チャネルを通してパッケージ１３の形態でユーザに配布される。配布された状態のデジタルコンテンツパッケージ１３には、共通暗号／復号鍵（ＫＤ）（すなわち、（ＫＤ（コンテンツ）））を用いて暗号化されたデジタルコンテンツ１２、ならびにコンテンツを特定する他の情報、そのコンテンツに対するライセンスを得るための方法等が含まれる。
【０００６】
信頼ベースのＲＭシステム７０により、デジタルコンテンツ１２のレンダリングが可能になる前に従うべき規則をデジタルコンテンツ１２の所有者が特定できるようになる。こういった規則には前述の要求事項および／またはその他の事項を含めることができ、ユーザ／ユーザの演算装置１４（これ以降、これらの用語は状況によってそうでない場合を除き、同じ意味で用いられるものとする）がコンテンツ所有者あるいはその代理人から取得しなければならないデジタルライセンス１６内で具現化される、あるいはそのような規則を事前にコンテンツ１２に付属させる。そのようなライセンス１６は、例えば、デジタルコンテンツ１２の復号を行うための復号鍵（ＫＤ）を含むが、このコンテンツはユーザの演算装置あるいは他の再生可能装置で復号可能な他の鍵によって暗号化されたものである。
【０００７】
デジタルコンテンツ１２の一部に対するコンテンツ所有者は、ライセンス１６あるいはその他においてコンテンツ所有者により特定された規則にユーザが従うという点に対して所有者が信頼をおくことができなければ、そのコンテンツ１２をユーザに配布することを望まない。その場合、好ましくは、ユーザの演算装置１４あるいは他の再生装置が、その規則を守らなければそのデジタルコンテンツ１２をレンダリングしないような信頼されるコンポーネントあるいは機構１８を備える。
【０００８】
信頼されるコンポーネント１８は、典型的には、規則のレビューを行い、要求しているユーザが、何よりも、求められた様式で要求されたデジタルコンテンツ１２をレンダリングする権利をもつかどうかについて、レビューされた規則に基づいて判定するエバリュエータ２０をもつ。理解されるとおり、エバリュエータ２０は、規則に従ってデジタルコンテンツ１２の所有者の意思を実行するためのＤＲＭシステム１０に信頼されており、ユーザは、悪意をもった、あるいは他のいかなる目的においてもそのような信頼されるコンポーネント１８および／またはエバリュエータ２０を簡単に変更できるようであってはならない。
【０００９】
理解されるとおり、コンテンツ１２をレンダリングするための規則により、ユーザが誰か、どこにユーザがいるか、どのタイプの演算装置１４あるいは他の再生装置をユーザが使っているか、どのレンダリングアプリケーションがＲＭシステム１０を呼び出しているか、日付、時間等を含むさまざまな因子のいずれかに基づいてユーザがレンダリングする権利をもっているかどうかを特定できる。さらに、この規則により、例えば、所定数のプレイ、所定プレイ時間にレンダリングを制限する。
【００１０】
この規則は、ある適当な言語やシンタクスにより特定される。例えばこの言語は、単純に、満足させるべき属性や値（例えば、ＤＡＴＥがＸよりも後でなければならない）を特定する、あるいは特定のスクリプト（例えば、ＤＡＴＥがＸよりも大きければ．．．を行う）に従う機能の実施を要求する。
【００１１】
ユーザが規則を守っているとエバリュエータ２０が判定すれば、デジタルコンテンツ１２をレンダリングさせることができる。特に、コンテンツをレンダリングするため、復号鍵（ＫＤ）を所定のソースから得て、この復号鍵がコンテンツパッケージ１３から（ＫＤ（ＣＯＮＴＥＮＴ））に、さらに真のコンテンツ１２に適用され、この真のコンテンツ１２が実際にレンダリングされる。
【００１２】
ＲＭシステム１０において、コンテンツ１２は、そのコンテンツ１２を暗号化し、１組の規則とこのコンテンツ１２とを関連付けることでユーザが利用するようパッケージされ、これによりコンテンツ１２は、規則のみに従ってレンダリングできる。コンテンツ１２は規則に従ってレンダリングできるだけであるため、このコンテンツは自由に配布される。しかし、さまざまなコンテンツ１２は複数のＲＭシステム１０により保護されるが、各システムは他の各ＲＭシステム１０とは必ずしも互換性がないということを認識すべきである。
【００１３】
したがって、複数目的点のいずれかに配送される複数システム１０のいずれかからのコンテンツ１２に対する保護されたメディアパスを定義する構成および方法に対する必要性がある。特に、コンテンツ１２に対応する信頼しうる、規則を守るポリシーとしてどのようにしてパスが構築されるかを定義するような構成に関連する方法に対して必要性がある。
【発明の開示】
【課題を解決するための手段】
【００１４】
演算装置によりコンテンツをソースからシンクへ提供するための方法が提供される本発明によって、少なくとも部分的に上記で説明した必要性が充足される。演算装置上のアプリケーションは、コンテンツ、ソース、シンクの定義とともに演算装置に基づいてメディアベースを呼び出し、メディアベースは、定義されたコンテンツ、ソースとシンクに基づいて、保護されたメディアパスを確立して、上記の提供を実行する。確立された保護メディアパスは、メディアベース、ソースに関連し対応し、またソースをメディアベースに接続し、保護されたメディアパス内でソースを表示するセキュアロックボックスとして作動するソース信頼権限（ＳＯＴＡ）と、シンクに関連し対応し、またシンクをメディアベースに接続し、保護されたメディアパス内でシンクを表示するセキュアロックボックスとして作動するシンク信頼権限（ＳIＴＡ）を含んでいる。
【００１５】
ソースの代わりのＳＯＴＡは、保護されたメディアパスに対してトラストを確立し、保護されたメディアパスに対してトラストが確立されると、保護されたメディアパスへ提供されるコンテンツに対応したポリシーを伝播する。ＳＯＴＡは、保護されたメディアパスを介して提供されるコンテンツで実施される特定タイプのアクションを決定し、伝播されたポリシーに関して、保護されたメディアパスを介して提供されるコンテンツで実施できない特定タイプのアクションを決定して、拒絶をメディアベースに通知して、当該アクションを行う。一方、メディアベースは拒絶をアプリケーションに通知して、アクションを行う。
【００１６】
ＳＯＴＡは、ＳＯＴＡが利用可能な特定のイネーブラによって拒絶が取り除かれる場合があることを認識すると、ＳＯＴＡはメディアベースにより特定のイネーブラをアプリケーションへ提供する。提供されたイネーブラは、拒絶に応答するために必要なデータを取得するために、アプリケーションに必要な情報と方法を含んでいる。アプリケーションは、メディアベースにより、そのインターフェースでイネーブラを受信し、インターフェースは共通の相互処理手法を適用して、拒絶に応答するために必要なデータをイネーブラに取得させる。この後で、アプリケーションは提供されたデータをメディアベースに適用し、メディアベースは拒絶に応答するために提供されたデータを利用する。
【００１７】
ここで、伝播されたポリシーに関して、また少なくとも部分的には応答された拒絶に基づいて、ＳＯＴＡは保護されたメディアパスを介して提供されたコンテンツで特定タイプのアクションが実施されることを判定して、その旨メディアベースに通知し、メディアベースは、特定タイプのアクションが実施できることをアプリケーションに通知する。メディアベースに命令することによって、アプリケーションはこの特定タイプのアクションの実施を進める。
【発明を実施するための最良の形態】
【００１８】
コンピュータ環境
図１および以下の考察は、本発明および／またはその一部を実施するのに適した計算環境の短い一般的説明を示すことを意図したものである。要求されたものではないが、本発明は、クライアントワークステーションあるいはサーバといったコンピュータで実行されるプログラムモジュールといったコンピュータ実行可能命令の一般的なコンテクストで説明される。一般に、プログラムモジュールは、特定のタスクを行う、あるいは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに、本発明およびその一部を、手持型装置、マルチプロセッサシステム、マイクロプロセッサベースあるいはプログラム可能家電、ネットワークＰＣ、マイクロコンピュータ、メインフレームコンピュータ等を含む他のコンピュータシステム構成を用いて実施してもよい。本発明を、通信ネットワークを通してリンクされた遠隔処理装置でタスクが実施される分散型計算環境で実施してもよい。分散型計算環境において、プログラムモジュールを、局部あるいは遠隔メモリ記憶装置の両方においてもよい。
【００１９】
図２に示すとおり、典型的な汎用計算システムには、処理ユニット１２１と、システムメモリ１２２と、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２１に結合するシステムバス１２３とを含む従来型パソコン１２０等がある。システムバス１２３は、メモリバスあるいはメモリ制御装置、周辺バス、さまざまなバス構成のいずれかを用いるローカルバスを含む複数タイプのバス構造のいずれかである。システムメモリにはリードオンリーメモリ（ＲＯＭ）１２４やランダムアクセスメモリ（ＲＡＭ）１２５がある。起動中といった、パソコン１２０内の要素間で情報を伝送する際に助けとなる基本ルーチンを含む基本入出力システム１２６（ＢIＯＳ）がＲＯＭ１２４に記憶される。
【００２０】
パソコン１２０はさらに、（図示されていない）ハードディスクからの読み込みやそこへの書き込みを行うためのハードディスクドライブ１２７、取外し可能磁気ディスク１２９からの読み込みあるいはそこへの書き込みを行うための磁気ディスクドライブ１２８、ＣＤ−ＲＯＭあるいは他の光媒体といった取外し可能光ディスク１３１からの読み込みあるいはそこへの書き込みを行うための光ディスクドライブ１３０が含まれる。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、光ディスクドライブ１３０は、ハードディスクドライブインターフェース１３２、磁気ディスクドライブインターフェース１３３、光ドライブインターフェース１３４でそれぞれシステムバス１２３に接続される。ドライブと、関連するコンピュータ読み込み可能媒体により、パソコン２０に対するコンピュータ読み込み可能指示、データ構造、プログラムモジュール、他のデータの非揮発性保存が行われる。
【００２１】
ここで説明された典型的環境ではハードディスク、取外し可能磁気ディスク１２９、取外し可能光ディスク１３１を用いているものの、コンピュータでアクセス可能なデータを保存することのできる他のタイプのコンピュータ読み込み可能媒体は典型的作動環境でも用いることができることを認識すべきである。このような他のタイプの媒体には、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）等が含まれる。
【００２２】
オペレーティングシステム１３５、１つ以上のアプリケーションプログラム１３６、他のプログラムモジュール１３７、プログラムデータ１３８を含む多数のプログラムモジュールが、ハードディスク、磁気ディスク１２９、光ディスク１３１、ＲＯＭ１２４あるいはＲＡＭ１２５で保存される。ユーザは、キーボード１４０やポインティング装置１４２といった入力装置を通して命令や情報をパソコン１２０に入力する。（図示されていない）他の入力装置には、マイク、ジョイスティック、ゲームパッド、衛星ディスク、スキャナ等が含まれる。これらの入力装置および他の入力装置が、システムバスに結合されたシリアルポートインターフェース１４６を通して処理ユニット１２１に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）といった他のインターフェースで接続されることもある。モニタ１４７あるいは他のタイプの表示装置は、ビデオアダプタ１４８といったインターフェース経由でシステムバス１２３にも接続される。モニタ１４７に加えて、パソコンは、典型的には、スピーカやプリンタといった（図示されていない）他の周辺出力装置を含む。図２の典型的なシステムには、ホストアダプタ１５５、小型コンピュータシステムインターフェース（ＳＣＳI）バス１５６、ＳＣＳIバス１５６に接続された外部記憶装置１６２も含まれる。
【００２３】
パソコン１２０は、遠隔コンピュータ１４９といった１つ以上の遠隔コンピュータへの論理接続を用いるネットワーク環境で作動する。遠隔コンピュータ１４９は、他のパソコン、サーバ、ルータ、ネットワークＰＣ、ピア装置、あるいは他の共通ネットワークノードであり、典型的には、パソコン１２０に関して上述の要素の多く、あるいはその全てを含むものであるが、図２ではメモリ記憶装置１５０だけが示されている。図２に示される論理接続にはローカルエリアネットワーク（ＬＡＮ）１５１やワイドエリアネットワーク（ＷＡＮ）１５２が含まれる。このようなネットワーク環境は、事務所、全社的コンピュータネットワーク、イントラネット、インターネットでは普通のものである。
【００２４】
ＬＡＮネットワーク環境で用いられる場合、パソコン１２０はネットワークインターフェースあるいはアダプタ１５３経由でＬＡＮ１５１に接続される。ＷＡＮネットワーク環境で用いられる場合、パソコン１２０は、典型的には、モデム１５４、あるいはインターネットといったワイドエリアネットワーク１５２上での通信を確立するための他の手段を含む。モデム１５４は内部あるいは外部に置かれるものであるが、シリアルポートインターフェース１４６経由でシステムバス１２３に接続される。ネットワーク環境において、パソコン１２０に関連して示されるプログラムモジュール、あるいはその一部が遠隔メモリ保存装置内に保存される。ここで示されたネットワーク接続は代表的なものであり、コンピュータ間で通信リンクを確立するために他の手段が使われるということが認められる。
【００２５】
保護されたメディアパス
コンテンツ保護とは、コンテンツの所有者および／または供給者の意思に反する様式でコンテンツ１２を利用できないようデジタルコンテンツ１２を保護するための方法や技術の範囲を示す。方法としては、特に、コピー保護（ＣＰ）、リンク保護（ＬＰ）、条件付きアクセス（ＣＡ）、権利管理（ＲＭ）、デジタル権利管理（ＤＲＭ）がある。コンテンツ保護システムの基本は、保護されたコンテンツ１２の利用のための黙示的および／または明示的規則に対してそれが適切に一致することを保証する、信頼されるアプリケーションだけが非保護形態でコンテンツにアクセスできるということである。典型的には、コンテンツ１２がある方法で暗号化されることで保護されるが、この場合、信頼される者だけがこのコンテンツを復号できる。
【００２６】
コピー保護は、厳密な意味では特に記憶装置に常駐するコンテンツ１２に適用されるものであるのに対して、リンク保護は、送信媒体上のアプリケーション／装置間を流れるコンテンツ１２に対して適用される条件付きアクセスはリンク保護のさらに精巧な形態と考えることができるが、この場合、プレミアムプログラム、チャネルおよび／または映画が移送中に暗号化される。そのようなコンテンツ１２へのアクセスについては、料金を支払った加入者だけにこのコンテンツの復号で必要な鍵が与えられる。
【００２７】
デジタル権利管理は拡張可能な構造をもち、ここでコンテンツ１２の特定部分の認定使用に関する規則は明示的であり、この規則がコンテンツ１２そのものに拘束される、あるいは関連付けされる。ＤＲＭ機構は他の方法よりも内容豊富で表現豊かな規則をサポートでき、コンテンツの個々の部分のレベル、あるいはそのコンテンツの副コンテンツに対しても優れた制御や柔軟性が与えられる。デジタル権利管理システムの例は、１９９９年４月１２日に申請された米国特許出願番号０９／２９０，３６３および１９９９年３月２７日に申請された米国仮特許出願番号６０／１２６，６１４で示されているが、これらの各例はここでは全て参照によって組み込まれている。
【００２８】
権利管理は、組織内あるいはその部分集合の中だけでアクセス可能になるようコンテンツ１２が保護できるということに組織的に基づいたＤＲＭ形態である。権利管理システムの例は、それぞれ２００２年６月２８日に申請された米国特許出願番号１０／１８５，５２７および１０／１８５，２７８、１０／１８５，５１１で示されているが、ここでは全て参照によって組み込まれている。
【００２９】
本発明において、上で示されたシステムを含む複数のコンテンツ管理システムのいずれかからのコンテンツ処理および供給を可能にするよう、保護されたメディアパス構造が演算装置１４上で定められる。特に、このような構造により、ソース３０から目標点あるいは「シンク」３２から保護されたコンテンツ１２を供給するための機構がもたらされ、その一方、保護されたコンテンツ１２を必要に応じて処理する。ソース３０はコンテンツ１２の供給あるいは「ソース」を行うシステムであるが、本発明の真の趣旨および範囲から逸脱することのない適切なシステムであって、当然ながら、ソース３０が構成との間で相互作用すると仮定される。例えば、ソース３０は、ＤＲＭあるいはＲＭシステムといった複数の高機能の、あるいは最小限の機能性をもった権利管理システム、あるいはＣＰ、ＬＰあるいはＣＡシステムといった限定されたコンテンツ保護の複数ソース３０、基本データ保存システムあるいはサーバ、ファイル保存システムあるいはサーバといった本来的なコンテンツ保護が、もしあるとしてもわずかしかないような複数ソース３０のいずれかである。ソース３０がどこかから真のコンテンツ１２を取得するということに注意すること。例えば、権利保護されたコンテンツ１２であれば、そのコンテンツは遠隔ファイルサーバ上にあるが、演算装置１４上の権利管理システムといったソース３０経由でアクセス可能である。
【００３０】
その後、一般的に、ソース３０は、あるインターフェースを通して一般的な様式でマルチメディアデータのソースを行うことが可能である。ソース３０の実施は、アクセスしているコンテンツの異なる手段に対応するものであり、ハードドライブあるいは他のファイルシステムからＤＲＭファイルの読み込みを行うことのできるＤＲＭソース、ＤＶＤディスクからＤＶＤマルチメディアデータを読み込むことのできるＤＶＤソースといったものを含むことができる。ソース３０であることは、必ずしもそこからコンテンツ１２を保護することであるということを意味しない。一部のソース３０については、ある例においてコンテンツ保護がある場合もない場合もありうる。
【００３１】
同様に、１つ以上のシンク３２のそれぞれは、コンテンツ１２の受け入れあるいは「シンク」を行うシステムであるが、本発明の真の趣旨および範囲から逸脱することのない適切なシステムであって、同様に、当然ながらシンク３２が構成との間で相互作用するということが仮定される。例えば、シンク３２は、スピーカーに供給される音響を受け入れるための音響システム、ディスプレイに供給される映像を受け入れるためのビデオシステム、光源システム用制御装置に供給される光制御信号を受け入れるための光制御システム、モータシステム用制御装置に供給されるモータ制御信号を受け入れるためのモータ制御システム、等である。さらに、シンク３２は、単にネットワークあるいはデータケーブルといった導管に接続するインターフェースであってもよい。ソース３０と同様に、シンク３２はどこかに真のコンテンツ１２を供給するということに注意すること。例えば、音響コンテンツであれば、演算装置１４上の音声カードといったシンク３２で遠隔スピーカーに供給される。シンク３２によっては出力資源に関連付けられており、コンテンツ保護システムではないということに注意すること。シンク３２のある例では、それに関連付けられたコンテンツ保護システムがある場合もない場合もありうる。
【００３２】
重要なことは、本構成において、さらにここで図３に戻ると、各ソース３０および各シンク３２は、対応するソース信頼権限（ＳＯＴＡ）３８あるいはシンク信頼権限（ＳIＴＡ）４０をそれぞれが供給あるいはそれにアクセスすることで演算装置１４上のメディアベース３６のポリシーエンジン３４に統合することが可能ということである。これにより、各ソース３０および各シンク３２が演算装置１４の近辺あるいは遠隔に位置することができるが、それぞれの対応するＳＯＴＡ３８およびＳIＴＡ４０は演算装置１４の近辺にあるため、各ソース３０およびシンク３２に対する代理あるいは代行として、少なくともある点においては、機能することになる。重要なこと、さらに認識すべきことは、大部分のソース３０あるいはシンク３２が、それぞれ対応するＳＯＴＡ３８あるいはＳIＴＡ４０をもつことで、メディアベース３６と保護メディアパス構造に関与できるということである。
【００３３】
各ＳＯＴＡ３８は、構造で定義される保護されたメディアパス３９にある対応するソース３０の代行となり、必要に応じてソース３０からのコンテンツ１２の復号を行うための復号機能性をもたらすとともに、コンテンツ１２に関連付けられたポリシーを、元の様式からポリシーエンジン３４に従う様式に変換する。認められるとおり、このようなポリシーは実質的に、例えば図１のライセンス１６で示されているように、コンテンツ１２へのアクセスおよびレンダリングのための規則および必要事項である。ＳＯＴＡ３８はまた、特に信頼、ポリシー、権利に関連する問題に関して、ソース３０に代わって機能するということに注意すること。
【００３４】
同様に、各ＳIＴＡ４０は、構造で定義される保護されたメディアパス３９にある対応するシンク３２の代行となり、必要に応じてシンク３２に供給されるコンテンツ１２の暗号化を行うための暗号化機能性をもたらすとともに、ポリシーエンジン３４の様式からシンク３２に従う様式にコンテンツ１２に関連付けられたポリシーを変換する。これにより、シンク３２はコンテンツ１２と、対応するポリシーとを受信し、必要に応じて受信されたコンテンツ１２の復号を行い、受信されたポリシーに基づいてこのコンテンツのレンダリングを行う。ＳＯＴＡ３８は同様に、特に信頼、ポリシー、権利に関連する問題に関して、シンク３２に代わって機能するということに注意すること。
【００３５】
さらにまた、コンテンツ１２の特定部分に対応するポリシーが、本発明の真の趣旨および範囲から逸脱することのない適当なポリシーであるということに注意すること。こういったポリシーは典型的には、特定のソースだけに当てはまる上で述べたような元の様式で示され、任意の複雑さをもちうる。例えば、ポリシーは、オンあるいはオフに設定された一連のビットとして表現でき、実行される所定の言語で表現された論理を含むことができ、さらに／または実行可能な機械コードを含む、あるいはそれを参照することもできる。一般的に、ポリシーは、対応するコンテンツ１２に関して実行できるアクションといった情報、アクションに先立ってあるべき条件、アクションに引き続いて行われるべきイベント、コンテンツ１２に関連してあるべき、あるいはあってはならない要素、そのような要素に関する条件、供給されるコンテンツとともに伝送されるポリシー等の情報を表現する。
【００３６】
メディアベース３６のポリシーエンジン３４は、保護されたメディアパス構造の中心になるものであり、各ＳＯＴＡ３８の代わりにポリシーを実施する役割をもつ。このように、さらに、以下で詳細を示すとおり、ポリシーエンジン３４は、必要なシンクコンテンツ保護システム、シンクコンテンツ保護システムに対する流出ポリシー、メディアパスコンポーネントの内包および除外を含む、各適用ソース３０および各適用シンク３２間でポリシーを交渉する。ポリシーエンジン３４はまた、コンテンツ１２を不法主体からの盗難から保護する保証レベルで受信コンテンツ１２を処理できるような保護環境をもたらす。
【００３７】
ポリシーエンジン３４をもつメディアベース３６は、実質的に、特定ソース３０からのコンテンツ１２の処理を有効にして、処理されたコンテンツ１２を特定シンク３２に供給するための共通インフラをもたらす上で必要な機能を共通収集したものである。重要なことは、コンテンツ１２や関連するポリシーの様式がソース３０からソース３０で変わるものの、メディアベースはそのようなコンテンツ１２と関連ポリシーとを取り扱うことができるということである。その理由は、各ソース３０が対応するＳＯＴＡ３８をもち、ＳＯＴＡが必要に応じてコンテンツ１２の復号を行い、前述の元の様式から、ポリシーエンジン３４に従う前述の様式に関連ポリシーを変換するためである。同様に、コンテンツ１２や関連するポリシーの様式がシンク３２からシンク３２で変わるものの、メディアベースはそのようなコンテンツ１２と関連ポリシーとを取り扱うことができる。その理由は、各シンク３２が対応するＳIＴＡ４０をもち、ＳIＴＡが必要に応じてコンテンツ１２の暗号化を行い、ポリシーエンジン３４に従う前述の様式から、シンク３２に従う様式に関連ポリシーを変換するためである。
【００３８】
さらに詳細には、メディアベース３６は、演算装置１４のオペレーティングシステム、保護環境境界を越えて権利、規則、ポリシーの変換および交渉のための一般的機構、高ビット速度メディアデータの暗号化／復号を行うとともにこのデータを演算装置１４の保護環境と他の保護環境との間に安全に送るための一般的機構に保護環境をもたらすことで、メディアコンテンツ１２の保護環境への流入およびそこからの流出を可能にするための共通インフラを与える。これにより、メディアベース３６が、保護コンテンツ１２に対して演算装置１４からの、そこへの、さらにそれを経由したコンテンツ１２を保護様式で流すことを可能にし、保護コンテンツ１２の任意の処理を可能にする。その結果、どのような関係者であっても、場合に応じて、適当なＳＯＴＡ３８および／またはＳIＴＡ４０を配布することで演算装置１４上のオペレーティングシステムに対する任意のコンテンツ保護を行うためのサポートを追加できる。
【００３９】
典型的には、さらに図３でわかるとおり、メディアベース３６は、そのメディアベース３６の前述の共通インフラをもたらす多数のコアコンポーネント４２を含む。認められるとおり、各コンポーネント４２は、本発明の真の趣旨および範囲から逸脱することのない適当なコンポーネントである。そのようなコアコンポーネント４２を利用することは一般に知られているものであり、関係者にとって明らかなものであることから、ここで詳細を示す必要はない。
【００４０】
メディアベース３６のコアコンポーネント４２でもたらされる機能性に加えて、さらに必要な場合、関係者は、その追加機能性をもたらすためメディアベース３６と関連して作動するよう設計された適当な補助コンポーネント、あるいは「プラグイン」４４を配布することで演算装置１４上のオペレーティングシステムに対する任意の追加保護機能性のためのサポートを追加することができる。認められるとおり、各プラグイン４４は、本発明の真の趣旨および範囲から逸脱することのない適当なプラグインである。そのようなプラグイン４４を利用することは一般に知られているものであり、関係者にとって明らかなものであることから、ここで詳細を示す必要はない。
【００４１】
本発明の１つの実施例において、メディアベース３６が起動され、演算装置１４上のメディアアプリケーションにより、１つ以上の選定されたソース３０のそれぞれと、１つ以上の選定されたシンク３２のそれぞれとの間に保護されたメディアパス３９を配設する。おそらく、メディアアプリケーション４６は、演算装置１４あるいは他の場所にあるユーザあるいは他のアプリケーションの制御を受けている。これにより、メディアアプリケーション４６はレンダリングされるコンテンツ１２を選定し、その際に１つ以上の選定されたソース３０を選定して必要に応じて１つ以上のシンク３２を選定する。その後、メディアアプリケーション４６は、配設された保護されたメディアパス３９における保護コンテンツ１２のレンダリングには関与しないが、例外としては、おそらく、開始、停止、繰り返し、戻す、早送り等のレンダリング制御命令を行うものがある。
【００４２】
本発明の１つの実施例において、メディアベース３６およびそこに配設された保護されたメディアパス３９は、そのように配設された保護されたメディアパス３９内のコンテンツ１２を制御する役割だけをもち、そのため、アプリケーション４６はそのように配設された保護されたメディアパス３９内のコンテンツ１２に対する制御を行わない。これにより、アプリケーション４６は、メディアベース３６と、それにより配設された保護されたメディアパス３９とを通してコンテンツ１２のレンダリングを指示するが、非保護形式でそのコンテンツ１２への実際のアクセスあるいはそれに対する制御は特に行わない。特に、メディアベース３６および保護されたメディアパス３９は、コンテンツ１２に対応するポリシーに反してコンテンツ１２に関するアクションを行うようアプリケーション４６あるいは他の要素によって指示されることができない。その結果、さらに重要なことであるが、アプリケーション４６は、図３の保護されたメディアパス３９に関連して特に信頼性を確立する必要がなく、実際には、アプリケーション４６は、ある信頼された様式でコンテンツ１２を取り扱うよう信頼されていない。当然ながら、メディアベース３６と、それにより配設された保護されたメディアパス３９との作動中に上で示したようなレンダリング制御命令を発すること以外に、アプリケーション４６が実際にコンテンツ１２を取り扱わないため、アプリケーションにおいてそのように信頼を欠くということは有害ではない。
【００４３】
まとめると、１つ以上のソース３０からのコンテンツ１２が１つ以上のシンク３２に供給される保護されたメディアパス３９を配設するよう、メディアベース３６はアプリケーション４６の指示の下で作動する。おそらく、コンテンツ１２はある様式でメディアベース３６において作動し、配設された保護されたメディアパス３９を移行させるが、そのようなメディアベース３６によりそのコンテンツ１２上で行う作動は最小限必要なもの、あるいは最大限必要なものである。重要なことは、各ソース３０がそのコンテンツ１２に対して、配設された保護されたメディアパス３９を移行させることを可能にする前に、さらに本発明の１つの実施例において、メディアベース３６、そのポリシーエンジン３４、それで利用された各コンポーネント４２、それで利用された各プラグイン４４、各受信シンク３２、およびコンテンツ１２上で接する、すなわち「タッチ」する他の要素が（ａ）信頼しうるものであり、（ｂ）コンテンツ１２に関連付けられたポリシーに基づいてコンテンツ１２に接する権利をもつという条件をソース３０が満たすことである。
【００４４】
本発明に関して、ある要素が、その要素を保証するトークンの提供に基づいて信頼しうるということを示すことができる。そのように保証されたトークンは、本発明の真の趣旨および範囲から逸脱することのない適当な保証トークンである。例えば、さらに、特にデジタル領域において、そのような保証トークンは、おそらく既知の信頼されるルート権限に拡張戻しされる一連の保証認証を含む保証権限からのデジタル認証をもつものである。そのような認証には、認証内の鍵に基づいて信頼されるようになる保証可能要素のハッシュを含み、これにより、そのような要素の信頼に違反することを含む、ある目的のための要素の改変を行った結果として保証に失敗したハッシュとなるが、その場合、その要素は信頼されない。
【００４５】
同様に本発明に関連して、ある要素が信頼しうるとみなされると、その要素は信頼され、コンテンツ１２に関連付けられたポリシーで示された権利を与えられることができるかどうかに基づいてコンテンツ１２にタッチすることができるかどうかを自ら判断する。それに代わり、この要素は、他の要素からの権利ベースのクエリに対して真に応答するため、信頼をおかれるものである。例えば、ある要素が少なくともあるバージョン番号をもたなければならないとポリシーが述べており、しかもその要素が古いバージョン番号をもっている場合、この要素は信頼され、そのコンテンツ１２に接することを拒否するが、この特定のケースでは、問い合わせ側に対してそのように拒否した理由を説明することが期待される。同様に、例えば、ある要素が非保護形態でコンテンツ１２を保存してはならないとポリシーが述べており、しかもその要素が実際にはそうしている場合、この要素は同様に信頼され、そのコンテンツ１２に接することを拒否するが、同様にこの特定のケースでは、問い合わせ側に対してそのように拒否した理由を説明することが期待される。
【００４６】
本発明の１つの実施例において、さらにここで図４を参照すると、図３で示される保護されたメディアパス構成を用いて、１つ以上のソース３０から１つ以上のシンク３２に対して以下の様式でコンテンツ１２を供給する。予備的に、ユーザあるいは他の要素の指示によりアプリケーション４６が１つ以上のソース３０から１つ以上のシンク３２にコンテンツ１２を移送することを望み、それによりコンテンツ１２の定義をもつメディアベース３６に対して、コンテンツ１２が得られるソース３０のそれぞれと、コンテンツ１２が供給されるシンク３２のそれぞれとを呼び出す（ステップ４０１）。
【００４７】
それに応じて、定義されたコンテンツ１２、ソース３０、シンク３２に基づいて、メディアベース３６がそのような供給を行うために保護されたメディアパス３９を確立する（ステップ４０３）。これを行う際、メディアベース３６は、コンテンツ１２を取り扱い、その上で作動するとともに保護されたメディアパス３９経由で供給される１つ以上のコンポーネント４２を選定するが、同様に、コンテンツ１２を取り扱い、その上で作動するとともに保護されたメディアパス３９経由で供給される１つ以上のプラグイン４４を選定する。メディアベース３６は、保護されたメディアパス３９を確立し、本発明の真の趣旨および範囲から逸脱することなくコンポーネント４２およびプラグイン４４を選定するための適切な方法を用いる。そのような保護されたメディアパス３９の確立とコンポーネント４２およびプラグイン４４の選定をメディアベース３６により行うことは既知のものであり、関係者にとっては明らかなものであるため、ここで詳細を示す必要はない。例えば、本発明のメディアベース３６で、さらにそれに関連して実行されるアクションは「付録」で示すものを含む。
【００４８】
重要なことは、メディアベース３６が保護されたメディアパス３９を確立すると同時に、定義されたパス３９の各ソース３０に対応するＳＯＴＡ３８が、図３で見られるとおり、ソース３０をメディアベース３６に接続するセキュアロックボックスとしてインスタンス化されるということである（ステップ４０５、図４）。このようなインスタンス化は、本発明の真の趣旨および範囲から逸脱することなく、ソース３０、メディアベース３６、あるいはそれらを組み合わせたものにより実施される。上で示したとおり、各ＳＯＴＡ３８は信頼権限であり、保護されたメディアパス３９にある対応ソース３０の代行となり、必要に応じてソース３０からのコンテンツ１２の復号機能性をもたらすとともに、コンテンツ１２に関連付けられたポリシーを、元の様式からメデイアベース３６のポリシーエンジン３４に従う様式に変換する。ＳＯＴＡ３８はまた、特に信頼、ポリシー、権利に関連する問題に関して、ソース３０に代わって機能するということにも注意すること。
【００４９】
同様に重要なことは、メディアベース３６が保護されたメディアパス３９を確立すると同時に、定義されたパス３９の各シンク３２に対応するＳIＴＡ４０が、図３で見られるとおり、シンク３２をメディアベース３６に接続するセキュアロックボックスとしてインスタンス化されるということである（ステップ４０７、図４）。このようなインスタンス化は、本発明の真の趣旨および範囲から逸脱することなく、シンク３２、メディアベース３６、あるいはそれらを組み合わせたものにより同様に実施される。同様に、上で述べたとおり、各ＳIＴＡ４０は信頼権限であり、保護されたメディアパス３９にある対応シンク３２の代行となり、必要に応じてシンク３２に供給されるコンテンツ１２の暗号化機能性をもたらすとともに、コンテンツ１２に関連付けられたポリシーをポリシーエンジン３４の様式からシンク３２に従う様式に変換する。さらに、ＳIＴＡ４０はまた、特に信頼、ポリシー、権利に関連する問題に関して、シンクに代わって機能するということにも注意すること。
【００５０】
本発明の１つの実施例において、ソース３０の代わりに機能するＳＯＴＡ３８は保護されたメディアパス３９に対して信頼を確立する。その後、さらに信頼が一度確立されると、ステップ４０１でアプリケーション４６により定義されたとおり、レンダリングされるコンテンツ１２に対応するポリシーをＳＯＴＡ３８が伝播させる。特に、ＳＯＴＡ３８はメディアベース３６のポリシーエンジン３４でまず信頼を確立することでＳＯＴＡ３８が信頼を確立する（ステップ４０９）。その後、信頼されるポリシーエンジン３４が、そのＳIＴＡ４０で示される各コンポーネント４２、各プラグイン４４、各シンク３２を含む、保護されたメディアパス３９の残りで信頼を確立する（ステップ４１１）。
【００５１】
信頼確立において、さらに上で示されたとおり、ある要素が、その要素を保証する保証権限からのデジタル認証といったトークンの提供に基づいて信頼しうるということを示すことができる。そのようなトークン／認証には、認証中の鍵に基づいて証明でき信頼されるようになる要素のハッシュが含まれ、これにより要素の信頼確立にそのハッシュの証明を含めることができる。どの点でも、ある要素で信頼が確立されない場合、そのような要素はコンテンツ１２へのアクセスが拒絶されるということに注意すること。これにより、この要素は、可能であれば保護されたメディアパス３９から除去されなければならない。可能でない場合、ＳＯＴＡ３８はコンテンツ１２を保護されたメディアパス３９にリリースしない。
【００５２】
信頼されるポリシーエンジン３４が、そのＳIＴＡ４０で示される各コンポーネント４２、各プラグイン４４、各シンク３２を含む、保護されたメディアパス３９の各要素で実際に信頼を確立し、その後、ＳＯＴＡ３８が、レンダリングされるコンテンツ１２に対応するポリシーを伝播させる。特に、ＳＯＴＡ３８はそのようなポリシーをポリシーエンジン３４に伝播させる（ステップ４１３）。これを行う際、ＳＯＴＡ３８は、元の様式からメディアベース３６のポリシーエンジン３４に従う様式にポリシーを変換する上で必要な機能性を用いて、その後、変換されたポリシーをポリシーエンジン３４に移送する。
【００５３】
その後、変換されたポリシーをもつポリシーエンジン３４は、メディアベース３６の各コンポーネント４２および各プラグイン４４が、変換されたポリシーに対応するコンテンツ１２に接する、あるいはそれにアクセスする権利をもつという状態を確立する。特に、変換されたポリシーに基づき、ポリシーエンジン３４は必要に応じて、メディアベース３６の各コンポーネント４２およびプラグイン４４が、変換されたポリシーの項を満たすということを判定する（ステップ４１５）。その場合でも、信頼された要素は、ポリシーに基づいてコンテンツ１２に接する、あるいはそれにアクセスする権利をもたないということに注意すること。例えば、さらに、上で示されたとおり、ある要素が少なくともあるバージョン番号をもたなければならないとポリシーが述べており、その要素が古いバージョン番号をもっている場合でも、そのように信頼された要素はそのコンテンツ１２に接する、あるいはそれにアクセスする権利をもたない。ある点で信頼された要素が、ポリシーエンジン３４で決定されたとおり、コンテンツ１２にアクセスする、あるいはそれに接する権利をもたない場合、そのような要素はコンテンツ１２へのアクセスを拒絶される。これにより、この要素は、可能であれば保護されたメディアパス３９から除去されなければならない。可能でない場合、ＳＯＴＡ３８はコンテンツ１２を保護されたメディアパス３９にリリースしない。
【００５４】
さらに、変換されたポリシーをもつポリシーエンジン３４は、保護されたメディアパス３９の各シンク３２が、変換されたポリシーに対応するコンテンツ１２に接する、あるいはそれにアクセスする権利をもつという状態を確立する。特に、ポリシーエンジン３４はそのように変換されたポリシーをシンク３２のＳIＴＡ４０に伝播させる（ステップ４１７）。これを行う際、ＳIＴＡ４０は同様に、変換されたポリシーをシンク３２に従う様式に再変換する上で必要な機能性を用いて、その後、その再変換されたポリシーをＳIＴＡ４０に送信する。その後、シンク３２およびそのＳIＴＡ４０は保護されたメディアパス３９の信頼された要素として、そのような再変換されたポリシーに従うよう信頼をおかれるようになる。
【００５５】
本発明の１つの実施例において、ポリシーエンジン３４は、追加あるいは代替として、ポリシーに対応するコンテンツ１２に関してシンク３２が取ろうとするアクションをシンク３２のＳIＴＡ４０に要求する（ステップ４１９）。そのようなアクションには、例えば、コンテンツ１２のプレイ、コンテンツ１２のコピー、コンテンツ１２を非保護様式でエクスポートするといったものがある。ＳIＴＡ４０およびそのシンク３２を含む保護されたメディアパス３９はアプリケーション４６の指示で確立されたため、そのようなＳIＴＡ４０／シンク３２は、そのコンテンツ１２に関してどのようなアクションが取られようとしているかを明示的あるいは黙示的に知るべきであるということに注意すること。さらにまた、ポリシーエンジン３４はアプリケーション４６に対してそのようなアクションを依頼できるものの、そのアプリケーション４６は真に応答するまでは信頼されていないのに対して、シンク３２／ＳIＴＡ４０は実際にはそのように信頼されているということに注意すること。
【００５６】
少なくとも、信頼されたシンク３２／ＳIＴＡ４０はそのようなアクションに応答し、ポリシーエンジン３４がそれをＳＯＴＡ３８に転送する（ステップ４２１）。その後、ＳＯＴＡ３８は、おそらくはコンテンツ１２に対応するポリシーを参照しながらＳIＴＡ４０／シンク３２がアクションをとることができるかどうかを決定し、ポリシーエンジン３４に対してそれを通知する（ステップ４２３）。認められるとおり、アクションを取ることができない場合、ＳＯＴＡ３８は、コンテンツ１２が保護されたメディアパス３９にリリースされることを認めない。
【００５７】
アクションが取られると仮定すると、ポリシーエンジン３４がアプリケーション４６に対してそれを通知し（ステップ４２５）、アプリケーション４６がメディアベース３６に対してそのようなアクションや関連するアクションを実施するよう命令することで次に進む（ステップ４２７）。例えば、アプリケーションはメディアベースに対してそのコンテンツ１２をプレイするよう命令し、さらに、その後でメディアベース３６に対して停止、巻き戻し、早送り、前スキップ、後スキップ等を命令する。
【００５８】
アクションを取っている際に、コンテンツ１２が、メディアベース３６で配設されたとおりに保護されたメディアパス３９を移送する。特に、メディアベース３６はソース３０からコンテンツ１２を検索し、必要に応じてコンテンツ１２の復号を行うためＳＯＴＡ３８の復号機能性を用い、その後、そのコンテンツ１２を下流に送る。これにより、メディアベース３６とそのコンポーネント４２およびプラグイン４４は、コンテンツ１２で必要とされるどのようなプロセスでも実施し、その後、メディアベース３６が、必要に応じてコンテンツ１２の暗号化を行うためにＳIＴＡ４０の暗号化機能性を用い、このコンテンツ１２をシンク３２に供給する。当然ながら、その後、シンク３２がこのコンテンツ１２を最終目的地に送る。
【００５９】
コンテンツ１２に関して取られるアクションは、ポリシーエンジン３４によってＳＯＴＡ３８に伝えられるため、ＳＯＴＡ３８は、そのコンテンツ１２に対応するポリシーに関連する状況情報を更新することができる。例えば、プレイカウントを維持するようそのポリシーが要求する場合、ＳＯＴＡ３８は、ある時点後にプレイカウントの調整を行うよう伝えなければならない。それに代わり、コンテンツ１２の供給を行うＳＯＴＡ３８は、アクションが取られているということを自ら検知し、その後、必要に応じて状況情報を更新する。
【００６０】
ここで認められるとおり、アプリケーション４６は後のある時点で保護されたメディアパス３９を再構成することを決定する。例えば、アプリケーション４６は音響シンク３２および光シンク３２を変更する。この場合、さらに認められるとおり、図４に示されるプロセスが繰り返され、再構成されたパス３９における信頼の確立と、それに対する権利の伝播を行わなければならない。
【００６１】
さらに認められることとして、本発明において、メディアベース３６は、ソース３０とシンク３２との任意の、あるいはほぼ任意の組合せに基づいて保護されたメディアパス３９を確立するよう指示される。重要なことは、どのようなパス３９が確立されたとしても、本発明の構造により、そのようなパス３９が信頼されうるものとして、そのパスを移送するためのコンテンツ１２に対応するポリシーあるいは権利に関して満足できるものであるものとして認証されることができるということである。さらに、パス３９がアプリケーション４６の命令により確立されたとしても、そのアプリケーション４６そのものは信頼されうるものである必要はない。理由は、そのようなコンテンツ１２を盗み出すよう故意に、あるいは故意ではなくともアプリケーション４６が用いられるような方法でアプリケーション４６はコンテンツ１２に接する、あるいはアクセスすることが決してないためである。
【００６２】
拒絶応答イネーブラおよびそのインターフェース
図４に示された方法に関連して上で示したとおり、信頼されるシンク３２／ＳIＴＡ４０は、ステップ４２１といったポリシーエンジン３４に応じて取られるアクションをもたらし、ＳＯＴＡ３８は、ＳIＴＡ４０／シンク３２がアクションを取ることができるかどうかを判定し、ステップ４２３においてこれをポリシーエンジン３４に通知する。アクションが取られるようにすることをＳＯＴＡ３８が拒絶した場合、ＳＯＴＡ３８は、コンテンツ１２が保護されたメディアパス３９にリリースされることを認めない。
【００６３】
そのような拒絶があれば、通常、図４のそれ以降のプロセスを終了させるが、おそらくその結果は、アプリケーション４６のユーザにとって不満足なものとなる。しかし、拒絶のうち少なくとも一部のタイプの根拠は予測でき、そのような根拠の少なくとも一部は比較的直接的な様式で取り扱うことができ、さらに、そのため少なくとも拒絶の一部の根拠を示すための機能性を含む、あるいはそれにアクセスするようＳＯＴＡ３８を構築することができるということが認められる。そのような拒絶は数多く、広範であり、適切なライセンス１６の抜け（図１）、要素の最新バージョンの抜け、不適切な機能を行うよう設定されたシンク３２が含まれるといったことがある。本発明の１つの実施例において、保護されたメディアパス３９の構成が、少なくとも拒絶の一部に応じる拒絶応答機能性をもつ。
【００６４】
そのような拒絶応答機能性は、本発明の真の趣旨および範囲から逸脱することのないメディアベース３６とともに含まれるものである。しかし、そのような拒絶応答機能性は特定ソース３０と密接に関連付けられているため、そのような機能性が、そのソース３０に対応するＳＯＴＡ３８とともに含まれる、あるいはそれにアクセスされる可能性が高い。
【００６５】
拒絶への応答には、アプリケーション４６を通してユーザからの入力を必要とすることがあり、さらにそのようなユーザ入力の前に代わりに、ＳＯＴＡ３８がユーザの助けを借りずに応答することもあることに注意すること。しかし、良好な慣習として、アプリケーションのユーザは、特に、その応答においてネットワークといった遠隔ソースからアイテムあるいは情報を得る必要がある場合、拒絶に対する応答に常にかかわるべきである。本発明の１つの実施例において、さらに図５をここで参照すると、各ＳＯＴＡ３８は１つ以上の拒絶レスポンダイネーブラ４８をもたらすが、これらはそれぞれ特定の拒絶に応じるものであり、アプリケーション４６は、メディアベース３６経由で供給される各イネーブラ４８とインターフェースすることのできるレスポンダインターフェース５０を含む。
【００６６】
これにより、さらに認められるべきものとして、供給されたイネーブラ４８およびインターフェース５０が、アプリケーション４６経由でＳＯＴＡ３８により拒絶応答の詳細を有効にするための抽象層をもたらす。特に、ＳＯＴＡ３８の供給されたイネーブラ４８は特定の拒絶に応答するための手順を示すが、それには、情報、ユーザから要求される入力といったものを取得するための１つ以上の場所が含まれ、インターフェース５０は、アプリケーション４６と、メディアベース３６経由で供給されるイネーブラ４８との間の一定の相互作用手順を特定する。重要なことは、供給されるイネーブラ４８は拒絶から拒絶、ソース３０からソース３０の間で変わるが、供給されるイネーブラ４８が関連付けられるのがどのような拒絶あるいはどのようなソース３０／ＳＯＴＡ３８であるかに関係なく、このインターフェース５０は、常に同一のインターフェース手順を用いるということである。これにより、そのイネーブラ４８を供給した特定ソース３０を区別するが必要なく、拒絶応答する提供されたイネーブラ４８から利用できる機能がどのようなものであっても、アプリケーション４６がそれを利用することになる。アプリケーション４６が信頼されていないものであっても、イネーブラ４８経由で得られた情報あるいはデータがどのようなものであっても、それがメディアベース３８および／または携帯式メディアパス３９に供給され、それ自体で、メディアベース３６および／または携帯式メディアパス３９のコンテキスト内で信頼しうるものであることを証明しなければならないということに注意すること。つまり、インターフェース５０がイネーブラ４８を実行する場合、アプリケーション４６がとる方策で固有な信頼性というものはない。
【００６７】
ここで図６に戻ると、保護されたメディアパス３９に関連して上で示されたとおり、信頼されたＳIＴＡ４０は、ステップ４２１といったポリシーエンジン３４に応じて取られるアクションをもたらし、ＳＯＴＡ３８は、ＳIＴＡ４０がこの時点でアクションを取ることができるようにすることを認めないが、その理由はステップ４２３における欠陥が認められるためである（ステップ６０１）。しかし、ＳＯＴＡ３８は、その拒絶の根拠が、そのＳＯＴＡ３８で利用可能な、あるいはそれに含まれる特定イネーブラ４８のアプリケーション経由で応答され（ステップ６０３）、さらにＳＯＴＡ３８はそのようにして、メディアベース３６経由でアプリケーション４６に対して特定イネーブラ４８を供給するということも認めている（ステップ６０５）。メディアベース３６がポインタあるいはインターフェース５０への他の参照手段をもち、それにより、そのポインタあるいは他の参照手段によりアプリケーション４６のインターフェース５０に対して提供されたイネーブラが指示するということに注意すること。
【００６８】
認められるとおり、供給されるイネーブラ４８は、そのイネーブラ４８を必要とする拒絶に応じるため、必要な情報あるいはデータがどのようなものであっても、それを取得するためのインターフェース５０を経由してアプリケーション４６に対して必要となる全ての情報や方法を含む。これにより、供給されたイネーブラ４８は、メディアベース３６経由でアプリケーション４６のインターフェース５０によりＳＯＴＡ３８から受け入れられ（ステップ６０７）、インターフェース５０は、供給されたイネーブラ４８を実質的に実行するための前述の一定の相互作用手順を適用する（ステップ６０９）。これにより、供給されたイネーブラ４８と、ユーザからの必要な、および／または慎重な入力とを用いて、アプリケーション４６と、そのインターフェース５０とが、実際にはソースがどのように必要なものであり、それが近辺にあるか遠隔にあるかに関係なく、ソースからの拒絶によりどのようなデータあるいは情報が必要とされるかという状況を得ようとする（ステップ６１１）。当然ながら、必要なユーザの相互作用のレベルは状況に応じて変わる。例えば、特にダウンロードが無料である場合、データあるいは情報をダウンロードする前にユーザからの許可を得るだけで十分であるような状況もある。しかし費用がかかわる場合、その費用をどのように支払うかということは言うまでもなく、その費用を支払うことについてユーザの許可を得る必要があるのは当然である。
【００６９】
これにより、拒絶理由が適切なライセンス１６がないというものであれば、そのライセンス１６が取得される。要素が最新バージョンでないという理由によるのであれば、その要素の最新のバージョンが取得され、不適切な機能を実施するよう設定されたシンク３２が含まれているという理由であれば、何よりも、ユーザおよび／またはアプリケーションがシンク３２を適切に設定する。当然ながら全ての拒絶が修復できるわけではないことに注意すること。例えば、ユーザが要求されたライセンス１６の取得を望まない場合、要素の最新バージョンが入手できない場合、ＳＯＴＡ３８にとって満足できるような様式でシンク３２の設定ができない場合がある。当然ながら、そのような状況ではその応答は失敗し、ＳIＴＡ４０がその要求されたアクションを取ることをできるようにすることをＳＯＴＡ３８が拒絶する。
【００７０】
しかし、必要なデータあるいは情報を取得することで拒絶が実際には修復される場合、アプリケーション４６がそのデータあるいは情報をメディアベース３６に送付し（ステップ６１３）、そのメディアベース３６は、例えばライセンス１６をライセンス保存装置に保存する、コンポーネントの最新バージョンをインストールする、シンク３２の設定を調節するといった方法で必要に応じてそのデータを適切に利用する（ステップ６１５）。
【００７１】
一旦終了すると、インターフェース５０は、ＳＯＴＡ３８、アプリケーション４６、および／またはアプリケーション４６のユーザに対して、供給されたイネーブラ４８に伴う応答が完了し、その応答がおそらく成功した、あるいは失敗したということを通知する（ステップ６１７）。さらに、インターフェース５０の一定相互作用手順が、ＳＯＴＡ３８、アプリケーション４６、および／またはアプリケーション４６のユーザに対して定期的に応答の進捗と、前述の時間が応答を逃すことなくそれに失敗することがないということを通知する定期進捗通知機能を含むということもある。その場合、インターフェース５０は、実際には定期的に、ＳＯＴＡ３８、アプリケーション４６、および／またはアプリケーション４６のユーザに対して、応答の途中にその進捗を通知する（ステップ６１２）。
【００７２】
少なくとも、ステップ６１７で応答が完了したことをＳＯＴＡ３８が通知されると、ＳIＴＡ４０／シンク３２が当初拒絶されたアクションを取ることができるかどうかをＳＯＴＡが再び判定する（ステップ６１９）。アクションが取られるようにできることをＳＯＴＡ３８が再び拒絶した場合、ＳＯＴＡ３８は保護されたメディアパス３９にコンテンツ１２がリリースされることを再び認めないが、それに代わり、その拒絶の根拠が、ステップ６０３においてＳＯＴＡ３８で利用可能な、あるいはそれに含まれる特定イネーブラ４８のアプリケーションを通して応答されるということが再び認められ、ＳＯＴＡ３８はステップ６０５においてメディアベース３６経由でアプリケーション４６に対して特定イネーブラ４８を再び供給する。
【００７３】
しかし、ＳＯＴＡ３８が実際にはここでＳIＴＡ４０が要求されたアクションを取ることを認める場合、この時点でＳＯＴＡ３８はコンテンツ１２が保護されたメディアパス３９にリリースされることを認め、図４のステップ４２５において、ポリシーエンジン３４がアプリケーション４６に対してそのことを通知する。ここで認められるとおり、アプリケーション４６はその後、図４のステップ４２７において、そのようなアクションおよび関連するアクションを実施するようメディアベース３６に命令することで、次に進む。
【００７４】
ここで認められるとおり、ＳIＴＡ４０で要求されたアクションをＳＯＴＡが拒絶した場合、ユーザおよび／またはアプリケーション４６にＳＯＴＡ３８に対する応答をさせるようＳＯＴＡ３８に行わせることができるようアプリケーション４６のインターフェース５０で実行されるイネーブラ４８をＳＯＴＡ３８が使用する。ＳＯＴＡ３８は、おそらく良好な慣習として独自にこれに応答できるが、特に、その応答においてネットワークといった遠隔ソースからデータ、あるいは情報を得る必要がある場合、アプリケーションのユーザが拒絶に対する応答に常にかかわるべきである。さらに、少なくとも、アプリケーション４６におけるユーザの関与が必要とされるようなケースがありうる。
【産業上の利用可能性】
【００７５】
本発明は、適切なソース３０およびシンク３２がそれぞれ対応するＳＯＴＡ３８およびＳIＴＡ４０をもち、これによりメディアベース３６との通信が達成可能であることを仮定したソース３０およびシンク３２に関して実施されてもよい。したがって、本発明の保護されたメディアパス３９は、ソース３０からシンク３２にコンテンツを供給するよう任意の様式で保護されたメディアパス３９を確立することを可能にするＳＯＴＡ３８、メディアベース３６、ＳIＴＡ４０を含むものと解釈される。
【００７６】
レンダリングあるいは再生を行うシンク３２に関連して本発明は開示されているものの、本発明の真の趣旨および範囲から逸脱することなくシンク３２が他のアクションを実施できることに注意すること。こういった他のアクションには、パソコン、携帯型装置等の別個の演算装置１４にコンテンツ１２を伝送すること；携帯式メモリ、磁気あるいは光ディスク等にコンテンツ１２を伝送すること；異なる保護スキームでコンテンツ１２を伝送すること；保護スキームなしでコンテンツ１２をエクスポートする；異なる様式でコンテンツ１２を伝送あるいはエクスポートするといったものが含まれるが、これらに限定されるものではない。
【００７７】
一般的に、その後、コンテンツ１２をレンダリングあるいは再生し、コンテンツ作成、編集、分配といったタスクを行うため、メディアベース３６で配設された保護されたメディアパス３９を用いることが可能である。例えば、コンテンツ１２は、コンテンツ１２をある方法で編集することを認める、あるいは禁止するポリシーをもつことが可能である。このように、コンテンツ１２に対応するポリシーに全て従う様式でコンテンツ１２を復号し、これを編集し、その後再暗号化するため、保護されたメディアパス３９を用いることができる。
【００７８】
本発明に関連して実施されるプロセスを有効にするため必要なプログラミングは比較的直送的であり、関連するプログラミング界で明らかなものである。したがって、このようなプログラミングはここには添付されない。その後、ある特定のプログラミングを用いて、本発明の真の趣旨および範囲から逸脱することなく本発明を有効にする。
【００７９】
前述の説明において、本発明が、複数シンク３２のいずれかに配送される複数ソース３０のいずれかからのコンテンツ１２に対する保護されたメディアパス３９を定義する新しい有用な構成および方法を含むということがわかる。このような構成に関連する方法では、コンテンツ１２に対応する、信頼しうる、規則を守るポリシーとしてどのようにしてパスが確立されるかを定義する。
【００８０】
発明の概念から逸脱することなく上述の実施例に対して変更を加えることができることを認識すべきである。したがって、本発明は、開示された特定の実施例だけに限定されるものではなく、添付の請求項で定義される本発明の真の趣旨および範囲内における改造も含めることを意図することを理解すべきである。
【００８１】
付録
［注：「再生」という用語は、ファイルへの保管や一斉同報等を含む、コンテンツの出力レンダリングについて述べているものと解釈されるべきである。「再生」という語を用いるのは単に便利なためである。］
【００８２】
Ｉ．メディアベースＡＰＩおよび機能性
本セクションおよび以下のセクションは両方とも、与えられた機能性タイプで分類されたＡＰＩについて考察する。
ａ．マルチメディアを開く／閉じる
ｉ．ＯｐｅｎＵＲＬ：メディアベースを用いてマルチメディアを開く場合の何よりももっとも一般的な方法であり、これにより、特定ＵＲＬでコンテンツを読むことのできるメディアソースを作成するため、メディアベースがそのソースレゾルバを使うことになる。
ｉｉ．ＯｐｅｎＳｏｕｒｃｅ：アプリケーションがすでにメディアソースを作成し、そのソースを用いるために表示を望む場合、ＯｐｅｎＳｏｕｒｃｅ（）を呼び出し、メディアベースがそのソースを直接使用する。
ｉｉｉ．ＯｐｅｎＢｉｎｄａｂｌｅ：これは、メディアソースをもたないがメディアソースオブジェクトが得られるＩＢｉｎｄａｂｌｅを実施するオブジェクトを代わりにもつアプリケーションのためのものである。ＩＢｉｎｄａｂｌｅインターフェースはデバイスディレクトリからのものである。
ｉｖ．ＯｐｅｎＢｙｔｅＳｔｒｅａｍ：これは、提示されるマルチメディアデータ読み込み可能なＩＭＦＢｙｔｅＳｔｒｅａｍをもつアプリケーションのためのものである。ＩＭＦＢｙｔｅＳｔｒｅａｍは、シーケンシャルデータを得ることのできるオブジェクトに対するメディアベースの抽象化である。
ｖ．ＯｐｅｎＴｏｐｏｌｏｇｙ：改良型アプリケーションでは、メディアベースやメディアセッションの実施に依存する代わりに、表示で用いられるソース、シンク、トランスフォームを定義するトポロジーを作成することが望まれる（ＩＩＩ．ａ．ｉｉｉ参照）。これらのアプリケーションによりトポロジーを与え、その他の場合に実施されるソースあるいはトポロジー分解をバイパスすることができる。
ｖｉ．閉じる：現在のメディアを閉じる。メディアベースは、その後、上記の「開く」呼び出しのいずれかを用いることで新たなメディアに対して再利用可能である。
ｂ．表示制御
ｉ．開始：アプリケーションが再生開始のためにこれを呼び出す。パラメータにより、再生に対する開始位置および終了位置をアプリケーションが特定できるようになるが、デフォルトとしては、再生要求により開始点で開始され終了点までプレイする。これらの開始・終了パラメータの単位を定める第３のパラメータがある。デフォルトの単位は、１０ＭＨｚの時間単位であるが、例えばフレーム番号あるいは時間コードといったマルチメディア表示における位置を特定する他のシステムを用いることも可能である。
開始は、メディアベースがすでに開始されている場合にも呼び出される；これはコンテンツにおける新たな場所を探すためのものであり、ここから再生が開始される。
ｉｉ．停止：アプリケーションが再生を停止するためにこれを呼び出す。クロック上に示される時間はゼロに戻る。アプリケーションが、同じくデフォルトパラメータでＳｔａｒｔ（）を呼び出すと、表示の初めから再生が開始される。
ｉｉｉ．一時停止：アプリケーションが再生を一時停止するためにこれを呼び出す。クロック上に示される時間は「凍結」されたままになる。アプリケーションが、同じくデフォルトパラメータでＳｔａｒｔ（）を呼び出すと、一時停止されたところから再生が再開される。
ｉｖ．ＳｅｔＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＳｏｕｒｃｅ：表示のためにクロック上の時間を駆動させようとする改良型アプリケーションのためのものである。アプリケーションがこれを呼び出すと、この時間ソースで示される時間に従って全コンポーネントが起動しようとする。この呼び出しがない場合、メディアセッションは、１つをオファーする全コンポーネントから時間ソースを選定する（ＩＩＩ．ｂ．ｉｉｉ参照）。
ｃ．情報クエリ
以下に示すＡＰＩは、表示に関する情報をさらに求めるアプリケーションに対して有用である。
ｉ．ＧｅｔＣａｐａｂｉｌｉｔｉｅｓ：この方法は、表示中に変わりうるメディアベースやメディアセッションのさまざまな機能を示す。
ｉｉ．ＧｅｔＭｅｔａｄａｔａ：この方法により、表示（例えば、継続時間、件名、著者等）に関するメタデータに対してクエリの可能なプロパティストアをアプリケーションが取得できるようになる。
ｉｉｉ．ＧｅｔＤｅｓｔｉｎａｔｉｏｎ：使用中の送信先にポインタ検索する。
ｉｖ．ＧｅｔＳｔａｔｉｓｔｉｃｓ：メディアベースのアクティビティに関する統計量を検索する。
ｄ．シャットダウン：メディアベースがもう使われなくなった場合に呼び出される。全リソースと、（メディアセッションを含む）他コンポーネントへの参照をリリースし、これらを同じくシャットダウンする。
ｅ．イベント
メディアベースがメディアイベント発生器を経由してアプリケーションにイベントを通知する。以下に示すものは、より一般的なイベントの一部を示すリストであるが、メディアセッション内においてコンポーネントで発生される他のイベントについてもアプリケーションに伝播される。
ｉ．ＭＥＭｅｄｉａＯｐｅｎｅｄ：このイベントは、表示出力がどのように見えるかを記述する表示デスクリプタに伴うものである。
ｉｉ．ＭＥＭｅｄｉａＳｔａｒｔｅｄ
ｉｉｉ．ＭＥＭｅｄｉａＳｔｏｐｐｅｄ
ｉｖ．ＭＥＭｅｄｉａＰａｕｓｅｄ
ｖ．ＭＥＭｅｄｉａＥｎｄｅｄ
ｖｉ．ＭＥＭｅｄｉａＣｌｏｓｅｄ
ｖｉｉ．ＭＥＭｅｄｉａＲａｔｅＣｈａｎｇｅｄ
ｖｉｉｉ．ＭＥＥｎｇｉｎｅＳｔａｔｅＣｈａｎｇｅｄ
ｉｘ．ＭＥＮｅｗＰｒｅｓｅｎｔａｔｉｏｎ：このイベントは、メディアソースから現れる表示がどのように見えるかを記述する表示デスクリプタに伴うものである。「開く」の１つが呼び出された後に、タイムラインシナリオで継続してメディアソースが出力する新たな表示毎にこのイベントが受け入れられる。アプリケーションが任意にこの情報を用いて、この新規表示の予測宛先を構成する。
ｘ．ＭＥＰｒｅｓｅｎｔａｔｉｏｎＳｗｉｔｃｈｅｄ：新規表示が実際に再生されると、このイベントが送られる。表示の行われるさまざまな出力全てに関係する。
ｘｉ．ＭＥＯｕｔｐｕｔｓＵｐｄａｔｅｄ：宛先（出力）変更が全て解決され定置されると、この変更の際にこのイベントが送信される。表示が現在行われているさまざまな出力全てに関係する。
【００８３】
ＩＩ．メディアセッションＡＰＩおよび機能性
メディアベース制御層を用いる各表示は、インスタンス化された、あるいはメディアベースで取得されたメディアセッションで実行される。メディアベースは広範な多数のシナリオで用いられるメディアセッション実施をもたらすものの、ＡＰＩ下で表示される他のメディアセッションは仕様に従って構築できる。表示されているマルチメディアが、メディアソース、メディアシンク、ＭＦによるメディアセッションで用いられる他のＭＦ構成の概念に適していない場合、これが一般に有用である。例えば、ショックウェーブフラッシュ表示を行うことのできるメディアセッションがメディアベースで供給される。
ａ．セッション構成
以下のＡＰＩにより、メディアベースが表示用にメディアセッションを構成することができるようになる。
ｉ．ＲｅｓｏｌｖｅＴｏｐｏｌｏｇｙ：全トポロジーに対する解決の必要な表示（ＩＩＩ．ａ．ｉｉｉ参照）に対する部分トポロジーを作成した場合、メディアベースがこれを呼び出す。
ｉｉ．ＳｅｔＴｏｐｏｌｏｇｙ：予定されている表示に対して完全なトポロジーをもつ場合、メディアベースがこれを呼び出す。メディアセッションがメディアプロセッサ上でこれを設定し、トポロジーで特定された全ての変換を通してメディアソースからデータを取得するため、メディアプロセッサがパイプラインを設定する。
ｉｉｉ．ＳｅｔＰｒｅｓｅｎｔａｔｉｏｎＣｌｏｃｋ：これが呼び出されると、表示を制御するために用いられるクロックからの通知を受信するため、メディアセッションは、全コンポーネント（メディアシンクおよび一部のメディアソース）が加入していることを確認する。
ｉｖ．ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｐｅｒｔｙＳｔｏｒｅ：拡張可能な構成パラメータ組がメディアセッションにこの方法を用いて渡される。
ｂ．表示制御
以下のＡＰＩにより、メディアベースが表示制御を行うことが可能になる。ＩＩ．ｂ．iからＩＩ．ｂ．ｉｖについては、上記のメディアベースセクション（Ｉ．ｂ）におけるコメント参照のこと。
i．開始
ｉｉ．停止
ｉｉｉ．一時停止：
ｉｖ．ＳｅｔＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＳｏｕｒｃｅ
ｖ．プレロール：メディアセッションに対して、予定されている表示を開始するために全ての準備を整えるよう伝えるため、メディアベースがこれを用いる。
ｃ．情報クエリ
このＡＰＩにより、メディアベースがメディアセッションから情報取得できるようになる。
i．ＧｅｔＳｅｓｓｉｏｎＧＵＩＤ：メディアセッションの実施特定を行う。上述のとおり、メディアベースは広範囲の多数のシナリオで用いられる実装をもたらすが、他の実装も同様に用いることができる。
ｉｉ．ＧｅｔＳｅｓｓｉｏｎＣａｐａｂｉｌｉｔｉｅｓ：Ｉ．ｃ．iと同様。
ｄ．シャットダウン：
ｅ．イベント
メディアセッションで生成されたイベントはメディアベースで受け入れられる。メディアベースは、その一部を、メディアベースイベント（Ｉ．ｅ）のリストでリストアップされているイベントの１つに変換する。一部について、メディアベースは、それに含まれる情報に基づいて作動し、それをアプリケーションに伝播しない。他のものについて、メディアベースはアプリケーションに伝播する。
i．ＭＥＳｅｓｓｉｏｎＰｒｅｒｏｌｌｅｄ
ｉｉ．ＭＥＳｅｓｓｉｏｎＳｔａｒｔｅｄ
ｉｉｉ．ＭＥＳｅｓｓｉｏｎＳｔｏｐｐｅｄ
ｉｖ．ＭＥＳｅｓｓｉｏｎＥｎｄｅｄ
ｖ．ＭＥＳｅｓｓｉｏｎＰａｕｓｅｄ
ｖｉ．ＭＥＭｅｄｉａＲａｔｅＣｈａｎｇｅｄ
【００８４】
ＩＩＩ．メディアベースにおける表示フロー
本セクションは、メディアベースおよびメディアセッションが表示のために何を行うかについての記述とともに、典型的なマルチメディアシナリオの概要を示す。
ａ．メディアベースワーク
i．ソースレゾリューション
このステップにより、マルチメディアデータ読み込み可能なメディアソースを取得する。このステップは、マルチメディアを開くためにＯｐｅｎＵＲＬあるいはＯｐｅｎＢｙｔｅＳｔｒｅａｍが用いられる場合に関するものである。他の開くの機能は直接メディアソースを特定する。
メディアベースはＵＲＬあるいはバイトストリームをソースレゾルバに送る。ソースレゾルバにＵＲＬが与えられると、特定の場所から読み取られるバイトストリームを作成するため、ＵＲＬ（ファイル：／／、ｈｔｔｐ：／／等）のスキームを参照する。
両方のケースにおいて、ソースレゾルバは、バイトストリームのコンテンツにおいて、ビット（ＡＳＦ，ＡＶＩ，ＭＥＰＧ等）の様式を決定することができるため、メディアソースがその様式を理解することを示すことができる。
ｉｉ．メディアセッション設定
メディアソースは表示デスクリプタを求められる。このデスクリプタは、カスタムメディアセッションが用いられることを指定する。これは常にあるケースではなく、通常は、デフォルトのメディアベースメディアセッションがここで示される。
ｉｉｉ．部分トポロジーレゾリューション
メディアベースはメディアソースから表示デスクリプタを取得し、ＭＥＮｅｗＰｒｅｓｅｎｔａｔｉｏｎを通してその表示のアプリケーションを通知する。アプリケーションがそのイベントの取り扱いに関心をもつ場合、メディアベースは、アプリケーションがその取り扱いを終了するのを待つ。
メディアベースは、その後、アプリケーション提示宛先と交渉し、表示の出力用にメディアシンクを作成する。メディアベースは「部分トポロジー」を構築し、部分トポロジーはソースメディアストリームと出力ストリームシンクとを示すが、そこに達する上で必要な変換を必ずしも特定しない。
ｉｖ．トポロジーレゾリューションおよびアクティベーション
メディアベースはメディアセッションに対して部分トポロジーを全特定トポロジーに分解するよう依頼する。その後、メディアベースは、メディアセッション上に新規の全特定トポロジーを設定する。
ｖ．表示制御
アプリケーションは、この時点で、メディアベース上の開始、停止、一時停止を呼び出すことで表示の進展を制御できる。メディアベースはこれらの呼び出しをメディアセッションに転送し、メディアセッションがこれらの呼び出しを取り扱う。
ｖｉ．メディアソースからの新規表示の取り扱い
メディアソースがタイムラインであれば、イベントを通して予定新規表示のメディアセッションを通知し、イベントをメディアベースに転送する。メディアベースはその後、新規表示用のデスクリプタを用いてステップＩＩＩ．ａ．ｉｉｉからＩＩＩ．ａ．ｉｖに移る。その新規表示の再生が開始されようとすると、ＭＥＰｒｅｓｅｎｔａｔｉｏｎＳｗｉｔｃｈがアプリケーションに送信される。
ｖｉｉ．出力変更の取り扱い
出力側の変更について通知するアプリケーション提示宛先からメディアベースがイベントを受信すると、既存表示に対するデスクリプタを用いてステップＩＩＩ．ａ．ｉｉｉからＩＩＩ．ａ．ｉｖに移る。新出力を用いた再生が開始されようとすると、ＭＥＯｕｔｐｕｔｓＵｐｄａｔｅｄがアプリケーションに送信される。
ｂ．メディアセッションワーク
以下に、メディアセッションの主要メディアベースの実行がどのように行われるかの詳細を示す。他のメディアセッションは、上でリストアップ（ＩＩ）されたＡＰＩおよび機能性をもたらさなければならないが、異なる様式で達成する場合もある。
i．全トポロジーレゾリューション
このセッションはトポロジーローダを用いてトポロジーの解決を行うものであるが、これにより、ソースメディアストリームから出力ストリームシンクまでデータを送る上でどの変換が必要であるかを見つけ出す。
ｉｉ．メディアプロセッサ作成
このセッションではメディアプロセッサを所有する。トポロジーがメディアセッションで設定された場合、メディアセッションはメディアプロセッサ上のトポロジーを参照するが、これにより、メディアストリームからストリームシンクで必要とされる様式までのパイプラインを構成する。
ｉｉｉ．時間ソース選定
表示開始時、メディアセッションは、表示を行うために用いられる利用可能な時間ソースがどれであるかの判定を行う。各コンポーネントは、この時間ソースからの時間と同期しながら表示の一部を実行する。
メディアシンクは任意に時間ソースのオファーを行う。典型的には、音響レンダラがこれを行い、時間ソース上の時間がマシン上のオーディオ装置により表示されるが、メディアシンクもまた同様に行ってもよい。メディアソースもまた時間ソースのオファーを行う。メディアセッションは、これらの中のどれが「最優先」の時間ソースであるかを判定するが、この時間ソースは主要表示クロックで用いられ、これに対して全クロック認識コンポーネントがその表示を同期させる。
ｉｖ．表示制御
メディアセッションは、メディアベースからプレロール、開始、終了、一時停止の呼びかけを取得する。典型的には、これらのものはメディアベースに関するアプリケーション呼びかけに対応する。
メディアセッションは、メディアベースが与えた表示クロックを通して表示制御を行う。全メディアシンク以降、表示クロックの開始／停止／一時停止により、全シンクがその通知を受信し、適切に対応する。メディアセッションは、開始／停止／一時停止方法を直接呼び出すことで、メディアプロセッサの開始／停止／一時停止を行う。
メディアセッションは、全ストリームによりある操作が完了した後にメディアベースにイベントを送信する。
ｖ．ビットポンプ
メディアセッションは、メディアプロセッサのストリームからストリームシンクへの全てのデータフローを行う。各メディアシンク−ストリームシンク対は、開始あるいはプレロール状態中に、以下のループで作動するビットポンプに関連付けられる：
１．ストリームシンクからサンプル割り付けを要求
２．サンプル割付要求が満たされた場合、メディアストリームがデータでサンプルを満たすよう要求
３．サンプルを満たす要求が提示された場合、サンプルをストリームシンクに提出し、他のサンプル割り付けを要求
２つ以上のサンプルが、ある時間において「空中」に存在できるということに注意のこと。
ｖｉ．新規表示および出力変更の取り扱い
上記のＩＩＩ．ａ．ｖｉおよびＩＩＩ．ａ．ｖｉｉを参照のこと。メディアセッションは、予定されている表示についてのメディアプロセッサの通知をメディアベースに転送し、トポロジーレゾリューションおよびアクティベーションに参加するという役割をもつ。
【００８５】
ＩＶ．要求される最小限のメディアベース構成
メディアベースが断然、もっとも一般的に用いられるのは、マルチメディア表示の単純な再生を構成する場合である。上の「戦略的重要性」で示されているとおり、メディアベースの重要な目標は、この構成を非常に簡単にすることである。
アプリケーションの視点から、以下のステップでは、メディアベースを用いてマルチメディア表示を構成するため、少なくともアプリケーションが何を行うべきかを記述する。
ａ．メディアベースの作成
ｂ．再生宛先の作成を行い、映像がレンダリング表示されるウィンドウに対するハンドルを提示
ｃ．ＩＭＦＭｅｄｉａＥｎｇｉｎｅ：：ＯｐｅｎＵＲＬを呼び出し、呼び出されるマルチメディアファイルへのＵＲＬおよび再生宛先へのポインタを供給
ｄ．ＩＭＦＭｅｄｉａＥｎｇｉｎｅ：：開始／停止／一時停止ＡＰＩを用いて、メディア表示がここで再生可能である。アプリケーションが何らかのイベント到達を待つ必要はなく、これらのイベントの取り扱いが任意であることに注意のこと。
【００８６】
Ｖ．追加サービスの供給
追加マルチメディアアプリケーションにより、メディアベースおよびメディアセッションで利用可能な広範で拡張可能なサービスアレイの利点が得られる。これについては、メディアベースで表示されるＩＭＦＧｅｔＳｅｒｖｉｃｅインターフェースを用いて評価できるが、メディアベース、メディアセッション、あるいは利用されているメディアソース、シンク、その他のコンポーネントの内の１つで示されるサービスを元に戻す。
このサービス構成は拡張可能であるが、以下に示すのはその一例である：
ａ．速度サポートおよび速度制御
ｂ．音響用音量制御
ｃ．シナリオ編集用フレームキャッシュサポート
ｄ．映像レンダリング構成
【図面の簡単な説明】
【００８７】
前述の概要とともに、以下に示す本発明の実施例の詳細な説明は、添付の図面と関連して読めばさらに理解が深まるであろう。本発明の説明目的のため、好ましいものとして提示された図面実施例が示されている。しかし、理解されるとおり、本発明は、ここで示された詳細な配置や手段に限定されるものではない。
【図１】信頼ベースシステムの例の実施構成を示すブロック図である。
【図２】本発明の観点および／またはその一部が組み込まれた汎用コンピュータシステムを示すブロック図である。
【図３】本発明の１つの実施例によりコンテンツをソースからシンクに供給するため、アプリケーションで呼び出された際にメディアベースによって定義される携帯式メディアパスを示すブロック図である。
【図４】本発明の１つの実施例により、コンテンツをソースからシンクに供給できるかどうかを判定する際に図３の携帯式メディアパスによって実施される主要ステップを示すフロー図である。
【図５】本発明の１つの実施例による、拒絶応答イネーブラをもつソース信頼権限と、イネーブラを受信して作動させるための拒絶応答インターフェースをもつアプリケーションとを含む、図３の携帯式メディアパスの一部を示すブロック図である。
【図６】本発明の１つの実施例によりアクションの実行に対する拒絶に応じて図５の要素によって実施される主要なステップを示すフロー図である。
【図１】
2007509419.tif 000003
【図２】
2007509419.tif 000004
【図３】
2007509419.tif 000005
【図４】
2007509419.tif 000006
【図５】
2007509419.tif 000007
【図６】
2007509419.tif 000008
【国際調査報告】
2007509419.tif 000009