JP6694048B1

JP6694048B1 - データ取引システム

Info

Publication number: JP6694048B1
Application number: JP2018238786A
Authority: JP
Inventors: 友康鈴木; 敏也後藤; 大将小河
Original assignee: PLAT'HOME CO., LTD.
Current assignee: PLAT'HOME CO., LTD.
Priority date: 2018-12-20
Filing date: 2018-12-20
Publication date: 2020-05-13
Anticipated expiration: 2038-12-20
Also published as: WO2020129815A1; JP2020101926A; KR20210087071A; CN113196327A; EP3896637A4; KR102652129B1; EP3896637A1; US20220058647A1

Abstract

【課題】ＩｏＴのデータを円滑に流通させる仕組みを実現することを目的とする。【解決手段】データ取引システムは、外部からの制御によって、データのチャネルを設定し、所定の相手先にデータを送出することができるデータトランスポート部と、データの取引契約を実行するデータトランザクション部と、データを提供する提供者のために、データトランザクション部に対してデータの売りオファーを発行する取得部と、データを利用するサービスプロバイダのために、データトランザクション部に対してデータの買いオファーを発行するデータブローカと、を備え、データトランザクション部は、売りオファーと買いオファーとを条件マッチングし、マッチングした場合には、サービスプロバイダに、提供者からサービスプロバイダにデータを送出するためのチャネルを設定させる。【選択図】図４

Description

本発明は、データの取引を行うデータ取引システムに関する。特に、契約からデータの取引までを円滑に行うことができるデータ取引システムに関する。

（１）ＩｏＴ分野の伸展
近年、物のインターネットであるＩｏＴ（Internet of Things）が広く利用されている。このＩｏＴ上のセンサ等で得られたデータを、通常のインターネット上のユーザが利用するためには、一度サーバに蓄積し、インターネット上のユーザが当該サーバにアクセスしてデータを利用する仕組みが多く用いられている。

従来のＩｏＴプラットフォームの概念図が、図２５に示されている。このプラットフォームは、データ蓄積型プラットフォームと呼ぶ。（以下、プラットフォームをＰＦと称する）。図２５に示すように、データを取得するデバイス１４は、ゲートウェイ（以下、ゲートウェイをＧＷと称する）１２を介して、ＰＦ１０にデータを供給する。この従来のＰＦ１０は、ストレージ（記憶装置）を備えており、データを蓄積することができる。データは一旦蓄積された後、種々の相手方に提供される。ＧＷ１２を利用しているのは、デバイス１４のネットワークと、インターネットとの橋渡しを行うためである。図２５のデータ蓄積型ＰＦは、データサイロ型（倉庫型）とも呼ばれ、従来のＩｏＴの利用は、このデータ蓄積型を用いることが多い。

データ蓄積型ＩｏＴプラットフォームは、
・データを保持する（利用させる）
・占有型（ストック型）
・シングルドメインアーキテクチャである
という特徴がある。
しかしながら、近年、ＩｏＴで扱うデータ量は膨大なものとなっている。１時間毎の気温データのごとき非常に少ないデータ量の場合もあるが、監視カメラ等、大量のデータ量を活用する必要があるＩｏＴも多い。このよう大量のデータを大量に、かつ、リアルタイムに配送する効率的な仕組みは、従来知られていない。

（２）取引契約の自動実行（スマートコントラクト）
また、近年、種々の取引が自動的に実行されるスマートコントラクトの枠組みが活用されつつある。この枠組みでは、例えば分散台帳等の技術を用いることによって信頼性を担保しながら契約が自動実行される技術の活用が広く提唱されている。
この従来のスマートコントラクトの枠組みは、いわゆるブロックチェーンの技術を活用したものが多く、上述したように、膨大なデータを扱うＩｏＴのデータの契約に用いることは困難であった。

例えば、下記特許文献１では、ＩｏＴゲートウェイ等でブロックチェーンアプリを起動する仕組みが開示されている。ここで、ブロックチェーンアプリは、さらに分散ファイル共有アプリを起動し、分散ファイル共有ネットワークに情報のファイルの登録等を実行する。このような仕組みによれば、ブロックチェーンアプリを用いているので、ファイルのコンテンツの一意性を確保できるとされている。

特開２０１８−８１４６４号公報

上記（１）で述べたように、大量のＩｏＴのデータに対応するためには、従来のデータ蓄積型ＰＦでは限界があるが、これを解決する手段で有効な仕組みは未だ知られていない。そのため、ＩｏＴにおける大量のデータを効率よく輸送する仕組みが望まれている。
また、（２）で述べたように、近年、分散型台帳で取引を管理する仕組みは広く活用が進んでいる。しかし、分散型台帳の仕組みは、いわゆるブロックチェーンを構築していく仕組みから成り立っているので、大量のデータを扱うことは原理的に困難である。そのため、分散型台帳の仕組みをＩｏＴの分野の取引に応用することは事実上困難であると考えられる。これを解決する手段で有効な仕組みは未だ知られていない。そのため、ＩｏＴにおける大量のデータの取引を分散型台帳で管理する仕組みが望まれている。

本発明は、このような事情に鑑み、ＩｏＴのデータを円滑に流通させる仕組みを実現することを目的とする。また、この流通の仕組みを採用しつつ、そのＩｏＴのデータの取引の管理を分散型台帳を利用して実行する仕組みを実現することを目的とする。

本発明に係るデータ取引システム（例えば、後述するＰｔＤＸ１１６）は、外部からの制御によって、データのチャネルを設定し、所定の相手先にデータを送出することができるデータトランスポート部（例えば、後述するＤＥＸＰＦ１０６）と、データの取引契約を実行するデータトランザクション部（例えば、後述するＰＴＰＦ１１８）と、データを提供する提供者（例えば、後述するＤＯ１０２）のために、前記データトランザクション部に対してデータの売りオファーを発行する取得部（例えば、後述するＡＣ１０４）と、データを利用するサービスプロバイダ（例えば、後述するＳＰ１０８）のために、前記データトランザクション部に対してデータの買いオファーを発行するデータブローカ（例えば、後述するＤＢ１１０）と、を備え、前記データトランザクション部は、前記売りオファーと前記買いオファーとを条件マッチングし、マッチングした場合には、前記サービスプロバイダに、前記提供者から前記サービスプロバイダにデータを送出するための前記チャネルを設定させる。

