JP2008269614A - 提供装置および方法 - Google Patents

Abstract

【課題】メディア・コンテントをキャッシングするのを可能にし、システム効率を高める。
【解決手段】システムが、複数のソース・タイプ（208）からのトランスコーディングを行う複数のトランスコーダ（218）を含み、メディア・コンテントに対するトランスコーディング要求を受信し、トランスコーディング要求に応答してメディア・コンテントを取り込み、ソース・タイプ（208）および宛先タイプに基づいて複数のトランスコーダのうちの1つにメディア・コンテントを送信し、それによって、変換されたメディア・コンテントを生成し、変換されたメディア・コンテントが提供される。本発明は、例えば、メディア・コンテントのトランスコーディング・システムに適用することができる。
【選択図】図２

Description

本発明は、情報を変換する提供装置および方法に関する。具体的には、本発明は、メディア・コンテントを変換する提供装置および方法に関する。

人類の歴史においては常にメディア・コンテントの迅速な公開が追及されている。公開者はメディア・コンテントをより多くの視聴者により高速に供給するよう努力している。本明細書では、語「メディア・コンテント」は、オーディオ、ビデオ、データ、概念、画像、物語、音声、テキスト、または人間の1つまたは複数の感覚によって知覚されるその他のコンテントを含む任意の情報を指す。

今や、メディア・コンテントのデジタル表現とコンピューティング技術およびネットワーク化技術が組み合わされることによって、効果的な公開方法が実現されている。この新しい公開モードによれば、ネットワーク化技術は、デジタル化されたメディア・コンテントをネットワーク上でエンド・ユーザ・コンピュータに供給するのを可能にする。通信プロトコルは、デジタル化されたメディア・コンテントをネットワーク上でどのように交換するかを定義する。メディア・プレーヤは、エンド・ユーザ・コンピュータ上で動作し、ユーザがメディア・コンテントを再生するかまたはその他の方法で経験するのを可能にする。

メディア・コンテントのデジタル表現には様々な種類のものがある。これらの種類は一般に、メディア・コンテントに関連するファイル・フォーマット、ビット・レート、通信プロトコル、物理メディア、圧縮アルゴリズム、および／またはデジタル権利管理情報を含むことができるがそれらに限らない一連の公開変数によって定義される。使用されるデジタル化メディア・コンテントの種類は、公開プロセスに用いられるコンピューティングおよび／またはネットワーク化技術やコンテント自体の性質のようないくつかの因子に依存する。

たとえば、多くの種類のデジタル化メディア・コンテントがファイル・フォーマットによって定義されている。一般的なファイル・フォーマットには、QUICK TIME、MPEG、AVI、MP3、REAL、WINDOWS MEDIA、H.263ビデオ符号化、およびPALM互換フォーマットが含まれる。フォーマットはメディア・コンテントをファイルとしてまたはデータ・ストリーム中に定義する。たとえば、参照として本明細書に組み入れられるJ.D. MurrayおよびW.vanRyper著「グラフィックス・ファイル・フォーマット大辞典第2版（The Encyclopedia of Graphics File Formats, Second Edition）」（O'Reilly & Associates, Inc.: カリフォルニア州Sebastopol、1996年）に記載されたグラフィックス・ファイル・フォーマットおよびその他のフォーマットを参照されたい。

デジタル化メディア・コンテントの種類は、メディア・コンテントの物理サイズを小さくするのに用いられる符号化または圧縮技術の種類に応じるか、またはメディア・コンテントの記憶をサポートする物理メディアの種類に応じて範疇分けすることもできる。磁気記憶装置または光学記憶装置や、メモリ装置や、無線メディアのような様々な種類の物理メディアがメディア・コンテントを公開する際に使用されている。

