JP2024514859A - ブロックチェーンマイクロトランザクション - Google Patents

Abstract

セキュアなトランザクションを実行するための方法およびシステムであって、方法は、ＵＩＣＣを有するデバイスとサーバとの間でセキュアな通信チャネルを開始するステップであって、セキュアな通信チャネルがＵＩＣＣを使用して確保される、ステップと、サーバにおいて、セキュアな通信チャネルを介してデバイスから、トランザクションを実行する命令を受信するステップと、受信した命令に応答して、トランザクションを実行する要求をサーバから分散型台帳に送信するステップと、要求に応答して、分散型台帳内に格納された公開鍵と秘密鍵のペアを使用して、分散型台帳でトランザクションに署名するステップとを含む。

Description

発明の分野
本発明は、分散型台帳にトランザクションを記録するための、特にデバイスまたはオブジェクトがそのようなトランザクションを安全に生成するためのシステムおよび方法に関する。

発明の背景
異なるエンティティが価値およびデータを交換するために互いに対話および取引することが一般的に必要とされている。しかしながら、これがトランザクションの各当事者にとって安全かつセキュアな方法で行われるためには、トランザクションエンティティ間に信頼のレベルが存在する必要がある。そのような信頼がない場合、強制可能な契約および第三者機関または仲介者などの他の構造および手順が必要である。

暗号通貨は、代替通貨（または私有通貨）の形態であるデジタル通貨である。それらは通常、中央制御された政府発行通貨（例えば、法定不換通貨）とは異なり、非中央集権型または分散型の通貨および／または交換媒体を提供する。デジタル通貨は、ある所有者またはエンティティから別の所有者またはエンティティに取引または送信されてもよく、商品の購入、サービスの購入、またはデータの取得などの任意の目的に使用されてもよい。したがって、デジタル通貨は、従来の通貨の代替手段を表す。

暗号通貨の一例はビットコインであるが、他の多くの暗号通貨システムが考案されている。ビットコインは、Ｓａｔｏｓｈｉ Ｎａｋａｍｏｔｏによって開発され、ビットコイン技術および原理の基本を概説するオリジナルの論文「Ｂｉｔｃｏｉｎ：Ａ Ｐｅｅｒ－ｔｏ－Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍ」はｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆに記載されている。

分散型台帳などの分散型暗号通貨の基礎となる技術は、他のタイプのトランザクションを記録するために使用することもでき、エンティティ間に存在する信頼を必要とせずに、交換の検証可能な履歴または他の形態のデータを形成することができる。ブロックチェーンなどの分散型台帳は、そのような信頼がない場合にトランザクションおよび価値の交換を行うことを可能にする。しかしながら、これは、個々の当事者またはエンティティによる破壊または制御が困難なコンセンサスを形成するために、公開ブロックチェーンの使用を必要とする。これは通常、プルーフ・オブ・ワークに基づいてコンセンサスを得ようとする競争の形をとるが、これ自体が計算および電力の形で非常に高いレベルのリソースを消費する可能性がある。

代替的な手法は、プライベート型ブロックチェーンを使用するが、当事者とプライベート型ブロックチェーン自体の所有者およびコントローラとの間で信頼を築く必要性が再び生じる。

信頼は、エンティティのアイデンティティまたは他の特性を決定および検証することによって築くことができるが、この努力は、オーバーヘッドおよび追加の作業を導入し、コンピュータまたは電気通信ネットワークの非効率性および追加の負荷につながる可能性がある。さらに、そのような検証またはチェックは、多くの場合、別個の情報源に依存し、その各々も検証および承認または信頼される必要があり得る。これは、かなりの帯域幅および処理リソースを必要とし得る。したがって、この手法は、オーバーヘッドが大きな負担にならない、特定の価値を超えて取引する特定のエンティティにのみ適切であり得る。これはまた、互いに新しいエンティティ間の新しい価値およびデータの交換、または低価値であるが大量の一時的な交換を妨げる。モノのインターネットまたは他の低計算量のパワーデバイスを形成するものなどの小型または多数のエンティティまたはデバイスの場合、オーバーヘッドは小さな価値交換を大幅に上回る可能性がある。したがって、これは、特に自律型または監視されていないデバイスのために、価値またはデータパッケージを交換するために必要な効率およびスケーラビリティを制限する。

したがって、これらの問題を克服する方法およびシステムが必要とされている。

発明の概要
方法およびシステムは、ＵＩＣＣ（例えば、ＳＩＭ）を使用してデバイスとサーバ（例えば、デジタルアセットブローカ、ＤＡＢ）との間のセキュアなチャネルを開始する。サーバは、トランザクションを実行するためにこのセキュアなチャネルを介して命令を受信する。サーバは、分散型台帳（例えば、ブロックチェーン）にトランザクションを実行するよう要求または命令を送信し、分散型台帳は、この要求に応答して、格納された公開鍵と秘密鍵のペア（例えば、分散型台帳および／またはデバイスのＵＩＣＣ内）を使用してトランザクションに署名する。これにより、デバイスが１つ以上の分散型台帳とより安全に対話することが可能になり、ウォレット識別子および鍵のより便利で安全な管理も提供される。このシステムおよび方法は、より効率的なトランザクション処理を可能にし、より大量のより低価値のトランザクションで使用され得る。

このデジタルアセットブローカ（ＤＡＢ）ウォレットは、いくつかのウォレットのような機能を束ねて調和させることができる。ＳＩＭ（例えば、ＧＳＭＡ ＩｏＴ ＳＡＦＥ規格）上の公開鍵基盤（ＰＫＩ）によって提供されるこのＤＡＢウォレットは、ハイブリッド方式で異なるブロックチェーンを認証し、その中で取引することができる。ＳＩＭは、ブロックチェーンノードを介してアイデンティティおよび署名機能を直接提供することができる。さらに、ＳＩＭまたはＳＩＭトラスト上のＰＫＩを介してＤＡＢバックエンドサービスまたはミドルウェア（例えば、プロキシサーバ）への信頼できる接続を活用して、ブロックチェーン内、ブロックチェーン全体、および従来の非ブロックチェーン決済ネットワーク上で認証および取引することもできる。

第１の態様によれば、セキュアなトランザクションを実行するための方法が提供され、本方法は、
ＵＩＣＣを有するデバイスとサーバとの間でセキュアな通信チャネルを開始するステップであって、セキュアな通信チャネルが、ＵＩＣＣを使用して確保される、ステップと、
サーバにおいて、セキュアな通信チャネルを介してデバイスから、トランザクションを実行するための命令を受信するステップと、
受信した命令に応答して、サーバから分散型台帳に、トランザクションを実行する要求を送信するステップと、
要求に応答して、分散型台帳および／またはデバイスのＵＩＣＣ（例えば、ＳＩＭ）内に格納された公開鍵と秘密鍵のペアを使用して、分散型台帳内でトランザクションに署名するステップと
を含む。トランザクションは、デバイスで開始されてもよいし、さらなるデバイス（例えば、それ自体のＵＩＣＣまたはＳＩＭありまたはなし）によって開始されてもよい。

任意選択で、ＵＩＣＣとサーバとの間のセキュアな通信は、ＵＩＣＣに格納された公開鍵と秘密鍵のペアを使用して開始されてもよい。これは、ＵＩＣＣ（例えば、ＳＩＭ）がすでに他の目的のためのセキュアなメモリおよびストレージを有し得るので、セキュリティをさらに向上させる。

好ましくは、本方法は、ＵＩＣＣ内で公開鍵と秘密鍵のペアを生成するステップをさらに含み得る。これはすでにＵＩＣＣの機能であり得るので、追加のセキュアなプロセッサは必要ない。

任意選択で、ＵＩＣＣとサーバとの間のセキュアな通信は、共有秘密を使用して開始されてもよい。例えば、これは、限定はしないが、Ｔｗｏｆｉｓｈ、Ｓｅｒｐｅｎｔ、ＡＥＳ、Ｃａｍｅｌｌｉａ、Ｓａｌｓａ２０、ＣｈａＣｈａ２０、Ｂｌｏｗｆｉｓｈ、ＣＡＳＴ５、Ｋｕｚｎｙｅｃｈｉｋ、ＲＣ４、ＤＥＳなどを含む対称鍵であってもよい。

任意選択で、秘密は、
ＵＩＣＣが製造されるときに、ＵＩＣＣ内および電気通信ネットワークコンポーネント内に共有秘密を格納すること、および
電気通信ネットワークコンポーネントがサーバに共有秘密を送信すること
によってＵＩＣＣとサーバとの間で共有されてもよい。

好ましくは、電気通信ネットワークコンポーネントは、ホームロケーションレジスタ、ＨＬＲ（またはコアネットワーク内の別のコンポーネント）であり得る。

有利には、共有秘密は、汎用ブートストラッピングアーキテクチャ、ＧＢＡを使用して生成され得る。

好ましくは、秘密は、
ＵＩＣＣおよびブートストラッピングサーバ機能、ＢＳＦ内で共有秘密を生成すること、および
ＢＳＦがサーバに共有秘密を送信すること
によってＵＩＣＣとサーバとの間で共有され得る。他の共有または交換機構が使用されてもよい。

任意選択で、トランザクションは、デバイスに関連付けられたウォレット識別子と共に分散型台帳に記録されてもよい。

有利には、方法は、セキュアな通信チャネルとは異なる物理通信チャネルを使用してデバイスを検証することによって分散型台帳上のデバイスに関連付けられたウォレット識別子を生成するステップをさらに含み得る。

任意選択で、異なる物理チャネルはＳＭＳであってもよい。
好ましくは、トランザクションはブロックチェーントランザクションであり得る。

任意選択で、トランザクションはクレジットカードまたは銀行取引であってもよい。トランザクションはまた、トークントランザクションまたはブロックチェーン上の他の価値トランザクションであってもよい。

第２の態様によれば、
ＵＩＣＣを有するデバイスと、
公開鍵と秘密鍵のペアを格納する分散型台帳と、
１つ以上のプロセッサと、１つ以上のプロセッサに、
ＵＩＣＣを使用してデバイスとのセキュアな通信チャネルを提供すること、
セキュアな通信チャネルを介してデバイスから、トランザクションを実行するための命令を受信すること、および
受信した命令に応答して、サーバから分散型台帳にトランザクションの実行する要求を送信すること
を行わせるように構成された命令を格納するメモリとを有するサーバと
を備えるシステムが提供され、
分散型台帳は、１つ以上のプロセッサと、分散型台帳の１つ以上のプロセッサに、
サーバからの要求に応答して、格納された公開鍵と秘密鍵のペアを使用してトランザクションに署名させること
を行わせるように構成された命令を格納するメモリとを有する。

任意選択で、分散型台帳のメモリはさらに、分散型台帳の１つ以上のプロセッサに、
デバイスに関連付けられたウォレット識別子を分散型台帳に記録することであって、トランザクションが、デバイスに関連付けられたウォレット識別子を用いて分散型台帳に記録されること
を行わせるように構成された命令を含む。

これは、デバイス（またはデバイスのユーザ）とトランザクションとの間の直接的な関連付けを提供する。間接的な関連付けは、例えば、外部データベース、デバイス（またはＵＩＣＣ）の識別子とトランザクション識別子またはウォレット識別子との間のマッピングまたはルックアップテーブルを使用することによって使用され得る。

任意選択で、分散型台帳のメモリはさらに、分散型台帳の１つ以上のプロセッサに、
セキュアな通信チャネルとは異なる物理通信チャネルを使用してデバイスを検証することによって分散型台帳上のデバイスに関連付けられたウォレット識別子を生成すること
を行わせるように構成された命令を含む。

任意選択で、デバイスのＵＩＣＣは、検証要求に応答する命令を含むセキュアなアプレットを格納するメモリをさらに備えてもよい。

任意選択で、トランザクションはデバイスの識別子に関連付けられる。これは、直接的または間接的な関連付けによるものであり得る。

上述の方法は、コンピュータを動作させるためのプログラム命令を含むコンピュータプログラムとして実装され得る。コンピュータプログラムは、コンピュータ可読媒体に記憶されてもよい。

コンピュータシステムは、中央処理装置（ＣＰＵ）などの１つまたは複数のプロセッサ（例えば、ローカル、仮想、またはクラウドベース）、および／または単一もしくは集合のグラフィックス処理装置（ＧＰＵ）を含み得る。プロセッサは、ソフトウェアプログラムの形態のロジックを実行し得る。コンピュータシステムは、揮発性および不揮発性記憶媒体を含むメモリを含んでもよい。ロジックまたはプログラム命令を記憶するために、コンピュータ可読媒体が含まれてもよい。システムの異なる部分は、ネットワーク（例えば、無線ネットワークおよび有線ネットワーク）を使用して接続され得る。コンピュータシステムは、１つ以上のインターフェースを含むことができる。コンピュータシステムは、例えば、Ｊａｖａ（登録商標）、ＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）（ＲＴＭ）またはＬｉｎｕｘ（登録商標）などの適切なオペレーティングシステムを含むことができる。

上記の任意の特徴は、本発明の任意の特定の態様または実施形態で使用され得ることに留意されたい。

図面の簡単な説明
本発明は、いくつかの方法で実施することができ、ここで、添付の図面を参照して、単なる例として実施形態を説明する。

分散型台帳にトランザクションを記録する方法のフローチャートを示す。 ＳＩＭを有するデバイスを含む、分散型台帳にトランザクションを記録するためのシステムの概略図を示す。 両方ともＳＩＭを有する第１のデバイスおよび第２のデバイスを含む、分散型台帳を使用してセンサデータを配信するためのシステムの概略図を示す。 図１の方法のより詳細な例示的ステップのシーケンス図を示す。 図１の方法のより詳細な例示的ステップのシーケンス図を示す。 図１の方法のより詳細な例示的ステップのシーケンス図を示す。 図１の方法のより詳細な例示的ステップのシーケンス図を示す。 図２ｂの方法のステップの流れを示す概略図である。 図２ｂの方法のステップの流れのさらなる例を示す概略図である。 図２ｂの方法のステップの流れのさらなる例を示す概略図である。 図２のシステムの高レベル機能を示す概略図である。 図２のシステムのいくつかのアーキテクチャ構成要素の概略図を示す。 デバイスおよびＳＩＭ、プロキシサーバおよび分散型台帳を含む、図２のシステムの例示的な実装形態の概略図を示す。 図２のシステムのさらなる例示的な実装形態の概略図を示す。 図５のシステムに従って動作するデバイスのシステムの概略図を示す。 図５のシステムに従って動作するデバイスのシステムのより詳細な概略図を示す。 図６のシステムの例示的な実装形態の概略図を示す。 １つ以上のノードを含む、図２のシステムのさらなる例示的な実装形態の概略図を示す。 図１０のノードの概略図を示す。 図１０のシステムによって実行される方法ステップの概略図を示す。 図２のシステムの例示的な実装形態の概略図を示す。 図５のＳＩＭの例示的な実装形態の概略図を示す。 図５のデバイスの例示的な実装形態の概略図を示す。 図１の方法で使用される鍵を管理するための方法のフローチャートを示す。 図６の例示的な実装形態で使用される構成要素の概略図を示す。 図６の例示的な実装形態で使用される構成要素の対話の概略図を示す。 図６の例示的な実装形態において鍵を生成するために使用される方法ステップを示す概略図である。 図６の例示的な実装形態においてデータを交換するために使用される方法ステップを示す概略図である。 図２のシステム内のデバイスアーキテクチャの概略図を示す。 図２のＳＩＭ内のセキュアエレメントと対話するために使用されるアーキテクチャミドルウェアの概略図を示す。 図１の方法に従ってトランザクションに署名するための手順のシーケンス図を示す。 図２２のＳＩＭのセキュアエレメントを使用してトランザクションに署名するための手順内の方法ステップの概略図を示す。 ＰＫＩを使用し、図２２のＳＩＭを使用するＴＬＳ認証プロセスの概略図を示す。 図２の分散型台帳の例示的な実装形態の概略図を示す。 図１の方法を実装する例示的なユースケースを示す。 データ交換内でオファーを照合するための方法の一部のシーケンス図を示す。 図２８の方法の一部のシーケンス図を示す。 図２のシステム内で使用されるメッセージングシステムの概略図を示す。 図２のシステムの例示的な実装形態の概略図を示す。 図３０のメッセージングシステム内で使用される方法ステップのシーケンス図を示す。 図３０のメッセージングシステム内で使用されるさらなる方法ステップのシーケンス図を示す。 図１の方法の例示的な実装形態のシーケンス図を示す。 図１の方法で使用するためのデバイスをプロビジョニングするための方法ステップを示す概略図である。 図１の方法で使用するデバイスをセットアップするための方法ステップを示す概略図である。 図１の方法で使用するためのデバイスをセットアップするための方法ステップを示す概略図である。 図３６および図３７のデバイスと共に使用するためにユーザを認証するための方法ステップを示す概略図である。 図３６および図３７のデバイスと共に使用するためにユーザを認証するための方法ステップを示す概略図である。 図１の方法の例示的な実装形態の方法ステップを示す概略図である。 図１の方法の例示的な実装形態のさらなる方法ステップを示す概略図である。 図１の方法の例示的な実装形態のさらなる方法ステップを示す概略図である。 図１の方法の例示的な実装形態のさらなる方法ステップを示す概略図である。 図２のシステムの例示的な実装形態の概略図を示す。 図２のシステムの例示的なアーキテクチャ構成要素を示す概略図である。 図２のシステムの一部の例示的な実装形態を示す概略図である。 図２のシステム内のデバイスの例示的な実装形態を示す概略図である。 図２のシステムとの相互作用の例示的な実装形態を示す概略図である。

