特表 2022-518107 オーディオビジュアルライブコンテンツ配信のための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-03-14

(54)【発明の名称】オーディオビジュアルライブコンテンツ配信のための方法およびシステム

(51)【国際特許分類】

   H04N 21/647 20110101AFI20220307BHJP

   H04L 45/00 20220101ALI20220307BHJP

   H04N 21/61 20110101ALI20220307BHJP

【ＦＩ】

H04N21/647

H04L12/761

H04N21/61

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021531094

(86)(22)【出願日】2018-11-28

(85)【翻訳文提出日】2021-07-08

(86)【国際出願番号】 IB2018001488

(87)【国際公開番号】W WO2020109834

(87)【国際公開日】2020-06-04

(81)【指定国・地域】

(71)【出願人】

【識別番号】521231455

【氏名又は名称】ブロードピーク

(74)【代理人】

【識別番号】110001656

【氏名又は名称】特許業務法人谷川国際特許事務所

(72)【発明者】

【氏名】ベール，ソフィー

(72)【発明者】

【氏名】ブレビオン，レミー

(72)【発明者】

【氏名】レナード，ニコラス

(72)【発明者】

【氏名】マーティン，ジーン－フランソワ

(72)【発明者】

【氏名】ブトー，ピエール－オリヴィエ

【テーマコード（参考）】

5C164

5K030

【Ｆターム（参考）】

5C164SB24S

5C164TA08S

5C164TA22P

5C164TB03S

5C164TB04S

5C164TB11S

5C164TB45P

5K030HD03

5K030JT04

5K030LD05

5K030LD06

(57)【要約】

オーディオビジュアルライブコンテンツ配信システムは、ゲートウェイ（１４０）を介して、プロバイダネットワーク（１０２）にアクセスするクライアント（１１０）と、プロバイダネットワーク（１０２）を介してマルチキャスト形式でオーディオビジュアルライブコンテンツを送信するためのマルチキャスタを備える、オーディオビジュアルライブコンテンツ配信機器（１２０）と、マルチキャスタからマルチキャスト形式で受信されたオーディオビジュアルライブコンテンツのユニキャスト形式の変換を実行することができるデマルチキャスタ（１５０）と、オーディオビジュアルライブコンテンツを取得する要求のルーティングを管理するコントローラ（１３０）と、を含む。クライアント（１１０）は、デマルチキャスタ（１５０）の潜在的存在および可用性に関する情報を受信することを目的とした発見手順を実行する。クライアント（１１０）が標的化されたオーディオビジュアルライブコンテンツを受信することを意図するときに、クライアント（１１０）は、デマルチキャスタ（１５０）の存在および可用性の有無の指示を提供する要求をコントローラ（１３０）に送信する。次いで、コントローラ（１３０）は、少なくともデマルチキャスタ（１５０）の存在および可用性の有無の指示に従って、クライアント（１１０）をどのようにリダイレクトして要求を果たすかを判定する。
【選択図】図１

【特許請求の範囲】

【請求項1】

標的化されたオーディオビジュアルライブコンテンツをクライアント（１１０）に配信するための方法であって、前記方法が、
－プロバイダネットワーク（１０２）へのアクセスを提供するゲートウェイ（１４０）によって前記プロバイダネットワーク（１０２）に相互接続されたローカルエリアネットワーク（１０１）に位置するか、または前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）に位置する、前記クライアント（１１０）と、
－前記プロバイダネットワーク（１０２）を介して、マルチキャスト形式でオーディオビジュアルライブコンテンツを伝送するためのマルチキャスタがある１つ以上のサーバを備える、オーディオビジュアルライブコンテンツ配信機器（１２０）と、
－前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置する任意のデバイス内のデマルチキャスタ（１５０）であって、前記マルチキャスタからマルチキャスト形式で受信されたオーディオビジュアルライブコンテンツのユニキャスト形式の変換を実行することができる、デマルチキャスタ（１５０）と、
－オーディオビジュアルライブコンテンツを取得する要求のルーティングを管理するコントローラ（１３０）と、を含む、オーディオビジュアルライブコンテンツシステムによって実行され、
前記方法が、
－前記クライアント（１１０）が、前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）および前記ローカルエリアネットワーク（１０１）に接続された任意のデバイスから、前記デマルチキャスタ（１５０）の潜在的存在および可用性に関する情報を受信することを目的とした発見手順（２００、２１０、５００、５１０、７０１、９０１、９１１、１１１１）を実行することと、
前記クライアント（１１０）が前記標的化されたオーディオビジュアルライブコンテンツを受信することを意図するときに、
－前記クライアント（１１０）が、前記デマルチキャスタ（１５０）の存在および可用性の有無の指示を提供する、または提供しない前記標的化されたオーディオビジュアルライブコンテンツを取得する要求（２０１、２１１、５０３、５１３、７０４、９０４、９１４、１１１４）を前記コントローラ（１３０）に送信することと、
－前記コントローラ（１３０）が、少なくとも前記デマルチキャスタ（１５０）の存在および可用性の有無の前記指示に従って、前記クライアント（１１０）をどのようにリダイレクトして、前記標的化されたオーディオビジュアルライブコンテンツを取得する要求を果たすかを判定することと、を含むことを特徴とする、方法。

【請求項2】

前記デマルチキャスタ（１５０）の存在および可用性の有無の前記指示が、前記標的化されたオーディオビジュアルライブコンテンツを取得するために前記要求において暗黙的に提供され、その結果、前記デマルチキャスタ（１５０）が存在し利用可能である場合に、前記標的化されたオーディオビジュアルライブコンテンツを取得する前記要求が、前記発見手順から生じる前記デマルチキャスタ（１５０）のアドレスを提供するインラインパラメータを含む、請求項１に記載の方法。

【請求項3】

前記プロバイダネットワーク（１０２）が、前記プロバイダネットワーク（１０２）を介して、前記ゲートウェイ（１４０）および前記ローカルエリアネットワーク（１０１）からのアップリンク通信を可能にし、前記コントローラ（１３０）が、前記プロバイダネットワーク（１０２）上に位置し、前記コントローラ（１３０）は、前記コントローラ（１３０）が、前記クライアント（１１０）が前記変換から利益を得ることができないと判断するときに、前記クライアント（１１０）を前記オーディオビジュアルライブコンテンツ配信機器のユニキャストサーバ（１２３）にリダイレクトし、そうでなければ前記クライアント（１１０）を前記デマルチキャスタ（１５０）にリダイレクトする、請求項１および２のいずれか一項に記載の方法。

【請求項4】

前記クライアントが、前記プロバイダネットワーク（１０２）に位置するドメイン名サーバ（１６１）にドメイン名解決を要求することによって、前記コントローラ（１３０）に接触するアドレスを判定し、前記ドメイン名解決が、前記標的化されたオーディオビジュアルライブコンテンツを識別するユニフォームリソースロケータに含まれる完全修飾ドメイン名に関するものである、請求項３に記載の方法。

【請求項5】

前記デマルチキャスタ（１５０）が、前記マルチキャスタ（１２１）から前記標的化されたオーディオビジュアルライブコンテンツを受信する前記オーディオビジュアルライブコンテンツ配信機器（１２０）の修復ユニキャストサーバ（１２２）から、マルチキャスト形式で失われた前記標的化されたオーディオビジュアルライブコンテンツのセグメントを検索する、請求項３または４に記載の方法。

【請求項6】

前記クライアント（１１０）を前記デマルチキャスタ（１５０）にリダイレクトするときに、前記コントローラ（１３０）が、前記標的化されたオーディオビジュアルライブコンテンツを取得する前記要求に指示され、かつ前記標的化されたオーディオビジュアルライブコンテンツを識別する、ユニフォームリソースロケータに含まれる前記完全修飾ドメイン名を提供するインラインパラメータを含むリダイレクトメッセージを伝送し、前記デマルチキャスタ（１５０）が、前記クライアント（１１０）が前記変換から利益を受けることができないと判定したときに、前記デマルチキャスタ（１５０）が、前記クライアント（１１０）を前記プロバイダネットワーク（１０２）上のユニキャストサーバにリダイレクトし、前記デマルチキャスタ（１５０）が、前記完全修飾ドメイン名を提供する前記インラインパラメータを使用して、前記プロバイダネットワーク（１０２）に位置するドメイン名サーバ（１６１）にドメイン名解決を要求することによって、前記ユニキャストサーバのアドレスを判定する、請求項３～５のいずれか一項に記載の方法。

【請求項7】

前記プロバイダネットワーク（１０２）が、前記プロバイダネットワーク（１０２）を介して、前記ゲートウェイ（１４０）および前記ローカルエリアネットワーク（１０１）からのアップリンク通信を可能にし、前記コントローラ（１３０）が、前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置し、前記コントローラ（１４０）は、前記コントローラ（１３０）が、前記クライアント（１１０）が前記変換から利益を受けることができないと判定するときに、前記クライアント（１１０）を前記プロバイダネットワーク（１０２）上のマルチキャスト非認識ユニキャストサーバにリダイレクトし、そうでなければ前記クライアントを前記デマルチキャスト（１５０）にリダイレクトする、請求項１および２のいずれか一項に記載の方法。

【請求項8】

前記クライアント（１１０）が、前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置するローカルドメイン名サーバ（１６２）にドメイン名解決を要求することによって、前記コントローラ（１３０）に接触するアドレスを判定し、前記ドメイン名解決が、前記標的化されたオーディオビジュアルライブコンテンツを識別するユニフォームリソースロケータに含まれる完全修飾ドメイン名に関するものである、請求項７に記載の方法。

【請求項9】

前記コントローラ（１３０）が、前記完全修飾ドメイン名を前記コントローラ（１３０）のアドレスと関連付けるように、前記ローカルドメイン名サーバ（１６２）を事前に構成している、請求項８に記載の方法。

【請求項10】

前記コントローラ（１３０）および前記デマルチキャスタ（１５０）が、同じマシン内に併設されており、前記クライアント（１１０）が、前記発見手順から生じる前記デマルチキャスタ（１５０）に接触するアドレスから前記コントローラ（１３０）に接触する前記アドレスを導出することによって、前記コントローラ（１３０）に接触するアドレスを判定する、請求項７に記載の方法。

【請求項11】

前記デマルチキャスタ（１５０）が、前記マルチキャスタ（１２１）から前記標的化されたオーディオビジュアルライブコンテンツを受信する前記オーディオビジュアルライブコンテンツ配信機器（１２０）の修復ユニキャストサーバ（１２２）から、マルチキャスト形式で失われた前記標的化されたオーディオビジュアルライブコンテンツのセグメントを検索する、請求項８～１０に記載の方法。

【請求項12】

前記クライアント（１１０）を前記デマルチキャスタ（１５０）にリダイレクトするときに、前記コントローラ（１３０）が、前記標的化されたオーディオビジュアルライブコンテンツを取得する前記要求に指示され、前記標的化されたオーディオビジュアルライブコンテンツを識別するユニフォームリソースロケータに含まれる前記完全修飾ドメイン名を提供するインラインパラメータを含むリダイレクトメッセージを伝送し、前記デマルチキャスタ（１５０）が、前記クライアント（１１０）が前記変換から利益を受けることができないと判定したときに、前記デマルチキャスタ（１５０）が、前記クライアント（１１０）を前記プロバイダネットワーク（１０２）上のマルチキャスト非認識ユニキャストサーバにリダイレクトし、前記デマルチキャスタ（１５０）が、前記完全修飾ドメイン名を提供する前記インラインパラメータを使用して、前記プロバイダネットワーク（１０２）に位置するドメイン名サーバ（１６１）にドメイン名解決を要求することによって、前記マルチキャスト非認識ユニキャストサーバのアドレスを判定する、請求項８～１１のいずれか一項に記載の方法。

【請求項13】

前記プロバイダネットワーク（１０２）が、前記プロバイダネットワーク（１０２）を介して、前記ゲートウェイ（１４０）および前記ローカルエリアネットワーク（１０１）からのアップリンク通信を可能にせず、前記コントローラ（１３０）が、前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置し、前記コントローラ（１３０）は、前記コントローラ（１３０）が、前記クライアント（１１０）が前記変換から利益を受けることができないと判定するときに、前記標的化されたオーディオビジュアルライブコンテンツを取得する前記要求を拒否し、そうでなければ前記クライアント（１１０）を前記デマルチキャスト（１５０）にリダイレクトする、請求項１および２のいずれか一項に記載の方法。

