JP7462705B2 - データ収集サーバ及びデータ流通方法 - Google Patents

Description

本発明は、データ収集サーバ及びデータ流通方法に関する。

機器から取得された機器データを取引対象とするデータ流通市場の形成が進められつつある。例えば、特許文献１には、多数の無線通信ノードと、無線通信ノードからセンシングデータを収集する仲介サーバと、仲介サーバからセンシングデータの提供を受けるアプリケーションサーバとを含むセンシングネットワークにより、データ流通市場を形成することが示唆されている。

特開２０１５－３８４８４号公報

一方、IoT（Internet of Things）関連技術の進展により、膨大な機器データがデータ流通市場に流通することが予想される。しかし、データ流通市場に膨大なデータが流通することが予想されるにも関わらず、特許文献１には、膨大なデータを扱う技術に関しては何ら示されてない。そのため、膨大な機器データを扱うための技術が求められている。

本発明の目的は、上記の事情に鑑み、膨大な機器データを好適に扱えるデータ収集サーバ等を提供することにある。

上記の目的を達成するため、本発明に係るデータ収集サーバは、
記憶手段に保存された機器データと前記機器データに対応する付帯情報とを取り出すデータ取り出し手段と、
前記データ取り出し手段により取り出された１以上の前記機器データと前記付帯情報との組であるデータ群に関する包括付帯情報であって前記データ群の販売価格を示す情報を含む包括付帯情報を作成する包括付帯情報作成手段と、
前記データ群と前記包括付帯情報とを、流通データとしてデータ利用サーバに送信する送信手段と、
を備える。

本発明によれば、機器データの使用頻度を推定するので、膨大な機器データを好適に扱える。

本発明の実施の形態１に係るデータ流通システムの構成を示す図 本発明の実施の形態１に係るデータ収集サーバと接続されたストレージサーバの特性の一例を示す図 本発明の実施の形態１に係る機器が送信する機器データの一例を示す図 本発明の実施の形態１に係るデータ流通システムがインターネットを介して構成されていることを例示する図 本発明の実施の形態１に係るデータ収集サーバの機能的構成を示すブロック図 本発明の実施の形態１に係るデータ収集サーバによる、機器データの意味を特定することの一例を示す図 本発明の実施の形態１に係るデータ収集サーバによる、機器データの意味に基づいて使用頻度を推定することの一例を示す図 本発明の実施の形態１に係るデータ収集サーバがストレージサーバに保存するデータの一例を示す図 本発明の実施の形態１に係るストレージサーバに機器データ及び付帯情報が保存される様子の一例を示す図 本発明の実施の形態１に係るストレージサーバに機器データ及び付帯情報が保存される様子の別の一例を示す図 本発明の実施の形態１に係るデータ利用サーバの機能的構成を示すブロック図 本発明の実施の形態１に係るデータ収集サーバのハードウェア構成の一例を示す図 本発明の実施の形態１に係るデータ収集サーバによるデータ保存の動作の一例を示すフローチャート 本発明の実施の形態１に係るデータ収集サーバとデータ利用サーバによるデータ流通の動作の一例を示すシーケンス図 本発明の実施の形態２に係る機器の機能的構成を示すブロック図 本発明の実施の形態２に係るデータ収集サーバによるデータ保存の動作の一例を示すフローチャート 本発明の実施の形態３に係るデータ流通システムの構成を示す図 本発明の実施の形態３に係る施工業者サーバが送信する施工データの一例を示す図 本発明の実施の形態３に係るデータ収集サーバが個人情報ストレージに保存するデータの一例を示す図 本発明の実施の形態４に係るデータ収集サーバが送信する流通データの一例を示す図 本発明の実施の形態４に係るデータ収集サーバが送信する流通データに含まれる包括付帯情報の一例を示す図 本発明の実施の形態４に係るデータ収集サーバの機能的構成を示すブロック図 本発明の実施の形態５に係るデータ収集サーバの機能的構成を示すブロック図 本発明の実施の形態６に係るデータ流通システムの構成を示す図 本発明の実施の形態６に係るデータ収集サーバと証明サーバによるデータ証明の動作の一例を示すシーケンス図 本発明の実施の形態６の変形例に係るデータ収集サーバが送信する流通データの一例を示す図 従来の情報銀行を活用したデータ流通システムを示した図 従来の情報銀行を活用したデータ流通システムにおけるデータの流れを示す図 従来の複数のメーカが存在する場合の家庭内機器の情報転送を示す図 機器から出てくる情報の説明図 データ提供事業者とサービサでの流通を示す図 データ提供事業者とサービサでの流通において異なるデータフォーマットで配信された場合を示す図 機器の情報による見守りサービスの例を示す図 標準データフォーマットで配信された場合を示す図 メーカとサービサ間でのダイレクト情報転送時のデータの流れを示す図 複数のメーカが存在する場合のWeb_API情報転送を示す図 意味によるカテゴライズ化を示す図 別の情報とのリンクによる付加価値を示す図 別の情報とのリンクによる付加価値事例を示す図 データの深さによる階層化を示す図 クラウドサーバ上の階層化構成例を示す図 サーバ特性を配慮したデータ階層化を示す図 サーバ特性とデータの深さによる階層化を示す図 更新頻度情報の例外活用事例を示す図 データ階層におけるリンクを示す図 データ格納事例-パターン一覧を示す図 更新頻度情報の記載を示す図 機器からのデータファイル形式を示す図 カタログ化データファイル形式を示す図 ＪＳＯＮスキーマによるフォーマット情報付加例を示す図 データファイルのＩＤによるリンクを示す図 個人情報の管理例を示す図 付帯情報の結合を示す図 機器データ配信時のフォーマット変換を示す図 カタログデータ配信時のフォーマット変換を示す図 データ証明書の発行を示す図 証明書を含む流通データの生成（データ提供事業者⇒サービサ）を示す図 証明書を含む流通データの生成（情報銀行⇒サービサ）を示す図 複数の証明書を含む場合の配信データを示す図 統合後のデータ加工があり、また複数の証明書を含む場合の配信データを示す図 階層化データの証明書と付帯情報を示す図 階層集約後の証明書と付帯情報を示す図 データ群の分類を示す図 内容が分けられた情報群と配信を示す図 リアルタイム更新データの配信を示す図 リアルタイムデータを使ったサービス事例を示す図 蓄積データを使ったサービス事例を示す図 データファイル通信プロトコルを示す図 データ提供側にアプリを持つ場合のデータファイル通信プロトコルを示す図 データ流通前のＩｏＴちらし情報を示す図 データ流通前の購入希望・販売内容情報を示す図 付帯情報テーブル内容を示す図 データちらし情報テーブル内容を示す図 包括付帯情報テーブルの内容を示す図 データ構造の記述を示す図

以下、図面を参照しながら、本発明の実施の形態に係るデータ流通システムを説明する。各図面においては、同一又は同等の部分に同一の符号を付す。

（実施の形態１）
図１を参照しながら、実施の形態１に係るデータ流通システム１を説明する。データ流通システム１は、例えば、機器データの取引のために構築されるシステムである。データ流通システム１は、データ収集サーバ１０と、複数のストレージサーバ１１と、データ利用サーバ２０と、複数のストレージサーバ２１と、複数の機器３０と、を備える。データ流通システム１は、本発明に係るデータ流通システムの一例である。図１では、ストレージサーバ１１及びストレージサーバ２１をそれぞれ３つずつ示しているが、必ずしも３台でなくてもよい。

データ収集サーバ１０は、例えば機器３０の製造者が運営するメーカサーバである。データ収集サーバ１０は、機器３０から機器データを受信し、ストレージサーバ１１に保存する。データ収集サーバ１０は、ストレージサーバ１１に保存された機器データを取り出し、当該機器データを含む流通データをデータ利用サーバ２０に送信する。なお、データ収集サーバ１０は、データ収集サーバ１０の運営者以外が製造した機器３０の機器データを受信可能であってもよい。データ収集サーバ１０は、本発明に係るデータ収集サーバの一例である。

ストレージサーバ１１は、例えばクラウドプロバイダが運営するクラウドストレージサーバである。例えば、データ収集サーバ１０の運営者は、データ保存量、データ読み出し量等に応じた利用料をストレージサーバ１１の運営者に支払う。ストレージサーバ１１は、本発明に係る記憶手段の一例である。

複数のストレージサーバ１１はそれぞれ、例えば図２に示す特性を有する。図２に示される３つのストレージサーバ１１をそれぞれストレージＡ、ストレージＢ、ストレージＣと称する。保存料金とは、ストレージサーバ１１に一定量、例えば１ギガバイトのデータを保存したときに課金される料金を示す。保存料金とデータ保存料とに比例して、課金される料金が増加する。取り出し料金とは、ストレージサーバ１１から一定量、例えば１ギガバイトのデータを取り出すときに課金される料金を示す。取り出し料金とデータ取り出し量とに比例して、課金される料金が増加する。取り出し速度とは、ストレージサーバ１１からデータを取り出す速度を示す。

ストレージＡは、保存料金は高いが取り出し料金が無料であり、取り出し速度も速いので、サイズが小さく使用頻度の高いデータを保存するのに好適である。ストレージＡは、例えばSSD（Solid State Drive）のような、高速だが低容量で高価な二次記憶装置を主として構築される。ストレージＢは、保存料金は安く取り出し速度が普通だが取り出し料金が高いため、サイズが比較的大きく、使用頻度はやや低いが１週間毎、１ヶ月毎など定期的に統計処理の対象となるデータを保存するのに好適である。ストレージＢは、例えばHDD（Hard Disk Drive）のような、あまり高速ではないが比較的容量が多く、価格もさほど高くない二次記憶装置を主として構築される。ストレージＣは、保存料金も取り出し料金も安いが取り出し速度が遅いため、定期的な使用が想定され難いデータを保存するのに好適である。ストレージＣは、例えばテープドライブのような、低速だが大容量で安価な二次記憶装置を主として構築される。

再び図１を参照する。データ利用サーバ２０は、例えば機器データに基づくサービスを契約者に提供するサービサが運営するサービササーバである。サービサは、データ利用サーバ２０により契約者に各種サービスを提供する。機器データに基づくサービスの例として、機器データに基づいて契約者の家庭内の機器３０の動作状況を把握する見守りサービス、１ヶ月間の機器データに基づいて節電プランを契約者に提案する節電提案サービス等が挙げられる。

データ利用サーバ２０は、データ収集サーバ１０に流通データの要求をする。データ利用サーバ２０は、データ収集サーバ１０が要求に応じて送信した流通データを受信し、ストレージサーバ２１に保存する。データ利用サーバ２０は、保存した流通データに含まれる機器データに基づき、契約者にサービスを提供する。データ利用サーバ２０は、本発明に係るデータ利用サーバの一例である。

ストレージサーバ１１と同様に、ストレージサーバ２１は、例えばクラウドプロバイダが運営するクラウドストレージサーバである。例えば、データ利用サーバ２０の運営者は、データ保存量、データ読み出し量等に応じた利用料をストレージサーバ２１の運営者に支払う。ストレージサーバ２１は、本発明に係る記憶手段の一例である。複数のストレージサーバ２１はそれぞれ、例えば図２に示す特性を有する点もストレージサーバ１１と同様である。

機器３０は、例えば、データ収集サーバ１０との通信機能を有するIoT機器である。機器３０の例として、エアコン、給湯機、調理器等の電気機器、電力計、温度計、風量計等のセンサ機器が挙げられる。機器３０は、自身の動作、状態等に関する情報を機器データとしてデータ収集サーバ１０に送信する。機器３０は、本発明に係る機器の一例である。

機器データの一例を図３に示す。機種データは、当該機器３０を個別に識別する機器ID（IDentifier）と、機器３０の動作、状態等の内容の情報と、当該動作、状態等を検知した日時である検知日時の情報とを含む。機器３０を個別に識別する機器IDとして、例えば機器３０の型番と機器３０のシリアルナンバーとを連結した文字列が採用可能である。動作の検知は、例えばユーザの操作により当該動作が行われる際に行われる。状態の検知は、例えば１時間毎などの一定時間間隔で行われる。機器３０は、機器３０の動作、状態等を検知したタイミングで即時に機器データをデータ収集サーバ１０に送信してもよいし、機器データを即時には送信せずに一時的に保存し、保存された機器データを一定時間毎にまとめて送信してもよい。機器データは、例えばJSON（JavaScript Object Notation）、XML（Extensible Markup Language）などの形式により表される。

図１では、機器３０とデータ収集サーバ１０とが接続され、データ収集サーバ１０とストレージサーバ１１とが接続され、データ収集サーバ１０とデータ利用サーバ２０とが接続され、データ利用サーバ２０とストレージサーバ２１とが接続されているように図示されている。しかし、物理的な通信線によりこのような接続がされていなくともよい。例えば、図４に示すように、データ収集サーバ１０、ストレージサーバ１１、データ利用サーバ２０、ストレージサーバ２１及び機器３０がインターネットＮＴに接続され、各サーバ及び機器３０がインターネットＮＴを介して通信するものであってもよい。また、全てのサーバ及び機器３０がインターネットＮＴを介して通信するものでなくてもよい。例えば、機器３０とデータ収集サーバ１０とが、インターネットＮＴではなくLPWAN（Low Power Wide Area Network）により形成された無線センサネットワーク上で通信をし、他の通信はインターネットＮＴ上で行われるものであってもよい。

データ収集サーバ１０とデータ利用サーバ２０との通信は、例えば予め定められたWeb API（Web Application Programming Interface）により行われる。例えば、データ収集サーバ１０が当該Web APIに準拠したインタフェースを有するWeb APIサーバであり、データ利用サーバ２０が、Web APIサーバであるデータ収集サーバ１０と通信するWeb APIクライアントである。データ利用サーバ２０は、データ収集サーバ１０の運営者とは異なる運営者が運営するデータ収集サーバと通信する場合であっても、当該データ収集サーバが当該Web APIに準拠している限り、データ収集サーバ１０と通信する場合と同様に通信することができる。また、セキュリティの面から、Web APIによる通信は、HTTPS（Hyper Text Transfer Protocol Secure）上で行われることが好ましい。

次に、図５を参照しながら、データ収集サーバ１０の機能的構成を説明する。データ収集サーバ１０は、通信部１００と制御部１１０と記憶部１２０とを備える。

通信部１００は、例えばインターネットＮＴと通信可能なネットワークインタフェースである。通信部１００は、機器３０、ストレージサーバ１１及びデータ利用サーバ２０と通信する。通信部１００は、特に、機器３０から機器データを受信し、データ利用サーバ２０に後述の流通データを送信する。通信部１００は、本発明に係る受信手段及び送信手段の一例である。

制御部１１０は、データ収集サーバ１０を統括的に制御する。制御部１１０は、意味特定部１１０１と、使用頻度推定部１１０２と、付帯情報作成部１１０３と、データ保存部１１０４と、取り出し条件決定部１１０５と、データ取り出し部１１０６と、を備える。

意味特定部１１０１は、通信部１００が機器３０から受信した機器データの意味を特定する。意味特定部１１０１は、本発明に係る意味特定手段の一例である。機器データの意味を特定することの一例を図６に示す。例えば、機器３０の機器種別がエアコンであり、機器データに含まれる内容が冷房ONである場合、当該機器データの意味はON/OFF制御であると特定する。なお、機器種別は機器データに含まれる機器IDから特定可能である。機器データの意味の特定は、例えば後述の記憶部１２０に保存された、機器データの内容と意味との対応付けを表すテーブルに基づいて行われる。

使用頻度推定部１１０２は、意味特定部１１０１が特定した機器データの意味に基づいて、当該機器データの使用頻度を推定する。使用頻度推定部１１０２は、本発明に係る使用頻度推定手段の一例である。

ここで、機器データの使用頻度とは、当該機器データがストレージサーバ１１に保存されたと仮定したときの、当該保存された機器データの使用頻度である。例えば、機器データがON/OFF制御を意味するデータである場合、当該機器データは頻繁に利用されることが想定される。したがって、当該機器データがストレージサーバ１１に保存されたと仮定したとき、当該保存された機器データの使用頻度は高いと考えられる。一方、機器データの意味が風向制御である場合、風向設定が変更される頻度は低く、かつ風向制御のデータは利用頻度が低いと考えられるため、当該機器データの使用頻度は低いと考えられる。

機器データの意味に基づいて使用頻度を推定することの一例を図７に示す。例えば、機器データの意味がON/OFF制御である場合、当該機器データの使用頻度は「高」と推定される。機器データの使用頻度の推定は、例えば後述の記憶部１２０に保存された、機器データの意味と使用頻度との対応付けを表すテーブルに基づいて行われる。この場合、使用頻度推定部１１０２は、意味特定部１１０１により特定された意味に対応して予め定められた使用頻度を当該機器データの使用頻度として推定する。

付帯情報作成部１１０３は、機器データに対応する付帯情報を作成する。付帯情報作成部１１０３は、特に、意味特定部１１０１により特定された意味の情報と、使用頻度推定部１１０２により推定された使用頻度の情報とを含む付帯情報を作成する。付帯情報は、上記の情報以外に、例えば、機器データがどの機器種別の電気機器によるものかを示す機器種別の情報を含む。付帯情報は、例えばJSON Schema、XML Schema、DTD（Document Type Definition）などのスキーマ言語により表される。

