JP2017504104A - グラフ状データ構造の効率的で低遅延の同期のための装置、システムおよび方法 - Google Patents

Abstract

装置が提供される。装置は、データモデル（１１０）を含み、上記データモデル（１１０）は３つ以上のノードを含み、データモデル（１１０）の３つ以上のノードの１つまたは複数は、それに割り当てられているＩＤを有し、上記１つまたは複数のノードの各々は、そのＩＤによってデータモデル（１１０）の他のノードから一義的に区別可能であり、データモデル（１１０）のノードのうちの少なくとも２つは各々、１つまたは複数の属性を含み、上記属性の各々が、データモデル（１１０）内に記憶されている値を利用することが可能であり、上記少なくとも２つのノードの各ノードは、それに割り当てられているパス指示を有し、パス指示は、当該パス指示が割り当てられているそれぞれのノード、および、データモデル（１１０）の３つ以上のノードのうちの少なくとももう１つのノードを含み、上記少なくとも２つのノードの各ノードのパス指示は、それぞれのノードのＩＤとは異なる。加えて、装置は、属性を有するデータモデル（１１０）の３つ以上のノードの各々の各属性のための書き込み関数を含むコントローラを含み、属性の値は、書き込み関数によって変更可能である。さらに、装置はシンクロナイザ（１３０）を含む。シンクロナイザ（１３０）は、データモデル（１１０）のノードのうちの１つを指定する更新通知を受信するように構成されており、上記更新通知は、上記ノードの属性をさらに指定し、更新通知は、この属性の値がどのように更新されるべきかを示し、更新通知は、ノードのＩＤによってノードを指定する。コントローラ（１２０）は、この属性の書き込み関数によって、更新通知に応じてこのノードのこの属性の値を更新するように構成されている。

Description

本特許出願は、低遅延同期に関し、特に、グラフ状、たとえば、ツリー状のデータ構造の効率的な低遅延同期のための装置、システムおよび方法に関する。

多数のソフトウェアアプリケーションが、グラフ状データ構造、たとえば、ツリーの形状に編成されているデータ構造を内部で使用する。ツリーの形状に体系化されているそのようなデータ構造において、アプリケーションの状態はそのようなデータ構造内で保持され得る。データ構造の部分が変化した場合、アプリケーションはこれに対応し、たとえば、画面表示を変化させるか、または、接続されている周辺デバイスを制御する。基礎となる設計パターンは、ＭＶＣ（モデルビューコントローラ）と称される。

たとえば、数人のユーザがアプリケーションを用いて協働して（合同で／協調して）作業するために、その状態がそのようなグラフ状、たとえば、ツリー状のデータ構造においていくつかのデバイス上で同時に保持される、そのようなアプリケーションを実施することが所望される場合、または、ユーザが、操作性を改善する目的で、複数の異なる端末デバイス、たとえば、タブレットＰＣおよび携帯電話にアプリケーションの複数の異なる表示を配布することを所望する場合、以下のことが起こるべくして起こる。

一方において、複数の異なる端末デバイス上で同時に動作するアプリケーションを同期させるための通信プロトコルが、多大な労力を伴う形で提供され、実装されなければならない。上記実装は一般的に費用も時間もかかり、したがって、誤りも生じやすい。

他方において、上記プロトコルは高速かつ効率的でなければならない。第１のデバイス上のユーザ入力と、さらなるデバイス上でのアプリケーションの更新との間に顕著な遅延が発生してはならない。特にオーディオシステムの制御について、同期にかかる時間は数ミリ秒を超えてはならない。

従来技術には、いくつかのモバイルデバイス、たとえば、調整卓のためのＭａｃｋｉｅ−Ｃｏｎｔｒｏｌまたは多様なｉＰａｄコントロールを使用することによって、システムを同時に制御することができる既知の装置がある。

現在、アプリケーションの複数の異なるクライアント（クライアント、クライアントアプリケーション）の通信は、通例、データベースを用いて実行される。データベースプロトコルを介して、データベース内で状態が設定され、これらの状態はその後、複数の異なるクライアントに送信される。これに対する２つの手法がある。

第１の手法は、いわゆるキー値手法である。たとえば、Ｒｅｄｉｓデータベースを参照されたい。キーは、それとともに記憶されているデータセットを有する。データセットは、キーを介して迅速にアクセスされることができる。この手法の利点は、性能レベルが高いことである。しかしながら、キー値手法に基づいた複雑なアプリケーションの開発は計り知れず、したがって、費用がかかり、誤りを生じやすい。

第２の手法は、いわゆるドキュメント指向型手法である。たとえば、ＣｏｕｃｈＤｂ、ＭｏｎｇｏＤｂを参照されたい。データはグラフの形状に構造化され、アドレスパスを介してアクセスされることができる。この手法は、良好に構造化されたデータ、したがって、容易に取り扱うことができるアプリケーションを実現することを可能にする。それゆえ、アプリケーションは高速に、直接的に開発され開発される。欠点は、データへのアクセスに費用がかかることである。しかしながら、高い頻度で変化し、待ち時間の短いデータの制御について、そのような手法はそれほど適していない。

しかしながら、一方では低遅延同期およびデータ更新において高い性能レベルを実現し、他方ではデータアクセス中に高度な直観性を実現する概念が提供されることが望ましい。

請求項１において特許請求されているような装置、請求項１４において特許請求されているようなサーバ、請求項２１において特許請求されているようなクライアント、請求項２５において特許請求されているようなシステム、請求項２６において特許請求されているような方法、および、請求項２７において特許請求されているようなコンピュータプログラムが提供される。

装置が提供される。装置は、データモデルを含み、データモデルは３つ以上のノードを含み、データモデルの３つ以上のノードの１つまたは複数は、それらと関連付けられているＩＤを有し、上記１つまたは複数のノードの各々は、そのＩＤによってデータモデルの他のノードから一義的に区別可能であり、データモデルのノードのうちの少なくとも２つは各々、１つまたは複数の属性を有し、上記属性の各々が、データモデル内に記憶されている値を利用することが可能であり、上記少なくとも２つのノードの各ノードは、それらに割り当てられているパス指示を有し、パス指示は、当該パス指示が割り当てられているそれぞれのノード、および、少なくとも、データモデルの３つ以上のノードのうちのさらなるノードを含み、上記少なくとも２つのノードの各ノードのパス指示は、それぞれのノードのＩＤとは異なる。

一実施形態において、たとえば、データモデルのノードの各々は、それに割り当てられているＩＤを有し、データモデルのノードの各々は、そのＩＤによってデータモデルの他のノードから一義的に区別可能である。

さらに、装置は、属性を有するデータモデルの３つ以上のノードの各々の各属性のための書き込み関数を含むコントローラを含み、属性の値は、書き込み関数によって変更可能である。さらに、装置はシンクロナイザを含む。シンクロナイザは、データモデルのノードのうちの１つを指定する更新通知を受信するように構成されており、上記更新通知は、上記ノードの属性をさらに指定し、更新通知は、この属性の値がどのように更新されるべきかを示し、更新通知は、ノードのＩＤによってノードを指定する。コントローラは、この属性の書き込み関数によって、更新通知に応じてこのノードのこの属性の値を更新するように構成されている。

実施形態において、書き込み関数は、データモデル内の値の設定を担うだけでなく、シンクロナイザの報告および／またはさらなるオブザーバの報告、ならびに、後の復元または取り消しを目的とした経時的な変化の記録のような、さらなる可能性をもつ機能をも担う。

実施形態によれば、シンクロナイザは、更新通知を送信するように構成されている。

本発明の実施形態は、従来技術と比較したときに多数の利点、たとえば、同期プロトコルの明らかにより容易な拡張性、アプリケーション開発者にとってのトランスペアレントな同期の完全にウェブベースの実施、および／または、新たな構成要素の容易な統合を含む。従来技術において、プロバイダは、クライアントおよびサーバ内の永続的データ表現ではなく、プロトコルを定義するに過ぎないが、実施形態によれば、永続的データ表現が定義され、プロトコルはそこから導出される。実施形態は、さらなるツールを提供する。

一実施形態によれば、サーバが提供される。サーバは、上述したような装置である。さらに、サーバは、１つまたは複数のクライアントからの登録（ログイン）を受信するように構成されている。加えて、サーバは、１つまたは複数のクライアントに、当該クライアントの登録を受けて、データモデルに関する情報を転送するように構成されており、データモデルに関する上記情報は、属性を有するデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、データモデルに関する情報は、データモデルの各ノードまたはデータモデルの少なくとも２つのノードについて、データモデルのいずれの１つもしくは複数のノードが当該ノードに直に後続するか、および／または、データモデルのいずれの１つまたは複数のノードが当該ノードに直に先行するかをさらに示す。

一実施形態において、サーバは、たとえば、１つまたは複数のクライアントに、当該クライアントの登録を受けて、サーバのデータモデルの２つ以上のノードのＩＤを転送するように構成されてもよい。

さらなる実施形態によれば、クライアントが提供される。サーバは、上述したような装置である。さらに、クライアントは、上述したサーバに登録するように構成されている。クライアントは、サーバに登録されると、サーバのデータモデルに関する情報を受信するように構成されており、サーバのデータモデルに関する上記情報は、属性を有するサーバのデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、サーバのデータモデルに関する情報は、サーバのデータモデルの各ノードまたはサーバのデータモデルの２つ以上のノードについて、サーバのデータモデルのいずれのノードが当該ノードに直に後続するか、および／または、サーバのデータモデルのいずれのノードが当該ノードに直に先行するかをさらに示す。さらに、クライアントは、サーバのデータモデルに関する情報に応じてそのデータモデルを更新するように構成されている。

さらに、システムのようなが提供される。システムは、上述したサーバおよび上述したクライアントを含む。クライアントは、サーバに更新通知を送信するように構成されている。サーバのシンクロナイザは、更新通知を受信するように構成されており、更新通知は、データモデルのノードのうちの１つを指定し、さらに、上記ノードの属性を指定し、上記属性の値がどのように更新されるべきかを示す。サーバのコントローラは、更新通知がノードのＩＤを指定する場合に、更新通知に応じて上記ノードの上記属性の値を更新するように構成されている。

さらに、方法が提供される。方法は、
ノードのＩＤによってデータモデルのノードを指定する更新通知を受信するステップであって、上記更新通知は上記ノードの属性をさらに指定し、上記更新通知は、この属性の値がどのように更新されるべきかを示し、上記データモデルは３つ以上のノードを含み、データモデルの３つ以上のノードの１つまたは複数は、それに割り当てられているＩＤを有し、上記１つまたは複数のノードの各々は、そのＩＤによってデータモデルの他のノードから一義的に区別可能であり、データモデルのノードのうちの少なくとも２つは各々、１つまたは複数の属性を含み、上記属性の各々が、データモデル内に記憶されている値を利用することが可能であり、上記少なくとも２つのノードの各ノードは、それに割り当てられているパス指示を有し、パス指示は、当該パス指示が割り当てられているそれぞれのノード、および、データモデルの３つ以上のノードのうちの少なくとももう１つのノードを含み、上記少なくとも２つのノードの各ノードのパス指示は、それぞれのノードのＩＤとは異なる、受信するステップと、
更新通知に応じて、この属性の書き込み関数によって、更新通知において指定されている属性の値を更新するステップとを含む。

実施形態において、方法は、たとえば、以下の１つまたは複数のさらなるステップを含んでもよい。

ＩＤを生成するステップ、ならびに／または
クライアントとサーバとの間で更新するステップ、
サーバとクライアントとの間でデータモデルをマッチングするステップ、ならびに／または
書き込み関数／記憶機能を指定するステップ。

さらに、上述した方法を実施するためのプログラムコードを有するコンピュータプログラムが提供される。

好ましい実施形態が、従属請求項に見出される。

一実施形態による装置を示す図である。 一実施形態によるデータモデルの階層グラフ構造を示す図である。 一実施形態によるシステムを示す図である。 データモデル、オブザーバ構造およびコントローラ構造を示す図である。 クライアントとサーバとの間の同期の可能性のある過程を示す図である。 ＵＩ．ＦＭを使用することなく音波処理システムを導入するための例を示す図である。 実施形態による低遅延同期の本発明による適用例を示す図である。 実施形態による低遅延同期の本発明による適用例を示す図である。 実施形態による低遅延同期の本発明による適用例を示す図である。 実施形態による低遅延同期の本発明による適用例を示す図である。 好ましい実施形態によるＵＩ．ＦＭシステムを示す図である。 実施形態による低遅延同期のさらなる本発明による適用例を示す図である。 実施形態による低遅延同期のさらなる本発明による適用例を示す図である。 実施形態による低遅延同期のさらなる本発明による適用例を示す図である。 実施形態による低遅延同期のさらなる本発明による適用例を示す図である。 実施形態による低遅延同期のさらなる本発明による適用例を示す図である。 一実施形態によるウェブアプリケーションの本発明による具現化を示す図である。 一実施形態によるウェブアプリケーションの本発明による具現化を示す図である。 一実施形態によるウェブアプリケーションの本発明による具現化を示す図である。 実施形態による低遅延同期のさらなる実施形態を示す図である。 実施形態による低遅延同期のさらなる実施形態を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 一実施形態による、プログラミングの観点からのデータモデルおよびその実施態様を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 実施形態による、プログラミングコマンドのコンソール入力および返される結果を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 一実施形態による、属性を追加することによるデータ構造の変化を示す図である。 データモデルの値が変化するときに、一実施形態に従って、ユーザが自身をどのように報告されるようにすることができるかを示す図である。 データモデルの値が変化するときに、一実施形態に従って、ユーザが自身をどのように報告されるようにすることができるかを示す図である。 データモデルの値が変化するときに、一実施形態に従って、ユーザが自身をどのように報告されるようにすることができるかを示す図である。 データモデルの値が変化するときに、一実施形態に従って、ユーザが自身をどのように報告されるようにすることができるかを示す図である。 データモデルの値が変化するときに、一実施形態に従って、ユーザが自身をどのように報告されるようにすることができるかを示す図である。 一実施形態による、復元されたデータ記録に従った、データ記録の復元を受けての警告出力を示す図である。

図面を参照しながら、本発明の好ましい実施形態を下記に説明する。

図１ａは、一実施形態による装置を示す。

装置は、データモデル１１０を含み、データモデル１１０は３つ以上のノードを含み、データモデル１１０の３つ以上のノードの１つまたは複数は、それに割り当てられているＩＤを有し、上記１つまたは複数のノードの各々は、そのＩＤによってデータモデル１１０の他のノードから一義的に区別可能であり、データモデル１１０のノードのうちの少なくとも２つは各々、１つまたは複数の属性を含み、上記属性の各々が、データモデル１１０内に記憶されている値を利用することが可能であり、上記少なくとも２つのノードの各ノードは、それに割り当てられているパス指示を有し、パス指示は、当該パス指示が割り当てられているそれぞれのノード、および、データモデル１１０の３つ以上のノードのうちの少なくとももう１つのノードを含み、上記少なくとも２つのノードの各ノードのパス指示は、それぞれのノードのＩＤとは異なる。

一実施形態において、データモデル１１０のノードの各々は、それに割り当てられているＩＤを有し、たとえば、データモデルのノードの各々は、そのＩＤによってデータモデル１１０の他のノードから一義的に区別可能である。

言い換えれば、それゆえ、データモデルの多数のノードが、２つ以上のノードを含むパス指示を含む。たとえば、ツリー階層において、たとえば、ノード「Ｒｅｎｄｅｒｅｒ」がノード「ｒｏｏｔ」に直に後続する場合、パス指示はたとえば、「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ」として参照することができ、したがって、当該パス指示は、データモデルのノードのうちの２つ、すなわち、「ｒｏｏｔ」および「Ｒｅｎｄｅｒｅｒ」を含む。パス指示「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ」にとどまらず、ノード「Ｒｅｎｄｅｒｅｒ」はまた、データモデル内で一義的である、それに割り当てられているＩＤ、たとえば、数字「２」を有する（たとえば、図３のデータモデル３１０を参照されたい）。しかしながら、いずれにせよ、ノードのＩＤとパス指示は常に互い に異なる。このように、パス指示に加えて、ノードに割り当てられているＩＤが存在する。ＩＤが短い識別子によってノードをアドレス指定する役割を果たす一方で、パス指示の目的は、中でも、データモデルのノードを、パス構造を介して直観的にアドレス指定可能にすることである。