【請求項14】

前記クライアントが、前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置するローカルドメイン名サーバ（１６２）にドメイン名解決を要求することによって、前記コントローラ（１３０）に接触するアドレスを判定し、前記ドメイン名解決が、前記標的化されたオーディオビジュアルライブコンテンツを識別するユニフォームリソースロケータに含まれる完全修飾ドメイン名に関するものである、請求項１３に記載の方法。

【請求項15】

前記デマルチキャスタ（１５０）が、前記完全修飾ドメイン名を前記コントローラ（１３０）のアドレスと関連付けるように、前記ローカルドメイン名サーバ（１６２）を事前に構成している、請求項１４に記載の方法。

【請求項16】

前記コントローラ（１３０）および前記デマルチキャスタ（１５０）が、同じマシン内に併設されており、前記クライアント（１１０）が、前記発見手順から生じる前記デマルチキャスタ（１５０）に接触するアドレスから前記コントローラ（１３０）に接触する前記アドレスを導出することによって、前記コントローラ（１３０）に接触するアドレスを判定する、請求項１３に記載の方法。

【請求項17】

オーディオビジュアルライブコンテンツ配信システムであって、
－プロバイダネットワーク（１０２）へのアクセスを提供するゲートウェイ（１４０）によって前記プロバイダネットワーク（１０２）に相互接続されたローカルエリアネットワーク（１０１）に位置するか、または前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）に位置するクライアント（１１０）と、
－前記プロバイダネットワーク（１０２）を介してマルチキャスト形式でオーディオビジュアルライブコンテンツを伝送するためのマルチキャスタがある１つ以上のサーバを備える、オーディオビジュアルライブコンテンツ配信機器（１２０）と、
－前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）または前記ローカルエリアネットワーク（１０１）に位置する任意のデバイス内のデマルチキャスタ（１５０）であって、前記マルチキャスタからマルチキャスト形式で受信されたオーディオビジュアルライブコンテンツのユニキャスト形式の変換を実行することができる、デマルチキャスタ（１５０）と、
－オーディオビジュアルライブコンテンツを取得する要求のルーティングを管理するコントローラ（１３０）と、を含み、
－前記クライアント（１１０）が、前記プロバイダネットワーク（１０２）へのアクセスを提供する前記ゲートウェイ（１４０）および前記ローカルエリアネットワーク（１０１）に接続された任意のデバイスから、前記デマルチキャスタ（１５０）の潜在的存在および可用性に関する情報を受信することを目的とした発見手順（２００、２１０、５００、５１０、７０１、９０１、９１１、１１１１）を実行するための手段を含むことと、
－前記クライアント（１１０）が、前記クライアント（１１０）が前記標的化されたオーディオビジュアルライブコンテンツを受信することを意図するときに、前記デマルチキャスタ（１５０）の存在および可用性の有無の指示を提供する、前記標的化されたオーディオビジュアルライブコンテンツを取得する要求を前記コントローラ（１３０）に送信するための手段（２０１、２１１、５０３、５１３、７０４、９０４、９１４、１１１４）を含むことと、
－前記コントローラ（１３０）が、少なくとも前記デマルチキャスタ（１５０）の存在および可用性の有無の前記指示に従って、前記クライアント（１１０）をどのようにリダイレクトして、前記標的化されたオーディオビジュアルライブコンテンツを取得する要求を果たすかを判定することと、を特徴とする、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、クライアントデバイスと、ローカルエリアネットワークをプロバイダネットワークに相互接続するゲートウェイデバイスであって、クライアントデバイスが、ローカルエリアネットワークに接続されている、ゲートウェイデバイスと、プロバイダネットワークに接続されているオーディオビジュアルライブコンテンツを提供するように適合された機器と、にオーディオビジュアルライブコンテンツを配信することに関する。

【0002】

関連技術
過去に、ほとんどのビデオライブストリーミング技術は、ＲＴＰ（規範文書ＲＦＣ ３５５０で定義されている「リアルタイム転送プロトコル」）またはＲＴＳＰ（規範文書ＲＦＣ ２３２６で定義されている「リアルタイムストリーミングプロトコル」）などのストリーミングプロトコルに依存していた。今日のライブストリーミング技術は、ほぼＨＴＴＰ（規範的文書ＲＦＣ ２６１６で定義されている「ハイパーテキストトランスファープロトコル」）のみに基づいており、インターネットなどの大規模かつ分散的なＨＴＴＰネットワークで効率的に動作するように設計されている。

【0003】

アダプティブビットレートストリーミング（ＡＢＳ）は、コンピュータネットワークを介したコンテンツのストリーミングに使用される一般的なＨＴＴＰストリーミング技術の１つであり、ＨＬＳ（以下「ＨＴＴＰライブストリーミング」）は、ＨＴＴＰに基づくライブストリーミング通信プロトコルであり、Ａｐｐｌｅ Ｉｎｃ．によって開発されており、１つの特定の実装である。ＨＬＳは、全体的なＡＶ（「オーディオビジュアル」）ストリームを、ＨＴＴＰベースの小さなファイルダウンロードのシーケンスに分割することで動作し、各々が、潜在的に無限の転送ストリーム全体の１つのチャンクを含む。ＡＶコンテンツは、様々な解像度で利用可能であり、チャンクに分割され、チャンクは、実際の解像度に関わらず、ＡＶコンテンツの時間セグメントに対応する、ＡＶコンテンツの一部である。ＡＶストリームが再生されると、ＡＶコンテンツを復号化するクライアントデバイスは、様々なそれぞれの解像度（様々なそれぞれのビットレート）で符号化された同じマテリアルを含む異なる代替バージョン（レイヤまたは表現とも称される）から選択してもよく、ストリーミングセッションがネットワークの利用可能な伝送リソースおよび／またはクライアントデバイスの利用可能な処理リソースに適合することを可能にする。ストリーミングセッションの開始時に、クライアントデバイスは、通常、「Ｍ３Ｕ」または「ｍ３ｕ８」ファイル拡張子を有するテキストファイルの形態でプレイリストをダウンロードする。このテキストファイルには、関連するＡＶコンテンツで利用可能な様々な代替バージョンのメタデータが含まれている。

【0004】

同様のＡＢＳアプローチは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．によって提供される統合ＨＴＴＰベースのメディア配信プラットフォームであるＩｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ（ＩＩＳ）Ｍｅｄｉａ Ｓｅｒｖｉｃｅｓの特徴であるＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇによって実装される。ＡＶストリームがプレイリストファイルを補完したチャンクを含む複数のファイルで切断されるＨＬＳとは対照的に、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇはピースに切断される単一のＡＶファイルに依存し、各ファイルには該当する層を指示する記述子およびＡＶコンテンツ内の参照時間が含まれる。しかしながら、プロトコルの基礎および利点は同等である。

【0005】

同様に、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐが開発した、かつ、ＨＤＳ、ＨＬＳおよびＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇに関連するＭＰＥＧダッシュと称される、マルチメディアストリーミング技術であるＡｄｏｂｅ ＳｙｓｔｅｍｓのＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＨＤＳ）およびＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ を同様に考慮してもよい。「ｍｐｄ」ファイル拡張子を持つファイルが次いで使用される。

【0006】

ＨＴＴＰベースのストリーミング技術は、ＨＴＴＰがファイアウォールを通過することを可能にし、ＴＣＰ（規範文書ＲＦＣ ７９３によって定義される「伝送制御プロトコル」）に依存することによってデータの整合性を保証するため、非常に便利である。しかし、ＡＢＳの文脈におけるＨＴＴＰのユニキャストの性質は、ライブストリーミングにＡＢＳベースの機構を採用することを妨げるＣＤＮ（「コンテンツ配信ネットワーク」）オペレータにとって大きなスケーラビリティの問題を生み出している。実際、ＨＴＴＰベースのストリーミング技術はユニキャスト伝送に依存し、したがって、多くのユーザがＡＶライブコンテンツの視聴を同時に要求する可能性があるため、バックエンドインフラストラクチャの観点から持続不可能である可能性がある。

【0007】

ライブＡＶコンテンツ配信のためのＨＴＴＰベースのストリーミング技術のこのような欠点を考慮して、多くのオペレータはマルチキャストベースのライブストリーミング技術に依存している。これにより、バックエンドインフラストラクチャをより費用対効果の高い方法でサイジングすることができる。したがって、マルチキャスト－ＡＢＲ（以下、特許文献ＥＰ ２ ７０４ ３９１ Ａ１に開示されているように、Ｍ－ＡＢＲと称される）で改善されている。

【0008】

これは、マニフェストファイルおよびＡＶライブコンテンツの様々な表現をマルチキャストＩＰ（規範文書ＲＦＣ ７９１によって定義される「インターネットプロトコル」）パケットとしてマルチキャストまたはブロードキャスト媒体を介して送信することで構成され、したがって、ネットワークリソースの大幅な消費削減を提供する。ネットワーク側には、いわゆるマルチキャストサーバ（マルチキャスタと称される）があり、基本的にマニフェストを取得し、その後、対応するセグメントを発信元サーバから取得する。マルチキャスタは、中間転送プロトコルのいくつかのカプセル化スキームを使用して、マルチキャストＩＰパケット内のセグメントをカプセル化する。ゲートウェイ側には、当該中間転送プロトコルを実装することによってマルチキャストＩＰパケットを受信し、ユニキャスト送信を使用することによってクライアントデバイスのプレイヤに供給する準備ができたメディアセグメントとしてペイロードを抽出する、いわゆるデマルチキャスタが存在する。プレイヤは、セグメントの持続時間および推定品質／ビットレートに基づいて、従来のユニキャスト方式（例えば、ＭＰＥＧダッシュ）で、クライアントデバイスの立場からＨＴＴＰサーバとして機能するデマルチキャスタにセグメントを要求する。

【0009】

クライアントデバイスがデマルチキャスタをプロキシとして使用することを保証するために、特許文献ＥＰ ２ ７０４ ３９１ Ａ１は、クライアントデバイスがＡＶライブコンテンツの配信を要求するＣＤＮコントローラが、クライアントデバイスが位置するローカルエリアネットワーク（ＬＡＮ）と、ＣＤＮコントローラとマルチキャスタが位置するプロバイダネットワークとを相互接続するゲートウェイ内のデマルチキャスタにクライアントデバイスをリダイレクトするリダイレクト機構を開示している。

【0010】

しかしながら、柔軟性の考慮のために、ＣＤＮコントローラが、クライアントデバイスが位置するＬＡＮとプロバイダネットワークとを相互接続するゲートウェイがこのようなデマルチキャスタを実装するかどうか、また、存在する場合、このデマルチキャスタが問題のクライアントデバイスを担当することができるかどうかを動的に判定することが望ましいであろう。クライアントデバイスの観点からＣＤＮコントローラと見なされるデバイスの有効な場所、特にＣＤＮコントローラと見なされるデバイスの有効な場所がクライアントデバイスの実装に影響を及ぼさないという点で柔軟なソリューションを提供することがさらに望ましい。クライアントデバイス（例えば、ブロードキャストネットワーク）からのアップリンク通信能力を有しないプロバイダネットワークおよびこのようなアップリンク通信能力を有するプロバイダネットワークをサポートするのに十分な柔軟性を有するソリューションを提供することがさらに望ましい。

【0011】

適応ストリーミングの文脈で動作するソリューションを提供することがさらに望ましく、したがって、様々な対応するビットレート（または解像度）で符号化されたＡＶライブコンテンツの異なる代替バージョン（または表現）の可用性からユーザが利益を得ることが可能になる。

【0012】

また、単純かつ費用対効果の高いソリューションを提供することも特に望ましい。

【発明の概要】

【0013】

そのために、本発明は、標的化されたオーディオビジュアルライブコンテンツをクライアントに配信するための方法に関し、本方法は、

【0014】

