JP2012533913A - クライアント制御セッションレス適応を促進する方法および装置 - Google Patents

Abstract

メディアコンテンツを管理するための開示される例示的方法は、利用可能なメディアのためのメタデータ情報にアクセスするステップと、アクセスされたメタデータから、少なくとも、ユニフォームリソースロケータ（ＵＲＬ）および１つ以上のバイト範囲を読み出すステップであって、利用可能なメディアの１つ以上の部分は、１つ以上のバイト範囲とＵＲＬの組み合わせによってアドレス可能である、ステップと、を含む。例示的方法はまた、読み出されたメタデータに基づいて、利用可能なメディアの第１の少なくとも１つの部分を要求する第１の要求を送信するステップを含む。

Description

関連出願
本特許は、２００９年６月１５日に出願された米国仮特許出願第６１／１８７，０９０号および２０１０年６月１４日に出願された米国特許出願第１２／８１４，５６６号の利益を主張し、これらの米国出願は、本明細書において、全体が参照により援用される。

本開示は、概して、無線メディア配信に関し、より具体的には、クライアント制御セッションレス適応を促進するための方法および装置に関する。

ユーザ機器（ＵＥ）は、メディアコンテンツを受信し、要求に応答して、ユーザに表示し得る。メディアのための１つ以上の要求が、ＵＥによって要求されると、メディアコンテンツは、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）等のいくつかのプロトコルを経由して、ＵＥにストリーミングされ得る。

ＵＥにストリーミングメディアコンテンツを提供するために、ＵＥは、１つ以上のコマンドをメディアサーバに送信し、メディアサーバは、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）を経由して等、記述で応答する。メディアコンテンツが、ＵＥにストリーミングされるのに伴って、メディアサーバは、典型的には、終始、アクティブセッションを維持する。

以下は、他の構成要素の中でも、ハードウェア上で実施されるソフトウェアを含む、例示的方法および装置を開示するが、そのような方法および装置は、例証に過ぎず、制限するものとして考慮すべきではないことに留意されたい。例えば、これらのハードウェアおよびソフトウェア構成要素のうちの一部または全部を、ハードウェアのみ、ソフトウェアのみ、ファームウェアのみ、またはハードウェア、ソフトウェア、および／またはファームウェアのいずれかの組み合わせで具現化できることが想定される。したがって、以下は、例示的方法および装置について説明しているが、当業者は、提供される実施例が、そのような方法および装置を実装するための唯一の方法ではないことを容易に理解されよう。

本明細書に説明される例示的方法および装置は、ユーザ機器（ＵＥ）によって、１つ以上のチャネル条件および／またはＵＥの現在の条件に基づいて、ＵＥ上でレンダリングされる、メディアパラメータの種類を制御するために使用可能である。ＵＥは、オーディオ（例えば、ＭＰ３オーディオ）および／またはビデオを含むが、それらに限定されない、メディアの任意の種類をレンダリングし得、メディアパラメータは、メディアビットレート、メディア分解能等を含み得るが、それらに限定されない。メディアコンテンツプロバイダは、それぞれ、１つ以上の異なるビットレート、分解能、サイズ等を有する、１つ以上の異なる構成（本明細書では、「エンコードされたメディア構成」と称される）において、メディアコンテンツをエンコードするが、メディアコンテンツがレンダリングされるデバイスは、どのエンコードされたメディア構成が、現在の条件に基づいて、最も適切であるかを選択するステップに関与しない。本明細書で使用されるように、用語「適応」とは、メディアコンテンツが、現在のチャネル条件および／またはＵＥの能力によってより好適なフォーマットで配信されるように、修正および／または選択される状況に関する。ユーザの視点から、不利なチャネル条件および／またはＵＥ制限（例えば、あるビットレート、分解能、ＵＥプロセッサスピード制限等において、メディアをレンダリングするＵＥの能力）は、途切れがちのオーディオ／ビデオ（Ａ／Ｖ）、比較的に長い休止および／またはバッファリング時間、ならびに／あるいは同期していないＡ／Ｖとして露顕し得る。本明細書で参照されるＵＥは、モバイル通信デバイス、モバイルコンピューティングデバイス、または無線ネットワークと無線で通信可能な任意の他のデバイスを含み得るが、それらに限定されない。端末または無線端末とも称される、そのようなデバイスは、モバイルスマートフォン（例えば、ＢＬＡＣＫＢＥＲＲＹ（登録商標）スマートフォン）、無線携帯端末（ＰＤＡ）、無線アダプタを伴う、ラップトップ／ノートブック／ネットブックコンピュータ等を含み得る。例示的方法および装置は、とりわけ、外部ネットワークとの相互作用を定義する、ＩＥＥＥ（登録商標）（Ｉｎｓｔｉｔｕｔｅ ｆｏｒ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１として周知の無線ローカルエリアネットワーク（ＷＬＡＮ）通信規格に関連して、本明細書に説明される。しかしながら、例示的方法および装置は、加えて、または代替として、他のＷＬＡＮ規格、パーソナルエリアネットワーク（ＰＡＮ）規格、ワイドエリアネットワーク（ＷＡＮ）規格、またはセルラー通信規格を含む、他の無線通信規格と関連して実装され得る。

例示的方法および装置は、とりわけ、外部ネットワークとの相互作用を定義する、ＩＥＥＥ（登録商標）（Ｉｎｓｔｉｔｕｔｅ ｆｏｒ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１として周知の無線ローカルエリアネットワーク（ＷＬＡＮ）通信規格に関連して、本明細書に説明される。しかしながら、例示的方法および装置は、加えて、または代替として、他のＷＬＡＮ規格、パーソナルエリアネットワーク（ＰＡＮ）規格、ワイドエリアネットワーク（ＷＡＮ）規格、またはセルラー通信規格を含む、他の無線通信規格と関連して実装され得る。

サーバからＵＥへメディアコンテンツをストリーミングするための周知の技法または規格と関連付けられるユーザ経験は、いくつかの制限を含む。例えば、メディアコンテンツの従来のストリーミングは、リアルタイムおよび／または略リアルタイムストリーミングを有効化するクライアント／サーバプロトコルである、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）を採用する。概して、サーバからメディアを要求する動作の際、ＵＥは、ＤＥＳＣＲＩＢＥコマンドをメディアサーバに送信し、メディアサーバは、プレゼンテーション記述（例えば、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ））で応答する。ＳＤＰ情報は、メディアプレゼンテーション全体および／またはプレゼンテーションを構成するために使用される各ストリームの記述を含む。次いで、クライアントは、インターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、またはＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケットを介して、所望のメディアを受信し得る。しかしながら、本状況では、メディアが、クライアント発行ＳＥＴＵＰコマンド、ＰＬＡＹコマンド、およびクライアントがメディアを終了する時のＴＥＡＲＤＯＷＮコマンド等、ＵＥへのストリーミングまたはＵＥ上での表示を開始する前に、付加的制御が、依然として、要求される。

従来のＲＴＳＰストリーミング技法は、クライアントとメディアサーバとの間の永続的伝送制御プロトコル（ＴＣＰ）接続の必要性を回避するが、メディアサーバは、メディアを要求するクライアント毎に、アクティブセッションを維持可能でなければならない。加えて、ＲＴＳＰストリーミングは、平均レートまたはメディアがエンコードされたレートで、クライアントにパケットを送信し、レートパケット伝送が、バッファ占有状態に基づいて、調整され得るが、従来のストリーミングおよび／またはパケット切替ストリーミング（ＰＳＳ）は、依然として、ファイアウォール、ネットワークアドレス変換（ＮＡＴ）を通過させることに関する課題を呈し、比較的に高価なストリーミングサーバを要求する。標準的ウェブサーバは、メディアストリーミングサーバと異なり、典型的には、メディアストリーミングサーバより有意に安価であって、ステートレスな様式でＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を採用する。言い換えると、業界標準ウェブサーバは、余剰処理電力および／または状態ベースの通信プロトコル（例えば、ＲＴＳＰ）の設定、維持、ならびに／あるいは分解と関連付けられる複雑性を伴わずに、ＨＴＴＰ（例えば、ＨＴＴＰ １．１）を採用し得る。したがって、メディアストリーミングサーバは、典型的には、一部には、需要に伴う、有意な処理要件のため、良好にスケーリングできない。一方、標準的ウェブサーバは、時として、クライアントによって要求されていないコンテンツを返す、「非知能型」サーバと称され、複雑性、コストを最小限にし、よりコストのかかるメディアストリーミングサーバより良好にスケーリングを行う。

