JP4761158B2 - 情報処理方法および記録媒体 - Google Patents

Description

本明細書中に説明されている本発明は、情報システムに関し、より詳細にはマルチメディア・コンテンツ・クライアント・コンフィギュレーション情報の検出に関する。

本出願は、参照により本明細書に組み込まれている２００１年１１月９日に出願され、２００３年５月１５日に米国特許出願公開第２００３／００９３５０７号として発行された米国特許出願第０９／９８６，６８３号の一部継続出願であり、本願請求項に係る発明は、発明者Jody Shapiroによる「System, Method, and Computer Program Product for Remotely Determining the Configuration of Multi-Media Content User」という名称の２００３年１０月３１日に出願され、番号がまだ割り当てられていない米国仮出願（速達郵便第ＥＶ３３１８７１９６９ＵＳ）に対する優先権を主張するものである。

データ・ネットワークの有用性および高速データ接続の有用性を考えると、エンド・ユーザがマルチメディア・コンテンツにアクセスすることは、今では一般的になっている。今やいくつものウェブ・サイトが、オーディオおよびビデオをユーザに対して提供している。ユーザがウェブ・ページ中に提示されるリンクまたはコントロールをクリックするだけで、１つまたは複数のマルチメディア・ファイルが配信されることが理想的である。このユーザが、適切なハードウェアおよびソフトウェアのコンフィギュレーションを有する場合には、次いでこのファイルが再生されうる。

しかし、現在では、かなり様々なユーザ・コンフィギュレーションが存在する。一部のユーザは、インテル（Intel）ベースのＰＣ（personal computerパーソナル・コンピュータ）を有するが、他のユーザは、アップル・マッキントッシュ（APPLE MACINTOSH）コンピュータを有することもある。更にこれらとも異なるオペレーティング・システムも存在する。一部のユーザは、マイクロソフト社（MICROSOFT, Inc.）からのあるバージョンのマイクロソフト・ウィンドウズ（登録商標）（MICROSFT WINDOWS（登録商標））を有することになるが、他のユーザは、アップル社（APPLE, Inc.）からのあるバージョンのＭＡＣ ＯＳを有する。さらに、今ではこのユーザ・コミュニティにおいて、これらのオペレーティング・システムのそれぞれにはいくつかのバージョンが存在する。さらに、今ではいくつものソフトウェア・プログラムを使用して、ユーザのコンピュータ上でマルチメディアを再生することができる。これらのプレーヤは、（アップル社からの）クイックタイム（QUICKTIME）、（リアルネットワークス社（REALNETWORKS, Inc.）からの）リアルプレーヤ（REALPLAYER）、および（マイクロソフト社からの）ウィンドウズ・メディア・プレーヤ（WINDOWS MEDIAPLAYER）を含んでいる。さらに、これらのプレーヤのそれぞれには、このユーザ・コミュニティにおいて現在使用可能ないくつかのバージョンがある。最終的に、異なるユーザが、異なるデータ・レートで動作させることもある。一部のユーザは、高速ブロードバンド接続を有することもあるが、他のユーザは、５６Ｋモデム接続を有することもある。
米国特許出願第０９／９８６，６８３号 米国特許出願公開第２００３／００９３５０７号 米国仮出願（速達郵便第ＥＶ３３１８７１９６９ＵＳ）Jody Shapiro、「System, Method, and Computer Program Product for Remotely Determining the Configuration of Multi-Media Content User」 米国特許第３３９４３５２号 米国特許第３９３７８８１号 米国特許第５６５７０１５号 米国特許第６５９３８６０号 米国特許第６４０７６８０号 米国特許第６４６６９３９号 米国特許第５９２８３３０号 米国特許第６３１７１３４号 米国特許第６０７０００２号 米国特許出願公開第２００３／０１５８９１３号 米国特許出願公開第２００３／００９３５０７号 米国特許出願公開第２００２／００９９８５８号 米国特許出願公開第２００２／００９９７７０号 米国特許出願公開第２００２／００９１８００号 米国特許出願第１０／６４４６０２号 Chapman, Nigel他、「Digital Multimedia」、John Wiley & Sons, Ltd.、Copyright 2000 Murray, James D.他、「Encyclopedia of Graphics File Formats: Second Edition」、O'Reilly & Associates, Inc.、Copyright 1994、1996

この様々なプラットフォーム、オペレーティング・システム、プレーヤ、およびデータ・レートのことを考えると、コンテンツ・プロバイダは、配信すべきコンテンツをいかにしてフォーマットすべきかという問題に直面する。誤ったフォーマティングは、ユーザのコンフィギュレーションとは互換性のないコンテンツの配信をもたらすはずである。これは、使用できないコンテンツをもたらす可能性がある。このコンテンツが使用可能な場合にも、このコンテンツは、このユーザのコンフィギュレーションで使用可能なすべての機能を有効活用できないフォーマットになってしまっていることもあり、ユーザが体験するところのコンテンツは、実際にそうであるような上質なものではない。

過去においては、コンテンツ・プロバイダは、何組かの一般的なユーザ・コンフィギュレーションのセットを選択することによってこの問題に対処してきている。例えばこのプロバイダは、最も一般的なメディア・プレーヤとこれらのバージョンを特定するかもしれない。このプロバイダは、これらのプレーヤのそれぞれについてこのコンテンツをフォーマットし、これら種々雑多なバージョンのコンテンツを記憶する。次いで、このプロバイダは、どのメディアプレーヤをこのユーザが有しているかについて、または、このユーザが複数のプレーヤを有している場合には、どのプレーヤをこのユーザが好むかについて実際に照会するために、このユーザに提供すべきメニューを開発するはずである。次いで、このユーザは、選択を行い、この選択されたフォーマットであらかじめ符号化されているコンテンツがこのユーザに対して配信される。

この解決方法には制限がある。まずこの解決方法は、比較的柔軟性がない。オプション数が限られている。ユーザの特定のコンフィギュレーションが、このメニュー中のオプションとして提示されていないこともある。エンド・ユーザがこのユーザにとって使用可能な複数のメディア・プレーヤを有する場合には、このユーザの好ましい選択肢が、オプションとしてリストアップされていないこともある。また上記解決方法は、毎回ユーザ入力を必要とする。このユーザは、照会されることを欲しないかもしれない。その代わりに、このユーザは、このフォーマッティングが自分のために解決されていることを好むこともある。他の状況では、このユーザは、このメニューが要求している情報について知らない可能性もある。このユーザは、自分がどのバージョンのメディア・プレーヤを有するかについて知らない可能性もある。この解決方法ではまた、コンテンツ・プロバイダが、これらのメニューを変更し、新しいプレーヤ（または、既存のプレーヤの新しいバージョン）が普及するようになるときにはいつでも、コンテンツを再符号化する必要もある。したがって、以上の解決方法は、柔軟性を欠き、このユーザにとってもこのプロバイダにとっても共に厄介である。

したがって、ユーザのコンフィギュレーションを特定して、最適な閲覧体験をもたらす互換性のあるフォーマットでこのユーザにコンテンツを提供する方法が必要となってきている。さらに、ユーザ入力の必要性を最小にしたり、または、ユーザ・フレンドリであるようにした方法で、このコンフィギュレーションの特定が行われるべきである。さらに、ユーザの接続速度を特定する効率的な方法が望まれる。

本発明の一側面の情報処理方法は、配信管理サーバと、トランスコーダによってフォーマットされ、ストリーミングサーバを介して配信されるマルチメディア・コンテンツを再生するクライアントとからなる情報処理システムにおいて、前記配信管理サーバが前記クライアントのコンフィギュレーションをリモートに特定するための情報処理方法であって、前記配信管理サーバから前記クライアントに、前記クライアントが有するブラウザにおいて前記マルチメディア・コンテンツを再生するプレーヤを検出するために実行されるプレーヤ検出スクリプトを送信するスクリプト送信ステップと、前記クライアントが、前記配信管理サーバから送信される前記プレーヤ検出スクリプトが実行されることに応じて、前記ブラウザの種類を識別する識別ステップと、前記識別ステップの処理により識別された前記ブラウザの種類に応じて、前記ブラウザに付随する所定の管理データから前記プレーヤについての情報を探索するか、または、前記プレーヤをインスタンス化することを試みることにより、前記ブラウザにおいて前記プレーヤが存在するかを判定する判定ステップと、前記ストリーミングサーバから配信される前記マルチメディア・コンテンツを前記トランスコーダがフォーマットするのに十分であるかを前記配信管理サーバが判断するための情報であって、前記判定ステップの処理によって前記ブラウザにおいて存在すると判定された前記プレーヤの識別情報およびバージョンを少なくとも含むコンフィギュレーション情報を、前記配信管理サーバに送信するコンフィギュレーション情報送信ステップとを含む。
前記コンフィギュレーション情報送信ステップには、前記コンフィギュレーション情報を、前記クッキーとして前記配信管理サーバのドメインに関して設定されたクッキーに格納して送信させることができる。

本発明の一側面の記録媒体に記録されるプログラムは、配信管理サーバと、トランスコーダによってフォーマットされ、ストリーミングサーバを介して配信されるマルチメディア・コンテンツを再生するクライアントとからなる情報処理システムにおいて、前記クライアントのコンフィギュレーションをリモートに特定する情報処理を、前記配信管理サーバに実行させるプログラムであって、前記配信管理サーバから前記クライアントに、前記クライアントが有するブラウザにおいて前記マルチメディア・コンテンツを再生するプレーヤを検出するために実行されるプレーヤ検出スクリプトの送信を制御する送信制御ステップと、前記クライアントが、前記配信管理サーバから送信される前記プレーヤ検出スクリプトが実行されることに応じて、前記ブラウザの種類を識別し、前記識別ステップの処理により識別された前記ブラウザの種類に応じて、前記ブラウザに付随する所定の管理データから前記プレーヤについての情報を探索するか、または、前記プレーヤをインスタンス化することを試みることにより、前記ブラウザにおいて前記プレーヤが存在するかを判定し、送信してくる、前記ストリーミングサーバから配信される前記マルチメディア・コンテンツを前記トランスコーダがフォーマットするのに十分であるかを前記配信管理サーバが判断するための情報であって、前記ブラウザにおいて存在すると判定された前記プレーヤの識別情報およびバージョンを少なくとも含むコンフィギュレーション情報の受信を制御する受信制御ステップとを含む処理を前記配信管理サーバに実行させる。
本発明の一側面においては、配信管理サーバによって、配信管理サーバからクライアントに、クライアントが有するブラウザにおいてマルチメディア・コンテンツを再生するプレーヤを検出するために実行されるプレーヤ検出スクリプトが送信され、クライアントによって、配信管理サーバから送信されるプレーヤ検出スクリプトが実行されることに応じて、ブラウザの種類が識別され、識別されたブラウザの種類に応じて、ブラウザに付随する所定の管理データからプレーヤについての情報を探索するか、または、プレーヤをインスタンス化することを試みることにより、ブラウザにおいてプレーヤが存在するかが判定され、ストリーミングサーバから配信されるマルチメディア・コンテンツをトランスコーダがフォーマットするのに十分であるかを配信管理サーバが判断するための情報であって、ブラウザにおいて存在すると判定されたプレーヤの識別情報およびバージョンを少なくとも含むコンフィギュレーション情報が、配信管理サーバに送信される。

本明細書中に組み込まれており、本明細書の一部分を形成する添付図面は、本発明を例証しており、本明細書と共にさらに本発明の諸原理を説明し、また関連する当技術分野における当業者が本発明を作成し使用することを可能にする役割を果たしている。

本発明の好ましい実施形態について、次にこれらの添付図面を参照して説明することにする。これらの図面中において、同様な参照番号は、同一の、または機能的に同様な要素を示す。

参照による組込み
以下は、参考文献の引用リストであり、これらの各参考文献は、本発明の背景、要約書、および本発明の概要として説明されたものに追加して、それ以外に以下では詳細に記述されていないこれらの好ましい実施形態の要素または特徴の代替実施形態を開示するものとして、ここに以下の好ましい実施形態の詳細な説明に参照により組み込まれている。これらの参考文献、すなわち
１９６８年７月に発行された米国特許第３３９４３５２号、１９７６年２月に発行された米国特許第３９３７８８１号、１９９７年８月に発行された米国特許第５６５７０１５号、２００３年７月１５日に発行された米国特許第６５９３８６０号、２００２年６月に発行された米国特許第６４０７６８０号、２００２年１０月１５日に発行された米国特許第６４６６９３９号、１９９９年７月２７日に発行された米国特許第５９２８３３０号、２００１年１１月１３日に発行された米国特許第６３１７１３４号、および２０００年５月３０日に発行された米国特許第６０７０００２号、ならびに
２００３年８月２１日に公開された米国特許出願公開第２００３／０１５８９１３号、２００３年５月１５日に公開された米国特許出願公開第２００３／００９３５０７号、２００２年７月２５日に公開された米国特許出願公開第２００２／００９９８５８号、２００２年７月２５日に公開された米国特許出願公開第２００２／００９９７７０号、および２００２年７月１１日に公開された米国特許出願公開第２００２／００９１８００号、ならびに
２００３年８月２０日に出願された米国特許出願第１０／６４４６０２号、ならびに
Chapman, Nigel他、「Digital Multimedia」、John Wiley & Sons, Ltd.、Copyright 2000、ならびに
Murray, James D.他、「Encyclopedia of Graphics File Formats: Second Edition」、O'Reilly & Associates, Inc.、Copyright 1994、1996
のうちの１つまたは２つ以上の組合せを調べて、本明細書中の詳細な説明中に説明される好ましい実施形態の変形形態を得ることができる。

好ましい実施形態の概要
エンド・ユーザのコンピュータ・システムのコンフィギュレーションを特定するためのシステム、方法、およびコンピュータ・プログラム製品。特に、このユーザのメディア・プレーヤおよびネットワーク接続速度が特定される。次いで、このコンフィギュレーション情報は、第２のコンピュータにより、好ましくは配信管理サーバによって受信される。このユーザに対して配信するためのマルチメディア・コンテンツをフォーマットするために、このコンフィギュレーション情報が使用される。このコンテンツはこのコンフィギュレーション情報に従ってフォーマットされるので、このコンテンツは、このユーザのコンフィギュレーションと互換性がある。このコンフィギュレーション特定プロセスは、このコンテンツ・プロバイダのウェブ・ページ中に配置されたサーバ・コンタクト・コードを必要とする。このウェブ・ページがこのユーザによってロードされるとき、このサーバ・コンタクト・コードは、このブラウザに、この配信管理サーバからコードを取得させる。このコードがこのユーザによって実行されるときに、このユーザのメディア・プレーヤが特定される。この情報は、このユーザの所のクッキーに格納され、この配信管理サーバへと送信される。このコンフィギュレーション情報が不確定または不完全である場合には、このユーザには、プリファランス・ページが提示され、このプリファランス・ページ中で、このユーザはこのコンフィギュレーションを指し示すことができる。このプリファランス・ページは、このユーザの接続速度を特定するためのメカニズムも含んでいる。このプリファランス・ページは、このユーザに対して特定の推奨を行うこともでき、例えばこのユーザが特定のメディア・プレーヤを選択することを推奨することもできる。このプリファランス・ページは、既知のサイズを有するデータのブロックを含んでいる。このブロックを転送するために必要とされる時間が測定され、次いで、この接続速度が計算され、この配信管理サーバに対して提供される。

好ましい実施形態によれば、このコンフィギュレーション特定プロセスは、このコンテンツ・プロバイダのウェブ・ページ中に配置されたサーバ・コンタクト・コードを必要としている。このウェブ・ページがこのユーザによってロードされるときに、このサーバ・コンタクト・コードは、このブラウザに、この配信管理サーバからスクリプトを取得させる。このスクリプトがこのユーザによって実行されるときに、このユーザのメディア・プレーヤが特定される。この情報は、このユーザの所のクッキーに格納され、この配信管理サーバへと送信される。次いで、このコンフィギュレーション情報は、トランスコーダが使用することができ、このトランスコーダは、このコンフィギュレーション情報に従ってこのメディア・コンテンツをフォーマットする。

このコンフィギュレーション情報が、不確定または不完全である場合には、このユーザには、プリファランス・ページが提示され、このプリファランス・ページ中でこのユーザは、このコンフィギュレーションを指し示すことができる。このプリファランス・ページを介して特定されたこのコンフィギュレーションもまた、クッキーに格納され、この配信管理サーバに送信されて、コンテンツのフォーマッティングを可能にする。このプリファランス・ページはまた、このユーザに対して特定の推奨を行うこともでき、例えばこのユーザが特定のメディア・プレーヤを選択することを推奨することもできる。

