JP2015038744A - センシングデータの提供契約及び利用契約のデータ構造 - Google Patents

Abstract

【課題】センサネットワークの実用化および普及を促進するための技術を提供する。【解決手段】センシングデータの提供者の契約条件を定義した提供契約データのデータ構造は、センサを特定するためのセンサ番号を表すデータと、前記センサのアドレスを表すデータと、契約番号を表すデータと、前記センサにより得られるセンシングデータの種別を表すデータと、前記センサによるセンシングエリアの位置を表すデータと、前記センサのセンシング周期を表すデータと、前記センサにより得られるセンシングデータの信頼度を表すデータと、センシングデータの対価を表すデータと、センシングデータの利用範囲を表すデータと、を含む。【選択図】図１３

Description

本発明は、センサネットワークに関する。

センサネットワークとは、センサ機能と無線通信機能をもつ機器（ノード）を様々な場所に設置しそれらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能化する技術である。センサネットワークが実現すれば、あらゆる場所の状況を何処からでも素早く正確に把握することが容易となるので、製造現場や物流などの産業分野への応用はもちろんのこと、交通・各種インフラといった社会システムや、医療・教育などの生活に関わる分野まで、幅広い応用が期待されている。

ところで、センサネットワークの実現および実用化のためには、いくつかクリアすべき課題がある。一つは、各地に設置されたノード（センサ）を２４時間３６５日稼働させるための可用性および信頼性の確保であり、もう一つは、数多くのノードを網羅的に設置するために必要なコスト（あるいは動機付け）の問題である。これらは特に、センサネットワークの普及・拡充を図る上で避け得ない問題として存在する。

本発明者は、これらの問題を解決するために、センサネットワークに関わるシステムおよびサービスの仕組みについて検討を重ねている。その検討のなかで、センサネットワークを構成する各ノードに平常時と災害時とでそれぞれ別の役割を担わせることで、ノードの利用価値を向上することができないかとの着想を得た。例えば、平常時には別の目的（本来の目的）で稼働していたノードを、災害時には情報インフラや情報ステーションとして機能させるというものが考えられる。また、各々のノードが現実世界における位置座標（設置位置）と結びついているという性質を活かし、現実世界でのゲーム（例えばウォークラリーゲーム）のチェックポイントとしてノードを利用するなど、平常時の利用方法にも様々なものが考えられる。

なお、災害時の情報インフラに関わる先行技術としては、例えば特許文献１（特開２００８−２９９５９７号公報）のシステムが知られている。同システムは、災害時の安否確認や防災情報の告知のためのシステムであり、中央局と親局の間は無線回線と冗長ネットワークとで接続され、親局と複数の子局は無線アドホックネットワークを形成している点に特徴がある。中央局が発信した警報は、親局を経由して、無線アドホックネットワークを通じて各子局に配信される。また、各子局で入力された安否情報は親局を経由して中央局に集約される。しかしながら、特許文献１のものはセンサネットワークとは技術分野が異なり、これをそのままセンサネットワークに適用することはできない。また特許文献１のものは災害時専用のシステムであって、平常時の利用は何ら想定されていない。

一方、特許文献２（特開２００７−１９０３４４号公報）には、パソコンと歩数計を用いて仮想世界でのウォークラリーゲームを行うシステムが開示されている。具体的には、ユーザが歩数計をパソコンに接続すると、歩数データが所定のウェブサイトに自動的に伝送され、ウェブサイトにおいて当該ユーザの歩行距離・到達地点・残距離などが計算され、それらが地図データとともにユーザのパソコンに表示されるというものである。しかし、このシステムは、現実世界に設置されたノードを利用するものではなく、センサネットワークには適用できない。

特開２００８−２９９５９７号公報 特開２００７−１９０３４４号公報

本発明は、上記実情に鑑みてなされたものであって、センサネットワークの実用化および普及を促進するための技術を提供することを目的とする。

上記目的を達成するために本発明では、以下の構成を採用する。

請求項１に係る発明は、センシングデータの提供者が希望する契約条件とセンシングデータの利用者が希望する契約条件とのマッチングに用いるための、提供者の契約条件を定義した提供契約データのデータ構造であって、センサを特定するためのセンサ番号を表すデータと、前記センサのアドレスを表すデータと、契約番号を表すデータと、前記センサにより得られるセンシングデータの種別を表すデータと、前記センサによるセンシングエリアの位置を表すデータと、前記センサのセンシング周期を表すデータと、前記センサにより得られるセンシングデータの信頼度を表すデータと、センシングデータの対価を表すデータと、センシングデータの利用範囲を表すデータと、を含むことを特徴とする、センシングデータの提供契約データのデータ構造である。

請求項２に係る発明は、センシングデータの提供者が希望する契約条件とセンシングデータの利用者が希望する契約条件とのマッチングに用いるための、利用者の契約条件を定義した利用契約データのデータ構造であって、利用者を特定するための利用者番号を表すデータと、センシングデータの提供先のアドレスを表すデータと、契約番号を表すデータと、希望するセンシングデータの種別を表すデータと、希望するセンシングエリアの位置を表すデータと、希望するセンシング周期を表すデータと、希望するセンシングデータの信頼度を表すデータと、希望するセンシングデータの対価を表すデータと、センシングデータの利用範囲を表すデータと、を含むことを特徴とする、センシングデータの利用契約データのデータ構造である。

本発明によれば、センサネットワークの実用化および普及を促進することができる。

センサネットワークシステムの全体構成と平常時の動作を説明するための図。 センサネットワークシステムの全体構成と災害時の動作を説明するための図。 陣取りソーシャルゲームを説明するための図。 （ａ）はゲーム参加者の個人管理情報のデータ構造の例、（ｂ）はアプリケーションサーバーに集計された移動履歴データのデータ構造の例。 閉ループ間の包含関係の検出処理のフローチャート。 閉ループ間の包含関係に基づき計算された陣取り状態を示す図。 各参加者または各参加グループ単位での獲得ポイントを算出する処理のフローチャート。 陣取りソーシャルゲームの中間状態の提示画面の例。 災害時対応サーバーの構成および動作を説明するための図。 仲介サーバーの構成を示す機能ブロック図。 契約マッチング処理部の機能および動作を説明するための図。 契約マッチング処理のフローチャート。 （ａ）はセンシングデータ提供契約データベースのデータ構造の例、（ｂ）はセンシングデータ利用契約データベースのデータ構造の例。 センシングデータ配信制御部の機能および動作を説明するための図。 センシングデータ配信制御のフローチャート。 センシングデータ処理制御部の機能および動作を説明するための図。 センシングデータ処理制御のフローチャート。 仮想センサ管理データの一例を示す図。 対価精算処理部の機能および動作を説明するための図。 実センサからのセンシングデータ取得処理部の機能および動作を説明するための図。

本発明は、センサ機能と無線通信機能をもつ機器を様々な場所に設置しネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能にする技術（センサネットワーク）に関するものである。

本明細書では、センサネットワークを実現するための構成として、異なる地点に設置される多数の「無線通信ノード」と、各無線通信ノードで得られたセンシングデータを収集し管理する「仲介サーバー」と、仲介サーバーから提供を受けたセンシングデータを利用する「アプリケーションサーバー」とからなるシステムを説明する。このシステム構成は、無線通信ノードを設置しそこで得られたセンシングデータを提供する者（提供者）と、アプリケーションサーバーを運用しセンシングデータの利用を行う者（利用者）とが別の者であり、第三者（仲介者）で運用される仲介サーバーが提供者と利用者の間のセンシングデータの取引・売買を仲介する、という形態を想定したものである。このような仕組みの実現によりセンシングデータそのものの流通市場が形成されれば、無線通信ノードを設置する提供者側とデータを利用する利用者側の双方にメリットが生まれるため、提供者および利用者の新たな参加や無線通信ノードの設置が加速度的に進み、センサネットワークの普及・拡充が図られると期待される。

無線通信ノードには、無線通信ノード自身がセンサを備えている構成のものもあるし、別に設けられたセンサからセンシングデータを取得する構成のものもある。以下の説明においては、無線通信ノードを単に「ノード」または（センサを備えた構成の無線通信ノードの場合は）「センサ」ともよぶ。なお、センサには様々な種類のものが存在するが、本発明に係るセンサネットワークでは、センシングした結果をデジタルデータの形式で取り出すことができさえすれば、いかなる種類のセンサ（およびそのセンシングデータ）を利用することができる。センサの一例を挙げると、画像センサ、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ、ガスセンサなどがあるが、もちろんこれらに限られない。

