JP2003513348A - 分散型ネットワークを経て運動データを発生しそして通信するためのシステム及び方法 - Google Patents

Abstract

(57)【要約】 図１の制御ソフトウェアシステム(20)は、運動媒体の形態の運動コンテンツを、分散型ネットワーク(22)を経て、ターゲット装置を動作するためのクライアントブラウザ(24)及びコンテンツサーバー(26)との間で発生し、分配しそして接続するように構成される。制御ソフトウェアシステム(20)は、コンテンツサーバー(26)に発生された運動プログラムに基づいて運動媒体を発生する。制御ソフトウェアシステム(20)は、ターゲット運動装置に関連したクライアントブラウザ(24)に運動媒体を分配する。

Description

【発明の詳細な説明】

【０００１】

【関連出願】

本出願は、１９９９年１０月２７日に出願された米国プロビジョナル特許出願
第６０／１６１，９０１号；１９９９年１１月１日に出願された第６０／１６２
，９８９号；１９９９年１１月１日に出願された第６０／１６２，８０２号；１
９９９年１１月１日に出願された第６０／１６２，８０１号；２０００年２月１
６日に出願された第６０／１８２，８６４号；及び２０００年２月２５日に出願
された第６０／１８５，１９２号の優先権を請求するものである。

【技術分野】

本発明は、運動制御システムに係り、より詳細には、運動制御ソフトウェアの
生成及び分配を容易にするソフトウェアシステムに係る。

【０００２】

【発明の背景】

運動制御装置の目的は、物体を希望通りに運動させることである。運動制御装
置の基本的な要素は、コントローラ及び機械的システムである。機械的システム
は、コントローラにより発生された信号を物体の運動に変換する。 機械的システムは、通常、駆動装置及び電気モータを備えているが、液圧又は
振動システムのような多数の他のシステムを使用して、制御信号に基づき物体を
運動させることもできる。更に、運動制御装置が複数の駆動装置及びモータを備
えていて、物体の運動の多軸制御を許すこともできる。

【０００３】 本発明は、少なくとも１つの駆動装置及び電気モータを備え、その回転シャフ
トが、運動されるべき物体にある状態で接続されたターゲット装置又はシステム
に関して特に重要であり、そのような応用例について詳細に説明する。しかしな
がら、本発明の原理は、一般に、制御信号に基づいて運動を発生するターゲット
装置又はシステムにも適用できる。従って、本発明の範囲は、以下の詳細な説明
ではなく、特許請求の範囲に基づいて決定されねばならない。 コントローラ、駆動装置及び電気モータを備えた機械的システムにおいて、モ
ータは、運動されるべき物体に物理的に接続され、モータシャフトの回転が物体
の運動に変換される。駆動装置は、制御されたやり方でモータシャフトを回転す
るようにモータに電力を供給するための電子式電力増幅器である。制御コマンド
に基づいて、コントローラは、物体が所望のやり方で運動されるように駆動装置
を予想し得るように制御する。

【０００４】 これらの基本的な要素は、通常、特定のタスクを遂行するために大きなシステ
ムに配置される。例えば、１つのコントローラが、多軸システムにおいて多数の
駆動装置及びモータに関連して動作し、被加工片に対し所定の経路に沿ってツー
ルを移動させる。 更に、上記の基本的な要素は、ホストコンピュータ又はプログラム可能な論理
コントローラ（ＰＬＣ）に関連してしばしば使用される。ホストコンピュータ又
はＰＬＣは、高レベルプログラミング言語を使用して制御コマンドを発生し、こ
れらコマンドがコントローラに通される。従って、ホストコンピュータで実行さ
れるソフトウェアは、コントローラをプログラミングするタスクを簡単化するよ
うに設計される。

【０００５】 運動制御装置を製造する会社は、慣例的に、自分が製造するハードウェア専用
のソフトウェアを製造するハードウェア指向の会社である。これらソフトウェア
製品は、低レベルプログラムと称することができる。低レベルプログラムは、通
常、所与のモータ制御装置に特有の運動制御コマンド言語で直接的に機能する。
このような低レベルプログラムは、ハードウェアに対する実質的に完全な制御を
プログラマーに与えるが、これらプログラムは、ハードウェアに著しく依存して
いる。 低レベルプログラムとは対照的に、ファクトリーオートメーションアプリケー
ションとも時には称される高レベルのソフトウェアプログラムは、ファクトリー
システムデザイナーが、運動制御装置を含む非常に多数の入力／出力（Ｉ／Ｏ）
装置を、ファクトリーのフロア環境を自動化するのに使用される複雑なシステム
へと結合するアプリケーションプログラムを開発できるようにする。これらのフ
ァクトリーオートメーションアプリケーションは、Ｉ／Ｏ装置が高レベルプログ
ラムによってサポートされる限り、いかなる数のＩ／Ｏ装置でも所与のシステム
に使用することができる。他のソフトウェア開発者により開発されるカスタムア
プリケーションは、ファクトリーオートメーションプログラムにより与えられる
簡単な運動制御機能の利点を取り入れるように開発することができない。

【０００６】 更に、これらのプログラムは、プログラマーがシステム内の各運動制御装置を
著しく制御するのを許さない。ファクトリーオートメーションアプリケーション
で開発される各プログラムは、そのアプリケーションのコンテクスト内で実行さ
れねばならない。 この全体的なコンテクストにおいて、特定のタスクを遂行するための専用の運
動制御システムを形成するのに、多数の異なる個人が含まれる。通常、これらの
個人は、運動制御システムを形成する全体的プロセスにおいて特定のタスクを遂
行できるようにする特殊な背景を有する。従って、運動制御システムの開発で協
働する異種の相補的背景をもつ個人間の協力を容易にするシステム及び方法が要
望される。 従来、運動システムをプログラミングしそしてカスタマイズすることは、非常
に経費がかかり、従って、商業的工業的環境に限定される。しかしながら、カス
タマイズできる運動システムの使用は、消費者レベルまで拡張することができ、
そしてここで運動媒体と称する運動制御ソフトウェアを分配する新規なシステム
及び方法が要求される。

【０００７】

【公知技術】

個々の運動制御装置をプログラミングするか又は多数の運動制御装置を含むシ
ステムの開発に助成するために多数のソフトウェアプログラムが現在存在する。 以下は、現在商業的に入手できる高レベルソフトウェアプログラムを開示する
文書のリストである。（ａ）Software Products For Industrial Automation, i
conics 1993；（ｂ）The complete, computer-based automation tool (IGSS),
Seven Technologies A/S；（ｃ）Open Batch Product Brief, PID, Inc；（ｄ）
FIX Product Brochure, Intellution (1994)；（ｅ）Paragon TNT Product Broc
hure, Intec Controls Corp.；（ｆ）WEB 3.0 Product Brochure, Trihedral En
gineering LTD. (1994)；及び（ｇ）AIMAX-WIN Product Brochure, TA Engineer
ing Co., Inc.。次の文書は、シミュレーションソフトウェアを開示するもので
ある。（ａ）Exper Tune PID Tuning Software, Gerry Engineering Software；
及び（ｂ）XANALOG Model NL-SIM Product Brochure, XANALOG。

【０００８】 以下のリストは、低レベルプログラムに関連した文書を識別する。（ａ）Comp
umotor Digiplan 1993-94 catalog, page 10-11；（ｂ）Aerotech Motion Contr
ol Product Guide, page 233-34；（ｃ）PMAC Product Catalog, page 43；（ｄ
）PC/DSP-Series Motion Controller C Programming Guide, page 1-3；（ｅ）O
regon Micro Systems Product Guide, page 17；（ｆ）Precision Microcontrol
Product Guide。 本出願人は、ウインドウズプログラミング環境において使用するためにマイク
ロソフト社により定義されたＷＯＳＡとも称されるソフトウェアモデルも知って
いる。ＷＯＳＡモデルは、書籍「Inside Windows 95」、第３４８−３５１ペー
ジに掲載されている。又、ＷＯＳＡモデルは、「WOSA Backgrounder: Deliverin
g Enterprise Services to the Windows-based Desktop」と題する論文にも述べ
られている。ＷＯＳＡモデルは、下位ハードウェア又はサービスとは独立したＡ
ＰＩ層と、ハードウェア独立であるがサービス従属であるＳＰＩ層とを設けるこ
とにより、異なるサービスプロバイダーに対してプログラミングする複雑さから
アプリケーションプログラマーを分離する。ＷＯＳＡモデルは、運動制御装置と
は何ら関係を有していない。

【０００９】 又、本出願人は、プリンター等のハードウェアに対してドライバーが設けられ
、ワードプロセッサのようなアプリケーションプログラムによりユーザが所与の
プリンターに関連したドライバーを選択してアプリケーションプログラムがその
所与のプリンターでプリントを行えるようにする共通のプログラミング習慣も知
っている。 この解決策は、既存の各ハードウェアコンフィギュレーションに対するプログ
ラミングの複雑さからアプリケーションプログラマーを分離するが、この解決策
は、基本的な増分ステップでハードウェアを制御する能力をアプリケーションプ
ログラマーに与えるものではない。プリンターの例では、アプリケーションプロ
グラマーは、設けられたプリンタードライバーを使用してプリンターの各ステッ
パモーターを制御することができず、むしろ、プリンタードライバーは、高レベ
ルコマンドのグループを実施するために必要に応じて所定のシーケンスでプリン
ター内の多数のステッパモーターを制御する。

【００１０】 従って、プリンター等に現在使用されているソフトウェアドライバーモデルは
、運動制御装置に対する一連の制御コマンドの開発に適用することができない。 本出願人は、更に、高レベルプログラマーがあるプログラミング変数にアクセ
スするのを制限するために一般的なプログラミングに使用されるアプリケーショ
ンプログラミングインターフェイスセキュリティスキムも知っている。例えば、
マイクロソフト社のＷｉｎ３２プログラミング環境は、このようなセキュリティ
スキムを実施する。しかしながら、本出願人が知る限り、運動制御システムに使
用するためのソフトウェアを発生するように設計されたプログラミングシステム
にはこのようなセキュリティスキムがこれまで使用されていない。

【００１１】

【発明の開示】

本発明は、運動制御システム用の運動媒体を発生しそして分配するためのシス
テムを提供する。制御ソフトウェアシステムが、インターネットのようなネット
ワークに接続される。制御ソフトウェアシステムは、ネットワークを経てクライ
アントに運動媒体を分配する。ネットワークに接続されたコンテンツサーバーが
アプリケーションプログラムを生成し、これは、運動媒体としてクライアントに
直接送信することもできるし、又はハードウェア独立の運動媒体を発生する制御
コマンド発生システムにより処理することもできる。 制御ソフトウェアシステムは、サービスマネージャーモジュール、メタエンジ
ンモジュール、インターリーブエンジンモジュール、フィルターリングエンジン
モジュール、及び／又はストリーミングエンジンモジュールの１つ以上を含む。
ソフトウェアシステムは、更に、運動スクリプト、運動媒体、及び／又はレート
付けされた運動媒体を記憶するためのメモリを備えている。

【００１２】

【発明を実施するための最良の形態】

図１を参照すれば、２０で示されているのは、分散型ネットワーク２２を経て
クライアントブラウザ２４及びコンテンツサーバー２６との間で運動媒体の形態
の運動コンテンツを発生し、分配しそして収集するように構成された制御ソフト
ウェアシステムである。 分散型ネットワーク２２は、従来のコンピュータネットワーク、例えば、プラ
イベートイントラネット、インターネット、或いは他の特殊な又は所有権のある
ネットワーク構成、例えば、工業用の自動化市場に見られるもの（例えば、ＣＡ
Ｎバス、デバイスネット(DeviceNet)、フィールドバス(FieldBus)、プロフィバ
ス(ProfiBus)、イーサネット（登録商標）、決定論的イーサネット、等）である
。分散型ネットワーク２２は、制御ソフトウェアシステム２０、クライアントブ
ラウザ２４、及びコンテンツサーバー２６の間にデータを流せるようにする通信
リンクとして働く。

【００１３】 クライアントブラウザ２４は、エンドユーザにより所有され及び／又は操作さ
れる運動システム又は装置に関連される。クライアントブラウザ２４は、ここで
ターゲット装置と称するものを含むか又はそれに接続される。ターゲット装置は
、運動システムを制御するのに使用されるハンドヘルド式ＰＤＡ、運動システム
を制御するのに使用されるパーソナルコンピュータ、工業用マシン、電子玩具、
或いは最低限物理的な運動を生じさせる他の形式の運動ベースシステムである。
クライアントブラウザ２４は、多数のソースから運動媒体を再生し、そして制御
ソフトウェアシステム２０のような他のソースからの運動データの要求に応答す
ることができる。例示的なクライアントブラウザ２４は、制御ソフトウェアシス
テム２０から運動データを受信する。

【００１４】 クライアントブラウザ２４の一部分を形成するか又はそれに接続されたターゲ
ット装置は、最低限、実行すべき運動コンテンツ命令（制御及びコンフィギュレ
ーションコンテンツ）並びに問合せ要求（問合せコンテンツ）を受信するマシン
又は他のシステムである。各コンテンツ形式は、クライアントブラウザの状態を
変更し、物理的な運動を生じさせ及び／又はクライアントブラウザから値を問合
せるといったアクションをクライアントブラウザ２４に生じさせる。更に、クラ
イアントブラウザ２４におけるターゲット装置は、オーディオを再生し及び／又
はビデオ又はアニメグラフィックスを表示するといった他の機能を遂行すること
もできる。

【００１５】 ここで使用する「運動媒体」という用語は、ターゲット装置の設定又は現在行
われているアクションを記述し及び／又は運動関連オペレーションを遂行するよ
うにクライアントブラウザ２４に指令するデータセットを指す。クライアントブ
ラウザ２４は、通常、ホスト制御ソフトウェアシステム２０のクライアントであ
ると考えられ、１つのクライアントブラウザ２４が示されているが、多数のクラ
イアントブラウザがシステム２０により共通にサポートされる。以下の説明及び
添付された資料において、システム２０及びクライアントブラウザ２４の役割を
逆にして、クライアントブラウザがホストとして働きそしてシステム２０がクラ
イアントであるようにしてもよい。

