サービス・レイヤにより支援する、マルチメディア・ストリーム・アクセス配信の変更
ストリーミング・サーバが、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにより配信のためのマルチメディア・ストリームを移動端末に送る。かかる移動端末がアクセス配信をユニキャストからブロードキャストに変更することを支援するために、ストリーミング・サーバは、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を送る。移動端末は、ユニキャストによりマルチメディア・ストリームを受信すると、そのようなマルチメディア・コンテンツ・タイミング情報を受信する。移動端末は、同じマルチメディア・ストリームがまたブロードキャストにより利用できることを決定するけれども、移動端末は隙間中にユニキャストからブロードキャストへの変更を開始する。移動端末はアクセス変更を隙間まで遅らせるので、アクセス変更に起因するどのようなデータ損失も、マルチメディア・コンテンツの加入者体験にわずかな影響を与えるだけである。さらに、隙間がよく生じて、そのような変更が大して遅れることなく、そしてこのようにして、ブロードキャストの使用も大して遅れないであろうということを保証する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は広く、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおけるマルチメディア・ストリームのアクセス配信を変更するための方法および装置に関するものであり、詳しくはマルチメディア・ストリームのコンテンツにおける隙間（interstice）にユニキャスト配信からブロードキャスト配信に変更することに関する。
【背景技術】
【０００２】
移動体ネットワークでのマルチメディア・コンテンツ（たとえば、移動体テレビ）の配信に対する需要が増大しており、ブロードキャスト技術を用いてマルチメディア・コンテンツを配信する要請が強まってきている。ブロードキャスト技術は、より効率的なネットワーク利用を保証するブロードキャスト・ベアラ・サービス、たとえば、デジタル映像放送−ハンドヘルド（ＤＶＢ−Ｈ）およびマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）などの使用を伴う。加入者が同じ地域で同じマルチメディア・コンテンツを要求していても、各加入者に１つのリンクを消費する、ユニキャスト・ベアラ・サービス（たとえば、３Ｇでのパケット交換ストリーミング）とは違って、ブロードキャスト・ベアラ・サービスは、加入者がかかる同じマルチメディア・コンテンツに対して単一のリンクを共用することを可能にする。しかしながら、マルチメディア・コンテンツを要求する加入者の数が減少するにつれて、ブロードキャスト配信の効率も低下する。したがって、ネットワーク運用会社は、あるマルチメディア・コンテンツのブロードキャスト配信を、いつでもどこでも利用できるようにすることを拒否する場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークでは、ユニキャスト配信は、あるマルチメディア・ストリームに対するブロードキャストのサービスエリアが有効でない場所および時間に、ブロードキャスト配信を補完する。すなわち、移動端末は、あるマルチメディア・ストリームのブロードキャスト配信が利用できなくなる場合を検出し、そしてマルチメディア・ストリームに対してユニキャスト配信を用いるように変更する。そのような変更は、ブロードキャストのサービスエリアを欠くにも係らず、配信を可能にするが、移動端末は、ブロードキャストのサービスエリアが再度利用できるようになると、より効率的なブロードキャスト配信を用いるように戻るべきである。
【０００４】
移動端末がブロードキャスト配信を用いるように戻る時間は、しかしながら、ネットワーク利用の効率と加入者のマルチメディア体験の双方に影響する場合がある。ブロードキャストサービスエリアが安定しないうちに、移動端末がブロードキャスト配信を用いるように戻ると、たとえば、ユニキャスト配信とブロードキャスト配信との間でのピンポン効果が、重大なデータ損失および加入者のマルチメディア体験の中断をもたらす場合がある。他方、移動端末が、潜在的にかなりの量の時間（たとえば、加入者がマルチメディア・チャネルを変更するまで）変更を遅らせることにより、この中断を回避すると、ネットワーク利用が著しくより非効率になる。
【課題を解決するための手段】
【０００５】
本明細書で教示される方法および装置は、ネットワーク・リソースを効率的に利用するとともに、ユーザのマルチメディア体験における中断を最小限にしながら、移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するのを、都合よく可能にする。ブロードキャスト配信が利用できるようになると直ぐにそのような変更を開始する代わりに、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報に従って移動端末が変更を開始する。そのような隙間中での変更に起因するデータ損失はいずれも、加入者のマルチメディア体験にわずかしか影響を与えない。さらに、隙間がよく生じて、そのような変更が大して遅れることなく、そしてこのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【０００６】
より詳しくは、移動端末が、ユニキャスト・ベアラでユニキャスト配信によるマルチメディア・ストリームだけでなく、かかるマルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する。マルチメディア・ストリームのコンテンツが、１つ以上のマルチメディア・プログラムおよび１つ以上の商業広告を備えると、たとえば、そのようなコンテンツにおける隙間が、各マルチメディア・プログラム（たとえば、商業広告）間の合間（breaks）、またはマルチメディア・プログラムと商業広告との間の合間を含む場合がある。あるいは、マルチメディア・ストリームのコンテンツは、映画フィルムすなわち映画を備える場合があり、そしてそのようなコンテンツにおける隙間がその中に１つ以上のシーン・カットを含む場合がある。したがって、移動端末はその後、同じマルチメディア・ストリームがブロードキャスト・ベアラでブロードキャスト配信により利用できるようになるのを決定するけれども、移動端末は、マルチメディア・コンテンツ・タイミング情報に示された隙間中に、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【０００７】
そのような変更を補助するために、マルチメディア・ストリームを移動端末に送るストリーミング・サーバが、このマルチメディア・コンテンツ・タイミング情報を決定する。ストリーミング・サーバは、たとえば、マルチメディア・ストリームのコンテンツ自身を、たとえば、商業広告または他の映像素材がマルチメディア・プログラムに追加されている時間を自律的に識別することによるなどで、解析する場合がある。あるいは、ストリーミング・サーバは、マルチメディア・コンテンツにおける隙間の表示を、対応するコンテンツ・プロバイダから受信する場合がある。いずれにしても、ストリーミング・サーバは、このマルチメディア・コンテンツ・タイミング情報を移動端末に送る。ストリーミング・サーバは、たとえば、移動端末の要求に応答して、またはそのような情報が付加されていることを移動端末により知られているメッセージにそのような情報を付加することによって、そのような情報を送る。勿論、本発明は上記の特徴および利点に限定されない。実際、当業者は、以下の詳細な明細書を読むと、そして添付図面を見ると、さらなる特徴および利点を認めるであろう。
【図面の簡単な説明】
【０００８】
【図１】図１は、本発明が用いられる場合があるマルチメディア・システムのブロック図である。
【図２】図２は、本発明のストリーミング・サーバの１つの実施形態を説明するブロック図である。
【図３】図３は、移動端末がアクセス配信をユニキャスト配信からブロードキャスト配信に変更するのを補助するための、ストリーミング・サーバにおける方法の論理フロー図である。
【図４】図４は、本発明の移動端末の１つの実施形態を説明するブロック図である。
【図５】図５は、アクセス配信をユニキャスト配信からブロードキャスト配信に変更するための、移動端末における方法の論理フロー図である。
【図６Ａ】、
【図６Ｂ】、
【図６Ｃ】図６Ａから図６Ｃまでは、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰによってストリーミング・サーバに要求することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図である。
【図７】図７は、マルチメディア・コンテンツ・タイミング情報が追加されることを知られている、ストリーミング・サーバのＲＴＳＰ ＰＬＡＹ応答を復号することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図の一部である。
【図８】図８は、マルチメディア・コンテンツ・タイミング情報が追加されることを知られている、ストリーミング・サーバのＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを復号することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図の一部である。
【発明を実施するための形態】
【０００９】
図１は、本発明が採用される場合があるマルチメディア・システム１０を説明している。マルチメディア・システム１０は、サービス・レイヤ２０および、移動端末４０にマルチメディア・ストリームを配信するためのハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０を備える。
【００１０】
マルチメディア・ストリームをそのような配信に利用できるようにするために、サービス・レイヤ２０は、１つ以上のコンテンツ・プロバイダ２２、ＩＰネットワーク２４およびストリーミング・サーバ５０を備える。１つ以上のコンテンツ・プロバイダ２２は各々、マルチメディア・コンテンツ、たとえば、移動体テレビのための音響／映像プログラムおよび商業広告または映画フィルムすなわち映画などを準備する。移動端末４０にストリーミングするためにマルチメディア・コンテンツを適切なフォーマットに符号化してから、各コンテンツ・プロバイダ２２は、このコンテンツをＩＰネットワーク２４によって、ストリーミング・サーバ５０に送る。
【００１１】
ストリーミング・サーバ５０は、１つ以上のコンテンツ・プロバイダ２２から送られるコンテンツに対する多くのマルチメディア・ストリームを構築する。各マルチメディア・ストリームは、他のマルチメディア・ストリームと異なるコンテンツを有し、移動端末４０に、あるマルチメディア・コンテンツを受信するために、いずれのマルチメディア・ストリームを受信するべきかを知るように求める。このようにして、サービス・レイヤ２０は、各コンテンツ・プロバイダ２２から送られるコンテンツに関する情報を電子サービス・ガイド（ＥＳＧ）に集約しており、ＥＳＧは、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０で配信される、あるマルチメディア・ストリームによって、あるマルチメディア・コンテンツをどのように受信するかを移動端末４０に説明する。
【００１２】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０には、ストリーミング・サーバ５０により提供されるマルチメディア・ストリームのブロードキャスト配信に用いられるブロードキャスト配信リソース３４（たとえば、ブロードキャスト・ベアラ・サービス）がある。ブロードキャスト・ベアラ・サービスの例には、たとえば、デジタル映像放送−ハンドヘルド（ＤＶＢ−Ｈ）およびマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）がある。特定のブロードキャスト・ベアラ・サービスに係らず、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０は、かかるマルチメディア・ストリームのコンテンツの人気によっては、特定のマルチメディア・ストリームをブロードキャスト配信によって提供可能である。そうであると、ブロードキャスト配信によってかかるマルチメディア・ストリームを受信するために、移動端末４０は、ＥＳＧの説明に従ってブロードキャスト・ベアラ・サービスに同調する。ＤＶＢ−Ｈが利用される場合、たとえば、移動端末４０は、ストリーミング・サーバ５０がマルチメディア・ストリームをプッシュ配信するＩＰポートであるとしてＥＳＧに挙げられている、あるＩＰポートにローカル参加する。
【００１３】
マルチメディア・ストリームのブロードキャスト配信は、しかしながら、ある時間に、ある地域でのブロードキャストサービスエリアを欠くために、利用できなくなる場合がある（たとえば、ＤＶＢ−Ｈが利用されていると、信号強度が、一定のサービス品質には不十分である場合がある）。したがって、ＥＳＧはまた、ブロードキャスト配信が利用できなくなるような場合に、かかるマルチメディア・ストリームをユニキャスト配信によってどのように受信するかを、移動端末４０に説明する。ユニキャスト配信のために、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０には、ユニキャスト配信リソース３２（たとえば、ユニキャスト・ベアラ・サービス）がある。ユニキャスト・ベアラ・サービスの例には、たとえば、３Ｇでのパケット交換ストリーミングまたは汎用移動体通信システム（ＧＳＭ）がある。ユニキャスト配信によってマルチメディア・ストリームを受信するように変更を開始するために、移動端末４０は、ブロードキャスト配信によってマルチメディア・ストリームを受信するのを停止し、そしてストリーミング・サーバ５０からのマルチメディア・ストリームのユニキャスト・フローを開始するのに、ＥＳＧにおけるＵＲＩにより識別されるように、アプリケーション・レベル・プロトコルを利用する。実時間ストリーミング・プロトコル（ＲＴＳＰ）は、たとえば、このようにストリーミング・サーバ５０を制御するために用いられる場合がある。
【００１４】
しかしながら、マルチメディア・ストリームのユニキャスト配信は、マルチメディア・ストリームのブロードキャスト配信よりも効率を下げてネットワーク・リソースを利用するので、移動端末４０は、ブロードキャスト配信が再び利用できるようになると、ブロードキャスト配信を用いるように戻す変更を選択的に開始する。けれども、移動端末４０がこのアクセス変更を開始する特定の時間は、ブロードキャスト配信の可用性ばかりでなく、そのような変更がマルチメディア・ストリームのコンテンツの加入者視聴に及ぼす恐れのある影響にも依存する。
【００１５】
加入者の視聴体験の中断を最小にする時間で、移動端末４０がユニキャスト配信からブロードキャスト配信に変更するのを支援するために、ストリーミング・サーバ５０は図２に従って構成される。図２では、ストリーミング・サーバ５０は、ネットワーク・インタフェース回路５２および、ストリーム処理回路５６および隙間決定回路５８を含む、１つ以上の処理回路５４を備える。ストリーム処理回路５６は、ネットワーク・インタフェース回路５２により、移動端末４０を含めて１つ以上の移動端末にマルチメディア・ストリームを送るためにマルチメディア・ストリームを構築し、そして管理するように構成される。たとえば、ストリーム処理回路５６は、マルチメディア・ストリームのユニキャスト配信を開始するために、上記のプロトコル、たとえばＲＴＳＰなどに従って、マルチメディア・ストリームを管理する場合がある。
【００１６】
ストリーミング・サーバ５０は、しかしながら、隙間決定回路５８により決定され、そしてネットワーク・インタフェース回路５２により移動端末４０に送られるマルチメディア・コンテンツ・タイミング情報に従って、移動端末４０がユニキャスト配信から変更するのを支援する。そのようなマルチメディア・コンテンツ・タイミング情報は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示す。そのようなマルチメディア・コンテンツ・タイミング情報を移動端末４０に提供する際、ストリーミング・サーバ５０は、移動端末４０がマルチメディア・コンテンツにおける隙間中にユニキャスト配信からブロードキャスト配信への変更を選択的に開始できるようにし、そしてそれによって、変更により引き起こされるマルチメディア・コンテンツにおけるどのような中断も最小限にする。さらに、隙間がよく生じて、そのような変更が大して遅れることなく、そしてこのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【００１７】
１つの実施形態では、たとえば、マルチメディア・ストリームのコンテンツは、１つ以上のマルチメディア・プログラムおよび１つ以上の商業広告を含む。この場合、そのようなコンテンツにおける隙間は、マルチメディア・プログラムと商業広告との間に存在する切れ目の時点を含むことがある。あるいは、隙間には、マルチメディア・プログラム間の切れ目が、たとえば商業広告中などに存在する時間間隔を含む場合がある。注目すべきは、しかしながら、ユニキャストで配信されるマルチメディア・ストリームの商業広告は、移動端末４０に個別化されており、したがって、同じ時間中にブロードキャストで配信されるマルチメディア・ストリームの商業広告とは異なる場合がある。隙間決定回路５８は、したがって、マルチメディア・コンテンツ・タイミング情報において、マルチメディア・ストリームのコンテンツがユニキャストとブロードキャストとの双方で同じである隙間のみ（すなわち、その間のアクセス配信変更が適切であろう隙間のみ）を示すように構成される場合がある。隙間決定回路５８は、代替の方法では、マルチメディア・ストリームのコンテンツにおけるすべての隙間を示すように、しかしある隙間（たとえば、その間のコンテンツがユニキャストとブロードキャストとの双方で同じでないような隙間）中にアクセス配信変更が禁止されることをまた示すように構成される場合がある。本発明は、しかしながら、マルチメディア・ストリームの特定のコンテンツに限定されない。
【００１８】
他の実施形態では、たとえば、マルチメディア・ストリームのコンテンツがそのなかにシーン・カットを含めて、映画フィルムすなわち映画を含むことを考慮している。この例では、そのようなコンテンツにおける隙間には、映画フィルムすなわち映画にあるシーン・カットの時点を含む。そのようなコンテンツにおける隙間はまた、映画クレジットなどが存在する時間間隔を含む場合がある。当業者は、したがって、そのような隙間の正確な特質が本発明を限定しないこと、そして隙間にはまたマルチメディア・ストリームのコンテンツにおける類似したどのような合間をも含む場合があることを十分理解するであろう。さらに、当業者は、隙間が様々なフォーマット、たとえば標準再生時間（Normal Play Time）（ｎｐｔ）、絶対時間（ａｂｓ）で、またはネットワーク時間プロトコル（ＮＴＰ）に従って、示される場合があることを正しく理解するであろう。
【００１９】
当業者はまた容易に、隙間決定回路５８がマルチメディア・コンテンツ・タイミング情報を決定する仕方により本発明が限定されないことを、正しく理解するであろう。１つの実施形態では、たとえば、隙間決定回路５８は、たとえば、商業広告、シーン・カット、クレジット、または他の映像素材がマルチメディア・プログラムまたは映画フィルムすなわち映画に追加されている時間を自律的に識別することによるなどで、マルチメディア・ストリーム自身のコンテンツを解析する。代替の実施形態では、しかしながら、隙間決定回路５８は、対応するコンテンツ・プロバイダ２２から、マルチメディア・コンテンツにおける隙間の表示を受信する。そのようなタイミング情報が決定される仕方に係らず、したがって、ストリーミング・サーバ５０はそれにも係わらず、マルチメディア・コンテンツ・タイミング情報を移動端末４０に送る。
【００２０】
当業者はまた容易に、ネットワーク・インタフェース回路５２が、マルチメディア・セッションにおける任意時点でこのマルチメディア・コンテンツ・タイミング情報を送るように構成される場合があることを理解するであろう。しかしながら、ネットワーク・インタフェース回路５２が、ある隙間に対応するマルチメディア・コンテンツ・タイミング情報を、移動端末４０がかかる隙間を発見する前のある時点で送ると、移動端末４０は、その隙間中にアクセス配信における変更を開始するだけの場合がある。マルチメディア・ストリームのコンテンツがマルチメディア生番組を含む場合にそのようにするために、たとえば、ストリーミング・サーバ５０はさらに、遅延バッファ（図示されていない）を備える場合がある。マルチメディア・ストリームの送信を（たとえば、１秒間）遅らせることにより、遅延バッファは、ある隙間を示すマルチメディア・コンテンツ・タイミング情報が、移動端末４０がかかる隙間を発見する前に、送られるようにできる。しかも、マルチメディア・ストリームのコンテンツがマルチメディア生番組を含むかどうかに係らず、移動端末４０は、ネットワーク・インタフェース回路５２がマルチメディア・コンテンツ・タイミング情報を送るかどうか、そしていつ送るかを制御可能である。
【００２１】
１つの実施形態では、たとえば、ネットワーク・インタフェース回路５２は、１つ以上の移動端末の要求、たとえば移動端末４０の要求などに応答して、マルチメディア・コンテンツ・タイミング情報を送る。そのような要求は、移動端末４０へのユニキャスト配信中の任意の時点で移動端末４０によりなされる場合がある。ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法によって移動端末４０により要求される場合、たとえば、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報をＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答の本体内に含める。
【００２２】
代替の実施形態では、しかしながら、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報を、そのような情報が付加されていることを移動端末により知られているメッセージに付加することにより送るように構成される。ネットワーク・インタフェース回路５２は、たとえば、移動端末４０がブロードキャスト配信からユニキャストに変更する場合、自動的に（すなわち、ブロードキャストサービスエリアが利用できるようになることを予期して）マルチメディア・コンテンツ・タイミング情報を送る場合がある。この実施形態でユニキャスト配信がＲＴＳＰを用いて設定されると、ネットワーク・インタフェース回路５２は自動的に、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰ ＰＬＡＹ応答に付加する場合がある。あるいは、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージに付加する場合がある。他の例には、マルチメディア・コンテンツ・タイミング情報をＥＳＧに、または任意のＤＶＢ通知メッセージに付加することを含む。
【００２３】
勿論、本発明のストリーミング・サーバ５０は、マルチメディア・コンテンツ・タイミング情報を移動端末４０に送るために、一定のプロトコルを用いることに何ら限定されない。実際、ストリーミング・サーバ５０は、マルチメディア・コンテンツ・タイミング情報を、たとえば、ＲＴＳＰメッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットを利用して送る場合がある。
【００２４】
ストリーミング・サーバ５０の変形および実装の上記要点を考慮に入れて、当業者は、本発明のストリーミング・サーバ５０が広く、図３で説明されている方法を行うことを正しく理解するであろう。図３に従って、ネットワーク・インタフェース回路５２は、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０により、ユニキャスト配信およびブロードキャスト配信のためのマルチメディア・ストリームを、移動端末４０を含めて、１つ以上の移動端末に送る（ブロック１００）。かかるマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更する際に、それらの移動端末を補助するために、隙間決定回路５８は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定する（ブロック１１０）。ネットワーク・インタフェース回路５２はその後、そのようなマルチメディア・コンテンツ・タイミング情報を、ネットワーク３０からマルチメディア・ストリームを受信する、移動端末４０を含めて、１つ以上の移動端末に送る（ブロック１２０）。
【００２５】
加入者の視聴体験への中断を最小限にする時間でユニキャスト配信からブロードキャスト配信に変更するためにストリーミング・サーバ５０により送られるマルチメディア・コンテンツ・タイミング情報を利用するように、移動端末４０は、図４に従って構成される。図４で、移動端末４０は、受信機４２および１つ以上の処理回路４４を備える。
【００２６】
受信機４２は、移動端末４０をストリーミング・サーバ５０と通信できるように連結する。ストリーミング・サーバ５０と移動端末４０との間の通信は、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０によって生じるので、受信機４２は、ユニキャスト配信かブロードキャスト配信のどちらかによって、ストリーミング・サーバ５０からマルチメディア・ストリームを受信するように構成される。前述のように、たとえば、受信機４２は、ＥＳＧに挙げられている一定のＩＰポートへの地域参加が、それによってブロードキャスト配信による受信を容認できるように、構成される場合がある。アクセス配信に係らず、しかしながら、受信機４２は、今度は１つ以上の処理回路４４に通信できるように連結される。
【００２７】
１つ以上の処理回路４４は、上述のように、マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するように構成される。より詳しくは、１つ以上の処理回路４４はストリーミング・サーバ５０からマルチメディア・コンテンツ・タイミング情報を受信するように構成される。再度、このマルチメディア・コンテンツ・タイミング情報は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示し、そしてマルチメディア・プログラム間の合間、マルチメディア・プログラムと商業広告との間の合間、シーン・カット、クレジット、またはコンテンツにおける同様な合間を含む場合がある。１つ以上の処理回路４４はさらに、同じマルチメディア・ストリームがまた、ストリーミング・サーバ５０からブロードキャスト／マルチキャスト配信により利用できることを決定するように構成される。しかしながら、１つ以上の処理回路４４は、マルチメディア・ストリームが利用できるようになると直ぐに、ブロードキャスト配信への変更を必ずしも開始する必要はない。むしろ、１つ以上の処理回路４４は、前に受信したマルチメディア・コンテンツ・タイミング情報に基づいてアクセス変更を選択的に開始する。すなわち、１つ以上の処理回路４４は、隙間のうちの対応する１つの間に、マルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。１つ以上の処理回路４４は、たとえば、次にやってくる隙間中にブロードキャスト配信に変更する場合がある。マルチメディア・コンテンツにおける隙間中にユニキャスト配信からブロードキャスト配信に変更する際に、移動端末４０はそれにより、マルチメディア・コンテンツにおける、変更により引き起こされる可能性のある中断をいずれも最小限にする。さらに、これらの隙間がよく生じて、そのような変更が大して遅れることなく、そしてそのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【００２８】
図４で説明されている１つの実施形態では、移動端末４０はさらに、クライアント・アプリケーション・プログラム４７を格納するためのメモリ４６を備える。この実施形態では、１つ以上の処理回路４４は、クライアント・アプリケーション・プログラムを実行することによって上述のようにアクセス配信を変更し、それによってクライアント・アプリケーション４５を創り出すように構成される。クライアント・アプリケーション４５は、たとえば、移動端末４０における多くのアプリケーションの１つまたは、移動端末４０におけるそれらの多くのアプリケーションに利用できる共通の機能を提供する、アプリケーション領域に存在する高レベル論理を備える場合がある。とにかく、クライアント・アプリケーション４５は、通信する１つ以上のミドルウェアＡＰＩレイヤのサービス、たとえばマルチメディア・プレイヤなどを利用し、そしてサービス・レイヤ２０においてストリーミング・サーバ５０からのマルチメディア・ストリームの受信を達成する場合がある。さらに、上述のように、マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するために、１つの実施形態では、クライアント・アプリケーション４５は機能的に、配信受取コントローラ６２、配信選択タイミング・コントローラ６４、配信利用コントローラ６６、および配信選択コントローラ６８を備える。
【００２９】
配信受取コントローラ６２は、ストリーミング・サーバ５０から送られるマルチメディア・ストリームを、ユニキャスト・ベアラでユニキャスト配信により受信するように構成される。配信利用コントローラは、同じマルチメディア・ストリームがまた、ストリーミング・サーバ５０からブロードキャスト・ベアラでブロードキャスト配信により利用できることを決定するように構成されるけれども、移動端末４０は、ブロードキャスト配信が利用できるようになると直ぐに、必ずしもブロードキャスト配信に変更するとは限らない。むしろ、配信選択タイミング・コントローラ６４は、上述のようにストリーミング・サーバ５０により送られるマルチメディア・コンテンツ・タイミング情報を受信し、そして配信選択コントローラ６８は、そのようなタイミング情報に基づいてアクセス変更を選択的に開始する。したがって、配信選択コントローラ６８は、隙間のうちの対応する１つの間にマルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【００３０】
当業者は、ストリーミング・サーバ５０における上述の変形に伴う場合がある、移動端末４０での対応する変形を正しく理解するであろう。１つの実施形態では、たとえば、１つ以上の処理回路４４はさらに、マルチメディア・コンテンツ・タイミング情報をストリーミング・サーバ５０に要求するように構成される。そのような実施形態では、１つ以上の処理回路４４は、そのようなタイミング情報を要求するためにＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法を利用する場合がある。代替の実施形態では、１つ以上の処理回路４４は、マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号するように構成される。
【００３１】
１つ以上の処理回路４４は、たとえば、ＲＴＳＰ ＰＬＡＹ法に対するストリーミング・サーバ５０の応答を復号することによって、またはストリーミング・サーバ５０により送られるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを復号することにより、タイミング情報を受信する場合がある。他の例には、マルチメディア・コンテンツ・タイミング情報をＥＳＧにまたは任意のＤＶＢ通知メッセージに付加する工程を含む。しかも本発明の移動端末４０は、マルチメディア・コンテンツ・タイミング情報を受信するために、一定のプロトコルを用いることに何ら限定されない。実際、移動端末４０は、マルチメディア・コンテンツ・タイミング情報を、たとえば、ＲＴＳＰメッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットを復号することにより受信可能である。
【００３２】
他の変形が、しかしながら、移動端末４０の特定の実装を伴う場合がある。１つの実施形態では、１つ以上の処理回路４４は、マルチメディア・ストリームがまた、マルチメディア・コンテンツ・タイミング情報により示される隙間の直前の時間で、ブロードキャスト配信により利用できるかどうかを調べるだけである。すなわち、１つ以上の処理回路４４は、同じマルチメディア・ストリームがまた、隙間が生じる直前にブロードキャスト配信により利用できることを決定し、そしてかかる隙間中にユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【００３３】
さらに、いずれの隙間中にアクセス変更を選択的に開始すべきかについて、１つ以上の処理回路４４によりなされる決定がまた、（たとえば、アクセス配信タイプ間でのピンポン効果を防止するために、）より知的になされる場合がある。１つの実施形態では、たとえば、１つ以上の処理回路４４は、マルチメディア・ストリームがある最小限の期間にわたってユニキャスト配信により受信されていると、変更を開始することにより、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。１つの実施形態では、たとえば、１つ以上の処理回路４４は、ブロードキャスト配信からユニキャスト配信にごく最近変更されたアクセス配信を含めて、マルチメディア・ストリームに対するアクセス配信変更時間の履歴を維持する場合がある。この場合、１つ以上の処理回路４４は、このごく最近のアクセス配信変更時間以来、最小限の時間が過ぎていると、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する場合がある。特定の実装に係らず、しかしながら、この実施形態における１つ以上の処理回路４４は、アクセス配信タイプ間での潜在的なピンポン効果を防止する。
【００３４】
再度、移動端末４０の変形および実装の上記要点を考慮に入れて、当業者は、本発明の移動端末４０が広く、図５に説明されている方法を行うことを正しく理解するであろう。図５に従って、受信機４２は、マルチメディア・ストリームをユニキャスト・ベアラでユニキャスト配信により受信する（ブロック１３０）。移動端末４０が加入者の視聴体験への中断を最小限にする時間で、このユニキャスト配信からブロードキャスト配信に変更できるようにするために、１つ以上の処理回路４４は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する（ブロック１４０）。同じマルチメディア・ストリームがまた、ブロードキャスト・ベアラでブロードキャスト配信により利用できることを、１つ以上の処理回路４４が決定して（ブロック１５０）からの時点で、１つ以上の処理回路４４は、隙間のうちの対応する１つの隙間中にマルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する（ブロック１６０）。
【００３５】
図６Ａから図６Ｃまでの実施形態は、クライアント・アプリケーション４５によってアクセス配信を変更する１つ以上の処理回路４４に従って実装される移動端末４０の特定の例を説明している。特に、クライアント・アプリケーション４５は、移動体テレビ・マルチメディア・ストリームを受信するために上述したような方法を行うように構成される。図６Ａから図６Ｃまででは、クライアント・アプリケーション４５は、通信するミドルウェアＡＰＩレイヤのサービス、ＴＶプレーヤー７０およびＢＣ ＨＷ受信機７４を利用し、そしてストリーミング・サーバ５０からのマルチメディア・ストリームの受信を達成する。したがって、ＴＶプレーヤー７０は、クライアント・アプリケーション４５に、移動体テレビの受信およびレンダリングに関連するサービスだけでなく、ＩＰスタック７２によってストリーミング・サーバ５０との通信も提供する。ＩＰスタック７２は、マルチメディア・ストリームを搬送するためにＲＴＰ／ＵＤＰ／ＩＰを、そしてマルチメディア・ストリームを受信することに関連する制御メッセージを搬送するためにＲＴＳＰ／ＴＣＰ／ＩＰを用いて、ＩＰに基づく搬送を提供する。マルチメディア・ストリームをＩＰスタック７２に提供することに加えて、ＢＣ ＨＷ受信機は、クライアント・アプリケーション４５が信号強度表示ＡＰＩによってブロードキャスト配信の可用性の表示を受信できるようにする。移動端末４０のそのような典型的な実装が本発明を説明するのに有用であるが、当業者は、用いられる特定の実装が本発明を限定しないことを正しく理解するであろう。
【００３６】
次に図６Ａの呼フロー図を参照すると、クライアント・アプリケーション４５は、マルチメディア・コンテンツ・タイミング情報をストリーミング・サーバ５０にＲＴＳＰによって要求することにより、ＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する。特に、ＥＳＧに含まれるマルチメディア・コンテンツのリストが与えられると、加入者は、一定のマルチメディア・コンテンツを視聴することを選択する（工程１）。ＥＳＧはまた、ＲＴＳＰ ＵＲＩおよび、ユニキャスト配信とブロードキャスト配信との両方で選択されたマルチメディア・コンテンツに対応するマルチメディア・ストリームをどのように受信するかをクライアント・アプリケーション４５に説明する、ＢＣセッション記述プロトコル（ＳＤＰ）を含む。本明細書に基づいて、クライアント・アプリケーション４５は、マルチメディア・ストリームに対してＲＴＳＰ ＵＲＩおよびＢＣ ＳＤＰを用いてＴＶプレーヤー７０からＴＶセッションを創り出し（工程２）、そしてマルチメディア・トラック（たとえば、音響および映像）が描画されるように選ぶ（工程３）。クライアント・アプリケーション４５により選ばれたマルチメディア・トラックが与えられると、ＴＶプレーヤー７０は、ＲＴＳＰによって、ユニキャスト配信のためのセッションを設定する（工程４）だけでなく、ブロードキャスト配信のために並列セッションを設定する（工程５）。
【００３７】
ユニキャスト配信かブロードキャスト配信のいずれかによってマルチメディア・ストリームを受信するように決める際、クライアント・アプリケーション４５は、好適なブロードキャスト配信が利用できるかどうかを判定する。そうするために、クライアント・アプリケーション４５は、ＤＶＢ−Ｈに対する信号強度を調べるために、ＢＣ ＨＷ受信機７４からの信号強度ＡＰＩを用いる（工程６）。この例では、信号強度は一定のサービス品質に対する要件を満たし、そしてこのようにして、図６Ｂに示されているように、クライアント・アプリケーション４５は、ブロードキャスト配信によってマルチメディア・ストリームを受信するように要求する（工程７）。ＴＶプレーヤー７０が、ブロードキャスト配信のために、ＥＳＧに挙げられているＩＰポートに地域参加してから、ＴＶプレーヤー７０は、ブロードキャスト配信によってレンダリングのためのマルチメディア・ストリームを受信する（工程８）。
【００３８】
しばらくすると、しかしながら、クライアント・アプリケーション４５は、マルチメディア・ストリームの好適なブロードキャスト配信には、ＩＰパケット到着率が不十分であることを示す報告を受信する。ブロードキャストのサービスエリアを離れると、クライアント・アプリケーション４５は、ブロードキャスト配信からユニキャスト配信に変更するように決める（工程９）。したがって、クライアント・アプリケーション４５は、以前に設定したユニキャスト・セッションを用いてユニキャスト配信によってマルチメディア・ストリームを受信するように要求する（工程１０）。そのような変更を達成するために、ＴＶプレーヤー７０は、ブロードキャスト配信を終わらせ、そしてＲＴＳＰ ＰＬＡＹ法によってユニキャスト配信を開始する（工程１１）。ストリーミング・サーバ５０は、ＲＴＳＰ ＰＬＡＹ要求に応答（"ＯＫ"）を提供し、するとすぐに、ＴＶプレーヤー７０は、ユニキャスト配信によってレンダリングのためのマルチメディア・ストリームを受信する。
【００３９】
上述したように、しかしながら、クライアント・アプリケーション４５は、利用できるのであれば、ブロードキャスト配信によってマルチメディア・ストリームを受信し勝ちである。したがって、利用できるならば、その場合には、ブロードキャスト配信に変更することに備えて、クライアント・アプリケーション４５は、マルチメディア・コンテンツの加入者視聴での中断を最小限にする時間中にそのような変更を達成するために、マルチメディア・コンテンツ・タイミング情報（たとえば、切り替え時間のリスト）を要求する（工程１２）。切り替え時間のリストは、前述のように、マルチメディア・プログラム間の合間、マルチメディア・プログラムと商業広告との間の合間、シーン・カット、クレジット、またはコンテンツにおける同様な合間のような、マルチメディア・ストリームのコンテンツにおける隙間を備える。ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法を用いてＴＶプレーヤー７０によってなされる要求に応答して、ストリーミング・サーバ５０は、要求されたマルチメディア・コンテンツ・タイミング情報を提供する。
【００４０】
マルチメディア・コンテンツ・タイミング情報により示される（工程１３）隙間の直前に、クライアント・アプリケーション４５は、図６Ｃで示されているように、ＤＶＢ−Ｈに対する信号強度を調べることにより、好適なブロードキャスト配信が利用できるかどうかを判定する（工程１４）。この例では、信号強度は、ブロードキャスト配信のために一定のサービス品質に対する要件を満たす（工程１５）。クライアント・アプリケーション４５は、したがって、マルチメディア・コンテンツの加入者視聴で中断を最小限にするように隙間で好適なブロードキャスト配信への変更を選択的に開始する場合がある。そうするために、クライアント・アプリケーションは、ブロードキャスト配信によってマルチメディア・ストリームを受信するように要求し（工程１６）、するとすぐに、ＴＶプレーヤー７０は、マルチメディア・コンテンツ・タイミング情報に示されている隙間でブロードキャスト配信を用いるように変更する（工程１７）。
【００４１】
上記の例は、勿論、マルチメディア・コンテンツ・タイミング情報を、そのような情報が付加されていることを知られているメッセージを復号することにより、クライアント・アプリケーション４５が受信することを説明するように修正可能である。図６Ｂにおける上述の工程１０から工程１２までは、たとえば、図７で説明されている工程１０から工程１２までと置き換え可能である。図７では、ストリーミング・サーバ５０は、クライアント・アプリケーション４５のＲＴＳＰ ＰＬＡＹ要求に対する応答（"ＯＫ"）を送り（工程１０）、そして切り替え時間のリストをかかる応答に自動的に付加する（工程１１）。したがって、クライアント・アプリケーション４５は、切り替え時間のリストが付加されていることを知られているこの応答を復号する。この応答を復号することにより、切り替え時間のリストを既に受信していて、クライアント・アプリケーション４５は、図６Ｂで説明されている工程１２におけるように、リストを特に要求する必要がない。むしろ、クライアント・アプリケーション４５は、ユニキャスト配信によってマルチメディア・ストリームを単に受信可能である（工程１２）。
【００４２】
あるいは、図６Ｂにおける上述の工程１０から工程１２までは、図８に説明されている工程１０から工程１２までに置き換えられる場合がある。図８では、再度、クライアント・アプリケーション４５は、ユニキャスト配信によってマルチメディア・ストリームを受信するように要求し（工程１０）、そしてＴＶプレーヤー７０はそれに対応して、ＲＴＳＰ ＰＬＡＹ法によってユニキャスト配信を開始する（工程１１）。図７におけるように、切り替え時間のリストをＲＴＳＰ ＰＬＡＹ応答に自動的に付加する代わりに、しかしながら、ストリーミング・サーバ５０は、ＴＶプレーヤー７０が、ユニキャスト配信によってレンダリングのためにマルチメディア・ストリームを受信し始めてしばらく後に送られるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージに切り替え時間のリストを自動的に付加する（工程１２）。したがって、クライアント・アプリケーション４５は、切り替え時間のリストが追加されていることを知られている、このメッセージを復号する。
【００４３】
クライアント・アプリケーション４５が、図７および図８でマルチメディア・コンテンツ・タイミング情報を受信する仕方に係らず、けれども、クライアント・アプリケーション４５は、図６Ａから図６Ｃまでに関して説明したのと同じ仕方で、すなわち、マルチメディア・コンテンツ・タイミング情報内に示されている隙間に従って、アクセス配信の変更を開始する。
【００４４】
しかしながら、当然のことながら、前述の明細書および添付の図面は、本明細書で教示されている方法および個々の装置の限定されない例を表わしている。そのようなものとして、本発明は、前述の明細書および添付の図面により限定されない。その代わりに、本発明は、以下の特許請求の範囲およびそれらの法的均等論によってのみ限定される。
【技術分野】
【０００１】
本発明は広く、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおけるマルチメディア・ストリームのアクセス配信を変更するための方法および装置に関するものであり、詳しくはマルチメディア・ストリームのコンテンツにおける隙間（interstice）にユニキャスト配信からブロードキャスト配信に変更することに関する。
【背景技術】
【０００２】
移動体ネットワークでのマルチメディア・コンテンツ（たとえば、移動体テレビ）の配信に対する需要が増大しており、ブロードキャスト技術を用いてマルチメディア・コンテンツを配信する要請が強まってきている。ブロードキャスト技術は、より効率的なネットワーク利用を保証するブロードキャスト・ベアラ・サービス、たとえば、デジタル映像放送−ハンドヘルド（ＤＶＢ−Ｈ）およびマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）などの使用を伴う。加入者が同じ地域で同じマルチメディア・コンテンツを要求していても、各加入者に１つのリンクを消費する、ユニキャスト・ベアラ・サービス（たとえば、３Ｇでのパケット交換ストリーミング）とは違って、ブロードキャスト・ベアラ・サービスは、加入者がかかる同じマルチメディア・コンテンツに対して単一のリンクを共用することを可能にする。しかしながら、マルチメディア・コンテンツを要求する加入者の数が減少するにつれて、ブロードキャスト配信の効率も低下する。したがって、ネットワーク運用会社は、あるマルチメディア・コンテンツのブロードキャスト配信を、いつでもどこでも利用できるようにすることを拒否する場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークでは、ユニキャスト配信は、あるマルチメディア・ストリームに対するブロードキャストのサービスエリアが有効でない場所および時間に、ブロードキャスト配信を補完する。すなわち、移動端末は、あるマルチメディア・ストリームのブロードキャスト配信が利用できなくなる場合を検出し、そしてマルチメディア・ストリームに対してユニキャスト配信を用いるように変更する。そのような変更は、ブロードキャストのサービスエリアを欠くにも係らず、配信を可能にするが、移動端末は、ブロードキャストのサービスエリアが再度利用できるようになると、より効率的なブロードキャスト配信を用いるように戻るべきである。
【０００４】
移動端末がブロードキャスト配信を用いるように戻る時間は、しかしながら、ネットワーク利用の効率と加入者のマルチメディア体験の双方に影響する場合がある。ブロードキャストサービスエリアが安定しないうちに、移動端末がブロードキャスト配信を用いるように戻ると、たとえば、ユニキャスト配信とブロードキャスト配信との間でのピンポン効果が、重大なデータ損失および加入者のマルチメディア体験の中断をもたらす場合がある。他方、移動端末が、潜在的にかなりの量の時間（たとえば、加入者がマルチメディア・チャネルを変更するまで）変更を遅らせることにより、この中断を回避すると、ネットワーク利用が著しくより非効率になる。
【課題を解決するための手段】
【０００５】
本明細書で教示される方法および装置は、ネットワーク・リソースを効率的に利用するとともに、ユーザのマルチメディア体験における中断を最小限にしながら、移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するのを、都合よく可能にする。ブロードキャスト配信が利用できるようになると直ぐにそのような変更を開始する代わりに、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報に従って移動端末が変更を開始する。そのような隙間中での変更に起因するデータ損失はいずれも、加入者のマルチメディア体験にわずかしか影響を与えない。さらに、隙間がよく生じて、そのような変更が大して遅れることなく、そしてこのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【０００６】
より詳しくは、移動端末が、ユニキャスト・ベアラでユニキャスト配信によるマルチメディア・ストリームだけでなく、かかるマルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する。マルチメディア・ストリームのコンテンツが、１つ以上のマルチメディア・プログラムおよび１つ以上の商業広告を備えると、たとえば、そのようなコンテンツにおける隙間が、各マルチメディア・プログラム（たとえば、商業広告）間の合間（breaks）、またはマルチメディア・プログラムと商業広告との間の合間を含む場合がある。あるいは、マルチメディア・ストリームのコンテンツは、映画フィルムすなわち映画を備える場合があり、そしてそのようなコンテンツにおける隙間がその中に１つ以上のシーン・カットを含む場合がある。したがって、移動端末はその後、同じマルチメディア・ストリームがブロードキャスト・ベアラでブロードキャスト配信により利用できるようになるのを決定するけれども、移動端末は、マルチメディア・コンテンツ・タイミング情報に示された隙間中に、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【０００７】
そのような変更を補助するために、マルチメディア・ストリームを移動端末に送るストリーミング・サーバが、このマルチメディア・コンテンツ・タイミング情報を決定する。ストリーミング・サーバは、たとえば、マルチメディア・ストリームのコンテンツ自身を、たとえば、商業広告または他の映像素材がマルチメディア・プログラムに追加されている時間を自律的に識別することによるなどで、解析する場合がある。あるいは、ストリーミング・サーバは、マルチメディア・コンテンツにおける隙間の表示を、対応するコンテンツ・プロバイダから受信する場合がある。いずれにしても、ストリーミング・サーバは、このマルチメディア・コンテンツ・タイミング情報を移動端末に送る。ストリーミング・サーバは、たとえば、移動端末の要求に応答して、またはそのような情報が付加されていることを移動端末により知られているメッセージにそのような情報を付加することによって、そのような情報を送る。勿論、本発明は上記の特徴および利点に限定されない。実際、当業者は、以下の詳細な明細書を読むと、そして添付図面を見ると、さらなる特徴および利点を認めるであろう。
【図面の簡単な説明】
【０００８】
【図１】図１は、本発明が用いられる場合があるマルチメディア・システムのブロック図である。
【図２】図２は、本発明のストリーミング・サーバの１つの実施形態を説明するブロック図である。
【図３】図３は、移動端末がアクセス配信をユニキャスト配信からブロードキャスト配信に変更するのを補助するための、ストリーミング・サーバにおける方法の論理フロー図である。
【図４】図４は、本発明の移動端末の１つの実施形態を説明するブロック図である。
【図５】図５は、アクセス配信をユニキャスト配信からブロードキャスト配信に変更するための、移動端末における方法の論理フロー図である。
【図６Ａ】、
【図６Ｂ】、
【図６Ｃ】図６Ａから図６Ｃまでは、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰによってストリーミング・サーバに要求することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図である。
【図７】図７は、マルチメディア・コンテンツ・タイミング情報が追加されることを知られている、ストリーミング・サーバのＲＴＳＰ ＰＬＡＹ応答を復号することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図の一部である。
【図８】図８は、マルチメディア・コンテンツ・タイミング情報が追加されることを知られている、ストリーミング・サーバのＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを復号することで、移動端末がＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する手順を説明する呼フロー図の一部である。
【発明を実施するための形態】
【０００９】
図１は、本発明が採用される場合があるマルチメディア・システム１０を説明している。マルチメディア・システム１０は、サービス・レイヤ２０および、移動端末４０にマルチメディア・ストリームを配信するためのハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０を備える。
【００１０】
マルチメディア・ストリームをそのような配信に利用できるようにするために、サービス・レイヤ２０は、１つ以上のコンテンツ・プロバイダ２２、ＩＰネットワーク２４およびストリーミング・サーバ５０を備える。１つ以上のコンテンツ・プロバイダ２２は各々、マルチメディア・コンテンツ、たとえば、移動体テレビのための音響／映像プログラムおよび商業広告または映画フィルムすなわち映画などを準備する。移動端末４０にストリーミングするためにマルチメディア・コンテンツを適切なフォーマットに符号化してから、各コンテンツ・プロバイダ２２は、このコンテンツをＩＰネットワーク２４によって、ストリーミング・サーバ５０に送る。
【００１１】
ストリーミング・サーバ５０は、１つ以上のコンテンツ・プロバイダ２２から送られるコンテンツに対する多くのマルチメディア・ストリームを構築する。各マルチメディア・ストリームは、他のマルチメディア・ストリームと異なるコンテンツを有し、移動端末４０に、あるマルチメディア・コンテンツを受信するために、いずれのマルチメディア・ストリームを受信するべきかを知るように求める。このようにして、サービス・レイヤ２０は、各コンテンツ・プロバイダ２２から送られるコンテンツに関する情報を電子サービス・ガイド（ＥＳＧ）に集約しており、ＥＳＧは、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０で配信される、あるマルチメディア・ストリームによって、あるマルチメディア・コンテンツをどのように受信するかを移動端末４０に説明する。
【００１２】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０には、ストリーミング・サーバ５０により提供されるマルチメディア・ストリームのブロードキャスト配信に用いられるブロードキャスト配信リソース３４（たとえば、ブロードキャスト・ベアラ・サービス）がある。ブロードキャスト・ベアラ・サービスの例には、たとえば、デジタル映像放送−ハンドヘルド（ＤＶＢ−Ｈ）およびマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）がある。特定のブロードキャスト・ベアラ・サービスに係らず、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０は、かかるマルチメディア・ストリームのコンテンツの人気によっては、特定のマルチメディア・ストリームをブロードキャスト配信によって提供可能である。そうであると、ブロードキャスト配信によってかかるマルチメディア・ストリームを受信するために、移動端末４０は、ＥＳＧの説明に従ってブロードキャスト・ベアラ・サービスに同調する。ＤＶＢ−Ｈが利用される場合、たとえば、移動端末４０は、ストリーミング・サーバ５０がマルチメディア・ストリームをプッシュ配信するＩＰポートであるとしてＥＳＧに挙げられている、あるＩＰポートにローカル参加する。
【００１３】
マルチメディア・ストリームのブロードキャスト配信は、しかしながら、ある時間に、ある地域でのブロードキャストサービスエリアを欠くために、利用できなくなる場合がある（たとえば、ＤＶＢ−Ｈが利用されていると、信号強度が、一定のサービス品質には不十分である場合がある）。したがって、ＥＳＧはまた、ブロードキャスト配信が利用できなくなるような場合に、かかるマルチメディア・ストリームをユニキャスト配信によってどのように受信するかを、移動端末４０に説明する。ユニキャスト配信のために、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０には、ユニキャスト配信リソース３２（たとえば、ユニキャスト・ベアラ・サービス）がある。ユニキャスト・ベアラ・サービスの例には、たとえば、３Ｇでのパケット交換ストリーミングまたは汎用移動体通信システム（ＧＳＭ）がある。ユニキャスト配信によってマルチメディア・ストリームを受信するように変更を開始するために、移動端末４０は、ブロードキャスト配信によってマルチメディア・ストリームを受信するのを停止し、そしてストリーミング・サーバ５０からのマルチメディア・ストリームのユニキャスト・フローを開始するのに、ＥＳＧにおけるＵＲＩにより識別されるように、アプリケーション・レベル・プロトコルを利用する。実時間ストリーミング・プロトコル（ＲＴＳＰ）は、たとえば、このようにストリーミング・サーバ５０を制御するために用いられる場合がある。
【００１４】
しかしながら、マルチメディア・ストリームのユニキャスト配信は、マルチメディア・ストリームのブロードキャスト配信よりも効率を下げてネットワーク・リソースを利用するので、移動端末４０は、ブロードキャスト配信が再び利用できるようになると、ブロードキャスト配信を用いるように戻す変更を選択的に開始する。けれども、移動端末４０がこのアクセス変更を開始する特定の時間は、ブロードキャスト配信の可用性ばかりでなく、そのような変更がマルチメディア・ストリームのコンテンツの加入者視聴に及ぼす恐れのある影響にも依存する。
【００１５】
加入者の視聴体験の中断を最小にする時間で、移動端末４０がユニキャスト配信からブロードキャスト配信に変更するのを支援するために、ストリーミング・サーバ５０は図２に従って構成される。図２では、ストリーミング・サーバ５０は、ネットワーク・インタフェース回路５２および、ストリーム処理回路５６および隙間決定回路５８を含む、１つ以上の処理回路５４を備える。ストリーム処理回路５６は、ネットワーク・インタフェース回路５２により、移動端末４０を含めて１つ以上の移動端末にマルチメディア・ストリームを送るためにマルチメディア・ストリームを構築し、そして管理するように構成される。たとえば、ストリーム処理回路５６は、マルチメディア・ストリームのユニキャスト配信を開始するために、上記のプロトコル、たとえばＲＴＳＰなどに従って、マルチメディア・ストリームを管理する場合がある。
【００１６】
ストリーミング・サーバ５０は、しかしながら、隙間決定回路５８により決定され、そしてネットワーク・インタフェース回路５２により移動端末４０に送られるマルチメディア・コンテンツ・タイミング情報に従って、移動端末４０がユニキャスト配信から変更するのを支援する。そのようなマルチメディア・コンテンツ・タイミング情報は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示す。そのようなマルチメディア・コンテンツ・タイミング情報を移動端末４０に提供する際、ストリーミング・サーバ５０は、移動端末４０がマルチメディア・コンテンツにおける隙間中にユニキャスト配信からブロードキャスト配信への変更を選択的に開始できるようにし、そしてそれによって、変更により引き起こされるマルチメディア・コンテンツにおけるどのような中断も最小限にする。さらに、隙間がよく生じて、そのような変更が大して遅れることなく、そしてこのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【００１７】
１つの実施形態では、たとえば、マルチメディア・ストリームのコンテンツは、１つ以上のマルチメディア・プログラムおよび１つ以上の商業広告を含む。この場合、そのようなコンテンツにおける隙間は、マルチメディア・プログラムと商業広告との間に存在する切れ目の時点を含むことがある。あるいは、隙間には、マルチメディア・プログラム間の切れ目が、たとえば商業広告中などに存在する時間間隔を含む場合がある。注目すべきは、しかしながら、ユニキャストで配信されるマルチメディア・ストリームの商業広告は、移動端末４０に個別化されており、したがって、同じ時間中にブロードキャストで配信されるマルチメディア・ストリームの商業広告とは異なる場合がある。隙間決定回路５８は、したがって、マルチメディア・コンテンツ・タイミング情報において、マルチメディア・ストリームのコンテンツがユニキャストとブロードキャストとの双方で同じである隙間のみ（すなわち、その間のアクセス配信変更が適切であろう隙間のみ）を示すように構成される場合がある。隙間決定回路５８は、代替の方法では、マルチメディア・ストリームのコンテンツにおけるすべての隙間を示すように、しかしある隙間（たとえば、その間のコンテンツがユニキャストとブロードキャストとの双方で同じでないような隙間）中にアクセス配信変更が禁止されることをまた示すように構成される場合がある。本発明は、しかしながら、マルチメディア・ストリームの特定のコンテンツに限定されない。
【００１８】
他の実施形態では、たとえば、マルチメディア・ストリームのコンテンツがそのなかにシーン・カットを含めて、映画フィルムすなわち映画を含むことを考慮している。この例では、そのようなコンテンツにおける隙間には、映画フィルムすなわち映画にあるシーン・カットの時点を含む。そのようなコンテンツにおける隙間はまた、映画クレジットなどが存在する時間間隔を含む場合がある。当業者は、したがって、そのような隙間の正確な特質が本発明を限定しないこと、そして隙間にはまたマルチメディア・ストリームのコンテンツにおける類似したどのような合間をも含む場合があることを十分理解するであろう。さらに、当業者は、隙間が様々なフォーマット、たとえば標準再生時間（Normal Play Time）（ｎｐｔ）、絶対時間（ａｂｓ）で、またはネットワーク時間プロトコル（ＮＴＰ）に従って、示される場合があることを正しく理解するであろう。
【００１９】
当業者はまた容易に、隙間決定回路５８がマルチメディア・コンテンツ・タイミング情報を決定する仕方により本発明が限定されないことを、正しく理解するであろう。１つの実施形態では、たとえば、隙間決定回路５８は、たとえば、商業広告、シーン・カット、クレジット、または他の映像素材がマルチメディア・プログラムまたは映画フィルムすなわち映画に追加されている時間を自律的に識別することによるなどで、マルチメディア・ストリーム自身のコンテンツを解析する。代替の実施形態では、しかしながら、隙間決定回路５８は、対応するコンテンツ・プロバイダ２２から、マルチメディア・コンテンツにおける隙間の表示を受信する。そのようなタイミング情報が決定される仕方に係らず、したがって、ストリーミング・サーバ５０はそれにも係わらず、マルチメディア・コンテンツ・タイミング情報を移動端末４０に送る。
【００２０】
当業者はまた容易に、ネットワーク・インタフェース回路５２が、マルチメディア・セッションにおける任意時点でこのマルチメディア・コンテンツ・タイミング情報を送るように構成される場合があることを理解するであろう。しかしながら、ネットワーク・インタフェース回路５２が、ある隙間に対応するマルチメディア・コンテンツ・タイミング情報を、移動端末４０がかかる隙間を発見する前のある時点で送ると、移動端末４０は、その隙間中にアクセス配信における変更を開始するだけの場合がある。マルチメディア・ストリームのコンテンツがマルチメディア生番組を含む場合にそのようにするために、たとえば、ストリーミング・サーバ５０はさらに、遅延バッファ（図示されていない）を備える場合がある。マルチメディア・ストリームの送信を（たとえば、１秒間）遅らせることにより、遅延バッファは、ある隙間を示すマルチメディア・コンテンツ・タイミング情報が、移動端末４０がかかる隙間を発見する前に、送られるようにできる。しかも、マルチメディア・ストリームのコンテンツがマルチメディア生番組を含むかどうかに係らず、移動端末４０は、ネットワーク・インタフェース回路５２がマルチメディア・コンテンツ・タイミング情報を送るかどうか、そしていつ送るかを制御可能である。
【００２１】
１つの実施形態では、たとえば、ネットワーク・インタフェース回路５２は、１つ以上の移動端末の要求、たとえば移動端末４０の要求などに応答して、マルチメディア・コンテンツ・タイミング情報を送る。そのような要求は、移動端末４０へのユニキャスト配信中の任意の時点で移動端末４０によりなされる場合がある。ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法によって移動端末４０により要求される場合、たとえば、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報をＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答の本体内に含める。
【００２２】
代替の実施形態では、しかしながら、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報を、そのような情報が付加されていることを移動端末により知られているメッセージに付加することにより送るように構成される。ネットワーク・インタフェース回路５２は、たとえば、移動端末４０がブロードキャスト配信からユニキャストに変更する場合、自動的に（すなわち、ブロードキャストサービスエリアが利用できるようになることを予期して）マルチメディア・コンテンツ・タイミング情報を送る場合がある。この実施形態でユニキャスト配信がＲＴＳＰを用いて設定されると、ネットワーク・インタフェース回路５２は自動的に、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰ ＰＬＡＹ応答に付加する場合がある。あるいは、ネットワーク・インタフェース回路５２は、マルチメディア・コンテンツ・タイミング情報をＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージに付加する場合がある。他の例には、マルチメディア・コンテンツ・タイミング情報をＥＳＧに、または任意のＤＶＢ通知メッセージに付加することを含む。
【００２３】
勿論、本発明のストリーミング・サーバ５０は、マルチメディア・コンテンツ・タイミング情報を移動端末４０に送るために、一定のプロトコルを用いることに何ら限定されない。実際、ストリーミング・サーバ５０は、マルチメディア・コンテンツ・タイミング情報を、たとえば、ＲＴＳＰメッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットを利用して送る場合がある。
【００２４】
ストリーミング・サーバ５０の変形および実装の上記要点を考慮に入れて、当業者は、本発明のストリーミング・サーバ５０が広く、図３で説明されている方法を行うことを正しく理解するであろう。図３に従って、ネットワーク・インタフェース回路５２は、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０により、ユニキャスト配信およびブロードキャスト配信のためのマルチメディア・ストリームを、移動端末４０を含めて、１つ以上の移動端末に送る（ブロック１００）。かかるマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更する際に、それらの移動端末を補助するために、隙間決定回路５８は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定する（ブロック１１０）。ネットワーク・インタフェース回路５２はその後、そのようなマルチメディア・コンテンツ・タイミング情報を、ネットワーク３０からマルチメディア・ストリームを受信する、移動端末４０を含めて、１つ以上の移動端末に送る（ブロック１２０）。
【００２５】
加入者の視聴体験への中断を最小限にする時間でユニキャスト配信からブロードキャスト配信に変更するためにストリーミング・サーバ５０により送られるマルチメディア・コンテンツ・タイミング情報を利用するように、移動端末４０は、図４に従って構成される。図４で、移動端末４０は、受信機４２および１つ以上の処理回路４４を備える。
【００２６】
受信機４２は、移動端末４０をストリーミング・サーバ５０と通信できるように連結する。ストリーミング・サーバ５０と移動端末４０との間の通信は、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワーク３０によって生じるので、受信機４２は、ユニキャスト配信かブロードキャスト配信のどちらかによって、ストリーミング・サーバ５０からマルチメディア・ストリームを受信するように構成される。前述のように、たとえば、受信機４２は、ＥＳＧに挙げられている一定のＩＰポートへの地域参加が、それによってブロードキャスト配信による受信を容認できるように、構成される場合がある。アクセス配信に係らず、しかしながら、受信機４２は、今度は１つ以上の処理回路４４に通信できるように連結される。
【００２７】
１つ以上の処理回路４４は、上述のように、マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するように構成される。より詳しくは、１つ以上の処理回路４４はストリーミング・サーバ５０からマルチメディア・コンテンツ・タイミング情報を受信するように構成される。再度、このマルチメディア・コンテンツ・タイミング情報は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示し、そしてマルチメディア・プログラム間の合間、マルチメディア・プログラムと商業広告との間の合間、シーン・カット、クレジット、またはコンテンツにおける同様な合間を含む場合がある。１つ以上の処理回路４４はさらに、同じマルチメディア・ストリームがまた、ストリーミング・サーバ５０からブロードキャスト／マルチキャスト配信により利用できることを決定するように構成される。しかしながら、１つ以上の処理回路４４は、マルチメディア・ストリームが利用できるようになると直ぐに、ブロードキャスト配信への変更を必ずしも開始する必要はない。むしろ、１つ以上の処理回路４４は、前に受信したマルチメディア・コンテンツ・タイミング情報に基づいてアクセス変更を選択的に開始する。すなわち、１つ以上の処理回路４４は、隙間のうちの対応する１つの間に、マルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。１つ以上の処理回路４４は、たとえば、次にやってくる隙間中にブロードキャスト配信に変更する場合がある。マルチメディア・コンテンツにおける隙間中にユニキャスト配信からブロードキャスト配信に変更する際に、移動端末４０はそれにより、マルチメディア・コンテンツにおける、変更により引き起こされる可能性のある中断をいずれも最小限にする。さらに、これらの隙間がよく生じて、そのような変更が大して遅れることなく、そしてそのようにして、ブロードキャスト配信の使用により実現されるネットワーク利用効率の増加も遅れないであろうことを保証する。
【００２８】
図４で説明されている１つの実施形態では、移動端末４０はさらに、クライアント・アプリケーション・プログラム４７を格納するためのメモリ４６を備える。この実施形態では、１つ以上の処理回路４４は、クライアント・アプリケーション・プログラムを実行することによって上述のようにアクセス配信を変更し、それによってクライアント・アプリケーション４５を創り出すように構成される。クライアント・アプリケーション４５は、たとえば、移動端末４０における多くのアプリケーションの１つまたは、移動端末４０におけるそれらの多くのアプリケーションに利用できる共通の機能を提供する、アプリケーション領域に存在する高レベル論理を備える場合がある。とにかく、クライアント・アプリケーション４５は、通信する１つ以上のミドルウェアＡＰＩレイヤのサービス、たとえばマルチメディア・プレイヤなどを利用し、そしてサービス・レイヤ２０においてストリーミング・サーバ５０からのマルチメディア・ストリームの受信を達成する場合がある。さらに、上述のように、マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト配信に変更するために、１つの実施形態では、クライアント・アプリケーション４５は機能的に、配信受取コントローラ６２、配信選択タイミング・コントローラ６４、配信利用コントローラ６６、および配信選択コントローラ６８を備える。
【００２９】
配信受取コントローラ６２は、ストリーミング・サーバ５０から送られるマルチメディア・ストリームを、ユニキャスト・ベアラでユニキャスト配信により受信するように構成される。配信利用コントローラは、同じマルチメディア・ストリームがまた、ストリーミング・サーバ５０からブロードキャスト・ベアラでブロードキャスト配信により利用できることを決定するように構成されるけれども、移動端末４０は、ブロードキャスト配信が利用できるようになると直ぐに、必ずしもブロードキャスト配信に変更するとは限らない。むしろ、配信選択タイミング・コントローラ６４は、上述のようにストリーミング・サーバ５０により送られるマルチメディア・コンテンツ・タイミング情報を受信し、そして配信選択コントローラ６８は、そのようなタイミング情報に基づいてアクセス変更を選択的に開始する。したがって、配信選択コントローラ６８は、隙間のうちの対応する１つの間にマルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【００３０】
当業者は、ストリーミング・サーバ５０における上述の変形に伴う場合がある、移動端末４０での対応する変形を正しく理解するであろう。１つの実施形態では、たとえば、１つ以上の処理回路４４はさらに、マルチメディア・コンテンツ・タイミング情報をストリーミング・サーバ５０に要求するように構成される。そのような実施形態では、１つ以上の処理回路４４は、そのようなタイミング情報を要求するためにＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法を利用する場合がある。代替の実施形態では、１つ以上の処理回路４４は、マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号するように構成される。
【００３１】
１つ以上の処理回路４４は、たとえば、ＲＴＳＰ ＰＬＡＹ法に対するストリーミング・サーバ５０の応答を復号することによって、またはストリーミング・サーバ５０により送られるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを復号することにより、タイミング情報を受信する場合がある。他の例には、マルチメディア・コンテンツ・タイミング情報をＥＳＧにまたは任意のＤＶＢ通知メッセージに付加する工程を含む。しかも本発明の移動端末４０は、マルチメディア・コンテンツ・タイミング情報を受信するために、一定のプロトコルを用いることに何ら限定されない。実際、移動端末４０は、マルチメディア・コンテンツ・タイミング情報を、たとえば、ＲＴＳＰメッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットを復号することにより受信可能である。
【００３２】
他の変形が、しかしながら、移動端末４０の特定の実装を伴う場合がある。１つの実施形態では、１つ以上の処理回路４４は、マルチメディア・ストリームがまた、マルチメディア・コンテンツ・タイミング情報により示される隙間の直前の時間で、ブロードキャスト配信により利用できるかどうかを調べるだけである。すなわち、１つ以上の処理回路４４は、同じマルチメディア・ストリームがまた、隙間が生じる直前にブロードキャスト配信により利用できることを決定し、そしてかかる隙間中にユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。
【００３３】
さらに、いずれの隙間中にアクセス変更を選択的に開始すべきかについて、１つ以上の処理回路４４によりなされる決定がまた、（たとえば、アクセス配信タイプ間でのピンポン効果を防止するために、）より知的になされる場合がある。１つの実施形態では、たとえば、１つ以上の処理回路４４は、マルチメディア・ストリームがある最小限の期間にわたってユニキャスト配信により受信されていると、変更を開始することにより、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する。１つの実施形態では、たとえば、１つ以上の処理回路４４は、ブロードキャスト配信からユニキャスト配信にごく最近変更されたアクセス配信を含めて、マルチメディア・ストリームに対するアクセス配信変更時間の履歴を維持する場合がある。この場合、１つ以上の処理回路４４は、このごく最近のアクセス配信変更時間以来、最小限の時間が過ぎていると、ユニキャスト配信からブロードキャスト配信への変更を選択的に開始する場合がある。特定の実装に係らず、しかしながら、この実施形態における１つ以上の処理回路４４は、アクセス配信タイプ間での潜在的なピンポン効果を防止する。
【００３４】
再度、移動端末４０の変形および実装の上記要点を考慮に入れて、当業者は、本発明の移動端末４０が広く、図５に説明されている方法を行うことを正しく理解するであろう。図５に従って、受信機４２は、マルチメディア・ストリームをユニキャスト・ベアラでユニキャスト配信により受信する（ブロック１３０）。移動端末４０が加入者の視聴体験への中断を最小限にする時間で、このユニキャスト配信からブロードキャスト配信に変更できるようにするために、１つ以上の処理回路４４は、マルチメディア・ストリームのコンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する（ブロック１４０）。同じマルチメディア・ストリームがまた、ブロードキャスト・ベアラでブロードキャスト配信により利用できることを、１つ以上の処理回路４４が決定して（ブロック１５０）からの時点で、１つ以上の処理回路４４は、隙間のうちの対応する１つの隙間中にマルチメディア・ストリームのユニキャスト配信からブロードキャスト配信への変更を選択的に開始する（ブロック１６０）。
【００３５】
図６Ａから図６Ｃまでの実施形態は、クライアント・アプリケーション４５によってアクセス配信を変更する１つ以上の処理回路４４に従って実装される移動端末４０の特定の例を説明している。特に、クライアント・アプリケーション４５は、移動体テレビ・マルチメディア・ストリームを受信するために上述したような方法を行うように構成される。図６Ａから図６Ｃまででは、クライアント・アプリケーション４５は、通信するミドルウェアＡＰＩレイヤのサービス、ＴＶプレーヤー７０およびＢＣ ＨＷ受信機７４を利用し、そしてストリーミング・サーバ５０からのマルチメディア・ストリームの受信を達成する。したがって、ＴＶプレーヤー７０は、クライアント・アプリケーション４５に、移動体テレビの受信およびレンダリングに関連するサービスだけでなく、ＩＰスタック７２によってストリーミング・サーバ５０との通信も提供する。ＩＰスタック７２は、マルチメディア・ストリームを搬送するためにＲＴＰ／ＵＤＰ／ＩＰを、そしてマルチメディア・ストリームを受信することに関連する制御メッセージを搬送するためにＲＴＳＰ／ＴＣＰ／ＩＰを用いて、ＩＰに基づく搬送を提供する。マルチメディア・ストリームをＩＰスタック７２に提供することに加えて、ＢＣ ＨＷ受信機は、クライアント・アプリケーション４５が信号強度表示ＡＰＩによってブロードキャスト配信の可用性の表示を受信できるようにする。移動端末４０のそのような典型的な実装が本発明を説明するのに有用であるが、当業者は、用いられる特定の実装が本発明を限定しないことを正しく理解するであろう。
【００３６】
次に図６Ａの呼フロー図を参照すると、クライアント・アプリケーション４５は、マルチメディア・コンテンツ・タイミング情報をストリーミング・サーバ５０にＲＴＳＰによって要求することにより、ＤＶＢ−Ｈでユニキャスト配信からブロードキャスト配信に変更する。特に、ＥＳＧに含まれるマルチメディア・コンテンツのリストが与えられると、加入者は、一定のマルチメディア・コンテンツを視聴することを選択する（工程１）。ＥＳＧはまた、ＲＴＳＰ ＵＲＩおよび、ユニキャスト配信とブロードキャスト配信との両方で選択されたマルチメディア・コンテンツに対応するマルチメディア・ストリームをどのように受信するかをクライアント・アプリケーション４５に説明する、ＢＣセッション記述プロトコル（ＳＤＰ）を含む。本明細書に基づいて、クライアント・アプリケーション４５は、マルチメディア・ストリームに対してＲＴＳＰ ＵＲＩおよびＢＣ ＳＤＰを用いてＴＶプレーヤー７０からＴＶセッションを創り出し（工程２）、そしてマルチメディア・トラック（たとえば、音響および映像）が描画されるように選ぶ（工程３）。クライアント・アプリケーション４５により選ばれたマルチメディア・トラックが与えられると、ＴＶプレーヤー７０は、ＲＴＳＰによって、ユニキャスト配信のためのセッションを設定する（工程４）だけでなく、ブロードキャスト配信のために並列セッションを設定する（工程５）。
【００３７】
ユニキャスト配信かブロードキャスト配信のいずれかによってマルチメディア・ストリームを受信するように決める際、クライアント・アプリケーション４５は、好適なブロードキャスト配信が利用できるかどうかを判定する。そうするために、クライアント・アプリケーション４５は、ＤＶＢ−Ｈに対する信号強度を調べるために、ＢＣ ＨＷ受信機７４からの信号強度ＡＰＩを用いる（工程６）。この例では、信号強度は一定のサービス品質に対する要件を満たし、そしてこのようにして、図６Ｂに示されているように、クライアント・アプリケーション４５は、ブロードキャスト配信によってマルチメディア・ストリームを受信するように要求する（工程７）。ＴＶプレーヤー７０が、ブロードキャスト配信のために、ＥＳＧに挙げられているＩＰポートに地域参加してから、ＴＶプレーヤー７０は、ブロードキャスト配信によってレンダリングのためのマルチメディア・ストリームを受信する（工程８）。
【００３８】
しばらくすると、しかしながら、クライアント・アプリケーション４５は、マルチメディア・ストリームの好適なブロードキャスト配信には、ＩＰパケット到着率が不十分であることを示す報告を受信する。ブロードキャストのサービスエリアを離れると、クライアント・アプリケーション４５は、ブロードキャスト配信からユニキャスト配信に変更するように決める（工程９）。したがって、クライアント・アプリケーション４５は、以前に設定したユニキャスト・セッションを用いてユニキャスト配信によってマルチメディア・ストリームを受信するように要求する（工程１０）。そのような変更を達成するために、ＴＶプレーヤー７０は、ブロードキャスト配信を終わらせ、そしてＲＴＳＰ ＰＬＡＹ法によってユニキャスト配信を開始する（工程１１）。ストリーミング・サーバ５０は、ＲＴＳＰ ＰＬＡＹ要求に応答（"ＯＫ"）を提供し、するとすぐに、ＴＶプレーヤー７０は、ユニキャスト配信によってレンダリングのためのマルチメディア・ストリームを受信する。
【００３９】
上述したように、しかしながら、クライアント・アプリケーション４５は、利用できるのであれば、ブロードキャスト配信によってマルチメディア・ストリームを受信し勝ちである。したがって、利用できるならば、その場合には、ブロードキャスト配信に変更することに備えて、クライアント・アプリケーション４５は、マルチメディア・コンテンツの加入者視聴での中断を最小限にする時間中にそのような変更を達成するために、マルチメディア・コンテンツ・タイミング情報（たとえば、切り替え時間のリスト）を要求する（工程１２）。切り替え時間のリストは、前述のように、マルチメディア・プログラム間の合間、マルチメディア・プログラムと商業広告との間の合間、シーン・カット、クレジット、またはコンテンツにおける同様な合間のような、マルチメディア・ストリームのコンテンツにおける隙間を備える。ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ法を用いてＴＶプレーヤー７０によってなされる要求に応答して、ストリーミング・サーバ５０は、要求されたマルチメディア・コンテンツ・タイミング情報を提供する。
【００４０】
マルチメディア・コンテンツ・タイミング情報により示される（工程１３）隙間の直前に、クライアント・アプリケーション４５は、図６Ｃで示されているように、ＤＶＢ−Ｈに対する信号強度を調べることにより、好適なブロードキャスト配信が利用できるかどうかを判定する（工程１４）。この例では、信号強度は、ブロードキャスト配信のために一定のサービス品質に対する要件を満たす（工程１５）。クライアント・アプリケーション４５は、したがって、マルチメディア・コンテンツの加入者視聴で中断を最小限にするように隙間で好適なブロードキャスト配信への変更を選択的に開始する場合がある。そうするために、クライアント・アプリケーションは、ブロードキャスト配信によってマルチメディア・ストリームを受信するように要求し（工程１６）、するとすぐに、ＴＶプレーヤー７０は、マルチメディア・コンテンツ・タイミング情報に示されている隙間でブロードキャスト配信を用いるように変更する（工程１７）。
【００４１】
上記の例は、勿論、マルチメディア・コンテンツ・タイミング情報を、そのような情報が付加されていることを知られているメッセージを復号することにより、クライアント・アプリケーション４５が受信することを説明するように修正可能である。図６Ｂにおける上述の工程１０から工程１２までは、たとえば、図７で説明されている工程１０から工程１２までと置き換え可能である。図７では、ストリーミング・サーバ５０は、クライアント・アプリケーション４５のＲＴＳＰ ＰＬＡＹ要求に対する応答（"ＯＫ"）を送り（工程１０）、そして切り替え時間のリストをかかる応答に自動的に付加する（工程１１）。したがって、クライアント・アプリケーション４５は、切り替え時間のリストが付加されていることを知られているこの応答を復号する。この応答を復号することにより、切り替え時間のリストを既に受信していて、クライアント・アプリケーション４５は、図６Ｂで説明されている工程１２におけるように、リストを特に要求する必要がない。むしろ、クライアント・アプリケーション４５は、ユニキャスト配信によってマルチメディア・ストリームを単に受信可能である（工程１２）。
【００４２】
あるいは、図６Ｂにおける上述の工程１０から工程１２までは、図８に説明されている工程１０から工程１２までに置き換えられる場合がある。図８では、再度、クライアント・アプリケーション４５は、ユニキャスト配信によってマルチメディア・ストリームを受信するように要求し（工程１０）、そしてＴＶプレーヤー７０はそれに対応して、ＲＴＳＰ ＰＬＡＹ法によってユニキャスト配信を開始する（工程１１）。図７におけるように、切り替え時間のリストをＲＴＳＰ ＰＬＡＹ応答に自動的に付加する代わりに、しかしながら、ストリーミング・サーバ５０は、ＴＶプレーヤー７０が、ユニキャスト配信によってレンダリングのためにマルチメディア・ストリームを受信し始めてしばらく後に送られるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージに切り替え時間のリストを自動的に付加する（工程１２）。したがって、クライアント・アプリケーション４５は、切り替え時間のリストが追加されていることを知られている、このメッセージを復号する。
【００４３】
クライアント・アプリケーション４５が、図７および図８でマルチメディア・コンテンツ・タイミング情報を受信する仕方に係らず、けれども、クライアント・アプリケーション４５は、図６Ａから図６Ｃまでに関して説明したのと同じ仕方で、すなわち、マルチメディア・コンテンツ・タイミング情報内に示されている隙間に従って、アクセス配信の変更を開始する。
【００４４】
しかしながら、当然のことながら、前述の明細書および添付の図面は、本明細書で教示されている方法および個々の装置の限定されない例を表わしている。そのようなものとして、本発明は、前述の明細書および添付の図面により限定されない。その代わりに、本発明は、以下の特許請求の範囲およびそれらの法的均等論によってのみ限定される。
【特許請求の範囲】
【請求項１】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいてマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更する、移動端末における方法であって、
ユニキャスト・ベアラでユニキャスト配信により前記マルチメディア・ストリームを受信する工程と、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する工程と、
同じマルチメディア・ストリームをまたブロードキャスト／マルチキャスト・ベアラでブロードキャスト／マルチキャスト配信により利用できることを判定する工程と、
前記隙間のうちの対応する１つの間に前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程と
有することを特徴とする方法。
【請求項２】
前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程が、ある最小限の期間にわたってユニキャスト配信により前記マルチメディア・ストリームが受信されていれば変更を開始する工程を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記マルチメディア・コンテンツ・タイミング情報を要求する工程をさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
前記マルチメディア・コンテンツ・タイミング情報を受信する工程が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号する工程を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記マルチメディア・コンテンツ・タイミング情報を受信する工程が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを復号する工程を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記マルチメディア・コンテンツ・タイミング情報がまた前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示しており、かつ前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程が前記隙間のうちの前記対応する１つの間での変更が禁止されていることを前記マルチメディア・コンテンツ・タイミング情報が示さなければ、変更を開始する工程を備えることを特徴とする請求項１に記載の方法。
【請求項７】
移動端末をストリーミング・サーバと通信できるように連結するための受信器であって、ユニキャスト・ベアラでユニキャスト配信により、またはブロードキャスト／マルチキャスト・ベアラでブロードキャスト／マルチキャスト配信により、前記ストリーミング・サーバからマルチメディア・ストリームを受信するように構成された受信機と、
前記受信機に通信できるように連結され、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおける前記マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を前記ストリーミング・サーバから受信する工程と、
同じマルチメディア・ストリームがまたブロードキャスト／マルチキャスト配信により前記ストリーミング・サーバから利用できることを判定する工程と、
前記隙間のうちの対応する１つの間に前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程と
の各工程により行うように構成された１つ以上の処理回路と
を備えることを特徴とする移動端末。
【請求項８】
前記１つ以上の処理回路が、ある最小限の期間にわたってユニキャスト配信により前記マルチメディア・ストリームが受信されていれば変更を開始することにより、前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項９】
前記１つ以上の処理回路がさらに、前記マルチメディア・コンテンツ・タイミング情報を前記ストリーミング・サーバに要求するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１０】
前記１つ以上の処理回路が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号することにより前記マルチメディア・コンテンツ・タイミング情報を受信するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１１】
前記１つ以上の処理回路が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを復号することにより前記マルチメディア・コンテンツ・タイミング情報を受信するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１２】
前記マルチメディア・コンテンツ・タイミング情報がまた前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示しており、かつ前記隙間のうちの前記対応する１つの間での変更が禁止されていることを前記マルチメディア・コンテンツ・タイミング情報が示していなければ変更を開始することにより前記１つ以上の処理回路が前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１３】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいて移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更することを支援する、ストリーミング・サーバにおける方法であって、
前記ネットワークによりユニキャスト配信およびブロードキャスト配信のための前記マルチメディア・ストリームを１つ以上の移動端末に送る工程と、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定する工程と、
前記ネットワークから前記マルチメディア・ストリームを受信する１つ以上の移動端末に前記マルチメディア・コンテンツ・タイミング情報を送る工程と
を有することを特徴とする方法。
【請求項１４】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、前記１つ以上の移動端末からの要求に応答して前記マルチメディア・コンテンツ・タイミング情報を送る工程を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを前記１つ以上の移動端末に知られているメッセージに前記マルチメディア・コンテンツ・タイミング情報を付加する工程を備えることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを送る工程を含むことを特徴とする請求項１３に記載の方法。
【請求項１７】
前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを前記マルチメディア・コンテンツ・タイミング情報の一部として示す工程をさらに有することを特徴とする
請求項１３に記載の方法。
【請求項１８】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいて移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更することを支援するように構成されたストリーミング・サーバであって、
前記マルチメディア・ストリームを構築し、そして管理するように構成されたストリーム処理回路と、
前記マルチメディア・ストリームの前記コンテンツにおいて１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定するように構成された隙間決定回路と、
ユニキャスト配信およびブロードキャスト配信のための前記マルチメディア・ストリームを前記ネットワークにより１つ以上の移動端末に送り、かつ前記ネットワークから前記マルチメディア・ストリームを受信する１つ以上の移動端末に前記マルチメディア・コンテンツ・タイミング情報を送るように構成されたネットワーク・インタフェース回路と
を備えることを特徴とするストリーミング・サーバ。
【請求項１９】
前記ネットワーク・インタフェース回路が、前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に前記１つ以上の移動端末からの要求に応答して送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２０】
前記ネットワーク・インタフェース回路が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを前記１つ以上の移動端末に知られているメッセージに、前記マルチメディア・コンテンツ・タイミング情報を付加することにより、前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２１】
前記ネットワーク・インタフェース回路が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを送ることにより前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２２】
前記隙間決定回路がさらに、前記マルチメディア・コンテンツ・タイミング情報の一部として前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示すように構成されたことを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項１】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいてマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更する、移動端末における方法であって、
ユニキャスト・ベアラでユニキャスト配信により前記マルチメディア・ストリームを受信する工程と、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を受信する工程と、
同じマルチメディア・ストリームをまたブロードキャスト／マルチキャスト・ベアラでブロードキャスト／マルチキャスト配信により利用できることを判定する工程と、
前記隙間のうちの対応する１つの間に前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程と
有することを特徴とする方法。
【請求項２】
前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程が、ある最小限の期間にわたってユニキャスト配信により前記マルチメディア・ストリームが受信されていれば変更を開始する工程を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記マルチメディア・コンテンツ・タイミング情報を要求する工程をさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
前記マルチメディア・コンテンツ・タイミング情報を受信する工程が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号する工程を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記マルチメディア・コンテンツ・タイミング情報を受信する工程が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを復号する工程を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記マルチメディア・コンテンツ・タイミング情報がまた前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示しており、かつ前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程が前記隙間のうちの前記対応する１つの間での変更が禁止されていることを前記マルチメディア・コンテンツ・タイミング情報が示さなければ、変更を開始する工程を備えることを特徴とする請求項１に記載の方法。
【請求項７】
移動端末をストリーミング・サーバと通信できるように連結するための受信器であって、ユニキャスト・ベアラでユニキャスト配信により、またはブロードキャスト／マルチキャスト・ベアラでブロードキャスト／マルチキャスト配信により、前記ストリーミング・サーバからマルチメディア・ストリームを受信するように構成された受信機と、
前記受信機に通信できるように連結され、ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおける前記マルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を前記ストリーミング・サーバから受信する工程と、
同じマルチメディア・ストリームがまたブロードキャスト／マルチキャスト配信により前記ストリーミング・サーバから利用できることを判定する工程と、
前記隙間のうちの対応する１つの間に前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始する工程と
の各工程により行うように構成された１つ以上の処理回路と
を備えることを特徴とする移動端末。
【請求項８】
前記１つ以上の処理回路が、ある最小限の期間にわたってユニキャスト配信により前記マルチメディア・ストリームが受信されていれば変更を開始することにより、前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項９】
前記１つ以上の処理回路がさらに、前記マルチメディア・コンテンツ・タイミング情報を前記ストリーミング・サーバに要求するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１０】
前記１つ以上の処理回路が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを知られているメッセージを復号することにより前記マルチメディア・コンテンツ・タイミング情報を受信するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１１】
前記１つ以上の処理回路が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを復号することにより前記マルチメディア・コンテンツ・タイミング情報を受信するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１２】
前記マルチメディア・コンテンツ・タイミング情報がまた前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示しており、かつ前記隙間のうちの前記対応する１つの間での変更が禁止されていることを前記マルチメディア・コンテンツ・タイミング情報が示していなければ変更を開始することにより前記１つ以上の処理回路が前記マルチメディア・ストリームのユニキャスト配信からブロードキャスト／マルチキャスト配信への変更を選択的に開始するように構成されることを特徴とする請求項７に記載の移動端末。
【請求項１３】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいて移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更することを支援する、ストリーミング・サーバにおける方法であって、
前記ネットワークによりユニキャスト配信およびブロードキャスト配信のための前記マルチメディア・ストリームを１つ以上の移動端末に送る工程と、
前記マルチメディア・ストリームの前記コンテンツにおける１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定する工程と、
前記ネットワークから前記マルチメディア・ストリームを受信する１つ以上の移動端末に前記マルチメディア・コンテンツ・タイミング情報を送る工程と
を有することを特徴とする方法。
【請求項１４】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、前記１つ以上の移動端末からの要求に応答して前記マルチメディア・コンテンツ・タイミング情報を送る工程を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを前記１つ以上の移動端末に知られているメッセージに前記マルチメディア・コンテンツ・タイミング情報を付加する工程を備えることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送る工程が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを送る工程を含むことを特徴とする請求項１３に記載の方法。
【請求項１７】
前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを前記マルチメディア・コンテンツ・タイミング情報の一部として示す工程をさらに有することを特徴とする
請求項１３に記載の方法。
【請求項１８】
ハイブリッド・ユニキャスト−ブロードキャスト配信ネットワークにおいて移動端末がマルチメディア・ストリームのアクセス配信をユニキャスト配信からブロードキャスト／マルチキャスト配信に変更することを支援するように構成されたストリーミング・サーバであって、
前記マルチメディア・ストリームを構築し、そして管理するように構成されたストリーム処理回路と、
前記マルチメディア・ストリームの前記コンテンツにおいて１つ以上の隙間を示すマルチメディア・コンテンツ・タイミング情報を決定するように構成された隙間決定回路と、
ユニキャスト配信およびブロードキャスト配信のための前記マルチメディア・ストリームを前記ネットワークにより１つ以上の移動端末に送り、かつ前記ネットワークから前記マルチメディア・ストリームを受信する１つ以上の移動端末に前記マルチメディア・コンテンツ・タイミング情報を送るように構成されたネットワーク・インタフェース回路と
を備えることを特徴とするストリーミング・サーバ。
【請求項１９】
前記ネットワーク・インタフェース回路が、前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に前記１つ以上の移動端末からの要求に応答して送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２０】
前記ネットワーク・インタフェース回路が、前記マルチメディア・コンテンツ・タイミング情報が付加されていることを前記１つ以上の移動端末に知られているメッセージに、前記マルチメディア・コンテンツ・タイミング情報を付加することにより、前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２１】
前記ネットワーク・インタフェース回路が、実時間ストリーミング・プロトコル・メッセージ、実時間トランスポート・プロトコル・パケット、または一方向トランスポートでのファイル配信（ＦＬＵＴＥ）パケットのうちの１つを送ることにより前記マルチメディア・コンテンツ・タイミング情報を１つ以上の移動端末に送るように構成されることを特徴とする請求項１８に記載のストリーミング・サーバ。
【請求項２２】
前記隙間決定回路がさらに、前記マルチメディア・コンテンツ・タイミング情報の一部として前記１つ以上の隙間の各々の間でのアクセス変更が禁止されているかどうかを示すように構成されたことを特徴とする請求項１８に記載のストリーミング・サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【公表番号】特表２０１２−５１４３６２（Ｐ２０１２−５１４３６２Ａ）
【公表日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１１−５４２８４０（Ｐ２０１１−５４２８４０）
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０６７９４５
【国際公開番号】ＷＯ２０１０／０７６３０１
【国際公開日】平成２２年７月８日（２０１０．７．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０６７９４５
【国際公開番号】ＷＯ２０１０／０７６３０１
【国際公開日】平成２２年７月８日（２０１０．７．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]