JP2013528332A - メディアストリームのシームレスな転送 - Google Patents

Abstract

第１のレンダリングデバイスから第２のレンダリングデバイスへの、メディアプロバイダからのメディアの転送は、ネットワーク位置およびセッションコンテキスト情報に基づいて、メディアプロバイダと第２のレンダリングデバイスとの間にネットワーク接続を確立することを含む。複製が、両方のレンダリングデバイスを聴いているユーザが経験しているような、メディアのレンダリングの実質的中断を回避し、第１のレンダリングデバイスおよび第２のレンダリングデバイス双方に所望の伝送複製が送られるように、メディアの所望の伝送複製が決定される。伝送は、メディアプロバイダから第２のレンダリングデバイスへと継続される。
【選択図】図２

Description

関連技術の相互参照
本出願は、米国特許仮出願整理番号第６１／３４８，９２７号（出願日：２０１０年５月２７日）の優先権を主張する出願である。

多様な実施形態において、本発明はメディアデバイスの利用に関し、詳細には、相互接続された無線メディアデバイスに関する。

近年、多様な種類のコンテンツ（例えば、音楽、ビデオなど）にアクセスし、これらを保存し、かつ再生する家庭用電子デバイスがますます普及している。このようなデバイスとしては、音楽およびビデオをダウンロードおよび保存するｉＰｏｄ、データ、音楽およびビデオを保存するネットワークイネーブル型記憶ドライブ、多様な娯楽プログラミングを保存する衛星ラジオ、およびデジタルビデオレコーダ（ＤＶＲ）が挙げられる。同時に、無線ネットワークも多くの家庭において普及している。多くのコンテンツソース（例えば、ｉＰｏｄ、記憶ドライブ、衛星ラジオおよびＤＶＲ）が、受信されたコンテンツを共有しかつ／またはホームネットワークを介して他のメディアデバイスによって保存するように、設計されている。

レンダリングデバイス（例えば、携帯電話、パーソナルコンピュータ（「ＰＣ」）、ポータブル音楽プレーヤまたは他の家庭用電子デバイス）を用いて行うネットワーク化されたデジタルメディアの経験（例えば、視聴など）が、ユーザにとって広く一般的になっている。典型的なレンダリングデバイスは、多様なソース（例えば、ブロードキャストラジオ、衛星ラジオ、ローカルメモリ、ローカルネットワークまたはリモートネットワーク、またはプレーヤデバイス）からデジタルメディアにアクセスして、そのメディアをローカルに接続されたスピーカまたはリモートに接続されたスピーカから再生してもよい。

ユーザがデジタルメディアを経験するセッションを既に開始し、その後レンダリングデバイスの物理的位置の変更、および／または再生を新規レンダリングデバイスに変更することを決定した場合、ユーザは、変更が行われている間、自身が選択したデジタルメディアの経験を停止する必要がある。例えば、ユーザは、ネットワーク音声／ビデオ受信器（「ＡＶＲ」）を用いてデジタルメディアを経験しており、その後再生を、同一または他の、位置またはネットワーク内の携帯電話へ切り換える場合がある。このような場合、ユーザは、ＡＶＲ上での現在の再生セッションを停止し、新規のレンダリングデバイス上において同じデジタルメディアコンテンツを見つけだし、その後サービスまたはセッションを再開し、元のセッションのときと同じ再生における同一時点まで早送りする必要がある。

実際、デジタルメディアの経験は、ユーザが複数の有能なレンダリングデバイスを利用することが可能な場合であっても、レンダリングデバイスの種類および位置に左右されることが極めて多い。

このように、現在のメディア転送方法は、第１のネットワークデバイス上において発生した（すなわち、ホストされた）デジタルメディアの第２のネットワークデバイスへの転送に限定される。例えば、ポータブルデバイス上において発生したストリーミングデジタルメディアコンテンツをホストデバイスへと転送することは可能である。しかし、これら現行の方法は、デジタルメディアが第３のメディアデバイス（例えば、メディアサーバまたはサービス）から発生したものである場合に、デジタルメディアの第１のデバイスから第２のデバイスへの転送に対処することができない。さらに、これら現行の方法は当該メディアコンテンツがウェブベースのサーバまたはサービスからストリームされる場合に、かかるコンテンツがメディアストリーム（例えば、無線局）であるかまたは有限メディアファイルであるかに関係無く、デジタルメディアコンテンツの第１のデバイスから第２のデバイスへの転送に対処しない。

