特表 2024-545953 分散データ管理のための方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-16

(54)【発明の名称】分散データ管理のための方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241209BHJP

   G06F 21/64 20130101ALI20241209BHJP

【ＦＩ】

H04L9/32 200B

G06F21/64

【審査請求】未請求

【予備審査請求】有

(21)【出願番号】P 2024533076

(86)(22)【出願日】2022-12-01

(85)【翻訳文提出日】2024-07-25

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

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

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

(31)【優先権主張番号】63/284,816

(32)【優先日】2021-12-01

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】524207541

【氏名又は名称】ウエストレイク，コリン フィリップ

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】ウエストレイク，コリン フィリップ

(57)【要約】

本発明は、ユーザデバイス上での分散データ管理のためのコンピュータ実装方法に関する。本方法は、中央サーバからデータについてのクエリを受信することと、ユーザデバイス上に記憶されたデータがクエリの少なくとも１つの条件を満たすことを決定することと、ユーザデバイスによって生成された、ユーザデバイスによって記憶されたデータを使用して、ユーザデバイスによって生成された以前に生成された公開鍵を決定することであって、ユーザデバイスによって記憶されたデータがデータを含むデータエンベロープと、以前に生成された公開鍵とを含み、データエンベロープが外部エンティティによって署名されている、決定することと、以前に生成された公開鍵と鍵ペアを形成する秘密鍵を使用してデータエンベロープに署名することと、署名されたデータエンベロープでクエリに応答することと、を含む。
【選択図】図１２

【特許請求の範囲】

【請求項1】

ユーザデバイス上における分散データ管理のためのコンピュータ実装方法であって、
中央サーバからデータのクエリを受信するステップ；
前記ユーザデバイス上に記憶されたデータが前記クエリの少なくとも１つの条件を満たすことを判定するステップ；
前記ユーザデバイスによって生成された、以前に生成された公開鍵を、前記ユーザデバイスによって記憶された前記データを使用して決定するステップであって、前記ユーザデバイスによって記憶されたデータは、データと前記以前に生成された公開鍵とを備えるデータエンベロープを備え、前記データエンベロープは外部エンティティによって署名されている、ステップ；
前記以前に生成された公開鍵との間で鍵ペアを形成する秘密鍵を使用して前記データエンベロープに署名するステップ；
前記署名されたデータエンベロープでクエリに応答するステップ；
を有する方法。

【請求項2】

前記外部エンティティは前記データを提供しているか、または、前記外部エンティティは前記データの認証について保証されている、請求項１記載の方法。

【請求項3】

データに対する前記クエリはクエリ公開鍵を含み、前記署名されたデータエンベロープは前記クエリに応答する前に前記クエリ公開鍵を使用して暗号化される、請求項１または請求項２記載の方法。

【請求項4】

前記ユーザデバイスは、ショートフォームランダム識別子および前記署名されたデータエンベロープで応答する、請求項１から３のいずれか１項記載の方法。

【請求項5】

前記クエリは、前記中央サーバによって前記ユーザデバイスに対してプッシュされる、請求項１から４のいずれか１項記載の方法。

【請求項6】

前記クエリは、前記ユーザデバイスによって前記中央サーバから収集される、請求項１から４のいずれか１項記載の方法。

【請求項7】

前記ユーザデバイスによって記憶される前記データは、トランザクションに関するデータおよびプライベートデータのうちの少なくとも１つである、請求項１から６のいずれか１項記載の方法。

【請求項8】

前記ユーザデバイスは、前記署名されたデータエンベロープと、外部エンティティＩＤと、オプションとして前記外部エンティティの公開鍵とで応答する、請求項１から７のいずれか１項記載の方法。

【請求項9】

前記ユーザデバイスは所定数のピアデバイスに対して接続され、前記ユーザデバイスは処理のために前記クエリを前記ピアデバイスに対して転送する、請求項１から８のいずれか１項記載の方法。

【請求項10】

トランザクションに関する前記中央サーバからのメッセージを受信するステップ；
トランザクション公開鍵／秘密鍵ペアを生成し、前記トランザクション公開鍵を用いてトランザクションデータについて前記トランザクション業者に対して要求を送信するステップ；
前記トランザクションデータと前記トランザクション公開鍵とを含む署名されたデータエンベロープを受信および記憶するステップであって、前記データエンベロープは前記トランザクション業者の秘密鍵で署名されている、ステップ；
を有する、
請求項１から９のいずれか１項記載の方法。