好ましい実施形態の説明
本明細書中で説明されるこれらの好ましい実施形態は、ユーザのコンピュータ・システム・コンフィギュレーションのリモートな特定を可能にするシステム、方法、およびコンピュータ・プログラム製品に関する。これにより、このユーザのコンフィギュレーションと互換性があるようにして、このコンピュータ向けのマルチメディア・コンテンツをフォーマットすることができるようになる。十分なコンフィギュレーション情報が取得されるならば、このユーザにとって可能な最良のメディア体験を実現することができるように、このコンテンツをフォーマットすることができる。

以下に続く説明においては、ユーザのコンピュータの概念は、全範囲のプログラマブル・デバイスまたはプログラムされたデバイスを含むように広範に定義されることに留意されたい。ユーザのコンピュータは、それだけには限定されないが、パーソナル・コンピュータまたは他のワークステーション、ラップトップ、パームトップ、携帯型個人情報端末、もしくは携帯電話とすることもできる。

好ましい実施形態によれば、サーバ・コンタクト・コードは、コンテンツ・プロバイダによってこのユーザに対して送信されるウェブ・ページ中に含まれる。このサーバ・コンタクト・コードは、配信管理サーバから１つまたは複数のスクリプトを取得する。このスクリプトにより、このユーザのコンピュータ・システムのコンフィギュレーション情報の特定が可能になる。本発明の一実施形態においては、このコンフィギュレーション情報は、このユーザの１つ（または複数）のメディア・プレーヤの識別情報（identity）およびバージョンを含んでいる。次いでこのコンフィギュレーション情報は、この配信管理サーバに返信される。次いでこのコンフィギュレーション情報を使用して、このマルチメディア・コンテンツを適切にフォーマットすることができる。本発明の一実施形態においては、コンフィギュレーション情報はまた、クッキーの形態でこのユーザのコンピュータにローカルに記憶される。その後のＨＴＴＰ（hypertext transfer protocolハイパーテキスト転送プロトコル）要求において、これらのクッキーは、このコンフィギュレーション情報を伝える方法としてこの配信管理サーバに送信することができる。

このコンフィギュレーション情報が不完全であり、または期限切れしている可能性があることが特定される場合には、追加のウェブ・ページが開かれる。これは、プリファランス・ページであり、ここでこのユーザは、この配信管理サーバに対して自分のコンフィギュレーション（例えば、自分の使用可能な、もしくは好ましいメディア・プレーヤのタイプおよびバージョン、または好ましい接続速度、もしくはその両方）を指定することができる。このプリファランス・ページを使用して、このユーザが特定のメディア・プレーヤを選択することを推奨することもできる。

好ましい実施形態によれば、プリファランス・ページは、既知のサイズのデータのブロックを含んでいる。このブロックは、このユーザのコンピュータにこのプリファランス・ページの一部分として転送される。このユーザのコンピュータの接続速度を特定するために、このデータのブロックを転送するために必要とされる時間が測定される。この接続速度の情報は、追加の１つのコンフィギュレーション情報を表す。この接続速度の情報もまた、クッキーの形態でこのユーザのコンピュータにローカルに記憶される。このクッキーは、この配信管理サーバにこのユーザの接続レートを伝える方法として、この配信管理サーバに送信することもできる。

好ましい実施形態のシステムは、基本的に２つの物事、すなわちサーバからクライアントへの接続速度（帯域幅）と、このクライアント上にインストールされた（プレーヤ・バージョンを含む）メディア・プレーヤとの検出をサポートする。接続速度の検出に関しては、このメディア・ストリームは、このサーバからこのクライアントへと送信されることになるので、サーバからクライアントへの推定しか望まれない。一部のメディア・プレーヤ制御チャネル・データは、このクライアントからこのサーバへと逆に送信されることになるが、このデータ量については、このサーバから送信される実際のメディア・データに比べて非常に少ない。

メディア・プレーヤを検出する場合、理想的には、以下、すなわちインストールされたメディア・プレーヤ（例えば、クイックタイム（QuickTime）、ウィンドウズ・メディア・プレーヤ（Windows Media Player）、リアルプレーヤ（RealPlayer）など）と、インストールされたメディア・プレーヤのバージョン（例えば、クイックタイム５．０．２、ウィンドウズ・メディア・プレーヤ６．４、リアルプレーヤ８．０）と、各メディア・プレーヤにインストールされた個々のオーディオ・コーデックおよびビデオ・コーデック（クイックタイム用のソレンソン（Solenson）ν３、ウィンドウズ・メディア・ビデオ（Windows Media Video）Ｖ８、リアルプレーヤ用のソニー（Sony）ＡＴＲＡＣ（登録商標）など）のすべてを検出することが可能であることである。

ジェネリック・メディア（Generic Media）のアプリケーションでは、このクライアント環境の詳細を知ることも有用である。有用な情報は、オペレーティング・システム・バージョン、ウェブ・ブラウザ・バージョン、ハードウェア・プラットフォーム、および好ましいユーザ・インターフェース言語を含んでいる。この情報の一部は、（一般的にこのクライアントによってこのサーバに対して送信されるＨＴＴＰヘッダの一部分として）簡単に取得されるが、他の情報は、取得することがもっと困難であり、または取得するのに時間がかかり、（要求ごとでなく）定期的に行うことが最良である。これらの場合には、このクライアントのウェブ・ブラウザに格納されたクッキーにこの検出された情報（ならびに任意のユーザ・プリファランス）を保存することが望ましい。要求がジェネリック・メディア・サーバに対して行われるときには、このウェブ・ブラウザは、関連のクッキー・データをこのサーバに対して自動的に送信することになる。

検出システム
好ましい実施形態による全体的なアーキテクチャは、コンテンツ・プロバイダのウェブ・ページ中に埋め込まれたサーバ・コンタクト・コードを含んでいる。このサーバ・コンタクト・コードは、このユーザのブラウザを配信管理サーバへと誘導し、この配信管理サーバは、１つまたは複数のスクリプトをこのユーザに対して送信する。このスクリプトの実行は、このユーザのメディア・プレーヤのタイプおよびバージョンの識別を可能にすることができる。この配信管理サーバは、この情報をこのユーザから受信する。結局のところ、このコンフィギュレーション情報を使用して、このユーザに対して配信するためのマルチメディア・コンテンツをフォーマットすることができる。

本発明のシステムの一実施形態が、図１に示されている。コンテンツ・プロバイダ１０５が、ユーザ１１０に対して情報を配信することが示されている。ウェブ・ページ１１５中にはサーバ・コンタクト・コード１２０が含まれている。ユーザ１１０のブラウザがサーバ・コンタクト・コード１２０にアクセスするときに、このブラウザは、配信管理サーバ１２５とのコンタクトを確立し、１つまたは複数のプレーヤ検出スクリプト１４０を要求する。サーバ１２５は、スクリプト１４０をこのユーザ１１０に送信することによって応答する。以下でさらに詳細に説明するようにして、このスクリプト１４０は、実行されるときに、ユーザ１１０についてのコンフィギュレーション情報１３５を特定する。本発明の一実施形態においては、このコンフィギュレーション情報は、コンフィギュレーション情報１３５を含むクッキーを設定するプロセスによって、ユーザ１１０の装置に記憶される。これらのクッキーはユーザ１１０によって保持され、ユーザ１１０がＨＴＴＰ要求１３０を行ってこのコンテンツにアクセスするときにこれらのクッキーの形態のコンフィギュレーション情報１３５は、配信管理サーバ１２５へと送信される。トランスコーダ（図示せず）は、コンフィギュレーション情報１３５によって指定されるようにマルチメディア・コンテンツをフォーマットする。次いで、この結果生ずるフォーマット済みのコンテンツは、ストリーミング・サーバ（図示せず）を介してユーザ１１０に配信することができる。

コンフィギュレーション情報１３５が使用可能でない（または、そうでなければ、更に明確化することを必要とする）場合には、スクリプト１４０のうちの１つとしてユーザ１１０に提供される追加のスクリプトが、プリファランス・ウェブ・ページ１５０をロードする新しいウィンドウを開く。このページを用いて、ユーザ１１０は、プリファランス・ページ１５０中のユーザ・インターフェースを介してコンフィギュレーション情報１３５（例えばこのプレーヤ・タイプおよびバージョン）を明示的に識別することができる。上述と同様に、コンフィギュレーション情報１３５は、クッキーの形態でユーザ１１０の所に保持されることができ、配信管理サーバ１２５へと転送されることができる。

本発明の一実施形態においては、プリファランス・ページ１５０を介してこの配信管理サーバによってこのユーザが選択することができ、または選択すべき特定のメディア・プレーヤについての推奨をこのユーザに対して行うことができる。かかる推奨は、このユーザのオプションについて何が知られているかに基づいている。プリファランス・ページ１５０のかかる一実施形態においては、この推奨は、このページの一部分を介して伝えることができる。このサーバは、このインターフェースを介してこのユーザに通信するので、この部分は、サーバ・インターフェースと考えることもできる。

以下でさらに詳細に説明しているように、このプリファランス・ページは、既知のサイズを有するデータのブロック１５５を含んでいる。ユーザ１１０の接続速度を特定するために、ブロック１５５の転送時間が計測される。本発明の一実施形態においては、（以降では、このタイミング・ブロックとして知られている）ブロック１５５が、プリファランス・ページ１５０中のＨＴＭＬコメント中に組み込まれる。

本発明のコンテキストにおいては、配信管理サーバ１２５は、かかるサーバの組のうちの１つである。ここで、この１組の配信管理サーバは、本明細書中で説明される本発明の手段により、ユーザのコミュニティにサービスを行う。コンテンツを求めるユーザの要求があった場合、このユーザは、複数のユーザによる負荷を均衡させるための選択メカニズムを介して特定の配信管理サーバに割り当てられるはずである。

本発明の一実施形態においては、配信管理サーバ１２５の機能は、トランスコーディング・エンジン（transcoding engine）に対するビューア・ウェブ・サーバ・インターフェース（viewer web server interface）の形で実施される。一般に、このトランスコーディング・エンジンは、コンテンツ・プロバイダからのコンテンツを受信し、このコンテンツをユーザ１１０によって使用可能なようにこのコンテンツをフォーマット（「トランスコード」）する。このビューア・ウェブ・サーバ・インターフェースは、このトランスコーディング・エンジンとユーザ１１０の間のネットワーク・インターフェースであり、このネットワーク・インターフェースにより、ユーザ１１０がコンテンツを要求することができるようになる。このビューア・ウェブ・サーバ・インターフェースは、ユーザ１１０からのコンテンツ要求を受信し処理し、それによってこの要求されたコンテンツのトランスコーディングとユーザ１１０に対する配信を開始する。このビューア・ウェブ・サーバ・インターフェースは、ユーザ１１０の要求に対する応答を送信し、この要求されたメディア・コンテンツを受信するためのものから、適切なストリーミング・サーバへとユーザ１１０をリダイレクトする。次いで、フォーマット済みの（「トランスコード済みの」）コンテンツが、（このトランスコーディング・エンジンの一部分でもある）ストリーミング・サーバおよび／またはプロキシ・サーバによってユーザ１１０に対してストリーミングされる。かかるトランスコーディング・エンジンについては、米国特許第６４０７６８０号、および第６５９３８６０号中にさらに詳細に説明されており、その全体が参照により本明細書に組み込まれている。もう一方の選択肢として、配信管理サーバ１２５およびこのビューア・ウェブ・サーバ・インターフェースは、別々のサーバとして実装することもできる。

本明細書中に説明される本発明は、様々な組織の状況において実装することもできることに留意されたい。例えば、前述のこのトランスコーディング・オペレーションおよび配信管理オペレーションは、配信管理サービスにより実施することができる。このサービスは、例えばコンテンツ・プロバイダ１０５とは独立な別の組織または企業体であってもよい。この場合には、ウェブ・ページ１１５は、コンテンツ・プロバイダ１０５がこの配信管理サービスとは独立に開発することができる。この場合には、ウェブ・ページ１１５は、コンテンツ・プロバイダ１０５に特有のロゴまたは他のブランド・イメージおよび／または外観と雰囲気を含むことができる。同様に、プリファランス・ページ１５０は、配信管理サーバ１２５によってユーザ１１０に対して配信されるが、コンテンツ・プロバイダ１０５がこの配信管理サービスとは独立に開発することもできる。

この配信管理サービスとコンテンツ・プロバイダ１０５との独立性により、この配信管理サービスは、それ自体の上でサービス変更を行うことができるようにもなるはずである。この配信管理サービスは、機能を追加するか、または、修正することにより、自由にそのサービスをアップグレードするはずである。このプレーヤ検出プロセスをより高速により包括的にするために、例えば特定のコンテンツ・プロバイダ１０５とは独立にプレーヤ検出スクリプト１４０を改善することができる。

例えば追加のメディア・フォーマットに対応することができるようにし、またはより高速なトランスコーディングを実現するために、コンテンツ・プロバイダ１０５とは独立に、このトランスコーディング・プロセスをアップグレードすることもできる。この配信管理サーバ１２５は、ハードウェア、ソフトウェア、またはこれらの組合せにより実装することができる。特に、サーバ１２５は、コンピュータ・システムまたは他の処理システムを使用して実装することができる。かかるコンピュータ・システム２００の一実施例が、図２に示されている。コンピュータ・システム２００は、プロセッサ２０４など、１つまたは複数のプロセッサを含んでいる。プロセッサ２０４は、通信インフラストラクチャ２０６（例えば、バスまたはネットワーク）に接続される。様々なソフトウェア実施形態は、この例示のコンピュータ・システムを考慮して説明することができる。この説明を読んだ後には、他のコンピュータ・システムおよび／またはコンピュータ・アーキテクチャを使用して、どのようにして本発明を実装すべきかが、当業者には明らかになろう。

コンピュータ・システム２００はまた、好ましくはＲＡＭ（random access memoryランダム・アクセス・メモリ）である主記憶装置２０８を含み、更に、補助記憶装置２１０を含むこともできる。補助記憶装置２１０は、例えばハード・ディスク・ドライブ２１２、および／または磁気テープ・ドライブ、光ディスク・ドライブなどを表す着脱可能ストレージ・ドライブ２１４を含んでいてもよい。着脱可能ストレージ・ドライブ２１４は、公知の方法で着脱可能ストレージ・ユニット２１８から情報を読み取り、またはそれに情報を書き込み、もしくはその両方を行う。着脱可能ストレージ・ユニット２１８は、磁気テープ、光ディスクなどを表している。当然のことながら、着脱可能ストレージ・ユニット２１８は、それにコンピュータのソフトウェアおよび／またはデータを記憶しているコンピュータ使用可能ストレージ媒体を含んでいる。

補助記憶装置２１０はまた、コンピュータ・プログラムまたは入力データをコンピュータ・システム２００にロードすることができるようにする他の同様な手段を含むこともできる。かかる手段は、例えば着脱可能ストレージ・ユニット２２２およびインターフェース２２０を含んでいてもよい。このような実施例は、（ビデオ・ゲーム・デバイス中で見出されるような）プログラム・カートリッジおよびカートリッジ・インターフェースと、（ＥＰＲＯＭやＰＲＯＭなどの）着脱可能メモリ・チップおよび関連するソケットと、ソフトウェアおよびデータを着脱可能ストレージ・ユニット２２２からコンピュータ・システム２００へと転送することができるようにする他の着脱可能ストレージ・ユニット２２２およびインターフェース２２０を含んでいてもよい。

コンピュータ・システム２００は、通信インターフェース２２４を含むこともできる。通信インターフェース２２４により、ソフトウェアおよびデータをコンピュータ・システム２００と外部デバイスの間で転送することができるようになる。通信インターフェース２２４の実施例は、モデム、（イーサネット（登録商標）・カードなどの）ネットワーク・インターフェース、通信ポート、ＰＣＭＣＩＡスロットおよびカードなどを含むことができる。通信インターフェース２２４を介して転送されるソフトウェアおよびデータは、通信インターフェース２２４が受信することが可能な電子信号、電磁信号、光信号または他の信号とすることができる信号２２８の形式である。これらの信号２２８は、通信経路（すなわち、チャネル）２２６を介して通信インターフェース２２４に供給される。このチャネル２２６は、コンピュータ・システム２００へと、またそこから信号２２８を伝え、ワイヤまたはケーブル、光ファイバ、電話回線、携帯電話網、ＲＦリンクおよび他の通信チャネルを使用して実装することができる。本発明の一実施形態においては、信号２２８は、ＨＴＴＰ要求１３０やコンフィギュレーション情報１３５などの配信管理サーバ１２５によって必要とされる情報を伝えることができる。信号２２８はまた、スクリプト１４０やプリファランス・ページ１５０などの情報もユーザ１１０に対して伝送することもできる。

