JP2010524128A - ワークフローインターフェースのためのメッセージメカニズム - Google Patents

Abstract

【課題】
シンプルなメッセージ手法によって、コンテンツ管理システム内のアプリケーションのインターフェースを提供する。
【解決手段】
メッセージ管理手法は、コンテンツワークフローにおいて、少なくとも一つの作業、例えばアプリケーションの実行中に少なくとも一つの選択パラメータを抽出することによって作動する。そして、オペレータは、抽出されたパラメータに従って、少なくとも一つの作業がうまく実行されたかどうかを知らされる。

Description

本発明はコンテンツ管理システムの構成要素とのインターフェースを提供する技術に関する。

［関連出願についてのクロス・リファレンス］
本出願は、米国特許法１１９条（ｅ）の下で２００８年４月１２日に出願した仮特許出願番号６０／９２３，０２８の優先権を主張する。そして、この仮出願の内容は本願明細書に組み込まれる。

エンティティ、例えばブロードキャスタは、コンテンツを受信し、処理し、および／または、配信する。コンテンツの形式は、オーディオビジュアルプログラムを含む電子ファイルの形となっており、ブロードキャスタは、大きなシステムを使用してこのようなコンテンツを管理する。考察の容易さのために、コンテンツの受信、処理および／または配信は、集合的にコンテンツワークフローの一般の作業を有するとする。

特定のコンテンツワークフローにおけるコンテンツの処理には、さまざまなオペレーションが含まれ得る。与えられたオペレーション、例えばノンリニア編集は、通常は少なくとも一つ、および、場合によっては幾つかの別の構成要素を必要とする。そして、これらの各々は、ハードウェア、ソフトウェアのいずれか、または両方の組合せを有する。多くの例において、単一のベンダーが、与えられたコンテンツ処理オペレーションまたはオペレーションのセットを実行するのに必要な構成要素の全てを提供する場合もある。しかしながら、他のコンテンツ処理オペレーションでは、複数の異なるベンダーからの構成要素を必要とすることがある。

一つ以上の処理オペレーションを実行する複数の別のベンダーからの構成要素の組合せは、コンテンツ標準化に関して課題を提起し得る。例えば、メディア産業の中で、ノンリニア編集としてコンテンツを編集するために、多くのソリューションが存在する。このために、一部のベンダーは、いくつかの周知の標準化されたフォーマット、例えば編集された素材に関して編集決定リストを利用するＡＡＦ（Ａｄｖａｎｃｅｄ Ａｕｔｈｏｒｉｎｇ Ｆｏｒｍａｔ）と互換性を持つ器材を提供する。ＡＡＦフォーマットは、未だ世界的な利用にまでは普及しておらず、そして通常はポストプロダクションのような特定の領域で応用されているにとどまっている。ＭＸＦ（Ｍａｔｅｒｉａｌ ＥＸｃｈａｎｇｅ Ｆｏｒｍａｔ）はコンテンツのストリーミングおよび、記憶のための標準となっており、かつ、マルチレイヤおよびセグメントコンテンツを含むエッセンスおよびメタデータの転送を都合よく扱うことができる。しかしながら、ＭＸＦは、単純なコンポジット・コンテンツに対してよく機能するが、汎用的な適用性を欠いている。このために、コンテンツプロセスデバイスの多くの供給元は、ＡＡＦ標準をサポートする。しかしながら、現在のソリューションは、タスク記述のようなオペレーション上の側面、コンテンツの使用法、および、優先処理に対応していない。

要約すれば、本願発明の好ましい実施例において、オペレーションを最適化するために、ワークフローを管理するフレームワークによって、限定されたインターフェース能力を有するアプリケーションを管理する方法が提供される。本方法は、オペレーションのワークフロー管理手法において、アプリケーションに対してインターフェースを提供するシンプルなメッセージ手法を提供する。本願発明の方法は、コンテンツワークフローの少なくとも一つの作業（例えばアプリケーション）の実行中に少なくとも一つの選択パラメータを抽出することによって開始される。オペレータは、前記少なくとも一つの作業が、抽出されたパラメータによって、うまく実行できたかどうかを知ることになる。