図１、２Ａ、および２Ｂは、クライアント制御セッションレス適応を促進するためのユーザ機器（ＵＥ）とサーバとの間の例示的メッセージフローを例証する。 図１、２Ａ、および２Ｂは、クライアント制御セッションレス適応を促進するためのユーザ機器（ＵＥ）とサーバとの間の例示的メッセージフローを例証する。 図３および４は、クライアント制御セッションレス適応を促進するように実装され得る、例示的３ＧＰＰファイルオブジェクトボックスを例証する。 図３および４は、クライアント制御セッションレス適応を促進するように実装され得る、例示的３ＧＰＰファイルオブジェクトボックスを例証する。 図５および６は、本開示に従って実装可能な例示的サーバを例証する。 図５および６は、本開示に従って実装可能な例示的サーバを例証する。 図７は、本開示に従って実装可能な例示的ＵＥを例証する。 図８および９は、クライアント制御セッションレス適応を促進するための例示的プロセスの工程図を例証する。 図８および９は、クライアント制御セッションレス適応を促進するための例示的プロセスの工程図を例証する。

図１は、事前に記録されたメディアストリーム（すなわち、ライブではない）と関連付けられる、ユーザ機器（ＵＥ）１０２とサーバ１０４との間の例示的メッセージ交換１００を例証する。さらに詳細に後述されるように、例示的サーバ１０４は、標準的ウェブサーバまたは類似ＨＴＴＰサーバであり得る。一実施例では、システムは、無線デバイスへのメディアストリーミングを促進するための１つ以上のメディアストリーミングサーバ（図示せず）を採用し得、本明細書に説明される方法および装置は、比較的に高価なメディアストリーミングサーバではなく、コスト的に賢明なサーバの利用を可能にする。メディアの受信を始動させるために、例示的ＵＥ１０２は、例示的サーバ１０４へのセッションレス要求（１０６）を生成する。セッションレス要求（１０６）は、例示的ＵＥ１０２のユーザによって行われた選択と関連付けられる、ユニフォームリソースロケータ（ＵＲＬ）によって識別されたＴｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ ＧＰＰ）ファイルを識別する、ＨＴＴＰ要求を含み得る。加えて、または代替として、例示的セッションレス要求は、ＨＴＴＰ １．１においてサポートされるＧＥＴコマンドを経由して等、ダウンロードするためのファイルのバイト範囲を含み得る。セッションレス要求（１０６）の受信に応答して、例示的サーバ１０４は、ボックスと称される一連のオブジェクトを含む、対応する識別された３ＧＰＰファイルを提供する。３ＧＰＰファイル内の各ボックスは、所定のメディア特性（例えば、所定の分解能、所定のビットレート、所定のコーデック、および／またはそれらの任意の組み合わせ）で構築されたメディア（例えば、オーディオ、ビデオ等）等のメディア情報またはメタデータを含有し得る。

例示的サーバ１０４は、３ＧＰＰファイルをＵＥ１０２に伝送（１０８）し、その中に含有されるメディアをＵＥ１０２によってレンダリング可能にする。加えて、例示的ＵＥ１０２は、オブジェクトボックスのための受信した３ＧＰＰファイルを解析し、メディア特性の１つ以上の代替順列が、サーバ１０４において利用可能であるかどうかを識別する。サーバが、適応および／またはパケットがＵＥに送信されるレート（例えば、典型的には、メディアがエンコードされたレートに匹敵するリアルタイムレート）を制御する、従来のストリーミングと異なり、本明細書に説明される方法および装置は、ＵＥに、比較的に高価な１つ以上のメディアストリーミングサーバではなく、従来のウェブサーバを採用する様式において、ストリームと関連付けられるメディア特性を制御可能にする。その結果、ＵＥ１０２は、例えば、ＵＥ１０２の１つ以上の現在の条件（例えば、チャネル混雑、信号強度劣化等）および／またはＵＥ１０２の１つ以上の能力（例えば、バッファ占有量、ＵＥプロセッサ能力／スピード等）に基づいて、メディアストリームビットレート、分解能等に関連する１つ以上の決定を制御し得る。加えて、従来のストリーミングは、典型的には、１つ以上のセッションを維持するために、ＵＥおよびサーバの両方から処理リソースを要求する、ＲＴＳＰを採用する。そのような処理リソースは、特に、ＵＥが、１つ以上の制御機能（例えば、再生、停止、早送、巻戻、スキップ等）を行っていない時でも、各現在のストリーミングインスタンスのためにセッションを維持しなければならない、メディアサーバに重荷になる。一方、本明細書に説明される方法および装置は、任意のセッション維持要件を排除し、それによって、サーバ複雑性および／またはコストを削減する、ＨＴＴＰストリーミングを採用する。

例示的ＵＥ１０２が、３ＧＰＰファイル（１０８）を受信し、利用可能な代替メディア特性を示す、ＵＲＬメタデータのための受信した３ＧＰＰファイルを解析後、ＵＥ１０２は、解析されＵＲＬにナビゲートし、その中に含有される任意の付加的メタデータを要求する（１１０）。例示的サーバ１０４（１１２）から返される付加的メタデータは、メディアコンテンツのための付加的／代替メディア特性、メディアがライブであるかどうかを示す情報、フラグメントインデックス値、および／またはシークを有効化するためのバイトオフセット値を含み得るが、それらに限定されない。さらに詳細に後述されるように、付加的メタデータによって、例示的ＵＥ１０２は、代替メディア特性（例えば、より低ビットレート、より低分解能、代替コーデック等）を有する代替メディアストリームのうちの１つを要求し得る（１１４）。例えば、ＵＥ１０２は、劣化したチャネル条件、バッファ占有量、および／または比較的に高ビットレート、分解能等において、メディアをレンダリングするためのＵＥの制限に基づいて、代替メディアストリームを要求し得る。例示的サーバ１０４は、選択されたメディアコンテンツを送信（１１６）することによって、要求に応答する。

図２Ａは、サーバ１０４を介して提供されるメディアコンテンツが、事前に記録されたものではなく、ライブである状況に対する、ＵＥ１０２とサーバ１０４との間の例示的メッセージ交換２００を例証する。ＵＥ１０２による、ライブ３ＧＰＰファイル（例えば、メディアコンテンツ作成者または配信者（例えば、放送局）によって、サーバ１０４上に格納された一連の関連３ＧＰＰファイルフラグメント）の受信の試行の際、ＵＥ１０２を使用するクライアントは、以前の視聴時間周期における開始ではなく、ライブ（例えば、最新の）フラグメントに直接シークすることを好み得る。例えば、いくつかのライブストリーミング要求は、ライブイベントが、比較的に長い時間周期（例えば、数分、数時間等）の間、生じた後、ＵＥ１０２から始動し得、クライアントは、ＵＥ１０２を介して、最新の一連の利用可能な３ＧＰＰファイルにシークを試行し得る。従来のストリーミング技法は、典型的には、最新の利用可能なメディアを識別しようとする目的で、３ＧＰＰファイルを解析可能にするが、そのような技法は、プロセス集約的であって、時間がかかる。本明細書に説明される方法および装置は、連続的、周期的、非周期的、および／またはスケジュール化されたベースに基づいて、アップデートされる、ライブ−ストリーム−メタファイルを維持および／または別様に受信することによって、ライブストリーミングコンテンツの効率的シークを可能にする。したがって、３ＧＰＰファイルフラグメントの１つ以上の具体的シーク場所は、例示的ＵＥ１０２が、アップデートされたライブ−ストリーム−メタファイルにアクセスし、現在のファイルフラグメントインデックス値および／またはバイトオフセット値を特定後、識別され得る。

図２Ａの例証される実施例では、ＵＥ１０２は、セッションレスＨＴＴＰ要求を例示的サーバ１０４（２０２）に生成し、メタデータおよびメディア情報（２０４）を有するオブジェクトボックスを受信する。さらに詳細に後述されるように、受信したオブジェクトボックスは、メディアがライブであるかどうかを示す情報、付加的メタデータ（例えば、３ＧＰＰメタデータペイロードサイズを最小限にするため）を参照するためのＵＲＬ、代替メディア特性を有する利用可能なメディアのリスト、代替メディア特性（例えば、ＵＲＬ）と関連付けられた利用可能な３ＧＰＰファイル場所のリスト、および／またはＳＤＰ情報を含み得るが、それらに限定されない。例示的ＵＥ１０２は、受信したＵＲＬ（２０６）にクエリを行い、該当する場合、付加的メタデータを受信する（２０８）。サーバ（２０２）から受信したメタデータが、完全である場合、および／または付加的メタデータおよび／またはＵＲＬが提供されない場合、交換２０６および／または２０８は、排除され得る。

