(57)【要約】  デジタルメディアコンテンツに関してネットワークノードからのプレイリスト検索能力をもたらすためのシステムおよび方法である。メディアのユーザがストリーミングセッションを呼び出すと、適切なプレイリスト関連制御属性のセットを含むリアルタイムストリーミングプロトコル（ＲＴＳＰ）ユニフォームリソースロケータ（ＵＲＬ）またはセッション記述プロトコル（ＳＤＰ）ファイルが供給される。ＲＴＳＰ  ＵＲＬまたはＳＤＰファイルに応答してＲＴＳＰメッセージがネットワークノードに供給され、このＲＴＳＰメッセージは識別されたプレイリストに付随するＵＲＬ照会ストリング内にプレイリスト関連制御属性を含む。特に、さらに用途の広い検索能力を可能にするために、クリップインデックス（これは特定のメディアクリップを識別するためにプレイリストの中に索引を付ける）ならびにオフセット（識別されたメディアクリップの中の開始時間）がプレイリスト関連制御属性として提供される。
2008535317.tif 000002
【特許請求の範囲】
【請求項１】
セッション記述プロトコル（ＳＤＰ）ファイルおよびリアルタイムストリーミングプロトコル（ＲＴＳＰ）ユニフォームリソースロケータ（ＵＲＬ）のうちの少なくとも一方を介してプレイリストに付随する適切なプレイリスト関連制御属性のセットを提供する工程と、
前記プレイリスト関連制御属性に応答して、ネットワークノードに付随するサーバストリームモジュールに、デジタルメディア装置上で実行するメディアプレーヤエンジンによってＲＴＳＰメッセージを供給する工程であって、前記ＲＴＳＰメッセージが前記プレイリストに関して前記ＲＴＳＰメッセージに付随するＵＲＬ照会ストリング内に前記プレイリスト関連制御属性を含む、前記供給する工程と、
前記ＲＴＳＰメッセージ内で識別された前記プレイリストのストリーミングセッションを開始する工程とを含み、前記プレイリストの中の特定のメディアクリップの開始および前記特定のメディアクリップの中へのオフセットが前記プレイリスト関連制御属性に基づいて指定される、
前記ネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項２】
前記メディアプレーヤエンジンによって提供される前記ＲＴＳＰメッセージがＳＥＴＵＰ、ＰＬＡＹ、およびＰＡＵＳＥメッセージのうちの１つから成る、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項３】
前記プレイリストが、複数のレベルを有する階層配列へと組織化される前記デジタルメディアコンテンツの保管場所の一部として提供される、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項４】
前記特定のメディアクリップが前記プレイリスト関連制御属性のクリップインデックス属性によって識別される、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項５】
前記特定のメディアクリップの中への前記オフセットが前記プレイリスト関連制御属性内に提供されたタイムスタンプによって識別され、前記タイムスタンプがノーマルプレイタイム（ＮＰＴ）書式、ＳＭＰＴＥ書式、およびｈｈ：ｍｍ：ｓｓ：ｆｆ書式のうちの１つから成る書式を有する、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項６】
前記デジタルメディア装置が有線ネットワーク、無線ネットワーク、およびケーブルネットワークのうちの少なくとも１つの上で前記ネットワークノードにアクセスする、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項７】
前記デジタルメディア装置がデジタル音楽プレーヤ、デジタルビデオプレーヤ、ストリーミングメディアを受け取ることを可能にされたコンピュータおよびハンドヘルド通信装置のうちの少なくとも１つから成る、請求項１に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法。
【請求項８】
セッション記述プロトコル（ＳＤＰ）ファイルおよびリアルタイムストリーミングプロトコル（ＲＴＳＰ）ユニフォームリソースロケータ（ＵＲＬ）のうちの少なくとも一方を介してプレイリストに付随する適切なプレイリスト関連制御属性のセットを提供するための手段と、
デジタルメディア装置上で実行するメディアプレーヤエンジンに付随し、ネットワークノードに付随するサーバストリームモジュールにＲＴＳＰメッセージを提供するために前記プレイリスト関連制御属性に応答して動作し、前記ＲＴＳＰメッセージが前記プレイリストに関して前記ＲＴＳＰメッセージに付随するＵＲＬ照会ストリング内に前記プレイリスト関連制御属性を含む、手段と、
前記ＲＴＳＰメッセージ内で識別された前記プレイリストのストリーミングセッションを開始するための、前記プレイリストの中の特定のメディアクリップの開始および前記特定のメディアクリップの中へのオフセットが前記プレイリスト関連制御属性に基づいて指定される、手段と
を含む、前記ネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項９】
前記メディアプレーヤエンジンに付随する前記手段によって提供される前記ＲＴＳＰメッセージがＳＥＴＵＰ、ＰＬＡＹ、およびＰＡＵＳＥメッセージのうちの１つから成る、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１０】
前記プレイリストが、複数のレベルを有する階層配列へと組織化される前記デジタルメディアコンテンツの保管場所の一部として提供される、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１１】
前記特定のメディアクリップが前記プレイリスト関連制御属性のクリップインデックス属性によって識別される、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１２】
前記特定のメディアクリップの中への前記オフセットが前記プレイリスト関連制御属性内に提供されたタイムスタンプによって識別され、前記タイムスタンプがノーマルプレイタイム（ＮＰＴ）書式、ＳＭＰＴＥ書式、およびｈｈ：ｍｍ：ｓｓ：ｆｆ書式のうちの１つから成る書式を有する、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１３】
前記デジタルメディア装置が有線ネットワーク、無線ネットワーク、およびケーブルネットワークのうちの少なくとも１つの上で前記ネットワークノードにアクセスする、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１４】
前記デジタルマルチメディア装置がデジタル音楽プレーヤ、デジタルビデオプレーヤ、ストリーミングメディアを受け取ることを可能にされたコンピュータおよびハンドヘルド通信装置のうちの少なくとも１つから成る、請求項８に記載のネットワークノードからデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステム。
【請求項１５】
ネットワークノードへのリアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージを作り出すためのデジタルメディア装置上で実行するメディアプレーヤエンジンに付随し、前記ＲＴＳＰメッセージが前記ＲＴＳＰメッセージ内で識別されたプレイリストに関してユニフォームリソースロケータ（ＵＲＬ）照会ストリング内にプレイリスト関連制御属性のセットを含む、論理回路と、
前記ＲＴＳＰメッセージ内で識別された前記プレイリストを再生するための、前記プレイリストの中の特定のメディアクリップの開始および前記特定のメディアクリップの中へのオフセットが前記プレイリスト関連制御属性に基づいて指定される、手段と
を含む、前記ネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【請求項１６】
前記メディアプレーヤエンジンに付随する前記論理回路によって作り出される前記ＲＴＳＰメッセージがＳＥＴＵＰ、ＰＬＡＹ、およびＰＡＵＳＥメッセージのうちの１つから成る、請求項１５に記載のネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【請求項１７】
前記プレイリストが、複数のレベルを有する階層配列へと組織化される前記デジタルメディアコンテンツの保管場所の一部として提供される、請求項１５に記載のネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【請求項１８】
前記特定のメディアクリップが前記プレイリスト関連制御属性のクリップインデックス属性によって識別される、請求項１５に記載のネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【請求項１９】
前記特定のメディアクリップの中への前記オフセットが前記プレイリスト関連制御属性内に提供されたタイムスタンプによって識別され、前記タイムスタンプがノーマルプレイタイム（ＮＰＴ）書式、ＳＭＰＴＥ書式、およびｈｈ：ｍｍ：ｓｓ：ｆｆ書式のうちの１つから成る書式を有する、請求項１５に記載のネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【請求項２０】
有線ネットワーク、無線ネットワーク、およびケーブルネットワークのうちの少なくとも１つの上で前記ネットワークノードにアクセスするための手段をさらに含む、請求項１５に記載のネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して、ネットワーク上でのメディアのストリーミングに関する。より詳細には、どのような限定の方式でもないが、本発明はクライアント−サーバアーキテクチャ内でデジタルメディアコンテンツに関してネットワークノードからプレイリスト検索を達成するためのシステムおよび方法に関する。
【背景技術】
【０００２】
現在広く行き渡った主要通信媒体としてのインターネットの使用により、コンピュータネットワークはマルチメディアのデータ（例えば音声、フルモーションビデオ、画像など）を送信するためにますます使用されつつある。ネットワークを基盤にした背景では、情報を作り出す１つの単純なモデルはサーバからマルチメディアのデータをダウンロードする処理を要求するクライアント装置を含む。いったんダウンロードされると、次にクライアントはこの情報を消費、または提示することができる。このモデルは実施することが比較的容易であるが、しかしながらプレゼンテーションが開始可能になるのに先立ってダウンロードを完了させるためにクライアントが待つことを要求されるという点で最適ではない。この遅れはマルチメディアデータの大きいブロックが含まれる場合に無視できないものになり得る。
【０００３】
情報を作り出すさらに洗練されたモデルは、ネットワーク上で別のサイトのクライアントにマルチメディア情報を「ストリーミングする」コンテンツサーバを１つのネットワークサイトに有する。ストリーミングは、インターネットプロトコル（ＩＰ）を基盤にしたネットワーク上で送られるパケットが、実質的にリアルタイムで到着するかのようにユーザに感知されるように連続的に資料を受信クライアントに提示するために使用される処理である。それ自体、クライアントは資料を表示する前に大きいファイルをダウンロードして保存する必要がない。すなわち、クライアントはプレゼンテーションを開始するのに先立って全データセットが到着するのを待つのではなく、到着時に情報の提示を開始する（すなわちジャストインタイムレンダリング）。したがって、受信されたデータはマルチメディアコンテンツのリアルタイムのプレゼンテーションのためにクライアントによって受信された途端に、または直後にキャッシュメモリの中にバッファリングされて連続的に処理される。
【０００４】
殆どのストリーミングセッションはライブまたはビデオオンデマンド（ＶＯＤ）ソースのどちらかを含み、通常では単一のコンテンツソース（すなわち単一のＶＯＤファイルまたは単一のライブソース、例えばビデオカメラ）に付随する。しかしながら、単一のストリーミングセッションの中に複数のソースを組合わせる能力を追加することによってはるかに豊かな応用がマルチメディアストリーミングに基づいて構築されることが可能になる。
【０００５】
最も単純な形態の「プレイリスト」はローカルコンテンツ（すなわち音声ファイル）の再生を単純に管理するため、またはストリーミングメディアのセッションを制御するために使用されることが可能であるメディアの単なる一覧表である。マルチメディアのストリーミングの背景で使用されるとき、プレイリストはストリーミングを介してユーザにカスタマイズ可能なオーディオおよびビデオコンテンツを配信するための拡張可能で動的な方法を提供する。プレイリストはサーバがクライアントにストリーミングすることができるメディア項目の一覧表を表わし、これは例えばプログラムコンテンツと広告（ａｄｓ）の混合体を含んでもよい。また、プレイリストは短いクリップを上演するため、またはプログラミングの長いブロックをユーザに提供するために使用されることもあり得る。
【０００６】
クライアント−サーバのストリーミングアーキテクチャでは、２つのタイプのプレイリスト、すなわちクライアント側のプレイリストとサーバ側のプレイリストが供給されてもよい。２つのタイプのプレイリストの主な違いは、クライアント側のプレイリストが使用されるときにはクライアントのプレーヤアプリケーションがストリーミングエクスペリエンスの制御を有し、それに対してサーバ側のプレイリストが使用されるときにはストリーミングサーバがストリーミングエクスペリエンスの制御を有することである。サーバ側のプレイリストはストリーミングサーバが多数のソースからの（順々の）ストリームと単一のセッションにおけるクライアントへのストリームを組合わせる能力を提供する。クライアントは多数のメディアソースが存在することに気付く必要がない（気付くことさえできない）。これは広告挿入能力を供給するため、または途切れない（多数のソースからの）ストリーミングが望まれる、すなわちクライアントが各々の新たなソースからのストリーミングを明白に要求する必要がない用途のために有用である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
サーバ側のプレイリストを利用するときの課題の１つはプレイリストのナビゲーションをサポートすることであり、これは末端ユーザに説得力があって有用なユーザエクスペリエンスを提供するのに有利である。付け加えると、プレイリストナビゲーション機能は、重大なクライアント装置のリソースの制約に起因するクライアント装置のアプリケーションに対する最少限の影響を伴なって達成されるべきである。しかしながら、現在あるサーバ側プレイリストの仕組みは、プレイリスト検索のクライアント側ナビゲーション制御をサポートしないという点で不十分である。
【課題を解決するための手段】
【０００８】
概して、本開示の実施形態はネットワークノードからのデジタルメディアコンテンツに関して機能強化されたプレイリスト検索能力をもたらし、それにより、中にあるどのようなメディアクリップでもユーザがプレイリストを開始することができる仕組みに向けられる。適切なプレイリスト関連の制御属性のセットを含むリアルタイムストリーミングプロトコル（ＲＴＳＰ）ユニフォームリソースロケータ（ＵＲＬ）またはセッション記述プロトコル（ＳＤＰ）ファイルはユーザが適切なデジタルメディアプレーヤ上でストリーミングセッションを呼び出すと提供される。ＲＴＳＰ  ＵＲＬまたはＳＤＰファイルに応答して、ＲＴＳＰメッセージがネットワークノードに供給され、このＲＴＳＰメッセージは識別されるプレイリストに付随するＵＲＬ照会ストリング内にプレイリスト関連の制御属性を含む。特に、さらに多目的の検索能力を可能にするために、（特定のメディアクリップを識別するためにプレイリストの中に索引を付ける）クリップインデックスおよびオフセット（識別されたメディアクリップ内の開始時間）がプレイリスト関連の制御属性として提供される。
【０００９】
１つの態様では、本発明はネットワークノードからのデジタルメディアコンテンツに関してプレイリスト検索を達成するための方法に向けられ、この方法はプレイリストに付随する適切なプレイリスト関連制御属性のセットを、ＳＤＰファイルおよびＲＴＳＰ  ＵＲＬのうちの少なくとも一方を介して供給する工程、受信したプレイリスト関連制御属性に応答して、デジタルマルチメディア装置上で実行するメディアプレーヤエンジンによってネットワークノードに付随するサーバストリームモジュールにＲＴＳＰメッセージ（このＲＴＳＰメッセージはプレイリストに関してＲＴＳＰメッセージに付随するＵＲＬ照会ストリング内にプレイリスト関連制御属性を含む）を供給する工程、およびＲＴＳＰメッセージ内で識別されたプレイリストのストリーミングセッションを開始する工程を含み、プレイリストの中の特定のメディアクリップの開始および特定のメディアクリップの中へのオフセットはプレイリスト関連制御属性に基づいて特定される。
【００１０】
他の態様では、本発明はネットワークノードからのデジタルメディアコンテンツに関してプレイリスト検索を達成するためのシステムに向けられ、このシステムはプレイリストに付随する適切なプレイリスト関連制御属性のセットをＳＤＰファイルおよびＲＴＳＰ  ＵＲＬのうちの少なくとも一方を介して供給するための手段、デジタルマルチメディア装置上で実行するメディアプレーヤエンジンに付随する手段であって、ネットワークノードに付随するサーバストリームモジュールにＲＴＳＰメッセージ（このＲＴＳＰメッセージはプレイリストに関してＲＴＳＰメッセージに付随するＵＲＬ照会ストリング内にプレイリスト関連制御属性を含む）を供給するために受信したプレイリスト関連制御属性に応答して動作する手段、およびＲＴＳＰメッセージ内で識別されたプレイリストのストリーミングセッションを開始するための手段を含み、プレイリストの中の特定のメディアクリップの開始および特定のメディアクリップの中へのオフセットはプレイリスト関連制御属性に基づいて特定される。
【００１１】
なおも別の態様では、本発明はネットワークノードからデジタルメディアコンテンツを検索するように動作可能なデジタルメディア装置に向けられ、この装置はネットワークノードへのＲＴＳＰメッセージ（このＲＴＳＰメッセージはＲＴＳＰメッセージ内で識別されたプレイリストに関してＵＲＬ照会ストリング内にプレイリスト関連制御属性のセットを含む）を作り出すためのデジタルマルチメディア装置上で実行するメディアプレーヤエンジンに付随する論理回路、およびＲＴＳＰメッセージ内で識別されたプレイリストを再生するためのメディアプレーヤエンジンに付随する手段を含み、プレイリストの中の特定のメディアクリップの開始および特定のメディアクリップの中へのオフセットはプレイリスト関連制御属性に基づいて特定される。
【００１２】
添付の図面は現時点で本発明の好ましい１つまたは複数の例示的な実施形態を例示するために本願明細書の中に組入れられ、明細書の一部を形成する。本発明の様々な利点および特徴は添付の特許請求項と関連付けられる以下の「発明を実施するための最良の形態」、および添付の図面を参照して理解されるであろう。
【発明を実施するための最良の形態】
【００１３】
本発明が最良に為され、かつ使用される方法の様々な例を参照して本発明の実施形態がここで述べられる。類似した、または相当する部品類を示すために図面類の説明およびいくつかの視野全体を通じて類似した参照番号が使用され、ここでは様々な素子は必ずしも縮尺通りに作図されていない。ここで図面、さらに特定して図１を参照すると、これに描かれているものは本発明の実施形態が実践され得る一例のネットワーク環境１００である。参照番号１０２Ａおよび１０２Ｂは、とりわけ、いずれかの有線、無線、衛星、またはケーブルのネットワーク配列またはこれらの組合わせを含んでもよいネットワークアーキテクチャ基盤の具体例であり、クライアント−サーバのネットワークアーキテクチャ上でデジタルマルチメディアコンテンツをサーバノード１１０から、そのようなコンテンツを受け取ることができる様々なクライアント装置へと送る処理をサポートすることが可能である。１つの実践例では、ネットワーク１０２Ａは狭帯域（例えばダイヤルアップ）と広帯域（例えばケーブル、デジタル加入者回線、またはＤＳＬなど）アクセスメカニズムの両方を含めた適切なアクセス手段を介してアクセス可能であるインターネットなどの公衆パケット交換ネットワークを含んでもよい。場合によっては、ネットワーク１０２Ａは私企業レベルのイントラネットとして実施されてもよい。無線ネットワーク１０２Ｂは、グローバルシステムフォーモバイルコミュニケーション（ＧＳＭ）に基づいたキャリアネットワークのセルラー基盤アーキテクチャを使用するモバイル装置のためのパケット無線アクセスを提供するジェネラルパケット無線サービス（ＧＰＲＳ）ネットワークなどの無線パケットデータサービスネットワークとして実施されてもよい。なおもさらなる実践例では、無線ネットワーク１０２Ｂは、中でも短距離のワイヤレスフェデリティ（ＷｉＦｉ）アクセスポイント（ＡＰ）または「ホットスポット」を含む適切な無線基盤アーキテクチャ１１２を使用するインターネットプロトコル（ＩＰ）の可能なハンドヘルド装置、例えばモバイル型クライアント装置１１４に役立つように動作可能な、いずれかの知られている、またはこれまで知られていない第３世代パートナーシッププロジェクト（すなわち３ＧＰＰ、３ＧＰＰ２など）のネットワークを含んでもよい。下記で見られるように、クライアント装置によってサーバをベースとするデジタルマルチメディアコンテンツを検索するための本特許出願の実施形態はネットワーク１０２Ａ、１０２Ｂのどのような無線または有線のネットワーク実践例にもかかわらずに述べられるであろう。
【００１４】
サーバノード１１０はネットワーク１０２Ａに接続された単一ノードであるように例示されているが、その機能は根底にあるストリーミング用メディアアーキテクチャによって決まる複数のノードの中に配分されてもよい。実例のクライアント装置は、変化するレベルの処理能力で、Ｊａｖａ（登録商標）アプリケーション、プラグインなどを含んでもよい適切なストリーミング用クライアントアプリケーションを実行するように動作可能なシック（ｔｈｉｃｋ）クライアントまたはシン（ｔｈｉｎ）クライアントであってもよい。クライアント装置は総称的にコンピュータ１０４として表わされる携帯用コンピュータ、ラップトップ、ハンドヘルドコンピュータ、デスクトップコンピュータ、概してＡ／Ｖ部品１０８として表わされるデジタルミュージックプレーヤ、デジタルビデオプレーヤなどのネットワーク意識のオーディオ／ビデオ（Ａ／Ｖ）、またはｉＰｏｄ（商標）装置などの特化されたマルチメディア装置１０６を含んでもよい。さらに、前に示唆されたように、クライアント装置はデジタルマルチメディアコンテンツを受け取って再生することができるモバイル型クライアント装置（例えば装置１１４）を含むこともやはりあり得る。
【００１５】
図２は本発明の実施形態によるサーバ（例えばサーバノード１１０）に付随するサーバ側メディア管理システム２００の一例の実施形態を描いている。サーバ側メディア管理システム２００はメディアマネージャ２０２およびデジタルマルチメディアコンテンツデータベース２０４を含んでもよく、ここではメディアマネージャ２０２がデータベース２０４へのアクセスを制御する。１つの実践例では、メディアマネージャ２０２はデジタルマルチメディア装置上で実行するクライアントアプリケーションから要求を受け取り、コンテンツデータベースにアクセスし、クライアントアプリケーションに対する応答を返す。下記で述べられるように、データベース２０４は、データベース２０４内のメディア（すなわちメディア項目）を分類、識別、および／または記述するために使用されるパラメータに基づいた複数のレベルを有する入れ子型階層配列へと組織化されるデジタルマルチメディアコンテンツの保管場所の役割りを果たす。例えば、サーバに付随するデジタルマルチメディアコンテンツはリアルタイムストリーミングプロトコル（ＲＴＳＰ）などの適切なテキストベースのプロトコルの制御下でネットワーク上でストリーミングされることが可能な音楽ファイルを含むこともあり得る。他のメディアファイルがいずれかの形態のデジタルメディアを含むことが可能であり、これがサウンドファイル、画像データ、映画、テキストファイル、またはコンピュータ上にデジタル保存され得るいずれかの他のタイプのメディアを含んでもよいことは理解されるはずである。したがって、サーバ側のプレイリストは混合されたデジタルメディアのコレクションを含めたメディアコレクションに一般化されることが可能であり、各々のプレイリストが１つまたは複数の個別のマルチメディアファイルまたはマルチメディアクリップを含む。メディアマネージャ２０２は、例えばサーバの名前、使用されるデータベースのバージョン、要求されるセキュリティのタイプ、サーバが利用可能なデータベースの数、標準外のメディアがサポートされるかどうか、永続的な識別番号がサポートされるかどうか、などを含んでもよいデータベース２０４についての情報を有するかまたは得ることができる。データベース２０４についての情報が単一の記録ファイル内に存在してもよく、またはオンデマンドで部分的もしくは全体的のどちらかで作り出されてもよく、必要なときに情報の様々な断片を識別することを当業者は理解するはずである。１つまたは複数のメタデータファイル２０６はデータベース２０４内の利用可能な各々のメディア項目に関するメタデータを含む。メディア項目が歌である具体例の方式で、メタデータは例えば歌の名前もしくはタイトル、識別番号、永続的識別番号、アーティスト、アルバム、歌のサイズ、歌の書式、必要なビットレート、およびいずれかの他の適切な情報であってもよく、これはメディアのタイプによって決まると見込まれる。ビデオファイルは追加的な領域、例えばディレクターおよびプロデューサーの領域、男優および女優の領域などを有してもよい。スチル画像はビットレート情報を有さなくてもよい。いくつかの領域は標準的であるがその他は或る用途に特異的であってもよい。例えば、ビデオ信号が他のビデオ関連メタデータ情報に加えて二次音声プログラム（ＳＡＰ）情報を有することもあり得る。
【００１６】
プレイリスト記録２０８はデータベース２０４内の利用可能な各々のプレイリストについての情報を有し、これらのプレイリストは通常ではいずれかの特定の順序であってもなくてもよいメディアクリップのコレクションから成る。ユーザはジャンル、気分、アーティスト、ディレクター／プロデューサー、聴衆、またはいずれかの他の重要な配列によってメディアを組合わせるように選択することができる。サーバ１１０上のプレイリストは普通では自己の音楽データベース２０４内に含まれるメディアクリップを有するのみであろうが、プレイリスト記録２０８がサーバ側メディア管理システム２００の実践例に応じてマルチメディアクリップ、または他のサーバに保存されたプレイリストを含み得ることもやはり可能である。
【００１７】
図３は本発明の一実施形態に従ってデジタルマルチメディアコンテンツをストリーミングするためにネットワーク環境で動作可能な一例のクライアント−サーバ配列３００のブロック図を描いており、ここではサーバ側アーキテクチャは複数の相互運用モジュールの中に配分される。クライアント−サーバ配列３００が図１および図２に関して上記で述べられたサーバノード１１０とクライアント装置を含む１つの具体的な実践例であることを当業者は認識するはずである。いずれかの適切なデジタルマルチメディア装置上で実行するストリーミング用クライアントアプリケーション３０２はユーザの要求および経路３１６を介して供給されるユーザのフィードバックに対してウェブサーバ３０６と相互作用するように動作可能である。クライアントアプリケーション３０２に付随するものはメディアプレーヤエンジン３０４であり、これはストリーミングセッション上で受け取られたストリーミングメディアを再生するためにソフトウェア、ハードウェア、ファームウェア、またはこれらのいずれかの組合わせで具現されることが可能である。ウェブサーバ３０６は、特定のプレイリストに関してセッション記述プロトコル（ＳＤＰ）ファイルを作り出すサーバアプリケーションモジュール（ＡＭ）３０８へのメタデータファイル作成要求３１８を作ることによってプレゼンテーション記述を呼び出すための論理アーキテクチャと機能を含む。概して、プレゼンテーション記述は各々が共通の時間軸を保持する１つまたは複数のプレゼンテーションを記述してよい。単一のプレゼンテーションが、クライアントアプリケーションがメディアの最も適切な組合わせを選択することを可能にするコード化情報、言語、および他のパラメータをその記述が有するいくつかのメディアストリームを含むこともあり得る。多数のメディアストリームが含まれる場合、これらは異なるメディアサーバ上に配置され得ることも可能であり、例えばオーディオとビデオのストリームが負荷分散のために複数のサーバにわたって分割されることもあり得る。
【００１８】
例を挙げると、サーバのストリーミング用モジュール（ＳＭ）３１０、これに付随するコンテンツデータベース３１２、およびローカルコンテンツマネージャ（ＬＣＭ）３１４はリアルタイムトランスポートプロトコル（ＲＴＰ）などのトランスポートプロトコルを介して達成されるリアルタイムのメディア配信経路３２４を経由してクライアントプレーヤエンジン３０４にデジタルマルチメディアをストリーミングするためのメディアサーバの代表である。ストリーミング事象は経路３２２を介してストリーミング用モジュールによってサーバＡＭ３０８へと通知され、ストリーミングセッション状態の更新は経路３２０を介してサーバＡＭモジュール３０８によってウェブサーバ３０６へと供給される。ウェブサーバ３０６はプレイリストとメディアコンテンツの管理およびプレイリスト識別子（例えばユニフォームリソースロケータすなわちＵＲＬ）に関して経路３２６を介してＬＣＭと相互作用するように動作可能である。
【００１９】
上記で示唆されたように、クライアント−サーバ配列３００内のリアルタイム特性を備えたデータ（すなわちデジタルマルチメディア）の配信全体にわたる制御は、多数のデータ配信セッションを制御し、ユーザーデータグラムプロトコル（ＵＤＰ）チャンネル、マルチキャストＵＤＰチャンネルなどの配信チャンネルを選択するための手段を提供し、同様にＲＴＰに基づいてデータ配信メカニズムを選択するための手段を提供するように動作可能であるＲＴＳＰなどのアプリケーションレベルのテキストベースプロトコルによって達成されることが可能である。本特許開示の教示は特にＲＴＳＰメッセージ送信の背景の中で例証されるので、その簡単な説明が直ぐ下に述べられる。
【００２０】
ＲＴＳＰはオーディオおよびビデオなどの連続的なメディアの１つまたは複数の時間同期したストリームを確立および制御し、制御されるべきストリームのセットはプレゼンテーション記述によって規定される。ＲＴＳＰ接続の概念は無く、その代わりにサーバが通常では識別子によって標識される論理的セッションを維持する。概して、ＲＴＳＰセッションは伝送制御プロトコル（ＴＣＰ）などのトランスポートレベルの接続に関係しない。ＲＴＳＰセッションの間、ＲＴＳＰクライアントアプリケーションはＲＴＳＰ要求を出すためにサーバへのいくつかのＴＣＰトランスポート接続を開閉することが可能である。場合によっては、ＵＤＰなどのコネクションレス型トランスポートプロトコルを使用することもあり得る。
【００２１】
「プレゼンテーション」はプレゼンテーション記述情報を使用してクライアントに完全なメディア供給として提示される１つまたは複数のストリームのセットである。ＲＴＳＰ背景の中の殆どのケースで、これはこれらのストリームの集合体制御を暗示するが必ずしもそうではない。プレゼンテーション記述はプレゼンテーションの中の１つまたは複数のメディアストリーム、例えばコード化のセットなどについての情報、ネットワークアドレス、およびコンテンツについての他の情報を含む。ＳＤＰなどの他のインターネットエンジニアリングタスクフォース（ＩＥＴＦ）プロトコルはライブのプレゼンテーションを記述するために「セッション」という用語を使用する。プレゼンテーション記述は、限定はされないが上記で示唆されたＳＤＰベースのセッション記述書式を含めたいくつかの異なる書式をとることもあり得る。
【００２２】
ＲＴＳＰによって制御されるストリームはデータ配信のためにＲＴＰを使用することもあり得るが、しかしＲＴＳＰの動作は連続的なメディアを搬送するために使用されるトランスポートメカニズムに左右されない。ＲＴＳＰの構文および動作はさらに使い慣れたハイパーテキスト転送プロトコル（ＨＴＴＰ）のそれらと同様であるが、しかし２つの間にはいくつかの重要な差異が存在する。例えば、ＲＴＳＰのサーバとクライアントの両方が要求を出すことが可能であり、それに対してＨＴＴＰはクライアントが要求を出してサーバが応答する非対称プロトコルである。また、ＲＴＳＰに関しては、データは通常では異なるプロトコル（例えばＲＴＰ）によって帯域外で搬送される。以下の動作、すなわち（ｉ）メディアサーバからのメディアの検索、（ｉｉ）会議へのメディアサーバの招待、および（ｉｉｉ）既に有るプレゼンテーションへのメディアの追加がＲＴＳＰによってサポートされる。
【００２３】
全体的な動作の観点では、各々のプレゼンテーションおよびメディアストリームはＲＴＳＰ  ＵＲＬによって識別されることが可能である。例えば、以下のＲＴＳＰ  ＵＲＬ
ｒｔｓｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ：５５４／ｔｗｉｓｔｅｒ／ａｕｄｉｏｔｒａｃｋ
はプレゼンテーション「ｔｗｉｓｔｅｒ」の中のオーディオストリームを識別し、これはホスト＜ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ＞のポート５５４へのＴＣＰ接続上で出されるＲＴＳＰ要求を介して制御されることが可能である。前に指摘したように、メディアのプレゼンテーションおよび特性はプレゼンテーション記述ファイルによって規定され、これはＨＴＴＰまたは他の手段（例えばｅ−メールおよびＲＳＴＰ  ＤＥＳＣＲＩＢＥ要求など）を使用してクライアントアプリケーションによって得られることが可能であって必ずしもメディアサーバに保存されなくてもよい。以下の表は要求メッセージ内で識別されるリソース上で実行されるべき特定の方法を示すＲＴＳＰ法のトークンを要約している。
【表１】
2008535317.tif 000003
【００２４】
単一のストリームに適用されてもまたはストリームの群（すなわちプレゼンテーション）に適用されてもこれらの方法の各々は通常ではクライアント−サーバ配列内のＲＴＳＰトランザクションをさらに規定するために使用されるいくつかのヘッダ領域を供給される。これらおよび関連するＲＴＳＰ要求に関する追加的な詳細は、本願明細書に参照で組入れられるＳｃｈｕｌｚｒｉｎｎｅら（日付け１９９８年４月）によるＩＥＴＦリクエストフォーコメント（ＲＦＣ）２３２６、「Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）」に見出されることが可能である。
【００２５】
ＲＴＳＰが既に有る方法を新たなパラメータで拡張する方式によるか、または促進された機能を付与するように設計される新たな方法を規定するかのどちらかによって拡張を供給するのに十分なほど用途が広いことは理解されるはずである。下記で見受けられるであろうが、本特許開示は例えば上記で述べられた配列３００などのクライアント−サーバ配列の中のサーバ側プレイリストに関して高められたプレイリスト検索能力を可能にする新たな方法を提供する。
【００２６】
ここで図４を参照すると、これに示されているものは図３に示されたクライアント−サーバ配列３００に関する動作の１つの態様のフローチャートである。ウェブサーバ３０６はユーザがサービス登録するときに見込まれる初期のプレイリストを作り出す（ブロック４０２）ように動作可能である。１つの実践例では、初期のプレイリストは単純にデフォルトのプレイリストであってもよく、これが後にカスタマイズされる。クライアントアプリケーション３０２は特定のプレイリストにアクセスするためにウェブサーバ３０６への要求を作り（ブロック４０４）、するとサーバ３０６はサーバアプリケーションモジュール３０８上のメタデータファイル作成サービスに対して特定のプレイリストに関するＳＤＰファイルについての要求を作る（ブロック４０６）。次いでメタデータファイル作成サービスがＳＤＰファイルに関してこの要求をＬＣＭ３１４に伝える（ブロック４０８）。ＳＤＰファイルがＲＴＳＰ  ＤＥＳＣＲＩＢＥ要求を介して得られていることが可能なデータ、ならびに追加的な情報を含み、それゆえにクライアントアプリケーション３０２が別個のＲＴＳＰ  ＤＥＳＣＲＩＢＥ要求を出さなくてもよいことを当業者は理解するはずである。ＳＤＰファイルに応答して、ＬＣＭ３１４はプレイリストファイルおよび適切な（複数の）メディアファイルを開き、ＳＤＰ情報を作り出し、それをメタデータファイル作成サービスへと返し（ブロック４１０）、これがＳＤＰファイルを要求元ウェブサーバ３０６へと送る（ブロック４１２）。引き続いて、ウェブサーバ３０６が、デジタルマルチメディア装置上で実行するクライアントアプリケーション３０２へと（予め作り出された）プレイリストおよびこれに対応するＳＤＰファイルを返す（ブロック４１４）。クライアントアプリケーション３０２は、選択されたメディアの配信を受け取るためのストリーミング用モジュール３１０とストリーミングセッションを確立するプレーヤエンジン３０４にこのＳＤＰファイルを送る（ブロック４１６）。例えば複数のオーディオファイルが含まれる場合、これらはいくつかの方式、例えばアドバンストオーディオコーディング（ＡＡＣ）、Ｗｉｎｄｏｗｓ（登録商標）メディアオーディオ（ＷＭＡ）、ＭＰ３などにコード化されることが可能である。
【００２７】
さらなる変形例では、ＬＣＭ３１４はＳＤＰファイルを作り出す工程に含まれなくてもよい。その代わりに、ベースのＳＤＰ記述を受け取るためにメタデータファイル作成サービスが直接（ＲＴＳＰ  ＤＥＳＣＲＩＢＥを介して）ストリーミングサーバへの要求を作る。その後、メタデータファイル作成サービスは受け取ったＳＤＰ記述を改造してクライアントの消費に適したものにする。付け加えると、必ずしもプレイリストファイルがすべてのケースでＳＤＰファイルと共にクライアントアプリケーションに配信されるわけではない。クライアントアプリケーションがプレイリストファイルの構文を理解する１つの実施形態では、プレイリストはＳＤＰファイルに付け加えて供給されてもよく、それにより、はるかに豊かなユーザエクスペリエンスおよびクライアントとの相互作用を可能にする。クライアントが全体としてプレイリストに全く気付かなくてもよいケースでは、ＳＤＰファイルのみを受け取るであろう。
【００２８】
図５は本発明の教示に従ってプレイリスト検索能力をもたらすための仕組みの実施形態のフローチャートであり、ここではユーザ（すなわちメディア需要者）は中にあるいずれのメディアクリップでプレイリストを開始することも可能である。１つの実施形態では、プレイリストのための適切なプレイリスト関連制御属性はクライアント側に伝えられるＳＤＰファイル（すなわちクライアントアプリケーションとこれに付随するメディアプレーヤエンジン）内に供給される。場合によっては、プレイリスト関連制御属性はＲＴＳＰ  ＵＲＬを介して照会ストリング内の内蔵パラメータとして供給されてもよい（ブロック５０２）。言い換えると、必ずしもプレイリストセッションがＳＤＰファイルで始まる必要がないことは理解されるはずである。そうではなく、これらは単純に（例えばウェブページに内蔵される）ＲＴＳＰ  ＵＲＬで始まることも可能である。前に述べられたメタデータファイル作成サービスは内蔵のプレイリスト関連制御属性を備えたＲＴＳＰ  ＵＲＬの作成をサポートするように適切に変更されることもあり得る。このシナリオでは、クライアントがサーバへのＤＥＳＣＲＩＢＥ要求を作り、これに応答した適切なＳＤＰファイルを受け取る。どちらのケースでも、受け取ったプレイリスト関連制御属性に応答してＲＴＳＰメッセージがプレーヤエンジン３０４によってＳＭモジュール３１０へと供給され、このメッセージは識別されたプレイリストに付随するＵＲＬ照会ストリング内にプレイリスト関連制御属性を含む（ブロック５０４および５０６）。ＳＤＰデータに応じて（ＳＤＰファイルを通じて、またはＲＴＳＰ  ＤＥＳＣＲＩＢＥ要求に応答して返されるＳＤＰデータを通じてのどちらかで）、プレイリスト照会ストリング属性はセッションレベルまたはメディアレベルのどちらかのＵＲＬ内に存在すると考えられる。したがって、下記で例証されるであろうが、メディアレベルのＵＲＬ内のプレイリスト属性はＳＥＴＵＰ要求内に担持されてもよく、それに対してセッションレベルのＵＲＬに基づいたプレイリスト属性は他のＲＴＳＰ要求に担持されてもよく、適切な変更はサーバ側論理回路に供給される。
【００２９】
ストリーミングエクスペリエンス全体にわたるユーザ制御をサポートするために、クリップインデックスパラメータ（これは特定のメディアクリップを指定するためにプレイリストの中に索引を付ける）ならびにオフセットパラメータ（これは選択されたメディアクリップの中の開始時間を指定する）がＲＴＳＰメッセージのプレイリスト関連制御属性として供給されることも可能である。特に、ユーザがプレイリスト内のいずれのメディアクリップから始めることを望むか指定するために、ＲＴＳＰ  ＳＥＴＵＰメッセージが、これらに付随するＵＲＬ照会ストリング内にストリーミングセッションの開始時にこれらの属性を含んでもよい。下記に述べられるものは１つの実施形態によるＲＴＳＰ  ＳＥＴＵＰ要求である。
ＳＥＴＵＰ＜ｕｒｌ＞？＜ｓｅｃｕｒｅ  ｑｕｅｒｙ  ｓｔｒｉｎｇ  ｅｌｅｍｅｎｔｓ＞＆ｃｌｉｐＩｎｄｅｘ＝＜ｉｎｄｅｘ＞
＆ｃｌｉｐＯｆｆｓｅｔ＝＜ｏｆｆｓｅｔ＞ＲＴＳＰ／１．０
ＣＳｅｑ：ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ
Ｓｅｓｓｉｏｎ：ｓｅｓｓｉｏｎ  ｉｄ
Ｔｒａｎｓｐｏｒｔ：ｔｒａｎｓｐｏｒｔ  ｉｎｆｏｒｍａｔｉｏｎ
ここで、
ｕｒｌは要求されたプレイリストファイルのＵＲＬであり、
ｉｎｄｅｘは特定のクリップを識別する（例えば４番目のクリップで開始する）、プレイリストの中の索引であり、
ｏｆｆｓｅｔはクリップの中の開始時間である（すなわちクリップに３０秒入れる）。
【００３０】
１つの実践例では、インデックスパラメータは「０」の値がプレイリスト内の最初のクリップを示し、「１」の値がプレイリスト中の２番目のクリップを示す等々の意味ではゼロベースであってもよい。オフセットパラメータは秒ドット小数書式のノーマルプレイタイム（ＮＰＴ）のタイムスタンプとして提供されてもよいが、他のタイムスタンプ書式（例えばＳＭＰＴＥ（映画テレビ技術者協会）およびｈｈ：ｍｍ：ｓｓ：ｆｆ（時間：分：秒：小数の秒）書式）も同様に使用されることが可能である。プレイリスト関連制御属性を有するＲＴＳＰメッセージに応答して、識別されたプレイリストに関するストリーミングセッションが適切なトランスポート上でＳＭモジュールとプレーヤエンジンの間で開始されることが可能であり、ここではプレイリストの中の特定のメディアクリップの開始およびメディアクリップの中へのオフセットはプレイリスト関連制御属性に基づいて特定される（ブロック５０８）。
【００３１】
本開示のプレイリスト検索制御を達成するために、ソフトウェアおよび／またはファームウェアのどちらかの中の適切な構造または論理回路モジュールの変更および実施は本願明細書に述べられた実例のストリーミング用メディアアーキテクチャのクライアント側ならびにサーバ側で提供されてもよいということが当業者には認識されるはずである。前に示唆されたように、上述されたメタデータファイル作成サービスは、追加的な照会ストリング属性が作り出されたＳＤＰファイル内のセッションレベル制御ＵＲＬ（群）ならびにメディアレベルＵＲＬ（群）の両方の中に置かれることができるような能力を含むように変更されてもよい。メタデータファイル作成サービスへのインターフェースは照会ストリング属性を含む新たな要素を追加するように拡張されることが可能である。メタデータファイル作成への要求が新たな要素の一覧表を含む以下の実例を考える。
＜ｑｕｅｒｙＳｔｒｉｎｇＬｉｓｔ＞
＜ｑｕｅｒｙＳｔｒｉｎｇ＞ｆｏｏ＜／ｑｕｅｒｙＳｔｒｉｎｇ＞
＜ｑｕｅｒｙＳｔｒｉｎｇ＞ｂａｒ＜／ｑｕｅｒｙＳｔｒｉｎｇ＞
＜ｑｕｅｒｙＳｔｒｉｎｇ＞ｂａｍ＜／ｑｕｅｒｙＳｔｒｉｎｇ＞
＜／ｑｕｅｒｙＳｔｒｉｎｇＬｉｓｔ＞
メタデータファイル作成サービスは一覧表の中の各々の要素を取り入れ、制御ＵＲＬ照会ストリングの終端に各々を付け足すように動作可能であるので、結果として得られるＳＤＰファイル内の制御ＵＲＬは以下のように見えるであろう。
ａ＝ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／ｈｏｓｔ／ｐａｔｈ？ｆｏｏ＆ｂａｒ＆ｂａｍ
【００３２】
ストリーミングが例えばプレイリスト内の５番目のメディアクリップで３５秒のオフセットを伴なって始まる場合の他の実例では、メタデータファイル作成サービスへの要求は以下を含むであろう。
＜ｑｕｅｒｙＳｔｒｉｎｇＬｉｓｔ＞
＜ｑｕｅｒｙＳｔｒｉｎｇ＞ｃｌｉｐＩｎｄｅｘ＝４＜／ｑｕｅｒｙＳｔｒｉｎｇ＞
＜ｑｕｅｒｙＳｔｒｉｎｇ＞ｃｌｉｐＯｆｆｓｅｔ＝３５．０＜／ｑｕｅｒｙＳｔｒｉｎｇ＞
＜／ｑｕｅｒｙＳｔｒｉｎｇＬｉｓｔ＞
したがって、結果として得られるＳＤＰファイル内の制御ＵＲＬは以下のように見えるであろう。
ａ＝ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／ｈｏｓｔ／ｐａｔｈ？ｃｌｉｐＩｎｄｅｘ＝４＆ｃｌｉｐＯｆｆｓｅｔ＝３５．０
【００３３】
プレイリスト関連照会ストリング属性はＳＤＰファイル内のセッションおよびメディアレベルの両方の制御ＵＲＬに存在することが可能であるので、ＳＤＰベースのセッション規則を使用するときにこれらの属性はクライアントからのすべての要求（例えばＳＥＴＵＰ、ＰＬＡＹ、ＰＡＵＳＥなど）に存在することが可能であることが理解されるはずである。好ましくはサーバ側の論理回路が下位互換性になるように、ＳＭは追加のプレイリスト関連制御属性を伴なうかまたは伴なわないＲＴＳＰ要求メッセージを受け取ることが可能である。ＳＭが追加的な属性を伴なった第１のＳＥＴＵＰメッセージを受け取れば、これがストリーミングセッションを新たな属性によって規定されるポイントで始めるであろう。他方で、第１のＳＥＴＵＰメッセージの中に追加的な属性が指定されていなければ、ＳＭはストリーミングセッションをプレイリスト内に規定された（すなわちデフォルトモード）第１のクリップの開始時に始めるように動作可能である。添付されたプレイリスト照会ストリング属性を有し得るいずれの後続の要求（すなわちＰＬＡＹまたはＰＡＵＳＥ）についても、ＳＭの論理回路はこれらの属性を無視し得る。
【００３４】
図６はネットワークノードからデジタルメディアコンテンツを検索するための実施形態に付随するメッセージのフロー図を描いている。例示されるように、プレーヤエンジン３０４は適切なプレイリスト関連制御属性（すなわちインデックスおよびオフセットパラメータ）のセットを有するＲＴＳＰ  ＳＥＴＵＰ要求６０４を一例のメディアネットワークノード６０２のＳＭ３１０へと出すように動作可能である。ネットワークノード６０２が、いくつかの階層方式で組織化されることが可能な様々なタイプ（例えばオーディオ、ビデオなど）から成るメディアの保管場所であってもよいことを当業者は認識するであろう。物理的コンテンツは概してプレイリストとメディアクリップで構成されてもよい。デジタルメディアに付随する実例の論理的コンテンツ階層は、各々が１つまたは複数のメディアクリップおよび／または１つまたは複数の追加的なプレイリスト（すなわち二次プレイリスト）への参照を含むことが可能な複数の一次レベルプレイリスト識別子を有してもよい。各々の二次プレイリスト参照はさらに、追加的なメディアクリップ参照および／または三次プレイリストなどへの参照を含むことも可能であり、すべての多重レベルの親子関係に配列される。
【００３５】
ＲＴＳＰ  ＳＥＴＵＰ要求６０４の発行の後、ＲＴＳＰ  ＰＬＡＹメッセージ６０８がプレーヤエンジン３０４によってＳＭ３１０へと伝えられ、これが次いでそれらの間のストリーミングデータ配信セッションを達成し、選択されたクリップおよび／またはオフセットで開始する。また、サーバ側のＳＭ３１０もプレーヤエンジン３０４に周期的なメッセージ（例えばＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージ６１０−１から６１０−Ｎ）を送るように動作可能であり、選択されたプレイリストの中の新たなメディアクリップまたは（要求があれば）全く新しいプレイリストへの切り換えを示す。
【００３６】
前述の「発明を実施するための最良の形態」に基づくと、本特許開示が、メディアプレイリストの中の特定のクリップおよびクリップの中の特定のポイントでストリーミングセッションを開始するようにストリーミングサーバノードに要求する能力をストリーミング用クライアントアプリケーションに都合良く提供することは理解されるはずである。或るいくつかの例の実施形態を参照して本発明が述べられてきたが、示されて説明された本発明の形態が単なる例の実施形態として扱われるべきであることは理解されるはずである。したがって、添付の特許請求項によって規定される本発明の趣旨および範囲から逸脱することなく様々な変更、置き換え、および改造が実現されることが可能である。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施形態が実践され得る一例のネットワーク環境を描く図である。
【図２】本発明の実施形態に従って動作可能なサーバ側メディア管理システムの一例の実施形態を描く図である。
【図３】本発明の一実施形態によるストリーミング用デジタルマルチメディアコンテンツのためのネットワーク環境内で動作可能なクライアント−サーバ配置を描くブロック図である。
【図４】図３に示されたクライアント−サーバ配置に関する動作の一態様のフローチャートである。
【図５】本発明の一実施形態に従ってプレイリスト検索能力をもたらすための仕組みのフローチャートである。
【図６】ネットワークノードからデジタルメディアコンテンツを検索するための一実施形態に付随するメッセージのフロー図である。
【図１】
2008535317.tif 000004
【図２】
2008535317.tif 000005
【図３】
2008535317.tif 000006
【図４】
2008535317.tif 000007
【図５】
2008535317.tif 000008
【図６】
2008535317.tif 000009
【国際調査報告】
2008535317.tif 000010