このドキュメント中では、用語「コンピュータ・プログラム媒体」および「コンピュータ使用可能媒体」を使用して、着脱可能ストレージ・ドライブ２１４、ハード・ディスク・ドライブ２１２にインストールされたハード・ディスク、信号２２８などの媒体のことを一般的に言及している。これらのコンピュータ・プログラム製品は、コンピュータ・システム２００に対してソフトウェアを供給するための手段である。本発明は、部分的にはかかるコンピュータ・プログラム製品も対象としている。

（コンピュータ制御ロジックとも呼ばれる）コンピュータ・プログラムは、主記憶装置２０８および／または補助記憶装置２１０に記憶される。コンピュータ・プログラムは、通信インターフェース２２４を介して受信することもできる。かかるコンピュータ・プログラムは、実行されることにより、コンピュータ・システム２００が、本明細書中で説明される本発明の諸機能を実施することを可能にする。特に、このコンピュータ・プログラムは、実行されることにより、プロセッサ２０４が本発明の諸機能を実施することを可能にする。したがって、かかるコンピュータ・プログラムは、コンピュータ・システム２００のコントローラに相当するものである。

検出方法
好ましい実施形態による方法においては、ユーザのコンピュータのコンフィギュレーション情報が特定され、配信管理サーバへと送信される。次いで、この配信管理サーバは、このコンフィギュレーション情報に従ってマルチメディア・コンテンツをフォーマットするトランスコーダにこのコンフィギュレーション情報を渡す。次いでこのフォーマットされたコンテンツは、このユーザに対して送信されることができる。

本発明の一実施形態による全体的なプロセスが、図３Ａ乃至３Ｄに示されている。このプロセスは、ステップ３０５から開始される。ステップ３１０において、このユーザは、コンテンツ・プロバイダのウェブ・ページをローディングすることを開始する。セクション１１に説明されているように、このウェブ・ページは、サーバ・コンタクト・コードを含んでおり、このサーバ・コンタクト・コードが、この配信管理サーバへとこのユーザのブラウザを誘導する。本発明の一実施形態においては、これは、このコンテンツ・プロバイダのウェブ・ページのＨＴＭＬヘッダ中において実現される。例えば、このＨＴＭＬヘッダは、以下のサーバ・コンタクト・コード、すなわち
<Script SRC="http://js.genericmedia.net/js"LANGUAGE=javascript></SRC>
を含むことができ、ここで「js.genericmedia.net」は、この配信管理サーバを表している。

本発明の一実施形態においては、このサーバ・コンタクト・コードの実行は、このコンテンツ・プロバイダのウェブ・ページ中のコントロールまたはリンクをクリックすることなど、このユーザのアクションによって、または明示的なコマンドを入力することによって開始される。一代替実施形態においては、このサーバ・コンタクト・コードは、このウェブ・ページをロードした後に自動的に実行される。ステップ３２０において、このユーザのブラウザは、この配信管理サーバ（上記例における「js」）からのプレーヤ検出コードをフェッチする。ステップ３２５において、このユーザが使用することができるメディア・プレーヤが特定される。このステップについては、以下でさらに詳細に説明することにする。ステップ３３０において、このメディア・プレーヤの識別情報がこのユーザのコンピュータ中の１つまたは複数のクッキーに記録される。このステップについても、以下でさらに詳細に説明することにする。

このステップに関連して、受信されたコンフィギュレーション情報が、要求されたマルチメディア・コンテンツをフォーマットするのに十分であるかどうかについての判断が、配信管理サーバにおいて行われる（ステップ３３１）。クッキーが受信され、有効な設定を有するものであると検証される場合、最低限のＨＴＴＰ応答が返信され、有効性を示す。この受信されたコンフィギュレーション情報が、この要求されたマルチメディア・コンテンツをフォーマットするのに十分である場合に、処理は、以下で説明しているようにステップ３３５において継続される。（ステップ３３１と同様な）追加の判断ポイントについては、図３Ａに関連して提示および説明されている方法におけるステップ３２０と３２５の間で実行される。すなわち、十分な情報が受信される場合には、プレーヤ検出は、一実施形態において完全にスキップすることもできる。他の実施形態においては、たとえ十分な情報が受信されていたとしても、何らかの軽いプレーヤ検出が行われる。いずれにしても、もしあるとしたら、どのプレーヤ検出コードを送信すべきかについての決定は、このクライアントがこのサーバからそれを要求するときにステップ３２０の後に実施することができる。

jsが有効なクッキーを受信しない場合（すなわち、このユーザの所のコンフィギュレーション情報が不十分であり、または存在しない場合）には、この方法は、ステップ３３２において継続される。ステップ３３２において、プリファランス・ページがこのユーザのために表示される。本発明の一実施形態においては、これは、このプリファランス・ページをロードする新しいウィンドウを開くジャバスクリプト（javascript）（登録商標）のセグメントをこのユーザに送信することによって実現される。このプリファランス・ページにより、このユーザは、この配信管理サーバに対して、このユーザのコンフィギュレーションまたはメディア・プレーヤに関するプリファランス、および／またはこのユーザの接続速度を意図的に示すことができるようになる。本発明の一実施形態においては、このプリファランス・ページは、このユーザに対して特定のメディア・プレーヤが選択されるように推奨することもできる。また以下でさらに詳細に説明しているように、このプリファランス・ページは、このユーザのコンピュータの接続速度を特定し、この配信管理サーバに対して中継することができるようにするメカニズムも含んでいる。

ステップ３３３において、このユーザによって提供されたこれらのプリファランスがこのユーザのコンピュータによって受け取られる。ステップ３３４において、これらのプリファランスは、クッキーに格納される。次いで処理は、ステップ３３５において継続される。ステップ３３５において、このユーザは、ＨＴＴＰ要求を行うことにより、ウェブ・ページを介してこのコンテンツ・プロバイダが使用可能にしているマルチメディア・コンテンツを要求する。かかる要求は、例えばこのコンテンツ・プロバイダのウェブ・ページのある領域をクリックすることによって行うことができる。この要求の一部分として、コンフィギュレーション情報を含む任意のクッキーが、この配信管理サーバに対して送信される。これらのクッキーは、例えばこのメディア・プレーヤのタイプおよびバージョンを記述することができる。これらのクッキーは、このユーザが有しているかもしれない好ましい接続速度の情報だけでなく、この測定された接続速度の情報をも格納することもできる。このユーザは、例えばストリーミングするために使用可能な帯域幅の一部分しか使用したくないと思うこともある。ここで、このユーザは、このユーザのコンフィギュレーションによって許可された最大速度よりも遅い速度を選択するはずである。このプロセスは、ステップ３７０において終了する。

ＨＴＴＰ要求（「GET」）の一実施例は、以下のようである。既存のクッキー（gmPlayers、gmPlayerPref、およびgmBitratePref）が、このGETコマンド、すなわち
GET/xc?p=keith&s=media/Trailer.mov&v=1 HTTP/1.1
Accept: image/gif, image/x xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- powerpoint, application/vnd.ms-excel, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT 5.0)
Host: xc.genericmedia.net
Connection: Keep-Alive
Cookie:gmPlayer=v1%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%
2FWMP-6.4%2F%2F； gm PlayerPref=real; gmBitratePref=300000
の一部分として配信管理サーバに対して送信される。

このサーバは、このＵＲＬ情報およびクッキー情報を使用して、リアルプレーヤＧ２、すなわち
HTTP/1.1 200 OK
Date: Mon, Jul. 16, 2001 23:52:00 GMT
Server: Apache/1.3.14 (Unix) mod_perl/11.24
Connection: close
Expires: Thu, Dec. 1, 1994 16:00:00 GMT
Pragma: no-cache, no-store, must-revalidate, no-transform
Transfer-Encoding: chunked
Content-Type: audio/x-pn-realaudio 41
rtsp://64.124.76.136:554/cache/Mlk3JeFIY0209200d7dn-a/Trailer.rm 0
に適した３００ｋｂｐｓ符号化へとこの映画「media/Trailer.mov」を（ユーザであるキースのアカウントで）トランスコードすることを決定する。

ユーザは、複数のメディア・プレーヤを用いて構成することができることに留意されたい。その場合、このコンテンツをどのようにしてフォーマットするか、すなわちどのプレーヤを選択するかが、明確でないこともある。さらに、このユーザは、他のプレーヤよりもあるプレーヤについて特定の優先順位を有することもある。このプリファランス・ページは、このユーザがプレーヤ・プリファランスをこの配信管理サーバに伝えるようにすることにより、これらの状況を解決する方法を提供している。本発明の一実施形態においては、このプリファランス・ページは、どのメディア・プレーヤがこれらの最良の結果をもたらすことができるかについての推奨をこのユーザに対して伝えることもできる。

上述したプロセスにより、このユーザのコンフィギュレーションを確実に識別することができない場合も存在する。このプレーヤ検出プロセスは、例えばこのユーザのメディア・プレーヤをあいまい性なしに確認することができないこともあり、またこのユーザは、このプリファランス・ページ上でこれらの問合せに対する答え方が十分に分からないこともある。このような場合には、この配信管理サーバは、このユーザのコンフィギュレーションについての既知の内容に基づいて、１つまたは複数の推測を行うこともできる。例えば、このユーザがマッキントッシュ・プラットフォームを有することが知られている場合には、マッキントッシュ・コンピュータには多くの場合にクイックタイムが装備されているので、クイックタイムがこのプラットフォーム上で使用可能であることを一般に想定することができる。かかる他の関連付けを使用して、そうでなければ使用可能でないコンフィギュレーション情報を推論することもできる。本発明の一実施形態においては、このプリファランス・ページを介してこのユーザに確認を求めることにより、かかる推論の確認を行うこともできる。

図３Ｂは、配信マネージャＨＴＴＰ要求３７１を受信することを含めて、本発明の一実施形態によるサーバ側の要求処理を示すフロー・チャートである。ステップ３７２において、配信マネージャ・クッキーが受信されているかどうかが検査される。受信されていない場合、次いでステップ３７３において、クライアントを送信するコードを含むＨＴＴＰ応答が検出ＵＲＬへと送信される。受信されている場合には、次いでステップ３７４において空のＨＴＴＰ応答が戻される。

図３Ｃは、検出ＵＲＬ ＨＴＴＰ要求３７５を受信することを含めて、好ましい実施形態によるサーバ側要求処理を示すフロー・チャートである。ステップ３７６において、このクライアントのコンフィギュレーション情報を特定するために、ＨＴＴＰヘッダが解析される。この特定された情報のうちには、図に示すようにオペレーティング・システム、プラットフォーム、およびＨＴＴＰクライアントまたはユーザ・エージェントが存在する。例えば図７乃至９および他のどこかに関連した本明細書中のさらなる説明から理解されるように、ステップ３７６において特定することができる、クライアント・コンピュータの多数の機能、特性、および差異が存在する。さらに、このサーバにおいて受信することが望まれる特定のアイテムの情報は、図３Ｄに示されるようにこのクライアントに対して示すことができ、以下でさらに詳細に説明している。

このクライアントの帯域幅または接続速度を特定するために、タイマスタート（TimerStart）コードをステップ３７７において送信することができる。ステップ３７８においてデータ・ブロックまたはタイミング・ブロックは、帯域幅を測定するためにこのクライアントに対して送信される。タイマストップ（TimerStop）コードが、ステップ３７９において送信される。一実施形態においては、ステップ３８０において、この帯域幅は、このタイマストップ時刻とタイマスタート時刻との差から決定される時間中に伝えられるデータ量から計算され、クッキーに格納される。以下でより詳細に説明しているように、時間を固定し、この時間中にどれだけ多くのデータが送信されるかに基づいてこの帯域幅を特定する代わりに、このチャンク・サイズまたはタイミング・ブロック・サイズを固定し、これを伝えるためにどれだけ長い時間がかかるかに基づいて帯域幅を特定することができる。この試行（exercise）が、かなり正確な帯域幅特定を行うために必要とされる最小限度の時間より少しだけ長く続くように、このチャンク・サイズまたはタイミング・ブロック・サイズを選択することができることが有利である。ステップ３８１において、クライアント側メディア・プレーヤ検出コードが送信される。

検出メカニズムの詳細
例示の使用シナリオにおいては、ユーザは、一般的にパーソナル・コンピュータまたはＰＤＡ（パーム社（Palm）、ポケットＰＣ（PocketPC））から接続していてもよい。この接続は、一般にＨＴＴＰ要求を行うことができるウェブ・ブラウザまたはメディア・プレーヤからのＨＴＴＰを介したものであってもよい。

このタイプの環境では、一般的にこのクライアント・デバイス・ソフトウェアには書込みを行うことができず、またはそうでなくても制御することができず、その代わりに既存のクライアントの制約条件内で機能するという難しい側面がある。より詳細には、特定の既存のウェブ・ブラウザ（例えば、インターネット・エクスプローラ（Internet Explorer）、ネットスケープ（Netscape）、モジラ（Mozilla）など）へと進む方法がないこともあり、それ故にコンフィギュレーション検出アルゴリズムが、ジャバスクリプトのこれらのサポートの範囲内で機能し、個々のブラウザ・バージョンのバグ／気紛れ（quirk）を回避して機能する必要がある。

同様に、異なるメディア・プレーヤは、様々なレベルのバージョンおよびインストールされたコーデックの問合せをサポートする。多くの場合には（特に旧来のプレーヤでは）、特定のコーデックがインストールされているかどうかを直接的に問い合わせる方法は存在しない。その代わりに、これは既知のコンフィギュレーションに依存して間接的に行われる。例えば、このメディア・プレーヤがウィンドウズ・メディア・バージョン（Window Media Version）７．０である場合には、次いでこのバージョンは、ウィンドウズ・メディア・ビデオ７、マイクロソフトＭＰＥＧ４ｖ３ビデオ・コーデック、およびマイクロソフトＩＳＯ−ＭＰＥＧ４ｖ１ビデオ・コーデックと共に出荷されたことが理解される。

ＰＤＡの場合には、メディア・プレーヤ検出は、一般的にＰＤＡについての現行のメディア・プレーヤ・サポートが限られていることによって簡略化することができる。例えば、パームＯＳ（PalmOS）ベースのＰＤＡ上では、使用可能であり、かつ／またはサポートされているものとしては、１つのビデオ・プレーヤしか存在し得ない。他の実施例としてポケットＰＣ上では、マイクロソフトのポケット・ウィンドウズ・メディア・プレーヤ（Pocket Windows Media Player）が、長い間たった１つの使用可能なプレーヤであった。リアルネットワークとパケットビデオ（PacketVideo）もまた、ＰＤＡ用のプレーヤとして導入されている。限られたプレーヤの選択肢しかないので、この検出ロジックは、多くの場合に所与のＰＤＡと（デフォルトの）メディア・プレーヤとの間の１対１のマッピングへと簡略化することができる。

帯域幅の測定は、ＨＴＴＰおよびジャバスクリプトの制約内で推定することも簡単ではない。帯域幅測定ツールは、一般的にクライアントが既知のデータ量を受信するためにどれだけ長い時間がかかるかを計ることにより、これらの推定を行うことができる。このデータを実際に伝送するのに費やされる時間までにこの時間測定が制限される場合、またこのデータ・サイズが伝送される実際のバイト数を正確に評価する場合には、さらに高い帯域幅の推定精度が取得可能になることもある。複数の測定値を取得して、異常値を平均することが理想的である。

例示の実装形態においては、（検出メカニズムについての）設計要件／制約条件は、以下を含んでいてもよい。
・（ウェブ・ブラウザ中で）ウェブ・ページ内から行う必要がある
・コード／スクリプティング（scripting）は、このクライアントの既存のウェブ・ブラウザ（例えば、ジャバスクリプト、ＶＢスクリプト（VBScript）、ＨＴＭＬ）によってすでにサポートされている言語しか使用してはならない
・ユーザは、ダウンロードされた任意のモジュール／プラグインをインストールする必要があってはならない
・検出はできるだけ速く、またできるだけ侵襲的でないように行われるべきである（理想的には、ユーザは検出コードが実行されていることに気づくべきでない）

これら以上の制約条件内で帯域幅測定を行うためには、ＨＴＭＬおよびジャバスクリプトのコードを介して帯域幅を測定することが、１つの方法となることもある。小さなジャバ・アプレット（Java（登録商標） applet）によって、より細かくより高度な測定アルゴリズムが可能になり得るが、この場合には、ダウンロードされたアプレットとジャバ・ランタイム環境を必要とすることもあり、これらの両方がこれらの設計制約条件に違反する可能性もある。