データ保存部１１０４は、使用頻度推定部１１０２により推定された使用頻度に応じたストレージサーバ１１に機器データを保存する。使用頻度に応じたストレージサーバ１１とは、機器データの使用頻度の高低に対応して保存先となるべきストレージサーバ１１をいう。例えば図２に示す例では、使用頻度が「高」の機器データはストレージＡに保存されることが好ましい。同様に、使用頻度が「中」の機器データはストレージＢに、使用頻度が「低」の機器データはストレージＣに保存されることが好ましい。データ保存部１１０４は、本発明に係る保存手段の一例である。

また、データ保存部１１０４は、付帯情報作成部１１０３により作成された付帯情報を、対応する機器データと関連付けてストレージサーバ１１に保存する。この際、付帯情報は、対応する機器データの使用頻度が「高」でない場合であっても、使用頻度「高」に対応するストレージサーバ１１、例えばストレージＡに保存してもよい。付帯情報は、データの取り出しの際に「索引」として用いられることが考えられるため、機器データそのものよりも使用頻度が高くなることが想定され、また機器データそのものよりも小容量だからである。付帯情報をストレージＡに保存する場合、当該付帯情報は、他のストレージサーバ１１に保存される機器データへのリンクを示す情報を含む。

ストレージサーバ１１に保存されるデータの一例を図８に示す。図８では、「高」「中」「低」の全ての使用頻度に係るデータをまとめて示しているが、上記のとおり、保存先のストレージサーバ１１は使用頻度に応じてそれぞれ異なる。

機器データ及び関連する付帯情報が各ストレージサーバ１１に保存される様子の一例を図９に示す。図９に示す例では、使用頻度「高」の機器データ及び対応する付帯情報がストレージＡに、使用頻度「中」の機器データ及び対応する付帯情報がストレージＢに、使用頻度「低」の機器データ及び対応する付帯情報がストレージＣに保存されている。

機器データ及び関連する付帯情報が各ストレージサーバ１１に保存される様子の別の一例を図１０に示す。図１０に示す矢印は、付帯情報から機器データへのリンクを表す。図１０に示す例では、図９の場合と異なり、付帯情報は全てストレージＡ、つまり使用頻度「高」に対応するストレージサーバ１１に保存されている。そして、使用頻度「高」以外の機器データに対応する付帯情報は、他のストレージサーバ１１に保存されている機器データへのリンクを含む。

再び図５を参照する。取り出し条件決定部１１０５は、通信部１００がデータ利用サーバ２０から受信したデータ要求に基づいて、ストレージサーバ１１からの取り出し対象となるべき機器データの取り出し条件を決定する。取り出し条件決定部１１０５は、例えば、データ利用サーバが直近１ヶ月間のエアコンのON/OFF制御に関する流通データを要求したとき、「機器データが示す日時が直近１ヶ月以内であり、機器データに対応する付帯情報が示す意味がエアコンのON/OFF制御である」ことを取り出し条件として決定する。

データ取り出し部１１０６は、取り出し条件決定部１１０５により決定された取り出し条件に応じて、ストレージサーバ１１から機器データ及び付帯情報を取り出す。データ取り出し部１１０６は、本発明に係るデータ取り出し手段の一例である。

制御部１１０は、通信部１００を介して、データ取り出し部１１０６が取り出した機器データ及び付帯情報を含む流通データをデータ利用サーバ２０に送信する。したがって、流通データには、機器データと当該機器データの意味の情報と当該機器データの使用頻度の情報とが含まれる。

制御部１１０は、上記のほか、データ処理のために必要な処理などの各種処理を実行する。

記憶部１２０は、制御部１１０によるデータ収集サーバ１０の制御に必要な各種情報を記憶する。例えば、上記のとおり、記憶部１２０は、機器データの内容と意味との対応付けを表すテーブル及び機器データの意味と使用頻度との対応付けを表すテーブルを記憶する。

次に、図１１を参照しながら、データ利用サーバ２０の機能的構成を説明する。データ利用サーバ２０は、通信部２００と制御部２１０と記憶部２２０とを備える。

通信部２００は、例えばインターネットＮＴと通信可能なネットワークインタフェースである。通信部２００は、データ収集サーバ１０及びストレージサーバ２１と通信する。通信部２００は、特に、データ収集サーバ１０から流通データを受信する。通信部２００は、本発明に係る受信手段の一例である。

制御部２１０は、データ利用サーバ２０を統括的に制御する。制御部２１０は、データ要求部２１０１とデータ保存部２１０２とを備える。

データ要求部２１０１は、通信部２００を介して、データ収集サーバ１０に流通データの送信を要求する。要求内容は、例えば、「直近３日間のエアコンのON/OFF制御のデータが欲しい」、「直近１ヶ月間で室温が３０℃以上となったデータが欲しい」など、特定の条件を満たすデータの要求である。

データ保存部２１０２は、通信部２００が受信した流通データを、流通データに含まれる使用頻度に応じたストレージサーバ２１に保存する。データ保存部２１０２は、本発明に係る保存手段の一例である。

制御部２１０は、上記のほか、サービスの提供に必要な処理、データ処理のために必要な処理等の各種処理を実行する。

次に、データ収集サーバ１０のハードウェア構成の一例を、図１２を参照しながら説明する。図１２に示すデータ収集サーバ１０は、例えばパーソナルコンピュータ、マイクロコントローラなどのコンピュータにより実現される。

データ収集サーバ１０は、バス８０００を介して互いに接続された、プロセッサ８００１と、メモリ８００２と、インタフェース８００３と、二次記憶装置８００４と、を備える。

プロセッサ８００１は、例えばCPU（Central Processing Unit: 中央演算装置）である。プロセッサ８００１が、二次記憶装置８００４に記憶された動作プログラムをメモリ８００２に読み込んで実行することにより、データ収集サーバ１０の各機能が実現される。

メモリ８００２は、例えば、RAM（Random Access Memory）により構成される主記憶装置である。メモリ８００２は、プロセッサ８００１が二次記憶装置８００４から読み込んだ動作プログラムを記憶する。また、メモリ８００２は、プロセッサ８００１が動作プログラムを実行する際のワークメモリとして機能する。

インタフェース８００３は、例えばシリアルポート、ネットワークインタフェースなどのI/O（Input/Output）インタフェースである。インタフェース８００３により、通信部１００の機能が実現される。

二次記憶装置８００４は、例えば、フラッシュメモリ、HDD、SSDである。二次記憶装置８００４は、プロセッサ８００１が実行する動作プログラムを記憶する。また、二次記憶装置８００４により、記憶部１２０の機能が実現される。

また、データ利用サーバ２０も同様に、例えば図１２に示すハードウェア構成をとることができる。

次に、図１３を参照しながら、データ収集サーバ１０によるデータ保存の動作の一例を説明する。当該動作は、制御部１１０の制御により実行される。

まず、通信部１００が、機器３０からの機器データの受信を待ち受ける（ステップＳ１０１）。通信部１００が機器データを受信したら次の動作に進む。

次に、意味特定部１１０１が、受信された機器データの意味を特定する（ステップＳ１０２）。上記のとおり、機器データの意味の特定は、例えば、記憶部１２０に保存された、機器データの内容と意味との対応付けを表すテーブルに基づいて行われる。

次に、使用頻度推定部１１０２が、意味特定部１１０１により特定された意味に基づいて、受信された機器データの使用頻度を推定する（ステップＳ１０３）。上記のとおり、使用頻度の推定は、例えば、記憶部１２０に保存された、機器データの意味と使用頻度との対応付けを表すテーブルに基づいて行われる。

次に、付帯情報作成部１１０３が、意味特定部１１０１により特定された意味の情報と、使用頻度推定部１１０２により推定された使用頻度の情報とを含み、受信された機器データに対応する付帯情報を作成する（ステップＳ１０４）。

次に、データ保存部１１０４が、推定された使用頻度に応じたストレージサーバ１１に、機器データと付帯情報とを関連付けて保存する（ステップＳ１０５）。ただし、上記のとおり、付帯情報は使用頻度「高」に対応するストレージサーバ１１に保存してもよい。

データ保存後、制御部１１０は、ステップＳ１０１からの動作の流れを繰り返す。

次に、図１４を参照しながら、データ収集サーバ１０及びデータ利用サーバ２０によるデータ流通の動作の一例を説明する。

まず、データ利用サーバ２０がデータ要求部２１０１により、データ収集サーバ１０に流通データの送信を要求する（ステップＴ１０１）。

次に、データ要求をデータ利用サーバ２０から受信したデータ収集サーバ１０が、取り出し条件決定部１１０５により、受信したデータ要求に基づいて取り出し条件を決定する（ステップＴ１０２）。

次に、データ収集サーバ１０がデータ取り出し部１１０６により、決定した取り出し条件に基づいてストレージサーバ１１から機器データと付帯情報とを取り出す（ステップＴ１０３）。

次に、データ収集サーバ１０が通信部１００により、取り出された機器データと付帯情報とを含む流通データをデータ利用サーバ２０に送信する（ステップＴ１０４）。

そして、流通データをデータ収集サーバ１０から受信したデータ利用サーバ２０が、データ保存部２１０２により、流通データに含まれる使用頻度に応じたストレージサーバ２１にデータを保存する（ステップＴ１０５）。

以上、実施の形態１に係るデータ流通システム１を説明した。実施の形態１によれば、データ収集サーバ１０が、機器データの意味に基づいて当該機器データの使用頻度を推定し、使用頻度に応じたストレージサーバ１１に当該機器データを保存する。そのため、膨大な機器データを効率的に保存することができる。また、膨大な機器データを効率的に保存することにより、データ収集サーバ１０の運営者がストレージサーバ１１の運営者に支払うべき料金を節約することができる。

また、データ収集サーバ１０は、機器データと、当該機器データの意味の情報及び当該機器データの使用頻度の情報を含む付帯情報とを流通データとしてデータ利用サーバ２０に送信する。そのため、流通データを受信したデータ利用サーバ２０は、使用頻度の推定をすることなく、流通データが示す使用頻度に応じたストレージサーバ２１にデータを保存することにより、膨大な機器データを効率的にストレージサーバ２１に保存することができる。

上記のいずれの場合も、実施の形態１によれば、膨大な機器データを好適に扱うことができる。

（実施の形態１の変形例）
実施の形態１では、データ収集サーバ１０は機器３０から直接機器データを受信するものとした。しかし、機器データは、機器３０から直接受信されるものでなくてもよい。例えば、HEMS（Home Energy Management System）コントローラが機器３０から機器データを受信し、データ収集サーバ１０は当該HEMSコントローラから機器データを受信するものであってもよい。この場合も、データ収集サーバ１０は、HEMSコントローラを介して、機器３０から機器データを受信する。

実施の形態１では、使用頻度推定部１１０２は、意味特定部１１０１により特定された意味に対応して予め定められた使用頻度を機器データの使用頻度として推定した。一方、意味特定部１１０１により特定された意味と同一の意味を有する機器データの取得頻度に基づいて使用頻度を推定してもよい。例えば、同一の意味を有する機器データを１日に１０回取得できた場合に、当該意味を有する機器データの使用頻度を「高」と推定することが考えられる。

実施の形態１では、データ利用サーバ２０は、データ収集サーバ１０から受信した流通データが示す使用頻度に応じたストレージサーバ２１にデータを保存した。しかし、データ利用サーバ２０は、必ずしも流通データが示す使用頻度に応じたストレージサーバ２１にデータを保存する必要はない。例えば、データ収集サーバ１０では使用頻度が高い機器データであっても、データ利用サーバ２０では使用頻度が高くない機器データを扱う場合、流通データが示す使用頻度は「高」となるが、データ利用サーバ２０は使用頻度「中」に対応するストレージサーバ２１にデータを保存してもよい。

実施の形態１では、データ収集サーバ１０は、流通データ送信の際、機器データ受信時に推定された使用頻度の情報を流通データに含めて送信する。しかし、データ収集サーバ１０は、流通データ送信の際に、推定された使用頻度とは異なる使用頻度の情報を流通データに含めてもよい。例えば、送信しようとする流通データに含まれる機器データが、使用頻度「中」である給湯機の温度制御に関するデータであり、流通データを受信するデータ利用サーバ２０の運営者が銭湯の給湯分析サービスを提供するサービサであるとする。この場合、データ利用サーバ２０の運営者にとって、給湯機の温度制御に関するデータは重要な情報であり、使用頻度が高くなると考えられる。そのため、データ収集サーバ１０は、給湯機の温度制御に関する機器データを含む流通データをデータ利用サーバ２０に送信する際、使用頻度を「高」として送信してもよい。つまり、データ収集サーバ１０は、データ利用サーバ２０に応じて使用頻度を変更して流通データを送信してもよい。

（実施の形態２）
実施の形態２に係るデータ流通システム１を説明する。実施の形態２に係るデータ流通システムは、機器３０自身が機器データの意味を特定し、機器データの使用頻度を推定し、付帯情報を機器データと関連付けてデータ収集サーバ１０に送信する点が異なる。その他の点は概ね実施の形態１と同様である。

図１５を参照しながら、実施の形態２に係る機器３０の機能的構成を説明する。機器３０は、通信部３００と制御部３１０と記憶部３２０とを備える。

通信部３００は、例えばインターネットＮＴと通信可能なネットワークインタフェースである。通信部３００は、データ収集サーバ１０と通信する。通信部３００は、特に、機器データ及び当該機器データに関連付けられた付帯情報をデータ収集サーバ１０に送信する。通信部３００は、本発明に係る送信手段の一例である。

制御部３１０は、機器３０を統括的に制御する。制御部３１０は、機器データ作成部３１０１と、意味特定部３１０２と、使用頻度推定部３１０３と、付帯情報作成部３１０４と、を備える。

機器データ作成部３１０１は、機器３０自身の動作、状態等に基づいて機器データを作成する。機器データ作成部３１０１は、本発明に係る機器データ作成手段の一例である。

意味特定部３１０２、使用頻度推定部３１０３及び付帯情報作成部３１０４の機能は、データ収集サーバ１０の意味特定部１１０１及び使用頻度推定部１１０２の機能と概ね同様であるため、説明を省略する。使用頻度推定部３１０３は、本発明に係る使用頻度推定手段の一例である。

記憶部３２０の機能は、データ収集サーバ１０の記憶部１２０の機能と概ね同様であるため、説明を省略する。

次に、図１６を参照しながら、実施の形態２に係るデータ収集サーバ１０によるデータ保存の動作の一例を、図１３に示す実施の形態１の場合と比較して説明する。

まず、通信部１００が、機器３０からの機器データ及び付帯情報の受信を待ち受ける（ステップＳ１０１Ａ）。付帯情報の受信も待ち受ける点が実施の形態１のステップＳ１０１と異なる。

次に、データ保存部１１０４が、受信した付帯情報が示す使用頻度に応じたストレージサーバ１１に、受信した機器データ及び付帯情報を保存する（ステップＳ１０５Ａ）。すでに付帯情報が存在し、かつ付帯情報に使用頻度の情報が含まれているので、実施の形態１にて実行したステップＳ１０２～Ｓ１０４の動作は不要となる。

データ保存後、制御部１１０は、ステップＳ１０１Ａからの動作の流れを繰り返す。

データ流通の動作は実施の形態１と全く同様であるため説明を省略する。

以上、実施の形態２に係るデータ流通システム１を説明した。実施の形態２によれば、機器３０自身が機器データの使用頻度を推定するので、データ収集サーバ１０が使用頻度を推定することなく、膨大な機器データを効率的に保存することができる。そのため、データ収集サーバ１０の処理負担が軽減する。つまり、実施の形態２によれば、膨大な機器データを好適に扱うことができる。

（実施の形態３）
図１７を参照しながら、実施の形態３に係るデータ流通システム１を説明する。実施の形態３に係るデータ流通システム１は、機器データのみならず、施工業者による機器３０の設置、点検、改修等の施工に関するデータである施工データも取り扱う。実施の形態３に係るデータ流通システム１は、実施の形態１の場合に加え、個人情報ストレージ１２と、個人情報ストレージ２２と、施工業者サーバ４０と、をさらに備える。

データ収集サーバ１０は、実施の形態１の場合に加え、さらに以下の機能を有する。データ収集サーバ１０は、施工業者サーバ４０から施工データを受信する。データ収集サーバ１０は、施工データを機器データと関連付けて保存する。データ収集サーバ１０は、施工データに含まれる、機器３０と関連付けられた個人情報を個人情報ストレージ１２に保存する。データ収集サーバ１０は、施工データを含む流通データもデータ利用サーバ２０に送信する。

データ利用サーバ２０は、実施の形態１の場合に加え、さらに以下の機能を有する。データ利用サーバ２０は、施工データを含む流通データもデータ収集サーバ１０から受信する。データ利用サーバ２０は、施工データを機器データと関連付けて保存する。データ収集サーバ１０は、施工データに含まれる、機器３０と関連付けられた個人情報を個人情報ストレージ２２に保存する。

個人情報ストレージ１２は、例えば、データ収集サーバ１０の運営者が運営する個人情報保存用のストレージサーバである。個人情報ストレージ１２は、機器３０と関連付けられた個人情報を保存する。個人情報ストレージ１２は、本発明に係る個人情報記憶手段の一例である。

個人情報ストレージ２２は、例えば、データ利用サーバ２０の運営者が運営する個人情報保存用のストレージサーバである。個人情報ストレージ２２は、機器３０と関連付けられた個人情報を保存する。個人情報ストレージ２２は、本発明に係る個人情報記憶手段の一例である。