サードパーティ製のサブシステムに対してインターフェースを提供するために、本願発明のメッセージ管理技術を使用したコンテンツ管理システムを示すブロック図である。 サードパーティ製のサブシステムから図１のコンテンツマネージメントサブシステムへのインターフェースを提供するための、メッセージ管理に係る本願発明の方法を示すフローチャートである。

図１は、コンテンツ管理システム１０であり、例えば、トムソン・グラス・バレー・ビーヴァートン、オレゴンから入手可能なトムソン・グラス・バレー「Content ShareＣＳ２」システムが挙げられる。コンテンツ管理システム１０は、パソコンまたはミニコンピュータのプロセッサ（図示せず）を有し、ハードウェア、ソフトウェアまたはその両者の組み合わせを有する一つ以上の構成要素とインターフェースがとられている。コンテンツ管理システム１０の内の主要な構成要素は、コンテンツ管理システムによって実行されるさまざまなコンテンツ加工を命ずるワークフローエレメント１２である。所望のコンテンツワークフローに従い、ワークフローエンジン１２は、コンテンツ加工機能、例えばノンリニア編集、を実行することを命ずることができる。他のコンテンツ加工オペレーションとしては、コンテンツ圧縮が含まれる。他のコンテンツ加工オペレーションは、よく知られているため、ここでは記載を省略する。

コンテンツ管理システム１０の内の他の構成要素としては、一つ以上のオペレータがデバイス、例えばキーボード、およびタッチスクリーンを介してコンテンツ管理システムと対話することを可能にするユーザーインターフェース（ＵＩ）アプリケーション１４がある。加えて、ＵＩアプリケーション１４は、コンテンツ管理システムからデータを得て、オペレータにコンテンツ管理システムのオペレーションを表す情報を提供するために、一つ以上のモニタ（図示せず）の表示のためのデータを操作する。

コンテンツ管理システム１０の内の他の構成要素としては、プロダクトライフサイクルマネージメント（ＰＬＭ）モジュールがある。これは、コンテンツ管理システムのオペレーションをトラック（追跡）するために作動する。ＰＬＭは、巨大なシステム（super system）とのインターフェースを提供する。たとえば、資源を制御し、かつプロセスデバイス資源管理レイヤーを提供するＴｒａｆｆｉｃシステムが挙げられ、これは、全体のシステムにおいて、オペレーションのタイミングを合わせること、例えばサービスの質（Quality of service）の向上を可能とする。

コンテンツ管理システム１０は、さまざまな要素を含むインフラストラクチャを有する。たとえば、ウエブサービスモジュール１８が挙げられる。このモジュールは、例えばインターネットなどのネットワークとコンテンツ管理システム１０とのリンクを実現するソフトウェアおよび／またはハードウェアを含んでいる。また、コンテンツ管理システムのインフラストラクチャは、ソフトウェア開発ツールキット（ＳＤＫ）２０を有する。これは、オペレータによってアクセスできる一つ以上のソフトウェアプログラムを含み、コンテンツ管理システム１０の中でソフトウェアの追加、削除および／または変更を可能とする。最後に、コンテンツ管理システムのインフラストラクチャは、コア・サービスモジュール２２を有する。これは、コア・サービス（例えば入力されるコンテンツの受信、完了したコンテンツの配信、レコーディングを維持する情報の収集等の機能）を管理する。

コンテンツ管理システム１０は、少なくとも１つの、好ましくは、多数のブローカー（Broker）２４_１、２４_２．．．２４_ｎ（ｎは整数）を有する。それぞれのブローカーは、それぞれ、異なるデバイス２６_１〜２６_ｎとのインターフェースを提供する。各々のデバイス２６_１〜２６_ｎは、少なくとも一つの機能、および、しばしば、複数の機能を実行する。たとえば、コンテンツの受信、プロセッシング、記憶および／または配信などである。ブローカーは、外部のプロセスデバイスとのインターフェースを提供する。実際には、ブローカーは、さまざまなプロセスデバイスの機能を抽出し、かつ、全体的なインターフェースをコンテンツ管理システム内部のクライアントに提供する。これは、プロセスデバイスの機能を使用して、全体の複雑なワークフローを提供する。プロセスデバイスは、もちろん同じ製造業者からの製品であってもよく、多くの場合は、サードパーティ製のものである。そしてこれらはブローカーのインターフェースを使用してコンテンツ管理システムに組み込まれる。

