特許 7502311 位置を決定または検証するためのコンピュータで実施されるシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-10

(45)【発行日】2024-06-18

(54)【発明の名称】位置を決定または検証するためのコンピュータで実施されるシステムおよび方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240611BHJP

   H04L 9/08 20060101ALI20240611BHJP

   G06F 21/64 20130101ALI20240611BHJP

   G01S 5/14 20060101ALI20240611BHJP

【ＦＩ】

H04L9/32 200B

H04L9/08 F

G06F21/64

G01S5/14

【請求項の数】 20

(21)【出願番号】P 2021544918

(86)(22)【出願日】2020-01-20

(65)【公表番号】

(43)【公表日】2022-05-11

(86)【国際出願番号】 IB2020050405

(87)【国際公開番号】W WO2020157596

(87)【国際公開日】2020-08-06

【審査請求日】2022-12-28

(31)【優先権主張番号】1901391.1

(32)【優先日】2019-02-01

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】クレイグ・スティーヴン・ライト

(72)【発明者】

【氏名】ダニエル・ジョセフ

【審査官】中里 裕正

(56)【参考文献】

【文献】特開平０９－２０５４２２（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０３６６３４２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１０／０２４８６３２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００８／０１８１４１３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００７／００７８８１７（ＵＳ，Ａ１）

【文献】GAMBS, S.，PROPS : A PRivacy-preserving lOcation Proof Syste，2014 IEEE 33rd International Symposium on Reliable Distributed Systems，2014年10月，pp.1-10

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｈ０４Ｌ ９／０８

Ｇ０６Ｆ ２１／６４

Ｇ０１Ｓ ５／１４

(57)【特許請求の範囲】

【請求項1】

コンピュータで実施される方法であって、
位置データに対する要求をブロードキャストするステップと、
複数のノードの各々から、そのノードに隣接するそれぞれの少なくとも1つのエリアに対応する少なくとも1つの公開鍵を備えるそれぞれの位置データを受信するステップと、
前記複数のノードのセットに共通の共通公開鍵を選択するステップと、
前記共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加するようにノードの前記セットに要求するステップと
を備える、方法。

【請求項2】

前記位置データが距離属性をさらに備え、前記方法が、前記距離属性に基づいて前記公開鍵を順位付けするステップをさらに備え、前記複数のノードの前記セットに共通の共通公開鍵を前記選択するステップが、前記順位付けの結果に基づいて実行される、請求項1に記載の方法。

【請求項3】

前記距離属性が、それぞれのノードから前記要求の起源までの距離を備え、前記順位付けが、前記距離の順序で前記公開鍵を順位付けするステップを備える、請求項2に記載の方法。

【請求項4】

位置データに対する前記要求を前記ブロードキャストするステップが、前記要求のブロードキャスタを識別するための識別子をブロードキャストするステップを備え、かつ/または位置データを受信する前記ステップが、前記複数のノードの各々から、それぞれの少なくとも1つのノードと関連付けられる公開鍵を受信するステップをさらに備える、請求項1～3のいずれか一項に記載の方法。

【請求項5】

前記共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加するようにノードの前記セットに前記要求するステップが、署名されるべきデータを提供するステップを備える、請求項1に記載の方法。

【請求項6】

署名されるべき前記データが、(i)メッセージ、(ii)メッセージのハッシュ、および(iii)前記要求のブロードキャスタを識別するための識別子のうちの少なくとも1つを備える、請求項5に記載の方法。

【請求項7】

前記ノードの公開鍵と関連付けられるそれぞれのノード署名を少なくとも1つのノードから受信し、前記少なくとも1つのノード署名の妥当性を確認し、前記妥当性の確認の結果に基づいて閾値秘密共有に参加するようにノードに要求するかどうかを決定するステップをさらに備える、請求項1に記載の方法。

【請求項8】

少なくとも1つのノード署名が、(i)メッセージ、(ii)メッセージのハッシュ、(iii)前記要求のブロードキャスタを識別するための識別子、(iv)前記位置データ、および(v)前記ノードの公開鍵のうちの少なくとも1つとさらに関連付けられる、請求項7に記載の方法。

【請求項9】

(i)暗号秘密のシェア部分を少なくとも1つのノードに送信するステップ、(ii)前記それぞれの少なくとも1つのさらなるノードの公開鍵を用いて暗号化される関数値を少なくとも1つのノードから少なくとも1つのさらなるノードに中継するステップ、(iii)中間暗号値のそれぞれの複数の部分を前記複数のノードから受信し、前記部分を前記中間暗号値へと組み合わせ、前記中間暗号値を少なくとも1つのさらなるノードに送信するステップ、(iv)前記暗号署名のそれぞれの複数の部分を前記複数のノードから受信し、前記複数の部分を前記暗号署名の構成要素へと組み合わせるステップ、および(v)前記暗号署名をブロックチェーントランザクションに供給することによって前記ブロックチェーントランザクションを履行するステップのうちの少なくとも1つをさらに備える、請求項1から8のいずれか一項に記載の方法。

【請求項10】

コンピュータで実施される方法であって、
位置データに対する要求を受信するステップと、
前記要求と関連付けられる距離属性を決定するステップと、
前記距離属性およびそれぞれの少なくとも1つの隣接エリアに対応する少なくとも1つの公開鍵を備える位置データを送信するステップと、
共通公開鍵と関連付けられる暗号署名を提供するために閾値秘密共有に参加するための要求を受信するステップと、
複数のノードと、前記暗号署名を取得するために閾値秘密共有において協調するステップと
を備える、方法。

【請求項11】

さらなる距離属性を決定するステップをさらに備える、請求項10に記載の方法。

【請求項12】

距離属性を前記決定するステップが、タイムオブフライト測定を備え、かつ/または位置データに対する前記要求を前記受信するステップが、前記要求のブロードキャスタを識別するための識別子を受信するステップを備える、請求項10または11に記載の方法。

【請求項13】

前記共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加するための前記要求を受信する前記ステップが、署名されるべきデータを受信するステップを備える、請求項10に記載の方法。

【請求項14】

署名されるべき前記データが、(i)メッセージ、(ii)メッセージのハッシュ、および(iii)前記要求のブロードキャスタを識別するための識別子のうちの少なくとも1つを備える、請求項13に記載の方法。

【請求項15】

位置データを前記送信するステップが、ノード公開鍵を送信するステップをさらに備える、請求項10に記載の方法。

【請求項16】

少なくとも前記ノードの公開鍵と関連付けられるノード署名を前記要求のブロードキャスタに送信するステップをさらに備える、請求項15に記載の方法。

【請求項17】

前記ノード署名が、(i)メッセージ、(ii)メッセージのハッシュ、(iii)前記ブロードキャスタを識別するための識別子、(iv)前記位置データ、および(v)前記ノードの公開鍵のうちの少なくとも1つとさらに関連付けられる、請求項16に記載の方法。

【請求項18】

(i)暗号秘密のシェア部分を前記要求のブロードキャスタに送信するステップ、(ii)少なくとも1つのノードと関連付けられるそれぞれの値から計算される少なくとも1つの関数値を前記ブロードキャスタに送信するステップ、(iii)中間暗号値の部分を前記ブロードキャスタに送信して前記中間暗号値を受信するステップ、(iv)前記暗号署名の部分を前記ブロードキャスタに送信するステップ、および、(v)前記ブロードキャスタから、複数の前記ノードと関連付けられるさらなる位置データを受信し、前記ブロードキャスタの計算された位置を決定するために三辺測量の計算を実行し、前記計算された位置を少なくとも前記位置データと比較し、前記比較の結果に基づいて前記閾値秘密共有に参加するかどうかを決定するステップのうちの少なくとも1つをさらに備える、請求項10から17のいずれか一項に記載の方法。

【請求項19】

コンピュータで実施されるシステムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに、請求項1から18のいずれか一項に記載のコンピュータで実施される方法の任意の実施形態を実行させる実行可能命令を含むメモリと
を備える、システム。

【請求項20】

コンピュータシステムのプロセッサにより実行される結果として、前記コンピュータシステムに、請求項1から18のいずれか一項に記載の方法の実施形態を少なくとも実行させる実行可能命令が記憶された、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は全般に、ユーザ、デバイス、物体、もしくはエンティティの位置を決定または検証(認証)するための方法に関し、より具体的には、位置を決定/認証するために閾値秘密共有を使用することに関する。本開示は、限定はされないが、ビットコインブロックチェーンなどのブロックチェーンとともに使用するのに特に適している。

【背景技術】

【0002】

この文書では、すべての形式の電子的なコンピュータベースの分散型台帳を含むものとして、「ブロックチェーン」という用語を使用する。これらは、コンセンサスベースのブロックチェーンおよびトランザクションチェーン技術、認可型台帳および非認可型台帳、共有台帳、ならびにこれらの変形を含む。最もよく知られているブロックチェーン技術の応用はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。便宜的に、および説明のために、本明細書ではビットコインに言及することがあるが、本開示はビットコインブロックチェーンとともに使用することに限定されず、代替のブロックチェーンの実装とプロトコルが本開示の範囲内にあることに留意されたい。「ユーザ」という用語は、本明細書では人またはプロセッサベースのリソースを指すことがある。「ビットコイン」という用語は、ビットコインプロトコルの変形、または派生物である任意のプロトコルを含むことが意図される。

【0003】

ブロックチェーンは、ブロックからなるコンピュータベースの非集中型の分散型システムとして実装されるピアツーピア電子台帳であり、ブロックはトランザクションからなる。各トランザクションは、ブロックチェーンシステムの参加者間でのデジタル資産の管理権の移行を符号化するとともに、少なくとも1つの入力および少なくとも1つの出力を含む、データ構造である。各ブロックは以前のブロックのハッシュを含むので、ブロックは一緒につながれるようになり、ブロックチェーンの発足以来ブロックチェーンに書き込まれているすべてのトランザクションの恒久的で変更不可能な記録を作成する。トランザクションは、入力および出力に、スクリプトとして知られている小さいプログラムが埋め込まれており、これが、トランザクションの出力にどのようにアクセスできるか、および誰がアクセスできるかを指定する。ビットコインプラットフォームでは、これらのスクリプトは、スタックベースのスクリプト言語を使用して書かれる。

【0004】