施工業者サーバ４０は、例えば、機器３０の製造者と協力関係にある施工業者が運営するサーバである。施工業者サーバ４０は、機器３０と関連付けられた施工データをデータ収集サーバ１０に送信する。施工データは、例えば機器３０の施工時に施工業者の携帯端末により施工業者サーバ４０に入力される。

図１８を参照しながら、施工データの一例を説明する。施工データは、施工を個別に識別する施工IDと、施工業者のIDと、施工対象となる機器３０の機器IDと、施工内容、施工日、施工場所、施工画像等の施工に関する情報と、施工対象となる機器３０のユーザのユーザIDと、施工対象となる機器３０の設置場所の住所とを含む。前述のとおり、機器IDは機器３０を個別に識別するIDであるため、施工データから、機器３０とユーザ及び住所が関連付けられていることとなる。つまり、施工データには、個人情報が含まれている。施工データは、機器データと同様に、例えばJSON、XMLなどの形式により表される。

次に、実施の形態３に係るデータ収集サーバ１０について、実施の形態１の場合と異なる点を、図５を参照しながら説明する。

通信部１００は、施工業者サーバ４０とも通信する点が実施の形態１と異なる。特に、通信部１００は、施工業者サーバ４０から施工データを受信する。

使用頻度推定部１１０２は、施工データの使用頻度も推定する点が実施の形態１と異なる。使用頻度推定部１１０２は、機器データの場合と異なり、施工データの使用頻度の推定の際に、施工データに含まれる各種データごとに使用頻度を推定する。図１８に示す例を用いて説明すると、施工ID、業者ID、機器ID、施工内容及び施工日のデータについては使用頻度が高くなることが想定されるので、これらのデータの使用頻度を「高」と推定する。一方、施工場所及び施工画像のデータは、めったに使用されないことが想定されるため、これらのデータの使用頻度を「低」と推定する。なお、ユーザID及び住所のデータは、個人情報であり、後述の通り個人情報ストレージ１２に保存されるため、これらのデータについては使用頻度の推定をしない。

付帯情報作成部１１０３は、施工データに対応する付帯情報も作成する点が実施の形態１と異なる。施工データの付帯情報は、使用頻度推定部１１０２にて推定された、施工データに含まれる各種データの使用頻度を含む。また、後述の通り、付帯情報は、使用頻度「高」に対応するストレージサーバ１１に保存されるデータと、他のストレージサーバ１１に保存されるデータとを関連付ける情報を含むことが好ましい。

データ保存部１１０４は、施工データ及び当該施工データに対応する付帯情報もストレージサーバ１１に保存する点及び施工データに含まれる個人情報を機器IDと関連付けて個人情報ストレージ１２に保存する点が実施の形態１と異なる。なお、ストレージサーバ１１には個人情報は保存されない。

データ保存部１１０４は、施工データに含まれる各種データを、推定された使用頻度に応じたストレージサーバ１１に保存する。この際、同一の施工に関するデータであっても使用頻度に応じて異なるストレージサーバ１１に保存される。そのため、使用頻度「高」に対応するストレージサーバ１１に保存されるデータと、他のストレージサーバ１１に保存されるデータとを関連付ける情報を付帯情報が含むことが好ましい。

データ保存部１１０４は、ユーザID、住所などの施工データに含まれる個人情報を、施工データに含まれる機器IDと関連付けて個人情報ストレージ１２に保存する。個人情報ストレージ１２に保存されるデータの一例を図１９に示す。図１９に示すとおり、ユーザを個別に識別するユーザID及び機器３０の設置場所の住所を含む個人情報と、機器３０の機器IDとが関連付けられて保存されている。

実施の形態３に係るデータ利用サーバ２０についての、実施の形態１の場合と異なる点は、データ収集サーバ１０の場合と概ね同様であるため説明を省略する。また、データ保存の動作、データ流通の動作も、施工データを扱う点、個人情報が個人情報ストレージに保存される点以外は実施の形態１の場合と概ね同様であるため説明を省略する。

以上、実施の形態３に係るデータ流通システム１を説明した。実施の形態３によれば、機器データのみならず施工データも扱うことができる。また、機器IDと個人情報とを関連付けて個人情報ストレージ１２に保存し、ストレージサーバ１１には個人情報を保存しないことにより、個人情報を他の情報とは別に管理することを可能としつつ、ユーザと機器３０とを関連付けることができる。そのため、例えば、特定のユーザに関する機器データを提供するサービスを実現できる。また、個人情報ストレージ１２に保存された、個人情報及び関連付けられた機器IDを削除することにより、ストレージサーバ１１に機器データが残されつつも、残された機器データから個人を特定することが不可能となる。そのため、実施の形態３によれば、個人情報の保護を図りつつ、膨大なデータを好適に扱うことができる。

（実施の形態４）
実施の形態４に係るデータ流通システム１を説明する。実施の形態１において、流通データは、機器データと当該機器データに対応する付帯情報とを含むものとなっている。一方、データ利用サーバ２０は、例えば一定期間におけるON/OFF制御のデータ全てを要求するなど、膨大なデータ量を要求することが考えられるため、データ利用サーバ２０に送信すべき流通データは膨大となりうる。そのため、データ流通市場においては、送信対象となる機器データと付帯情報との組をまとめて取り扱うことが好ましい。実施の形態４は、そのような問題に対応した、実施の形態１の変形である。

実施の形態４における流通データは、図２０に示すように、１以上の機器データと付帯情報との組（以下、「データ群」という）と、データ群に関する情報である包括付帯情報とを含む。データ収集サーバ１０は、このような流通データをデータ利用サーバ２０に送信する。包括付帯情報は、例えば図２１に示すように、データ群のデータサイズ、データ群がどのような機器のデータを対象としているかを示す対象機器、データ群がどのような内容かを示すデータ内容、データ群がどの期間のデータを対象としているかを示す対象期間、データ群を送信するデータ送信者及びデータ群の販売価格を示す情報など、データ群に関する情報を含む。

図２２を参照しながら、データ収集サーバ１０の機能的構成のうち、実施の形態１の場合と異なる点を説明する。データ収集サーバ１０の制御部１１０は、実施の形態１の場合に加え、さらに、包括付帯情報作成部１１０７を備える。

包括付帯情報作成部１１０７は、データ取り出し部１１０６が取り出したデータ群全体に関する情報を包括付帯情報として作成する。例えば、包括付帯情報作成部１１０７は、取り出し条件決定部１１０５が決定した取り出し条件に基づいて、包括付帯情報が含むべき情報のうち、対象機器、データ内容、対象期間などの情報を作成する。包括付帯情報作成部１１０７は、本発明に係る包括付帯情報作成手段の一例である。

通信部１００は、制御部１１０の制御により、データ群と包括付帯情報とを含むデータを流通データとしてデータ利用サーバ２０に送信する。

データ利用サーバ２０の機能的構成は、実施の形態１の場合と同様であるため説明を省略する。また、データ保存の動作も実施の形態１の場合と同様であるため説明を省略する。また、データ流通の動作も、流通データがデータ群と包括付帯情報とを含む点以外は実施の形態１の場合と概ね同様であるため説明を省略する。

以上、実施の形態４に係るデータ流通システム１を説明した。実施の形態４によれば、データ群に対応する包括付帯情報を作成し、データ群と包括付帯情報とをまとめて流通データとして送信する。そのため、膨大なデータ量の取り扱いが容易となる。つまり、実施の形態４によれば、膨大なデータ量を好適に扱うことができる。

（実施の形態４の変形例）
実施の形態４では、データ収集サーバ１０は、流通データを送信するときに包括付帯情報を作成した。しかし、データ収集サーバ１０は、任意のタイミングで包括付帯情報作成部１１０７により包括付帯情報を作成し、データ保存部１１０４により使用頻度「高」に応じたストレージサーバ１１に保存してもよい。作成する包括付帯情報としては、例えば、データ利用サーバ２０にとって必要性の高いデータ群に関するものが考えられる。例えば、１ヶ月間の室温に関するデータ群はデータ利用サーバ２０にとって必要性が高いと考えられるので、当該データ群に対応する包括付帯情報を予め作成してストレージサーバ１１に保存してもよい。

実施の形態４は、上記の各実施の形態及び変形例と適切に組み合わせることもできる。例えば、実施の形態３と組み合わせることを考える。この場合、包括付帯情報は、データ群に個人情報が含まれているか否かを示す情報をさらに含んでもよい。また、この場合、個人情報が含まれているか否かで販売価格を異なるものとしてもよい。

（実施の形態５）
実施の形態５に係るデータ流通システム１を説明する。上記の実施の形態４の変形例にて、データ収集サーバ１０が予め包括付帯情報を作成することを説明した。実施の形態５に係るデータ流通システムは、当該実施の形態４の変形例をさらに変形したものであり、データ収集サーバ１０が予め作成された包括付帯情報を活用して流通データの販売目録を作成し、データ利用サーバ２０が当該販売目録に示された流通データを購入することを可能とする。

図２３を参照しながら、データ収集サーバ１０の機能的構成のうち、実施の形態４の場合と異なる点を説明する。データ収集サーバ１０は、実施の形態４の場合に加え、さらに、目録作成部１１０８を備える。

目録作成部１１０８は、ストレージサーバ１１に保存された包括付帯情報に基づいて、当該包括付帯情報と関連付けられたデータ群の販売目録を作成する。販売目録は、当該データ群を含む流通データの販売をデータ利用サーバ２０の運営者に広告するための販売目録となる。販売目録には、データの内容、対象期間、価格など、データ利用サーバ２０の運営者が流通データを購入すべきか否か判断できる程度の情報が含まれていればよい。販売目録の内容は、例えば、概ね図２１で示す包括付帯情報の例と同様の内容となる。目録作成部１１０８は、本発明に係る目録作成手段の一例である。

通信部１００は、制御部１１０の制御により、販売目録をデータ利用サーバ２０に送信する。

次に、データ利用サーバ２０の機能的構成のうち、実施の形態４の場合と異なる点を、図１１を参照しながら説明する。

通信部２００は、データ収集サーバ１０から、流通データの販売目録を受信する。データ要求部２１０１は、受信した販売目録にて示される内容から、流通データを購入するか否かを判定する。データ要求部２１０１は、流通データを購入すると判定したとき、当該流通データの要求を、通信部２００を介してデータ収集サーバ１０に要求する。流通データを購入するか否かの判定は、内容、対象期間、販売価格など、予め定められた条件に従うものでもよいし、データ収集サーバ１０の運営者による入力装置を介した入力により判定してもよい。

データ保存の動作は実施の形態４の場合と同様であるため説明を省略する。また、データ流通の動作も、データ収集サーバ１０が販売目録をデータ利用サーバ２０に送信し、販売目録を受信したデータ利用サーバ２０が流通データを購入するか否か判定する点以外は、実施の形態４の場合と概ね同様であるため説明を省略する。

以上、実施の形態５に係るデータ流通システム１を説明した。実施の形態５によれば、データ収集サーバ１０が流通データの販売目録を作成してデータ利用サーバ２０に送信するので、膨大な機器データの取引を円滑にすることができる。したがって、実施の形態５によれば、膨大な機器データを好適に扱える。

（実施の形態６）
図２４を参照しながら、実施の形態６に係るデータ流通システム１を説明する。上記の各実施の形態及び変形例はいずれも、機器データの正当性を担保することは考慮されていなかった。そのため、例えば、正当性のない、ねつ造された機器データが流通してしまうことが考えられる。したがって、データの正当性を担保することが必要となる。実施の形態６は、このような問題に対応した、実施の形態１の変形である。

データ収集サーバ１０は、実施の形態１の場合に加えてさらに、証明サーバ５０を備える。証明サーバ５０は、例えば、データ収集サーバ１０の運営者ともデータ利用サーバ２０の運営者とも無関係な第三者機関により運営されるサーバである。証明サーバ５０は、データ収集サーバ１０の依頼に基づいて、データ収集サーバが有する機器データの正当性を証明する証明書を発行する。証明書発行の具体的な動作については後述する。証明サーバ５０は、本発明に係る証明サーバの一例である。

図５を参照しながら、データ収集サーバ１０の機能的構成のうち、実施の形態１の場合と異なる点を説明する。

制御部１１０は、正当性を証明する対象とするデータ群を決定する。制御部１１０は、流通データを通信部１００により送信する際、証明書も流通データに含めて送信する。

通信部１００は、証明サーバ５０と通信する。特に、通信部１００は、証明サーバ５０に付帯情報、データ証明要求及び検査対象データを送信し、証明サーバ５０から検査対象データ要求及び証明書を受信する。

取り出し条件決定部１１０５は、証明サーバ５０から要求された検査対象データを取り出す条件を決定する。

データ保存部１１０４は、証明サーバ５０から受信した証明書を、対応する機器データ及び付帯情報と関連付けてストレージサーバ１１に保存する。

データ利用サーバ２０については、流通データに証明書が含まれる点以外は実施の形態１の場合と概ね同様であるため、説明を省略する。また、データ保存の動作、データ流通の動作についても実施の形態１の場合と概ね同様であるため説明を省略する。

次に、図２５を参照しながら、データ収集サーバ１０と証明サーバ５０によるデータ証明の動作の一例を説明する。

まず、データ収集サーバ１０は、制御部１１０により、正当性を証明する対象となる機器データを決定する（ステップＴ２０１）。この際、関連性のある複数の機器データをまとめて証明対象として決定することが好ましい。例えば、特定１ヶ月間におけるエアコンON/OFF制御のデータをまとめて証明対象とすることが考えられる。

次に、データ収集サーバ１０は、制御部１１０により、証明対象として決定された機器データに対応する付帯情報を証明サーバ５０に送信し、当該機器データに対する正当性の証明を証明サーバ５０に要求する（ステップＴ２０２）。

次に、付帯情報及び証明要求を受信した証明サーバ５０は、受信した付帯情報に基づいて、正当性証明のために検査対象とする機器データを検査対象データとして決定し、当該検査対象データをデータ収集サーバ１０に要求する（ステップＴ２０３）。ここで、理想的には付帯情報に対応する全ての機器データを検査対象とすることが好ましいが、この場合データ量が膨大となることが考えられ、現実的ではない場合がある。そのため、証明サーバ５０は、例えば、付帯情報に基づいて全データのうち数％程度を無作為に検査対象として決定し、当該検査対象のデータをデータ収集サーバ１０に要求することが考えられる。

検査対象データ要求を受信したデータ収集サーバ１０は、取り出し条件決定部１１０５により、検査対象データを取り出す条件を決定し、データ取り出し部１１０６により検査対象データである機器データをストレージサーバ１１から取り出し、通信部１００により検査対象データを証明サーバ５０に送信する（ステップＴ２０４）。

検査対象データを受信した証明サーバ５０は、検査対象データの正当性を検査し、正当性が確認できた場合には証明書をデータ収集サーバ１０に発行する（ステップＴ２０５）。正当性の判定は、例えば、検査対象となる値の相関関係、変化量などに基づいて行う。例えば室温に関する機器データが検査対象データとなっている場合、室温としては不自然な相関関係、変化量などを検知した場合には正当性がない、と判定する。なお、図２５には示していないが、正当性が確認できなかった場合、証明書は発行されない。

証明書を受信したデータ収集サーバ１０は、データ保存部１１０４により、証明書を対応する機器データ及び付帯情報と関連付けてストレージサーバ１１に保存する。

以上、実施の形態６に係るデータ流通システム１を説明した。実施の形態６によれば、機器データの正当性を証明することができるので、データ流通市場に流通する膨大な機器データを好適に扱うことができる。

（実施の形態６の変形例）
実施の形態６は、例えば実施の形態４あるいは５と適切に組み合わせることができる。この場合の、証明書を含む流通データの一例を図２６に示す。証明書は、１つのデータ群を証明範囲とした証明書である。包括付帯情報は、２つのデータ群及び対応する２つの証明書に関連付けられている。このように、証明書が複数の機器データを証明し、証明された複数のデータ群を１つの包括付帯情報に関連付けてもよい。これにより、証明された複数のデータ群をまとめて流通させることができる。また、この場合、包括付帯情報は、証明書の有無を示す情報を含んでもよい。

（その他の変形例）
上記の各実施の形態及び変形例では、機器データが加工されていないことを前提としている。一方、数値データの有効桁数、日時の表現の統一化などを理由に、機器データに軽微な加工をする必要が生じる場合がある。その場合、データを加工した旨、加工内容、加工した者の情報等の加工に関する追加情報を、加工された機器データに対応する付帯情報に追加することが考えられる。加工に関する情報を付帯情報に追加することにより、加工の際に問題が生じた場合に、どのような経緯で誰が加工したかを特定することが可能となる。つまり、データ加工のトレーサビリティを確保することができる。

上記の各実施の形態及び変形例では、機器データごとに価値が異なる可能性については考慮していない。しかし、例えば、一部のエアコンに搭載された熱画像センサにより得られる熱画像情報は、価値の高い情報となりうる。したがって、例えば、データ収集サーバ１０の意味特定部１１０１にて機器データの価値の高低も意味として特定し、価値の高低に応じてデータ群を分類し、同価値のデータ群を包括付帯情報にて関連付けることが考えられる。この際に、包括付帯情報が示す販売価格を、データ群に応じた個別の価格設定ではなく、価値に応じた価格設定にすることにより、販売価格の設定、金額計算処理等が容易となる。また、価値の高低に応じて異なるストレージサーバ１１に機器データを保存してもよい。

