(57)【要約】      （修正有）【課題】メディア・ファイル・サイズとクライアント処理パワー／ネットワーク帯域幅との間の依存性を低減または解消する、協調的マルチ・ユーザ・ビデオ編集システムを提供する。【解決手段】サーバ１０２において、リモート・クライアント１１０からのビデオ編集コマンドを受信し、受信コマンドに応じてストレージ１０８に格納されたソース・メディア・ファイルに対する参照を含む仮想表現を変更する。ストレージコントローラ１０４が高速リンクを通じてサーバ１０２に接続されており、変更されたソース・メディア・ファイルのプロキシ表現を発生し、リモート・クライアント１１０に送信する。プロキシ表現の種々の領域を、その複雑度に応じて、背景でレンダリングするかまたはリアル・タイムでレンダリングする。レンダリングされたフレームは、背景で発生されたものであってもまたはリアル・タイムで発生されたものであっても、再利用のために格納される。【選択図】図１
2010252328.tif 000002
【特許請求の範囲】
【請求項１】
遠隔ビデオ編集のためのシステムであって、
ソース・メディア・ファイルを格納する記憶デバイスと、
ネットワークを通じて、前記ソース・メディア・ファイルに関するビデオ編集コマンドを受信する入力と、
前記ソース・メディア・ファイルの仮想表現であって、前記編集コマンドと、前記ソース・メディア・ファイルへのリンクとを含む、仮想表現と、
前記仮想表現の領域のプロキシ表現をレンダリングするための複雑度を判定する複雑度評価部であって、レンダリングが、前記受信したビデオ編集コマンドを、前記ソース・メディア・ファイルの前記領域に適用することを含む、複雑度評価部と、
前記領域の複雑度が所定のしきい値を超過する場合、前記レンダリング対象領域を背景レンダリング・エンジンに送出するレンダリング・スケジューラであって、前記背景レンダリング・エンジンは、前記受信した編集コマンドを前記領域に対応する前記ソース・メディア・ファイルの一部に適用することによって前記領域をレンダリングし、該レンダリングした領域をレンダリング・キャッシュに格納する、レンダリング・スケジューラと、
前記編集したソース・メディア・ファイルのプロキシ表現を配信するメディア配信エンジンであって、前記仮想表現の各領域について、該領域のレンダリングが前記レンダリング・キャッシュ内にある場合、前記メディア配信エンジンは前記領域を前記レンダリング・キャッシュから取り出して、前記領域をネットワークを通じて送信し、前記領域のレンダリングが前記レンダリング・キャッシュ内にない場合、前記メディア配信エンジンは、前記領域に対応する前記ソース・メディア・ファイルの一部を取り出し、前記受信したビデオ編集コマンドを前記ソース・メディア・ファイルの取り出した部分に適用することによって、リアル・タイム・レンダリング・エンジンを用いて前記領域をリアル・タイムでレンダリングし、前記領域を前記ネットワークを通じて送信する、メディア配信エンジンと、
を含む、システム。
【請求項２】
請求項１記載のシステムにおいて、前記リアル・タイム・レンダリング・エンジンは、前記レンダリングした領域を、レンダリング・キャッシュに格納する、システム。
【請求項３】
請求項１記載のシステムにおいて、前記プロキシ表現はビデオ・ストリームであり、前記メディア配信エンジンはストリーミング・エンジンである、システム。
【請求項４】
請求項１記載のシステムにおいて、前記仮想表現の前記領域は、前記ソース・メディア・ファイルのうち、前記ビデオ編集コマンドが適用された１つ以上のフレームを含む、システム。
【請求項５】
請求項１記載の遠隔ビデオ編集システムにおいて、第１ユーザが前記ネットワークを通じて前記ビデオ編集システムに接続され、前記ビデオ編集システムは、前記ネットワークを通じて前記第１ユーザからビデオ編集コマンドを受信するように構成され、前記第１ユーザからの前記コマンドは、前記仮想表現と関連付けられた、遠隔ビデオ編集システム。
【請求項６】
請求項５記載の遠隔ビデオ・システムであって、更に、前記最初に述べた仮想表現を含む複数の仮想表現を備えており、該複数の仮想表現の各々は、前記ネットワークを通じて前記ビデオ編集システムに接続された複数のユーザのうち一人と関連付けられており、前記複数のユーザは前記第１ユーザを含み、前記ビデオ編集システムは、前記複数の接続されたユーザの各々から、ビデオ編集コマンドを前記ネットワークを通じて受信するように構成され、受信される各コマンドは、当該受信されたコマンドの発信元である、前記複数のユーザのうちの一人と関連のある前記複数の仮想表現のうちの１つに関する、遠隔ビデオ・システム。
【請求項７】
請求項６記載の遠隔ビデオ編集システムにおいて、前記複数の接続されたユーザの一人以上に割り当てられる処理資源レベルは、接続されたユーザ数に動的に依存する、遠隔ビデオ編集システム。
【請求項８】
請求項７記載の遠隔ビデオ編集システムにおいて、前記複数の接続されたユーザの一人以上に割り当てられる前記処理資源レベルは、背景レンダリングに対する割り当てを含む、遠隔ビデオ編集システム。
【請求項９】
請求項７記載の遠隔ビデオ編集システムにおいて、前記複数の接続されたユーザの一人以上に割り当てられる前記処理資源レベルは、リアル・タイム・レンダリングと前記プロキシ表現の前記ネットワークを通じた送信とのための前景処理資源の割り当てを含む、遠隔ビデオ編集システム。
【請求項１０】
請求項６記載の遠隔ビデオ編集システムにおいて、接続されたユーザに割り当てられる処理資源レベルは、当該ユーザに割り当てられる重みに部分的に基づく、遠隔ビデオ編集システム。
【請求項１１】
遠隔ビデオ編集のためのシステムであって、
クライアントであって、
（ａ）メディアのプロキシ表現を受信するための入力と、
（ｂ）前記プロキシ表現を復号化するためのプロセッサと、
（ｃ）前記復号化したプロキシ表現によって表されるコンテンツを表示するためのグラフィカル・ユーザ・インターフェースと、
（ｄ）前記プロキシ表現を編集するためのコマンドの入力を容易にするためのユーザ入力と、
（ｅ）前記編集コマンドと送信するための出力と、
を含む、クライアントと、
前記編集コマンドを受信し、該編集コマンドをソース・メディア・ファイルに適用し、前記ソース・メディア・ファイルおよび前記編集コマンドに応じて前記プロキシ表現を発生するサーバであって、前記ソース・メディア・ファイルのうち、前記編集コマンドの適用が所定のしきい値を超過する計算負荷を伴う領域に対して、前記プロキシ表現を背景プロセスによって発生し、前記ソース・ファイルのうち、前記編集コマンドの適用が所定のしきい値未満の計算負荷を伴う領域に対して、前記プロキシ表現をリアル・タイムで発生する、サーバと、
を含む、システム。
【請求項１２】
請求項１１記載のシステムにおいて、前記クライアントは、デスクトップ・コンピュータ、ワークステーション、ラップトップ・コンピュータ、ノートブック、およびスマートフォンのうちの１つである、システム。
【請求項１３】
請求項１１記載のシステムにおいて、前記プロキシ表現はメディア・ストリームを含む、システム。
【請求項１４】
請求項１１記載のシステムにおいて、前記プロキシ表現は、前記ユーザ入力を通じて要求された１つ以上の個々のフレームを含み、該１つ以上の個々のフレームは、前記編集コマンドの前記ソース・メディア・ファイルへの適用に対応する、システム。
【請求項１５】
ビデオ・ファイル遠隔編集のための方法であって、
サーバにおいて、リモート・クライアントからのビデオ編集コマンドを受信するステップと、
前記サーバにおいて、前記受信したコマンドに応じてメディア・ファイルの仮想表現を変更するステップであって、前記仮想表現が、記憶デバイスに格納されたソース・メディア・ファイルに対する参照を含み、前記記憶デバイスが高速リンクを通じて前記サーバに接続された、ステップと、
前記編集コマンドによって変更された前記ソース・メディア・ファイルのプロキシ表現をレンダリングし、前記サーバから前記リモート・クライアントに送信するステップであって、前記プロキシ表現のうち、当該プロキシ表現のレンダリングがしきい値を超過する計算資源を必要とする領域を、背景レンダリング・プロセスによってレンダリングし、前記プロキシ表現の残りの領域をリアル・タイムでレンダリングする、ステップと、
を含む、方法。
【請求項１６】
請求項１５記載の方法において、前記サーバは複数の仮想表現を含み、前記方法は、更に、複数のリモート・クライアントからビデオ編集コマンドを受信するステップを含み、前記リモート・クライアントの各々は、対応する仮想表現と関連付けられ、前記編集コマンドの各々は、当該受信されたコマンドの発信元である、クライアントに対応する前記複数の仮想表現のうちの１つに関する、方法。
【請求項１７】
請求項１６記載の方法において、前記複数のリモート・クライアントの１つ以上に割り当てられるサーバ処理資源レベルは、前記サーバに接続されたリモート・クライアントの数に動的に依存する、方法。
【請求項１８】
請求項１７記載の方法において、前記複数のリモート・クライアントの１つ以上に割り当てられる前記処理資源レベルは、背景レンダリングに対する割り当てを含む、方法。
【請求項１９】
請求項１７記載の方法において、前記複数のリモート・クライアントの１つ以上に割り当てられる前記処理資源レベルは、リアル・タイム・レンダリングと前記プロキシ表現の送信とのための前景処理資源の割り当てを含む、方法。
【請求項２０】
請求項１６記載の方法において、リモート・クライアントに割り当てられる処理資源レベルは、該クライアントに割り当てられる重みに部分的に基づく、方法。
【請求項２１】
請求項１５記載の方法において、前記プロキシ表現はビデオ・ストリームを含む、方法。
【請求項２２】
請求項１５記載の方法において、前記サーバは、前記プロキシ表現をレンダリング・キャッシュに格納する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願に対する相互引用
本願は、２００９年４月１４日に出願し、"Multi-User Remote Video Editing"（マルチ・ユーザ遠隔ビデオ編集）と題する米国仮特許出願第６１／１６９，１２５号、および２００９年９月３日に出願し"Rendering in Multi-User Video Editing System"（マルチ・ユーザ・ビデオ編集システムにおけるレンダリング）と題する米国仮特許出願第６１／２３９，６００号に対する優先権の利益を主張する。これら双方をここで引用したことにより、その内容は本願にも含まれるものとする。本願は、本願と同じ日に出願され"Multi-User Remote Video Editing"（マルチ・ユーザ・ビデオ編集）と題する米国特許出願第１２／７５４，８２６号に関係がある。この出願をここで引用したことにより、その内容全体が本願にも含まれるものとする。
【背景技術】
【０００２】
ビデオ編集ソフトウェアを実行するコンピュータは、カット、サイズ変更、レイヤリング(layering)、合成(compositing)、タイリング、ルーピング、およびグラフィックスや効果の追加を含む動作を実行することによって、ビデオおよび／またはオーディオを収容するメディアを編集するために用いることができる。ソース・マテリアルは、種々のフォーマットの内の１つで符号化したディジタル・メディア・ファイルとすることができ、その上、アナログ・ソース・メディアでも、ディジタル・ファイルに変換し、編集し、オプションとしてアナログ・フォーマットに変換し直すこともできる。
【０００３】
コンピュータを基本とする従前のビデオ編集システムは、一人または複数のユーザに対処するように構成することができるが、各コンフィギュレーションが望ましくない特性を有する場合もあり得る。単一ユーザ編集システムは、例えば、ユーザ間において協調や資源共有ができず、利用度が過小となる虞れもある。例えば、一人のユーザが編集動作を実行していない間、アイドル状態となっている可能性があり、あるいは実行中の編集動作の計算コストが多大でない場合にはほぼアイドル状態となっている場合がある。単一ユーザ編集システムは、ユーザが実行する可能性がある最も複雑な編集タスクでも処理できる程にロバストでなければならないので、そしてこのロバスト性には出費が伴うこともあるので、単一ユーザ・システムに少しでもアイドル時間が生ずると、システムに投資した資金が無駄になることになる。
【０００４】
他方で、従前のマルチ・ユーザ・システムは、集中して配置したメディアを複数ユーザに共有させることができる。例えば、ファイル・サーバは、メディア・ファイルの１つのコピーをホストし、ローカル・エリア・ネットワークを通じて接続されている複数クライアント・ワークステーションにそれを配信することができる。あるいは、ｈｔｔｐサーバは、インターネットを通じて接続されている複数クライアント・ワークステーションにメディア・ファイルをストリーミングすることができる。いずれの場合でも、メディア・ファイルの集中格納が、ビデオ編集アプリケーションの全体的効率を高めることができる。しかしながら、従前のマルチ・ユーザ編集システムには様々な欠点がある。１つには、これらは、メディア・ファイルをホストし配信するための強力なサーバと、実際の編集を実行する強力なワークステーション・クライアントとの双方を必要とする。ワークステーション・クライアントは、前述の単一ユーザ・システムと同様、複雑な編集タスクを処理するためには十分にロバストでなければならないものの、所与のワークステーションにおけるユーザが常にクライアントの最大パワーを用いる訳ではないので、過小利用に陥る虞れがある。更に、ファイル・サーバまたはｈｔｔｐサーバは、ファイルまたはストリームをクライアントに送る前に、それらをインテリジェントに処理する能力に欠ける。例えば、複雑なプロフェッショナル品質の編集プロジェクトでは、様々なオーディオおよびビデオ・クリップを同時に一緒に積層して、合成したメディアを作成する。しかしながら、このファイルまたはｈｔｔｐサーバは各レイヤの全体を要求元のクライアントに送信しなければならず、更にシステムに負担がかかることになる。
【０００５】
従前のマルチ・ユーザ・システムの別の欠点は、これらが大量のネットワーク帯域幅を必要とすることである。「オンライン」編集、即ち、クライアントによるソース・メディア・ファイルの直接変更では、クライアントが最初にソース・メディア・ファイル全体をサーバからローカル・ストレージにダウンロードし、編集が完了したときにメディア・ファイルをアップロードすること、またはクライアントが、ネットワーク接続されたファイル・システムを通じて、ソース・メディア・ファイルにアクセスすることのいずれかを必要とする。いずれの場合でも、サーバとクライアント間で大量のネットワーク・トラフィックが発生するので、非常に高い帯域幅およびコストのかかるクライアント／サーバ・ネットワークが必要となる。このトラフィックの一部を軽減するために、従前のマルチ・ユーザ・システムは「オフライン」編集を用いることもできるが、その場合、本来のサイズが大きいメディア・ファイルの代わりに、ソース・メディアのサイズを縮小したコピー（「プロキシ」）を発生し、クライアントに送る。クライアントは、プロキシを編集することができ、プロキシに対して実行される一連の編集コマンド（「タイムライン」）をソース・メディアに適用（即ち、「再リンク」）することができる。しかしながら、オフライン編集には、これらのプロキシを発生するために要する時間、処理資源、およびストレージの浪費に加えて、プロキシを送信および編集するためになおも多大な量のネットワークおよびクライアント処理パワーが必要となるという欠点がある。更に、ユーザがオフライン・プロキシを編集している時間中、ソース・メディアには、例えば、元のメディアを置換すること、または新しいソース・メディアをプロジェクトに追加することによって変更が生ずる場合があり、つまり以前に発生したプロキシを追跡し、これらを元のメディアと連続的に同期させるという厄介な作業が必要となる。最後に、ある種のハイ・エンド効果のような複雑な編集機能は、オフラインでは実行することができず、オンラインで実行しなければならない。
【０００６】
更に、従前のリモート・アクセス・ビデオ・システムは、一般に、ビデオ編集に必要とされる、ソース・メディアの正確で高速なフレーム毎の制御ができない。殆どのビデオ符号化方式は、異なる形式のフレームを用いており、それらの全てが自己充足的ではない (self-contained)。例えば、所与のフレームが、符号化ピクチャ内・フレーム(intra-coded picture frame)即ちＩ−フレームとして知られている、最大仕様ピクチャ・フレームである場合がある。しかしながら、他のフレームは最大仕様ではなく、代わりに、現フレームと最後のＩ−フレームとの間の差を捕らえるものであることもある。これらのフレームは、予測ピクチャ・フレーム（「Ｐ−フレーム」）または二回予測ピクチャ・フレーム(bipredicted-picture frame)（「Ｂ−フレーム」）として知られている。ユーザが要求したフレームが偶然Ｐ−フレームまたはＢ−フレームである場合、編集アプリケーションは直前のＩ−フレームまで逆戻りし、次いで中間にあるＰ−およびＢ−フレームを経て順方向に辿らなければならず、こうして要求されたフレームを再現する。しかしながら、この動作を高速に実行するには、メディア・ファイル全体へのローカル・アクセスが必要となり、従前のリモート・アクセス・システムにとって、これはメディア・ファイル全体をダウンロードすることを意味し、これによって、前述したネットワーク帯域幅の不利益(penalties)を招くことになる。ソース・メディア・ファイルに対するローカル・アクセスを行わないと、リモート・クライアントは、要求されたフレームが専有するメディア・ファイルにおける位置を推定するが、推定における誤差があるとそのいずれもが、フレーム・シーク時間において時間的な不利益を招く。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述の欠点の多くは、ＨＤＴＶのように、ビデオ・フォーマットの分解能が高くなる程悪化する。分解能が大きい程、そして対応するＨＤＴＶ状メディア・ファイルのファイル・サイズが大きい程、分析するための処理パワー増大、および伝達するためのネットワーク帯域幅拡大が必要となる。この傾向は、ビデオ信号の分解能および品質が高くなる限り続くこととなり、クライアント処理パワーの一層の増量およびネットワークの高速化が必要となる。メディア・ファイル・サイズとクライアント処理パワー／ネットワーク帯域幅との間の依存性を低減または解消する、協調的マルチ・ユーザ・ビデオ編集システムが求められていることは明らかである。
【課題を解決するための手段】
【０００８】
本発明の実施形態は、メディア・プロジェクトの遠隔ビデオ編集用システムおよび方法を含む。編集が行われるプロジェクトは、低帯域幅表現の形態で、１つ以上のクライアントに１つ以上のサーバからネットワークを通じて送信される。これら実施形態は、この低帯域幅表現をレンダリングし、マルチ・ユーザ環境におけるクライアントに送信するためのサーバ資源の最適な使用を促進する。
【０００９】
概説すると、一形態において、遠隔ビデオ編集システムは、ソース・メディア・ファイルを格納する記憶デバイスと、ネットワークを通じて、ソース・メディア・ファイルに関するビデオ編集コマンドを受信する入力と、ソース・メディア・ファイルの仮想表現であって、編集コマンドと、ソース・メディア・ファイルへのリンクとを備えている、仮想表現と、仮想表現の領域のプロキシ表現をレンダリングするために、複雑度を判定する複雑度評価部であって、レンダリングが、受信したビデオ編集コマンドを、ソース・メディア・ファイルの領域に適用することを含む、複雑度評価部と、領域の複雑度が所定のしきい値を超過する場合、レンダリング対象領域を背景レンダリング・エンジンに送出するレンダリング・スケジューラであって、背景レンダリング・エンジンは、受信した編集コマンドを領域に対応するソース・メディア・ファイルの一部に適用することによって領域をレンダリングし、レンダリングした領域をレンダリング・キャッシュに格納する、レンダリング・スケジューラと、編集したソース・メディア・ファイルのプロキシ表現を配信するメディア配信エンジンであって、仮想表現の各領域について、当該領域のレンダリングがレンダリング・キャッシュ内にある場合、メディア配信エンジンは当該領域をレンダリング・キャッシュから取り出して、当該領域をネットワークを通じて送信し、この領域のレンダリングがレンダリング・キャッシュ内にない場合、メディア配信エンジンは、この領域に対応するソース・メディア・ファイルの一部を取り出し、受信したビデオ編集コマンドをソース・メディア・ファイルの取り出した部分に適用することによって、リアル・タイム・レンダリング・エンジンを用いて前述の領域をリアル・タイムでレンダリングし、この領域をネットワークを通じて送信する、メディア配信エンジンとを含む。
【００１０】
種々の実施形態は、以下の特徴の１つ以上を含む。リアル・タイム・レンダリング・エンジンは、前述のレンダリングした領域をレンダリング・キャッシュに格納する。プロキシ表現はビデオ・ストリームであり、メディア配信エンジンはストリーミング・エンジンである。仮想表現の領域は、前述のソース・メディア・ファイルのうち、ビデオ編集コマンドが適用された１つ以上のフレームを備えている。第１ユーザがネットワークを通じてビデオ編集システムに接続されており、ビデオ編集システムは、ネットワークを通じて第１ユーザからビデオ編集コマンドを受信するように構成されており、第１ユーザからのコマンドは、前述の仮想表現と関連付けられている。本システムは、更に、最初に述べた仮想表現を含む複数の仮想表現を備えており、この複数の仮想表現の各々は、ネットワークを通じてビデオ編集システムに接続されている複数のユーザのうち一人と関連付けられており、複数のユーザは第１ユーザを含み、ビデオ編集システムは、複数の接続されているユーザの各々から、ビデオ編集コマンドをネットワークを通じて受信するように構成されており、受信される各コマンドは、当該受信されたコマンドの発信元である、複数のユーザのうちの一人と関連のある複数の仮想表現のうちの１つに関する。複数の接続されているユーザの一人以上に割り当てられる処理資源レベルは、接続されているユーザ数に動的に依存する。複数の接続されているユーザの一人以上に割り当てられる処理資源レベルは、背景レンダリングに対する割り当てを含む。複数の接続されているユーザの一人以上に割り当てられる処理資源レベルは、リアル・タイム・レンダリングとプロキシ表現のネットワークを通じた送信とのための前景処理資源の割り当てを含む。接続されているユーザに割り当てられる処理資源レベルは、当該ユーザに割り当てられる重みに部分的に基づく。
【００１１】
概説すると、別の形態では、遠隔ビデオ編集システムは、メディアのプロキシ表現を受信する入力と、前述のプロキシ表現を復号化するプロセッサと、前記復号化したプロキシ表現によって表されるコンテンツを表示するグラフィカル・ユーザ・インターフェースと、このプロキシ表現を編集するためのコマンドの入力を容易にするユーザ入力と、編集コマンドを送信する出力とを備えているクライアントと、編集コマンドを受信し、編集コマンドをソース・メディア・ファイルに適用し、ソース・メディア・ファイルおよび編集コマンドに応じてプロキシ表現を発生するサーバであって、ソース・メディア・ファイルのうち、編集コマンドの適用が所定のしきい値を超過する計算負荷を伴う領域に対して、プロキシ表現を背景プロセスによって発生し、ソース・ファイルのうち、編集コマンドの適用が所定のしきい値未満の計算負荷を伴う領域に対して、プロキシ表現をリアル・タイムで発生する、サーバとを含む。
【００１２】
種々の実施形態は、次の特徴の１つ以上を含む。クライアントは、デスクトップ・コンピュータ、ワークステーション、ラップトップ・コンピュータ、ノートブック、およびスマートフォンのうちの１つである。プロキシ表現はメディア・ストリームを備えている。プロキシ表現は、ユーザ入力を通じて要求された１つ以上の個々のフレームを含み、１つ以上の個々のフレームは、編集コマンドのソース・メディア・ファイルへの適用に対応する。
【００１３】
概説すると、更に別の形態では、ビデオ・ファイル遠隔編集方法は、サーバにおいて、リモート・クライアントからのビデオ編集コマンドを受信するステップと、サーバにおいて、受信したコマンドに応じてメディア・ファイルの仮想表現を変更するステップであって、仮想表現が、記憶デバイスに格納されているソース・メディア・ファイルに対する参照を含み、記憶デバイスが高速リンクを通じてサーバに接続されている、ステップと、編集コマンドによって変更されたソース・メディア・ファイルのプロキシ表現をレンダリングし、サーバからリモート・クライアントに送信するステップであって、プロキシ表現のうち、当該プロキシ表現をレンダリングする際にしきい値を超過する計算資源を必要とする領域を、背景レンダリング・プロセスによってレンダリングし、プロキシ表現の残りの領域をリアル・タイムでレンダリングする、ステップとを含む。
【００１４】
種々の実施形態は、次の特徴の１つ以上を含む。サーバは複数の仮想表現を含み、前述の方法は、更に、複数のリモート・クライアントからビデオ編集コマンドを受信するステップを含み、リモート・クライアントの各々は、対応する仮想表現と関連付けられており、編集コマンドの各々は、当該受信されたコマンドの発信元である、クライアントに対応する複数の仮想表現のうちの１つに関する。サーバは、プロキシ表現をレンダリング・キャッシュに格納する。
【図面の簡単な説明】
【００１５】
【図１】図１は、マルチ・ユーザ遠隔ビデオ編集システムの上位ブロック図である。
【図２】図２は、サーバのコンポーネント、および図１のマルチ・ユーザ遠隔ビデオ編集システムにおけるサーバとクライアントとの間の相互作用を示すブロック図である。
【図３】図３は、ユーザがビデオ作品に対して編集を行うときに発生する一連のイベントを示す流れ図である。
【図４】図４は、所与のユーザに対して、背景レンダリングにどのように資源を割り当てるかを示す流れ図である。
【図５】図５は、記載する実施形態におけるレンダリング・キャッシュ構造を示す図である。
【発明を実施するための形態】
【００１６】
ビデオ編集機能を集中サーバにおいて実行するマルチ・ユーザ・ビデオ編集システムが、２００９年４月１４日に出願した、関連する米国仮特許出願第６１／１６９，１２５号に記載されている。この出願をここで引用したことにより、その内容は本願にも全体が含まれるものとする。
【００１７】
図１は、本発明によるクライアント／サーバ・アーキテクチャの一実施形態を示す。サーバ１０２は、高帯域幅リンク１０６を通じてストレージ・コントローラ１０４に接続されており、このストレージ・コントローラは、１つ以上の記憶デバイス１０８を管理する。広帯域幅リンクは、Fibre Channel、InfiniBand、または１０Ｇｂイーサネット（登録商標）というようなプロトコルを用いて実現することができ、毎秒ギガビット単位の帯域幅をサポートすることができる。サーバは、１つ以上の離れて位置する複数クライアント１１０と、低帯域幅ネットワーク１１２を通じて通信する。この低帯域幅ネットワークは、例えば、イーサネットまたはワイヤレス・ネットワーク（毎秒メガビット単位程度の帯域幅に制限される）あるいはインターネット接続（毎秒１メガビット未満の帯域幅に制限される）とするとよい。サーバは、１つのデバイスでも、並列に接続されている複数のデバイスでもよい。実施形態によっては、サーバは、既知のアドレスを有する専用マシンである場合もある。他の実施形態では、サーバは、ネットワークを通じてアクセスされる１つ以上のマシンを備えており、例えば、「クラウド」においてリースされる計算および記憶資源の一部をなすサーバである。他のサーバ構成も可能である。一実施形態では、サーバはビデオ編集アプリケーション・サーバである。ストレージ・コントローラおよび記憶装置は、直接接続ストレージまたはネットワーク接続ストレージのような、数ある市販のストレージ提案のうち任意のものでよい。
【００１８】
ユーザは、ビデオ編集システムと、クライアント・コンピュータ１１０を通じて双方向処理を行う。クライアント・コンピュータ１１０は、低帯域幅ネットワーク１１２を通じてサーバ１０２に接続されており、サーバ１０２は全てのビデオ編集動作を実行し、メディア・プロジェクトの現在の状態の仮想表現をクライアント・ユーザに提示する。元のメディア・ファイルは、サーバだけが処理し、記憶デバイスに格納するか、または広帯域幅リンクを通じて前述のサーバに接続されている他の複数サーバ（図示せず）に格納してもよい。
【００１９】
ビデオ作品を作成するためのメディア・プロジェクトは、一般に、３つの主要なフェーズ、即ち、取込フェーズ、編集フェーズ、およびエクスポート・フェーズと進展する。取込フェーズでは、編集者は作品を作成する際に用いられる元のメディア・ファイルを入手する。編集フェーズでは、編集者は、編集、編成、効果の追加、色補正、および元のメディア・ファイルを用いてのその他の機能の実行によって、ビデオ作品を作成する。最後に、エクスポート・フェーズでは、空中ブロードキャストによって、あるいはＤＶＤまたはテープのような記憶媒体に書き込むことによって、あるいはその他の手段のいずれかによって、配信すべきバージョンを発生しエクスポートする。本明細書に記載するシステムおよび方法は、編集フェーズに言及する。編集フェーズの間に実行されるレンダリングおよび編成機能の目的は、編集者に、進展中の作業の状態の仮想表現、即ち、タイムラインによって表されるプロジェクトを再生したときにどのように見えるか提示することである。
【００２０】
図２は、サーバとクライアントとの間における基本的な双方向処理を示す。サーバ１０２（およびそれに関連する記憶デバイス）は、元のメディア・ファイル２０２を含む。元のメディア・ファイル２０２は、編集プロセスを経てビデオ作品を発生するためのビデオおよびオーディオ・ソース・マテリアルを含む。また、サーバは、メディア・ファイルを編成するため、そしてメディア・プロジェクト、ビデオ作品の現在の状態のプロキシ表現を発生し、それをネットワークを通じてクライアント２０４に配信するためのエンジンも含む。以下に続く説明全体を通じて、プロキシ表現は、編集コマンドをソース・メディア・ファイルに適用した際の、ビデオ作品の現在の状態を表す実行時ビデオ・ストリームとすることができ、あるいはＪＰＥＧのような圧縮フォーマットで表された１つ以上の個々のフレームであってもよく、あるいはビデオ作品の別のコンパクトな表現を含むこともできる。また、ビデオ・サーバは、編集したメディア・プロジェクト２０８の現在の状態の仮想表現も含み、この仮想表現は、サーバによって受信された編集コマンド、および元のメディア・ファイル２０２へのリンクを含む。記載している実施形態では、編集されたメディア・プロジェクトは、タイムラインとして表わされる。サーバは、プロキシ表現をクライアント２０４にネットワークを通じて送信し、ユーザはクライアントにおいてストリームを視認することができる。また、サーバは、複雑度評価部および背景レンダリング・スケジューラ２１０、背景レンダラ２１２、およびレンダリング・キャッシュ２１４も含む。これらについて、以下で詳細に説明する。
【００２１】
ユーザがタイムラインの再生を要求すると、レンダリングおよびメディア配信エンジン２０６は、作品の現在の状態をネットワーク１１２を通じてクライアントに送る。要求したコンテンツのうち任意のものが既にレンダリングされている場合、レンダリングされているマテリアルをレンダリング・キャッシュ２１４から取り出し、それをクライアントに送信する。それが未だレンダリングされていない場合、エンジンは、要求されたタイムラインの部分をリアル・タイムでレンダリングしてから、それをクライアントに送信する。また、後に再利用するために、リアル・タイムでレンダリングしたいずれのフレームも、レンダリング・キャッシュに格納する。
【００２２】
クライアント２０４は、ユーザの編集コマンドを受け入れるために編集グラフィカル・ユーザ・インターフェース（ＧＵＩ）２１６を含む。ユーザが入力した編集コマンドは、サーバに返送され、サーバは、プロジェクト・タイムラインの表現を含むメディア・プロジェクト・ファイル２０８におけるコマンドを収集する。サーバにおいてこれらが受信されると直ちに、編集コマンドがメディア・プロジェクト・ファイルにおいて実施され、それに応じてタイムラインが更新される。タイムラインの現在の状態のレンダリングのみが、要求を受けたときに、ユーザにストリーミングで返されるが、個々のフレームがストリーミングされることは決してない。元のメディア・ファイル全体も、その任意の縮小サイズ・バージョン全体も、クライアントに送信する必要はなく、クライアント自体はいずれの編集コマンドも処理することができない。クライアント２０４は、受信したメディア・コンテンツをユーザに表示するために、メディア・ビューア２１８を含む。
【００２３】
これより、どのようにシステムが再生、ストリーミング、および編集体験のスケジュールを組み、その優先順位を決定するかについて、１組の接続されているクライアント編集者のために編集体験を最適化するという視点で説明する。
【００２４】
図３は、ユーザが作品に対して編集を行うときに生ずる一連のイベントを示す流れ図である。編集命令が受信されると（３０２）、システムは、編集が、レンダリングのし直しが必要となるような、即ち、領域を無効にするような、変化をタイムラインの領域に発生させたか否か判断する（３０４）。このような無効は、たとえば、ビデオのレイヤを追加することによって、またはビデオ効果を導入することによって生ずる。しかしながら、セグメントの一部をトリミングして削除すること、つまり、影響のある領域の期間を短縮することは、その領域を無効にすることにはならない。編集コマンドが領域を無効にしない場合、またはそうでなくても、任意の領域にレンダリングを必要とさせない場合、レンダリング行為は要求されない（３０６）。次いで、システムは、レンダリングすべきタイムラインの部分が十分に単純であるため、ストリーミング・エンジンによってリアル・タイムでレンダリングできるか否か、またはリアル・タイムのレンダリングには複雑過ぎるか否か判断する。この判断は、その部分に対してコスト関数を評価することによって行われる（３０８）。コスト関数は、編成するソースの数、それらの分解能（例えば、標準品位（（ＳＤ）テレビジョン・ビデオ、または高品位テレビジョン規格（ＨＤＴＶ））、ならびに適用する編成機能および効果の特質を考慮に入れる。また、コスト関数は、サーバのハードウェア構成も考慮に入れ、ハードウェア構成には、ＣＰＵクロック速度、コアの数、メモリ・バスの速度、およびレンダリング・プロセスの性能に影響を及ぼすその他の関連仕様が含まれる。コスト関数に集計されるコストの値は、参照表から得られる。例えば、クロマキー効果の正規化した複雑度は５とすることができ、３Ｄワープ効果の複雑度は８とすることができる。加えて、実施形態によっては、所与の数およびフォーマットのソース・ビデオ・レイヤについて共通に発生する効果をレンダリングするのに要する時間の測定値を用いることによって、コスト値を経験的に変更することもある。
【００２５】
コスト関数に含めることができる追加のパラメータに、プロジェクトの編集フェーズ中にレンダリングされるプレビュー（または作業）分解能およびフレーム・レートがある。このプレビュー分解能およびフレーム・レートは、プロジェクトの開始時に決定され、レンダリング・キャッシュに対して発生されるビデオの品質に言及する。これは、プロジェクトの編集フェーズの間にクライアントにストリーミングすることができる最高の品質に設定される。例えば、ユーザは、７２０×４８６のＳＤ  ＮＴＳＣに対応するように目標分解能を設定することもあり得る。この場合、全ての背景レンダリングはこの品質で実行される。しかしながら、クライアントが、この品質のビデオ・ストリームをサポートしない低帯域幅接続を通じて作業している場合、クライアントはもっと低い分解能のストリームを要求することができる。次いで、ストリーミング・エンジンは、レンダリング・キャッシュからの、既にレンダリングされている任意のフレームをダウンサンプリングし、任意のレンダリングされていないフレームをリアル・タイムで発生することによって、品質を低下させたストリームを送る。一方、クライアントが高帯域幅ネットワークを通じてサーバに接続されており、ユーザ数が少ないと予想される場合、ユーザはプレビューをＨＤで受信することができ、システムはプレビューをＨＤでストリーミングすることができ、この場合、ユーザは７２０ｉ、７２０ｐ、１０８０ｉ、または１０８０ｐに対応するレンダリングの目標分解能およびフレーム・レートを選択する選択肢を有する。
【００２６】
一旦レンダリングすべき領域のコスト関数が決定したなら、システムは、それを所定のコスト関数しきい値と比較する（３１０）。記載している実施形態では、コスト関数しきい値は、ユーザが定める値である。別の実施形態では、システム構成およびユーザの好みを含む要因に基づいて、このしきい値は自動的に決められる。コスト関数によって決定されたタイムラインの無効領域の複雑度がしきい値よりも上である場合、再生の要求を受けたときに、リアル・タイム・レンダラの能力を拠り所としてその領域をリアル・タイムでレンダリングするのではなく、システムはその領域が、背景レンダリングを必要とする程複雑であると見なす。したがって、その領域を背景レンダラに送出する（３１２）。無効化された領域の複雑度がコスト関数しきい値を超過していない場合、その領域は背景レンダラに送出されない（３１４）。何故なら、その領域は、クライアントによって要求された場合、リアル・タイム・レンダリング・エンジン２０６によって、リアル・タイムにレンダリングすることができるからである。
【００２７】
コスト関数しきい値は、サーバの全体的利用度を最適化しつつ、接続されているユーザの各々についてレイテンシおよびリアル・タイム再生能力の容認可能なレベルを維持するようなレベルに設定される。このレベルは、経験的に決定され、システムおよび構成情報に基づく。この情報は、予測されるユーザの最大数、ソース・マテリアルの特質、および性能に影響を及ぼす可能性があるその他のプロジェクトに関するパラメータを含むことができる。例えば、ソース・メディアを、例えば、伸張が計算集約的な高度圧縮フォーマットのような、大量の処理を必要とする形態で符号化するときには、しきい値を上方向に調節して、タイムラインの無効化された領域の大部分を背景レンダラに送出して、リアル・タイム再生に利用可能な資源を過度に枯渇させることを回避する。高処理要求が生ずるフォーマットの例には、RED Cameraフォーマット、Dalsa Bayerフォーマット、および非線形歪像変換を必要とするビデオ・カメラ・フォーマットがある。
【００２８】
このような高複雑度プロジェクトでは、リアル・タイム・レンダリングおよびストリーミング・エンジンは、要求された分解能でレンダリングおよび再生を実行できないこともあり得るのであり、そうなった場合、オーディオ・フレームには手を付けないままにして、ビデオ・フレームを欠落させることによって、ストリーミング・フレーム・レートを制御する。オーディオ・ストリームに影響がある場合、再生を停止し、ストリーミング・エンジンはストリームをバッファリングし始める。この状況が生ずるのは、背景レンダリングを実行する前に背景レンダラに送出し終えている領域が再生に要求されるとき、あるいは背景レンダリング機構がオフになっているとき、あるいはユーザが定めたコスト関数しきい値が、必要上、高いレベルの複雑度に設定されており、リアル・タイムでレンダリング可能と指定された領域の複雑度が上昇するときである。尚、個々のフレーム・レベルの粒度に至るまで、実行された部分的背景レンダリングのうち任意のものを、ストリーミング・エンジンによってレンダリング・キャッシュから取り出すことができ、こうしてストリーミングの品質を向上させることができる。
【００２９】
以下に説明するように、システムは、動的に割り当てられる資源を用いて、高い優先順位をリアル・タイム・レンダリングおよび再生に割り当て、背景レンダリング・タスクの方が優先順位は低い。
【００３０】
マルチ・ユーザ環境では、サーバにかかる負荷は、新たなユーザがログ・オンして彼らの編集プロジェクトで作業を開始すると、予測不可能に変化する可能性がある。このため、タイムライン上の特定の領域をリアル・タイムで再生できるか否か評価する際、即ち、コスト関数しきい値を設定する際、システムは当該領域をユーザにストリーミングする時点において所与のユーザに利用可能な資源について、控えめな推定値を用いる。
【００３１】
図４は、所与のユーザに対して背景レンダリングにどのように資源を割り当てるかを示す流れ図である。複雑度評価およびレンダリング・スケジューラ（図２、２１０）によって送出されたレンダリング・ジョブを受けると（４０２）、背景レンダラ２１２は、背景レンダリングのために対応するユーザに現在どの資源が利用可能であるか確認する（４０４）。この確認は、サーバにおいて利用可能な全処理資源、およびシステムに現在接続されているユーザのリストを考慮に入れる（４０６）。以下のアルゴリズムは、前述のビデオ編集システムにおける資源の割り当てを例示する。所与のサーバ構成の計算資源は、作業スレッドの数Ｍによって表すことができる。例えば、特定のサーバが８つのコアを有し、各コアが４つのスレッドを提供する場合、利用可能な作業スレッドの総数は３２となる。デフォルトとして、接続されている各ユーザには、利用可能なスレッドの等しい端数が割り当てられているが、１スレッド以上である。つまり、背景レンダラに何を送るべきか判断する際に、システムは最悪の状況を想定する、即ち、ユーザには１つの作業スレッドしか利用可能でないと想定する。したがって、１つの作業スレッドを用いてレンダリングすることができない領域は、いずれも背景レンダラに送られる。尚、１つのスレッドを用いてリアル・タイムでレンダリングすることができる領域は、不要かもしれない計算を実行することを回避するように、背景でのレンダリングは行われないことを注記しておく。不要な計算の一例は、タイムラインに対する変化が再生の前に行われないときに発生する。
【００３２】
実施形態によっては、例えば、次の式を用いて、各ユーザに、どれくらいの資源がそのユーザに割り当てられるかに影響を及ぼす重みを割り当てることもある。
【００３３】
【数１】
2010252328.tif 000003
【００３４】
あるユーザがシステムにログ・インすると、この新たなユーザに必要なスレッド数を解放するために、既にログ・インしている一人以上のユーザに割り当てられているスレッドの数が減少し、ログ・インしているユーザの各々が１つ以上のスレッドを放棄する場合もある。逆に、あるユーザがログ・オフすると、そのユーザの資源は、残りの接続中のユーザに利用可能となり、彼らの各々は、１つ以上の余分なスレッドへのアクセスを得ることができる。このように、所与の接続中のユーザに利用可能なスレッドの数は、いずれの時点でも変化する可能性がある。本明細書において用いる場合、「スレッド」という用語は、サーバ処理資源の任意の単位を指す。システムは、接続中のユーザに対して、サーバ資源の柔軟で動的な配分を最適化するために、スレッドに関連する資源のレベルを設定することができる。
【００３５】
図４に示すように、システムが、背景レンダリング資源は現在ユーザに利用可能でないと判断すると（４０８）、背景レンダリング・ジョブは、資源が利用可能になるまで、キュー内に留置される（４１０）。一旦資源が利用可能となると、背景レンダラはレンダリングを開始し（４１２）、レンダリングした各フレームをレンダリング・キャッシュに格納する（４１４）。レンダリング・タスクが完了していない場合（４１６）、接続中ユーザのリストが変化しなければ（４１８）、割り当てられたサーバ資源を用いて、背景レンダリングを継続する。接続中ユーザのリストが変化した場合、割り当てられている資源を調節し（４２０）、新たなリストに対処する（４０６）。
【００３６】
種々の発見的規則にしたがって、背景レンダリングに優先順位を付ける。高い優先順位は、ユーザのカーソルが現在アクティブであるタイムラインの領域に与えられる。これは、このエリアがユーザの注目を受けており、ユーザは彼の編集を評価するためにこの領域を視認したいと考える可能性があるという想定に基づいている。実施形態によっては、コスト関数の評価によって決定される複雑度が高い領域を最初にレンダリングする。何故なら、背景レンダリングの完了前にユーザが再生を要求した場合、これらが再生ストリームにおいて最大の劣化を被るからである。
【００３７】
背景レンダリングが予定されているが未だ完了していない領域の再生をユーザが要求した場合、リアル・タイム・レンダリングおよびストリーミング・エンジンは、要求元ユーザに利用可能な全てのスレッドを用いる。利用可能な資源が、要求された品質でリアル・タイムでレンダリングを実行するためには十分でない場合、システムは、分解能および／または１秒当たりのフレーム数を減少させて、適切にストリーミング品質を低下させる。
【００３８】
クライアントにストリーミングを戻すとき、リアル・タイム・レンダリングおよびストリーミング・エンジンは、レンダリング・キャッシュ内にあるのであれば、要求された再生のいずれの部分でも、個々のフレームのレベルまで、取り出すことができる。つまり、未だ有効なフレームがレンダリング・キャッシュ内にあれば、ストリーミング・エンジンはそのいずれでも取り出してストリーミングすることによって、未だレンダリングされていないフレームをレンダリングするために、利用可能な資源が限定して適用されることを確保する。加えて、リアル・タイム・レンダリング・エンジンによってリアル・タイムにレンダリングされる各フレームは、レンダリング・キャッシュに格納される。こうして、背景レンダラおよびリアル・タイム・レンダラの双方から発したフレームが、レンダリング・キャッシュに詰め込まれる。
【００３９】
レンダリング・キャッシュからの既にレンダリングされたフレームと、リアル・タイムでレンダリングされているフレームとの組み合わせを用いることによって、ビデオ・ストリームをリアル・タイムで組み立てるストリーミング・エンジンの能力は、レンダリング・キャッシュの構造およびそのインデクシング方式に基づく。図５は、レンダリング・キャッシュの構造を示す図である。タイムライン５０２は、Ｓ１、Ｓ２、．．．Ｓｎで示す編集／効果イベントの位置に基づいて、対象領域のスライスに分割される（５０４）。以下のように、各領域に一意のスライス識別子（ＳＩＤ）が定められる。
【００４０】
【数２】
2010252328.tif 000004
【００４１】
ここで、ＳＩＧＮは、ＭＤ５またはＳＨＡのような標準的なダイジェスト関数(digest function)である。所与の領域に対するレンダリング・キャッシュのエントリ（BucketKey)は、次のように定められる。
【００４２】
【数３】
2010252328.tif 000005
【００４３】
各バケット５０６の中では、レンダリングされたフレーム・ファイルにはFile＿Frame＿N、File＿Frame＿N+1等が付番され、開始数Ｎは、追跡時間とレンダリング・キャッシュ・シーケンス時間(rendered cache sequence time)との間のオフセットを反映する（５０８）。バケット毎のキャッシュ範囲（５１０）CacheRangeは、範囲リストとして定められる。
【００４４】
【数４】
2010252328.tif 000006
【００４５】
レンダリング・キャッシュは、タイムラインにおける各領域またはフレームの現在の状態にのみインデックスを付ける。有効なフレームまたは領域の現在の状態を得るために、実行された編集コマンド・シーケンスには独立して、領域またはフレームを一意に定める、ソース・メディアの記述子、オフセット、効果、編成規則などからのみ得られるパラメータを用いる。キャッシュ・インデックスによって、システムは、現在有効なフレームまたは領域がレンダリング・キャッシュ内にあるか否か素早く判断することが可能になる。レンダリング・キャッシュは、プロジェクトの編集フェーズ全体において既にレンダリングされた全てのフレームを保持するので、所与のフレームまたは領域が１回よりも多くレンダリングされることはなく、これによってサーバの効率を高めている。このレンダリング処理の節約は非常に重要となり得る。何故なら、多くの編集者が編集を行って特定の選択物を評価し、コマンドを実行しなかった状態に戻したり、これらのコマンドを異なるシーケンスで再度実行することによって、後戻り(backtrack)することを決定することが多いからである。
【００４６】
本明細書に記載した技法および方法は、マルチ・サーバの実現例にも拡張する。このような実現例では、複数のサーバのうち１つ以上をレンダリング・サーバに指定することができる。レンダリング・サーバは、背景レンダラを実行し、オプションとしてレンダリング・キャッシュを含む。１つ以上のレンダリング・サーバを含む実施形態、およびレンダリング専用のサーバを特に指定しない実施形態のいずれについても、複数のサーバ間の負荷は、負荷均衡技法を用いて、均衡させることができる。
【００４７】
各物理サーバは、中央処理ユニット、グラフィクス・プロセッサ、オペレーティング・システム、ならびにユーザ−およびシステム−レベルのライブラリというような、その動作に必要な標準的なハードウェアおよびソフトウェアを含む。サーバのハードウェアおよびソフトウェアは、例えば、符号化または復号化処理集約メディア圧縮方式のような、ビデオ編集タスクの性能を向上させるための標準であるものを超えてカスタム化することもできる。
【００４８】
ユーザがサーバにログ・インすると、サーバはユーザ毎に別個のプロセスを作成する。各プロセスは、他のプロセスによって分離することができる。負荷均衡モジュールが、自動的に、ｍ個のサーバのうちどれが、新たなユーザの要求を実行するのに最も適しているか判断することもできる。負荷均衡モジュールは、入力として、均衡を取ろうとするサーバの処理パワーを表すパラメータを、負荷均衡部における種々の要因の所望の重みを表す、ユーザが定めたパラメータと共に用いる。各サーバについて、ＣＰＵ仕様、メモリ仕様を追跡し、更に、全てのサーバに跨るシステムへのアクティブな接続の総数を追跡する。一実施形態では、均衡部は、サーバにかかる負荷を、サーバおよび現在のＣＰＵの処理能力ならびにメモリ使用度の関数として計算し、負荷が最も少ないサーバを、新たなユーザ接続を引き受けさせるために選択する。この関数は、以下のように、ユーザが定めたパラメータによって線形に重み付けすることができる。
【００４９】
【数５】
2010252328.tif 000007
【００５０】
サーバは、任意の多数のユーザから新たなユーザ要求を受け入れることができ、本発明のシステム・アーキテクチャにおいては、ユーザの最大数を設定するものはない。しかしながら、実施形態によっては、ユーザ数が所与のシステムにおいて利用可能な資源を超過することもある。例えば、サーバ側ストレージへの帯域幅またはサーバ側ストレージからの帯域幅が飽和してくることもあり、サーバの処理パワーを超過することもある。長期的な解決策では、サーバのしかるべき資源を増大させるとするとよい。しかしながら、短期では、サーバは、編集精度に影響を及ぼさない程度に、各クライアントをホストするために用いられる帯域幅および／または処理資源を削減すればよい。例えば、サーバは一時的に各クライアントに送られるストリームのフレーム・レートを低下させる、および／またはサイズを縮小することができる。あるいは、クライアントが複雑な編集タスクを要求する場合、そのタスクの結果はリアル・タイムでは見ることができないことを、クライアントに知らせることもできる。一旦資源不足が解消したなら、サーバは通常の動作に戻ることができる。
【００５１】
前述のコンピュータ・システムは、コンピュータ・プログラミング言語、スクリプティング言語、またはアセンブラ言語でも用いてプログラム可能な汎用コンピュータ・システムとすることができる。また、コンピュータ・システムは、特別にプログラムされた、特殊目的ハードウェアであってもよい。汎用コンピュータ・システムでは、プロセッサは通例市販のプロセッサである。また、汎用コンピュータは、通例、オペレーティング・システムを有し、このオペレーティング・システムが他のコンピュータ・プログラムの実行を制御し、スケジューリング、デバッギング、入力／出力制御、アカウンティング、コンパイル、ストレージ割り当て、データ管理およびメモリ管理、ならびに通信制御および関係するサービスを提供する。
【００５２】
メモリ・システムは、通例、コンピュータ読み取り可能媒体を含む。この媒体は、揮発性または不揮発性、書き込み可能または書き込み不可能、および／または再書き込み可能または再書き込み不可能であってもよい。メモリ・システムは、通例では二進形態のデータを格納する。このようなデータは、マイクロプロセッサによって実行すべきアプリケーション・プログラム、あるいはディスクに格納されておりアプリケーション・プログラムによって処理する情報を定めることができる。本発明は、特定のメモリ・システムには限定されない。
【００５３】
本明細書において記載したようなシステムは、ソフトウェアまたはハードウェアまたはファームウェア、あるいはこれら３つの組み合わせで実現することができる。本システムの種々のエレメントは、個々でもまたは組み合わせても、１つ以上のコンピュータ・プログラム生産物として実現することができ、コンピュータによる実行のために、コンピュータ・プログラム命令がコンピュータ読み取り可能媒体に格納されている。プロセスの種々のステップは、このようなコンピュータ・プログラム命令を実行するコンピュータによって実行することができる。コンピュータ・システムは、マルチプロセッサ・コンピュータ・システムであってもよく、またはコンピュータ・ネットワークを通じて接続されている複数のコンピュータを含んでもよい。図２および図３に示すコンポーネントは、コンピュータ・プログラムの別個のモジュールであってもよく、または別個のコンピュータにおいて動作可能とすることができる、別個のコンピュータ・プログラムであってもよい。これらのコンポーネントによって生成されるデータは、メモリ・システムに格納し、コンピュータ・システム間で送信することができる。
【００５４】
以上、実施形態の一例について説明したが、以上のことは単なる例示であって限定ではないことは、当業者には明白なはずである。多くの修正および他の実施形態も、当業者の範囲内に入り、本発明の範囲に該当すると考える。
【図１】
2010252328.tif 000008
【図２】
2010252328.tif 000009
【図３】
2010252328.tif 000010
【図４】
2010252328.tif 000011
【図５】
2010252328.tif 000012
【外国語明細書】
2010252328000001.pdf