帯域幅測定は、ＨＴＭＬデータのチャンクが、このクライアントによって受信されるのにどれだけ長い時間がかかるかを計ることによって行うことができることが有利である。「ランダム」ＡＳＣＩＩデータまたは他のランダム・データを使用して、データ圧縮モデム、ルータ、およびウェブ・サーバによる圧縮を防止することが好ましい（この圧縮は、受信される実際のビット数を減少させ、それによってこの帯域幅計算に影響を及ぼすはずである）。ユーザへの影響を最小にするためには、この帯域幅測定の計算が、１回しか実行されないか、または代わりに複数回しか実行されないことが好ましい。約３００ｋｂｐｓのＬＡＮ接続速度のユーザについての正確な測定の必要性に対する、モデム・ユーザついての便宜的な測定の必要性とのバランスを取ると、このデータ・チャンクのサイズは、２０キロバイトに選択することができる。

この場合にも、これらの設計制約条件に起因して、より高度／正確な帯域幅測定技法が望ましくない可能性もある。これらの測定は、依然として計算の破壊（corruption）を受けやすい可能性もある。他のアプリケーションまたはブラウザ・ウィンドウがデータを送信しており、それによって例えばこの伝送時間を遅らせている可能性もある。また中間ルータが、データをバッファしており、それを大きなまとまりで伝送している可能性もある。さらに、データが、依然として中間ルータ／モデムによって圧縮されている可能性もある。このデータは、この最後のネットワーク・リンク上で、例えばそのファイアウォールからこのコンピュータまでバーストしている可能性もあり、あるいは例えばこのブラウザ中で諸セクション中のジャバスクリプトを解析／実行している可能性もあり、これらのセクションのどれかまたはすべてが、この伝送時間を誤って減少させている可能性もある。

ジャバスクリプトをサポートしていないクライアントでは、デフォルトの検出結果を使用することもできる。ユーザは、リンクをクリックして、設定／プリファランスを変更するウェブ・ページへと進むことにより、後の日付のこれらのユーザのプリファランスを変更することができる。デフォルトの検出結果は、（例えば、オペレーティング・システム、ハードウェア・プラットフォームなど）これらのＨＴＴＰ要求ヘッダから収集された情報に基づいて異なるクライアントについて有利にカスタマイズすることもできる。一実施形態においては、マッキントッシュ・クライアントは、デフォルトとしてクイックタイムがインストールされている可能性もあるが、ポケットＰＣクライアントでは、このデフォルトとしてポケット・ウィンドウズ・メディア・プレーヤがインストールされている可能性もある。無線モデム・キャリアを介しての接続については、デフォルト帯域幅が５６ｋｂｐｓであってもよい。

永続性データ
好ましい実装形態では、ユーザのセッションの間で永続性データを格納するために「クッキー」を利用している。クッキーは、ドメインに関連するＨＴＴＰクライアントによって記憶される名称と値のペアである。このクライアントが後続のＨＴＴＰ要求を行うときに、このクライアントは、このＨＴＴＰサーバのドメインに関連するこれらの要求クッキーを用いて送信する。クッキーは、さらにある日付の後に有効期限が切れる（削除される）ように指定することもできる。

例示の実装形態においては、測定された帯域幅、検出されたメディア・プレーヤ（およびこれらのバージョン）、ユーザ・ビット・レート・プリファランス、ストリーミングについてのユーザ・メディア・プレーヤ・プリファランス、および／またはダウンロードされるコンテンツについてのユーザ・メディア・プレーヤ・プリファランスのような物事を格納するために別々のクッキーを作成し／使用することができる。各クッキーは、検出された情報の一部分が古くなってしまっており、再検出するための期限であると考えることができる頻度を設定するために利用することができるそれ自体の有効期限を有していてもよい。

特に、比較的長い時間を費やす検出事項（帯域幅およびインストールされたメディア・プレーヤのバージョン）は、一度実行されたとしたら、また次いで定期的に（またはユーザ要求に応じて）しか再検出することができない。典型的なコンフィギュレーション検出の実装の困難さと複雑さの多くは、サーバ側の環境を書き込み／制御することができることだけに起因している。クライアント側プラットフォーム、ブラウザ、メディア・プレーヤ、スクリプト言語、バグなどは、例えば不変であると考えられるような好ましい実施形態に従って、その範囲内および周囲で必ずしも動作させられる必要があるとは限らないため、有利である。設計要件ごとに、このクライアントのインストールされたソフトウェアをアップグレードし／変更することが、今や可能であってもよいが、一方、特に可能でなくてもよい。

実装の実施例
好ましい実施形態による例示の実装形態においては、このクライアント側の環境にはより多くの自由度があるので、多数の障害を回避することができる。間接的な照会方法を工夫してクライアント・ソフトウェアのコンフィギュレーションまたは機能を特定する代わりに、直接的な照会サポートが最初から有利なように設計に盛り込まれる。同様に、クライアントＨＴＴＰヘッダ値を指定して（かつ／または新しいヘッダを追加して）、詳細なクライアント情報を提供することができる。

この観点から、図３Ｄは、本発明の一実施形態によるさらなる要求処理を示すフロー・チャートである。修正された情報ヘッダ命令が、ステップ３８２において送信される。すなわち、このクライアントがすでに送信済みであるか、または標準的な要求または以前の要求に基づいて送信する準備をしている情報と異なる情報を求める要求が、このクライアントに対して送信される。固有のクライアントＩＤがステップ３８３において送信され、その結果、要求され、次いでこのクライアントから受信されるこの特定の情報は、このクライアントに関連している。例えば、異なる情報を他のクライアントについて要求することもできる。異なるエンド・ユーザ・マシンは、組み込まれた、検出についての固有のＩＤコードを有することができることが有利である。

クライアント・オペレーション３８４乃至３８６は、サーバ・オペレーション３８２乃至３８３によるクライアント側の処理に対する効果を示す。ステップ３８４において、このクライアントは、ステップ３８２に基づいて、受信された命令に肯定応答し、ステップ３８３に基づいてこの要求されたヘッダ情報にクライアントＩＤポインタ・アドレス情報を追加する。このクライアントは、ステップ３８２の命令中において要求される情報に応じて、ステップ３８５において、修正されたヘッダ情報を作成する。ステップ３８６において、このクライアントは、さらなる要求があるとすぐに修正されたヘッダ情報をＩＤと共に送信する。このサブルーチンは、ステップ３８７で終了する。この修正された情報は、以前に受信された情報には含まれなかった情報、またはこのサーバによって望まれていることをクライアントが理解している情報を含む可能性がある。これにより、このサーバが所望のすべての情報を取得することができるようになることが有利である。この修正された情報は、以前に含まれていた情報、またはこのクライアントが他にこのサーバに送信するはずの情報を除外することもできる。特に、一部のデータについて、このサーバで処理すること、それともトランスコードすること、またはそれともメディア・トランスコーディング・サービスを提供すること、もしくはこれらの両方を行うことが望まれないときには、これにより、送信されるデータ量を減少させることができ、有利である。

クライアント・ハードウェア、クライアント・ユーザ・インターフェース・バージョン、または他のクライアント・コンフィギュレーション機能のアダプテーション情報は、このサーバによって要求され、またはこのクライアントから送信され、もしくはその両方が行われたコンフィギュレーション情報に含めることができる。この修正されたヘッダ情報命令は、このアダプテーション情報に従って作成することもできる。これらのアダプテーションは、例えばこのクライアントにおける特定のブラウザ・コンフィギュレーションに従うようにすることもできる。

カスタム・クライアント・ソフトウェアの記述においてより大きな自由度を実現することができるように、実装アーキテクチャの設計要件が設計されるようにすることができる。ジャバスクリプトのプログラミングの制約なしに、例えば（おそらくＣ／Ｃ＋＋で書かれた）カスタム拡張は、より高度なより正確な帯域幅測定アルゴリズムを実装することができる。

検出された情報が、セッションごとに記憶されるように、永続性ストレージの形態を提供することができる。これによって、帯域幅測定に費やされる時間を有利に減少させることが可能になる。これに代わって、この帯域幅推定値は、絶えず、定期的に、またはこのサーバからこのクライアントへと送信されるデータのタイミング／タイムスタンプに基づいて要求に応じて、測定し、またはアップデートし、もしくはその両方を行うこともできる。所与のセッション内において、例えば、検出情報をメモリ中に保持し、その結果、この検出情報は、要求を有するこのクライアントによってこのサーバへと送信することができる。

実装実施例の詳細
前述のように、クライアント機能について直接的に通知することは、間接的に照会することよりも一般的に簡単で効率的である。メディア・プレーヤの検出では、このクライアントは、どのメディア・プレーヤがクライアント上にインストールされているかを速やかに／簡単に知る方法を有することができる点で有利である。一実施形態によれば、フックがこのオペレーティング・システム（またはソフトウェア・インストレーション・マネージャ）中に提供され、その結果、検出ソフトウェアは、どのメディア・プレーヤ・ソフトウェアがインストールされているか、そのメディア・プレーヤ・ソフトウェアは、どのバージョンであるか、どのバージョンのコーデックがインストールされているか、または他のコンフィギュレーション情報、もしくはこれらの組合せについて直接に照会することができるようになっている。この実装が、１つのメディア・プレーヤしかインストールされておらず、かつ／または追加のインストレーションが利用可能でなく、もしくはこの検出管理ソフトウェアがこのメディア・プレーヤに統合されているように行われる場合には、その代わりこのメディア・プレーヤ・ソフトウェアにこの情報を直接に報告させることが有利になる可能性がある。

サーバ側では、通知されたバージョン情報からクライアントの実際のメディア・プレーヤ機能についての直接の相関を行うことができる。例えば、このＶ ＸＹＺビデオ・コーデックのバージョン１．０．４は、このＸＹＺアルゴリズムを用いて圧縮されたビデオを復号化することができるが、このデコーダでは、このビデオのフレーム／サイズの大きさが、８ピクセルの倍数であることが必要になることが知られていることもある。他の実施例では、このクライアントがオーディオ・コーデックＡ ＡＢＣバージョン１．１とオーディオ・コーデックＡ ＤＥＦバージョン３．０を有し、このサーバが他のどのようなオーディオ・コーデックを用いて符号化したデータも送信してはならないことをこのクライアントが報告する場合には、この使用される圧縮アルゴリズムは、このクライアントのオーディオ・コーデックのうちの１つによって復号化可能でなければならない可能性がある。

基本的にすべての帯域幅測定アルゴリズムは、既知のサイズのデータ・チャンクを受信するのにどれだけ長い間かかるかを、または所定の期間にどれだけ多くのデータが伝えられるかを測定することに要約される。このチャンク・サイズまたはタイミング・ブロック・サイズを現行の概算された帯域幅に従って変化させ選択することができるように、１つまたは複数のデータ・チャンクを送信することを含んでいる図５Ｂを参照して、アルゴリズムが以下で有利に、さらに詳細に説明される。

検出情報をこのサーバ側上で使用して、トランスコードされるビット・レートおよびメディア・プレーヤのフォーマット／バージョンを特定することができる。帯域幅とコーデックのすべての可能な組合せの形でトランスコードを実現することは、一般的に非効率的であり、リソースを非常に多く使用する。使用されるコーデックは、例えば、最も一般的にインストールされているものに限られ、符号化されるビット・レートは、最も一般的なターゲット視聴者に対応したビット・レートに、例えば２８．８ｋモデムでは２０ｋｂｐｓに、５６ｋモデムでは３４ｋｂｐｓに、ＩＳＤＮでは９０ｋｂｐｓに、ＤＳＬでは３００ｋｂｐｓに、ケーブル・モデムでは５００ｋｂｐｓに限られてしまうこともある。

図３Ａのステップ３２５に戻って参照すると、プレーヤ検出を実施するステップは、図４Ａにさらに詳細に説明されている。このプロセスは、ステップ４０５から開始される。ステップ４１０において、このユーザがどのブラウザを有するかについての判定が行われる。一般的にこのユーザのブラウザは、ネットスケープ・ナビゲータ（NETSCAPE NAVIGATOR（登録商標））の１バージョン、またはＩＥ（INTERNET EXPLORERインターネット・エクスプローラ（登録商標））の１バージョンであることになる。このユーザが、ネットスケープ・ナビゲータを有する場合、次いでこのプロセスは、ステップ４１１から継続される。ステップ４１１において、所与のメディア・プレーヤについてのストリング探索は、この常駐のＭＩＭＥタイプ・アレイ（mimetype array）およびプラグイン・アレイを介して実施される。このＭＩＭＥタイプ・アレイは、所与のＭＩＭＥタイプを有する応答を受信するとすぐにどのアプリケーションをロードするかについてのマッピングである。所与の任意のメディア・プレーヤは、一般的にそれ自体のＭＩＭＥタイプを有する。このプラグイン・アレイは、インストールされているすべてのブラウザ・プラグインのリストであり、一般的に各ブラウザ・プラグインは、対応するＭＩＭＥタイプを登録している。結果として、これらのアレイは、一般的にこのユーザのコンピュータ上に常駐する１つ（または複数）のメディア・プレーヤを指し示すキャラクタ・ストリングを含むことになる。クイックタイムは、例えばストリング「QuickTime（登録商標）」によって指し示され、ウィンドウズ・メディア・プレーヤは、ストリング「video/x-msvideo」によって指し示される。

ステップ４１３においてこのストリング探索が正常である場合、次いでステップ４１５においてこのプレーヤが存在することが判定される。そうでなければ、処理はステップ４１６から継続される。ステップ４１６において、他のメディア・プレーヤについて求めるべきかどうかについての判定が行われる。そうである場合には、処理は、ステップ４１１へと戻り、ストリング探索が他のメディア・プレーヤについて行われる。したがって例示の実施形態においては、複数のストリング探索が一般に実施されることになるが、本発明は、１つの探索を実施するように実装することもできる。このプロセスは、ステップ４１７において終了する。

少し異なる名前またはプロパティを使用して、所与のプレーヤの異なるバージョンをこのブラウザに登録することができることに留意されたい。ストリング探索によるこれらの区別の検出は、特定のバージョンについての情報を提供することができる。本発明の一実施形態においては、このストリング探索は、ジャバスクリプトを使用して実装される。