図面は簡略化のために示されており、必ずしも縮尺通りに描かれていないことに留意されたい。同様の特徴には同じ参照番号が付されている。

好ましい実施形態の詳細な説明
「モノのインターネット」は成長しており、「モノの経済」（ＥｏＴ）に移行しつつある。ＩｏＴデバイスの数は増加しており、大量のデータを生成している。ＩｏＴデバイスおよびスマートサービスは、所有権ドメインにわたって対話および相互運用し、データおよびスマートサービス価値トランザクションをほぼリアルタイムで自動的にサポートする可能性を提供する。これにより、相互運用性および機能性を向上させることができる。

「モノの経済」は、デバイス／サービスが互いに識別し、信頼し、必要に応じて直接またはピアツーピア機能を使用して自動的に価値を取引する能力を必要とする。デジタルＩＤ、連合セキュリティ、ならびにＩｏＴに必要なトランザクションアプリケーションおよびサービスをサポートする分散型台帳、セキュアエレメント、暗号およびデバイスウォレットに及ぶ様々な技術があるが、それらは断片化されており、コストが高く、十分にスケーラブルではない。

図１は、トランザクションを実行する方法１０のフローチャートを示す。ステップ２０において、ＵＩＣＣを有するデバイスとサーバ（例えば、デジタルアセットブローカ、ＤＡＢ）との間でセキュアな通信チャネルが開始される。ステップ３０において、サーバは、セキュアな通信チャネルを介してデバイスから、トランザクションを実行するための命令またはメッセージを受信する。ステップ４０において、受信した命令に応答して、サーバは、トランザクションを実行する要求を分散型台帳（例えば、ブロックチェーン）に送信する。これは、例えば、支払トランザクション、トークントランザクションまたはデータトランザクションであってもよい。ステップ５０で、サーバからのこの要求に応答して、分散型台帳において、分散内（例えば、同じまたは別のブロック内）またはＵＩＣＣもしくはＳＩＭ内に格納された公開鍵と秘密鍵のペアの公開鍵を使用して、トランザクションにデジタル署名する。

図２は、図１を参照して説明した方法を実施するために使用される例示的なシステム１００の概略図を示す。ＳＩＭ（１２０）を有するデバイス１１０、およびサーバ１４０（ＤＡＢ）は、通信チャネルを介して安全に通信する。分散型台帳１５０は、トランザクションを実行する命令をサーバ１４０から受信する。

図２ｂは、分散型台帳１５０にトランザクションを生成または追加するための例示的な方法のシーケンス図を示す。この方法は、図１を参照して説明した方法１０にさらなる詳細を提供する。この例示的な実装形態では、ＳＩＭ１２０間（デバイス１１０を有する）にセキュアなチャネルを確立するための２つの方法が示されている。１つの方法は、そのセキュアな場所１３０内で、ＳＩＭ１２０上に公開鍵と秘密鍵のペアを生成することである。この鍵ペアは、例えばＧＳＭＡ ＩｏＴ ＳＡＦＥ規格を使用して、サーバ１４０へのセキュアな接続に使用される。別の方法は、ＳＩＭ（デバイス１１０を有する）とサーバ１４０（ＤＡＢバックエンド）との間で共有秘密を共有することである。これは、例えば、ＳＩＭトラストプロトコルを備えたＧＢＡサーバを使用することによって達成される。

この設定プロセスが完了すると、サーバ１４０（ＤＡＢバックエンド）は、デバイス１１０からトランザクション命令を受信し、トランザクションをトリガするように分散型台帳１５０（ブロックチェーン）に命令する。これは、例えば、ブロックチェーン内のスマートコントラクトとして実装され得る。図２ｂに示すプロセスは、ブロックチェーン上でのみ記録および完了されたトランザクションをもたらす。これは、価値がブロックチェーン自体の中で実現され得るトークントランザクションとして説明され得る。トークンは、例えば、さらなるブロックチェーントランザクションで使用されてもよい。

図２ｃは、分散型台帳１５０にトランザクションを追加するためのさらなる例示的な方法のシーケンス図を示す。この方法は、図２ｂを参照して説明した方法に類似している（同様の初期または設定手順は、対称または非対称鍵を生成してセキュアな通信を設定するために使用される）が、ブロックチェーンに記録されたトランザクションに加えて、銀行取引やクレジットカードまたはデビットカード取引などの従来の決済レールも含む。従来の（または金銭的な）トランザクションは、通常の銀行およびクレジットカードのインフラストラクチャ内で実行されるが、このトランザクションもブロックチェーンにログまたは記録される。ブロックチェーン内に格納された公開鍵と秘密鍵のペアは、ＳＩＭまたはデバイスに代わって従来のまたは通貨の（すなわち外部の）トランザクションに署名するために使用される。これは、支払決済トランザクションとして説明することができる。

図２ｄは、図２ｂを参照して説明した方法を使用するシステムの例示的な実装形態の概略図を示す。この例示的な実装形態では、デバイスは車両である。人は、例えばプライマリアカウント番号を使用して、それらに代わってＥＶ充電器に支払う許可を委任する。フリートまたは複数の車両の場合、管理コンソールを使用して、フリート全体で支払いを可能にするアカウントを設定してもよい。ＳＩＭは、各車両内ならびに各充電ステーション内に存在してもよい。この例では、支払いはトークン化されたトランザクションとして分散型台帳１５０内で行われる。トランザクションの詳細および確認を提供するために、各車両と任意の変更ステーションとの間でローカル無線通信（例えば、車両からすべて－Ｖ２Ｘ）を開始してもよい。

図２ｅは、図２ｂまたは図２ｃを参照して説明した方法を使用するシステムの例示的な実装形態の概略図を示す。ここでも、固有のデジタル識別子およびウォレットが、充電の支払いに同意するためにユーザによって設定される。車両がＥＶ充電ステーションに到着すると、ローカル通信（例えばＶ２Ｘ）を使用して車両および特定のＥＶ充電ポイントを識別し、これがトランザクションをトリガする。この例示的な実装形態では、このトリガステップにスマートコントラクトが使用される。料金の支払いはＥＶ充電ポイントで開始され、これは充電量の確認および車の支払い方法の検証を含む。

ＥＶ充電器は、（車両、例えば車の）検証を完了し、スマートコントラクトに示された支払い方法を介して支払いを処理し、スマートコントラクトに概説された量までの充電を完了する。ＥＶ充電器は、そのＳＩＭ上の秘密鍵を使用してトランザクションに署名する。支払い処理および決済が行われる。トランザクションのアカウントまたは当事者に対する確認が行われる。これは、分散型台帳１５０に記録されたトークン化されたトランザクションを表す。しかしながら、代替実施形態では、決済レールを使用して通貨取引を開始することができ、分散型台帳はこれらのトランザクションを記録する。

図２ｆは、図２ｂまたは図２ｃを参照して説明した方法を使用するシステムのさらなる例示的な実装形態を示す。この例示的な実装形態では、デバイスはまた、充電ステーションでの充電を取得して支払うことを認可されたフリートの一部であってもよい車両購入である。そうでなければ、このシステムは、トークン化および決済レール（例えば、ＥＭＶ支払い）実装の両方において、図２ｅを参照して説明したものと同様の方法で動作する。

上述のように動作するＤＡＢウォレットは、少なくとも３つのウォレット機能（例えば、ハイブリッド手法として）を可能にし得る。

１）（図示せず）ＳＩＭ上の公開鍵基盤（ＰＫＩ）を介したＳＩＭ／エッジデバイス上の認証および署名機能（古典的なウォレット）：
ａ）ＤＡＢウォレットは、ＳＩＭ技術（ＩｏＴ ＳＡＦＥアプレット、楕円曲線）上のＤＡＢ ＰＫＩを活用して、主要ブロックチェーン（例えば、イーサリウム、ハイパーレジャー、Ｒ３など）への認証を受け、複数のブロックチェーン内でピアツーピアトランザクションを開始および署名する（複数のＰＫＩをＳＩＭセキュアエレメント上で生成できるため）。

ｂ）周知のハードウェアウォレットと同様に、非常にセキュアな方法で機能を提供する。

２）図２ｂ参照：ブロックチェーン内およびブロックチェーン間で取引するためのさらなる機能を提供する信頼できるバックエンドサービスに対する認証。

ａ）ＤＡＢウォレットは、ＤＡＢバックエンドサービスへの認証を受けるためにＳＩＭ上のＰＫＩと統合してもよく、ＳＩＭ／デバイスとＤＡＢバックエンドサービスとの間でトランザクションデータの非対称鍵暗号化を実行し、次にブロックチェーンへの認証およびトランザクションを編成する。これには、追加のｗａｌｌｅｔ－ｔｏ－ｌｅｄｇｅｒプロトコルまたはスマートコントラクトの使用も含まれ得る。

ａ）ＤＡＢウォレットは、ＤＡＢバックエンドサービスへの認証を受けるためにＳＩＭトラスト／ＧＢＡと統合してもよく、ＳＩＭ／デバイスとＤＡＢバックエンドサービスとの間でトランザクションデータの対称鍵暗号化を実行し、次にブロックチェーンへの認証およびトランザクションを編成する。これには、追加のｗａｌｌｅｔ－ｔｏ－ｌｅｄｇｅｒプロトコルまたはスマートコントラクトの使用も含まれ得る。

３）図２ｃ参照：従来の非ブロックチェーン決済ネットワークにアクセスするためのさらなる機能を提供する信頼できるバックエンドサービスに対する認証。

ａ）ＤＡＢウォレットは、（上記（２）で説明したように）ＳＩＭ上のＰＫＩおよびＳＩＭトラストを活用して、ＤＡＢバックエンドサービスを介して従来の決済レールへの認証を受ける。外部支払いサービスプロバイダがＤＡＢによって使用され、（ＡＰＩを介して）従来のトランザクションをトリガする。

ｂ）ＤＡＢウォレットは、ＳＩＭおよびＳＩＭトラスト上のＰＫＩを活用して（（２）で説明したように）ＤＡＢバックエンドサービスを介してトークン化されたプライマリアカウント番号（ＰＡＮ）への認証を受け、そこでクレデンシャルがデバイスに委譲され、処理および決済をトリガする。

ＤＡＢウォレットは、上述のように（２）と（３）の組み合わせを実行し、ＰＡＮ準拠のスマートコントラクト、およびＤＡＢサービス上でビジネスロジックを実行してフローを開始する従来のトランザクションを含むブロックチェーンを介して、スマートコントラクトおよびオラクルと対話することができる。したがって、ＤＡＢウォレットは、言及された機能のすべてを１つの解決策にまとめる「複数のウォレット中のウォレット」として見ることができる。

図３は、前述のシステムの高レベル機能を概略的に示す。
ＵＩＣＣ（ＳＩＭ）
システム内の役割：信頼のチェーン（顧客のアセットとしてのＳＩＭ）にセキュアなエントリポイントを提供する。本開示を通して、ＳＩＭおよびＵＩＣＣという用語は、アプリケーションおよびアプレットと同様に交換可能に使用され得る。

バリアント：
・好ましくはＧＳＭＡ ＩｏＴ ＳＡＦＥアプレットをサポートする、ＳＩＭ上のセキュアエレメント、または
・３ＧＰＰ（登録商標）汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラスト。

システムの異なる実装形態が存在する。一実装形態では、ＳＩＭまたはＵＩＣＣアプレットは、１つ以上の暗号鍵ペアを生成する。別の実装形態では、ＳＩＭまたはＵＩＣＣは暗号材料でプロビジョニングされてもよい。例えば、これは３ＧＰＰ ＧＢＡを使用することができる。しかしながら、全体を通して説明する特徴および実装形態の例または組み合わせのいずれも、いずれかまたは両方の実装形態と共に使用することができる。

デバイス
システム内の役割：上位層に統合器を提供し（デジタルアセットブローカ、ＤＡＢ、管理コア）、通信を調和させる（異なる電気通信ネットワークからのＳＩＭまたは非ＳＩＭデバイスについても）。デバイスは、例えば、単純なＩｏＴデバイス（例えば、需給計器）から車両まで様々な形態をとることができる。

構成要素
・ＩｏＴ ＳＡＦＥアプレット用ＤＡＢミドルウェア、または
・ＳＩＭトラスト用ＤＡＢミドルウェア、
・貨幣化可能イベント検出のためのセンサデータ抽出
ＤＡＢ管理コア
エコシステム内の役割：オンチェーンおよびオフチェーン機能を使用するためのＤＡＢシステム内の対話の仲介。

構成要素
・フローオーケストレーションエンジン
・共通ＡＰＩ
ＤＡＢ管理サービス
エコシステム内の役割：ＭＶＰ（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡ、ＰａｙＰａｌ）のためのフローの簡素化およびＤＡＢのカスタマイズ。

構成要素
・カスタマイズされたオフチェーン処理（オフチェーン）
・カスタマイズされたＡＰＩ
ＤＡＢブロックチェーンサービス
エコシステム内の役割：ＤＡＢ対話をブロックチェーン言語に変換するコネクタを提供する。

構成要素
・モノの台帳（Ｌｅｄｇｅｒ ｏｆ Ｔｈｉｎｇｓ）
・ＤＡＢエクスチェンジ
・スマートコントラクトエンジンを含むブロックチェーンハブ
アーキテクチャ構成要素
図４は、システムおよび方法の様々なアーキテクチャ構成要素を概略的に示す。

ＩｏＴ ＳＡＦＥアプレットの実装は便利な機能を提供するが、ＧＢＡプロビジョニング（例えば、Ｖｏｄａｆｏｎｅ ＳＩＭトラスト）の使用は、既に展開されている可能性があるレガシーＳＩＭのシステム内での使用を可能にする。したがって、（システム内で同時にまたは別々に機能することができる）両方の実装形態の組み合わせは、できるだけ多くの参加者がシステムを使用することを可能にする。デバイスファームウェアは、レガシーデバイスのために無線で更新することができ、したがって、ＧＢＡ実装（例えば、ＳＩＭトラスト）は、デバイス内のＵＩＣＣまたはＳＩＭを変更することなく使用することができる。

図５および図６は、システム１００による両方の実装形態の使用を高レベルで示す。機構は独立しているが交換可能であり、異なるユースケースに適している場合がある。新規およびレガシーＳＩＭに柔軟性を提供するだけでなく、各実装オプションには異なる利点がある。例えば、銀行および公共サービスは、対称鍵をサポートするので、図６に示すＧＢＡ実装（例えば、ＳＩＭトラスト）と対話することを好む場合がある。図５に示すＳＩＭアプレット実装（例えばＩｏＴ ＳＡＦＥ）は、中間またはプロキシサーバ１４０を必要とせずにＵＩＣＣまたはＳＩＭによってトランザクションに直接署名できるため、改善されたブロックチェーン対話を提供する。したがって、両方の機構は、互いに企図し、特定の技術的要件を満たす。

高いレベルでは、これらの２つの機構の主な違いは暗号手法にある。ＩｏＴ ＳＡＦＥアプレットは、主に非対称暗号化（ＰＫＩとしても知られる）のための鍵を格納および管理するためにＳＩＭ上のセキュアエレメントを使用し、公開鍵と秘密鍵のペアが生成および格納される。ＧＢＡ（例えば、ＳＩＭトラスト）手法では、ＳＩＭとエンドポイント（例えば、ＤＡＢサーバなどのサーバ）との間の対称暗号化を確立するためにモバイルネットワーク機能が使用される。

非対称暗号化またはＰＫＩは、公開／秘密鍵ペアを使用してｈｔｔｐｓおよびサーバ間の他の接続を保護するために多くのＩＴインフラストラクチャによって使用される技術である。

図７および図８は、ＳＩＭ １２０と共に実行されるＩｏＴ Ｓａｆｅアプレットを使用して、ＩｏＴデバイスとサーバとの間でセキュアな通信チャネルがどのように設定され得るかを概略的に示す。図８は、デバイスがサーバとのセキュアな接続をどのように開始するかをより詳細に示す。