さらに、装置は、属性を有するデータモデルの３つ以上のノードの各々の各属性のための書き込み関数を含むコントローラ１２０を含み、属性の値は、書き込み関数によって変更可能である。

加えて、装置はシンクロナイザ１３０を含む。シンクロナイザ１３０は、データモデル１１０のノードのうちの１つを指定する更新通知を受信するように構成されており、上記更新通知は、上記ノードの属性をさらに指定し、更新通知は、この属性の値がどのように更新されるべきかを示し、更新通知は、ノードのＩＤによってノードを指定する。

コントローラ１２０は、この属性の書き込み関数によって、更新通知に応じてこのノードのこの属性の値を更新するように構成されている。

この文脈において、データモデル１１０は、グラフ状構造を含み得る。たとえば、ノード「ｒｏｏｔ」がノード「Ｒｅｎｄｅｒｅｒ」に先行することが指定され得る。この関係は、「ｒｏｏｔ」から「Ｒｅｎｄｅｒｅｒ」へのグラフとして定義および／または指示され得る。さらに、たとえば、ノード「Ｒｅｎｄｅｒｅｒ」がノード「Ｓｃｅｎｅ」に先行することが指定され得る。この関係もまた、「Ｒｅｎｄｅｒｅｒ」から「Ｓｃｅｎｅ」へのグラフとして規定されるか、または、そのように考えられ得る。このとき、そのような関係のすべてが結果として、データモデル１１０のグラフ状構造をもたらす。

データモデル１１０は、グラフ状構造の特別な事例と考えることができる、ツリー状階層構造を含み得る。ツリー状階層構造では、一般的に、データモデルのさらなるノードのすべてが間接的または直接的にそれに後続するルートノードが存在する。そのようなツリー状階層構造が図１ｂに示されている。

たとえば、パス指示「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ．Ｓｃｅｎｅ．ｓｒｃ０」は、図１ｂのツリー状階層のようなツリー状階層内の対応するノードｓｒｃ０を一義的に指定することができる。そのようなパス指示は、ノード「ｓｒｃ０」ならびにデータモデルの３つのさらなるノード、すなわち、「ｒｏｏｔ」、「Ｒｅｎｄｅｒｅｒ」および「Ｓｃｅｎｅ」を含む。対応するノードを一義的に指定するための名前として「ｓｒｃ０」のみを使用することは、「ｓｒｃ０」が、データモデル内の名前として数回現れる可能性があるため、十分ではない可能性がある。

それによってノードが簡潔にかつ一義的にアドレス指定されるＩＤは、たとえば、数字であってもよい。たとえば、ノード「ｓｒｃ０」は、ＩＤ「７」によって指定されてもよい。

用語ＩＤとパス指示とを区別するために、以下の説明が与えられ得る。単純なＩＤの要件はただ１つである。すなわち、ＩＤは、システム全体を通じて１つだけのノードを一義的にアドレス指定しなければならない。それゆえ、ここでは、たとえば、すべてのノードを単純に番号付けすれば十分である。

通例、パス指示は、ＩＤにとどまらないさらなる特性を呈する。すなわち、パス指示は、グラフのルートから、中間ノードを介して、アドレス指定されるべきノードまでの経路を記載するローカルノード名を含む。グローバルＩＤとは対照的に、ローカルノード名は、当該ノードおよびその兄弟ノードに対してのみ一義的であればよい。ノードのローカルノード名を、ノードの親要素および／または先行する要素のローカルノード名と組み合わせることによって、結果として、同じくシステム全体を通じて一義的であるパス指示がもたらされる。

一実施形態において、データモデルの３つ以上のノードの各々のＩＤは、たとえば、数字または文字列またはハッシュ値であってもよい。

一実施形態において、コントローラ１２０は、属性を含むデータモデルの３つ以上のノードの各々の各属性について読み出し関数を含み、属性の値は、読み出し関数によって読み出し可能である。

たとえば、特定の実施形態において、シンクロナイザ１４０は、更新通知を受信し、更新通知内に含まれているＩＤを用いて、このノードに対処する、コントローラ１２０の該当するコントローラサブユニットを判定し（この目的のために、シンクロナイザ１４０は、たとえば、各ＩＤに対するコントローラサブユニットに対する参照を記憶している辞書／マップを保持する）、その後、これに、変更されるべき属性の名前および値を含む情報片を伝達する。コントローラ１２０のコントローラサブユニットは、その後、書き込み関数を用いてデータモデル１１０を変更する。

一実施形態によれば、シンクロナイザは、データモデルの上記ノードを指定する更新通知を受信するように構成されており、更新通知は、このノードの上記属性をさらに指定し、更新通知は、この属性の値がどのように更新されるべきかを示し、更新通知は、ノードのパス指示を指定し、コントローラは、更新通知に応じてこのノードのこの属性の値を更新するように構成されている。

一実施形態において、データモデルの３つ以上のノードがグラフ状の、たとえば、ツリー状の階層を形成し、それによって、データモデルの各ノードには、グラフ状階層内のデータモデルのノードのうちの少なくとも１つが直に後続し、かつ／または、グラフ状階層内のデータモデルのノードのうちの少なくとも１つが直に先行し、データモデルのノードのうちの少なくとも１つには、ツリー状階層内のデータモデルの２つのノードが直に後続する。

図１ｂは、一実施形態によるデータモデルのツリー状階層データ構造の例を使用することによって、そのようなグラフ状データ構造を示す。データモデルのツリー状階層において、ノード「ＤＨＤ（Ｒ）」および「Ｒｅｎｄｅｒｅｒ」は、ノード「ｒｏｏｔ」に直に後続する。逆に、ノード「ｒｏｏｔ」は、ノード「ＤＨＤ（Ｒ）」および「Ｒｅｎｄｅｒｅｒ」に直に先行する。ノード「Ｒｅｎｄｅｒｅｒ」には、ノード「ＬＳＳｅｔｕｐｓ」、「Ｓｃｅｎｅ」、「Ｓｐａｔｉａｌ Ｓｏｕｎｄ Ｗａｖｅ」、および「ＷａｖＰＩ」が直に後続する。逆に、ノード「Ｒｅｎｄｅｒｅｒ」は、ノード「ＬＳＳｅｔｕｐｓ」、「Ｓｃｅｎｅ」、「Ｓｐａｔｉａｌ Ｓｏｕｎｄ Ｗａｖｅ」、および「ＷａｖＰＩ」などに直に先行する。

一実施形態によれば、装置は、データモデルのノードのうちの１つに１つまたは複数の属性を追加する、データモデルの変更に関する情報を受信するように構成されているインターフェースをさらに備え、装置は、上記追加される１つまたは複数の属性の各々についての読み出し関数および書き込み関数を自動的に生成するように構成されており、上記属性の値は、読み出し関数によって読み出し可能であり、属性の値は、書き込み関数によって変更可能である。

実施形態において、生成される書き込み関数はローカルデータモデルの値を変更するだけでなく、たとえば、同時に、シンクロナイザが変更に関して報告されること、変更イベントがシステム内で伝搬されること、ならびに／または、接続されているオブザーバが変更に対応することができること、および／もしくは、自動化データの記録、取り消し／やり直しなどのようなさらなる物事が行われるようにされることを保証もする。

一実施形態において、装置は、ウェブアプリケーションによって、属性を含むデータモデルのノードの各々の属性の各々についての読み出し関数および書き込み関数を与えるように構成されており、それによって、上記読み出し関数および上記書き込み関数は、ウェブアプリケーションによって使用することができる。一実施形態において、ウェブアプリケーションは、たとえば、ＪａｖａＳｃｒｉｐｔおよび／またはＨＴＭＬにおいて実装されてもよい。

一実施形態によれば、装置は、ユーザ入力を受けてデータモデルのノードのうちの１つの属性のうちの１つに対する変化モニタリングを導入するように構成されている。

たとえば、上記変化モニタリングは、「イベント」を送信またはトリガするように構成されてもよい。

たとえば、装置は、変化モニタリングが導入されている１つの属性の値が変化するときに警告を出力するように構成されてもよい。

たとえば、警告を示すために、イベントにオブザーバを登録することができる。上記オブザーバは、イベントを受信し、その後、警告を出力する。しかしながら、対応は、警告の出力とは異なる任意の対応であり得る。

一実施形態によれば、サーバが提供される。サーバは、上述したような装置である。さらに、サーバは、１つまたは複数のクライアントからの登録を受信するように構成されている。加えて、サーバは、１つまたは複数のクライアントに、当該クライアントの登録を受けて、データモデルに関する情報を転送するように構成されており、データモデルに関する上記情報は、属性を有するデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、データモデルに関する情報は、データモデルの各ノードまたはデータモデルの少なくとも２つのノードについて、データモデルのいずれのノードが当該ノードに直に後続するか、および／または、データモデルのいずれのノードが当該ノードに直に先行するかをさらに示す。データモデルはまた、たとえば、ノードＩＤをも含む。

一実施形態において、サーバは、２つ以上のクライアントからの登録を受信するように構成されており、サーバのシンクロナイザは、データモデルのノードの属性の値が変化していることを示す、クライアントのうちの１つからのメッセージを受信するように構成されており、サーバのシンクロナイザは、上記クライアントのメッセージを受けて、データモデルのノードの属性の値が変化しているということを、サーバに登録している他の２つ以上のクライアントに報告するように構成されている。

逆に、サーバはまた、クライアントからデータモデルおよび更新を受信し得る。これは、たとえば、クライアントがたとえば、相対的に長い期間にわたってサーバに一切接続することなく作業しているとき、たとえば、オフラインで作業しているときに有用であり得る。

一実施形態によれば、サーバは、無線または有線でデバイスにメッセージを送信するように構成されており、上記メッセージは、データモデルのノードのうちの１つの属性が変化していることをデバイスに知らせる。

一実施形態において、装置は、たとえば、ＷＬＡＮによって、ＧＰＲＳによって、または、ＵＭＴＳもしくはＬＴＥによって、無線でデバイスにメッセージを送信するように構成されている。

一実施形態によれば、デバイスは、１つまたは複数のスピーカ信号を生成するためのレンダラである。一実施形態において、デバイスはまた、ＤＨＤ（登録商標）オーディオマトリックスであってもよい。たとえば、接続されているクライアントは、（３Ｄ）オーディオワークステーション、オーディオプラグイン（ＶＳＴ／ＲＴＡＳ／ＡｕｄｉｏＵｎｉｔｓなど）および／またはＩＰａｄ（登録商標）アプリであってもよい。

一実施形態において、サーバは、クライアントからクライアントのデータモデルに関する情報を受信するように構成されており、クライアントのデータモデルに関する上記情報は、属性を有するクライアントのデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、クライアントのデータモデルに関する情報は、クライアントのデータモデルの各ノードまたはクライアントのデータモデルの少なくとも２つのノードについて、クライアントのデータモデルのいずれのノードが当該ノードに直に後続するか、および／または、クライアントのデータモデルのいずれのノードが当該ノードに直に先行するかをさらに示す。

さらなる実施形態によれば、クライアントが提供される。サーバは、上述したような装置である。さらに、クライアントは、上述したサーバに登録するように構成されている。クライアントは、サーバに登録されると、サーバのデータモデルに関する情報を受信するように構成されており、サーバのデータモデルに関する上記情報は、属性を有するサーバのデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、サーバのデータモデルに関する情報は、サーバのデータモデルの各ノードまたはサーバのデータモデルの２つ以上のノードについて、サーバのデータモデルのいずれのノードが当該ノードに直に後続するか、および／または、サーバのデータモデルのいずれのノードが当該ノードに直に先行するかをさらに示す。さらに、クライアントは、サーバのデータモデルに関する情報に応じてそのデータモデルを更新するように構成されている。

一実施形態において、クライアントは、クライアントのデータモデルに関する情報をサーバに転送するように構成されており、クライアントのデータモデルに関する上記情報は、属性を有するクライアントのデータモデルのすべてのノードまたは２つ以上のノードの属性の値を含み、クライアントのデータモデルに関する情報は、クライアントのデータモデルの各ノードまたはクライアントのデータモデルの少なくとも２つのノードについて、クライアントのデータモデルのいずれのノードが当該ノードに直に後続するか、および／または、クライアントのデータモデルのいずれのノードが当該ノードに直に先行するかをさらに示す。

一実施形態によれば、クライアントは、オブジェクト指向オーディオシーンを生成するように構成されてもよい。

図１ｃは、一実施形態によるシステムを示す。

システムは、上述したサーバ１７０および上述したクライアント１６０を含む。クライアント１６０は、サーバ１７０に更新通知を送信するように構成されている。サーバ１７０のシンクロナイザは、更新通知を受信するように構成されており、更新通知は、サーバ１７０のデータモデルのノードのうちの１つを指定し、さらに、上記ノードの属性を指定し、上記属性の値がどのように更新されるべきかを示す。サーバ１７０のコントローラは、更新通知がノードのＩＤを指定する場合に、更新通知に応じて上記ノードの上記属性の値を更新するように構成されている。

以下において、最初に実施形態の基本概念を説明する。その後、好ましい実施形態およびそれらの概念を詳細に説明する。

実施形態は、キー値ベースのデータベースの利点を、ドキュメント指向型手法と組み合わせる全般的なメカニズムを提供する。その目的は、グラフの形状に構造化されているデータ構造を互いに、リアルタイムでかつ／または少ない待ち時間および／もしくは低い遅延で同期させることである。

実施形態によれば、アプリケーションの開発におけるこの手法は、以下の様なものである。

アプリケーションのデータを表すグラフ状データ構造が定義される。データ構造は、ＪＳＯＮまたはＸＭＬデータセットであってもよい（ＪＳＯＮ＝ＪａｖａＳｃｒｉｐｔオブジェクト表記法、ＸＭＬ＝拡張可能マークアップ言語）。

コード生成器、実行可能コントローラおよびデータモデルによって、グラフ状データ構造からコードが生成される。これは、サーバ側またはクライアント側のいずれで行われてもよい。このように生成されたコードは、たとえば、データをグラフモデルに読み出しおよび書き込むためのルーチン、変化に関心のあるオブザーバに通知するためのルーチン、ならびに、中央サーバおよび／もしくはそれに接続されているクライアントにデータモデルの変化を送信するためのルーチンを含む。

図２ａは、グラフの形状を有する、元のデータモデルに基づいて自動的に生成される３つの構造、すなわち、データモデル（モデル）２０１、オブザーバ構造（ビュー）２０３およびコントローラ構造（コントローラ）２０２を示す。

生成されるコントローラ構造２０２は、ツリー階層をサーバと、したがって同じく他のクライアントとも同期させるためのコードをすでに含んでいる。同期は、クライアントからサーバへ、および／または、サーバからクライアントへと実行されてもよい。

図２ｂは、クライアント２１０とサーバ２２０との間の同期の可能性のある過程を示す。図２ｂにおいて、クライアント２１０は、データモデル２１１と、コントローラ２１２と、ビュー２１３と、シンクロナイザ２１４とを含む。図２ｂのサーバ２２０は、データモデル２２１と、コントローラ２２２と、シンクロナイザ２２４とを含む。

たとえば、ユーザ（Ａｎｎａ）２０５が、何かを変更した場合、クライアント２１０のコントローラ２１２がこれを通知される。クライアント２１０のコントローラ２１２は、ツリー状データ構造（モデル）２１１を変更し、同時にまた、更新通知を用いてクライアント２１０のシンクロナイザ２１４に報告する。これはすべて、たとえば、自動的に生成される書き込み関数を用いて実行される。

クライアント２１０のシンクロナイザ２１４は、更新通知において、サーバ２２０に、たとえば、サーバ２２０のシンクロナイザ２２４に、変更を送信する。サーバ２２０は、更新通知を受けて、たとえば、サーバ２２０のコントローラ２２２によって、そのローカルデータモデル２２１に変更を入力する。加えて、サーバ２２０は同時にまた、すべてのクライアント（図２ｂには示されていない）に変更を送信する。

サーバまたはクライアントアプリケーションが始動すると、それらは最初に、グラフ状データ構造の定義をロードし、上述したコード生成器を用いてアプリケーションコードを生成する。

コード生成器は、たとえば、ハードディスクからロードされてもよく、または、たとえば、登録中にサーバからクライアントに送信されてもよい。