【請求項11】

検証者公開鍵を受信し、前記検証者公開鍵を用いて、前記少なくとも１つの条件を満たす、前記ユーザデバイスによって記憶された前記データを暗号化し、前記暗号化されたデータを前記検証者に対して送信するステップを有する、請求項１から１０のいずれか１項記載の方法。

【請求項12】

中央サーバ上の分散データ管理のためのコンピュータ実装方法であって、
ユーザデバイスに対してクエリを生成するステップ；
署名されたデータエンベロープおよび公開鍵を、前記クエリに応答して前記ユーザデバイスから受信し、前記公開鍵を少なくとも１つの検証者に対して提供するステップ；
前記署名されたデータエンベロープのデータが前記クエリの条件を満たすかどうかに基づいて、前記少なくとも１つの検証者から結果を受信するステップ；
を有する方法。

【請求項13】

前記署名されたデータエンベロープおよび前記公開鍵を前記少なくとも１つの検証者に対してプッシュし、または、前記署名されたデータエンベロープおよび前記公開鍵を前記少なくとも１つの検証者による収集のために利用可能にするステップを有する、請求項１２記載の方法。

【請求項14】

前記中央サーバは、複数の署名されたデータエンベロープおよび関連する公開鍵を受信し、前記複数の署名されたデータエンベロープおよび関連する公開鍵を複数の検証者に対して提供し、前記複数の検証者からの結果を組み合わせる、請求項１２または請求項１３記載の方法。

【請求項15】

検証者を用いた分散データ管理のためのコンピュータ実装方法であって、
ユーザデバイスの公開鍵およびクエリを中央サーバから受信するステップ；
前記ユーザデバイスのための検証公開鍵および前記ユーザデバイスの公開鍵を提供するステップ；
前記ユーザデバイスの公開鍵に関連付けられたデータエンベロープを受信するステップであって、前記データエンベロープは前記検証公開鍵で署名される、ステップ；
前記データエンベロープ内のデータが前記クエリの少なくとも１つの条件を満たすかどうかを判定するステップ；
前記データエンベロープ内のデータが前記クエリの少なくとも１つの条件を満たすかどうかに基づいて結果を前記中央サーバに対して送信するステップ；
を有する方法。

【請求項16】

前記データエンベロープは、前記検証公開鍵を用いて暗号化される、請求項１５記載の方法。

【請求項17】

前記ユーザデバイスの前記検証公開鍵および前記公開鍵は、前記ユーザデバイスに対して送信されるか、または、前記ユーザデバイスが収集するために利用可能にされる、請求項１５または請求項１６記載の方法。

【請求項18】

前記中央サーバから前記ユーザデバイスの公開鍵およびクエリを受信するステップは、複数の公開鍵を受信することと、処理のために１つを選択することとを含む、請求項１５から１７のいずれか１項記載の方法。

【請求項19】

前記検証者がユーザデバイスである、請求項１５から１８のいずれか１項記載の方法。

【請求項20】

コンピュータプログラムであって、前記プログラムがコンピュータによって実行されると、前記コンピュータに、請求項１から１９のいずれか１項記載の方法を実行させる命令を含む、コンピュータプログラム。

【請求項21】

コンピュータによって実行されると、前記コンピュータに請求項１から１９のいずれか１項記載の方法を実行させる命令を含む、コンピュータ可読媒体。

【請求項22】

請求項１から１９のいずれか１項記載の方法を実行するように構成されたプロセッサを備えるデータ処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、プライバシーを損なうことなく集約クエリを可能にすることを目的とする、情報の記憶および交換を含む、分散データ管理のための方法およびシステムに関する。

【背景技術】

【0002】

消費者は、オンラインおよび物理的な世界の両方での商業活動によって生成されるデータ証跡の存在および価値をますます認識するようになってきている。多くの人々はこのデータが誤用される可能性があることを警戒しているが、ほとんどがデータ駆動型である業者からのオファーも評価している。

【0003】

業者はビジネスモデルを最適化し、これまで以上に収集しようとするために、消費者データの大規模なリポジトリに依存しているが、データ侵害によって引き起こされるビジネス上の脅威に警戒している。政府はデータの利用と保存の規制を強化し始め、GDPR、HＩＰPA、CCPA（カリフォルニア州プライバシー法）などの法律を制定し、違反に対する多額の罰金を科している。

