WO2017104287A1

WO2017104287A1 - データフロー制御装置およびデータフロー制御方法

Info

Publication number: WO2017104287A1
Application number: PCT/JP2016/082846
Authority: WO
Inventors: 哲二大和
Original assignee: オムロン株式会社
Priority date: 2015-12-14
Filing date: 2016-11-04
Publication date: 2017-06-22
Also published as: EP3392775A1; JP2017111501A; US10896347B2; US20180373956A1; JP6465012B2; EP3392775A4

Abstract

データフロー制御装置は、デバイス側メタデータおよびアプリ側メタデータのマッチングを行うことでアプリケーションの要求を満たすデータを提供可能なデバイスを抽出する。前記デバイス側メタデータには、デバイスが提供するデータの来歴を示す情報を記述可能であり、前記アプリ側メタデータには、アプリケーションが要求するデータの来歴を示す情報を記述可能である。データフロー制御装置は、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、複数のデバイスのなかからアプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出する。

Description

データフロー制御装置およびデータフロー制御方法

　本発明は、センサなどのデバイスにおいて得られるデータを当該データを利用するアプリケーションへと提供するデータフローを制御するための技術に関する。

　現在、Ｍ２Ｍクラウドと呼ばれるＩＴ環境が注目を集めている。Ｍ２Ｍ（Ｍａｃｈｉｎｅ　ｔｏ　Ｍａｃｈｉｎｅ）とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。Ｍ２Ｍを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。

　このようなＭ２Ｍの技術をクラウドコンピューティング環境上で実現したものはＭ２Ｍクラウドと呼ばれる。これは、Ｍ２Ｍに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。

　また、特許文献１に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス（以下、単に「センサ」とも呼ぶ）を様々な場所、移動体、産業設備などに設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。

　通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない（センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない）ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。

　また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。ＩｏＴから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。

特開２００７－３００５７１号公報国際公開第２０１４／０４１８２６号

　本出願人は、ＩｏＴにおいてセンシングデータなどの情報資源を適切に流通させる仕組みを実現するため、センサに関する情報が記述された「センサ側メタデータ」とセンシングデータを利用するアプリケーションに関する情報が記述された「アプリ側メタデータ」とのマッチングを行うことで、アプリケーションの要求を満たすセンシングデータを取得可能なセンサを特定し、センサからアプリケーションへのデータフローを制御するシステムを検討している（特許文献２参照）。この仕組みによれば、データの提供者と利用者の仲介を自動化でき、センシングデータの流通や利活用が促進されると期待できる。

　データの流通市場が拡大し、データ提供者やセンサの数が増えていくと、複数の者から類似のデータが提供されることが予想される。例えば、気象庁がＸ社製の温度センサｘで測定した京都の気温データを提供し、民間業者ＡがＹ社製の温度センサｙで測定した京都の気温データを提供し、個人ＢがＺ社製の温度センサｚで測定した京都の気温データを提供する、というような状況である。いずれのデータも京都の気温を測定したものであるが、測定者、測定方法、測定に用いるセンサなどが異なるため、データの精度・品質には当然違いがでる。このような場合、データ利用者としては、データの利用目的や用途にもっとも合致したデータの利用を望むはずである。例えば、データ利用者がアプリケーションにおいて正確なデータ解析を行う場合は、元データに高い精度や品質が要求される可能性が高い。一方、取引の安全やデータの品質保証の観点からも、提供されるデータの精度や品質を明らかにすることは重要と考えられる。しかしながら、従来（特許文献２）のセンサ側メタデータでは、センシングデータの信頼度を設定できるにとどまっている。信頼度は「高い」「低い」のように相対評価もしくは主観評価の結果により規定される可能性があり、センシングデータの精度や品質を絶対的もしくは客観的に保証する情報としては不足している。

　なお、ここまでセンサネットワークを例に挙げて説明をしたが、センサ以外の装置が出力（提供）するデータを流通させるネットワークにおいても、全く同様の課題が発生し得る。センサ以外の装置としては、例えば、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなど、何らかのデータを出力する装置であればどのような物も該当し得る。本明細書では、これらの装置（センサも含む）を包含する概念として「デバイス」という用語を用い、このようなデバイスが出力（提供）するデータを流通させるネットワークを「デバイスネットワーク」と呼ぶ。デバイスネットワークには、上に例示した様々な種類のデバイスが混在して接続されることもあり得る。

　本発明は上記実情に鑑みなされたものであり、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上するための技術を提供することを目的とする。

　請求項１に記載された発明は、複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部と、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部と、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスを抽出するマッチング部と、前記マッチング部のマッチング結果に基づき、前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行うデータフロー制御部と、を有し、前記デバイス側メタデータには、デバイスが提供するデータの来歴を示す情報を記述可能であり、前記アプリ側メタデータには、アプリケーションが要求するデータの来歴を示す情報を記述可能であり、前記マッチング部は、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出することを特徴とするデータフロー制御装置である。

　請求項１に記載された発明によれば、メタデータにデータの来歴を示す情報（以下、「データ来歴情報」と呼ぶ）が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ来歴情報によって、例えばそのデータの由来、経過、出所などがわかれば、データ利用者にとってはそのデータの精度、品質、信頼性、安全性などを判断する際の有効な材料となる。一方、データ提供者にとっては、データ来歴情報を開示することによって、そのデータの精度、品質、信頼性、安全性などを保証し、データの商品価値を高めることができるという利点がある。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項２に記載された発明は、データの来歴を示す情報は、当該データを提供するデバイスの製造者もしくは販売者を特定する情報、当該データを提供するデバイスの機種もしくは型式を特定する情報、および、当該データを提供するデバイスの所有者もしくは管理者を特定する情報、のうち少なくともいずれかを含むことを特徴とする請求項１に記載のデータフロー制御装置である。

