JP6861454B2 - 共有アセット及び個別化アセットからのストーリーボード指示ビデオ制作 - Google Patents

Description

実施形態は、一般的にはビデオ制作に関し、より詳細には、リッチストーリーボード指
示ビデオアセットの収集及び制作に関する。

プロフェッショナルなビデオ制作は従来、コストがかかり、時間がかかることがある。
従来の環境では、コンセプトが一人又は複数のフロントエンド専門家（例えば、ライター
及びディレクターのようなプレプロダクション専門家）に提供され、フロントエンド専門
家は、コンセプトをいかに伝達するか、及びどのビデオ及び／又は他のコンテンツを収集
し包含するかを決定する。次に、取得専門家（例えば、ディレクター、舞台デザイナー、
カメラオペレータ、照明デザイナー、サウンドデザイナー等）による任意の所望のビデオ
撮影を含め、コンテンツが取得される。コンテンツは、取得されると、バックエンド専門
家（例えば、ディレクター、ビデオエディター、及びレンダラーのようなポストプロダク
ション専門家）に渡されて、最終的なビデオ制作出力を生成する。各制作段階において、
対応する専門家は、受信した入力を所望の出力の形にしようとする。例えば、ディレクタ
ーは、少なくとも、コンセプトを満足させる良好な最終作品をカットするために必要にな
るものを取得しようとして、多数の映像を撮影しようとし、次に、映像が、ディレクター
のビジョンを満足させようとして、ポストプロダクションでカット編集される。これらの
手法を用いる場合、様々なプロセス段階を通して多くの専門家が使われる傾向があり、各
専門家は、追加の反復、映像の再撮影、再編集等で制作を更に複雑にせずに、提供された
入力から所望の出力を生成しようとする。

これらの従来の手法は、状況数の点で制限され得る。そのような一制限は、従来の手法
が、殆どではないにしろ多くの使用に関して法外な時間及び／又はコストがかかり得るこ
とである。ビデオ制作がより一般的になるにつれて、ビデオ制作が望まれるより多くの状
況が生じるが、十分な時間及び／又は資金を従来のプロフェッショナルなビデオ制作ワー
クフロー及び関連する専門家に対して費やすことは、非現実的又は不可能である。別のそ
のような制限は、従来の手法の最終的な出力が通常、上手くいけば提供されるコンセプト
を満たす単一のビデオ作品であることである。単一のコンセプトに準拠する多くの個別化
されたビデオ作品への要望がある、増大する数の状況が生じている。従来のワークフロー
は、共有専門家リソースから複数のビデオ作品を出力することの助けになる傾向は低く、
そうすることは高価であり、且つ時間がかかる傾向がある。さらに、従来の手法は、特に
、ビデオアセットが異なる人々により、異なる場所で、且つ／又は異なる時間で、異なる
技法等を用いて収集される場合、同様のコンセプトに従って複数の作品を作成することに
役立つ傾向を有さない。

特に、データリッチストーリーボードによって統制される仕様に従ってビデオ制作ワー
クフローの部分を自動的に推進するシステム及び方法が記載される。実施形態は、従来の
制作ワークフローの制作専門家の大半又は全てをフロントエンドストーリーボードフェー
ズに移そうとする新規のビデオ制作ワークフローの状況で動作する。例えば、コンセプト
、プレプロダクション、取得、ポストプロダクション、承認、及び／又は他の専門家は、
ワークフローのストーリーボードフェーズで協働して、コンセプト及び規則に従って単一
のデータリッチストーリーボードを構築する。リッチストーリーボードは、ワークフロー
の部分を自動化し、一貫して繰り返すことができるように、ワークフローにわたり仕様を
推進するデータフレームワークで生成され、記憶される。例えば、リッチストーリーボー
ドは、ユーザ（「ストーリーメーカー」）から個別化ストーリーアセットの取得及び事前
監査の自動化コーチ（例えば、ウィザードアプリケーション）の生成を推進する。次に、
リッチストーリーボードは、それぞれがリッチストーリーボードのコンセプト、規則、及
び仕様に準拠する複数の個別化ビデオ作品へのアセットの自動レンダリングを推進するこ
とができる。

１組の実施形態によれば、リッチストーリーボードからビデオ作品を生成する方法が提
供される。本方法は、幾つかのビデオ作品に使用する制作仕様及びストーリービートシー
ケンスを定義するコンピュータ可読リッチストーリーボードを識別することであって、各
ストーリービートは１組のストーリービートアセットを含み、ストーリービートアセット
の第１の部分は、共有アセットデータに関連付けられた共有ストーリービートアセットで
あり、ストーリービートアセットの第２の部分は、アセット取得仕様に関連付けられた個
別化ストーリービートアセットである、識別することと、各個別化ストーリービートアセ
ットについて、アセット収集仕様に従って個別化アセットデータを取得するように動作可
能なコンピュータ実施アセット取得コーチを生成することと、コンピュータ実施アセット
取得コーチを介して、各個別化ストーリービートアセットの個別化アセットデータを受信
することと、ストーリービートシーケンスに従ってビデオ作品をレンダリングすることが
できるように、各個別化ストーリービートアセットの個別化アセットデータをレンダリン
グシステムに通信することであって、各共有ストーリービートアセットは、制作仕様及び
それに関連付けられた共有アセットデータに従ってレンダリングされ、各個別化ストーリ
ービートアセットは、制作仕様及びそれに関連付けられた個別化アセットデータに従って
レンダリングされる、通信することを含む。幾つかのそのような実施形態は、非一時的な
プロセッサ可読媒体に常駐し、プロセッサ可読命令を有するコンピュータプログラム製品
を含み、プロセッサ可読命令は、実行されると、プロセッサに本方法を実行させる。

別の組の実施形態によれば、リッチストーリーボードに従って生成されるビデオ作品で
使用される個別化アセットを取得するストーリーメーカーシステムが提供される。本シス
テムは、コンピュータ実施アセットコーチングサブシステムと、コンピュータ実施アセッ
ト監査サブシステムとを含む。コンピュータ実施アセットコーチングサブシステムは、幾
つかのビデオ作品に使用する制作仕様及びストーリービートシーケンスを定義するリッチ
ストーリーボードに従って生成されるアセット取得仕様を受信することであって、各スト
ーリービートは１組のストーリービートアセットを含み、ストーリービートアセットの第
１の部分は、共有アセットデータに関連付けられた共有ストーリービートアセットであり
、ストーリービートアセットの第２の部分は、アセット取得仕様及びアセット許容仕様に
関連付けられた個別化ストーリービートアセットである、受信することと、コンピュータ
実施グラフィカルアセット取得インタフェースを介して、各アセット収集仕様に従って各
個別化ストーリービートアセットの個別化アセットデータを取得することとを行うように
動作可能である。コンピュータ実施アセット監査サブシステムは、アセットコーチングサ
ブシステムと通信し、個別化アセットデータを監査して、個別化アセットデータがアセッ
ト許容仕様に準拠するか否かを判断するように動作可能である。コンピュータ実施アセッ
トコーチングサブシステムは、個別化アセットデータがアセット許容仕様に準拠する場合
、ストーリービートシーケンスに従ってビデオ作品をレンダリングすることができるよう
、各個別化ストーリービートアセットの個別化アセットデータを通信するように更に動作
可能であり、各個別化ストーリービートアセットは、制作仕様及びそれに関連付けられた
個別化アセットデータに従ってレンダリングされる。

更に別の組の実施形態によれば、リッチストーリーボードに従って生成されるビデオ作
品で使用する個別化アセットを取得するエージェンシーシステムが提供される。本システ
ムは、ストーリーバインストーリーボードサブシステムと、ストーリーバインレンダリン
グサブシステムとを含む。ストーリーバインストーリーボードサブシステムは、幾つかの
ビデオ作品に使用する制作仕様及びストーリービートシーケンスを定義するコンピュータ
可読リッチストーリーボードを生成することであって、各ストーリービートは１組のスト
ーリービートアセットを含み、ストーリービートアセットの第１の部分は、共有アセット
データに関連付けられた共有ストーリービートアセットであり、ストーリービートアセッ
トの第２の部分は、アセット取得仕様に関連付けられた個別化ストーリービートアセット
である、生成することと、コンピュータ実施アセットコーチングサブシステムにアセット
取得仕様を通信することであって、コンピュータ実施アセットコーチングサブシステムは
、グラフィカルアセット取得インタフェースを介して、各アセット収集仕様に従って各個
別化ストーリービートアセットの個別化アセットデータを取得するように動作可能である
、通信することを行うように動作可能である。ストーリーバインレンダリングサブシステ
ムは、コンピュータ実施アセットコーチングサブシステムから、個別化ストーリービート
アセットの個別化アセットデータを受信することと、各共有ストーリービートアセットを
制作仕様及びそれに関連付けられた共有アセットデータに従ってレンダリングするととも
に、各個別化ストーリービートアセットを制作仕様及びそれに関連付けられた個別化アセ
ットデータに従ってレンダリングすることにより、ストーリービートシーケンスに従って
ビデオ作品をレンダリングすることとを行うように動作可能である。

本開示を添付図と併せて説明する。

様々な実施形態による、ネットワークを介して複数のストーリーメーカーシステムと通信するエージェンシーシステムを有するビデオ制作環境の一実施形態のブロック図を示す。 幾つかの従来技術による実施態様による、従来のビデオ制作ワークフローの流れ図を示す。 様々な実施形態による新規のビデオ制作ワークフローの流れ図を示す。 様々な実施形態による、２つの例示的なストーリーバイン間でアセットを共有する、図３のワークフローのようなビデオ制作ワークフローの流れ図を示す。 様々な実施形態による、リッチストーリーボードからストーリーバインビデオを制作するために異なるタイプの情報を交換する様々なサブシステムを有する例示的なビデオ制作環境のブロック図を示す。 様々な実施形態と併用される例示的なアセットコーチサブシステムのコーチングインタフェースからの画面例を示す。 様々な実施形態による、１つ若しくは複数のシステム又はシステムの１つ若しくは複数の構成要素を実施する例示的な計算システムを示す。 様々な実施形態による、リッチストーリーボードによって定義される仕様を使用する、ビデオ作品を指示する例示的な方法の流れ図を示す。 様々な実施形態による、個別化ストーリービートアセットデータを取得する例示的な方法の流れ図を示す。

添付図では、同様の構成要素及び／又は特徴は同じ参照ラベルを有することができる。
さらに、同じタイプの様々な構成要素は、参照ラベルの後に、同様の構成要素を区別する
第２のラベルが続くことによって区別することができる。第１の参照ラベルのみが本明細
書で使用される場合、その説明は、第２の参照ラベルに関係なく、同じ第１の参照ラベル
を有する同様の構成要素の任意の１つに当てはまる。

パーソナル計算力が増大するにつれて、より多くの情報が、ビデオを使用してより多数
のプラットフォームを通して消費されている。したがって、フルスケール作品（例えば、
映画、テレビ番組、ドキュメンタリー等）からショート形態の作品（例えば、ビデオブロ
グ、広告、ビデオカード及びビデオ招待状等）までの状況で高品質ビデオ作品を作成する
要望が増大している。通常、ビデオ作品を生成したいエンドユーザは、限られた選択肢を
有する。選択肢の範囲の一端では、エンドユーザは、ビデオ映像を撮影し、且つ／又は他
の様式で収集し、消費者レベルソフトウェアを使用して、最終作品（例えば、ビデオクリ
ップの事後再編成、シーン遷移の追加、音楽の追加等）を制作することができる。このタ
イプの手法は費用効率的である傾向があるが、結果として生成される作品はプロフェッシ
ョナルに見えない傾向がある。選択肢の範囲の他端では、エンドユーザは、ビデオ制作専
門家を雇い、コンセプトを作成し、映像を撮影して収集し、映像を編集し、プロフェッシ
ョナルなビデオ制作ソフトウェア及びハードウェアを使用して最終的なビデオ作品を制作
（例えば、レンダリング）することができる。このタイプの手法では、プロフェッショナ
ルに見える結果が生成されるが、コストがかかり、時間がかかる傾向がある。

