ホーム > 特許ランキング > 国立大学法人京都大学
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-02-19
(45)【発行日】2024-02-28
(54)【発明の名称】ブロックチェーンネットワークシステム
(51)【国際特許分類】
H04L 9/32 20060101AFI20240220BHJP
G09C 1/00 20060101ALI20240220BHJP
G06F 21/64 20130101ALI20240220BHJP
G06N 20/00 20190101ALI20240220BHJP
【ＦＩ】
H04L9/32 200Z
G09C1/00 640D
G06F21/64
G06N20/00
【請求項の数】
9
(21)【出願番号】P 2020067697
(22)【出願日】2020-04-03
(65)【公開番号】P2021164136
(43)【公開日】2021-10-11
【審査請求日】2023-02-10
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成３０年度、国立研究開発法人科学技術振興機構、戦略的創造研究推進事業「人々の移動に関する実空間情報をリアルタイムに形成するためのデータを目利きできるネットワークＡＩ」委託研究、産業技術力強化法第１７条の適用を受ける特許出願
(73)【特許権者】
【識別番号】504132272
【氏名又は名称】国立大学法人京都大学
(74)【代理人】
【識別番号】100114764
【弁理士】
【氏名又は名称】小林 正樹
(72)【発明者】
【氏名】新熊 亮一
【審査官】行田 悦資
(56)【参考文献】
【文献】特開２０１９－０７４９５６（ＪＰ，Ａ）
【文献】特開２０１９－１５３１３０（ＪＰ，Ａ）
【文献】特開２０１９－１９２２０７（ＪＰ，Ａ）
【文献】特開２０１３－２３９１１５（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ９／３２
Ｇ０９Ｃ １／００
Ｇ０６Ｆ ２１／６４
Ｇ０６Ｎ ２０／００
(57)【特許請求の範囲】
【請求項1】
複数のセンサ装置がブロックチェーンネットワークを介して互いに通信可能な状態で接続され、前記センサ装置で取得したセンサデータをブロックチェーンネットワーク上で分散して管理するブロックチェーンネットワークシステムにおいて、前記センサ装置は、
実空間のセンサデータをフレームごとに逐次取得するセンサ部と、
前記センサ部により取得されたセンサデータを処理するデータ処理部と、
前記センサ部により取得されたセンサデータを保存するデータ保存部と、
前記センサ部により取得されたセンサデータを暗号化する暗号化部と、
前記暗号化部により暗号化されたセンサデータをブロックチェーンネットワーク上に登録する登録部とを備え、
前記データ処理部は、前記センサ部により取得されたセンサデータを所定のフレーム集約数で集約し、前記暗号化部は、前記データ処理部により所定のフレーム集約数で集約されたセンサデータを一括して暗号化することを特徴とするブロックチェーンネットワークシステム。
【請求項2】
前記暗号化部は、前記センサ部により取得されたセンサデータをフレームごとに暗号化したあと、暗号化した各センサデータを所定のフレーム集約数で一括して暗号化する請求項１に記載のブロックチェーンネットワークシステム。
【請求項3】
前記データ処理部は、センサデータを下式[１]の条件を満たすフレーム集約数で集約する請求項１または請求項２に記載のブロックチェーンネットワークシステム。ＴＦ×Ｎ＞Ｔ…[１]
ＴＦ：センサデータのフレーム間隔
Ｎ：フレーム集約数
Ｔ：ブロックチェーンネットワークシステムにおけるセンサデータの登録所要時間
【請求項4】
前記ブロックチェーンネットワークに通信可能な状態で接続されたサーバ装置を備え、前記サーバ装置は、
前記各センサ装置からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部と、
前記サーバ用受信部により受信されたセンサデータに基づいてセンサーデータの特徴モデルを生成する学習部と、
前記学習部により生成された特徴モデルに基づいて、センサデータの重要度を決定する重要度決定部とを備え、
前記センサ装置において、
前記データ処理部は、前記センサ部により取得されたセンサデータについて、前記サーバ装置の前記重要度決定部により決定されたセンサーデータの重要度に基づいて、センサデータの所定のフレーム集約数を設定する請求項１から請求項３のいずれかに記載のブロックチェーンネットワークシステム。
【請求項5】
前記データ処理部は、前記センサ部により取得されたセンサデータについて、前記サーバ装置の前記重要度決定部により決定されたセンサーデータの重要度に基づいて、重要度の高いセンサーデータのフレーム集約数を小さく設定する一方、重要度の低いセンサデータのフレーム集約数を大きく設定する請求項４に記載のブロックチェーンネットワークシステム。
【請求項6】
前記データ処理部は、センサデータを下式［２］で表されるフレーム集約数の平均値で集約する請求項５に記載のブロックチェーンネットワークシステム。Ｎ＝ＮＨ×ＷＨ＋ＮＬ×ＷＬ…[２]
Ｎ：フレーム集約数の平均値
ＮＨ：重要度の高いセンサデータのフレーム集約数
ＷＨ：全てのセンサデータに対する重要度の高いセンサデータの割合
ＮＬ：重要度の低いセンサデータのフレーム集約数
ＷＬ：全てのセンサデータに対する重要度の低いセンサデータの割合
【請求項7】
前記サーバ装置は、前記サーバ用受信部により受信されたセンサデータをフレーム集約数ごとにブロックチェーンネットワークに問い合わせて検証するサーバ用検証部を備え、前記学習部は、前記サーバ用検証部によりセンサデータが適正であると検証された場合、前記サーバ用受信部により受信されたセンサデータに基づいてセンサーデータの特徴モデルを生成する請求項４から請求項６のいずれかに記載のブロックチェーンネットワークシステム。
【請求項8】
前記ブロックチェーンネットワークに接続されたユーザ端末装置を備え、前記ユーザ端末装置は、前記サーバ装置から送信されてきたセンサデータを受信するユーザ用受信部と、
前記ユーザ用受信部により受信されたセンサデータをフレーム集約数ごとにブロックチェーンネットワークに問い合わせて検証するユーザ用検証部と、
前記ユーザ用検証部によりセンサデータが適正であると検証された場合、該センサデータを出力する出力部とを備える請求項４から請求項７のいずれかに記載のブロックチェーンネットワークシステム。
【請求項9】
前記サーバ装置は、前記学習部により生成された特徴モデルに基づいて、前記サーバ用受信部により受信されたセンサデータを監視する監視部を備え、前記監視部は、前記サーバ用受信部により受信されたセンサデータに所定の異常や変化を検知した場合、前記ユーザ端末装置に対して所定の異常や変化を通知する請求項８に記載のブロックチェーンネットワークシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のセンサ装置がブロックチェーンネットワークを介して互いに通信可能な状態で接続され、センサ装置で取得したセンサデータをブロックチェーンネットワーク上で分散して管理するブロックチェーンネットワークシステムに関するものである。
【背景技術】
【0002】
人々の移動により交通の利用、消費が発生して、経済が活性化するが、一方で、移動は、交通事故や、犯罪に巻き込まれたり、ウイルスに感染するといったリスクを生じる。このため、将来のスマートシティの構想において、スマートモニタリングにより移動の安全を保証することが求められる。
【0003】
このスマートモニタリングは、分散配置されたネットワークにより相互接続された多数のセンサがセンサデータを収集し、サーバコンピュータでセンサデータを集約し処理する中央管理型のセンサネットワーク基盤により実現され、事故や、犯罪、ウイルス感染などのリスクを予測的に検知することが可能になる。
【0004】
そして、スマートモニタリングのためのセンサネットワーク基盤のセンサとして、カメラなどの２次元イメージセンサ、ＬＩＤＡＲ（Light Detection and Ranging）などの３次元イメージセンサが、人や車両を検知するのに有利である。
【0005】
ところが、中央管理型のセンサネットワーク基盤の場合、以下の３つの課題があった。 （１）人の顔や、ナンバープレートといったプライバシー情報の保護
（２）改ざんといった不正アクセスに対する強固さ
（３）センサデータや、加工データ、分析モデルの権利の保護
（２）改ざんといった不正アクセスに対する強固さ
（３）センサデータや、加工データ、分析モデルの権利の保護
【0006】
ところで、最近、Ｐ２Ｐネットワーク型のブロックチェーンネットワークが注目されている。このブロックチェーンネットワークとは、データをネットワーク上に配置された複数の端末装置により分散管理するものである。
【0007】
具体的には、ブロックチェーンネットワークで管理されるデータは、そのブロックチェーンネットワークの運用が開始されてから、すべての登録や変更などの履歴が管理されており、誰でもその履歴を閲覧することができる。ブロックチェーンネットワークで管理されるデータの履歴はトランザクションとして一つにまとめられ、このトランザクションをまとめたものをブロックという。ブロックは直列に配置されており、新しく繋がれるブロックが正しければチェーンに繋がれる仕組みとなっている。一般に、ブロックチェーンネットワークシステムは、ネットワークに参加していれば、ソフトウェアをインストールするだけで世界中のどこからでも利用することができる。
【0008】
このブロックチェーンネットワークを利用することにより、中央管理型のセンサネットワーク基盤の課題が下記（１）～（３）のように解決されることが考えられる。
（１）データに対するアクセス権限を限定できる
（２）一方向ハッシュ関数を用いた不正アクセスに対する保護機能がある
（３）データの過去のすべての登録・変更などの履歴をブロックチェーンとして管理できる
（１）データに対するアクセス権限を限定できる
（２）一方向ハッシュ関数を用いた不正アクセスに対する保護機能がある
（３）データの過去のすべての登録・変更などの履歴をブロックチェーンとして管理できる
【先行技術文献】
【非特許文献】
【0009】
【文献】Fernandez-Carames, T. M., and Fraga-Lamas, P. "A Review on the Use of Blockchain for the Internet of Things, " IEEE Access,?6, 32979-33001, 2018.
【文献】Jeong, Y., Hwang, D., and Kim, K. H., "Blockchain-Based Management of Video Surveillance Systems," IEEE International Conference on Information Networking (ICOIN), pp. 465-468, 2019.
【発明の概要】
【発明が解決しようとする課題】
【0010】
しかしながら、ブロックチェーンネットワークは、通常、人による取引に関するデータ（早くても数秒間隔）を想定しており、データのトランザクションの登録が完了するまでに一定の登録所要時間（例えば、平均して３．７秒）がかかっていた。
【0011】
これに対して、センサネットワーク基盤におけるセンサデータは、ビデオ形式のようなストリームデータであり、ブロックチェーンネットワーク上でセンサデータをフレームごとに登録しようとすると、その登録間隔はミリ秒オーダーとなる。
【0012】
このため、ブロックチェーンネットワークだとセンサデータの１回の登録に一定の所要時間（例えば、平均して３．７秒）を要するため、センサデータをフレームごとに頻繁に登録しようとするとブロックチェーンネットワークがオーバーフローするという問題があった。もとより、オーバフローを回避するために、一定の登録所要時間（例えば、平均３．７秒）ごとにセンサデータの一フレームを登録することも考えられるが、これだと多くのデータ欠損が生じるという問題があった。
【0013】
本発明は、上述の問題に鑑みてなされたものであり、センサで取得したセンサデータをブロックチェーンネットワーク上に分散して管理するに際して、センサデータのオーバフローやデータ欠損を防止または軽減することができるブロックチェーンネットワークシステムを提供することを目的とする。
【課題を解決するための手段】
【0014】
本発明は、上記目的を達成するために、複数のセンサ装置がブロックチェーンネットワークを介して互いに通信可能な状態で接続され、前記センサ装置で取得したセンサデータをブロックチェーンネットワーク上で分散して管理するブロックチェーンネットワークシステムにおいて、前記センサ装置は、実空間のセンサデータをフレームごとに逐次取得するセンサ部と、前記センサ部により取得されたセンサデータを処理するデータ処理部と、前記センサ部により取得されたセンサデータを保存するデータ保存部と、前記センサ部により取得されたセンサデータを暗号化する暗号化部と、前記暗号化部により暗号化されたセンサデータをブロックチェーンネットワーク上に登録する登録部とを備え、前記データ処理部は、前記センサ部により取得されたセンサデータを所定のフレーム集約数で集約し、前記暗号化部は、前記データ処理部により所定のフレーム集約数で集約されたセンサデータを一括して暗号化することを特徴とする。
【0015】
また、前記暗号化部は、前記センサ部により取得されたセンサデータをフレームごとに暗号化したあと、暗号化した各センサデータを所定のフレーム集約数で一括して暗号化してもよい。
【0016】
また、前記データ処理部は、センサデータを下式[１]の条件を満たすフレーム集約数で集約してもよい。
【0017】
ＴＦ×Ｎ＞Ｔ…[１]
ＴＦ：センサデータのフレーム間隔
Ｎ ：フレーム集約数
Ｔ ：ブロックチェーンネットワークシステムにおけるセンサデータの登録所要時間
ＴＦ：センサデータのフレーム間隔
Ｎ ：フレーム集約数
Ｔ ：ブロックチェーンネットワークシステムにおけるセンサデータの登録所要時間
【0018】
また、前記ブロックチェーンネットワークに通信可能な状態で接続されたサーバ装置を備え、前記サーバ装置は、前記各センサ装置からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部と、前記サーバ用受信部により受信されたセンサデータに基づいてセンサーデータの特徴モデルを生成する学習部と、前記学習部により生成された特徴モデルに基づいて、センサデータの重要度を決定する重要度決定部とを備え、前記センサ装置において、前記データ処理部は、前記センサ部により取得されたセンサデータについて、前記サーバ装置の前記重要度決定部により決定されたセンサーデータの重要度に基づいて、センサデータの所定のフレーム集約数を設定してもよい。
【0019】
また、前記データ処理部は、前記センサ部により取得されたセンサデータについて、前記サーバ装置の前記重要度決定部により決定されたセンサーデータの重要度に基づいて、重要度の高いセンサーデータのフレーム集約数を小さく設定する一方、重要度の低いセンサデータのフレーム集約数を大きく設定してもよい。
【0020】
また、前記データ処理部は、センサデータを下式［２］で表されるフレーム集約数の平均値で集約してもよい。
【0021】
Ｎ＝ＮＨ×ＷＨ＋ＮＬ×ＷＬ…[２]
Ｎ：フレーム集約数の平均値
ＮＨ：重要度の高いセンサデータのフレーム集約数
ＷＨ：全てのセンサデータに対する重要度の高いセンサデータの割合
ＮＬ：重要度の低いセンサデータのフレーム集約数
ＷＬ：全てのセンサデータに対する重要度の低いセンサデータの割合
Ｎ：フレーム集約数の平均値
ＮＨ：重要度の高いセンサデータのフレーム集約数
ＷＨ：全てのセンサデータに対する重要度の高いセンサデータの割合
ＮＬ：重要度の低いセンサデータのフレーム集約数
ＷＬ：全てのセンサデータに対する重要度の低いセンサデータの割合
【0022】
また、前記サーバ装置は、前記サーバ用受信部により受信されたセンサデータをフレーム集約数ごとにブロックチェーンネットワークに問い合わせて検証するサーバ用検証部を備え、前記学習部は、前記サーバ用検証部によりセンサデータが適正であると検証された場合、前記サーバ用受信部により受信されたセンサデータに基づいてセンサーデータの特徴モデルを生成してもよい。
【0023】
また、前記ブロックチェーンネットワークに接続されたユーザ端末装置を備え、前記ユーザ端末装置は、前記サーバ装置から送信されてきたセンサデータを受信するユーザ用受信部と、前記ユーザ用受信部により受信されたセンサデータをフレーム集約数ごとにブロックチェーンネットワークに問い合わせて検証するユーザ用検証部と、前記ユーザ用検証部によりセンサデータが適正であると検証された場合、該センサデータを出力する出力部とを備えてもよい。
【0024】
また、前記サーバ装置は、前記学習部により生成された特徴モデルに基づいて、前記サーバ用受信部により受信されたセンサデータを監視する監視部を備え、前記監視部は、前記サーバ用受信部により受信されたセンサデータに所定の異常や変化を検知した場合、前記ユーザ端末装置に対して所定の異常や変化を通知してもよい。
【発明の効果】
【0025】
本発明によれば、センサで取得したセンサデータをブロックチェーンネットワーク上に分散して管理するに際して、センサデータのオーバフローやデータ欠損を防止または軽減することができる。このため、実空間のセンサネットワーク基盤において、プライバシー情報の保護、不正アクセスに対する強固さの向上、センサデータや、加工データ、分析モデルの権利の保護を実現することが可能となる。
【図面の簡単な説明】
【0026】
【図1】本発明の第１の実施形態に係るブロックチェーンネットワークシステムの構成概略図である。
【図3】センサデータのフレームの集約を説明するための概念図である。
【図4】センサデータの登録の流れを示すフローチャートである
【図5】第２の実施形態に係るブロックチェーンネットワークシステムの構成概略図である。
【図7】センサデータの重要度を説明するための概念図である。
【図8】センサデータの重要度決定の流れを示すフローチャートである
【図9】第３の実施形態に係るブロックチェーンネットワークシステムの構成概略図である。
【図11】センサデータの監視・出力の流れを示すフローチャートである
【発明を実施するための形態】
【0027】
【0028】
［全体構成］
本システムは、図１に示すように、複数のセンサ装置１がブロックチェーンネットワーク（以下、ＢＣネットワークという）を介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをブロックチェーンネットワーク上で分散して管理する。なお、図１では、３台のセンサ装置１を図示しているが、その他の台数のセンサ装置１が接続されてもよい。
本システムは、図１に示すように、複数のセンサ装置１がブロックチェーンネットワーク（以下、ＢＣネットワークという）を介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをブロックチェーンネットワーク上で分散して管理する。なお、図１では、３台のセンサ装置１を図示しているが、その他の台数のセンサ装置１が接続されてもよい。
【0029】
このセンサデータは、静止画や動画の画像データ、音声データ、動画または静止画の画像や音声が混合して構成されるマルチメディアデータのほか、降水量、積雪量、風向、風速、波高などに関する天気データ、地熱や地中成分などに関する地勢データ、震度などに関する地震データなど、実空間においてセンサにより取得可能なあらゆるデータが挙げられる。
【0030】
また、前記ＢＣネットワークは、そのＢＣネットワークの運用が開始されてから、すべてのセンサデータの登録や変更などの履歴が管理されており、誰でもその履歴を閲覧することができる。ＢＣネットワークで管理されるセンサデータの履歴はトランザクションとして一つにまとめられ、このトランザクションをまとめたものをブロックという。ブロックは直列に配置されており、新しく繋がれるブロックが正しければチェーンに繋がれる仕組みとなっている。一般に、ＢＣネットワークシステムは、ネットワークに参加していれば、ソフトウェアをインストールするだけで世界中のどこからでも利用することができる。
【0031】
［センサ装置１の構成］
前記センサ装置１は、図２に示すように、実空間のセンサデータを取得するセンサ部１１と、センサデータを処理するデータ処理部１２と、センサデータを保存するデータ保存部１３と、センサデータを暗号化する暗号化部１４と、センサデータをＢＣネットワーク上に登録する登録部１５とを備える。
前記センサ装置１は、図２に示すように、実空間のセンサデータを取得するセンサ部１１と、センサデータを処理するデータ処理部１２と、センサデータを保存するデータ保存部１３と、センサデータを暗号化する暗号化部１４と、センサデータをＢＣネットワーク上に登録する登録部１５とを備える。
【0032】
前記センサ部１１は、例えばカメラなどの２次元イメージセンサや、ＬＩＤＡＲ（Light Detection and Ranging）などの３次元イメージセンサなどであって、実空間の画像データ等のセンサデータを所定間隔（例えば、５０ｍｓ）のフレームごとに逐次取得する。
【0033】
前記データ処理部１２は、センサ部１１により取得されたセンサデータをデータ保存部１３に保存させたり、センサ部１１により取得されたセンサデータを所定のフレーム集約数で集約する。本実施形態のセンサデータの集約方法については後述する。
【0034】
前記データ保存部１３は、データ処理部１２の指示によりセンサ部１１により取得されたセンサデータを保存する。なお、本実施形態では、データ保存部１３は、センサ部１１により取得されたセンサデータを逐次保存する。
【0035】
前記暗号化部１４は、データ処理部１２により所定のフレーム集約数で集約されたセンサデータを一括して暗号化するものである。例えば、暗号化部１４は、所定のフレーム集約数で集約されたセンサデータを一括してハッシュ化し、所定桁の数値からなるハッシュ値を生成する。なお、本実施形態では、ハッシュを用いて暗号化したが、その他の方法により暗号化してもよい。
【0036】
前記登録部１５は、前記暗号化部１４により暗号化（ハッシュ化）されたセンサデータ（ハッシュ値）を取得日とＩＤと紐づけて、トランザクションとしてＢＣネットワーク上に登録する。なお、このＢＣネットワーク上に登録されたセンサデータ（トランザクション）は、ＢＣネットワークに接続された各センサ装置１において分散して管理される。
【0037】
［センサデータの集約方法］
上述のように、ＢＣネットワークは、通常、人による取引に関するデータ（早くても数秒間隔）を想定しており、データのトランザクションの登録が完了するまでに一定の登録所要時間（例えば、平均して３．７秒）がかかっていた。
上述のように、ＢＣネットワークは、通常、人による取引に関するデータ（早くても数秒間隔）を想定しており、データのトランザクションの登録が完了するまでに一定の登録所要時間（例えば、平均して３．７秒）がかかっていた。
【0038】
これに対して、センサネットワーク基盤におけるセンサデータは、ビデオ形式のようなストリームデータであり、ＢＣネットワーク上でセンサデータをフレームごとに登録しようとすると、その登録間隔はミリ秒オーダーとなる。
【0039】
このため、ＢＣネットワークだとセンサデータの１回の登録に一定の所要時間（例えば、平均して３．７秒）を要するため、センサデータをフレームごとに頻繁に登録しようとするとＢＣネットワークがオーバーフローするという問題があった。もとより、オーバフローを回避するために、一定の登録所要時間（例えば、平均３．７秒）ごとにセンサデータの一フレームを登録することも考えられるが、これだと多くのデータ欠損が生じるという問題があった。
【0040】
そこで、本発明では、前記データ処理部１２が、センサ部１１により取得されたセンサデータを所定のフレーム集約数で集約する。そして、前記暗号化部１４が、データ処理部１２により所定のフレーム集約数で集約されたセンサデータを一括して暗号化する。そして、前記登録部１５が、前記暗号化部１４により暗号化（ハッシュ化）されたセンサデータ（ハッシュ値）をトランザクションとしてＢＣネットワーク上に登録する。
【0041】
このとき、前記データ処理部１２は、センサデータを下式［１］の条件を満たすフレーム集約数で集約すると、センサデータの登録に際してオーバーフローが生じることを確実に防止できる。
【0042】
ＴＦ×Ｎ＞Ｔ…[１]
ＴＦ：センサデータのフレーム間隔
Ｎ：フレーム集約数
Ｔ：ブロックチェーンネットワークシステムにおけるセンサデータの登録所要時間
ＴＦ：センサデータのフレーム間隔
Ｎ：フレーム集約数
Ｔ：ブロックチェーンネットワークシステムにおけるセンサデータの登録所要時間
【0043】
例えば、図３に示すように、センサデータのフレーム間隔ＴＦが５０ｍｓ、ＢＣネットワークシステムにおけるセンサデータの登録所要時間Ｔが平均３．７秒の場合、フレーム集約数Ｎが７４以上であれば、上式［１］の条件を満たすため、センサデータの登録に際してオーバーフローを確実に防止できる。
【0044】
また、前記データ処理部１２は、暗号化部１４に対してセンサデータを暗号化させる際、前記センサ部１１により逐次取得したセンサデータをフレームごとに暗号化したあと、暗号化した各センサデータを所定のフレーム集約数で一括して暗号化するとよい。
【0045】
なお、ＢＣネットワークシステムにおけるセンサデータの登録所要時間については、例えば、下式［３］で表される。
【0046】
Ｔ＝（Ｎ+１）×Ｔｈ+ＴＣＡ+ＴＴＸ+ＴＯ+Ｔｐｍ …［３］
Ｔｈ：ハッシュ化時間
ＴＣＡ ：ＣＡ（認証機関）の処理時間
ＴＴＸ ：トランザクションの検証時間
ＴO ：Ｏｒｄｅｒｅｒがトランザクションの順序付けをする時間
Ｔｐｍ ：ピアの処理時間の最悪値
Ｔｈ：ハッシュ化時間
ＴＣＡ ：ＣＡ（認証機関）の処理時間
ＴＴＸ ：トランザクションの検証時間
ＴO ：Ｏｒｄｅｒｅｒがトランザクションの順序付けをする時間
Ｔｐｍ ：ピアの処理時間の最悪値
【0047】
上式［３］において、右式の第１項の（Ｎ+１）×Ｔｈ はセンサデータのハッシュ化の総時間を表わすが、これは０．４秒程度と無視できる程度に非常に短い時間である。なお、暗号化部１４は、Ｎ個のフレームのセンサデータをフレームごとに暗号化したあと、暗号化した各センサデータをＮ個で集約した状態で一括して暗号化するため、ハッシュ化時間Ｔに暗号化回数（Ｎ+１）が掛け合わされる。一方、右式の第２項以降のＴＣＡ+ＴＴＸ+ＴＯ+Ｔｐｍは、暗号化したセンサデータをＢＣネットワークに登録すること自体に必要な時間であって、平均して３．７秒と長い時間がかかる。
【0048】
［センサデータの登録の流れ］
次に本システムにおけるセンサデータの登録の流れについて、図４を参照しつつ説明する。
次に本システムにおけるセンサデータの登録の流れについて、図４を参照しつつ説明する。
【0049】
まず、前記センサ部１１は、実空間の画像データ等のセンサデータを所定間隔（例えば、５０ｍｓ）のフレームごとに逐次取得する（Ｓ１）。
【0050】
そして、前記データ処理部１２が、センサ部１１により取得されたセンサデータをデータ保存部１３に保存させる（Ｓ２）。また、前記データ処理部１２が、センサ部１１により取得されたセンサデータを所定のフレーム集約数で集約する（Ｓ３）。
【0051】
そして、前記暗号化部１４が、データ処理部１２により所定のフレーム集約数で集約されたセンサデータを一括して暗号化する（Ｓ４）。
【0052】
そして、前記登録部１５が、前記暗号化部１４により暗号化（ハッシュ化）されたセンサデータ（ハッシュ値）をトランザクションとしてＢＣネットワーク上に登録する（Ｓ５）。
【0053】
【0054】
［全体構成］
本システムは、図５に示すように、サーバ装置２と複数のセンサ装置１がＢＣネットワークを介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをＢＣネットワーク上で分散して管理する。
本システムは、図５に示すように、サーバ装置２と複数のセンサ装置１がＢＣネットワークを介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをＢＣネットワーク上で分散して管理する。
【0055】
［センサ装置１］
前記センサ装置１は、図６に示すように、実空間のセンサデータを取得するセンサ部１１と、センサデータを処理するデータ処理部１２と、センサデータを保存するデータ保存部１３と、センサデータを暗号化する暗号化部１４と、センサデータをＢＣネットワーク上に登録する登録部１５と、センサデータをサーバ装置２に送信する送信部１６を備える。なお、センサ部１１、データ保存部１３、暗号化部１４、登録部１５は、第１の実施形態と同一であるため、その説明を省略する。
前記センサ装置１は、図６に示すように、実空間のセンサデータを取得するセンサ部１１と、センサデータを処理するデータ処理部１２と、センサデータを保存するデータ保存部１３と、センサデータを暗号化する暗号化部１４と、センサデータをＢＣネットワーク上に登録する登録部１５と、センサデータをサーバ装置２に送信する送信部１６を備える。なお、センサ部１１、データ保存部１３、暗号化部１４、登録部１５は、第１の実施形態と同一であるため、その説明を省略する。
【0056】
前記データ処理部１２は、センサ部１１により取得されたセンサデータをデータ保存部１３に保存させたり、センサ部１１により取得されたセンサデータを所定のフレーム集約数で集約する。本実施形態のセンサデータの集約方法については後述する。
【0057】
前記送信部１６は、データ保存部１３に保存されたセンサデータをサーバ装置２に送信する。センサデータの送信に際しては、リアルタイム性を高めるためにデータ保存部１３に保存されたセンサデータを逐次送信してもよいし、センサデータを所定のフレーム数ごとに送信してもよい。
【0058】
［前記サーバ装置２］
前記サーバ装置２は、各センサ装置１からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部２１と、センサデータを認証するサーバ用検証部２２と、センサデータの特徴モデルを生成する学習部２３と、センサデータの特徴モデルを蓄積する特徴モデルデータベース（以下、特徴モデルＤＢ２４という）と、センサデータの重要度を決定する重要度決定部２５とを備える。
前記サーバ装置２は、各センサ装置１からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部２１と、センサデータを認証するサーバ用検証部２２と、センサデータの特徴モデルを生成する学習部２３と、センサデータの特徴モデルを蓄積する特徴モデルデータベース（以下、特徴モデルＤＢ２４という）と、センサデータの重要度を決定する重要度決定部２５とを備える。
【0059】
前記サーバ用検証部２２は、サーバ用受信部２１により受信されたセンサデータをＢＣネットワークに問い合わせて検証するものである。具体的には、サーバ検証部は、サーバ用受信部２１により受信されたセンサデータを所定のフレーム集約数（センサ装置１のデータ処理部１２におけるフレーム集約数と同一）で暗号化（ハッシュ化）して、所定桁の数値からなるハッシュ値を生成して、そのハッシュ値をＢＣネットワーク上で管理されている同センサデータのハッシュ値との比較を行うことにより検証する。このハッシュ値は、少しでも違う文字列データをハッシュ化することで全く違う値になる特性を持っていることから、仮にサーバ用受信部２１により受信されたセンサデータが改ざんされていると、サーバ用検証部２２でのハッシュ値とＢＣネットワーク上のハッシュ値が全く異なる値となるため、データ改ざんを容易に発見することができる。
【0060】
前記学習部２３は、サーバ用検証部２２においてセンサデータが適正（改ざんされていない）と検証された場合、サーバ用受信部２１により受信されたセンサデータに基づいて特徴モデル（ＭＬモデル）を生成する。この特徴モデルは、逐次蓄積されたセンサデータを機械学習することにより生成されるものである。例えば、センサデータが交差点や道路などの画像データの場合、車両や歩行者は一般的に群として移動することが知られており、学習部２３は当該センサデータを蓄積して機械学習により群移動のパターンを特徴モデルとして生成する。
【0061】
前記特徴モデルＤＢ２４は、学習部２３により生成されたセンサデータの特徴モデルを蓄積するものであり、逐次、アップデートされる。
【0062】
前記重要度決定部２５は、サーバ用検証部２２において所定のフレーム集約数のセンサデータの検証が完了したあと、前記学習部２３により生成された特徴モデルに基づいて、センサデータの重要度を決定する。具体的には、重要度決定部２５は、サーバ用受信部２１により受信された各センサデータについて、特徴モデルＤＢ２４に蓄積されているセンサデータの特徴モデルを照らし合わせて、各センサデータの重要度を決定する。
【0063】
例えば、図７に示すように、センサデータが交差点や道路などの画像データの場合、過去の画像データを蓄積して特徴モデルを生成していき、車両や歩行者が続いている場合には事故の発生の確率が高まることを機械学習しているとする。このとき、センサデータの某フレームに車両や歩行者が現れていない場合（Frame k）、そのようなフレームのセンサデータは重要度が低いと評価する。そして、センサデータの某フレームが車両や歩行者が後続しそうである場合（Frame k+1）、その後の車両や歩行者が後続している各フレーム（Frame k+1、Frame k+2、Frame k+3）のセンサデータは重要度が高いと評価する。そして、再び、センサデータの某フレームに車両や歩行者が現れなくなった場合（Frame k+4）、そのようなフレームのセンサデータは重要度が低いと評価する。これらセンサデータの重要度は、センサ装置１に送信され、センサ装置１のデータ処理部１２によるセンサデータのフレームの集約に用いられる。このセンサデータの重要度は数値化されてもよい。
【0064】
なお、前記重要度決定部２５は、サーバ用検証部２２において所定のフレーム集約数のセンサデータの検証が完了する前に、当該センサデータの重要度を決定することによりリアルタイム性を高めるものとしてもよい。
【0065】
［センサデータの集約方法］
前記データ処理部１２は、前記センサ部１１により逐次取得されたセンサデータについて、前記サーバ装置２の重要度決定部２５により決定されたセンサーデータの重要度に基づいて、センサデータを所定のフレーム集約数を設定する。
前記データ処理部１２は、前記センサ部１１により逐次取得されたセンサデータについて、前記サーバ装置２の重要度決定部２５により決定されたセンサーデータの重要度に基づいて、センサデータを所定のフレーム集約数を設定する。
【0066】
具体的には、前記データ処理部１２は、センサ部１１により逐次取得されたセンサデータについて、サーバ装置２の重要度決定部２５により決定されたセンサーデータの重要度に基づいて、重要度の高いセンサーデータのフレーム集約数を小さく設定する一方、重要度の低いセンサデータのフレーム集約数を大きく設定する。
【0067】
例えば、センサデータのフレーム間隔が５０ｍｓ、ＢＣネットワークにおけるセンサデータの登録所要時間Ｔが３．７秒の場合、前記データ処理部１２が、センサデータをフレーム集約数７４以上で集約すれば、ＢＣネットワークにセンサデータを登録するに際してオーバーフローは生じない。ただ、この場合だと、センサデータを取り扱う場合、７４個以上のセンサデータが必要となり、リアルタイム性に欠ける虞がある。
【0068】
そこで、データ処理部１２は、重要度の高いセンサデータのフレーム集約数を２０、重要度の低いセンサデータのフレーム集約数を１００とすれば、センサデータを取り扱う場合、少なくとも重要度の高いセンサデータに関しては２０個のセンサデータさえあればよく、リアルタイム性を向上させることができる。
【0069】
このとき、前記データ処理部１２は、センサデータを下式［１］［２］の条件を満たすフレーム集約数で集約するのが好ましい。
【0070】
ＴＦ×Ｎ＞Ｔ…[１]
ＴＦ：センサデータのフレーム間隔
Ｎ：フレーム集約数
Ｔ：ＢＣネットワークシステムにおけるセンサデータの登録所要時間
ＴＦ：センサデータのフレーム間隔
Ｎ：フレーム集約数
Ｔ：ＢＣネットワークシステムにおけるセンサデータの登録所要時間
【0071】
Ｎ＝ＮＨ×ＷＨ＋ＮＬ×ＷＬ…[２]
Ｎ：フレーム集約数の平均値
ＮＨ：重要度の高いセンサデータのフレーム集約数
ＷＨ：全てのセンサデータに対する重要度の高いセンサデータの割合
ＮＬ：重要度の低いセンサデータのフレーム集約数
ＷＬ：全てのセンサデータに対する重要度の低いセンサデータの割合
Ｎ：フレーム集約数の平均値
ＮＨ：重要度の高いセンサデータのフレーム集約数
ＷＨ：全てのセンサデータに対する重要度の高いセンサデータの割合
ＮＬ：重要度の低いセンサデータのフレーム集約数
ＷＬ：全てのセンサデータに対する重要度の低いセンサデータの割合
【0072】
例えば、重要度の高いセンサデータのフレーム集約数ＮＨが２０、全てのセンサデータに対する重要度の高いセンサデータの割合ＷＨ が１／４、重要度の低いセンサデータのフレーム集約数ＮＬ が１００、全てのセンサデータに対する重要度の低いセンサデータの割合ＷＬ が３／４とすれば、フレーム集約数の平均値は８０となって、登録所要時間Ｔ（平均して３．４秒）を満たすフレーム集約数７４を上回るため、オーバーフローを防止できる。
【0073】
［センサデータの重要度決定の流れ］
次に本システムにおけるセンサデータの重要度決定の流れについて、図８を参照しつつ説明する。
次に本システムにおけるセンサデータの重要度決定の流れについて、図８を参照しつつ説明する。
【0074】
まず、前記センサ装置１において、前記センサ部１１は、実空間の画像データ等のセンサデータを所定間隔（例えば、５０ｍｓ）のフレームごとに逐次取得する（Ｓ１１）。
【0075】
そして、前記データ処理部１２が、センサ部１１により取得されたセンサデータをデータ保存部１３に保存させる（Ｓ１２）。
【0076】
そして、前記送信部１６が、データ保存部１３に保存されているセンサデータをサーバ装置２に送信する（Ｓ１３）。
【0077】
次に、前記サーバ装置２において、前記サーバ用受信部２１が、センサ装置１からネットワークを介して送信されてきたセンサデータを受信する（Ｓ１４）。
【0078】
そして、前記サーバ用検証部２２は、サーバ用受信部２１により受信されたセンサデータをＢＣネットワークに問い合わせて検証する（Ｓ１５）。
【0079】
そして、前記学習部２３は、サーバ用検証部２２においてセンサデータが適正（改ざんされていない）と検証された場合、サーバ用受信部２１により受信されたセンサデータに基づいて特徴モデルを生成する（Ｓ１６）。
【0080】
そして、前記重要度決定部２５は、サーバ用検証部２２において所定のフレーム集約数のセンサデータの検証が完了したあと、前記学習部２３により生成された特徴モデルに基づいて、センサデータの重要度を決定する（Ｓ１７）。このセンサデータの重要度は、サーバ装置２からセンサ装置１に送信され、センサ装置１においてセンサデータのフレーム集約数の設定に用いられる。
【0081】
なお、センサデータの登録の流れについては、第１の実施形態と同一であるため、その説明を省略する。
【0082】
【0083】
［全体構成］
本システムは、図１に示すように、サーバ装置２、ユーザ端末装置３および複数のセンサ装置１がＢＣネットワークを介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをＢＣネットワーク上で分散して管理する。なお、センサ装置１は、第２の実施形態と構成が同一であるため、その説明を省略する。
本システムは、図１に示すように、サーバ装置２、ユーザ端末装置３および複数のセンサ装置１がＢＣネットワークを介して互いに通信可能な状態で接続され、センサ装置１で取得したセンサデータをＢＣネットワーク上で分散して管理する。なお、センサ装置１は、第２の実施形態と構成が同一であるため、その説明を省略する。
【0084】
［サーバ装置２］
前記サーバ装置２は、各センサ装置１からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部２１と、センサデータを検証するサーバ用検証部２２と、センサデータの特徴モデルを生成する学習部２３と、センサデータの特徴モデルを蓄積する特徴モデルＤＢ２４と、センサデータの重要度を決定する重要度決定部２５と、センサデータを監視する監視部２６と、センサデータをユーザ端末装置３に転送する転送部２７とを備える。なお、サーバ用受信部２１、サーバ用検証部２２、学習部２３、特徴モデルＤＢ２４、重要度決定部２５は、第２の実施形態と同一であるため、その説明を省略する。
前記サーバ装置２は、各センサ装置１からネットワークを介して送信されてきたセンサデータを受信するサーバ用受信部２１と、センサデータを検証するサーバ用検証部２２と、センサデータの特徴モデルを生成する学習部２３と、センサデータの特徴モデルを蓄積する特徴モデルＤＢ２４と、センサデータの重要度を決定する重要度決定部２５と、センサデータを監視する監視部２６と、センサデータをユーザ端末装置３に転送する転送部２７とを備える。なお、サーバ用受信部２１、サーバ用検証部２２、学習部２３、特徴モデルＤＢ２４、重要度決定部２５は、第２の実施形態と同一であるため、その説明を省略する。
【0085】
前記監視部２６は、学習部２３により生成された特徴モデルに基づいて、サーバ用受信部２１により受信されたセンサデータを監視するものであって、サーバ用受信部２１により受信されたセンサデータに所定の異常や変化を検知した場合、ユーザ端末装置３に対して所定の異常や変化を通知する。
【0086】
前記転送部２７は、ユーザ端末装置３からの要求に応じて、サーバ用受信部２１により受信されたセンサデータをユーザ端末装置３に転送する。
【0087】
［ユーザ端末装置３］
前記ユーザ情報端末は、サーバ装置２から送信されてきたセンサデータを受信するユーザ用受信部３１と、ユーザ用受信部３１により受信されたセンサデータを検証するユーザ用検証部３２と、センサデータを出力する出力部３３とを備える。
前記ユーザ情報端末は、サーバ装置２から送信されてきたセンサデータを受信するユーザ用受信部３１と、ユーザ用受信部３１により受信されたセンサデータを検証するユーザ用検証部３２と、センサデータを出力する出力部３３とを備える。
【0088】
前記ユーザ用受信部３１は、サーバ装置２の監視部２６から所定の異常や変化を通知された場合、前記サーバ装置２に対してセンサデータを要求して、サーバ装置２から送信されてきたセンサデータを受信する。
【0089】
前記ユーザ用検証部３２は、ユーザ用受信部３１により受信されたセンサデータをＢＣネットワークに問い合わせて検証するものである。センサデータの検証方法は、第２の実施形態のサーバ用検証部２２と同一であるため、その説明を省略する。
【0090】
前記出力部３３は、ユーザ用検証部３２においてセンサデータが適正（改ざんされていない）と検証された場合、ユーザ用受信部３１により受信されたセンサデータをアラートなどの形式で出力する。
【0091】
このとき、前記センサ装置１において、センサデータの重要度に基づいて重要度の高いセンサデータのフレーム集約数を少なく設定している場合、ユーザ端末装置３において、重要度の高いセンサデータについては、少ないフレーム集約数にて検証することができるため、重要度の高いセンサデータをリアルタイムに取り扱うことができる。
【0092】
なお、センサ装置１において重要度の高いセンサデータを登録するのにも登録所要時間（例えば、平均３．７秒）がかかるが、当該重要度の高いセンサデータがセンサ装置１からサーバ装置２を介してユーザ端末装置３に到達するまでに一定程度の時間がかかることから、重要度が高いセンサデータがユーザ端末装置３に到達したときには、当該登録所要時間を経過または経過直前の状態であるため、ユーザ端末装置３においてセンサデータを検証できる状態またはほぼできる状態となっている。
【0093】
［センサデータの監視・出力の流れ］
次に本システムにおけるセンサデータの監視・出力の流れについて、図１１を参照しつつ説明する。
次に本システムにおけるセンサデータの監視・出力の流れについて、図１１を参照しつつ説明する。
【0094】
まず、サーバ装置２において、前記監視部２６が、学習部２３により生成された特徴モデルに基づいて、サーバ用受信部２１により受信されたセンサデータを監視し、サーバ用受信部２１により受信されたセンサデータに所定の異常や変化を検知した場合、ユーザ端末装置３に対して所定の異常や変化を通知する（Ｓ２１）。
【0095】
次に、ユーザ端末装置３において、ユーザ用受信部３１が、サーバ装置２の監視部２６から所定の異常や変化を通知された場合、前記サーバ装置２に対してセンサデータを要求する（Ｓ２２）。
【0096】
次に、サーバ装置２において、前記転送部２７が、ユーザ端末装置３からの要求に応じて、サーバ用受信部２１により受信されたセンサデータをユーザ端末装置３に転送する（Ｓ２３）。
【0097】
次に、ユーザ端末装置３において、前記ユーザ用受信部３１が、サーバ装置２から送信されてきたセンサデータを受信する（Ｓ２４）。
【0098】
そして、前記ユーザ用検証部３２は、ユーザ用受信部３１により受信されたセンサデータをＢＣネットワークに問い合わせて検証する（Ｓ２５）。
【0099】
そして、前記出力部３３は、ユーザ用検証部３２においてセンサデータが適正（改ざんされていない）と検証された場合、ユーザ用受信部３１により受信されたセンサデータをアラートなどの形式で出力する（Ｓ２６）。
【0100】
なお、センサデータの登録の流れ、センサデータの重要度の決定の流れについては、第１の実施形態、第２の実施形態と同一であるため、その説明を省略する。
【実施例1】
【0101】
実施例１として、センサ装置１およびサーバ装置２において、交差点の状況を監視して、機械学習により事故が発生しやすいパターンを検知した場合、サーバ装置２からスマートモニタリングの監視員のユーザ端末装置３に通知し、該ユーザ端末装置３において交差点のセンサデータ（画像データ）が出力されることが考えられる。
【0102】
本発明を用いない場合、センサ装置１においてセンサデータをＢＣネットワークに登録するのに平均３．７秒かかるため、ＢＣネットワークに登録されるセンサデータが欠損するか、オーバーフローして登録が完了しない虞がある。
【0103】
本発明を用いれば、センサデータのフレーム間隔ＴＦが５０ｍｓ（フレームレート２０ｆｐｓ）、フレーム集約数７４以上で集約すれば、データも欠損しないし、オーバーフローもしない。
【0104】
ただ、この場合、サーバ装置２やユーザ端末装置３では、フレーム集約数と同じフレーム数７４以上のセンサデータを受信しなければ検証を行うことができない。このため、重要度の高いセンサデータのフレーム集約数を小さく設定する。例えば、フレーム集約数を２０にすると、サーバ装置２やユーザ端末装置３は１秒ごとにセンサデータを取り扱うことができる。
【0105】
なお、このときでも、重要度の低いセンサデータのフレーム数を大きく（例えば、ＮＬ＝１００）設定すれば、平均的に７４以上のフレーム集約数で集約することができるため、センサデータのリアルタイム性を確保しながら、センサデータ全体のオーバーフローを防止できる。
【実施例2】
【0106】
実施例２として、センサ装置１およびサーバ装置２において、交差点の状況を監視して、機械学習により事故が発生しやすいパターンを検知した場合、サーバ装置２から自動車（ユーザ端末装置３）に通知し、該自動車（ユーザ端末装置３）において交差点のアラートが出力されることが考えられる。
【実施例3】
【0107】
実施例３として、センサ装置１およびサーバ装置２において、公共交通機関が近くにない場所で屋内から多くの歩行者が出てくるのを検知した場合、サーバ装置２からスマート配車システム（ユーザ端末装置３）にその旨を通知し、スマート配車システムから各タクシーに通知されることにより、当該場所の近辺を走行しているタクシーが予測的に当該場所に向かうことが考えられる。
【実施例4】
【0108】
実施例４として、センサ装置１およびサーバ装置２において、ショッピングモールや博物館などの屋内において、機械学習により動きのパターンが不自然な不審者を検知した場合、サーバ装置２からスマートモニタリングシステム（ユーザ端末装置３）に通知し、警備員が予測的に不審者に声をかけに向かったり、スマートモニタリングがその不審者の動きを追跡することが考えられる。
【0109】
以上、図面を参照して本発明の実施形態を説明したが、本発明は、図示した実施形態のものに限定されない。図示された実施形態に対して、本発明と同一の範囲内において、あるいは均等の範囲内において、種々の修正や変形を加えることが可能である。
【符号の説明】
【0110】
１…センサ装置
１１…センサ部
１２…データ処理部
１３…データ保存部
１４…暗号化部
１５…登録部
１６…送信部
２…サーバ装置
２１…サーバ用受信部
２２…サーバ用検証部
２３…学習部
２４…特徴モデルＤＢ
２５…重要度決定部
２６…監視部
２７…転送部
３…ユーザ端末装置
３１…ユーザ用受信部
３２…ユーザ用検証部
３３…出力部
１１…センサ部
１２…データ処理部
１３…データ保存部
１４…暗号化部
１５…登録部
１６…送信部
２…サーバ装置
２１…サーバ用受信部
２２…サーバ用検証部
２３…学習部
２４…特徴モデルＤＢ
２５…重要度決定部
２６…監視部
２７…転送部
３…ユーザ端末装置
３１…ユーザ用受信部
３２…ユーザ用検証部
３３…出力部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
