JP2019507511A - 複数のメディアタイトルを再生する方法、適合メディアソース装置、メディアプレーヤ装置、メディア委譲装置、及び構成可能且つ適合されたコンピュータプログラム - Google Patents

Abstract

複数の人が一緒にいてメディアを共同で消費したい、即ち或るメディアタイトルの単一のプレゼンテーションがあり、全員が共同で観ている及び／又は聴いている場合、提示すべきメディアタイトルが複数のメディア装置（１０、２０、．．．、７０）、クラウド記憶域（１００、２００、３００）、又はストリーミングサービスにわたって分散する問題がある。この問題を解決するために、メディアの再生／プレゼンテーションを担う１つのメディア装置（１０、７０）にメディアプレーヤの機能を割り当てる概念がある。その装置は、メディアを共同で消費するセッション内でメディアソース装置（２０、３０）であるように構成されている他のメディア装置からプレゼンテーション要求を受信することができる。プレゼンテーション要求がメディアプレーヤ装置（１０、７０）によって承認される場合、提案されたタイトルが共通のプレイリストに追加される。そのタイトルは再生中にメディアソース装置（２０、３０）からメディアプレーヤ装置（１０、７０）にストリーミングされる。

Description

本開示は、複数のメディアタイトルを再生する方法に関する。本開示は、適合メディアソース装置、適合メディアプレーヤ装置、及び適合メディア委譲装置にも関する。本開示は、どのように構成されているのかにもよるが、コンピュータシステム内で実行されるとき、複数のメディアタイトルを再生する方法の中のメディアソース装置、メディアプレーヤ装置、又はメディア委譲装置の方法ステップをコンピュータシステムに実行させるコンピュータ実行可能命令を含む、構成可能なコンピュータプログラムに更に関する。

携帯電話、とりわけ現代のスマートフォンの使用が一層広がっている。歌、ビデオ、フォトピクチャ、電子新聞や電子書籍等のテキスト文書のようなメディアタイトルをスマートフォンのメモリ内に保持するためには、この種のアプリケーションがスマートフォン上の有力な機能であり、スマートフォン上で十分にサポートされるように、顧客にとってはメモリが重要である。今日ではメディアタイトルはスマートフォンの記憶手段内でアクセスできるだけでなく、メディアタイトルがクラウド内のどこかに記憶され、スマートフォンアクセス可能にされることもサポートされている。同様に、メディアタイトルは、Napster、Spotify、Deezer、Apple（登録商標） Music、又はGoogle（登録商標） Play Musicのようなストリーミングサービスの助けでアクセス可能にされ得る。そのために、スマートフォンはインターネット技術内で広く使用されているＴＣＰ／ＩＰ、ＨＴＴＰ、ＵＤＰ、ＲＴＰ、ＲＴＳＰ、ＲＴＭＰ、ＲＴＣＰ等の複数の通信プロトコルを備える。

メディアを消費するとき、メディアコンテンツへのアクセスが必要である。これにより、或る利用者のメディアコンテンツは様々な位置（ローカル装置、クラウド記憶域、ストリーミングサービス）内に記憶され得る。複数の人が一緒に集まり、パーティ中、車や電車等での移動時のような状況でメディアを共同で消費したい場合、メディアコンテンツが複数の装置に分散している、即ち第１の人のマルチメディアプレーヤ上に幾つかのタイトルが記憶されており、第２の人のプレーヤ装置上に複数のタイトルが記憶されており、第３の人のプレーヤ上に別のタイトルが記憶されていることが多々ある。従って、メディアをプレゼンテーション／再生するために装置を交代し又はプレゼンテーション／再生の前にメディアコンテンツをコピーする必要がある。

ローカルネットワーク内で又はインターネット内でメディアファイルをストリーミングするのに利用可能な技法の広範な概要をKompendium: http://kompendium.infotip.de/streaming-media.html!の中でも見つけることができる。

本発明の目的は、集団内の人々のうちの少なくとも２人又は数人に散在するメディアタイトルを人の集団が単一のメディアプレーヤ装置上に保持されるプレイリストの制御下である程度シームレスに共同で消費することを可能にする技術的手段を与えることである。即ち、プレイリストに従って再生を開始する前に、集団が消費したい全てのメディアタイトルを単一の再生装置に／内にコピーする／集める必要がない。この及び他の目的が、請求項１に記載の複数のメディアタイトルを再生する方法、請求項９に記載の適合メディアソース装置、請求項１０に記載の適合メディアプレーヤ装置、請求項１１に記載の適合メディア委譲装置、及び請求項１２に記載の構成可能且つ適合されたコンピュータプログラムによって解決される。

提案する本発明により、装置を交代し又はメディアコンテンツをコピーすることなしに、人の集団が集団内の人々の装置上に分散／記憶されているメディアコンテンツを共同で消費することができる。本発明は、複数の利用者が、１つの装置上で消費する前に装置を物理的に交代し又はメディアをコピーする必要なしに、自分のメディア（ピクチャ、音楽、ビデオ、テキスト等）を提示し、再生し、混合することができるやり方を説明する。概念は、メディアの再生を担う１つの装置を有することである。その装置は、メディアをプレゼンテーション／再生するための要求を他のメディアソース装置から受信することができる。

従属請求項は、本開示による方法及び装置に対する有利な発展及び改善を含む。

メディアプレーヤ装置（例えばスマートフォン）を選択し、次にメディアプレゼンテーション装置（例えば家庭用／車用娯楽システム）と対にする。この対にすることは無線で、ＵＳＢ又は音声／ビデオケーブルによって行うことができる。メディアプレーヤ装置はメディアプレゼンテーション装置への中央接続を有する。メディアプレーヤ装置は、プレゼンテーションを制御するのに必要な全ての共通機能（例えば音声、ビデオ、ピクチャ、文書の完全な再生制御）を有する。メディアを共同で消費するには、次に集団内の他の人々がメディアソース装置を必要とする。

本開示による方法では、メディアソース装置上に位置し又は通信ネットワーク経由でメディアソース装置によってアクセス可能なサーバ上に位置するメディアタイトルを指定するプレゼンテーション要求が、メディアソース装置からメディアプレーヤ装置に送信される。メディアプレーヤ装置は、プレゼンテーション要求内で指定されるメディアタイトルをメディアプレーヤ装置のプレイリストに追加する。従って、メディアを共同で消費するための共通のプレイリストがメディアプレーヤ装置上に保持される。

プレゼンテーション要求は、プレゼンテーション要求内で識別されるメディアタイトルのためのＵＲＬ情報（統一資源ロケータ）を含む。様々な種類の全ての携帯端末がこの情報を理解するように、かかるＵＲＬ情報は標準化されている。