　請求項２に記載された発明によれば、データ来歴情報を参照することで、デバイスの製造者、デバイスの販売者、デバイスの機種、デバイスの型式、デバイスの所有者、および、デバイスの管理者のうち少なくともいずれかの情報を知ることができる。例えば、データの精度や特性はそのデータを提供するデバイスの性能に大きく影響を受けると考えられるため、デバイスの製造者・販売者・機種・型式などの情報はデータの信頼性を判断する上で参考となる。また、データの品質保証という観点では、データの提供側の体制、運営、管理、メンテナンスの良し悪しなども影響するため、デバイスの所有者ないし管理者などの情報もデータの信頼性を判断する上で参考となる。

　請求項３に記載された発明は、データの来歴を示す情報は、当該データ、当該データを提供するデバイス、当該データの提供者、または、当該データを提供するデバイスの所有者もしくは管理者が、所定の基準に適合していることを証明する証明情報を含むことを特徴とする請求項１または２に記載のデータフロー制御装置である。

　請求項３に記載された発明によれば、データ来歴情報に含まれる証明情報によって、データ、デバイス、データ提供者、または、デバイスの所有者もしくは管理者が所定の基準に適合していることが証明されるので、当該データの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項４に記載された発明は、前記証明情報は、第三者認証機関により発行された電子証明書であることを特徴とする請求項３に記載のデータフロー制御装置である。

　請求項４に記載された発明によれば、第三者認証機関により発行された電子証明書を用いるので、当該データの精度や品質を客観的に保証することができ、データ取引の安全と信頼を一層向上することができる。

　請求項５に記載された発明は、前記デバイスは、センシングデータを出力するセンサであることを特徴とする請求項１～３のうちいずれか１項に記載のデータフロー制御装置である。

　請求項６に記載された発明は、コンピュータが、複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部から、デバイス側メタデータを取得するステップと、コンピュータが、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部から、アプリ側メタデータを取得するステップと、コンピュータが、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスを抽出するステップと、コンピュータが、前記マッチング結果に基づき、前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行うステップと、を有し、前記デバイス側メタデータには、デバイスが提供するデータの来歴を示す情報を記述可能であり、前記アプリ側メタデータには、アプリケーションが要求するデータの来歴を示す情報を記述可能であり、前記マッチングを行うステップでは、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出することを特徴とするデータフロー制御方法である。

　請求項６に記載された発明によれば、メタデータにデータの来歴を示す情報（以下、「データ来歴情報」と呼ぶ）が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ来歴情報によって、例えばそのデータの由来、経過、出所などがわかれば、データ利用者にとってはそのデータの精度、品質、信頼性、安全性などを判断する際の有効な材料となる。一方、データ提供者にとっては、データ来歴情報を開示することによって、そのデータの精度、品質、信頼性、安全性などを保証し、データの商品価値を高めることができるという利点がある。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項７に記載された発明は、請求項６に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラムである。

　請求項７に記載された発明によれば、メタデータにデータの来歴を示す情報（以下、「データ来歴情報」と呼ぶ）が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ来歴情報によって、例えばそのデータの由来、経過、出所などがわかれば、データ利用者にとってはそのデータの精度、品質、信頼性、安全性などを判断する際の有効な材料となる。一方、データ提供者にとっては、データ来歴情報を開示することによって、そのデータの精度、品質、信頼性、安全性などを保証し、データの商品価値を高めることができるという利点がある。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項８に記載された発明は、デバイスが提供するデータに関する情報を記述するデバイス側のメタデータのデータ構造であって、前記デバイスが提供するデータの仕様を示す情報と、前記デバイスが提供するデータの来歴を示す情報と、を含み、前記デバイス側メタデータは、データを利用するアプリケーションが要求する仕様および来歴の両方を満たすデータを提供可能なデバイスを複数のデバイスのなかから抽出するマッチングに利用されることを特徴とするメタデータのデータ構造である。

　請求項８に記載された発明によれば、デバイス側メタデータにデータの来歴を示す情報（以下、「データ来歴情報」と呼ぶ）が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ来歴情報によって、例えばそのデータの由来、経過、出所などがわかれば、データ利用者にとってはそのデータの精度、品質、信頼性、安全性などを判断する際の有効な材料となる。一方、データ提供者にとっては、データ来歴情報を開示することによって、そのデータの精度、品質、信頼性、安全性などを保証し、データの商品価値を高めることができるという利点がある。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項９に記載された発明は、アプリケーションが利用を希望するデータに関する情報を記述するアプリ側のメタデータのデータ構造であって、前記アプリケーションが要求するデータの仕様を示す情報と、前記アプリケーションが要求するデータの来歴を示す情報と、を含み、前記アプリ側メタデータは、前記アプリケーションが要求する仕様および来歴の両方を満たすデータを提供可能なデバイスを複数のデバイスのなかから抽出するマッチングに利用されることを特徴とするメタデータのデータ構造である。

　請求項９に記載された発明によれば、アプリ側メタデータにデータの来歴を示す情報（以下、「データ来歴情報」と呼ぶ）が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ利用者は、データ来歴情報を指定することによって、例えば信頼に足る由来、経過、出所のデータを利用することができるようになる。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項１０に記載された発明は、データの来歴を示す情報は、当該データを提供するデバイスの製造者もしくは販売者を特定する情報、当該データを提供するデバイスの機種もしくは型式を特定する情報、および、当該データを提供するデバイスの所有者もしくは管理者を特定する情報、のうち少なくともいずれかを含むことを特徴とする請求項８または９に記載のメタデータのデータ構造である。