【００１６】 必ずしもそうでないが多くの場合に、エンドユーザは、運動媒体を開発するの
に必要な専門知識又はファシリティをもたない。この場合、運動媒体は、コンテ
ンツサーバー２６を動作するコンテンツプロバイダーにより開発された運動プロ
グラムに基づいて発生することができる。従って、コンテンツサーバーシステム
２６は、運動プログラムの形態の運動コンテンツを与え、ここから、制御ソフト
ウェアシステム２０は、運動媒体を発生し、これがクライアントブラウザ２４へ
供給される。 又、コンテンツサーバーシステム２６は、制御ソフトウェアシステム２０のク
ライアントとも考えられ、多数のこのようなサーバーシステム２６がシステム２
０により共通にサポートされる。コンテンツサーバー２６は、必ずしもそうでは
ないが、制御ソフトウェアシステム２０を動作する同じ当事者によって動作され
てもよい。参考としてここに添付する添付資料１は、通信ネットワークにおける
コンテンツサーバーの使用を更に詳細に示している。

【００１７】 上記で簡単に述べたように、クライアントブラウザ２４により使用される運動
媒体は、他のシステム及び方法によって生成されて分配されてもよいが、ここに
述べる制御ソフトウェアシステム２０は、このような運動媒体の生成及び分配を
実際的且つ経済的に実現可能なものにする。 運動媒体は、問合せコンテンツ、コンフィギュレーションコンテンツ、制御コ
ンテンツ及び／又はその組合せを含む多数のコンテンツ形式又はデータ形式より
成る。コンフィギュレーションコンテンツは、クライアントブラウザ２４を構成
するのに使用されるデータを指す。問合せコンテンツは、クライアントブラウザ
２４から読み取られたデータを指す。制御コンテンツは、図１に２８で概略的に
示す所望の運動タスクを遂行するようにクライアントブラウザ２４を制御するの
に使用されるデータを指す。

【００１８】 コンテンツプロバイダーは、１つ以上のオーディオ、ビデオ、ショックウェー
ブ又はフラッシュアニメグラフィックスのような非運動データや他の種々の形式
のデータを提供することができる。好ましい実施形態では、制御ソフトウェアシ
ステム２０は、運動データをこのような非運動データと合併して、特殊な形式の
運動媒体を得ることができ、特に、非運動データを含む運動媒体は、ここでは、
エンハンスト運動媒体と称する。 本発明は、本出願人の米国特許第５，６９１，８９７号及び第５，８６７，３
８５号に開示されたようなハードウェア独立モデルを使用して運動プログラムか
ら運動媒体が発生されるときに特に意義がある。これら特許の開示は、参考とし
てここに援用するものである。しかしながら、本発明は、運動媒体が、従来のよ
うに、特定のハードウェア装置に対して特に書かれた運動プログラムから発生さ
れるときにも適用できる。

【００１９】 以下に詳細に説明するように、制御ソフトウェアシステム２０は、次の機能の
１つ以上を遂行する。制御ソフトウェアシステム２０は、その制御ソフトウェア
システム２０とクライアントブラウザ２４との間のデータ接続を開始する。又、
制御ソフトウェアシステム２０は、コンテンツサーバーシステム２６からの運動
プログラムの形態の入力に基づいて運動媒体を生成する。更に、制御ソフトウェ
アシステム２０は、運動媒体を動的な運動媒体又は静的な運動媒体のいずれかと
してクライアントブラウザ２４へ供給する。動的な運動媒体は、要求があったと
きにシステム２０により生成されるが、静的な運動媒体は生成されて、後で検索
するために永続的な記憶位置に記憶される。 再び、図１を参照すれば、例示的な制御ソフトウェアシステム２０は、サービ
スマネージャー３０と、メタエンジン３２と、インターリーブエンジン３４と、
フィルタリングエンジン３６と、ストリーミングエンジン３８とを備えている。
この例示的なシステム２０において、運動媒体は位置４０に記憶され、運動スク
リプトは位置４２に記憶され、一方、レート付けされた運動データは、位置４４
に記憶される。これらの記憶位置は、１つの物理的な装置でもよいし、又は１つ
の形式の記憶しか必要とされない場合には１つの位置でもよい。

【００２０】 本発明により構成された所与の制御ソフトウェアシステムには、これらの要素
の全部が必要とされるのではない。例えば、所与の制御ソフトウェアシステムが
運動媒体のみを供給し、エンハンスト運動媒体は供給しないよう意図された場合
には、インターリーブエンジン３４を省略又はディスエイブルしてもよい。或い
は、システムデザイナーが、コンテンツルールに基づいて運動媒体の分配を制御
することに関与しない場合には、フィルタリングエンジン３６及びレート付けさ
れた運動記憶位置４４を省略又はディスエイブルしてもよい。 サービスマネージャー３０は、制御ソフトウェアシステム２０を構成する他の
全てのモジュールを整合する役割を果たすソフトウェアモジュールである。又、
サービスマネージャー３０は、ネットワークにわたり全てのクライアントに対す
る主たるインターフェイスでもある。

【００２１】 メタエンジン３２は、問合せ、コンフィギュレーション及び制御アクションを
含む全ての運動データを個別の運動パケットへとアレンジする役割を果たす。メ
タエンジン３２は、更に、運動パケットを、信頼性あるオペレーションを確保す
るために一緒に実行しなければならない最小数の運動パケットを作り上げる運動
フレームへとグループ編成する。信頼性が問題でない場合には、各運動フレーム
は、運動データの１つのパケット即ち１つの運動命令のみを含む。メタエンジン
３２は、更に、運動フレームを、ターゲット運動システムにより実行されるべき
一連の運動オペレーションを作り上げる運動スクリプトへとグループ編成する。
これら運動パケット及び運動スクリプトは、上記の運動媒体を形成する。運動フ
レーム及び運動スクリプトを形成するプロセスは、参考としてここに添付する添
付資料２に詳細に説明されている。

【００２２】 インターリーブエンジン３４は、運動パケットより成る運動フレームを含む運
動媒体を非運動データと合併する役割を果たす。運動媒体と非運動データとの合
併は、参考としてここに添付する添付資料３に詳細に説明されている。 運動フレームは、時間ベース、パケット又はデータサイズベース、或いはパケ
ットカウントベースのいずれかで他の非運動データと混合される。運動のフレー
ムを他の媒体と時間ベースで混合するときには、運動フレームが他のデータと同
期され、運動オペレーションが見掛け上他の媒体と同期して発生するようになる
。例えば、運動／オーディオ混合物を再生するときには、ターゲット運動システ
ムは、オーディオサウンドと同期して運動するように制御される。

【００２３】 非運動データ（例えば、オーディオ、ビデオ等）に関連したデータを、運動に
関連したデータと合併した後に、新たなデータセットが生成される。上述したよ
うに、運動媒体を非運動データと合成するこの新たなデータセットは、ここでは
、エンハンスト運動媒体と称する。 より詳細には、インターリーブエンジン３４は、クライアントブラウザ２２に
おけるターゲット装置の能力に基づいて２つの方法の１つでエンハンスト運動媒
体を形成する。第三者のコンテンツサイト又はターゲット装置自体のいずれかに
より非運動フォーマットを（デフォールトフォーマットとして）使用するように
要求されたときには、運動フレームが非運動媒体に注入される。さもなければ、
インターリーブエンジン３４は、非運動媒体を運動媒体に「生のデータ」の特殊
な運動コマンドとして注入するか、又は非運動データ形式（即ち「オーディオデ
ータ」又は「ビデオデータ」）を特定する。デフォールトにより、インターリー
ブエンジン３４は、運動データを非運動データに注入することによりエンハンス
ト運動媒体を生成する。

【００２４】 フィルタリングエンジン３６は、レーティング（レート付け）データを運動媒
体データセットに注入する。レーティングデータは、レーティングデータ記憶位
置４４に記憶されるものであり、運動媒体を構成する各スクリプト又はフレーム
の始めに注入されるのが好ましい。クライアントブラウザ２２は、レーティング
ルールを含み、そしてもし必要であれば、受信した全ての運動媒体をこれらルー
ルに基づいてフィルタして、フィルタされた運動媒体を得る。 特に、クライアントブラウザ２２は、受信した運動媒体に含まれたレーティン
グデータを、ブラウザ２２に記憶されたレーティングルールと比較する。クライ
アントブラウザ２２は、レーティングデータがレーティングルールで実施される
パラメータ内に入るときに、運動媒体をフレームごとに又はスクリプトベースで
受け入れる。クライアントブラウザは、レーティングデータがレーティングルー
ルで実施されるパラメータ内に入らないときには、媒体をフレームごとに又はス
クリプトベースで全体的又は部分的に拒絶する。

【００２５】 別の実施形態では、フィルタリングエンジン３６は、レート付けされた運動デ
ータをブロードキャストするときに運動媒体を動的にフィルタするように構成さ
れてもよい。従って、運動媒体における不適切な運動コンテンツの変更又は抑制
がフィルタリングエンジン３６において実行される。特に、フィルタリングエン
ジン３６は、送信される運動媒体のレーティングをダウングレードするか又はそ
の送信を防止し、クライアントブラウザ２２に到達する運動媒体がブラウザ２２
におけるレーティングルールに合致するようにする。 運動媒体は、ターゲットシステムのレーティングルール内に入るフレームを、
ターゲットシステムのレーティング内に入らないフレームと置き換えることによ
りダウングレードされる。従って、フィルタリングエンジン３６は、ここでレー
ト付けされた運動媒体と称する又は運動媒体が非運動データを含む場合にはレー
ト付けされたエンハンスト運動媒体と称するデータセットを発生する。

【００２６】 ストリーミングエンジン３８は、最終的なデータセット（生の運動スクリプト
、エンハンスト運動媒体、レート付けされた運動媒体、又はレート付けされたエ
ンハンスト運動媒体）を取り出し、そしてこの最終的なデータセットをクライア
ントブラウザ２２へ送信する。より詳細には、生の更新セッションでは、最終的
なデータセットが全体的にクライアントブラウザ２２へ送信され、従って、それ
に関連したターゲット装置に送信される。データをターゲット装置へストリーミ
ングするときには、データセットがターゲット装置に連続的に送信される。任意
であるが、ターゲットシステムは、受信される残りの運動ストリームの前に連続
的な媒体再生を維持するに充分な再生データが存在するまでデータをバッファす
る。これは、ターゲット装置が各フレームを、それが受け取られるときに再生す
るよう選択してもよく、しかも、ネットワークの速度が、媒体を連続的に再生す
る能力を低下し得るので、任意である。このプロセスは、運動媒体データセット
が終了するまで続けられてもよいし、又は運動媒体が動的に発生されるときにそ
れが不定に再生されてもよい。

【００２７】 図２は、ホストシステムソフトウェア２０及びクライアントブラウザ２４のタ
ーゲット装置間でデータを通信することのできる種々の形態を示すブロック図で
ある。ホストとターゲットとの間にデータを送信できるようになるまでに、その
両者間にネットワーク接続を開始しなければならない。この開始プロセスを行う
方法は多数存在する。図２に示すように、この開始プロセスは、ブロードキャス
ティング、生の更新及び要求ブローカーによって行うことができる。 更に、図２に示すように、ホストとターゲットシステムとの間に接続がいった
ん開始されると、コンテンツ供給が動的に行われるか、又は既に生成されたコン
テンツの静的なプールを経て行われる。動的にコンテンツを供給するときには、
コンテンツが要求を介して第三者コンテンツサイトからスレーブモードで送信さ
れ、この場合、第三者は、ターゲットシステムに代わってホストから運動媒体を
要求する。或いは、動的なコンテンツがマスターモードで供給されてもよく、こ
の場合、ターゲットシステムは、運動サービスが存在するホストから運動媒体の
直接的な要求を発する。

【００２８】 以下、図３ないし８に示す筋書きマップについて詳細に説明する。これらの筋
書きマップは、制御ソフトウェアシステム２０が動作するところの多数の筋書き
を示す。 最初に、図３を参照すれば、ホストがネットワークを横切って考えられる全て
のターゲットに情報を送信して、その各々に、ホストが運動媒体を送信するため
の接続を開始する準備ができたことを通知するブロードキャスティングプロセス
を記述する筋書きマップが示されている。ブロードキャスティングは、ユーザダ
イアグラムプロトコル（即ちＵＤＰ）を経てデータを送信することにより無接続
プロトコルを介してホストの既存の全クライアントに通知することによってクラ
イアントとの接続を開始することより成る。ＵＤＰは、インターネットプロトコ
ルの標準的なＴＣＰ／ＩＰファミリーの一部分である無接続プロトコル規格であ
る。ホストがサービスすべき運動媒体を有することが通知されると、各ターゲッ
トは、接続を完了するための受け入れに応答することができる。又、ブロードキ
ャスティングプロセスは、参考としてここに添付した添付資料１及び４にも説明
されている。

【００２９】 ブロードキャスティングを経て接続を開始するときには、次のステップが生じ
る。 第１に、データをブロードキャスティングする前に、サービスマネージャー３
０は、使用可能なコンテンツ及びそのレーティング情報についてメタエンジン３
２及びフィルターエンジン３６に問合せする。 第２に、問合せされたときに、フィルタリングエンジン３６は、メタエンジン
３２を経てエンハンスト又は非エンハンスト運動媒体へのアクセスを得る。フィ
ルタリングエンジン３６は、レーティングデータを抽出し、インターネットサー
ビスマネージャー３０までそれにサービスする。

【００３０】 第３に、運動媒体記述子が形成されそしてネットワークを横切って送出される
。この媒体記述子は、サービスされるレート付けされた媒体に対するレーティン
グのリストと同程度に簡単なデータを含む。或いは、記述子は、サポートされる
媒体カテゴリーの形式のようなより広範囲なデータ（即ち、入手可能な２脚及び
４脚付きの玩具に対する媒体）を含んでもよい。この情報は、無接続プロトコル
を使用してネットワークを横切って盲目的に送信される。いずれかのターゲット
がブロードキャストを受信するという保証はない。上述したように、レーティン
グデータは任意であり、それが使用されない場合には、ヘッダ情報のみがターゲ
ットに送信される。