本明細書に記載の実施形態は、非プロフェッショナルに見えるビデオ作品が不十分であ
るか、又は望ましくなく、従来のプロフェッショナルなビデオ制作ワークフローを使用す
ることに法外なコスト及び／又は時間がかかる（又は他の様式で非現実的であるか、又は
望ましくない）状況に対処する。国の株式仲介ファームが数百又は数千のエージェントを
有し、ウェブサイトに各エージェントからのビデオ紹介を有したいと考える。さらに、各
ビデオをプロフェッショナルに見せるのみならず、一貫した見た目及び感じを有すること
も望む（例えば、特定の共通するグラフィックス、配色、話の流れ、マーケティング及び
ブランディング目的への準拠等）。従来のプロフェッショナルなワークフローに従って各
エージェントのビデオをプロフェッショナルに制作することは、高価であり、時間がかか
る。さらに、特に、エージェントが地理的に多様であり、且つ／又はエージェンシーが異
なる時間に参加する場合、ビデオ作品にわたって一貫性を制御することは困難であり、高
価でありがちである。

実施形態は、従来の制作ワークフロー全体を通して使われる傾向がある専門家（例えば
、取得専門家及びポストプロダクション専門家）の多く又は全てをフロントエンドに移そ
うとする新規のビデオ制作ワークフローの状況で動作する。幾つかの実施形態によれば、
コンセプト、プレプロダクション、取得、ポストプロダクション、承認、及び／又は他の
専門家は、ワークフローのストーリーボードフェーズで協働して、コンセプト及び規則に
従って単一のデータリッチストーリーボードを構築する。リッチストーリーボードは、ワ
ークフローの部分を自動化し、一貫して繰り返すことができるように、ワークフローにわ
たって仕様を推進するデータフレームワークで生成され記憶される。例えば、リッチスト
ーリーボードは、ユーザ（「ストーリーメーカー」）から個別化ストーリーアセットを取
得し事前監査する自動コーチ（例えば、ウィザードアプリケーション）の生成を推進する
。次に、ストーリーボードは、それぞれがリッチストーリーボードコンセプト、規則、及
び仕様に準拠した複数の個部化されたビデオ作品へのアセットの自動レンダリングを推進
することができる。

以下の説明では、様々な実施形態の完全な理解を提供するために、多くの具体的な詳細
が記載される。しかし、これらの具体的な詳細なしで本発明を実施可能なことを当業者は
認識すべきである。場合によっては、本発明を曖昧にしないように、回路、構造、及び技
法については詳細に示していない。

図１を参照して、様々な実施形態による、ネットワーク１４０を介して複数のストーリ
ーメーカーシステム１２０と通信するエージェンシーシステム１０５を有するビデオ制作
環境１００の一実施形態のブロック図を示す。実施形態により、エージェンシーは、全て
事前定義されるデータリッチストーリーボードに従って、複数のストーリーメーカーから
の個別化データの取得を制御するとともに、ストーリービートシーケンスにわたって共通
の見た目及び感じを有する複数のストーリーバインビデオを制作する際のそのデータの使
用を制御することができる。本明細書で使用される場合、「エージェンシー」は一般に、
１つ又は複数のストーリーバインビデオ作品の制作を目的として、リッチストーリーボー
ドをそれ自体で、又は代理として作成する任意の個人又はエンティティを指すことが意図
される。「リッチストーリーボード」は、幾つかのコンピュータ可読仕様としての、エー
ジェンシー及び／又は他からの幾つかの規則、コンセプト、及び他の入力を表す。例えば
、リッチストーリーボードは、制作仕様、アセット収集仕様、監査仕様等を含む。リッチ
ストーリーボードは幾つかの（例えば、シーケンスになった）「ストーリービート」も含
み、各ストーリービートは、１組のストーリービートアセット及びレイアウト仕様（例え
ば、位置、サイズ、形状、透明度、遷移、レイヤ等）として、最終的なストーリーバイン
ビデオ作品の部分（例えば、クリップ、セグメント、ビネット等）を表す。各ストーリー
ビートでの「ストーリービートアセット」は、ビデオデータ、テキストデータ、オーディ
オデータ、及び／又は任意の他の適するデータを含むことができる。各リッチストーリー
ボードでは、ストーリービートのうちの少なくとも幾つかは、「個別化ストーリービート
」であり、個別化ストーリービートの場合、アセットのうちの少なくとも幾つかは「個別
化アセット」である。リッチストーリーボードは、どのストーリービートアセットが個別
化アセットであるかを定義し、各個別化アセットに１つ又は複数のアセット取得基準を関
連付ける。個別化ストーリービートアセットデータは、アセット取得基準に従って「スト
ーリーメーカー」（エンドユーザ）から取得される。他のストーリービートアセットは、
同じリッチストーリーボードから生成される複数のストーリーバインビデオ作品にわたっ
て使用されることが意図されるという点で、「共有ストーリービートアセット」である。
例えば、共有ストーリービートアセットは、特に特定のリッチストーリーボード等と併用
されるように生成される事前記憶アセットのプールから取得することができ、それにより
、同じリッチストーリーボードから生成されるストーリーバインビデオ作品のうちの幾つ
か又は全ては、特定の所望の見た目及び感じを具現する。上述した用語は、本明細書に提
供される実施形態の説明の文脈の中で更に理解されよう。

エージェンシーシステム１０５は、ストーリーバインストーリーボードサブシステム１
１０と、ストーリーバイン監査サブシステム１７０と、ストーリーバインレンダリングサ
ブシステム１９０とを含む。ストーリーバインストーリーボードサブシステム１１０は、
幾つかのコンピュータ可読仕様として、幾つかの規則、コンセプト、及び他の入力を表す
データリッチストーリーボード１１５を生成する。例えば、コンセプト専門家（例えば、
ライター及びディレクター）が、高レベルストーリーコンセプト及びフローの定式化を開
始する。プレプロダクション専門家（例えば、ディレクター、舞台及び照明デザイナー、
ブランディング及びマーケティング専門家等）が、高レベルコンセプト及びフローを、そ
れぞれが関連付けられたタイミング（例えば、タイミング範囲、同期情報等）、遷移、ス
トーリービートアセット等を有するストーリービートに成熟化させる。共有ストーリービ
ートアセットによっては、既に利用可能なものもあれば、指定且つ／又は他の様式で生成
されるものもある。個別化ストーリービートアセットが望まれる場合、どのデータが望ま
れるか、データをいかに収集すべきか、収集されたデータをいつ及び／又はいかに承認す
べきか等を定義する仕様が作成される。ポストプロダクション専門家（例えば、レンダリ
ング及び編集専門家）は、コンセプト及びプレプロダクション専門家と協働して、ストー
リービートをいかにレンダリングし、編集し、承認すべきか等の制作仕様を開発する。こ
れら及び／又は他のタイプの仕様のうちの幾つか又は全ては、リッチストーリーボード１
１５を構成するコンピュータ可読仕様に定式化される。このようにして、リッチストーリ
ーボード１１５に従って、略全体の制作ワークフローを自動化し、指示することができる
。

リッチストーリーボード１１５は、ネットワーク１４０を介して１つ又は複数のストー
リーメーカーシステム１２０に通信される。各ストーリーメーカーシステム１２０は、ア
セットコーチサブシステム１３０を含む。アセットコーチサブシステム１３０は、個々の
ストーリーメーカーに、ストーリーバインビデオ作品１９５の作成に使用する個別化スト
ーリービートアセットデータ１３５を提供するようコーチングするように構成される。幾
つかの実施形態では、ストーリーメーカーシステム１２０はアセット監査サブシステム１
５０を含み、このサブシステムは、ストーリーバインビデオ作品１９５への使用を許可す
る前に、提供されたストーリービートアセットデータ１３５を監査する。幾つかの実施態
様では、アセット監査サブシステム１５０は、エージェンシーシステム１０５から受信さ
れるリッチストーリーボード１１５に従って定義されるアセット取得仕様及び／又はアセ
ット監査仕様に従って、提供されたストーリービートアセットデータ１３５を自動的に監
査する。

取得（例えば、監査）された個別化ストーリービートアセットデータ１３５は、エージ
ェンシーシステム１０５のうちの１つ又は複数のサブシステムに通信される。幾つかの実
施態様では、ストーリービートアセットデータ１３５はストーリーバイン監査サブシステ
ム１７０に通信され、ここで、手動及び／又は自動的にそれだけで、及び／又はストーリ
ービートの他のアセットのコンテキストで監査される。例えば、ストーリービートの事前
レンダリングバージョンは、ストーリーバイン監査サブシステム１７０を介してストーリ
ービートをレビューし事前承認することができる監査人員に通信される。他の実施態様で
は、ストーリービートアセットデータ１３５はストーリーバインレンダリングサブシステ
ム１９０に通信され、そこで、ストーリービート、１組のストーリービート、又は全体ス
トーリーバインビデオ作品１９５にレンダリングされる。例えば、個別化ストーリービー
トアセットデータ１３５及び共有ストーリービートアセットデータは、リッチストーリー
ボード１１５によって定義される制作仕様に従ってレンダリングされて、最終的なビデオ
作品、ドラフトビデオ作品（例えば、プルーフ、低解像度バージョン等）等を生成する。
次に、レンダリングされたビデオ作品をストーリーバイン監査サブシステム１７０に通信
して、更に監査（例えば、手動及び／又は自動監査）することができる。ストーリーバイ
ン監査サブシステム１７０は、アセットの更なる取得が望ましいか否か、アセットの再取
得が望ましいか否か、最終的なストーリーバインビデオ作品をリリースすることができる
か否か等を判断することができる。最終的なストーリーバインビデオ作品１９５は、記憶
し、インターネットに公開し、又は任意の他の所望の様式で使用することができる。

ビデオ制作環境１００の実施形態は、任意の適するネットワークアーキテクチャで実施
することができる。例示的な一実施態様では、エージェンシーシステム１０５のサブシス
テムは全て同じ場所に配置される。例えば、サブシステムは全て、単一の計算環境の一部
として、単一のローカルエリアネットワーク内で、単一のサーバ又はサーバ群内等で実施
し得る。他の実施態様では、エージェンシーシステム１０５のサブシステムのうちの幾つ
か又は全ては、互いからリモートである。例えば、単一の計算環境を、ストーリーバイン
ストーリーボードサブシステム１１０及びストーリーバイン監査サブシステム１７０をア
プリケーションとして含むように構成することができ、一方、ストーリーバインレンダリ
ングサブシステム１９０は、公衆又は私設ネットワークを介して他のサブシステムと通信
するリモートクラウドベースのレンダリング環境で実施される。エージェンシーシステム
１０５は、任意の適するタイプのネットワーク１４０を介してストーリーメーカーシステ
ム１２０と通信することができる。例えば、ネットワーク１４０は、公衆及び／又は私設
ネットワーク、有線及び／又は無線ネットワークリンク等を含むことができる。各ストー
リーメーカーシステム１２０は、任意の適する装置又はシステムで実施することができる
。幾つかの実施態様では、ストーリーメーカーシステム１２０は、コンピュータ、スマー
トフォン、タブレット等の固定又はモバイルユーザ装置で実施される。他の実施態様では
、ストーリーメーカーシステム１２０は、ビデオカメラのようなコンテンツ取得装置のア
プリケーションとして実施される。例えば、ビデオ機能を有するスマートフォン又はプロ
フェッショナルなビデオカメラは、アセットコーチサブシステム１３０及び／又はアセッ
ト監査サブシステム１５０を含むアプリケーションを実行するように構成することができ
る。

説明のために、不動産仲介エージェンシーが、各エージェントからの紹介ビデオをウェ
ブサイトで公開したい。仲介エージェンシーは地理的に多様であり、異なる性格を有し、
強調する異なる技能及び統計を有する。仲介エージェンシーは、それらの違いを強調した
いが、まとまり感、プロフェッショナル性、及びブランドも伝達したい。さらに、特に仲
介エージェンシーは常にチームに加入離脱し、各仲介エージェンシーに関連付けられた情
報は経時変化するため、媒体エージェンシーが、一貫性を有し、費用効率的でもありなが
ら、個別化され、動的なようにエージェントビデオを生成し変更可能なことが重要である
。

仲介エージェンシーは、ストーリー構築者を雇い、複数のビデオにわたって維持される
コンセプトを作成する。ストーリー構築者（様々なコンセプト、プレプロダクション、ポ
ストプロダクション、及び／又は他の専門家を含む）は、エージェンシーのマーケティン
グチーム及び他の人員と協働して、エージェントビデオのリッチストーリーボード１１５
を作成する。各エージェント紹介ビデオは、一貫したプロフェッショナルな見た目及び感
じ（グラフィカル要素、時系列、レイアウト、配色等）を提供する、全てのビデオに共通
する多くの要素を含むように構築される。しかし、各ビデオは、各エージェントに固有の
個別化部分（例えば、独自のグラフィックス、ビデオセグメント、情報リスト等）を包含
するようにも構築される。