デジタル化メディア・コンテントの種類は、メディア・コンテントを送信するのに用いられる通信プロトコルの種類によって範疇分けすることもできる。インタネットなどのパケット交換網では、多数のプロトコル層が使用されている。このようなプロトコルには、ネットワーク・プロトコルおよびトランスポート・プログラムならびにアプリケーション・プロトコルを含めることができる。ネットワーク・プロトコルおよびトランスポート・プロトコルはデジタル・データのパケットを供給する責任の一部を負っている。ネットワーク・プロトコルおよびトランスポート・プロトコルの例には、IP（Internet Protocol）、TCP（Transmission Control Protocol）、UDP（User Datagram Protocol）、およびRTP（Real-Time Transport Protocol）がある。アプリケーションイ・プロトコルは、ネットワーク・プロトコルおよびトランスポート・プロトコル上で動作するより高いレベルのプロトコルである。特に、アプリケーション・プロトコルは、デジタル・メディア公開をサポートするサービスを提供する。WWW技術で使用されるアプリケーション・プロトコルの例にはHTTP（HyperText Transport Protocol）およびRTSP（Real-Time Streaming Protocol）がある。

メディア・プレーヤの数が急激に増えてきたため、メディア・コンテントの種類の豊富さとクライアント装置がコンテントを取り扱う多様な機能との相違が大きくなってきた。その結果、エンド・ユーザの技術選択プロセスが極めて複雑になっている。たとえば、ユーザは、所与のメディア・プレーヤが、ユーザが関心を抱いている種類のメディア・コンテントを再生できるかどうか明確に分からないことが多い。また、ユーザは、所望のコンテントにアクセスするために頻繁に新しいメディア再生ソフトウェアをダウンロードしなければならない。

さらに、ユーザが様々なクライアントメディア・プレーヤを使用するので、コンテント・プロバイダは、多数のユーザにコンテントを供給するために最初のメディア・コンテントをいくつかのソース・タイプで公開する必要がある。保存されたメディア・コンテントを有するコンテント・プロバイダには、保存されたメディア・コンテントを新しいまたは更新されたソース・タイプで公開するという負担も課される。

トランスコーダは、ある種類のメディア・コンテント（ソース・タイプ）を他の種類のメディア・コンテント（宛先タイプ）に変換する。この変換は「トランスコーディング」と呼ばれている。トランスコーディングにはいくつかの異なる変換動作を含めることができる。使用される特定の変換動作は、どんな公開変数が変換されているかに依存する。たとえば、トランスコーディングには、ある符号化データ・フォーマットから他の符号化データ・フォーマットへの変換動作（CCITT Group3符号化データからRLE符号化データへの変換など）を含めることができる。MurrayおよびvanRyperの1095ページを参照されたい。

従来のマルチタイプ変換サービスは、コンテント・プロバイダがメディア・コンテントを公開する前にオフラインで実行され、公開プロセスに望ましくない避けがたい遅延をもたらす。メディア・コンテントのリアルタイム・トランスコーディング用の構成が既知であるが（たとえば、インタネット上でのライブ・メディアのトランスコーディングおよび供給）、このような構成は、それらがメディア・コンテントを単一の宛先タイプにしか変換できず、かつメディア・コンテントを複数の宛先タイプで供給することができないという点で制限されている。

さらに、オフライン・マルチフォーマット・トランスコーディング・サービスはコストがかかるので、コンテント・プロバイダはそのメディア・コンテントを限られた数の宛先タイプにしか変換できない。変換済みのファイルの宛先タイプに対処できないメディア・プレーヤを有するユーザは、このコンテントにアクセスすることができない。したがって、従来のメディア生成は、ユーザが自分のメディア・ファイルを再生するのにどのメディア・プレーヤを用いるかコンテント・プロバイダが推測せざるを得ない「プッシュ」プロセスに限られる。

メディア公開技術がこのように急速に発展したことのもう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の各構成要素間の通信をサポートすることができる。たとえば、TCP/IP（Transmission Control Protocol/Internet Protocol）スイートを用いてリンクを確立することができ、トランスポート・データおよびRTSP（Real-Time Streaming Protocol）を用いてトランスコーディング・システム100の各構成要素間でデータをストリーミングすることができる。WWWベースのアプリケーション層およびブラウザ（およびウェブ・サーバ）を用いて、図1に示されている各構成要素間の通信をさらに容易にすることもできる。しかし、これらの例は例示的なものである。本発明は、特定の通信プロトコルまたはアプリケーションに限るものではなく、他の特許されたネットワーク通信プロトコルまたはアプリケーションあるいは特許されていないネットワーク通信プロトコルまたはアプリケーションを使用することができる。