【００３１】 第４に、ターゲットがブロードキャストを受信し、コンテンツレーティングが
ターゲットレーティングの基準を満足しそしてターゲットが接続に対してオープ
ンである場合には、ターゲットが確認メッセージをホストに送信するときに接続
が完了となる。この確認メッセージを受信すると、ホストとターゲットとの間に
接続がなされ、そしてホストは、動的又は静的なコンテンツ供給に対する準備を
開始する。 図４は、生の更新接続開始のプロセスを示す筋書きマップである。生の更新接
続は、ホストとターゲットとの間の予め定義された基準をベースとする接続であ
って、ターゲットは予め登録されて即ち「既知」であり、そしてホストは、通知
メッセージをこの既知のターゲットに直接送信する。生の更新接続開始のプロセ
スは、参考としてここに添付する添付資料１及び５にも開示されている。

【００３２】 生の更新を遂行するときには次のステップが実行される。 第１に、インターネットサービスマネージャー３０は、運動媒体及びレーティ
ング情報を収集する。収集される運動媒体情報は、既知の即ち予め登録されたタ
ーゲットにより以前に登録された情報に基づく。例えば、ターゲットレジスタそ
れ自体を２脚付き玩具と言えば、このような場合、ホストは、２脚付き運動媒体
に関するデータのみを収集し、そして他の全ての分類の運動媒体を無視する。 第２に、問合せされたときに、フィルタリングエンジン３６は、次いで、メタ
エンジン３２に生のレーティング情報について問合せする。更に、メタエンジン
３２は、生の更新を介して送信されるべき運動媒体に関するヘッダ情報を問合せ
る。

【００３３】 第３に、運動媒体ヘッダ情報及びそれに関連したレーティング情報は、ターゲ
ットシステムに送信される。レーティング情報が使用されない場合には、ヘッダ
情報のみがターゲットに送信される。 第４に、ターゲットシステムは、運動媒体をそのレーティング又は他の環境、
例えば、ターゲットシステムが既にビジーで運動媒体を実行していることに基づ
いて、受け入れ又は拒絶する。 図５は、ターゲットがホストから運動媒体を要求することによってホストとの
接続を開始するマスターモードにおける要求ブローカリングのプロセスを示す。 第１に、要求ブローカー接続を開始するために、ターゲットは、運動媒体デー
タセットを供給したい旨をホストに通知する。ターゲットは、それがコンテンツ
フィルタリングをサポートする場合に、それが受け入れできる最も高いレーティ
ング（又はターゲットシステムのオペレータ入力又は他のパラメータに基づいて
受け入れたい最高のもの）と、そのレーティングに基づいて媒体を拒絶又はダウ
ングレードすべきかどうかも送信する。

【００３４】 第２に、サービスマネージャー３０は、メタエンジン３２に要求された媒体に
ついて問合せし、そして要求されたレーティングをコンテンツのレーティングと
比較するようにフィルタリングエンジン３６に問合せする。レーティングがレー
ティングルールの基準を満足しない場合には、フィルターエンジンがコンテンツ
ヘッダダウンサイジングサポート情報を使用してレーティングコンテンツダウン
サイジングを実行する。 第３に、メタエンジン３２は、要求された運動媒体に対して全てのヘッダ情報
を収集し、そしてそれをサービスマネージャー３０に返送する。

【００３５】 第４に、レーティングがサポートされる場合には、メタエンジン３２は、レー
ト付けされた運動媒体４４から全ての生のレーティング情報も問合せする。レー
ティングが使用されるときには、レート付けされた運動媒体４４が、もし使用で
きれば、排他的に使用される。媒体が既にレート付けされている場合には、その
レート付けされた媒体が送出される。コンテンツサーバーにおいてフィルタリン
グがサポートされない場合には、レーティング情報が無視され、そして生の運動
スクリプト又は運動媒体データが使用される。 第５に、運動媒体ヘッダ情報及びレーティング情報（もし使用できれば）は、
要求を発しているターゲット装置に返送され、該装置は、次いで、接続を受け入
れるか又は拒絶する。もしそれを受け入れる場合には、サービスマネージャー３
０に通知が返送されて、コンテンツ供給セッションの準備をスタートするように
指令する。

【００３６】 図６は、要求ブローカー接続開始をスレーブモードにおいて示している。スレ
ーブモードの接続開始においては、ターゲットが第三者コンテンツサーバー２６
との接続を開始し、次いで、このコンテンツサーバーは、ターゲットシステムに
代わってホストとの接続を開始する。スレーブモードにおける要求ブローカリン
グは、マスターモードにおける要求ブローカリングと同様であるが、ターゲット
システムは、ホストシステムではなく、第三者コンテンツサーバー２６と直接的
に通信する。 スレーブモードは、第三者コンテンツサイトを使用して運動コンテンツ発生を
駆動するときに特に意義がある。例えば、運動媒体は、第三者コンテンツサイト
により発生された非運動データに基づいて発生することができる。音楽サイトは
、オーディオサウンドをホストシステムに送信し、ホストシステムは、次いで、
オーディオサウンドに基づいて運動を発生する。

【００３７】 スレーブモードで要求ブローカリングするときには次のステップが生じる。 第１に、ターゲットシステムは、第三者コンテンツサーバーからコンテンツを
要求する（例えば、ターゲットシステムに接続されるか又はその一部分である玩
具において再生する歌を要求する）。 第２に、要求を受信すると、第三者コンテンツサーバーは、要求された歌を探
索する。 第３に、第三者コンテンツサーバー２６は、次いで、歌の題名及びおそらくは
要求された関連運動スクリプト（１つ又は複数）を、運動インターネットサービ
スマネージャー３０が存在するホストシステム２０に送信する。 第４に、第三者コンテンツサーバー２６からコンテンツヘッダを受信すると、
サービスマネージャー３０は、レーティング情報（もしあれば）及び要求された
運動スクリプトを探索する。

【００３８】 第５に、レーティング情報は、フィルタリングエンジン３６へ送信されて、運
動媒体が適当であることが照合されると共に、要求された運動スクリプト情報が
メタエンジン３２へ送信される。 第６に、フィルタリングエンジン３６は、要求された運動媒体からレーティン
グ情報を抽出し、そしてそれを、第三者コンテンツサーバー２６を経て得たター
ゲットシステムのレーティング要求と比較する。又、メタエンジンは、運動媒体
ヘッダ情報を収集する。 第７に、メタエンジン３２は、フィルタリングエンジン３６に代わってレート
付けされた運動媒体からレーティング情報を抽出する。 第８に、コンテンツが得られるかどうか及びそれがターゲットのレーティング
要求を満足するかどうかについて第三者コンテンツサーバーに通知がなされるか
又はターゲットシステムに直接的に通知がなされる。ターゲットは、応答に基づ
いて接続を受け入れるか又は拒絶する。もし受け入れる場合には、運動インター
ネットサービスがコンテンツ供給の準備を開始する。

【００３９】 図７は、ホストが運動媒体をいかに動的に生成しそしてターゲットシステムま
でそれにサービスするかを示す。ホストとターゲットとの間に接続が開始される
と、コンテンツ供給が開始される。動的なコンテンツ供給は、運動スクリプト（
予め生成されたスクリプト又は動的に発生されるスクリプト）を外部媒体（即ち
オーディオ、ビデオ等）と混合することにより、エンハンスト運動媒体をリアル
タイムで実際に生成することを含む。更に、レーティングをダウングレードする
ことが要求される場合には、媒体がターゲットシステムのレーティング要求を満
足するように調整される。 第１ステップでは、第三者コンテンツサーバーからのコンテンツがホストに送
信されるか、又は第三者コンテンツサーバーにより管理されるコンテンツに運動
媒体を注入するようにホストが要求される。残りのステップは、第三者コンテン
ツサーバーからのコンテンツがホストに送信される状態に特に向けられるが、同
じ一般的ロジックを他の状態に適用することもできる。

【００４０】 第２に、第三者コンテンツサーバーとのコンテンツ接続を受信すると、サービ
スマネージャー３０は、非運動データ（即ち、オーディオ、ビデオ、フラッシュ
グラフィック、等）と運動スクリプトとの混合を開始するようにインターリーブ
エンジン３４を指令する。 第３に、インターリーブエンジン３４は、メタエンジン３２を使用して、運動
スクリプトにアクセスする。インターリーブエンジン３４により指令されるよう
に、メタエンジン３２は、インターリーブエンジン３４により使用されるインタ
ーリーブアルゴリズム（即ち、時間ベース、データサイズベース、又はパケット
カウントベースのインターリーブ）に基づいて運動のスクリプト及び／又はフレ
ーム間に全非運動データを注入する。これは、運動媒体データセットをエンハン
スト運動媒体データセットに変換する。

【００４１】 第４に、レーティングが使用されそしてターゲットレーティング基準をベース
とするダウングレードが要求される場合には、フィルタリングエンジン３６は、
レーティングに基づいて拒絶されたコンテンツを選択して、低いレーティングを
もつ同等のオペレーションと置き換えるように、メタエンジン３２に要求する。
例えば、低いレーティングをもつほとんど激しさのない運動が、高いレーティン
グをもつ非常に激しい運動に置き換えられる。レート付けされたエンハンストデ
ータセットは、レート付けされた運動媒体として位置４４に記憶される。上述し
たように、サービスマネージャー３０がコンテンツレーティングをサポートしな
いので、このステップは任意である。

【００４２】 第５に、メタエンジン３２は、フィルタリングエンジン３６により要求された
ときに最終的な運動媒体データセットを発生する。 第６に、それによって得られた最終的な運動媒体データセット（エンハンスト
運動媒体又はレート付けされたエンハンスト運動媒体）のいずれかを含む）は、
ストリーミングエンジン３８に通される。ストリーミングエンジン３８は、次い
で、その最終的なデータセットをターゲットシステムに送信する。 第７に、小さなデータセットの場合には、データが全体的に送信された後に、
ターゲットシステムにより実際に再生されてもよい。大きなデータセット（又は
連続的に生成される無限のデータセット）の場合には、ストリーミングエンジン
が全てのデータをデータストリームとしてターゲットに送信する。 第８に、ターゲットは、データを再生することが新たなデータをバッファする
ことに追いつかなくなるポイントまで全てのデータをバッファし、従って、ター
ゲットは、運動媒体を連続的に実行させることができる。

【００４３】 図８は、予め生成された又は静的な運動媒体をホストがターゲットシステムに
対していかにサービスするかを示す。静的なコンテンツ供給は、ターゲットから
要求が受け取られる前に全てのデータが準備される以外は、動的な供給と同様で
ある。コンテンツは、静的なコンテンツでは、オンザフライでは生成されず、又
、リアルタイムでも生成されない。 静的なコンテンツをホストからターゲットへ供給するときには次のステップが
行われる。 第１ステップでは、第三者コンテンツサーバー２６からの運動媒体がホストに
送信されるか、又は既に生成された運動媒体を検索するようにホストが要求され
る。残りのステップは、既に生成された運動媒体を検索するようにホストが要求
される状態に対して特有であるが、同じ一般的ロジックを他の状態に適用するこ
ともできる。

【００４４】 第２に、第三者コンテンツサーバーとのコンテンツ接続を受信すると、サービ
スマネージャー３０は、運動媒体を検索するようにメタエンジン３２に指令する
。 第３に、メタエンジン３２は、最終的な運動媒体データセットを検索し、そし
てその位置をサービスマネージャー３０へ返送する。この場合も、最終的な運動
セットは、運動スクリプト、エンハンスト運動媒体、レート付けされた運動媒体
、又はレート付けされたエンハンスト運動媒体を含む。 第４に、最終データの運動媒体データセットは、ストリーミングエンジン３８
へ通され、該エンジンは、次いで、そのデータをターゲットシステムに供給する
。 第５に、小さなデータセットの場合には、データが全体的に送信された後に、
ターゲットシステムにより実際に再生されてもよい。大きなデータセット（又は
連続的に生成される無限のデータセット）の場合には、ストリーミングエンジン
が全てのデータをデータストリームとしてターゲットに送信する。 第６に、ターゲットは、データを再生することが新たなデータをバッファする
ことに追いつかなくなるポイントまで全てのデータをバッファし、従って、ター
ゲットは、運動媒体を連続的に実行させることができる。

【００４５】 ここに述べる制御ソフトウェアシステム２０は、種々様々な環境に使用するこ
とができる。以下、このシステム２０を多数のオペレーティングモードに基づき
多数の例示的環境においていかに使用するかについて説明する。より詳細には、
ソフトウェアシステム２０は、ブロードキャスティングモデル、要求ブローカリ
ングモデル又は自律的分配モデルにおいて実施される。これらの各モデルが多数
の異なる環境にいかに適用されるかの例を説明する。 ホストマシンを使用してデータセットの大きな集合体を生成しそして記憶し、
次いで、それらを、視聴されてもされなくてもよい１組の多数のターゲット装置
へと展開するブロードキャストモデルは、多数の環境に使用することができる。
このブロードキャストモデルは、ラジオ局によって送信されたデータを聞くのに
使用される１組のラジオへデータを放送するラジオ局と同様である。

【００４６】 このブロードキャストモデルは、工業用自動化の多数の領域で実施することが
できる。例えば、ホストマシンを使用してデータセットを発生し、これらデータ
セットを使用して、ファクトリーのフロア上のマシンを制御することができる。
各データセットは、工学的図面を既知のフォーマット（ＡｕｔｏＣａｒｄ又は他
の一般的なＣＡＤパッケージによりサポートされるデータフォーマットのような
）からデータセットに変換し、これを記憶して最終的に１組のターゲット装置に
ブロードキャストすることにより、ホストマシンによって生成することができる
。各ターゲット装置は、同じ形式のマシンでよい。データセットを同じ形式の全
てのマシンにブロードキャストすると、ファクトリーで大きな１組の製品を製造
することができる。例えば、各ターゲット装置は、フライス盤でよい。フライス
盤のグループに送信されたデータセットは、各マシンが同じ部品を同時に製造す
るようにさせ、従って、２つ以上の同じ部品を同時に製造し、ひいては、生産性
を高める。