－プロバイダネットワークへのアクセスを提供するゲートウェイによってプロバイダネットワークに相互接続されたローカルエリアネットワークに位置する、またはプロバイダネットワークへのアクセスを提供するゲートウェイに位置するクライアントと、

【0015】

－プロバイダネットワークを介してマルチキャスト形式でオーディオビジュアルライブコンテンツを伝送するためのマルチキャスタがある１つ以上のサーバを備える、オーディオビジュアルライブコンテンツ配信機器と、
－プロバイダネットワークへのアクセスを提供するゲートウェイまたはローカルエリアネットワークに位置する任意のデバイス内のデマルチキャスタであって、マルチキャスタからマルチキャスト形式で受信されたオーディオビジュアルライブコンテンツのユニキャスト形式の変換を実行することができる、デマルチキャスタと、
－オーディオビジュアルライブコンテンツを取得する要求のルーティングを管理するコントローラと、を含む、オーディオビジュアルライブコンテンツシステムによって実行され、
本方法は、
－クライアントが、プロバイダネットワークへのアクセスを提供するゲートウェイおよびローカルエリアネットワークに位置する任意のデバイスから、デマルチキャスタの潜在的存在および可用性に関する情報を受信することを目的とした発見手順を実行することと、
クライアントが標的化されたオーディオビジュアルライブコンテンツを受信することを意図するときに、
－クライアントが、デマルチキャスタの存在および可用性の有無の指示を提供する、または提供しない標的化されたオーディオビジュアルライブコンテンツを取得する要求をコントローラに送信することと、
－コントローラが、少なくとも前記デマルチキャスタの存在および可用性の有無の指示に従って、クライアントをどのようにリダイレクトして、標的化されたオーディオビジュアルライブコンテンツを取得する要求を果たすかを判定することと、を含む。

【0016】

したがって、要求において、デマルチキャストの存在および可用性の有無の指示を受信することによって、コントローラは、マルチキャストからユニキャストへの変換からクライアントに利益をもたらすことが可能であるかどうかを判定することができる。コントローラは、存在しない、または存在するが利用可能（例えば、アクティブ）ではないデマルチキャスタにクライアントをリダイレクトしようとすることを回避する。コントローラは、ローカルエリアネットワーク内のゲートウェイまたは別のデバイスがデマルチキャスタを埋め込んでいるかどうか、また、デマルチキャスタ（存在する場合）が有効にアクティブであるかどうかを自身で確認する必要があることを回避し、これは、コントローラが多数のゲートウェイと対話するときに、時間およびリソースを消費する。

【図面の簡単な説明】

【0017】

本発明の特徴は、少なくとも１つの実施形態の以下の説明の読み取りからより明確に現れるであろう。当該説明は、添付の図面を参照して作成される。

【0018】

【図1】本発明による、ＡＶライブコンテンツ配信システムを模式的に表す。

【図2A】本発明による、ＡＶライブコンテンツ配信システムに発生する交換を模式的に表す。

【図2B】本発明による、ＡＶライブコンテンツ配信システムに発生する交換を模式的に表す。

【図3】ＡＶライブコンテンツ配信システム内のデバイスの例示的なハードウェアアーキテクチャを模式的に表す。

【図4】ＡＶライブコンテンツ配信システムの第１の実施形態を模式的に表す。

【図5A】ＡＶライブコンテンツ配信システムの第１の実施形態で発生する交換を模式的に表す。

【図5B】ＡＶライブコンテンツ配信システムの第１の実施形態で発生する交換を模式的に表す。

【図6】ＡＶライブコンテンツ配信システムの第２の実施形態を模式的に表す。

【図7】ＡＶライブコンテンツ配信システムの第２の実施形態で発生する交換を模式的に表す。

【図8】ＡＶライブコンテンツ配信システムの第３の実施形態を模式的に表す。

【図9A】ＡＶライブコンテンツ配信システムの第３の実施形態で発生する交換を模式的に表す。

【図9B】ＡＶライブコンテンツ配信システムの第３の実施形態で発生する交換を模式的に表す。

【図10】ＡＶライブコンテンツ配信システムの第４の実施形態を模式的に表す。

【図11】ＡＶライブコンテンツ配信システムの第４の実施形態で発生する交換を模式的に表す。

【0019】

少なくとも１つの実施形態の詳細な説明
図１は、本発明による、ＡＶライブコンテンツ配信システムを模式的に表す。

【0020】

ＡＶライブコンテンツ配信システムは、ＬＡＮ１０１とプロバイダネットワークＰＮ１０２とを相互接続するゲートウェイＧＷ１４０を備える。プロバイダネットワークＰＮ１０２は、例えばＩＳＰ（「インターネットサービスプロバイダ」）ネットワークである。プロバイダネットワークＰＮ１０２は、例えば、ケーブルまたは衛星放送ネットワークである。したがって、プロバイダネットワークＰＮ１０２は、以下で詳細に説明されるように、ダウンリンクおよびアップリンク伝送を可能にしてもよく、またはダウンリンク伝送のみを可能にしてもよい。好ましい実施形態において、ＬＡＮ１０１およびプロバイダネットワークＰＮ１０２は、ＩＰプロトコルをサポートする。ゲートウェイＧＷ１４０は、好ましくはレジデンシャルゲートウェイである。

【0021】

ＡＶライブコンテンツ配信システムは通常、複数のＬＡＮを含み、したがって、異なる地理的位置にあるクライアントデバイスがＡＶライブコンテンツ配信から利益を得ることを可能にするように、それぞれのゲートウェイによってプロバイダネットワークＰＮ１０２に相互接続される。

【0022】

ＡＶライブコンテンツ配信システムでは、少なくとも１つのクライアントがプレイヤＰＬ１１０を含む、または、それに接続されている。クライアントは通常、ＬＡＮ１０１に接続されている。プレイヤＰＬ１１０は、クライアントによって受信されたＡＶライブコンテンツをユニキャスト形式で消費する（例えば、再生する、記録する）ように適合され、構成されている。好ましくは、クライアントは、ＨＴＴＰを使用してＡＶライブコンテンツを通信し、受信するように適合され、構成されており、例えば、ＨＡＳ（「ＨＴＴＰ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ」）スキームに準拠したＡＶライブコンテンツを消費するように適合され、構成されている。したがって、クライアントはマルチキャストまたはブロードキャスト形式でＡＶライブコンテンツを受信することができない。以下に詳細に説明するように、プレイヤＰＬ１１０は、ＡＶライブコンテンツ配信システムのインフラストラクチャに対して不可知である。クライアントは、ＡＶライブコンテンツデータがプレイヤＰＬ１１０に十分な形式であるように、プレイヤＰＬ１１０によって消費されることを意図して受信したＡＶライブコンテンツデータを形作る。クライアントは、プレイヤＰＬ１１０が当該ＡＶライブコンテンツデータを受信することを可能にするためにプロトコル交換を実行する。以下、クライアントおよびプレイヤＰＬ１１０が単一のエンティティであることを簡素化のために考慮する。

【0023】

ＡＶライブコンテンツ配信システムでは、コンテンツ配信機器ＣＤＥ１２０は、プロバイダネットワークＰＮ１０２に直接または間接的に接続される。コンテンツ配信機器ＣＤＥ１２０は、１つ以上のサーバを備える。コンテンツ配信機器ＣＤＥ１２０は、少なくともマルチキャスタを備える。マルチキャスタは、プロバイダネットワークＰＮ１０２ＡＶライブコンテンツをマルチキャスト形式で提供することを担当する。例えば、マルチキャスタは、ＵＤＰ（規範文書ＲＦＣ ７６８によって定義される「ユーザデータグラムプロトコル」）上でＲＴＰを使用したマルチキャストストリームの形式でＡＶライブコンテンツの様々な表現を提供する。プロバイダネットワークＰＮ１０２を介したマルチキャスト送信に依存することは、ユニキャスト方式でのＡＶライブコンテンツの配信と比較して、バックエンドインフラストラクチャ（すなわち、ＡＶライブコンテンツ配信を実行するためのコンテンツ配信機器ＣＤＥ１２０によって必要とされる処理リソースおよび帯域幅）のダウンサイジングを可能にする。

【0024】

マルチキャスタの上流には、ＡＶライブコンテンツの様々な表現をセグメントにパッケージ化することを担当する発信元サーバ（発信元パッケージャとも称される）が存在してもよく、これらはすべて、例えば、ＨＡＳスキームに準拠したメディアファイルのセットとして整列されている（同じ期間、同じ画像）。発信元パッケージャの上流には、ＡＶライブコンテンツ（例えば、テレビチャネル）の様々な表現を発信元パッケージャに配信するＯＴＴ（「オーバーザトップ」）エンコーダが存在してもよく、各表現は、特定のビットレート／品質を有するＯＴＴエンコーダによって符号化される。

【0025】

ゲートウェイＧＷ１４０またはＬＡＮ１０１内の別のデバイス（クライアントを含む）は、デマルチキャスタＤＭ１５０を備える。デマルチキャスタＤＭ１５０は、おそらくデマルチキャスタＤＭ１５０がＬＡＮ１０１内の別のデバイスに位置するときにゲートウェイＧＷ１４０を通過することによって、マルチキャスタによって伝送されたマルチキャストＩＰパケットを受信するように適合され、構成されている。

【0026】

デマルチキャスタＤＭ１５０は、ユニキャスト伝送を使用することによってプレイヤＰＬ１１０に供給する準備ができたＡＶライブコンテンツセグメントを抽出するように適合され、構成されている。プレイヤＰＬ１１０がＡＶライブコンテンツを受信するときに、プレイヤＰＬ１１０は、ＡＶライブコンテンツを受信するために利用可能な帯域幅を監視し、さらに、利用可能な帯域幅および好ましくは利用可能な内部処理リソースと一致するＡＶライブコンテンツの表現を選択するように適合され、構成されている。したがって、デマルチキャスタＤＭ１５０は、マルチキャストからユニキャストへの変換を実行するように適合され、構成されている。そのために、デマルチキャスタＤＭ１５０は、例えば、ＩＧＭＰ（規範文書ＲＦＣ３３７６によって定義されるように、「インターネットグループ管理プロトコル」）プロトコルを実装することによって、マルチキャストストリーム登録を管理するように適合され、構成されている。さらに、デマルチキャスタＤＭ１５０は、事前の構成によって、例えば、コンテンツ配信機器ＣＤＥ１２０によって提供される所定の専用マルチキャストストリームもしくはチャネルを使用することによって、またはコンテンツ配信機器ＣＤＥ１２０の所定の専用構成サーバと交換することによって、どのＡＶライブコンテンツがマルチキャスト伝送を介して受信され得るかを知る。

【0027】

デマルチキャスタＤＭ１５０は、デマルチキャスタＤＭ１５０がマルチキャスト伝送中に失われたＡＶライブコンテンツセグメントを検索することを可能にするために、コンテンツ配信機器ＣＤＥ１２０のユニキャストサーバＲＵＳを修復するユニキャスト形式のＡＶライブコンテンツセグメントを要求し、それに応答して受信するようにさらに適合され、構成されてもよい。この態様は、以下で取り上げられる。

【0028】

ゲートウェイＧＷ１４０およびＬＡＮ１０１等のプロバイダネットワークＰＮ１０２に接続されるゲートウェイおよびＬＡＮは、このようなデマルチキャスタを含んでもよく、一方、プロバイダネットワークＰＮ１０２に接続される他のゲートウェイまたは他のＬＡＮは、このようなデマルチキャスタを含まなくてもよい。さらに、このようなデマルチキャスタを含むゲートウェイまたはＬＡＮの中で、いくつかのデマルチキャスタが存在するが、アクティブではなくてもよく、いくつかのデマルチキャスタは、メモリおよび／または処理リソースが既に不足している可能性がある。この態様は、以下で詳細に取り上げられる。

【0029】