上記の各実施の形態及び変形例では、機器データに対して何も統計的な処理を施していないことを前提としている。一方、１週間毎の消費電力量、１ヶ月間の平均室温等、一定の期間に集約された機器データの需要も多々あると考えられる。データ利用サーバ２０が、集約された機器データのみ必要な場合に、当該期間中の全ての機器データを取り出して送信するのは効率的ではない。そのため、データ収集サーバ１０は、任意のタイミングで、一定の期間を対象として機器データを集約し、集約された機器データをストレージサーバ１１に保存してもよい。この際、集約された機器データに対応する付帯情報に、機器データが集約された旨、集約前のデータへのリンクなどを含むことが好ましい。また、集約されたデータを、他のデータの保存先とは異なる専用のストレージサーバ１１に保存してもよい。

また、集約されたデータは、データ容量がさほど大きくない。そのため、スマートフォン、タブレット端末など、記憶容量の小さい端末装置でも受信可能である。そのため、実施の形態５において、集約されたデータに関する販売目録を端末装置に送信し、当該端末装置が集約されたデータを要求し購入することも可能である。

上記の各実施の形態及び変形例において、一度ストレージサーバ１１に保存した機器データを他のストレージサーバ１１に移動してもよい。例えば、保存してから１ヶ月、半年等の一定期間が経過した機器データは使用頻度が低くなると考えられる。この場合、当該機器データを、より低い使用頻度に応じたストレージサーバ１１に移動することにより、より効率的に機器データを保存することができる。機器データを他のストレージサーバ１１に移動した場合、トレーサビリティの観点から、機器データを移動した旨の情報を付帯情報に追加することが好ましい。

その他、本発明の実施の形態として、上記の各実施の形態及び変形例を当業者の通常の知識の範囲内で適切に組み合わせたものを採用してもよい。例えば、実施の形態３と６とを組み合わせ、施工データの正当性を証明してもよい。

なお、図１２に示すハードウェア構成においては、データ収集サーバ１０が二次記憶装置８００４を備えている。しかし、これに限らず、二次記憶装置８００４をデータ収集サーバ１０の外部に設け、インタフェース８００３を介してデータ収集サーバ１０と二次記憶装置８００４とが接続される形態としてもよい。この形態においては、USBフラッシュドライブ、メモリカードなどのリムーバブルメディアも二次記憶装置８００４として使用可能である。

また、図１２に示すハードウェア構成に代えて、ASIC（Application Specific Integrated Circuit: 特定用途向け集積回路）、FPGA（Field Programmable Gate Array）などを用いた制御回路によりデータ収集サーバ１０を構成してもよい。また、図１２に示すハードウェア構成において、データ収集サーバ１０の機能の一部を、例えばインタフェース８００３に接続された制御回路により実現してもよい。

また、データ収集サーバ１０で用いられるプログラムは、CD-ROM（Compact Disc Read Only Memory）、DVD（Digital Versatile Disc）、USBフラッシュドライブ、メモリカード、HDD等のコンピュータ読み取り可能な記録媒体に格納して配布することが可能である。そして、かかるプログラムを特定の又は汎用のコンピュータにインストールすることによって、当該コンピュータをデータ収集サーバ１０として機能させることが可能である。

また、上述のプログラムをインターネット上の他のサーバが有する記憶装置に格納しておき、当該サーバから上述のプログラムがダウンロードされるようにしてもよい。

（関連技術の補足説明）
以下、上記の各実施の形態及び変形例に関連する技術について、図面を参照しながら補足説明をする。なお、各図中における丸で囲まれた数字は、以下の説明では括弧つきの数字にて示す。例えば、丸で囲まれた数字の１は、以下の説明では「（１）」と記載する。

図２７は、従来の情報銀行を活用したデータ流通システムを示した図である。情報銀行とは、ビッグデータとしての機器データの流通を仲介する機関である。以下では、メーカ、サービサ、情報銀行などの各運営者が運営するサーバを、適宜当該運営者の名称により表す。図２７に示すように、メーカからアップされるビックデータを一旦情報銀行５３を介してからサービサ５５に提供する形態では、この情報銀行５３が各データ提供事業者５１（メーカクラウド等）からアップされるデータのフォーマットをそろえるなどの加工が行われる。

特にクラウドを所有しない機器メーカ、メーカクラウドを所有するが流通システムを持たない機器メーカ、データ加工規模が大きいために専門IT部門が必要となる機器メーカなどは、情報銀行５３にデータ流通の業務を代行させる必要がある。情報銀行５３が代行するデータ流通の業務は、個人情報の管理、データ蓄積と集約、データカタログの作成などである。この場合、情報銀行５３がデータ流通を受け持つので、データフォーマットなどAPIをきっちり規定しなくても（必要な情報があるかどうかだけで）良い。

特に情報銀行５３がデータ流通を受け持つので、データフォーマットなどAPIをきっちり規定しなくても（必要な情報があるかどうかだけで）全体のシステムが成り立つ。そのため情報銀行５３は、個人情報の管理アプリ、データ加工アプリ、データ統合アプリなどのデータ処理アプリ５７を有し、これにより加工及び提供が行われる。

ただしこの場合は、情報銀行５３が仲介する形となるため、データ提供側のニーズとサービサ５５のニーズを調整する必要があり、また情報銀行５３自体のビジネスモデルによってデータ流通が限定されてしまう課題があった。

一方、本発明の実施の形態と関連する、後述のオープンシステム（データ提供事業者５１が直接サービサ５５にデータを流通させるシステム）では、より流通性が高いものとなるが、上記理由で提供側にシステムが構築できない場合は、情報銀行５３を活用する場合とオープンシステムとの併用が予想されるためデータフォームはオープンシステムに合わせる必要がある。またこのとき、個人情報に関し個人５６がデータの閲覧または削除を要求する場合があり、情報取得アプリ５６ａを介して情報銀行５３から自身のデータ取得を行う。

図２８は、従来の情報銀行５３を活用したデータ流通システムにおけるデータの流れを示す図である。各家庭５８がHEMSシステムのように宅内制御システム単位で構成されている場合、システム責任を持つシステムメーカサーバ５９の単位で各家庭５８のIoTデータが管理され、このIoTデータを情報銀行５３が吸い上げ、データ形式等を加工し、サービサ５５に提供する。この際、データはサービサ５５が使いやすいようにカタログ化（各意味を標準的な言語で記述し、誰でも使えるように一般化）し提供する。

機器からアップされるデータは、例えば家庭用機器（家電）であれば、各家庭５８に設置された単位となっており、また各機器に取り付けられた通信アダプタもしくは、機器に内蔵された通信手段により一旦メーカなどが管理しているシステムメーカサーバ５９にアップされるのが一般的である。また施工業者などのシステム事業者がビルシステム、ＨＥＭＳシステムなどとあわせシステム事業者のクラウドシステムにアップされる形態もある。この際、各機器のデータはアダプタ等のＩＤ番号もしくは機器ＩＤを有した個々の機器単位でアップされるため、ＲＡＣ、給湯機（ＨＷＤ: Hot Water Dispenser）、スマートメータ（スマメ）とあった場合は、それぞれの単位でシリアルにデータがクラウドに転送される形態となる。

ただしデータ更新頻度が高いものは頻繁に、低いものは低い頻度のデータファイルとしてアップされる。また家庭５８毎に設置施工され、例えばＨＥＭＳシステムなどでシステム化された場合は、機器からアップされるデータ以外に、個人ＩＤを含む個人情報、設置施工を含む管理情報などが別途入力され各家庭５８の機器が家庭５８及び個人５６と紐付けられた状態でメーカクラウドにアップされる場合がある。

図２９は、従来の複数のメーカが存在する場合の家庭内機器の情報転送を示す図である。一般の家庭５８では、家電機器が１つのメーカで一本化されているケースはあまり無く、複数のメーカの機器が設置されている。特に近年のスマート家電では家電機器自身がメーカクラウド５９（システムメーカサーバ５９）と連携することで機器の機能を提供するようになっているため、この場合各機器はメーカ毎に各メーカのクラウドシステム５９（システムメーカサーバ５９）に接続されるようになる。

このような場合でも、機器からのデータを一旦情報銀行５３のデータ加工サーバに集約し、各メーカ単位で仕様の異なるデータフォームをあわせたり、サービサ５５のサービスに必要な情報を取り出したりすることでデータ活用サービスが実現する。

図３０は、機器から出てくる情報を示す図である。機器からは機器毎の単位で、シリアルに情報が送出される。各家庭５８の機器（スマート家電）からアップされるデータは、例えば機器に取り付けられたアダプタを単位としてＩＤが付与されており、ＯＮ／ＯＦＦの制御情報なのか、状態を示す情報なのか、設定した情報なのかなどの意味分類と具体的なデータ内容からなる。アダプタのキャッシュメモリにも依存するが、家庭５８からはルータを介してデータがクラウドにアップされる事を考慮し、ある程度まとまったデータとして、定期的なポーリング単位あるいは操作毎にアップされるのが一般的である。

ここで例えば６１はルームエアコン（ＲＡＣ）からアップされるデータ、６２は給湯機（ＨＷＤ）からアップされるデータである。一方、ＨＥＭＳシステムなど宅内コントローラを介してクラウドに接続する形態であれば、宅内コントローラでデータが一旦集約されるため、コントローラとクラウドの間で取り決めたポーリングサイクルでデータがアップされる。例えば電力マネージメント関連では３０分単位でデータをまとめてアップするシステムが一般的である。

図３１はデータ提供事業者とサービサでの流通を示す図である。本発明に係る実施の形態では、メーカのクラウド等の各データ提供事業者５１がサービサ５５と直接データの受け渡しを行う事により、よりオープンなデータ流通システムを実現し、データ流通によるサービサの利用拡大等を行うことを目的とする。なお、個人情報管理アプリ６３は、認証機関が認定したものであり、情報取得アプリ５８は、サービスとからめてサービサが提供するものである。

本システムにおいては、データフォーム及びクラウド間でのデータの受け渡しのＡＰＩ６２をきちんと定義する事で、サービサ５５はどのデータ提供事業者５５からも同じフォームのＡＰＩ６２でデータ提供を受ける事ができる。この際データカタログ化のフォーム、データ群の構造、ファイル方式・暗号化方式などを標準化することで、各メーカ間のデータをメーカ毎に個別加工したり、メーカ間のフォーマット差異をそろえるための処理が不要となる。

このため、サービサ５５が所有するクラウド上のアプリ６４で、データの統合化及び自由なカタログ化が可能となってくる。また近年、個人情報保護の観点から一旦許諾した後でも、自身のデータ閲覧、削除などを行う必要があるが、データフォームのＡＰＩ６２を標準化することで、個人５６のアプリからも実現可能となる。個人５６も、情報取得アプリ５８により、必要な情報を入手する事が可能となる。

図３２は、データ提供事業者５１とサービサ５５での流通において異なるデータフォーマットで配信された場合を示す図である。ここで、メーカ等データ提供事業者５１からアップされるデータが標準化されていない場合、サービスを実現するためには、まずは各メーカのデータフォームをそろえ、必要な部分を抽出したり加工したりする、前処理用のクラウドシステム６５が必要となってくる。すなわちここで整形・加工したデータをあらためてサービスを行うクラウド上のアプリケーションで実現する事となる。

最終のサービスが例えばスマートフォン６６のアプリで表示動作するものであった場合、サービス提供クラウド５５（サービサ５５）経由で必要なデータを送り込むケース（ルートＡ）と、直接スマートフォン６６とやりとりするケース（ルートＢ）があり、いずれにしても、サービサ５５のクラウドシステム上にデータフォーマットの整形処理システムを構築するか、情報銀行５３などのプラットフォーマに加工を委託してサービスを受ける形態となるほか、データの整形及び加工は、提供するメーカ等のデータ提供事業者５１が変わる都度フォーマットをそろえる必要があるため、追加投資、個々のメーカとのデータ授受の契約交渉等が必要となってくる。そのため、このような追加投資、開発の部分、個別の契約準備等が、データ流通が広がらない要因となる。

図３３は、機器の情報による見守りサービスの例を示す図である。ホームエネルギーマネジメントシステム（ＨＥＭＳ）では、家にＨＥＭＳを施工する時点で各部屋にどの機器を設置したかが登録されるため、例えば機器における通信アダプタの施工設置をする施工業者と、システムを提供しているサービサが同一事業者の場合、施工情報から得られる家の間取りから、機器の状態を一覧表示する事で、機器のＯＮ／ＯＦＦを監視することによる簡単な見守りサービスが可能となる。

サービス事例として、タブレット画面で表示される家の家電状態を見える化する事例６７と、スマートフォンで宅外から見る事例６８を示す。

ここでは、例えば今まで機器のスイッチが入っていなかった子供部屋の機器がＯＮされたことを見て、子供の帰宅を判断したり、離れた家の高齢者が普段どおり生活しているかどうかを、機器の操作状態から見守る事が可能となる。現状このようなシステムは、スマート家電機器の提供と、設置施工業者が同一事業者の場合、同じクラウドでＩＤ間の紐付けが可能となるため、容易に実現できるものの、施工業者がまったく別の場合、両者間での契約に基づくＩＤの紐付けシステム構築等ができないと、実際のサービス提供は困難である。

図３４は、流通データが標準データフォーマットで配信された場合を示す図である。データフォーマットのＡＰＩ６２を標準化した場合、サービサ５５のクラウドシステムの入り口に標準的なデータ授受のＡＰＩ－ＩＦ（インタフェース）を構築しておくことで、どのメーカのデータが来ても、標準化フォームに準拠したものであれば、サービスシステムが構築できる構成をとることが可能となる。また比較的データ量の多いものは、一旦サービサクラウドで蓄積・処理した後スマホアプリ６６などのサービサアプリとつなぐ方法もあるが、データ量がスマートフォンで処理できるレベルのものであれば、直接スマホアプリ６６とメーカクラウドなどのデータ提供事業者５１がＩＦを取る事も可能である。これら、クラウド上やスマホ上の標準ＡＰＩ－ＩＦは、データフォーマット同様に汎用的なものとなるため、クラウド上及びスマホ上のＡＰＩ６２は標準的なミドルウエアとして、スマホ事業者及びクラウド事業者が標準で準備しておく形態も考えられる。

これらのデータ提供形態においては、（１）データを提供するだけのケース、（２）データはサービサ５５のアプリが都度必要分を取りに行く（閲覧する）ケース、（３）データ提供と提供後のデータの都度取得（閲覧する）の両方を行うケースがあり、スマホ等のメモリ制限がある場合は特にサービサ５５側でデータをかかえない方式が有効である。

このようにデータの流通市場を拡大するためには、これら標準的な対応による、サービスシステムの効率化が必要となるほか、データ提供事業者５１が直接サービサ５５とデータ授受を行うため、データ売買にかかわるビジネスモデルも構築しやすくなるメリットがある。

図３５は、メーカとサービサ間でのダイレクト情報転送時のデータの流れを示す図である。各機器が機器メーカ等のデータ提供事業者５１のクラウドにそれぞれつながっている場合、あるいは複数のシステムメーカが存在している場合でも、機器から出てくるIoTデータをWeb API６２（ＡＰＩ６２）で標準化する事で、クラウド間連携システム上で必要なデータを個別に流通させる事が可能になる。この際メーカデータあるいはサービサに対し情報銀行５３が証明書及びデータ活用のＩＦアプリを提供する事も可能になる。なお、標準化されたWeb API６２は、後述するデータ構造、付帯情報も含めたデータのやりとりのプロトコル、データカタログのラベリングの意味、階層構造になっている場合も階層構造の情報等も含めた形で規定することで、サービサ５５が持つ標準的なＩＦアプリで処理することができるようになる。逆にWeb API６２のフォーマットにあいまいな部分があるとサービサ５５のアプリのＩＦ部分が個別に作る必要がありサービサ５５毎にアプリのIF部分を個別に開発する必要がある。一方、例外的な記述ができなくなってサービス内容あるいは取得先のメーカを限定してしまう可能性がある。そのため、標準化されたWeb APIは定義を明確化するとともに、例外的な記述部分の定義を用意しておく事が必要となる。

図３６は、複数のメーカが存在する場合の、Web API６２による情報転送を示す図である。１つの家庭５８内に複数のメーカ機器が存在する場合も同様にWeb API６２で標準化されると、サービサ５５のアプリで各メーカ情報を取得しサービスが可能となる。特にメーカが異なる場合、メーカ毎にメーカクラウド５１が存在し、サービサ５５のIFアプリが個々のメーカに取りに行く事になるが、Web API６２の定義がメーカにより異なるとサービサ５５のアプリが誤解釈したり、動作しないケースがあるため、メーカ間の定義を一様にそろえておく事が必要となる。

図３７は、意味によるカテゴライズ化を示す図である。メーカクラウド等のデータ提供事業者５１内では、機器単位にアップされているIoTデータを、サービサ５５が活用しやすくするために意味単位のデータに変換するケースが想定される。そのため機器からアップされるデータ６９は意味の情報（制御、設定）とか、さらに詳しい（ON/OFF、温度、湯量、風向）といった意味情報をあわせてもち、機器単位と意味単位で変換できるようにストアしておくことが必要となる。設定に関するデータをまとめたカタログ化データの例をカタログ化データ７０に示す。

図３８は、別の情報とのリンクによる付加価値を示す図である。機器から上がってくるデータだけでなく、例えば施工業者のデータ７１とリンクさせることで、家庭５８の中にある機器が、家庭５８のどこにつけられたかどうか、いつ施工したかといった情報がわかるようになる。これにより、家庭５８の間取りに個々に配置された機器の動作状態を監視して見守りサービスを行ったり、施工期日と機器からのエラー情報をリンクさせて耐用年数の過ぎた機器を監視し保守サービスあるいは予防保全を行う事も可能になる。

