(57)【特許請求の範囲】
【請求項１】
デバイスの群から選択された複数のデバイスを使用して機械を構成する方法であって、前記群内の各デバイスが、短距離無線通信能力を有し、
ユーザからの指示に応答して、能力要件および実行時論理のコーディングを含むアプリケーション・テンプレートを始動するステップと、
前記機械に必要な能力を決定するために前記テンプレートを分析するステップと、
前記能力の１つまたは複数を有するデバイスについて前記群内を検索するステップと、
所定の基準に従って候補デバイスをフィルタリングするステップと、
前記フィルタリングされたデバイスを前記機械に統合するステップと
を含むことを特徴とする方法。
【請求項２】
前記テンプレートが、デバイスでのそれぞれが必要な能力を有する１つまたは複数の構成要素を用いて形成される前記機械を定義し、前記統合するステップが、
リンクされたデバイスを使用して前記構成要素のそれぞれを構築するために、前記必要な能力の少なくとも１つを有する、前記群からのデバイスをリンクするステップと、
前記構成要素を前記機械に統合するステップと
を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記テンプレート・アプリケーション用のプール処理を実行することができるプール処理デバイスが前記群内に存在するかどうかを判定するステップ
をさらに含むことを特徴とする、請求項１に記載の方法。
【請求項４】
プール処理デバイスが前記群内に存在すると判定される時に、前記プール処理デバイスが、前記検索するステップおよびデバイス管理を実行することを特徴とする、請求項３に記載の方法。
【請求項５】
プール処理デバイスが前記群内に存在しないと判定される時に、前記検索するステップが、
前記群に照会メッセージをブロードキャストするステップと、
前記群内の各デバイスが、そのデバイスの情報を用いて前記照会メッセージに応答することを可能にするステップと
を含むことを特徴とする、請求項３に記載の方法。
【請求項６】
前記デバイスの情報が、前記群内のすべてのデバイスに共通する１つまたは複数の言語で、可読フォーマットで記述された、前記デバイスの詳細なプロファイルを含むことを特徴とする、請求項５に記載の方法。
【請求項７】
前記デバイスの情報に基づいて、前記機械を構築するのに使用されるデバイスを選択するステップ
をさらに含むことを特徴とする、請求項５に記載の方法。
【請求項８】
短距離無線通信能力を有するデバイスの群から選択された複数のデバイスを使用して機械を構成するためのプログラムであって、コンピュータに、
ユーザからの指示に応答して、能力要件および実行時論理のコーディングを含むアプリケーション・テンプレートを始動するステップと、
前記機械に必要な能力を決定するために前記テンプレートを分析するステップと、
前記能力の１つまたは複数を有するデバイスについて前記群内を検索するステップと、
所定の基準に従って候補デバイスをフィルタリングするステップと、
前記フィルタリングされたデバイスを前記機械に統合するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、効率的な無線装置のアクセスおよび管理を実施するための、デバイスの能力を統合することによってダイナミック・マシン（ＤＭ）を構成する方法に関する。
【０００２】
【従来の技術】
さまざまなアプリケーションおよびサービスによって、パーベイシブ・デバイスへの要求がますます増え、単一の機器を用いて異なる問題を解決することは不可能であるのだが、さまざまな機器を使用することが必要になる。しかし、異なる機器は、異なるアクセス手法および管理手法を必要とし、したがって、それらをうまく使えるようになる前に、それらを操作する方法を習得しなければならない。リモート・コントロールおよび音声コマンドなど、すでに十分に受け入れられた一貫性があり自然なアクセスおよび管理の手法があるが、これらは、ある種の機器でのみ使用することができる。
【０００３】
ＡＴＭまたはコピー器など、広範囲の機能および能力を実行するための複数のコンポーネント即ち構成要素からなる強力な機械が知られている。しかし、これらの構成要素は、通常は、取り外し、他の機械または他の目的に再利用することができない。たとえば、自動車のサウンド・システムは、家庭内では絶対に機能しない可能性があり、ＡＴＭプリンタは、ＰＤＡのメモのコピーを印刷しない。問題は、機械が特定の応用例のみのために最適化されていることと、機械およびその構成要素が他の機能の実行に適切でないことである。新しい応用分野が現れ、古い機械が役に立たない時には、必ず、新しい機械を設計し、製造しなければならず、古い機械は、おそらくはすべての構成要素と共に捨てられるが、これは資源の浪費でしかない。
【０００４】
【発明が解決しようとする課題】
したがって、本発明の主目的は、一貫性があり自然なアクセスおよび管理の方法をすべての可能な無線対応デバイスから使用可能にする方法を提供することである。
【０００５】
本発明のもう１つの目的は、元々は実際の機械のみによって処理された複雑な作業を実行することができるダイナミック・マシンを形成するために、さまざまなパーベイシブ・デバイスの能力を動的に統合できる方法を設計することである。
【０００６】
【課題を解決するための手段】
この２つの目標に到達するために、本発明者は、ダイナミック・マシン合成（ＤＭＳ）スタックが動作するためにデバイス上である基本的な要件だけを有するアーキテクチャおよびオペレーティング・プラットフォームを設計した。
【０００７】
本発明では、単純なデバイスを、ＤＭＳによってダイナミック・マシン（ＤＭ）に統合して、統合されたアクセスおよび管理方法をユーザに提供することができ、これによって、真の柔軟性および便宜がもたらされる。したがって、複雑なアプリケーション要件またはサービス要件を、単純なデバイスの組を用いて満足することができる。デバイス自体は、もはや、個々のデバイスとしてではなく、ＤＭの構成要素として扱われる。
【０００８】
本発明のＤＭＳは、複雑な問題を解決する新しい手法も提供する。新しい実際の機械を設計、製造するのではなくダイナミック・マシンを使用することによって、ほとんどコストなしで、必要な時にＤＭを構築し、もはや不要になった時に分解することができる。
【０００９】
Bluetoothは、音声とデータの両方の短距離無線ＲＦ通信の使用に関する技術および仕様である。Bluetoothは、さまざまなデバイスを接続する便利でコスト効率のよい形をもたらす。本明細書に記載の無線デバイスは、少なくとも１つの短距離ＲＦモジュールを有するデバイスを指す。長距離ＲＦモジュールは、ＤＭＳでは採用されない。というのは、機械と呼ぶことができるどのようなものであっても、短距離通信によってカバーすることができる適度なサイズを有すると思われるからである。あるデバイスが、長距離内部通信を実行しなければならない場合には、そのデバイスは、通常は、１つの機械とみなされない。既に複数の短距離無線プロトコルが使用可能であり、Bluetoothは、ＤＭＳ実施形態に好ましい選択である。
【００１０】
本発明のさらなる長所には、下記が含まれる。
１）統合されたデバイスのアクセスおよび管理の方法が提供される。
２）複数のデバイスが一緒に同時に働くことを必要とする複雑な作業を実行する時に、ユーザの構成および操作が単純になる。
３）複雑な作業を単純なデバイスで処理することができる。
４）最適化された形のリソース分配がもたらされる。
【００１１】
【発明の実施の形態】
基本概念
本発明の基本的な発想は、統合された無線デバイスのアクセスおよび管理のためにダイナミック・マシンを統合する方法を設計することである。この方法では、短距離無線通信技術を使用して、さまざまなデバイスを接続し、デバイスの機能を統合して、真の便宜および柔軟性をエンド・ユーザに提供できるＤＭを構成する。
【００１２】
まず、いくつかの基本概念の定義を、下記のように行う必要がある。
１．デバイス：比較的単純な構造および機能を有する機器、たとえばランプを指す。ＰＤＡは、複数の構成要素にもかかわらず、小さくコンパクトであり、限られた機能を提供するので、デバイスとも見なされる。
２．機械（マシン）：複雑な機能を実行することができる、複数の構成要素からなる機器を指す。たとえば、自動車は、数百個の構成要素からなる機械である。構成要素自体は、デバイスまたは機械とすることができる。構成機械は、デバイスのサブセットとみなすことができる。
３．能力：デバイスまたは機械が提供できる機能および機能の範囲を指す（他のいくつかの論文では、これをサービスとも称する。混乱を避けるために、単語「能力」が選択される）。たとえば、モニタは、テキストおよびグラフィックスを表示することができ、さらに、さまざまな解像度、カラー・デプス、およびリフレッシュ・レートを有することができる。
４．プロパティ：デバイスまたは機械の内部データまたは状況情報を表す、デバイス変数または機械変数。プロパティは、時間と共に変化する可能性がある、デバイスまたは機械の動的情報または実行時情報である。
５．メソッド：デバイスまたは機械が提供する、ユーザまたは他のデバイスがそれを操作するための形。たとえば、デバイスが、他者がそれをオンまたはオフにするための「オン／オフ」メソッドを有することができる。
６．イベント：デバイスまたは機械が互いに送る相互通信データの小さいパッケージ。イベントを用いて、デバイスが、互いに関する多数の内部知識なしで、データおよびコマンドを交換することができる。
７．サービス：１つまたは複数のデバイスまたは機械からの、情報またはデータのリモートまたはローカルな提供。
【００１３】
ダイナミック・マシン・スタック（ＤＭＳ）
ＤＭＳは、あるプラットフォーム上のダイナミック・マシンの必要なすべての機能のソフトウェア実施形態である。ＤＭＳは、下記の機能モジュールまたはサービス・モジュールを有しなければならない。
１）Bluetoothまたは他の無線プロトコルもしくはその両方のサポート
ターゲット・プラットフォームが、既にBluetoothのようなモジュールをサポートする場合には、ＤＭＳでの余分なサポートは不要である。しかし、無線モジュールが任意選択であるシステムでは、ＤＭＳによって、必要なBluetoothまたは他の無線プロトコルもしくはその両方のサポートを有しなければならない。
Bluetoothまたは他の無線プロトコルもしくはその両方のサポートは、ＤＭＳの必要な機能である。
２）ダイナミック・マシン転送プロトコル（ＤＭＴＰ）処理
異なる無線デバイスが互いに通話するために、高水準プロトコルが必要である。ＤＭＴＰは、そのようなプロトコルを指し、これによって、基礎となるプロトコルから独立のデバイス・データ交換が可能になる。ＤＭＴＰ処理モジュールは、実際のＤＭＴＰ動作を実行して、異なるデバイスの上位層が互いに通話できるようにするモジュールである。
ＤＭＴＰ処理機能が、必ずＤＭＳによって要求される。
３）ダイナミック・マシン・ネーム・サービス（ＤＭＮＳ）処理
人間のアクセス用の簡単な名前を与えるために必要なＤＭの必須構成要素。ユーザが暗黙のコマンドを発行する時に、ＤＭは、ユーザがどの構成要素を参照しているかを見つける必要がある。ＤＭＮＳは、まさにこのためにある。ＤＭＮＳモジュールは、デバイスまたはＤＭの特性、ユーザの習慣または経験などに従って、実際のネーミング処置または解決処置を実行する。ＤＭＮＳ処理は、ＤＭＳの任意選択の機能である。
４）ダイナミック・マシン・デバイス・プール（ＤＭＤＰ）処理
大量のデバイスを管理するために、アシスタント・サービスが必要である。ＤＭＤＰは、そのような問題に対処するためにある。十分な処理能力を有するシステムだけが、他のデバイスを管理し、サービスするためにこのモジュールを含むことを必要とする。ＤＭＤＰは、ＤＭＳの任意選択の機能である。
５）ダイナミック・マシン・マークアップ言語（ＤＭＭＬ）処理
さまざまなデバイスがそれ自体を記述し、他のデバイスによって理解されるために、共通の言語が必要である。ＤＭＭＬ言語は、この目的のためにある。ＤＭＭＬモジュールの仕事は、デバイスがＤＭＴＰを介して記述を保管し、交換することである。ＤＭＭＬ処理は、ＤＭＳの必要な機能である。
６．ダイナミック・マシン・テンプレート言語（ＤＭＴＬ）ランタイム
ＤＭＳアプリケーションの作成のために、クロスプラットフォーム言語が必要である。ＤＭＴＬは、そのような言語を指す。ＤＭＴＬランタイムには、デバイスが、たとえばＪａｖａ（Ｒ）ランタイムなど、ＤＭＳアプリケーションを実行するのに必要なサポート機能が含まれなければならない。
【００１４】
ＤＭＳは、最も広い範囲のデバイス上で動作することが想定されるので、動作可能なＤＭＳを構築する際には、標準規格が非常に重要になる。主要なデバイス製造業者および構成要素開発者は、オープン標準規格を確立し、それに従い、その結果、さまざまな製品が問題なく相互作用できるようにする必要がある。非オープンまたは特定の応用分野であっても、すべての部分が一緒にうまく動作するようにするために、内部規格がやはり必要である。
【００１５】
ダイナミック・マシン合成をサポートするすべてのデバイスが、ＤＭＳ（ダイナミック・マシン・スタック）をインストールされなければならない。スタックのある構成要素を、オペレーティング・システムの設計者からまたはサード・パーティ開発者からのものとすることができる。これは、ファイル、ＲＡＭ、ＲＯＭ、またはチップ論理ユニット内に組み込まれた、ライブラリ、プラグイン、プログラム、またはドライバによって表すことができる。これは、各構成要素がどのように実施されるかに無関係に、ＤＭＳとみなされる。
【００１６】
ＤＭＳは、Bluetoothなどの無線プロトコル・スタックの上にあり、デバイス相互通信プロトコルとしてＤＭＴＰを利用する。デバイスは、他者による理解のための自己記述にＤＭＭＬを使用する。ＤＭＴＬで記述されたアプリケーションによって、さまざまなＤＭの機能性および挙動が定義され、真の便宜および柔軟性がユーザにもたらされる。
【００１７】
下記は、ＤＭＳ構成要素の詳細な説明である。
【００１８】
ＤＭＴＰとデバイスの間の相互通信
Bluetoothなどのプロトコルは、既に音声通信およびデータ通信をサポートするが、それ以外のプロトコルはそうではない。したがって、複雑なデータ交換のために、より上位のプロトコルが必要である。さらに、ＤＭＳは、Bluetooth以外のさまざまなスタックにまたがって動作することが想定され、したがって、クロスプラットフォーム通信を可能にするために、より上位のプロトコルが必要である。ここでのＤＭＴＰは、そのようなプロトコルの１つを指す。
【００１９】
実際のＤＭＴＰは、既存の無線プロトコルの特性を考慮に入れ、基礎となる詳細を隠蔽し、さまざまなプラットフォームの間での可能にされた複雑なデータ交換への標準インターフェースを提供しなければならない。ＤＭＴＰは、必要なルーティング能力およびフォールト・トレランス能力を有する、コネクション指向またはコネクションレスのパケット交換プロトコルとすることができる。たとえば、２つのBluetoothデバイスが、同一のピコネット内にある場合に、これらのデバイスは、互いに直接に通話することができる。あるいは、２つのデバイスが異なるピコネット内にある場合に、転送機能が、パケットが宛先に到達するのを助ける。また、２つのデバイスが、異なる通信モジュールを有する場合に、ゲートウェイまたはルータが、２つのデバイスの間のデータ交換を助ける。
【００２０】
ある状況、たとえば、すべてのデバイスがBluetooth対応であり、同一のピコネット内にある場合に、ＤＭＴＰ処理モジュールが不要と思われることに留意されたい。しかし、より一般的な実施形態について、ＤＭＴＰは必須である。最も単純な場合であっても、確かに、ＤＭＴＰは、通信の信頼性を強化し、同一の種類のスタックの異なるバージョンの間の非互換性の曲線をやわらげるのに役立つ。
【００２１】
ＤＭＭＬおよびデバイス記述
ＤＭＴＰは、デバイスが共通の形で通話することを保証するが、デバイスは、互いを理解できるようになる前に、同一の言語を話さなければならない。ＤＭＭＬは、デバイス記述用のすべての可能な共通言語を指す。実際のＤＭＭＬは、ＸＭＬ技術に基づくものとすることができ、これによって、ＤＭＳアプリケーションとＸＭＬベース・サービスの間の可能な接続が簡単になる。各ＤＭＳデバイスは、１つまたは複数の組込みＤＭＭＬページを持たなければならず、これによって、デバイス自体の能力、プロパティ、イベント、および、使用可能な場合に、制御パネル、音声コマンド、および、デバイスまたは人間もしくはその両方がデバイスの性質を理解するのに必要な他の情報が記述される。あるデバイスからのＤＭＭＬページは、可読フォーマットでのそのデバイスの詳細なプロファイルとみなされる。このページを解析した後に、このデバイスに対するさらなる操作を行うことができる。
【００２２】
ＤＭＳデバイスは、ＤＭＭＬ処理モジュールを有しなければならず、このＤＭＭＬ処理モジュールの仕事は、他のデバイスから得たＤＭＭＬページを解析し、ＤＭＴＰモジュールを介する照会の際に、このデバイス自体のページを他のデバイスに送信することである。
【００２３】
さらに、ＤＭ全体に関するＤＭＭＬページを、必要な時に高水準管理のために生成することができる。ＤＭＳアプリケーションに、ページを生成するメソッドを含めることができる。
【００２４】
ＤＭＴＬおよびＤＭＳアプリケーション
ＤＭは、構成要素デバイスの組込み機能を超えた高度な機能を提供することが想定される。他のデバイスのそれぞれの能力を理解し、強化された機能を自動的に生成するのに十分にスマートなデバイスを構築することは、非常に困難である。また、２つの最も単純なデバイスを利用する多数の形がありえる。したがって、強化された特徴をユーザが使用可能にするために、ＤＭＳアプリケーションと称する特別なプログラムが必要である。
【００２５】
ＤＭＳアプリケーションは、さまざまなプラットフォームにまたがって動作することが想定され、したがって、ＤＭＴＬと称する、プラットフォーム独立のプログラミング言語が必要である。実際のＤＭＴＬで記述されたアプリケーションは、さまざまなプラットフォームで動作することが想定される。したがって、各プラットフォームに、必要なサポートが存在しなければならず、これは、ＤＭＴＬ実行時モジュールに含まれると想定される。
【００２６】
さらに、同一のアプリケーションが、デバイスがすべての要件を満たす限り、デバイスの異なる組で実行されることが想定される。したがって、ＤＭＳアプリケーションは、テンプレートとも呼ばれる。テンプレートにあてはまるオブジェクトのあらゆる組が、アプリケーションを実行することができる。テンプレートには、デバイス能力要件、必要なデータ、およびメソッドが含まれなければならない。また、テンプレートは、アプリケーションが、かかわるデバイスの実際の組をサポートするまで決定されない。
【００２７】
ＤＭＮＳ
他のデバイスは、あるデバイスをそのアドレスによって識別することができる。しかし、必要なデバイスまたは構成要素のそれぞれに、ユーザフレンドリな名前が必要である。ユーザが暗黙のコマンドを発行する時に、実際のターゲット・デバイスを識別することも必要である。ＤＭＮＳは、上記の問題を解決するサービスを指す。
【００２８】
実際のＤＭＮＳは、専用の公用デバイス、機械、またはユーザ・デバイス上で稼動するアプリケーション独立のサービスと想定される。実際のＤＭＮＳは、デバイスとあいまって動作して、アプリケーションおよびデバイスの性質、ユーザの習慣、またはプリファレンスならびに空間的情報などの必要な情報を入手して、デバイスの正しい名前を見つけるか、実際のデバイス名を解決しなければならない。
【００２９】
構成デバイスの名前は、一時的な別名にすぎず、ＤＭの分解の後に無効になる可能性がある。しかし、実際のＤＭＮＳ実施形態で自己学習機構を採用することができ、その名前を、おそらくはサービス性能を改善するために保持することができる。
【００３０】
ＤＭＤＰ
公用の場所ならびに家庭または自動車環境で、公用アクセス用の数百個または数千個のデバイスがある場合がある。ＤＭＤＰは、効率的な管理手段を用いてこの混乱を解決するサービスである。
【００３１】
実際のＤＭＤＰサービスは、専用の公用デバイスまたは公用機械上で稼動することができる。ＤＭＤＰは、デバイス管理作業を処理するブローカとして動作することができる。ＤＭＳアプリケーションが始動され、ある能力を有するデバイスが必要である時には、必ず、ＤＭＤＰが、アプリケーションが適切なデバイスを見つけるのを助けなければならない。アプリケーションが、このデバイスの使用を終了する時に、ＤＭＤＰは、将来の使用のためにこれらのデバイスをリセットするのを助ける。
【００３２】
ＤＭＤＰの仕事は、多数の候補の間から適切なデバイスを見つけることのオーバーヘッドを除去して、ＤＭの構築を単純化し、高速化し、通信性能を最適化することである。
【００３３】
必要な標準規格
１）デバイス能力記述
これは、ＤＭＳの基礎であり、既存デバイスのカテゴリ化を介して得ることができる。たとえば、モニタについて機能項目名「ディスプレイ」を定義し、その後、この項目の下で、「解像度」、「カラー・デプス」、および他の必要な項目などのサブ項目を定義することができる。各項目のラベルおよび有効なパラメータ範囲を、決定しなければならない。
２）デバイス・プロパティ記述
能力は、デバイスの「静的」情報を提示するが、プロパティは、モニタの現在の解像度など、デバイスの「動的」または実行時の状況を示す。プロパティ記述標準規格は、能力標準規格に非常に類似し、同様のルーチンを介して得ることができる。
３）イベント記述
デバイスがデータまたは制御を互いに交換するために、デバイス相互作用を、イベントすなわち、コマンドまたはデータを含むメッセージ・パケットを介して実行することができる。イベント記述標準規格は、標準化されたデータ・フォーマットおよびパラメータ範囲を介してデータ交換を正規化すると想定される。
【００３４】
すべての種類のデバイスを含む完全な標準規格は、簡単には生成できない。しかし、いくつか種類のデバイスが、標準規格のサブセットとみなされるイベントの同一の組をサポートすることは可能である。サブセットは、必要な時に更新することができ、開発者は、アプリケーション作成のために最新バージョンを検索することができる。
【００３５】
すべてのデバイスが、互換性および一貫性を維持するために、オープンであれクローズドであれ、関連ＤＭＳ標準規格に従わなければならず、そうでなければＤＭＳは絶対に正常に動作しない。
【００３６】
ダイナミック・マシン合成
１）デバイス要件
ＤＭＳアプリケーションは、ＤＭＳ対応デバイスを必要とし、ＤＭＳ対応デバイスは、要求される構成要素および機能を有し、最も重要なことにＤＭＳ関連標準規格に従わなければならない、全く新しいデバイスまたは再調整された従来のデバイスとすることができる。
２）無線能力に関する要件
ＤＭＳデバイスは、Bluetooth、ＩＲ、または他の、少なくとも１つの無線モジュールを備えなければならない。ＤＭＳスタックの必要な構成要素が、インストールされなければならない。
３）ＤＭＳ作業モード・サポート
デバイスは、下記の作業モードをサポートしなければならない。
・独立：他のデバイスと無関係に独立に動作する、すべてのデバイスのデフォルト・モードである。
・スレーブ：あるデバイスが、他のデバイスから送られるコマンドまたはデータのみに従って動作する。このモードでは、デバイスが、ＤＭの１構成要素として動作する。すべてのデバイスが、このモードをサポートしなければならない。
・マスタ：デバイスが、ＤＭのコーディネータとして動作する、すなわち、デバイスが、複数のデバイスの状況を監視し、ＤＭＳアプリケーション論理に従ってそれらのデバイスの動作を制御する。強い処理能力を有するデバイスだけが、マスタ・モードをサポートする必要がある。
【００３７】
ダイナミック・マシンの必要な論理構成要素
ＤＭが動作するために、いくつかの論理構成要素が必要である。論理構成要素は、実際には、構成デバイスの連合である。これらの構成要素のすべての定義が、ＤＭＳアプリケーション・コードに含まれなければならず、ある種のアプリケーションは、アプリケーション定義を満足するデバイスの組の上でのみ動作すると思われる。論理構成要素の実際の構成は、アプリケーションによって異なる。同一のアプリケーションと同一のデバイスの組について、構成を、毎回異なるものとすることもできる。
ＣＰＵ：ＰＣに対するＣＰＵと同様に、ＤＭのＣＰＵは、デバイス全体の動作を制御する。マスタ・モードをサポートするデバイスであれば、どれでもＣＰＵになることができ、ＣＰＵを、複数のそのようなデバイスからなるものとすることができる。
制御パネル：ＤＭは、人間−コンピュータ相互作用のために必要な能力を有しなければならない。制御パネルは、さまざまなデバイスのＨＣＩ能力を組み合わせて、ユーザが機械にアクセスするための１つの統合されたインターフェースを形成すると想定される。
主機能本体：ＤＭのうちで主要な作業を達成する部分。これは、アプリケーション定義およびデバイス能力に従う１つまたは複数のデバイスからなるものとすることができる。
接続点：これは、他のデバイス、機械、またはサービスへのＤＭのインターフェースである。これは、複数のデバイスからの複数のモジュールからなるものとすることができる。ＤＭが他のものとの接触を必要としない場合には、接続点は不要である。
【００３８】
動的デバイス・リンク（ＤＤＬ）
プログラミング時に、アプリケーション作成者は、実行時にＤＭがどのデバイスを使用するかを正確に知らない場合がある。アプリケーション作成者は、構成デバイスの必要な能力を定義することだけができ、ダミー・オブジェクトを使用してＤＭ論理コードを完成させる。一致するデバイスを見つけ、ダミー・オブジェクトを実際のデバイスにリンクするのは、実行時マスタ・デバイスの責任である。この手順を、動的デバイス・リンクと称する。
【００３９】
図２（Ａ）からわかるように、ＤＭに、ＡからＨまでの能力が必要である場合がある。下の３つのデバイスが、たまたま、これらの必要な能力のすべてを有し、したがって、実行時に、図２（Ａ）に示されているように、それぞれ正しいダミー・オブジェクトにリンクされる。もちろん、これは、デバイスをオブジェクトにリンクする唯一の形ではない。図２（Ｂ）に、デバイス・リンクのもう１つの可能な形を示す。
【００４０】
ＤＤＬ処理は、ＤＭを構築する時にマスタ・デバイスによって行われると想定される。マスタ・デバイスは、使用可能な適切なデバイスを見つけ、論理構成要素ならびにＤＭ全体をＤＭＴＰを介して構築することを試みなければならない。リンクされたデバイスは、スレーブ・モードに設定され、始動されて、ＣＰＵから送られるコマンドに従って動作する。ＤＭが、もはや不要である時に、逆の処理が開始され、すべてのリンクされたデバイスが、リンクを解除され、独立モードに設定される。
【００４１】
ＤＤＬは、プログラム論理が実際のオブジェクトに従って記述されるのではなく、ダミー・オブジェクトに従って記述されるという、ＤＭＳプログラミングの重要な概念である。アプリケーション論理が実際に動作を開始できるようになる前に、ダミー・オブジェクトを実際のデバイスにリンクしなければならないことも、ＤＭ構築の非常に重要なステップである。
【００４２】
ダイナミック・マシンのライフサイクル
ライフサイクルは、ダイナミック・マシンが、望み通りに存在するようになり、動作し、消滅するための可能なステップを表す。
概念／発想ステップ：ＤＭは、ユーザが簡単にある種類の問題を解決するのを助けると想定される。したがって、問題を発見し、問題に対する解決策を考えることが必要である。
アプリケーション／作成：関係するプロトコルおよび標準規格に基づいて、解決策をＤＭＴＬコードにする実際のステップ。ＤＭの静的定義および実行時論理を、アプリケーション・コードに含めなければならない。
アプリケーションのインストール：ＤＭＳアプリケーション・コードが完成した時に、それが動作し始める前に、あるＤＭＳ対応デバイスにインストールされることが必要である。アプリケーションは、デバイスＯＳまたはハードウェアに事前にインストールするか、任意選択のライブラリ、プラグイン、またはプログラムとして事前にインストールすることができる。
トリガ：アプリケーションは、動作を開始する前に、トリガされる必要がある。アプリケーションは、ユーザによって手動で起動されるか、ユーザのプリファレンス、デバイス構成、ポリシ、イベント、スケジュールなどに従って自動的に起動することができる。
ＤＤＬ：使用可能なデバイスを使用してＤＭを構成する組立処理。構築ステップで特殊な処置を講ずる必要がある場合には、アプリケーション・コードに、必要なコンストラクタ・メソッドを含めることができる。十分なデバイス・リソースが使用可能でない場合には、この処理が失敗し、以下のステップは行われない。
作業／動作：ＤＭは、アプリケーションで定義された論理に従って動作し、デバイス・イベントまたはユーザ・コマンドに応答して、ある作業を完了しなければならない。
逆ＤＬＬ：分解処理は、アプリケーション論理によって自動的に、またはＤＭがもはや不要になった時にＤＭユーザによって手動でのいずれかで、開始される。占有されたすべての構成デバイスおよびリソースが、開放されると想定される。
アプリケーションに、分解ステップで余分な処置を実行するために、必要な破棄メソッドを含めることができる。
ユーザ・フィードバック：上の必要なステップを繰り返すことによって、デバイス製造業者、アプリケーション開発者、またはサービス提供者が、ＤＭＳアプリケーションの使い易さ、効率、およびパフォーマンスを改善するのを助けることができる正しい受取り側に、ユーザの経験、不満、提案、および他の形のフィードバックを向けるのを助けるために、アプリケーションに、あるメソッドを含めることもできる。
【００４３】
ダイナミック・マシンの組立、動作、および分解を、図面に関して下で説明する。
【００４４】
図１に、ＤＭＳアプリケーション（テンプレート）の生成の処理を示す。これには、ユーザが遭遇する問題の発見、要求分析の実行、テンプレート設計の実行、およびテンプレートのインストール／動作が含まれる。
【００４５】
図１では、ステップＳ１０１で、ユーザが、単一の既存のデバイスを使用することによって解決できない問題と、解決策の要求を判定する。その後、ステップＳ１０２で、要件分析を実行して、解決策に必要な能力／構成要素を見つける。ステップＳ１０３では、システム設計を実行するが、これには、ユーザの対話と、システム構成要素間および他のデバイス／機械間のデータ交換とを定義することが含まれる。ステップＳ１０４で、テンプレート・プログラミングを実行するが、これは、能力要件および実行時論理を含む解決策の実際のコーディングであり、これらの能力要件および実行時論理のすべてを、テンプレートに書き込むことができ、テンプレートは、デバイスのすべての類似する組で動作することができる。
【００４６】
オブジェクト指向スクリプト言語ＤＭＴＬが、テンプレート作成に使用され、これによって、クロスプラットフォーム互換性が保証される。テンプレート・プログラミングにかかわる標準規格には、デバイス能力記述、デバイス・プロパティ記述、デバイス・メソッド記述、およびイベント記述が含まれる。
【００４７】
ステップＳ１０５で、プログラムされたテンプレートを、ユーザ・デバイスにインストールして、稼動の準備をする。
【００４８】
図３に、ＤＭＳアプリケーションの組立の処理を示すが、これには、ユーザによるテンプレートすなわちアプリケーションの始動、アプリケーションの分析、必要なデバイスの検索、必要な論理機能構成要素の構成、および稼動の開始が含まれる。ステップＳ３０１で、正しいデバイスを使用して、ユーザがテンプレートを始動する。デバイスは、無線通信対応でなければならず、ＤＭＴＬ実行時環境、必要な処理能力、およびメモリを有しなければならない。ステップＳ３０２で、テンプレートの分析を実行して、必要な能力／構成要素を判定し、必要な処理能力を推定する。ステップＳ３０３で、必要な構成要素を検索する。ステップＳ３０４で、ＤＭＤＰが使用可能であるかどうかを判定する。判定の結果が「ＮＯ」である場合には、ステップＳ３０５に進み、照会メッセージをブロードキャストして、プロトコル独立のデータ交換にＤＭＴＰを使用する。その後、ステップＳ３０６で、デバイスがＤＭＭＬページで応答するのを待つ。
【００４９】
すべてのデバイスが、照会の受信時に照会メッセージに対する応答として組込みＤＭＭＬページを送り返さなければならない。このＤＭＭＬページには、デバイス能力記述、デバイス・プロパティ記述、デバイス・メソッド記述、イベント記述などを含めることができる。
【００５０】
ステップＳ３０７で、所定の判断基準に従って候補デバイスをフィルタリングするが、この判断基準には、あるデバイスが最適であるかどうか、あるデバイスが満足であるかどうか、あるデバイスが最も安価であるかどうか、どの位置にデバイスがあるか、などが含まれ、その後、処理はステップＳ３１１に進む。
【００５１】
ステップＳ３０４の判定の結果が「ＹＥＳ」である、すなわち、ＤＭＤＰが使用可能である場合には、ステップＳ３０９に進み、要件をＤＭＤＰサーバに送信する。ＤＭＤＰは、デバイス管理に関するデバイス・ウェアハウス・サービスを提供し、デバイス検索を高速化する。その後、ステップＳ３１０で、ＤＭＤＰが、正しいデバイスを見つけ、その結果をユーザ・デバイスに送り返す。その後、処理はステップＳ３１１に進む。
【００５２】
ステップＳ３１１では、必要なデバイスが見つかったかどうかを判定する。ステップＳ３１１の結果が「ＮＯ」である場合には、処理はステップＳ３１２に進んで、ユーザに、障害についてプロンプトを出し、その後、処理を打ち切る。必要なデバイスが見つかった場合には、処理はステップＳ３１３に進み、見つかったデバイスへの無線接続をセット・アップするが、ここで、さまざまな無線プロトコル・スタックを有するデバイスが含まれる場合には、ゲートウェイが必要になる場合がある。その後、ステップＳ３１４で、動的デバイス・リンクを実行する。
【００５３】
ステップＳ３１５で、ＤＭの論理構成要素を、テンプレート要件および実行時論理定義に従って構築するが、各構成要素が、複数のデバイスからなる場合がある。これらのデバイスには、通常は、ＣＰＵすなわち、ＤＭ動作を制御するのに十分な処理能力を有し、テンプレートを始動するユーザ・デバイスまたは他のデバイスとすることができるデバイスと、ＤＭ全体のＨＣＩ部分であり、テンプレートで定義された必要なＨＣＩ能力に従って構築される制御パネルと、ＤＭの主要な作業を達成する部分である主機能本体と、ＤＭが他のデバイス／機械との接続を必要とする時に限って必要な接続点とが含まれる。
【００５４】
ステップＳ３１６で、ＤＭＮＳを介して構成要素／デバイスのネーミングを実行する、すなわち、ＤＭ内の必要な構成要素／デバイスに、マルチモーダル処理のためのユーザフレンドリな名前が付けられる。
【００５５】
したがって、ＤＭが構築された。
【００５６】
図４は、ＤＭＳの動作処理を示す図であり、ここでは、ＣＰＵが、初期化を実行し、動作中に生成されるさまざまなイベントを処理する、すなわち、関連デバイスに対する動作を実行する。
【００５７】
図４からわかるように、ＤＭＭＬが作業を開始した後に、ステップＳ４０１で、ＣＰＵが、ＤＭを初期化し、テンプレートで定義されたポータル・メソッドを実行して、正しいイベント・パケットを構成デバイスに送ることによって必要なデバイスおよびＤＭ全体を初期化する。
【００５８】
ステップＳ４０２で、イベントを取得するが、これは、ユーザ入力、データ交換、またはデバイス状態変化によって生成され、ＣＰＵに送られていたイベントである可能性がある。
【００５９】
ステップＳ４０３で、事前定義の処理論理が見つかるかどうかを判定する。ステップＳ４０３の結果が「ＮＯ」である場合には、処理はステップＳ４０４に進み、イベントを除去する。
【００６０】
ステップＳ４０３で事前定義の処理論理が見つかる場合には、処理はステップＳ４０６に進み、テンプレートの事前定義の論理を使用することによってイベントを処理し、構成デバイスが実行しなければならないことを判定する。
【００６１】
その後、処理はステップＳ４０７に進み、構成デバイスに、イベントを介して指令し、ＣＰＵが、正しいデバイスへの適当なイベント・パケットを生成する。ここで、イベント記述標準規格が使用される。
【００６２】
その後、処理はステップＳ４０８に進み、ＣＰＵが、ＤＭＴＰを介して正しいデバイスにイベント・パケットを送る。
【００６３】
図５に、ＤＭＳの分解処理を示すが、ここでは、ＣＰＵが、分解を実行し、リセット・メッセージをブロードキャストし、デバイスを解放する。
【００６４】
図５からわかるように、ステップＳ５０１で、分解処理が、ユーザ・コマンドまたはある種のイベントによってトリガされ、ＤＭが作業を停止する。その後、ステップＳ５０２で、ＣＰＵが、リソースの解放、リモート・サーバからの切断などを含む、デストラクタ・メソッドを呼び出し、その後、ステップＳ５０３で、リセット・イベントをブロードキャストする。すべての構成デバイスが、このイベントに応答することによって確認し、必要なクリーン・アップを実行しなければならない。このステップでは、イベント記述標準規格が使用される。ステップＳ５０４で、各構成要素が確認するまで待つ。
【００６５】
その後、ステップＳ５０５で、構成要素がＤＭＤＰを介して得られるかどうかを判定する。ステップＳ５０５の結果が「ＮＯ」である場合には、処理はステップＳ５０６に進んで、もう１つのリセット・イベントをブロードキャストする。その後、ステップＳ５０７で、ＣＰＵが、ＤＭＳの自己分解を実行し、ＣＰＵによって制御された構成要素を解放し、分解処理を終了する。
【００６６】
ステップＳ５０５の結果が「ＹＥＳ」である場合には、処理はステップＳ５０８に進み、構成デバイスが、ＤＭＤＰに返され、ＤＭＤＰが、必要なクリーン・アップおよびリセットを実行する。その後、ステップＳ５０９で、ユーザ・デバイスが、それ自体を解放し、分解処理を終了する。
【００６７】
ＤＭＳの長所
自然で一貫性のあるデバイス・アクセスおよびデバイス管理：さまざまなデバイスが、さまざまなアクセス・メソッドを有する。従来の手法では、デバイスが、ある種類のアクセス・メソッドをサポートする必要がある場合に、そのデバイスに、適当なモジュールを物理的にインストールしなければならない。たとえば、電子レンジが音声コマンドをサポートする場合には、電子レンジが、音声認識モジュールを有しなければならない。さまざまなデバイスが、一緒にされた時に多数の混乱および不便を引き起こすであろうさまざまなリモートコントロール・セットを備える。ＤＭＳは、この種類の問題を解決する新しい解決策を提供する。それは、すべてのデバイスからのすべてのアクセス能力および管理能力を、ＤＭ構築を介してすべての他のデバイスから使用可能にすることである。たとえば、あるデバイスの音声認識エンジンが、他のデバイスをサービスして、それらのデバイスが音声対応であるように見えるようにすることができる。あるいは、タッチ・スクリーンを有するＰＤＡが、多数の他のデバイスの制御パネルを表示することができ、ユーザが、いつでも所望のデバイスをとり、混乱なしにそのＰＤＡを用いてターゲット・デバイスに指令することができる。
【００６８】
便宜および柔軟性：人々は、仕事をする時にさまざまなことを行う必要があるが、単一のデバイスのどれであっても、すべての作業を処理することはできない。多数のデバイスを常時持ち運ぶことができるが、これは全く便利ではない。あるいは、ある強力な「オールインワン」デバイスを発明しようとすることもできる。実際には、「オールインワン」は、魅力的ではあるが実用的ではない。というのは、そのようなデバイスが、ポータブルな形で構築することが困難であり、新しい要件を満足するためにしばしば更新しなければならず、まったく柔軟でないからである。ＤＭＳを用いると、強力なＤＭを、必要な時に構築することができ、ユーザは、少数の強力なマスタ・デバイスを持ち歩くだけでよい。特定の応用例のために機械を調整する必要がない、単純なデバイスを使用する多数の形がありえる。ＤＭＳは、最も複雑な問題でも解決できるダイナミック・マシンを提供する。
【００６９】
最適化されたリソース分配：このごろは、人々が、「８０−２０」問題に常に遭遇する、すなわち、仕事する時間の８０％を、すべての機能のうちの２０％だけを用いて過ごす。しかし、１００％のために支払わなければならない。ＤＭＳは、頻繁には使用されない機能モジュールを、共用される公用リソースにする、この問題に対する可能な解決策を提供する。これらのリソースを、ＤＭＳを介して他のデバイスにつないで、完全な作業を実行することができる。したがって、ユーザは、頻繁には使用されないリソースを、それを使用する希な機会のために「買い」、その時を待つのではなく、必要な時に「借りる」ことができる。
【００７０】
本明細書の実施形態および修正形態の説明および図示が、本発明の原理の例示だけを目的とし、本発明の範囲から逸脱せずに、当業者がさまざまな修正を実施できることを理解されたい。
【００７１】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００７２】
（１）デバイスの群から選択されたデバイスを使用して機械を構成する方法であって、前記群内の各デバイスが、短距離無線通信能力を有し、
ユーザからの指示に応答してアプリケーション・テンプレートを始動するステップと、
前記機械に必要な能力を決定するために前記テンプレートを分析するステップと、
前記能力の１つまたは複数を有するデバイスについて前記群内を検索するステップと、
前記検索ステップで探し出されたデバイスを前記機械に統合するステップと
を含むことを特徴とする方法。
（２）前記テンプレートが、それぞれが必要な能力を有する１つまたは複数の構成要素を用いて形成される前記機械を定義し、前記統合するステップが、
リンクされたデバイスを使用して前記構成要素のそれぞれを構築するために、前記必要な能力の少なくとも１つを有する、前記群からのデバイスをリンクするステップと、
前記構成要素を前記機械に統合するステップと
を含むことを特徴とする、上記（１）に記載の方法。
（３）前記テンプレート・アプリケーション用のプール処理を実行することができるプール処理デバイスが前記群内に存在するかどうかを判定するステップ
をさらに含むことを特徴とする、上記（１）に記載の方法。
（４）プール処理デバイスが前記群内に存在すると判定される時に、前記プール処理デバイスが、前記検索するステップおよびデバイス管理を実行することを特徴とする、上記（３）に記載の方法。
（５）プール処理デバイスが前記群内に存在しないと判定される時に、前記検索するステップが、
前記群に照会メッセージをブロードキャストするステップと、
前記群内の各デバイスが、その自己記述情報を用いて前記照会メッセージに応答することを可能にするステップと
を含むことを特徴とする、上記（３）に記載の方法。
（６）前記自己記述情報が、少なくともそれ自体の能力、プロパティ、およびイベントを記述する、少なくとも１つの組込みページを含むことを特徴とする、上記（５）に記載の方法。
（７）前記少なくとも１つの組込みページが、前記群内のすべてのデバイスに共通する１つまたは複数の言語で、可読フォーマットで記述された、前記デバイスの詳細なプロファイルを含むことを特徴とする、上記（５）に記載の方法。
（８）前記プロファイルが、
デバイス能力記述と、
デバイス・プロパティ記述と、
デバイス・メソッド記述と、
イベント記述と
から選択される情報を含む、上記（７）に記載の方法。
（９）高水準管理のために前記機械に関する情報を生成するステップ
をさらに含む、上記（７）に記載の方法。
（１０）前記自己記述情報に基づいて、前記計算機を構築するのに使用されるデバイスを選択するステップ
をさらに含むことを特徴とする、上記（５）に記載の方法。
【図面の簡単な説明】
【図１】テンプレートを構成する処理を示す図である。
【図２】構成要素がデバイスからどのように定式化されるかを示す図である。
【図３】ＤＭの組立処理を説明する流れ図である。
【図４】ＤＭの動作を説明するのに使用される図である。
【図５】ＤＭの分解を説明するのに使用される図である。
【符号の説明】
ＤＭ  ダイナミック・マシン
【図１】
0003870168.tif 000002
【図２】
0003870168.tif 000003
【図３】
0003870168.tif 000004
【図４】
0003870168.tif 000005
【図５】
0003870168.tif 000006