以下、図面を参照しながら、本発明の実施の形態に係るデータ流通システムを説明する。各図面においては、同一又は同等の部分に同一の符号を付す。
(実施の形態1)
図1を参照しながら、実施の形態1に係るデータ流通システム1を説明する。データ流通システム1は、例えば、機器データの取引のために構築されるシステムである。データ流通システム1は、データ収集サーバ10と、複数のストレージサーバ11と、データ利用サーバ20と、複数のストレージサーバ21と、複数の機器30と、を備える。データ流通システム1は、本発明に係るデータ流通システムの一例である。図1では、ストレージサーバ11及びストレージサーバ21をそれぞれ3つずつ示しているが、必ずしも3台でなくてもよい。
データ収集サーバ10は、例えば機器30の製造者が運営するメーカサーバである。データ収集サーバ10は、機器30から機器データを受信し、ストレージサーバ11に保存する。データ収集サーバ10は、ストレージサーバ11に保存された機器データを取り出し、当該機器データを含む流通データをデータ利用サーバ20に送信する。なお、データ収集サーバ10は、データ収集サーバ10の運営者以外が製造した機器30の機器データを受信可能であってもよい。データ収集サーバ10は、本発明に係るデータ収集サーバの一例である。
ストレージサーバ11は、例えばクラウドプロバイダが運営するクラウドストレージサーバである。例えば、データ収集サーバ10の運営者は、データ保存量、データ読み出し量等に応じた利用料をストレージサーバ11の運営者に支払う。ストレージサーバ11は、本発明に係る記憶手段の一例である。
複数のストレージサーバ11はそれぞれ、例えば図2に示す特性を有する。図2に示される3つのストレージサーバ11をそれぞれストレージA、ストレージB、ストレージCと称する。保存料金とは、ストレージサーバ11に一定量、例えば1ギガバイトのデータを保存したときに課金される料金を示す。保存料金とデータ保存料とに比例して、課金される料金が増加する。取り出し料金とは、ストレージサーバ11から一定量、例えば1ギガバイトのデータを取り出すときに課金される料金を示す。取り出し料金とデータ取り出し量とに比例して、課金される料金が増加する。取り出し速度とは、ストレージサーバ11からデータを取り出す速度を示す。
ストレージAは、保存料金は高いが取り出し料金が無料であり、取り出し速度も速いので、サイズが小さく使用頻度の高いデータを保存するのに好適である。ストレージAは、例えばSSD(Solid State Drive)のような、高速だが低容量で高価な二次記憶装置を主として構築される。ストレージBは、保存料金は安く取り出し速度が普通だが取り出し料金が高いため、サイズが比較的大きく、使用頻度はやや低いが1週間毎、1ヶ月毎など定期的に統計処理の対象となるデータを保存するのに好適である。ストレージBは、例えばHDD(Hard Disk Drive)のような、あまり高速ではないが比較的容量が多く、価格もさほど高くない二次記憶装置を主として構築される。ストレージCは、保存料金も取り出し料金も安いが取り出し速度が遅いため、定期的な使用が想定され難いデータを保存するのに好適である。ストレージCは、例えばテープドライブのような、低速だが大容量で安価な二次記憶装置を主として構築される。
再び図1を参照する。データ利用サーバ20は、例えば機器データに基づくサービスを契約者に提供するサービサが運営するサービササーバである。サービサは、データ利用サーバ20により契約者に各種サービスを提供する。機器データに基づくサービスの例として、機器データに基づいて契約者の家庭内の機器30の動作状況を把握する見守りサービス、1ヶ月間の機器データに基づいて節電プランを契約者に提案する節電提案サービス等が挙げられる。
データ利用サーバ20は、データ収集サーバ10に流通データの要求をする。データ利用サーバ20は、データ収集サーバ10が要求に応じて送信した流通データを受信し、ストレージサーバ21に保存する。データ利用サーバ20は、保存した流通データに含まれる機器データに基づき、契約者にサービスを提供する。データ利用サーバ20は、本発明に係るデータ利用サーバの一例である。
ストレージサーバ11と同様に、ストレージサーバ21は、例えばクラウドプロバイダが運営するクラウドストレージサーバである。例えば、データ利用サーバ20の運営者は、データ保存量、データ読み出し量等に応じた利用料をストレージサーバ21の運営者に支払う。ストレージサーバ21は、本発明に係る記憶手段の一例である。複数のストレージサーバ21はそれぞれ、例えば図2に示す特性を有する点もストレージサーバ11と同様である。
機器30は、例えば、データ収集サーバ10との通信機能を有するIoT機器である。機器30の例として、エアコン、給湯機、調理器等の電気機器、電力計、温度計、風量計等のセンサ機器が挙げられる。機器30は、自身の動作、状態等に関する情報を機器データとしてデータ収集サーバ10に送信する。機器30は、本発明に係る機器の一例である。
機器データの一例を図3に示す。機種データは、当該機器30を個別に識別する機器ID(IDentifier)と、機器30の動作、状態等の内容の情報と、当該動作、状態等を検知した日時である検知日時の情報とを含む。機器30を個別に識別する機器IDとして、例えば機器30の型番と機器30のシリアルナンバーとを連結した文字列が採用可能である。動作の検知は、例えばユーザの操作により当該動作が行われる際に行われる。状態の検知は、例えば1時間毎などの一定時間間隔で行われる。機器30は、機器30の動作、状態等を検知したタイミングで即時に機器データをデータ収集サーバ10に送信してもよいし、機器データを即時には送信せずに一時的に保存し、保存された機器データを一定時間毎にまとめて送信してもよい。機器データは、例えばJSON(JavaScript Object Notation)、XML(Extensible Markup Language)などの形式により表される。
図1では、機器30とデータ収集サーバ10とが接続され、データ収集サーバ10とストレージサーバ11とが接続され、データ収集サーバ10とデータ利用サーバ20とが接続され、データ利用サーバ20とストレージサーバ21とが接続されているように図示されている。しかし、物理的な通信線によりこのような接続がされていなくともよい。例えば、図4に示すように、データ収集サーバ10、ストレージサーバ11、データ利用サーバ20、ストレージサーバ21及び機器30がインターネットNTに接続され、各サーバ及び機器30がインターネットNTを介して通信するものであってもよい。また、全てのサーバ及び機器30がインターネットNTを介して通信するものでなくてもよい。例えば、機器30とデータ収集サーバ10とが、インターネットNTではなくLPWAN(Low Power Wide Area Network)により形成された無線センサネットワーク上で通信をし、他の通信はインターネットNT上で行われるものであってもよい。
データ収集サーバ10とデータ利用サーバ20との通信は、例えば予め定められたWeb API(Web Application Programming Interface)により行われる。例えば、データ収集サーバ10が当該Web APIに準拠したインタフェースを有するWeb APIサーバであり、データ利用サーバ20が、Web APIサーバであるデータ収集サーバ10と通信するWeb APIクライアントである。データ利用サーバ20は、データ収集サーバ10の運営者とは異なる運営者が運営するデータ収集サーバと通信する場合であっても、当該データ収集サーバが当該Web APIに準拠している限り、データ収集サーバ10と通信する場合と同様に通信することができる。また、セキュリティの面から、Web APIによる通信は、HTTPS(Hyper Text Transfer Protocol Secure)上で行われることが好ましい。
次に、図5を参照しながら、データ収集サーバ10の機能的構成を説明する。データ収集サーバ10は、通信部100と制御部110と記憶部120とを備える。
通信部100は、例えばインターネットNTと通信可能なネットワークインタフェースである。通信部100は、機器30、ストレージサーバ11及びデータ利用サーバ20と通信する。通信部100は、特に、機器30から機器データを受信し、データ利用サーバ20に後述の流通データを送信する。通信部100は、本発明に係る受信手段及び送信手段の一例である。
制御部110は、データ収集サーバ10を統括的に制御する。制御部110は、意味特定部1101と、使用頻度推定部1102と、付帯情報作成部1103と、データ保存部1104と、取り出し条件決定部1105と、データ取り出し部1106と、を備える。
意味特定部1101は、通信部100が機器30から受信した機器データの意味を特定する。意味特定部1101は、本発明に係る意味特定手段の一例である。機器データの意味を特定することの一例を図6に示す。例えば、機器30の機器種別がエアコンであり、機器データに含まれる内容が冷房ONである場合、当該機器データの意味はON/OFF制御であると特定する。なお、機器種別は機器データに含まれる機器IDから特定可能である。機器データの意味の特定は、例えば後述の記憶部120に保存された、機器データの内容と意味との対応付けを表すテーブルに基づいて行われる。
使用頻度推定部1102は、意味特定部1101が特定した機器データの意味に基づいて、当該機器データの使用頻度を推定する。使用頻度推定部1102は、本発明に係る使用頻度推定手段の一例である。
ここで、機器データの使用頻度とは、当該機器データがストレージサーバ11に保存されたと仮定したときの、当該保存された機器データの使用頻度である。例えば、機器データがON/OFF制御を意味するデータである場合、当該機器データは頻繁に利用されることが想定される。したがって、当該機器データがストレージサーバ11に保存されたと仮定したとき、当該保存された機器データの使用頻度は高いと考えられる。一方、機器データの意味が風向制御である場合、風向設定が変更される頻度は低く、かつ風向制御のデータは利用頻度が低いと考えられるため、当該機器データの使用頻度は低いと考えられる。
機器データの意味に基づいて使用頻度を推定することの一例を図7に示す。例えば、機器データの意味がON/OFF制御である場合、当該機器データの使用頻度は「高」と推定される。機器データの使用頻度の推定は、例えば後述の記憶部120に保存された、機器データの意味と使用頻度との対応付けを表すテーブルに基づいて行われる。この場合、使用頻度推定部1102は、意味特定部1101により特定された意味に対応して予め定められた使用頻度を当該機器データの使用頻度として推定する。
付帯情報作成部1103は、機器データに対応する付帯情報を作成する。付帯情報作成部1103は、特に、意味特定部1101により特定された意味の情報と、使用頻度推定部1102により推定された使用頻度の情報とを含む付帯情報を作成する。付帯情報は、上記の情報以外に、例えば、機器データがどの機器種別の電気機器によるものかを示す機器種別の情報を含む。付帯情報は、例えばJSON Schema、XML Schema、DTD(Document Type Definition)などのスキーマ言語により表される。
データ保存部1104は、使用頻度推定部1102により推定された使用頻度に応じたストレージサーバ11に機器データを保存する。使用頻度に応じたストレージサーバ11とは、機器データの使用頻度の高低に対応して保存先となるべきストレージサーバ11をいう。例えば図2に示す例では、使用頻度が「高」の機器データはストレージAに保存されることが好ましい。同様に、使用頻度が「中」の機器データはストレージBに、使用頻度が「低」の機器データはストレージCに保存されることが好ましい。データ保存部1104は、本発明に係る保存手段の一例である。
また、データ保存部1104は、付帯情報作成部1103により作成された付帯情報を、対応する機器データと関連付けてストレージサーバ11に保存する。この際、付帯情報は、対応する機器データの使用頻度が「高」でない場合であっても、使用頻度「高」に対応するストレージサーバ11、例えばストレージAに保存してもよい。付帯情報は、データの取り出しの際に「索引」として用いられることが考えられるため、機器データそのものよりも使用頻度が高くなることが想定され、また機器データそのものよりも小容量だからである。付帯情報をストレージAに保存する場合、当該付帯情報は、他のストレージサーバ11に保存される機器データへのリンクを示す情報を含む。
ストレージサーバ11に保存されるデータの一例を図8に示す。図8では、「高」「中」「低」の全ての使用頻度に係るデータをまとめて示しているが、上記のとおり、保存先のストレージサーバ11は使用頻度に応じてそれぞれ異なる。
機器データ及び関連する付帯情報が各ストレージサーバ11に保存される様子の一例を図9に示す。図9に示す例では、使用頻度「高」の機器データ及び対応する付帯情報がストレージAに、使用頻度「中」の機器データ及び対応する付帯情報がストレージBに、使用頻度「低」の機器データ及び対応する付帯情報がストレージCに保存されている。
機器データ及び関連する付帯情報が各ストレージサーバ11に保存される様子の別の一例を図10に示す。図10に示す矢印は、付帯情報から機器データへのリンクを表す。図10に示す例では、図9の場合と異なり、付帯情報は全てストレージA、つまり使用頻度「高」に対応するストレージサーバ11に保存されている。そして、使用頻度「高」以外の機器データに対応する付帯情報は、他のストレージサーバ11に保存されている機器データへのリンクを含む。
再び図5を参照する。取り出し条件決定部1105は、通信部100がデータ利用サーバ20から受信したデータ要求に基づいて、ストレージサーバ11からの取り出し対象となるべき機器データの取り出し条件を決定する。取り出し条件決定部1105は、例えば、データ利用サーバが直近1ヶ月間のエアコンのON/OFF制御に関する流通データを要求したとき、「機器データが示す日時が直近1ヶ月以内であり、機器データに対応する付帯情報が示す意味がエアコンのON/OFF制御である」ことを取り出し条件として決定する。
データ取り出し部1106は、取り出し条件決定部1105により決定された取り出し条件に応じて、ストレージサーバ11から機器データ及び付帯情報を取り出す。データ取り出し部1106は、本発明に係るデータ取り出し手段の一例である。
制御部110は、通信部100を介して、データ取り出し部1106が取り出した機器データ及び付帯情報を含む流通データをデータ利用サーバ20に送信する。したがって、流通データには、機器データと当該機器データの意味の情報と当該機器データの使用頻度の情報とが含まれる。
制御部110は、上記のほか、データ処理のために必要な処理などの各種処理を実行する。
記憶部120は、制御部110によるデータ収集サーバ10の制御に必要な各種情報を記憶する。例えば、上記のとおり、記憶部120は、機器データの内容と意味との対応付けを表すテーブル及び機器データの意味と使用頻度との対応付けを表すテーブルを記憶する。
次に、図11を参照しながら、データ利用サーバ20の機能的構成を説明する。データ利用サーバ20は、通信部200と制御部210と記憶部220とを備える。
通信部200は、例えばインターネットNTと通信可能なネットワークインタフェースである。通信部200は、データ収集サーバ10及びストレージサーバ21と通信する。通信部200は、特に、データ収集サーバ10から流通データを受信する。通信部200は、本発明に係る受信手段の一例である。
制御部210は、データ利用サーバ20を統括的に制御する。制御部210は、データ要求部2101とデータ保存部2102とを備える。
データ要求部2101は、通信部200を介して、データ収集サーバ10に流通データの送信を要求する。要求内容は、例えば、「直近3日間のエアコンのON/OFF制御のデータが欲しい」、「直近1ヶ月間で室温が30℃以上となったデータが欲しい」など、特定の条件を満たすデータの要求である。
データ保存部2102は、通信部200が受信した流通データを、流通データに含まれる使用頻度に応じたストレージサーバ21に保存する。データ保存部2102は、本発明に係る保存手段の一例である。
制御部210は、上記のほか、サービスの提供に必要な処理、データ処理のために必要な処理等の各種処理を実行する。
次に、データ収集サーバ10のハードウェア構成の一例を、図12を参照しながら説明する。図12に示すデータ収集サーバ10は、例えばパーソナルコンピュータ、マイクロコントローラなどのコンピュータにより実現される。
データ収集サーバ10は、バス8000を介して互いに接続された、プロセッサ8001と、メモリ8002と、インタフェース8003と、二次記憶装置8004と、を備える。
プロセッサ8001は、例えばCPU(Central Processing Unit: 中央演算装置)である。プロセッサ8001が、二次記憶装置8004に記憶された動作プログラムをメモリ8002に読み込んで実行することにより、データ収集サーバ10の各機能が実現される。
メモリ8002は、例えば、RAM(Random Access Memory)により構成される主記憶装置である。メモリ8002は、プロセッサ8001が二次記憶装置8004から読み込んだ動作プログラムを記憶する。また、メモリ8002は、プロセッサ8001が動作プログラムを実行する際のワークメモリとして機能する。
インタフェース8003は、例えばシリアルポート、ネットワークインタフェースなどのI/O(Input/Output)インタフェースである。インタフェース8003により、通信部100の機能が実現される。
二次記憶装置8004は、例えば、フラッシュメモリ、HDD、SSDである。二次記憶装置8004は、プロセッサ8001が実行する動作プログラムを記憶する。また、二次記憶装置8004により、記憶部120の機能が実現される。
また、データ利用サーバ20も同様に、例えば図12に示すハードウェア構成をとることができる。
次に、図13を参照しながら、データ収集サーバ10によるデータ保存の動作の一例を説明する。当該動作は、制御部110の制御により実行される。
まず、通信部100が、機器30からの機器データの受信を待ち受ける(ステップS101)。通信部100が機器データを受信したら次の動作に進む。
次に、意味特定部1101が、受信された機器データの意味を特定する(ステップS102)。上記のとおり、機器データの意味の特定は、例えば、記憶部120に保存された、機器データの内容と意味との対応付けを表すテーブルに基づいて行われる。
次に、使用頻度推定部1102が、意味特定部1101により特定された意味に基づいて、受信された機器データの使用頻度を推定する(ステップS103)。上記のとおり、使用頻度の推定は、例えば、記憶部120に保存された、機器データの意味と使用頻度との対応付けを表すテーブルに基づいて行われる。
次に、付帯情報作成部1103が、意味特定部1101により特定された意味の情報と、使用頻度推定部1102により推定された使用頻度の情報とを含み、受信された機器データに対応する付帯情報を作成する(ステップS104)。
次に、データ保存部1104が、推定された使用頻度に応じたストレージサーバ11に、機器データと付帯情報とを関連付けて保存する(ステップS105)。ただし、上記のとおり、付帯情報は使用頻度「高」に対応するストレージサーバ11に保存してもよい。
データ保存後、制御部110は、ステップS101からの動作の流れを繰り返す。
次に、図14を参照しながら、データ収集サーバ10及びデータ利用サーバ20によるデータ流通の動作の一例を説明する。
まず、データ利用サーバ20がデータ要求部2101により、データ収集サーバ10に流通データの送信を要求する(ステップT101)。
次に、データ要求をデータ利用サーバ20から受信したデータ収集サーバ10が、取り出し条件決定部1105により、受信したデータ要求に基づいて取り出し条件を決定する(ステップT102)。
次に、データ収集サーバ10がデータ取り出し部1106により、決定した取り出し条件に基づいてストレージサーバ11から機器データと付帯情報とを取り出す(ステップT103)。
次に、データ収集サーバ10が通信部100により、取り出された機器データと付帯情報とを含む流通データをデータ利用サーバ20に送信する(ステップT104)。
そして、流通データをデータ収集サーバ10から受信したデータ利用サーバ20が、データ保存部2102により、流通データに含まれる使用頻度に応じたストレージサーバ21にデータを保存する(ステップT105)。
以上、実施の形態1に係るデータ流通システム1を説明した。実施の形態1によれば、データ収集サーバ10が、機器データの意味に基づいて当該機器データの使用頻度を推定し、使用頻度に応じたストレージサーバ11に当該機器データを保存する。そのため、膨大な機器データを効率的に保存することができる。また、膨大な機器データを効率的に保存することにより、データ収集サーバ10の運営者がストレージサーバ11の運営者に支払うべき料金を節約することができる。
また、データ収集サーバ10は、機器データと、当該機器データの意味の情報及び当該機器データの使用頻度の情報を含む付帯情報とを流通データとしてデータ利用サーバ20に送信する。そのため、流通データを受信したデータ利用サーバ20は、使用頻度の推定をすることなく、流通データが示す使用頻度に応じたストレージサーバ21にデータを保存することにより、膨大な機器データを効率的にストレージサーバ21に保存することができる。
上記のいずれの場合も、実施の形態1によれば、膨大な機器データを好適に扱うことができる。
(実施の形態1の変形例)
実施の形態1では、データ収集サーバ10は機器30から直接機器データを受信するものとした。しかし、機器データは、機器30から直接受信されるものでなくてもよい。例えば、HEMS(Home Energy Management System)コントローラが機器30から機器データを受信し、データ収集サーバ10は当該HEMSコントローラから機器データを受信するものであってもよい。この場合も、データ収集サーバ10は、HEMSコントローラを介して、機器30から機器データを受信する。
実施の形態1では、使用頻度推定部1102は、意味特定部1101により特定された意味に対応して予め定められた使用頻度を機器データの使用頻度として推定した。一方、意味特定部1101により特定された意味と同一の意味を有する機器データの取得頻度に基づいて使用頻度を推定してもよい。例えば、同一の意味を有する機器データを1日に10回取得できた場合に、当該意味を有する機器データの使用頻度を「高」と推定することが考えられる。
実施の形態1では、データ利用サーバ20は、データ収集サーバ10から受信した流通データが示す使用頻度に応じたストレージサーバ21にデータを保存した。しかし、データ利用サーバ20は、必ずしも流通データが示す使用頻度に応じたストレージサーバ21にデータを保存する必要はない。例えば、データ収集サーバ10では使用頻度が高い機器データであっても、データ利用サーバ20では使用頻度が高くない機器データを扱う場合、流通データが示す使用頻度は「高」となるが、データ利用サーバ20は使用頻度「中」に対応するストレージサーバ21にデータを保存してもよい。
実施の形態1では、データ収集サーバ10は、流通データ送信の際、機器データ受信時に推定された使用頻度の情報を流通データに含めて送信する。しかし、データ収集サーバ10は、流通データ送信の際に、推定された使用頻度とは異なる使用頻度の情報を流通データに含めてもよい。例えば、送信しようとする流通データに含まれる機器データが、使用頻度「中」である給湯機の温度制御に関するデータであり、流通データを受信するデータ利用サーバ20の運営者が銭湯の給湯分析サービスを提供するサービサであるとする。この場合、データ利用サーバ20の運営者にとって、給湯機の温度制御に関するデータは重要な情報であり、使用頻度が高くなると考えられる。そのため、データ収集サーバ10は、給湯機の温度制御に関する機器データを含む流通データをデータ利用サーバ20に送信する際、使用頻度を「高」として送信してもよい。つまり、データ収集サーバ10は、データ利用サーバ20に応じて使用頻度を変更して流通データを送信してもよい。
(実施の形態2)
実施の形態2に係るデータ流通システム1を説明する。実施の形態2に係るデータ流通システムは、機器30自身が機器データの意味を特定し、機器データの使用頻度を推定し、付帯情報を機器データと関連付けてデータ収集サーバ10に送信する点が異なる。その他の点は概ね実施の形態1と同様である。
図15を参照しながら、実施の形態2に係る機器30の機能的構成を説明する。機器30は、通信部300と制御部310と記憶部320とを備える。
通信部300は、例えばインターネットNTと通信可能なネットワークインタフェースである。通信部300は、データ収集サーバ10と通信する。通信部300は、特に、機器データ及び当該機器データに関連付けられた付帯情報をデータ収集サーバ10に送信する。通信部300は、本発明に係る送信手段の一例である。
制御部310は、機器30を統括的に制御する。制御部310は、機器データ作成部3101と、意味特定部3102と、使用頻度推定部3103と、付帯情報作成部3104と、を備える。
機器データ作成部3101は、機器30自身の動作、状態等に基づいて機器データを作成する。機器データ作成部3101は、本発明に係る機器データ作成手段の一例である。
意味特定部3102、使用頻度推定部3103及び付帯情報作成部3104の機能は、データ収集サーバ10の意味特定部1101及び使用頻度推定部1102の機能と概ね同様であるため、説明を省略する。使用頻度推定部3103は、本発明に係る使用頻度推定手段の一例である。
記憶部320の機能は、データ収集サーバ10の記憶部120の機能と概ね同様であるため、説明を省略する。
次に、図16を参照しながら、実施の形態2に係るデータ収集サーバ10によるデータ保存の動作の一例を、図13に示す実施の形態1の場合と比較して説明する。
まず、通信部100が、機器30からの機器データ及び付帯情報の受信を待ち受ける(ステップS101A)。付帯情報の受信も待ち受ける点が実施の形態1のステップS101と異なる。
次に、データ保存部1104が、受信した付帯情報が示す使用頻度に応じたストレージサーバ11に、受信した機器データ及び付帯情報を保存する(ステップS105A)。すでに付帯情報が存在し、かつ付帯情報に使用頻度の情報が含まれているので、実施の形態1にて実行したステップS102〜S104の動作は不要となる。
データ保存後、制御部110は、ステップS101Aからの動作の流れを繰り返す。
データ流通の動作は実施の形態1と全く同様であるため説明を省略する。
以上、実施の形態2に係るデータ流通システム1を説明した。実施の形態2によれば、機器30自身が機器データの使用頻度を推定するので、データ収集サーバ10が使用頻度を推定することなく、膨大な機器データを効率的に保存することができる。そのため、データ収集サーバ10の処理負担が軽減する。つまり、実施の形態2によれば、膨大な機器データを好適に扱うことができる。
(実施の形態3)
図17を参照しながら、実施の形態3に係るデータ流通システム1を説明する。実施の形態3に係るデータ流通システム1は、機器データのみならず、施工業者による機器30の設置、点検、改修等の施工に関するデータである施工データも取り扱う。実施の形態3に係るデータ流通システム1は、実施の形態1の場合に加え、個人情報ストレージ12と、個人情報ストレージ22と、施工業者サーバ40と、をさらに備える。
データ収集サーバ10は、実施の形態1の場合に加え、さらに以下の機能を有する。データ収集サーバ10は、施工業者サーバ40から施工データを受信する。データ収集サーバ10は、施工データを機器データと関連付けて保存する。データ収集サーバ10は、施工データに含まれる、機器30と関連付けられた個人情報を個人情報ストレージ12に保存する。データ収集サーバ10は、施工データを含む流通データもデータ利用サーバ20に送信する。
データ利用サーバ20は、実施の形態1の場合に加え、さらに以下の機能を有する。データ利用サーバ20は、施工データを含む流通データもデータ収集サーバ10から受信する。データ利用サーバ20は、施工データを機器データと関連付けて保存する。データ収集サーバ10は、施工データに含まれる、機器30と関連付けられた個人情報を個人情報ストレージ22に保存する。
個人情報ストレージ12は、例えば、データ収集サーバ10の運営者が運営する個人情報保存用のストレージサーバである。個人情報ストレージ12は、機器30と関連付けられた個人情報を保存する。個人情報ストレージ12は、本発明に係る個人情報記憶手段の一例である。
個人情報ストレージ22は、例えば、データ利用サーバ20の運営者が運営する個人情報保存用のストレージサーバである。個人情報ストレージ22は、機器30と関連付けられた個人情報を保存する。個人情報ストレージ22は、本発明に係る個人情報記憶手段の一例である。
施工業者サーバ40は、例えば、機器30の製造者と協力関係にある施工業者が運営するサーバである。施工業者サーバ40は、機器30と関連付けられた施工データをデータ収集サーバ10に送信する。施工データは、例えば機器30の施工時に施工業者の携帯端末により施工業者サーバ40に入力される。
図18を参照しながら、施工データの一例を説明する。施工データは、施工を個別に識別する施工IDと、施工業者のIDと、施工対象となる機器30の機器IDと、施工内容、施工日、施工場所、施工画像等の施工に関する情報と、施工対象となる機器30のユーザのユーザIDと、施工対象となる機器30の設置場所の住所とを含む。前述のとおり、機器IDは機器30を個別に識別するIDであるため、施工データから、機器30とユーザ及び住所が関連付けられていることとなる。つまり、施工データには、個人情報が含まれている。施工データは、機器データと同様に、例えばJSON、XMLなどの形式により表される。
次に、実施の形態3に係るデータ収集サーバ10について、実施の形態1の場合と異なる点を、図5を参照しながら説明する。
通信部100は、施工業者サーバ40とも通信する点が実施の形態1と異なる。特に、通信部100は、施工業者サーバ40から施工データを受信する。
使用頻度推定部1102は、施工データの使用頻度も推定する点が実施の形態1と異なる。使用頻度推定部1102は、機器データの場合と異なり、施工データの使用頻度の推定の際に、施工データに含まれる各種データごとに使用頻度を推定する。図18に示す例を用いて説明すると、施工ID、業者ID、機器ID、施工内容及び施工日のデータについては使用頻度が高くなることが想定されるので、これらのデータの使用頻度を「高」と推定する。一方、施工場所及び施工画像のデータは、めったに使用されないことが想定されるため、これらのデータの使用頻度を「低」と推定する。なお、ユーザID及び住所のデータは、個人情報であり、後述の通り個人情報ストレージ12に保存されるため、これらのデータについては使用頻度の推定をしない。
付帯情報作成部1103は、施工データに対応する付帯情報も作成する点が実施の形態1と異なる。施工データの付帯情報は、使用頻度推定部1102にて推定された、施工データに含まれる各種データの使用頻度を含む。また、後述の通り、付帯情報は、使用頻度「高」に対応するストレージサーバ11に保存されるデータと、他のストレージサーバ11に保存されるデータとを関連付ける情報を含むことが好ましい。
データ保存部1104は、施工データ及び当該施工データに対応する付帯情報もストレージサーバ11に保存する点及び施工データに含まれる個人情報を機器IDと関連付けて個人情報ストレージ12に保存する点が実施の形態1と異なる。なお、ストレージサーバ11には個人情報は保存されない。
データ保存部1104は、施工データに含まれる各種データを、推定された使用頻度に応じたストレージサーバ11に保存する。この際、同一の施工に関するデータであっても使用頻度に応じて異なるストレージサーバ11に保存される。そのため、使用頻度「高」に対応するストレージサーバ11に保存されるデータと、他のストレージサーバ11に保存されるデータとを関連付ける情報を付帯情報が含むことが好ましい。
データ保存部1104は、ユーザID、住所などの施工データに含まれる個人情報を、施工データに含まれる機器IDと関連付けて個人情報ストレージ12に保存する。個人情報ストレージ12に保存されるデータの一例を図19に示す。図19に示すとおり、ユーザを個別に識別するユーザID及び機器30の設置場所の住所を含む個人情報と、機器30の機器IDとが関連付けられて保存されている。
実施の形態3に係るデータ利用サーバ20についての、実施の形態1の場合と異なる点は、データ収集サーバ10の場合と概ね同様であるため説明を省略する。また、データ保存の動作、データ流通の動作も、施工データを扱う点、個人情報が個人情報ストレージに保存される点以外は実施の形態1の場合と概ね同様であるため説明を省略する。
以上、実施の形態3に係るデータ流通システム1を説明した。実施の形態3によれば、機器データのみならず施工データも扱うことができる。また、機器IDと個人情報とを関連付けて個人情報ストレージ12に保存し、ストレージサーバ11には個人情報を保存しないことにより、個人情報を他の情報とは別に管理することを可能としつつ、ユーザと機器30とを関連付けることができる。そのため、例えば、特定のユーザに関する機器データを提供するサービスを実現できる。また、個人情報ストレージ12に保存された、個人情報及び関連付けられた機器IDを削除することにより、ストレージサーバ11に機器データが残されつつも、残された機器データから個人を特定することが不可能となる。そのため、実施の形態3によれば、個人情報の保護を図りつつ、膨大なデータを好適に扱うことができる。
(実施の形態4)
実施の形態4に係るデータ流通システム1を説明する。実施の形態1において、流通データは、機器データと当該機器データに対応する付帯情報とを含むものとなっている。一方、データ利用サーバ20は、例えば一定期間におけるON/OFF制御のデータ全てを要求するなど、膨大なデータ量を要求することが考えられるため、データ利用サーバ20に送信すべき流通データは膨大となりうる。そのため、データ流通市場においては、送信対象となる機器データと付帯情報との組をまとめて取り扱うことが好ましい。実施の形態4は、そのような問題に対応した、実施の形態1の変形である。
実施の形態4における流通データは、図20に示すように、1以上の機器データと付帯情報との組(以下、「データ群」という)と、データ群に関する情報である包括付帯情報とを含む。データ収集サーバ10は、このような流通データをデータ利用サーバ20に送信する。包括付帯情報は、例えば図21に示すように、データ群のデータサイズ、データ群がどのような機器のデータを対象としているかを示す対象機器、データ群がどのような内容かを示すデータ内容、データ群がどの期間のデータを対象としているかを示す対象期間、データ群を送信するデータ送信者及びデータ群の販売価格を示す情報など、データ群に関する情報を含む。
図22を参照しながら、データ収集サーバ10の機能的構成のうち、実施の形態1の場合と異なる点を説明する。データ収集サーバ10の制御部110は、実施の形態1の場合に加え、さらに、包括付帯情報作成部1107を備える。
包括付帯情報作成部1107は、データ取り出し部1106が取り出したデータ群全体に関する情報を包括付帯情報として作成する。例えば、包括付帯情報作成部1107は、取り出し条件決定部1105が決定した取り出し条件に基づいて、包括付帯情報が含むべき情報のうち、対象機器、データ内容、対象期間などの情報を作成する。包括付帯情報作成部1107は、本発明に係る包括付帯情報作成手段の一例である。
通信部100は、制御部110の制御により、データ群と包括付帯情報とを含むデータを流通データとしてデータ利用サーバ20に送信する。
データ利用サーバ20の機能的構成は、実施の形態1の場合と同様であるため説明を省略する。また、データ保存の動作も実施の形態1の場合と同様であるため説明を省略する。また、データ流通の動作も、流通データがデータ群と包括付帯情報とを含む点以外は実施の形態1の場合と概ね同様であるため説明を省略する。
以上、実施の形態4に係るデータ流通システム1を説明した。実施の形態4によれば、データ群に対応する包括付帯情報を作成し、データ群と包括付帯情報とをまとめて流通データとして送信する。そのため、膨大なデータ量の取り扱いが容易となる。つまり、実施の形態4によれば、膨大なデータ量を好適に扱うことができる。
(実施の形態4の変形例)
実施の形態4では、データ収集サーバ10は、流通データを送信するときに包括付帯情報を作成した。しかし、データ収集サーバ10は、任意のタイミングで包括付帯情報作成部1107により包括付帯情報を作成し、データ保存部1104により使用頻度「高」に応じたストレージサーバ11に保存してもよい。作成する包括付帯情報としては、例えば、データ利用サーバ20にとって必要性の高いデータ群に関するものが考えられる。例えば、1ヶ月間の室温に関するデータ群はデータ利用サーバ20にとって必要性が高いと考えられるので、当該データ群に対応する包括付帯情報を予め作成してストレージサーバ11に保存してもよい。
実施の形態4は、上記の各実施の形態及び変形例と適切に組み合わせることもできる。例えば、実施の形態3と組み合わせることを考える。この場合、包括付帯情報は、データ群に個人情報が含まれているか否かを示す情報をさらに含んでもよい。また、この場合、個人情報が含まれているか否かで販売価格を異なるものとしてもよい。
(実施の形態5)
実施の形態5に係るデータ流通システム1を説明する。上記の実施の形態4の変形例にて、データ収集サーバ10が予め包括付帯情報を作成することを説明した。実施の形態5に係るデータ流通システムは、当該実施の形態4の変形例をさらに変形したものであり、データ収集サーバ10が予め作成された包括付帯情報を活用して流通データの販売目録を作成し、データ利用サーバ20が当該販売目録に示された流通データを購入することを可能とする。
図23を参照しながら、データ収集サーバ10の機能的構成のうち、実施の形態4の場合と異なる点を説明する。データ収集サーバ10は、実施の形態4の場合に加え、さらに、目録作成部1108を備える。
目録作成部1108は、ストレージサーバ11に保存された包括付帯情報に基づいて、当該包括付帯情報と関連付けられたデータ群の販売目録を作成する。販売目録は、当該データ群を含む流通データの販売をデータ利用サーバ20の運営者に広告するための販売目録となる。販売目録には、データの内容、対象期間、価格など、データ利用サーバ20の運営者が流通データを購入すべきか否か判断できる程度の情報が含まれていればよい。販売目録の内容は、例えば、概ね図21で示す包括付帯情報の例と同様の内容となる。目録作成部1108は、本発明に係る目録作成手段の一例である。
通信部100は、制御部110の制御により、販売目録をデータ利用サーバ20に送信する。
次に、データ利用サーバ20の機能的構成のうち、実施の形態4の場合と異なる点を、図11を参照しながら説明する。
通信部200は、データ収集サーバ10から、流通データの販売目録を受信する。データ要求部2101は、受信した販売目録にて示される内容から、流通データを購入するか否かを判定する。データ要求部2101は、流通データを購入すると判定したとき、当該流通データの要求を、通信部200を介してデータ収集サーバ10に要求する。流通データを購入するか否かの判定は、内容、対象期間、販売価格など、予め定められた条件に従うものでもよいし、データ収集サーバ10の運営者による入力装置を介した入力により判定してもよい。
データ保存の動作は実施の形態4の場合と同様であるため説明を省略する。また、データ流通の動作も、データ収集サーバ10が販売目録をデータ利用サーバ20に送信し、販売目録を受信したデータ利用サーバ20が流通データを購入するか否か判定する点以外は、実施の形態4の場合と概ね同様であるため説明を省略する。
以上、実施の形態5に係るデータ流通システム1を説明した。実施の形態5によれば、データ収集サーバ10が流通データの販売目録を作成してデータ利用サーバ20に送信するので、膨大な機器データの取引を円滑にすることができる。したがって、実施の形態5によれば、膨大な機器データを好適に扱える。
(実施の形態6)
図24を参照しながら、実施の形態6に係るデータ流通システム1を説明する。上記の各実施の形態及び変形例はいずれも、機器データの正当性を担保することは考慮されていなかった。そのため、例えば、正当性のない、ねつ造された機器データが流通してしまうことが考えられる。したがって、データの正当性を担保することが必要となる。実施の形態6は、このような問題に対応した、実施の形態1の変形である。
データ収集サーバ10は、実施の形態1の場合に加えてさらに、証明サーバ50を備える。証明サーバ50は、例えば、データ収集サーバ10の運営者ともデータ利用サーバ20の運営者とも無関係な第三者機関により運営されるサーバである。証明サーバ50は、データ収集サーバ10の依頼に基づいて、データ収集サーバが有する機器データの正当性を証明する証明書を発行する。証明書発行の具体的な動作については後述する。証明サーバ50は、本発明に係る証明サーバの一例である。
図5を参照しながら、データ収集サーバ10の機能的構成のうち、実施の形態1の場合と異なる点を説明する。
制御部110は、正当性を証明する対象とするデータ群を決定する。制御部110は、流通データを通信部100により送信する際、証明書も流通データに含めて送信する。
通信部100は、証明サーバ50と通信する。特に、通信部100は、証明サーバ50に付帯情報、データ証明要求及び検査対象データを送信し、証明サーバ50から検査対象データ要求及び証明書を受信する。
取り出し条件決定部1105は、証明サーバ50から要求された検査対象データを取り出す条件を決定する。
データ保存部1104は、証明サーバ50から受信した証明書を、対応する機器データ及び付帯情報と関連付けてストレージサーバ11に保存する。
データ利用サーバ20については、流通データに証明書が含まれる点以外は実施の形態1の場合と概ね同様であるため、説明を省略する。また、データ保存の動作、データ流通の動作についても実施の形態1の場合と概ね同様であるため説明を省略する。
次に、図25を参照しながら、データ収集サーバ10と証明サーバ50によるデータ証明の動作の一例を説明する。
まず、データ収集サーバ10は、制御部110により、正当性を証明する対象となる機器データを決定する(ステップT201)。この際、関連性のある複数の機器データをまとめて証明対象として決定することが好ましい。例えば、特定1ヶ月間におけるエアコンON/OFF制御のデータをまとめて証明対象とすることが考えられる。
次に、データ収集サーバ10は、制御部110により、証明対象として決定された機器データに対応する付帯情報を証明サーバ50に送信し、当該機器データに対する正当性の証明を証明サーバ50に要求する(ステップT202)。
次に、付帯情報及び証明要求を受信した証明サーバ50は、受信した付帯情報に基づいて、正当性証明のために検査対象とする機器データを検査対象データとして決定し、当該検査対象データをデータ収集サーバ10に要求する(ステップT203)。ここで、理想的には付帯情報に対応する全ての機器データを検査対象とすることが好ましいが、この場合データ量が膨大となることが考えられ、現実的ではない場合がある。そのため、証明サーバ50は、例えば、付帯情報に基づいて全データのうち数%程度を無作為に検査対象として決定し、当該検査対象のデータをデータ収集サーバ10に要求することが考えられる。
検査対象データ要求を受信したデータ収集サーバ10は、取り出し条件決定部1105により、検査対象データを取り出す条件を決定し、データ取り出し部1106により検査対象データである機器データをストレージサーバ11から取り出し、通信部100により検査対象データを証明サーバ50に送信する(ステップT204)。
検査対象データを受信した証明サーバ50は、検査対象データの正当性を検査し、正当性が確認できた場合には証明書をデータ収集サーバ10に発行する(ステップT205)。正当性の判定は、例えば、検査対象となる値の相関関係、変化量などに基づいて行う。例えば室温に関する機器データが検査対象データとなっている場合、室温としては不自然な相関関係、変化量などを検知した場合には正当性がない、と判定する。なお、図25には示していないが、正当性が確認できなかった場合、証明書は発行されない。
証明書を受信したデータ収集サーバ10は、データ保存部1104により、証明書を対応する機器データ及び付帯情報と関連付けてストレージサーバ11に保存する。
以上、実施の形態6に係るデータ流通システム1を説明した。実施の形態6によれば、機器データの正当性を証明することができるので、データ流通市場に流通する膨大な機器データを好適に扱うことができる。
(実施の形態6の変形例)
実施の形態6は、例えば実施の形態4あるいは5と適切に組み合わせることができる。この場合の、証明書を含む流通データの一例を図26に示す。証明書は、1つのデータ群を証明範囲とした証明書である。包括付帯情報は、2つのデータ群及び対応する2つの証明書に関連付けられている。このように、証明書が複数の機器データを証明し、証明された複数のデータ群を1つの包括付帯情報に関連付けてもよい。これにより、証明された複数のデータ群をまとめて流通させることができる。また、この場合、包括付帯情報は、証明書の有無を示す情報を含んでもよい。
(その他の変形例)
上記の各実施の形態及び変形例では、機器データが加工されていないことを前提としている。一方、数値データの有効桁数、日時の表現の統一化などを理由に、機器データに軽微な加工をする必要が生じる場合がある。その場合、データを加工した旨、加工内容、加工した者の情報等の加工に関する追加情報を、加工された機器データに対応する付帯情報に追加することが考えられる。加工に関する情報を付帯情報に追加することにより、加工の際に問題が生じた場合に、どのような経緯で誰が加工したかを特定することが可能となる。つまり、データ加工のトレーサビリティを確保することができる。
上記の各実施の形態及び変形例では、機器データごとに価値が異なる可能性については考慮していない。しかし、例えば、一部のエアコンに搭載された熱画像センサにより得られる熱画像情報は、価値の高い情報となりうる。したがって、例えば、データ収集サーバ10の意味特定部1101にて機器データの価値の高低も意味として特定し、価値の高低に応じてデータ群を分類し、同価値のデータ群を包括付帯情報にて関連付けることが考えられる。この際に、包括付帯情報が示す販売価格を、データ群に応じた個別の価格設定ではなく、価値に応じた価格設定にすることにより、販売価格の設定、金額計算処理等が容易となる。また、価値の高低に応じて異なるストレージサーバ11に機器データを保存してもよい。
上記の各実施の形態及び変形例では、機器データに対して何も統計的な処理を施していないことを前提としている。一方、1週間毎の消費電力量、1ヶ月間の平均室温等、一定の期間に集約された機器データの需要も多々あると考えられる。データ利用サーバ20が、集約された機器データのみ必要な場合に、当該期間中の全ての機器データを取り出して送信するのは効率的ではない。そのため、データ収集サーバ10は、任意のタイミングで、一定の期間を対象として機器データを集約し、集約された機器データをストレージサーバ11に保存してもよい。この際、集約された機器データに対応する付帯情報に、機器データが集約された旨、集約前のデータへのリンクなどを含むことが好ましい。また、集約されたデータを、他のデータの保存先とは異なる専用のストレージサーバ11に保存してもよい。
また、集約されたデータは、データ容量がさほど大きくない。そのため、スマートフォン、タブレット端末など、記憶容量の小さい端末装置でも受信可能である。そのため、実施の形態5において、集約されたデータに関する販売目録を端末装置に送信し、当該端末装置が集約されたデータを要求し購入することも可能である。
上記の各実施の形態及び変形例において、一度ストレージサーバ11に保存した機器データを他のストレージサーバ11に移動してもよい。例えば、保存してから1ヶ月、半年等の一定期間が経過した機器データは使用頻度が低くなると考えられる。この場合、当該機器データを、より低い使用頻度に応じたストレージサーバ11に移動することにより、より効率的に機器データを保存することができる。機器データを他のストレージサーバ11に移動した場合、トレーサビリティの観点から、機器データを移動した旨の情報を付帯情報に追加することが好ましい。
その他、本発明の実施の形態として、上記の各実施の形態及び変形例を当業者の通常の知識の範囲内で適切に組み合わせたものを採用してもよい。例えば、実施の形態3と6とを組み合わせ、施工データの正当性を証明してもよい。
なお、図12に示すハードウェア構成においては、データ収集サーバ10が二次記憶装置8004を備えている。しかし、これに限らず、二次記憶装置8004をデータ収集サーバ10の外部に設け、インタフェース8003を介してデータ収集サーバ10と二次記憶装置8004とが接続される形態としてもよい。この形態においては、USBフラッシュドライブ、メモリカードなどのリムーバブルメディアも二次記憶装置8004として使用可能である。
また、図12に示すハードウェア構成に代えて、ASIC(Application Specific Integrated Circuit: 特定用途向け集積回路)、FPGA(Field Programmable Gate Array)などを用いた制御回路によりデータ収集サーバ10を構成してもよい。また、図12に示すハードウェア構成において、データ収集サーバ10の機能の一部を、例えばインタフェース8003に接続された制御回路により実現してもよい。
また、データ収集サーバ10で用いられるプログラムは、CD-ROM(Compact Disc Read Only Memory)、DVD(Digital Versatile Disc)、USBフラッシュドライブ、メモリカード、HDD等のコンピュータ読み取り可能な記録媒体に格納して配布することが可能である。そして、かかるプログラムを特定の又は汎用のコンピュータにインストールすることによって、当該コンピュータをデータ収集サーバ10として機能させることが可能である。
また、上述のプログラムをインターネット上の他のサーバが有する記憶装置に格納しておき、当該サーバから上述のプログラムがダウンロードされるようにしてもよい。
(関連技術の補足説明)
以下、上記の各実施の形態及び変形例に関連する技術について、図面を参照しながら補足説明をする。なお、各図中における丸で囲まれた数字は、以下の説明では括弧つきの数字にて示す。例えば、丸で囲まれた数字の1は、以下の説明では「(1)」と記載する。
図27は、従来の情報銀行を活用したデータ流通システムを示した図である。情報銀行とは、ビッグデータとしての機器データの流通を仲介する機関である。以下では、メーカ、サービサ、情報銀行などの各運営者が運営するサーバを、適宜当該運営者の名称により表す。図27に示すように、メーカからアップされるビックデータを一旦情報銀行53を介してからサービサ55に提供する形態では、この情報銀行53が各データ提供事業者51(メーカクラウド等)からアップされるデータのフォーマットをそろえるなどの加工が行われる。
特にクラウドを所有しない機器メーカ、メーカクラウドを所有するが流通システムを持たない機器メーカ、データ加工規模が大きいために専門IT部門が必要となる機器メーカなどは、情報銀行53にデータ流通の業務を代行させる必要がある。情報銀行53が代行するデータ流通の業務は、個人情報の管理、データ蓄積と集約、データカタログの作成などである。この場合、情報銀行53がデータ流通を受け持つので、データフォーマットなどAPIをきっちり規定しなくても(必要な情報があるかどうかだけで)良い。
特に情報銀行53がデータ流通を受け持つので、データフォーマットなどAPIをきっちり規定しなくても(必要な情報があるかどうかだけで)全体のシステムが成り立つ。そのため情報銀行53は、個人情報の管理アプリ、データ加工アプリ、データ統合アプリなどのデータ処理アプリ57を有し、これにより加工及び提供が行われる。
ただしこの場合は、情報銀行53が仲介する形となるため、データ提供側のニーズとサービサ55のニーズを調整する必要があり、また情報銀行53自体のビジネスモデルによってデータ流通が限定されてしまう課題があった。
一方、本発明の実施の形態と関連する、後述のオープンシステム(データ提供事業者51が直接サービサ55にデータを流通させるシステム)では、より流通性が高いものとなるが、上記理由で提供側にシステムが構築できない場合は、情報銀行53を活用する場合とオープンシステムとの併用が予想されるためデータフォームはオープンシステムに合わせる必要がある。またこのとき、個人情報に関し個人56がデータの閲覧または削除を要求する場合があり、情報取得アプリ56aを介して情報銀行53から自身のデータ取得を行う。
図28は、従来の情報銀行53を活用したデータ流通システムにおけるデータの流れを示す図である。各家庭58がHEMSシステムのように宅内制御システム単位で構成されている場合、システム責任を持つシステムメーカサーバ59の単位で各家庭58のIoTデータが管理され、このIoTデータを情報銀行53が吸い上げ、データ形式等を加工し、サービサ55に提供する。この際、データはサービサ55が使いやすいようにカタログ化(各意味を標準的な言語で記述し、誰でも使えるように一般化)し提供する。
機器からアップされるデータは、例えば家庭用機器(家電)であれば、各家庭58に設置された単位となっており、また各機器に取り付けられた通信アダプタもしくは、機器に内蔵された通信手段により一旦メーカなどが管理しているシステムメーカサーバ59にアップされるのが一般的である。また施工業者などのシステム事業者がビルシステム、HEMSシステムなどとあわせシステム事業者のクラウドシステムにアップされる形態もある。この際、各機器のデータはアダプタ等のID番号もしくは機器IDを有した個々の機器単位でアップされるため、RAC、給湯機(HWD: Hot Water Dispenser)、スマートメータ(スマメ)とあった場合は、それぞれの単位でシリアルにデータがクラウドに転送される形態となる。
ただしデータ更新頻度が高いものは頻繁に、低いものは低い頻度のデータファイルとしてアップされる。また家庭58毎に設置施工され、例えばHEMSシステムなどでシステム化された場合は、機器からアップされるデータ以外に、個人IDを含む個人情報、設置施工を含む管理情報などが別途入力され各家庭58の機器が家庭58及び個人56と紐付けられた状態でメーカクラウドにアップされる場合がある。
図29は、従来の複数のメーカが存在する場合の家庭内機器の情報転送を示す図である。一般の家庭58では、家電機器が1つのメーカで一本化されているケースはあまり無く、複数のメーカの機器が設置されている。特に近年のスマート家電では家電機器自身がメーカクラウド59(システムメーカサーバ59)と連携することで機器の機能を提供するようになっているため、この場合各機器はメーカ毎に各メーカのクラウドシステム59(システムメーカサーバ59)に接続されるようになる。
このような場合でも、機器からのデータを一旦情報銀行53のデータ加工サーバに集約し、各メーカ単位で仕様の異なるデータフォームをあわせたり、サービサ55のサービスに必要な情報を取り出したりすることでデータ活用サービスが実現する。
図30は、機器から出てくる情報を示す図である。機器からは機器毎の単位で、シリアルに情報が送出される。各家庭58の機器(スマート家電)からアップされるデータは、例えば機器に取り付けられたアダプタを単位としてIDが付与されており、ON/OFFの制御情報なのか、状態を示す情報なのか、設定した情報なのかなどの意味分類と具体的なデータ内容からなる。アダプタのキャッシュメモリにも依存するが、家庭58からはルータを介してデータがクラウドにアップされる事を考慮し、ある程度まとまったデータとして、定期的なポーリング単位あるいは操作毎にアップされるのが一般的である。
ここで例えば61はルームエアコン(RAC)からアップされるデータ、62は給湯機(HWD)からアップされるデータである。一方、HEMSシステムなど宅内コントローラを介してクラウドに接続する形態であれば、宅内コントローラでデータが一旦集約されるため、コントローラとクラウドの間で取り決めたポーリングサイクルでデータがアップされる。例えば電力マネージメント関連では30分単位でデータをまとめてアップするシステムが一般的である。
図31はデータ提供事業者とサービサでの流通を示す図である。本発明に係る実施の形態では、メーカのクラウド等の各データ提供事業者51がサービサ55と直接データの受け渡しを行う事により、よりオープンなデータ流通システムを実現し、データ流通によるサービサの利用拡大等を行うことを目的とする。なお、個人情報管理アプリ63は、認証機関が認定したものであり、情報取得アプリ58は、サービスとからめてサービサが提供するものである。
本システムにおいては、データフォーム及びクラウド間でのデータの受け渡しのAPI62をきちんと定義する事で、サービサ55はどのデータ提供事業者55からも同じフォームのAPI62でデータ提供を受ける事ができる。この際データカタログ化のフォーム、データ群の構造、ファイル方式・暗号化方式などを標準化することで、各メーカ間のデータをメーカ毎に個別加工したり、メーカ間のフォーマット差異をそろえるための処理が不要となる。
このため、サービサ55が所有するクラウド上のアプリ64で、データの統合化及び自由なカタログ化が可能となってくる。また近年、個人情報保護の観点から一旦許諾した後でも、自身のデータ閲覧、削除などを行う必要があるが、データフォームのAPI62を標準化することで、個人56のアプリからも実現可能となる。個人56も、情報取得アプリ58により、必要な情報を入手する事が可能となる。
図32は、データ提供事業者51とサービサ55での流通において異なるデータフォーマットで配信された場合を示す図である。ここで、メーカ等データ提供事業者51からアップされるデータが標準化されていない場合、サービスを実現するためには、まずは各メーカのデータフォームをそろえ、必要な部分を抽出したり加工したりする、前処理用のクラウドシステム65が必要となってくる。すなわちここで整形・加工したデータをあらためてサービスを行うクラウド上のアプリケーションで実現する事となる。
最終のサービスが例えばスマートフォン66のアプリで表示動作するものであった場合、サービス提供クラウド55(サービサ55)経由で必要なデータを送り込むケース(ルートA)と、直接スマートフォン66とやりとりするケース(ルートB)があり、いずれにしても、サービサ55のクラウドシステム上にデータフォーマットの整形処理システムを構築するか、情報銀行53などのプラットフォーマに加工を委託してサービスを受ける形態となるほか、データの整形及び加工は、提供するメーカ等のデータ提供事業者51が変わる都度フォーマットをそろえる必要があるため、追加投資、個々のメーカとのデータ授受の契約交渉等が必要となってくる。そのため、このような追加投資、開発の部分、個別の契約準備等が、データ流通が広がらない要因となる。
図33は、機器の情報による見守りサービスの例を示す図である。ホームエネルギーマネジメントシステム(HEMS)では、家にHEMSを施工する時点で各部屋にどの機器を設置したかが登録されるため、例えば機器における通信アダプタの施工設置をする施工業者と、システムを提供しているサービサが同一事業者の場合、施工情報から得られる家の間取りから、機器の状態を一覧表示する事で、機器のON/OFFを監視することによる簡単な見守りサービスが可能となる。
サービス事例として、タブレット画面で表示される家の家電状態を見える化する事例67と、スマートフォンで宅外から見る事例68を示す。
ここでは、例えば今まで機器のスイッチが入っていなかった子供部屋の機器がONされたことを見て、子供の帰宅を判断したり、離れた家の高齢者が普段どおり生活しているかどうかを、機器の操作状態から見守る事が可能となる。現状このようなシステムは、スマート家電機器の提供と、設置施工業者が同一事業者の場合、同じクラウドでID間の紐付けが可能となるため、容易に実現できるものの、施工業者がまったく別の場合、両者間での契約に基づくIDの紐付けシステム構築等ができないと、実際のサービス提供は困難である。
図34は、流通データが標準データフォーマットで配信された場合を示す図である。データフォーマットのAPI62を標準化した場合、サービサ55のクラウドシステムの入り口に標準的なデータ授受のAPI−IF(インタフェース)を構築しておくことで、どのメーカのデータが来ても、標準化フォームに準拠したものであれば、サービスシステムが構築できる構成をとることが可能となる。また比較的データ量の多いものは、一旦サービサクラウドで蓄積・処理した後スマホアプリ66などのサービサアプリとつなぐ方法もあるが、データ量がスマートフォンで処理できるレベルのものであれば、直接スマホアプリ66とメーカクラウドなどのデータ提供事業者51がIFを取る事も可能である。これら、クラウド上やスマホ上の標準API−IFは、データフォーマット同様に汎用的なものとなるため、クラウド上及びスマホ上のAPI62は標準的なミドルウエアとして、スマホ事業者及びクラウド事業者が標準で準備しておく形態も考えられる。
これらのデータ提供形態においては、(1)データを提供するだけのケース、(2)データはサービサ55のアプリが都度必要分を取りに行く(閲覧する)ケース、(3)データ提供と提供後のデータの都度取得(閲覧する)の両方を行うケースがあり、スマホ等のメモリ制限がある場合は特にサービサ55側でデータをかかえない方式が有効である。
このようにデータの流通市場を拡大するためには、これら標準的な対応による、サービスシステムの効率化が必要となるほか、データ提供事業者51が直接サービサ55とデータ授受を行うため、データ売買にかかわるビジネスモデルも構築しやすくなるメリットがある。
図35は、メーカとサービサ間でのダイレクト情報転送時のデータの流れを示す図である。各機器が機器メーカ等のデータ提供事業者51のクラウドにそれぞれつながっている場合、あるいは複数のシステムメーカが存在している場合でも、機器から出てくるIoTデータをWeb API62(API62)で標準化する事で、クラウド間連携システム上で必要なデータを個別に流通させる事が可能になる。この際メーカデータあるいはサービサに対し情報銀行53が証明書及びデータ活用のIFアプリを提供する事も可能になる。なお、標準化されたWeb API62は、後述するデータ構造、付帯情報も含めたデータのやりとりのプロトコル、データカタログのラベリングの意味、階層構造になっている場合も階層構造の情報等も含めた形で規定することで、サービサ55が持つ標準的なIFアプリで処理することができるようになる。逆にWeb API62のフォーマットにあいまいな部分があるとサービサ55のアプリのIF部分が個別に作る必要がありサービサ55毎にアプリのIF部分を個別に開発する必要がある。一方、例外的な記述ができなくなってサービス内容あるいは取得先のメーカを限定してしまう可能性がある。そのため、標準化されたWeb APIは定義を明確化するとともに、例外的な記述部分の定義を用意しておく事が必要となる。
図36は、複数のメーカが存在する場合の、Web API62による情報転送を示す図である。1つの家庭58内に複数のメーカ機器が存在する場合も同様にWeb API62で標準化されると、サービサ55のアプリで各メーカ情報を取得しサービスが可能となる。特にメーカが異なる場合、メーカ毎にメーカクラウド51が存在し、サービサ55のIFアプリが個々のメーカに取りに行く事になるが、Web API62の定義がメーカにより異なるとサービサ55のアプリが誤解釈したり、動作しないケースがあるため、メーカ間の定義を一様にそろえておく事が必要となる。
図37は、意味によるカテゴライズ化を示す図である。メーカクラウド等のデータ提供事業者51内では、機器単位にアップされているIoTデータを、サービサ55が活用しやすくするために意味単位のデータに変換するケースが想定される。そのため機器からアップされるデータ69は意味の情報(制御、設定)とか、さらに詳しい(ON/OFF、温度、湯量、風向)といった意味情報をあわせてもち、機器単位と意味単位で変換できるようにストアしておくことが必要となる。設定に関するデータをまとめたカタログ化データの例をカタログ化データ70に示す。
図38は、別の情報とのリンクによる付加価値を示す図である。機器から上がってくるデータだけでなく、例えば施工業者のデータ71とリンクさせることで、家庭58の中にある機器が、家庭58のどこにつけられたかどうか、いつ施工したかといった情報がわかるようになる。これにより、家庭58の間取りに個々に配置された機器の動作状態を監視して見守りサービスを行ったり、施工期日と機器からのエラー情報をリンクさせて耐用年数の過ぎた機器を監視し保守サービスあるいは予防保全を行う事も可能になる。
この仕組みがあれば図33に示す簡単な見守りサービスに関し、同一事業者にしばられる事がなくなり、機器提供メーカと施工事業者が別の事業者であってもデータのリンクを張ることで見守りなどといった新たなサービスが可能になる。
図39は、別の情報とのリンクによる付加価値事例を示す図である。実際には施工業者自身が管理用のクラウドシステム72(施工業者クラウド72)を有する場合があり、この施工業者クラウド72とメーカクラウド等のデータ提供事業者51とを、同じ標準化されたWeb API62で接続し、施工業者の施工IDとメーカの機器IDを紐づけることで、リンクシステムを形成することができる。特に施工については、1つの施工業者だけで家の施工が行われないケースが多く、複数の施工業者がからんでくる可能性が高いため、データ提供事業者51と各施工業者クラウド72とを標準的なWeb API62で接続し、家庭58単位となるリンク情報を有し、これをもってサービサ55に提供する事が可能となる。例えば、図38の場合と同様に、見守りサービスを提供する事が可能となる。
図40は、データの深さによる階層化を示す図である。機器からアップされるデータ及び施工情報を含むデータについては、これらの情報をカタログ化する際に階層構造で記述することが有効になる。例えば階層構造73に示すデータ構造のように制御情報にはON/OFF温度設定といった基本的な情報、細かな温度設定、風向、風力といった付随する情報、タイマー設定、省エネ設定などメーカ毎に仕様が異なってくる情報があり、これらを階層的に記述することで、各メーカ間で共有できるものあるいはユーザの使用上一般的なものと、メーカ毎に異なるものを分けておくことが可能となる。また施工情報についても同様で、施工日や完了日といった基本情報から、定期点検・保障期間、施工時の写真といったより詳しく施工業者毎に対応が異なるものを分けておくことも可能となる。
例えば本見守りの事例では、第一階層のみの情報で実現できるため、全情報を送らなくても、第一階層情報郡をサービサに転送しておけばよいことになる。
階層構造73は、例えば以下のような手順で規定される。
一般的な言語の意味から想起される内容で、データの階層化をあらかじめ定義しておく。データのカタログ化において、まず汎用的な定義から規定。
○家電機器制御の場合のデータの深さ
機器のON/OFF
>(機器の基本設定にかかわるもの)温度設定/風力/風向
>(機器の付加機能に関するもの)省エネ/タイマー設定
○設置施工の場合の場合のデータの深さ
施工日時/完了未完了
>同時に施工した機器/施工業者名/定期点検情報/機器保証期間/施工費用伝票
>施工業者住所/電話番号/地図/リンク先URL/施工時写真/動画/マニュアル
といった階層構造73が構成できる。
図41は、クラウドサーバ上の階層化の構成例を示す図である。一般的なパブリッククラウドでは、データを格納しているサーバシステムにおいてURL(Uniform Resource Locator)をIDとしたデータ群を、オブジェクト構造で配置しているケースがある。
これらのデータを階層構造73で記述した場合、基本的には使用頻度及び情報量(画像を含むなど)によってどの階層にあるべきかが規定されている。また、一般的なサーバシステムにおいても、アクセス毎コストが無償もしくは非常に小さいサーバシステムと、アクセス毎のコストが発生するもののデータ容量単位のコストが大きいサーバシステム、これらの中間的なもの等、複数の選択の中でデータファイリングすることが一般的なため、このデータ階層構造の定義に従い、それぞれのクラウドシステムのデータ格納先を設定することが行われる。
この際、各サーバシステムにデータが分かれてファイリングされているため、各階層間のデファイルータリンクを取っておくことが必要となり、この場合はURLがIDとなるため、各データファイルの付帯情報の中にリンク先のURLを記述しておくことが必要となる。
図42は、サーバ特性を配慮したデータ階層化を示す図である。各メーカクラウド等のデータ提供事業者51及びサービサ55のクラウドには、IoTデータを格納しておくサーバシステムが必要となるが、一般的なパブリッククラウドでは、サーバシステムの特性により、アクセス毎コストが無償もしくは非常に小さいがデータ容量単位のコストが高いサーバシステムと、アクセス毎のコストが発生するもののデータ容量単位のコストが小さいサーバシステム、これらの中間的なもの等が存在する。
これは、サーバシステムのハードウェアが、アクセスコストが低い反面、容量を大きく取りにくい半導体メモリ77からなるものと、容量が大きくファイルビット単価の安いハードディスク78および79を使ったものが存在することに起因する。
そのため大規模なビックデータを扱うIoTシステムにおいては、このデータファイルコストを最小限に設定する必要があり、データのアクセス頻度などで階層化された定義情報をベースに、システムが自動的にサーバのファイル先を設定するのがのぞましい。これについてはメーカなどのデータ提供事業者51だけでなく、データ利用業者であるサービサ55のクラウド内も同様になるため、各メーカなどのデータ提供事業者51あるいは各サービサ55が、個々に最適なサーバシステムの設計・構築作業を行わなくても良いように、あらかじめ標準化されたWeb API62で階層構造を定義しておくことで標準的なクラウドアプリで対応できるようになる。サービサ55は、当該クラウドアプリにより、データ配信元の更新頻度目安を参考に、自社クラウドにおけるデータの最適配置を行う。
したがってデータに階層構造を持たせる場合、更新頻度の高い(アクセス毎の課金が不要)な情報を最上位とし、更新頻度の低いもの(アクセス数が低いもの)をより下層に配置する。例えば、図42に示すサーバAには、分、時間、日単位で更新されるデータ及びデータ量が増減するデータが保存され、サーバBには、月、年単位で更新されるデータが保存され、サーバCには、更新されないデータあるいは更新頻度が極めて低いデータが保存される。この際、元々はサーバAに保存されていたデータであっても古いデータについては、更新頻度が下がることが想定されるため、秒・分を示すデータを削除する加工をした上でサーバBに移動してもよい。同様に、元々はサーバBに保存されていたデータであっても古いデータについては、秒・分のみならず時を示すデータを削除する加工をした上でサーバCに移動してもよい。
図43は、サーバ特性とデータの深さによる階層化を示す図である。メーカなどのデータ提供事業者51と施工業者72のクラウドの両方のデータを持つ場合においても、機器からアップされるデータ群を、意味毎に再定義した上で標準的なWeb APIに対応できるよう整理する際、階層構造も標準フォームで定義することでどのサーバシステムにデータを振り分けるかが自動的に決まるので、都度開発を行う必要がなくなる。
新たなカタログを定義する場合でも、あらたなカタログに階層構造のどの階層構造かといった記述及び更新頻度に関する情報を記述しておくことで、以降自動的にデータの振り分けが可能となる。
IoTのビックデータシステムにおいては、膨大なデータをいかに効率的にストアリングするかが重要となっている。操作履歴や温度センサの履歴などの履歴情報といったものは年々積みあがってくるものであり、この膨大なデータのストレージと維持管理を最適なコストで効率運用することがもとめられ、このようにサーバ特性を考慮したデータの分類が重要となってくる。
例えば更新頻度の高いデータとしては、随時更新/データ増減情報(分、時間、日単位で更新されるデータあるいはデータ量が増減するもの)として、エネマネ情報、センサ情報、操作履歴情報、生活行動履歴、コールセンターオペレーションなどがある。
また更新頻度が中程度のデータ(月、年単位で更新されるデータ)として、休日/出勤カレンダー、通勤経路、習い事/ジム契約、クレジット契約/ネット契約、加工された古い情報、などがある。
また更新頻度の少ない情報(1タイムのデータ)として、施工内容、施工業者の詳細(住所/業務内容)、施工画像、家の住所、購入製品番号、などがある。
これらをカタログデータ化する際にカタログ分類内容に合わせて更新頻度の目安としておおまかなくくりを定義しておくことで、どのストレージ階層にファイリングしておくべきかが自動的に決定できる。
図44は、更新頻度情報の例外活用事例を示す図である。これはお風呂屋の事例である。お風呂屋チェーンを管理するサービサクラウドでも、階層構造に応じたデータ管理が行われる。一般的な家庭においては、お風呂設定を頻繁に変更することはなく、湯量の設定についても同様である。しかしながらお風呂屋といった浴場事業においては個人の一般家庭におけるお風呂管理のケースと異なり、日々の状況により個別に設定を変更する必要があり、湯量などの制御も頻繁になってくる。そのため湯量に関する標準APIに記述が第二階層であっても、更新頻度大として例外記述を行うことにより、お風呂屋チェーンを管理するサービスシステムにおいて湯量の全体管理がデータ保管コストの適正化が可能となる。
そのためデータ提供事業者(お風呂事業者)からアップするデータフォーマット80として、更新頻度の情報80aを追加し、サービサ55はこの頻度情報を元に自身のクラウドシステムにおけるデータストレージに最適な振り分けを自動で行う。
この場合、事業者クラウド51の元データの更新頻度に応じて、最適なサーバ配置が異なるため、データ提供業者51は、本データ更新頻度の目安をデータに付けて配信する。事業者により、標準で定義されたデータカタログの階層構造から変更が必要な場合、更新頻度情報を新たに記述する。この場合、更新頻度情報が優先される。
これによりカタログ化された文言での意味定義から逸脱する場合においても、本内容を参照することで例外的なデータの使い方を担保する事が可能となる。この時、後述する付帯情報及び包括付帯情報において、例外的なデータの使い方をしているかどうかのフラグを用意し、このフラグを確認することで、フラグが立っている場合は更新頻度情報を確認しストレージサーバの階層を判断することも可能となる。
図45は、データ階層におけるリンクを示す図である。IoTデータにおいては1つの独立した情報が第二階層75だけ、もしくは第三階層76だけといった場合も存在する。例えばあるメーカの製品に対し、今後対応可能な追加施工業者の情報などを記述しておく場合、施工業者の住所、連絡先、地図といった第三階層だけの情報をもっておく場合、アクセス課金がある下の階層のサーバシステムに保管しているものの、頻繁にアクセスする第一階層74にも下の階層にどのような情報があるかを記述しておくことがのぞましい。
要は頻繁にアクセスするデータは上位階層にあるため、下位の階層にしか実データが無い場合でも上位階層には、リンク先の下位階層にあるデータの情報を記載しておく。
第一階層74は、例えば常時アクセスされる部分であり、どのような情報が階層構造下にあるかの配置情報だけは有し、必要である事が確認された後、下の階層からデータを取り出すようにすることで、常にサーバアクセスコストを最適化することができる。
また、この時、後述する付帯情報や包括付帯情報において、配置情報のみを有するデータであるかどうかのフラグを用意し、このフラグを確認することで、フラグが立っている場合で実際のIoTデータが必要なケースにおいては、下位のデータを改めて取得することも可能となり、これにより最上位階層がアクセス毎にかかる費用が小さいことを利用した全体コストの削減が可能となる。
図46はデータ格納事例-パターン一覧を示す図である。事例81は、複数の料金プランが存在するパブリッククラウドの事例である。
このように一般的なクラウドでは、高アクセス用と、低アクセス用と、その中間的なものとが用意されており、低アクセス用は一般的にストレージビット単価の安いものとなっている。
図47は、更新頻度情報の記載を示す図である。データの階層化に際し、まずはカタログの各項目内容に基づき階層構造のどに位置にあるべきかを定義し、サーバシステムの選択も含めて自動化できることがのぞましい。
これはサービサが新たなサービスを検討するに際し、例えば更新頻度あるいはアクセス頻度が高い第一階層の情報である事をカタログ内容(文言定義)でもってサービサが認識イメージし、新たなサービスを構想・設計することが容易になるからである。
なお、個々に更新頻度を数値で記載する方法もあるが、すべてのカタログ列に記載された頻度の数値を個々に確認しながらサービスを構想することが難しいからである。
例えば、フレッシュで頻繁に更新されるデータの事例82としては、エネマネ情報、センサ情報、操作履歴情報、生活行動履歴、コールセンターオペレーションなどがあり、更新が頻繁にないと思われるデータ事例83としては、休日/出勤カレンダー、通勤経路、習い事/ジム契約、クレジット契約/ネット契約、加工された古い情報などがある。
これらに対し、サービサが必要な情報が元はフレッシュデータとしてであっても日単位のデータ更新が不要な例外的な事例84として、消費者購買行動などの比較的大きな流れ、お風呂の湯温設定の推移、エネルギーの月額課金情報などのケースがあり、また一般的に頻繁に更新が無いと思われていても日単位で更新が必要な例外的な事例85として、派遣会社での時間帯勤務詳細、派遣会社社員の通勤経路、クレジットのクーポン等日々の情報、ネット映像配信の支払い情報などの例外的事例がある。
このようにメーカあるいはシステム事業者からアップされるIoTデータには、標準APIで規定された階層構造から逸脱する例外的なものも存在する。これはデータを作り出している事業者毎(生成事業者)に、必要な更新頻度は変わってくるため、標準的なカタログフォーマットを定義しても、事業者による例外が存在するためである。
すなわち、データを作り出している事業者毎(生成事業者)に、必要な更新頻度は変わってくる。結果、標準的なカタログフォーマットを定義しても、事業者による例外が存在する。
この規定はデータ生成事業者(メーカ等)の事業形態に依存し、データ生成頻度及び精度はデータ生成事業者の判断で決定されるので、この更新頻度情報はデータ生成事業者が決定し記載され、この際に更新頻度の情報を付加することで、例外含めてカバーできる。
例えば、企業の休日出勤カレンダーの更新は一般的に年1回であるが、派遣会社の場合はデイリーで変更されるといった場合などである。一方、サービサ55とデータ生成事業者51間の話し合い(契約)でも変更される場合があり、この場合はデータ提供事業者がサービサのニーズを汲んでデータを再加工するケースなどがある。
図48は機器からのデータファイル形式を示す図である。機器からアップされる情報には、センサで検知した情報、操作した情報そのもの、もしくは平均値処理、まるめ処理などを施した実情報であるJSONファイル87がある。
一般的には機器からのデータは機器に搭載された通信アダプタあるいは通信回路が、当該通信回路が有するキャッシュメモリに蓄えられた分を当該機器単位にまとめて出力する。したがって、機器のデータは、通信アダプタ等から機器単位で配信される。なお、機器のデータは、例えば、定期的に配信され、あるいはユーザが機器を操作したときに配信される。
なおこれ以外に情報の意味、ID、関連する意味情報、リンク先のIDなどを記述するJSONスキーマファイル86があり、ファイル付帯情報として、同時に配信する。
図49はカタログ化データファイル形式を示す図である。次にカタログ化したデータファイルの形式を記載する。メーカ等のデータ提供事業者51もしくは情報銀行53からデータを活用するサービサ55のクラウドへは、サービスに必要な情報をひとまとめにした形態で送付、もしくはこれらをいくつかのカタログ単位でまとめた複数の形態で送付する場合がある。
この場合でもデータファイルの先頭には、付帯情報全般が記述された管理情報ファイルとしてJSONスキーマファイル86が配置される。JSONスキーマファイル86には、データ授受に必要な、データサイズ、データ受信送信日時、ファイル形式、データ構造(階層等)、データの混在情報、暗号化情報、データ加工者、データ加工内容、データ加工履歴などが記述される。JSONスキーマファイル86は、サービサ55に送付される。
これによりひきまとめた情報の先頭に付帯情報を設ける事でサービサ55は入手するデータの内容を把握し、サービサ55のサーバの情報入手のためのシステム選択及び入手妥当性確認を行う事ができる。
またサービサ55のサービスアプリ64において、この標準化された付帯情報の内容を自動確認することで、サービサ55におけるデータの複数のストレージ階層へのファイリング、実際のサービスを行うサービスアプリ64への自動展開などを行うとともに、意図したデータと異なる場合にエラー情報を自動的にデータ提供事業者51に返送することも可能となる。
特にこのような多くのデータ提供事業者から複数の情報配信を受けてサービスを行う場合は、個々の入手データを自動的に管理・判断する事が不可欠となるため、このようなデータ内容を記述した付帯情報の定義をデータ提供者間で合わせ、提供側と利用側でのデータ授受の自動化ができるようにしておく必要がある。
図50はJSONスキーマによるフォーマット情報付加例を示す図である。JSONスキーマの情報記述例を記載する。現在データ流通で使われているJSON情報は、そのデータの意味を説明するための付帯情報としてJSONスキーマにて記述される事がよく使われており、IoTデータの付帯情報の記述においてもこのスキーマファイルで記述する。意味とデータとのマッピング一覧をJSONスキーマとして整備することで、JSONスキーマを入手した会社ならどこでもデータの意味を理解できるようになる。もちろん、CSVあるいはXMLでのデータ記述でも付帯情報を独立して持たせることで同様なシステムが構築できる。
図51は、データファイルのIDによるリンクを示す図である。データファイルはサーバシステムのID例えばURLで記述されたもので指定されている。実際に機器の場合は、アダプタに書き込まれている機器IDが当該家電機器の情報IDとなっており、製品にアダプタが内蔵されている場合は、製品番号あるいは製造番号がIDになっている場合もある。
このような機器データ90のIDはそのままサーバシステムのIDとはならないため、その外にサーバIDをかぶせた形態となる。システム事業者のシステムデータ89のIoTデータは、各機器をシステムアップして構成されているため、各機器IDの上位に、いくつかの機器を束ねたシステムIDを有するほか、施工業者の場合は施工IDの下に施工情報やどの機器を施工したかの機器IDが記載されている。これらは家に設置されたシステム単位であったり、同一業者の施工情報であったりする。なおこれらシステム情報あるいは施工情報もまた、クラウド内ではサーバIDがつけられた状態で管理される。
ここで個人情報については、別途個人情報ファイル92を管理するサーバシステムで保存されるが、ここでは各サーバID間のID管理ファイル91におけるリンクテーブルを持つことによって、各機器、システム、施工及び個人情報とのリンクが行われる。またこれらのID群は例えば後述するJSONスキーマなどで記述される。
また、クラウドを運用しているシステムの単位でリンク関係が張られる。特にシステムの施工時に機器及びシステム個人の情報リンクが張られ、システム(メーカ)クラウドでID管理される。
このように構成することで、個人情報92を別に分けて管理し、またこれら個人情報92に関連した機器データにおいて当該個人とのリンク関係をID管理ファイル91にて削除することが可能となる。つまり、個人情報92の一元管理が可能となり、削除や追加が容易となる。
ここで、図52を参照しながら、実際の個人情報管理例について示す。ユーザ登録情報、施工情報などの個人情報及び関連する情報については、同じサーバシステム内であっても別にストアされる部分を用意し、そこで管理するのが一般的である。この際独立した個人情報サーバ93においては、機器IDと個人ID、施工IDとのリンク情報が管理されるリンク情報テーブル91が構成される。例えば個人が自分の情報を閲覧したい場合では、メインのデータ収集サーバを介して個人情報サーバにアクセスし、このリンク情報を取得することでデータ提供事業者51あるいは情報銀行53のデータ収集サーバの情報を取り出し閲覧する。さらに個人情報を削除したい場合は、この個人に関わるリンク情報を削除することで個人情報を削除することができる。この時複数のサービサからのサービスを同時に受けている場合において、他のサービスが同じ機器あるいは設備からのデータを利用している場合は、データ削除要求時に、他のサービスの機能が停止もしくは制限される旨の通知を行い、承諾を受けたのちに前記リンク情報テーブルのユーザ登録IDから、前記情報テーブルにおけるリンクを解除することで、個人を特定できなくする。またサービサのIDも併記しサービサ毎に個人IDと機器IDのリンクが識別できるようにすることで、機器が他のサービスにも使用されておらず他のサービスへの影響が無い場合は、当該削除要求があったサービスでの個人情報リンクを削除し、機器が他のサービスにも使用されている場合は、他のサービスの機能が停止もしくは制限される旨の通知を行い、承諾を受けたのちに前記リンク情報テーブルのユーザ登録IDから、前記情報テーブルにおけるリンクを解除することで、個人を特定できなくすることができる。
図53は、付帯情報の結合を示す図である。次に複数のJSONスキーマを合わせて送付する場合、特に各家庭58毎にコントローラ58aを有するHEMSシステムなどでは、コントローラ58aが家庭58の各データを統合しJSONスキーマをつけて送付するケースが考えられる。ここから同じ意味単位(例えばON/OFFの情報のみ)に加工してデータを配信するケースでは、元のJSONスキーマ86−1、JSONスキーマ86−2から必要部分だけを取り出してJSONスキーマ86−3、JSONスキーマ86−4を作成し、さらにこの先頭に新たなJSONスキーマ(3)からなる包括付帯情報94(JSONスキーマ94)を構成し、JSONスキーマ94の中に加工内容、加工履歴、加工事業者などを規定することができる。
このようにできるだけ元のスキーマ情報を残した上で、加工した情報のみを別に追加することで、データのトレーサビリティを確保することも可能になる。
図54は、機器単位のデータを流通させる場合における、機器データ配信時のフォーマット変換を示す図である。例えば、家庭58からアップされる(1)の機器のIoTデータ87−4を加工し、カタログ化してサービサに提供する際、上記の標準化Web APIに沿った形でデータファイリングされるが、家庭58からアップされるデータに加え、他の事業者がIoTデータを管理・加工している(2)の機器からのデータカタログを購入し、この(1)と(2)をあわせた統合データカタログとしてサービサに提供するケースがある。たとえばこの他の事業者がマンション95の場合を図に示すが(必ずしもマンションでなくてよい)、データカタログ87−5の詳細部分の仕様及び定義が異なったり(例えば、温度データに関する仕様について、家庭58では温度が0.5度単位、マンション95では温度が1度単位で表現されている場合)する場合がある他、家庭58ではIoTデータの形式がJSON形式であったがマンション95ではIoTデータの形式がXML形式であるなどファイル形式が異なっている場合、データの更新頻度がある提供事業者は非常に時間刻みが細かく、他の提供事業者は時間刻みがあらいケースなどである。
これらの整合を取るためにメーカなどのデータ提供事業者51もしくは情報銀行53においてフォーマット変換96を行う場合がある。この場合フォーマット変換96の後のJSONスキーマ86−7に旧フォーマット86−6の情報に加え、変換した際の情報(日時・内容・変更者)を記述し、データ87−6のトレーサビリティを持たせることが必要となる。これは、何らかのデータ品質にかかわる問題が発生した場合に、過去のデータ提供元にさかのぼる必要がある他、後述する情報銀行でのデータ証明書発行時にも責任分解点を明確化するためである。
ここで機器単位のデータをサービサに返信する場合は、元データ87−4及び87−6から提供に必要なデータのみを抽出したデータ87−7及び87−8を配信する際に、86−8及び86−9をそれぞれに付帯させて配信する。例えば、制御に関するデータのみを機器単位で抽出して配信する。この時付帯情報86−8及び86−9は元の付帯情報86−5及び86−7をそのままもしくは必要部分を抜粋したものであり、また86−9にはフォーマット変換した情報86−7からトレーサビリティ確保に必要な情報も含めることで、データ流通におけるデータ品質が担保される。
図55は、意味単位のデータを流通させる場合における、カタログデータ配信時のフォーマット変換を示す図である。機器単位の情報提供ではなく、意味単位にカタログ化した情報提供を行う場合においても、前述のトレーサビリティ担保のため、フォーマット変換履歴を残してそのデータを合わせてサービサに送付する。この際元の付帯情報をそのまま後ろに添付した形で送付すれば、加工履歴前後の状況をサービサが確認することができる。
例えば制御に関するデータのみをまとめカタログ化するケースでは、元データ87−4及び87−6から制御に関するデータのみをまとめたカタログデータ87−7を生成し、この際、元の付帯情報86−5及び86−7を元に必要な部分を抜粋もしくはそのままとした付帯情報86−8及び86−9を用意し、それらをひきまとめた包括付帯情報94−1を生成することで、配信する制御情報に関する情報の内容及び履歴の情報と合わせサービサに提供することができる。包括付帯情報94−1は、まとめたデータに対する新たな付帯情報と、各機器に対応する付帯情報86−8及び86−9の存在を示す情報とを含む。
図56は、データ証明書の発行を示す図である。データの信憑性を担保するためデータ形式及び内容での矛盾やぬけ、個人情報・時間情報やトレーサビリティを含めた確認を、情報銀行53にて監査し、情報銀行53から証明書96の発行を受けることが考えられる。
図56ではサービサへのデータ提供が情報銀行53経由ではないため、例えばJSONスキーマ情報86−3、JSONスキーマ情報86−4及びJSONスキーマ情報94だけをまず情報銀行53に送付し、データ本体は情報銀行53がメーカなどのデータ提供事業者51に送付した閲覧アプリ98を使って、データ提供事業者51のクラウドを閲覧する形で確認が取られる。データ閲覧後問題ないことがわかれば、データ証明書96と暗号キー99aを発行する。
メーカクラウド51では情報銀行53から提供された暗号化アプリ99により、確認されたIoTデータ87−3及び付帯情報86−3、付帯情報86−4及び付帯情報94をその状態(情報銀行53による確認後は一切修正せずに)で暗号キー99aにより暗号化する。
このようにして暗号化したデータとデータ証明書96と暗号キー99aをサービサに提供することでIoTデータの送付が行われる。
上記暗号化までのアーキテクチャは、まず情報銀行はIoTデータ提供事業者に情報確認アプリとIoT情報暗号化アプリを提供し、情報銀行は送付された付帯情報もしくは包括付帯情報に基づきIoT情報確認アプリ経由でIoT情報を確認した結果に基づき、暗号キーをIoTデータ提供事業者に送付する、ということである。
このようにすることで、データ提供事業者はサービサへのIoTデータを情報銀行が許諾した暗号化データとして送付することを可能となる。
図57は、証明書96を含む流通データの生成(データ提供事業者51⇒サービサ55)を示す図である。情報銀行53でデータ証明書96を発行されたIoTデータをサービサ55に送る際は、まず統合化されたカタログデータ(イ)のうち、データ内容詳細を記述したJSONファイル86−3及びJSONファイル86−4と、実データである4つのIoTデータをまとめて暗号化する。ここで流通用の包括付帯情報であるJSONファイル94については暗号化の対象外とする。
このJSONファイル94は、これらデータの全体概要を記載したJSONスキーマであり、証明書96をもらって暗号化をかけた時点で、流通用の包括付帯情報94は、暗号化をかけて証明書の発行を受けた旨の情報を追記しJSONファイル94−2として、流通データ(ロ)の先頭に証明書96ととともに配置される。JSONファイル94−2は、元の流通用の包括付帯情報94に加え、証明書及び暗号化データを含む包括付帯情報である。
このようにすることで証明書96発行後のデータは一切変更することなく(証明済みのデータに変更を加えることなく)、必要な追加情報を記載しサービサ55に送付できる。
そのためメーカ等データ提供事業者51からサービサ55のクラウドへのデータ配信は、まず流通用概要情報と証明書96、次に暗号化されたIoTデータ500、最後に暗号キー99aの順で送付される。
図58は、証明書96を含む流通データの生成(情報銀行53⇒サービサ)を示しており、情報銀行53でデータ証明書96を発行されたIoTデータをサービサに送る方法として、直接情報銀行53経由でサービサに情報を送付する方法もある。
この場合は、メーカ等のデータ提供事業者51のクラウドからJSONスキーマ86−3及びJSONスキーマ86−4で構成されたデータの内容と、流通用の包括付帯情報94を合わせて、情報銀行53に送付する。情報銀行53では図27の処理と同様の手段で、まず統合化されたカタログデータ(イ)のうち、データ内容詳細を記述したJSONスキーマ86−3及びJSONスキーマ86−4と、実データである4つのIoTデータをまとめて暗号化する。
ここで流通用の包括付帯情報である包括付帯情報94については暗号化の範囲外とし、外だしする。この包括付帯情報94は、これらデータの全体概要を記載したJSONスキーマであり、証明書を受けて暗号化を行った時点で、流通用の包括付帯情報94は、証明書を受けて暗号化を行った旨の情報を追記し包括付帯情報94−2として、流通データ(ロ)の先頭に証明書ととともに配置される。
この場合、情報銀行53からサービサのクラウドへのデータ配信は、まず流通用の包括付帯情報94−2と証明書96、次に暗号化されたIoTデータ500、最後に暗号キー99aの順で送付される。このシステムの場合、メーカ等データ提供事業者51のクラウドから情報銀行53へのデータ送付の際、ネット経由でのデータ安全性を担保するため図57と同じしくみで暗号化したものを情報銀行53に送付することも考えられる。
図59は、複数の証明書を含む場合の配信データを示す図である。複数の元データを合わせてサービサ55のクラウドに送付する場合として、例えば家の情報をまとめているメーカ等のデータ提供事業者51がクラウド上にIoTシステムを構築し、マンション97の事業者クラウド507のデータを購入したうえで、家庭58とマンション95のデータを統合させる場合について記述している。
この場合、マンション95の事業者のデータも情報銀行からの証明書504を取っている場合、一旦証明書504をとった情報はそのまま保持し、これを合わせこんだ全体で新たな流通用の包括付帯情報であるJSONスキーマ506を配置し、これを先頭にもった上で流通させる。
この際、家庭58のデータ501に含まれる証明書A、付帯情報(1)−1、付帯情報(2)−1及び包括付帯情報(3)、マンションのデータ502に含まれる証明書504、付帯情報(3)−1、付帯情報(4)−1及び包括付帯情報505をひきまとめた1つのデータとして配信するが、これら全体をひきまとめた全体情報を包括付帯情報506に記載することで、2つのデータを統合する際の統合での新たな加工内容履歴、加工事業者、新たな証明書の有無等を記述し、統合データがどのようなものかを確認することができるようになる。
このようにすることで、これらを合わせこんだデータである情報包括付帯情報506を見た上で、それぞれのデータ元である証明済みの情報を流通させることができるほか、複数のデータ群をマージした場合も、これらのマージ処理、加工、等に関するデータトレーサビリティが記載できるため、データ品質に問題が発生した場合のトレーサビリティの確保や、流通経路の把握等も行う事ができる。
図60は、統合後のデータ加工があり、また複数の証明書を含む場合の配信データを示す図である。2つのデータ提供事業者からの情報をあわせて、新たな加工データ(特徴を抽出してグラフ化したものや、地域、天気、ユーザの属性、などで抽出し特定セグメントで情報をぬきだしたもの、さらにこれらを見やすいように並び替え(地域の北から南、年齢順など)たもの、また同じ時間帯における同じ操作の履歴を抽出したもの、などの加工データを有する場合は以下のようになる。
元のデータ501およびデータ502を元に加工した加工情報508とともに加工情報全体を示すJSONスキーマであるJSONスキーマ509を準備し、そこに加工情報508の内容を記述するとともに、新たな証明書510を情報銀行53から受信し、加工情報自体の信頼性を担保する。その上ですべてのデータ512における流通用の包括付帯情報511を設け、ここに加工情報508、付帯情報509、加工データ証明書510、元データ501及び元データ502の概要を記載する。なお、元データをそのまま取り出した場合もしくは、元データのある部分を取り出しただけの場合、新たな証明書510は省略可能である。また、加工データは、同じ時間帯かつ同じ操作のデータを抽出して得られたデータ、同じ地域のIDを持つデータを抽出して得られたデータ、元データをグラフ化して得られたデータなどである。
このひきまとめた情報全体の暗号化は、暗号化範囲513を対象とし、ひきまとめたデータ全体の証明書510と包括付帯情報511を除く部分を再度暗号化して配信する。
また、この場合3つの証明書を流通データの暗号化外として別送することも可能であり元のデータに加工等がなければ暗号化された状態の元データ501と元データ502はそのまま暗号化した上で、加工データ508と加工データ508の付帯情報509を新たに暗号化し、加工データ証明書510と全体包括付帯情報511をつけて配信する方法もある。
この場合、元のデータ501及び502の暗号化を解くためのキー情報も配信する必要があり、この501及び502の暗号キーを加工データの付帯情報509内に記述してこれ自体を加工データ509とあわせて再暗号化して暗号強度を強化する方法もある。
図61の階層化データの証明書と付帯情報を示す図を参照しながら、階層化されたIoTデータに対する証明書の発行と付帯情報につき説明する。
図61においては、関連するデータをまとめて証明するため、本図のように複数の階層にまたがって証明書がカバーされる。
この際、証明書96自体をあらかじめ付帯情報514、付帯情報515及び付帯情報516を有するデータのすべてもしくは、個々別々、もしくはいくつかの組み合わせのすべてで証明書が有効になるよう、データ内容のチェック・監査を行う。このように組み合わせであっても証明書自体を有効化することによって、上位のみ、中位のみ、下位のみ、もしくは複数の組み合わせ、だけを送付する場合も証明書96で対応できるようにしておく。
この際分割の組み合わせに応じた複数の暗号キーの提供を情報銀行から受け、サービサとの商談内容に応じたファイル群の組み合わせで対応するキーを提供する。
証明書96の発行は、情報銀行によるチェックの工程を踏んで行われるため、サービサの要求により階層別の送付が必要になった場合に、再度証明書発行を行うための手続きが不要となるため、データ流通市場におけるサービサとの間で迅速な流通決済の処理が可能となる。
また、包括付帯情報517にある概要付帯情報は、証明書の範囲外とし、サービサの要求で送付するデータ群を変更する場合、流通及び販売に必要な付帯情報として、データのカタログ概要、ちらし情報、更新日時/頻度、データ規模、データ階層あるいは構造、証明書の有無、個人情報の有無、販売額、販売元、連絡先などを記載変更できるものとする。例えばデータ提供事業者の住所、電話番号あるいは販売価格が変わった場合などでも個々のデータ証明書を取り直す必要はなくなる。
これによりIoTデータそのものではなく、データ流通販売に必要な情報を証明書の範囲外の情報を、データ証明発行以降も必要に応じて追記もしくは変更でき、データ流通市場における迅速な流通決済処理及びシステムコスト削減ができるようになる。
図62は、階層集約後の証明書と付帯情報を示す図である。データ自体が古くなりデータの鮮度が落ちてきた場合(例えば10年前の情報など、めったに使用されなくなったデータ)、データサーバでは最下層のサーバシステムに落とし込むことで、データ維持コストを削減する方法がある。
この場合でも証明書96でカバーされたデータ群をまとめて最下層に配置することになるが、この階層変更に関し、上述した概要付帯情報に変更履歴を記載することでも対応できるものとする。
このようにすることで、過去のデータの階層を変更する際に新たな証明書を取る必要がなくなり、膨大なデータを管理しているメーカクラウド及びサービサクラウドでの維持コスト低減を図ることが可能となる。
このとき、包括付帯情報518に階層変更があった旨を記載する事によって、当初証明書96が発行された際と異なる階層に付帯情報を含む情報が変更されても、証明書96の証明内容がそのまま担保されるものとする。
このようにすることで、長期間の保存での階層変更あるいはサービサにニーズの変化に伴い階層レイヤを変更した際でも、新たな証明書を取りなおすことが必要なくなり、全体のデータ管理システムの維持コスト削減が可能になる。
図63は、データ群の分類を示す図である。データの分類には、アクセス頻度あるいは使用頻度による階層化だけではなく、サービサへ配信するデータ群として大きなくくりで分割しておく必要がある場合がある。
特に高付加価値データとして提供コストを他の一般データと分けておきたい場合に、個人情報を含みその取り扱いにおいて特別な扱いが必要なものなどである。
このような大きな分割は、サービサがデータ流通市場から購入する際に必要となってくるものであり、機器単位・意味単位といったデータカタログ情報群のさらに上位で、流通のしくみ上必要となってくるものである。特に価格別に流通データ群を分けておくことは、随時更新し配信されるIoTデータ群において売買時の費用処理システムを簡素化する効果がある。
また、個人情報を含むデータを他の一般データと分ける理由は、例えば欧州連合のGDPR(General Data Protection Regulation:一般データ保護規則)で規定されるように、サービサへ配信したデータであっても元データの個人が削除を希望する場合関連する情報を削除するような処理が必要となるからであり、サービサにおいて個人情報を削除可能なシステムコスト・管理コストの高いサーバシステムへの保管を自動的に行う事で情報事故を回避できるようになるからである。なお個人情報の有無及び流通コストが高いものかどうかについては付帯情報内に記載されるべきものである。
いくつかのデータ群を分類する分類については、データ群の分類種別がどのようになっているかについて、包括付帯情報内に記述しておく必要がある。
データ群の分類については、
(1)更新頻度別階層分類:サーバ特性を配慮した階層構造でデータ容量とアクセス頻度の違いによるファイル分けを行い、全ファイルを最短更新させないようにする。
(2)単価別データ分類:販売データ単価が異なる価格別分類(データ付加価値での分類)で例えば元データの意味が深いものと浅いもの、あるいは加工に工夫したデータと生データで価格差をつけるなどする。
(3)GDPR対応度合い別分類:個人情報の有無による分類でデータ取り扱いに注意が必要なものは分けておきデータ全体が取り扱い注意とならないようにする。
(4)データ集約度別分類:データ集約度合いによる分類(年月日)の単位別データ分類で月及び年はデータ集約度(まるめ)が高いためまるめられたデータとそうでないものを1つのファイルにしないで分けておく。
等があるが、これらの組み合わせとなっている場合、どれとどれの組み合わせになっているかを付帯情報に記述しておく必要がある。
また、包括付帯情報では、個々のデータのIDでもって構造を記述し包括付帯情報以下の情報がどのように配置されているかを記述することで、本情報で全体構造が把握できるようにする。
例えとして、図64を参照しながら、提供コストを高くした高付加価値データ526と個人情報を含み取り扱いに注意が必要なデータ527が、通常のデータ528とは別に存在するケースを示す。
この場合、特定のデータ提供事業者が管理している、特定の地域に限定される場合、特定の機器もしくは機種でくくられるケース、特定の家の集合体(特定の住宅メーカもしくはマンションに紐づけられたもの)などで、お互いのデータに関連があり全体としていつのデータ群を形成している場合、高付加価値データ526と、個人情報を含み取り扱いに注意が必要なデータ527が、通常のデータ528それぞれにおいて付帯情報519、付帯情報520及び付帯情報521が個々の分類単位で設けられる。
また、上述のように、関連するデータにおいて、付加価値(販売額)が異なる場合や提供先が限定される情報などを含むものに分けられる場合、それぞれにデータ証明書523、データ証明書524及びデータ証明書525が個々の分類単位で設けられ、全体の情報内容を記述した包括付帯情報522が設けられ、通常のデータを流通させる場合は通常のデータ528を暗号化するとともに、送付内容を記述した元の包括付帯情報522から抜粋して作成した包括付帯情報521を付けてサービサ55に配信する。ここで、包括付帯情報522は、関連するすべてのビックデータに関する付帯情報であって、証明書が不要であり変更が可能な情報である。
サービサ55はこの包括付帯情報521の内容を読み取りサービスアプリを起動したりストレージサーバに自動保存する。
本事例では高付加価値データ526と、個人情報を含み取り扱いに注意が必要なデータ527を分けたが、この両方の組み合わせの場合も別で分割ファイルを構成する。
また更新頻度あるいはアクセス頻度に差がない場合は、これによるストレージサーバの階層を分ける処理は不要である。
このようにすることで、ファイル管理上重要な個人情報管理と費用管理を、膨大なデータが混在する場合でも確実にかつ迅速に処理することが可能となる。
もし費用の異なるデータや個人情報管理の厳しいデータがそれ以外と混在すると、利用時に1つ1つのデータをチェックし抜き取ったり選別したりする新たなクラウド処理が発生し、データ管理規模が膨大なビックデータになってくれば、これらの処理コストが膨大に膨らむことになるため、本ファイル形式によってコスト最適化がはかれるようになる。
図65は、リアルタイム更新データの配信を示す図である。エネルギーマネージメントに使用するデータは、エネルギー管理上、例えば30分単位の情報流通が必要となってくる場合があり、このような電力データ、随時監視が必要な見守りサービスで使われる情報などにおいては、リアルタイムでのデータ流通が必要となってくる。
このようなデータにおいてデータ証明書を付ける場合、データの信憑性のチェックと証明書の発行をリアルタイムで行う事が難しいため、例えば1ヶ月単位のデータに対し月末で証明書を発行し、後付で承認する方法がある。
例えば図65では3月分のデータ528は証明書を含むまとまったデータに対し3月分の包括付帯情報529を付けてサービサ55へ配信されるが、4月1日のデータ530はまだ証明書が発行されていない状態にある。
そのため、この場合まだ証明書がついていないデータ配信においては包括付帯情報531において証明書が無い旨を記述し、月末最終日の証明書発行後にその証明書を含むスキーマ上に過去分も含め証明した旨の記載を行う。
従って、月末最終日の証明書付きデータの包括付帯情報537は、例えばその月すべての証明書がカバーする内容を記載したスキーマとなる。
また、この際は4月30日のデータ535と後付の4月分の証明書536と、前記包括付帯情報537を合わせてサービサ55に送付する形式となる。例えばデータ量が地域の各家庭からのデータであったり膨大なデータ量となる場合などでは、毎回過去のデータを含めて配信するとデータコストがかさむため、あくまでその日の分のデータ535を配信する形態となる。
また、具体的な包括付帯情報537の記載においては、添付している証明書536がカバーする範囲(過去送付分の証明範囲ID(証明開始するデータのID、証明終了するデータのID)もしくは、証明範囲期間(証明開始日時、証明終了日時)、もしくは証明する全ファイルのID)を記載する。
これにより、過去データをさらに流通させる場合においても、本証明書付きデータの包括付帯情報をベースに、データ提供側と受領側であるサービサが確認し、当該範囲期間のIoTデータを流通させることが可能となる。
特にこのようにすることで、リアルタイムデータを配信し、かつある間隔で証明書を取得発行することが可能となる。
図66は、リアルタイムデータを使ったサービス事例を示す図である。図66は、スマートシティ542において、HEMS事業者のクラウド538と電力アグリゲータのクラウド539が、リアルタイムデータの配信によって行う、タウン電力マネージメントシステムの事例である。
この場合、スマートシティ542内の各家庭58には太陽光発電システム543が搭載されており、各家庭の消費電力データ及び太陽光発電システム543の発電量及び売電量などのリアルタイムデータが例えば30分単位にアップされ、各家庭58における家庭内のスマート家電(太陽光発電システム543を含む)をHEMS事業者のクラウド538から、例えばHEMSコントローラを介して制御し、各家庭58の省エネ管理及び生活支援サービスが行われる。
このようなHEMSシステムを運営している事業者において、これら各家庭58での30分毎の電力情報がクラウド538にアップされており、このリアルタイムデータ545を電力アグリゲータのクラウド539に配信することで、電力アグリゲータが電力供給・需要管理を行い、発電事業者の発電システム540を最適運転することで、スマートシティ542の全体エネルギー管理が実現する。
電力アグリゲータは、クラウド539からHEMS事業者クラウドに対し、給湯機などの蓄熱機器への制御指示を行うことで、太陽光発電の余剰電力が大きい場合にお湯を給湯機で昼間に作るなどといった、電力平準化の指示を出すことも可能となる。
いずれも発電システム540の運転状況と太陽光発電システム543の発電状況をリアルタイムでチェックしながら、発電システム540の発電量を全体調整していく。
電力需給は逼迫するケースでは、場合によりHEMSシステムにて省エネ設定などの指示を行う事も可能である。
これらのHEMSシステムは、同一地域内において複数の事業者がサービスをしているケースもあるため、電力アグリゲータクラウド539へのデータ配信は標準フォーマットにより統一されることで個別のインタフェース開発、仕様すり合わせなどが不要となる。
特にスマートタウン規模となると電力データのデータ規模も膨大なものとなるほか、各家庭58の消費電力量、機器の操作状況などといった個人情報に関連する情報もあり、これらデータの取り扱いにおいては、情報銀行53の配信データ監査を受けデータ証明書を発行いただくことが望ましい。
そのため前述したリアルタイムデータの配信手続きにより、タイムラグはあるものの、データ証明を定期的に受けることで、情報事故を最小限に食い止めることが可能となる。
図67は、蓄積データを使ったサービス事例を示す図である。冷蔵庫547などの食料品を保存する機器におけるスマート化が進むと、例えば冷蔵庫547内にカメラ547aを搭載し、庫内の食品状況を撮影しスマートフォンに転送することで、宅外で確認するなどのサービスが実現できる。
これらのシステムでは冷蔵庫メーカが有する家電管理用のメーカクラウド548に接続されており、メーカクラウド548において画像認識等により食材画像情報552から食材内容を特定しデータ化する(例えばりんご5個、きゅうり3本、ビール2本、キャベツ1個、醤油1本、牛乳1本など)処理を行うことも可能になる。
ここで各家庭の冷蔵庫情報を管理するメーカクラウド548においては各課程の食材在庫情報が随時アップされており、ここを統計的に処理することで、例えばどのような食材が購入されて消費されているか、またどの食材あるいはどのメーカの商品が多く消費されているか、といったビックデータを蓄積取得することが可能となる。
これらのビックデータを、例えば同一の地域毎に家庭で当該メーカの冷蔵庫を保有している分から集計し、週単位でスーパーのクラウド553あるいは当該地域の商店共同運営クラウド554に配信することで、スーパーあるいは商店がその季節、時期・地域における食品の購入志向あるいは好みに合わせ食品生産業者555あるいは農協等556の生産者に事前発注し、旬の食材の流通時期を逃さないように商品在庫管理及び発注をすることが可能となる。
例えば特定の商材の購入数の伸びが右肩あがりにのびつつある兆候をとらえ、事前手配をかけるといったアクションをとることができる。
もちろんこれらは、リアルタイム発注により当日配送を行うなどのネットスーパーシステムとも連動し、ネットスーパー購入発注時のスマートフォンアプリあるいはPCアプリの商品選択画面に、上記売れ行きが伸びつつある商材を優先的に表示配置し、事前仕入れの加速と合わせ、さらなる販売加速に使うことも可能となる。
ここでは、メーカクラウド548からスーパーのクラウド553あるいは地域商店のクラウド554へのデータ配信は、冷蔵庫食材情報といった個人情報に関連する部分を含むため、配信データの内容を情報銀行53にて監査し、証明書を付けて送付することになるものの、統計データであればリアルタイムではなく、送付の都度証明を受けるのであれば図65のリアルタイムデータには該当しない。ただし、週単位のデータ送付であっても証明を受けるのが月単位であれば、図65のリアルタイムデータの扱いと同じになる。
図68は、データファイル通信プロトコルを示す図である。メーカなどのデータ提供事業者51及び情報銀行53のクラウドとサービサ55のクラウド間の情報のやりとりについては、まずデータ販売前のやりとりと販売(契約)確定後のやりとりに分けられる。
データ販売前においてはどのようなカタログ情報を持っているかといった目次情報などのチラシ情報として、データ流通市場で閲覧できるものを提供する必要があり、ここではデータ販売内容情報などを記載したちらし情報557がまずデータ流通市場に提供される。
次にサービサ55からは、ちらし情報557を確認した上で必要なカタログ購入依頼558がデータ提供事業者51に発行される。
そしてデータ販売の了解と見積書559が発行され、実際のデータ配信前の購入決定処理が完了する。なおこれらの購入前処理の情報についてもJSONスキーマ等のファイル形式でやりとりすることで後述する包括付帯情報の記載とあわせ、内容のマッチングを取ることが可能になる。
またデータ販売が確定した以降は、まずサービサ55からデータ配信要求563があり、次にメーカクラウドから包括付帯情報94を送付し、これの受領を確認する受領確認情報560を受けてから、証明書96の送付、またこの証明書の受領確認とデータ送信依頼561を確認した後、暗号化したIoTデータ本体500を送付(JSONもしくはJSONスキーマによる付帯情報を含む)することになる。
またこの後前述の暗号化データの暗号キー99aを送付し、最後に受領決済情報562を返すことで、一連のデータやりとりが終了するとの手順が考えられる。
なお、上述のデータ証明書はIoTデータ本体とあわせて暗号化しまとめて送ってしまう方法もある他、包括付帯情報及び証明書も含めてまとめて暗号化されたファイル565でまとめて送る方法もある。この方法により、サービサとの確認手順を省略できる。
このようにまとめると、メーカクラウドとサービサクラウド間のシーケンスを省略し、販売前、データ送付、受領決済の3つの処理に簡略化できるなど多くのデータ流通を同時に行いやすくするメリットがある。
特にデータ流通ではREST API(REpresentational State Transfer API)の思想に基づき、セッションなどの状態管理を行わない事が全体システム簡素化に必要であるが、売買の部分においてのみ確認及び決済のプロトコルを残すことが全体システムとして安全かつ効率的である。
図69は、データ提供側にアプリを持つ場合のデータファイル通信プロトコルを示す図である。IoTデータが大規模でサービサ55のクラウドのストレージ容量が小さい場合、サービサ55のサービスアプリがスマートフォンに実装される場合などにおいて、付帯情報のみをサービサ55に送付し実際のIoTデータ自体をサービサが都度データ提供事業者51のクラウドにアクセスすることで対応できるかどうかのフラグ情報もあわせて付帯情報に記載しておくことで、サービサ55が本フラグを確認してからデータ提供事業者51のクラウドにアクセスし、サービサ55がすべてのIoTデータを自身のストレージサーバに入れなくてもサービスに対応することが可能である。当該アプリにより、IoTデータを見える化したり、ある閾値を超えたかどうかの判定を行うことができる。
このためには、サービサがデータを購入する前のちらし情報557においてデータ提供事業者51のクラウドで処理できるデータの見える化、閾値判定などのアプリ内容が記載され、サービサはこの内容を含んで購入判断を行う。実サービス起動時ではメーカクラウドからのスキーマ情報において、閲覧モードが使用可能であるフラグが立っている場合、サービサクラウドは自身のスマートフォンアプリに閲覧モード可能を通知し、スマートフォンからメーカクラウドの閲覧データ依頼のスキーマを送付する。
閲覧データ依頼には、サービスの内容であるIoTデータの見える化表示(例えば使用電力量のグラフ化、機器の使用頻度回数のグラフなど)であったり閾値判定(例えば設定温度を超えているかどうか)などのデータ変換あるいは判定を依頼、メーカクラウド上に搭載された閲覧アプリから得られる閲覧結果をスマートフォンに表示したり判断に使うことでスマートフォンアプリのメモリ領域の削減が可能となる。
図70はデータ流通前のIoTちらし情報を示す図である。IoTデータ流通における販売前のちらし情報は、一般的な宣伝広告資料としてビジュアル化したものもあるが、まずはカタログの目次を記述したJSONもしくはJSONスキーマでの市場展開が考えられる。
この場合、例えばこのスキーマで記述されたちらし情報557を使って、複数のデータ提供事業者51のクラウドからのちらし情報にある目次情報を結合し新たな総合目録情報572を作成することで、データ流通市場運営サイト569自身あるいはデータ流通商社機能を持ったデータ流通商社570がデータ総合目録572をもってデータ販売サイト上で市場運営することが可能となる。
ここではカタログ化されたデータの提供事業者名、データ規模、取得件数、計測メッシュ、取得期間、機器内容、機器数、価格情報、の一部もしくは全部をリスト化したちらし情報571としてデータ流通市場運営サイト569に展開するとともに、ちらし情報571は、データ提供事業者51から事前に開示される情報が部分的に無い場合であっても、リストの一部もしくは全部の項目がすべて記載されたものであるか、もしくは各項目につけられた項目番号でもって管理でき、総合目録572が容易に作成できるものとする。
またサービサ55においては、この総合目録572があることによって、各データ提供事業者51を個々に検索し必要な情報を集めてくる膨大な手間が不要であり、またデータ流通商社あるいはデータ市場運営サイト自身が総合目録572を作成し、例えばこれをビジュアル化することによって、サービサ55へのデータ販売を促進させる効果がある。総合目録572は複数のメーカクラウドのデータを集めた場合に、機器単位、意味単位、もしくは特徴抽出し切り出したものを、流通商社自体の業務として提供することが可能である。
図71は、データ流通前の購入希望・販売内容情報を示す図である。IoTちらし情報557は、実データを含まず、カタログ情報・目次やデータの量、取得期間、メッシュ等の基本情報を、ちらしとして汎用的に提供するものであり、例えば温度情報、電力データなどの実際のデータは含まないものの、データ売買を行うために必要となる情報を含むものである。
そのため、そのデータがどのような機器から出てくるものか、それは制御情報なのか状態を表す情報なのかといった意味、いくらで販売するか、といった内容のものを実データ提供前にやりとりを行う。
データ価格の設定については、機器IDの個数と更新頻度あるいはデータ精度により決定される場合もある他、単純に送信データByte量で規定する場合などが考えられる。なお、ここでは市場で公開しているIoTデータちらし情報に対し、購入するサービサ55より必要なデータを選択し見積金額を算定、最終的に販売金額を双方で了解するといった手順が考えられる。
これらの価格見積方法については販売側のクラウドにWeb経由で自動計算するアプリプログラムを搭載し、データを必要とするサービサが、この見積システムにアクセスし金額を確認する方法もある。
なお、ちらし情報557を確認した後、サービサ55は購入希望情報558を配信する。ここではちらし情報の中から必要なデータあるいは不要なデータを記述したものであり、それぞれのデータに対し購入希望の有無が記述される。
当然であるが備考欄等にちらし情報557以外の情報入手希望、更新頻度、データそのもののまるめ(平均化対応など)などの依頼情報を別途記述してもかまわない。
またデータ提供事業者は、購入希望情報558を元に、販売内容の確認及び見積書の情報559を送付し、ここではデータカタログのそれぞれに対し、了解かどうかの記載が行われる。
このような決済処理等においても標準的なフォーマットを規定することで、多くのデータ提供事業者51及び多くのサービサ55が、標準的な売買アプリケーションによりデータ売買を行うことが可能になる。
図72はIoTデータの付帯情報を示すテーブル内容である。本テーブル情報はJSON、JSONスキーマ、XML等の言語で記述され、ID番号としてクラウド内で使われるURL表示でもって記述されるものである。
テーブル内容としては、本付帯情報のID、ファイル形式、データ格納リンク先ID、下位層付帯情報リンク先ID、ファイル配信頻度、暗号化有無、暗号形式、データ配信者、データ加工者、元データ供給機器製造者、証明書の有無、情報銀行などの証明者、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データ販売事業者、データ取得期間、データ配信元機器、データカタログ内容どを含み、本付帯情報を認識することでどのようなデータが配信されるかがわかるようになっている。
ここでは特に、データ加工内容の記述で意味単位、機器単位、時間単位、地域単位等での加工内容がわかるほか、データカタログ内容や更新頻度情報によって前述したストレージ階層を自動的に振りわけストレージすることが可能になる。
またデータ配信元機器数やデータサイズ・取得期間・証明書関係などはデータ規模だけでなくデータ販売価値に関連する情報であり、サービサへの提供が必要となってくるものである。
図73はデータちらし情報テーブル内容を示す図である。本テーブルはデータ販売前のデータちらし情報557で、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データカタログ内容、データ配信機器、データ証明書有無、ファイル形式、データ閲覧モード、データ販売希望価格、付帯ファイルID、付帯ファイル内容などを含む。
本情報は流通データそのものではなく、サービサ55が購入を検討するにあたって必要となる情報のみを抜粋したもので、当然データ提供事業者55が秘匿すべきと見なす場合の項目は中身を記載しないものとする。
これら項目を標準的なちらし情報としてデータ流通市場で流通させることにより、どのサービサも同じ視点でデータを確認したり、購入検討用のアプリケーションで自動判断することができるようになる。
特に多数のデータ提供事業者51からの情報提供によりサービスを行う場合においては、これらちし情報の標準化が不可欠であり、購入先の提供者数が多くなればなるほど購入アプリケーションによる自動購入が不可欠になるためである。
また本チラシ情報557には、付帯ファイルID、付帯ファイル内容、が記載されており、ここでは後続の付帯ファイル564において、本データの使い方事例、閲覧モードの使用方法などの情報が添付されるものである。IoTデータはサービサがデータ内容からサービスを起案し実行するものであるが、機器の特徴などを熟知したデータ提供事業者がある程度の使い方事例を提供した方が、データ市場流通が拡大する可能性があることから、このようなデータ内容以外の記述があった方が望ましい。また、開示してもよいデータ構造については、この使い方事例の中で紹介する。データ構造自体も1つの情報であるため、原則としてちらし内には記述しない。
特に店舗、個人商売などの小規模サービス事業者には、必ずしもデータの使い方に熟知しているとは限らず、テキスト文章・絵・写真・動画等の使い方事例、使うにあたっての注意事項などをファイル形式で直接添付するか、もしくはこれら事例が記載されたデータ提供事業者のURLを記述することで、より多くのユーザでデータ流通売買ができるようになるものである。
図74は包括付帯情報94のテーブル内容である。本テーブルの前段部分はデータ販売前のデータちらし情報557と同じであり、本ファイルのID、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データカタログ内容、データ配信機器、データ証明書有無、ファイル形式、データ閲覧モード、データ販売希望価格から構成される。
さらに上記ちらし情報557以降の情報として、データ構造(階層等)、本ファイル配置位置、ファイル配信頻度、暗号化有無、暗号形式、データ配信者、データ加工者、元データ供給機器製造者、証明者、データファイルID、データ見積もり金額などが記載され、上記ちらし情報557とあわせて包括付帯情報94が構成される。包括付帯情報94は、販売後に付帯させるものであり、証明書が不要かつ更新が可能な付帯情報である。これはサービサ55が本包括付帯情報を確認することで、購入前のちらしと同じか、もしくはその後の交渉等で修正した部分などをチェックできるようにしたものであり、このチェック処理もサービサ55のアプリケーションで自動化する事が望ましい。
また包括付帯情報は暗号化処理や証明書取得後にも追記修正できるデータであるため、ファイル配置や配信者、金額等の情報が記述される。
図75はデータ構造の記述を示すための包括付帯情報テーブル記載内容の詳細である。特にIoTデータが複数のファイルに構造化されている場合は、これに関する記述が必要であり、ここで包括付帯情報を含むファイル自身が、さらなる全体構造の中の1つである場合は本ファイルの上位階層の有無を記載し、上位を含む全体構造はさらに上位の包括付帯情報内に記載される。
例えば、本図では更新頻度が異なりかつ販売価格が異なる場合で構造化した事例を記載し、第一階層、第二階層、第三階層の3つにファイルをふりわけたものである。
データ構造全体(階層等)−更新頻度別3階層+単価別分類
本ファイル配置位置 −最上位データファイル
ファイル1(ID:****)―第一階層(更新頻度高)+無償
ファイル2(ID:****)―第二階層1(更新頻度中)+100円/T
ファイル3(ID:****)―第二階層2(更新頻度中)+200円/T
ファイル4(ID:****)―第三階層(更新頻度小)+500円/T
ここでは全体構造を記述するとともに、各IoTデータファイルが全体構造のどこに該当するかを記述する。
ただし、特に個人情報のファイルを分けて配置している場合に、データ構造全体自体が秘匿情報になる場合もあり、配信するデータの階層構造のみがわかるよう、自身の階層及び同一階層で配信するデータがある場合はそのすべてと、その下にぶら下がっている配信するデータ群の階層構造を本包括付帯情報内に記述し、自身の階層から上位にある配信しない部分の構造や、同列の階層及び下の階層で配信しないものは秘匿する。
また自身より上位階層のデータを配信する場合であっても、上位階層の配信有無のみを記載し階層構造や内容を記載しないことで構造を秘匿するものである。
特にサービサへの提供以降で、サービサ自身がさらに別のサービサへデータの分割提供を行う場合も想定されるため、上位の構造情報はその下の包括付帯情報には記載しないこととし、構造情報の伝播を防ぐようにしたものである。
本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施の形態ではなく、請求の範囲によって示される。そして、請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。
本出願は、2018年8月24日に出願された、日本国特許出願特願2018−157582号に基づく。本明細書中に日本国特許出願特願2018−157582号の明細書、特許請求の範囲、図面全体を参照として取り込むものとする。