以下に述べる実施形態では、各種センサを備えたノードを様々な地点に設置し、平常時には、各ノードから周囲環境の状態を収集する一方で、各ノードを歩数計（活動量計）を使ったゲームのマークポイントとしても活用し、さらに災害時には、各ノードを被災状況や安否情報を収集したり各種情報を提供したりする情報インフラや情報ステーションとして活用するシステムを説明する。ただし、これらの利用形態は本発明の一つの適用例にすぎず、本発明の範囲をこれらの構成に限定する趣旨のものではない。

＜システム全体構成（平常時）＞
図１は、本発明の実施形態に係るセンサネットワークシステムの全体構成と平常時の動作を模式的に示している。

図に示すように、マークポイントノード設置施設Ａ，Ｂ，Ｃ，Ｉ，Ｎ・・・にそれぞれマークポイントノード１と称される無線通信ノードが設置されている。各施設のマークポイントノード１は、無線ＬＡＮルーター１００、モデム（光モデムやＡＤＳＬモデム）１０１などのネットワーク装置を介して、公衆通信ネットワークであるインターネットに接続されている。また、ゲームを提供するゲーム実行装置としてのアプリケーションサーバー４、および、センシングデータの仲介を行う仲介装置としての仲介サーバー３もそれぞれインターネットに接続されている。

（マークポイントノードの構成）
マークポイントノード１は、太陽光発電パネル１２とバッテリ１３からなる電源を内蔵している。太陽光発電パネル１２は自然エネルギーである太陽光を受けて発電するデバイスであり、バッテリ１３は太陽光発電パネル１２で発電した電力を蓄積する電池である。この電源はマークポイントノード１内の給電対象デバイスに電力を供給するために利用される。太陽光発電パネル１２とバッテリ１３の他に、商用電源（ＡＣ電源）を利用するための電源を設けることもできる。その場合、平常時は商用電源を利用し、災害時（停電時）には太陽光発電パネル１２とバッテリ１３を利用するように切り換えるとよい。あるいは、マークポイントノード設置施設内に太陽光発電システムや風力発電システムなどの非常用電源が設けられている場合は、災害時にはそれらの外部非常用電源から電力の供給を受けるようにしてもよい。

マークポイントノード１は、環境センサ１４とＲＦＩＤリーダライタ１７を有している。環境センサ１４は周囲環境の状態をセンシングするためのセンシング手段であり、例えば、画像センサ、温度センサ、湿度センサなど、目的に応じて１つまたは複数のセンサが設けられる。環境センサ１４からは定期的にセンシングデータが取り込まれる。ＲＦＩＤリーダライタ１７は、ユーザの保持する移動体端末２から非接触無線通信によりデータを読み取ったり、移動体端末２にデータを伝送したりする手段である。

マークポイントノード１は、ゲームの参加者を含め、当該ノード１を利用する人との間のＭＭＩ（マンマシンインターフェイス）のための表示部１５とスピーカー１６も備えている。図示しないが、キーボードやタッチパネルなどの入力部を備えてもよい。

そして、これらのデバイスは制御用ＰＣ（パーソナルコンピュータ）１０で制御される。この制御用ＰＣ１０は、マークポイントノード１の設置位置を例えば（緯度，経度）というデータで記憶しているし、正確な日時を測定するクロックを内蔵する。なお、マークポイントノード１にＧＰＳセンサを内蔵し、ＧＰＳセンサの出力からノード１の設置位置を求める構成でもよいし、あるいは仲介サーバー３が各ノード１の設置位置を記憶・管理している場合にはノード１の側に位置データを記憶しておく必要はない。

さらに、制御用ＰＣ１０は、無線通信手段としての無線ＬＡＮ子機１１を有しており、マークポイントノード設置施設Ｎに設けられている無線ＬＡＮルーター１００と無線通信を行うことができる。そのため、マークポイントノード１は、電源供給の面でも情報通信の面でも、ケーブル設置工事なしで、マークポイント設置施設Ｎに設置することができる。

マークポイント設置施設Ｎは、典型的には一般住宅や店舗である。つまり、一般の人々や店舗の経営者などに、マークポイントノード１の設置・運用ならびにセンシングデータの提供を行う「提供者」となってもらうことを想定している。最近では、光通信、ＡＤＳＬ、ケーブル通信などのブロードバンド接続サービスを導入している住宅、店舗がほとんどである。その場合は、モデム１０１は既存のものを利用し、（なければ）無線ＬＡＮル
ーター１００を追加するだけで、マークポイントノード１を設置する準備が整う。この提供者が定額制でブロードバンド接続サービスを受けている場合には、マークポイントノード１を設置して、マークポイントノード１が常時動作する状況を実現しても、この提供者の金銭的な負担は増加しない。なお、マークポイントノード１を住宅に設置する場合には、例えばフェンスや外壁などに道路側に向けて取り付けるとよい。店舗の場合には、ゲーム参加者を来店客として呼び込むために、店舗の中に設置するとよい。

（ゲームに関わる動作）
ゲームの参加者は、移動体端末２を保持して歩きながら、マークポイントを巡る。移動体端末２は、歩数計もしくは活動量計、または、歩数計測機能をもつ携帯電話もしくは携帯型情報端末（スマートフォン、スレート型端末含む）である。参加者が歩いた累積歩数データが移動体端末２のメモリ２０内に蓄積されている。また、メモリ２０内には、参加者毎（端末毎）に割り当てられたＩＤ情報も格納されている。

ゲーム参加者が、マークポイントを巡り、移動体端末２をＲＦＩＤリーダライタ１７にかざすと、（１）ＩＤ情報、（２）現時点での累積歩数データがマークポイントノード１に読み取られる。マークポイントノード１の制御用ＰＣ１０は、移動体端末２から読み取った（１）ＩＤ情報と（２）累積歩数データに、（３）マークポイントノード１の位置（緯度，経度）と（４）読み取った時刻の情報を組にして記憶する。このデータを通過点データとよぶ。

各設置施設Ａ，Ｂ，Ｃ，Ｉ，Ｎ・・・に設置されている各マークポイントノード１は、そこに訪れたゲーム参加者の通過点データを蓄積し、これを所定の周期でインターネットを通じて仲介サーバー３に送信する。仲介サーバー３は必要な処理を行った後、これらの通過点データをアプリケーションサーバー４に送信する。仲介サーバー３の構成および動作については後述する。

アプリケーションサーバー４上で動作するゲームソフトウェアは、複数のマークポイントノード１から受け取った通過点データを集計すると、（１）ＩＤ情報、（２）マークポイントノードの位置（通過点）、（３）ＩＤを読み取った時刻（通過時刻）に基づき集計データを分析することにより、各ゲーム参加者の移動経路を抽出する。そして、アプリケーションサーバー４は、参加者間（あるいは参加グループ間）で移動経路を比較し、その比較結果をゲームのルールに当てはめて、ゲームの結果データを生成する。ゲームの結果（勝敗、獲得ポイントなど）はゲーム参加者のＰＣ４０や携帯電話４１などに通知され、また各施設のマークポイントノード１でも確認することができる。さらに、アプリケーションサーバー４はゲームの面白さを高めるために、ゲームの途中における中間状態をゲーム参加者やゲーム観戦者に示すため、各種の情報を生成し、提示してもよい。この中間情報についてもＰＣ４０、携帯電話４１、マークポイントノード１で確認可能にするとよい。

（陣取りソーシャルゲーム）
ゲームの具体例として、陣取りソーシャルゲームを説明する。陣取りソーシャルゲームのルールは以下の通りである。