ＡＶライブコンテンツ配信システムでは、コントローラＣＴＲＬ１３０は、ＡＶライブコンテンツ配信を編成し、すなわち、オーディオビジュアルライブコンテンツを取得する要求のルーティングを管理する。ＡＶライブコンテンツ配信システムのインフラストラクチャに応じて、コントローラＣＴＲＬ１３０は、プロバイダネットワークＰＮ１０２に位置し、もしくはそれに接続されもよく、または、ゲートウェイＧＷ１４０もしくはＬＡＮ１０１に位置してもよい。プレイヤＰＬ１１０が（例えば、ユーザコマンドに従って）ＡＶライブコンテンツを消費することが予想されるとき、プレイヤＰＬ１１０は、問題のＡＶライブコンテンツの配信を要求するためにコントローラＣＴＲＬ１３０に接触する。プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０がＡＶライブコンテンツを配信することができるサーバであるかのようにコントローラＣＴＲＬ１３０に接触する。コントローラＣＴＲＬ１３０が単独でＡＶライブコンテンツを配信できないという事実は、プレイヤＰＬ１１０にとって透過的である。プレイヤＰＬ１１０は、ＤＮＳ（「ドメイン名システム」）解決を使用して、またはゲートウェイＧＷ１４０もしくはＬＡＮ１０１内の別のデバイスにおけるデマルチキャスタＤＭ１５０の可用性を検出することを目的とした発見手順からアドレス推定を使用して、コントローラＣＴＲＬ１３０に接触する方法を判定する。この態様は、以下で詳細に取り上げられる。ＡＶライブコンテンツを配信する要求を果たすために、コントローラＣＴＲＬ１３０は、プロバイダネットワークＰＮ１０２内のリソース消費を最適化する目的で、ＡＶライブコンテンツ配信システムのインフラストラクチャおよび実際の動作状態を考慮して実行可能なものに応じて、プレイヤＰＬ１１０を適切なユニキャストサーバ（例えば、コンテンツ配信機器ＣＤＥ１２０の）またはデマルチキャスタＤＭ１５０にリダイレクトする。言い換えれば、コントローラは、マルチキャストからユニキャストへの変換をクライアントに提供することができるように、少なくとも、このようなマルチキャストからユニキャストへの変換をクライアントに提供することができるデマルチキャスタの存在および可用性の有無の指示に従って、標的化されたＡＶライブコンテンツを取得する要求を果たすようにクライアントをリダイレクトする方法を判定する。この態様は、以下でも詳細に取り上げられる。

【0030】

特定の実施形態において、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に設置される。別の特定の実施形態では、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に接続されたセットトップボックスに設置される。このようなセットトップボックスは、ＬＡＮ１０１内にあり、ＬＡＮ１０１を介して、または専用リンクによって、ゲートウェイＧＷ１４０にさらに接続されてもよい。

【0031】

特定の実施形態において、クライアントおよびプレイヤＰＬ１１０は、ゲートウェイＧＷ１４０、またはゲートウェイＧＷ１４０に接続されたセットトップボックスに設置される。デマルチキャスタＤＭ１５０がゲートウェイＧＷ１４０、またはそれに接続されたセットトップボックスにも存在する場合、クライアントおよびプレイヤＰＬ１１０は、デマルチキャスタＤＭ１５０に対して密閉して、存在する場合、コントローラＣＴＲＬ１３０から設置される。つまり、発見手順を実行する前に、クライアントおよびプレイヤＰＬ１１０は、それらがデマルチキャスタＤＭ１５０と同じデバイス内に併設されているかどうかを認識していないことを意味する。

【0032】

図２Ａおよび図２Ｂは、本発明による、ＡＶライブコンテンツ配信システム内で発生する交換を模式的に表す。

【0033】

図２Ａのステップ２００および図２Ｂのステップ２１０において、プレイヤＰＬ１１０は、ゲートウェイＧＷ１４０およびＬＡＮ１０１上の任意の他のデバイスが、当該ゲートウェイＧＷ１４０またはＬＡＮ１０１上の当該他のデバイスが利用可能なデマルチキャスタを埋め込むかどうかをプレイヤＰＬ１１０に通知する必要がある発見手順を開始する。プレイヤＰＬ１１０がゲートウェイＧＷ１４０とは異なるデバイスに埋め込まれると、ＬＡＮ１０１において発見手順が実行される。プレイヤＰＬ１１０が、このようなデマルチキャスタ（ゲートウェイＧＷ１４０など）を埋め込むことができるデバイスによってホストされるときに、発見手順は、プレイヤＰＬ１１０をホストするデバイスのＡＰＩ（「アプリケーションプログラミングインターフェース」）を介してさらに実行される。

【0034】

利用可能なデマルチキャスタは、第１に存在し、第２にアクティブである（すなわち、実行中である）デマルチキャスタを指す。利用可能なデマルチキャスタは、マルチキャストからユニキャストへの変換のための補足的なＡＶライブコンテンツを担当するのに十分なメモリおよび／または処理リソースを有するデマルチキャスタをさらに指してもよい。

【0035】

以下では、プレイヤＰＬ１１０がゲートウェイＧＷ１４０とは異なるデバイスに埋め込まれていること、また、ＬＡＮ１０１のみで発見処理が行われることを例示的に検討する。ＬＡＮ１０１の文脈において本明細書に記載される発見手順原理は、前述のＡＰＩの文脈において必要な修正を加えて適用される。

【0036】

例えば、発見手順は、ＵＰｎＰ（標準文書ＩＳＯ／ＩＥＣ２９３４１で定義されている「Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ｎ’Ｐｌａｙ」）プロトコルでも使用されるＳＳＤＰ（「シンプルサービスディスカバリープロトコル」）プロトコルなどのＳＤＰ（「サービスディスカバリープロトコル」）プロトコルまたはＡｐｐｌｅのＢｏｎｊｏｕｒまたはＤＮＳベースのサービス発見アプローチなどの技術Ｚｅｒｏｃｏｎｆを使用する。例えばゲートウェイＧＷ１４０に位置し、おそらくデマルチキャスタＤＭ１５０によって事前に構成されたローカルＤＮＳサーバは、存在する場合、当該デマルチキャスタＤＭ１５０と関連付けられた所定のドメイン名の解決を可能にする。

【0037】

発見手順の間、プレイヤＰＬ１１０は、デマルチキャスタがゲートウェイＧＷ１４０に存在するかどうか、またはより一般的にＬＡＮ１０１上に存在するかどうか、また、好ましくはデマルチキャスタ（存在する場合）がアクティブであるかどうかを判定するためにＬＡＮ１０１をプローブする。デバイスがこのようなデマルチキャスタをホストする場合、当該デバイスは、問題のデマルチキャスタＤＭ１５０を識別する記述子に応答して伝送する。ゲートウェイＧＷ１４０がデマルチキャスタＤＭ１５０を埋め込むことを考慮すると、したがって、ゲートウェイＧＷ１４０は、デマルチキャスタＤＭ１５０を識別する記述子を応答して伝送する。したがって、記述子は、本質的に、デマルチキャスタＤＭ１５０の存在を指示する。記述子は、デマルチキャスタＤＭ１５０と、おそらくデマルチキャスタＤＭ１５０を設置する際の構成によって定義されるデマルチキャスタＤＭ１５０のローカル名とを接触させるためのアドレスをさらに示す。

【0038】

本明細書で使用される「アドレス（ａｄｄｒｅｓｓ）」という用語は、特にＩＰアドレスおよびポート番号の連結を含むその広義で理解されなければならないことに留意されたい。

【0039】

記述子は、デマルチキャスタＤＭ１５０がアクティブであるかどうかをさらに示してもよい。記述子は、デマルチキャスタＤＭ１５０が、別のＡＶライブコンテンツ配信を受け入れるのに十分なメモリおよび／または処理リソースを有するかどうかをさらに示してもよい。このような情報を記述子に記入するために、デマルチキャスタＤＭ１５０をホストするデバイスは、デマルチキャスタＤＭ１５０がアクティブであること、また、おそらくデマルチキャスタＤＭ１５０が別のＡＶライブコンテンツ配信を受け入れるのに十分なメモリおよび／または処理リソースを有するかどうかを確認するように内部的に要求してもよい。

【0040】

好ましい代替的な実施形態では、記述子は、デマルチキャスタＤＭ１５０ならびにデマルチキャスタＤＭ１５０に接触するためのＩＰアドレスおよびポート番号などのアドレスの存在のみを指示する。次いで、プレイヤＰＬ１１０は、記述子に提供されるアドレスを使用して、デマルチキャスタＤＭ１５０がアクティブであるかどうかを判定するために、デマルチキャスタＤＭ１５０に専用の要求を伝送する。デマルチキャスタＤＭ１５０が当該専用要求に応答すると、プレイヤＰＬ１１０は、デマルチキャスタＤＭ１５０がアクティブであると結論づける。応答するときに、デマルチキャスタＤＭ１５０は、デマルチキャスタＤＭ１５０が別のＡＶライブコンテンツ配信を受け入れるのに十分なメモリおよび／または処理リソースを有するかどうかを指示してもよい。所定のタイムアウト遅延内に専用要求への応答が受信されない場合、プレイヤＰＬ１１０は、デマルチキャスタＤＭ１５０が非アクティブであると結論づける。

【0041】

図２Ａのステップ２０１および図２Ｂのステップ２１１において、プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０に接触するためのアドレスを取得し、コントローラＣＴＲＬ１３０に、１つの特定のＡＶライブコンテンツの配信を要求する要求ＲＥＱ１を伝送する。したがって、要求ＲＥＱ１は、問題のＡＶライブコンテンツを識別するユニキャストメッセージである。例えば、要求ＲＥＱ１は、ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄなどの（ＡＶライブコンテンツがパッケージ化されている形式を考慮して）適切なファイル拡張子を持つテキストファイルへのパスが後に続く、ＦＱＤＮ（「完全修飾ドメイン名」）で構成されるＵＲＬ（「ユニフォームリソースロケータ」）を含むＨＴＴＰ取得メッセージである。

【0042】

要求ＲＥＱ１は、発見後、プレイヤＰＬ１１０がプロバイダネットワークＰＮ１０２にアクセスするゲートウェイが、プレイヤＰＬ１１０のＡＶライブコンテンツ配信を担当することができるデマルチキャスタを埋め込むかどうかを指示する情報をさらに含む。例えば、上記の例を再利用すると、要求ＲＥＱ１は、デマルチキャスタ可用性を示すときに、以下のような情報を明示的に提供するインラインパラメータを含む。
ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ｄｅ－ｍｕｌｔｉｃａｓｔｅｒ＝ＯＮ
デマルチキャスタが利用不可能であることを示す場合、以下の通りである。
ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ｄｅ－ｍｕｌｔｉｃａｓｔｅｒ＝ＯＦＦ

【0043】

別の好ましいアプローチは、要求ＲＥＱ１がこのような情報を暗黙的に含むことである。要求ＲＥＱ１は、代わりに、問題のデマルチキャスタのアドレスまたはそのローカル名を提供するインラインパラメータ（存在する場合）を含む。アドレスが指定されていない場合、利用可能なデマルチキャスタがなく、要求ＲＥＱ１にはこのようなインラインパラメータが含まれておらず、例えば、次のようになる。
ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ
そうでなければ、要求ＲＥＱ１は、例えば以下のように、インラインパラメータとして、当該デマルチキャスタのアドレスまたはローカル名を含む。
ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？
ｄｅ－ｍｕｌｔｉｃａｓｔｅｒ＝１９２．１６８．１．１００：８０００

【0044】

ここで、この例では、１９２．１６８．１．１００：８０００は、デマルチキャスタＤＭ１５０のＩＰアドレスとポート番号の組み合わせである。

【0045】

この好ましいアプローチは、有利には、ＡＶライブコンテンツ配信システムに展開されているすべてのデマルチキャスタのための確立されたローカル名および／またはアドレスのみを有することを回避することを可能にする。

【0046】

要求ＲＥＱ１は、デマルチキャスタが存在する場合、追加のインラインパラメータとして、以下のＦＱＤＮ情報（この例ではｔｖ．ｍｙＩＳＰ．ｃｏｍ）をさらに含んでもよい。
ＨＴＴＰ ＧＥＴ ｔｖ．ｍｙＩＳＰ．ｃｏｍ／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？
ｄｅ－ｍｕｌｔｉｃａｓｔｅｒ＝１９２．１６８．１．１００：８０００＆ＦＱＤＮ＿ｏｒｉｇ＝ ｔｖ．ｍｙＩＳＰ．ｃｏｍ