【００４７】 又、工業用の自動化は、インターネット（又は他のネットワーク）リンクを経
てホストマシンへ送信される工学的図面からデータセットが変換されるようなプ
ログラム分配をしばしば含む。受信すると、ホストは、そのデータを、エンドユ
ーザにより選択される多数の機械工場の１つにおいて運転されるマシンの形式へ
と変換する。変換が完了した後に、データセットは、データリンクを横切って指
定の機械工場におけるターゲット装置に送信され、ターゲット装置は、フライス
盤又は旋盤である。データセットを受信すると、ターゲット装置は、そのデータ
セットにより定義された一連の運動を実行することによって機械的部品を形成す
る。形成されると、機械工場は、工学的図面を最初にホストへ送信したユーザに
その部品をメールにより送信する。このモデルは、図面を形成するために選択す
るところの無限数の機械工場をエンドユーザに与えるという利点を有する。一方
、このモデルは、機械工場において運転されるマシンに特有に調整されたデータ
セットを送信する非常に大きなビジネスソースも機械工場に与える。

【００４８】 又、本発明のブロードキャスティングモデルは、環境モニタリング及びサンプ
リング中にも特に意義のあるものである。例えば、環境市場においては、大きな
１組のターゲット装置が、環境浄化に関連したモニタリング又は集塵プロセスの
いずれかに使用できる。この例では、１組の装置が、川の種々のポイントに沿っ
て水溜りを攪拌するのに使用され、攪拌プロセスは、各ポイントにおけるデータ
収集を改善する重要な要素である。ホストマシンは、水を攪拌しそして１組のセ
ンサから非常に正確に読み取るのに使用されるデータセットを発生する。データ
セットは、形成されると、ホストマシンにより川に沿った全ての装置に同時にブ
ロードキャストされて、川に沿った全ての装置から同時に読み取りを行い、従っ
て、川の実際の廃棄物レベルはどんなものかについて正確な映像を時間と共に与
える。

【００４９】 又、ブロードキャスティングレベルは、農業においても意義がある。例えば、
農場主は、異なる農作方法を各々必要とする５つの異なる農作物畑を所有する。
ホストマシンは、農作される畑に特有の各データセットを形成するのに使用され
る。形成されると、ホストマシンは、各データセットを、各畑に指定されたター
ゲット装置にブロードキャストする。各ターゲット装置は、それに指定された特
定データチャンネルのみを聴取するように構成される。その指定のデータチャン
ネルを横切ってデータセットを受信すると、ターゲット装置は、各メタコマンド
を実行することによりデータセットを実行し、畑の収穫又は維持に使用される耕
作又は他の農作方法を遂行する。この場合に、ターゲット装置は、標準的な農作
装置をモーター、駆動装置、運動コントローラ、及び各メタコマンドの実行によ
り各々を制御するのに使用されるソフトウェアカーネル（ＸＭＣリアルタイムカ
ーネルのような）で改造した形態である。本発明の原理を用いて実施される農作
業は、散水、畑の点検、畑の肥沃化及び／又は畑の収穫を含む。

【００５０】 又、ブロードキャスティングモデルは、小売店業界にも使用できる。例えば、
ターゲット装置は、簡単なモーター、駆動装置、運動コントローラ、及びメタコ
マンドを実行するのに使用されるソフトウェアカーネルを使用する１組のマネキ
ンである。ホストマシンは、ターゲットマネキンの領域で再生しようとする音楽
の選択と同期されたデータセットを生成する（又は予め生成されたものを使用す
る）。次いで、ホストマシンを使用して、ターゲット装置が音楽演奏と同期して
ダンス（又は運動）できるようにデータセットをブロードキャストし、これによ
り、ターゲット装置が音楽に合わせてダンスする錯覚を与える。この例は、この
形式の娯楽がマネキンに向かって注意を引き、最終的には、マネキンが着ている
衣服に注意を引かせるので、小売店にとって有用である。ホストマシンは、固定
配線ネットワーク（イーサネットのような）、ワイヤレスリンク又は他のデータ
リンクを経てターゲットマネキンにデータセットを送信することができる。ワイ
ヤレスリンクは、容易な配置換えを維持しつつマネキンが更新を受信できるよう
にする。

【００５１】 又、ブロードキャスティングモデルは、娯楽産業にも使用することができる。
その一例は、本発明をバイオフィードバックシステムの一部分として使用するこ
とである。ターゲット装置は、人間、動物、又は通常生命のない物体の形態であ
る。ホストマシンは、フィードバックループを形成するようにデータセットを生
成する。例えば、あるバンドが音楽を演奏し、ホストマシンがそれを検出して、
データのストリーム（又は生の更新）を作り上げる一連の整合されたメタコマン
ドに変換する。データストリームは、次いで、１組のターゲット装置にブロード
キャストされ、これらターゲット装置は、次いで、音楽に対してリズムを取って
運動する。一連のメタコマンドを発生するのに使用できる他の形式の入力は、次
の幾つか、即ち標準的なサウンドシステムからの音楽、群集（例えばダンスフロ
アでダンスしている人々のグループ）から検出される熱、及び／又は群集（例え
ばロックバンドに聞き入っている聴衆）から発生される騒音レベルである。

【００５２】 又、ブロードキャスティングモデルは、消費者に直接適用することもできる。
より詳細には、本発明は、セキュリティシステムの一部分を形成することができ
る。ターゲット装置は、メタコマンドを実行できる１組の小さな運動システムで
改造された１組の家具のような簡単なものである。ホストマシンは、住居セキュ
リティの妥協であると解釈される外部事象を検出するのに使用される。検出され
ると、運動シーケンスが発生されてターゲット家具へ送信され、従って、住居に
人がいるという印象を侵入者に与え、窃盗の機会を低減させる。別のターゲット
装置は、１組のカーテンである。人が繰り返しまっすぐに引っ張ってカーテンを
引くのを模した一連の運動を加えて、住居に人がいるという錯覚を与えることが
できる。

【００５３】 又、ブロードキャスティングモデルは玩具やゲームにも適用できる。例えば、
ターゲット装置は、アクションフィギュア（例えば、ＧＩジョー、バービー及び
／又はスターウオーズフィギュア）の形態である。この場合のホストマシンは、
一連の運動を発生するのに使用され、この運動が各ターゲット装置に送信されて
玩具のエンドユーザにより再生される。データセットは、ハードウェア独立であ
るので、特定のデータセットが、多数の異なる製造者により製作された広範囲な
玩具に作用し得る。例えば、ＧＩジョーは、バービーが運動ハードウェアを実施
又は使用する方法とは著しく異なるやり方で運動を実施するハードウェアで作ら
れる。運動カーネルを使用して、全てのデータをハードウェア独立のメタコマン
ドから、各モーターを制御するためのハードウェア特有のロジック使用に変換す
ると、両方の玩具が同じデータセットを実行できる。このモデルを生の更新及び
ストリーミング技術と結合すると、各玩具は、集中型ホストから同じデータセッ
トを受け取って実行することができる。

【００５４】 又、要求ブローカリング(brokering)モデルは、本発明を多数の環境に使用で
きるようにする。要求ブローカリングとは、ターゲット装置がデータセットをホ
ストから要求し、次いで、ホストがターゲット装置に対し要求されたデータの生
の更新又はストリーミングを実行するプロセスである。 又、要求ブローカリングは、工業的自動化にも適用できる。例えば、要求ブロ
ーカリングモデルを使用して実施される本発明は、インターアクティブメンテナ
ンスを遂行するのに使用できる。この場合に、ターゲット装置は、旋盤、フライ
ス盤、又はファクトリーのフロアにおいて運動を使用するカスタム装置である。
装置に既にブロードキャストされたデータセットを実行するときには、ターゲッ
ト装置は、内部部品の機械的なブレークダウン又はモーターのような電子部品の
バーンアウトを最終的に生じさせる状態を検出するように構成される。このよう
な状態が検出されると、ターゲット装置は、現在実行されているものほど部品に
ストレスを生じない異なるデータセットで装置を更新するようにホストに要求す
る。このようなモデルは、ファクトリーフロアにおける各ターゲット装置の寿命
を改善することができる。

【００５５】 工業用自動化環境における要求ブローカリングモデルの別の例は、材料の流れ
プロセスである。この例では、ターゲット装置は、ファクトリーフロアにおける
運動を使用するカスタム装置で、異なる形式の材料を、その運動を使用する装置
により実行される複雑なプロセスへと移動するものである。材料の形式を検出す
ると、ターゲット装置は、その特定形式の材料にとって特有のオペレーションを
遂行するデータの新たな生の更新又はストリーミングを任意に要求することがで
きる。要求されると、ホストは、新たなデータセットを装置に送信し、次いで、
装置は、新たなメタコマンドを実行し、材料を適切に処理する。このモデルは、
各ターゲット装置を２つ以上の形式の材料及び／又は部品及び／又はプロセスに
使用できるので、各ターゲット装置の使用性を拡張する。

【００５６】 又、要求ブローカリングモデルは、小売業界にも適用できる。１つの例におい
て、ターゲット装置は、マネキンであるか、又は他のターゲット装置は、小売店
により販売されている商品をディスプレイし又はそれに注意を引くように使用さ
れる。センサを使用して建物又は他のスペース内の位置を検出すると（即ちグロ
ーバルポジショニングシステム）、ターゲット装置は、それがある位置から別の
位置へいつ移動されたかを検出することができる。装置の位置に基づいて、現在
位置に関するホストへデータ要求を送信することにより、その現在位置に関する
データセットを要求する。次いで、ホストマシンは、要求されたデータを送信す
る。新たなデータを受信すると、装置は、それを実行し、そしてその位置に基づ
いてその振舞いを変更することにより見掛け上位置に気付くようになる。

【００５７】 又、要求ブローカリングモデルは、玩具及びゲーム又は娯楽産業にも適用でき
る。玩具及び娯楽装置も、位置に気付くようにすることができる。他の装置は、
玩具、或いは玩具とマネキンとの混合物と同様であるが、もっと大人の設定で使
用され、装置は、装置の位置に基づくやり方で大人と対話する。又、バイオフィ
ードバックに気付く玩具及び娯楽装置は、使用する音声のトーンを検出するか、
又はユーザにより玩具に与えられる圧力の量を感知し、そしてこの情報を使用し
て、その振舞いを変更し、ひいては、見掛け上状態に気付くように新たなデータ
セット（又はデータセットのグループ）を要求する。娯楽装置は、玩具又はマネ
キンと同様であるが、バイオフィードバック、騒音、音楽等に基づいて大人と対
話するように使用される。 又、自律的分配モデルも、多数の環境に適用することができる。自律的分配モ
デルとは、各装置がホスト及びターゲット装置の両方のタスクを実行するもので
ある。各装置は、ホストマシンのようにデータを生成し、記憶しそして送信し、
しかも、ターゲット装置のようにデータを受信しそして実行する。

【００５８】 工業用の自動化においては、この自律的分配モデルは、問題を分割しそして打
ち勝つように実施することができる。このアプリケーションでは、１組の装置が
、最初に、問題の全解決策を作り上げる異なる領域に特有のデータセットで構成
される。ホストマシンは、各装置に特定のデータチャンネルを指定し、そしてそ
れを横切って初期設定を実行する。その初期のデータセットで構成されると、各
装置は、全解決策の当該部分の実行を開始する。位置検出及び他のセンサ入力の
ような状態に気付く技術を使用して、各ターゲット装置は、それらの解決スペー
スが交差するか又は重畳するように互いに協力し合う。各装置は、その初期のデ
ータセットを実行するだけでなく、その現在状態（位置、進行等）から学習しそ
して新たなデータセットを発生し、これは、それ自身に適用されるか、又は他の
装置に送信されて実行される。

【００５９】 更に、装置の状態に基づいて、装置は、各装置が互いに協力して学習するのを
助けるやり方で、そのワクチン接種において他の装置から新たなデータセットを
要求する。例えば、自動車工場には、車体にドアを溶接するのに使用される１つ
の装置と、ウインドウを設置するのに使用される別の装置が存在する。溶接装置
は、溶接を完了すると、小さなデータセットをウインドウ設置装置に送信し、従
って、ウインドウの設置をスタートするようにそれに指令する。この点において
、溶接装置は、新たな車体にドアを溶接し始める。

【００６０】 又、自律的分配モデルは、環境モニタ及び制御システムにも適用できる。例え
ば、流れ管理については、各装置は、川に沿った種々のポイントに１組として配
備される廃棄物検出装置である。この例では、上流の装置は、データセットを生
成して下流の装置へ送信するように促すある廃棄物レベルを検出し、新たな廃棄
物の流れがそこを通過するときに実行する必要のある特殊なオペレーションにつ
いて下流の装置を準備させる。例えば、ある形式の廃棄物は、検出が困難であり
、完全に検出するには高精度で且つ複雑な手順を使用しなければならない。上流
の装置は、一般的な検出により適した精度の低い検出方法を使用して廃棄物形式
の僅かな痕跡を検出することができる。廃棄物の痕跡を検出すると、上流の装置
は、廃棄物形式に対してより精度の高い検出方法へ変更するように下流の装置に
指令するデータセットを送信する。

【００６１】 農業においては、自律的分配モデルは、多数の用途を有する。１つの例では、
装置は、ある農作物の品質を検出するのに使用される農耕装置の既存の断片であ
る。検出中に、装置は、その農作物が、畑のあるエリアにおいてもっと水を必要
とするか又はもっと肥料を必要とすることを検出する。この検出が行われると、
装置は、給水及び／又は肥料方法を変更するように別の装置（給水又は肥料補給
に使用される装置）に指令する新たなデータセットをそのエリアに対して生成す
る。新たなデータセットは、生成されると、ターゲット装置に送信される。 又、自律的分配モデルは、小売店販売環境にも適用できる。この場合も、ダン
スするマネキンが本発明のシステムに組み込まれる。マネキンがダンスするとき
に、そのエリアにおけるマネキンからデータ要求を送信し、そしてそれが他のマ
ネキンと良好に同期してダンスするようにそれ自身のメタコマンドセットを変更
することができる。

【００６２】 この自律的分配モデルには、玩具及びゲームも使用できる。玩具は、それらの
アクションを互いに整合することによりグループとして作用させることができる
。例えば、多数のバービー人形が、次々に又はプレイハウスでダンスするように
して互いに対話することができる。 以上の説明から、本発明は、上記とは異なる形態で実施できることが明らかで
あろう。従って、本発明の範囲は、特許請求の範囲によって限定されるものであ
って、好ましい実施形態の前記説明により限定されるものではない。