加えて、既存のネットワークインフラストラクチャは、シームレスな転送を困難にする。例えば、ＴＣＰ／ＩＰプロトコル群は、インターネットにおけるネットワーキングインフラストラクチャの基盤である。ネットワーク層において、インターネットは、ともに階層的に接続された１組のネットワークまたは自律システムとみなされる。インターネットプロトコル（すなわち「ＩＰ」）は、これらのネットワークを共に接続させる機構である。その基本的機能は、データのソースから目的地へ、両者の物理的位置とは無関係に送達することである。ＩＰは、各ノードを、インターネットに対する各ノードの物理的取り付けを指定するＩＰアドレスを用いて一意に特定する。

ＩＰは、パケットの目的地ＩＰアドレスからネットワーク情報を決定することにより、ネクストホップを決定する。一方、ＴＣＰなどのより高レベルの層は、終点およびポート番号の両方のＩＰアドレスを含む４つ組によってインデックスされた接続についての情報を維持する。よって、ＴＣＰ／ＩＰネットワーキングを用いた、ストリーミングセッションの、一方のメディアレンダリングデバイスから別のメディアレンダリングデバイスへのシームレスな転送は、多くの困難に直面する。例えば、ストリーミング音声を含むパケット中の目的地アドレスは、元々のレンダリングデバイスのアドレスから新規レンダリングデバイスのアドレスへと変更する必要がある。さらに、既存のＴＣＰ接続は、接続の維持のためにＩＰアドレスを同一に保持することに依存する場合があるため、ストリームの途中でのＩＰアドレスの変更は、接続が中断させる場合がある。

いずれの場合においても、既存の方法は、消費者に対して、メディアを、中断の無いメディア経験を確実にするくらい十分に高速で転送しないだけでなく、同一コンテンツが複数のレンダリングデバイスによって再生されている場合にメディアレンダリングを同期する必要性にも対処しない。そのため、異なる種類およびソースのメディアを、多様なデバイスへ、および多様なデバイスから、つっかえること、および中断無く転送するためのロバストかつ適合可能な方法が、明らかに必要とされている。

本発明の実施形態は、ローカルベースまたはウェブベースのメディアサーバまたはサービスから発生したデジタルメディアを一方のネットワークレンダリングデバイスから別のネットワークレンダリングデバイスへとシームレスに転送するためのシステム、アーキテクチャおよび方法を含む。多様な実施形態において、本発明は、メディアを、同種のネットワークまたは異種のネットワーク上で、レンダリングデバイスへ、またはレンダリングデバイスから、および、全ての種類のネットワークレンダリングデバイスにわたって転送する。。加えて、転送は、消費者に対する中断のないメディア経験を確実にするのに十分な速度で行われる。一実施形態において、レンダリングデバイス上のアプリケーションとメディアサーバ上のアプリケーションとの協働によってシームレスな転送が達成され、これにより、以下により詳細に説明するように、既存のインターネットインフラストラクチャへの変更を最小に保持し、かつ／またはより高レベルのプロトコルに対する透明性を増加させつつ、セッションコンテキストが転送される。

従って、本発明の実施形態は、メディアプロバイダから転送されたメディアに基づいた、第１のレンダリングデバイスから第２のレンダリングデバイスへのメディアレンダリングの転送方法を提供する。方法は、第２のレンダリングデバイスのネットワーク位置をメディアプロバイダへと提供することと、第１のレンダリングデバイスとメディアプロバイダとの間のネットワーク接続に関するセッションコンテキストを前記第２のレンダリングデバイスへ提供することとを含む。その後、ネットワーク位置およびセッションコンテキストに基づいて、メディアプロバイダと第２のレンダリングデバイスとの間にネットワーク接続が確立される。複製が、両方のレンダリングデバイスを聴いているユーザが経験したような、メディアのレンダリングの実質的中断を回避するように、および所望の伝送複製が第１のレンダリングデバイスおよび第２のレンダリングデバイス双方へと送られるように、メディアの所望の伝送複製が決定される。伝送は、メディアプロバイダから第２のレンダリングデバイスへと継続される。

