JP6372508B2 - データフロー制御装置およびデータフロー制御方法 - Google Patents

Description

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

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

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

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

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

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

特開２００７−３００５７１号公報 特許第５４４５７２２号公報

出願人らはさらに、センサネットワークにおいて、センシングデータなどの情報資源を適切に流通させるための技術について鋭意検討している。例えば、センサに関する情報が記述されたデータと、センシングデータを利用するアプリケーションに関する情報が記述
されたデータを適切にマッチングさせることで、センシングデータを提供したいユーザと、センシングデータを利用したいユーザとを結びつけることができる（特許文献２参照）。
これにより、例えばセンサの所有者は、データ利用者に対してセンサの一時利用を許可したりセンシングデータを提供したりすることで対価を得られる。また利用者にとっては、センサを設置する投資が不要なため安価に必要なデータを得ることができるというメリットがある。

特許文献２に記載の発明では、センサに対応するメタデータと、当該センシングデータを利用するアプリケーションに対応するメタデータを用いてマッチングを行い、センサとアプリケーションのペアを生成している。
ところで、センシングデータを提供する側にとっては、利益の面から、センサの能力内でより多くのアプリケーションに対してデータを提供することが好ましい。また、センシングデータを利用する側にとっては、必要なデータを収集するため、複数のセンサから情報を収集することが好ましい場合がある。しかし、特許文献２に記載の発明では、このように、組み合わせる相手の数を適切に制御することはできない。

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

本発明は上記実情に鑑みなされたものであり、データ提供者とデータ利用者との組み合わせを生成するデバイスネットワークにおいて、組み合わせる相手の数を制御することを目的とする。

本発明に係るデータフロー制御装置は、
複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得手段と、前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションに対応するアプリ側メタデータと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスに対応するデバイス側メタデータの組み合わせを抽出するマッチング手段と、前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、を有し、前記デバイス側メタデータまたはアプリ側メタデータは、複数の相手側メタデータとの組み合わせを許可するか否かを表す情報である可否情報を含み、前記マッチング手段は、前記デバイス側メタデータまたはアプリ側メタデータが有する前記可否情報に基づいて、単一の相手側メタデータとの組み合わせを生成するか、複数の相手側メタデータとの組み合わせを生成するかを決定することを特徴とする。

可否情報は、複数の相手側メタデータとの組み合わせを生成することを許可するか否か
を示す情報である。例えば、単一の相手とのみ組み合わせを生成したい場合（すなわち、二者以上とのペアリングを行いたくない場合）、否を表す情報を設定する。可否情報は、メタデータを登録するユーザによって設定されてもよい。
かかる構成によると、メタデータ同士の組み合わせにおいて、一対一の組み合わせを生成するか、一対多の組み合わせを生成するかを制御することができる。

また、前記可否情報は、組み合わせを許容する相手側メタデータの最大数を含み、前記マッチング手段は、対象メタデータとの組み合わせの対象となる相手側メタデータを、前記最大数を上限として抽出することを特徴としてもよい。

複数の相手側メタデータとの組み合わせを許可する場合、組み合わせの数に上限を設けておかないと、不都合が生じるおそれがある。例えば、デバイス側においては、デバイスの処理能力を上回る数のアプリケーションがペアリングされてしまうことで過負荷がかかるおそれがあり、アプリケーション側においては、アプリケーションが必要な数以上のデバイスがペアリングされてしまうことで過剰なコストがかかるおそれがある。よってマッチング手段は、上限として設定された数の範囲内でペアリングを行うことが好ましい。

また、前記マッチング手段は、マッチングの結果得られた相手側メタデータの個数が、前記最大数を下回る場合に、得られた組み合わせを抽出するとともに、前記最大数から前記得られた相手側メタデータの個数を減じた値を前記最大数に再設定することを特徴としてもよい。

前述したケースとは反対に、必要な個数の相手先メタデータが見つからない場合がある。これに対応するため、得られた相手側メタデータの個数が最大数を下回る場合、下回った個数を最大数として再設定してもよい。例えば、最大数が５個であって、ペアリングが成立したメタデータが３個のみであった場合、最大数を２個に更新してもよい。このようにすることで、相手先の数が、ユーザが所望する数に達するまでマッチングを続けることができる。