この仕組みがあれば図３３に示す簡単な見守りサービスに関し、同一事業者にしばられる事がなくなり、機器提供メーカと施工事業者が別の事業者であってもデータのリンクを張ることで見守りなどといった新たなサービスが可能になる。

図３９は、別の情報とのリンクによる付加価値事例を示す図である。実際には施工業者自身が管理用のクラウドシステム７２（施工業者クラウド７２）を有する場合があり、この施工業者クラウド７２とメーカクラウド等のデータ提供事業者５１とを、同じ標準化されたWeb API６２で接続し、施工業者の施工ＩＤとメーカの機器ＩＤを紐づけることで、リンクシステムを形成することができる。特に施工については、１つの施工業者だけで家の施工が行われないケースが多く、複数の施工業者がからんでくる可能性が高いため、データ提供事業者５１と各施工業者クラウド７２とを標準的なWeb API６２で接続し、家庭５８単位となるリンク情報を有し、これをもってサービサ５５に提供する事が可能となる。例えば、図３８の場合と同様に、見守りサービスを提供する事が可能となる。

図４０は、データの深さによる階層化を示す図である。機器からアップされるデータ及び施工情報を含むデータについては、これらの情報をカタログ化する際に階層構造で記述することが有効になる。例えば階層構造７３に示すデータ構造のように制御情報にはON/OFF温度設定といった基本的な情報、細かな温度設定、風向、風力といった付随する情報、タイマー設定、省エネ設定などメーカ毎に仕様が異なってくる情報があり、これらを階層的に記述することで、各メーカ間で共有できるものあるいはユーザの使用上一般的なものと、メーカ毎に異なるものを分けておくことが可能となる。また施工情報についても同様で、施工日や完了日といった基本情報から、定期点検・保障期間、施工時の写真といったより詳しく施工業者毎に対応が異なるものを分けておくことも可能となる。

例えば本見守りの事例では、第一階層のみの情報で実現できるため、全情報を送らなくても、第一階層情報郡をサービサに転送しておけばよいことになる。

階層構造７３は、例えば以下のような手順で規定される。
一般的な言語の意味から想起される内容で、データの階層化をあらかじめ定義しておく。データのカタログ化において、まず汎用的な定義から規定。
○家電機器制御の場合のデータの深さ
機器のON/OFF
＞（機器の基本設定にかかわるもの）温度設定/風力/風向
＞（機器の付加機能に関するもの）省エネ/タイマー設定
○設置施工の場合の場合のデータの深さ
施工日時/完了未完了
＞同時に施工した機器/施工業者名/定期点検情報/機器保証期間/施工費用伝票
＞施工業者住所/電話番号/地図/リンク先URL/施工時写真/動画/マニュアル
といった階層構造７３が構成できる。

図４１は、クラウドサーバ上の階層化の構成例を示す図である。一般的なパブリッククラウドでは、データを格納しているサーバシステムにおいてURL（Uniform Resource Locator）をＩＤとしたデータ群を、オブジェクト構造で配置しているケースがある。

これらのデータを階層構造７３で記述した場合、基本的には使用頻度及び情報量（画像を含むなど）によってどの階層にあるべきかが規定されている。また、一般的なサーバシステムにおいても、アクセス毎コストが無償もしくは非常に小さいサーバシステムと、アクセス毎のコストが発生するもののデータ容量単位のコストが大きいサーバシステム、これらの中間的なもの等、複数の選択の中でデータファイリングすることが一般的なため、このデータ階層構造の定義に従い、それぞれのクラウドシステムのデータ格納先を設定することが行われる。

この際、各サーバシステムにデータが分かれてファイリングされているため、各階層間のデファイルータリンクを取っておくことが必要となり、この場合はURLがＩＤとなるため、各データファイルの付帯情報の中にリンク先のURLを記述しておくことが必要となる。

図４２は、サーバ特性を配慮したデータ階層化を示す図である。各メーカクラウド等のデータ提供事業者５１及びサービサ５５のクラウドには、IoTデータを格納しておくサーバシステムが必要となるが、一般的なパブリッククラウドでは、サーバシステムの特性により、アクセス毎コストが無償もしくは非常に小さいがデータ容量単位のコストが高いサーバシステムと、アクセス毎のコストが発生するもののデータ容量単位のコストが小さいサーバシステム、これらの中間的なもの等が存在する。

これは、サーバシステムのハードウェアが、アクセスコストが低い反面、容量を大きく取りにくい半導体メモリ７７からなるものと、容量が大きくファイルビット単価の安いハードディスク７８および７９を使ったものが存在することに起因する。

そのため大規模なビックデータを扱うIoTシステムにおいては、このデータファイルコストを最小限に設定する必要があり、データのアクセス頻度などで階層化された定義情報をベースに、システムが自動的にサーバのファイル先を設定するのがのぞましい。これについてはメーカなどのデータ提供事業者５１だけでなく、データ利用業者であるサービサ５５のクラウド内も同様になるため、各メーカなどのデータ提供事業者５１あるいは各サービサ５５が、個々に最適なサーバシステムの設計・構築作業を行わなくても良いように、あらかじめ標準化されたWeb API６２で階層構造を定義しておくことで標準的なクラウドアプリで対応できるようになる。サービサ５５は、当該クラウドアプリにより、データ配信元の更新頻度目安を参考に、自社クラウドにおけるデータの最適配置を行う。

したがってデータに階層構造を持たせる場合、更新頻度の高い（アクセス毎の課金が不要）な情報を最上位とし、更新頻度の低いもの（アクセス数が低いもの）をより下層に配置する。例えば、図４２に示すサーバＡには、分、時間、日単位で更新されるデータ及びデータ量が増減するデータが保存され、サーバＢには、月、年単位で更新されるデータが保存され、サーバＣには、更新されないデータあるいは更新頻度が極めて低いデータが保存される。この際、元々はサーバＡに保存されていたデータであっても古いデータについては、更新頻度が下がることが想定されるため、秒・分を示すデータを削除する加工をした上でサーバＢに移動してもよい。同様に、元々はサーバＢに保存されていたデータであっても古いデータについては、秒・分のみならず時を示すデータを削除する加工をした上でサーバＣに移動してもよい。

図４３は、サーバ特性とデータの深さによる階層化を示す図である。メーカなどのデータ提供事業者５１と施工業者７２のクラウドの両方のデータを持つ場合においても、機器からアップされるデータ群を、意味毎に再定義した上で標準的なWeb APIに対応できるよう整理する際、階層構造も標準フォームで定義することでどのサーバシステムにデータを振り分けるかが自動的に決まるので、都度開発を行う必要がなくなる。

新たなカタログを定義する場合でも、あらたなカタログに階層構造のどの階層構造かといった記述及び更新頻度に関する情報を記述しておくことで、以降自動的にデータの振り分けが可能となる。

IoTのビックデータシステムにおいては、膨大なデータをいかに効率的にストアリングするかが重要となっている。操作履歴や温度センサの履歴などの履歴情報といったものは年々積みあがってくるものであり、この膨大なデータのストレージと維持管理を最適なコストで効率運用することがもとめられ、このようにサーバ特性を考慮したデータの分類が重要となってくる。

例えば更新頻度の高いデータとしては、随時更新/データ増減情報（分、時間、日単位で更新されるデータあるいはデータ量が増減するもの）として、エネマネ情報、センサ情報、操作履歴情報、生活行動履歴、コールセンターオペレーションなどがある。

また更新頻度が中程度のデータ（月、年単位で更新されるデータ）として、休日/出勤カレンダー、通勤経路、習い事/ジム契約、クレジット契約/ネット契約、加工された古い情報、などがある。

また更新頻度の少ない情報（１タイムのデータ）として、施工内容、施工業者の詳細（住所/業務内容）、施工画像、家の住所、購入製品番号、などがある。

これらをカタログデータ化する際にカタログ分類内容に合わせて更新頻度の目安としておおまかなくくりを定義しておくことで、どのストレージ階層にファイリングしておくべきかが自動的に決定できる。

図４４は、更新頻度情報の例外活用事例を示す図である。これはお風呂屋の事例である。お風呂屋チェーンを管理するサービサクラウドでも、階層構造に応じたデータ管理が行われる。一般的な家庭においては、お風呂設定を頻繁に変更することはなく、湯量の設定についても同様である。しかしながらお風呂屋といった浴場事業においては個人の一般家庭におけるお風呂管理のケースと異なり、日々の状況により個別に設定を変更する必要があり、湯量などの制御も頻繁になってくる。そのため湯量に関する標準APIに記述が第二階層であっても、更新頻度大として例外記述を行うことにより、お風呂屋チェーンを管理するサービスシステムにおいて湯量の全体管理がデータ保管コストの適正化が可能となる。

そのためデータ提供事業者（お風呂事業者）からアップするデータフォーマット８０として、更新頻度の情報８０ａを追加し、サービサ５５はこの頻度情報を元に自身のクラウドシステムにおけるデータストレージに最適な振り分けを自動で行う。

この場合、事業者クラウド５１の元データの更新頻度に応じて、最適なサーバ配置が異なるため、データ提供業者５１は、本データ更新頻度の目安をデータに付けて配信する。事業者により、標準で定義されたデータカタログの階層構造から変更が必要な場合、更新頻度情報を新たに記述する。この場合、更新頻度情報が優先される。

これによりカタログ化された文言での意味定義から逸脱する場合においても、本内容を参照することで例外的なデータの使い方を担保する事が可能となる。この時、後述する付帯情報及び包括付帯情報において、例外的なデータの使い方をしているかどうかのフラグを用意し、このフラグを確認することで、フラグが立っている場合は更新頻度情報を確認しストレージサーバの階層を判断することも可能となる。

図４５は、データ階層におけるリンクを示す図である。IoTデータにおいては１つの独立した情報が第二階層７５だけ、もしくは第三階層７６だけといった場合も存在する。例えばあるメーカの製品に対し、今後対応可能な追加施工業者の情報などを記述しておく場合、施工業者の住所、連絡先、地図といった第三階層だけの情報をもっておく場合、アクセス課金がある下の階層のサーバシステムに保管しているものの、頻繁にアクセスする第一階層７４にも下の階層にどのような情報があるかを記述しておくことがのぞましい。

要は頻繁にアクセスするデータは上位階層にあるため、下位の階層にしか実データが無い場合でも上位階層には、リンク先の下位階層にあるデータの情報を記載しておく。

第一階層７４は、例えば常時アクセスされる部分であり、どのような情報が階層構造下にあるかの配置情報だけは有し、必要である事が確認された後、下の階層からデータを取り出すようにすることで、常にサーバアクセスコストを最適化することができる。

また、この時、後述する付帯情報や包括付帯情報において、配置情報のみを有するデータであるかどうかのフラグを用意し、このフラグを確認することで、フラグが立っている場合で実際のIoTデータが必要なケースにおいては、下位のデータを改めて取得することも可能となり、これにより最上位階層がアクセス毎にかかる費用が小さいことを利用した全体コストの削減が可能となる。

図４６はデータ格納事例-パターン一覧を示す図である。事例８１は、複数の料金プランが存在するパブリッククラウドの事例である。

このように一般的なクラウドでは、高アクセス用と、低アクセス用と、その中間的なものとが用意されており、低アクセス用は一般的にストレージビット単価の安いものとなっている。

図４７は、更新頻度情報の記載を示す図である。データの階層化に際し、まずはカタログの各項目内容に基づき階層構造のどに位置にあるべきかを定義し、サーバシステムの選択も含めて自動化できることがのぞましい。

これはサービサが新たなサービスを検討するに際し、例えば更新頻度あるいはアクセス頻度が高い第一階層の情報である事をカタログ内容（文言定義）でもってサービサが認識イメージし、新たなサービスを構想・設計することが容易になるからである。

なお、個々に更新頻度を数値で記載する方法もあるが、すべてのカタログ列に記載された頻度の数値を個々に確認しながらサービスを構想することが難しいからである。

例えば、フレッシュで頻繁に更新されるデータの事例８２としては、エネマネ情報、センサ情報、操作履歴情報、生活行動履歴、コールセンターオペレーションなどがあり、更新が頻繁にないと思われるデータ事例８３としては、休日/出勤カレンダー、通勤経路、習い事/ジム契約、クレジット契約/ネット契約、加工された古い情報などがある。

これらに対し、サービサが必要な情報が元はフレッシュデータとしてであっても日単位のデータ更新が不要な例外的な事例８４として、消費者購買行動などの比較的大きな流れ、お風呂の湯温設定の推移、エネルギーの月額課金情報などのケースがあり、また一般的に頻繁に更新が無いと思われていても日単位で更新が必要な例外的な事例８５として、派遣会社での時間帯勤務詳細、派遣会社社員の通勤経路、クレジットのクーポン等日々の情報、ネット映像配信の支払い情報などの例外的事例がある。

このようにメーカあるいはシステム事業者からアップされるIoTデータには、標準APIで規定された階層構造から逸脱する例外的なものも存在する。これはデータを作り出している事業者毎（生成事業者）に、必要な更新頻度は変わってくるため、標準的なカタログフォーマットを定義しても、事業者による例外が存在するためである。

すなわち、データを作り出している事業者毎（生成事業者）に、必要な更新頻度は変わってくる。結果、標準的なカタログフォーマットを定義しても、事業者による例外が存在する。

この規定はデータ生成事業者（メーカ等）の事業形態に依存し、データ生成頻度及び精度はデータ生成事業者の判断で決定されるので、この更新頻度情報はデータ生成事業者が決定し記載され、この際に更新頻度の情報を付加することで、例外含めてカバーできる。

例えば、企業の休日出勤カレンダーの更新は一般的に年１回であるが、派遣会社の場合はデイリーで変更されるといった場合などである。一方、サービサ５５とデータ生成事業者５１間の話し合い（契約）でも変更される場合があり、この場合はデータ提供事業者がサービサのニーズを汲んでデータを再加工するケースなどがある。

図４８は機器からのデータファイル形式を示す図である。機器からアップされる情報には、センサで検知した情報、操作した情報そのもの、もしくは平均値処理、まるめ処理などを施した実情報であるＪＳＯＮファイル８７がある。

一般的には機器からのデータは機器に搭載された通信アダプタあるいは通信回路が、当該通信回路が有するキャッシュメモリに蓄えられた分を当該機器単位にまとめて出力する。したがって、機器のデータは、通信アダプタ等から機器単位で配信される。なお、機器のデータは、例えば、定期的に配信され、あるいはユーザが機器を操作したときに配信される。

なおこれ以外に情報の意味、ＩＤ、関連する意味情報、リンク先のＩＤなどを記述するＪＳＯＮスキーマファイル８６があり、ファイル付帯情報として、同時に配信する。

図４９はカタログ化データファイル形式を示す図である。次にカタログ化したデータファイルの形式を記載する。メーカ等のデータ提供事業者５１もしくは情報銀行５３からデータを活用するサービサ５５のクラウドへは、サービスに必要な情報をひとまとめにした形態で送付、もしくはこれらをいくつかのカタログ単位でまとめた複数の形態で送付する場合がある。

この場合でもデータファイルの先頭には、付帯情報全般が記述された管理情報ファイルとしてＪＳＯＮスキーマファイル８６が配置される。ＪＳＯＮスキーマファイル８６には、データ授受に必要な、データサイズ、データ受信送信日時、ファイル形式、データ構造（階層等）、データの混在情報、暗号化情報、データ加工者、データ加工内容、データ加工履歴などが記述される。ＪＳＯＮスキーマファイル８６は、サービサ５５に送付される。

これによりひきまとめた情報の先頭に付帯情報を設ける事でサービサ５５は入手するデータの内容を把握し、サービサ５５のサーバの情報入手のためのシステム選択及び入手妥当性確認を行う事ができる。

またサービサ５５のサービスアプリ６４において、この標準化された付帯情報の内容を自動確認することで、サービサ５５におけるデータの複数のストレージ階層へのファイリング、実際のサービスを行うサービスアプリ６４への自動展開などを行うとともに、意図したデータと異なる場合にエラー情報を自動的にデータ提供事業者５１に返送することも可能となる。

特にこのような多くのデータ提供事業者から複数の情報配信を受けてサービスを行う場合は、個々の入手データを自動的に管理・判断する事が不可欠となるため、このようなデータ内容を記述した付帯情報の定義をデータ提供者間で合わせ、提供側と利用側でのデータ授受の自動化ができるようにしておく必要がある。

図５０はＪＳＯＮスキーマによるフォーマット情報付加例を示す図である。ＪＳＯＮスキーマの情報記述例を記載する。現在データ流通で使われているＪＳＯＮ情報は、そのデータの意味を説明するための付帯情報としてＪＳＯＮスキーマにて記述される事がよく使われており、IoTデータの付帯情報の記述においてもこのスキーマファイルで記述する。意味とデータとのマッピング一覧をＪＳＯＮスキーマとして整備することで、ＪＳＯＮスキーマを入手した会社ならどこでもデータの意味を理解できるようになる。もちろん、CSVあるいはXMLでのデータ記述でも付帯情報を独立して持たせることで同様なシステムが構築できる。