ＵＥ１０２に、メディアの所望の場所への直接シークを可能にするために、ＵＥ１０２は、サーバ１０４によって提供されたライブ−ストリーム−メタファイルからフラグメントインデックス値および／またはバイトオフセット値を選択する（２１０）。ライブメディアの継続に伴って、メディアコンテンツを提供する当事者（例えば、放送局）は、サーバ１０４および／または任意の他の場所（例えば、別のサーバ、ネットワーク記憶リソース、インターネットリソース等）上に格納され得る、受信したＵＲＬ（２０６）によって指定された場所において、ライブ−ストリーム−メタファイルをアップデートする。ＵＥ１０２のクライアントが、代替３ＧＰＰフラグメントインデックス場所にシークする、および／または最新のフラグメントインデックスが特定された場所を再確認することを所望する場合、ＵＥ１０２は、以前に読み出されたメタデータが現在のものであると考えられるかどうかを判定し得る。例えば、以前に読み出されたメタデータが、アップデートされたフラグメントインデックス値および／またはバイトオフセット値が利用可能であり得る、数分前のものである場合、ＵＥ１０２は、ＵＲＬに再びクエリを行い（２１２）、例えば、アップデートされたフラグメントインデックス値および／またはアップデートされたデータオフセット値を含有する、アップデートされたライブ−ストリーム−メタファイルを含有するサーバ１０４からの応答を待機する（２１４）。ＵＥ１０２は、周期的、非周期的、スケジュール化、および／または手動ベースに基づいて、ＵＲＬにクエリを行い、ライブメディアコンテンツと関連付けられた現在の３ＧＰＰファイル詳細の認識を維持し得る。

図２Ｂは、ＵＥ１０２と、ＵＥ１０２に、ユーザ選好および／または変化するチャネル条件に応答して、適応を制御可能にする、サーバ１０４との間の例示的メッセージ交換２５０を例証する。図２Ｂの例証される実施例では、交換２５０は、サーバ１０４が、交換２０４によって示される伝送等、メタデータおよび／またはメディアの第１のインスタンスを伝送後、開始する。例示的ＵＥ１０２によって変化したチャネル条件２５２に応答して、ＵＥ１０２は、ＵＲＬ（例えば、図２Ａの交換２１２において提供されるＵＲＬ）にクエリを行い、代替メディア特性を有する代替メディアが利用可能であるかどうかを識別する（２５４）。一方、例示的ＵＥ１０２は、以前のセッションレス要求２０２によって、利用可能なビットレート、分解能等を示すメタデータを既に有し得る。例示的サーバ１０４は、３ＧＰＰファイル場所およびＵＥ１０２に利用可能な対応するメディア特性を示す、メタデータで応答する（２５６）。利用可能なメディア特性に基づいて、例示的ＵＥ１０２は、変化したチャネル条件２５２に対処する、３ＧＰＰファイルを選択する。変化したチャネル条件は、チャネル帯域幅の低下（例えば、チャネル集中のため）、ドロップアウト条件の増加、同一チャネル干渉、フェーディング、待ち時間値の増加、および／またはジッタの増加を含み得るが、それらに限定されない。加えて、または代替として、劣化した性能は、あるビットレートおよび／または分解能において、メディアを処理／レンダリングするためのＵＥ１０２の能力等、ＵＥ１０２の１つ以上の制限により得る。そのようなチャネル条件および／またはＵＥ１０２性能における劣化は、超過する（例えば、性能の下限を超える、性能の上限を超える）と、ＵＥ１０２に、不良チャネル条件を被り難い３ＧＰＰファイルを要求することを可能にする、ＵＥ１０２上の１つ以上の閾値によって検証され得る。言い換えると、より低いビットレート３ＧＰＰファイル、より低い分解能３ＧＰＰファイル、および／または代替コーデックを有する３ＧＰＰファイルは、帯域幅が不良チャネル条件によって制限される時、ＵＥ１０２において、より優れたクライアント経験をもたらし得る。例示的ＵＥ１０２は、より低いビットレートを有する３ＧＰＰファイル等の代替３ＧＰＰファイルを選択し（２５８）、例示的サーバ１０４は、ＨＴＰＰ（例えば、クライアントＨＴＴＰ ＧＥＴコマンドへのサーバ応答）を介して、選択された３ＧＰＰファイルをストリーミングすることによって応答する（２６０）。

一方、チャネル条件が改善する場合、例示的ＵＥ１０２は、改善されたチャネル条件によって対応可能な３ＧＰＰファイルのために、別の要求をサーバ１０４に発行し得る。言い換えると、ＵＥ１０２は、チャネル条件が、所与の時間の間、十分な帯域幅を維持する時、比較的に高分解能および／または高ビットレート３ＧＰＰファイルを要求し得る。上述のように、ＵＥ１０２は、周期的、非周期的、スケジュール化、および／または手動ベースに基づいて、チャネル条件を監視し、チャネル測定値（例えば、チャネルジッタ、チャネル待ち時間等）を収集し、そのような測定値を１つ以上の閾値と比較し得る。そのようなチャネル条件が、好ましい様式において、１つ以上の閾値を超える（例えば、測定されたビットレート値が、高分解能無線ビデオのための最小ビットレート閾値を超える）場合、ＵＥ１０２は、そのような変化した条件下、好ましく動作する１つ以上の３ＧＰＰファイル（例えば、より高い分解能、より高いビットレート等を有する３ＧＰＰファイル）を要求し得る。

図３は、本開示に従って実装される、３ＧＰＰファイルオブジェクトボックス３００の例示的部分を例証する。概して、３ＧＰＰファイルフォーマットは、ＩＳＯ／ＩＥＣ １４４９６−１２ ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＭＰ４ファイル規格と称される）に基づく、３ＧＰＰ ＴＳ ２６．２４４に規定される要件に準拠する。３ＧＰＰファイルは、ボックスと呼ばれ、それぞれ、メディアまたはメタデータを含有する、一連の階層オブジェクトとして配列される。各ボックスは、典型的には、４文字の名称および関連付けられたサイズ（例えば、３２ビット符号なし整数）である、関連付けられたボックスタイプを有する。いくつかのボックスタイプは、必須であって、各３ＧＰＰファイル内に見られるが、ＭＰ４規格は、いくつかの任意のボックスタイプを含む。ボックスタイプ階層は、図３の最左列３０２等の最左列内の最上位ボックスを識別する。ボックスタイプ「ｆｔｙｐ」（ファイルタイプ）３０４は、通常、所与の３ＧＰＰファイル内で最初に生じる。「ｍｏｏｖ」ボックス（動画ボックス）３０６は、プレゼンテーションのためのメタデータを格納し、３ＧＰＰファイルの最上位（最左）に生じる。「ｍｅｔａ」ボックス（３０８）は、利用可能なコーデック３１０、利用可能なビットレート３１２、利用可能な分解能３１４、他のファイル場所３１６、および／または付加的メタデータが特定され得るＵＲＬ３１８を含み得るが、それらに限定されない、３ＧＰＰファイルのための記述および／または注釈メタデータを含有する。

図３の例証される実施例では、例示的「ｍｅｔａ」ボックス３０８は、より上位の「ｍｏｏｖ」ボックス３０６下に含まれ、対応する３ＧＰＰファイルが、サーバ１０４によって伝送後、例示的ＵＥ１０２によって、先にダウンロードおよび／または解析可能にする。概して、サーバ１０４が、３ＧＰＰファイルをＵＥ１０２に伝送するのに伴って、ＵＥ１０２は、到着すると、直ぐに、３ＧＰＰファイルの解析を開始し得る。ＵＥ１０２が、例えば、より低い分解能を有する１つ以上の代替メディアを直ぐに要求する場合、ＵＥ１０２は、３ＧＰＰファイルの残りの部分をダウンロードするために待機せずに、例示的サーバ１０４に別の要求を行い得る。言い換えると、ＵＥ１０２は、現在のチャネル条件および／またはＵＥ１０２の能力に基づいて、より優れた性能を有する可能性のある代替メディアコンテンツを支持し、現在のメディアコンテンツのダウンロードを中断することによって、周知のチャネル条件に対して、より応答性を向上し得る。一方、例示的「ｍｅｔａ」ボックス３０８は、代わりに、ストリーミングされたコンテンツを可能な限り早く例示的ＵＥ１０２上に表出可能にする目的で、最左列３０２かつより下位の行に特定され得る。