メディアソース装置から離れて位置するサーバ上のメディアタイトルでは、プレゼンテーション要求認可メッセージをメディアプレーヤ装置から折り返し受信するとき、メディアソース装置がプレイリストに追加されているメディアタイトルのファイルをサーバからダウンロードし始めることが有利である。メディアタイトルをダウンロードするには通常しばらく時間がかかるので、この形態には共通のプレイリストに従ってタイトルを再生するときメディアソース装置のローカルメモリ内でメディアタイトルを入手できる利点がある。

メディアを共同で消費することに関して、メディアプレーヤ装置上のプレイリストに追加されているメディアタイトルを再生するために、メディアプレーヤ装置がメディアソース装置にアクセス要求を送信することが有利であり、そのアクセス要求に応答して、メディアソース装置は、メディアプレーヤ装置に対して要求されたメディアタイトルのストリーミングを開始する。従って、共通のプレイリストを保持するメディアプレーヤ装置に全てのメディアタイトルを前もってコピーする必要がない。

アクセス要求は、アクセスが要求されるメディアタイトルのＵＲＬ情報に基づいてメディアタイトルのファイル名及び位置を識別するＨＴＴＰ Ｇｅｔ要求に好ましくは対応する。ＨＴＴＰプロトコルは電子装置内で広くサポートされている。

同様に、メディアソース装置がストリーミングプロトコルを使ってメディアプレーヤ装置に対してメディアタイトルのストリーミングを行うことが有利である。かかるストリーミングプロトコルは両方の装置、メディアソース装置及びメディアプレーヤ装置でサポートされる必要がある。広くサポートされているストリーミングプロトコルはＨＴＴＰストリーミング、ＲＴＰストリーミング、又はＨＴＴＰチャンク転送エンコーディングのうちの１つである。

内蔵の又は接続されたプレゼンテーション手段（ラウドスピーカ、ディスプレイ）によるメディアタイトルの提示にもメディアプレーヤ装置が使用される場合、メディアプレーヤ装置はメディアプレーヤ装置上に位置するメディアファイルを再生のために復号し、復号したコンテンツを自らの又は接続されたプレゼンテーション手段によって提示する。

メディアプレーヤ装置が外部のメディアプレゼンテーション装置と対にされる場合、メディアプレーヤ装置はメディアタイトルのストリーミング中に受信されるメディアファイルのセグメントを再生のために復号し、復号したコンテンツを提示するためにメディアプレゼンテーション装置に転送する。この転送操作は、ストリーミングプロトコルを使ったメディアストリーミング操作の形を取ることもできる。

車の運転手が車用娯楽システムと対にされるスマートフォンの所有者であるような一部のシナリオでは、メディアを共同で消費するためにメディアをプレゼンテーション／再生する制御を委譲する必要がある。ここでは、別の人のメディア装置をメディア委譲装置として構成することが有利である。委譲装置はメディアプレーヤ装置を制御するために使用される。従って、メディアプレーヤ装置からメディア委譲装置に制御が委譲される。かかる制御は、プレゼンテーション要求、プレイリスト、及び再生の制御を含む。メディアプレーヤ装置から委譲装置への制御の委譲はメディアソース装置にとって透過的である。

メディアソース装置からプレゼンテーション要求を受信するとき、メディアプレーヤ装置がプレゼンテーション要求をメディア委譲装置に転送し、メディア委譲装置がプレゼンテーション要求を処理し、プレゼンテーション要求の承認時にメディアプレーヤ装置にプレイリスト更新メッセージを送信することが更に有利である。メディアプレーヤ装置は、メディア更新メッセージの受信に応答してメディアプレーヤ装置内に保持されているプレイリストにメディアタイトルを追加する。

本開示の例示的実施形態を図中に示し、以下の説明の中でより詳細に説明する。

メディアを共同で消費するセットアップの第１の例を示す。 委譲装置を含む、メディアを共同で消費するセットアップの第２の例を示す。 メディアプレーヤ及びメディアプレゼンテーション複合装置のブロック図を示す。 メディアプレーヤ及びメディアプレゼンテーション複合装置が使用される、メディアを共同で消費するセットアップの第３の例を示す。 メディアソース装置用のグラフィカルユーザインタフェースの一例を示す。 制御委譲機能が無効にされているモードにある、メディアプレゼンテーション−再生及びソース複合装置用のグラフィカルユーザインタフェースの一例を示す。 制御委譲機能が有効にされているモードにある、メディアプレゼンテーション−再生及びソース複合装置用のグラフィカルユーザインタフェースの一例を示す。 メディア委譲装置用のグラフィカルユーザインタフェースの一例を示す。 メディア委譲及びソース複合装置用のグラフィカルユーザインタフェースの一例を示す。 本開示によるスマートフォンのブロック図を示す。 メディア装置を構成するためのソフトウェアプログラムの流れ図を示す。 メディアソース装置モードに構成されたメディア装置によって実行されるソフトウェアプログラムの流れ図を示す。 メディアプレーヤ装置として構成されているメディア装置によって、又はメディアプレーヤ及びメディアプレゼンテーション複合装置として構成されているメディア装置によって実行される第１のソフトウェアプログラムの流れ図を示す。 メディアプレーヤ装置として構成されているメディア装置によって実行される第２のソフトウェアプログラムの流れ図を示す。 メディアプレーヤ及びメディアプレゼンテーション複合装置として構成されている、実行される第３のソフトウェアプログラムの流れ図を示す。 委譲装置として構成されているメディア装置によって実行される第４のソフトウェアプログラムの流れ図を示す。 メディアプレーヤ装置として構成されているメディア装置によって実行される第５のソフトウェアプログラムの流れ図を示す。

この説明は本開示の原理を示す。従って本明細書で明示的に説明され又は示されていなくても、本開示の原理を実施し本開示の範囲に含まれる様々な機構を当業者なら考案できることが理解されよう。

本明細書で挙げる全ての例及び条件付き言語は、当技術分野を促進するために発明者がもたらす本開示の原理及び概念を読者が理解するのを助けるための教示を目的とするものであり、具体的に挙げるかかる例及び条件に限定されないものと解釈されるべきである。

従って、例えば本明細書に示すブロック図は、本開示の原理を具体化する例示的回路の概念図を表すことを当業者なら理解されよう。同様に、任意の流れ図、工程図、状態遷移図、疑似コード等は、コンピュータ可読媒体内で実質的に表すことができ、そのためコンピュータ又はプロセッサによって、かかるコンピュータ又はプロセッサが明示的に示されていようがいまいが実行される様々なプロセスを表すことが理解されよう。

図示の様々な要素の機能は、専用ハードウェア並びに適切なソフトウェアに関連してソフトウェアを実行可能なハードウェアを使用することによって与えられ得る。プロセッサによって与えられるとき、それらの機能は単一の専用プロセッサによって、単一の共用プロセッサによって、又はその一部が共用され得る複数の個別のプロセッサによって与えられ得る。更に、「プロセッサ」又は「コントローラ」という用語を明示的に使用することは、ソフトウェアを実行可能なハードウェアに排他的に言及するものだと解釈すべきではなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを記憶するための読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性記憶域を制限なしに暗に含み得る。