【００６３】 公開１ＸＭＣウェブ・モデル コミュニティおよびスケジューリング ＲＯＹ−Ｇ−ＢＩＶコーポレーション・コンフィデンシャル 著者： Ｄａｖｅ Ｂｒｏｗｎ 作成日：２０００年２月２２日 保存日：００００年ＸＸＸ月０日 印刷日：２０００年２月２５日 プロジェクト： $/prjcmpnt/xmc/v.100/persdev/doc/_devpers/web_models/webmodels ドキュメント: Ｄｏｃｕｍｅｎｔ２ 記述： 改訂： Software for a spectrum of ideas 著作権２０００ ＲＯＹ−Ｇ−ＢＩＶコーポレーションがすべての権利を有す
る。 ＲＯＹ−Ｇ−ＢＩＶは登録商標であり、Software for a spectrum ideasは、
ＲＯＹ−Ｇ−ＢＩＶコーポレーションの商標である。すべての他のブランドまた
は製品名は、それぞれの所有者の商標または登録商標である。

【００６４】 目 次 １・ 概観 １ ２・ コミュニティ・モデル ２ 個人セッション ２ グループセッション ３ コンテンツ同期 ４ ホストツウデバイス同期 ５ デバイスツウデバイス同期 ６ 同期ハンドシェイキング ７ 実行速度同期 ８ ３・ スケジューリング・モデル ９ ホスト・スケジューリングおよび同報通信 ９ ターゲット・スケジューリング １０

【００６５】 １・概 観 本書は、コンテンツがコンテンツ・プレーヤで実行されるべきスケジュール時
間と同様に、コンテンツを作成し、および使用する時に、ユーザが他人と協力す
ることができるという点で有用である方法で、モーション制御命令、オーディオ
、ビデオ、コンピュータ命令、および他の媒体等、コンテンツを提供するために
用いられるウェブ・モデルを説明する。 本書には三つの主な章があり、コンテンツ・ユーザの一群が、コミュニティと
して協力することができるようにする、ネットワーク化コンテンツ・モデルを、
ユーザが、コンテンツが実行される時をスケジュールすることができるようにす
るネットワーク化コンテンツ・モデルと同様に説明している。本書の章は、以下
のとおりである：第１章−概観 ；本章第２章−コミュニティ・モデル ；いくつかのコンテンツ・ユーザおよび／または
クリエータが、コンテンツの作成または使用において協力することができるよう
にするネットワーク・コミュニティ・モデルを説明する。第３章−スケジューリング・モデル ；ユーザが、いつコンテンツが実行されるか
スケジュールすることができるようにするネットワーク・スケジューリング・モ
デルを説明する。

【００６６】 ２・コミュニティ・モデル コミュニティ・モデルは、一人以上のユーザがコンテンツについて協力し、共
有し、および議論する会議場になるように設計されている。ユーザは、他のユー
ザが使用するため（または他人に販売するため）に作成するコンテンツをアップ
ロードする。他のユーザは、プレーヤが人形、またはコンテンツをランさせるこ
とができる他の電子機器でもよい、他人が自らのローカル・プレーヤでの使用の
ために作成する新しいコンテンツをダウンロードする（または購入する）だけで
もよい。 以下の図は、コミュニティ・モデルを示している。 コミュニティ・モデル このコンテンツ・モデルを使用する場合、コンテンツが、一人の人間によってネ
ットワーク（すなわち、インターネット、ローカル・ネットワーク等）を介して
アップロードされ、およびダウンロードされる、個人としてユーザが働くか、ま
たは前記モデルが、コンテンツをランさせる時に実行される各動作が、グループ
のすべてのメンバの間で同期されるグループによって使用されてもよい。以下の
節は、これらの考えの各々を詳細に説明する。

【００６７】 個人セッション 個人セッションは、実行のためにコンテンツをダウンロードし、および／または
それらが作成するコンテンツをアップロードする単一のユーザを含む。コンテン
ツを実行するために、ユーザは、ディレクトリ・リスト、ウェブ・ブラウザ、ま
たは実行されるべき各コンテンツ・スクリプトまたはコンテンツ・ストリームの
タイトルを表示する他の手段を介して、コンテンツ・リストをブラウズする（br
owse）。 ユーザは、他人と共有したい自らのコンテンツを作成してもよい。作成されると
、ユーザは、自らのコンテンツを、ネットワーク上のコンテンツ・サイトにアッ
プロードする。

【００６８】 グループ・セッション グループ・セッションは、個人セッションで説明されたものと類似のアップロ
ードおよびダウンロード方法に、新たな追加をしたものを使用する。すなわち―
グループにおけるユーザは、リアルタイムで、互いに協力することができる。例
えば、一組のユーザは、同じコンテンツ・スクリプトまたはストリームをランさ
せることを任意で選択してもよい。後述のコンテンツ同期を用いて、各ユーザ・
マシンまたは装置でランするコンテンツは同期され、そして各エンド・ユーザに
、同じ体験をさせる。 注：スケジューリングと結合されると、ユーザの介入を要することなく、一群の
装置が互いに同期を取るかもしれない。後述のスケジューリング・モデルの章で
は、これをより詳細に説明する。

【００６９】 コンテンツ同期 各マシンまたは装置に、同じコンテンツ・スクリプトまたはストリームを実行
させ、および互いに同期の状態を維持させることが有用な場合がある。例えば、
二人のユーザが人形を所有しており、一定のコンテンツ・スクリプトを実行する
ように指示されると、双方の人形が同時に歌い、踊る。各ユーザに、同様の体験
をさせるために、双方のユーザ装置が、ホスト・マシンによって、または互いに
通信することによって、互いに同期を取る。同期を取ると、各装置は同時に同じ
コンテンツをランさせる。双方の人形が、隣り合わせて配置される場合、それら
は同じコンテンツをランさせる時に、同期した方法で踊るであろう。各装置が同
じコンテンツを動作させることは重要ではないが、それらが動作をランする時、
ラン（run）は別の装置と同期する方法でランされる。 ホストツウデバイス同期は、ホスト（簡単にホストの役割を果たすターゲット装
置でもよい）によって動かされる同期モデルであり、ホストはコンテンツを、他
のターゲット装置に同報通信する。同報通信中、コンテンツ・データは、各装置
が、受信されたコンテンツ・データを実行する速度を調整するために使用する同
期パケットを注入される。通常、ホストツウデバイス・モデルは、多くのターゲ
ット装置上でコンテンツ・データのストリームをランさせる時に使用される。

【００７０】 ホストツウデバイス・モデル デバイスツウデバイス同期モデルを使用する時、特定の装置は、他の装置が同期
セッションを開始することを要求する。同期セッション中、双方の装置が、周期
的に、互いに同期パケットを送信し、それに従って、各々が自らの個別実行速度
を変更することができるようにする。通常、デバイスツウデバイス同期は、各装
置が、ホストからダウンロードされたコンテンツ・スクリプトを実行する時に使
用される。

【００７１】 デバイスツウデバイス・モデル

【００７２】 ホストツウデバイス同期 ホストツウデバイス同期を用いる時、ホスト・マシンは、同期パケットを生成
し、それらを、ターゲット・マシンの各々によって実行されているストリームに
注入する。

【００７３】 ホストツウデバイス同期 以下のステップは、ホストツウデバイス同期中に生じる。

【００７４】 ステップ 説明 １ 時間署名、パケット通し番号、または他の参照データを用いて、ホストは周
期的に、各同期パケットを構築する。各同期パケットは、予め定義された間隔で
、コンテンツ・データへと注入される。 ２ すべてのデータが、すべてに同時に、または、次のパケットが送信される前
に、各パケットがすべてのターゲットに送信されるラウンド・ロビン（round ro
bin）・アプローチを用いて、できる限り同時に近い状態で送信される同報通信
方法で、コンテンツ・データが一つ以上のターゲット装置に送信される。 ３ 各パケットを受信すると、ターゲット装置は、同期パケットが受信されるま
で、各パケットをバッファする。同期パケットを受信すると、残りのパケットは
、コンテンツ・プレーヤによって処理され、ムーヴメント、または他のアクショ
ンを生じさせる。 デバイスツウデバイス同期 デバイスツウデバイス同期を用いる時、一つの装置が、同期パケットを他の装
置に送信し、それが、要求している装置と同期して、スクリプトまたはストリー
ムをランさせることを要求する。

【００７５】 デバイスツウデバイス同期 デバイスツウデバイス同期を実行する時、以下のステップが生じる。 ステップ 説明 １ 同期処理を開始するために、装置は、他の装置に、同期セッションを開始す
ることを要求する。前記要求において、本来の装置は、（ランさせるべき）スク
リプトまたはストリーム名および開始時間を送信する。 ２ 同期要求を受信すると、受信装置は、受領メッセージ（ＡＣＫ）で応答する
。 ３ 各装置は、同期要求において特定された、合図を出すべき開始時間を待つ。
４ 前記時刻になると、双方の装置が、自らのコンテンツ・プレーヤに、コンテ
ンツのランを開始するように指示する。 ５ コンテンツをランさせることで、モーションまたは他のアクションを生じさ
せる。 注：デバイスツウデバイス同期は、すべての装置クロックが、少なくとも一回、
外部基準点と同期されたことを前提とする。例えば、すべての装置は、（中央ホ
ストによって）ＧＭＴウェブ・サーバで、または中央ホスト・マシンのクロック
でその内部クロックを更新するよう求められるかもしれない。

【００７６】 同期ハンドシェイキング 以下の目次は、装置Ｂが特定の時間Ｘにおいて、スクリプトＹと同期を取るよ
うに、装置Ａが最初に要求する、同期ハンドシェイキング・セッションの一例を
示す。 装置Ｂは、装置Ａと同期しなくなると、そのコンテンツ・パケットの実行速度を
調整するか、またはデータがモーションを含む場合は、コンテンツ・データをラ
ンさせることによって生じるムーヴ（あれば）の速度を調整しなければならない
。

【００７７】 実行速度同期 実行速度を調整する方法を決定するために使用される一般的アルゴリズムは、以
下の通りである： TimeA = time of sync packet from deviceA TimeB = time of sync packet from deviceB Tdelta = TimeA TimeB If (Tdelta > 0) Increase the Play Rate Else If (Tdelta < 0) Decrease the Play Rate Else Don't change the Play Rate

【００７８】 実行速度を調整するための方法は数多くあり、通常は、選択される方法は、使
用されるコンテンツの種類に依存する。 コンテンツが次元点データ（三次元点の＜Ｘ，Ｙ，Ｚ＞等）を含む場合、新し
い点が、点のセットの中に挿入され、各ムーヴが、少し多く時間がかかるように
し、そして実行速度を遅くする。同じ例において、実行速度を速めることは、点
データをスキップすることによって達成される。 他の例において、コンテンツが、特定の速度でのムーヴを起こすことに従事す
るモーション命令を含む場合、実際の速度は変更されてもよく、前記命令によっ
て指示されたムーヴが、より短い、またはより長い時間で完了するようにする。
例えば、この方法で実行速度を速めるために、ムーヴの速度は少し速められ、そ
れは同様に、より短い時間で、モーション命令が完了するようにする。通常ムー
ヴ命令は、前記ムーヴが、次の命令をランさせる前に前記ムーヴが完了するまで
、命令プロセッサが待つようにする、‘ｗａｉｔ ｆｏｒ ｍｏｖｅ’命令を伴
う。

【００７９】 ３・スケジューリング・モデル スケジューリングは、ホストに、コンテンツの同報通信を開始させ、および／
または装置に、すでにダウンロードされている、あるいは同報通信されているコ
ンテンツのランを開始させるよう指示するための両方に用いられる。ホスト・ス
ケジューリングは、ホスト・マシンが、同報通信セッションを開始する等の特定
のアクションを実行する時間をスケジュールすることに従事する。ターゲット・
スケジューリングは、各ターゲット装置が、特定の、予め決められた時点で、コ
ンテンツのランを開始するようにスケジュールすることに従事する。 ホスト・スケジューリングおよび同報通信 ホスト・スケジューリングで、ホスト・マシンは、予め決められた時点で、特
定のオペレーションを実行するように構成されている。例えば、テレビ・プログ
ラミングのように、ホスト・マシンは、特定の時点において、特定のコンテンツ
・ストリームを同報通信するようにスケジュールするよう、構成されてもよい。

【００８０】 ホスト・スケジューリング・モデル 以下のステップは、ホスト・スケジューリング中に生じる ステップ 説明 １ 特定の、予め決められた時点で、ホストは、ストリーム・データを同報通信
する等、予め決められたアクションの実行を開始する。 ２ 予め決められた時に、ホストは、コンテンツの、ネットワーク（すなわち、
インターネット、または内部ネットワーク）への同報通信を開始する。 ３ 特定の同報通信チャネルに‘合わせる（tune-into）’ように構成されてい
るターゲット装置は、コンテンツを、受信した通りにランさせる。 ホスト・スケジューリングの一例として、ホスト・マシンは、インターリーブ
された（interleaved）モーション／オーディオ・データを含むいくつかのコン
テンツ・ストリームで構成されてもよい。各々の、予め決められた‘スケジュー
ルされた’時間に、ホストは、インターリーブされたモーション／オーディオ・
データを、聴いている装置に同報通信し始める。一例として、聴いている装置は
、踊ると音楽を演奏する、踊るマネキンでもよく、音楽に合わせてマネキンが踊
っているように見せる。

【００８１】 ターゲット・スケジューリング ターゲット・スケジューリングは、特定の、スケジュールされた時間に、ホス
トからのコンテンツを要求し、およびランさせるように（またはすでにダウンロ
ードされたデータ・セットをランさせるように）プログラムされたターゲット装
置を含む。 ターゲット・スケジューリング・モデル 以下のステップは、ターゲットに基づいたスケジューリング中に生じる。 ステップ 説明 １ ターゲット装置は、報じるべき特定の時点を待つようにプログラムされてい
る。 ２ スケジュールされた時間になると、ターゲット装置のスケジューラ（schedu
ler）が起動し、コンテンツ・スクリプトがないか、ネットワークを介してホス
トに照会する。 ３ コンテンツ・スクリプトを受信すると、ターゲット装置は、コンテンツをラ
ンさせ始める。 ４ スケジュールされた時間になると、ターゲット装置のスケジュー ラは、コ
ンテンツ・ストリームもないか、ネットワークを介して、ホストに照会してもよ
い。 ５ コンテンツ・ストリームを受信すると、ターゲット装置は、各命令をランさ
せ始める。 ターゲット・ベース・スケジューリングの一例として、モーション・ベース人
形の所有者はウェブ・サイトに行き、特定のデータでランするための特定のモー
ション・スクリプトまたはストリームを選択する（すなわち、親が、マカレナ（
Macarena）ダンスを選び、それを自分の子供の誕生日に、お祝いとしてランさせ
てもよい）。一度スケジュールされると、子供の誕生日に、前記人形は自動的に
ホスト・ウェブ・サイトに接続し、データをダウンロードし、ダンスをランさせ
始めるであろう。