ルール１： 開始日と終了日からなるゲーム期間と、明確な境界線が定義できる開催地域が定められた陣取りソーシャルゲームにおいて、開催地域内でゲーム期間内に獲得した陣地の所定特性値（例：面積、店の売上高、米の生産量）に応じて換算されるポイントを獲得できる。
ルール２： 陣地を獲得するためには、その陣地の全体を右回りまたは左回りで包む閉曲線（以下、閉ループという）の経路を、ゲーム期間内に周回した回数が、他のどのグル
ープまたは個人よりも多いことが必要である。
ルール３： 個人は、他の個人と提携してグループを形成し、その陣地を各人が周回した回数を、形成したグループ内で合算することができる。この合算においては、陣地を周回する方向が同じ場合は足し算で合算されるが、周回する方向が逆の場合には引き算で合算される。
ルール４： 陣地の領域と周回方向は、対象の個人またはグループに属する個人ごとに、マークポイントノードへの最新の到着時刻の古いものから新しいものに向かう順に、マークポイントノードの系列を形成し、その系列の順にマークポイントの位置を直線で結んでいくことで決定する。
ルール５： 個人は、１つのゲーム期間内においては、陣地獲得のために陣地を囲む周回方向を右回りまたは左回りのどちらかで、周回方向の登録をしておく。周回方向が登録されたものと異なる、その個人のデータは集計の対象とならない。
ルール６： 陣取りソーシャルゲームに参加する個人は、一定の期間ごとに一定の参加料（例：年会費）を支払う。
ルール７： ゲーム参加者がグループを形成する場合、グループを形成する個人のデータは、ゲーム期間の終了の所定時間前またはゲーム期間の開始前までに登録しなければならない。
ルール８： 個人は１つのゲーム期間内では複数のグループには加入できない。

図３は、上記ルールに従った陣取りソーシャルゲームの経過を模式的に示すものである。図３は陣取りソーシャルゲームの開催地域を示す地図であり、地図上の○印がマークポイント（マークポイントノード１が設置された位置）を示している。開催地域内の様々な地点（住宅または店舗）にマークポイントが設けられていることが分かる。それぞれ３名ずつで構成される赤組（Ｇｐ０１）と青組（Ｇｐ０２）とがゲームに参加しており、赤組は周回方向を左回りで登録し、青組は右回りで登録したものとする。

（１）赤組は３人全員を投入して、閉ループＡを左回りに２回転した。合算後の回転数は６であり、閉ループＡの面積は３ｈａである。
（２）青組は１人を投入して、閉ループＢを右回りに１回転した。合算後の回転数は１であり、閉ループＢの面積は１ｈａである。
（３）青組は２人を投入して、閉ループＣを右回りに４回転した。合算後の回転数は８であり、閉ループＣの面積は１．５ｈａである。
（４）（１）での赤組の回転数よりも、（３）での青組の回転数の方が多いので、閉ループＣの内部は青組の陣地となる。青組は閉ループＣと閉ループＢを陣地としたので、陣地の面積合計は２．５ｈａとなる。一方、赤組の陣地は閉ループＡから閉ループＣを除いた面積なので、１．５ｈａとなる。この時点では、青組の陣地の方が赤組の陣地よりも広い。

（アプリケーションサーバーの動作）
次に、図４〜図８を参照して、アプリケーションサーバーのゲームソフトウェアの動作を具体的に説明する。図４（ａ）はアプリケーションサーバー４に登録されている、ゲーム参加者の個人管理情報のデータ構造の例であり、図４（ｂ）は、アプリケーションサーバー４に集計された移動履歴データのデータ構造の例である。図５は、閉ループ間の包含関係の検出処理のフローチャートであり、図６は、閉ループ間の包含関係に基づき計算された陣取り状態を示す図である。図７は、各参加者または各参加グループ単位での獲得ポイントを算出する処理のフローチャートである。図８（ａ）と（ｂ）は、陣取りソーシャルゲームの中間状態の提示画面の例である。

ゲームへの参加を希望する個人もしくはグループは、インターネットを通じてアプリケーションサーバー４のウェブサイトにアクセスすることにより、参加申込をすることがで
きる。アプリケーションサーバー４では、ゲーム参加者それぞれの情報を図４（ａ）および（ｂ）のように管理している。（ａ）では、個人管理情報として、参加者に一意に割り振られる個人ＩＤ（Ｐ００２０１）、氏名（歩行太郎）、メールアドレス（ａ１＠ｃ．ｊｐ）、ゲームの中間状態や結果を確認するためのウェブサイトにログインする際に必要なパスワード、所属グループのＩＤ（Ｇｐ０１）、獲得した陣地となる閉ループ番号リスト（初期状態では空であり、陣地を獲得すると閉ループ番号が記述される）、獲得した勝利者ポイント（初期状態では０であり、陣地を獲得するとそれに応じたポイントが付与される）、周回方向（右または左）が示されている。また（ｂ）がこの参加者がマークポイントを巡った履歴をまとめたものである。

アプリケーションサーバー４は、仲介サーバー３を介して各マークポイントノード１から通過点データを受け取ると、それらを参加者のＩＤ別に集計し、図４（ｂ）の移動履歴データとしてまとめる。移動履歴データには、マークポイントを通過した日時、マークポイントのＩＤ、マークポイントの位置（緯度，経度）、および、閉ループ番号が含まれている。なお、閉ループ番号は、当該参加者の移動履歴を分析した結果、閉ループが形成されたことが判明した時点で入力される情報である（図７のＳ２０７参照）。

陣取りソーシャルゲームの期間が終わると、全ての参加者の移動履歴データが確定する。そうしたら、アプリケーションサーバー４は、図７のフローチャートの手順で、各個人およびグループごとに獲得した陣地（閉ループ）を計算し、それに基づいて、各個人およびグループの獲得ポイントを計算する。以下、図７の処理を順に説明する。

アプリケーションサーバー４は、処理対象とする個人ＩＤを順に選択し（Ｓ２００）、その個人ＩＤの移動履歴データ（図４（ｂ））を個人管理情報から読み取る（Ｓ２０２）。次に、アプリケーションサーバー４は、移動履歴データから日時の古い順にデータを読み込み、上述したルール４と５に従って閉ループとその回転方向を検出する（Ｓ２０３）。次に、アプリケーションサーバー４は、検出した閉ループが他の誰も周回したことのない閉ループか（つまり、閉ループ番号が未付与の閉ループか）どうかを調べる（Ｓ２０４）。ＹＥＳ判定の場合は、アプリケーションサーバー４は新たな閉ループ番号を発行し（Ｓ２０５）、ＮＯ判定の場合は、同じ閉ループに付与されている閉ループ番号を用いる（Ｓ２０６）。そしてアプリケーションサーバー４は、Ｓ２０３で検出した閉ループを構成する各行のデータにＳ２０５またはＳ２０６で決定した閉ループ番号を記入する（Ｓ２０７）。移動履歴データの中に閉ループ番号が記入されていないデータがなくなるまで、Ｓ２０３〜Ｓ２０７の処理が繰り返される（Ｓ２０８）。全てのデータに閉ループ番号を付したら（Ｓ２０８；ＮＯ）、アプリケーションサーバー４は、その個人が周回した閉ループについて、その個人の個人ＩＤと閉ループ番号の組み合わせごとに、その個人の閉ループの周回数と回転方向を図６に示すテーブルに記録する（Ｓ２０９）。

以上述べたＳ２０２〜Ｓ２０９の処理を個人ＩＤごとに繰り返し（Ｓ２００，Ｓ２０１）、ゲームの参加者全員の処理が終了したら、Ｓ２１０の処理に移行する。Ｓ２１０では、アプリケーションサーバー４が、閉ループ間の包含関係を評価し、各閉ループが包含する他の閉ループのリストを作成する。

図５のフローチャートを参照して、Ｓ２１０における包含関係の判定アルゴリズムを説明する。図５は、第１の閉ループが第２の閉ループを包含しているか否かを判定する処理を示しており、この判定処理がすべての閉ループの組み合わせについて行われる。

まず、アプリケーションサーバー４が、第１の閉ループを構成するすべての頂点の座標リスト
｛（ｘ１１，ｙ１１）；（ｘ１２，ｙ１２）；……；（ｘ１Ｎ，ｙ１Ｎ）｝
を作成する（Ｓ１００）。ここで、ｘは緯度、ｙは経度であり、添え字の１文字目「１」は第１の閉ループであることを示し、２文字目「１」〜「Ｎ」は頂点のインデックスを示している。Ｎは第１の閉ループを構成する頂点の個数である。この座標リストの１点目、２点目、…を順に接続し、最後のＮ点目を１点目に接続することで閉ループが形成される。