【発明の概要】

【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】支払中のデータフローを示す；

【図3】支払い中の代替データフローを示す；

【図4】データポイントがクエリの条件を満たすことを検証するプロセスを示している。

【図5】検証されたデータ点を記憶するためのプロセスを図示する；

【図6】支払い中の代替データフローを示す；

【図7】データポイントがクエリの条件を満たすことを検証するためのプロセスを示す；

【図8】発行者によって署名されたトークンの例を示す；

【図9】システム署名の１例を示す；

【図10】発行者署名の例を示す；

【図11】非対称暗号化方式に対する代替暗号化を示す；

【図12】本発明の１実施形態による方法を示す

【図13】本発明の１実施形態による２重符号付きデータエンベロープを示す。

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

【0032】

用語Ｎｙｍは、匿名化の目的のために使用されるランダムに生成されたＩＤを表す。これは、公開鍵とオプションのショートフォームランダム識別子で構成される。公開された公開鍵に対応する秘密鍵は、Ｎｙｍ所有者によって保持され、いかなる他の当事者にも公開されない。Ｎｙｍ生成は、パブリック／プライベートキーペアおよびオプションのショートフォーム識別子を生成するプロセスである。他の当事者へＮｙｍを送信することは、常にＮｙｍの公開部分のみについてのものであり、非公開部分は関係しない。ユーザは通常、多くのＮｙｍを持ち、おそらくトランザクションごとに１つのＮｙｍを持つ。Ｎｙｍの使用は、ユーザが異なる当事者と取引するときに複数のＩＤを提示することを可能にする。

【0033】

ＳＣは、「システムコーディネータ」を意味する。これは、ビジネスロジックおよびメッセージルーティングの実行を担当するプロセスである。この用語は「トランザクションコーディネータ」と同義であり、２つの用語は、以下で互換的に使用される。システムコーディネータは、中央サーバ上に実装され得る。

【0034】

ＶＮは『検証者ノード』を意味する。これらは、データの出所をチェックし、それが必要な条件を満たすことをチェックする。この用語は「トランザクション検証者」と同義である。２つの用語は、以下で互換的に使用される。

【0035】

ＮＡＴは、Network Address Translationの略である。

【0036】

ＩＰは、発行者プロセッサを意味する。これらのエンティティは、カード発行者に代わってカード取引を処理する。

【0037】

ＢＩＮは、バンク識別番号（カード番号の最初の６ 桁または８ 桁）を意味する。

【0038】

ＰＳＰは、「決済ゲートウェイ」と呼ばれる決済サービスプロバイダーを意味する。これらは、業者が支払ネットワーク（例えば、VISA、マスターカード、およびAmex）を介して発行銀行に支払要求を発行するために使用するインターフェースを提供する。

【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】

フローはトークン償還を伴わないフローと同じ方法で開始するが、ＳＣがユーザのアプリに業者のＩＤを送信するとき、ユーザにはトランザクションに対して償還するトークンを選択するオプションが与えられる。次いで、トークンＩＤ（またはトークン自体）がＳＣに送信され、ＳＣはトークンを台帳と照合して、すべての条件が満たされているかどうか、たとえば、ユーザが正当な所有者であり、トークンが期限切れではなく、トークンが、関連する特定のトランザクションタイプで使用するのに有効であるかどうかを確認する。この最後のステップは、取引のより多くの詳細を取り出すために、業者にデータ要求することをＳＣへ要求することができる。

【0093】

条件が満たされない場合、ユーザは通知され、そうでない場合、トークンに対するクレジットがトランザクションに対して適用され、その結果、ユーザのアカウントは額面よりも低く課金され、残高はトークンに対して相殺される。重要なことに、このプロセスは、トークンが償還されたことを知る方法を持たない業者には見えない。

【0094】

同じ結果を達成するために使用することができる２つの可能な動作モードがあることに留意されたい。報酬はユーザが適切な資格チェックに合格した後に発行されるトークンの形態で保持することができるか、またはトークンの使用を省くことができ、資格チェックは、請求の時点で実施することができる。どちらの場合も、２重支出を防ぐために台帳を維持する必要があることに注意する。また、トークンが、何らかの理由で、ハンドを交換するか、または分割されるか、または値を調整する場合にも、台帳が必要とされる。

【0095】