図１は、メディアを共同で消費することが人々の集団、例えば車を有する家族の旅行中に車内で行われる本発明の一実施形態を示す。３人の人がスマートフォン１０、２０、３０を有すると仮定する。運転手又は運転手の隣の人が、車用娯楽システム４０と対にされるスマートフォン１０を有すると更に仮定する。対にするプロセスはBluetooth（登録商標）通信システムの通常の形態である。代替形態として、スマートフォン１０はＷＬＡＮインタフェース、ＵＳＢケーブル、ＨＤＭＩケーブル、別のＡＶケーブル、又は純粋なオーディオケーブル（例えばＲＣＡケーブルやヘッドフォンケーブル）によって車用娯楽システムに接続され得る。同時に、その人のスマートフォン１０は、他のスマートフォン２０、３０がＳＳＩＤ及びパスワードを使って通常の形式で接続するＷＬＡＮローカルエリアネットワークをセットアップする。この場合のＷＬＡＮネットワークはアクセスポイントになる装置がない状態で、アドホックモードでセットアップされる。セットアッププロセスは手動で行われ得る。

代替的実施形態では、車用娯楽システムが全てのスマートフォン１０、２０、３０が接続するアクセスポイントである状態で、ＷＬＡＮネットワークがインフラモードでセットアップされる。このために、車用娯楽システム４０がＷＬＡＮインタフェース（不図示）を備える必要がある。

ネットワーク内の局内のサービスを見つけるために、発見サービス（不図示）が局内に好ましくは実装される。これは所謂ＲＥＳＴサービスの形で好ましくは行われ得る。かかる発見サービスの例はＤＮＳ−ＳＤ（apple Bonjour）、ＵｐｎＰシステムの一部としてのＳＳＤＰ、及びＡｌｌＳｅｅｎアライアンスによるＡｌｌＪｏｙｎである。これらの全ての解決策はサービス通知及び発見抽出（discovery abstraction）を与える。サービスの発見に関する更なる情報については、
https://en.wikipedia.org/wiki/Zeroconfiguration_networking#Service_discovery
のリンク下のzero configuration and service discoveryに関するWikipediaのエントリを参照されたい。

車内でメディアを共同で消費する一例は音楽タイトルを聴くことである。スマートフォンの所有者は通常、自分の音楽タイトルをスマートフォン上に記憶している。同乗者が車用娯楽システムのラウドスピーカによる提示によって音楽を共同で消費する場合、それらの同乗者は予め選択されたスマートフォン１０上に位置するプレイリストの順番で自分の好きな音楽タイトルを聴きたい場合がある。第１の例では、スマートフォン１０の所有者が自分のスマートフォン上に音楽タイトルを記憶していないと仮定する。音楽を共同で消費するために、スマートフォン１０上で保持されるプレイリストに音楽タイトルを追加する必要がある。以下、このプレイリストを共通のプレイリストと呼ぶ。

この目的のために、スマートフォン２０及び３０がプレゼンテーション要求構築機能を備える。この機能は、スマートフォン１０上に位置する共通の音楽プレイリストにスマートフォンの所有者が追加したい各音楽タイトルのプレゼンテーション要求を構築し、伝送することを可能にする。プレゼンテーション要求は、最低でも音楽タイトル及びＵＲＬ情報を含む。複数のタイトルをプレイリストに追加すべきである場合、プレゼンテーション要求は全ての被選択音楽タイトル及び対応するＵＲＬ情報のリストを含む。かかるプレゼンテーション要求の一例を以下に示す：

プレゼンテーション要求はＨＴＴＰプロトコルを使って送信され、ＨＴＴＰ Ｐｏｓｔ要求の形式を有する。上記の所与の例では、プレゼンテーション要求が２つのタイトルに対するプレゼンテーション要求である。この例では、１つはプレビューのサムネイル用、もう１つは対応するオーディオストリーム用の２つのＵＲＬがタイトルごとに列挙されている。ＵＲＬ内のパス情報は、局名：例えばスマートフォン２０、ソースコンポーネント：例えばｓｃ、及び暗号化されたパス情報である識別情報：例えばtemp-id1で構成される。スマートフォン１０はスマートフォン２０のフォルダに関する情報を暗号化されていない形で得ることはないので、このパス情報の暗号化は他のスマートフォン２０のフォルダへのアクセスを制限するために重要である。そのためスマートフォン１０は、対応するtemp-idを得ることなしに他のフォルダにアクセスすることはできない。このようにしてスマートフォン２０及び３０上に位置する被選択音楽タイトルがスマートフォン１０上で保持される共通のプレイリストに追加される。スマートフォン１０のＵＩコンポーネント１３は、他の同乗者からのプレゼンテーション要求を表示するように適合される。スマートフォン１０の所有者は、次にプレゼンテーション要求を示すためのユーザメニュ内に表示されるＯＫボタンをクリックすることによってプレゼンテーション要求を手動で承認する機会を有する。

メディアソース装置２０、３０からのプレゼンテーション要求は１つ又は複数のプレゼンテーション要求項目を含む。プレゼンテーション要求項目は、メディアプレーヤ装置１０のプレイリストに追加することができ且つ／又はメディアをストリーミングするために使用される一時的なメディアストリーム位置（例えばＵＲＬ）を含む。プレゼンテーション要求項目は、視覚的表現（例えばサムネイル）及びメディアタイトルを表す他のメタデータも含み得る。プレゼンテーション要求が複数のプレゼンテーション要求項目を含む場合、メディアプレーヤ装置１０の利用者はどのプレゼンテーション要求項目を承認するのかを選ぶことができる。

プレイリストに追加される被選択音楽タイトルは、プレゼンテーション要求の送信元であるスマートフォン２０及び３０上に記憶されたままである。スマートフォン２０及び３０からの被選択タイトルは、どれもスマートフォン１０に前もってダウンロードされることはない。スマートフォン１０から離れて位置するタイトルは、プレイリストに従ってそのタイトルを再生すべきときにアクセスされる。その瞬間にスマートフォン１０は、プレイリストからのそのタイトルのＵＲＬ情報の助けでＨＴＴＰ Ｇｅｔ要求を生成する。かかるダウンロード要求の一例を以下に示す：
Get thumbnail: GET https://smartphone-20/sc/temp-id1/thumbnail HTTP/1.1
Get stream: GET https://smartphone20/sc/temp-id1/stream HTTP/1.1