いくつかの実施形態において、第２のレンダリングデバイスのネットワーク位置の提供は、第１のレンダリングデバイスから提供される。提供は、トリガーイベントに応答して提供されてもよい。トリガーイベントは、第１のレンダリングデバイスまたは第２のレンダリングデバイスにおいて発生してもよい。トリガーイベントの例としては、例えば、ユーザによるメニューオプションの選択、レンダリングデバイスのうちの１つのボタンまたはスイッチの押圧、および／または所望の信号強度閾値を下回ったことを通知する信号強度通知が挙げられる。メディアプロバイダから第１のレンダリングデバイスへのメディア伝送は、メディアの所望の伝送複製における伝送後に終了されてもよい。

本明細書中に開示される本発明の実施形態の利点および特徴とともに、これらおよび他の目的は、以下の記載、添付図面および特許請求の範囲からより明らかとなる。さらに、本明細書中に記載される多様な実施形態の特徴は相互に排他的なものではなく、多様な組み合わせおよび順列で存在することができることが理解される。

図面において、異なる図面を通して、類似の参照符号は概して同一部分を指す。また、図面は必ずしも縮尺通りではなく、その代わりに、概して本発明の原理を例示する、強調が施されている。以下の記載において、以下の図面を参照しつつ、本発明の多様な実施形態が記述される。

本発明の多様な実施形態による、２つのレンダリングデバイス間のメディアストリームの転送を行う方法を示すデータフロー図である。 本発明の多様な実施形態によるネットワークメディアを示す。 本発明の多様な実施形態による、ネットワークメディアシステムのコンポーネント間のメディアストリームの伝送を示す。 本発明の多様な実施形態による、ネットワークメディアシステムのコンポーネント間のメディアストリームの伝送を示す。 本発明の多様な実施形態に従って、メディアシステムの複数のコンポーネントがその中の１つのデバイス上に常駐する、ネットワークメディアシステムを示す。 本発明の多様な実施形態に従って、メディアストリームがその中で１つのデバイスから別のデバイスへと転送される、ネットワークメディアシステムを示す。 本発明の多様な実施形態に従って、メディアストリームがその中で１つのデバイスから別のデバイスへと転送される、ネットワークメディアシステムの別の実施形態を示す。。

図１に示す一実施形態において、ネットワークレンダリングデバイスは、発見プロトコルを用いたネットワーク（家庭ネットワークまたは既知のＩＰアドレスおよび／または適切なＩＰアドレスを用いた公的に利用可能なＷｉＦｉネットワーク）上に存在する少なくとも１つの他のネットワークレンダリングデバイスの存在およびサービス能力（例えば、メディアレンダリングサービスの種類およびサポートされる通信プロトコル）を認識する。一般的接続性に加えて、プロトコルは、デバイスを公表または発見し、各レンダリングデバイスのサービス能力を特定する（例えば、インターネットラジオ、ＡＭ／ＦＭラジオを再生することが可能な１つのデバイス、ならびにＡｉｒｐｌａｙ／ｉＴｕｎｅおよびＰＣ／Ｗｉｎ７サーバ等を再生することが可能な別のデバイス）。発見プロトコルは、公的に利用可能なプロトコル（例えば、ｕＰｎＰまたはＢｏｎｊｏｕｒ）に基づいてもよいが、システムは、占有の発見プロトコルでも機能する場合がある。例えば、デバイスは、自身の識別情報およびサービス能力を定期的に通知することで、他のデバイスがこれらのデバイスについて学び、かつその情報を利用してもよい。占有の発見プロトコルは、ビーコニングまたは自己公表機構、登録、認証、命名規則、ドロップアンドアド機構およびサービス能力公表を含んでもよい（例えば、ラジオサービス、コーデックおよびデータレート能力、音声サンプリングレート等）。発見プロセスから得られた情報に基づいて、２つのデバイス間に接続が確立されてもよい。一実施形態において、各ネットワークレンダリングデバイスは、その他のレンダリングデバイス全ての存在および能力を認識する。