前記データトランスポート部は、データの蓄積を目的としないデータ流通型プラットフォーム（例えば、後述する図１に示すデータ流通型ＰＦ）であってよい。

前記データトランザクション部は、前記取引契約を分散型台帳を利用して保全及び管理をしてよい。

前記分散型台帳はブロックチェーン（例えば、後述するブロックチェーン２００）を利用してよい。

前記分散型台帳は公開されたブロックチェーン（例えば、後述するブロックチェーン２００）を利用してよい。

前記提供者が提供するデータを得るためのデバイス（例えば、後述するデバイス１０）に紐付けられた公開鍵が、前記ブロックチェーン上に記憶されてもよい。

前記データトランザクション部は、Ethereumのシステムを利用して構成されてよい。

前記データトランスポート部の出力データを処理し、前記処理後の前記出力データを、前記データトランスポート部の入力に供給するサブルーティン部（例えば、後述するサブルーティン２０２ｎ〜２０２ｍ）、を有してよい。

前記取得部と前記データブローカとは、前記データトランザクション部において、仮想通貨、又は、暗号通貨を用いて決済してよい。

前記データは、ＩｏＴデータでもよく、前記提供者は、ＩｏＴデータを提供してよい。

上で述べたデータ取引システムを２個以上と、前記２個以上のデータ取引システム内の前記データトランザクション部に接続する他のデータトランザクション部であって、前記２個以上の複数のデータトランザクション部の上位のｍａｉｎデータトランザクション部（例えば、後述するＭａｉｎとなるＰＴＰＦネットワーク１１８ｍ）、を備えてもよい。

本発明によれば、ＩｏＴのデータの流通を円滑にすることができる。また、ＩｏＴの上でいわゆるスマートコントラクトを実現することが可能となる。

本実施形態のＰｔＤＸの原理図である。本実施形態のＰｔＤＸのＩｏＴプラットフォームを含むサービス提供の様子を示す説明図であって、他のプラットフォームと接続した様子を示す図である。本実施形態のＰｔＤＸの構成とその周辺構成を示す説明図である。本実施形態の具体的な取引の動作の様子を表す説明図である。本実施形態のＰＴＰＦ１１８の処理の概念図である。図５のデータトランザクションの部分を二点鎖線で示し、データトランスポートの部分を一点鎖線で示した図である。図６に加えて対価の流れを書き加えた図である。 Nettingを行う場合の説明図である。ＰＴＰＦ１１８内で、ＡＣ１０４と、ＤＢ１１０と、Ｂ１２０と、の間の取引を実行する様子を示す説明図である。ＰＴＰＦ１１８を構築する場合の分散型台帳は、Private DLT又はPublic DLTで実現してよいことを示す説明図である。ＡＣ１０４が３個存在する場合の説明図である。図１１の図に、トークン１３０（ＸＰＴ）と、Public Blockchain PF１３２の構成を加えた説明図である。ＤＥＸＰＦ１０６に接続する部分のみを取り出した説明図である。ＤＯ１０２が２個存在し、ＳＰ１０８が２個存在するＰｔＤＸの構成図が示されている。ＰＴＰＦ１１８が条件マッチングを行う様子を示す説明図である。ＰＴＰＦ１１８がチャネルＩＤを発行する様子を示す説明図である。チャネルＩＤを設定されたＤＥＸＰＦ１０６はデータ流通を開始する様子を示す説明図である。ＡＣ１０４とＤＢ１１０との間で決済が行われる様子を示す説明図である。ＩｏＴデータの伝送のデータプレイン（高速路）と、取引を含むメタデータのコントロールプレイン（低速路）とが分離している様子を示す概念図である。コントロールプレインのメタデータを、ブロックチェーンによる公開ドメイン上に構築する様子を示す概念図である。データの出口をサブルーティンへ入れて処理をさせ、さらに、処理後のデータをＤＥＸＰＦ１０６の入力データとすることによって再帰的な処理が可能とした概念図である。ＭａｉｎとなるＰＴＰＦネットワーク１１８ｍが複数のブランドドメインを配下に配置している様子を示す説明図である。ＤｅＩＤ（デバイスＩＤ）に紐付けられた公開鍵をブロックチェーン上に置く様子を示す概念図である。ＰＤＥｘｃｈａｎｇｅ４００の構成図である。従来の一般的なＩｏＴプラットフォームであるデータサイロ型（倉庫型）の原理図である。

以下、本発明の実施形態を図面に基づいて説明する。
１．採用するＩｏＴプラットフォーム
図１には、本実施形態で説明する特徴的なＩｏＴプラットフォームであるＰｔＤＸ１１６のＩｏＴプラットフォームの原理を示す原理図である。この図は、従来のＩｏＴプラットフォームである図２５と対比される図である。
同図に示すように、デバイス２４のデータは、ゲートウェイ２２を経由してＰｔＤＸ１１６のネットワーク中に流される。これをデータ流通型ＰＦ（プラットフォーム）と呼ぶ。

このデータ流通型ＰＦは、
・データを保持しない
・共有型（フロー型）
・クロスドメインアーキテクチャ
という特徴を有する。図２５で説明したデータ蓄積型ＰＦが、
・データを保持する（利用させる）
・占有型（ストック型）
・シングルドメインアーキテクチャである
という点で、大きく両者は異なる。

２．ＰｔＤＸの役割
本実施形態では、
（１）データの流通面では、本実施形態で提案する新しいＩｏＴのＰＦであるＤＥＸＰＦを用いている点。
（２）データの取引やサービスレイヤの提供面をＰＴＰＦと呼ばれるトランザクションプラットフォームを用いている点。
を特徴とする仕組みを説明する。このような仕組みをＰｔＤＸ１１６と呼ぶ。ＰｔＤＸは、ＰｔＤａｔａＥｘｃｈａｎｇｅの略であり、ここで、Ｐｔとは、仮想通貨の単位である。本実施形態では、仮想通貨による対価の支払いが可能であることを特徴とする取引を実現している。そのため、本願発明者らは、本仕組みをＰｔＤＸと呼ぶ。