【0047】

これは、後述の詳細な実施形態で説明される、例えば、アクセス制御の理由およびさらなる態様のために、デマルチキャスタＤＭ１５０にとって有用である。このインラインパラメータは必須ではないことに留意すべきである。存在しない場合、次いで、それは、プレイヤＰＬ１１０をデマルチキャスタＤＭ１５０にリダイレクトするときにコントローラＣＴＲＬ１３０によって追加されてもよい。存在する場合、コントローラＣＴＲＬ１３０には透過的であり、コントローラ１３０は、プレイヤＰＬ１１０をデマルチキャスタＤＭ１５０にダイレクトする必要があるときに、要求ＲＥＱ１のインラインパラメータをコピーする必要があるだけである。

【0048】

図２Ａのステップ２０１では、要求ＲＥＱ１は、プレイヤＰＬ１１０のＡＶライブコンテンツ配信を担当することができるデマルチキャスタがローカルに存在することを指示する情報を含むと考えられる。図２Ｂのステップ２１１において、要求ＲＥＱ１は、プレイヤＰＬ１１０のＡＶライブコンテンツ配信を担当することができるデマルチキャスタがローカルに存在しないことを示す情報を含むと相補的に考えられる。

【0049】

図２Ａのステップ２０２および図２Ｂのステップ２１２では、コントローラＣＴＲＬ１３０は、問題のＡＶライブコンテンツが任意の形式で利用可能であるかどうかをチェックする。コントローラＣＴＲＬ１３０が、問題のＡＶライブコンテンツが任意の形式で利用可能でないと判定すると、コントローラＣＴＲＬ１３０は、例えば、ＨＴＴＰエラー４０４メッセージを返すことによって、要求ＲＥＱ１を拒否する。

【0050】

図２Ａのステップ２０２では、コントローラＣＴＲＬ１３０は、問題のＡＶライブコンテンツがマルチキャスト形式で利用可能であるかどうかをチェックする。コントローラＣＴＲＬ１３０は、例えば、マルチキャスト形式で利用可能なＡＶライブコンテンツのリストを提供するファイルにアクセスする。コントローラＣＴＲＬ１３０が、問題のＡＶライブコンテンツがマルチキャスト形式で利用可能であると判定すると、コントローラＣＴＲＬ１３０は、図２Ａに示すように、プレイヤＰＬ１１０をデマルチキャスタＤＭ１５０にリダイレクトする。そのために、コントローラＣＴＲＬ１３０は、要求ＲＥＱ１に応答して伝送されるリダイレクトメッセージＲＥＤＩＲ１に、要求ＲＥＱ１のインラインパラメータとして提供されるように、デマルチキャスタＤＭ１５０のアドレスまたはローカル名を含むことが好ましい。

【0051】

さらに、プロバイダネットワークＰＮ１０２がアップリンク通信を許可するときに、コントローラＣＴＲＬ１３０は、リダイレクトメッセージＲＥＤＩＲ１に、（例えば、コンテンツ配信機器ＣＤＥ１２０の）プロバイダネットワークＰＮ１０２上のユニキャストＡＶライブコンテンツ配信サーバのアドレス（またはＵＲＬ）をインラインパラメータとして含んでもよい。このようなユニキャストＡＶライブコンテンツ配信サーバは、特に、デマルチキャストＤＭ１５０がマルチキャスト形式で受信したセグメントの中に少なくとも１つの欠落したＡＶライブコンテンツがあることを検出したときに、ユニキャスト形式のセグメントによってマルチキャスト形式で受信したＡＶライブコンテンツセグメントを完了するために、後でデマルチキャストＤＭ１５０によって使用することができる。

【0052】

上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ１は、したがって、例えば以下のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ １９２．１６８．１．１００：８０００／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ＦＱＤＮ＿ｏｒｉｇ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ＆ＣＤＮ＿ｕｎｉｃａｓｔＳｅｒｖｅｒ＝＜ａｄｄｒｅｓｓ ｏｆ ｔｈｅ ｓｅｒｖｅｒ＞

【0053】

コントローラＣＴＲＬ１３０が問題のＡＶライブコンテンツがマルチキャスト形式で利用可能ではないと判定するときに、コントローラＣＴＲＬ１３０は、ＡＶライブコンテンツ配信システムのインフラストラクチャがゲートウェイＧＷ１４０およびＬＡＮ１０１からコンテンツ配信機器ＣＤＥ１２０へのアップリンク通信を可能にする場合、また、このようなユニキャストＡＶライブコンテンツ配信サーバがプロバイダネットワークＰＮ１０２内（例えば、コンテンツ配信機器ＣＤＥ１２０内）に存在する場合、プレイヤＰＬ１１０を（例えば、コンテンツ配信機器ＣＤＥ１２０の）プロバイダネットワークＰＮ１０２上のユニキャストＡＶライブコンテンツ配信サーバにリダイレクトする。したがって、プレイヤＰＬ１１０は、図２Ｂに示すように、ゲートウェイＧＷ１４０またはＬＡＮ１０１の任意の他のデバイスにデマルチキャスタが存在しないかのように、同じ方法でリダイレクトされる。

【0054】

コントローラＣＴＲＬ１３０が、問題のＡＶライブコンテンツがマルチキャスト形式で利用可能であるかどうかを判定することができないときに、コントローラＣＴＲＬ１３０は、デマルチキャスタＤＭ１５０にこのようなチェックを最後に実行させる。この場合、コントローラＣＴＲＬ１３０は、リダイレクトメッセージＲＥＤＩＲ１のインラインパラメータとして、問題のユニキャストＡＶライブコンテンツ配信サーバのアドレス（またはＵＲＬ）を指示することが好ましい。

【0055】

次いで、リダイレクトメッセージＲＥＤＩＲ１の各インラインパラメータは、リダイレクト中にプレイヤＰＬ１１０によってデマルチキャスタＤＭ１５０に提供され、したがって、デマルチキャスタＤＭ１５０は、必要に応じてユニキャストＡＶライブコンテンツ配信サーバのアドレスを識別することを可能にする。この態様は、図８に示される特定のインフラストラクチャの実施形態の文脈において図９Ａおよび図９Ｂで取り上げられるが、同じ原理は、図４に示される特定のインフラストラクチャの実施形態の文脈においても（すなわち、プロバイダネットワークＰＮ１０２がアップリンク通信を可能にする限り）適用される。

【0056】

特定の実施形態では、プレイヤＰＬ１１０をデマルチキャスタＤＭ１５０にリダイレクトするリダイレクトメッセージＲＥＤＩＲ１は、例えば、修復ユニキャストサーバのアドレス（存在する場合）、および／またはコントローラＣＴＲＬ１３０によって既知の場合、問題のＡＶライブコンテンツの様々な表現のマルチキャストアドレスなどの他のインラインパラメータをさらに含む。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ１は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ １９２．１６８．１．１００：８０００／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ＦＱＤＮ＿ｏｒｉｇ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ＆ＣＤＮ＿ｕｎｉｃａｓｔＳｅｒｖｅｒ＝＜ａｄｄｒｅｓｓ ｏｆ ｔｈｅ ｓｅｒｖｅｒ＞
＆ｒｅｐａｉｒ＝１７２．１６．２５４．１：８０

【0057】

ここで、１７２．１６．２５４．１：８０は、問題の修復ユニキャストサーバに割り当てられたＩＰアドレスとポート番号の組み合わせである。

【0058】

ここで、図２Ｂのステップ２１２を参照すると、コントローラＣＴＲＬ１３０は、問題のＡＶライブコンテンツがユニキャスト形式で利用可能であるかどうかをチェックする。コントローラＣＴＲＬ１３０は、例えば、ユニキャスト形式で利用可能なＡＶライブコンテンツのリストを提供するファイルにアクセスする。コントローラＣＴＲＬ１３０が問題のＡＶライブコンテンツがユニキャスト形式で利用可能ではないと判定するときに、コントローラＣＴＲＬ１３０は、ＡＶライブコンテンツ配信システムのインフラストラクチャがＬＡＮ１０１からコンテンツ配信機器ＣＤＥ１２０へのアップリンク通信を可能にする場合、また、このようなユニキャストＡＶライブコンテンツ配信サーバがプロバイダネットワークＰＮ１０２内（例えば、コンテンツ配信機器ＣＤＥ１２０内）に存在する場合、プレイヤＰＬ１１０を（例えば、コンテンツ配信機器ＣＤＥ１２０の）プロバイダネットワークＰＮ１０２上のユニキャストＡＶライブコンテンツ配信サーバにリダイレクトする。そのために、コントローラＣＴＲＬ１３０は、要求ＲＥＱ１に応答して送信されるリダイレクトメッセージＲＥＤＩＲ１に、問題のユニキャストＡＶライブコンテンツ配信サーバのアドレスを含むことが好ましい。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ１は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ １７２．１６．２４８．３：８０／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ

【0059】

ここで、１７２．１６．２４８．３：８０は、問題のユニキャストＡＶライブコンテンツ配信サーバのＩＰアドレスとポート番号の組み合わせである。

【0060】

そうでなければ、コントローラＣＴＲＬ１３０は、例えば、ＨＴＴＰエラー４０４メッセージを返すことによって、要求ＲＥＱ１を拒否する。

【0061】

図２Ａのステップ２０３および図２Ｂのステップ２１３において、プレイヤＰＬ１１０は、リダイレクトメッセージＲＥＤＩＲ１に含まれる命令に従って、別の要求ＲＥＱ２を伝送する。したがって、要求ＲＥＱ２は、コントローラＣＴＲＬ１３０が最初に要求した以外のサーバから問題のＡＶライブコンテンツの配信を要求する。図２Ａのステップ２０３では、プレイヤＰＬ１１０は、要求ＲＥＱ２をデマルチキャスタＤＭ１５０に伝送する。

【0062】

図２Ｂのステップ２１３では、プレイヤＰＬ１１０は、要求ＲＥＱ２をユニキャストＡＶライブコンテンツ配信サーバに伝送する。

【0063】

したがって、プレイヤＰＬ１１０は、問題のＡＶライブコンテンツを受信する。図２Ａのステップ２０５において、ステップ２０４においてコンテンツ配信機器ＣＤＥ１２０から受信された伝送の中継として機能するデマルチキャスタＤＭ１５０からユニキャスト形式でＡＶライブコンテンツを受信するか、または図２Ｂのステップ２１４において、ユニキャストＡＶライブコンテンツ配信サーバ（例えば、コンテンツ配信機器ＣＤＥ１２０）からユニキャスト形式で、すなわち、デマルチキャスタＤＭ１５０を介して通過することなく、ＡＶライブコンテンツを受信するかのいずれかである。

【0064】

ステップ２０４および２０５では、プロバイダネットワーク１０２がアップリンク通信を許可するときに、要求されたＡＶライブコンテンツセグメントは、コンテンツ配信機器ＣＤＥ１２０のマルチキャスタから以前にマルチキャスト形式で受信されたように、デマルチキャスタＤＭ１５０に存在し、デマルチキャスタＤＭ１５０は、要求されたＡＶライブコンテンツセグメントをプレイヤＰＬ１１０に返すことができるか、またはセグメントが欠落している場合、デマルチキャスタＤＭ１５０は、ユニキャストＡＶライブコンテンツ配信サーバからコンテンツを要求することができる。

【0065】

上述のアプローチのおかげで、コントローラＣＴＲＬ１３０は、ゲートウェイＧＷ１４０またはＬＡＮ１０１内の任意の他のデバイスがこのようなデマルチキャスタを実装しているかどうか、また、このデマルチキャスタがＡＶライブコンテンツ配信要求を果たすためにプレイヤＰＬ１１０を担当することができるかどうかを動的に判定する。実際、デマルチキャスタは存在し得るが、非アクティブであり、つまり、この場合、プレイヤＰＬ１１０をデマルチキャスタにリダイレクトすることは、少なくともプレイヤＰＬ１１０のＱｏＥ（「経験の質」）の観点から有意な無駄な待ち時間を暗示するので不十分であることを意味する。

【0066】