第１のネットワークレンダリングデバイス（例えば、デバイス（Ｘ））は、ネットワークメディアサーバ（ローカルデバイス）またはネットワークサービスプロバイダ（例えば、インターネットベースのストリーミングサービス）へのサービス接続を要求および確立する。これに応答して、メディアサーバまたはサービスプロバイダは、レンダリングデバイスへのデジタルメディアのストリーミングを開始する。デバイス（Ｘ）は、この特定のセッション（例えば、一意セッションＩＤ）および／または全ての付随する接続および認証データ（本明細書中、「セッションコンテキスト」と呼ぶ）を一意に特定する情報を維持してもよい。この情報は、レンダリングデバイスによってローカルに生成されてもよく、アクセス情報（例えば、ＩＰアドレス、アカウントログインおよびパスワード等）を含んでもよい。

一定時間の経過後、ユーザは、異なるレンダリングデバイス（例えば、ネットワークレンダリングデバイス（Ｙ））上におけるデジタルメディアのレンダリングについての要求を開始してもよい。メディアのレンダリングの転送の要求は、いずれかのデバイス（Ｘ）、デバイス（Ｙ）またはネットワークベースのリモートコントローラから開始されてもよい。例えば、リモートコントローラにより、ユーザが、スマートフォン、ｉＰａｄまたは家庭コンピュータのようなデバイスを用いてエコシステムとの相互作用を行うことが可能となる。いくつかの場合において、要求は、例えば信号強度インジケータ、出力レベルインジケータまたは他の状態情報に基づいて、デバイスそのものによって自動的に開始されてもよい。例えば、デバイスが自身の出力レベルが１０％を下回っていることを認識した場合、または無線信号の信号強度が最低デシベルレベルを下回った場合、要求が開始されてもよい。デバイス（Ｘ）は、必要なセッションコンテキスト情報をデバイス（Ｙ）へと送信する。セッションコンテキスト情報は、接続の確立に必要なメディアサーバまたはネットワークサービスプロバイダ間のトランザクション時間および／またはデータフローを低減または最小化してもよい。いくつかの場合において、サーバアクセスデータが１つの領域において利用可能であり、デバイスは、必要なアクセス情報をフェッチするためのプロトコルおよび１組の交換を経由する必要は無い。

その後、デバイス（Ｘ）は、ストリームされたメディアパケットを新規目的地であるデバイス（Ｙ）へと経路設定することをメディアサーバまたはネットワークサービスプロバイダに通知する。具体的には、最下層において、例えば、ＨＴＭＬ、ＪＳＯＮおよびＸＭＬなどのようなより高位の層プロトコルが利用されてもよいとしても、ＩＰを用いて情報をメディアサーバへと通信する。ＩＰアドレスに一意に結合された論理名およびネットワーキング層におけるスイッチングを促進するポートを用いて、アプリケーションレベルにおいて、目的地が特定されてもよい。この時点において、メディアストリームがデバイス（Ｘ）からデバイス（Ｙ）へとシームレスに転送される。このメディア転送は、提案されたアーキテクチャを用いて、およそ２秒未満の期間にわたって行われてもよい。概して、デバイス（Ｙ）がメディア再生を開始する準備ができるときまで、メディアストリームおよび再生がデバイス（Ｘ）によって継続され、これにより、ストリームの連続再生はほとんど、またはまったく中断されなくなる（例えば、中断はどんなに長くてもおよそ１００ミリ秒未満となる）。いくつかの場合において、デバイスは、再生セッションが、自身の「発見およびサービス公表」プロシージャの一部として、開始することが可能となる前に、バッファすることが可能な音声データの量およびバッファされる音声データの量を公表する。いくつかの場合において、切り換えにかかる時間を結合することができ、かつこれをシームレスに転送するために使用することができる。あるいは、これを、転送を完了した旨の確認を目標デバイスから入手するまで、元々のデバイスへのストリーミングを継続することができる、仲介エンティティ（ＳＭＤ）によって調整することができる。より具体的には、メディアサーバ／サービスプロバイダは、デバイス（Ｘ）による再生が継続している場合においても、デバイス（Ｙ）への伝送を開始する。なぜならば、メディアサーバ／サービスプロバイダは、各デバイスとの接続のための伝送時間を決定することによって、伝送重複の適切な量を計算することができ、これにより、中断時間が１００ミリ秒の閾値を越えないようにすることができるからである。

上述したメディアストリームを転送するのための方法は、ネットワーク種類またはネットワークレンダリングデバイスと関係無く、複数のネットワークレンダリングデバイスにわたって複数回繰り返されてもよい。一実施形態において、ソースデバイス上における再生は、目的地デバイス上での再生が開始した後まで継続され、目的地デバイス上での再生は、ソースデバイス上での再生と同期される。よって、ユーザは、例えば別個の部屋において複数のデバイスを用いて同一メディアコンテンツを再生してもよい。