デバイスには、クライアントＰＫＩ証明書（例えば、ＵＩＣＣまたはＳＩＭ内）が事前プロビジョニングされる。図９に示す例では、デバイスは車両であるが、モバイルまたはその他の任意のデバイスであってもよい。クライアントＰＫＩ証明書は、好ましくは、認証機関によって調達され署名されたパブリックトラスト証明書である。サーバは、同様のサーバ証明書を保持している。通信チャネルがクライアントによってサーバに対して開始されると、両方の当事者が認証機関（ＣＡ）を使用して互いを認証して他方の当事者の正当性を確認する交換が行われる。

ＣＡを使用して実装される機構は、一緒に使用される鍵のペアを利用し、一方は暗号化し、他方は解読する。鍵は、第１の暗号化関数を実行するいずれかで使用することができ、他方の鍵は復号化演算を実行するために使用することができる。これらの機能を実行する２つの異なる鍵の非対称性のために、これはしばしば「非対称」暗号と呼ばれる。これらの鍵の一方は公開されており、他方は秘密である。公開暗号化システムでは、受信者の公開鍵を使用して誰でもメッセージを暗号化することができるが、受信者のみが秘密鍵を使用してメッセージを復号することができる。

暗号化手法とは別に、ＩｏＴ ＳＡＦＥに基づく解決策は、分散型台帳（例えば、ブロックチェーン）関連環境で使用され得るさらなる機能を容易にするいくつかの追加機能を提供する。

対称暗号化アルゴリズムは、暗号化と復号化の両方に同じ暗号鍵を使用する。鍵は、実際には、個人情報リンクを維持するために使用することができる２者以上の当事者間の共有秘密を表す。両方の当事者が同じ秘密鍵にアクセスできるという要件は、非対称暗号化と比較して、対称鍵暗号化の主な欠点の１つである。モバイル通信空間では、この解決策は、電気通信ネットワークサービスへの接続を有するモバイルＳＩＭを含むデバイスによって促進される。携帯電話は、元々ＩｏＴデバイス空間に存在する多くの要件を有し、これらの問題に対する標準ベースの解決策を使用する。これらは、２０年を超える期間にわたって開発され、精査されており、したがって、多くのエンティティおよび組織によって信頼され得る。

電話機器が移動セルラネットワークに接続すると、電話機器は、
・モバイルネットワークとの間で認証すること、および
・モバイルネットワークとの通信を暗号化するために使用できる鍵に同意すること
を含む少なくとも２つのアクションを実行する。

これは、典型的には、標準ベースの認証および鍵合意（ＡＫＡ）プロトコルを使用して達成される。したがって、ＡＫＡプロトコルは、モバイル機器（ローミングまたはその他）と（場合によっては信頼されていない）セルラネットワークとの間に信頼を作り出し、その結果、２つの当事者は機密保護を伴って通信することができる。

この代替技術は、例えばＳＩＭトラストのＶｏｄａｆｏｎｅ実装などの汎用ブートストラッピングアーキテクチャ（ＧＢＡ）として形式化されている同じＡＫＡプロトコルを使用するが、従来のセルラ使用事例とは異なり、信頼は、ユーザまたは顧客の直接制御下でデバイスとアプリケーションプラットフォームとの間に作成される。

図１３は、このＧＢＡ実装を示す。ＵＩＣＣまたはＳＩＭがアプリケーションサーバへの標準モバイル接続を作成している間、ＡＫＡプロトコルは、デバイスと訪問先モバイルネットワークとの間の機密保護された通信を作成するために使用される。ＳＩＭトラスト（ＧＢＡプロトコルを使用）は、ＡＫＡフローを繰り返してデバイスとアプリサーバとの間の対称暗号化を作成することによって別の信頼層を追加する。その結果、２つのエンドポイント間の通信のための相互に認証されたセキュアなチャネルが得られる。

図１０は、個々のデバイスが分散型台帳ネットワーク内のノードと通信する例示的なネットワーク構成を示す。このネットワーク構成は、特定の暗号化方式（例えば、対称暗号化または非対称暗号化を使用することができる）から独立していてもよい。図１１は、これらの個々のノードの形態を概略的に示す。１つ以上のノードがネットワーク内に存在してもよい。

より詳細には、図１０および図１１は、以下の特徴を示す。ＳＩＭ上（デバイス内）またはノード上のセキュアなアプレット（例えば、ＤＬＴアプレット）は、鍵を安全に生成および保持する。これらの鍵は、（ブロックチェーンを使用した）セキュアな価値交換に使用されるウォレット、証明書、および／または他のモードのデジタルトラストの表現であり得る。セキュアなアプレットは、論理的には、ホーム加入者サーバ（ＨＳＳ）のハードウェアセキュアモジュール（通信会社または事業者のコアネットワークの奥深くにある既存のネットワークエレメント）の拡張であってもよい。ＳＩＭ上のセキュアなアプレットとのＨＳＳの関係は、ＳＩＭと直接セキュアな通信チャネルを作成するために使用されるマシンであり得る別の既存のネットワークエレメント（例えば、無線ＯＴＡサーバ）によって管理され得る。Ｔｅｌｃｏノードは、例えば、セキュアなアプリケーション配信、更新、許可、およびデコミッショニングアクティビティのライフサイクルを管理するために必要な証明書を作成および管理するために、各ＤＡＢノードの非中央集権型機関との管理で動作する分散型台帳技術（ＤＬＴ）ノータリーの役割を果たす。

ｔｅｌｃｏノードはまた、システム（例えば、ＤＬＴセキュアサービス）によって提供されるサービスのＣＡ（認証機関）としても機能する。ＨＳＳの強化されたセキュリティがＤＬＴセキュアサービスを介してＳＩＭに拡張されると、ＤＡＢ ＤＬＴはＳＩＭおよび格納された鍵を使用して新しいコンセンサスプロトコル（「プルーフ・オブ・セキュアＳＩＭ」）を作成し、ＳＩＭは、ネットワーク全体にわたる高価で高処理のプルーフ・オブ・ワーク／ステークタイプの処理を必要とせずに、各トランザクション時にシステム（ＤＡＢ）上でその有効性を証明するように求められる。これにより、各ＤＡＢノードが軽量になり、ＳＩＭの計算要件が制限される（ＰＵＢ／ＰＲＶ鍵は非同期的に生成され、トランザクション開始時点で検証のためにＤＡＢ ＤＬＴに提供され得るため）。

デバイス所有者または他のエンティティは、異なるシステムからの異種デバイスが共通のルートオブトラスト（すなわち、ＳＩＭおよびセキュアなアプレットまたはＧＢＡ対応デバイス）を使用して互いに対話できるように、スマートコントラクトまたは他の条件をプログラムまたは定義することができる。これは、デバイスが対話および取引することを可能にする機構およびプロトコルを提供する。これは、１つ以上のノードと対話する複数のデバイス（およびそれらのＳＩＭ）で大規模に行うことができる。このプロトコルは、従来ＡＰＩを使用して解決されてきたユースケースである、デバイスがトークンをトークンに交換し、さらにトークンとデータを交換することを可能にする。さらに、このようにして有効にされたデバイス（ＤＡＢデバイス）は、アクション（例えば、アクセス制御）からデータストリーム（例えば、第１のデバイスまたは提供デバイスのデバイス位置）に及ぶ価値のためにそれらの１つ以上のウォレット内のトークンを自律的に交換してもよく、二次「親」ノードは、例えば、サービス消費を管理および追跡するためにこれらのウォレットをリチャージすることができる。このシステムは、マイクロペイメントおよびマイクロビリングシステム、ならびに非中央集権型台帳のクレジット／デビットと結合され得る価値交換の要求／送信／決済を提供する。

以下では、図１０の例示的なネットワーク構成を動作させるときにとられるステップを説明する。ここでも、いずれの暗号化方式（対称または非対称）を使用してもよい。以下の番号は、異なる構成要素間で生じる方法ステップを示す図１２に示す番号に対応する。

０．背景：ＡおよびＢは、ＤＡＢ ＮＷに登録されており、互いに価値を交換することを許可されている。

１．ＡおよびＢの所有者は、スマートコントラクトに合意している（すなわち、「データＸをくれたら、Ｙトークンをあげる」）。

２．Ｂが所定のスマートコントラクト（Ｃ）に基づいてＡにデータを要求する。
３．Ｂの要求は、ＤＬＴセキュアＢセキュリティで署名され、Ｄａｐｐ Ｃ（プルーフ・オブ・セキュアＳＩＭ）によって検証される。

４．「購入」トランザクションは、ＤＡＢ ＤＬＴネットワーク上でＢに代わって公開される。

５．Ａは、トランザクション決定の適用可能な要求をダウンロードする。
６．ＤＬＴセキュアＡは、要求（４）を検証する。

７．デバイスＡは、「販売」したいことをＤＡＢ ＤＬＴにシグナリングする。
８．デバイスＡは、センサＡからデータＡを受信してパッケージ化する。

９．ＤＬＴセキュアＡは、パッケージＡに署名する。
１０．Ａは、呼び出されるべきスマートコントラクトＣ上のＤＬＴ呼び出し上の交換を確認応答する。

１１．Ａは、パッケージＡをＢに送る（オンチェーンまたはオフチェーンのいずれか）。

１２．ＤＬＴセキュアＢは、ＤＬＴ、ＤＬＴ記録を更新し、スマートコントラクトＣを使用して決済を開始する。

１３．デバイスＢはＣを満たす。
１４．デバイスＡは、トークン受領を確認にする。

１５．ＤＬＴはＣクロージャを検証する。
１６．デバイスＢはパッケージＡを分析し、アクションＡの実行を決定する。

次の２つのセクションは、２つの実装がどのように動作するかについての詳細を提供する。

ＵＩＣＣアプレット実装は、ＵＩＣＣ（例えば、ＳＩＭ）内のセキュアエレメントを使用する。ＳＩＭは、暗号鍵および通信を保護するハードウェアウォレットとして機能する。この実装は、重要なセキュリティ機能の容易かつ効率的な実装のために、ＳＩＭがＩｏＴデバイスのためのルートオブトラストを提供することを可能にする。ＳＩＭは、トランザクション署名鍵を安全に格納し、セキュアな環境内で安全に暗号アセットトランザクション署名を実行することができる。

図１４は、ＳＩＭおよびＯＴＡサーバのアーキテクチャ設計の概略図を示す。ＳＩＭにはＧＳＭＡ ＩｏＴ ＳＡＦＥアプレットが設けられていてもよい。トランザクション署名用のＳＩＭ暗号化ウォレットを保持することに加えて、これにより、ＧＳＭＡ仕様ｈｔｔｐｓ：／／ｗｗｗ．ｇｓｍａ．ｃｏｍ／ｉｏｔ／ｗｐ－ｃｏｎｔｅｎｔ／ｕｐｌｏａｄｓ／２０１９／１２／ＩｏＴ．０５－ｖ１－ＩｏＴ－Ｓｅｃｕｒｉｔｙ－Ａｐｐｌｅｔ－Ｉｎｔｅｒｆａｃｅ－Ｄｅｓｃｒｉｐｔｉｏｎ．ｐｄｆで定義されているように、ＳＩＭハードウェアのルートオブトラストにバインドされた相互認証されたＴＬＳ接続が可能になる。

ＧＳＭＡ ＩｏＴ ＳＡＦＥベースの解決策は、ＩｏＴ展開のためにチップからクラウドまでのセキュリティを提供する。ハードウェアのセキュアエレメント、すなわち「ルートオブトラスト」を使用して、ＩｏＴ ＳＡＦＥベースの解決策は、エンドツーエンドのセキュリティを提供する。ＧＳＭＡ標準化セキュアエレメントおよびＩｏＴ ＳＡＦＥアプレットの使用は、さらに、異なる企業間の相互運用性およびＩｏＴデバイス製造業者による一貫した使用を保証する。

ＳＩＭ上に位置するＩｏＴ ＳＡＦＥアプレットと外部（例えば、プロキシサーバ、ブロックチェーンなど）との間の通信のために、暗号ミドルウェアライブラリもデバイス内で実行されるが、必ずしもＳＩＭ内では実行されない。

この実装形態では、ＳＩＭとデバイスとの間、ならびにＳＩＭと無線（ＯＴＡ）サーバとの間で標準的な認証機構が発生する。これらの機構はまた、ＳＩＭ上のセキュアエレメントを含んでもよい。これは、アプリケーションおよび／またはＳＩＭをロック解除するための基本的な機構（例えば、ＰＩＮ保護を使用することによって）、ＳＩＭロック機構、ＳＩＭとデバイスアプリケーションとの間の相互認証などによって結合される。ブロックチェーントランザクションは、トランザクションの一部として送信されたデジタル署名を含むプロトコルを使用してブロックチェーンノードによって検証される。

汎用スマートＳＩＭウォレット
ＩｏＴ ＳＡＦＥアプレットを使用することにより、ＳＩＭは、ＳＩＭのセキュアエレメント内の１つ以上の鍵コンテナまたはストレージへのアクセスを提供する。これらのコンテナは、異なるユースケースに使用されてもよく、同じユースケースまたは動作のための複数のアイデンティティを提供するために使用されてもよい。図１５は、ＳＩＭ内の複数のアイデンティティのストレージを概略的に示す。各アイデンティティは、ユーザが異なるアプリケーション内でトランザクションを認証および署名することを可能にするＳＩＭウォレットとして使用することができる。これはブロックチェーンに限定されず、従来の決済レール（例えば、他のデバイスまたは企業との直接通信）などのオフチェーン機構内で使用することもできる。ＳＩＭの無線（ＯＴＡ）更新機能は、特定の実装で使用するための新しいコンテナおよび鍵管理機能の追加を可能にする。

ＳＩＭは、異なるブロックチェーンネットワーク用の鍵に署名するための追加の鍵コンテナでパーソナライズすることができる。好ましい実装形態では、ＳＩＭにはデフォルトで利用可能な３つの鍵コンテナがある。２つのコンテナはＳＥＣＰ２５６ Ｋ１ ＥＣＤＳＡ鍵ペアを保持し、１つのコンテナはＳＥＣＰ２５６ Ｒ１ ＥＣＤＳＡ鍵ペアを保持する。しかしながら、異なる鍵ペアタイプを任意の組み合わせで使用してもよい。

エンドツーエンドの解決策を考慮すると、ＩｏＴ（または他の）デバイス内の、ＳＩＭをハードウェアのルートオブトラストとして使用するＳＩＭ暗号ウォレットは、以下の機能のいずれかまたはすべてを提供し得る。

・ハードウェアウォレット（署名支払い／デジタルアセット送信トランザクション）
・署名されたトランザクションの検証
・セキュアな通信
・機密データのセキュアなストレージ
したがって、ＳＩＭ自体は、以下の機能のいずれかまたはすべてを提供することができる。

・追加の暗号化機能
・ＩｏＴデバイスＩＤメタデータストレージ
・セキュアなバックアップ／復元、鍵管理
・デバイス開始ブートストラップ
ＳＩＭ内で暗号鍵ボールトを使用すると、秘密鍵および秘密の改ざん防止および安全が保たれる。ＳＩＭは、一般に、専用の暗号プロセッサおよび高度に安全なＳＩＭ ＯＳを備えた改ざん防止ハードウェアであり、秘密鍵を安全にするために必要なレベルの保証を提供する。このようにしてＳＩＭに格納された鍵は、ＳＩＭ上で生成され、好ましくはＳＩＭから離れない。

表１は、使用される好ましい暗号アルゴリズムのリストをまとめたものである。他のアルゴリズムが使用されてもよい。

ブロックチェーンおよび暗号通貨ネットワークは通常、それらのトランザクションがピアツーピアまたは参加者のグループ内であるため、非対称暗号に依存する。異なるトランザクション間の参加者のリストは異なり得る。ブロックチェーントランザクションのこのピアツーピアの性質を考えると、対称暗号の使用は実現不可能であり得る。さらに、非対称暗号を使用すると、ブロックチェーンおよびＤＬＴトランザクションは、第三者によって監査可能である。現在のシステム内でＰＫＩを使用することにより、エンティティまたは人が秘密鍵にアクセスすることなくトランザクションを検証することが可能になる。

ＥＭＶトークン
ＥＭＶは、Ｅｕｒｏｃａｒｄ（ＲＴＭ）、ＭａｓｔｅｒＣａｒｄ（ＲＴＭ）、Ｖｉｓａ（ＲＴＭ）の略称であり、決済アプリケーションのための定義された仕様を表し、今日のほとんどの銀行カードチップに実装されている。それは、銀行カードチップ上に安全に格納された認証情報にアクセスすることによって対称暗号と協働する。現在の環境では、ＥＭＶを使用して支払いトランザクションに署名し、それらを既存の決済レールに送信してトランザクションを可能にすることができる。したがって、ＳＩＭウォレットは、支払いアプリケーションのための（対称）鍵値を保持するために使用され、その後デバイスミドルウェアによって使用され、本システムを介したＥＭＶ支払いを容易にする。