ビューア・クライアント102は、ユーザまたは視聴者がネットワーク108を介してメディア・コンテントを要求して受信し、かつ受信したメディア・コンテントを再生するときに用いられる。ある態様では、ビューア・クライアント102は、ウェブ・ブラウザと、コンピュータ・オペレティング・システムの下で動作する1つまたは複数のメディア・プレーヤとを含むパーソナル・コンピュータである。または、ビューア・クライアント102はWEBTV、WINDOWS CE装置、PDA（Personal Digital Assistant）、PALMハンドヘルド装置、ネットワーク・アクセス機能を有するコンソール器械、MP3器械、メディア・コンテントを要求し、受信し、再生することのできる他の任意のクライアント装置および／またはプログラムであってよい。しかし、本発明はこれらの例に限らず、当業者には、様々なクライアント装置およびプログラムを用いてネットワーク108を介したメディア・コンテントの要求、受信、再生を行うことができることが理解されよう。本発明は、そのような他のクライアント装置およびプログラムに関する。

ビューア・クライアント102は、様々な種類のメディア・コンテントを受信し再生することができる。たとえば、ビューア・クライアント102は、MPEGフォーマット、AVIフォーマット、MP3フォーマット、REALフォーマット、WINDOWS MEDIAフォーマット、QUICK TIMEフォーマット、H.263ビデオ符号化フォーマット、およびPALM互換フォーマットを含むがそれらに限らない様々な公知の符号化フォーマットでメディア・コンテントを受信し再生することができる。

コンテント・プロバイダ・クライアント104は、コンテント・プロバイダがネットワーク108を介してメディア・コンテントを公開しかつ／または送信するときに使用される。ある態様では、コンテント・プロバイダ・クライアント104は、クライアント・ワークステーションと、メディア入力装置および／またはプログラムとを含んでいる。たとえば、コンテント・プロバイダ・クライアント104は、接続されたメディア入力装置を有するパーソナル・コンピュータを含んでよい。コンテント・プロバイダ・クライアント104は、様々なメディア入力装置およびプログラムを用いてメディア・コンテントを供給することができる。たとえば、カメラ（8mm、Hi-8、または任意のビデオ・デジタル化装置）、ラインイン／マイクロフォン（任意のカメラ装置に接続されたものか、またはスタンドアロン・オーディオ入力装置）、デジタル・カメラ、ボイス・オーバー・イラストレーションを有するスライド・ショウをアップロードする装置、クライアントが選択したフォーマットですでに符号化されたファイル、またはネットワーク・アクセス可能なマウント・ポイント（HTTP（Hypertext Transfer Protocol）、FTP（File Transfer Protocol）、リモート・サーバなどであるが、それらに限らない）を介して得られるファイルを用いてメディア・コンテントを供給することができる。これらの例は制限的なものではなく、当業者には、様々なクライアント装置およびプログラムを用いてネットワーク108を介してメディア・コンテントを公開しかつ／または送信することができることが理解されよう。本発明はそのようなクライアント装置およびプログラムに関する。

コンテント・プロバイダ・クライアント104は様々な種類のメディア・コンテントを公開しかつ／または送信することができる。たとえば、コンテント・プロバイダ・クライアント104はMPEGフォーマット、AVIフォーマット、MP3フォーマット、REALフォーマット、WINDOWS MEDIAフォーマット、QUICK TIMEフォーマット、H.263ビデオ符号化フォーマット、および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に供給するURL（Uniform Resource Locator）を含んでいる。コンテント・プロバイダは、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フォーマット、WINDOWS MEDIAフォーマット、QUICK TIMEフォーマットなどの変換されたメディア・コンテントの供給専用に使用することができる。マシン・ファーム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はメディア・コンテントのあるコピーをキャッシュ内に保持すべきかそれとも破棄すべきかをLRU（Least-Recently-Used）アルゴリズムを用いて判定する。LRUアルゴリズムによれば、メディア・コンテントのコピーが所与の時間内の数回のアクセスにわたって所定のしきい値を満たさなかった場合、そのメディア・コンテントのコピーは破棄される。この例は制限的なものではなく、当業者には、当技術分野で既知の任意の数のインテリジェント・アルゴリズムを用いて、マスタ・アーカイブ214および変換済みキャッシュ212の利用状況を管理できることが理解されよう。このようなインテリジェント・アルゴリズムは本発明の範囲および趣旨の範囲内である。