　請求項１０に記載された発明によれば、データ来歴情報を参照することで、デバイスの製造者、デバイスの販売者、デバイスの機種、デバイスの型式、デバイスの所有者、および、デバイスの管理者のうち少なくともいずれかの情報を知ることができる。例えば、データの精度や特性はそのデータを提供するデバイスの性能に大きく影響を受けると考えられるため、デバイスの製造者・販売者・機種・型式などの情報はデータの信頼性を判断する上で参考となる。また、データの品質保証という観点では、データの提供側の体制、運営、管理、メンテナンスの良し悪しなども影響するため、データ提供者やデバイスの所有者ないし管理者などの情報もデータの信頼性を判断する上で参考となる。

　請求項１１に記載された発明は、データの来歴を示す情報は、当該データ、当該データを提供するデバイス、当該データの提供者、または、当該データを提供するデバイスの所有者もしくは管理者が、所定の基準に適合していることを証明する証明情報を含むことを特徴とする請求項８～１０のうちいずれか１項に記載のメタデータのデータ構造である。

　請求項１１に記載された発明によれば、データ来歴情報に含まれる証明情報によって、データ、デバイス、データ提供者、または、デバイスの所有者もしくは管理者が所定の基準に適合していることが証明されるので、当該データの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　請求項１２に記載された発明は、前記証明情報は、第三者認証機関により発行された電子証明書であることを特徴とする請求項１１に記載のメタデータのデータ構造である。

　請求項１２に記載された発明によれば、第三者認証機関により発行された電子証明書を用いるので、当該データの精度や品質を客観的に保証することができ、データ取引の安全と信頼を一層向上することができる。

　本発明における「デバイス」は、何らかのデータを出力（提供）するあらゆる装置を意味し、センサ、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなどが例示できる。中でも本発明は、センサから出力されるセンシングデータの流通を行うセンサネットワークに好適である。

　なお、本発明は、上記構成ないし機能の少なくとも一部を有するデータフロー制御装置として捉えることができる。また、本発明は、データフロー制御装置を有するデバイスネットワークシステムとして捉えることもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法、または、かかる方法をコンピュータに実行させるためのプログラム、または、そのようなプログラムを非一時的に記録したコンピュータ読取可能な記録媒体として捉えることもできる。また、本発明は、上記データフローを制御するための制御指令データストリームとして捉えることもできる。上記構成および処理の各々は技術的な矛盾が生じない限り互いに組み合わせて本発明を構成することができる。

　本発明によれば、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

図１はセンサネットワークシステムの全体構成を示す図。図２Ａはセンサ側メタデータ管理テーブルの一例を示す図、図２Ｂはアプリ側メタデータ管理テーブルの一例を示す図。図３Ａはセンサ側メタデータのデータ来歴設定画面の一例を示す図、図３Ｂはアプリ側メタデータのデータ来歴設定画面の一例を示す図。図４はセンサネットワークサーバによるマッチングおよびデータフロー制御のフローチャート。図５はデータフロー制御指令の一例を示す図。

　以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。

　以下に述べる実施形態では、本発明をＭ２Ｍクラウドを用いたセンサネットワークシステムに適用した例について説明する。かかる仕組みが実現すれば、センサネットワーク上に存在する多数のセンサから得られる多種多様な情報のなかから、所望の情報を誰もがどこからでも容易に取得することができるようになり、センサ（リソース）の有効利用、並びに、データ提供者からデータ利用者へのセンシングデータの流通が促進されると期待される。このシステムは、例えば、交通状況のセンシングデータに基づく交通制御システム、環境のセンシングデータに基づく気象予測システム、ビッグデータを利用した各種分析システム、センサメーカによる販売済みセンサのメンテナンスサービスなど、様々な用途への応用展開が可能である。

　＜システムの全体構成＞
　図１を参照して、本発明の実施形態に係るセンサネットワークシステムの全体的な構成を説明する。このセンサネットワークシステムは、データ提供者からデータ利用者へのセンシングデータの流通を制御するためのシステムであり、概略、複数のセンサ１０と、センサ１０を管理する装置であるセンサネットワークアダプタ１１と、センシングデータを利用してサービスを提供するアプリケーションを有する複数のアプリケーションサーバ１２と、センシングデータの提供者と利用者の仲介を担うデータフロー制御装置としてのセンサネットワークサーバ１４とを有している。

　各装置のあいだはインターネット等の広域ネットワークまたはＬＡＮにより通信可能に接続されている。なお、ネットワークは単一のネットワークとは限らず、様々な通信方式やトポロジーをもつ複数のネットワークを相互に接続した概念的なものと考えてもよい。要するに、センシングデータの送受信や、センシングデータの流通に関わるメタデータおよびデータフロー制御指令等のデータの送受信が実現できれば、どのような形態のネットワークを利用してもよい。

　（センサ）
　センサ１０は、センシング対象の物理量やその変化を検出し、センシングデータとして出力するデバイスである。センサ１０には、物理的な実体をもつセンサである「実センサ」と、１以上の元センサから得られるセンシングデータを加工、分析等して新たなデータを生成し仮想的なセンシングデータとして出力する機能モジュールである「仮想センサ」とが存在する。本明細書では、実センサと仮想センサを区別する必要がない文脈では単に「センサ」と記す。