（記載されたいずれの実装形態とも使用される）この拡張されたまたはオプションの機能では、これは、ＥＭＶによってブロックチェーンまたは既存の決済レールを使用して支払いを選択するためのオプションをユーザに提供する。セキュリティの観点から、ＳＩＭカードはすでに銀行カードの認証を通過することができる。

複数のウォレット中のウォレット
ＳＩＭは、所望の支払い方法に関連する鍵を提供するために使用される。支払いに使用されるウォレット自体は、ＳＩＭに格納されている必要はない（しかし、格納されていてもよい）。分散型台帳と直接対話するために使用されるウォレットは、別個のエンティティ、サーバもしくはプロキシサーバ、またはブローカ（例えば、ＤＡＢ）によって提供され、特定のユースケースに応じた支払い方法の好みに基づいて選択され得る。

第三者文書は、ＳＩＭ無線（ＯＴＡ）上に展開され得る。デバイス上のウォレットアプリケーションは、アプリケーション（アプレット）のＳＩＭ部分と安全に対話し、（同様にＯＴＡを介して）バインディングを確立する。これは、セキュリティドメインのセキュリティおよび認証プロセス、ならびに外部アプリケーションとの統合のための承認に従う。

鍵管理
トランザクション管理で使用される鍵のライフサイクルを管理するための明確に定義された機構が実装され得る。暗号鍵のライフサイクル管理には、鍵のバックアップ、復元、鍵の失効および更新が含まれ、紛失、盗難、および／または侵入されたデバイスを処理するためのセキュリティポリシーが実装されてもよい。秘密鍵は最も機密性の高いアセットであり、クリアな環境または保護されていない環境ではバックアップされない。ブロックチェーンのトランザクション署名鍵のバックアップおよび復元には、使用されるいくつかの異なる機構がある。

例えば、ビットコインは、シードを生成し、ＢＩＰ３９／ＢＩＰ３２仕様に基づいてシードを使用して鍵ペアを生成するために、人間が読める一連の単語に基づいて決定論的鍵生成を定義する。ＢＩＰ３９の実装は、鍵を復元するために記憶されて再入力され得るニーモニックから鍵を導出することを指定する。ＢＩＰ３２は、シードおよびインデックス値に基づいて鍵を導出する階層決定性ウォレットを定義する。そのような機構は、本システムで使用することができ、図１６に概略的に示されている。

別の例示的な実装形態では、ＳＩＭバックアップボールトサービスは、単一のＳＩＭが完全な値を持たないように、透過的に他のＳＩＭ上に秘密鍵の構成要素または一部をバックアップする。鍵を復元することは、バックアッププロセスで使用されたＳＩＭのクラスタからバックアップされた値（Ｎ個のうちのｋ個）の構成要素を収集することを含む協調努力であり得る。

さらなる例示的な実装形態では、ブロックチェーンスマートコントラクトベースの解決策は、バックアップおよび復元プロセスの複雑さを低減する。例えば、スマートコントラクトアカウントは、指定された条件が満たされるまで、エスクロー機構と同様のデジタルアセットを保持する。ＩｏＴデバイスに関連付けられたアカウントは、マイクロペイメントのみを扱い、デジタル値または暗号通貨を独自に保持しない。スマートコントラクトアカウントは、例えば、いくつかのデバイスが故障しているシナリオを解決するためのルール、およびアカウントを他のデバイスに送信する方法を定義することができる。

汎用ブートストラッピングアーキテクチャ（ＧＢＡ）
汎用ブートストラッピングアーキテクチャ（ＧＢＡ）としても知られている技術仕様（３ＧＰＰ ＴＳ ３３ ２２０）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラストアーキテクチャ。証明書と同様に、ＧＢＡは当事者間の信頼を確立するために使用される。一方、証明書は、暗号機能をサポートするために互いに組み合わせて使用できる異なる鍵ペアを作成するために非対称暗号に依存する。ＧＢＡは、ハードウェアベースの信頼できる実行環境（ＴＥＥ）を使用して対称鍵を格納し、これらの対称鍵を使用して、認証、機密保護、および完全性保護の少なくとも３つの機能をサポートするために使用できる一時鍵を導出する機能を提供する。ＧＢＡ規格に関するさらなる詳細は、ＥＴＳＩ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＴＳ ３３．２２１ Ｖ１４．０（２０１７－０５）に見出すことができる。

ＩｏＴ環境では、ＧＢＡ ＴＥＥはＳＩＭによって提供される。ＳＩＭは、認証鍵導出および鍵合意機能をサポートするための資格情報を格納するために使用される。

対称暗号化には、互いに通信する必要があるすべての当事者間で鍵を配布および共有する必要があるという欠点がある。これを鍵配布問題と呼ぶ。電気通信業界は、ＳＩＭ製造プロセス中に鍵が配布され、対称鍵が２つの場所に格納される対称暗号に依存している。

１．携帯電話またはＩｏＴデバイスであり得るユーザ機器（ＵＥ）に格納されたハードウェアトークンデバイスである加入者識別モジュール（ＳＩＭ）、および
２．認証センタ（ＡｕＣ）上のオペレータコアネットワークの中央にあり、ホームロケーションレジスタ（ＨＬＲ）を介してアクセスされる。

この配布プロセスのセキュリティは、この鍵資料の管理においてＳＩＭ製造業者および携帯電話事業者が従う安全なプロセスに依存している。

しかしながら、この鍵資料の配布に関与するプロセスおよび人々を標的とする多くのエンティティが知られている。アセットを保護するためにＳＩＭに依存する産業は、厳しいセキュリティプロセスおよびベンダ選択を使用することによってこの鍵配布攻撃の問題に対抗してきた。しかしながら、これは費用がかかる可能性がある。

通信フロー
ＳＩＭカードは、アプリケーション層でのエンドツーエンドの認証および暗号化を大規模に実現するために使用できる共有鍵を導出するためのルートオブトラストとして使用される。一般に、このプロセスは３Ｇ ＡＫＡプロセス（ＡＫＡ＝認証および鍵合意）に依存する。ＡＫＡプロセスは、任意のモバイルデバイスがモバイルネットワーク（＞２Ｇ）に接続し、相互認証および鍵合意を実行するときに使用される。図１７および図１８は、ＧＢＡのＳＩＭトラスト実装に使用される通信フローを高レベルで示す。

デバイスとバックエンドアプリケーションとの間にセキュアなチャネルを確立するためのステップは、鍵を生成するステップと、鍵を使用してセキュアなチャネルを介してデータを交換するステップとの２つのステップからなる。

鍵生成プロセス
鍵生成プロセスは、図１９に概略的に示されている。ＳＩＭはデバイス内のデバイスＡＰＩと対話し、デバイスは、コアネットワークと通信しているＳＩＭトラストサーバから対称鍵を取得する。デバイスは、ｈｔｔｐを介してＳＩＭトラストサーバと通信して、対称鍵の形式で共有秘密を導出する。この対称鍵は、認証されてＳＩＭ内に格納される。

鍵を使用してセキュアなチャネルを介してデータを交換する。
共有秘密（対称鍵）が導出されると、それはデータを通信するためのチャネルを保護するために使用され得る。これは、図２０に概略的に示されている。

各ネットワークエンティティを通る通信フローを以下に説明する。
デバイス管理（ＤＭ）クライアントは、汎用認証アーキテクチャ（ＧＡＡ）サーバに鍵を問い合わせる。

ＧＡＡサーバはＳＩＭ（ＡＴ＋ＣＳＩＭ）のアイデンティティを確立する。
一方、ＧＡＡサーバは、待機するようにＤＭクライアントに通知する。

ＤＭクライアントは、待機中に他の作業を処理することができる。
ＧＡＡサーバは、アイデンティティを使用してＵｂＰｒｏｘｙに認証ベクトルを求める。

ＵｂＰｒｏｘｙは要求を検証し、正しいブートストラッピングサーバ機能（ＢＳＦ）にルーティングする。

ＢＳＦはＨＬＲにＡＶを要求する。
ＨＬＲはＢＳＦにＡＶを返す。

ＢＳＦは資格情報を格納し、４０１コードでＵｂＰｒｏｘｙにベクトルのバージョンを返す。

ＵｂＰｒｏｘｙは、同じメッセージおよびエラーコードをＧＡＡサーバに返す。
これはＳＩＭに認証を要求する。

有効な応答（開始時のＤＢ）は、有効な応答が抽出されてＵｂＰｒｏｘｙに送信されることを可能にする。

それは次にそれをＢＳＦに送信する。
それは先にＨＬＲから受信したものに対してメッセージに含まれる応答を検証し、２００応答を送信する。

ＵｂＰｒｏｘｙはＧＡＡサーバに２００応答を返す。
ＧＡＡサーバは鍵を計算し、それをＤＭクライアントに返す。

ＤＭクライアントは、必要に応じて鍵を使用し、そのサーバにＩＤを渡す。
ＤＭサーバが鍵を必要とするとき、ＩＤを使用してＮＡＦを介してＵｂＰｒｏｘｙに問い合わせる。

ＵｂＰｒｏｘｙは、適切なＢＳＦに鍵要求を送信する。
それは鍵を計算し、それを返す。

ＵｂＰｒｏｘｙは鍵をＤＭサーバに返す。
ＤＭサーバは必要に応じて鍵を使用する。

ＳＩＭトラストから（例えばＶｏｄａｆｏｎｅから）開始して、デバイス側のミドルウェアは、デバイスがネットワーク内のＳＩＭとＳＩＭトラストプラットフォーム（ブートストラッピングサーバ機能、ＢＳＦ）との間でメッセージを送信することを可能にする。デバイスは、ＳＩＭトラストデバイスライブラリをサポートし、統合ソフトウェアライブラリ（ＤＤＫ）を有する。バックエンド側では、アプリケーションがＡＰＩハブを介してアプリケーション処理インターフェース（ＡＰＩ）呼び出しを使用してＳＩＭトラストプラットフォームから共有鍵を取得する。

特定のグローバル・データ・サービス・プラットフォーム（ＧＳＤＰ）は、特定のＳＩＭカードまたはＩＭＳＩ範囲に対してＧＢＡ（例えば、ＳＩＭトラスト）を有効にすることができる。

デバイス
汎用アーキテクチャ
ＳＩＭとＤＡＢとの間の統合器層としてデバイスを使用するために、例示的に４つの相互連結された構成要素を設けることができる。

ＳＩＭ中心：ＳＩＭカード（セキュアエレメントと、暗号鍵を格納し、トランザクションおよびデータを認証および署名することができるハードウェアコンポーネントとを含む）。

ＳＩＭ製造業者によって提供されるライブラリ：接続されたアプリケーション（例えば、記載された暗号ミドルウェア）による使用のためにＳＩＭの機能を公開するライブラリのセット。

ミドルウェア：ＳＩＭ製造業者のライブラリを直接組み込むことができないアプリケーション、またはデバイスの外部で実行されるアプリケーションおよびデバイス（例えば、データ収集ネットワーク）のためのＳＩＭアプレットのインフラストラクチャ機能を公開するミドルウェアコンポーネント。

イベント検出：ＤＡＢサービスの残りの部分と、またはブロックチェーンおよびマーケットプレイスおよび／またはエクスチェンジのいずれかと直接、イベントを検出および取引するアプリケーション／アルゴリズム。

これらの構成要素は、図２１に概略的に示されている。
本サービス、およびＧＤＳＰ（管理されたＩｏＴ接続性のためのＶｏｄａｆｏｎｅのグローバルデータサービスプラットフォーム）、ＳＩＭトラスト、またはＩｏＴ ＳＡＦＥなどの既存の機能の使用と共に、デバイスは、ブロックチェーンウォレットおよび信頼された認証者の機能を果たすエッジ統合ポイントと見なすことができる。それらはまた、セキュアな自律的イベントを提供する能力、または単純なハードウェアセキュアモジュール（ＨＳＭ）として使用される能力を開く。

ミドルウェアは、デバイスがトランザクションエコシステムに円滑に参加することを可能にし、アプリケーションが製造者ライブラリを組み込み、鍵プロビジョニングおよびトランザクション署名のためにＳＩＭ機能を消費することを可能にする。接続されたデバイスの外部で実行されるアプリケーションは、これらの機能を利用して、そのＡＰＩを介してミドルウェアにアクセスすることもできる。

デバイスは、直接読み取りから計算分析（例えば、貨物占有評価）までの範囲のデータを処理または収集し、（ＳＩＭの場合はＰＫＩで、）暗号化され、ＳＩＭカードの秘密鍵で署名されると、任意のブロックチェーンにトークン化するか、または垂直横断的な使用のためにプラットフォーム内の他の場所に格納することができる。

ＳＩＭ上のセキュアエレメント用ミドルウェア
図２２に示すような典型的なＩｏＴ展開は、機密データおよびデバイス認証のセキュアな送信を提供するＧＳＭＡ ＩｏＴ ＳＡＦＥから直接利益を得ることができる。それにもかかわらず、ＳＩＭアプレットとアプリケーション側との間の通信を容易にするために、デバイス上の上述のミドルウェアが必要とされる。

アーキテクチャ
ＳＩＭ上のセキュアエレメント用ミドルウェアは、モジュール式アプリケーションを介して異種のアプレット管理を抽象化し、デバイスとデジタルアセットブローカ（ＤＡＢ）サービスプラットフォームとの統合を可能にする。それは、製造業者に関係なく、アプレット管理のための統一された単一のＲＥＳＴｆｕｌ ＡＰＩ（ＳＩＭサービスＡＰＩ）を提供する。

ＳＩＭ機能をデバイスに公開するために、暗号ミドルウェアライブラリは、アプレット実行プラットフォームを提供し、それとインターフェースする。ライブラリは、Ｊａｖａ（登録商標）、Ａｎｄｒｏｉｄ、またはＳｗｉｆｔ用のＯＳレベルＣライブラリおよび／またはフレームワーク対応モジュールを含むことができ、（展開、削除、更新など）アプレット自体を管理するための方法、ならびに各々によって利用可能にされる動作を提供する。ＤＡＢミドルウェアコンポーネントの概要を図２２に示す。

ＳＩＭサービスＡＰＩは、前述の統一された動作を公開するベースエンドポイントのセットであり、各受信された要求に対して、暗号化コアは、例えば外部または組み込まれたＪａｖａライブラリであっても、第三者ベンダ統合オプションと対話するために必要なステップを編成する役割を果たす。これらの各々は、アプレット管理および利用のための独自のロジックフローを備えているので、個々のアダプタコンポーネントは、ＤＡＢミドルウェアプロバイダコモンズ層によってインターフェース接続され得る。これにより、異なる製造業者によって提供される動作が利用可能になる。

実装
例示的な実装形態では、ＳＩＭカードのセキュアエレメント内で実行されるＩｏＴ ＳＡＦＥアプレットと整列した２つのデバイス構成が提供される。

１．携帯電話で実行されているＤＡＢアプリケーションは、ＤＡＢサービスによって指示されたようにデータセットに署名して検証するために、組み込まれたＡｎｄｒｏｉｄライブラリを介してそのＳＩＭカードに直接アクセスする。

２．４Ｇ接続された自動車用Ｍ２Ｍルータ（テストでは、ＲａｓｐｂｅｒｒｙＰｉおよびＶｏｄａｆｏｎｅ ＵＳＢ Ｃｏｎｎｅｃｔ ４Ｇ ｖ２ドングルを使用してシミュレートされるが、他の適切なハードウェアを使用してもよい）はＳＩＭを含むが、ＤＡＢミドルウェアを介してその暗号化機能を他のアプリケーションに公開する。

実装されたＤＡＢミドルウェアは、以下の例示的な技術を使用する。
Ｓｐｒｉｎｇ Ｂｏｏｔ、
ＯｐｅｎＡＰＩ、
Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）、および
ｉｏｔ－ｓａｆｅミドルウェア。他の技術が使用されてもよい。

１つの例示的な実装形態では、Ｊａｖａ Ｓｐｒｉｎｇ Ｂｏｏｔは、製造業者ライブラリとの多数の可能な統合シナリオをカバーする。これはまた、それらがＪＶＭを実行することができる限り、スマートデバイスまたはＩｏＴゲートウェイを含むいくつかの種類のデバイスにそれを含める可能性を開く。ＣＰＵおよびメモリが制約され得るローエンドデバイスの場合、ＪＶＭを使用することは最も効率的な実装ではないが、ハードウェアの違いを抽象化する。

これは、提供される各ライブラリのために拡張することができる構成可能モジュールに分割することができ、コードモジュールを直接インポートすること、またはＯＳレベルのライブラリと対話すること（例えば、ＳＩＭ製造業者によって提供されるＣライブラリがＪＮＩ外部機能インターフェースを介してインターフェース接続される必要がある場合）のいずれかによって、統合方法のより容易な統合を提供するための手法である。これは、通信ユニットに接続された同じデバイス上で実行されるスタンドアロンアプリケーションとしてインスタンス化されてもよく、またはイベント検出ソフトウェア（例えばＪａｖａベースの場合）に組み込まれてもよい。

