(57)【特許請求の範囲】
【請求項１】
複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す項目を含むデバイス側メタデータを取得するデバイス側メタデータ取得手段と、
前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示す項目を含むアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、
前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、
前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、
を有し、
前記デバイス側メタデータおよびアプリ側メタデータが有するマッチング対象の項目には、変更可否を表すフラグがそれぞれ関連付けられており、
前記マッチング手段は、前記デバイス側メタデータおよびアプリ側メタデータが有する前記項目のうち、前記マッチング対象の項目が一致したか否かに基づいて前記組み合わせを抽出し、不一致が発生した項目があり、当該不一致が発生した項目が変更可である場合に、当該不一致が発生した項目の変更可否を、前記デバイスを管理するユーザおよび前記アプリケーションを管理するユーザに対して問い合わせ、前記デバイスを管理するユーザおよび前記アプリケーションを管理するユーザから取得した回答に基づいて前記不一致が発生した項目を変更する
ことを特徴とするデータフロー制御装置。
【請求項２】
前記マッチング手段は、不一致が発生した項目の数が所定の数より多い場合に、当該項目の変更を行わない
ことを特徴とする、請求項１に記載のデータフロー制御装置。
【請求項３】
前記デバイスは、センシングデータを出力するセンサである
ことを特徴とする、請求項１又は２に記載のデータフロー制御装置。
【請求項４】
コンピュータが、
複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す項目を含むデバイス側メタデータを取得するデバイス側メタデータ取得ステップと、
前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示す項目を含むアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶ステップと、
前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチングステップと、
前記マッチングステップで抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御ステップと、
を実行し、
前記デバイス側メタデータおよびアプリ側メタデータが有するマッチング対象の項目には、変更可否を表すフラグがそれぞれ関連付けられており、
前記マッチングステップでは、前記デバイス側メタデータおよびアプリ側メタデータが有する前記項目のうち、前記マッチング対象の項目が一致したか否かに基づいて前記組み合わせを抽出し、不一致が発生した項目があり、当該不一致が発生した項目が変更可である場合に、当該不一致が発生した項目の変更可否を、前記デバイスを管理するユーザおよび前記アプリケーションを管理するユーザに対して問い合わせ、前記デバイスを管理するユーザおよび前記アプリケーションを管理するユーザから取得した回答に基づいて前記不一致が発生した項目を変更する
ことを特徴とするデータフロー制御方法。
【請求項５】
請求項４に記載のデータフロー制御方法の各ステップをコンピュータに実行させること
を特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センサなどのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供するデータフローを制御するための技術に関する。
【背景技術】
【０００２】
現在、Ｍ２Ｍクラウドと呼ばれるＩＴ環境が注目を集めている。Ｍ２Ｍ（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ）とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。Ｍ２Ｍを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。
【０００３】
このようなＭ２Ｍの技術をクラウドコンピューティング環境上で実現したものはＭ２Ｍクラウドと呼ばれる。これは、Ｍ２Ｍに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。
【０００４】
また、特許文献１に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス（以下、単に「センサ」とも呼ぶ）を様々な場所、移動体、産業設備などに設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。
【０００５】
通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない（センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない）ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。
【０００６】
また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。ＩｏＴから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−３００５７１号公報
【特許文献２】特許第５４４５７２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
出願人らはさらに、センサネットワークにおいて、センシングデータなどの情報資源を適切に流通させるための技術について鋭意検討している。例えば、センサに関する情報が記述されたデータと、センシングデータを利用するアプリケーションに関する情報が記述
されたデータを適切にマッチングさせることで、センシングデータを提供したいユーザと、センシングデータを利用したいユーザとを結びつけることができる（特許文献２参照）。
これにより、例えばセンサの所有者は、データ利用者に対してセンサの一時利用を許可したりセンシングデータを提供したりすることで対価を得られる。また利用者にとっては、センサを設置する投資が不要なため安価に必要なデータを得ることができるというメリットがある。
【０００９】
特許文献２に記載の発明では、センサに対応するメタデータと、当該センシングデータを利用するアプリケーションに対応するメタデータを用いてマッチングを行い、センサとアプリケーションのペアを生成している。しかし、各メタデータには、センサ自体の属性情報、センシング対象の属性情報、センシング動作の属性情報などが数多く含まれており、これらが完全に一致しないとペアが成立しない。すなわち、登録されているメタデータの数によっては、センサとアプリケーションが結びつかないという課題があった。
この課題を解決するためには、ペアの成立を妨げている項目がある場合に、当該項目を積極的に変更させる必要がある。
【００１０】
なお、ここまでセンサネットワークを例に挙げて説明をしたが、センサ以外の装置が出力（提供）するデータを流通させるネットワークにおいても、全く同様の課題が発生し得る。センサ以外の装置としては、例えば、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなど、何らかのデータを出力する装置であればどのような物も該当し得る。本明細書では、これらの装置（センサも含む）を包含する概念として「デバイス」という用語を用い、このようなデバイスが出力（提供）するデータを流通させるネットワークを「デバイスネットワーク」と呼ぶ。デバイスネットワークには、上に例示した様々な種類のデバイスが混在して接続されることもあり得る。
【００１１】
本発明は上記実情に鑑みなされたものであり、データ提供者とデータ利用者とをマッチングさせるデバイスネットワークにおいて、ペアの成立率を向上させることを目的とする。
【課題を解決するための手段】
【００１２】
本発明に係るデータフロー制御装置は、メタデータをマッチングさせた結果、条件が一致しない項目が発生した場合に、当該項目を調整する手段を設けたことを特徴とする。
【００１３】
具体的には、本発明に係るデータフロー制御装置は、
複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す項目を含むデバイス側メタデータを取得するデバイス側メタデータ取得手段と、前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示す項目を含むアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、を有し、前記マッチング手段は、前記デバイス側メタデータおよびアプリ側メタデータが有する前記項目のうち、マッチング対象の項目が一致したか否かに基づいて前記組み合わせを抽出し、不一致が発生した項目がある場合に、当該不一致が発生した項目の変更可否を表す情報を取得し、当該情報に基づいて前記不一致が発生した項目を変更することを特徴とする。
【００１４】
変更可否を表す情報は、例えば、項目ごとにあらかじめ設定されたデータであってもよいし、メタデータを登録したユーザに問い合わせを行い、当該ユーザの指示に基づいて生成されてもよい。
かかる構成によると、マッチングにおいて項目間に不一致が発生した場合に、当該不一致が発生した項目の内容を個別に修正することができ、デバイスとアプリケーションのペアが成立する確率を向上させることができる。
【００１５】
また、前記マッチング手段は、前記不一致が発生した項目の変更可否を、前記デバイスまたはアプリケーションを管理するユーザに対して問い合わせ、ユーザから取得した回答に基づいて当該項目を変更することを特徴としてもよい。
【００１６】
問い合わせは、例えば電子メールやメッセージングサービスを介して行ってもよい。かかる構成によると、項目を修正する機会をユーザに与えることができ、ユーザは、デバイスとアプリケーションのペアを成立させるために条件を変更すべきか、見送るべきかを状況に応じて判断することができる。
【００１７】
また、前記デバイス側メタデータおよびアプリ側メタデータが有する前記マッチング対象の項目には、変更可否を表すフラグがそれぞれ関連付けられており、前記マッチング手段は、前記不一致が発生した項目が変更可である場合に、前記ユーザに対して問い合わせを行うことを特徴としてもよい。
【００１８】
例えば、マッチングの状況によっては項目の内容を変更してもよいとユーザが考える場合、当該項目に「変更可」を表すフラグを付加し、それ以外の項目については「変更不可」を表すフラグを付加する。かかる構成によると、無用な問い合わせを減らすことができ、ユーザの利便性が向上する。
【００１９】
また、前記デバイス側メタデータおよびアプリ側メタデータが有する前記マッチング対象の項目には、一つ以上の変更候補がそれぞれ関連付けられており、前記マッチング手段は、項目間に不一致が発生した場合に、前記変更候補に基づいて当該項目を変更することを特徴としてもよい。
【００２０】
このように、メタデータが有する項目に変更候補を持たせ、自動的に項目を修正してもよい。なお、変更候補は複数個であってもよい。かかる構成によると、ユーザに対して問い合わせを行う必要がなくなるため、デバイスとアプリケーションのペアを迅速に成立させることができる。
【００２１】
また、前記マッチング手段は、不一致が発生した項目の数が所定の数より多い場合に、当該項目の変更を行わないことを特徴としてもよい。
【００２２】
不一致が発生した項目が多い場合、調整に時間がかかるほか、最終的にユーザが希望する条件から遠のいてしまう可能性が高くなる。そこで、不一致が発生した項目の数によっては、調整そのものを行わない構成としてもよい。
【００２３】
また、前記デバイスは、センシングデータを出力するセンサであることを特徴としてもよい。本発明に係るデータフロー制御装置は、センシングデータを提供するデータ提供者と、センシングデータを利用するデータ利用者とで構成されるセンサネットワークに好適に適用することができる。
【００２４】
なお、本発明は、上記手段の少なくとも一部を含むデータフロー制御装置として特定す
ることができる。また、本発明は、上記データフロー制御装置を有するデバイスネットワークシステムとして特定することもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法として特定することもできる。また、本発明は、コンピュータに上記方法を実行させるプログラムとして特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【００２５】
本発明における「デバイス」は、何らかのデータを出力（提供）するあらゆる装置を意味し、センサ、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなどが例示できる。中でも本発明は、センサから出力されるセンシングデータの流通を行うセンサネットワークに好適である。
【発明の効果】
【００２６】
本発明によれば、データ提供者とデータ利用者とをマッチングさせるデバイスネットワークにおいて、ペアの成立率を向上させることができる。
【図面の簡単な説明】
【００２７】
【図１】第一の実施形態に係るセンサネットワークシステムの構成図である。
【図２】第一の実施形態における、センサ側／アプリ側メタデータの例である。
【図３】センサ側メタデータを登録する画面の例である。
【図４】マッチング処理のフローチャート図である。
【図５】項目修正処理のフローチャート図である。
【図６】メタデータ同士のマッチングを説明する図である。
【図７】変更依頼メールの例である。
【図８】第二の実施形態における、センサ側／アプリ側メタデータの例である。
【図９】第二の実施形態における、項目修正処理の処理フローチャート図である。
【発明を実施するための形態】
【００２８】
（第一の実施形態）
以下、本発明の好ましい実施形態について図面を参照しながら説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。
【００２９】
以下に述べる実施形態では、本発明を、Ｍ２Ｍクラウドを用いたセンサネットワークシステムに適用した例について説明する。かかる仕組みが実現すれば、センサネットワーク上に存在する多数のセンサから得られる多種多様な情報のなかから、所望の情報を誰もがどこからでも容易に取得することができるようになり、センサ（リソース）の有効利用、並びに、データ提供者からデータ利用者へのセンシングデータの流通が促進されると期待される。このシステムは、例えば、交通状況のセンシングデータに基づく交通制御システム、環境のセンシングデータに基づく気象予測システム、ビッグデータを利用した各種分析システム、センサメーカによる販売済みセンサのメンテナンスサービスなど、様々な用途への応用展開が可能である。
【００３０】
＜システムの全体構成＞
図１を参照して、第一の実施形態に係るセンサネットワークシステムの全体的な構成を説明する。このセンサネットワークシステムは、データ提供者からデータ利用者へのセンシングデータの流通を制御するためのシステムであり、複数のセンサ２１およびセンサ２１を管理する装置であるセンサネットワークアダプタ２２からなるセンサ装置２０と、センシングデータを利用してサービスを提供するアプリケーションを有するアプリケーションサーバ３０と、センシングデータの提供者（以下、データ提供者）と利用者（以下、デ
ータ利用者）の仲介を担うデータフロー制御装置としてのセンサネットワークサーバ１０とを有している。なお、本例では、センサ装置２０およびアプリケーションサーバ３０を一つずつ例示しているが、センサ装置２０およびアプリケーションサーバ３０は複数あってもよい。
【００３１】
各装置の間は、インターネット等の広域ネットワーク又はＬＡＮによって通信可能に接続されている。なお、ネットワークは単一のネットワークとは限らず、様々な通信方式やトポロジーをもつ複数のネットワークを相互に接続した概念的なものと考えてもよい。要するに、センシングデータの送受信や、センシングデータの流通に関わるメタデータ及びデータフロー制御指令等のデータの送受信が実現できれば、どのような形態のネットワークを利用してもよい。
【００３２】
＜＜センサ＞＞
センサ２１は、センシング対象の物理量やその変化を検出し、センシングデータとして出力するデバイスである。
センサには、例えば、画像センサ（監視カメラなど）、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射線センサ、ガスセンサ、加速度センサ、ジャイロスコープ、ＧＰＳセンサなどが該当する。また、携帯電話、スマートフォン、タブレット端末、モバイルＰＣ、ドローンなどの機器は様々な種類のセンサを搭載しているため、これらの機器をセンサとして取り扱うこともできる。本実施形態のセンサネットワークシステムには、ここで例示したセンサをはじめとして、いかなる種類のセンサを接続することができる。また、工場のＦＡや生産管理、都市交通制御、気象等の環境計測、ヘルスケア、防犯など、世の中のあらゆる場所に様々な用途・目的で多数のセンサが既に設置されているが、これらのセンサを本システムに接続することも可能である。なお、センサネットワークシステムは、一種類のセンサのみで構成してもよいし、複数の種類のセンサを混在させてもよい。
【００３３】
＜＜センサネットワークアダプタ＞＞
センサネットワークアダプタ２２は、１つ又は複数のセンサ２１と有線又は無線により通信可能に接続され、センサ２１の管理、センサ２１からのセンシングデータの取得、センサネットワークシステムやアプリケーションへのセンシングデータの送信などを行う装置である。センサネットワークアダプタ２２は、センシングデータに所定の処理（例えばノイズ除去などの信号処理、平均処理などの演算、サンプリング、データ圧縮、タイムスタンプなど）を施す機能を有していてもよい。センサネットワークアダプタ２２は、外部装置との通信機能を有しており、アプリケーションサーバ３０、センサネットワークサーバ１０等とネットワークを介して通信が可能である。
【００３４】
スマートフォン、タブレット端末、モバイルＰＣ、ドローン、ウェアラブル端末などの機器は、画像センサ、ＧＰＳセンサ、加速度センサ、マイクなどのセンサを内蔵し、各センサで得られたデータを加工し出力する機能やネットワーク通信機能を有している。したがって、これらの機器は、センサ２１とセンサネットワークアダプタ２２とが物理的に一体となったデバイスの例である。なお、センサ２１が通信機能を内蔵している場合、単体で（つまりセンサネットワークアダプタ２２を介さずに）センサネットワークシステムに接続可能である。
【００３５】
＜＜アプリケーションサーバ＞＞
アプリケーションサーバ３０は、センシングデータを利用してサービスを提供する各種アプリケーションプログラムがインストールされたサーバ装置である。アプリケーションサーバ３０は、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。アプリケーショ
ンサーバ３０は、センシングデータの利用者が設置するものであり、その用途・目的に応じて様々なアプリケーションが想定される。
【００３６】
アプリケーションの例としては、例えば、道路に設置されたセンサや、道路上を走行する車両に搭載された車載端末又は運転者のスマートフォンなどから、各地点の交通状況を収集して渋滞マップを生成し、渋滞情報を利用する事業者等に提供するアプリケーションが考えられる。他にも、スマートフォンや車載カメラなどで走行中に撮影された画像データを収集し、各地点の状況を知りたい利用者に提供する映像配信アプリケーション、渋滞情報等を元に車両の走行ルートを検索する経路探索アプリケーション、特定の場所に設置されたカメラの映像から通行者の属性（性別、年齢層など）の統計データを推定し、各種調査用のデータとして提供するアプリケーション、センサメーカが販売済みの自社センサをオンラインメンテナンスするアプリケーションなど、様々なものが考えられる。
【００３７】
＜＜センサネットワークサーバ＞＞
センサネットワークサーバ１０は、センシングデータの提供者と利用者のあいだのマッチング、提供者から利用者へのセンシングデータのデータフロー制御などを担うサーバ装置であり、本発明に係るデータフロー制御装置の一具体例である。センサネットワークサーバ１０も、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。後述するセンサネットワークサーバ１０の各種機能は、ＣＰＵが必要なプログラムを実行することにより実現される。
【００３８】
センサネットワークシステムは、多数の（又は多種多様な）センサをネットワーク化し、センシングデータの収集や利用を可能とするものであるが、本実施形態では、データ提供者（センサ２１）がデータ利用者（アプリケーションサーバ３０）に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、データ提供者にとっては収益の機会、利用者にとっては安価なデータ取得というメリットが得られる。センサネットワークサーバ１０は、このようなセンシングデータの取引の仲介を行うサーバ装置であり、データ提供者とデータ利用者のあいだのマッチングを行い、センシングデータの適切な流通を実現する。
【００３９】
ところで、データ提供者とデータ利用者のあいだのマッチングを行う際に、データ利用者の希望条件に合致するデータを膨大なセンシングデータのなかから抽出するのは現実的ではない。そこで本システムでは、センサネットワークに登録されているすべてのセンサについて、センシングデータの仕様や提供条件などを記述したメタデータ（センサ側メタデータ）を準備するとともに、データ利用者であるアプリケーションについても、センシングデータの要求仕様や利用条件などを記述したメタデータ（以下、アプリ側メタデータ）を用いる。そして、メタデータ同士を比較することで、データ提供者（センサ）と利用者（アプリケーション）の適切なマッチングを行う。
【００４０】
図１のシステム構成例では、センサネットワークサーバ１０は、記憶部１１、マッチング部１２、調整部１３、入出力部１４、データフロー制御部１５を有する。
記憶部１１は、センサネットワークに登録されているすべてのアプリケーションに対応するアプリ側メタデータと、センサネットワークに登録されているすべてのセンサに対応するセンサ側メタデータを記憶するデータベースである。
【００４１】
マッチング部１２は、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータのマッチングを行い、アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出し、センサとアプリケーションのペアを生成する（ペアリングを行う）手段である。
また、調整部１３は、マッチング部が行ったマッチング処理の結果、ペアの成立を妨げている項目が発生した場合に、当該項目の内容を調整する（すなわち、変更の可否を判定し、判定結果に基づいて変更を行う）手段である。
マッチング部１２および調整部１３の詳細については後述する。
【００４２】
入出力部１４は、登録対象のセンサ側メタデータまたはアプリ側メタデータを取得するためのインタフェース手段である。入出力部１４は、有線または無線接続で外部のコンピュータと通信を行うハードウェアである。なお、入出力部１４は、ディスプレイデバイスとヒューマンインタフェースデバイス（キーボードやマウス等）を含んでいてもよい。この場合、外部のコンピュータと通信を行う必要はない。いずれの場合も、入出力部１４を介して、ユーザに情報を提供し、また、ユーザから情報を取得することができる。
データフロー制御部１５は、マッチング部１２が出力した情報に基づき、センシングデータの送信を指令するデータフロー制御指令を生成し送信する機能である。これらの機能の詳細は後述する。
【００４３】
＜センサ側メタデータ＞
次に、記憶部１１に記憶されるメタデータの詳細について説明する。
図２（Ａ）は、記憶部１１にテーブル形式で格納されるセンサ側メタデータの例である。
センサ側メタデータは、センサの属性情報、センサが提供可能なセンシングデータの仕様を示す情報や、センシングデータの提供条件を示す情報などを記述したメタデータである。センサの属性情報は、例えば、センサを特定するＩＤ、センサの種別、センサのネットワークアドレス、センサの動作履歴などを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ＭＡＣアドレス、ＵＲＩ（Uniform Resource Identifier）などを利
用できる。センサがセンサネットワークアダプタ２２を介してネットワークに接続している場合は、センサネットワークアダプタ２２のネットワークアドレスを設定すればよい。
センシングデータの仕様を示す情報は、例えば、センシング対象（つまり何をセンシングするか）、センシングする場所や領域（例：位置、範囲など）、センシング時間（センシングデータを取得可能な時刻や時間帯）、センシングデータのデータ種別（例：画像、動画、温度など）、データフォーマット（例：ＪＰＥＧ、テキストなど）、センシング条件（例：シャッタスピード、解像度、サンプリング周期など）、データ信頼度などを含ませることができる。
センシングデータの提供条件を示す情報は、データ提供者が希望する取引条件を示す情報であり、例えば、データ提供者を特定するＩＤ、対価（データの提供価格）、利用範囲・利用目的（例：商用利用不可、二次利用可など）などを含ませることができる。
【００４４】
さらに、センサ側メタデータには、センシングデータの来歴を示す情報（「データ来歴情報」と呼ぶ）を記述することができる。データ来歴情報は、そのセンシングデータの由来、経緯、出所、起源、素性、履歴、成り立ち、責任者などを表す情報であり、センシングデータの精度や品質、信頼性、安全性などを判断する客観的な材料となり得る情報であればどのような情報でもよい。
【００４５】
＜アプリ側メタデータ＞
図２（Ｂ）は、記憶部１１にテーブル形式で格納されるアプリ側メタデータの例である。
アプリ側メタデータは、アプリケーションの属性情報、アプリケーションが要求するセンシングデータの仕様（要求仕様）を示す情報、センシングデータの利用条件を示す情報などを記述したメタデータである。
アプリケーションの属性情報は、例えば、アプリケーションを特定するＩＤ、アプリケーションの種別、アプリケーションのネットワークアドレスなどを含むとよい。ネットワ
ークアドレスには、例えばＩＰアドレス、ポート番号などを利用できる。センシングデータの要求仕様を示す情報は、例えば、センシング対象、センシングする領域、センシング時間、センシングデータのデータ種別、データフォーマット、センシング条件、データ信頼度などを含ませることができる。
利用条件を示す情報は、データ利用者が希望する取引条件を示す情報であり、例えば、データ利用者を特定するＩＤ、対価（データの利用価格の上限）、利用範囲・利用目的などを含ませることができる。
【００４６】
アプリ側メタデータにも、データ来歴情報を記述することができる。データ来歴情報の内容はセンサ側メタデータに記述する情報と同じであるため、説明を割愛する。ただし、センサ側メタデータには、提供するセンシングデータについてのデータ来歴情報を記述するのに対し、アプリ側メタデータには、アプリケーションが要求するデータ来歴情報を記述する点が異なる。したがってアプリ側メタデータには、アプリケーションが許容するデータ来歴情報を複数記述することができる。
【００４７】
本実施形態では、センサ側メタデータおよびアプリ側メタデータの双方が有する各項目に、変更可否を表すフィールド（以下、変更可否フラグ）が付加されている。図示した例では、センサＩＤ「Ｖ００１」のセンサにおいて、「５０円以上」という希望対価が設定されており、当該項目について「変更可能」である旨が定義されている。変更可否フラグの詳細については後述する。
【００４８】
＜メタデータの登録＞
データ提供者あるいはデータ利用者が、データの提供または利用を希望する際は、自己が所有するコンピュータをセンサネットワークサーバ１０に接続し、メタデータの内容を入力する。具体的には、ネットワークを介して入出力部１４にアクセスし、入出力部１４が生成した画面に従って情報の入力を行う。これにより、センサ側メタデータあるいはアプリ側メタデータが生成され、記憶部１１に記憶される。本例では、データ提供者がセンサ側メタデータを生成する例を挙げて説明を行うが、データ利用者がアプリ側メタデータを生成する場合も同様である。
【００４９】
図３は、データ提供者がセンサ側メタデータを新規登録する際に表示される画面の例である。当該画面は、入出力部１４が生成し、入出力部１４に接続されたデータ提供者のコンピュータに出力される。
【００５０】
本実施形態では、メタデータの内容を入力する際に、項目ごとに変更可否を設定する。「変更可」とは、マッチングにおいて不一致が発生した場合に、当該項目の内容変更を許可する旨を表している。すなわち、項目の内容に検討の余地がある場合、当該チェックボックスをオンにする。例えば、図３の例では、「１００円以上」という対価を設定しているが、対価で折り合わない場合、１００円未満にすることを検討してもよい場合は、「変更可」のチェックボックスをオンにする。
【００５１】
図３に示した画面で、情報を入力したユーザが「登録」を押下すると、センサ側メタデータが記憶部１１に登録される。またこの際、「変更可」チェックボックスの内容に応じて、各項目の変更可否フラグに値（「可」または「不可」）が設定される。
【００５２】
＜マッチング処理＞
マッチングとは、マッチング部１２が行う処理であって、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータ同士を比較し、条件が合致するもの同士を抽出してペアリングしたうえで、該当するセンサからアプリケーションへのセンシングデータのデータフロー制御指令を発行する処理である。マッチングは、新規にメタデータを登録した
場合に実行される。
図４は、センサ側メタデータを登録した際に実行されるマッチングの処理フローチャート図である。
【００５３】
まず、記憶部１１が有するセンサ側メタデータテーブルから、処理待ちのセンサ側メタデータを一つずつ取得する（ステップＳ１１）。
次に、記憶部１１が有するアプリ側メタデータテーブルから、アプリ側メタデータを一つ取得する（ステップＳ１２）。
【００５４】
次に、アプリ側メタデータで規定されたセンシングデータの仕様および取引条件（提供条件）が、センサ側メタデータで規定されたセンシングデータの要求仕様および取引条件（利用条件）を満足するか否かを判定する。ここで、センサ側メタデータおよびアプリ側メタデータが有する比較対象項目が一致した場合、ペア成立となり、一つでも一致しなかった場合、ペア不成立となる（ステップＳ１３）。
なお、条件が一致するか否かは、必ずしも文言上の完全一致によって判断する必要はない。例えば、センシング場所が、センサ側において「京都市内」であって、アプリ側において「京都駅前」であった場合、両者は一致するものと判定される。
【００５５】
なお、ステップＳ１３で一致しない項目があり、ペアが成立しなかった場合は、当該項目の修正を行う処理を試行する。当該処理については、図５を参照しながら後ほど説明する。
【００５６】
ステップＳ１３でペアが成立した場合、ステップＳ１２で取得したアプリ側メタデータが、最終的なペア候補の一つとして抽出される（ステップＳ１４）。
ステップＳ１２〜Ｓ１４の処理は、アプリ側メタデータテーブルに登録されているすべてのアプリ側メタデータについて実行される（ステップＳ１５）。
【００５７】
次に、ステップＳ１６で、候補として抽出されたアプリ側メタデータの数を判定する。
候補として抽出されたアプリ側メタデータが複数存在する場合、マッチング部１２は、それら複数の候補のなかからデータ提供者にとって最も有利なものを選択する（ステップＳ１７）。例えば対価優先の場合は、データの価格が最も高いものを選択すればよい。データ提供者に最も有利なアプリケーションをどのような基準で選択するかは、適宜設定することができる。
なお、候補として抽出されたアプリ側メタデータが一つもなかった場合は、処理を終了してもよいし、データ仕様や取引条件、データ来歴情報が最も近いものをレコメンドしてもよい。また、所定の時間が経過後、再度図４に示した処理を実行するようにしてもよい。
【００５８】
最後に、データフロー制御部１５が、対象のセンサに対して、センシングデータの送信を指令するデータフロー制御指令を生成し、当該データフロー制御指令を、当該センサ２１（または当該センサ２１を管理するセンサネットワークアダプタ２２）に対し送信する（ステップＳ１８）。
そして、図１に示したように、センサネットワークアダプタ２２が、データフロー制御指令に基づいてセンサ２１から必要なセンシングデータを取得し、対応するアプリケーションサーバ３０へと送信する。
【００５９】
なお、データフロー制御指令は、データフロー制御指令ＩＤ、センサを特定する情報（センサＩＤ、センサのネットワークアドレス）、アプリを特定する情報（アプリＩＤ、アプリのネットワークアドレス）、データ送信を行う時間情報などを含んだデータであるが、これ以外の情報を含んでいてもよい。
【００６０】
以上に説明したように、センサとアプリケーションのペアを成立させるためには、センサ側メタデータが有する比較対象項目と、アプリ側メタデータが有する比較対象項目が完全にマッチする必要がある。すなわち、一つでも一致しない項目があった場合、ペアは成立せず、データ提供者、データ利用者の双方にとって機会損失となってしまう場合がある。そこで、本実施形態では、メタデータが有する比較対象項目に、変更可否を表すフラグを付加し、一部の項目が一致しなかった場合に、センサネットワークサーバ１０が、当該フィールドに設定された情報に基づいて項目の調整を行う。
【００６１】
＜項目の調整＞
本実施形態では、ステップＳ１３にて項目が完全に一致しなかった場合に、調整部１３が処理を引き継ぎ、一致しなかった項目を調整する処理を実施する。図５は、調整部１３が行う処理を説明したフローチャートである。
【００６２】
ステップＳ１３で不一致が発生した場合、ステップＳ２１で、不一致が発生した項目の数が所定の数（例えば３個）以下であるかを判定する。ここで、不一致が発生した項目の数が所定の数より少ない場合、処理はステップＳ２２へ遷移する。一方、不一致が発生した項目の数が所定の数を上回っている場合、調整は困難であると判断し、ペア不成立とする。なお、所定の数は一例であり、いくつであってもよい。
【００６３】
次に、ステップＳ２２で、センサ側メタデータまたはアプリ側メタデータのいずれかにおいて、不一致となった項目の変更可否フラグが全て「変更可」であるか否かを判定する。この結果、肯定判定であった場合、処理はステップＳ２３へ遷移し、否定判定であった場合、ペア不成立とする。
【００６４】
例えば、図２において、センサＩＤ「Ｒ００２」と、アプリＩＤ「Ａ００１」をマッチングさせる場合を考える。本例では、センシング場所、センシング時間、データ種別、利用範囲、対価、データ来歴の６項目が比較対象項目であるため、図６に示したように、対価のみが一致しないことになる。
一方で、アプリ側メタデータの項目「対価」が有する変更可否フラグには「変更可」が設定されているため、ステップＳ２２は肯定判定となる。
【００６５】
ステップＳ２３では、ペアを成立させるため、「変更可」が設定された項目を変更してもよいか否かをユーザに問い合わせる。問い合わせは、典型的には電子メールで行うが、これ以外の手段を用いてもよい。例えば、図７に示したような文面を電子メールやメッセージングサービスを介して送信し、ユーザからの回答をＷｅｂサーバ経由で取得するようにしてもよい。
なお、ここでは修正すべき項目が一つのみである場合を例示したが、修正すべき項目が複数存在する場合、変更内容を全てユーザに提示し、全項目について変更を承認するか否かを問い合わせる。
【００６６】
次に、ステップＳ２４で、ユーザからの回答を取得し、変更の実施可否を判定する。例えば、「５０円以下」という対価を「１００円以下」に変更することに対するユーザの同意が得られた場合、当該項目を「１００円以下」に変更する。同意が得られない場合（所定の時間内に回答が無かった場合を含む）は、ペアが成立しなかったものとする。
これにより、比較対象項目が一致するようになり、結果、ペアが成立する。
【００６７】
以上説明したように、本実施形態に係るセンサネットワークサーバは、メタデータ同士のマッチングを行った結果、一致しない項目が発生した場合、当該項目の変更可否をユーザに確認し、得られた回答に基づいて、ペアが成立するように自動的に項目を修正する。
これにより、ペアの成立率を向上させることができる。
【００６８】
なお、本実施形態では、データ利用者側に問い合わせを行う例を挙げたが、変更可の項目がセンサ側のみにあった場合、データ提供者側に問い合わせを行ってもよい。
また、不一致が発生した項目について、センサ側メタデータとアプリ側メタデータの双方が変更可であった場合、どちらに問い合わせを行ってもよい。例えば、後からメタデータを登録した側に問い合わせを行ってもよいし、先にメタデータを登録した側に問い合わせを行ってもよい。
【００６９】
また、複数の項目において不一致が発生した場合、一部をセンサ側、残りをアプリ側に修正させるようにしてもよい。
また、センサ側メタデータとアプリ側メタデータの双方を修正する必要がある場合、データ提供者とデータ利用者の双方に問い合わせを行ってもよい。この場合、相手の承認待ちである旨を互いのユーザに通知するようにしてもよい。また、どちらか片方の承認が得られなかった場合、他方の承認をキャンセルするようにしてもよい。
【００７０】
（第二の実施形態）
第二の実施形態は、項目を変更する場合の修正候補をあらかじめメタデータに持たせておき、ユーザへの問い合わせを行うことなく自動で修正する実施形態である。
【００７１】
第二の実施形態では、図８に示したように、メタデータが有する各項目に、複数の条件を設定することができる。例えば、アプリＩＤ「Ａ００１」において、対価として、「５０円以下」「７５円以下」「１００円以下」という三つの条件が設定されている。各条件はそれぞれ第一希望、第二希望、第三希望を表しており、マッチングにおいては通常、第一希望が用いられる。
【００７２】
図９は、第二の実施形態における項目修正処理のフローチャートである。第一の実施形態と同様のステップについては点線で図示し、説明を省略する。
第二の実施形態では、項目間に不一致が発生した場合、ステップＳ２５で、条件の再設定が可能な項目があるか否かを判定する。例えば、第一希望でマッチングを行った結果、不一致が発生した場合、第二希望が設定されているかを判定し、第二希望を用いて当該項目を設定し直す（ステップＳ２６）。また、第二希望でマッチングを行った結果、不一致が発生した場合、第三希望が設定可能か試行する。なお、本例では第三希望まで例示するが、数に制限は無い。再設定後は、ステップＳ１３を再度実行し、ペアリングを試行する。
【００７３】
以上説明したように、第二の実施形態によると、通常のマッチングにおいては、より好ましい条件を用い、項目を修正することでペアの成立が見込める場合、条件を緩くしながらマッチングの再試行を自動で行うことができる。すなわち、ユーザへの問い合わせを行うことなく、迅速にペアを成立させることができる。
【００７４】
なお、ステップＳ２５で条件の再設定が不可能になった場合、図９の通りペア不成立と判断してもよいが、第一の実施形態のように、ユーザに対して問い合わせを送信し、ペアを成立させるための条件が受け入れ可能であるか、確認を行うようにしてもよい。
【００７５】
また、第二の実施形態では、アプリ側メタデータを変更する例を挙げたが、変更可の項目がセンサ側のみにあった場合、センサ側メタデータを変更してもよい。
また、不一致が発生した項目について、センサ側メタデータとアプリ側メタデータの双方が変更可であった場合、どちらを変更してもよい。例えば、後から登録されたメタデータを変更してもよい。
また、複数の項目において不一致が発生した場合、一部をセンサ側、残りをアプリ側で変更させるようにしてもよい。
また、複数の項目が一致せず、センサ側メタデータとアプリ側メタデータの双方を変更する必要がある場合、双方を変更してもよい。
【００７６】
（変形例）
なお、上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。例えば、上記実施形態で示したデータ構造やテーブル構造は一例であり、項目を適宜追加したり入れ替えたりしてもよい。
【００７７】
また、実施形態の説明では、ステップＳ１７において、データ提供者にとっての有利さを基準として相手先メタデータの候補を選択したが、当該方法は一例であり、これ以外の条件に基づいて候補を選択してもよい。
【００７８】
また、実施形態の説明では、センサ側メタデータが新規に登録されたことをトリガとして図４に示したマッチング処理を行う例を挙げたが、マッチング処理は、アプリ側メタデータが新規に登録されたことをトリガとして実行してもよい。この場合、センサとアプリ、データ提供者とデータ利用者をそれぞれ読み替えればよい。また、実施形態の説明では、メタデータを登録したタイミングでマッチング処理を実行するものとしたが、マッチング処理は周期的に実行されてもよい。
【００７９】
また、ペアが成立したセンサ側メタデータおよびアプリ側メタデータは、記憶部１１から削除してもよいし、契約が成立した旨のフラグを付与し、契約が解除されるまでマッチング対象から外すようにしてもよい。
【００８０】
また、上記実施形態では、センサネットワークにおけるセンシングデータの流通を例示したが、本発明は、センサ以外のデバイスを含むデバイスネットワークにおけるデータの流通にも適用可能である。その場合も、システムの基本的な構成は上記実施形態のものと同様であり、上記実施形態における「センサ」を「デバイス」と読み替え、「センシングデータ」を「データ」と読み替えればよい。
【符号の説明】
【００８１】
１０  センサネットワークサーバ
１１  記憶部
１２  マッチング部
１３  調整部
１４  入出力部
１５  データフロー制御部
２０  センサ装置
２１  センサ
２２  センサネットワークアダプタ
３０  アプリケーションサーバ
【図１】
0006458755.tif 000002
【図２】
0006458755.tif 000003
【図３】
0006458755.tif 000004
【図４】
0006458755.tif 000005
【図５】
0006458755.tif 000006
【図６】
0006458755.tif 000007
【図７】
0006458755.tif 000008
【図８】
0006458755.tif 000009
【図９】
0006458755.tif 000010