図２および図３において、ＰＳＰは、明確にするために省略されていることに留意されたい。

【0096】

決済ネットワークを利用しないトランザクションフロー
図６を参照する。

【0097】

取引を観察するためにＩＰを使用する代わりに、システムオペレータは、要求および応答を中継する、業者とＰＳＰとの間に位置するサービスを提供することができ、必要に応じて、再送信中に両方を修正する。これにより、ＩＰで説明したのと同じ機能が有効になるが、ＩＰに関連付けられたＢＩＮを持つカードだけでなく、決済カードも有効になる。例えば、要求が＄１００の支払いに対してなされ、ユーザが償還を望む＄１０の値を有するトークンを有するとシステムが決定した場合、サービスはＰＳＰ要求のペイロードを動的に変更し、要求された値を＄９０に減らすことができ、応答が戻ったとき、オプションで、＄１００のトランザクションが承認されたことを示すようにデータを変更することができる。ユーザは＄９０を請求されるが、業者は＄１００の通常の取引を見る。１０ドルの残高は、集計された日々の決済方法の一部として、業者口座に対して相殺され、したがって、データ漏洩を停止する。このようなサービスは、ＰＳＰに対して送信されたペイロードを正しく解釈するための手段を必要とし、したがって、多くの様々なＰＳＰと共に動作するようにプログラムされる機能を必要とする。ほとんどのＰＳＰ ＡＰＩは、ＸＭＬ、ＪＳＯＮ、または名前の値のペアであるペイロードを使用するＨＴＴＰベースであるので、これを提供するのは面倒ではない。いくつかのＰＳＰはまた、それらのシステムにおけるハッシュ関数またはＨＭＡＣ署名の使用を含み、この場合、ハッシュまたはデジタル署名はトランザクション量にわたってであり、システムは、量の変更後にハッシュまたは署名の再作成を可能にするように構成可能である必要がある。

【0098】

オファーまたはリワードの発行
業者は、特定の基準を満たす人々の設定に対してオファーまたはプロモーションをすることを望むことがある。業者が取引をすでにしているユーザに加えて、業者は、取引履歴のない基準を満たす他のユーザに対してオファーすることを望む場合がある。これを実施するために、オファーは、すべてのユーザにブロードキャストされるか、またはユーザが閲覧できるようにする必要がある。いずれの場合も、ユーザアプリはユーザのデバイスに記憶されたデータを検査することによって基準が満たされているかどうかを判定することができるので、システムは基準を満たしていないユーザをフィルタリングすることができる。償還の時点で、または、報酬が代替可能なトークンの形態である場合、請求の時点で、ユーザの適格性をチェックするだけでよい。

【0099】

モバイルデバイスへの真のブロードキャストは、本文書の他の箇所で述べられている理由のために困難であり得るので、ユーザデバイスが間隔を置いてオファーをチェックするポーリング機構が好ましい場合がある。

【0100】

トークンの販売／譲渡
オファーは有限数の請求者、例えば、最初の５００に限定されてもよく、または、時間によってのみ、例えば、ある日付の前に限定されてもよい。

【0101】

追加の制限は、フィットネス条件、すなわち、特定のアドホック基準を満たすことによって課されてもよい。

【0102】

オファーは後の請求のために基準を満たすすべての人がそれを記憶することを可能にする全てに対してブロードキャストされてもよく、先着順で利用可能であってもよい。これはトークンを主張する最初の５００人が１つを受け取るということを意味する（ここではトークンを請求することについて話しており、償還を請求することについて話していない）。

【0103】

加えて、人々の適格性は時間とともに、すなわち、オファーがなされた時点で変化し得るが、彼らは償還日前に適格になり得る。

【0104】

これは流通市場の可能性を開く。

【0105】

図１１は、非対称暗号化方式の代替暗号化を示している。図１１によれば、データはＡＥＳのような対称アルゴリズムで暗号化され、ＡＥＳ鍵は、意図された受信者の公開鍵で非対称暗号化を使用して暗号化される。次いで、暗号化された対称暗号化鍵は、メッセージとともに受信者に送信することができる。次いで、受信者は暗号化された対称鍵を解読するためにその秘密鍵を使用し、次いで、これを使用してメッセージを解読する。

【0106】