さらに、たとえば、グラフ状データ構造のノードの各々は、クライアントにとって一義的である、それに関連付けられているＩＤを有する。

ＩＤは、たとえば、以下のように生成することができる。各クライアントは最初に、システム全体を通じて一義的であるクライアントＩＤを与えられる。クライアントが新たなノードを生成する場合、システム全体を通じて一義的であるノードＩＤを形成するために、ローカルに一義的なノード指定子が、クライアントＩＤと組み合わされる。結果として、クライアントＩＤが送信されると、中央のＩＤ生成はもはや必要なくなる。利点は特に、クライアントにおける新たなノードの生成のためにサーバクエリが必要とされなくなることに存する。したがって、クライアントは、上記クライアントがオフラインであるときでさえ、システム全体を通じて一義的であるＩＤを生成することが可能になる。しかしながら、このための必要条件は、クライアントが少なくとも１度上記サーバに接続されていることである。クライアント内でローカルに生成されたノードは、（後の時点において）たとえば、サーバおよび残りのクライアントに送信されることになり、そこでローカルデータ構造に添付されることになる。しかしながら、ＩＤの名前を変えることはもはや必要なくなる。

たとえば、ＩＤは、動作時間中にのみ有効なままである。このＩＤによって、後に、ツリーの各ノードを直にアドレス指定することが可能になる。「／ｔｒｕｎｋ／ｂｒａｎｃｈ／ｔｗｉｇ／ｌｅａｆ／ｃｅｌｌ」のような長いパスアドレスの代わりにツリーのノードはこのとき、短いハッシュ、たとえば、「０ｄ４」を表すＩＤを介してアドレス指定することができる。これは、特に高レベルのデータトラフィックを有する用途にとって重要で
ある。

クライアントおよびサーバが始動されると、データ構造は初期相互マッチングを受けなければならない。クライアントがしばらくオフラインで作業した場合、たとえばサーバが、たとえばクライアントの現在のデータ構造を適合させることができるように、クライアントがそのデータ構造に関してサーバに報告するという点において、クライアントからサーバへとデータ構造をマッチングすることは有用であることが多い。しかしながら、クライアントが後の時点においてサーバから既存のアプリケーションをダウンロードすることを所望する場合、データ構造は、たとえば、クライアントがサーバからサーバのデータ構造を得るという点において、たとえば、サーバからクライアントへとマッチングされなければならない。

たとえば、データがサーバからクライアントへとマッチングされるべきであると仮定すると、これは、たとえば、以下のように実行することができる。

第１のステップにおいて、クライアントとサーバとの間のノードＩＤがマッチングされなければならない。すなわち、クライアント側およびサーバ側の関連ノードが、同じアドレスを有しなければならない。この目的のために、サーバは、たとえば、データツリーと同じ構造を有するが、最初はＩＤのみを含むＩＤツリーを生成する。代替的に、サーバおよび／またはクライアントはまた、たとえば、パスをＩＤと関連付けるテーブルを送信してもよい。このＩＤツリーは、クライアントに送信される。後者は、既存のＩＤを、サーバのものに置き換える。ツリーのオブザーバ（ビュー）はまた、ＩＤの名前の変更に関しても報告される。

このステップの後、実際のツリーデータが、サーバからクライアントに送信されなければならない。ここで、たとえば、これがどのように機能し得るかについて２つの可能性がある。

例１：第１の可能性は、クライアントにツリーデータを、ツリー状データ構造として送信し、これを対応するノードへと解析（入力）することである。

例２：第２の可能性は、サーバからクライアントにツリーデータを個々に、ノードごとに送信することである。この目的のために、たとえば、それぞれのノードのデータがノード指定子またはノード名とともにデータパケットにパケット化され、クライアントに送信される。クライアントは、ノード指定子を用いて関連ノードを判定することができ、対応するデータを上記関連ノードに書き込むことができる。

第１の可能性は、最初に、サーバからクライアントにおよび／またはその逆に、相対的に大きいデータ構造を送信するために使用される。第２の可能性は、小さいが頻繁に発生する任意の変化をクライアントとサーバとの間で効率的に交換するために使用される。

いくつかのクライアントを互いに接続するためには、このコンテキストにおいては、サーバが、当該サーバが得るデータパケットをクライアントから他のクライアントに単純に転送すれば十分である。ここで提案されているシステムによって、すべてのクライアントは同じツリー構造および同じＩＤを有する。したがって、クライアントの各々は、他のクライアントの変化の任意のメッセージを把握することが可能である。

実施形態は、キー値アドレス指定（キー値データベース）の性能優位性を、ドキュメント指向型手法（たとえば、ＸＭＬ、ＪＳＯＮデータ）および自動コード生成の可能性と組み合わせる。

データのキー値アドレス指定は、データに対する高速の機械的アクセスを可能にする。このように、ソフトウェアアプリケーションの高頻度、低待ち時間の同期が保証される。

ドキュメント指向型手法は、複雑に構造化されている大きいデータセットの管理を単純化する。結果として、たとえば、アプリケーション開発者にとってデータへのアクセスが非常に単純になる。その結果として、アプリケーションを高速かつ効率的に開発することができる。

自動コード生成は、コントローラ、パブリッシャ、パーサ、シリアライザ、シンクロナイザ、読み出し関数および書き込み関数のような回帰コード構成要素の生成が、グラフ状データ構造から自動的に生成されることを可能にする。これによって、配布ソフトウェアアプリケーションの開発期間をさらに低減することが可能である。

同様に、グラフ状データ構造からの自動コード生成はまた、配布ソフトウェアアプリケーションを開発する時間および費用も節約する。グラフ状データ構造が拡張されることは、自動的にまた、プロトコルの拡張、パーサ、シリアライザなど、シンクロナイザなども拡張されることを示す。

グラフ状データ構造間の同期は、アプリケーション開発者に対して絶対的にトランスペアレントであるように実行される。アプリケーション開発者は、単純にそのデータ構造を定義し、残りはコード生成器によって行われる。

各クライアントとサーバの両方がデータモデル全体（または、実施形態によれば、データモデルの少なくとも一部分）を保持するということに起因して、クライアントがオフラインで作業するようにし、後にそれらのクライアントを同期させることが可能である。同時に、システムの安定性が明らかに増大する。したがって、各クライアントが、サーバのバックアップとして同時に動作することができる。

実施形態の重要な使用分野は、ウェブ開発の分野である。コードは一般的に、機械コードの形態ではなく、ＪａｖａＳｃｒｉｐｔ、Ｒｕｂｙなどとしてオープンに送信される。

適用技術分野は、たとえば、機械の制御およびモニタリング、オーディオシステム、一般的な分散ソフトウェアアプリケーション、およびウェブアプリケーションの制御およびモニタリングのような、協働分散リアルタイム適用である。

実施形態は、たとえば、ウェブベースであってもよく、分散アプリケーションの開発を明らかによりユーザフレンドリかつよりコスト効率的にし、それらをクロスプラットフォームに設計する、ユーザインターフェースフレームワーク（ＵＩ．ＦＭ）として実装されている。

いくつかの実施形態は、たとえば、３Ｄオーディオシステムを、たとえば、スタジアム内でいくつかの聴取位置から同時に音響的に導入するために使用されてもよい。

図２ｃは、ＵＩ．ＦＭを使用しない例を示す。図２ｃは、Ｂｒｅｇｅｎｚのレイクステージを表す。正面に、ステージ２３０が図示されている。多数のスピーカ２３１、２３２、２３３、２３Ｎがステージ２３０上に設置されている。聴衆の領域に、調整可能制御パラメータに従ってスピーカ２３１、２３２、２３３、２３Ｎを駆動するＦｏＨ２４０（「Front of House」：ステージ建物の正面中央の空間、音声モニタリングオペレータが音声を調整する場所）が見える。ＦｏＨは、調整卓２４１、方向ミキサ（ｄｍ）２４２、設定ツール（ｃｏｎｆｉｇ）２４３などを含む。たとえば、広い聴衆領域２５０、７，０００が人のための座席を提供する。

目的は、すべての聴衆メンバが最適な音声を聴くことである。この目的のために、たとえば、本発明の実施形態が利用可能でない場合、以下の手法を採用することになる。すなわち、第１の座席、たとえば、右手側の位置２５１に行く。この第１の位置２５１において音声を聴き、その後、携帯電話を介してＦｏＨ２４０に任意の変更要求を送信する。ＦｏＨ２４０において、それに従ってパラメータが変更される。その後、音声を聞き、音声に満足した場合、第２の位置２５２、たとえば、さらに左のある位置に移動する。そこで、再びそれに従って音声を聴き、再び、ＦｏＨ２４０に任意の変更要求を、無線によって送信する。ＦｏＨにおいて、それに従って再びパラメータが変更され、第２の位置２５２において、それに従って変更された音声を再び聴き、その後再び、それに従ってＦｏＨによるマッチングを実施する。その後、次の位置に移動し、それに従ってこのプロセスを継続する。そのようなプロセスは非常に費用および労力がかかる。

以下において、実施形態を詳細に説明する。ＵＩ．ＦＭの機能を説明する。ＵＩ．ＦＭは、新規のユーザインターフェースフレームワークである。

図２ｄは、この新規のソリューションが実装される実施形態を示す。ここでも、ステージ２６０、ＦｏＨ２７０および聴衆領域２８０が図示されている。しかしながら、図２ｄの例では、ＵＩ．ＦＭサーバ２７５が１つだけ設置されている。ＵＩ．ＦＭサーバ２７５は、システム内の構成要素に接続されている。３つの異なる端末デバイス、すなわち、２つのｉＰａｄ（登録商標）２８２、２８３およびｉＰｈｏｎｅ（登録商標）２８１が見える。端末デバイスはまた、任意の他の適切な端末デバイスであってもよい。

たとえば、３人の音響技師２８４、２８５、２８６が、スタンド内の異なる位置に同時に移動することができ、ここで、音響技師２８４、２８５、２８６の各々が、音声を位置付け、構成および／または設定することが可能である。変更は、各事例においてそれぞれの携帯端末デバイス２８１、２８２、２８３を介して行われる。携帯端末デバイス２８１、２８２、２８３は、たとえば、ＷＬＡＮを介してＵＩ．ＦＭサーバ２７５に接続されている。端部情報がＵＩ．ＦＭサーバ２７５内で設定され、それに従ってスタジオ室内の構成要素を制御する（図２ｄには示されていない）。たとえば、Ｃｏｎｆｉｇ、Ｒｉｍおよび調整卓が、制御される構成要素であってもよい。

端末デバイス２８３に対して音響技師２８６によって実行される任意の変更は、他の端末デバイス２８１、２８２に直ちに転送される。すなわち、他の端末デバイス２８１、２８２がそれに従って更新される。これは、他の参加者（たとえば、図２ｄにおいては他の音響技師）２８４、２８５が、参加者の１人２８６が変更したものが何かを直ちに知ることができ、それに従って変化を聞くことができ、それに直ちに対応することができることを意味する。言い換えれば、位置Ｃに位置する音響技師の１人が位置Ｃにおいて非常に良好に聞こえるが、位置Ｂにおいてはそうでない何かを変更した場合、位置Ｂに位置する人２８５は、それに即座に対応することができ、異なる設定を実施し、したがって、再び変更を行うことができる。これによって、位置Ａ、ＢおよびＣに位置する３人２８４、２８５、２８６がパラメータを最適にネゴシエート、たとえば、制御することができる。したがって、図２ｄの実施形態は、図２ｃを参照して上記で説明したものと比較して明らかな単純化および改善を表す。

異なる適用シナリオ、すなわち、音響システムの車内への設置が、図２ｅに示されている。たとえば、内部に４つの座席２６１、２６２、２６３、２６４を有する車両、ここでは、自動車２５５が見られる。多数のスピーカ２６５を備える音波処理システムが、それに従って車両内に設置されている。各座席２６１、２６２、２６３、２６４にとって最適な音声が生成されることが所望される。

これを実施することを可能にするために、４つのｉＰａｄ（登録商標）２６６、２６７、２６８、２６９を、自動車２５５内で使用することができる。４人の音響技師２５６、２５７、２５８、２５９が、ここで、自動車２５５内で４つのｉＰａｄ（登録商標）２６６、２６７、２６８、２６９を利用することができる。たとえば、自動車２５５内の４人の音響技師２５６、２５７、２５８、２５９は、ｉＰａｄ（登録商標）２６６、２６７、２６８、２６９を用いて音声を同時に設定することができる。たとえば、自動車２５５内の４人の音響技師２５６、２５７、２５８、２５９が、Ｂｒｅｇｅｎｚのレイクステージの事例において図２ｄの例ですでに説明したように、ｉＰａｄ（登録商標）２６６、２６７、２６８、２６９によって、音声を直ちに聞き、最適な（全体的な）音声を互いにネゴシエートすることができる。この目的のために、Ｗｉｆｉを介してｉＰａｄ（登録商標）２６６、２６７、２６８、２６９が接続されているＵＩ．ＦＭサーバ２７６が利用される。ユーザ２５６がデバイス２６６に対して実施する任意の変更がデバイス２６６からＵＩ．ＦＭサーバ２７６に送信され、ＵＩ．ＦＭサーバ２７６は、変更を他のデバイス２６７、２６８、２６９に転送する。このすべてが、低レベルの遅延で実施される。

図２ｆは、ＩｌｍｅｎａｕのＦｒａｕｎｈｏｆｅｒ Ｉｎｓｔｉｔｕｔ ｆｕｅｒ Ｄｉｇｉｔａｌｅ Ｍｅｄｉｅｎｔｅｃｈｎｏｌｏｇｉｅの音響研究所が提示されている一実施態様によるさらなる実施形態を示す。ここには、互いに協働すべきである大量のサーバ技術がある。中でも、図２ｆは、レンダラ２９１、加えて照明コントローラ２９２、さらに増幅器２９３、およびオーディオマトリックス２９４を示している。図２ｆの左手側には、いくつかの端末デバイス、たとえば、ＰＣワークプレイス２９５、第１のｉＰａｄ（登録商標）（ｉＰａｄ（登録商標）１）２９６、第２のｉＰａｄ（登録商標）（ｉＰａｄ（登録商標）２）２９７、および、たとえば、ゲストの端末デバイス２９８が提示されている。たとえば、ゲストもまた、他のデバイス２９１、２９２、２９３、２９４、２９５、２９６、２９７と協働すべきである自身の携帯電話２９８を携行することができる。

たとえば、図２ｆの右手側のハードウェア２９１、２９２、２９３、２９４を、図２ｆの左手側のデバイス２９５、２９６、２９７、２９８によって制御することができることが望ましい場合がある。たとえば、すべてのパラメータが、図２ｆの左手側のデバイス２９５、２９６、２９７、２９８によって設定されることを可能にすることが意図されている。

図２ｆの左手側のデバイス２９５、２９６、２９７、２９８と、図２ｆの右手側のハードウェア２９１、２９２、２９３、２９４との相互接続は、ＵＩ．ＦＭサーバ２９０によって実施される。ＵＩ．ＦＭサーバ２９０は、一方では、図２ｆの右手側のハードウェア２９１、２９２、２９３、２９４に接続されている。たとえば、レベルデータおよび制御データが、ＵＩ．ＦＭサーバ２９０とレンダラ２９１との間で交換される。したがって、図２ｆの右手側のさらなるハードウェア２９２、２９３、２９４も、ＵＩ．ＦＭサーバ２９０に接続されている。したがって、図２ｆの左手側の端末デバイス２９５、２９６、２９７、２９８も、ＵＩ．ＦＭサーバ２９０に接続されている。ユーザが、ｉＰａｄ（登録商標）２９６、２９７のうちの１つを介して、たとえば、「ｉＰａｄ（登録商標）１」２９６を介して入力を行うと、たとえば、制御情報を入力すると、上記入力は、それに従ってＵＩ．ＦＭサーバ２９０に送信される。その後、ＵＩ．ＦＭサーバ２９０は、上記情報を、それに従って図２ｆの右手側の周辺ハードウェア２９１、２９２、２９３、２９４に渡す。