ＳＩＭにインストールされたＩｏＴ ＳＡＦＥアプレットによって利用可能にされる暗号化機能に関する、４つの例示的なＳＩＭサービス動作を定義することができる。これらの動作は、Ｔｈａｌｅｓ暗号ミドルウェアＣ＋＋ライブラリによって利用可能にされたＡＰＩメソッドの非常に類似したシグネチャをミラーリングしている（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＴｈａｌｅｓＧｒｏｕｐ／ｉｏｔ－ｓａｆｅ－ｍｉｄｄｌｅｗａｒｅも参照）。Ｔｈａｌｅｓによって提供される暗号ミドルウェアライブラリは、それ自体で２つの方法またはコンパイル、すなわち、通常のＡｎｄｒｏｉｄアプリ内からの直接アプレット通信用のＪａｖａ Ａｎｄｒｏｉｄライブラリ、または上述のミドルウェア手法に適したＣ＋＋ビルドで使用することができる。

ＤＡＢミドルウェアＡＰＩ
例示的な実装形態では、ＳＩＭにインストールされたＩｏＴ ＳＡＦＥアプレットによって利用可能にされる暗号化機能に関するＳＩＭサービス動作は、公開鍵を取得するかまたはメッセージに署名する必要性に応じてアプリケーションによって呼び出される。それらはすべて「コンテナ」ベースの手法に従い（「コンテナ」は、各々がクライアント証明書および鍵ペアを保持するセキュアなメモリ空間である）、展開された各ＤＡＢユースケースは、それがどの鍵タイプまたはデジタル署名アルゴリズムを必要とするかを認識することができる。したがって、ＤＡＢミドルウェアを呼び出すときにどのパラメータ／コンテナを使用するかを認識することもできる。

一例では、ＡＰＩを以下のように簡単に要約することができる。
／コンテナ：ＳＩＭのコンテナに関する情報をリストする、
／証明書：特定のコンテナのクライアント証明書を取得する、
／公開鍵：特定のクライアント証明書／コンテナの公開鍵を読み取る、および
／署名：特定のクライアント証明書／コンテナを使用してメッセージに署名する。

このビジネスロジックを図２３に示す。
アプリケーション
ＳＩＭウォレットを用いたトランザクション署名
ブロックチェーン、暗号通貨ネットワーク、および他のマイクロペイメントの解決策は、トランザクションに署名するノードの能力に依存している。これらのトランザクションのこのピアツーピアの性質により、ノードがトランザクションに参加したことを証明して、否認されないことを保証できることが重要である。したがって、ブロックチェーンアドレスに関連付けられた秘密鍵を安全な場所（理想的には、改ざん防止暗号モジュール）に保持することが重要である。

ＤＡＢミドルウェアが用意したトランザクションは、ＳＩＭに安全に保存された秘密鍵を用いて署名される。この例を図２４に概略的に示す。

ＴＬＳ認証
ＳＩＭ（例えば、ＩｏＴ ＳＡＦＥ ＳＩＭ）に安全に格納されたクライアント鍵およびサーバルート証明書は、ＤＡＢブロックチェーンアプリケーションをサポートするためだけでなく、デバイスとクラウドで実行されているサービスとの間の相互認証されたＴＬＳセッションを実行するためにも使用できる。これを図２５に概略的に示す。

ＤＡＢミドルウェアはまた、ＳＩＭにインストールされたアプレットの鍵生成、ウォレット管理、および管理（インストール、削除など）に対する制御を配信することができる。これは、例えば、新しい鍵ペアを生成するため、またはデジタル署名アルゴリズムを修正するために、ＩｏＴ ＳＡＦＥアプレットに対する制御を公開することを伴い得る。

ＳＩＭおよびデバイス製造業者の多様性のために、ＤＡＢミドルウェアは、複数の言語およびオペレーティングシステム用のソフトウェア開発キット（ＳＤＫ）として利用可能であり、ＯＥＭが独自のデバイスにそれを円滑に組み込むことを可能にする。そのＪａｖａベースの性質を考えると、別のオプションは、それをＪａｖａカード技術に移植し、すぐに使用できるＤＡＢアクセス可能性のためにすべてのＳＩＭに予めインストールされ得る単一のアプリケーションを配信することを含む。

ＳＩＭサービスＡＰＩは、（許可されている場合には）ＤＡＢプラットフォームに接続されたアプリケーションアクセラレータまたは第三者アプリケーションによる直接デバイス管理のためにＤＡＢ ＡＰＩインベントリで利用可能である。好ましくは、これは、それ自体のユースケースで取引しているデバイスを制御するために、各ＤＡＢサービスインスタンスによって消費され得る。

イベント検出のためのセンサデータ抽出
例示的な実装形態では、ＩｏＴ展開は、様々な機能を有することができるデバイスをエンドノードとして使用することができる。これらは、以下を含むことができる。

センサデータを上位層（クラウドまたはサーバ）に直接転送する、または
同じ機能を実行するゲートウェイと通信する。

センサデータは、例えば、デバイス内で発生し得る。
スマートデバイスおよびセキュアエレメントはますます普及しており、結果として得られるデータに基づいて知識を抽出したりアクションを生成したりする能力は、ＩｏＴの自律性の鍵となりつつある。データセットを認証する能力、検出アルゴリズムを実行するアプリケーションは、ＳＩＭ暗号化アプレットにアクセスするための互換性のあるライブラリを直接組み込むか、またはＤＡＢミドルウェアを使用して選択可能な秘密鍵で情報に署名することを可能にし、変更できないデータセットをもたらすことができる。

ＤＡＢデバイスはまた、ＤＡＢ駆動のユースケース（例えば、検出アルゴリズム展開、ウォレット管理など）で機能することができるデバイス側機能を展開するための制御点として機能し得る。ＤＡＢ駆動デバイスは、ＤＡＢサービスがそれらの検出ソフトウェアおよびＳＩＭアプレットを管理するためにアクセス可能であり得る。

ＤＡＢフレームワーク
例示的な実装形態では、ＤＡＢサービスは、ＤＡＢスタックのインスタンス化されたコンポーネントであり、ＤＡＢエコシステムのトランザクションおよび認証プラットフォームとして機能する。それは、ＩｏＴデバイスがサービス／データの価値を取引する機能を提供し、モバイルＩｏＴデバイス、複数のタイプのブロックチェーン技術、および任意の第三者外部システム間の接続性を処理する。このために、ＤＡＢサービスは、トランザクションコミッタル、デジタルアイデンティティ管理、および第三者サービスアクセスのための、ユースケースオーケストレーションのセットアップのためのＲＥＳＴベースのＡＰＩを提供することができる。

好ましくは、システムはＪａｖａ Ｓｐｒｉｎｇ Ｂｏｏｔフレームワークを使用する。これにより、ほとんどのオンプレミスまたはクラウドベースのマシンで実行可能なモジュール性が可能になる。これはまた、ライブラリ、ドライバ、および通信スタックであっても、異なる種類のソフトウェアおよびハードウェアアプリケーションと相互接続するための柔軟な環境である。しかしながら、他のフレームワークが使用されてもよい。

例示的な実装形態では、ＤＡＢサービスは、以下の技術を使用することができる。
Ｓｐｒｉｎｇ Ｂｏｏｔ、Ｗｅｂ３Ｊ、ＯｐｅｎＡＰＩ、Ｆｉｒｅｂａｓｅ Ｊａｖａ ＳＤＫ、Ｓｐｒｉｎｇ Ｑｕａｒｔｚ、Ｌｉｑｕｉｂａｓｅ、フェイルセーフＳＤＫ、ＪＪＷＴ ｌｉｂ、Ｐａｈｏ ＭＱＴＴ、ＰｏｓｔｇｒｅＳＱＬ １０、および／またはＳｐｒｉｎｇ Ｒｅａｃｔｏｒ。

エコシステム内の役割
ＤＡＢサービスは、エコシステム、管理デバイス、ユースケース、フロー、およびエンティティのエンジンである。ＡＰＩを通じて公開されるすべての機能に加えて、ＤＡＢサービスは、第三者マーケットプレイスからの外部システム、他の電気通信コンポーネント、または追加のブロックチェーンネットワークを統合する。

ネットワークへの接続に加えて、デバイスは管理およびアクセスされ、ＤＡＢサービスを用いて、デバイスの接続、管理、認証および証明が行われる。外部エンティティ（例えば、会社）がエコシステムに参加したい場合、それはＤＡＢサービスを「サービスとして」使用してもよい。別のエンティティがデバイスの周りでより多くの制御を得たい場合、ＤＡＢサービスのインスタンスは、それら自体のデバイスでの特定の使用のために展開され、それら自体のエコシステムの部分を制御することができる。

ＩｏＴデバイスは、計算能力が低いセンサまたは低エネルギーデバイスとして機能し得る。また、デバイスは毎回接続する必要はなく、分散型台帳（例えば、ブロックチェーン）や他のタイプのネットワークに必ずしも常時接続している必要はない。デバイスの計算負荷を低減するために、ＤＡＢサービスは、デバイスを任意の種類のネットワークと接続するためのプロキシ（またはプロキシサーバ）として機能し得る。これにより、デバイスからのデータを処理する負担が軽減され、あまり強力でないデバイスをエコシステムの一部にすることができる。

ＤＡＢ管理コア
ＤＡＢ管理コアは、フローオーケストレーションエンジンおよびＡＰＩコンポーネントからなる、すべての当事者間の主要な通信層として機能する。フローオーケストレーションエンジンは、３つの構成要素からなる。各コンポーネントはＡＰＩを通じてアクセス可能である。

フローオーケストレーションエンジン
プロビジョニングエンジンは、各ＤＡＢサービスインスタンスでインスタンス化されたユースケースのセットアップと管理の両方を処理し、特定の実装または技術とのユースケースのリンクアップを抽象化する役割を担う。さらに、プロビジョニングエンジンは、これらの技術および第三者サービスの構成を処理する。それは、（ＳＩＭサービスＡＰＩを介して）アルゴリズムおよび鍵管理を展開するためのＤＡＢスタックに参加するデバイスの管理のためのアクセス層を配信する。このコンポーネントでは、以下の機能が処理される。

ビジネスルール：各デバイスが特定のネットワークまたはマーケットプレイス／エクスチェンジと行うことができる対話を定義するルールのセット。

ユースケース管理：各ＤＡＢインスタンスの利用可能なユースケースの管理（作成・編集・削除）。また、デバイスがトリガできる使用可能なユースケースをデバイスにプロビジョニングする役割も担う。

接続性：ＳＩＭ管理、位置サービスなどのためのＧＤＳＰなどの他のプラットフォームとの統合。

アルゴリズム：ＳＩＭサービスＡＰＩを活用する、ＤＡＢ駆動デバイスへのアルゴリズムの管理、カタログ作成、および展開。この機能は、好ましくは無線でアップグレードされたデバイス上に高レベルのカスタマイズおよび可能性を提供し、その結果、デバイスからデータがなくなることなく、それら自体のデータに基づいて新しいイベントを発見することができる。

認証エンジン
認証エンジンは、接続されたデバイスおよび作成されたスマートサービスのすべてのデジタルアイデンティティロジックを処理する役割を担う。デバイスからパートナーまたはサービスまでの範囲のエンティティは、ビジネスをペアリングおよび接続する（所与の時間に互いにアクセス可能なものを管理する）ために使用することができるデジタルアイデンティティを有する。したがって、このエンジンは、外部バックエンドのネットワーク内にＩｏＴデバイスエンティティを作成し、それぞれのレジストリに対して認証する能力を提供する。したがって、認証エンジンは、好ましくは一意の識別子によって、ＤＡＢエコシステムにわたってアイデンティティを一義的にアサートする。プロビジョニングされた鍵を保持し、アイデンティティおよびトランザクションの信頼性に関するコンテキストを提供するデバイスは、プラグインを許可され、実証された実証可能な由来をデータに提供することができる。

トランザクションエンジン
ユースケースに応じて、異なる機能を起動することができ、このカスタマイズはＤＡＢプラットフォームの追加の利点である。このようにしてデバイスを認証することにより、受信したトランザクションが信頼できるデバイスから、すなわちＳＩＭカードの秘密鍵を介して、暗号化および署名されることが保証され、由来およびアイデンティティが保証される。したがって、複数のマーケットプレイス／エクスチェンジ（通常、各々が特定のドメインに焦点を合わせている）でトランザクションを直ちに実行することができる。

このように、トランザクションエンジンは、受信されたデバイストランザクションおよびＡＰＩ呼び出しを処理する傾向があるロジックを処理する役割を担うことができる。これは、ＤＡＢサービス層にわたって情報をリダイレクトし、コンポーネント間要求を行うことを必要とする。例えば、これは、データベース、外部システム、またはブロックチェーン統合にアクセスすることを含むことができる。候補イベントを受信すると、ＤＡＢサービスは、含まれるデータ以上に依存してどのユースケースを適用するかを決定してもよく、デバイスで選択されたアルゴリズムまたはそれらのデータ上で生成されたインサイトをチェックしてもよい。

トランザクションが「長い」処理またはマーケットプレイスタイプのオファー／デマンド照合手順を必要とする場合、トランザクションエンジンは、セキュアなＣＰＵエンクレーブ内で特別なアルゴリズムを実行するためのサービスを提供するＤＡＢ管理サービスのオフチェーン処理コンポーネントにインターフェースを提供する。これは、ＤＡＢサービスまたは第三者によって制御されるサービスを含み得る。

トランザクションエンジンは、データセットがＤＡＢスタックに入るイングレスエンドポイントを提供する。これらは同期ＨＴＴＰ ＰＯＳＴによってＤＡＢ（または他の通信プロトコル）に配信されてもよく、それらは解析され適用可能なユースケースにルーティングされ、それに関連する（構成された）編成されたフローが開始される。

典型的な価値取引プロセスは、３つのステップに従うことができる。これらは、ほとんどのユースケースに適用可能であり、ユースケース実装がどのようにアプローチされるかを示す。

受信されたメッセージは、価値取引プロセスの開始をトリガする。例えば、これは、ＤＡＢ駆動デバイスによって送信されたトランザクション（トランザクションエンジンを参照）、または第三者による消費のためにＤＡＢサービスによって展開されたカスタムＡＰＩ上で受信された特定のメッセージであってもよい。

プロデューサのアイデンティティが検証され、アクティブ化されたユースケースが識別される。トランザクションをブロックチェーンに展開する、または外部システムもしくはＤＡＢデバイスにメッセージもしくは信号を配信するなど、結果として生じるアクションが生成される。

アプリケーションは、商業的使用のための実行可能な実用的アプリケーションとして生じるセッション記録およびデータセット照合の概念など、単純なトークン転送を超えるいくつかの種類のユースケースをカバーすることができる。トランザクション可能な多くの種類のデータを一般化するために、トランザクションエンジンは、どのユースケースのフローをアクティブにするかを示すために必要なすべての情報を含むように、できるだけ一般的であるように概説されたＡＰＩメッセージフォーマットを実施することができる。

例示的な実装形態において、例示的なＪＳＯＮコードを以下に示す。メッセージプロパティは、以下を示すことができる。

ｔｒａｎｓａｃｔｉｏｎＩｄ－デバイスによって生成され、メッセージごとに一意のＵＵＩＤ、
ｕｓｅｃａｓｅＴｙｐｅ－使用されるブロックチェーン技術とユースケースの動作モード（例えば、イーサリウム、セッションベースなど）の両方を一義的に識別する必要がある、
ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ－すべてのユースケースで使用されるが、その動作モードの各ステップを記述するために必要なキーワードに限定される（例えば、開始セッション、オープンセッション、支払い）、
ｆｒｏｍＤｅｖｉｃｅ－ＳＳＩＤ－各ＳＩＭのグローバルに一意の識別コード－デバイス識別に使用される、
ｃｒｅａｔｉｏｎＤａｔｅ－デバイスによって生成されたタイムスタンプ、
ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ－現在位置を示すデバイスによって送信されたＧＰＳデータを搬送する「ｌｏｃａｔｉｏｎＯｂｊｅｃｔ」プロパティと共に、ブロックチェーン（ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ）に挿入されるデータを含む、
ｄａｔａＴｙｐｅ－ブロックチェーンに挿入されるデータのタイプ（「ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ」内に含まれるデータ）を示すために使用される。これは、そのＪＳＯＮフォーマットを区別するために使用され得る。