　実センサには、例えば、画像センサ（監視カメラなど）、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ、ガスセンサ、加速度センサ、ジャイロスコープ、ＧＰＳセンサなどが該当する。また、携帯電話、スマートフォン、タブレット端末、モバイルＰＣ、ドローンなどの機器は様々な種類のセンサを搭載しているため、これらの機器を実センサとして取り扱うこともできる。本実施形態のセンサネットワークシステムには、ここで例示したセンサをはじめとして、いかなる種類のセンサを接続することができる。また、工場のＦＡや生産管理、都市交通制御、気象等の環境計測、ヘルスケア、防犯など、世の中のあらゆる場所に様々な用途・目的で多数のセンサが既に設置されているが、これらのセンサを本システムに接続することも可能である。なお、センサネットワークシステムは、一種類のセンサのみで構成してもよいし、複数の種類のセンサを混在させてもよい。

　仮想センサは、１以上の元センサ（入力センシングデータの取得先のセンサ）と、入力センシングデータを加工、分析等するプログラムである仮想センサ関数との組み合わせで構成される。元センサは実センサであってもよいし仮想センサであってもよい。

　例えば、あるアプリケーションサーバ１２が必要としている情報が「道路ＡＢを通過する車両の速度」であったとする。センサネットワークに接続された実センサのなかに道路ＡＢに設置された速度センサが存在していれば、この速度センサで得られたセンシングデータをアプリケーションサーバ１２に提供すればよい。しかし、アプリケーションサーバ１２の要求に完全に合致する実センサが存在しない場合もあり得る。そのような場合に、もし道路ＡＢの入口側の交差点Ａと出口側の交差点Ｂにそれぞれカメラが設置されていたならば、入口側カメラと出口側カメラのそれぞれから得られた画像データと時刻情報、および各カメラの位置情報をもとに、車が交差点Ａから交差点Ｂまで移動するのに要した時間と交差点ＡとＢの間の距離を計算し、その結果から車の速度を推定することができる。すなわち、交差点Ａ、Ｂそれぞれに設置されたカメラと仮想センサ関数により、車速センサと同等の機能を実現する仮想センサを作り出すことができるのである。なお、ここで例示したもの以外にも様々な種類の仮想センサを作ることが可能である。すなわち、１つまたは複数の入力センシングデータから、元の入力センシングデータとは異なる価値（新たな価値）をもつデータを生成し出力する機能を提供するモジュールであれば仮想センサと呼ぶことができ、アイデア次第で様々な仮想センサを創出できる。

　上記例より分かるように、本システムにおいて仮想センサの利用を可能にすることで、センサネットワークのリソース（実センサ）の利用率の向上や、新たな価値をもつセンシングデータの提供など、様々な効果が期待できる。

　（センサネットワークアダプタ）
　センサネットワークアダプタ１１は、１つまたは複数のセンサ１０と有線または無線により通信可能に接続され、センサ１０の管理、センサ１０からのセンシングデータの取得、センサネットワークシステムやアプリケーションへのセンシングデータの送信などを行う装置である。センサネットワークアダプタ１１は、センシングデータに所定の処理（例えばノイズ除去などの信号処理、平均処理などの演算、サンプリング、データ圧縮、タイムスタンプなど）を施す機能を有していてもよい。センサネットワークアダプタ１１は、外部装置との通信機能を有しており、アプリケーションサーバ１２、センサネットワークサーバ１４等とネットワークを介して通信が可能である。

　スマートフォン、タブレット端末、モバイルＰＣ、ドローン、ウェアラブル端末などの機器は、画像センサ、ＧＰＳセンサ、加速度センサ、マイクなどのセンサを内蔵し、各センサで得られたデータを加工し出力する機能やネットワーク通信機能を有している。したがって、これらの機器は、センサ１０とセンサネットワークアダプタ１１とが物理的に一体となったデバイスの例である。なお、通信機能を内蔵するセンサ１０の場合には単体で（つまりセンサネットワークアダプタ１１を介さずに）センサネットワークシステムに接続可能である。

　（アプリケーションサーバ）
　アプリケーションサーバ１２は、センシングデータを利用してサービスを提供する各種アプリケーションプログラムがインストールされたサーバ装置である。アプリケーションサーバ１２は、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。アプリケーションサーバ１２は、センシングデータの利用者が設置するものであり、その用途・目的に応じて様々なアプリケーションが想定される。

　アプリケーションの例としては、例えば、道路に設置されたセンサや、道路上を走行する車両に搭載された車載端末または運転者のスマートフォンなどから、各地点の交通状況を収集して渋滞マップを生成し、渋滞情報を利用する事業者等に提供するアプリケーションが考えられる。他にも、スマートフォンや車載カメラなどで走行中に撮影された画像データを収集し、各地点の状況を知りたい利用者に提供する映像配信アプリケーション、渋滞情報等を元に車両の走行ルートを検索する経路探索アプリケーション、特定の場所に設置されたカメラの映像から通行者の属性（性別、年齢層など）の統計データを推定し、各種調査用のデータとして提供するアプリケーション、センサメーカが販売済みの自社センサをオンラインメンテナンスするアプリケーションなど、様々なものが考えられる。

　（センサネットワークサーバ）
　センサネットワークサーバ１４は、センシングデータの提供者と利用者のあいだのマッチング、提供者から利用者へのセンシングデータのデータフロー制御などを担うサーバ装置であり、本発明に係るデータフロー制御装置の一具体例である。センサネットワークサーバ１４も、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。後述するセンサネットワークサーバ１４の各種機能は、ＣＰＵが必要なプログラムを実行することにより実現される。