デバイス２６_１〜２６_ｎに加えて、コンテンツ管理システム１０は、インテリジェント・ワークフロー・ゲートウェイ２８を有する。これは、コンテンツ管理システム１０と一つ以上の独立のサードパーティサブシステム（実例としてサブシステム３０で例示される）にリンクするインターフェースとして機能する。通常、サブシステム３０は、プロセッサ等（図示せず）を有する。これは、少なくとも一つのコンテンツ加工アプリケーション３２（ハードウェア、ソフトウェアまたはこれらの組み合わせで構成される）を制御する。コンテンツ加工アプリケーション３２は、それ自体がコンテンツ加工オペレーションを実行するが、また、それは、一つ以上の（２６_１〜２６_ｎと基本的に同様の）デバイス３４を用いてコンテンツ加工オペレーションを実行する。

インテリジェントワークフロー・ゲートウェイ２８は、主にコンテンツ管理システムワークフローエンジン１２を独立サブシステム３０から切り離すために用いる。いずれにせよ、オペレーションのための最初の指示は、ワークフローエンジン１２から発せられ、この仕事の指示は、インテリジェントワークフロー・ゲートウェイ２８を経てサブシステム３０に伝えられる。仕事の指示は、サブシステム３０の閾値（例えばパラメーター値）の情報を含む。このパラメータ情報は、達成されなければならず、返信のメッセージイベントを発生させ、サブシステム３０に発せられた仕事の指示が無事完了したことをワークフローエンジン１２に対して伝える。加えて、インテリジェントワークフロー・ゲートウェイ２８は、仕事の指示の完了通知と共に、サブシステム３４から返信されることになっている更なる情報を受信することも可能である。インテリジェントワークフロー・ゲートウェイ２８は、サブシステム３０での仕事の指示（作業）の実行を独立にモニタして、前に確立された仕事の指示達成の閾値に基づいて、予想される情報を配信する。一旦、インテリジェントワークフロー・ゲートウェイ２８が、待機しているワークフローエンジン１２を起動させ、ワークフローを指示すると、情報スレッドがワークフローエンジンに戻される。これは、起動しているワークパッケージ（Workpackage）の一部としてワークフローに従って継続される。

本願発明の態様に従って、サードパーティサブシステムは、メッセージ送信モジュール３６を有する。メッセージ送信モジュール３６はコンテンツ管理システム１０のワークフローエンジンから指示メッセージを取り出し、かつ、レスポンスを提供する。その内容としては、特定のアクティビティを示すものであり、その特定のアクティビティが成功裏に発生したことの警告をオペレータに送る。メッセージ送信モジュール３６は、通常は、図２のフローチャート形式で表される方法を実行するソフトウェアという形をとる。図２において表されるメッセージ送信プロセスは、ステップ２００の実行に始まる。ステップ２００は、オペレータによって、モニタリングのための所望の情報が確立（establish）される。通常、実際には、オペレータは、図１のサブシステム３０によって実行されるコンテンツワークフローの内の与えられたアプリケーションが適切に実行されているかどうかについて知りたいのである。加えて、オペレータは、追加情報（例えばロギング、および、タイミング・データ）を入手したい場合もある。そしてステップ２００において、オペレータは、所望のモニタリング情報を確立する。なお、図１のメッセージ送信モジュール３６は、オペレータによって修正することができるモニタリング情報のデフォルト設定を確立することができる。

ステップ２００後、図２のステップ２０２が実行される。図１のメッセージ送信モジュール３６は、所望のモニタリング情報の関連づけられたパラメータを決定する。通常は、特定のアクティビティと関連して集められるモニタリング情報は、それとともに関連づけられる一つ以上のパラメータを有する。このように、関連づけられたパラメータは、それ自身が、アクティビティの情報を提供する。例えば、アクティビティがうまく実行されたか否かの情報である。