適応は、「ｍｅｔａ」ボックスを伴って、または伴わず、「ｍｏｏｖ」ボックスとして構築される、１つ以上のファイルを含み得る。加えて、例示的３ＧＰＰファイルは、時間整合され、各フラグメントが、ランダムアクセスポイントで開始する、１つ以上のフラグメントを含み得る。したがって、ファイル間の切替が、行われ得る。ファイル識別は、１つ以上のブランド識別子を介して、さらに促進され得、それによって、クライアントに、他のファイルへのメタデータリンクが可能であることの表示を提供する。

図４の例証される実施例では、３ＧＰＰファイルオブジェクトボックス４００の例示的部分は、「ｈｎｔｉ」（ヒント）ボックス４０２を含む。「ｈｎｔｉ」ボックス４０２は、ユーザデータボックスタイプ「ｕｄｔａ」４０４の拡張子であって、ＳＤＰ情報を含む。ＳＤＰ情報は、典型的には、ＨＴＴＰ通信ではなく、セッションベースの通信と関連付けられるが、１つ以上のＳＤＰパラメータが、例示的ＵＥ１０２を付加的メタデータを含有するＵＲＬにダイレクトするために、「ｈｎｔｉ」ボックス４０２内に埋め込まれ得る。例えば、ＳＤＰは、ＵＲＬと関連付けられた「ｕ＝」フィールド４０６を含む、いくつかのフィールドを含む。例示的サーバ１０４は、ＵＲＬを「ｕ＝」フィールド４０６に加え、さらに、「ｈｎｔｉ」ボックス４０２内に「ｕ＝」フィールド４０６を埋め込み、受信に応じて、ＵＥ１０２に、付加的メタデータを特定可能にし得る。

図５は、本開示に従って実装可能な、例示的サーバ１０４である。図５の例示的サーバ１０４は、サーバ１０４、フラッシュメモリ５０４、ランダムアクセスメモリ５０６、およびメディアライブラリ５０８の全体的動作を行うために、プロセッサ５０２を含み、すべて、プロセッサ５０２に連結される。上述のように、例示的サーバ１０４は、当業者によって周知の標準的ウェブサーバであり得る。ＵＥ１０２と通信するために、例示的サーバ１０４は、ネットワーク化された通信（例えば、ＩＥＥＥ（登録商標）（Ｉｎｓｔｉｔｕｔｅ ｆｏｒ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１を介した無線ローカルエリアネットワーク通信、および／またはＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋｓ（ＵＴＲＡＮ）における無線通信）を促進するための通信サブシステム５１０を含む。例示的通信サブシステム５１０は、図７に関連して後述される、例示的通信サブシステム７１１に実質的に類似し得る。図５の例示的サーバ１０４は、サーバ１０４から、図１、２Ａ、および２Ｂの例示的ＵＥ１０２等の１つ以上のＵＥに送信される、３ＧＰＰファイルのオブジェクトボックスコンテンツを生成および／または別様に管理するために、任意のメディアファイルマネージャ５１２に通信可能に接続され得る。

動作時、例示的通信サブシステム５１０は、標準的ＨＴＴＰ ＧＥＴコマンド等のメディアのための要求とともに、ＵＥ１０２からＨＴＴＰ接続を受信する。メディア要求は、ＴＣＰ伝送をサーバ１０４にダイレクトする、ＵＥ１０２のユーザによってタイプおよび／または別様に選択されたＵＲＬを含み得る。例示的サーバ１０４は、例えば、サーバ１０４の内部および／または外部の１つ以上のデータベースとして実装され得る、１つ以上のメディアライブラリ５０８からの要求と関連付けられた３ＧＰＰメディアファイルを読み出す。いくつかの実施例では、メディアを提供する当事者は、１つ以上のボックスタイプ順序および／または構成を確認するための３ＧＰＰファイルを構築する。他の実施例では、例示的メディアファイルマネージャ５１２は、ボックスタイプおよび／またはボックスタイプ階層的配置によって、確認するための読み出された３ＧＰＰファイルを構築および／または別様に修正する。例えば、例示的メディアファイルマネージャ５１２は、標的ＵＥ１０２が、図３に示されるように、受信後、可能な限り早く利用可能な代替メディアコンテンツを識別可能なように、「ｍｏｏｖ」ボックス３０６の参照先として、「ｍｅｔａ」ボックス３０８を含み得る。一方、例示的メディアファイルマネージャ５１２は、単独最上位ボックスとして、「ｍｅｔａ」ボックス３０８を含み得る。および／または選択された３ＧＰＰファイルの構築および／または拡張の完了に応じて、例示的通信サブシステム５１０は、ＨＴＴＰを介して、３ＧＰＰファイルを要求ＵＥ１０２に伝送する。しかしながら、クライアント制御セッションレス適応を促進するための本明細書に説明される例示的方法および装置は、業界標準ＨＴＴＰウェブサーバとともに採用され得る。

例示的メディアファイルマネージャは、ＳＤＰ情報を含むように、選択された３ＧＰＰファイルを構築および／または拡張し得る。上述のように、「ｕ＝」フィールド４０６は、受信ＵＥ１０２に、付加的メタデータが格納される場所を識別可能にするためのＵＲＬとともにポピュレートされ得る。例示的「ｕ＝」フィールド４０６の使用は、例えば、選択された３ＧＰＰファイルのためのメタデータペイロードの減少を可能にする。その結果、ＵＥ１０２によって受信されたメディアコンテンツは、サーバ１０４からＵＥ１０２に転送するためのタデータペイロード情報が少ないため、より早くレンダリングし得る。

図６は、図５の例示的メディアファイルマネージャ５１２の付加的詳細を例証する。図６の例証される実施例では、メディアファイルマネージャ５１２は、オブジェクトボックスマネージャ６０２と、ライブストリーミングメタデータアップデータ６０４と、を含む。動作時、例示的オブジェクトボックスマネージャ６０２は、ＵＥ１０２に、どのコンテンツがサーバ１０４上で利用可能であるかを認識可能にするように、オブジェクトボックスを構築、配列、および／または選択された３ＧＰＰファイルに加える。したがって、ＵＥ１０２は、例えば、伝送選好および／またはＵＥ１０２の既存チャネル条件に基づいて、メディア適応に関与し得る。例示的オブジェクトボックスマネージャ６０２は、例示的フラッシュメモリ５０４等、メモリ内に格納された１つ以上のボックス順序プロファイルに基づいて、１つ以上のオブジェクトボックスを階層順序に配列し得る。

プロファイルは、任意の選択された３ＧＰＰファイルのメタデータペイロードを最小限にすることによって、ＵＥ１０２による受信後、可能な限り早く、メディアレンダリングを促進する、オブジェクトボックス順序構成を含み得るが、それらに限定されない。そのようなペイロード最小限化は、１つ以上の離散メタデータ値タイプではなく、「ｍｅｔａ」ボックス３０８内のメタデータ参照ＵＲＬを含む、オブジェクトボックスマネージャ６０２によって達成され得る。加えて、または代替として、例示的オブジェクトボックスマネージャ６０２は、「ｕ＝」フィールド４０６を利用して、メタデータ参照ＵＲＬを関連付けることによって、「ｈｎｔｉ」ボックス４０２を採用し得る。一方、例示的オブジェクトボックスマネージャ６０２は、例えば、３ＧＰＰファイル内の初期にメタデータを含むことによって、ＵＥ１０２のためのメディア適応選択肢の早期認識を促進するように、１つ以上のオブジェクトボックス構成を順序付け得る。したがって、ＵＥ１０２は、初期「ｆｔｙｐ」ボックス３０４が、現在のチャネル条件により好適な代替のエンコードされたメディア構成ファイルを入手直後、１つ以上のボックス（例えば、「ｍｅｔａ」ボックス３０８）を解析し得る。したがって、例示的ＵＥ１０２は、代替（例えば、より低い帯域幅）メディアファイルを支持して、係属中の３ＧＰＰファイルダウンロードに対する全試行を直ぐに停止し得る。