次にアプリケーションサーバー４が、第２の閉ループを構成するすべての頂点の座標リスト
｛（ｘ２１，ｙ２１）；（ｘ２２，ｙ２２）；……；（ｘ２Ｍ，ｙ２Ｍ）｝
を作成する（Ｓ１０１）。ここで、ｘは緯度、ｙは経度であり、添え字の１文字目「２」は第２の閉ループであることを示し、２文字目「１」〜「Ｍ」は頂点のインデックスを示している。Ｍは第２の閉ループを構成する頂点の個数である。この座標リストの１点目、２点目、…を順に接続し、最後のＭ点目を１点目に接続することで閉ループが形成される。

次にアプリケーションサーバー４が、第１の閉ループの座標リストのなかからｘ座標の最大値ｘｍａｘ１とｙ座標の最大値ｙｍａｘ１を抽出する（Ｓ１０２）。そして、値ｘｍａｘ１，ｙｍａｘ１をそれぞれ２倍した値ｘＥ，ｙＥを計算し、これを座標値とする点Ｅ（ｘＥ，ｙＥ）を定義する。このようにして得られた点Ｅは、第１の閉ループの外側であることが保証された点である。

次にアプリケーションサーバー４が、フラグＦを０で初期化するとともに、頂点ポインタＱを１で初期化する（Ｓ１０４，Ｓ１０５）。フラグＦは、第２の閉ループが第１の閉ループに包含される場合にＦ＝０、包含されない場合にＦ＝１となるフラグである。また頂点ポインタＱは第２の閉ループの頂点を一つずつ選択するために用いるポインタである。

そしてアプリケーションサーバー４は、点Ｅ（ｘＥ，ｙＥ）と第２の閉ループのＱ番目の頂点（ｘ２Ｑ，ｙ２Ｑ）とを端点とする線分と、第１の閉ループの交点の個数Ｗを算出し、Ｗが奇数かどうかを調べる（Ｓ１０７，Ｓ１０８）。このとき、点（ｘ２Ｑ，ｙ２Ｑ）が第１の閉ループ上に乗っている場合も交点とする。

この処理を第２の閉ループを構成するすべての頂点Ｑ（＝１〜Ｍ）について順に行い（Ｓ１０９，Ｓ１０６）、Ｗが奇数とならない頂点がひとつでも見つかった場合には（Ｓ１０８；ＮＯ）、フラグＦに１を設定してループを抜ける（Ｓ１１０）。なお、すべての頂点でＷが奇数となった場合は、フラグＦは初期値０のままである。最後に、アプリケーションサーバー４は、フラグＦに基づき第１の閉ループと第２の閉ループの間の包含関係の結論を設定し（Ｓ１１１）、処理を終了する。

以上の判定処理を閉ループのすべての組み合わせについて実行したら、その結果を図６に示すテーブルに書き込む。図６の最初の行は、閉ループ「Ｂ」を、個人ＩＤ「Ｐ００２０１」の者が、「２７」回、右回りに周回したこと、閉ループ「Ｂ」は他の閉ループを包含しておらず（ＮＯＮＥ）、個人ＩＤ「Ｐ００２０１」の者はグループ「Ｇｐ０２」に属していること、が記録されている。また、図６の３番目の行には、閉ループ「Ａ」を、個人ＩＤ「Ｐ００１１５」の者が、「６」回、左回りに周回したこと、閉ループ「Ａ」は閉ループ「Ｃ」を包含していること、個人ＩＤ「Ｐ００１１５」の者はグループ「Ｇｐ０１」に属していること、が記録されている。

図６のテーブルが完成した後、アプリケーションサーバー４は、ルール２と３に従って、陣地ごとに獲得した個人またはグループのＩＤを検出する（Ｓ２１１）。そして、アプ
リケーションサーバー４は、個人またはグループごとに、獲得した陣地の特性項目ごとの特性値を集計し、それを獲得ポイントに換算する（Ｓ２１２）。獲得した陣地とポイントは図４（ａ）の個人管理情報に記録される。

Ｓ２１１とＳ２１２の処理について、図６の例を用いて詳しく説明する。グループＧｐ０１には、Ｐ００１１５というＩＤを持つメンバーと、Ｐ０００７８というＩＤを持つメンバーの２名が所属する。Ｐ００１１５は閉ループＡを左に６回転し、Ｐ０００７８は閉ループＡを左に８回転した。よって、グループＧｐ０１としては閉ループＡを左に計１４回転したことになる。

この閉ループＡには閉ループＣが含まれる。閉ループＣはＰ００２０１というＩＤを持つメンバーによって右に１０回転された。また、閉ループＣには、その中に含まれる他の閉ループが存在しない。閉ループＡと閉ループＣは包含関係にあるとともに、回転方向が逆であり、異なるグループが周回している。ルール２に基づいて、閉ループＣの陣地は、グループＧｐ０１が獲得する。なぜならば、Ｇｐ０１の回転数は１４であり、Ｇｐ０２の回転数は１０であって、Ｇｐ０１の方がＧＰ０２よりも回転数が多く、しかも相互に回転方向が逆であるからである。Ｇｐ０１が、閉ループＣ内も含めてループＡ内の全領域を、自分たちの陣地にできたことになる。

閉ループＡ内の領域の特性項目ごとの特性値が、Ｇｐ０１が獲得した陣地の特性項目ごとの特性値に加算される。ここで、特性項目としては、例えば、当該領域内の全店舗の前年度売上高，前年度の米の生産量，当該領域の面積が考えられる。このように、Ｇｐ０１が獲得した陣地の特性項目ごとに特性値が合計される。このようにして合計された特性値は、各特性項目に応じたポイント換算率を適用して、ポイント数の算出に用いられる。Ｇｐ０１が獲得した全陣地の特性項目ごとにポイント数が集計され、このようにして集計された特性項目ごとのポイント数が合算されて、Ｇｐ０１が獲得したポイント数合計が算出される。

前述のように本実施形態のアプリケーションサーバー４では、この陣取りソーシャルゲームの面白さを高めるために、ゲーム期間の途中における中間状態を、ゲーム参加者やゲーム観戦者に示すための各種の情報を生成し、ＰＣ４０、携帯電話４１、各マークポイントノード１（表示部１５、スピーカー１６）で確認可能とする。図８（ａ）に、あるマークポイントノード１で確認できる中間状態の表示例を示す。この表示画面では、当該マークポイントを頂点として含む閉ループＡ，Ｃそれぞれの各参加者の周回状況が表示されている。また図８（ｂ）は、マークポイントノード１で確認できる中間状態の別の表示例である。この画面は、マークポイントノード１がＲＦＩＤリーダライタで読み取った個人ＩＤに基づき、その個人（Ｐ００１１５）に向けたアドバイスを提示した例である。図８（ａ）や図８（ｂ）の画面を見ることで、ゲーム参加者は、誰が今リードしているのか、逆転するためにはどの閉ループを何周すべきか、といった戦略を立てることができる。このように、マークポイントノード１は、ゲーム参加者が、仮想世界で行うゲームと現実世界との間のリアルタイムな情報交換を行うゲートウェイとしての役割も担っている。

（災害時に備えた自動点検）
本実施形態のマークポイントノード１は、平常時においても、災害時での動作に必要な各機能の定期点検やスケジュールに従った点検を実施する。

すなわち、マークポイントノード１の各部がバッテリ１３から供給される電力で動作して、次の各事項が実行できることを確認する。
（１）ＲＦＩＤリーダライタ１７での移動体端末２との通信
（２）環境センサ１４からのセンシングデータの読み込み
（３）表示部１５へのメッセージの表示
（４）スピーカー１６での音声出力
（５）周辺のマークポイントノードとのアドホック無線通信での情報の送受信

ただし、上記（３）と（４）の点検項目は、周囲にその内容を確認可能な人が存在している場合に実行が可能である。内容確認した人は、図１には図示していないキーボード又はボタンを操作して、確認した内容の適否を示すデータを入力する。それ以外の点検項目（１）、（２）、（５）については、通信ができるかどうか、読み込みができるかどうかを自動的に確認する。その動作結果の評価については、仲介サーバー３もしくは不図示の管理サーバーに通知される。

