スマートアイテムに関する階層型多層マッピングおよびモニタリングアーキテクチャ
【課題】 ビジネス業務に関する正確かつ適時なデータをビジネスに提供し、そのビジネス業務の能率化および自動化を支援する技術を提供すること。
【解決手段】 サービスリポジトリを使用して、少なくとも１つのサービスを、そのサービスのサービス要件を記述したサービスメタデータに関連付けて、格納する。サービスリポジトリは、１つまたは複数のプラットフォーム固有のサービス実行ファイルも格納する。サービスマッパを使用して、複数のデバイスの各々に関連付けられたデバイスメタデータ（１３０）を判定する。このデバイスメタデータは、デバイスのデバイス特性を提供する。このようにして、サービスマッパは、サービス要件の対応する要素と、デバイス特性とのマッチングに基づいて、複数のデバイスから選択されたデバイス上にサービスを配置するために、サービスを選択されたデバイスにマッピングすることができる。
【解決手段】 サービスリポジトリを使用して、少なくとも１つのサービスを、そのサービスのサービス要件を記述したサービスメタデータに関連付けて、格納する。サービスリポジトリは、１つまたは複数のプラットフォーム固有のサービス実行ファイルも格納する。サービスマッパを使用して、複数のデバイスの各々に関連付けられたデバイスメタデータ（１３０）を判定する。このデバイスメタデータは、デバイスのデバイス特性を提供する。このようにして、サービスマッパは、サービス要件の対応する要素と、デバイス特性とのマッチングに基づいて、複数のデバイスから選択されたデバイス上にサービスを配置するために、サービスを選択されたデバイスにマッピングすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユビキタスコンピューティング技術に関する。
【背景技術】
【０００２】
スマートアイテム技術には、例えば、無線周波数識別（ＲＦＩＤ：Radio-Frequency IDentification）システム、組み込みシステム、センサモート（sensor mote）、および／または、センサネットワークが含まれ、スマートアイテム技術を使用して、例えば、実世界データへの高速アクセスをビジネスソフトウェアアプリケーションに対して提供することができる。例えば、スマートアイテム技術を使用して、ＲＦＩＤタグの検出、読み取り、または書き込みをサポートすることでき、さらに、無線センサネットワークと組み込みシステムとの通信、および、それらの制御をサポートすることができる。多くの例において、スマートアイテムは、ローカルな処理パワー、メモリ、および／または通信能力を有するデバイスを含むことができる。そのデバイスは、デバイスに関するデータおよび特性、またはスマートアイテムデバイスの現在の状態もしくは環境についての情報を提供することができる。したがって、そのようなデバイスの中には、バックエンドまたは下位のビジネスアプリケーションのサービスコンポーネントを実行するのに使用することができ、特に、例えば、モバイルアドホックネットワークを形成して、ビジネスデータを収集、処理、または送信することにより、それを協調して行うことができるものもある。
【０００３】
スマートアイテムデバイスの例として、ＲＦＩＤタグがある。ＲＦＩＤタグは、受動型または能動型のものがあり、実世界の物体に取り付けて、その物体に関する製品情報または取扱い情報を提供するために使用できる。スマートアイテムデバイスの他の例には、例えば、環境センサ（温度センサ、湿度センサ、または振動センサ）等の様々なセンサがあり、前述したように、これらは、１つまたは複数のセンサネットワークを形成して、通信することができる。これら、および他の種類のスマートアイテムデバイスにはまた、組み込みシステムも含まれる。その組み込みシステムは一般に、特殊用途プロセッサおよび／またはプログラムを含む任意のシステムを指し、ならびに／あるいは、そのシステムは、制御されているデバイス内にカプセル化される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ビジネス業務に関する正確かつ適時なデータをビジネスに提供し、そのビジネス業務の能率化および自動化を支援する技術が必要とされている。自動的でリアルタイムな物体追跡能力および検出能力を用いることにより、スマートアイテム技術によって、コスト削減および新たなビジネス上の利益（例えば、資産可視化の進展、応答性の改善、およびビジネス機会の拡大）を得ることができる。
【課題を解決するための手段】
【０００５】
一般的な一側面にしたがうと、サービスが判定され、そのサービスが、そのサービスを記述するためのサービスメタデータに関連付けられる。複数のデバイスの各々に関連付けられたデバイスメタデータが判定され、サービスメタデータおよびデバイスメタデータに基づいて、複数のデバイスから、選択されるデバイスが決定される。
【０００６】
実施形態には、次のうちの１つまたは複数の特徴を含めることができる。例えば、サービスの判定において、サービスのマッピング要求を受信することができ、および／または、そのサービスは、元のデバイス上で現在実行されているサービスと判定することができる。
【０００７】
サービスの判定において、サービスの実行ファイル、および、そのサービスのサービスメタデータを、サービスリポジトリから判定することができる。さらに、サービスを実行するためのサービス要件は、サービスメタデータから判定することができる。後者の例において、サービス要件を判定することには、次のうちの１つまたは複数のことを含めることができる。それらは、サービスの挙動を判定すること、抽象的な技術的制約を判定すること、具体的な技術的制約を判定すること、抽象的な技術的制約と具体的な技術的制約との間の変換を判定すること、入力／出力の制約を判定すること、前提条件を判定すること、効果を判定すること、静的なハードウェア要件を判定すること、動的なハードウェア要件を判定すること、処理特性を判定すること、メモリ特性を判定すること、電力特性を判定すること、実行プラットフォームを判定すること、またはネットワーク特性を判定することである。
【０００８】
デバイスメタデータを判定することには、次のことを含めることができる。それらは、複数のデバイスからなる少なくとも１つのグループを定義すること、そのグループのグループリーダデバイスを定義すること、および、そのグループリーダデバイスに命令してグループに問い合わせ、グループ内の各デバイスに関するデバイスメタデータを取得して、グループに関する取得したデバイスメタデータを転送することである。さらに、デバイスメタデータを判定することには、複数のデバイスに問い合わせて、各デバイスのデバイス特性を判定することを含めることができる。後者の例において、複数のデバイスに問い合わせることには、次のうちの１つまたは複数を含むデバイス特性を判定することを含めることができる。それらは、デバイスの記述、デバイスの名前、デバイスの識別子、デバイスの種類、デバイスのベンダ、ソフトウェアの記述、オペレーティングシステムの記述、サービス、ハードウェアの記述、プロセッサの記述、接続の記述、接続の速度、接続の種類、メモリの記述、総メモリ量、空きメモリ量、デバイスの状態、または実行プラットフォームである。
【０００９】
複数のデバイスから選択されるデバイスを決定することには、サービスメタデータとデバイスメタデータとの間で対応する要素をマッチングさせることを含めることができる。さらに、複数のデバイスから選択されるデバイスを決定することには、サービス要件を複数のデバイスの各々の対応するデバイス特性とマッチングさせることと、サービスに関連付けられた重み付け式（weighted formula）をデバイス特性に適用して、各デバイスに関連付けられた少なくとも１つの値を取得することと、その少なくとも１つの値に基づいて、選択されるデバイスを選択することとを含めることができる。
【００１０】
複数のデバイスから選択されるデバイスを決定することには、それらのデバイスの少なくともいくつかを含むネットワークに関連付けられたネットワークメタデータを判定することと、そのネットワークメタデータに基づいて、選択されるデバイスを決定することとを含めることができる。そのネットワークメタデータには、次のうちの１つまたは複数が含まれる。それらは、利用可能な帯域幅、送信特性、ネットワークプロトコル、または現在のネットワークパラメータである。さらに、複数のデバイスから選択されるデバイスを決定することには、サービスの配置を要求するユーザが提供する管理上のシステム制約を判定することと、選択されたデバイス上に配置するために、その管理上のシステム制約を変換することとを含めることができる。
【００１１】
また、サービスは、選択されたデバイス上にインストールされたサービスインジェクタにそのサービスを提供することにより、選択されたデバイスに配置することができる。
【００１２】
別の一般的な一側面にしたがうと、システムは、サービスのサービス要件を記述するサービスメタデータと関連させて少なくとも１つのサービスを格納することができるサービスリポジトリと、複数のデバイスの各々に関連付けられ、デバイスのデバイス特性を提供するデバイスメタデータを判定することができるサービスマッパとを備える。そのサービスマッパは、さらに、サービス要件とデバイス特性との対応する要素のマッチングに基づいて、複数のデバイスのうちの選択されたデバイスに対して、その選択されたデバイスに配置するために、サービスをマッピングすることができる。
【００１３】
実施形態には、次のうちの１つまたは複数の特徴を含めることができる。例えば、複数のデバイスと、その複数のデバイスのうちの少なくともいくつかを含むネットワークに関連付けられたネットワークメタデータとのうちの少なくとも一方をモニタリングすることができるシステムモニタを含めることができる。
【００１４】
サービスマッパには、ローカルネットワークの特性にしたがってセンサネットワークのローカルネットワークをソートすることができるグローバルサービスマッパコンポーネントと、少なくとも１つのローカルネットワークに関連付けられ、複数のデバイスからなるグループをソートすることができるローカルサービスマッパコンポーネントと、少なくとも１つのグループのグループリーダに関連付けられたグループサービスマッパコンポーネントとを含めることができる。サービスマッパは、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、およびグループサービスマッパコンポーネントを使用して、デバイスの問い合わせを配布することにより、デバイスメタデータを判定することができる。サービスマッパは、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、またはグループサービスマッパコンポーネントを使用して、サービスメタデータを選択されたデバイスとマッチングさせることにより、サービスをマッピングすることができる。サービスマッパはさらに、上記の配布に応じて、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、およびグループサービスマッパコンポーネントのうちの少なくとも１つを更新することができる。
【００１５】
サービスマッパは、パフォーマンスメトリックをマッチングの初期結果集合に適用した結果に基づいて、選択されるデバイスを決定することができる。そのパフォーマンスメトリックには、サービスの実行に対する各要素の相対的な重要度に基づいて要素を重み付けすることが含まれる。デバイスには、例えば、ＲＦＩＤリーダ、センサネットワーク内のデバイス、センサモート、または組み込みシステムデバイスなどの、１つまたは複数のスマートアイテムデバイスを含めることができる。
【発明を実施するための最良の形態】
【００１６】
図面を参照しながら、以下において、１つまたは複数の実施形態を詳細に説明する。他の特徴は、その説明および図面、ならびに特許請求の範囲から明らかとなるであろう。
【００１７】
図１は、スマートアイテムデバイスに関して、サービスからデバイスにマッピングするシステム１００のブロック図である。図１の例において、様々なスマートアイテムデバイスを含むローカルネットワーク１０２は、ワイドエリアネットワーク１０６（これは、ローカルエリアネットワークまたは他の種類のネットワークを、追加で、または代替として含んでもよい）を使用して、１つまたは複数のビジネスデータ処理システム１０４に、正確かつ適時に実世界データを提供する。例えば、ローカルネットワーク１０２には、スマートアイテムデバイス１０８、１１０、１１２および１１４を含めることができ、それらを本明細書では、「スマートアイテムデバイス」、または、単に「デバイス」と呼ぶ。それらのデバイスには、（実世界の物体に関連付けられたＲＦＩＤタグを読み取るための）ＲＦＩＤリーダ、様々な組み込みシステム、および／または、様々な種類のセンサ、および／または、センサモートを含めることができる。
【００１８】
図１において、デバイス１０８は、中央処理装置（ＣＰＵ）１１６およびメモリ１１８を備えるものとして示されている。したがって、デバイス１０８は、様々なレベルのコンピューティング能力を有することができるものと理解されたい。そのコンピューティング能力には、例えば、（デバイス１０８がセンサを備えていた場合、）検出したデータの処理や送信が含まれる。明瞭にするために、図１に具体的には示していないが、デバイス１１０、１１２および１１４もまた、同様の、または異なるコンピューティング能力を有することができるものと理解されたい。そのコンピューティング能力には、例えば、無線ネットワークおよび／またはピアツーピアネットワークなどのローカルネットワーク１０２を形成する能力、および、そのネットワークに参加する能力が含まれる。
【００１９】
したがって、ローカルネットワーク１０２を使用して、ビジネスデータ処理システム１０４にとって有用となり得るデータを収集、処理、フィルタリング、集約、または送信することができる。例えば、ビジネスデータ処理システム１０４には、在庫管理システム、サプライチェーンマネジメントシステム、小売店管理システム、倉庫管理システム、および、実世界の物体に関するビジネス処理の実行に使用できる任意の他のシステム（群）を含めることができる。このような実世界の物体には、例えば、販売用製品、パレットまたは他の出荷に関わる要素、患者、または製造資材／製造機器を含めることができる。このような実世界の物体を追跡および分析することにより、ビジネスデータ処理システム１０４を使用して、例えば、在庫レベルの判定、価格レベルの設定、マーケティング戦略の評価、製造技術または生産技術の評価、盗難の低減、または安全の維持が可能となる。
【００２０】
ローカルネットワーク１０２のデバイス１０８、１１０、１１２および１１４のようなスマートアイテムデバイスを含むことにより、（複数の）データ収集プロセスにおいて、非常に迅速に処理を実行することができるので、ビジネスデータ処理アプリケーション１０４にかかる負荷を軽減または排除することができる。例えば、ビジネスデータ処理アプリケーション１０４は、企業の本社に配置することができ、ローカルネットワーク１０２は、ワイドエリア（またはローカルエリア）ネットワーク１０６を介して接続された、広範囲の地理的領域にわたって分散する可能性のある多数の（様々な種類の）デバイスネットワークのうちの１つを表すことができる。したがって、例えば、ビジネスデータ処理システム１０４は、ネットワーク１０２（および関連するネットワーク）を介して収集されたデータの所定のサブセットまたは特性を要求するだけでよく、全ての収集データを必要としないし、全ての収集データを要求しなくてよい。
【００２１】
いくつかの実施形態において、ビジネスデータ処理システム１０４には、明確に定義された（複数の）タスクを実行するために設計された再利用可能なソフトウェアコンポーネントまたはサービスから構成される複合アプリケーションあるいは合成アプリケーションを含めることができる。また、これら、または他の実施形態において、ビジネスデータ処理システム１０４には、データ収集デバイスと（または、他のビジネスデータ処理システムと）容易に通信することができないレガシーアプリケーションを含めることができ、その場合、サービスまたはサービスコンポーネントを、レガシーアプリケーションと、データ収集デバイスおよび／または他のシステムとの間のインタフェースとして提供することができる。システム１００により、これら、および他のアプリケーション、ならびにサービスを、デバイス１０８、１１０、１１２および１１４上に直接配置することができるので、例えば、適時に、効率的に、確実に、自動的に、コスト効率良く、および拡張性を有するように、サービスをそのデバイス上で実行（ならびに、データを収集および／または処理）することができる。したがって、例えば、ビジネス処理を個々のサービスに分解し、異なるデバイスに配置することができる。
【００２２】
システム１００には、図示するように、サービス１２２を配置するために、デバイスのネットワーク１０２に存在する複数のデバイス１０８、１１０、１１２および１１４の中から選択されるデバイスとして、デバイス１０８を選択することができるサービスマッパ１２０が含まれる。その過程において、サービスマッパ１２０は、ローカルネットワーク１０２および／または他のネットワーク（図１には図示せず）内での実行に適する複数のサービスを格納することができるサービスリポジトリ１２４にアクセスする。サービスマッパ１２０は、実際のサービス実行ファイル１２８とともに、サービスメタデータ１２６を判定し、サービスメタデータ１２６を、複数のデバイス１０８、１１０、１１２および１１４の各々に関連付けられたデバイスメタデータ１３０と比較する。少なくともサービスメタデータ１２６およびデバイスメタデータ１３０に基づいて、サービスマッパ１２０は、（サービス実行ファイル１２８を含む）サービス１２２を配置するのに特に適しているものとして、デバイス１０８を選択することができる。
【００２３】
例えば、デバイスメタデータ１３０には、各デバイスの記述を含めることができ、その記述は、オントロジおよび／またはスキーマにしたがって構築される。そのオントロジおよび／またはスキーマは、サービスマッパ１２０にとって既知であり、様々なデバイス１０８、１１０、１１２および１１４に共通するものである。追加で、または代替として、デバイスメタデータ１３０は、例えば、システムモニタ１３２により、デバイス１０８、１１０、１１２および１１４の各々に関するデバイス固有のフォーマットまたはデバイス固有の構造で収集することができ、その後、サービスマッパ１２０が使用するための共通のスキーマに変換することができる。例えば、デバイスメタデータには、デバイス１０８、１１０、１１２および１１４の様々な技術的能力の記述を含めることができる。その記述は、以下でより詳細に説明するように、例えば、ＸＭＬ（eXtensible Markup Language）スキーマを使用することによって、ＸＭＬベースの言語で提供される。他のフォーマット、言語、および／または構造も同様に使用できることは言うまでもない。
【００２４】
より一般的には、デバイスメタデータ１３０には、例えば、デバイスの記述、ソフトウェアの記述、ハードウェアの記述、およびデバイスの状態を含めることができる。例えば、デバイスの記述には、デバイスの名前、識別子、または種類を含めることができ、あるいは、ベンダの名前またはベンダのウェブサイトなどのベンダの情報を含めることができる。ソフトウェアの記述には、バージョンおよび／またはベンダなどのオペレーティングシステムの記述を含めることができ、あるいは、デバイスのプラットフォーム上で実行されているサービスの記述、または実行が許可されるサービスの記述を含めることができる。ハードウェアの記述には、ＣＰＵ１１６の属性（例えば、名前および／または速度）、メモリ１１８の属性（例えば、メモリの総容量および／または空き容量）、または（複数の）デバイスの接続能力の属性（例えば、接続速度または接続の種類）に関する情報を含めることができる。デバイスの状態には、デバイスの位置、現在のＣＰＵ使用率、または、電力もしくはメモリの残量などの、より変化しやすい（volatile）情報を含めることができる。以下で説明するように、および／または、明らかであるように、他のデバイスの態様または情報がデバイスメタデータ１３０に含まれてもよいことは言うまでもない。例えば、デバイスメタデータ１３０には、例えばデバイス１０８がＲＦＩＤリーダを備えていた場合、他のデバイスに関する情報を含めることができ、デバイスメタデータ１３０には、ＲＦＩＤリーダが読み取り、および／または、書き込みすることができるＲＦＩＤタグの種類の記述を含めることができる。
【００２５】
サービスメタデータ１２６にも、少々類似した形で、（複数の）サービスが１つまたは複数のデバイス上で実行されるか否かと、その実行方法とに関する様々なサービスの記述および／または要件を含めることができる。例えば、サービスメタデータには、サービスの挙動の記述、サービスの技術的制約、あるいは、サービスの入力、出力、前提条件、または効果（ＩＯＰＥ）に関する情報を含めることができる。例えば、技術的制約には、必要とするＣＰＵの種類または速度、必要とする（空き）メモリ容量、必要とする、または好適な接続の種類または速度、オペレーティングシステムのバージョン／名前／記述、あるいは、バッテリまたは他のデバイスの電力源（群）の種類または状態を含めることができる。
【００２６】
したがって、デバイスメタデータ１３０と同様に、ハードウェア要件などの、静的なサービス要件と動的なサービス要件との間で、差異が生じる場合がある。例えば、（複数の）サービスの実行時に、サービスが必要とする総メモリ容量または最大処理速度などの静的な値を、利用可能なメモリ／処理／電力、および／または、当該（複数の）サービスと並行してデバイス上で実行可能な他のサービスの数または種類などの動的な値とともに含めることができる。
【００２７】
サービスメタデータ１２６の構築および使用は、（複数の）サービスが複合サービスおよび／またはアトミックサービス（atomic service）と考えられるか否かに応じて異なってもよい。アトミックサービスとは、１つのデバイス上で実行される個別のサービスを指し、複合サービスとは、１つまたは複数のアトミックサービスが含まれ、そのアトミックサービスを合成する高レベルのサービスを指す。例えば、複合サービスは、蓄積された、または集約された（複数の）機能を提供するために、所定の数または所定の種類のデバイス１０８、１１０、１１２または１１４を必要とするローカルネットワーク１０２上に配置することができる。アトミックサービスは、デバイス１０８、１１０、１１２または１１４の個々に配置されるサービス１２２などのサービスを指す。例えば、デバイス１０８、１１０、１１２および１１４は、決められた領域内に分散されてその領域の温度分布または温度勾配を判定する温度センサを備えることができる。この場合、各デバイス１０８、１１０、１１２または１１４は、温度収集サービス（例えば、デバイス１０８上のサービス１２２）を実行することができ、デバイス１０８、１１０、１１２または１１４のうちの１つまたは複数、あるいは、いくつかの他のデバイスは、デバイス１０８、１１０、１１２および１１４の全てから温度データを集約して温度分布または温度勾配に関する情報を判定する複合サービスを実行することができる。したがって、例えば、複合サービス用のサービスメタデータ１２６の一部には、複合サービスを構成するアトミックサービスに関する情報を含めることができることを理解されたい。
【００２８】
さらに、複合サービスに関して、サービスメタデータ１２６には、サービスの密度（例えば、２５ｑｍ２ごとに複合サービスを配置する）などの抽象的制約を含めることができる。この抽象的制約は、複合サービスに含まれるアトミックサービスに対する具体的要件に変換される必要がある場合もある。例えば、前述した抽象的な密度の制約が、対応する複合サービスのアトミックサービスに対する具体的要件となり、この場合、アトミックサービスは、利用可能なデバイス全体のうちの１０％に配置される。
【００２９】
したがって、所与のシステム（例えば、システム１００）の特定のコンテキストにおいて、変換プロセスを使用して、複合サービスの抽象的制約を、対応するアトミックサービスに対する具体的なサービス要件に変換することができる。このような変換プロセスは、当該システム（例えば、システム１００）に関する情報に基づいて、複合サービスの抽象的制約を判定し、抽象的制約を具体的要件に変換することができる。複合サービスのアトミックサービスが通信して協働する範囲では、全てのアトミックサービスについて、具体的な値が同一であることを保障するのは合理的であると言える。例えば、複合サービスが、２５ｑｍ２ごとに配置されるという抽象的制約に関連付けられる場合、システム情報を適用することができる。そのシステム情報として、例えば、システムのフィールドサイズが１００ｑｍ２であり、２５ｑｍ２ごとに１０個のデバイスを含み、したがって４０個のデバイスがフィールド全体をカバーするという情報が挙げられる。その結果、２５ｑｍ２ごとに複合サービスを配置するという抽象的制約は、対応するアトミックサービスの配置密度が１０％ということとなる。すなわち、この場合、４０個のデバイスのうち４つ（１０％）が、複合サービスおよび／または対応するアトミックサービスを実行し、１つのデバイスが、１００ｑｍ２のフィールド全体における５ｑｍｘ５ｑｍの各フィールド内で、そのデバイス上に配置される（複数の）サービスを有することになる。
【００３０】
より一般的には、少なくともサービスメタデータ１２６およびデバイスメタデータ１３０を使用することにより、サービスマッパ１２０は、ローカルネットワーク１０２のデバイス１０８、１１０、１１２または１１４上に所与のサービスをマッピングすることができる。このようなマッピングは、サービスメタデータ１２６およびデバイスメタデータ１３０の様々な態様の値マッチングを必要に応じて行う（例えば、サービスメタデータ１２６内で指定された必要メモリを、デバイスメタデータ１３０内で指定されたデバイスメモリとマッチングさせる）だけでなく、当該サービスの配置および実行を可能にして最適化するようにも設計されている。例えば、デバイス１０８およびデバイス１１０の両方が、名目上または表面上はサービス１２２を実行できてもよい（例えば、デバイス１０８および１１０の両方が、メモリ、処理能力、または電力の必要最小値を有してもよい）。しかしながら、サービス１２２が、メモリよりも電力をより必要とし（逆もあり得る）、デバイス１０８が、他の候補デバイス１１０と比べて、より多くの電力を現在提供することができる場合、デバイス１１０が、デバイス１０８よりも多くの空きメモリを現在提供していたとしても、サービスマッパ１２０は、サービス１２２をデバイス１０８にマッピングしてもよい。
【００３１】
より形式的には、マッチング集合を関数として表すことができる。その関数は、デバイスのセットに関するデバイスメタデータ（例えば、デバイスプロファイル）を、配置されるサービスに関するサービスメタデータ（例えば、技術的要件）と比較する。具体的には、集合Ｄｃａｐは、利用可能な個々のデバイスプロファイル「ｄ」全ての集合として定義することができ、ｓｔｅｃは、当該サービスの技術的要件を指す。すると、マッチング集合は、以下の式（１）のように定義することができる。
【００３２】
【数１】
【００３３】
したがって、集合Ｄｃａｐ内のデバイスプロファイル「ｄ」は、当該サービスの全ての技術的要件ｓｔｅｃが満たされた場合に限り、マッチング集合の要素として認められる。
【００３４】
しかしながら、上述したように、サービスメタデータ１２６の値をデバイスメタデータ１３０と単にマッチングさせるだけでは、どのマッチングまたは候補デバイスプロファイル「ｄ」が、当該サービスの機能を実行するのに品質的に最適であるかを判定するには十分ではない場合もある。例えば、デバイスメタデータの１つまたは複数の属性に数値の重みを割り当てるパフォーマンスメトリックを適用することができる。ただし、（複数の）数値の重みは、対応する属性値に基づいて、当該サービスに割り当てることができるので、例えば、数値の重みは、異なるサービスに対しては異なる場合がある（例えば、サービスに固有である場合がある）。例えば、そのようなパフォーマンスメトリックは、以下の式（２）のように表すことができる。
【００３５】
【数２】
【００３６】
式（２）において、重み値ｗ１、ｗ２、ｗ３およびｗ４は、「１」に等しいように選択されてもよいし、および／または、単位の任意の差異を考慮するために、別の方法により、正規化または修正されてもよい。
【００３７】
したがって、式（２）は、全ての利用可能なデバイス（または、式（１）のマッチング集合内の全てのデバイス）に対して適用することができ、その結果、各デバイスごとに、Ｖａｌｄの値を取得することができる。次いで、Ｖａｌｄのデバイス固有値が比較されて、当該デバイス全てに対する最大値が判定され、関連するデバイスが、サービスマッパ１２０によって選択される。このようにして、当該サービスを実行するのに利用可能な最高品質を提供するデバイスを選択することができる。
【００３８】
さらに、式（２）の例におけるパフォーマンスメトリックを拡張して、他のデバイス、または、アプリケーションに依存する問題をカバーすることができる。例えば、配置されたサービスを実行する際、所定の種類またはブランドのデバイスが、例えば、信頼性の点でいくらか有用であることが既知である場合がある。したがって、例えば、この種類またはブランドのデバイス全てに適切な重みを割り当てることができ、この種類またはブランドのデバイス全てを、式（２）のパフォーマンスメトリックまたは同様のパフォーマンスメトリックに含めることができる。
【００３９】
適切なサービスマッピングが実行されると、サービスインジェクタ１３４を使用して、デバイス１０８上にマッピングされたサービス（例えば、サービス１２２）をインストールして開始することができる。さらに、より一般的にサービスインジェクタ１３４を使用して、例えば、必要に応じて、サービスを更新または停止することによって、サービス（群）のライフサイクルを管理することができる。
【００４０】
したがって、サービスインジェクタ１３４のタスクの１つは、具体的なサービスコード（例えば、サービス実行ファイル（群）１２８のうちの適切な１つ）を、選択されたデバイス（群）に転送することである。したがって、サービスインジェクタ１３４は、当該コードを受信してインストールする。サービスインジェクタ１３４のような前述のインストールコンポーネントは、デバイス側に１つのスタンドアロンソフトウェアコンポーネントとしてインストールしてもよいし、または、サービス実行ファイル１２８を分散させるために、他のインストールコンポーネントと協働してもよい。後者の状況では、例えば、サービスマッパ１２０が、要求されたサービスのインストールに関して、選択されたデバイス全てに連絡できない場合、複数のデバイス上のサービスインジェクタは、互いに通信してインストールを遂行する。サービス実行ファイル１２８をインストールした後、サービス１２２は、サービスインジェクタが起動信号を送信してサービスをアクティブ状態に変化させるまで、非アクティブ状態を保つことができる。同様に、サービスインジェクタ１３４を使用して、サービスの更新および停止を体系化することができる。
【００４１】
サービス１２２のマッピングが実行され、サービス１２２がデバイス１０８上にインストールされて開始されると、必要に応じて、サービス１２２の実行を継続することができる。しかしながら、時間が経過すると、デバイス１０８は、ローカルネットワーク１０２内のサービス１２２を実行する最適なデバイスでなくなる場合がある。例えば、デバイス１１０は、自機のサービスの実行を停止し、それにより十分なメモリリソース、処理リソースまたは電力リソースを解放して、サービス１２２の実行に関してデバイス１０８よりも上回る場合がある。別の例として、デバイス１１２は、デバイス１０８上にサービス１２２を配置した後のある時点でローカルネットワーク１０２に参加し、サービス１２２を実行するための優位なリソースを有するデバイスであることを示す場合がある。例えば、デバイス１０８は、携帯情報端末（ＰＤＡ：Personal Digital Assistant）であり、デバイス１１２は、ＰＤＡデバイス１０８より優位なコンピューティング能力を有するラップトップであってもよい。最後の例として、デバイス１０８は、自機のリソースが欠乏し始める場合がある（例えば、バッテリ電力がほぼ放電状態の場合）。それによって、デバイス１０８は、ローカルネットワーク１０２全体としての潜在的な脆弱性を生じさせることになり、デバイス１１０、１１２または１１４のうち１つが、サービス１２２を実行する上で優位であると考えられる場合がある。
【００４２】
したがって、サービスマッパ１２０は、サービス１２２が実行されている間に、デバイス１０８などの元のデバイスから、例えばデバイス１１０といった別の選択されたデバイスに、サービス１２２を再マッピングして、削除し、再配置することができる。このように、相対的にリソース不足のデバイスから、よりパワフルなデバイスにサービスを再配置することにより、デバイスの活用を改善し、信頼性を改善することができる。以下でより詳細に説明するように、各デバイスにおける利用可能なリソースの判定は、システムモニタ１３２により実行することができ、それに応じて再マッピングの開始時間および方法に関する決定をすることができる。
【００４３】
マッピングおよび／または再マッピングを実行する際、ビジネスデータ処理システム１０４、サービスリポジトリ、システムモニタ、ローカルネットワーク１０２、または、デバイス１０８、１１０、１１２および１１４のいずれか、または全てを、ワイドエリアネットワーク１０６を介して接続された、比較的広い地理的領域にわたって分散させてもよい。ワイドエリアネットワーク１０６には、例えば、インターネット、または企業規模の専用ネットワークを含めることができる。さらに、ビジネスデータ処理システム１０４にレポートするスマートアイテムデバイスの総数によっては、サービスマッパ１２０が、このようなデバイスの全てに対するサービスマッピングプロセスの全ての段階を独立して扱うのは非実用的であるか、または望ましくないものになり得る。
【００４４】
したがって、サービスマッパ１２０のコンポーネントまたは階層を使用してもよい。そのコンポーネントまたは階層は、例えば、サービスメタデータ１２６および／またはデバイスメタデータ１３０用に使用されるセマンティックス（semantics）または記述に応じて変わり、あるいは、利用可能なコンピューティング電力に応じて変わり、あるいは、ビジネスデータ処理システム１０４、ローカルネットワーク１０２、および／またはデバイス１０８、１１０、１１２もしくは１１４に関する地理的位置に応じて変わる。例えば、グローバルサービスマッパ（ＧＳＭ：Global Service Mapper）コンポーネント１２０ａを使用することができる。そのＧＳＭコンポーネントは、ローカルネットワーク１０２と同様に、複数のローカルネットワークに共通であり、ワークステーションまたはパワフルなパーソナルコンピュータ（ＰＣ：Personal Computer）などの相対的にパワフルなコンピューティングデバイスを表す。それに対し、デバイス１０８、１１０、１１２および１１４などのデバイス、ならびにローカルネットワーク１０２（または図示していないが、他のデバイス）に固有であるローカルサービスマッパ（ＬＳＭ：Local Service Mapper）コンポーネント１２０ｂを使用することができる。ＬＳＭコンポーネント１２０ｂは、（以下でより詳細に説明する）スターゲートサーバ（Stargate sever）またはＰＤＡなどのあまりパワフルではないコンポーネントを表すことができる。最後に、ローカルネットワークにおける全てのデバイスのサブセットであるグループに関連付けられるグループリーダサービスマッパ（ＧＬＳＭ：Group Leader Service Mapper）コンポーネント１２０ｃを、ローカルネットワーク１０２内で使用することができる。したがって、ＧＬＳＭコンポーネント１２０ｃは、ローカルネットワークのデバイスの１つ（例えば、図示したように、センサノードなどのデバイス１０８）によって実装され、そのデバイスは、一般に、様々なサービスマッパコンポーネント１２０ａ、１２０ｂおよび１２０ｃのコンピューティングリソースの最小量を有する。図３を参照しながら、このような階層アーキテクチャの実装の一例を以下で例示して説明する。
【００４５】
上記の説明は、サービスマッパ１２０のための階層アーキテクチャの一例を提供することを意図したものであり、上記の階層より多数または少数の層が使用できることを理解されたい。このような階層アーキテクチャを実装することにより、例えば、以下でより詳細に説明するように、様々な特徴および利点を得ることができる。例えば、前述したように、サービスのマッピングおよび／または再マッピングをデバイスに対して、および、デバイス間で、適時に、効率的に、かつコスト効果的に、実行できることを維持しつつ、システム１００を容易に拡張して、多数のスマートアイテムデバイスをシステム１００に含ませることができる。
【００４６】
図１の例において、ＧＳＭコンポーネント１２０ａは、アーキテクチャの階層のルート（root）を構築し、サービスマッピング要求の最初の受信者としての役割を果たすことができる。例えば、ＧＳＭコンポーネント１２０ａは、（例えば、図１には示していないサービス構成モジュールなどの）外部モジュールに対するインタフェースとしての役割を果たすことができる。この外部モジュールは、マッピングプロセスを開始するために使用される。
【００４７】
ＧＳＭコンポーネント１２０ａは、一般的に、それに関連するローカルネットワーク（例えば、ローカルネットワーク１０２）に関する情報を提供する。このようなローカルネットワークの各々は、倉庫または小売店などの、物理的および／または地理的位置に関連付けられる。例えば、ＧＳＭコンポーネント１２０ａを使用して、デバイスと、提供されたサービスと、前述した、位置を含む任意のさらなるセマンティック情報（semantic information）とにしたがって、ローカルネットワークをソートすることができる。
【００４８】
例えば、ＧＳＭコンポーネント１２０ａには、ＧＳＭメタデータテーブル１３６を含めることができる。そのＧＳＭメタデータテーブル１３６は、所与のローカルネットワークにおける既存デバイスおよびデバイス能力についての情報を含むローカルネットワークデバイスの記述を格納する。例えば、ＧＳＭメタデータテーブル１３６は、所与の倉庫がその倉庫内に分散された１００個のセンサと、倉庫の従業員が使用する２０個のＰＤＡとを含むという情報を反映することができる。このようなデバイス情報の取扱いに加えて、ＧＳＭメタデータテーブル１３６は、それぞれのローカルネットワークにおいて提供されるサービスについての情報を格納および提供することができる。前述の例を続けると、ＧＳＭメタデータテーブル１３６は、（例えば、センサなどのスマートアイテムデバイスを使用して、）倉庫の温度を測定するサービスが倉庫内にインストールされているという情報を格納することができる。したがって、それらのデバイス、提供されたサービス、および、さらなるセマンティックな態様を有するローカルネットワークについての上記の情報は、１つまたは複数のデバイスに対してサービスマッピングを実行する際に使用するのに利用可能である。図４Ａを参照しながら、ＧＳＭメタデータテーブル１３６の詳細な例を提示し、以下でより詳細に説明する。
【００４９】
ＧＳＭコンポーネント１２０ａには一般的に、単体のデバイスと、その（複数の）現在の使用状況とに関する記述または情報を含める必要はなく、その代わり、ＧＳＭコンポーネント１２０ａは、抽象的なデバイスクラスと、それに関連する一般的属性の記述とを単に保持するだけでよい。したがって、個々のローカルネットワークを体系化する役割および追跡する役割を、ＬＳＭコンポーネント１２０ｂに担わせることができる。ＬＳＭコンポーネント１２０ｂは、ＧＳＭコンポーネント１２０ａよりも、その関連するネットワークデバイスに対して近くに位置する可能性が高いので、複数のＬＳＭコンポーネント１２０ｂは、様々なネットワークスマートアイテムデバイス全てが収集して分析したデータを配布する。ＧＳＭコンポーネント１２０ａと同様に、ＬＳＭコンポーネント１２０ｂには、ＬＳＭメタデータテーブル１３８を含めることができる。そのＬＳＭメタデータテーブル１３８は、各デバイスに関連付けられたサービス情報、サービス情報の品質、および、各デバイスに関するより詳細な位置情報とともに、デバイス情報を格納する。図４Ｂを参照しながら、ＬＳＭメタデータテーブル１３８の詳細な例を以下に提示する。
【００５０】
ＬＳＭコンポーネント１２０ｂが、個々のスマートアイテムデバイスに関する情報を追跡および提供することは可能であるが、図１の例は、ＬＳＭコンポーネント１２０ｂが、下位ネットワーク（例えば、ローカルネットワーク１０２）を、通常物理的に近い位置にある異種である可能性が高いデバイスのセットを含むクラスタまたはグループに分割する場合を示している。例えば、デバイス１０８、および／または、１つまたは複数のデバイス１１０、１１２および１１４、ならびに不図示の他のデバイスは、ローカルネットワーク１０２およびＬＳＭコンポーネント１２０ｂに関連付けられた１つまたは複数のグループに含めることができる。
【００５１】
図１の例において、デバイス１０８は、上記のグループに対するグループリーダとしての役割を果たし、ＧＬＳＭコンポーネント１２０ｃを含む。このようなグループ化により、デバイス１０８、１１０、１１２および１１４の状態の一部を、改善した形で制御することができる。例えば、サービスが、定義された領域内に均一に配布される必要がある場合、上記のグループ分割は有用である。例えば、配置要求または配置命令は、サービスが、ローカルネットワーク１０２のデバイス全体の１０％にインストールされるよう要求することができる。その結果、グループがローカル領域内に均一に分散する場合、その配置を、全てのデバイスに対して一度に行うのではなく、グループごとに行うことをベースにすることができ、サービス配布の役割の一部を、様々なグループリーダに割り当てることができる。
【００５２】
ＧＬＳＭコンポーネント１２０ｃおよび前述の関連デバイスのグループ化により得られる利点の別の例は、デバイスメタデータ１３０の収集に対する簡便性および効率性に関する。その収集は、例えば、システムモニタ１３２および／またはサービスマッパ１２０（これには、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂ、またはＧＬＳＭコンポーネント１２０ｃが含まれる）によって行われる。例えば、サービス配置要求の時点で、所定のデバイスの現状を複数のローカルネットワークにわたって判定する必要がある場合がある。したがって、デバイスの問い合わせは、ＧＳＭコンポーネント１２０ａにより、適切なＬＳＭコンポーネント１２０ｂに配布され、次いで、適切なＬＳＭコンポーネント１２０ｂから適切なＧＬＳＭコンポーネント１２０ｃに配布することができる。このように、グローバルシステム内の全てのデバイスに、または様々なローカルネットワーク内の全てのデバイスに、または所与のローカルネットワーク内の全てのデバイスにさえも、問い合わせる必要はない。むしろ、特別なサービスマッピングに対して実際に候補であるデバイスまたは候補の可能性があるデバイスのみに、それらの関連デバイスメタデータを提供するよう要求することができる。
【００５３】
同様に、問い合わせられたデバイス、または別の形で指定されたデバイスのモニタリングは、グローバルなレベルではなく、グループおよび／または（複数の）ローカルネットワーク層において行うことができる。例えば、システムモニタ１３２には、デバイス１０８上にインストールされたモニタコンポーネント１３２ａを含めることができる。しかしながら、他の例においては、モニタコンポーネント１３２ａは、追加で、または代替として、ＬＳＭコンポーネント１２０ｂに格納されてもよい。このようにデバイスをモニタリングすることにより、デバイスメタデータ１３０は、適時に、効率的に、かつ拡張性を有して収集することができるので、サービスマッピングまたは再マッピングに関する判定を、同様に迅速に行うことができる。
【００５４】
図１の上述の説明は、サービスメタデータ１２６およびデバイスメタデータ１３０がおそらくパフォーマンスメトリックとともに使用されて、サービスリポジトリ１２４から、１つまたは複数のデバイス１０８、１１０、１１２または１１４に対してサービスマッピングを実行する例を示しているが、このようなマッピングを実行する際、他の情報も有用であることを理解されたい。例えば、ネットワークメタデータ１４０には、様々なネットワークパラメータを含めることができる。特にこの場合、前述のパラメータは、動的であり、任意の単一のデバイスについての情報から必ずしも識別可能ではない。ネットワークメタデータ１４０のこのような例の１つとして、ローカルネットワーク１０２上で利用可能な帯域幅を挙げることができる。他の例には、ＬＳＭコンポーネント１２０ｂからのデバイスの距離（または他の位置情報）、ネットワーク全体としての可動特性、およびネットワーク接続の信頼性を記述する、ネットワークトポロジの記述が含まれる。位置の例に関して、例えば、所与のサービスを配置して、ローカルネットワーク１０２内の特定領域内に現在配置されているサービスを置き換えることができる。この場合、ローカルネットワーク１０２内のグループを、追加のネットワークパラメータとしてのグループ識別子（ＩＤ）と関連付けて、配置を、上記のグループＩＤに関して、少なくとも部分的に進めることができる。例えば、新たなサービスが、所定の時間制約内にマッピングされる必要がある場合、このようなサービスは、グループＩＤおよび関連情報に基づいて、ＬＳＭコンポーネント１２０ｂに最も近いグループ内のデバイス上に配置することができる。
【００５５】
さらに、このようなグループＩＤは同様に、他の設定においても使用することができる。例えば、グループＩＤは、当該サービスが指定された数または種類のグループのうちの少なくとも１つに配置されるというサービス要件として、サービスメタデータ１２６内で使用することができる。同様に、グループＩＤは、特定のデバイスのパラメータとして、そのデバイスに関連付けられたデバイスメタデータ１３０内で関連付けることができる。これに関して、グループＩＤは、デバイスがグループ間で割り当てられる、または再割り当てされるか否かと、その頻度とに応じて、デバイスメタデータ１３０の静的パラメータまたは動的（変化しやすい）パラメータのいずれかとして考えることができる。
【００５６】
図２Ａおよび図２Ｂは、図１のシステム１００の動作例を示すフローチャートである。詳細には、図２Ａは、システム１００のマッピング動作例を示すフローチャートである。図２Ａの例において、サービス配置に対する要求を受信する（２０２）。例えば、ユーザは、図１０と関連させて以下で述べるユーザインタフェース例などのユーザインタフェースを使用して、指定されたサービスの配置要求を入力できる。他の例においては、要求は自動化することができる。例えば、サービスの配置を要求するビジネスデータ処理システム１０４のアプリケーションから、要求を受信することができる。
【００５７】
要求に基づいて、指定されたサービスおよび関連するサービスメタデータを判定することができる（２０４）。例えば、サービスマッパ１２０、より詳細には、ＧＳＭコンポーネント１２０ａは、要求に応じてサービスリポジトリ１２４にアクセスして、要求されたサービスが利用可能か否かを判定し、関連するサービスメタデータ１２６およびサービス実行ファイル１２８を判定することができる。いくつかの例においては、複数の開発プラットフォームに対して実装することができる。例えば、同一のサービスを、Ｃプログラミング言語またはＪａｖａ（登録商標）プログラミング言語に基づく既知の開発プラットフォームに対して実装することができる。このような多様な開発プラットフォームを提供することにより、所与のサービスは、使用可能なより広範囲な、または様々な種類のデバイスに配置することができる。当該サービスの開発プラットフォーム（群）についての情報は、サービスメタデータ１２６の一種類として、例えば、図１と関連させて提示および上述したサービスを動作させるための任意の様々なサービス要件または優先度とともに、含めることができる。
【００５８】
次いで、複数のデバイスに関する現在のデバイスメタデータを取得することができる（２０６）。例えば、サービス要求は、特定のローカルネットワーク、デバイスグループ、デバイス、または様々なデバイスを指定することができる。他の例においては、サービスマッパ１２０および／またはＧＳＭコンポーネント１２０ａは、サービス要求および／または関連するサービスメタデータに基づいて、所定のデバイスまたは様々な種類のデバイスを自動的に選択することができる。デバイスメタデータ１３０を収集するために、システムモニタ１３２は、適切なデバイスに配布される１つまたは複数の問い合わせを開始することができる（その問い合わせは、おそらくサービスマッパ１２０または関連するコンポーネントから、あるいは、それらが連動して、送信される）。次いで、システムモニタ１３２は、問い合わせに応じて、デバイスメタデータ１３０を収集することができる。例えば、問い合わせを配布し、応答であるデバイスメタデータ１３０を収集するために、ＧＳＭメタデータテーブル１３６および／またはＬＳＭメタデータテーブル１３８からの情報を使用することができ、適時かつ拡張性を有するようにデバイスメタデータを収集するために、デバイスのグループを構築して、そのデバイスのグループをグループＩＤと関連付けることができる。他の例においては、デバイスメタデータ１３０は、将来のサービス要求を予測して定期的にデバイス情報を要求することにより、収集することができる。
【００５９】
少なくともサービスメタデータ１２６およびデバイスメタデータ１３０に基づいて、複数のデバイスから、選択されるデバイスを決定することができる（２０８）。例えば、どの問い合わされたデバイスがサービスを配置することが可能であるかを判定するために、サービスマッパ１２０またはコンポーネント１２０ａ、１２０ｂ、１２０ｃのうちの１つは、式（１）にしたがってマッチング動作を適用することができる。例えば、そのマッチング動作には、サービスの利用可能なプラットフォームに固有の実装（実行ファイル）（例えば、Ｊａｖａ（登録商標）ベースのサービスに対するＪａｖａ仮想マシン（登録商標））が、少なくともデバイス（群）の所与の１つで実行可能であると判定することが含まれる。または、他のデバイスの特性および能力は、配置されるサービスのサービス要件とマッチングさせることができる。次いで、式（２）に示したようなパフォーマンスメトリックを使用して、マッチングされたデバイスのうち選択されるデバイスを、配置されるサービスの最適化パフォーマンスを可能とするものとして判定することができる。前述したように、ネットワークメタデータ１４０を含む他の情報を使用して、選択されるデバイスの判定を実行することができることは言うまでもない。
【００６０】
最後に図２Ａにおいて、選択されたデバイスにサービスを配置する（２１０）。例えば、サービスインジェクタ１３４などのサービスインジェクタを使用して、選択されたデバイス（群）上でサービスを配置、インストール、および／または開始することができる。いくつかの実施形態において、サービスインジェクタ１３４は、複数のサービスインジェクタを表すか、またはこれらを含み、この場合、各サービスインジェクタは、特定の開発プラットフォームに関連付けられる。このような場合、特定の種類のサービスインジェクタの利用可能性は、デバイスメタデータ１３０内に含まれ、サービスメタデータ１２６の対応する要件とマッチングさせることができる。
【００６１】
したがって、図２Ａは、サービスを、選択されたデバイス上またはデバイスのセット上に配置するための、システム１００または関連するシステム内で実行されるサービスからデバイスへのマッピングプロセスの高レベルな記述を示している。上述したように、サービスが、すでに１つまたは複数のデバイスにマッピングおよび／または配置され、考えられ得る複数の理由により、実行されているサービスが停止され、そのサービスが現在実行しているデバイスから削除され、より好適なデバイスに再マッピングおよび再配置されるべきであると判定される場合がある。図２Ｂは、システム１００が実行できる、このような再マッピングプロセスの例を示すフローチャートである。
【００６２】
図２Ｂの例において、元のデバイス上で実行されている配置されたサービスを再配置する動機付けを判定する（２１２）。例えば、上述したように、サービス１２２は、デバイス１０８などの元のデバイス上に配置され、実行されている場合がある。次いで、システムモニタ１３２は、サービス１２２を再マッピングする動機付けを判定することに関与することができる。その動機付けには、例えば、ローカルネットワーク１０２上のデバイス１１０などの、よりパワフルな、またはより適切なデバイスの利用可能性の検出がある。例えば、このようなデバイスは、より適切なデバイス１１０がローカルネットワーク１０２の範囲に物理的に移動した結果として、またはデバイス１１０上の他の何らかのサービスが停止した結果として（それにより、デバイス１１０のリソースを解放し、サービス１２２の実行のためにデバイスが利用可能になった結果として）、利用可能となることを検出することができる。別の例において、動機付けには、元のデバイス１０８における低電力またはメモリ制限の検出を含めることができる。さらに別の例において、動機付けには、予め定められた時間の経過後にサービス１２２を再配置するようサービスマッパ１２０に命令することを含めることができる。これらの動機付けの１つまたは複数の結果として、サービス１２２がローカルネットワーク１０２の適切なデバイス上で確実に実行されることを支援する再マッピングを実行することができる。
【００６３】
十分な動機付けが判定されると、元のデバイスから、複数のデバイスの中から選択されたデバイスへの、配置されたサービスの再マッピングが実行される（２１４）。例えば、図２Ａのマッピングプロセスが実行されると、その場合、図２Ａのサービス配置要求（２０２）が再マッピングプロセスを開始する動機付けの判定に対応しており、その動機付けは、例えば、システムモニタ１３２により示されてもよいし、または判定されてもよい。さらに、図２Ｂのプロセスを「再マッピング」と呼んでいるが、元のデバイス１０８上のサービスは、必ずしも図２Ａのマッピングプロセスによって初めにマッピングされる必要がないことを理解されたい。例えば、サービス１２２は、図２Ａのマッピングプロセスを利用せずに、初めに直接的かつ明示的にデバイス１０８上にインストールされる場合もある。したがって、この意味において、再マッピングとは、サービス１２２または同様のサービスを、元のデバイスから選択されたデバイスに再配置して、元のデバイスからサービスを削除することを指す。
【００６４】
さらに、再マッピングを実行する技術には、例えば、再マッピングの動機付けに依存するものがあることを理解されたい。例えば、特定のデバイスがローカルネットワーク１０２に移動した場合、マッピングは、最初に再マッピングを開始したデバイスに対して直接実行することができる。すなわち、このようなデバイスは、サービス１２２に対して選択されるデバイス、またはサービス１２２に対する受信デバイスであると自動的に判定されることになる。他の例において、動機付けとして、元のデバイス１０８の今にも起こりそうな電力損失の検出が含まれる場合、図２Ａの完全なマッピングプロセスを実行することができる。デバイス１１０などの１つまたは複数のデバイスを含む選択されるデバイスを決定するために、例えば、完全なデバイスの問い合わせ、サービスメタデータ１２６に対する結果のデバイスメタデータ１３０のマッチング、適切なパフォーマンスメトリックの判定および適用の全てを実行することができる。
【００６５】
再マッピングが実行されると、選択されたデバイスに、配置されたサービスを再配置する（２１６）。例えば、配置されたサービス１２２は、デバイス１１０上のサービスインジェクタを使用することにより、デバイス１０８から、デバイス１１０または他の選択されたデバイス（群）に再配置することができる。図７と関連させて以下でより詳細に述べるように、このような再配置には、その再配置の直前である元のデバイス１０８上のサービス１２２の状態を維持することを含めることができる。このように、例えば、再マッピングプロセス中でも、サービスの継続性が維持される。
【００６６】
次いで、配置されたサービスを、元のデバイスから削除することができる（２１８）。例えば、デバイス１０８上のサービスインジェクタ１３４は、サービス１２２を停止し、元のデバイス１０８からサービス１２２を削除することができる。この例において、サービス１２２を元のデバイス１０８から削除することは、サービス１２２をデバイス１１０に再配置した後に実行されるものとして説明している。例えば、このことは、サービス１２２が、サービスの継続性を要求する何らかの安全機能または他のサービス（例えば、危険化学物質または危険条件をモニタリングするセンサ）を提供している場合に実行されるので、特に前述の状態を維持するとともに、（複数の）危険な条件がモニタリングされていない状態の時間はほとんどないか、または全くない。しかしながら、他の例においては、どのサービス１２２の状態も維持される必要はなく、サービス１２２のデバイス１１０への再配置と並行して、または、サービス１２２がデバイス１１０に再配置される前に、元のデバイスからサービス１２２を削除できることを理解されたい。
【００６７】
図３は、図１のシステムの３階層アーキテクチャを使用したシステム３００を示すブロック図である。すなわち、図３の例は、図１と関連させて上述したグローバル、ローカル、およびデバイス（グループ）層の使用を示している。例えば、図３は、与えられたサービス（群）および／または含まれるデバイスごとに、異なるネットワークをグループ化できるシステム１００の能力を示している。このように、広範囲に及ぶサービスを広範囲に及ぶスマートアイテムデバイスに配置して、様々なビジネス目標を達成することができる。さらに、デバイスネットワークをコミュニティに構造化することができる。
【００６８】
詳細には、図３において、グローバル層には、施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４が含まれる。図１の上述の説明から理解されるように、施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４の各々は、グローバルサービスマッパ（ＧＳＭ）コンポーネント１０２ａの実装に関連付けることができる。次いで、例えば、施設安全管理コミュニティ３０２には、危険な条件（例えば、可燃性または爆発性の物質、またはそれらの物質の組合せの存在）の判定に使用されるサービスおよびデバイスを含めることができる。一方、資産追跡コミュニティ３０４には、製品が元請／製造者から販売用に棚に置かれるまで、製品を追跡するために使用できるサービスおよびデバイスを含めることができる。このようにサービスおよびデバイスを分離することにより、企業からの情報を適切に割り振ることができ、本明細書で説明した様々なマッピングおよび再マッピングのプロシージャを効率的に実行することができる。なぜならば、例えば、施設安全管理コミュニティ３０２において有用な振動検出サービスを資産追跡コミュニティ３０４内のデバイスにマッピングしようとする際、上記のサービスが後者のコンテキストにおいて有用でないと予め知られていれば、無駄が生じないからである。
【００６９】
次に、ローカルネットワーク３０６および３０８は、図１と関連させて上述したローカル層の一部であるとみなすことができる。ローカルネットワーク３０６および３０８は、施設安全管理コミュニティ３０２に関連付けることができ、一方、ローカルネットワーク３１０は、ローカル層にあって、資産追跡コミュニティ３０４に関連付けられる。図１と関連させてすでに述べたように、ローカルネットワーク３０６、３０８および３１０の各々は、複数のデバイスに関連付けることができ、特にローカルネットワーク３０６は、デバイス３１２、３１４および３１６に関連付けることができ、ローカルネットワーク３０８は、デバイス３１８、３２０および３２２に関連付けることができる。次いで、様々なデバイスをグループ化して、図１のグループ層を形成することができ、デバイスの１つが、所与のグループのグループリーダとして選択または決定される。図３において、デバイス３１２は、デバイス３１２、３１４および３１６を含むグループのグループリーダであり、デバイス３２２は、デバイス３１８、３２０および３２２のグループリーダである。
【００７０】
一方、資産追跡コミュニティ３０４のローカルネットワーク３１０は、グループ３２４およびグループ３２６に関連付けられる。グループ３２４は、デバイス３２８（グループ３２４のグループリーダ）、３３０、３３２および３３４を含み、グループ３２６は、デバイス３３６（グループ３２６のグループリーダ）、３３８および３４０を含む。図１の上述した説明から理解されるように、ローカルネットワーク３０６、３０８、３１０には、ローカルサービスマッパ（ＬＳＭ）コンポーネント１２０ｂの実装を含めることができる。このようなＬＳＭコンポーネントには、コンピューティングデバイスまたはサーバ（例えば、ラップトップコンピュータまたはスターゲートサーバ）を含めることができる。そのコンピューティングデバイスまたはサーバは、十分なコンピューティングリソースを有し、対応するＧＳＭコンポーネントと比較して、対応するデバイスに物理的に近い位置に存在する。したがって、図３において、グループ３２４および３２６は、いくつかの実施形態において、所定のデバイス（例えば、デバイス３３０、ただし、必ずしもグループリーダデバイスではない）のみが、ＬＳＭコンポーネント１２０ｂを実行するデバイスまたはサーバに対する直接的なアクセスを有することができるということを示している。結果として、このような場合、ＬＳＭコンポーネントと、グループ３２４および３２６の他のデバイスとの間の通信は、直接接続されたデバイス３３０を介して生じさせることができる。
【００７１】
図４Ａおよび図４Ｂはそれぞれ、ＧＳＭメタデータテーブル１３６およびＬＳＭメタデータテーブル１３８の例を示すテーブルである。図４Ａにおいて、ＧＳＭメタデータテーブル１３６には、関連するローカルネットワークを識別する（例えば、ＬＳＭ１２０ｂの実装を識別する）列４０２が含まれる。例えば、図３において、列４０２により、ローカルネットワーク３０６および／またはローカルネットワーク３０８が、施設安全管理コミュニティ３０２に関連付けられたＧＳＭコンポーネント１２０ａの実装に関連付けられることを識別することができ、そのコミュニティは、列４０４において識別される。
【００７２】
次いで、列４０６を使用して、対応するデバイスメタデータファイル（例えば、定義されたＸＭＬスキーマにしたがうＸＭＬファイル）を参照することができる。そのデバイスメタデータファイルファイルは、例えば、ある能力を提供することができるＬＳＭコンポーネント１２０ｂに関連付けられたセンサを記述している。同様に、列４０８を使用して、対応するサービスメタデータファイルを参照することができ、そのサービスメタデータファイルは、当該サービス（群）の一般的性質、例えば、列４０６のセンサにより実装されている温度サービスおよび振動サービスに関する情報を含む性質を記述している。列４１０は、ローカルネットワークの位置、例えば、図示したように、「倉庫Ａ」に関する位置を提示する。したがって、デバイスメタデータ１３０およびサービスメタデータ１２６は、全ての（またはいくつかの）ローカルネットワークの全デバイスの現在の状態を保持するＧＳＭメタデータテーブル１３６を要求することなく、一般的な高レベルの方法により、ＧＳＭメタデータテーブル１３６内で参照することができる。例えば、デバイスが、移動式であるか固定式であるかなどの他の情報を、ＧＳＭメタデータテーブル１３６内に含めてもよいことは言うまでもない。
【００７３】
ＧＳＭメタデータテーブル１３６のデータファイルは、１つまたは複数のサーバ上に格納することができ、要求に応じてユーザによりロードすることができる。他の実施形態においては、ＧＳＭメタデータテーブル１３６のデータファイルは、ＧＳＭコンポーネント１２０ｂ、または管理者により自動的にロードすることができる（より一般的には、ユーザにより実行されているものとして本明細書で説明した事実上どのようなアクションも、適切なコンピューティングリソース（群）を使用して、自動的に実行できることを理解されたい）。結果として、サービスマッピング要求は、グローバル層において、適切なＧＳＭコンポーネントにルーティングすることができ、対応するＧＳＭメタデータテーブル１３６を使用して、例えば、どの関連デバイス／サービスの特性または種類が、サービスマッピング要求用であると考えられるかを判定することができる。ＧＳＭメタデータテーブル１３６、および、他のこのようなテーブルを使用することにより、利用可能なローカルネットワークおよびデバイスの全てを、継続的に縦横に検索する必要性を低減または排除することができる。
【００７４】
図４Ｂは、ＬＳＭメタデータテーブル１３８の例を示している。図４Ｂには、関連するグループ識別子を使用してデバイスのグループを識別する列４１２が含まれる。列４１４により、列４１２において識別されたグループのメンバが識別される。例えば、列４１４により、関連する（様々な）能力を有するＰＤＡおよびセンサノードが含まれる列４１２のグループを識別することができる。
【００７５】
列４１６により、列４１４のグループメンバ（デバイス）上で実行できる（様々な種類の）サービスが識別される。図４Ｂにおいて、列４１６により、ディスプレイサービスおよび温度サービスが識別される。したがって、グループは、デバイスの集合としてだけでなく、そのグループによって提供されるサービスの集合としても考えることができる。このような場合、サービスは、広い領域にわたっていても、多種多様な複数のデバイスに対しても識別される。
【００７６】
列４１８により、例えば、グループＩＤ列４１２において識別されるグループの現在のリソース使用率などの、サービス品質（ＱｏＳ）が識別される。グループの利用可能なＱｏＳを識別することにより、グループの信頼性およびパフォーマンスを認識し、評価することができる。最後に、図４Ｂにおいて、列４２０により、関連するローカルネットワーク内、例えば、図示したようなローカルネットワークの「倉庫Ａ」の「領域１」内の、識別されたグループの位置が特定される。したがって、グループの位置は、例えば、そのグループのＬＳＭコンポーネント１２０ｂに近接することができ、その結果、例えば、ＬＳＭコンポーネント１２０ｂとグループとの間の通信は、適時かつ信頼性があるものにすることができる。
【００７７】
図３、図４Ａ、および図４Ｂ、ならびに上述の説明から、ＬＳＭコンポーネント１２０ｂは、自身のローカルネットワークを体系化する役割を担うことができ、ＧＳＭコンポーネント１２０ａと、ＧＳＭコンポーネント１２０ａの、高レベルな記述、および様々な種類のデバイスならびに／またはサービスの分類の格納とは対照的に、ＬＳＭコンポーネント１２０ｂは、現実の個々のデバイスおよび／またはサービスに固有の情報を格納する役割を担うことができる。説明したように、ＬＳＭコンポーネント（群）１２０ｂは、それぞれのデバイスおよびネットワークに物理的に近くに位置することができ（例えば、そのデバイスと同一の倉庫、または同一の他の建物もしくは場所に位置することができ）、ＬＳＭコンポーネント（群）１２０ｂを使用して、ＧＳＭコンポーネント（群）１２０ａと個々のデバイスとの間の空間をブリッジ（bridge）ことができる。この方法により役割を分割させることによって、大量のデータを好適に配布することができる。
【００７８】
したがって、ＬＳＭコンポーネント１２０ｂには、対応するＧＳＭコンポーネント１２０ａに対する標準インタフェースを含めることができ、ＬＳＭコンポーネント１２０ｂは、１つまたは複数のＬＳＭコンポーネント１２０ｂのデバイスにサービスをマッピングするためのマッピング要求を、そのインタフェースを介して受信することができる。ＬＳＭコンポーネント１２０ｂには、以下でより詳細に説明するように、ゲートウェイサーバを含めることができる。
【００７９】
図４Ａおよび図４Ｂの例の域を越えて、他のパラメータおよびメタデータを、ＧＳＭメタデータテーブル１３６内および／またはＬＳＭメタデータテーブル１３８内に含めることができることを理解されたい。例えば、グループ（群）のさらなる特性を含めることができる。その特性には、例えば、各グループの規模などが含まれる。その各グループの規模として、例えば、グループリーダとグループメンバとの間の最大ホップ数、または、含めることができるグループメンバの最大数を定義するグループサイズが挙げられる。
【００８０】
図１および図３の３階層アーキテクチャの第３層（群）は、ＧＬＳＭコンポーネント１２０ｃを配置できるグループリーダ層である。したがって、グループリーダは一般的に、ローカルネットワークの専用デバイスを表し、そのデバイスは、（図１および図３に示したような、）ローカルネットワークがクラスタリングされた対応するグループの代表としての役割を果たす。図４Ｂに示したように、このようなグループリーダは、ＬＳＭコンポーネント１０２ｂに登録され（例えば、ＬＳＭメタデータテーブル１３８内に格納され）、対応する下位のデバイスクラスタからの抽象化を提供する。したがって、グループリーダを使用して、各グループメンバについての情報と、グループメンバによって提供されるサービスについての情報とを提供することができる。
【００８１】
３階層アーキテクチャの各層のセマンティック情報は、下位のモバイルアドホックネットワークに配置された軽量セマンティックオーバーレイ（light-weight semantic overlay）のビルディングブロックとみなすことができる。このようなセマンティックオーバーレイは、セマンティックに関連するサービスまたはデバイスを、サービス／デバイスの物理的位置とは無関係に、一緒にクループ化することを可能にする。例えば、グローバル（ＧＳＭコンポーネント１２０ａ）層において、物理的に分散したローカルネットワークを識別することができる。そのネットワークは、企業内で同一または類似した（複数の）役割ごとに接続されている。同様に、ローカル（ＬＳＭコンポーネント１２０ｂ）レベルのグループは、これらグループの構成デバイスおよび機能についての情報に関して、識別することができる。
【００８２】
図５は、図１および図３のシステムをそれぞれ実装するスマートアイテムインフラストラクチャ５００のブロック図である。スマートアイテムインフラストラクチャ５００は、５つの層を含む。５つの層とは、デバイス層５０２、デバイスレベルサービス層５０４、ビジネス処理ブリッジング層５０６、システム接続層５０８、および企業アプリケーション層５１０である。層５０２は、複数のグループ、ローカルネットワーク、および／または物理的位置にわたって、図１のデバイス１０８、１１０、１１２および１１４、または同様のデバイスのうちの様々なデバイスを含むものと考えることができる。一方、層５０６、５０８および５１０は、図１のビジネスデータ処理システムの一部、または、それに関連付けられるものと考えることができる。したがって、層５０４は、図１のシステム１００の残りのコンポーネント、例えば、図５に示すような、サービスマッパ１２０、およびそのコンポーネント１２０ａ、１２０ｂもしくは１２０ｃと、システムモニタ１３２、およびそのコンポーネント１３２ａと、サービスリポジトリ１２４とを表すものと考えることができる。
【００８３】
したがって、デバイス層５０２は、現実のスマートアイテムデバイスと、それらの間の任意の通信とを含む。デバイス層５０２はまた、任意の提供されたハードウェアサービスを次の高次層、すなわち、デバイスレベルサービス層５０４に提供する役割も担う。デバイスとして、例えば、ＲＦＩＤデバイス５１２、組み込みシステム５１４、センサネットワーク５１６、および、適切であれば、他の任意の新規技術または新興技術５１８を挙げることができる。
【００８４】
例えば、ＲＦＩＤデバイス（群）５１２に関して、モバイルタグを実世界の物体に取り付けることができ、モバイルタグは、ＲＦＩＤリーダによって読み取られる（および、オプションとして、モバイルタグに書き込まれる）。アクティブなタグを使用した実装において、アクティブなタグは、さらなるセンサデータ（例えば、現在値または過去値）を提供することができる。ＲＦＩＤにおいて、通信は通常、リーダによって開始されるが、タグは、互いに直接的に通信してもよいし、通信しなくてもよい。このようなＲＦＩＤリーダは、タグデータを処理する程度まで、構成することができる。例えば、ＲＦＩＤリーダは、書き込みデータの検証を行うように、または、表面上失われたタグが、実際には所与の時間ウィンドウ内に再び現れる場合、タグの消失の報告を回避するように構成することができる。
【００８５】
組み込みシステム５１４との通信技術は、組み込みシステムのデバイスの種類に応じて変えることができる。例えば、組み込みシステムは、小規模な１チップマイクロコンピュータから高機能なＰＣハードウェアに至る全てのものを表すことができる。したがって、例えば、携帯電話、またはそれ以上の能力を有する（例えば、Ｊａｖａ仮想マシン（登録商標）を実行できる）デバイスに対して、Ｊａｖａ（登録商標）を用いて、または、ＯＳＧｉ（ＯＳＧｉは、アプリケーションおよび／またはアプリケーションコンポーネントのリモートインストールおよびリモート管理用のコンポーネントモデルを実装する公知のフレームワークを表す）に基づいて、実装することができる。前述したように、センサネットワーク５１６には、任意の数の様々な種類のセンサを含めることができ、これらのセンサは、統合された処理電力を含み、ピアツーピア通信を実行することができる。
【００８６】
デバイスレベルサービス層５０４は、デバイス層５０２により使用される配置可能なサービスを管理する。したがって、層５０４には、サービスマッパ１２０（ならびにサービスマッパコンポーネント１２０ａ、１２０ｂ、および１２０ｃ）、システムモニタ１３２（およびシステムモニタコンポーネント１３２）、およびサービスリポジトリ１２４が含まれる。
【００８７】
上述したように、サービスリポジトリ１２４は、少なくとも２種類のサービス、すなわち、複合サービスおよびアトミックサービスを格納することができる。複合サービスは一般に、他のサービスに依存して、それらのタスクを遂行し、自身の直接的に実行可能なコードを有さなくてもよい。むしろ、複合サービスには、実行可能なサービス構成の記述を含めることができ、その記述は、対応するサービスの記述に格納される。したがって、複合サービスは、１つのサービス実行ファイル、すなわち、サービス構成の記述を有することができる。それに対し、アトミックサービスは一般に、他のサービスを使用せず、自身の直接的に実行可能なコードを有する。さらに、上述したように、アトミックサービスは、異なるプラットフォームに配置可能であるので、アトミックサービスは、複数のサービス実行ファイルを有することができ、例えば、異なるプラットフォームの各々に対して、１つのサービス実行ファイルを有することができる。
【００８８】
サービスリポジトリ１２４は、サービスメタデータ１２６を格納することができる。このサービスメタデータ１２６は、上記にて詳細に説明した。サービスリポジトリ１２４には、サービスの名前、識別子、バージョン、またはベンダを含めることができる。あるいは、サービスリポジトリ１２４は、例えば、技術的な配置要件（例えば、高帯域幅、または、必要とする最小処理電力）、セマンティックな要件（例えば、受信デバイスは、シリアル接続、および／または、多数の近隣デバイスを有する必要があるという要件）、および空間的な要件（例えば、受信デバイスは、地下にある、または特定ビルの南側にあるという要件）などのサービスのランタイム要件を記述することができる。
【００８９】
最後に、デバイスレベルサービス層５０４には、デバイスリポジトリ５２０を含めることができる。上述の説明から理解されるように、デバイスリポジトリ５２０には、例えば、サービスリポジトリ１２４がサービスについての情報（例えば、サービスメタデータ）を保持するのと同様に、デバイスについての情報（例えば、デバイスメタデータ）を含めることができる。例えば、デバイスメタデータは、デバイスの問い合わせ動作の結果が判定された後に、デバイスリポジトリ５２０内に格納することができる。あるいは、別の実施形態においては、デバイスメタデータは、デバイスに関する外部から利用可能な情報に基づいて、管理者により格納することができる。例えば、すでに述べたように、デバイスメタデータには、デバイスの名前、電力量、メモリ容量、処理容量、または、サービスを関連デバイスにマッピングする（および、最終的には配置する）ことに関連する他の情報を含めることができる。
【００９０】
実行時に、システムモニタ１２４は、現在のシステムの状態をモニタリングする。サービスの状態の任意の部分をシステムモニタに公開するか否か、および、その公開方法は、設計時に、サービスの開発者により設定することができる。この状態利用可能性情報は、その後、システム管理者およびサービスマッパ１２０の両方に対して利用可能となる。上述したように、サービスマッパ１２０は、配置要求を受信し、次いで、例えば、サービスメタデータをデバイスメタデータとマッチングさせることにより、どのデバイス（群）に、対応するサービスが配置されるべきかを判定する。このデバイスメタデータには、スマートアイテムデバイス、および関連するローカルネットワーク（群）の現在の状態を含めることができる。本明細書で説明したように、サービスマッパ１２０は、（システムモニタ１２４によって認識される）ネットワークの状態変化などの所定のイベントまたは条件に対応することができる。その後、サービスマッパ１２０は、サービスを再マッピングするか、あるいは、サービスのインスタンスを追加または削除するよう判定して、所与の配置要求／要件をより良く遂行することができる。
【００９１】
ビジネス処理ブリッジング層５０６には、デバイス層５０２にあるデバイスから、デバイスレベルサービス層５０４を介して提供されたデータを集約して、デバイス層５０２からのデータをビジネス関連情報に変換するよう設計されたサービスが含まれる。それを行う際、バックエンド企業アプリケーションシステムに送信されるデータ量を低減することができ、ビジネスロジックは、企業アプリケーションシステムの様々なシステムに対して実行することができる。
【００９２】
例えば、１つまたは複数のルールプロセッサ５２２を使用して、着信メッセージを解析したり、基本動作サービス（例えば、アイテムの移動、関連付け、関連付け解除、または、デバイスの読み取り／書き込み）および情報の問い合わせをサポートしたりすることができる。ルールプロセッサ５２２は、実行または参照する必要がある他の任意の基本動作サービスを定義または参照する、ユーザにより定義されたビジネスルールを処理する。このようなルールおよび基本動作サービスを使用することによって、システム５００を異なるビジネスシナリオに適合させる柔軟性のあるフレームワークが提供される。
【００９３】
ルールプロセッサ５２２は、関心のある全ての物理的な物体を追跡し続けるために、例えば、追跡している所与の物体の現在の状態、位置、タイムスタンプ、または関連するビジネストランザクションを追跡し続けるために、および、どのような将来の行動が期待されるかを追跡し続けるために、データリポジトリ５２４を使用することができる。データリポジトリ５２４からの集約された情報は、例えば、日次または月次に、定期的にレポートすることができる。
【００９４】
層５０２、５０４および５０６の動作の一例には、「商品受け取り」のシナリオが含まれる。例えば、対象物を受取人に配送する供給者は、電子製品コード（ＥＰＣ：Electronic Product Code）などの物体識別子とともに、出荷物内の全物体の一覧を含む事前出荷通知（ＡＳＮ：Advanced Shipment Notification）を送信することができる。ＡＳＮは、データリポジトリ５２４内に格納することができる。出荷物が到着し、例えば、受入ドックドアなどのデバイス層５０２にあるＲＦＩＤリーダを通過すると、ＥＰＣが、ＲＦＩＤリーダによって読み取られ、ルールプロセッサ５２２に送信される。ルールプロセッサは、メッセージの送信元であるリーダのＩＤを調べ、そのリーダの位置と役割とを判定し、次いで、受け入れた出荷物の処理責任を有する適切な基本動作サービスを呼び出す。この動作サービスは、取得したＥＰＣを、以前のＡＳＮから予想されるＥＰＣと比較する。マッチングが見つかった場合、この動作サービスは、配送が届いて完了したことを企業アプリケーション５３２にレポートする。次いで、実行された動作サービスは、データリポジトリ５２４内のデータを更新することができる。上述したサービスは、関連するメッセージを送受信するサービスとともに、サービスマネージャ５２６により管理することができる。
【００９５】
システム接続層５０８内のコンポーネントを使用して、異なるアプリケーションシステムを接続し、システムおよびデータの統合をサポートすることができる。例えば、メッセージおよびデータは、情報交換モジュールおよび情報変換モジュール５２８によって、適切なバックエンドシステムにルーティングすることができ、それにより変換されて、セマンティックに正確な統合を可能にすることができる。所与のサービスが、開発環境から、デバイスレベルサービス層５０４のサービスリポジトリ１２４に配置された場合、システム接続層５０８を使用して、メッセージルーティングおよび変換サービスに加えて、外部サービスリポジトリ５３０を用いることにより、サービス実行ファイル（群）１２８を移送することができる。
【００９６】
企業アプリケーション層５３２には、例えば、企業ビジネスアプリケーションを制御および管理する役割を担う従来の企業ＩＴシステムが含まれる。特定のビジネスプロセスをカバーする企業アプリケーションは、単一のプログラムでなくてもよく、むしろ、所望の機能を実現するために協働する様々なサービスから構成することができる。このようなサービスは、同一の企業システム、企業アプリケーション層５３２内の別の企業システム（ビジネスパートナのサイトに位置する可能性が高い）、または下位層のシステム（例えば、デバイス層５０２にあるスマートアイテムデバイス）により、提供されてもよい。
【００９７】
最後に、図５において、開発ツール５３４とは、企業アプリケーション（群）５３２および他のアプリケーション／サービスを作成するツールを指す。インフラストラクチャ５００に統合された開発環境を使用することによって、企業アプリケーション空間において公知の開発ツールと同様の方法により、基本サービスの実装をサポートすることができる。さらに、開発ツール５３４により、必要なサービスメタデータ１２６を作成することができ、加えて、既存サービスを新たなアプリケーションに組み込むことができる。さらに、開発ツール５３４により、開発者は、あるサービスをどこで実行するべきかを指定すること、個々のサービスのインスタンスを構成すること、および、サービスを所望の方法で配置することが可能となる。すなわち、開発者は、開発ツール５３４を使用して、サービスメタデータ／実行ファイル（群）５３６を開発することができ、その後、サービスリポジトリ１２４内に格納するために、および／または、同時または後でサービスマッパ１２０によりマッピング／再マッピングするために、サービスメタデータ／実行ファイル（群）５３６のうち望ましいものを提供することができる。
【００９８】
図６は、サービスからデバイスへのマッピング動作を示すフローチャート６００である。図６の例において、（サービスメタデータと、１つまたは複数のサービス実行ファイルとを含む、および／または、それらに関連付けられる）サービスが最初に開発され、サービスリポジトリ１２４に登録される（６０２）。例えば、図５の開発ツール５３４を使用して、特定の種類のプラットフォーム上での実装のために、サービス実行ファイルおよび関連するサービスメタデータを設計して構築することができる。
【００９９】
次いで、本明細書で説明したグローバルなレベルの３階層アーキテクチャにおいて、ローカルネットワークを識別することができる（６０４）。例えば、図１および図４ＡのＧＳＭメタデータテーブル１３６を判定することができ、コミュニティ情報、デバイスまたはサービス情報、位置情報、および、おそらく追加的または代替的な情報を含むローカルネットワーク情報（例えば、ＬＳＭ情報）を、そのテーブル内に格納することができる。図４Ａと関連させて説明したように、このようなグローバルなレベルの情報は、例えば、任意の特別なデバイスまたは単体のデバイスを参照することなく、デバイスの種類、機能、または、所与のローカルネットワーク（群）に関連付けられていることが既知のサービスに関して、高レベルまたは抽象的なレベルで判定および表すことができる。以下で説明するように、したがって、ＧＳＭメタデータテーブル１３６は、サービスからデバイスへのマッピングの進行の可否および方法を判定する開始点としての役割を果たす。
【０１００】
それに応じて、例えばＧＳＭコンポーネント１２０ａといったサービスマッパ１２０において、サービスマッピング要求を受信することができる（６０６）。例えば、管理者もしくは他のユーザ、または別のシステムコンポーネントは、所望のサービスを適切なローカルネットワークおよびデバイスにマッピングする目的で、ＧＳＭメタデータテーブル１３６にアクセスすることができ、その結果、所望のサービスまたはサービスの種類を識別することにより、ＧＳＭコンポーネント１２０ａにサービスマッピング要求を送信することができる。このような要求は、様々な形態をとってもよい。例えば、管理者または他のシステムコンポーネントは、明示的に識別された１つまたは複数のデバイスに特定のサービスをマッピングすることを要求することができる。あるいは、管理者または他のシステムコンポーネントは、（利用可能な）全てのデバイス上にサービスを配置することを要求することができる。管理者または他のシステムコンポーネントはまた、指定された数個または数パーセントのデバイスにサービスをマッピングおよび配置することを要求することもできる。最後に、図６の例において以下で説明するように、管理者は、例えば、図１および図２Ａと関連させて上述したようなパフォーマンスメトリックにしたがって、サービスが、所与のコンテキストに関する「最良」のデバイス（群）上で設定される必要があると指定することができる。
【０１０１】
対象となるデバイスが、サービスマッピング要求内で与えられた場合、ＧＳＭメタデータテーブル１３６を使用して、指定されたデバイスを含む全てのローカルネットワークを検出することができる。例えば、サービスを、全てのローカルネットワークにおける全てのＰＤＡに配置する必要がある場合、ＰＤＡを含む全てのローカルネットワークが検索される。したがって、ローカルネットワークの検索は、ＧＳＭメタデータテーブル１３６内にローカルネットワークに関する追加情報として保持される抽象デバイスクラスによって、サポートすることができる。
【０１０２】
他の例において、サービスの記述は、ローカルネットワークを判定する際に有用となり得る。例えば、サービスメタデータ１２６を使用することにより、すでに実行されている同様のサービスを有するコミュニティを発見し分析して、使用されている関連する（様々な）デバイスを検出することができる。例えば、施設安全管理の一部である新たなサービスを配置する必要がある場合、ローカルネットワークがコミュニティに関連付けられるので、対応する施設安全管理コミュニティ３０２を使用して、考えられ得る関連するローカルネットワーク／デバイスを検出することができる。
【０１０３】
ＧＳＭコンポーネント１２０ａに対するさらなる入力として、管理者または他のシステムコンポーネントは、所定の管理上の制約を指定することができる（６０８）。例えば、管理者または他のシステムコンポーネントは、（図１と関連させて上述したような）サービスの必要な配置密度、所定の種類のデバイスの使用、または、マッピングおよび／または配置を実現するための時間的制約を指定することができる。同様に図１と関連させて説明したように、このような抽象的な管理上の制約は、サービスがマッピングされることになるデバイスの特定のネットワークに関する具体的な制約に変換することができる（例えば、１０％のデバイス密度は、特定のローカルネットワークに関連付けられた領域内の具体的なデバイスの数に変換することができる）。
【０１０４】
次いで、サービスマッピング要求を、関連するローカルネットワークの情報と比較することができる（６１０）。例えば、サービスマッピング要求をローカルネットワーク情報と比較することは、ＧＳＭメタデータテーブル１３６のグローバル層またはグローバルなレベルにおいても、サービスマッピング要求の考えられ得る結果を著しく狭めることができる。例えば、図３に関して、サービスマッピング要求が、資産追跡コミュニティ３０４に関連付けられる場合、施設安全管理コミュニティ３０２に関連付けられたローカルネットワーク３０６、３０８は、サービスマッピング要求に対する考慮事項から取り除くことができる。同様に、デバイス、サービスまたは位置情報の列４０６、４０８または４１０により、それぞれ、考えられ得るサービス配置に関して考慮すべきローカルネットワークの数を低減することができる。
【０１０５】
したがって、サービスの配置が実現可能か否かに関する判定がなされる（６１２）。どのデバイス、サービス、または位置もサービスマッピング要求および／または管理上の制約のいずれともマッチングしない場合などのように、配置が実現可能でない場合、可能な動作が存在すれば、いくつかの動作を実行することができる（６１４）。例えば、管理者に通知されるか、または、（例えば、デバイスまたはネットワークの状態が変化して、その後配置が実現可能になる可能性を予測して）待機モードに入る。さらに、新たなサービスが提供される。例えば、サービスが新たに設計され、修正され、サービスリポジトリ１２４に（再）登録され、新たに登録されたサービスが、現行のローカルネットワークの状態と適合するようになる。
【０１０６】
しかしながら、指定されたサービスの配置に問題がないと識別された場合、サービスマッピング要求は、ＬＳＭコンポーネント１２０ｂに送信され、ＬＳＭコンポーネント１２０ｂにおいて、受信することができる（６１６）。次いで、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４への接続をオープンして、要求された（種類の）サービスに関連付けられた特定のサービスメタデータを取得することができる（６１８）。例えば、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４から、予め定められたＸＭＬスキーマを有し、かつ、例えば、サービス要件などのサービスメタデータを指定するＸＭＬドキュメントを取得することができる。
【０１０７】
次いで、グループ、および、それに関連するグループリーダを、そのグループに一意なグループＩＤにより、判定または構築することができる（６２０）。説明したように、グループは、その構成デバイスおよび／または提供される機能により、記述することができる。
【０１０８】
ローカルネットワーク内のグループ世代は、複数のメカニズムにより生じてもよい。例えば、グループは、複数のパラメータ／要件に基づいて、判定または指定されてもよい。そのパラメータ／要件として、例えば、グループメンバ（群）と、（考えられ得る）グループリーダとの間の最大ホップ数や、グループメンバの最大数が挙げられる。
【０１０９】
グループの作成中、ネットワークトラフィックを最小にしつつ、デバイスの発見を可能とする発見メカニズムを使用することができる。なぜならば、ネットワークトラフィック、および、デバイスの他の送信／受信動作は、スマートアイテムデバイスにとって重要であり、それらは、相対的に少量のコンピューティングリソースおよび電力リソースしか有さない可能性が高いからである。このようなプロセスの一部として、ローカルネットワーク上に送信され、グループの構築を意図したメッセージには、一意なグループＩＤとともに、機能的グループ属性および非機能的グループ属性の両方を含めることができる。次いで、考えられ得るグループメンバからの応答メッセージを評価して、グループを作成することができる。デバイスの中には、例えば、グループの規模または他の属性に関する制限のために、作成されるグループから除外されるものがある。このような除外されたデバイスは、同一の、または類似した方法で、別のグループ作成プロセスを開始することができ、その結果、（例えば、図３に示したように、）ローカルネットワークは、最終的にグループまたはクラスタに分割される。
【０１１０】
次いで、各グループまたは各クラスタのグループリーダが、次に示す１つまたは複数の基準、または他の基準に基づいて選択される。例えば、グループリーダを判定するために、複数のグループメンバ間で決定する際、考えられ得るグループリーダが有するリソースの豊富さを含む要素が、互いに比較され考慮される。なぜならば、例えば、グループリーダは、ＬＳＭコンポーネント１２０ｂおよびグループメンバと通信し、その結果、この通信を可能にするための十分なリソース（例えば、バッテリ、ＣＰＵ、メモリ、または帯域幅）を必要とするからである。別の例として、考えられ得るグループリーダが接続される大多数のデバイスは、その考えられ得るグループリーダが、関連するグループメンバから情報を集約する際、または関連するグループメンバに対して情報を伝達する際、より効率的に動作することを可能にすることができる。別の例として、考えられ得るグループリーダを、頻繁に、または直前に使用することにより、何らかの条件が満たされるまで、そのデバイスがグループリーダとして再度動作しないようにすることができる。
【０１１１】
グループリーダが決定されると、適切なルーティングプロトコルを選択して、考えられ得るグループメンバデバイスは、互いに適切かつ効率的に、確実に通信できるようになる。例えば、グループに、ラップトップ、ＰＤＡ、またはスマートフォンなどの異種のデバイスが含まれていたとしても、それらの間の通信は可能である必要がある。ルーティングプロトコルの例として、（デバイスの物理的位置に基づく）位置ベースのルーティングプロトコル、および／または、デバイス間の直接的な近接さに基づくトポロジベースのルーティングプロトコルが挙げられる。
【０１１２】
グループリーダ（群）が決定されると、ＬＳＭコンポーネント１２０ｂは、グループリーダ（群）に命令して、その（それらの）関連するグループ（群）のデバイスメタデータ（例えば、デバイスプロファイル）を収集するために、メッセージをグループリーダ（群）に送信することができる（６２２）。デバイスメタデータの収集は、関連するローカルネットワークとデバイスとの電力および／または通信容量を使い果たすことなくデバイスメタデータを収集することができる様々な問い合わせ技術を使用することにより、実行することができる。さらに、このような問い合わせ技術は、ローカルネットワークインフラストラクチャの考えられ得る移植性および非信頼性を考慮に入れることができる。なぜならば、例えば、新たなデバイスが、問い合わせプロセス中、ローカルネットワークに参加することもあるし、または、ローカルネットワークから離れることもからである。
【０１１３】
実行する問い合わせの種類を変えてもよい。例えば、結果の完全性に重点を置いた蓄積問い合わせ（hoarding query）を使用することができる。例えば、前述の蓄積問い合わせは、（まれであり、そのためローカルネットワーク上で簡単に識別できるデバイスを参照する）一意な問い合わせ（unique query）、または、（例えば、特定の建物内の全てのデバイスなどの、領域の全てのデバイス上でサービス配置が生じることになる問い合わせを参照する）代表的な問い合わせ（representative query）を実行することができる。
【０１１４】
これらの蓄積問い合わせとは対照的に、選択的問い合わせ（selective query）には、拡張可能で適応的なクラスタベースのデバイス検索を提供する様々な方法を含めることができる。上記のデバイス検索には、（１）要求されたデバイスが含まれる適切なクラスタの識別と、（２）優先順位の割り当て（ここで、優先順位は、グループリーダに転送する問い合わせに関する順位を評価し、どのグループから、より関連のある結果が期待されるかを示す）とを含めることができる。
【０１１５】
要求されたデバイスが含まれる適切なクラスタの識別に関して、グループメンバの絶対数は、特定のデバイスクラスに属するグループメンバの相対数とそれほど関連性はなくてもよいことを理解されたい。優先順位の割り当てに関して、グループから、ＬＳＭコンポーネント１２０ｂを実行するゲートウェイサーバまでの距離を考慮に入れることができる。すなわち、例えば、ＬＳＭコンポーネント１２０ｂにより近いグループは、データパケットをＬＳＭコンポーネント１２０ｂに送信するために、より少ないホップ数しか必要としない。さらに、比較的より大きな現在のリソース能力を有するグループが好適である。
【０１１６】
一般的にネットワーク内の全ての種類のデバイスを対象とする代表的な問い合わせに関しては、様々な方法を使用することができる。例えば、次に示す優先順位が、継続的に続行される。その優先順位とは、最多の（非特異的な）デバイスを有するグループ、データの問い合わせおよび／または取り出しの並行性、利用可能性の高い帯域幅を有するグループリーダ、最高のリソース能力を有するグループ、および、ホップ数という点でＬＳＭコンポーネント１２０ｂに近いグループである。
【０１１７】
上記の代表的な問い合わせ技術では、グループに含まれるデバイスの絶対数と関連性がある。この場合、代表的な概要が必要とされるので、特定の種類のデバイス間の差異は必要とされなくてもよい。並行性および利用可能性の高い帯域幅を使用して、考えられ得る大量のデバイスプロファイルの高速転送を可能にすることができる。また、並行性および利用可能性の高い帯域幅を使用して、モバイルネットワークおよび信頼性がないと考えられるネットワークにおける問い合わせの配布を効率的に体系化することができる。
【０１１８】
選択的問い合わせでは、期待される結果の完全性よりもパフォーマンスを対象とした類似の技術および考慮が可能である。例えば、「上位Ｎ個」（例えば、ローカルネットワーク上の１０個の最良ノード）および「最初のＮ個」（例えば、ローカルネットワーク上で発見され、ＬＳＭコンポーネント１２０ｂから所定の距離内に位置する最初のデバイス）に関する方法は、識別されたデバイスプロファイルを適切に予め選択することに依存する。
【０１１９】
一般に、これらの選択的問い合わせの例（すなわち「上位Ｎ個」および「最初のＮ個」）の両方は、１つのプロシージャにしたがうことができる。そのプロシージャでは、グループリーダが、全グループメンバからデバイスプロファイルを要求し、次いで、グループリーダが、受信した結果（すなわち、最良の「Ｎ個」のデバイスプロファイル、または最初の「Ｎ個」のデバイスプロファイルのいずれか）を予め選択する。最後に、グループリーダは、結果セットをＬＳＭコンポーネント１２０ｂに転送し、次いで、そのＬＳＭコンポーネント１２０ｂは、最良の「Ｎ個」の結果全体を選択することができる。
【０１２０】
いくつかの実施形態において、現在のデバイスの状態は、恒久的にはモニタリングされないことを理解されたい。代わりに、ローカルネットワーク、およびローカルネットワークのデバイスの現在の状態についての必要な情報は、サービスマッピング要求時に取得することができる。
【０１２１】
各グループリーダが、前述した問い合わせ技術の１つまたは複数を使用して、または他の技術を使用して、それぞれのグループデバイスに問い合わせると、グループリーダは、関連するＬＳＭコンポーネントに転送するために、収集されたデバイスメタデータ（例えば、デバイスプロファイル）をマージすることができる（６２４）。例えば、グループリーダは、その関連デバイスに関するデバイスメタデータの全てを含むＸＭＬファイルを作成することができる。
【０１２２】
このように、ＬＳＭコンポーネントは、既知のサービスメタデータを受信デバイスメタデータとマッチングさせる必要な情報を有する（６２６）。例えば、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４からサービスメタデータ１２６を取得し、前述したように、複数のデバイスに関するデバイスメタデータ１３０を受信した後、例えば、サービスメタデータ１２６のサービス要件をデバイスメタデータ１３０のデバイスプロファイルとマッチングさせることができる。例えば、サービス要件およびデバイスプロファイルが、予め定められたＸＭＬスキーマにしたがって、それぞれ、ＸＭＬドキュメントで提供される場合、例えば、メモリ、電力および処理パワーに関するパラメータおよび値を互いにマッチングさせ、当該サービスの配置を取扱うことができる少なくとも１つのグループのデバイスに関する何らかのサブセットを判定することができる。
【０１２３】
上記のマッチング動作を試みた結果、配置が実現可能でないと判定された場合（６２８）、上述した様々なオプション（６１４）の１つまたは複数が呼び出される。そのオプションには、管理者に通知すること、待機モードに入ること、少なくとも１つのデバイス上に配置することができる新たなサービスを登録すること、および／または、新たなデバイスまたはデバイス能力を提供することが含まれる。
【０１２４】
しかしながら、配置が実現可能である場合（６２８）、かつ、少なくとも最小数のマッチングするデバイスが配置に関して判定された場合、パフォーマンスメトリックを適用して、どのマッチングされたデバイスが当該サービスの機能を実行するのに最適であるかを判定することができる。例えば、上述した例のように、サービスメタデータ１２６には、サービス要件のうち所定のものの、そのサービス要件の他のものに対する相対的な重みまたは重要性に関する情報を含めることができる。次いで、これらの相対的な重みは、デバイスメタデータと比較するために、パフォーマンスメトリックに組み込むことができる。その結果、どのデバイスがそのサービスの機能を実行するのに最適であるかということにしたがって、マッチングされたデバイスを順位付けおよび／またはフィルタリングすることができる。次いで、上記の最適なデバイスを、当該サービスをそのデバイス上に配置するために、ＬＳＭコンポーネント１２０ｂによって識別し選択することができる。
【０１２５】
したがって、選択されたデバイス（群）におけるサービスの導入（これには、その実行ファイルの導入が含まれることを理解されたい）を実行することができる（６３２）。例えば、図１と関連させて説明したように、サービスインジェクタ１３４を使用して、選択されたデバイス上にサービスをインストールし、そのデバイス上でサービスを開始することができる。上述したように、サービスインジェクタ１３４は、サービスのサービス実行ファイルが含まれる開発プラットフォームとの適合性に基づいて、選択することができる。
【０１２６】
上述した、サービスからデバイスへのマッピングが実行されると、ＧＳＭテーブルおよびＬＳＭテーブルを更新することができる（６３４）。例えば、ＬＳＭコンポーネント１２０ｂおよび／またはグループリーダ（群）によって取得された情報は、ＧＳＭメタデータテーブル１３６内および／またはＬＳＭメタデータテーブル１３８内に反映することができる。例えば、ＬＳＭメタデータテーブル１３８のサービス品質の列４１８を更新して、異なるグループの各々についての新たなリソース使用率を反映することができる。別の例として、ＬＳＭメタデータテーブル１３８のグループＩＤ列４１２を更新して、上述したデバイス発見プロシージャの後に存在する新たな、および／または、様々なグループを反映することができる。
【０１２７】
図７は、図１のシステム１００における再マッピングの実装を示すブロック図である。すなわち、図２Ｂと関連させてすでに説明したように、システム１００は、再マッピングプロシージャに関与することができ、そのプロシージャは、リソース不足のデバイスから、よりパワフルなデバイスにサービスを再配置することにより、改善されたデバイスの活用を可能にする。
【０１２８】
図７において、デバイス１１０および１０８はそれぞれ、図２Ｂの再マッピングプロシージャの元のデバイスおよび選択されたデバイスとして示されている。デバイス１０８および１１０の様々な要素は、明瞭かつ簡潔にするために図７には示していないが、これらの要素には、例えば、図１のコンテキストにおいて、デバイス１０８に関して述べた様々な要素が含まれる。
【０１２９】
元のデバイス１１０は、サービス７０４、サービス７０６およびサービス７０８を格納するメモリ７０２を備えている。同様に、選択されたデバイス１０８は、メモリ１１８を備え、メモリ１１８には、サービス７１２およびサービス７１４とともに、利用可能なストレージ７１０が含まれる。
【０１３０】
システムモニタ１３２には、図７の例に示すように、システムモニタコンポーネント１３２ａおよび１３２ｂを含めることができ、それらのコンポーネントは、サービスマッパ１２０にレポートするために、現在のリソースの利用可能性、および／または、それらのそれぞれのデバイスの使用率に関する情報を検出することができる。他の実施例においては、システムモニタ１３２は、デバイス１０８、１１０から離れた位置に実装することができ、サービスマッパ１２０は、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂおよびＧＬＳＭコンポーネント１２０ｃを含むよう実装することができることは言うまでもない。
【０１３１】
したがって、図７において、モニタコンポーネント１３２ａおよび１３２ｂはそれぞれ、デバイス１０８および１１０に関するリソース使用率、および／または、利用可能性の情報を検出および提供することができる。このモニタリングされた情報に基づいて、サービスマッパ１２０は、サービス７０６を再マッピングする動機付けの存在を判定することができる。動機付けの例については、上記にて提示したが、その動機付けとしては、元のデバイス１１０のリソースレベルが相対的に、または危険なまでに低いと判定されることや、よりパワフルなデバイスまたはリソースが豊富なデバイスがローカルネットワークの範囲内に入ることが挙げられる。
【０１３２】
以下でより詳細に説明するように、図７は、サービス７０６が、元のデバイス１１０から、選択されたデバイス１０８に再マッピングされる例を提示している。一般に、このような再マッピングプロシージャの前または最中に、サービス７０６の関連するサービスメタデータを使用して、サービスマッパ１２０は、サービス７０６（または他のサービス）の移植性をチェックすることができる。例えば、サービスメタデータには、元のデバイスの位置に関する情報を含めることができる（その元のデバイスは、例えば、接続性が弱い位置にある場合、サービス７０６の移植性を制限する場合がある）。別の例として、サービスメタデータには、サービス７０６と、サービス７０６の再マッピングを防止できる元のデバイス１１０との間に存在し得る任意の依存性に関する情報を含めることができる。
【０１３３】
より一般的には、サービス７０６の移植性は、「固定」、「移植可能」、および「部分的に移植可能」として表すことができる。「固定」では、再マッピングが許可されない。「移植可能」では、サービス（および、おそらくサービスの状態）を、あるデバイスから別のデバイスに移植することができる。「部分的に移植可能」では、サービス７０６には、異なる相互作用部分を含めることができ、その部分の全てではなく、一部については、（例えば、複合サービスの場合において、）再マッピングが許可される。
【０１３４】
いくつかの実施形態において、元のデバイス１１０から、選択されたデバイス１０８へのサービス７０６の再マッピングは、例えば、図６と関連させて上述したマッピングプロセスの多くの特徴を共有することができる。したがって、図６のマッピングプロセスに追加した、または、そのマッピングプロセスを修正した再マッピングの特徴を以下でより詳細に説明する。
【０１３５】
例えば、図２Ｂと関連させて説明したように、元のデバイス１１０に関して、実行されているサービス７０６の現在の状態を保存することは必要または有用であり、図７において、メモリ７０２内に格納されたデータファイル７１６を、この目的のために使用することができる。このコンテキストでは、「状態」または「サービスの状態」という用語には、例えば、サービス７０６に関連付けられ、および／または、再マッピングプロセスの前、最中、後にサービス７０６の実行の継続を可能とする全ての関連データを含めることができる。
【０１３６】
どのデータがサービス７０６とともに移植／包含される必要があるかの判定は、例えば、サービスの種類によって異なり得る。例えば、「平均温度」のような集約サービスに関して、最後に計算された温度値を選択されたデバイス１０８に保存および送信することが合理的である場合がある。しかしながら、他の実施形態においては、平均温度サービスの温度履歴全てを送信することが合理的である場合もある。どのサービス／データが移植されるかに関する情報は、対応するサービスメタデータに含めることができる。
【０１３７】
一般に、データファイル７１６を使用して、選択されたデバイス１０８に移植される関連データを保存することができる。デバイス１１０上でサービス７０６が実行されている間、データファイル７１６に継続的にデータを書き込むことができ、それにより、履歴または他のサービスデータを再構築することが可能となる。いずれの場合においても、サービスの再マッピング時に、任意の種類の関連データをデータファイル７１６内に格納することができることを理解されたい。
【０１３８】
さらに、サービスマッパ１２０により実行される再マッピングプロシージャは、一貫性のためにサービスデータおよび／またはデバイスデータをチェックすること、および、それらをデータファイル７１６内に保存することを担当する場合がある。この場合、バッファを使用して、サービスデータの格納および送信を促進することができる。異なるサービスに対し異なるプロシージャを許可することも可能である。そのプロシージャでは、例えば、サービスの状態が可能な再配置の一部にあることを、サービスのサービスメタデータ内に定義することができる。
【０１３９】
いくつかの実施形態において、サービス７０６（例えば、サービス実行ファイル）は、元のデバイス１１０から、選択されたデバイス１０８に直接移植することができる。他の実施形態においては、サービス７０６は、元のデバイス１１０のメモリ７０２内のサービスマッパ１２０により識別することができ、次いで、選択されたデバイス１０８のメモリ１１８上への導入のために、サービスリポジトリ１２４からアクセスすることができる。
【０１４０】
いくつかの例において、再マッピングは、異なる種類のデバイス間で実行することができる。例えば、元のデバイス１１０には、ＰＤＡを含めることができ、選択されたデバイス１０８には、ラップトップコンピュータを含めることができる。このような柔軟性は、適切なサービス実行ファイルを選択することにより得ることができ、そのサービス実行ファイルは、データファイル７１６内で発見されたサービスメタデータを解釈できなければならない。この意味におけるサービスメタデータの解釈には、対応するデータ型をサポートするためのサポート情報を含めることができ、データを表現する異なる機会を含めることができる。例えば、ラップトップは通常、ＰＤＡディスプレイよりも大きな、かつ、高解像度のディスプレイサイズを有する。ＰＤＡから送信されるデータは、例えば、データグラフといった、より洗練された表示形式で表示することができる。さらに、データ格納フォーマットおよび／またはデータ格納技術は、特定のデバイスの種類に固有である。例えば、あるデバイスは、ファイルフォーマット／システムを使用することができ、一方、別のデバイスは、バイナリフォーマット／システムを使用することができる。
【０１４１】
したがって、いくつかの実施形態において、サービスの再マッピングは、同一の予め定められたクラスまたは種類のデバイス間でのみ許可される。他の実施形態においては、変換サービス（図示せず）を使用することができる。その変換サービスは、所与のサービス状態データを、選択されたデバイス１０８がサポートする適切なデータフォーマットに変換する。例えば、このような変換サービスは、選択されたサービス実行ファイルのサービスメタデータを使用して、どのデータ変換が必要であるかを識別することができる。
【０１４２】
図８は、図２Ｂにしたがう再マッピング動作を示すフローチャート８００である。図８において、元のデバイス上で実行されている配置されたサービスを再マッピングする動機付けを判定する（８０２）。例えば、上述したように、デバイスが、メモリまたは電力などの何らかのリソースを使い果たす寸前である（または必要とする最小レベル未満になる）場合がある。図７を参照すると、いくつかの実施形態では、動機付けを判定することには、元のデバイス１１０上で実行されているモニタコンポーネント１３２ｂにおいて動機付け（例えば、低レベルのメモリまたは電力）を検出することを含めることができる。そのモニタコンポーネントは、デバイスのリソースが不足した場合、サービスマッパ１２０に警告または通知を送信することができる。
【０１４３】
あるいは、ネットワーク全体のためにより良くリソースを利用するために、新たな、または変更されたデバイスの状態により、上記の再マッピングが可能になるか、または強制される。新たなデバイスの状態には、自身が新たなサービス提供者として役立つ１つまたは複数の新たなパワフルなデバイスを含めることができる。その後、相対的にパワフルでないデバイス上で実行されているサービスは、ネットワーク内でより良い負荷分散を実現するために、より能力のあるそのデバイスに転送することができる。
【０１４４】
再マッピングの動機付けの別の例には、指定された間隔内にグローバルなモニタリングの一部として再マッピングを行う命令が含まれる。その命令は、例えば、ＧＳＭコンポーネント１２０ａおよび／またはＬＳＭコンポーネント１２０ｂによって開始することができる。上記のグローバルなモニタリングは、他の定義されたシステム制約が違反されたか否かに基づいて、これらの場合における動機付けを判定することができる。例えば、所定のデバイスグループは、例えば、グループメンバが下回るべきではないバッテリの閾値などの所定の不変条件にしたがうのが望ましく、このような不変条件は、システム制約として使用される。例えば、他のグループよりも不可欠な機能（すなわち、より重要なサービス）を表すグループが、ローカルネットワーク１０２内にいくつか存在してもよい。その結果、上記のグループに対して安定した環境を保証するために、前述したバッテリの閾値などの可能な不変条件を、上記の重要なグループに対して定義することができる。
【０１４５】
さらに、異なるサービス品質（ＱｏＳ）属性を、１つまたは複数のグループに対して定義することができ、これらのＱｏｓ属性を、一定の間隔でモニタリングすることができる。これらの実施形態において、所定のＱｏｓ属性に違反することは、再マッピングの動機付けとなり得る。モバイル無線ネットワークのコンテキストにおいて、Ｑｏｓは、サービスレベル属性またはリソースレベル属性のいずれかを指すことができる。サービスレベルでは、信頼性およびパフォーマンスを挙げることができ、一方、リソースレベルでは、ＣＰＵ負荷、メモリ、帯域幅およびバッテリレベルなどの要素が、代表的な属性を表す。一般的に、実行されているサービスの信頼性またはパフォーマンスは、現在のリソース能力に大きく左右される。例えば、より低いバッテリ状態は、近い将来のデバイス不良の可能性を増大させ、そのため、関連するサービスの予想される信頼性の減少に対応する。
【０１４６】
適切な動機付けが判定されると、再マッピングされるサービスに関連付けられたサービスメタデータを判定し（８０４）、複数のデバイスの各々について、現在のデバイスメタデータも判定する（８０６）。例えば、サービスメタデータ１２６は、サービスリポジトリ１２４から判定することができ、デバイスメタデータ１３０は、上記にて提示した様々なサービスからデバイスへのマッピング例のコンテキストで説明した、様々なデバイス検索、グループリーダの形成、および／または、プロファイル問い合わせ、および／または、転送技術を使用して、判定することができる。
【０１４７】
このような技術は、必要に応じて修正されてもよいことは言うまでもない。例えば、サービス７０６が、ローカルネットワーク１０２内でのみ再マッピングされることが許可される場合、（例えば、ＧＳＭメタデータテーブル１３６を使用して、）他のローカルネットワークの検証を行う必要はない。別の例において、再マッピングの動機付けには、新たなデバイスが、ローカルネットワーク１０２に入ることが含まれる場合がある。この場合、その新たなデバイスに関するデバイスメタデータのみが収集される必要がある。したがって、例えば、ＬＳＭコンポーネント１２０ｂは、関連するローカルネットワークのグループリーダから、１つまたは複数のデバイスの集約されたデバイスプロファイル（群）を受信することができる。
【０１４８】
さらに、存在すれば、再マッピングの記述を適用する（８０８）。再マッピングの記述とは一般的に、サービスの技術的要件を指し、その技術的要件は、再マッピングが生じる前に満たされることが必要とされる。このような再マッピングの記述には、例えば、元のデバイスへの初期のサービスマッピングの要件、上述したようなグループの不変条件、または位置の制約を含めることができる。例えば、初期のマッピングが、パフォーマンスメトリックにしたがって最良のデバイスを選択することを必要としなかった場合、図８の再マッピングプロセスは、上記のパフォーマンスメトリックの適用を試みることができる。別の例として、初期グループ内でのサービスの再マッピングの失敗が、結果として、最も近いグループのデバイスへのサービスの移植をもたらす場合、位置の制約を使用することができる。
【０１４９】
次いで、サービスメタデータおよびデバイスメタデータに基づいて、選択されるデバイスを決定することができる（８１０）。例えば、サービスメタデータおよびデバイスメタデータのＸＭＬファイル内において同様にタグ付けされたデータアイテム間で、マッチング動作を実行することができる。さらに、マッチング動作が完了した後、パフォーマンスメトリックにしたがって、サービスを実行するのに最適なマッチングしたデバイスからデバイスを選択するために、パフォーマンスメトリックを適用することができる。
【０１５０】
すでに説明したように、新たなパワフルなデバイスが、ローカルネットワークに入って再マッピングをトリガするときのように、例えば、最初の再マッピングの動機付けの判定に基づいて、選択されるデバイスの存在が、表面上はすでに知られている可能性がある場合があることを理解されたい。このような場合、選択されるデバイスを決定することは、新たに利用可能となったデバイスのデバイスメタデータにマッチング動作および／またはパフォーマンスメトリックを適用することを指すと、さらに考えることができる。なぜならば、考えられ得る再マッピングの動機付けを判定することは、その再マッピングの実際の実現可能性または望ましさを保証するのに十分でない場合があるからである。例えば、デバイスは、多くのメモリおよび／または電力が利用可能な状態でネットワークに入ることができるが、再マッピングを妨害し得る何らかの他の非適合性を有する（例えば、利用可能なサービス実行ファイルがないオペレーティングプラットフォーム／オペレーティングシステムを提供するのみである）場合がある。
【０１５１】
元のデバイス上に存在する現在のサービスの状態を、判定および格納することができる（８１２）。例えば、図７において、サービス７０６の現在の状態は、データファイル７１６内に格納される。サービスの状態には、例えば、最も直近に収集されたデータ、最も直近に計算されたデータ分析、または最近更新されたサービスの履歴を含めることができる。
【０１５２】
次いで、任意の再マッピングルールを判定および適用することができる（８１４）。このコンテキストにおいて、再マッピングルールとは一般に、システムの安定性、パフォーマンス、および／または信頼性を維持するために、許可された再マッピングを別の方法で防止するルールのことを指す。例えば、このようなルールの１つにより、特定のデバイスまたはデバイスのペアに関して実行できる再マッピングの回数または頻度を制限することができる。例えば、デバイス１０８が、サービス７０６の再マッピング用の十分なメモリ空間を提供する場合、後続の再マッピングプロセスが、デバイス１１０上の十分なメモリを解放して、またデバイス１１０にサービス７０６を再マッピングする動機付けの判定をトリガすることになる。すなわち、再マッピング動作そのものが、後続の再マッピングをトリガする。したがって、これにより、交互に続く再マッピングのループが生じ得る。
【０１５３】
したがって、再マッピングルールの最初の例は、デバイスメタデータ（例えば、デバイスプロファイル）の順序に基づくことができる。例えば、式（２）に類似した重み付けされたメトリックを使用して、すなわち、重み付けされたリソース属性に基づいて、各デバイスプロファイルに数値を割り当てることができる。次いで、再マッピングプロセスが頻繁に変わる問題を解決するために、元のデバイスの計算値と、選択されたデバイスの計算値との間に生じる差異が、何らかの定義された閾値より大きい場合に限り、再マッピングを実行する再マッピングルールを作成することができる。したがって、この閾値に応じて、元のデバイスより非常に優位なリソース能力を有する１つまたは複数のデバイスが利用可能である場合に、再マッピングを開始することになる。
【０１５４】
再マッピングルールの２番目の例において、各デバイスが再マッピングプロセス（群）に関与する頻度を判定することができる。次いで、交互に続く再マッピングを回避するために、元のデバイスは、所定の規定された時間が経過した場合に、再び対象のデバイスまたは選択されたデバイスになることができる。したがって、全てのデバイスは、そのデバイスが再マッピングプロセスに関与した最後の時間を示すローカルタイマを有することができる。他の実施形態においては、ＬＳＭコンポーネント１２０ｂにより、１つまたは複数のグローバルタイマを実装することができる。そのタイマは、ローカルネットワークにおける１つまたは複数のグループの、１つまたは複数のデバイスに適用される。このようなタイマは通常、各再マッピングの後にリセットすることができる。
【０１５５】
他の再マッピングルールを定義および実装できることは言うまでもない。さらに、上述した２つのルールの例の組合せを含む、これらの再マッピングルールの様々な組合せを使用することができる。
【０１５６】
再マッピングルールが満たされた場合、選択されたデバイスにサービスを再配置することができる（８１６）。例えば、ＬＳＭコンポーネント１２０ｂは、上述したように、例えば、適切なサービスインジェクタを使用して、サービスリポジトリ１２４から、選択されたデバイスにサービス実行ファイルを転送することができる。
【０１５７】
ＬＳＭコンポーネント１２０ｂはまた、例えば、データファイル７１６を使用して、サービスの状態の転送を開始することもでき、例えば、再び適切なサービスインジェクタを使用して、選択されたデバイス上のサービスを開始することができる（８１８）。最後に、図８において、ＬＳＭコンポーネント１２０ｂは、元のデバイス上のサービスに対して、停止命令を送信することができる（８２０）。いくつかの実施形態において、元のデバイス上のサービスを実際に停止することは、送信が完了した後に実現することができる。例えば、上述したように、危険な状況を検出または回避するために使用されるサービスは、再マッピングまたは再配置されたサービスが選択されたデバイス上のその新たな位置から制御を受け継ぐ準備ができるまで、継続することが要求される。
【０１５８】
図９〜図１７は、上述した、サービスからデバイスへのマッピング技術および／または再マッピング技術の様々な例を提示している。図９は、３階層サービスマッパ１２０をＯＳＧｉ実装したクラス図のブロック図であり、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂ、および、（図１のＧＬＳＭコンポーネント１２０ｃを実行する）デバイス１０８を含む。
【０１５９】
図９の例において、図示したコンポーネントの各々に対する適切なデバイスの例を、以下でより詳細に説明する。ＯＳＧｉバンドルは、各々のデバイス上にインストールされ、ＯＳＧｉ環境によって管理される。したがって、バンドルは、互いに通信して、本明細書で説明したサービスからデバイスへのマッピング（および／または再マッピング）を実装することができる。
【０１６０】
より詳細には、図９の例において、ＧＳＭコンポーネント１２０ａは、インストールされたＧＳＭバンドル９０２を実行するラップトップコンピュータによって実装することができる。ＧＳＭバンドル９０２は、ＪＳＰ（Java Server Page：登録商標）を呼び出すことによって、サービスマッピングおよびサービス配置の開始を管理する。ＪＳＰ（登録商標）は、ウェブサーバ上で動的なウェブページを生成する公知技術の一例であり、ＧＳＭメタデータテーブル１３６を表示する（図１０および図１７を参照しながら、以下でより詳細に説明する）。上述したように、この実装は単に１つの例にすぎず、他の実装においては、サービスマッピングは、例えば、ＧＳＭコンポーネント１２０ａに関連付けられたアプリケーションプログラムインタフェース（ＡＰＩ：Application Program Interface）を使用して、別のシステムコンポーネントからの呼び出しによって開始されてもよいことは言うまでもない。ＧＳＭバンドル９０２を使用して、サービスからデバイスへのマッピングの結果に基づいて、ＧＳＭメタデータテーブル１３６を更新することもできる。
【０１６１】
図９におけるＬＳＭコンポーネント１２０ｂは、ＧＳＭコンポーネント１２０ａより少ない計算リソースしか有さなくてもよいゲートウェイサーバとすることができる。ＬＳＭコンポーネントは、インストールされたＬＳＭバンドル９０４を有するゲートウェイとしての役割を果たす。そのＬＳＭバンドル９０４は、ＧＳＭコンポーネント１２０ａからサービスマッピング要求を受信し、次いで、サービスからデバイスへのマッピングを実行する。詳細には、ＬＳＭバンドルは、サービスからデバイスへのマッピング要求を転送し、ローカルネットワーク（のグループ）内のデバイスのデバイスプロファイルを収集し、デバイスプロファイルまたは他のデバイスメタデータをサービスメタデータ（例えば、要件）とマッチングさせることができる。したがって、ＬＳＭバンドル９０４は、デバイスグループ（群）のグループリーダ（群）に、プロファイルが必要であることを通知し、ＧＳＭコンポーネント１２０ａにマッチング動作の結果を通知し、ＬＳＭメタデータテーブル１３８を更新することもできる。
【０１６２】
図９におけるデバイス１０８には、インストールされたグループリーダバンドル９０６を実行するＰＤＡが含まれる。グループリーダバンドル９０６は、グループデバイスのプロファイルまたは他のデバイスメタデータを問い合わせ／検索し、そのプロファイルを単一のメッセージにマージし、そのプロファイルを含むそのメッセージをＬＳＭコンポーネント１２０ｂに送信することができる。グループリーダバンドル９０６は、例えば、ＬＳＭメタデータテーブル１３８内に含めるために、グループ情報を更新することもできる。
【０１６３】
最後に、図９において、デバイス１１０は、グループリーダ１０８からのプロファイルの要求を受信し、その要求に対して適切なプロファイルをもって応答するグループメンバとして示されている。デバイス１１０は、マッピングまたは再マッピングされているサービスを最終的に受信し、このようなマッピングおよび再マッピングの結果は、グループリーダデバイス１０８に同様に報告することができることは言うまでもない。
【０１６４】
図１０は、サービスからデバイスへのマッピングを開始する前のＧＳＭテーブルの例を示すスクリーンショット１０００である。図１０の例において、上述したように、スクリーンショット１０００は、ＪＳＰ（登録商標）ページ（または、任意の種類の対話ツール）を表すことができ、ＪＳＰ（登録商標）上では、管理者または他のユーザは、最初にデバイスの種類を検索することができ、すでにインストールされたサービスは、識別されたローカルネットワーク内に存在し得る。例えば、ＧＳＭメタデータテーブル１３６は、図３の施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４の両方についての情報を含むものとして示される。
【０１６５】
したがって、例えば、管理者は、例えば、利用可能なデバイスを選択するためのドロップダウンリスト１００２、および／または、利用可能なサービスを選択するためのドロップダウンリスト１００４を使用して、ＧＳＭメタデータテーブル１３６のデバイスおよび／またはサービスを選択することができる。上記の選択リストは、（異なるローカルネットワーク内の）企業内に存在する利用可能な全てのデバイスと、サービスリポジトリ１２４内に格納された全てのサービスとを示すことができる。したがって、管理者は、様々な種類の、サービスからデバイスへのマッピングを選択することができる。例えば、管理者は、リスト１００２において選択されたデバイスの種類（例えば、ＰＤＡ）の全デバイス上で、サービスマッピング／サービス配置を開始することもできるし、特定の種類のデバイスのうち利用可能な最良のデバイス上に、選択されたサービスを配置することもできる。
【０１６６】
最初の例において、サービスマッパ１２０は、「チェックおよび配置」ボタン１００６を選択したことに応答して、選択されるサービスの技術的要件が、現在のデバイス能力によって満たされるか否かを調べることができる。２番目の例において、サービスマッパは、管理者が「最良のデバイスをチェックおよび配置」ボタンを選択したことに基づいて、利用可能なリソースに関して最もパワフルなデバイスを検出することができる。最後に、図１０において、リセットボタン１０１０により、管理者は、スクリーンショット１０００のＪＳＰ（登録）のフィールドをリセットすることができる。「配置に関する通知」フィールド１０１２は、配置後（および／または試みた配置）の情報（図１６において示す例）を管理者に提供する。明らかなように、ローカルネットワーク、デバイス、および／またはサービスの説明した識別は、管理者により手動で実行することもできるし、または自動プロセスの一部として実行することもできる。
【０１６７】
管理者が、ボタン１００６または１００８を選択することにより、サービスからデバイスへのマッピングを開始すると、サービスの名前、デバイスの種類、および配置モード（例えば、いくつかのデバイス、全てのデバイス、または最良のデバイス（群））などの入力パラメータが、ＬＳＭコンポーネント１２０ｂに転送される。次いで、ＬＳＭバンドル９０４は、これらの入力パラメータを受信し、サービスリポジトリ１２４への接続をオープンして、そのサービスの技術的要件に関する情報が含まれる対応するサービスメタデータ（例えば、サービス記述ファイル）を取り出す。
【０１６８】
図１１は、上記のサービスメタデータファイル１１００の例である。詳細には、図１１は、ＸＭＬファイル（「ｓｅｒｖｉｃｅ．ｘｍｌ」）を示している。このＸＭＬファイルでは、セクション１１０２により、そのファイルがサービスメタデータ（例えば、サービス要件）記述ファイルであると識別される。ファイルの残りの部分にあるセクション１１０４には、図示するように、メモリ、ＣＰＵ、バッテリ、プラットフォーム、および接続特性を含むサービスパラメータに関する様々な要件が含まれる。図１２は、図１１のサービスメタデータファイルの特定インスタンス１２００の例である。図１１には、特定のパラメータが、様々なサービス要件に対して示されている。したがって、図１２は、図１のサービスメタデータ１２６のインスタンスの特定の例として理解されたい。詳細には、例えば、セクション１４０２により、３００ＭＢというメモリ要件、２００ＭＨｚというＣＰＵ速度、および、図示した他のパラメータに関して対応する指標が指定される。その他のパラメータは、バッテリ寿命、プラットフォーム情報、および接続特性に関する。図示した記述ファイルは、ＸＭＬファイルとして示されているが、他の種類のファイルフォーマットおよび／または表現フォーマットを使用してもよいことを理解されたい。
【０１６９】
ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂが、サービス記述ファイル（例えば、図１２に示すファイル）を受信して保存した後、上述した、様々なサービスからデバイスへのマッピング動作（例えば、図２Ａおよび図６）を実行してもよい。例えば、メッセージを、グループリーダデバイス１０８に送信することができ、そのグループリーダデバイスは、グループメンバデバイスのデバイスメタデータ（例えば、デバイスプロファイル）全てを収集し、そのプロファイルを単一のＸＭＬファイル（ｐｒｏｆｉｌｅｓ．ｘｍｌ）にマージすることができる。このＸＭＬファイルは、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに返送される。図１３は、上記のＸＭＬファイルの部分的な例１３００である。図１３において、最初のセクション１３０２により、そのファイルがデバイスメタデータ（例えば、デバイスプロファイル）記述ファイルであると識別される。ファイルの残りの部分にあるセクション１２０４には、デバイスの記述（例えば、名前、種類、またはベンダ）、およびハードウェアの記述（例えば、ＣＰＵの記述、接続特性、およびメモリの記述）を含むサービスパラメータに関する様々な要件が含まれる。前述したように、図１３は、部分的な例であり、上記の説明から、様々な他のデバイス特性がデバイスプロファイル内に含まれてもよいことを理解されたい。例えば、図１４は、図１３のデバイスプロファイルの完全な例である特定インスタンス１４００を示しており、記述部１４０２、ハードウェア記述部１４０４、ソフトウェア記述部１４０６、およびデバイス状態部１４０８を含む。図示したように、これらの部分１４０２〜１４０８の各々には、図１と関連させて上記にて提示した例に対応する様々なデバイスパラメータ、または他のデバイスパラメータを含めることができる。したがって、図１４は、図１におけるデバイスメタデータ１３０のインスタンスの特定の例として理解されたい。
【０１７０】
ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、現在のデバイス能力の全てを含むデバイスメタデータＸＭＬファイルを受信した後、デバイスメタデータファイルをサービスメタデータファイルとマッチングさせることができる。例えば、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、両方のＸＭＬファイル、すなわち、図１３のｓｅｒｖｉｃｅ．ｘｍｌファイル、および、図１５のｐｒｏｆｉｌｅｓ．ｘｍｌを解析することができる。次いで、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、サービスの技術的要件を、現在のデバイスリソースと比較することができる。例えば、ｓｅｒｖｉｃｅ．ｘｍｌ内に含まれる＜ｍｅｍｏｒｙ＞タグの値は、ｐｒｏｆｉｌｅｓ．ｘｍｌファイル内に含まれる対応する＜ｍｅｍｏｒｙ＞タグの値と比較されることになる。
【０１７１】
最後に、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、ラップトップ／ＧＳＭコンポーネント１２０ａに、要求されたサービスを配置できるデバイスについての情報を通知する。利用可能なデバイスがない場合、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、サービスの技術的要件を満たす利用可能なデバイスがないことを、ラップトップ／ＧＳＭコンポーネント１２０ａに通知することができ、例えば、利用可能なメモリが十分にないといった、そのサービスをその特定のデバイス上に配置できない具体的な理由を提供することができる。
【０１７２】
例えば、図１０に関して、管理者は、倉庫内にある商品の現在の温度を示す温度サービスをＰＤＡ上に配置したいと望む場合がある。この例において、倉庫内には、５個のＰＤＡがあるとする。管理者は、図１０のスクリーンショット１０００のＪＳＰ（登録商標）にアクセスして、リスト１００２および１００４をそれぞれ使用することにより、デバイス（群）およびサービスを選択することができる。次いで、管理者は、「チェックおよび配置」ボタン１００６を選択することができる。
【０１７３】
結果として、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、すでに説明したように、図１５のログウィンドウ１５００に提示されている上記のパフォーマンスの結果を用いて、実行することができる。詳細には、セクション１５０２は、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂが、サービスリポジトリ１２４にアクセスして、図１２に示したようなサービスメタデータ（例えば、要件）ファイルを取得することを示している。セクション１５０４において、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、図１４に示したようなグループ内の各デバイスに関するデバイスメタデータ（例えば、デバイスプロファイル）を取得する命令を含むメッセージをグループリーダデバイス１０８に送信し、次いで、そのメッセージが保存される。
【０１７４】
次いで、セクション１５０６においてマッチング動作を実行し、この例では、そのマッチング動作において、サービスのメモリ要件をデバイス特性とマッチングさせる。図示するように、５つのチェックされたデバイスプロファイルのうち４つが十分なメモリを有し、５番目のデバイス（ＰＤＡ）は、十分なメモリを有していない。したがって、図１６において、スクリーンショット１０００のＪＳＰ（登録商標）の更新バージョンであるスクリーンショット１６００が示され、そのスクリーンショット１６００において、「配置に関する通知」フィールド１０１２により、サービスが、５つのデバイスのうち４つにインストールされ、５番目のデバイスは十分なメモリを有さなかったことが、管理者に通知される。
【０１７５】
上記では、１つの例しか提示されていないが、多数の他の例が可能であることは言うまでもない。例えば、管理者は、５つの利用可能なＰＤＡのうち、最良のＰＤＡ上にのみサービスを配置することを望む場合もある。この場合、管理者は、単に、「最良のデバイスをチェックおよび配置」ボタン１００８を選択することができ、現在の例においては、サービスマッパ１２０が、最多メモリ容量を有するＰＤＡを識別して、そのＰＤＡにサービスを配置することになる。
【０１７６】
図１７は、再マッピング動作を実行するためのスクリーンショット１７００である。詳細には、図１７は、ＪＳＰ（登録商標）が使用される例を示しており、そのＪＳＰ（登録商標）には、再マッピングプロセスを決定する再マッピングルールを識別するためのフィールド１７０２が含まれる。さらに、フィールド１７０４を使用して、デバイスの種類を識別し、フィールド１７０６を使用して、デバイスの特性を識別し、フィールド１７０８を使用して、そのルールのパラメータ（群）の閾値を識別する。フィールド１７１０は、そのルールの実装を説明するコメント用の領域を提供する。この場合、そのルールは、ネットワーク／グループ内のＰＤＡのメモリが、指定されたパラメータ閾値３０ＭＢに達した場合に、再マッピングを実行することを明示している。すなわち、例えば、そのルールは、システムモニタコンポーネントが、５つの利用可能なＰＤＡのうちの１つまたは複数のＰＤＡが、指定されたサービスをそのＰＤＡ上に（再）配置するために、少なくとも３０ＭＢのメモリを提供できるか否か、および、いつ提供できるかを判定できることを明示している。スクリーンショット１７００において、保存ボタン１７１２により、管理者は、表示されたルールを保存することができ、リセットボタン１７１４により、管理者は、スクリーンショット１７００のフィールド１７０２〜１７１０の内容をリセットすることができる。最後に、「ルールを表示」ボタン１７０６により、管理者は、以前に作成された１つまたは複数の任意のルールを見ることができる。さらに、すでに述べたように、ＧＳＭコンポーネント１２０ａのＡＰＩを使用することにより、図１７と関連させて上述した１つまたは複数の様々な機能は、人間のユーザによってではなく、システムコンポーネントによって実行することができる。
【０１７７】
図２Ｂおよび図８と関連させてすでに説明したように、再マッピング中、再マッピングプロセスは、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂによりサポートすることができる。例えば、再マッピングを可能にするため、ＬＳＭバンドル９０４は、管理者が任意の再マッピングルールを定義したか否かを監視するように設計された制御スレッドを開始することができる。新たなルールが管理者によって設定された場合、スレッドは、それを受信して保存する。サービスの再マッピングを実行する必要がある場合、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、相対的にリソース不足なデバイスから、相対的にリソース豊富なデバイス（例えば、現在利用可能な最もリソース豊富なデバイス）にサービスを再配置することができる。
【０１７８】
グループリーダデバイス１０８が、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂから要求を受信すると、グループリーダデバイス１０８は、関連するグループのデバイスプロファイル全てを収集し始める。この例においては、グループには、４つの他のグループメンバが含まれるので、グループリーダデバイス１０８は、グループメンバにメッセージを送信することができ、グループメンバの各々は、それに対して、対応するデバイスメタデータ（例えば、デバイスプロファイル）をもって応答することができる。
【０１７９】
すでに説明したように、次いで、グループリーダデバイス１０８は、送信されてきたデバイスプロファイルを受信し、それらを（例えば、図１３のｐｒｏｆｉｌｅｓ．ｘｍｌメッセージフォーマットにしたがう）単一のＸＭＬファイルにマージすることができる。全てのプロファイルが受信されてマージされると、グループリーダデバイス１０８は、収集したデバイスプロファイルをゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに送信することができる。
【０１８０】
ＰＤＡバンドル９０６は、追加で、または代替として、デバイスの状態を監視する制御スレッドを開始してもよい。したがって、新たなデバイスがネットワークに参加した場合、このスレッドにより、グループリーダデバイス１０８に通知することができる。例えば、上記の新たなデバイスは、「ｈｅｌｌｏメッセージ」をデバイス状態スレッドに送信するよう要求される。グループリーダデバイス１０８が、上記の新たなグループメンバを認識した場合、（新たなプロファイルを含む）デバイスプロファイルを収集するための収集プロセスを開始することができる。次いで、グループリーダデバイス１０８は、マージしたプロファイルを、（上述したように）ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに送信することができ、その結果、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、次いで、再マッピングを実行する必要があるか否か、および、再マッピングの方法を判定することができる。
【０１８１】
マージされたデバイスプロファイルを受信する際、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、本明細書で説明したマッチング動作を実行することができ、適切なパフォーマンスメトリックを実装することができる。次いで、少なくとも１つのデバイスがパラメータの閾値（群）にマッチングし、その結果、再マッピングルール（群）が満たされると仮定すると、本明細書で説明したように、関連するサービスを再マッピングおよび再配置することができる。
【０１８２】
本明細書で説明したように、アーキテクチャのフレームワークと、サービスからデバイスへのマッピングアルゴリズムとにより、適切なスマートアイテムデバイスに対する自動的でインテリジェントなサービスのマッピングが可能となる。マッピングメカニズムは、サービスのセマンティックス（例えば、メモリまたはＣＰＵパワー、期待される入力／出力、挙動および可能な他の特性などの技術的要件）と、利用可能なデバイス（例えば、メモリ、ＣＰＵ、およびバッテリ寿命、ならびに信頼性といった観点における技術的能力）との洗練された記述に基づく。配置される所与のサービスに関して、この知識に基づいて、サービスマッパは、そのサービスをホストすることができるデバイスの候補を識別する。次いで、サービスおよびデバイスの技術的要件および特性にそれぞれ基づいて、（例えば、処理能力およびメモリ能力の点で）最もコスト効率のよいデバイスが、自動的な配置のために選択される。
【０１８３】
本明細書で説明した様々な技術の実施形態は、デジタル電子回路、もしくはコンピュータハードウェア、コンピュータファームウェア、コンピュータソフトウェア、またはそれらの組合せを用いて実装することができる。また、これらの実施形態は、コンピュータプログラム製品、すなわち、情報キャリア内で具現化されたコンピュータプログラムとして、実装することもできる。その情報キャリアとして、例えば、データ処理装置により実行するための、または、データ処理装置の動作を制御するためのマシンが読取り可能な記憶デバイスまたは伝播信号が挙げられる。そのデータ処理装置として、例えば、プログラマブルプロセッサ、１つのコンピュータ、または複数のコンピュータが挙げられる。上述したコンピュータプログラム（群）などのコンピュータプログラムは、コンパイル言語またはインタプリタ言語を含む任意の形態のプログラミング言語を用いて記述することができ、スタンドアロンプログラム、または、コンピュータ環境において使用するのに適したモジュール、コンポーネント、サブルーチン、もしくは他のユニットなどの任意の形態で配置することができる。コンピュータプログラムは、１つのサイトにある１つのコンピュータ上もしくは複数のコンピュータ上、または多数のサイトに分散されて通信ネットワークを介して相互接続された１つのコンピュータ上もしくは複数のコンピュータ上で実行するために配置することができる。
【０１８４】
方法のステップは、１つまたは複数のプログラマブルプロセッサにより実行することができる。そのプログラマブルプロセッサは、入力データに対して操作を行い、出力を生成することにより、関数を実行するコンピュータプログラムを実行する。フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または特定用途向け集積回路（ＡＳＩＣ：Application-Specific Integrated Circuit）のような特定用途向け論理回路により、方法のステップが実行されてもよいし、その特定用途向け論理回路として、装置が実装されてもよい。
【０１８５】
コンピュータプログラムの実行に適したプロセッサには、例えば、汎用マイクロプロセッサおよび特定用途のマイクロプロセッサの両方、および任意の種類のデジタルコンピュータにおける１つまたは複数の任意のプロセッサが含まれる。一般に、プロセッサは、ＲＯＭ（Read Only Memomy）、ＲＡＭ（Random Access Memory）、または、それら両方から、命令およびデータを受信する。コンピュータの要素には、命令を実行するための少なくとも１つのプロセッサと、命令およびデータを格納するための１つまたは複数のメモリデバイスとを含めることができる。コンピュータには一般に、例えば、磁気ディスク、光磁気ディスク、または光ディスクなどの、データを格納するための１つまたは複数の大容量記憶デバイスを含めることができるし、あるいは、コンピュータは一般に、そのデバイスに対してデータを送受信するために動作可能なように結合することができるし、あるいは、その両方が可能である。コンピュータプログラムの命令およびデータを具現化するのに適した情報キャリアには、あらゆる形態の不揮発性メモリが含まれる。その不揮発性メモリには、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクまたは取外し可能なディスクなどの磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクが含まれる。プロセッサおよびメモリは、特殊目的の論理回路により補完されてもよいし、特殊目的の論理回路に組み込まれてもよい。
【０１８６】
ユーザとの対話を提供するために、実施形態は、例えば、ユーザに情報を表示するためのＣＲＴ（Cathode Ray Tube）モニタまたはＬＣＤ（Liquid Crystal Display）モニタなどのディスプレイデバイス、ならびに、ユーザがコンピュータに入力を提供できるキーボードや、例えば、マウスまたはトラックボールなどのポインティングデバイスを有するコンピュータ上で実装することができる。同様に、ユーザとの対話を提供するために、他の種類のデバイスを使用してもよい。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックなどの任意の形態の感覚フィードバックとすることができる。ユーザからの入力は、音響入力、会話入力、または触覚入力などの任意の形態で受信することができる。
【０１８７】
実施形態は、例えばデータサーバのようなバックエンドコンポーネント、例えばアプリケーションサーバのようなミドルウェアコンポーネント、例えばユーザが実施形態と対話できるウェブブラウザ、もしくはグラフィカルユーザインタフェースを有するクライアントコンピュータのようなフロントエンドコンポーネント、または、上記のバックエンドコンポーネント、ミドルウェアコンポーネント、フロントエンドコンポーネントの任意の組合せが含まれるコンピューティングシステムを用いて実装することができる。コンポーネントは、例えば通信ネットワークのような任意の形態のデジタルデータ通信媒体を介して相互接続することができる。通信ネットワークの例には、ＬＡＮ、および、例えばインターネットなどのＷＡＮが含まれる。
【０１８８】
説明した実施形態の特徴を、本明細書で例示したが、多数の変形形態、置換形態、変更形態および均等形態が、当業者には思い浮かぶであろう。したがって、添付の特許請求の範囲は、上記の変形形態および変更形態の全てを、本発明の実施形態の要旨の範囲内に包含するよう意図するものであることを理解されたい。
【図面の簡単な説明】
【０１８９】
【図１】スマートアイテムデバイスに関して、サービスからデバイスにマッピングするシステムを示すブロック図である。
【図２Ａ】図１のシステムの動作例を示すフローチャートである。
【図２Ｂ】図１のシステムの動作例を示すフローチャートである。
【図３】図１のシステムの３階層アーキテクチャを使用するシステムを示すブロック図である。
【図４Ａ】グローバルサービスメタデータを示す表である。
【図４Ｂ】ローカルサービスメタデータを示す表である。
【図５】図１および図３のシステムを実装するスマートアイテムインフラストラクチャを示すブロック図である。
【図６】サービスからデバイスへのマッピング動作を示すフローチャートである。
【図７】図１のシステムにおける再マッピングの実装を示すブロック図である。
【図８】図２Ｂにしたがう再マッピング動作を示すフローチャートである。
【図９】図１および／または図７のシステムの実装例を示すブロック図である。
【図１０】人間のユーザが対話的にサービスからデバイスへのマッピング要求を指定するサーバページのスクリーンショットを示す図である。
【図１１】サービスメタデータを表すファイルフォーマット例を示す図である。
【図１２】図１１の形式を使用したサービスメタデータファイル例を示す図である。
【図１３】デバイスメタデータを表すファイルフォーマット例を示す図である。
【図１４】図１３の形式を使用したデバイスメタデータファイル例を示す図である。
【図１５】サービスからデバイスへのマッピング要求の結果を示すスクリーンショットを示す図である。
【図１６】サービスからデバイスへのマッピング要求の結果を示すサーバページのスクリーンショットを示す図である。
【図１７】再マッピングプロシージャの一部を示すスクリーンショットを示す図である。
【符号の説明】
【０１９０】
１０８、１１０、１１２、１１４、３１２〜３４０ デバイス
３１２、３２２、３２８、３３６ グループリーダデバイス
１０２、３０６、３０８、３１０ ローカルネットワーク
１０６ ワイドエリアネットワーク
１２０ サービスマッパ
１２０ａ グローバルサービスマッパコンポーネント
１２０ｂ ローカルサービスマッパコンポーネント
１２０ｃ グループリーダサービスマッパコンポーネント
１２２、７０４〜７１４ サービス
１２４ サービスリポジトリ
１２６ サービスメタデータ
１３０ デバイスメタデータ
１３２ システムモニタ
１３２ａ、１３２ｂ モニタコンポーネント
【技術分野】
【０００１】
本発明は、ユビキタスコンピューティング技術に関する。
【背景技術】
【０００２】
スマートアイテム技術には、例えば、無線周波数識別（ＲＦＩＤ：Radio-Frequency IDentification）システム、組み込みシステム、センサモート（sensor mote）、および／または、センサネットワークが含まれ、スマートアイテム技術を使用して、例えば、実世界データへの高速アクセスをビジネスソフトウェアアプリケーションに対して提供することができる。例えば、スマートアイテム技術を使用して、ＲＦＩＤタグの検出、読み取り、または書き込みをサポートすることでき、さらに、無線センサネットワークと組み込みシステムとの通信、および、それらの制御をサポートすることができる。多くの例において、スマートアイテムは、ローカルな処理パワー、メモリ、および／または通信能力を有するデバイスを含むことができる。そのデバイスは、デバイスに関するデータおよび特性、またはスマートアイテムデバイスの現在の状態もしくは環境についての情報を提供することができる。したがって、そのようなデバイスの中には、バックエンドまたは下位のビジネスアプリケーションのサービスコンポーネントを実行するのに使用することができ、特に、例えば、モバイルアドホックネットワークを形成して、ビジネスデータを収集、処理、または送信することにより、それを協調して行うことができるものもある。
【０００３】
スマートアイテムデバイスの例として、ＲＦＩＤタグがある。ＲＦＩＤタグは、受動型または能動型のものがあり、実世界の物体に取り付けて、その物体に関する製品情報または取扱い情報を提供するために使用できる。スマートアイテムデバイスの他の例には、例えば、環境センサ（温度センサ、湿度センサ、または振動センサ）等の様々なセンサがあり、前述したように、これらは、１つまたは複数のセンサネットワークを形成して、通信することができる。これら、および他の種類のスマートアイテムデバイスにはまた、組み込みシステムも含まれる。その組み込みシステムは一般に、特殊用途プロセッサおよび／またはプログラムを含む任意のシステムを指し、ならびに／あるいは、そのシステムは、制御されているデバイス内にカプセル化される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ビジネス業務に関する正確かつ適時なデータをビジネスに提供し、そのビジネス業務の能率化および自動化を支援する技術が必要とされている。自動的でリアルタイムな物体追跡能力および検出能力を用いることにより、スマートアイテム技術によって、コスト削減および新たなビジネス上の利益（例えば、資産可視化の進展、応答性の改善、およびビジネス機会の拡大）を得ることができる。
【課題を解決するための手段】
【０００５】
一般的な一側面にしたがうと、サービスが判定され、そのサービスが、そのサービスを記述するためのサービスメタデータに関連付けられる。複数のデバイスの各々に関連付けられたデバイスメタデータが判定され、サービスメタデータおよびデバイスメタデータに基づいて、複数のデバイスから、選択されるデバイスが決定される。
【０００６】
実施形態には、次のうちの１つまたは複数の特徴を含めることができる。例えば、サービスの判定において、サービスのマッピング要求を受信することができ、および／または、そのサービスは、元のデバイス上で現在実行されているサービスと判定することができる。
【０００７】
サービスの判定において、サービスの実行ファイル、および、そのサービスのサービスメタデータを、サービスリポジトリから判定することができる。さらに、サービスを実行するためのサービス要件は、サービスメタデータから判定することができる。後者の例において、サービス要件を判定することには、次のうちの１つまたは複数のことを含めることができる。それらは、サービスの挙動を判定すること、抽象的な技術的制約を判定すること、具体的な技術的制約を判定すること、抽象的な技術的制約と具体的な技術的制約との間の変換を判定すること、入力／出力の制約を判定すること、前提条件を判定すること、効果を判定すること、静的なハードウェア要件を判定すること、動的なハードウェア要件を判定すること、処理特性を判定すること、メモリ特性を判定すること、電力特性を判定すること、実行プラットフォームを判定すること、またはネットワーク特性を判定することである。
【０００８】
デバイスメタデータを判定することには、次のことを含めることができる。それらは、複数のデバイスからなる少なくとも１つのグループを定義すること、そのグループのグループリーダデバイスを定義すること、および、そのグループリーダデバイスに命令してグループに問い合わせ、グループ内の各デバイスに関するデバイスメタデータを取得して、グループに関する取得したデバイスメタデータを転送することである。さらに、デバイスメタデータを判定することには、複数のデバイスに問い合わせて、各デバイスのデバイス特性を判定することを含めることができる。後者の例において、複数のデバイスに問い合わせることには、次のうちの１つまたは複数を含むデバイス特性を判定することを含めることができる。それらは、デバイスの記述、デバイスの名前、デバイスの識別子、デバイスの種類、デバイスのベンダ、ソフトウェアの記述、オペレーティングシステムの記述、サービス、ハードウェアの記述、プロセッサの記述、接続の記述、接続の速度、接続の種類、メモリの記述、総メモリ量、空きメモリ量、デバイスの状態、または実行プラットフォームである。
【０００９】
複数のデバイスから選択されるデバイスを決定することには、サービスメタデータとデバイスメタデータとの間で対応する要素をマッチングさせることを含めることができる。さらに、複数のデバイスから選択されるデバイスを決定することには、サービス要件を複数のデバイスの各々の対応するデバイス特性とマッチングさせることと、サービスに関連付けられた重み付け式（weighted formula）をデバイス特性に適用して、各デバイスに関連付けられた少なくとも１つの値を取得することと、その少なくとも１つの値に基づいて、選択されるデバイスを選択することとを含めることができる。
【００１０】
複数のデバイスから選択されるデバイスを決定することには、それらのデバイスの少なくともいくつかを含むネットワークに関連付けられたネットワークメタデータを判定することと、そのネットワークメタデータに基づいて、選択されるデバイスを決定することとを含めることができる。そのネットワークメタデータには、次のうちの１つまたは複数が含まれる。それらは、利用可能な帯域幅、送信特性、ネットワークプロトコル、または現在のネットワークパラメータである。さらに、複数のデバイスから選択されるデバイスを決定することには、サービスの配置を要求するユーザが提供する管理上のシステム制約を判定することと、選択されたデバイス上に配置するために、その管理上のシステム制約を変換することとを含めることができる。
【００１１】
また、サービスは、選択されたデバイス上にインストールされたサービスインジェクタにそのサービスを提供することにより、選択されたデバイスに配置することができる。
【００１２】
別の一般的な一側面にしたがうと、システムは、サービスのサービス要件を記述するサービスメタデータと関連させて少なくとも１つのサービスを格納することができるサービスリポジトリと、複数のデバイスの各々に関連付けられ、デバイスのデバイス特性を提供するデバイスメタデータを判定することができるサービスマッパとを備える。そのサービスマッパは、さらに、サービス要件とデバイス特性との対応する要素のマッチングに基づいて、複数のデバイスのうちの選択されたデバイスに対して、その選択されたデバイスに配置するために、サービスをマッピングすることができる。
【００１３】
実施形態には、次のうちの１つまたは複数の特徴を含めることができる。例えば、複数のデバイスと、その複数のデバイスのうちの少なくともいくつかを含むネットワークに関連付けられたネットワークメタデータとのうちの少なくとも一方をモニタリングすることができるシステムモニタを含めることができる。
【００１４】
サービスマッパには、ローカルネットワークの特性にしたがってセンサネットワークのローカルネットワークをソートすることができるグローバルサービスマッパコンポーネントと、少なくとも１つのローカルネットワークに関連付けられ、複数のデバイスからなるグループをソートすることができるローカルサービスマッパコンポーネントと、少なくとも１つのグループのグループリーダに関連付けられたグループサービスマッパコンポーネントとを含めることができる。サービスマッパは、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、およびグループサービスマッパコンポーネントを使用して、デバイスの問い合わせを配布することにより、デバイスメタデータを判定することができる。サービスマッパは、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、またはグループサービスマッパコンポーネントを使用して、サービスメタデータを選択されたデバイスとマッチングさせることにより、サービスをマッピングすることができる。サービスマッパはさらに、上記の配布に応じて、グローバルサービスマッパコンポーネント、ローカルサービスマッパコンポーネント、およびグループサービスマッパコンポーネントのうちの少なくとも１つを更新することができる。
【００１５】
サービスマッパは、パフォーマンスメトリックをマッチングの初期結果集合に適用した結果に基づいて、選択されるデバイスを決定することができる。そのパフォーマンスメトリックには、サービスの実行に対する各要素の相対的な重要度に基づいて要素を重み付けすることが含まれる。デバイスには、例えば、ＲＦＩＤリーダ、センサネットワーク内のデバイス、センサモート、または組み込みシステムデバイスなどの、１つまたは複数のスマートアイテムデバイスを含めることができる。
【発明を実施するための最良の形態】
【００１６】
図面を参照しながら、以下において、１つまたは複数の実施形態を詳細に説明する。他の特徴は、その説明および図面、ならびに特許請求の範囲から明らかとなるであろう。
【００１７】
図１は、スマートアイテムデバイスに関して、サービスからデバイスにマッピングするシステム１００のブロック図である。図１の例において、様々なスマートアイテムデバイスを含むローカルネットワーク１０２は、ワイドエリアネットワーク１０６（これは、ローカルエリアネットワークまたは他の種類のネットワークを、追加で、または代替として含んでもよい）を使用して、１つまたは複数のビジネスデータ処理システム１０４に、正確かつ適時に実世界データを提供する。例えば、ローカルネットワーク１０２には、スマートアイテムデバイス１０８、１１０、１１２および１１４を含めることができ、それらを本明細書では、「スマートアイテムデバイス」、または、単に「デバイス」と呼ぶ。それらのデバイスには、（実世界の物体に関連付けられたＲＦＩＤタグを読み取るための）ＲＦＩＤリーダ、様々な組み込みシステム、および／または、様々な種類のセンサ、および／または、センサモートを含めることができる。
【００１８】
図１において、デバイス１０８は、中央処理装置（ＣＰＵ）１１６およびメモリ１１８を備えるものとして示されている。したがって、デバイス１０８は、様々なレベルのコンピューティング能力を有することができるものと理解されたい。そのコンピューティング能力には、例えば、（デバイス１０８がセンサを備えていた場合、）検出したデータの処理や送信が含まれる。明瞭にするために、図１に具体的には示していないが、デバイス１１０、１１２および１１４もまた、同様の、または異なるコンピューティング能力を有することができるものと理解されたい。そのコンピューティング能力には、例えば、無線ネットワークおよび／またはピアツーピアネットワークなどのローカルネットワーク１０２を形成する能力、および、そのネットワークに参加する能力が含まれる。
【００１９】
したがって、ローカルネットワーク１０２を使用して、ビジネスデータ処理システム１０４にとって有用となり得るデータを収集、処理、フィルタリング、集約、または送信することができる。例えば、ビジネスデータ処理システム１０４には、在庫管理システム、サプライチェーンマネジメントシステム、小売店管理システム、倉庫管理システム、および、実世界の物体に関するビジネス処理の実行に使用できる任意の他のシステム（群）を含めることができる。このような実世界の物体には、例えば、販売用製品、パレットまたは他の出荷に関わる要素、患者、または製造資材／製造機器を含めることができる。このような実世界の物体を追跡および分析することにより、ビジネスデータ処理システム１０４を使用して、例えば、在庫レベルの判定、価格レベルの設定、マーケティング戦略の評価、製造技術または生産技術の評価、盗難の低減、または安全の維持が可能となる。
【００２０】
ローカルネットワーク１０２のデバイス１０８、１１０、１１２および１１４のようなスマートアイテムデバイスを含むことにより、（複数の）データ収集プロセスにおいて、非常に迅速に処理を実行することができるので、ビジネスデータ処理アプリケーション１０４にかかる負荷を軽減または排除することができる。例えば、ビジネスデータ処理アプリケーション１０４は、企業の本社に配置することができ、ローカルネットワーク１０２は、ワイドエリア（またはローカルエリア）ネットワーク１０６を介して接続された、広範囲の地理的領域にわたって分散する可能性のある多数の（様々な種類の）デバイスネットワークのうちの１つを表すことができる。したがって、例えば、ビジネスデータ処理システム１０４は、ネットワーク１０２（および関連するネットワーク）を介して収集されたデータの所定のサブセットまたは特性を要求するだけでよく、全ての収集データを必要としないし、全ての収集データを要求しなくてよい。
【００２１】
いくつかの実施形態において、ビジネスデータ処理システム１０４には、明確に定義された（複数の）タスクを実行するために設計された再利用可能なソフトウェアコンポーネントまたはサービスから構成される複合アプリケーションあるいは合成アプリケーションを含めることができる。また、これら、または他の実施形態において、ビジネスデータ処理システム１０４には、データ収集デバイスと（または、他のビジネスデータ処理システムと）容易に通信することができないレガシーアプリケーションを含めることができ、その場合、サービスまたはサービスコンポーネントを、レガシーアプリケーションと、データ収集デバイスおよび／または他のシステムとの間のインタフェースとして提供することができる。システム１００により、これら、および他のアプリケーション、ならびにサービスを、デバイス１０８、１１０、１１２および１１４上に直接配置することができるので、例えば、適時に、効率的に、確実に、自動的に、コスト効率良く、および拡張性を有するように、サービスをそのデバイス上で実行（ならびに、データを収集および／または処理）することができる。したがって、例えば、ビジネス処理を個々のサービスに分解し、異なるデバイスに配置することができる。
【００２２】
システム１００には、図示するように、サービス１２２を配置するために、デバイスのネットワーク１０２に存在する複数のデバイス１０８、１１０、１１２および１１４の中から選択されるデバイスとして、デバイス１０８を選択することができるサービスマッパ１２０が含まれる。その過程において、サービスマッパ１２０は、ローカルネットワーク１０２および／または他のネットワーク（図１には図示せず）内での実行に適する複数のサービスを格納することができるサービスリポジトリ１２４にアクセスする。サービスマッパ１２０は、実際のサービス実行ファイル１２８とともに、サービスメタデータ１２６を判定し、サービスメタデータ１２６を、複数のデバイス１０８、１１０、１１２および１１４の各々に関連付けられたデバイスメタデータ１３０と比較する。少なくともサービスメタデータ１２６およびデバイスメタデータ１３０に基づいて、サービスマッパ１２０は、（サービス実行ファイル１２８を含む）サービス１２２を配置するのに特に適しているものとして、デバイス１０８を選択することができる。
【００２３】
例えば、デバイスメタデータ１３０には、各デバイスの記述を含めることができ、その記述は、オントロジおよび／またはスキーマにしたがって構築される。そのオントロジおよび／またはスキーマは、サービスマッパ１２０にとって既知であり、様々なデバイス１０８、１１０、１１２および１１４に共通するものである。追加で、または代替として、デバイスメタデータ１３０は、例えば、システムモニタ１３２により、デバイス１０８、１１０、１１２および１１４の各々に関するデバイス固有のフォーマットまたはデバイス固有の構造で収集することができ、その後、サービスマッパ１２０が使用するための共通のスキーマに変換することができる。例えば、デバイスメタデータには、デバイス１０８、１１０、１１２および１１４の様々な技術的能力の記述を含めることができる。その記述は、以下でより詳細に説明するように、例えば、ＸＭＬ（eXtensible Markup Language）スキーマを使用することによって、ＸＭＬベースの言語で提供される。他のフォーマット、言語、および／または構造も同様に使用できることは言うまでもない。
【００２４】
より一般的には、デバイスメタデータ１３０には、例えば、デバイスの記述、ソフトウェアの記述、ハードウェアの記述、およびデバイスの状態を含めることができる。例えば、デバイスの記述には、デバイスの名前、識別子、または種類を含めることができ、あるいは、ベンダの名前またはベンダのウェブサイトなどのベンダの情報を含めることができる。ソフトウェアの記述には、バージョンおよび／またはベンダなどのオペレーティングシステムの記述を含めることができ、あるいは、デバイスのプラットフォーム上で実行されているサービスの記述、または実行が許可されるサービスの記述を含めることができる。ハードウェアの記述には、ＣＰＵ１１６の属性（例えば、名前および／または速度）、メモリ１１８の属性（例えば、メモリの総容量および／または空き容量）、または（複数の）デバイスの接続能力の属性（例えば、接続速度または接続の種類）に関する情報を含めることができる。デバイスの状態には、デバイスの位置、現在のＣＰＵ使用率、または、電力もしくはメモリの残量などの、より変化しやすい（volatile）情報を含めることができる。以下で説明するように、および／または、明らかであるように、他のデバイスの態様または情報がデバイスメタデータ１３０に含まれてもよいことは言うまでもない。例えば、デバイスメタデータ１３０には、例えばデバイス１０８がＲＦＩＤリーダを備えていた場合、他のデバイスに関する情報を含めることができ、デバイスメタデータ１３０には、ＲＦＩＤリーダが読み取り、および／または、書き込みすることができるＲＦＩＤタグの種類の記述を含めることができる。
【００２５】
サービスメタデータ１２６にも、少々類似した形で、（複数の）サービスが１つまたは複数のデバイス上で実行されるか否かと、その実行方法とに関する様々なサービスの記述および／または要件を含めることができる。例えば、サービスメタデータには、サービスの挙動の記述、サービスの技術的制約、あるいは、サービスの入力、出力、前提条件、または効果（ＩＯＰＥ）に関する情報を含めることができる。例えば、技術的制約には、必要とするＣＰＵの種類または速度、必要とする（空き）メモリ容量、必要とする、または好適な接続の種類または速度、オペレーティングシステムのバージョン／名前／記述、あるいは、バッテリまたは他のデバイスの電力源（群）の種類または状態を含めることができる。
【００２６】
したがって、デバイスメタデータ１３０と同様に、ハードウェア要件などの、静的なサービス要件と動的なサービス要件との間で、差異が生じる場合がある。例えば、（複数の）サービスの実行時に、サービスが必要とする総メモリ容量または最大処理速度などの静的な値を、利用可能なメモリ／処理／電力、および／または、当該（複数の）サービスと並行してデバイス上で実行可能な他のサービスの数または種類などの動的な値とともに含めることができる。
【００２７】
サービスメタデータ１２６の構築および使用は、（複数の）サービスが複合サービスおよび／またはアトミックサービス（atomic service）と考えられるか否かに応じて異なってもよい。アトミックサービスとは、１つのデバイス上で実行される個別のサービスを指し、複合サービスとは、１つまたは複数のアトミックサービスが含まれ、そのアトミックサービスを合成する高レベルのサービスを指す。例えば、複合サービスは、蓄積された、または集約された（複数の）機能を提供するために、所定の数または所定の種類のデバイス１０８、１１０、１１２または１１４を必要とするローカルネットワーク１０２上に配置することができる。アトミックサービスは、デバイス１０８、１１０、１１２または１１４の個々に配置されるサービス１２２などのサービスを指す。例えば、デバイス１０８、１１０、１１２および１１４は、決められた領域内に分散されてその領域の温度分布または温度勾配を判定する温度センサを備えることができる。この場合、各デバイス１０８、１１０、１１２または１１４は、温度収集サービス（例えば、デバイス１０８上のサービス１２２）を実行することができ、デバイス１０８、１１０、１１２または１１４のうちの１つまたは複数、あるいは、いくつかの他のデバイスは、デバイス１０８、１１０、１１２および１１４の全てから温度データを集約して温度分布または温度勾配に関する情報を判定する複合サービスを実行することができる。したがって、例えば、複合サービス用のサービスメタデータ１２６の一部には、複合サービスを構成するアトミックサービスに関する情報を含めることができることを理解されたい。
【００２８】
さらに、複合サービスに関して、サービスメタデータ１２６には、サービスの密度（例えば、２５ｑｍ２ごとに複合サービスを配置する）などの抽象的制約を含めることができる。この抽象的制約は、複合サービスに含まれるアトミックサービスに対する具体的要件に変換される必要がある場合もある。例えば、前述した抽象的な密度の制約が、対応する複合サービスのアトミックサービスに対する具体的要件となり、この場合、アトミックサービスは、利用可能なデバイス全体のうちの１０％に配置される。
【００２９】
したがって、所与のシステム（例えば、システム１００）の特定のコンテキストにおいて、変換プロセスを使用して、複合サービスの抽象的制約を、対応するアトミックサービスに対する具体的なサービス要件に変換することができる。このような変換プロセスは、当該システム（例えば、システム１００）に関する情報に基づいて、複合サービスの抽象的制約を判定し、抽象的制約を具体的要件に変換することができる。複合サービスのアトミックサービスが通信して協働する範囲では、全てのアトミックサービスについて、具体的な値が同一であることを保障するのは合理的であると言える。例えば、複合サービスが、２５ｑｍ２ごとに配置されるという抽象的制約に関連付けられる場合、システム情報を適用することができる。そのシステム情報として、例えば、システムのフィールドサイズが１００ｑｍ２であり、２５ｑｍ２ごとに１０個のデバイスを含み、したがって４０個のデバイスがフィールド全体をカバーするという情報が挙げられる。その結果、２５ｑｍ２ごとに複合サービスを配置するという抽象的制約は、対応するアトミックサービスの配置密度が１０％ということとなる。すなわち、この場合、４０個のデバイスのうち４つ（１０％）が、複合サービスおよび／または対応するアトミックサービスを実行し、１つのデバイスが、１００ｑｍ２のフィールド全体における５ｑｍｘ５ｑｍの各フィールド内で、そのデバイス上に配置される（複数の）サービスを有することになる。
【００３０】
より一般的には、少なくともサービスメタデータ１２６およびデバイスメタデータ１３０を使用することにより、サービスマッパ１２０は、ローカルネットワーク１０２のデバイス１０８、１１０、１１２または１１４上に所与のサービスをマッピングすることができる。このようなマッピングは、サービスメタデータ１２６およびデバイスメタデータ１３０の様々な態様の値マッチングを必要に応じて行う（例えば、サービスメタデータ１２６内で指定された必要メモリを、デバイスメタデータ１３０内で指定されたデバイスメモリとマッチングさせる）だけでなく、当該サービスの配置および実行を可能にして最適化するようにも設計されている。例えば、デバイス１０８およびデバイス１１０の両方が、名目上または表面上はサービス１２２を実行できてもよい（例えば、デバイス１０８および１１０の両方が、メモリ、処理能力、または電力の必要最小値を有してもよい）。しかしながら、サービス１２２が、メモリよりも電力をより必要とし（逆もあり得る）、デバイス１０８が、他の候補デバイス１１０と比べて、より多くの電力を現在提供することができる場合、デバイス１１０が、デバイス１０８よりも多くの空きメモリを現在提供していたとしても、サービスマッパ１２０は、サービス１２２をデバイス１０８にマッピングしてもよい。
【００３１】
より形式的には、マッチング集合を関数として表すことができる。その関数は、デバイスのセットに関するデバイスメタデータ（例えば、デバイスプロファイル）を、配置されるサービスに関するサービスメタデータ（例えば、技術的要件）と比較する。具体的には、集合Ｄｃａｐは、利用可能な個々のデバイスプロファイル「ｄ」全ての集合として定義することができ、ｓｔｅｃは、当該サービスの技術的要件を指す。すると、マッチング集合は、以下の式（１）のように定義することができる。
【００３２】
【数１】
【００３３】
したがって、集合Ｄｃａｐ内のデバイスプロファイル「ｄ」は、当該サービスの全ての技術的要件ｓｔｅｃが満たされた場合に限り、マッチング集合の要素として認められる。
【００３４】
しかしながら、上述したように、サービスメタデータ１２６の値をデバイスメタデータ１３０と単にマッチングさせるだけでは、どのマッチングまたは候補デバイスプロファイル「ｄ」が、当該サービスの機能を実行するのに品質的に最適であるかを判定するには十分ではない場合もある。例えば、デバイスメタデータの１つまたは複数の属性に数値の重みを割り当てるパフォーマンスメトリックを適用することができる。ただし、（複数の）数値の重みは、対応する属性値に基づいて、当該サービスに割り当てることができるので、例えば、数値の重みは、異なるサービスに対しては異なる場合がある（例えば、サービスに固有である場合がある）。例えば、そのようなパフォーマンスメトリックは、以下の式（２）のように表すことができる。
【００３５】
【数２】
【００３６】
式（２）において、重み値ｗ１、ｗ２、ｗ３およびｗ４は、「１」に等しいように選択されてもよいし、および／または、単位の任意の差異を考慮するために、別の方法により、正規化または修正されてもよい。
【００３７】
したがって、式（２）は、全ての利用可能なデバイス（または、式（１）のマッチング集合内の全てのデバイス）に対して適用することができ、その結果、各デバイスごとに、Ｖａｌｄの値を取得することができる。次いで、Ｖａｌｄのデバイス固有値が比較されて、当該デバイス全てに対する最大値が判定され、関連するデバイスが、サービスマッパ１２０によって選択される。このようにして、当該サービスを実行するのに利用可能な最高品質を提供するデバイスを選択することができる。
【００３８】
さらに、式（２）の例におけるパフォーマンスメトリックを拡張して、他のデバイス、または、アプリケーションに依存する問題をカバーすることができる。例えば、配置されたサービスを実行する際、所定の種類またはブランドのデバイスが、例えば、信頼性の点でいくらか有用であることが既知である場合がある。したがって、例えば、この種類またはブランドのデバイス全てに適切な重みを割り当てることができ、この種類またはブランドのデバイス全てを、式（２）のパフォーマンスメトリックまたは同様のパフォーマンスメトリックに含めることができる。
【００３９】
適切なサービスマッピングが実行されると、サービスインジェクタ１３４を使用して、デバイス１０８上にマッピングされたサービス（例えば、サービス１２２）をインストールして開始することができる。さらに、より一般的にサービスインジェクタ１３４を使用して、例えば、必要に応じて、サービスを更新または停止することによって、サービス（群）のライフサイクルを管理することができる。
【００４０】
したがって、サービスインジェクタ１３４のタスクの１つは、具体的なサービスコード（例えば、サービス実行ファイル（群）１２８のうちの適切な１つ）を、選択されたデバイス（群）に転送することである。したがって、サービスインジェクタ１３４は、当該コードを受信してインストールする。サービスインジェクタ１３４のような前述のインストールコンポーネントは、デバイス側に１つのスタンドアロンソフトウェアコンポーネントとしてインストールしてもよいし、または、サービス実行ファイル１２８を分散させるために、他のインストールコンポーネントと協働してもよい。後者の状況では、例えば、サービスマッパ１２０が、要求されたサービスのインストールに関して、選択されたデバイス全てに連絡できない場合、複数のデバイス上のサービスインジェクタは、互いに通信してインストールを遂行する。サービス実行ファイル１２８をインストールした後、サービス１２２は、サービスインジェクタが起動信号を送信してサービスをアクティブ状態に変化させるまで、非アクティブ状態を保つことができる。同様に、サービスインジェクタ１３４を使用して、サービスの更新および停止を体系化することができる。
【００４１】
サービス１２２のマッピングが実行され、サービス１２２がデバイス１０８上にインストールされて開始されると、必要に応じて、サービス１２２の実行を継続することができる。しかしながら、時間が経過すると、デバイス１０８は、ローカルネットワーク１０２内のサービス１２２を実行する最適なデバイスでなくなる場合がある。例えば、デバイス１１０は、自機のサービスの実行を停止し、それにより十分なメモリリソース、処理リソースまたは電力リソースを解放して、サービス１２２の実行に関してデバイス１０８よりも上回る場合がある。別の例として、デバイス１１２は、デバイス１０８上にサービス１２２を配置した後のある時点でローカルネットワーク１０２に参加し、サービス１２２を実行するための優位なリソースを有するデバイスであることを示す場合がある。例えば、デバイス１０８は、携帯情報端末（ＰＤＡ：Personal Digital Assistant）であり、デバイス１１２は、ＰＤＡデバイス１０８より優位なコンピューティング能力を有するラップトップであってもよい。最後の例として、デバイス１０８は、自機のリソースが欠乏し始める場合がある（例えば、バッテリ電力がほぼ放電状態の場合）。それによって、デバイス１０８は、ローカルネットワーク１０２全体としての潜在的な脆弱性を生じさせることになり、デバイス１１０、１１２または１１４のうち１つが、サービス１２２を実行する上で優位であると考えられる場合がある。
【００４２】
したがって、サービスマッパ１２０は、サービス１２２が実行されている間に、デバイス１０８などの元のデバイスから、例えばデバイス１１０といった別の選択されたデバイスに、サービス１２２を再マッピングして、削除し、再配置することができる。このように、相対的にリソース不足のデバイスから、よりパワフルなデバイスにサービスを再配置することにより、デバイスの活用を改善し、信頼性を改善することができる。以下でより詳細に説明するように、各デバイスにおける利用可能なリソースの判定は、システムモニタ１３２により実行することができ、それに応じて再マッピングの開始時間および方法に関する決定をすることができる。
【００４３】
マッピングおよび／または再マッピングを実行する際、ビジネスデータ処理システム１０４、サービスリポジトリ、システムモニタ、ローカルネットワーク１０２、または、デバイス１０８、１１０、１１２および１１４のいずれか、または全てを、ワイドエリアネットワーク１０６を介して接続された、比較的広い地理的領域にわたって分散させてもよい。ワイドエリアネットワーク１０６には、例えば、インターネット、または企業規模の専用ネットワークを含めることができる。さらに、ビジネスデータ処理システム１０４にレポートするスマートアイテムデバイスの総数によっては、サービスマッパ１２０が、このようなデバイスの全てに対するサービスマッピングプロセスの全ての段階を独立して扱うのは非実用的であるか、または望ましくないものになり得る。
【００４４】
したがって、サービスマッパ１２０のコンポーネントまたは階層を使用してもよい。そのコンポーネントまたは階層は、例えば、サービスメタデータ１２６および／またはデバイスメタデータ１３０用に使用されるセマンティックス（semantics）または記述に応じて変わり、あるいは、利用可能なコンピューティング電力に応じて変わり、あるいは、ビジネスデータ処理システム１０４、ローカルネットワーク１０２、および／またはデバイス１０８、１１０、１１２もしくは１１４に関する地理的位置に応じて変わる。例えば、グローバルサービスマッパ（ＧＳＭ：Global Service Mapper）コンポーネント１２０ａを使用することができる。そのＧＳＭコンポーネントは、ローカルネットワーク１０２と同様に、複数のローカルネットワークに共通であり、ワークステーションまたはパワフルなパーソナルコンピュータ（ＰＣ：Personal Computer）などの相対的にパワフルなコンピューティングデバイスを表す。それに対し、デバイス１０８、１１０、１１２および１１４などのデバイス、ならびにローカルネットワーク１０２（または図示していないが、他のデバイス）に固有であるローカルサービスマッパ（ＬＳＭ：Local Service Mapper）コンポーネント１２０ｂを使用することができる。ＬＳＭコンポーネント１２０ｂは、（以下でより詳細に説明する）スターゲートサーバ（Stargate sever）またはＰＤＡなどのあまりパワフルではないコンポーネントを表すことができる。最後に、ローカルネットワークにおける全てのデバイスのサブセットであるグループに関連付けられるグループリーダサービスマッパ（ＧＬＳＭ：Group Leader Service Mapper）コンポーネント１２０ｃを、ローカルネットワーク１０２内で使用することができる。したがって、ＧＬＳＭコンポーネント１２０ｃは、ローカルネットワークのデバイスの１つ（例えば、図示したように、センサノードなどのデバイス１０８）によって実装され、そのデバイスは、一般に、様々なサービスマッパコンポーネント１２０ａ、１２０ｂおよび１２０ｃのコンピューティングリソースの最小量を有する。図３を参照しながら、このような階層アーキテクチャの実装の一例を以下で例示して説明する。
【００４５】
上記の説明は、サービスマッパ１２０のための階層アーキテクチャの一例を提供することを意図したものであり、上記の階層より多数または少数の層が使用できることを理解されたい。このような階層アーキテクチャを実装することにより、例えば、以下でより詳細に説明するように、様々な特徴および利点を得ることができる。例えば、前述したように、サービスのマッピングおよび／または再マッピングをデバイスに対して、および、デバイス間で、適時に、効率的に、かつコスト効果的に、実行できることを維持しつつ、システム１００を容易に拡張して、多数のスマートアイテムデバイスをシステム１００に含ませることができる。
【００４６】
図１の例において、ＧＳＭコンポーネント１２０ａは、アーキテクチャの階層のルート（root）を構築し、サービスマッピング要求の最初の受信者としての役割を果たすことができる。例えば、ＧＳＭコンポーネント１２０ａは、（例えば、図１には示していないサービス構成モジュールなどの）外部モジュールに対するインタフェースとしての役割を果たすことができる。この外部モジュールは、マッピングプロセスを開始するために使用される。
【００４７】
ＧＳＭコンポーネント１２０ａは、一般的に、それに関連するローカルネットワーク（例えば、ローカルネットワーク１０２）に関する情報を提供する。このようなローカルネットワークの各々は、倉庫または小売店などの、物理的および／または地理的位置に関連付けられる。例えば、ＧＳＭコンポーネント１２０ａを使用して、デバイスと、提供されたサービスと、前述した、位置を含む任意のさらなるセマンティック情報（semantic information）とにしたがって、ローカルネットワークをソートすることができる。
【００４８】
例えば、ＧＳＭコンポーネント１２０ａには、ＧＳＭメタデータテーブル１３６を含めることができる。そのＧＳＭメタデータテーブル１３６は、所与のローカルネットワークにおける既存デバイスおよびデバイス能力についての情報を含むローカルネットワークデバイスの記述を格納する。例えば、ＧＳＭメタデータテーブル１３６は、所与の倉庫がその倉庫内に分散された１００個のセンサと、倉庫の従業員が使用する２０個のＰＤＡとを含むという情報を反映することができる。このようなデバイス情報の取扱いに加えて、ＧＳＭメタデータテーブル１３６は、それぞれのローカルネットワークにおいて提供されるサービスについての情報を格納および提供することができる。前述の例を続けると、ＧＳＭメタデータテーブル１３６は、（例えば、センサなどのスマートアイテムデバイスを使用して、）倉庫の温度を測定するサービスが倉庫内にインストールされているという情報を格納することができる。したがって、それらのデバイス、提供されたサービス、および、さらなるセマンティックな態様を有するローカルネットワークについての上記の情報は、１つまたは複数のデバイスに対してサービスマッピングを実行する際に使用するのに利用可能である。図４Ａを参照しながら、ＧＳＭメタデータテーブル１３６の詳細な例を提示し、以下でより詳細に説明する。
【００４９】
ＧＳＭコンポーネント１２０ａには一般的に、単体のデバイスと、その（複数の）現在の使用状況とに関する記述または情報を含める必要はなく、その代わり、ＧＳＭコンポーネント１２０ａは、抽象的なデバイスクラスと、それに関連する一般的属性の記述とを単に保持するだけでよい。したがって、個々のローカルネットワークを体系化する役割および追跡する役割を、ＬＳＭコンポーネント１２０ｂに担わせることができる。ＬＳＭコンポーネント１２０ｂは、ＧＳＭコンポーネント１２０ａよりも、その関連するネットワークデバイスに対して近くに位置する可能性が高いので、複数のＬＳＭコンポーネント１２０ｂは、様々なネットワークスマートアイテムデバイス全てが収集して分析したデータを配布する。ＧＳＭコンポーネント１２０ａと同様に、ＬＳＭコンポーネント１２０ｂには、ＬＳＭメタデータテーブル１３８を含めることができる。そのＬＳＭメタデータテーブル１３８は、各デバイスに関連付けられたサービス情報、サービス情報の品質、および、各デバイスに関するより詳細な位置情報とともに、デバイス情報を格納する。図４Ｂを参照しながら、ＬＳＭメタデータテーブル１３８の詳細な例を以下に提示する。
【００５０】
ＬＳＭコンポーネント１２０ｂが、個々のスマートアイテムデバイスに関する情報を追跡および提供することは可能であるが、図１の例は、ＬＳＭコンポーネント１２０ｂが、下位ネットワーク（例えば、ローカルネットワーク１０２）を、通常物理的に近い位置にある異種である可能性が高いデバイスのセットを含むクラスタまたはグループに分割する場合を示している。例えば、デバイス１０８、および／または、１つまたは複数のデバイス１１０、１１２および１１４、ならびに不図示の他のデバイスは、ローカルネットワーク１０２およびＬＳＭコンポーネント１２０ｂに関連付けられた１つまたは複数のグループに含めることができる。
【００５１】
図１の例において、デバイス１０８は、上記のグループに対するグループリーダとしての役割を果たし、ＧＬＳＭコンポーネント１２０ｃを含む。このようなグループ化により、デバイス１０８、１１０、１１２および１１４の状態の一部を、改善した形で制御することができる。例えば、サービスが、定義された領域内に均一に配布される必要がある場合、上記のグループ分割は有用である。例えば、配置要求または配置命令は、サービスが、ローカルネットワーク１０２のデバイス全体の１０％にインストールされるよう要求することができる。その結果、グループがローカル領域内に均一に分散する場合、その配置を、全てのデバイスに対して一度に行うのではなく、グループごとに行うことをベースにすることができ、サービス配布の役割の一部を、様々なグループリーダに割り当てることができる。
【００５２】
ＧＬＳＭコンポーネント１２０ｃおよび前述の関連デバイスのグループ化により得られる利点の別の例は、デバイスメタデータ１３０の収集に対する簡便性および効率性に関する。その収集は、例えば、システムモニタ１３２および／またはサービスマッパ１２０（これには、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂ、またはＧＬＳＭコンポーネント１２０ｃが含まれる）によって行われる。例えば、サービス配置要求の時点で、所定のデバイスの現状を複数のローカルネットワークにわたって判定する必要がある場合がある。したがって、デバイスの問い合わせは、ＧＳＭコンポーネント１２０ａにより、適切なＬＳＭコンポーネント１２０ｂに配布され、次いで、適切なＬＳＭコンポーネント１２０ｂから適切なＧＬＳＭコンポーネント１２０ｃに配布することができる。このように、グローバルシステム内の全てのデバイスに、または様々なローカルネットワーク内の全てのデバイスに、または所与のローカルネットワーク内の全てのデバイスにさえも、問い合わせる必要はない。むしろ、特別なサービスマッピングに対して実際に候補であるデバイスまたは候補の可能性があるデバイスのみに、それらの関連デバイスメタデータを提供するよう要求することができる。
【００５３】
同様に、問い合わせられたデバイス、または別の形で指定されたデバイスのモニタリングは、グローバルなレベルではなく、グループおよび／または（複数の）ローカルネットワーク層において行うことができる。例えば、システムモニタ１３２には、デバイス１０８上にインストールされたモニタコンポーネント１３２ａを含めることができる。しかしながら、他の例においては、モニタコンポーネント１３２ａは、追加で、または代替として、ＬＳＭコンポーネント１２０ｂに格納されてもよい。このようにデバイスをモニタリングすることにより、デバイスメタデータ１３０は、適時に、効率的に、かつ拡張性を有して収集することができるので、サービスマッピングまたは再マッピングに関する判定を、同様に迅速に行うことができる。
【００５４】
図１の上述の説明は、サービスメタデータ１２６およびデバイスメタデータ１３０がおそらくパフォーマンスメトリックとともに使用されて、サービスリポジトリ１２４から、１つまたは複数のデバイス１０８、１１０、１１２または１１４に対してサービスマッピングを実行する例を示しているが、このようなマッピングを実行する際、他の情報も有用であることを理解されたい。例えば、ネットワークメタデータ１４０には、様々なネットワークパラメータを含めることができる。特にこの場合、前述のパラメータは、動的であり、任意の単一のデバイスについての情報から必ずしも識別可能ではない。ネットワークメタデータ１４０のこのような例の１つとして、ローカルネットワーク１０２上で利用可能な帯域幅を挙げることができる。他の例には、ＬＳＭコンポーネント１２０ｂからのデバイスの距離（または他の位置情報）、ネットワーク全体としての可動特性、およびネットワーク接続の信頼性を記述する、ネットワークトポロジの記述が含まれる。位置の例に関して、例えば、所与のサービスを配置して、ローカルネットワーク１０２内の特定領域内に現在配置されているサービスを置き換えることができる。この場合、ローカルネットワーク１０２内のグループを、追加のネットワークパラメータとしてのグループ識別子（ＩＤ）と関連付けて、配置を、上記のグループＩＤに関して、少なくとも部分的に進めることができる。例えば、新たなサービスが、所定の時間制約内にマッピングされる必要がある場合、このようなサービスは、グループＩＤおよび関連情報に基づいて、ＬＳＭコンポーネント１２０ｂに最も近いグループ内のデバイス上に配置することができる。
【００５５】
さらに、このようなグループＩＤは同様に、他の設定においても使用することができる。例えば、グループＩＤは、当該サービスが指定された数または種類のグループのうちの少なくとも１つに配置されるというサービス要件として、サービスメタデータ１２６内で使用することができる。同様に、グループＩＤは、特定のデバイスのパラメータとして、そのデバイスに関連付けられたデバイスメタデータ１３０内で関連付けることができる。これに関して、グループＩＤは、デバイスがグループ間で割り当てられる、または再割り当てされるか否かと、その頻度とに応じて、デバイスメタデータ１３０の静的パラメータまたは動的（変化しやすい）パラメータのいずれかとして考えることができる。
【００５６】
図２Ａおよび図２Ｂは、図１のシステム１００の動作例を示すフローチャートである。詳細には、図２Ａは、システム１００のマッピング動作例を示すフローチャートである。図２Ａの例において、サービス配置に対する要求を受信する（２０２）。例えば、ユーザは、図１０と関連させて以下で述べるユーザインタフェース例などのユーザインタフェースを使用して、指定されたサービスの配置要求を入力できる。他の例においては、要求は自動化することができる。例えば、サービスの配置を要求するビジネスデータ処理システム１０４のアプリケーションから、要求を受信することができる。
【００５７】
要求に基づいて、指定されたサービスおよび関連するサービスメタデータを判定することができる（２０４）。例えば、サービスマッパ１２０、より詳細には、ＧＳＭコンポーネント１２０ａは、要求に応じてサービスリポジトリ１２４にアクセスして、要求されたサービスが利用可能か否かを判定し、関連するサービスメタデータ１２６およびサービス実行ファイル１２８を判定することができる。いくつかの例においては、複数の開発プラットフォームに対して実装することができる。例えば、同一のサービスを、Ｃプログラミング言語またはＪａｖａ（登録商標）プログラミング言語に基づく既知の開発プラットフォームに対して実装することができる。このような多様な開発プラットフォームを提供することにより、所与のサービスは、使用可能なより広範囲な、または様々な種類のデバイスに配置することができる。当該サービスの開発プラットフォーム（群）についての情報は、サービスメタデータ１２６の一種類として、例えば、図１と関連させて提示および上述したサービスを動作させるための任意の様々なサービス要件または優先度とともに、含めることができる。
【００５８】
次いで、複数のデバイスに関する現在のデバイスメタデータを取得することができる（２０６）。例えば、サービス要求は、特定のローカルネットワーク、デバイスグループ、デバイス、または様々なデバイスを指定することができる。他の例においては、サービスマッパ１２０および／またはＧＳＭコンポーネント１２０ａは、サービス要求および／または関連するサービスメタデータに基づいて、所定のデバイスまたは様々な種類のデバイスを自動的に選択することができる。デバイスメタデータ１３０を収集するために、システムモニタ１３２は、適切なデバイスに配布される１つまたは複数の問い合わせを開始することができる（その問い合わせは、おそらくサービスマッパ１２０または関連するコンポーネントから、あるいは、それらが連動して、送信される）。次いで、システムモニタ１３２は、問い合わせに応じて、デバイスメタデータ１３０を収集することができる。例えば、問い合わせを配布し、応答であるデバイスメタデータ１３０を収集するために、ＧＳＭメタデータテーブル１３６および／またはＬＳＭメタデータテーブル１３８からの情報を使用することができ、適時かつ拡張性を有するようにデバイスメタデータを収集するために、デバイスのグループを構築して、そのデバイスのグループをグループＩＤと関連付けることができる。他の例においては、デバイスメタデータ１３０は、将来のサービス要求を予測して定期的にデバイス情報を要求することにより、収集することができる。
【００５９】
少なくともサービスメタデータ１２６およびデバイスメタデータ１３０に基づいて、複数のデバイスから、選択されるデバイスを決定することができる（２０８）。例えば、どの問い合わされたデバイスがサービスを配置することが可能であるかを判定するために、サービスマッパ１２０またはコンポーネント１２０ａ、１２０ｂ、１２０ｃのうちの１つは、式（１）にしたがってマッチング動作を適用することができる。例えば、そのマッチング動作には、サービスの利用可能なプラットフォームに固有の実装（実行ファイル）（例えば、Ｊａｖａ（登録商標）ベースのサービスに対するＪａｖａ仮想マシン（登録商標））が、少なくともデバイス（群）の所与の１つで実行可能であると判定することが含まれる。または、他のデバイスの特性および能力は、配置されるサービスのサービス要件とマッチングさせることができる。次いで、式（２）に示したようなパフォーマンスメトリックを使用して、マッチングされたデバイスのうち選択されるデバイスを、配置されるサービスの最適化パフォーマンスを可能とするものとして判定することができる。前述したように、ネットワークメタデータ１４０を含む他の情報を使用して、選択されるデバイスの判定を実行することができることは言うまでもない。
【００６０】
最後に図２Ａにおいて、選択されたデバイスにサービスを配置する（２１０）。例えば、サービスインジェクタ１３４などのサービスインジェクタを使用して、選択されたデバイス（群）上でサービスを配置、インストール、および／または開始することができる。いくつかの実施形態において、サービスインジェクタ１３４は、複数のサービスインジェクタを表すか、またはこれらを含み、この場合、各サービスインジェクタは、特定の開発プラットフォームに関連付けられる。このような場合、特定の種類のサービスインジェクタの利用可能性は、デバイスメタデータ１３０内に含まれ、サービスメタデータ１２６の対応する要件とマッチングさせることができる。
【００６１】
したがって、図２Ａは、サービスを、選択されたデバイス上またはデバイスのセット上に配置するための、システム１００または関連するシステム内で実行されるサービスからデバイスへのマッピングプロセスの高レベルな記述を示している。上述したように、サービスが、すでに１つまたは複数のデバイスにマッピングおよび／または配置され、考えられ得る複数の理由により、実行されているサービスが停止され、そのサービスが現在実行しているデバイスから削除され、より好適なデバイスに再マッピングおよび再配置されるべきであると判定される場合がある。図２Ｂは、システム１００が実行できる、このような再マッピングプロセスの例を示すフローチャートである。
【００６２】
図２Ｂの例において、元のデバイス上で実行されている配置されたサービスを再配置する動機付けを判定する（２１２）。例えば、上述したように、サービス１２２は、デバイス１０８などの元のデバイス上に配置され、実行されている場合がある。次いで、システムモニタ１３２は、サービス１２２を再マッピングする動機付けを判定することに関与することができる。その動機付けには、例えば、ローカルネットワーク１０２上のデバイス１１０などの、よりパワフルな、またはより適切なデバイスの利用可能性の検出がある。例えば、このようなデバイスは、より適切なデバイス１１０がローカルネットワーク１０２の範囲に物理的に移動した結果として、またはデバイス１１０上の他の何らかのサービスが停止した結果として（それにより、デバイス１１０のリソースを解放し、サービス１２２の実行のためにデバイスが利用可能になった結果として）、利用可能となることを検出することができる。別の例において、動機付けには、元のデバイス１０８における低電力またはメモリ制限の検出を含めることができる。さらに別の例において、動機付けには、予め定められた時間の経過後にサービス１２２を再配置するようサービスマッパ１２０に命令することを含めることができる。これらの動機付けの１つまたは複数の結果として、サービス１２２がローカルネットワーク１０２の適切なデバイス上で確実に実行されることを支援する再マッピングを実行することができる。
【００６３】
十分な動機付けが判定されると、元のデバイスから、複数のデバイスの中から選択されたデバイスへの、配置されたサービスの再マッピングが実行される（２１４）。例えば、図２Ａのマッピングプロセスが実行されると、その場合、図２Ａのサービス配置要求（２０２）が再マッピングプロセスを開始する動機付けの判定に対応しており、その動機付けは、例えば、システムモニタ１３２により示されてもよいし、または判定されてもよい。さらに、図２Ｂのプロセスを「再マッピング」と呼んでいるが、元のデバイス１０８上のサービスは、必ずしも図２Ａのマッピングプロセスによって初めにマッピングされる必要がないことを理解されたい。例えば、サービス１２２は、図２Ａのマッピングプロセスを利用せずに、初めに直接的かつ明示的にデバイス１０８上にインストールされる場合もある。したがって、この意味において、再マッピングとは、サービス１２２または同様のサービスを、元のデバイスから選択されたデバイスに再配置して、元のデバイスからサービスを削除することを指す。
【００６４】
さらに、再マッピングを実行する技術には、例えば、再マッピングの動機付けに依存するものがあることを理解されたい。例えば、特定のデバイスがローカルネットワーク１０２に移動した場合、マッピングは、最初に再マッピングを開始したデバイスに対して直接実行することができる。すなわち、このようなデバイスは、サービス１２２に対して選択されるデバイス、またはサービス１２２に対する受信デバイスであると自動的に判定されることになる。他の例において、動機付けとして、元のデバイス１０８の今にも起こりそうな電力損失の検出が含まれる場合、図２Ａの完全なマッピングプロセスを実行することができる。デバイス１１０などの１つまたは複数のデバイスを含む選択されるデバイスを決定するために、例えば、完全なデバイスの問い合わせ、サービスメタデータ１２６に対する結果のデバイスメタデータ１３０のマッチング、適切なパフォーマンスメトリックの判定および適用の全てを実行することができる。
【００６５】
再マッピングが実行されると、選択されたデバイスに、配置されたサービスを再配置する（２１６）。例えば、配置されたサービス１２２は、デバイス１１０上のサービスインジェクタを使用することにより、デバイス１０８から、デバイス１１０または他の選択されたデバイス（群）に再配置することができる。図７と関連させて以下でより詳細に述べるように、このような再配置には、その再配置の直前である元のデバイス１０８上のサービス１２２の状態を維持することを含めることができる。このように、例えば、再マッピングプロセス中でも、サービスの継続性が維持される。
【００６６】
次いで、配置されたサービスを、元のデバイスから削除することができる（２１８）。例えば、デバイス１０８上のサービスインジェクタ１３４は、サービス１２２を停止し、元のデバイス１０８からサービス１２２を削除することができる。この例において、サービス１２２を元のデバイス１０８から削除することは、サービス１２２をデバイス１１０に再配置した後に実行されるものとして説明している。例えば、このことは、サービス１２２が、サービスの継続性を要求する何らかの安全機能または他のサービス（例えば、危険化学物質または危険条件をモニタリングするセンサ）を提供している場合に実行されるので、特に前述の状態を維持するとともに、（複数の）危険な条件がモニタリングされていない状態の時間はほとんどないか、または全くない。しかしながら、他の例においては、どのサービス１２２の状態も維持される必要はなく、サービス１２２のデバイス１１０への再配置と並行して、または、サービス１２２がデバイス１１０に再配置される前に、元のデバイスからサービス１２２を削除できることを理解されたい。
【００６７】
図３は、図１のシステムの３階層アーキテクチャを使用したシステム３００を示すブロック図である。すなわち、図３の例は、図１と関連させて上述したグローバル、ローカル、およびデバイス（グループ）層の使用を示している。例えば、図３は、与えられたサービス（群）および／または含まれるデバイスごとに、異なるネットワークをグループ化できるシステム１００の能力を示している。このように、広範囲に及ぶサービスを広範囲に及ぶスマートアイテムデバイスに配置して、様々なビジネス目標を達成することができる。さらに、デバイスネットワークをコミュニティに構造化することができる。
【００６８】
詳細には、図３において、グローバル層には、施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４が含まれる。図１の上述の説明から理解されるように、施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４の各々は、グローバルサービスマッパ（ＧＳＭ）コンポーネント１０２ａの実装に関連付けることができる。次いで、例えば、施設安全管理コミュニティ３０２には、危険な条件（例えば、可燃性または爆発性の物質、またはそれらの物質の組合せの存在）の判定に使用されるサービスおよびデバイスを含めることができる。一方、資産追跡コミュニティ３０４には、製品が元請／製造者から販売用に棚に置かれるまで、製品を追跡するために使用できるサービスおよびデバイスを含めることができる。このようにサービスおよびデバイスを分離することにより、企業からの情報を適切に割り振ることができ、本明細書で説明した様々なマッピングおよび再マッピングのプロシージャを効率的に実行することができる。なぜならば、例えば、施設安全管理コミュニティ３０２において有用な振動検出サービスを資産追跡コミュニティ３０４内のデバイスにマッピングしようとする際、上記のサービスが後者のコンテキストにおいて有用でないと予め知られていれば、無駄が生じないからである。
【００６９】
次に、ローカルネットワーク３０６および３０８は、図１と関連させて上述したローカル層の一部であるとみなすことができる。ローカルネットワーク３０６および３０８は、施設安全管理コミュニティ３０２に関連付けることができ、一方、ローカルネットワーク３１０は、ローカル層にあって、資産追跡コミュニティ３０４に関連付けられる。図１と関連させてすでに述べたように、ローカルネットワーク３０６、３０８および３１０の各々は、複数のデバイスに関連付けることができ、特にローカルネットワーク３０６は、デバイス３１２、３１４および３１６に関連付けることができ、ローカルネットワーク３０８は、デバイス３１８、３２０および３２２に関連付けることができる。次いで、様々なデバイスをグループ化して、図１のグループ層を形成することができ、デバイスの１つが、所与のグループのグループリーダとして選択または決定される。図３において、デバイス３１２は、デバイス３１２、３１４および３１６を含むグループのグループリーダであり、デバイス３２２は、デバイス３１８、３２０および３２２のグループリーダである。
【００７０】
一方、資産追跡コミュニティ３０４のローカルネットワーク３１０は、グループ３２４およびグループ３２６に関連付けられる。グループ３２４は、デバイス３２８（グループ３２４のグループリーダ）、３３０、３３２および３３４を含み、グループ３２６は、デバイス３３６（グループ３２６のグループリーダ）、３３８および３４０を含む。図１の上述した説明から理解されるように、ローカルネットワーク３０６、３０８、３１０には、ローカルサービスマッパ（ＬＳＭ）コンポーネント１２０ｂの実装を含めることができる。このようなＬＳＭコンポーネントには、コンピューティングデバイスまたはサーバ（例えば、ラップトップコンピュータまたはスターゲートサーバ）を含めることができる。そのコンピューティングデバイスまたはサーバは、十分なコンピューティングリソースを有し、対応するＧＳＭコンポーネントと比較して、対応するデバイスに物理的に近い位置に存在する。したがって、図３において、グループ３２４および３２６は、いくつかの実施形態において、所定のデバイス（例えば、デバイス３３０、ただし、必ずしもグループリーダデバイスではない）のみが、ＬＳＭコンポーネント１２０ｂを実行するデバイスまたはサーバに対する直接的なアクセスを有することができるということを示している。結果として、このような場合、ＬＳＭコンポーネントと、グループ３２４および３２６の他のデバイスとの間の通信は、直接接続されたデバイス３３０を介して生じさせることができる。
【００７１】
図４Ａおよび図４Ｂはそれぞれ、ＧＳＭメタデータテーブル１３６およびＬＳＭメタデータテーブル１３８の例を示すテーブルである。図４Ａにおいて、ＧＳＭメタデータテーブル１３６には、関連するローカルネットワークを識別する（例えば、ＬＳＭ１２０ｂの実装を識別する）列４０２が含まれる。例えば、図３において、列４０２により、ローカルネットワーク３０６および／またはローカルネットワーク３０８が、施設安全管理コミュニティ３０２に関連付けられたＧＳＭコンポーネント１２０ａの実装に関連付けられることを識別することができ、そのコミュニティは、列４０４において識別される。
【００７２】
次いで、列４０６を使用して、対応するデバイスメタデータファイル（例えば、定義されたＸＭＬスキーマにしたがうＸＭＬファイル）を参照することができる。そのデバイスメタデータファイルファイルは、例えば、ある能力を提供することができるＬＳＭコンポーネント１２０ｂに関連付けられたセンサを記述している。同様に、列４０８を使用して、対応するサービスメタデータファイルを参照することができ、そのサービスメタデータファイルは、当該サービス（群）の一般的性質、例えば、列４０６のセンサにより実装されている温度サービスおよび振動サービスに関する情報を含む性質を記述している。列４１０は、ローカルネットワークの位置、例えば、図示したように、「倉庫Ａ」に関する位置を提示する。したがって、デバイスメタデータ１３０およびサービスメタデータ１２６は、全ての（またはいくつかの）ローカルネットワークの全デバイスの現在の状態を保持するＧＳＭメタデータテーブル１３６を要求することなく、一般的な高レベルの方法により、ＧＳＭメタデータテーブル１３６内で参照することができる。例えば、デバイスが、移動式であるか固定式であるかなどの他の情報を、ＧＳＭメタデータテーブル１３６内に含めてもよいことは言うまでもない。
【００７３】
ＧＳＭメタデータテーブル１３６のデータファイルは、１つまたは複数のサーバ上に格納することができ、要求に応じてユーザによりロードすることができる。他の実施形態においては、ＧＳＭメタデータテーブル１３６のデータファイルは、ＧＳＭコンポーネント１２０ｂ、または管理者により自動的にロードすることができる（より一般的には、ユーザにより実行されているものとして本明細書で説明した事実上どのようなアクションも、適切なコンピューティングリソース（群）を使用して、自動的に実行できることを理解されたい）。結果として、サービスマッピング要求は、グローバル層において、適切なＧＳＭコンポーネントにルーティングすることができ、対応するＧＳＭメタデータテーブル１３６を使用して、例えば、どの関連デバイス／サービスの特性または種類が、サービスマッピング要求用であると考えられるかを判定することができる。ＧＳＭメタデータテーブル１３６、および、他のこのようなテーブルを使用することにより、利用可能なローカルネットワークおよびデバイスの全てを、継続的に縦横に検索する必要性を低減または排除することができる。
【００７４】
図４Ｂは、ＬＳＭメタデータテーブル１３８の例を示している。図４Ｂには、関連するグループ識別子を使用してデバイスのグループを識別する列４１２が含まれる。列４１４により、列４１２において識別されたグループのメンバが識別される。例えば、列４１４により、関連する（様々な）能力を有するＰＤＡおよびセンサノードが含まれる列４１２のグループを識別することができる。
【００７５】
列４１６により、列４１４のグループメンバ（デバイス）上で実行できる（様々な種類の）サービスが識別される。図４Ｂにおいて、列４１６により、ディスプレイサービスおよび温度サービスが識別される。したがって、グループは、デバイスの集合としてだけでなく、そのグループによって提供されるサービスの集合としても考えることができる。このような場合、サービスは、広い領域にわたっていても、多種多様な複数のデバイスに対しても識別される。
【００７６】
列４１８により、例えば、グループＩＤ列４１２において識別されるグループの現在のリソース使用率などの、サービス品質（ＱｏＳ）が識別される。グループの利用可能なＱｏＳを識別することにより、グループの信頼性およびパフォーマンスを認識し、評価することができる。最後に、図４Ｂにおいて、列４２０により、関連するローカルネットワーク内、例えば、図示したようなローカルネットワークの「倉庫Ａ」の「領域１」内の、識別されたグループの位置が特定される。したがって、グループの位置は、例えば、そのグループのＬＳＭコンポーネント１２０ｂに近接することができ、その結果、例えば、ＬＳＭコンポーネント１２０ｂとグループとの間の通信は、適時かつ信頼性があるものにすることができる。
【００７７】
図３、図４Ａ、および図４Ｂ、ならびに上述の説明から、ＬＳＭコンポーネント１２０ｂは、自身のローカルネットワークを体系化する役割を担うことができ、ＧＳＭコンポーネント１２０ａと、ＧＳＭコンポーネント１２０ａの、高レベルな記述、および様々な種類のデバイスならびに／またはサービスの分類の格納とは対照的に、ＬＳＭコンポーネント１２０ｂは、現実の個々のデバイスおよび／またはサービスに固有の情報を格納する役割を担うことができる。説明したように、ＬＳＭコンポーネント（群）１２０ｂは、それぞれのデバイスおよびネットワークに物理的に近くに位置することができ（例えば、そのデバイスと同一の倉庫、または同一の他の建物もしくは場所に位置することができ）、ＬＳＭコンポーネント（群）１２０ｂを使用して、ＧＳＭコンポーネント（群）１２０ａと個々のデバイスとの間の空間をブリッジ（bridge）ことができる。この方法により役割を分割させることによって、大量のデータを好適に配布することができる。
【００７８】
したがって、ＬＳＭコンポーネント１２０ｂには、対応するＧＳＭコンポーネント１２０ａに対する標準インタフェースを含めることができ、ＬＳＭコンポーネント１２０ｂは、１つまたは複数のＬＳＭコンポーネント１２０ｂのデバイスにサービスをマッピングするためのマッピング要求を、そのインタフェースを介して受信することができる。ＬＳＭコンポーネント１２０ｂには、以下でより詳細に説明するように、ゲートウェイサーバを含めることができる。
【００７９】
図４Ａおよび図４Ｂの例の域を越えて、他のパラメータおよびメタデータを、ＧＳＭメタデータテーブル１３６内および／またはＬＳＭメタデータテーブル１３８内に含めることができることを理解されたい。例えば、グループ（群）のさらなる特性を含めることができる。その特性には、例えば、各グループの規模などが含まれる。その各グループの規模として、例えば、グループリーダとグループメンバとの間の最大ホップ数、または、含めることができるグループメンバの最大数を定義するグループサイズが挙げられる。
【００８０】
図１および図３の３階層アーキテクチャの第３層（群）は、ＧＬＳＭコンポーネント１２０ｃを配置できるグループリーダ層である。したがって、グループリーダは一般的に、ローカルネットワークの専用デバイスを表し、そのデバイスは、（図１および図３に示したような、）ローカルネットワークがクラスタリングされた対応するグループの代表としての役割を果たす。図４Ｂに示したように、このようなグループリーダは、ＬＳＭコンポーネント１０２ｂに登録され（例えば、ＬＳＭメタデータテーブル１３８内に格納され）、対応する下位のデバイスクラスタからの抽象化を提供する。したがって、グループリーダを使用して、各グループメンバについての情報と、グループメンバによって提供されるサービスについての情報とを提供することができる。
【００８１】
３階層アーキテクチャの各層のセマンティック情報は、下位のモバイルアドホックネットワークに配置された軽量セマンティックオーバーレイ（light-weight semantic overlay）のビルディングブロックとみなすことができる。このようなセマンティックオーバーレイは、セマンティックに関連するサービスまたはデバイスを、サービス／デバイスの物理的位置とは無関係に、一緒にクループ化することを可能にする。例えば、グローバル（ＧＳＭコンポーネント１２０ａ）層において、物理的に分散したローカルネットワークを識別することができる。そのネットワークは、企業内で同一または類似した（複数の）役割ごとに接続されている。同様に、ローカル（ＬＳＭコンポーネント１２０ｂ）レベルのグループは、これらグループの構成デバイスおよび機能についての情報に関して、識別することができる。
【００８２】
図５は、図１および図３のシステムをそれぞれ実装するスマートアイテムインフラストラクチャ５００のブロック図である。スマートアイテムインフラストラクチャ５００は、５つの層を含む。５つの層とは、デバイス層５０２、デバイスレベルサービス層５０４、ビジネス処理ブリッジング層５０６、システム接続層５０８、および企業アプリケーション層５１０である。層５０２は、複数のグループ、ローカルネットワーク、および／または物理的位置にわたって、図１のデバイス１０８、１１０、１１２および１１４、または同様のデバイスのうちの様々なデバイスを含むものと考えることができる。一方、層５０６、５０８および５１０は、図１のビジネスデータ処理システムの一部、または、それに関連付けられるものと考えることができる。したがって、層５０４は、図１のシステム１００の残りのコンポーネント、例えば、図５に示すような、サービスマッパ１２０、およびそのコンポーネント１２０ａ、１２０ｂもしくは１２０ｃと、システムモニタ１３２、およびそのコンポーネント１３２ａと、サービスリポジトリ１２４とを表すものと考えることができる。
【００８３】
したがって、デバイス層５０２は、現実のスマートアイテムデバイスと、それらの間の任意の通信とを含む。デバイス層５０２はまた、任意の提供されたハードウェアサービスを次の高次層、すなわち、デバイスレベルサービス層５０４に提供する役割も担う。デバイスとして、例えば、ＲＦＩＤデバイス５１２、組み込みシステム５１４、センサネットワーク５１６、および、適切であれば、他の任意の新規技術または新興技術５１８を挙げることができる。
【００８４】
例えば、ＲＦＩＤデバイス（群）５１２に関して、モバイルタグを実世界の物体に取り付けることができ、モバイルタグは、ＲＦＩＤリーダによって読み取られる（および、オプションとして、モバイルタグに書き込まれる）。アクティブなタグを使用した実装において、アクティブなタグは、さらなるセンサデータ（例えば、現在値または過去値）を提供することができる。ＲＦＩＤにおいて、通信は通常、リーダによって開始されるが、タグは、互いに直接的に通信してもよいし、通信しなくてもよい。このようなＲＦＩＤリーダは、タグデータを処理する程度まで、構成することができる。例えば、ＲＦＩＤリーダは、書き込みデータの検証を行うように、または、表面上失われたタグが、実際には所与の時間ウィンドウ内に再び現れる場合、タグの消失の報告を回避するように構成することができる。
【００８５】
組み込みシステム５１４との通信技術は、組み込みシステムのデバイスの種類に応じて変えることができる。例えば、組み込みシステムは、小規模な１チップマイクロコンピュータから高機能なＰＣハードウェアに至る全てのものを表すことができる。したがって、例えば、携帯電話、またはそれ以上の能力を有する（例えば、Ｊａｖａ仮想マシン（登録商標）を実行できる）デバイスに対して、Ｊａｖａ（登録商標）を用いて、または、ＯＳＧｉ（ＯＳＧｉは、アプリケーションおよび／またはアプリケーションコンポーネントのリモートインストールおよびリモート管理用のコンポーネントモデルを実装する公知のフレームワークを表す）に基づいて、実装することができる。前述したように、センサネットワーク５１６には、任意の数の様々な種類のセンサを含めることができ、これらのセンサは、統合された処理電力を含み、ピアツーピア通信を実行することができる。
【００８６】
デバイスレベルサービス層５０４は、デバイス層５０２により使用される配置可能なサービスを管理する。したがって、層５０４には、サービスマッパ１２０（ならびにサービスマッパコンポーネント１２０ａ、１２０ｂ、および１２０ｃ）、システムモニタ１３２（およびシステムモニタコンポーネント１３２）、およびサービスリポジトリ１２４が含まれる。
【００８７】
上述したように、サービスリポジトリ１２４は、少なくとも２種類のサービス、すなわち、複合サービスおよびアトミックサービスを格納することができる。複合サービスは一般に、他のサービスに依存して、それらのタスクを遂行し、自身の直接的に実行可能なコードを有さなくてもよい。むしろ、複合サービスには、実行可能なサービス構成の記述を含めることができ、その記述は、対応するサービスの記述に格納される。したがって、複合サービスは、１つのサービス実行ファイル、すなわち、サービス構成の記述を有することができる。それに対し、アトミックサービスは一般に、他のサービスを使用せず、自身の直接的に実行可能なコードを有する。さらに、上述したように、アトミックサービスは、異なるプラットフォームに配置可能であるので、アトミックサービスは、複数のサービス実行ファイルを有することができ、例えば、異なるプラットフォームの各々に対して、１つのサービス実行ファイルを有することができる。
【００８８】
サービスリポジトリ１２４は、サービスメタデータ１２６を格納することができる。このサービスメタデータ１２６は、上記にて詳細に説明した。サービスリポジトリ１２４には、サービスの名前、識別子、バージョン、またはベンダを含めることができる。あるいは、サービスリポジトリ１２４は、例えば、技術的な配置要件（例えば、高帯域幅、または、必要とする最小処理電力）、セマンティックな要件（例えば、受信デバイスは、シリアル接続、および／または、多数の近隣デバイスを有する必要があるという要件）、および空間的な要件（例えば、受信デバイスは、地下にある、または特定ビルの南側にあるという要件）などのサービスのランタイム要件を記述することができる。
【００８９】
最後に、デバイスレベルサービス層５０４には、デバイスリポジトリ５２０を含めることができる。上述の説明から理解されるように、デバイスリポジトリ５２０には、例えば、サービスリポジトリ１２４がサービスについての情報（例えば、サービスメタデータ）を保持するのと同様に、デバイスについての情報（例えば、デバイスメタデータ）を含めることができる。例えば、デバイスメタデータは、デバイスの問い合わせ動作の結果が判定された後に、デバイスリポジトリ５２０内に格納することができる。あるいは、別の実施形態においては、デバイスメタデータは、デバイスに関する外部から利用可能な情報に基づいて、管理者により格納することができる。例えば、すでに述べたように、デバイスメタデータには、デバイスの名前、電力量、メモリ容量、処理容量、または、サービスを関連デバイスにマッピングする（および、最終的には配置する）ことに関連する他の情報を含めることができる。
【００９０】
実行時に、システムモニタ１２４は、現在のシステムの状態をモニタリングする。サービスの状態の任意の部分をシステムモニタに公開するか否か、および、その公開方法は、設計時に、サービスの開発者により設定することができる。この状態利用可能性情報は、その後、システム管理者およびサービスマッパ１２０の両方に対して利用可能となる。上述したように、サービスマッパ１２０は、配置要求を受信し、次いで、例えば、サービスメタデータをデバイスメタデータとマッチングさせることにより、どのデバイス（群）に、対応するサービスが配置されるべきかを判定する。このデバイスメタデータには、スマートアイテムデバイス、および関連するローカルネットワーク（群）の現在の状態を含めることができる。本明細書で説明したように、サービスマッパ１２０は、（システムモニタ１２４によって認識される）ネットワークの状態変化などの所定のイベントまたは条件に対応することができる。その後、サービスマッパ１２０は、サービスを再マッピングするか、あるいは、サービスのインスタンスを追加または削除するよう判定して、所与の配置要求／要件をより良く遂行することができる。
【００９１】
ビジネス処理ブリッジング層５０６には、デバイス層５０２にあるデバイスから、デバイスレベルサービス層５０４を介して提供されたデータを集約して、デバイス層５０２からのデータをビジネス関連情報に変換するよう設計されたサービスが含まれる。それを行う際、バックエンド企業アプリケーションシステムに送信されるデータ量を低減することができ、ビジネスロジックは、企業アプリケーションシステムの様々なシステムに対して実行することができる。
【００９２】
例えば、１つまたは複数のルールプロセッサ５２２を使用して、着信メッセージを解析したり、基本動作サービス（例えば、アイテムの移動、関連付け、関連付け解除、または、デバイスの読み取り／書き込み）および情報の問い合わせをサポートしたりすることができる。ルールプロセッサ５２２は、実行または参照する必要がある他の任意の基本動作サービスを定義または参照する、ユーザにより定義されたビジネスルールを処理する。このようなルールおよび基本動作サービスを使用することによって、システム５００を異なるビジネスシナリオに適合させる柔軟性のあるフレームワークが提供される。
【００９３】
ルールプロセッサ５２２は、関心のある全ての物理的な物体を追跡し続けるために、例えば、追跡している所与の物体の現在の状態、位置、タイムスタンプ、または関連するビジネストランザクションを追跡し続けるために、および、どのような将来の行動が期待されるかを追跡し続けるために、データリポジトリ５２４を使用することができる。データリポジトリ５２４からの集約された情報は、例えば、日次または月次に、定期的にレポートすることができる。
【００９４】
層５０２、５０４および５０６の動作の一例には、「商品受け取り」のシナリオが含まれる。例えば、対象物を受取人に配送する供給者は、電子製品コード（ＥＰＣ：Electronic Product Code）などの物体識別子とともに、出荷物内の全物体の一覧を含む事前出荷通知（ＡＳＮ：Advanced Shipment Notification）を送信することができる。ＡＳＮは、データリポジトリ５２４内に格納することができる。出荷物が到着し、例えば、受入ドックドアなどのデバイス層５０２にあるＲＦＩＤリーダを通過すると、ＥＰＣが、ＲＦＩＤリーダによって読み取られ、ルールプロセッサ５２２に送信される。ルールプロセッサは、メッセージの送信元であるリーダのＩＤを調べ、そのリーダの位置と役割とを判定し、次いで、受け入れた出荷物の処理責任を有する適切な基本動作サービスを呼び出す。この動作サービスは、取得したＥＰＣを、以前のＡＳＮから予想されるＥＰＣと比較する。マッチングが見つかった場合、この動作サービスは、配送が届いて完了したことを企業アプリケーション５３２にレポートする。次いで、実行された動作サービスは、データリポジトリ５２４内のデータを更新することができる。上述したサービスは、関連するメッセージを送受信するサービスとともに、サービスマネージャ５２６により管理することができる。
【００９５】
システム接続層５０８内のコンポーネントを使用して、異なるアプリケーションシステムを接続し、システムおよびデータの統合をサポートすることができる。例えば、メッセージおよびデータは、情報交換モジュールおよび情報変換モジュール５２８によって、適切なバックエンドシステムにルーティングすることができ、それにより変換されて、セマンティックに正確な統合を可能にすることができる。所与のサービスが、開発環境から、デバイスレベルサービス層５０４のサービスリポジトリ１２４に配置された場合、システム接続層５０８を使用して、メッセージルーティングおよび変換サービスに加えて、外部サービスリポジトリ５３０を用いることにより、サービス実行ファイル（群）１２８を移送することができる。
【００９６】
企業アプリケーション層５３２には、例えば、企業ビジネスアプリケーションを制御および管理する役割を担う従来の企業ＩＴシステムが含まれる。特定のビジネスプロセスをカバーする企業アプリケーションは、単一のプログラムでなくてもよく、むしろ、所望の機能を実現するために協働する様々なサービスから構成することができる。このようなサービスは、同一の企業システム、企業アプリケーション層５３２内の別の企業システム（ビジネスパートナのサイトに位置する可能性が高い）、または下位層のシステム（例えば、デバイス層５０２にあるスマートアイテムデバイス）により、提供されてもよい。
【００９７】
最後に、図５において、開発ツール５３４とは、企業アプリケーション（群）５３２および他のアプリケーション／サービスを作成するツールを指す。インフラストラクチャ５００に統合された開発環境を使用することによって、企業アプリケーション空間において公知の開発ツールと同様の方法により、基本サービスの実装をサポートすることができる。さらに、開発ツール５３４により、必要なサービスメタデータ１２６を作成することができ、加えて、既存サービスを新たなアプリケーションに組み込むことができる。さらに、開発ツール５３４により、開発者は、あるサービスをどこで実行するべきかを指定すること、個々のサービスのインスタンスを構成すること、および、サービスを所望の方法で配置することが可能となる。すなわち、開発者は、開発ツール５３４を使用して、サービスメタデータ／実行ファイル（群）５３６を開発することができ、その後、サービスリポジトリ１２４内に格納するために、および／または、同時または後でサービスマッパ１２０によりマッピング／再マッピングするために、サービスメタデータ／実行ファイル（群）５３６のうち望ましいものを提供することができる。
【００９８】
図６は、サービスからデバイスへのマッピング動作を示すフローチャート６００である。図６の例において、（サービスメタデータと、１つまたは複数のサービス実行ファイルとを含む、および／または、それらに関連付けられる）サービスが最初に開発され、サービスリポジトリ１２４に登録される（６０２）。例えば、図５の開発ツール５３４を使用して、特定の種類のプラットフォーム上での実装のために、サービス実行ファイルおよび関連するサービスメタデータを設計して構築することができる。
【００９９】
次いで、本明細書で説明したグローバルなレベルの３階層アーキテクチャにおいて、ローカルネットワークを識別することができる（６０４）。例えば、図１および図４ＡのＧＳＭメタデータテーブル１３６を判定することができ、コミュニティ情報、デバイスまたはサービス情報、位置情報、および、おそらく追加的または代替的な情報を含むローカルネットワーク情報（例えば、ＬＳＭ情報）を、そのテーブル内に格納することができる。図４Ａと関連させて説明したように、このようなグローバルなレベルの情報は、例えば、任意の特別なデバイスまたは単体のデバイスを参照することなく、デバイスの種類、機能、または、所与のローカルネットワーク（群）に関連付けられていることが既知のサービスに関して、高レベルまたは抽象的なレベルで判定および表すことができる。以下で説明するように、したがって、ＧＳＭメタデータテーブル１３６は、サービスからデバイスへのマッピングの進行の可否および方法を判定する開始点としての役割を果たす。
【０１００】
それに応じて、例えばＧＳＭコンポーネント１２０ａといったサービスマッパ１２０において、サービスマッピング要求を受信することができる（６０６）。例えば、管理者もしくは他のユーザ、または別のシステムコンポーネントは、所望のサービスを適切なローカルネットワークおよびデバイスにマッピングする目的で、ＧＳＭメタデータテーブル１３６にアクセスすることができ、その結果、所望のサービスまたはサービスの種類を識別することにより、ＧＳＭコンポーネント１２０ａにサービスマッピング要求を送信することができる。このような要求は、様々な形態をとってもよい。例えば、管理者または他のシステムコンポーネントは、明示的に識別された１つまたは複数のデバイスに特定のサービスをマッピングすることを要求することができる。あるいは、管理者または他のシステムコンポーネントは、（利用可能な）全てのデバイス上にサービスを配置することを要求することができる。管理者または他のシステムコンポーネントはまた、指定された数個または数パーセントのデバイスにサービスをマッピングおよび配置することを要求することもできる。最後に、図６の例において以下で説明するように、管理者は、例えば、図１および図２Ａと関連させて上述したようなパフォーマンスメトリックにしたがって、サービスが、所与のコンテキストに関する「最良」のデバイス（群）上で設定される必要があると指定することができる。
【０１０１】
対象となるデバイスが、サービスマッピング要求内で与えられた場合、ＧＳＭメタデータテーブル１３６を使用して、指定されたデバイスを含む全てのローカルネットワークを検出することができる。例えば、サービスを、全てのローカルネットワークにおける全てのＰＤＡに配置する必要がある場合、ＰＤＡを含む全てのローカルネットワークが検索される。したがって、ローカルネットワークの検索は、ＧＳＭメタデータテーブル１３６内にローカルネットワークに関する追加情報として保持される抽象デバイスクラスによって、サポートすることができる。
【０１０２】
他の例において、サービスの記述は、ローカルネットワークを判定する際に有用となり得る。例えば、サービスメタデータ１２６を使用することにより、すでに実行されている同様のサービスを有するコミュニティを発見し分析して、使用されている関連する（様々な）デバイスを検出することができる。例えば、施設安全管理の一部である新たなサービスを配置する必要がある場合、ローカルネットワークがコミュニティに関連付けられるので、対応する施設安全管理コミュニティ３０２を使用して、考えられ得る関連するローカルネットワーク／デバイスを検出することができる。
【０１０３】
ＧＳＭコンポーネント１２０ａに対するさらなる入力として、管理者または他のシステムコンポーネントは、所定の管理上の制約を指定することができる（６０８）。例えば、管理者または他のシステムコンポーネントは、（図１と関連させて上述したような）サービスの必要な配置密度、所定の種類のデバイスの使用、または、マッピングおよび／または配置を実現するための時間的制約を指定することができる。同様に図１と関連させて説明したように、このような抽象的な管理上の制約は、サービスがマッピングされることになるデバイスの特定のネットワークに関する具体的な制約に変換することができる（例えば、１０％のデバイス密度は、特定のローカルネットワークに関連付けられた領域内の具体的なデバイスの数に変換することができる）。
【０１０４】
次いで、サービスマッピング要求を、関連するローカルネットワークの情報と比較することができる（６１０）。例えば、サービスマッピング要求をローカルネットワーク情報と比較することは、ＧＳＭメタデータテーブル１３６のグローバル層またはグローバルなレベルにおいても、サービスマッピング要求の考えられ得る結果を著しく狭めることができる。例えば、図３に関して、サービスマッピング要求が、資産追跡コミュニティ３０４に関連付けられる場合、施設安全管理コミュニティ３０２に関連付けられたローカルネットワーク３０６、３０８は、サービスマッピング要求に対する考慮事項から取り除くことができる。同様に、デバイス、サービスまたは位置情報の列４０６、４０８または４１０により、それぞれ、考えられ得るサービス配置に関して考慮すべきローカルネットワークの数を低減することができる。
【０１０５】
したがって、サービスの配置が実現可能か否かに関する判定がなされる（６１２）。どのデバイス、サービス、または位置もサービスマッピング要求および／または管理上の制約のいずれともマッチングしない場合などのように、配置が実現可能でない場合、可能な動作が存在すれば、いくつかの動作を実行することができる（６１４）。例えば、管理者に通知されるか、または、（例えば、デバイスまたはネットワークの状態が変化して、その後配置が実現可能になる可能性を予測して）待機モードに入る。さらに、新たなサービスが提供される。例えば、サービスが新たに設計され、修正され、サービスリポジトリ１２４に（再）登録され、新たに登録されたサービスが、現行のローカルネットワークの状態と適合するようになる。
【０１０６】
しかしながら、指定されたサービスの配置に問題がないと識別された場合、サービスマッピング要求は、ＬＳＭコンポーネント１２０ｂに送信され、ＬＳＭコンポーネント１２０ｂにおいて、受信することができる（６１６）。次いで、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４への接続をオープンして、要求された（種類の）サービスに関連付けられた特定のサービスメタデータを取得することができる（６１８）。例えば、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４から、予め定められたＸＭＬスキーマを有し、かつ、例えば、サービス要件などのサービスメタデータを指定するＸＭＬドキュメントを取得することができる。
【０１０７】
次いで、グループ、および、それに関連するグループリーダを、そのグループに一意なグループＩＤにより、判定または構築することができる（６２０）。説明したように、グループは、その構成デバイスおよび／または提供される機能により、記述することができる。
【０１０８】
ローカルネットワーク内のグループ世代は、複数のメカニズムにより生じてもよい。例えば、グループは、複数のパラメータ／要件に基づいて、判定または指定されてもよい。そのパラメータ／要件として、例えば、グループメンバ（群）と、（考えられ得る）グループリーダとの間の最大ホップ数や、グループメンバの最大数が挙げられる。
【０１０９】
グループの作成中、ネットワークトラフィックを最小にしつつ、デバイスの発見を可能とする発見メカニズムを使用することができる。なぜならば、ネットワークトラフィック、および、デバイスの他の送信／受信動作は、スマートアイテムデバイスにとって重要であり、それらは、相対的に少量のコンピューティングリソースおよび電力リソースしか有さない可能性が高いからである。このようなプロセスの一部として、ローカルネットワーク上に送信され、グループの構築を意図したメッセージには、一意なグループＩＤとともに、機能的グループ属性および非機能的グループ属性の両方を含めることができる。次いで、考えられ得るグループメンバからの応答メッセージを評価して、グループを作成することができる。デバイスの中には、例えば、グループの規模または他の属性に関する制限のために、作成されるグループから除外されるものがある。このような除外されたデバイスは、同一の、または類似した方法で、別のグループ作成プロセスを開始することができ、その結果、（例えば、図３に示したように、）ローカルネットワークは、最終的にグループまたはクラスタに分割される。
【０１１０】
次いで、各グループまたは各クラスタのグループリーダが、次に示す１つまたは複数の基準、または他の基準に基づいて選択される。例えば、グループリーダを判定するために、複数のグループメンバ間で決定する際、考えられ得るグループリーダが有するリソースの豊富さを含む要素が、互いに比較され考慮される。なぜならば、例えば、グループリーダは、ＬＳＭコンポーネント１２０ｂおよびグループメンバと通信し、その結果、この通信を可能にするための十分なリソース（例えば、バッテリ、ＣＰＵ、メモリ、または帯域幅）を必要とするからである。別の例として、考えられ得るグループリーダが接続される大多数のデバイスは、その考えられ得るグループリーダが、関連するグループメンバから情報を集約する際、または関連するグループメンバに対して情報を伝達する際、より効率的に動作することを可能にすることができる。別の例として、考えられ得るグループリーダを、頻繁に、または直前に使用することにより、何らかの条件が満たされるまで、そのデバイスがグループリーダとして再度動作しないようにすることができる。
【０１１１】
グループリーダが決定されると、適切なルーティングプロトコルを選択して、考えられ得るグループメンバデバイスは、互いに適切かつ効率的に、確実に通信できるようになる。例えば、グループに、ラップトップ、ＰＤＡ、またはスマートフォンなどの異種のデバイスが含まれていたとしても、それらの間の通信は可能である必要がある。ルーティングプロトコルの例として、（デバイスの物理的位置に基づく）位置ベースのルーティングプロトコル、および／または、デバイス間の直接的な近接さに基づくトポロジベースのルーティングプロトコルが挙げられる。
【０１１２】
グループリーダ（群）が決定されると、ＬＳＭコンポーネント１２０ｂは、グループリーダ（群）に命令して、その（それらの）関連するグループ（群）のデバイスメタデータ（例えば、デバイスプロファイル）を収集するために、メッセージをグループリーダ（群）に送信することができる（６２２）。デバイスメタデータの収集は、関連するローカルネットワークとデバイスとの電力および／または通信容量を使い果たすことなくデバイスメタデータを収集することができる様々な問い合わせ技術を使用することにより、実行することができる。さらに、このような問い合わせ技術は、ローカルネットワークインフラストラクチャの考えられ得る移植性および非信頼性を考慮に入れることができる。なぜならば、例えば、新たなデバイスが、問い合わせプロセス中、ローカルネットワークに参加することもあるし、または、ローカルネットワークから離れることもからである。
【０１１３】
実行する問い合わせの種類を変えてもよい。例えば、結果の完全性に重点を置いた蓄積問い合わせ（hoarding query）を使用することができる。例えば、前述の蓄積問い合わせは、（まれであり、そのためローカルネットワーク上で簡単に識別できるデバイスを参照する）一意な問い合わせ（unique query）、または、（例えば、特定の建物内の全てのデバイスなどの、領域の全てのデバイス上でサービス配置が生じることになる問い合わせを参照する）代表的な問い合わせ（representative query）を実行することができる。
【０１１４】
これらの蓄積問い合わせとは対照的に、選択的問い合わせ（selective query）には、拡張可能で適応的なクラスタベースのデバイス検索を提供する様々な方法を含めることができる。上記のデバイス検索には、（１）要求されたデバイスが含まれる適切なクラスタの識別と、（２）優先順位の割り当て（ここで、優先順位は、グループリーダに転送する問い合わせに関する順位を評価し、どのグループから、より関連のある結果が期待されるかを示す）とを含めることができる。
【０１１５】
要求されたデバイスが含まれる適切なクラスタの識別に関して、グループメンバの絶対数は、特定のデバイスクラスに属するグループメンバの相対数とそれほど関連性はなくてもよいことを理解されたい。優先順位の割り当てに関して、グループから、ＬＳＭコンポーネント１２０ｂを実行するゲートウェイサーバまでの距離を考慮に入れることができる。すなわち、例えば、ＬＳＭコンポーネント１２０ｂにより近いグループは、データパケットをＬＳＭコンポーネント１２０ｂに送信するために、より少ないホップ数しか必要としない。さらに、比較的より大きな現在のリソース能力を有するグループが好適である。
【０１１６】
一般的にネットワーク内の全ての種類のデバイスを対象とする代表的な問い合わせに関しては、様々な方法を使用することができる。例えば、次に示す優先順位が、継続的に続行される。その優先順位とは、最多の（非特異的な）デバイスを有するグループ、データの問い合わせおよび／または取り出しの並行性、利用可能性の高い帯域幅を有するグループリーダ、最高のリソース能力を有するグループ、および、ホップ数という点でＬＳＭコンポーネント１２０ｂに近いグループである。
【０１１７】
上記の代表的な問い合わせ技術では、グループに含まれるデバイスの絶対数と関連性がある。この場合、代表的な概要が必要とされるので、特定の種類のデバイス間の差異は必要とされなくてもよい。並行性および利用可能性の高い帯域幅を使用して、考えられ得る大量のデバイスプロファイルの高速転送を可能にすることができる。また、並行性および利用可能性の高い帯域幅を使用して、モバイルネットワークおよび信頼性がないと考えられるネットワークにおける問い合わせの配布を効率的に体系化することができる。
【０１１８】
選択的問い合わせでは、期待される結果の完全性よりもパフォーマンスを対象とした類似の技術および考慮が可能である。例えば、「上位Ｎ個」（例えば、ローカルネットワーク上の１０個の最良ノード）および「最初のＮ個」（例えば、ローカルネットワーク上で発見され、ＬＳＭコンポーネント１２０ｂから所定の距離内に位置する最初のデバイス）に関する方法は、識別されたデバイスプロファイルを適切に予め選択することに依存する。
【０１１９】
一般に、これらの選択的問い合わせの例（すなわち「上位Ｎ個」および「最初のＮ個」）の両方は、１つのプロシージャにしたがうことができる。そのプロシージャでは、グループリーダが、全グループメンバからデバイスプロファイルを要求し、次いで、グループリーダが、受信した結果（すなわち、最良の「Ｎ個」のデバイスプロファイル、または最初の「Ｎ個」のデバイスプロファイルのいずれか）を予め選択する。最後に、グループリーダは、結果セットをＬＳＭコンポーネント１２０ｂに転送し、次いで、そのＬＳＭコンポーネント１２０ｂは、最良の「Ｎ個」の結果全体を選択することができる。
【０１２０】
いくつかの実施形態において、現在のデバイスの状態は、恒久的にはモニタリングされないことを理解されたい。代わりに、ローカルネットワーク、およびローカルネットワークのデバイスの現在の状態についての必要な情報は、サービスマッピング要求時に取得することができる。
【０１２１】
各グループリーダが、前述した問い合わせ技術の１つまたは複数を使用して、または他の技術を使用して、それぞれのグループデバイスに問い合わせると、グループリーダは、関連するＬＳＭコンポーネントに転送するために、収集されたデバイスメタデータ（例えば、デバイスプロファイル）をマージすることができる（６２４）。例えば、グループリーダは、その関連デバイスに関するデバイスメタデータの全てを含むＸＭＬファイルを作成することができる。
【０１２２】
このように、ＬＳＭコンポーネントは、既知のサービスメタデータを受信デバイスメタデータとマッチングさせる必要な情報を有する（６２６）。例えば、ＬＳＭコンポーネント１２０ｂは、サービスリポジトリ１２４からサービスメタデータ１２６を取得し、前述したように、複数のデバイスに関するデバイスメタデータ１３０を受信した後、例えば、サービスメタデータ１２６のサービス要件をデバイスメタデータ１３０のデバイスプロファイルとマッチングさせることができる。例えば、サービス要件およびデバイスプロファイルが、予め定められたＸＭＬスキーマにしたがって、それぞれ、ＸＭＬドキュメントで提供される場合、例えば、メモリ、電力および処理パワーに関するパラメータおよび値を互いにマッチングさせ、当該サービスの配置を取扱うことができる少なくとも１つのグループのデバイスに関する何らかのサブセットを判定することができる。
【０１２３】
上記のマッチング動作を試みた結果、配置が実現可能でないと判定された場合（６２８）、上述した様々なオプション（６１４）の１つまたは複数が呼び出される。そのオプションには、管理者に通知すること、待機モードに入ること、少なくとも１つのデバイス上に配置することができる新たなサービスを登録すること、および／または、新たなデバイスまたはデバイス能力を提供することが含まれる。
【０１２４】
しかしながら、配置が実現可能である場合（６２８）、かつ、少なくとも最小数のマッチングするデバイスが配置に関して判定された場合、パフォーマンスメトリックを適用して、どのマッチングされたデバイスが当該サービスの機能を実行するのに最適であるかを判定することができる。例えば、上述した例のように、サービスメタデータ１２６には、サービス要件のうち所定のものの、そのサービス要件の他のものに対する相対的な重みまたは重要性に関する情報を含めることができる。次いで、これらの相対的な重みは、デバイスメタデータと比較するために、パフォーマンスメトリックに組み込むことができる。その結果、どのデバイスがそのサービスの機能を実行するのに最適であるかということにしたがって、マッチングされたデバイスを順位付けおよび／またはフィルタリングすることができる。次いで、上記の最適なデバイスを、当該サービスをそのデバイス上に配置するために、ＬＳＭコンポーネント１２０ｂによって識別し選択することができる。
【０１２５】
したがって、選択されたデバイス（群）におけるサービスの導入（これには、その実行ファイルの導入が含まれることを理解されたい）を実行することができる（６３２）。例えば、図１と関連させて説明したように、サービスインジェクタ１３４を使用して、選択されたデバイス上にサービスをインストールし、そのデバイス上でサービスを開始することができる。上述したように、サービスインジェクタ１３４は、サービスのサービス実行ファイルが含まれる開発プラットフォームとの適合性に基づいて、選択することができる。
【０１２６】
上述した、サービスからデバイスへのマッピングが実行されると、ＧＳＭテーブルおよびＬＳＭテーブルを更新することができる（６３４）。例えば、ＬＳＭコンポーネント１２０ｂおよび／またはグループリーダ（群）によって取得された情報は、ＧＳＭメタデータテーブル１３６内および／またはＬＳＭメタデータテーブル１３８内に反映することができる。例えば、ＬＳＭメタデータテーブル１３８のサービス品質の列４１８を更新して、異なるグループの各々についての新たなリソース使用率を反映することができる。別の例として、ＬＳＭメタデータテーブル１３８のグループＩＤ列４１２を更新して、上述したデバイス発見プロシージャの後に存在する新たな、および／または、様々なグループを反映することができる。
【０１２７】
図７は、図１のシステム１００における再マッピングの実装を示すブロック図である。すなわち、図２Ｂと関連させてすでに説明したように、システム１００は、再マッピングプロシージャに関与することができ、そのプロシージャは、リソース不足のデバイスから、よりパワフルなデバイスにサービスを再配置することにより、改善されたデバイスの活用を可能にする。
【０１２８】
図７において、デバイス１１０および１０８はそれぞれ、図２Ｂの再マッピングプロシージャの元のデバイスおよび選択されたデバイスとして示されている。デバイス１０８および１１０の様々な要素は、明瞭かつ簡潔にするために図７には示していないが、これらの要素には、例えば、図１のコンテキストにおいて、デバイス１０８に関して述べた様々な要素が含まれる。
【０１２９】
元のデバイス１１０は、サービス７０４、サービス７０６およびサービス７０８を格納するメモリ７０２を備えている。同様に、選択されたデバイス１０８は、メモリ１１８を備え、メモリ１１８には、サービス７１２およびサービス７１４とともに、利用可能なストレージ７１０が含まれる。
【０１３０】
システムモニタ１３２には、図７の例に示すように、システムモニタコンポーネント１３２ａおよび１３２ｂを含めることができ、それらのコンポーネントは、サービスマッパ１２０にレポートするために、現在のリソースの利用可能性、および／または、それらのそれぞれのデバイスの使用率に関する情報を検出することができる。他の実施例においては、システムモニタ１３２は、デバイス１０８、１１０から離れた位置に実装することができ、サービスマッパ１２０は、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂおよびＧＬＳＭコンポーネント１２０ｃを含むよう実装することができることは言うまでもない。
【０１３１】
したがって、図７において、モニタコンポーネント１３２ａおよび１３２ｂはそれぞれ、デバイス１０８および１１０に関するリソース使用率、および／または、利用可能性の情報を検出および提供することができる。このモニタリングされた情報に基づいて、サービスマッパ１２０は、サービス７０６を再マッピングする動機付けの存在を判定することができる。動機付けの例については、上記にて提示したが、その動機付けとしては、元のデバイス１１０のリソースレベルが相対的に、または危険なまでに低いと判定されることや、よりパワフルなデバイスまたはリソースが豊富なデバイスがローカルネットワークの範囲内に入ることが挙げられる。
【０１３２】
以下でより詳細に説明するように、図７は、サービス７０６が、元のデバイス１１０から、選択されたデバイス１０８に再マッピングされる例を提示している。一般に、このような再マッピングプロシージャの前または最中に、サービス７０６の関連するサービスメタデータを使用して、サービスマッパ１２０は、サービス７０６（または他のサービス）の移植性をチェックすることができる。例えば、サービスメタデータには、元のデバイスの位置に関する情報を含めることができる（その元のデバイスは、例えば、接続性が弱い位置にある場合、サービス７０６の移植性を制限する場合がある）。別の例として、サービスメタデータには、サービス７０６と、サービス７０６の再マッピングを防止できる元のデバイス１１０との間に存在し得る任意の依存性に関する情報を含めることができる。
【０１３３】
より一般的には、サービス７０６の移植性は、「固定」、「移植可能」、および「部分的に移植可能」として表すことができる。「固定」では、再マッピングが許可されない。「移植可能」では、サービス（および、おそらくサービスの状態）を、あるデバイスから別のデバイスに移植することができる。「部分的に移植可能」では、サービス７０６には、異なる相互作用部分を含めることができ、その部分の全てではなく、一部については、（例えば、複合サービスの場合において、）再マッピングが許可される。
【０１３４】
いくつかの実施形態において、元のデバイス１１０から、選択されたデバイス１０８へのサービス７０６の再マッピングは、例えば、図６と関連させて上述したマッピングプロセスの多くの特徴を共有することができる。したがって、図６のマッピングプロセスに追加した、または、そのマッピングプロセスを修正した再マッピングの特徴を以下でより詳細に説明する。
【０１３５】
例えば、図２Ｂと関連させて説明したように、元のデバイス１１０に関して、実行されているサービス７０６の現在の状態を保存することは必要または有用であり、図７において、メモリ７０２内に格納されたデータファイル７１６を、この目的のために使用することができる。このコンテキストでは、「状態」または「サービスの状態」という用語には、例えば、サービス７０６に関連付けられ、および／または、再マッピングプロセスの前、最中、後にサービス７０６の実行の継続を可能とする全ての関連データを含めることができる。
【０１３６】
どのデータがサービス７０６とともに移植／包含される必要があるかの判定は、例えば、サービスの種類によって異なり得る。例えば、「平均温度」のような集約サービスに関して、最後に計算された温度値を選択されたデバイス１０８に保存および送信することが合理的である場合がある。しかしながら、他の実施形態においては、平均温度サービスの温度履歴全てを送信することが合理的である場合もある。どのサービス／データが移植されるかに関する情報は、対応するサービスメタデータに含めることができる。
【０１３７】
一般に、データファイル７１６を使用して、選択されたデバイス１０８に移植される関連データを保存することができる。デバイス１１０上でサービス７０６が実行されている間、データファイル７１６に継続的にデータを書き込むことができ、それにより、履歴または他のサービスデータを再構築することが可能となる。いずれの場合においても、サービスの再マッピング時に、任意の種類の関連データをデータファイル７１６内に格納することができることを理解されたい。
【０１３８】
さらに、サービスマッパ１２０により実行される再マッピングプロシージャは、一貫性のためにサービスデータおよび／またはデバイスデータをチェックすること、および、それらをデータファイル７１６内に保存することを担当する場合がある。この場合、バッファを使用して、サービスデータの格納および送信を促進することができる。異なるサービスに対し異なるプロシージャを許可することも可能である。そのプロシージャでは、例えば、サービスの状態が可能な再配置の一部にあることを、サービスのサービスメタデータ内に定義することができる。
【０１３９】
いくつかの実施形態において、サービス７０６（例えば、サービス実行ファイル）は、元のデバイス１１０から、選択されたデバイス１０８に直接移植することができる。他の実施形態においては、サービス７０６は、元のデバイス１１０のメモリ７０２内のサービスマッパ１２０により識別することができ、次いで、選択されたデバイス１０８のメモリ１１８上への導入のために、サービスリポジトリ１２４からアクセスすることができる。
【０１４０】
いくつかの例において、再マッピングは、異なる種類のデバイス間で実行することができる。例えば、元のデバイス１１０には、ＰＤＡを含めることができ、選択されたデバイス１０８には、ラップトップコンピュータを含めることができる。このような柔軟性は、適切なサービス実行ファイルを選択することにより得ることができ、そのサービス実行ファイルは、データファイル７１６内で発見されたサービスメタデータを解釈できなければならない。この意味におけるサービスメタデータの解釈には、対応するデータ型をサポートするためのサポート情報を含めることができ、データを表現する異なる機会を含めることができる。例えば、ラップトップは通常、ＰＤＡディスプレイよりも大きな、かつ、高解像度のディスプレイサイズを有する。ＰＤＡから送信されるデータは、例えば、データグラフといった、より洗練された表示形式で表示することができる。さらに、データ格納フォーマットおよび／またはデータ格納技術は、特定のデバイスの種類に固有である。例えば、あるデバイスは、ファイルフォーマット／システムを使用することができ、一方、別のデバイスは、バイナリフォーマット／システムを使用することができる。
【０１４１】
したがって、いくつかの実施形態において、サービスの再マッピングは、同一の予め定められたクラスまたは種類のデバイス間でのみ許可される。他の実施形態においては、変換サービス（図示せず）を使用することができる。その変換サービスは、所与のサービス状態データを、選択されたデバイス１０８がサポートする適切なデータフォーマットに変換する。例えば、このような変換サービスは、選択されたサービス実行ファイルのサービスメタデータを使用して、どのデータ変換が必要であるかを識別することができる。
【０１４２】
図８は、図２Ｂにしたがう再マッピング動作を示すフローチャート８００である。図８において、元のデバイス上で実行されている配置されたサービスを再マッピングする動機付けを判定する（８０２）。例えば、上述したように、デバイスが、メモリまたは電力などの何らかのリソースを使い果たす寸前である（または必要とする最小レベル未満になる）場合がある。図７を参照すると、いくつかの実施形態では、動機付けを判定することには、元のデバイス１１０上で実行されているモニタコンポーネント１３２ｂにおいて動機付け（例えば、低レベルのメモリまたは電力）を検出することを含めることができる。そのモニタコンポーネントは、デバイスのリソースが不足した場合、サービスマッパ１２０に警告または通知を送信することができる。
【０１４３】
あるいは、ネットワーク全体のためにより良くリソースを利用するために、新たな、または変更されたデバイスの状態により、上記の再マッピングが可能になるか、または強制される。新たなデバイスの状態には、自身が新たなサービス提供者として役立つ１つまたは複数の新たなパワフルなデバイスを含めることができる。その後、相対的にパワフルでないデバイス上で実行されているサービスは、ネットワーク内でより良い負荷分散を実現するために、より能力のあるそのデバイスに転送することができる。
【０１４４】
再マッピングの動機付けの別の例には、指定された間隔内にグローバルなモニタリングの一部として再マッピングを行う命令が含まれる。その命令は、例えば、ＧＳＭコンポーネント１２０ａおよび／またはＬＳＭコンポーネント１２０ｂによって開始することができる。上記のグローバルなモニタリングは、他の定義されたシステム制約が違反されたか否かに基づいて、これらの場合における動機付けを判定することができる。例えば、所定のデバイスグループは、例えば、グループメンバが下回るべきではないバッテリの閾値などの所定の不変条件にしたがうのが望ましく、このような不変条件は、システム制約として使用される。例えば、他のグループよりも不可欠な機能（すなわち、より重要なサービス）を表すグループが、ローカルネットワーク１０２内にいくつか存在してもよい。その結果、上記のグループに対して安定した環境を保証するために、前述したバッテリの閾値などの可能な不変条件を、上記の重要なグループに対して定義することができる。
【０１４５】
さらに、異なるサービス品質（ＱｏＳ）属性を、１つまたは複数のグループに対して定義することができ、これらのＱｏｓ属性を、一定の間隔でモニタリングすることができる。これらの実施形態において、所定のＱｏｓ属性に違反することは、再マッピングの動機付けとなり得る。モバイル無線ネットワークのコンテキストにおいて、Ｑｏｓは、サービスレベル属性またはリソースレベル属性のいずれかを指すことができる。サービスレベルでは、信頼性およびパフォーマンスを挙げることができ、一方、リソースレベルでは、ＣＰＵ負荷、メモリ、帯域幅およびバッテリレベルなどの要素が、代表的な属性を表す。一般的に、実行されているサービスの信頼性またはパフォーマンスは、現在のリソース能力に大きく左右される。例えば、より低いバッテリ状態は、近い将来のデバイス不良の可能性を増大させ、そのため、関連するサービスの予想される信頼性の減少に対応する。
【０１４６】
適切な動機付けが判定されると、再マッピングされるサービスに関連付けられたサービスメタデータを判定し（８０４）、複数のデバイスの各々について、現在のデバイスメタデータも判定する（８０６）。例えば、サービスメタデータ１２６は、サービスリポジトリ１２４から判定することができ、デバイスメタデータ１３０は、上記にて提示した様々なサービスからデバイスへのマッピング例のコンテキストで説明した、様々なデバイス検索、グループリーダの形成、および／または、プロファイル問い合わせ、および／または、転送技術を使用して、判定することができる。
【０１４７】
このような技術は、必要に応じて修正されてもよいことは言うまでもない。例えば、サービス７０６が、ローカルネットワーク１０２内でのみ再マッピングされることが許可される場合、（例えば、ＧＳＭメタデータテーブル１３６を使用して、）他のローカルネットワークの検証を行う必要はない。別の例において、再マッピングの動機付けには、新たなデバイスが、ローカルネットワーク１０２に入ることが含まれる場合がある。この場合、その新たなデバイスに関するデバイスメタデータのみが収集される必要がある。したがって、例えば、ＬＳＭコンポーネント１２０ｂは、関連するローカルネットワークのグループリーダから、１つまたは複数のデバイスの集約されたデバイスプロファイル（群）を受信することができる。
【０１４８】
さらに、存在すれば、再マッピングの記述を適用する（８０８）。再マッピングの記述とは一般的に、サービスの技術的要件を指し、その技術的要件は、再マッピングが生じる前に満たされることが必要とされる。このような再マッピングの記述には、例えば、元のデバイスへの初期のサービスマッピングの要件、上述したようなグループの不変条件、または位置の制約を含めることができる。例えば、初期のマッピングが、パフォーマンスメトリックにしたがって最良のデバイスを選択することを必要としなかった場合、図８の再マッピングプロセスは、上記のパフォーマンスメトリックの適用を試みることができる。別の例として、初期グループ内でのサービスの再マッピングの失敗が、結果として、最も近いグループのデバイスへのサービスの移植をもたらす場合、位置の制約を使用することができる。
【０１４９】
次いで、サービスメタデータおよびデバイスメタデータに基づいて、選択されるデバイスを決定することができる（８１０）。例えば、サービスメタデータおよびデバイスメタデータのＸＭＬファイル内において同様にタグ付けされたデータアイテム間で、マッチング動作を実行することができる。さらに、マッチング動作が完了した後、パフォーマンスメトリックにしたがって、サービスを実行するのに最適なマッチングしたデバイスからデバイスを選択するために、パフォーマンスメトリックを適用することができる。
【０１５０】
すでに説明したように、新たなパワフルなデバイスが、ローカルネットワークに入って再マッピングをトリガするときのように、例えば、最初の再マッピングの動機付けの判定に基づいて、選択されるデバイスの存在が、表面上はすでに知られている可能性がある場合があることを理解されたい。このような場合、選択されるデバイスを決定することは、新たに利用可能となったデバイスのデバイスメタデータにマッチング動作および／またはパフォーマンスメトリックを適用することを指すと、さらに考えることができる。なぜならば、考えられ得る再マッピングの動機付けを判定することは、その再マッピングの実際の実現可能性または望ましさを保証するのに十分でない場合があるからである。例えば、デバイスは、多くのメモリおよび／または電力が利用可能な状態でネットワークに入ることができるが、再マッピングを妨害し得る何らかの他の非適合性を有する（例えば、利用可能なサービス実行ファイルがないオペレーティングプラットフォーム／オペレーティングシステムを提供するのみである）場合がある。
【０１５１】
元のデバイス上に存在する現在のサービスの状態を、判定および格納することができる（８１２）。例えば、図７において、サービス７０６の現在の状態は、データファイル７１６内に格納される。サービスの状態には、例えば、最も直近に収集されたデータ、最も直近に計算されたデータ分析、または最近更新されたサービスの履歴を含めることができる。
【０１５２】
次いで、任意の再マッピングルールを判定および適用することができる（８１４）。このコンテキストにおいて、再マッピングルールとは一般に、システムの安定性、パフォーマンス、および／または信頼性を維持するために、許可された再マッピングを別の方法で防止するルールのことを指す。例えば、このようなルールの１つにより、特定のデバイスまたはデバイスのペアに関して実行できる再マッピングの回数または頻度を制限することができる。例えば、デバイス１０８が、サービス７０６の再マッピング用の十分なメモリ空間を提供する場合、後続の再マッピングプロセスが、デバイス１１０上の十分なメモリを解放して、またデバイス１１０にサービス７０６を再マッピングする動機付けの判定をトリガすることになる。すなわち、再マッピング動作そのものが、後続の再マッピングをトリガする。したがって、これにより、交互に続く再マッピングのループが生じ得る。
【０１５３】
したがって、再マッピングルールの最初の例は、デバイスメタデータ（例えば、デバイスプロファイル）の順序に基づくことができる。例えば、式（２）に類似した重み付けされたメトリックを使用して、すなわち、重み付けされたリソース属性に基づいて、各デバイスプロファイルに数値を割り当てることができる。次いで、再マッピングプロセスが頻繁に変わる問題を解決するために、元のデバイスの計算値と、選択されたデバイスの計算値との間に生じる差異が、何らかの定義された閾値より大きい場合に限り、再マッピングを実行する再マッピングルールを作成することができる。したがって、この閾値に応じて、元のデバイスより非常に優位なリソース能力を有する１つまたは複数のデバイスが利用可能である場合に、再マッピングを開始することになる。
【０１５４】
再マッピングルールの２番目の例において、各デバイスが再マッピングプロセス（群）に関与する頻度を判定することができる。次いで、交互に続く再マッピングを回避するために、元のデバイスは、所定の規定された時間が経過した場合に、再び対象のデバイスまたは選択されたデバイスになることができる。したがって、全てのデバイスは、そのデバイスが再マッピングプロセスに関与した最後の時間を示すローカルタイマを有することができる。他の実施形態においては、ＬＳＭコンポーネント１２０ｂにより、１つまたは複数のグローバルタイマを実装することができる。そのタイマは、ローカルネットワークにおける１つまたは複数のグループの、１つまたは複数のデバイスに適用される。このようなタイマは通常、各再マッピングの後にリセットすることができる。
【０１５５】
他の再マッピングルールを定義および実装できることは言うまでもない。さらに、上述した２つのルールの例の組合せを含む、これらの再マッピングルールの様々な組合せを使用することができる。
【０１５６】
再マッピングルールが満たされた場合、選択されたデバイスにサービスを再配置することができる（８１６）。例えば、ＬＳＭコンポーネント１２０ｂは、上述したように、例えば、適切なサービスインジェクタを使用して、サービスリポジトリ１２４から、選択されたデバイスにサービス実行ファイルを転送することができる。
【０１５７】
ＬＳＭコンポーネント１２０ｂはまた、例えば、データファイル７１６を使用して、サービスの状態の転送を開始することもでき、例えば、再び適切なサービスインジェクタを使用して、選択されたデバイス上のサービスを開始することができる（８１８）。最後に、図８において、ＬＳＭコンポーネント１２０ｂは、元のデバイス上のサービスに対して、停止命令を送信することができる（８２０）。いくつかの実施形態において、元のデバイス上のサービスを実際に停止することは、送信が完了した後に実現することができる。例えば、上述したように、危険な状況を検出または回避するために使用されるサービスは、再マッピングまたは再配置されたサービスが選択されたデバイス上のその新たな位置から制御を受け継ぐ準備ができるまで、継続することが要求される。
【０１５８】
図９〜図１７は、上述した、サービスからデバイスへのマッピング技術および／または再マッピング技術の様々な例を提示している。図９は、３階層サービスマッパ１２０をＯＳＧｉ実装したクラス図のブロック図であり、ＧＳＭコンポーネント１２０ａ、ＬＳＭコンポーネント１２０ｂ、および、（図１のＧＬＳＭコンポーネント１２０ｃを実行する）デバイス１０８を含む。
【０１５９】
図９の例において、図示したコンポーネントの各々に対する適切なデバイスの例を、以下でより詳細に説明する。ＯＳＧｉバンドルは、各々のデバイス上にインストールされ、ＯＳＧｉ環境によって管理される。したがって、バンドルは、互いに通信して、本明細書で説明したサービスからデバイスへのマッピング（および／または再マッピング）を実装することができる。
【０１６０】
より詳細には、図９の例において、ＧＳＭコンポーネント１２０ａは、インストールされたＧＳＭバンドル９０２を実行するラップトップコンピュータによって実装することができる。ＧＳＭバンドル９０２は、ＪＳＰ（Java Server Page：登録商標）を呼び出すことによって、サービスマッピングおよびサービス配置の開始を管理する。ＪＳＰ（登録商標）は、ウェブサーバ上で動的なウェブページを生成する公知技術の一例であり、ＧＳＭメタデータテーブル１３６を表示する（図１０および図１７を参照しながら、以下でより詳細に説明する）。上述したように、この実装は単に１つの例にすぎず、他の実装においては、サービスマッピングは、例えば、ＧＳＭコンポーネント１２０ａに関連付けられたアプリケーションプログラムインタフェース（ＡＰＩ：Application Program Interface）を使用して、別のシステムコンポーネントからの呼び出しによって開始されてもよいことは言うまでもない。ＧＳＭバンドル９０２を使用して、サービスからデバイスへのマッピングの結果に基づいて、ＧＳＭメタデータテーブル１３６を更新することもできる。
【０１６１】
図９におけるＬＳＭコンポーネント１２０ｂは、ＧＳＭコンポーネント１２０ａより少ない計算リソースしか有さなくてもよいゲートウェイサーバとすることができる。ＬＳＭコンポーネントは、インストールされたＬＳＭバンドル９０４を有するゲートウェイとしての役割を果たす。そのＬＳＭバンドル９０４は、ＧＳＭコンポーネント１２０ａからサービスマッピング要求を受信し、次いで、サービスからデバイスへのマッピングを実行する。詳細には、ＬＳＭバンドルは、サービスからデバイスへのマッピング要求を転送し、ローカルネットワーク（のグループ）内のデバイスのデバイスプロファイルを収集し、デバイスプロファイルまたは他のデバイスメタデータをサービスメタデータ（例えば、要件）とマッチングさせることができる。したがって、ＬＳＭバンドル９０４は、デバイスグループ（群）のグループリーダ（群）に、プロファイルが必要であることを通知し、ＧＳＭコンポーネント１２０ａにマッチング動作の結果を通知し、ＬＳＭメタデータテーブル１３８を更新することもできる。
【０１６２】
図９におけるデバイス１０８には、インストールされたグループリーダバンドル９０６を実行するＰＤＡが含まれる。グループリーダバンドル９０６は、グループデバイスのプロファイルまたは他のデバイスメタデータを問い合わせ／検索し、そのプロファイルを単一のメッセージにマージし、そのプロファイルを含むそのメッセージをＬＳＭコンポーネント１２０ｂに送信することができる。グループリーダバンドル９０６は、例えば、ＬＳＭメタデータテーブル１３８内に含めるために、グループ情報を更新することもできる。
【０１６３】
最後に、図９において、デバイス１１０は、グループリーダ１０８からのプロファイルの要求を受信し、その要求に対して適切なプロファイルをもって応答するグループメンバとして示されている。デバイス１１０は、マッピングまたは再マッピングされているサービスを最終的に受信し、このようなマッピングおよび再マッピングの結果は、グループリーダデバイス１０８に同様に報告することができることは言うまでもない。
【０１６４】
図１０は、サービスからデバイスへのマッピングを開始する前のＧＳＭテーブルの例を示すスクリーンショット１０００である。図１０の例において、上述したように、スクリーンショット１０００は、ＪＳＰ（登録商標）ページ（または、任意の種類の対話ツール）を表すことができ、ＪＳＰ（登録商標）上では、管理者または他のユーザは、最初にデバイスの種類を検索することができ、すでにインストールされたサービスは、識別されたローカルネットワーク内に存在し得る。例えば、ＧＳＭメタデータテーブル１３６は、図３の施設安全管理コミュニティ３０２および資産追跡コミュニティ３０４の両方についての情報を含むものとして示される。
【０１６５】
したがって、例えば、管理者は、例えば、利用可能なデバイスを選択するためのドロップダウンリスト１００２、および／または、利用可能なサービスを選択するためのドロップダウンリスト１００４を使用して、ＧＳＭメタデータテーブル１３６のデバイスおよび／またはサービスを選択することができる。上記の選択リストは、（異なるローカルネットワーク内の）企業内に存在する利用可能な全てのデバイスと、サービスリポジトリ１２４内に格納された全てのサービスとを示すことができる。したがって、管理者は、様々な種類の、サービスからデバイスへのマッピングを選択することができる。例えば、管理者は、リスト１００２において選択されたデバイスの種類（例えば、ＰＤＡ）の全デバイス上で、サービスマッピング／サービス配置を開始することもできるし、特定の種類のデバイスのうち利用可能な最良のデバイス上に、選択されたサービスを配置することもできる。
【０１６６】
最初の例において、サービスマッパ１２０は、「チェックおよび配置」ボタン１００６を選択したことに応答して、選択されるサービスの技術的要件が、現在のデバイス能力によって満たされるか否かを調べることができる。２番目の例において、サービスマッパは、管理者が「最良のデバイスをチェックおよび配置」ボタンを選択したことに基づいて、利用可能なリソースに関して最もパワフルなデバイスを検出することができる。最後に、図１０において、リセットボタン１０１０により、管理者は、スクリーンショット１０００のＪＳＰ（登録）のフィールドをリセットすることができる。「配置に関する通知」フィールド１０１２は、配置後（および／または試みた配置）の情報（図１６において示す例）を管理者に提供する。明らかなように、ローカルネットワーク、デバイス、および／またはサービスの説明した識別は、管理者により手動で実行することもできるし、または自動プロセスの一部として実行することもできる。
【０１６７】
管理者が、ボタン１００６または１００８を選択することにより、サービスからデバイスへのマッピングを開始すると、サービスの名前、デバイスの種類、および配置モード（例えば、いくつかのデバイス、全てのデバイス、または最良のデバイス（群））などの入力パラメータが、ＬＳＭコンポーネント１２０ｂに転送される。次いで、ＬＳＭバンドル９０４は、これらの入力パラメータを受信し、サービスリポジトリ１２４への接続をオープンして、そのサービスの技術的要件に関する情報が含まれる対応するサービスメタデータ（例えば、サービス記述ファイル）を取り出す。
【０１６８】
図１１は、上記のサービスメタデータファイル１１００の例である。詳細には、図１１は、ＸＭＬファイル（「ｓｅｒｖｉｃｅ．ｘｍｌ」）を示している。このＸＭＬファイルでは、セクション１１０２により、そのファイルがサービスメタデータ（例えば、サービス要件）記述ファイルであると識別される。ファイルの残りの部分にあるセクション１１０４には、図示するように、メモリ、ＣＰＵ、バッテリ、プラットフォーム、および接続特性を含むサービスパラメータに関する様々な要件が含まれる。図１２は、図１１のサービスメタデータファイルの特定インスタンス１２００の例である。図１１には、特定のパラメータが、様々なサービス要件に対して示されている。したがって、図１２は、図１のサービスメタデータ１２６のインスタンスの特定の例として理解されたい。詳細には、例えば、セクション１４０２により、３００ＭＢというメモリ要件、２００ＭＨｚというＣＰＵ速度、および、図示した他のパラメータに関して対応する指標が指定される。その他のパラメータは、バッテリ寿命、プラットフォーム情報、および接続特性に関する。図示した記述ファイルは、ＸＭＬファイルとして示されているが、他の種類のファイルフォーマットおよび／または表現フォーマットを使用してもよいことを理解されたい。
【０１６９】
ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂが、サービス記述ファイル（例えば、図１２に示すファイル）を受信して保存した後、上述した、様々なサービスからデバイスへのマッピング動作（例えば、図２Ａおよび図６）を実行してもよい。例えば、メッセージを、グループリーダデバイス１０８に送信することができ、そのグループリーダデバイスは、グループメンバデバイスのデバイスメタデータ（例えば、デバイスプロファイル）全てを収集し、そのプロファイルを単一のＸＭＬファイル（ｐｒｏｆｉｌｅｓ．ｘｍｌ）にマージすることができる。このＸＭＬファイルは、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに返送される。図１３は、上記のＸＭＬファイルの部分的な例１３００である。図１３において、最初のセクション１３０２により、そのファイルがデバイスメタデータ（例えば、デバイスプロファイル）記述ファイルであると識別される。ファイルの残りの部分にあるセクション１２０４には、デバイスの記述（例えば、名前、種類、またはベンダ）、およびハードウェアの記述（例えば、ＣＰＵの記述、接続特性、およびメモリの記述）を含むサービスパラメータに関する様々な要件が含まれる。前述したように、図１３は、部分的な例であり、上記の説明から、様々な他のデバイス特性がデバイスプロファイル内に含まれてもよいことを理解されたい。例えば、図１４は、図１３のデバイスプロファイルの完全な例である特定インスタンス１４００を示しており、記述部１４０２、ハードウェア記述部１４０４、ソフトウェア記述部１４０６、およびデバイス状態部１４０８を含む。図示したように、これらの部分１４０２〜１４０８の各々には、図１と関連させて上記にて提示した例に対応する様々なデバイスパラメータ、または他のデバイスパラメータを含めることができる。したがって、図１４は、図１におけるデバイスメタデータ１３０のインスタンスの特定の例として理解されたい。
【０１７０】
ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、現在のデバイス能力の全てを含むデバイスメタデータＸＭＬファイルを受信した後、デバイスメタデータファイルをサービスメタデータファイルとマッチングさせることができる。例えば、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、両方のＸＭＬファイル、すなわち、図１３のｓｅｒｖｉｃｅ．ｘｍｌファイル、および、図１５のｐｒｏｆｉｌｅｓ．ｘｍｌを解析することができる。次いで、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、サービスの技術的要件を、現在のデバイスリソースと比較することができる。例えば、ｓｅｒｖｉｃｅ．ｘｍｌ内に含まれる＜ｍｅｍｏｒｙ＞タグの値は、ｐｒｏｆｉｌｅｓ．ｘｍｌファイル内に含まれる対応する＜ｍｅｍｏｒｙ＞タグの値と比較されることになる。
【０１７１】
最後に、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、ラップトップ／ＧＳＭコンポーネント１２０ａに、要求されたサービスを配置できるデバイスについての情報を通知する。利用可能なデバイスがない場合、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、サービスの技術的要件を満たす利用可能なデバイスがないことを、ラップトップ／ＧＳＭコンポーネント１２０ａに通知することができ、例えば、利用可能なメモリが十分にないといった、そのサービスをその特定のデバイス上に配置できない具体的な理由を提供することができる。
【０１７２】
例えば、図１０に関して、管理者は、倉庫内にある商品の現在の温度を示す温度サービスをＰＤＡ上に配置したいと望む場合がある。この例において、倉庫内には、５個のＰＤＡがあるとする。管理者は、図１０のスクリーンショット１０００のＪＳＰ（登録商標）にアクセスして、リスト１００２および１００４をそれぞれ使用することにより、デバイス（群）およびサービスを選択することができる。次いで、管理者は、「チェックおよび配置」ボタン１００６を選択することができる。
【０１７３】
結果として、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、すでに説明したように、図１５のログウィンドウ１５００に提示されている上記のパフォーマンスの結果を用いて、実行することができる。詳細には、セクション１５０２は、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂが、サービスリポジトリ１２４にアクセスして、図１２に示したようなサービスメタデータ（例えば、要件）ファイルを取得することを示している。セクション１５０４において、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、図１４に示したようなグループ内の各デバイスに関するデバイスメタデータ（例えば、デバイスプロファイル）を取得する命令を含むメッセージをグループリーダデバイス１０８に送信し、次いで、そのメッセージが保存される。
【０１７４】
次いで、セクション１５０６においてマッチング動作を実行し、この例では、そのマッチング動作において、サービスのメモリ要件をデバイス特性とマッチングさせる。図示するように、５つのチェックされたデバイスプロファイルのうち４つが十分なメモリを有し、５番目のデバイス（ＰＤＡ）は、十分なメモリを有していない。したがって、図１６において、スクリーンショット１０００のＪＳＰ（登録商標）の更新バージョンであるスクリーンショット１６００が示され、そのスクリーンショット１６００において、「配置に関する通知」フィールド１０１２により、サービスが、５つのデバイスのうち４つにインストールされ、５番目のデバイスは十分なメモリを有さなかったことが、管理者に通知される。
【０１７５】
上記では、１つの例しか提示されていないが、多数の他の例が可能であることは言うまでもない。例えば、管理者は、５つの利用可能なＰＤＡのうち、最良のＰＤＡ上にのみサービスを配置することを望む場合もある。この場合、管理者は、単に、「最良のデバイスをチェックおよび配置」ボタン１００８を選択することができ、現在の例においては、サービスマッパ１２０が、最多メモリ容量を有するＰＤＡを識別して、そのＰＤＡにサービスを配置することになる。
【０１７６】
図１７は、再マッピング動作を実行するためのスクリーンショット１７００である。詳細には、図１７は、ＪＳＰ（登録商標）が使用される例を示しており、そのＪＳＰ（登録商標）には、再マッピングプロセスを決定する再マッピングルールを識別するためのフィールド１７０２が含まれる。さらに、フィールド１７０４を使用して、デバイスの種類を識別し、フィールド１７０６を使用して、デバイスの特性を識別し、フィールド１７０８を使用して、そのルールのパラメータ（群）の閾値を識別する。フィールド１７１０は、そのルールの実装を説明するコメント用の領域を提供する。この場合、そのルールは、ネットワーク／グループ内のＰＤＡのメモリが、指定されたパラメータ閾値３０ＭＢに達した場合に、再マッピングを実行することを明示している。すなわち、例えば、そのルールは、システムモニタコンポーネントが、５つの利用可能なＰＤＡのうちの１つまたは複数のＰＤＡが、指定されたサービスをそのＰＤＡ上に（再）配置するために、少なくとも３０ＭＢのメモリを提供できるか否か、および、いつ提供できるかを判定できることを明示している。スクリーンショット１７００において、保存ボタン１７１２により、管理者は、表示されたルールを保存することができ、リセットボタン１７１４により、管理者は、スクリーンショット１７００のフィールド１７０２〜１７１０の内容をリセットすることができる。最後に、「ルールを表示」ボタン１７０６により、管理者は、以前に作成された１つまたは複数の任意のルールを見ることができる。さらに、すでに述べたように、ＧＳＭコンポーネント１２０ａのＡＰＩを使用することにより、図１７と関連させて上述した１つまたは複数の様々な機能は、人間のユーザによってではなく、システムコンポーネントによって実行することができる。
【０１７７】
図２Ｂおよび図８と関連させてすでに説明したように、再マッピング中、再マッピングプロセスは、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂによりサポートすることができる。例えば、再マッピングを可能にするため、ＬＳＭバンドル９０４は、管理者が任意の再マッピングルールを定義したか否かを監視するように設計された制御スレッドを開始することができる。新たなルールが管理者によって設定された場合、スレッドは、それを受信して保存する。サービスの再マッピングを実行する必要がある場合、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、相対的にリソース不足なデバイスから、相対的にリソース豊富なデバイス（例えば、現在利用可能な最もリソース豊富なデバイス）にサービスを再配置することができる。
【０１７８】
グループリーダデバイス１０８が、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂから要求を受信すると、グループリーダデバイス１０８は、関連するグループのデバイスプロファイル全てを収集し始める。この例においては、グループには、４つの他のグループメンバが含まれるので、グループリーダデバイス１０８は、グループメンバにメッセージを送信することができ、グループメンバの各々は、それに対して、対応するデバイスメタデータ（例えば、デバイスプロファイル）をもって応答することができる。
【０１７９】
すでに説明したように、次いで、グループリーダデバイス１０８は、送信されてきたデバイスプロファイルを受信し、それらを（例えば、図１３のｐｒｏｆｉｌｅｓ．ｘｍｌメッセージフォーマットにしたがう）単一のＸＭＬファイルにマージすることができる。全てのプロファイルが受信されてマージされると、グループリーダデバイス１０８は、収集したデバイスプロファイルをゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに送信することができる。
【０１８０】
ＰＤＡバンドル９０６は、追加で、または代替として、デバイスの状態を監視する制御スレッドを開始してもよい。したがって、新たなデバイスがネットワークに参加した場合、このスレッドにより、グループリーダデバイス１０８に通知することができる。例えば、上記の新たなデバイスは、「ｈｅｌｌｏメッセージ」をデバイス状態スレッドに送信するよう要求される。グループリーダデバイス１０８が、上記の新たなグループメンバを認識した場合、（新たなプロファイルを含む）デバイスプロファイルを収集するための収集プロセスを開始することができる。次いで、グループリーダデバイス１０８は、マージしたプロファイルを、（上述したように）ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂに送信することができ、その結果、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、次いで、再マッピングを実行する必要があるか否か、および、再マッピングの方法を判定することができる。
【０１８１】
マージされたデバイスプロファイルを受信する際、ゲートウェイサーバ／ＬＳＭコンポーネント１２０ｂは、本明細書で説明したマッチング動作を実行することができ、適切なパフォーマンスメトリックを実装することができる。次いで、少なくとも１つのデバイスがパラメータの閾値（群）にマッチングし、その結果、再マッピングルール（群）が満たされると仮定すると、本明細書で説明したように、関連するサービスを再マッピングおよび再配置することができる。
【０１８２】
本明細書で説明したように、アーキテクチャのフレームワークと、サービスからデバイスへのマッピングアルゴリズムとにより、適切なスマートアイテムデバイスに対する自動的でインテリジェントなサービスのマッピングが可能となる。マッピングメカニズムは、サービスのセマンティックス（例えば、メモリまたはＣＰＵパワー、期待される入力／出力、挙動および可能な他の特性などの技術的要件）と、利用可能なデバイス（例えば、メモリ、ＣＰＵ、およびバッテリ寿命、ならびに信頼性といった観点における技術的能力）との洗練された記述に基づく。配置される所与のサービスに関して、この知識に基づいて、サービスマッパは、そのサービスをホストすることができるデバイスの候補を識別する。次いで、サービスおよびデバイスの技術的要件および特性にそれぞれ基づいて、（例えば、処理能力およびメモリ能力の点で）最もコスト効率のよいデバイスが、自動的な配置のために選択される。
【０１８３】
本明細書で説明した様々な技術の実施形態は、デジタル電子回路、もしくはコンピュータハードウェア、コンピュータファームウェア、コンピュータソフトウェア、またはそれらの組合せを用いて実装することができる。また、これらの実施形態は、コンピュータプログラム製品、すなわち、情報キャリア内で具現化されたコンピュータプログラムとして、実装することもできる。その情報キャリアとして、例えば、データ処理装置により実行するための、または、データ処理装置の動作を制御するためのマシンが読取り可能な記憶デバイスまたは伝播信号が挙げられる。そのデータ処理装置として、例えば、プログラマブルプロセッサ、１つのコンピュータ、または複数のコンピュータが挙げられる。上述したコンピュータプログラム（群）などのコンピュータプログラムは、コンパイル言語またはインタプリタ言語を含む任意の形態のプログラミング言語を用いて記述することができ、スタンドアロンプログラム、または、コンピュータ環境において使用するのに適したモジュール、コンポーネント、サブルーチン、もしくは他のユニットなどの任意の形態で配置することができる。コンピュータプログラムは、１つのサイトにある１つのコンピュータ上もしくは複数のコンピュータ上、または多数のサイトに分散されて通信ネットワークを介して相互接続された１つのコンピュータ上もしくは複数のコンピュータ上で実行するために配置することができる。
【０１８４】
方法のステップは、１つまたは複数のプログラマブルプロセッサにより実行することができる。そのプログラマブルプロセッサは、入力データに対して操作を行い、出力を生成することにより、関数を実行するコンピュータプログラムを実行する。フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または特定用途向け集積回路（ＡＳＩＣ：Application-Specific Integrated Circuit）のような特定用途向け論理回路により、方法のステップが実行されてもよいし、その特定用途向け論理回路として、装置が実装されてもよい。
【０１８５】
コンピュータプログラムの実行に適したプロセッサには、例えば、汎用マイクロプロセッサおよび特定用途のマイクロプロセッサの両方、および任意の種類のデジタルコンピュータにおける１つまたは複数の任意のプロセッサが含まれる。一般に、プロセッサは、ＲＯＭ（Read Only Memomy）、ＲＡＭ（Random Access Memory）、または、それら両方から、命令およびデータを受信する。コンピュータの要素には、命令を実行するための少なくとも１つのプロセッサと、命令およびデータを格納するための１つまたは複数のメモリデバイスとを含めることができる。コンピュータには一般に、例えば、磁気ディスク、光磁気ディスク、または光ディスクなどの、データを格納するための１つまたは複数の大容量記憶デバイスを含めることができるし、あるいは、コンピュータは一般に、そのデバイスに対してデータを送受信するために動作可能なように結合することができるし、あるいは、その両方が可能である。コンピュータプログラムの命令およびデータを具現化するのに適した情報キャリアには、あらゆる形態の不揮発性メモリが含まれる。その不揮発性メモリには、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクまたは取外し可能なディスクなどの磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクが含まれる。プロセッサおよびメモリは、特殊目的の論理回路により補完されてもよいし、特殊目的の論理回路に組み込まれてもよい。
【０１８６】
ユーザとの対話を提供するために、実施形態は、例えば、ユーザに情報を表示するためのＣＲＴ（Cathode Ray Tube）モニタまたはＬＣＤ（Liquid Crystal Display）モニタなどのディスプレイデバイス、ならびに、ユーザがコンピュータに入力を提供できるキーボードや、例えば、マウスまたはトラックボールなどのポインティングデバイスを有するコンピュータ上で実装することができる。同様に、ユーザとの対話を提供するために、他の種類のデバイスを使用してもよい。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックなどの任意の形態の感覚フィードバックとすることができる。ユーザからの入力は、音響入力、会話入力、または触覚入力などの任意の形態で受信することができる。
【０１８７】
実施形態は、例えばデータサーバのようなバックエンドコンポーネント、例えばアプリケーションサーバのようなミドルウェアコンポーネント、例えばユーザが実施形態と対話できるウェブブラウザ、もしくはグラフィカルユーザインタフェースを有するクライアントコンピュータのようなフロントエンドコンポーネント、または、上記のバックエンドコンポーネント、ミドルウェアコンポーネント、フロントエンドコンポーネントの任意の組合せが含まれるコンピューティングシステムを用いて実装することができる。コンポーネントは、例えば通信ネットワークのような任意の形態のデジタルデータ通信媒体を介して相互接続することができる。通信ネットワークの例には、ＬＡＮ、および、例えばインターネットなどのＷＡＮが含まれる。
【０１８８】
説明した実施形態の特徴を、本明細書で例示したが、多数の変形形態、置換形態、変更形態および均等形態が、当業者には思い浮かぶであろう。したがって、添付の特許請求の範囲は、上記の変形形態および変更形態の全てを、本発明の実施形態の要旨の範囲内に包含するよう意図するものであることを理解されたい。
【図面の簡単な説明】
【０１８９】
【図１】スマートアイテムデバイスに関して、サービスからデバイスにマッピングするシステムを示すブロック図である。
【図２Ａ】図１のシステムの動作例を示すフローチャートである。
【図２Ｂ】図１のシステムの動作例を示すフローチャートである。
【図３】図１のシステムの３階層アーキテクチャを使用するシステムを示すブロック図である。
【図４Ａ】グローバルサービスメタデータを示す表である。
【図４Ｂ】ローカルサービスメタデータを示す表である。
【図５】図１および図３のシステムを実装するスマートアイテムインフラストラクチャを示すブロック図である。
【図６】サービスからデバイスへのマッピング動作を示すフローチャートである。
【図７】図１のシステムにおける再マッピングの実装を示すブロック図である。
【図８】図２Ｂにしたがう再マッピング動作を示すフローチャートである。
【図９】図１および／または図７のシステムの実装例を示すブロック図である。
【図１０】人間のユーザが対話的にサービスからデバイスへのマッピング要求を指定するサーバページのスクリーンショットを示す図である。
【図１１】サービスメタデータを表すファイルフォーマット例を示す図である。
【図１２】図１１の形式を使用したサービスメタデータファイル例を示す図である。
【図１３】デバイスメタデータを表すファイルフォーマット例を示す図である。
【図１４】図１３の形式を使用したデバイスメタデータファイル例を示す図である。
【図１５】サービスからデバイスへのマッピング要求の結果を示すスクリーンショットを示す図である。
【図１６】サービスからデバイスへのマッピング要求の結果を示すサーバページのスクリーンショットを示す図である。
【図１７】再マッピングプロシージャの一部を示すスクリーンショットを示す図である。
【符号の説明】
【０１９０】
１０８、１１０、１１２、１１４、３１２〜３４０ デバイス
３１２、３２２、３２８、３３６ グループリーダデバイス
１０２、３０６、３０８、３１０ ローカルネットワーク
１０６ ワイドエリアネットワーク
１２０ サービスマッパ
１２０ａ グローバルサービスマッパコンポーネント
１２０ｂ ローカルサービスマッパコンポーネント
１２０ｃ グループリーダサービスマッパコンポーネント
１２２、７０４〜７１４ サービス
１２４ サービスリポジトリ
１２６ サービスメタデータ
１３０ デバイスメタデータ
１３２ システムモニタ
１３２ａ、１３２ｂ モニタコンポーネント
【特許請求の範囲】
【請求項１】
デバイスネットワークを介して使用する階層型多層マッピングおよびモニタリングシステムであって、
サービスリポジトリ（１２４）であって、
少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたグローバルデバイスメタデータ（１３６）を追跡するように構成されたグローバルサービス（１２０、１２０ａ、１３２、９０２）と、
前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたローカルデバイスメタデータ（１３８）を追跡して、前記ローカルデバイスメタデータ（１３８）に基づいて、前記グローバルデバイスメタデータ（１３６）を更新するように構成されたローカルサービス（１２０、１２０ｂ、１３２、９０４）と、
前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイス（１０８〜１１４、３１２〜３４０）に問い合わせ、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）に送信して前記ローカルデバイスメタデータ（１３８）を更新するためにグループレベルのデバイスメタデータを集約するように構成されたグループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）と
を格納するように構成されたサービスリポジトリと、
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれのサービスメタデータ（１２６）を、少なくとも１つのグローバルデバイス（１２０ａ）、少なくとも１つのローカルデバイス（１０２ｂ）、および少なくとも１つのグループリーダデバイス（１０８）それぞれのデバイスメタデータ（１３０）に関連付け、前記関連付けに基づいて、前記サービスを各前記デバイスにマッピングするように構成されたサービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）と
を備えたことを特徴とするシステム。
【請求項２】
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれは、グローバルサービスマッパコンポーネント（１２０ａ）、ローカルサービスマッパコンポーネント（１２０ｂ）、およびグループリーダサービスマッパコンポーネント（１２０ｃ）それぞれに関連付けられることを特徴とする請求項１に記載のシステム。
【請求項３】
前記サービスマッパコンポーネント（１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルデバイスメタデータ（１３６）と、前記ローカルデバイスメタデータ（１３８）と、前記グループリーダデバイスメタデータとのうちの少なくとも１つに基づいて、前記サービスリポジトリ（１２４）から、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の機能に関連付けられたデバイスネットワークサービス（１２２、１２８、７０４〜７１４、９０２〜９０６）を、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の前記問い合わされたデバイスのうちの１つにマッピングするように構成されることを特徴とする請求項２に記載のシステム。
【請求項４】
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれは、グローバルサービスモニタコンポーネント（１２０ａ、９０２）、ローカルサービスモニタコンポーネント（１２０ｂ、９０４）、およびグループリーダサービスモニタコンポーネント（１２０ｃ／１３２ａ、９０６）それぞれに関連付けられることを特徴とする請求項１に記載のシステム。
【請求項５】
前記サービスモニタコンポーネント（１２０ａ、１２０ｂ、１２０ｃ／１３２ａ）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたモニタリングデータを、前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）に提供するように構成され、前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、デバイスネットワークサービス（１２２、１２８、７０４〜７１４）を、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイスにマッピングするように構成されることを特徴とする請求項４に記載のシステム。
【請求項６】
前記グローバルサービスモニタコンポーネント（１２０ａ）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたモニタリングデータを、アプリケーションのユーザインタフェース（１０００、１６００、１７００）に提供するように構成されることを特徴とする請求項４に記載のシステム。
【請求項７】
前記サービスリポジトリ（１２４）は、前記グループリーダサービスモニタコンポーネント（１３２ａ）に通信するためのデバイスレベルのデバイスメタデータを取得するように構成されたデバイスレベルのサービスモニタコンポーネント（１３２ｂ）を含むことを特徴とする請求項４に記載のシステム。
【請求項８】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記デバイスレベルのサービスモニタコンポーネント（１３２ｂ）を、前記少なくとも１つのデバイスネットワークのデバイス（１１０）にマッピングするように構成されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記グローバルデバイスメタデータ（１３６）は、複数のローカルサービス（４０２、４０４、４０８）に関する情報を含み、
前記複数のローカルサービスの各々は、少なくとも１つのグループリーダサービス（１２２）と通信し、
前記グローバルデバイスメタデータ（１３６）は、前記複数のローカルサービスに関連付けられた前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）における１つまたは複数のデバイスのクラス（４０６）を識別し、さらに、前記少なくとも１つのデバイスネットワーク上に配置された１つまたは複数のサービスのクラス（４０８）を識別する
ことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ローカルデバイスメタデータ（１３８）は、複数のグループリーダサービス（１２０ｃ、４１２）に関する情報を含み、
各前記グループリーダサービスは、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイスと通信し、
前記ローカルデバイスメタデータ（１３８）は、前記少なくとも１つのデバイスの位置を示す位置情報（４２０）とともに、デバイス固有の情報およびサービス固有の情報（４１４〜４１８）を識別する
ことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記グループリーダデバイスメタデータ（１３０）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイス（１０８〜１１４）に関連付けられたデバイス固有のデバイスメタデータを含み、
前記グループリーダサービス（１２０ｃ、１３２ａ）は、前記デバイス固有のデバイスメタデータを前記ローカルサービス（１２０ｂ）に送信する前に、前記デバイス固有のデバイスメタデータを処理するように構成される
ことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルサービス（１２０ａ、９０２）のうちの少なくとも１つと、前記ローカルサービス（１２０ｂ、９０４）のうちの少なくとも１つと、前記グループリーダサービス（１２０ｃ、９０６）のうちの少なくとも１つとのうちのいずれかを、前記グローバルデバイス（１２０ａ）、前記ローカルデバイス（１２０ｂ）、前記グループリーダデバイス（１０８）から、それぞれ、第２グローバルデバイス、第２ローカルデバイス、第２グループリーダデバイスに再マッピングするように構成されることを特徴とする請求項１に記載のシステム。
【請求項１３】
単一のデバイスが、前記少なくとも１つのグローバルデバイス（１２０ａ）と、前記少なくとも１つのローカルデバイス（１２０ｂ）と、前記少なくとも１つのグループリーダデバイス（１０８）とのうちの少なくとも２つとして動作し、
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルサービス（１２０ａ、９０２）と、前記ローカルサービス（１２０ｂ、９０４）と、前記グループリーダサービス（１０８、９０６、１３２ａ）とのうちの少なくとも２つを、前記単一のデバイスにマッピングするように構成される
ことを特徴とする請求項１に記載のシステム。
【請求項１４】
グループリーダサービス（１２０ｃ、１３２ａ、９０６）を、デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループリーダデバイス（１０８）にマッピングするステップであって、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）は、前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイスに問い合わせて、前記デバイスからデバイスメタデータ（１３０）を取得し、送信するために前記デバイスメタデータ（１３０）を処理するように構成されるステップと、
ローカルサービス（１２０ｂ、９０４）を、前記グループリーダデバイス（１０８）に関連付けられたローカルデバイス（１２０ｂ）にマッピングするステップであって、前記ローカルサービス（１２０ｂ、９０４）は、前記処理されたデバイスメタデータを格納するために、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）から、前記処理されたデバイスメタデータを受信するように構成されるステップと、
グローバルサービス（１２０ａ、９０２）を、前記ローカルデバイス（１２０ｂ）と通信するグローバルデバイス（１２０ａ）にマッピングするステップであって、前記グローバルサービス（１２０ａ、９０２）は、前記ローカルサービス（１２０ｂ、９０４）と通信して、前記処理されて格納されたデバイスメタデータに基づいて、グローバルレベルのデバイスメタデータを更新するように構成されるステップと
を備え、
前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）、前記ローカルサービス（１２０ｂ、９０４）、および前記グローバルサービス（１２０ａ、９０２）の前記マッピングはそれぞれ、各前記サービスのサービスメタデータ（１２６）と、前記グループリーダデバイス（１０８）、前記ローカルデバイス（１２０ｂ）、および前記グローバルデバイス（１２０）のデバイス能力との関連付けに基づいて実行される
ことを特徴とする方法。
【請求項１５】
前記デバイスメタデータ（１３０）をモニタリングするステップ（６００）
をさらに備え、
前記モニタリングするステップは、
前記グローバルサービス（１２０ａ、９０２）において、問い合わせ要求を受信するステップ（６０６）と、
前記問い合わせ要求に基づいて、前記ローカルサービス（１２０ｂ、９０４）を判定するステップ（６１０）と、
前記問い合わせ要求を前記ローカルサービス（１２０ｂ、９０４）に送信するステップ（６１６）と、
前記問い合わせ要求に基づいて、前記ローカルサービスにおいて、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）を判定するステップ（６２０）と、
前記問い合わせ要求に基づいて、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）からの問い合わせを、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）に関連付けられた前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループデバイスに配布するステップ（６２２）と、
前記グループデバイスから前記デバイスメタデータを収集するステップ（６２２、６２４）と
を含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記デバイスメタデータ（１３０）をモニタリングするステップ（６００）
をさらに備え、
前記モニタリングするステップは、
デバイスレベルのサービス（１３２ａ、１３２ｂ）において、前記デバイスメタデータ（１３０）を収集するステップ（６２２）と、
前記デバイスメタデータ（１３０）を、前記デバイスレベルのサービス（１３２ａ、１３２ｂ）から前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）に送信するステップ（６２２、６２４）と、
前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）において、前記デバイスメタデータ（１３０）を処理するステップ（６２４）と、
前記処理されたデバイスメタデータを、前記ローカルサービス（１２０ｂ、９０４）に送信するステップ（６２４）と、
デバイスネットワークサービス（１２２、７０４〜７１４）のサービスメタデータ（１２６）と、前記処理されて格納されたデバイスメタデータとの関連付けに基づいて、前記ローカルサービス（１２０ｂ、９０４）において、前記デバイスネットワークサービス（１２２、７０４〜７１４）のマッピングを実行するステップ（６２６）と、
前記処理されて格納されたデバイスメタデータと、前記マッピングとに基づいて、前記グローバルレベルのデバイスメタデータ（１３６）を更新するステップ（６３４）と
を含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループリーダデバイス（１０８）上に配置されたグループリーダサービス（１２０ｃ、１３２ａ、９０６）であって、前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイスのグループのうちの少なくとも１つのデバイスに関連付けられたデバイスメタデータ（１３０）を収集して処理するように構成されたグループリーダサービス（１２０ｃ、１３２ａ、９０６）と、
ローカルデバイス（１２０ｂ）上に配置されたローカルサービス（１２０ｂ、９０４）であって、前記グループリーダデバイス（１０８）と通信して、前記グループリーダデバイス（１０８）から、前記処理されたデバイスメタデータを受信するように構成されたローカルサービス（１２０ｂ、９０４）と、
グローバルデバイス（１２０ａ）上に配置されたグローバルサービス（１２０ａ、９０２）であって、前記ローカルデバイス（１２０ｂ）と通信して、前記デバイスメタデータ（１３０）に基づいて、グローバルデバイスメタデータ（１３６）を更新するように構成されたグローバルサービス（１２０ａ、９０２）と、
前記デバイスメタデータを受信し、前記デバイスメタデータ（１３０）と、デバイスネットワークサービス（１２２、７０４〜７１４）に関連付けられたサービスメタデータ（１２６）とに基づいて、サービスリポジトリ（１２４）から、前記デバイスネットワークサービス（１２２、７０４〜７１４）を、前記デバイスのうちの少なくとも１つにマッピングするように構成されたサービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）と
を備えたことを特徴とするシステム。
【請求項１８】
前記デバイスのグループのうちの前記少なくとも１つのデバイス上に配置されたデバイスレベルのサービス（１３２ａ、１３２ｂ）
をさらに備え、
前記デバイスレベルのサービス（１３２ａ、１３２ｂ）は、前記少なくとも１つのデバイスにおいて、前記デバイスメタデータ（１３０）を検出し、前記デバイスメタデータを前記グループリーダサービス（１２０ａ、９０２）に送信するように構成される
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グループリーダサービス（１２０ｃ）と、前記ローカルサービス（１２０ｂ）と、前記グローバルサービス（１２０ａ）とのうちの少なくとも１つの一部分として配置されることを特徴とする請求項１７に記載のシステム。
【請求項２０】
システムモニタ（１３２、１３２ａ、１３２ｂ）
をさらに備え、
前記システムモニタは、前記グループリーダサービス（１２０ｃ、９０６、１３２ａ）と、前記ローカルサービス（１２０ｂ、９０４）と、前記グローバルサービス（１２０ａ、９０２）とのうちの少なくとも１つの一部分として配置される
ことを特徴とする請求項１７に記載のシステム。
【請求項１】
デバイスネットワークを介して使用する階層型多層マッピングおよびモニタリングシステムであって、
サービスリポジトリ（１２４）であって、
少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたグローバルデバイスメタデータ（１３６）を追跡するように構成されたグローバルサービス（１２０、１２０ａ、１３２、９０２）と、
前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたローカルデバイスメタデータ（１３８）を追跡して、前記ローカルデバイスメタデータ（１３８）に基づいて、前記グローバルデバイスメタデータ（１３６）を更新するように構成されたローカルサービス（１２０、１２０ｂ、１３２、９０４）と、
前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイス（１０８〜１１４、３１２〜３４０）に問い合わせ、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）に送信して前記ローカルデバイスメタデータ（１３８）を更新するためにグループレベルのデバイスメタデータを集約するように構成されたグループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）と
を格納するように構成されたサービスリポジトリと、
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれのサービスメタデータ（１２６）を、少なくとも１つのグローバルデバイス（１２０ａ）、少なくとも１つのローカルデバイス（１０２ｂ）、および少なくとも１つのグループリーダデバイス（１０８）それぞれのデバイスメタデータ（１３０）に関連付け、前記関連付けに基づいて、前記サービスを各前記デバイスにマッピングするように構成されたサービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）と
を備えたことを特徴とするシステム。
【請求項２】
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれは、グローバルサービスマッパコンポーネント（１２０ａ）、ローカルサービスマッパコンポーネント（１２０ｂ）、およびグループリーダサービスマッパコンポーネント（１２０ｃ）それぞれに関連付けられることを特徴とする請求項１に記載のシステム。
【請求項３】
前記サービスマッパコンポーネント（１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルデバイスメタデータ（１３６）と、前記ローカルデバイスメタデータ（１３８）と、前記グループリーダデバイスメタデータとのうちの少なくとも１つに基づいて、前記サービスリポジトリ（１２４）から、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の機能に関連付けられたデバイスネットワークサービス（１２２、１２８、７０４〜７１４、９０２〜９０６）を、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の前記問い合わされたデバイスのうちの１つにマッピングするように構成されることを特徴とする請求項２に記載のシステム。
【請求項４】
前記グローバルサービス（１２０、１２０ａ、１３２、９０２）、前記ローカルサービス（１２０、１２０ｂ、１３２、９０４）、および前記グループリーダサービス（１２０、１２０ｃ、１３２、１３２ａ、９０６）それぞれは、グローバルサービスモニタコンポーネント（１２０ａ、９０２）、ローカルサービスモニタコンポーネント（１２０ｂ、９０４）、およびグループリーダサービスモニタコンポーネント（１２０ｃ／１３２ａ、９０６）それぞれに関連付けられることを特徴とする請求項１に記載のシステム。
【請求項５】
前記サービスモニタコンポーネント（１２０ａ、１２０ｂ、１２０ｃ／１３２ａ）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたモニタリングデータを、前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）に提供するように構成され、前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、デバイスネットワークサービス（１２２、１２８、７０４〜７１４）を、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイスにマッピングするように構成されることを特徴とする請求項４に記載のシステム。
【請求項６】
前記グローバルサービスモニタコンポーネント（１２０ａ）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）に関連付けられたモニタリングデータを、アプリケーションのユーザインタフェース（１０００、１６００、１７００）に提供するように構成されることを特徴とする請求項４に記載のシステム。
【請求項７】
前記サービスリポジトリ（１２４）は、前記グループリーダサービスモニタコンポーネント（１３２ａ）に通信するためのデバイスレベルのデバイスメタデータを取得するように構成されたデバイスレベルのサービスモニタコンポーネント（１３２ｂ）を含むことを特徴とする請求項４に記載のシステム。
【請求項８】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記デバイスレベルのサービスモニタコンポーネント（１３２ｂ）を、前記少なくとも１つのデバイスネットワークのデバイス（１１０）にマッピングするように構成されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記グローバルデバイスメタデータ（１３６）は、複数のローカルサービス（４０２、４０４、４０８）に関する情報を含み、
前記複数のローカルサービスの各々は、少なくとも１つのグループリーダサービス（１２２）と通信し、
前記グローバルデバイスメタデータ（１３６）は、前記複数のローカルサービスに関連付けられた前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）における１つまたは複数のデバイスのクラス（４０６）を識別し、さらに、前記少なくとも１つのデバイスネットワーク上に配置された１つまたは複数のサービスのクラス（４０８）を識別する
ことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ローカルデバイスメタデータ（１３８）は、複数のグループリーダサービス（１２０ｃ、４１２）に関する情報を含み、
各前記グループリーダサービスは、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイスと通信し、
前記ローカルデバイスメタデータ（１３８）は、前記少なくとも１つのデバイスの位置を示す位置情報（４２０）とともに、デバイス固有の情報およびサービス固有の情報（４１４〜４１８）を識別する
ことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記グループリーダデバイスメタデータ（１３０）は、前記少なくとも１つのデバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）の少なくとも１つのデバイス（１０８〜１１４）に関連付けられたデバイス固有のデバイスメタデータを含み、
前記グループリーダサービス（１２０ｃ、１３２ａ）は、前記デバイス固有のデバイスメタデータを前記ローカルサービス（１２０ｂ）に送信する前に、前記デバイス固有のデバイスメタデータを処理するように構成される
ことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルサービス（１２０ａ、９０２）のうちの少なくとも１つと、前記ローカルサービス（１２０ｂ、９０４）のうちの少なくとも１つと、前記グループリーダサービス（１２０ｃ、９０６）のうちの少なくとも１つとのうちのいずれかを、前記グローバルデバイス（１２０ａ）、前記ローカルデバイス（１２０ｂ）、前記グループリーダデバイス（１０８）から、それぞれ、第２グローバルデバイス、第２ローカルデバイス、第２グループリーダデバイスに再マッピングするように構成されることを特徴とする請求項１に記載のシステム。
【請求項１３】
単一のデバイスが、前記少なくとも１つのグローバルデバイス（１２０ａ）と、前記少なくとも１つのローカルデバイス（１２０ｂ）と、前記少なくとも１つのグループリーダデバイス（１０８）とのうちの少なくとも２つとして動作し、
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グローバルサービス（１２０ａ、９０２）と、前記ローカルサービス（１２０ｂ、９０４）と、前記グループリーダサービス（１０８、９０６、１３２ａ）とのうちの少なくとも２つを、前記単一のデバイスにマッピングするように構成される
ことを特徴とする請求項１に記載のシステム。
【請求項１４】
グループリーダサービス（１２０ｃ、１３２ａ、９０６）を、デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループリーダデバイス（１０８）にマッピングするステップであって、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）は、前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイスに問い合わせて、前記デバイスからデバイスメタデータ（１３０）を取得し、送信するために前記デバイスメタデータ（１３０）を処理するように構成されるステップと、
ローカルサービス（１２０ｂ、９０４）を、前記グループリーダデバイス（１０８）に関連付けられたローカルデバイス（１２０ｂ）にマッピングするステップであって、前記ローカルサービス（１２０ｂ、９０４）は、前記処理されたデバイスメタデータを格納するために、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）から、前記処理されたデバイスメタデータを受信するように構成されるステップと、
グローバルサービス（１２０ａ、９０２）を、前記ローカルデバイス（１２０ｂ）と通信するグローバルデバイス（１２０ａ）にマッピングするステップであって、前記グローバルサービス（１２０ａ、９０２）は、前記ローカルサービス（１２０ｂ、９０４）と通信して、前記処理されて格納されたデバイスメタデータに基づいて、グローバルレベルのデバイスメタデータを更新するように構成されるステップと
を備え、
前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）、前記ローカルサービス（１２０ｂ、９０４）、および前記グローバルサービス（１２０ａ、９０２）の前記マッピングはそれぞれ、各前記サービスのサービスメタデータ（１２６）と、前記グループリーダデバイス（１０８）、前記ローカルデバイス（１２０ｂ）、および前記グローバルデバイス（１２０）のデバイス能力との関連付けに基づいて実行される
ことを特徴とする方法。
【請求項１５】
前記デバイスメタデータ（１３０）をモニタリングするステップ（６００）
をさらに備え、
前記モニタリングするステップは、
前記グローバルサービス（１２０ａ、９０２）において、問い合わせ要求を受信するステップ（６０６）と、
前記問い合わせ要求に基づいて、前記ローカルサービス（１２０ｂ、９０４）を判定するステップ（６１０）と、
前記問い合わせ要求を前記ローカルサービス（１２０ｂ、９０４）に送信するステップ（６１６）と、
前記問い合わせ要求に基づいて、前記ローカルサービスにおいて、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）を判定するステップ（６２０）と、
前記問い合わせ要求に基づいて、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）からの問い合わせを、前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）に関連付けられた前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループデバイスに配布するステップ（６２２）と、
前記グループデバイスから前記デバイスメタデータを収集するステップ（６２２、６２４）と
を含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記デバイスメタデータ（１３０）をモニタリングするステップ（６００）
をさらに備え、
前記モニタリングするステップは、
デバイスレベルのサービス（１３２ａ、１３２ｂ）において、前記デバイスメタデータ（１３０）を収集するステップ（６２２）と、
前記デバイスメタデータ（１３０）を、前記デバイスレベルのサービス（１３２ａ、１３２ｂ）から前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）に送信するステップ（６２２、６２４）と、
前記グループリーダサービス（１２０ｃ、１３２ａ、９０６）において、前記デバイスメタデータ（１３０）を処理するステップ（６２４）と、
前記処理されたデバイスメタデータを、前記ローカルサービス（１２０ｂ、９０４）に送信するステップ（６２４）と、
デバイスネットワークサービス（１２２、７０４〜７１４）のサービスメタデータ（１２６）と、前記処理されて格納されたデバイスメタデータとの関連付けに基づいて、前記ローカルサービス（１２０ｂ、９０４）において、前記デバイスネットワークサービス（１２２、７０４〜７１４）のマッピングを実行するステップ（６２６）と、
前記処理されて格納されたデバイスメタデータと、前記マッピングとに基づいて、前記グローバルレベルのデバイスメタデータ（１３６）を更新するステップ（６３４）と
を含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のグループリーダデバイス（１０８）上に配置されたグループリーダサービス（１２０ｃ、１３２ａ、９０６）であって、前記デバイスネットワーク（１０２、１０８〜１１４、３０６〜３１０、３２４、３２６）のデバイスのグループのうちの少なくとも１つのデバイスに関連付けられたデバイスメタデータ（１３０）を収集して処理するように構成されたグループリーダサービス（１２０ｃ、１３２ａ、９０６）と、
ローカルデバイス（１２０ｂ）上に配置されたローカルサービス（１２０ｂ、９０４）であって、前記グループリーダデバイス（１０８）と通信して、前記グループリーダデバイス（１０８）から、前記処理されたデバイスメタデータを受信するように構成されたローカルサービス（１２０ｂ、９０４）と、
グローバルデバイス（１２０ａ）上に配置されたグローバルサービス（１２０ａ、９０２）であって、前記ローカルデバイス（１２０ｂ）と通信して、前記デバイスメタデータ（１３０）に基づいて、グローバルデバイスメタデータ（１３６）を更新するように構成されたグローバルサービス（１２０ａ、９０２）と、
前記デバイスメタデータを受信し、前記デバイスメタデータ（１３０）と、デバイスネットワークサービス（１２２、７０４〜７１４）に関連付けられたサービスメタデータ（１２６）とに基づいて、サービスリポジトリ（１２４）から、前記デバイスネットワークサービス（１２２、７０４〜７１４）を、前記デバイスのうちの少なくとも１つにマッピングするように構成されたサービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）と
を備えたことを特徴とするシステム。
【請求項１８】
前記デバイスのグループのうちの前記少なくとも１つのデバイス上に配置されたデバイスレベルのサービス（１３２ａ、１３２ｂ）
をさらに備え、
前記デバイスレベルのサービス（１３２ａ、１３２ｂ）は、前記少なくとも１つのデバイスにおいて、前記デバイスメタデータ（１３０）を検出し、前記デバイスメタデータを前記グループリーダサービス（１２０ａ、９０２）に送信するように構成される
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記サービスマッパ（１２０、１２０ａ、１２０ｂ、１２０ｃ）は、前記グループリーダサービス（１２０ｃ）と、前記ローカルサービス（１２０ｂ）と、前記グローバルサービス（１２０ａ）とのうちの少なくとも１つの一部分として配置されることを特徴とする請求項１７に記載のシステム。
【請求項２０】
システムモニタ（１３２、１３２ａ、１３２ｂ）
をさらに備え、
前記システムモニタは、前記グループリーダサービス（１２０ｃ、９０６、１３２ａ）と、前記ローカルサービス（１２０ｂ、９０４）と、前記グローバルサービス（１２０ａ、９０２）とのうちの少なくとも１つの一部分として配置される
ことを特徴とする請求項１７に記載のシステム。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２Ａ】
【図２Ｂ】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２００７−１５７１３３（Ｐ２００７−１５７１３３Ａ）
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願番号】特願２００６−３１４５６５（Ｐ２００６−３１４５６５）
【出願日】平成１８年１１月２１日（２００６．１１．２１）
【出願人】（３０００１５４４７）エスアーペー アーゲー (146)
【氏名又は名称原語表記】ＳＡＰ ＡＧ
【住所又は居所原語表記】Ｄｉｅｔｍａｒ−Ｈｏｐｐ−Ａｌｌｅｅ １６， ６９１９０ Ｗａｌｌｄｏｒｆ， Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願日】平成１８年１１月２１日（２００６．１１．２１）
【出願人】（３０００１５４４７）エスアーペー アーゲー (146)
【氏名又は名称原語表記】ＳＡＰ ＡＧ
【住所又は居所原語表記】Ｄｉｅｔｍａｒ−Ｈｏｐｐ−Ａｌｌｅｅ １６， ６９１９０ Ｗａｌｌｄｏｒｆ， Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
[ Back to top ]