リッチストーリーボード１１５は、アセットコーチサブシステム１３０を使用して環境
の構築を促進し、アセットコーチサブシステム１３０を通して、各仲介エージェント（ス
トーリーメーカー）は、ストーリーメーカーシステム１２０を通しての所望のストーリー
ビートアセットデータ１３５の提供を通してコーチングされる。例えば、ある画面は、エ
ージェントにテキスト欄に記入する（例えば、氏名、場所、プロフィール等）ように求め
、別の画面は、エージェントにビデオカメラを３フィート離れて配置し、家族の家の販売
に対するエージェントの哲学について２０秒間話すように求める。各仲介エージェントか
らのストーリービートアセットデータ１３５は、アセット監査サブシステム１５０を使用
して監査して、入力が事前定義される許容基準（例えば、データフォーマット、画質、照
明品質、持続時間等）を満たすか否かを判断することができる。満たさない場合、仲介エ
ージェントに再試行を求めることができる。

仲介エージェントのストーリービートアセットデータ１３５が取得（例えば、許容）さ
れると、これを共有アセット及び他のリッチストーリーボード情報（例えば、制作仕様）
と組み合わせて、ストーリーバインレンダリングサブシステム１９０を使用してストーリ
ーバインビデオ作品１９５を自動的にレンダリングすることができる。例えば、個別化ア
セットは、追加のバックエンド編集又は他の処理の必要が殆ど又は全くない状態で、リッ
チストーリーボード１１５によって指示される任意の所望の時系列、音楽、グラフィック
ス、遷移、及び／又は他の特徴（例えば、静的特徴及び／又は動的特徴）を有するプレコ
ンセプト化されたビデオ作品にメッシュ化される。他の仲介エージェントが、各自のスト
ーリービートアセットデータ１３５を取得し終えると、ストーリーバインビデオ作品１９
５は、同じリッチストーリーボード１１５に従ってストーリーバインレンダリングサブシ
ステム１９０を使用してレンダリングすることができる。各仲介エージェンシーは、各自
のストーリービートアセットデータ１３５を異なる方法（例えば、プロフェッショナルな
ビデオグラファー又はスマートフォンカメラを使用して）、異なる場所、異なる時間等で
取得し得るが、略一貫した見た目の、各仲介エージェントからのストーリービートアセッ
トデータ１３５のセットが生成されるようにアセット収集をコーチングし監査することが
できる。したがって、リッチストーリーボード１１５は、個別化アセットを使用して、高
レベルのコンセプト及び制作目的を保ちながら、任意の数のストーリーメーカーの一貫し
た制作品質のストーリーバインビデオ１９５を出力することに役立つ。

本明細書で考察されるようなビデオ制作環境を用いて、幾つかの特徴を実現することが
できる。そのような一特徴は、制作コストを多くのビデオ作品にわたって拡散（例えば、
ならす）ことができることである。例えば、従来のビデオ制作ワークフローからの高価な
専門技能が、リッチストーリーボード１１５の作成に使用される場合であっても、それと
同じリッチストーリーボード１１５を使用して、専門家の介入が略又は全くない状態で、
複数のビデオの制作を指示することができる。別の特徴は、各ストーリービートアセット
（例えば、共有されるか、それとも個別化されるかに関係なく）にリッチ階層メタデータ
スタックを関連付けることができることである。例えば、個別化ストーリービートアセッ
トに、許容仕様（例えば、照明、画質、持続時間の閾値等）、役割仕様（例えば、ビデオ
アセットをストーリーメーカーによって承認することができるか否か、又は特定の権限を
有する誰かによって承認される必要があるか否か）、制作仕様（例えば、ストーリーボー
ド内のコンテキスト、シーケンス、フォアグラウンド、又はバックグラウンドレベル、透
明度、遷移等を定義する属性）、取得仕様（例えば、プロンプト命令、コーチングページ
レイアウト命令等）、データ階層内の位置（例えば、特定のエージェンシーの特定の部門
の特定のエージェントの特定のビデオ等）等を関連付けることができる。

別の特徴は、リッチストーリーボード１１５の指示に従って個別化ストーリービートア
セットが取得されるが、個別化ストーリービートアセットが、一部をなすリッチストーリ
ーボード１１５及び／又はストーリーバインビデオ作品１９５から独立して「ライブ」で
あることである。例えば、共有アセット及び個別化アセットは、リッチストーリーボード
１１５に従ってストーリーバインビデオ作品１９５に動的にレンダリングすることができ
、後に、リッチストーリーボード１１５への変更、メタデータ、ストーリービートアセッ
トデータ１３５等に従ってリミックスすることができる。説明のために、上記例の仲介エ
ージェンシーのエージェントが新しい状態に移ると考える。各ストーリーアセットは最終
的なビデオ作品とは別個であるため、エージェントの状態を参照する個別化アセットを更
新する（例えば、手動又は自動的に）ことができ、比較的少ない労力でビデオ作品を再レ
ンダリングすることができる。別の関連する特徴は、リッチストーリーボード１１５が、
低レベルストーリービートアセットデータ１３５に関連する収集、承認、及び／又は他の
タスクへの高レベルビジネス規則等の適用に役立つことである。リッチストーリーボード
１１５は、定義されたアセット（例えば、特定の共有又は個別化グラフィック、ビデオセ
グメント、テキスト要素等）の取得を推進することができるが、取得し、且つ／又は１つ
又は複数のアセットを変更するのはどの組のアセットかを動的に決定するビジネス規則を
定義することもできる。例えば、仲介エージェントは、ウィザードを介して個別化アセッ
トとしてオフィスの郵便番号を入力する。ビデオ作品がレンダリングされる場合、バック
グラウンドに地図を表示するビデオの共有アセットは自動的に、仲介エージェントの郵便
番号によってカバーされる地図の領域を強調表示する。

これら及び他の特徴は、本明細書での様々な実施形態の説明に鑑みて、ビデオ制作ワー
クフローへの従来の手法と比較してより十分に理解されよう。図２を参照して、幾つかの
従来技術による実施態様による従来のビデオ制作ワークフロー２００の流れ図を示す。ワ
ークフロー２００は、幾つかのフェーズを含み、それらのフェーズへの幾つかの典型的な
入力専門技能及びそれらのフェーズからの出力を示す。フェーズの名称は単なる例示を意
図され、現実世界のワークフローは、フェーズの適宜重複、フェーズ内及びフェーズ間の
反復、フェーズの並列実行等を包含する傾向がある。異なるタイプの制作が異なるタイプ
の専門技能（又は異なるタイトルを有する同様の専門技能）異なる方法で利用するため、
フェーズに属する専門技能も単なる例示を意図される。

示されるように、従来のワークフローは、ビデオ制作のコンセプトがコンセプトデザイ
ナー２１３によって生成されるコンセプトフェーズ２１０で開始される。コンセプトデザ
イナー２１３は、エージェンシー人員、マーケティング専門家、広告専門家、ライター、
及び／又は任意の他の適する個人又はエンティティであることができる。例えば、コンセ
プトは、台本若しくは脚本、又は１組の高レベルコンセプト目的（例えば、ブランディン
グ目的等）として具現し得る。コンセプトフェーズ中、予算及びビジネス規則等の他の規
則を決定することもできる。コンセプトはプレプロダクションフェーズ２２０でも更に作
成され、その間、ライター２２３、ディレクター２２５、及び／又は任意の他の適する個
人又はエンティティは、基本ストーリーボード２７０を生成する。基本ストーリーボード
２７０は、ストーリーコンセプトを時系列上の１組の「ショット」に分割することができ
る。幾つかの場合、ライター２２３、ディレクター２２５、及び／又は他は、基本ストー
リーボード２７０を使用して、ロケーション設定、俳優、小道具、ショットタイプ（例え
ば、カメラ位置、アングル等）、エフェクト（例えば、照明、カメラ移動、コンピュータ
グラフィックス等）等についての計画を用いて各ショットをコンセプト化する。

プレプロダクションフェーズ２２０後、基本ストーリーボード２７０はビデオ制作出力
２９０に変えられる。アセット収集フェーズ２３０中、ディレクター２２５は俳優２３３
、デザイナー２３５（例えば、照明、舞台、小道具、エフェクト等の）、機器オペレータ
２３７（例えば、カメラオペレータ、グリップ等）、及び／又は任意の他の適する個人又
はエンティティと協働して、各ショットに必要なアセットを収集することができる。例え
ば、各ショットが準備され、撮影される。通常、全ての俳優２３３、デザイナー２３５、
機器オペレータ２３７、及び／又は他をシーンの再撮影のために呼び戻す必要性を回避す
るために、事後編集（例えば、カッティング、組み立て等）の計画で必要なよりもかなり
多くの映像が収集される。ポストプロダクションフェーズ２４０中、全ての映像及び／又
は他の資料（例えば、コンピュータエフェクト等）を使用して、任意の有用なエディット
（例えば、プルーフ、プリエディット、最終カット等）を生成する。ディレクター２２５
及びデザイナー２３５は、エディタ２４５と協働して、映像を準備し（例えば、カット、
遷移、エフェクト等を決定し）、エフェクトを生成して適用し（例えば、音楽及びサウン
ドエフェクトを作曲して同期させ、コンピュータグラフィックス及び特殊効果を生成し、
照明及び／又は映像の他の側面を調整するなど）等を行うことができる。

エディットは、承認フェーズ２５０中にディレクター２２５及び監査人２５５によって
評価することができる。例えば、映像は、技術的問題（例えば、ショットの一貫性、照明
及びサウンドの明瞭さ等）及び／又は他の問題（例えば、エディットが初期コンセプト及
び規則をどの程度満たしているかなど）についてチェックすることができる。エディット
が承認されない場合、ポストプロダクションフェーズ２４０（又は潜在的に、アセット収
集フェーズ２３０）に戻すことにより、映像を再度カッティングするか、又は他の様式で
変更して、エディットが最終的に承認されると、マスタとして記憶することができる。マ
スタは、レンダリング専門家２６５によってレンダリングフェーズ２６０でレンダリング
することができる。例えば、マスタは所望のフォーマットに変換することができ、最終エ
ディット（例えば、クリーンアップ）等を適用することができる。

各フェーズは、幾つかのタイプの専門技法に関わり、その専門技能は多くの場合、多く
の異なるタイプの制作専門家２１５（例えば、ライター２２３、ディレクター２２５、デ
ザイナー２３５、機器オペレータ２３７、エディタ２４５、監査者２５５、レンダラー２
６５等によって提供される。したがって、制作専門技法は通常、ワークフローにわたって
使用され、これは、高価であり、スケジュールが難しく、反復が難しいなどのことがある
（例えば、映像が異なる時間及び／又は異なる場所で収集される場合）。さらに、フェー
ズに戻ること（例えば、再撮影、再編集等）は、対応する専門家を呼び戻し、潜在的にワ
ークフローの後のフェーズを繰り返すことを含み得る。

さらに、多くの場合、多数のコピー及びマスタから生成することができるが、従来のワ
ークフローの出力はそれでもなお、通常、１組のマスタ映像である。例えば、マスタを「
ディレクターズカット」版、「拡張」版、「ＴＶ向け」版、トレイラー等用に再カットす
ることができるが、バージョンは同じ映像、エフェクト等の単なる再エディット（例えば
、再カット等）である。単一のビデオ出力２９０への任意のかなりの変更は通常、新しい
アセット収集フェーズ２３０（再撮影及び／又は映像追加のために）に向けて俳優２３３
、デザイナー２３５、機器オペレータ２３７、及び／又は他を呼び戻すことを含む。その
場合であっても、新しいマスタの生成は、専門技能を召還し、ポストプロダクションフェ
ーズ２４０、承認フェーズ２５０、及び／又はレンダリングフェーズ２６０を再実行する
作業を含み得る。

これより図３を参照し、様々な実施形態による新規のビデオ制作フロー３００の流れ図
を示す。ワークフロー３００は、明確にするため、且つ特定の違いを強調するために、図
２に示される従来のワークフロー２００と同様のフォーマットで示されている。例えば、
図２と同様に、図３のワークフロー３００は、幾つかのフェーズを含み、それらのフェー
ズへの幾つかの典型的な入力専門技法及びそれらのフェーズからの出力を示し、簡潔にす
るために、同様の名称のフェーズ及び専門技法が使用される。しかし、従来のワークフロ
ー２００及び新規のワークフロー３００は、簡易化され、例示であることが意図され、本
明細書で考察される他の実施形態を限定するものとして解釈されるべきではない。