ＰｔＤＸ１１６の役割は、簡単に言えば、ＩｏＴへのＡＰＩ／サービスレイヤの提供である。ＰｔＤＸ１１６は、各ＰＦや、サービスプラットフォームに対して、ＩｏＴデバイスレイヤへのＡＰＩ・アクセスサービスを提供する。この結果、各ＩｏＴデバイスは様々なＰＦや、サービスにフレキシブルに接続可能となる。
このようなＰｔＤＸ１１６の原理図が図２に示されている。同図に示すように、デバイス１４のデータは、ＧＷ１２を経由してＰｔＤＸ１１６のネットワークに供給される。各ＰＦ１０は、このＰｔＤＸ１１６のネットワークを介してＩｏＴのデータを受け取ることができる。
すなわち、ＰｔＤＸ１１６は、ＩｏＴへのＡＰＩ／サービスレイヤを提供するものである。
ＰｔＤＸ１１６は、ＩｏＴデータトランスポート＆トランザクションプラットフォームであり、ＩｏＴデータを安全・高速に伝送＆取引を執行できる汎用／情報ビジネス基盤である。
ＰｔＤＸ１１６は、請求の範囲のデータ取引システムの好適な一例に相当する。

ＰｔＤＸ１１６は、利用者にとって、下記のような特徴を有する。
クロスドメインであるという特徴を有する。
すなわち、ＩｏＴの全てのドメイン、全てのリージョン、全てのティア（クラウド、エッジ、Ｔｈｉｎｇｓ）でのトランザクションを可能とするプラットフォームである。
ビジネス面での特徴
プラットフォーム上でビジネス執行可能という特徴を有する。つまり、（ａ）契約の締結・実施管理・決済、（ｂ）データエクスチェンジ、（ｃ）データオーナシップの管理、が可能となるプラットフォームである。

３．ＰｔＤＸの技術面における特徴
ＰｔＤＸは、ＩｏＴデータエクスチェンジと取引・決済を提供する情報基盤であり、以下のような技術的特徴がある。
（１）分散台帳技術：分散台帳技術（ＤＬＴ： Distributed Ledger Technology）を利用している。ＰＦ利用のためのトークン発行をすることによってデータの流通取引を可能としている。
（２）超高速：データ通信は、ＤＥＸＰＦを使用しているので超高速で通信することができる。ＰＴＰＦは、チャネルＩＤを付与することによって、データ取引、決済、権利コントロールを実現している。また、超大量トラフィックに対応することができる。
（３）スケール：Global、クラウド、エッジ、Things、すべて対応することができる。
（４）セキュア：End to End、Center to Endでのセキュリティと管理の確保をすることができる。
（５）完全性：取引レコードの保全をすることができる。Data of Record / IoT Transaction記録の完全な保全と管理が可能である。
（６）Ownershipコントロール：データオリジンから各フローの段階の権利に基づくデータ利用の権限管理が可能である（DLT/スマートコントラクト)。
（７）クロスドメイン：異種ドメインのクロスプラットフォームに対応することができる。プラットフォームのプラットフォームとしても機能することができる。これは、いわゆるInter Platformである。

４．ＰｔＤＸの役割
ＰｔＤＸは、情報産業革命後の産業上重要な役割を果たしている。その役割を従前の産業形態と比較し、説明する。
従前の経済システムにおける主な対象物は、物質やエネルギーであったが、ＰｔＤＸは、情報を対象物とする。また、従前の経済システムで用いられる通貨は、貨幣（貝、金・銀）や、紙幣（銀行券）であったが、ＰｔＤＸでは、仮想通貨／トークン（Crypto Currency）を通貨とする。また、従前の経済システムで用いられる台帳は、帳簿やＤＢ（データベース）であったが、ＰｔＤＸでは、分散台帳（DLT：Distributed Ledger Technology）を台帳とする。

５．ＰｔＤＸの構成
図３には、本実施形態におけるＰｔＤＸ１１６の構成とその周辺構成が示されている。ＰｔＤＸ１１６は、請求の範囲のデータ取引システムの好適な一例に相当する。
図３に示すように、ＰｔＤＸ１１６は、ＰＴＰＦ１１８と、ＤＥＸＰＦ１０６から構成されている。
デバイス１００は、ＩｏＴのデータを入出力するデバイス１００である。本実施形態では、データを取得するデバイス１００として説明し、デバイス１００が取得したデータを取引する場合を説明する。
ＤＯ１０２は、デバイスオペレーター（Device Operator）であり、デバイス１００を制御する者（装置）を意味する。ＤＯ１０２は、請求の範囲の提供者の好適な一例に相当する。
ＡＣ１０４は、アクワイアラ（Acquirer）であり、データの売りオファー等を実行する者（のアカウント）である。
アカウントについて
例えば、Ethereumを利用する場合、Ethereum上では２種のアカウントを利用することができる。一つは、Externally Owned Account（以下、ＥＯＡと称する）であり、もう一つは、Contract である。ＥＯＡは、ユーザによって生成され、コントロールされるアカウントである。Contractは、ＥＯＡからトランザクションを介して生成されるアカウントである。また、Contractは、一種の自動エージェントであり、ＥＯＡが発信するトランザクションをトリガとして、コントラクト・コードを実行する。また、Contractは、簡単に言えば、変数と関数との集合体のようなものである。なお、本実施形態における関数は、本願発明者らが独自に構築したものである。つまり、コントラクト・コードは、Ethereum上で実行される関数のようなものである。本実施形態におけるＡＣ１０４は、例えば、上記Contract であり、関数を実行する。
本実施形態においては、ＡＣ１０４も、ＤＢ１１０も、ＰＴＰＦ１１８も、例えば、Ethereum上のContract で実現してよい。また、本実施形態における関数とは、上述したEthereum上のコントラクト・コードで実現してよい。
ＡＣ１０４は、ＤＯ１０２のためにデータの売りオファーを発行する。また、ＡＣ１０４は、請求の範囲の取得者の好適な一例に相当する。