このアプローチは、図４、図６、図８、および図１０の特定のインフラストラクチャ実施形態で後述するように、コントローラＣＴＲＬ１３０の有効位置に関して柔軟であり、このような有効位置は、プレイヤＰＬ１１０（すなわち、クライアント）実装に影響を及ぼさない。さらに、アプローチは、ゲートウェイＧＷ１４０およびＬＡＮ１０１から当該プロバイダネットワーク（例えば、ブロードキャストネットワーク）を介してアップリンク通信能力を有しないプロバイダネットワーク、ならびに、このようなアップリンク通信能力を有するプロバイダネットワークをサポートするのに十分に柔軟である。アプローチが適応ストリーミングに十分であることにさらに気づくことができ、したがって、様々な対応するビットレート（または解決）で符号化されたＡＶライブコンテンツの異なる代替バージョン（または表現）の可用性からユーザが利益を得ることが可能になる。

【0067】

図３は、ＡＶライブコンテンツ配信システムのデバイスの例示的なハードウェアアーキテクチャを模式的に表す。デマルチキャスタＤＭ１５０および／またはコントローラＣＴＲＬ１３０および／またはゲートウェイＧＷ１４０および／またはプレイヤＰＬ１１０および／またはコンテンツ配信機器ＣＤＥ１２０の任意の他のサーバは、このような例示的なハードウェアアーキテクチャの周りに構築されてもよい。図３が、コントローラＣＴＲＬ１３０のハードウェアアーキテクチャを表すことを例示的に考えてみる。

【0068】

示される例示的なハードウェアアーキテクチャによれば、コントローラＣＴＲＬ１３０は、通信バス３１０によって相互接続された以下の構成要素：プロセッサ、マイクロプロセッサ、マイクロコントローラ、またはＣＰＵ（「中央処理ユニット」）３０１、ラム（「ランダムアクセスメモリ」）３０２、ＲＯＭ（「読み取り専用メモリ」）３０３またはＥＥＰＲＯＭ（「電気的に消去可能なＲＯＭ」）もしくはフラッシュメモリ、ハードディスクドライブ、またはＳＤ（「セキュアデジタル」）カードリーダ３０４などの非一過性記憶媒体に記憶された情報を読み取るように適合された任意の他のデバイス、ＬＡＮ１０１および／またはプロバイダネットワークＰＮ１０２を介して通信することを可能にする少なくとも１つの通信インターフェースＣＯＭ３０５を備える。

【0069】

ＣＰＵ３０１は、ＲＯＭ３０３またはＳＤカードなどの外部メモリからラム３０２にロードされた命令を実行することができる。コントローラＣＴＲＬ１３０の電源が入った後、ＣＰＵ３０１は、ラム３０２から命令を読み取り、これらの命令を実行することができる。命令は、ＣＰＵ３０１にコントローラＣＴＲＬ１３０に関して本明細書に記載されるステップを実行させる１つのコンピュータプログラムを形成する。

【0070】

本明細書に記載されるステップは、ＰＣ（「パーソナルコンピュータ」）、ＤＳＰ（「デジタル信号プロセッサ」）もしくはマイクロコントローラなどのプログラマブルコンピューティングマシンによる命令またはプログラムのセットの実行によって、またはそれ以外の場合、ＦＰＧＡ（「フィールドプログラマブルゲートアレイ」）もしくはＡＳＩＣ（「アプリケーション固有の集積回路」）などのマシンもしくは専用構成要素によってハードウェア形式で実装されてもよいことに留意されたい。より一般的に、ＡＶライブコンテンツ配信システムの任意のデバイスは、問題のデバイスに関して本明細書に記載されるような関連するステップを実装するように適合され、構成された処理電子回路を含む。

【0071】

図４は、ＡＶライブコンテンツ配信システムの第１の実施形態を模式的に表し、コントローラＣＴＲＬ１３０は、プロバイダネットワークＰＮ１０２に位置するか、またはプロバイダネットワークＰＮ１０２に接続されている、すなわち、プレイヤＰＬ１１０の観点からゲートウェイＧＷ１４０を越えている。図４では、ドメイン名を解決するためのプロバイダネットワークＰＮ１０２におけるＤＮＳサーバ１６１をさらに示す。また、図４のコンテンツ配信機器ＣＤＥ１２０は、マルチキャスタまたはマルチキャストサーバＭＳ１２１、および前述の修復ユニキャストサーバＲＵＳ１２２を示している。修復ユニキャストサーバＲＵＳ１２２は、マルチキャストサーバＭＳ１２１と併設され、すなわち、同じマシン上に物理的に配置されてもよい。修復ユニキャストサーバＲＵＳ１２２は、欠落したＡＶライブコンテンツセグメントを、通常は、マルチキャスト動作（例えば、ＲＴＰまたはＦＬＵＴＥ／ＡＬＣ）に使用される転送プロトコルに応じて選択された標準化された通信プロトコルを通じて回復させるための機構を実装する。コンテンツ配信機器ＣＤＥ１２０は、既に呼び出されているように、他のサーバを含んでもよい。

【0072】

特定の特徴によれば、修復ユニキャストサーバＲＵＳ１２２は、問題のＡＶライブコンテンツのそれぞれの様々な表現のためにマルチキャストサーバＭＳ１２１によって供給される様々なマルチキャストストリームに参加することによって、ＡＶライブコンテンツのセグメントを取得する。修復ユニキャストサーバＲＵＳ１２２は、当該マルチキャストストリームの所定のライフタイムパケット中に記憶し、潜在的なセグメント損失を補償するために、デマルチキャスタＤＭ１５０からの修復要求を提供する。例えば、修復ユニキャストサーバＲＵＳ１２２は、データ損失検出を容易に可能にするマルチキャストサーバＭＳ１２１によって伝送されるＲＴＰパケット内の連続性カウンタに基づいて、ＲＴＰ再試行（規範文書ＲＦＣ４５８８に定義されるように）に依存することによって修復サービスを提供する。

【0073】

図４において、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に埋め込まれる。既に言及したように、デマルチキャスタＤＭ１５０は、変形例において、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。

【0074】

図５Ａおよび図５Ｂは、図４に示されるＡＶライブコンテンツ配信システムの第１の実施形態で発生する交換を模式的に表す。

【0075】

図５Ａのステップ５００および図５Ｂのステップ５１０において、プレイヤＰＬ１１０は、図２Ａのステップ２００および図２Ｂのステップ２１０に関して既に説明したように、ＬＡＮ１０１において（および／またはＡＰＩを通じて）発見手順を実行する。

【0076】

コントローラＣＴＲＬ１３０に接触するためのアドレスを取得するために、プレイヤＰＬ１１０は、ＤＮＳサーバ１６１にドメイン名解決を要求する。ＤＮＳサーバ１６１に接触するアドレスは、プレイヤＰＬ１１０が、ゲートウェイＧＷ１４０が管理するＬＡＮ１０１に正常に登録されたときに、プレイヤＰＬ１１０のゲートウェイＧＷ１４０によって構成されている。ＤＮＳサーバ１６１に接触するためのアドレスは、代替的に、プレイヤＰＬ１１０を設置するときに、ユーザによって手動で構成されてもよい。したがって、図５Ａのステップ５０１および図５Ｂのステップ５１１において、プレイヤＰＬ１１０は、要求ＲＥＱ０をＤＮＳサーバ１６１に伝送する。要求ＲＥＱ０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍの解決を要求する。ＤＮＳサーバ１６１はドメイン名解決を実行し、したがってプロバイダネットワークＰＮ１０２内のコントローラＣＴＲＬ１３０のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレス：７２．６８．１８．１４につながる。

【0077】

図５Ａのステップ５０２および図５Ｂのステップ５１２において、ＤＮＳサーバ１６１は、応答メッセージＲＥＳＰ０においてコントローラＣＴＲＬ１３０の検索されたアドレスをプレイヤＰＬ１１０に返す。したがって、プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０に接触することができる。

【0078】

図５Ａでは、その後に行われるステップ５０３～５０７は、それぞれ、図２Ａのステップ２０１～２０５とそれぞれ同一である。また、図５Ｂにおいて、その後に行われるステップ５１３～５１６は、図２Ｂのステップ２１１～２１４とそれぞれ同一である。

【0079】

デマルチキャストＤＭ１５０がコンテンツ配信機器ＣＤＥ１２０からＡＶライブコンテンツのセグメントを取得する図５Ａのステップ５０６を考慮すると、デマルチキャストＤＭ１５０は、マルチキャストサーバＭＳ１２１によって供給され、プレイヤＰＬ１１０によって要求されたＡＶライブコンテンツの表現に対応するマルチキャストストリームを利用する。デマルチキャスタＤＭ１５０がセグメント損失に直面すると、デマルチキャスタＤＭ１５０は、受信したマルチキャストストリームの潜在的なセグメント損失にもかかわらず、プレイヤＰＬ１１０にＡＶライブコンテンツセグメントを連続的に提供し、したがって、ＱｏＥを改善するために、問題の失われたセグメントを修復ユニキャストサーバＲＵＳ１２２からユニキャスト形式で要求する。プロバイダネットワークＰＮ１０２は、ゲートウェイＧＷ１４０およびＬＡＮ１０１からコンテンツ配信機器ＣＤＥ１２０へのアップリンク通信を構造的に可能にするため、図４に示すＡＶライブコンテンツ配信システムの第１の実施形態では、このような修復から利益を得ることが可能である。修復サーバＲＵＳ１２２に依存することは、通常は再伝送機構を有さない転送プロトコル（ＵＤＰなど）を使用して伝送されるマルチキャストパケットの損失がある場合に特に有用である。セグメント損失が連続した正しく受信されたマルチキャストパケットの間の欠落したセグメントに起因する場合、デマルチキャスタＤＭ１５０は、欠落したセグメントをユニキャストＡＶライブコンテンツ配信サーバから要求してもよい。

【0080】

図６は、ＡＶライブコンテンツ配信システムの第２の実施形態を模式的に表し、コントローラＣＴＲＬ１３０はゲートウェイＧＷ１４０またはＬＡＮ１０１内の別のデバイスにも位置する。図６において、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に埋め込まれる。既に言及したように、デマルチキャスタＤＭ１５０は、変形例において、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。さらに、図６では、コントローラＣＴＲＬ１３０は、デマルチキャスタＤＭ１５０と、すなわち、ゲートウェイＧＷ１４０内に併設される。コントローラＣＴＲＬ１３０は、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。

【0081】

ドメイン名を解決するためのローカルＤＮＳ（ＬＤＮＳ）サーバ１６２を図６にさらに示す。ＬＤＮＳサーバ１６２は、図６のゲートウェイＧＷ１４０に位置するが、ＬＡＮ１０１の別のデバイスに位置してもよい。プロバイダネットワークＰＮ１０２はブロードキャスト型のネットワークであるため、コンテンツ配信機器ＣＤＥに対してＬＡＮ１０１やゲートウェイＧＷ１４０からのアップリンク通信を行うことはできない。したがって、ゲートウェイＧＷ１４０によってアクセス可能なコンテンツ配信機器ＣＤＥ内のサーバおよびＬＡＮ１０１内の任意の他のデバイスは、マルチキャストサーバＭＳ１２１などのマルチキャストサーバのみであり、ダウンリンク通信のためにのみであり得る。このようなコンテキストブロードキャストプロバイダネットワークサーバでは、各デマルチキャスタは、どのＡＶコンテンツライブストリーム（例えば、テレビチャネル）を効果的に受信し、処理するかを選択するため、したがって、マルチキャスト伝送を指す（ブロードキャスト伝送は、すべてのデマルチキャストが同じデータを受信することにつながるため）ため、本明細書ではマルチキャストサーバと見なされることに留意されたい。

【0082】

図７は、図６に示されるＡＶライブコンテンツ配信システムの第２の実施形態で発生する交換を模式的に表す。

【0083】

ステップ７０１において、プレイヤＰＬ１１０は、図２Ａのステップ２００に関して既に説明したように、ＬＡＮ１０１（および／またはＡＰＩを介して）において発見手順を実行する。

【0084】