また、前記デバイスは、センシングデータを出力するセンサであることを特徴としてもよい。本発明に係るデータフロー制御装置は、センシングデータを提供するデータ提供者と、センシングデータを利用するデータ利用者とで構成されるセンサネットワークに好適に適用することができる。

なお、本発明は、上記手段の少なくとも一部を含むデータフロー制御装置として特定することができる。また、本発明は、上記データフロー制御装置を有するデバイスネットワークシステムとして特定することもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法として特定することもできる。また、本発明は、コンピュータに上記方法を実行させるプログラムとして特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

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

本発明によれば、データ提供者とデータ利用者との組み合わせを生成するデバイスネットワークにおいて、組み合わせる相手の数を制御することができる。

実施形態に係るセンサネットワークシステムの構成図である。 実施形態における、センサ側／アプリ側メタデータの例である。 センサ側メタデータを登録する画面の例である。 マッチング処理のフローチャート図である。 マッチング処理のフローチャート図である。

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

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

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

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

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

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

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

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

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

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

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

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

図１のシステム構成例では、センサネットワークサーバ１０は、記憶部１１、マッチング部１２、入出力部１３、データフロー制御部１４を有する。
記憶部１１は、センサネットワークに登録されているすべてのアプリケーションに対応するアプリ側メタデータと、センサネットワークに登録されているすべてのセンサに対応するセンサ側メタデータを記憶するデータベースである。

マッチング部１２は、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータのマッチングを行い、アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出し、センサとアプリケーションのペアを生成する（ペアリングを行う）手段である。
マッチング部１２が行う処理の詳細については後述する。

入出力部１３は、登録対象のセンサ側メタデータまたはアプリ側メタデータを取得するためのインタフェース手段である。入出力部１３は、有線または無線接続で外部のコンピュータと通信を行うハードウェアである。なお、入出力部１３は、ディスプレイデバイスとヒューマンインタフェースデバイス（キーボードやマウス等）を含んでいてもよい。この場合、外部のコンピュータと通信を行う必要はない。いずれの場合も、入出力部１３を介して、ユーザに情報を提供し、また、ユーザから情報を取得することができる。
データフロー制御部１４は、マッチング部１２が出力した情報に基づき、センシングデータの送信を指令するデータフロー制御指令を生成し送信する機能である。これらの機能の詳細は後述する。

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

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

複数ペア許容フラグは、当該センサ側メタデータについて、複数のアプリ側メタデータとのペアリングを許容するか否かを表すフラグである。
また、複数ペア許容数フィールドは、複数ペア許容フラグがＯＮである場合に、ペアを組む相手先となるアプリ側メタデータの最大数が代入されるフィールドである。複数ペア許容フラグがＯＦＦである場合、複数ペア許容数は０となる。

＜アプリ側メタデータ＞
図２（Ｂ）は、記憶部１１にテーブル形式で格納されるアプリ側メタデータの例である。
アプリ側メタデータは、アプリケーションの属性情報、アプリケーションが要求するセンシングデータの仕様（要求仕様）を示す情報、センシングデータの利用条件を示す情報などを記述したメタデータである。
アプリケーションの属性情報は、例えば、アプリケーションを特定するＩＤ、アプリケーションの種別、アプリケーションのネットワークアドレスなどを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ポート番号などを利用できる。センシングデータの要求仕様を示す情報は、例えば、センシング対象、センシングする領域、センシング時間、センシングデータのデータ種別、データフォーマット、センシング条件、データ信頼度などを含ませることができる。
利用条件を示す情報は、データ利用者が希望する取引条件を示す情報であり、例えば、データ利用者を特定するＩＤ、対価（データの利用価格の上限）、利用範囲・利用目的などを含ませることができる。

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

また、アプリ側メタデータも、複数ペア許容フラグおよび複数ペア許容数フィールドを
有している。
複数ペア許容フラグは、当該アプリ側メタデータについて、複数のセンサ側メタデータとのペアリングを許容するか否かを表すフラグである。
また、複数ペア許容数フィールドは、複数ペア許容フラグがＯＮである場合に、ペアを組む相手先となるセンサ側メタデータの最大数が代入されるフィールドである。複数ペア許容フラグがＯＦＦである場合、複数ペア許容数は０となる。