ＵＩ．ＦＭは多数の利点を備える。たとえば、ＵＩ．ＦＭサーバは、たとえば、図２ｇに示すように、ウェブサーバ２１５として実装することができ、クライアント、たとえば、ｉＰａｄ（登録商標）２１６、２１７が、ウェブクライアント２２６、２２７を実装することができる。したがって、クライアント２１６、２１７にソフトウェアをインストールする必要はなく、クライアント２１６、２１７の登録を受けて、ウェブサーバ２１５がクライアント２１６、２１７にソフトウェアを配信する。ウェブサーバ２１５および／またはウェブクライアント２２６、２２７として実装することに起因して、大量の支出が節約される。

ＵＩ．ＦＭのさらなる利点は、システムが低遅延で動作することである。たとえば、ウェブクライアント２２６として実装されているクライアント２１６の１つに置かれる制御パラメータは、ＵＩ．ＦＭサーバ２１５に即座に送信される。ＵＩ．ＦＭサーバ２１５はその後、１つまたは複数のさらなるクライアント、たとえば、さらなるｉＰａｄ（登録商標）２１７に、制御データを即座に送信する。このとき、（１つまたは複数の）さらなるクライアント（複数可）２１７もまた、その上に位置する１つのウェブクライアント２２７を有する。対応するさらなる端末デバイス２１７上のそれぞれのさらなるウェブクライアント２２７はその後、問題になっているパラメータを直ちに更新する。同時に、ＵＩ．ＦＭサーバ２１５は、接続されている周辺機器、たとえば、レンダラ２２９に、パラメータ更新に関して報告する。

一実施形態によれば、クライアントは、ウェブブラウザにおいて動作するように構成されてもよい。その利点は、プログラムがクライアント側のウェブブラウザにおいて動作することに起因して、アプリケーション開発者がその中に開発者がコマンドを直に入力することができるコマンドライン（図２ｇの参照符号２２８）を開くことができることである。たとえば、図２ｇの実施形態において、コマンド「ｓｃｅｎｅ．ｓｏｕｒｃｅ０．ｐｏｓ ＝ ．．．」を入力することができ、それによって、たとえば、「ｓｏｕｒｃｅ０」の位置を変更することができる。したがって、システムはスクリプト可能性が高い。

一実施形態において、クライアントは、たとえば、サーバに、クライアントのデータモデルの２つ以上のノードのＩＤを送信するように構成されてもよい。

以下において、図３に示す例示的な設定によって、システムおよびその構成要素を説明する。図３の各単一の構成要素は単独で実装されてもよく、したがって、単独で一実施形態を表すことが理解される。さらに、図３の１つまたは複数の構成要素に関連して説明されている一般的な方法および一般的な実施態様がまた、一般的に実施されてもよく、したがってまた、一般的な方法および／または一般的な実施態様として、本発明の一実施形態をも表すことが理解される。

一例を上げると、図３は、ワークプレイスＰＣ３５０を表す。加えて、図３は、モバイルｉＰａｄ（登録商標）３６０を示す。さらに、図３は、レンダラ３８０、および、オーディオマトリックスユニット３９０、たとえば、ＤＨＤ（登録商標）オーディオマトリックスユニットを示す。さらに、図３は、ＵＩ．ＦＭサーバ３００を示す。

レンダラ３８０は、サブモジュール、たとえば、立体音響波サブモジュール３８１を含んでもよい。さらに、レンダラ３８０は、シーン、たとえば、シーンユニット３８２を保持してもよい。さらに、レンダラ３８０は、たとえば、スピーカ設定を構成するためのスピーカ設定ユニット３８３を含んでもよい。さらなるサブモジュールが存在してもよい。たとえば、Ｗａｖプレーヤ３８４が、さらに存在してもよい。同様に、オーディオマトリックスユニット３９０がサブモジュールを備えてもよい。たとえば、ＤＨＤ（登録商標）オーディオマトリックスユニット３９０は、たとえば、クロスポイントマトリックスサブモジュール３９１内にクロスポイントマトリックスを含んでもよい。

ＵＩ．ＦＭサーバ３００は、たとえば、レンダラ３８０および／またはＤＨＤ（登録商標）オーディオマトリックスによって、図示されているような実世界を、グラフ状、たとえば、ツリー状のデータモデル３１０にマッピングするように構成されている。たとえば、図３の右手側のＵＩ．ＦＭサーバ３００の表現は、データモデル３１０を示す。データモデル３１０内の最上部には、ルートノード（「Ｒｏｏｔ」）が図示されている。ルートノードの下部には、ＤＨＤ（登録商標）オーディオマトリックス（「ＤＨＤ（Ｒ）」）およびレンダラが図示されている。ＤＨＤ（Ｒ）オーディオマトリックス３９０を表す、データモデル３１０内のノードＤＨＤ（Ｒ）は、その下部に位置する「ｃｒｏｓｓｐｏｉｎｔ ｍａｔｒｉｘ」ノードを有する。クロスポイントマトリックス３９１の上記表現は、翻って、接点、たとえば、ｘ₀、ｘ₁およびｘ₂を含む。データモデル３１０内のレンダラ３８０の表現は、翻って、レンダラ３８０の現実のサブモジュールを表す後続のノードとして、その下部に位置するノード「ｓｐｅａｋｅｒ ｓｅｔｕｐ」、「Ｗａｖ Ｐｌａｙｅｒ」および「Ｓｃｅｎｅ」を有する。シーンは、翻って、ソース、たとえば、ｓｒｃ０、ｓｒｃ１およびｓｒｃ２を有する。ソースｓｒｃ０、ｓｒｃ１およびｓｒｃ２は、それらに関する限りでは、特性、たとえば、位置ｐｏｓ、回転ｒｏｔ、ｏｎ／ｏｆｆ、消音などをも有する。これらのサブモジュール、属性および関係のすべてを、データモデル３１０によってマッピングすることができる。したがって、データモデル３１０は、特に有利に構成されているメモリを表す。

ＵＩ．ＦＭサーバ３００および周辺ハードウェア３８０、３９０の相互作用を下記に説明する。

たとえば、実施されるべきことが、たとえば、データモデル内のソースｓｒｃ０、ｓｒｃ１、ｓｒｃ２が変更されるとき、たとえば、レンダラ３８０が上記情報を得、また、それに従って、対応するソース、たとえば、ｓｒｃ０、ｓｒｃ１またはｓｒｃ２の位置の変更の形態でそれを実施することであるとき、特定の問題が生じる。

これに対する解決策を実施するために、コントローラ（制御ユニット）３２０が、ＵＩ．ＦＭサーバ３００内に導入される。たとえば、データモデルのｓｒｃ０に関連して、ＵＩ．ＦＭサーバ３００のコントローラ３２０内にも、ノードｓｒｃ０がある。ソースｓｒｃ０の各特性について、たとえば、特性「ｐｏｓ」、「ｒｏｔ」、「ｏｎ／ｏｆｆ」および「ｍｕｔｅ」について、コントローラ３２０は、特性の値を設定するための対応する関数、および、特性の値を読み出すための対応する関数を備える。たとえば、コントローラ３２０は、特性ｐｏｓの値を設定するためのｓｅｔＰｏｓ（．．．）関数、および、特性ｐｏｓの値を読み出すためのＰｏｓ（．．．）関数を提供する。たとえば、データモデル内の位置を変更するよう所望する場合、ｓｅｔＰｏｓ（．．．）関数を呼び出す。ｓｅｔＰｏｓ（．．．）関数において、その位置が設定されるべき設定先である現在の位置、たとえば、（１， ２， ３）が示される。コントローラ３２０内の関数ｓｅｔＰｏｓ（．．．）を呼び出すことによって、データモデル内の位置ｐｏｓが変更される。属性が値を有すると記載されているとき、「値」という用語は、広い意味において理解されるべきであり、たとえば、数値、文字列値、すなわち、単語または文を表す値、（１， ２， ３）のような数値のタプル、または、たとえば、文字列値のタプル、たとえば、（“Ｈａｌｌｏ Ｗｅｌｔ”）（“ｈｅｌｌｏ ｗｏｒｌｄ”）、「コード」および任意の他の種類の値型を含む。

属性（特性）の値を指定および変更するだけの可能性に加えて、ｓｅｔＰｏｓ（．．．）関数は、接続されているビューに報告する可能性をさらに提供する。

一実施形態において、デバイス、たとえば、レンダラ３８０またはＤＨＤ（登録商標）オーディオマトリックス３９０は、無線または有線でそれに送信されているメッセージを有し、上記メッセージは、デバイスに、データモデル３１０のノードのうちの１つの属性が変化していることを報告する。

そのようなメッセージによって、たとえば、レンダラを制御するために、たとえば、ビュー、すなわち、データモデル３１０および／もしくはその属性に対するビュー、ならびに／または、コントローラ構造３２０に対するビューを表すレンダラドライバ３３０がプログラムされるべきである。そのようなビューによって、周辺機器、たとえば、レンダラを、それに従って制御することができる。

たとえば、ＵＩ．ＦＭサーバ３００のレンダラドライバ３３０は、ビューとして、ＵＩ．ＦＭサーバ３００のコントローラ３２０のノードｓｒｃ０に登録することができる。それによって、レンダラドライバは、コントローラ３２０のｓｒｃ０ノードのビューになる。ＵＩ．ＦＭサーバ３００のコントローラ３２０のｓｒｃ０．ｓｅｔＰｏｓ（．．．）関数を呼び出すことによってデータモデル内の位置が設定されると、ビュー３３０（すなわち、レンダラドライバ３３０）は同時に、それに従って通知される。

そのような通知を受けて、レンダラドライバ３３０はその後、データモデル３１０から、更新されているｓｒｃ０の特性ｐｏｓ（すなわち、ソースｓｒｃ０の位置）をロードする。しかしながら、特性はまた、通知のフレームワーク内でレンダラドライバ３３０に通信されてもよい。結果として、データモデルに対するアクセスが省かれる。

加えて、レンダラドライバ３３０は、プロトコルメッセージを生成し、上記プロトコルメッセージをレンダラ３８０に送信する。たとえば、プロトコルメッセージは、ＯＳＣ制御メッセージであってもよい（ＯＳＣ＝オープンサウンドコントロール）。

レンダラドライバ３３０に加えて、または、レンダラドライバ３３０に対する代替形態として、ＵＩ．ＦＭサーバ３００は、同じくたとえばコントローラ３２０のソースｓｒｃ０に登録されるさらなるドライバを含んでもよいが、上記さらなるまたは代替的なビューは、異なる挙動を呈する。ここでも、たとえば、ｓｒｃ０の特性ｐｏｓ（すなわち、ｓｒｃ０の位置）が変化すると、データモデルが変更され、接続されているドライバのすべて（すなわち、それに従って登録されているドライバ）が通知される。接続されているドライバは、対応する周辺ハードウェアに送信される対応するプロトコルメッセージを生成する。対応する変更が、その後、周辺ハードウェアにおいて実施される。

逆のデータ送信および更新様式も可能であり、たとえば、プロセスは、たとえば、レンダラ３８０内で、たとえば、ｓｒｃ０の位置を変更してもよい。この事例において、レンダラ３８０は、対応するレンダラドライバ３３０にプロトコルメッセージを送信することになる。そのようなメッセージによって、レンダラドライバ３３０は、対応する位置が変化しているということを通知され、コントローラ３２０のｓｒｃ０のｓｅｔＰｏｓ（．．．）関数を呼び出し、データモデル３１０内のｓｒｃ０の特性ｐｏｓの値がその後、変更される。

レンダラドライバ３３０が、レンダラドライバ自体が引き起こしたｓｒｃ０の位置の変化に関して通知されることを回避するために（必ずしもそうとは限らないが、無限ループの危険の可能性がある）、ＵＩ．ＦＭサーバ３００のレンダラドライバ３３０は、ｓｒｃ０の位置の変化、たとえば、レンダラドライバ自体が引き起こした変化に関して通知されることを所望しないことを指定することができる。

それと同様に、たとえば、ＤＨＤ（登録商標）オーディオマトリックスユニット３９０のさらなるドライバ、たとえば、レンダラドライバが、ＵＩ．ＦＭサーバ３００内に実装されてもよい。

ＵＩ．ＦＭサーバ３００のコントローラ３２０のさらなる特性を下記に説明する。

ソースｓｒｃ０だけでなく、さらなるソースｓｒｃ１およびｓｒｃ２ならびにシーンも、コントローラ３２０内に含まれることが留意されるべきである。言い換えれば、データモデル３１０内の各ノードに対してコントローラサブユニットがある。

これは、ＵＩ．ＦＭサーバ３００の重要な特性である。最終的に、ツリー構造を有するデータモデル階層３１０に加えて、それと同様にこれもツリー構造を有するコントローラ階層３２０が結果としてもたらされる。コントローラ３２０の上記ツリー構造はこのとき、ちょうどデータモデル階層３１０のツリー構造と同様のものと考えられる。

実施形態によれば、ＵＩ．ＦＭサーバ３００のデータモデル階層３１０は、ユーザによって定義されてもよい。たとえば、ＵＩ．ＦＭサーバ３００のデータモデル階層３１０は、完全にユーザによって定義されてもよい。たとえば、コントローラ階層３２０がデータモデル階層３１０から生成されるか、または逆に、データモデル階層３１０がコントローラ階層３２０から生成され得るかのいずれかの可能性がある。好ましい実施形態において、コントローラ階層３２０が定義され、データモデル階層３１０がそこから導出される。

したがって、ＵＩ．ＦＭサーバ３００の１つの特定の特性は、２つの並列階層、すなわち、コントローラ階層３２０およびデータモデル階層３１０が共存し、互いに関連していることに存する。したがって、コントローラ階層３２０内の各ノードは、データモデル階層３１０内の対応するノードに対する対応する参照(reference)を有する。たとえば、コントローラ階層３２０のルートノードとデータモデル階層３１０のルートノードとの間に参照があり得る。したがって、コントローラおよびデータモデル階層３１０ならびに接続されている周辺ハードウェアの間に接続が存在する。

制御デバイスとＵＩ．ＦＭサーバ３００との間ならびに／または制御デバイスとＵＩ．ＦＭサーバ３００のコントローラ階層３２０および／もしくはデータモデル階層３１０との間の接続は下記において説明される。

従来技術において、データモデル３１０はデータベース内で編成される。従来技術において、クライアントはさらに、データベースに問い合わせを送信し、データベースから返ってくる応答を受信し、その後、得られたデータを用いて作業することが可能になる。

さらに、従来技術によれば、クライアントは、データモデル３１０のノードに登録することができ、データモデルのノードが変化するときにメッセージを受信する。データモデル自体は、たとえば、データベース内に記憶されてもよい。しかしながら、データモデル３１０の編成およびデータモデル３１０が更新されるべき様式は、従来技術においては、たとえば、完全にアプリケーション開発者に委ねられたままである。

一実施形態によれば、ユーザを大量の作業から解放するメカニズムが提供される。このメカニズムを、以下において説明する。

クライアント、たとえば、ワークプレイスＰＣ３５０が始動すると、クライアントはＵＩ．ＦＭサーバ３００に登録する（図３のワークプレイスＰＣ３５０とＵＩ．ＦＭサーバ３００との間の項目（１）を参照されたい）。したがって、クライアントは最初に、ＵＩ．ＦＭサーバ３００に登録する。

その後、ＵＩ．ＦＭサーバ３００は、コントローラ階層３２０をクライアントに送信する（図３のワークプレイスＰＣ３５０とＵＩ．ＦＭサーバ３００との間の項目（２）を参照されたい）。コントローラ階層３２０とともに、データモデル階層３１０も送信される。これは、クライアントが、たとえば、コントローラ階層３２０からデータモデル階層３１０を導出するという点において、または、データモデル階層３１０は、コントローラ階層３２０に加えて明示的に送信されるという点において黙示的に実行されてもよい。

コントローラ階層３２０の（および、可能性としてまたデータモデル階層３１０に加えての）送信に起因して、クライアントとＵＩ．ＦＭサーバ３００の両方に同じ階層が存在する。すなわち、コントローラ階層３５２およびデータモデル３５１が、クライアント、たとえば、ワークプレイスＰＣ３５０に存在する。

コントローラ階層３２０およびデータモデル階層３１０の送信はまた、たとえば、ワークプレイスＰＣ３５０に加えて、たとえば、ｉＰａｄ（登録商標）３６０がＵＩ．ＦＭサーバ３００に登録する場合は、同じく当該ｉＰａｄ（登録商標）についてのように、さらなるクライアントについても実施されてもよい。したがって、図３のｉＰａｄ（登録商標）３６０は、ちょうど図３のワークプレイスＰＣのように、コントローラ階層３６２およびデータモデル３６１を備える。