従来のワークフローのように、ワークフロー３００の実施形態は、ビデオ制作のコンセ
プトがコンセプトデザイナー２１３によって生成されるコンセプトフェーズ２１０で開始
される。幾つかの実施態様では、コンセプトは、ブランディング目的、ビジネス規則、イ
ンタラクティブ規則、制作規則等のような様々なタイプの高レベル概念目的を有する台本
又は脚本として具現される。図２の従来のワークフロー２００では、制作専門家２１５が
、残りのワークフローフェーズ全体を通して使われて、コンセプトを基本ストーリーボー
ド２７０に変換し、最終的に単一のマスタビデオ作品２９０にする。新規のワークフロー
３００では、制作専門技能（及び対応する政策専門家２１５）の大半又は全ては、ストー
リーボード作成フェーズ３２０に前期投入される。従来の基本ストーリーボードを作成す
るのではなく、ストーリーボードフェーズ３２０の出力は、例えば図１を参照して上述さ
れるようなデータリッチストーリーボード１１５である。

ストーリーボードフェーズ３２０中、ライター２２３、ディレクター２２５、デザイナ
ー２３５、機器オペレータ２３７、エディタ２４５、レンダラー２６５、及び／又は任意
の他の適する個人又はエンティティの専門技能が協働して、改変プレプロダクションフェ
ーズ２２０’及び改変ポストプロダクションフェーズ２４０’のタスク並びに追加のタス
クを実行する。例えば、リッチストーリーボード１１５は、ストーリービートシーケンス
を用いて設計され、各ストーリーボードには、アセット選択、アセット収集仕様、アセッ
ト監査仕様、制作仕様等を含む幾つかの仕様が関連付けられる。仕様は、高レベルコンセ
プト及び規則を忠実に表現しようとしながら、ワークフローの後続フェーズがいかに処理
されるかの低レベル詳細を定義する。仕様の大半又は全ては、ワークフローの後続フェー
ズの完全又は部分的な自動実行に役立つコンピュータ可読仕様として、リッチストーリー
ボード１１５に記憶される。

リッチストーリーボード１１５が作成されると、後続フェーズはリッチストーリーボー
ド１１５の仕様によって指示される。アセット収集フェーズ３３０に進むことができ、リ
ッチストーリーボード１１５からのアセット収集、アセット承認、及び／又は他の仕様を
使用して、１つ又は複数のストーリーメーカー３３３からの共有アセット及び個別化アセ
ットの取得を指示する。これは、ディレクター２２５、デザイナー２３５、及び他の存在
なしで達成することができ、その理由は、それらの専門技能がリッチストーリーボード１
１５に捕捉されているためである。取得されたアセット及び／又は部分的又は完全なスト
ーリービートは、承認フェーズ３５０において監査することができる。承認はリッチスト
ーリーボード１１５の仕様によって指示されるが、様々な実施態様では、完全又は部分的
に自動化し得る（例えば、監査者２５５を用いて）。例えば、様々な制作専門家２１５及
び／又は他は、取得されたアセット、ストーリービート等を自動的且つ／又は手動で監査
する際に使用する許容基準をストーリーボードフェーズ３２０において事前定義すること
ができる。幾つかの実施態様では、ストーリーメーカー３３３は、提供されるデータを承
認することができるまで、反復タスクを通して所望のアセットデータを提供するようにコ
ーチングすることができる。

次に、レンダリングフェーズ３６０において、リッチストーリーボード１１５の制作仕
様に従って、承認されたストーリービートをレンダリングすることができる。例えば、レ
ンダリング専門家２６５は、任意のストーリービートが実際に取得される前に、ストーリ
ーボードフェーズ３２０において、ストーリービートがいかにレンダリング技法及び命令
（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）命令等）と対話す
べきかを決定することができる。幾つかの実施態様では、レンダリングされたビデオも、
最終化前に承認される。例えば、レンダリング設定を承認段階で調整することができる（
例えば、手動及び／又は自動）。専門技能がワークフロー全体に拡散して、単一のマスタ
ビデオ作品を制作するのではなく、示される新規のワークフロー３００は、専門技能を前
期投入して、リッチストーリーボード１１５を生成し、そこから、共通のコンセプトセッ
ト、規則等に従って、多くの個別化ビデオ作品（ストーリーバインビデオ１９５）を生成
することができる。

例示のために、従来の基本ストーリーボード２７０が、組織のサポーターが建物の前に
立ち、サポートを選んだ理由について話すショットを含むと考える。従来のワークフロー
によれば、様々な制作専門家２１５が、ストーリーボードショットのように見える場所を
準備し、シーンを撮影し、シーンを編集し、要素をシーンに追加し（例えば、グラフィッ
クスのオーバーレイ、サウンドの追加等）、シーンを承認するなどし得る。次に、追加の
労力及び専門技能を使用して、シーンを他のシーンに追加し、最終的なビデオ作品をレン
ダリングすることができる。組織が後に、同様のビデオを異なるサポーターに作成したい
場合、様々な制作専門家２１５はもう一度、ストーリーボードショットのように見える場
所を準備し、新しいシーンを撮影し、新しいシーンを編集し、要素を新しいシーンに追加
し、新しいシーンを承認し、新しいシーンを他のシーンに追加し、最終的なビデオ作品を
再レンダリングし得る。

リッチストーリーボード１１５は、基本レイアウト及び指針を提供する他、ビデオ映像
を提供することを通して、コンセプト及び規則に準拠してサポーターにいかにインタラク
ティブにコーチングするか、提供されたアセット（例えば、ビデオ映像及び他の資料）を
承認するか、それとも拒絶するかを自動的にいかに判断するか、各シーンで要素をいかに
追加し配置するか、シーン間でいかに遷移するか、シーンをいかに編集しレンダリングす
るか等を定義するコンピュータ可読仕様を含むことができる。例えば、サポーターとコン
タクトをとり、ビデオ映像を提供する前に、内部に効率的に埋め込まれた制作専門技能を
有するリッチストーリーボード１１５は既に作成されている。コーチングアプリケーショ
ンは、リッチストーリーボード１１５からの仕様を使用して、例えば、どこに立つか、カ
メラをどこに配置するか、どれくらいの大きさで話すか、話す期間等を含め、所望の映像
を提供することを通して、サポーターをインタラクティブにコーチングすることができる
。幾つかの実施態様では、リッチストーリーボード１１５の仕様は、１つ又は複数のシス
テムに通信されて、シーンの編集、シーンの構築（例えば、要素の追加等）、シーンの承
認、他のシーンへのシーンの追加、シーンを含む最終的なビデオ作品のレンダリング等を
自動的に指示する。例えば、エディタ２４５は、コンピュータ可読形態でリッチストーリ
ーボード１１５において、全てのシーンの全てのアセットが取得される前に、各シーンを
いかに編集すべきかを指定する。組織が後に、同様のビデオを新しいサポーターに作成し
たい場合、コーチングアプリケーションは、その新しいサポーターから新しい映像を取得
することができる。リッチストーリーボード１１５からの同じ仕様に従って新しい映像を
取得し監査することにより、新しい映像を、リッチストーリーボード１１５によって定義
される制作枠組みにまとまりをもって追加することができる。したがって、制作専門家２
１５からの追加のサポートが殆ど又は全くない状態で、新しい映像を包含するように、追
加のビデオ作品を生成することができる（例えば、自動的に）。

図４は、様々な実施形態による、２つの例示的なストーリーバイン４１０間でアセット
を共有する図３のワークフロー３００のようなビデオ制作ワークフロー４００の流れ図を
示す。示されていないが、コンセプトが、例えばコンセプトフェーズで生成されると仮定
する。第１のワークフロー４００ａが第１のストーリーボード作成フェーズ３２０ａで開
始され、第１のデータリッチストーリーボード１１５ａが生成される。リッチストーリー
ボード１１５ａは、第１のアセット収集フェーズ３３０ａ、第１の承認フェーズ３５０ａ
、及び第１のレンダリングフェーズ３６０ａを推進する仕様を定義する。示されるように
、アセット収集フェーズ３３０ａにより、幾つかのストーリーメーカーアセット４１５ａ
及び他のアセット４３５ａが生成される。例えば、ストーリーメーカーアセット４１５ａ
は、インタラクティブコーチングアプリケーションを通して収集された個別化アセットで
あり、他のアセット４３５ａは共有アセット及び／又は任意の他のアセットを含む。

ストーリーメーカーアセット４１５ａ及び他のアセット４３５ａは、リッチストーリー
ボード１１５ａの仕様に従って、承認フェーズ３５０ａにおいて監査される。ストーリー
ビートを結合してストーリーバインにすることができ、ストーリーバインは、リッチスト
ーリーボード１１５ａの制作仕様及び／又は他の仕様に従って、第１のレンダリングフェ
ーズ３６０ａにおいて１つ又は複数の第１のストーリーバインビデオ作品１９５ａにレン
ダリングすることができる。幾つかの実施態様では、承認フェーズ３５０ａは実際に、一
連の承認フェーズである。例えば、アセットは、リッチストーリーボード１１５ａによっ
て指定される承認基準に従って自動的に承認することができ、その後、リッチストーリー
ボード１１５ａの編集仕様、制作仕様、及び／又は他の仕様に従って各ストーリービート
１３５ａにすることができる。完全なストーリーバインの生成に使用する前に、ストーリ
ービート１３５ａを承認フェーズ３５０ａにおいて監査することもできる（例えば、個別
化ストーリービートアセットを有するストーリービートを個々に、又は群として、手動又
は自動的に監査することができる）。ストーリーバインも、レンダリング前に監査するこ
とができ、レンダリングされたストーリーバインビデオ作品１９５ａも監査することがで
きる。各承認フェーズ３５０ａは、完全又は部分的に手動であるか、それとも自動である
か、どの個人、エンティティ、又はシステムがそのフェーズを監査する権限を有するかな
どに関して異なり得る。

上述したように、単一のリッチストーリーボード１１５ａを使用して、個別化ストーリ
ービートアセットデータを多くのストーリーメーカーから取得し、共通コンセプトに従っ
て多くの対応する個別化ビデオ作品をレンダリングすることができる。このようにして、
リッチストーリーボード１１５ａ、関連付けられた高レベルコンセプト及び規則、並びに
その低レベル仕様は全て、リッチストーリーボード１１５ａから生成される、最終的にレ
ンダリングされるストーリーバインビデオ作品１９５ａの部分である任意の個別化ストー
リービートアセットデータから独立して（例えば、個別化ストーリービートアセットデー
タの取得前に）生成することができる。

さらに、幾つかの実施形態では、収集されたアセットデータは、個別化ストーリービー
トアセットデータであっても、アセットデータが最初に取得されたリッチストーリーボー
ド１１５の基準及びコンテキストから独立して存在することができる。各ストーリービー
トアセットは、アセットを定義し、属性を記述するなどの任意の所望の情報を定義するこ
とができる関連付けられたリッチメタデータスタックと共に記憶することができる。した
がって、共有ストーリービートアセット及び個別化ストーリービートアセットの両方を、
特定のストーリーボード内の複数のコンテキスト内又は複数のストーリーボード間で使用
することができる。

説明のために、第２のワークフロー４００ｂは第２のストーリーボード作成フェーズ３
２０ｂで開始され、第２のデータリッチストーリーボード１１５ｂが生成される。例えば
、第２のリッチストーリーボード１１５ｂは、同じエージェンシーであるが、異なるコン
セプトに従って生成される。ここでも、リッチストーリーボード１１５ｂは、第２のアセ
ット収集フェーズ３３０ｂと、第２の承認フェーズ３５０ｂと、第２のレンダリングフェ
ーズ３６０ｂとを推進する仕様を定義する。幾つかの実施態様では、第２のリッチストー
リーボード１１５ｂの全ての個別化アセットは、第１のリッチストーリーボード１１５ａ
で取得されたストーリーメーカーアセット４１５ａのプールからとられる。例えば、個別
化映像の幾つか又は全ては、第２のストーリーバイン４１０ｂのコンセプト及び関連付け
られたリッチストーリーボード１１５ｂに従って再カットされ、異なるシーケンス及びグ
ラフィカルコンテキストでレイアウトされる。

アセット収集フェーズ３３０ｂをなお行うことができ、このフェーズ中、共有及び／又
は他のアセット４３５ｂが取得され、且つ／又は生成される。それらの新しいアセットは
、関連付けられた第２のストーリービート１３５ｂの生成に使用される前に、第２の承認
フェーズ３５０ｂにおいて監査することができる（例えば、自動的に）。第２のストーリ
ービート１３５ｂは、第１のアセット収集フェーズ３３０ａ中に取得される個別化アセッ
トを含め、第２の承認フェーズ３５０ｂにおいて、第２のリッチストーリーボード１１５
ｂの基準に従って監査することができる。ここでも、ストーリービートを組み合わせて、
新しいストーリーバインにすることができ、新しいストーリーバインを、リッチストーリ
ーボード１１５ｂの制作仕様及び／又は他の仕様に従って、第２のレンダリングフェーズ
３６０ｂにおいて１つ又は複数の第２のストーリーバインビデオ作品１９５ｂにレンダリ
ングすることができる。