ＤＥＸＰＦ１０６は、伝送（トランスポート）ＰＦであり、データを伝送する交換装置である。
ＰＴＰＦ１１８は、取引（トランザクション）ＰＦであり、データではなく、取引（トランザクション）を実行する。
ＤＢ１１０は、データブローカ（Data Broker）であり、データを買いオファーを実行し、データの取引を行う。ＤＢ１１０は、後述するＳＰ１０８のために、データの買いオファーを発行する。また、ＤＢ１１０は、請求の範囲のデータブローカの好適な一例に相当する。ＤＢ１１０も、ＡＣ１０４と同様に、例えば、上記Ethereum上のContract で実現してよく、所定の関数を実行してよい。
Ｂ１１４は、ブランド（Brand）である。
ＳＰ１０８は、サービスプロバイダ（Service Provider）であり、データを利用してサービスを提供する者（のアカウント）である。ＳＰ１０８は、請求の範囲のサービスプロバイダの好適な一例に相当する。
Ｂｎｆ１１２は、データを利用してビジネスを実行する者（のアカウント）である。Ｂｎｆ１１２における「Ｂｎｆ」とは、Beneficiaryを表し、受取人、受益者を意味する。
また、図３において、二点鎖線は、ビジネス上のデータの流れ（Business Data Flow）を示している。そして、一点鎖線は、ＩｏＴのデータの流れ（IoT Data Flow）を表している。
図４には、具体的な取引の場合の動作の様子が示されている。

（１）まず、ＡＣ１０４は、ＤＯ１０２の依頼を受けて、データの売りオファーをＰＴＰＦ１１８上で発行する。本実施形態におけるデータの売りオファーは、具体的には次のように記述される。
（ａ）メタデータの記述（データプロファイルそのもの）
（ｂ）宛先（区分）
（ｃ）権利情報
（ｄ）その他
このような売りオファーが発行される。
さて、ＰＴＰＦ１１８（スマートコントラクト基盤）上では、データの売り買いを実行することができる。条件が合致していれば、自動的に約定が実行され、契約条件に基づき契約が執行される。ここで、契約が執行されるとは、その契約に対応するチャネルが付与されて、データが利用可能になること、及び、条件に基づき決済が行われること、の２つの処理を実行することをいう。ここで、トランザクションデータは、改竄されることなく、ＰＴＰＦ１１８において永久に保管されてもよい。
また、ＰＴＰＦ１１８は、ＩｏＴデータトランザクション基盤ということができる。本実施形態では、例えば、ＤＬＴ：Distributed ledger Technology (Enterprise Ethereum)PF（プラットフォーム）を用いて構成してよい。Ethereumは商標である。

（２）次に、ＤＢ１１０が、ＳＰ１０８の依頼を受けて、買いファーをＰＴＰＦ１１８上で発行する。本実施形態におけるデータの買いオファーは、具体的には次のように記述してよい。
（ａ）トランザクションのためのＩＤ、アカウント情報、Price
（ｂ）ＤＢ１１０の信頼できるクレジット（裏書き）
ＰＴＰＦ１１８は、これら売りオファー、買いオファーの条件が適合していれば契約を自動執行する。
なお、図４において、ＤＯ１０２のＩＤは、図示されていない管理システムによってＩＤ管理されている。また、ＳＰ１０８も、図示されていない管理システムによってＩＤ管理されている。

６．ＰＴＰＦの処理動作
図５には、ＰＴＰＦ１１８の処理の概念図が示されている。ＰＴＰＦ１１８は、データトランザクションプラットフォーム（取引）であり、データ取引のトランザクション部分を受け持つ。なお、これに対して、ＤＥＸＰＦ１０６は、データトランスポートプラットフォーム（伝送）であり、データ取引のデータ取引の伝送部分を受け持つ。
図５に示すように、ＰＴＰＦ１１８においては、ＡＣ１０４から売りオファーを受け付け、ＤＢ１１０から買いオファーを受け付けるＢ（Brand）１２０が描かれている。
図６は、図５の中のデータトランザクションの部分を、二点鎖線で示し、図５の中のデータトランスポートの部分を一点鎖線で示した図である。このように本実施形態で特徴的なことの一つは、トランザクション部分と、データトランスポート部分を分けていることである。従来の分散型台帳は、売りオファーや買いオファーを処理することはできるが、データの伝送のように、大量のデータを取り扱うことは困難である。本実施形態では両プラットフォームのそれぞれの特徴を生かすような処理をそれぞれ行わせて、いわゆる分業の効果を得ようとするものである。

図７は、図６と同様の図であるが、対価の流れが描かれている。
図７に示すように、データの取引における対価は、ＳＰ１０８からＤＢ１１０に渡される。次に、ＤＢ１１０からＰＴＰＦ１１８内で、Ｂ１２０に伝送される。Ｂ１２０は、契約の条件が成立していれば、対価をＡＣ１０４に伝送する。ＡＣ１０４は、ＤＯ１０２に対価を渡す。このように、契約のトランザクションの部分は、データトランザクションプラットフォーム（取引）であるＰＴＰＦ１１８内で行われる。
ＤＯ１０２は、例えば、対価の受領を以て、データの提供を行う。
なお、いわゆるNettingもＰＴＰＦ１１８内で実行することもできる。図８に示すようにＡＣ１０４と、ＤＢ１１０との間で直接にNetting を行ってよい。なお、Netting（ネッティング）とは、債権と債務とを相殺するように、当事者間で、支払金額と受取金額の差額を計算して、その差額を当事者間で決済することをいう。
なお、ＰＴＰＦ１１８内での決済、対価の支払い、対価の受領、等は種々の方法で実行してよいが、例えば仮想通貨、暗号通貨等で実行してもよい。例えば、ＰＴＰＦ１１８をEthereum（商標）を用いて構成する場合は、仮想通貨Etherを用いて決済してもよい。