｛
“ｔｒａｎｓａｃｔｉｏｎＩｄ”：“｛｛ｖ４ｕｕｉｄ｝｝”，
“ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ”：“ｎｅｗｄａｔａ”，
“ｆｒｏｍＤｅｖｉｃｅ”：“８９８１３００９９９０９０９００００６Ｆ”，
“ｃｒｅａｔｉｏｎＤａｔｅ”：“２０２０－０４－２７Ｔ１７：３２：４７．０２０１５４Ｚ”，
“ｕｓｅＣａｓｅＴｙｐｅ”：“ｓｅｒｖｉｃｅ”，
“ｄａｔａＴｙｐｅ”：“ｇｅｎｅｒａｌｄａｔａ”，
“ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ”：｛
“ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ”：“｛＼“ｂｏｒｒｏｗｅｒ＼”：＼“Ｄａｉｍｌｅｒ＼”，…｝”，
“ｌｏｃａｔｉｏｎＯｂｊｅｃｔ”：“｛＼“ｌｏｃａｔｉｏｎ＿ｄａｔａ＼”：｛＼“ｌａｔ＼”：５１…｝｝”｝
｝
データ永続性サービスなどのサポート機能
データ永続性サービスは、ユースケースオーケストレーション、デバイス構成、デバイスサービス関連データ、およびデータセットハッシュを記述する情報を格納するためにＤＡＢサービスが必要とするすべてのデータベース接続性を扱う。これは、特にタイミングが重要になるときに使用され得る。

ＤＡＢ管理コアの機能は、プラットフォームＧＵＩによってサポートされてもよい。これは、ＩＮＶＥＮＴによって実施されてもよいが、他の技術を使用してもよい。

共通ＡＰＩ
フローオーケストレーションエンジンは、ユースケース、認証およびトランザクションを構築および管理するのに適したエンドポイントを提供するために、コア機能の共通ＡＰＩのセットを必要とする場合がある。

ＤＡＢ管理サービス
ＤＡＢ管理サービス機能は、特定の業界垂直またはユースケースに関連するカスタマイズされたデータ処理を実施することができる場所として機能する。それは、ＤＡＢ管理コアから独立していてもよく、ＤＡＢ対話のために第三者サービスを統合する必要が生じたときにいつでも定義および開発することができる独自のＡＰＩを有してもよい。スケーラビリティを向上させるために、コア要素はカスタマイズされた要素から独立していてもよい。

カスタマイズされたオフチェーン処理
トランザクションが照合処理を必要とする場合（例えば、トラック容量）、またはマイクロペイメント集約の場合（例えば、料金徴収サービス）、アルゴリズムは、Ｐｙｔｈｏｎおよびソフトウェアガードエクステンション（ＳＧＸ）エンクレーブで実行することができる。

カスタマイズされたＡＰＩ
ユースケースが外部システムによってトリガされるために特定の統合が必要な場合、ＤＡＢサービスによって公開されたエンドポイントは、このコンポーネントに編成され得る。これらのユースケースは、一般に、ＤＡＢにデジタルデバイスのアイデンティティを問い合わせる、署名を要求する、またはブロックチェーントランザクションをトリガするなど、ＤＡＢスタックに既に存在するデータに依存する。これらの特注の制御点は、ＲＥＳＴを超えて、ＳＯＡＰ、ＭＱＴＴなどのＪａｖａによってサポートされる任意の他の技術で利用可能にすることができる。

ＤＡＢブロックチェーンサービス
モノの台帳
モノの台帳は、例えば、Ｃｏｒｄａネットワークに基づいてデジタルＩＤを作成、維持、および使用する能力を提供する（他の分散型台帳技術が使用されてもよい）。これはその後、認証およびトランザクション署名のためにＤＡＢ管理コアによって消費される。モノの台帳上のデバイスのバルクプロビジョニングは、企業が多数のデバイスのデジタルツインを容易かつ同時に作成することを可能にする。ＤＡＢエクスチェンジは、デバイスおよびユースケースを互いに自動的にマッピングするための重要な差別化要因となるイベント検出を含む。

ブロックチェーンハブおよびスマートコントラクトエンジン
ブロックチェーンハブ
ブロックチェーンハブは、ブロックチェーン実装によって選択された異なる統合機構を管理し、ＤＡＢコアサービスに相互接続機能を提供する。これらの機構は、組み込みＪａｖａライブラリの使用から、ＤＡＢサービス自体と共に実行される外部アプリケーションとのシステムレベルの相互作用にまで及ぶ場合がある。したがって、層は、それらの使用に必要なすべてのロジックを技術またはパートナーによって分離する異なるクラスを提供する。（プロビジョニングエンジンを介して）ユースケースを構築するとき、プログラマは、これらのコネクタのうちの１つを容易に選択し、特定のノード、サーバ、または資格情報を使用するようにそれを構成し、トランザクション管理のための単純な方法を提供されることを期待する。

異なるタイプの分散型台帳を使用してもよい。例えば、以下の３つの異なるブロックチェーンを使用することができる。

Ｃｏｒｄａネットワークでは、ＤＬＴネットワークのいくつかのノードとのＲＥＳＴｆｕｌ ＡＰＩを介してトランザクションが行われる。ＲＰＣコネクタを使用することも可能であるが、ＲＥＳＴｆｕｌ ＡＰＩは低摩擦で容易な統合を提供する。

ｉＥｘｅｃネットワークでは、連続するオペレーティングシステムプロセスが実行され、（パートナーのドキュメントに記載されているような）順序付けられたコマンドのセットが、ＤＡＢインスタンスと並んでインストールされたＮｏｄｅＪＳクライアント（ｉＥｘｅｃ ＳＤＫ）に発行され、ＤＡＢによって処理および解釈される必要があるテキストＪＳＯＮ出力を同期して実行および返す。

ＥＷＦは、データマーケットプレイスとしてイーサリウムブロックチェーンを使用するシステムを構築したが、デバイスの参加はＭＱＴＴメッセージを受信するのみのデータ処理能力のない（ｄｕｍｂ）デバイスに限定されることを考慮している。したがって、それらのＥＷＦをＤＡＢサービスに統合するために、ＭＱＴＴクライアント／コネクタは、ＤＡＢサービスが許可するすべてのデバイスのすべてのＥＷＦフローを管理する。

既存のブロックチェーン実装の複雑さを考慮すると、ＧｅｔｈおよびＷｅｂ３などのライブラリに基づいてさらなるコネクタを統合して、きめ細かい接続オプションを強化することが可能である。

例示的なユースケース
ユースケース：「サービスの支払い」
このユースケースは、駐車または料金（自動車）のようなサービスを使用および支払いするためにトークン交換がどのように使用され得るかを示す。Ｒ３ Ｃｏｒｄａ技術は、ワンタイムトークン／支払いトランザクションを作成するためにトークンＳＤＫフレームワークを実装する。ネットワーク内の５つのノードは、権限ノードとして機能する１つのノータリー、サービス用の２つのノード、およびコンシューマ用の２つのノードを含む。Ｒ３ Ｃｏｒｄａブロックチェーン上の各ノードは、サービス会社（例えば、駐車、料金徴収会社またはＥＶ充電提供者）などの主要エンティティ、および自動車会社などのコンシューマ企業を表す。各デバイスはトランザクションをトリガすることができるが、そのアイデンティティは必ずしもブロックチェーン自体にミラーリングされるわけではなく、トリガしているスマートコントラクト上に表されてもよい。これを図２６に概略的に示す。

スマートコントラクト（Ｃｏｒｄａ上のフロー）に関しては、ネットワークを管理するためのすべてのフローに加えて、各エンティティの各デバイスによって行われるトランザクションを作成および記録するためのメインフロー（すべてのトランザクションの閲覧、情報の収集、または計算の実行を含む）。ＣｏｉｎＴｏｋｅｎＴｙｐｅＣｏｎｔｒａｃｔは、ＣｒｅａｔｅＥｖｏｌｖａｂｌｅＴｏｋｅｎＦｌｏｗオブジェクトを表す。そのフローをトリガするとき、フローを開始しているデバイスのアイデンティティなどのいくつかの必須フィールドがあり、そのエンティティは、サービスのコンシューマであるそのデバイスを表す。ＡＰＩは、ネットワーク上のトランザクションを管理およびトリガし、それらを外部ポータルおよびアプリケーションと統合する。

ネットワークは、アクセスおよびネットワーク利用可能なポートおよびＡＰＩに基づいて定義された構造を有するエンティティによって分離された、ＡＷＳ（または他の）環境に展開され得る。各ノードは、独自のＡＰＩを提供し、かつ利用可能なネットワークの残りの部分とは独立して動作することができる、独自のウェブサーバを有する。

機能の統合は、スマートフォンまたは他のデバイス（例えば、Ａｎｄｒｏｉｄ携帯）内で行われている。プラットフォームは、ネットワークを監視し、手動でアクションをトリガすることができる。この解決策は、ＲＥＳＴおよびＳＳＨを使用して、ノード上で直接Ｒ３ Ｃｏｒｄａインスタンスとインターフェースし、ネットワークトランザクションの監視、新しいトランザクションのトリガ、およびＮｏｄｅ－ＣＬＩを介したノードの制御などの管理された機能を提供する。次のイメージは、その機能を詳細に示している。

自動車のシナリオでは、Ｒ３ Ｃｏｒｄａブロックチェーン機能を使用することによって、サービスに対する支払いを自動的に達成することができる。

インターフェース／依存関係
様々なインターフェースは、ＲＥＳＴｆｕｌ（または他の）ＡＰＩを介してノード上のトランザクションの制御およびトリガを可能にする。ＲＰＣおよびＳＳＨを含む他のインターフェースが使用されてもよい（図２６参照）。

以下は、それらの機能の説明と共に、使用され得る例示的なＡＰＩのリストを提供する。これらのＡＰＩは、内部で使用されてもよく、または外部エンティティによってアクセスされてもよい。

名称 説明
ｇｅｔＭｅ ノードが誰であるかに関する情報を取得する。

ｇｅｔＰｅｅｒｓ ネットワーク上の他のノードに関する情報を取得する。
ｇｅｔＮｅｔｗｏｒｋＭａｐ 接続のネットワークマップを取得する。

ｇｅｔＮｅｔｗｏｒｋＦｅｅｄ トランザクションのネットワークフィードを取得する。

ｇｅｔＮｅｔｗｏｒｋＰａｒａｍｅｔｅｒｓ ネットワーク実装パラメータを取得する。

ｇｅｔＲｅｇｉｓｔｅｒｅｄＦｌｏｗｓ そのノードの実行可能なフローのリストを取得する。

ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩＤ ノードが関与したトランザクションＩＤのリストを取得する。

ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩｎｆｏＢｙＩＤ ＩＤによりトランザクションの情報を取得する。

ｇｅｔＮｕｍｂｅｒＯｆＴｒａｎｓａｃｔｉｏｎｓ ネットワーク内のトランザクション数を取得する。

ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩｎｖｏｌｖｅｄ ノードが関与したトランザクション情報のリストを取得する。

ｇｅｔＮｕｍｂｅｒＯｆＴｒａｎｓａｃｔｉｏｎｓＩｎｖｏｌｖｅｄ ノードが関与したトランザクションの数を取得する。

ｇｅｔＮｏｄｅＩｎｆｏ ノード自体に関する情報を取得する。
ｇｅｔＮｏｄｅＴｉｍｅ ノードの現在時刻を取得する。

ｇｅｔＴｒａｎｓａｃｔｉｏｎｓ すべてのトランザクションの情報のリストを取得する。

ｇｅｔＶｏｄａｃｏｉｎｓ 「Ｖｏｄａｃｏｉｎｓ」の残高の数字を取得する。
ｐｏｓｔＣｒｅａｔｅＴｘ ネットワーク上でトランザクションを作成する。ビジネスロジックの項に記載
分散型台帳内（例えば、ブロックチェーンネットワーク）の各ノードについて、ＡＰＩは複製可能であり、ネットワークの残りの部分と対話するために同じタイプのフローを実行することができる。

ビジネスロジック
ＤＬＴ（例えば、Ｃｏｒｄａ）との対話は、確立されたＲＥＳＴエンドポイントおよびＳＳＨ接続のセットを介して行われるため、ＤＡＢブロックチェーンサービスコネクタは、台帳からのデータの挿入および取得に必要なコールフローを調整する。これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、公開層に記述されたメッセージフォーマットに従ってトランザクションを構築する。

この機能のために、サービス支払いシナリオ（ｕｓｅＣａｓｅＴｙｐｅ「ｓｅｒｖｉｃｅ」）は、「ｎｅｗｄａｔａ」トランザクションタイプのみを必要とする。例えば、アプリケーション（ＤＡＢアプリ）を使用していくつかのユースケースおよびシナリオを手動でトリガすることが可能である。

混雑課金、ワン・タイム・パーキング、または任意の他のサービスのようなサービスの支払いのために、ユーザは、ＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ」、タブ「サービス」を選択し、フィールドに入力する。

借り手－トークン／価値を譲渡したい相手（サービスプロバイダ）
価値－トークン数
タイプ：
ＭＩＮ－持続時間量（例えば、分）
ＣＣ－金銭的価値における混雑課金額
支払い－金銭的価値における任意の他の支払い
サブ値－選択された支払いタイプに対応する数値（例えば、３分、３ユーロ、３ボーダコイン）
ＶＩＮ－車両Ｖｉｎ
スロットＩＤ－例えば、駐車スロットまたは料金所を指定するために使用できる任意選択のフィールド
場所－例えば、混雑領域入口点または駐車場所を指定するために使用することができる任意選択のフィールド
ＩＣＣＩＤ－ＳＩＭカードＩＣＣＩＤまたはＵＩＣＣ
これは、ＪＳＯＮオブジェクトに変換され得る。

自動的なトリガおよび統合（例えば、自動車の統合）は、ブロックチェーンとの改善された直接対話を提供する。さらに、ネットワークパーティ間の決済が容易になり得る。ブロックチェーンは、コンシューマまたは当事者間で行われたすべてのトランザクションを登録することができるため、サービスは、それらの間で決済が行われながら同じネットワークで取引することができる。スマートコントラクト／フローは、特定の債務を決定し、ある当事者から別の当事者に資金を自動的に送信することができる。あるいは、外部請求システムは、ネットワーク上に存在するすべての単一トランザクションを集約することができる。

ユースケース：「イベント駆動フリート」
このユースケースは、データを生成し、ブロックチェーンベースのマーケットプレイス／エクスチェンジを提供するために直接使用することができる。これは、異なる状況およびシナリオで実施され得る。例示的な実施態様では、物流会社は貨物輸送能力を完全に利用しない場合がある。センサ生成データは、エッジ秘密計算ユニットを使用して処理され、マーケットプレイスまたはエクスチェンジで共有されると、他の当事者またはエンティティによって検索および入札または購入され得る「オファー」データセットを構築することができる。この例では、ｉＥｘｅｃプラットフォームを使用して、ＤＡＢサービスによってキューに入れられ、Ｉｎｔｅｌ ＳＧＸエングレーブを使用して実行されるｉＥｘｅｃを使用してスクリプト化されたカスタムオフチェーンアルゴリズムによって実行されるジョブを照合した。これを図２７に概略的に示す。

販売者は、ルートを販売したいときはいつでも、手動または自動でＤＡＢアプリのＵＩに入力し、それをｉＥｘｅｃマーケットプレイスの他のエクスチェンジに挿入するようにＤＡＢサービスに要求する。別のエンティティは、アプリケーション内の同様のプロセスまたはレイアウトを使用して、それらのニーズを記述してもよい。互換性のあるオファー（過去と未来の両方）を検索して照合してもよい。ＤＡＢサービスは、これらのクエリを受信し、照合ジョブを展開し、一致するものが見つかった場合に双方に通知する。

検出アルゴリズムによって生成されたデータセットの自動展開を使用してもよい。
インターフェース／依存関係
テストシステムでは、オファーおよびデマンドトランザクションを構築し、それらをＤＡＢサービスのトランザクションエンジンに送信するために、ＤＡＢアプリ（ＡｎｄｒｏｉｄまたはｉＯＳベース）にユーザインターフェースのセットが作成されている。

マーケットプレイス／エクスチェンジを使用するために、ＤＡＢサービスはｉＥｘｅｃ ＳＤＫと対話する。このアプリケーションは、独自のイーサリウムトランザクションロジック、およびデータ挿入と検索を調整するための別のブロックチェーン統合レイヤコネクタをラップする、コマンドラインＮｏｄｅＪＳツールである。これらの動作は各々、実行されるべきいくつかのＯＳ呼び出しを伴い、順序付けられたコマンドのセットがＳＤＫに発行され、ＳＤＫは、ＤＡＢサービスによって処理および解釈されるテキストＪＳＯＮ出力を同期的に実行および返す。すべてのｉＥｘｅｃオフチェーンアルゴリズムはセキュアなエンクレーブで実行されるため、それらが使用するデータセットはそれらのブロックチェーンに直接挿入されない。代わりに、これらは、ＳＤＫによって生成された秘密で暗号化されると、公開ＩＰＦＳネットワーク（または他のファイルシステム）に展開される。この秘密は、データセットのＩＰＦＳハッシュと共に、挿入フロー中にｉＥｘｅｃに各々プッシュされ、秘密は秘密管理サービスに送信され、ハッシュはブロックチェーンに送信される。ＩＰＦＳピンニングサービスの場合、Ｐｉｎａｔａが使用されてもよい。この実装はＡＰＩも使用する。