レストランが幾つかのビデオをウェブサイトに載せることを望むことを考える。幾つか
の所望のビデオは、自分自身、レストラン以外の興味、及び何故そのレストランで働くこ
とが好きなのかについて語る給仕者及び他の従業員のビデオである。ビデオコンセプトは
、インタビュー部分中、一貫したブランディング要素（例えば、配色、ロゴ配置、イント
ロ及びアウトロスプラッシュグラフィックス等）、最小の追加スクリーングラフィックス
で、レストラン外部の歩道でのカジュアルなインタビューのように見えることである。所
望の効果は、高度に個別化された作り込みが最小であり、それでもなおまとまりのある強
力なブランドを表現する見た目である。ウェブサイトに望まれる別のビデオは、レストラ
ンの一般的な広告であり、これは、多くのプロフェッショナルなグラフィックス及び他の
情報要素によって囲まれた、選択された従業員のインタビュービデオからのショートセグ
メントを含む。所望の効果は、過不足のない程度の従業員インタビュービデオからのカジ
ュアルな感じを維持する、強力なマーケティング力を有する高度に作り込まれた見た目で
ある。第１の組の従業員ビデオは、第１のワークフロー４００ａに従って生成することが
でき、関連する個別化アセットを第２のワークフロー４００ｂで再使用して、レストラン
の広告ビデオを生成することができる。

図５は、様々な実施形態による、異なるタイプの情報を交換して、リッチストーリーボ
ード１１５からストーリーバインビデオ１９５を生成する様々なサブシステムを有する例
示的なビデオ制作環境５００のブロック図を示す。上述したように、ビデオ制作環境５０
０の実施形態は、ストーリーバインストーリーボードサブシステム１１０と、ストーリー
バイン監査サブシステム１７０と、ストーリーバインレンダリングサブシステム１９０と
、アセットコーチサブシステム１３０と、アセット監査サブシステム１５０とを含む。コ
ンセプトデザイナー２１３及び制作専門家２１５及び／又は任意の他の個人又はエンティ
ティ（例えば、エージェンシー人員及びマーケティング専門家）は協働して、ストーリー
バインストーリーボードサブシステム１１０を介して、ストーリーコンセプト５０１及び
様々な規則をリッチストーリーボード１１５に成熟化させる。様々な規則は、ビジネス規
則５０３、インタラクティブ規則５０５、制作規則５０７、及び／又はリッチストーリー
ボード１１５の作成をガイドする任意の他の有用規則を含むことができる。

リッチストーリーボード１１５は、例えば、コンピュータ可読形態で様々なタイプの仕
様を定義する。仕様は、非常に詳細なレベルでのワークフロー指示を提供しながら、高レ
ベルストーリーバインコンセプト５０１及び規則を効率的に具現することができる。リッ
チストーリーボード１１５の実施形態は、コーチング仕様５２１、アセット収集仕様５２
３、アセット承認仕様５２５、役割仕様５２７、制作仕様５２９、及び／又は任意の他の
適する仕様を定義する。例えば、アセット収集仕様５２３は、アセットの取得、生成、及
び使用の支援として、アセット及び任意の有用な属性を定義することを含め、何が共有さ
れ、何が個別化されるか、及び／又は他のストーリービートアセットデータ５４３が望ま
れるかを定義することができる。コーチング仕様５２１は、個別化ストーリービートアセ
ット毎に、所望のストーリービートアセットデータ５４３を通してストーリーメーカー５
３９をインタラクティブにガイドするコーチ５３７及び／又はアセットコーチサブシステ
ム１３０を提供する情報を定義することができる。

アセットコーチサブシステム１３０の実施形態は、インタラクティブコーチングをスト
ーリーメーカー５３９に提供して、コーチング仕様５２１及びアセット収集仕様５２３に
従って個別化ストーリービートアセットデータを提供する。幾つかの実施態様では、アセ
ットコーチサブシステム１３０は、コーチングアセット５３５（例えば、標準ウィザード
レイアウト、標準仮想コーチ等）及びコーチングアプリケーションプログラミング仕様５
３３（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）コマンドセッ
ト）のプールを有す得る計算システムのアプリケーションである。コーチングアセット５
３５及びコーチングアプリケーションプログラミング仕様５３３は、任意の所望の個別化
ストーリービートアセットデータを取得するインタラクティブコーチング環境を構築する
枠組みを提供する。この枠組み並びにリッチストーリーボード１１５からのコーチング仕
様５２１及びアセット収集仕様５２３を使用して、完全なコーチング環境をアセットコー
チサブシステム１３０に構築することができる。幾つかの実施態様では、コーチング仕様
５２１及びアセット収集仕様５２３は、コーチングアセット５３５及びコーチングアプリ
ケーションプログラミング仕様５３３に準拠するコンピュータ可読フォーマットで提供さ
れ、したがって、アセットコーチサブシステム１３０は、殆ど又は全くの手動介入なしで
コーチングインタフェースを自動的に構築することができる。他の実施態様では、コーチ
ングインタフェースの構築は、例えば、コーチングアセット５３５、インタフェース要素
、ウィザードレイアウト等の設計及び／又はプログラミングを含め、幾らかの人的介入が
関わる。

アセットコーチサブシステム１３０の幾つかの実施態様は、仮想コーチ（例えば、コー
チングアセット５３５の一部として記憶されるライブコーチの標準記録、ストーリーボー
ド作成フェーズの一環として生成され、コーチング仕様５２１の一環として通信されるコ
ーチングアセット、コンピュータ生成コーチ等）のみを使用する。他の実施態様は、追加
又は代替として、ライブのインタラクティブコーチングを使用する。例えば、ライブテキ
スト及び／又はビデオチャットインタフェースが、コーチングインタフェースの一部とし
て提供され、それにより、ストーリーメーカー５３９は個々のコーチ５３７と対話するこ
とができる（例えば、コーチ５３７は、リッチストーリーボード１１５からの人間可読コ
ーチング仕様５２１によって指示される。アセットコーチサブシステム１３０の幾つかの
実施形態は更に、リッチストーリーボード１１５の役割仕様５２７に従って動作する。例
えば、役割仕様５２７は、誰が特定のストーリービートアセットのストーリーメーカー５
３９又はコーチ５３７であることができるかを統制（又はガイド）することができる。

例示のために、図６は、様々な実施形態と併用される例示的なアセットコーチサブシス
テム１３０のコーチングインタフェース６００からの画面例を示す。コーチングインタフ
ェース６００は、ビデオカメラを含むか、又はビデオカメラに結合されるタブレットコン
ピュータで実施し得る。コーチングインタフェース６００は、それぞれが様々なインタラ
クティブ要素を有する幾つかの領域を含む。例示的な一領域は、幾つかのビートアイコン
６１５を含むストーリービートシーケンス及びステータス領域６１０である。ストーリー
ビートアイコン６１５は、リッチストーリーボード１１５でのストーリービートシーケン
ス及びシーケンス中の各ストーリービートのステータスの概観を提供する。例えば、スト
ーリービートアイコン６１５ａは、「ストーリービート４」が取得され（データの一部の
サムネイル画像で示される）、承認された（ストーリービートアイコン６１５ａ内のチェ
ックマークで示される）ことを示し、ストーリービートアイコン６１５ｂは、「ストーリ
ービート５」が、取得する関連付けられた個別化ストーリービートアセットデータを有さ
ないことを示し、ストーリービートアイコン６１５ｃは、「ストーリービート７」が、関
連付けられた個別化ストーリービートアセットデータが現在取得されているビートを示す
。

別の例示的な領域は、インタラクティブアセット取得領域６２０である。インタラクテ
ィブアセット取得領域６２０は、アセット収集仕様５２５、コーチング仕様５２１等に従
って所望のアセットデータを取得する任意のインタラクティブ要素を含むことができる。
図示のシナリオでは、所望のストーリービートアセットは、Ｊｏｅの店の建物の前に立ち
、自己紹介する従業員ストーリーメーカーの正面クローズアップビューをフィーチャーし
たショートビデオである。インタラクティブアセット取得領域６２０は、所望の入力を提
供するようにストーリーメーカーをガイドするのに役立つ幾つかの例示的なインタラクテ
ィブコーチング要素を含む。そのような１つのインタラクティブコーチング要素は、カメ
ラ位置決めガイド６２５である。カメラ位置決めガイド６２５は、カメラが適宜位置決め
された場合、フィーチャーされるストーリーメーカーの頭及び肩が仮想的なストーリーメ
ーカーの頭及び肩の輪郭線と略一致するような（示されるように）サイズ及び位置の、仮
想的なストーリーメーカーの頭及び肩の太線の輪郭線であることができる。このようにし
て、ストーリーメーカー（又は映像を取得中の人が誰であれ）は、カメラがフィーチャー
されるストーリーメーカーに対して適切な距離、アングル等であることを直観的に知るこ
とができる。別のそのようなインタラクティブなコーチング要素は、コンテンツガイド６
２７である。コンテンツガイド６２７は、所望のコンテンツタイプをストーリーメーカー
に通知するのに役立つテキスト又は何らかの他のプロンプトであることができる。例示的
なコンテンツガイド６２７は、一般的なガイダンスをストーリーメーカーに与えるテキス
トボックス「笑って！カメラを見て。あなたの名前と、ここで何をしているかを話して」
である。

上述したように、任意のカメラ位置決めガイド６２５、コンテンツガイド６２７、及び
／又は他のタイプのインタラクティブコーチング要素が、リッチストーリーボード１１５
の仕様に従って生成される。例えば、仕様は、アセットコーチングアプリケーションのコ
ーチングＡＰＩに従って解釈して、各ストーリービートのデータが取得されているとき、
インタラクティブアセット取得領域６２０にカメラ位置決めガイド６２５を自動的に生成
することができるフォーマットで書かれた命令を含む。示されるシナリオのように、所望
の情報の小さな論理的セグメントとして（例えば、長いフォーマットのビデオ等としてで
はなく）ストーリービートを生成することが望ましいことがあることに留意することに価
値がある。これにより、経験の少ないストーリーメーカーにより、より少数のテイクで所
望の情報を取得することが可能になり、他のコンテキストでのストーリービートの再使用
を促進することができるなどである。

別の例示的な領域はコーチ領域６３０である。示されるように、コーチ領域６３０は、
適切な情報の提供を通して、ストーリーメーカーに話すライブ又は仮想コーチのオーディ
オ及び／又はビデオを含むことができる。コーチ領域６３０は、事前記録された情報（例
えば、何を提供するかストーリーメーカーに話すコーチの事前記録ビデオ、アセットに提
供される適切なコンテンツの事前記録例等）、ライブ情報（例えば、ライブオーディオ及
び／又はビデオチャットインタフェース）、及び／又は任意の他の適する情報を表示する
ことができる。上述したように、コーチ領域は、リッチストーリーボード１１５、コーチ
ングアセット、コーチングＡＰＩ等からの仕様を使用して自動的及び／又は手動で構築す
ることができる。

更に他の例示的な領域はナビゲーション領域６４０である。ナビゲーション領域６４０
は、コーチングインタフェース、アセット取得等をナビゲートする任意の有用なボタン、
制御機構、及び／又は他のインタラクティブ要素を含むことができる。示されるように、
ナビゲーション制御機構は、様々な他の領域の周囲及び様々な他の領域内に分散する。例
えば、インタラクティブアセット取得領域６２０及びコーチ領域６３０の下には、ファイ
ルにアクセスし、ヘルプを探し、データを記録し、データを再生し、カメラ設定を調整す
るなどのための１組のナビゲーションボタンである。幾つかの実施態様では、ナビゲーシ
ョン領域６４０の幾つか又は全ては、例えば、コーチングアセット、コーチングＡＰＩ、
及び／又はアセットコーチングアプリケーションの他のプロパティに従って、全てのスト
ーリービートの全てのコーチングインタフェースにわたって共通する。他の実施態様では
、ナビゲーション領域６４０の幾つか又は全ては、例えば、アプリケーションプリファレ
ンスに従ってストーリーメーカーによって構成可能である。更に他の実施態様によれば、
ナビゲーション領域６４０の幾つか又は全ては、リッチストーリーボード１１５の仕様に
従って自動的に生成される。