このように、本実施形態においては、データの伝送以外の取引や契約の締結、決済等をＰＴＰＦ１１８内で実行することができる。この結果、図９に示すように、ＡＣ１０４と、ＤＢ１１０と、Ｂ１２０と、の間で取引をＰＴＰＦ１１８内で円滑に行うことが可能である。本実施形態において特徴的なことは、契約に関するプラットフォームを、データの伝送のプラットフォームと別に設けていることである。その結果、分散型台帳等の技術を利用することができるので、安全で、改竄が困難な取引を実現することができる。
つまり、分散型台帳を利用して、契約内容（契約書）や、各種取引の書類、決済の記録、等を保全、管理、保管のいずれか１個以上の処理を行ってもよい。

また、ＰＴＰＦ１１８は、その採用する分散型台帳を種々の手法で実現することができる。例えば、Private DLTで実現してもよいし、Public DLTで実現してもよい。また、他の様々なブロックチェーン（コンソーシアム型等）を利用してもよい。この説明図が図１０に示されている。図１０に示すように、ＰＴＰＦ１１８を構築する場合の分散型台帳は、その用途に応じてPrivate DLT又はPublic DLTで実現してよい。ここで、DLTとは、Distributed Ledger Technologyの意味である。ＰＴＰＦ１１８は、例えば、イーサリアム（Ethereumは商標）のシステムで構成してもよい。

７．実際の形態
これまでは、ＡＣ１０４、ＤＢ１１０が１個ずつ存在する場合を例として説明したが、これらはそれぞれ複数個存在してよい。このような例を示す説明図が図１１に示されている。図１１には、例えば、ＡＣ１０４が３個存在する例を示している。この３個は、例えば、データ提供会社の東京支店、京都支店、大阪支店、等でよい。
東京支店は、その制御下の東京の複数の温度センサを管理しており、それらのデータを吸い上げて、ＤＥＸＰＦ１０６に供給する。
京都支店は、その制御下の京都の複数の温度センサを管理しており、それらのデータを吸い上げて、ＤＥＸＰＦ１０６に供給する。
大阪支店は、その制御下の大阪の複数の温度センサを管理しており、それらのデータを吸い上げて、ＤＥＸＰＦ１０６に供給する。

また、図１１には、例えば、ＤＢ１１０、ＳＰ１０８がそれぞれ３個存在する例を示している。このＳＰ１０８の３個は、例えば、武蔵野市役所、京都市役所、大阪市役所、等でよい。
武蔵野市役所は、東京の武蔵野市の温度データを欲しており、これらのデータを用いて熱中症等の判断を行おうとしている。したがって、所定の温度データをＤＢ１１０経由で申し込んでいる。そして、実際のデータは、ＤＥＸＰＦ１０６を介して入手している。
京都市役所は、京都市の温度データを欲しており、これらのデータを用いて光化学スモッグ等の判断を行おうとしている。したがって、所定の温度データをＤＢ１１０経由で申し込んでいる。そして、実際のデータは、ＤＥＸＰＦ１０６を介して入手している。
大阪市役所は、大阪市の温度データを欲しており、これらのデータを用いて電力量の予測判断を行おうとしている。したがって、所定の温度データをＤＢ１１０経由で申し込んでいる。そして、実際のデータは、ＤＥＸＰＦ１０６を介して入手している。
このように、複数の意ＤＯ１０２及びＡＣ１０４が存在していてもよいし、同様に、複数のＤＢ１１０、ＳＰ１０８が存在してよい。但し、いずれの場合も、ＤＥＸＰＦにおいて適宜データのスイッチが行われるので、チャネル毎にデータが自動的に振り分けられる。

図１２には、図１１に構成に加えて、トークン１３０（ＸＰＴ）と、Public Blockchain PF
１３２とを備えた構成が示されている。この図に示すように、ＰＴＰＦ１１８のプラットフォーム中に、種々のブロックチェーンを含めてもよい。例えば公開ブロックチェーンでもよい。また、対価も、種々の仮想通貨やトークンを用いてよい。ＸＰＴと呼ばれる暗号通貨を用いてもよい。

８．ＤＥＸＰＦの構成
図１３は、ＤＥＸＰＦ１０６に接続する部分のみを取り出した説明図である。この図に示すように、ＤＥＸＰＦ１０６（ＩｏＴデータ伝送／交換プラットフォーム）は、いわば交換機の役割を果たし、外部からＡＰＩを使用することよって、適宜所望のルートでチャネルを形成することができるものである。したがって、ＩｏＴのデータを、大量に伝送／交換することができる。ＤＥＸＰＦ１０６は、請求の範囲のデータトランスポート部の好適な一例に相当する。
このように本実施形態では、契約書や対価の送受信を行うプラットフォームとは別に、ＩｏＴのデータ伝送／交換プラットフォームを設けているので、大量のデータ伝送が可能である。これに対してスマートコントラクトを行おうとしてＰＴＰＦ１１８を採用し、データもＰＴＰＦ上で伝送しようとすると、大きなデータ容量に対応することが困難である。例えばＰＴＰＦ１１８内でブロックチェーンを用いて管理する場合、大量のデータをブロックチェーンの各ブロックに収容することは非常に困難となることが予想される。
その点、本実施形態によれば、図１に示すように、データ蓄積を伴わないデータ流通型のプラットフォームをデータ伝送用に用いているので、スマートコントラクトを利用しつつ、大量のデータの伝送も可能になった。

９．動作例
ブロックチェーンを利用する場合の動作例を図面に基づき説明する。
図１４〜図１８では、これまで説明してきた図３、図４等と異なり、ＤＯ１０２が２個存在し、ＳＰ１０８が２個存在する構成の図が示されている。以下、このような図を用いて動作例の説明を行う。

図１４において、ＡＣ１０４が売りオファーを発行する。また、ＤＢ１１０が買いオファーを発行する。
図１５において、ＰＴＰＦ１１８が、条件マッチングを実行する。
図１６において、ＰＴＰＦ１１８は、条件がマッチングしたので、チャネルＩＤを発行して、これをＤＥＸＰＦ１０６に供給する。具体的には、ＤＥＸＰＦ１０６に対して、チャネルの設定を行うためのアプリを起動して、このアプリでＤＥＸＰＦ１０６に対してチャネルＩＤを発行するためのＡＰＩを操作する。

