IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ イネーブラー株式会社の特許一覧

特開2024-62672データ収集・分析システム及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024062672
(43)【公開日】2024-05-10
(54)【発明の名称】データ収集・分析システム及びプログラム
(51)【国際特許分類】
   G06F 16/901 20190101AFI20240501BHJP
   G08C 15/00 20060101ALI20240501BHJP
   G08C 15/06 20060101ALI20240501BHJP
   G16Y 40/20 20200101ALI20240501BHJP
   G06F 16/909 20190101ALI20240501BHJP
【FI】
G06F16/901
G08C15/00 E
G08C15/06 H
G16Y40/20
G06F16/909
【審査請求】未請求
【請求項の数】8
【出願形態】OL
(21)【出願番号】P 2022170668
(22)【出願日】2022-10-25
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
(71)【出願人】
【識別番号】516003171
【氏名又は名称】イネーブラー株式会社
(74)【代理人】
【識別番号】100092783
【弁理士】
【氏名又は名称】小林 浩
(74)【代理人】
【識別番号】100136744
【弁理士】
【氏名又は名称】中村 佳正
(72)【発明者】
【氏名】杉井 靖典
(72)【発明者】
【氏名】篠原 隆浩
(72)【発明者】
【氏名】松坂 要佐
【テーマコード(参考)】
2F073
5B175
【Fターム(参考)】
2F073AA01
2F073AA02
2F073AA03
2F073AA19
2F073AA21
2F073AB01
2F073AB05
2F073BB01
2F073BB07
2F073BB09
2F073BC01
2F073BC02
2F073CC03
2F073CC09
2F073CC12
2F073CC14
2F073CD17
2F073DD07
2F073DE06
2F073DE13
2F073DE17
2F073EF08
2F073EF09
2F073FF01
2F073FG01
2F073FG02
2F073GG01
2F073GG06
2F073GG08
2F073GG09
5B175FB02
5B175FB03
(57)【要約】
【課題】 異なる多種多様なセンサから収集したデータの横断的検索を容易にする。
【解決手段】 1以上のセンサから送信されるセンサデータを集約するゲートウェイと、ゲートウェイを通過したデータを集積するデジタルエビデンスプラットフォームとを備えるデータ収集・分析システムであって、ゲートウェイは、集約したセンサデータに時空タグを付与し、時空タグを付与した1次データをブロックデータとしてデジタルエビデンスプラットフォームに送信し、デジタルエビデンスプラットフォームは、ゲートウェイから送信されたブロックデータを保存し、ブロックデータに含まれるセンサの種類ごとに分割した2次データ(エンティティデータ)を生成し、2次データに対してスキーマを使って意味づけされた3次データ(セマンティクスデータ)を生成し、2次データ及び3次データを検索可能なインデックスを生成することを特徴とする。
【選択図】 図1
【特許請求の範囲】
【請求項1】
1以上のセンサから送信されるセンサデータを集約するゲートウェイと、
前記ゲートウェイを通過したデータを集積するデジタルエビデンスプラットフォームと
を備えるデータ収集・分析システムであって、
前記ゲートウェイは、
集約した前記センサデータに時空タグを付与し、前記時空タグを付与した1次データをブロックデータとして前記デジタルエビデンスプラットフォームに送信し、
前記デジタルエビデンスプラットフォームは、前記ゲートウェイから送信された前記ブロックデータを保存し、
前記ブロックデータに含まれる前記センサの種類ごとに分割した2次データ(エンティティデータ)を生成し、
前記2次データ(エンティティデータ)に対してスキーマを使って意味づけされた3次データ(セマンティクスデータ)を生成し、
前記2次データ(エンティティデータ)及び前記意味づけされた3次データ(セマンティクスデータ)を横断的に検索可能なインデックスを生成する
ことを特徴とするシステム。
【請求項2】
前記デジタルエビデンスプラットフォームは、さらに、
前記3次データ(セマンティクスデータ)について、有効数字を考慮した単位の相互変換が可能となる4次データ(コンバーチブルデータ)を生成し、
前記4次データ(コンバーチブルデータ)を横断的に検索可能なインデックスを生成する
を行うことを特徴とする請求項1に記載のシステム。
【請求項3】
前記デジタルエビデンスプラットフォームに保存された前記1次データ~前記4次データは、SDKによって機能提供され、
前記提供される機能においては、
時空検索ができ、かつ、
前記時空検索の結果は、エンティティとして得られる
ことを特徴とする請求項2に記載のシステム。
【請求項4】
前記検索結果である前記エンティティにはURI含まれ、前記URIから前記1次データ~4次データの各階層の証跡を辿ることができる
ことを特徴とする請求項3に記載のシステム。
【請求項5】
1以上のセンサから送信されるセンサデータを集約するゲートウェイと、前記ゲートウェイを通過したデータを集積するデジタルエビデンスプラットフォームとを備えるデータ収集・分析システム上で動作するコンピュータプログラムであって、
前記ゲートウェイに、
集約した前記センサデータに時空タグを付与させ、前記時空タグを付与した1次データをブロックデータとして前記デジタルエビデンスプラットフォームに送信させるステップと、
前記デジタルエビデンスプラットフォームに、前記ゲートウェイから送信された前記ブロックデータを保存させるステップと、
前記ブロックデータに含まれる前記センサの種類ごとに分割した2次データ(エンティティデータ)を生成させるステップと、
前記2次データ(エンティティデータ)に対してスキーマを使って意味づけされた3次データ(セマンティクスデータ)を生成させるステップと、
前記2次データ(エンティティデータ)及び前記意味づけされた3次データ(セマンティクスデータ)を横断的に検索可能なインデックスを生成させるステップと
実行することを特徴とするプログラム。
【請求項6】
前記デジタルエビデンスプラットフォームに、さらに、
前記3次データ(セマンティクスデータ)について、有効数字を考慮した単位の相互変換が可能となる4次データ(コンバーチブルデータ)を生成させるステップと、
前記4次データ(コンバーチブルデータ)を横断的に検索可能なインデックスを生成させるステップと
を実行することを特徴とする請求項5に記載のプログラム。
【請求項7】
前記デジタルエビデンスプラットフォームに保存された前記1次データ~前記4次データは、SDKによって機能提供され、
前記提供される機能においては、
時空検索ができ、かつ、
前記時空検索の結果は、エンティティとして得られる
ことを特徴とする請求項6に記載のプログラム。
【請求項8】
前記検索結果である前記エンティティにはURI含まれ、前記URIから前記1次データ~4次データの各階層の証跡を辿ることができる
ことを特徴とする請求項7に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、広くデータを収集し分析するシステム等に関し、より詳細には、IoTセンサなどから収集したデータを収集し、分析するシステム等に関する。
【背景技術】
【0002】
従来、全ての物がインターネットに接続されるIoT(Internet of Things)社会が到来するとの想定のもと、ネットワークに接続された各種センサから多種多量のデータを収集し、収集したデータを解析して有益な情報を引き出すための様々な取り組みがなされてきた。これらの取り組みにおいては、時刻同期の問題を含め、種々の課題と向き合ってきた。
【0003】
たとえば、センサの演算性能とクロックの精度が悪い場合でも、各センサから送信されるセンサデータの正確な時刻同期をとることができるセンシングシステム及び時刻同期方法が提案されている(特許文献1)。
【0004】
すなわち、特許文献1には、センサデータを送信するように構成された1つ以上のセンサと、前記センサデータを上位装置へ送信するように構成されたデータ収集端末親機と、前記センサと前記データ収集端末親機との間で前記センサデータの中継を行うように構成されたデータ収集端末子機とを備え、前記センサは、時間を計測するように構成された第1の時計部と、前記センサデータを送信するときに、前記第1の時計部の時刻情報を基にデータ送信時刻を示すタイムスタンプを前記センサデータに付与するように構成されたタイムスタンプ付与部と、前記データ収集端末親機から前記データ収集端末子機を介してダミーパケットを受信したときに、返送パケットを生成し、前記第1の時計部の時刻情報を基に前記ダミーパケットの受信時刻を示すタイムスタンプと前記返送パケットの送信時刻を示すタイムスタンプとを前記返送パケットに付与するように構成された返送パケット生成部と、前記タイムスタンプ付与部によってタイムスタンプが付与されたセンサデータおよび前記返送パケット生成部によってタイムスタンプが付与された返送パケットを前記データ収集端末子機に送信するように構成された第1の通信処理部とを備え、前記データ収集端末親機は、時間を計測するように構成された第2の時計部と、時刻同期処理を行う際に、前記ダミーパケットを前記センサに送信するように構成されたダミーパケット送信部と、前記返送パケットを受信したときに、前記第2の時計部の時刻情報から取得した前記ダミーパケットの送信時刻および前記返送パケットの受信時刻と、前記返送パケットのタイムスタンプから取得した前記ダミーパケットの受信時刻および前記返送パケットの送信時刻とから、前記データ収集端末親機と前記センサの同期ずれ時間および前記データ収集端末親機と前記センサ間の伝搬遅延時間を算出するように構成された時間算出部と、前記センサデータを受信したときに、このセンサデータのタイムスタンプから取得したデータ送信時刻と、前記同期ずれ時間および前記伝搬遅延時間とから、補正されたデータ送信時刻を算出するように構成された補正時刻算出部と、この補正時刻算出部の算出結果を基に前記センサデータのタイムスタンプを補正するように構成されたタイムスタンプ補正部と、このタイムスタンプ補正部によってタイムスタンプが補正されたセンサデータを上位装置に転送するように構成された第2の通信処理部とを備えることを特徴とするセンシングシステムが開示されている。
【0005】
また、精度とコストとのトレードオフの問題を克服した時系列データ収集・分析支援システム等も提案されている(特許文献2)。
【0006】
すなわち、特許文献2には、GNSS信号を受信できないIoT端末に対してiPNTからの時刻情報及び位置情報(空間情報)を提供し、前記IoT端末から送信されるデータを時系列データとして収集し、前記時系列データの分析を支援するシステムあって、前記iPNTからの時刻情報及び位置情報(空間情報)を管理し、前記システムと同期をとっている無線通信端末のうちの親端末に対し、前記管理している前記iPNTの時刻情報及び位置情報(空間情報)を提供することを特徴とするシステム等が開示されている。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】WO2018/123857
【特許文献2】特開2021-068297
【発明の概要】
【発明が解決しようとする課題】
【0008】
しかしながら、上述した従来技術においても、次のような課題があった。
(1)複数のセンサの時刻同期を行ったとしても同期の精密性が十分でなく、このため、収集したデータの時刻を揃え、空間情報を含めた精密な分析を行おうとすると改善の余地があった。
(2)複数のセンサについては、複数の異なるベンダから提供される多種の規格に基づくセンサが存在するのであり、これらの異なる多種多様なセンサから収集したデータを横断的に検索しようとすると改善の余地がった。
(3)物流の現場等においては、複数の運送事業者(大中小のトラック運送、鉄道、海運)、生産事業者、小売事業者など複数のプレイヤーがおり、複数のプレイヤーがそれぞれで収集したデータを集約して検索する必要がある。その際、プレイヤー間で品質や信頼性の点でばらつきあるデータを取り扱おうとすると、プレイヤー間の相互信頼の問題もあり、改善の余地があった。
【0009】
そこで、本発明は、複数のセンサの時刻同期を高度な精密度で行い、また、高精度に同期された時刻情報と空間情報とを含めた時空間情報を分析し、さらに、異なる多種多様なセンサから収集したデータの横断的検索を容易にするシステム等を提供することを目的とする。
【0010】
また、本発明は、物流の現場等における複数のプレイヤーがそれぞれで収集したデータを集約して検索する技術を提供し、プレイヤー間で品質や信頼性の点でばらつきあるデータを高い信頼性をもって取り扱える技術を提供することを目的とする。
【課題を解決するための手段】
【0011】
本発明にかかるデータ収集・分析システムは、1以上のセンサから送信されるセンサデータを集約するゲートウェイと、
前記ゲートウェイを通過したデータを集積するデジタルエビデンスプラットフォームと
を備えるデータ収集・分析システムであって、
前記ゲートウェイは、
集約した前記センサデータに時空タグを付与し、前記時空タグを付与した1次データをブロックデータとして前記デジタルエビデンスプラットフォームに送信し、
前記デジタルエビデンスプラットフォームは、前記ゲートウェイから送信された前記ブロックデータを保存し、
前記ブロックデータに含まれる前記センサの種類ごとに分割した2次データ(エンティティデータ)を生成し、
前記2次データ(エンティティデータ)に対してスキーマを使って意味づけされた3次データ(セマンティクスデータ)を生成し、
前記2次データ(エンティティデータ)及び前記意味づけされた3次データ(セマンティクスデータ)を横断的に検索可能なインデックスを生成する
ことを特徴とする
【0012】
また、前記デジタルエビデンスプラットフォームは、さらに、前記3次データ(セマンティクスデータ)について、有効数字を考慮した単位の相互変換が可能となる4次データ(コンバーチブルデータ)を生成し、前記4次データ(コンバーチブルデータ)を横断的に検索可能なインデックスを生成することを特徴とする。
【0013】
また、前記デジタルエビデンスプラットフォームに保存された前記1次データ~前記4次データは、SDKによって機能提供され、前記提供される機能においては、時空検索ができ、かつ、前記時空検索の結果は、エンティティとして得られることを特徴とする。
【発明の効果】
【0014】
本発明にかかるデータ収集・分析システム等によれば、複数のセンサの時刻同期を高度な精密度で行い、また、異なる多種多様なセンサから収集したデータの横断的検索を容易にする技術を提供することができる。
【0015】
また、物流の現場等における複数のプレイヤーがそれぞれで収集したデータを集約して検索する技術を提供し、プレイヤー間で品質や信頼性の点でばらつきあるデータを高い信頼性をもって取り扱える技術を提供することができる。
【図面の簡単な説明】
【0016】
図1】本発明の一実施形態にかかるデータ収集・分析システムのシステム構成概念を説明する説明図である。
図2A】本発明の一実施形態にかかるデータ収集・分析システムのシステム構成概念を説明する説明図である。
図2B】本発明の一実施形態にかかるデータ収集・分析システムのシステム構成概念を説明する説明図である。
図3A】本発明の一実施形態にかかるデータ収集・分析システムにおける検索インデックス作成サーバの機能構成を説明する説明図である。
図3B】本発明の一実施形態にかかるデータ収集・分析システムにおけるブロックチェーン合意形成作成サーバの機能構成を説明する説明図である。
図4】本発明の一実施形態にかかるデータ収集・分析システムにおける動作フローを説明するためのフローチャートである。
図5】本発明の一実施形態にかかるデータ収集・分析システムにおける処理の詳細フローを説明するためのフローチャートである。
図6】本発明の一実施形態にかかるデータ収集・分析システムにおいて生成されるデータのデータ形式例を説明する説明図である。
図7】本発明の一実施形態にかかるデータ収集・分析システムにおいて生成される階層型ブロックチェーンの構成概念例を説明する説明図である。
図8A】本発明の一実施形態にかかるデータ収集・分析システムにおける動作をクライアント側からみたフローを説明するための説明図である。
図8B】本発明の一実施形態にかかるデータ収集・分析システムにおける動作をクライアント側からみたフローを説明するための説明図である。
図9A】本発明の一実施形態にかかるデータ収集・分析システムにおいて取り扱われるデータのデータ構造例を説明する説明図である。
図9B】本発明の一実施形態にかかるデータ収集・分析システムにおいて取り扱われるデータのデータ構造例を説明する説明図である。
図9C】本発明の一実施形態にかかるデータ収集・分析システムにおいて取り扱われるデータのデータ構造例を説明する説明図である。
図10】本発明の一実施形態にかかるデータ収集・分析システムにおける4次データの登録動作例を説明する説明図である。
図11】本発明の一実施形態にかかるデータ収集・分析システムにおける4次データに対する読み出し、応答動作例を説明する説明図である。
図12】本発明の一実施形態にかかるデータ収集・分析システムにおける1次テーブル(1次データ)~4次テーブル(4次データ)までのテーブル間の関係を証跡の観点から説明する説明図である。
【発明を実施するための形態】
【0017】
(用語の定義)
はじめに、本実施例で使用される用語の定義を行う。
【0018】
[時空情報(時空間情報)]
時空情報(時空間情報ともいう。以下、総称して「時空情報」という。)とは、日時/時刻や空間に関する情報全般をいい、特に、本実施例においては、モノやヒト等の位置情報及び日時/時刻情報、あるいは、モノやヒト等の緯度・経度・高度・日時/時刻情報をいう。
【0019】
[電子署名]
測位信号に含まれる航法メッセージは本物であることを証明する電子情報をいう。一例として、みちびき(準天頂衛星システム:QZSS)においては、この電子署名の仕組みが既に実装されており、位置情報及び時刻情報の信頼性・安全性を高めることができる。
【0020】
[ゲートウェイ]
本発明にかかるデータ収集・分析システムを構成する装置であり、ネットワークのエッジとなる各現場に配置されるデータ収集装置をいう。一例として、物流拠点に配置される拠点ゲートウェイや車載ゲートウェイなどがある。
ゲートウェイでは、GPS信号を使ったナノ秒精度の時刻同期が行われており、収集されたデータに対して、時空情報の一形態である「時空タグ」が付与される。ゲートウェイで収集される前の各種センサデータは時刻情報が不揃いの可能性があるが、ゲートウェイを通過することで、地球上のどの場所であっても、人工衛星に搭載された原子時計に高精度で同期した時刻タグを付与することができ、後に時刻と位置を使った正確な検索が可能になる。
なお、ゲートウェイを通過するデータのデータ構造の概略は次のとおりである。まず、各種センサデータは、エンティティデータとして「エンティティコンテナ」に格納される。複数のエンティティデータは、ブロックデータとして「ブロックコンテナ」に格納される。ゲートウェイ上のブロックコンテナに対しては、ブロックチェーン特有のチェーン状のハッシュ値計算が行われると同時に、電子署名が付与される。これにより、データ改竄や詐称が極めて難しくなる。ブロックデータは、電子署名が付与され、後述のDEPに送信される。
【0021】
[デジタルエビデンスプラットフォーム(DEP)]
インターネット回線等を通して送り込まれた各ゲートウェイで生成されたデータを保存し、検索可能なインデックス生成を行って外部からの検索リクエストに応答するプラットフォームである。DEP上では、各ゲートウェイに安全に保存されている秘密鍵と対になる公開鍵が保存されており、送信されてきたデータの電子署名データの検証による真正性の確認が行われる。
【0022】
[スキーマ、スキーマID]
本発明にかかるデータ収集・分析システムにおけるクロックチェーンでは、どのようなセンサデータでも収集して解析することができる。この場合、センサ毎にデータのデータ構造が異なるため、その構造を定義したスキーマデータを各センサに対して作成することになる。つまり、スキーマは、センサ毎に異なるデータ構造の定義である。そして、このスキーマデータを識別する識別子がスキーマIDである。スキーマIDは、DEPに保存される。
【0023】
[サイドチェーン]
本発明にかかるデータ収集・分析システムにおけるゲートウェイから送信されるブロックデータは、ブロックチェーン状の構造をしているが、DEP上では、複数のゲートウェイから送信されてくる各ブロックのハッシュ値を使ってブロックデータ全体をまとめるブロックチェーンを生成する必要がある。このような多重構造のブロックチェーンをサイドチェーンという。ブロックチェーンそれ自体においては、同時に処理できるデータ量に制限があるが、このサイドチェーンにより、そのデータ量の制限を緩和することができる。
【0024】
[マークルツリー構造]
本発明にかかるデータ収集・分析システムにおけるブロック内には、複数のエンティティが格納されている(オリジナルのブロックチェーンにおいては「トランザクション」と呼ばれるものである)。これら各エンティティのデータの改竄を検知するためのハッシュ値計算を高速化するために使われるデータ構造をマークルツリー構造という。マークルツリーのオリジナルは、R.C.Merkleによって1980年に提案された概念である。
【0025】
[1次データ、1次テーブル]
本発明にかかるデータ収集・分析システムにおけるDEP上に格納されるブロック情報に関するデータを1次データといい、1次データのデータベース構造を1次テーブルいう。入力された各ブロックに付与された時空タグ、ブロックのハッシュ値、電子署名の検証結果が格納されて検索に利用される。この段階で証跡毎の検索が可能になる。
【0026】
[2次データ、2次テーブル]
本発明にかかるデータ収集・分析システムにおけるDEP上に格納されるエンティティ情報に関するデータを2次データといい、2次データのデータベース構造を2次テーブルという。ブロックに格納された各エンティティ情報が分解されて格納され、検索に利用される。この段階ではセンサデータ毎の検索が可能になるが、スキーマを使ったデータの解析や意味づけはまだ行われない。
【0027】
[3次データ、3次テーブル]
本発明にかかるデータ収集・分析システムにおけるDEP上に格納されるセンサ情報に関するデータを3次データといい、3次データのデータベース構造を3次テーブルいう。3次テーブル作成にあたっては、スキーマを使ってエンティティデータが解析されており(意味づけされており)、センサ情報は、各センサ値に分解され、検索可能になっている。
【0028】
[4次データ、4次テーブル]
本発明にかかるデータ収集・分析システムにおけるDEP上に格納されるセンサ情報に関するデータを4次データといい、4次データのデータベース構造を4次テーブルという。4次テーブルでは、3次テーブルのセンサ値が単位変換され、また同じ意味を持つデータにまとめて整理されている点に特徴がある。これにより、異種センサから収集したデータの集合体であっても、これらデータの集合体を横断的に検索することが可能となる。
なお、この「横断的検索」は、「串刺し検索」ともいうが、本願においては横断的検索と呼ぶこととする。
【0029】
[時空認証(登録商標。以下、同じ)]
時空情報を用いた認証技術をいう。時空認証は、数学的、暗号学的に証明しうる事実をマークルツリー構造で管理し、改ざん不可能な状態を保ちながら時間/空間/責任者/確からしさ等を事後検証できるように作動する分散認証技法である。時空認証では、データの取得時に中央機関による認証行為を行うアーキテクチャを採用していない。
なお、時空認証を行うゲートウェイを「時空認証ゲートウェイ」、「時空認証ゲートウェイサーバ」、あるいは、単に「ゲートウェイサーバ」ともいう。
【0030】
[iPNT]
iPNTとは、「Indoor Position, Navigation, Timing」の略称であり、GNSS互換信号を用いて、屋内空間に高精度な時刻、タイミング、位置座標、メッセージ情報を放送して高精度時刻同期を実現する仕組みをいう。
具体的には、上空のGNSS信号を受信したTAS(Time and Authentication Service)装置で独自の時刻メッセージを生成し、そのメッセージを既存のTV共視聴システムなどの伝送経路を利用して、建物内に放送として配信するなどがある。ここで、GPS信号(iPNT信号)を送信したい任意の場所にiPNT送信機を設置して、IMESS同様にiPNT信号(GNSS信号)を送信する。そのiPNTを受信したGNSS受信機では、位置情報やメッセージを読み取ると同時に時刻メッセージを読みとることで、高精度な同期信号(1PPS)を出力できることとなる。
【0031】
[IMES]
IMESとは、「Indoor Messaging System」の略称であり、IMES信号は、GNSS信号を補完するための疑似的な信号である。
【0032】
(本発明の基本概念)
本発明の理解のために、まず、本発明の基本概念について説明する。本発明の目的は、あらゆるセンサデータに「時間・空間・確からしさ・データの責任者・追跡性」を付与したうえで、数学的・暗号学的に改ざん不能な情報として保管すると共に、これら情報の横断的検索性を持たせたデジタルトラスト証跡基盤(クロックチェーン(登録商標。以下、同じ))を提供することである。
【0033】
ここで、クロックチェーンにおける「情報の横断的検索性」は、さらに具体的には次のような機能的性質を有している。
(1)時間と空間の情報を検索条件として、複数の発信者によるデータを一元的に検索できる(時空検索)。
(2)上記(1)の時空検索に加え、データの「意味」を検索条件として、複数の発信元から送信されてきたデータを一元的に検索できる(セマンティクス検索)。
(3)上記(1)及び(2)の検索結果について、データの単位を統合して管理することができる。
(4)上記(1)~(3)のいずれにおいても、「時間」「空間」「確からしさ」及び、「データの責任者」を事後検証でき、かつ、それらの証跡を辿ること、すなわち、それらに対する「追跡可能性」を有する。
【0034】
また、クロックチェーンを実現するための基本的な仕組みは、大別して次のようなものである((a)~(h))。
(a)データの発生源からデータを収集してくる仕組み(データコレクタ)。データコレクタの具体的デバイスとしては、シーケンサ、デジタコ、RFID、バーコードリーダー、ドキュメント(リポジトリ(スマホ、スキャナ、NAS))がある。
(b)上記(a)のデータを集約する仕組み(時空認証ゲートウェイ)。
(c)上記(b)のデータスキーマを定義する仕組み。
(d)クロックチェーンのネットワークに当該データを送信する仕組み。
(e)送信されたデータを改ざん不可能な状態で保管し、ID化する仕組み。
(f)上記(e)のIDをブロックチェーンに書き込み、証跡化する仕組み。必要に応じてサイドチェーンが採用される。
(g)上記(f)のデータを時空検索および、セマンティクス検索を可能化し、単位を統合する仕組み。
(h)ダウンロードまたはAPIを通じて上記(f)の検索結果を取得可能にする仕組み(アクセスコントロール機能を含む。なお、アクセスコントロールは、情報の発生源の責任者が自ら設定可能)。
【0035】
(本発明の活用分野等)
本発明にかかるデータ収集・分析システム等によれば、荷物のトレーサビリティや無人授受(所有者移転)、CO2排出量の算出において一定の成果が得られるほか、物流サプライチェーン(情報共有・取引)、交通、インフラ維持管理(保守データ)、工場・製造(予知保全データ・サプライ情報)、不動産(評価データ)、医療・介護(広域にわたる移動)、農業、漁業等、様々な方面へのシステム等展開が期待できる。
【0036】
(本発明の基本原理、課題の解決手段の要点)
まず、本発明にかかるデータ収集・分析システム等においては、複数センサの時刻同期を精密に行うために、センサから収録したデータを各現場に設置されたゲートウェイに通過させ、このゲートウェイ上でタイムスタンプを付与する。なお、一実施形態において、ゲートウェイはGPS受信機をもち、人工衛星に搭載された原子時計と同期することで、世界中どこでもマイクロ秒以下の精度で時刻同期することができる。
【0037】
また、複数ベンダが製造した多種の規格が異なるセンサから収集したデータに対して横断的検索を可能にするためには、データスキーマと各データベーステーブルを用いる。本発明はこれに限定されるものではないが、一実施形態において、ゲートウェイから送信されたデータは、クロックチェーンのクラウドサービスで受信され、クラウドサービス上でデータの分析が行われる。
そして、データの受信時刻とタイムスタンプ時刻、電子署名の検証結果を格納する「1次テーブル」、データを個別のセンサデータに分割した「2次テーブル」、個別のセンサデータを個別のセンサ値に分割した「3次テーブル」、多種のセンサから収集された同質のデータごとに単位を揃えて検索可能に構成された「4次テーブル」を作成する。最終的には、この4次テーブルに対する検索を行うことで、多種多様なデータに対する横断的検索が可能になる。また、各テーブルは親子関係をもち、その関連を辿ることができる(証跡化)。例えば、「検索した4次テーブルのデータに対する電子署名の検証を1次テーブルから得る」といったことも可能となる。
【0038】
複数のプレイヤー間の相互信頼の問題に関しては、電子署名とブロックチェーン技術を用いることで解決する(必要に応じて、サイドチェーンが採用される。以下、同様)。ゲートウェイは、データに対してタイムスタンプを付与すると同時に電子署名も付与する。また、一実施形態において、電子署名は、偽造が困難なハードウェアセキュリティモジュールに格納されており、「確かにその機器をデータが通過した」ことを信頼性高く証明することができる。さらに、データはブロックチェーンのリンク構造の形でサーバに送信されるため、データの偽造がより困難になる。サーバに送信されたデータは電子署名の検証とリンク構造の検証が行われた上で、ブロックチェーンの合意形成の仕組みを使って複数サーバによる検証計算結果を統合する形でデータ検証が行われる。また、複数のプレイヤーは、自分自身で検証サーバを運用することもでき、データの利用者は、特定のプレイヤーによる検証ではなく、複数のプレイヤーの合意によって信頼ができると検証されたデータを利用することができる。
【0039】
以下、本発明にかかるデータ収集・分析システム等ついて、図面を参照しながら詳述する。
【実施例0040】
図1に、本発明の一実施形態にかかるデータ収集・分析システムのシステム構成を示す。図1において、一実施形態にかかるデータ収集・分析システム100aは、1以上のIoTセンサ110と、時空認証ゲートウェイサーバ120と、4G/5G基地局130と、デジタルエビデンスプラットフォーム140とを含む。ここで、時空認証ゲートウェイサーバ120と、4G/5G基地局130との通信については、例示的にLPWA設備120dが採用される(但し、本発明の構成はこれに限定されない)。
IoTセンサ110は、ネットワークに接続され、モノ(Things)の測定データを収集及び/または管理するセンサであり、そのセンサの種類によってあらゆるIoTセンサデータを収集する。一実施形態においては、IoTセンサには、光センサ、イメージセンサ、圧力センサ、温度センサ、湿度センサ、加速度センサなどがあり、これらのセンサからの測定情報を収集する。また、必要に応じてGPS受信機等を搭載するなどして、単独で位置情報を収集させることもできる。
【0041】
また、図1において、他の実施形態にかかるデータ収集・分析システム100bは、時空認証ゲートウェイサーバ120と4G/5G基地局130と、デジタルエビデンスプラットフォーム140とを含む。この場合、データ収集・分析システムは、1以上のIoTセンサ110を必須の構成要素としない。
また、図1において図示しないさらに他の実施形態にかかるデータ収集・分析システムにおいては、LPWA設備120d、4G/5G基地局130に替えて、他の通信設備を採用することもできる。
【0042】
次に、IoTセンサについて具体的に説明する。一例として、ある建物のある位置に取り付けられたIoTセンサであれば、振動情報や温度情報などを収集することができる。また、IoTセンサがバイオメトリクスセンサであれば、そのセンサの取り付け位置の体温情報、血圧情報、または心拍情報を収集することができる。
本発明はこれに限定されるものではないが、図1に一実施形態にかかるIoTセンサが取り付けられたモノ(Things)の例示を11a~11fを示す。11a~11fは、IoTセンサ110のバリエーションである。
【0043】
なお、本発明の一実施形態において、各IoTセンサには、個別のIDを割り当てることができ、各IoTセンサからのデータ送信時に発信元としてこのIDを送信させることができる。また、IoTセンサからのデータ送信には、WiFi,Bluetoothといった低消費電力無線方式や、いわゆるLPWA(Low Power Wide Area)を採用することができる。
【0044】
図1において、IoTセンサ110が収集したデータは、時空認証ゲートウェイサーバ120へ送信される。
【0045】
時空認証ゲートウェイサーバ120は、IoTセンサ110から送信されるデータメトリクスを受信するとともに、図中の測位衛星10a~10cから送信される測位信号(典型的には、位置情報+時刻情報)を受信する。
【0046】
本発明の一実施形態において、時空認証ゲートウェイサーバ120は、IoTセンサ110から受信したデータメトリクスと測位衛星10a~10cから受信した測位信号とに基づいて、時空認証スタンプ処理を行う。具体的には、IoTセンサ110から受信したデータメトリクスにそのデータ送信元の位置情報や発信時刻情報(一例として、受信時刻から推定する)を刻印する。
【0047】
また、本発明の一実施形態において、取得されたデータには、その種別に関係なく、識別ID、時刻情報、空間情報(位置樹報)が付加されることができる。これらの付加情報は、その妥当性が検証可能な形式を有する。
さらに、付加情報(時刻情報、空間情報)に加え、その正確さの度合いを表すアキュラシー情報も併せて記録される。このアキュラシー情報は、例えば、同時刻の周辺のプローブデータに基づいて後処理を行うことでさらに高精度のデータへ補正するために利用される。
【0048】
時空認証ゲートウェイサーバ120においてこの時空認証スタンプがなされることによって、IoTセンサ110から送信されるあらゆるデータメトリクスは、正確に認証された時空情報となる。これらのデータは、トランザクションデータとして、LPWA設備120d(一例として、LTE Cat.M1, Narrow Band-IoTなど)を介して4Gないし5Gの基地局130から外部へ発信される。本発明の一実施形態においては、デジタルエビデンスプラットフォーム140へ送信され、されに高次のデータ分析やデータ加工がなされる。
【0049】
本発明の一実施形態において、時空認証ゲートウェイサーバ120は、上記時空認証スタンプ処理のほかに、ブロックチェーン向けのトランザクション作成や署名、投稿処理などを行うことができる。
【0050】
一実施形態において、基地局130からは、時空認証ゲートウェイサーバ120で生成されたトランザクションデータがLTE閉域網を介してデジタルエビデンスプラットフォーム140へ送信され、ユーザ端末等に対するサービスが提供される。こうしたサービスの提供は、「デジタルエビデンスクラウドサービス」として位置付けることができる。
【0051】
デジタルエビデンスクラウドサービスの一形態としては、指定のエリア及び期間、ならびにデータタイプ等の検索設定条件から抽出したデータセットのサービス提供や、所定のフィルタリングを経たデータストリームのサービス提供といったサービス形態が挙げられる。
【0052】
なお、図1に示したデータ収集・分析システムは、時空認証ゲートウェイサーバ120が固定的に設置されたタイプのものであるが、本発明はこれに限定されず、自動車等の移動体に設置されるタイプのものもある。これらについては、例えば、図2Bを参照して後述する。
【実施例0053】
図2Aに、本発明の一実施形態にかかるデータ収集・分析システムのシステム構成概念を示す。特に、図2Aでは、図1のDEP140の具体的なバリエーション(DEP210)を示す。
【0054】
図2Aにおいて、DEP210は、ストリーム処理部/仮想ゲートウェイ211と、検索インデックス作成部212と、ブロックチェーン処理部213と、データベース214と、API(Application Programming Interface)215とを備えている。ストリーム処理部/仮想ゲートウェイ211は、センサ群201a~201e(図1のセンサ群110:11a~11fに対応)からのセンシングデータをストリーミングとして受信及び処理する仮想的なゲートウェイとして機能する。この意味で、ストリーム処理部/仮想ゲートウェイ211は、時空認証ゲートウェイサーバ120に対応する部分を含む。検索インデックス作成部212は、処理されたストリーミングデータを検索可能にするための検索インデックスを作成する処理部である。ブロックチェーン処理部213は、検索可能になったデータの証跡化を可能にするための処理部である。データベース214は、DEP210で蓄積されたデータやデータの加工処理によって生成したデータ構造を保存する。例えば、DEP210内で処理されたデータを時系列データあるいはジオメトリデータとして格納する。API215は、外部のサービス提供者やユーザに対してサービス230を提供するためのインタフェースである。具体的には、時空検索サービスや時空データダウンロードサービス、デジタルツインストリーム配信サービス、ジオフェンス通知サービスなどがある。
【0055】
なお、本実施例で採用されている仮想ゲートウェイは、これに制限されるものではないが、一実施形態において次のような処理機能を有している。すわなち、データソースが、現場からリアルタイムに取得されるセンサデータ(ストリーム処理部の処理対象)ではなく、すでにセンシングされたセンサデータを蓄積する外部システムから取得されるデータである場合に、この外部システムから、デリミタ付きのレコードデータとしてエクスポートした上で、時刻情報、空間情報(位置情報)、および、アキュラシー情報を付加し、上記各号の条件を満たすデータ変換処理を行い、ゲートウェイの機器から発せられるものと同じフォーマットのデータを構成して、インターネット上にアップロードする。
なお、本実施例では、仮想ゲートウェイを採用しているが、センサデータをリアルタイムに処理するゲートウェイを採用することもできる。
【0056】
また、DEP210は、外部に提供するためのサービスをすべて自前で処理することに限定されない。図2Aに図示されるように、外部加工データ230を取り込むことも可能である。例えば、時空間情報付きの1次データから、2次データあるいは3次データまで外部で加工されたものを取り込み、DEP210内でインデックス化等の処理を行うことができる。
【実施例0057】
図2Bに、本発明の一実施形態にかかるデータ収集・分析システムのシステム構成概念を示す。特に、図2Bでは、図1のDEP140の具体的なバリエーション(DEP260)を示す。
【0058】
DEP260とDEP210との相違点は、DEP210では内部に存在していた仮想ゲートウェイ部が、DEP260では外部に切り離されてゲートウェイ255として機能していることである。このゲートウェイ255は、センサデータをリアルタイムに処理する。このような独立したゲートウェイ255は、ネットワークのエッジとなる各現場に配置されるデータ収集装置を想定しており、一例として、物流拠点に配置される拠点ゲートウェイや車載ゲートウェイなどがある。
その他については、センサ251a~251eは、センサ201a~201eに対応し、検索インデックス作成部262は212に対応し、ブロックチェーン処理部263は213に対応し、データベース264は214に対応し、API265は215にそれぞれ対応する。また、外部加工データ280も270に対応する。
【実施例0059】
図3Aに、本発明の一実施形態にかかるデータ収集・分析システムにおける検索インデックス作成サーバの機能構成を示す。同図における検索インデックス作成サーバ310は、機能的に検索インデックス作成部212、262の少なくとも一部に対応する。
【0060】
図3Aにおいて、検索インデックス作成サーバ310は、インターネット340を介してゲートウェイ320から取得したストリームデータを自身のプロセスP311~P314に従って処理していく。また、プロセスP311~P314の各処理において、1次テーブル~4次テーブルが生成されていく。なお、3次テーブルを生成するプロセスP313、及び4次テーブルを生成するプロセスP314では、センサ毎に異なるデータ構造を定義したスキーマを格納するスキーマデータベース330が利用される。
【0061】
具体的には、プロセスP311において、ゲートウェイから送られてきたストリームデータの電子署名の検証、及びリンク構造の検証が行われる。検証の結果、1次テーブルとして出力される(D311)。
プロセスP312では、IoTセンサごとのデータ分割処理が行われ、分割されたデータは、2次テーブルとして出力される(D312)。
プロセスP313では、IoTセンサのセンサ値ごとのデータ分割処理が行われ、分割されたデータは、3次テーブルとして出力される(D313)。
プロセスP314では、センサ値の単位変換処理が行われ、同種センサごとの分類処理が行われる。これらの処理の結果は、4次テーブルとして出力される(D314)。
【実施例0062】
図3Bに、本発明の一実施形態にかかるデータ収集・分析システムにおけるブロックチェーン合意形成作成サーバの機能構成を示す。同図におけるブロックチェーン合意形成作成サーバ370は、機能的にブロックチェーン処理部213、263の少なくとも一部に対応する。また、同図におけるブロックチェーンデータベース380は、データベース214、264にその一部または全部が対応する。
【0063】
図3Bに示されるように、ブロックチェーン合意形成作成サーバ370は、少なくとも3以上のブロックチェーン検証サーバ371~373を含む。本発明の一実施形態において、ブロックチェーン合意形成作成サーバ370は、ゲートウェイ350及び検索インデックス作成サーバ360を介して取得したデータに基づいて作成されたブロックチェーンをこれらの検証サーバ使って検証し、それらの検証結果のうち多数一致となる結果を採用して合意形成を行うことができる(この合意形成の手法は、ブロックチェーンの検証のための既知の手法を採用することができる)。
合意形成の作成結果は、ブロックチェーンデータベース380に格納され、管理されることができる。
【0064】
図4に、本発明の一実施形態にかかるデータ収集・分析システムにおける動作フローを説明するためのフローチャートを示す。
【0065】
図4において、センサ1及びセンサ2は、図1におけるIoTセンサ群110(11a~11f)に対応する。図4において、説明の便宜上、センサは2つしか表示されていないが、本発明はこれに限定されるものではなく、3以上のセンサを備えていてもよい。
【0066】
図4におけるゲートウェイは、図1におけるゲートウェイサーバ120に対応する。また、同図中の解析サーバは、機能的に、図1におけるデジタルエビデンスプラットフォーム140の少なくとも一部に対応する。
また、図4中、t1~t11は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。
【0067】
まず、時刻t1において、センサ1から生計測データがゲートウェイに送信される(ステップS401)。センサ1からは、後述するように時刻t4、t7、t10においても生計測データがゲートウェイに送信される(ステップS406、ステップS411、ステップS416)が、本発明の一実施形態においては、これらの送信タイミングの同期はとられていない(非同期送信)。
【0068】
時刻t2において、センサ2から生計測データがゲートウェイに送信される(ステップS402)。センサ2からは、後述するように時刻t5、t9においても生計測データがゲートウェイに送信される(ステップS407、ステップS415)が、本発明の一実施形態においては、これらの送信タイミングの同期はとられていない(非同期送信)。
【0069】
図4において、ゲートウェイでは、センサ1及びセンサ2から送られてきた生計測データを集約し、定期/不定期に時刻情報を刻印する(ステップS403、ステップS408、ステップS412、ステップS417)。そして、ゲートウェイにて時刻情報が刻印された生計測データ(群)は、時間単位集合データ(ブロックデータに対応する。以下、同じ)として解析サーバへ送信される(ステップS404、ステップS409、ステップS413、ステップS418)。
なお、本発明の一実施形態において、時刻情報を刻印するとは、集約した各生計測データに時刻情報を付加して1つのデータセットとする処理を行うことをいう。
また、本発明の一実施形態において、各生計測データには、計測値データのほか、各センサの位置情報を含めることができる(この場合は、各センサが自身の位置情報を記憶しているか、あるいは、各センサ自身が位置情報を記憶していない場合であっても、ゲートウェイの位置情報を代表的に利用して各センサの位置とすることもできる。)。
【0070】
次に、時刻t3において、ゲートウェイからは、集約し時刻情報を刻印した生計測データ(群)を時間単位集合データとして解析サーバへ送信する(ステップS404)。
【0071】
ステップS404において時間単位集合データを受信した解析サーバでは、これを図示しない記憶領域に格納する(ステップS405)。一実施形態において、格納されたデータは、デジタルエビデンスプラットフォーム内の他の処理系、あるいは、図示しないアプリケーション等によって利用される(ステップS491)。
ここで、デジタルエビデンスプラットフォーム内の他の処理系、あるいは、アプリケーション等によって利用されるデータのデータ形式等について、図6を参照して説明する。
【0072】
図6に、本発明の一実施形態にかかるデータ収集・分析システムにおいて生成されるデータのデータ形式例を示す。このデータ形式は、本発明の一実施形態におけるデジタルエビデンスプラットフォームで取り扱われるデータ形式例であるが、データ形式はこれに限定されない。
【0073】
図6に示されるように、データ600は、タイムスタンプ情報(時刻情報)601と内容データ602とからなる。タイプスタンプ情報601は、ゲートウェイによって生計測データに対して刻印された時刻情報である。一実施形態において、年月日及び時分秒のデータ形式が採用されている。
【0074】
また、内容データ602には、各生計測データの数値の列(1以上の列)が格納されている。本発明の一実施形態において、内容データ602には、下表のようなデータ項目が含まれる。
【表1】
本発明の一実施形態においては、上記センサID、計測値、及びセンサ位置情報を必須とし、付加的にセンサの位置情報を含めることもできる(その場合は、各センサが自身の位置情報を記憶している)。
あるいは、センサの位置情報に関し、GWの位置情報が代表的に利用されて、各センサの位置情報とされてもよい。
【0075】
図4に戻り、ゲートウェイでの時刻情報刻印(ステップS408)に着目すると、ここでの時刻情報刻印対象データは、時刻t4においてセンサ1から送信されてきた生計測データと時刻t5においてセンサ2から送信されてきた生計測データである。同ステップで時刻情報を刻印された生計測データ(群)は、時間単位集合データとして解析サーバへ送信される(ステップS409)。ステップS409において時間単位集合データを受信した解析サーバでは、これを図示しない記憶領域に格納する(ステップS410)。一実施形態において、格納されたデータは、デジタルエビデンスプラットフォーム内の他の処理系、あるいは、図示しないアプリケーション等によって利用される(ステップS492、ステップS493)。
【0076】
次に、ゲートウェイでの時刻情報刻印(ステップS412)に着目した場合には、ステップS403やステップS408とは異なった処理がなされている。つまり、ステップS412において集約された生計測データは、センサ1から送信されてきたデータのみである。このように、本発明の一実施形態においては、必ずしも時刻刻印のタイミングごとに、全てのセンサからの生計測データの到来を待つことはない。個別の事情(作動タイミングのゆらぎ)によって、所定の時刻刻印タイミングに到来が間に合わなかった生計測データ(ここでは、センサ2からの到来データ)は、切り捨てることができる。
【0077】
ステップS412において時刻情報を刻印された生計測データ(群)は、時間単位集合データとして解析サーバへ送信される(ステップS413)。ステップS413において時間単位集合データを受信した解析サーバでは、これを図示しない記憶領域に格納する(ステップS414)。一実施形態において、格納されたデータは、デジタルエビデンスプラットフォーム内の他の処理系、あるいは、図示しないアプリケーション等によって利用される(ステップS494)。
【0078】
次に、ゲートウェイでの時刻情報刻印(ステップS417)に着目した場合には、ステップS403やステップS408、また、ステップS412とは異なった処理がなされている。つまり、ステップS418において集約された生計測データは、センサ1及びセンサ2から送信されてきたデータであるが、データ到来の順序がこれまでと異なっている。このように、本発明の一実施形態においては、必ずしも全てのセンサからの生計測データの到来順序は問題とされない。
【0079】
ステップS417において時刻情報を刻印された生計測データ(群)は、時間単位集合データとして解析サーバへ送信される(ステップS418)。ステップS418において時間単位集合データを受信した解析サーバでは、これを図示しない記憶領域に格納する(ステップS419)。一実施形態において、格納されたデータは、デジタルエビデンスプラットフォーム内の他の処理系、あるいは、図示しないアプリケーション等によって利用される(図4において、不図示)。
【0080】
図5に、本発明の一実施形態にかかるデータ収集・分析システムにおける処理の詳細フローを示す。図5に示されたフローは、図1に示されたデータ収集・分析システムでの処理を前提としているが、図5に示されたフローでは、実施形態のバリエーションとして、iPNT信号の受信を想定している。しかしながら、本発明にかかるデータ収集・分析システムの全ての実施形態が、iPNT信号の受信を前提とするものではない。この意味において、本発明の一実施形態にかかるデータ収集・分析システムにおいては、図5のステップS502~S505を割愛するか、及び/または、他の処理に置き換えることができる。
【0081】
図5のステップS501において処理を開始すると、ステップS502へ進み、図示しないiPNT受信機においてiPNT信号が受信される(ステップS502)。次に、ステップS503へ進み、iPNT受信機において1PPS(一例として、クロック10MHz)ごとの同調信号が生成される。本発明の一実施形態において、生成信号は、iPNT受信機内で継続して処理される。また、一実施形態において、この信号は、屋外GNSSと同期されてもよい。
【0082】
次に、ステップS504へ進み、一実施形態において、iPNT受信機内にてNMEAメッセージ生成処理がなされる(NMEAメッセージとは、米国海洋電子機器協会(NationalMarine Electronics Association)が定めた規格で、受信機とナビゲーション機器の通信に使用されるプロトコルである。)。ここでは、時刻情報を取り出すことができる。次に、ステップS505へ進み、一実施形態において、iPNT受信機内にてNMEA-INPTメッセージ生成処理がなされる(NMEA-iPNTメッセージとは、NMEAメッセージにiPNTに関する情報が加わった通信プロトコルである。)。ここでは、時刻+位置+メッセージ情報を取り出すことができる。
本発明の一実施形態において、これらの情報は、ゲートウェイ(一例として、120など)へ送信される。
【0083】
次に、ステップS506へ進み、ゲートウェイにおいて各センサからのデータ収集が行われる。一例として、図4のステップS401、S402、S406、S407、S411、S415、S416である。
そして、ステップS507に進み、ゲートウェイにおいて収集されたデータ(群)に対する時間情報の刻印処理がなされる。一実施形態において、ここでの刻印処理で採用される時刻情報は、ゲートウェイにおけるデータの受付時間である。これらの刻印処理は、一例として、図4のステップ403、S408、S412、S417である。
【0084】
そして、ステップS508へ進み、ゲートウェイから解析サーバへ刻印済みのデータ(群)が送信される。これらの送信処理は、一例として、図4のステップS404、S409、S413、S418である。
【0085】
図7に、本発明の一実施形態にかかるデータ収集・分析システムにおいて生成される階層型ブロックチェーンの構成概念例を示す。ここでの処理やデータ構造の構築は、これに限定されるものではないが、一例として、デジタルで微デンスプラットフォーム210や260において実施されている。
【0086】
図7において、センサデータ等の生データ710は、マークルツリー化されるとともに(720)、データのブロックごとのハッシュ値が取得される。これらのハッシュ値は、トランザクションプール740(メモリ上の所定の領域である)に記憶される。
また、補正ロジックについても適宜ハッシュ値が取得され、これらのハッシュ値も、トランザクションプール740に記憶される。なお、補正ロジックは、付加情報(時刻情報、空間情報)に加え、その正確さの度合いを表すアキュラシー情報を用いてさらに高精度のデータへ補正するためのロジックなどが挙げられる。
【0087】
ここで、マークルツリー化の一実施形態は、およそ次のとおりである。すなわち、DEP内部では、ゲートウェイを通じて一定時間毎(一例として、1秒~1分程度)にアップロードされてきたプローブデータ(及び付加情報)をマークルツリー構造にして保存する。具体的には、ハッシュベースのCIDを用いてファイル管理を行うP2P分散ストレージにセンシングデータ(プローブデータ)を記録し、当該ファイルのCIDは、ブロックチェーンにアンカリングする。これにより、証跡化が可能になる。
マークルツリー構造に保持されたデータは、その順序性が保証され、また、データの改ざんの防止及び検出が可能なように構成される。
【0088】
次に、トランザクションプール740上では、取得されたハッシュ値に基づいて、さらにマールツリー化が行われる。この一連の流れは、トランザクションデータとしてリアルタイムで流れており、これらのトランザクションデータは、適宜インデックスデータベース760に保存される。
一方で、本発明では、特徴的に、これらのトランザクションデータを階層型ブロックチェーンとして構成し(750)、そのブロックハッシュをインデックスデータベース760に保存していくこともできる。
【0089】
図7における、階層型ブロックチェーン750では、トランザクションプール740において構成されるトランザクションデータを取得し、一例として、ブロックごとのマークルルートを転機する形でエリアごとのブロックチェーン751、752・・・を階層的に構成していく。そして、上位層のブロックチェーン755は、集約ブロックチェーンとして構成される。
本発明の一実施形態においては、階層型ブロックチェーン750のブロックハッシュ値を適宜インデックスデータベース760に保存していくことができる。
【0090】
図8Aに、本発明の一実施形態にかかるデータ収集・分析システムにおける動作をクライアント側からみたフローを示す。同図では、クライアント側からクライアント認証及び時空検索のリクエストを行った場合のフローが示される。ここで、クライアント側とは、ユーザ端末を介してユーザにサービスを提供するサービス提供者や、ユーザ端末が挙げられる。
また、同図において、SDKは、DEPが提供するAPIを含むソフトウェア開発キットに基づいて構築されたソフトウェアモジュールである。一実施形態において、クライアントからは、このSDKを介してAPIに対する要求がなされ、その要求に対する結果が返送される。
【0091】
(時空検索の特徴)
データベースに対する検索(時空検索等)や、データベースからのデータのダウンロードは、SDKによって開発されたアプリケーション(API)を介して行われる。
ここで、本発明の一実施形態にかかる時空検索機能には、次の特徴(a)~(b)がある。
(a)時空検索
検索の基本スタイルは、時間条件及び/または空間条件からなる論理式検索である(これが「時空検索」の実体である)。
時間条件には期間が含まれる。また、空間条件にはジオフェンス(仮想的な境界線で囲まれた任意のエリア)が含まれる。
検索結果は、エンティティ(所定のデータセット)として得られる。
(b)時空検索の柔軟性
時空検索結果であるエンティティから、1次データ~4次データそれぞれの自身の階層に留まらず、4階層のどの階層の証跡も辿ることもできる。具体的には、検索結果として提示されるURIを辿って証跡を参照することができる(証跡URI)。この証跡を検証することにより、1次データ~4次データのどの階層のデータの出自をも割り出すことができる。また、そのデータの精度等をさらに検証して、ユーザ側のアプリケーションでの採用可否を判断することができる。
なお、URI(Uniform Resource Identifier)は、特定のコンテキストによって特定のコンテンツを指定するために使用される。この場合、コンテキストは、URIスキームによって決定される。一例として、プレフィックスとしてのURIに追加され、その後に“://”が続く型式である。一実施形態においては、“http://”に代替されることもできる。
【0092】
図8AのステップS801において、クライアント側からSDKの呼び出しが行われると、ステップS802において、SDKでは呼び出しを行ったクライアントの認証処理が開始され、ステップS803において、クライアント認証APIの呼び出しが行われる。その後、図示しないファイアウォールでの接続元フィルタ処理が行われ、DEPのAPIに到達し、必要なパラメータ取得が行われた後、DEPのアプリ処理として認証処理が行われ、認証結果が返却される。この認証結果は、再びSDKにおいて所得される(ステップS804)。SDKでは、認証トークンとしてクライアント側に返却される(ステップS805)。この認証トークンは、クライアント側にて保持される(ステップS806)。
【0093】
ステップS807において、再びクライアント側からSDKの呼び出しが行われると(ステップS807)、ステップS807において、SDKでは時空検索処理が開始され、ステップS809において、時空検索APIの呼び出しが行われる。その後、時空検索がDEP側で実施され、その結果は、ステップS810においてSDKに返却される。さらに、SDKは、この時空検索結果をクライアント側に返却し(ステップS811)、クライアント側では、その結果が利用されて諸処の処理が行われる(ステップS812)。
【0094】
図8Bに、本発明の一実施形態にかかるデータ収集・分析システムにおける他の動作をクライアント側からみたフローを示す。同図では、クライアント側からデジタルエビデンス取得のリクエストを行った場合のフローが示される。
同図において、SDKは、DEPが提供するAPIを含むソフトウェア開発キットに基づいて構築されたソフトウェアモジュールである。一実施形態において、クライアントからは、このSDKを介してAPIに対する要求がなされ、その要求に対する結果が返送される。
【0095】
図8BのステップS850において、クライアント側からSDKの呼び出しが行われると、ステップS851において、SDKでは呼び出しを行ったクライアントのデジタルエビデンス取得処理が開始され、ステップS852において、デジタルエビデンス取得APIの呼び出しが行われる。その後、図示しないファイアウォールでの接続元フィルタ処理が行われ、DEPのAPIに到達し、必要なパラメータ取得が行われた後、DEPのデジタルエビデンス取得処理としてコンテンツID取得処理等が行われ、取得結果が返却される。この認証結果は、再びSDKにおいて所得される(ステップS853)。SDKでは、取得結果をクライアント側に返却する(ステップS854)。この取得結果は、クライアント側にて保持される(ステップS855)。
【0096】
次に、図9A図9Cを参照して、本発明の一実施形態にかかるデータ収集・分析システムにおいて取り扱われるデータのデータ構造例を示す。図9Aは、ゲートウェイを通過するデータのデータ構造の一形態であるエンティティデータが格納される「エンティティコンテナ」の構造例である。図9Bは、複数のエンティティデータがブロックデータとして格納される「ブロックコンテナ」の構造例である。図9Cは、ブロックデータを立証ないし証明するためのウィットネス部の構造例である。
以下、各データ構造について、詳述する。
【0097】
図9Aにおいて、エンティティコンテナの一単位であるエンティティ910は、バージョン情報(2バイト)911と、ソースID(32バイト)912と、時刻タグ(12バイト)913と、空間タグ(42バイト)914と、エンティティのデータサイズ情報(4バイト)915と、エンティティ本体部(最大2GB)916と、チェックサム(CRC32、4バイト)917とで構成される。
なお、ソースID912は外部でも事後的に生成可能であり、必ずしもデータの生成時にリアルタイムで生成される必要はない。
また、エンティティのデータサイズ915及びエンティティ本体部916は、RTC要求の時刻を処理する際、ソースIDhにGNSSを指定し、エンティティサイズをゼロに設定することもできる。この場合、エンティティ本体部を含まない96バイトを当該RTC発生の「時空スタンプ」とすることができる。
【0098】
時刻タグ913及び空間タグ914は、図9Aに示されるように、さらに詳細にデータフォーマット9131及び9141からなる時空タグとして構成されることができる。このとき、時空タグは、一実施形態において、U-Bloxのバイナリデータ形式に準じて生成されることができる。一例として、UBX-NAV-POSLLH(0x01 0x02)、UBX-NAV-DOP(0x01 0x04)などである。
【0099】
図9Bにおいて、ブロック950は、ヘッダー部951と、ボディ部952とで構成される。
【0100】
ヘッダー部951は、さらに、ゲートウェイブロック部のバージョン情報(2バイト)9511と、時空認証ゲートウェイのソースID(32バイト)9512と、前ブロックの関連情報部9513と、当該ブロックの関連情報部9514と、データスペック部9515とからなる。
また、ボディ部952は、さらに、データエンティティ9521~952nを含む。
【0101】
さらに、詳細の構成例は、同図に図示したとおりである。
【0102】
図9Cにおいて、ウィットネス部970は、ヘッダー部971と、ボディ部972とで構成される。
【0103】
ヘッダー部971は、さらに、ウィットネス部のバージョン情報(2バイト)9711と、対象ブロックの番号(4バイト)9712と、対象ブロックのハッシュ値SHA2-256(32バイト)9713と、対象ブロックのマークルルートハッシュ値SHA2-2567(32バイト)9714とを含む。
また、ボディ部972は、さらに、対象ブロックの電子署名部9721と、電子署名に用いたデジタル証明書のフィンガープリント部(32バイト)9722とを含む。ここで、フィンガープリントの一実施形態として、時空認証ゲートウェイ毎にデジタル証明書をセットし、そのPKIフィンガープリント(SHA2-256)を記録させることができる。
【0104】
図10に、本発明の一実施形態にかかるデータ収集・分析システムにおける4次データの登録動作例を示す。同図では、特に、3次データから4次データへの変換に着目したデータ登録の例示を行っている。
【0105】
図10において、3次データのデータベース1010には、4次データ登録時の入力データが格納されており、例示的に、次のようなパターンのデータが格納されている。
(1)入力されるデータ文字列に定数が含まれているパターン。
(2)入力されるデータ文字列の意味に定数が含まれているパターン。
(3)入力されるデータ(数値)の意味に定数が含まれているパターン。
【0106】
このようなデータベース1010に格納されたデータパターンに対して、所定の変換後に4次データのデータベース1020への登録時には、次のような値が格納されることになる。
(A)定数を展開(計算)した値。
(B)定数を展開しない値。
【0107】
図10においては、実質的に3次データから4次データへの変換が行われて登録処理が実行されているが、この変換処理の詳細をさらに例示的に示すと、「単位変換」、「日付変換」、「SI接頭辞」、「倍率」、「定数」、「計算方法」といった区分において、それぞれ次のように処理される。
【0108】
(1)単位変換
SI単位(SI基本単位、SI組立単位)の場合には変換しない(単位例としては、m、Kg、s、A、K、Pa、W、J等)。
また、SI併用単位の場合にも変換しない(°、L、t等)。
一方、SI単位への変換が1次式以内の計算となる場合には、SI単位へ変換する。(G(加速度)等)。
なお、上記のいずれにも当てはまらないような例外ケースにおいては、変換しない(dBm、UVI等)。
【0109】
(2)日付変換
WellkownTypeが日付関連項目となり、日付文字列は、Date型へ変換される。
【0110】
(3)SI接頭辞
所定の基準に基づき、変換を行う。この際、4次データ側の基準を定めて必要に応じて変換する。たとえば、c、d、da、hの場合は、接頭辞なしに変換され、c、d、da、h以外の場合は、変換しない(…n,μ,m,k,M,G…)といった具合である。
なお、同じWellKnownTypeが既に登録されている場合は、既に登録されている値で変換することができる(例:μT(既に登録)、mT(新規)→μT)。
【0111】
(4)倍率
所定の値で変換される。一実施形態において、4次データ変換においては倍率1で統一されることができる。
【0112】
(5)定数
一実施形態において、定数が入力値に含まれる場合は対象外とし(1π、1e等)、定数の意味が単位に含まれる場合は、変換しないこととできる(1(πrad))。
【0113】
(6)計算方法
一実施形態において、4次データ=3次データ×単位変換係数×倍率係数×SI接頭辞係数×格納SI接頭辞係数とすることができる。
ここで、計算過程においては、以下の基準を採用することができる。
・有効数字+1桁で丸める(ISO丸め)。
・DEPでの有効数字は通常の有効数字で扱う。
・4次要素のデータ型はdecimalとする。
・4次要素の算出は任意精度型で行う。
【0114】
図11に、本発明の一実施形態にかかるデータ収集・分析システムにおける4次データに対する読み出し、応答動作例を示す。
【0115】
図11において、DEP1100は、WellKnownテーブル1110と4次データを格納しているデータベース1120とを含む。
なお、本発明の一実施形態において、WellKnownテーブルを構成するデータタイプは、次表のような構成を有する。
【表2】
【0116】
図11において、API1140を介して受け付けた応答要求は、単位や接頭辞、定数の有無に着目しつつ、適宜、WellKnownテーブル1110及びデータベース1120を参照して応答値の算出を行って、応答要求元に返信する。この応答値の算出に際しては、上述した丸め処理や、定数・単位の付与処理等が行われる。
【0117】
また、図11における検索処理においては、次のような事項が採用されてもよい。
(1)「単位変換」、「SI接頭辞」、「倍率」、「定数」に関して
・リクエスト時に指定の応答単位・接頭辞・定数有無により変換を行う。
・倍率変換は検索の際には行わない。
・単位変換はSI単位、ヤードポンド法(長さ・質量)、尺貫法(長さ・質量)を取扱う。
【0118】
(2)「日付変換」に関して
・ISO8601の標準形式で出力する。また、タイムゾーンはZとする。
【0119】
(3)「計算方法」に関して
・有効数字で丸める(ISO丸め)。
・DEPでの有効数字は通常の有効数字で扱う。
・4次要素のデータ型はdecimalとする。
・4次要素の算出は任意精度型で行う。
【0120】
図12に、本発明の一実施形態にかかるデータ収集・分析システムにおける1次テーブル(1次データ)~4次テーブル(4次データ)までのテーブル間の関係を証跡の観点から示す。
【0121】
図12において、1次テーブル1210、2次テーブル1220、3次テーブル1230、4次テーブル1240の生成関係はすでに説明したとおりであるが、本発明の一実施形態においては、時空検索の結果であるエンティティからそれぞれの次元のテーブルに留まらず、どの階層の証跡も辿ることができる。例えば、4次テーブル1240の検索結果から3次テーブル1230や2次テーブル1220の証跡を辿ることもでき、さらには、2次テーブルを介して1次テーブルの証跡をも辿ることができる(図中、一点破線で示した)。これは、既に説明したとおり、各テーブルが親子関係を持ち、多種多様なデータに対する横断的検索ができるように構成されているためである。具体的は、すでに説明したとおり、検索結果として提示されるURIを辿って証跡を参照することによって他のテーブルの証跡を辿ることができる。
【0122】
なお、本発明は、これに限定されるものではないが、証跡のストレージの一実施形態において、IPFS(InterPlanetary File System)を採用することができる。IPFSは、分散ファイルシステムにデータやコンテンツを保存したり、共有したりできるプロトコルを規定する。一実施形態において、P2Pネットワーク上で動作し、データやコンテンツは、特定のサイズのブロックに分割され、IPFSネットワーク上で共有される。
分散ファイルシステムに保存されたデータやコンテンツを取得するには、分割された各ブロックをIPFSネットワーク上の複数のノードからダウンロードすることにより実施される。
【0123】
このとき、IPFSにおいては、コンテンツ識別子(CID)を使用してファイルを一意に識別することができる。また、IPFSは、httpに替えて独自のウェブ配布を行うことができる。たとえば、本発明の一実施形態における証跡URIは次のように表現される。