図５に戻ると、アセットコーチサブシステム１３０の出力はストーリービートデータ１
３５である。幾つかの実施形態によれば、ストーリービートデータ１３５は、ストーリー
ビートアセット５４３及び関連付けられたアセットメタデータ５４５を含む。一例では、
ストーリービートアセット５４３は、自己紹介するストーリーメーカー５３９のビデオで
ある。関連付けられたアセット収集仕様５２３、アセット承認仕様５２５、制作仕様５２
９、ストーリーメーカー情報（例えば、どのストーリーメーカー５３９に、取得されたア
セット、人口統計、又はストーリーメーカー５３９の所属が関連付けられるか等）等の幾
つかのアセットメタデータ５４５は、リッチストーリーボード１１５から取得又は導出す
ることができる。ステータス（例えば、アセットが取得され承認されたか否か）、取得さ
れた属性（例えば、実際の持続時間、カラー情報、解像度、サイズ、フォーマット等）、
追跡情報（例えば、アセットデータの承認前に幾つかのテイクが行われたか、いくつの仮
想及び／又はライブコーチングが使用されたか等）等の他のアセットメタデータ５４５は
、アセット収集及び／又は承認フェーズから取得又は導出することができる。

ストーリービートデータ１３５は、アセット監査サブシステム１５０に通信することが
できる。幾つかの実施態様では、アセット監査サブシステム１５０は、リッチストーリー
ボード１１５からのアセット承認仕様５２５に従ってストーリービートデータ１３５を自
動的に監査する自動システムである。例えば、アセット監査サブシステム１５０は、ビデ
オアセットが適切な解像度、持続時間、明度、フォーマット、組成等のものであるか否か
をチェックすることができる。追加の処理（例えば、画像、ボイス、及び／又は他の認識
技法）を使用して、ビデオアセットが所望のコンテンツを含むか否か、許容できないコン
テンツ（例えば、著作権保護された資料、不適切な言葉又は他の資料、法律又はビジネス
規則によって禁止された文章等）等を含むか否かを判断することができる。他の実施態様
では、アセット監査サブシステム１５０は人間の監査者を含む。アセット監査サブシステ
ム１５０の実施形態は、アセットコーチサブシステム１３０の一部として、アセットコー
チサブシステム１３０と同じ装置で、アセットコーチサブシステム１３０からリモートに
（例えば、公衆若しくは私設ネットワークを介してエージェンシーシステムの一部として
、インターネットを介してクラウドベースのアプリケーションの一部として等）、又は任
意の他の適する様式で実施することができる。

ストーリービートデータ１３５が承認されない場合、アセット監査サブシステム１５０
は、ストーリーメーカー５３９がストーリービートデータ１３５を再び提供できるように
するか、そうするように命令することができる。幾つかの実施態様では、アセット監査サ
ブシステム１５０は、ストーリービートデータ１３５が承認されなかったことをアセット
コーチサブシステム１３０に示し、アセットコーチサブシステム１３０のコーチングイン
タフェースはそれに従って更新される。例えば、アセットコーチサブシステム１３０は、
アセットコーチサブシステム１３０を通して取得すべき個別化ストーリービートアセット
の幾つか又は全てを表示し、どれが取得されたか、それが承認されたか等を示す。別の例
では、ストーリーメーカー５３９が、ストーリービートデータ１３５の入力の試みを終え
た（例えば、ビデオセグメントのテイクを撮影した）場合、データは、アセット監査サブ
システム１５０を通して自動的に認証される（又はストーリーメーカー５３９は、コーチ
ングインタフェースを介して、データを認証させることを選択することができる）。デー
タが認証されない場合、ストーリーメーカー５３９に通知され、再試行するように促され
る。

ストーリービートデータが承認される場合、ストーリーバインレンダリングサブシステ
ム１９０に通信することができる。ストーリーバインレンダリングサブシステム１９０は
、リッチストーリーボードの制作仕様５２９に従ってストーリービートデータ１３５をレ
ンダリングするように動作可能である。幾つかの実施形態では、ストーリーバインレンダ
リングサブシステム１９０は、レンダリングアプリケーションプログラミング仕様５９３
（例えば、ＡＰＩ）を含み、制作仕様５２９は、レンダリングアプリケーションプログラ
ミング仕様５９３を介してストーリービートデータ１３５のレンダリングを指示するよう
に構成される。幾つかの実施形態では、ストーリーバインレンダリングサブシステム１９
０は、事前レンダリングストーリービート５８３を生成することができる。例えば、完全
なストーリーバインビデオ１９５を最高品質でレンダリングするのではなく、特定のスト
ーリービート（例えば、個別化ストーリービートアセットを含むもの）の「プルーフ」を
生成することができる。事前レンダリングストーリービート５８３は、ストーリーバイン
監査サブシステム１７０に通信して、リッチストーリーボード１１５のアセット承認仕様
５２５に従って承認することができる。幾つかの実施態様では、事前レンダリング機能は
アセットコーチサブシステム１３０と同じ場所に配置される。例えば、アセットコーチサ
ブシステム１３０は、自己監査のためにストーリーメーカー５３９により、コンテキスト
内のアセットデータ監査のためにアセット監査サブシステム１５０により、完成したスト
ーリービートとして監査するためにストーリーバイン監査サブシステム１７０等によって
使用される事前レンダリング機能を含むストーリーメーカー装置のアプリケーションであ
る。他の実施態様では、事前レンダリング機能は、例えば、エージェンシーサーバ、クラ
ウドベースシステム等の一部として、アセットコーチサブシステム１３０とは別個である
。

ストーリービートデータが承認される場合、他の実施形態は、データをストーリーバイ
ンレンダリングサブシステム１９０に通信して、完全なストーリーバインビデオ１９５を
レンダリングする。幾つかのそのような実施形態では、レンダリングされたビデオはまず
、事前承認済みのストーリーバインビデオ５８５として生成される。事前承認済みストー
リーバインビデオ５８５は、ストーリーバイン監査サブシステム１７０に通信されて、ア
セット承認仕様５２５に従って自動的及び／又は手動で（監査者２７３により）承認され
る。事前承認済みストーリーバインビデオ５８５は、ラフバージョン、最高品質バージョ
ン、又は任意の他の有用バージョンであることができる。承認されると、ビデオ作品は、
最終的に承認されたストーリーバインビデオ１９５として見なす（例えば、又は最終的に
承認されたストーリーバインビデオ１９５として再レンダリングする）ことができる。

事前承認済みストーリーバインビデオ５８５が承認されない場合、様々な選択肢をとる
ことができる。例えば、ストーリーバインレンダリングサブシステム１９０は、変更され
た仕様（例えば、リッチストーリーボード１１５の仕様、規則、又はパラメータに従って
手動又は自動的に調整し得る）に従ってデータを再レンダリングすることができ、新しい
又は代替アセットをストーリービートデータ１３５として選択することができ（例えば、
アセットプール等から）、アセットコーチサブシステム１３０を介して個別化ストーリー
ビートデータ１３５を再取得することができるなどである。アセットは、リッチストーリ
ーボード１１５の仕様に従って取得され、編集され、生成され、承認され、レンダリング
され、且つ／又は他の様式で処理されるため、事前レンダリングされたストーリービート
５８３又は事前承認済みのストーリーバインビデオ５８５の非承認は、リッチストーリー
ボード自体の所望の変更を示すことができる。例えば、リッチストーリーボード１１５の
仕様は、ストーリービートデータ１３５の再レンダリング、再取得、再承認、及び／又は
他の再処理を指示するように調整することができる。このようにして、調整されたリッチ
ストーリーボード１１５から生成される全ての後続ストーリーバインビデオ１９５は、更
新された仕様を満たすことになる。

幾つかの実施態様では、最終的なストーリーバインビデオ１９５は、ビデオプレーヤ等
を通して表示される標準ビデオファイルのように、事実上静的（例えば、非インタラクテ
ィブ）である。他の実施態様では、最終的なストーリーバインビデオ１９５は、動的及び
／又はインタラクティブ機能が埋め込まれた状態でレンダリングされる。動的機能は、ス
トーリーバインビデオ１９５が、エンドビューア、プレーヤアプリケーション、エンドビ
ューアシステム等からの暗黙的及び／又は明示的な入力に動的に適合できるようにし得る
。例えば、ストーリーバインビデオ１９５の部分は、エンドビューアの地理的場所、時刻
、プレーヤ属性（例えば、ブラウザタイプ、ディスプレイタイプ、ディスプレイサイズ、
接続速度等）、関連するコンテキスト情報（例えば、現在の株式市場状況等）、又は任意
の他の適する情報に基づいて動的に変更することができる。例示的な一例では、不動産仲
介業者は、数百のエージェントからの紹介ビデオを含むアセットデータから構築されるス
トーリーバインビデオ１９５を出力するが、エンドビューアの人口統計情報に応じてそれ
らのエージェント紹介ビデオのうちの３つを動的に選択する。特定の実施形態では、動的
機能は、レンダリングパラメータ（例えば、リッチストーリーボード１１５の制作仕様５
２９）を調整することによって実現され、したがって、ストーリーバインレンダリングサ
ブシステム１９０は、動的に変化するパラメータに従ってストーリーバインビデオ１９５
を動的にレンダリングすることができる。他の実施形態では、動的機能は、レンダリング
された出力に埋め込まれる（例えば、埋め込みコードとして）。例えば、ストーリーバイ
ンビデオ１９５は、ウェブブラウザインタフェースを通して再生するためにレンダリング
され、動的に受信される暗黙的及び／又は明示的な入力データに従って、表示されたビデ
オに動的に影響するブラウザ可読コードが内部に埋め込まれる。

幾つかの実施態様は、レンダリングストーリーバインビデオ１９５でのインタラクティ
ブ機能をサポートする。ストーリーバインビデオ１９５は、埋め込みプロンプト等を含む
ことができ、それらのプロンプトに応答するように動作可能であることができる。例示的
な一実施態様では、ストーリーバインビデオ１９５は、エンドビューアによる選択に桜桃
する分岐ストーリーラインを含む。別の例示的な実施態様では、ストーリーバインビデオ
１９５は、エンドビューアが各自のビデオ情報（例えば、各自の個別化ストーリービート
アセットデータ）を提供できるようにするリンク、ポータル、又は他の機能を含む。例え
ば、教授は、技法のデモンストレーションを実行し、生徒に一連の質問を出し、生徒から
のビデオ応答を求めている自分のビデオ映像を含むストーリーバインビデオ１９５を作成
する。次に、ビデオは、生徒が各自のビデオ応答を提供することができるリンク又は他の
メカニズムを提供することができる。ビデオ応答は、新しいストーリーバインビデオ１９
５として、現在のストーリーバインビデオ１９５の新しい個別化ストーリービートアセッ
トデータとして、又は任意の有用な方法で、実施形態によって処理することができる。ビ
デオ応答に、教授のビデオへの関連付け、生徒の氏名、タイムスタンプ情報等をタグ付け
することもできる。様々な実施形態の動的及び／又はインタラクティブ機能を１つ又は複
数のシステム又はサブシステムに更にフィードバックして、任意の各入力又は出力情報（
例えば、ビジネス規則５０３、コーチング仕様５２１、アセット収集仕様５２３等）に影
響することもできる。

図７は、様々な実施形態による、１つ若しくは複数のシステム又はシステムの１つ若し
くは複数の構成要素を実施する例示的な計算システム７００を示す。計算システム７００
は、図１を参照して説明したストーリーメーカーシステム１２０’のように、例示的なス
トーリーメーカーシステム１２０’の機能を実施するものとして説明される。同様の計算
システムを使用して、ストーリーバインストーリーボードサブシステム１１０、ストーリ
ーバイン監査サブシステム１７０、及び／又はストーリーバインレンダリングサブシステ
ム１９０等の図１を参照して説明されたエージェンシーシステム１０５の他のシステム、
サブシステム、又は構成要素の機能を実施することができる。計算システム７００の実施
形態は、単一又は分散したコンピュータシステムで、又は任意の他の有用な方法で実施す
るか、又は具現することができる。例えば、ストーリーメーカーシステム１２０’は、デ
スクトップ、ラップトップ、又はタブレットコンピュータ、スマートフォン又は他のポー
タブルインタラクティブメディア装置（例えば、スマートビデオカメラ）、専用装置等で
実施することができる。