＜メタデータの登録＞
データ提供者あるいはデータ利用者が、データの提供または利用を希望する際は、自己が所有するコンピュータをセンサネットワークサーバ１０に接続し、メタデータの内容を入力する。具体的には、ネットワークを介して入出力部１３にアクセスし、入出力部１３が生成した画面に従って情報の入力を行う。これにより、センサ側メタデータあるいはアプリ側メタデータが生成され、記憶部１１に記憶される。本例では、データ提供者がセンサ側メタデータを生成する例を挙げて説明を行うが、データ利用者がアプリ側メタデータを生成する場合も同様である。

図３は、データ提供者がセンサ側メタデータを新規登録する際に表示される画面の例である。当該画面は、入出力部１３が生成し、入出力部１３に接続されたデータ提供者のコンピュータに出力される。

本実施形態では、メタデータの内容を入力する際に、「ペアリング上限数」を設定する。ペアリング上限数は、相手側メタデータとのペアを成立させる上限数である。図３の例では、ペアリング上限数に５件が設定されている。この場合、例えば、メタデータ同士のマッチングを行った結果１０件のアプリ側メタデータがヒットした場合、５個を上限としてペアを生成する。図３の例は、センサ側メタデータを入力する例であるが、アプリ側メタデータを入力する場合も同様である。

ペアリング上限数が多すぎると、センサの処理能力を超過する、データ利用者が支払う対価が想定を上回る、ネットワークのトラフィックが過剰になるといったおそれがあるため、ペアリング上限数には適切な値を設定することが好ましい。

図３に示した画面で、情報を入力したユーザが「登録」を押下すると、入力されたメタデータがセンサ側メタデータとして記憶部１１に登録される。またこの際、設定されたペアリング上限数に応じて、複数ペア許容フラグと、複数ペア許容数が設定される。
具体的には、ペアリング上限数が０の場合、複数ペア許容フラグにはＯＦＦが設定され、ペアリング上限数が１以上の場合、複数ペア許容フラグにはＯＮが設定される。また、複数ペア許容数には、入力されたペアリング上限数が設定される。

＜マッチング処理＞
マッチングとは、マッチング部１２が行う処理であって、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータ同士を比較し、条件が合致するもの同士を抽出してペアリングしたうえで、該当するセンサからアプリケーションへのセンシングデータのデータフローを制御する指令を発行する処理である。マッチングは、新規にメタデータを登録した場合に実行される。
図４は、センサ側メタデータを登録した際に実行されるマッチングの処理フローチャート図である。

まず、記憶部１１が有するセンサ側メタデータテーブルから、処理待ちのセンサ側メタデータを一つずつ取得する（ステップＳ１１）。
次に、記憶部１１が有するアプリ側メタデータテーブルから、アプリ側メタデータを一
つ取得する（ステップＳ１２）。

次に、アプリ側メタデータで規定されたセンシングデータの仕様および取引条件（提供条件）が、センサ側メタデータで規定されたセンシングデータの要求仕様および取引条件（利用条件）を満足するか否かを判定する。ここで、センサ側メタデータおよびアプリ側メタデータが有する比較対象項目が合致した場合、ペア成立となり、合致しなかった場合、ペア不成立となる（ステップＳ１３）。
なお、条件が合致するか否かは、必ずしも文言上の完全一致によって判断する必要はない。例えば、センシング場所が、センサ側において「京都市内」であって、アプリ側において「京都駅前」であった場合、両者は合致するものと判定される。

例えば、図２における、センサＩＤ「Ｒ００１」を考える。本例では、センシング場所、センシング時間、データ種別、利用範囲、対価、データ来歴の６項目が比較対象項目であるため、アプリＩＤ「Ａ００１」および「Ａ００２」の双方と条件が一致する。すなわち、「Ｒ００１とＡ００１」、「Ｒ００１とＡ００２」という２つのペアが成立する。

ステップＳ１３でペアが成立した場合、ステップＳ１２で取得したアプリ側メタデータが、最終的なペア候補の一つとして抽出される（ステップＳ１４）。
ステップＳ１２〜Ｓ１４の処理は、アプリ側メタデータテーブルに登録されているすべてのアプリ側メタデータについて実行される（ステップＳ１５）。