このように、平常時モードにおいても所定のスケジュールで災害時モードの動作テストを自動で実施することで、災害時に必要な機能が適切に実行できる状態を維持できる。これにより、マークポイントノード１ならびにセンサネットワーク全体の信頼性を向上することができる。

＜システム全体構成（災害時）＞
図２は、本発明の実施形態に係るセンサネットワークシステムの全体構成と災害時の動作を模式的に示している。

災害時には、商用電源とインターネット、固定電話および携帯電話ネットワークがダウンすると想定する。その場合においても、災害現場の状態のセンシングと災害現場にいる人々の安否確認と災害現場にいる人へのメッセージ伝達の機能を実現することが必要である。そこで災害時には、マークポイントノード１が情報インフラあるいは情報ステーションとして機能し、上述した災害時に必要とされる各種のサービスを実現する。

マークポイントノード１は太陽光発電パネル１２とバッテリ１３を内蔵しているので、商用電源がダウンしても動作を継続することができる。平常時は無線ＬＡＮ子機１１がマークポイントノード設置施設（例：一般住宅）に設置済みの無線ＬＡＮルーター１００とモデム１０１経由でインターネットに接続していたが、災害時には無線ＬＡＮ子機１１はアドホック通信モードで動作し、隣接するマークポイントノード設置施設（例：一般住宅）内の他のマークポイントノード内の無線ＬＡＮ子機と通信を行って、無線通信ネットワークを形成する。

無線ＬＡＮ子機１１がアドホック通信モードにモード遷移をするためのイベントとしては、本来の通信相手方である無線ＬＡＮルーター１００が所定時間以上、応答しない場合がある。他には、常に毎時最初の１分間は一斉に各マークポイントノードの無線ＬＡＮ子機が一時的アドホック通信モードとなり、災害時対応処理の指令があるかどうかを確認し、災害時対応処理の指令を受信できたことをもって、アドホック通信モードとなるためのイベントとするという方法もある。

アドホック通信モードは、ＩＥＥＥ８０２．１１無線ＬＡＮの動作モードのひとつで、それぞれの端末に設置された無線ＬＡＮアダプタが、互いに直接通信をするものである。２つの無線ＬＡＮアダプタをアドホック通信モードで通信させるには、アダプタに設定するＥＳＳ−ＩＤ（Extended Service Set Identifier）を一致させておけば良い。

一時的アドホック通信モードで動作している際に、図２の設置施設Ｉ内のマークポイント親ノードが、通信衛星７および災害時通信局６を経由して、災害時対応サーバー５と通信する。そして、マークポイント親ノードが一時的アドホック通信モードが正常動作していることを通報するとともに、災害時対応処理の指令が、災害時対応サーバー５から来る
かどうかをチェックする。災害時対応処理の指令が来た場合は、マークポイント親ノードからアドホック無線通信ネットワークを通じてすべてのマークポイントノードに対し災害時モードへの切り替え命令が送出される。これにより各マークポイントノードはアドホック通信モードを維持するとともに、災害時モードでの動作を開始する。一方、災害時対応処理の指令が一定時間来なければ、一時的アドホック通信モードは終了し、図１に示す平常時の動作に移る。

災害時には、各マークポイントノードが環境センサ１４で周囲環境の状態をセンシングし、アドホック無線通信ネットワークを通じて、その地域を統括するマークポイント親ノードに対しセンシングデータを伝送する。これによりマークポイント親ノードに、その地域の現場の状況を示すセンシングデータが収集される。そして各地域のマークポイント親ノードで収集されたデータは、通信衛星７などの回線を通じて、災害時対応サーバー５に集約される。

このセンシングデータの一つとして、移動体端末２から読み取った歩数もしくは活動量のデータが使用できる。すなわち、災害時モードにおいても、ＲＦＩＤリーダライタ１７により移動体端末２から個人ＩＤと歩数もしくは活動量のデータを収集するのである。この個人データは、その個人の所在と活動状態を示す情報ゆえ、安否確認に利用することができる。移動体端末２からデータを読み取るときに、環境センサ１４の一つとして設置されている画像センサで本人の画像を取得して、この画像を個人ＩＤとマークポイントＩＤと一緒に、マークポイント親ノード経由で災害時対応サーバー５に安否確認用に送っても良い。

また、災害時対応サーバー５からの指令や情報を、通信衛星７⇒マークポイント親ノード⇒マークポイントノード１というルートで送って、マークポイントノード設置施設の周辺にいる人々に情報を伝達することもできる。情報の提示には、マークポイントノード１に装備している表示部１５とスピーカー１６を用いる。

（災害時対応サーバーの動作）
図９に基づいて、災害時対応サーバー５の動作をさらに詳しく説明する。

災害時対応サーバー５（以下、Ｓサーバー５という）は、災害時通信局６を経由して、各マークポイント親ノードおよび各マークポイントノードと通信を行うための対マークポイントノード通信機能５０と、各マークポイントノードから収集した情報を管理するマークポイントノード管理機能５１とを有している。マークポイントノード管理機能５１は、各マークポイントノード１から収集した災害対応の基礎となる情報を、「マークポイントノード別の個人情報のデータベース」という第１のデータベース５２と、「マークポイントノード別のセンシングデータのデータベース」という第２のデータベース５３に記録する。

これらの２つのデータベース５２，５３は、概略として次の情報を管理する。すなわち、第１のデータベース５２に入るものは、マークポイントノード１ごとに、その周囲に存在している人のＩＤと活動量のデータを含む個人情報のリストである。ＩＤと活動量は各人が保有する移動体端末２から取得する。すなわち、平常時には陣取りソーシャルゲームに参加する目的や健康増進の目的に使っていたこの移動体端末２を、災害時には個人のＩＤと位置と活動量を発信する安否確認の目的に転用するというものである。

第１のデータベース５２に集約された情報は、各マークポイントノード１の周囲にいる人の人数と各人の安否状態を示しているし、ＩＤから各人を特定できるので、その人の能力や関係者の連絡先なども把握でき、災害状況マップの作成において有益である。

第２のデータベース５３は、マークポイントノード１ごとの環境状態を示すデータを災害時通信局６を通じて収集したものを保管するデータベースである。これには、各マークポイントノード１の環境センサ１４（例：温度センサ、ガスセンサ、地震センサ、画像センサ）で収集したデータが、マークポイントノード１のＩＤまたはマークポイントノードの位置情報および時刻データと対応付けて保存される。

Ｓサーバー５は、第１のデータベース５２を処理して、対個人の通信用の「個人ＩＤとネットワークＩＤの対応テーブル」を作成する。すなわち、各個人のＩＤを、その個人が属しているマークポイントノードのＩＰアドレスに対応付けたテーブル（以下、対応テーブル５４という）を作成する。この対応テーブル５４は、そのマークポイントノード１を経由して他のノードなどと通信するためのルーティングテーブルの一部を構成する。すなわち、個人ＩＤをあて先にした通信は、その個人ＩＤの人が属するマークポイントノード１のＩＤを経由ノードにした通信となる。個人ＩＤをあて先とする各種のメッセージは、「対個人の安否確認、所在追跡、メッセージ送信機能」５５で生成、送信される。

個人ＩＤをあて先とするメッセージをマークポイントノード１が受信すると、そのメッセージはマークポイントノード１の記憶部にとりあえず保管される。そして、マークポイントノード１が、保管しているメッセージに付された宛先ＩＤと同じ個人ＩＤをＲＦＩＤリーダライタ１７で読み取った時点で、マークポイントノード１からその人への情報伝達が実行される。例えば、「○○さんへのお知らせがあります。」という通知を表示部１５またはスピーカー１６から出力した後、保管していたメッセージを表示部１５またはスピーカー１６から出力することができる。あるいは、保管していたメッセージをＲＦＩＤリーダライタ１７から移動体端末２に送り、移動体端末２上でメッセージを再生できるようにしてもよい。

さらに、各個人は、移動体端末２もしくはマークポイントノード１を用いて、情報の発信や返信を行うこともできる。例えば、移動体端末２の上で宛先を指定した簡単なメッセージを作成し、マークポイントノード１のＲＦＩＤリーダライタ１７にかざすと、移動体端末２から個人ＩＤ、歩数もしくは活動量のデータ、宛先付きの簡単なメッセージが読み取られる。またマークポイントノード１を用いて情報発信を行う場合は、マークポイントノード１に移動体端末２をかざして個人ＩＤを読み取らせた後、キーボード等のＭＭＩ手段を利用してメッセージや宛先の入力を行えばよい。