　センサネットワークシステムは、多数の（または多種多様な）センサをネットワーク化し、センシングデータの収集や利用を可能とするものであるが、本実施形態では、データ提供者（センサ１０）がデータ利用者（アプリケーションサーバ１２）に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、データ提供者にとっては収益の機会、利用者にとっては安価なデータ取得というメリットが得られる。センサネットワークサーバ１４は、このようなセンシングデータの取引の仲介を行うサーバ装置であり、データ提供者とデータ利用者のあいだのマッチングを行い、センシングデータの適切な流通を実現する。

　ところで、データ提供者とデータ利用者のあいだのマッチングを行う際に、データ利用者の希望条件に合致するデータを膨大なセンシングデータのなかから抽出するのは現実的ではない。そこで本システムでは、センサネットワークに登録されているすべてのセンサ（実センサ、仮想センサ含む）について、センシングデータの仕様や提供条件などを記述したセンサ側メタデータを準備するとともに、データ利用者であるアプリケーションについても、センシングデータの要求仕様や利用条件などを記述したアプリ側メタデータを用いる。そして、メタデータ同士の比較により、データ提供者（センサ）と利用者（アプリケーション）の適切なマッチングを行う。

　図１のシステム構成例では、センサネットワークサーバ１４は、アプリ側メタデータＤＢ１４０、センサ側メタデータＤＢ１４１、マッチング部１４２、データフロー制御部１４３を有する。アプリ側メタデータＤＢ１４０は、各アプリケーションサーバ１２から受信したアプリ側メタデータを記憶する記憶部である。センサ側メタデータＤＢ１４１は、センサネットワークに登録されているすべてのセンサについてのセンサ側メタデータを記憶する記憶部である。マッチング部１４２は、アプリ側メタデータとセンサ側メタデータのマッチングを行い、アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出する機能である。データフロー制御部１４３は、マッチング部１４２のマッチング結果に基づき、センシングデータの送信を指令するデータフロー制御指令を生成し送信する機能である。これらの機能の詳細は後述する。

　（センサ側メタデータ）
　センサ側メタデータは、センサの属性情報、センサが提供可能なセンシングデータの仕様を示す情報、センシングデータの提供条件を示す情報などを記述したメタデータである。センサの属性情報は、例えば、センサを特定するＩＤ、実センサか仮想センサかを示す情報（センサクラスと呼ぶ）、センサの種別、センサのネットワークアドレス、センサの動作履歴などを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ＭＡＣアドレス、ＵＲＩ（Uniform Resource Identifier）などを利用できる。センサがセンサネットワークアダプタ１１を介してネットワークに接続している場合は、センサネットワークアダプタ１１のネットワークアドレスを設定すればよく、仮想センサの場合は、仮想センサ関数を実行し仮想的なセンシングデータを生成するコンピュータのネットワークアドレスを設定すればよい。センシングデータの仕様を示す情報は、例えば、センシング対象（つまり何をセンシングするか）、センシングする領域（例：位置、範囲など）、センシング時間（センシングデータを取得可能な時刻や時間帯）、センシングデータのデータ種別（例：画像、動画、温度など）、データフォーマット（例：ＪＰＥＧ、テキストなど）、センシング条件（例：シャッタスピード、解像度、サンプリング周期など）、データ信頼度などを含むとよい。センシングデータの提供条件を示す情報は、データ提供者が希望する取引条件を示す情報であり、例えば、データ提供者を特定するＩＤ、対価（データの提供価格）、利用範囲・利用目的（例：商用利用不可、二次利用可など）などを含むとよい。

　さらに、センサ側メタデータには、センシングデータの来歴を示す情報（「データ来歴情報」と呼ぶ）を記述することができる。データ来歴情報は、そのセンシングデータの由来、経緯、出所、起源、素性、履歴、成り立ち、責任者などを表す情報であり、センシングデータの精度や品質、信頼性、安全性などを判断する客観的な材料となり得る情報であればどのような情報でもよい。

　例えば、センサの製造者もしくは販売者を特定する情報（製造者名、製造者ＩＤ、販売者名、販売者ＩＤなど）、センサの機種もしくは型式を特定する情報（機種名、型番など）、センサの所有者もしくは管理者を特定する情報（所有者名、所有者ＩＤ、管理者名、管理者ＩＤなど）、データの提供者を特定する情報（提供者名、提供者ＩＤなど）などをデータ来歴情報として好ましく用いることができる。センシングデータの精度や特性はセンサの性能に大きく影響を受けると考えられるため、センサの製造者・販売者・機種・型式などの情報はセンシングデータの信頼性を判断する上で参考となる。すなわち、センサの製造者や販売者、あるいは、センサの機種に対し一定の信用が生じている場合には、その信用がセンシングデータの信頼性の保証となるのである。また、センシングデータの品質保証という観点（例えば、決められた仕様通りのセンシングデータが提供されるかどうか、データに改ざんなどの不正がないか、万一データに不備があった場合のフォローはあるかなど）では、データの提供側の体制、運営、管理、メンテナンスの良し悪しなども影響するため、センサの所有者ないし管理者、データ提供者などの情報もセンシングデータの信頼性を判断する上で参考となるからである。

