クライアントから要求されるメディアコンテントを提供する提供装置において、前記メディアコンテントを記憶する記憶手段と、前記クライアントから前記メディアコンテントの要求を受信すると共に要求された前記メディアコンテントを提供する通信手段と、前記クライアントからの要求に応答して、前記クライアントから要求されるメディアコンテントを、前記記憶手段から取得する取得手段と、前記メディアコンテントのタイプをトランスコードするトランスコーダと、前記クライアントから要求されたメディアコンテントのタイプを判定する判定手段とを備え、前記トランスコーダは、前記取得手段において取得されたメディアコンテントを、前記判定手段において判定されたタイプのトランスコーダにおいて、トランスコードを実行し、前記通信手段において、前記トランスコーダにおいてトランスコードされたメディアコンテントを、前記クライアントに提供することを特徴とする提供装置。メディアコンテントのタイプは、少なくとも、1メディアコンテントのファイルフォーマット、2メディアコンテントのビットレート、3メディアコンテントを記憶するための圧縮アルゴリズム、4メディアコンテントを転送するための通信プロトコル、5メディアコンテントを記憶する物理メディア、6圧縮アルゴリズム、7デジタル権利管理情報、または、8これらの組み合わせの内一つを含むことを特徴とする請求項1に記載の提供装置。前記クライアントから要求されるタイプは、前記メディアコンテントを再生するソフトウェアによって判定されることを特徴とする請求項1に記載の提供装置。メディアコンテントを記憶する記憶手段と、クライアントから前記メディアコンテントの要求を受信すると共に要求された前記メディアコンテントを提供する通信手段と、前記クライアントからの要求に応答して、前記クライアントから要求されるメディアコンテントを、前記記憶手段から取得する取得手段と、前記メディアコンテントのタイプをトランスコードするトランスコーダと、前記クライアントから要求されたメディアコンテントのタイプを判定する判定手段とを備える提供装置の前記クライアントから要求されるメディアコンテントを提供する提供方法であって、サーバにおいて、前記クライアントからメディアコンテントの要求を、前記通信手段を介して受信する受信ステップと、前記要求に応答して、前記クライアントの要求するメディアコンテントを、前記記憶手段から、取得する取得ステップと、前記クライアントから要求されたメディアコンテントのタイプに従って、取得した前記メディアコンテントをトランスコーダにおいてトランスコードするトランスコードステップと、前記トランスコーダにおいてトランスコードされたメディアコンテントを、前記クライアントに前記通信手段を介して提供する提供ステップとを含むことを特徴とする提供方法。メディアコンテントのタイプは、少なくとも、1メディアコンテントのファイルフォーマット、2メディアコンテントのビットレート、3メディアコンテントを記憶するための圧縮アルゴリズム、4メディアコンテントを転送するための通信プロトコル、5メディアコンテントを記憶する物理メディア、6圧縮アルゴリズム、7デジタル権利管理情報、または、8これらの組み合わせの内一つを含むことを特徴とする請求項4に記載の提供方法。前記クライアントから要求されるタイプは、前記メディアコンテントを再生するソフトウェアによって判定されることを特徴とする請求項4に記載の提供方法。従来のマルチタイプ変換サービスは、コンテントプロバイダがメディアコンテントを公開する前にオフラインで実行され、公開プロセスに望ましくない避けがたい遅延をもたらす。メディアコンテントのリアルタイムトランスコーディング用の構成が既知であるがたとえば、インタネット上でのライブメディアのトランスコーディングおよび供給、このような構成は、それらがメディアコンテントを単一の宛先タイプにしか変換できず、かつメディアコンテントを複数の宛先タイプで供給することができないという点で制限されている。さらに、オフラインマルチフォーマットトランスコーディングサービスはコストがかかるので、コンテントプロバイダはそのメディアコンテントを限られた数の宛先タイプにしか変換できない。変換済みのファイルの宛先タイプに対処できないメディアプレーヤを有するユーザは、このコンテントにアクセスすることができない。したがって、従来のメディア生成は、ユーザが自分のメディアファイルを再生するのにどのメディアプレーヤを用いるかコンテントプロバイダが推測せざるを得ないプッシュプロセスに限られる。メディア公開技術がこのように急速に発展したことのもう1つの結果として、新しいインタネットおよび無線装置製造業者も、新しいメディア再生装置上で様々なコンテントを新しい宛先タイプとして経験できるようにメディアコンテントのトランスコーディングに多額の投資をしなければならない。したがって、新しいインタネットおよび無線装置製造業者は、上述の従来のトランスコーディング方式の欠点と同じ欠点を経験する。本発明の一側面の提供装置は、クライアントから要求されるメディアコンテントを提供する提供装置であって、前記メディアコンテントを記憶する記憶手段と、前記クライアントから前記メディアコンテントの要求を受信すると共に要求された前記メディアコンテントを提供する通信手段と、前記クライアントからの要求に応答して、前記クライアントから要求されるメディアコンテントを、前記記憶手段から取得する取得手段と、前記メディアコンテントのタイプをトランスコードするトランスコーダと、前記クライアントから要求されたメディアコンテントのタイプを判定する判定手段とを備え、前記トランスコーダは、前記取得手段において取得されたメディアコンテントを、前記判定手段において判定されたタイプのトランスコーダにおいて、トランスコードを実行し、前記通信手段において、前記トランスコーダにおいてトランスコードされたメディアコンテントを、前記クライアントに提供することを特徴とする。メディアコンテントのタイプには、少なくとも、メディアコンテントのファイルフォーマット、メディアコンテントのビットレート、メディアコンテントを記憶するための圧縮アルゴリズム、メディアコンテントを転送するための通信プロトコル、メディアコンテントを記憶する物理メディア、圧縮アルゴリズム、デジタル権利管理情報、または、これらの組み合わせの内一つを含ませるようにすることができる。前記クライアントから要求されるタイプは、前記メディアコンテントを再生するソフトウェアによって判定されるようにすることができる。本発明の一側面の提供方法は、メディアコンテントを記憶する記憶手段と、クライアントから前記メディアコンテントの要求を受信すると共に要求された前記メディアコンテントを提供する通信手段と、前記クライアントからの要求に応答して、前記クライアントから要求されるメディアコンテントを、前記記憶手段から取得する取得手段と、前記メディアコンテントのタイプをトランスコードするトランスコーダと、前記クライアントから要求されたメディアコンテントのタイプを判定する判定手段とを備える提供装置の前記クライアントから要求されるメディアコンテントを提供する提供方法であって、サーバにおいて、前記クライアントからメディアコンテントの要求を、前記通信手段を介して受信する受信ステップと、前記要求に応答して、前記クライアントの要求するメディアコンテントを、前記記憶手段から、取得する取得ステップと、前記クライアントから要求されたメディアコンテントのタイプに従って、取得した前記メディアコンテントをトランスコーダにおいてトランスコードするトランスコードステップと、前記トランスコーダにおいてトランスコードされたメディアコンテントを、前記クライアントに前記通信手段を介して提供する提供ステップとを含む。メディアコンテントのタイプには、少なくとも、メディアコンテントのファイルフォーマット、メディアコンテントのビットレート、メディアコンテントを記憶するための圧縮アルゴリズム、メディアコンテントを転送するための通信プロトコル、メディアコンテントを記憶する物理メディア、圧縮アルゴリズム、デジタル権利管理情報、または、これらの組み合わせの内一つを含ませるようにすることができる。前記クライアントから要求されるタイプは、前記メディアコンテントを再生するソフトウェアによって判定されるようにすることができる。本発明の一側面においては、前記メディアコンテントが記憶され、前記クライアントから前記メディアコンテントの要求が受信されると共に要求された前記メディアコンテントが提供され、前記クライアントからの要求に応答して、前記クライアントから要求されるメディアコンテントが、取得され、前記メディアコンテントのタイプがトランスコードされ、前記クライアントから要求されたメディアコンテントのタイプが判定され、取得されたメディアコンテントが、判定されたタイプのトランスコーダにおいて、トランスコードが実行され、トランスコードされたメディアコンテントが、前記クライアントに提供される。本発明は、コンテントプロバイダおよびユーザに対して透過的な方法でメディアコンテントを単一のソースタイプから様々な宛先タイプにオンデマンドで変換するのを可能にするという点で有利である。本発明は、ファイルに記憶されているメディアコンテントを、コンテントプロバイダおよびユーザに対して透過的な方法で単一のソースタイプから様々な宛先タイプにオンデマンドで変換するのを可能にするという点で有利である。本発明の他の利点は、本発明が、コンテントプロバイダおよびユーザに対して透過的な方法でライブすなわち、ストリーミングメディアコンテントを単一のソースタイプから様々な宛先タイプにオンデマンドで変換するのを可能にすることである。本発明の他の利点は、本発明によって、ユーザが、ユーザによって使用されるメディアプレーヤにかかわらず様々な種類のメディアコンテントを再生できることである。本発明の他の利点は、本発明によって、ユーザが、新しいメディアプレーヤをダウンロードしなくても、あるいは既存のメディアプレーヤをアップグレードしなくても所望のメディアコンテントにアクセスできるようになることである。本発明の他の利点は、本発明によって、コンテントプロバイダが単一のソースタイプの最初のメディアコンテントを、様々なメディアコンテントタイプを許容する多様なメディアプレーヤを用いて多数のユーザに与えることができることである。本発明の他の利点は、本発明により、メディアコンテントプロバイダが最初にオフライン符号化サービスを使用することなくメディアコンテントを公開できるようにすることによって、メディアコンテントプロバイダの公開プロセスが容易になることである。したがって、本発明は、メディアコンテントを公開するための市場時間を最短にする。本発明の他の利点は、本発明により、コンテントプロバイダが必要なトランスコーディングタスクを外注し、トランスコーディングに必要なトランスコーディングサーバおよびその他の機器への投資を回避するのを可能にすることによって、メディア公開への参入の障壁が低くなることである。本発明の他の利点は、本発明によって、コンテントプロバイダが、最初のメディアコンテントのソースタイプに対処できないメディアプレーヤを有するユーザにメディアコンテントを供給できることである。本発明の他の利点は、本発明が、特定のメディアプレーヤのユーザによってコンテントが要求されるまでメディアコンテントのトランスコーディングを遅延させることである。したがって、コンテントプロバイダは、最初のメディアコンテントの、ユーザによって要求されていない種類へのトランスコーディングへの不要な投資を回避することができる。本発明の一側面によれば、メディアトランスコーディングエンジン106がメディアコンテントを様々な宛先タイプに変換できるので、コンテントプロバイダは、単一の入力装置を用いてメディアコンテントを供給し、しかも各々が異なる宛先タイプを必要とする様々な異なるメディアプレーヤを用いる視聴者にコンテントを供給することができる。さらに、本発明の一側面によれば、ユーザは、ユーザがどんなメディアプレーヤを使用しているかにかかわらず、それぞれの異なるソースタイプで公開された様々なメディアコンテントにアクセスすることができる。A.発明の概要本発明は、メディア情報を様々なソースタイプから様々な宛先タイプにオンデマンドで変換するシステムおよび方法に関する。本発明によれば、複数のソースタイプから複数の宛先タイプへのトランスコーディングを行うトランスコーダを含むシステムにおいて、メディアコンテントをソースタイプから宛先タイプに変換する方法が提供される。この方法は、メディアコンテントに対するトランスコーダ要求を受信する段階と、メディアコンテントを取り込む段階と、複数のトランスコーダのうちの選択された1つにメディアコンテントを送信する段階とを含んでいる。トランスコーダは、ソースタイプおよび宛先タイプに基づいて選択される。トランスコーダは、メディアコンテントをソースタイプから宛先タイプに変換し、それによって、変換されたメディアコンテントを生成する。次いで、変換されたメディアコンテントは送信される。本発明によるメディアコンテントトランスコーディングシステムは、メディアコンテントをソースタイプから宛先タイプに変換する。トランスコーディングシステムは、ネットワークインタフェースと、リソースマネージャと、送信サーバと、ストリーミングサーバと、複数のソースタイプから複数の宛先タイプへのトランスコーディングを行う複数のトランスコーダとを含んでいる。ネットワークインタフェースは、メディアコンテントに対するトランスコーディング要求を受信する。リソースマネージャは、送信サーバにメディアコンテントを取り込むよう命令する。リソースマネージャは、ソースタイプおよび宛先タイプに基づいて複数のトランスコーダのうちの1つを選択し、選択されたトランスコーダに、メディアコンテントをソースタイプから宛先タイプに変換し、変換されたメディアコンテントを生成するよう命令する。リソースマネージャは、ストリーミングサーバに、変換されたメディアコンテントを送信するよう命令する。次に、本発明について図1乃至7を参照してさらに説明する。B.動作環境図1は、本発明のトランスコーディングシステムの動作環境の一例を示すブロック図である。動作環境例100が例示的な目的にのみ示されており、本発明を制限するものではないことを理解されたい。本明細書に記載された動作環境の他の実現態様は、本明細書に含まれる教示に基づいて当業者に明らかになろう。本発明は、このような他の実現態様に関する。図1を参照すると、動作環境例100は、ビューアクライアント102、コンテントプロバイダクライアント104、メディアトランスコーディングエンジン106、およびネットワーク108を含んでいる。図を明確にするために、ビューアクライアント102およびコンテントプロバイダクライアント104のみが示されている。一般に、本発明のトランスコーディングシステムに任意の数のこれらの構成要素を含めることができる。ビューアクライアント102、コンテントプロバイダクライアント104、およびメディアトランスコーディングエンジン106はすべて、ネットワーク108を介して接続されている。ネットワーク108は、本発明のすべての構成要素を接続するネットワークであり、任意の種類のコンピュータネットワークであっても、回路交換網および/またはパケット交換網ならびに無線網を含むがそれらに限らないネットワークの組合せであってもよい。一例として、ネットワーク108は、インタネットを含む。任意の種類の通信プロトコルを用いてトランスコーディングシステム100の各構成要素間の通信をサポートすることができる。たとえば、TCPIPTransmissionControlProtocolInternetProtocolスイートを用いてリンクを確立することができ、トランスポートデータおよびRTSPRealTimeStreamingProtocolを用いてトランスコーディングシステム100の各構成要素間でデータをストリーミングすることができる。WWWベースのアプリケーション層およびブラウザおよびウェブサーバを用いて、図1に示されている各構成要素間の通信をさらに容易にすることもできる。しかし、これらの例は例示的なものである。本発明は、特定の通信プロトコルまたはアプリケーションに限るものではなく、他の特許されたネットワーク通信プロトコルまたはアプリケーションあるいは特許されていないネットワーク通信プロトコルまたはアプリケーションを使用することができる。ビューアクライアント102は、ユーザまたは視聴者がネットワーク108を介してメディアコンテントを要求して受信し、かつ受信したメディアコンテントを再生するときに用いられる。ある態様では、ビューアクライアント102は、ウェブブラウザと、コンピュータオペレティングシステムの下で動作する1つまたは複数のメディアプレーヤとを含むパーソナルコンピュータである。または、ビューアクライアント102はWEBTV、WINDOWSCE装置、PDAPersonalDigitalAssistant、PALMハンドヘルド装置、ネットワークアクセス機能を有するコンソール器械、MP3器械、メディアコンテントを要求し、受信し、再生することのできる他の任意のクライアント装置および/またはプログラムであってよい。しかし、本発明はこれらの例に限らず、当業者には、様々なクライアント装置およびプログラムを用いてネットワーク108を介したメディアコンテントの要求、受信、再生を行うことができることが理解されよう。本発明は、そのような他のクライアント装置およびプログラムに関する。ビューアクライアント102は、様々な種類のメディアコンテントを受信し再生することができる。たとえば、ビューアクライアント102は、MPEGフォーマット、AVIフォーマット、MP3フォーマット、REALフォーマット、WINDOWSMEDIAフォーマット、QUICKTIMEフォーマット、H263ビデオ符号化フォーマット、およびPALM互換フォーマットを含むがそれらに限らない様々な公知の符号化フォーマットでメディアコンテントを受信し再生することができる。コンテントプロバイダクライアント104は、コンテントプロバイダがネットワーク108を介してメディアコンテントを公開しかつ/または送信するときに使用される。ある態様では、コンテントプロバイダクライアント104は、クライアントワークステーションと、メディア入力装置および/またはプログラムとを含んでいる。たとえば、コンテントプロバイダクライアント104は、接続されたメディア入力装置を有するパーソナルコンピュータを含んでよい。コンテントプロバイダクライアント104は、様々なメディア入力装置およびプログラムを用いてメディアコンテントを供給することができる。たとえば、カメラ8mm、Hi8、または任意のビデオデジタル化装置、ラインイン/マイクロフォン任意のカメラ装置に接続されたものか、またはスタンドアロンオーディオ入力装置、デジタルカメラ、ボイスオーバーイラストレーションを有するスライドショウをアップロードする装置、クライアントが選択したフォーマットですでに符号化されたファイル、またはネットワークアクセス可能なマウントポイントHTTPHypertextTransferProtocol、FTPFileTransferProtocol、リモートサーバなどであるが、それらに限らないを介して得られるファイルを用いてメディアコンテントを供給することができる。これらの例は制限的なものではなく、当業者には、様々なクライアント装置およびプログラムを用いてネットワーク108を介してメディアコンテントを公開しかつ/または送信することができることが理解されよう。本発明はそのようなクライアント装置およびプログラムに関する。コンテントプロバイダクライアント104は様々な種類のメディアコンテントを公開しかつ/または送信することができる。たとえば、コンテントプロバイダクライアント104はMPEGフォーマット、AVIフォーマット、MP3フォーマット、REALフォーマット、WINDOWSMEDIAフォーマット、QUICKTIMEフォーマット、H263ビデオ符号化フォーマット、およびPALM互換フォーマットを含むがそれらに限らない様々な公知の符号化フォーマットでマルチメディアファイルを供給することができる。メディアトランスコーディングエンジン106は、コンテントプロバイダクライアント104とビューアクライアント102との間の媒介として働く。以下に詳しく説明するように、メディアトランスコーディングエンジン106は、ビューアクライアント102からメディアコンテントに対する要求を受信し、要求されたメディアコンテントをコンテントプロバイダクライアント104から得る。メディアトランスコーディングエンジン106は次いで、コンテントプロバイダクライアント104から受信されたメディアコンテントをソースタイプから、ビューアクライアント102によって対処できる宛先タイプに変換し、変換されたメディアコンテントをビューアクライアント102に供給する。メディアトランスコーディングエンジン106は、要求されたメディアコンテントのトランスコーディングおよび供給を、コンテントプロバイダおよびメディアコンテントの視聴者に対して透過的にオンデマンドで行う。本発明によれば、メディアトランスコーディングエンジン106がメディアコンテントを様々な宛先タイプに変換できるので、コンテントプロバイダは、単一の入力装置を用いてメディアコンテントを供給し、しかも各々が異なる宛先タイプを必要とする様々な異なるメディアプレーヤを用いる視聴者にコンテントを供給することができる。さらに、本発明によって、ユーザは、ユーザがどんなメディアプレーヤを使用しているかにかかわらず、それぞれの異なるソースタイプで公開された様々なメディアコンテントにアクセスすることができる。次に、図1のメディアトランスコーディングエンジン106について詳しく説明する。C.本発明のメディアトランスコーディングエンジン図2は、本発明の態様によるメディアトランスコーディングエンジン106のブロック図である。メディアトランスコーディングエンジン106は、ビューアウェブサーバインタフェース202、コンテントプロバイダウェブサーバインタフェース204、タスクマネージャ206、リソースマネージャ208、データベース210、変換済みキャッシュ212、マスタアーカイブ214、マシンファーム216と、マシンファーム216内のトランスコーダサーバ218、送信側サーバ220、およびストリーミングサーバ222を含むいくつかの構成要素で構成されている。メディアトランスコーディングエンジン106の各構成要素はそれぞれ、図2の各構成要素を接続する矢印によって部分的に表される内部コンピュータネットワークによって互いに動作可能に接続されている。コンピュータネットワークは、同じサーバ上に共存する各構成要素を接続する1つまたは複数のコンピュータバスと、回路交換網および/またはパケット交換網ならびに無線網を含むがそれらに限らない各リモート構成要素を接続する任意の他の種類の通信インフラストラクチャとを含んでよい。ある態様では、メディアトランスコーディングエンジン106内で各構成要素を接続するネットワークにはローカルエリアネットワークLANが含まれる。次に、メディアトランスコーディングエンジン106の各構成要素について説明する。コンテントプロバイダウェブサーバインタフェース204は、コンテントプロバイダがメディアコンテントを公開するのを可能にする、メディアトランスコーディングエンジン106とコンテントプロバイダクライアント104との間のネットワークインタフェースである。コンテントプロバイダウェブサーバインタフェース204は、コンテントプロバイダクライアント104からのメディアコンテントの公開を求める要求を受信して処理する。ある態様では、コンテントプロバイダウェブサーバインタフェース204はまた、メディアコンテント自体を、メディアトランスコーディングエンジン106内に保存することを目的としてコンテントプロバイダクライアント104から受信する。または、コンテントプロバイダウェブサーバインタフェース204は、メディアトランスコーディングエンジン106が後で、メディアコンテントを変換しかつ/または視聴者に供給するためにメディアコンテントを見つけて取り込むのを可能にする位置アクセス情報を、コンテントプロバイダクライアント104から受信する。ある態様では、コンテントプロバイダは、コンテントプロバイダクライアント104からコンテントプロバイダウェブサーバインタフェース204へのメディアコンテントの供給を容易にするソフトウェアツールまたはプラグインをコンテントプロバイダウェブサーバインタフェース204からダウンロードすることができる。このツールは、コンテントプロバイダクライアント104上に存在する環境設定可能なインタフェースを構成し、コンテントプロバイダが様々な種類のメディアコンテントをコンテントプロバイダウェブサーバインタフェース204にアップロードするのを可能にする。コンテントプロバイダウェブサーバインタフェース204は、メディアコンテントを受信するか、またはメディアコンテントを取り込むのに必要な位置アクセス情報を受信した後、コンテントプロバイダクライアント104にアドレスソース情報を返す。アドレス情報は、コンテントプロバイダのメディアコンテントを要求している視聴者をメディアトランスコーディングエンジン106に示し、ソース情報は、要求されたメディアコンテントのソースに関する情報を与える。図2に示されているように、本発明のある態様では、アドレスソース情報は、メディアトランスコーディングエンジン106にビューアクライアントを示し、要求されたメディアコンテントのソースに関する情報をメディアトランスコーディングエンジン106に供給するURLUniformResourceLocatorを含んでいる。コンテントプロバイダは、URLをコンテントプロバイダのウェブサイト上のリンクとして知らせることができ、それによって、コンテントプロバイダのウェブサイトにアクセスする視聴者がURLをクリックしてメディアトランスコーディングエンジン106を介してメディアコンテントにアクセスするのを可能にする。ビューアウェブサーバインタフェース202は、視聴者がメディアコンテントを要求し視聴者に供給させるのを可能にする、メディアトランスコーディングエンジン106とビューアクライアント102との間のネットワークインタフェースである。ビューアウェブサーバインタフェース202は、メディアコンテントへのアクセスを求める要求をビューアクライアント102から受信して処理し、それによって、要求されたメディアコンテントの変換およびビューアクライアント102への供給を開始する。変換されたメディアコンテントは、以下に詳しく論じるようにストリーミングサーバおよび/またはプロキシサーバによってビューアクライアント102にストリーミングされるので、ビューアウェブサーバインタフェース202は、ビューアクライアント102に応答を返し、ビューアクライアント102の入出力先を、要求されたメディアコンテントを受信する適切なサーバに変更する。メディアトランスコーディングエンジン106は、要求されたメディアコンテントを最適な宛先タイプでビューアクライアント102に供給するようになっている。ビューアクライアント102の最適な宛先タイプはいくつかの方法で判定することができる。ある態様では、視聴者は、メディアトランスコーディングエンジン106からビューアクライアント102へのメディアコンテントの供給を容易にするソフトウェアツールまたはプラグインをビューアウェブサーバインタフェース202からダウンロードすることができる。このツールは、ビューアクライアント102上で動作し、メディアコンテントを受信し再生するのに最適な、ビューアクライアント102用の宛先タイプを判定するのを助ける。ある態様では、最適な宛先タイプを、ビューアクライアント102上で実行される自動テストによって判定するか、または視聴者にシステム好み情報を明示的に供給するよう求めることによって判定することができる。次いで、最適な宛先タイプは、将来メディアトランスコーディングエンジン106によって参照できるようにソフトウェアツールによってビューアクライアント102上にクッキーとして記憶することができる。または、最適な宛先タイプをメディアトランスコーディングエンジン106内のデータベースに記憶し、ユーザを単純に識別するクッキーをビューアクライアント102上に記憶することができる。次いで、メディアトランスコーディングエンジン106は、メディアコンテントをビューアクライアント102に供給できるように変換することを要求されたときに、クッキーを読み取り、ユーザのIDをデータベースにマップして最適な宛先タイプを得ることができる。他の態様では、最適な環境設定は、より高いレベルのユーザに対して調整可能にすることも、ビューアクライアント102とネットワーク108との間でネットワーク条件が変更される場合たとえば、インタネットサービスプロバイダの変更や接続速度の変更に周期的に更新することもできる。上述のように、コンテントプロバイダウェブサーバインタフェース204およびビューアウェブサーバインタフェース202はそれぞれ、ネットワークインタフェースを含んでいる。ある態様では、コンテントプロバイダウェブサーバインタフェース204およびビューアウェブサーバインタフェース202はそれぞれ、ウェブサーバを含んでいる。他の態様では、コンテントプロバイダウェブサーバインタフェース204およびビューアウェブサーバインタフェース202はそれぞれ、要求の入出力先を他の物理的なウェブサーバに変更する言い換えれば、これらのサーバは仮想ウェブサーバであるロードバランサを含んでいる。タスクマネージャ206は、ビューアウェブサーバインタフェース202から受信されたメディアコンテントに対する要求を処理するメディアトランスコーディングエンジン106の構成要素である。タスクマネージャ206は、メディアトランスコーディングエンジン106が、要求されたメディアコンテントを供給するのに必要なすべての情報を有するかどうかを判定し、欠落している情報を収集し、要求されたメディアコンテントを供給するにはどんなタスクを実行する必要があるかを判定する。タスクマネージャ206は次いで、リソースマネージャ208と対話して必要なタスクを実行する。リソースマネージャ208は、必要なメディアコンテントを供給するのに必要なタスクを実施するたとえば、必要なメディアコンテントを取り込み変換するうえでメディアトランスコーディングエンジン106内でどんなリソースが利用可能であるかを判定し、必要なタスクを適切なリソースに割り当て、次いで各タスクを完了するように管理する。ある意味では、リソースマネージャ208は従来のロードバランサと同様に働く。しかし、従来のロードバランサが、別々のタスクおよび同一のタスクを実行する1組のマシンから成る仮想マシンを管理することによって動作するのに対し、リソースマネージャは、互いに異なり独立したものであることが多い各タスクを分配する。リソースマネージャ208が各タスクを分配しリソースを割り当てるプロセスについて以下に詳しく説明する。図2は、1つのリソースマネージャ208のみを示しているが、当業者には、メディアトランスコーディングエンジン106の他の態様が、メディアトランスコーディングエンジン106内でタスクおよびリソースを割り当てる複数のリソースマネージャを含んでよいことが理解されよう。ある態様では、タスクマネージャ206およびリソースマネージャ208は、メディアトランスコーディングエンジン106内の1つまたは複数の汎用サーバ上で動作するソフトウェアとして実施することができる。マシンファーム216は、要求されたメディアコンテントの、メディアトランスコーディングエンジン106内でのトランスコーディングおよび供給を実行する複数の個々のサーバを含んでいる。マシンファーム216は、要求されたメディアコンテントに関するソースデータを取り込む送信側サーバ220と、ソースデータを適切な宛先タイプに変換するトランスコーダサーバ218と、変換されたメディアコンテントをビューアクライアント102にストリーミングするか、またはビューアクライアント102に供給できるようにプロキシサーバにストリーミングするストリーミングサーバ222とを含んでいる。送信側サーバ220は、送信側サーバ220が、要求されたメディアコンテントをソース位置から取り込み、トランスコーダサーバ218、ストリーミングサーバ222、プロキシサーバ図示せずのうちの1つに送信するのを可能にする送信機ソフトウェアを動作させる。トランスコーダサーバ218は、トランスコーダサーバ218が様々な既知のソースタイプから様々な既知の宛先タイプへのトランスコーディングを行うのを可能にするトランスコーダソフトウェアを動作させる。ある態様では、マシンファーム216は、新しいトランスコーディングサービスを増分的に追加できるようにし、それによって、メディアトランスコーディングエンジン106が新しいメディアタイプに対処できるようにするプラグインアーキテクチャを利用して実施される。本発明の他の態様では、単一のサーバが送信機機能とトランスコーダ機能の両方を実行することができる。他の態様では、要求されたメディアコンテントの送信をメディアトランスコーディングエンジン106の外部のソフトウェアによって行うことができる。たとえば、要求されたメディアコンテントの送信は、コンテントプロバイダクライアント104上に存在するソフトウェアによって実行することができる。ある態様では、マシンファーム216内のストリーミングサーバは、単一のタイプのメディアコンテントの供給専用のタイプ固有のストリーミングサーバである。たとえば、マシンファーム216内のストリーミングサーバは、REALフォーマット、WINDOWSMEDIAフォーマット、QUICKTIMEフォーマットなどの変換されたメディアコンテントの供給専用に使用することができる。マシンファーム216内のストリーミングサーバ222は、既製の業界標準ストリーミングサーバ、すなわち、公開されている標準ストリーミングサーバプログラムまたは特許されたストリーミングサーバプログラムに従って実施されるストリーミングサーバプログラムを動作させることができる。ストリーミングサーバ222は、メディアコンテントをビューアクライアント102にストリーミングするだけでなく、供給されるメディアコンテントと、メディアコンテントが供給される宛先タイプとに関する使用状況統計を維持する。ストリーミングサーバ222は、リソースマネージャ208に使用状況統計を供給し、それによって、リソースマネージャ208がメディアトランスコーディングエンジン106内でキャッシュ管理機能を実行するのを可能にする。たとえば、このような使用状況統計は、リソースマネージャ208が、最も頻繁に要求される変換されたメディアコンテントを最も頻繁に要求される宛先タイプでキャッシュするのを可能にする。変換されたメディアコンテントのキャッシングについては、以下に変換済みキャッシュ212に関して詳しく説明する。他の態様では、ストリーミングメディアコンテントをストリーミングサーバ222からビューアクライアント102に向ける任意のプロキシサーバ図示せずによって使用状況統計の追跡が行われる。このような実現態様は、ストリーミングサーバ222が使用状況統計を追跡できない場合に望ましい。図2に示されているように、マシンファーム216内の各サーバは、サーバとリソースマネージャ208との間のインタフェースとして働くスレーブモニタを含んでいる。スレーブモニタは、リソースマネージャ208からタスクを受信し、サーバ内のタスクを初期設定し、割り当てられたタスクの失敗または完了の報告を含め、初期設定されたタスクのステータスを報告するように動作する。スレーブモニタは、サーバ内の各タスクのステータスを報告することによって、リソースマネージャ208がメディアトランスコーディングエンジン106内のすべてのタスクの実行を管理するのを可能にする。他の態様では、スレーブモニタはリソースマネージャ208から受信されたタスクを開始するに過ぎず、タスク自体がスレーブモニタではなくリソースマネージャ208に直接報告する。データベース210は、リソースマネージャ208がメディアトランスコーディングエンジン106内でのタスクおよびリソースを管理するのを助けるときに使用される。データベース210は、処理中のタスクおよび未処理のタスクのそれぞれのステータスに関する情報と、マシンファーム216内の各リソースのステータスに関する情報を記憶し、それによって、現在リソースマネージャ208が必要なタスクを実行するのに利用できるのはどのリソースかを判定する際にリソースマネージャ208を助ける。データベース210は、タスクマネージャ206が、メディアトランスコーディングエンジン106内に保存されている公開されたメディアコンテントを追跡するときにも使用される。データベース210は、メディアコンテントのID、ソース位置、およびソースタイプが利用可能なときにはそれらを含む、このような公開されたメディアコンテントに関するソース情報を維持する。データベース210は、リレーショナルデータベース、オブジェクト指向データベース、フラットファイルデータベース、または反転リストデータベースを含むがそれらに限らない、データを記憶する技術分野で既知の、任意の種類のデータベース構造を用いて実施することができる。ある態様では、データベース210は、メディアトランスコーディングエンジン106の内部の、1つまたは複数の汎用サーバ、ファイルサーバ、またはネットワークに接続された記憶装置上に記憶することができる。マスタアーカイブ214は、コンテントプロバイダによって公開されコンテントプロバイダウェブサーバインタフェース204によってコンテントプロバイダクライアント104から受信された最初のメディアコンテントを記憶するメディアトランスコーディングエンジン106内のアーカイブである。さらに、メディアトランスコーディングエンジン106がメディアトランスコーディングエンジン106の外部の位置から最初のメディアコンテントを取り込む必要がある場合、メディアトランスコーディングエンジン106は最初のメディアコンテントのコピーをマスタアーカイブ214にキャッシュすることができる。メディアトランスコーディングエンジン106は、最初のメディアコンテントのコピーをマスタアーカイブ214にキャッシュすることによって、後で同じメディアコンテントに対する要求が受信されたときにエンジンの内部ネットワークの外部から最初のメディアコンテントを取り込む必要を無くすことができる。変換済みキャッシュ212は、メディアトランスコーディングエンジン106内のキャッシュである。変換済みキャッシュ212は、メディアトランスコーディングエンジン106が、要求されたメディアコンテントが変換された後にこのメディアコンテントのコピーを記憶するときに使用される。同じ宛先タイプの同じメディアコンテントに対するその後の要求が受信されたときに、メディアトランスコーディングエンジン106は変換済みキャッシュからこのコンテントを供給し、それによって、同じメディアコンテントを反復的に変換するコストのかかるCPUオーバヘッドを回避する。リソースマネージャ208は、マスタアーカイブ214および変換済みキャッシュ212内に何がキャッシュされているかを追跡し、インテリジェントアルゴリズムを用いて各キャッシュの利用状況を管理する。ある態様では、リソースマネージャ208が各キャッシュの利用状況を管理するのに用いるインテリジェントアルゴリズムは、メディアコンテントが様々な宛先タイプで要求される頻度に関する、上述のようにストリーミングサーバ222および/または任意のプロキシサーバ図示せずから受信される使用状況統計に基づくアルゴリズムである。たとえば、ある態様では、リソースマネージャ208はメディアコンテントのあるコピーをキャッシュ内に保持すべきかそれとも破棄すべきかをLRULeastRecentlyUsedアルゴリズムを用いて判定する。LRUアルゴリズムによれば、メディアコンテントのコピーが所与の時間内の数回のアクセスにわたって所定のしきい値を満たさなかった場合、そのメディアコンテントのコピーは破棄される。この例は制限的なものではなく、当業者には、当技術分野で既知の任意の数のインテリジェントアルゴリズムを用いて、マスタアーカイブ214および変換済みキャッシュ212の利用状況を管理できることが理解されよう。このようなインテリジェントアルゴリズムは本発明の範囲および趣旨の範囲内である。ある態様では、マスタアーカイブ214および/または変換済みキャッシュ212は、メディアトランスコーディングエンジン106内の内部ネットワークに結合された、ネットワークに接続された1つまたは複数の記憶装置として実施される。しかし、本発明はこれに限らず、キャッシングソフトウェアを動作させる汎用サーバ、ファイルサーバ、1つまたは複数のディスクアレイ、またはSANStorageAreaNetworkを含むがそれらに限らない任意の適切な記憶装置を用いて、マスタアーカイブ214および/または変換済みキャッシュ212を実施することができる。次に、本発明のある態様による、メディアコンテントを公開する方法およびメディアコンテントにアクセスする方法について説明する。D.本発明のある態様によるメディアコンテントの公開本発明のある態様では、メディアコンテントを符号化ファイルとして公開することも、ライブオーディオやビデオフィードのような連続的なデータストリームとして供給することもできる。図3は、メディアコンテントが符号化されたメディアファイルである、本発明のある態様による、メディアコンテントを公開する方法のフローチャート300である。しかし、本発明はフローチャート300によって与えられる説明に限らない。当業者には、本明細書の教示から、他の機能フローも本発明の範囲および趣旨の範囲内であることが明らかになろう。段階302で、コンテントプロバイダは、コンテントの公開を求める要求をコンテントプロバイダクライアント104からコンテントプロバイダウェブサーバインタフェース204に送信する。ある態様では、この要求はHTTP要求を含んでいる。段階304で、コンテントプロバイダウェブサーバインタフェース204は、メディアコンテント自体またはメディアコンテントを取り込むのに必要な位置アクセス情報を求めるプロンプトをコンテントプロバイダクライアント104に送信する。上述のように、本発明のある態様によれば、コンテントプロバイダは、メディアコンテントをメディアトランスコーディングエンジン106内に保存することも、コンテントプロバイダ自体のサーバのようなメディアトランスコーディングエンジン106の外部の他の位置にメディアコンテントを記憶することもできる。段階306に示されているように、コンテントプロバイダが、符号化されたメディアファイルをメディアトランスコーディングエンジン106内のアーカイブに記憶したい場合、コンテントプロバイダは、このメディアファイルをコンテントプロバイダクライアント104を介してコンテントプロバイダウェブサーバインタフェース204に供給する。段階308で、コンテントプロバイダウェブサーバインタフェース204は、符号化されたメディアファイルを情報した後、このファイルをメディアトランスコーディングエンジン106内に保存できるようにマスタアーカイブ214に送信する。符号化されたファイルは、マスタアーカイブ214から、リソースマネージャ208およびメディアトランスコーディングエンジン106の他の構成要素によって利用することができる。段階310で、保存されたファイルのIDおよび位置がコンテントプロバイダウェブサーバインタフェース204によってタスクマネージャ206に報告され、タスクマネージャ206はこの情報を将来参照できるようにデータベース210内に記憶する。ある態様では、保存されたファイルのソースタイプも将来参照できるようにデータベース210内に記憶される。段階312に示されているように、コンテントプロバイダが、符号化されたファイルをメディアトランスコーディングエンジン106の外部の他の位置に記憶したい場合、コンテントプロバイダは、符号化されたメディアファイルに必要な位置アクセス情報をコンテントプロバイダクライアント104を介してコンテントプロバイダウェブサーバインタフェース204に供給する。段階316で、コンテントプロバイダウェブサーバインタフェース204は、符号化されたメディアファイル、または符号化されたメディアファイルと取り込むのに必要な位置アクセス情報を受信した後、コンテントプロバイダクライアント104にアドレスソース情報を供給する。アドレス情報は、コンテントプロバイダのメディアコンテントを要求している視聴者をメディアトランスコーディングエンジン106に示し、ソース情報は、要求されたメディアコンテントのソースに関する情報を与える。符号化されたメディアファイルがメディアトランスコーディングエンジン106の外部の他の位置に記憶される場合、ソース情報は、先の段階312でコンテントプロバイダによって与えられた位置アクセス情報を含む。ある態様では、アドレスソース情報は、メディアトランスコーディングエンジン106にビューアクライアント102を示し、要求されたメディアコンテントのソースに関する情報をメディアトランスコーディングエンジン106に与えるURLUniformResourceLocatorを含んでいる。コンテントプロバイダは、URLをコンテントプロバイダのウェブサイト上のリンクとして知らせることができ、それによって、コンテントプロバイダのウェブサイトにアクセスする視聴者がURLをクリックしてメディアトランスコーディングエンジン106を介してメディアコンテントにアクセスするのを可能にする。段階316で、フローチャート300は終了する。図4は、メディアコンテントがライブオーディオまたはビデオフィードの場合のように連続的なデータストリームとして供給される、本発明のある態様による、メディアコンテントを公開する方法のフローチャート400である。しかし、本発明は、フローチャート400によって与えられる説明に限らない。当業者には、本明細書の教示から、他の機能フローも本発明の範囲および趣旨の範囲内であることが明らかになろう。段階402で、コンテントプロバイダは、ストリーミングメディアコンテントの公開を求める要求をコンテントプロバイダクライアント104からコンテントプロバイダウェブサーバインタフェース204に送信する。ある態様では、この要求はHTTP要求を含んでいる。段階404で、コンテントプロバイダウェブサーバインタフェース204は、ストリーミングメディアコンテントを求めるプロンプトをコンテントプロバイダクライアント104に送信する。段階406に示されているように、コンテントプロバイダは、メディアコンテントをコンテントプロバイダクライアント104を介してコンテントプロバイダウェブサーバインタフェース204に連続的にストリーミングする。段階410で、コンテントプロバイダウェブサーバインタフェース204は、ストリーミングメディアコンテントを受信した後、コンテントプロバイダクライアント104にアドレスソース情報を供給する。アドレス情報は、コンテントプロバイダのメディアコンテントを要求している視聴者をメディアトランスコーディングエンジン106に示し、ソース情報は、要求されたメディアコンテントのソースに関する情報を与える。ある態様では、アドレスソース情報は、メディアトランスコーディングエンジン106にビューアクライアント102を示し、要求されたメディアコンテントのソースに関する情報をメディアトランスコーディングエンジン106に与えるURLUniformResourceLocatorを含んでいる。コンテントプロバイダは、URLをコンテントプロバイダのウェブサイト上のリンクとして知らせることができ、それによって、コンテントプロバイダのウェブサイトにアクセスする視聴者がURLをクリックしてメディアトランスコーディングエンジン106を介してメディアコンテントにアクセスするのを可能にする。段階410で、フローチャート400は終了する。次に、本発明のある態様による、視聴者が公開されたメディアコンテントにアクセスする方法について説明する。E.本発明のある態様によるメディアコンテントのアクセス本明細書で説明するように、本発明のある態様は、メディアコンテントへのアクセスを求める視聴者の要求に応答して、メディアコンテントのトランスコーディングをオンデマンドで実行する。さらに、本発明のある態様は基本的に、メディアコンテントが公開された後に、メディアコンテント供給プロセスの一部として、メディアコンテントのリアルタイムのトランスコーディングを実行する。本発明の特定の態様では、メディアコンテントを見ることを求める要求がメディアトランスコーディングエンジン106に送信されしからメディアコンテントがビューアクライアント102に供給されるまでの遅延は約30秒以下である。しかし、本発明は、特定の供給時間に限らず、30秒よりも長いかまたは短い様々な供給時間を包含することができる。図5は、本発明のある態様による、視聴者がメディアコンテントにアクセスする方法のフローチャート500である。しかし、本発明は、フローチャート500によって与えられる説明に限らない。当業者には、本明細書の教示から、他の機能フローも本発明の範囲および趣旨の範囲内であることが明らかになろう。段階502で、視聴者は、メディアコンテントへのアクセスを求める要求をビューアクライアント102を介してメディアトランスコーディングエンジン106内のビューアウェブサーバインタフェース202に送信する。ある態様では、この要求は、視聴者がコンテントプロバイダのウェブサイト上のURLをクリックしたときにビューアクライアント102によって生成されるHTTP要求である。上述のように、URLリンクは、メディアコンテント公開プロセス中にメディアトランスコーディングエンジン106からコンテントプロバイダに供給できるリンクであり、メディアトランスコーディングエンジン106にビューアクライアント102を示し、要求されたメディアコンテントのソースに関する情報をメディアトランスコーディングエンジン106に与えるアドレス情報およびソース情報を含んでいる。ビューアウェブサーバインタフェース202は、要求を受信した後それをタスクマネージャ206に転送する。段階504で、タスクマネージャ206は要求を解析し、要求を満たすのに必要な要求情報が含まれているかどうかを判定する。要求がHTTP要求を含む本発明のある態様では、タスクマネージャ206はHTTP要求のヘッダを解析して、要求を満たすのに必要な要求情報が含まれているかどうかを判定する。ある態様では、必要な情報には、少なくともソース位置、ソースタイプ、宛先位置、および宛先タイプが含まれる。ソースタイプと宛先タイプはそれぞれ、少なくとも1つの公開変数によって定義される。ある態様では、メディアコンテントの公開変数には、ファイルフォーマット、ビットレート、通信プロトコル、物理媒体、圧縮アルゴリズム、デジタル権利管理情報、またはそれらの組合せを含めることができるが、それらに限らない。一態様では、要求を満たすのに必要な情報には、少なくともソース位置、ソースフォーマット、ソースビットレート、宛先位置、宛先フォーマット、および宛先ビットレートが含まれる。タスクマネージャ206は、要求情報が完全ではないと判定した場合、段階506および508に示されているように必要な情報を取り込む。たとえば、要求にソースタイプまたはソース位置が含まれておらず、要求されたメディアコンテントがメディアトランスコーディングエンジン106内に記憶されている場合、タスクマネージャ206はデータベース210に問い合わせて必要なソース情報を見つける。または、メディアコンテントがメディアトランスコーディングエンジン106に対して外部に記憶されている場合、タスクマネージャ206はネットワーク要求を実行してコンテントプロバイダのウェブサイトから必要な情報を取り込む。たとえば、タスクマネージャ206は、HTTP要求、RTSP要求、または他の任意の標準ネットワークアプリケーションプロトコルを用いた要求を実行することができる。さらに、宛先タイプが得られない場合、タスクマネージャ206は、ビューアクライアント102に問い合わせることによって必要な情報を取り込むことができる。上述のように、ある態様では、宛先位置に最適な宛先タイプを、タスクマネージャ206からアクセスできるビューアクライアント102上に、クッキーとして記憶することができる。段階510で、タスクマネージャ206は、要求を満たすのに必要な情報を得た後、要求されたメディアコンテントを供給するにはどんなタスクを実行する必要があるかを判定する。このタスクには、必要なメディアコンテントを供給するのに必要なすべての段階が含まれ、必要なメディアコンテントを取り込む段階と、必要なメディアコンテントをソースタイプから宛先タイプに変換する段階と、変換されたメディアコンテントをビューアクライアント102にストリーミングする段階とを含めることができる。タスクマネージャ206は、どんなタスクを実行する必要があるかを判定した後、リソースマネージャ208とのインタフェースをとり、リソースマネージャ208に必要なタスクを実行するよう指示する。リソースマネージャ208は、この指示を受信してタスクマネージャ206からの必要なタスクを実行し、段階512で、マシンファーム216内の1つまたは複数のマシンに各タスクを割り当てる。リソースマネージャ208は、利用可能なリソースによって各タスクを効率的に実行するようにプログラムされている。ある態様では、リソースマネージャ208による所与のタスクへのリソースの割当ては、必要なタスクを実行するのに必要なユーティリティをサポートするのはどのマシンか、利用可能なリソースたとえば、利用可能なCPUを有するのはどのマシンか、およびタスクの実行に関してマシンの調整が必要なときにタスクを実行するにあたって互いに調整できるのはどのマシンかを含むがそれらに限らない様々な因子に基づいて決定される。リソースマネージャ208は、ネットワーク輻輳の回避を含む、他の様々な基準に基づいてタスクを分散させるようにプログラムすることもできる。たとえば、リソースマネージャ208は、未圧縮データをメディアトランスコーディングエンジン106の内部ネットワーク内のあるマシンから他のマシンに送信する結果として起こるネットワーク輻輳を回避するために解凍および圧縮を同じマシンに割り当てるようにプログラムすることもできる。本発明によれば、リソースマネージャ208は、タスクが割り当てられた後でそれらを監視し、それらが適切な実行されていることを確認する。リソースマネージャ208は、すべての割り当てられたタスクのリストをデータベース210内に維持し、所与のタスクを動作させる各マシンのスレーブモニタと定期的に通信してタスクのステータスを判定することによって、割り当てられたタスクの実行を監視する。ある態様では、リソースマネージャ208は、タスクが割り当てられたマシンのスレーブモニタを定期的にポーリングし、タスクのステータスを判定する。他の態様では、スレーブモニタ自体がリソースマネージャ208に定期的なステータスメッセージを送信し、割り当てられたタスクのステータスをリソースマネージャ208に知らせる。リソースマネージャ208は、それがスレーブモニタから情報した、各タスクおよび各マシンのステータスに関する情報をデータベースに記憶し、必要なタスクを割り当て監視するリソースマネージャ208の機能を助ける。本発明の他の態様では、スレーブモニタはリソースマネージャ208から受信されたタスクを開始するに過ぎず、タスク自体がスレーブモニタではなくリソースマネージャ208に直接報告する。リソースマネージャ208は、それ自体が、タスクの失敗時にそのことを判定し、問題を解消し要求されたメディアコンテントを確実に供給する必要な段階を実行するのを可能にするフォールトトレランスルーチンに従って、割り当てられた各タスクを監視する。たとえば、タスクが割り当てられているマシンが所定の期間にわたってステータス問合せに応答しない場合、そのタスクを異なるマシンに割り当て直し、応答しないマシンを再ブートするようにリソースマネージャ208をプログラムすることができる。さらに、タスクが失敗した結果、分配された互いに独立したタスクのチェーンに障害が起こった場合、すべての独立したタスクをシャットダウンし、1組のタスク全体を割り当て直して、必要なメディアコンテントを確実に供給するようにリソースマネージャ208をプログラムすることができる。これらの例は制限的なものではなく、当業者には、本明細書に含まれる教示に基づいて他のフォールトトレランス方式が明らかになろう。本発明はそのような他のフォールトトレランス方式に関する。本発明の他の態様では、個々のタスクにそれぞれ優先順位が割り当てられる。リソースマネージャ208は、新しいタスクを監視し、既存のタスクの優先順位が、割り当てる必要のある新しいタスクの優先順位よりも低くなったときに、既存のタスクにそれ自体を消去するよう指示し、新しいより高い優先順位のタスクを受け入れる。または、スレーブモニタが既存のタスクを消去することができる。低優先順位のタスクの例には、視聴者が要求されたコンテントを見るのを停止した後の、視聴者用のメディアコンテントのトランスコーディングが挙げられる。段階514で、すべてのタスクが割り当てられた後、タスクマネージャ206は、ビューアクライアント102から受信されたメディアコンテントへのアクセスを求める初期要求への応答を作成する。この応答は、ビューアクライアント102に対する、ビューアクライアント102の入出力先を、要求されたメディアコンテントの最終的な送信元であるストリーミングサーバまたはプロキシサーバに変更する働きをする。ある態様では、この応答はHTTP応答を含んでいる。段階516乃至526で、マシンファーム216内の各マシンは、リソースマネージャ208から受信された割り当てられたタスクに従って、要求されたメディアコンテントを供給するのに必要な段階を実行する。本発明のある態様では、メディアコンテントの供給は、同じメディアコンテントストリームのそれぞれの異なる部分の取込み、トランスコーディング、およびストリーミングを同時に行うことのできるパイプライン化プロセスである。リソースマネージャ208は、メディアトランスコーディングエンジン106内のリソース割当てを通じて、これらの段階のパイプライン化を準備する。これらの段階をパイプライン化することにより、メディアトランスコーディングエンジン106による要求されたメディアの供給時間が短縮される。段階516に示されているように、要求されたメディアコンテントがすでに、適切な宛先タイプたとえば、適切な宛先フォーマットおよびビットレートまたは他の適切な公開変数に変換された変換済みキャッシュ212に存在している場合、コンテントの供給は、変換されたメディアコンテントを後述のようにビューアクライアント102にストリーミングするストリーミングサーバ222によって、段階524で行われる。しかし、要求されたメディアコンテントが、適切な宛先タイプに変換された変換済みキャッシュ212に存在しない場合、段階518に示されているように、マシンファーム216内の送信側サーバ220の1つが、データストリームとしての要求されたメディアコンテントの、ソース位置からの取込みを開始する。上記に図3および4に関して論じたように、本発明のある態様では、要求されたメディアコンテントは、最初からメディアトランスコーディングエンジン106内のマスタアーカイブ214内、またはメディアトランスコーディングエンジン106の外部のアーカイブ内に存在することも、コンテントプロバイダクライアント104から直接得られるストリーミングフィードとして受信することもできる。要求されたメディアコンテントがマスタアーカイブ214内に存在する場合、送信側サーバ220の1つが、要求されたメディアコンテントをメディアトランスコーディングエンジン106の内部ネットワークを介して取り込む。要求されたメディアコンテントがメディアトランスコーディングエンジン106の外部のアーカイブに存在する場合、送信側サーバ220のうちの1つが、公開プロセス中に供給されたアクセス情報を用いて、要求されたメディアコンテントを取り込む。ある態様では、送信側サーバがアクセス情報を用いて、要求されたメディアコンテントを取り込んだ後、要求されたメディアコンテントを一時的にマスタアーカイブ214にキャッシングすることができ、同じメディアコンテントに対するその後の要求がメディアトランスコーディングエンジン106によって受信されたときにメディアコンテントへの高速のアクセスが可能になる。要求されたメディアコンテントがコンテントプロバイダクライアント104から直接得られるストリーミングフィードである場合、送信側サーバ220のうちの1つがコンテントプロバイダウェブサーバインタフェース204からストリーミングデータを取り込む。本発明のある態様では、ストリーミングデータが視聴者によって実際に要求されるまでストリーミングデータを取り込んで変換することは行われないため、それによってメディアコンテントの不要なトランスコーディングが回避される。段階520に示されているように、送信側サーバが、要求されたメディアコンテントの取込みを開始した後、ソースタイプが宛先タイプと同じであるたとえば、ソースフォーマットおよびビットレートが宛先フォーマットおよびビットレートと同じである場合、トランスコーディングは不要であり、メディアコンテントは、取り込まれた直後にストリーミングサーバ222に送信される。ストリーミングサーバ222は次いで、後述のように段階524でビューアクライアント102にコンテントをストリーミングする。しかし、ソースタイプが宛先タイプと同じである場合、段階522に示されているように、マシンファーム216内のトランスコーディングサーバ218のうちの1つがメディアコンテントをソースタイプから宛先タイプに変換する。上記に段階512に関して論じたように、リソースマネージャ208は、公開変数の適切な変換を実行するのに必要なトランスコーダソフトウェアを動作させるトランスコーダサーバにトランスコーディングタスクを割り当てる。ある態様では、トランスコーディングは、メディアコンテントを変換する従来のコーデックルーチンを含む、ある種類のメディアコンテントを他の種類のメディアコンテントに変換する様々な公知の方法を使用して行われる。ある態様では、トランスコーディングが完全である場合、変換されたメディアコンテントのコピーは一時的に変換済みキャッシュ212に記憶され、同じ宛先タイプに変換された同じメディアコンテントに対するその後の要求がメディアトランスコーディングエンジン106によって受信されたときにメディアコンテントを高速に供給することができる。段階524で、ビューアクライアント102に対する適切な宛先タイプのメディアコンテントがトランスコーダ、送信機、または変換済みキャッシュ212から受信された直後に、ストリーミングサーバ222のうちの1つがメディアコンテントをストリーミングする。ある態様では、上記に図2に関して論じたように、変換されたメディアコンテントは任意のプロキシサーバを介してビューアクライアント102にストリーミングされる。他の態様では、ストリーミングサーバまたは任意のプロキシサーバは、供給されるメディアコンテントと、リソースマネージャ208がキャッシュを管理するのに用いる、メディアコンテントが供給される宛先タイプとに関する使用状況統計を維持する。ある態様では、ビューアクライアント102へのストリーミングメディアおよび送信側サーバ220とトランスコーダサーバ218とストリーミングサーバ222との間のストリーミングデータに用いられるプロトコルは、RTSPのような、ストリーミングメディア用の標準プロトコルである。または、TCPUDPのような標準ネットワークプロトコルを介して定義された特許されたプロトコルを使用することができる。他の態様では、様々なプロトコルを用いてネットワークインフラストラクチャのそれぞれの異なるニーズに対処することができる。たとえば、ネットワークトラフィック条件に応じて動的に変換するプロトコルを実施することができる。しかし、これらの例は例示的なものである。本発明は、特定の通信プロトコルまたはアプリケーションに限るものではなく、他の特許されたネットワーク通信プロトコルまたはアプリケーションあるいは特許されていないネットワーク通信プロトコルまたはアプリケーションを使用することができる。段階526で、ビューアクライアント102は、ストリーミングサーバまたはプロキシサーバからストリーミングメディアを受信する。この点で、ビューアクライアント102は、ビューアクライアント102上に存在するメディアプレーヤに関連する宛先タイプに応じてメディアコンテントを再生する。本発明の他の態様では、メディアコンテントを受信し、後で再生するか、または他のメディア再生装置に転送することができるように、ビューアクライアント102上のダウンロードされたファイルとして記憶することができる。段階526で、フローチャート500は終了する。F.他のトランスコーダ動作およびメディアコンテントの例上述のように、メディアトランスコーディングエンジン106は1つまたは複数のトランスコーダ218を含んでいる。トランスコーダ218はある種類のメディアコンテント本明細書ではソースタイプと呼ぶから他の種類のメディアコンテント本明細書では宛先タイプと呼ぶに変換する。トランスコーディングにはいくつかの異なる変換動作を含めることができる。使用される特定の変換動作は、変換されるメディアコンテントおよび関連する公開変数に依存する。本明細書で使用される公開変数とは、メディアコンテントの様々な特性を指す。本発明によれば、メディアコンテントはネットワーク上で公開されるデジタルデータである。この場合、公開対象は、ネットワーク上で供給しかつ宛先メディアプレーヤによって表示することができるようにフォーマットされたデジタルデータを指す。メディアコンテントの公開変数には、ファイルフォーマット、ビットレート、通信プロトコル、物理媒体、圧縮アルゴリズム、および/またはデジタル権利管理情報を含めることができるがそれらに限らない。デジタルデータは、コンテナフォーマット、ビットマップフォーマット、ビデオフォーマット、オーディオフォーマット、ベクトルフォーマット、メタファイルフォーマット、シーンフォーマット、アニメーションフォーマット、マルチメディアフォーマット、ハイブリッドフォーマット、ハイパーテキストフォーマットおよびハイパーメディアフォーマット、三次元データ3Dフォーマット、VRMLVirtualRealityModelingLanguageフォーマット、フォントフォーマットビットマップフォント、ストロークフォント、スプラインベースのアウトラインフォント、ページ記述言語PDLフォーマット、ならびに任意の他の種類のグラフィックスファイルフォーマットまたは他のファイルフォーマットを含むがそれらに限らない任意の種類のファイルフォーマットであってよい。表1に、本発明のある態様で使用できるそのようなファイルフォーマットの例をリストする。表1ファイルフォーマット例MurrayおよびvanRyperの12ページ乃至26ページを参照されたい。これらの例は例示的なものであり、必ずしも本発明を制限するものではない。この説明を読んだ当業者には明らかなように現在既知であるかまたは将来開発される他のファイルフォーマットを使用することができる。同じファイルフォーマット内でも、様々な圧縮アルゴリズムに従ってデジタルデータを圧縮することができる。たとえば、QUICKTIMEフォーマットファイルでは、H263標準、CINEPAK標準、JPEG標準、QTANIMATION標準、またはQTVIDEO標準に従ってビデオデータを圧縮することができる。他の例として、WINDOWSMEDIAASFフォーマットファイルでは、MICROSOFTAUIDOFORMAT標準、ACELP標準、VOXWARE標準、またはMP3標準に従ってオーディオを圧縮することができる。圧縮アルゴリズムの選択は、ビットレートの選択に応じるか、またはコンテントの性質に応じて、最適化に基づいて行うことができる。たとえば、ほとんど動きのないビデオファイルトーキングヘッドおよび実質的な量の動きがあるビデオファイルハイモーションビデオはそれぞれ、異なる圧縮アルゴリズムを用いてより効率的に圧縮することができる。任意の1つの圧縮アルゴリズム内に、さらなる変形例があってよい。たとえば、JPEG標準に従って圧縮されるファイルは、YUBベースであっても、RGBベースであってもよい。上記に記載された公開変数だけでなく、ビデオデータおよびオーディオデータに固有の公開変数もある。ビデオデータ用の公開変数には、画素単位のビデオ画像の幅および高さと、ビデオのフレームレートが含まれる。ビットレート要件およびデータの性質に応じて、最高の画質を得るには様々な設定が必要である。たとえば、ビットレートは同じであっても、ある種のビデオは、160x120画素で毎秒15フレームで表示した方が高い画質が得られるが、他のビデオは320x240画素で毎秒5フレームで表示した方が高い画質が得られる。ビットレートが56Kbpsである場合、画質は非常に制限され、640x480画素の解像度でビデオを供給しても最適な画質が得られることはめったにない。ビデオデータ用の他の公開変数は1構成要素当たりビット数である。オーディオデータ用の公開変数には、毎秒サンプル数、チャネル数たとえば、モノ、ステレオ、5チャネル、およびサンプルサイズ8ビット、16ビットなどが含まれる。特定のコンテントタイプおよびビットレートに考慮してオーディオ品質を確保するには様々な設定が必要である。公開変数には、送信されるデータパケットのサイズおよび送信プロトコルの選択たとえば、TCPかそれともUDPを含めてもよい。図6は、ソースタイプメディアコンテント610を宛先タイプメディアコンテント650にオンデマンドで変換するトランスコーダ例218を示している。ソースタイプメディアコンテント610は、ネットワーク上で1つまたは複数のパケットで供給されるデジタルデータである。ソースタイプメディアコンテント610を形成するデジタルデータは、1つまたは複数の公開変数によって定義される。図6に示されている公開変数には、以下の変数、ソースファイルフォーマット、ソースビットレート、ソース物理媒体、ソース通信プロトコル、ソース符号化、またはそれらの任意の組合せのうちの1つまたは複数が含まれる。宛先タイプメディアコンテント650は、メディアコンテントを要求しているエンドユーザにネットワーク上で1つまたは複数のパケットで供給されるデータである。宛先タイプメディアコンテント650を形成するデジタルデータは、1つまたは複数の公開変数によって定義される。図6に示されている公開変数には、以下の変数、宛先ファイルフォーマット、宛先ビットレート、宛先物理媒体、宛先通信プロトコル、宛先符号化、またはそれらの任意の組合せのうちの1つまたは複数が含まれる。図7は、1つまたは複数のトランスコーダ218がソースタイプメディアコンテント710から第1の宛先タイプ750へのオンデマンドのトランスコーディングを行う実現態様例の表である。図7は、1つまたは複数のトランスコーダ218がソースタイプメディアコンテント710から第2の宛先タイプ760へのオンデマンドのトランスコーディングを行う実現態様例も示している。ソースタイプメディアコンテント710は、以下のソース公開変数に従って公開されるデジタルデータを含んでいる。すなわち、物理媒体はローカルディスクであり、通信プロトコルはファイル入出力を含み、ファイルフォーマットは毎秒128キロバイトkbpsのビットレートでのMP3符号化を用いるMP3である。第1の宛先タイプメディアコンテント750は、以下の宛先公開関数に従って公開できるように変換されたデジタルデータを含んでいる。すなわち、物理媒体はパケット交換網インタネットであり、通信プロトコルはWINDOWSMEDIASTREAMINGMMSプロトコルを含み、ファイルフォーマットは、56kbpsのビットレートでMP3符号化を用いるWINDOWSMEDIAFILEである。第2の宛先タイプメディアコンテント760は、以下の宛先公開関数に従って公開できるように変換されたデジタルデータを含んでいる。すなわち、物理媒体は無線網であり、通信プロトコルはHTTPを含み、ファイルフォーマットは、12kbpsのビットレートでのMP3符号化を含むMP3である。他の例は以下の表に示されている。表2乃至5トランスコーダ動作例表2表3表4表5これらの例は例示的なものであり、本発明を制限するものではない。この説明を読んだ当業者には明らかなように、現在既知であるかまたは将来開発される他の種類のオンデマンドトランスコーディング動作を使用することができる。G.本発明の他の態様本明細書では、本発明の方法およびシステムの態様例について説明した。他の個所で指摘したように、これらの態様例は、例示的な目的にのみ記載されており、制限的なものではない。当業者には、本明細書で説明した態様とわずかに異なるかまたは実質的に異なる他の態様が、本明細書に含まれる教示に基づいて明らかになろう。たとえば、当業者には、本発明のトランスコーディングシステムおよび方法がメディアコンテントのみのトランスコーディングおよび供給に限らず、圧縮ファイル、電子ドキュメント、HTMLページ、XMLドキュメント、および複数のフォーマットで記憶し電子的に供給することのできる他の任意の情報を含むがそれらに限らないすべての種類の情報のトランスコーディングおよび供給も包含することが理解されよう。他の態様には、本発明の方法、システム、および構成要素のハードウェア実現態様、ソフトウェア実現態様、およびソフトウェア/ハードウェア実現態様が含まれるがそれらに限らない。このような他の態様は、本発明の範囲および趣旨の範囲内である。H.結論上記には本発明の様々な態様について説明したが、これらの態様が一例としてのみ示されており、制限として示されているのではないことに理解されたい。当業者には、添付の特許請求の範囲に定義された本発明の趣旨および範囲から逸脱せずに各態様の形態および詳細に様々な変更を加えられることが理解されよう。したがって、本発明の範囲は、上述の例示的な態様によって制限されるべきではなく、添付の特許請求の範囲およびその均等物に従ってのみ定義すべきである。