図１７において、ＤＥＸＰＦ１０６はチャネルが設定されたので、データ流通が開始される。
図１８において、ＡＣ１０４と、ＤＢ１１０との間で決済が実行される。決済は、仮想通貨や暗号通貨で決済を行ってよいし、他の方法で決済してもよい。
このようにして、ＰＴＰＦ１１８と、ＤＥＸＰＦ１０６と、を用いて、データ通信の部分と、契約や決済等の部分とをそれぞれ実行しているので、効率的なビジネスを展開することが可能である。

１０．技術的特徴事項
以上述べたように、本実施形態においては、さまざまな技術的特徴事項を備えているが、それら技術的特徴事項を、ここで説明する。

（１）２層構造
上述したように、本実施形態におけるＰｔＤＸ１１６は、ＩｏＴデータの伝送のデータプレイン（高速路）と、取引を含むメタデータのコントロールプレイン（低速路）とを分離している。この概念図が図１９に示されている。これまで説明してきた取引等メタデータ通信を行うＰＴＰＦ１１８と、ＩｏＴデータ通信であるＤＥＸＰＦ１０６と、の２層構造をなしている。すなわち、ＰＴＰＦ１１８がコントロールプレインであり、ＤＥＸＰＦ１０６がデータプレインである。
したがって、高速・間欠・バルク・非定型等のデータ通信と、低速の随時データ伝送との両方を実現している。

（２）公開プレインと非公開プレインとを分離する。
コントロールプレインのメタデータを、ブロックチェーンによる公開ドメイン上に構築することで、第三者からの閲覧とライセンスの唯一性を実現している。この概念図が図２０に示されている。メタデータを公開されたブロックチェーン上に配置値することによって、参加者全員が参照可能であるにもかかわらず、改竄不能で、正当な権限者のみが改変できる状態を作り出すことによって、誰もが当該データを当該条件によってしか利用できない状況を実現することができる。
つまり、ＰＴＰＦ１１８において、Publicなブロックチェーンを用いて、様々な権利情報が公開される（誰もが閲覧可能な状況にする）。公開された（Publicな）とは、そのブロックチェーンに参加するメンバーの誰もが閲覧できる状態をいう。また、ここで、メタデータとは、情報の類、ライセンスの定義、権利情報等をいう。

（３）サブルーティンによる重畳型データ処理
データの出口をサブルーティンへ入れて処理をさせ、さらに、処理後のデータをＤＥＸＰＦ１０６の入力データとすることによって再帰的な処理が可能となる。
すなわち、ＤＥＸＰＦ１０６の出力データは、ＤＥＸＰＦ１０６の出口に接続されるサブルーティン２０２ｎ〜２０２ｍに与えられる。サブルーティン２０２ｎ〜２０２ｍの出力データは、ＤＥＸＰＦ１０６の入力データとなる。すなわち、サブルーティン２０２ｎ〜２０２ｍは、処理のデータを、ＤＥＸＰＦ１０６の入力に供給する。
したがって、再帰的な処理が可能となる。これらサブルーティン２０２ｎ〜２０２ｍ含む図が図２１に示されている。ここでｎ、ｍは、自然数である。したがって、データの変換やデータの多重化した処理を実現することができる。データフォーマット変換や、インテリジェントな処理等を行うことが可能である。
なお、サブルーティン２０２ｎ〜２０２ｍは、請求の範囲のサブルーティン部の好適な一例に相当する。

（４）マスターブランドセトルメント
ＭａｉｎとなるＰＴＰＦネットワーク１１８ｍが同一ブランド内（マスターブランド配下）の各ブランド間のクロスドメインセトルメントを実施する。その様子が図２２に示されている。図２２に示すように、ＭａｉｎとなるＰＴＰＦネットワーク１１８ｍが複数のブランドドメインを配下に配置している。各ドメインにはこれまで説明したようなＰＴＰＦ１１８とＤＥＸＰＦ１０６とによるデータ取引システム（ブランドＢ１）が形成されている。図２２の例では、ブランドが３種配置されているが、何個存在してもよい。なお、Ｄｏｍａｉｎ下のＤＥＸ（Data Exchange）から見たときのＤＥＸ（Data Exchange）をプリマルＤＥＸと呼ぶ。
つまり、上の実施形態で説明してきたＰＴＰＦ１１８に上位のＰＴＰＦ１１８ｍを設け、複数のＰＴＰＦ１１８の間の取引が（上位のＰＴＰＦ１１８ｍを介して）可能になる。
なお、ＭａｉｎとなるＰＴＰＦネットワーク１１８ｍは、請求の範囲のｍａｉｎデータトランザクション部の好適な一例に相当する。

（５）ＤｅＩＤの公開鍵をブロックチェーン上に置く
ＤｅＩＤ（デバイスＩＤ）に紐付けられた公開鍵をブロックチェーン上に置くことによって、デバイスへのＤｅＩＤのエンベッドがどの段階で行われてもＤｅｖ（デバイス）の秘密鍵は秘匿したままで、ＤＥＸ（Data Exchange）は改竄不能で参照可能な情報を利用することができる。この説明図が図２３に示されている。黒地で表されている部分で、デバイスＩＤの書き込みが行われる。

図２３のcase1では、ＤＰ３０２がＤｅＩＤをデバイスに書き込んでＤＯ１０２に納品する例を表している。すなわち、ＤＭ（Device Manufacture）３００がデバイスを作成して、ＤＰ（Device Provider）３０２に渡す。ＤＰ３０２は、ＤｅＩＤをデバイスに書き込んでからＤＯ１０２に渡している。
図２３のcase2では、ＤＭ３００がＤｅＩＤをデバイスに書き込んでＤＰ３０２又はＤＯ１０２に納品する例を表している。すなわち、ＤＭ（Device Manufacture）３００がＤｅＩＤをデバイスに書き込んでから、ＤＰ（Device Provider）３０２又はＤＯ（Device Operator）１０２に渡す。
図２３のcase3では、ＤＯ１０２がＤｅＩＤをデバイスに書き込んでからデバイスをデプロイする。
本実施形態では、公開鍵をブロックチェーン上に置く（記憶させる）ことによって、いずれの形態をも採用することができる。