マークポイントノード１からの送信メッセージの通信パケットは、隣接するマークポイントノードの間で形成しているアドホック無線通信ネットワークを通じて、マークポイント親ノードに集約される。そして、そのマークポイント親ノードから通信衛星７経由で、災害時通信局６に伝達され、そこからＳサーバー５に伝送される。

また、「対個人の安否確認、所在追跡、メッセージ送信機能」５５は、第１のデータベース５２に集約された情報や、ＭＭＩ機能５６で入力された情報に基づき、各人の安否確認や所在追跡を行ったり、各種メッセージの生成・送信を行うこともできる。

さらに、災害状況マップ作成機能５７は、第１のデータベース５２、第２のデータベース５３、地図情報ＤＢ５８を用いて、災害状況マップを作成する。具体的には、災害状況マップ作成機能５７は、地図情報ＤＢ５８から読み込んだ地図データの上に、各マークポイントノード１の位置、各マークポイントノード１の周囲環境の状況、各マークポイントノード１の周辺に存在する人の数と各人の状況を記述したデータを作成する。このようにして作成された災害状況マップは、災害状況マップの配信機能５９により、対マークポイントノード通信機能５０を経由して、各マークポイントノードに配信される。

さらに、ユーザが「避難先と避難経路の設定機能」６０とＭＭＩ機能５６を用いて、災害状況マップを参照しながら、避難先や避難経路を設定することもできる。設定された避難先と避難経路は、対マークポイントノード通信機能５０を経由して、各マークポイントノード１に配信することもできるし、ラジオ放送設備６１を用いて放送することもできる。このラジオ放送は、マークポイントノード１のラジオ受信機１８で受信し、スピーカー１６から再生することもできるし、移動体端末２がラジオ機能を内蔵しておれば各個人が聞くこともできる。

＜仲介サーバーの構成＞
次に、図１０を用いて、仲介サーバー３の構成を詳しく説明する。図１０は仲介サーバー３の機能構成の概略を示す機能ブロック図である。

仲介サーバー３は、前述のように、マークポイントノード１を設置しそこで得られたセンシングデータを提供する者（提供者）と、アプリケーションサーバー４を運用しセンシングデータの利用を行う者（利用者）との間の、センシングデータの取引・売買を仲介する機能を担うサーバーである。センシングデータの提供者は、自分が提供するデータの利用率を高めたいと望む一方で、それが意図しない者に勝手に使われたり、意図しない使われ方をしたりして、自らの利益が害されることは避けたい。一方、センシングデータの利用者は、自分の希望に合致する仕様のセンシングデータをできるだけ低コストで利用できることを希望する。したがって、センシングデータの流通を実現するには、提供者と利用者の間での、センシングデータの取引にかかわる契約条件や法律関係をクリアにする枠組みが必要となる。本実施形態のシステムでは、提供者と利用者のマッチングを仲介サーバー３が自動で行うことで、センシングデータの健全かつ安全な利用を実現している。

仲介サーバー３は、図１０に示すように、契約マッチング処理部３０、センシングデータ提供契約データベース３１、センシングデータ利用契約データベース３２、センシングデータ配信制御部３３、センシングデータ処理制御部３４、実センサからのセンシングデータ取得処理部３５、センシングデータデータベース３６、仮想センサの管理データデータベース３７、配信ログデータベース３８、対価精算処理部３９を有する。これらの機能は、仲介サーバー３の補助記憶装置に格納された仲介プログラムを仲介サーバー３のＣＰＵが実行することで実現されるものである。以下、各機能について順に説明する。

（契約マッチング処理）
図１１に契約マッチング処理部３０の機能構成を示し、図１２に契約マッチング処理部３０における契約マッチング処理のフローチャートを示す。

契約マッチング処理部３０は、定期的に図１２の契約マッチング処理を実行する。なお契約マッチング処理の実行周期は、数秒から数分に一回でもよいし、数十分から数時間に一回のように設定することもできる。センサネットワークの用途や契約者などに応じて適宜設定すればよい。

まず契約マッチング処理部３０は、利用契約読み出しカウンタｋと、ｋ番目のマッチングリストを初期化する（Ｓ３００）。次に、利用契約の読み出し処理部３０２が、センシングデータ利用契約データベース３２から、ｋ番目の契約データを読み出し（Ｓ３０１）、その契約データの利用条件を調べることで当該利用者が現時点においてセンシングデータの利用を必要としているかどうかを判断する（Ｓ３０３）。例えば利用者が毎週土曜日の朝１０時の渋滞情報の取得を希望をしている場合には、土曜日の当該時刻以外の場合はＳ３０３においてＮＯ判定されることとなる。

図１３（ｂ）はセンシングデータ利用契約データベース３２に格納されている利用条件の契約データの一例である。契約データは、利用者番号、ＩＰアドレス、契約番号、センシング種別、センシングエリアの位置、センシング周期、センシングデータの信頼度、センシングデータの対価、センシングデータの使用可能アプリの範囲などの項目で構成されている。ＩＰアドレスは、利用者のアプリケーションサーバーのネットワークアドレスである。この利用者「ＵＳＥＲ００２」は、京福嵐山駅の近辺に設置されたノード（センサ）から、２００秒以内の周期で８０％以上の高信頼度で計測される、人の位置・時刻・ＩＤのセンシングデータを希望している。またその対価としては、センシングデータ１件につき１５０円まで可能であること、センシングデータの利用範囲は、人の見守りと陣取りゲームに限定する旨、定めている。

Ｓ３０３においてセンシングデータの利用を必要としている利用契約が見つかった場合は、提供契約の読み出し処理部３０１が、提供契約読み出しカウンタｕを初期化し（Ｓ３０５）、センシングデータ提供契約データベース３１から、ｕ番目の契約データを読み出す（Ｓ３０６）。図１３（ａ）は、センシングデータ提供契約データベース３１に格納されている提供条件の契約データの一例である。提供条件の契約データの項目は、先に述べた利用条件の契約データの項目と同じであるため、説明を割愛する。

次に、契約項目の一致判定処理部３０３が、ｋ番目の利用契約の各項目とｕ番目の提供契約の各項目とを比較し、すべての項目の値（条件）が合致するかどうかを判断する（Ｓ３０８）。図１３（ａ）と図１３（ｂ）の例を比較すると、両者の条件はマッチしていることが分かる。すべての項目がマッチしていた場合は、マッチングリストの作成処理部３０４が、契約番号ｕをｋ番目のマッチングリストに追加する（Ｓ３０９）。Ｓ３０６〜Ｓ３０９の処理は、センシングデータ提供契約データベース３１内に格納されているすべての提供契約について繰り返される（Ｓ３１０、Ｓ３０７）。

すべての提供契約についてｋ番目の利用契約とのマッチ／非マッチが確認されたら、提供契約の選択部３０５が、ｋ番目のマッチングリストのなかに契約番号が１つ以上記述されているかどうかを確認する（Ｓ３１１）。１つも契約番号がない場合、ｋ番目の利用契約にマッチする提供契約がないということなので、ｋ番目の利用契約を提示した利用者へのセンシングデータの提供は行われない。一方、マッチングリストのなかに１つ以上契約番号が記述されていた場合には、提供契約の選択部３０５が、それらの提供契約のなかで対価が最小の提供契約を選択する（Ｓ３０５）。このように対価最小ルールで提供契約を選択することで、利用者の利益を尊重できるとともに、センシングデータの対価の適正を図ることもできる。

以上の処理を、すべての利用契約について実行した後、契約マッチング処理を終了する（Ｓ３０４、Ｓ３０２）。その後、取得元アドレス検出部３０６が、対価最小の提供契約データからセンシングデータの取得元アドレス（図１３（ａ）の例ではＩＰアドレス）を読み出し、これをセンシングデータ配信制御部３３に引き渡す。同様に、センサ番号検出部３０７が、対価最小の提供契約データからセンサ番号を読み出し、これをセンシングデータ配信制御部３３に引き渡す。なお、センシングデータの取得元が、実センサではなく、後述する仮想センサの場合には、センサ番号のみで特定することとなるため、取得元アドレスには仮のアドレス（例えば「０．０．０．０」など）が設定されている。取得元が実センサか仮想センサかは、センサ番号の範囲で判断することもできるし、提供契約データのなかに正当なＩＰアドレスが記述されているかどうかでも判断できる。さらに、提供先アドレス検出部３０８は、利用契約データから利用者のＩＰアドレスを読み出し、これを提供先アドレスとしてセンシングデータ配信制御部３３に引き渡す。

