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