ipfs://bafybeigdyrzt5sfp7uda7hu76uh7y26nf3efuylqabf3aclgtqa55fbzdi

IPFSにより、時間の試練に耐えることができる安全で検証可能な分散型の方法で、本発明の実施形態にかかる、あらゆるサイズと形式のデータを表すことができる。
【0124】
コンテンツ識別子(CID)は、IPFSの素材を指すために使用されるラベルということができる。この場合、CIDは、コンテンツが保存されている場所を示すものというよりは、コンテンツ自体に基づいて一種のアドレスが形成されるものである。
【0125】
CIDは、コンテンツの暗号化ハッシュに基づいて生成される。たとえば、コンテンツに違いがある場合には、異なるCIDが生成され、同じ設定を使用して2つの異なる IPFSノードに同じコンテンツを追加すると、同じCIDが生成されるといった具合である。一実施形態において、IPFSは、標準的にsha-256ハッシュアルゴリズムが使用されるが、その他の多くのアルゴリズムをサポートすることもできる。
【0126】
以上のとおり、図面を参照しながら本発明の実施形態について、様々な局面から具体的に説明したが、特許請求の範囲、明細書、要約書、図面に記載された全ての技術的要素、ならびに、方法ないし処理ステップは、これら要素及び/又はステップの少なくとも一部が相互に排他的となる組み合わせを除く任意の組み合わせによって、本発明にかかるシステムならびにプログラムの構成要素ないし構成段階となりうる。
【0127】
また、本発明は、上述した実施形態のいずれの個別具体的な詳細記載に制限ないし限定されることはない。さらに、本発明の技術的範囲は、上述の説明のみによってではなく、特許請求の範囲の記載によってその外延が特定されるものであり、特許請求の範囲と均等となる置換ないし変更も本発明の技術的範囲となるものである。
【符号の説明】
【0128】
10a~10c 測位衛星
11a~11f モノ(Things)
100a、100b データ収集・分析システム
110 IoTセンサ(データ収集・分析システム100の必須構成ではない)
120 時空認証ゲートウェイサーバ
130 基地局
140 デジタルエビデンスプラットフォーム
図1
図2A
図2B
図3A
図3B
図4
図5
図6
図7
図8A
図8B
図9A
図9B
図9C
図10
図11
図12