【００８２】 公開２ＸＭＣ 拡張 モーション・シーケンスのスクリプトおよびフレーミング ＲＯＹ−Ｇ−ＢＩＶコーポレーション・コンフィデンシャル 著者： Ｄａｖｅ Ｂｒｏｗｎ 作成日：１９９９年１０月２６日 保存日：００００年ＸＸＸ月０日 印刷日：１９９９年１０月２７日 プロジェクト： $/prjcmpnt/xmc/v.100/int/persdev/doc/des/script_frames ドキュメント: Ｄｏｃｕｍｅｎｔ２ 記述： 改訂： Software for a spectrum of ideas 著作権１９９９ ＲＯＹ−Ｇ−ＢＩＶコーポレーションがすべての権利を有す
る。 ＲＯＹ−Ｇ−ＢＩＶは登録商標であり、Software for a spectrum ideasは、
ＲＯＹ−Ｇ−ＢＩＶコーポレーションの商標である。すべての他のブランドまた
は製品名は、それぞれの所有者の商標または登録商標である。

【００８３】 目 次 １・概観 １ ２・システム設計 ２ メタ・コマンド ３ モーション・フレーム ４ モーション・スクリプト ４ ３・一般的使用 ５ スクリプトを構築する ５ フレームをランさせる ７ ４・例 ９ データをランさせる １０ １・概観 モーション・コントロールを用いる多くのアプリケーションは、マシンによっ
て実行されるオペレーションを実行するための、いくつかのシーケンスの基本的
なモーション・オペレーションをしばしば使用する。各モーション・シーケンス
の作成は通常、オフラインで作成され、それからそれがランされるマシンへとダ
ウンロードされる。ホスト・マシン（モーション・シーケンスを作成し、および
記憶するために使用される）とターゲット装置（モーション・データのコンシュ
ーマ）との間の接続が断続的であり、または信頼できない時は、このモデルは大
変制約され、ほとんど使用できない。 本書は、各シーケンスの基本的モーション・オペレーションまたはモーション
・スクリプトを、実際にターゲット装置上でランされる前に、そのすべてが送信
されなければならない、小さなフレームのモーション・オペレーションに分割す
る処理を説明する。信頼できない、または断続的なデータ・ラインで、小さなデ
ータ・パケットを送信することは、より大きなデータ・パケットを送信するより
も簡単なので、モーション・オペレーションのスクリプトを、小さなフレームに
分割することは、大変重要である。

【００８４】 ２・システム設計 メタ・スクリプティング・システム（meta scripting system）は、スクリプ
ト、フレーム、およびメタ・コマンドで構成されており、各フレームは、一組の
メタ・コマンドであり、各スクリプトは、一組のモーション・フレームである。 メタ・スクリプティング・システム 以下の部分が、モーション・スクリプトおよびフレーミング・システムを構成
する。 アイテム 説明 メタ・コマンド メタ・コマンドは、ターゲット装置によって実行されるべき単
純なモーション・コントロール・オペレーションを説明する原子スクリプト・エ
レメントである。

【００８５】 モーション・フレーム モーション・フレームは、ＴＲＵＥに設定された ‘Ｆｒａｍｅ Ｅｎｄ’属性を有するメタ・コマンドで終わる一組のメタ・コマ
ンドである。フレームにおける、すべての他の、前のメタ・コマンドは、ＦＡＬ
ＳＥに設定されたこの属性を有しなければならない。 スクリプト設計者は、そのすべてが装置上でうまくランし、その完了時には
、前記装置を安全な状態に置くような方法で、スクリプトを構成する各フレーム
を構築することを推奨される。例えば、他のフレームにある他のモーション・オ
ペレーションの処理を継続する前に、設計者は、すべてのモーションが完了する
のを待つ、Ｗａｉｔオペレーションを伴うムーヴ・オペレーションを含むすべて
のフレームを終了させるであろう。

【００８６】 モーション・スクリプト モーション・スクリプトは、ターゲット装置によって実行される特定のオペ
レーションを定義する一組のモーション・フレームである。スクリプトは、装置
上で、一回に一つのフレームを実行する。 スクリプトを、メタ・コマンドのフレームで構築することが推奨されるのは
、そのようにすることで、設計者が、装置へのスクリプトのダウンロードを、タ
ーゲット装置上での前記スクリプトの実行から切り離すことができるからである
。例えば、ホストが大きなスクリプトをダウンロードしている間、ターゲット装
置は、実際に、全体のスクリプトを受信する前でも、スクリプトにおける最初の
フレームをランさせ始めてもよい。これは、装置が選択してもよいオプションで
あるが、必要とはされない。

【００８７】 メタ・コマンド 各メタ・コマンドは、ターゲット装置でランするスクリプト・エンジンによっ
て実行される基本モーション・オペレーションを説明するのに必要なすべての情
報を含む。スクリプト・エンジンは、多くの様々な形式の実装の一つを使用する
ことを選択してもよい。例えば、ハードウェア独立ＸＭＣモーション・コントロ
ール・システムは、一つの実装として使用されてもよく、またはスクリプト・エ
ンジンが、同様に、各オペレーションに関して、ハードウェア依存実装を使用し
てもよい。メタ・コマンド・データによって、設計者は、モーション・コントロ
ール・オペレーションを記述するデータを、実際の実装から分離することができ
る。

【００８８】 定義 typedef struct XMCMetaCommand ｛ DWORD dwMetaCmdID; LPVARIANT pParamData; DWORD dwParamDataCount; DWORD dwFlags; ｝; ｄｗＭｅｔａＣｍｄＩＤ−メタ・コマンド識別子であり、このメタ・コマン
ドが、ターゲット装置上でランするスクリプト・エンジンと遭遇する時に、ラン
されるべき特定の基本モーション・オペレーション実装に対応する独自の識別子
である。 ｐＰａｒａｍＤａｔａ−各々が、メタ・コマンドをランさせる時に使用され
る単一のパラメータを記述する、ＶＡＲＩＡＮＴ¹構造のアレイである。 ｄｗＰａｒａｍＤａｔａＣｏｕｎｔ−エレメントｐＰａｒａｍＤａｔａアレ
イ内のエレメントの数である。 ｄｗＦｌａｇｓ−メタ・コマンドと、およびそれがどのように処理されるか
を記述する属性フラグのセットである。以下のフラグがサポートされる。

【００８９】 フラグ： 説明 ＸＭＣ＿ＭＦ＿ＦＲＡＭＥＥＮＤ コマンドの現在のフレーム内のメタ・コマン
ドを終了させる。 ¹ ＶＡＲＩＡＮＴ構造に関するさらなる情報は、Ｍｉｃｒｏｓｏｆｔ登録商標
Ｗｉｎ３２登録商標リファレンス・ガイドまたはＭｉｃｒｏｓｏｆｔ登録商標Ｍ
ＳＤＮ登録商標オンライン・ヘルプを参照のこと。 注 メタ・コマンドの完全なセットのうち、いくつかは、デフォルトでＴＲＵＥに
設定された‘Ｆｒａｍｅ Ｅｎｄ’属性で定義される。いくつかのキー・メタ・
コマンドをフレーム・エンド・コマンドになるようにデフォルトすることによっ
て、システム設計者は、スクリプト・エンジンが使用するフレーミング・メカニ
クスの心配をする必要なく、メタ・スクリプトを迅速に構築することができる。
しかしながら、彼らがコマンド・フレーミングに対してより多くの直接コントロ
ールを有する選択をする場合、彼らはあらゆるコマンドの ｄｗＦｌａｇｓフィールドを簡単に変更し、およびそのＸＭＣ＿ＭＦ＿ ＦＲＡＭＥＥＮＤ属性をイネーブル（enable）またはディスエーブル(disable)
することができる。

【００９０】 モーション・フレーム モーション・フレームは、エンド・メタ・コマンド一つのみが、ＴＲＵＥに設
定された‘Ｆｒａｍｅ Ｅｎｄ’属性を有する、一組のメタ・コマンドである−
すべての他のコマンドに関する‘Ｆｒａｍｅ Ｅｎｄ’属性は、ＦＡＬＳＥに設
定される。フレームの主な目的は、ターゲット装置におけるスクリプト・エンジ
ンに、ホスト・マシンと装置との間のデータ・リンクが断続的になるか、または
省略されても、信頼できる方法でランすることができるモーション・オペレーシ
ョンのシーケンスを供給する。ターゲット装置のスクリプト・エンジンは、一度
フレームが全体で受信されるとそれをランさせるにすぎない。

【００９１】 定義 各フレームは、実際には、ＸＭＣメタ・コマンドのアレイ内における、エ
レメントの連続したセットであり、前記セットにおける最後のエレメントは、Ｔ
ＲＵＥに設定された‘Ｆｒａｍｅ Ｅｎｄ’を有する。次のフレームは、前のフ
レームにおける最後のエレメントの直後に開始する。

【００９２】 モーション・スクリプト モーション・スクリプトは、ターゲット装置によってランされるべき基本モー
ション・オペレーションのシーケンスを定義する、一組のメタ・コマンドである
。各スクリプトは、モーションの、一つ以上のフレームから構成される。ターゲ
ット装置にスクリプトを送信する時、データは一回に１フレームを送信される。
前記スクリプト・データを受信すると、ターゲット装置は、完全なフレームの各
々が受信された後にのみ、モーションの各フレームをランさせるだけであろう。 ３・一般的使用 メタ・スクリプティング・システムにおいて、生じるステップは二つある。す
なわち：ａ．）スクリプトを構築する、およびｂ．）スクリプトをランさせるス
テップである。以下の説は、これらの各々について、より詳細に説明する。 スクリプトを構築する スクリプトの構築は、モーション・オペレーションを定義するモーション・シ
ーケンスのスクリプトを構築するために使用可能であるメタ・コマンドのセット
から選択することを含む。以下の図は、この処理の詳細を示す。

【００９３】 スクリプト・データを構築する この処理を構成するステップは、以下の通りである。 ステップ 説明 １ ターゲット装置においてランされるべきモーションのシーケンスを定義する
方法で、各スクリプトを構築するためのスクリプト言語を構成するメタ・コマン
ドの、サポートされたセットから、メタ・コマンドを選択する。 ２ メタ・コマンドに関するパラメータ・データを設定する。 ３ メタ・コマンドによってサポートされる一般的属性を（あれば）設定する。 ４ メタ・コマンドに関して‘Ｆｒａｍｅ Ｅｎｄ’属性を設定する（またはア
ンセット（unset））する。各メタ・コマンドは、その値がコマンドに依存する
この属性に関して、デフォルトで定義されるので、このステップは任意である。

【００９４】 フレームをランさせる ターゲット装置でスクリプト・データをランさせるために、前記データは、最
初に前記装置に転送されなければならず、同様に、各フレームが受信されると、
前記データをランさせる。

【００９５】 スクリプト・データをランさせる スクリプト・データをランさせるときに関わるステップは、以下の通りである
。

【００９６】 ステップ 説明 １ 各フレームは、装置に転送され、この場合、スクリプトにおける第一のフレ
ームが転送される。 ２ スクリプトにおける第二のフレームが転送される。 ３ スクリプトにおける第三のフレームが転送される。 Ａ 一度受信されると、スクリプトにおける第一のフレームがランされる。 Ｂ 一度受信され、第一のフレームがランを完了すると、第二のフレームがラン
される。 Ｃ 一度受信され、第二のフレームがランを完了すると、第三のフレームがラン
される。

【００９７】 ４・例 以下の例において、モーションのシーケンスを含むスクリプトが構築される。 以下のモーション・シーケンスは、加速度と速度を設定し、二つの絶対運動（
absolute move）をつくり、それからすべてのモーション（あれば）を中止する
ために使用される。 以下のステップが、このスクリプトを構築するために利用された。

【００９８】 ステップ 説明 １ メタ・コマンドは、メタ言語から選択され、スクリプトにおける所望の実行
順序で編成される。 ２ すべてのパラメータ・データが、各メタ・コマンドに関して入力される。 ３ すべての一般的属性（あれば）が、各メタ・コマンドに関して設定される。 ４ ‘Ｆｒａｍｅ Ｅｎｄ’属性は、ダウンロード／ラン処理をより効率良くす
るために、いくつかのコマンドに設定される。この例において、‘Ｆｒａｍｅ
Ｅｎｄ’属性はＦＡＬＳＥであるので、この属性は、デフォルト設定のために、
‘ＳｅｔＶｅｌ’および ‘ＳｅｔＡｃｃｅｌ’メタ・コマンドに設定された。装置は、ほとんどのオペレ
ーションを完了する前に、完了するべきモーションを待たなければならないので
、‘Ｗａｉｔ’コマンドは、一方で、 ‘ＴＲＵＥ’のデフォルト設定を有する。

【００９９】 データをランさせる データをランさせる時、ホストは、各モーション・フレームを、最初のもので
始まる装置に送信する。同様に、前記装置は、受信した通りに、各フレームをラ
ンさせる。以下のダウンロード／ラン処理は、モーション・データに合わせる。 a.) Download Frame 1 - ｛ SetAccel ｝ b.) Download Frame 2 - ｛ SetVel ｝ c.) Download Frame 3 - ｛ MoveAbs, Wait ｝ d.) Download Frame 4 - ｛ MoveAbs, Wait ｝ e.) Download Frame 5 - ｛ Stop, Wait ｝ ダウンロード処理中、前記装置は、受信した通りに、各フレームをランさせ始
める。以下の表は、ダウンロードおよびラン・シーケンスが、どのように実際に
重複するかの一例を示す。 フレーム メタ・コマンド ホスト・マシン ターゲット装置 １ ｛ SetAccel ｝ Download Frm 1 Waiting for input ２ ｛ SetVel ｝ Download Frm 2 Run Frm 1 ３ ｛ MoveAbs, Wait ｝ Download Frm 3 Run Frm 2 ４ ｛ MoveAbs, Wait ｝ Download Frm 4 Run Frm 3 ５ ｛ Stop, Wait ｝ Download Frm 5 Pending on Frm 3