ダウンロード要求はＨＴＴＰプロトコルを使って送信され、ＨＴＴＰ Ｇｅｔ要求の形式を有する。タイトルの再生は大幅な遅延なしに開始すべきなので、車用娯楽システム４０と対にされるスマートフォン１０に音楽タイトルを転送するためにＨＴＴＰストリーミングが使用されることが好ましい。より具体的には、ＨＴＴＰストリーミングの技法では、スマートフォン２０又は３０のウェブサーバは、例えば１０ｓの再生長をそれぞれ有する複数のより小さいサイズのファイル単位で再生すべき音楽ファイルのデータを編成する。ウェブサーバはインデックスファイルを作成し、インデックスファイルは、音楽タイトルの様々なチャンクを与えるより小さいサイズのファイルのためのメタデータを含む拡張プレイリストに対応する。そのように準備されたファイルセグメントは、インデックスファイルがスマートフォン１０にダウンロードされた後で生成される対応するＨＴＴＰ Ｇｅｔ要求に対する複数のＨＴＴＰ応答の中でスマートフォン１０に転送される。そのため複数の応答のそれぞれにおいて、通常のＨＴＴＰ Ｇｅｔ要求応答のようにファイルがダウンロードされ、かかる形態はその要求が標準的なＨＴＴＰトランザクションしか使用しないので、ＲＴＰ等のＵＤＰベースのストリーミングプロトコルとは異なり、標準的なＨＴＴＰトラフィックを通過させるファイアウォール又はプロキシサーバをＨＴＴＰストリーミングが越えることができるという明白な利点を有する。かかる形態は、発信源としてコンテンツが従来のＨＴＴＰサーバからオファーされ、広く利用可能なＨＴＴＰベースのコンテンツ配信ネットワーク上で配信されることも可能にする。ＨＴＴＰストリーミングの技法を明記する、Apple Inc.によって書かれたインターネットドラフトが存在している。この点に関して、本発明の開示ではこのインターネットドラフトはＨＴＴＰストリーミングに関するインターネットドラフトを表現上指す。

ＨＴＴＰストリーミングによって被選択音楽タイトルがアクセス可能にされるウェブサーバ（不図示）を与える、スマートフォン２０及び３０内のソースコンポーネント２１及び３１がある。音楽タイトルはローカル記憶域コンポーネント、典型的にはＦＥＰＲＯＭ形式のソリッドステートメモリ、又はＣＭＯＳ−ＲＡＭ、ＳＤカード、又はマイクロＳＤカード内に記憶される。記憶域コンポーネントの他のあり得る形態はＨＤＤ、ＳＤＤ、ＤＶＤ等に対応する。

スマートフォン１０は音楽ファイル片を受信し、それらを再生するために集める。再生中、音楽タイトルは音声復号のためのｍｐ３復号器やＡＡＣ復号器等、スマートフォン１０の内蔵コンポーネントである対応する復号器を使って復号される。復号器はスマートフォン１０内の再生／プレイリストコンポーネント１１の一部である。再生は復号器のバッファを埋めるのに十分なデータを入手でき次第開始し、そのため全ファイルが転送されるまで待つ必要がない。復号（未圧縮）音声データは、プレゼンテーションのために車用娯楽システム４０に出力される。車用娯楽システムは等化、サラウンドサウンドミキシング、ラウドネス、レベル調節、そして最後に車に内蔵されたラウドスピーカを用いてプレゼンテーションするためのＤＡ変換や増幅等、音を発生させるためのデータに対する後処理を行う。このデータは、上記で説明したようにスマートフォン１０とのケーブル接続（ＵＳＢ、ＨＤＭＩ、ＲＣＡ等）によって、又は無線Bluetooth接続によって車用娯楽システムに運ばれる。

今日、所有者の音楽タイトルの一部はスマートフォン内に記憶されておらず、「クラウド」、即ちクラウド記憶域プロバイダ、例えばDropbox（登録商標）のクラウド記憶装置上のどこかに記憶されていることもよくある。車内でプレゼンテーションするために「クラウド」から音楽タイトルも取得するために、スマートフォン２０及び３０を更に適合させる必要がある。スマートフォン２０の利用者のクラウド記憶域を参照番号２００でラベル付けする。スマートフォン３０の利用者のクラウド記憶域を参照番号３００でラベル付けする。

スマートフォン２０の所有者が共通のプレイリストに追加するためにクラウド記憶域２００上に記憶された音楽タイトルを選択した後、スマートフォン２０内のソースコンポーネント２１がクラウド記憶域２００に送信されるＨＴＴＰ Ｇｅｔ要求を生成する。音楽タイトルがクラウド記憶域２００から直ちにダウンロードされ、ソースコンポーネント２１のウェブサーバ上にローカルコピーが記憶される。クラウド記憶域２００からファイルをダウンロードするためのＨＴＴＰ Ｇｅｔ要求は電話網上でクラウド記憶域プロバイダに送信される。適切な電話網技術の例は、ＬＴＥ（４Ｇ）やＵＭＴＳ（３Ｇ）携帯電話通信標準である。更に、要求されたファイルは電話網を介してスマートフォン２０に転送される。

ソースコンポーネント２１はまた、クラウドからの音楽タイトルを共通のプレイリストに追加するために、クラウドからの音楽タイトルに対するプレゼンテーション要求をダウンロードプロセス前に又はダウンロードプロセス後に生成し送信する。被選択音楽タイトルに対するプレゼンテーション要求をスマートフォン１０に送信するとき、ソースコンポーネント２１は、ソースコンポーネント２１の一部としての自らのローカルウェブサーバのためのＵＲＬ情報を挿入する。

次に、スマートフォン２０によって共通のプレイリストに追加されたタイトルを再生するときが来た状況を検討する。この音楽タイトルの再生時に、スマートフォン１０内の再生／プレイリストコンポーネント１１がスマートフォン２０のウェブサーバに行くＨＴＴＰ Ｇｅｔ要求を生成する。次いでソースコンポーネント２１が音楽タイトルにアクセスし、それをローカルに記憶された音楽タイトルと同じやり方で（上記参照）ＨＴＴＰストリーミングによってスマートフォン１０に送信する。

図２は、本発明の別の実施形態を示す。同じ参照番号は図１に関して説明したのと同じコンポーネントを示し、繰返しを避けるために再び説明することはない。メディアのプレゼンテーション／再生機能の制御を別の装置に委譲することができる。委譲することは車内でメディアを共同で消費するシナリオにおいて有用であり得る。通常、運転手が車用娯楽システム４０を制御し、自分のスマートフォン１０を車用娯楽システム４０と対にする。しかし旅行の間、注意散漫になる危険があるので車の運転中はスマートフォン１０を操作することができない。そのため、他の同乗者が運転手のスマートフォン１０上に記録されている共通のプレイリストにメディアタイトルを追加したい場合は運転手がプレゼンテーション要求を手動で承認することができない。

この問題を解決するために、制御が委譲される場合、メディアプレーヤ装置１０を制御するために使用可能な委譲装置５０を導入することを提案する。従って、メディアプレーヤ装置１０からメディア委譲装置５０に制御が委譲される。かかる委譲は、プレゼンテーション要求の制御、プレイリストの制御、及び再生の制御を含む。共通のプレイリストはスマートフォン１０上に記憶されたままであることに留意されたい。メディアプレーヤ装置１０から委譲装置５０への制御の委譲はメディアソース装置２０、３０にとって透過的である。

