(57)【要約】  システム及び方法は、ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中の拡張性フィードバックを、ブロードキャスト／マルチキャストストリーミングセッション中のユーザフィードバックと共に含む。ＰｔＭストリーミングセッション中に拡張性フィードバックを与える方法は、送信者から少なくとも１人の受信者へデータを通信し、そしてマルチメディアストリーミングセッション中に少なくとも１人の受信者のうちの少なくとも１人から送信者へフィードバックを通信することを含む。【選択図】図３
2008541533.tif 000002
【特許請求の範囲】
【請求項１】
ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中に拡張性フィードバックを与える方法において、
送信者から少なくとも１人の受信者へデータを通信する段階と、
マルチメディアストリーミングセッション中に前記少なくとも１人の受信者のうちの少なくとも１人から前記送信者へフィードバックを通信する段階と、
を備えた方法。
【請求項２】
前記少なくとも１人の受信者の入力を促す段階を更に備えた、請求項１に記載の方法。
【請求項３】
前記少なくとも１人の受信者から入力を収集するためのパラメータと、ランダム時間分散のための最大バックオフタイムとを与える段階を更に備えた、請求項２に記載の方法。
【請求項４】
関連配送手順の拡張を使用してマルチメディアストリーミングセッション中に前記少なくとも１人の受信者からの入力をプロビジョニングする段階を更に備えた、請求項２に記載の方法。
【請求項５】
前記少なくとも１人の受信者から入力を促す前記段階は、サービスアナウンスメントチャンネルを経てトークンを送出することを含む、請求項２に記載の方法。
【請求項６】
前記少なくとも１人の受信者からランダム数を抽出し、そしてそのランダム数が、送信者と通信する受信者の一部分を指示する数以下である場合に、クオリティレポートを送信する段階を更に備えた、請求項５に記載の方法。
【請求項７】
ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中に拡張性フィードバックを与えるシステムにおいて、
マルチメディアセッションを開始し、そしてマルチメディアストリーミングセッション中に通信ネットワークを経てマルチメディアデータを通信する送信装置と、
ＰｔＭマルチメディアストリーミングセッション中に促すことに応答して前記マルチメディアデータにフィードバックを通信する受信装置と、
を備えたシステム。
【請求項８】
マルチメディアブロードキャストストリーミングに使用されるコンピュータプログラム製品において、
送信者から少なくとも１人の受信者へデータを通信するためのコンピュータコードと、
ポイント対マルチキャストのマルチメディアストリーミングセッション中に前記少なくとも１人の受信者のうちの少なくとも１人から前記送信者へフィードバックを通信するためのコンピュータコードと、
を備えたコンピュータプログラム製品。
【請求項９】
ネットワークを経てマルチメディアセッションで通信する装置において、
少なくとも１人の受信者へマルチメディアデータを通信するためのインストラクションを実行するプロセッサと、
前記少なくとも１人の受信者から収集される入力と、ポイント対マルチキャストのマルチメディアストリーミングセッション中のランダム時間分散のための最大バックオフタイムとを記憶するメモリと、
を備えた装置。
【請求項１０】
ネットワークを経てマルチメディアセッションで通信する装置において、
送信装置からマルチメディアデータを受け取るプロセッサと、
ポイント対マルチキャストのマルチメディアストリーミングセッション中に前記受信したマルチメディアデータに応答して入力の通信を与えるプログラムされたインストラクションと、
を備えた装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、マルチメディアブロードキャスト／マルチキャストサービス（ＭＢ／ＭＳ）ストリーミングサービスに係る。より詳細には、本発明は、ＭＢ／ＭＳストリーミングセッション中に限定ユーザフィードバックをスケジューリング及び搬送するためのメカニズムに係る。
【背景技術】
【０００２】
本節は、背景又は環境について説明する。ここでの説明は、追及することのできる概念を含むが、これは、必ずしも、従来考えられ又は追求されたものではない。それ故、特に指示のない限り、本節で述べるのは、本出願の請求の範囲に対する従来技術でもないし、本節に含ませることにより従来技術であると認められるものでもない。
【０００３】
マルチメディアブロードキャスト／マルチキャストサービス（ＭＢ／ＭＳ）ストリーミングサービスは、３Ｇ移動環境において多数の受信者への人気のあるリアルタイムコンテンツのリソース効率の良い配送を促進する。異なるポイント対ポイント（ＰｔＰ）ベアラを使用して同じコンテンツを異なる移動装置へ配送するのではなく、単一ポイント対多ポイント（ＰｔＭ）を使用して、同じコンテンツを所与のセル内の異なる移動装置に配送する。ストリーム状のコンテンツは、ビデオ、オーディオ、ＳＶＧ、タイムドテキスト、及び他のサポートされるメディアより成る。このコンテンツは、予め記録されてもよいし、又はライブフィードから発生されてもよい。
【０００４】
配送手順については、ファイルダウンロード後のＰｔＰ修理、及びダウンロード又はストリーミングセッション後のコンテンツ配送検証レポートを含む種々の提案がなされている。ダウンロードセッションの場合に、コンテンツ配送検証レポートは、首尾良くダウンロードされたファイルの詳細を含んでもよい。ストリーミングセッションの場合には、コンテンツ配送検証レポートは、ＱｏＥメトリックを含む。本出願と同じ譲受人で、参考としてここに援用する２００４年２月１８日に出願された“DATA REPAIR”と題する米国特許出願第１０／７８２，３７１号は、同時のＰｔＰ修理要求及びコンテンツ配送検証レポートにより生じるネットワーク過負荷を減少するためのメカニズムを説明している。これは、ランダムバックオフタイムの使用及びランダム修理サーバーの選択を推薦している。又、関連パラメータ、即ち最大バックオフタイムのシグナリング、及び修理又は検証レポートを取り扱うサーバーのリストも定義する。しかしながら、これらの提案されたメカニズムの中で、ＭＢＭＳストリーミングセッション中にユーザフィードバックを取り扱うものは、皆無である。
【０００５】
ブロードキャスト／マルチキャストストリーミングセッション中のユーザフィードバックは、移動ＴＶ又はＭＢＭＳターミナルにおける双方向プログラミングを促進できる望ましい特徴である。しかしながら、現在のＭＢＭＳ仕様は、ＭＢＭＳストリーミングセッション中のユーザフィードバックのためのメカニズムを指定するものではない。多数のＭＢＭＳクライアントからの同時ユーザフィードバックは、サーバーにおいてフィードバックインプロージョン問題を引き起こし、ネットワークリソースの過負荷／阻止状態を生じることがある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、ＭＢＭＳストリーミングセッション中に限定ユーザフィードバックのスケジューリング及び搬送を行なうメカニズムが要望される。更に、ブロードキャスト又はマルチキャストストリーミングセッション中にクライアントフィードバックをスケジューリングするための関連シグナリング情報も要望される。
【課題を解決するための手段】
【０００７】
一般に、本発明は、ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中の拡張可能なフィードバックに係る。ブロードキャスト／マルチキャストストリーミングセッション中のユーザフィードバックは、移動ＴＶ又はＭＢＭＳターミナルにおける双方向プログラミングを促進できる望ましい特徴である。このようなフィードバックは、例えば、次のものを含む。（１）リアリティショー中の移動ＴＶ視聴者の投票、（２）現在ストリーミングセッション中に受け取る投票に基づき次のストリーミングセッションのコンテンツを変化させること、及び（３）ユーザの応答をある時間内にサーバーへ送信する必要のあるユーザ対話を促すＳＶＧ（拡張性ベクトルグラフィック）コンテンツのアニメーション。
【０００８】
１つの実施形態は、ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中に拡張性フィードバックを与える方法に係る。この方法は、送信者から少なくとも１人の受信者へデータを通信する段階と、マルチメディアストリーミングセッション中に少なくとも１人の受信者のうちの少なくとも１人から送信者へフィードバックを通信する段階とを含むことができる。
【０００９】
他の実施形態は、ＰｔＭストリーミングセッション中に拡張性フィードバックを与えるためのシステム、コンピュータプログラム及び装置に係る。
【発明を実施するための最良の形態】
【００１０】
図１は、一実施形態による１対多データ送信シナリオを示す。送信装置１０は、サーバー、ＩＰベースの装置、ＤＶＢ装置、ＧＰＲＳ（又はＵＭＴＳ）装置、又は同様の装置で、先見的フォワードエラー修正、例えば、ＡＬＣ（非同期レイヤ型コード）メカニズム及び／又はＦＥＣ（フォワードエラー修正）メカニズムを使用して、マルチキャストデータブロック（又はパケット）を１対多の形態で受信装置２０へ送出する。各受信装置２０は、欠落ブロック（受信されないか又は誤って受信されたブロック）に関する否定確認（ＮＡＣＫ）メッセージ（又は要求）を送信装置１０へ送出する。ＮＡＣＫメッセージ（１つ又は複数）に応答して、送信装置１０は、一般に、ＦＬＵＴＥ（単一方向性搬送を経てのファイル配送）セッション（オリジナル送信について確立されたオリジナルＦＬＵＴＥセッションと同じセッション、又は後続のＦＬＵＴＥセッション）において欠落ブックを受信装置２０へ再送信する。或いは又、ＦＬＵＴＥ以外のプロトコルを使用したセッションが使用されてもよい。
【００１１】
データは、オブジェクトとして送信者１０から受信者（１つ又は複数）２０へ転送される。例えば、ファイル、ＪＰＥＧ映像、ファイルスライスは、全て、オブジェクトである。ファイル（又はデータ）配送に対して送信装置１０と受信装置２０との間にセッションが確立される。単一のセッションは、単一のオブジェクト又は複数のオブジェクトの通信を含むことができる。異なる識別子を使用して、オブジェクト及びセッションが識別される。
【００１２】
各データブロックは、各ブロックを識別するソースブロックナンバー（ＳＢＮ）と称される番号又は同様のものを有する。ブロックは、エンコード記号のセットにより表わされる。エンコード記号識別子（ＥＳＩ）又は同様のものは、次いで、データパケット（又はブロック）のペイロードに支持されたエンコード記号が前記オブジェクト（例えば、ファイル）からどのように発生されたか指示する。
【００１３】
ここに例示する実施形態は、ポイント対マルチキャスト（ＰｔＭ）ストリーミングセッション中に拡張性フィードバックを与える。これらの実施形態は、アプリケーション／コンテンツ駆動フィードバック、ＭＢＭＳにおける関連配送手順への拡張、及びＲＴＣＰフィードバックレポートを使用して具現化することができる。
【００１４】
アプリケーション／コンテンツ駆動フィードバック具現化の一例を以下に示す。ＰｔＭストリーミングコンテンツが、セッション中にユーザフィードバックを必要とする場合には、ＰｔＭサーバーが、アウトオブバンドの関連パラメータを記述する（例えば、関連配送手順に対応するＳＤＰファイルに）。このようなパラメータの最小セットは、（１）フィードバックを収集するサーバーのＵＲＩのセット、及び（２）ランダム時間分散に対する最大バックオフタイム（“ｍａｘＢａｃｋＯｆｆ”）を含む。
【００１５】
ＭＢＭＳストリーミングセッション中に、クライアントアプリケーション又はＳＶＧアニメーションは、ユーザ入力、例えば、イエス／ノーの選択、ベストの選択、トップスリーのランク付け、等を促すことができる。アプリケーションは、ユーザ入力を、それが与えられるや否や収集し（例えば、時間＝“feedback_time”に）、そしてそれをバッファに記憶し、フィードバックサーバーへのスケジュールされた搬送を行なう。クライアントの搬送スケジューラは、“０”と“maxBackOff”との間でランダム番号“Ｘ”を発生する。次いで、Actual_transport_time＝feedback_time+Ｘを計算する。ＳＤＰにおいて前もってシグナリングされたＵＲＩのセットからランダムにフィードバック収集サーバーが選択される。Current_time＝“actual_transport_time”であるときには、ランダムに選択されたＵＲＩに対してＴＣＰ接続が確立される。ユーザ応答は、ＨＴＴＰ  ＰＯＳＴ方法を使用して送信されるＸＭＬオブジェクトに埋め込まれる。
【００１６】
ユーザフィードバックは、ＸＭＬオブジェクトにおいてフォーマットできる。ＸＭＬオブジェクトは、フィードバック、ストリーミングセッション及びクライアントＩＤを識別するのに必要なパラメータを含む。アプリケーション指向のフィードバックは、対応するＸＭＬスキーマへの拡張を指定することによりＸＭＬオブジェクトに含まれる。
【００１７】
ＭＢＭＳストリーミングセッション中のユーザフィードバックは、関連配送手順に対してＭＢＭＳで定義されたＸＭＬスキーマの簡単な拡張によりプロビジョニングすることができる。ＭＢＭＳにおける関連配送手順に対する拡張の具現化の一例を以下に示す。
【００１８】
以下のサンプルコードに示す「関連配送手順」に対応するＸＭＬスキーマにおいて形式userFeedbackTypeの新たなエレメントが導入される。必要なエレメント“serverURI”は、クライアントからフィードバックを収集するサーバーのリストのＵＲＩを指定する。図２は、“waitTime”及び“maxBackOff”パラメータの定義を示す。フィードバックを収集した後に、クライアントは、“waitTime”時間単位を待機し、“０”と“maxBackOff”との間でランダム番号“Ｘ”を発生する。“Ｘ”の更なる時間単位を待機した後にフィードバックを送信する。フィードバックは、ＨＴＴＰ／ＴＣＰを使用して確実に送信される。
【００１９】
2008541533.tif 000003
【００２０】
ＭＢＭＳストリーミングサーバーは、ＭＢＭＳストリーミングセッション中にある形式のフィードバックを収集するように判断する。フィードバックの形式は、例えば、「イエス／ノーの投票」、「アイテムのグループ（Ａ／Ｂ／Ｃ／・・・）間の最良」、「ランク付け」、等である。クライアントアプリケーションは、必要な時間に適当な形式のフィードバックを収集する。又、クライアントアプリケーションは、フィードバックを、ＨＴＴＰ  ＰＯＳＴ方法を使用してその後に搬送されるべきＸＭＬオブジェクトへとフォーマットする。
【００２１】
ユーザは、ＭＢＭＳストリーミングセッション中の多数の時間に同じ形式のフィードバックを与えることができる。クライアントフィードバックに対応するＸＭＬオブジェクトは、各フィードバックを独特に識別するある手段、例えば、クライアントフィードバックが収集された時間に対応するタイムスタンプを含むことができる。他の実施形態では、フィードバックカウンタを使用して、種々のフィードバックインスタンスを追跡することができる。クライアントＩＤ、サーバーＵＲＩ、等の他の有用な情報が、ユーザフィードバックに対応するＸＭＬオブジェクトに任意に含まれる。
【００２２】
各形式のフィードバックに対応するＸＭＬスキーマは、以下のサンプルコードに示すように定義することができる。クライアントアプリケーションは、フィードバックを、このＸＭＬスキーマを使用してＸＭＬオブジェクトへとフォーマットする。
【００２３】
2008541533.tif 000004
2008541533.tif 000005
【００２４】
多数のフィードバックインスタンスに対応するＸＭＬオブジェクトは、多部分ＭＩＭＥ構造体を使用して総計されてもよい。
【００２５】
ＲＴＣＰ（リアルタイム制御プロトコル）フィードバックレポートの具現化の例を以下に示す。送信者は、ＲＴＰ又はＲＴＣＰストリーム内でダウンリンク方向にアウトオブバンドの又はダウンリンク方向にインバンドのサービスアナウンスメントチャンネル（ＳＤＰ、ＸＭＬ、ＦＬＵＴＥ、等）を経てフィードバックトークンを送信することにより複数の受信者からフィードバックを要求する（例えば、適当なフィールドを伴うＲＴＰヘッダ拡張を使用するか、又は適当なフィールドで拡張したＲＴＣＰ  ＡＰＰパケットを使用することにより）。フィールドは、フィードバックのインジケータ（フィードバックが要求されたことを指示する）、任意の時間インジケータ（フィードバックが要求されたときを指示する）、及びフィードバックを送信することが要求された受信者の一部分を示す数を含む。
【００２６】
受信者は、ランダム数を抽出し、そしてその数が（送信者により受け取られた）受信者の一部分を指示する数以下である場合には、ＲＴＣＰレポート（又は他の何らかのクオリティレポート）を直ちに、又は送信者により受信者へ通信されるタイミングルールを使用して送信する。
【００２７】
図３は、ここに例示する実施形態による受信装置２０を示す。通信システムは、送信装置１０と、送信ネットワーク３０、例えば、ＩＰネットワーク又は別の固定ネットワーク、ワイヤレスネットワーク、或いは固定及びワイヤレス（セルラー）ネットワークの組み合せ、等と、受信装置２０とを備えている。受信装置２０は、セルラー電話、衛星電話、パーソナルデジタルアシスタント、又はブルーツース装置、ＷＬＡＮ装置、ＤＶＢ装置、或いは他の同様のワイヤレス装置である。この装置２０は、内部メモリ２１と、プロセッサ２２と、オペレーティングシステム２３と、アプリケーションプログラム２４と、ネットワークインターフェイス２５と、ＮＡＣＫ＆修理メカニズム２６とを備えている。内部メモリ２１は、プロセッサ２２、オペレーティングシステム２３及びアプリケーションプログラム２４を収容する。ＮＡＣＫ＆修理メカニズム２６は、データ送信における欠落データ又は破壊データに応答してＮＡＣＫ処理及び修理手順を行えるようにする。装置２０は、ネットワークインターフェイス２５及びネットワーク３０を経て送信装置１０及び他の装置と通信することができる。
【００２８】
図４は、ここに例示する実施形態による送信装置１０を示す。この送信装置１０は、例えば、ネットワークサーバーであるか、又はファイル（又はメディア）配送に意図された適当な装置である。この装置１０は、内部メモリ１１と、プロセッサ１２と、オペレーティングシステム１３と、アプリケーションプログラム１４と、ネットワークインターフェイス１５と、送信＆修理メカニズム１６と、データ記憶装置１７とを備えている。内部メモリ１１は、プロセッサ１２、オペレーティングシステム１３及びアプリケーションプログラム１４を収容する。送信＆修理メカニズム１６は、受信装置２０へのデータパケットの送信を可能にする。更に、修理セッションにおいてデータパケットの再送信を行うことができる。受信装置２０へ送信されるべきデータ及び再送信されるべきデータは、データ記憶装置１７に記憶することができる。或いは又、データは、送信装置１０と同じ位置にある又はその外部にある個別の装置に記憶することもできる。装置１０は、ネットワークインターフェイス１５及びネットワーク３０を経て受信装置２０及び他の装置と通信することができる。
【００２９】
本発明の幾つかの実施形態を説明したが、本発明に係る当業者であれば、修正や変更がなされ得ることが理解されよう。従って、本発明は、特許請求の範囲によって厳密に限定されるものとする。
【図面の簡単な説明】
【００３０】
【図１】一実施形態による１対多データ送信シナリオを示す図である。
【図２】一実施形態による“waitTime”及び“maxBackOff”パラメータの意味を示す図である。
【図３】一実施形態による受信装置を示す図である。
【図４】一実施形態による送信装置を示す図である。
【図１】
2008541533.tif 000006
【図２】
2008541533.tif 000007
【図３】
2008541533.tif 000008
【図４】
2008541533.tif 000009
【国際調査報告】
2008541533.tif 000010
2008541533.tif 000011
2008541533.tif 000012