ある態様では、マスタ・アーカイブ214および／または変換済みキャッシュ212は、メディア・トランスコーディング・エンジン106内の内部ネットワークに結合された、ネットワークに接続された1つまたは複数の記憶装置として実施される。しかし、本発明はこれに限らず、キャッシング・ソフトウェアを動作させる汎用サーバ、ファイル・サーバ、1つまたは複数のディスク・アレイ、またはSAN（Storage Area Network）を含むがそれらに限らない任意の適切な記憶装置を用いて、マスタ・アーカイブ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に与えるURL（Uniform Resource Locator）を含んでいる。コンテント・プロバイダは、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に与えるURL（Uniform Resource Locator）を含んでいる。コンテント・プロバイダは、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のような、ストリーミング・メディア用の標準プロトコルである。または、TCP/UDPのような標準ネットワーク・プロトコルを介して定義された特許されたプロトコルを使用することができる。他の態様では、様々なプロトコルを用いてネットワーク・インフラストラクチャのそれぞれの異なるニーズに対処することができる。たとえば、ネットワーク・トラフィック条件に応じて動的に変換するプロトコルを実施することができる。しかし、これらの例は例示的なものである。本発明は、特定の通信プロトコルまたはアプリケーションに限るものではなく、他の特許されたネットワーク通信プロトコルまたはアプリケーションあるいは特許されていないネットワーク通信プロトコルまたはアプリケーションを使用することができる。

段階526で、ビューア・クライアント102は、ストリーミング・サーバまたはプロキシ・サーバからストリーミング・メディアを受信する。この点で、ビューア・クライアント102は、ビューア・クライアント102上に存在するメディア・プレーヤに関連する宛先タイプに応じてメディア・コンテントを再生する。本発明の他の態様では、メディア・コンテントを受信し、後で再生するか、または他のメディア再生装置に転送することができるように、ビューア・クライアント102上のダウンロードされたファイルとして記憶することができる。

段階526で、フローチャート500は終了する。

F．他のトランスコーダ動作およびメディア・コンテントの例
上述のように、メディア・トランスコーディング・エンジン106は1つまたは複数のトランスコーダ218を含んでいる。トランスコーダ218はある種類のメディア・コンテント（本明細書ではソース・タイプと呼ぶ）から他の種類のメディア・コンテント（本明細書では宛先タイプと呼ぶ）に変換する。トランスコーディングにはいくつかの異なる変換動作を含めることができる。使用される特定の変換動作は、変換されるメディア・コンテントおよび関連する公開変数に依存する。本明細書で使用される公開変数とは、メディア・コンテントの様々な特性を指す。

本発明によれば、メディア・コンテントはネットワーク上で公開されるデジタル・データである。この場合、公開対象は、ネットワーク上で供給しかつ宛先メディア・プレーヤによって表示することができるようにフォーマットされたデジタル・データを指す。メディア・コンテントの公開変数には、ファイル・フォーマット、ビット・レート、通信プロトコル、物理媒体、圧縮アルゴリズム、および／またはデジタル権利管理情報を含めることができるがそれらに限らない。

デジタル・データは、コンテナ・フォーマット、ビットマップ・フォーマット、ビデオ・フォーマット、オーディオ・フォーマット、ベクトル・フォーマット、メタファイル・フォーマット、シーン・フォーマット、アニメーション・フォーマット、マルチメディア・フォーマット、ハイブリッド・フォーマット、ハイパーテキスト・フォーマットおよびハイパーメディア・フォーマット、三次元データ（3D）フォーマット、VRML（Virtual Reality Modeling Language）フォーマット、フォント・フォーマット（ビットマップ・フォント、ストローク・フォント、スプライン・ベースのアウトライン・フォント）、ページ記述言語（PDL）フォーマット、ならびに任意の他の種類のグラフィックス・ファイル・フォーマットまたは他のファイル・フォーマットを含むがそれらに限らない任意の種類のファイル・フォーマットであってよい。表1に、本発明のある態様で使用できるそのようなファイル・フォーマットの例をリストする。