　また、データ来歴情報には、センシングデータが所定の基準に適合していることを証明する証明情報を含めても良い。例えば、国、行政、業界団体、標準化団体などにおいてセンシングデータの精度、品質、取引の安全性、信頼性などついての基準を定め、第三者認証機関による基準適合検査に合格したセンシングデータに対してのみそのような証明情報の付加を認める、といった運用が好ましい。このとき、第三者認証機関により発行される電子証明書を証明情報としてデータ来歴情報に付加するとよい。このような証明情報を用いれば、センシングデータが精度や品質などの点で所定の基準を満たしていることを客観的に証明ないし保証することができるので、データ取引の安全と信頼を向上することができる。なお、センシングデータ自体の証明情報ではなく、センサの証明情報、データ提供者の証明情報、または、センサの所有者もしくは管理者の証明情報を用いてもよい。すなわち、センサ、データ提供者、センサの所有者もしくは管理者などが所定の基準に適合しているという信用が、そこから提供されるセンシングデータの信頼性の保証となるからである。

　データ来歴情報としていくつか例示したが、メタデータに付加する情報はそれらのうちの一部でもよいし全部でもよい。図２Ａに、センサ側メタデータＤＢ１４１に格納されているセンサ側メタデータ管理テーブルの一例を示す。図２Ａの例では、実センサＲ００１～Ｒ００２と仮想センサＶ００１のセンサ側メタデータが示されている。この例では、データ来歴情報として、センサの製造者名と機種名が用いられている。ここで、仮想センサＶ００１のメタデータのデータ来歴情報には、元センサ（元センサが仮想センサの場合はさらにその元センサ）のメタデータのデータ来歴情報が継承される。これにより、仮想センサが仮想センシングデータの生成に用いたデータの由来が明らかとなり、仮想センシングデータの信頼性を判断するための参考となる。

　（アプリ側メタデータ）
　アプリ側メタデータは、アプリケーションの属性情報、アプリケーションが要求するセンシングデータの仕様（要求仕様）を示す情報、センシングデータの利用条件を示す情報などを記述したメタデータである。アプリケーションの属性情報は、例えば、アプリケーションを特定するＩＤ、アプリケーションの種別、アプリケーションのネットワークアドレスなどを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ポート番号などを利用できる。センシングデータの要求仕様を示す情報は、例えば、センシング対象、センシングする領域、センシング時間、センシングデータのデータ種別、データフォーマット、センシング条件、データ信頼度などを含むとよい。利用条件を示す情報は、データ利用者が希望する取引条件を示す情報であり、例えば、データ利用者を特定するＩＤ、対価（データの利用価格の上限）、利用範囲・利用目的などを含むとよい。なお、特に条件の指定が無い項目については空欄（指定しない）にすればよい。

　アプリ側メタデータにも、データ来歴情報を記述することができる。データ来歴情報の内容はセンサ側メタデータに記述する情報と同じであるため、説明を割愛する。ただし、センサ側メタデータには、提供するセンシングデータについてのデータ来歴情報を記述するのに対し、アプリ側メタデータには、アプリケーションが要求するデータ来歴情報を記述する点が異なる。したがってアプリ側メタデータには、アプリケーションが許容するデータ来歴情報を複数記述することができる。

　図２Ｂに、アプリ側メタデータＤＢ１４０に格納されているアプリ側メタデータ管理テーブル（キューテーブルとも呼ぶ）の一例を示す。図２Ｂの例では、２つのアプリケーションＡ００１、Ａ００２からそれぞれ受信したアプリ側メタデータが示されている。アプリケーションＡ００１は、データ来歴情報を指定していない（つまり、どのような来歴のデータでも許容する）。アプリケーションＡ００２のアプリ側メタデータは、データ来歴として、Ａ社製の機種名ａａ１、Ａ社製の機種名ａａ２、Ｂ社製の機種名ｂｂ１のいずれかのセンサを希望する例である。

　（メタデータの登録）
　図３Ａは、データ提供者がセンサネットワークサーバ１４のセンサ側メタデータＤＢ１４１にセンサ側メタデータを新規登録する際に、データ提供者のコンピュータに表示されるメタデータ作成ＧＵＩの一例である。ただし、図３Ａは、メタデータ作成ＧＵＩのうちデータ来歴情報の設定画面のみを抜粋して示している。この例では、データ来歴情報として、センサの製造者名「Ａ社」、センサの型式「ａａ１」、データの提供者名「Ｏ社」、電子証明書の発行元「ＣＡ認証機関」、電子証明書「ａｂｃｄｅｆ」、電子証明書の有効期限「２０１５／１１／０９」が設定されている。

　図３Ｂは、データ利用者がアプリ側メタデータを新規作成する際に、データ利用者のコンピュータに表示されるメタデータ作成ＧＵＩの一例である。ただし、図３Ｂは、メタデータ作成ＧＵＩのうちデータ来歴情報の設定画面のみを抜粋して示している。センサ側メタデータの設定画面（図３Ａ）との違いは、各項目について複数の選択肢を設定したり、「指定なし」（つまり何でもよい）という設定が可能な点である。データ利用者は、各項目の選択肢を広めに設定することにより、データ提供者のデータ来歴情報とマッチする可能性を高めることができる。図３Ｂの例では、センサの製造者名として「Ａ社」と「Ｂ社」が設定され、センサの型式として「Ａ社のａａ１」と「Ｂ社のｂｂ２」と「Ｂ社のｂｂ３」が設定され、データ提供者は「指定なし」（つまり誰でもよい）が設定されている。また、電子証明書は「必須」であり、その発行元は「指定なし」（つまりいずれの発行元でもよい）に設定されている。

　以上述べたメタデータ作成ＧＵＩによりユーザの入力支援を行うことにより、メタデータのデータ来歴情報の設定が容易となり、データ提供者およびデータ利用者双方の利便性向上を図ることができる。