１０．ＤＥＸＰＦ１０６の具体例の一つである「ＰＤＥｘｃｈａｎｇｅ」
本実施形態における特徴的な構成の一つであるＤＥＸＰＦ１０６は、種々の伝送システムを利用することができるが、例えば、本願出願人の製品である「ＰＤＥｘｃｈａｎｇｅ」をそのままＤＥＸＰＦ１０６として利用することもできる。ＰＤＥｘｃｈａｎｇｅは、例えばhttps://pd.plathome.co.jp/product/pd-exchange/#pd_1にその詳細が記載されている。
以下、このＰＤＥｘｃｈａｎｇｅについて説明する。
ＰＤＥｘｃｈａｎｇｅは、ＩｏＴアプリケーション開発における共通機能「ＩｏＴデバイスからのデータ集約」と「ＩｏＴデバイスへのコマンド送信」に特化した、データ交換サーバソフトウェア及びクラウドサービスである。

ＰＤＥｘｃｈａｎｇｅの役割
ＰＤＥｘｃｈａｎｇｅは柔軟な配信機能を備えている。例えば、同時に送られてきた「温度」と「湿度」のデータをそれぞれ別のアプリケーションに配信することや、一方のアプリケーションには「温度」のみを配信し、他方のアプリケーションには「温度」と「湿度」の両方を配信することもできる。すなわちデータの振り分けをすることも可能である。
ＰＤＥｘｃｈａｎｇｅの製品構成
ＡＰＩＣｏｎｎｅｃｔ（オープン・プラットフォーム）
ＰＤＥｘｃｈａｎｇｅはＲＥＳＴＡＰＩで操作をすることができる。既存のネットワークとの親和性が良いアプリケーションを素早く開発しリクエスト＆レスポンス型ＡＰＩの他、即時配信を行うリアルタイムＡＰＩも利用可能である。
Ｔｗｏ−ｗａｙＣｈａｎｎｅｌ（双方向通信）
単なるデータの送信だけでは、ＩｏＴデータの価値を十分に生かせない場合もあるが、ＰＤＥｘｃｈａｎｇｅを用いれば、アプリケーションからのコマンドをＩｏＴデバイスに送る双方向通信が可能である。
Ｓｅｃｕｒｉｔｙ（堅牢なセキュリティ）
ＰＤＥｘｃｈａｎｇｅは、SSL/TSSによるデータ送受信路の暗号化を行うことによって、盗聴対策を行っている。また、メッセージダイジェストを利用したデータ改ざん対策もサポートしている。データ交換はＰＤＥｘｃｈａｎｇｅ上で行われ、データは一定期間で完全破棄される。すなわち、ＰＤＥｘｃｈａｎｇｅはデータの蓄積を目的としていない。

Ａｎａｌｙｓｉｓ（記録と分析）
ユーザは、ＰＤＥｘｃｈａｎｇｅのサービスを利用開始した直後から、使用状況レポートを入手できる。使用状況レポートに含まれるデータや、使用状況レポートそのものはＣＳＶ等のレガシーフォーマットによるダウンロードを行うことができる。さらに、管理系ＡＰＩでのデータ取得することも可能である。
Ｃｏｓｔｓａｖｉｎｇ（価値のある開発へ）
ＰＤＥｘｃｈａｎｇｅを利用開始するまでの時間やアプリケーションの開発工数、設備の費用、サービスイン後の運用リソースなどを削減することができ、ＩｏＴビジネスの価値・利益創造を図ることができる。
Ａｎｙｗｈｅｒｅ（クラウド及びオンプレミスに適用することができる）
パブリック・クラウド・サービスやオンプレミス・システムなどのIaaSへインストールして使用することができる。また、ＰＤＥｘｃｈａｎｇｅをインフラシステムとて提供することも可能である。

アーキテクチャ
次に、図面に基づき、ＰＤＥｘｃｈａｎｇｅ４００のアーキテクチャ（構成）を説明する。図２４には、ＰＤＥｘｃｈａｎｇｅ４００の構成図が示されている。同図に示すように、ＰＤＥｘｃｈａｎｇｅ４００は、データの伝送のチャネルを割り当てるChannel Mapper４０２と、ＩｏＴデバイスへＡＰＩであるAPI for IoT Devices４０４と、ＩｏＴアプリケーションへのＡＰＩであるAPI for IoT Applications４０６と、このＰＤＥｘｃｈａｎｇｅ４００へのコントロールを行うためのＡＰＩであるAPI for IoT Management４０８と、を備えている。
Channel Mapper４０２は、上述のように、外部からのコントロールによってＩｏＴデータのチャネルを設定し、所定のＩｏＴデータを指定された宛先へ送出する動作を実行する。
API for IoT Devices４０４は、IoT Devices４１０から送信されてきたＩｏＴデータを受信するＡＰＩである。IoT Devices４１０は、IoT Gatewayでもよい。
API for IoT Applications４０６は、IoT Applications４１２に対するＡＰＩであり、このAPI for IoT Applications４０６を用いて、IoT Applications４１２はＩｏＴデータを受信する。
API for IoT Management４０８は、外部から、ＰＤＥｘｃｈａｎｇｅ４００へのコントロールを行うためのＡＰＩである。図２４では、Management Toolbelt４１４が、API for IoT Management４０８を用いて、ＰＤＥｘｃｈａｎｇｅ４００をコントロールする例が示されている。