ワークプレイスＰＣ３５０のコントローラ階層３５２は、「ｒｏｏｔ」、および、加えて、ＵＩ．ＦＭサーバ３００のコントローラ階層と同様に、「ｒｏｏｔ」から下流に接続されているノード、たとえば、中でも、ｓｒｃ０およびその下流ノードを備える。同じことが、クライアント内のデータモデル、たとえば、ワークプレイスＰＣ３５０のデータモデルおよびｉＰａｄ（登録商標）３６０のデータモデルに当てはまる。たとえば、ソースｓｒｃ０が、それらのコントローラ階層３５２、３６２にも見出される。

ＵＩ．ＦＭサーバ３００に登録する各クライアント内で、ＵＩ．ＦＭサーバ内に導入されているものと同じデータモデル構造３５１、３６１が最初に導入される。これは、たとえば、ｉＰａｄ（登録商標）３６０のコントローラ階層３６２およびデータモデル３６１に適用される。したがって、クライアント３５０、３６０のコントローラ階層３５２、３６２およびデータモデル３５１、３６１のすべてがＵＩ．ＦＭサーバ３００のデータモデル３１０およびコントローラ階層３２０とマッチングされている。

加えて、実際のデータ送信は、サーバからクライアントへと行われる（図３のワークプレイスＰＣ３５０とＵＩ．ＦＭサーバ３００との間の項目（３）を参照されたい）。したがって、実際には、コントローラ階層３２０およびデータモデル３１０の階層構造をサーバ３００からクライアント３５０に送信するだけでなく、正確には実際のデータ、すなわち、たとえば、データモデル内の属性が各事例において有する値に関するデータ（すなわち、それぞれソースｓｒｃ０、ｓｒｃ１、ｓｒｃ２の位置ｐｏｓがいずれの値（複数可）を有するか、など）も送信する必要がある。

実施形態によれば、ＵＩ．ＦＭサーバ３００のコントローラ階層３２０の各ノードは、それと関連付けられているＩＤを有する。ＩＤは、ノードを迅速にアドレス指定する役割を果たす。したがって、通常は、コントローラ階層３２０およびデータモデル３１０がグラフ状構造であることに起因して、データモデル内および／またはコントローラ階層内の特定の要素をアドレス指定するように、完全な経路、たとえば、「ｒｏｏｔ／Ｒｅｎｄｅｒｅｒ／Ｓｃｅｎｅ／ｓｒｃ０」が示されなければならない。ここでは、各ノードがそれに割り当てられているＩＤを有するということに起因して、ノードの各々に対する短い識別子があり、したがって、それぞれのノードをその識別子によってアドレス指定することが可能である。比喩的に言えば、各ノードについて短い「電話番号」があり、長いパスを示す代わりに、この電話番号を使用することができる。たとえば、ＵＩ．ＦＭサーバ３００のコントローラ階層３２０において、ノード「ｒｏｏｔ」はＩＤ０を有し、ノード「ＤＨＤ（Ｒ）」はＩＤ１を有し、ノード「Ｒｅｎｄｅｒｅｒ」はＩＤ２を有し、ノード「ＬＳＳｅｔｕｐｓ」はＩＤ３を有し、ノード「ＷａｖＰＩ．」（Ｗａｖプレーヤ）はＩＤ４を有し、ノード「ｃｏｕｐｌｉｎｇ ｐｏｉｎｔ ｍａｔｒｉｘ」はＩＤ５を有し、ノード「Ｓｃｅｎｅ」はＩＤ６を有し、ノード「ｓｒｃ０」はＩＤ７を有し、ノード「ｓｒｃ１」はＩＤ８を有する、などである。

したがって、ＩＤはＵＩ．ＦＭサーバ３００からクライアント３５０に送信され（図３のワークプレイスＰＣ３５０とＵＩ．ＦＭサーバ３００との間の項目（４）を参照されたい）、クライアント３５０のデータモデル３５１およびコントローラ階層３５２、たとえば、ワークプレイスＰＣクライアント３５０のデータモデル３５１およびコントローラ階層３５２に書き込まれる。

このように、データ送信に後続してＩＤが送信される。すなわち、コントローラ階層と同じ構造を有するＩＤツリーが生成される。その差は、個々のノードがその中に位置するＩＤを有することである。その後、ＩＤは対応するノードに書き込まれる。

上記の説明において、項目（２）、（３）および（４）は、ＵＩ．ＦＭサーバ３００におけるクライアント３５０の初期化において所望される任意の順序で実施されてもよいことが理解されるべきである。

以下において、ソース（音源）がワークプレイスＰＣ３５０によって位置決めし直される、一実施形態による一実施例を説明することとする。言い換えれば、たとえば、ワークプレイスＰＣ３５０上で動作しているウェブアプリケーションが、たとえば、仮想ソース（音源）の空間位置を位置決めし直すために使用される。たとえば、例として３つの音源のそれぞれの音声が３つの別個のオーディオ信号において収集されるシナリオがあり得る。

上記３つのオーディオ信号が後の時点において１つの全体的な信号に混合されるとき、３つのオーディオ信号は、音源の仮想位置に従って混合されることになる。たとえば、第１の音源の仮想位置が聴き手の想定される位置から遠く離れて位置する場合、全体的な信号に関するそのオーディオ信号の部分は一般的に、その仮想位置が想定される聴き手の位置の近くに位置する第２の音源のオーディオ信号の部分よりも小さい。

しかしながら、たとえば、３つのソースの３つのオーディオ信号から複数のスピーカ信号を生成することも可能である。たとえば、第１の音源の仮想位置が、各事例において考慮されるスピーカの（想定される）位置から遠く離れて位置する場合、スピーカ信号に関するそのオーディオ信号の部分は一般的に、その仮想位置が（想定される）スピーカ位置の近くに位置する第２の音源のオーディオ信号の部分よりも小さい。

ワークプレイスＰＣ３５０上の上述したウェブアプリケーションによって、ソース（音源）の（仮想）位置をこのように設定することができ、それによって、ワークプレイスＰＣ３５０から、レンダラ３８０がソースの個々のオーディオ信号を全体的な信号または複数の個々のスピーカ信号にどのように混合するかを制御することができる。

それぞれのソースを動かすことを可能にするために、ビュー３５３がクライアント（たとえば、ワークプレイスＰＣ３５０）に導入される。この目的のために、ワークプレイスＰＣ３５０は、このビュー３５３を含む。

ソース３５８が、図３のワークプレイスＰＣ３５０のビュー３５３内に表現されている。ソース３５８は、たとえば、タッチスクリーンによって示され、指で触れて、たとえば、引っ張られることによって動かすことができる。この移動が行われると、たとえば、イベントがトリガされる。

ユーザの側のこのソースの移動の結果として、たとえば、ソースは新たな位置、たとえば、位置（ｘ， ｙ， ｚ） ＝ （８， ９， １０）に移動されることになる。この位置は、それに従って、コントローラ階層の一部分である関数ｓｅｔＰｏｓ（．．．）を介して、ソースｓｒｃ０に設定される。クライアント３５０のコントローラ３５２は同時に、ＵＩ．ＦＭサーバ３００に関連してすでに説明したような更新メカニズムを、変更すべきところは変更して、含む。ちょうどＵＩ．ＦＭサーバ３００のように、ワークプレイスＰＣ３５０はまた、ビュー３５３をも有する。ソースが移動されるときに呼び出されるｓｅｔＰｏｓ（．．．）関数は、ワークプレイスＰＣのデータモデル内での位置を設定する。

ワークプレイスＰＣ３５０のデータモデル３５１内でのソースの位置の変化はその後、ＵＩ．ＦＭサーバ３００に送信される。実施形態によれば、上述したＩＤがデータ送信に使用される。この文脈において、たとえば、ｓｒｃ０に対処する、ＰＣ３５０のコントローラのあるユニットが、ワークプレイスＰＣ３５０のシンクロナイザ３５４に報告する。

シンクロナイザ３５４は、データが変化したときに報告されるある種のビューであると想定され得る。たとえば、シンクロナイザ３５４は、対応するＩＤを使用し、たとえば、ＩＤ７を有するノード内で位置が変化したこと、および、対応する位置の値が何であるか（たとえば、（８， ９， １０））を記述するメッセージを生成する。シンクロナイザ３５４によって生成される上記更新通知、たとえば、「７： Ｐｏｓ： （８， ９， １０）」は、ＵＩ．ＦＭサーバ３００に送信される。

したがって、ＵＩ．ＦＭサーバ３００上にも同様に、更新通知によって送信されるｓｒｃ０の新たな位置を受信するシンクロナイザ３４０がある。ＵＩ．ＦＭサーバ３００のシンクロナイザ３４０は、受信した位置を、対応するＩＤを有するノード、すなわち、この事例においてはたとえば、ＩＤ７を有するノードに送信する。

ＵＩ．ＦＭサーバ３００のシンクロナイザ３４０はその後、ＩＤによって、コントローラ３２０の対応するノードを判定する。たとえば、シンクロナイザ３４０は、ＩＤ７を有するノードがノードｓｒｃ０であると判定し、ｓｒｃ０コントローラノードのｓｅｔＰｏｓ（．．．）関数を呼び出す。

ｓｅｔＰｏｓ（．．．）関数は、ＵＩ．ＦＭサーバ３００のデータモデル３１０に位置を入力し、加えて、レンダラドライバ３３０に新たな位置を通知する。レンダラドライバ３３０は、それに関する限りでは、レンダラド３３０に新たな位置を渡す。

ＵＩ．ＦＭサーバ３００のシンクロナイザ３００に関する限り、ワークプレイスＰＣ３５０に関するメッセージは、最小限の時間遅延で、シンクロナイザ３４０からすべてのさらなるクライアント、たとえば、ｉＰａｄ（登録商標）３６０に渡される。ｉＰａｄ（登録商標）３６０は、ＵＩ．ＦＭサーバ３００と同じコントローラ階層３６２、および、同じＩＤを有するデータ構造３６１を有する。さらに、ｉＰａｄ（登録商標）３６０は加えて、シンクロナイザ３６４を含む。ｉＰａｄ（登録商標）３６０のシンクロナイザ３６４は同様に、上記ＩＤをそのデータモデル３６１に入力する。ｉＰａｄ（登録商標）がビュー（たとえば、図３のビュー３６３）を備える場合、コントローラ３６２は、シンクロナイザ３６４からの、変化した位置に関する情報を、ｉＰａｄ（登録商標）３６０のデータモデル３６１にだけでなく、加えて、ｉＰａｄ（登録商標）３６０のビュー３６３にも送信する。このように、ｉＰａｄ（登録商標）３６０のビュー３６３は更新される。

ワークプレイスＰＣ３５０を使用する代わりに、ユーザは、上記の説明と同様に、ｉＰａｄ（登録商標）３６０上でもソースを動かしてもよい。この情報は、同様に、ｉＰａｄ（登録商標）３６０のコントローラ３６２のｓｅｔＰｏｓ（．．．）関数を介して書き込まれる。ｉＰａｄ（登録商標）３６０のコントローラ３６２は、ｉＰａｄ（登録商標）３６０のデータモデル３６１を更新する。さらに、ｉＰａｄ（登録商標）３６０のコントローラ３６２は、ｉＰａｄ（登録商標）３６０のシンクロナイザ３６４に報告する。ｉＰａｄ（登録商標）３６０のシンクロナイザ３６４は、更新通知において、ＵＩ．ＦＭサーバ３６０のシンクロナイザ３４０に、上記情報を送信する。ＵＩ．ＦＭサーバ３６０のシンクロナイザ３６４は、更新通知内に含まれる情報を、他のクライアントのシンクロナイザに、たとえば、ワークプレイスＰＣ３５０のシンクロナイザ３５４に直接渡す。さらに、ＵＩ．ＦＭサーバ３００のシンクロナイザ３４０は、上記情報を、サーバ３００のコントローラ３２０内でも設定する。ＵＩ．ＦＭサーバ３００のコントローラ３２０は、サーバ３００のデータモデル３１０内でｓｒｃ０の位置を更新する。さらに、サーバ３００のコントローラ３２０は、サーバの対応するドライバに、位置の変化を通知する。したがってここではレンダラドライバ３３０である、上記ドライバは、それに従ってレンダラ３８０に報告する。

提供される概念の特別な利点を、下記に実施形態に従って提示する。

実施形態によれば、上述した機能を実施するコードは、ウェブブラウザにおいて動作するのに適している。一実施形態において、たとえば、ブラウザ、たとえば、ＵＲＬを介して、サーバ側を呼び出すことが可能である。ワークプレイスＰＣ３５０のためのコードがライブで送信され、その後、ワークプレイスＰＣ３５０上で即座に実行される。このように、複雑な導入プロセスが省かれる。

さらなる大きな利点は、ドキュメンテーションに関する。データモデル階層全体がクライアントに、たとえば、ワークプレイスＰＣ３５０に送信されるため、そこでは、意味的に直観的に、非常に容易に理解できるシステム記述が存在することになる。上記システム記述は、クライアント３５０上で容易にアクセスすることができる。さらに、システム記述はこのときまた、その階層構造化ツリー構造に起因して理解できる形式で存在することになる。結果として、ドキュメンテーションの支出が省かれる。

実施形態は、動的コード生成、たとえば、実行可能コードの動的生成のための手段を提供する。システムはウェブベースであり、他の関数を生成するための関数を使用することが可能である。生成された上記他の関数は、その後実行することができる。これは、ユーザがコントローラ階層を、最小限の範囲でのみ定義すればよいこと、および、ＩＤ等を割り当てるために同期させるための任意の他のコードを自動的に生成することができることを意味する。

たとえば、ユーザは、ソースｓｒｃ０が特性、たとえば、標準値（ｘ， ｙ， ｚ） ＝ （０， ０， ０）を有する位置（ｘ， ｙ， ｚ）を有すると単純に定義することができる。実施形態において、システムは、上記情報から２つの関数、たとえば、ｓｒｃ０の属性ｐｏｓの値を読み出す、すなわち、ソースｓｒｃ０の位置の値がシステムに返されるようにするための関数「Ｐｏｓ（）」、および、ソースｓｒｃ０の属性ｐｏｓの新たな値を設定するための関数ｓｅｔＰｏｓ（．．．）、たとえば、それによって属性ｐｏｓの値を（ｘ， ｙ， ｚ） ＝ （８， ９， １０）であるように設定することができる「ｓｅｔＰｏｓ（８， ９， １０）」を自動的に生成するように構成されている。

アプリケーション開発者が、たとえば、属性ｐｏｓが標準値（０， ０， ０）を有するという情報を１度記憶するという点において、実施形態において、特に、たとえばワークプレイスＰＣ３５０内のクライアントの各々について、クライアントがコントローラ階層を引き継ぐという点において、上記関数の両方が自動的に生成される。言い換えれば、そのようなコントローラ、たとえば、ノードｓｒｃ０のそのようなコントローラユニットを定義するために必要とされる情報量は極端に少ない。

さらなる利点は、本発明の実施形態が、一方では直観的なアクセスを可能にし、他方では、同時に非常に高速であるデータ構造のノードへのアクセスを可能にするということである。したがって、従来のシステムが通常は直観的であるかまたは高速であるかのいずれかであり、両方ではないのに対して、実施形態は、直観性の特性と速度の特性の両方を組み合わせる。

データ構造の直観性は、アプリケーション開発者にとって特に重要である。アプリケーション開発者がデータモデル内で情報を設定することを所望するとき、上記アプリケーション開発者は、自身がソースｓｒｃ０の情報をどのように得るかについての相対的に単純なパスを、自身にとって利用可能にしなければならない。

一実施形態によれば、システムは、それによって個々のノードがブラウザ内で容易にアドレス指定可能である、この目的のための命令セットを生成する。たとえば、ブラウザ内でコマンドラインを開くことができる。ユーザまたはアプリケーション開発者は、以下を上記コマンドラインに入力することができる：「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ．Ｓｃｅｎｅ．ｓｒｃ０．ｓｅｔＸｙｚ（８， ９， １０）」。そのような行は、グラフ状データ構造の対応する構造を知るときに、直観性が高い。したがって、データ構造の情報に非常に容易に、すなわち、直観的にアクセスし、情報をロードし、情報を更新することができる。このすべてにおいて、データ構造はその階層ツリー状アーキテクチャからすでに明らかであるため、ドキュメンテーションの支出は非常に低くなる。

