ストリーミングメディアサービスを管理するための方法
【課題】ストリーミングメディアサービスを管理するための方法を提供する。
【解決手段】本方法は、ストリーミングメディアサービスの要求をクライアントから受信することを含む。本ストリーミングメディアサービスは、複数のメディアサービスコンポーネントを含む。さらに、本方法は、ネットワークの複数のサービスノードの或るサービスノードに、複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断することを含む。本方法はまた、或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知することを含む。
【解決手段】本方法は、ストリーミングメディアサービスの要求をクライアントから受信することを含む。本ストリーミングメディアサービスは、複数のメディアサービスコンポーネントを含む。さらに、本方法は、ネットワークの複数のサービスノードの或るサービスノードに、複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断することを含む。本方法はまた、或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知することを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングメディアサービスを管理するための方法に関する。
【背景技術】
【０００２】
［背景］
クライアントデバイスがメディアファイルの配信を要求することが、その要求したメディアファイルに対して雑音低減等の或る処理が行われることを伴って行うことができるシステムがある。要求されたメディア配信がサーバによって受信されると、メディアファイルは取り出され、次いで、要求された処理が、サーバによりそのメディアファイルに対して実行される。この処理が完全に行われると、サーバは、処理されたメディアファイルをクライアントデバイスへ送信する。このタイプのシステムに関連した問題がある。たとえば、サーバが、異なる要求側クライアントデバイスへのメディアファイルの処理及び送信の多くの個別の要求をハンドリングしようと試みている場合、クライアントデバイスのユーザは、かなり長い間待たなければならない場合がある。また、ストリーミングメディアファイルは非常に大きい場合があり、ストリーミング配信の開始前にその内容に対して要求された処理を完了するには長い時間を要する場合がある。これは、特に、クライアントデバイスのユーザが期限前に何かを完了しようと試みている場合に、そのユーザにフラストレーションを与えている場合がある。
【０００３】
これらの理由及び他の理由から、本発明が必要とされる。
【発明の開示】
【課題を解決するための手段】
【０００４】
［発明の概要］
本発明の一実施の形態は、ストリーミングメディアサービスを管理するための方法を含む。本方法は、ストリーミングメディアサービスの要求をクライアントから受信することを含む。本ストリーミングメディアサービスは、複数のメディアサービスコンポーネントを含む。さらに、本方法は、ネットワークの複数のサービスノードの或るサービスノードに、複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断することを含む。本方法はまた、複数のメディアサービスコンポーネントの或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知することを含む。
【発明を実施するための最良の形態】
【０００５】
［好ましい実施の形態の説明］
次に、本発明の実施の形態を詳細に参照する。本発明の実施の形態の例は、添付図面に示されている。本発明は、実施の形態と共に説明されるが、実施の形態は、本発明をこれら実施の形態に限定することを目的としているものではないことが理解されよう。逆に、本発明は、代替形態、変更形態、及び等価物を包含することを目的とし、これら代替形態、変更形態、及び等価物は、添付の特許請求の範囲によって画定された本発明の精神及び範囲内に含めることができる。さらに、本発明の以下の詳細な説明では、本発明の十分な理解を提供するために、多数の具体的な詳細が述べられている。しかしながら、本発明は、これらの具体的な詳細がなくても実施できることが当業者には明らかであろう。それ以外の場合には、本発明の態様を不必要に分かりにくくしないように、既知の方法、手順、コンポーネント、及び回路は詳細に説明していない。
【０００６】
［表記法及び用語法］
以下の詳細な説明のいくつかの部分は、計算システム又はデジタルシステムのメモリ内のデータビットに対するオペレーションの手順、論理ブロック、処理、及び他のシンボル表現の観点から提示される。これらの説明及び表現は、データ処理技術における当業者が自身の作業の内容を他の当業者に最も効果的に伝えるのに使用する手段である。手順、論理ブロック、プロセス等は、本明細書では、一般的に、所望の結果をもたらすオペレーション又は命令の自己矛盾のないシーケンスであると考えられる。オペレーションは、物理量の物理的な操作を含むことができる。必ずしもそうではないが、通例、これらの物理的な操作は、計算システム又は類似の電子計算デバイスにおける記憶、転送、組み合わせ、比較、及びそれ以外の操作を行うことができる電気信号又は磁気信号の形態を取る。便宜上の理由から、且つ、共通の用法に関して、これらの信号は、本発明に関しては、ビット、値、要素、シンボル、文字、用語、数字等と呼ばれる。
【０００７】
一方、これらの用語のすべては、物理的な操作及び物理量に言及するものと解釈されるべきであり、単なる便利なラベルであり、さらに、当該技術分野で一般に使用される用語に鑑みて解釈されるべきであることに留意すべきである。特に指定のない限り、以下の説明から明らかなように、本発明の説明の全体にわたって、「判断」、「適用」、「処理」、「実行」、「決定」、「確認」、「送信」、「受信」、「取り出し」、「提供」、「認識」、「生成」、「利用」、「除去」、「通知」、「排除」、「廃棄」、「実施」、「使用」、「記憶」等の用語を利用した説明は、データの操作及び変換を行う計算システム又は類似の電子計算デバイスの動作及びプロセスを指すことが理解される。データは、計算システムのレジスタ及びメモリ内では物理（電子）量として表され、他のデータに変換される。他のデータも、同様に、計算システムのメモリ若しくはレジスタ、又は、他のこのような情報ストレージデバイス、送信デバイス、若しくは表示デバイスの内部で物理量として表されるものである。
【０００８】
［導入］
デスクトップマシン又はラップトップマシン（たとえば、図１の１２２）は、ネット上でのランダムなブラウジングの入力（さまざまなＵＲＬ又は検索照会のタイプ入力）要件及び出力（信頼性のある高帯域幅の接続）要件をより良くサポートできることから、通常、人々は、自身のこれらのデバイスから自身のウェブブラウジングの経験に基づいてさまざまなコンテンツサイト（たとえば、ビデオに基づく映画のページ）の位置を知る。これらのウェブユーザは、高帯域幅無線アクセスの保証があることを信じて、自身の携帯情報端末（ＰＤＡ）、たとえば１１０、１１６、及び１２０、又は、ビデオ使用可能携帯電話、たとえば１１２、１１４、及び１１８を使用して同じサイトへの接続を試みる場合がある。このより幅広いアクセスの結果、コンテンツプロバイダは、（接続の帯域幅に従った）広範囲の異なるビットレート、（処理能力管理ストラテジーに従ってそれ自体動的に変化する、クライアントデバイスで利用可能なＣＰＵ処理能力に従った）ビデオフレームレート、及び（クライアントデバイスで利用可能な表示サイズに従った）ビデオフレームサイズをサポートする必要がある。また、日本の３ＧＰＰ［１］プロバイダが遭遇するように、軽量のクライアントからの移動アクセスをサポートするには、サーバが、多数のセッションの状態変数を保持して更新することが必要とされる。簡潔にし、且つ、明瞭にするために、参考文献［１］〜［２０］の引用の詳細なリスト一式が本明細書の後部に見られる。これらリストされた参考文献［１］〜［２０］のすべては、背景資料として参照により本明細書に援用されることに留意されたい。たとえば、夕方の移行期の間、数千の移動ユーザの「フラッシュクラウド（flash crowd）」が東京の都心のオフィスエリアからレストラン地区へ多く見られる。
【０００９】
したがって、問題は２つの部分から成る。一方は、クライアントの能力に動的に調整されたフォーマットでビデオコンテンツ及び音響コンテンツを提供することである。他方は、そのストリーミングプロセスのサポートを動的に分散させて、不要な輻輳及びその結果生じる品質劣化を回避することである。この解決法の双方の部分が依存する因子は、それ自体、多くの場合、素早く変化しているので、これら双方の部分は動的に行われるべきである。
【００１０】
メディアサービスが、ストリーミングコンテンツ配信ネットワーク（ＣＤＮ（content -delivery network））基盤内において分散形式で統合及び管理されない限り、移動ストリーミングメディア（ＭＳＭ（mobile streaming media））の無線デバイスの潜在能力は、完全には実現されないことになる。本発明者等は、無線移動ストリーミングクライアントをサポートする既存のネットワーク基盤にわたって、信頼性のあるスケーラブルなメディアストリーミングを提供することに関して背景となる研究を説明する。本発明者等は、ＣＤＮ内で利用可能な分散資源の動的な監視によって、メディアサービスの管理された配置の手法を概説する。資源監視手法間のトレードオフも説明される。これは、本発明者等のＭＳＭ−ＣＤＮテストベッド内におけるサービスロケーションマネージャ（ＳＬＭ（service location manager））の例示のインプリメンテーションの説明としてのものであり、且つ、当該ＳＬＭの結果として生じるものである。
【００１１】
［移動クライアントへの適合型ストリーミングコンテンツ配信］
図１内において、移動ストリーミングメディアシステムの基本コンポーネントは、記憶されたメディアコンテンツ用のストリーミングサーバ（たとえば、１０２）、ライブストリーミングサーバ、及びストリーミングメディアクライアント（たとえば、１１０〜１２０）を含む。スケーラブルな形式で多数のユーザにビデオクリップを配信するために、既存のネットワーク上で、たとえば図３に示すような本発明のＭＳＭ−ＣＤＮオーバーレイを使用することができる。このＭＳＭ−ＣＤＮオーバーレイは、ストリーミングエッジ（又は代理（surrogate））サーバ及び管理サーバを含む。ストリーミングエッジサーバは、コンテンツの分配／キャッシュ機能［１６］、ストリーミング機能、資源監視機能、資源管理機能、及びシグナリング機能を有する。また、ストリーミングエッジサーバは、ライブメディアの適合等のメディアサービス機能も実行することができる。管理サーバは、コンテンツを分配させ、クライアントの位置並びに現在のシステム及びネットワークの負荷に基づいてメディアセッションを割り当てる。換言すると、管理サーバは、クライアントが要求したセッションを利用可能な最良のエッジサーバに割り当てる。
【００１２】
ＭＳＭ−ＣＤＮシステムは、表示能力及び復号能力の観点から、幅広いクライアントのサポートを援助すべきである。図１内において、これを行う「従来」の方法は、送信元の素材の複数のコピーをコンテンツサーバ１０２に記憶し、次いで、クライアント（たとえば、１１２、１１４、１１６、及び１２０）との或る初期交渉に従ってどのコピーを送信するか（たとえば、矢印１２４、１２６、１２８、及び１３０によって示すように）を選択することである。しかしながら、ストリーミングセッション中に、ネットワーク１００のさまざまな部分からクライアントへの接続の信頼性及び帯域幅は、クライアントが物理的な位置を移動すると変化し、また、他のクライアントからのストリーミングセッションが、共有された無線環境内で開始及び終了すると変化する。この交渉は、複数の記憶された符号化によって容易に提供されるものよりも広範囲の選択肢に及ぶ必要があり、その交渉プロセスは、ネットワークの状態が変化するにつれて動的に更新されるべきである。リアルタイムのメディアサービスは、今日のネットワークサーバマシンにおいて実用的且つ入手可能であるので、メディアレート、サイズ、及び帯域幅のこの広範囲な必要性は、図２のネットワーク２００内にメディアサービスを組み込むことによって満たすことができる。図２内において、矢印２０８は、コンテンツサーバ１０２からメディアサービスノード２０２へ出力されるストリーミングメディアを示しているのに対して、矢印２１０は、サービスノード２０２からクライアント１０２への処理されたメディアストリーミングを示している。図１のネットワーク１００及び図２のネットワーク２００は、無線基地局１０４、１０６、及び１０８を含むことに留意されたい。これらの無線基地局は、移動クライアントデバイス１１０、１１２、１１４、１１６、１１８、１２０、及び１２２との無線通信の一部として利用することができる。
【００１３】
このリアルタイムで待ち時間の少ないメディアサービングを提供することは、メディアサービスノードとも呼ばれるエッジサーバ［２、７］の重要な機能の１つである。メディアサービスプロセスは、たとえば、圧縮ビデオストリームをクライアントディスプレイに適合させることができる。また、メディアサービスプロセスは、ＲＴＣＰベースのフィードバックを使用して、クライアントデバイスによって経験された、変化する帯域幅の状態に、ストリーム内のビットレートを動的に調整することができる。これらのリアルタイムのメディアサービス提供は、今や、圧縮領域処理［１４、１５、１０］を使用することにより、標準的なデスクトップマシン又はサーバマシンに設けることができる。
【００１４】
これらの新しい圧縮領域のサービス提供技法は、個々の各サービス提供セッションの計算コストを大幅に削減することができ、それによって、移動ストリーミングを実用的且つ入手可能なものにすることができる。しかしながら、コンテンツ管理と同様に、メディアサービスストリームのサイズ及び継続時間並びにそれらのストリームを変更することに関連した計算要求は、注意深い管理を必要とする場合がある。数千又は数百万の移動クライアント（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）が存在する状況では、分散されたエッジサービスとしてメディアサービスを提供できるように、計算能力の高いサーバがその基盤全体にわたって離散され得る。
【００１５】
たとえば、上記説明によって必要とされたメディアサービスを提供する１つの方法は、各コンテンツサーバが、固定されたメディアサービスノード（たとえば、図２の２０２、２０４、又は２０６）へのクライアントブラウザ（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）の静的なリダイレクトを提供することである。このタイプの静的なリダイレクトは、コンテンツ配信の観点からよく検討される。ローカルな「ミラー」サイトへのリダイレクトは、今日のウェブ環境では日常的に行われている。この静的なリダイレクトの不利な点は、この静的なリダイレクトが、ネットワーク１００及びサーバの負荷の変動のいずれも考慮していないことである。さまざまなノード（又はサーバ）で利用可能な帯域幅及び計算負荷は、クライアントの変化する要件に従って変化し、且つ、新たに追加されたクライアント又は新たに取り除かれたクライアントの変化する要件に従って変化する。したがって、異なるサーバにおけるメディアサービスプロセスの配置は、それ自体、動的であるべきであり、好ましくは、クライアントプロセッサが物理的な位置を変更するにつれて調整されるべきである。最後に、移動ウェブブラウジングを行う一般の人々が簡単に使用できるように、これらの動的な決定のすべては、隠蔽され、自動的にすることができる。
【００１６】
［サービスロケーション管理（ＳＬＭ）］
図３内において、動的なサービスロケーション管理の背後にあるアイデアは、最初の接触サイトを変更するように移動ユーザ（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）に要求することなく、移動ストリーミング環境で必要とされる柔軟性を提供することである。一般的なシステムは、そうしないで、或る個数の広く公表されたポータルサイト（たとえば、３０４及び３０６）を提供する。これらのポータルは、（矢印３０８によって示すように）移動ユーザの最初の接触点であり、元のコンテンツサイトへのリダイレクトを受け付ける（コンテンツサーバ１０２への矢印３１０によって示される）。その後のすべてのリダイレクトは、動的なＳＭＩＬ書き換え［１６］を使用して、クライアントにトランスペアレントな方法で行われる。
【００１７】
一般に、図３は、クライアントデバイス１２０からサービスポータル３０６に入る要求を矢印３０８で示している。したがって、図４のサービスポータル３０６は、その後、（矢印４０４によって示すように）サービスロケーションマネージャ３０２と通信して、要求されたストリーミングメディアセッションを配置するための最良のサービスノードを見つけ出す。また、図４は、サービスロケーションマネージャ３０２が、双方向矢印４０６、４０８、及び４１０によって示される１組のメディアサービスノード２０２、２０４、及び２０６を観察又は監視していることも示している。サービスロケーションマネージャ３０２は、ストリーミングセッションを配置するための最良のサービスノードをサービスポータル３０６へ返す。したがって、図３、図４、及び図５は、セッションを開始させる方法のオペレーションを示している。図９は、その後の要求がネットワーク３００内に配置された時に、それらの要求が、それぞれそれらの同じオペレーションを通過することを示している。図５Ａ及び図５Ｂは、サービスロケーションマネージャ３０２が、二点鎖線の楕円５０６によって示すように或るサービスノード（たとえば、２０２）から別のサービスノード（たとえば、２０４）へ現在のセッションの割り当てを変更できることを示している。メディアサービスノード（たとえば、２０２、２０４、及び２０６）は、それぞれ、ハードウェア、ソフトウェア、又は、ハードウェア及びソフトウェアのあらゆる組み合わせとして実施することができることに留意されたい。これに加えて、サービスノード（たとえば、２０２、２０４、又は２０６）は、１つ又は複数の物理的な計算デバイスとして実施することができる。
【００１８】
図４内において、ポータルサイト３０６は、矢印３０８によって示すようにクライアント１２０により接触されると、矢印４０４によって示すようにサービスロケーションマネージャ（ＳＬＭ）３０２と接触する。単一のＳＬＭ３０２が自身の利用可能なサービスのポートフォリオに複数のタイプのサービスを有することができることに留意されたい。したがって、ＳＬＭ３０２は、各メディアサービスノード（たとえば、２０２、２０４、又は２０６）がメディアのストリームに対して実行できるサービスを（たとえば、テーブルで）把握している。メディアサービスには、ビデオ処理が含まれ得る。このビデオ処理は、トランスコード、ジッタ除去、顔認識に基づくダイナミッククリッピング、ビデオ解析、ビデオのサイズ変更、ビデオからのＯＣＲ、音響強調（audio enhancement）、背景除去、ビデオメディアのストリームに対して動作できるあらゆるもの等であるが、これらに限定されるものではない。これに加えて、メディアサービスには、音響処理が含まれ得る。この音響処理は、背景除去、音響速度の増減、音響強調（audio enhancement）、雑音低減、発話認識、音響解析、音響メディアのストリームに対して動作できるあらゆるもの等であるが、これらに限定されるものではない。次いで、ＳＬＭ３０２は、自身の決定を行っている時に、そのテーブルを一覧して、１つ又は複数のどのサービスノードが、要求された特定のメディアサービスを実行できるかを見つけ出す。
【００１９】
ポータルサイト３０６がＳＬＭ３０２と接触すると、ＳＬＭ３０２は、次に、要求された素材を所与のクライアント（たとえば、１２０）に供給するのにどのタイプのメディアサービスが必要とされるかを判断し、（部分的又は完全に）ＳＬＭ３０２の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のステータスを調べる。そのステータスは、メディアサービスノードのそれぞれにおける利用可能なサイクル及び利用可能なメモリの観点から要約することができる。付加的なステータス指示子が、メディアサービスノードのそれぞれからコンテンツプロバイダ（又は最も近いミラーサイト）への接続及びストリーミングクライアントへの接続の予想された帯域幅及び信頼性を含むことができる。収集されたステータス情報に基づいて、ＳＬＭ３０２は、ＳＭＩＬファイルを動的に生成し、その新たに生成されたＳＭＩＬ応答に、交渉されたあらゆるパラメータと共に自身のＵＲＬを組み込むことによって、適切なサービスノードへクライアントのリダイレクトを行う（図５）。３ＧＰＰ又はＩＳＭＡ［５］に準拠したストリーミングクライアントは、次に、書き換えられたＳＭＩＬファイルを構文解析して、コンテンツサーバ１０２及びメディアサービスノード２０２との適切なストリーミングセッションをセットアップする。したがって、全体の処理はエンドユーザにトランスペアレントである。矢印５０２は、コンテンツサーバ１０２からメディアサービスノード２０２へのメディアのストリーミングを示しているのに対して、矢印５０４は、サービスノード２０２からクライアント１２０への処理されたメディアストリームのストリーミングを示していることに留意されたい。メディアサービス提供を必要とする他のクライアントからのその後のコンテンツ要求も、新たな現在のネットワーク資源及び計算資源に従って分散される（図９）。
【００２０】
動的サービスロケーションのための資源監視
上記説明では、ＳＬＭ３０２は、自身の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のそれぞれのステータスを調べて、現在のクライアント要求により必要とされるメディアサービスタスクをどのようにディスパッチするのが最良であるかを判断する。この調査を完了できるさまざまな方法がある。以下では、本発明に従って実施できるいくつかの異なる実施の形態を詳述する。
【００２１】
基本的な「ポーリングベース」の監視
一実施の形態内では、ＳＬＭ３０２の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のステータスを監視する一手法は、プロセスが「ポーリングベース」であることである。この手法では、ＳＬＭ３０２は、メディアサービスの新たなクライアント要求を得るたびに、（たとえば、そのＣＰＵの個数及びクロック速度、その設置されたメモリ、並びにその最良の場合のネットワーク帯域幅の観点から）十分な資源を有する可能性のあるサービスノードのそれぞれと積極的に接触する。この「資源ポーリング」に応答して、各サービスノード（たとえば、２０２、２０４、又は２０６）は、自身の現在利用可能な資源の記述を提供する。この記述は、所与の時点における空き状態の計算サイクル数及び空き状態のメモリ量を含むことができる。理想的には、この記述は、コンテンツサーバ１０２及びクライアント（たとえば、１１０〜１２０）への空き状態のネットワーク帯域幅の或る見積もりも含む。ＳＬＭ３０２は、この情報を収集し、次に、空き状態のネットワーク帯域幅、計算資源、及びメモリ資源の最良の組み合わせを提供するサービスノードならばいずれのサービスノードへでも、要求されたメディアサービスタスクをディスパッチすることができる。
【００２２】
この「ポーリングベース」の手法は、空き状態のサービスノード資源の最新のスナップショットを提供するという利点を有する。また、この手法は、サービスノードが、ネットワーク障害又はマシン障害のいずれかによって非稼動状態である時の明瞭な表示も提供する。他方、ポーリングベースの資源監視は、拡張性の観点から厳しい制限を有する。クライアント要求の個数及び監視されるメディアサービスノードの個数が増大するにつれて、それらの所産としてポーリング要求の個数も増大する。監視されるメディアサービスノードの個数は、クライアントのサービス要求の個数に正比例して増大する傾向があるので、ポーリング要求の個数は、事実上、クライアントの個数の２乗として増大する。
【００２３】
基本的な「テーブルベース」の監視
ポーリングの実施の形態に代わるものは、資源情報がメディアサービスノード（たとえば、２０２、２０４、及び２０６）から監視を行うＳＬＭ３０２へ「プッシュされる」ものである。この手法では、更新は、システム及びネットワークの管理ソフトウェアによって提供される等、サービスロケーションスーパーバイザ（ＳＬＳ（service location supervisor））によって周期的に提供される。このＳＬＳは、各メディアサービスノードで実行されている軽量のバックグラウンドデーモンとすることができる。各クライアント要求時に、ＳＬＭ３０２は、ＳＬＳが提供した情報を収集すること（及び日付を付けること）から作成された空き状態資源データベースにアクセスする。これによって、資源監視によって受ける接続要件が、メディアサービスノードの個数の２次依存関係から１次依存関係へ削減される。
【００２４】
さらに、ＳＬＭ３０２自体に監視能力及び「再開（re-launch）」能力を含めることもできる。単純なＳＬＭデーモンは、最新のＳＬＳデータベースリフレッシュのタイムスタンプを監視し、或るプリセット時間間隔よりも長い間接触していないＳＬＳマシンとの接触を試みる。おそらく、これらの接触の試みのかなりの部分は、進行中のネットワークの障害又はメディアサービスノードの障害のために失敗することになる。しかしながら、ＳＬＳの接触を再開しようとするこれらの試みは、非同期に行われるので、クライアント要求に対するＳＬＭ３０２の応答時間に影響を与えない。
【００２５】
テーブルベースの監視は、直接的なポーリングベースの結果よりも時期の遅れた資源情報に依拠するという不利な点を有する。この弱点は、資源監視の次の実施の形態によって対処される。
【００２６】
［ノードから受信された近時データに基づくＳＬＭの適合性及びＳＬＭの動作］
機能強化された「テーブルベース」の監視
この実施の形態内では、テーブルベースの監視手法は、時期の遅れた情報の欠点を低減するように変更される。これは、ＳＬＭ３０２が近時のクライアントタスクをディスパッチしたメディアサービスノードの短期記録をＳＬＭ３０２に保持させることによって行われる。ＳＬＭ３０２は、次に、それに応じて、どの資源が新たなジョブに利用可能であるかの自身の予測を調整する。たとえば、資源統計値が或るメディアサービスノードから最後に送信される前に、メディアサービスタスクがそのサービスノードに１分未満ディスパッチされた場合、そのノードの資源記録は、前にディスパッチされたそのメディアサービスジョブによって要求された資源予算よりも低くなる。
【００２７】
［共有サービスを有する複数のＳＬＭ］
メディアサービスノードのいくつかが、２つ以上のＳＬＭの権限下にある場合（すなわち、分散された１組のＳＬＭマシンの２つ以上が、そのサービスノードへのメディアサービス要求のリダイレクトを許可された場合）、ディスパッチが行われるとすぐに、各ＳＬＭは、ディスパッチされたジョブに関する情報も、そのメディアサービスノードにおけるＳＬＳデーモンへ伝えるべきである。そのようにして、ＳＬＳデーモンは、すべてのディスパッチの通知を他のＳＬＭプロセッサへ再送することができ、それによって、異なるＳＬＭからの交差するディスパッチによって、メディアサービスノードの計算資源又はネットワーク資源の定数以上の予約が取られる回数を最小にすることができる。
【００２８】
共有サービスを有するＳＬＭを１つ又は複数有することによって、これは、サービスノードが２つ又は３つ以上の異なる組織又はグループ内で動作できる局部的なセグメンテーション（regional segmentation）を可能にすることに留意されたい。したがって、サービス要求をそのサービスノードに割り当てる能力をＳＬＭに与えることが望ましい。これに加えて、このように、各ＳＬＭの権限からサービスノードを除去しないことにより、ＳＬＭの過負荷を回避することができる。複数のＳＬＭがサービスを共有することを可能にすることは、組織、グループ、又は企業内でサービスを結び付けることがサービスの共有に適している場合に現実的なものとなり得る。これに加えて、ＳＬＭ間でのサービスの共有は、ＳＬＭの１つが動作不能になった場合のフォールトトレランスを提供することができる。さらに、ＳＬＭ間でのサービスの共有は、ＳＬＭに負荷バランシングを提供することができる。
【００２９】
時期遅れの情報の欠点を低減するために、ＳＬＭ３０２は、自身が近時のタスクをディスパッチしたサービスノードの短期記録を保持できることに留意されたい。そういうことから、このタイプの「プッシュ」ベースの監視では、サービスノードは、一定の周期で起こり得る自身のデータをＳＬＭ３０２へプッシュしている。サービスノード（たとえば、２０２、２０４、及び２０６）によって送信されている統計値のそれぞれは、平均化を行うことによって、同様にその内部に一定の待ち時間を有する。そういうことから、何がＳＬＭ３０２で発生しても、ＳＬＭ３０２が何かをディスパッチする時、ＳＬＭ３０２は、前にジョブをディスパッチしたのはどの資源かという情報を有するディスパッチが取るか又は取るものと予想される、自身のサービスノードの実行テーブルを保持する。このようにして、ＳＬＭ３０２が自身の次のディスパッチを行う時、ＳＬＭ３０２は、サービスノードから得られた自身のテーブルの統計値を使用することができ、それらの統計値がどの程度古いものかを理解することができる。したがって、ＳＬＭ３０２は、それらの統計値が受信されてから行われたあらゆるディスパッチがそれらの統計値に全く反映されないことを知ることができる。ＳＬＭ３０２は、実際の利用可能な資源が各サービスノードにあると予想するための正しい近似を得るために或る時点で線形補間を行うことができることに留意されたい。
【００３０】
ＳＬＭ３０２は、この利用可能なテーブルを有し、当該テーブルは、所与のサービスノード（たとえば、２０２）からのその最新の更新を示す日時が付けられている。ＳＬＭ３０２が有する、そのサービスノードからの最新の統計値がたとえば１０分古いものであり、ＳＬＭ３０２が５分毎の更新を予想している場合、ＳＬＭ３０２は、そのサービスノードに関して何かが故障していると判断して結論付けることができる。その問題はいくつかのものである場合があり、たとえば、ネットワーク３００が障害を受けている場合もあるし、サービスノード２０２が障害を受けている場合もあるし、あるいはＳＬＳデーモンがそのサービスノード２０２において停止している場合もある。したがって、ノードがＳＬＭ３０２に報告することによって、この情報を提供することもできるし、あるいはＳＬＭ３０２が、サービスノードのすべてにおける自身のテーブルの一般的なラウンドロビンチェックを、オーバーヘッドの低いバックグラウンドプロセスとして行うこともできる。このようにして、ＳＬＭ３０２は、サービスノードの１つ又は複数に関連する場合がある問題に気付くことができる。問題が検出された場合、ＳＬＭ３０２は、そのサービスノードにおいて、ＳＬＳデーモンの再起動を試みることもできるし、ＳＬＭ３０２がノードと接触できない場合には、ＳＬＭ３０２は、オープンビュー（Open View）監視システムを用いて、その特定のノードに関する問題を示すフラグを立てることもできる。この機能を実行することによって、ＳＬＭ３０２は、動作不能のおそれがあるメディアサービスノードへのストリーミングセッションのディスパッチも割り当ても行わないことに留意されたい。
【００３１】
テストベッドの結果
サービスロケーション管理アーキテクチャの一実施の形態は、メディアサービスを移動ストリーミングメディア配信システムと統合するように設計された。移動ストリーミングメディア（ＭＳＭ（mobile streaming media））のテストベッドは、これらの能力を実証するように設計、開発、及び実施された。ＭＳＭのテストベッドは、複数の記憶コンテンツ／ライブコンテンツストリーミングサーバ及びストリーミングメディアクライアントから成る。ストリーミングエッジサーバ及び管理サーバは、共に、適合型ＭＳＭ−ＣＤＮを形成する。ストリーミングエッジサーバは、コンテンツの分配及びキャッシュ、ストリーミング、資源監視、資源管理、並びにシグナリングのサポートを提供する。これに加えて、ストリーミングエッジサーバは、ライブストリームの分割（又は、メディアストリーミングセッションのアプリケーションレイヤのマルチキャスト）や、ＭＰＥＧ−４ビデオストリームのリアルタイムのメディアトランスコード等のメディアサービス機能も実行する。
【００３２】
これらのストリーミングサーバ、クライアント、及びエッジサーバは、３ＧＰＰ標準規格に準拠することができ、したがって、セッション記述プロトコル（ＳＤＰ（Session Description Protocol））［４］、リアルタイムストリーミングプロトコル（ＲＴＳＰ（Real Time Streaming Protocol））［１３］、及びリアルタイムトランスポートプロトコル（ＲＴＰ（Realtime Transport Protocol））［１２］を使用することができ、ＭＰＥＧ−４［８］ビデオ標準規格及びオーディオ／モデムライザ（ＡＭＲ（Audio/Modem Riser））音響メディア標準規格をサポートすることができる。ストリーミングエッジサーバ及び管理サーバは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）［３］をシグナリング用に使用することができる。他の標準規格も本発明に従って利用できることに留意されたい。
【００３３】
サービスロケーションマネージャ（ＳＬＭ）３０２は、クライアントが要求したストリーミング／メディアサービスセッションを、ネットワーク及びシステムの資源使用量に基づいて「最良の利用可能な」ストリーミングエッジノードに割り当てる。ＳＬＭ３０２は、１組のストリーミングエッジノードにおける統計値を収集し、それらの統計値を解析して、最良の利用可能なエッジサービスノードを選択し、その選択したエッジノードをクライアント要求に応答して伝える。ＳＬＭ３０２は、ＳＯＡＰ／ＸＭＬシグナリングを使用して、エッジノードから資源使用量の統計値を収集し、選択したエッジノードを要求側クライアントに動的に伝える。
【００３４】
ＳＬＭ３０２の資源監視に対して提案した３つの手法のそれぞれは、ＭＳＭ−ＣＤＮのテストベッドで実施されてテストされた。ポーリングベースの監視は、場合により、完全なストリーミング障害という結果になった。これは、移動クライアントの応答タイムアウト期間があまりにも小さく設定され、その結果、クライアントが諦める前に、ＳＬＭ３０２がポーリング応答のすべてを収集し、それらを処理し、且つ、動的に生成されたＳＭＩＬ応答を提供するのに十分な時間を有しない場合に発生した。これらのあまりにも遅い応答は、通常、メディアサービスノードの１つ又は複数がネットワークから切り離された時に起こる。これらの場合、ＳＭＬ３０２は、そのサービスノードをクライアントの可能性のあるメディアサービスプラットフォームとして無視する前に、標準的なＳＯＡＰタイムアウト期間、待機していた。ポーリングベースの監視に関連した遅延も、ネットワークの拡大縮小を優雅にサポートしない。監視されるサービスノードの個数が増加するにつれて、ポーリングに関連した遅延は比例して増加する。
【００３５】
基本的なテーブルベースの監視は、このタイムアウトの障害モードを受けなかった。しかしながら、この監視は、多くの場合、準最適な負荷バランシングという結果になった。これは、クライアント要求が間断なく到来した時に発生した。たとえ、メディアサービスノードにおけるＳＬＳが、ＳＬＭ３０２のデータベースに含まれる空き状態資源情報を更新するように変更されても、新たなローカルメディアサービスタスクに遭遇するたびに、この準最適な負荷バランシングは依然として発生した。時に、この準最適なタスク割り当ては、新たにインスタンス化されたタスクに対する空き状態資源統計値の応答の待ち時間に起因するものであった。さらに多くの場合、準最適なタスク割り当ては、ＳＬＭ３０２が、（動的なＳＭＩＬファイルをクライアントへ送信することにより）メディアサービスタスクを特定のサービスノードにディスパッチした後であって、その以前のクライアントが、（ＲＴＳＰのＳＥＴＵＰ要求を送信することにより）選択されたサービスノードにそのメディアサービスタスクを実際に確立する前に到来する新たなクライアント要求に起因するものであった。
【００３６】
機能強化されたテーブルベースの監視は、ポーリングベースの監視で見られたタイムアウト障害、及び、基本的なテーブルベースの監視で見られた、インターリーブされた要求の誤りの双方を回避した。
【００３７】
メディアサービスのハンドオフの管理のためのＳＬＭ
図５Ａ及び図５Ｂは、本発明による一実施の形態を示している。具体的には、サービスロケーションマネージャ３０２は、或るメディアサービスノード（たとえば、図５Ａに示す２０２）から別個のメディアサービスノード（たとえば、図５Ｂに示す２０４）へメディアストリーミングセッション（二点鎖線の楕円５０６によって示す）を移動させるのに使用することができる。この移動は、ハンドオフと呼ぶことができる。たとえば、サービスノード２０２が、ストリーミングメディアセッションをハンドオフする必要があると判断した場合（又は、ネットワーク３００の他の或るコンポーネントがこれを判断した場合）、この情報はＳＬＭ３０２へ通信することができる。ＳＬＭ３０２は、次に、その特定のストリーミングセッションをどのサービスノードにハンドオフするかを算定するために、その時点で、サービスノードの負荷、ネットワーク３００の負荷等を計算することができる。このように、あらかじめ定義されたハンドオフノードを決定する必要はない。その代わり、ハンドオフノードは、ＳＬＭ３０２によって実行中に決定される。したがって、所望のサービスを実行できる最良のメディアサービスノードがＳＬＭ３０２によって選択される。次に、ハンドオフは、図６、図７、図８Ａ、及び図８Ｂで説明するものと同様の方法で行うことができる。ハンドオフを実行する方法は、最初のサービスノード（たとえば、２０２）によって実行されているサービスのタイプに特有のものとすることができることに留意されたい。
【００３８】
図６は、本発明の実施の形態を実施できる単一のコンテンツサーバ１０２を有するデータセッションハンドオフの例示のシステム６００のブロック図である。システム６００は、データセッションハンドオフに含めることができる例示のメディアサービスとして、トランスコードを含むことに留意されたい。システム６００は、任意のメディアサービスを含むことができ、トランスコードに限定されるものでないことが理解される。一実施の形態では、システム６００において、データ（たとえば、ビデオメディア）が、無線リンクを介して移動クライアント（たとえば、電子デバイス）へストリーミングされる。一実施の形態では、そのデータは、ストリーミング音響やストリーミングビデオ等、連続フローで構造化されて処理されるストリーミングデータである。ストリーミングデータは複数のデータパケット（たとえば、部分）を含み、各パケットはそのフローにおいて順序付けられている。
【００３９】
一実施の形態では、システム６００は、コンテンツサーバ１０２（たとえば、データ送信元）、トランスコーダデバイス６０２及び６０４、並びに電子デバイス１２０を備える。一実施の形態では、トランスコーダ６０２は、セル６０８に位置する電子デバイスへメディアストリームを供給するように動作することができ、トランスコーダ６０４は、セル６１０に位置する電子デバイスへメディアストリームを供給するように動作することができる。本実施の形態では、コンテンツサーバ１０２は、トランスコーダ６０２へ送信される高ビットレートで高解像度のビデオストリームを生成する。トランスコーダ６０２は、そのビデオストリームを、電子デバイス１２０へその後送信される低ビットレートで中解像度のビデオストリームにトランスコードする。
【００４０】
本アプリケーションにおいて、一実施の形態では、トランスコーダ６０２は第１のトランスコーダと呼ばれ、トランスコーダ６０４は第２のトランスコーダと呼ばれる。別の実施の形態では、トランスコーダ６０２は第２のトランスコーダと呼ばれ、トランスコーダ６０４は第１のトランスコーダと呼ばれる。簡潔にし、且つ、明瞭にするために、本明細書では、本発明の実施の形態をトランスコーダ６０２及びトランスコーダ６０４に関して説明する。
【００４１】
一実施の形態では、電子デバイス１２０は移動デバイスである。本実施の形態では、電子デバイス１２０は、無線接続上のデータを受信するように構成された任意のデバイスである。この任意のデバイスには、ラップトップコンピュータ、パームトップコンピュータシステム、携帯電話等が含まれるが、これらに限定されるものではない。
【００４２】
図７は、本発明の実施の形態を実施できるコンテンツ分配ネットワーク６１４を有するデータセッションハンドオフの例示のシステム７００のブロック図である。システム７００は、データセッションハンドオフに含めることができる例示のメディアサービスとして、トランスコードを含むことに留意されたい。システム７００は、任意のメディアサービスを含むことができ、トランスコードに限定されるものでないことが理解される。一実施の形態では、システム７００において、データ（たとえば、ビデオメディア）が、無線リンクを介して移動クライアント（たとえば、移動電子デバイス）へストリーミングされる。一実施の形態では、そのデータは、ストリーミング音響やストリーミングビデオ等、連続フローで構造化されて処理されるストリーミングデータである。
【００４３】
一実施の形態では、システム７００は、コンテンツ分配ネットワーク６１４（たとえば、データ送信元）、トランスコーダデバイス６０２及び６０４、並びに電子デバイス１２０を備える。一実施の形態では、トランスコーダ６０２は、セル６０８に位置する電子デバイスへメディアストリームを供給するように動作することができ、トランスコーダ６０４は、セル６１０に位置する電子デバイスへメディアストリームを供給するように動作することができる。コンテンツ分配ネットワーク６１４は、複数のエッジサーバ（たとえば、エッジサーバ６１６及び６１８）を備える。エッジサーバ６１６及び６１８は、それぞれが当該エッジサーバに地理的に非常に近い移動クライアントへメディアを供給するためのものとなるように地理的に分散され、ネットワークオーバーヘッドを軽減するようになっている。本実施の形態では、エッジサーバ６１６は、トランスコーダ６０２へ送信されるフルビットレートで高解像度のビデオストリームを生成する。トランスコーダ６０２は、そのビデオストリームを、電子デバイス１２０へその後送信される低ビットレートで中解像度のビデオストリームにトランスコードする。
【００４４】
一実施の形態では、電子デバイス１２０は移動デバイスである。本実施の形態では、電子デバイス１２０は、無線接続上のデータを受信するように構成された任意のデバイスである。この任意のデバイスには、ラップトップコンピュータ、パームトップコンピュータシステム、携帯電話等が含まれるが、これらに限定されるものではない。
【００４５】
図６及び図７を参照して、システム６００及びシステム７００は、共に、トランスコーダ６０２及び６０４を使用して、ビデオストリームを、ターゲットの電子デバイス（たとえば、電子デバイス１２０）の表示能力と一致した低ビットレートのストリームにトランスコードする。
【００４６】
一インプリメンテーションでは、コンテンツサーバ１０２又はエッジサーバ６１６は、フルビットレートのメディアストリームをトランスコーダ６０２へ送信し、トランスコーダ２６０２（６０２？）は、セル６０８に位置する電子デバイスへのメディアをトランスコードする。一実施の形態では、コンテンツサーバ１０２はエッジサーバであることが理解されるべきである。トランスコーダ６０２は、次に、メディアストリームを低ビットレートのストリームにトランスコードし、そのストリームを電子デバイス１２０へ送信する。電子デバイス１２０が別のセルに向けて移動しているという通知をトランスコーダ６０２が受信すると、トランスコーダ６０２は、その新たなセルに貢献する別のトランスコーダとのハンドオフオペレーションを開始する。このハンドオフプロセスは、図８Ａ及び図８Ｂのプロセス８００において、以下で非常に詳細に説明する。
【００４７】
一実施の形態では、ハンドオフは、サービスロケーションマネージャ３０２等の中央ノードの制御及び指示の下で達成される。別のエンティティ（たとえば、専用ハンドオフマネージャ）がこの機能を代わりに実行できることが理解される。一実施の形態では、サービスノード２０２は、メディアセッションを別のサービスノードへ転送するのに使用されるハンドオフ情報を指定する。このような一実施の形態では、ハンドオフ情報は、サービスロケーションマネージャ３０２へ転送される。サービスロケーションマネージャ３０２は、次に、メディアセッションハンドオフを受け取ることになるサービスノード（たとえば、サービスノード２０４）を選択することができ、ハンドオフ情報をそのサービスノードへ転送することができる。別の実施の形態では、サービスロケーションマネージャ３０２は、メディアセッションハンドオフを受け取ることになるサービスノードを特定することができ、そのサービスノードへハンドオフ情報を直接通信するようにサービスノード２０２に指示することができる。
【００４８】
図８Ａ及び図８Ｂは、本発明の一実施の形態によるデータセッションハンドオフのプロセス８００を示すフローチャートである。一実施の形態では、プロセス８００は、トランスコーダデバイス（たとえば、トランスコーダデバイス６０２又は６０４）において、メモリに記憶されてコントローラにより実行されるコンピュータ可読プログラム命令として実施される。図８Ａ及び図８Ｂには具体的なオペレーションが開示されているが、このようなオペレーションは例示である。すなわち、本発明は、他のさまざまなオペレーション、又は、図８Ａ及び図８Ｂに列挙したオペレーションの変形を実行することにも良く適している。
【００４９】
プロセス８００のオペレーション８０５では、移動デバイス（たとえば、図６の電子デバイス１２０）が、トランスコーダ（たとえば、図６のトランスコーダ６０２）と接触して、メディアファイル（たとえば、データ）を要求する。一実施の形態では、トランスコーダ６０２は、セル６０８内に位置する電子デバイスへメディアを供給するように動作することができる。一実施の形態では、移動デバイスは、最も近いトランスコーダと接触して、メディアファイルを要求する。一実施の形態では、移動デバイスは、メッセージを送信することによってトランスコーダと接触する。一実施の形態では、このメッセージは伝送制御プロトコル（ＴＣＰ）メッセージである。オペレーション８０５は、図６及び図７では、矢印６３０として図的に表されている。
【００５０】
オペレーション８１０では、トランスコーダ６０２が、データ送信元（たとえば、コンテンツサーバ１０２又はコンテンツ分配ネットワーク６１４）と接触して、メディアセッションをセットアップする。一実施の形態では、トランスコーダ６０２は、メッセージを送信することによってデータ送信元（たとえば、図６のコンテンツサーバ１０２又は図７のコンテンツ分配ネットワーク６１４）と接触する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８１０は、図６及び図７では、矢印６３２として図的に表されている。
【００５１】
オペレーション８１５では、データ送信元が、要求されたメディアをトランスコーダ６０２へストリーミングすることを開始する。一実施の形態では、要求されたメディアは、ユーザデータグラムプロトコル（ＵＤＰ）を使用して送信される。オペレーション８１５は、図６及び図７では、矢印６３４として図的に表されている。
【００５２】
オペレーション８２０では、トランスコーダ６０２が、ストリーミングメディアを電子デバイス１２０にダウントランスコードする。オペレーション８２０は、図６及び図７では、矢印６３６として図的に表されている。
【００５３】
オペレーション８２５では、電子デバイス１２０が新たな位置（たとえば、セル６１０）へ移動しているとの通知をトランスコーダ６０２が受ける。一実施の形態では、電子デバイス１２０は、新たな位置への移動をトランスコーダ６０２へ直接通信する。別の実施の形態では、その移動の通知は、電子デバイス１２０の非常に近くに位置して電子デバイス１２０の移動を監視するカメラによりトランスコーダ６０２へ通信される。別の実施の形態では、電子デバイス１２０が新たな位置へ移動することは、当該電子デバイス１２０の監視された振る舞いに基づいてコンピュータシステムにより予測される。別の実施の形態では、電子デバイス１２０が新たな位置へ移動することは、トランスコーダ６０２によって監視される電子デバイス１２０の内部に常駐した全地球測位システムに基づいて判断される。新たな位置への電子デバイス１２０の移動をどの方法によってもトランスコーダ６０２に気付かせることが可能であることが理解されるべきである。セル６０８からセル６１０への電子デバイス１２０の移動は、図６及び図７では、矢印６３６として図的に表されている。
【００５４】
オペレーション８３０では、トランスコーダ６０２が、セル６１０に非常に近いトランスコーダ（たとえば、トランスコーダ６０４）へハンドオフメッセージを送信し、電子デバイス１２０へメディアをストリーミングする準備をするようにトランスコーダ６０４に通知する。一実施の形態では、このハンドオフメッセージは、トランスコード情報（たとえば、電子デバイス１２０の表示サイズ及び帯域幅サイズ）並びにシーケンスヘッダ（たとえば、データストリームの現在のバイト位置）を含む。このシーケンスヘッダは、メディアストリームのどの部分が現在電子デバイス１２０へ送信されているかを示す。一実施の形態では、トランスコーダ６０２は、メッセージを送信することによってトランスコーダ６０４に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８３０は、図６及び図７では、矢印６３８として図的に表されている。
【００５５】
オペレーション８３５では、トランスコーダ６０４が、データ送信元と接触して、メディアセッションをセットアップする。一実施の形態では、このメディアセッションは、オペレーション８３０で受信されたシーケンスヘッダに基づいて要求される。シーケンスヘッダに示されたビット位置においてメディアセッションを開始することにより、電子デバイス１２０は、トランスコーダの切り換え中であってもシームレスなメディアセッションを受信する。一実施の形態では、トランスコーダ６０４は、メッセージを送信することによってデータ送信元に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８３５は、図６及び図７では、矢印６４０として図的に表されている。
【００５６】
オペレーション８４０では、データ送信元が、要求されたメディアをトランスコーダ６０４へストリーミングすることを開始する。一実施の形態では、上記で列挙したように、メディアセッションは、シーケンスヘッダに示されたビット位置を起点として、電子デバイス１２０にトランスコードされ、電子デバイス１２０にシームレスなメディアセッションを提供する。一実施の形態では、要求されたメディアは、ＵＤＰを使用して送信される。オペレーション８４０は、図６及び図７では、矢印６４２として図的に表されている。
【００５７】
オペレーション８４５では、トランスコーダ６０４が電子デバイス１２０と通信する準備ができていること、及び、トランスコーダ６０２が電子デバイス１２０との通信を遮断できることを、トランスコーダ６０４がトランスコーダ６０２に通知する。一実施の形態では、トランスコーダ６０４は、メッセージを送信することによってトランスコーダ６０２に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８４５は、図６及び図７では、矢印６４４として図的に表されている。
【００５８】
オペレーション８５０では、トランスコーダ６０４が、ストリーミングメディアを電子デバイス１２０にダウントランスコードする。上述したように、ストリーミングメディアは、オペレーション８３０で受信されたシーケンスヘッダに示された位置でトランスコードを開始して、シームレスな形式で電子デバイス１２０に提示される。オペレーション８５０は、図６及び図７では、矢印６４８として図的に表されている。
【００５９】
オペレーション８５５では、トランスコーダ６０２が、電子デバイス１２０へのメディアのトランスコードを停止する。
【００６０】
関連した作業
デガス（Degas）システムは、ユーザが定義したメディア処理を、プログラマブルメディアゲートウェイを使用して可能にするものである［９］。ディグレット（deglet）と呼ばれるプログラムを、宣言型プログラミングモデルを使用してゲートウェイにアップロードすることができる。デガスシステムは、メディアゲートウェイと相互作用するための特別なクライアントを含む。他方、本明細書で説明したＳＬＭシステムは、３ＧＰＰに準拠したクライアントには完全にトランスペアレントとすることができる。デガスシステムは、ネットワーク帯域幅の利用に関して最適にゲートウェイを配置しようと試み、必要に応じて、処理タスクを動的に移動させることができる。しかしながら、資源管理は実施されなかった。このシステムは、マルチメディアソフトウェアライブラリを使用して、メディアゲートウェイのコードを最適化する。
【００６１】
コンテンツサービスネットワーク（ＣＳＮ（content service network））が［７］で提案された。キーフレームの抽出を有するビデオセグメンテーションが、サンプルの基盤サービスとして使用された。本発明者等のアーキテクチャと同様に、ＣＳＮは、既存のＣＤＮを利用して、基盤サービスとして計算（たとえば、処理）を追加する。サービス分散／管理（ＳＤＭ（Service Distribution and Management））サーバが、ネットワークのサービス、並びに、サーバ負荷及びクライアントの人口統計の履歴に関する情報を保持するのに使用される。リダイレクトサーバが、処理要求をアプリケーションプロキシサーバへ送信するためにネットワークエッジに配置される。提案されたＣＳＮは、ＤＮＳリダイレクトを使用して、最も近いアプリケーションプロキシへ要求を送信する。本発明者等のアーキテクチャでは、この機能は、動的なＳＭＩＬの書き換えによってアプリケーションレベルで完全に実行される。これによって、ＤＮＳリダイレクト能力の必要性は基盤から取り除かれる。
【００６２】
ＣＳＮとＳＬＭ／ＭＳＡとの相違
＊ＣＳＮは、独立したオーバーレイ基盤を必要とし、サービス割り当てプロセス用に追加のＤＮＳリダイレクトを必要とする。ＳＬＭは、既存のコンテンツ配信構造に埋め込まれ、サービス要求の転送は、動的なＳＭＩＬの書き換えによってアプリケーションレベルで完全に実行される。
＊ＣＳＮは、加入モデル（subscription model）を使用し、エンドユーザ又はコンテンツプロバイダのいずれかが特定のサービスに加入する。ＳＬＭは、どのパーティからも加入を必要としない。
＊ＣＳＮでは、サービスセッションがサービスノードに一旦割り当てられると、そのノードは、ノードが障害を受けない限り、そのセッションを完了する。ＳＬＭは、サービスセッションの最中に異なるノードに動的に切り換わることができる。
＊ＣＳＮは、結果を供給できるようになる前にサービスが完了されていることを必要とするＯＰＥＳを使用する。ＳＬＭは、ストリーミングされるメディアサービスを可能にする。すなわち、メディアサービスの結果は、サービスセッションが進行中の時に並列に供給することができる。
＊ＣＳＮは、動的なサービス配置／セッション割り当てを有するサービス管理を実施する方法を開示しない。一方、これは、ＳＬＭに関しては本明細書で説明される。
＊ＣＳＮは、ＡＰ（別名、サービスノード）の「監視」がどのように行われるかを示さず、そういうことから、監視がスケーラブルであるのかどうかも、監視がノードの障害を自動的に検出するのかどうかも示されない。ＳＬＭは、本明細書で説明するようなプッシュベース又はプルベースの監視を利用することができる。
＊受信された監視統計値（それらの統計値がどのように受信されようとも）は、ＳＬＭにより近時のディスパッチを反映するように変更される。ＣＳＮはこれを教示していない。
【００６３】
要約すれば、移動デバイスは、あちらこちらに移動し、バックグラウンドタスクの開始及び停止を行い、自身のプロセッサパラメータ及びディスプレイパラメータを、さまざまな電力管理ストラテジーを考慮に入れるように調整することから、これらのメディアサービスは、移動デバイスによって提示される、高速に拡大し、且つ、非常に動的な、ディスプレイ、プロセッサ、及び帯域幅の１組の制限をサポートするのに望ましい。概説したＳＬＭソリューションは、ＣＰＵに集中したメディア処理タスクの負荷をネットワークの複数のサービスノードにわたってバランスさせる問題に有効に対処することができる。クライアントが既知のポータルサイトにアクセスする時、サービスロケーションマネージャ３０２は、要求を、最小負荷のサービスノードに動的にルーティングする。さらに、トランスコードされたストリームは、３ＧＰＰに準拠したクライアントにトランスペアレントな方法で、ネットワークの適切なサービスノードから提供される。
【００６４】
このアーキテクチャは、［６、１１］で概説されているように、移動クライアントのメディアサービスセッションのアプリケーションレベルのハンドオフをトリガするように拡張することができる。ＳＬＭアーキテクチャは、新たなクライアントの位置の近くにあるメディアサービスノードを判断するのによく適している。セッション中のハンドオフを実行する能力によって、前述したものよりもはるかにきめの細かな粒度の負荷バランシングが可能になる。
【００６５】
［コンポーネント化されたネットワークベースのメディアサービスの例示のアーキテクチャ］
本発明の一実施の形態によるメディアサービスアーキテクチャ（ＭＳＡ（Media Service Architecture））は、ストリーミング音響及びストリーミングビデオがネットワークを通ってフローする際に、当該ストリーミング音響及びストリーミングビデオに対して動作するサービスの要求、構成、及び実行を行うための柔軟で一般的なアーキテクチャを提供することができる。ＭＳＡは、要求されたメディアサービスをモジュール形式の処理コンポーネントに分解する。これらのモジュール形式の処理コンポーネントは、ネットワーク全体にわたってサーバに分散させることができ、且つ、（たとえば、標準的なストリーミングプロトコルを介して）相互通信することができるものである。標準的なプロトコルを使用することによって、ＭＳＡとメディアコンテンツ配信ネットワークとの間のシームレスな相互運用性も与えられる。ＭＳＡは、利用可能な計算資源及びネットワーク資源を効率的に使用する方法で、ネットワーク接続されたサーバの監視、及び、ネットワーク接続されたサーバへのサービスコンポーネントの割り当てを行うことによって、メディアサービスを管理する。サービスのコンポーネント化及びネットワーク配信によって、新たなサービス及び改良されたサービスの高速な開発が可能になり、幅広いサービス可用性及びデバイス互換性が増進される一方、エンドユーザに対するシステムメンテナンスの負担が大幅に削減されることに留意されたい。
【００６６】
一実施の形態内では、ＭＳＡは、複雑なメディアサービスを、柔軟に構成されたネットワークベースのパーツに分解することによって、コンポーネント化されたウェブベースのサービスをストリーミングリッチメディアの領域に拡張する。この手法によって、新しい強力なアプリケーションの高速な開発及び簡単なメンテナンスが可能になり、多数のユーザへのスケーラビリティが増進される。このすべてが、メディアサービスクライアントの立場からの使いやすさを犠牲にすることなく達成される。
【００６７】
ネットワークベースのメディアサービス
スタンドアロンシステムで音響、ビデオ、及び他のメディアに対して実行される多くのタイプの解析を、ネットワーク接続処理アーキテクチャに統合することができる。たとえば、発話認識、顔検出及び顔認識、並びに音響雑音除去は、ローカルなデスクトップを離れて、利用可能な帯域幅及び処理能力を有するネットワーク接続されたサーバマシンへ簡単に移動させることができる。これに加えて、ＭＳＡは、実用的で新しい利用可能な高い価値のサービスを作り出す。このサービスには以下のものが含まれる。
【００６８】
ビデオ合成：複数の送信元からのコンテンツを有する単一のビデオストリームを生成するためのマスクに従って、２つ又は３つ以上のビデオストリームを画像ごとにブレンドすることができる。多くのアプリケーションの中には、「ピクチャインピクチャ」特殊効果及び「ブルースクリーニング」特殊効果がある。ビデオトランスコードは、入力ストリームの一致しないフォーマット、解像度、及びフレームレートを打開するのに望ましい場合がある。
【００６９】
会議の要約及び転写（transcription）：カメラ及びマイクが会議に存在する場合、入力する音響ストリーム及びビデオストリームをネットワークで収集でき、ビデオ及び音響のセグメンテーション並びに音声及び顔の認識を用いて処理して、インデックスされた会議記録を生成することができる。これに加えて、自動発話認識（ＡＳＲ）、キーワードスポッティング、及び文書要旨抽出（document gisting）を使用して、インデックスされ、注釈を付けられ、且つ、部分的に転写された、会議記録を生成することができる。これらのタイプの記録は、後に会議コンテンツを素早く思い起こすのに使用することができる。
【００７０】
マルチ音源音響強化：いくつかのマイク使用可能携帯情報端末（ＰＤＡ）又は他の電子記録デバイスを用いた会議等において、複数の音響ストリームが、単一の部屋で異なるマイクから取り込まれている時、ブラインド音源分離をこの特別なマイク配列に適用して、異なる参加者からの発話を分離して雑音除去することができる。
【００７１】
動的なビュー選択：ウェブキャストされるライブ遠隔会議講演の用途では、多くの場合、十分なカバレッジを得るために複数のカメラが望ましい。最良のカメラビューは、通常、そのイベント中に何度も変わる。イベントからのビデオストリーム及び音響ストリームの解析をネットワークベースのサービスが使用して、最良のビデオフィードを自動的に選択することができる。
【００７２】
これらのタイプのメディア解析は、今日、ローカルなデスクトップ処理を通じて利用可能である。しかしながら、ネットワーク内でメディアストリームに対して動作する、コンポーネント化されたサービスは、従来のデスクトップモデルを上回る多くの利点を提供する。この利点には以下のものが含まれる。
【００７３】
アプリケーション提供の改善：開発者は、ＭＳＡを単に更新するだけで、改良されたサービスを素早く分配することができる。新たなサービスは、コンポーネントの混合及び整合を行うことによって素早く作成される。単にユーザがアプリケーションをインストールすることができる自身のマシンにアクセスできる時だけでなく、ユーザがネットワークに到達できる時はいつでも、アプリケーションが利用可能である。
【００７４】
システム管理運営の削減：処理はネットワークで実行されるので、エンドユーザは、自身のマシンに対する継続的なインストール及び更新の面倒について気にする必要がない。
【００７５】
マルチストリーム処理の円滑化：会議要約等の多くのメディアベースのアプリケーションは、結合処理のために収集される複数のストリームを含む。これらのストリームが、同じマシンから発生したものでない場合、通例、ネットワーク内でそれらのストリームを処理した方がはるかに効率的である。
【００７６】
計算環境の制御：個々のユーザのマシンは、それらマシンの計算能力、メモリ容量、及びオペレーティングシステムの点で広く変化する場合があるが、ＭＳＡマシンは、狭い範囲の規格値に標準化することができる。サービスコンポーネントは、これらの規格値について開発及び最適化することができ、より信頼性のある全体的なアプリケーション性能がもたらされる。
【００７７】
結果の効率的な共有：会議要約の状況等の多くの状況では、複数のユーザが望む処理されたメディア及び解析結果は、ほとんど同じであるか、又は、同一である。ネットワーク内処理は、各ユーザのマシン上でこの処理を複製するのではなく、重複計算を１回実行し、次いで、それらの結果を各ユーザに分配することができる。簡単に言えば、ネットワークベースのメディア処理サービスは、メンテナンスの削減及び信頼性の問題について、現在のローカルなメディア中心のアプリケーションよりもはるかに大きな柔軟性及び機能性の可能性をユーザに提供する。
【００７８】
［メディアサービスアーキテクチャ（ＭＳＡ）］
ＭＳＡの実施の形態について、メディア配信アーキテクチャと統合すること、及び、非常に柔軟な方法でメディアサービスを可能にすることに焦点を当てる。ＭＳＡのいくつかの特徴は、以下のものを含むことができる。
相互運用性：オープンインターフェース及びオープン標準規格を使用したコンポーネント間のシームレスなストリーミングの相互接続、
モジュール性：ネットワーク内で動的なメディアサービスの構築を可能にするモジュール形式のサービスコンポーネント、並びに
管理可能性：スケーラブルな方法での計算資源及び記憶資源へのメディアサービスの効率的な割り当て。
アーキテクチャがこれらの特徴のそれぞれを提供できる手段を以下に説明する。
【００７９】
ストリーミングの相互運用性のためのシームレスな相互接続
ＭＳＡ内、並びに、ＭＳＡの要素間及びメディアコンテンツ配信ネットワーク（ＣＤＮ）のコンポーネント間におけるメディアストリームのマシン間のすべてのトランスポートは、「Ｅａｒ」と呼ぶことができる均一な入力モジュール及び出力モジュールを介して行うことができる。一実施の形態内では、Ｅａｒは、標準規格ベースのメディアストリーミングプロトコルに依拠し、それによって、ＭＳＡとＣＤＮ及び他のストリーミングメディアアプリケーションとの統合を容易にする。入力Ｅａｒ及び出力Ｅａｒは、共に、マルチメディアを記述するためのＳＤＰプロトコル、セッション管理及びメディア再生制御のためのリアルタイムストリーミングプロトコル（ＲＴＳＰ）、並びに、リアルタイムの制約の下でのデータのトランスポートのためのリアルタイムプロトコル／リアルタイム制御プロトコル（ＲＴＰ／ＲＴＣＰ）を介して、他のネットワーク接続されたマシンと通信することができる。ただし、プロトコルはこれらのものに限定されるものではない。所与のＥａｒは、単一のメディアストリームのフローの一方の端部（送信又は受信）を管理することができるが、同じ同期したストリーミングセッションに複数のＥａｒをリンクすることができる。
【００８０】
また、ネットワーク送信に多く使用される圧縮フォーマットと、メディア処理及び解析技法によって多く要求される非圧縮フォーマットとの間で、このアーキテクチャを通ってフローするマルチメディアを相互変換できるように、Ｅａｒは、データの圧縮機能及び伸張機能も提供することができる。入力Ｅａｒは、入力するメディアストリームのフォーマットを自動的に検出でき、適切な伸張モジュールを募集して、そのデータをメディア解析に適切な形式に変換することができる。出力Ｅａｒは、生のデータストリームを、ネットワークトランスポートに適した圧縮フォーマットに変換することができる。サポートされた標準圧縮方式には、動画エキスパートグループ（ＭＰＥＧ）であるＭＰＥＧ−１、ＭＰＥＧ−２、及びＭＰＥＧ−４のビデオ、並びに、オーディオ／モデムライザ（ＡＭＲ）及びＷＡＶの音響が含まれ得るが、これらに限定されるものではない。適切な圧縮モジュール及び伸張モジュールを登録することによって新たなフォーマットを追加できることに留意されたい。
【００８１】
最後に、メディア処理技法は、ストリーミングメディアと同じレートで動作できない場合があるので、Ｅａｒは、データバッファリング方法及びフロー制御方法を実施して、データレートの不一致を取り除くことができる。循環バッファリングによって、高価なデータコピーが最小にされ、マルチスレッド化によって、ネットワーク、アプリケーション、並びに伸張ルーチン及び圧縮ルーチンからのデータ要求に効率的にサービスが提供される。バッファオーバーフローは、フレームを廃棄するための選択可能なポリシーによってハンドリングすることができる。
【００８２】
柔軟なモジュール形式のサービス分解
ＭＳＡサービスは、サービスポータルと接触することによって、簡単な高レベルメディアサービス要求から開始することができる。これらの要求は、ユーザデバイスがインターネット等のネットワークを介して直接行うこともできるし、ローカル又はＭＳＡ内のいずれかでユーザデバイスによって実行されるアプリケーションが生成することもできる。各要求は、送信元及び宛先のユニフォームリソースロケータ（ＵＲＬ）等のあらゆるサービスパラメータと共に、「ビデオ合成」等のサービス名を含むことができる。
【００８３】
これらの簡単なメディアサービス要求は、要求側クライアントからのほとんどのメディアサービスの複雑さを隠蔽する。たとえば、会議要約は、発話認識、顔検出、ビデオ動き解析、及び音声識別を使用することができ、次に、これらのコンポーネント技法のそれぞれは、いくつかのサブコンポーネントに分割することができる。他方、所与の処理技法は、多くの異なるサービスにおける有用なコンポーネントとすることができる。これらの理由から、メディア処理技法を、柔軟で動的に組み合わせられる、モジュール形式の再利用可能なコンポーネントにカプセル化することが望ましい。
【００８４】
したがって、各メディアサービスは、データストリームを通じて通信する独立した「コンポーネント」のグラフとして構造化される。各コンポーネントは、互いにしっかりと動作する１つ又は複数の「サブコンポーネント」処理技法をカプセル化することができる。１つのメディアサービスのコンポーネントは、単一のマシンに動的に配置することもできるし、ネットワークにわたって動的に分散することもできる。コンポーネントは、適切にカプセル化されるので、各コンポーネントは、この分散を気にすることなく動作することができる。
【００８５】
図１０は、ＭＳＡが本発明の一実施の形態に従ってサービスを分解して分散させる例示のオペレーションを示すブロック図である。サービスポータル１００６は、ユーザデバイス１００２によって発行されたメディアサービス要求１００４を受信した後、その要求の遂行を管理するためのサービスビルダ１００８を起動して実行する。指名された各メディアサービスを異なるサービスビルダ（たとえば、１００８）に関連付けることができ、各サービスビルダは、そのサービスを実施するコンポーネント（たとえば、１００１）の抽象グラフの構造を知っていることに留意されたい。このグラフの各コンポーネントについて、サービスビルダ１００８は、コンポーネント配置要求１０１０を「サービスロケーションマネージャ」（ＳＬＭ）１０１２へ送信して、本明細書で説明したように、１つ又は複数のコンポーネントを実行するための、ネットワーク接続されたサービス提供可能マシン（たとえば、１０２２、１０２４、又は１０２６）を決定する。ＳＬＭ１０１２は、コンポーネント配置決定１０１４をサービスビルダ１００８へ返信する。このコンポーネント配置決定１０１４は、各コンポーネントの各入力ストリーム及び各出力ストリームの具体的なＵＲＬ（ポート番号を有する）を含むことができる。サービスビルダ１００８は、選択されたサービス提供可能マシン（たとえば、１０２２）によるこれらの決定をグループ化し、次いで、選択された各マシンへ１つの構築要求１０１６をネットワーク（たとえば、インターネット１０２８）を介して送信する。この構築要求１０１６は、所望のコンポーネント１２０並びにそれらコンポーネントの入力ＵＲＬ及び出力ＵＲＬを列記している。
【００８６】
［ローカルビルダ］
「ローカルビルダ」（たとえば、１０１８）は、各ＭＳＡマシン（たとえば、１０２２、１０２４、及び１０２６）で実行され、構築要求１０１６にサービスを提供する。所与の要求１０１６について、ローカルビルダ１０１８は、指名されたコンポーネントのそれぞれを作成することができ、入力ＵＲＬ及び出力ＵＲＬを使用して、Ｅａｒ１０３０及び１０３２をインスタンス化し、これらのコンポーネント及び他のマシンのコンポーネント（たとえば、１０２２及び１０２６）の間でデータを送受信する。このようにして、ローカルビルダ１０１８は、サービスコンポーネントを結び付ける。また、ローカルビルダ１０１８は、２つ以上のコンポーネントによって行われる同一のサブコンポーネントの処理を取り除くことによって、単一のマシン（たとえば、１０２４）で実行される、相互通信するコンポーネントの各集合の最適化も試みる。このような重複は、時に、サービスが合理的なサイズの再利用可能なコンポーネントに分割された場合に起こる。サービスのモジュール性のこのコストは、このように、ローカルビルダの最適化によって軽減される。ローカルビルダは、冗長なサブコンポーネントの処理を取り除いた後、サービス処理を遂行するために、１つにまとめられたコンポーネントの入力ストリーム及び出力ストリームを必要に応じてリダイレクトする。
【００８７】
図１０内において、すべての構築要求１０１６が遂行された後、サービスを実行する準備ができる。データの宛先に最も近い、サービスグラフにおけるコンポーネントが、ＲＴＳＰのＰＬＡＹコマンドを介してメディアを要求し、それによって、接続されたコンポーネントのグラフ全体を通じてデータをプルする。ただし、コマンドは、ＲＴＳＰのＰＬＡＹコマンドに限定されるものではない。したがって、所望のメディアは、１つ又は複数の送信元（たとえば、コンテンツサーバ１０３３並びにライブカメラ１０３５及び１０３７）からフローし、選択されたサービスコンポーネントは、そのストリーミングメディアに対して動作し、最終的には、処理されたメディアを宛先（たとえば、出力ディスプレイ１００３）へ配信する。矢印１０３２と同様に見える、図１０内の矢印は、ストリーミングメディア／データを表していることに留意されたい。
【００８８】
動的なサービスロケーション管理−コンポーネント（複数可）配置
ＭＳＡネットワークの多くの個々のマシンは、メディアサービスについて基礎を成す処理を実行することができる。したがって、各メディアサービス要求（たとえば、１００４）について、要求を最も良く遂行するためにＭＳＡ資源をどのように割り当てるかについての決定を行うことができる。ネットワークの負荷を過度に増加させることを回避するために、これらの決定は、さまざまなサービス提供可能マシン（たとえば、１０２２、１０２４、及び／又は１０２６）の、メディアストリームの送信元と宛先との間の良好なパスに対する（ネットワーク）近接性に部分的に基づくことができる。また、サービスの遅延を最小にし、且つ、サービスの品質を最高にするために、これらの決定は、各ＭＳＡメディアプロセッサが保持する現在の処理負荷を考慮することもできる。最後に、サービスのいくつかのコンポーネントがサブコンポーネントの処理を共有する場合、それらのコンポーネントを同じサービス提供可能マシン（たとえば、１０２２、１０２４、又は１０２６）上にグループ化することが好ましい場合がある。
【００８９】
これらの決定を知的に行う一方法は、［１７］で説明されるような「サービスロケーション管理」を利用することである。ＭＳＡは、サービスロケーションマネージャ（ＳＬＭ）、たとえば１０１２を含む。このＳＬＭは、サービスを含む個々のコンポーネントを配置する場所を判断するものである。所与のメディアサービス要求（たとえば、１００４）について、ＳＬＭ（たとえば、１０１２）は、後述する複数の因子を考慮して、関連したサービスビルダ（たとえば、１００８）により定義された順序で、一時に１つずつサービスのコンポーネントを配置する。コンポーネントの配置決定は、代替的に、すべての因子及びすべてのコンポーネントにわたる同時最適化を通じて同時に行うこともできる。ただし、これは、適度に高度なサービスについても、複雑で多くの時間を要する手続きとなる可能性がある。また、異なるコンポーネントの配置決定は、代替的に、完全に独立して行うこともできる。ただし、これは、データパスが非効率的になり、サブコンポーネントの処理が重複する可能性がある。ＳＬＭ（たとえば、１０１２）は、そのようにしないで、近時のコンポーネント配置決定のテーブルを保持することもでき、新たな各決定の基礎を部分的にこの履歴に置くこともできる。
【００９０】
たとえば、サービスの抽象グラフにおいて互いに結び付けられたコンポーネントを、同じサービス提供可能マシン（たとえば、１０２２）、又は、高帯域幅及び／若しくは少ない待ち時間の相互接続を有するマシンに優先的に配置できるように、各コンポーネント配置決定を、同じサービス要求の他のコンポーネントについての前の決定に部分的に基づくものとすることができる。コンポーネントのグラフ全体にわたる同時配置最適化（joint placement optimization）は、おそらく高価なプロセスとなり、完全に独立した配置決定は、データパスがあまりにも複雑になるおそれがあり、重複した計算を取り除くことができないおそれがあるが、このようなコンポーネント配置決定の基礎を前の決定履歴に置くことは、コンポーネントのグラフ全体にわたる同時配置最適化と、完全に独立した配置決定との間の折衷案である。したがって、ＳＬＭ（たとえば、１０１２）は、前の配置決定に基づいて配置を最適化することは可能であるが、コンポーネントの全グラフにわたって割り当てを最適化するように試みることはできない。代替的に、ＳＬＭ（たとえば、１０１２）は、前の配置決定に基づいて配置を最適化することが可能であり、且つ、コンポーネントの全グラフにわたって割り当てを最適化するように試みることができることにも留意されたい。
【００９１】
図１１は、本実施の形態の一実施の形態によるサービスロケーション管理方法論のブロック図である。サービスビルダ１００８によってＳＬＭ１０１２へ送信された各コンポーネント配置要求１０１０について、ＳＬＭ１０１２は、まず、ネットワークの区域及び前のコンポーネント配置決定に基づいて、可能性のあるホストマシン（たとえば、１０２２、１０２４、及び／又は１０２６）のプールを選択することができる。そのネットワークの区域にアクセスするために、ＳＬＭ１０１２は、サーバマシン（たとえば、１０２２、１０２４、及び１０２６）間のネットワーク「距離」のテーブル１１０２を調べて、どのマシンがサービスデータの送信元及び宛先、又は、それらの間のパス（複数可）に近いかを判断することができる。テーブルの距離は、測定されたネットワーク遅延及び帯域幅によって求めることができることに留意されたい。ＳＬＭ１０１２は、そのサービスの他のコンポーネントが前に配置されたことがあるマシンを、現在のコンポーネントの配置についてより優先させることができ、特に、前に配置されたそれらのコンポーネントが、現在のコンポーネントに直接結び付けられることになるか、又は、現在のコンポーネントとサブコンポーネントの処理を共有する可能性があることを示されている場合には、優先させることができる。この情報のすべては、可能性のある各ホスト（たとえば、１０２２、１０２４、又は１０２６）の「マシン配置コスト」の計算に組み合わせることができる。
【００９２】
また、ＳＬＭ１０１２は、前のコンポーネント配置決定を見直して、同時コンポーネント配置を通じて可能性のある計算節減を見つけることもできる。一実施の形態内では、各タイプのコンポーネントは、自身が含む指名された「サブコンポーネント」技法のリストに関連付けられている。たとえば、「発話認識」コンポーネントは、（音響）ケプストラム特徴量（cepstral feature）を計算することができ、ＨＭＭを使用して、それらの特徴量を解析することができる。前に配置されたコンポーネント内に同じケプストラムサブコンポーネント（cepstral sub-component）を有するマシンがある場合、そのマシンを現在の決定プロセスで優先させることができる。この情報は、ネットワークの区域評価と組み合わせて、「マシン配置コスト」１１０６を生成することができ、最小コストを有するマシンは、現在のコンポーネントについて可能性のあるホストマシンのプールを形成する。これらのコストは、次に、各マシンにおける資源可用性に従って調整することができる。
【００９３】
図１１内において、コンポーネントの必要とする計算資源及びメモリ資源は、メディアの解像度やフレームレート等のサービスパラメータを、そのタイプのコンポーネントに関連付けられた資源要件ルーチン１１０８に供給することによって、ＳＬＭ１０１２により判断される。可能性のあるホストにおける資源可用性は、それらのマシン（１０２２、１０２４及び１０２６）に常駐するローカル資源マネージャ（ＬＲＭ（Local Resource Manager））（たとえば、１１１０、１１１２、及び１１１４）に資源照会１１１６を送信することによるＬＲＭの診断を通じて、ＳＬＭ１０１２が判断することができる。各ＬＲＭ（たとえば、１１１０、１１１２、又は１１１４）は、自身のオペレーティングシステムに直接問い合わせることによってそのマシンの状態を監視できることに留意されたい。また、ＬＲＭは、サービスロケーションスーパーバイザ（ＳＬＳ）と呼ぶこともできることにも留意されたい。また、マシンのローカルビルダ（たとえば、１０１８）からの、保留中で且つ近時に遂行された要求は、現在のプロセッサの負荷統計値にまだ反映されていない場合があるので、ＬＲＭは、これらの要求を追跡（図示せず）することもできる。各ＬＲＭ（たとえば、１１１０、１１１２、又は１１１４）は、次に、コンポーネントがそこに配置された場合に、当該コンポーネントによる使用に予約されたネットワークポート番号と共に、マシン資源ステータスをＳＬＭ１０１２へ返信することができる。ＳＬＭ１０１２は、マシンの資源可用性に反比例して、すべてのマシン配置コスト１１０６をインクリメントすることができる。したがって、ＳＬＭ１０１２は、可能性のある各ホスト（たとえば、１０２２、１０２４、又は１０２６）の最終的なマシン配置コスト１１０６を計算することができる。
【００９４】
最小マシン配置コストを有するマシンは、コンポーネントホストとして選択することができる。このホストを指定し、且つ、コンポーネントの入力ＵＲＬ及び出力ＵＲＬ並びに予約ポートを含むコンポーネント配置決定１０１４を、ＳＬＭ１０１２がサービスビルダ１００８へ返信することができる。また、ＳＬＭ１０１２の近時の配置決定１１０４のテーブルを更新して、この情報を反映させることもできる。
【００９５】
図１０及び図１１内において、ＳＬＭ１０１２は、サービス提供可能マシンの負荷、ネットワーク負荷及び／又は帯域幅、クライアントの位置、既存のメディア／データサービスストリーミングセッション、クライアント要求の集約等に基づいてコンポーネントを配置する場所を決定することができる。このように、ＳＬＭ１０１２は、複数のメディア／データサービスストリーミングセッションを管理することができる。
【００９６】
例示のサービスのインプリメンテーション
さまざまなサービスを構築できるコンポーネントと共にＭＳＡのプロトタイプが実施されていることに留意されたい。ＭＳＡの実施の形態のオペレーション及び利点をより良く示すために、ビデオメディアに対して動作する以下の３つのコンポーネントによりサポートされたサービスについて説明する。
サイズ変更：ビデオの幅及び／又は高さを変更する；たとえば、高解像度ビデオは、より良好な送信及びＰＤＡでの表示のためにダウンサンプリングすることができる。
背景除去：シーンにおいて、人々等の動的な又は「興味のある」オブジェクトを抽出する一方、壁や家具等、シーンの他の変化しない光景を抑制する。背景除去コンポーネントの一実施の形態は、［１８］の技法に基づくものとすることができる。この技法は、シーンの背景を一定の色（白等）に取り替えるように試みる一方、前景を変更せずそのままにする。
合成：ローカルテレビ（ＴＶ）の天気予報によって使用される「ブルースクリーニング」技法のように、マスクを使用して、ビデオストリームのピクセルを、別の画像又はビデオストリームからのピクセルと取り替える。合成コンポーネントは、特別な色（白等）を有するビデオストリームのピクセルを、別の画像又はストリームからのピクセルと取り替えることができる一方、前景を変更せずそのままにする。
【００９７】
これらの３つのコンポーネントから複数の有用なサービスを構築することができる。
【００９８】
ＰＤＡや移動電話等の移動クライアントに適した低解像度にビデオをトランスコードすることは、現代のＣＤＮ設計［１９、２０］にとって望ましく、サイズ変更コンポーネントを介して達成することができる。
【００９９】
長期間にわたってシーンの外観の明示的なモデル化を行うことにより、背景除去コンポーネントは、そのシーンの興味のあるオブジェクトをより多くのビットを使用して符号化できるように、それらオブジェクトをセグメントにすることができる。静止カメラの場合、背景は、ビデオの開始時近くに１度送信し、背景が大きく変化するたび再び送信する必要があるだけである。これは、標準的な圧縮を上回るかなりの利得を達成することができる。標準的な圧縮は、背景が、移動する前景のオブジェクトによって現れるたびに、背景を「新しい」ものとして再送することになる。したがって、この背景除去コンポーネントをオプションとしてサイズ変更と併せて使用することにより、ユーザによって要求される極めて低い目標レベルにビットレートを低減することができる。
【０１００】
ここでの説明は、上記コンポーネントの３つすべてを使用する「移動プライベートビデオ電話」（ＭＰＶＰ（Mobile Private Video Phone））サービスに焦点を当てる。このＭＰＶＰによって、ビデオ遠隔会議の参加者は、合成を使用して自身の背景を自身が選んだ画像又はビデオと取り替えることにより、他の参加者に自身の環境の詳細を見えないようにすることが可能になることに留意されたい。たとえば、ビーチから電話をかけている人は、自身のオフィスの背景画像を使用することを好む場合がある。ユーザが移動デバイスにおいてビデオを受信する場合、ビットレート削減のために、（サイズ変更を介した）ダウンサンプリングも使用することができる。
【０１０１】
ＭＰＶＰサービスは、インターネットプロトコル（ＩＰ）電話通信アプリケーション内で開始することができる。このＩＰ電話通信アプリケーションは、遠隔の参加者に対して音響チャネルをすでに開いており、現在、ビデオの追加を望んでいる。このアプリケーションは、「ＭＰＶＰ」サービスの要求を、宛先ＩＰアドレスや所望のビデオ解像度等のパラメータと共に、ＭＳＡサービスポータル（たとえば、１００６）へ送信することができる。このポータル１００６は、次に、ＭＰＶＰサービスビルダ（たとえば、１００８）を開始することができる。このＭＰＶＰサービスビルダは、図１２ａに示す抽象グラフ等のサービスの抽象グラフを知っている。図１２ａは、本発明の実施の形態によるサービスのコンポーネントの例示の抽象グラフ１２００であることに留意されたい。具体的には、抽象グラフ１２００は、最終的にビデオをビデオの宛先１２１０へ配信する前に、ビデオ送信元１２０２からのビデオがサイズ変更コンポーネント１２０４へ送信され、サイズ変更コンポーネント１２０４が自身の出力を背景除去１２０６へ送信し、次に、背景除去１２０６が合成１２０８にフィードされることから成る。
【０１０２】
サービスビルダ（たとえば、１００８）は、３つのコンポーネントが抽象グラフ１２００に現れる順序で、それら３つのコンポーネントのそれぞれについてのコンポーネント配置要求（たとえば、１０１０）をＳＬＭ（たとえば、１０１２）へ送信することができる。例示として、図１０及び図１１のＳＬＭ１０１２がコンポーネントを配置できるサービス提供可能マシン１０２２、１０２４、及び１０２６をネットワーク１２１２が含むということが、図１２ｂ〜図１２ｄに与えられている。また、ＳＬＭ１０１２は、コンポーネントの２つ又は３つ以上が同じマシン（たとえば、１０２６）に配置される場合に、どれだけの量の計算を削減できるかも知ることができる。ＳＬＭ１０１２は、コンポーネントをどのように分散するかについての決定に達するために、可能性のある計算節減、各マシンの現在の計算負荷レベル、各コンポーネントの処理要件、並びにネットワークトポロジー及びネットワーク負荷レベルを考慮することができる。ネットワーク１２１２におけるコンポーネントの３つの例示の分散が、図１２ｂ〜図１２ｄに示されている。
【０１０３】
図１２ｂ〜図１２ｄ内において、サーバ１０２２、１０２４、及び１０２６は、ビデオの送信元１２１４及び宛先１２１６と共に、それらの相対的なネットワーク距離を反映するように配置されている。画像は、各リンク上をフローするビデオ（処理されることがある）を表していることに留意されたい。処理コンポーネントを有しないマシンはメディアを単に転送するだけである。
【０１０４】
図１２ｂの第１の分散は、その長いデータパスがサービスの待ち時間を大きくすることになることから、本発明者等のＳＬＭには好まれない。このような分散は、ネットワークトポロジー及び配置履歴を考慮しないランダム選択等のより単純な配置技法によって選択される場合がある。具体的には、最終的にビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサービス提供可能マシン１０２６へ送信し、サービス提供可能マシン１０２６は自身の出力をサイズ変更１２０４及び背景除去１２０６用のサービス提供可能マシン１０２２へ送信し、次に、サービス提供可能マシン１０２２は合成１２０８用のサービス提供可能マシン１０２４にフィードされる。
【０１０５】
図１２ｃの第２の構成は、すべてのコンポーネント１２０４〜１２０８をサービス提供可能マシン１０２６に配置する。具体的には、最終的にビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサービス提供可能マシン１０２４へ送信し、サービス提供可能マシン１０２４は自身の出力をサイズ変更１２０４、背景除去１２０６、及び合成１２０８用のサービス提供可能マシン１０２６へ送信し、次に、サービス提供可能マシン１０２６はサービス提供可能マシン１０２２にフィードされる。すべてのコンポーネント１２０４〜１２０８をサービス提供可能マシン１０２６に配置することにより、これは、コンポーネント１２０４〜１２０８が個々のマシンにある場合に実行されるであろう、Ｅａｒ１０３０、１０３２、１２１８、及び１２２０によって実行される、冗長なサブコンポーネントの処理の削減を通じてだけでなく、余分なビデオ伸張ステップ及びビデオ圧縮ステップを除去することによっても、計算の節減になる。図１２ｃの構成は、このように、サービスネットワーク１２１２に取り入れられる全体の計算負荷を大幅に削減し、多くのサービスが進行中である場合のように、システム負荷レベルが高い場合に、好ましいものとすることができる。
【０１０６】
しかしながら、すべてのコンポーネントを１つのマシンに配置することの不利な点は、それらコンポーネントの組み合わせられた処理が、ビデオ送信元１２１４を起点とするストリーミングビデオのフレームレートに遅れない可能性が低くなるということである。たとえば、サイズ変更１２０４、背景除去１２０６、及び合成１２０８をすべて同じマシン（たとえば、１０２６）で３０フレーム／秒で行うことは難しい場合がある。それゆえ、いくつかのフレームを廃棄することが必要な場合があり、その結果、ビデオ品質は低下する。
【０１０７】
他方、図１２ｄに示すように、コンポーネント１２０４〜１２０８を３つの異なるマシン（たとえば、１０２２〜１０２６）にわたって拡散させることにより、３つのすべてのコンポーネント１２０４〜１２０８は、３０フレーム／秒でフレームを廃棄することなく、円滑に実行される可能性が高くなり、特に、これらのマシン１０２２〜１０２６が、比較的負荷が小さいことから選択された場合には、円滑に実行される可能性が高くなる。具体的には、ビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサイズ変更１２０４用のサービス提供可能マシン１０２４へ送信し、サービス提供可能マシン１０２４は自身の出力を背景除去１２０６用のサービス提供可能マシン１０２６へ送信し、サービス提供可能マシン１０２６は自身の出力を合成１２０８用のサービス提供可能マシン１０２２へ送信する。
【０１０８】
ＳＬＭ（たとえば、１０１２）によって行われる配置決定は、サービスビルダ（たとえば、１００８）へ返信される。サービスビルダは、それらの配置決定をマシンごとにグループ化し、構築要求（たとえば、１０１６）を、それらのマシンに常駐するローカルビルダ（たとえば、１０１８）へ送出する。ローカルビルダは、要求されたコンポーネント（たとえば、１２０４、１２０６、及び／又は１２０８）を起動し、構築要求に指定されたＵＲＬに従ってデータを送受信するようにそれらのコンポーネントに指示する。すべてのローカルビルダが、自身のコンポーネントの準備ができたことをサービスビルダに通知すると、サービスを通るメディアフローをＲＴＳＰの「ＰＬＡＹ」コマンドを介して開始することができる。図１２ｂ〜図１２ｄのマシン間のリンク上に示す画像は、実際のビデオストリームがさまざまなサービストポロジーを通ってフローする際に、そのビデオストリームに対して行われた処理の例を示していることに留意されたい。
【０１０９】
図１２ａ〜図１２ｄのこれらのサービス例は、ＭＳＡのいくつかの態様を示している。この手法は、処理されたストリームを複数のユーザデバイスへ分岐することだけでなく、数タイプのコンポーネントの処理を追加して組み込むように拡張できることが理解されよう。複数のユーザデバイスのそれぞれは、自身の分岐に沿って異なる処理をさらに要求することができる。また、この例はビデオ入力からビデオ出力を生成するが、他のサービスコンポーネントの多くは、ビデオ及び音響の解析を使用して、（たとえば、発話認識からの）テキスト又は（たとえば、ビジョンベースの人追跡及びアクティビティの解析からの）イベント要約及びタイムインデックス等の非メディアデータストリームを生成することができる。これに加えて、ＳＬＭ（たとえば、１０１２）は、サーバの計算負荷、ネットワークトポロジー及びネットワーク負荷レベル、並びに、同じサービス提供可能マシンにおけるコンポーネントの同時配置を通じて得ることができる処理削減量に応じて、複数の方法のいずれかでコンポーネントの分散を決定することができる。
【０１１０】
ビデオ及び音響の解析及び処理の多くの進歩した技法が、広く使用されたアプリケーションにまだ進出していないことに留意されたい。これは、複雑なメディア処理アプリケーションが必要とすることが多いかなりの量の処理資源を得る際、及び、これらのアプリケーションを興味のあるメディアの送信元及び望ましい出力位置に接続する際に、それらアプリケーションを構成することの難しさに部分的に起因する場合がある。ネットワーク自体に存在する柔軟なメディア処理を可能にすることによって、メディアサービスアーキテクチャの一実施の形態は、高度なメディアリッチアプリケーションを広範囲で主流として使用されるようにする潜在能力を有する。このアーキテクチャの実施の形態は、メディアＣＤＮと容易に統合され、サービスのモジュール性を可能にして再構成及び再利用を容易にし、少ないネットワーク資源の効率的な割り当てを増進する一方、エンドユーザのメンテナンス問題、互換性問題、及び可用性問題を削減する。
【０１１１】
ＭＳＡ内におけるマシン間の通信及び／又はノード間の通信は、本発明の実施の形態による多種多様な方法で実施できることに留意されたい。この通信には、サービスビルダがＳＬＭと通信すること、サービスビルダが１つ又は複数のローカルビルダと通信すること、ＬＲＭがＳＬＭと通信すること、及びＬＲＭがローカルビルダと通信することが含まれ得るが、これらに限定されるものではない。ＬＲＭとローカルビルダとの間の通信は、マシン間とはならない場合があるが、その代わり、オペレーティングシステム、ローカルファイル等を使用したマシン内又はノード内の通信とすることができる。ただし、使用するものは、オペレーティングシステム、ローカルファイル等に限定されるものではない。
【０１１２】
図１３は、本発明の一実施の形態に従って実行される、ストリーミングメディアサービスを管理するためのオペレーションのフローチャート１３００である。ストリーミングメディアサービスは、メディアストリームサービスと呼ぶこともできる。フローチャート１３００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１３００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１３に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１３００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１１３】
オペレーション１３０２では、ストリーミングメディアサービスの要求がクライアントから受信される。このストリーミングメディアサービスは、複数のコンポーネントメディアサービスを含む。
【０１１４】
オペレーション１３０４では、複数のコンポーネントメディアサービスのどのコンポーネントメディアサービスを、ネットワークの複数のサービスノードの或るサービスノードに割り当てるかについての判断が行われる。
【０１１５】
オペレーション１３０６では、複数のコンポーネントメディアサービスの或るコンポーネントメディアサービスを実行するように割り当てられた各サービスノードが、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知を受ける。
【０１１６】
オペレーション１３０８では、割り当てられた各サービスノードの入力通信ソケット及び出力通信ソケットが生成されて、割り当てられたサービスノード間の通信が可能にされる。
【０１１７】
ＭＳＡ内における複数のストリームのハンドリング
ビデオ合成等のアプリケーションは、メディアサービスアーキテクチャ（ＭＳＡ）によって可能にされる、ネットワークベースのメディアサービスとすることができる。ビデオ合成の場合、複数のビデオストリームが、新たなビデオストリームを生成するために共に処理されなければならない。このアプリケーションは、ピクチャインピクチャ効果を提供するのに使用することができる。
【０１１８】
図１４は、本発明の一実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。ＭＳＡは、異なる入力ストリーム（たとえば、１４０８及び１４１０）からコンテンツを得ることができるリスンＥａｒ（たとえば、１４１２及び１４１４）をセットアップすることによって、この種のサービスをサポートすることができる。メディアストリーミング送信元（たとえば、１４０２及び１４０４）は、サービスロケーションマネージャ（図示せず）によって指定される。このサービスロケーションマネージャは、（たとえば）２つのビデオサービスの中間のネットワークポイント（たとえば、サービスノード１４０６）に合成サービスを配置することができる。この合成サービス１４１６は、次に、２つのストリーム（たとえば、１４０８ａ及び１４１０）を互いに同期させ、ストリーム１４０８からトランスコードされたビデオ１４０８ａを他方のストリーム１４１０にオーバーレイすることによって「ピクチャインピクチャ」オペレーションを実行することができ、次いで、その結果生成されたビデオ１４２０を出力Ｅａｒ１４１８を通じて外部にストリーミングする。この実施の形態は、複数のストリームを、メディアサービス、この場合にはビデオ合成（たとえば、１４１６）の入力側でどのように管理できるかを示している。
【０１１９】
図１５は、本発明の別の実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。具体的には、共に図示しないローカルビルダ（又はＳＬＭ）が、既存のサービスセッションの出力を、新たに作成されたサービスセッションへの入力として「タップ（tap）」することにより、ストリーミングメディアがネットワークを通ってフローする際にそのストリーミングメディアを最適化することができる。
【０１２０】
図１５のコンポーネントは、上述した図１４のコンポーネントと同様に動作していることに留意されたい。一方、図１５内では、サービスが進行中であって、別のクライアント（図示せず）が、ビデオ１４０８をトランスコードしたものを要求した場合、ＳＬＭは、メッセージを（ＳＯＡＰ／ＸＭＬを介して）合成サービス１４１６へ送信して、ビデオ１４０８をトランスコードしたものを新たなクライアントに利用可能にすることができる。
【０１２１】
複数のメディアストリームを、本発明の実施の形態による多種多様な方法でハンドリングできることに留意されたい。たとえば、ビデオストリームは、それをトランスコードし、次いで、トランスコードされたビデオを複数のクライアントへ出力するサービス提供可能マシンが受信することができる。これに加えて、ビデオストリームは第１のノードに入り、背景除去が実行される。この第１のノードは、合成サービスを実行している第２のノードへ前景を送出する。その第２のノードは、他の或る送信元から入ってくる第２のビデオストリームも有する。第２のノードは、受信した前景ビデオ及び第２のビデオストリームの合成ビデオストリームを第５のノードへ出力する。これに加えて、第１のビデオストリームの他の或る部分は、第３のノードへも送出されている。この第３のノードは、或る人の識別を行っている場合があり、そのノードでは結合コンポーネントが実行されている。第３のノードは、第４のノードによって受信される或るインデックスを生成する。この第４のノードは、第５のノードへ出力される或るテキスト生成を実行している。第５のノードは、その入力を組み合わせるサービスを実行して、ビーチにいる人の出力を生成する。この出力は、このビーチにいる人の下にその人の名前を有する。これに加えて、音響ストリームが第４のノードに入っている場合があり、この音響出力ストリームは第５のノードへ出力される。
【０１２２】
図１６は、本発明の一実施の形態に従って実行されるオペレーションのフローチャート１６００である。フローチャート１６００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１６００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１６に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１６００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１２３】
オペレーション１６０２では、クライアントからのサービス要求及びパラメータをリスンして受信する。
【０１２４】
オペレーション１６０４では、要求されたサービスをどのように実施するかの記述を受信する。
【０１２５】
オペレーション１６０６では、サービスのインプリメンテーションを実行するためのネットワーク接続されたコンピュータを選択し、所望のネットワーク接続をどのように行うかを判断する。
【０１２６】
オペレーション１６０８では、選択された、ネットワーク接続されたコンピュータにおいて処理を行うように準備する。
【０１２７】
オペレーション１６１０では、ネットワーク及び選択されたコンピュータにおける処理を通るメディアのフローを開始する。データの結果は、サービス要求に指定された宛先へルーティングされることに留意されたい。
【０１２８】
図１７は、本発明の一実施の形態に従って実行されるオペレーションのフローチャート１７００である。フローチャート１７００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１７００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１７に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１７００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１２９】
オペレーション１６０２では、クライアントからのサービス要求及びパラメータをリスンして受信する。
【０１３０】
オペレーション１７０２では、サービスを実施するコンポーネントの抽象グラフ及び各コンポーネントの資源要件を受信する。
【０１３１】
オペレーション１７０４では、各サービスコンポーネントを実行するためのネットワーク接続されたコンピュータを選択する。
【０１３２】
オペレーション１７０６では、選択されたマシンにおけるコンポーネントの構築を要求し、それらの相互接続を準備する。
【０１３３】
オペレーション１７０８では、ネットワーク全体にわたって分散された処理コンポーネントを通るメディアのフローを開始する。データの結果は、サービス要求に指定された宛先へルーティングされることに留意されたい。
【０１３４】
Ｅａｒは、多種多様な方法で実施できることに留意されたい。たとえば、入力Ｅａｒは、ＲＴＰ／ＲＴＳＰを使用して受信を行うことができ、また、誤り耐性のある復号器プラグイン、スマートバッファリング、フロー管理、及び最小限データコピーも含むことができる。さらに、出力Ｅａｒは、ＲＴＰ／ＲＴＳＰを使用して送信を行うことができ、可変フレームレート符号化器プラグイン、スマートバッファリング、及びフロー管理を含むことができる。これに加えて、入力Ｅａｒ又は出力Ｅａｒは、圧縮機能又は伸張機能も含むことができる。各Ｅａｒは、単一のメディアストリームのフローの一方の端部（送信又は受信）を管理する。標準規格ベースのメディアストリーミング（ＲＴＰ／ＲＴＣＰ／ＲＴＳＰ）を使用することができる。これに加えて、Ｅａｒは、符号化器プラグイン及び復号器プラグイン（たとえば、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４、ＡＭＲ、ＷＡＶ）を使用して、メディア配信に適した圧縮フォーマットと、メディア処理に多く使用される非圧縮フォーマットとの間の変換を行う。また、バッファリングポリシー、フロー制御ポリシー、及びフレーム廃棄ポリシーがＥａｒによって実施されて、配信と処理との間のデータレートの不一致を取り除くこともできる。
【０１３５】
図１０、図１１、図１２ａ〜図１２ｄは、本明細書で説明した他の実施の形態と同様に、プロセスを含むことに留意されたい。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションが本明細書に開示されるが、このようなオペレーションは例示である。すなわち、これらの実施の形態は、他のさまざまなオペレーション、又は、本明細書に列挙したオペレーションの変形を実行することにも良く適している。本明細書で列挙したオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１３６】
本発明の具体的な実施の形態の上記説明は、図解及び説明の目的で提示されたものである。それら説明は、網羅的であることを目的とするものでもなければ、開示した正確な形態に本発明を限定することを目的とするものでもなく、多くの変更及び変形が、上記教示に鑑みて可能であることは明らかである。実施の形態は、本発明の原理及びその実用的な用途を最もよく説明し、それによって、他の当業者が、本発明、及び、検討した特定の使用に適するようなさまざまな変更を有するさまざまな実施の形態を最もよく利用することを可能にするために選ばれて説明されたものである。本発明の範囲は、本明細書に添付した特許請求の範囲及びその等価物によって画定されることが意図されている。
【図面の簡単な説明】
【０１３７】
【図１】メディアを複数の移動クライアントデバイスへ配信する従来の方法を示す図である。
【図２】メディアを処理して移動クライアントデバイスへ配信する従来の方法を示す図である。
【図３】本発明による一実施の形態の図である。
【図４】本発明による一実施の形態の図である。
【図５Ａ】本発明による一実施の形態の図である。
【図５Ｂ】本発明による一実施の形態の図である。
【図６】本発明の実施の形態を実施できる単一のコンテンツサーバを有するデータセッションハンドオフの例示のシステムのブロック図である。
【図７】本発明の実施の形態を実施できるコンテンツ分配ネットワークを有するデータセッションハンドオフの別の例示のシステムのブロック図である。
【図８Ａ】本発明の一実施の形態によるデータセッションハンドオフのプロセスを示すフローチャートである。
【図８Ｂ】本発明の一実施の形態によるデータセッションハンドオフのプロセスを示すフローチャートである。
【図９】本発明による一実施の形態の図である。
【図１０】メディアサービスアーキテクチャ（ＭＳＡ）が本発明の一実施の形態に従ってサービスを分解して分散させる例示のオペレーションを示すブロック図である。
【図１１】本実施の形態の一実施の形態によるサービスロケーション管理方法論のブロック図である。
【図１２ａ】本発明の実施の形態によるサービスのコンポーネントの例示の抽象グラフである。
【図１２ｂ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１２ｃ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１２ｄ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１３】本発明の一実施の形態に従って実行される、ストリーミングメディアサービスを管理するためのオペレーションのフローチャートである。
【図１４】本発明の一実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。
【図１５】本発明の別の実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。
【図１６】本発明の一実施の形態に従って実行されるオペレーションのフローチャートである。
【図１７】本発明の別の実施の形態に従って実行されるオペレーションのフローチャートである。
【符号の説明】
【０１３８】
１０２・・・コンテンツサーバ
１０４、１０６、１０８・・・無線基地局
１１０、１１２、１１４、１１６、１１８、１２０・・・移動クライアントデバイス
１２０・・・電子デバイス
１２４、１２６、１２８、１３０・・・コピーの送信
１２２・・・ ラップトップ
２００、３００・・・ネットワーク
２０２、２０４、２０６・・・メディアサービスノード
２０８・・・ストリーミングメディア
２１０・・・メディアストリーミング
３０２・・・サービスロケーションマネージャ
３０４、３０６・・・サービスポータル
３０８・・・要求
３１０・・・リダイレクト
４０４・・・通信
４０６、４０８、４１０・・・観察又は監視
５０２・・・メディアのストリーミング
５０４・・・メディアストリームのストリーミング
５０６・・・メディアストリーミングセッション
６０２、６０４・・・トランスコーダ
６０８、６１０・・・セル
６１４・・・コンテンツ分配ネットワーク
６１６、６１８・・・エッジサーバ
１００１・・・コンポーネントの抽象グラフ
１００２・・・ユーザデバイス
１００３・・・出力ディスプレイ
１００４・・・メディアサービス要求
１００６・・・サービスポータル
１００８・・・サービスビルダ
１０１０・・・コンポーネント配置要求
１０１２・・・サービスロケーションマネージャ
１０１４・・・コンポーネント配置決定
１０１６・・・構築要求
１０１８・・・ローカルビルダ
１０２０・・・コンポーネント
１０２２、１０２４、１０２６・・・サービス提供可能マシン
１０２８・・・インターネット
１０３０、１０３２・・・Ｅａｒ
１０３３・・・コンテンツサーバ
１０３５、１０３７・・・ライブカメラ
１１０２・・・ネットワーク距離テーブル
１１０４・・・前の決定テーブル
１１０６・・・マシン配置コスト
１１０８・・・資源要件ルーチン
１１１０、１１１２、１１１４・・・ローカル資源マネージャ
１１１６・・・資源照会
１２０２・・・ビデオ送信元
１２０４・・・サイズ変更
１２０６・・・背景除去
１２０８・・・合成
１２１０・・・ビデオ宛先
１２１２・・・ネットワーク
１２１４・・・ビデオ送信元
１２１６・・・ＰＤＡ
１４０２、１４０４・・・ビデオ
１４０６・・・サービスノード
１４０８、１４１０・・・入力ストリーム
１４０８ａ・・・ビデオ
１４１２、１４１４、１４１８・・・Ｅａｒ
１４１６・・・ビデオ合成
１４２０・・・ビデオ
【技術分野】
【０００１】
本発明は、ストリーミングメディアサービスを管理するための方法に関する。
【背景技術】
【０００２】
［背景］
クライアントデバイスがメディアファイルの配信を要求することが、その要求したメディアファイルに対して雑音低減等の或る処理が行われることを伴って行うことができるシステムがある。要求されたメディア配信がサーバによって受信されると、メディアファイルは取り出され、次いで、要求された処理が、サーバによりそのメディアファイルに対して実行される。この処理が完全に行われると、サーバは、処理されたメディアファイルをクライアントデバイスへ送信する。このタイプのシステムに関連した問題がある。たとえば、サーバが、異なる要求側クライアントデバイスへのメディアファイルの処理及び送信の多くの個別の要求をハンドリングしようと試みている場合、クライアントデバイスのユーザは、かなり長い間待たなければならない場合がある。また、ストリーミングメディアファイルは非常に大きい場合があり、ストリーミング配信の開始前にその内容に対して要求された処理を完了するには長い時間を要する場合がある。これは、特に、クライアントデバイスのユーザが期限前に何かを完了しようと試みている場合に、そのユーザにフラストレーションを与えている場合がある。
【０００３】
これらの理由及び他の理由から、本発明が必要とされる。
【発明の開示】
【課題を解決するための手段】
【０００４】
［発明の概要］
本発明の一実施の形態は、ストリーミングメディアサービスを管理するための方法を含む。本方法は、ストリーミングメディアサービスの要求をクライアントから受信することを含む。本ストリーミングメディアサービスは、複数のメディアサービスコンポーネントを含む。さらに、本方法は、ネットワークの複数のサービスノードの或るサービスノードに、複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断することを含む。本方法はまた、複数のメディアサービスコンポーネントの或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知することを含む。
【発明を実施するための最良の形態】
【０００５】
［好ましい実施の形態の説明］
次に、本発明の実施の形態を詳細に参照する。本発明の実施の形態の例は、添付図面に示されている。本発明は、実施の形態と共に説明されるが、実施の形態は、本発明をこれら実施の形態に限定することを目的としているものではないことが理解されよう。逆に、本発明は、代替形態、変更形態、及び等価物を包含することを目的とし、これら代替形態、変更形態、及び等価物は、添付の特許請求の範囲によって画定された本発明の精神及び範囲内に含めることができる。さらに、本発明の以下の詳細な説明では、本発明の十分な理解を提供するために、多数の具体的な詳細が述べられている。しかしながら、本発明は、これらの具体的な詳細がなくても実施できることが当業者には明らかであろう。それ以外の場合には、本発明の態様を不必要に分かりにくくしないように、既知の方法、手順、コンポーネント、及び回路は詳細に説明していない。
【０００６】
［表記法及び用語法］
以下の詳細な説明のいくつかの部分は、計算システム又はデジタルシステムのメモリ内のデータビットに対するオペレーションの手順、論理ブロック、処理、及び他のシンボル表現の観点から提示される。これらの説明及び表現は、データ処理技術における当業者が自身の作業の内容を他の当業者に最も効果的に伝えるのに使用する手段である。手順、論理ブロック、プロセス等は、本明細書では、一般的に、所望の結果をもたらすオペレーション又は命令の自己矛盾のないシーケンスであると考えられる。オペレーションは、物理量の物理的な操作を含むことができる。必ずしもそうではないが、通例、これらの物理的な操作は、計算システム又は類似の電子計算デバイスにおける記憶、転送、組み合わせ、比較、及びそれ以外の操作を行うことができる電気信号又は磁気信号の形態を取る。便宜上の理由から、且つ、共通の用法に関して、これらの信号は、本発明に関しては、ビット、値、要素、シンボル、文字、用語、数字等と呼ばれる。
【０００７】
一方、これらの用語のすべては、物理的な操作及び物理量に言及するものと解釈されるべきであり、単なる便利なラベルであり、さらに、当該技術分野で一般に使用される用語に鑑みて解釈されるべきであることに留意すべきである。特に指定のない限り、以下の説明から明らかなように、本発明の説明の全体にわたって、「判断」、「適用」、「処理」、「実行」、「決定」、「確認」、「送信」、「受信」、「取り出し」、「提供」、「認識」、「生成」、「利用」、「除去」、「通知」、「排除」、「廃棄」、「実施」、「使用」、「記憶」等の用語を利用した説明は、データの操作及び変換を行う計算システム又は類似の電子計算デバイスの動作及びプロセスを指すことが理解される。データは、計算システムのレジスタ及びメモリ内では物理（電子）量として表され、他のデータに変換される。他のデータも、同様に、計算システムのメモリ若しくはレジスタ、又は、他のこのような情報ストレージデバイス、送信デバイス、若しくは表示デバイスの内部で物理量として表されるものである。
【０００８】
［導入］
デスクトップマシン又はラップトップマシン（たとえば、図１の１２２）は、ネット上でのランダムなブラウジングの入力（さまざまなＵＲＬ又は検索照会のタイプ入力）要件及び出力（信頼性のある高帯域幅の接続）要件をより良くサポートできることから、通常、人々は、自身のこれらのデバイスから自身のウェブブラウジングの経験に基づいてさまざまなコンテンツサイト（たとえば、ビデオに基づく映画のページ）の位置を知る。これらのウェブユーザは、高帯域幅無線アクセスの保証があることを信じて、自身の携帯情報端末（ＰＤＡ）、たとえば１１０、１１６、及び１２０、又は、ビデオ使用可能携帯電話、たとえば１１２、１１４、及び１１８を使用して同じサイトへの接続を試みる場合がある。このより幅広いアクセスの結果、コンテンツプロバイダは、（接続の帯域幅に従った）広範囲の異なるビットレート、（処理能力管理ストラテジーに従ってそれ自体動的に変化する、クライアントデバイスで利用可能なＣＰＵ処理能力に従った）ビデオフレームレート、及び（クライアントデバイスで利用可能な表示サイズに従った）ビデオフレームサイズをサポートする必要がある。また、日本の３ＧＰＰ［１］プロバイダが遭遇するように、軽量のクライアントからの移動アクセスをサポートするには、サーバが、多数のセッションの状態変数を保持して更新することが必要とされる。簡潔にし、且つ、明瞭にするために、参考文献［１］〜［２０］の引用の詳細なリスト一式が本明細書の後部に見られる。これらリストされた参考文献［１］〜［２０］のすべては、背景資料として参照により本明細書に援用されることに留意されたい。たとえば、夕方の移行期の間、数千の移動ユーザの「フラッシュクラウド（flash crowd）」が東京の都心のオフィスエリアからレストラン地区へ多く見られる。
【０００９】
したがって、問題は２つの部分から成る。一方は、クライアントの能力に動的に調整されたフォーマットでビデオコンテンツ及び音響コンテンツを提供することである。他方は、そのストリーミングプロセスのサポートを動的に分散させて、不要な輻輳及びその結果生じる品質劣化を回避することである。この解決法の双方の部分が依存する因子は、それ自体、多くの場合、素早く変化しているので、これら双方の部分は動的に行われるべきである。
【００１０】
メディアサービスが、ストリーミングコンテンツ配信ネットワーク（ＣＤＮ（content -delivery network））基盤内において分散形式で統合及び管理されない限り、移動ストリーミングメディア（ＭＳＭ（mobile streaming media））の無線デバイスの潜在能力は、完全には実現されないことになる。本発明者等は、無線移動ストリーミングクライアントをサポートする既存のネットワーク基盤にわたって、信頼性のあるスケーラブルなメディアストリーミングを提供することに関して背景となる研究を説明する。本発明者等は、ＣＤＮ内で利用可能な分散資源の動的な監視によって、メディアサービスの管理された配置の手法を概説する。資源監視手法間のトレードオフも説明される。これは、本発明者等のＭＳＭ−ＣＤＮテストベッド内におけるサービスロケーションマネージャ（ＳＬＭ（service location manager））の例示のインプリメンテーションの説明としてのものであり、且つ、当該ＳＬＭの結果として生じるものである。
【００１１】
［移動クライアントへの適合型ストリーミングコンテンツ配信］
図１内において、移動ストリーミングメディアシステムの基本コンポーネントは、記憶されたメディアコンテンツ用のストリーミングサーバ（たとえば、１０２）、ライブストリーミングサーバ、及びストリーミングメディアクライアント（たとえば、１１０〜１２０）を含む。スケーラブルな形式で多数のユーザにビデオクリップを配信するために、既存のネットワーク上で、たとえば図３に示すような本発明のＭＳＭ−ＣＤＮオーバーレイを使用することができる。このＭＳＭ−ＣＤＮオーバーレイは、ストリーミングエッジ（又は代理（surrogate））サーバ及び管理サーバを含む。ストリーミングエッジサーバは、コンテンツの分配／キャッシュ機能［１６］、ストリーミング機能、資源監視機能、資源管理機能、及びシグナリング機能を有する。また、ストリーミングエッジサーバは、ライブメディアの適合等のメディアサービス機能も実行することができる。管理サーバは、コンテンツを分配させ、クライアントの位置並びに現在のシステム及びネットワークの負荷に基づいてメディアセッションを割り当てる。換言すると、管理サーバは、クライアントが要求したセッションを利用可能な最良のエッジサーバに割り当てる。
【００１２】
ＭＳＭ−ＣＤＮシステムは、表示能力及び復号能力の観点から、幅広いクライアントのサポートを援助すべきである。図１内において、これを行う「従来」の方法は、送信元の素材の複数のコピーをコンテンツサーバ１０２に記憶し、次いで、クライアント（たとえば、１１２、１１４、１１６、及び１２０）との或る初期交渉に従ってどのコピーを送信するか（たとえば、矢印１２４、１２６、１２８、及び１３０によって示すように）を選択することである。しかしながら、ストリーミングセッション中に、ネットワーク１００のさまざまな部分からクライアントへの接続の信頼性及び帯域幅は、クライアントが物理的な位置を移動すると変化し、また、他のクライアントからのストリーミングセッションが、共有された無線環境内で開始及び終了すると変化する。この交渉は、複数の記憶された符号化によって容易に提供されるものよりも広範囲の選択肢に及ぶ必要があり、その交渉プロセスは、ネットワークの状態が変化するにつれて動的に更新されるべきである。リアルタイムのメディアサービスは、今日のネットワークサーバマシンにおいて実用的且つ入手可能であるので、メディアレート、サイズ、及び帯域幅のこの広範囲な必要性は、図２のネットワーク２００内にメディアサービスを組み込むことによって満たすことができる。図２内において、矢印２０８は、コンテンツサーバ１０２からメディアサービスノード２０２へ出力されるストリーミングメディアを示しているのに対して、矢印２１０は、サービスノード２０２からクライアント１０２への処理されたメディアストリーミングを示している。図１のネットワーク１００及び図２のネットワーク２００は、無線基地局１０４、１０６、及び１０８を含むことに留意されたい。これらの無線基地局は、移動クライアントデバイス１１０、１１２、１１４、１１６、１１８、１２０、及び１２２との無線通信の一部として利用することができる。
【００１３】
このリアルタイムで待ち時間の少ないメディアサービングを提供することは、メディアサービスノードとも呼ばれるエッジサーバ［２、７］の重要な機能の１つである。メディアサービスプロセスは、たとえば、圧縮ビデオストリームをクライアントディスプレイに適合させることができる。また、メディアサービスプロセスは、ＲＴＣＰベースのフィードバックを使用して、クライアントデバイスによって経験された、変化する帯域幅の状態に、ストリーム内のビットレートを動的に調整することができる。これらのリアルタイムのメディアサービス提供は、今や、圧縮領域処理［１４、１５、１０］を使用することにより、標準的なデスクトップマシン又はサーバマシンに設けることができる。
【００１４】
これらの新しい圧縮領域のサービス提供技法は、個々の各サービス提供セッションの計算コストを大幅に削減することができ、それによって、移動ストリーミングを実用的且つ入手可能なものにすることができる。しかしながら、コンテンツ管理と同様に、メディアサービスストリームのサイズ及び継続時間並びにそれらのストリームを変更することに関連した計算要求は、注意深い管理を必要とする場合がある。数千又は数百万の移動クライアント（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）が存在する状況では、分散されたエッジサービスとしてメディアサービスを提供できるように、計算能力の高いサーバがその基盤全体にわたって離散され得る。
【００１５】
たとえば、上記説明によって必要とされたメディアサービスを提供する１つの方法は、各コンテンツサーバが、固定されたメディアサービスノード（たとえば、図２の２０２、２０４、又は２０６）へのクライアントブラウザ（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）の静的なリダイレクトを提供することである。このタイプの静的なリダイレクトは、コンテンツ配信の観点からよく検討される。ローカルな「ミラー」サイトへのリダイレクトは、今日のウェブ環境では日常的に行われている。この静的なリダイレクトの不利な点は、この静的なリダイレクトが、ネットワーク１００及びサーバの負荷の変動のいずれも考慮していないことである。さまざまなノード（又はサーバ）で利用可能な帯域幅及び計算負荷は、クライアントの変化する要件に従って変化し、且つ、新たに追加されたクライアント又は新たに取り除かれたクライアントの変化する要件に従って変化する。したがって、異なるサーバにおけるメディアサービスプロセスの配置は、それ自体、動的であるべきであり、好ましくは、クライアントプロセッサが物理的な位置を変更するにつれて調整されるべきである。最後に、移動ウェブブラウジングを行う一般の人々が簡単に使用できるように、これらの動的な決定のすべては、隠蔽され、自動的にすることができる。
【００１６】
［サービスロケーション管理（ＳＬＭ）］
図３内において、動的なサービスロケーション管理の背後にあるアイデアは、最初の接触サイトを変更するように移動ユーザ（たとえば、１１０、１１２、１１４、１１６、１１８、及び１２０）に要求することなく、移動ストリーミング環境で必要とされる柔軟性を提供することである。一般的なシステムは、そうしないで、或る個数の広く公表されたポータルサイト（たとえば、３０４及び３０６）を提供する。これらのポータルは、（矢印３０８によって示すように）移動ユーザの最初の接触点であり、元のコンテンツサイトへのリダイレクトを受け付ける（コンテンツサーバ１０２への矢印３１０によって示される）。その後のすべてのリダイレクトは、動的なＳＭＩＬ書き換え［１６］を使用して、クライアントにトランスペアレントな方法で行われる。
【００１７】
一般に、図３は、クライアントデバイス１２０からサービスポータル３０６に入る要求を矢印３０８で示している。したがって、図４のサービスポータル３０６は、その後、（矢印４０４によって示すように）サービスロケーションマネージャ３０２と通信して、要求されたストリーミングメディアセッションを配置するための最良のサービスノードを見つけ出す。また、図４は、サービスロケーションマネージャ３０２が、双方向矢印４０６、４０８、及び４１０によって示される１組のメディアサービスノード２０２、２０４、及び２０６を観察又は監視していることも示している。サービスロケーションマネージャ３０２は、ストリーミングセッションを配置するための最良のサービスノードをサービスポータル３０６へ返す。したがって、図３、図４、及び図５は、セッションを開始させる方法のオペレーションを示している。図９は、その後の要求がネットワーク３００内に配置された時に、それらの要求が、それぞれそれらの同じオペレーションを通過することを示している。図５Ａ及び図５Ｂは、サービスロケーションマネージャ３０２が、二点鎖線の楕円５０６によって示すように或るサービスノード（たとえば、２０２）から別のサービスノード（たとえば、２０４）へ現在のセッションの割り当てを変更できることを示している。メディアサービスノード（たとえば、２０２、２０４、及び２０６）は、それぞれ、ハードウェア、ソフトウェア、又は、ハードウェア及びソフトウェアのあらゆる組み合わせとして実施することができることに留意されたい。これに加えて、サービスノード（たとえば、２０２、２０４、又は２０６）は、１つ又は複数の物理的な計算デバイスとして実施することができる。
【００１８】
図４内において、ポータルサイト３０６は、矢印３０８によって示すようにクライアント１２０により接触されると、矢印４０４によって示すようにサービスロケーションマネージャ（ＳＬＭ）３０２と接触する。単一のＳＬＭ３０２が自身の利用可能なサービスのポートフォリオに複数のタイプのサービスを有することができることに留意されたい。したがって、ＳＬＭ３０２は、各メディアサービスノード（たとえば、２０２、２０４、又は２０６）がメディアのストリームに対して実行できるサービスを（たとえば、テーブルで）把握している。メディアサービスには、ビデオ処理が含まれ得る。このビデオ処理は、トランスコード、ジッタ除去、顔認識に基づくダイナミッククリッピング、ビデオ解析、ビデオのサイズ変更、ビデオからのＯＣＲ、音響強調（audio enhancement）、背景除去、ビデオメディアのストリームに対して動作できるあらゆるもの等であるが、これらに限定されるものではない。これに加えて、メディアサービスには、音響処理が含まれ得る。この音響処理は、背景除去、音響速度の増減、音響強調（audio enhancement）、雑音低減、発話認識、音響解析、音響メディアのストリームに対して動作できるあらゆるもの等であるが、これらに限定されるものではない。次いで、ＳＬＭ３０２は、自身の決定を行っている時に、そのテーブルを一覧して、１つ又は複数のどのサービスノードが、要求された特定のメディアサービスを実行できるかを見つけ出す。
【００１９】
ポータルサイト３０６がＳＬＭ３０２と接触すると、ＳＬＭ３０２は、次に、要求された素材を所与のクライアント（たとえば、１２０）に供給するのにどのタイプのメディアサービスが必要とされるかを判断し、（部分的又は完全に）ＳＬＭ３０２の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のステータスを調べる。そのステータスは、メディアサービスノードのそれぞれにおける利用可能なサイクル及び利用可能なメモリの観点から要約することができる。付加的なステータス指示子が、メディアサービスノードのそれぞれからコンテンツプロバイダ（又は最も近いミラーサイト）への接続及びストリーミングクライアントへの接続の予想された帯域幅及び信頼性を含むことができる。収集されたステータス情報に基づいて、ＳＬＭ３０２は、ＳＭＩＬファイルを動的に生成し、その新たに生成されたＳＭＩＬ応答に、交渉されたあらゆるパラメータと共に自身のＵＲＬを組み込むことによって、適切なサービスノードへクライアントのリダイレクトを行う（図５）。３ＧＰＰ又はＩＳＭＡ［５］に準拠したストリーミングクライアントは、次に、書き換えられたＳＭＩＬファイルを構文解析して、コンテンツサーバ１０２及びメディアサービスノード２０２との適切なストリーミングセッションをセットアップする。したがって、全体の処理はエンドユーザにトランスペアレントである。矢印５０２は、コンテンツサーバ１０２からメディアサービスノード２０２へのメディアのストリーミングを示しているのに対して、矢印５０４は、サービスノード２０２からクライアント１２０への処理されたメディアストリームのストリーミングを示していることに留意されたい。メディアサービス提供を必要とする他のクライアントからのその後のコンテンツ要求も、新たな現在のネットワーク資源及び計算資源に従って分散される（図９）。
【００２０】
動的サービスロケーションのための資源監視
上記説明では、ＳＬＭ３０２は、自身の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のそれぞれのステータスを調べて、現在のクライアント要求により必要とされるメディアサービスタスクをどのようにディスパッチするのが最良であるかを判断する。この調査を完了できるさまざまな方法がある。以下では、本発明に従って実施できるいくつかの異なる実施の形態を詳述する。
【００２１】
基本的な「ポーリングベース」の監視
一実施の形態内では、ＳＬＭ３０２の制御下にあるメディアサービスノード（たとえば、２０２、２０４、及び２０６）のステータスを監視する一手法は、プロセスが「ポーリングベース」であることである。この手法では、ＳＬＭ３０２は、メディアサービスの新たなクライアント要求を得るたびに、（たとえば、そのＣＰＵの個数及びクロック速度、その設置されたメモリ、並びにその最良の場合のネットワーク帯域幅の観点から）十分な資源を有する可能性のあるサービスノードのそれぞれと積極的に接触する。この「資源ポーリング」に応答して、各サービスノード（たとえば、２０２、２０４、又は２０６）は、自身の現在利用可能な資源の記述を提供する。この記述は、所与の時点における空き状態の計算サイクル数及び空き状態のメモリ量を含むことができる。理想的には、この記述は、コンテンツサーバ１０２及びクライアント（たとえば、１１０〜１２０）への空き状態のネットワーク帯域幅の或る見積もりも含む。ＳＬＭ３０２は、この情報を収集し、次に、空き状態のネットワーク帯域幅、計算資源、及びメモリ資源の最良の組み合わせを提供するサービスノードならばいずれのサービスノードへでも、要求されたメディアサービスタスクをディスパッチすることができる。
【００２２】
この「ポーリングベース」の手法は、空き状態のサービスノード資源の最新のスナップショットを提供するという利点を有する。また、この手法は、サービスノードが、ネットワーク障害又はマシン障害のいずれかによって非稼動状態である時の明瞭な表示も提供する。他方、ポーリングベースの資源監視は、拡張性の観点から厳しい制限を有する。クライアント要求の個数及び監視されるメディアサービスノードの個数が増大するにつれて、それらの所産としてポーリング要求の個数も増大する。監視されるメディアサービスノードの個数は、クライアントのサービス要求の個数に正比例して増大する傾向があるので、ポーリング要求の個数は、事実上、クライアントの個数の２乗として増大する。
【００２３】
基本的な「テーブルベース」の監視
ポーリングの実施の形態に代わるものは、資源情報がメディアサービスノード（たとえば、２０２、２０４、及び２０６）から監視を行うＳＬＭ３０２へ「プッシュされる」ものである。この手法では、更新は、システム及びネットワークの管理ソフトウェアによって提供される等、サービスロケーションスーパーバイザ（ＳＬＳ（service location supervisor））によって周期的に提供される。このＳＬＳは、各メディアサービスノードで実行されている軽量のバックグラウンドデーモンとすることができる。各クライアント要求時に、ＳＬＭ３０２は、ＳＬＳが提供した情報を収集すること（及び日付を付けること）から作成された空き状態資源データベースにアクセスする。これによって、資源監視によって受ける接続要件が、メディアサービスノードの個数の２次依存関係から１次依存関係へ削減される。
【００２４】
さらに、ＳＬＭ３０２自体に監視能力及び「再開（re-launch）」能力を含めることもできる。単純なＳＬＭデーモンは、最新のＳＬＳデータベースリフレッシュのタイムスタンプを監視し、或るプリセット時間間隔よりも長い間接触していないＳＬＳマシンとの接触を試みる。おそらく、これらの接触の試みのかなりの部分は、進行中のネットワークの障害又はメディアサービスノードの障害のために失敗することになる。しかしながら、ＳＬＳの接触を再開しようとするこれらの試みは、非同期に行われるので、クライアント要求に対するＳＬＭ３０２の応答時間に影響を与えない。
【００２５】
テーブルベースの監視は、直接的なポーリングベースの結果よりも時期の遅れた資源情報に依拠するという不利な点を有する。この弱点は、資源監視の次の実施の形態によって対処される。
【００２６】
［ノードから受信された近時データに基づくＳＬＭの適合性及びＳＬＭの動作］
機能強化された「テーブルベース」の監視
この実施の形態内では、テーブルベースの監視手法は、時期の遅れた情報の欠点を低減するように変更される。これは、ＳＬＭ３０２が近時のクライアントタスクをディスパッチしたメディアサービスノードの短期記録をＳＬＭ３０２に保持させることによって行われる。ＳＬＭ３０２は、次に、それに応じて、どの資源が新たなジョブに利用可能であるかの自身の予測を調整する。たとえば、資源統計値が或るメディアサービスノードから最後に送信される前に、メディアサービスタスクがそのサービスノードに１分未満ディスパッチされた場合、そのノードの資源記録は、前にディスパッチされたそのメディアサービスジョブによって要求された資源予算よりも低くなる。
【００２７】
［共有サービスを有する複数のＳＬＭ］
メディアサービスノードのいくつかが、２つ以上のＳＬＭの権限下にある場合（すなわち、分散された１組のＳＬＭマシンの２つ以上が、そのサービスノードへのメディアサービス要求のリダイレクトを許可された場合）、ディスパッチが行われるとすぐに、各ＳＬＭは、ディスパッチされたジョブに関する情報も、そのメディアサービスノードにおけるＳＬＳデーモンへ伝えるべきである。そのようにして、ＳＬＳデーモンは、すべてのディスパッチの通知を他のＳＬＭプロセッサへ再送することができ、それによって、異なるＳＬＭからの交差するディスパッチによって、メディアサービスノードの計算資源又はネットワーク資源の定数以上の予約が取られる回数を最小にすることができる。
【００２８】
共有サービスを有するＳＬＭを１つ又は複数有することによって、これは、サービスノードが２つ又は３つ以上の異なる組織又はグループ内で動作できる局部的なセグメンテーション（regional segmentation）を可能にすることに留意されたい。したがって、サービス要求をそのサービスノードに割り当てる能力をＳＬＭに与えることが望ましい。これに加えて、このように、各ＳＬＭの権限からサービスノードを除去しないことにより、ＳＬＭの過負荷を回避することができる。複数のＳＬＭがサービスを共有することを可能にすることは、組織、グループ、又は企業内でサービスを結び付けることがサービスの共有に適している場合に現実的なものとなり得る。これに加えて、ＳＬＭ間でのサービスの共有は、ＳＬＭの１つが動作不能になった場合のフォールトトレランスを提供することができる。さらに、ＳＬＭ間でのサービスの共有は、ＳＬＭに負荷バランシングを提供することができる。
【００２９】
時期遅れの情報の欠点を低減するために、ＳＬＭ３０２は、自身が近時のタスクをディスパッチしたサービスノードの短期記録を保持できることに留意されたい。そういうことから、このタイプの「プッシュ」ベースの監視では、サービスノードは、一定の周期で起こり得る自身のデータをＳＬＭ３０２へプッシュしている。サービスノード（たとえば、２０２、２０４、及び２０６）によって送信されている統計値のそれぞれは、平均化を行うことによって、同様にその内部に一定の待ち時間を有する。そういうことから、何がＳＬＭ３０２で発生しても、ＳＬＭ３０２が何かをディスパッチする時、ＳＬＭ３０２は、前にジョブをディスパッチしたのはどの資源かという情報を有するディスパッチが取るか又は取るものと予想される、自身のサービスノードの実行テーブルを保持する。このようにして、ＳＬＭ３０２が自身の次のディスパッチを行う時、ＳＬＭ３０２は、サービスノードから得られた自身のテーブルの統計値を使用することができ、それらの統計値がどの程度古いものかを理解することができる。したがって、ＳＬＭ３０２は、それらの統計値が受信されてから行われたあらゆるディスパッチがそれらの統計値に全く反映されないことを知ることができる。ＳＬＭ３０２は、実際の利用可能な資源が各サービスノードにあると予想するための正しい近似を得るために或る時点で線形補間を行うことができることに留意されたい。
【００３０】
ＳＬＭ３０２は、この利用可能なテーブルを有し、当該テーブルは、所与のサービスノード（たとえば、２０２）からのその最新の更新を示す日時が付けられている。ＳＬＭ３０２が有する、そのサービスノードからの最新の統計値がたとえば１０分古いものであり、ＳＬＭ３０２が５分毎の更新を予想している場合、ＳＬＭ３０２は、そのサービスノードに関して何かが故障していると判断して結論付けることができる。その問題はいくつかのものである場合があり、たとえば、ネットワーク３００が障害を受けている場合もあるし、サービスノード２０２が障害を受けている場合もあるし、あるいはＳＬＳデーモンがそのサービスノード２０２において停止している場合もある。したがって、ノードがＳＬＭ３０２に報告することによって、この情報を提供することもできるし、あるいはＳＬＭ３０２が、サービスノードのすべてにおける自身のテーブルの一般的なラウンドロビンチェックを、オーバーヘッドの低いバックグラウンドプロセスとして行うこともできる。このようにして、ＳＬＭ３０２は、サービスノードの１つ又は複数に関連する場合がある問題に気付くことができる。問題が検出された場合、ＳＬＭ３０２は、そのサービスノードにおいて、ＳＬＳデーモンの再起動を試みることもできるし、ＳＬＭ３０２がノードと接触できない場合には、ＳＬＭ３０２は、オープンビュー（Open View）監視システムを用いて、その特定のノードに関する問題を示すフラグを立てることもできる。この機能を実行することによって、ＳＬＭ３０２は、動作不能のおそれがあるメディアサービスノードへのストリーミングセッションのディスパッチも割り当ても行わないことに留意されたい。
【００３１】
テストベッドの結果
サービスロケーション管理アーキテクチャの一実施の形態は、メディアサービスを移動ストリーミングメディア配信システムと統合するように設計された。移動ストリーミングメディア（ＭＳＭ（mobile streaming media））のテストベッドは、これらの能力を実証するように設計、開発、及び実施された。ＭＳＭのテストベッドは、複数の記憶コンテンツ／ライブコンテンツストリーミングサーバ及びストリーミングメディアクライアントから成る。ストリーミングエッジサーバ及び管理サーバは、共に、適合型ＭＳＭ−ＣＤＮを形成する。ストリーミングエッジサーバは、コンテンツの分配及びキャッシュ、ストリーミング、資源監視、資源管理、並びにシグナリングのサポートを提供する。これに加えて、ストリーミングエッジサーバは、ライブストリームの分割（又は、メディアストリーミングセッションのアプリケーションレイヤのマルチキャスト）や、ＭＰＥＧ−４ビデオストリームのリアルタイムのメディアトランスコード等のメディアサービス機能も実行する。
【００３２】
これらのストリーミングサーバ、クライアント、及びエッジサーバは、３ＧＰＰ標準規格に準拠することができ、したがって、セッション記述プロトコル（ＳＤＰ（Session Description Protocol））［４］、リアルタイムストリーミングプロトコル（ＲＴＳＰ（Real Time Streaming Protocol））［１３］、及びリアルタイムトランスポートプロトコル（ＲＴＰ（Realtime Transport Protocol））［１２］を使用することができ、ＭＰＥＧ−４［８］ビデオ標準規格及びオーディオ／モデムライザ（ＡＭＲ（Audio/Modem Riser））音響メディア標準規格をサポートすることができる。ストリーミングエッジサーバ及び管理サーバは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）［３］をシグナリング用に使用することができる。他の標準規格も本発明に従って利用できることに留意されたい。
【００３３】
サービスロケーションマネージャ（ＳＬＭ）３０２は、クライアントが要求したストリーミング／メディアサービスセッションを、ネットワーク及びシステムの資源使用量に基づいて「最良の利用可能な」ストリーミングエッジノードに割り当てる。ＳＬＭ３０２は、１組のストリーミングエッジノードにおける統計値を収集し、それらの統計値を解析して、最良の利用可能なエッジサービスノードを選択し、その選択したエッジノードをクライアント要求に応答して伝える。ＳＬＭ３０２は、ＳＯＡＰ／ＸＭＬシグナリングを使用して、エッジノードから資源使用量の統計値を収集し、選択したエッジノードを要求側クライアントに動的に伝える。
【００３４】
ＳＬＭ３０２の資源監視に対して提案した３つの手法のそれぞれは、ＭＳＭ−ＣＤＮのテストベッドで実施されてテストされた。ポーリングベースの監視は、場合により、完全なストリーミング障害という結果になった。これは、移動クライアントの応答タイムアウト期間があまりにも小さく設定され、その結果、クライアントが諦める前に、ＳＬＭ３０２がポーリング応答のすべてを収集し、それらを処理し、且つ、動的に生成されたＳＭＩＬ応答を提供するのに十分な時間を有しない場合に発生した。これらのあまりにも遅い応答は、通常、メディアサービスノードの１つ又は複数がネットワークから切り離された時に起こる。これらの場合、ＳＭＬ３０２は、そのサービスノードをクライアントの可能性のあるメディアサービスプラットフォームとして無視する前に、標準的なＳＯＡＰタイムアウト期間、待機していた。ポーリングベースの監視に関連した遅延も、ネットワークの拡大縮小を優雅にサポートしない。監視されるサービスノードの個数が増加するにつれて、ポーリングに関連した遅延は比例して増加する。
【００３５】
基本的なテーブルベースの監視は、このタイムアウトの障害モードを受けなかった。しかしながら、この監視は、多くの場合、準最適な負荷バランシングという結果になった。これは、クライアント要求が間断なく到来した時に発生した。たとえ、メディアサービスノードにおけるＳＬＳが、ＳＬＭ３０２のデータベースに含まれる空き状態資源情報を更新するように変更されても、新たなローカルメディアサービスタスクに遭遇するたびに、この準最適な負荷バランシングは依然として発生した。時に、この準最適なタスク割り当ては、新たにインスタンス化されたタスクに対する空き状態資源統計値の応答の待ち時間に起因するものであった。さらに多くの場合、準最適なタスク割り当ては、ＳＬＭ３０２が、（動的なＳＭＩＬファイルをクライアントへ送信することにより）メディアサービスタスクを特定のサービスノードにディスパッチした後であって、その以前のクライアントが、（ＲＴＳＰのＳＥＴＵＰ要求を送信することにより）選択されたサービスノードにそのメディアサービスタスクを実際に確立する前に到来する新たなクライアント要求に起因するものであった。
【００３６】
機能強化されたテーブルベースの監視は、ポーリングベースの監視で見られたタイムアウト障害、及び、基本的なテーブルベースの監視で見られた、インターリーブされた要求の誤りの双方を回避した。
【００３７】
メディアサービスのハンドオフの管理のためのＳＬＭ
図５Ａ及び図５Ｂは、本発明による一実施の形態を示している。具体的には、サービスロケーションマネージャ３０２は、或るメディアサービスノード（たとえば、図５Ａに示す２０２）から別個のメディアサービスノード（たとえば、図５Ｂに示す２０４）へメディアストリーミングセッション（二点鎖線の楕円５０６によって示す）を移動させるのに使用することができる。この移動は、ハンドオフと呼ぶことができる。たとえば、サービスノード２０２が、ストリーミングメディアセッションをハンドオフする必要があると判断した場合（又は、ネットワーク３００の他の或るコンポーネントがこれを判断した場合）、この情報はＳＬＭ３０２へ通信することができる。ＳＬＭ３０２は、次に、その特定のストリーミングセッションをどのサービスノードにハンドオフするかを算定するために、その時点で、サービスノードの負荷、ネットワーク３００の負荷等を計算することができる。このように、あらかじめ定義されたハンドオフノードを決定する必要はない。その代わり、ハンドオフノードは、ＳＬＭ３０２によって実行中に決定される。したがって、所望のサービスを実行できる最良のメディアサービスノードがＳＬＭ３０２によって選択される。次に、ハンドオフは、図６、図７、図８Ａ、及び図８Ｂで説明するものと同様の方法で行うことができる。ハンドオフを実行する方法は、最初のサービスノード（たとえば、２０２）によって実行されているサービスのタイプに特有のものとすることができることに留意されたい。
【００３８】
図６は、本発明の実施の形態を実施できる単一のコンテンツサーバ１０２を有するデータセッションハンドオフの例示のシステム６００のブロック図である。システム６００は、データセッションハンドオフに含めることができる例示のメディアサービスとして、トランスコードを含むことに留意されたい。システム６００は、任意のメディアサービスを含むことができ、トランスコードに限定されるものでないことが理解される。一実施の形態では、システム６００において、データ（たとえば、ビデオメディア）が、無線リンクを介して移動クライアント（たとえば、電子デバイス）へストリーミングされる。一実施の形態では、そのデータは、ストリーミング音響やストリーミングビデオ等、連続フローで構造化されて処理されるストリーミングデータである。ストリーミングデータは複数のデータパケット（たとえば、部分）を含み、各パケットはそのフローにおいて順序付けられている。
【００３９】
一実施の形態では、システム６００は、コンテンツサーバ１０２（たとえば、データ送信元）、トランスコーダデバイス６０２及び６０４、並びに電子デバイス１２０を備える。一実施の形態では、トランスコーダ６０２は、セル６０８に位置する電子デバイスへメディアストリームを供給するように動作することができ、トランスコーダ６０４は、セル６１０に位置する電子デバイスへメディアストリームを供給するように動作することができる。本実施の形態では、コンテンツサーバ１０２は、トランスコーダ６０２へ送信される高ビットレートで高解像度のビデオストリームを生成する。トランスコーダ６０２は、そのビデオストリームを、電子デバイス１２０へその後送信される低ビットレートで中解像度のビデオストリームにトランスコードする。
【００４０】
本アプリケーションにおいて、一実施の形態では、トランスコーダ６０２は第１のトランスコーダと呼ばれ、トランスコーダ６０４は第２のトランスコーダと呼ばれる。別の実施の形態では、トランスコーダ６０２は第２のトランスコーダと呼ばれ、トランスコーダ６０４は第１のトランスコーダと呼ばれる。簡潔にし、且つ、明瞭にするために、本明細書では、本発明の実施の形態をトランスコーダ６０２及びトランスコーダ６０４に関して説明する。
【００４１】
一実施の形態では、電子デバイス１２０は移動デバイスである。本実施の形態では、電子デバイス１２０は、無線接続上のデータを受信するように構成された任意のデバイスである。この任意のデバイスには、ラップトップコンピュータ、パームトップコンピュータシステム、携帯電話等が含まれるが、これらに限定されるものではない。
【００４２】
図７は、本発明の実施の形態を実施できるコンテンツ分配ネットワーク６１４を有するデータセッションハンドオフの例示のシステム７００のブロック図である。システム７００は、データセッションハンドオフに含めることができる例示のメディアサービスとして、トランスコードを含むことに留意されたい。システム７００は、任意のメディアサービスを含むことができ、トランスコードに限定されるものでないことが理解される。一実施の形態では、システム７００において、データ（たとえば、ビデオメディア）が、無線リンクを介して移動クライアント（たとえば、移動電子デバイス）へストリーミングされる。一実施の形態では、そのデータは、ストリーミング音響やストリーミングビデオ等、連続フローで構造化されて処理されるストリーミングデータである。
【００４３】
一実施の形態では、システム７００は、コンテンツ分配ネットワーク６１４（たとえば、データ送信元）、トランスコーダデバイス６０２及び６０４、並びに電子デバイス１２０を備える。一実施の形態では、トランスコーダ６０２は、セル６０８に位置する電子デバイスへメディアストリームを供給するように動作することができ、トランスコーダ６０４は、セル６１０に位置する電子デバイスへメディアストリームを供給するように動作することができる。コンテンツ分配ネットワーク６１４は、複数のエッジサーバ（たとえば、エッジサーバ６１６及び６１８）を備える。エッジサーバ６１６及び６１８は、それぞれが当該エッジサーバに地理的に非常に近い移動クライアントへメディアを供給するためのものとなるように地理的に分散され、ネットワークオーバーヘッドを軽減するようになっている。本実施の形態では、エッジサーバ６１６は、トランスコーダ６０２へ送信されるフルビットレートで高解像度のビデオストリームを生成する。トランスコーダ６０２は、そのビデオストリームを、電子デバイス１２０へその後送信される低ビットレートで中解像度のビデオストリームにトランスコードする。
【００４４】
一実施の形態では、電子デバイス１２０は移動デバイスである。本実施の形態では、電子デバイス１２０は、無線接続上のデータを受信するように構成された任意のデバイスである。この任意のデバイスには、ラップトップコンピュータ、パームトップコンピュータシステム、携帯電話等が含まれるが、これらに限定されるものではない。
【００４５】
図６及び図７を参照して、システム６００及びシステム７００は、共に、トランスコーダ６０２及び６０４を使用して、ビデオストリームを、ターゲットの電子デバイス（たとえば、電子デバイス１２０）の表示能力と一致した低ビットレートのストリームにトランスコードする。
【００４６】
一インプリメンテーションでは、コンテンツサーバ１０２又はエッジサーバ６１６は、フルビットレートのメディアストリームをトランスコーダ６０２へ送信し、トランスコーダ２６０２（６０２？）は、セル６０８に位置する電子デバイスへのメディアをトランスコードする。一実施の形態では、コンテンツサーバ１０２はエッジサーバであることが理解されるべきである。トランスコーダ６０２は、次に、メディアストリームを低ビットレートのストリームにトランスコードし、そのストリームを電子デバイス１２０へ送信する。電子デバイス１２０が別のセルに向けて移動しているという通知をトランスコーダ６０２が受信すると、トランスコーダ６０２は、その新たなセルに貢献する別のトランスコーダとのハンドオフオペレーションを開始する。このハンドオフプロセスは、図８Ａ及び図８Ｂのプロセス８００において、以下で非常に詳細に説明する。
【００４７】
一実施の形態では、ハンドオフは、サービスロケーションマネージャ３０２等の中央ノードの制御及び指示の下で達成される。別のエンティティ（たとえば、専用ハンドオフマネージャ）がこの機能を代わりに実行できることが理解される。一実施の形態では、サービスノード２０２は、メディアセッションを別のサービスノードへ転送するのに使用されるハンドオフ情報を指定する。このような一実施の形態では、ハンドオフ情報は、サービスロケーションマネージャ３０２へ転送される。サービスロケーションマネージャ３０２は、次に、メディアセッションハンドオフを受け取ることになるサービスノード（たとえば、サービスノード２０４）を選択することができ、ハンドオフ情報をそのサービスノードへ転送することができる。別の実施の形態では、サービスロケーションマネージャ３０２は、メディアセッションハンドオフを受け取ることになるサービスノードを特定することができ、そのサービスノードへハンドオフ情報を直接通信するようにサービスノード２０２に指示することができる。
【００４８】
図８Ａ及び図８Ｂは、本発明の一実施の形態によるデータセッションハンドオフのプロセス８００を示すフローチャートである。一実施の形態では、プロセス８００は、トランスコーダデバイス（たとえば、トランスコーダデバイス６０２又は６０４）において、メモリに記憶されてコントローラにより実行されるコンピュータ可読プログラム命令として実施される。図８Ａ及び図８Ｂには具体的なオペレーションが開示されているが、このようなオペレーションは例示である。すなわち、本発明は、他のさまざまなオペレーション、又は、図８Ａ及び図８Ｂに列挙したオペレーションの変形を実行することにも良く適している。
【００４９】
プロセス８００のオペレーション８０５では、移動デバイス（たとえば、図６の電子デバイス１２０）が、トランスコーダ（たとえば、図６のトランスコーダ６０２）と接触して、メディアファイル（たとえば、データ）を要求する。一実施の形態では、トランスコーダ６０２は、セル６０８内に位置する電子デバイスへメディアを供給するように動作することができる。一実施の形態では、移動デバイスは、最も近いトランスコーダと接触して、メディアファイルを要求する。一実施の形態では、移動デバイスは、メッセージを送信することによってトランスコーダと接触する。一実施の形態では、このメッセージは伝送制御プロトコル（ＴＣＰ）メッセージである。オペレーション８０５は、図６及び図７では、矢印６３０として図的に表されている。
【００５０】
オペレーション８１０では、トランスコーダ６０２が、データ送信元（たとえば、コンテンツサーバ１０２又はコンテンツ分配ネットワーク６１４）と接触して、メディアセッションをセットアップする。一実施の形態では、トランスコーダ６０２は、メッセージを送信することによってデータ送信元（たとえば、図６のコンテンツサーバ１０２又は図７のコンテンツ分配ネットワーク６１４）と接触する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８１０は、図６及び図７では、矢印６３２として図的に表されている。
【００５１】
オペレーション８１５では、データ送信元が、要求されたメディアをトランスコーダ６０２へストリーミングすることを開始する。一実施の形態では、要求されたメディアは、ユーザデータグラムプロトコル（ＵＤＰ）を使用して送信される。オペレーション８１５は、図６及び図７では、矢印６３４として図的に表されている。
【００５２】
オペレーション８２０では、トランスコーダ６０２が、ストリーミングメディアを電子デバイス１２０にダウントランスコードする。オペレーション８２０は、図６及び図７では、矢印６３６として図的に表されている。
【００５３】
オペレーション８２５では、電子デバイス１２０が新たな位置（たとえば、セル６１０）へ移動しているとの通知をトランスコーダ６０２が受ける。一実施の形態では、電子デバイス１２０は、新たな位置への移動をトランスコーダ６０２へ直接通信する。別の実施の形態では、その移動の通知は、電子デバイス１２０の非常に近くに位置して電子デバイス１２０の移動を監視するカメラによりトランスコーダ６０２へ通信される。別の実施の形態では、電子デバイス１２０が新たな位置へ移動することは、当該電子デバイス１２０の監視された振る舞いに基づいてコンピュータシステムにより予測される。別の実施の形態では、電子デバイス１２０が新たな位置へ移動することは、トランスコーダ６０２によって監視される電子デバイス１２０の内部に常駐した全地球測位システムに基づいて判断される。新たな位置への電子デバイス１２０の移動をどの方法によってもトランスコーダ６０２に気付かせることが可能であることが理解されるべきである。セル６０８からセル６１０への電子デバイス１２０の移動は、図６及び図７では、矢印６３６として図的に表されている。
【００５４】
オペレーション８３０では、トランスコーダ６０２が、セル６１０に非常に近いトランスコーダ（たとえば、トランスコーダ６０４）へハンドオフメッセージを送信し、電子デバイス１２０へメディアをストリーミングする準備をするようにトランスコーダ６０４に通知する。一実施の形態では、このハンドオフメッセージは、トランスコード情報（たとえば、電子デバイス１２０の表示サイズ及び帯域幅サイズ）並びにシーケンスヘッダ（たとえば、データストリームの現在のバイト位置）を含む。このシーケンスヘッダは、メディアストリームのどの部分が現在電子デバイス１２０へ送信されているかを示す。一実施の形態では、トランスコーダ６０２は、メッセージを送信することによってトランスコーダ６０４に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８３０は、図６及び図７では、矢印６３８として図的に表されている。
【００５５】
オペレーション８３５では、トランスコーダ６０４が、データ送信元と接触して、メディアセッションをセットアップする。一実施の形態では、このメディアセッションは、オペレーション８３０で受信されたシーケンスヘッダに基づいて要求される。シーケンスヘッダに示されたビット位置においてメディアセッションを開始することにより、電子デバイス１２０は、トランスコーダの切り換え中であってもシームレスなメディアセッションを受信する。一実施の形態では、トランスコーダ６０４は、メッセージを送信することによってデータ送信元に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８３５は、図６及び図７では、矢印６４０として図的に表されている。
【００５６】
オペレーション８４０では、データ送信元が、要求されたメディアをトランスコーダ６０４へストリーミングすることを開始する。一実施の形態では、上記で列挙したように、メディアセッションは、シーケンスヘッダに示されたビット位置を起点として、電子デバイス１２０にトランスコードされ、電子デバイス１２０にシームレスなメディアセッションを提供する。一実施の形態では、要求されたメディアは、ＵＤＰを使用して送信される。オペレーション８４０は、図６及び図７では、矢印６４２として図的に表されている。
【００５７】
オペレーション８４５では、トランスコーダ６０４が電子デバイス１２０と通信する準備ができていること、及び、トランスコーダ６０２が電子デバイス１２０との通信を遮断できることを、トランスコーダ６０４がトランスコーダ６０２に通知する。一実施の形態では、トランスコーダ６０４は、メッセージを送信することによってトランスコーダ６０２に通知する。一実施の形態では、このメッセージはＴＣＰメッセージである。オペレーション８４５は、図６及び図７では、矢印６４４として図的に表されている。
【００５８】
オペレーション８５０では、トランスコーダ６０４が、ストリーミングメディアを電子デバイス１２０にダウントランスコードする。上述したように、ストリーミングメディアは、オペレーション８３０で受信されたシーケンスヘッダに示された位置でトランスコードを開始して、シームレスな形式で電子デバイス１２０に提示される。オペレーション８５０は、図６及び図７では、矢印６４８として図的に表されている。
【００５９】
オペレーション８５５では、トランスコーダ６０２が、電子デバイス１２０へのメディアのトランスコードを停止する。
【００６０】
関連した作業
デガス（Degas）システムは、ユーザが定義したメディア処理を、プログラマブルメディアゲートウェイを使用して可能にするものである［９］。ディグレット（deglet）と呼ばれるプログラムを、宣言型プログラミングモデルを使用してゲートウェイにアップロードすることができる。デガスシステムは、メディアゲートウェイと相互作用するための特別なクライアントを含む。他方、本明細書で説明したＳＬＭシステムは、３ＧＰＰに準拠したクライアントには完全にトランスペアレントとすることができる。デガスシステムは、ネットワーク帯域幅の利用に関して最適にゲートウェイを配置しようと試み、必要に応じて、処理タスクを動的に移動させることができる。しかしながら、資源管理は実施されなかった。このシステムは、マルチメディアソフトウェアライブラリを使用して、メディアゲートウェイのコードを最適化する。
【００６１】
コンテンツサービスネットワーク（ＣＳＮ（content service network））が［７］で提案された。キーフレームの抽出を有するビデオセグメンテーションが、サンプルの基盤サービスとして使用された。本発明者等のアーキテクチャと同様に、ＣＳＮは、既存のＣＤＮを利用して、基盤サービスとして計算（たとえば、処理）を追加する。サービス分散／管理（ＳＤＭ（Service Distribution and Management））サーバが、ネットワークのサービス、並びに、サーバ負荷及びクライアントの人口統計の履歴に関する情報を保持するのに使用される。リダイレクトサーバが、処理要求をアプリケーションプロキシサーバへ送信するためにネットワークエッジに配置される。提案されたＣＳＮは、ＤＮＳリダイレクトを使用して、最も近いアプリケーションプロキシへ要求を送信する。本発明者等のアーキテクチャでは、この機能は、動的なＳＭＩＬの書き換えによってアプリケーションレベルで完全に実行される。これによって、ＤＮＳリダイレクト能力の必要性は基盤から取り除かれる。
【００６２】
ＣＳＮとＳＬＭ／ＭＳＡとの相違
＊ＣＳＮは、独立したオーバーレイ基盤を必要とし、サービス割り当てプロセス用に追加のＤＮＳリダイレクトを必要とする。ＳＬＭは、既存のコンテンツ配信構造に埋め込まれ、サービス要求の転送は、動的なＳＭＩＬの書き換えによってアプリケーションレベルで完全に実行される。
＊ＣＳＮは、加入モデル（subscription model）を使用し、エンドユーザ又はコンテンツプロバイダのいずれかが特定のサービスに加入する。ＳＬＭは、どのパーティからも加入を必要としない。
＊ＣＳＮでは、サービスセッションがサービスノードに一旦割り当てられると、そのノードは、ノードが障害を受けない限り、そのセッションを完了する。ＳＬＭは、サービスセッションの最中に異なるノードに動的に切り換わることができる。
＊ＣＳＮは、結果を供給できるようになる前にサービスが完了されていることを必要とするＯＰＥＳを使用する。ＳＬＭは、ストリーミングされるメディアサービスを可能にする。すなわち、メディアサービスの結果は、サービスセッションが進行中の時に並列に供給することができる。
＊ＣＳＮは、動的なサービス配置／セッション割り当てを有するサービス管理を実施する方法を開示しない。一方、これは、ＳＬＭに関しては本明細書で説明される。
＊ＣＳＮは、ＡＰ（別名、サービスノード）の「監視」がどのように行われるかを示さず、そういうことから、監視がスケーラブルであるのかどうかも、監視がノードの障害を自動的に検出するのかどうかも示されない。ＳＬＭは、本明細書で説明するようなプッシュベース又はプルベースの監視を利用することができる。
＊受信された監視統計値（それらの統計値がどのように受信されようとも）は、ＳＬＭにより近時のディスパッチを反映するように変更される。ＣＳＮはこれを教示していない。
【００６３】
要約すれば、移動デバイスは、あちらこちらに移動し、バックグラウンドタスクの開始及び停止を行い、自身のプロセッサパラメータ及びディスプレイパラメータを、さまざまな電力管理ストラテジーを考慮に入れるように調整することから、これらのメディアサービスは、移動デバイスによって提示される、高速に拡大し、且つ、非常に動的な、ディスプレイ、プロセッサ、及び帯域幅の１組の制限をサポートするのに望ましい。概説したＳＬＭソリューションは、ＣＰＵに集中したメディア処理タスクの負荷をネットワークの複数のサービスノードにわたってバランスさせる問題に有効に対処することができる。クライアントが既知のポータルサイトにアクセスする時、サービスロケーションマネージャ３０２は、要求を、最小負荷のサービスノードに動的にルーティングする。さらに、トランスコードされたストリームは、３ＧＰＰに準拠したクライアントにトランスペアレントな方法で、ネットワークの適切なサービスノードから提供される。
【００６４】
このアーキテクチャは、［６、１１］で概説されているように、移動クライアントのメディアサービスセッションのアプリケーションレベルのハンドオフをトリガするように拡張することができる。ＳＬＭアーキテクチャは、新たなクライアントの位置の近くにあるメディアサービスノードを判断するのによく適している。セッション中のハンドオフを実行する能力によって、前述したものよりもはるかにきめの細かな粒度の負荷バランシングが可能になる。
【００６５】
［コンポーネント化されたネットワークベースのメディアサービスの例示のアーキテクチャ］
本発明の一実施の形態によるメディアサービスアーキテクチャ（ＭＳＡ（Media Service Architecture））は、ストリーミング音響及びストリーミングビデオがネットワークを通ってフローする際に、当該ストリーミング音響及びストリーミングビデオに対して動作するサービスの要求、構成、及び実行を行うための柔軟で一般的なアーキテクチャを提供することができる。ＭＳＡは、要求されたメディアサービスをモジュール形式の処理コンポーネントに分解する。これらのモジュール形式の処理コンポーネントは、ネットワーク全体にわたってサーバに分散させることができ、且つ、（たとえば、標準的なストリーミングプロトコルを介して）相互通信することができるものである。標準的なプロトコルを使用することによって、ＭＳＡとメディアコンテンツ配信ネットワークとの間のシームレスな相互運用性も与えられる。ＭＳＡは、利用可能な計算資源及びネットワーク資源を効率的に使用する方法で、ネットワーク接続されたサーバの監視、及び、ネットワーク接続されたサーバへのサービスコンポーネントの割り当てを行うことによって、メディアサービスを管理する。サービスのコンポーネント化及びネットワーク配信によって、新たなサービス及び改良されたサービスの高速な開発が可能になり、幅広いサービス可用性及びデバイス互換性が増進される一方、エンドユーザに対するシステムメンテナンスの負担が大幅に削減されることに留意されたい。
【００６６】
一実施の形態内では、ＭＳＡは、複雑なメディアサービスを、柔軟に構成されたネットワークベースのパーツに分解することによって、コンポーネント化されたウェブベースのサービスをストリーミングリッチメディアの領域に拡張する。この手法によって、新しい強力なアプリケーションの高速な開発及び簡単なメンテナンスが可能になり、多数のユーザへのスケーラビリティが増進される。このすべてが、メディアサービスクライアントの立場からの使いやすさを犠牲にすることなく達成される。
【００６７】
ネットワークベースのメディアサービス
スタンドアロンシステムで音響、ビデオ、及び他のメディアに対して実行される多くのタイプの解析を、ネットワーク接続処理アーキテクチャに統合することができる。たとえば、発話認識、顔検出及び顔認識、並びに音響雑音除去は、ローカルなデスクトップを離れて、利用可能な帯域幅及び処理能力を有するネットワーク接続されたサーバマシンへ簡単に移動させることができる。これに加えて、ＭＳＡは、実用的で新しい利用可能な高い価値のサービスを作り出す。このサービスには以下のものが含まれる。
【００６８】
ビデオ合成：複数の送信元からのコンテンツを有する単一のビデオストリームを生成するためのマスクに従って、２つ又は３つ以上のビデオストリームを画像ごとにブレンドすることができる。多くのアプリケーションの中には、「ピクチャインピクチャ」特殊効果及び「ブルースクリーニング」特殊効果がある。ビデオトランスコードは、入力ストリームの一致しないフォーマット、解像度、及びフレームレートを打開するのに望ましい場合がある。
【００６９】
会議の要約及び転写（transcription）：カメラ及びマイクが会議に存在する場合、入力する音響ストリーム及びビデオストリームをネットワークで収集でき、ビデオ及び音響のセグメンテーション並びに音声及び顔の認識を用いて処理して、インデックスされた会議記録を生成することができる。これに加えて、自動発話認識（ＡＳＲ）、キーワードスポッティング、及び文書要旨抽出（document gisting）を使用して、インデックスされ、注釈を付けられ、且つ、部分的に転写された、会議記録を生成することができる。これらのタイプの記録は、後に会議コンテンツを素早く思い起こすのに使用することができる。
【００７０】
マルチ音源音響強化：いくつかのマイク使用可能携帯情報端末（ＰＤＡ）又は他の電子記録デバイスを用いた会議等において、複数の音響ストリームが、単一の部屋で異なるマイクから取り込まれている時、ブラインド音源分離をこの特別なマイク配列に適用して、異なる参加者からの発話を分離して雑音除去することができる。
【００７１】
動的なビュー選択：ウェブキャストされるライブ遠隔会議講演の用途では、多くの場合、十分なカバレッジを得るために複数のカメラが望ましい。最良のカメラビューは、通常、そのイベント中に何度も変わる。イベントからのビデオストリーム及び音響ストリームの解析をネットワークベースのサービスが使用して、最良のビデオフィードを自動的に選択することができる。
【００７２】
これらのタイプのメディア解析は、今日、ローカルなデスクトップ処理を通じて利用可能である。しかしながら、ネットワーク内でメディアストリームに対して動作する、コンポーネント化されたサービスは、従来のデスクトップモデルを上回る多くの利点を提供する。この利点には以下のものが含まれる。
【００７３】
アプリケーション提供の改善：開発者は、ＭＳＡを単に更新するだけで、改良されたサービスを素早く分配することができる。新たなサービスは、コンポーネントの混合及び整合を行うことによって素早く作成される。単にユーザがアプリケーションをインストールすることができる自身のマシンにアクセスできる時だけでなく、ユーザがネットワークに到達できる時はいつでも、アプリケーションが利用可能である。
【００７４】
システム管理運営の削減：処理はネットワークで実行されるので、エンドユーザは、自身のマシンに対する継続的なインストール及び更新の面倒について気にする必要がない。
【００７５】
マルチストリーム処理の円滑化：会議要約等の多くのメディアベースのアプリケーションは、結合処理のために収集される複数のストリームを含む。これらのストリームが、同じマシンから発生したものでない場合、通例、ネットワーク内でそれらのストリームを処理した方がはるかに効率的である。
【００７６】
計算環境の制御：個々のユーザのマシンは、それらマシンの計算能力、メモリ容量、及びオペレーティングシステムの点で広く変化する場合があるが、ＭＳＡマシンは、狭い範囲の規格値に標準化することができる。サービスコンポーネントは、これらの規格値について開発及び最適化することができ、より信頼性のある全体的なアプリケーション性能がもたらされる。
【００７７】
結果の効率的な共有：会議要約の状況等の多くの状況では、複数のユーザが望む処理されたメディア及び解析結果は、ほとんど同じであるか、又は、同一である。ネットワーク内処理は、各ユーザのマシン上でこの処理を複製するのではなく、重複計算を１回実行し、次いで、それらの結果を各ユーザに分配することができる。簡単に言えば、ネットワークベースのメディア処理サービスは、メンテナンスの削減及び信頼性の問題について、現在のローカルなメディア中心のアプリケーションよりもはるかに大きな柔軟性及び機能性の可能性をユーザに提供する。
【００７８】
［メディアサービスアーキテクチャ（ＭＳＡ）］
ＭＳＡの実施の形態について、メディア配信アーキテクチャと統合すること、及び、非常に柔軟な方法でメディアサービスを可能にすることに焦点を当てる。ＭＳＡのいくつかの特徴は、以下のものを含むことができる。
相互運用性：オープンインターフェース及びオープン標準規格を使用したコンポーネント間のシームレスなストリーミングの相互接続、
モジュール性：ネットワーク内で動的なメディアサービスの構築を可能にするモジュール形式のサービスコンポーネント、並びに
管理可能性：スケーラブルな方法での計算資源及び記憶資源へのメディアサービスの効率的な割り当て。
アーキテクチャがこれらの特徴のそれぞれを提供できる手段を以下に説明する。
【００７９】
ストリーミングの相互運用性のためのシームレスな相互接続
ＭＳＡ内、並びに、ＭＳＡの要素間及びメディアコンテンツ配信ネットワーク（ＣＤＮ）のコンポーネント間におけるメディアストリームのマシン間のすべてのトランスポートは、「Ｅａｒ」と呼ぶことができる均一な入力モジュール及び出力モジュールを介して行うことができる。一実施の形態内では、Ｅａｒは、標準規格ベースのメディアストリーミングプロトコルに依拠し、それによって、ＭＳＡとＣＤＮ及び他のストリーミングメディアアプリケーションとの統合を容易にする。入力Ｅａｒ及び出力Ｅａｒは、共に、マルチメディアを記述するためのＳＤＰプロトコル、セッション管理及びメディア再生制御のためのリアルタイムストリーミングプロトコル（ＲＴＳＰ）、並びに、リアルタイムの制約の下でのデータのトランスポートのためのリアルタイムプロトコル／リアルタイム制御プロトコル（ＲＴＰ／ＲＴＣＰ）を介して、他のネットワーク接続されたマシンと通信することができる。ただし、プロトコルはこれらのものに限定されるものではない。所与のＥａｒは、単一のメディアストリームのフローの一方の端部（送信又は受信）を管理することができるが、同じ同期したストリーミングセッションに複数のＥａｒをリンクすることができる。
【００８０】
また、ネットワーク送信に多く使用される圧縮フォーマットと、メディア処理及び解析技法によって多く要求される非圧縮フォーマットとの間で、このアーキテクチャを通ってフローするマルチメディアを相互変換できるように、Ｅａｒは、データの圧縮機能及び伸張機能も提供することができる。入力Ｅａｒは、入力するメディアストリームのフォーマットを自動的に検出でき、適切な伸張モジュールを募集して、そのデータをメディア解析に適切な形式に変換することができる。出力Ｅａｒは、生のデータストリームを、ネットワークトランスポートに適した圧縮フォーマットに変換することができる。サポートされた標準圧縮方式には、動画エキスパートグループ（ＭＰＥＧ）であるＭＰＥＧ−１、ＭＰＥＧ−２、及びＭＰＥＧ−４のビデオ、並びに、オーディオ／モデムライザ（ＡＭＲ）及びＷＡＶの音響が含まれ得るが、これらに限定されるものではない。適切な圧縮モジュール及び伸張モジュールを登録することによって新たなフォーマットを追加できることに留意されたい。
【００８１】
最後に、メディア処理技法は、ストリーミングメディアと同じレートで動作できない場合があるので、Ｅａｒは、データバッファリング方法及びフロー制御方法を実施して、データレートの不一致を取り除くことができる。循環バッファリングによって、高価なデータコピーが最小にされ、マルチスレッド化によって、ネットワーク、アプリケーション、並びに伸張ルーチン及び圧縮ルーチンからのデータ要求に効率的にサービスが提供される。バッファオーバーフローは、フレームを廃棄するための選択可能なポリシーによってハンドリングすることができる。
【００８２】
柔軟なモジュール形式のサービス分解
ＭＳＡサービスは、サービスポータルと接触することによって、簡単な高レベルメディアサービス要求から開始することができる。これらの要求は、ユーザデバイスがインターネット等のネットワークを介して直接行うこともできるし、ローカル又はＭＳＡ内のいずれかでユーザデバイスによって実行されるアプリケーションが生成することもできる。各要求は、送信元及び宛先のユニフォームリソースロケータ（ＵＲＬ）等のあらゆるサービスパラメータと共に、「ビデオ合成」等のサービス名を含むことができる。
【００８３】
これらの簡単なメディアサービス要求は、要求側クライアントからのほとんどのメディアサービスの複雑さを隠蔽する。たとえば、会議要約は、発話認識、顔検出、ビデオ動き解析、及び音声識別を使用することができ、次に、これらのコンポーネント技法のそれぞれは、いくつかのサブコンポーネントに分割することができる。他方、所与の処理技法は、多くの異なるサービスにおける有用なコンポーネントとすることができる。これらの理由から、メディア処理技法を、柔軟で動的に組み合わせられる、モジュール形式の再利用可能なコンポーネントにカプセル化することが望ましい。
【００８４】
したがって、各メディアサービスは、データストリームを通じて通信する独立した「コンポーネント」のグラフとして構造化される。各コンポーネントは、互いにしっかりと動作する１つ又は複数の「サブコンポーネント」処理技法をカプセル化することができる。１つのメディアサービスのコンポーネントは、単一のマシンに動的に配置することもできるし、ネットワークにわたって動的に分散することもできる。コンポーネントは、適切にカプセル化されるので、各コンポーネントは、この分散を気にすることなく動作することができる。
【００８５】
図１０は、ＭＳＡが本発明の一実施の形態に従ってサービスを分解して分散させる例示のオペレーションを示すブロック図である。サービスポータル１００６は、ユーザデバイス１００２によって発行されたメディアサービス要求１００４を受信した後、その要求の遂行を管理するためのサービスビルダ１００８を起動して実行する。指名された各メディアサービスを異なるサービスビルダ（たとえば、１００８）に関連付けることができ、各サービスビルダは、そのサービスを実施するコンポーネント（たとえば、１００１）の抽象グラフの構造を知っていることに留意されたい。このグラフの各コンポーネントについて、サービスビルダ１００８は、コンポーネント配置要求１０１０を「サービスロケーションマネージャ」（ＳＬＭ）１０１２へ送信して、本明細書で説明したように、１つ又は複数のコンポーネントを実行するための、ネットワーク接続されたサービス提供可能マシン（たとえば、１０２２、１０２４、又は１０２６）を決定する。ＳＬＭ１０１２は、コンポーネント配置決定１０１４をサービスビルダ１００８へ返信する。このコンポーネント配置決定１０１４は、各コンポーネントの各入力ストリーム及び各出力ストリームの具体的なＵＲＬ（ポート番号を有する）を含むことができる。サービスビルダ１００８は、選択されたサービス提供可能マシン（たとえば、１０２２）によるこれらの決定をグループ化し、次いで、選択された各マシンへ１つの構築要求１０１６をネットワーク（たとえば、インターネット１０２８）を介して送信する。この構築要求１０１６は、所望のコンポーネント１２０並びにそれらコンポーネントの入力ＵＲＬ及び出力ＵＲＬを列記している。
【００８６】
［ローカルビルダ］
「ローカルビルダ」（たとえば、１０１８）は、各ＭＳＡマシン（たとえば、１０２２、１０２４、及び１０２６）で実行され、構築要求１０１６にサービスを提供する。所与の要求１０１６について、ローカルビルダ１０１８は、指名されたコンポーネントのそれぞれを作成することができ、入力ＵＲＬ及び出力ＵＲＬを使用して、Ｅａｒ１０３０及び１０３２をインスタンス化し、これらのコンポーネント及び他のマシンのコンポーネント（たとえば、１０２２及び１０２６）の間でデータを送受信する。このようにして、ローカルビルダ１０１８は、サービスコンポーネントを結び付ける。また、ローカルビルダ１０１８は、２つ以上のコンポーネントによって行われる同一のサブコンポーネントの処理を取り除くことによって、単一のマシン（たとえば、１０２４）で実行される、相互通信するコンポーネントの各集合の最適化も試みる。このような重複は、時に、サービスが合理的なサイズの再利用可能なコンポーネントに分割された場合に起こる。サービスのモジュール性のこのコストは、このように、ローカルビルダの最適化によって軽減される。ローカルビルダは、冗長なサブコンポーネントの処理を取り除いた後、サービス処理を遂行するために、１つにまとめられたコンポーネントの入力ストリーム及び出力ストリームを必要に応じてリダイレクトする。
【００８７】
図１０内において、すべての構築要求１０１６が遂行された後、サービスを実行する準備ができる。データの宛先に最も近い、サービスグラフにおけるコンポーネントが、ＲＴＳＰのＰＬＡＹコマンドを介してメディアを要求し、それによって、接続されたコンポーネントのグラフ全体を通じてデータをプルする。ただし、コマンドは、ＲＴＳＰのＰＬＡＹコマンドに限定されるものではない。したがって、所望のメディアは、１つ又は複数の送信元（たとえば、コンテンツサーバ１０３３並びにライブカメラ１０３５及び１０３７）からフローし、選択されたサービスコンポーネントは、そのストリーミングメディアに対して動作し、最終的には、処理されたメディアを宛先（たとえば、出力ディスプレイ１００３）へ配信する。矢印１０３２と同様に見える、図１０内の矢印は、ストリーミングメディア／データを表していることに留意されたい。
【００８８】
動的なサービスロケーション管理−コンポーネント（複数可）配置
ＭＳＡネットワークの多くの個々のマシンは、メディアサービスについて基礎を成す処理を実行することができる。したがって、各メディアサービス要求（たとえば、１００４）について、要求を最も良く遂行するためにＭＳＡ資源をどのように割り当てるかについての決定を行うことができる。ネットワークの負荷を過度に増加させることを回避するために、これらの決定は、さまざまなサービス提供可能マシン（たとえば、１０２２、１０２４、及び／又は１０２６）の、メディアストリームの送信元と宛先との間の良好なパスに対する（ネットワーク）近接性に部分的に基づくことができる。また、サービスの遅延を最小にし、且つ、サービスの品質を最高にするために、これらの決定は、各ＭＳＡメディアプロセッサが保持する現在の処理負荷を考慮することもできる。最後に、サービスのいくつかのコンポーネントがサブコンポーネントの処理を共有する場合、それらのコンポーネントを同じサービス提供可能マシン（たとえば、１０２２、１０２４、又は１０２６）上にグループ化することが好ましい場合がある。
【００８９】
これらの決定を知的に行う一方法は、［１７］で説明されるような「サービスロケーション管理」を利用することである。ＭＳＡは、サービスロケーションマネージャ（ＳＬＭ）、たとえば１０１２を含む。このＳＬＭは、サービスを含む個々のコンポーネントを配置する場所を判断するものである。所与のメディアサービス要求（たとえば、１００４）について、ＳＬＭ（たとえば、１０１２）は、後述する複数の因子を考慮して、関連したサービスビルダ（たとえば、１００８）により定義された順序で、一時に１つずつサービスのコンポーネントを配置する。コンポーネントの配置決定は、代替的に、すべての因子及びすべてのコンポーネントにわたる同時最適化を通じて同時に行うこともできる。ただし、これは、適度に高度なサービスについても、複雑で多くの時間を要する手続きとなる可能性がある。また、異なるコンポーネントの配置決定は、代替的に、完全に独立して行うこともできる。ただし、これは、データパスが非効率的になり、サブコンポーネントの処理が重複する可能性がある。ＳＬＭ（たとえば、１０１２）は、そのようにしないで、近時のコンポーネント配置決定のテーブルを保持することもでき、新たな各決定の基礎を部分的にこの履歴に置くこともできる。
【００９０】
たとえば、サービスの抽象グラフにおいて互いに結び付けられたコンポーネントを、同じサービス提供可能マシン（たとえば、１０２２）、又は、高帯域幅及び／若しくは少ない待ち時間の相互接続を有するマシンに優先的に配置できるように、各コンポーネント配置決定を、同じサービス要求の他のコンポーネントについての前の決定に部分的に基づくものとすることができる。コンポーネントのグラフ全体にわたる同時配置最適化（joint placement optimization）は、おそらく高価なプロセスとなり、完全に独立した配置決定は、データパスがあまりにも複雑になるおそれがあり、重複した計算を取り除くことができないおそれがあるが、このようなコンポーネント配置決定の基礎を前の決定履歴に置くことは、コンポーネントのグラフ全体にわたる同時配置最適化と、完全に独立した配置決定との間の折衷案である。したがって、ＳＬＭ（たとえば、１０１２）は、前の配置決定に基づいて配置を最適化することは可能であるが、コンポーネントの全グラフにわたって割り当てを最適化するように試みることはできない。代替的に、ＳＬＭ（たとえば、１０１２）は、前の配置決定に基づいて配置を最適化することが可能であり、且つ、コンポーネントの全グラフにわたって割り当てを最適化するように試みることができることにも留意されたい。
【００９１】
図１１は、本実施の形態の一実施の形態によるサービスロケーション管理方法論のブロック図である。サービスビルダ１００８によってＳＬＭ１０１２へ送信された各コンポーネント配置要求１０１０について、ＳＬＭ１０１２は、まず、ネットワークの区域及び前のコンポーネント配置決定に基づいて、可能性のあるホストマシン（たとえば、１０２２、１０２４、及び／又は１０２６）のプールを選択することができる。そのネットワークの区域にアクセスするために、ＳＬＭ１０１２は、サーバマシン（たとえば、１０２２、１０２４、及び１０２６）間のネットワーク「距離」のテーブル１１０２を調べて、どのマシンがサービスデータの送信元及び宛先、又は、それらの間のパス（複数可）に近いかを判断することができる。テーブルの距離は、測定されたネットワーク遅延及び帯域幅によって求めることができることに留意されたい。ＳＬＭ１０１２は、そのサービスの他のコンポーネントが前に配置されたことがあるマシンを、現在のコンポーネントの配置についてより優先させることができ、特に、前に配置されたそれらのコンポーネントが、現在のコンポーネントに直接結び付けられることになるか、又は、現在のコンポーネントとサブコンポーネントの処理を共有する可能性があることを示されている場合には、優先させることができる。この情報のすべては、可能性のある各ホスト（たとえば、１０２２、１０２４、又は１０２６）の「マシン配置コスト」の計算に組み合わせることができる。
【００９２】
また、ＳＬＭ１０１２は、前のコンポーネント配置決定を見直して、同時コンポーネント配置を通じて可能性のある計算節減を見つけることもできる。一実施の形態内では、各タイプのコンポーネントは、自身が含む指名された「サブコンポーネント」技法のリストに関連付けられている。たとえば、「発話認識」コンポーネントは、（音響）ケプストラム特徴量（cepstral feature）を計算することができ、ＨＭＭを使用して、それらの特徴量を解析することができる。前に配置されたコンポーネント内に同じケプストラムサブコンポーネント（cepstral sub-component）を有するマシンがある場合、そのマシンを現在の決定プロセスで優先させることができる。この情報は、ネットワークの区域評価と組み合わせて、「マシン配置コスト」１１０６を生成することができ、最小コストを有するマシンは、現在のコンポーネントについて可能性のあるホストマシンのプールを形成する。これらのコストは、次に、各マシンにおける資源可用性に従って調整することができる。
【００９３】
図１１内において、コンポーネントの必要とする計算資源及びメモリ資源は、メディアの解像度やフレームレート等のサービスパラメータを、そのタイプのコンポーネントに関連付けられた資源要件ルーチン１１０８に供給することによって、ＳＬＭ１０１２により判断される。可能性のあるホストにおける資源可用性は、それらのマシン（１０２２、１０２４及び１０２６）に常駐するローカル資源マネージャ（ＬＲＭ（Local Resource Manager））（たとえば、１１１０、１１１２、及び１１１４）に資源照会１１１６を送信することによるＬＲＭの診断を通じて、ＳＬＭ１０１２が判断することができる。各ＬＲＭ（たとえば、１１１０、１１１２、又は１１１４）は、自身のオペレーティングシステムに直接問い合わせることによってそのマシンの状態を監視できることに留意されたい。また、ＬＲＭは、サービスロケーションスーパーバイザ（ＳＬＳ）と呼ぶこともできることにも留意されたい。また、マシンのローカルビルダ（たとえば、１０１８）からの、保留中で且つ近時に遂行された要求は、現在のプロセッサの負荷統計値にまだ反映されていない場合があるので、ＬＲＭは、これらの要求を追跡（図示せず）することもできる。各ＬＲＭ（たとえば、１１１０、１１１２、又は１１１４）は、次に、コンポーネントがそこに配置された場合に、当該コンポーネントによる使用に予約されたネットワークポート番号と共に、マシン資源ステータスをＳＬＭ１０１２へ返信することができる。ＳＬＭ１０１２は、マシンの資源可用性に反比例して、すべてのマシン配置コスト１１０６をインクリメントすることができる。したがって、ＳＬＭ１０１２は、可能性のある各ホスト（たとえば、１０２２、１０２４、又は１０２６）の最終的なマシン配置コスト１１０６を計算することができる。
【００９４】
最小マシン配置コストを有するマシンは、コンポーネントホストとして選択することができる。このホストを指定し、且つ、コンポーネントの入力ＵＲＬ及び出力ＵＲＬ並びに予約ポートを含むコンポーネント配置決定１０１４を、ＳＬＭ１０１２がサービスビルダ１００８へ返信することができる。また、ＳＬＭ１０１２の近時の配置決定１１０４のテーブルを更新して、この情報を反映させることもできる。
【００９５】
図１０及び図１１内において、ＳＬＭ１０１２は、サービス提供可能マシンの負荷、ネットワーク負荷及び／又は帯域幅、クライアントの位置、既存のメディア／データサービスストリーミングセッション、クライアント要求の集約等に基づいてコンポーネントを配置する場所を決定することができる。このように、ＳＬＭ１０１２は、複数のメディア／データサービスストリーミングセッションを管理することができる。
【００９６】
例示のサービスのインプリメンテーション
さまざまなサービスを構築できるコンポーネントと共にＭＳＡのプロトタイプが実施されていることに留意されたい。ＭＳＡの実施の形態のオペレーション及び利点をより良く示すために、ビデオメディアに対して動作する以下の３つのコンポーネントによりサポートされたサービスについて説明する。
サイズ変更：ビデオの幅及び／又は高さを変更する；たとえば、高解像度ビデオは、より良好な送信及びＰＤＡでの表示のためにダウンサンプリングすることができる。
背景除去：シーンにおいて、人々等の動的な又は「興味のある」オブジェクトを抽出する一方、壁や家具等、シーンの他の変化しない光景を抑制する。背景除去コンポーネントの一実施の形態は、［１８］の技法に基づくものとすることができる。この技法は、シーンの背景を一定の色（白等）に取り替えるように試みる一方、前景を変更せずそのままにする。
合成：ローカルテレビ（ＴＶ）の天気予報によって使用される「ブルースクリーニング」技法のように、マスクを使用して、ビデオストリームのピクセルを、別の画像又はビデオストリームからのピクセルと取り替える。合成コンポーネントは、特別な色（白等）を有するビデオストリームのピクセルを、別の画像又はストリームからのピクセルと取り替えることができる一方、前景を変更せずそのままにする。
【００９７】
これらの３つのコンポーネントから複数の有用なサービスを構築することができる。
【００９８】
ＰＤＡや移動電話等の移動クライアントに適した低解像度にビデオをトランスコードすることは、現代のＣＤＮ設計［１９、２０］にとって望ましく、サイズ変更コンポーネントを介して達成することができる。
【００９９】
長期間にわたってシーンの外観の明示的なモデル化を行うことにより、背景除去コンポーネントは、そのシーンの興味のあるオブジェクトをより多くのビットを使用して符号化できるように、それらオブジェクトをセグメントにすることができる。静止カメラの場合、背景は、ビデオの開始時近くに１度送信し、背景が大きく変化するたび再び送信する必要があるだけである。これは、標準的な圧縮を上回るかなりの利得を達成することができる。標準的な圧縮は、背景が、移動する前景のオブジェクトによって現れるたびに、背景を「新しい」ものとして再送することになる。したがって、この背景除去コンポーネントをオプションとしてサイズ変更と併せて使用することにより、ユーザによって要求される極めて低い目標レベルにビットレートを低減することができる。
【０１００】
ここでの説明は、上記コンポーネントの３つすべてを使用する「移動プライベートビデオ電話」（ＭＰＶＰ（Mobile Private Video Phone））サービスに焦点を当てる。このＭＰＶＰによって、ビデオ遠隔会議の参加者は、合成を使用して自身の背景を自身が選んだ画像又はビデオと取り替えることにより、他の参加者に自身の環境の詳細を見えないようにすることが可能になることに留意されたい。たとえば、ビーチから電話をかけている人は、自身のオフィスの背景画像を使用することを好む場合がある。ユーザが移動デバイスにおいてビデオを受信する場合、ビットレート削減のために、（サイズ変更を介した）ダウンサンプリングも使用することができる。
【０１０１】
ＭＰＶＰサービスは、インターネットプロトコル（ＩＰ）電話通信アプリケーション内で開始することができる。このＩＰ電話通信アプリケーションは、遠隔の参加者に対して音響チャネルをすでに開いており、現在、ビデオの追加を望んでいる。このアプリケーションは、「ＭＰＶＰ」サービスの要求を、宛先ＩＰアドレスや所望のビデオ解像度等のパラメータと共に、ＭＳＡサービスポータル（たとえば、１００６）へ送信することができる。このポータル１００６は、次に、ＭＰＶＰサービスビルダ（たとえば、１００８）を開始することができる。このＭＰＶＰサービスビルダは、図１２ａに示す抽象グラフ等のサービスの抽象グラフを知っている。図１２ａは、本発明の実施の形態によるサービスのコンポーネントの例示の抽象グラフ１２００であることに留意されたい。具体的には、抽象グラフ１２００は、最終的にビデオをビデオの宛先１２１０へ配信する前に、ビデオ送信元１２０２からのビデオがサイズ変更コンポーネント１２０４へ送信され、サイズ変更コンポーネント１２０４が自身の出力を背景除去１２０６へ送信し、次に、背景除去１２０６が合成１２０８にフィードされることから成る。
【０１０２】
サービスビルダ（たとえば、１００８）は、３つのコンポーネントが抽象グラフ１２００に現れる順序で、それら３つのコンポーネントのそれぞれについてのコンポーネント配置要求（たとえば、１０１０）をＳＬＭ（たとえば、１０１２）へ送信することができる。例示として、図１０及び図１１のＳＬＭ１０１２がコンポーネントを配置できるサービス提供可能マシン１０２２、１０２４、及び１０２６をネットワーク１２１２が含むということが、図１２ｂ〜図１２ｄに与えられている。また、ＳＬＭ１０１２は、コンポーネントの２つ又は３つ以上が同じマシン（たとえば、１０２６）に配置される場合に、どれだけの量の計算を削減できるかも知ることができる。ＳＬＭ１０１２は、コンポーネントをどのように分散するかについての決定に達するために、可能性のある計算節減、各マシンの現在の計算負荷レベル、各コンポーネントの処理要件、並びにネットワークトポロジー及びネットワーク負荷レベルを考慮することができる。ネットワーク１２１２におけるコンポーネントの３つの例示の分散が、図１２ｂ〜図１２ｄに示されている。
【０１０３】
図１２ｂ〜図１２ｄ内において、サーバ１０２２、１０２４、及び１０２６は、ビデオの送信元１２１４及び宛先１２１６と共に、それらの相対的なネットワーク距離を反映するように配置されている。画像は、各リンク上をフローするビデオ（処理されることがある）を表していることに留意されたい。処理コンポーネントを有しないマシンはメディアを単に転送するだけである。
【０１０４】
図１２ｂの第１の分散は、その長いデータパスがサービスの待ち時間を大きくすることになることから、本発明者等のＳＬＭには好まれない。このような分散は、ネットワークトポロジー及び配置履歴を考慮しないランダム選択等のより単純な配置技法によって選択される場合がある。具体的には、最終的にビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサービス提供可能マシン１０２６へ送信し、サービス提供可能マシン１０２６は自身の出力をサイズ変更１２０４及び背景除去１２０６用のサービス提供可能マシン１０２２へ送信し、次に、サービス提供可能マシン１０２２は合成１２０８用のサービス提供可能マシン１０２４にフィードされる。
【０１０５】
図１２ｃの第２の構成は、すべてのコンポーネント１２０４〜１２０８をサービス提供可能マシン１０２６に配置する。具体的には、最終的にビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサービス提供可能マシン１０２４へ送信し、サービス提供可能マシン１０２４は自身の出力をサイズ変更１２０４、背景除去１２０６、及び合成１２０８用のサービス提供可能マシン１０２６へ送信し、次に、サービス提供可能マシン１０２６はサービス提供可能マシン１０２２にフィードされる。すべてのコンポーネント１２０４〜１２０８をサービス提供可能マシン１０２６に配置することにより、これは、コンポーネント１２０４〜１２０８が個々のマシンにある場合に実行されるであろう、Ｅａｒ１０３０、１０３２、１２１８、及び１２２０によって実行される、冗長なサブコンポーネントの処理の削減を通じてだけでなく、余分なビデオ伸張ステップ及びビデオ圧縮ステップを除去することによっても、計算の節減になる。図１２ｃの構成は、このように、サービスネットワーク１２１２に取り入れられる全体の計算負荷を大幅に削減し、多くのサービスが進行中である場合のように、システム負荷レベルが高い場合に、好ましいものとすることができる。
【０１０６】
しかしながら、すべてのコンポーネントを１つのマシンに配置することの不利な点は、それらコンポーネントの組み合わせられた処理が、ビデオ送信元１２１４を起点とするストリーミングビデオのフレームレートに遅れない可能性が低くなるということである。たとえば、サイズ変更１２０４、背景除去１２０６、及び合成１２０８をすべて同じマシン（たとえば、１０２６）で３０フレーム／秒で行うことは難しい場合がある。それゆえ、いくつかのフレームを廃棄することが必要な場合があり、その結果、ビデオ品質は低下する。
【０１０７】
他方、図１２ｄに示すように、コンポーネント１２０４〜１２０８を３つの異なるマシン（たとえば、１０２２〜１０２６）にわたって拡散させることにより、３つのすべてのコンポーネント１２０４〜１２０８は、３０フレーム／秒でフレームを廃棄することなく、円滑に実行される可能性が高くなり、特に、これらのマシン１０２２〜１０２６が、比較的負荷が小さいことから選択された場合には、円滑に実行される可能性が高くなる。具体的には、ビデオをその宛先であるＰＤＡ１２１６へ配信する前に、ビデオ送信元１２１４はビデオをサイズ変更１２０４用のサービス提供可能マシン１０２４へ送信し、サービス提供可能マシン１０２４は自身の出力を背景除去１２０６用のサービス提供可能マシン１０２６へ送信し、サービス提供可能マシン１０２６は自身の出力を合成１２０８用のサービス提供可能マシン１０２２へ送信する。
【０１０８】
ＳＬＭ（たとえば、１０１２）によって行われる配置決定は、サービスビルダ（たとえば、１００８）へ返信される。サービスビルダは、それらの配置決定をマシンごとにグループ化し、構築要求（たとえば、１０１６）を、それらのマシンに常駐するローカルビルダ（たとえば、１０１８）へ送出する。ローカルビルダは、要求されたコンポーネント（たとえば、１２０４、１２０６、及び／又は１２０８）を起動し、構築要求に指定されたＵＲＬに従ってデータを送受信するようにそれらのコンポーネントに指示する。すべてのローカルビルダが、自身のコンポーネントの準備ができたことをサービスビルダに通知すると、サービスを通るメディアフローをＲＴＳＰの「ＰＬＡＹ」コマンドを介して開始することができる。図１２ｂ〜図１２ｄのマシン間のリンク上に示す画像は、実際のビデオストリームがさまざまなサービストポロジーを通ってフローする際に、そのビデオストリームに対して行われた処理の例を示していることに留意されたい。
【０１０９】
図１２ａ〜図１２ｄのこれらのサービス例は、ＭＳＡのいくつかの態様を示している。この手法は、処理されたストリームを複数のユーザデバイスへ分岐することだけでなく、数タイプのコンポーネントの処理を追加して組み込むように拡張できることが理解されよう。複数のユーザデバイスのそれぞれは、自身の分岐に沿って異なる処理をさらに要求することができる。また、この例はビデオ入力からビデオ出力を生成するが、他のサービスコンポーネントの多くは、ビデオ及び音響の解析を使用して、（たとえば、発話認識からの）テキスト又は（たとえば、ビジョンベースの人追跡及びアクティビティの解析からの）イベント要約及びタイムインデックス等の非メディアデータストリームを生成することができる。これに加えて、ＳＬＭ（たとえば、１０１２）は、サーバの計算負荷、ネットワークトポロジー及びネットワーク負荷レベル、並びに、同じサービス提供可能マシンにおけるコンポーネントの同時配置を通じて得ることができる処理削減量に応じて、複数の方法のいずれかでコンポーネントの分散を決定することができる。
【０１１０】
ビデオ及び音響の解析及び処理の多くの進歩した技法が、広く使用されたアプリケーションにまだ進出していないことに留意されたい。これは、複雑なメディア処理アプリケーションが必要とすることが多いかなりの量の処理資源を得る際、及び、これらのアプリケーションを興味のあるメディアの送信元及び望ましい出力位置に接続する際に、それらアプリケーションを構成することの難しさに部分的に起因する場合がある。ネットワーク自体に存在する柔軟なメディア処理を可能にすることによって、メディアサービスアーキテクチャの一実施の形態は、高度なメディアリッチアプリケーションを広範囲で主流として使用されるようにする潜在能力を有する。このアーキテクチャの実施の形態は、メディアＣＤＮと容易に統合され、サービスのモジュール性を可能にして再構成及び再利用を容易にし、少ないネットワーク資源の効率的な割り当てを増進する一方、エンドユーザのメンテナンス問題、互換性問題、及び可用性問題を削減する。
【０１１１】
ＭＳＡ内におけるマシン間の通信及び／又はノード間の通信は、本発明の実施の形態による多種多様な方法で実施できることに留意されたい。この通信には、サービスビルダがＳＬＭと通信すること、サービスビルダが１つ又は複数のローカルビルダと通信すること、ＬＲＭがＳＬＭと通信すること、及びＬＲＭがローカルビルダと通信することが含まれ得るが、これらに限定されるものではない。ＬＲＭとローカルビルダとの間の通信は、マシン間とはならない場合があるが、その代わり、オペレーティングシステム、ローカルファイル等を使用したマシン内又はノード内の通信とすることができる。ただし、使用するものは、オペレーティングシステム、ローカルファイル等に限定されるものではない。
【０１１２】
図１３は、本発明の一実施の形態に従って実行される、ストリーミングメディアサービスを管理するためのオペレーションのフローチャート１３００である。ストリーミングメディアサービスは、メディアストリームサービスと呼ぶこともできる。フローチャート１３００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１３００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１３に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１３００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１１３】
オペレーション１３０２では、ストリーミングメディアサービスの要求がクライアントから受信される。このストリーミングメディアサービスは、複数のコンポーネントメディアサービスを含む。
【０１１４】
オペレーション１３０４では、複数のコンポーネントメディアサービスのどのコンポーネントメディアサービスを、ネットワークの複数のサービスノードの或るサービスノードに割り当てるかについての判断が行われる。
【０１１５】
オペレーション１３０６では、複数のコンポーネントメディアサービスの或るコンポーネントメディアサービスを実行するように割り当てられた各サービスノードが、ストリーミングメディアに対してストリーミングメディアサービスを実行することを可能にするように通知を受ける。
【０１１６】
オペレーション１３０８では、割り当てられた各サービスノードの入力通信ソケット及び出力通信ソケットが生成されて、割り当てられたサービスノード間の通信が可能にされる。
【０１１７】
ＭＳＡ内における複数のストリームのハンドリング
ビデオ合成等のアプリケーションは、メディアサービスアーキテクチャ（ＭＳＡ）によって可能にされる、ネットワークベースのメディアサービスとすることができる。ビデオ合成の場合、複数のビデオストリームが、新たなビデオストリームを生成するために共に処理されなければならない。このアプリケーションは、ピクチャインピクチャ効果を提供するのに使用することができる。
【０１１８】
図１４は、本発明の一実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。ＭＳＡは、異なる入力ストリーム（たとえば、１４０８及び１４１０）からコンテンツを得ることができるリスンＥａｒ（たとえば、１４１２及び１４１４）をセットアップすることによって、この種のサービスをサポートすることができる。メディアストリーミング送信元（たとえば、１４０２及び１４０４）は、サービスロケーションマネージャ（図示せず）によって指定される。このサービスロケーションマネージャは、（たとえば）２つのビデオサービスの中間のネットワークポイント（たとえば、サービスノード１４０６）に合成サービスを配置することができる。この合成サービス１４１６は、次に、２つのストリーム（たとえば、１４０８ａ及び１４１０）を互いに同期させ、ストリーム１４０８からトランスコードされたビデオ１４０８ａを他方のストリーム１４１０にオーバーレイすることによって「ピクチャインピクチャ」オペレーションを実行することができ、次いで、その結果生成されたビデオ１４２０を出力Ｅａｒ１４１８を通じて外部にストリーミングする。この実施の形態は、複数のストリームを、メディアサービス、この場合にはビデオ合成（たとえば、１４１６）の入力側でどのように管理できるかを示している。
【０１１９】
図１５は、本発明の別の実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。具体的には、共に図示しないローカルビルダ（又はＳＬＭ）が、既存のサービスセッションの出力を、新たに作成されたサービスセッションへの入力として「タップ（tap）」することにより、ストリーミングメディアがネットワークを通ってフローする際にそのストリーミングメディアを最適化することができる。
【０１２０】
図１５のコンポーネントは、上述した図１４のコンポーネントと同様に動作していることに留意されたい。一方、図１５内では、サービスが進行中であって、別のクライアント（図示せず）が、ビデオ１４０８をトランスコードしたものを要求した場合、ＳＬＭは、メッセージを（ＳＯＡＰ／ＸＭＬを介して）合成サービス１４１６へ送信して、ビデオ１４０８をトランスコードしたものを新たなクライアントに利用可能にすることができる。
【０１２１】
複数のメディアストリームを、本発明の実施の形態による多種多様な方法でハンドリングできることに留意されたい。たとえば、ビデオストリームは、それをトランスコードし、次いで、トランスコードされたビデオを複数のクライアントへ出力するサービス提供可能マシンが受信することができる。これに加えて、ビデオストリームは第１のノードに入り、背景除去が実行される。この第１のノードは、合成サービスを実行している第２のノードへ前景を送出する。その第２のノードは、他の或る送信元から入ってくる第２のビデオストリームも有する。第２のノードは、受信した前景ビデオ及び第２のビデオストリームの合成ビデオストリームを第５のノードへ出力する。これに加えて、第１のビデオストリームの他の或る部分は、第３のノードへも送出されている。この第３のノードは、或る人の識別を行っている場合があり、そのノードでは結合コンポーネントが実行されている。第３のノードは、第４のノードによって受信される或るインデックスを生成する。この第４のノードは、第５のノードへ出力される或るテキスト生成を実行している。第５のノードは、その入力を組み合わせるサービスを実行して、ビーチにいる人の出力を生成する。この出力は、このビーチにいる人の下にその人の名前を有する。これに加えて、音響ストリームが第４のノードに入っている場合があり、この音響出力ストリームは第５のノードへ出力される。
【０１２２】
図１６は、本発明の一実施の形態に従って実行されるオペレーションのフローチャート１６００である。フローチャート１６００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１６００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１６に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１６００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１２３】
オペレーション１６０２では、クライアントからのサービス要求及びパラメータをリスンして受信する。
【０１２４】
オペレーション１６０４では、要求されたサービスをどのように実施するかの記述を受信する。
【０１２５】
オペレーション１６０６では、サービスのインプリメンテーションを実行するためのネットワーク接続されたコンピュータを選択し、所望のネットワーク接続をどのように行うかを判断する。
【０１２６】
オペレーション１６０８では、選択された、ネットワーク接続されたコンピュータにおいて処理を行うように準備する。
【０１２７】
オペレーション１６１０では、ネットワーク及び選択されたコンピュータにおける処理を通るメディアのフローを開始する。データの結果は、サービス要求に指定された宛先へルーティングされることに留意されたい。
【０１２８】
図１７は、本発明の一実施の形態に従って実行されるオペレーションのフローチャート１７００である。フローチャート１７００は、本発明のプロセスを含む。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションがフローチャート１７００に開示されるが、このようなオペレーションは例示である。すなわち、本実施の形態は、他のさまざまなオペレーション、又は、図１７に列挙したオペレーションの変形を実行することにも良く適している。本実施の形態内では、フローチャート１７００のオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１２９】
オペレーション１６０２では、クライアントからのサービス要求及びパラメータをリスンして受信する。
【０１３０】
オペレーション１７０２では、サービスを実施するコンポーネントの抽象グラフ及び各コンポーネントの資源要件を受信する。
【０１３１】
オペレーション１７０４では、各サービスコンポーネントを実行するためのネットワーク接続されたコンピュータを選択する。
【０１３２】
オペレーション１７０６では、選択されたマシンにおけるコンポーネントの構築を要求し、それらの相互接続を準備する。
【０１３３】
オペレーション１７０８では、ネットワーク全体にわたって分散された処理コンポーネントを通るメディアのフローを開始する。データの結果は、サービス要求に指定された宛先へルーティングされることに留意されたい。
【０１３４】
Ｅａｒは、多種多様な方法で実施できることに留意されたい。たとえば、入力Ｅａｒは、ＲＴＰ／ＲＴＳＰを使用して受信を行うことができ、また、誤り耐性のある復号器プラグイン、スマートバッファリング、フロー管理、及び最小限データコピーも含むことができる。さらに、出力Ｅａｒは、ＲＴＰ／ＲＴＳＰを使用して送信を行うことができ、可変フレームレート符号化器プラグイン、スマートバッファリング、及びフロー管理を含むことができる。これに加えて、入力Ｅａｒ又は出力Ｅａｒは、圧縮機能又は伸張機能も含むことができる。各Ｅａｒは、単一のメディアストリームのフローの一方の端部（送信又は受信）を管理する。標準規格ベースのメディアストリーミング（ＲＴＰ／ＲＴＣＰ／ＲＴＳＰ）を使用することができる。これに加えて、Ｅａｒは、符号化器プラグイン及び復号器プラグイン（たとえば、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４、ＡＭＲ、ＷＡＶ）を使用して、メディア配信に適した圧縮フォーマットと、メディア処理に多く使用される非圧縮フォーマットとの間の変換を行う。また、バッファリングポリシー、フロー制御ポリシー、及びフレーム廃棄ポリシーがＥａｒによって実施されて、配信と処理との間のデータレートの不一致を取り除くこともできる。
【０１３５】
図１０、図１１、図１２ａ〜図１２ｄは、本明細書で説明した他の実施の形態と同様に、プロセスを含むことに留意されたい。これらのプロセスは、いくつかの実施の形態では、コンピュータ可読で且つコンピュータ実行可能な命令の制御下でプロセッサ（複数可）及び電気コンポーネントによって実行される。コンピュータ可読で且つコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能揮発性メモリ、コンピュータ使用可能不揮発性メモリ、及び／又はコンピュータ使用可能マスデータストレージ等のデータストレージ装備に存在することができる。しかしながら、コンピュータ可読で且つコンピュータ実行可能な命令は、どのタイプのコンピュータ可読媒体にも存在することができる。具体的なオペレーションが本明細書に開示されるが、このようなオペレーションは例示である。すなわち、これらの実施の形態は、他のさまざまなオペレーション、又は、本明細書に列挙したオペレーションの変形を実行することにも良く適している。本明細書で列挙したオペレーションは、ソフトウェア、ハードウェア、又は、ソフトウェア及びハードウェアのあらゆる組み合わせによって実行できることに留意されたい。
【０１３６】
本発明の具体的な実施の形態の上記説明は、図解及び説明の目的で提示されたものである。それら説明は、網羅的であることを目的とするものでもなければ、開示した正確な形態に本発明を限定することを目的とするものでもなく、多くの変更及び変形が、上記教示に鑑みて可能であることは明らかである。実施の形態は、本発明の原理及びその実用的な用途を最もよく説明し、それによって、他の当業者が、本発明、及び、検討した特定の使用に適するようなさまざまな変更を有するさまざまな実施の形態を最もよく利用することを可能にするために選ばれて説明されたものである。本発明の範囲は、本明細書に添付した特許請求の範囲及びその等価物によって画定されることが意図されている。
【図面の簡単な説明】
【０１３７】
【図１】メディアを複数の移動クライアントデバイスへ配信する従来の方法を示す図である。
【図２】メディアを処理して移動クライアントデバイスへ配信する従来の方法を示す図である。
【図３】本発明による一実施の形態の図である。
【図４】本発明による一実施の形態の図である。
【図５Ａ】本発明による一実施の形態の図である。
【図５Ｂ】本発明による一実施の形態の図である。
【図６】本発明の実施の形態を実施できる単一のコンテンツサーバを有するデータセッションハンドオフの例示のシステムのブロック図である。
【図７】本発明の実施の形態を実施できるコンテンツ分配ネットワークを有するデータセッションハンドオフの別の例示のシステムのブロック図である。
【図８Ａ】本発明の一実施の形態によるデータセッションハンドオフのプロセスを示すフローチャートである。
【図８Ｂ】本発明の一実施の形態によるデータセッションハンドオフのプロセスを示すフローチャートである。
【図９】本発明による一実施の形態の図である。
【図１０】メディアサービスアーキテクチャ（ＭＳＡ）が本発明の一実施の形態に従ってサービスを分解して分散させる例示のオペレーションを示すブロック図である。
【図１１】本実施の形態の一実施の形態によるサービスロケーション管理方法論のブロック図である。
【図１２ａ】本発明の実施の形態によるサービスのコンポーネントの例示の抽象グラフである。
【図１２ｂ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１２ｃ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１２ｄ】本発明の実施の形態による、ネットワークにおけるコンポーネントの３つの例示の分散を示す図である。
【図１３】本発明の一実施の形態に従って実行される、ストリーミングメディアサービスを管理するためのオペレーションのフローチャートである。
【図１４】本発明の一実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。
【図１５】本発明の別の実施の形態に従って、複数のメディアストリームがＭＳＡ内でハンドリングされるブロック図である。
【図１６】本発明の一実施の形態に従って実行されるオペレーションのフローチャートである。
【図１７】本発明の別の実施の形態に従って実行されるオペレーションのフローチャートである。
【符号の説明】
【０１３８】
１０２・・・コンテンツサーバ
１０４、１０６、１０８・・・無線基地局
１１０、１１２、１１４、１１６、１１８、１２０・・・移動クライアントデバイス
１２０・・・電子デバイス
１２４、１２６、１２８、１３０・・・コピーの送信
１２２・・・ ラップトップ
２００、３００・・・ネットワーク
２０２、２０４、２０６・・・メディアサービスノード
２０８・・・ストリーミングメディア
２１０・・・メディアストリーミング
３０２・・・サービスロケーションマネージャ
３０４、３０６・・・サービスポータル
３０８・・・要求
３１０・・・リダイレクト
４０４・・・通信
４０６、４０８、４１０・・・観察又は監視
５０２・・・メディアのストリーミング
５０４・・・メディアストリームのストリーミング
５０６・・・メディアストリーミングセッション
６０２、６０４・・・トランスコーダ
６０８、６１０・・・セル
６１４・・・コンテンツ分配ネットワーク
６１６、６１８・・・エッジサーバ
１００１・・・コンポーネントの抽象グラフ
１００２・・・ユーザデバイス
１００３・・・出力ディスプレイ
１００４・・・メディアサービス要求
１００６・・・サービスポータル
１００８・・・サービスビルダ
１０１０・・・コンポーネント配置要求
１０１２・・・サービスロケーションマネージャ
１０１４・・・コンポーネント配置決定
１０１６・・・構築要求
１０１８・・・ローカルビルダ
１０２０・・・コンポーネント
１０２２、１０２４、１０２６・・・サービス提供可能マシン
１０２８・・・インターネット
１０３０、１０３２・・・Ｅａｒ
１０３３・・・コンテンツサーバ
１０３５、１０３７・・・ライブカメラ
１１０２・・・ネットワーク距離テーブル
１１０４・・・前の決定テーブル
１１０６・・・マシン配置コスト
１１０８・・・資源要件ルーチン
１１１０、１１１２、１１１４・・・ローカル資源マネージャ
１１１６・・・資源照会
１２０２・・・ビデオ送信元
１２０４・・・サイズ変更
１２０６・・・背景除去
１２０８・・・合成
１２１０・・・ビデオ宛先
１２１２・・・ネットワーク
１２１４・・・ビデオ送信元
１２１６・・・ＰＤＡ
１４０２、１４０４・・・ビデオ
１４０６・・・サービスノード
１４０８、１４１０・・・入力ストリーム
１４０８ａ・・・ビデオ
１４１２、１４１４、１４１８・・・Ｅａｒ
１４１６・・・ビデオ合成
１４２０・・・ビデオ
【特許請求の範囲】
【請求項１】
ストリーミングメディアサービスを管理するための方法（１３００）であって、
ストリーミングメディアサービスの要求（１００４）をクライアント（１００２）から受信すること（１３０２）であって、前記ストリーミングメディアサービスは、複数のメディアサービスコンポーネント（１０２０）を含む、受信すること（１３０２）と、
ネットワーク（１２１２）の複数のサービスノードの或るサービスノード（１０２２）に、前記複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断すること（１３０４）と、
前記複数のメディアサービスコンポーネントの或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディア（１０３２）に対して前記ストリーミングメディアサービスを実行することを可能にするように通知すること（１３０６）と
を含む方法。
【請求項２】
前記ストリーミングメディアは、ビデオ、音響、マルチメディア、及びテキストから選択される
請求項１に記載の方法。
【請求項３】
前記判断することは、前記クライアントの前記位置に基づく
請求項１に記載の方法。
【請求項４】
前記判断することは、前記ネットワークの帯域幅に基づく
請求項１に記載の方法。
【請求項５】
前記判断することは、前記ネットワークの負荷に基づく
請求項１に記載の方法。
【請求項６】
前記判断することは、前記複数のサービスノードの各サービスノードの負荷に基づく
請求項１に記載の方法。
【請求項７】
前記判断することは、前記ネットワークの既存のストリーミングメディアサービスに基づく
請求項１に記載の方法。
【請求項８】
前記判断することは、前に割り当てられたメディアサービスコンポーネントに基づく
請求項１に記載の方法。
【請求項９】
前記要求を前記受信することは、サービスポータルを通じて行われる
請求項１に記載の方法。
【請求項１０】
割り当てられた各サービスノードの入力通信ソケット（１２１８）及び出力通信ソケット（１２２０）を生成すること（１３０８）であって、それによって、前記割り当てられたサービスノード間の通信を可能にする、生成すること（１３０８）
をさらに含む
請求項１に記載の方法。
【請求項１】
ストリーミングメディアサービスを管理するための方法（１３００）であって、
ストリーミングメディアサービスの要求（１００４）をクライアント（１００２）から受信すること（１３０２）であって、前記ストリーミングメディアサービスは、複数のメディアサービスコンポーネント（１０２０）を含む、受信すること（１３０２）と、
ネットワーク（１２１２）の複数のサービスノードの或るサービスノード（１０２２）に、前記複数のメディアサービスコンポーネントのどのメディアサービスコンポーネントを割り当てるかを判断すること（１３０４）と、
前記複数のメディアサービスコンポーネントの或るメディアサービスコンポーネントを実行するように割り当てられた各サービスノードに、ストリーミングメディア（１０３２）に対して前記ストリーミングメディアサービスを実行することを可能にするように通知すること（１３０６）と
を含む方法。
【請求項２】
前記ストリーミングメディアは、ビデオ、音響、マルチメディア、及びテキストから選択される
請求項１に記載の方法。
【請求項３】
前記判断することは、前記クライアントの前記位置に基づく
請求項１に記載の方法。
【請求項４】
前記判断することは、前記ネットワークの帯域幅に基づく
請求項１に記載の方法。
【請求項５】
前記判断することは、前記ネットワークの負荷に基づく
請求項１に記載の方法。
【請求項６】
前記判断することは、前記複数のサービスノードの各サービスノードの負荷に基づく
請求項１に記載の方法。
【請求項７】
前記判断することは、前記ネットワークの既存のストリーミングメディアサービスに基づく
請求項１に記載の方法。
【請求項８】
前記判断することは、前に割り当てられたメディアサービスコンポーネントに基づく
請求項１に記載の方法。
【請求項９】
前記要求を前記受信することは、サービスポータルを通じて行われる
請求項１に記載の方法。
【請求項１０】
割り当てられた各サービスノードの入力通信ソケット（１２１８）及び出力通信ソケット（１２２０）を生成すること（１３０８）であって、それによって、前記割り当てられたサービスノード間の通信を可能にする、生成すること（１３０８）
をさらに含む
請求項１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２ａ】
【図１２ｂ】
【図１２ｃ】
【図１２ｄ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２ａ】
【図１２ｂ】
【図１２ｃ】
【図１２ｄ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公表番号】特表２００７−５３１３３２（Ｐ２００７−５３１３３２Ａ）
【公表日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願番号】特願２００６−５１７８５１（Ｐ２００６−５１７８５１）
【出願日】平成１６年７月１日（２００４．７．１）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２１５２６
【国際公開番号】ＷＯ２００５／００６７０９
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公表日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願日】平成１６年７月１日（２００４．７．１）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２１５２６
【国際公開番号】ＷＯ２００５／００６７０９
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]