(57)【要約】【課題】デバイスを動的に発見し利用する分散リソース活用システムにおいて、個々のデバイスの仕様や設定に依存せず、複数のデバイスが連携しサービスを提供できるようにする。【解決手段】分散リソース活用システム１００のデバイス連携サーバ１は、デバイスの複数を連携して実行させるための連携ロジックを記憶する記憶部１３と、端末の位置情報を含むサービス要求を受信するサービス要求受信部１１１と、複数のデバイスそれぞれの機能および位置情報を含むメタデータを取得するメタデータ取得部１１２と、要求するサービスに用いるデバイスを選択するデバイス選択部１１３と、選択したデバイスからデバイス処理情報を収集するデバイス処理情報収集部１１４と、連携ロジックに基づき、選択したデバイスに、収集した具体的な処理内容による指示を行うことにより、連携したサービスを実行するサービス実行部１１５とを備える。【選択図】図３
2019125068.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させる分散リソース活用システムのデバイス連携サーバであって、
前記デバイスは、標準化されたインタフェースを備えるデバイスである標準デバイスであり、
前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記標準化されたインタフェースの定義で記述された連携ロジックを記憶する記憶部と、
前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、
前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、
前記要求するサービスで用いられる機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、
前記標準化されたインタフェースの定義で記述され、前記デバイスにおいて前記サービスを実行させるための具体的な処理内容を示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、
前記連携ロジックに基づき、前記選択したデバイスに、収集した前記具体的な処理内容による指示を行うことにより、連携したサービスを実行するサービス実行部と、
を備えることを特徴とするデバイス連携サーバ。
【請求項２】
ネットワークに接続された複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させる分散リソース活用システムのデバイス連携サーバであって、
前記複数のデバイスは、インタフェースが標準化されておらず、具体的インタフェースの異なるデバイスで構成されており、
前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記具体的インタフェースの定義に依存しない抽象的な指示情報として記述された連携ロジックを記憶する記憶部と、
前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、
前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、
前記要求するサービスで用いられる機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、
前記抽象的な指示情報の定義に則って記述され、前記デバイスにおいて前記サービスを実行させるための処理手順と、当該処理手順を前記具体的インタフェースに適合させるマッピング情報と、当該具体的インタフェースの情報とを示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、
前記選択したデバイスにおいて前記抽象的な指示情報で記述される前記処理手順を、前記マッピング情報を用いて、前記具体的インタフェースに適合した指示情報に変換するマッピング処理部と、
前記連携ロジックに基づき、前記選択したデバイスに、前記マッピング処理部が変換した前記具体的インタフェースに適合した指示情報を送信することにより、連携したサービスを実行するサービス実行部と、
を備えることを特徴とするデバイス連携サーバ。
【請求項３】
コンピュータを、請求項１または請求項２に記載のデバイス連携サーバとして機能させるためのデバイス連携プログラム。
【請求項４】
複数のデバイスに接続されるゲートウェイと、当該複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させるデバイス連携サーバとを備える分散リソース活用システムであって、
前記複数のデバイスは、インタフェースが標準化されておらず、具体的インタフェースの異なるデバイスで構成されており、
前記デバイス連携サーバは、
前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記具体的インタフェースの定義に依存しない抽象的な指示情報として記述された連携ロジックを記憶する記憶部と、
前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、
前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、
前記要求するサービスで用いられる前記機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、
前記連携ロジックに基づき、前記選択したデバイスを収容する前記ゲートウェイに、前記抽象的な指示情報を送信するサービス実行部と、を備え、
前記ゲートウェイは、
前記抽象的な指示情報の定義に則って記述され、前記デバイスにおいて前記サービスを実行させるための処理手順と、当該処理手順を前記具体的インタフェースに適合させるマッピング情報と、当該具体的インタフェースの情報とを示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、
受信した前記抽象的な指示情報で記述される前記処理手順を、前記マッピング情報を用いて、前記選択したデバイスの前記具体的インタフェースに適合した指示情報に変換するマッピング処理部と、
前記選択したデバイスに、前記マッピング処理部が変換した前記具体的インタフェースに適合した指示情報を送信する指示出力部と、
を備えることを特徴とする分散リソース活用システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに多種多様なＩｏＴ（Internet of Things）デバイスが繋がる環境における、デバイス連携サーバ、デバイス連携プログラムおよび分散リソース活用システムに関する。
【背景技術】
【０００２】
近年のＩｏＴ技術の進展により、数多くのセンサやアクチュエータ、ロボット等のＩｏＴ機器がネットワークに繋がり、様々な分析等に活用されるようになっている。しかしながら、現状のＩｏＴの適用は、特定のターゲットに合わせた垂直統合的なワンオフソリューションになりがちである。つまり、センサの選定や、分析、表示、アクション等を一括で行い、システム化して提供するＳＩ（System Integration）ビジネスで用いられることが多い。この結果、個々のＩｏＴサービスのコストが高くなり、多彩なサービスが十分出ていないという現状がある。
【０００３】
多彩なＩｏＴサービスを、コストを抑えて開発、運用するためには、センサやアクチュエータ等のデバイスとサービスとを分離し、水平分離的にデバイスとサービスを相互に利用可能とすることが必要となる。このような考え方はオープンＩｏＴと呼ばれ、今後のＩｏＴサービスを活性化するために重視されている。
【０００４】
このようなオープンＩｏＴにむけて、サービスからデバイスを自由に利用するための仕組みとしてTacit Computing技術が提案されている（非特許文献１参照）。Tacit Computingは、デバイスがその時点で保持するライブデータに基づき、ユーザが必要なデータを保持するデバイスをオンデマンドに発見し、利用することを可能にする技術である。
【０００５】
図１１は、Tacit Computingの概要を説明するための図である。
Tacit Computingでは、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層の中から、ユーザへのサービスに適切なリソースを発見し連携することにより、そのユーザのリクエストに応えサービスを継続する（図１１の符号ａ）。また、３層の構成のうち、時々刻々変化する状況に対応するため、データが発生する現場に近いデバイスレイヤにおいてできるだけ処理を行うようにする（図１１の符号ｂ）。より低いレイヤで処理を行うことにより、ネットワークトラフィックの削減や（図１１の符号ｃ）、プライバシー性の高いデータの流出を抑えることができる（図１１の符号ｄ）。
【０００６】
このTacit Computingでは、その要素技術として、ライブデータ検索技術とデバイス仮想化技術を用いる。
ライブデータ検索技術は、ユーザにとって必要なデータを提供するデバイスを検索するための技術である。ＩｏＴサービスの例として、橋等の施設にセンサを複数設置し、劣化状況等をモニタリングするサービスがある。この場合、劣化状況が急激に進むとは考えられないため、数時間等の周期で複数点でのセンサデータをクラウドに上げ、劣化状況の変化を統計ソフトや機械学習により分析すればよい。これに対し、定点のカメラに映った人物に対して、情報案内や警告アラート等を行うサービスの例では、数秒程度しかカメラに人物は映らないし、また、その人物が写ったカメラの映像しかその人物には意味のないデータといえる。このように、デバイスレイヤで発生し、時々刻々変化するようなデータをライブデータと呼ぶ。
【０００７】
ユーザにとって必要なこのライブデータを検索するため、Tacit Computingでは、クラウドレイヤにデータが上がってくるのを待つのではなく、下位レイヤに分析する機能を配置し、その下位レイヤにおいてライブデータを検索させる。
例えば、駅伝予選会に友人が参加しており、その友人が写ったカメラの映像を自動で繋いで欲しいとする。この場合、例えば友人のゼッケン番号を検索キーとしてリクエストすると、Tacit Computingでは、カメラを収容するゲートウェイやネットワークエッジに、OpenCV等の画像分析機能を配置する。そして、カメラに近い場所で映像を分析することにより、友人のゼッケン番号が画像分析により抽出され、友人が映っているカメラを特定することができる。このようにして、Tacit Computingにおいてライブデータ検索技術が用いられる。
【０００８】
次に、利用したいデバイスがライブデータ検索技術により特定された場合に、そのデバイスを実際に利用する必要がある。ＩｏＴデバイスは、多数のメーカーが開発しており、利用時のプロトコルやインタフェース、アドレス等、即ち仕様や設定がデバイス毎に異なる。そこで、デバイス仮想化技術によって、個々のデバイスにおけるインタフェース等の違いを吸収する。
例えば、上記した例であれば、カメラ映像の取得のような共通のリクエストを元に、カメラを収容するゲートウェイ等で、デバイス毎のアダプタを設けておきプロトコル等の変換を行った上で、個々のカメラに応じたリクエストを行う。このようなデバイス仮想化技術を用いることにより、ユーザはデバイス個々の違いを意識せず、そのデバイスの利用が可能となる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】佐々木潤子、他５名、「Tacit Computing：オープンＩｏＴ・偏在リソース時代にむけたネットワークサービス」、株式会社ビジネスコミュニケーション社、ビジネスコミュニケーション、Vol.54、No.5、pp.24-25、May 2017
【発明の概要】
【発明が解決しようとする課題】
【００１０】
Tacit Computingではクラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、ユーザに適切なリソースを発見することで、そのユーザのリクエストに応える。３層の構造において、時々刻々変化する情報に対応するため、データの発生源に近いデバイスレイヤでできるだけ処理を行うコンセプトをとる。低レイヤ側で処理を終えることで、ネットワークトラフィックの削減や、プライバシー性の高いデータの流出を抑えることができる。また、Tacit Computingでは、分析プログラムの配信等によりユーザが必要なデータを持つデバイスを発見し、デバイス仮想化技術を用いることで、個々のデバイスのインタフェースを隠蔽することにより、デバイスの動的な利用が可能となる。
【００１１】
このように、従来のTacit Computingでは、その時点の状況に合わせてデバイスを発見し、利用することはできるようになった。しかしながら、複数のデバイスを連携させてサービスの提供する際の、連携ロジックの記述については充分な検討がなされていない。
Tacit Computingでは、動的にデバイスを発見し利用するため、実行時でなければ利用するデバイスが決まらない。そのため、特定デバイスからのデータを別の特定デバイスに引き継ぐといった、連携プログラムの記述を事前に行うことができない。
【００１２】
連携サービスの例として、駅での観光客へのナビゲーションを考える。連携するデバイスは、駅のカメラ、駅のディスプレイ、駅の放送スピーカ等である。ナビゲーションサービスに、観光客が行き先をスマートフォンやタッチパネル等で指定すると、駅のディスプレイに乗換先や時刻、地図等が表示され、駅のスピーカで何番線に行くかの案内が流れる。さらに、駅のカメラで観光客をモニタして、移動方向等を画像解析により分析し、誤った方向に向かった場合には検知して、スピーカで別方向であることのアラートを流す。
【００１３】
このように、ディスプレイやスピーカを用いて単に案内を表示したり音声を流したりするだけでなく、カメラで進行方向を分析し、誤っている場合にイベントを立ち上げて、スピーカ等でアラートする。このようなイベント処理を行うためには、複数のデバイスを連携させるためのプログラムロジックが必要である。
【００１４】
また、従来、各駅に設置されている、ディスプレイ、カメラ、スピーカは、アドレスだけでなく、機種や機器インタフェース（ＩＦ）が異なるため、デバイスを連携するためには、そのデバイスに合わせて事業者（鉄道会社）毎にプログラムを記述する必要があった。
【００１５】
一方、Tacit Computingでは、より広範囲に様々なデバイスを動的に連携して利用するという観点から、各デバイスを連携するためのロジック（連携ロジック）は、個々のデバイスに依存せずに記述できることが望まれる。しかしながら、従来のTacit Computing等の技術では、この連携ロジックの記述と実行の手法については、充分な検討がなされてこなかった。
【００１６】
このような点に鑑みて本発明がなされたのであり、デバイスを動的に発見し利用する分散リソース活用システムにおいて、個々のデバイスの仕様や設定に依存せず、複数のデバイスが連携してサービスを提供するデバイス連携サービスを実現することを課題とする。
【課題を解決するための手段】
【００１７】
前記した課題を解決するため、請求項１に記載の発明は、ネットワークに接続された複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させる分散リソース活用システムのデバイス連携サーバであって、前記デバイスは、標準化されたインタフェースを備えるデバイスである標準デバイスであり、前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記標準化されたインタフェースの定義で記述された連携ロジックを記憶する記憶部と、前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、前記要求するサービスで用いられる機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、前記標準化されたインタフェースの定義で記述され、前記デバイスにおいて前記サービスを実行させるための具体的な処理内容を示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、前記連携ロジックに基づき、前記選択したデバイスに、収集した前記具体的な処理内容による指示を行うことにより、連携したサービスを実行するサービス実行部と、を備えることを特徴とするデバイス連携サーバとした。
【００１８】
このように、デバイス連携サーバによれば、連携ロジックを、標準インタフェースの定義で記述することにより、標準インタフェースにより動作可能な標準デバイスを用いて連携サービスを提供することができる。よって、標準インタフェースを備えるデバイスであれば、デバイスの種別を問わず、各デバイスが備える機能を連携させてサービスを提供することが可能となる。
【００１９】
請求項２に記載の発明は、ネットワークに接続された複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させる分散リソース活用システムのデバイス連携サーバであって、前記複数のデバイスは、インタフェースが標準化されておらず、具体的インタフェースの異なるデバイスで構成されており、前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記具体的インタフェースの定義に依存しない抽象的な指示情報として記述された連携ロジックを記憶する記憶部と、
前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、前記要求するサービスで用いられる機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、前記抽象的な指示情報の定義に則って記述され、前記デバイスにおいて前記サービスを実行させるための処理手順と、当該処理手順を前記具体的インタフェースに適合させるマッピング情報と、当該具体的インタフェースの情報とを示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、前記選択したデバイスにおいて前記抽象的な指示情報で記述される前記処理手順を、前記マッピング情報を用いて、前記具体的インタフェースに適合した指示情報に変換するマッピング処理部と、前記連携ロジックに基づき、前記選択したデバイスに、前記マッピング処理部が変換した前記具体的インタフェースに適合した指示情報を送信することにより、連携したサービスを実行するサービス実行部と、を備えることを特徴とするデバイス連携サーバとした。
【００２０】
このように、デバイス連携サーバに記憶される連携ロジックを、個別のインタフェース等に依存しないように抽象的に記述する。そして、デバイス連携サーバは、その抽象的に記述された連携ロジックに基づく指示情報を、デバイスそれぞれに適合するインタフェースに変換して、連携したサービスを提供することができる。
【００２１】
請求項３に記載の発明は、コンピュータを、請求項１または請求項２に記載のデバイス連携サーバとして機能させるためのデバイス連携プログラムとした。
【００２２】
このようにすることにより、一般的なコンピュータを用いて、請求項１または請求項２に記載のデバイス連携サーバの各機能を実現させることができる。
【００２３】
請求項４に記載の発明は、複数のデバイスに接続されるゲートウェイと、当該複数のデバイスの中から、サービスの提供に用いる前記デバイスを選択して前記サービスを実行させるデバイス連携サーバとを備える分散リソース活用システムであって、前記複数のデバイスは、インタフェースが標準化されておらず、具体的インタフェースの異なるデバイスで構成されており、前記デバイス連携サーバは、前記デバイスの複数を連携して実行させて前記サービスを提供するため、前記具体的インタフェースの定義に依存しない抽象的な指示情報として記述された連携ロジックを記憶する記憶部と、前記サービスを要求する端末から、要求するサービスの識別情報を示すサービス識別情報、および、前記端末の位置情報を含むサービス要求メッセージを受信するサービス要求受信部と、前記複数のデバイスそれぞれが前記サービスの提供に際して実行する機能および前記複数のデバイスそれぞれの位置情報を含むメタデータを取得し、前記記憶部に格納するメタデータ取得部と、前記要求するサービスで用いられる前記機能および前記端末の位置情報を用いて、前記記憶部に記憶された前記デバイスそれぞれの機能および位置情報を含む前記メタデータを参照し、前記サービスを実行させるデバイスを選択するデバイス選択部と、前記連携ロジックに基づき、前記選択したデバイスを収容する前記ゲートウェイに、前記抽象的な指示情報を送信するサービス実行部と、を備え、前記ゲートウェイは、前記抽象的な指示情報の定義に則って記述され、前記デバイスにおいて前記サービスを実行させるための処理手順と、当該処理手順を前記具体的インタフェースに適合させるマッピング情報と、当該具体的インタフェースの情報とを示すデバイス処理情報を、前記選択したデバイスから収集するデバイス処理情報収集部と、受信した前記抽象的な指示情報で記述される前記処理手順を、前記マッピング情報を用いて、前記選択したデバイスの前記具体的インタフェースに適合した指示情報に変換するマッピング処理部と、前記選択したデバイスに、前記マッピング処理部が変換した前記具体的インタフェースに適合した指示情報を送信する指示出力部と、を備えることを特徴とする分散リソース活用システムとした。
【００２４】
このように、分散リソース活用システムによれば、デバイス連携サーバに、個別のインタフェース等に依存しない抽象的な連携ロジックを記述しておき、その抽象的な連携ロジックで示される抽象的な指示情報を、ゲートウェイに送信する。そして、ゲートウェイが、その抽象的な指示情報を、デバイスそれぞれに適合するインタフェースに変換して各デバイスに送信する。よって、デバイス連携サーバは、各デバイスに対応したインタフェースへの変換機能を持つ必要をなくすことができる。これにより、分散リソース活用システムでは、デバイス連携サーバの負荷を低減した上で、連携したサービスを提供することができる。
【発明の効果】
【００２５】
本発明によれば、デバイスを動的に発見し利用する分散リソース活用システムにおいて、個々のデバイスの仕様や設定に依存せず、複数のデバイスが連携してサービスを提供するデバイス連携サービスを実現することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施形態に係るデバイス連携サーバを含む分散リソース活用システムを示す図である。
【図２】本発明の第１実施形態に係る分散リソース活用システムの概要を説明するための図である。
【図３】本発明の第１実施形態に係るデバイス連携サーバの構成例を示す機能ブロック図である。
【図４】本発明の第１実施形態に係るデバイス連携サーバの処理の流れを示すフローチャートである。
【図５】本発明の第２実施形態に係る分散リソース活用システムの概要を説明するための図である。
【図６】本発明の第２実施形態に係るデバイス連携サーバの構成例を示す機能ブロック図である。
【図７】本発明の第２実施形態に係るデバイス連携サーバの処理の流れを示すフローチャートである。
【図８】本発明の第３実施形態に係る分散リソース活用システムの概要を説明するための図である。
【図９】本発明の第３実施形態に係るデバイス連携サーバおよびゲートウェイ（ＧＷ）の構成例を示す機能ブロック図である。
【図１０】本発明の第３実施形態に係る分散リソース活用システム（デバイス連携サーバおよびゲートウェイ）の処理の流れを示すシーケンス図である。
【図１１】Tacit Computingの概要を説明するための図である。
【発明を実施するための形態】
【００２７】
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）における、デバイス連携サーバ１等について説明する。
図１は、本実施形態に係るデバイス連携サーバ１を含む分散リソース活用システム１００を示す図である。なお、本実施形態では、ネットワークに接続された複数のリソース（デバイス等）から、ユーザが所望のサービスを実現するための適切なリソースを発見して利用する分散リソース活用システムとして、Tacit Computingシステムを例として、以下説明する。
本実施形態に係る分散リソース活用システム１００（Tacit Computingシステム）は、図１１に示した従来のTacit Computingの構成に加え、図１に示すように、デバイス連携サーバ１を含むことを特徴とする。デバイス連携サーバ１は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層に位置する各リソース（デバイス）と通信可能に接続され、ユーザが所望するサービスを実現するために、各デバイスが備える各種機能を連携するように制御する装置である。
【００２８】
分散リソース活用システム１００において、デバイスを連携してサービスを提供する際、図１に示したデバイス連携サーバ１に、連携ロジックを格納しておき、Tacit Computingシステムを用いて適切なリソース（デバイス）を発見することで、そのデバイスを動的に利用し連携サービスを実現する。
以下、本実施形態に係るデバイス連携サーバ１が、分散リソース活用システム１００（Tacit Computingシステム）におけるデバイスの動的な利用により連携サービスを実現する構成例について、第１〜第３実施形態として説明する。
【００２９】
＜第１実施形態＞
第１実施形態は、デバイス連携サーバ１が、標準インタフェース（定義）を用いて記述された連携ロジックを備えることを特徴とする。
図２は、本発明の第１実施形態に係る分散リソース活用システム１００Ａの概要を説明するための図である。なお、図２においては、図１に示した分散リソース活用システム１００のうち、デバイスレイヤの各リソース（センサやアクチュエータ等のデバイス）とデバイス連携サーバ１のみを抽出して図示している。
【００３０】
図２に示すように、分散リソース活用システム１００Ａにおけるデバイスは、デバイスが持つサービスのアクション（機能）が標準化されているデバイス（以下、「標準デバイス２Ａ」と称する。）で構成される。この標準デバイス２Ａは、例えば、ＵＰｎＰ（Universal Plug and Play）（登録商標）の規格に準拠したインタフェースを備えるデバイスである。
サービスを実現する各標準デバイス２Ａ（２Ａ１，２Ａ２、２Ａ３）は、ＵＰｎＰにおいて規格化されたＳＯＡＰ（Simple Object Access Protocol）等によりデバイス連携サーバ１Ａからの要求や応答が送受信される。
【００３１】
また、標準デバイス２Ａのメタデータは、所定の形式（例えば、ＸＭＬ（Extensible Markup Language））等のドキュメントとして公開されている（図２の公開メタデータ２００）。これにより、デバイス連携サーバ１Ａは、各デバイスが備えるサービスの機能に関する情報を、自身の記憶部に記憶し、サービスの実行に最適なデバイスを選択することができる。
【００３２】
図３は、本発明の第１実施形態に係るデバイス連携サーバ１Ａの構成例を示す機能ブロック図である。デバイス連携サーバ１Ａは、サービス利用者９０（図２参照）が備える端末９（図２参照）からのサービス要求を受け付け、そのサービスを実行するために最適なデバイスを発見するとともに、標準インタフェース（定義）により記述された連携ロジック（連携ロジック（標準ＩＦ）１３１Ａ）を用いて、複数のデバイスが連携してサービスを提供するように制御する装置である。
このデバイス連携サーバ１Ａは、図３に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。
【００３３】
入出力部１２は、クラウドレイヤ、ネットワークレイヤおよびデバイスレイヤに属する各デバイス等との間で情報の送受信を行うための通信インタフェースと、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースとから構成される。
【００３４】
記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
この記憶部１３には、標準インタフェース（ＩＦ）を使って記述された連携ロジック１３１Ａおよびデバイス情報ＤＢ（DataBase）１３２が記憶されるとともに、制御部１１の処理に必要な情報（例えば、各デバイスから取得するＵＰｎＰ Description等）が一時的に記憶される。
【００３５】
ここで、連携ロジック（標準ＩＦ）１３１Ａには、サービスを連携させるためのプログラムが、標準インタフェース（ＩＦ）に基づく仕様（標準化された定義に基づく仕様）により記述される。この標準インタフェース（ＩＦ）は、上記したＵＰｎＰに限定されず、例えば、ＷＳＤＬ（Web Services Description Language）や、Ｅｃｈｏｎｅｔ（登録商標）、ＲＥＳＴ（Representational State Transfer）等であってもよい。
また、デバイス情報ＤＢ１３２には、デバイスレイヤに存在する各標準デバイス２Ａの公開されているメタデータが格納される。このデバイスのメタデータには、少なくとも、デバイスの識別情報、デバイスの種別（そのデバイスの機能等を示す情報）、デバイスの位置情報が格納される。
【００３６】
制御部１１は、デバイス連携サーバ１Ａ全体の制御を司り、サービス要求受信部１１１と、メタデータ取得部１１２と、デバイス選択部１１３と、デバイス処理情報収集部１１４と、サービス実行部１１５とを備える。
また、この制御部１１は、例えば、記憶部１３に記憶されたプログラム（デバイス連携プログラム）を不図示のＣＰＵ（Central Processing Unit）が、ＲＡＭに展開し実行することにより実現される。
【００３７】
サービス要求受信部１１１は、サービス利用者９０（図２参照）が備える端末９からのサービス要求メッセージ（サービス要求）を受信する。
このサービス要求メッセージには、少なくとも要求するサービスの識別情報（サービス識別情報）、ユーザの識別情報、端末９の位置情報が含まれる。
【００３８】
メタデータ取得部１１２は、各標準デバイス２Ａのメタデータ（デバイスの機能や位置情報等）を取得し、記憶部１３内のデバイス情報ＤＢ１３２に格納する。メタデータ取得部１１２は、例えば、サービス要求受信部１１１が受信した端末９の位置情報を用いて、その端末９が位置するエリアに存在する各標準デバイス２ＡからメタデータをＨＴＴＰ（Hyper Text Transfer Protocol）等により取得する。その他でも、メタデータ取得部１１２は、自身と接続するすべての標準デバイス２Ａから、あらかじめメタデータを取得するようにしてもよい。このメタデータ取得部１１２による各標準デバイス２Ａのメタデータの取得手法は特に限定はなく、何らかの既存手法で、デバイス連携サーバ１Ａは、各標準デバイス２Ａのメタデータを取得し、デバイス情報ＤＢ１３２に格納する。
【００３９】
デバイス選択部１１３は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれる要求するサービスの識別情報（サービス識別情報）を用いて、記憶部１３内の連携ロジック（標準ＩＦ）１３１Ａを参照し、そのサービスの提供に必要なデバイスの機能を特定する。そして、デバイス選択部１１３は、特定した機能を備え、端末９の位置情報で示される位置の近傍に位置する標準デバイス２Ａを、デバイス情報ＤＢ１３２を参照して選択する。なお、デバイス選択部１１３は、機能および位置情報とともに、例えば、その標準デバイス２Ａを利用する値段（利用料金）やサービス提供者（事業者）等の他のメタデータの情報を条件に加えて、サービスに利用する標準デバイス２Ａを選択するようにしてもよい。
【００４０】
デバイス処理情報収集部１１４は、デバイス選択部１１３が選択した標準デバイス２Ａに対し、例えば、ＨＴＴＰ等の既存のアクセス手法により、そのデバイスの操作手順等を示すデバイス処理情報を要求し、その標準デバイス２Ａから収集する。
デバイス処理情報収集部１１４は、標準インタフェースが例えばＵＰｎＰである場合には、選択した標準デバイス２Ａから、デバイス処理情報として、ＵＰｎＰ Descriptionを収集する。
【００４１】
サービス実行部１１５は、記憶部１３に記憶された連携ロジック（標準ＩＦ）１３１Ａに基づき、複数の標準デバイス２Ａを連携させるサービスを実行する。その際、サービス実行部１１５は、各標準デバイス２Ａへの具体的な操作等の指示を、デバイス処理情報収集部１１４が収集した、ＵＰｎＰ Descriptionに記述されたＳＯＡＰ等により行う。
【００４２】
＜処理の流れ＞
次に、本発明の第１実施形態に係るデバイス連携サーバ１Ａの処理の流れについて説明する。図４は、本発明の第１実施形態に係るデバイス連携サーバ１Ａの処理の流れを示すフローチャートである。
【００４３】
まず、デバイス連携サーバ１Ａのサービス要求受信部１１１は、サービス利用者９０（図２参照）が備える端末９から、サービス要求メッセージを受信する（ステップＳ１０）。このサービス要求メッセージには、少なくとも要求するサービスの識別情報（サービス識別情報）、ユーザの識別情報、端末９の位置情報が含まれる。
なお、ユーザの識別情報としては、そのユーザに固有なＩＤ（Identification）に加えて、監視カメラ等からの映像を画像解析（顔認識）し、人物を特定するための情報（顔写真のデータや特徴量等）が含まれていてもよい。
【００４４】
続いて、メタデータ取得部１１２は、各標準デバイス２Ａのメタデータ（デバイスの機能や位置情報等）を取得し、記憶部１３内のデバイス情報ＤＢ１３２に格納する（ステップＳ１１）。
ここで、メタデータ取得部１１２は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれる端末９の位置情報に基づき、端末９が位置するエリアに属する標準デバイス２Ａからメタデータを取得するようにしてもよい。
【００４５】
次に、デバイス連携サーバ１Ａのデバイス選択部１１３は、サービス利用者が要求するサービスを実現するためのデバイス（標準デバイス２Ａ）を選択する（ステップＳ１２）。
具体的には、デバイス選択部１１３は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれるサービス識別情報を用いて、記憶部１３内の連携ロジック（標準ＩＦ）１３１Ａを参照し、そのサービスの提供に必要なデバイスの機能を特定する。そして、デバイス選択部１１３は、その特定した機能を備え、端末９の位置情報で示される位置の近傍に位置する標準デバイス２Ａを、デバイス情報ＤＢ１３２を参照して選択する。デバイス選択部１１３は、機能および位置に加えて、メタデータに含まれる他の条件（値段、サービス提供者等）も加えて、標準デバイス２Ａを選択してもよい。
【００４６】
続いて、デバイス連携サーバ１Ａのデバイス処理情報収集部１１４は、デバイス選択部１１３が選択した標準デバイス２Ａに対し、例えば、ＨＴＴＰ等のアクセス手法により、そのデバイスの操作手順等を示すデバイス処理情報を要求し、その標準デバイス２Ａから収集する（ステップＳ１３）。
デバイス処理情報収集部１１４は、標準インタフェースが例えばＵＰｎＰである場合には、選択した標準デバイス２Ａから、デバイス処理情報として、ＵＰｎＰ Descriptionを収集する。例えば、標準デバイス２Ａが、監視カメラであれば、監視カメラの動き（ズームやパン等）の指示の記述をＵＰｎＰ Descriptionとして取得する。
【００４７】
そして、サービス実行部１１５は、記憶部１３に記憶された連携ロジック（標準ＩＦ）１３１Ａに基づき、連携サービスを実行する（ステップＳ１４）。
例えば、駅での観光客のナビゲーションサービスでは、デバイス連携サーバ１Ａは、そのサービス利用者９０の近傍に位置する、駅の監視カメラ、駅のディスプレイ、駅のスピーカ等を標準デバイス２Ａとして選択する。そして、デバイス連携サーバ１Ａのサービス実行部１１５は、監視カメラによって、観光客を顔認識により特定し、駅のディスプレイの前にくると、そのディスプレイに、乗換先や時刻、地図等が表示されるように、ディスプレイを制御する。また、監視カメラによって、対象とする観光客の移動方向を解析することにより、誤った方向に向かっていると判定した場合には、駅のスピーカにより、別方向に向かっている旨のアナウンスを発する指示を出す。
このような連携サービスの個々の処理を実行する条件は、連携ロジック（標準ＩＦ）１３１Ａにおいて記述される。そして、デバイス連携サーバ１Ａのサービス実行部１１５は、時々刻々変化するサービス利用者９０の情報（位置情報や画像解析の情報等）をリアルタイムに取得し、適切なナビゲーションをサービスとして実行する。
【００４８】
このように、本実施形態に係る分散リソース活用システム１００Ａのデバイス連携サーバ１Ａによれば、連携ロジックを、標準インタフェースを用いて記述し、標準インタフェースにより動作可能な標準デバイス２Ａを用いて連携サービスを提供することができる。よって、標準インタフェースを備えるデバイスであれば、デバイスの種別を問わず、各デバイスが備える機能を連携させてサービスを提供することが可能となる。
【００４９】
＜第２実施形態＞
第２実施形態は、デバイス連携サーバ１が、抽象的に記述された連携ロジックを備え、サービス実行時には、デバイス連携サーバ１が各デバイスに適合するインタフェース（ＩＦ）に変換して指示することを特徴とする。
【００５０】
図５は、本発明の第２実施形態に係る分散リソース活用システム１００Ｂの概要を説明するための図である。なお、図５においては、図１に示した分散リソース活用システム１００のうち、デバイスレイヤの各リソース（センサやアクチュエータ等のデバイス）とデバイス連携サーバ１のみを抽出して図示している。
【００５１】
図５に示すように、分散リソース活用システム１００Ｂにおけるデバイス２Ｂは、図２で示した第１実施形態に係るデバイス（標準デバイス２Ａ）のように、標準化されておらず、各デバイス２Ｂにおいてインタフェース（ＩＦ）が異なっていてもよいことを前提としている。各デバイス２Ｂ（２Ｂ１，２Ｂ２，２Ｂ３）は、例えば、ＢＬＥ（Bluetooth Low Energy）（「Bluetooth」は登録商標）、Ｅｃｈｏｎｅｔ、ＲＥＳＴ等の各通信プロトコルに準拠したインタフェースによりアクセスが可能であるとする。
これは、デバイスについては、現実には多種多様であり、標準化されていないデバイスを用いてサービスを提供する必要がある場合も想定されるからである。このため、連携ロジックをデバイスの具体的インタフェースに依存しない抽象的指示として記述する。
【００５２】
分散リソース活用システム１００Ｂのデバイス連携サーバ１Ｂは、複数のデバイス２Ｂを連携させたサービスを実現するため、抽象的な連携ロジック（図５の「連携ロジック（抽象的）１３１Ｂ」）を予め記憶しておく。そして、サービス利用者９０の端末９から、サービス要求メッセージを受け付けた際に、デバイス連携サーバ１Ｂは、その抽象的な連携ロジックに基づき、各デバイス２Ｂのメタデータや端末９の位置情報を用いて、サービスに利用するデバイス２Ｂを選択する。次に、デバイス連携サーバ１Ｂは、選択した各デバイス２Ｂの処理を実行する際に、抽象的な連携ロジックを、デバイス２Ｂから取得したデバイス処理情報で示される具体的インタフェースにマッチングすることにより変換する。そして、変換した具体的なインタフェースを用いて、デバイスを連携利用する。
なお、本実施形態（第２および後記する第３実施形態）において、「抽象的な（指示・ロジック）」とは、個々のデバイスの具体的インタフェースに依存しないことを意味し、例えば、ＸＭＬ等のメタデータにより記述された指示情報やロジックを意味する。
【００５３】
この抽象的な連携ロジックを用いた処理は、例えば、セマンティックＷｅｂの技術を用いて実現される。このセマンティックＷｅｂは、例えば、「赤埴淳一、他５名、“実世界セマンティックＷｅｂに向けて ― 時空間メタデータによるＷｅｂ検索の拡張”、一般社団法人電気通信協会、ＮＴＴ技術ジャーナル、2003年4月、P.29-34」に詳しい。
セマンティックＷｅｂは、情報（メタデータ）を記述するための枠組みであるＲＤＦ（Resource Description Framework）と、語彙（単語間の関係：オントロジ）を定義するためのＯＷＬ−Ｓ（Web Ontology Language for Service）とによって実現される。このＯＷＬ−Ｓは、図５に示すように、サービスの概要を示すプロファイル（Profile）、具体的な操作（プロセス）を示すプロセスモデル（Process Model）、ＯＷＬ−Ｓで記述した内容を各デバイスのインタフェース（ＩＦ）の規格に沿った記述にマッピングするためのグランディング（Grounding）という３種類の情報からなり、これら情報（公開メタデータ２００）が各デバイス２Ｂに付与される。デバイス連携サーバ１Ｂは、この公開メタデータ２００のうち、各デバイス２Ｂ（２Ｂ１，２Ｂ２，２Ｂ３）に関するプロファイルの情報を取得し記憶部に記憶する。そして、その情報を用いて、要求されたサービスを実現できるように、利用するデバイス２Ｂを選択する。次に、デバイス連携サーバ１Ｂは、選択したデバイス２Ｂから、プロセスモデル、グランディングの情報（デバイス処理情報）および具体的インタフェースの情報を取得し、抽象的な連携ロジックに基づく指示情報をそのデバイス２Ｂに適合した具体的インタフェースに変換した上で、サービスを提供する。
【００５４】
図６は、本発明の第２実施形態に係るデバイス連携サーバ１Ｂの構成例を示す機能ブロック図である。デバイス連携サーバ１Ｂは、サービス利用者９０（図２参照）が備える端末９からのサービス要求メッセージを受け付け、そのサービスを実行するための最適なデバイスを発見するとともに、抽象的な連携ロジック（連携ロジック（抽象的）１３１Ｂ）を用いて、複数のデバイス２Ｂが連携してサービスを提供するように制御する装置である。
このデバイス連携サーバ１Ｂは、図６に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。図３に示したデバイス連携サーバ１Ａとの違いは、制御部１１にマッピング処理部１１６をさらに備えることと、連携ロジックが、標準インタフェース（ＩＦ）ではなく、抽象的な連携ロジック（連携ロジック（抽象的）１３１Ｂ）となっていることである。なお、図３に示したデバイス連携サーバ１Ａと、同じ機能を備える構成は、同一の名称と符合を付し、詳細な説明を省略する。
【００５５】
記憶部１３に記憶される連携ロジック１３１Ｂは、上記のように、抽象的な指示情報として記述される。例えば、セマンティックＷｅｂのＯＷＬ−Ｓの規定に則り記述される。その他でも、標準化団体ＯＭＡ（Open Mobile Alliance）において標準化されたＧｏＴＡＰＩ等であってもよい。ＧｏＴＡＰＩについては、例えば、「 “ＧｏＴＡＰＩとは”、［online］、デバイスWebAPIコンソーシアム、［平成30年1月5日検索］、インターネット＜ＵＲＬ：https://device-webapi.org/gotapi.html＞」に詳しい。
【００５６】
記憶部１３のデバイス情報ＤＢ１３２には、デバイスレイヤに存在する各デバイス２Ｂの公開されているメタデータが格納される。このデバイスのメタデータには、少なくとも、デバイスの識別情報、デバイスの種別（そのデバイスの機能等を示す情報）、デバイスの位置情報が格納される。
なお、抽象的な連携ロジック１３１Ｂとして、ＯＷＬ−Ｓを採用した場合には、このデバイス情報ＤＢ１３２には、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報（例えば、図５に示す、機能、位置、サービスの利用に関する値段、デバイスの所有者（具体的サービスの提供者）等）が格納される。
【００５７】
デバイス選択部１１３は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれる要求するサービスの識別情報（サービス識別情報）を用いて、そのサービスの提供に必要なデバイス２Ｂの機能を特定する。そして、デバイス選択部１１３は、特定した機能を備えるデバイス（デバイス２Ｂ）であり、端末９の位置情報で示される位置の近傍に位置するデバイス２Ｂを、デバイス情報ＤＢ１３２を参照して選択する。例えば、デバイス選択部１１３は、デバイス情報ＤＢ１３２に記憶された、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報に基づき、デバイス２Ｂを選択する。なお、デバイス選択部１１３は、機能および位置情報とともに、例えば、そのデバイス２Ｂを利用する値段（利用料金）やサービス提供者（事業者）等の他のメタデータに関する情報を条件に加えて、サービスに利用するデバイス２Ｂを選択するようにしてもよい。
【００５８】
デバイス処理情報収集部１１４は、デバイス選択部１１３が選択したデバイス２Ｂに対し、そのデバイスの操作手順等を示すデバイス処理情報を要求し、そのデバイス２Ｂから取得する。
なお、デバイス処理情報収集部１１４は、例えば、各デバイス２Ｂの公開メタデータがＯＷＬ−Ｓで規定されている場合には、デバイス処理情報として、プロセスモデル（Process Model）およびグランディング（Grounding）の情報と、そのデバイス２Ｂの具体的インタフェースの情報とを、デバイス処理情報として取得する。
【００５９】
マッピング処理部１１６は、デバイス処理情報収集部１１４がデバイス２Ｂから取得したデバイス処理情報を用いて、そのデバイス２Ｂに適合する具体的なインタフェースに、サービスの実行に関する処理をマッピングすることにより変換する。
例えば、マッピング処理部１１６は、ＯＷＬ−Ｓで規定されるプロセスモデルで示される具体的なプロセス（デバイスの処理）を、グランディングの情報を用いてそのデバイス２Ｂに適合するインタフェースに変換する。図５に示すように、マッピング処理部１１６は、デバイス２Ｂの具体的インタフェース（ＩＦ）として設定されている、ＢＬＥや、Ｅｃｈｏｎｅｔ、ＲＥＳＴ等に変換する。
【００６０】
サービス実行部１１５は、記憶部１３に記憶された連携ロジック（抽象的）１３１Ｂに基づき、複数のデバイス２Ｂを連携させるサービスを実行する。その際、サービス実行部１１５は、マッピング処理部１１６が変換した具体的な操作等を各デバイス２Ｂに指示する。
【００６１】
＜処理の流れ＞
次に、本発明の第２実施形態に係るデバイス連携サーバ１Ｂの処理の流れについて説明する。図７は、本発明の第２実施形態に係るデバイス連携サーバ１Ｂの処理の流れを示すフローチャートである。
なお、以下においては、分散リソース活用システム１００Ｂは、セマンティックＷｅｂのＯＷＬ−Ｓに規定されたメタデータや記述を採用している例として説明する。よって、デバイス連携サーバ１Ｂの記憶部１３内のデバイス情報ＤＢ１３２には、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報として、そのデバイスの識別情報、デバイスの種別（そのデバイスの機能等を示す情報）、デバイスの位置情報等が格納される。
【００６２】
まず、デバイス連携サーバ１Ｂのサービス要求受信部１１１は、サービス利用者９０（図２参照）が備える端末９から、サービス要求メッセージを受信する（ステップＳ２０）。このサービス要求メッセージには、少なくとも要求するサービスの識別情報（サービス識別情報）、ユーザの識別情報、端末９の位置情報が含まれる。
なお、ユーザの識別情報としては、そのユーザに固有なＩＤに加えて、監視カメラ等からの映像を画像解析（顔認識）し、人物を特定するための情報（顔写真のデータや特徴量等）が含まれていてもよい。
【００６３】
続いて、メタデータ取得部１１２は、各デバイス２Ｂのメタデータ（デバイスの機能や位置情報等）を取得し、記憶部１３内のデバイス情報ＤＢ１３２に格納する（ステップＳ２１）。
ここで、メタデータ取得部１１２は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれる端末９の位置情報に基づき、端末９が位置するエリアに属するデバイス２Ｂからメタデータを取得するようにしてもよい。
【００６４】
次に、デバイス連携サーバ１Ｂのデバイス選択部１１３は、サービス利用者９０が要求するサービスを実現するためのデバイス（デバイス２Ｂ）を選択する（ステップＳ２２）。
具体的には、デバイス選択部１１３は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれるサービス識別情報を用いて、記憶部１３内の連携ロジック（抽象的）１３１Ｂを参照し、そのサービスの提供に必要なデバイスの機能を特定する。そして、デバイス選択部１１３は、その特定した機能を備えるデバイス（デバイス２Ｂ）であり、端末９の位置情報で示される位置の近傍に位置するデバイス２Ｂを、デバイス情報ＤＢ１３２を参照して選択する。
ここで、デバイス選択部１１３は、例えば、デバイス情報ＤＢ１３２に記憶された、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報（機能や位置情報）に基づき、デバイス２Ｂを選択する。
なお、デバイス選択部１１３は、機能および位置に加えて、メタデータに含まれる他の条件（値段、サービス提供者等）も加えて、デバイス２Ｂを選択してもよい。
【００６５】
続いて、デバイス連携サーバ１Ｂのデバイス処理情報収集部１１４は、デバイス選択部１１３が選択したデバイス２Ｂに対し、そのデバイスの操作手順等を示すデバイス処理情報を要求し、そのデバイス２Ｂから収集する（ステップＳ２３）。
デバイス処理情報収集部１１４は、例えば、各デバイス２Ｂの公開メタデータがＯＷＬ−Ｓで規定されている場合には、デバイス処理情報として、プロセスモデル（Process Model）およびグランディング（Grounding）の情報と、そのデバイス２Ｂの具体的インタフェースの情報とを、デバイス処理情報として取得する。
【００６６】
次に、デバイス連携サーバ１Ｂのマッピング処理部１１６は、デバイス処理情報収集部１１４がデバイス２Ｂから取得したデバイス処理情報を用いて、そのデバイス２Ｂに適合する具体的インタフェース（ＩＦ）に、サービスの実行に関する処理をマッピングすることにより変換する（ステップＳ２４）。
マッピング処理部１１６は、例えば、ＯＷＬ−Ｓで規定されるプロセスモデルで示される具体的なプロセス（デバイスの処理）を、グランディングの情報を用いて、そのデバイス２Ｂに適合する具体的インタフェース（ＩＦ）、例えば、ＢＬＥやＥｃｈｏｎｅｔ、ＲＥＳＴ等に変換する。
【００６７】
そして、デバイス連携サーバ１Ｂのサービス実行部１１５は、記憶部１３に記憶された連携ロジック（抽象的）１３１Ｂに基づき、連携サービスを実行する（ステップＳ２５）。
各デバイス２Ｂを連携するためのロジック（連携ロジック１３１Ｂ）には、各デバイス２Ｂが処理を実行に移すための条件やパラメータが記述される。そして、デバイス連携サーバ１Ｂは、時々刻々変化するサービス利用者９０の情報（位置情報等）をリアルタイムに取得し、適切なデバイス２Ｂを発見した上で、連携ロジック（抽象的）１３１Ｂに基づく指示情報を、そのデバイス２Ｂの具体的インタフェースに適合する指示情報に変換した上で、ナビゲーション等の連携サービスを実行する。
【００６８】
このように、本実施形態に係る分散リソース活用システム１００Ｂのデバイス連携サーバ１Ｂによれば、連携ロジックを、個別のインタフェース等に依存しないように抽象的に記述する。そして、デバイス連携サーバ１Ｂは、その抽象的に記述された連携ロジックを、デバイス２Ｂそれぞれに適合するインタフェースに変換して、連携したサービスを提供することができる。
【００６９】
＜第３実施形態＞
第３実施形態は、デバイス連携サーバ１が、抽象的に記述された連携ロジックを備え、サービス実行時には、デバイス連携サーバ１から抽象的な指示をゲートウェイ（ＧＷ）に送り、ゲートウェイがその抽象的な指示を各デバイスに対応した具体的なインタフェースに変換することにより、各デバイスの処理を実行させることを特徴とする。
【００７０】
図８は、本発明の第３実施形態に係る分散リソース活用システム１００Ｃの概要を説明するための図である。なお、図８においては、図１に示した分散リソース活用システム１００のうち、デバイスレイヤの各リソース（センサやアクチュエータ等のデバイス）、デバイスレイヤのゲートウェイ（ＧＷ）３０、デバイス連携サーバ１のみを抽出して図示している。
【００７１】
図８に示すように、分散リソース活用システム１００Ｃにおけるデバイス２Ｃは、図５で示したデバイス２Ｂと同様に、標準化されておらず、各デバイス２Ｃのおいて、インタフェース（ＩＦ）が異なっていてもよいことを前提としている。各デバイス２Ｃ（２Ｃ１，２Ｃ２，２Ｃ３）は、例えば、ＢＬＥ、Ｅｃｈｏｎｅｔ、ＲＥＳＴ等の各通信プロトコルに準拠したインタフェースによりアクセスが可能であるとする。
また、このデバイス２Ｃは、そのデバイス２Ｃそれぞれを収容するデバイスレイヤに属するゲートウェイ３０と接続され、このゲートウェイ３０を介して、デバイス連携サーバ１Ｃとの間で情報の送受信を行う。
【００７２】
図５で示した第２実施形態に係る分散リソース活用システム１００Ｂとの違いは、第２実施形態においては、デバイス連携サーバ１Ｂが、デバイス処理情報収集部１１４およびマッピング処理部１１６を備え、各デバイス２Ｂに適合するインタフェースに変換することにより、サービス実行部１１５が、直接各デバイス２Ｂに変換した指示情報を送信していた。
一方、図８で示す第３実施形態に係る分散リソース活用システム１００Ｃでは、デバイス連携サーバ１Ｃのサービス実行部１１５Ｃ（後記する図９参照）が、サービスを実行するための抽象的な指示（抽象的指示情報）をゲートウェイ３０に送信する。そして、ゲートウェイ３０が、デバイス処理情報収集部３０１およびマッピング処理部３０２（図９参照）を備え、各デバイス２Ｃに適合するインタフェースに指示情報を変換し、各デバイス２Ｃに送信することにより、連携サービスを実現する。
なお、第２実施形態と同様に、第３実施形態に係る分散リソース活用システム１００Ｃの抽象的な連携ロジックは、セマンティックＷｅｂのＯＷＬ−Ｓが採用されたものとして説明する。
【００７３】
図９は、本発明の第３実施形態に係るデバイス連携サーバ１Ｃおよびゲートウェイ（ＧＷ）３０の構成例を示す機能ブロック図である。
デバイス連携サーバ１Ｃは、サービス利用者９０（図２参照）が備える端末９からのサービス要求を受け付け、そのサービスを実行するための最適なデバイス２Ｃを発見するとともに、抽象的な連携ロジック（連携ロジック（抽象的）１３１Ｃ）を用いて、抽象的指示をゲートウェイ３０に送信する。ゲートウェイ３０は、デバイス連携サーバ１Ｃから受け取った抽象的指示を、各デバイス２Ｃに適合する具体的インタフェースに変換して、そのデバイス２Ｃに送信し、連携サービスを実行させる。
【００７４】
≪デバイス連携サーバ１Ｃ≫
デバイス連携サーバ１Ｃは、図９に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。図６に示したデバイス連携サーバ１Ｂとの違いは、制御部１１に、デバイス処理情報収集部１１４およびマッピング処理部１１６を備えないことと、図６のサービス実行部１１５が、サービス実行部１１５Ｃとなったことである。
なお、図６に示したデバイス連携サーバ１Ｂと、同じ機能を備える構成は、同一の名称と符合を付し、詳細な説明を省略する。
【００７５】
記憶部１３に記憶される連携ロジック（抽象的）１３１Ｃは、連携ロジックが標準インタフェース（ＩＦ）ではなく、図６の連携ロジック１３１Ｂと同様に、抽象的な連携ロジックが格納される。
また、記憶部１３のデバイス情報ＤＢ１３２には、デバイスレイヤに存在する各デバイス２Ｃの公開されているメタデータが格納される。このデバイス２Ｃのメタデータには、少なくとも、デバイスの識別情報、デバイスの種別（そのデバイスの機能等を示す情報）、デバイスの位置情報が格納される。
なお、抽象的な連携ロジック１３１Ｃとして、ＯＷＬ−Ｓを採用した場合には、このデバイス情報ＤＢ１３２には、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報（例えば、図８に示す、機能、位置、サービスの利用に関する値段、デバイスの所有者（具体的サービスの提供者）等）が格納される。
【００７６】
サービス実行部１１５Ｃは、記憶部１３に記憶された連携ロジック（抽象的）１３１Ｃに基づき、連携サービスを実行する。その際、サービス実行部１１５Ｃは、時々刻々変化するサービス利用者９０の情報（位置情報等）をリアルタイムに取得し、デバイス選択部１１３の処理により適切なデバイス２Ｃを随時選択しながら、適切なサービスが実行できるような指示情報（抽象的指示情報）を、デバイス選択部１１３が選択したデバイス２Ｃを収容するゲートウェイ３０に送信する。なお、サービス実行部１１５Ｃは、デバイス２Ｃを収容するゲートウェイ３０に対し、抽象的指示情報を標準的手段（例えば、ＲＥＳＴ等）により送信する。
【００７７】
≪ゲートウェイ≫
ゲートウェイ（ＧＷ）３０は、不図示の制御部と、入出力部と、記憶部とを含んで構成され、通常のゲートウェイの機能である異なるネットワーク同士を接続するためのプロトコル変換等の機能に加え、制御部の中に、図９に示すような、デバイス処理情報収集部３０１、マッピング処理部３０２および指示出力部３０３を備えることを特徴とする。
【００７８】
デバイス処理情報収集部３０１は、そのゲートウェイ（ＧＷ）３０に接続されるデバイス２Ｃから、当該デバイス２Ｃの操作手順等を示すデバイス処理情報を取得する。このデバイス処理情報は、例えば、各デバイス２Ｃの公開メタデータがＯＷＬ−Ｓで規定されている場合には、プロセスモデル（Process Model）およびグランディング（Grounding）の情報と、そのデバイス２Ｃの具体的インタフェースの情報である。
デバイス処理情報収集部３０１は、自身と接続するデバイス２Ｃに関するデバイス処理情報を、予め収集し記憶部に記憶しておくようにしてもよいし、デバイス連携サーバ１Ｃから、特定のデバイス２Ｃに関する指示情報（抽象的指示情報）を受信した際に、その特定のデバイス２Ｃから、デバイス処理情報を取得するようにしてもよい。
【００７９】
マッピング処理部３０２は、デバイス連携サーバ１Ｃから、サービスに関する処理の指示情報（抽象的指示情報）を受信した際に、その処理を実行するデバイス２Ｃのデバイス処理情報を用いて、そのデバイス２Ｃに適合する具体的なインタフェースに、その指示情報をマッピングすることにより変換する。
マッピング処理部３０２は、例えば、ＯＷＬ−Ｓで規定されるプロセスモデルで示される具体的なプロセス（デバイスの処理）を、グランディングの情報を用いてそのデバイス２Ｃに適合するインタフェースに変換する。図８に示すように、マッピング処理部３０２は、デバイス２Ｃの具体的インタフェース（ＩＦ）として設定されている、ＢＬＥや、Ｅｃｈｏｎｅｔ、ＲＥＳＴ等に変換する。
【００８０】
指示出力部３０３は、マッピング処理部３０２により、そのデバイス２Ｃの具体的インタフェースに適合するように変換された指示情報を、当該デバイス２Ｃに出力する。これにより、各デバイス２Ｃを動作させ、連携サービスを実現させる。
【００８１】
＜処理の流れ＞
次に、本発明の第３実施形態に係る分散リソース活用システム１００Ｃの処理の流れについて説明する。図１０は、本発明の第３実施形態に係る分散リソース活用システム１００Ｃ（デバイス連携サーバ１Ｃおよびゲートウェイ３０）の処理の流れを示すシーケンス図である。
なお、以下においては、分散リソース活用システム１００Ｃは、セマンティックＷｅｂのＯＷＬ−Ｓに規定されたメタデータや記述を採用している例として説明する。よって、デバイス連携サーバ１Ｃの記憶部１３内のデバイス情報ＤＢ１３２には、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報として、そのデバイスの識別情報、デバイスの種別（そのデバイスの機能等を示す情報）、デバイスの位置情報等が格納される。また、ゲートウェイ３０の記憶部には、各デバイス２Ｃのプロセスモデル（Process Model）およびグランディング（Grounding）に関する情報と、各デバイス２Ｃの具体的インタフェースの情報が格納される。
【００８２】
まず、デバイス連携サーバ１Ｃのサービス要求受信部１１１は、サービス利用者９０（図２参照）が備える端末９から、サービス要求メッセージを受信する（ステップＳ３０）。このサービス要求メッセージには、少なくとも要求するサービスの識別情報（サービス識別情報）、ユーザの識別情報、端末９の位置情報が含まれる。
なお、ユーザの識別情報としては、そのユーザに固有なＩＤに加えて、監視カメラ等からの映像を画像解析（顔認識）し、人物を特定するための情報（顔写真のデータや特徴量等）が含まれていてもよい。
【００８３】
続いて、メタデータ取得部１１２は、各デバイス２Ｃのメタデータ（デバイスの機能や位置情報等）を取得し、記憶部１３内のデバイス情報ＤＢ１３２に格納する（ステップＳ３１）。
ここで、メタデータ取得部１１２は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれる端末９の位置情報に基づき、端末９が位置するエリアに属するデバイス２Ｃからメタデータを取得するようにしてもよい。
【００８４】
次に、デバイス連携サーバ１Ｃのデバイス選択部１１３は、サービス利用者が要求するサービスを実現するためのデバイス（デバイス２Ｃ）を選択する（ステップＳ３２）。
具体的には、デバイス選択部１１３は、サービス要求受信部１１１が受信したサービス要求メッセージに含まれるサービス識別情報を用いて、記憶部１３内の連携ロジック（抽象的）１３１Ｃを参照し、そのサービスの提供に必要なデバイスの機能を特定する。そして、デバイス選択部１１３は、その特定した機能を備えるデバイス（デバイス２Ｃ）であり、端末９の位置情報で示される位置の近傍に位置するデバイス２Ｃを、デバイス情報ＤＢ１３２を参照して選択する。
ここで、デバイス選択部１１３は、例えば、デバイス情報ＤＢ１３２に記憶された、ＯＷＬ−Ｓで規定されるプロファイル（Profile）の情報（機能や位置情報）に基づき、デバイス２Ｃを選択する。
なお、デバイス選択部１１３は、機能および位置に加えて、メタデータに含まれる他の条件（値段、サービス提供者等）も加えて、デバイス２Ｃを選択してもよい。
【００８５】
続いて、デバイス連携サーバ１Ｃのサービス実行部１１５Ｃは、記憶部１３に記憶された連携ロジック（抽象的）１３１Ｃに基づき、サービスを実現するための処理内容を示す指示情報（抽象的指示情報）を、デバイス選択部１１３が選択した特定のデバイス２Ｃを収容するゲートウェイ３０へ送信する（ステップＳ３３）。
【００８６】
続いて、デバイス連携サーバ１Ｃから抽象的指示情報を受信したゲートウェイ３０のデバイス処理情報収集部３０１は、デバイス連携サーバ１Ｃのデバイス選択部１１３が選択したデバイス２Ｃに対し、そのデバイスの操作手順等を示すデバイス処理情報を要求し、そのデバイス２Ｃから収集する（ステップＳ３４）。
デバイス処理情報収集部３０１は、例えば、各デバイス２Ｃの公開メタデータがＯＷＬ−Ｓで規定されている場合には、デバイス処理情報として、プロセスモデル（Process Model）およびグランディング（Grounding）の情報と、そのデバイス２Ｃの具体的インタフェースの情報とを、デバイス処理情報として取得する。
【００８７】
次に、ゲートウェイ３０のマッピング処理部３０２は、抽象的指示情報を、取得したデバイス処理情報を用いて、そのデバイス２Ｃに適合する具体的インタフェースにマッピングすることにより変換する（ステップＳ３５）。
マッピング処理部３０２は、例えば、ＯＷＬ−Ｓで規定されるプロセスモデルで示される具体的なプロセス（デバイスの処理）を、グランディングの情報を用いて、そのデバイス２Ｃに適合する具体的インタフェース（ＩＦ）、例えば、ＢＬＥやＥｃｈｏｎｅｔ、ＲＥＳＴ等に変換する。
【００８８】
そして、ゲートウェイ３０の指示出力部３０３は、マッピング処理部３０２により、そのデバイス２Ｃのインタフェースに適合するように変換された指示情報を、当該デバイス２Ｃに出力する（ステップＳ３６）。これにより、各デバイス２Ｃを動作させ、連携サービスを実現させる。
【００８９】
このように、本実施形態に係る分散リソース活用システム１００Ｃによれば、デバイス連携サーバ１Ｃに、個別のインタフェース等に依存しない抽象的な連携ロジック１３１Ｃを記述しておき、その抽象的な連携ロジック１３１Ｃで示される抽象的指示情報を、ゲートウェイ３０に送信する。よって、デバイス連携サーバ１Ｃにおいて、各デバイス２Ｃに対応したＩＦアクセス手段への変換機能（デバイス処理情報収集部およびマッピング処理部）を持つ必要をなくすことができる。これにより、デバイス連携サーバ１Ｃの負荷を低減することができる。
【００９０】
（変形例）
本発明は、上記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
例えば、本発明の第２実施形態と第３実施形態の両方の構成を備えた手法としてもよい。
具体的には、ＳＯＡＰやＲＥＳＴ等の主要な通信プロトコルで制御できるデバイスは、第２実施形態のデバイス連携サーバ１Ｂのように、デバイス連携サーバが直接そのデバイスに適合したインタフェースに変換して制御する。一方、あまり知られていない通信プロトコルで制御されるデバイスは、第３実施形態のデバイス連携サーバ１Ｃのように、デバイス連携サーバ１から抽象的指示情報をゲートウェイ３０に送信し、ゲートウェイ３０がそのデバイスに適合したインタフェースに変換して指示をする。
これにより、デバイス連携サーバ１が、すべてのデバイスに適合する変換手段を備える必要がなくなる。また、デバイス連携サーバ１が主要な通信プロトコルで制御できるデバイスの処理を担当するため、ゲートウェイ３０の変換機能の実装コストを低減することができる。
【符号の説明】
【００９１】
１，１Ａ，１Ｂ，１Ｃ  デバイス連携サーバ
２，２Ｂ，２Ｃ  デバイス
２Ａ    標準デバイス
９      端末
１１    制御部
１２    入出力部
１３    記憶部
３０    ゲートウェイ（ＧＷ）
９０    サービス利用者
１００，１００Ａ，１００Ｂ，１００Ｃ  分散リソース活用システム
１１１  サービス要求受信部
１１２  メタデータ取得部
１１３  デバイス選択部
１１４，３０１  デバイス処理情報収集部
１１５，１１５Ｃ  サービス実行部
１１６，３０２  マッピング処理部
１３１Ａ  連携ロジック（標準ＩＦ）
１３１Ｂ，１３１Ｃ  連携ロジック（抽象的）
１３２  デバイス情報ＤＢ
２００  公開メタデータ
３０３  指示出力部
【図１】
2019125068.tif 000003
【図２】
2019125068.tif 000004
【図３】
2019125068.tif 000005
【図４】
2019125068.tif 000006
【図５】
2019125068.tif 000007
【図６】
2019125068.tif 000008
【図７】
2019125068.tif 000009
【図８】
2019125068.tif 000010
【図９】
2019125068.tif 000011
【図１０】
2019125068.tif 000012
【図１１】
2019125068.tif 000013