（センシングデータ配信制御）
図１４にセンシングデータ配信制御部３３の機能構成を示し、図１５にセンシングデータ配信制御部３３におけるセンシングデータ配信制御のフローチャートを示す。

センシングデータ配信制御部３３は、契約マッチング処理部３０から、契約条件がマッチしたセンシングデータ取引に関するデータ（具体的には、取得元アドレス、センサ番号、提供先アドレス）を受け取るのを待つ（Ｓ４００）。データを受け取ったら、取得元アドレスは取得元アドレス記憶部３３０に、センサ番号はセンサ番号記憶部３３１に、提供先アドレスは提供先アドレス記憶部３３２に、それぞれ格納する。

センシングデータ受信部３３３は、取得元アドレスとセンサ番号をセンシングデータ処理制御部３４に引き渡して、それに対応するセンサによる最新のセンシングデータを要求し（Ｓ４０１）、センシングデータ処理制御部３４から要求したセンシングデータを受け取るのを待つ（Ｓ４０２）。

その後、センシングデータ送信部３３４が、受け取ったセンシングデータを、提供先アドレスに対して送信する（Ｓ４０３）。そして、配信記録部３３５が、配信ログデータベース３８に対して、センシングデータの種類、センサ番号、提供先アドレス、取得元アドレス、送信日時を記録する（Ｓ４０４）。これにより、どのセンサから得たどのような種類のセンシングデータをいつ、どの提供先アドレスの利用者に提供したか、というログが残る。

（センシングデータ処理制御）
図１６にセンシングデータ処理制御部３４の機能構成を示し、図１７にセンシングデータ処理制御部３４におけるセンシングデータ処理制御のフローチャートを示す。

センシングデータ処理制御部３４は、センシングデータ配信制御部３３から、センシングデータの要求を受け取るのを待つ（Ｓ５００）。要求を受け取ったら、センサ種別判定部３４０が、センサ番号と取得元アドレスに基づき、当該センサが実センサであるか仮想センサであるかを判定する（Ｓ５０１）。実センサとはマークポイントノードとして設置されているセンサのことであり、図１０ではＲ１からＲｎまでｎ個の実センサが設けられている。一方、仮想センサとは、１つまたは複数の実センサから得られたセンシングデータを加工して出力するモジュールであり、基本的にはコンピュータプログラムで実現されるものである。現実世界に設置される実センサと区別するため仮想センサと呼ぶが、センシングデータの取扱いは、実センサであると仮想センサであると変わるところはない。

要求のあったセンシングデータが実センサのものである場合には（Ｓ５０１；ＮＯ）、センシングデータ読み出し部３４１がセンシングデータＤＢ３６から当該センサ番号もしくは取得元アドレスで特定されるセンサの最新のセンシングデータを読み取り、そのデータをセンシングデータ配信制御部３３に引き渡す（Ｓ５０２）。

一方、要求のあったセンシングデータが仮想センサのものである場合には（Ｓ５０１；ＹＥＳ）、仮想センサ管理データ読み出し部３４２が、仮想センサの管理データＤＢ３７から、当該センサ番号に対応する仮想センサ管理データを読み取る。仮想センサ管理データとは、仮想センサのセンシングデータを生成するのに利用される下位のセンサのリストと、下位のセンサのセンシングデータをどのように加工処理するか（処理方式）の定義が記述されたものである。図１８（ａ）、（ｂ）は仮想センサの管理データの一例を示している。図８（ａ）の例は、仮想センサＶＳ００１は、実センサＲ００２と実センサＲ００４のセンシングデータを用いて、信頼性データ付きのセンシングデータを生成するということが定義されている。また図８（ｂ）の例は、仮想センサＶＳ００４は、仮想センサＶＳ００１と仮想センサＶＳ００３のセンシングデータを用いて、条件判断付きセンシング
を行うことが定義されている。仮想センサ管理データ読み出し部３４３は、このようにして得た下位センサ番号をセンシングデータ読み出し部３４１に引き渡す。なお、図８（ｂ）のように下位センサも仮想センサである場合には、実センサのセンサ番号が得られるまで再帰的に処理を繰り返せばよい。

センシングデータ読み出し部３４１は、指定された下位センサそれぞれの最新のセンシングデータをセンシングデータＤＢ３６から順次読み出し、センシングデータバッファ３４３に格納する（Ｓ５０４）。すべての下位センサのセンシングデータが読み出されたら、センシングデータ加工処理部３４４が、仮想センサ管理データに定義されている加工処理を下位センサのセンシングデータに対し適用することで、加工されたセンシングデータを得る（Ｓ５０５）。この加工されたセンシングデータが、仮想センサのセンシングデータとして、センシングデータ配信制御部３３に引き渡される。

（仮想センサの例）
以下、仮想センサの具体例をいくつか説明する。

（１）差分処理
差分処理とは、同じセンシング対象から測定された時間差のある観測値の差分をとって、その変化率を得る処理方式である。位置ｐ１に設置されているセンサｓ１で時刻ｔ１に測定値ｍ１が測定され、その後、同じＩＤをもつセンシング対象から、位置ｐ２に設置されているセンサｓ２で時刻ｔ２に測定値ｍ２が測定されたと仮定する。

差分処理で得られるセンシングデータとしては、例えば、
速度ベクトル＝（ｐ２−ｐ１）／（ｔ２−ｔ１）
測定値の時間変化率＝（ｍ２−ｍ１）／（ｔ２−ｔ１）
測定値の空間変化率＝（ｍ２−ｍ１）／（ｐ２−ｐ１）
などが考えられる。

（２）平均検出処理
平均検出処理とは、同じセンシング対象からほぼ同じ位置・時刻で測定された観測値の平均を計算する処理方式である。ＳＮ比を向上してセンシングデータの信頼性を上げるために利用される。位置ｐ１に設置されているセンサｓ１で時刻ｔ１に測定値ｍ１が測定され、同じＩＤをもつセンシング対象から、位置ｐ２に設置されているセンサｓ２で時刻ｔ２に測定値ｍ２が測定されたと仮定する。ただし、｜ｐ２−ｐ１｜＜δｐ、かつ、｜ｔ２−ｔ１｜＜δｔを満たし、両者の位置、時刻はほぼ同じとみなせるとする。この場合、平均検出処理で得られるセンシングデータとしては、例えば、
測定値の平均値＝（ｍ１＋ｍ２）／２
などが考えられる。なお、単純平均ではなく、重み付き平均など他の平均処理を適用してもよい。

（３）信頼性データ付きのセンシングデータ生成
この処理は、同じセンシング対象から測定された複数の観測値に基づき、観測値の信頼性を計算し、その信頼性データを観測値と一緒に出力するというものである。ここでは、センシング対象領域の関係モデルと一致する関係のセンシングデータは信頼性が高いという仮定の下、以下の方法で信頼性データを計算する。

２つのセンサｓ１、ｓ２でそれぞれ測定値Ａ１（ｒ，ｔ）、Ａ２（ｒ，ｔ）が得られたとする。各センサからの出力Ａ１とＡ２の相互相関関数を次のようにする。
Ｓ（α，β）＝∬Ａ１（ｒ，ｔ）・Ａ２（ｒ−α，ｔ−β）ｄｒｄｔ
そして、Ｓの最大値であるＳ＊と、その際のαとβの組である（α＊，β＊）を得る。（
α＊，β＊）が、センサｓ１とセンサｓ２のセンシング対象領域の関係モデル（αＭ，βＭ）と許容誤差内で一致していて、かつ、Ｓ＊が閾値ＴＨＭ以上であれば、Ａ１とＡ２を信頼性の高いセンシングデータとして出力する。

（４）複数のセンシングデータの条件判断付き処理
この処理は、同じセンシング対象から測定された異なる属性に関するセンシングデータを用いて条件判断をすることで、高度な判断結果を出力可能なセンサを実現するというものである。