ステップ４１０において、このユーザのブラウザがインターネット・エクスプローラであることが判定される場合には、次いでこのプロセスは、ステップ４２０へ継続される。ここで、このブラウザに照会して、所与のメディア・プレーヤおよびバージョンについてオブジェクトをインスタンス化する。本発明の一実施形態においては、このインスタンス化は、Ｖｂスクリプトを使用して行われる。リアルプレーヤのバージョン５オブジェクトの作成は、例えば以下のステートメント、すなわち
CreateObject("RealPlayer.RealPlayer(tm) ActiveX Control (32-bit)"
を用いて試みられるはずである。

ステップ４２５において、このインスタンス化が許可される場合、これは、ステップ４３０に示されるようにこのメディア・プレーヤが、実際にこのユーザのコンピュータ上に存在することを意味する。次いで、このプロセスは、ステップ４４０へ継続される。ステップ４２５においてこの所与のメディア・プレーヤのオブジェクトのインスタンス化が許可されない場合には、次いでこのメディア・プレーヤがこのユーザのコンピュータには常駐していないことを想定することができる。ステップ４４０において、他の任意のメディア・プレーヤの存在について確認すべきであるかどうかについての判定が行われる。確認すべき場合、このプロセスは、ステップ４２０へと戻り、他の試みが行われることになり、今回は異なるメディア・プレーヤについてのオブジェクトをインスタンス化する。ステップ４４０において、他のメディア・プレーヤについては求めないという判定が行われる場合には、次いでこのプロセスは、ステップ４１７において終了する。プレーヤ間の差、特にプレーヤのバージョン間の差は、ステップ４２０においてどのようにしてプレーヤ・オブジェクトがインスタンス化されるかに対応する差によって検出することができる。またバージョン照会をサポートするプレーヤ・オブジェクト（例えば、クイックタイムおよびリアルプレーヤ）では、このプレーヤは、そのバージョンについて直接に問い合わせることもできる。

ウィンドウズ（登録商標）・メディア・プレーヤの検出
図４Ｂは、本発明の例示の一実施形態によるクライアント側ウィンドウズ・メディア・プレーヤ（ＷＭＰ）検出を示すフロー・チャートである。ステップ４４１において、ＷＭＰは、このクライアントのＯＳ／プラットフォーム上で使用可能であるかどうかが検査される。ＷＭＰが使用可能でない場合、次いでステップ４５１においてＷＭＰバージョンはノー（no）に設定され、この方法は、この実施例に従ってリアルプレーヤ検出へと進む。ＷＭＰが使用可能である場合には、次いでステップ４４２において、アクティブエックス（ActiveX）がクライアント・ブラウザ上で使用可能であるかどうかが検査される。イエス（yes）である場合、次いでステップ４４３において、ＷＭＰ７．１またはＷＭＰ８についてのクラスＩＤを作成することができるかどうかが検査される。イエスである場合、次いでステップ４４４において、ＷＭＰバージョンは、バージョン７．１に設定され、このプロセスは、この実施例における図４Ｃによるリアルプレーヤ検出へと進む。ステップ４４３において、ＷＭＰ７．１またはＷＭＰ８についてのクラスＩＤを作成することができないと判定される場合には、次いでステップ４４５において、ＷＭＰ７についてのクラスＩＤを作成することができるかどうかが検査される。ＷＭＰ７についてのクラスＩＤを作成することができる場合、次いでＷＭＰバージョンは、ＷＭＰ７に設定され、このプロセスは、リアルプレーヤ検出へと進む。ステップ４４５において、ＷＭＰ７についてのクラスＩＤを作成することができないと判定される場合には、次いでステップ４４７において、ＷＭＰ６．４についてのクラスＩＤを作成することができるかどうかが検査され、作成することができる場合、ＷＭＰバージョンは、６．４に設定され、作成することができない場合には、次いでこのプロセスは、ステップ４４９へと進む。ここで、ＷＭＰオブジェクトを作成することができるかどうかが検査され、作成することができる場合には、ＷＭＰバージョンはイエス（yes）に設定され、作成することができない場合には、次いでＷＭＰバージョンは、ノーに設定され、どちらの場合にもこのプロセスは、図４Ｃに示されるリアルプレーヤ検出へと進む。

ステップ４４２においてアクティブエックスがこのクライアント・ブラウザ上で使用可能であるかどうかについて検査した結果が、使用可能でない場合には、次いでこのプロセスは、ステップ４５２へと進む。ステップ４５２において、ＭＩＭＥタイプapplication/x-ms-wmdがプラグインによって登録されているかどうかが検査される。登録されている場合、次いでＷＭＰバージョンは、バージョン７に設定され、このＷＭＰ検出プロシージャが終了される。登録されていない場合には、次いでステップ４５３において、ＭＩＭＥタイプapplication/x-ms-wmvがプラグインに登録されているかどうかが検査される。登録されている場合、次いでＷＭＰバージョンは、バージョン６．４に設定され、このサブルーチンが終了される。登録されていない場合には、次いでステップ４５４においてＭＩＭＥタイプapplication/x-msplayer2がプラグインに登録されているかどうかが検査される。登録されている場合、次いでＷＭＰバージョンは、イエスにセットされ、登録されていない場合には、次いでＷＭＰバージョンは、ノーに設定され、どちらの場合にもこのプロセスは、リアルプレーヤ検出へと進む。

リアルプレーヤの検出
図４Ｃは、本発明の例示の一実施形態によるクライアント側のリアルプレーヤ（リアル）検出を示すフロー・チャートである。ステップ４５５において、リアルがこのクライアントのＯＳ／プラットフォーム上で使用可能であるかどうかが検査される。使用可能でない場合、次いでリアルバージョンは、ノーに設定され、このサブルーチンを終了し、このプロセスをクイックタイム検出へと進める。使用可能である場合には、次いでステップ４５６において、アクティブエックスがこのブラウザ上で使用可能であるかどうかが検査される。イエスである場合、次いでステップ４５７において、リアルプレーヤＧ２オブジェクトを作成することができるかどうかが検査される。作成することができる場合、次いでリアルバージョンは、RealPlayerG2Object.GetVersioninfo()に設定され、このプロセスは、図４Ｄに示されるようにクイックタイム検出へと進む。作成することができない場合には、次いでステップ４５９において、リアルプレーヤ・オブジェクトを作成することができるかどうかが検査される。イエスである場合、次いでリアルバージョンはバージョン５に設定され、このサブルーチンを終了し、またノーである場合には、次いでこのプロセスは、ステップ４６１へと進み、ここでリアルビデオ・オブジェクトを作成することができるかどうかが検査される。イエスである場合、このリアルバージョンはバージョン４に設定され、作成することができない場合には、次いでリアルバージョンは、ノーに設定され、どちらの場合にも、このサブルーチンは終了される。

ステップ４５６において、アクティブエックスがこのブラウザ上で使用可能でないと判定される場合には、次いでこのサブルーチンは、図４Ｃに示されるようにステップ４６４へと進み、ここでＭＩＭＥタイプaudio/x-pn-realaudio-pluginがプラグインによって登録されているかどうかが検査される。ステップ４６５において、リアルバージョンは、イエスに設定される。次いで、ステップ４６６において、「RealOne」を含むプラグイン名が存在するかどうかが検査される。存在する場合、次いでリアルバージョンは、ステップ４６７においてOneに設定され、このサブルーチンを終了する。存在しない場合には、次いでステップ４６８において、「RealPlayerG2」を含むプラグイン名が存在するかどうかが検査され、存在する場合、次いでリアルバージョンは、G2に設定され、このサブルーチンを終了する。存在しない場合には、次いでステップ４７０において、「RealPlayer」を含むプラグイン名が存在するかどうかが検査される。存在する場合、次いでリアルバージョンは、バージョン５に設定され、存在しない場合には、次いでステップ４７１において、「Realvideo」を含むプラグイン名が存在するかどうかが検査される。存在する場合、次いでリアルバージョンは、バージョン４に設定され、存在しない場合には、次いでリアルバージョンは、ノーに設定され、どちらの場合にもこのプロセスは、図４Ｄおよびクイックタイム検出へと進む。

クイックタイム・プレーヤの検出
図４Ｄは、本発明の例示の一実施形態によるクライアント側のクイックタイム（ＱＴ）検出を示すフロー・チャートである。ステップ４７２において、ＱＴがこのＯＳ／プラットフォーム上で使用可能かどうかが検査される。ノーである場合、次いでＱＴバージョンは、ノーにセットされ、このサブルーチンを終了する。イエスである場合には、次いでステップ４７３において、アクティブエックスがこのブラウザ上で使用可能であるかどうかが検査される。イエスである場合、次いでステップ４７４において、クイックタイム検査オブジェクトを作成することができるかどうかが検査される。作成することができない場合、次いでＱＴバージョンは、ノーに設定され、作成することができる場合には、次いでこのサブルーチンは、ステップ４７５へと進む。そこでコールQuickTimeCheckObjectVersion.IsQuickTimeAvailable()を使用することにより、クイックタイムが使用可能であるかどうかが検査される。ステップ４７５におけるこの検査の結果がノーである場合、次いでＱＴバージョンは、ノーに設定され、ステップ４７５のこの結果がイエスである場合には、次いでＱＴバージョンは、QuickTimeCheckObject.QuickTimeVersionに設定され、どちらの場合にもこのサブルーチンは、ステップ４８２においてこれらの検出結果を保存するとすぐに終了される。

ステップ４７３において、アクティブエックスがこのブラウザ上で使用可能でないと判断される場合には、次いでステップ４７８において、ＭＩＭＥタイプvideo/quicktimeがプラグインによって登録されているかどうかが検査される。登録されていない場合、このＱＴバージョンは、ノーに設定され、また登録されている場合には、ＱＴバージョンは、ステップ４７９においてイエスに設定される。次いで、ステップ４８０において、「QuickTime Plug-in」を含むプラグイン名が存在するかどうかが検査される。ノーである場合、次いでこのサブルーチンは、終了され、検出結果がステップ４８２において保存される。存在する場合には、次いでＱＴバージョンは、QuickTime Plug-inバージョンに設定され、次いでこれらの結果がステップ４８２において保存され、図４Ｂ乃至４Ｄに示されるプロセス・グループを終了する。

図３Ａのステップ３５５を参照すると、このユーザに対してプリファランス・ページを提示するステップは、本発明の一実施形態に従って図５Ａにさらに詳細に示されている。このプロセスは、ステップ５０５から開始される。ステップ５１０において、このプリファランス・ページは、配信管理サーバからロードされる。ステップ５１５において、このプリファランス・ページ内に格納された、既知のサイズのデータ・ブロックの転送が開始される。このブロックの転送は、このユーザの接続速度を特定するために時間が計られる。このブロックは、以降ではタイミング・ブロックとして示される。本発明の一実施形態においては、このタイミング・ブロックは、このプリファランス・ページ中にＨＴＭＬコメントとして含まれる。その結果、このブラウザは、処理する目的のためにこのタイミング・ブロックを無視する。

同時に、このタイミング・ブロックの転送が開始され、このブラウザは、このタイミング・ブロックの転送が開始する時刻を記録する。ステップ５２０において、このタイミング・ブロックの転送が終了し、この転送が終了する時刻もまた、このブラウザによって記録される。ステップ５３０において、このタイミング・ブロックを転送するために必要とされる時間とその既知のサイズとに基づいてこの接続速度、すなわちデータ転送レートについての計算が行われる。ステップ５３５において、このプリファランス・ページのローディングが終了し、このユーザが有するかもしれないこれらの可能性のあるコンフィギュレーションがこのユーザのために表示される。ステップ５４０において、このコンフィギュレーションに関するこのユーザの入力が受信される。このプロセスは、ステップ５４５において終了する。

このプリファランス・ページは、時には、図３Ａに関して前述したもの以外にも表示することもできる。本発明の一実施形態においては、このユーザには、望むときにはいつでもこれを介してこのプリファランス・ページにアクセスすることができる、コンテンツ・プロバイダのウェブ・ページ中のリンクが与えられる。これにより、このユーザは、意のままにこの述べられているプリファランスを変更することができるようになる。本発明の他の実施形態においては、このプリファランス・ページは、定期的な間隔で、例えば６ヶ月ごとにこのユーザに対して表示される。これにより、このユーザは、このコンフィギュレーション情報の定期的なアップデートを行うことができるようになる。

クッキーの設定に関しては、ブラウザがサーバに対して要求を行うときに、このブラウザは、ただこのサーバのドメインに関連するクッキーを送るだけである。クッキーは、２つの方法、すなわち
１）セット−クッキー：ヘッダ（Set-Cookie: header）は、この新しいドメイン内のサーバから受信される
２）このクッキーは、この新しいドメイン中のサーバからロードされたページによってジャバスクリプトを介して設定される
のうちの一方で新しいドメインに関連づけることができる。

このプレーヤ検出コードは、必ずしも配信管理サーバ・ページから実行されるとは限らないので（例えば、このプレーヤ検出が、コンテンツ・プロバイダのウェブ・ページのヘッダの一部分としてロードされる場合）、これらのクッキーを設定する方法が必要とされる。このゴールは、サード・パーティ・クッキーであり、それによってそうでなければその元のドメイン（コンテンツ・プロバイダのドメイン）に設定されるはずのクッキーは、その代わりにこの配信管理サーバのドメインに対して設定される。本発明の一実施形態においては、これは、ジャバスクリプト内からdummy image( )要求を行うことによって行うことができる。この配信管理サーバのドメインからロードされるイメージの要求を仮定すると、この配信管理サーバは、セット−クッキー：ヘッダを返信することにより応答することができる。

これは、以上のステップ３３０および３３４において適用することができる。例えば、ＵＲＬは、この配信管理サーバにおけるクッキー設定スクリプト（cookie set script）に向けられたこのユーザのコンピュータにおいて構築することができる。次に、ダミー・イメージ・オブジェクトを、このユーザのコンピュータにおいて作成することができる。このオブジェクトは、ジャバスクリプト内からこの配信管理サーバのドメインに対してダミー・イメージ要求を行うことができるようにする以外の目的は果たさない。次いで、このブラウザは、ＨＴＴＰ要求を行い、ダミー・イメージがこの配信管理サーバのドメインからロードされるように求めており、この要求は、このクッキー設定スクリプトを求める要求を組み込んでいる。この配信管理サーバは、これらのクッキーをこのサーバに関連づける（すなわち、セット−クッキー：ヘッダを返信する）ことによって応答する。たとえこのユーザのコンピュータにおけるこれらのクッキーの存在が、このコンテンツ・プロバイダまたは何らかの他のドメインによって最初から決定されていたとしても、これにより、これらのクッキーを、この配信管理サーバに対して送信することができるようになるはずである。このコンフィギュレーション情報は、これらのクッキーに格納される。

ユーザと配信管理サーバの間のこのようなやりとりの実施例が、以下に示されている。
GET/ssp/cookieset?gmPlayerPref=real HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-
powerpoint, application/vnd.ms-excel, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: js.genericmedia.net
Connection: Keep-Alive
Cookie:gmPlayers=v1%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%
2FWM P-6.4%2F%2F;gmPlayerPref=wmf; gmBitratePref=300000
The server then responds:
HTTP/1.1 200 OK
Date: Tue, Jun. 12, 2001 20:08:29 GMT
Server: Apache/1.3.14 (Unix) mod_perl/1.24
Set-Cookie: gmPlayers=v1%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%
2FWMP-6.4%2F%2F;domain=.genericmedia.net;path=/; expires=Mon, Sep. 10, 2001
20:08:29 GMT
P3P: CP="IND OUR PRE UNI ONL COM"
Set-Cookie: gmPlayerPref=real; domain=.genericmedianet; path=/; expires=Mon, Sep.
10, 2001 20:08:29 GMT
Connection: close
Cache-Control: no-cache, max-age=1
Transfer-Encoding: chunked
Content-Type: text/html

図５Ｂは、本発明の一実施形態による帯域幅検出方法を一般的に示すフロー・チャートである。この実施形態において、サブルーチンが、ステップ５５０から開始され、ステップ５５２へと進んで、例えば以前の帯域幅検出またはそれ以外の方法から決定される、推定帯域幅情報をフェッチする。ステップ５５４において、十分な分解能を伴う接続速度を割り出すために、すなわちこの推定された帯域幅情報を使用して、データを取得する推定時間が特定される。ここで、この理由としては、本発明者等がこのタイミング・ブロック・サイズまたはチャンク・サイズがこのステップのこれらの結果に基づいて選択されることを望み、本発明者らが、この推定時間が、許容可能な分解能の範囲内で帯域幅情報を特定することができる最小時間に比べて短くはなく、かつ長すぎないことを望むからである。例えば、この推定時間が、低速の接続速度を有するクライアントに対してあまりにも長すぎるとしたら、ひいてはこの帯域幅測定は、このユーザにとって、いらだたしい、必要とされない遅延を伴うことになるであろう。また一方、例えば非常に高速の接続速度を有するクライアントに対して、この推定された時間があまりにも短い場合には、この特定におけるエラーは、あまりにも大きすぎるか、またはエラーの許容可能なマージンの範囲を超えてしまうことになる。

推定された時間が決定された後に、次いで推定時間をかけて通信されるチャンク・サイズまたはタイミング・ブロック・サイズが、ステップ５５６において決定される。好ましい実施形態によれば、ランダムＡＳＣＩＩデータなどのランダム・データがこのタイミング・ブロックまたはチャンク内で使用され、その結果、モデムは、このデータを圧縮せずに、この推定時間よりも劇的に短い通信時間をもたらし、この分解能許容範囲外の結果を残すことになる。

およそこの推定時間がかかることになるタイミング・ブロック・サイズまたはチャンク・サイズが決定された後に、次いでこの決定されたサイズのタイミング・ブロックまたはデータ・チャンクは、ステップ５５８においてこのクライアントに対して通信される。このタイミング・ブロックを通信するためにかかる実際の時間が測定される。次いで、この帯域幅は、ステップ５５８において送信されたこのデータ・チャンクまたはタイミング・ブロックのサイズ、および、このクライアントによるこの測定された取得時間に基づいて、ステップ５６０において特定される。図５Ｂに示されるこのサブルーチンは、ステップ５６２において終了される。

実施形態に従ったメディア・コンテンツへのアクセス
本明細書中で説明しているように、好ましい実施形態によるシステムおよび方法は、メディア・コンテンツにアクセスするビューアの要求に応じて、オンデマンドでメディア・コンテンツのトランスコーディングを実施する。さらに、好ましい実施形態は、基本的にはこのメディア・コンテンツ配信プロセスの一部分として、このメディア・コンテンツの発行の後に「リアルタイム」にメディア・コンテンツのトランスコーディングを実施する。個々の実施形態においては、このメディア・トランスコーディング・エンジン（参照により組み込まれている米国特許第６４０７６８０号および米国特許出願第１０／６４４６０２号を参照）に対してメディア・コンテンツを閲覧する要求をサブミットしてから、ビューア・クライアントに対してこのメディア・コンテンツを配信するまでの遅延は、およそ３０秒以下になる。しかし、本発明は、特定の配信時間だけには限定されることなく、３０秒を上回り、または下回る様々な配信時間を包含することもできる。

図６Ａ乃至６Ｃは、本発明の実施形態による、メディア・コンテンツをビューアがアクセスするための方法のフロー・チャート１５００を示している。しかし、本発明は、フロー・チャート１５００によって提供される説明だけに限定されるものではない。もっと正確に言えば、他の機能フローも、本発明の範囲および趣旨の範囲内に含まれることが、本明細書中のこれらの教示から当業者には明らかなはずである。

図６Ａのステップ１５０２において、このビューアは、このメディア・トランスコーディング・エンジン内のビューア・ウェブ・サーバ・インターフェースに対して、このビューア・クライアントを経由してメディア・コンテンツにアクセスする要求を送信する。実施形態において、この要求は、このビューアがこのコンテンツ・プロバイダのウェブ・サイト上でＵＲＬをクリックするときに、このビューア・クライアントが生成するＨＴＴＰ要求である。以上に説明されるように、このメディア・コンテンツ発行プロセス中にこのコンテンツ・プロバイダに対してこのメディア・トランスコーディング・エンジンが提供することができるＵＲＬリンクは、このビューア・クライアントにこのメディア・トランスコーディング・エンジンを指し示すアドレス情報およびソース情報を含み、このメディア・トランスコーディング・エンジンに対してこの要求されたメディア・コンテンツのソースについての情報を提供する。このビューア・ウェブ・サーバ・インターフェースが、この要求を受信した後に、このインターフェースは、この要求をタスク・マネージャへと転送する（この場合にも、参照により組み込まれている米国特許第６４０７６８０号および米国特許出願第１０／６４４６０２号を参照されたい）。

ステップ１５０４において、このタスク・マネージャは、この要求を解析して、この要求にサービスを行うために必要な要求情報が含まれているかどうかを判定する。この要求がＨＴＴＰ要求を含む本発明の実施形態においては、このタスク・マネージャは、このＨＴＴＰ要求のヘッダを解析して、この要求にサービスを行うために必要な情報が含まれるかどうかを決定する。実施形態においては、この必要な情報は、少なくとも１つのソース・ロケーション、１つのソース・タイプ、１つの宛先ロケーション、および１つの宛先タイプを含んでいる。このソース・タイプおよび宛先タイプは、それぞれ少なくとも１つの発行変数によって定義される。実施形態においては、メディア・コンテンツについての発行変数は、それだけには限定されないが、このファイル・フォーマット、ビット・レート、１つ（または複数）の通信プロトコル、物理媒体、圧縮アルゴリズム、デジタル権限管理情報、またはこれらの任意の組合せを含むことが可能である。一実施形態においては、この要求にサービスを行うために必要とされる情報は、少なくとも１つのソース・ロケーション、ソース・フォーマット、ソース・ビット・レート、宛先ロケーション、宛先フォーマット、および宛先ビット・レートを含んでいる。

このタスク・マネージャが、この要求情報が完全でないと判定する場合、このタスク・マネージャは、ステップ１５０６および１５０８に示されるようにこの必要な情報をフェッチすることになる。例えば、このソース・タイプまたはソース・ロケーションがこの要求中に含まれておらず、この要求されたメディア・コンテンツがこのメディア・トランスコーディング・エンジン内に記憶されている場合、このタスク・マネージャは、データベースを調べて、この必要なソース情報を見出すことができる。代わりに、このメディア・コンテンツが、このメディア・トランスコーディング・エンジンに関してその外部に記憶されている場合には、このタスク・マネージャは、ネットワーク要求を実施して、このコンテンツ・プロバイダのウェブ・サイトからこの必要な情報をフェッチすることができる。例えば、このタスク・マネージャは、ＨＴＴＰ要求、ＲＴＳＰ要求、または他のどのような標準ネットワーク・アプリケーション・プロトコルを使用した要求も実施することができる。さらに、この宛先タイプが使用可能でない場合には、このタスク・マネージャは、このビューア・クライアントに照会することにより、この必要とされる情報をフェッチすることもできる。前述のように、実施形態においては、この宛先ロケーションについての最適な宛先タイプは、このビューア・クライアント上の「クッキー」として記憶することもでき、これらのクッキーは、このタスク・マネージャによってアクセスすることができる。

ステップ１５１０において、このタスク・マネージャが、この要求にサービスを行うためにこの必要な情報を得た後に、次いでこのタスク・マネージャは、この要求されたメディア・コンテンツを配信するためにどのタスクを実行する必要があるかを決定する。これらのタスクは、この要求されたメディア・コンテンツを配信するために必要なすべてのステップを含んでおり、この要求されたメディア・コンテンツをフェッチすること、このソース・タイプからこの宛先タイプへとこの要求されたメディア・コンテンツをトランスコードすること、およびこのトランスコードされたメディア・コンテンツをこのビューア・クライアントに対してストリーミングすることを含むことができる。このタスク・マネージャが、どのタスクを実行する必要があるかを決定した後に、次いでこのタスク・マネージャは、リソース・マネージャ（この場合にも、参照により組み込まれている米国特許第６４０７６８０号および米国特許出願第１０／６４４６０２号を参照されたい）と通信し、このリソース・マネージャにこれらの要求されたタスクを実行するように指示する。

このリソース・マネージャは、この指示を受け取って、このタスク・マネージャから要求されたタスクを実行し、ステップ１５１２において、このマシン・ファーム（machine farm）内の１つまたは複数のマシンに各タスクを割り当てる。このリソース・マネージャは、これらの使用可能なリソースにより、効率的なタスクの実行を達成するようにプログラムされる。実施形態においては、このリソース・マネージャによるリソースの所与のタスクへの割付けは、それだけには限定されないが、どのマシンが、この必要とされるタスクを実施するための必要なユーティリティをサポートするか、どのマシンが、使用可能なリソース（例えば、使用可能なＣＰＵ）を有するか、実行するために協調が必要とされるときに、どのマシンが互いに協調してこのタスクを実行することができるかを含む、様々なファクタに基づいて決定される。このリソース・マネージャは、ネットワーク輻輳の回避を含む、様々な他の判断基準に基づいてタスクを配信するようにもプログラムすることができる。例えば、このリソース・マネージャは、伸張タスクおよび圧縮タスクをこの同じマシンに対して割り当てるようにプログラムして、このメディア・トランスコーディング・エンジンの内部ネットワーク内の１つのマシンから他のマシンへと圧縮されていないデータを伝送することにより発生するかもしれないネットワーク輻輳を回避することもできる。

好ましい実施形態によれば、このリソース・マネージャは、これらのタスクが割り当てられた後にタスクを監視して、これらのタスクが適切に実行されることを確認する。このリソース・マネージャは、このデータベース中のすべての割り当てられたタスクのリストを保持し、所与のタスクを実行する各マシンのスレーブ・モニタと定期的に通信を行ってこのタスクの状態を決定することにより、この割り当てられた諸タスクの実行を監視する。

実施形態においては、このリソース・マネージャは、このタスクが割り当てられているマシンのスレーブ・モニタを定期的にポーリングして、このタスクのステータスを決定する。代替実施形態においては、このスレーブ・モニタそれ自体は、定期的なステータス・メッセージをこのリソース・マネージャに送信し、割り当てられたタスクのステータスについてこのリソース・マネージャに通知する。このリソース・マネージャは、必要な諸タスクを割り当て監視するその機能を支援するために、リソース・マネージャがこのデータベース中の各タスクおよび各マシンのステータスについてこれらのスレーブ・モニタから受信する情報を記憶する。

代替実施形態においては、これらのスレーブ・モニタは、このリソース・マネージャから受信されるタスクを開始するにすぎず、これらのタスク自体は、これらのスレーブ・モニタに対してではなくて、このリソース・マネージャに対して直接に通知する。

このリソース・マネージャは、このリソース・マネージャが、いつタスクが失敗したかを特定し、この問題を訂正し、この要求されたメディア・コンテンツの配信を確実にするための必要なステップを実行することができるようにするフォールト・トレランス・ルーチンに従って、割り当てられた各タスクを監視する。例えば、タスクが割り当てられているマシンが、所定の期間の間ステータス照会に応答しない場合には、このリソース・マネージャは、異なるマシンに対してこのタスクを再割り当てし、応答していないマシンをリブートするようにプログラムすることができる。さらに、タスクの失敗が、一連の分散された従属するタスクの失敗ももたらす場合には、このリソース・マネージャは、これらのすべての従属するタスクをシャットダウンし、この全体のタスクのセットを再割り当てして、この要求されたメディア・コンテンツの配信を確実にするようにプログラムすることもできる。これらの実施例は、限定的なものではなく、他のフォールト・トレランス・スキームも本明細書中に含まれる教示に基づいて当業者には明らかになるはずであり、本発明は、このような他のフォールト・トレランス・スキームも対象としている。

さらなる実施形態において、個々のタスクにはそれぞれ優先順位が割り当てられる。このリソース・マネージャは新しい諸タスクを監視し、既存のタスクの優先順位が、割り当てられる必要のある新しいタスクの優先順位よりも低いときに、このリソース・マネージャは、この既存のタスクにそれ自体を消滅させて、この新しいより高い優先順位のタスクに対応することができるように指示することになる。代わりに、このスレーブ・モニタがこの既存のタスクを消滅させることも可能である。低優先順位のタスクの一実施例は、ビューアがこの要求されたコンテンツを閲覧することを停止した後のこのビューアのためのメディア・コンテンツのトランスコーディングを含んでいる。

ステップ１５１４において、これらのすべてのタスクが割り当てられた後に、このタスク・マネージャは、最初の要求に対する応答を構築して、このビューア・クライアントから受信されるメディア・コンテンツにアクセスする。この応答は、ストリーミング・サーバまたはプロキシ・サーバに対してこのビューア・クライアントをリダイレクトする役割を果たし、この要求されたメディア・コンテンツは、最終的にこのサーバからこのビューア・クライアントによって受信されることになる。実施形態においては、この応答はＨＴＴＰ応答を含んでいる。

ステップ１５３２において、好ましい一実施形態による自動的なソース・タイプ検出が作動されているかどうかについての判定が行われる。このシステムは、永続的に自動的ソース・タイプ検出をオンに、または自動的ソース・タイプ検出をオフに設定することもでき、もしくはこのシステムは、選択的に切り替えることもできる。この自動的ソース・タイプ検出が、永続的にオンまたはオフである場合、次いでこの判定は必要ではなく、この方法は、この対応するステップ１５３４または１５３６へと進むことができる。図６Ｂに示される方法においては、この判定が行われた後に、次いでこの方法は、この次の対応するステップへと進む。すなわち、自動的ソース・タイプ検出が作動されている場合、次いでステップ１５３４において、ソース・タイプ情報は、ソース・サーバまたはクライアントから自動的にフェッチされる。利点は、これがこのユーザにとってより速くより簡単であることである。一方、自動的ソース・タイプ検出が停止されている場合には、次いでステップ１５３６において、このコンテンツを要求しているユーザからソース・ユーザ・インターフェースを介して入力が要求される。利点は、このコンテンツについて複数のソース・タイプを有するユーザが、これらの間で選択することができることであるか、あるいはこのソースがファイアウォールを有する場合には、このソース・タイプはユーザ入力を用いて簡単に検出することができないようになってしまう。

ステップ１５３８において、好ましい一実施形態による自動的宛先タイプ検出が作動されているかどうかについての判定が行われる。このシステムは、永続的に自動的宛先タイプ検出をオンに、または自動的宛先タイプ検出をオフに設定することもでき、あるいはこのシステムは、選択的に切り替えることもできる。この自動的宛先タイプ検出が、永続的にオンまたはオフである場合、次いでこの判定は必要ではなく、この方法は、この対応するステップ１５４０または１５４２へと進むことができる。図６Ｂに示される方法においては、この判定が行われた後に、次いでこの方法は、この次の対応するステップへと進む。すなわち、自動的宛先タイプ検出が作動されている場合、次いでステップ１５４０において、宛先タイプ情報は、宛先サーバまたはクライアントから自動的にフェッチされる。利点は、これがこのユーザにとってより速くより簡単であることである。一方、自動的宛先タイプ検出が停止されている場合には、次いでステップ１５４２において、このコンテンツを要求しているユーザから宛先ユーザ・インターフェースを介して入力が要求される。利点は、このコンテンツについて複数の宛先タイプを有するユーザが、これらの間で選択することができることであり、あるいはこの宛先がファイアウォールを有する場合には、この宛先タイプはユーザ入力を用いて簡単に検出することができないようになってしまう。

宛先タイプと独立したさらなる判断基準は、例えば、このメディア・コンテンツの発行者によって設定されるような指定された規則に基づいて、あるいはそうでなければビジネス規則に基づいて検出し適用することができる。例えば、帯域幅判断基準は、顧客の契約に基づいたものとすることができ、あるいは予告編もしくはクリップまたはこれらの両方を発行者による要求があるとすぐにこのトランスコードされたメディア・コンテンツと共に挿入することができる。

図６Ｃのステップ１５１６乃至１５２６において、このマシン・ファーム内のこれらのマシンは、このリソース・マネージャから受信されるこれらの割り当てられたタスクに従って、この要求されたメディア・コンテンツを配信するのに必要なこれらのステップを実施する。本発明の実施形態においては、このメディア・コンテンツの配信は、同じメディア・コンテンツ・ストリームの異なる部分のフェッチ、トランスコーディングおよびストリーミングを同時に行うことができるパイプライン化されたプロセスである。このリソース・マネージャは、このメディア・トランスコーディング・エンジン内におけるリソース割付けを介してこれらのステップのパイプライン化のためのアレンジを行う。これらのステップのパイプライン化は、このメディア・トランスコーディング・エンジンによる要求されたメディアについてのより高速な配信時間をもたらす。

ステップ１５１６に示されるように、この要求されたメディア・コンテンツがこの適切な宛先タイプ（例えば、この適切な宛先フォーマットおよびビット・レート、または他の適切な発行変数）にトランスコードされたトランスコード化キャッシュ中に存在する場合、次いでこのコンテンツの配信は、ステップ１５２４においてストリーミング・サーバによって達成され、このストリーミング・サーバは、このトランスコードされたメディア・コンテンツをこのビューア・クライアントへとストリーミングする。

しかし、この要求されたメディア・コンテンツが、この適切な宛先タイプにトランスコードされたトランスコード化キャッシュ中に存在しない場合には、次いでこのマシン・ファーム内の１つまたは複数のトランスミッタ・サーバは、ステップ１５１８に示されるようにこのソース・ロケーションからのデータ・ストリームとしてこの要求されたメディア・コンテンツをフェッチすることを開始する。図３Ａ乃至３Ｂおよび４Ａ乃至４Ｄに関して以上で説明したように、本発明の実施形態においては、この要求されたメディア・コンテンツは最初に、このメディア・トランスコーディング・エンジン内のマスタ・アーカイブ内に、またはこのメディア・トランスコーディング・エンジンの外部のアーカイブ中に存在することもでき、あるいはこのコンテンツ・プロバイダ・クライアントから直接にストリーミング・フィード（streaming feed）として受信することもできる。この要求されたメディア・コンテンツが、このマスタ・アーカイブ内に存在する場合には、これらのトランスミッタ・サーバのうちの１つが、このメディア・トランスコーディング・エンジンの内部ネットワーク上でこの要求されたメディア・コンテンツをフェッチする。

この要求されたメディア・コンテンツが、このメディア・トランスコーディング・エンジンの外側のアーカイブ中に存在する場合には、この要求されたメディア・コンテンツをフェッチするために、これらのトランスミッタ・サーバのうちの１つは、この発行プロセス中に提供されるアクセス情報を使用する。実施形態においては、このトランスミッタ・サーバが、要求されたメディア・コンテンツをフェッチするために、このアクセス情報を使用した後に、この要求されたメディア・コンテンツは、このマスタ・アーカイブに一時的にキャッシュされることができ、この同じメディア・コンテンツについての後続の要求がこのメディア・トランスコーディング・エンジンによって受信される場合、このメディア・コンテンツに対する効率の良いアクセスを可能にすることができる。

この要求されたメディア・コンテンツが、このコンテンツ・プロバイダ・クライアントからの直接なストリーミング・フィードである場合には、これらのトランスミッタ・サーバのうちの１つは、このコンテンツ・プロバイダ・ウェブ・サーバ・インターフェースからこのストリーミング・データをフェッチする。本発明の実施形態は、それがビューアによって実際に要求されるまで、このストリーミング・データをフェッチしトランスコードすることを行わないので、これにより、メディア・コンテンツの不必要なトランスコーディングが回避される。

ステップ１５２０に示されるように、このトランスミッタ・サーバが、この要求されたメディア・コンテンツのフェッチを開始した後に、このソース・タイプがこの宛先タイプと同じである（例えば、このソースのフォーマットおよびビット・レートが、この宛先のフォーマットおよびビット・レートと同じである）場合、次いでトランスコーディングは必要ではなく、このメディア・コンテンツは、これがフェッチされるとすぐにこのストリーミング・サーバに対して伝送される。次いでステップ１５２４において、このストリーミング・サーバは、以下で説明されるように、このビューア・クライアントに対してこのコンテンツをストリーミングする。しかし、このソース・タイプが、この宛先タイプと同じでない場合には、次いでこのマシン・ファーム内のこれらのトランスミッタ・サーバのうちの１つは、ステップ１５２２に示されるように、このメディア・コンテンツをこのソース・タイプからこの宛先タイプへとトランスコードすることになる。ステップ１５１２に関するこの考察によれば、このリソース・マネージャは、発行変数の適切な変換を実施するために、この必要なトランスコーダ・ソフトウェアを実行するトランスコーダ・サーバにこのトランスコーディング・タスクを割り当てる。実施形態においては、このトランスコーディングは、様々なよく知られている方法のうちの１つを使用して、１タイプのメディア・コンテンツを他のタイプのメディア・コンテンツへと変換するために実行され、メディア・コンテンツをトランスコードするための従来のコーデック・ルーチンを含んでいる。トランスコーディング・オペレーションおよび実施例のさらなる説明が、以下に提供される。実施形態においては、このトランスコーディングが完了した後に、このトランスコードされたメディア・コンテンツのコピーが一時的にこのトランスコード化キャッシュに記憶され、この同じ宛先タイプにトランスコードされたこの同じメディア・コンテンツについての後続の要求が、このメディア・トランスコーディング・エンジンによって受信される場合、このメディア・コンテンツの効率の良い配信が可能になる。

ステップ１５２４において、これらのストリーミング・サーバのうちの１つは、このメディア・コンテンツが、トランスコーダ、トランスミッタ、またはこのトランスコード化キャッシュから受信されるとすぐに、このビューア・クライアントに対してこの適切な宛先タイプのメディア・コンテンツをストリーミングする。実施形態においては、このトランスコードされたメディア・コンテンツは、オプションのプロキシ・サーバを経由してこのビューア・クライアントに対してストリーミングされる。さらなる実施形態においては、このストリーミング・サーバまたはこのオプションのプロキシ・サーバは、配信されるこのメディア・コンテンツに属する使用統計値のみならず、キャッシュ管理の目的のためにこのリソース・マネージャによって使用されるメディア・コンテンツが配信されるこれらの宛先タイプを保持する。

実施形態においては、このビューア・クライアントに対してメディアをストリーミングし、これらのトランスミッタ・サーバ、トランスコーダ・サーバおよびストリーミング・サーバの間でデータをストリーミングするために使用されるプロトコルは、ＲＴＳＰなど、メディアをストリーミングするための標準プロトコルである。これに代わって、ＴＣＰ／ＵＤＰのような標準ネットワーク・プロトコル上で定義される独自開発プロトコル（proprietary protocol）を使用することもできる。さらなる実施形態においては、異なるプロトコルを使用して、異なるネットワーク・インフラストラクチャのニーズに対応できるようにすることもできる。例えば、ネットワーク・トラフィック状態に従って動的に変化するプロトコルを実装することもできる。しかし、これらの実施例は、例示である。本発明は、特定の通信プロトコルまたはアプリケーションだけに限定する意図はなく、他の独自開発のまたは非独自開発のネットワーク通信プロトコルおよびアプリケーションを用いることもできる。

ステップ１５２６において、このビューア・クライアントは、このストリーミング・サーバまたはこのプロキシ・サーバからのストリーミング・メディア・コンテンツを受信する。このポイントにおいて、このビューア・クライアントは、このビューア・クライアント上に常駐するこのメディア・プレーヤに関連する宛先タイプに従ってこのメディア・コンテンツを再生する。本発明の代替実施形態においては、このメディア・コンテンツは、その後になって再生するための、または代わりのメディア再生デバイスに転送するために、このビューア・クライアント上のダウンロードされたファイルとして受信し、記憶することもできる。ステップ１５２６の後に、このフロー・チャート１５００は終了する。

メディア・コンテンツの実施例
米国特許第６４０７６８０号中で説明されているように、例えばメディア・トランスコーディング・エンジンは、１つまたは複数のトランスコーダを含んでいてもよい。トランスコーダは、（本明細書中でソース・タイプと呼んでいる）ある種のタイプのメディア・コンテンツを（本明細書中で宛先タイプと呼んでいる）他のタイプのメディア・コンテンツへと変換する。トランスコーディングは、いくつかの異なる変換オペレーションに関与する可能性がある。この使用される個々の変換オペレーションは、このメディア・コンテンツと、変換される関連する発行変数とに依存する。これが、宛先となり得るクライアントのコンフィギュレーション情報の効率的な検出が有利になる理由である。本明細書中で使用される発行変数は、メディア・コンテンツの異なる特性を意味している。

好ましい実施形態によれば、メディア・コンテンツは、ネットワーク上で発行されるデジタル・データである。この場合には、発行とは、ネットワーク上で配信するために、かつ宛先メディア・プレーヤによって閲覧するためにフォーマットされており、デジタル・データのことを意味する。メディア・コンテンツについての発行変数は、それだけには限定されないが、このファイル・フォーマット、ビット・レート、１つ（または複数）の通信プロトコル、物理媒体、圧縮アルゴリズム、および／またはデジタル権限管理情報を含むことが可能である。

このデジタル・データは、それだけには限定されないが、コンテナ・フォーマット、ビットマップ・フォーマット、ビデオ・フォーマット、オーディオ・フォーマット、ベクトル・フォーマット、メタファイル・フォーマット、シーン・フォーマット、アニメーション・フォーマット、マルチメディア・フォーマット、ハイブリッド・フォーマット、ハイパーテキスト・フォーマットおよびハイパーメディア・フォーマット、３次元（３Ｄ；three dimensional）データ・フォーマット、仮想現実モデリング言語（ＶＲＭＬ；virtual reality modeling language）フォーマット、フォント・フォーマット（ビットマップ・フォント、ストローク・フォント、スプラインベースのアウトライン・フォント）、ページ記述言語（ＰＤＬ；page description language）フォーマット、および他の任意タイプのグラフィックス・ファイル・フォーマットまたは他のファイル・フォーマットを含めて、任意のタイプのファイル・フォーマットとすることが可能である。表１は、本発明の実施形態中で使用することができるこのようなファイル・フォーマットの実施例をリストアップしたものである。
表１
実施例のファイル・フォーマット
フォーマット タイプ
アドビ・イラストレータ メタファイル
アドビ・フォトショップ ビットマップ
アタリＳＴグラフィックス・フォーマット ビットマップおよびアニメーション
オートキャドＤＸＦ ベクトル
オートデスク３Ｄスタジオ シーン記述
ＢＤＦ ビットマップ
ＢＲＬ−ＣＡＤ 他
ＢＵＦＲ 他
ＣＡＬＳラスタ ビットマップ
ＣＧＭ メタファイル
ＣＭＵフォーマット マルチメディア
ＤＫＢ シーン記述
ＤＯＲＥラスタ・ファイル・フォーマット ビットマップ
ＤＰＸ ビットマップ
ＤＲ．ＨＡＬＯ ビットマップ
ＤＶＭムービー アニメーション
カプセル化ポストスクリプト メタファイル（ページ記述言語）

ＦＡＣＥＳＡＶＥＲ ビットマップ
ＦＡＸフォーマット ビットマップ
ＦＩＴＳ 他
ＦＬＩ アニメーション
ＧＥＭラスタ ビットマップ
ＧＥＭ ＶＤＩ メタファイル
ＧＩＦ ビットマップ
ＧＲＡＳＰ アニメーション
ＧＲＩＢ 他
ハーバード・グラフィックス メタファイル
階層的データ・フォーマット メタファイル
ＩＦＦ ビットマップ
ＩＧＥＳ 他
ＩＮＳＥＴ ＰＩＸ ビットマップ
インテルＤＶＩ マルチメディア
ＪＰＥＧファイル交換フォーマット ビットマップ
コダック・フォトＣＤ ビットマップ
コダックＹＣＣ ビットマップ
ロータスＤＩＦ ベクトル
ロータスＰＩＣ ベクトル
ＬＵＭＥＮＡペイント ビットマップ
マッキントッシュ・ペイント ビットマップ
マッキントッシュＰＩＣＴ メタファイル
マイクロソフト・ペイント ビットマップ
マイクロソフトＲＩＦＦ マルチメディア
マイクロソフトＲＴＦ メタファイル
マイクロソフトＳＹＬＫ ベクトル
マイクロソフト・ウィンドウズ・ビットマップ ビットマップ
マイクロソフト・ウィンドウズ・メタファイル メタファイル
ＭＩＦＦ ビットマップ
ＭＰＥＧ 他
ＭＴＶ シーン記述
ＮＡＰＬＰＳ メタファイル
ＮＦＦ シーン記述
ＯＦＦ シーン記述
ＯＳ／２ビットマップ ビットマップ
Ｐ３Ｄ シーン記述
ＰＢＭ．、ＰＧＭ．、ＰＮＭ．、およびＰＰＭ． ビットマップ
ＰＣＸ ビットマップ
ＰＤＳ 他
ＰＩＣ ＴＯＲ ＰＣペイント ビットマップ
ピクサーＲＩＢ シーン記述
ＰＬＯＴ−１０ ベクトル
ＰＮＧ ビットマップ
ＰＯＶ ベクトル
プレゼンテーション・マネージャ・メタファイル メタファイル
ＰＲＴ シーン記述
ＱＲＴ シーン記述
クイックタイム 他
ＲＡＤＩＡＮＣＥ シーン記述
ＲＡＹＳＨＡＤＥ シーン記述
ＲＩＸ ビットマップ
ＲＴＲＡＣＥ シーン記述
ＳＡＦ ビットマップおよび他
ＳＥＮＳＥ８ ＮＦＦ シーン記述
ＳＧＩイメージ・ファイル・フォーマット ビットマップ
ＳＧＩ ＩＮＶＥＮＴＯＲ シーン記述
ＳＧＩ ＹＡＯＤＬ シーン記述
ＳＧＯ ベクトル
ＳＰＩＦＦ ビットマップ
ＳＵＮアイコン ビットマップ
ＳＵＮラスタ ビットマップ
ＴＤＤＤ ベクトルおよびアニメーション
ＴＧＡ ビットマップ
ＴＩＦＦ ビットマップ
ＴＴＤＤＤ ベクトルおよびアニメーション
ＵＲＡＹ シーン記述
ＵＴＡＨ ＲＬＥ ビットマップ
ＶＩＣＡＲ２ ビットマップ
ＶＩＦＦ ビットマップ
ＶＩＳ−５Ｄ ベクトル
ＶＩＶＩＤ ＡＮＤ ＢＯＢ シーン記述
ＷＡＶＥＦＲＯＮＴ ＯＢＪ ベクトル
ＷＡＶＥＦＲＯＮＴ ＲＬＡ ビットマップ
ワードパーフェクト・グラフィックス・メタファイル メタファイル
ＸＢＭ ビットマップ
ＸＰＭ ビットマップ
ＸＷＤ ビットマップ
ＺＢＲ メタファイル
Murray and vanRyper、12乃至26頁を参照されたい。これらの実施例は、例示的なものであり、本発明を限定することを意図してはいない。本明細書を提供された当業者には明らかなはずであるように、（現在知られている、または将来開発される）他のファイル・フォーマットについても使用することができる。

同じファイル・フォーマット内においてさえ、デジタル・データは、異なる圧縮アルゴリズムに従って圧縮することができる。クイックタイムでフォーマットされたファイルにおいては、例えばビデオは、Ｈ．２６３規格、ＣＩＮＥＰＡＫ規格、ＪＰＥＧ規格、ＱＴアニメーション規格、またはＱＴビデオ規格に従って圧縮することができる。さらなる実施例として、ウィンドウズ・メディアＡＳＦでフォーマットされたファイルにおいては、オーディオは、マイクロソフト・オーディオ・フォーマット規格、ＡＣＥＬＰ規格、ＶＯＸＷＡＲＥ規格またはＭＰ３規格に従って圧縮することができる。圧縮アルゴリズムの選択は、ビット・レートの選択に従った、またはこのコンテンツの性質に従った最適化に基づいて行うことができる。例えば、ほとんど動きの起こらないビデオ・ファイル（「トーキング・ヘッド」）と、かなりの量の動きが存在するビデオ・ファイル（「ハイモーション・ビデオ」）とは、それぞれ異なる圧縮アルゴリズムを使用してもっと効率的に圧縮することができる。

どの１つの圧縮アルゴリズム内においても、さらなる変形が存在する可能性がある。例えば、ＪＰＥＧ規格に従って圧縮されたファイルは、ＹＵＶ−ベースのものまたはＲＧＢ−ベースのものである可能性がある。

この好ましい実施形態のデジタル権限管理システムに関して、本発明の一態様に従って検出される、クライアント・コンピュータ上のメディア・プレーヤは、このメディア・プレーヤが処理することができるＤＲＭ情報タイプまたは使用規則タイプを特定する。例えば、ウィンドウズ・メディア・プレーヤは、マイクロソフト・ウィンドウズ・メディアＤＲＭシステムによって提供される使用規則を解釈し、または処理し、もしくはその両方を行うことができるが、一般にリアルのＨｅｌｉｘ ＤＲＭシステムによって提供されるこれらの使用規則を解釈し、または処理し、もしくはその両方を行うことはできない。さらに、リアルワン・プレーヤ（RealOne player）は、リアルのＨｅｌｉｘ ＤＲＭシステムによって提供されるこれらの使用規則を解釈し、または処理し、もしくはその両方を行うことができるが、マイクロソフト・ウィンドウズ・メディアＤＲＭシステムによって提供されるこれらの使用規則を解釈し、または処理し、もしくはその両方を行うことはできない。すなわち、メディア・プレーヤ・タイプは、一般にこのプレーヤが解釈することができるＤＲＭタイプに対する１対１の対応を有する。

さらに、ＤＲＭ情報または使用規則情報は、タグ、およびこれらのタグの値を含めてＸｒＭＬ、ＸＭＬなどによって記述することもできる。ＤＲＭ情報または使用規則情報は、コンテンツに付属させることもできる。そうでなければ、ＤＲＭ情報または使用規則情報は、コンテンツから物理的に切り離すことができ、コンテンツＩＤや、そのようなものを介して論理的にコンテンツに関連づけられる。ＤＲＭ情報または使用規則情報は、ユーザがこの関連するコンテンツをどのように、またはいつ、もしくはどのようにいつ使用することができるかを定義することもできる。

本発明の一態様によれば、このサーバ・システムは、クライアント・コンピュータ上のメディア・プレーヤ・タイプを自動的に検出し、メディア・プレーヤ・タイプに基づいてこのクライアント・コンピュータ上のＤＲＭタイプを特定し、ＤＲＭ情報または使用規則情報を自動的にトランスコードして、このクライアント・コンピュータ上でＤＲＭ情報または使用規則情報を解釈し、または処理し、もしくはその両方を行うことができるようにすることができる。米国特許第６４０７６８０号に説明されているように、ＤＲＭ情報は、ソース・タイプ（例えば、ＭＳＦＴウィンドウズ・メディアＤＲＭ）から宛先タイプ（例えば、リアルＨｅｌｉｘ）へとトランスコードすることができる。

本発明のこの態様によれば、次いでマルチメディア・コンテンツ・ユーザのコンピュータのコンフィギュレーションをリモートに特定するための方法が、提供される。この有利な方法は、このユーザのコンピュータにプレーヤ検出コードを送信すること、このユーザのコンピュータに関するコンフィギュレーション情報を受信すること、およびこの受信済みのコンフィギュレーション情報に基づいてこのユーザのコンピュータ上のデジタル権限管理情報のタイプを特定することを含んでいる。

前述の発行変数に加えて、ビデオ・データおよびオーディオ・データに特有の発行変数も存在する。ビデオ・データについての発行変数は、このビデオ・イメージのピクセルにおける幅および高さ、ならびにこのビデオのフレーム・レートを含んでいる。これらのビット・レート要件およびこのデータの性質に応じて、最良のピクチャ品質を保証するために異なる設定が必要なこともある。例えば、あるビデオは、１６０×１２０ピクセルにおいて毎秒１５フレームで良好に閲覧することができるが、他のあるビデオは、同じビット・レートではあるが、３２０×２４０ピクセルで毎秒５フレームで良好に閲覧することもできる。このビット・レートが５６Ｋｂｐｓである場合、ピクチャ品質は、非常に限られたものになり、６４０×４８０ピクセル分解能でビデオを配信することは、ほとんど最適ではない。ビデオ・データについてのさらに他の発行変数は、コンポーネント当たりのビット数である。

オーディオ・データの発行変数は、毎秒当たりのサンプル数、チャンネル数（例えば、モノ、ステレオ、５−チャンネル）、およびサンプル・サイズ（８−ビット、１６−ビットなど）を含んでいる。特定のコンテンツ・タイプおよびビット・レートの観点でオーディオ品質を保証するために、異なる設定が必要となることもある。発行変数はまた、送信されるデータ・パケット・サイズおよび伝送プロトコルの選択（例えば、ＴＣＰ対ＵＤＰ）も含んでいる。

図７は、オンデマンドでソース・タイプ・メディア・コンテンツ６１０を宛先タイプ・メディア・コンテンツ６５０へとトランスコードする一実施例のトランスコーダを示している。ソース・タイプ・メディア・コンテンツ６１０は、１つまたは複数のパケットの形でネットワーク上を配信されるデジタル・データである。ソース・タイプ・メディア・コンテンツ６１０を形成するデジタル・データは、１つまたは複数の発行変数によって定義される。図７に示される発行変数は、１つまたは複数の以下の変数、すなわちソース・ファイル・フォーマット、ソース・ビット・レート、ソース物理媒体、ソース通信プロトコル、ソース符号化、またはこれらの任意の組合せを含んでいる。宛先タイプ・メディア・コンテンツ６５０は、１つまたは複数のパケットの形でネットワーク上をこのメディア・コンテンツを要求するエンド・ユーザに対して配信されるデジタル・データである。宛先タイプ・メディア・コンテンツ６５０を形成するデジタル・データもまた、１つまたは複数の発行変数によって定義される。図７に示される発行変数は、１つまたは複数の以下の変数、すなわち宛先ファイル・フォーマット、宛先ビット・レート、宛先物理媒体、宛先通信プロトコル、宛先符号化、またはこれらの任意の組合せを含んでいる。

図８は、１つまたは複数のトランスコーダが、オンデマンドでソース・タイプ・メディア・コンテンツ７１０から第１の宛先タイプ７５０へとトランスコードする一実施例の実装形態の表を示している。図８はまた、１つまたは複数のトランスコーダが、オンデマンドでソース・タイプ・メディア・コンテンツ７１０から第２の宛先タイプ７６０へとトランスコードする一実施例の実装形態を示している。ソース・タイプ・メディア・コンテンツ７１０は、以下のソース発行変数に従って発行されるデジタル・データを含んでいる。すなわち、この物理媒体は、ローカル・ディスクであり、この通信プロトコルは、ファイルＩ／Ｏを含んでおり、このファイル・フォーマットは、毎秒当たり１２８キロビット（ｋｂｐｓ）のビット・レートにおけるＭＰ３符号化を使用したＭＰ３である。この第１の宛先タイプ・メディア・コンテンツ７５０は、以下の宛先発行変数に従って発行するためにトランスコードされたデジタル・データを含んでいる。すなわち、この物理媒体は、パケット交換ネットワーク（インターネット）であり、この通信プロトコルは、ウィンドウズ・メディア・ストリーミングＭＭＳプロトコルを含んでおり、このファイル・フォーマットは、５６ｋｂｐｓのビット・レートにおけるＭＰ３符号化を使用したウィンドウズ・メディア・ファイルである。第２の宛先タイプ・メディア・コンテンツ７６０は、以下の宛先発行変数に従って発行するためにトランスコードされたデジタル・データを含んでいる。すなわち、この物理媒体は、無線ネットワークであり、この通信プロトコルは、ＨＴＴＰを含んでおり、このファイル・フォーマットは、１２ｋｂｐｓのビット・レートにおけるＭＰ３符号化を含めたＭＰ３である。

他の実施例が、以下の諸表に示されている。
表２乃至５：実施例のトランスコーダ・オペレーション
表２
発行変数 ソース・タイプ 宛先タイプ
物理媒体 ディスク ネットワーク
１つ（または複数）の通信プロトコル ファイルI/O RTSP
コンテナ・フォーマット MPEG1 クイックタイム
符号化 MPEG1 SOLENSON（ビデオ）
QDESIGN（オーディオ）
ビット・レート 1.5Mbps 300kbps
表３
発行変数 ソース・タイプ 宛先タイプ
物理媒体 有線ネットワーク 無線ネットワーク
１つ（または複数）の通信プロトコル HTTP MMS
コンテナ・フォーマット MPEG1 ウィンドウズ・メディア
符号化 MPEG1 MPEG4（ビデオ）
MSAUDIO（オーディオ）
ビット・レート 1.5Mbps 100kbps
表４
発行変数 ソース・タイプ 宛先タイプ
物理媒体 有線ネットワーク 有線ネットワーク
１つ（または複数）の通信プロトコル ＨＴＴＰ ＲＴＳＰ
コンテナ・フォーマット クイックタイム リアル
符号化 Ｈ．２６３ リアル
独自開発Ｇ２
ビデオ／オーディオ
ビット・レート ５６ｋｂｐｓ ５６ｋｂｐｓ
表５
発行変数 ソース・タイプ 宛先タイプ
物理媒体 ディスク 無線ネットワーク
１つ（または複数）の通信プロトコル ファイルＩ／Ｏ ＨＴＴＰ
コンテナ・フォーマット ＭＰＥＧ１ ＭＰ３
符号化 ＭＰＥＧ１ オーディオのみ−ＭＰ３
ビット・レート １．５Ｍｂｐｓ １６ｋｂｐｓ

図９は、本発明の一実施形態による例示のクライアント環境変数タイプを示す表である。この好ましい実施環境のシステムは、ＯＳ（operating systemオペレーティング・システム）バージョン、ウェブ・ブラウザ・バージョン、ハードウェア・プラットフォームおよびユーザ・インターフェース言語を含めてクライアント・システムのさらなる特性を特定することができる。この機能は、どのタイプのＯＳ、例えばＷｉｎｄｏｗｓ、ＭａｃまたはＬｉｎｕｘがこのクライアント・マシン上で使用されているかを識別する有利な機能を含むシステム以上にさらに有利な改善となっている。例えば、たとえこのシステムがＷｉｎｄｏｗｓを使用していることが既知であったとしても、このクライアントが実際に有するよりも新しいバージョンを仮定すると、このメディア・ストリームに完全な障害をもたらす可能性があり、またもっと以前のバージョンであるという保守的な仮定が、効率の悪さをもたらす可能性もある。

すなわちこのメディア・コンテンツが供給され、初期設定のＯＳバージョンとしてＷｉｎｄｏｗｓ ＸＰ（登録商標）を有し、そのブラウザ・バージョンとしてナビゲータ３．０（Navigator 3.0）を有し、ペンティアム（登録商標）４（Pentium（登録商標） 4）処理チップがインストールされ、そのユーザ・インターフェース言語としてナビゲータ３．０についてのジャバスクリプトを使用するように構成されたソース・タイプ８１０についての一実施例が提供されている。これらのソース・タイプは、本明細書中の一実施形態に従って記述されるクライアント・コンフィギュレーションの特定と同様に提供されるか、または特定されることができる。次いで、宛先タイプ８５０は、Ｍａｃ ＯＳ Ｘオペレーティング・システム、Ｏｍｎｉｗｅｂ４．１ウェブ・ブラウザ・バージョン、Ｇ３プロセッサ・チップ、およびＯｍｎｉｗｅｂ４．１についてのユーザ・インターフェース言語ＸＳＬＴであるものとして示されている。宛先タイプ８５０が本明細書中の一実施形態に従ってリモートに特定され、ソース・タイプ８１０も特定された後に、次いで参照により本明細書に組み込まれている米国特許出願第１０／６４４６０２号に好ましく説明されていることなどもある有利なトランスコーディング・プロセスを使用して、これらの異なるタイプのハードウェアおよびソフトウェアが使用されているにもかかわらず、このソースからこの宛先へと提供されるメディア・コンテンツをストリーミングすることができる。

これらの実施例は、例示的なものであり本発明を限定することを意図してはいない。現在知られており、または将来に開発される他のタイプのオンデマンドのトランスコーディング・オペレーションについても、この明細書の提供された当業者には明らかなはずであるように使用することが可能である。

代替実施形態
本発明の方法およびシステムの実施例の実施形態について、本明細書中で説明してきた。他の所で指摘したように、これらの実施例の実施形態は、例示の目的のためだけに説明されており、限定的なものではない。本明細書中で説明されたこれらの実施形態と少しまたはかなり異なる代替実施形態についても、本明細書中に含まれるこれらの教示に基づいて当業者には明らかであろう。例えば、当業者なら、本発明のトランスコーディングのシステムおよび方法が、メディア・コンテンツのトランスコーディングおよび配信だけには限定されず、これらだけには限定されないが、例えば、圧縮ファイル、電子ドキュメント、ＨＴＭＬページ、ＸＭＬドキュメント、または、複数のフォーマットで記憶し、電子的に配信することができる他の任意の情報を含めて、すべてのタイプの情報のトランスコーディングおよび配信も包含することが認識可能であろう。他の代替実施形態は、それだけには限定されないが、本発明のこれらの方法、システム、およびコンポーネントのハードウェア実装形態、ソフトウェア実装形態、およびソフトウェア／ハードウェア実装形態を含んでいる。かかる代替実施形態は、本発明の範囲および趣旨に含まれる。

また、ソース・タイプから宛先タイプへとメディア・コンテンツのオンデマンドによるトランスコードを行うためのシステムおよび方法も実現することができ、ここでこのシステムは、複数のソース・タイプから複数の宛先タイプへとトランスコードするための複数のトランスコーダを含んでおり、またここでこのシステムは、メディア・コンテンツについてのトランスコーディング要求を受信し、このトランスコーディング要求に応じてこのメディア・コンテンツをフェッチし、このソース・タイプおよび宛先タイプに基づいて複数のトランスコーダのうちの１つにこのメディア・コンテンツを送信し、このソース・タイプから宛先タイプへとこのメディア・コンテンツをトランスコードし、それによってトランスコードされたメディア・コンテンツを生成し、このトランスコードされたメディア・コンテンツを伝送する。このシステムは、パイプライン化された様式で、このメディア・コンテンツをフェッチし、送信し、トランスコードし、このトランスコードされたメディア・コンテンツを伝送する。このシステムはまた、デジタル・データのファイルまたはストリームとしてのメディア・コンテンツの発行、メディア・コンテンツのアーカイブ、およびシステム効率を改善するためのトランスコードされたメディア・コンテンツのキャッシングを実現できるようにすることもできる。

さらに、本明細書中における、以上で説明されてもいる好ましい実施形態に従って実施することができる方法においては、これらのオペレーションは、選択された印刷記載上（typographical）の順序で説明されている。しかし、これらの順序は、印刷記載上の便宜のために選択され、そのように順序づけされており、これらのオペレーションを実施するためのどのような特定の順序を意味することも意図してはいない。

本発明の一実施形態の一般的なアーキテクチャを示す図である。 本発明の一実施形態のコンピューティング環境を示すブロック図である。 本発明の一実施形態の全体的なプロセスを示すフロー・チャートである。 配信管理ＨＴＴＰ要求を受信することを含めて、一実施形態によるサーバ側要求処理を示すフロー・チャートである。 検出ＵＲＬ ＨＴＴＰ要求を受信することを含めて、一実施形態によるサーバ側要求処理を示すフロー・チャートである。 本発明の一実施形態によるさらなる要求処理を示すフロー・チャートである。 本発明の一実施形態による、メディア・プレーヤ検出の処理を示すフロー・チャートである。 本発明の例示の一実施形態による、クライアント側ウィンドウズ・メディア・プレーヤ（ＷＭＰ）検出を示すフロー・チャートである。 本発明の他の例示の実施形態によるクライアント側リアルプレーヤ（リアル）検出を示すフロー・チャートである。 本発明の例示の一実施形態によるクライアント側クイックタイム（ＱＴ）検出を示すフロー・チャートである。 本発明の一実施形態による、このユーザに対してプリファランス・ページを提示するプロセスを示すフロー・チャートである。 本発明の一実施形態による帯域幅検出方法を一般的に示すフロー・チャートである。 本発明の一実施形態による、メディア・コンテンツにアクセスするための１つのルーチンを説明するフロー・チャートである。 本発明の一実施形態による、メディア・コンテンツにアクセスするための１つのルーチンを説明するフロー・チャートである。 本発明の一実施形態による、メディア・コンテンツにアクセスするための１つのルーチンを説明するフロー・チャートである。 本発明の実施形態に従って使用することができるトランスコーダの一例を示す図である。 本発明の一実施形態による様々な発行変数についての例示のトランスコードするソース・タイプおよび宛先タイプを示す表である。 本発明の一実施形態による例示のクライアント環境可変タイプを示す表である。

Claims (3)

1. 配信管理サーバと、トランスコーダによってフォーマットされ、ストリーミングサーバを介して配信されるマルチメディア・コンテンツを再生するクライアントとからなる情報処理システムにおいて、前記配信管理サーバが前記クライアントのコンフィギュレーションをリモートに特定するための情報処理方法であって、
   前記配信管理サーバから前記クライアントに、前記クライアントが有するブラウザにおいて前記マルチメディア・コンテンツを再生するプレーヤを検出するために実行されるプレーヤ検出スクリプトを送信するスクリプト送信ステップと、
   前記クライアントが、前記配信管理サーバから送信される前記プレーヤ検出スクリプトが実行されることに応じて、前記ブラウザの種類を識別する識別ステップと、
   前記識別ステップの処理により識別された前記ブラウザの種類に応じて、前記ブラウザに付随する所定の管理データから前記プレーヤについての情報を探索するか、または、前記プレーヤをインスタンス化することを試みることにより、前記ブラウザにおいて前記プレーヤが存在するかを判定する判定ステップと、
   前記ストリーミングサーバから配信される前記マルチメディア・コンテンツを前記トランスコーダがフォーマットするのに十分であるかを前記配信管理サーバが判断するための情報であって、前記判定ステップの処理によって前記ブラウザにおいて存在すると判定された前記プレーヤの識別情報およびバージョンを少なくとも含むコンフィギュレーション情報を、前記配信管理サーバに送信するコンフィギュレーション情報送信ステップと
   を含む情報処理方法。
2. 前記コンフィギュレーション情報送信ステップは、前記コンフィギュレーション情報を、前記クッキーとして前記配信管理サーバのドメインに関して設定されたクッキーに格納して送信する
   請求項１に記載の情報処理方法。
3. 配信管理サーバと、トランスコーダによってフォーマットされ、ストリーミングサーバを介して配信されるマルチメディア・コンテンツを再生するクライアントとからなる情報処理システムにおいて、前記クライアントのコンフィギュレーションをリモートに特定する処理を前記配信管理サーバに実行させるプログラムにおいて、
   前記配信管理サーバから前記クライアントに、前記クライアントが有するブラウザにおいて前記マルチメディア・コンテンツを再生するプレーヤを検出するために実行されるプレーヤ検出スクリプトの送信を制御する送信制御ステップと、
   前記クライアントが、前記配信管理サーバから送信される前記プレーヤ検出スクリプトが実行されることに応じて、前記ブラウザの種類を識別し、前記識別ステップの処理によって識別された前記ブラウザの種類に応じて、前記ブラウザに付随する所定の管理データから前記プレーヤについての情報を探索するか、または、前記プレーヤをインスタンス化することを試みることにより、前記ブラウザにおいて前記プレーヤが存在するかを判定し、送信してくる、前記ストリーミングサーバから配信される前記マルチメディア・コンテンツを前記トランスコーダがフォーマットするのに十分であるかを前記配信管理サーバが判断するための情報であって、前記ブラウザにおいて存在すると判定された前記プレーヤの識別情報およびバージョンを少なくとも含むコンフィギュレーション情報の受信を制御する受信制御ステップと
   を含む処理を前記配信管理サーバに実行させるプログラムが記録されている記録媒体。

Images