例示的ライブストリーミングメタデータアップデータ６０４は、周期的、非周期的、スケジュール化、および／または手動ベースに基づいて、ライブ−ストリーム−メタファイルをアップデートするように動作し得る（図２Ａの交換２１４参照）。上述のように、事前に記録されたメディアは、典型的には、メディア内の個々のトラックおよび／またはシークポイントを記述し、例えば、シーク動作、再生、巻戻、早送等を有効化するためのメタデータの比較的に詳細コンパイルを含む。しかしながら、ライブメディアコンテンツは、典型的には、そのような制御を可能にする関連付けられたメタデータをほとんど含有しない。したがって、メディアコンテンツ作成者は、典型的には、ライブメディアコンテンツを含む１つ以上の３ＧＰＰファイルを作成する前に、フラグメントインデックス値および／またはデータオフセット値を作成するための十分な時間および／または処理能力のみ有する。例示的ライブストリーミングメタデータアップデータ６０４は、利用可能となると直ぐに、フラグメントインデックス値および／またはデータオフセット値を読み出し、そのような値をライブ−ストリーム−メタファイルにプリペンドする。メディアイベントの継続に伴って、関連付けられたライブ−ストリーム−メタファイルは、ファイルの開始時に保存された最新のフラグメントインデックス値および最新のデータオフセット値とともに、サイズが増大する。

図７は、本開示に従って実装可能な、例示的ＵＥである。ＵＥ７００は、好ましくは、少なくとも、音声およびデータ通信能力を有する、双方向無線通信デバイスである。ＵＥ７００は、好ましくは、ネットワーク、イントラネット、および／またはインターネット上の他のコンピュータシステムと通信する能力を有する。提供される正確な機能性に応じて、無線デバイスは、実施例として、データメッセージングデバイス、双方向ページャ、無線電子メールデバイス、データメッセージング能力、無線インターネット装置、またはデータ通信デバイスを伴う携帯電話と称され得る。

ＵＥ７００が、双方向通信のために有効化される場合受信機７１２および送信機７１４の両方を含む通信サブシステム７１１、ならびに１つ以上の、好ましくは、内蔵または内部アンテナ要素７１６および７１８、ローカル発振器（ＬＯ）７１３、デジタル信号プロセッサ（ＤＳＰ）７２０等の処理モジュール等の関連付けられた構成要素を組み込むであろう。通信サブシステム７１１の特定の設計は、デバイスが動作するように意図される、通信ネットワークに依存するであろう。例えば、ＵＥ７００は、汎用パケット無線システム（ＧＰＲＳ）ネットワークおよび／またはＵＭＴＳネットワーク内で動作するように設計される、通信サブシステム７１１を含み得る。

ネットワークアクセス要件はまた、ネットワーク７１９のチアプに応じて、可変であるでろう。例えば、ＵＭＴＳおよびＧＰＲＳネットワークでは、ネットワークアクセスは、ＵＥ７００の加入者またはユーザと関連付けられる。したがって、例えば、ＧＰＲＳモバイルデバイスは、ＧＰＲＳネットワーク上で動作するために、加入者識別モジュール（ＳＩＭ）カードを要求する。ＵＭＴＳでは、汎用加入者識別モジュール（ＵＳＩＭ）またはＳＩＭモジュールが、要求される。しかしながら、ＣＤＭＡでは、可撤性ユーザ識別モジュール（ＲＵＩＭ）カードまたはモジュールが、要求される。これらは、本明細書では、ＵＩＭインターフェースと称されるであろう。有効なＵＩＭインターフェースがない場合、モバイルデバイスは、完全に機能し得ない。ローカルまたは非ネットワーク通信機能、ならびに緊急呼等の法的に要求された機能（該当する場合）は、利用可能であり得るが、モバイルデバイス７００は、ネットワークを介した通信を伴う、任意の他の機能を実行不可能であろう。ＵＩＭインターフェース７４４は、通常、ディスケットまたはＰＣＭＣＩＡカードのような挿入または排出可能である、カードスロットに類似する。ＵＩＭカードは、約６４Ｋのメモリを有し、多くのキー構成７５１、識別等の他の情報７５３、および加入者関連情報を保持可能である。

要求されるネットワーク登録またはアクティブ化プロシージャが、完了されると、ＵＥ７００は、ネットワーク７１９を介して、通信信号を送受信し得る。通信ネットワーク７１９を通して、アンテナ７１６によって受信された信号はアナログ／デジタル（Ａ／Ｄ）変換を含む、信号増幅、周波数下方変換、フィルタリング、チャネル選択等の共通受信機機能を行い得る、、受信機７１２に入力される。受信した信号のＡ／Ｄ変換は、ＤＳＰ７２０内で行われる復調およびデコード等のより複雑な通信機能を可能にする。同様に、伝送される信号は、例えば、ＤＳＰ７２０による変調およびエンコードを含め、処理され、デジタル／アナログ変換、周波数上方変換、フィルタリング、増幅、およびアンテナ７１８を介した通信ネットワーク７１９上の伝送のために、送信機７１４に入力される。ＤＳＰ７２０は、通信信号を処理するだけではなく、また、受信機および送信機制御を提供する。例えば、受信機７１２および送信機７１４内の通信信号に印加される増幅率は、ＤＳＰ７２０内に実装される自動増幅率制御アルゴリズムを通して、適応的に制御され得る。

さらに、ネットワーク７１９は、例示的サーバ１０４等のサーバ７６０と、他の要素（図示せず）と、を含む、多重システムと通信し得る。例えば、ネットワーク７１９は、１つ以上のサービスレベルを伴う、１つ以上のクライアントに対応するために、企業システムおよびウェブクライアントシステムの両方と通信し得る。

ＵＥ７００は、デバイスの全体的動作を制御する、マイクロプロセッサ７３８を含む。少なくともデータ通信を含む、通信機能は、通信サブシステム７１１を通して行われる。マイクロプロセッサ７３８はまた、ディスプレイ７２２、フラッシュメモリ７２４、ランダムアクセスメモリ（ＲＡＭ）７２６、補助入力／出力（Ｉ／Ｏ）サブシステム７２８、シリアルポート７３０、キーボード７３２、スピーカ７３４、マイクロホン７３６、短距離通信サブシステム７４０、および、概して、７４２として指定される、任意の他のデバイスサブシステム等のさらなるデバイスサブシステムと相互作用する。

図７に示されるサブシステムのいくつかは、通信関連機能を行う一方、他のサブシステムは、「常駐」またはデバイス上機能を提供し得る。注目すべきこととして、例えば、キーボード７３２およびディスプレイ７２２等のいくつかのサブシステムは通信ネットワークを介した伝送のためのテキストメッセージの入力等の通信関連機能と、計算機またはタスクリスト等のデバイス常駐機能の両方のために使用され得る。

マイクロプロセッサ７３８によって使用されるオペレーティングシステムソフトウェアは、フラッシュメモリ７２４等の永続的記憶装置内に格納され得るが、代わりに、読取専用メモリ（ＲＯＭ）または類似記憶要素（図示せず）であってもよい。当業者は、オペレーティングシステム、特定デバイスアプリケーション、またはその一部が、ＲＡＭ７２６等の揮発性メモリ内に一時的にロードされ得ることを理解するであろう。受信した通信信号はまた、ＲＡＭ７２６内に格納され得る。さらに、一意の識別子もまた、好ましくは、読取専用メモリ内に格納される。

示されるように、フラッシュメモリ７２４は、コンピュータプログラム７５８とプログラムデータ記憶装置７５０、７５２、７５４、および７５６の両方に対して、異なる領域に分離可能である。これらの異なる記憶タイプは、各プログラムが、そのそれぞれのデータ記憶要件に対して、フラッシュメモリ７２４の一部を配分可能なことを示す。加えて、フラッシュメモリ７２４は、オブジェクトボックスパーサモジュール７７０と、無線状態モニタモジュール７７２と、動作閾値モジュール７７４と、メディアセレクタモジュール７７６と、を含む。オブジェクトボックスパーサモジュール７７０は、サーバ１０４から受信した３ＧＰＰファイルを解析し、１つ以上の着目オブジェクトボックスを識別する。例えば、オブジェクトボックスパーサモジュール７７０は、「ｍｅｔａ」ボックス３０８のインスタンスを識別し、その中のコンテンツを抽出し、ストリーミングのために利用可能なエンコードされたメディア構成選択肢を識別するように構成され得る。１つ以上の解析されたオブジェクトボックスから抽出された利用可能なメディア選択肢は、後の読出および／または選択のために、例示的フラッシュメモリ７２４等のメモリ内に格納され得る。上述のように、代替メディアコンテンツを有する代替メディア選択肢の後の読出および／または選択は、例示的ＵＥ１０２のチャネル条件が不満足な状態になる時に生じ得る。