（表１）ファイル・フォーマット例

MurrayおよびvanRyperの12ページ乃至26ページを参照されたい。これらの例は例示的なものであり、必ずしも本発明を制限するものではない。この説明を読んだ当業者には明らかなように（現在既知であるかまたは将来開発される）他のファイル・フォーマットを使用することができる。

同じファイル・フォーマット内でも、様々な圧縮アルゴリズムに従ってデジタル・データを圧縮することができる。たとえば、QUICK TIMEフォーマット・ファイルでは、H.263標準、CINEPAK標準、JPEG標準、QT ANIMATION標準、またはQT VIDEO標準に従ってビデオ・データを圧縮することができる。他の例として、WINDOWS MEDIA ASFフォーマット・ファイルでは、MICROSOFT AUIDO FORMAT標準、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は、以下の宛先公開関数に従って公開できるように変換されたデジタル・データを含んでいる。すなわち、物理媒体はパケット交換網（インタネット）であり、通信プロトコルはWINDOWS MEDIA STREAMING MMSプロトコルを含み、ファイル・フォーマットは、56kbpsのビット・レートでMP3符号化を用いるWINDOWS MEDIA FILEである。第2の宛先タイプ・メディア・コンテント760は、以下の宛先公開関数に従って公開できるように変換されたデジタル・データを含んでいる。すなわち、物理媒体は無線網であり、通信プロトコルはHTTPを含み、ファイル・フォーマットは、12kbpsのビット・レートでのMP3符号化を含むMP3である。

他の例は以下の表に示されている。
表2乃至5 トランスコーダ動作例

（表２）

（表３）

（表４）

（表５）

これらの例は例示的なものであり、本発明を制限するものではない。この説明を読んだ当業者には明らかなように、現在既知であるかまたは将来開発される他の種類のオン・デマンド・トランスコーディング動作を使用することができる。

G．本発明の他の態様
本明細書では、本発明の方法およびシステムの態様例について説明した。他の個所で指摘したように、これらの態様例は、例示的な目的にのみ記載されており、制限的なものではない。当業者には、本明細書で説明した態様とわずかに異なるかまたは実質的に異なる他の態様が、本明細書に含まれる教示に基づいて明らかになろう。たとえば、当業者には、本発明のトランスコーディング・システムおよび方法がメディア・コンテントのみのトランスコーディングおよび供給に限らず、圧縮ファイル、電子ドキュメント、HTMLページ、XMLドキュメント、および複数のフォーマットで記憶し電子的に供給することのできる他の任意の情報を含むがそれらに限らないすべての種類の情報のトランスコーディングおよび供給も包含することが理解されよう。他の態様には、本発明の方法、システム、および構成要素のハードウェア実現態様、ソフトウェア実現態様、およびソフトウェア／ハードウェア実現態様が含まれるがそれらに限らない。このような他の態様は、本発明の範囲および趣旨の範囲内である。

H．結論
上記には本発明の様々な態様について説明したが、これらの態様が一例としてのみ示されており、制限として示されているのではないことに理解されたい。当業者には、添付の特許請求の範囲に定義された本発明の趣旨および範囲から逸脱せずに各態様の形態および詳細に様々な変更を加えられることが理解されよう。したがって、本発明の範囲は、上述の例示的な態様によって制限されるべきではなく、添付の特許請求の範囲およびその均等物に従ってのみ定義すべきである。

本発明の一態様によるメディア・トランスコーディング・システムのブロック図である。 本発明の一態様によるメディア・トランスコーディング・エンジンの一例のブロック図である。 本発明の態様による、メディア・コンテントを公開するルーチンについて説明するフローチャートである。 本発明の態様による、メディア・コンテントを公開するルーチンについて説明するフローチャートである。 本発明の態様による、メディア・コンテントにアクセスするルーチンについて説明するフローチャートである。 本発明の態様による、メディア・コンテントにアクセスするルーチンについて説明するフローチャートである。 本発明のある態様によって使用できる例示的なトランスコーダを示す図である。 本発明の態様による様々な公開変数に関するソース・タイプおよび宛先タイプの例示的なトランスコーディングを示す表である。

