ホーム > 特許ランキング > ＤＡＢＣＯ ＬＩＭＩＴＥＤ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-04-03
(54)【発明の名称】ＳＩＭ暗号鍵ストレージ
(51)【国際特許分類】
H04L 9/08 20060101AFI20240327BHJP
H04L 9/32 20060101ALI20240327BHJP
H04L 9/10 20060101ALI20240327BHJP
H04W 12/0431 20210101ALI20240327BHJP
H04W 12/03 20210101ALI20240327BHJP
【ＦＩ】
H04L9/08 B
H04L9/08 E
H04L9/32 200Z
H04L9/10 A
H04W12/0431
H04W12/03
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023562473
(86)(22)【出願日】2022-04-06
(85)【翻訳文提出日】2023-12-05
(86)【国際出願番号】 GB2022050858
(87)【国際公開番号】W WO2022214804
(87)【国際公開日】2022-10-13
(31)【優先権主張番号】2105090.1
(32)【優先日】2021-04-09
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＡＮＤＲＯＩＤ
２．ＳＷＩＦＴ
３．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】523382100
【氏名又は名称】ダブコ・リミテッド
【氏名又は名称原語表記】ＤＡＢＣＯ ＬＩＭＩＴＥＤ
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】ポシュケ，ニルス
(72)【発明者】
【氏名】パーマー，デイビッド
(72)【発明者】
【氏名】ベント，ジョージ
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067EE02
5K067EE10
5K067HH23
5K067HH36
(57)【要約】
分散型台帳にトランザクションを記録するための方法およびシステムであって、方法は、デバイスのＵＩＣＣ内およびブートストラッピングサーバ機能、ＢＳＦに格納された事前プロビジョニングされた鍵を使用して、デバイスとＢＳＦとの間にセキュアなチャネルを作成するステップと、セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有するステップと、デバイスのＵＩＣＣ上に共有秘密を格納するステップと、１つ以上のトランザクションを分散型台帳のブロックに追加するステップであって、１つ以上のトランザクションが共有秘密を使用して識別される、ステップとを含む。
【特許請求の範囲】
【請求項1】
分散型台帳にトランザクションを記録する方法であって、前記方法が、デバイスのＵＩＣＣ内およびブートストラッピングサーバ機能、ＢＳＦに格納された事前プロビジョニングされた鍵を使用して、前記デバイスと前記ＢＳＦとの間にセキュアなチャネルを作成するステップと、
セキュアなチャネルを介して前記デバイスと前記ＢＳＦとの間で秘密を共有するステップと、
前記デバイスの前記ＵＩＣＣ上に前記共有秘密を格納するステップと、
分散型台帳のブロックに１つ以上のトランザクションを追加するステップであって、前記１つ以上のトランザクションが前記共有秘密を使用して識別される、ステップと
を含む、方法。
【請求項2】
前記共有秘密を前記ＢＳＦからサーバに送信するステップであって、前記共有秘密が、前記デバイスと前記サーバとの間の通信チャネルを保護するために使用され、前記サーバが、前記１つ以上のトランザクションを前記分散型台帳の前記ブロックに追加する、ステップをさらに含む、請求項１に記載の方法。
【請求項3】
前記１つ以上のトランザクションが、前記分散型台帳内の前記サーバのウォレット識別子に関連付けられ、前記１つ以上のトランザクションが、前記サーバが、前記分散型台帳の前記ブロックに追加された前記１つ以上のトランザクションのトランザクション識別子を、前記デバイスからリモートに格納すること、および
前記サーバが、前記格納されたトランザクション識別子を前記共有秘密にマッピングすること
によって識別される、請求項２に記載の方法。
【請求項4】
前記トランザクション識別子が、前記ＵＩＣＣのアイデンティティおよび前記共有秘密に基づく、請求項２または３に記載の方法。
【請求項5】
前記ブロックに追加された前記トランザクションが、前記ＵＩＣＣのアイデンティティおよび前記共有秘密に基づいてウォレット識別子によって識別される、請求項１に記載の方法。
【請求項6】
前記共有秘密が、前記ＵＩＣＣの信頼できる実行環境、ＴＥＥ内に格納される、先行する請求項のいずれかに記載の方法。
【請求項7】
前記共有秘密が対称鍵である、先行する請求項のいずれかに記載の方法。
【請求項8】
前記デバイスと前記ＢＳＦとの間に前記セキュアなチャネルを作成し、前記セキュアなチャネルを介して前記デバイスと前記ＢＳＦとの間で前記秘密を共有することが、汎用ブートストラップアーキテクチャ、ＧＢＡを使用し、および／またはＧＳＭＡ ＩｏＴセキュリティアプレットインターフェース記述、ＩｏＴ ＳＡＦＥに従う、先行する請求項のいずれかに記載の方法。
【請求項9】
前記デバイスが、ＩｏＴデバイス、ＵＥ、スマートフォン、車両、自動車、または無人航空機のいずれか１つである、先行する請求項のいずれかに記載の方法。
【請求項10】
分散型台帳と、ブートストラッピングサーバ機能、ＢＳＦと、
ＵＩＣＣを有するデバイスと、
１つ以上のプロセッサおよびメモリであって、前記メモリが、前記１つ以上のプロセッサに、
前記デバイスの前記ＵＩＣＣ内および前記ＢＳＦに格納された事前プロビジョニングされた鍵を使用して、前記デバイスと前記ＢＳＦとの間にセキュアなチャネルを作成すること、
前記セキュアなチャネルを介して前記デバイスと前記ＢＳＦとの間で秘密を共有すること、および
前記デバイスの前記ＵＩＣＣ上に前記共有秘密を格納すること、および、
前記分散型台帳のブロックに１つ以上のトランザクションを追加することであって、前記１つ以上のトランザクションが前記共有秘密を使用して識別されること
を行わせるプログラム命令を含む、１つ以上のプロセッサおよびメモリと
を備えるシステム。
【請求項11】
サーバをさらに備え、
前記ＢＳＦが、前記共有秘密を前記サーバに送信するように構成され、
前記プログラム命令がさらに、前記１つ以上のプロセッサに、前記デバイスと前記サーバとの間の通信チャネルを保護するために前記共有秘密を使用させ、前記サーバが、前記１つ以上のトランザクションを前記分散型台帳のブロックに追加する、請求項１０に記載のシステム。
【請求項12】
前記１つ以上のトランザクションが、前記サーバのウォレット識別子に関連付けられ、前記サーバがさらに、前記分散型台帳の前記ブロックに追加された前記１つ以上のトランザクションのトランザクション識別子を格納するように構成されたデータベースと、前記格納されたトランザクション識別子の前記共有される共有秘密へのマッピングとをさらに備える、請求項１１に記載のシステム。
【請求項13】
前記トランザクション識別子が、前記ＵＩＣＣのアイデンティティおよび前記共有秘密に基づく、請求項１１または１２に記載のシステム。
【請求項14】
前記ブロックに追加された前記トランザクションが、前記ＵＩＣＣのアイデンティティおよび前記共有秘密に基づいてウォレット識別子によって識別される、請求項１０に記載のシステム。
【請求項15】
前記デバイスが、前記１つ以上のプロセッサと、前記１つ以上のプロセッサに前記１つ以上のトランザクションを前記分散型台帳の前記ブロックに追加させるためのプログラム命令を含む前記メモリとを備える、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
発明の分野
本発明は、分散型台帳にトランザクションを記録するための、特にデバイスまたはオブジェクトがそのようなトランザクションを安全に生成するためのシステムおよび方法に関する。
本発明は、分散型台帳にトランザクションを記録するための、特にデバイスまたはオブジェクトがそのようなトランザクションを安全に生成するためのシステムおよび方法に関する。
【背景技術】
【0002】
発明の背景
異なるエンティティが価値を交換するために互いに対話および取引することが一般的に必要とされている。しかしながら、これがトランザクションの各当事者にとって安全かつセキュアな方法で行われるためには、トランザクションエンティティ間に信頼のレベルが存在する必要がある。そのような信頼がない場合、強制可能な契約および第三者機関または仲介者などの他の構造および手順が必要である。
異なるエンティティが価値を交換するために互いに対話および取引することが一般的に必要とされている。しかしながら、これがトランザクションの各当事者にとって安全かつセキュアな方法で行われるためには、トランザクションエンティティ間に信頼のレベルが存在する必要がある。そのような信頼がない場合、強制可能な契約および第三者機関または仲介者などの他の構造および手順が必要である。
【0003】
暗号通貨は、代替通貨（または私有通貨）の形態であるデジタル通貨である。それらは通常、中央制御された政府発行通貨（例えば、法定不換通貨）とは異なり、非中央集権型または分散型の通貨および／または交換媒体を提供する。デジタル通貨は、ある所有者またはエンティティから別の所有者またはエンティティに取引または送信されてもよく、商品の購入、サービスの購入、またはデータの取得などの任意の目的に使用されてもよい。したがって、デジタル通貨は、従来の通貨の代替手段を表す。
【0004】
暗号通貨の一例はビットコインであるが、他の多くの暗号通貨システムが考案されている。ビットコインは、Ｓａｔｏｓｈｉ Ｎａｋａｍｏｔｏによって開発され、ビットコイン技術および原理の基本を概説するオリジナルの論文「Ｂｉｔｃｏｉｎ：Ａ Ｐｅｅｒ－ｔｏ－Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍ」はｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆに記載されている。
【0005】
分散型台帳などの分散型暗号通貨の基礎となる技術は、他のタイプのトランザクションを記録するために使用することもでき、エンティティ間に存在する信頼を必要とせずに、交換の検証可能な履歴または他の形態のデータを形成することができる。ブロックチェーンなどの分散型台帳は、そのような信頼がない場合にトランザクションおよび価値の交換を行うことを可能にする。しかしながら、これは、個々の当事者またはエンティティによる破壊または制御が困難なコンセンサスを形成するために、公開ブロックチェーンの使用を必要とする。これは通常、プルーフ・オブ・ワークに基づいてコンセンサスを得ようとする競争の形をとるが、これ自体が計算および電力の形で非常に高いレベルのリソースを消費する可能性がある。
【0006】
代替的な手法は、プライベート型ブロックチェーンを使用するが、当事者とプライベート型ブロックチェーン自体の所有者およびコントローラとの間で信頼を築く必要性が再び生じる。
【0007】
信頼は、エンティティのアイデンティティまたは他の特性を決定および検証することによって築くことができるが、この努力は、オーバーヘッドおよび追加の作業を導入し、コンピュータまたは電気通信ネットワークの非効率性および追加の負荷につながる可能性がある。さらに、そのような検証またはチェックは、多くの場合、別個の情報源に依存し、その各々も検証および承認または信頼される必要があり得る。これは、かなりの帯域幅および処理リソースを必要とし得る。したがって、この手法は、オーバーヘッドが大きな負担にならない、特定の価値を超えて取引する特定のエンティティにのみ適切であり得る。これはまた、互いに新しいエンティティ間の新しい価値の交換、または低価値であるが大量の一時的な交換を妨げる。モノのインターネットまたは他の低計算量のパワーデバイスを形成するものなどの小型または多数のエンティティまたはデバイスの場合、オーバーヘッドは小さな価値交換を大幅に上回る可能性がある。したがって、これは、特に自律型または監視されていないデバイスのために、価値またはデータパッケージを交換するために必要な効率およびスケーラビリティを制限する。
【0008】
したがって、これらの問題を克服する方法およびシステムが必要とされている。
【発明の概要】
【課題を解決するための手段】
【0009】
発明の概要
トランザクションは、好ましくはブロックチェーンにブロックを追加することによって、分散型台帳に記録される。分散型台帳は、作業および報酬の証明システムを使用して個々のエンティティが制御を引き継ぐことを防止する公開台帳またはブロックチェーンである必要はない。代わりに、分散型台帳をプライベートにすることができる。イベントおよびトランザクションの検証可能な記録を提供する分散型台帳と価値を交換するエンティティとの間に信頼が築かれる必要がある。さらに、異なる当事者が、誰と取引しているかを確実に知る必要がある。これを達成するために、トランザクションが発生するデバイスは、ＳＩＭなどのＵＩＣＣを含む。ＳＩＭが製造またはパーソナライズされると、固有の１つまたは複数の鍵がＳＩＭ内のセキュアなメモリ内に格納される。（ＳＩＭに固有の）同じ鍵が、ＳＩＭを発行または所有する電気通信ネットワークに格納されるかまたは利用可能である。この鍵は、ＳＩＭの識別子に関連付けられ得る。この鍵は、ＳＩＭ（またはＳＩＭを収容するデバイス）とブートストラッピングサーバ機能（ＢＳＦ）との間にセキュアな通信チャネルを作成するために使用される。ＢＳＦは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を実装するために使用される電気通信ネットワーク内の要素である。
トランザクションは、好ましくはブロックチェーンにブロックを追加することによって、分散型台帳に記録される。分散型台帳は、作業および報酬の証明システムを使用して個々のエンティティが制御を引き継ぐことを防止する公開台帳またはブロックチェーンである必要はない。代わりに、分散型台帳をプライベートにすることができる。イベントおよびトランザクションの検証可能な記録を提供する分散型台帳と価値を交換するエンティティとの間に信頼が築かれる必要がある。さらに、異なる当事者が、誰と取引しているかを確実に知る必要がある。これを達成するために、トランザクションが発生するデバイスは、ＳＩＭなどのＵＩＣＣを含む。ＳＩＭが製造またはパーソナライズされると、固有の１つまたは複数の鍵がＳＩＭ内のセキュアなメモリ内に格納される。（ＳＩＭに固有の）同じ鍵が、ＳＩＭを発行または所有する電気通信ネットワークに格納されるかまたは利用可能である。この鍵は、ＳＩＭの識別子に関連付けられ得る。この鍵は、ＳＩＭ（またはＳＩＭを収容するデバイス）とブートストラッピングサーバ機能（ＢＳＦ）との間にセキュアな通信チャネルを作成するために使用される。ＢＳＦは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を実装するために使用される電気通信ネットワーク内の要素である。
【0010】
予め格納された鍵を使用してデバイスとＢＳＦとの間で通信チャネルが確保されると、この確保されたチャネルを介してＢＳＦとＳＩＭとの間で（デバイス内で）秘密が共有される。この共有秘密は、ＳＩＭのセキュアなストレージ内に格納される。そして、デバイスは、この共有秘密を使用して、分散型台帳のブロックに追加されたエントリまたはトランザクションを識別する。ＧＢＡを使用して共有される共有秘密を使用してまたはそれに基づいてトランザクションを識別することができるため、いずれの当事者もトランザクションを信頼することができ、その起源または発信元は宣言されたとおりである。ＳＩＭ上のデータストアは暗号的に保護され、（デバイスによってさえ）改ざん防止されるので、これは追加のセキュリティを提供し、信頼を維持する。
【0011】
トランザクションを追加することは、例えば、この共有秘密自体をトランザクション識別子の一部もしくは全部として使用することによって、またはそれから導出されることによって、トランザクション識別子内で直接共有秘密を使用し得る。しかしながら、プロキシサーバ（すなわち、デバイスと分散型台帳との間の中間部）などのサーバは、それ自体の識別子またはウォレット識別子（またはそのウォレット識別子のセットのうちの１つ）を使用してトランザクションをブロックに追加し、ＳＩＭおよびデバイスに関連付けられた共有秘密にトランザクションをマッピングする機能を実行することができる。そのようなマッピングは、プロキシサーバ内または外部にあるがプロキシサーバによってアクセス可能なデータベースまたは他のデータストアに格納され得る。したがって、トランザクション、ひいてはトランザクションが発生するエンティティは、ＳＩＭの信頼されている性質により、他の当事者またはエンティティによって信頼され得る。この実装例では、異なるエンティティ、機能、またはトランザクションタイプに対して異なるサーバが動作してもよい。
【0012】
第１の態様によれば、分散型台帳にトランザクションを記録する方法が提供され、本方法は、
デバイスのＵＩＣＣ内およびＢＳＦに格納された事前プロビジョニングされた鍵を使用して、デバイスとブートストラッピングサーバ機能、ＢＳＦとの間にセキュアなチャネルを作成するステップと、
セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有するステップと、
デバイスのＵＩＣＣ上に共有秘密を格納するステップと、
分散型台帳のブロックに１つ以上のトランザクションを追加するステップであって、１つ以上のトランザクションが共有秘密を使用して識別される、ステップと
を含む。したがって、分散型台帳へのトランザクションまたはエントリは、高度にセキュアなＳＩＭ鍵配布を無効にすることなく、改ざんが困難または不可能な方法で、それらの識別子を特定のデバイスにリンクできるので、より信頼できる。
デバイスのＵＩＣＣ内およびＢＳＦに格納された事前プロビジョニングされた鍵を使用して、デバイスとブートストラッピングサーバ機能、ＢＳＦとの間にセキュアなチャネルを作成するステップと、
セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有するステップと、
デバイスのＵＩＣＣ上に共有秘密を格納するステップと、
分散型台帳のブロックに１つ以上のトランザクションを追加するステップであって、１つ以上のトランザクションが共有秘密を使用して識別される、ステップと
を含む。したがって、分散型台帳へのトランザクションまたはエントリは、高度にセキュアなＳＩＭ鍵配布を無効にすることなく、改ざんが困難または不可能な方法で、それらの識別子を特定のデバイスにリンクできるので、より信頼できる。
【0013】
任意選択で、本方法は、
共有秘密をＢＳＦからサーバに送信するステップであって、共有秘密が、デバイスとサーバとの間の通信チャネルを保護するために使用され、サーバが、１つ以上のトランザクションを分散型台帳のブロックに追加する、ステップ
をさらに含む。したがって、サーバは、デバイスと分散型台帳またはブロックチェーンとの間のプロキシとして機能する。これにより、スケーラビリティを向上させることができる。例えば、各々が異なるデバイスもしくは機能のセットにサービスを提供する、または負荷分散の目的のための、複数のサーバが存在してもよい。
共有秘密をＢＳＦからサーバに送信するステップであって、共有秘密が、デバイスとサーバとの間の通信チャネルを保護するために使用され、サーバが、１つ以上のトランザクションを分散型台帳のブロックに追加する、ステップ
をさらに含む。したがって、サーバは、デバイスと分散型台帳またはブロックチェーンとの間のプロキシとして機能する。これにより、スケーラビリティを向上させることができる。例えば、各々が異なるデバイスもしくは機能のセットにサービスを提供する、または負荷分散の目的のための、複数のサーバが存在してもよい。
【0014】
好ましくは、１つ以上のトランザクションは、分散型台帳内のサーバのウォレット識別子に関連付けられてもよく、１つ以上のトランザクションは、
サーバが、分散型台帳のブロックに追加された１つ以上のトランザクションのトランザクション識別子を、デバイスからリモートに格納すること、および
サーバが、格納されたトランザクション識別子を共有秘密にマッピングすること
によって識別される。デバイスとの関連付けは、他の代替機構を使用して達成されてもよい。
サーバが、分散型台帳のブロックに追加された１つ以上のトランザクションのトランザクション識別子を、デバイスからリモートに格納すること、および
サーバが、格納されたトランザクション識別子を共有秘密にマッピングすること
によって識別される。デバイスとの関連付けは、他の代替機構を使用して達成されてもよい。
【0015】
任意選択で、トランザクション識別子は、ＵＩＣＣのアイデンティティおよび共有秘密に基づいてもよい。トランザクション識別子は、追加的に、デバイスの識別子（例えばＩＭＳＩ）に基づくか、またはそれから導出されてもよい。
【0016】
任意選択で、ブロックに追加されてもよいトランザクションは、ＵＩＣＣのアイデンティティおよび共有秘密に基づいてウォレット識別子によって識別される。
【0017】
好ましくは、共有秘密は、ＵＩＣＣの信頼できる実行環境、ＴＥＥ内に格納され得る。これにより、セキュリティがさらに向上する。
【0018】
有利には、共有秘密は対称鍵であり得る。対称鍵を生成および使用するために使用される例示的なアルゴリズムには、Ｔｗｏｆｉｓｈ、Ｓｅｒｐｅｎｔ、ＡＥＳ、Ｃａｍｅｌｌｉａ、Ｓａｌｓａ２０、ＣｈａＣｈａ２０、Ｂｌｏｗｆｉｓｈ、ＣＡＳＴ５、Ｋｕｚｎｙｅｃｈｉｋ、ＤＥＳなどが含まれるが、これらに限定されない。
【0019】
任意選択で、デバイスとＢＳＦとの間にセキュアなチャネルを作成し、セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有することは、汎用ブートストラップアーキテクチャ、ＧＢＡを使用してもよく、および／またはＧＳＭＡ ＩｏＴセキュリティアプレットインターフェース記述、ＩｏＴ ＳＡＦＥに従ってもよい。
【0020】
任意選択で、デバイスは、ＩｏＴデバイス、ＵＥ、スマートフォン、車両、自動車、または無人航空機のいずれか１つであってもよい。他のデバイスが使用されてもよく、または本方法を実施してもよい。
【0021】
第２の態様によれば、
分散型台帳と、
ブートストラッピングサーバ機能、ＢＳＦと、
ＵＩＣＣを有するデバイスと、
１つ以上のプロセッサおよびメモリであって、メモリが、１つ以上のプロセッサに、
デバイスのＵＩＣＣ内およびＢＳＦに格納された事前プロビジョニングされた鍵を使用して、デバイスとＢＳＦとの間にセキュアなチャネルを作成すること、
セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有すること、および
デバイスのＵＩＣＣ上に共有秘密を格納すること、および
１つ以上のトランザクションを分散型台帳のブロックに追加し、１つ以上のトランザクションが共有秘密を使用して識別されること
を行わせるプログラム命令を含む、１つ以上のプロセッサおよびメモリと
を備えるシステムが提供される。システムは、電気通信ネットワークを介して通信する構成要素を有し得る。
分散型台帳と、
ブートストラッピングサーバ機能、ＢＳＦと、
ＵＩＣＣを有するデバイスと、
１つ以上のプロセッサおよびメモリであって、メモリが、１つ以上のプロセッサに、
デバイスのＵＩＣＣ内およびＢＳＦに格納された事前プロビジョニングされた鍵を使用して、デバイスとＢＳＦとの間にセキュアなチャネルを作成すること、
セキュアなチャネルを介してデバイスとＢＳＦとの間で秘密を共有すること、および
デバイスのＵＩＣＣ上に共有秘密を格納すること、および
１つ以上のトランザクションを分散型台帳のブロックに追加し、１つ以上のトランザクションが共有秘密を使用して識別されること
を行わせるプログラム命令を含む、１つ以上のプロセッサおよびメモリと
を備えるシステムが提供される。システムは、電気通信ネットワークを介して通信する構成要素を有し得る。
【0022】
任意選択で、本システムは、
サーバをさらに備え、
ＢＳＦは、共有秘密をサーバに送信するように構成され、
プログラム命令はさらに、１つ以上のプロセッサに、デバイスとサーバとの間の通信チャネルを保護するために共有秘密を使用させ、サーバは、１つ以上のトランザクションを分散型台帳のブロックに追加する。
サーバをさらに備え、
ＢＳＦは、共有秘密をサーバに送信するように構成され、
プログラム命令はさらに、１つ以上のプロセッサに、デバイスとサーバとの間の通信チャネルを保護するために共有秘密を使用させ、サーバは、１つ以上のトランザクションを分散型台帳のブロックに追加する。
【0023】
任意選択で、１つ以上のトランザクションは、サーバのウォレット識別子に関連付けられてもよく、サーバはさらに、分散型台帳のブロックに追加された１つ以上のトランザクションのトランザクション識別子を格納するように構成されたデータベースと、格納されたトランザクション識別子の共有される共有秘密へのマッピングとをさらに備える。
【0024】
任意選択で、トランザクション識別子は、ＵＩＣＣのアイデンティティおよび共有秘密に基づいてもよい。
【0025】
好ましくは、ブロックに追加されたトランザクションは、ＵＩＣＣのアイデンティティおよび共有秘密に基づいて、ウォレットまたは他の識別子によって識別され得る。
【0026】
好ましくは、デバイスは、１つ以上のプロセッサと、１つ以上のプロセッサに１つ以上のトランザクションを分散型台帳のブロックに追加させるためのプログラム命令を含むメモリとを備える。
【0027】
上述の方法は、コンピュータを動作させるためのプログラム命令を含むコンピュータプログラムとして実装され得る。コンピュータプログラムは、コンピュータ可読媒体に記憶されてもよい。
【0028】
コンピュータシステムは、中央処理装置（ＣＰＵ）などの１つまたは複数のプロセッサ（例えば、ローカル、仮想、またはクラウドベース）、および／または単一もしくは集合のグラフィックス処理装置（ＧＰＵ）を含み得る。プロセッサは、ソフトウェアプログラムの形態のロジックを実行し得る。コンピュータシステムは、揮発性および不揮発性記憶媒体を含むメモリを含んでもよい。ロジックまたはプログラム命令を記憶するために、コンピュータ可読媒体が含まれてもよい。システムの異なる部分は、ネットワーク（例えば、無線ネットワークおよび有線ネットワーク）を使用して接続され得る。コンピュータシステムは、１つ以上のインターフェースを含むことができる。コンピュータシステムは、例えば、Ｊａｖａ（登録商標）、ＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）（ＲＴＭ）またはＬｉｎｕｘ（登録商標）などの適切なオペレーティングシステムを含むことができる。
【0029】
上記の任意の特徴は、本発明の任意の特定の態様または実施形態で使用され得ることに留意されたい。
【0030】
図面の簡単な説明
本発明は、いくつかの方法で実施することができ、ここで、添付の図面を参照して、単なる例として実施形態を説明する。
本発明は、いくつかの方法で実施することができ、ここで、添付の図面を参照して、単なる例として実施形態を説明する。
【図面の簡単な説明】
【0031】
【図1】分散型台帳にトランザクションを記録するための例示的な方法のフローチャートを示す。
【図2】ＳＩＭを有するデバイスを含む、分散型台帳にトランザクションを記録するためのシステムの概略図を示す。
【図28】データ交換内でオファーを照合するための方法の一部のシーケンス図を示す。
【発明を実施するための形態】
【0032】
図面は簡略化のために示されており、必ずしも縮尺通りに描かれていないことに留意されたい。同様の特徴には同じ参照番号が付されている。
【0033】
好ましい実施形態の詳細な説明
「モノのインターネット」は成長しており、「モノの経済」（ＥｏＴ）に移行しつつある。ＩｏＴデバイスの数は増加しており、大量のデータを生成している。ＩｏＴデバイスおよびスマートサービスは、所有権ドメインにわたって対話および相互運用し、データおよびスマートサービス価値トランザクションをほぼリアルタイムで自動的にサポートする可能性を提供する。これにより、相互運用性および機能性を向上させることができる。
「モノのインターネット」は成長しており、「モノの経済」（ＥｏＴ）に移行しつつある。ＩｏＴデバイスの数は増加しており、大量のデータを生成している。ＩｏＴデバイスおよびスマートサービスは、所有権ドメインにわたって対話および相互運用し、データおよびスマートサービス価値トランザクションをほぼリアルタイムで自動的にサポートする可能性を提供する。これにより、相互運用性および機能性を向上させることができる。
【0034】
「モノの経済」は、デバイス／サービスが互いに識別し、信頼し、必要に応じて直接またはピアツーピア機能を使用して自動的に価値を取引する能力を必要とする。デジタルＩＤ、連合セキュリティ、ならびにＩｏＴに必要なトランザクションアプリケーションおよびサービスをサポートする分散型台帳、セキュアエレメント、暗号およびデバイスウォレットに及ぶ様々な技術があるが、それらは断片化されており、コストが高く、十分にスケーラブルではない。
【0035】
トランザクションを安全に生成するためのシステムおよび方法を実装するために、様々な構成要素が使用される。図１は、分散型台帳にトランザクションを記録する方法１０のフローチャートを示す。図２は、この方法を実装するためのシステム１００の高レベルの概略図を示す。この例示的な実装形態では、分散型台帳はブロックチェーン（適切な構成要素によって生成される）１５０であり、デバイス１１０はスマートフォンなどのモバイルデバイスである。しかしながら、多くの異なるデバイスが使用されてもよい。適切なブロックチェーン技術の例については後述する。
【0036】
対称暗号化は方法１０で実施される。ステップ２０で、デバイス１１０（またはデバイス１１０内のＳＩＭ１２０）とブートストラッピングサーバ機能（ＢＳＦ）との間にセキュアな通信チャネルが作成される。ステップ３０で、ＢＳＦとデバイスとの間で秘密（すなわち、対称鍵）が共有される。ステップ４０で、この共有秘密はＳＩＭ内（例えば、ＳＩＭ内のセキュアな格納場所）に格納される。ステップ５０で、トランザクションまたはエントリが分散型台帳１５０に追加される。トランザクションの識別子は、共有秘密に基づいて生成されるか、共有秘密から導出されるか、または共有秘密を使用して識別可能である。この識別子は、例えば、特定のアルゴリズムを使用して導出され得るか、または共有秘密（例えば、データベース）とのマッピングを使用して間接的に識別され得る。
【0037】
ＧＢＡ（例えば、ＳＩＭトラスト）を使用して、デバイス１１０とＩｏＴバックエンドまたはサーバ１４０との間にセキュアなチャネルを作成してもよい。これは、デバイスとアプリケーションサーバとの間でセキュアな鍵を迅速に生成、配布、および更新することができるセキュアな鍵管理解決策を提供する。ＳＩＭトラストは対称鍵を生成する（例えば２５６ビット）。顧客および他のエンティティは、以下を含む多くの方法で対称鍵を使用することができる。
【0038】
否認防止：メッセージまたはトランザクションのソース（認証）および完全性を証明する。
【0039】
機密性：エンドツーエンドの暗号化を提供する（無線インターフェースだけではない）。
【0040】
したがって、この機構は、ＳＩＭカード１２０とコアネットワーク（ＨＬＲ、ホームロケーションレジスタ）との間の相互認証および鍵合意の上でアプリケーション層上にセキュアなチャネルを構築する。結果として、分散型台帳技術（ＤＬＴ）ノードは、ＳＩＭのアイデンティティを使用してブロックチェーンと対話し、デバイス１１０が誰であるかを確認することができる。
【0041】
トランザクションは、直接（すなわち、デバイス１１０が分散型台帳１５０と直接対話してブロックチェーン上にブロックを追加することによって）または仲介者、サーバもしくはプロキシサーバ１４０を介して分散型台帳１５０に追加され得る。このプロキシサーバ１４０は、デジタルアセットブローカ、ＤＡＢ、またはＤＡＢサービスとして説明され得る。この例示的な実装形態では、プロキシサーバ１４０は、プロキシサーバ１４０を識別する識別子を用いてトランザクションをブロックチェーンに追加する。そして、プロキシサーバ１４０は、１つ以上のデバイスの公開鍵に基づく識別子に対して追加されたトランザクションのデータストアを保持することができるが（システムは１つ以上のプロキシサーバ１４０を有してもよい）、より多くのデバイスが各々１つ以上のプロキシサーバに関連付けられる。
【0042】
したがって、ブロックチェーン上のトランザクションの識別子は、デバイス１１０のＵＩＣＣ １２０に格納された公開鍵を含むか、または公開鍵から導出されてもよく、または公開鍵から導出された識別子にマッピングされるトランザクション識別子であってもよい。識別子を導出することはまた、デバイス１１０またはユーザの一意のアイデンティティを使用することもできる。これは、例えば、ＩＭＳＩであってもよい。他の導出方式を使用してもよい。プロキシサーバ１４０を使用すると、少ない識別情報が必要とされるほど分散型台帳の処理を簡素化することができる。
【0043】
図３は、システムの高レベル機能を概略的に示す。
ＵＩＣＣ（ＳＩＭ）
システム内の役割：信頼のチェーン（顧客のアセットとしてのＳＩＭ）にセキュアなエントリポイントを提供する。本開示を通して、ＳＩＭおよびＵＩＣＣという用語は、アプリケーションおよびアプレットと同様に交換可能に使用され得る。
ＵＩＣＣ（ＳＩＭ）
システム内の役割：信頼のチェーン（顧客のアセットとしてのＳＩＭ）にセキュアなエントリポイントを提供する。本開示を通して、ＳＩＭおよびＵＩＣＣという用語は、アプリケーションおよびアプレットと同様に交換可能に使用され得る。
【0044】
バリアント：
・好ましくはＧＳＭＡ ＩｏＴ ＳＡＦＥアプレットをサポートする、ＳＩＭ上のセキュアエレメント、または
・３ＧＰＰ（登録商標）汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラスト。
・好ましくはＧＳＭＡ ＩｏＴ ＳＡＦＥアプレットをサポートする、ＳＩＭ上のセキュアエレメント、または
・３ＧＰＰ（登録商標）汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラスト。
【0045】
システムの異なる実装形態が存在する。一実装形態では、ＳＩＭまたはＵＩＣＣアプレットは、１つ以上の暗号鍵ペアを生成する。別の実装形態では、ＳＩＭまたはＵＩＣＣは暗号材料でプロビジョニングされてもよい。例えば、これは３ＧＰＰ ＧＢＡを使用することができる。しかしながら、全体を通して説明する特徴および実装形態の例または組み合わせのいずれも、いずれかまたは両方の実装形態と共に使用することができる。
【0046】
デバイス
システム内の役割：上位層に統合器を提供し（デジタルアセットブローカ、ＤＡＢ、管理コア）、通信を調和させる（異なる電気通信ネットワークからのＳＩＭまたは非ＳＩＭデバイスについても）。デバイスは、例えば、単純なＩｏＴデバイス（例えば、需給計器）から車両まで様々な形態をとることができる。
システム内の役割：上位層に統合器を提供し（デジタルアセットブローカ、ＤＡＢ、管理コア）、通信を調和させる（異なる電気通信ネットワークからのＳＩＭまたは非ＳＩＭデバイスについても）。デバイスは、例えば、単純なＩｏＴデバイス（例えば、需給計器）から車両まで様々な形態をとることができる。
【0047】
構成要素
・ＩｏＴ ＳＡＦＥアプレット用ＤＡＢミドルウェア（例示としての一例）、または
・ＳＩＭトラスト用ＤＡＢミドルウェア（図１を参照して説明した方法１０で使用される実装例）、
・貨幣化可能イベント検出のためのセンサデータ抽出
ＤＡＢ管理コア
エコシステム内の役割：オンチェーンおよびオフチェーン機能を使用するためのＤＡＢシステム内の対話の仲介。
・ＩｏＴ ＳＡＦＥアプレット用ＤＡＢミドルウェア（例示としての一例）、または
・ＳＩＭトラスト用ＤＡＢミドルウェア（図１を参照して説明した方法１０で使用される実装例）、
・貨幣化可能イベント検出のためのセンサデータ抽出
ＤＡＢ管理コア
エコシステム内の役割：オンチェーンおよびオフチェーン機能を使用するためのＤＡＢシステム内の対話の仲介。
【0048】
構成要素
・フローオーケストレーションエンジン
・共通ＡＰＩ
ＤＡＢ管理サービス
エコシステム内の役割：ＭＶＰ（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡ、ＰａｙＰａｌ）のためのフローの簡素化およびＤＡＢのカスタマイズ。
・フローオーケストレーションエンジン
・共通ＡＰＩ
ＤＡＢ管理サービス
エコシステム内の役割：ＭＶＰ（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡ、ＰａｙＰａｌ）のためのフローの簡素化およびＤＡＢのカスタマイズ。
【0049】
構成要素
・カスタマイズされたオフチェーン処理（オフチェーン）
・カスタマイズされたＡＰＩ
ＤＡＢブロックチェーンサービス
エコシステム内の役割：ＤＡＢ対話をブロックチェーン言語に変換するコネクタを提供する。
・カスタマイズされたオフチェーン処理（オフチェーン）
・カスタマイズされたＡＰＩ
ＤＡＢブロックチェーンサービス
エコシステム内の役割：ＤＡＢ対話をブロックチェーン言語に変換するコネクタを提供する。
【0050】
構成要素
・モノの台帳（Ｌｅｄｇｅｒ ｏｆ Ｔｈｉｎｇｓ）
・ＤＡＢエクスチェンジ
・スマートコントラクトエンジンを含むブロックチェーンハブ
アーキテクチャ構成要素
図４は、システムおよび方法の様々なアーキテクチャ構成要素を概略的に示す。
・モノの台帳（Ｌｅｄｇｅｒ ｏｆ Ｔｈｉｎｇｓ）
・ＤＡＢエクスチェンジ
・スマートコントラクトエンジンを含むブロックチェーンハブ
アーキテクチャ構成要素
図４は、システムおよび方法の様々なアーキテクチャ構成要素を概略的に示す。
【0051】
ＩｏＴ ＳＡＦＥアプレットの実装（例示的な一例）は便利な機能を提供するが、ＧＢＡプロビジョニング（例えば、Ｖｏｄａｆｏｎｅ ＳＩＭトラスト）の使用は、既に展開されている可能性があるレガシーＳＩＭのシステム内での使用を可能にする。したがって、（システム内で同時にまたは別々に機能することができる）両方の実装形態の組み合わせは、できるだけ多くの参加者がシステムを使用することを可能にする。デバイスファームウェアは、レガシーデバイスのために無線で更新することができ、したがって、ＧＢＡ実装（例えば、ＳＩＭトラスト）は、デバイス内のＵＩＣＣまたはＳＩＭを変更することなく使用することができる。
【0052】
図５および図６は、システム１００による両方の実装形態の使用を高レベルで示す。機構は独立しているが交換可能であり、異なるユースケースに適している場合がある。新規およびレガシーＳＩＭに柔軟性を提供するだけでなく、各実装オプションには異なる利点がある。例えば、銀行および公共サービスは、対称鍵をサポートするので、図６に示すＧＢＡ実装（例えば、ＳＩＭトラスト）と対話することを好む場合がある。図５に示すＳＩＭアプレット実装（例えばＩｏＴ ＳＡＦＥ）は、中間またはプロキシサーバ１４０を必要とせずにＵＩＣＣまたはＳＩＭによってトランザクションに直接署名できるため、改善されたブロックチェーン対話を提供する。したがって、両方の機構は、互いに企図し、特定の技術的要件を満たす。
【0053】
高いレベルでは、これらの２つの機構の主な違いは暗号手法にある。ＩｏＴ ＳＡＦＥアプレットは、主に非対称暗号化（公開鍵基盤、ＰＫＩとしても知られる）のための鍵を格納および管理するためにＳＩＭ上のセキュアエレメントを使用し、公開鍵と秘密鍵のペアが生成および格納される。ＧＢＡ（例えば、ＳＩＭトラスト）手法では、ＳＩＭとエンドポイント（例えば、ＤＡＢサーバなどのサーバ）との間の対称暗号化を確立するためにモバイルネットワーク機能が使用される。
【0054】
非対称暗号化またはＰＫＩは、公開／秘密鍵ペアを使用してｈｔｔｐｓおよびサーバ間の他の接続を保護するために多くのＩＴインフラストラクチャによって使用される技術である。
【0055】
図７および図８は、ＳＩＭ １２０と共に実行されるＩｏＴ Ｓａｆｅアプレットを使用して、ＩｏＴデバイスとサーバとの間でセキュアな通信チャネルがどのように設定され得るかを概略的に示す。図８は、デバイスがサーバとのセキュアな接続をどのように開始するかをより詳細に示す。
【0056】
デバイスには、クライアントＰＫＩ証明書（例えば、ＵＩＣＣまたはＳＩＭ内）が事前プロビジョニングされる。図９に示す例では、デバイスは車両であるが、モバイルまたはその他の任意のデバイスであってもよい。クライアントＰＫＩ証明書は、好ましくは、認証機関によって調達され署名されたパブリックトラスト証明書である。サーバは、同様のサーバ証明書を保持している。通信チャネルがクライアントによってサーバに対して開始されると、両方の当事者が認証機関（ＣＡ）を使用して互いを認証して他方の当事者の正当性を確認する交換が行われる。
【0057】
ＣＡを使用して実装される機構は、一緒に使用される鍵のペアを利用し、一方は暗号化し、他方は解読する。鍵は、第１の暗号化関数を実行するいずれかで使用することができ、他方の鍵は復号化演算を実行するために使用することができる。これらの機能を実行する２つの異なる鍵の非対称性のために、これはしばしば「非対称」暗号と呼ばれる。これらの鍵の一方は公開されており、他方は秘密である。公開暗号化システムでは、受信者の公開鍵を使用して誰でもメッセージを暗号化することができるが、受信者のみが秘密鍵を使用してメッセージを復号することができる。
【0058】
暗号化手法とは別に、ＩｏＴ ＳＡＦＥに基づく解決策は、分散型台帳（例えば、ブロックチェーン）関連環境で使用され得るさらなる機能を容易にするいくつかの追加機能を提供する。
【0059】
対称暗号化アルゴリズムは、暗号化と復号化の両方に同じ暗号鍵を使用する。鍵は、実際には、個人情報リンクを維持するために使用することができる２者以上の当事者間の共有秘密を表す。両方の当事者が同じ秘密鍵にアクセスできるという要件は、非対称暗号化と比較して、対称鍵暗号化の主な欠点の１つである。モバイル通信空間では、この解決策は、電気通信ネットワークサービスへの接続を有するモバイルＳＩＭを含むデバイスによって促進される。携帯電話は、元々ＩｏＴデバイス空間に存在する多くの要件を有し、これらの問題に対する標準ベースの解決策を使用する。これらは、２０年を超える期間にわたって開発され、精査されており、したがって、多くのエンティティおよび組織によって信頼され得る。
【0060】
電話機器が移動セルラネットワークに接続すると、電話機器は、
・モバイルネットワークとの間で認証すること、および
・モバイルネットワークとの通信を暗号化するために使用できる鍵に同意すること
を含む少なくとも２つのアクションを実行する。
・モバイルネットワークとの間で認証すること、および
・モバイルネットワークとの通信を暗号化するために使用できる鍵に同意すること
を含む少なくとも２つのアクションを実行する。
【0061】
これは、典型的には、標準ベースの認証および鍵合意（ＡＫＡ）プロトコルを使用して達成される。したがって、ＡＫＡプロトコルは、モバイル機器（ローミングまたはその他）と（場合によっては信頼されていない）セルラネットワークとの間に信頼を作り出し、その結果、２つの当事者は機密保護を伴って通信することができる。
【0062】
この代替技術は、例えばＳＩＭトラストのＶｏｄａｆｏｎｅ実装などの汎用ブートストラッピングアーキテクチャ（ＧＢＡ）として形式化されている同じＡＫＡプロトコルを使用するが、従来のセルラ使用事例とは異なり、信頼は、ユーザまたは顧客の直接制御下でデバイスとアプリケーションプラットフォームとの間に作成される。
【0063】
図１３は、このＧＢＡ実装を示す。ＵＩＣＣまたはＳＩＭがアプリケーションサーバへの標準モバイル接続を作成している間、ＡＫＡプロトコルは、デバイスと訪問先モバイルネットワークとの間の機密保護された通信を作成するために使用される。ＳＩＭトラスト（ＧＢＡプロトコルを使用）は、ＡＫＡフローを繰り返してデバイスとアプリサーバとの間の対称暗号化を作成することによって別の信頼層を追加する。その結果、２つのエンドポイント間の通信のための相互に認証されたセキュアなチャネルが得られる。
【0064】
図１０は、個々のデバイスが分散型台帳ネットワーク内のノードと通信する例示的なネットワーク構成を示す。このネットワーク構成は、特定の暗号化方式（例えば、対称暗号化または非対称暗号化を使用することができる）から独立していてもよい。図１１は、個々のノードの形態を概略的に示す。１つ以上のノードがネットワーク内に存在してもよい。
【0065】
より詳細には、図１０および図１１は、以下の特徴を示す。ＳＩＭ上（デバイス内）またはノード上のセキュアなアプレット（例えば、ＤＬＴアプレット）は、鍵を安全に生成および保持する。これらの鍵は、（ブロックチェーンを使用した）セキュアな価値交換に使用されるウォレット、証明書、および／または他のモードのデジタルトラストの表現であり得る。セキュアなアプレットは、論理的には、ホーム加入者サーバ（ＨＳＳ）のハードウェアセキュアモジュール（通信会社または事業者のコアネットワークの奥深くにある既存のネットワークエレメント）の拡張であってもよい。ＳＩＭ上のセキュアなアプレットとのＨＳＳの関係は、ＳＩＭと直接セキュアな通信チャネルを作成するために使用されるマシンであり得る別の既存のネットワークエレメント（例えば、無線ＯＴＡサーバ）によって管理され得る。Ｔｅｌｃｏノードは、例えば、セキュアなアプリケーション配信、更新、許可、およびデコミッショニングアクティビティのライフサイクルを管理するために必要な証明書を作成および管理するために、各ＤＡＢノードの非中央集権型機関との管理で動作するＤＬＴノータリーの役割を果たす。
【0066】
ｔｅｌｃｏノードはまた、システム（例えば、ＤＬＴセキュアサービス）によって提供されるサービスのＣＡ（認証機関）としても機能する。ＨＳＳの強化されたセキュリティがＤＬＴセキュアサービスを介してＳＩＭに拡張されると、ＤＡＢ ＤＬＴはＳＩＭおよび格納された鍵を使用して新しいコンセンサスプロトコル（「プルーフ・オブ・セキュアＳＩＭ」）を作成し、ＳＩＭは、ネットワーク全体にわたる高価で高処理のプルーフ・オブ・ワーク／ステークタイプの処理を必要とせずに、各トランザクション時にシステム（ＤＡＢ）上でその有効性を証明するように求められる。これにより、各ＤＡＢノードが軽量になり、ＳＩＭの計算要件が制限される（ＰＵＢ／ＰＲＶ鍵は非同期的に生成され、トランザクション開始時点で検証のためにＤＡＢ ＤＬＴに提供され得るため）。
【0067】
デバイス所有者または他のエンティティは、異なるシステムからの異種デバイスが共通のルートオブトラスト（すなわち、ＳＩＭおよびセキュアなアプレットまたはＧＢＡ対応デバイス）を使用して互いに対話できるように、スマートコントラクトまたは他の条件をプログラムまたは定義することができる。これは、デバイスが対話することを可能にする機構およびプロトコルを提供する。これは、１つ以上のノードと対話する複数のデバイス（およびそれらのＳＩＭ）で大規模に行うことができる。このプロトコルは、従来ＡＰＩを使用して解決されてきたユースケースである、デバイスがトークンをトークンに交換し、さらにトークンとデータを交換することを可能にする。さらに、このようにして有効にされたデバイス（ＤＡＢデバイス）は、アクション（例えば、アクセス制御）からデータストリーム（例えば、デバイス位置）に及ぶ価値のためにそれらの１つ以上のウォレット内のトークンを自律的に交換してもよく、二次「親」ノードは、例えば、サービス消費を管理および追跡するためにこれらのウォレットをリチャージすることができる。このシステムは、マイクロペイメントおよびマイクロビリングシステム、ならびに非中央集権型台帳のクレジット／デビットと結合され得る価値交換の要求／送信／決済を提供する。
【0068】
以下では、図１０の例示的なネットワーク構成を動作させるときにとられるステップを説明する。以下の番号は、異なる構成要素間で生じる方法ステップを示す図１２に示す番号に対応する。ここでも、いずれの暗号化方式（対称または非対称）を使用してもよい。
【0069】
０．背景：ＡおよびＢは、ＤＡＢ ＮＷに登録されており、互いに価値を交換することを許可されている。
【0070】
１．ＡおよびＢの所有者は、スマートコントラクトに合意している（すなわち、「データＸをくれたら、Ｙトークンをあげる」）。
【0071】
２．Ｂが所定のスマートコントラクト（Ｃ）に基づいてＡにデータを要求する。
３．Ｂの要求は、ＤＬＴセキュアＢセキュリティで署名され、Ｄａｐｐ Ｃ（プルーフ・オブ・セキュアＳＩＭ）によって検証される。
３．Ｂの要求は、ＤＬＴセキュアＢセキュリティで署名され、Ｄａｐｐ Ｃ（プルーフ・オブ・セキュアＳＩＭ）によって検証される。
【0072】
４．「購入」トランザクションは、ＤＡＢ ＤＬＴネットワーク上でＢに代わって公開される。
【0073】
５．Ａは、トランザクション決定の適用可能な要求をダウンロードする。
６．ＤＬＴセキュアＡは、要求（４）を検証する。
６．ＤＬＴセキュアＡは、要求（４）を検証する。
【0074】
７．デバイスＡは、「販売」したいことをＤＡＢ ＤＬＴにシグナリングする。
８．デバイスＡは、センサＡからデータＡを受信してパッケージ化する。
８．デバイスＡは、センサＡからデータＡを受信してパッケージ化する。
【0075】
９．ＤＬＴセキュアＡは、パッケージＡに署名する。
１０．Ａは、呼び出されるべきスマートコントラクトＣ上のＤＬＴ呼び出し上の交換を確認応答する。
１０．Ａは、呼び出されるべきスマートコントラクトＣ上のＤＬＴ呼び出し上の交換を確認応答する。
【0076】
１１．Ａは、パッケージＡをＢに送る（オンチェーンまたはオフチェーンのいずれか）。
【0077】
１２．ＤＬＴセキュアＢは、ＤＬＴ、ＤＬＴ記録を更新し、スマートコントラクトＣを使用して決済を開始する。
【0078】
１３．デバイスＢはＣを満たす。
１４．デバイスＡは、トークン受領を確認にする。
１４．デバイスＡは、トークン受領を確認にする。
【0079】
１５．ＤＬＴはＣクロージャを検証する。
１６．デバイスＢはパッケージＡを分析し、アクションＡの実行を決定する。
１６．デバイスＢはパッケージＡを分析し、アクションＡの実行を決定する。
【0080】
次の２つのセクションは、２つの実装がどのように動作するかについての詳細を提供する。
【0081】
ＵＩＣＣアプレット実装は、ＵＩＣＣ（例えば、ＳＩＭ）内のセキュアエレメントを使用する。ＳＩＭは、暗号鍵および通信を保護するハードウェアウォレットとして機能する。この実装は、重要なセキュリティ機能の容易かつ効率的な実装のために、ＳＩＭがＩｏＴデバイスのためのルートオブトラストを提供することを可能にする。ＳＩＭは、トランザクション署名鍵を安全に格納し、セキュアな環境内で安全に暗号アセットトランザクション署名を実行することができる。
【0082】
図１４は、ＳＩＭおよびＯＴＡサーバのアーキテクチャ設計の概略図を示す。ＳＩＭにはＧＳＭＡ ＩｏＴ ＳＡＦＥアプレットが設けられていてもよい。トランザクション署名用のＳＩＭ暗号化ウォレットを保持することに加えて、これにより、ＧＳＭＡ仕様ｈｔｔｐｓ：／／ｗｗｗ．ｇｓｍａ．ｃｏｍ／ｉｏｔ／ｗｐ－ｃｏｎｔｅｎｔ／ｕｐｌｏａｄｓ／２０１９／１２／ＩｏＴ．０５－ｖ１－ＩｏＴ－Ｓｅｃｕｒｉｔｙ－Ａｐｐｌｅｔ－Ｉｎｔｅｒｆａｃｅ－Ｄｅｓｃｒｉｐｔｉｏｎ．ｐｄｆで定義されているように、ＳＩＭハードウェアのルートオブトラストにバインドされた相互認証されたＴＬＳ接続が可能になる。
【0083】
ＧＳＭＡ ＩｏＴ ＳＡＦＥベースの解決策は、ＩｏＴ展開のためにチップからクラウドまでのセキュリティを提供する。ハードウェアのセキュアエレメント、すなわち「ルートオブトラスト」を使用して、ＩｏＴ ＳＡＦＥベースの解決策は、エンドツーエンドのセキュリティを提供する。ＧＳＭＡ標準化セキュアエレメントおよびＩｏＴ ＳＡＦＥアプレットの使用は、さらに、異なる企業間の相互運用性およびＩｏＴデバイス製造業者による一貫した使用を保証する。
【0084】
ＳＩＭ上に位置するＩｏＴ ＳＡＦＥアプレットと外部（例えば、プロキシサーバ、ブロックチェーンなど）との間の通信のために、暗号ミドルウェアライブラリもデバイス内で実行されるが、必ずしもＳＩＭ内では実行されない。
【0085】
この実装形態では、ＳＩＭとデバイスとの間、ならびにＳＩＭと無線（ＯＴＡ）サーバとの間で標準的な認証機構が発生する。これらの機構はまた、ＳＩＭ上のセキュアエレメントを含んでもよい。これは、アプリケーションおよび／またはＳＩＭをロック解除するための基本的な機構（例えば、ＰＩＮ保護を使用することによって）、ＳＩＭロック機構、ＳＩＭとデバイスアプリケーションとの間の相互認証などによって結合される。ブロックチェーントランザクションは、トランザクションの一部として送信されたデジタル署名を含むプロトコルを使用してブロックチェーンノードによって検証される。
【0086】
汎用スマートＳＩＭウォレット
ＩｏＴ ＳＡＦＥアプレットを使用することにより、ＳＩＭは、ＳＩＭのセキュアエレメント内の１つ以上の鍵コンテナまたはストレージへのアクセスを提供する。これらのコンテナは、異なるユースケースに使用されてもよく、同じユースケースまたは動作のための複数のアイデンティティを提供するために使用されてもよい。図１５は、ＳＩＭ内の複数のアイデンティティのストレージを概略的に示す。各アイデンティティは、ユーザが異なるアプリケーション内でトランザクションを認証および署名することを可能にするＳＩＭウォレットとして使用することができる。これはブロックチェーンに限定されず、従来の決済レール（例えば、他のデバイスまたは企業との直接通信）などのオフチェーン機構内で使用することもできる。ＳＩＭの無線（ＯＴＡ）更新機能は、特定の実装で使用するための新しいコンテナおよび鍵管理機能の追加を可能にする。
ＩｏＴ ＳＡＦＥアプレットを使用することにより、ＳＩＭは、ＳＩＭのセキュアエレメント内の１つ以上の鍵コンテナまたはストレージへのアクセスを提供する。これらのコンテナは、異なるユースケースに使用されてもよく、同じユースケースまたは動作のための複数のアイデンティティを提供するために使用されてもよい。図１５は、ＳＩＭ内の複数のアイデンティティのストレージを概略的に示す。各アイデンティティは、ユーザが異なるアプリケーション内でトランザクションを認証および署名することを可能にするＳＩＭウォレットとして使用することができる。これはブロックチェーンに限定されず、従来の決済レール（例えば、他のデバイスまたは企業との直接通信）などのオフチェーン機構内で使用することもできる。ＳＩＭの無線（ＯＴＡ）更新機能は、特定の実装で使用するための新しいコンテナおよび鍵管理機能の追加を可能にする。
【0087】
ＳＩＭは、異なるブロックチェーンネットワーク用の鍵に署名するための追加の鍵コンテナでパーソナライズすることができる。好ましい実装形態では、ＳＩＭにはデフォルトで利用可能な３つの鍵コンテナがある。２つのコンテナはＳＥＣＰ２５６ Ｋ１ ＥＣＤＳＡ鍵ペアを保持し、１つのコンテナはＳＥＣＰ２５６ Ｒ１ ＥＣＤＳＡ鍵ペアを保持する。しかしながら、異なる鍵ペアタイプを任意の組み合わせで使用してもよい。
【0088】
エンドツーエンドの解決策を考慮すると、ＩｏＴ（または他の）デバイス内の、ＳＩＭをハードウェアのルートオブトラストとして使用するＳＩＭ暗号ウォレットは、以下の機能のいずれかまたはすべてを提供し得る。
【0089】
・ハードウェアウォレット（署名支払い／デジタルアセット送信トランザクション）
・署名されたトランザクションの検証
・セキュアな通信
・機密データのセキュアなストレージ
したがって、ＳＩＭ自体は、以下の機能のいずれかまたはすべてを提供することができる。
・署名されたトランザクションの検証
・セキュアな通信
・機密データのセキュアなストレージ
したがって、ＳＩＭ自体は、以下の機能のいずれかまたはすべてを提供することができる。
【0090】
・追加の暗号化機能
・ＩｏＴデバイスＩＤメタデータストレージ
・セキュアなバックアップ／復元、鍵管理
・デバイス開始ブートストラップ
ＳＩＭ内で暗号鍵ボールトを使用すると、秘密鍵および秘密の改ざん防止および安全が保たれる。ＳＩＭは、一般に、専用の暗号プロセッサおよび高度に安全なＳＩＭ ＯＳを備えた改ざん防止ハードウェアであり、秘密鍵を安全にするために必要なレベルの保証を提供する。このようにしてＳＩＭに格納された鍵は、ＳＩＭ上で生成され、好ましくはＳＩＭから離れない。
・ＩｏＴデバイスＩＤメタデータストレージ
・セキュアなバックアップ／復元、鍵管理
・デバイス開始ブートストラップ
ＳＩＭ内で暗号鍵ボールトを使用すると、秘密鍵および秘密の改ざん防止および安全が保たれる。ＳＩＭは、一般に、専用の暗号プロセッサおよび高度に安全なＳＩＭ ＯＳを備えた改ざん防止ハードウェアであり、秘密鍵を安全にするために必要なレベルの保証を提供する。このようにしてＳＩＭに格納された鍵は、ＳＩＭ上で生成され、好ましくはＳＩＭから離れない。
【0091】
表１は、使用される好ましい暗号アルゴリズムのリストをまとめたものである。他のアルゴリズムが使用されてもよい。
【0092】
【表1】
【0093】
ブロックチェーンおよび暗号通貨ネットワークは通常、それらのトランザクションがピアツーピアまたは参加者のグループ内であるため、非対称暗号に依存する。異なるトランザクション間の参加者のリストは異なり得る。ブロックチェーントランザクションのこのピアツーピアの性質を考えると、対称暗号の使用は実現不可能であり得る。さらに、非対称暗号を使用すると、ブロックチェーンおよびＤＬＴトランザクションは、第三者によって監査可能である。現在のシステム内でＰＫＩを使用することにより、エンティティまたは人が秘密鍵にアクセスすることなくトランザクションを検証することが可能になる。
【0094】
ＥＭＶトークン
ＥＭＶは、Ｅｕｒｏｃａｒｄ（ＲＴＭ）、ＭａｓｔｅｒＣａｒｄ（ＲＴＭ）、Ｖｉｓａ（ＲＴＭ）の略称であり、決済アプリケーションのための定義された仕様を表し、今日のほとんどの銀行カードチップに実装されている。それは、銀行カードチップ上に安全に格納された認証情報にアクセスすることによって対称暗号と協働する。現在の環境では、ＥＭＶを使用して支払いトランザクションに署名し、それらを既存の決済レールに送信してトランザクションを可能にすることができる。したがって、ＳＩＭウォレットは、支払いアプリケーションのための（対称）鍵値を保持するために使用され、その後デバイスミドルウェアによって使用され、本システムを介したＥＭＶ支払いを容易にする。
ＥＭＶは、Ｅｕｒｏｃａｒｄ（ＲＴＭ）、ＭａｓｔｅｒＣａｒｄ（ＲＴＭ）、Ｖｉｓａ（ＲＴＭ）の略称であり、決済アプリケーションのための定義された仕様を表し、今日のほとんどの銀行カードチップに実装されている。それは、銀行カードチップ上に安全に格納された認証情報にアクセスすることによって対称暗号と協働する。現在の環境では、ＥＭＶを使用して支払いトランザクションに署名し、それらを既存の決済レールに送信してトランザクションを可能にすることができる。したがって、ＳＩＭウォレットは、支払いアプリケーションのための（対称）鍵値を保持するために使用され、その後デバイスミドルウェアによって使用され、本システムを介したＥＭＶ支払いを容易にする。
【0095】
（記載されたいずれの実装形態とも使用される）この拡張されたまたはオプションの機能では、これは、ＥＭＶによってブロックチェーンまたは既存の決済レールを使用して支払いを選択するためのオプションをユーザに提供する。セキュリティの観点から、ＳＩＭカードはすでに銀行カードの認証を通過することができる。
【0096】
複数のウォレット中のウォレット
ＳＩＭは、所望の支払い方法に関連する鍵を提供するために使用される。支払いに使用されるウォレット自体は、ＳＩＭに格納されている必要はない（しかし、格納されていてもよい）。分散型台帳と直接対話するために使用されるウォレットは、別個のエンティティ、サーバもしくはプロキシサーバ、またはブローカ（例えば、ＤＡＢ）によって提供され、特定のユースケースに応じた支払い方法の好みに基づいて選択され得る。
ＳＩＭは、所望の支払い方法に関連する鍵を提供するために使用される。支払いに使用されるウォレット自体は、ＳＩＭに格納されている必要はない（しかし、格納されていてもよい）。分散型台帳と直接対話するために使用されるウォレットは、別個のエンティティ、サーバもしくはプロキシサーバ、またはブローカ（例えば、ＤＡＢ）によって提供され、特定のユースケースに応じた支払い方法の好みに基づいて選択され得る。
【0097】
第三者文書は、ＳＩＭ無線（ＯＴＡ）上に展開され得る。デバイス上のウォレットアプリケーションは、アプリケーション（アプレット）のＳＩＭ部分と安全に対話し、（同様にＯＴＡを介して）バインディングを確立する。これは、セキュリティドメインのセキュリティおよび認証プロセス、ならびに外部アプリケーションとの統合のための承認に従う。
【0098】
鍵管理
トランザクション管理で使用される鍵のライフサイクルを管理するための明確に定義された機構が実装され得る。暗号鍵のライフサイクル管理には、鍵のバックアップ、復元、鍵の失効および更新が含まれ、紛失、盗難、および／または侵入されたデバイスを処理するためのセキュリティポリシーが実装されてもよい。秘密鍵は最も機密性の高いアセットであり、クリアな環境または保護されていない環境ではバックアップされない。ブロックチェーンのトランザクション署名鍵のバックアップおよび復元には、使用されるいくつかの異なる機構がある。
トランザクション管理で使用される鍵のライフサイクルを管理するための明確に定義された機構が実装され得る。暗号鍵のライフサイクル管理には、鍵のバックアップ、復元、鍵の失効および更新が含まれ、紛失、盗難、および／または侵入されたデバイスを処理するためのセキュリティポリシーが実装されてもよい。秘密鍵は最も機密性の高いアセットであり、クリアな環境または保護されていない環境ではバックアップされない。ブロックチェーンのトランザクション署名鍵のバックアップおよび復元には、使用されるいくつかの異なる機構がある。
【0099】
例えば、ビットコインは、シードを生成し、ＢＩＰ３９／ＢＩＰ３２仕様に基づいてシードを使用して鍵ペアを生成するために、人間が読める一連の単語に基づいて決定論的鍵生成を定義する。ＢＩＰ３９の実装は、鍵を復元するために記憶されて再入力され得るニーモニックから鍵を導出することを指定する。ＢＩＰ３２は、シードおよびインデックス値に基づいて鍵を導出する階層決定性ウォレットを定義する。そのような機構は、本システムで使用することができ、図１６に概略的に示されている。
【0100】
別の例示的な実装形態では、ＳＩＭバックアップボールトサービスは、単一のＳＩＭが完全な値を持たないように、透過的に他のＳＩＭ上に秘密鍵の構成要素または一部をバックアップする。鍵を復元することは、バックアッププロセスで使用されたＳＩＭのクラスタからバックアップされた値（Ｎ個のうちのｋ個）の構成要素を収集することを含む協調努力であり得る。
【0101】
さらなる例示的な実装形態では、ブロックチェーンスマートコントラクトベースの解決策は、バックアップおよび復元プロセスの複雑さを低減する。例えば、スマートコントラクトアカウントは、指定された条件が満たされるまで、エスクロー機構と同様のデジタルアセットを保持する。ＩｏＴデバイスに関連付けられたアカウントは、マイクロペイメントのみを扱い、デジタル値または暗号通貨を独自に保持しない。スマートコントラクトアカウントは、例えば、いくつかのデバイスが故障しているシナリオを解決するためのルール、およびアカウントを他のデバイスに送信する方法を定義することができる。
【0102】
汎用ブートストラッピングアーキテクチャ（ＧＢＡ）
汎用ブートストラッピングアーキテクチャ（ＧＢＡ）としても知られている技術仕様（３ＧＰＰ ＴＳ ３３ ２２０）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラストアーキテクチャ。証明書と同様に、ＧＢＡは当事者間の信頼を確立するために使用される。一方、証明書は、暗号機能をサポートするために互いに組み合わせて使用できる異なる鍵ペアを作成するために非対称暗号に依存する。ＧＢＡは、ハードウェアベースの信頼できる実行環境（ＴＥＥ）を使用して対称鍵を格納し、これらの対称鍵を使用して、認証、機密保護、および完全性保護の少なくとも３つの機能をサポートするために使用できる一時鍵を導出する機能を提供する。ＧＢＡ規格に関するさらなる詳細は、ＥＴＳＩ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＴＳ ３３．２２１ Ｖ１４．０（２０１７－０５）に見出すことができる。
汎用ブートストラッピングアーキテクチャ（ＧＢＡ）としても知られている技術仕様（３ＧＰＰ ＴＳ ３３ ２２０）に基づくＶｏｄａｆｏｎｅ ＳＩＭトラストアーキテクチャ。証明書と同様に、ＧＢＡは当事者間の信頼を確立するために使用される。一方、証明書は、暗号機能をサポートするために互いに組み合わせて使用できる異なる鍵ペアを作成するために非対称暗号に依存する。ＧＢＡは、ハードウェアベースの信頼できる実行環境（ＴＥＥ）を使用して対称鍵を格納し、これらの対称鍵を使用して、認証、機密保護、および完全性保護の少なくとも３つの機能をサポートするために使用できる一時鍵を導出する機能を提供する。ＧＢＡ規格に関するさらなる詳細は、ＥＴＳＩ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＴＳ ３３．２２１ Ｖ１４．０（２０１７－０５）に見出すことができる。
【0103】
ＩｏＴ環境では、ＧＢＡ ＴＥＥはＳＩＭによって提供される。ＳＩＭは、認証鍵導出および鍵合意機能をサポートするための資格情報を格納するために使用される。
【0104】
対称暗号化には、互いに通信する必要があるすべての当事者間で鍵を配布および共有する必要があるという欠点がある。これを鍵配布問題と呼ぶ。電気通信業界は、ＳＩＭ製造プロセス中に鍵が配布され、対称鍵が２つの場所に格納される対称暗号に依存している。
【0105】
１．携帯電話またはＩｏＴデバイスであり得るユーザ機器（ＵＥ）に格納されたハードウェアトークンデバイスである加入者識別モジュール（ＳＩＭ）、および
２．認証センタ（ＡｕＣ）上のオペレータコアネットワークの中央にあり、ホームロケーションレジスタ（ＨＬＲ）を介してアクセスされる。
２．認証センタ（ＡｕＣ）上のオペレータコアネットワークの中央にあり、ホームロケーションレジスタ（ＨＬＲ）を介してアクセスされる。
【0106】
この配布プロセスのセキュリティは、この鍵資料の管理においてＳＩＭ製造業者および携帯電話事業者が従う安全なプロセスに依存している。
【0107】
しかしながら、この鍵資料の配布に関与するプロセスおよび人々を標的とする多くのエンティティが知られている。アセットを保護するためにＳＩＭに依存する産業は、厳しいセキュリティプロセスおよびベンダ選択を使用することによってこの鍵配布攻撃の問題に対抗してきた。しかしながら、これは費用がかかる可能性がある。
【0108】
通信フロー
ＳＩＭカードは、アプリケーション層でのエンドツーエンドの認証および暗号化を大規模に実現するために使用できる共有鍵を導出するためのルートオブトラストとして使用される。一般に、このプロセスは３Ｇ ＡＫＡプロセス（ＡＫＡ＝認証および鍵合意）に依存する。ＡＫＡプロセスは、任意のモバイルデバイスがモバイルネットワーク（＞２Ｇ）に接続し、相互認証および鍵合意を実行するときに使用される。図１７および図１８は、ＧＢＡのＳＩＭトラスト実装に使用される通信フローを高レベルで示す。
ＳＩＭカードは、アプリケーション層でのエンドツーエンドの認証および暗号化を大規模に実現するために使用できる共有鍵を導出するためのルートオブトラストとして使用される。一般に、このプロセスは３Ｇ ＡＫＡプロセス（ＡＫＡ＝認証および鍵合意）に依存する。ＡＫＡプロセスは、任意のモバイルデバイスがモバイルネットワーク（＞２Ｇ）に接続し、相互認証および鍵合意を実行するときに使用される。図１７および図１８は、ＧＢＡのＳＩＭトラスト実装に使用される通信フローを高レベルで示す。
【0109】
デバイスとバックエンドアプリケーションとの間にセキュアなチャネルを確立するためのステップは、鍵を生成するステップと、鍵を使用してセキュアなチャネルを介してデータを交換するステップとの２つのステップからなる。
【0110】
鍵生成プロセス
鍵生成プロセスは、図１９に概略的に示されている。ＳＩＭはデバイス内のデバイスＡＰＩと対話し、デバイスは、コアネットワークと通信しているＳＩＭトラストサーバから対称鍵を取得する。デバイスは、ｈｔｔｐを介してＳＩＭトラストサーバと通信して、対称鍵の形式で共有秘密を導出する。この対称鍵は、認証されてＳＩＭ内に格納される。
鍵生成プロセスは、図１９に概略的に示されている。ＳＩＭはデバイス内のデバイスＡＰＩと対話し、デバイスは、コアネットワークと通信しているＳＩＭトラストサーバから対称鍵を取得する。デバイスは、ｈｔｔｐを介してＳＩＭトラストサーバと通信して、対称鍵の形式で共有秘密を導出する。この対称鍵は、認証されてＳＩＭ内に格納される。
【0111】
鍵を使用してセキュアなチャネルを介してデータを交換する。
共有秘密（対称鍵）が導出されると、それはデータを通信するためのチャネルを保護するために使用され得る。これは、図２０に概略的に示されている。
共有秘密（対称鍵）が導出されると、それはデータを通信するためのチャネルを保護するために使用され得る。これは、図２０に概略的に示されている。
【0112】
各ネットワークエンティティを通る通信フローを以下に説明する。
デバイス管理（ＤＭ）クライアントは、汎用認証アーキテクチャ（ＧＡＡ）サーバに鍵を問い合わせる。
デバイス管理（ＤＭ）クライアントは、汎用認証アーキテクチャ（ＧＡＡ）サーバに鍵を問い合わせる。
【0113】
ＧＡＡサーバはＳＩＭ（ＡＴ＋ＣＳＩＭ）のアイデンティティを確立する。
一方、ＧＡＡサーバは、待機するようにＤＭクライアントに通知する。
一方、ＧＡＡサーバは、待機するようにＤＭクライアントに通知する。
【0114】
ＤＭクライアントは、待機中に他の作業を処理することができる。
ＧＡＡサーバは、アイデンティティを使用してＵｂＰｒｏｘｙに認証ベクトルを求める。
ＧＡＡサーバは、アイデンティティを使用してＵｂＰｒｏｘｙに認証ベクトルを求める。
【0115】
ＵｂＰｒｏｘｙは要求を検証し、正しいブートストラッピングサーバ機能（ＢＳＦ）にルーティングする。
【0116】
ＢＳＦはＨＬＲにＡＶを要求する。
ＨＬＲはＢＳＦにＡＶを返す。
ＨＬＲはＢＳＦにＡＶを返す。
【0117】
ＢＳＦは資格情報を格納し、４０１コードでＵｂＰｒｏｘｙにベクトルのバージョンを返す。
【0118】
ＵｂＰｒｏｘｙは、同じメッセージおよびエラーコードをＧＡＡサーバに返す。
これはＳＩＭに認証を要求する。
これはＳＩＭに認証を要求する。
【0119】
有効な応答（開始時のＤＢ）は、有効な応答が抽出されてＵｂＰｒｏｘｙに送信されることを可能にする。
【0120】
それは次にそれをＢＳＦに送信する。
それは先にＨＬＲから受信したものに対してメッセージに含まれる応答を検証し、２００応答を送信する。
それは先にＨＬＲから受信したものに対してメッセージに含まれる応答を検証し、２００応答を送信する。
【0121】
ＵｂＰｒｏｘｙはＧＡＡサーバに２００応答を返す。
ＧＡＡサーバは鍵を計算し、それをＤＭクライアントに返す。
ＧＡＡサーバは鍵を計算し、それをＤＭクライアントに返す。
【0122】
ＤＭクライアントは、必要に応じて鍵を使用し、そのサーバにＩＤを渡す。
ＤＭサーバが鍵を必要とするとき、ＩＤを使用してＮＡＦを介してＵｂＰｒｏｘｙに問い合わせる。
ＤＭサーバが鍵を必要とするとき、ＩＤを使用してＮＡＦを介してＵｂＰｒｏｘｙに問い合わせる。
【0123】
ＵｂＰｒｏｘｙは、適切なＢＳＦに鍵要求を送信する。
それは鍵を計算し、それを返す。
それは鍵を計算し、それを返す。
【0124】
ＵｂＰｒｏｘｙは鍵をＤＭサーバに返す。
ＤＭサーバは必要に応じて鍵を使用する。
ＤＭサーバは必要に応じて鍵を使用する。
【0125】
ＳＩＭトラストから（例えばＶｏｄａｆｏｎｅから）開始して、デバイス側のミドルウェアは、デバイスがネットワーク内のＳＩＭとＳＩＭトラストプラットフォーム（ブートストラッピングサーバ機能、ＢＳＦ）との間でメッセージを送信することを可能にする。デバイスは、ＳＩＭトラストデバイスライブラリをサポートし、統合ソフトウェアライブラリ（ＤＤＫ）を有する。バックエンド側では、アプリケーションがＡＰＩハブを介してアプリケーション処理インターフェース（ＡＰＩ）呼び出しを使用してＳＩＭトラストプラットフォームから共有鍵を取得する。
【0126】
特定のグローバル・データ・サービス・プラットフォーム（ＧＳＤＰ）は、特定のＳＩＭカードまたはＩＭＳＩ範囲に対してＧＢＡ（例えば、ＳＩＭトラスト）を有効にすることができる。
【0127】
デバイス
汎用アーキテクチャ
ＳＩＭとＤＡＢとの間の統合器層としてデバイスを使用するために、例示的に４つの相互連結された構成要素を設けることができる。
汎用アーキテクチャ
ＳＩＭとＤＡＢとの間の統合器層としてデバイスを使用するために、例示的に４つの相互連結された構成要素を設けることができる。
【0128】
ＳＩＭ中心：ＳＩＭカード（セキュアエレメントと、暗号鍵を格納し、トランザクションおよびデータを認証および署名することができるハードウェアコンポーネントとを含む）。
【0129】
ＳＩＭ製造業者によって提供されるライブラリ：接続されたアプリケーション（例えば、記載された暗号ミドルウェア）による使用のためにＳＩＭの機能を公開するライブラリのセット。
【0130】
ミドルウェア：ＳＩＭ製造業者のライブラリを直接組み込むことができないアプリケーション、またはデバイスの外部で実行されるアプリケーションおよびデバイス（例えば、データ収集ネットワーク）のためのＳＩＭアプレットのインフラストラクチャ機能を公開するミドルウェアコンポーネント。
【0131】
イベント検出：ＤＡＢサービスの残りの部分と、またはブロックチェーンおよびマーケットプレイスおよび／またはエクスチェンジのいずれかと直接、イベントを検出および取引するアプリケーション／アルゴリズム。
【0132】
これらの構成要素は、図２１に概略的に示されている。
本サービス、およびＧＤＳＰ（管理されたＩｏＴ接続性のためのＶｏｄａｆｏｎｅのグローバルデータサービスプラットフォーム）、ＳＩＭトラスト、またはＩｏＴ ＳＡＦＥなどの既存の機能の使用と共に、デバイスは、ブロックチェーンウォレットおよび信頼された認証者の機能を果たすエッジ統合ポイントと見なすことができる。それらはまた、セキュアな自律的イベントを提供する能力、または単純なハードウェアセキュアモジュール（ＨＳＭ）として使用される能力を開く。
本サービス、およびＧＤＳＰ（管理されたＩｏＴ接続性のためのＶｏｄａｆｏｎｅのグローバルデータサービスプラットフォーム）、ＳＩＭトラスト、またはＩｏＴ ＳＡＦＥなどの既存の機能の使用と共に、デバイスは、ブロックチェーンウォレットおよび信頼された認証者の機能を果たすエッジ統合ポイントと見なすことができる。それらはまた、セキュアな自律的イベントを提供する能力、または単純なハードウェアセキュアモジュール（ＨＳＭ）として使用される能力を開く。
【0133】
ミドルウェアは、デバイスがトランザクションエコシステムに円滑に参加することを可能にし、アプリケーションが製造者ライブラリを組み込み、鍵プロビジョニングおよびトランザクション署名のためにＳＩＭ機能を消費することを可能にする。接続されたデバイスの外部で実行されるアプリケーションは、これらの機能を利用して、そのＡＰＩを介してミドルウェアにアクセスすることもできる。
【0134】
デバイスは、直接読み取りから計算分析（例えば、貨物占有評価）までの範囲のデータを処理または収集し、（ＳＩＭの場合はＰＫＩで、）暗号化され、ＳＩＭカードの秘密鍵で署名されると、任意のブロックチェーンにトークン化するか、または垂直横断的な使用のためにプラットフォーム内の他の場所に格納することができる。
【0135】
ＳＩＭ上のセキュアエレメント用ミドルウェア
図２２に示すような典型的なＩｏＴ展開は、機密データおよびデバイス認証のセキュアな送信を提供するＧＳＭＡ ＩｏＴ ＳＡＦＥから直接利益を得ることができる。それにもかかわらず、ＳＩＭアプレットとアプリケーション側との間の通信を容易にするために、デバイス上の上述のミドルウェアが必要とされる。
図２２に示すような典型的なＩｏＴ展開は、機密データおよびデバイス認証のセキュアな送信を提供するＧＳＭＡ ＩｏＴ ＳＡＦＥから直接利益を得ることができる。それにもかかわらず、ＳＩＭアプレットとアプリケーション側との間の通信を容易にするために、デバイス上の上述のミドルウェアが必要とされる。
【0136】
アーキテクチャ
ＳＩＭ上のセキュアエレメント用ミドルウェアは、モジュール式アプリケーションを介して異種のアプレット管理を抽象化し、デバイスとデジタルアセットブローカ（ＤＡＢ）サービスプラットフォームとの統合を可能にする。それは、製造業者に関係なく、アプレット管理のための統一された単一のＲＥＳＴｆｕｌ ＡＰＩ（ＳＩＭサービスＡＰＩ）を提供する。
ＳＩＭ上のセキュアエレメント用ミドルウェアは、モジュール式アプリケーションを介して異種のアプレット管理を抽象化し、デバイスとデジタルアセットブローカ（ＤＡＢ）サービスプラットフォームとの統合を可能にする。それは、製造業者に関係なく、アプレット管理のための統一された単一のＲＥＳＴｆｕｌ ＡＰＩ（ＳＩＭサービスＡＰＩ）を提供する。
【0137】
ＳＩＭ機能をデバイスに公開するために、暗号ミドルウェアライブラリは、アプレット実行プラットフォームを提供し、それとインターフェースする。ライブラリは、Ｊａｖａ、Ａｎｄｒｏｉｄ、またはＳｗｉｆｔ用のＯＳレベルＣライブラリおよび／またはフレームワーク対応モジュールを含むことができ、（展開、削除、更新など）アプレット自体を管理するための方法、ならびに各々によって利用可能にされる動作を提供する。ＤＡＢミドルウェアコンポーネントの概要を図２２に示す。
【0138】
ＳＩＭサービスＡＰＩは、前述の統一された動作を公開するベースエンドポイントのセットであり、各受信された要求に対して、暗号化コアは、例えば外部または組み込まれたＪａｖａライブラリであっても、第三者ベンダ統合オプションと対話するために必要なステップを編成する役割を果たす。これらの各々は、アプレット管理および利用のための独自のロジックフローを備えているので、個々のアダプタコンポーネントは、ＤＡＢミドルウェアプロバイダコモンズ層によってインターフェース接続され得る。これにより、異なる製造業者によって提供される動作が利用可能になる。
【0139】
実装
例示的な実装形態では、ＳＩＭカードのセキュアエレメント内で実行されるＩｏＴ ＳＡＦＥアプレットと整列した２つのデバイス構成が提供される。
例示的な実装形態では、ＳＩＭカードのセキュアエレメント内で実行されるＩｏＴ ＳＡＦＥアプレットと整列した２つのデバイス構成が提供される。
【0140】
１．携帯電話で実行されているＤＡＢアプリケーションは、ＤＡＢサービスによって指示されたようにデータセットに署名して検証するために、組み込まれたＡｎｄｒｏｉｄライブラリを介してそのＳＩＭカードに直接アクセスする。
【0141】
２．４Ｇ接続された自動車用Ｍ２Ｍルータ（テストでは、ＲａｓｐｂｅｒｒｙＰｉおよびＶｏｄａｆｏｎｅ ＵＳＢ Ｃｏｎｎｅｃｔ ４Ｇ ｖ２ドングルを使用してシミュレートされるが、他の適切なハードウェアを使用してもよい）はＳＩＭを含むが、ＤＡＢミドルウェアを介してその暗号化機能を他のアプリケーションに公開する。
【0142】
実装されたＤＡＢミドルウェアは、以下の例示的な技術を使用する。
Ｓｐｒｉｎｇ Ｂｏｏｔ；
ＯｐｅｎＡＰＩ；
Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）；ａｎｄ
ｉｏｔ－ｓａｆｅ－ｍｉｄｄｌｅｗａｒｅ．他の技術が使用されてもよい。
Ｓｐｒｉｎｇ Ｂｏｏｔ；
ＯｐｅｎＡＰＩ；
Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）；ａｎｄ
ｉｏｔ－ｓａｆｅ－ｍｉｄｄｌｅｗａｒｅ．他の技術が使用されてもよい。
【0143】
１つの例示的な実装形態では、Ｊａｖａ Ｓｐｒｉｎｇ Ｂｏｏｔは、製造業者ライブラリとの多数の可能な統合シナリオをカバーする。これはまた、それらがＪＶＭを実行することができる限り、スマートデバイスまたはＩｏＴゲートウェイを含むいくつかの種類のデバイスにそれを含める可能性を開く。ＣＰＵおよびメモリが制約され得るローエンドデバイスの場合、ＪＶＭを使用することは最も効率的な実装ではないが、ハードウェアの違いを抽象化する。
【0144】
これは、提供される各ライブラリのために拡張することができる構成可能モジュールに分割することができ、コードモジュールを直接インポートすること、またはＯＳレベルのライブラリと対話すること（例えば、ＳＩＭ製造業者によって提供されるＣライブラリがＪＮＩ外部機能インターフェースを介してインターフェース接続される必要がある場合）のいずれかによって、統合方法のより容易な統合を提供するための手法である。これは、通信ユニットに接続された同じデバイス上で実行されるスタンドアロンアプリケーションとしてインスタンス化されてもよく、またはイベント検出ソフトウェア（例えばＪａｖａベースの場合）に組み込まれてもよい。
【0145】
ＳＩＭにインストールされたＩｏＴ ＳＡＦＥアプレットによって利用可能にされる暗号化機能に関する、４つの例示的なＳＩＭサービス動作を定義することができる。これらの動作は、Ｔｈａｌｅｓ暗号ミドルウェアＣ＋＋ライブラリによって利用可能にされたＡＰＩメソッドの非常に類似したシグネチャをミラーリングしている（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＴｈａｌｅｓＧｒｏｕｐ／ｉｏｔ－ｓａｆｅ－ｍｉｄｄｌｅｗａｒｅも参照）。Ｔｈａｌｅｓによって提供される暗号ミドルウェアライブラリは、それ自体で２つの方法またはコンパイル、すなわち、通常のＡｎｄｒｏｉｄアプリ内からの直接アプレット通信用のＪａｖａ Ａｎｄｒｏｉｄライブラリ、または上述のミドルウェア手法に適したＣ＋＋ビルドで使用することができる。
【0146】
ＤＡＢミドルウェアＡＰＩ
例示的な実装形態では、ＳＩＭにインストールされたＩｏＴ ＳＡＦＥアプレットによって利用可能にされる暗号化機能に関するＳＩＭサービス動作は、公開鍵を取得するかまたはメッセージに署名する必要性に応じてアプリケーションによって呼び出される。それらはすべて「コンテナ」ベースの手法に従い（「コンテナ」は、各々がクライアント証明書および鍵ペアを保持するセキュアなメモリ空間である）、展開された各ＤＡＢユースケースは、それがどの鍵タイプまたはデジタル署名アルゴリズムを必要とするかを認識することができる。したがって、ＤＡＢミドルウェアを呼び出すときにどのパラメータ／コンテナを使用するかを認識することもできる。
例示的な実装形態では、ＳＩＭにインストールされたＩｏＴ ＳＡＦＥアプレットによって利用可能にされる暗号化機能に関するＳＩＭサービス動作は、公開鍵を取得するかまたはメッセージに署名する必要性に応じてアプリケーションによって呼び出される。それらはすべて「コンテナ」ベースの手法に従い（「コンテナ」は、各々がクライアント証明書および鍵ペアを保持するセキュアなメモリ空間である）、展開された各ＤＡＢユースケースは、それがどの鍵タイプまたはデジタル署名アルゴリズムを必要とするかを認識することができる。したがって、ＤＡＢミドルウェアを呼び出すときにどのパラメータ／コンテナを使用するかを認識することもできる。
【0147】
一例では、ＡＰＩを以下のように簡単に要約することができる。
／コンテナ：ＳＩＭのコンテナに関する情報をリストする、
／証明書：特定のコンテナのクライアント証明書を取得する、
／公開鍵：特定のクライアント証明書／コンテナの公開鍵を読み取る、および
／署名：特定のクライアント証明書／コンテナを使用してメッセージに署名する。
／コンテナ：ＳＩＭのコンテナに関する情報をリストする、
／証明書：特定のコンテナのクライアント証明書を取得する、
／公開鍵：特定のクライアント証明書／コンテナの公開鍵を読み取る、および
／署名：特定のクライアント証明書／コンテナを使用してメッセージに署名する。
【0148】
このビジネスロジックを図２３に示す。
アプリケーション
ＳＩＭウォレットを用いたトランザクション署名
ブロックチェーン、暗号通貨ネットワーク、および他のマイクロペイメントの解決策は、トランザクションに署名するノードの能力に依存している。これらのトランザクションのこのピアツーピアの性質により、ノードがトランザクションに参加したことを証明して、否認されないことを保証できることが重要である。したがって、ブロックチェーンアドレスに関連付けられた秘密鍵を安全な場所（理想的には、改ざん防止暗号モジュール）に保持することが重要である。
アプリケーション
ＳＩＭウォレットを用いたトランザクション署名
ブロックチェーン、暗号通貨ネットワーク、および他のマイクロペイメントの解決策は、トランザクションに署名するノードの能力に依存している。これらのトランザクションのこのピアツーピアの性質により、ノードがトランザクションに参加したことを証明して、否認されないことを保証できることが重要である。したがって、ブロックチェーンアドレスに関連付けられた秘密鍵を安全な場所（理想的には、改ざん防止暗号モジュール）に保持することが重要である。
【0149】
ＤＡＢミドルウェアが用意したトランザクションは、ＳＩＭに安全に保存された秘密鍵を用いて署名される。この例を図２４に概略的に示す。
【0150】
ＴＬＳ認証
ＳＩＭ（例えば、ＩｏＴ ＳＡＦＥ ＳＩＭ）に安全に格納されたクライアント鍵およびサーバルート証明書は、ＤＡＢブロックチェーンアプリケーションをサポートするためだけでなく、デバイスとクラウドで実行されているサービスとの間の相互認証されたＴＬＳセッションを実行するためにも使用できる。これを図２５に概略的に示す。
ＳＩＭ（例えば、ＩｏＴ ＳＡＦＥ ＳＩＭ）に安全に格納されたクライアント鍵およびサーバルート証明書は、ＤＡＢブロックチェーンアプリケーションをサポートするためだけでなく、デバイスとクラウドで実行されているサービスとの間の相互認証されたＴＬＳセッションを実行するためにも使用できる。これを図２５に概略的に示す。
【0151】
ＤＡＢミドルウェアはまた、ＳＩＭにインストールされたアプレットの鍵生成、ウォレット管理、および管理（インストール、削除など）に対する制御を配信することができる。これは、例えば、新しい鍵ペアを生成するため、またはデジタル署名アルゴリズムを修正するために、ＩｏＴ ＳＡＦＥアプレットに対する制御を公開することを伴い得る。
【0152】
ＳＩＭおよびデバイス製造業者の多様性のために、ＤＡＢミドルウェアは、複数の言語およびオペレーティングシステム用のソフトウェア開発キット（ＳＤＫ）として利用可能であり、ＯＥＭが独自のデバイスにそれを円滑に組み込むことを可能にする。そのＪａｖａベースの性質を考えると、別のオプションは、それをＪａｖａカード技術に移植し、すぐに使用できるＤＡＢアクセス可能性のためにすべてのＳＩＭに予めインストールされ得る単一のアプリケーションを配信することを含む。
【0153】
ＳＩＭサービスＡＰＩは、（許可されている場合には）ＤＡＢプラットフォームに接続されたアプリケーションアクセラレータまたは第三者アプリケーションによる直接デバイス管理のためにＤＡＢ ＡＰＩインベントリで利用可能である。好ましくは、これは、それ自体のユースケースで取引しているデバイスを制御するために、各ＤＡＢサービスインスタンスによって消費され得る。
【0154】
イベント検出のためのセンサデータ抽出
例示的な実装形態では、ＩｏＴ展開は、様々な機能を有することができるデバイスをエンドノードとして使用することができる。これらは、以下を含むことができる。
例示的な実装形態では、ＩｏＴ展開は、様々な機能を有することができるデバイスをエンドノードとして使用することができる。これらは、以下を含むことができる。
【0155】
センサデータを上位層（クラウドまたはサーバ）に直接転送する、または
同じ機能を実行するゲートウェイと通信する。
同じ機能を実行するゲートウェイと通信する。
【0156】
センサデータは、例えば、デバイス内で発生し得る。
スマートデバイスおよびセキュアエレメントはますます普及しており、結果として得られるデータに基づいて知識を抽出したりアクションを生成したりする能力は、ＩｏＴの自律性の鍵となりつつある。データセットを認証する能力、検出アルゴリズムを実行するアプリケーションは、ＳＩＭ暗号化アプレットにアクセスするための互換性のあるライブラリを直接組み込むか、またはＤＡＢミドルウェアを使用して選択可能な秘密鍵で情報に署名することを可能にし、変更できないデータセットをもたらすことができる。
スマートデバイスおよびセキュアエレメントはますます普及しており、結果として得られるデータに基づいて知識を抽出したりアクションを生成したりする能力は、ＩｏＴの自律性の鍵となりつつある。データセットを認証する能力、検出アルゴリズムを実行するアプリケーションは、ＳＩＭ暗号化アプレットにアクセスするための互換性のあるライブラリを直接組み込むか、またはＤＡＢミドルウェアを使用して選択可能な秘密鍵で情報に署名することを可能にし、変更できないデータセットをもたらすことができる。
【0157】
ＤＡＢデバイスはまた、ＤＡＢ駆動のユースケース（例えば、検出アルゴリズム展開、ウォレット管理など）で機能することができるデバイス側機能を展開するための制御点として機能し得る。ＤＡＢ駆動デバイスは、ＤＡＢサービスがそれらの検出ソフトウェアおよびＳＩＭアプレットを管理するためにアクセス可能であり得る。
【0158】
ＤＡＢフレームワーク
例示的な実装形態では、ＤＡＢサービスは、ＤＡＢスタックのインスタンス化されたコンポーネントであり、ＤＡＢエコシステムのトランザクションおよび認証プラットフォームとして機能する。それは、ＩｏＴデバイスがサービス／データの価値を取引する機能を提供し、モバイルＩｏＴデバイス、複数のタイプのブロックチェーン技術、および任意の第三者外部システム間の接続性を処理する。このために、ＤＡＢサービスは、トランザクションコミッタル、デジタルアイデンティティ管理、および第三者サービスアクセスのための、ユースケースオーケストレーションのセットアップのためのＲＥＳＴベースのＡＰＩを提供することができる。
例示的な実装形態では、ＤＡＢサービスは、ＤＡＢスタックのインスタンス化されたコンポーネントであり、ＤＡＢエコシステムのトランザクションおよび認証プラットフォームとして機能する。それは、ＩｏＴデバイスがサービス／データの価値を取引する機能を提供し、モバイルＩｏＴデバイス、複数のタイプのブロックチェーン技術、および任意の第三者外部システム間の接続性を処理する。このために、ＤＡＢサービスは、トランザクションコミッタル、デジタルアイデンティティ管理、および第三者サービスアクセスのための、ユースケースオーケストレーションのセットアップのためのＲＥＳＴベースのＡＰＩを提供することができる。
【0159】
好ましくは、システムはＪａｖａ Ｓｐｒｉｎｇ Ｂｏｏｔフレームワークを使用する。これにより、ほとんどのオンプレミスまたはクラウドベースのマシンで実行可能なモジュール性が可能になる。これはまた、ライブラリ、ドライバ、および通信スタックであっても、異なる種類のソフトウェアおよびハードウェアアプリケーションと相互接続するための柔軟な環境である。しかしながら、他のフレームワークが使用されてもよい。
【0160】
例示的な実装形態では、ＤＡＢサービスは、以下の技術を使用することができる。
Ｓｐｒｉｎｇ Ｂｏｏｔ、Ｗｅｂ３Ｊ、ＯｐｅｎＡＰＩ、Ｆｉｒｅｂａｓｅ Ｊａｖａ ＳＤＫ、Ｓｐｒｉｎｇ Ｑｕａｒｔｚ、Ｌｉｑｕｉｂａｓｅ、フェイルセーフＳＤＫ、ＪＪＷＴ ｌｉｂ、Ｐａｈｏ ＭＱＴＴ、ＰｏｓｔｇｒｅＳＱＬ １０、および／またはＳｐｒｉｎｇ Ｒｅａｃｔｏｒ。
Ｓｐｒｉｎｇ Ｂｏｏｔ、Ｗｅｂ３Ｊ、ＯｐｅｎＡＰＩ、Ｆｉｒｅｂａｓｅ Ｊａｖａ ＳＤＫ、Ｓｐｒｉｎｇ Ｑｕａｒｔｚ、Ｌｉｑｕｉｂａｓｅ、フェイルセーフＳＤＫ、ＪＪＷＴ ｌｉｂ、Ｐａｈｏ ＭＱＴＴ、ＰｏｓｔｇｒｅＳＱＬ １０、および／またはＳｐｒｉｎｇ Ｒｅａｃｔｏｒ。
【0161】
エコシステム内の役割
ＤＡＢサービスは、エコシステム、管理デバイス、ユースケース、フロー、およびエンティティのエンジンである。ＡＰＩを通じて公開されるすべての機能に加えて、ＤＡＢサービスは、第三者マーケットプレイスからの外部システム、他の電気通信コンポーネント、または追加のブロックチェーンネットワークを統合する。
ＤＡＢサービスは、エコシステム、管理デバイス、ユースケース、フロー、およびエンティティのエンジンである。ＡＰＩを通じて公開されるすべての機能に加えて、ＤＡＢサービスは、第三者マーケットプレイスからの外部システム、他の電気通信コンポーネント、または追加のブロックチェーンネットワークを統合する。
【0162】
ネットワークへの接続に加えて、デバイスは管理およびアクセスされ、ＤＡＢサービスを用いて、デバイスの接続、管理、認証および証明が行われる。外部エンティティ（例えば、会社）がエコシステムに参加したい場合、それはＤＡＢサービスを「サービスとして」使用してもよい。別のエンティティがデバイスの周りでより多くの制御を得たい場合、ＤＡＢサービスのインスタンスは、それら自体のデバイスでの特定の使用のために展開され、それら自体のエコシステムの部分を制御することができる。
【0163】
ＩｏＴデバイスは、計算能力が低いセンサまたは低エネルギーデバイスとして機能し得る。また、デバイスは毎回接続する必要はなく、分散型台帳（例えば、ブロックチェーン）や他のタイプのネットワークに必ずしも常時接続している必要はない。デバイスの計算負荷を低減するために、ＤＡＢサービスは、デバイスを任意の種類のネットワークと接続するためのプロキシ（またはプロキシサーバ）として機能し得る。これにより、デバイスからのデータを処理する負担が軽減され、あまり強力でないデバイスをエコシステムの一部にすることができる。
【0164】
ＤＡＢ管理コア
ＤＡＢ管理コアは、フローオーケストレーションエンジンおよびＡＰＩコンポーネントからなる、すべての当事者間の主要な通信層として機能する。フローオーケストレーションエンジンは、３つの構成要素からなる。各コンポーネントはＡＰＩを通じてアクセス可能である。
ＤＡＢ管理コアは、フローオーケストレーションエンジンおよびＡＰＩコンポーネントからなる、すべての当事者間の主要な通信層として機能する。フローオーケストレーションエンジンは、３つの構成要素からなる。各コンポーネントはＡＰＩを通じてアクセス可能である。
【0165】
フローオーケストレーションエンジン
プロビジョニングエンジンは、各ＤＡＢサービスインスタンスでインスタンス化されたユースケースのセットアップと管理の両方を処理し、特定の実装または技術とのユースケースのリンクアップを抽象化する役割を担う。さらに、プロビジョニングエンジンは、これらの技術および第三者サービスの構成を処理する。それは、（ＳＩＭサービスＡＰＩを介して）アルゴリズムおよび鍵管理を展開するためのＤＡＢスタックに参加するデバイスの管理のためのアクセス層を配信する。このコンポーネントでは、以下の機能が処理される。
プロビジョニングエンジンは、各ＤＡＢサービスインスタンスでインスタンス化されたユースケースのセットアップと管理の両方を処理し、特定の実装または技術とのユースケースのリンクアップを抽象化する役割を担う。さらに、プロビジョニングエンジンは、これらの技術および第三者サービスの構成を処理する。それは、（ＳＩＭサービスＡＰＩを介して）アルゴリズムおよび鍵管理を展開するためのＤＡＢスタックに参加するデバイスの管理のためのアクセス層を配信する。このコンポーネントでは、以下の機能が処理される。
【0166】
ビジネスルール：各デバイスが特定のネットワークまたはマーケットプレイス／エクスチェンジと行うことができる対話を定義するルールのセット。
【0167】
ユースケース管理：各ＤＡＢインスタンスの利用可能なユースケースの管理（作成・編集・削除）。また、デバイスがトリガできる使用可能なユースケースをデバイスにプロビジョニングする役割も担う。
【0168】
接続性：ＳＩＭ管理、位置サービスなどのためのＧＤＳＰなどの他のプラットフォームとの統合。
【0169】
アルゴリズム：ＳＩＭサービスＡＰＩを活用する、ＤＡＢ駆動デバイスへのアルゴリズムの管理、カタログ作成、および展開。この機能は、好ましくは無線でアップグレードされたデバイス上に高レベルのカスタマイズおよび可能性を提供し、その結果、デバイスからデータがなくなることなく、それら自体のデータに基づいて新しいイベントを発見することができる。
【0170】
認証エンジン
認証エンジンは、接続されたデバイスおよび作成されたスマートサービスのすべてのデジタルアイデンティティロジックを処理する役割を担う。デバイスからパートナーまたはサービスまでの範囲のエンティティは、ビジネスをペアリングおよび接続する（所与の時間に互いにアクセス可能なものを管理する）ために使用することができるデジタルアイデンティティを有する。したがって、このエンジンは、外部バックエンドのネットワーク内にＩｏＴデバイスエンティティを作成し、それぞれのレジストリに対して認証する能力を提供する。したがって、認証エンジンは、好ましくは一意の識別子によって、ＤＡＢエコシステムにわたってアイデンティティを一義的にアサートする。プロビジョニングされた鍵を保持し、アイデンティティおよびトランザクションの信頼性に関するコンテキストを提供するデバイスは、プラグインを許可され、実証された実証可能な由来をデータに提供することができる。
認証エンジンは、接続されたデバイスおよび作成されたスマートサービスのすべてのデジタルアイデンティティロジックを処理する役割を担う。デバイスからパートナーまたはサービスまでの範囲のエンティティは、ビジネスをペアリングおよび接続する（所与の時間に互いにアクセス可能なものを管理する）ために使用することができるデジタルアイデンティティを有する。したがって、このエンジンは、外部バックエンドのネットワーク内にＩｏＴデバイスエンティティを作成し、それぞれのレジストリに対して認証する能力を提供する。したがって、認証エンジンは、好ましくは一意の識別子によって、ＤＡＢエコシステムにわたってアイデンティティを一義的にアサートする。プロビジョニングされた鍵を保持し、アイデンティティおよびトランザクションの信頼性に関するコンテキストを提供するデバイスは、プラグインを許可され、実証された実証可能な由来をデータに提供することができる。
【0171】
トランザクションエンジン
ユースケースに応じて、異なる機能を起動することができ、このカスタマイズはＤＡＢプラットフォームの追加の利点である。このようにしてデバイスを認証することにより、受信したトランザクションが信頼できるデバイスから、すなわちＳＩＭカードの秘密鍵を介して、暗号化および署名されることが保証され、由来およびアイデンティティが保証される。したがって、複数のマーケットプレイス／エクスチェンジ（通常、各々が特定のドメインに焦点を合わせている）でトランザクションを直ちに実行することができる。
ユースケースに応じて、異なる機能を起動することができ、このカスタマイズはＤＡＢプラットフォームの追加の利点である。このようにしてデバイスを認証することにより、受信したトランザクションが信頼できるデバイスから、すなわちＳＩＭカードの秘密鍵を介して、暗号化および署名されることが保証され、由来およびアイデンティティが保証される。したがって、複数のマーケットプレイス／エクスチェンジ（通常、各々が特定のドメインに焦点を合わせている）でトランザクションを直ちに実行することができる。
【0172】
このように、トランザクションエンジンは、受信されたデバイストランザクションおよびＡＰＩ呼び出しを処理する傾向があるロジックを処理する役割を担うことができる。これは、ＤＡＢサービス層にわたって情報をリダイレクトし、コンポーネント間要求を行うことを必要とする。例えば、これは、データベース、外部システム、またはブロックチェーン統合にアクセスすることを含むことができる。候補イベントを受信すると、ＤＡＢサービスは、含まれるデータ以上に依存してどのユースケースを適用するかを決定してもよく、デバイスで選択されたアルゴリズムまたはそれらのデータ上で生成されたインサイトをチェックしてもよい。
【0173】
トランザクションが「長い」処理またはマーケットプレイスタイプのオファー／デマンド照合手順を必要とする場合、トランザクションエンジンは、セキュアなＣＰＵエンクレーブ内で特別なアルゴリズムを実行するためのサービスを提供するＤＡＢ管理サービスのオフチェーン処理コンポーネントにインターフェースを提供する。これは、ＤＡＢサービスまたは第三者によって制御されるサービスを含み得る。
【0174】
トランザクションエンジンは、データセットがＤＡＢスタックに入るイングレスエンドポイントを提供する。これらは同期ＨＴＴＰ ＰＯＳＴによってＤＡＢ（または他の通信プロトコル）に配信されてもよく、それらは解析され適用可能なユースケースにルーティングされ、それに関連する（構成された）編成されたフローが開始される。
【0175】
典型的な価値取引プロセスは、３つのステップに従うことができる。これらは、ほとんどのユースケースに適用可能であり、ユースケース実装がどのようにアプローチされるかを示す。
【0176】
受信されたメッセージは、価値取引プロセスの開始をトリガする。例えば、これは、ＤＡＢ駆動デバイスによって送信されたトランザクション（トランザクションエンジンを参照）、または第三者による消費のためにＤＡＢサービスによって展開されたカスタムＡＰＩ上で受信された特定のメッセージであってもよい。
【0177】
プロデューサのアイデンティティが検証され、アクティブ化されたユースケースが識別される。トランザクションをブロックチェーンに展開する、または外部システムもしくはＤＡＢデバイスにメッセージもしくは信号を配信するなど、結果として生じるアクションが生成される。
【0178】
アプリケーションは、商業的使用のための実行可能な実用的アプリケーションとして生じるセッション記録およびデータセット照合の概念など、単純なトークン転送を超えるいくつかの種類のユースケースをカバーすることができる。トランザクション可能な多くの種類のデータを一般化するために、トランザクションエンジンは、どのユースケースのフローをアクティブにするかを示すために必要なすべての情報を含むように、できるだけ一般的であるように概説されたＡＰＩメッセージフォーマットを実施することができる。
【0179】
例示的な実装形態において、例示的なＪＳＯＮコードを以下に示す。メッセージプロパティは、以下を示すことができる。
【0180】
ｔｒａｎｓａｃｔｉｏｎＩｄ－デバイスによって生成され、メッセージごとに一意のＵＵＩＤ、
ｕｓｅｃａｓｅＴｙｐｅ－使用されるブロックチェーン技術とユースケースの動作モード（例えば、イーサリウム、セッションベースなど）の両方を一義的に識別する必要がある、
ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ－すべてのユースケースで使用されるが、その動作モードの各ステップを記述するために必要なキーワードに限定される（例えば、開始セッション、オープンセッション、支払い）、
ｆｒｏｍＤｅｖｉｃｅ－ＳＳＩＤ－各ＳＩＭのグローバルに一意の識別コード－デバイス識別に使用される、
ｃｒｅａｔｉｏｎＤａｔｅ－デバイスによって生成されたタイムスタンプ、
ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ－現在位置を示すデバイスによって送信されたＧＰＳデータを搬送する「ｌｏｃａｔｉｏｎＯｂｊｅｃｔ」プロパティと共に、ブロックチェーン（ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ）に挿入されるデータを含む、
ｄａｔａＴｙｐｅ－ブロックチェーンに挿入されるデータのタイプ（「ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ」内に含まれるデータ）を示すために使用される。これは、そのＪＳＯＮフォーマットを区別するために使用され得る。
ｕｓｅｃａｓｅＴｙｐｅ－使用されるブロックチェーン技術とユースケースの動作モード（例えば、イーサリウム、セッションベースなど）の両方を一義的に識別する必要がある、
ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ－すべてのユースケースで使用されるが、その動作モードの各ステップを記述するために必要なキーワードに限定される（例えば、開始セッション、オープンセッション、支払い）、
ｆｒｏｍＤｅｖｉｃｅ－ＳＳＩＤ－各ＳＩＭのグローバルに一意の識別コード－デバイス識別に使用される、
ｃｒｅａｔｉｏｎＤａｔｅ－デバイスによって生成されたタイムスタンプ、
ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ－現在位置を示すデバイスによって送信されたＧＰＳデータを搬送する「ｌｏｃａｔｉｏｎＯｂｊｅｃｔ」プロパティと共に、ブロックチェーン（ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ）に挿入されるデータを含む、
ｄａｔａＴｙｐｅ－ブロックチェーンに挿入されるデータのタイプ（「ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ」内に含まれるデータ）を示すために使用される。これは、そのＪＳＯＮフォーマットを区別するために使用され得る。
【0181】
｛
“ｔｒａｎｓａｃｔｉｏｎＩｄ”：“｛｛ｖ４ｕｕｉｄ｝｝”，
“ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ”：“ｎｅｗｄａｔａ”，
“ｆｒｏｍＤｅｖｉｃｅ”：“８９８１３００９９９０９０９００００６Ｆ”，
“ｃｒｅａｔｉｏｎＤａｔｅ”：“２０２０－０４－２７Ｔ１７：３２：４７．０２０１５４Ｚ”，
“ｕｓｅＣａｓｅＴｙｐｅ”：“ｓｅｒｖｉｃｅ”，
“ｄａｔａＴｙｐｅ”：“ｇｅｎｅｒａｌｄａｔａ”，
“ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ”：｛
“ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ”：“｛＼“ｂｏｒｒｏｗｅｒ＼”：＼“Ｄａｉｍｌｅｒ＼”，…｝”，
“ｌｏｃａｔｉｏｎＯｂｊｅｃｔ”：“｛＼“ｌｏｃａｔｉｏｎ＿ｄａｔａ＼”：｛＼“ｌａｔ＼”：５１…｝｝”｝
｝
データ永続性サービスなどのサポート機能
データ永続性サービスは、ユースケースオーケストレーション、デバイス構成、デバイスサービス関連データ、およびデータセットハッシュを記述する情報を格納するためにＤＡＢサービスが必要とするすべてのデータベース接続性を扱う。これは、特にタイミングが重要になるときに使用され得る。
“ｔｒａｎｓａｃｔｉｏｎＩｄ”：“｛｛ｖ４ｕｕｉｄ｝｝”，
“ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ”：“ｎｅｗｄａｔａ”，
“ｆｒｏｍＤｅｖｉｃｅ”：“８９８１３００９９９０９０９００００６Ｆ”，
“ｃｒｅａｔｉｏｎＤａｔｅ”：“２０２０－０４－２７Ｔ１７：３２：４７．０２０１５４Ｚ”，
“ｕｓｅＣａｓｅＴｙｐｅ”：“ｓｅｒｖｉｃｅ”，
“ｄａｔａＴｙｐｅ”：“ｇｅｎｅｒａｌｄａｔａ”，
“ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ”：｛
“ｂｌｏｃｋｃｈａｉｎＯｂｊｅｃｔ”：“｛＼“ｂｏｒｒｏｗｅｒ＼”：＼“Ｄａｉｍｌｅｒ＼”，…｝”，
“ｌｏｃａｔｉｏｎＯｂｊｅｃｔ”：“｛＼“ｌｏｃａｔｉｏｎ＿ｄａｔａ＼”：｛＼“ｌａｔ＼”：５１…｝｝”｝
｝
データ永続性サービスなどのサポート機能
データ永続性サービスは、ユースケースオーケストレーション、デバイス構成、デバイスサービス関連データ、およびデータセットハッシュを記述する情報を格納するためにＤＡＢサービスが必要とするすべてのデータベース接続性を扱う。これは、特にタイミングが重要になるときに使用され得る。
【0182】
ＤＡＢ管理コアの機能は、プラットフォームＧＵＩによってサポートされてもよい。これは、ＩＮＶＥＮＴによって実施されてもよいが、他の技術を使用してもよい。
【0183】
共通ＡＰＩ
フローオーケストレーションエンジンは、ユースケース、認証およびトランザクションを構築および管理するのに適したエンドポイントを提供するために、コア機能の共通ＡＰＩのセットを必要とする場合がある。
フローオーケストレーションエンジンは、ユースケース、認証およびトランザクションを構築および管理するのに適したエンドポイントを提供するために、コア機能の共通ＡＰＩのセットを必要とする場合がある。
【0184】
ＤＡＢ管理サービス
ＤＡＢ管理サービス機能は、特定の業界垂直またはユースケースに関連するカスタマイズされたデータ処理を実施することができる場所として機能する。それは、ＤＡＢ管理コアから独立していてもよく、ＤＡＢ対話のために第三者サービスを統合する必要が生じたときにいつでも定義および開発することができる独自のＡＰＩを有してもよい。スケーラビリティを向上させるために、コア要素はカスタマイズされた要素から独立していてもよい。
ＤＡＢ管理サービス機能は、特定の業界垂直またはユースケースに関連するカスタマイズされたデータ処理を実施することができる場所として機能する。それは、ＤＡＢ管理コアから独立していてもよく、ＤＡＢ対話のために第三者サービスを統合する必要が生じたときにいつでも定義および開発することができる独自のＡＰＩを有してもよい。スケーラビリティを向上させるために、コア要素はカスタマイズされた要素から独立していてもよい。
【0185】
カスタマイズされたオフチェーン処理
トランザクションが照合処理を必要とする場合（例えば、トラック容量）、またはマイクロペイメント集約の場合（例えば、料金徴収サービス）、アルゴリズムは、Ｐｙｔｈｏｎおよびソフトウェアガードエクステンション（ＳＧＸ）エンクレーブで実行することができる。
トランザクションが照合処理を必要とする場合（例えば、トラック容量）、またはマイクロペイメント集約の場合（例えば、料金徴収サービス）、アルゴリズムは、Ｐｙｔｈｏｎおよびソフトウェアガードエクステンション（ＳＧＸ）エンクレーブで実行することができる。
【0186】
カスタマイズされたＡＰＩ
ユースケースが外部システムによってトリガされるために特定の統合が必要な場合、ＤＡＢサービスによって公開されたエンドポイントは、このコンポーネントに編成され得る。これらのユースケースは、一般に、ＤＡＢにデジタルデバイスのアイデンティティを問い合わせる、署名を要求する、またはブロックチェーントランザクションをトリガするなど、ＤＡＢスタックに既に存在するデータに依存する。これらの特注の制御点は、ＲＥＳＴを超えて、ＳＯＡＰ、ＭＱＴＴなどのＪａｖａによってサポートされる任意の他の技術で利用可能にすることができる。
ユースケースが外部システムによってトリガされるために特定の統合が必要な場合、ＤＡＢサービスによって公開されたエンドポイントは、このコンポーネントに編成され得る。これらのユースケースは、一般に、ＤＡＢにデジタルデバイスのアイデンティティを問い合わせる、署名を要求する、またはブロックチェーントランザクションをトリガするなど、ＤＡＢスタックに既に存在するデータに依存する。これらの特注の制御点は、ＲＥＳＴを超えて、ＳＯＡＰ、ＭＱＴＴなどのＪａｖａによってサポートされる任意の他の技術で利用可能にすることができる。
【0187】
ＤＡＢブロックチェーンサービス
モノの台帳
モノの台帳は、例えば、Ｃｏｒｄａネットワークに基づいてデジタルＩＤを作成、維持、および使用する能力を提供する（他の分散型台帳技術が使用されてもよい）。これはその後、認証およびトランザクション署名のためにＤＡＢ管理コアによって消費される。モノの台帳上のデバイスのバルクプロビジョニングは、企業が多数のデバイスのデジタルツインを容易かつ同時に作成することを可能にする。ＤＡＢエクスチェンジは、デバイスおよびユースケースを互いに自動的にマッピングするための重要な差別化要因となるイベント検出を含む。
モノの台帳
モノの台帳は、例えば、Ｃｏｒｄａネットワークに基づいてデジタルＩＤを作成、維持、および使用する能力を提供する（他の分散型台帳技術が使用されてもよい）。これはその後、認証およびトランザクション署名のためにＤＡＢ管理コアによって消費される。モノの台帳上のデバイスのバルクプロビジョニングは、企業が多数のデバイスのデジタルツインを容易かつ同時に作成することを可能にする。ＤＡＢエクスチェンジは、デバイスおよびユースケースを互いに自動的にマッピングするための重要な差別化要因となるイベント検出を含む。
【0188】
ブロックチェーンハブおよびスマートコントラクトエンジン
ブロックチェーンハブ
ブロックチェーンハブは、ブロックチェーン実装によって選択された異なる統合機構を管理し、ＤＡＢコアサービスに相互接続機能を提供する。これらの機構は、組み込みＪａｖａライブラリの使用から、ＤＡＢサービス自体と共に実行される外部アプリケーションとのシステムレベルの相互作用にまで及ぶ場合がある。したがって、層は、それらの使用に必要なすべてのロジックを技術またはパートナーによって分離する異なるクラスを提供する。（プロビジョニングエンジンを介して）ユースケースを構築するとき、プログラマは、これらのコネクタのうちの１つを容易に選択し、特定のノード、サーバ、または資格情報を使用するようにそれを構成し、トランザクション管理のための単純な方法を提供されることを期待する。
ブロックチェーンハブ
ブロックチェーンハブは、ブロックチェーン実装によって選択された異なる統合機構を管理し、ＤＡＢコアサービスに相互接続機能を提供する。これらの機構は、組み込みＪａｖａライブラリの使用から、ＤＡＢサービス自体と共に実行される外部アプリケーションとのシステムレベルの相互作用にまで及ぶ場合がある。したがって、層は、それらの使用に必要なすべてのロジックを技術またはパートナーによって分離する異なるクラスを提供する。（プロビジョニングエンジンを介して）ユースケースを構築するとき、プログラマは、これらのコネクタのうちの１つを容易に選択し、特定のノード、サーバ、または資格情報を使用するようにそれを構成し、トランザクション管理のための単純な方法を提供されることを期待する。
【0189】
異なるタイプの分散型台帳を使用してもよい。例えば、以下の３つの異なるブロックチェーンを使用することができる。
【0190】
Ｃｏｒｄａネットワークでは、ＤＬＴネットワークのいくつかのノードとのＲＥＳＴｆｕｌ ＡＰＩを介してトランザクションが行われる。ＲＰＣコネクタを使用することも可能であるが、ＲＥＳＴｆｕｌ ＡＰＩは低摩擦で容易な統合を提供する。
【0191】
ｉＥｘｅｃネットワークでは、連続するオペレーティングシステムプロセスが実行され、（パートナーのドキュメントに記載されているような）順序付けられたコマンドのセットが、ＤＡＢインスタンスと並んでインストールされたＮｏｄｅＪＳクライアント（ｉＥｘｅｃ ＳＤＫ）に発行され、ＤＡＢによって処理および解釈される必要があるテキストＪＳＯＮ出力を同期して実行および返す。
【0192】
ＥＷＦは、データマーケットプレイスとしてイーサリウムブロックチェーンを使用するシステムを構築したが、デバイスの参加はＭＱＴＴメッセージを受信するのみのデータ処理能力のない（ｄｕｍｂ）デバイスに限定されることを考慮している。したがって、それらのＥＷＦをＤＡＢサービスに統合するために、ＭＱＴＴクライアント／コネクタは、ＤＡＢサービスが許可するすべてのデバイスのすべてのＥＷＦフローを管理する。
【0193】
既存のブロックチェーン実装の複雑さを考慮すると、ＧｅｔｈおよびＷｅｂ３などのライブラリに基づいてさらなるコネクタを統合して、きめ細かい接続オプションを強化することが可能である。
【0194】
例示的なユースケース
ユースケース：「サービスの支払い」
このユースケースは、駐車または料金（自動車）のようなサービスを使用および支払いするためにトークン交換がどのように使用され得るかを示す。Ｒ３ Ｃｏｒｄａ技術は、ワンタイムトークン／支払いトランザクションを作成するためにトークンＳＤＫフレームワークを実装する。ネットワーク内の５つのノードは、権限ノードとして機能する１つのノータリー、サービス用の２つのノード、およびコンシューマ用の２つのノードを含む。Ｒ３ Ｃｏｒｄａブロックチェーン上の各ノードは、サービス会社（例えば、駐車、料金徴収会社またはＥＶ充電提供者）などの主要エンティティ、および自動車会社などのコンシューマ企業を表す。各デバイスはトランザクションをトリガすることができるが、そのアイデンティティは必ずしもブロックチェーン自体にミラーリングされるわけではなく、トリガしているスマートコントラクト上に表されてもよい。これを図２６に概略的に示す。
ユースケース：「サービスの支払い」
このユースケースは、駐車または料金（自動車）のようなサービスを使用および支払いするためにトークン交換がどのように使用され得るかを示す。Ｒ３ Ｃｏｒｄａ技術は、ワンタイムトークン／支払いトランザクションを作成するためにトークンＳＤＫフレームワークを実装する。ネットワーク内の５つのノードは、権限ノードとして機能する１つのノータリー、サービス用の２つのノード、およびコンシューマ用の２つのノードを含む。Ｒ３ Ｃｏｒｄａブロックチェーン上の各ノードは、サービス会社（例えば、駐車、料金徴収会社またはＥＶ充電提供者）などの主要エンティティ、および自動車会社などのコンシューマ企業を表す。各デバイスはトランザクションをトリガすることができるが、そのアイデンティティは必ずしもブロックチェーン自体にミラーリングされるわけではなく、トリガしているスマートコントラクト上に表されてもよい。これを図２６に概略的に示す。
【0195】
スマートコントラクト（Ｃｏｒｄａ上のフロー）に関しては、ネットワークを管理するためのすべてのフローに加えて、各エンティティの各デバイスによって行われるトランザクションを作成および記録するためのメインフロー（すべてのトランザクションの閲覧、情報の収集、または計算の実行を含む）。ＣｏｉｎＴｏｋｅｎＴｙｐｅＣｏｎｔｒａｃｔは、ＣｒｅａｔｅＥｖｏｌｖａｂｌｅＴｏｋｅｎＦｌｏｗオブジェクトを表す。そのフローをトリガするとき、フローを開始しているデバイスのアイデンティティなどのいくつかの必須フィールドがあり、そのエンティティは、サービスのコンシューマであるそのデバイスを表す。ＡＰＩは、ネットワーク上のトランザクションを管理およびトリガし、それらを外部ポータルおよびアプリケーションと統合する。
【0196】
ネットワークは、アクセスおよびネットワーク利用可能なポートおよびＡＰＩに基づいて定義された構造を有するエンティティによって分離された、ＡＷＳ（または他の）環境に展開され得る。各ノードは、独自のＡＰＩを提供し、かつ利用可能なネットワークの残りの部分とは独立して動作することができる、独自のウェブサーバを有する。
【0197】
機能の統合は、スマートフォンまたは他のデバイス（例えば、Ａｎｄｒｏｉｄ携帯）内で行われている。プラットフォームは、ネットワークを監視し、手動でアクションをトリガすることができる。この解決策は、ＲＥＳＴおよびＳＳＨを使用して、ノード上で直接Ｒ３ Ｃｏｒｄａインスタンスとインターフェースし、ネットワークトランザクションの監視、新しいトランザクションのトリガ、およびＮｏｄｅ－ＣＬＩを介したノードの制御などの管理された機能を提供する。次のイメージは、その機能を詳細に示している。
【0198】
自動車のシナリオでは、Ｒ３ Ｃｏｒｄａブロックチェーン機能を使用することによって、サービスに対する支払いを自動的に達成することができる。
【0199】
インターフェース／依存関係
様々なインターフェースは、ＲＥＳＴｆｕｌ（または他の）ＡＰＩを介してノード上のトランザクションの制御およびトリガを可能にする。ＲＰＣおよびＳＳＨを含む他のインターフェースが使用されてもよい（図２６参照）。
様々なインターフェースは、ＲＥＳＴｆｕｌ（または他の）ＡＰＩを介してノード上のトランザクションの制御およびトリガを可能にする。ＲＰＣおよびＳＳＨを含む他のインターフェースが使用されてもよい（図２６参照）。
【0200】
以下は、それらの機能の説明と共に、使用され得る例示的なＡＰＩのリストを提供する。これらのＡＰＩは、内部で使用されてもよく、または外部エンティティによってアクセスされてもよい。
【0201】
名称 説明
ｇｅｔＭｅ ノードが誰であるかに関する情報を取得する。
ｇｅｔＭｅ ノードが誰であるかに関する情報を取得する。
【0202】
ｇｅｔＰｅｅｒｓ ネットワーク上の他のノードに関する情報を取得する。
ｇｅｔＮｅｔｗｏｒｋＭａｐ 接続のネットワークマップを取得する。
ｇｅｔＮｅｔｗｏｒｋＭａｐ 接続のネットワークマップを取得する。
【0203】
ｇｅｔＮｅｔｗｏｒｋＦｅｅｄ トランザクションのネットワークフィードを取得する。
【0204】
ｇｅｔＮｅｔｗｏｒｋＰａｒａｍｅｔｅｒｓ ネットワーク実装パラメータを取得する。
【0205】
ｇｅｔＲｅｇｉｓｔｅｒｅｄＦｌｏｗｓ そのノードの実行可能なフローのリストを取得する。
【0206】
ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩＤ ノードが関与したトランザクションＩＤのリストを取得する。
【0207】
ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩｎｆｏＢｙＩＤ ＩＤによりトランザクションの情報を取得する。
【0208】
ｇｅｔＮｕｍｂｅｒＯｆＴｒａｎｓａｃｔｉｏｎｓ ネットワーク内のトランザクション数を取得する。
【0209】
ｇｅｔＴｒａｎｓａｃｔｉｏｎｓＩｎｖｏｌｖｅｄ ノードが関与したトランザクション情報のリストを取得する。
【0210】
ｇｅｔＮｕｍｂｅｒＯｆＴｒａｎｓａｃｔｉｏｎｓＩｎｖｏｌｖｅｄ ノードが関与したトランザクションの数を取得する。
【0211】
ｇｅｔＮｏｄｅＩｎｆｏ ノード自体に関する情報を取得する。
ｇｅｔＮｏｄｅＴｉｍｅ ノードの現在時刻を取得する。
ｇｅｔＮｏｄｅＴｉｍｅ ノードの現在時刻を取得する。
【0212】
ｇｅｔＴｒａｎｓａｃｔｉｏｎｓ すべてのトランザクションの情報のリストを取得する。
【0213】
ｇｅｔＶｏｄａｃｏｉｎｓ 「Ｖｏｄａｃｏｉｎｓ」の残高の数字を取得する。
ｐｏｓｔＣｒｅａｔｅＴｘ ネットワーク上でトランザクションを作成する。ビジネスロジックの項に記載
分散型台帳内（例えば、ブロックチェーンネットワーク）の各ノードについて、ＡＰＩは複製可能であり、ネットワークの残りの部分と対話するために同じタイプのフローを実行することができる。
ｐｏｓｔＣｒｅａｔｅＴｘ ネットワーク上でトランザクションを作成する。ビジネスロジックの項に記載
分散型台帳内（例えば、ブロックチェーンネットワーク）の各ノードについて、ＡＰＩは複製可能であり、ネットワークの残りの部分と対話するために同じタイプのフローを実行することができる。
【0214】
ビジネスロジック
ＤＬＴ（例えば、Ｃｏｒｄａ）との対話は、確立されたＲＥＳＴエンドポイントおよびＳＳＨ接続のセットを介して行われるため、ＤＡＢブロックチェーンサービスコネクタは、台帳からのデータの挿入および取得に必要なコールフローを調整する。これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、公開層に記述されたメッセージフォーマットに従ってトランザクションを構築する。
ＤＬＴ（例えば、Ｃｏｒｄａ）との対話は、確立されたＲＥＳＴエンドポイントおよびＳＳＨ接続のセットを介して行われるため、ＤＡＢブロックチェーンサービスコネクタは、台帳からのデータの挿入および取得に必要なコールフローを調整する。これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、公開層に記述されたメッセージフォーマットに従ってトランザクションを構築する。
【0215】
この機能のために、サービス支払いシナリオ（ｕｓｅＣａｓｅＴｙｐｅ「ｓｅｒｖｉｃｅ」）は、「ｎｅｗｄａｔａ」トランザクションタイプのみを必要とする。例えば、アプリケーション（ＤＡＢアプリ）を使用していくつかのユースケースおよびシナリオを手動でトリガすることが可能である。
【0216】
混雑課金、ワン・タイム・パーキング、または任意の他のサービスのようなサービスの支払いのために、ユーザは、ＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ」、タブ「サービス」を選択し、フィールドに入力する。
【0217】
借り手－トークン／価値を譲渡したい相手（サービスプロバイダ）
価値－トークン数
タイプ：
ＭＩＮ－持続時間量（例えば、分）
ＣＣ－金銭的価値における混雑課金額
支払い－金銭的価値における任意の他の支払い
サブ値－選択された支払いタイプに対応する数値（例えば、３分、３ユーロ、３ボーダコイン）
ＶＩＮ－車両Ｖｉｎ
スロットＩＤ－例えば、駐車スロットまたは料金所を指定するために使用できる任意選択のフィールド
場所－例えば、混雑領域入口点または駐車場所を指定するために使用することができる任意選択のフィールド
ＩＣＣＩＤ－ＳＩＭカードＩＣＣＩＤまたはＵＩＣＣ
これは、ＪＳＯＮオブジェクトに変換され得る。
価値－トークン数
タイプ：
ＭＩＮ－持続時間量（例えば、分）
ＣＣ－金銭的価値における混雑課金額
支払い－金銭的価値における任意の他の支払い
サブ値－選択された支払いタイプに対応する数値（例えば、３分、３ユーロ、３ボーダコイン）
ＶＩＮ－車両Ｖｉｎ
スロットＩＤ－例えば、駐車スロットまたは料金所を指定するために使用できる任意選択のフィールド
場所－例えば、混雑領域入口点または駐車場所を指定するために使用することができる任意選択のフィールド
ＩＣＣＩＤ－ＳＩＭカードＩＣＣＩＤまたはＵＩＣＣ
これは、ＪＳＯＮオブジェクトに変換され得る。
【0218】
自動的なトリガおよび統合（例えば、自動車の統合）は、ブロックチェーンとの改善された直接対話を提供する。さらに、ネットワークパーティ間の決済が容易になり得る。ブロックチェーンは、コンシューマまたは当事者間で行われたすべてのトランザクションを登録することができるため、サービスは、それらの間で決済が行われながら同じネットワークで取引することができる。スマートコントラクト／フローは、特定の債務を決定し、ある当事者から別の当事者に資金を自動的に送信することができる。あるいは、外部請求システムは、ネットワーク上に存在するすべての単一トランザクションを集約することができる。
【0219】
ユースケース：「イベント駆動フリート」
このユースケースは、データを生成し、ブロックチェーンベースのマーケットプレイス／エクスチェンジを提供するために直接使用することができる。これは、異なる状況およびシナリオで実施され得る。例示的な実施態様では、物流会社は貨物輸送能力を完全に利用しない場合がある。センサ生成データは、エッジ秘密計算ユニットを使用して処理され、マーケットプレイスまたはエクスチェンジで共有されると、他の当事者またはエンティティによって検索および入札または購入され得る「オファー」データセットを構築することができる。この例では、ｉＥｘｅｃプラットフォームを使用して、ＤＡＢサービスによってキューに入れられ、Ｉｎｔｅｌ ＳＧＸエングレーブを使用して実行されるｉＥｘｅｃを使用してスクリプト化されたカスタムオフチェーンアルゴリズムによって実行されるジョブを照合した。これを図２７に概略的に示す。
このユースケースは、データを生成し、ブロックチェーンベースのマーケットプレイス／エクスチェンジを提供するために直接使用することができる。これは、異なる状況およびシナリオで実施され得る。例示的な実施態様では、物流会社は貨物輸送能力を完全に利用しない場合がある。センサ生成データは、エッジ秘密計算ユニットを使用して処理され、マーケットプレイスまたはエクスチェンジで共有されると、他の当事者またはエンティティによって検索および入札または購入され得る「オファー」データセットを構築することができる。この例では、ｉＥｘｅｃプラットフォームを使用して、ＤＡＢサービスによってキューに入れられ、Ｉｎｔｅｌ ＳＧＸエングレーブを使用して実行されるｉＥｘｅｃを使用してスクリプト化されたカスタムオフチェーンアルゴリズムによって実行されるジョブを照合した。これを図２７に概略的に示す。
【0220】
販売者は、ルートを販売したいときはいつでも、手動または自動でＤＡＢアプリのＵＩに入力し、それをｉＥｘｅｃマーケットプレイスの他のエクスチェンジに挿入するようにＤＡＢサービスに要求する。別のエンティティは、アプリケーション内の同様のプロセスまたはレイアウトを使用して、それらのニーズを記述してもよい。互換性のあるオファー（過去と未来の両方）を検索して照合してもよい。ＤＡＢサービスは、これらのクエリを受信し、照合ジョブを展開し、一致するものが見つかった場合に双方に通知する。
【0221】
検出アルゴリズムによって生成されたデータセットの自動展開を使用してもよい。
インターフェース／依存関係
テストシステムでは、オファーおよびデマンドトランザクションを構築し、それらをＤＡＢサービスのトランザクションエンジンに送信するために、ＤＡＢアプリ（ＡｎｄｒｏｉｄまたはｉＯＳベース）にユーザインターフェースのセットが作成されている。
インターフェース／依存関係
テストシステムでは、オファーおよびデマンドトランザクションを構築し、それらをＤＡＢサービスのトランザクションエンジンに送信するために、ＤＡＢアプリ（ＡｎｄｒｏｉｄまたはｉＯＳベース）にユーザインターフェースのセットが作成されている。
【0222】
マーケットプレイス／エクスチェンジを使用するために、ＤＡＢサービスはｉＥｘｅｃ ＳＤＫと対話する。このアプリケーションは、独自のイーサリウムトランザクションロジック、およびデータ挿入と検索を調整するための別のブロックチェーン統合レイヤコネクタをラップする、コマンドラインＮｏｄｅＪＳツールである。これらの動作は各々、実行されるべきいくつかのＯＳ呼び出しを伴い、順序付けられたコマンドのセットがＳＤＫに発行され、ＳＤＫは、ＤＡＢサービスによって処理および解釈されるテキストＪＳＯＮ出力を同期的に実行および返す。すべてのｉＥｘｅｃオフチェーンアルゴリズムはセキュアなエンクレーブで実行されるため、それらが使用するデータセットはそれらのブロックチェーンに直接挿入されない。代わりに、これらは、ＳＤＫによって生成された秘密で暗号化されると、公開ＩＰＦＳネットワーク（または他のファイルシステム）に展開される。この秘密は、データセットのＩＰＦＳハッシュと共に、挿入フロー中にｉＥｘｅｃに各々プッシュされ、秘密は秘密管理サービスに送信され、ハッシュはブロックチェーンに送信される。ＩＰＦＳピンニングサービスの場合、Ｐｉｎａｔａが使用されてもよい。この実装はＡＰＩも使用する。
【0223】
ｉＥｘｅｃ ＳＤＫ ｖ４．０．３は、同じマシン内のＤＡＢサービスインスタンスと共にインストールされ、ＮｏｄｅＪＳ ８．１０．０およびＤｏｃｋｅｒ １９．０３．６の構成を必要とした。
【0224】
ＤＡＢアプリは、ＤＡＢサービスに送信されるトランザクションを構築するユーザインターフェースのセットを作成するために使用される。これは、オファーおよびデマンドの容量をシミュレートする。しかしながら、そのようなプロセスは、異なるエンティティおよびプロセスによってオファーおよび許容が生成される生成システムにおいて自動化される。同様のメッセージフォーマットは、２つの異なるタイプのトランザクションで使用される。
【0225】
「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」が「ｎｅｗｄａｔａ」に等しい場合、オファーデータセットが含まれ、それをブロックチェーン／マーケットプレイス／エクスチェンジに展開するようにＤＡＢサービスをトリガする；
「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」に等しい場合、所望のトリップパラメータを含むデマンドデータセットを搬送する。
「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」に等しい場合、所望のトリップパラメータを含むデマンドデータセットを搬送する。
【0226】
ｉＥｘｅｃによって準備された照合アルゴリズムは、オファーとデマンドの両方に類似した厳密なデータセット形式、出荷会社が特定の価格、日付およびルートで雇用のために利用可能なトラックスペースを販売するテストシナリオを特徴付けるＪＳＯＮ構造を扱うので、両方のデータセットはプロパティ「ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ」内にある。
【0227】
取引情報
トラックトリップのための空間提供を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ」、タブ「トラック容量」を選択し、フィールドに入力する。生成システムでは、データセットは、容量を示すことができるセンサを有する個々のトラックによって作成される。データセットは以下を含む。
トラックトリップのための空間提供を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ」、タブ「トラック容量」を選択し、フィールドに入力する。生成システムでは、データセットは、容量を示すことができるセンサを有する個々のトラックによって作成される。データセットは以下を含む。
【0228】
サービスプロバイダ－サービスプロバイダの名称、
提供スペース－利用可能な貨物ユニットの数量、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－希望価格、
トラックトリップの要求を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「データを探す」を選択し、フィールドに入力する。
提供スペース－利用可能な貨物ユニットの数量、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－希望価格、
トラックトリップの要求を記述するデータセットを手動で作成するために、ユーザはＤＡＢアプリ上でメニューエントリ「データを探す」を選択し、フィールドに入力する。
【0229】
サービスプロバイダ－貨物空間を探すエンティティの名称、
必要な空間－必要な貨物ユニット、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－入札価格。
必要な空間－必要な貨物ユニット、
起点－トリップ起点、
終点－トリップ目的地、
日付－トリップ日付、
価格－入札価格。
【0230】
ここでも、生成システムでは、貨物空間の入札は、そのようなサービスを必要とするエンティティに対して自動的に生成され得る。
【0231】
「ｎｅｗｄａｔａ」または「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」を受信すると、ＤＡＢサービスは、ｉＥｘｅｃ ＳＤＫとの一連のシステムレベルの対話を開始する。ｉＥｘｅｃブロックチェーンに挿入されるのは、オファーデータセット自体ではなく、そのＩＰＦＳハッシュ（他の関連するｉＥｘｅｃデータと共に）である。
【0232】
「ｎｅｗｄａｔａ」トランザクションがマーケットプレイス／エクスチェンジに挿入されるデータセットを識別する場合、「ｌｏｏｋｉｎｇｆｏｒｄａｔａ」はＤＡＢ側フローをトリガし、ＤＡＢ側フローは、以前に挿入された「ｎｅｗｄａｔａ」データセットをループして、（ｉＥｘｅｃによって管理されるＩｎｔｅｌ ＳＧＸエンクレーブワーカープールで実行される）オフチェーン照合タスクを順次展開してポーリングすることを必要とする。このプロセスを図２８に概略的に示す。
【0233】
照合プロセスは、ＤＡＢサービスが、対の相手のないオファーおよびデマンドデータセットのハッシュを選択し、それらをｉＥｘｅｃワーカープール内の「タスク」に挿入することを伴う。これらのタスクは、ｉＥｘｅｃワーカープールによってピックアップされて実行され、結果が計算されるまでＤＡＢサービスによって繰り返しポーリングされる。ＤＡＢサービスは、そのデータベース内のすべてのデータセットハッシュを含む更新されたリストを保持する。このプロセスを図２９に概略的に示す。
【0234】
これらのオフチェーンタスクは同時に複数の比較を実行することができないため、ＤＡＢサービスはデータセットごとに実行を発行する役割を担う。オファーとデマンドとの間に一致が見つかった場合、それらのデータセットハッシュがＤＡＢサービスデータベースに登録され、購入者のデバイスに通知される。
【0235】
オファーおよびデマンドデータセットの両方を挿入したデバイスに一致を通信するため、特にＡｎｄｒｏｉｄアプリケーションのメッセージおよびプッシュ通知のためのクロスプラットフォームクラウドによる解決策であるために、Ｆｉｒｅｂａｓｅクラウドメッセージングプラットフォームが使用され得る。コンポーネントは、ＤＡＢ駆動デバイスのためのＦｉｒｅｂａｓｅメッセージングを処理し、すべてのデバイスは、起動時にそれらのＦｉｒｅｂａｓｅ接続トークンを登録するようにされる（ＤＡＢサービスにポストされたデバイス登録メッセージに沿って送信される）。したがって、それらは起動の準備ができている。ここでも、生成システムでは、メッセージを異なる方法で処理してもよい。
【0236】
マーケットプレイス／エクスチェンジへのデータの自動供給は、異なる機構を使用して達成してもよい。例えば、ＡＩおよびセンサネットワークは、自動化された市場交渉で設定することができる。既製の照合アルゴリズムを、ワーカープールを保護するために展開してもよい。
【0237】
代替の実装形態には、
ＩＰＦＳをより高速な分散ストレージによる解決策に置き換えること、
複数のデータセットを同時に扱うことができる照合アルゴリズムを展開すること、
ＤＡＢサービスがデマンドデータセットをアンロードし、一致が見つかったときに非同期通知を提供する連続分析のためのデータセットハッシュを提供する、専用のワーカープールを設定すること、が含まれる。
ＩＰＦＳをより高速な分散ストレージによる解決策に置き換えること、
複数のデータセットを同時に扱うことができる照合アルゴリズムを展開すること、
ＤＡＢサービスがデマンドデータセットをアンロードし、一致が見つかったときに非同期通知を提供する連続分析のためのデータセットハッシュを提供する、専用のワーカープールを設定すること、が含まれる。
【0238】
ユースケース：「エネルギーアイデンティティおよび支払い」
この使用により、「ＤＡＢ対応デバイス」（ＳＩＭおよびそれぞれのミドルウェア上のセキュアエレメントを有する）をＥｎｅｒｇｙ Ｗｅｂ Ｆｏｕｎｄａｔｉｏｎスマートエネルギープラットフォームに統合し、アクティブな参加者になることが可能になる。
この使用により、「ＤＡＢ対応デバイス」（ＳＩＭおよびそれぞれのミドルウェア上のセキュアエレメントを有する）をＥｎｅｒｇｙ Ｗｅｂ Ｆｏｕｎｄａｔｉｏｎスマートエネルギープラットフォームに統合し、アクティブな参加者になることが可能になる。
【0239】
接続されたデバイスは、Ｆｌｅｘｈｕｂ ＭＱＴＴブローカからのメッセージ（すべてＪＷＴストリングに符号化されている）を排他的に読み取り、デジタル署名する。アセット所有者は、（電力を売買するための）オファー割当をプログラムしており、ＦｌｅｘＨｕｂプラットフォームによって管理および処理される。ＤＡＢプラットフォームは、ドメイン相互接続を追加する。これは、ＤＡＢサービスがトランザクションされたデータを認識し、これらのデータを操作することを必要とする。したがって、統合アーキテクチャは、デバイスのためにＤＡＢサービスブローカを使用し、それらに代わってＦｌｅｘＨｕｂノードとのメッセージングを処理する。ＥＷＦデバイス側コード（元々Ｐｙｔｈｏｎで書かれている）は、ＦｌｅｘＨｕｂ機能に何ら影響を与えることなく、現在は複数のデバイスにサービスするＤＡＢコア上で実行されているＳｐｒｉｎｇ Ｂｏｏｔコンポーネントに移植される。このシステムの概略図を図３０に示す。
【0240】
ＥＷＦによって定義された関連するユーザ／当事者／役割には、以下が含まれる。
ＴＳＯ（伝送システムオペレータ）は柔軟性の要求を提出し、制約および制限を定義し、確認済みアセットをアクティブ化する。
ＴＳＯ（伝送システムオペレータ）は柔軟性の要求を提出し、制約および制限を定義し、確認済みアセットをアクティブ化する。
【0241】
アセット所有者は、その個人アセットの各々がそれらのパラメータと一致するオファーを提出できるように、オファーパラメータを定義する。
【0242】
インストーラは、アセット所有者のアセットの登録を承認する。
管轄機関は、市場に参加している他の当事者の役割の登録を承認する。
管轄機関は、市場に参加している他の当事者の役割の登録を承認する。
【0243】
ＴＳＯは、それらのエネルギー柔軟性要求および制約をシステムに提出し、アセット所有者は、それらのオファーを提出し（自身で、またはインテリジェンスの第三者プロバイダを介して）、Ｆｌｅｘ ｓｙｓｔｅｍは、要求を満たすための最低コストの方法を決定する。
【0244】
他の強化には、以下が含まれ得る。
登録、プロビジョニング、オファー作成の自動化。
登録、プロビジョニング、オファー作成の自動化。
【0245】
ＡｎｄｒｏｉｄまたはＪａｖａを使用しているデバイス以外のデバイス。
デバイスは、トランザクションに署名するように要求され、オファーのアクティブ化が通知される。これらは、ＤＡＢサービスによってトリガされる。これにより、デバイスが、各デバイスから命令のためにそれぞれのＦｌｅｘＨｕｂ ＭＱＴＴキューをポーリングすることが回避される。ＤＡＢアプリは、以下を含む機能を提供する。
デバイスは、トランザクションに署名するように要求され、オファーのアクティブ化が通知される。これらは、ＤＡＢサービスによってトリガされる。これにより、デバイスが、各デバイスから命令のためにそれぞれのＦｌｅｘＨｕｂ ＭＱＴＴキューをポーリングすることが回避される。ＤＡＢアプリは、以下を含む機能を提供する。
【0246】
デバイスは、署名用のＥＷＦトランザクションを含むメッセージを受信し、それはその後、ＤＡＢコアサービスＡＰＩ上のカスタムエンドポイントにポストされ、ＤＡＢコアをトリガしてそれぞれのＥＷＦビジネスフローを完了する。
【0247】
アクティブ化メッセージが受信されるときはいつでも、ＤＡＢアプリはユーザ通知を表示し、これは有用で実際のアクション（例えば、モバイルアプリケーションから到達可能なデバイスをオン／オフする）で置き換えてもよい。これを図３１に概略的に示す。
【0248】
ビジネスロジック
フローは、Ｆｌｅｘ ＷｅｂＡｐｐ内の様々なＥＷＦアクターによって行われた入力から開始される。ＤＡＢサービスは、ＥＷＦビジネスロジック（および任意の種類のフロー状態可観測性）を実装する唯一のコンポーネントであるため、ＦｌｅｘＨｕｂが必要とする様々なＪＷＴに署名するようにデバイスに要求する。
フローは、Ｆｌｅｘ ＷｅｂＡｐｐ内の様々なＥＷＦアクターによって行われた入力から開始される。ＤＡＢサービスは、ＥＷＦビジネスロジック（および任意の種類のフロー状態可観測性）を実装する唯一のコンポーネントであるため、ＦｌｅｘＨｕｂが必要とする様々なＪＷＴに署名するようにデバイスに要求する。
【0249】
要求されたメッセージに署名した後、デバイスは、署名されたメッセージを送信したデバイスに対してどのフローが実行されていたかを判定するのに十分な情報とともに、ＤＡＢサービスにそれらを返す。デバイスは、手元のユースケース（ＤＡＢスタック目標の１つ）に関係するものとは別の他のＪＷＴに署名する必要があり得る。したがって、Ｆｉｒｅｂａｓｅ Ｄａｔａ Ｍｅｓｓａｇｅフォーマットは、他のシナリオに対する高速な適応を可能にする。「ｕｓｅＣａｓｅ」プロパティは、署名を求めるＤＡＢユースケースを指定し、提出時にＤＡＢサービスでトリガするアクションを識別するために、サーバがその特定のユースケース内のアクションの追加のコースを区別できるようにする追加の「ｕｓｅＣａｓｅＡｃｔｉｏｎ」プロパティを含めることが適切であると本発明者らは感じた。図３２および図３３は、このプロセスのシーケンス図を示す。
【0250】
この統合のために、プロパティ「ｕｓｅＣａｓｅ」は「ｅｗｆ」としてタグ付けされ、「ｕｓｅＣａｓｅＡｃｔｉｏｎ」フィールドは、デバイスの署名を最初に必要とした特定のＥＷＦビジネスフローを示すために使用された。
【0251】
特定のアセットによって実行される所与のオファーのアクティブ化チャートを確認するために、Ｆｌｅｘ ＷｅｂＡｐｐをアセット所有者が使用することもでき、ダッシュボードを介してユーザは作成されたオファーのリストにアクセスし、チャート化したいオファーの「データシート」アイコンを選択することができる。
【0252】
デバイスは、ＥＷＦネットワークの一部になり、これは、発電機、バッテリなどをオン／オフするなどのさらなる実用的な動作に拡張することができる。同じことが、電気自動車充電（ＥＶＣ）または単純なスマートメータデータの貨幣化を含む、フレックスグリッド以外の他のマーケットプレイスにも適用可能である。
【0253】
ユースケース：「企業およびコンシューマ駐車」
このユースケースでは、デジタルＩＤ（人、サービス、および物に対する）を使用して、支払いの有無にかかわらず自動車をサービスとペアリングできる完全なエンドツーエンド体験を作成する。
このユースケースでは、デジタルＩＤ（人、サービス、および物に対する）を使用して、支払いの有無にかかわらず自動車をサービスとペアリングできる完全なエンドツーエンド体験を作成する。
【0254】
１．運転者のいずれかによって行われる（コンシューマＢ２Ｃシナリオ－運転者のデジタル識別情報および銀行プラットフォーム内の関連する個人口座を使用する）、
２．後の処理のためにＤＬＴ上で使用が維持される車自体に課金される（企業Ｂ２Ｂシナリオ－車が第三者、例えばレンタル会社に属する場合）、
ＤＡＢサービスは、フローを管理および編成する（およびＢ２Ｂ支払いに使用するためのＣｏｒｄａ ＤＬＴをホストする）。車両は、ＤＡＢミドルウェアアプリケーションおよびＤＡＢアプリのカスタマイズされたバージョン（例えば、タブレットアプリ）を実行する内部ルータを含み得る。これは、組み込み（例えば、ｉＯＳまたはＡｎｄｒｏｉｄベース）ダッシュボードコンピュータにインストールすることができる。
２．後の処理のためにＤＬＴ上で使用が維持される車自体に課金される（企業Ｂ２Ｂシナリオ－車が第三者、例えばレンタル会社に属する場合）、
ＤＡＢサービスは、フローを管理および編成する（およびＢ２Ｂ支払いに使用するためのＣｏｒｄａ ＤＬＴをホストする）。車両は、ＤＡＢミドルウェアアプリケーションおよびＤＡＢアプリのカスタマイズされたバージョン（例えば、タブレットアプリ）を実行する内部ルータを含み得る。これは、組み込み（例えば、ｉＯＳまたはＡｎｄｒｏｉｄベース）ダッシュボードコンピュータにインストールすることができる。
【0255】
インターフェース／依存関係
ＳＰＯＴ駐車システムは、「サービス支払い」ユースケースと同様に、同じ場所およびＣｏｒｄａ台帳にインストールすることができる。
ＳＰＯＴ駐車システムは、「サービス支払い」ユースケースと同様に、同じ場所およびＣｏｒｄａ台帳にインストールすることができる。
【0256】
ＳＩＭによる保護
トランザクションに署名するために、前述のＳＩＭ手法によって保護されたものが使用されてもよく、ＳＩＭ上でＰＫＩを消費する。ＳＩＭは、プロセッサまたは他のデバイス（例えば、車両）に差し込まれたＵＳＢドングルに追加される。ＤＡＢミドルウェアがデバイス上で実行され、前述したように、署名のためにＤＡＢミドルウェアＡＰＩを公開する。
トランザクションに署名するために、前述のＳＩＭ手法によって保護されたものが使用されてもよく、ＳＩＭ上でＰＫＩを消費する。ＳＩＭは、プロセッサまたは他のデバイス（例えば、車両）に差し込まれたＵＳＢドングルに追加される。ＤＡＢミドルウェアがデバイス上で実行され、前述したように、署名のためにＤＡＢミドルウェアＡＰＩを公開する。
【0257】
駐車インフラストラクチャにインストールされたＳＰＯＴ駐車システムは、そのゲートを横切る車両を検出し、カスタムＡＰＩセット（上記参照）でエンドポイントを呼び出すことによってＤＡＢサービスと共に動作する。このカスタマイズは、ＳＰＯＴがＤＡＢサービスにナンバープレートおよびゲート情報を送信するために使用され、次に、以下の場合にはリターンコードを予期する。
【0258】
入庫時：有効化された支払いが設定されたため、バリアを開くことができる、
出庫時：精算が完了し、車は出庫することができる。
出庫時：精算が完了し、車は出庫することができる。
【0259】
ＦＩＮＮ
Ｂ２Ｃシナリオを管理するために、ＦＩＮＮ（ＲＴＭ）を使用した。これは、ＩｏＴの支払いをスマートデバイスに追加するツールキットを含む商用プラットフォーム上に構築されたＩｏＴの解決策の貨幣化に特化している。要約すると、
「製品」は、サービスを提供し、それと対話するための様々なアクションを定義し、それぞれに利用価格を割り当てる。
Ｂ２Ｃシナリオを管理するために、ＦＩＮＮ（ＲＴＭ）を使用した。これは、ＩｏＴの支払いをスマートデバイスに追加するツールキットを含む商用プラットフォーム上に構築されたＩｏＴの解決策の貨幣化に特化している。要約すると、
「製品」は、サービスを提供し、それと対話するための様々なアクションを定義し、それぞれに利用価格を割り当てる。
【0260】
デバイスは、「製品」を使用するように登録し、そのアクションは、クレジットカードなど、デバイス所有者によって設定された支払い方法に課金される。
【0261】
デバイスが「製品」アクションをトリガするときはいつでも、ＦＩＮＮエコシステムにマイクロペイメントが登録される。
【0262】
ＦＩＮＮの場合、「製品」は、実世界で作動する任意の実システム（「製品」アクションを任意の自動化されたアクティビティと接続するためのＦＩＮＮ ＩＯＴ ＳＤＫと統合する）またはオフラインサービスを表す抽象エンティティとすることができる。ＳＰＯＴ内のすべての使用ロジックは、ＤＡＢサービスコンポーネントによって制御される。この「製品」のための構成された動作は、ゲート入口および出口を含み、それぞれ滞在期間に基づいて０および駐車料金が課金される。
【0263】
駐車セッションのシーケンス図を図３４に示す。
これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、ＤＡＢ管理コアに記載されたメッセージフォーマットに従ってトランザクションを構築する。駐車シナリオ（ユースケースタイプ「駐車」）の場合、セッション開始と終了は、それらの「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」の値（「ｎｅｗｄａｔａ」および「ｅｎｄｃｏｒｄａｓｅｓｓｉｏｎ」）と、「ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ」の内容によって区別される。この最後のフィールドは、ＤＬＴにコミットされる購入者（車）および供給者（駐車場）の両方の情報を搬送する。地理的情報と共に、ＤＡＢサービスは、各デバイスのプロキシサーバとして機能する（必要に応じてデバイスの位置を検証するために使用される）。
これらのシナリオをトリガするために、ＤＡＢアプリ内のユーザレイアウトの集合は、ＤＡＢ管理コアに記載されたメッセージフォーマットに従ってトランザクションを構築する。駐車シナリオ（ユースケースタイプ「駐車」）の場合、セッション開始と終了は、それらの「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」の値（「ｎｅｗｄａｔａ」および「ｅｎｄｃｏｒｄａｓｅｓｓｉｏｎ」）と、「ｔｒａｎｓａｃｔｉｏｎＯｂｊｅｃｔ」の内容によって区別される。この最後のフィールドは、ＤＬＴにコミットされる購入者（車）および供給者（駐車場）の両方の情報を搬送する。地理的情報と共に、ＤＡＢサービスは、各デバイスのプロキシサーバとして機能する（必要に応じてデバイスの位置を検証するために使用される）。
【0264】
シミュレートされた駐車セッションを開始するために、ユーザはＤＡＢアプリ上でメニューエントリ「新しい貨幣化可能データ、：タブ「駐車、を選択し、以下のフィールドに入力する。
【0265】
イニシエータ－駐車セッションを開始するデバイス（デバイスのＳＩＭ ＩＤが自動的に入力される）、
ターゲット－車両が登録されているＣｏｒｄａノード、
ターゲットＵＵＩＤ－イニシエータ車両のコード識別子（ＵＵＩＤ）、
ソースＵＵＩＤ－車両を駐車するために選択された駐車スロットのコード識別子（ＵＵＩＤ）、
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用してパーキングセッションを開始する：常に結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－Ａｎｄｒｏｉｄ ＯＳから読み取られるように、実際のＧＰＳ位置を使用して駐車セッションを開始する。このオプションを使用して正常な駐車セッションを開始する場合、イニシエータデバイスと駐車スロットは、互いに最大６ｍでなければならない。
ターゲット－車両が登録されているＣｏｒｄａノード、
ターゲットＵＵＩＤ－イニシエータ車両のコード識別子（ＵＵＩＤ）、
ソースＵＵＩＤ－車両を駐車するために選択された駐車スロットのコード識別子（ＵＵＩＤ）、
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用してパーキングセッションを開始する：常に結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－Ａｎｄｒｏｉｄ ＯＳから読み取られるように、実際のＧＰＳ位置を使用して駐車セッションを開始する。このオプションを使用して正常な駐車セッションを開始する場合、イニシエータデバイスと駐車スロットは、互いに最大６ｍでなければならない。
【0266】
駐車セッションを終了するために、ユーザは、
「トランザクション」メニューエントリ内のセッションを開き、以下のフィールドに入力する。
「トランザクション」メニューエントリ内のセッションを開き、以下のフィールドに入力する。
【0267】
ブロックチェーンに課金される分／価値単位、
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用して駐車セッションを停止する、この結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－デバイスの実際のＧＰＳ位置を使用して駐車セッションを終了する、
ＭＯＣＫ＿ＥＮＤ＿ＳＥＳＳＩＯＮ＿ＣＡＲ＿ＳＴＩＬＬ＿ＰＡＲＫＥ Ｄ－車が駐車場所を離れていないかのように動作するようにＣｏｒｄａ ＤＡｐｐに指示するテストフラグ。
ＧＰＳオプション：
ＭＯＣＫ＿ＨＡＰＰＹ＿ＰＡＴＨ－ＧＰＳ位置を使用して駐車セッションを停止する、この結果は成功したアクションになる、
ＲＥＡＬ＿ＧＰＳ－デバイスの実際のＧＰＳ位置を使用して駐車セッションを終了する、
ＭＯＣＫ＿ＥＮＤ＿ＳＥＳＳＩＯＮ＿ＣＡＲ＿ＳＴＩＬＬ＿ＰＡＲＫＥ Ｄ－車が駐車場所を離れていないかのように動作するようにＣｏｒｄａ ＤＡｐｐに指示するテストフラグ。
【0268】
ビジネスロジック
このユースケースでは、「製品」を使用するデバイスは車両である。しかしながら、その「アクション」は、Ｂ２Ｃシナリオでアクティブ化されてもよい。したがって、「スマートサービス」の概念が使用されており、ユーザのデジタルアイデンティティとＤＡＢスタックによって提供されるサービスとの間の関連付けである。
このユースケースでは、「製品」を使用するデバイスは車両である。しかしながら、その「アクション」は、Ｂ２Ｃシナリオでアクティブ化されてもよい。したがって、「スマートサービス」の概念が使用されており、ユーザのデジタルアイデンティティとＤＡＢスタックによって提供されるサービスとの間の関連付けである。
【0269】
ＤＡＢはデバイス（車）をＳＩＭに関連付ける：これはＦＩＮＮベースのスマートサービスであるため、ＤＡＢサービスは、それを使用したいデバイスに渡すために、ＳＰＯＴ駐車「製品」に関連するすべてのＦＩＮＮデータを知る必要がある。これは、車両タブレットアプリ（または車両もしくはデバイス内の他のプロセッサ）が起動するたびに行われ、それと一緒にインストールされるのは、ＦＩＮＮコアバックエンドに登録され、必要に応じていつでもＳＰＯＴ駐車「製品」を使用する準備ができるようにその車両を自動的にセットアップするためのコードを含む、ＦＩＮＮ提供アプリ（ＦＩＮＮ ＩＯＴ ＳＤＫを組み込む）である。このプロビジョニングフローは図３５に示されており、以下を含む。
【0270】
ステップ 説明 トリガ
１ 製造業者がＳＣＢ－ＤＡＢシステムに新しい車を追加する 製造業者
２ ＤＡＢは、その車のアイデンティティのための新しいスマートコントラクトをＤＤＩブロックチェーンネットワークに展開する ＤＡＢ
３ ＤＤＩブロックチェーンネットワークは対応するｄｉｄで応答する ＤＤＩブロックチェーン
４ ＤＡＢはそれを車のナンバープレートと関連付ける ＤＡＢ
５ ＤＡＢは対応する車に車のｄｉｄを送信する ＤＡＢ
６ 車は自分のデータベースに自分のｄｉｄを保存する 車
スマートサービスのオンボーディング：ユーザが「スマートサービス」のオンボーディングを実行したいときはいつでも、特別に開発されたＡｎｄｒｏｉｄアプリケーション（以下、「スマートサービスアプリケーション」として知られる）を使用して実行する。アプリは、デジタルアイデンティティを選択するためのＤＩＤアプリケーションと協働し、そのＵＩから選択されたスマートサービスをそれに関連付ける。これを図３６に概略的に示す。
１ 製造業者がＳＣＢ－ＤＡＢシステムに新しい車を追加する 製造業者
２ ＤＡＢは、その車のアイデンティティのための新しいスマートコントラクトをＤＤＩブロックチェーンネットワークに展開する ＤＡＢ
３ ＤＤＩブロックチェーンネットワークは対応するｄｉｄで応答する ＤＤＩブロックチェーン
４ ＤＡＢはそれを車のナンバープレートと関連付ける ＤＡＢ
５ ＤＡＢは対応する車に車のｄｉｄを送信する ＤＡＢ
６ 車は自分のデータベースに自分のｄｉｄを保存する 車
スマートサービスのオンボーディング：ユーザが「スマートサービス」のオンボーディングを実行したいときはいつでも、特別に開発されたＡｎｄｒｏｉｄアプリケーション（以下、「スマートサービスアプリケーション」として知られる）を使用して実行する。アプリは、デジタルアイデンティティを選択するためのＤＩＤアプリケーションと協働し、そのＵＩから選択されたスマートサービスをそれに関連付ける。これを図３６に概略的に示す。
【0271】
この時点で、ユーザが「ＳＰＯＴ駐車スマートサービス」を使用するためにオンボードしている場合、ＤＡＢサービスは、ユーザ側のＦＩＮＮ支払い方法を構成するのに十分なデータ（最初にタブレットアプリによって送信されたデータ）で応答しており、このために、スマートサービスアプリは、最初にユーザに有効な支払いクレジットカードを要求し、次いでそれをＳＰＯＴ駐車製品のコンシューマとして登録する、別のＦＩＮＮ供給アプリケーション（ＦＩＮＮモバイルＳＤＫを組み込む）とインテントを介して自動的に通信する。これを図３７に概略的に示す。この例示的な実装形態では、以下のステップをとることができる。
【0272】
Ｂ２Ｃサービスのオンボーディング（図３７）
ステップ 説明 トリガ
１ スマートサービスアプリは、ＤＡＢをトリガしてユーザ用の新しいサービスを作成する スマートサービスアプリ
２ ＤＡＢはプロファイルタイプ（個人の場合）をチェックし、ユーザデータを保存する ＤＡＢ
３ ＤＡＢは、ユーザ側初期化に必要なデータ：ユーザプロファイルデータ＋サービスデータで応答する ＤＡＢ
４ スマートサービスアプリは、（インテントを介して）新しいサービスを作成するためにＦｉｎｎモバイルアプリをトリガする スマートサービスアプリ
５ ＦｉｎｎモバイルアプリがＦＩＮＮコアに要求を転送する ＦＩＮＮモバイルアプリケーション
６ ＦＩＮＮコアは、成功またはエラーメッセージで応答する ＦＩＮＮコア
７ Ｆｉｎｎモバイルアプリは、成功またはエラーメッセージで応答する（インテントリターンを介して）ＦＩＮＮモバイルアプリケーション
９ スマートサービスアプリは、Ｆｉｎｎのオンボーディング確認を／サービス／確認にポストする スマートサービスアプリ
デバイスを識別する（例えば車）：ユーザがどの車を運転しているかを決定するために（および車両がＦＩＮＮ ＳＰＯＴ駐車「製品」アクションをトリガすることを理解するために）、ユーザと物との間のセッションを作成するためにデジタルアイデンティティ機能を活用するログイン機構がＤＡＢプラットフォームで確立される。このようにして、車が入口ゲートを横切るときはいつでも、ＤＡＢサービスは誰がそれを運転しているかを知る。このフローは、運転者がＤＡＢアプリ（車の車載されたタブレットに予めインストールされている）に車のナンバープレートを入力したときにトリガされ、その後のアクティビティは以下の２つの段階に分けることができる。
ステップ 説明 トリガ
１ スマートサービスアプリは、ＤＡＢをトリガしてユーザ用の新しいサービスを作成する スマートサービスアプリ
２ ＤＡＢはプロファイルタイプ（個人の場合）をチェックし、ユーザデータを保存する ＤＡＢ
３ ＤＡＢは、ユーザ側初期化に必要なデータ：ユーザプロファイルデータ＋サービスデータで応答する ＤＡＢ
４ スマートサービスアプリは、（インテントを介して）新しいサービスを作成するためにＦｉｎｎモバイルアプリをトリガする スマートサービスアプリ
５ ＦｉｎｎモバイルアプリがＦＩＮＮコアに要求を転送する ＦＩＮＮモバイルアプリケーション
６ ＦＩＮＮコアは、成功またはエラーメッセージで応答する ＦＩＮＮコア
７ Ｆｉｎｎモバイルアプリは、成功またはエラーメッセージで応答する（インテントリターンを介して）ＦＩＮＮモバイルアプリケーション
９ スマートサービスアプリは、Ｆｉｎｎのオンボーディング確認を／サービス／確認にポストする スマートサービスアプリ
デバイスを識別する（例えば車）：ユーザがどの車を運転しているかを決定するために（および車両がＦＩＮＮ ＳＰＯＴ駐車「製品」アクションをトリガすることを理解するために）、ユーザと物との間のセッションを作成するためにデジタルアイデンティティ機能を活用するログイン機構がＤＡＢプラットフォームで確立される。このようにして、車が入口ゲートを横切るときはいつでも、ＤＡＢサービスは誰がそれを運転しているかを知る。このフローは、運転者がＤＡＢアプリ（車の車載されたタブレットに予めインストールされている）に車のナンバープレートを入力したときにトリガされ、その後のアクティビティは以下の２つの段階に分けることができる。
【0273】
ＱＲコード（登録商標）の生成：ＤＡＢアプリは、認証プロセスを進めるために、運転者がスキャンするためのＱＲコードをタブレット上に生成する、および
運転者認証：運転者はＱＲコードをスキャンし、ＤＤＩアプリをトリガして開く。そこから、運転者は、車両と共有したい個人情報を許可する（または許可しない）。このデータの一部は強制的であるが、他は任意であり、これは（すべての車両のプロキシとして機能する）ＤＡＢで構成された設計決定である。ユーザによって共有されるすべての許可された情報は、ＤＡＢに格納され得る。これを図３８に概略的に示す。
運転者認証：運転者はＱＲコードをスキャンし、ＤＤＩアプリをトリガして開く。そこから、運転者は、車両と共有したい個人情報を許可する（または許可しない）。このデータの一部は強制的であるが、他は任意であり、これは（すべての車両のプロキシとして機能する）ＤＡＢで構成された設計決定である。ユーザによって共有されるすべての許可された情報は、ＤＡＢに格納され得る。これを図３８に概略的に示す。
【0274】
ＱＲコードを介した運転者－車ログイン（図３８）
ステップ 説明 トリガ
１ 運転者は、車のタブレットアプリにナンバープレートを入力する タブレットアプリ
２ タブレットアプリは、ログイン要求をＤＡＢに送信する タブレットアプリ
３ ＤＡＢは、そのログイン「セッション」を識別するランダムトピックＵＵＩＤを生成する ＤＡＢ
４ ＤＡＢは、ＧＣＬにノンス＋許可ＩＤを要求する ＤＡＢ
５ ＧＣＬ応答：ノンス＋ａｕｔｈＩＤ ＧＣＬ
６ ＤＡＢは、トピックをノンス＋ａｕｔｈＩＤ＋ステップ２データと関連付ける ＤＡＢ
７ ＤＡＢは、ＱＲコードを生成するために必要なデータをタブレットアプリに送信する ＤＡＢ
８ タブレットアプリは、認証用ＱＲコードを生成する タブレットアプリ
非中央集権化デジタルＩＤ（ＤＤＩ）を介した運転者－車ログイン（図３９）
ステップ 説明 トリガ
１ 運転者は、自分の電話でＱＲコードを読み取る（トピック＋車のＤＩＤアイデンティティを含む）運転者
２ ＤＤＩアプリが開き、運転者は自身について共有したいデータを選択および／または許可する。ＤＤＩアプリ
３ ＤＤＩアプリは、その情報を共有する ＧＣＬ
４ ＧＣＬは、提供された車のアイデンティティに格納されたＤＡＢリターンＵＲＬをブロックチェーンに要求する ＧＣＬ
５ ＧＣＬは、そのエンドポイントをポストし、トピックの存在をチェックするトピックが存在する場合、ＤＡＢは、ログインしようとしているユーザに関係する指示されたｕｓｅｒＤｉｄを格納する ＧＣＬ
６ ＤＡＢは、ＧＣＬにＯｋまたはエラー応答を送信する ＤＡＢ
７ ＧＣＬは、ログイン結果をＤＤＩアプリに送信する ＧＣＬ
８ ログイン結果が成功すると、ＤＤＩアプリはユーザプロファイル＋プロファイルタイプをＤＡＢにポストする ＤＤＩアプリ
９ ＤＡＢは、このユーザ／車セッションのユーザプロファイル＋プロファイルタイプを保存する ＤＡＢ
１０ ＤＡＢは、ログイン結果をタブレットアプリに送信する ＤＡＢ
１１ タブレットアプリは成功メッセージを表示する タブレットアプリ
ＤＡＢサービス：ＤＡＢサービスは、ＳＰＯＴがカスタムＡＰＩ（既存のＳＰＯＴインフラストラクチャの仕様に従って実装される）のカスタムＲＥＳＴエンドポイントに検出された車両ナンバープレートに関する情報をポストするたびにトリガされる。次のロジックは、ＳＰＯＴビジネスフローを管理するためにＤＡＢコア内に統合される追加のコンポーネントを必要としたが、これは以下のように要約することができる。
ステップ 説明 トリガ
１ 運転者は、車のタブレットアプリにナンバープレートを入力する タブレットアプリ
２ タブレットアプリは、ログイン要求をＤＡＢに送信する タブレットアプリ
３ ＤＡＢは、そのログイン「セッション」を識別するランダムトピックＵＵＩＤを生成する ＤＡＢ
４ ＤＡＢは、ＧＣＬにノンス＋許可ＩＤを要求する ＤＡＢ
５ ＧＣＬ応答：ノンス＋ａｕｔｈＩＤ ＧＣＬ
６ ＤＡＢは、トピックをノンス＋ａｕｔｈＩＤ＋ステップ２データと関連付ける ＤＡＢ
７ ＤＡＢは、ＱＲコードを生成するために必要なデータをタブレットアプリに送信する ＤＡＢ
８ タブレットアプリは、認証用ＱＲコードを生成する タブレットアプリ
非中央集権化デジタルＩＤ（ＤＤＩ）を介した運転者－車ログイン（図３９）
ステップ 説明 トリガ
１ 運転者は、自分の電話でＱＲコードを読み取る（トピック＋車のＤＩＤアイデンティティを含む）運転者
２ ＤＤＩアプリが開き、運転者は自身について共有したいデータを選択および／または許可する。ＤＤＩアプリ
３ ＤＤＩアプリは、その情報を共有する ＧＣＬ
４ ＧＣＬは、提供された車のアイデンティティに格納されたＤＡＢリターンＵＲＬをブロックチェーンに要求する ＧＣＬ
５ ＧＣＬは、そのエンドポイントをポストし、トピックの存在をチェックするトピックが存在する場合、ＤＡＢは、ログインしようとしているユーザに関係する指示されたｕｓｅｒＤｉｄを格納する ＧＣＬ
６ ＤＡＢは、ＧＣＬにＯｋまたはエラー応答を送信する ＤＡＢ
７ ＧＣＬは、ログイン結果をＤＤＩアプリに送信する ＧＣＬ
８ ログイン結果が成功すると、ＤＤＩアプリはユーザプロファイル＋プロファイルタイプをＤＡＢにポストする ＤＤＩアプリ
９ ＤＡＢは、このユーザ／車セッションのユーザプロファイル＋プロファイルタイプを保存する ＤＡＢ
１０ ＤＡＢは、ログイン結果をタブレットアプリに送信する ＤＡＢ
１１ タブレットアプリは成功メッセージを表示する タブレットアプリ
ＤＡＢサービス：ＤＡＢサービスは、ＳＰＯＴがカスタムＡＰＩ（既存のＳＰＯＴインフラストラクチャの仕様に従って実装される）のカスタムＲＥＳＴエンドポイントに検出された車両ナンバープレートに関する情報をポストするたびにトリガされる。次のロジックは、ＳＰＯＴビジネスフローを管理するためにＤＡＢコア内に統合される追加のコンポーネントを必要としたが、これは以下のように要約することができる。
【0275】
車両が駐車場に進入したときに、
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスは、ブロックチェーン統合層のＣｏｒｄａコネクタを使用して、Ｃｏｒｄａ ＤＬＴ上でその車両のセッションを開く（「駐車および料金」ユースケースをミラーリングする）、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品のアクティブ化がトリガされる。
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスは、ブロックチェーン統合層のＣｏｒｄａコネクタを使用して、Ｃｏｒｄａ ＤＬＴ上でその車両のセッションを開く（「駐車および料金」ユースケースをミラーリングする）、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品のアクティブ化がトリガされる。
【0276】
車両が駐車場を出るときに、
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスはその車両の以前に開かれたＤＬＴセッションを閉じる、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品の非アクティブ化がトリガされる。
スマートサービスにＢ２Ｂプロファイルがオンボードされていた場合、ＤＡＢサービスはその車両の以前に開かれたＤＬＴセッションを閉じる、
スマートサービスにＢ２Ｃプロファイルがオンボードされていた場合、Ｆｉｒｅｂａｓｅメッセージが車両のタブレットアプリにプッシュされて、ＳＰＯＴ製品識別子のＦｉｎｎバックエンドで製品の非アクティブ化がトリガされる。
【0277】
Ｂ２Ｂは、駐車フローの詳細を開始する（図４０）。
ステップ 説明 トリガ
１ 入口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する新しい駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の新しい駐車セッションをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、新しい駐車セッションを通知するＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｃは、駐車フローの詳細を開始する（図４１）
ステップ 説明 トリガ
１ 駐車ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、Ｆｉｒｅｂａｓｅ通知をタブレットアプリに送信し、Ｆｉｎｎアクション（入庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに入庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の入庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４２）。
ステップ 説明 トリガ
１ 入口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する新しい駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の新しい駐車セッションをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、新しい駐車セッションを通知するＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｃは、駐車フローの詳細を開始する（図４１）
ステップ 説明 トリガ
１ 駐車ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ 駐車ゲートは、そのナンバープレートに対する駐車セッションを開始するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、Ｆｉｒｅｂａｓｅ通知をタブレットアプリに送信し、Ｆｉｎｎアクション（入庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに入庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の入庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４２）。
【0278】
ステップ 説明 トリガ
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の駐車セッションのクローズをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４３）。
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（企業の場合）ＤＡＢ
４ ＤＡＢは、Ｃｏｒｄａ駐車ブロックチェーン内の駐車セッションのクローズをトリガする ＤＡＢ
５ ブロックチェーンからＤＡＢへの応答－成功またはエラー 駐車ブロックチェーン
６ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリに送信し、適切なメッセージでステップ２を返し、次にゲートをトリガして開く ＤＡＢ
７ タブレットアプリは、新しい駐車セッションに関する情報を画面に表示する タブレットアプリ
Ｂ２Ｂは、駐車フローの詳細を終了する（図４３）。
【0279】
ステップ 説明 トリガ
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリケーションに送信し、Ｆｉｎｎアクション（出庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに出庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の出庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
同様の解決策は、異なる駐車の解決策に適用することができ、また、例えば、ＥＶ充電および料金が同じフローに従うことができるスマートシティにおける異なるドメインにも適用することができる。コンシューマデジタルＩＤおよび支払いに関して、エンドツーエンド体験の改善が行われている。
１ 出口ゲートのカメラは、ナンバープレートを走査する 駐車ゲート
２ ゲートは、そのナンバープレートに対する駐車セッションを終了するようにＤＡＢに要求する 駐車ゲート
３ ＤＡＢは、駐車サービスのオンボーディングに使用されるユーザのＤＩＤプロファイルタイプをチェックする（個人の場合）ＤＡＢ
４ ＤＡＢは、駐車セッションの価格および持続時間を含むＦｉｒｅｂａｓｅ通知をタブレットアプリケーションに送信し、Ｆｉｎｎアクション（出庫）をトリガする ＤＡＢ
５ タブレットアプリは、インテントを介してＦＩＮＮ ＩｏＴ ＳＤＫに出庫アクションをトリガする タブレットアプリ
６ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＤＡＢミドルウェアを使用して、対応する鍵ペアでトランザクションに署名する ＦＩＮＮ ＩｏＴ ＳＤＫ
７ ＦＩＮＮ ＩｏＴ ＳＤＫは、ＦＩＮＮコア内の出庫アクションをトリガする ＦＩＮＮ ＩｏＴ ＳＤＫ
８ ＦＩＮＮ ＩｏＴ ＳＤＫに対するＦＩＮＮコアからの応答－成功またはエラー ＦＩＮＮコア
９ ＦＩＮＮ ＩｏＴ ＳＤＫは、インテントリターンを介して操作結果をシグナリングし、タブレットアプリは通知ポップアップを表示する ＦＩＮＮ ＩｏＴ ＳＤＫ
１０ ＤＡＢはステップ２で行われたポストから戻り、ゲートをトリガして開く タブレットアプリ
同様の解決策は、異なる駐車の解決策に適用することができ、また、例えば、ＥＶ充電および料金が同じフローに従うことができるスマートシティにおける異なるドメインにも適用することができる。コンシューマデジタルＩＤおよび支払いに関して、エンドツーエンド体験の改善が行われている。
【0280】
ＤＡＢユーザインターフェース
テスト環境には、以下の２つの主なユーザインターフェース（ＵＩ）がある。
テスト環境には、以下の２つの主なユーザインターフェース（ＵＩ）がある。
【0281】
ＤＡＢ ＡＰＰ：Ａｎｄｒｏｉｄ（または他の）モバイルアプリケーション
ＤＡＢ ＡＥＰ：ＤＡＢ Ｃｏｒｄａブロックチェーンを接続するためのＴｈｉｎｇｗｏｒｘ拡張
ＵＩは、顧客がすべての機能を利用できるようにするだけでなく、運用および保守チームがエコシステムおよび解決策を管理し、情報を監視および抽出できるようにするために重要である。
ＤＡＢ ＡＥＰ：ＤＡＢ Ｃｏｒｄａブロックチェーンを接続するためのＴｈｉｎｇｗｏｒｘ拡張
ＵＩは、顧客がすべての機能を利用できるようにするだけでなく、運用および保守チームがエコシステムおよび解決策を管理し、情報を監視および抽出できるようにするために重要である。
【0282】
【0283】
これはテストシナリオを説明しているが、実際の駐車セッションは、同様だがアプリケーションを必要としない方法で処理される場合がある。すべてのメッセージは、車両（または駐車位置）の内部または周囲のセンサおよび検出されたイベントから開始され得る。
【0284】
当業者には理解されるように、上記の実施形態の詳細は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく変更することができる。
【0285】
例えば、異なる分散型台帳または台帳技術を使用することができる。ＵＩＣＣは、例えば、組み込みＳＩＭであってもよい。例えば、移動式、可動式、固定式、監視付き、監視なし、家庭用、商業用または工業用デバイスを含む多くの異なるタイプのデバイスが使用されてもよい。
【0286】
上記の実施形態の特徴に対する多くの組み合わせ、修正、または変更は、当業者には容易に明らかであり、本発明の一部を形成することを意図している。１つの実施形態または例に具体的に関連して説明した特徴のいずれも、適切な変更を行うことによって任意の他の実施形態で使用され得る。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【国際調査報告】