例示的無線状態モニタ７７２は、ＵＥ９００の動作条件を監視し、測定値を動作閾値モジュール７７４内の１つ以上の閾値と比較する。サービスの質および／またはＵＥ７００のユーザに満足のゆく程度にレンダリングする対応する能力を示し得る、測定値は、ビットレート、待ち時間値、および／またはジッタ値を含むが、それらに限定されない。１つ以上の測定値が、閾値を超える場合（例えば、許容限度の下限を下回る、許容限度の上限を上回る）、例示的無線状態モニタモジュール７７２は、メディアセレクタモジュール７７６に、通信サブシステム７１１を起動し、現在の動作条件のためにより好適な代替メディアを読み出す（例えば、より低い分解能を有する３ＧＰＰファイルを選択する）ように指示し得る。

図８は、クライアント制御セッションレス適応を促進するために使用され得る、コンピュータ可読命令を表す、例示的フロー図を描写する。図８の例示的動作は、プロセッサ、コントローラ、および／または任意の他の好適な処理デバイスを使用して行われ得る。例えば、図８の例示的動作は、プロセッサ（例えば、図７のプロセッサ７３８および／または図５のプロセッサ５０２）と関連付けられたフラッシュメモリ、読取専用メモリ（ＲＯＭ）、および／またはランダムアクセスメモリ（ＲＡＭ）等の有形メディア上に格納されたコード化命令を使用して実装され得る。代替として、図８の例示的動作の一部または全部は、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブル論理デバイス（ＦＰＬＤ）、離散論理、ハードウェア、ファームウェア等の任意の組み合わせを使用して実装され得る。また、図８の例示的動作の一部または全部は、手動で、あるいは上述の技法のいずれかの任意の組み合わせ、例えば、ファームウェア、ソフトウェア、離散論理、および／またはハードウェアの任意の組み合わせとして、実装され得るさらに、図８の例示的動作は、図８のフロー図を参照して説明されているが、図８の動作を実装する他の方法も、採用され得る。例えば、ブロックの実行の順序は、変更され得、および／または説明されているブロックのいくつかは、変更、排除、再分割、または組み合わせられ得る。加えて、図８の例示的動作の一部または全部は、例えば、別個の処理スレッド、プロセッサ、デバイス、離散論理、回路等によって、逐次的および／または並行して、行われ得る。

一般に、図８の例示的フローズは、図７の例示的ＵＥ７００および／または図１、２Ａ、および２Ｂの例示的交換１００、２００、ならびに２５０を実装するために使用可能である。図８の例示的プロセス８００は、例示的ＵＥ１０２、７００上でメディアレンダリングのインスタンスを始動させるためのセッションレスメディア要求を伝送する（ブロック８０２）。セッションレスメディア要求の送信（ブロック８０２）に応答して、ＵＥ１０２、７００は、要求と関連付けられたデフォルト３ＧＰＰメディアファイルを受信する（ブロック８０４）。上述のように、関連付けられたメディアファイルは、ＵＥ１０２、７００のユーザによって提供されたＵＲＬに基づいて、および／またはユーザによって選択されたウェブリンクに応答して、受信され得る。デフォルト３ＧＰＰメディアファイルは、１つ以上の着目オブジェクトボックスを抽出するために、例示的オブジェクトボックスパーサ７７０によって解析される（ブロック８０６）。特に、オブジェクトボックスパーサ７７０は、「ｍｅｔａ」ボックス３０８の発生を識別し、その中に含有されるメタデータを抽出するように構成され得る。加えて、または代替として、例示的オブジェクトボックスパーサ７７０は、メタデータとして埋め込まれ、および／または例示的「ｈｎｔｉ」ボックス４０２の「ｕ＝」フィールドと関連付けられたＵＲＬを識別し得る。

受信した３ＧＰＰファイルと関連付けられたメタデータの入手に応じて、例示的オブジェクトボックスパーサ７７０は、ＵＥ１０２、７００に利用可能な１つ以上の代替のエンコードされたメディア構成選択肢を識別し得る（ブロック８０８）。例えば、解析されたメタデータは、１つ以上の代替３ＧＰＰファイルが、分解能および／またはビットレートの１つ以上の代替程度を有する、サーバ上で利用可能であることを識別し得る。解析されたメタデータはまた、各利用可能な代替メディアと関連付けられた１つ以上の場所（例えば、ＵＲＬ）を識別し得る。受信されたデフォルト３ＧＰＰファイル（ブロック８０４）が、現在のＵＥ１０２、７００チャネル条件に適切であるかどうかを判定するために、例示的無線状態モニタ７７２は、１つ以上のＵＥ動作条件を測定し、動作閾値モジュール７７４内に格納された１つ以上の動作閾値と比較する（ブロック８１０）。加えて、または代替として、例示的無線状態モニタ７７２は、ＵＥ性能能力と関連付けられた１つ以上のＵＥ動作条件を測定し得る。ＵＥ性能能力は、ＵＥが、バッファオーバーフローおよび／またはＵＥが処理／レンダリング可能な最大分解能に先立って、ビットストリームをレンダリングし得る、レートを含み得るが、それらに限定されない。１つ以上の閾値との比較が、代替３ＧＰＰファイルが必要ではないことを示す場合（例えば、現在の動作条件および／またはＵＥ性能能力が、１つ以上の閾値を侵害しないため）（ブロック８１２）、例示的メディアセレクタモジュール７７６は、デフォルト３ＧＰＰファイルをＵＥ１０２、７００上でストリーミングおよび／または別様にレンダリング可能にする（ブロック８１４）。一方、代替３ＧＰＰファイルが選択されるべき場合（ブロック８１２）（例えば、ＵＥ１０２、７００と関連付けられたチャネル条件が不良であるため）、例示的メディアセレクタモジュール７７６は、例示的通信サブシステム７１１を起動し、代替３ＧＰＰファイルのために、サーバ１０４へＨＴＴＰ要求を始動する（ブロック８１６）。上述のように、サーバへの後続ＨＴＴＰ要求は、代替のエンコードされたメディア構成選択肢の以前の識別（ブロック８０８）から得られた代替ＵＲＬを含み得る。

図９の例示的フロー図は、図５の例示的サーバ１０４および／または例示的図５ならびに６のメディアファイルマネージャ５１２、および／または図１、２Ａ、ならびに２Ｂの例示的交換１００、２００、および２５０を実装するために使用可能である。図９の例示的プロセス９００は、１つ以上のセッションレスＨＴＴＰ要求を監視する（ブロック９０２）。要求が受信されない場合、図９の例示的プロセス９００は、継続して待機し、そうでなければ、図６の例示的オブジェクトボックスマネージャ６０２は、要求された３ＧＰＰファイルと関連付けられた１つ以上のオブジェクトボックスを構築および／または別様にポピュレートする（ブロック９０４）。上述のように、１つ以上の３ＧＰＰファイルのオブジェクトボックスは、メディアコンテンツの責任当事者（例えば、放送局）によって、配列および／または構築され得る。例示的サーバ１０４は、通信サブシステム５１０を介して、セッションレスＨＴＴＰを介して（例えば、ＨＴＴＰ ＧＥＴコマンドに応答して）（ブロック９０６）、３ＧＰＰファイルを要求ＵＥに伝送し、メディアが、ライブイベントと関連付けられていない場合（ブロック９０８）、例示的サーバ１０４は、終了し、他の要求を継続して待機する（ブロック９０２）。制限としではないが、格納されたコンテンツフラグが、メディアコンテンツ作成者がローカル記憶を許可するかどうかを示すために、採用され得る。そうではない場合、コンテンツは、例示的ＵＥ１０２、７００によってレンダリングされた後、削除され得る。ＲＴＳＰを介した従来のストリーミングと異なり、本明細書に説明される方法および装置は、サーバに、アクティブ接続毎にセッションを作成、維持、および／または閉鎖する、重荷となる処理責任を負わせない。したがって、本明細書に説明される方法および装置とともに採用されるサーバは、ＲＴＳＰストリーミングを促進するメディアサーバよりコストが抑えられ得る。