バス７５５を介して電気的に結合することができるハードウェア要素を含む計算システ
ム７００が示される。ハードウェア要素は、１つ又は複数の中央演算処理装置（ＣＰＵ）
７０５、１つ又は複数の入力装置７１０（例えば、ビデオ又はスチルカメラ７１３、マウ
ス、キーボード等）、及び１つ又は複数の出力装置７１５（例えば、表示装置７１７、プ
リンタ等）を含むことができる。計算システム７００は、１つ又は複数の記憶装置７２０
を含むこともできる。例として、記憶装置７２０は、ディスクドライブ、光学記憶装置、
プログラマブルフラッシュ更新可能等であることができるランダムアクセスメモリ（ＲＡ
Ｍ）及び／又は読み取り専用メモリ（ＲＯＭ）等の固体状態記憶装置、幾つかの実施形態
では、記憶装置７２０は、上述したように、リッチストーリーボード１１５（図示せず）
から受信される仕様、生成されたストーリービートデータ等を記憶するように構成される
。

計算システム７００は更に、コンピュータ可読記憶媒体リーダ７２５ａ、通信システム
７３０（例えば、モデム、ネットワークカード（無線又は有線）又はチップセット、赤外
線通信装置等）、及び作業メモリ７４０を含むことができ、作業メモリ７４０は、上述し
たようにＲＡＭ及びＲＯＭ装置を含むことができる。幾つかの実施形態では、計算システ
ム７００は処理加速ユニット７３５を含むこともでき、これは、ＤＳＰ、専用プロセッサ
等を含むことができる。

コンピュータ可読記憶媒体リーダ７２５ａは、（任意選択的に記憶装置７２０と一緒に
なって）リモート、ローカル、固定、及び／又はリムーバブル記憶装置並びにコンピュー
タ可読情報を一時的に、及び／又はより永久的に包含する記憶媒体を包括的に表すコンピ
ュータ可読記憶媒体７２５ｂに更に接続することができる。通信システム７３０は、デー
タを公衆又は私設ネットワーク（例えば、ネットワーク１４０）及び／又は任意の他のシ
ステムと交換できるようにし得る。例えば、上述したように、リッチストーリーボード１
１５仕様は、通信システム７３０（例えば、及びネットワーク１４０を介して）ストーリ
ーメーカーシステム１２０’の構成要素又はサブシステムと、エージェンシーシステム１
０５の構成要素又はサブシステムとの間で通信することができる。

計算システム７００は、アプリケーションプログラム（クライアントアプリケーション
、ウェブブラウザ、中間階層アプリケーション、関係データベース管理システム（ＲＤＢ
ＭＳ）等であることができる）等のオペレーティングシステム７４５及び／又は他のコー
ド７５０を含め、現在作業メモリ７４０内に配置された状態で示されるソフトウェア要素
を含むこともできる。幾つかの実施形態では、ストーリーメーカーシステム１２０’の１
つ又は複数の機能は、作業メモリ７４０内のサプリケーションコード７５０として実施さ
れる。示されるように、アセットコーチサブシステム１３０及び／又はアセット監査サブ
システム１５０は、ストーリーメーカーシステム１２０’の作業メモリ内のアプリケーシ
ョンとして実施することができる。これらの各アプリケーションは、ＡＰＩ等の様々な記
憶情報を含むこともできる。

計算システム７００の代替の実施形態が上述したものからの多くの変形を有し得ること
を理解されたい。例えば、カスタマイズされたハードウェアを使用してもよく、且つ／又
は特定の要素をハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを
含む）、又は両方で実施し得る。さらに、ネットワーク入力／出力装置等の他の計算装置
への接続を利用することもできる。様々な実施形態では、図７に示されるような計算シス
テムを使用して、ストーリーメーカーシステム１２０’の１つ又は複数の機能を実施し、
計算システム７００は、必要又は所望に応じて他の機能構成要素と通信する。他の実施形
態では、図７に示されるような計算システム７００を使用して、後述するようなシステム
の方法の１つを実施する。

図８は、様々な実施形態による、リッチストーリーボードによって定義される仕様を使
用してビデオ制作を指示する例示的な方法８００の流れ図を示す。方法８００の実施形態
は、規則（例えば、ビジネス、インタラクティブ、制作、及び／又は他の規則）を有する
ストーリーバインコンセプトを設計することにより、段階８０４で開始される。例えば、
エージェンシー及びそのマーケティング部門は、１組のビデオのコンセプトを決定し、そ
れらのビデオの制作を統制すべき任意の関連規則を識別する。段階８０８において、スト
ーリーバインコンセプト及び関連付けられた規則は、幾つか（例えば、一連）のストーリ
ービートと、仕様とを有するリッチストーリーボードに変換する。仕様は、コンセプト及
び規則を離散したコーチング仕様、アセット収集仕様、役割仕様、アセット承認仕様、制
作仕様、及び／又は任意の他の有用な仕様に効率的に具現することができる（例えば、コ
ンピュータ可読フォーマットで）。

段階８１２において、リッチストーリーボードの仕様に従って、各ストーリービートの
ストーリービートアセットデータが取得される。例えば、及びアセットコーチングサブシ
ステム及びアセット監査サブシステムは、リッチストーリーボード仕様及び関連付けられ
たＡＰＩ及び／又は事前生成されるアセットに従って生成（例えば、自動的に構築）する
ことができる。アセットコーチングサブシステム及びアセット監査サブシステムを使用し
て、リッチストーリーボードの仕様に従って、ストーリーメーカーから任意の個別化スト
ーリービートアセットデータを取得し承認することができる（例えば、個別化ストーリー
ビートアセットデータをインタラクティブにコーチングされるように取得できるようにす
るコーチングインタフェースを介して）。幾つかの場合では、リッチストーリーボードを
使用して、共通の仕様に従うが、複数のストーリーメーカーからの個別化データを有する
複数のストーリーバインビデオ作品を生成する。例えば、幾つかのストーリーメーカーは
それぞれ、幾つかのストーリービートのそれぞれの個別化ストーリービートアセットデー
タを逐次、並列して、又は任意の他の適する様式で提供することができる。したがって、
段階８１２の実施形態は、幾つかのストーリーメーカーのそれぞれの各ストーリービート
のストーリービートアセットデータを取得する（例えば、コーチングインタフェースの１
つ又は複数のバージョンを通して）。

段階８１６において、取得されたストーリービートアセットデータは、リッチストーリ
ーボードの仕様に従って監査（例えば、承認、チェック、認証等）することができる。監
査は、ストーリービートアセットデータが取得されるとき、各ストーリービートアセット
がストーリーメーカーによって「最終化」された後（例えば、ストーリーメーカーが提供
されたアセットデータに満足した後、ストーリーメーカーからの要求で）、ストーリービ
ート又はストーリーバイン全体の全ての個別化アセットデータが収集された後、又は任意
の他の有用なときに実行することができる。さらに、幾つかの実施態様では、監査は、リ
ッチストーリーボードのアセット承認仕様に従って完全に自動化されて実行される。他の
実施態様では、監査の幾つか又は全ては手動で実行される（例えば、役割仕様に従って承
認された監査者により）。例えば、特定のストーリービートの個別化ストーリービートア
セットデータをまず、自動的に監査し、次に、人間の監査者によって認証することができ
る。

幾つかの実施形態は、アセットレベルで取得及び監査を処理し（例えば、段階８１２及
び８１６に従って）、ストーリーバインレベルでレンダリング及び最終的な承認を処理す
る（例えば、後述するように、段階８２８及び８３２に従って）。方法８００の他の実施
形態は、特定の機能をストーリービートレベルで実行する（例えば、段階８２０及び８２
４に従って）。そのような実施形態によれば、段階８２０において、ストーリービートは
、対応する取得され監査されたストーリービートアセットデータ及びリッチストーリービ
ートの仕様に従って生成される（例えば、最高品質又は最高未満の品質で部分的又は完全
にレンダリングされる）。例えば、特定のストーリービートの全てのアセットが取得され
、事前レンダリングされる（ラフカット等として）。段階８２４において、リッチストー
リーボードの仕様に従って各ストーリービートを監査することができる。例えば、手動及
び／又は自動監査を実行して、ストーリービートがリッチストーリーボード仕様及び／又
はその形成コンセプト及び規則に準拠することを確実にすることができる。準拠しない場
合、この段階により、望ましくない結果の早期検出が可能であり、より容易に個別化アセ
ットデータを再取得し、共有アセット又は他のアセットを再生成又は再取得し、ストーリ
ーボード仕様を調整するなどすることができる。

方法８００がストーリービートレベル機能を含むか否かに関係なく、段階８２８におい
て、リッチストーリーボードの仕様及びレンダリングアプリケーションプログラミング仕
様に従って、ストーリービートデータをストーリーバインビデオにレンダリングすること
ができる。例えば、制作仕様、レンダリングＡＰＩ、及び／又は他の情報を使用して、ス
トーリーバインビデオを自動的にレンダリングする。上述したように、仕様は、ストーリ
ービートシーケンス、アセット配置、シーン遷移、オーディオ同期、動的アセット生成（
例えば、共有アセットが、取得された個別化アセットデータに従って自動的に調整する場
合）、及び／又はレンダリングの任意の他の有用な側面（例えば、ポストプロダクション
、編集、再着色、フォーマット、アップ又はダウンコンバート等）を推進することができ
る。幾つかの実施形態では、段階８３２において、ストーリーバインビデオ（例えば、各
ストーリーバインビデオ）は、リッチストーリーボードの仕様に従って監査される。ビデ
オが承認されない場合、実施形態は、段階８１２での特定のアセットの再生成又は再取得
、段階８２０での特定の１つ又は複数の個々のストーリービートの再生成等の適する段階
に戻り得る。

幾つかの実施形態は、例えば、段階８１２に従っての個別化ストーリービートアセット
データの取得に的を絞る。図９は、様々な実施形態によるそのような方法９００の流れ図
を示す。方法９００の実施形態は、任意の適するシステムで、例えば、図１、図５、及び
図７を参照して上述したシステムのようなストーリーメーカーシステムで実施することが
できる。実施形態は、幾つかのビデオ作品で使用する制作仕様及びストーリービートシー
ケンスを定義するコンピュータ可読リッチストーリーボードを識別することにより、段階
９０４において開始される。各ストーリービートは、１組のストーリービートアセットを
有し、ストーリービートアセットの第１の部分は、共有アセットデータに関連付けられた
共有ストーリービートアセットであり、ストーリービートアセットの第２の部分は、アセ
ット取得仕様に関連付けられた個別化ストーリービートアセットである。例えば、特定の
ストーリービートは、自己紹介するストーリーメーカーのビデオを含む。ビデオセグメン
トは個別化ストーリービートアセットであり、一方、周囲のグラフィックス（例えば、ロ
ゴ、フレーム等）、バックグラウンドオーディオ、及び／又はシーンの他の要素は共有ス
トーリービートアセットである。多くのストーリーメーカーの多くのビデオが撮影される
場合、それらは全て独自のビデオセグメントコンテンツを有するが、同じ（又は略同じ）
周囲要素を有することになる。

段階９０８において、コンピュータ実施アセット取得コーチは、各個別化ストーリービ
ートアセットについて、アセット収集仕様に従って個別化アセットデータを取得するよう
動作可能なように生成される。例えば、コンピュータ実施アセット取得コーチは、インタ
ラクティブコーチングインタフェース（例えば、図６に記載されるような）を提供するア
プリケーションであることができる。段階９１２において、コンピュータ実施アセット取
得コーチを介して、各個別化ストーリービートアセットの個別化アセットデータが受信さ
れる。幾つかの実施態様では、アセット収集使用に従って個別化ストーリービートアセッ
トに関連付けられた個別化アセットデータを提供するようにストーリーメーカーにコーチ
ングするように設計されたグラフィカルユーザインタフェース（ＧＵＩ）（例えば、イン
タラクティブコーチングインタフェース）を介して、各個別化ストーリービートアセット
の個別化アセットデータが受信される。個別化ストーリービートアセットに関連付けられ
た個別化アセットデータは、ＧＵＩを介してストーリーメーカーから受信することができ
る。幾つかの実施形態では、ＧＵＩは、アセット収集仕様、事前定義されるコーチングア
セット、コーチングＡＰＩ、及び／又は任意の他の有用情報から構築される（例えば、自
動的に）。

幾つかの実施態様では、上述したように、個別化アセットデータを受信することは、個
別化アセットデータを監査して、アセットデータがアセット収集仕様に準拠するか否かを
判断することを含む。例えば、リッチストーリーボードは、各個別化ストーリービートア
セットに関連付けられた許容仕様を更に定義する。許容仕様は、アセット収集仕様から導
出することもでき、又はアセット収集仕様とは別個であってもよい。アセットデータがア
セット収集仕様に準拠する場合、アセットデータは、個別化アセット、ストーリーメーカ
ー、エージェンシー、又は任意の他の有用情報に関連付けて記憶する（又はタグ付け等）
ことができる。アセットデータがアセット収集仕様に準拠しない場合、アセットデータを
破棄するか、追跡目的で記憶するか、又は任意の適する様式で処理することができる。幾
つかの実施形態では、アセットデータが準拠しない場合、方法９００は、準拠データが受
信されるまで、アセットデータの再取得を試みることができる。