　（マッチングおよびデータフロー制御）
　次に、図１と図４を用いて、マッチングおよびデータフロー制御の処理について説明する。ここでは、アプリケーションサーバ１２から送信されたアプリ側メタデータをセンサネットワークサーバ１４が受信したことをトリガとして、センサネットワークサーバ１４がアプリ側メタデータとセンサ側メタデータのマッチングを行い、適切なセンサからアプリへのセンシングデータのデータフロー制御指令を発行する処理例について説明する。

　アプリケーションサーバ１２が、センサネットワークサーバ１４の所定のＡＰＩ（Application Programming Interface）を利用して、アプリ側メタデータと共にセンシングデータ要求を送信する。センサネットワークサーバ１４は、センシングデータ要求を受信すると、その要求に含まれているアプリ側メタデータをアプリ側メタデータＤＢ１４０のアプリ側メタデータ管理テーブル（図２Ｂ参照）に記録する。そして、マッチング部１４２がアプリ側メタデータ管理テーブルから処理待ちのアプリ側メタデータを一つずつ取得する（ステップＳ４０）。

　マッチング部１４２は、センサ側メタデータＤＢ１４１内のセンサ側メタデータ管理テーブル（図２Ａ参照）からセンサ側メタデータを一つ取得し（ステップＳ４１）、センサ側メタデータで規定されたセンシングデータの仕様および取引条件（提供条件）がアプリ側メタデータで規定されたセンシングデータの要求仕様および取引条件（利用条件）を満足するか否かを判定する（ステップＳ４２）。さらにマッチング部１４２は、センサ側メタデータで規定されたデータ来歴情報がアプリ側メタデータで規定されたデータ来歴情報を満足するか否かを判定する（ステップＳ４３）。ステップＳ４２とＳ４３の両方で肯定判定がなされた場合に、当該センサが候補の一つとして抽出される（ステップＳ４４）。なお、ステップＳ４２とＳ４３の判定の順番は逆でもよい。また、アプリ側メタデータにデータ来歴情報が含まれていない場合はステップＳ４３はスキップすればよい。ステップＳ４１～Ｓ４４の処理は、センサ側メタデータ管理テーブルに登録されているすべてのセンサ側メタデータについて実行される（ステップＳ４５）。

　候補として抽出されたセンサが複数存在した場合には（ステップＳ４６のＹＥＳ）、マッチング部１４２は、それら複数の候補のなかからデータ利用者にもっとも有利なセンサを選択する（ステップＳ４７）。例えば対価優先の場合は、データの価格が最も安いセンサを選択すればよいし、品質優先の場合は、データの精度や品質が最も高いセンサを選択すればよい。データ利用者にもっとも有利なセンサをどのような基準で選択するかは、アプリ側メタデータにおいて設定されていてもよい。なお、候補として抽出されたセンサが一つもなかった場合には、処理を終了をしてもよいし、データ仕様や取引条件やデータ来歴情報が最も近いセンシングデータをデータ利用者にレコメンドしてもよい。

　最後に、データフロー制御部１４３が、ステップＳ４７で選択されたセンサからアプリケーションへのセンシングデータの送信を指令するデータフロー制御指令を生成し、このデータフロー制御指令を当該センサ１０または当該センサ１０を管理するセンサネットワークアダプタ１１に対し送信する（ステップＳ４８）。すると、図１に破線矢印で示すように、データフロー制御指令に基づき、センサネットワークアダプタ１１がセンサ１０から必要なセンシングデータを取得し、そのセンシングデータをアプリケーションサーバ１２へと送信する。

　図５に、この場合のデータフロー制御指令の一例を示す。データフロー制御指令は、データフロー制御指令ＩＤ、センサを特定する情報（センサＩＤ、センサのネットワークアドレス）、アプリを特定する情報（アプリＩＤ、アプリのネットワークアドレス）、データ送信を行う時間情報などを含むとよい。

　以上述べた本実施形態の構成によれば、メタデータにデータ来歴情報が記述可能となり、データ提供者とデータ利用者のあいだのマッチングの項目の一つとしてこのデータ来歴情報を用いることができるようになる。データ来歴情報によって、例えばそのデータの由来、経過、出所などがわかれば、データ利用者にとってはそのデータの精度、品質、信頼性、安全性などを判断する際の有効な材料となる。一方、データ提供者にとっては、データ来歴情報を開示することによって、そのデータの精度、品質、信頼性、安全性などを保証し、データの商品価値を高めることができるという利点がある。したがって、データ来歴情報を記述したメタデータを用いることにより、データ流通市場において取引されるデータの精度や品質を保証し、データ取引の安全と信頼を向上することができる。

　なお、上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。例えば上記実施形態で示したデータ構造やテーブル構造は一例であり、項目を適宜追加したり入れ替えたりしてもよい。また、上記実施形態では、センサネットワークにおけるセンシングデータの流通を例示したが、本発明は、センサ以外のデバイスを含むデバイスネットワークにおけるデータの流通にも適用可能である。その場合も、システムの基本的な構成は上記実施形態のものと同様であり、上記実施形態における「センサ」を「デバイス」と読み替え、「センシングデータ」を「データ」と読み替えればよい。