いくつかの実施形態において、メディア転送に用いられるレンダリングデバイスは、同一レベルの忠実度または品質でメディアのレンダリングを等しく行うことができない（例えば、デバイス（Ｘ）は標準的精細度の音声のみの能力を有するのに対し、デバイス（Ｙ）は高精細度音声の能力を有する）。これらの実施形態において、目標レンダリングデバイスは、適合性目的のために協調ストリーミングされたデータの適切なトランスコーディングまたは変換を適用する。例えば、音声は元々の圧縮形式から線形ＰＣＭ（ＬＰＣＭ）へと復号化されてもよく、その後、目標レンダリングデバイスによって容易に受信できる新規形式に再圧縮されてもよい。代替的にまたは追加的に、メディアサーバは、ストリームデータの必要なトランスコーディングまたは変換をサーバ側において（例えば、Ｗｉｎｄｏｗｓ（登録商標）７ベースのＰＣ）において実施してもよい。セッションコンテキスト情報は、目標レンダリングデバイスがストリームデータのトランスコーディングまたは変換を行うノードを決定するために必要なデータを含んでもよい。

図２は、提案のシステムおよびアーキテクチャの一実施形態を示す。この実施形態において、図示している５個のデバイスは全て、上記した発見プロトコル（例えば、デジタルリビングネットワークアライアンス「ＤＬＮＡ」およびＢｏｎｊｏｕｒ）を通じて、相互の存在およびサービス能力を認識している。各デバイスは、相互通信のために異なるプロトコルを有してもよい。例示的な一例として、デバイス１はＤＬＮＡメディアサーバおよびプレーヤであり、デバイス２は、Ｂｏｎｊｏｕｒ通信プロトコルを用いたＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈコンピュータであり、デバイス３はｕＰｎＰ／ＤＬＮＡ ＷｉｎｄｏｗｓＰＣであり、デバイス４は、単純なＴＣＰ／ＩＰ通信プロトコルを用いたネットワークＣＥデバイスである。この例において、デバイス４は第１のデバイスであり、サーバへと接続してストリーミングメディアのレンダリングされるべきものである。レンダリングデバイス中の技術は、プロトコルの差異を解消してもよく、複数のプロトコル技術を用いて他のデバイスまたはサーバとの通信することができてもよい。その後、ユーザは、メディアストリーミングセッションをデバイス４からデバイス３（すなわち、ＷｉｎｄｏｗｓＰＣ）へとシームレスに転送することを決定する。上記した方法を通じて、メディアストリームは、デバイス３へとおよそ２秒未満でシームレスに転送され、ユーザに対してメディア中断は発生しない。しかしながら、システムは、ノードおよびサービス発見プロシージャ時において交換された情報に基づいて重複を適合させるので、データの重複はこれより長くも、または短くもすることができる。

別の例において、ユーザは、家庭ネットワークから離れて、家庭ネットワークとは異なるネットワーク上にあるポータブルデバイス（例えば、携帯電話）であるデバイス５へ、上記したプロセスと同じプロセスを用いて行いて、シームレスに、ストリーミングメディアを転送してもよい。この場合、発見および通信プロトコルは、インターネットおよび／またはセルラーデータネットワークを介して通信されてもよい。ストリームデータの形式および符号化は、上記したようにポータブルデバイス能力と適合され（例えば、ポータブルデバイスのより小さな帯域幅および／または音声能力を反映するように低減され）てもよい。レンダリングが、同一デバイス上であるが、異なるネットワーク上において発生する１つのシナリオは、携帯電話がローカルエリアネットワーク上において利用可能であり、発見において制御プロトコルが関与し、ＬＡＮを介して動作を切り換えるものである。携帯電話が家庭ネットワークの範囲である場合、ＬＡＮをストリーミングに用いてもよい。その後、携帯電話が家庭から離れるように移動した場合、ストリーミングはセルラーネットワークを介して達成されてもよい。あるいは、レンダリングデバイスがメディアサーバと協働して、通常の論理名の代わりに電話番号を用いてポータブルデバイスを特定することが必要である。