コントローラＣＴＲＬ１３０に接触するためのアドレスを取得するために、プレイヤＰＬ１１０は、ＬＤＮＳサーバ１６２にドメイン名解決を要求する。ＬＤＮＳサーバ１６２に接触するアドレスは、プレイヤＰＬ１１０が、ゲートウェイＧＷ１４０が管理するＬＡＮ１０１に正常に登録されたときに、プレイヤＰＬ１１０のゲートウェイＧＷ１４０によって構成されている。ＬＤＮＳサーバ１６２に接触するためのアドレスは、代替的に、プレイヤＰＬ１１０を設置するときに、特にＬＤＮＳサーバ１６２がＬＡＮ１０１内の別のデバイスに位置するときに、ユーザによって手動で構成されてもよい。したがって、ステップ７０２において、プレイヤＰＬ１１０は、要求ＲＥＱ０をＬＤＮＳサーバ１６２に伝送する。要求ＲＥＱ０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍの解決を要求する。ＬＤＮＳサーバ１６２はドメイン名解決を実行し、コントローラＣＴＲＬ１３０のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレスおよびポート番号：１９２．１６８．１．１００：８００１につながる。

【0085】

ＬＤＮＳサーバ１６２がドメイン名解決を実行し、コントローラＣＴＲＬ１３０のアドレスを検索できるようにＬＤＮＳサーバ１６２を構成することは、好ましくは、デマルチキャスタＤＭ１５０がゲートウェイＧＷ１４０に正常に設置されたときに、ＬＤＮＳサーバ１６２にステップ７００で、問題のＡＶライブコンテンツのＵＲＬのＦＱＤＮとコントローラＣＴＲＬ１３０に接触するためのアドレスとの間の関連付けを提供する構成メッセージＣＯＮＦ１を伝送することによって、デマルチキャスタＤＭ１５０によって実行される。したがって、このようなメッセージは、デマルチキャスタＤＭ１５０がゲートウェイＧＷ１４０によってホストされるときに、ゲートウェイＧＷ１４０の内部にある。代替的に、ＬＤＮＳサーバ１６２は、デマルチキャスタＤＭ１５０およびコントローラＣＴＲＬ１３０を設置するときにユーザによって手動で含む任意の他の手段によって構成されてもよい。

【0086】

デマルチキャスタＤＭ１５０およびコントローラＣＴＲＬ１３０が同じマシン（例えばゲートウェイＧＷ１４０）内に併設されている特定の実施形態では、ＬＤＮＳサーバ１６２によって実行されるドメイン名解決は、ＩＰエイリアシングと称されるデマルチキャスタＤＭ１５０に接触するために使用されるものとは異なるＩＰアドレスにつながってもよい。これは、ゲートウェイＧＷ１４０の他の構成要素とのポート番号割り当てにおける競合解決を容易にするために特に有用である。

【0087】

ステップ７０３では、ＬＤＮＳサーバ１６２は、応答メッセージＲＥＳＰ０においてコントローラＣＴＲＬ１３０の検索されたアドレスをプレイヤＰＬ１１０に返す。したがって、プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０に接触することができる。

【0088】

デマルチキャスタＤＭ１５０およびコントローラＣＴＲＬ１３０が同じマシン（例えば、ゲートウェイＧＷ１４０）内に併設されている特定の変形例の特徴によれば、プレイヤＰＬ１１０は、ドメイン名解決に依存せずにコントローラＣＴＲＬ１３０に接触するためのアドレスを判定する。この状況は、ＬＡＮ１０１にローカルＤＮＳサーバがない場合、または、コントローラＣＴＲＬ１３０がこのようなローカルＤＮＳサーバの設定を許可していない場合に発生する可能性がある。プレイヤＰＬ１１０は、この特定の変形例の特徴に従って、コントローラＣＴＲＬ１３０が同じマシン内（例えば、ゲートウェイＧＷ１４０内）のデマルチキャスタＤＭ１５０と併設されていることを構成によって認識する。したがって、コントローラＣＴＲＬ１３０は、発見手順でデマルチキャスタＤＭ１５０のアドレスを取得した後、デマルチキャスタＤＭ１５０に割り当てられたポート番号に所定の置換ルールを適用することにより、デマルチキャスタＤＭ１５０のアドレスからコントローラＣＴＲＬ１３０のアドレスを導出する。例えば、コントローラＣＴＲＬ１３０は、コントローラＣＴＲＬ１３０のアドレスのポート番号を取得するために、デマルチキャスタＤＭ１５０のアドレスのポート番号を１ユニットずつ増やす。

【0089】

図７では、その後に行われるステップ７０４～７０８は、それぞれ、図２Ａのステップ２０１～２０５とそれぞれ同一である。ここで、図５Ａとは逆に、図６のＡＶライブコンテンツ配信システムの第２の実施形態の文脈においてアップリンク通信を実行することは不可能であるため、デマルチキャスタＤＭ１５０は、ステップ７０７の任意のユニキャストサーバからここで利益を得ることができないことに留意されたい。

【0090】

図８は、図４および図６に関して上述した第１および第２の実施形態のハイブリッド組み合わせである、ＡＶライブコンテンツ配信システムの第３の実施形態を模式的に表す。図８において、コントローラＣＴＲＬ１３０はまた、ゲートウェイＧＷ１４０またはＬＡＮ１０１内の別のデバイスに位置する。図８において、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に埋め込まれる。既に言及したように、デマルチキャスタＤＭ１５０は、変形例において、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。さらに、図８では、コントローラＣＴＲＬ１３０は、デマルチキャスタＤＭ１５０と、すなわちゲートウェイＧＷ１４０内に併設される。コントローラＣＴＲＬ１３０は、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。しかしながら、図８において、プロバイダネットワークＰＮ１０２は、図４の第１の実施形態のように、アップリンク通信を可能にする。したがって、図６のコンテンツ配信機器ＣＤＥ１２０は、マルチキャスタまたはマルチキャストサーバＭＳ１２１および修復ユニキャストサーバＲＵＳ１２２を示している。

【0091】

図６のコンテンツ配信機器ＣＤＥ１２０は、コンテンツ配信ネットワークサーバＣＤＮＳ１２３をさらに含む。サーバＣＤＮＳ１２３は、コンテンツ配信機器ＣＤＥ１２０のマルチキャスト能力を認識せず、例えば、ＡＶライブコンテンツをユニキャスト形式で要求することができるサードパーティのサーバである。サーバＣＤＮＳ１２３は、コンテンツ配信機器ＣＤＥ１２０とは異なる権限ドメインにあってもよいため、コンテンツ配信機器ＣＤＥ１２０から分離されてもよい。ＡＶライブコンテンツ配信のために接触されると、サーバＣＤＮＳ１２３は、効果的なＡＶライブコンテンツ配信のためにプロバイダネットワークＰＮ１０２内の別のサーバへのリダイレクトを実行してもよいことに留意されたい。図４および図６にそれぞれ既に示されているＤＮＳサーバ１６１およびＬＤＮＳサーバ１６２をさらに図８に示す。ＬＤＮＳサーバ１６２は、図８のゲートウェイＧＷ１４０に位置するが、ＬＡＮ１０１の別のデバイスに位置してもよい。

【0092】

図９Ａおよび図９Ｂは、図８に示されるＡＶライブコンテンツ配信システムの第３の実施形態で発生する交換を模式的に表す。

【0093】

ＬＤＮＳサーバ１６２は、図７に関して既に説明したように構成されている。したがって、デマルチキャスタＤＭ１５０は、好ましくは、構成メッセージＣＯＮＦ１を介してステップ９００において、プレイヤＰＬ１１０がドメイン名解決によってコントローラＣＴＲＬ１３０に接触するためのアドレスを取得することを可能にするように、ＬＤＮＳサーバ１６２を構成してもよい。図７に関して説明したように、変形例は、コントローラＣＴＲＬ１３０とデマルチキャスタＤＭ１５０が同じマシン内に併設されているときの発見手順中に取得されたデマルチキャスタＤＭ１５０のアドレス（ポート番号）からコントローラＣＴＲＬ１３０のアドレス（ポート番号）を導出するプレイヤＰＬ１１０からなる。

【0094】

図９Ａのステップ９０１および図９Ｂのステップ９１１において、プレイヤＰＬ１１０は、図２Ａのステップ２００および図２Ｂのステップ２１０に関して既に説明したように、ＬＡＮ１０１において（および／またはＡＰＩを通じて）発見手順を実行する。

【0095】

図９Ａのステップ９０２および図９Ｂのステップ９１２において、プレイヤＰＬ１１０は、要求ＲＥＱ０をＬＤＮＳサーバ１６２に伝送する。要求ＲＥＱ０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍの解決を要求する。ＬＤＮＳサーバ１６２はドメイン名解決を実行し、コントローラＣＴＲＬ１３０のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレスおよびポート番号：１９２．１６８．１．１００：８００１につながる。

【0096】

図９Ａのステップ９０３および図９Ｂのステップ９１３では、ＬＤＮＳサーバ１６２は、応答メッセージＲＥＳＰ０のコントローラＣＴＲＬ１３０の検索されたアドレスをプレイヤＰＬ１１０に返す。したがって、プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０に接触することができる。

【0097】

図９Ａでは、その後に行われるステップ９０４～９０６は、図２Ａのステップ２０１～２０３とそれぞれ同一である。

【0098】

図９Ａにおいて、その後に行われるステップ９０９ａおよび９０９ｂは、図２Ａのステップ２０４および２０５とそれぞれ同一である。ここで、図７とは逆に、図８のＡＶライブコンテンツ配信システムの第３の実施形態の文脈においてアップリンク通信を実行することが可能であるため、デマルチキャスタＤＭ１５０は、ステップ９０９ｂにおける修復ユニキャストサーバＲＵＳ１２２および／またはサーバＣＤＮＳ１２３から利益を得ることができることに留意されたい。デマルチキャスタＤＭ１５０がサーバＣＤＮＳ１２３から利益を得ることができるようにするために、コントローラＣＴＲＬ１３０は、リダイレクトメッセージＲＥＤＩＲ１に、要求ＲＥＱ１に指示されれるように、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍを提供するインラインパラメータを含む。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ１は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ １９２．１６８．１．１００：８０００／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ＦＱＤＮ＿ｏｒｉｇ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ＆ＣＤＮ＿ｕｎｉｃａｓｔＳｅｒｖｅｒ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ

【0099】

これは、サーバＣＤＮＳ１２３がコントローラＣＴＲＬ１３０およびデマルチキャスタＤＭ１５０と比較してサードパーティによって管理される場合に特に有用である。ステップ９０６で要求ＲＥＱ２を受信するデマルチキャスタＤＭ１５０は、ＤＮＳサーバ１６１によるドメイン名解決を強制し、ＬＤＮＳサーバ１６２（存在する場合）がドメイン名解決によって標的化されることを回避するために、デマルチキャスタＤＭ１５０と同じマシンに、当該デマルチキャスタＤＭ１５０と併せて設置されたＤＮＳクライアントエージェントのサービスを使用してもよい。

【0100】

要求ＲＥＱ１に指示されるように当該ＦＱＤＮを提供するインラインパラメータから、デマルチキャスタＤＭ１５０は、それに応じてドメイン名解決を要求し、メッセージＲＥＱ３をステップ９０７で伝送する。ＤＮＳサーバ１６１は、要求ＲＥＱ３を処理し、ドメイン名解決を実行し、したがって、サーバＣＤＮＳ１２３のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレス：７２．３６．５３．１８につながる。そして、ステップ９０８において、ＤＮＳサーバ１６１は、応答メッセージＲＥＳＰ３においてサーバＣＤＮＳ１２３の検索されたアドレスをデマルチキャスタＤＭ１５０に返す。したがって、デマルチキャスタＤＭ１５０は、必要に応じて（例えば、欠落したＡＶライブコンテンツセグメントを取得するために）サーバＣＤＮＳ１２３に接触するためにそのアドレスを操作することができる。

【0101】