【０１００】 公開３ パケット・カウント・ベース・パッキング（Packet Count Based Packing） インターリーブされたデータ・ストリームをカウント・ベース・パッキングで
構築する時、現在のデータ・タイプ（すなわち、モーション、オーディオ、ビデ
オ等）から特定のカウントのパケットが、他のデータ・タイプからのパケットを
追加する前に、ターゲットとなる、インターリーブされたデータ・ストリームに
配置される。新しいデータ・タイプに転換した後、新しいデータ・タイプからの
、特定のカウントのパケットが、データ・ストリームに配置される。オリジナル
・データに特化したデータ・ストリームのいずれにもデータが残らなくなるまで
、各データ・タイプの、特定のカウントのパケットが、ターゲット・データ・ス
トリームへと配置される。

【０１０１】 カウント・ベース・パッキング カウント・ベース・パッキングは、各データ・ソースからの、特定のカウント
のパケットが、ターゲットとなる、インターリーブされたデータ・ストリームに
一緒に分類されることを確証するために使用される。

【０１０２】 コンビネーション・パッキング コンビネーション・パッキングは、各データ・ソースに関する異なるパッキン
グ・アルゴリズムの使用である。例えば、モーション・データ・ソースからデー
タをロードする時、サイズ・ベース・パッキング（size-based-packing）が用い
られてもよく、オーディオまたはビデオ・データ・ソースからデータをロードす
る時は、タイム・ベース・パッキング（time-based packing）が使用されてもよ
い。様々な方法の混合は任意であり、より良くデータを同期させるのを支援する
ために供給される。

【０１０３】 目 次 １・ 概観 １ ２・ インターリービング・モデル ２ パッキング方法 ３ タイム・ベース・パッキング ３ パケット・サイズ・ベース・パッキング ４ パケット・カウント・ベース・パッキング ５ コンビネーション・パッキング ６ １・概観 本書は、モーション・データを、オーディオやビデオ等の他の種類の媒体と混
ぜるために使用される、インターリービングの一般的モデルおよびアルゴリズム
を説明する。前記データを混合する目的は、モーション命令に、他の媒体と同期
を取って実行させることである。例えば、モーション命令は、ある対象物に、特
定の音楽や歌に合わせて動くように命令してもよく、前記対象物が演奏されてい
る音楽に合わせて踊っているように見せる。 本書は、以下の章で構成されている： 第１章 − 概観；本章 第２章 − インターリービング・モデル；ターゲット・データ・ストリーム
を構築するために、インターリービングがどのように働き、パッキング方法が使
用されるかを説明する。 第３章 − 一般的アルゴリズム；様々なパッキングおよびアンパッキング・
アルゴリズムを説明する。 ２・インターリービング・モデル インターリービングは、二つの異なるデータ・タイプからの二つのデータ・ソ
ースを、ターゲット・プレーヤに転送される単一のデータ・ストリームへと併合
する処理である。ターゲット・プレーヤは、同様にデータが受信されると、各デ
ータ・セットを同時に実行する。 インターリービングは、二つのデータ・タイプが、実行される時に、最終結果
（すなわち、音楽およびモーション駆動ムーヴメント）が互いに同期を取るよう
に、それらを同期させるように設計された技術である。例えば、インターリービ
ングによって音楽データとモーション命令は、ロボット装置で実行される時に、
前記装置が音楽に合わせて踊るような方法で混合される。

【０１０４】 一般的インターリービング・モデル 以下のステップは、インターリービング処理中に生じる。 ステップ 説明 １ 処理は、併合されるべき二つのデータ・ソースで開始する。 ２ 次に、ストリーム・パッカ（Stream Packer）は、各ストリームからのデー
タの選択を交互にするためのパッキング・アルゴリズムを用いて、各データ・ソ
ースを取り、各々を、インターリーブされたデータ・ストリームにパックする。 ３ 使用される時、各データ・パケットを抽出し、各々を適切なデータ・プレー
ヤ（または単一のプレーヤ装置における適切なデータ・プレーヤ・モジュール）
へと渡すために使用されるストリーム・アンパッカ（Stream Unpacker）を用い
て、インターリーブされたデータ・ストリームは、アンパックされる。前記デー
タは、データ・パケット・タイプに基づいて、各プレーヤに渡される。例えば、
モーション・データは、モーション・プレーヤに渡される一方で、オーディオお
よび／またはビデオ・データは、それぞれオーディオおよびビデオ・プレーヤに
渡される。 ４ 前記データは同時に実行され、次に最終結果を同期させる。例えば、オーデ
ィオ・データを実行するのと同時にモーション・データを実行することで、モー
ションは、オーディオ音と同期を取る。

【０１０５】 パッキング方法 パッキング方法は、ストリーム・パッカによって使用され、モーション媒体が
、オーディオまたはビデオ・データ等、他の媒体タイプとどのように混合される
かを決める。パッキング処理中に、データを混合するために使用される、４つの
主な方法がある。 タイム・ベース・パッキング（Time Based Packing） タイム・ベース・パッキングは、予め特定されたタイム・クオンタム（time q
uantum）に基づいて、各データ・ストリームからデータを選択する処理である。
異なるタイム・クオンタムが、各データ・ストリームと使用されてもよい。

【０１０６】 タイム・ベース・パッキング パケットを選択するデータ・ソースを選択する時、タイム・クオンタムは、前
記データ・ソースと関連する、予め特定された値にリセットされる。パケットは
、タイム・クオンタムが終わるまで、データ・ソースから引かれる。

【０１０７】 パケット・サイズ・ベース・パッキング（Packet Size Based Packing） サイズ・ベース・パッキングは、特定のバイト数が、データ・ソースからター
ゲットとなる、インターリーブされたデータ・ストリームにパックされるまで、
パケットがデータ・ソースから選択される、パケット選択方法である。特定のサ
イズに到達するか、またはそれを超えると、パケットは、他のデータ・ソースか
ら選択される。

【０１０８】 サイズ・ベース・パッキング サイズ・ベース・パッキングは、各データ・ソースからのパケットの各セット
が、少なくとも、予め特定されたサイズであるデータ・サイズを有するパケット
のグループとして、ターゲット・ストリームにパックされることを確証するため
に、使用される。

【０１０９】 公開４ モーション・ネットワーク・モデル ＸＭＣモーション・ネットワーク・モデル ＲＯＹ−Ｇ−ＢＩＶコーポレーション・コンフィデンシャル 著者： Ｄａｖｅ Ｂｒｏｗｎ 作成日：１９９９年１０月３１日 保存日：００００年ＸＸＸ月０日 印刷日：１９９９年１１月１日 プロジェクト： $/prjcmpnt/xmc/v.100/persdev/doc/_devpers/xmcmeta/des/network_models ドキュメント: Ｄｏｃｕｍｅｎｔ２ 記述： 改訂： Software for a spectrum of ideas 著作権１９９９ ＲＯＹ−Ｇ−ＢＩＶコーポレーションがすべての権利を有す
る。 ＲＯＹ−Ｇ−ＢＩＶは登録商標であり、Software for a spectrum ideasは、
ＲＯＹ−Ｇ−ＢＩＶコーポレーションの商標である。すべての他のブランドまた
は製品名は、それぞれの所有者の商標または登録商標である。

【０１１０】 目 次 １・ 概要 １ ２・ 基本モデル ２ 各アイテムの責任 ２ データ・チャネル ３ ３・ ネットワーク・モデル ４ 同報通信 ４ 要求ブローカリング ５ 自律分散 ６

【０１１１】 １・ 概観 スクリプティングならびにフレーミングおよびライブ更新およびストリーミン
グ技術を使用する時、ホスト・マシンとターゲット装置との関係は、多くの形式
を取るかもしれない。本書は、これらの関係のいくつかを、およびそれらがどの
ように、エンド・ユーザによって使用されてもよいかを詳細に説明する。 一般的な関係は、ホスト・マシンが、ある種のデータ・リンクによってターゲ
ット装置に接続されるそれである。ホストがデータを作成し、記憶することに責
任を有する場合、ターゲット装置は、データ・リンクを介してホストによってそ
れに送信されるデータを消費することに責任を有する。 この編成で、３つの主なモデルがある： ・同報通信 − このモデルは、データを送出し、いくつかの装置がデータを
選択し、それを実行できるようにするホスト・マシンとして定義される。ラジオ
局が、無線信号を多くのラジオ装置に放送するのとまったく同じ方法で、前記デ
ータは送出される。 ・要求ブローカリング − このモデルは、前記装置がデータ要求をした後に
、データが各装置にのみ送信される同報通信モデルを反転させる。ホスト・マシ
ンは、要求されるとデータを装置に送信するのみであるという点で、データ・ブ
ローカ（data broker）として振舞う。 ・自律分散 − このモデルは、各装置が、ホスト・マシンとターゲット装置
の両方の役目を果たすという点で、同報通信および要求ブローカリング・モデル
の両方の混合である。このモデルにおいて、各装置は、各々からのブローカ・デ
ータ要求と同様に、すべての他の装置にデータを同報通信することができる。各
装置が、実行のために合わせられている（tuned-in）ことを要求するか、または
同報通信する、データ・セットを実行するという点で、各装置はデータ・コンシ
ューマの役割も果たす。 本書は、基本モデルとともに、これらのモデルの各々を説明する。本書は、以
下の章から構成される。 第１章 − 概観；本章である。 第２章 − 基本モデル；ホスト・マシン、データ・リンクおよびターゲット装
置の間の一般的関係を説明する。 第３章 − ネットワーク・モデル；基本モデルの、いくつかの異なる使用を説
明する。

【０１１２】 ２・ 基本モデル 基本モデルは、ターゲット装置に接続されたホスト・マシンを含み、ここでは
、ホストが、データ・セットを作成し、ならびに記憶することに責任を有し、デ
ータ・リンクが、前記データをターゲット装置に転送することに責任を有し、お
よびターゲット装置が、実行することによってデータを消費することに責任を有
する。基本モデルは、エンド・ユーザに各々を構築させるために、ホストおよび
／またはターゲット・サイドに、任意でユーザ・インターフェースを有してもよ
い。 基本モデル 上記の画が、ホストとターゲットの両方を、個別の物理的マシンとして示して
いるが、単一の装置が、両方の機能のセットを供給することが完全に可能である
ことに、注目すべきである。この配列は、本書において、後に説明されるネット
ワーク・モデルの一つにおいて使用される。

【０１１３】 各アイテムの責任 基本モデルを構成するアイテムの各々は、以下のように説明される： ・ホスト・マシン−ホスト・マシンは、ライブ更新またはストリーム形式のいず
れかで、各データ・セットを作成し、および記憶する。データ・セットは、スク
リプトおよびフレーム形式で、またはターゲット装置が実行するための予定され
たオペレーションを説明するメタ・コマンドのシーケンスとして編成することが
できる。この技術の焦点は、モーション・コントロール・オペレーションのシー
ケンスのそれに置かれているが、前記オペレーションは、以下のように、ターゲ
ット装置を制御するために使用されるあらゆるオペレーションを説明してもよい
： ‐前記装置で、デジタルまたはアナログＩＯラインを制御し、および／また
は照会する。 ‐ビデオ・カメラ、デジタル・スチル・カメラ、または他のビジョン・ベー
ス・センサを制御し、および／または照会する。 ‐加速度計、熱電対、圧力変換器等、センサの大きなアレイのいずれかを制
御し、および／または照会する。 ‐内部論理シーケンス（ソフト・ロジック等）または前記装置でランする他
のアルゴリズムを制御し、および／または照会する。 ‐モーション・コントロール・オペレーションを制御し、および／または照
会する。 ・データ・リンク−データ・リンクは、それを介してデータがホスト・マシンか
らターゲット装置に送信される媒体である。データ・リンクは、以下のような、
多くの異なる形式でもよい： ‐Ｅｔｈｅｒｎｅｔベースのネットワーク・リンク（または ＴｏｋｅｎＲｉｎｇ等の、他の物理的ワイヤ・ベースのネットワーク）。 ‐ワイヤレス・リンク（赤外線、広帯域幅ワイヤレスまたは衛星）。 ‐物理的バックプレーン（ＩＳＡまたはＰＣＩバス）。ホストおよびターゲ
ット装置が、単一のマシンとして実装されている場合、バックプレーンは、各々
によって実装される論理の間のデータ・リンクとして振舞う。 ・ターゲット装置−ターゲット装置は、データのコンシューマ（consumer）であ
る。データを消費するために、ターゲット装置は、データ・セットを構成する各
メタ・コマンドと関連する論理マシン命令のセットを実行する。

【０１１４】 データ・チャネル 各データ・リンクは、その全体がチャネルと呼ばれ、またはいくつかのチャネ
ルに分割されることができる。データ・リンクをチャネルに分割するために、デ
ータの各パケットは、データ・リンクを介して送信される前に、そのチャネル番
号で印付けされる。受信されると、ターゲット装置は、現在聴いているデータ・
チャネルに、データ・アイテムが実際に存在するかどうかを認識することができ
る。データ・リンク全体が単一のチャネルと呼ばれる場合、各データ・パケット
の印付けは必要ない。 データの各パケットは、データ・チャネル番号またはパケットの通し番号等、
追加のパケット属性を伴う、一組の、メタ・コマンドの一つ以上のフレームであ
る。

【０１１５】 ３・ネットワーク・モデル いくつかの、基本モデルの重要な使用、すなわち：同報通信、要求ブローカリ
ング、および自律分配がある。以下の節は、これらの各々を詳細に説明する。 同報通信 同報通信は、ホスト・マシンが、一つまたは多くのデータ・リンクを介して、
データ・セットを、一つの、または多くの異なる装置に同時に送信する、基本モ
デルの変形である。ホスト・マシンは、装置がデータ・セットを聴いている（li
stening ）ことにさえ気づかないかもしれないが、これは、同報通信モデルにお
いては求められない。このモデルでは、前記リンクの他の端に誰がいるか気にす
ることなく、ホスト・マシンは主に、データ・セットを、データ・リンクを介し
て、送出することに関心がある。