実施形態によれば、ツリー構造が定義されると、たとえば、ＪａｖａＳｃｒｉｐｔにおいて、ノード間のドット演算子をイネーブルするコマンドが自動的に生成される。たとえば、実施形態において、ブラウザおよび／またはサーバコマンドラインが、上記ドット演算子を生成する。この文脈において、コントローラ構造は、上記演算子を単純に使用することができるように構成される。

実施形態において、たとえば、ルートノードから開始して、または、その後続のノードのうちの１つから開始して、所望のノードまでの連続するノードが１つずつ示され、連続するノードは各事例においてドットによって分離されているということによって、所望のノードに至るパスも示される。たとえば、例としてパス「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ．Ｓｃｅｎｅ．ｓｒｃ０」を示すことによって、または、例として「Ｒｅｎｄｅｒｅｒ．Ｓｃｅｎｅ．ｓｒｃ０」（たとえば、ルートノード「ｒｏｏｔ」が常に最初のノードであることが明らかであるとき）を示すことによって、ノードｓｒｃ０にアクセスすることができる。ノード名が一義的でない場合、たとえば、データ構造内に「ｓｒｃ０」の名前を有する複数のノードがある可能性があるため、アクセスのために単純に「ｓｒｃ０」を示すだけでは十分ではない。加えて、結果としてデータ構造の直観性も失われる。

説明されているパスはアプリケーション開発者にとっては直観的であるが、そのようなノードアクセスが非常に頻繁に実施さ荒れるときは、それらのパスは非効率的である。

たとえば、一実施形態において、レンダラ３８０は、それに従ってＯＳＣメッセージを介してＵＩ．ＦＭサーバ３００のレンダラドライバ３３０に送信されるレベルデータを生成するように構成され得る。レンダラドライバ３３０はその後、それに従って、コントローラ階層３２０内で、したがって、データモデル３１０内でレベルデータを設定する。６４個のソースについて、これらは、たとえば、例として毎秒５０回更新される６４項目の情報であり、すなわち、この例において毎秒３，２００回の更新が必要である。システムの他の部分において、処理されなければならないさらなる高頻度の情報が定期的に発生し得る。位置更新について、このとき、「ｒｏｏｔ．Ｒｅｎｄｅｒｅｒ．Ｓｃｅｎｅ．ｓｒｃ０．ｐｏｓＸｙｚ（８， ９， １０）」の形態のパスが毎回アドレス指定されなければならない。そのようなコマンドは、毎回メッセージ内で、クライアント、たとえば、ワークプレイスＰＣ３５０からＵＩ．ＦＭサーバ３００に送信される。しかしながら、これは非効率的である。

より効率的な実施のために、上記ですでに紹介されているＩＤが使用される。各ノードはある種のハッシュ値を表すＩＤ、すなわち、短いアドレスとして作用するＩＤを保持するため、ＩＤはまた、人間の開発者にとって良好である長いパスに対する代替形態として使用することもできる。一例が、コマンド「ｎｏｄｅ［７］．ｓｅｔＸｙｚ（８， ９， １０）」である。このように、ＩＤ７を有するノードの関数「ｓｅｔＸｙｚ（．．．）」、すなわち、ノードｓｒｃ０のｓｅｔＸｙｚ（．．．）関数が呼び出される。

したがって、ここで使用されているＩＤは、非常に短い様式で要素をアドレス指定する可能性をもたらし、これによって、同期がより効率的になり得る。情報の特定の項目が頻繁に変化する場合、たとえば、非常に多数の更新を伴ってソースが動かされるとき、クライアント３５０からＵＩ．ＦＭサーバ３００に送信されることになるものは、上述した長いパスではなく、対応するＩＤである。これはまた、たとえば、 ＩＤ７を有するノード（すなわち、ｓｒｃ０）の属性「ｐｏｓ」の値が（ｘ， ｙ， ｚ） ＝ （８， ９， １０）を読み出すために変更されるべきであることを記述している、「７： ｐｏｓ： ［８， ９， １０］」の形態の短い命令によっても実行することができる。

非常に短い様式で要素をアドレス指定することが可能であることは、情報の特定の項目が頻繁に変化するときに有利であり得、たとえば、同期に有用である。たとえば、ソース３５８を動かすことは、非常に多数の位置更新を伴う。この事例において、クライアントからサーバに送信されるものは長いパスではなくＩＤである。たとえば、「７： ｐｏｓ： ［８， ９， １０］」の形態のデータメッセージを使用することによって、データメッセージが非常に短くなるこれらはその後、ＵＩ．ＦＭサーバ３００およびすべてのクライアント、たとえば、ｉＰａｄ（登録商標）３６０に、非常に効率的に送信することができる。したがって、長いパスには、特に人間の開発者にとって直観的であるという利点があり、一方で、短いパス、すなわち、たとえば、「７： ｐｏｓ： ［８， ９， １０］」には、システムにとって非常に良好に処理可能であるという利点がある。ＩＤによるデータ送信は非常に高速である。実施形態は、長いパスと短いＩＤの両方のアドレス指定を提供することによって、両方の利点を組み合わせる。

実施形態において、コントローラ階層および／またはデータ構造が定義されるときに、両方のアドレス指定の可能性がシステムによって自動的に生成される。

システムの必須の特性を下記に説明する。

実施形態は、マルチクライアント機能を呈する。マルチクライアント機能は、まったく同一のアプリケーションが、複数のクライアント上で始動することを意味する。たとえば、同じアプリケーションが、ワークプレイスＰＣ３５０、ｉＰａｄ（登録商標）３６０、および、たとえば、さらなるデバイス上で始動することができる。クライアント、たとえば、ワークプレイスＰＣ３５０上で行われる各変更が、他のクライアント３６０のすべてに送信される。たとえば、アプリケーションは、複数のスクリーン上に同時に存在し、また同時に見ることができる。

アプリケーションのさらなる例において、アプリケーションの一部分が第１のクライアント、たとえば、ワークプレイスＰＣ３５０に上で提示され得、一方で、アプリケーションの他の部分が、たとえば、第２のクライアント、たとえば、ｉＰａｄ（登録商標）３６０上で提示され得る。たとえば、ソースは、左手でｉＰａｄ（登録商標）３６０上で消音するように切り替えることができ、一方で、音源は、右手でワークプレイスＰＣ３５０上に位置付けられる。そのような機能は、マルチデバイス機能と称され得る。

加えて、実施形態によるウェブベースの実施態様が有利である。

実施形態のさらなる必須の特徴は、それらが低遅延で問い合わせを実施することが可能であることである。たとえば、ソース３５８がクライアント、たとえば、ワークプレイスＰＣ３５０のブラウザ内で動かされる場合、上記ソース移動は、ほぼ一切の時間遅延なしで他のクライアント、たとえば、ｉＰａｄ（登録商標）３６０に送信され、そこで、ほぼ一切の時間遅延なしに見ることができる。同じことが、たとえば、レンダラ３８０から到来するレベルデータに当てはまる。したがって、これは、システムが、非常に高頻度のパラメータ変化でさえ処理することが可能であるのに十分に高速であることを示す。

すでに言及したように、コントローラ３２０は、複数の異なるタスクを有し、１つのタスクは、データモデル３１０の変更に存し、さらなるタスクは、付加的に、シンクロナイザ３４０によって実施される同期をトリガするために、ドライバ、たとえば、レンダラドライバ３３０に報告することに存する。

その上、ＵＩ．ＦＭ３００内でも実装されるコントローラ３２０は、さらなる機能、すなわち、経時的にデータ変化を記録する機能を備える。すなわち、ソース３５８が動かされると、当該変化を、コントローラ３２０によって記録することができ、後の時点において復元することができる。これは、たとえば、ソース移動を記録するために使用することができる。したがって、上記記録されたソース移動は、後の時点において、復元または再生することができる。これは、自動化機能と称される場合がある。

コントローラ階層およびデータモデル、すなわち、ツリー状構造とはどのようなものであるかを、下記に具体的に説明する。

実施形態は、自動コード生成、すなわち、ノード属性に対する対応するアクセスのための読み出し関数および書き込み関数の自動生成の特性を有する。これは、動的コード生成と称される。

実施形態において、シンクロナイザコードも、自動的に生成され得る。アクセス手順（acces routines）、すなわち、読み出し関数および書き込み関数だけでなく、同期関数も自動的に生成することが可能である。

さらに、実施形態は、ビュー３６３に通知するコードを、コントローラ定義および／またはデータ構造の定義から自動的に生成することができるという特性を有する。

以下において、実施形態の機能を説明する。例示的な適用事例において、スタジアムの音波処理技術が導入される。

たとえば、４人の人間、すなわち、たとえば、４人の音響技師が、音波処理技術の導入に関係することができるとする。音響技師の各々は、たとえば、スタジアムの一翼を担当することができ、たとえば、１人が北翼、１人が南翼、１人が東翼、１人が西翼を担当することができるとする。音響技師の各々は加えて、ｉＰａｄ（登録商標）を携行する。中央調整卓および中央音響システムが、このとき、このｉＰａｄ（登録商標）によって制御され得る。第１の人はこのとき、自身の位置について音声の最適な調整を開始する。その後、第２の人が音声の調整を開始する。第２の人も、ｉＰａｄ（登録商標）を使用する。その後、第３の人、またその後、第４の人もそれに従って開始する。音声はまた、同時に調整されてもよい。このように、音響技師の各々が、他の音響技師が行う調整がどのような効果を有するかを同時に聞くことができる。同時に、変化を知覚したそれぞれの音響技師が、当該変化を取り消すか、または、他の様態で干渉することもできる。すなわち、この例において、４人の音響技師は、すべて同時に最適な音波処理状況を達成することができる。これは、４つの異なるモバイルデバイスを用いて中央アプリケーションを制御することによって達成される。そのようなアプリケーションを実施するために、たとえば、ソフトウェアフレームワークとして実装されてもよいＵＩ．ＦＭが提供される。ＵＩ．ＦＭとは、いわゆるユーザインターフェースフレームワークを指す。このフレームワークは、そのようなアプリケーションを、これまで可能であったよりもはるかに高速かつ容易に実装することを可能にする。

ＵＩ．ＦＭによって開発される任意のアプリケーションは、自らマルチクライアント機能を呈する。たとえば、図４ａは、ｉＰａｄ（登録商標）４１０上にロードされているアプリケーションを示す。クライアント側で、アプリケーションはワークプレイスＰＣ４２０上にもロードされている。さらに、アプリケーションは、さらなるクライアント、さらなるワークプレイスＰＣ４３０上にもロードされている。合計で、ここでは３つの異なるクライアント４１０、４２０、４３０上にアプリケーションが存在する。

図４ｂを考えると、ｉＰａｄ（登録商標）上でたとえば、８つのソース４１１、４１２、４１３、４１４、４１５、４１６、４１７、４１８のうちの１つに触れ、それらを動かすことができる。たとえば、指４１９でそれらのソースの１つに触れ、それらを動かすことが、たとえば、図４ｃに示されている。クライアント４１０内でソースが動かされると同時に、ソースはまた、他のクライアント４２０、４３０のすべての中でも動く。

したがって、クライアント４１０上で指４１９を用いてソース４１６を制御すると、ソース４１６のソース位置の当該変化は、他のクライアント４２０、４３０の他のアプリケーションのすべてに直に送信される。指４１９によってではなく、ソース４１６はまた、マウス、またはそのポインタによって動かされてもよい。したがって、ソースが、たとえば、マウスによってＰＣ上で動かされ得、他のクライアント、たとえば、異なるｉＰａｄ（登録商標）上の対応するソースがそれに従って移動することになる。すなわち、複数の人が、１つのアプリケーションを用いて同時に作業し、そこでパラメータを変更することができ、上記変更されたパラメータは、他の端末デバイスに送信される。

実施形態は、ワークプレイスが拡張されるように、複数の端末デバイスにアプリケーションを配布することが可能である。たとえば、図４ｄは、一方において、８つの異なるソース４１１、４１２、４１３、４１４、４１５、４１６、４１７、４１８がその上に提示されている、背景にあるワークプレイスＰＣ４２０を示す。

同時に、ワークプレイスは、前景にあるｉＰａｄ（登録商標）４１０によって拡張されている。両方のデバイス４１０、４２０は、互いから分離している。デバイス４１０、４２０上では、異なるクライアントアプリケーションが動作している。ＰＣワークプレイス４２０は、ソース位置決めキャンバスをインストールされており、それによって、ソース４１１、４１２、４１３、４１４、４１５、４１６、４１７、４１８を動かすことができる。ｉＰａｄ（登録商標）４１０は消音マトリックスをインストールされており、それによって、個々のまたはすべてのソース４１１、４１２、４１３、４１４、４１５、４１６、４１７、４１８を消音することができる。

したがって、位置決めキャンバスおよび消音マトリックスは、両手で同時に制御することができる。したがって、たとえば、図４ｅに見られるように、１つまたは複数のソースを左手で消音することができ、一方で、右手を使用してソースを制御および位置決めすることができる。したがって、携帯端末デバイス４１０上で動作している第２のアプリケーションによってＰＣワークプレイス４２０が拡張されており、それら両方が、個々のユーザのために完璧に協働する。

実施形態によれば、ＵＩ．ＦＭはウェブベースである。図５ａは、一実施形態によるＵＩ．ＦＭのサーバ側を示す。「Ａｐｐｓ」上でクリックすると、図５ｂに提示されているアプリサイトに入れる。たとえば、ＵＩ．ＦＭサーバ上で動作しているアプリケーション「ＰｒｏｄｕｃｔｉｏｎＡｐｐ」上でクリックすることができ、その結果として、図５ｃに示すように、「ＰｒｏｄｕｃｔｉｏｎＡｐｐ」が開かれる。この時点で、このアプリケーションを用いて作業することができる（「Ａｐｐ」＝アプリケーション）。

ＵＩ．ＦＭは低遅延で動作する。クライアント上のアプリケーション内で行われる任意のことが、可能な限り高速で他のクライアント上の対応するアプリケーションに送信される。したがって、ウェブブラウザ内でリアルタイムのデータを示すことができる。たとえば、図６ａにおいて、最大３２個のソースを表示および制御することができる。上記最大３２個のソースのレベルが、毎秒２５枚の画像で更新される。同じように、すなわち、非常に短い期間内で、最大３２個のソースの位置も更新される。

一実施形態において、データモデルのノードのうちの１つの属性の変化を記録することができる。したがって、ＵＩ．ＦＭにおいて、すべてのパラメータが基本的に自動化可能である。たとえば、以前に実施されたソース移動が現時点で再生されるように、記録を開始し、ソースを動かし、記録を停止し、その後、記録を開始することができるシナリオが、図６ｂに示されている。このように、実施形態は、パラメータの記録を可能にする。

ＵＩ．ＦＭの実施形態において、アプリケーション開発者は、たとえば、図７ａに示すように、グラフ状、たとえば、ツリー状のデータモデルを定義することができる。

図７ａは、例示的なアプリケーションの例示的なデータモデルを示す。ルートノードは図７ａにおいては「ｒｏｏｔ」ではなく「ｓｓｃ」として参照されるが、ルートノードとしてのその重要性に関しては何ら変化がない。「ｃｌｏｃｋ」、「ｄｅｍｏＰｌａｙｅｒ」および「ａｕｄｉｏ」のような、種々のサブノードが存在する。「ａｕｄｉｏ」にあるノードは、その下に存在する様々なサブノード、たとえば、「ｓｃｅｎｅｓ」を有する。ノード「ｓｃｅｎｅｓ」は、サブノード「ｓｃｅｎｅ０」を含む。サブノード「ｓｃｅｎｅ０」は翻って、サブノード「ｓｏｌｏＭａｎａｇｅｒ」、「ｍａｎａｇｅ３ｄ」および「ｓｏｕｒｃｅｓ」を含む。ソース「ｓｒｃ０」はノード「ｓｏｕｒｃｅｓ」の下に位置する。さらに、ノード「ａｕｄｉｏ」は、その下に位置するサブノード「ｍｉｃＳｅｔｕｐｓ」、「ＩｓＳｅｔｕｐｓ」および「ｖｉｒｔｕａｌＬｓＳｅｔｕｐｓ」を有する。