上述したように、従来のＴＣＰ／ＩＰネットワーキングシステム（例えば、図３Ａに示す先行技術のシステム）内におけるメディアストリームの転送は、シームレスではない場合がある。このようなシステムにおいて、メディアサーバは、ストリームをレンダリングデバイス（例えば、メディアプレーヤ）へと送り、１つのレンダリングデバイスから別のレンダリングデバイスへのセッションの転送に関与する。図３Ｂに示すような本発明の一実施形態において、「ストリーミングメディアディレクタ」（ＳＭＤ）と呼ばれる仲介エンティティは、ストリームをメディアサーバから受信する。ストリーミングセッションは、図３ＢにおいてセッションＸおよびセッションＹとして示す、２つのセッションを含んでもよく、ＳＭＤは、情報を１つの接続から別の接続へと中継する。図４に示すシステムを示し、そこで、デバイスＸは、メディアサーバとのストリーミングセッションを確立し、このセッションにおいて、ＳＭＤおよびプレーヤは、共にデバイスＸ内に配置される。

図５は、ストリーミングセッションが、デバイスＸからデバイスＹへと転送されるシステムを示す。ＳＭＤは、デバイスＹ内のプレーヤとの新規セッション（セッションＹ２）を生成してもよい。ここで、セッションＸを通って流れているコンテンツは、セッションＹ２へと方向付けられてもよい。デバイスＸ内のプレーヤとのセッションＹ１は終了してもよい。ストリーミングメディアは、ネットワークを２回、すなわち、メディアサーバからデバイスＸへ、それからデバイスＸからデバイスＹへと横断してもよい。

図６は、ＳＭＤが、ゲートウェイデバイス（例えば、ルータまたはスイッチまたはゲートウェイアプリケーションを実行する汎用コンピュータなどのようなネットワークデバイス）内に実装される実施形態を示す。ストリームがデバイスＸを通過してデバイスＹに到達する必要が無いため、ネットワーク帯域幅が節約がされる場合がある。一実施形態において、デバイスＸおよびデバイスＹは、同じ家庭ネットワークの一部である。別の実施形態において、ＳＭＤおよびメディアサーバは、同一のノード／システム内で実装される。

本発明は、特定の実施形態を参照しながら具体的に図示および記載してきたが、当業者によって、形態および詳細における多様な変更が、添付の特許請求の範囲によって規定されているような、本発明の意図および範囲から逸脱することなくなされてもよいことが理解されるであろう。よって、本発明の範囲は、添付の特許請求の範囲によって示され、特許請求の範囲と均等な意味および範囲内に収まる全ての変更も包含されることが意図される。

Claims (4)

1. メディアプロバイダから伝送されたメディアに基づいて、メディアのレンダリングを第１のレンダリングデバイスから第２のレンダリングデバイスへと転送する方法であって、
   前記第２のレンダリングデバイスのネットワーク位置を提供するステップと、
   前記第１のレンダリングデバイスと前記メディアプロバイダとの間のネットワーク接続に関するセッションコンテキストを前記第２のレンダリングデバイスへと提供するステップと、
   前記ネットワーク位置および前記セッションコンテキストに基づいて、前記メディアプロバイダと前記第２のレンダリングデバイスとの間にネットワーク接続を確立するステップと、
   前記メディアのレンダリングの実質的中断を回避するように、前記メディアの所望の伝送複製を決定するステップと、
   前記メディアの所望の伝送複製を前記メディアプロバイダから前記第１のレンダリングデバイスおよび前記第２のレンダリングデバイスへと伝送するステップと、
   前記メディアプロバイダから前記第２のレンダリングデバイスへの前記メディアの伝送を継続するステップと、
   から構成されることを特徴とする方法。
2. 前記第２のレンダリングデバイスの前記ネットワーク位置を前記提供することは、前記第１のレンダリングデバイスから提供される、請求項１に記載の方法。
3. 前記第２のレンダリングデバイスの前記ネットワーク位置を前記提供することは、トリガーイベントに応答して、前記第１のレンダリングデバイスから提供される、請求項１に記載の方法。
4. 前記メディアの前記所望の伝送複製における伝送後、前記メディアプロバイダから前記第１のレンダリングデバイスへの前記メディアの伝送を停止することをさらに含む、請求項１に記載の方法。

Images