次に、ステップＳ１６で、候補として抽出されたアプリ側メタデータの数を判定する。
候補として抽出されたアプリ側メタデータが複数存在する場合、マッチング部１２は、対象のセンサ側メタデータが、複数ペアを許容しているか否かを判定する（ステップＳ１７）。

ここではまず、対象のセンサ側メタデータが、複数ペアを許容していない場合（ステップＳ１７−Ｎｏ）の説明を行う。この場合、複数の候補のなかからデータ提供者にとって最も有利なものを選択する（ステップＳ１８）。例えば対価優先の場合は、データの価格が最も高いものを選択すればよい。データ提供者に最も有利なアプリケーションをどのような基準で選択するかは、適宜設定することができる。
なお、候補として抽出されたアプリ側メタデータが一つもなかった場合は、処理を終了してもよいし、データ仕様や取引条件、データ来歴情報が最も近いものをレコメンドしてもよい。また、所定の時間が経過後、再度図４に示した処理を実行するようにしてもよい。

最後に、データフロー制御部１４が、対象のセンサに対して、センシングデータの送信を指令するデータフロー制御指令を生成し、当該データフロー制御指令を、当該センサ２１を管理するセンサネットワークアダプタ２２に対し送信する（ステップＳ１９）。
そして、図１に示したように、センサネットワークアダプタ２２が、データフロー制御指令に基づいてセンサ２１から必要なセンシングデータを取得し、対応するアプリケーションサーバ３０へと送信する。

なお、データフロー制御指令は、データフロー制御指令ＩＤ、センサを特定する情報（センサＩＤ、センサのネットワークアドレス）、アプリを特定する情報（アプリＩＤ、アプリのネットワークアドレス）、データ送信を行う時間情報などを含んだデータであるが、これ以外の情報を含んでいてもよい。

次に、対象のセンサ側メタデータが、複数ペアを許容していた場合（ステップＳ１７−Ｙｅｓ）の処理を、図５を参照しながら説明する。
まず、ステップＳ２１で、候補として抽出されたアプリ側メタデータの数が、処理対象のセンサ側メタデータの複数ペア許容数と同等か上回っているかを判定する。この結果、同等か上回っていた場合、データ提供者にとって有利な順に、アプリ側メタデータを許容数の数だけ選択する（ステップＳ２２）。例えば、複数ペア許容数が５個で、抽出された候補が１０個であった場合、センサ側メタデータと、アプリ側メタデータとのペアが５組成立する。そして、該当するアプリケーションに対するデータフロー制御指令が生成され、対象のセンサ装置へ送信される（ステップＳ１９）。

一方、ステップＳ２１で、候補として抽出されたアプリ側メタデータの数が、処理対象のセンサ側メタデータの複数ペア許容数を下回っていた場合（例えば、複数ペア許容数が５個であり、抽出された候補が２個であった場合）、アプリ側メタデータを、抽出された候補数ぶんだけ選択する（ステップＳ２３）。この結果、センサ側メタデータと、アプリ側メタデータとのペアが２組成立する。

この場合、ペアリングされたアプリ側メタデータが、許容数に対して少ない状態となるため、更なるペアの成立を待つことが好ましい。そこで、本実施形態では、ステップＳ２４で、対応するセンサ側メタデータの複数ペア許容数を、ペアリング可能な残数に変更する。例えば、複数ペア許容数が５個であって、ペアが２組成立した場合、残り３組のペアを生成することができる。そこで、対応するセンサ側メタデータの複数ペア許容数を３に変更する。このようにすることで、異なるタイミングで行われるマッチング処理によって更なるペアが成立することが期待できる。なお、ペアの数が複数ペア許容数よりも少なくてもよい場合は、ステップＳ２４を省略してもよい。

以上に説明したように、本実施形態では、センサ側メタデータおよびアプリ側メタデータに、複数の相手先メタデータとのペアリングを許容するか否かを表すフラグを付加し、具体的な上限数を設定する。また、当該情報に基づいてメタデータ同士のペアリングを行う。これにより、メタデータ同士のペアリングにおいて、一対多の組み合わせを生成するか、一対一の組み合わせを生成するかを制御することができ、ユーザの利便性が大きく向上する。