図１２は、本発明の１実施形態を示す。図１２において、方法１００は以下を有する：
●中央サーバからデータのためのクエリを受信（１０２）；
●ユーザデバイス上に記憶された（または保持された）データがクエリの少なくとも１つの条件を満たす（すなわち、デバイスが少なくとも１つのクエリ条件に一致するデータを保持するかどうかを決定する）（１０４）；
●ユーザデバイスによって記憶されたデータを使用して、ユーザデバイスによって生成された、以前に生成された公開鍵を決定する（または選択する）１０６。ユーザデバイスによって記憶されたデータは、データと以前に生成された公開鍵とを備えるデータエンベロープを備え、データエンベロープは外部エンティティによって署名されている（すなわち、データポイント内のＮｙｍ内の公開鍵に対応する秘密鍵を選択する）；
●以前に生成された公開鍵と鍵ペアを形成する秘密鍵を使用してデータエンベロープ（またはデータポイント）に署名する（１０８）；
●符号付きデータエンベロープ（またはデータポイント）でクエリに応答する（１１０）。

【0107】

方法は、クエリの他の条件とのさらなる一致があるかどうかを決定するステップ１１２と、ステップ１０６および１０８を繰り返すこととを含み得る。さらに、デバイスが少なくとも１つのクエリ条件に一致するデータを有しない場合、方法は終了する（１１４）。

【0108】

図１３は、本発明の１実施形態による２重符号付きデータエンベロープを示す。図示されるように、元のＮｙｍ（すなわち、ユーザＮｙｍまたはユーザ公開鍵）は、データ発行者（または業者）の秘密鍵を使用して署名された、発行者によって提供されるデータを有する署名されたデータエンベロープ内にある。データ発行者の識別子、および任意選択で公開鍵は、ユーザデバイスの秘密鍵で署名された第２エンベロープに含まれる。

【0109】

本発明の１実施形態はトークンを引き換えるためのコンピュータ実装方法を含むことができ、この方法は、条件および１つまたは複数のデータポイントとともにユーザデバイスからトークンを受信することと、１つまたは複数のデータポイントを１つまたは複数の検証者に配布することと、応答を調整することとを含む。

【0110】

トークンの所有権は、トークンおよび／または関連する台帳エントリに関連する暗号署名をチェックすることによって証明することができる。トークンを償還する際には、所有権と適格性の両方が任意の付属条件に合致する証拠を使用することができる。

【0111】

トークンに関する各データポイントは、データポイント上の署名を検証するために請求者と協調するトランザクション検証者に渡されてもよい。

【0112】

台帳に対するチェックは、ユーザが正当な所有者であり、トークンが満了しておらず、トークンが、関係する特定のトランザクションタイプにおいて使用するのに有効であるかどうかをチェックすることを含むことができる。最後のステップは、取引のより多くの詳細を検索するために業者にデータ要求することをシステムコーディネータへ要求することができる。

【0113】

トークンが、ハンドを変える、分割する、または何らかの理由で値を調整する場合、台帳を使用することができる。

【0114】

用語「備える（comprising）」は「含む（including）」ならびに「からなる（consisting）」を包含し、例えば、Ｘを「備える（comprising）」組成物はＸのみからなってもよく、または何か追加のもの、例えば、Ｘ＋Ｙを含んでもよい。

【0115】

特に明記しない限り、本明細書に記載の各実施形態は、本明細書に記載の別の実施形態と組み合わせることができる。

【0116】

本明細書に記載の方法は有形記憶媒体上の機械可読形態のソフトウェアによって、例えば、プログラムがコンピュータ上で実行されるときに本明細書に記載の方法のいずれかのすべての工程を実行するように適合されたコンピュータプログラムコード手段を含むコンピュータプログラムの形態で、実行されてもよく、コンピュータプログラムは、コンピュータ可読媒体上で実施されてもよい。有形（または非一時的）記憶媒体の例はディスク、ハードドライブ、サムドライブ、メモリカードなどを含み、伝搬信号を含まない。ソフトウェアは方法ステップが任意の適切な順序で、または同時に実行され得るように、並列プロセッサまたは直列プロセッサ上での実行に好適であり得る。これは、ファームウェアおよびソフトウェアが価値あり、別々に取引可能な商品であり得ることを認識する。所望の機能を実行するために、「ダム」または標準的なハードウェア上で実行または制御するソフトウェアを包含することが意図される。また、所望の機能を実行するために、シリコンチップを設計するために、またはユニバーサルプログラマブルチップを構成するために使用されるような、ＨＤＬ（ハードウェア記述言語）ソフトウェアなどのハードウェアの構成を「記述する」または定義するソフトウェアを包含することも意図される。