【０１１６】 同放送信ネットワーク・モデル データ・リンクの反対側では、ターゲット装置が、聴こうとして合わせている
（tuned）データを受信する。例えば、各装置は、データの単一のチャネル（す
なわち、データ・リンクの特定の部分、または一組のデータ・リンクから選択さ
れた特定のデータ・リンクのみさえ）を聴くために、合わせられてもよい。デー
タ・チャネルを聴く時、前記装置はそれから、データ・セットにおける各メタ・
コマンドと関連したすべてのマシン・ロジックをランさせることによって受信さ
れたすべてのデータを実行する。

【０１１７】 要求ブローカリング 要求ブローカ・モデルにおいて、一つ以上のターゲット装置は、ホスト・マシ
ンからデータ更新を要求する。各要求は、同時に、または異なる時に生じてもよ
い。ホスト・マシンは、データ・セットまたはデータ・チャネルへの接続に対す
る要求を受信するまで、アイドル状態で待つ。一度要求されると、ホスト・マシ
ンは、データ・セットおよび／またはデータ・チャネルを、要求している装置と
結びつけ、およびデータ・リンクを介してデータを送信し始める。

【０１１８】 要求ブローカリング・ネットワーク・モデル 要求されたデータを受信すると、ターゲット装置は、各々と結びついた論理マ
シン命令を実行することによって、データ内の各メタ・コマンドをランさせる。

【０１１９】 自律分散 自律分散は、各ターゲット装置が、内部的に、ホスト・マシンとターゲット装
置の両方の役割を果たす点で、同報通信と要求ブローカ・モデルの混合である。
ホスト・マシンとして、各装置がデータ・セットを作成し、記憶し、他の装置に
送信し、およびターゲット装置として、自らのデータ・セットを、または他の装
置から受信された他のデータ・セットを消費する。

【０１２０】 自律分散 このモデルで、ターゲット装置は、一つのコミュニティとして一緒に動作し、
困難なタスクを乗り越えるために分割し、および克服するために使用されること
ができる。

【０１２１】 公開５データ更新 ＸＭＣモーション・ライブ更新、更新要求およびストリーミング ＲＯＹ−Ｇ−ＢＩＶコーポレーション・コンフィデンシャル 著者： Ｄａｖｅ Ｂｒｏｗｎ 作成日：１９９９年１０月２８日 保存日：００００年ＸＸＸ月０日 印刷日：１９９９年１０月３０日 プロジェクト： $/prjcmpnt/xmc/v.100/int/persdev/doc/_devpers/xmcmeta/ dataupdate ドキュメント: Ｄｏｃｕｍｅｎｔ２ 記述： 改訂： Software for a spectrum of ideas 著作権１９９９ ＲＯＹ−Ｇ−ＢＩＶコーポレーションがすべての権利を有す
る。 ＲＯＹ−Ｇ−ＢＩＶは登録商標であり、Software for a spectrum ideasは、
ＲＯＹ−Ｇ−ＢＩＶコーポレーションの商標である。すべての他のブランドまた
は製品名は、それぞれの所有者の商標または登録商標である。

【０１２２】 目次 １・ 概観 １ ２・ データ更新モデル ２ ライブ更新 ２ ストリーミング ４ ３・ データ更新を開始する ６ プッシュ更新 ６ プル更新 ８

【０１２３】 １・概観 データ更新は、データ・セットを作成し、および記憶するために使用されるマ
シンからのデータ・セットを、前記データを消費するために使用されるターゲッ
ト装置に転送する処理である。本書は、これらのデータ転送をする時に生じる処
理、あるいはライブ更新（live update）として知られるものを詳細に説明する
。

【０１２４】 ホスト・マシンとターゲット装置の両方が、あらゆる双方向システムにおいて
、構成部分的役割を果たす。双方向システムにおいて、ホストは、後にターゲッ
ト装置でランされるデータ・セットを作成し、および記憶するマシン（または装
置）として定義される。ターゲット装置（実際には、同じホスト・マシンまたは
個別の独立したマシンまたは装置でもよい）は、データ・セットのコンシューマ
である。前記データを消費し、または実行することは、（外部か、または内部で
）イベントを生じさせるための、データ・セットを構成する命令またはメタ・コ
ードを実行する処理である。 例えば、ホスト・マシンは、特定のターゲット装置の所望の振る舞いを定義す
るスクリプトを構成するモーション・メタ・コマンドのフレームを生成するため
に使用されてもよい。受信されると、ターゲット装置は、各々と関連するアクシ
ョンを実行する（またはランする）ことによって、モーション・メタ・コマンド
の各フレームを実行し、モーション・アクションが起こるようにする。この例に
おいて、一つのマシンが、ホストと装置の両方のアクティビティを実行すること
ができ、または個別のマシンに置かれ、データ・リンク（すなわち、テサード・
ライン（tethered line）、ネットワーク接続、ワイヤレス接続、インターネッ
ト等）によって接続することができる 本書は、以下の章で構成されている： ・第１章‐概観；本章。 ・第２章‐データ更新モデル；データ更新を実行するために使用される様々なデ
ータ更新モデルを説明する。 ・第３章‐データ更新を開始する；データ更新セッションを開始する様々な方法
を説明する。

【０１２５】 ２・データ更新モデル ホストからターゲット装置にデータを転送するため、および以下のもの、すなわ
ち：‘ライブ更新’データをスケジュールし、要求し、およびストリーミングす
ることに従事するために用いられる一般的ライブ更新モデルの三つの変形がある
。以下の節は、一般的ライブ更新モデル、およびそれの、これら三つの変形の各
々を詳細に説明する。転送されるデータは：モーション・データのみ（前記デー
タは、基本モーション・コントロール・オペレーションのシーケンスである）、
モーションおよび音楽データの混合（前記モーション・データは、音楽データに
合わせて振り付けてもよい）、またはモーション、音楽、およびビデオ・データ
が結合されたものを含む、多くの形式を取ることができる。

【０１２６】 ライブ更新 ライブ更新は、ホスト（データを作成し、および記憶するために使用される場所
）から、ターゲット（前記データを実行するために使用されるマシン）へとデー
タを転送する処理である。ホストおよびターゲット両方のオペレーショのための
場所は、同じマシンにあってもよく、または、後述のように個別のマシンにあっ
てもよい。

【０１２７】 ライブ更新処理 以下のステップは、ライブ更新処理中に生じる。

【０１２８】 ステップ 説明 １ ライブ更新処理における第一のステップは、ターゲット装置に転送されるべ
きスクリプトのライブラリから選択するホスト・マシンのそれである。 ２ 一度選択されると、モーションの各フレームは順番に配列される（一つのフ
レームは、基本モーション・オペレーションを説明する、一組のモーション・メ
タ・コマンドとして定義され、最後のモーション・メタ・コマンドは、‘フレー
ム・エンド’属性として印付けされる）。詳細な説明は、‘スクリプティングお
よびフレーミング’設計文書を参照のこと。推奨はされないが、モーション・デ
ータの各スクリプトを、一回に１メタ・コマンドを、ターゲット装置にも送信す
ることも可能である。そのようにすることは、ホスト・マシンとターゲット装置
を接続するデータ・リンクが省略される場合、ターゲット装置を予測できない状
態にするかもしれないので、これは推奨されない。 ３ ターゲット装置は、スクリプトを構成するすべてのフレームが受信されるま
で、受信された各フレームを、一時的な場所に記憶する。 ４ スクリプト全体が一度受信されると、それは実行の準備ができていることを
示す準備キュー（ready queue）に記憶される。 ５ スクリプトがターゲット・スクリプトになると（すなわち、前記装置のスク
リプト選択ロジックが、タイム・クオンタム、プログラムされたロジック、また
は各スクリプトの基本的な順番を介してスクリプトを選択すると）、前記装置は
、スクリプトの実行を開始する。 ６ スクリプトを実行するために、ターゲット装置は、スクリプトによって定義
された順序で、各メタ・コマンドを実行する。この点において、フレームは使用
されない。メタ・コマンドの実行は、各メタ・コマンドに関連するモーション・
ロジックをランさせる処理である。

【０１２９】 ストリーミング ストリーミングは、前節で説明されたライブ更新処理を継続的に通過する処理
である。データのスクリプトを送信する代わりに、データ・セットは、連続した
歌のように実行し、モーションのフレームは継続的にターゲット装置に送信され
、同様に、受信された各フレームを記憶し、および受信された順番に各々をラン
させる。

【０１３０】 ストリーミング 以下のステップは、ライブ更新処理中に生じる。

【０１３１】 ステップ 説明 １ ストリーミングする時、ホスト・マシンは、大きなセットのフレームの各フ
レーム（または、ホスト・マシンによって継続的に作成され、または生成される
一組のフレーム）を、送信キューに送信する。 ２ 次に、各フレーム（ターゲット装置によって１セットとしてランされるのみ
である一つ以上のメタ・コマンドで構成されている）がターゲット装置に送信さ
れる。 ３ 各フレームを受信すると、ターゲット装置はそれらを受信キューに加える。
受信されたフレームは、順番でなく受信されることが可能であることが注目され
る。そのような場合、フレームは、ホスト・マシンによって送信された本来のシ
ーケンスを維持する方法で、受信キューへと挿入される。順序付け（sequencing
）は、基礎になるネットワーク・プロトコルによって頻繁に実行されるが、ホス
トおよびターゲット装置は自らの順序付けメカニズムを実行してもよいので、こ
れは必要とはされない。 ４ 継続する前に、データの完全なスクリプトが受信されるまで待つ同様の更新
方法とは異なり、各フレームは、実行の準備をしているターゲット装置出力キュ
ーに即座に渡される。 ５ 出力キューにある各メタ・コマンドは、各コマンドと関連するモーション・
ロジックをランさせることによって実行される。

【０１３２】 プル更新（Pull Update） プル更新は、ライブ更新モデルの変形であり、ホストの代わりに、ターゲット
が、ライブ更新処理を開始する。予め決められたイベント（またはイベントのセ
ット）に遭遇した後、前記装置は、ホスト・マシンからライブ更新を要求する。
前記通知を受信すると、ホスト・マシンは、要求されたデータをターゲット装置
に戻すために、更新処理を通過する。 プル更新 以下のステップは、ライブ更新処理中に生じる。

【０１３３】 ステップ 説明 １ プッシュ更新とは異なり、ターゲット装置は、外部イベントが生じるか、特
定の時間増分が経過するか、または内部論理アルゴリズムが指示した後、プルデ
ータ更新を開始する。 ２ データ更新トリガ・イベントが発生すると、ターゲット装置は、更新処理を
開始するために、データ更新要求を、ホスト・マシンに発する。 ３ データ更新要求を受信すると、ホスト・マシンは、ライブ更新のため、また
はデータ・ストリーミング・データ転送（data streaming data transfer）のた
めに、前記データを準備し始める。 ４ 準備できると、モーション・メタ・コマンドのフレームは、データ・リンク
接続を介して、ターゲット装置に転送される。 ５ 受信されると、前記装置は、プッシュ・データ更新でするのとまったく同じ
方法で、前記データを処理する。 ６ 受信されたデータは、データのフレームを構成する各メタ・コマンドを実行
することによって、ライブ更新か、またはストリームとしてランされる。メタ・
コマンドを実行することは、各メタ・コマンドと関連するモーション・ロジック
をランさせることを含み、それはターゲット・ハードウェアを操作し、監視し、
および／または制御する。

【図面の簡単な説明】

【図１】 本発明の原理により構成された例示的制御ソフトウェアシステムのシステムイ
ンターアクションマップである。

【図２】 図１の制御ソフトウェアシステムがクライアントといかに通信できるかを示す
ブロック図である。

【図３】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

【図４】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

【図５】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

【図６】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

【図７】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

【図８】 運動制御システムのモジュールが種々の筋書きのもとでいかに相互作用するか
を示すモジュールインターアクションマップである。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ６０／１６２，８０２ (32)優先日 平成11年11月１日(1999．11．1) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ６０／１６２，８０１ (32)優先日 平成11年11月１日(1999．11．1) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ６０／１８２，８６４ (32)優先日 平成12年２月16日(2000．2．16) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ６０／１８５，１９２ (32)優先日 平成12年２月25日(2000．2．25) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ， ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ， ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5H220 BB12 BB18 CC07 CX01 CX05 DD01 EE10 HH01 HH09 JJ12 KK10

Claims (5)

【特許請求の範囲】
1. 【請求項１】 分散型ネットワークを経て運動データを通信するための方法
   において、 制御ソフトウェアシステム、コンテンツサーバー及びクライアントブラウザを
   ネットワークに接続し、 上記コンテンツサーバーにおいて運動プログラムを生成し、 上記運動プログラムを上記コンテンツサーバーから制御ソフトウェアシステム
   へ転送し、 上記運動プログラムに基づいて制御ソフトウェアシステムにおいて運動媒体を
   発生し、そして 上記運動媒体をクライアントブラウザへ送信して、クライアントブラウザに関
   連したターゲット装置を上記運動媒体に基づいて動作する、 という段階を含む方法。
2. 【請求項２】 上記コンテンツサーバーにおいて非運動データを生成し、 上記非運動データを制御ソフトウェアシステムにおいて運動媒体と合成して、
   エンハンスト運動媒体を得、そして 上記エンハンスト運動媒体をクライアントブラウザに送信する、 という段階を更に含む請求項１に記載の方法。
3. 【請求項３】 上記クライアントブラウザに関連したレーティングルールを
   記憶し、そして 上記レーティングルールに基づいてどのターゲット装置が動作するかに基づき
   運動媒体を変更する、 という段階を更に含む請求項１に記載の方法。
4. 【請求項４】 上記運動プログラムは、ターゲット装置とは独立しており、
   そして運動媒体を発生する上記段階は、運動プログラムを、ターゲット装置に関
   連した形式の運動媒体に変換する段階を更に含む請求項１に記載の方法。
5. 【請求項５】 上記運動プログラムは、ターゲット装置に関連した形式のも
   のである請求項１に記載の方法。