暗号通貨の実装の使用について、ブロックチェーン技術が最も広く知られているが、デジタル起業家は、ビットコインが基礎とする暗号セキュリティシステムと、ブロックチェーンに記憶できるデータとの両方を使用して、新しいシステムを実装することを模索し始めている。暗号通貨の世界に限定されない、自動化されたタスクおよび処理のためにブロックチェーンを使用できれば、とても有利であろう。そのような解決策は、ブロックチェーンの利益(たとえば、改竄防止されたイベントの恒久的な記録、分散処理など)を利用しながら、それらの応用範囲をより広くすることが可能であろう。

【0005】

全地球測位システム(GPS)は、ジオロケーション情報および時間情報を地球上のレシーバに提供する、衛星ベースのナビゲーションシステムである。これは、米国政府により所有され、米空軍により運用されている。GPSは少なくとも24個の衛星からなり、米国防省が主導しているが、衛星は1980年代に民間利用が可能にされた。「GPS衛星は、正確な軌道で地球を一日に二周する。各衛星は、GPSデバイスが衛星の正確な位置を復号して計算することを可能にする、固有の信号および軌道パラメータを伝送する。GPSレシーバは、この情報と三辺測量を使用して、ユーザの厳密な位置を計算する。基本的に、GPSレシーバは、伝送された信号を受信するのにかかる時間の長さにより、各衛星までの距離を測定する。もう少し多くの衛星からの距離の測定結果があれば、レシーバは、ユーザの場所を決定し、それを電子的に表示することができる」(https://www8.garmin.com/aboutGPS/)。

【0006】

GPSは有用であり、現代の製品および生活に溶け込むことに成功しているが、いくつかの制約がある。気象条件、ならびに信号が高層建築および他の構造物により遮られることにより生じる、問題および途絶の他に、GPSには(少なくとも民間のバージョンには)起源証明または認証の機能がない。このことは、不正、偽装、電波妨害、およびサイバー攻撃を受けやすいシステムをもたらす。

【0007】

GPSの成功にもかかわらず、GPSはその位置データの認証を行わず、これは、ユーザの位置を要求するサービスに対して、衛星のGPSシステムから実際にデータが取得されることなく、ユーザが位置データを「入力」できることを意味する。基本的に、これは、ユーザが、GPS座標を提供することで、ある位置にいることを、その企図される位置にはいないにもかかわらず容易に主張できることを意味する。

【0008】

FOAMは、GPSなどの集中型の消費者マッピング技術およびサービス、ならびにGoogleおよびHEREなどのサービスプロバイダの代替を提供することを目指している位置証明プロトコルである。立案者は、FOAMを「時間同期を通じてGPSなどの外部の集中型のソースとは独立にセキュアな位置サービスを提供することができる、無線ビーコンの認可不要で自律的なネットワークを可能にする」プロトコルであると説明している(https://foam.space/)。FOAMの位置証明は、時間同期を実行する目的で、および最終的に三辺測量を通じてユーザの位置を決定するために、無線技術を利用する地上の「ノード」である、ゾーンアンカー(Zone Anchor)を利用する。しかしながら、偽装などのGPSのいくつかの制約に対処するための解決策として説明されているが、説明されたプロトコルには、ユーザにより提供された位置がFOAMのゾーンアンカーから正当に得られたことを検証するための明確な方法がない。

【発明の概要】

【発明が解決しようとする課題】

【0009】

したがって、位置を認証する方法を提供することが望ましい。そのような改善された解決策がここで考案された。したがって、本開示によれば、添付の特許請求の範囲において定義されるような方法が提供される。

【課題を解決するための手段】

【0010】

本開示によれば、コンピュータで実施される方法が提供されることがある。それは、位置を決定および/または認証するための方法として説明されることがある。方法は、
位置データに対する要求をブロードキャストするステップと、
複数のノードの各々から、そのノードに隣接するそれぞれの少なくとも1つのエリアに対応する少なくとも1つの公開鍵を備えるそれぞれの位置データを受信するステップと、
複数のノードのセットに共通の共通公開鍵を選択するステップと、
共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加するようにノードのセットに要求するステップとを備えてもよい。

【0011】

要求は、デバイスまたはそのユーザによりブロードキャストされてもよい。要求は、デバイスのブロードキャスト範囲内の、またはユーザにより選ばれた範囲内の複数の静止ノードにブロードキャストされてもよい。

【0012】

この方法は、方法のユーザが自身の位置を決定して、ユーザなしで位置が真正であることを確認する暗号署名を取得できるという利点、または、方法における任意の他の参加者が、任意の暗号秘密もしくは秘密鍵を決定して、閾値秘密共有の使用により、認証において所望のレベルのセキュリティおよび信用を達成するという利点をもたらす。

【0013】

各位置データは距離属性を備えてもよく、方法はさらに、距離属性に基づいて公開鍵を順位付けするステップを備えてもよく、複数のノードのセットに共通の共通公開鍵を選択するステップは、順位付けの結果に基づいて実行される。

【0014】

距離属性は、それぞれのノードからの距離を備えてもよい。順位付けは、前記距離の順序で公開鍵を順位付けすることを備えてもよい。

【0015】

これは、正確な位置を決定する確率を高めるという利点をもたらす。

【0016】

位置データに対する要求をブロードキャストするステップは、ブロードキャスタを識別するための識別子をブロードキャストするステップを備えてもよい。

【0017】

これは、ユーザの識別情報が検証されることを可能にし、それにより方法のセキュリティを高めるという利点をもたらす。

【0018】

位置データを受信するステップは、複数のノードの各々から、それぞれの少なくとも1つのノードと関連付けられる公開鍵を受信するステップを備えてもよい。

【0019】

これにより、複数のノードからユーザが受信するあらゆる情報の起源をユーザがより容易に特定することが可能になり、望まれる場合に特定のノードとのあらゆるさらなる通信をユーザが暗号化することが可能になる。

【0020】

共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加するようにノードのセットに要求するステップは、署名されるべきデータを提供するステップを備えてもよい。署名されるべきデータは、メッセージ、メッセージのハッシュ、およびブロードキャスタを識別するための識別子を備えてもよい。メッセージ自体が、メッセージのハッシュと識別子の連結であってもよい。

【0021】

これは、署名されるべきデータおよび署名自体を特定のユーザと結び付けて、ユーザの身元について後で確認が実行されることを可能にし、それにより方法のセキュリティを高めるという利点をもたらす。

【0022】

方法はさらに、ノードの少なくとも公開鍵と関連付けられるそれぞれのノード署名を少なくとも1つのノードから受信し、少なくとも1つのノード署名の妥当性を確認し、前記妥当性確認の結果に基づいて閾値秘密共有に参加するようにノードに要求するかどうかを決定するステップを備えてもよい。

【0023】

これにより、偽装の試みをユーザが検出することを可能にすることで特定のノードを信用すべきかどうかをユーザが決定することが可能になり、それによりユーザの安全性が高まる。

【0024】

ノード署名は、メッセージ、メッセージのハッシュ、ブロードキャスタを識別するための識別子、位置データ、およびノード公開鍵のいずれと関連付けられてもよい。

【0025】

方法はさらに、暗号秘密のシェア部分を少なくとも1つのノードに送信するステップを備えてもよい。

【0026】

方法はさらに、少なくとも1つのノードから少なくとも1つのさらなるノードに、それぞれの少なくとも1つのさらなるノードの公開鍵を用いて暗号化される関数値を中継するステップを備えてもよい。

【0027】

方法はさらに、複数のノードから中間暗号値のそれぞれの複数の部分を受信し、前記部分を中間値へと組み合わせ、中間値を少なくとも1つのさらなるノードに送信するステップを備えてもよい。

【0028】

方法はさらに、複数のノードから暗号署名のそれぞれの複数の部分を受信し、前記複数の部分を暗号署名の構成要素へと組み合わせるステップを備えてもよい。

【0029】

これらのステップの各々が、ノード間で行われた可能性のある通信にユーザを関わらせ、それにより、ユーザとノードの相対的な位置を確認するための機会の数を増やし、それらの間での通信の内容を更新し、署名計算の中間ステップの結果をユーザが確認することを可能にするという利点をもたらす。

【0030】

方法はさらに、暗号署名をブロックチェーントランザクションに供給することによってブロックチェーントランザクションを履行するステップを備えてもよい。ブロックチェーントランザクションは、要求のブロードキャスタ、すなわちユーザを識別するための識別子を備えてもよい。

【0031】

これは、ブロックチェーンが恒久的で公開された変更不可能な記録を提供することを考慮すると、あらゆる関心のある関係者がユーザの身元を検証することを可能にするという利点をもたらす。

【0032】

追加または代替として、本開示によれば、コンピュータで実施される方法が提供されてもよく、この方法は、
位置データに対する要求を受信するステップと、
要求と関連付けられる距離属性を決定するステップと、
距離属性およびそれぞれの少なくとも1つの隣接エリアに対応する少なくとも1つの公開鍵を備える位置データを送信するステップと、
共通公開鍵と関連付けられる暗号署名を提供するために閾値秘密共有に参加せよとの要求を受信するステップと、
複数のノードと、暗号署名を取得するために閾値秘密共有において協調するステップとを備える。

【0033】

位置データに対する要求は、ノマドと呼ばれることがある、自身の位置を証明しようとしているユーザにより操作されるデバイスから発信された可能性がある。位置データ自体が、ノマドのデバイスによる受信のためにノマドに送信されてもよい。秘密共有に参加せよとの要求は、ノマドのデバイスから発信された可能性がある。暗号署名は、取得されるとノマドに送信されてもよい。

【0034】

この方法は、位置データに対する要求のブロードキャスタの真正な位置をブロードキャスタなしで決定するという利点、または、方法における任意の他の参加者が、任意の暗号秘密もしくは秘密鍵を決定することから、閾値秘密共有の使用により、認証において所望のレベルのセキュリティおよび信用を達成するという利点をもたらす。

【0035】

方法はさらに、さらなる距離属性を決定するステップを備えてもよい。距離属性を決定するステップは、タイムオブフライト(time of flight)の測定結果を備えてもよい。さらなる距離属性は、方法のユーザ、すなわち第1のノードと、別のユーザ、すなわち第2のノードとの間の距離であってもよい。

【0036】

これは、三辺測量の計算などの、前記距離属性を使用して実行されるあらゆる後続の計算がどれだけ正確であるかをユーザが決定することを可能にするという利点をもたらし、ユーザが以前に取得された属性とさらなる距離属性を照合して、他のユーザが本物であることを検証することを可能にするという追加の利点をもたらす。

【0037】

位置データに対する要求を受信するステップは、要求のブロードキャスタを識別するための識別子を受信するステップを備えてもよい。

【0038】

これは、ユーザが、識別子を、テーブルの中のエントリ、またはブロックチェーンの使われていないトランザクション出力データベースの中のトランザクション、またはブロックチェーン上のトランザクションと比較することを可能にすることなどにより、ユーザがブロードキャスタの身元を検証することを可能にするという利点をもたらす。

【0039】

共通公開鍵と関連付けられる暗号署名を取得するために閾値秘密共有に参加せよとの要求を受信するステップは、署名されるべきデータを受信するステップを備えてもよい。署名されるべきデータは、メッセージ、メッセージのハッシュ、およびブロードキャスタを識別するための識別子を備えてもよい。

【0040】

これは、署名されるべきデータおよび署名自体を特定のブロードキャスタと結び付けて、ブロードキャスタの身元について後で確認が実行されることを可能にし、それにより方法のセキュリティを高めるという利点をもたらす。

【0041】

位置データを送信するステップはさらに、ノード公開鍵を送信するステップを備えてもよい。ノード公開鍵は、方法を行うユーザ、すなわちノードと関連付けられてもよい。

【0042】

これは、意図される受信者ノードにしか復号可能ではない、後続の通信を暗号化する手段を識別子が提供するという点で特に、位置データを送信するユーザを識別するという利点をもたらす。

【0043】

方法はさらに、ノードの少なくともある公開鍵と関連付けられるノード署名を、ブロードキャスタに送信するステップを備えてもよい。

【0044】

これは、ブロードキャスタがユーザからの通信の妥当性を確認することを可能にし、それにより方法のセキュリティを高める。

【0045】

ノード署名はさらに、メッセージ、メッセージのハッシュ、ブロードキャスタを識別するための識別子、位置データ、およびノード公開鍵のいずれと関連付けられてもよい。

【0046】

これは、上で言及されたデータのいずれの妥当性も確認するように、妥当性確認を拡張するという利点をもたらす。

【0047】

方法はさらに、暗号秘密のシェア部分をブロードキャスタに送信するステップを備えてもよい。

【0048】

方法はさらに、少なくとも1つのノードと関連付けられるそれぞれの値から計算された少なくとも1つの関数値を、ブロードキャスタに送信するステップを備えてもよい。

【0049】

方法はさらに、中間暗号値の部分をブロードキャスタに送信し、中間値を受信するステップを備えてもよい。

【0050】

方法はさらに、暗号署名の部分をブロードキャスタに送信するステップを備えてもよい。

【0051】

これらのステップの各々が、ユーザ間で行われた可能性のある通信にブロードキャスタを関わらせ、それにより、ブロードキャスタとユーザの相対的な位置を確認するための機会の数を増やし、それらの間での通信の内容を更新し、署名計算の中間ステップの結果をブロードキャスタが確認することを可能にするという利点をもたらす。

【0052】

方法はさらに、複数のノードと関連付けられるさらなる位置データを受信し、三辺測量の計算を実行してブロードキャスタの計算された位置を決定し、計算された位置を少なくとも位置データと比較し、前記比較の結果に基づいて閾値秘密共有に参加するかどうかを決定するステップを備えてもよい。

【0053】

これは、ブロードキャスタがユーザの望まれる範囲から出た場合に、方法においてユーザが参加を拒絶すること、または参加を止めることを可能にする。

【0054】

上のステップのすべてにおいて、ブロードキャスタはノマドであると理解されてもよい。

【0055】

追加または代替として、本開示によれば、コンピュータで実施されるシステムが提供されてもよく、このシステムは、
プロセッサと、
プロセッサによる実行の結果として、本明細書において説明されるコンピュータで実施される方法の任意の実施形態をシステムに実行させる実行可能命令を含むメモリとを備える。

【0056】

追加または代替として、本開示によれば、コンピュータシステムのプロセッサにより実行される結果として、本明細書において説明される方法の実施形態をコンピュータシステムに少なくとも実行させる実行可能命令が記憶された、非一時的コンピュータ可読記憶媒体が提供されてもよい。

【0057】

本開示のこれらおよび他の態様は、本明細書において説明される実施形態から明らかとなり、それを参照して解明される。単なる例として、添付の図面を参照して、本開示の実施形態がここで説明される。

【図面の簡単な説明】

【0058】

【図1】別々の六角形の幾何学的単位への2D平面のテッセレーションを示す図である。

【図2】ある実施形態のHexAnchorの配置の概略図である。

【図3】ある実施形態のHexAnchorのグループの詳細な概略図である。

【図4】共通のHexAnchor頂点を有するHexAnchorの複数のグループの概略図である。

【図5】ある実施形態による図4の頂点に割り振られるキーシェアを示す図である。

【図6】ある実施形態の図4および図5の頂点からHexSetの中のHexAnchorまでの距離を示す図である。

【図7】ある実施形態による頂点の位置を確認する図4から図6のHexAnchorのグループを示す図である。

【図8】所与の辺の長さの六角形の2つの頂点間の最大の離隔を示す図である。

【図9】ある実施形態の複数のHexAnchorの重複範囲の概略図である。

【図10】ある実施形態のステップを実証するフローチャートである。

【図11】ある実施形態による、複数のHexAnchorに対する相対的なユーザをHexKeyの順序付けられたテーブルとともに示す図である。

【図12】ある実施形態の複数のHexAnchorの重複範囲の概略図である。

【図13】ある実施形態の幾何学的配置の概略図である。

【図14】ある実施形態におけるHexAnchorの順序を示すテーブルである。

【図15】ある実施形態におけるユーザと複数のHexAnchorとの間の通信の概略図である。

【図16】ある実施形態のステップを実証するフローチャートである。

【図17】ある実施形態のステップを実証するフローチャートである。

【図18】ある実施形態のステップを実証するフローチャートである。

【図19】ある実施形態のブロックチェーン約束チャネルの概略図である。

【図20】様々な実施形態を実装することができるコンピューティング環境を示す概略図である。

【発明を実施するための形態】

【0059】

商業では、受信者がある地理的位置またはその近くにいない限り、リソースへのアクセス権またはビットコイントランザクションなどのトランザクションの制御権を受信者が得ることを、送信者が制約することを望むことがあるシナリオがある。運転手が乗客の求める場所で乗客を乗せない限り、運転手または車が乗客からのトランザクションの制御権を得ないような、タクシーまたは運転手のいない車の使用を考えてもよい。

【0060】

暗号通貨およびそれらの関連するスクリプト言語の到来は、トランザクションの制御権が受信者に渡ることを可能にする、高度なまたは洗練された条件がトランザクションに組み込まれる機会をもたらした。ユーザ位置の場合、制御権を解放するための基準がユーザの位置を必要することがあるが、受信者がその特定の位置にいなくても必要とされる位置データを容易に入力する可能性があるという危険性がある。「位置データ」は、前記データを要求するデバイスの位置などの、位置を指定する任意の情報を指す。位置データは距離属性を含んでもよく、これは、前記要求を受信するデバイスによって決定されるようなノマドまでの距離を含んでもよい。

【0061】

本明細書では、暗号通貨のトランザクションへと地理的基準を統合するための、地理空間プロトコルに関連するシステムが説明される。この解決策は、協調的に生成されたデジタル署名がユーザの位置の証明として働くような、所定の地理的位置にあるノードにより生成される閾値署名の使用を含む。以後、「ノード」は、少なくともプロセッサおよびメモリを有し、デジタル情報を受信して伝送すること、計算を実行すること、および好ましくはブロックチェーンと対話することが可能な、電子デバイスを指す。

【0062】

ビットコインの導入の際のより特筆すべき様相の1つは、トランザクションの履行のための基準を作成する際にユーザに柔軟性を与えるスクリプト言語が含まれていたことであった。利用可能なオペコードは、単純に公開鍵を送信することから、より洗練された「スマートコントラクト」タイプの条件にまでわたる、基準を構築するための能力を与える。

【0063】

ブロックチェーンにトランザクションを出すことに成功するには、送信者は、受信者のトランザクションの入力スクリプト内に必要とされるデータを含めなければならない。これは、署名および他の英数字の内容を含む。いくつかの場合、データの正しさは、送信者の出力スクリプト内のオペコードによって評価され得るが、データが「正しい」にもかかわらず、スクリプトに含まれるデータが「正当」であるかどうかについてさらなる懸念がある。

【0064】

スクリプトの実行が成功するにはデータが正しくなければならないことを考慮すると、この文脈での「正当性」は、データを獲得するために正しい活動が行われたかどうか、およびデータが認定されたソースから取得されたかどうかという疑問に関連する。

【0065】

以前に言及されたデータの懸念の例は、座標または他の空間表現タイプデータに依存することがある位置ベースのアプリケーションである。支払いを受け取るために、受信者が特定の位置にいることが必要とされることがある。支払いを受け取るために、受信者は、スクリプトにおいて座標データを提供し得るが、これらの座標を知っているということは、受信者(全体でノマドとも呼ばれる)が指定された位置にいることを必ずしも意味しない。ノマドが指定された位置にいることを認定することが望ましい。

【0066】

本明細書において、位置証明認定システム(PLaCES)が開示され、これは、ビットコイントランザクションのためのノマドの地理空間位置の認定を実施する方法を提供する。ノマドの位置の認定は、ビットコインに互換性のあるECDSAデジタル署名によって表され、提案されるプロトコルは、署名を取得するためにノマドが特定の位置もしくはその近くにいることまたはいたことを確実にする(少なくとも高い確率で)ように設計される。閾値署名方式(TSS)が、その位置について満足のいくレベルの合意に達するために利用される。以下で詳しく説明されるように、六角形にテッセレートされた平面の六角形の頂点にあるアンカーが、協調して署名を生成する。

【0067】

閾値秘密共有(TSS)は、秘密鍵がキーシェアへと分割されるような暗号化機構であり、秘密鍵は、少なくとも閾値の数のシェアの所有者の協調によって再構成されてもよい。

【0068】

PLaCESプロトコルは、ジオロケーションデータが検証されたソースから導かれていることの高水準の確証をプロトコルのユーザが得る際の、GPSの認証の制約に対処する。

【0069】

PLaCESプロトコル内では、位置を認証するために、ノマドは、その位置に対応するデジタル署名、より具体的には、楕円曲線上の点のためのデジタル署名を取得する。aCESプロトコル内では、位置を認証するために、ノマドは、その位置に対応するデジタル署名、より具体的には、楕円曲線上の点のためのデジタル署名を取得する。

【0070】

HexAnchorノードと呼ばれ以下で詳しく説明される、プロトコルを実行するノードは、自身が正しい秘密シェアを与えられていることを検証することが可能であることが望ましい。キーシェア検証のために、ノード自身のシェアならびに他のノードのシェアもノードが検証することを可能にする、公開検証可能秘密共有方式(PVSS)が利用されてもよい。

【0071】

PLaCESプロトコルは、ブロックチェーン/暗号通貨サービス、ならびに認証されたユーザ位置を要求および/または所望する他のシステムのために、ノマドの位置の認証を行う。ノマドは、自身の位置を提供することを求められ、プロトコルのユーザである、個人である。

【0072】

PLaCESプロトコルでは、ノマドの位置の認証は、デジタル署名の生成によって達成される。この署名は、十分な数の参加しているHexAnchorが、位置および/または距離の条件などのある条件をノマドが満たしていることに合意するときに、構築される。

【0073】

一方、GPSおよびFOAMの位置は緯度および経度ベースであり、PLaCESプロトコルは、別個の地理的単位(たとえば、郵便番号)の合意されたセットに対して設計される。PLaCESが包含する物理的エリアは、これらの別個の地理的単位へと再分割またはテッセレートされる。「テッセレーション」は、「密接に一緒に接合された形状の配置、特に間隙または重複なしで繰り返されるパターンでの多角形の配置」(https://en.oxforddictionaries.com/definition/tessellation)である。各地理的単位は、好ましくは規則的な六角形(6辺の多角形)の形状であるが、規則的な形状および不規則な形状の両方の、他の形状が完全に可能である。以後、PLaCESは六角形の地理的単位を参照して説明される。

【0074】

各多角形の表面積(または各辺の対応する長さ)は、必要とされる位置の粒度のレベル、HexAnchorからの無線信号の強度、コスト、およびロジスティックな問題の組合せに依存する。

【0075】

2次元平面における各六角形は、識別子を割り当てられる。各識別子(目的のためにHexKeyと名付けられる)は、楕円曲線(EC)公開鍵であり、またはそれを表すものである。EC公開鍵Pは、
P=pG
となるようなものであり、Gは楕円曲線上の底または生成元であり、pは秘密鍵である。

【0076】

自身の位置を証明することを望むノマドは、位置に対応する署名を取得することが必要とされる。位置は、ノマドがその中にいる六角形であり、署名は、対応するHexKeyの秘密鍵とともに作成された署名である。

【0077】

例として、図2のノマドは、公開鍵N=nGと結び付けられた位置にいる。ノマドが前記位置にいることをノマドが証明するには、ノマドは、秘密鍵nに基づいてデジタル署名を生成しなければならない。

【0078】

特に、ノマドも他の誰もがこの秘密鍵を持っておらず、または、平面の任意のHexKeyに対するどのような他の秘密鍵も本当に持っていない。これは、1人の関係者またはユーザもHexKey署名を生成することが可能ではないので、プロトコルのセキュリティを高める。

【0079】

HexAnchorは、六角形の頂点に位置するノードに与えられた名前である。本明細書では、表記法ψ_i ^AはHexAnchorを指し、AはHexKeyであり、iは六角形の中のノードの位置のインデックスである。図3に示されるように、この表記法はインデックスi=1を有するものとして六角形の一番上にあるアンカーを定義し、時計回りの方向にインデックスがインクリメントされることに留意されたい。

【0080】

六角形の頂点にあることは、アンカーが2D平面の外側の辺にない限り、アンカーが少なくとも3つの六角形の頂点にあることを意味する。これらの3つの六角形は、アンカーに近い、または隣接する3つのエリアであり、アンカーのHexSetとして知られている。あるノードよりも他のノードが六角形などのあるエリアの近くにない場合、そのノードはそのエリアに近いまたは隣接していると見なされることを理解されたい。

【0081】

例として、図4は、中心にあるHexAnchorのためのHexSetの中の3つの六角形(A,B,C)を示す。HexAnchorは、次のように3つの異なる方法で表記できることに留意されたい。
ψ₃ ^A＝ψ₅ ^B＝ψ₁ ^C
各HexAnchorは固有のIDを有する。これは、HexAnchorを区別するためのものである。この固有のIDは、ψ_i ^Aの表記とは別個である。この固有のIDは、公開鍵またはビットコインアドレスの形であってもよい。

【0082】

各アンカーは物理的に静止している。これは、アンカーが物理的に動かないことを意味する。事故および悪意のある関係者がノードを物理的に移動させることを試みることがあるが、PLaCESプロトコルは、誤った位置にあるアンカーに作用する、および/またはそれを識別するための対策を組み込む。

【0083】

各アンカーは、無線波の形などで、アンカーのHexSet内で発見される少なくともすべての他のアンカーとの間で、データを送信して受信するための能力を有する。これらの無線信号は、とりわけ、アンカーまたはノマド間の距離を決定するために使用される。各アンカーは、アンカーの無線トランシーバまたは他のものを介して、HexSetの中の他のアンカーとのクロック同期を実行することが可能である。PLaCESは、別のHexAnchorへの距離を判断することが可能になる能力をHexAnchorに与える。これがうまく行われるには、各アンカーのクロックは同期可能である。

【0084】

各アンカーは、無線波の形などで、アンカーのHexSetの六角形のいずれかの内側にいるノマドにより所有される特別に設計されたデバイスとの間で、データを送信して受信するための能力を有する。

【0085】

各アンカーはまた、ブロックチェーンネットワークの中にあるノードであり、またはブロックチェーンネットワークへのアクセス権を有し、すなわち、各HexAnchorは、ブロックチェーンまたは少なくともUTXOセットへのアクセス権を有する。

【0086】

ノマドの位置を認定するPLaCESの能力の中心にあるのは、閾値秘密共有(TSS)の使用である。TSSは、複数のキーシェア{x_i:i∈[1,n]}へと秘密鍵xが「分割」されることを伴う。秘密鍵は、方式の閾値に対応するキーシェアの十分な数が満たされた、またはそれを超えた場合にのみ、再構築されてもよい。Shamirの多角形手法が使用される場合、次数tの多項式に対して、n個のキーシェアのうちのt+1個が、秘密鍵xを決定するために必要とされる。

【0087】

十分な量のx_i個のキーシェアを利用することによって、秘密鍵xに基づいて、ECDSAデジタル署名を生成することが可能である。そのような場合、多項式の次数がtである場合、n個のキーシェアのうちのτ=2t+1個が、秘密鍵に対応するデジタル署名を生成するために必要とされる。これは、いずれの参加者も自身の個人のキーシェアを明らかにすることなく行われ得る。

【0088】

前に言及されたように、PLaCESプロトコルでは、各六角形は、HexKey(EC公開鍵)P=pGを割り当てられる。対応する秘密鍵pに対して、各HexAnchor ψ_i ^Pはキーシェアp_iを割り当てられる。HexAnchorが最大で3つの六角形の頂点であることを考慮すると、各アンカーは、最大で3つの異なるキーシェアを割り当てられてもよく、各シェアは異なる六角形に対応する。例として、図5では、HexAnchor(中心に示される)は、六角形Aのキーシェアa₃、六角形Bのキーシェアb₅、および六角形Cのキーシェアc₁を保有している。

【0089】

HexKeyのキーシェアの「分割」および/または分配は、次のように、
- 「秘密鍵xを知っているディーラー」にキーシェアを作成させて、これらのキーシェアが各参加者へセキュアに通信されるようにすること、または、
- 各関係者が自身のキーシェアを作成して、いずれの時点でも秘密鍵xの値を知っている参加者がいないような、ディーラーレスの解決策を利用すること
という、2つの方法で行われ得る。

【0090】

PLaCESプロトコルでは、いずれかのキーシェア分配方法が利用されてもよく、以下の表に注記されるように、各々に利点と欠点があることに注意されたい。

【0091】

【表1】

【0092】

ディーラーベースの選択肢の場合、信用される監督機関が、1つの六角形のHexAnchorだけではなく、すべてのHexAnchorにキーシェアを分配してもよい。

【0093】

代替的に、各六角形は、その六角形だけのためのキーシェアを分配する固有の信用される機関を有してもよい。

【0094】

ディーラーレスの選択肢が使用される場合、六角形のHexAnchorは、協調してその六角形の秘密鍵のキーシェアを生成する。

【0095】

HexAnchorが、テッセレーショントポロジーに従ってそれぞれの場所に配置される、セットアップ期間がある。この測位の物理的な様相を考慮すると、各HexAnchorは、テッセレートされたトポロジーの頂点に対応する位置に厳密に配置されることが可能ではないことがある。これは、地形的な、政治的な、またはロジスティックの問題によるものであり得る。しかしながら、HexAnchorが提案される位置から少しずれていることは、PLaCESプロトコルの有効性に影響しない。

【0096】

HexAnchorの最終的な位置が知られると、各HexAnchor ψ_i ^Pは、自身と、ψ_i ^PのHexSetの中のすべての他のHexAnchorとの間の距離を知る。このことの説明については図6を参照されたい。

【0097】

HexAnchor ψ_i ^Pが、他のHexAnchorまでの距離(y_ij)が何であるかを伝えられることとは別に、アンカーψ_i ^Pは、これらのアンカーが実際に述べられる距離にあることを自分で確証できることに留意されたい。この「距離確証」(CoD)プロセスは、アンカーの初期セットアップのときだけではなく、各アンカーによって決定される任意の時間に行われてもよい。

【0098】

無線トランシーバなどのトランシーバを利用して、応答信号を送信して受信するのにかかる時間に基づいて、HexAnchor ψ_i ^Pは、自身からの別のHexAnchor ψ_j ^Pの距離を決定することが可能である。ψ_j ^Pの厳密な位置は初めから正確には知られていないことがあること、および気象条件または他のことが無線信号に影響を与えることがあることを考慮すると、ψ_j ^Pの「机上の」距離が「現実世界」の値と厳密に同じであるという期待または予想はなく、y_ijの現実世界の値がある範囲内にあるという期待または予測だけがある。例として、HexAnchor ψ_j ^Pが、机上ではψ_i ^Pから100m離れている場合、ψ_i ^Pは、現実世界の距離であるものとしてψ_j ^Pを受け入れる用意がある誤差の余地、たとえばy_ij=(100±5)mを選択してもよい。

【0099】

アンカーψ_i ^Pは、アンカーψ_j ^Pの厳密な位置を決定せず、距離y_ij離れていることだけを決定することに留意されたい。距離の値しかない場合、これは、ψ_i ^Pが、アンカーψ_j ^Pが半径y_ijの円周上のどこかにあるということしか確定できないことを意味する。アンカーψ_i ^Pの位置を確定するために、アンカーと少なくとも3つのアンカーとの間の距離が必要である。3つの信頼できるアンカーの各々からのψ_j ^Pの距離が正しい場合、ψ_j ^Pの位置は正しいと考えられる。

【0100】

ノマドがある位置にあることを確認する署名を生成するには、十分な数のHexAnchorの協調が必要とされる。HexAnchorは個々に、かつ任意の時間に、あらゆるまたは1つ1つの他の協調しているアンカーが必要とされる距離にあるかどうかを決定するための確認を実行できるので、1つのアンカーψ_i ^Pが、任意の他の協調しているアンカーψ_j ^Pに対して測定される距離について満足しない場合、HexAnchor ψ_i ^Pは、ノマドのためのデジタル署名の生成に寄与するのを拒否してもよい。

【0101】

図7は、六角形の最も下の点における関心対象のアンカーに対して距離確認の確証を3つのアンカーが実行することを示す。各アンカーは、関心対象のアンカーが2つの円周の間にあることを確認することに留意されたい。アンカーのこれらの2つの円周は、関心対象のアンカーからの予想される距離の上限と下限である。すべてのアンカーが、それらの円周のペア内に関心対象のアンカーがいることに満足する場合、関心対象のアンカーは、正しい位置の境界内にいるものとして受け入れられてもよい。

【0102】

HexAnchorは、アンカーのHexSetにより包含される領域のどこかにいるノマドを検出することが可能である。これは、自身からの他のアンカーの距離を決定する能力に加えて、任意のHexAnchorの無線信号強度がアンカーのHexSetのいずれかにおける最も遠い頂点に達するのに十分であることを意味する。この例の地理的単位は、辺の長さ1の規則的な六角形であるので、この距離は2lである(図8参照)。アンカーの範囲は図9に示される。

【0103】

ノマドは、好ましくは無線信号の形で、データをブロードキャストして受信することが可能なデバイスを有する。デバイスは、近くのHexAnchorとの間で信号および/またはメッセージの送信と受信の両方を行うのに十分な範囲を有する。HexAnchor自体と同様に、ノマドのビーコンデバイスの最低限の範囲は好ましくは2lである。

【0104】

デバイスは、専用デバイス、またはスマートフォンもしくはタブレットなどの無線機能を含む多機能デバイスであり得る。デバイスには、携帯電話のsimカードなどの、固有の識別情報をデバイスに与える機構が含まれている。そのようなデバイスから出される通信は、偽装またはなりすましが難しい。

【0105】

閾値がキーシェアのために確立される。この閾値は、ノマドの位置(ならびにアンカーの位置)についての合意を形成するために必要とされるHexAnchorの最小限の数を表す。3次元空間におけるアンカーの位置を決定するには、すなわち、三辺測量の計算に成功するには、少なくとも3つのアンカーがなければならないことを考慮すると、閾値(全体でτと表記される)は少なくとも4であるはずである。

【0106】

τ≧4個のアンカーのうちのあるアンカーが、ノマドの位置に対する距離および/または位置基準が満たされていることに満足している(および好ましくは、六角形の中のすべての他のアンカーの距離についても満足している)場合、そのアンカーは、ノマドの位置を確認する署名の生成に寄与することを選ぶ。τ≧4個のアンカーが満足している場合、それらのアンカーは協調して六角形のHexKeyのためのデジタル署名を生成することに成功できる。

【0107】

ノマドがその位置を決定する際に行うステップが以下で説明される。ノマドおよびそのデバイスという用語は、簡潔にするために交換可能に使用されることがあることに留意されたい。

【0108】

1. ある位置にあるノマドが、その位置を確定しようとしていることを宣言する信号をブロードキャストする。このブロードキャストは、生成されたデバイス/ノマドの(たとえば、simカードの)固有の識別子を含む。

【0109】

2. 1つまたは複数のHexAnchorがこの信号を受信する。

【0110】

3. この信号を受信する各HexAnchorが、ノマドとの間での無線信号の送信と受信を通じて、HexAnchorからノマドまでの距離を決定する計算を実行する。これは、タイムオブフライト計算などの1つまたは複数のRF(無線周波数)計算を含んでもよく、これは、第1のトランシーバAから何らかの固有のデータを伝送して前記データが第2のトランシーバBからトランシーバAに返されるようにして、次いで往復にかかった時間を測定することを伴ってもよい。そして、2つのトランシーバ間の距離が計算されてもよい。追加または代替として、位相差の使用を含む他のタイムオブフライト解決策が使用されてもよい。

【0111】

4. ノマドがHexAnchorから2lの距離以内にある場合、アンカーはノマドに以下を伝送する:
a. HexAnchorが担当する六角形の3つのHexKey、
b. HexAnchorとノマドとの間の距離、
c. HexAnchorの公開鍵、および
d. ノマドとHexAnchorとの間の双方向通信チャネルのために必要とされる任意の他の情報。

【0112】

5. ノマドが、最も近いものから最も遠いものまで順番に順位付けられた対応するHexAnchorのリストを作成する。

【0113】

6. 最も近いアンカーから開始して、ノマドが、共通のHexKeyを担当する最初のτ個の固有のアンカーに到達するまで、リストの中を進む。共通のHexKeyは、複数のアンカーのセットに共通の公開鍵である。この例では、τ=5である。

【0114】

7. ノマドが次いで、その共通のHexKeyのために、デジタル署名を自身の代わりに生成するようにこれらのτ個のアンカーに依頼する。

【0115】

8. τ個のアンカーのセットが協調してこの署名を生成する。そうする際、ノマドが、完全な署名を取得する前に、アンカー間でのデータの中継および/またはアンカーから受信されたデータの処理に関与してもよい。

【0116】

図10のフローチャートは、ノマドの位置を確定するのに関係する行為の順序を示す。

【0117】

上のステップ5および6の代わりに、ノマドの位置を決定するためにノマドに対して他の方法が利用可能である。たとえば:

【0118】

Table1(表2)に示される距離情報をノマドが受信することを考える。

【0119】

【表2】

【0120】

ノマドが次いで、上のステップ5および6の代わりに以下のステップを実行してもよい。

【0121】

9. HexSetのセットにおいて表される固有の六角形のセット、たとえばH、M、N、I、O、S、T、B、G、Xを特定する。

【0122】

10. HexAnchorを介した表現のt個の事例を伴う少なくとも2つの六角形があるような、最大の整数値t≦6を選択し、たとえばt=3である。

【0123】

11. 少なくともt回表される各々の固有の六角形に対して、それぞれの表現のt個の事例を選択する(たとえば、六角形Nの場合、これらの事例は以下のTable2(表3)に示され、六角形Sの場合、これらの事例は以下のTable3(表3)に示される)。

【0124】

【表3】

【0125】

12. 少なくともt個のアンカーによって表される各六角形に対して、ノマド/デバイスが次いで、対応するHexAnchorのセットとノマドとの間の平均距離を計算する。たとえば、Sの平均は、(l+l+l⁺)/3であり、Nの平均は、(l+l+l)/3である。

【0126】

13. 次いで、平均距離が最低である六角形が、最も近い六角形として選択される。この例では、ノマドは、ノマドが六角形Nの中にあると決定する。ノマドは次いで、上のステップ7に続く。

【0127】

このセクションでは、ノマドがどこにいる可能性があるか、およびノマドの位置についてどのような決定が行われるかの例を考える。

【0128】

シナリオ1
シナリオ1では、ノマドが六角形の概ね中心にいる図11の場合を考える。最も近いアンカーは、ノマドがいる六角形を定義するアンカーである。各アンカーは約距離lだけ離れている。したがって、少なくともτ個のアンカーが位置に対する要求に応答する場合、これらのτ個のアンカーの共有されるHexKeyが、取り決められたノマド位置となる。

【0129】

アンカー1、2、3、4、5、および6が、位置を確定するためのノマドの要求に応答することを考える。これらのうち、共通のHexKeyを共有する、示される順序付けられたリストの中の最初のτ=5個のアンカーは、アンカー1、2、3、4、および5である。この共通のHexKeyはNであり、アンカーの同じセットが続いて、ノマドにそうするように依頼されると、協調して公開鍵Nのためのデジタル署名を生成する。

【0130】

シナリオ2
シナリオ2では、ノマドが六角形Tの内部にある図12の事例と、ノマドが別の六角形Nのためのデジタル署名を生成することが可能である確率を考える。「ノマドが(意図的にまたは別様に)ノマドの位置していない六角形のためのデジタル署名を生成する確率は？」という疑問が生じ得る。

【0131】

すなわち、六角形Tの中のノマドは、隣接する六角形Nのための署名を生成することが可能であるか？図12は、aからgと表記される7つの文字付きの領域を示す。円により包含されるエリアが、(六角形Nの)アンカーがノマドのための署名に寄与することが許容される範囲を表すと仮定すると、六角形Tの文字付きの領域は、これらの範囲が重複するエリアを表す。たとえば、領域aはアンカー3および4によって包含されるエリアを表し、領域bはアンカー3、4、および5によって包含され、一方領域gはすべてのアンカー1から6によって包含される。したがって、重複する範囲の数は、デジタル署名に寄与することが可能なHexAnchorの数である。

【0132】

これらの文字付きの領域の各々の幾何学的形状(六角形全体の形状および比例する面積)は、隣接する(NおよびT)六角形の任意の他のペアに対して同じであることに留意されたい。

【0133】

Table 4(表4)は、閾値τ=5である例における、文字付きの領域に対するHexAnchorの重複を示す。

【0134】

【表4】

【0135】

ノマドが六角形Tのある位置の中にある場合、六角形Nのためにデジタル署名を生成することができる。

【0136】

閾値τが5個のアンカーに設定される場合、六角形Nのための署名を生成することがある六角形Tの中の領域は、文字付きの領域e、g、およびfであり、これらの領域は六角形Nの境界に近い。この「バッファゾーン」は、ノマドの位置を知るための環境および状況に応じて受け入れ可能であってもよい。

【0137】

六角形の中にないにもかかわらず署名を生成するこの能力は、重複しているこれらのτ個のアンカーの寄与を使用して署名を生成することにより実際にはいない位置にいると主張することが可能である、悪意のあるノマドに対して問題となることに留意されたい。

【0138】

ノマドが六角形Nの中のアンカーから応答を受信しているだけではなく、六角形Tの中のアンカーからも通信を受信していることを考慮すると、六角形Tの中の信頼できるノマドは、それらの六角形に関して正しい位置を確定することが可能である。すべてのアンカーが動作可能であると仮定すると、順位付けられたリストにおいて、ノマドは、六角形Nの中のτ個のアンカーに到達する前に、六角形Tの中のτ個のアンカーに到達する。

【0139】

2つの隣接する一般的な六角形(NおよびT)を示す図13を考える。周りの六角形(図示せず)は図12に示されるような名前を有することに留意されたい。図13は、六角形Tの中にあるがNから少なくともτ個のアンカーの範囲にあるノマドが、どのようにTの中にあるものとして分類されるかを示す。τ≧4である場合、これは、Table 4(表5)において示されるように、領域e、f、および/またはgを参照する。

【0140】

図13から、Tの中のノマドから六角形Tの中のアンカーψ_i ^Tまでの距離は、そのノマドから六角形Nの中のミラーされたアンカーψ_i ^Nまでの距離より常に近いことに留意されたい。2つの六角形(NおよびT)は、アンカーψ₃ ^N＝ψ₁ ^Tおよびψ₄ ^N＝ψ₆ ^Tを共有することにも留意されたい。

【0141】

アンカーは(関連するHexSetとともに)図14においてミラーされたペアとして配置される。両方の六角形が共通の2つの共有されるアンカーを有することを念頭に置くと、ノマドは、六角形Nを共通に有するτ個のアンカーに到達するより前に、HexSetの要素として六角形Tを共通に有するτ個のアンカーに到達することに留意されたい。これは(共有されるアンカーとは別に)、
-ミラーされたアンカーに対して、Tの中のアンカーがNの中の対応するアンカーよりノマドに常に近い
- 他のアンカーがそれらの個々のHexSetにおいてNとTの両方を有する
という事実によるものである。

【0142】

図14を参照すると、順序付けられたリストにおいて、ノマドが、六角形Nを伴うτ個のアンカーに到達する前に、HexSetの中の六角形Tを伴うτ個のアンカーに到達するであろうことがわかる。図14において、最も近い/最も遠いという表記は、イントラミラーされた(intra-mirrored)アンカーペアだけに当てはまり、インターミラーされた(inter-mirrored)アンカーペアには当てはまらないことに留意されたい。また、図14では結合されるものとして表されているが、アンカーのペアのさらなるアンカーは、すべてのアンカーの順序付けられたリストにおいて必ずしもすぐ後のものではない(離れている距離に関係するので)ことにも留意されたい。

【0143】

認証されたノマド位置を表すデジタル(ECDSA)署名の生成がここで説明され、署名を生成するために必要とされるτ個のアンカーのセットは、

【数1】

であり、
- ノマドは上で説明されたようにその位置/六角形(たとえば、六角形N)を決定している。
- すべてのHexAnchorがそれらのそれぞれのHexSetの六角形(特に六角形N)のためのキーシェアを受信して妥当性を確認している。このキーシェアの妥当性確認は、前に説明された妥当性確認方式を使用して行われ得る。
- アンカーψ_i ^Nへのノマドの通信は、物理的なモバイルsimカードと結び付けられた数字などの、ノマドの埋め込まれた固有の識別子を含んでもよい。通信内にsimカード識別子情報を含めることは、好ましくは、ノマド自身によっては実行されず、PLaCESプロトコルを利用するノマドのデバイスによって実行される。例として、通話を行うユーザが自分の個人の電話番号を入力するのではなく、simカードに含まれる情報に基づいてその特定の電話から通話が発信されていることを、基地局が特定することが可能である。HexAnchorとの通信においてsimカードを介して埋め込まれた情報(nomadIDなど)をノマドが変更することが難しいことは、PLaCESプロトコルのセキュリティにとって有利である。

【0144】

すべてのHexAnchorがすべてのそれらのキーシェアの妥当性を(たとえば、上で説明されたPVSS法を使用して)確認すると、デジタル署名を生成する協調にどのアンカーが関与するかを決定するためのプロセスが開始される。これが完了すると、アンカーは次いで、署名を生成する協調プロセスを開始する。上で言及されたように、閾値署名方式の使用を通じて、署名が導かれる。

【0145】

アンカーがノマドへの近さにより並べられている、アンカーの順序付けられたリストから、少なくともτ個のアンカーに共通の第1の六角形がノマドの位置であると見なされることを思い出されたい。したがって、これらのτ個のアンカーは、ノマドの位置を確定する署名の作成において使用される。

【0146】

このプロセスにおいて、ノマドが六角形Nの中にいることを証明しようとしていると仮定する。
1. ノマドが、六角形Nのための署名協調に参加するようにτ個のアンカーの各々に依頼する要求を、それらのアンカーに送信する。各ノードへのこの通信は同時に行われ得る。
2. 各アンカーψ_i ^Pへの通信は、六角形公開鍵N、およびノマドが署名を望むメッセージの少なくともハッシュを含む。代替または追加として、メッセージ自体が送信されてもよい。
3. 各アンカーがブロックチェーンを確認して、さらなるユーザにより出される可能性のあるトランザクションにおける規定されたnomadIDが、ノマドの通信に含まれるものと同じであるかどうか、および/またはメッセージmの中のnomadIDと同じであるかどうかを決定する。
4. τ個のアンカーの各アンカーψ_i ^Nが、要求を受信すると、ノマドが要求される範囲内にあることを確認するための確認を実行してもよい。
5. ノマドが範囲内にあり、nomadIDが一致する場合、アンカーψ_i ^Nが、
<P_i, sig, N, H(m), timestamp, distance, nomadID>
というデータを含むベクトル

【数2】

を作成し(そして内部ストレージに保存してもよい)、
ここで、
a. P_iはアンカーψ_i ^N
の公開鍵であり(HexKeyとは異なる個人の鍵)、
b. H(m)は署名される必要のあるメッセージまたはトランザクションのハッシュであり、
c. 距離はアンカーからのノマドの距離であり、
d. タイムスタンプは、ψ_i ^Nがノマドの距離を確証した時間であり、
e. sigは、「少なくともH(m)、N、timestamp、distance、およびnomadIDの連結」のハッシュの公開鍵P_iに基づく、デジタル署名である。
6. 各アンカーψ_i ^Nが、自身のベクトル

【数3】

をノマドに送信し、
7. ノマドがこれらのベクトルの各々をリストLVに追加し、
8. リストが少なくともτ個のアンカーからの有効な署名を伴うベクトルを含む場合、これらのアンカーは、位置に対応するデジタル署名を生成する際に協調するものとして選ばれる。

【0147】

署名されるべきメッセージにnomadIDを値として含めることは、メッセージがビットコイントランザクションである場合には、nomadIDがオペコードOP_RETURNによってビットコイントランザクション内に記憶され、ブロックチェーンに交換不可能にかつ公開で記憶されるという点で、有利である。

【0148】

ノマドのメッセージのプライバシーが望まれる場合、ノマドは、そのメッセージのハッシュをアンカーだけに送信することを選ぶことがある。しかしながら、アンカーが協調して生成する署名は、nomadIDと組み合わされるメッセージのハッシュのハッシュの署名、すなわちH(H(m),nomadID)になる。

【0149】

メッセージmに識別子を含める理由は、そうすると、ノマドがそこから通信している意図される物理デバイスがブロックチェーン上の規定される識別子に対応することを、HexAnchorが確認できるからである。

【0150】

識別子の規定は、さらなるユーザのトランザクションにおいて行われてもよいことに留意されたい(さらなるユーザは、出されたトランザクションを履行するために特定の位置に受信者がいることを必要とするユーザである)。規定される識別子は、さらなるユーザのトランザクションのOP_RETURNまたは別のものに記憶され得る。

【0151】

ブロックチェーンは、トランザクションの記録、および公開されており変更不可能である規定された識別子/nomadIDの記録を提供する。HexAnchorは、メッセージ/トランザクションを署名するために協調するように依頼されるとき、またはあらゆる任意に選ばれた時間において、規定されたnomadIDが何であるかを確かめるために、ブロックチェーンを確認してもよい。

【0152】

今や、τ個のHexAnchorのセットが六角形Nのための署名協調に参加することに合意しているので、アンカーは次いで、前記署名を生成することができる。以前に述べられたように、この協調的な署名プロセスは、より前に説明された閾値署名方式を使用し、以下で詳しく説明される。

【0153】

ECDSA署名はペア(r,s)であり、ここで
r=x₁ mod n ただし(x₁,y₁)=k×G
s=k^-1 (m+xr) mod n
であり、xは秘密鍵である。

【0154】

ECDSA署名を生成するためのプロセスが以下で展開される。

【0155】

【表5】

【0156】

任意選択で、署名の生成において、HexAnchorは他のアンカーと直接インターフェースせず、代わりにノマドを通じて通信する。このことの利点は、ノマドと個々に通信しているアンカーが、アンカーの要求される範囲内にノマドがあることを確認するためのより多くの機会を与えられるということである。任意の時点で、ノマドが特定のHexAnchorの必要とされる範囲内にない場合、HexAnchorは、署名を生成するために協調するのを止めることによって署名プロセスを中止することができる。効率性および他の問題を考慮すると、各アンカーは必ずしも、あらゆる機会においてこの距離確認を実行しなくてもよい。各アンカーには、適当であると判断した場合にいつ距離を確認するかを選ぶ能力がある。

【0157】

ここで、Table 5(表5)の各ステップが、ノマドがそれらのステップの実行にどのように含まれることがあるかについて説明される。

【0158】

ステップ1: τ=2t+1個のアンカーのグループπが、乱数であるシェアk_iを計算するためにディーラーレス秘密分散を使用する。プロセスが図16に示される。

【0159】

ステップ1は、エフェメラルキーkのシェアの分散であり、これは、ECDSA署名の計算において使用されるランダムに生成される数である。ECDSA署名はペア(r,s)であり、ここで、kは、0<k<qかつqがサブグループの次数であるようなものであり、k×G=(x₁,y₁)のr=x₁ mod nであり、s=k^-1 (m+xr) mod nである。

【0160】

上で説明されたディーラーレスベースのキーシェア分散に基づいて、以下のステップが行われる。ノマドが少なくともτ個のベクトルを含むリストLVを保有していると仮定すると、

【0161】

1. ノマドがリストLVならびにx値x_iを各HexAnchorに送信し、各アンカーは、(乱数kの)自身のシェアk_iが発見される多角形に割り当てられる。いくつかの場合、これらのx値を送信することが必要ではないことがあり、アンカーψ_i ^Nが自身のx_iとしてiを利用するであろうと単に仮定することができ、アンカーψ₃ ^Nに対しては3がx値になる。x_iは暗号秘密kのシェア部分と見なされてもよいことに留意されたい。

【0162】

2. LVの受信に際して、各アンカーは、各ベクトルの中の署名の妥当性を確認し、「mの中の規定されたnomadID」が「通信の埋め込まれたnomadID」と一致すること、および/または、「ブロックチェーンにおいて発見される支払者のトランザクションにおける規定される識別子」と一致することを確認する。

【0163】

3. アンカーψ_i ^Nが、ノマドが必要とされる範囲内にあることを次のように検証する。
a. まず、アンカーψ_i ^Nが、LVの中のセット

【数4】

からの少なくとも3つのランダムベクトルの距離およびタイムスタンプ値を使用して、三辺測量の計算を実行する。これは、アンカーψ_i ^Nに、六角形Nの中のどこにノマドがいる可能性が高いかについてのより正確な理解を与える。
b. 第2に、望まれる場合、アンカーが、ノマドからの距離を再び計算するためにある関数を実行してもよい。そうすることの理由には、ベクトルデータを使用した三辺測量の計算に起因する矛盾、またはアンカーとの最後の通信からの時間経過に起因する矛盾があってもよい。

【0164】

4. ノマドが必要とされる領域内にあることにアンカーが満足しない場合、アンカーが署名生成プロセスから出て、それ以外の場合、アンカーが次のステップに続く。

【0165】

5. アンカーψ_i ^Nが次いで、次数tのランダム多項式f_i(x)を生成する。

【0166】

6. アンカーψ_i ^Nが、自身のベクトルの更新されたバージョン

【数5】

をノマドに送信する。「更新された」とは、新しい距離検証から取得された新しい距離およびその対応するタイムスタンプを含めることを指す。

【0167】

7. ノマドが、任意の新しい

【数6】

の値を用いてLVを更新する。

【0168】

8. アンカーψ_i ^Nが、アンカーψ_i ^Nの多項式f_i(x_j) mod n上のあらゆる他のプレーヤの点(y値)をノマドに秘密裏に送信する。これらの点は、意図されるアンカーの公開鍵P_j:j≠iを用いて各点が個別に暗号化されるという点で「秘密」である。y値は関数値と呼ばれることがある。

【0169】

9. 今度はノマドが点を意図されるアンカーに移送する。

【0170】

10. 各アンカーψ_i ^Nが、すべての自身の受信されたf₁(x_i)、f₂(x_i)、…f_τ(x_i)を加算して、乱数kのそれらのシェア

【数7】

を形成する。

【0171】

ステップ2: t+1人のプレーヤのサブグループπ'が協調して、Secure Share Joiningを使用してk×G=(x₁,y₁)を生成する。値r=x₁ mod nがグループ全体にブロードキャストされる。プロセスが図17に示される。

【0172】

ステップ2において、協調するアンカーは、ランダム値kの自身の個々のk_iシェアを明らかにすることなく、EC公開鍵r=kGを生成する。すべてのτ=2t+1個のアンカーがkGを生成することに参加することを要求されるのではなく、π'=t+1個のアンカーが参加することを要求されることに留意されたい。公開鍵を生成するために必要な乗算は、前に説明されたSecret Share Joiningに基づく。次のステップが行われる。

【0173】

11. ノマドが、LVからのπ'個のHexAnchorを、参加するであろうアンカーとして選択する。

【0174】

12. ノマドが、LVの現在のバージョンとともに、参加するように求める要求をそれらのアンカーに送信する。

【0175】

13. LVの受信に際して、各アンカーが、各ベクトルの中の署名の妥当性を確認し、mの中の規定されたnomadIDが通信において発見される埋め込まれたnomadIDと一致することを確認する。

【0176】

14. π'個のアンカーψ_i ^Nの各々が、ノマドが範囲内にあることを検証する。これは、ステップ1において以前に説明されたような三辺測量と距離の計算の両方を使用して行われ得る。アンカーが自身とノードとの間の距離を計算することはオプションである。

【0177】

15. 各アンカーψ_i ^Nが、自身の部分b_i,π'k_i×Gを計算し、ここでbは補間係数である。これらの部分は暗号署名の一部と見なされてもよい。

【0178】

16. 各アンカーψ_i ^Nが、自身の部分ならびに自身のベクトル

【数8】

の任意の更新されたバージョンをノマドに送信する。

【0179】

17. ノマドが、各部分を加算または合成して、

【数9】

を生成する。kGが署名の構成要素として見なされてもよい場合、r=x₁ mod nは署名(r,s)の構成要素であり、kGから直接かつ容易に導出可能である。

【0180】

18. ノマドが、すべての参加しているHexAnchorに少なくともr=x₁ mod nを送信する。

【0181】

19. ノマドが、受信された任意の新しい

【数10】

の値を用いてLVを更新する。

【0182】

ステップ3: τ=2t+1個のアンカーのグループπが、Secure Inverseを使用してk^-1 mod nにおけるシェアを計算する。各シェアは、k_i ^-1と呼ばれる。プロセスが図18に示される。

【0183】

ECDSA署名の決定においてsを計算するために、kの逆数が必要とされる。しかしながら、値k^-1(またはk)はいずれの参加者にも知られていない。代わりに、各HexAnchorが、署名の部分の作成において自身のシェアk_i ^-1を計算して利用する。このプロセスは秘密シェアの乗算を含むので、グループπは、k^-1 mod nにおいてシェアを計算するために協調するπ=2t+1人のプレーヤを備える。

【0184】

逆数としてそれらのシェアを得るために、次のステップが行われる。

【0185】

20. ノマドが、k_i ^-1のシェアを生成するためにLVおよび要求を送信するプロセスを開始する。

【0186】

21. LVの受信に際して、各アンカーが、各ベクトルの中の署名の妥当性を確認し、mの中の規定されたnomadIDが通信において発見される埋め込まれたnomadIDと一致することを確認する。

【0187】

22. π個のアンカーψ_i ^Nの各々が、ノマドが範囲内にあることを検証する。ステップ1およびステップ2におけるような同じ2段階の距離確認が、この検証を実行するために使用されてもよい。

【0188】

23. アンカーおよびノマドが、乱数であるシェアc_iを計算するためにディーラーレス秘密分散を利用する。これは、ステップ1の方法と同じやり方で達成される。

【0189】

24. 各アンカーψ_i ^Nが、部分b_i,πk_ic_i mod nを計算し、これをノマドに送信する。

【0190】

25. ノマドが、各部分を加算して、

【数11】

を生成し、kcは中間の暗号値として見なされてもよく、それは、kcは署名の構成要素ではないが、署名の構成要素をセキュアに計算するプロセスにおいて使用されるからである。したがって、部分b_i,πk_ic_i mod nは、中間の暗号値の部分と呼ばれ得る。

【0191】

26. ノマドが値kcを各アンカーに送信する。

【0192】

27. 各アンカーψ_i ^Nが、逆数(kc mod n)^-1 mod n=k^-1c^-1 mod nを計算する。

【0193】

28. 各アンカーψ_i ^Nが、第2の部分k^-1c^-1×c_i mod nを計算する。これは、逆数値k^-1のアンカーのシェアk_i ^-1である。

【0194】

ステップ4: グループπの各アンカーψ_i ^Nが部分b_i,πk_i ^-1(m+x_ir) mod nを計算し、mは署名されるメッセージ(たとえば、暗号トランザクション)である。

【0195】

今や各HexAnchorが逆数k^-1の自身のk_i ^-1のシェアを有するので、次いで各アンカーがECDSA署名の自身の部分を計算する。

【0196】

29. 各アンカーψ_i ^Nが、署名の自身の部分b_i,πk_i ^-1(m+x_ir) mod nを計算する。
30. アンカーが自身の部分をノマドに送信する。

【0197】

ステップ5: グループが協調して自身の部分を加算し、必要とされるECDSA署名のsを与える。

【0198】

ノマドが今や、τ=2t+1個のアンカーのセットからのすべての部分を加算してECDSA署名(r,s)のsを生成する責任を負う。

【0199】

31. ノマドが、すべての部分を加算または合成して、署名の別の構成要素であるsを次のように生成する。

【数12】

【0200】

32. ノマドは今や、ノマドの位置が六角形Nの中にあることを確認する有効な署名(r,s)を所有する。ノマドはステップ2からrをすでに知っていることを思い出されたい。

【0201】

33. ノマドは今や、ノマド位置の確証を必要とするブロックチェーントランザクションのデジタル署名などの、望まれるサービスのためのデジタル署名を使用してもよい。

【0202】

署名の生成において利用されるキーシェアの妥当性確認は、上で説明されたPVSS妥当性確認方式を使用することによって行われ得ることに留意されたい。アンカー間の通信が必要である場合、これはノマドを媒介者として行われてもよい。

【0203】

成功した位置証明(PoL)プロトコルの実行の出力がデジタル署名ECDSAであることを考慮すると、PLaCESは、ビットコイントランザクションのそれぞれのプロトコルの何も(オペコードまたは他のもの)変更する必要なく、ビットコイントランザクションとともに使用されてもよい。必要とされるのは、トランザクションTrAの出力スクリプト<scriptPubKey>に、六角形の公開鍵(たとえば、N)のためのデジタル署名に対する要件を、TrAのコインにアクセスするための別のトランザクションTrBの入力スクリプト<scriptSig>に対する条件の一部として追加することだけである。

【0204】

理論的には六角形Nのための署名だけが必要とされることがあるが、トランザクションは特定の個人/エンティティに向けられる可能性が高いことを考慮すると、コインにアクセスするために満たされるべき基準は、六角形の公開鍵ならびにエンティティの公開鍵Pに基づいてもよい。これは、以下で提示され図19において概略的に図示されるものなどの、m-of-nマルチシグトランザクションとしてスクリプトにおいて表されてもよい。

【0205】

【表6】

【0206】

トランザクションのnTimeLock値と組み合わされると、本開示の実施形態は、位置基準に加えて時間基準を含んでもよい。例として、航空会社は、ある時間までに乗客がいなければいけない場所に乗客を運べなかった場合に顧客に割引を約束するような仕組みを売り込むことがある。そのような合意は、約束チャネルを使用して実施され得る。これは、約束T_C、支払T_P、およびこの例では割引T_Dトランザクションという、3つのトランザクションを備える支払チャネルである。

【0207】

約束トランザクションT_Cは、顧客により作成され、商品/サービス(航空券)の費用であるコインxを預託する。預託された資金は、
1. 顧客の署名σ(C)および航空会社の署名σ(A)、または
2. 位置署名σ(N)および航空会社の署名σ(A)
のいずれかの提供があった場合にのみアクセスされ得る。

【0208】

約束トランザクションは、nomadID(航空機に固有のsimカード)の記録を含んでもよいことに留意されたい。

【0209】

支払トランザクションT_Pは、xの完全な支払を集めるために航空会社Aが使用するトランザクションである。このトランザクション内で、乗客σ(N)の意図される行き先の六角形のためのPLaCES署名が、航空会社σ(A)の署名とともに必要とされる。

【0210】

σ(N)の生成に関与するHexAnchorは、ブロックチェーンを参照して、約束トランザクションの規定されたnomadIDがノマド/航空会社からアンカーへの通信に埋め込まれているものと同じであることを検証してもよい。

【0211】

割引トランザクションT_Dは、約束トランザクションのx個の預託された資金から、総額dを顧客Cに、x-dを航空会社に移すnTimeLockedトランザクションである。dは乗客が取得する割引額である。

【0212】

割引トランザクションがnTimeLockedであることは、ある特定の時点(UNIX(登録商標)時間またはブロック高さに関して定義されてもよい)の前には割引トランザクションをブロックチェーンに出すことに成功できないことを意味する。これは、航空機が特定の期限の前にその位置に到達しない場合、顧客は割引トランザクションを出して自分でdを取り戻してもよいことを意味する。

【0213】

ここで図20を見ると、本開示の少なくとも1つの実施形態を実践するために使用されてもよいコンピューティングデバイス2600の説明のための簡略化されたブロック図が提供されている。様々な実施形態において、コンピューティングデバイス2600は、上で示され説明されたシステムのいずれかを実装するために使用されてもよい。たとえば、コンピューティングデバイス2600は、データサーバ、ウェブサーバ、ポータブルコンピューティングデバイス、パーソナルコンピュータ、または任意の電子コンピューティングデバイスとして使用するために構成されてもよい。図21に示されるように、コンピューティングデバイス2600は、メインメモリ2608および永続ストレージ2610を含むストレージサブシステム2606と通信するように構成され得る、1つまたは複数のレベルのキャッシュメモリおよびメモリコントローラ(まとめて2602と表記される)を伴う1つまたは複数のプロセッサを含んでもよい。示されるように、メインメモリ2608は、ダイナミックランダムアクセスメモリ(DRAM)2618と読取り専用メモリ(ROM)2620とを含み得る。ストレージサブシステム2606およびキャッシュメモリ2602は、本開示において説明されたようなトランザクションおよびブロックと関連付けられる詳細などの、情報の記憶のために使用されてもよい。プロセッサ2602は、本開示において説明されたような任意の実施形態のステップまたは機能を提供するために利用されてもよい。

【0214】

プロセッサ2602はまた、1つまたは複数のユーザインターフェース入力デバイス2612、1つまたは複数のユーザインターフェース出力デバイス2614、およびネットワークインターフェースサブシステム2616と通信することができる。

【0215】

バスサブシステム2604は、コンピューティングデバイス2600の様々なコンポーネントおよびサブシステムが意図されるように互いに通信することを可能にするための機構を提供してもよい。バスサブシステム2604は単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は複数のバスを利用してもよい。

【0216】

ネットワークインターフェースサブシステム2616は、他のコンピューティングデバイスおよびネットワークへのインターフェースを提供してもよい。ネットワークインターフェースサブシステム2616は、他のシステムからデータを受信し、コンピューティングデバイス2600から他のシステムにデータを伝送するためのインターフェースとして働いてもよい。たとえば、ネットワークインターフェースサブシステム2616は、データ技術者がデバイスをネットワークに接続することを可能にすることがあるので、データ技術者がデータセンタなどの離れた位置にいる間にデータをデバイスに伝送してデバイスからデータを受信することが可能であることがある。

【0217】

ユーザインターフェース入力デバイス2612は、キーボード、統合されたマウス、トラックボール、タッチパッド、またはグラフィクスタブレットなどのポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンなどのオーディオ入力デバイス、および他のタイプの入力デバイスなどの、1つまたは複数のユーザ入力デバイスを含んでもよい。一般に、「入力デバイス」という用語の使用は、コンピューティングデバイス2600に情報を入力するためのすべての可能なタイプのデバイスおよび機構を含むことが意図されている。

【0218】

1つまたは複数のユーザインターフェース出力デバイス2614は、ディスプレイサブシステム、プリンタ、またはオーディオ出力デバイスなどの非視覚的ディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)などのフラットパネルデバイス、発光ダイオード(LED)ディスプレイ、またはプロジェクションデバイスもしくは他のディスプレイデバイスであってもよい。一般に、「出力デバイス」という用語の使用は、コンピューティングデバイス2600から情報を出力するためのすべての可能なタイプのデバイスおよび機構を含むことが意図されている。1つまたは複数のユーザインターフェース出力デバイス2614は、たとえば、説明されるプロセスおよびその変形を実行するアプリケーションとのユーザの対話を、そのような対話が適切である可能性があるときに促進するための、ユーザインターフェースを提示するために使用されてもよい。

【0219】

ストレージサブシステム2606は、本開示の少なくとも1つの実施形態の機能を提供してもよい基本的なプログラミングおよびデータ構造物を記憶するための、コンピュータ可読記憶媒体を提供してもよい。アプリケーション(プログラム、コードモジュール、命令)は、1つまたは複数のプロセッサによって実行されると、本開示の1つまたは複数の実施形態の機能を提供してもよく、ストレージサブシステム2606に記憶されてもよい。これらのアプリケーションモジュールまたは命令は、1つまたは複数のプロセッサ2602によって実行されてもよい。ストレージサブシステム2606は追加で、本開示に従って使用されるデータを記憶するためのリポジトリを提供してもよい。たとえば、メインメモリ2608およびキャッシュメモリ2602は、プログラムおよびデータのための揮発性ストレージを提供することができる。永続ストレージ2610は、プログラムおよびデータのための永続(不揮発性)ストレージを提供することができ、フラッシュメモリ、1つまたは複数のソリッドステートドライブ、1つまたは複数の磁気ハードディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数のフロッピーディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数の光学ドライブ(たとえば、CD-ROMまたはDVDまたはBlue-Ray)ドライブ、および他の同様のストレージメディアを含んでもよい。そのようなプログラムおよびデータは、本開示において説明されるような1つまたは複数の実施形態のステップを行うためのプログラム、ならびに、本開示において説明されるようなトランザクションおよびブロックと関連付けられるデータを含み得る。

【0220】

コンピューティングデバイス2600は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション、または以下で説明される任意の他のデバイスを含む、様々なタイプであってもよい。加えて、コンピューティングデバイス2600は、1つまたは複数のポート(たとえば、USB、ヘッドフォンジャック、Lightningコネクタなど)を通じてコンピューティングデバイス2600に接続されてもよい別のデバイスを含んでもよい。コンピューティングデバイス2600に接続されてもよいデバイスは、光ファイバコネクタを受け入れるように構成される複数のポートを含んでもよい。したがって、このデバイスは、処理のためにデバイスをコンピューティングデバイス2600に接続するポートを通じて伝送されてもよい電気信号へと、光信号を変換するように構成されてもよい。コンピュータとネットワークの変化し続ける性質により、図21に図示されるコンピューティングデバイス2600の説明は、デバイスの好ましい実施形態を例示するための具体的な例として意図されているにすぎない。図21に図示されるシステムより多数または少数の構成要素を有する多くの他の構成が可能である。

【0221】

上で言及された実施形態は本開示を限定するのではなく例示すること、および、添付の特許請求の範囲により定義されるような本開示の範囲から逸脱することなく、当業者が多くの代替的な実施形態を設計することが可能であることに、留意されたい。請求項において、括弧の中に置かれたあらゆる参照符号は、請求項を限定するものとして解釈されるべきではない。「備える(comprising)」および「備える(comprises)」などの語は、任意の請求項または明細書に列挙されるもの以外の要素またはステップの存在を全体として排除するものではない。本明細書では、「備える(comprises)」は「含む(includes)またはからなる(consists of)」を意味し、「備える(comprising)」は「含む(including)またはからなる(consisting of)」を意味する。単数形での要素への言及は、そのような要素の複数形での言及を排除せず、その逆も当てはまる。本開示は、いくつかの別個の要素を備えるハードウェアによって、および適切にプログラムされたコンピュータによって実装されてもよい。いくつかの手段を列挙するデバイスの請求項において、これらの手段のいくつかは、ハードウェアの1つの同じ項目によって具現化されてもよい。ある対策が相互に異なる従属請求項に記載されているという単なる事実は、これらの対策の組合せを使用して利益を得ることができないことを示すものではない。

【符号の説明】

【0222】

2600 コンピューティングデバイス
2602 プロセッサ
2604 バスサブシステム
2606 ストレージサブシステム
2608 メインメモリ
2610 永続ストレージ
2612 ユーザインターフェース入力デバイス
2614 ユーザインターフェース出力デバイス
2616 ネットワークインターフェースサブシステム
2618 DRAM
2620 ROM

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】