次に、図２のステップ２０４が実行される。このステップで、図１のメッセージ送信モジュール３６は、ステップ２０２においてコンテンツ加工アプリケーション３２によって実行されている現在のアクティビティの特定された関連するパラメータを抽出する。それから、図１のメッセージ送信モジュール３６は、アプリケーションの実行を評価するために、ステップ２０６において、抽出されたパラメータを調べる。上述したように、ステップ２０２において、判断される関連づけられたパラメータの一つ以上は、アプリケーションがうまく実行されたかどうかの指示を提供してもよい。このように、ステップ２０６において、パラメータを調べることによって、アプリケーションの実行が成功したかどうか、メッセージ送信モジュール３６はステップ２０８において、判断することができる。アプリケーションの実行が成功したかどうかに従い、それぞれ、ステップ２１０、および、２１２において、メッセージ送信モジュールは、アプリケーションの実行の成功または失敗を報告することができる。図２のステップ２１０、および、２１２において、アプリケーションの実行の状態を報告することに加えて、図１のメッセージ送信モジュール３６がまた、他の情報を報告してもよい。例えば、各々のこれらのステップにおいてのロギング、および／またはタイミング・データが挙げられる。ステップ２１０または２１２のいずれかの実行後、方法プロセスはステップ２０４に戻る。与えられたアプリケーションのパラメータが発生するまで、および、更なるアプリケーションの実行の待機が無くなるまで、この繰り返しが続けられる。

以上の説明は、サブシステムのオペレーションを表示するメッセージを提供することによって、コンテンツ管理システムの少なくとも一つのサブシステム構成要素とのインターフェースを提供する技術を述べたものである。

Claims (10)

1. ワークフローの少なくとも一つのアクティビティの実行中に少なくとも一つの選択されたパラメータを抽出するステップと、
   オペレータに前記少なくとも一つのアクティビティが前記抽出されたパラメータに従って成功裏に実行されたか否かを知らせるステップと、
   を有する方法。
2. 前記抽出するステップは、
   前記少なくとも一つのアクティビティに関連づけられた所望のモニタリング情報を確立するステップと、
   抽出されたパラメータの最少の一つが閾値を上回る値を持つか否かを特定するステップと、
   を更に含む請求項１に記載の方法。
3. 前記少なくとも一つのアクティビティの実行に関連づけられたロギング情報、および、タイミング情報の少なくとも一つを提供するステップ、
   を更に有する請求項１に記載の方法。
4. オペレータによって前記所望のモニタリング情報が確立される請求項２に記載の方法。
5. コンテンツ・マネージメント・サブシステムが前記所望のモニタリング情報をデフォルトとして確立する、
   請求項４に記載の方法。
6. サブシステムからコンテンツ管理システムにメッセージを通信するためのメッセージ送信モジュールを有する装置であって：
   前記モジュールは、
   ワークフローの前記サブシステムによって実行された少なくとも一つのアクティビティの実行中に少なくとも一つの選択されたパラメータを抽出する手段と、
   オペレータに前記少なくとも一つのアクティビティが前記抽出されたパラメータに従って成功裏に実行されたか否かを知らせる手段と、
   を有する装置。
7. 前記抽出する手段は：
   前記少なくとも一つのアクティビティに関連づけられた所望のモニタリング情報を確立するための手段と、
   抽出されたパラメータの最少の一つが閾値を上回る値を持つか否かを特定するための手段と、
   を有する請求項６に記載のメッセージ送信モジュール。
8. 前記知らせる手段が更に、
   前記少なくとも一つのアクティビティの実行に関連づけられたロギング情報、および、タイミング情報の少なくとも一つを提供する、
   請求項６に記載のメッセージ送信モジュール。
9. 前記抽出する手段が、前記所望のモニタリング情報を確立するためのオペレータの入力に応答する、
   請求項６に記載のメッセージ送信モジュール。
10. 当該モジュールが前記所望のモニタリング情報をデフォルトとして確立する、
    請求項６に記載のメッセージ送信モジュール。

Images