ｉＥｘｅｃ ＳＤＫ ｖ４．０．３は、同じマシン内のＤＡＢサービスインスタンスと共にインストールされ、ＮｏｄｅＪＳ ８．１０．０およびＤｏｃｋｅｒ １９．０３．６の構成を必要とした。

ＤＡＢアプリは、ＤＡＢサービスに送信されるトランザクションを構築するユーザインターフェースのセットを作成するために使用される。これは、オファーおよびデマンドの容量をシミュレートする。しかしながら、そのようなプロセスは、異なるエンティティおよびプロセスによってオファーおよび許容が生成される生成システムにおいて自動化される。同様のメッセージフォーマットは、２つの異なるタイプのトランザクションで使用される。

「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」が「ｎｅｗｄａｔａ」に等しい場合、オファーデータセットが含まれ、それをブロックチェーン／マーケットプレイス／エクスチェンジに展開するようにＤＡＢサービスをトリガする；
「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」に等しい場合、所望のトリップパラメータを含むデマンドデータセットを搬送する。

ｉＥｘｅｃによって準備された照合アルゴリズムは、オファーとデマンドの両方に類似した厳密なデータセット形式、出荷会社が特定の価格、日付およびルートで雇用のために利用可能なトラックスペースを販売するテストシナリオを特徴付けるＪＳＯＮ構造を扱うので、両方のデータセットはプロパティ「ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ」内にある。

取引情報
トラックトリップのための空間提供を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ」、タブ「トラック容量」を選択し、フィールドに入力する。生成システムでは、データセットは、容量を示すことができるセンサを有する個々のトラックによって作成される。データセットは以下を含む。

サービスプロバイダ－サービスプロバイダの名称、
提供スペース－利用可能な貨物ユニットの数量、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－希望価格、
トラックトリップの要求を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「データを探す」を選択し、フィールドに入力する。

サービスプロバイダ－貨物空間を探すエンティティの名称、
必要な空間－必要な貨物ユニット、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－入札価格。

ここでも、生成システムでは、貨物空間の入札は、そのようなサービスを必要とするエンティティに対して自動的に生成され得る。

「ｎｅｗｄａｔａ」または「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」を受信すると、ＤＡＢサービスは、ｉＥｘｅｃ ＳＤＫとの一連のシステムレベルの対話を開始する。ｉＥｘｅｃブロックチェーンに挿入されるのは、オファーデータセット自体ではなく、そのＩＰＦＳハッシュ（他の関連するｉＥｘｅｃデータと共に）である。

「ｎｅｗｄａｔａ」トランザクションがマーケットプレイス／エクスチェンジに挿入されるデータセットを識別する場合、「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」はＤＡＢ側フローをトリガし、ＤＡＢ側フローは、以前に挿入された「ｎｅｗｄａｔａ」データセットをループして、（ｉＥｘｅｃによって管理されるＩｎｔｅｌ ＳＧＸエンクレーブワーカープールで実行される）オフチェーン照合タスクを順次展開してポーリングすることを必要とする。このプロセスを図２８に概略的に示す。

照合プロセスは、ＤＡＢサービスが、対の相手のないオファーおよびデマンドデータセットのハッシュを選択し、それらをｉＥｘｅｃワーカープール内の「タスク」に挿入することを伴う。これらのタスクは、ｉＥｘｅｃワーカープールによってピックアップされて実行され、結果が計算されるまでＤＡＢサービスによって繰り返しポーリングされる。ＤＡＢサービスは、そのデータベース内のすべてのデータセットハッシュを含む更新されたリストを保持する。このプロセスを図２９に概略的に示す。

これらのオフチェーンタスクは同時に複数の比較を実行することができないため、ＤＡＢサービスはデータセットごとに実行を発行する役割を担う。オファーとデマンドとの間に一致が見つかった場合、それらのデータセットハッシュがＤＡＢサービスデータベースに登録され、購入者のデバイスに通知される。

オファーおよびデマンドデータセットの両方を挿入したデバイスに一致を通信するため、特にＡｎｄｒｏｉｄアプリケーションのメッセージおよびプッシュ通知のためのクロスプラットフォームクラウドによる解決策であるために、Ｆｉｒｅｂａｓｅクラウドメッセージングプラットフォームが使用され得る。コンポーネントは、ＤＡＢ駆動デバイスのためのＦｉｒｅｂａｓｅメッセージングを処理し、すべてのデバイスは、起動時にそれらのＦｉｒｅｂａｓｅ接続トークンを登録するようにされる（ＤＡＢサービスにポストされたデバイス登録メッセージに沿って送信される）。したがって、それらは起動の準備ができている。ここでも、生成システムでは、メッセージを異なる方法で処理してもよい。

マーケットプレイス／エクスチェンジへのデータの自動供給は、異なる機構を使用して達成してもよい。例えば、ＡＩおよびセンサネットワークは、自動化された市場交渉で設定することができる。既製の照合アルゴリズムを、ワーカープールを保護するために展開してもよい。

代替の実装形態には、
ＩＰＦＳをより高速な分散ストレージによる解決策に置き換えること、
複数のデータセットを同時に扱うことができる照合アルゴリズムを展開すること、
ＤＡＢサービスがデマンドデータセットをアンロードし、一致が見つかったときに非同期通知を提供する連続分析のためのデータセットハッシュを提供する、専用のワーカープールを設定すること、が含まれる。

ユースケース：「エネルギーアイデンティティおよび支払い」
この使用により、「ＤＡＢ対応デバイス」（ＳＩＭおよびそれぞれのミドルウェア上のセキュアエレメントを有する）をＥｎｅｒｇｙ Ｗｅｂ Ｆｏｕｎｄａｔｉｏｎスマートエネルギープラットフォームに統合し、アクティブな参加者になることが可能になる。

接続されたデバイスは、Ｆｌｅｘｈｕｂ ＭＱＴＴブローカからのメッセージ（すべてＪＷＴストリングに符号化されている）を排他的に読み取り、デジタル署名する。アセット所有者は、（電力を売買するための）オファー割当をプログラムしており、ＦｌｅｘＨｕｂプラットフォームによって管理および処理される。ＤＡＢプラットフォームは、ドメイン相互接続を追加する。これは、ＤＡＢサービスがトランザクションされたデータを認識し、これらのデータを操作することを必要とする。したがって、統合アーキテクチャは、デバイスのためにＤＡＢサービスブローカを使用し、それらに代わってＦｌｅｘＨｕｂノードとのメッセージングを処理する。ＥＷＦデバイス側コード（元々Ｐｙｔｈｏｎで書かれている）は、ＦｌｅｘＨｕｂ機能に何ら影響を与えることなく、現在は複数のデバイスにサービスするＤＡＢコア上で実行されているＳｐｒｉｎｇ Ｂｏｏｔコンポーネントに移植される。このシステムの概略図を図３０に示す。

ＥＷＦによって定義された関連するユーザ／当事者／役割には、以下が含まれる。
ＴＳＯ（伝送システムオペレータ）は柔軟性の要求を提出し、制約および制限を定義し、確認済みアセットをアクティブ化する。

アセット所有者は、その個人アセットの各々がそれらのパラメータと一致するオファーを提出できるように、オファーパラメータを定義する。

インストーラは、アセット所有者のアセットの登録を承認する。
管轄機関は、市場に参加している他の当事者の役割の登録を承認する。

ＴＳＯは、それらのエネルギー柔軟性要求および制約をシステムに提出し、アセット所有者は、それらのオファーを提出し（自身で、またはインテリジェンスの第三者プロバイダを介して）、Ｆｌｅｘ ｓｙｓｔｅｍは、要求を満たすための最低コストの方法を決定する。

他の強化には、以下が含まれ得る。
登録、プロビジョニング、オファー作成の自動化。

ＡｎｄｒｏｉｄまたはＪａｖａを使用しているデバイス以外のデバイス。
デバイスは、トランザクションに署名するように要求され、オファーのアクティブ化が通知される。これらは、ＤＡＢサービスによってトリガされる。これにより、デバイスが、各デバイスから命令のためにそれぞれのＦｌｅｘＨｕｂ ＭＱＴＴキューをポーリングすることが回避される。ＤＡＢアプリは、以下を含む機能を提供する。

デバイスは、署名用のＥＷＦトランザクションを含むメッセージを受信し、それはその後、ＤＡＢコアサービスＡＰＩ上のカスタムエンドポイントにポストされ、ＤＡＢコアをトリガしてそれぞれのＥＷＦビジネスフローを完了する。

アクティブ化メッセージが受信されるときはいつでも、ＤＡＢアプリはユーザ通知を表示し、これは有用で実際のアクション（例えば、モバイルアプリケーションから到達可能なデバイスをオン／オフする）で置き換えてもよい。これを図３１に概略的に示す。

ビジネスロジック
フローは、Ｆｌｅｘ ＷｅｂＡｐｐ内の様々なＥＷＦアクターによって行われた入力から開始される。ＤＡＢサービスは、ＥＷＦビジネスロジック（および任意の種類のフロー状態可観測性）を実装する唯一のコンポーネントであるため、ＦｌｅｘＨｕｂが必要とする様々なＪＷＴに署名するようにデバイスに要求する。

要求されたメッセージに署名した後、デバイスは、署名されたメッセージを送信したデバイスに対してどのフローが実行されていたかを判定するのに十分な情報とともに、ＤＡＢサービスにそれらを返す。デバイスは、手元のユースケース（ＤＡＢスタック目標の１つ）に関係するものとは別の他のＪＷＴに署名する必要があり得る。したがって、Ｆｉｒｅｂａｓｅ Ｄａｔａ Ｍｅｓｓａｇｅフォーマットは、他のシナリオに対する高速な適応を可能にする。「ｕｓｅＣａｓｅ」プロパティは、署名を求めるＤＡＢユースケースを指定し、提出時にＤＡＢサービスでトリガするアクションを識別するために、サーバがその特定のユースケース内のアクションの追加のコースを区別できるようにする追加の「ｕｓｅＣａｓｅＡｃｔｉｏｎ」プロパティを含めることが適切であると本発明者らは感じた。図３２および図３３は、このプロセスのシーケンス図を示す。

この統合のために、プロパティ「ｕｓｅＣａｓｅ」は「ｅｗｆ」としてタグ付けされ、「ｕｓｅＣａｓｅＡｃｔｉｏｎ」フィールドは、デバイスの署名を最初に必要とした特定のＥＷＦビジネスフローを示すために使用された。

特定のアセットによって実行される所与のオファーのアクティブ化チャートを確認するために、Ｆｌｅｘ ＷｅｂＡｐｐをアセット所有者が使用することもでき、ダッシュボードを介してユーザは作成されたオファーのリストにアクセスし、チャート化したいオファーの「データシート」アイコンを選択することができる。

デバイスは、ＥＷＦネットワークの一部になり、これは、発電機、バッテリなどをオン／オフするなどのさらなる実用的な動作に拡張することができる。同じことが、電気自動車充電（ＥＶＣ）または単純なスマートメータデータの貨幣化を含む、フレックスグリッド以外の他のマーケットプレイスにも適用可能である。

ユースケース：「企業およびコンシューマ駐車」
このユースケースでは、デジタルＩＤ（人、サービス、および物に対する）を使用して、支払いの有無にかかわらず自動車をサービスとペアリングできる完全なエンドツーエンド体験を作成する。

１．運転者のいずれかによって行われる（コンシューマＢ２Ｃシナリオ－運転者のデジタル識別情報および銀行プラットフォーム内の関連する個人口座を使用する）、
２．後の処理のためにＤＬＴ上で使用が維持される車自体に課金される（企業Ｂ２Ｂシナリオ－車が第三者、例えばレンタル会社に属する場合）、
ＤＡＢサービスは、フローを管理および編成する（およびＢ２Ｂ支払いに使用するためのＣｏｒｄａ ＤＬＴをホストする）。車両は、ＤＡＢミドルウェアアプリケーションおよびＤＡＢアプリのカスタマイズされたバージョン（例えば、タブレットアプリ）を実行する内部ルータを含み得る。これは、組み込み（例えば、ｉＯＳまたはＡｎｄｒｏｉｄベース）ダッシュボードコンピュータにインストールすることができる。

インターフェース／依存関係
ＳＰＯＴ駐車システムは、「サービス支払い」ユースケースと同様に、同じ場所およびＣｏｒｄａ台帳にインストールすることができる。

ＳＩＭによる保護
トランザクションに署名するために、前述のＳＩＭ手法によって保護されたものが使用されてもよく、ＳＩＭ上でＰＫＩを消費する。ＳＩＭは、プロセッサまたは他のデバイス（例えば、車両）に差し込まれたＵＳＢドングルに追加される。ＤＡＢミドルウェアがデバイス上で実行され、前述したように、署名のためにＤＡＢミドルウェアＡＰＩを公開する。

駐車インフラストラクチャにインストールされたＳＰＯＴ駐車システムは、そのゲートを横切る車両を検出し、カスタムＡＰＩセット（上記参照）でエンドポイントを呼び出すことによってＤＡＢサービスと共に動作する。このカスタマイズは、ＳＰＯＴがＤＡＢサービスにナンバープレートおよびゲート情報を送信するために使用され、次に、以下の場合にはリターンコードを予期する。

入庫時：有効化された支払いが設定されたため、バリアを開くことができる、
出庫時：精算が完了し、車は出庫することができる。

ＦＩＮＮ
Ｂ２Ｃシナリオを管理するために、ＦＩＮＮ（ＲＴＭ）を使用した。これは、ＩｏＴの支払いをスマートデバイスに追加するツールキットを含む商用プラットフォーム上に構築されたＩｏＴの解決策の貨幣化に特化している。要約すると、
「製品」は、サービスを提供し、それと対話するための様々なアクションを定義し、それぞれに利用価格を割り当てる。

デバイスは、「製品」を使用するように登録し、そのアクションは、クレジットカードなど、デバイス所有者によって設定された支払い方法に課金される。

デバイスが「製品」アクションをトリガするときはいつでも、ＦＩＮＮエコシステムにマイクロペイメントが登録される。

ＦＩＮＮの場合、「製品」は、実世界で作動する任意の実システム（「製品」アクションを任意の自動化されたアクティビティと接続するためのＦＩＮＮ ＩＯＴ ＳＤＫと統合する）またはオフラインサービスを表す抽象エンティティとすることができる。ＳＰＯＴ内のすべての使用ロジックは、ＤＡＢサービスコンポーネントによって制御される。この「製品」のための構成された動作は、ゲート入口および出口を含み、それぞれ滞在期間に基づいて０および駐車料金が課金される。

駐車セッションのシーケンス図を図３４に示す。
これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、ＤＡＢ管理コアに記載されたメッセージフォーマットに従ってトランザクションを構築する。駐車シナリオ（ユースケースタイプ「駐車」）の場合、セッション開始と終了は、それらの「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」の値（「ｎｅｗｄａｔａ」および「ｅｎｄｃｏｒｄａｓｅｓｓｉｏｎ」）と、「ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ」の内容によって区別される。この最後のフィールドは、ＤＬＴにコミットされる購入者（車）および供給者（駐車場）の両方の情報を搬送する。地理的情報と共に、ＤＡＢサービスは、各デバイスのプロキシサーバとして機能する（必要に応じてデバイスの位置を検証するために使用される）。

シミュレートされた駐車セッションを開始するために、ユーザはＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ、：タブ「駐車、を選択し、以下のフィールドに入力する。

イニシエータ－駐車セッションを開始するデバイス（デバイスのＳＩＭ ＩＤが自動的に入力される）、
ターゲット－車両が登録されているＣｏｒｄａノード、
ターゲットＵＵＩＤ－イニシエータ車両のコード識別子（ＵＵＩＤ）、
ソースＵＵＩＤ－車両を駐車するために選択された駐車スロットのコード識別子（ＵＵＩＤ）、
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用してパーキングセッションを開始する：常に結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－Ａｎｄｒｏｉｄ ＯＳから読み取られるように、実際のＧＰＳ位置を使用して駐車セッションを開始する。このオプションを使用して正常な駐車セッションを開始する場合、イニシエータデバイスと駐車スロットは、互いに最大６ｍでなければならない。

駐車セッションを終了するために、ユーザは、
「トランザクション」メニューエントリ内のセッションを開き、以下のフィールドに入力する。