なお、本実施形態では、ステップＳ１８およびＳ２２において、データ提供者にとっての有利さを基準として相手先メタデータの候補を選択したが、当該方法は一例であり、これ以外の条件に基づいて候補を選択してもよい。

（変形例）
なお、上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。例えば、上記実施形態で示したデータ構造やテーブル構造は一例であり、項目を適宜追加したり入れ替えたりしてもよい。

また、実施形態の説明では、センサ側メタデータが新規に登録されたことをトリガとして図４に示したマッチング処理を行う例を挙げたが、マッチング処理は、アプリ側メタデータが新規に登録されたことをトリガとして実行してもよい。この場合、センサとアプリ、データ提供者とデータ利用者をそれぞれ読み替えればよい。また、実施形態の説明では、メタデータを登録したタイミングでマッチング処理を実行するものとしたが、マッチング処理は周期的に実行されてもよい。

また、ペアが成立したセンサ側メタデータおよびアプリ側メタデータは、記憶部１１から削除してもよいし、契約が成立した旨のフラグを付与し、契約が解除されるまでマッチング対象から外すようにしてもよい。

また、上記実施形態では、センサネットワークにおけるセンシングデータの流通を例示したが、本発明は、センサ以外のデバイスを含むデバイスネットワークにおけるデータの流通にも適用可能である。その場合も、システムの基本的な構成は上記実施形態のものと同様であり、上記実施形態における「センサ」を「デバイス」と読み替え、「センシングデータ」を「データ」と読み替えればよい。

１０ センサネットワークサーバ
１１ 記憶部
１２ マッチング部
１３ 入出力部
１４ データフロー制御部
２０ センサ装置
２１ センサ
２２ センサネットワークアダプタ
３０ アプリケーションサーバ

Claims (6)

1. 複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得手段と、
   前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
   前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、
   前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションに対応するアプリ側メタデータと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスに対応するデバイス側メタデータの組み合わせを抽出するマッチング手段と、
   前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、
   を有し、
   前記デバイス側メタデータまたはアプリ側メタデータは、複数の相手側メタデータとの組み合わせを許可するか否かを表す情報である可否情報を含み、
   前記マッチング手段は、前記デバイス側メタデータまたはアプリ側メタデータが有する前記可否情報に基づいて、単一の相手側メタデータとの組み合わせを生成するか、複数の相手側メタデータとの組み合わせを生成するかを決定する
   ことを特徴とするデータフロー制御装置。
2. 前記可否情報は、組み合わせを許容する相手側メタデータの最大数を含み、
   前記マッチング手段は、対象メタデータとの組み合わせの対象となる相手側メタデータを、前記最大数を上限として抽出する
   ことを特徴とする、請求項１に記載のデータフロー制御装置。
3. 前記マッチング手段は、マッチングの結果得られた相手側メタデータの個数が、前記最大数を下回る場合に、得られた組み合わせを抽出するとともに、前記最大数から前記得られた相手側メタデータの個数を減じた値を前記最大数に再設定する
   ことを特徴とする、請求項２に記載のデータフロー制御装置。
4. 前記デバイスは、センシングデータを出力するセンサである
   ことを特徴とする、請求項１から３のいずれか１項に記載のデータフロー制御装置。
5. コンピュータが、
   複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得ステップと、
   前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
   前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶ステップと、
   前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションに対応するアプリ側メタデータと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスに対応するデバイス側メタデータの組み合わせを抽出するマッチングステップと、
   前記マッチングステップで抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御ステップと、
   を実行し、
   前記デバイス側メタデータまたはアプリ側メタデータは、複数の相手側メタデータとの
   組み合わせを許可するか否かを表す情報である可否情報を含み、
   前記マッチングステップでは、前記デバイス側メタデータまたはアプリ側メタデータが有する前記可否情報に基づいて、単一の相手側メタデータとの組み合わせを生成するか、複数の相手側メタデータとの組み合わせを生成するかを決定する
   ことを特徴とするデータフロー制御方法。
6. 請求項５に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。
   
   

Images