図５１は、データファイルのＩＤによるリンクを示す図である。データファイルはサーバシステムのＩＤ例えばURLで記述されたもので指定されている。実際に機器の場合は、アダプタに書き込まれている機器ＩＤが当該家電機器の情報ＩＤとなっており、製品にアダプタが内蔵されている場合は、製品番号あるいは製造番号がＩＤになっている場合もある。

このような機器データ９０のＩＤはそのままサーバシステムのＩＤとはならないため、その外にサーバＩＤをかぶせた形態となる。システム事業者のシステムデータ８９のIoTデータは、各機器をシステムアップして構成されているため、各機器ＩＤの上位に、いくつかの機器を束ねたシステムＩＤを有するほか、施工業者の場合は施工ＩＤの下に施工情報やどの機器を施工したかの機器ＩＤが記載されている。これらは家に設置されたシステム単位であったり、同一業者の施工情報であったりする。なおこれらシステム情報あるいは施工情報もまた、クラウド内ではサーバＩＤがつけられた状態で管理される。

ここで個人情報については、別途個人情報ファイル９２を管理するサーバシステムで保存されるが、ここでは各サーバＩＤ間のＩＤ管理ファイル９１におけるリンクテーブルを持つことによって、各機器、システム、施工及び個人情報とのリンクが行われる。またこれらのＩＤ群は例えば後述するＪＳＯＮスキーマなどで記述される。

また、クラウドを運用しているシステムの単位でリンク関係が張られる。特にシステムの施工時に機器及びシステム個人の情報リンクが張られ、システム（メーカ）クラウドでＩＤ管理される。

このように構成することで、個人情報９２を別に分けて管理し、またこれら個人情報９２に関連した機器データにおいて当該個人とのリンク関係をＩＤ管理ファイル９１にて削除することが可能となる。つまり、個人情報９２の一元管理が可能となり、削除や追加が容易となる。

ここで、図５２を参照しながら、実際の個人情報管理例について示す。ユーザ登録情報、施工情報などの個人情報及び関連する情報については、同じサーバシステム内であっても別にストアされる部分を用意し、そこで管理するのが一般的である。この際独立した個人情報サーバ９３においては、機器ＩＤと個人ＩＤ、施工ＩＤとのリンク情報が管理されるリンク情報テーブル９１が構成される。例えば個人が自分の情報を閲覧したい場合では、メインのデータ収集サーバを介して個人情報サーバにアクセスし、このリンク情報を取得することでデータ提供事業者５１あるいは情報銀行５３のデータ収集サーバの情報を取り出し閲覧する。さらに個人情報を削除したい場合は、この個人に関わるリンク情報を削除することで個人情報を削除することができる。この時複数のサービサからのサービスを同時に受けている場合において、他のサービスが同じ機器あるいは設備からのデータを利用している場合は、データ削除要求時に、他のサービスの機能が停止もしくは制限される旨の通知を行い、承諾を受けたのちに前記リンク情報テーブルのユーザ登録ＩＤから、前記情報テーブルにおけるリンクを解除することで、個人を特定できなくする。またサービサのＩＤも併記しサービサ毎に個人ＩＤと機器ＩＤのリンクが識別できるようにすることで、機器が他のサービスにも使用されておらず他のサービスへの影響が無い場合は、当該削除要求があったサービスでの個人情報リンクを削除し、機器が他のサービスにも使用されている場合は、他のサービスの機能が停止もしくは制限される旨の通知を行い、承諾を受けたのちに前記リンク情報テーブルのユーザ登録ＩＤから、前記情報テーブルにおけるリンクを解除することで、個人を特定できなくすることができる。

図５３は、付帯情報の結合を示す図である。次に複数のＪＳＯＮスキーマを合わせて送付する場合、特に各家庭５８毎にコントローラ５８ａを有するHEMSシステムなどでは、コントローラ５８ａが家庭５８の各データを統合しＪＳＯＮスキーマをつけて送付するケースが考えられる。ここから同じ意味単位（例えばON/OFFの情報のみ）に加工してデータを配信するケースでは、元のＪＳＯＮスキーマ８６－１、ＪＳＯＮスキーマ８６－２から必要部分だけを取り出してＪＳＯＮスキーマ８６－３、ＪＳＯＮスキーマ８６－４を作成し、さらにこの先頭に新たなＪＳＯＮスキーマ（３）からなる包括付帯情報９４（ＪＳＯＮスキーマ９４）を構成し、ＪＳＯＮスキーマ９４の中に加工内容、加工履歴、加工事業者などを規定することができる。

このようにできるだけ元のスキーマ情報を残した上で、加工した情報のみを別に追加することで、データのトレーサビリティを確保することも可能になる。

図５４は、機器単位のデータを流通させる場合における、機器データ配信時のフォーマット変換を示す図である。例えば、家庭５８からアップされる（１）の機器のIoTデータ８７－４を加工し、カタログ化してサービサに提供する際、上記の標準化Web APIに沿った形でデータファイリングされるが、家庭５８からアップされるデータに加え、他の事業者がIoTデータを管理・加工している（２）の機器からのデータカタログを購入し、この（１）と（２）をあわせた統合データカタログとしてサービサに提供するケースがある。たとえばこの他の事業者がマンション９５の場合を図に示すが（必ずしもマンションでなくてよい）、データカタログ８７－５の詳細部分の仕様及び定義が異なったり（例えば、温度データに関する仕様について、家庭５８では温度が０．５度単位、マンション９５では温度が１度単位で表現されている場合）する場合がある他、家庭５８ではIoTデータの形式がＪＳＯＮ形式であったがマンション９５ではIoTデータの形式がXML形式であるなどファイル形式が異なっている場合、データの更新頻度がある提供事業者は非常に時間刻みが細かく、他の提供事業者は時間刻みがあらいケースなどである。

これらの整合を取るためにメーカなどのデータ提供事業者５１もしくは情報銀行５３においてフォーマット変換９６を行う場合がある。この場合フォーマット変換９６の後のＪＳＯＮスキーマ８６－７に旧フォーマット８６－６の情報に加え、変換した際の情報（日時・内容・変更者）を記述し、データ８７－６のトレーサビリティを持たせることが必要となる。これは、何らかのデータ品質にかかわる問題が発生した場合に、過去のデータ提供元にさかのぼる必要がある他、後述する情報銀行でのデータ証明書発行時にも責任分解点を明確化するためである。

ここで機器単位のデータをサービサに返信する場合は、元データ８７－４及び８７－６から提供に必要なデータのみを抽出したデータ８７－７及び８７－８を配信する際に、８６－８及び８６－９をそれぞれに付帯させて配信する。例えば、制御に関するデータのみを機器単位で抽出して配信する。この時付帯情報８６－８及び８６－９は元の付帯情報８６－５及び８６－７をそのままもしくは必要部分を抜粋したものであり、また８６－９にはフォーマット変換した情報８６－７からトレーサビリティ確保に必要な情報も含めることで、データ流通におけるデータ品質が担保される。

図５５は、意味単位のデータを流通させる場合における、カタログデータ配信時のフォーマット変換を示す図である。機器単位の情報提供ではなく、意味単位にカタログ化した情報提供を行う場合においても、前述のトレーサビリティ担保のため、フォーマット変換履歴を残してそのデータを合わせてサービサに送付する。この際元の付帯情報をそのまま後ろに添付した形で送付すれば、加工履歴前後の状況をサービサが確認することができる。

例えば制御に関するデータのみをまとめカタログ化するケースでは、元データ８７－４及び８７－６から制御に関するデータのみをまとめたカタログデータ８７－７を生成し、この際、元の付帯情報８６－５及び８６－７を元に必要な部分を抜粋もしくはそのままとした付帯情報８６－８及び８６－９を用意し、それらをひきまとめた包括付帯情報９４－１を生成することで、配信する制御情報に関する情報の内容及び履歴の情報と合わせサービサに提供することができる。包括付帯情報９４－１は、まとめたデータに対する新たな付帯情報と、各機器に対応する付帯情報８６－８及び８６－９の存在を示す情報とを含む。

図５６は、データ証明書の発行を示す図である。データの信憑性を担保するためデータ形式及び内容での矛盾やぬけ、個人情報・時間情報やトレーサビリティを含めた確認を、情報銀行５３にて監査し、情報銀行５３から証明書９６の発行を受けることが考えられる。

図５６ではサービサへのデータ提供が情報銀行５３経由ではないため、例えばＪＳＯＮスキーマ情報８６－３、ＪＳＯＮスキーマ情報８６－４及びＪＳＯＮスキーマ情報９４だけをまず情報銀行５３に送付し、データ本体は情報銀行５３がメーカなどのデータ提供事業者５１に送付した閲覧アプリ９８を使って、データ提供事業者５１のクラウドを閲覧する形で確認が取られる。データ閲覧後問題ないことがわかれば、データ証明書９６と暗号キー９９ａを発行する。

メーカクラウド５１では情報銀行５３から提供された暗号化アプリ９９により、確認されたIoTデータ８７－３及び付帯情報８６－３、付帯情報８６－４及び付帯情報９４をその状態（情報銀行５３による確認後は一切修正せずに）で暗号キー９９ａにより暗号化する。

このようにして暗号化したデータとデータ証明書９６と暗号キー９９ａをサービサに提供することでIoTデータの送付が行われる。

上記暗号化までのアーキテクチャは、まず情報銀行はIoTデータ提供事業者に情報確認アプリとIoT情報暗号化アプリを提供し、情報銀行は送付された付帯情報もしくは包括付帯情報に基づきIoT情報確認アプリ経由でIoT情報を確認した結果に基づき、暗号キーをIoTデータ提供事業者に送付する、ということである。

このようにすることで、データ提供事業者はサービサへのIoTデータを情報銀行が許諾した暗号化データとして送付することを可能となる。

図５７は、証明書９６を含む流通データの生成（データ提供事業者５１⇒サービサ５５）を示す図である。情報銀行５３でデータ証明書９６を発行されたIoTデータをサービサ５５に送る際は、まず統合化されたカタログデータ（イ）のうち、データ内容詳細を記述したＪＳＯＮファイル８６－３及びＪＳＯＮファイル８６－４と、実データである４つのIoTデータをまとめて暗号化する。ここで流通用の包括付帯情報であるＪＳＯＮファイル９４については暗号化の対象外とする。

このＪＳＯＮファイル９４は、これらデータの全体概要を記載したＪＳＯＮスキーマであり、証明書９６をもらって暗号化をかけた時点で、流通用の包括付帯情報９４は、暗号化をかけて証明書の発行を受けた旨の情報を追記しＪＳＯＮファイル９４－２として、流通データ（ロ）の先頭に証明書９６ととともに配置される。ＪＳＯＮファイル９４－２は、元の流通用の包括付帯情報９４に加え、証明書及び暗号化データを含む包括付帯情報である。

このようにすることで証明書９６発行後のデータは一切変更することなく（証明済みのデータに変更を加えることなく）、必要な追加情報を記載しサービサ５５に送付できる。

そのためメーカ等データ提供事業者５１からサービサ５５のクラウドへのデータ配信は、まず流通用概要情報と証明書９６、次に暗号化されたIoTデータ５００、最後に暗号キー９９ａの順で送付される。

図５８は、証明書９６を含む流通データの生成（情報銀行５３⇒サービサ）を示しており、情報銀行５３でデータ証明書９６を発行されたIoTデータをサービサに送る方法として、直接情報銀行５３経由でサービサに情報を送付する方法もある。

この場合は、メーカ等のデータ提供事業者５１のクラウドからＪＳＯＮスキーマ８６－３及びＪＳＯＮスキーマ８６－４で構成されたデータの内容と、流通用の包括付帯情報９４を合わせて、情報銀行５３に送付する。情報銀行５３では図２７の処理と同様の手段で、まず統合化されたカタログデータ（イ）のうち、データ内容詳細を記述したＪＳＯＮスキーマ８６－３及びＪＳＯＮスキーマ８６－４と、実データである４つのIoTデータをまとめて暗号化する。

ここで流通用の包括付帯情報である包括付帯情報９４については暗号化の範囲外とし、外だしする。この包括付帯情報９４は、これらデータの全体概要を記載したＪＳＯＮスキーマであり、証明書を受けて暗号化を行った時点で、流通用の包括付帯情報９４は、証明書を受けて暗号化を行った旨の情報を追記し包括付帯情報９４－２として、流通データ（ロ）の先頭に証明書ととともに配置される。

この場合、情報銀行５３からサービサのクラウドへのデータ配信は、まず流通用の包括付帯情報９４－２と証明書９６、次に暗号化されたIoTデータ５００、最後に暗号キー９９ａの順で送付される。このシステムの場合、メーカ等データ提供事業者５１のクラウドから情報銀行５３へのデータ送付の際、ネット経由でのデータ安全性を担保するため図５７と同じしくみで暗号化したものを情報銀行５３に送付することも考えられる。

図５９は、複数の証明書を含む場合の配信データを示す図である。複数の元データを合わせてサービサ５５のクラウドに送付する場合として、例えば家の情報をまとめているメーカ等のデータ提供事業者５１がクラウド上にIoTシステムを構築し、マンション９７の事業者クラウド５０７のデータを購入したうえで、家庭５８とマンション９５のデータを統合させる場合について記述している。

この場合、マンション９５の事業者のデータも情報銀行からの証明書５０４を取っている場合、一旦証明書５０４をとった情報はそのまま保持し、これを合わせこんだ全体で新たな流通用の包括付帯情報であるＪＳＯＮスキーマ５０６を配置し、これを先頭にもった上で流通させる。

この際、家庭５８のデータ５０１に含まれる証明書Ａ、付帯情報（１）－１、付帯情報（２）－１及び包括付帯情報（３）、マンションのデータ５０２に含まれる証明書５０４、付帯情報（３）－１、付帯情報（４）－１及び包括付帯情報５０５をひきまとめた１つのデータとして配信するが、これら全体をひきまとめた全体情報を包括付帯情報５０６に記載することで、２つのデータを統合する際の統合での新たな加工内容履歴、加工事業者、新たな証明書の有無等を記述し、統合データがどのようなものかを確認することができるようになる。

このようにすることで、これらを合わせこんだデータである情報包括付帯情報５０６を見た上で、それぞれのデータ元である証明済みの情報を流通させることができるほか、複数のデータ群をマージした場合も、これらのマージ処理、加工、等に関するデータトレーサビリティが記載できるため、データ品質に問題が発生した場合のトレーサビリティの確保や、流通経路の把握等も行う事ができる。

図６０は、統合後のデータ加工があり、また複数の証明書を含む場合の配信データを示す図である。２つのデータ提供事業者からの情報をあわせて、新たな加工データ（特徴を抽出してグラフ化したものや、地域、天気、ユーザの属性、などで抽出し特定セグメントで情報をぬきだしたもの、さらにこれらを見やすいように並び替え（地域の北から南、年齢順など）たもの、また同じ時間帯における同じ操作の履歴を抽出したもの、などの加工データを有する場合は以下のようになる。

元のデータ５０１およびデータ５０２を元に加工した加工情報５０８とともに加工情報全体を示すＪＳＯＮスキーマであるＪＳＯＮスキーマ５０９を準備し、そこに加工情報５０８の内容を記述するとともに、新たな証明書５１０を情報銀行５３から受信し、加工情報自体の信頼性を担保する。その上ですべてのデータ５１２における流通用の包括付帯情報５１１を設け、ここに加工情報５０８、付帯情報５０９、加工データ証明書５１０、元データ５０１及び元データ５０２の概要を記載する。なお、元データをそのまま取り出した場合もしくは、元データのある部分を取り出しただけの場合、新たな証明書５１０は省略可能である。また、加工データは、同じ時間帯かつ同じ操作のデータを抽出して得られたデータ、同じ地域のＩＤを持つデータを抽出して得られたデータ、元データをグラフ化して得られたデータなどである。

このひきまとめた情報全体の暗号化は、暗号化範囲５１３を対象とし、ひきまとめたデータ全体の証明書５１０と包括付帯情報５１１を除く部分を再度暗号化して配信する。

また、この場合３つの証明書を流通データの暗号化外として別送することも可能であり元のデータに加工等がなければ暗号化された状態の元データ５０１と元データ５０２はそのまま暗号化した上で、加工データ５０８と加工データ５０８の付帯情報５０９を新たに暗号化し、加工データ証明書５１０と全体包括付帯情報５１１をつけて配信する方法もある。

この場合、元のデータ５０１及び５０２の暗号化を解くためのキー情報も配信する必要があり、この５０１及び５０２の暗号キーを加工データの付帯情報５０９内に記述してこれ自体を加工データ５０９とあわせて再暗号化して暗号強度を強化する方法もある。

図６１の階層化データの証明書と付帯情報を示す図を参照しながら、階層化されたIoTデータに対する証明書の発行と付帯情報につき説明する。

図６１においては、関連するデータをまとめて証明するため、本図のように複数の階層にまたがって証明書がカバーされる。

この際、証明書９６自体をあらかじめ付帯情報５１４、付帯情報５１５及び付帯情報５１６を有するデータのすべてもしくは、個々別々、もしくはいくつかの組み合わせのすべてで証明書が有効になるよう、データ内容のチェック・監査を行う。このように組み合わせであっても証明書自体を有効化することによって、上位のみ、中位のみ、下位のみ、もしくは複数の組み合わせ、だけを送付する場合も証明書９６で対応できるようにしておく。

この際分割の組み合わせに応じた複数の暗号キーの提供を情報銀行から受け、サービサとの商談内容に応じたファイル群の組み合わせで対応するキーを提供する。