幾つかの実施態様では、個別化ストーリービートアセットの別個の組の個別化アセット
データが、コンピュータ実施アセット取得コーチを介して複数のストーリーメーカーのそ
れぞれから、各ストーリーメーカーに関連付けられて受信される。例えば、各ストーリー
メーカーのアセットが取得され、ストーリーメーカーの識別子（例えば、アセット取得、
ログインプロセス等の一環としてインタフェースを通して受信される）がタグ付け（例え
ば、関連付けて記憶）される。幾つかの実施形態は、各ストーリーメーカーのコンピュー
タ実施アセット取得コーチの対応するバージョンを含む。例えば、各ストーリーメーカー
は、コーチングインタフェースのカスタマイズされたバージョン（例えば、ストーリーメ
ーカーのプリファレンス等に従って）を見る。代替的には、アセット取得コーチの各バー
ジョンは略同じであるが、各ストーリーメーカーの装置で実施される。個別化ストーリー
ビートアセットの１組の個別化アセットデータは、コンピュータ実施アセット取得コーチ
の対応するバージョンを介して複数のストーリーメーカーのそれぞれから、各ストーリー
メーカーに関連付けて受信することができる。

段階９１６において、ビデオ作品をストーリービートシーケンスに従ってレンダリング
することができるように、各個別化ストーリービートアセットの個別化アセットデータが
レンダリングシステムに通信され、各共有ストーリービートアセットは、制作仕様及びそ
れに関連付けられた共有アセットデータに従ってレンダリングされ、各個別化ストーリー
ビートアセットは、制作仕様及びそれに関連付けられた個別化アセットデータに従ってレ
ンダリングされる。

上述したように（例えば、図８の方法８００を参照して）、幾つかの実施形態は、各ス
トーリーメーカーのストーリービートシーケンスに従ってビデオ作品をレンダリングする
。レンダリングは、各ビデオ作品が、リッチストーリーボードのストーリービートシーケ
ンス及び制作仕様に従って共通しており、各ビデオ作品が、各ストーリーメーカーに関連
付けて受信される１組の個別化アセットデータに従って個別化されるように実行すること
ができる。特定の実施態様では、レンダリングされたビデオ作品は、リッチストーリーボ
ードによって定義されるストーリーバイン承認仕様に従って監査することができる。

本明細書に開示される方法は、記載の方法を達成する１つ又は複数の動作を含む。本方
法及び／又は動作は、特許請求の範囲から逸脱せずに、互いと交換することができる。換
言すれば、特定の順序の動作が指定されない限り、特定の動作の順序及び／又は使用は、
特許請求の範囲から逸脱せずに変更することができる。

上述した方法及び特定のシステム構成要素の機能の様々な動作は、例えば、ハードウェ
ア及び／又はソフトウェアを含め、対応する機能を実行することが可能な任意の適する手
段によって実行することができる。本開示に関連して説明した方法のステップ、アルゴリ
アズム、又は他の機能は、ハードウェアでそのまま、プロセッサによって実行されるソフ
トウェアモジュールで、又はそれら２つの組み合わせで実施することができる。ソフトウ
ェアモジュールは、任意の形態の有形記憶媒体に常駐し得る。使用することができる記憶
媒体の幾つかの例としては、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（
ＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハー
ドディスク、リムーバブルディスク、ＣＤ−ＲＯＭ等が挙げられる。記憶媒体は、プロセ
ッサは、記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるようにプ
ロセッサに結合することができる。代替的に、記憶媒体はプロセッサに統合することがで
きる。

ソフトウェアモジュールは、単一の命令、又は多くの命令であることができ、幾つかの
異なるコードセグメント、異なるプログラム、及び複数の記憶媒体にわたって分散するこ
とができる。したがって、コンピュータプログラム製品は、本明細書に提示される動作を
実行することができる。例えば、そのようなコンピュータプログラム製品は、命令を有形
に記憶した（及び／又は符号化した）コンピュータ可読有形媒体であることができ、命令
は１つ又は複数のプロセッサによって実行可能であり、本明細書に記載の動作を実行する
。コンピュータプログラム製品はパッケージング材料を含むことができる。ソフトウェア
又は命令は、伝送媒体を介して伝送することもできる。例えば、ソフトウェアは、同軸ケ
ーブル、光ファイバケーブル、より対線、デジタル加入者回線（ＤＳＬ）、又は赤外線、
無線、若しくはマイクロ波等の無線技術等の伝送媒体を使用して、ウェブサイト、サーバ
、又は他のリモートソースから送信することができる。

他の例及び実施態様も本開示及び添付の特許請求の範囲の範囲及び趣旨内である。例え
ば、機能を実施する特徴は、機能の部分が異なる物理的場所で実施されるように分散する
ことを含め、様々な位置に物理的に配置することもできる。また、特許請求の範囲を含め
、本明細書で使用される場合、「のうちの少なくとも１つ」が前置される項目リスト内で
使用される「又は」は、例えば、「Ａ、Ｂ、又はＣのうちの少なくとも１つ」のリストが
、Ａ又はＢ又はＣ、ＡＢ又はＡＣ又はＢＣ又はＡＢＣ（すなわち、Ａ及びＢ及びＣ）を意
味するような離接的リストを示す。さらに、「例示的な」という用語は、説明される例が
他の例よりも好ましい又は良好なことを意味しない。

本明細書に記載の技法への様々な変更、置換、及び変形を、添付の特許請求の範囲によ
って規定される教示の技術から逸脱せずに行うことができる。さらに、本開示及び特許請
求の範囲の範囲は、上述される特定の態様のプロセス、マシン、製造、組成物、手段、方
法、及び動作に限定されない。本明細書に記載の対応する態様と略同じ機能を実行するか
、又は略同じ結果を達成する、現在存在するか、又は後に開発されるプロセス、マシン、
製造、組成物、手段、方法、又は動作を利用することができる。したがって、添付の特許
請求の範囲は、その範囲内に、そのようなプロセス、マシン、製造、組成物、手段、方法
、又は動作を包含する。

Claims (8)

1. リッチストーリーボードに従って生成されるビデオ作品で使用する個別化アセットを取得するシステムであって、
   前記システムは、ストーリーバインストーリーボードサブシステムと、コンピュータ実施アセットコーチングサブシステムと、ストーリーバインレンダリングサブシステムと、を含み、
   前記ストーリーバインストーリーボードサブシステムは、複数のビデオ作品に使用する制作仕様、及び、第１ストーリービートおよび第２ストーリービートを含むシーケンスを定義するコンピュータ可読リッチストーリーボードを生成するように動作可能であり、
   前記第１ストーリービートは、共有ストーリービートアセットと、第１個別化ストーリービートアセットとを含み、
   前記第１個別化ストーリービートアセットは、第１アセット取得仕様に関連して、前記第１個別化ストーリービートアセットを特徴づける第１ストーリー製作者に、コーチング仕様を提供し、
   前記第２ストーリービートは、前記共有ストーリービートアセットと、第２個別化ストーリービートアセットとを含み、
   前記第２個別化ストーリービートアセットは、第２アセット取得仕様に関連して、前記第２個別化ストーリービートアセットを特徴づける第２ストーリー製作者に、コーチング仕様を提供し、
   前記アセットコーチングサブシステムは、ストーリーバインストーリーボードサブシステムと通信し、
   前記ストーリーバインストーリーボードサブシステムから、前記第１または前記第２アセット取得仕様を受信し、
   コンピュータ実施グラフィカルアセット取得インタフェースを経由し、前記第１また
   は前記第２アセット取得仕様に従ってそれぞれ前記第１または前記第２個別化ストーリービートアセットのためのそれぞれ第１または第２個別化アセットデータを獲得するように動作可能であり、
   前記ストーリーバインストーリーボードサブシステムは、通信ネットワーク上で、複数のストーリーメーカー装置と通信するコンピュータシステムにおいて実行され、前記アセットコーチングサブシステムは、少なくとも１の前記ストーリーメーカー装置において実行され、
   前記ストーリーバインレンダリングサブシステムは、
   前記アセットコーチングサブシステムから前記第１または前記第２個別化ストーリービートアセットのそれぞれ前記第１または前記第２個別化アセットデータを受信し、
   前記第１および前記第２ストーリービートをそれぞれレンダリングすることによって、前記第１ストーリービートおよび前記第２ストーリービートを含むシーケンスに従ってビデオ作品をレンダリングするように動作可能な、
   システム。
2. 前記ストーリーバインレンダリングサブシステムは、前記ストーリーバインストーリーボードサブシステム及び通信ネットワーク上の前記複数のリモートストーリーメーカー装置と、通信可能である、
   請求項１に記載のシステム。
3. 各ストーリーメーカー装置には前記第１または前記第２ストーリー製作者が関連付けられ、
   前記ストーリーバインレンダリングサブシステムは、
   関連付けられた前記第１または前記第２ストーリー製作者に関連して、各ストーリーメーカー装置から前記第１または前記第２個別化ストーリービートアセットのそれぞれ前記第１または前記第２個別化アセットデータを受信し、
   各ビデオ作品が、前記第１または前記第２ストーリービートを含むシーケンス及び前記リッチストーリーボードの前記制作仕様に従って共通し、各ビデオ作品は、前記第１または前記第２ストーリー製作者に関連して受信される前記第１または前記第２個別化アセットデータに従って個別化されるように、複数のビデオ作品をレンダリングするように
   動作可能である、請求項１に記載のシステム。
4. 前記ストーリーバインストーリーボードサブシステムは、
   第１制作仕様及び前記第１ストーリービートを含むシーケンスを定義する第１コンピュータ可読リッチストーリーボードを生成し、
   第２制作仕様及び前記第２ストーリービートを含むシーケンスを定義する第２コンピュータ可読リッチストーリーボードを生成するように動作可能であり、
   前記第１ストーリービートを含むシーケンス及び前記第２ストーリービートを含むシーケンスは両方とも、共有ストーリービートアセット及び第１または第２個別化ストーリービートアセットを有する同一の一組のストーリービートアセットを含み、
   前記ストーリーバインレンダリングサブシステムは、
   前記第１制作仕様に従って前記共有ストーリービートアセット及び前記第１個別化ストーリービートアセットをレンダリングすることにより、前記第１ストーリービートを含むシーケンスに従って第１ビデオ作品をレンダリングし、
   前記第２制作仕様に従って前記共有ストーリービートアセット及び前記前記第２個別化ストーリービートアセットをレンダリングすることにより、前記第２ストーリービートを含むシーケンスに従って第２ビデオ作品をレンダリングするように動作可能である、請求項１に記載のシステム。
5. 前記ストーリーバインレンダリングサブシステムは、１組のアプリケーションプログラ
   ミング仕様を含み、
   前記制作仕様は、前記１組のアプリケーションプログラミング仕様に従って前記リッチストーリーボードによって定義され、
   前記ストーリーバインレンダリングサブシステムは、前記第１または第２ストーリービートを含むシーケンス、前記制作仕様、及び前記１組のアプリケーションプログラミング仕様に従って前記ビデオ作品をレンダリングするように動作可能である、請求項１に記載のシステム。
6. 前記グラフィカルアセット取得インタフェースは、
   ビデオ取得ウィンドウと、少なくとも１のグラフィカルコーチング要素を備え、
   少なくとも１つの前記第１または前記第２個別化ストーリービートアセットの前記第１または第２アセット取得仕様に従って、前記ビデオ取得ウィンドウを介して個別化ビデオ情報を提供するよう、前記第１または前記第２ストーリー製作者にインタラクティブにコーチングするように動作可能である、
   請求項１に記載のシステム。
7. 前記リッチストーリーボードによって定義されるストーリーバイン承認仕様に従って、前記レンダリングされたビデオ作品を監査するように構成されるストーリーバイン監査サブシステムを更に備える、請求項１に記載のシステム。
8. 前記アセット取得仕様は、アセット許容仕様を含み、
   前記システムは、さらに、
   前記アセットコーチングサブシステムと通信可能であり、各個別化アセットデータが前記アセット許容仕様に準拠するか否か、監査可能なアセット監査サブシステムを、
   備える、請求項１に記載のシステム。

Images