総じて、システム内で発生するデータは、グラフ状に、たとえば、ツリー状に構造化される。

図７ｂおよび図７ｃは、データモデルがどのように定式化されるかの一例を非常に具体的に示している。特に、これはソースの定義に関する。ここで、最初に、ソース内のオブジェクトの属性、たとえば、位置、回転、使用されるか否か（ｉｓＵｓｅｄ）、ソースが選択されるか否か（ｉｓＳｅｌｅｃｔｅｄ）、ソースがロックされているか否か（ｉｓＬｏｃｋｅｄ）、ソースが消音されているか否か（ｉｓＭｕｔｅｄ）、または、たとえば、ソースが３Ｄソースであるか否かなどを定義する。

上記属性の各々は、それに関連付けられている標準値を有する。標準値は同時に、属性のデータ型の決定に使用される。加えて、上記属性のいずれが自動化されるべきであるか（「ａｕｔｏｍａｔｅ ａｌｌ ａｔｔｒｉｂｕｔｅｓ ｅｘｃｅｐｔ」）を指定する様々な選択肢がある。

さらに、自動化のための時系列はどのようなものであるべきか（時系列構成）、および、どの程度近く隣接する表示点、すなわち、キーフレームが意図されるべきであるかの定義が与えられる。さらに、たとえば、空間的隣接および方向の変化を示すことが可能であるべきである。上述したデータ記録／自動化の最適化が達成される。さらに、それら属性のすべてではなく、特定の属性のみがファイルに直に記憶されることも言える。したがって、非常に多様な組み合わせ選択肢がある。

データモデル内のＮｅｗＣｏｎｔｒｏｌｌｅｒＣｌａｓｓをよびだすことによって、新たなノードの新たなコントローラサブユニットを生成することができる。名前、属性、ｃｈｉｌｄＣｒｅａｔｉｏｎＦｕｎｃｔｉｏｎおよび選択肢が、この呼び出しに引き渡される。このように、新たなノードが定義される。

加えて、個々のノードはグラフ状、たとえば、ツリー状の階層になるべきである。ツリー状階層は、図７ａにおいてすでに図で示した。したがって、「ｓｏｕｒｃｅ０」ソースは「ｓｏｕｒｃｅｓ」コンテナ内に位置し、「ｓｏｕｒｃｅｓ」コンテナは「ｓｃｅｎｅ０」コンテナ内に位置し、「ｓｃｅｎｅ０」コンテナは「ｓｃｅｎｅｓ」コンテナ内に位置する。

図７ａに概説されているデータモデルを指定するための、図７ｄ、図７ｅ、図７ｆに示されている様々なプログラミングコマンドが存在する。一方では、ノードが定義されることになり、加えて、ノードの属性が定義されることになり、ノードは所定のコマンドを介して親ノードに割り当てられることになる。このように、対応する階層を確立することができる。

実施形態によれば、ＵＩ．ＦＭは、たとえば、グラフ状、たとえば、ツリー状のデータ構造から一連の有用なツールを導出し、自動的に生成することが可能である。上記ソフトウェアツール、たとえば、ソフトウェア開発ツールを以下に説明する。

第１のツールは、データモデル内のノードに達するためのプログラミングコマンドの自動生成を実施する。したがって、ＵＩ．ＦＭは、以前に定義したツリー階層からプログラミングコマンドを自動的に生成する。図８ａはその一例を示しており、ＪａｖａＳｃｒｉｐｔコンソール８１０が開かれている。ＪａｖａＳｃｒｉｐｔコンソール８１０は、たとえば、Ｃｈｒｏｍｅ（登録商標）およびＦｉｒｅｆｏｘ（登録商標）のようなブラウザ内に位置する。このコンソールを介して、ブラウザ内にロードされているデータモデルにアクセスすることができる。

図８ｂに示すように、たとえば、「ｓｓｃ．ｇｌｏｂａｌＣｏｎｔｒｏｌｌｅｒ．ａｕｄｉｏ」と呼ばれるノード列がＪａｖａＳｃｒｉｐｔコンソール８１０に入力されると、以前に生成された「ａｕｄｉｏ」ノードがアドレス指定される。「ａｕｄｉｏ」ノードは、その下に存在する「ｓｃｅｎｅｓ」サブノードを有する。上記「ｓｃｅｎｅｓ」サブノードには、「ａｕｄｉｏ」の後に名前「ｓｃｅｎｅｓ」を追加することによってアクセスすることができる。「ｓｃｅｎｅｓ」のうち最初の２文字だけが入力されればよい。「ｓｃ」はその後自動的に補完されて、「ｓｃｅｎｅｓ」が読み出される。これは、以前に定義した、たとえば、ツリー状の階層から、正確なプログラミングコマンドがライブで自動的に付加されたことに起因する。次に、ノード名「ｓｃｅｎｅ０」が追加され、その後、「ｓｏｕｒｃｅｓ」サブノード、最後に「ｓｒｃ０」ソースがアドレス指定される。ノード名のそれぞれの最初の文字を入力すると、システムには、問題になる対応するサブノードがすでに分かっているため、システムは各事例において、可能性のある補完を提供する。図８ｃにおいて、「ｓｒｃ０」への完全なパスが示されている。

加えて、図８ｄは、そこで関数呼び出し「ｓｅｔＸｙｚ」によって、ソースのいずれの特性が変更されるべきであるかを指定する。コマンド「ｓｅｔＸｙｚ」は自動的に生成されたものである。しかしながら、データ定義においては、図８ｄに示すように、「ｘｙｚ： ［０，０，０］」しか入力されていない。したがって、定義されているのは、ｘｙｚと呼ばれ、標準値［０，０，０］を有する属性が存在すべきであることだけである。このラインから、ＵＩ．ＦＭはコマンド「ｓｅｔＸｙｚ（）」を自動的に生成している。

図８ｅは、ソースを位置［−１００， −１００， ０］にシフトするためのコマンドを示す。Ｅｎｔｅｒを押下することによってコマンドが送信されると、図８ｆに示すように、ソースが自動的にシフトされる。これは、たとえば、イベント（メッセージ）が、自動的に生成されたｓｅｔＸｙｚ関数内で生成されていることに起因する。ソース表現はこのメッセージにサブスクライブされており、その後、その位置を変更することが可能になっている。

したがって、アプリケーション開発者は、データモデルの一体部分、すなわち、ノードに単純に直観的にアクセスすることができる。ｓｅｔＸｙｚ（）関数に加えて、自動的に静止される、読み出しのための関数も、自動的に存在する。この関数は図８ｆに示されており、「ｘｙｚ（）」によって指定されている。対応するコマンド「ｘｙｚ（）」が送信されると、現在位置「［−１００， −１００， ０］」が出力される。図８ｇに示すように位置をシフトし、現在位置を表示するための関数を再び呼び出すと、ソースの現在位置が出力される。

実施形態によれば、ＵＩ．ＦＭは、クライアント１上のソースＡからクライアント２上の同じソースＡに属性または特性を送信するための同期コードを自動的に生成することが可能である。図９ａは、２つのアプリケーション９１０、９２０として２回始動されているプログラムを示す。

新たな属性を高速かつ容易に追加することができる。たとえば、図９ｂは、さらなるウィンドウにおいて、ソースのデータモデルを示しており、上記データモデルについてはすでに上記で説明している。図９ｃに示すように、ここでさらなる属性を容易に追加することができる。

図９ｃにおいて、値「ｕｉｆｍ」を有する属性「ｕｉｆｍ」が追加されている。したがって、この属性はその値として文字列を有する。「ａｔｔｒｉｂｕｔｅｓ」の下にラインを挿入するだけで、新たな属性が挿入されている。

実施されているそのような新たな定義が効果を有するようにするために、たとえば、図９ｄに示すようにサーバ３００を再始動する必要があり得る。したがって、ＵＩ．ＦＭサーバ３００は、サーバコマンドラインによって再始動することができる。サーバ３００の再始動後、両方のアプリケーション９１０、９２０も再始動される。

図９ｅは、この新たに挿入された「ｕｉｆｍ」属性が、両方のアプリケーション９１０、９２０において自動的に生成された「ｕｉｆｍ（）」コマンドを介して問い合わせることができ、戻り値として「ｕｉｆｍ」データ文字列を与えることを示す。これは、クライアントおよびサーバの両方の中で機能する。

自動的に生成された「ｓｅｔＵｉｆｍ（）」関数によってｕｉｆｍ属性の値を変更することも可能である。これは、図９ｆおよび図９ｇに示されている。第１のアプリケーション９１０において実施されたｕｉｆｍ属性の更新は、図９ｇの右手側にある第２のアプリケーション９２０に自動的に送信される。自動的に生成されたｕｉｆｍ（）関数によってｕｉｆｍ属性を問い合わせることによって、図９ｇの右側アプリケーション９２０においても、更新された文字列「Ｇａｂｒｉｅｌ Ｇａｔｚｓｃｈｅ」が与えられる。

同様に、ｕｉｆｍ属性の値は逆に、図９ｈに示すように、右手側アプリケーションにおいて、たとえば、「Ｂａｓｅ ｃａｍｐ」にリセットすることもできる。そのような更新は、図９ｈの左手側アプリケーション９１０に対して直接的かつ即時の効果を有する。したがって、ＵＩ．ＦＭは、データモデルの高速かつ容易な拡張を可能にし、同期コードの高速かつ容易な生成を可能にする。

ＵＩ．ＦＭは、それによって、接続されているオブザーバが自身を、データモデルの値が変化したときに報告されるようにすることができるコードを自動的に生成する（たとえば、パブリッシャ−オブザーバ、設計パターンを参照されたい）。参照されているオブザーバは人間のオブザーバではなく、変更メッセージにサブスクライブし、データモデルが変化するとすぐに変更メッセージを自動的に受信するプログラムモジュールである。

一実施形態によれば、たとえば、ユーザ入力を受けてのデータモデルのノードのうちの１つの属性のうちの１つに対しての、変化モニタリングが導入され得る。たとえば、変化モニタリングが導入されている１つの属性の値が変化するときに警告が出力される。警告の出力は一例に過ぎない。別の可能性は、たとえば、ブラウザのタイトルバーが更新されるようにすることなどである。

これは、変化モニタリングが導入されている図１０ａを参照して説明される。コンソールに入力されたコマンド「ｏｎ（‘ｃｈａｎｇｅ［ｕｉｆｍ］’， ｆｕｎｃｔｉｏｎ（）」によって、システムは、ｕｉｆｍの値が変化するときにその後定義される関数を呼び出すようにされる。図１０ａのｆｕｎｃｔｉｏｎ（）定義は、この事例においては、警告が特性ｕｉｆｍの値を示す出力であるべきであることを定義する。コンソールにおいてＥｎｔｅｒを押下すると、このように定義されたオブザーバが登録される。

図１０ｂにおいて、「ｐｒｏｄｕｃｔｉｏｎ ａｐｐ」におけるｕｉｆｍの値が変更される。図１０ｃに示すように、その後、ｕｉｆｍの新たな値、すなわち「ｐｒｏｄｕｃｔｉｏｎ ａｐｐ」を出力する警告が現れる。これはまた、第２のクライアントが開いている場合にも機能する。

図１０ｄは、第２のクライアントが開いているところを示す。ｕｉｆｍの値は、コンソール内の「ｓｅｔＵｉｆｍ」関数によって変更される。図１０ｅに見られるように、たとえｕｉｆｍの値が第２のクライアント内で変更されているとしても、ｕｉｆｍの値が「ｏｖｅｒｈｅａｄ」に変化していることを記述する警告は、第１のクライアントにおいても出力される。

詳細には、ｕｉｆｍの新たな値が第２のクライアントからサーバに送信されており、サーバからこの値が第１のクライアントに送信されており、そこで、ｕｉｆｍの値がそれに応じて更新されており、オブザーバが報告を受けており、図１０ｅに示すように、その結果として警告が出力されている。

ＵＩ．ＦＭによって、時系列データを記録することも非常に容易である。上述したように、属性ｕｉｆｍがデータモデルに追加されている。一実施形態において、この属性のために、時系列データを記録するように、コードが自動的に生成される。たとえば、値ｕｉｆｍの様々な変化を経時的に記録することができる。たとえば、再生キーを押下することによって、時間が流れ始めることを保証することができる。ｕｉｆｍの値が最初に「Ｆｒｉｄａｙ」に設定され、その後「Ｓａｔｕｒｄａｙ」に、その後「Ｓｕｎｄａｙ」に設定される場合、当該データ変化は、その波形内にそれらの時系列順における挙動を記録される。

たとえば、読み出しモード／復元モードが起動されると、以前に記録されたデータが、書き込み関数を介して時系列からデータモデルへと再び書き込まれる。接続されているオブザーバ（ビュー）は報告を受け、たとえば、各事例において、特に、収集モードの間にも値が変更されている復元時点において、警告を自動的に出力する。たとえば、図１１において、値「Ｓｕｎｄａｙ」が記録の再実行においても変更される時点において、警告「Ｓｕｎｄａｙ」が出力される。したがって、実施形態は、入力が復元されるときに、システムによって、時間的に正確に復元され、たとえば、収集に従って時間的に正確に警告を出力する、入力の収集を可能にする。

いくつかの態様が装置の文脈内で説明されているが、上記態様は、対応する方法の説明をも表し、それによって、装置のブロックまたは構造構成要素はまた、対応する方法ステップまたは方法ステップの特徴としても理解されるべきであることが理解される。それと同様に、方法ステップに関連して、または、方法ステップとして説明されている態様はまた、対応する装置の対応するブロックまたは詳細または特徴の説明をも表す。方法ステップのいくつかまたはすべては、プロセッサ、プログラム可能コンピュータまたは電子回路のようなハードウェア装置によって（またはハードウェア装置を使用している間に）実施されてもよい。いくつかの実施形態において、もっとも重要な方法ステップのいくつかまたは一部は、そのような装置によって実施されてもよい。

特定の実施要件に応じて、本発明の実施形態は、ハードウェアまたはソフトウェアにおいて実施されてもよい。実施は、それぞれの方法が実施されるようにプログラム可能コンピュータシステムと協働することができる、または、協働する電子可読制御信号を記憶されているデジタル記憶媒体、たとえば、フロッピーディスク、ＤＶＤ、Ｂｌｕ−ｒａｙディスク、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリ、ハードディスクまたは任意の他の磁気もしくは光学メモリを使用しながら実行されてもよい。このため、デジタル記憶媒体はコンピュータ可読であり得る。

したがって、本発明によるいくつかの実施形態は、本明細書に記載されている方法のいずれかが実施されるようにプログラム可能コンピュータシステムと協働することが可能である電子可読制御信号を含むデータキャリアを含む。

一般的に、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実装することができ、プログラムコードは、コンピュータプログラム製品がコンピュータ上で動作するときにいずれかの方法を実施するように実行可能である。

プログラムコードはまた、たとえば、機械可読キャリア上に記憶されてもよい。

他の実施形態は、本明細書に記載されている方法のいずれかを実施するためのコンピュータプログラムを含み、上記コンピュータプログラムは、機械可読キャリア上に記憶されている。言い換えれば、したがって、本発明の方法の一実施形態は、コンピュータプログラムがコンピュータ上で動作するときに、本明細書に記載されている方法のいずれかを実施するためのプログラムコードを有するコンピュータプログラムである。

したがって、本発明の方法のさらなる実施形態は、本明細書に記載されている方法のいずれかを実施するためのコンピュータプログラムが記録されているデータキャリア（またはデジタル記憶媒体もしくはコンピュータ可読媒体）である。

したがって、本発明の方法のさらなる実施形態は、本明細書に記載されている方法のいずれかを実施するためのコンピュータプログラムを表すデータストリームまたは信号系列である。データストリームまたは信号系列は、たとえば、データ通信リンク、たとえば、インターネットを介して転送されるように構成され得る。

さらなる実施形態は、本明細書に記載されている方法のいずれかを実施するように構成または適合されている処理手段、たとえば、コンピュータまたはプログラム可能論理デバイスを含む。

さらなる実施形態は、本明細書に記載されている方法のいずれかを実施するためのコンピュータプログラムがインストールされているコンピュータを含む。