メディアプレーヤ装置１０、委譲装置５０、及びメディアソース装置２０、３０は（グラフィカル、スピーチ等の）ユーザインタフェースコンポーネントをそれぞれ有する。メディアソース装置２０、３０のユーザインタフェースコンポーネント２２及び３２を使い、利用者はローカルメディア記憶域２３、３３上に又は関連するクラウド記憶域２００、３００内に記憶されているメディアコンテンツを提示されるように選択し、その被選択コンテンツに対するメディアプレゼンテーション要求をメディアプレーヤ装置１０に送信することができる。メディアプレーヤ装置１０のユーザインタフェースコンポーネント１３、５２又は委譲装置５０により、利用者は再生／プレイリストコンポーネント１１の共通のプレイリストに被選択コンテンツを追加するためのメディアプレゼンテーション要求を承認することができる。ユーザインタフェースコンポーネント１３、５２の助けで、全ての又は１つ若しくは複数の特定のメディアソース装置２０、３０からのプレゼンテーション要求を「常に尋ねる」／「常に許可する」のような特定のモードを構成すること、又は委譲装置５０へのメディアプレーヤ装置１０の制御の委譲を開始／停止することもできる。

図３は、本発明の更なる実施形態を示す。メディアプレーヤ装置１０、プレゼンテーション装置４０、メディアソース装置２０、３０、及び委譲装置５０の機能を１つのメディア装置６０に組み合わせることができ、そのブロック図を図３に示す。この形態は、典型的には本発明を（例えばGoogle Play Store又はAppleのiOSシステムのためのApp Storeのようなアプリケーション市場からダウンロードされ得るスマートフォンアプリ形式の）ソフトウェア手段によって実装する場合に当てはまる。アプリケーションは構成することができ、従ってメディアソース装置２０、３０、メディアプレーヤ装置１０、又は委譲装置５０として使用され得る。従って、メディアを共同で消費するセッションの始めに、人の集団は或る装置がメディアプレーヤ装置１０であること、及び任意選択的に別の装置が委譲装置５０であることに合意しなければならない。残りの装置はメディアソース装置２０、３０であるように構成されている。

図４は、本発明の別の実施形態を示す。ここでは、例えば一体型ラウドスピーカや接続されたサウンドバーによって音楽タイトルを提示するためにスマートフォン７０も使用される。従って、スマートフォン７０はプレゼンテーションコンポーネント４１を含む。加えてスマートフォン７０は、スマートフォンの利用者が所有する複数の音楽タイトルを自らのローカルメディア記憶域１４の中に記録している。従ってスマートフォン７０の所有者は、他のスマートフォン２０、３０からのプレゼンテーション要求を承認する前にプレイリストをまず定めることができる。全ファイルがローカルメディア記憶域１４内でローカルに入手可能なので、スマートフォン７０内のソースコンポーネント１５はＨＴＴＰストリーミングによって再生／プレイリストコンポーネント１１に音楽ファイルをストリーミングする必要がない。再生コンポーネントは、音楽タイトルを再生するとき通常のやり方でそこからファイルを取り出す。スマートフォン７０の所有者が、関連するクラウド記憶域１００上に記憶されている音楽タイトルを共通のプレイリストに更に追加する場合、図１の説明に関して説明したのと同じやり方でプレイリストに追加した直後にそのデータも同様にダウンロードされる。

メディアソース装置（２０、３０）がネットワークを離れる（例えば或る人が集団を離れる）場合、メディアプレーヤ装置（１０、７０）のプレイリスト内に依然として記憶されているそのメディアソース装置（２０、３０）に由来する全てのメディアストリーム位置がプレイリストから除去される。そのためにメディアプレーヤ装置（１０、７０）はどのメディアソース装置（２０、３０）がＷＬＡＮに接続されているのかをモニタする必要がある。メディアソース装置（２０、３０）の１つがＷＬＡＮとの接続を断つ場合、メディアプレーヤ装置（１０、７０）がＷＬＡＮネットワークを離れたメディアソース装置（２０、３０）に由来する全てのメディアタイトルを共通のプレイリストから除去する。

異なるカテゴリにおけるメディア装置用のグラフィカルユーザインタフェースＧＵＩの形式を図５ａから図５ｅに示す。ＧＵＩはアプリケーションプログラム、例えば上記で説明したような典型的なスマートフォンアプリケーションの一部として実装される。図５ａは、メディアソース装置２０、３０の形式で構成されているスマートフォンアプリケーション用のＧＵＩの一例を示す。画面上に示されているアプリケーション２４は、メディアソースを選択するためのウィンドウ２５を含む。このウィンドウ内で、ローカル記憶域２３、３３、又はクラウド記憶域２００、３００内に記憶されている全てのメディアタイトルが選択可能である。ウィンドウ２５内の被選択メディアタイトルをクリックすることにより、そのタイトルが再生ウィンドウ２６上に列挙される。メディアソース選択ウィンドウ２５を出た後でＯＫボタンを押すことによって利用者が選択を行うと、再生ウィンドウ２７のフィールド２８内に列挙されたタイトルに対するプレゼンテーション要求が生成される。

図５ｂは、メディアソース、メディアプレゼンテーション、メディア再生、及びメディア委譲複合装置６０の形式で構成されているスマートフォンアプリケーション用のＧＵＩの一例を示し、委譲機能は無効にされている。画面上に示されているアプリケーション６４は、複合装置の再生機能の共通のプレイリストを示すためのフィールド６６を有する再生ウィンドウ６５を含む。再生制御のためのフィールド６７が示されている。このフィールド内に典型的な再生制御ボタン、例えば再生、停止、一時停止、タイトルの早送り、タイトルの早戻しが例えばピクトグラムを使って示される。ソースウィンドウ６９は２つのフィールドを含む。フィールド６１内では、ローカル記憶域１４内に又はクラウド記憶域１００内に記憶されている全てのメディアタイトルが選択可能である。フィールド６１内の被選択メディアタイトルをクリックすることにより、そのタイトルが強調表示される。メディアソース選択フィールド６１を出た後でＯＫボタンを押すことによって利用者が選択を行うと、被選択タイトルがプレイリストフィールド６６に追加される。フィールド６２内には、他のメディアソース装置２０、３０から受信されるプレゼンテーション要求が列挙される。カーソルを使ってそれらを選択し、ＯＫボタンを押すことによって対応するプレゼンテーション要求が承認される。対応する肯定応答メッセージが要求の送信元であるメディアソース装置２０、３０に送り返される。ボタン６３を使って制御委譲機能をアクティブにすることができる。ボタン６３が押される場合、アクティブにされている委譲モジュールを有するネットワーク内の局の一覧が表示される。次いで利用者は列挙された局の１つを選択し、そうしてプレイリストの管理をどの局に委譲するのかを決定することができる。フィールド６８内で、利用者は音声信号をどの１組のラウドスピーカに出力すべきかを選択することができる。この選択は、スマートフォン７０が備えるローカルスピーカかスマートフォン７０が（例えばBluetoothやＷｉＦｉ（登録商標）によって）対にされるローカルスピーカかである。