ＰＤＥｘｃｈａｎｇｅ４００の特徴的技術
DeID
ＰＤＥｘｃｈａｎｇｅ４００の特徴的な事項の一つに、DeIDが挙げられる。DeIDは、ＰＤＥｘｃｈａｎｇｅ４００上においてＩｏＴデバイスの識別を行う単位となる。フォーマットはＰＤＥｘｃｈａｎｇｅ４００の独自のものではあるが、UUIDv4との互換性があり他のＩｏＴシステムとの親和性を高く保つことができる。
また、DeIDはPrefix部とSuffix部に分かれておりPrefix部はＰＤＥｘｃｈａｎｇｅ４００によって管理されている。これに対して、Suffix部はＰＤＥｘｃｈａｎｇｅ４００とは独立して、独自の設定が可能であり、IPアドレス(ネットワーク部とホスト部)のように管理が可能である。
チャネル
ＰＤＥｘｃｈａｎｇｅ４００では、チャネルという概念を利用してＩｏＴデータの流れを制御しているので、利用開始までの時間やアプリケーションの開発工数、設備の費用、サービスイン後の運用リソースなどを従来と比較して削減することができる。その結果、ＩｏＴビジネスの価値・利益創造の効果を奏する。
DeIDの匿名化
アプリケーションからは、チャネルIDでのみアクセスが可能でありDeIDはアプリケーション側に直接晒されることがない。一見不便のようであるが、このような構成によって、デバイスIDがアプリケーション側に漏洩する可能性を少なくすることができる。
このように、匿名化されているシステム上でデバイスIDがアプリケーションに漏洩する可能性を減少させることができる。IDが特定されるということは、すなわち、デバイス操作を許可したことと同義である。また、DeIDを匿名化することは、アプリケーション側におけるセンシティブ情報の保管コストを下げるという効果も奏する。

データ交換への特化
ＰＤＥｘｃｈａｎｇｅ４００はデータ蓄積を目的としない。データ取得を待つために一時保管は行うが、永続的に蓄積する機能は提供されない。また、いわゆる「キュー」と異なり、データが消去されるのは一時保管期間を経過した場合のみである。このような構成によって、購読管理（読み進めた場所の管理）をデータ取得側で行う必要があるが、その代わり複数のアプリケーションから独立して読み出すことができるため、アプリケーションの小型化が可能となる。
Docker
ＰＤＥｘｃｈａｎｇｅ４００はDockerで動作する。動作環境のコンテナ化によって、物理サーバからIaaSまで同様の環境化でシステム運用が可能となる。スタートアップ時は余っている物理サーバで開始し次第にIaaSへ移行する場合にも適用することができる。このような場合であっても、動作環境に関わるコードを変更することなくマイグレーションをすることができる。また、アップグレードも docker pull コマンドによるDocker imageの更新でより完全にコントロールすることができる。
ＰＤＥｘｃｈａｎｇｅ４００の導入タイプ
ＰＤＥｘｃｈａｎｇｅ４００の導入タイプとしては、２種類存在する。つまり、ＰＤＥｘｃｈａｎｇｅ４００を用いて構築しようとするシステムやソリューションの目的・用途に応じて、クラウド(SaaS)型とオンプレミス型の２種類から、より適したＰＤＥｘｃｈａｎｇｅ４００を選びだすことができる。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

１０……ＰＦ
１２……ＧＷ
１４……デバイス
２０……Ｒ
２２……ＧＷ
２４……デバイス
１００……デバイス
１０２……ＤＯ
１０４……ＡＣ
１０６……ＤＥＸＰＦ
１０８……ＳＰ
１１０……ＤＢ
１１２……Ｂｎｆ
１１４……Ｂ
１１６……ＰｔＤＸ
１１８……ＰＴＰＦ
１２０……Ｂ
１３０……Token（XPT）
１３２……Public Blockchain PF
２００……ブロックチェーン
３００……ＤＭ
３０２……ＤＰ
４００……ＰＤＥｘｃｈａｎｇｅ
４０２……Channel Mapper
４０４……API for IoT Devices
４０６……API for IoT Applications
４０８……API for IoT Managementと
４１０……IoT Devices
４１２……IoT Applications
４１４……Management Toolbelt

Claims

チャネルを外部から設定するためのＡＰＩを備え、外部から前記ＡＰＩを操作することによって、データのチャネルを設定し、所定のサービスプロバイダにデータを送出することができるデータトランスポート部と、
データの取引契約を実行し、前記データトランスポート部にチャネルの設定を行うためのアプリを備えるデータトランザクション部と、
データを提供する提供者のために、前記データトランザクション部に対してデータの売りオファーを発行する取得部と、
データを利用する前記サービスプロバイダのために、前記データトランザクション部に対してデータの買いオファーを発行するデータブローカと、
を備え、
前記データトランザクション部は、前記売りオファーと前記買いオファーとを条件マッチングし、マッチングした場合には、前記データトランスポート部のチャネルの設定を行うための前記アプリを起動し、前記アプリで、前記データトランスポート部の前記ＡＰＩを操作して、前記データトランスポート部に、前記提供者から前記サービスプロバイダにデータを送出するための前記チャネルを設定させ、
前記データトランスポート部は、データの蓄積を目的としない交換機であり、
前記データトランザクション部は、前記取引契約を、ブロックチェーンを用いた分散型台帳を利用して保全及び管理をし、
前記データは、ＩｏＴデータであり、前記提供者は、ＩｏＴデータを提供する、
データ取引システム。
前記分散型台帳は公開されたブロックチェーンを用いている、請求項１記載のデータ取引システム。
前記提供者が提供するデータを得るためのデバイスに紐付けられた公開鍵が、前記ブロックチェーン上に記憶されている、請求項１又は２記載のデータ取引システム。
前記データトランザクション部は、Ethereumのシステムを利用して構成されている、請求項１記載のデータ取引システム。
前記データトランスポート部の出力データを処理し、前記処理後の前記出力データを、前記データトランスポート部の入力に供給するサブルーティン部、
を有する請求項１から４のいずれか１項に記載のデータ取引システム。
前記取得部と前記データブローカとは、前記データトランザクション部において、仮想通貨、又は、暗号通貨を用いて決済する、請求項１から５のいずれか１項に記載のデータ取引システム。
請求項１から６のいずれか１項に記載のデータ取引システムを２個以上と、
前記２個以上のデータ取引システム内の前記データトランザクション部に接続する、前記データトランザクション部とは異なる他のデータトランザクション部であって、前記２個以上の複数のデータトランザクション部の上位のｍａｉｎデータトランザクション部、
を備えるデータ取引システム。