【0117】

当業者であれば、プログラム命令を記憶するために利用される記憶デバイスは、ネットワークにわたって分散され得ることを理解するであろう。例えば、リモートコンピュータは、ソフトウェアとして説明されるプロセスの例を記憶することができる。ローカルコンピュータまたは端末コンピュータはリモートコンピュータにアクセスし、ソフトウェアの一部または全部をダウンロードしてプログラムを実行することができる。あるいは、ローカルコンピュータが必要に応じてソフトウェアの一部をダウンロードするか、またはローカル端末およびリモートコンピュータ（またはコンピュータネットワーク）で一部のソフトウェア命令を実行することができる。当業者はまた、ソフトウェア命令のすべてまたは一部が、ＤＳＰ（デジタル信号プロセッサ）、プログラマブルロジックアレイなどの専用回路によって実行され得ることを、当業者に知られている従来の技法を利用することによって理解するであろう。

【0118】

上述の利益および利点は、１つの実施形態に関連し得るか、またはいくつかの実施形態に関連し得ることが理解されるであろう。実施形態は、記載された問題のいずれかまたはすべてを解決するもの、または記載された利益および利点のいずれかまたはすべてを有するものに限定されない。

【0119】

本明細書に記載の方法の工程は、任意の適切な順序で、または適切な場合には同時に実施することができる。さらに、個々のステップは、本明細書に記載される主題の趣旨および範囲から逸脱することなく、方法のいずれかから削除され得る。上記で説明した例のいずれかの態様を、記載された他の例のいずれかの態様と組み合わせて、求められる効果を失うことなく、さらなる例を形成することができる。上述のステップまたはプロセスのいずれも、ハードウェアまたはソフトウェアで実施することができる。

【0120】

好ましい実施形態の上記の説明は単なる例として与えられており、様々な修正が当業者によってなされ得ることが理解されるであろう。様々な実施形態がある程度の特定性を伴って、または１つ以上の個々の実施形態を参照して上述されてきたが、当業者は本発明の範囲から逸脱することなく、開示された実施形態に対して多数の変更をなすことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【手続補正書】

【提出日】2023-10-02

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

ユーザデバイス上における分散データ管理のためのコンピュータ実装方法であって、
中央サーバからデータのクエリを受信するステップ；
前記ユーザデバイス上に記憶されたデータが前記クエリの少なくとも１つの条件を満たすことを判定するステップ；
前記ユーザデバイスによって生成された公開鍵を、前記ユーザデバイスによって記憶された前記データを使用して選択するステップであって、前記ユーザデバイスによって記憶されたデータは、データと前記公開鍵とを備えるデータエンベロープを備え、前記データエンベロープは外部エンティティによって署名されている、ステップ；
前記公開鍵との間で鍵ペアを形成する秘密鍵を使用して前記データエンベロープに署名するステップ；
前記署名されたデータエンベロープで前記クエリに応答するステップ；
検証者公開鍵を受信し、前記検証者公開鍵を用いて、前記少なくとも１つの条件を満たす、前記ユーザデバイスによって記憶された前記データを暗号化し、前記暗号化されたデータを前記検証者に対して送信するステップ；
を有する方法。

【請求項2】

前記外部エンティティは前記データを提供しているか、または、前記外部エンティティは前記データの認証について保証されている、請求項１記載の方法。

【請求項3】

データに対する前記クエリはクエリ公開鍵を含み、前記署名されたデータエンベロープは前記クエリに応答する前に前記クエリ公開鍵を使用して暗号化される、請求項１または請求項２記載の方法。

【請求項4】

前記ユーザデバイスは、ショートフォームランダム識別子および前記署名されたデータエンベロープで応答する、請求項１から３のいずれか１項記載の方法。

【請求項5】

前記クエリは、前記中央サーバによって前記ユーザデバイスに対してプッシュされる、請求項１から４のいずれか１項記載の方法。

【請求項6】

前記クエリは、前記ユーザデバイスによって前記中央サーバから収集される、請求項１から４のいずれか１項記載の方法。

【請求項7】

前記ユーザデバイスによって記憶される前記データは、トランザクションに関するデータおよびプライベートデータのうちの少なくとも１つである、請求項１から６のいずれか１項記載の方法。