図５ｃは、メディアソース、メディアプレゼンテーション、メディア再生、及びメディア委譲複合装置６０の形式で構成されているスマートフォンアプリケーション用のＧＵＩの一例を示し、委譲機能は有効にされている。図５ｃに示すＧＵＩは基本的に図５ｂの同じ形式を有する。但し、フィールド６６、６７、６１、及び６２はグレー表示される。これらのフィールドはプレイリストの管理機能が委譲されているスマートフォンのＧＵＩ内に表示される。従って利用者は、音声出力用のラウドスピーカを選択し、委譲停止ボタン６３ｂによって委譲を停止することだけが可能である。

図５ｄは、メディア委譲装置５０の形式で構成されているスマートフォンアプリケーション用のＧＵＩの一例を示す。同じ参照番号は図５ｂ及び図５ｃの中で示されているのと同じコンポーネントを指定する。

図５ｅは、メディアソース及びメディア委譲複合装置の形式で構成されているスマートフォンアプリケーション用のＧＵＩの一例を示す。同じ参照番号は図５ｂ及び図５ｃの中で示されているのと同じコンポーネントを指定する。

構成可能なスマートフォン６０の典型的なハードウェアコンポーネントを図６に示す。スマートフォン６０は、プロセッサ２０１、メモリ２０２及び２０３、ディスプレイパネル２０４、タッチセンサ２０５、センサ２１２及び２１３、ＧＰＳ受信機２１１、カメラ２０８及び２０７、電源管理回路２０６、並びに通信インタフェース２１０を含む。

本開示によるソフトウェアはフラッシュメモリ２０３内に記憶され、ＲＡＭ２０２を使用することによってプロセッサ２０１上で実行される。

本開示によるメディア装置６０のためのソフトウェア実装を図７の流れ図に示す。先に説明したように、アプリケーションは設定されたプリファレンス又はユーザ入力によってメディアプレーヤ装置モード、メディアプレーヤ及びプレゼンテーション装置モード、メディアソース装置モード、又はメディア委譲装置モードに構成することができる。プログラムはステップ６０１で始まる。分岐ステップ６０２で、メディア装置がメディアソース装置モードで構成されているかどうかを確認する。当然ながら、対応するユーザ入力をここで待つ必要がある。はいの場合、メディア装置をメディアソース装置モードで構成し、プログラムはラベル１に進む。いいえの場合、プログラムは分岐ステップ６０３で続行する。分岐ステップ６０３で、メディア装置がメディアプレーヤ装置モードで構成されているかどうかを確認する。はいの場合、メディア装置をメディアプレーヤ装置モードで構成し、プログラムはラベル２に進む。いいえの場合、プログラムは分岐ステップ６０４で続行する。分岐ステップ６０４で、メディア装置がメディアプレーヤ及びプレゼンテーション装置モードで構成されているかどうかを確認する。はいの場合、メディア装置をメディアプレーヤ及びプレゼンテーション装置モードで構成し、プログラムはラベル３に進む。いいえの場合、プログラムは分岐ステップ６０５で続行する。分岐ステップ６０５で、メディア装置がメディア委譲装置モードで構成されているかどうかを確認する。はいの場合、メディア装置をメディア委譲装置モードで構成し、プログラムはラベル４に進む。いいえの場合、このプログラムはステップ６０６で終了する。

ラベル１で示すプログラム部分の流れ図を図８に示す。ラベル１における開始後に、ステップ３０１で、プログラムはタイトルを選択するためのユーザ入力を待つ。かかるユーザ入力が行われると、ステップ３０２で、メディアソース装置３０がメディアプレーヤ装置１０にプレゼンテーション要求を送信する。分岐ステップ３０３で、プレゼンテーション要求の承認がメディアプレーヤ装置１０から折り返し受信されているかどうかを確認する。いいえの場合、プログラムはステップ３０１に戻る。はいの場合、プレゼンテーション要求内で識別されているタイトルがクラウド記憶装置内に記憶されているかどうかを分岐ステップ３０４で確認する。この確認は、プレゼンテーション要求内で識別されているタイトルに関するＵＲＬ情報を評価することによって行われ得る。いいえの場合、次のステップ３０５を飛ばす。はいの場合、ステップ３０５で、プログラムがクラウド記憶域３００から識別されたタイトルをダウンロードする。次の分岐ステップ３０６で、ＨＴＴＰ Ｇｅｔ要求がメディアプレーヤ装置１０から折り返し受信されているかどうかを確認する。いいえの場合、プログラムはＨＴＴＰ Ｇｅｔ要求をループ内で待つ。はいの場合、ステップ３０７で被選択タイトルのＨＴＴＰストリーミングを行う。その後、プログラムはステップ３０８で終了する。

図９は、メディアプレーヤ装置１０又はメディアプレーヤ及びプレゼンテーション装置７０によって実行されるプログラムの第１の部分の流れ図を示す。このプログラム部分の開始をラベル２及びラベル３で指し示す。分岐ステップ１０１で、プレゼンテーション要求がメディアソース装置２０、３０から受信されているかどうかを確認する。はいの場合、スマートフォンの所有者がプレイリストに追加するためのタイトルを承認した後、ステップ１０２で、メディアプレーヤ装置１０又はメディアプレーヤ及びプレゼンテーション装置７０がプレゼンテーション要求を肯定応答する。いいえの場合、プログラムはラベル２及びラベル３に分岐して戻る。次にステップ１０２で、タイトルを共通のプレイリストに追加する。プログラムのこの部分はステップ１０３で終了する。

図１０は、図１に示すメディアプレーヤ装置１０内で実行されるプログラム部分の流れ図を示す。このプログラム部分はステップ１１０で開始する。ステップ１１１で、プレーヤが共通のプレイリスト上の次のタイトルを再生するために選択する。ステップ１１２で、プレイリストに対するタイトルの提案元であるメディアソース装置にＨＴＴＰ Ｇｅｔ要求を送信する。ステップ１１３で、メディアプレーヤ装置１０がＨＴＴＰストリーミングによって戻ってくる全てのファイルセグメントをメモリ内に集める。タイトルの再生はステップ１１４で開始する。ここでは、十分なセグメントを受信しており、それにより復号バッファが十分満たされている場合に再生を開始する。ステップ１１５で、復号データをケーブル接続によって又はＷＬＡＮ、Bluetooth、若しくは別の無線通信技術の助けで無線によってメディアプレゼンテーション装置４０に転送する。プログラムのこの部分はステップ１１６で終了する。復号コンテンツを圧縮形式でプレゼンテーション装置に運ぶために、AppleのAirplayプロトコルを使用することができる。そのプロトコルによれば、Apple Lossless音声コーディング法が使用される。代替的に、ＳＢＣコーディング又はaptXコーディングを伴うBluetooth A2DPプロトコルを使用することができる。但し、ＳＢＣコーディング及びaptXコーディング技法は無損失コーディング法ではない。