本発明によるさらなる実施形態は、本明細書に記載されている方法の少なくとも１つを実施するためのコンピュータプログラムを受信機に送信するように構成されている装置またはシステムを含む。送信は、たとえば、電子的または光学的であってもよい。受信機は、たとえば、コンピュータ、モバイルデバイス、メモリ装置または同様の装置であってもよい。装置またはシステムは、たとえば、コンピュータプログラムを受信機に送信するためのファイルサーバを含んでもよい。

いくつかの実施形態において、プログラム可能論理デバイス（たとえば、フィールドプログラマブルゲートアレイ、ＦＰＧＡ）が、本明細書に記載されている方法の機能のいくつかまたはすべてを実施するために使用され得る。いくつかの実施形態において、フィールドプログラマブルゲートアレイは、本明細書に記載されている方法のいずれかを実施するために、マイクロプロセッサと協働することができる。一般的に、方法は、いくつかの実施形態において任意のハードウェア装置によって実施される。上記ハードウェア装置は、コンピュータプロセッサ（ＣＰＵ）のような任意の普遍的に適用可能なハードウェアであってもよく、または、ＡＳＩＣのような、本方法に特異的なハードウェアであってもよい。

上述した実施形態は、本発明の原理の例示を表すに過ぎない。当業者には、本明細書に記載されている構成および詳細の任意の修正および変形が諒解されることが理解される。このため、本発明は、実施形態の記述および説明によって本明細書において提示されている特定の詳細によってではなく、添付の特許請求の範囲のみによって限定されるように意図されている。

Claims (27)

1. 装置（１６０， １７０； ３００， ３５０， ３６０）であって、
   データモデル（１１０； ３１０， ３５１， ３６１）であって、前記データモデル（１１０； ３１０， ３５１， ３６１）は３つ以上のノードを含み、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記３つ以上のノードの１つまたは複数は、それに割り当てられているＩＤを有し、前記１つまたは複数のノードの各々は、そのＩＤによって前記データモデル（１１０； ３１０， ３５１， ３６１）の他のノードから一義的に区別可能であり、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの少なくとも２つは各々、１つまたは複数の属性を含み、前記属性の各々が、前記データモデル（１１０； ３１０， ３５１， ３６１）内に記憶されている値を利用することが可能であり、前記少なくとも２つのノードの各ノードは、それに割り当てられているパス指示を有し、前記パス指示は、前記パス指示が割り当てられているそれぞれのノード、および、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記３つ以上のノードのうちの少なくとももう１つのノードを含み、前記少なくとも２つのノードの各ノードの前記パス指示は、それぞれのノードのＩＤとは異なる、データモデル（１１０； ３１０， ３５１， ３６１）と、
   属性を有する前記データモデル（１１０； ３１０， ３５１， ３６１）の前記３つ以上のノードの各々の各属性のための書き込み関数を含むコントローラ（１２０； ３２０， ３５２， ３６２）であって、前記属性の値は、前記書き込み関数によって変更可能である、コントローラ（１２０； ３２０， ３５２， ３６２）と、
   シンクロナイザ（１３０； ３４０， ３５４， ３６４）とを備え、
   前記シンクロナイザ（１３０； ３４０， ３５４， ３６４）は、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの１つを指定する更新通知を受信するように構成されており、前記更新通知は、前記ノードの属性をさらに指定し、前記更新通知は、この属性の値がどのように更新されるべきかを示し、前記更新通知は、前記ノードの前記ＩＤによって前記ノードを指定し、
   前記コントローラ（１２０； ３２０， ３５２， ３６２）は、この属性の前記書き込み関数によって、前記更新通知に応じてこのノードのこの属性の値を更新するように構成されている、装置（１６０， １７０； ３００， ３５０， ３６０）。
2. 前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードの各々は、それに割り当てられているＩＤを有し、
   前記データモデルの前記ノードの各々は、そのＩＤによって前記データモデル（１１０； ３１０， ３５１， ３６１）の他のノードから一義的に区別可能である、請求項１に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
3. 前記コントローラ（１２０； ３２０， ３５２， ３６２）は、属性を有する前記データモデル（１１０； ３１０， ３５１， ３６１）の前記３つ以上のノードの各々の各属性について読み出し関数を含み、前記属性の値は、前記読み出し関数によって読み出し可能である、請求項１または２に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
4. 前記データモデルの前記３つ以上のノードの各々の前記ＩＤは、数字または文字列またはハッシュ値である、請求項１から３のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
5. 前記データモデル（１１０； ３１０， ３５１， ３６１）の前記３つ以上のノードがグラフ状構造を含み、それによって、前記データモデル（１１０； ３１０， ３５１， ３６１）の各ノードには、前記グラフ状階層内の前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの少なくとも１つが直に後続し、かつ／または、前記グラフ状階層内の前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの１つが直に先行し、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの少なくとも１つには、前記グラフ状階層内の前記データモデル（１１０； ３１０， ３５１， ３６１）の２つのノードが直に後続する、請求項１から４のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
6. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記データモデルの前記ノードのうちの１つに１つまたは複数の属性を追加する、前記データモデル（１１０； ３１０， ３５１， ３６１）の変更に関する情報を受信するように構成されているインターフェースをさらに備え、
   前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記追加される１つまたは複数の属性の各々についての読み出し関数および書き込み関数を自動的に生成するように構成されており、前記属性の値は、前記読み出し関数によって読み出し可能であり、前記属性の値は、前記書き込み関数によって変更可能である、請求項１から５のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
7. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記データモデルの前記ノードのうちの１つに１つまたは複数の属性を追加する、前記データモデル（１１０； ３１０， ３５１， ３６１）の変更に関する情報を受信するように構成されているインターフェースをさらに備え、
   前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記追加される１つまたは複数の属性の各々についての書き込み関数を自動的に生成するように構成されており、前記属性の値は、前記書き込み関数によって変更可能であり、前記書き込み関数は、前記属性の値が変化するときに、前記シンクロナイザ（１３０； ３４０， ３５４， ３６４）および／またはビュー（２１３； ３３０， ３５３， ３６３）に報告するように構成されている、請求項１から５のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
8. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記データモデルの前記ノードのうちの１つに１つまたは複数の属性を追加する、前記データモデル（１１０； ３１０， ３５１， ３６１）の変更に関する情報を受信するように構成されているインターフェースをさらに備え、
   前記装置（１６０， １７０； ３００， ３５０， ３６０）は、前記追加される１つまたは複数の属性の各々についての書き込み関数を自動的に生成するように構成されており、前記属性の値は、前記書き込み関数によって変更可能であり、前記書き込み関数は、後に復元または取り消すことを目的として前記属性の値の変化を経時的に記録するように構成されている、請求項１〜５または請求項７のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
9. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、ウェブアプリケーションによって、属性を有する前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードの各々の属性の各々についての前記読み出し関数および前記書き込み関数を与えるように構成されており、それによって、前記読み出し関数および前記書き込み関数は、前記ウェブアプリケーションによって使用することができる、請求項１から８のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
10. 前記ウェブアプリケーションは、ＪａｖａＳｃｒｉｐｔおよび／またはＨＴＭＬにおいて実装される、請求項９に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
11. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、ユーザ入力を受けて前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの１つの前記属性のうちの１つに対する変化モニタリングを導入するように構成されている、請求項１から１０のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
12. 前記装置（１６０， １７０； ３００， ３５０， ３６０）は、変化モニタリングが導入されている前記属性のうちの１つの値が変化するときに警告を出力するように構成されている、請求項１１に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
13. 前記装置（１６０， １７０； ３００， ３５０， ３６０）（１６０， １７０； ３００， ３５０， ３６０）は、前記データモデル（１１０； ３１０， ３５１， ３６１）の前記ノードのうちの１つの属性に対して行われる変更を記録するように構成されている、請求項１から１２のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）。
14. サーバ（１７０； ３００）であって、
    前記サーバ（１７０； ３００）は、請求項１から１３のいずれか一項に記載の装置（１６０； ３１０）であり、
    前記サーバ（１７０； ３００）は、１つまたは複数のクライアント（１６０； ３５０， ３６０）からの登録（複数可）を受信するように構成されており、
    前記サーバ（１７０； ３００）は、前記１つまたは複数のクライアント（１６０； ３５０， ３６０）に、前記クライアントの登録を受けて、前記データモデル（３１０）に関する情報を送信するように構成されており、前記データモデル（３１０）に関する前記情報は、属性を有する前記データモデル（３１０）のすべての前記ノードまたは２つ以上の前記ノードの前記属性の値を含み、前記データモデル（３１０）に関する前記情報は、前記データモデル（３１０）の各ノードまたは前記データモデル（３１０）の前記少なくとも２つのノードについて、前記データモデル（３１０）のいずれの前記ノードが前記ノードに直に後続するか、および／または、前記データモデル（３１０）のいずれのノードが前記ノードに直に先行するかをさらに示す、サーバ（１７０； ３００）。
15. 前記サーバ（１７０； ３００）は、１つまたは複数のクライアント（１６０； ３５０， ３６０）からの登録（複数可）を受信するように構成されており、
    前記サーバ（１７０； ３００）の前記シンクロナイザ（３４０）は、前記データモデル（３１０）のノードの属性の値が変化していることを示す、前記クライアント（１６０； ３５０， ３６０）のうちの１つからのメッセージを受信するように構成されており、
    前記サーバ（１７０； ３００）の前記シンクロナイザ（３４０）は、前記クライアント（１６０； ３５０， ３６０）の前記メッセージを受けて、前記データモデル（３１０）のノードの属性の値が変化しているということを、前記サーバ（１７０； ３００）に登録している他の２つ以上のクライアント（１６０； ３５０， ３６０）に報告するように構成されている、請求項１４に記載のサーバ（１７０； ３００）。
16. 前記サーバ（１７０； ３００）は、無線または有線でデバイス（３８０， ３９０）にメッセージを送信するように構成されており、前記メッセージは、前記データモデル（３１０）の前記ノードのうちの１つの属性が変化していることを前記デバイス（３８０， ３９０）に通知する、請求項１４または１５に記載のサーバ（１７０； ３００）。
17. 前記サーバ（１７０； ３００）は、前記デバイス（３８０， ３９０）に前記メッセージを無線で送信するように構成されている、請求項１６に記載のサーバ（１７０； ３００）。
18. 前記デバイス（３８０， ３９０）は、１つまたは複数のスピーカ信号を生成するためのレンダラ（３８０）である、請求項１６または１７に記載のサーバ（１７０； ３００）。
19. 前記サーバ（１７０； ３００）は、前記クライアント（１６０； ３５０， ３６０）から前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する情報を受信するように構成されており、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する前記情報は、属性を有する前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のすべての前記ノードまたは２つ以上の前記ノードの前記属性の値を含み、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する前記情報は、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）の各ノードまたは前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）の前記少なくとも２つのノードについて、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のいずれの前記ノードが前記ノードに直に後続するか、および／または、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のいずれのノードが前記ノードに直に先行するかをさらに示す、請求項１４から１８のいずれか一項に記載のサーバ。
20. 前記サーバ（１７０； ３００）は、前記１つまたは複数のクライアント（１６０； ３５０， ３６０）の登録を受けて、前記１つまたは複数のクライアント（１６０； ３５０， ３６０）に、前記サーバ（１７０； ３００）の前記データモデル（３１０）の前記２つ以上の前記ノードの前記ＩＤを送信するように構成されている、請求項１４から１９のいずれか一項に記載のサーバ（１７０； ３００）。
21. クライアント（１６０； ３５０， ３６０）であって、
    前記クライアント（１６０； ３５０， ３６０）は、請求項１から１０のいずれか一項に記載の装置（１６０， １７０； ３００， ３５０， ３６０）であり、
    前記クライアント（１６０； ３５０， ３６０）は、請求項１４から２０のいずれか一項に記載のサーバ（１７０； ３００）に登録するように構成されており、
    前記クライアント（１６０； ３５０， ３６０）は、前記サーバ（１７０； ３００）に登録されると、前記サーバ（１７０； ３００）の前記データモデル（３１０）に関する情報を受信するように構成されており、前記サーバ（１７０； ３００）の前記データモデル（３１０）に関する前記情報は、属性を有する前記サーバ（１７０； ３００）の前記データモデル（３１０）のすべての前記ノードまたは２つ以上の前記ノードの前記属性の値を含み、前記サーバ（１７０； ３００）の前記データモデル（３１０）に関する前記情報は、前記サーバ（１７０； ３００）の前記データモデル（３１０）の各ノードまたは前記サーバ（１７０； ３００）の前記データモデル（３１０）の前記２つ以上のノードについて、前記サーバ（１７０； ３００）の前記データモデル（３１０）のいずれの前記ノードが前記ノードに直に後続するか、および／または、前記サーバ（１７０； ３００）の前記データモデル（３１０）のいずれのノードが前記ノードに直に先行するかをさらに示し、
    前記クライアント（１６０； ３５０， ３６０）は、前記サーバ（１７０； ３００）の前記データモデル（３１０）に関する前記情報に応じてそのデータモデル（３５１， ３６１）を更新するように構成されている、クライアント（１６０； ３５０， ３６０）。
22. 前記クライアント（１６０； ３５０， ３６０）は、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する情報を前記サーバ（１７０； ３００）に送信するように構成されており、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する前記情報は、属性を有する前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のすべての前記ノードまたは２つ以上の前記ノードの前記属性の値を含み、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）に関する前記情報は、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）の各ノードまたは前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）の前記少なくとも２つのノードについて、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のいずれの前記ノードが前記ノードに直に後続するか、および／または、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）のいずれのノードが前記ノードに直に先行するかをさらに示す、請求項２１に記載のクライアント（１６０； ３５０， ３６０）。
23. 前記クライアント（１６０； ３５０， ３６０）はウェブブラウザ内で動作するように構成されている、請求項２１または２２に記載のクライアント（１６０； ３５０， ３６０）。
24. 前記クライアント（１６０； ３５０， ３６０）は、前記サーバ（１７０； ３００）に、前記クライアント（１６０； ３５０， ３６０）の前記データモデル（３５１， ３６１）の２つ以上の前記ノードの前記ＩＤを送信するように構成されている、請求項２１から２３のいずれか一項に記載のクライアント（１６０； ３５０， ３６０）。
25. システムであって、
    請求項１４から２０のいずれか一項に記載のサーバ（１７０； ３００）と、
    請求項２１から２４のいずれか一項に記載のクライアント（１６０； ３５０， ３６０）とを含み、
    前記クライアント（１６０； ３５０， ３６０）は、前記サーバに更新通知を送信するように構成されており、
    前記サーバ（１７０； ３００）の前記シンクロナイザ（３４０）は、前記更新通知を受信するように構成されており、前記更新通知は、前記サーバ（１７０； ３００）の前記データモデル（３１０）の前記ノードのうちの１つを指定し、さらに、前記ノードの属性を指定し、この属性の値がどのように更新されるべきかを示し、
    前記サーバ（１７０； ３００）の前記コントローラ（３２０）は、前記更新通知が前記ノードの前記ＩＤを指定する場合に、前記更新通知に応じてこのノードのこの属性の値を更新するように構成されている、システム。
26. 方法であって、
    ノードのＩＤによってデータモデルのノードを指定する更新通知を受信するステップであって、前記更新通知は前記ノードの属性をさらに指定し、前記更新通知は、この属性の値がどのように更新されるべきかを示し、前記データモデルは３つ以上のノードを含み、前記データモデルの前記３つ以上のノードの１つまたは複数は、それに割り当てられているＩＤを有し、前記１つまたは複数のノードの各々は、そのＩＤによって前記データモデルの他のノードから一義的に区別可能であり、前記データモデルの前記ノードのうちの少なくとも２つは各々、１つまたは複数の属性を含み、前記属性の各々が、前記データモデル内に記憶されている値を利用することが可能であり、前記少なくとも２つのノードの各ノードは、それに割り当てられているパス指示を有し、前記パス指示は、前記パス指示が割り当てられているそれぞれのノード、および、前記データモデルの前記３つ以上のノードのうちの少なくとももう１つのノードを含み、前記少なくとも２つのノードの各ノードの前記パス指示は、それぞれのノードの前記ＩＤとは異なる、受信するステップと、
    前記更新通知に応じて、この属性の書き込み関数によって、前記更新通知におい
    て指定されている前記属性の値を更新するステップとを含む、方法。
27. 請求項２６に記載の方法を実施するためのプログラムコードを有する、コンピュータプログラム。