【請求項8】

前記ユーザデバイスは、前記署名されたデータエンベロープと、外部エンティティＩＤと、オプションとして前記外部エンティティの公開鍵とで応答する、請求項１から７のいずれか１項記載の方法。

【請求項9】

前記ユーザデバイスは所定数のピアデバイスに対して接続され、前記ユーザデバイスは処理のために前記クエリを前記ピアデバイスに対して転送する、請求項１から８のいずれか１項記載の方法。

【請求項10】

トランザクションに関する前記中央サーバからのメッセージを受信するステップ；
トランザクション公開鍵／秘密鍵ペアを生成し、前記トランザクション公開鍵を用いてトランザクションデータについて前記トランザクション業者に対して要求を送信するステップ；
前記トランザクションデータと前記トランザクション公開鍵とを含む署名されたデータエンベロープを受信および記憶するステップであって、前記データエンベロープは前記トランザクション業者の秘密鍵で署名されている、ステップ；
を有する、
請求項１から９のいずれか１項記載の方法。

【請求項11】

中央サーバ上の分散データ管理のためのコンピュータ実装方法であって、
ユーザデバイスに対してクエリを生成するステップ；
前記クエリを前記ユーザデバイスに対して送信するステップ；
署名されたデータエンベロープおよびＩＤを、前記クエリに応答して前記ユーザデバイスから受信するステップ；
前記ＩＤを少なくとも１つの検証者に対して提供するステップ；
前記署名されたデータエンベロープのデータが前記クエリの条件を満たすかどうかに基づいて、前記少なくとも１つの検証者から結果を受信するステップ；
を有する方法。

【請求項12】

前記署名されたデータエンベロープおよび前記ＩＤを前記少なくとも１つの検証者に対してプッシュし、または、前記署名されたデータエンベロープおよび前記ＩＤを前記少なくとも１つの検証者による収集のために利用可能にするステップを有する、請求項１１記載の方法。

【請求項13】

前記中央サーバは、複数の署名されたデータエンベロープおよび関連するＩＤを受信し、前記複数の署名されたデータエンベロープおよび関連するＩＤを複数の検証者に対して提供し、前記複数の検証者からの結果を組み合わせる、請求項１１または請求項１２記載の方法。

【請求項14】

検証者を用いた分散データ管理のためのコンピュータ実装方法であって、
ユーザデバイスのＩＤおよびクエリを中央サーバから受信するステップ；
前記ユーザデバイスのために検証公開鍵および前記ユーザデバイスのＩＤを提供するステップ；
前記ユーザデバイスの前記ＩＤに関連付けられたデータエンベロープを受信するステップであって、前記データエンベロープは前記検証公開鍵で暗号化される、ステップ；
前記データエンベロープ内のデータが前記クエリの少なくとも１つの条件を満たすかどうかを判定するステップ；
前記データエンベロープ内のデータが前記クエリの少なくとも１つの条件を満たすかどうかに基づいて結果を前記中央サーバに対して送信するステップ；
を有する方法。

【請求項15】

前記データエンベロープは、前記ユーザデバイスの公開鍵との間で鍵ペアを形成する秘密鍵を使用して署名される、請求項１４記載の方法。

【請求項16】

前記検証公開鍵および前記ユーザデバイスの前記ＩＤは、前記ユーザデバイスに対して送信されるか、または、前記ユーザデバイスが収集するために利用可能にされる、請求項１４または請求項１５記載の方法。

【請求項17】

前記中央サーバから前記ユーザデバイスのＩＤおよびクエリを受信するステップは、複数のＩＤを受信することと、処理のために１つを選択することとを含む、請求項１４から１６のいずれか１項記載の方法。

【請求項18】

前記検証者がユーザデバイスである、請求項１４から１７のいずれか１項記載の方法。

【請求項19】

コンピュータプログラムであって、前記プログラムがコンピュータによって実行されると、前記コンピュータに、請求項１から１８のいずれか１項記載の方法を実行させる命令を含む、コンピュータプログラム。

【請求項20】

コンピュータによって実行されると、前記コンピュータに請求項１から１８のいずれか１項記載の方法を実行させる命令を含む、コンピュータ可読媒体。

【請求項21】

請求項１から１８のいずれか１項記載の方法を実行するように構成されたプロセッサを備えるデータ処理装置。

【国際調査報告】