２つのセンサｓ１、ｓ２でそれぞれ測定値Ａ（ｒ，ｔ）、Ｂ（ｒ，ｔ）が得られたとする。このとき、例えば、以下のような条件判断処理により値Ｓを求め、仮想センサのセンシングデータとして値Ｓを出力する。
ＩＦ Ｃｏｎｄｉｔｉｏｎ１（Ａ（ｒ，ｔ））＆Ｃｏｎｄｉｔｉｏｎ２（Ｂ（ｒ，ｔ））
ＴＨＥＮ Ｓ＝Ｔｒｕｅ
ＥＬＳＥ Ｓ＝Ｆａｌｓｅ
この条件判断処理は、測定値ＡとＢがいずれも所定の条件を満足した場合には、センシングデータとしてＴｒｕｅを出力し、それ以外の場合にはＦａｌｓｅを出力する、というものである。

（対価精算処理）
図１９に対価精算処理部３９の機能構成を示す。対価精算処理部３９は、配信ログデータベース３８に記録されたセンシングデータ取引のログに基づいて、センシングデータ利用者に対する対価請求処理と、センシングデータ提供者に対する対価支払処理とを行う機能である。

具体的には、提供者別の配信ログ作成処理部３９０が、配信ログデータベース３８から未清算の配信ログを読み込み、そのログを提供別に仕分けして提供者別配信ログを生成する。提供契約読み取り部３９１は、センシングデータ提供契約データベース３１から各提供者の提供契約データを読み取る。そして、提供者別の対価計算処理部３９２が、提供者別配信ログから当該提供者が配信を行ったセンシングデータの件数を求め、その件数に提供契約に定められているセンシングデータの対価を乗じることで、対価の総額を計算する。提供者別の対価データは不図示の決済機関に送信され、各提供者に対価の支払いが行われる。

一方、利用者への対価請求に関しては、まず利用者別の受信ログ作成処理部３９３が、配信ログデータベース３８から未清算の配信ログを読み込み、そのログを利用者別に仕分けして利用者別受信ログを生成する。利用契約読み取り部３９４は、センシングデータ利用契約データベース３２から各利用者の利用契約データを読み取る。利用者別の請求金額計算処理部３９５は、利用者別受信ログ、提供者別対価データ、および、利用契約に基づいて、各利用者に対する請求総額を計算する。利用者別の請求金額データは不図示の決済機関に送信され、各利用者に対価の請求が行われる。

（実センサからのセンシングデータ取得処理部）
図２０に実センサからのセンシングデータ取得処理部３５の機能構成を示す。実センサからのセンシングデータ取得処理部３５は、図１０に示す実センサＲ１〜Ｒｎから定期的にセンシングデータを収集する機能である。また、センシングデータ処理制御部３４からセンサ番号や取得元アドレスを指定して最新のセンシングデータの取得要求があった場合にも、該当する実センサからデータ取得が行われる。

仲介サーバー３には多数の実センサ（ノード）が登録されているが、センサの種類ごとあるいは機種ごとに、データ取得の方法やデータ仕様（データ構造）が異なる場合がある。そこで、センサ管理情報データベース３５０には、データ取得の方法、データ仕様などの他、センサ別の固有の情報が登録されている。なお新たにセンサを登録する場合には、センサ管理情報設定部３５１の機能を利用して管理者がこれらの情報を入力することとなる。

例えば、センサ番号や取得元アドレスを指定してのデータ取得要求があると、センサ管理情報読み出し部３５２が、当該センサの情報をセンサ管理情報データベース３５０から読み出す。そして、センサ管理情報読み出し部３５２は、当該センサの取得元アドレスをアドレス設定部３５３へ、当該センサとの通信に使われるプロトコルの情報をプロトコル制御部３５４へ、当該センサから取得されるデータの仕様をデータ変換部３５６へ、それぞれ引き渡す。センサーアクセス実行部３５５はプロトコル制御部３５４の制御の下、アドレス設定部３５３から指定されたアドレスのセンサ（ノード）に対して、センシングデータの要求を送信する。これに応答してセンシングデータが送られてくると、データ変換部３５６がセンシングデータに所定のデータ変換を適用し、仲介サーバー３あるいはセンシングデータの利用者において取り扱いがしやすい形式のデータを得る。得られたセンシングデータはセンシングデータＤＢ３６に格納される。

＜本実施形態の利点＞
以上述べた本実施形態の構成によれば、次のような利点がある。すなわち、マークポイントノードを平常時モードと災害時モードを含む複数のモードで動作可能としたことで、ノードの利用機会および付加価値を高めることができるため、結果としてノードの設置導入に関するコスト対効果を高めることができる。よって、一般住宅や店舗などへのノードの設置が促進され、センサネットワークの普及・拡充を図ることが期待できる。

また、自然エネルギーによる発電を行う電源を内蔵し、または、利用する機能をマークポイントノードに設けたことにより、停電などの原因で商用電源が使用できなくなった状況下でもノードの稼働を維持できるため、ノードならびにセンサネットワーク全体の可用性・信頼性を向上することができる。

また、災害時には、各ノードが周囲に存在する他のノードとアドホック無線通信ネットワークを形成して各種情報の送受信を行うので、停電や断線などの原因で公衆通信ネットワークが使用できなくなった状況下でも、各ノードから情報を取得したり、各ノードへ情報を配信したりすることができ、災害時の情報インフラや情報ステーションとして活用することができる。さらに、平常時モードにおいても所定のスケジュールで災害時モードの動作テストを自動で実施することで、災害時に必要な機能が適切に実行できる状態を維持できる。これもノードならびにセンサネットワーク全体の信頼性向上に寄与する。

また、本実施形態では、マークポイントノードをゲームに活用することで、ノードの平常時における利用機会および付加価値を一層高めることができる。各ノードは異なる地点に物理的に設置されているものゆえ、ゲーム参加者を現実世界の中で実際に移動させて競わせるといった、競技性の高いゲームや面白いゲームを作るのが容易である。特に本実施形態で例示した陣取りソーシャルゲームにあっては、多くの人が参加するゲームを通じて、その地域の様々な道や店舗へ参加者を積極的に導くことができるので、地域の活性化や町おこしなどの効果を期待できる。また参加者に対しても、歩行を通じた健康促進の効果に加え、現実世界を使ったアトラクション的なゲーム体験を提供することができる。

また、本実施形態では、仲介サーバーを使ってデータ提供者とデータ利用者の間を自動的に仲介するようにしたので、センシングデータの健全かつ安全な利用を実現することが
できる。

１：マークポイントノード（無線通信ノード）
２：移動体端末
３：仲介サーバー（仲介装置）
４：アプリケーションサーバー（ゲーム実行装置）
５：災害時対応サーバー

Claims (2)

1. センシングデータの提供者が希望する契約条件とセンシングデータの利用者が希望する契約条件とのマッチングに用いるための、提供者の契約条件を定義した提供契約データのデータ構造であって、
   センサを特定するためのセンサ番号を表すデータと、
   前記センサのアドレスを表すデータと、
   契約番号を表すデータと、
   前記センサにより得られるセンシングデータの種別を表すデータと、
   前記センサによるセンシングエリアの位置を表すデータと、
   前記センサのセンシング周期を表すデータと、
   前記センサにより得られるセンシングデータの信頼度を表すデータと、
   センシングデータの対価を表すデータと、
   センシングデータの利用範囲を表すデータと、
   を含むことを特徴とする、センシングデータの提供契約データのデータ構造。
2. センシングデータの提供者が希望する契約条件とセンシングデータの利用者が希望する契約条件とのマッチングに用いるための、利用者の契約条件を定義した利用契約データのデータ構造であって、
   利用者を特定するための利用者番号を表すデータと、
   センシングデータの提供先のアドレスを表すデータと、
   契約番号を表すデータと、
   希望するセンシングデータの種別を表すデータと、
   希望するセンシングエリアの位置を表すデータと、
   希望するセンシング周期を表すデータと、
   希望するセンシングデータの信頼度を表すデータと、
   希望するセンシングデータの対価を表すデータと、
   センシングデータの利用範囲を表すデータと、
   を含むことを特徴とする、センシングデータの利用契約データのデータ構造。

Images