メディアコンテンツが、ライブイベントと関連付けられる場合（ブロック９０８）、例示的ライブストリーミングメタデータアップデータ６０４は、ライブ−ストリーム−メタファイルをアップデートし、現在のファイルフラグメントインデックス値および現在のデータオフセット値（ブロック９１０）を反映する。上述のように、ＵＥ１０２、７００は、サーバ１０４にクエリを行い、そのような現在の値を入手し、ライブメディアのシーク（例えば、ＨＴＴＰ ＧＥＴ）を可能にし得る。例示的メディアファイルマネージャ５１２は、手動信号、周期的、非周期的、および／またはスケジュール化時間周期の間、待機し（ブロック９１２）、ライブメディアイベントが終了したかどうかを判定する（ブロック９１４）。そうではない場合、例示的ライブストリーミングメタデータアップデータ６０４は、ライブ−ストリーム−メタファイルをアップデートし、現在のファイルフラグメントインデックス値および現在のデータオフセット値を反映し（ブロック９１０）、そうでなければ、例示的サーバ１０４は、別の要求を待機する（ブロック９０２）。他の実施例では、メディアコンテンツプロバイダ（例えば、放送局）は、例示的ライブ−ストリーム−メタファイルのアップデート（例えば、プリペンド）に関与する。

マイクロプロセッサ７３８は、そのオペレーティングシステム機能に加え、好ましくは、モバイルデバイス上でのソフトウェアアプリケーションの実行を有効化する。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本動作を制御する所定の一式のアプリケーションが、通常、製造の際、ＵＥ７００上にインストールされるであろう。好ましいソフトウェアアプリケーションは、電子メール、カレンダーイベント、音声メール、予定、およびタスク項目等であるが、それらに限定されない、モバイルデバイスのユーザに関連するデータ項目を整理および管理する能力を有する、個人情報マネージャ（ＰＩＭ）アプリケーションであり得る。必然的に、１つ以上のメモリ記憶装置は、ＰＩＭデータ項目の記憶を促進するために、モバイルデバイス上で利用可能となるであろう。そのようなＰＩＭアプリケーションは、好ましくは、無線ネットワーク７１９を介して、データ項目を送受信する能力を有するであろう。好ましい実施形態では、ＰＩＭデータ項目は、無線ネットワーク７１９を介して、ホストコンピュータシステムに格納された、またはそれと関連付けられたモバイルデバイスユーザの対応するデータ項目と、シームレスに統合、同期、およびアップデートされる。さらなるアプリケーションはまた、ネットワーク７１９、補助Ｉ／Ｏサブシステム７２８、シリアルポート７３０、短距離通信サブシステム７４０、または任意の他の好適なサブシステム７４２を通して、モバイルデバイス７００上にロードされ、ユーザによって、マイクロプロセッサ７３８による実行のために、ＲＡＭ７２６、または好ましくは、不揮発性記憶装置（図示せず）内にインストールされ得る。そのようなアプリケーションのインストールにおける柔軟性は、デバイスの機能性を増加させ、デバイス上機能、通信関連機能、または両方の向上を提供し得る。例えば、セキュア通信アプリケーションは、ＵＥ７００を使用して、電子商取引機能および他のそのような金融取引を行うことを有効化し得る。しかしながら、これらのアプリケーションは、上述によると、多くの場合、通信事業者によって承認される必要があるであろう。

データ通信モードでは、テキストメッセージまたはウェブページダウンロード等の受信した信号は、通信サブシステム７１１によって処理され、好ましくは、受信した信号をディスプレイ７２２、または代替として、補助Ｉ／Ｏデバイス７２８への出力のためにさらに処理する、マイクロプロセッサ７３８に入力されるであろう。ＵＥ７００のユーザはまた、例えば、ディスプレイ７２２と、可能性として、補助Ｉ／Ｏデバイス７２８と併せて、好ましくは、完全英数字キーボードまたは電話式キーパッドである、キーボード７３２を使用して、電子メールメッセージ等のデータ項目を構成し得る。次いで、そのような構成された項目は、通信サブシステム７１１を通して、通信ネットワークを介して伝送され得る。

音声通信の場合、ＵＥ７００の全体的動作は、類似するが、受信した信号は、好ましくは、スピーカ７３４に出力され、伝送のための信号が、マイクロホン７３６によって生成されるであろう。音声メッセージ記録サブシステム等の代替音声またはオーディオＩ／Ｏサブシステムはまた、ＵＥ７００上に実装され得る。音声またはオーディオ信号出力は、好ましくは、主に、スピーカ７３４を通して達成されるが、ディスプレイ７２２はまた、例えば、発呼当事者の識別の表示、音声呼の持続時間、または他の音声呼関連情報を提供するために使用され得る。

図７におけるシリアルポート７３０は、通常、ユーザのデスクトップコンピュータ（図示せず）との同期が望ましくあり得る、携帯端末（ＰＤＡ）型モバイルデバイス内に実装されるであろう。そのようなポート７３０は、ユーザに、外部デバイスまたはソフトウェアアプリケーションを通して、選好を設定させ、無線通信ネットワークを通して以外のＵＥ７００への情報またはソフトウェアダウンロードを提供することによって、モバイルデバイス７００の能力を拡張するであろう。代替ダウンロード経路は、例えば、直接、したがって、信頼かつ信用された接続を通して、デバイス上に暗号化キーをロードするために使用され、それによって、セキュアデバイス通信を有効化し得る。

代替として、シリアルポート７３０は、他の通信のために使用され得、ユニバーサルシリアルバス（ＵＳＢ）ポートとして、含まれ得る。インターフェースは、シリアルポート７３０と関連付けられる。

短距離通信サブシステム等の他の通信サブシステム７４０は、ＵＥ７００と、必ずしも、類似デバイスである必要はない、異なるシステムまたはデバイスとの間の通信を提供し得る、さらなる任意の構成要素である。例えば、サブシステム７４０は、同様に有効化されたシステムおよびデバイスとの通信を提供するために、赤外線デバイスと、関連付けられた回路および構成要素またはＢｌｕｅｔｏｏｔｈ（登録商標）通信モジュールと、を含み得る。

ある方法、装置、および製品が、本明細書で説明されたが、本特許の範囲は、これらに限定されない。対照的に、本特許は、文字通り、または均等物の原理に基づいて、添付の請求項の範囲内にある全ての方法、装置、および製品を公正に網羅するものである。