別の実施形態では、改善されたバッファ機構を実装することができる。改善されたバッファ機構では、バッファがタイトルの一部を前もってロードする。そのため、現在再生されているタイトルが終わりに近づいている場合、プレイリスト内の次にくるタイトルの最初の部分をバッファ内にロードしてから次のタイトルを実際に再生する。かかる形態は、プレイリストの次にくるタイトルを再生するときに途切れが発生するのを防ぐ。言い換えれば、この解決策はシームレスな再生体験に有利である。

図１１は、図４に示すメディアプレーヤ装置７０内で実行されるプログラム部分の流れ図を示す。このプログラム部分は、図１０にあるのと同じプログラムステップ１１１、１１２、１１３、及び１１４を含む。異なる点は、プレゼンテーションがメディアプレーヤ装置７０自体によって行われることである。従って、図１０のステップ１１５は行われない。プログラムのこの部分はステップ１１７で終了する。

図１２は、図３の委譲装置５０内で実行されるプログラム部分の流れ図を示す。分岐ステップ５０１で、転送されたプレゼンテーション要求がメディアプレーヤ装置１０から受信されているかどうかを確認する。いいえの場合、プログラムはこの要求が受信されるのをループ内で待つ。はいの場合、ステップ５０２において、要求を有効化するユーザ入力後、メディア委譲装置５０は、メディアプレーヤ装置１０の代わりにプレゼンテーション要求の受信をメディアソース装置２０、３０に肯定応答する。更にメディア委譲装置５０は、プレゼンテーション要求の受信をメディアプレーヤ装置１０に肯定応答する。プログラムはステップ５０３で終了する。

次に図１３の流れ図を簡潔に説明する。この流れ図は、図３のメディアプレーヤ装置１０によって実行されるプログラムに関するものである。プログラムの開始を参照番号１２０で示す。確認ステップ１２１で、プレゼンテーション要求がメディアソース装置２０、３０から受信されているかどうかを確認する。ステップ１２２で、メディアプレーヤ装置１０がプレゼンテーション要求をメディア委譲装置５０に転送する。ステップ１２３で、転送されているプレゼンテーション要求に対する肯定応答メッセージがメディア委譲装置５０から折り返し受信されているかどうかを確認する。いいえの場合、プログラムは分岐ステップ１２３にループして戻る。はいの場合、ステップ１２４で、プレゼンテーション要求メッセージ内で提案されたタイトルをメディアプレーヤ装置１０内のプレイリストに追加する。プログラムはステップ１２５で終了する。

メディアタイトルとして音楽タイトルの例を使って本開示の実施形態を説明してきた。但し、メディアタイトルはビデオタイトル、電子書籍タイトル、ゲームタイトル、テキストタイトル、プレゼンテーションのタイトル、ピクチャタイトル等の他のタイトルとすることもできる。かかるタイトルをプレゼンテーションするために、メディアプレーヤ装置１０、７０の外部又は内部にあり得るディスプレイを使用する必要がある。当然ながら、ここでのディスプレイとは、ヘッドアップディスプレイ形式であろうがデータグラス形式であろうが任意の形式のディスプレイパネル、ＣＲＴ、投写型ディスプレイ、ＬＣＤ、ＯＬＥＤ、ＰＤＰ、Ｅ−Ｉｎｋ、量子ドット等を意味する。

人々の集団がメディアタイトルを共同で消費し、集団内の全員がスマートフォンを有する例に基づいて本開示の実施形態を更に説明してきた。但し本開示はスマートフォンを使用することに限定されない。より広範に、人々の集団内で様々な種類のモバイル装置が使用され得る。概して、本発明の原理は持運び可能な任意の携帯端末に適用することができる。典型的な例は携帯電話、とりわけスマートフォン、タブレットコンピュータ、ノートブックコンピュータ、電子書籍リーダ、スマートウォッチ、ナビゲーションシステム等である。

図１に関連して説明した実施形態に関して或る独特な代替的実施形態がある。クラウド記憶域から共通のプレイリストにタイトルを追加するとき、そのタイトルは、そのタイトルがスマートフォン２０、３０の所有者のクラウド記憶域２００、３００内に記憶されているという指示と共にプレイリストに追加される。その場合、そのタイトルはプレイリストへの追加直後にダウンロードされることはない。そのタイトルを再生する時間が来ると、スマートフォン１０は、上記の例の中で示したのと同じ種類の情報と共にスマートフォン２０、３０にＨＴＴＰ Ｇｅｔ要求を送信する。ＵＲＬ情報がtemp-id内にコード化される。このtemp-idをローカル記憶域２３、３３又はクラウド記憶域２００、３００上のＵＲＬに変換するのはスマートフォン２０、３０である。それに応答してスマートフォン２０、３０は、そのタイトルの正しいＵＲＬ情報と共にクラウド記憶域２００、３００にＨＴＴＰ Ｇｅｔ要求を送信する。折り返し受信されるデータは、タイトルがスマートフォン２０、３０上にローカルに記憶される場合と全く同じやり方でスマートフォン１０に伝えられ、それによりスマートフォン２０、３０上のパススルーモードを実装する。

更なる選択肢は、スマートフォン１０、２０、３０、５０、６０、７０の構成に関する。これらの選択肢は図７に示したプログラムの修正に関し、１つの可能性はローカル記憶域サービス又はクラウド記憶域サービスが見つかった場合にメディアソース装置を自動でアクティブにすることである。同様のやり方で、内部の又は外部のプレゼンテーションサービスが選択される場合にメディアプレーヤサービス部分を自動でアクティブにすることができる。メディアプレーヤサービスをアクティブにすることは、自らのプレゼンテーション要求を送信することができるメディアプレーヤ装置をメディアソース装置が見つけることを保証する。代替的に、メディアプレーヤサービスのアクティブ化はユーザ入力によって起こり得る。メディアプレーヤ装置からメディア委譲装置に制御を委譲できるように、メディア委譲装置部分を常にアクティブにしておくことができる。

本開示は本明細書に記載した例示的実施形態に限定されない。本開示に同じく属すると考えられる多くの異なる適合及び発展の余地がある。