　本明細書に開示された技術思想は以下のような発明として特定することもできる。
　（付記１）
　メモリと、前記メモリに接続された少なくとも１つのハードウェアプロセッサと、を有するデータフローコントローラであって、
　前記メモリは、
　　複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を含み且つ当該デバイスが提供するデータの来歴を示す情報を記述可能である、デバイス側メタデータを記憶するデバイス側メタデータ記憶部と、
　　データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を含み且つ当該アプリケーションが要求するデータの来歴を示す情報を記述可能である、アプリ側メタデータを記憶するアプリ側メタデータ記憶部と、
を有し、
　前記少なくとも１つのハードウェアプロセッサは、
　　前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行い、
　　前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出し、
　　前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行う、
ように構成されている。
　（付記２）
　データフローコントロール方法であって、
　少なくとも１つのハードウェアプロセッサにより、複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を含み且つ当該デバイスが提供するデータの来歴を示す情報を記述可能である、デバイス側メタデータを記憶するデバイス側メタデータ記憶部から、デバイス側メタデータを取得すること、
　少なくとも１つのハードウェアプロセッサにより、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を含み且つ当該アプリケーションが要求するデータの来歴を示す情報を記述可能である、アプリ側メタデータを記憶するアプリ側メタデータ記憶部から、アプリ側メタデータを取得すること、
　少なくとも１つのハードウェアプロセッサにより、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うこと、
　少なくとも１つのハードウェアプロセッサにより、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出すること、および、
　少なくとも１つのハードウェアプロセッサにより、前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行うこと、
を有する。

１０：センサ
１１：センサネットワークアダプタ
１２：アプリケーションサーバ
１４：センサネットワークサーバ
１４０：アプリ側メタデータＤＢ
１４１：センサ側メタデータＤＢ
１４２：マッチング部
１４３：データフロー制御部

Claims

　複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部と、
　データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部と、
　前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスを抽出するマッチング部と、
　前記マッチング部のマッチング結果に基づき、前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行うデータフロー制御部と、を有し、
　前記デバイス側メタデータには、デバイスが提供するデータの来歴を示す情報を記述可能であり、
　前記アプリ側メタデータには、アプリケーションが要求するデータの来歴を示す情報を記述可能であり、
　前記マッチング部は、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出する
ことを特徴とするデータフロー制御装置。
　データの来歴を示す情報は、当該データを提供するデバイスの製造者もしくは販売者を特定する情報、当該データを提供するデバイスの機種もしくは型式を特定する情報、および、当該データを提供するデバイスの所有者もしくは管理者を特定する情報、のうち少なくともいずれかを含む
ことを特徴とする請求項１に記載のデータフロー制御装置。
　データの来歴を示す情報は、当該データ、当該データを提供するデバイス、当該データの提供者、または、当該データを提供するデバイスの所有者もしくは管理者が、所定の基準に適合していることを証明する証明情報を含む
ことを特徴とする請求項１または２に記載のデータフロー制御装置。
　前記証明情報は、第三者認証機関により発行された電子証明書である
ことを特徴とする請求項３に記載のデータフロー制御装置。
　前記デバイスは、センシングデータを出力するセンサである
ことを特徴とする請求項１～３のうちいずれか１項に記載のデータフロー制御装置。
　コンピュータが、複数のデバイスのそれぞれについて、デバイスが提供するデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部から、デバイス側メタデータを取得するステップと、
　コンピュータが、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部から、アプリ側メタデータを取得するステップと、
　コンピュータが、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスを抽出するステップと、
　コンピュータが、前記マッチングの結果に基づき、前記抽出されたデバイスから出力されるデータを前記アプリケーションへ提供するデータフロー制御を行うステップと、を有し、
　前記デバイス側メタデータには、デバイスが提供するデータの来歴を示す情報を記述可能であり、
　前記アプリ側メタデータには、アプリケーションが要求するデータの来歴を示す情報を記述可能であり、
　前記マッチングを行うステップでは、前記アプリ側メタデータの中に来歴を示す情報が記述されていた場合に、前記複数のデバイスのなかから前記アプリケーションの要求する仕様と来歴の両方を少なくとも満たすデータを提供可能なデバイスを抽出する
ことを特徴とするデータフロー制御方法。
　請求項６に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。
　デバイスが提供するデータに関する情報を記述するデバイス側のメタデータのデータ構造であって、
　前記デバイスが提供するデータの仕様を示す情報と、
　前記デバイスが提供するデータの来歴を示す情報と、を含み、
　前記デバイス側メタデータは、データを利用するアプリケーションが要求する仕様および来歴の両方を満たすデータを提供可能なデバイスを複数のデバイスのなかから抽出するマッチングに利用される
ことを特徴とするメタデータのデータ構造。
　アプリケーションが利用を希望するデータに関する情報を記述するアプリ側のメタデータのデータ構造であって、
　前記アプリケーションが要求するデータの仕様を示す情報と、
　前記アプリケーションが要求するデータの来歴を示す情報と、を含み、
　前記アプリ側メタデータは、前記アプリケーションが要求する仕様および来歴の両方を満たすデータを提供可能なデバイスを複数のデバイスのなかから抽出するマッチングに利用される
ことを特徴とするメタデータのデータ構造。
　データの来歴を示す情報は、当該データを提供するデバイスの製造者もしくは販売者を特定する情報、当該データを提供するデバイスの機種もしくは型式を特定する情報、および、当該データを提供するデバイスの所有者もしくは管理者を特定する情報、のうち少なくともいずれかを含む
ことを特徴とする請求項８または９に記載のメタデータのデータ構造。
　データの来歴を示す情報は、当該データ、当該データを提供するデバイス、当該データの提供者、または、当該データを提供するデバイスの所有者もしくは管理者が、所定の基準に適合していることを証明する証明情報を含む
ことを特徴とする請求項８～１０のうちいずれか１項に記載のメタデータのデータ構造。
　前記証明情報は、第三者認証機関により発行された電子証明書である
ことを特徴とする請求項１１に記載のメタデータのデータ構造。