ブロックチェーンに課金される分／価値単位、
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用して駐車セッションを停止する、この結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－デバイスの実際のＧＰＳ位置を使用して駐車セッションを終了する、
ＭＯＣＫ＿ＥＮＤ＿ＳＥＳＳＩＯＮ＿ＣＡＲ＿ＳＴＩＬＬ＿ＰＡＲＫＥ Ｄ－車が駐車場所を離れていないかのように動作するようにＣｏｒｄａ ＤＡｐｐに指示するテストフラグ。

ビジネスロジック
このユースケースでは、「製品」を使用するデバイスは車両である。しかしながら、その「アクション」は、Ｂ２Ｃシナリオでアクティブ化されてもよい。したがって、「スマートサービス」の概念が使用されており、ユーザのデジタルアイデンティティとＤＡＢスタックによって提供されるサービスとの間の関連付けである。

ＤＡＢはデバイス（車）をＳＩＭに関連付ける：これはＦＩＮＮベースのスマートサービスであるため、ＤＡＢサービスは、それを使用したいデバイスに渡すために、ＳＰＯＴ駐車「製品」に関連するすべてのＦＩＮＮデータを知る必要がある。これは、車両タブレットアプリ（または車両もしくはデバイス内の他のプロセッサ）が起動するたびに行われ、それと一緒にインストールされるのは、ＦＩＮＮコアバックエンドに登録され、必要に応じていつでもＳＰＯＴ駐車「製品」を使用する準備ができるようにその車両を自動的にセットアップするためのコードを含む、ＦＩＮＮ提供アプリ（ＦＩＮＮ ＩＯＴ ＳＤＫを組み込む）である。このプロビジョニングフローは図３５に示されており、以下を含む。

ステップ 説明 トリガ
１ 製造業者がＳＣＢ－ＤＡＢシステムに新しい車を追加する 製造業者
２ ＤＡＢは、その車のアイデンティティのための新しいスマートコントラクトをＤＤＩブロックチェーンネットワークに展開する ＤＡＢ
３ ＤＤＩブロックチェーンネットワークは対応するｄｉｄで応答する ＤＤＩブロックチェーン
４ ＤＡＢはそれを車のナンバープレートと関連付ける ＤＡＢ
５ ＤＡＢは対応する車に車のｄｉｄを送信する ＤＡＢ
６ 車は自分のデータベースに自分のｄｉｄを保存する 車
スマートサービスのオンボーディング：ユーザが「スマートサービス」のオンボーディングを実行したいときはいつでも、特別に開発されたＡｎｄｒｏｉｄアプリケーション（以下、「スマートサービスアプリケーション」として知られる）を使用して実行する。アプリは、デジタルアイデンティティを選択するためのＤＩＤアプリケーションと協働し、そのＵＩから選択されたスマートサービスをそれに関連付ける。これを図３６に概略的に示す。

この時点で、ユーザが「ＳＰＯＴ駐車スマートサービス」を使用するためにオンボードしている場合、ＤＡＢサービスは、ユーザ側のＦＩＮＮ支払い方法を構成するのに十分なデータ（最初にタブレットアプリによって送信されたデータ）で応答しており、このために、スマートサービスアプリは、最初にユーザに有効な支払いクレジットカードを要求し、次いでそれをＳＰＯＴ駐車製品のコンシューマとして登録する、別のＦＩＮＮ供給アプリケーション（ＦＩＮＮモバイルＳＤＫを組み込む）とインテントを介して自動的に通信する。これを図３７に概略的に示す。この例示的な実装形態では、以下のステップをとることができる。

Ｂ２Ｃサービスのオンボーディング（図３７）
ステップ 説明 トリガ
１ スマートサービスアプリは、ＤＡＢをトリガしてユーザ用の新しいサービスを作成する スマートサービスアプリ
２ ＤＡＢはプロファイルタイプ（個人の場合）をチェックし、ユーザデータを保存する ＤＡＢ
３ ＤＡＢは、ユーザ側初期化に必要なデータ：ユーザプロファイルデータ＋サービスデータで応答する ＤＡＢ
４ スマートサービスアプリは、（インテントを介して）新しいサービスを作成するためにＦｉｎｎモバイルアプリをトリガする スマートサービスアプリ
５ ＦｉｎｎモバイルアプリがＦＩＮＮコアに要求を転送する ＦＩＮＮモバイルアプリケーション
６ ＦＩＮＮコアは、成功またはエラーメッセージで応答する ＦＩＮＮコア
７ Ｆｉｎｎモバイルアプリは、成功またはエラーメッセージで応答する（インテントリターンを介して）ＦＩＮＮモバイルアプリケーション
９ スマートサービスアプリは、Ｆｉｎｎのオンボーディング確認を／サービス／確認にポストする スマートサービスアプリ
デバイスを識別する（例えば車）：ユーザがどの車を運転しているかを決定するために（および車両がＦＩＮＮ ＳＰＯＴ駐車「製品」アクションをトリガすることを理解するために）、ユーザと物との間のセッションを作成するためにデジタルアイデンティティ機能を活用するログイン機構がＤＡＢプラットフォームで確立される。このようにして、車が入口ゲートを横切るときはいつでも、ＤＡＢサービスは誰がそれを運転しているかを知る。このフローは、運転者がＤＡＢアプリ（車の車載されたタブレットに予めインストールされている）に車のナンバープレートを入力したときにトリガされ、その後のアクティビティは以下の２つの段階に分けることができる。

ＱＲコード（登録商標）の生成：ＤＡＢアプリは、認証プロセスを進めるために、運転者がスキャンするためのＱＲコードをタブレット上に生成する、および
運転者認証：運転者はＱＲコードをスキャンし、ＤＤＩアプリをトリガして開く。そこから、運転者は、車両と共有したい個人情報を許可する（または許可しない）。このデータの一部は強制的であるが、他は任意であり、これは（すべての車両のプロキシとして機能する）ＤＡＢで構成された設計決定である。ユーザによって共有されるすべての許可された情報は、ＤＡＢに格納され得る。これを図３８に概略的に示す。

ＱＲコードを介した運転者－車ログイン（図３８）
ステップ 説明 トリガ
１ 運転者は、車のタブレットアプリにナンバープレートを入力する タブレットアプリ
２ タブレットアプリは、ログイン要求をＤＡＢに送信する タブレットアプリ
３ ＤＡＢは、そのログイン「セッション」を識別するランダムトピックＵＵＩＤを生成する ＤＡＢ
４ ＤＡＢは、ＧＣＬにノンス＋許可ＩＤを要求する ＤＡＢ
５ ＧＣＬ応答：ノンス＋ａｕｔｈＩＤ ＧＣＬ
６ ＤＡＢは、トピックをノンス＋ａｕｔｈＩＤ＋ステップ２データと関連付ける ＤＡＢ
７ ＤＡＢは、ＱＲコードを生成するために必要なデータをタブレットアプリに送信する ＤＡＢ
８ タブレットアプリは、認証用ＱＲコードを生成する タブレットアプリ
非中央集権化デジタルＩＤ（ＤＤＩ）を介した運転者－車ログイン（図３９）
ステップ 説明 トリガ
１ 運転者は、自分の電話でＱＲコードを読み取る（トピック＋車のＤＩＤアイデンティティを含む）運転者
２ ＤＤＩアプリが開き、運転者は自身について共有したいデータを選択および／または許可する。ＤＤＩアプリ
３ ＤＤＩアプリは、その情報を共有する ＧＣＬ
４ ＧＣＬは、提供された車のアイデンティティに格納されたＤＡＢリターンＵＲＬをブロックチェーンに要求する ＧＣＬ
５ ＧＣＬは、そのエンドポイントをポストし、トピックの存在をチェックするトピックが存在する場合、ＤＡＢは、ログインしようとしているユーザに関係する指示されたｕｓｅｒＤｉｄを格納する ＧＣＬ
６ ＤＡＢは、ＧＣＬにＯｋまたはエラー応答を送信する ＤＡＢ
７ ＧＣＬは、ログイン結果をＤＤＩアプリに送信する ＧＣＬ
８ ログイン結果が成功すると、ＤＤＩアプリはユーザプロファイル＋プロファイルタイプをＤＡＢにポストする ＤＤＩアプリ
９ ＤＡＢは、このユーザ／車セッションのユーザプロファイル＋プロファイルタイプを保存する ＤＡＢ
１０ ＤＡＢは、ログイン結果をタブレットアプリに送信する ＤＡＢ
１１ タブレットアプリは成功メッセージを表示する タブレットアプリ
ＤＡＢサービス：ＤＡＢサービスは、ＳＰＯＴがカスタムＡＰＩ（既存のＳＰＯＴインフラストラクチャの仕様に従って実装される）のカスタムＲＥＳＴエンドポイントに検出された車両ナンバープレートに関する情報をポストするたびにトリガされる。次のロジックは、ＳＰＯＴビジネスフローを管理するためにＤＡＢコア内に統合される追加のコンポーネントを必要としたが、これは以下のように要約することができる。

車両が駐車場に進入したときに、
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスは、ブロックチェーン統合層のＣｏｒｄａコネクタを使用して、Ｃｏｒｄａ ＤＬＴ上でその車両のセッションを開く（「駐車および料金」ユースケースをミラーリングする）、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品のアクティブ化がトリガされる。

車両が駐車場を出るときに、
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスはその車両の以前に開かれたＤＬＴセッションを閉じる、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品の非アクティブ化がトリガされる。

Ｂ２Ｂは、駐車フローの詳細を開始する（図４０）。
ステップ 説明 トリガ
１ 入口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する新しい駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の新しい駐車セッションをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、新しい駐車セッションを通知するＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｃは、駐車フローの詳細を開始する（図４１）
ステップ 説明 トリガ
１ 駐車ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、Ｆｉｒｅｂａｓｅ通知をタブレットアプリに送信し、Ｆｉｎｎアクション（入庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに入庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の入庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４２）。

ステップ 説明 トリガ
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の駐車セッションのクローズをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４３）。

ステップ 説明 トリガ
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリケーションに送信し、Ｆｉｎｎアクション（出庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに出庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の出庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
同様の解決策は、異なる駐車の解決策に適用することができ、また、例えば、ＥＶ充電および料金が同じフローに従うことができるスマートシティにおける異なるドメインにも適用することができる。コンシューマデジタルＩＤおよび支払いに関して、エンドツーエンド体験の改善が行われている。

ＤＡＢユーザインターフェース
テスト環境には、以下の２つの主なユーザインターフェース（ＵＩ）がある。

ＤＡＢ ＡＰＰ：Ａｎｄｒｏｉｄ（または他の）モバイルアプリケーション
ＤＡＢ ＡＥＰ：ＤＡＢ Ｃｏｒｄａブロックチェーンを接続するためのＴｈｉｎｇｗｏｒｘ拡張
ＵＩは、顧客がすべての機能を利用できるようにするだけでなく、運用および保守チームがエコシステムおよび解決策を管理し、情報を監視および抽出できるようにするために重要である。

図４４～図４８は、例示的なプラットフォーム環境を示す。他のサーバタイプおよびサービスが使用されてもよい。

これはテストシナリオを説明しているが、実際の駐車セッションは、同様だがアプリケーションを必要としない方法で処理される場合がある。すべてのメッセージは、車両（または駐車位置）の内部または周囲のセンサおよび検出されたイベントから開始され得る。

当業者には理解されるように、上記の実施形態の詳細は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく変更することができる。

例えば、異なる分散型台帳または台帳技術を使用することができる。ＵＩＣＣは、例えば、組み込みＳＩＭであってもよい。例えば、移動式、可動式、固定式、監視付き、監視なし、家庭用、商業用または工業用デバイスを含む多くの異なるタイプのデバイスが使用されてもよい。

上記の実施形態の特徴に対する多くの組み合わせ、修正、または変更は、当業者には容易に明らかであり、本発明の一部を形成することを意図している。１つの実施形態または例に具体的に関連して説明した特徴のいずれも、適切な変更を行うことによって任意の他の実施形態で使用され得る。

Claims (18)

1. セキュアなトランザクションを実行するための方法であって、前記方法が、
   ＵＩＣＣを有するデバイスとサーバとの間でセキュアな通信チャネルを開始するステップであって、前記セキュアな通信チャネルが、前記ＵＩＣＣを使用して確保される、ステップと、
   前記サーバにおいて、前記セキュアな通信チャネルを介して前記デバイスから、トランザクションを実行するための命令を受信するステップと、
   前記受信した命令に応答して、前記サーバから分散型台帳に、前記トランザクションを実行する要求を送信するステップと、
   前記要求に応答して、前記分散型台帳内に格納された公開鍵と秘密鍵のペアを使用して、前記分散型台帳内で前記トランザクションに署名するステップと
   を含む、方法。
2. 前記ＵＩＣＣと前記サーバとの間の前記セキュアな通信が、前記ＵＩＣＣに格納された公開鍵と秘密鍵のペアを使用して開始される、請求項１に記載の方法。
3. 前記ＵＩＣＣ内で前記公開鍵と秘密鍵のペアを生成するステップをさらに含む、請求項２に記載の方法。
4. 前記ＵＩＣＣと前記サーバとの間の前記セキュアな通信が、共有秘密を使用して開始される、請求項１に記載の方法。
5. 前記秘密が、
   前記ＵＩＣＣが製造されるときに、前記ＵＩＣＣ内および電気通信ネットワークコンポーネント内に前記共有秘密を格納すること、および
   前記電気通信ネットワークコンポーネントが前記サーバに前記共有秘密を送信すること
   によって前記ＵＩＣＣと前記サーバとの間で共有される、請求項４に記載の方法。
6. 前記電気通信ネットワークコンポーネントが、ホームロケーションレジスタ、ＨＬＲである、請求項５に記載の方法。
7. 前記共有秘密が、汎用ブートストラッピングアーキテクチャ、ＧＢＡを使用して生成される、請求項４に記載の方法。
8. 前記秘密が、
   前記ＵＩＣＣおよびブートストラッピングサーバ機能、ＢＳＦ内で前記共有秘密を生成すること、および
   前記ＢＳＦが前記サーバに前記共有秘密を送信すること
   によって前記ＵＩＣＣと前記サーバとの間で共有される、請求項７に記載の方法。
9. 前記トランザクションが、前記デバイスに関連付けられたウォレット識別子と共に前記分散型台帳に記録される、先行する請求項のいずれかに記載の方法。
10. 前記セキュアな通信チャネルとは異なる物理通信チャネルを使用して前記デバイスを検証することによって前記分散型台帳上の前記デバイスに関連付けられた前記ウォレット識別子を生成するステップをさらに含む、請求項９に記載の方法。
11. 前記異なる物理チャネルがＳＭＳである、請求項１０に記載の方法。
12. 前記トランザクションがブロックチェーントランザクションである、先行する請求項のいずれかに記載の方法。
13. 前記トランザクションがクレジットカードまたは銀行取引である、請求項１～１１のいずれか１項に記載の方法。
14. ＵＩＣＣを有するデバイスと、
    公開鍵と秘密鍵のペアを格納する分散型台帳と、
    １つ以上のプロセッサと、前記１つ以上のプロセッサに、
    前記ＵＩＣＣを使用して前記デバイスとのセキュアな通信チャネルを提供すること、
    前記セキュアな通信チャネルを介して前記デバイスから、トランザクションを実行するための命令を受信すること、および
    前記受信した命令に応答して、前記サーバから前記分散型台帳に前記トランザクションの実行する要求を送信すること
    を行わせるように構成された命令を格納するメモリとを有するサーバと
    を備え、
    前記分散型台帳が、１つ以上のプロセッサと、前記分散型台帳の前記１つ以上のプロセッサに、
    前記サーバからの要求に応答して、前記格納された公開鍵と秘密鍵のペアを使用して前記トランザクションに署名させること
    を行わせるように構成された命令を格納するメモリとを有する、システム。
15. 前記分散型台帳の前記メモリがさらに、前記分散型台帳の前記１つ以上のプロセッサに、
    前記デバイスに関連付けられたウォレット識別子を前記分散型台帳に記録することであって、前記トランザクションが、前記デバイスに関連付けられた前記ウォレット識別子を用いて前記分散型台帳に記録されること
    を行わせるように構成された命令を含む、請求項１４に記載のシステム。
16. 前記分散型台帳の前記メモリがさらに、前記分散型台帳の前記１つ以上のプロセッサに、
    前記セキュアな通信チャネルとは異なる物理通信チャネルを使用して前記デバイスを検証することによって前記分散型台帳上の前記デバイスに関連付けられた前記ウォレット識別子を生成すること
    を行わせるように構成された命令を含む、請求項１５に記載のシステム。
17. 前記デバイスの前記ＵＩＣＣが、検証要求に応答する命令を含むセキュアなアプレットを格納するメモリをさらに備える、請求項１４～１６のいずれか１項に記載のシステム。
18. 前記トランザクションが前記デバイスの識別子に関連付けられる、請求項１４～１７のいずれか１項に記載のシステム。

Images