従来のＲＴＳＰストリーミング技法は、クライアントとメディアサーバとの間の永続的伝送制御プロトコル（ＴＣＰ）接続の必要性を回避するが、メディアサーバは、メディアを要求するクライアント毎に、アクティブセッションを維持可能でなければならない。加えて、ＲＴＳＰストリーミングは、平均レートまたはメディアがエンコードされたレートで、クライアントにパケットを送信し、レートパケット伝送が、バッファ占有状態に基づいて、調整され得るが、従来のストリーミングおよび／またはパケット切替ストリーミング（ＰＳＳ）は、依然として、ファイアウォール、ネットワークアドレス変換（ＮＡＴ）を通過させることに関する課題を呈し、比較的に高価なストリーミングサーバを要求する。標準的ウェブサーバは、メディアストリーミングサーバと異なり、典型的には、メディアストリーミングサーバより有意に安価であって、ステートレスな様式でＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を採用する。言い換えると、業界標準ウェブサーバは、余剰処理電力および／または状態ベースの通信プロトコル（例えば、ＲＴＳＰ）の設定、維持、ならびに／あるいは分解と関連付けられる複雑性を伴わずに、ＨＴＴＰ（例えば、ＨＴＴＰ １．１）を採用し得る。したがって、メディアストリーミングサーバは、典型的には、一部には、需要に伴う、有意な処理要件のため、良好にスケーリングできない。一方、標準的ウェブサーバは、時として、クライアントによって要求されていないコンテンツを返す、「非知能型」サーバと称され、複雑性、コストを最小限にし、よりコストのかかるメディアストリーミングサーバより良好にスケーリングを行う。
例えば、本発明は以下の項目を提供する。
（項目１）
メディアコンテンツを管理する方法であって、
該方法は、
利用可能なメディアに対するメタデータ情報にアクセスすることと、
該アクセスされたメタデータから、少なくとも、ユニフォームリソースロケータ（ＵＲＬ）および１つ以上のバイト範囲を読み出すことであって、該利用可能なメディアの１つ以上の部分は、該１つ以上のバイト範囲と該ＵＲＬの組み合わせとによってアクセス可能である、ことと、
読み出されたメタデータに基づいて、該利用可能なメディアの第１の少なくとも１つの部分を要求する第１の要求を送信することと
を含む、方法。
（項目２）
上記第１の要求は、ＧＥＴコマンドである、項目１に記載の方法。
（項目３）
上記ＧＥＴコマンドは、少なくとも、範囲指定子を含む、項目２に記載の方法。
（項目４）
利用可能なメディアの１つ以上の部分は、１つ以上のＴｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）動画フラグメントを含む、項目１に記載の方法。
（項目５）
上記１つ以上の部分は、ｍｏｏｖボックス、ｍｏｏｆボックス、ｆｔｙｐボックス、またはｍｅｄｉａ ｄａｔａ（ｍｄａｔ）ボックスのうちの少なくとも１つを含む、項目１に記載の方法。
（項目６）
上記１つ以上のバイト範囲は、連続的である、項目１に記載の方法。
（項目７）
上記第１の少なくとも１つの部分は、第１の利用可能な帯域幅容量に基づく、項目１に記載の方法。
（項目８）
上記利用可能なメディアの第２の少なくとも１つの部分を要求する第２の要求を送信することをさらに含む、項目１に記載の方法。
（項目９）
上記第２の少なくとも１つの部分は、上記第１の少なくとも１つの部分と異なる、項目８に記載の方法。
（項目１０）
上記第２の少なくとも１つの部分は、第２の利用可能な帯域幅容量に基づく、項目８に記載の方法。
（項目１１）
上記第１の利用可能な帯域幅容量は、上記第２の利用可能な帯域幅容量と異なる、項目１０に記載の方法。
（項目１２）
メディアコンテンツを管理するデバイスであって、
該デバイスはプロセッサを含み、該プロセッサは、
利用可能なメディアのためのメタデータ情報にアクセスすることと、
該アクセスされたメタデータ情報から、少なくともユニフォームリソースロケータ（ＵＲＬ）および１つ以上のバイト範囲を読み出すことであって、該利用可能なメディアの１つ以上の部分は、該１つ以上のバイト範囲と該ＵＲＬの組み合わせによってアクセス可能である、ことと、
該利用可能なメディアの読み出された１つ以上の部分に基づいて、該利用可能なメディアの第１の少なくとも１つの部分を要求する第１の要求を送信することと
を行うように構成される、デバイス。
（項目１３）
上記第２の要求は、ＧＥＴコマンドである、項目１２に記載のデバイス。
（項目１４）
上記ＧＥＴコマンドは、少なくとも範囲指定子を含む、項目１３に記載のデバイス。
（項目１５）
上記プロセッサはさらに、
上記利用可能なメディアの第２の少なくとも１つの部分を要求する第２の要求を送信するように構成される、項目１３に記載のデバイス。
（項目１６）
上記第２の少なくとも１つの部分は、上記第１の少なくとも１つの部分と異なる、項目１５に記載のデバイス。
（項目１７）
上記第２の少なくとも１つの部分は、第２の利用可能な帯域幅容量に基づく、項目１５に記載のデバイス。
（項目１８）
上記第１の利用可能な帯域幅容量は、上記第２の利用可能な帯域幅容量と異なる、項目１７に記載のデバイス。
（項目１９）
利用可能なメディアの１つ以上の部分は、１つ以上のＴｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）動画フラグメントを含む、項目１２に記載のデバイス。
（項目２０）
上記１つ以上の部分は、ｍｏｏｖボックス、ｍｏｏｆボックス、ｆｔｙｐボックス、またはｍｅｄｉａ ｄａｔａ（ｍｄａｔ）ボックスのうちの少なくとも１つを含む、項目１２に記載のデバイス。
（項目２１）
上記１つ以上のバイト範囲は、連続的である、項目１２に記載のデバイス。
（項目２２）
上記第１の少なくとも１つの部分は、第１の利用可能な帯域幅容量に基づく、項目１２に記載のデバイス。

Claims (22)

1. メディアコンテンツを管理する方法であって、
   該方法は、
   利用可能なメディアに対するメタデータ情報にアクセスすることと、
   該アクセスされたメタデータから、少なくとも、ユニフォームリソースロケータ（ＵＲＬ）および１つ以上のバイト範囲を読み出すことであって、該利用可能なメディアの１つ以上の部分は、該１つ以上のバイト範囲と該ＵＲＬの組み合わせとによってアクセス可能である、ことと、
   読み出されたメタデータに基づいて、該利用可能なメディアの第１の少なくとも１つの部分を要求する第１の要求を送信することと
   を含む、方法。
2. 前記第１の要求は、ＧＥＴコマンドである、請求項１に記載の方法。
3. 前記ＧＥＴコマンドは、少なくとも、範囲指定子を含む、請求項２に記載の方法。
4. 利用可能なメディアの１つ以上の部分は、１つ以上のＴｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）動画フラグメントを含む、請求項１に記載の方法。
5. 前記１つ以上の部分は、ｍｏｏｖボックス、ｍｏｏｆボックス、ｆｔｙｐボックス、またはｍｅｄｉａ ｄａｔａ（ｍｄａｔ）ボックスのうちの少なくとも１つを含む、請求項１に記載の方法。
6. 前記１つ以上のバイト範囲は、連続的である、請求項１に記載の方法。
7. 前記第１の少なくとも１つの部分は、第１の利用可能な帯域幅容量に基づく、請求項１に記載の方法。
8. 前記利用可能なメディアの第２の少なくとも１つの部分を要求する第２の要求を送信することをさらに含む、請求項１に記載の方法。
9. 前記第２の少なくとも１つの部分は、前記第１の少なくとも１つの部分と異なる、請求項８に記載の方法。
10. 前記第２の少なくとも１つの部分は、第２の利用可能な帯域幅容量に基づく、請求項８に記載の方法。
11. 前記第１の利用可能な帯域幅容量は、前記第２の利用可能な帯域幅容量と異なる、請求項１０に記載の方法。
12. メディアコンテンツを管理するデバイスであって、
    該デバイスはプロセッサを含み、該プロセッサは、
    利用可能なメディアのためのメタデータ情報にアクセスすることと、
    該アクセスされたメタデータ情報から、少なくともユニフォームリソースロケータ（ＵＲＬ）および１つ以上のバイト範囲を読み出すことであって、該利用可能なメディアの１つ以上の部分は、該１つ以上のバイト範囲と該ＵＲＬの組み合わせによってアクセス可能である、ことと、
    該利用可能なメディアの読み出された１つ以上の部分に基づいて、該利用可能なメディアの第１の少なくとも１つの部分を要求する第１の要求を送信することと
    を行うように構成される、デバイス。
13. 前記第２の要求は、ＧＥＴコマンドである、請求項１２に記載のデバイス。
14. 前記ＧＥＴコマンドは、少なくとも範囲指定子を含む、請求項１３に記載のデバイス。
15. 前記プロセッサはさらに、
    前記利用可能なメディアの第２の少なくとも１つの部分を要求する第２の要求を送信するように構成される、請求項１３に記載のデバイス。
16. 前記第２の少なくとも１つの部分は、前記第１の少なくとも１つの部分と異なる、請求項１５に記載のデバイス。
17. 前記第２の少なくとも１つの部分は、第２の利用可能な帯域幅容量に基づく、請求項１５に記載のデバイス。
18. 前記第１の利用可能な帯域幅容量は、前記第２の利用可能な帯域幅容量と異なる、請求項１７に記載のデバイス。
19. 利用可能なメディアの１つ以上の部分は、１つ以上のＴｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）動画フラグメントを含む、請求項１２に記載のデバイス。
20. 前記１つ以上の部分は、ｍｏｏｖボックス、ｍｏｏｆボックス、ｆｔｙｐボックス、またはｍｅｄｉａ ｄａｔａ（ｍｄａｔ）ボックスのうちの少なくとも１つを含む、請求項１２に記載のデバイス。
21. 前記１つ以上のバイト範囲は、連続的である、請求項１２に記載のデバイス。
22. 前記第１の少なくとも１つの部分は、第１の利用可能な帯域幅容量に基づく、請求項１２に記載のデバイス。