提案した方法及び機器は様々な形態のハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、又はその組合せによって実装され得ることを理解すべきである。専用プロセッサは、特定用途向け集積回路（ＡＳＩＣ）、縮小命令セットコンピュータ（ＲＩＳＣ）、及び／又は書替え可能ゲートアレイ（ＦＰＧＡ）を含み得る。好ましくは、提案した方法及び機器はハードウェアとソフトウェアとの組合せとして実装される。更にソフトウェアは、好ましくはプログラム記憶装置上に有形に具体化されるアプリケーションプログラムとして実装される。アプリケーションプログラムは、任意の適切なアーキテクチャを含むマシンにアップロードされ、かかるマシンによって実行され得る。好ましくは、そのマシンは１個又は複数個の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インタフェース等のハードウェアを有するコンピュータプラットフォーム上に実装される。コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードも含む。本明細書に記載した様々なプロセス及び機能は、オペレーティングシステムによって実行されるマイクロ命令コードの一部又はアプリケーションプログラムの一部（又はその組合せ）とすることができる。加えて、追加のデータ記憶装置、警告出力装置／通信装置、印刷装置等の他の様々な周辺装置がコンピュータプラットフォームに接続され得る。

図示の要素は様々な形態のハードウェア、ソフトウェア、又はその組合せによって実装され得ることを理解すべきである。好ましくはこれらの要素は、プロセッサ、メモリ、及び入出力インタフェースを含み得る１つ又は複数の適切にプログラムされた汎用装置上でハードウェアとソフトウェアとの組合せによって実装される。本明細書では「結合」という語句は直接接続されること、又は１つ若しくは複数の中間コンポーネントを介して間接的に接続されることを意味するものであると定義する。かかる中間コンポーネントは、ハードウェアによるコンポーネント及びソフトウェアによるコンポーネントの両方を含み得る。

添付図面に示した構成要素であるシステムコンポーネント及び方法ステップの一部はソフトウェアによって実装することが好ましいので、提案した方法及び機器をプログラムする方法に応じてシステムコンポーネント（又はプロセスステップ）間の実際の接続は異なり得ることを更に理解すべきである。本明細書の教示を所与として、当業者は提案した方法及び機器のこれらの及び同様の実装又は構成を考えることができる。

Claims (11)

1. 複数のメディアタイトルの再生を委譲する方法であって、プレイリストはメディアプレーヤ装置（１０、７０）上に保持されており、
   メディア委譲装置（５０）が、前記メディアプレーヤ装置（１０、７０）からプレゼンテーション要求を受信することであって、前記プレゼンテーション要求はメディアソース装置（２０、３０）上に位置する又は通信ネットワーク経由で前記メディアソース装置（２０、３０）によってアクセス可能なサーバ（１００、２００、３００）上に位置するメディアタイトルを指定する、受信すること、
   前記メディア委譲装置（５０）が、前記プレゼンテーション要求を処理すること、及び
   前記メディア委譲装置（５０）が、前記メディアプレーヤ装置（１０、７０）にプレイリスト更新メッセージを送信すること
   を含む、方法。
2. 前記プレゼンテーション要求は、前記プレゼンテーション要求内で識別される前記メディアタイトルのためのＵＲＬ情報を含む、請求項１に記載の方法。
3. 複数のメディアタイトルを再生する方法であって、プレイリストがメディアプレーヤ装置（１０、７０）上に保持されており、
   前記メディアプレーヤ装置（１０、７０）が、メディアソース装置（２０、３０）上に位置する又は通信ネットワーク経由で前記メディアソース装置（２０、３０）によってアクセス可能なサーバ（１００、２００、３００）上に位置するメディアタイトルを指定するプレゼンテーション要求をメディア委譲装置（５０）に転送すること、及び
   前記メディアプレーヤ装置（１０、７０）が、前記メディアタイトルを前記プレイリストに追加すること
   を含む、方法。
4. 前記メディアプレーヤ装置（１０、７０）が、プレゼンテーション要求認可メッセージを前記メディアソース装置（２０、３０）に送り返すこと、及び
   前記メディアソース装置（２０、３０）が、前記プレイリストに追加されている前記メディアタイトルのファイルを前記サーバ（１００、２００、３００）からダウンロードすること
   を更に含む、請求項３に記載の方法。
5. 前記メディアプレーヤ装置（１０、７０）上の前記プレイリストに追加されている前記メディアタイトルを再生するために、前記メディアプレーヤ装置（１０、７０）が前記メディアソース装置（２０、３０）にアクセス要求を送信し、前記アクセス要求に応答して前記メディアソース装置（２０、３０）が前記メディアプレーヤ装置（１０、７０）に対して前記要求されたメディアタイトルのストリーミングを開始する、請求項１〜４の何れか一項に記載の方法。
6. 前記アクセス要求は、アクセスが要求される前記メディアタイトルの前記ＵＲＬ情報に基づいて前記メディアタイトルのファイル名及び位置を識別するＨＴＴＰ Ｇｅｔ要求に対応し、前記メディアソース装置（２０、３０）がストリーミングプロトコルを使って前記メディアプレーヤ装置（１０、７０）に対して前記メディアタイトルのストリーミングを行う、請求項１〜５の何れか一項に記載の方法。
7. 前記ストリーミングプロトコルがＨＴＴＰストリーミング、ＲＴＰストリーミング、又はＨＴＴＰチャンク転送エンコーディングのうちの１つである、請求項１〜６の何れか一項に記載の方法。
8. 前記メディアプレーヤ装置（１０、７０）が、前記メディアプレーヤ装置（１０、７０）上に位置するメディアファイル、又は前記メディアタイトルのストリーミング中に受信される前記メディアファイルのセグメントを再生のために復号し、前記復号したコンテンツをプレゼンテーションのためにメディアプレゼンテーション装置（４０）に転送し、又は自らの若しくは接続されたプレゼンテーション手段によって提示する、請求項１〜７の何れか一項に記載の方法。
9. メディアタイトルのプレイリストを保持し、
   メディアソース装置（２０、３０）上に位置する又は通信ネットワーク経由で前記メディアソース装置（２０、３０）によってアクセス可能なサーバ（１００、２００、３００）上に位置するメディアタイトルを指定するプレゼンテーション要求をメディア委譲装置（５０）に転送し、
   前記メディアタイトルを前記プレイリストに追加する
   ように構成された、メディアプレーヤ装置（１０、７０）。
10. メディアタイトルのプレイリストが保持されているメディアプレーヤ装置（１０、７０）からプレゼンテーション要求を受信することであって、前記プレゼンテーション要求はメディアソース装置（２０、３０）上に位置する又は通信ネットワーク経由で前記メディアソース装置（２０、３０）によってアクセス可能なサーバ（１００、２００、３００）上に位置するメディアタイトルを指定する、受信すること、
    前記プレゼンテーション要求を処理すること、及び
    前記メディアプレーヤ装置（１０、７０）にプレイリスト更新メッセージを送信すること
    を行うように構成された、メディア委譲装置（５０）。
11. コンピュータシステム内で実行されるとき、請求項１〜８の何れか一項に記載のメディアプレーヤ装置（１０、７０）又はメディア委譲装置（５０）の方法ステップを前記コンピュータシステムに実行させるコンピュータ実行可能命令を含む、構成可能且つ適合されたコンピュータプログラム。