証明書９６の発行は、情報銀行によるチェックの工程を踏んで行われるため、サービサの要求により階層別の送付が必要になった場合に、再度証明書発行を行うための手続きが不要となるため、データ流通市場におけるサービサとの間で迅速な流通決済の処理が可能となる。

また、包括付帯情報５１７にある概要付帯情報は、証明書の範囲外とし、サービサの要求で送付するデータ群を変更する場合、流通及び販売に必要な付帯情報として、データのカタログ概要、ちらし情報、更新日時/頻度、データ規模、データ階層あるいは構造、証明書の有無、個人情報の有無、販売額、販売元、連絡先などを記載変更できるものとする。例えばデータ提供事業者の住所、電話番号あるいは販売価格が変わった場合などでも個々のデータ証明書を取り直す必要はなくなる。

これによりIoTデータそのものではなく、データ流通販売に必要な情報を証明書の範囲外の情報を、データ証明発行以降も必要に応じて追記もしくは変更でき、データ流通市場における迅速な流通決済処理及びシステムコスト削減ができるようになる。

図６２は、階層集約後の証明書と付帯情報を示す図である。データ自体が古くなりデータの鮮度が落ちてきた場合（例えば１０年前の情報など、めったに使用されなくなったデータ）、データサーバでは最下層のサーバシステムに落とし込むことで、データ維持コストを削減する方法がある。

この場合でも証明書９６でカバーされたデータ群をまとめて最下層に配置することになるが、この階層変更に関し、上述した概要付帯情報に変更履歴を記載することでも対応できるものとする。

このようにすることで、過去のデータの階層を変更する際に新たな証明書を取る必要がなくなり、膨大なデータを管理しているメーカクラウド及びサービサクラウドでの維持コスト低減を図ることが可能となる。

このとき、包括付帯情報５１８に階層変更があった旨を記載する事によって、当初証明書９６が発行された際と異なる階層に付帯情報を含む情報が変更されても、証明書９６の証明内容がそのまま担保されるものとする。

このようにすることで、長期間の保存での階層変更あるいはサービサにニーズの変化に伴い階層レイヤを変更した際でも、新たな証明書を取りなおすことが必要なくなり、全体のデータ管理システムの維持コスト削減が可能になる。

図６３は、データ群の分類を示す図である。データの分類には、アクセス頻度あるいは使用頻度による階層化だけではなく、サービサへ配信するデータ群として大きなくくりで分割しておく必要がある場合がある。

特に高付加価値データとして提供コストを他の一般データと分けておきたい場合に、個人情報を含みその取り扱いにおいて特別な扱いが必要なものなどである。

このような大きな分割は、サービサがデータ流通市場から購入する際に必要となってくるものであり、機器単位・意味単位といったデータカタログ情報群のさらに上位で、流通のしくみ上必要となってくるものである。特に価格別に流通データ群を分けておくことは、随時更新し配信されるIoTデータ群において売買時の費用処理システムを簡素化する効果がある。

また、個人情報を含むデータを他の一般データと分ける理由は、例えば欧州連合のＧＤＰＲ（General Data Protection Regulation:一般データ保護規則）で規定されるように、サービサへ配信したデータであっても元データの個人が削除を希望する場合関連する情報を削除するような処理が必要となるからであり、サービサにおいて個人情報を削除可能なシステムコスト・管理コストの高いサーバシステムへの保管を自動的に行う事で情報事故を回避できるようになるからである。なお個人情報の有無及び流通コストが高いものかどうかについては付帯情報内に記載されるべきものである。

いくつかのデータ群を分類する分類については、データ群の分類種別がどのようになっているかについて、包括付帯情報内に記述しておく必要がある。

データ群の分類については、
（１）更新頻度別階層分類：サーバ特性を配慮した階層構造でデータ容量とアクセス頻度の違いによるファイル分けを行い、全ファイルを最短更新させないようにする。
（２）単価別データ分類：販売データ単価が異なる価格別分類（データ付加価値での分類）で例えば元データの意味が深いものと浅いもの、あるいは加工に工夫したデータと生データで価格差をつけるなどする。
（３）ＧＤＰＲ対応度合い別分類：個人情報の有無による分類でデータ取り扱いに注意が必要なものは分けておきデータ全体が取り扱い注意とならないようにする。
（４）データ集約度別分類：データ集約度合いによる分類（年月日）の単位別データ分類で月及び年はデータ集約度（まるめ）が高いためまるめられたデータとそうでないものを１つのファイルにしないで分けておく。
等があるが、これらの組み合わせとなっている場合、どれとどれの組み合わせになっているかを付帯情報に記述しておく必要がある。

また、包括付帯情報では、個々のデータのＩＤでもって構造を記述し包括付帯情報以下の情報がどのように配置されているかを記述することで、本情報で全体構造が把握できるようにする。

例えとして、図６４を参照しながら、提供コストを高くした高付加価値データ５２６と個人情報を含み取り扱いに注意が必要なデータ５２７が、通常のデータ５２８とは別に存在するケースを示す。

この場合、特定のデータ提供事業者が管理している、特定の地域に限定される場合、特定の機器もしくは機種でくくられるケース、特定の家の集合体（特定の住宅メーカもしくはマンションに紐づけられたもの）などで、お互いのデータに関連があり全体としていつのデータ群を形成している場合、高付加価値データ５２６と、個人情報を含み取り扱いに注意が必要なデータ５２７が、通常のデータ５２８それぞれにおいて付帯情報５１９、付帯情報５２０及び付帯情報５２１が個々の分類単位で設けられる。

また、上述のように、関連するデータにおいて、付加価値（販売額）が異なる場合や提供先が限定される情報などを含むものに分けられる場合、それぞれにデータ証明書５２３、データ証明書５２４及びデータ証明書５２５が個々の分類単位で設けられ、全体の情報内容を記述した包括付帯情報５２２が設けられ、通常のデータを流通させる場合は通常のデータ５２８を暗号化するとともに、送付内容を記述した元の包括付帯情報５２２から抜粋して作成した包括付帯情報５２１を付けてサービサ５５に配信する。ここで、包括付帯情報５２２は、関連するすべてのビックデータに関する付帯情報であって、証明書が不要であり変更が可能な情報である。

サービサ５５はこの包括付帯情報５２１の内容を読み取りサービスアプリを起動したりストレージサーバに自動保存する。

本事例では高付加価値データ５２６と、個人情報を含み取り扱いに注意が必要なデータ５２７を分けたが、この両方の組み合わせの場合も別で分割ファイルを構成する。

また更新頻度あるいはアクセス頻度に差がない場合は、これによるストレージサーバの階層を分ける処理は不要である。

このようにすることで、ファイル管理上重要な個人情報管理と費用管理を、膨大なデータが混在する場合でも確実にかつ迅速に処理することが可能となる。

もし費用の異なるデータや個人情報管理の厳しいデータがそれ以外と混在すると、利用時に１つ１つのデータをチェックし抜き取ったり選別したりする新たなクラウド処理が発生し、データ管理規模が膨大なビックデータになってくれば、これらの処理コストが膨大に膨らむことになるため、本ファイル形式によってコスト最適化がはかれるようになる。

図６５は、リアルタイム更新データの配信を示す図である。エネルギーマネージメントに使用するデータは、エネルギー管理上、例えば３０分単位の情報流通が必要となってくる場合があり、このような電力データ、随時監視が必要な見守りサービスで使われる情報などにおいては、リアルタイムでのデータ流通が必要となってくる。

このようなデータにおいてデータ証明書を付ける場合、データの信憑性のチェックと証明書の発行をリアルタイムで行う事が難しいため、例えば１ヶ月単位のデータに対し月末で証明書を発行し、後付で承認する方法がある。

例えば図６５では３月分のデータ５２８は証明書を含むまとまったデータに対し３月分の包括付帯情報５２９を付けてサービサ５５へ配信されるが、４月１日のデータ５３０はまだ証明書が発行されていない状態にある。

そのため、この場合まだ証明書がついていないデータ配信においては包括付帯情報５３１において証明書が無い旨を記述し、月末最終日の証明書発行後にその証明書を含むスキーマ上に過去分も含め証明した旨の記載を行う。

従って、月末最終日の証明書付きデータの包括付帯情報５３７は、例えばその月すべての証明書がカバーする内容を記載したスキーマとなる。

また、この際は４月３０日のデータ５３５と後付の４月分の証明書５３６と、前記包括付帯情報５３７を合わせてサービサ５５に送付する形式となる。例えばデータ量が地域の各家庭からのデータであったり膨大なデータ量となる場合などでは、毎回過去のデータを含めて配信するとデータコストがかさむため、あくまでその日の分のデータ５３５を配信する形態となる。

また、具体的な包括付帯情報５３７の記載においては、添付している証明書５３６がカバーする範囲（過去送付分の証明範囲ＩＤ（証明開始するデータのＩＤ、証明終了するデータのＩＤ）もしくは、証明範囲期間（証明開始日時、証明終了日時）、もしくは証明する全ファイルのＩＤ）を記載する。

これにより、過去データをさらに流通させる場合においても、本証明書付きデータの包括付帯情報をベースに、データ提供側と受領側であるサービサが確認し、当該範囲期間のIoTデータを流通させることが可能となる。

特にこのようにすることで、リアルタイムデータを配信し、かつある間隔で証明書を取得発行することが可能となる。

図６６は、リアルタイムデータを使ったサービス事例を示す図である。図６６は、スマートシティ５４２において、ＨＥＭＳ事業者のクラウド５３８と電力アグリゲータのクラウド５３９が、リアルタイムデータの配信によって行う、タウン電力マネージメントシステムの事例である。

この場合、スマートシティ５４２内の各家庭５８には太陽光発電システム５４３が搭載されており、各家庭の消費電力データ及び太陽光発電システム５４３の発電量及び売電量などのリアルタイムデータが例えば３０分単位にアップされ、各家庭５８における家庭内のスマート家電（太陽光発電システム５４３を含む）をＨＥＭＳ事業者のクラウド５３８から、例えばＨＥＭＳコントローラを介して制御し、各家庭５８の省エネ管理及び生活支援サービスが行われる。

このようなＨＥＭＳシステムを運営している事業者において、これら各家庭５８での３０分毎の電力情報がクラウド５３８にアップされており、このリアルタイムデータ５４５を電力アグリゲータのクラウド５３９に配信することで、電力アグリゲータが電力供給・需要管理を行い、発電事業者の発電システム５４０を最適運転することで、スマートシティ５４２の全体エネルギー管理が実現する。

電力アグリゲータは、クラウド５３９からＨＥＭＳ事業者クラウドに対し、給湯機などの蓄熱機器への制御指示を行うことで、太陽光発電の余剰電力が大きい場合にお湯を給湯機で昼間に作るなどといった、電力平準化の指示を出すことも可能となる。

いずれも発電システム５４０の運転状況と太陽光発電システム５４３の発電状況をリアルタイムでチェックしながら、発電システム５４０の発電量を全体調整していく。

電力需給は逼迫するケースでは、場合によりＨＥＭＳシステムにて省エネ設定などの指示を行う事も可能である。

これらのＨＥＭＳシステムは、同一地域内において複数の事業者がサービスをしているケースもあるため、電力アグリゲータクラウド５３９へのデータ配信は標準フォーマットにより統一されることで個別のインタフェース開発、仕様すり合わせなどが不要となる。

特にスマートタウン規模となると電力データのデータ規模も膨大なものとなるほか、各家庭５８の消費電力量、機器の操作状況などといった個人情報に関連する情報もあり、これらデータの取り扱いにおいては、情報銀行５３の配信データ監査を受けデータ証明書を発行いただくことが望ましい。

そのため前述したリアルタイムデータの配信手続きにより、タイムラグはあるものの、データ証明を定期的に受けることで、情報事故を最小限に食い止めることが可能となる。

図６７は、蓄積データを使ったサービス事例を示す図である。冷蔵庫５４７などの食料品を保存する機器におけるスマート化が進むと、例えば冷蔵庫５４７内にカメラ５４７ａを搭載し、庫内の食品状況を撮影しスマートフォンに転送することで、宅外で確認するなどのサービスが実現できる。

これらのシステムでは冷蔵庫メーカが有する家電管理用のメーカクラウド５４８に接続されており、メーカクラウド５４８において画像認識等により食材画像情報５５２から食材内容を特定しデータ化する（例えばりんご５個、きゅうり３本、ビール２本、キャベツ１個、醤油１本、牛乳１本など）処理を行うことも可能になる。

ここで各家庭の冷蔵庫情報を管理するメーカクラウド５４８においては各課程の食材在庫情報が随時アップされており、ここを統計的に処理することで、例えばどのような食材が購入されて消費されているか、またどの食材あるいはどのメーカの商品が多く消費されているか、といったビックデータを蓄積取得することが可能となる。

これらのビックデータを、例えば同一の地域毎に家庭で当該メーカの冷蔵庫を保有している分から集計し、週単位でスーパーのクラウド５５３あるいは当該地域の商店共同運営クラウド５５４に配信することで、スーパーあるいは商店がその季節、時期・地域における食品の購入志向あるいは好みに合わせ食品生産業者５５５あるいは農協等５５６の生産者に事前発注し、旬の食材の流通時期を逃さないように商品在庫管理及び発注をすることが可能となる。

例えば特定の商材の購入数の伸びが右肩あがりにのびつつある兆候をとらえ、事前手配をかけるといったアクションをとることができる。

もちろんこれらは、リアルタイム発注により当日配送を行うなどのネットスーパーシステムとも連動し、ネットスーパー購入発注時のスマートフォンアプリあるいはＰＣアプリの商品選択画面に、上記売れ行きが伸びつつある商材を優先的に表示配置し、事前仕入れの加速と合わせ、さらなる販売加速に使うことも可能となる。

ここでは、メーカクラウド５４８からスーパーのクラウド５５３あるいは地域商店のクラウド５５４へのデータ配信は、冷蔵庫食材情報といった個人情報に関連する部分を含むため、配信データの内容を情報銀行５３にて監査し、証明書を付けて送付することになるものの、統計データであればリアルタイムではなく、送付の都度証明を受けるのであれば図６５のリアルタイムデータには該当しない。ただし、週単位のデータ送付であっても証明を受けるのが月単位であれば、図６５のリアルタイムデータの扱いと同じになる。

図６８は、データファイル通信プロトコルを示す図である。メーカなどのデータ提供事業者５１及び情報銀行５３のクラウドとサービサ５５のクラウド間の情報のやりとりについては、まずデータ販売前のやりとりと販売（契約）確定後のやりとりに分けられる。

データ販売前においてはどのようなカタログ情報を持っているかといった目次情報などのチラシ情報として、データ流通市場で閲覧できるものを提供する必要があり、ここではデータ販売内容情報などを記載したちらし情報５５７がまずデータ流通市場に提供される。

次にサービサ５５からは、ちらし情報５５７を確認した上で必要なカタログ購入依頼５５８がデータ提供事業者５１に発行される。

そしてデータ販売の了解と見積書５５９が発行され、実際のデータ配信前の購入決定処理が完了する。なおこれらの購入前処理の情報についてもＪＳＯＮスキーマ等のファイル形式でやりとりすることで後述する包括付帯情報の記載とあわせ、内容のマッチングを取ることが可能になる。

またデータ販売が確定した以降は、まずサービサ５５からデータ配信要求５６３があり、次にメーカクラウドから包括付帯情報９４を送付し、これの受領を確認する受領確認情報５６０を受けてから、証明書９６の送付、またこの証明書の受領確認とデータ送信依頼５６１を確認した後、暗号化したIoTデータ本体５００を送付（ＪＳＯＮもしくはＪＳＯＮスキーマによる付帯情報を含む）することになる。

またこの後前述の暗号化データの暗号キー９９ａを送付し、最後に受領決済情報５６２を返すことで、一連のデータやりとりが終了するとの手順が考えられる。

なお、上述のデータ証明書はIoTデータ本体とあわせて暗号化しまとめて送ってしまう方法もある他、包括付帯情報及び証明書も含めてまとめて暗号化されたファイル５６５でまとめて送る方法もある。この方法により、サービサとの確認手順を省略できる。

このようにまとめると、メーカクラウドとサービサクラウド間のシーケンスを省略し、販売前、データ送付、受領決済の３つの処理に簡略化できるなど多くのデータ流通を同時に行いやすくするメリットがある。

特にデータ流通ではREST API（REpresentational State Transfer API）の思想に基づき、セッションなどの状態管理を行わない事が全体システム簡素化に必要であるが、売買の部分においてのみ確認及び決済のプロトコルを残すことが全体システムとして安全かつ効率的である。

図６９は、データ提供側にアプリを持つ場合のデータファイル通信プロトコルを示す図である。IoTデータが大規模でサービサ５５のクラウドのストレージ容量が小さい場合、サービサ５５のサービスアプリがスマートフォンに実装される場合などにおいて、付帯情報のみをサービサ５５に送付し実際のIoTデータ自体をサービサが都度データ提供事業者５１のクラウドにアクセスすることで対応できるかどうかのフラグ情報もあわせて付帯情報に記載しておくことで、サービサ５５が本フラグを確認してからデータ提供事業者５１のクラウドにアクセスし、サービサ５５がすべてのIoTデータを自身のストレージサーバに入れなくてもサービスに対応することが可能である。当該アプリにより、IoTデータを見える化したり、ある閾値を超えたかどうかの判定を行うことができる。