図９Ｂにおいて、その後に行われるステップ９１４は、図２Ｂのステップ２１１と同一である。ここで、コントローラＣＴＲＬ１３０は、プレイヤＰＬ１１０によって要求されたＡＶライブコンテンツがマルチキャスト形式で利用可能であるかどうかを指示する情報を有していないと考えられる。同じマシン内に（例えば、ゲートウェイＧＷ１４０内に）併設される場合でも、コントローラＣＴＲＬ１３０およびデマルチキャスタＤＭ１５０は、互いに存在を認識しない。それらを相互作用させることは可能であろうが、それらの間の気密性を維持することは、当該コントローラＣＴＲＬ１３０が、ゲートウェイＧＷ１４０またはプロバイダネットワークＰＮ１０２に位置するときに異なる動作をしないため、コントローラＣＴＲＬ１３０の開発を簡素化する。次に、コントローラＣＴＲＬ１３０は、プレイヤＰＬ１１０によって要求されたＡＶライブコンテンツがマルチキャスト形式で利用可能であるかどうかをデマルチキャスタＤＭ１５０にチェックさせる。プレイヤＰＬ１１０によって要求されたＡＶライブコンテンツがマルチキャスト形式で利用可能である場合、交換は、図９Ａに示されるように続く。そうでなければ、デマルチキャスタＤＭ１５０は、プレイヤＰＬ１１０をサーバＣＤＮＳ１２３にリダイレクトする必要がある。

【0102】

プレイヤＰＬ１１０をサーバＣＤＮＳ１２３にリダイレクトするために、デマルチキャスタＤＭ１５０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮの解決を要求する必要がある。実際、先行するドメイン名解決は、プレイヤＰＬ１１０をコントローラＣＴＲＬ１３０に向け、無限ループにつながるため、現状では不便であろう。したがって、ステップ９１７において、デマルチキャスタＤＭ１５０は、要求ＲＥＱ３をＤＮＳサーバ１６１に伝送する。要求ＲＥＱ３は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍの解決を要求し、これは、ステップ９１５でリダイレクトメッセージＲＥＤＩＲ１のインラインパラメータとしてコントローラＣＴＲＬ１３０によって提供されていなければならない可能性がある。デマルチキャスタＤＭ１５０は、ＤＮＳサーバ１６１による解決を強制し、ＬＤＮＳサーバ１６２（存在する場合）がドメイン名解決によって標的化されることを回避するために、デマルチキャスタＤＭ１５０と同じマシンに、当該デマルチキャスタＤＭ１５０と併せて設置されたＤＮＳクライアントエージェントのサービスを使用してもよい。

【0103】

ＤＮＳサーバ１６１はドメイン名解決を実行し、サーバＣＤＮＳ１２３のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレス：７２．３６．５３．１８につながる。次いで、ステップ９１８において、ＤＮＳサーバ１６１は、応答メッセージＲＥＳＰ３においてサーバＣＤＮＳ１２３の検索されたアドレスをデマルチキャスタＤＭ１５０に返す。したがって、デマルチキャスタＤＭ１５０は、サーバＣＤＮＳ１２３のアドレスをプレイヤＰＬ１１０に提供することができる。

【0104】

ステップ９１９において、デマルチキャスタＤＭ１５０は、要求ＲＥＱ２に応答してリダイレクトメッセージＲＥＤＩＲ２をプレイヤＰＬ１１０に伝送する。リダイレクトメッセージＲＥＤＩＲ２は、対応するＦＱＤＮの代わりにサーバＣＤＮＳ１２３のアドレスを含む。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ２は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ ７２．３６．５３．１８：８０／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ

【0105】

ここで、サーバＣＤＮＳ１２３のＩＰアドレスの後にデフォルトのポート番号（‘８０’）が続く。

【0106】

ステップ９２０において、プレイヤＰＬ１１０は、リダイレクトメッセージＲＥＤＩＲ２に含まれる命令に従って、別の要求ＲＥＱ４を伝送する。したがって、要求ＲＥＱ４は、サーバＣＤＮＳ１２３から問題のＡＶライブコンテンツの配信を要求する。ステップ９２１において、プレイヤＰＬ１１０は、サーバＣＤＮＳ１２３から（すなわち、デマルチキャスタＤＭ１５０を介して通過することなく）ユニキャスト形式のＡＶライブコンテンツを受信する。

【0107】

図１０は、図８に関して上述した第３の実施形態に由来する、ＡＶライブコンテンツ配信システムの第４の実施形態を模式的に表す。図１０において、デマルチキャスタＤＭ１５０は、ゲートウェイＧＷ１４０に埋め込まれる。既に言及したように、デマルチキャスタＤＭ１５０は、変形例において、ＬＡＮ１０１内の別のデバイスに区別なく埋め込まれてもよい。図１０において、コントローラＣＴＲＬ１３０は、プロバイダネットワークＰＮ１０２に位置するか、プロバイダネットワークＰＮ１０２に接続されている、すなわち、プレイヤＰＬ１１０の観点からゲートウェイＧＷ１４０を越えている。図１０において、ＬＤＮＳサーバ１６２は、ゲートウェイＧＷ１４０に存在するが、ＬＡＮ１０１内の別のデバイスに位置してもよい。

【0108】

このような構成によって提起される問題は、特にＡＶライブコンテンツがマルチキャスト形式で利用可能でない場合のドメイン名解決にある。プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツがマルチキャスト形式で利用可能であるときに、コントローラＣＴＲＬ１３０がプレイヤＰＬ１１０の観点からゲートウェイＧＷ１４０を越えて位置していることを除いて、交換は図９Ａに関して既に説明したように実行される。したがって、簡略化のために、以下で詳細に説明する図１１は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツがマルチキャスト形式で利用可能ではなく、プロバイダネットワークＰＮ１０２を介してマルチキャスト機能を認識していないサーバＣＤＮＳ１２３からユニキャスト形式で提供されなければならない状況にのみ焦点を当てる。

【0109】

図１１は、図１０に示されるＡＶライブコンテンツ配信システムの第４の実施形態で発生する交換を模式的に表す。

【0110】

ＬＤＮＳサーバ１６２は、デマルチキャスタＤＭ１５０によって伝送される構成メッセージＣＯＮＦ１を介して構成されている。ＬＤＮＳサーバ１６２がドメイン名解決を実行し、コントローラＣＴＲＬ１３０のアドレスを検索できるようにＬＤＮＳサーバ１６２を構成することは、したがって、デマルチキャスタＤＭ１５０がゲートウェイＧＷ１４０に正常に設置されたときに、ステップ１１１０において、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツのＵＲＬのＦＱＤＮとコントローラＣＴＲＬ１３０に接触するためのアドレスとの間の関連付けを提供する構成メッセージＣＯＮＦ１をＬＤＮＳサーバ１６２に伝送することによって、デマルチキャスタ１５０によって実行される。図７に関して言及されるように、これは、変形例において、手動で実行され得る。

【0111】

ステップ１１１１において、プレイヤＰＬ１１０は、図２Ａのステップ２００に関して既に説明したように、ＬＡＮ１０１（および／またはＡＰＩを介して）において発見手順を実行する。

【0112】

ステップ１１１２において、プレイヤＰＬ１１０は、要求ＲＥＱ０をＬＤＮＳサーバ１６２に伝送する。要求ＲＥＱ０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮ、すなわち、上記の例のｔｖ．ｍｙＩＳＰ．ｃｏｍの解決を要求する。ＬＤＮＳサーバ１６２はドメイン名解決を実行し、したがってコントローラＣＴＲＬ１３０のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレス：７２．６８．１８．１４につながる。

【0113】

ステップ１１１３では、ＬＤＮＳサーバ１６２は、応答メッセージＲＥＳＰ０においてコントローラＣＴＲＬ１３０の検索されたアドレスをプレイヤＰＬ１１０に返す。したがって、プレイヤＰＬ１１０は、コントローラＣＴＲＬ１３０に接触することができる。

【0114】

ステップ１１１４において、プレイヤＰＬ１１０は、ＬＤＮＳサーバ１６２から取得したアドレスを使用して、要求ＲＥＱ１をコントローラＣＴＲＬ１３０に伝送する。要求ＲＥＱ１は、既に説明したように形成される。

【0115】

ステップ１１１５において、コントローラＣＴＲＬ１３０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツがマルチキャスト形式で利用可能であるかどうかを認識しておらず、要求ＲＥＱ１に応答して、リダイレクトメッセージＲＥＤＩＲ１を伝送する。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ１は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ １９２．１６８．１．１００：８０００／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ？ＦＱＤＮ＿ｏｒｉｇ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ＆ＣＤＮ＿ｕｎｉｃａｓｔＳｅｒｖｅｒ＝ｔｖ．ｍｙＩＳＰ．ｃｏｍ

【0116】

リダイレクトメッセージＲＥＤＩＲ１を受信すると、プレイヤＰＬ１１０は、リダイレクトメッセージＲＥＤＩＲ１に従って、ステップ１１１６において、要求ＲＥＱ２を介してその要求をデマルチキャスタＤＭ１５０にリダイレクトする。デマルチキャスタＤＭ１５０は、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツがマルチキャスト形式で利用可能ではないことを考慮して、デマルチキャスタＤＭ１５０は、要求ＲＥＱ２に応答して、ステップ１１１９において、リダイレクトメッセージＲＥＤＩＲ２を伝送する。

【0117】

リダイレクトメッセージＲＥＤＩＲ２において、デマルチキャスタＤＭ１５０は、要求ＲＥＱ２に指示されるアドレス（例えば、ＩＰアドレスおよびポート番号）を、要求ＲＥＱ２のインラインパラメータ（すなわち、上記の例ではインラインパラメータ「ＣＤＮ＿ｕｎｉｃａｓｔＳｅｒｖｅｒ」）として提供されるユニキャストサーバのアドレスに置き換えた。

【0118】

なお、プレイヤＰＬ１１０によって標的化されたＡＶライブコンテンツを識別するＵＲＬのＦＱＤＮを有するユニキャストサーバ、すなわちｔｖ．ｍｙＩＳＰ．ｃｏｍを参照することは、サーバＣＤＮＳ１２３がコントローラＣＴＲＬ１３０およびデマルチキャスタＤＭ１５０とは異なる権限によって管理される場合に特に有用である。ステップ１１１６で要求ＲＥＱ２を受信するデマルチキャスタＤＭ１５０は、ＤＮＳサーバ１６１によるドメイン名解決を強制し、ＬＤＮＳサーバ１６２（存在する場合）がドメイン名解決によって標的化されることを回避するために、デマルチキャスタＤＭ１５０と同じマシンに、当該デマルチキャスタＤＭ１５０と併せて設置されたＤＮＳクライアントエージェントのサービスを使用してもよい。

【0119】

デマルチキャスタＤＭ１５０は、ドメイン名解決を要求し、ステップ１１１７において、メッセージＲＥＱ３はそれに応じて伝送される。ＤＮＳサーバ１６１は、要求ＲＥＱ３を処理し、ドメイン名解決を実行し、したがって、サーバＣＤＮＳ１２３のアドレスを検索する。例えば、ドメイン名解決は、次のＩＰアドレス：７２．３６．５３．１８につながる。次いで、ステップ１１１８において、ＤＮＳサーバ１６１は、応答メッセージＲＥＳＰ３のサーバＣＤＮＳ１２３の検索されたアドレスをデマルチキャスタＤＭ１５０に返す。

【0120】

次に、デマルチキャスタＤＭ１５０は、リダイレクトメッセージＲＥＤＩＲ２を送信する。上記の例に引き続き、リダイレクトメッセージＲＥＤＩＲ２は、例えば次のようになる。
ＨＴＴＰ ＲＥＤＩＲＥＣＴ ７２．３６．５３．１８：８０／ＳｐｏｒｔｓＣｈａｎｎｅｌ１．ｍｐｄ

【0121】

リダイレクトメッセージＲＥＤＩＲ２を受信すると、ステップ１１２０において、プレイヤＰＬ１１０は、要求ＲＥＱ４をサーバＣＤＮＳ１２３に伝送し、それによって、サーバＣＤＮＳ１２３から問題のＡＶライブコンテンツの配信を要求する。次いで、ステップ１１２１において、プレイヤＰＬ１０は、サーバＣＤＮＳ１２３から（すなわち、デマルチキャスタＤＭ１５０を介して通過することなく）ユニキャスト形式のＡＶライブコンテンツを受信する。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】

【国際調査報告】