符号の説明

102 ビューア・クライアント 104 コンテント・プロバイダ・クライアント， 106 メディア・トランスコーディング・エンジン， 108 ネットワーク

Claims (6)

1. クライアントから要求されるメディア・コンテントを提供する提供装置において、
   前記メディア・コンテントを記憶する記憶手段と、
   前記クライアントから前記メディア・コンテントの要求を受信すると共に要求された前記メディア・コンテントを提供する通信手段と、
   前記クライアントからの要求に応答して、前記クライアントから要求されるメディア・コンテントを、前記記憶手段から取得する取得手段と、
   前記メディア・コンテントのタイプをトランスコードするトランスコーダと、
   前記クライアントから要求されたメディア・コンテントのタイプを判定する判定手段とを備え、
   前記トランスコーダは、前記取得手段において取得されたメディア・コンテントを、前記判定手段において判定されたタイプのトランスコーダにおいて、トランスコードを実行し、
   前記通信手段において、前記トランスコーダにおいてトランスコードされたメディア・コンテントを、前記クライアントに提供する
   ことを特徴とする提供装置。
2. メディア・コンテントのタイプは、少なくとも、
   （1）メディア・コンテントのファイル・フォーマット、
   （2）メディア・コンテントのビット・レート、
   （3）メディア・コンテントを記憶するための圧縮アルゴリズム、
   （4）メディア・コンテントを転送するための通信プロトコル、
   （5）メディア・コンテントを記憶する物理メディア、
   （6）圧縮アルゴリズム、
   （7）デジタル権利管理情報、または、
   （8）これらの組み合わせの内一つを含むことを特徴とする請求項１に記載の提供装置。
3. 前記クライアントから要求されるタイプは、前記メディア・コンテントを再生するソフトウェアによって判定されることを特徴とする請求項１に記載の提供装置。
4. メディア・コンテントを記憶する記憶手段と、
   クライアントから前記メディア・コンテントの要求を受信すると共に要求された前記メディア・コンテントを提供する通信手段と、
   前記クライアントからの要求に応答して、前記クライアントから要求されるメディア・コンテントを、前記記憶手段から取得する取得手段と、
   前記メディア・コンテントのタイプをトランスコードするトランスコーダと、
   前記クライアントから要求されたメディア・コンテントのタイプを判定する判定手段とを備える提供装置の前記クライアントから要求されるメディア・コンテントを提供する提供方法であって、
   サーバにおいて、前記クライアントからメディア・コンテントの要求を、前記通信手段を介して受信する受信ステップと、
   前記要求に応答して、前記クライアントの要求するメディア・コンテントを、前記記憶手段から、取得する取得ステップと、
   前記クライアントから要求されたメディア・コンテントのタイプに従って、取得した前記メディア・コンテントをトランスコーダにおいてトランスコードするトランスコードステップと、
   前記トランスコーダにおいてトランスコードされたメディア・コンテントを、前記クライアントに前記通信手段を介して提供する提供ステップと
   を含むことを特徴とする提供方法。
5. メディア・コンテントのタイプは、少なくとも、
   （1）メディア・コンテントのファイル・フォーマット、
   （2）メディア・コンテントのビット・レート、
   （3）メディア・コンテントを記憶するための圧縮アルゴリズム、
   （4）メディア・コンテントを転送するための通信プロトコル、
   （5）メディア・コンテントを記憶する物理メディア、
   （6）圧縮アルゴリズム、
   （7）デジタル権利管理情報、または、
   （8）これらの組み合わせの内一つを含む
   ことを特徴とする請求項４に記載の提供方法。
6. 前記クライアントから要求されるタイプは、前記メディア・コンテントを再生するソフトウェアによって判定される
   ことを特徴とする請求項４に記載の提供方法。

Images