このためには、サービサがデータを購入する前のちらし情報５５７においてデータ提供事業者５１のクラウドで処理できるデータの見える化、閾値判定などのアプリ内容が記載され、サービサはこの内容を含んで購入判断を行う。実サービス起動時ではメーカクラウドからのスキーマ情報において、閲覧モードが使用可能であるフラグが立っている場合、サービサクラウドは自身のスマートフォンアプリに閲覧モード可能を通知し、スマートフォンからメーカクラウドの閲覧データ依頼のスキーマを送付する。

閲覧データ依頼には、サービスの内容であるIoTデータの見える化表示（例えば使用電力量のグラフ化、機器の使用頻度回数のグラフなど）であったり閾値判定（例えば設定温度を超えているかどうか）などのデータ変換あるいは判定を依頼、メーカクラウド上に搭載された閲覧アプリから得られる閲覧結果をスマートフォンに表示したり判断に使うことでスマートフォンアプリのメモリ領域の削減が可能となる。

図７０はデータ流通前のIoTちらし情報を示す図である。IoTデータ流通における販売前のちらし情報は、一般的な宣伝広告資料としてビジュアル化したものもあるが、まずはカタログの目次を記述したＪＳＯＮもしくはＪＳＯＮスキーマでの市場展開が考えられる。

この場合、例えばこのスキーマで記述されたちらし情報５５７を使って、複数のデータ提供事業者５１のクラウドからのちらし情報にある目次情報を結合し新たな総合目録情報５７２を作成することで、データ流通市場運営サイト５６９自身あるいはデータ流通商社機能を持ったデータ流通商社５７０がデータ総合目録５７２をもってデータ販売サイト上で市場運営することが可能となる。

ここではカタログ化されたデータの提供事業者名、データ規模、取得件数、計測メッシュ、取得期間、機器内容、機器数、価格情報、の一部もしくは全部をリスト化したちらし情報５７１としてデータ流通市場運営サイト５６９に展開するとともに、ちらし情報５７１は、データ提供事業者５１から事前に開示される情報が部分的に無い場合であっても、リストの一部もしくは全部の項目がすべて記載されたものであるか、もしくは各項目につけられた項目番号でもって管理でき、総合目録５７２が容易に作成できるものとする。

またサービサ５５においては、この総合目録５７２があることによって、各データ提供事業者５１を個々に検索し必要な情報を集めてくる膨大な手間が不要であり、またデータ流通商社あるいはデータ市場運営サイト自身が総合目録５７２を作成し、例えばこれをビジュアル化することによって、サービサ５５へのデータ販売を促進させる効果がある。総合目録５７２は複数のメーカクラウドのデータを集めた場合に、機器単位、意味単位、もしくは特徴抽出し切り出したものを、流通商社自体の業務として提供することが可能である。

図７１は、データ流通前の購入希望・販売内容情報を示す図である。IoTちらし情報５５７は、実データを含まず、カタログ情報・目次やデータの量、取得期間、メッシュ等の基本情報を、ちらしとして汎用的に提供するものであり、例えば温度情報、電力データなどの実際のデータは含まないものの、データ売買を行うために必要となる情報を含むものである。

そのため、そのデータがどのような機器から出てくるものか、それは制御情報なのか状態を表す情報なのかといった意味、いくらで販売するか、といった内容のものを実データ提供前にやりとりを行う。

データ価格の設定については、機器ＩＤの個数と更新頻度あるいはデータ精度により決定される場合もある他、単純に送信データByte量で規定する場合などが考えられる。なお、ここでは市場で公開しているIoTデータちらし情報に対し、購入するサービサ５５より必要なデータを選択し見積金額を算定、最終的に販売金額を双方で了解するといった手順が考えられる。

これらの価格見積方法については販売側のクラウドにWeb経由で自動計算するアプリプログラムを搭載し、データを必要とするサービサが、この見積システムにアクセスし金額を確認する方法もある。

なお、ちらし情報５５７を確認した後、サービサ５５は購入希望情報５５８を配信する。ここではちらし情報の中から必要なデータあるいは不要なデータを記述したものであり、それぞれのデータに対し購入希望の有無が記述される。

当然であるが備考欄等にちらし情報５５７以外の情報入手希望、更新頻度、データそのもののまるめ（平均化対応など）などの依頼情報を別途記述してもかまわない。

またデータ提供事業者は、購入希望情報５５８を元に、販売内容の確認及び見積書の情報５５９を送付し、ここではデータカタログのそれぞれに対し、了解かどうかの記載が行われる。

このような決済処理等においても標準的なフォーマットを規定することで、多くのデータ提供事業者５１及び多くのサービサ５５が、標準的な売買アプリケーションによりデータ売買を行うことが可能になる。

図７２はIoTデータの付帯情報を示すテーブル内容である。本テーブル情報はＪＳＯＮ、ＪＳＯＮスキーマ、ＸＭＬ等の言語で記述され、ＩＤ番号としてクラウド内で使われるURL表示でもって記述されるものである。

テーブル内容としては、本付帯情報のＩＤ、ファイル形式、データ格納リンク先ＩＤ、下位層付帯情報リンク先ＩＤ、ファイル配信頻度、暗号化有無、暗号形式、データ配信者、データ加工者、元データ供給機器製造者、証明書の有無、情報銀行などの証明者、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データ販売事業者、データ取得期間、データ配信元機器、データカタログ内容どを含み、本付帯情報を認識することでどのようなデータが配信されるかがわかるようになっている。

ここでは特に、データ加工内容の記述で意味単位、機器単位、時間単位、地域単位等での加工内容がわかるほか、データカタログ内容や更新頻度情報によって前述したストレージ階層を自動的に振りわけストレージすることが可能になる。

またデータ配信元機器数やデータサイズ・取得期間・証明書関係などはデータ規模だけでなくデータ販売価値に関連する情報であり、サービサへの提供が必要となってくるものである。

図７３はデータちらし情報テーブル内容を示す図である。本テーブルはデータ販売前のデータちらし情報５５７で、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データカタログ内容、データ配信機器、データ証明書有無、ファイル形式、データ閲覧モード、データ販売希望価格、付帯ファイルＩＤ、付帯ファイル内容などを含む。

本情報は流通データそのものではなく、サービサ５５が購入を検討するにあたって必要となる情報のみを抜粋したもので、当然データ提供事業者５５が秘匿すべきと見なす場合の項目は中身を記載しないものとする。

これら項目を標準的なちらし情報としてデータ流通市場で流通させることにより、どのサービサも同じ視点でデータを確認したり、購入検討用のアプリケーションで自動判断することができるようになる。

特に多数のデータ提供事業者５１からの情報提供によりサービスを行う場合においては、これらちし情報の標準化が不可欠であり、購入先の提供者数が多くなればなるほど購入アプリケーションによる自動購入が不可欠になるためである。

また本チラシ情報５５７には、付帯ファイルＩＤ、付帯ファイル内容、が記載されており、ここでは後続の付帯ファイル５６４において、本データの使い方事例、閲覧モードの使用方法などの情報が添付されるものである。IoTデータはサービサがデータ内容からサービスを起案し実行するものであるが、機器の特徴などを熟知したデータ提供事業者がある程度の使い方事例を提供した方が、データ市場流通が拡大する可能性があることから、このようなデータ内容以外の記述があった方が望ましい。また、開示してもよいデータ構造については、この使い方事例の中で紹介する。データ構造自体も１つの情報であるため、原則としてちらし内には記述しない。

特に店舗、個人商売などの小規模サービス事業者には、必ずしもデータの使い方に熟知しているとは限らず、テキスト文章・絵・写真・動画等の使い方事例、使うにあたっての注意事項などをファイル形式で直接添付するか、もしくはこれら事例が記載されたデータ提供事業者のURLを記述することで、より多くのユーザでデータ流通売買ができるようになるものである。

図７４は包括付帯情報９４のテーブル内容である。本テーブルの前段部分はデータ販売前のデータちらし情報５５７と同じであり、本ファイルのＩＤ、データサイズ、データ加工履歴、データ加工内容、データ更新頻度、データカタログ内容、データ配信機器、データ証明書有無、ファイル形式、データ閲覧モード、データ販売希望価格から構成される。

さらに上記ちらし情報５５７以降の情報として、データ構造（階層等）、本ファイル配置位置、ファイル配信頻度、暗号化有無、暗号形式、データ配信者、データ加工者、元データ供給機器製造者、証明者、データファイルＩＤ、データ見積もり金額などが記載され、上記ちらし情報５５７とあわせて包括付帯情報９４が構成される。包括付帯情報９４は、販売後に付帯させるものであり、証明書が不要かつ更新が可能な付帯情報である。これはサービサ５５が本包括付帯情報を確認することで、購入前のちらしと同じか、もしくはその後の交渉等で修正した部分などをチェックできるようにしたものであり、このチェック処理もサービサ５５のアプリケーションで自動化する事が望ましい。

また包括付帯情報は暗号化処理や証明書取得後にも追記修正できるデータであるため、ファイル配置や配信者、金額等の情報が記述される。

図７５はデータ構造の記述を示すための包括付帯情報テーブル記載内容の詳細である。特にIoTデータが複数のファイルに構造化されている場合は、これに関する記述が必要であり、ここで包括付帯情報を含むファイル自身が、さらなる全体構造の中の１つである場合は本ファイルの上位階層の有無を記載し、上位を含む全体構造はさらに上位の包括付帯情報内に記載される。

例えば、本図では更新頻度が異なりかつ販売価格が異なる場合で構造化した事例を記載し、第一階層、第二階層、第三階層の３つにファイルをふりわけたものである。
データ構造全体（階層等）－更新頻度別３階層＋単価別分類
本ファイル配置位置 －最上位データファイル
ファイル１（ＩＤ：＊＊＊＊）―第一階層（更新頻度高）＋無償
ファイル２（ＩＤ：＊＊＊＊）―第二階層１（更新頻度中）＋１００円/Ｔ
ファイル３（ＩＤ：＊＊＊＊）―第二階層２（更新頻度中）＋２００円/Ｔ
ファイル４（ＩＤ：＊＊＊＊）―第三階層（更新頻度小）＋５００円/Ｔ

ここでは全体構造を記述するとともに、各IoTデータファイルが全体構造のどこに該当するかを記述する。

ただし、特に個人情報のファイルを分けて配置している場合に、データ構造全体自体が秘匿情報になる場合もあり、配信するデータの階層構造のみがわかるよう、自身の階層及び同一階層で配信するデータがある場合はそのすべてと、その下にぶら下がっている配信するデータ群の階層構造を本包括付帯情報内に記述し、自身の階層から上位にある配信しない部分の構造や、同列の階層及び下の階層で配信しないものは秘匿する。

また自身より上位階層のデータを配信する場合であっても、上位階層の配信有無のみを記載し階層構造や内容を記載しないことで構造を秘匿するものである。

特にサービサへの提供以降で、サービサ自身がさらに別のサービサへデータの分割提供を行う場合も想定されるため、上位の構造情報はその下の包括付帯情報には記載しないこととし、構造情報の伝播を防ぐようにしたものである。

本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施の形態ではなく、請求の範囲によって示される。そして、請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。

本出願は、２０１８年８月２４日に出願された、日本国特許出願特願２０１８－１５７５８２号に基づく。本明細書中に日本国特許出願特願２０１８－１５７５８２号の明細書、特許請求の範囲、図面全体を参照として取り込むものとする。

１ データ流通システム、１０ データ収集サーバ、１１ ストレージサーバ、１２ 個人情報ストレージ、２０ データ利用サーバ、２１ ストレージサーバ、２２ 個人情報ストレージ、３０ 機器、４０ 施工業者サーバ、５０ 証明サーバ、１００ 通信部、１１０ 制御部、１２０ 記憶部、２００ 通信部、２１０ 制御部、２２０ 記憶部、３００ 通信部、３１０ 制御部、３２０ 記憶部、１１０１ 意味特定部、１１０２ 使用頻度推定部、１１０３ 付帯情報作成部、１１０４ データ保存部、１１０５ 取り出し条件決定部、１１０６ データ取り出し部、１１０７ 包括付帯情報作成部、１１０８ 目録作成部、２１０１ データ要求部、２１０２ データ保存部、３１０１ 機器データ作成部、３１０２ 意味特定部、３１０３ 使用頻度推定部、３１０４ 付帯情報作成部、８０００ バス、８００１ プロセッサ、８００２ メモリ、８００３ インタフェース、８００４ 二次記憶装置、ＮＴ インターネット。

Claims (18)

1. 記憶手段に保存された機器データと前記機器データに対応する付帯情報とを取り出すデータ取り出し手段と、
   前記データ取り出し手段により取り出された１以上の前記機器データと前記付帯情報との組であるデータ群に関する包括付帯情報であって前記データ群の販売価格を示す情報を含む包括付帯情報を作成する包括付帯情報作成手段と、
   前記データ群と前記包括付帯情報とを、流通データとしてデータ利用サーバに送信する送信手段と、
   を備えるデータ収集サーバ。
2. 前記包括付帯情報に基づいて前記データ群のちらし、販売目録又は複数の前記ちらしに基づく総合目録を作成する目録作成手段をさらに備え、
   前記送信手段は、前記流通データの販売のために、前記ちらし、前記販売目録又は前記総合目録を前記データ利用サーバに送信する、
   請求項１に記載のデータ収集サーバ。
3. 前記ちらし、前記販売目録又は前記総合目録は、データ売買を行うために必要となる情報を含む、
   請求項２に記載のデータ収集サーバ。
4. 前記付帯情報は、個人情報記憶手段に保存されたテーブルによって、前記個人情報記憶手段に保存された個人情報と対応付けられている、
   請求項１から３のいずれか１項に記載のデータ収集サーバ。
5. 複数の記憶手段に保存された複数の機器データと、前記複数の機器データのそれぞれの機器データに対応する複数の付帯情報とを取り出すデータ取り出し手段と、
   前記データ取り出し手段により取り出された複数の前記機器データと前記付帯情報との組であるデータ群に関する包括付帯情報を作成する包括付帯情報作成手段と、
   前記データ群と前記包括付帯情報とを、流通データとしてデータ利用サーバに送信する送信手段と、
   を備えるデータ収集サーバ。
6. 前記包括付帯情報は、前記機器データの正当性を証明する証明書を含まない、
   請求項５に記載のデータ収集サーバ。
7. 前記包括付帯情報は、前記データ群を表すデータ構造に関する情報を含む、
   請求項５又は６に記載のデータ収集サーバ。
8. 前記包括付帯情報は、前記データ群が、複数の階層のうちどの階層に属するかを示す情報と、前記データ群が属する階層と同一の階層又は下位の階層に属する他のデータ群であって前記送信手段による送信の対象となるデータ群に関する情報とを含み、前記データ群が属する階層と同一の階層でも下位の階層でもない階層に属する他のデータ群に関する情報と、前記データ群が属する階層と同一の階層又は下位の階層に属する他のデータ群であっても前記送信手段による送信の対象となっていないデータ群に関する情報とを含まない、
   請求項７に記載のデータ収集サーバ。
9. 前記付帯情報と前記包括付帯情報との少なくとも１つは、ＪＳＯＮスキーマにより表される、
   請求項１から８のいずれか１項に記載のデータ収集サーバ。
10. 記憶手段に保存された機器データと前記機器データに対応する付帯情報とを取り出し、
    取り出された１以上の前記機器データと前記付帯情報との組であるデータ群に関する包括付帯情報であって前記データ群の販売価格を示す情報を含む包括付帯情報を作成し、
    前記データ群と前記包括付帯情報とを、流通データとしてデータ利用サーバに送信する、
    データ流通方法。
11. 前記包括付帯情報に基づいて前記データ群のちらし、販売目録又は複数の前記ちらしに基づく総合目録を作成し、
    前記流通データの販売のために、前記ちらし、前記販売目録又は前記総合目録を前記データ利用サーバに送信する、
    請求項１０に記載のデータ流通方法。
12. 前記ちらし、前記販売目録又は前記総合目録は、データ売買を行うために必要となる情報を含む、
    請求項１１に記載のデータ流通方法。
13. 前記付帯情報は、個人情報記憶手段に保存された個人情報と対応付けられている、
    請求項１０から１２のいずれか１項に記載のデータ流通方法。
14. 複数の記憶手段に保存された複数の機器データと、前記複数の機器データのそれぞれの機器データに対応する複数の付帯情報とを取り出し、
    取り出された複数の前記機器データと前記付帯情報との組であるデータ群に関する包括付帯情報を作成し、
    前記データ群と前記包括付帯情報とを、流通データとしてデータ利用サーバに送信する、
    データ流通方法。
15. 前記包括付帯情報は、前記機器データの正当性を証明する証明書を含まない、
    請求項１４に記載のデータ流通方法。
16. 前記包括付帯情報は、前記データ群を表すデータ構造に関する情報を含む、
    請求項１４又は１５に記載のデータ流通方法。
17. 前記包括付帯情報は、前記データ群が、複数の階層のうちどの階層に属するかを示す情報と、前記データ群が属する階層と同一階層に属する他のデータ群であって送信の対象となるデータ群に関する情報とを含み、前記データ群が属する階層と異なる階層に属する他のデータ群に関する情報と、前記データ群が属する階層と同一階層に属する他のデータ群であって送信の対象となっていないデータ群に関する情報とを含まない、
    請求項１６に記載のデータ流通方法。
18. 前記付帯情報と前記包括付帯情報との少なくとも１つは、ＪＳＯＮスキーマにより表される、
    請求項１０から１７のいずれか１項に記載のデータ流通方法。

Images