(57)【要約】  本発明は、分散型台帳をベースにしたシステムで、プライバシー規制への対応を可能にする。消費者識別子（消費者ＩＤ）を使用して、同意の履歴を共有された分散型台帳に保存することができる。また、同意ＩＤを使用して、消費者が、自分のデータがデータサプライチェーンを通じてどのように移動したかを照会できるようにする。消費者データ自体はブロックチェーンに保存されず、同意とデータ転送イベントのみが保存される。同意ＡＰＩを使用して、企業は元の消費者同意を同意台帳に入力できる。データ転送ＡＰＩを使用して、企業は相互転送を記録できる。購読ＡＰＩを使用して、特定の同意に対する変更を企業に通知できる。
2022500756.tif 000002
【特許請求の範囲】
【請求項１】
消費者の同意データを追跡するための分散型台帳システムであって、
ａ．複数の同意台帳であって、複数の同意台帳のそれぞれは、複数の同意台帳のうちの少なくとも１つの他の同意台帳と通信可能に接続されており、複数の同意台帳のそれぞれは、複数の消費者同意データを含み、複数の同意台帳のそれぞれは、消費者同意データの受信時に、消費者データを他の同意台帳のそれぞれにコピーするように構成されている、複数の同意台帳と、
ｂ．複数のデータ転送台帳であって、複数のデータ転送台帳のそれぞれが、複数の同意台帳のうちの少なくとも１つの他の台帳と通信可能に接続されており、複数のデータ転送台帳のそれぞれが、複数のデータ転送エントリを含み、複数のデータ転送台帳のそれぞれが、データ転送エントリの受信時に、データ転送エントリを他のデータ転送台帳のそれぞれにコピーするように構成されている、複数のデータ転送台帳と、
ｃ．複数の企業サーバであって、複数の企業サーバのそれぞれが、複数の同意台帳のうちの少なくとも１つと、複数のデータ転送台帳のうちの少なくとも１つと通信している、複数の企業サーバと、
を備える分散型台帳システム。
【請求項２】
請求項１に記載の分散型台帳システムであって、複数のピアノードをさらに備え、複数の同意台帳の１つと複数のデータ転送台帳の１つが、複数のピアノードのそれぞれに実装されていることを特徴とする分散型台帳システム。
【請求項３】
請求項２に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装された同意アプリケーションノードをさらに備え、前記同意アプリケーションノードは、元の消費者データを収集した複数の企業サーバのうちの１つから元の消費者同意メッセージを受信し、前記同意アプリケーションノードが通信している前記ピアノードのうちの当該１つ上の複数の同意台帳のうちの１つに消費者同意を書き込むように構成されていることを特徴とする分散型台帳システム。
【請求項４】
請求項３に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装されたデータ転送ノードをさらに備え、前記データ転送ノードは、前記複数の企業サーバのうちの別の１つから消費者データを受信した前記複数の企業サーバのうちの１つからデータ転送データを受信し、前記データ転送データを、前記データ転送ノードが通信している前記ピアノードのうちの当該１つ上の前記複数のデータ転送台帳のうちの１つに書き込むように構成されていることを特徴とする分散型台帳システム。
【請求項５】
請求項４に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つを備えた台帳サーバ上に実装された購読ノードをさらに備え、前記購読ノードは、前記複数の企業サーバのうちの少なくとも１つから購読要求を受信し、前記複数のピアノードのうちの１つにおける変更に応答して、前記複数の企業サーバのうちの購読している１つに消費者アウトデータ、消費者変更データ、またはその両方を送信するように構成されることを特徴とする分散型台帳システム。
【請求項６】
請求項５に記載の分散型台帳システムであって、前記複数の消費者同意データは、消費者のグループから特定の消費者に係るデータに一意に対応する同意識別子（同意ＩＤ）からなることを特徴とする分散型台帳システム。
【請求項７】
請求項６に記載の分散型台帳システムであって、前記複数の消費者同意データは、転送イベントからなることを特徴とする分散型台帳システム。
【請求項８】
請求項７に記載の分散型台帳システムであって、前記消費者同意データは、前記消費者同意データに関連する消費者に関する個人識別情報（ＰＩＩ）を含まないことを特徴とする分散型台帳システム。
【請求項９】
請求項８に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、前記購読ノード、またはそれらの任意の組み合わせが、アプリケーションプログラミングインターフェース（ＡＰＩ）として実装されていることを特徴とする分散型台帳システム。
【請求項１０】
請求項９に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信する企業内部の同意管理システムをさらに備えることを特徴とする分散型台帳システム。
【請求項１１】
請求項１０に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するプライバシーポータルをさらに備えることを特徴とする分散型台帳システム。
【請求項１２】
請求項１１に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するレギュレータサーバをさらに備えることを特徴とする分散型台帳システム。
【請求項１３】
複数のピアノードで構成される分散型台帳システムを介して消費者の同意を伝播する方法であって、
ａ．元のデータサーバで、消費者データの項目と消費者の同意を収集するステップと、
ｂ．前記複数のピアノードの１つで第１の同意アプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出して、前記消費者同意および消費者識別子（消費者ＩＤ）を前記ピアノードの同意台帳に入力するステップと、
ｃ．当該ピアノードの同意台帳の消費者同意と消費者ＩＤを、他のピアノードのそれぞれと同期させるステップと、
ｄ．消費者データを元のデータサーバから転送先のサーバに転送するステップと、
ｅ．ピアノードの１つで第１のデータ転送ＡＰＩを呼び出して、データ転送データを当該ピアノードのデータ転送台帳に入力するステップと、
ｆ．当該ピアノードの同意台帳のデータ転送データを、他の各ピアノードと同期させるステップと、を含む方法。
【請求項１４】
請求項１３の方法は、
ａ．前記消費者データを前記転送先サーバから前記広告サーバに転送するステップと、
ｂ．複数のピアノードの１つで第２のデータ転送ＡＰＩを呼び出して、データ転送データを当該ピアノードのデータ転送台帳に入力するステップと、
ｃ．当該ピアノードの同意台帳のデータ転送データを、他の各ピアノードと同期させるステップと、を含む方法。
【請求項１５】
請求項１４に記載の方法であって、前記複数のピアノードの１つで第３の同意ＡＰＩを呼び出して、当該ノードから消費者同意を取得するステップをさらに含むことを特徴とする消費者同意の伝播方法。
【請求項１６】
消費者がオプトアウトする方法であって、
ａ．元のデータサーバにおいて、当該消費者に関連する消費者データの使用に対するオプトアウトを要求する消費者メッセージを受信するステップと、
ｂ．複数のピアノードのうちの第１のピアノードで第１の同意アプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出して、第１のピアノードで同意台帳に消費者オプトアウトおよび消費者識別子（消費者ＩＤ）を入力するステップであって、第１のピアノードは、分散型ピアノードネットワークを形成する複数のピアノードのうちの１つである、ステップと、
ｃ．前記第１のピアノードの同意台帳にある消費者のオプトアウトを、他のピアノードのそれぞれと同期するステップと、
ｄ．第２の購読ＡＰＩを使用して、第２のピアノードの第２の同意台帳において、消費者がオプトアウトしたことを検出し、第２の購読ＡＰＩを介して、転送先サーバにオプトアウトメッセージを送信するステップであって、第１のピアノードおよび第２のピアノードは、同一のピアノードである、ステップと、
ｅ．第３のピアノードの第３の同意台帳で、第３の購読ＡＰＩを使用して、消費者がオプトアウトしたことを検出し、第３の購読ＡＰＩを介して広告サーバにオプトアウトメッセージを送信するステップであって、第１、第２、および第３のピアノードのいずれかまたはすべてが同じピアノードである、ステップと、
を含む方法。
【請求項１７】
請求項１６に記載の消費者のオプトアウト方法であって、第２または第３のノードがダウンしているために、第２または第３の購読ＡＰＩのいずれかがダウンしている場合、第４のピアノードで第４の購読ＡＰＩを介してオプトアウトメッセージを送信し、第４のピアノードは、第２または第３のピアノードがダウンしている場合のバックアップノードであることを特徴とする消費者のオプトアウト方法。
【請求項１８】
レギュレーター機能を実行する方法であって、
ａ．広告サーバーにおいて、レギュレータサーバーから監査要求を受信するステップと、
ｂ．第４のピアノードにおいて、レギュレータサーバから監査要求を受信し、広告サーバによって使用されるすべての消費者データが対応する有効な同意データを有することを検証するために、第４の同意アプリケーションプログラミングインターフェース（ＡＰＩ）に監査要求を送信するステップであって、第４のピアノードは、ピアノードネットワークを形成する複数のピアノードの１つである、ステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１８年９月１２日に出願された米国仮特許出願第６２／７３０，２７８号の利益を主張するものである。当該出願は、その全体が参照により本明細書に組み込まれる。
【背景技術】
【０００２】
現在、多くの企業（特にマーケティング・広告業界）は、外部ソースから消費者データを取得し、広告のパーソナライズなどの目的で消費者データを他の企業に渡している。このようなデータの多くは、消費者の明示的な同意の履歴や、データを収集した元の時点へのリンクが付いていない。さらに、このような情報は、データサプライチェーンを流れる間、通常、同意の履歴を含んでいない。このようなデータは、データの保存場所を特定する簡単な方法がないため、ＥＵの一般データ保護規則（ＧＤＰＲ：Ｇｅｎｅｒａｌ  Ｄａｔａ  Ｐｒｏｔｅｃｔｉｏｎ  Ｒｅｇｕｌａｔｉｏｎ）のような新しいプライバシー規制に準拠することが非常に困難である。
【０００３】
同意の保存方法は、企業によって異なる場合がある。これには２つの要素がある。１つ目は、特定の企業（そのオントロジー）がどのような同意データを保持しているか、２つ目はそのデータのレイアウト（フィールド名、フィールド定義、データタイプなど）である。同意は企業から企業へと受け渡されなければならないため、標準化されていないということは、すべての企業が他のすべての企業とカスタム統合を行わなければならないことを意味する。
【０００４】
同意を使用する際のもう一つの問題は、複雑なデータサプライチェーンにおいて、消費者が知らないうちに、あるチャネルを通じてベンダーに自分のデータの特定の用途について同意を与え、同じベンダーに同じデータの別の用途について同意を与える可能性がある。そのため、各企業は同意のソースを追跡し、矛盾点を探さなければならず、これは非常に手間とコストのかかる作業になる。
【０００５】
３つ目の問題は、企業が同意をどのように保存するか、また、どの同意に優先順位をつけるかについてのルールが、企業ごとに異なることである。そのため、データのサプライチェーン全体で消費者の同意を一貫して把握することはほとんど不可能である。
【０００６】
このような問題があるため、企業は現在、法的保護を利用して、データ供給者（サプライヤ）との契約書を書き換え、供給されるデータが消費者の同意を得たものであることを明記している。データ提供者は、自社のデータ提供者との契約を書き換え、これが消費者データのサプライチェーン全体に及んでいる。異なる業界、あるいは同一業界の異なる部分で、同意の取り扱いに関する矛盾した基準、プロトコル、プロセスが開発されている。
【０００７】
一方、ＧＤＰＲなどの規制では、消費者が企業に対してＳＡＲ（Ｓｕｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔ）を行使して、企業が保有する消費者に関するデータのコピーを入手できるだけでなく、消費者が「オプトアウト」（データを削除して使用しないこと）できるようにしなければならない。現在、企業は、オプトアウトを行った消費者のサプレッションリストを社内で作成することで、オプトアウトのサポートを行っている。消費者データの次の更新時に、その消費者のデータがまだ存在しているように、オプトアウトを元のデータソースに伝搬させる標準的な方法はない。一方、消費者は、それぞれの企業に「オプトアウト」を依頼しに行かなければならないだけでなく、どの企業が自分のデータを持っているのかを簡単に知る方法がないため、どこにオプトアウトの依頼を送ればよいのかわからないのが現状である。上記の問題を解決するために、従来の中央集権的な同意のクリアリングハウス（清算機関）を作るためのインセンティブシステムはない。
【０００８】
背景技術で言及されている文献は、本発明に関する先行技術であるとは認識されていない。
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明は、企業がＧＤＰＲなどのプライバシー規制を遵守し、いつでも、どの目的で、どの環境で、どの消費者の同意が最も正しいのか、単一の一貫した真実の情報源を得ることを可能にする分散型のシステムおよび方法に関するものである。消費者データを保有・利用する企業は、そのデータが他社から提供されたものであっても、最新の消費者からの明示的な同意を得ていることを保証することができる。データの同意には、一意のユニバーサルな同意識別子（同意ＩＤ）が生成される。同意ＩＤはデータと一緒に渡すことができるため、データを受信したサプライチェーン上の誰もが元の同意履歴を参照することができる。これにより、データの履歴が共有された分散型台帳に保存され、データの履歴を簡単に照会できるようになる。また、同意ＩＤは、消費者が、自分のデータがデータサプライチェーンの中でどのように移動したかを照会できるようにする。個人を特定できる情報（ＰＩＩ：Ｐｅｒｓｏｎａｌｌｙ  Ｉｄｅｎｔｉｆｉａｂｌｅ  Ｉｎｆｏｒｍａｔｉｏｎ）を含む消費者のデータ自体はブロックチェーンに保存されず、同意とデータ転送イベントのみが保存されるが、同意ＩＤにより、データを対応するデータ履歴情報とリンクさせることができる。
【００１０】
特定の実装では、オープンソースの分散型台帳技術であるＨｙｐｅｒｌｅｄｇｅｒ  Ｆａｂｒｉｃ（ハイパーレジャーファブリック）上に、ＪａｖａでコーディングされたＡＰＩの定義された仕様と、ｎｏｄｅ．ｊｓを使用したクライアントアプリケーションで構成されている。これらの実装におけるＡＰＩは、主に３つのセクションで構成されている。
１．同意ＡＰＩ：同意ＡＰＩは、元の消費者データを収集した企業が、元の消費者の同意を同意台帳に入力できるようにするものである。同意台帳は、Ｈｙｐｅｒｌｅｄｇｅｒの不変的な分散型データストア内に実装される。実際の消費者データは書き込まれず、消費者がどのようなデータや利用に同意したかを記述したメタデータのみが書き込まれる。このＡＰＩでは、企業は同意ＩＤに基づいて同意を検索することもできる。
２．データ転送ＡＰＩ：消費者データがある企業から別の企業に転送されるたびに、データ転送ＡＰＩにより、企業はデータ転送台帳（Ｈｙｐｅｒｌｅｄｇｅｒの不変的分散データストア内にも実装されている）にデータ転送エントリを書き込むことができる。このデータ転送エントリには、関連する同意ＩＤが含まれている。このようにして、消費者データがどこに伝播しても、消費者データのサプライチェーンに沿った企業は、元の同意に直接リンクすることになる。
３．購読ＡＰＩ：購読ＡＰＩにより、企業は与えられた同意に変更があった場合に通知を受信することができる。したがって、ユーザーが同意を解除したり、元の同意を変更したりすると、通知を購読しているすべての企業に通知される。
本発明の主要な構成要素は、特定の実装においては、上述の３つのＡＰＩ、分散型台帳データストア、企業固有の内部同意管理システム、プライバシーポータル、および監査ポータルである。
【００１１】
他のブロックチェーンシステムと同様に、このシステムの価値は、ネットワーク効果現象の特性に従う。システムに参加する企業が多ければ多いほど（つまり、同意やデータ転送を台帳に記録する企業が多ければ多いほど）、システムの価値は高くなる。システムが分散型であることから、参加者が分散型ノードの運営コストを分担し、同意やデータ転送をシステムに記録することを約束するコンソーシアム方式が必要となる。
【００１２】
本発明を使用すると、ＧＤＰＲなどのプライバシー規制への対応が大幅に容易になるため、消費者データやその他のデータの供給者にもメリットがある。また、広告主やマーケティング担当者にとっても、マーケティングキャンペーンの一環として提供されるデータの履歴を検証することができるというメリットがある。最後に、本発明は、消費者が自分の個人データへのアクセスや使用をより簡単に監視・制御できるようになるため、消費者にもメリットがある。
【００１３】
本発明のこれらおよびその他の特徴、目的、および利点は、以下の好ましい実施形態の詳細な説明および添付の特許請求の範囲を、以下に記載する図面と併せて検討することにより、よりよく理解されるであろう。
【図面の簡単な説明】
【００１４】
【図１】図１は、本発明の特定の実装のための全体的なシステムアーキテクチャを示す図である。
【図２】図２は、本発明の特定の実装において、同意を伝播する方法を示すデータフロー図である。
【図３】図３は、本発明のある実施形態における同意の取り消し（オプトアウト）の方法を示すデータフロー図である。
【図４】図４は、本発明のある実施形態における同意を検証する方法を示すデータフロー図である。
【発明を実施するための形態】
【００１５】
本発明の一実施態様によるシステムの全体的なアーキテクチャを図１に示す。図１のサンプルアーキテクチャは、Ｈｙｐｅｒｌｅｄｇｅｒの分散型台帳システムのピアノード１６、１８、２０、２２、２４（この場合は５つであるが、任意の数を使用することができる）を示しており、すべてがＣｏｕｃｈＤＢデータベース２６に実装されているファブリック世界の状態に接続されている。各ピアノード上で動作するＲｅｓｔ  ＡＰＩは、コンセント（同意）、データ転送、サブスクリプション（購読）の各ＡＰＩを実装している。クライアントアプリケーション１０、１２、１４（例えば、内部同意管理システム、プライバシーポータル、レギュレータポータル）は、希望するピアノード上のＡＰＩサービスを呼び出すが、任意のピアノードでも同じ機能を提供し、代替的に使用することができる。このサンプルの実装アーキテクチャでは、クライアントアプリケーション１０、１２、１４はｎｏｄｅ．ｊｓで記述されているが、ピアノード１６、１８、２０、２２、２４のＲｅｓｔ  ＡＰＩを呼び出すことができる任意の技術を使用して実装することができる。より堅牢（ロバスト）な実装では、クライアントアプリケーションとＲｅｓｔ  ＡＰＩサービス（図示せず）の間にＡＰＩゲートウェイやルーティングサービスが存在することになるが、それらはシステムが機能するために必要ではない。
【００１６】
ここで、図２を参照して、同意がシステムを介して伝播される方法を、一例に従って説明することができる。なお、各ピアはＡＰＩサービスを有しているので、ピアノードがブロックチェーン台帳方式で相互に同期するため、任意のピアを呼び出すことができる。ステップ２８で、Ａ社のシステムは、該当する消費者から同意を収集し、消費者データを収集する。Ａ社のウェブサイトは、ピアノード１６の同意ＡＰＩを呼び出して、同意台帳に新しい同意を入力する。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期し、すべてのノードが新しい同意を得るようにする。
【００１７】
ステップ３０で、Ａ社はＢ社にデータを販売・転送する。Ａ社のシステムは、ピアノード１６のデータ転送ＡＰＩを呼び出して、データ転送台帳にデータ転送情報を入力する。ユーザーの同意ＩＤは、データ転送入力の一部である。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するので、すべてのノードが新しいデータ転送エントリを得ることになる。
【００１８】
ステップ３２で、Ｂ社はＣ社に広告キャンペーン用のデータを送信する。Ｂ社のシステムは、ピアノード１６のデータ転送ＡＰＩを呼び出して、データ転送台帳にデータ転送情報を入力する。同意ＩＤは、この新しいデータ転送エントリに一緒に渡される。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するため、すべてのノードが新しいデータ転送エントリを得ることになる。データを受信した後、Ｃ社はマーケティング目的でデータを使用することに消費者の明示的な同意があるかどうかを検証する。検証するために、Ｃ社のシステムはピアノード２０の同意ＡＰＩを呼び出して、同意の詳細を検索し、同意がマーケティング目的を許可していることを検証する。ピアノードのそれぞれがこの同じ機能を実行することができ、したがって、ピアノードに対して先ほど説明した呼び出しは、任意のピアノードに関して実行することができることに再度留意することができる。
【００１９】
ここで、図３を参照して、消費者が本システムを使用してオプトアウトする方法を説明することができる。処理は、消費者３４が企業に連絡し、オプトアウトを要求することから始まる。ステップ３６で、ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するので、すべてのノードが同意を取り消したことになる。
【００２０】
ステップ３８で、ピアノード１８上の購読ＡＰＩは、同意が取り消されたことを検出し、以前にＢ社のシステムがその同意のために通知を購読していたので、Ｂ社のシステムに通知を送信する。
【００２１】
ステップ４０で、ピアノード２０上の購読ＡＰＩは、同意が取り消されたことを検出し、以前にＣ社のシステムがその同意に対する通知を購読していたため、Ｃ社のシステムに通知を送信する。標準的な冗長性プロトコルを使用して、購読ＡＰＩはプライマリおよびセカンダリのピアノードがあり、１つのノードがダウンしても通知が送信されないことがないようにするが、これらの機能を実行する特定のノードが変わる可能性があることに留意してもよい。
【００２２】
ここで、図４を参照して、システムが適合性をチェックすることによってレギュレータ機能を実行する方法を、特定の例を参照して説明することができる。Ｃ社がレギュレータ（規制者）によって監査されたとする。ステップ４２で、Ｃ社のシステムは、要求されたデータを関連する同意ＩＤとともにレギュレータに送信する。レギュレータは、ピアノード２２の同意ＡＰＩを呼び出して、すべてのデータに有効な同意があることを検証する。その後、ピアノード２２は、要求された検証データをレギュレータに返す。
【００２３】
別段の記載がない限り、本明細書で使用されているすべての技術用語および科学用語は、本発明が属する技術分野の通常の技術者が一般的に理解しているものと同じ意味を持つ。本明細書に記載されているものと同様または同等の任意の方法および材料も、本発明の実施または試験に使用することができるが、本明細書では例示的な方法および材料を限定的に記載している。
【００２４】
本明細書で使用されているすべての用語は、文脈と一致する可能な限り広範な方法で解釈されるべきである。本明細書でグループ化が使用される場合、グループのすべての個々のメンバー、ならびにグループの可能なすべての組み合わせおよびサブコンビネーションが、本開示に個別に含まれることが意図される。本明細書で引用されたすべての文献は、本明細書の開示と矛盾しない範囲で、参照により本明細書に組み込まれる。本明細書で範囲が表現されている場合、その範囲は、その範囲内のすべての副範囲およびその範囲内のすべての特定の点を包含し、開示することが意図されている。
【図１】
2022500756.tif 000003
【図２】
2022500756.tif 000004
【図３】
2022500756.tif 000005
【図４】
2022500756.tif 000006
【手続補正書】
【提出日】令和2年4月12日(2020.4.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
消費者同意データを追跡するための分散型台帳システムであって、
ａ．複数の同意台帳であって、前記複数の同意台帳のそれぞれは、前記複数の同意台帳のうちの少なくとも１つの他の同意台帳と通信可能に接続されており、前記複数の同意台帳のそれぞれは、前記複数の消費者同意データを含み、前記複数の消費者同意データは、消費者が当該消費者に関する個人データの使用に同意したかどうかを示すデータを含み、前記複数の同意台帳のそれぞれは、前記消費者同意データの受信時に、前記消費者同意データを前記複数の同意台帳のうちの他の同意台帳のそれぞれにコピーするように構成されている、前記複数の同意台帳と、
ｂ．複数のデータ転送台帳であって、前記複数のデータ転送台帳のそれぞれが、前記複数の同意台帳のうちの少なくとも１つの他の同意台帳と通信可能に接続されており、前記複数のデータ転送台帳のそれぞれが、複数のデータ転送エントリを含み、前記複数のデータ転送台帳のそれぞれが、前記複数のデータ転送エントリの受信時に、前記複数のデータ転送エントリを複数の同意台帳のうちの他のデータ転送台帳のそれぞれにコピーするように構成されている、前記複数のデータ転送台帳と、
ｃ．複数の企業サーバであって、前記複数の企業サーバのそれぞれが、前記複数の同意台帳のうちの少なくとも１つと、前記複数のデータ転送台帳のうちの少なくとも１つと通信している、複数の企業サーバと、
を備える分散型台帳システム。
【請求項２】
請求項１に記載の分散型台帳システムであって、複数のピアノードをさらに備え、前記複数の同意台帳の１つと前記複数のデータ転送台帳の１つが、前記複数のピアノードのそれぞれに実装されていることを特徴とする分散型台帳システム。
【請求項３】
請求項２に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装された同意アプリケーションノードをさらに備え、前記同意アプリケーションノードは、元の消費者データを収集した前記複数の企業サーバのうちの１つから元の消費者同意メッセージを受信し、前記同意アプリケーションノードが通信している前記複数のピアノードのうちの該当する１つのピアノードの複数の同意台帳のうちの１つに前記複数の消費者同意データを書き込むように構成されていることを特徴とする分散型台帳システム。
【請求項４】
請求項３に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装されたデータ転送ノードをさらに備え、前記データ転送ノードは、前記複数の企業サーバのうちの別の１つから消費者データを受信した前記複数の企業サーバのうちの１つからデータ転送データを受信し、前記データ転送データを、前記データ転送ノードが通信している前記ピアノードのうちの当該１つ上の前記複数のデータ転送台帳のうちの１つに書き込むように構成されていることを特徴とする分散型台帳システム。
【請求項５】
請求項４に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つを備えた台帳サーバ上に実装された購読ノードをさらに備え、前記購読ノードは、前記複数の企業サーバのうちの少なくとも１つから購読要求を受信し、前記複数のピアノードのうちの１つにおける変更に応答して、前記複数の企業サーバのうちの購読している１つに消費者アウトデータ、消費者変更データ、またはその両方を送信するように構成されることを特徴とする分散型台帳システム。
【請求項６】
請求項５に記載の分散型台帳システムであって、前記複数の消費者同意データは、消費者のグループから特定の消費者に係るデータに一意に対応する同意識別子（同意ＩＤ）からなることを特徴とする分散型台帳システム。
【請求項７】
請求項６に記載の分散型台帳システムであって、前記複数の消費者同意データは、転送イベントからなることを特徴とする分散型台帳システム。
【請求項８】
請求項７に記載の分散型台帳システムであって、前記消費者同意データは、前記消費者同意データに関連する消費者に関する個人識別情報（ＰＩＩ）を含まないことを特徴とする分散型台帳システム。
【請求項９】
請求項８に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、前記購読ノード、またはそれらの任意の組み合わせが、アプリケーションプログラミングインターフェース（ＡＰＩ）として実装されていることを特徴とする分散型台帳システム。
【請求項１０】
請求項９に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信する企業内部の同意管理システムをさらに備えることを特徴とする分散型台帳システム。
【請求項１１】
請求項１０に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するプライバシーポータルをさらに備えることを特徴とする分散型台帳システム。
【請求項１２】
請求項１１に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するレギュレータサーバをさらに備えることを特徴とする分散型台帳システム。
【請求項１３】
複数のピアノードで構成される分散型台帳システムを介して消費者の同意を伝播する方法であって、
ａ．元のデータサーバで、消費者データの項目と消費者の同意を収集するステップであって、前記消費者の同意は、当該消費者が当該消費者に関する個人データの使用に同意したかどうかを示すデータを含む、ステップと、
ｂ．前記複数のピアノードの１つで第１の同意アプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出して、前記消費者の同意および消費者識別子（消費者ＩＤ）を前記ピアノードの同意台帳に入力するステップと、
ｃ．当該ピアノードの同意台帳の前記消費者の同意と消費者ＩＤを、他のピアノードのそれぞれと同期させるステップと、
ｄ．消費者データを元のデータサーバから転送先のサーバに転送するステップと、
ｅ．ピアノードの１つで第１のデータ転送ＡＰＩを呼び出して、データ転送データを当該ピアノードのデータ転送台帳に入力するステップと、
ｆ．当該ピアノードの同意台帳のデータ転送データを、他の各ピアノードと同期させるステップと、を含む方法。
【請求項１４】
請求項１３の方法は、
ａ．前記消費者データを前記転送先サーバから前記広告サーバに転送するステップと、
ｂ．複数のピアノードの１つで第２のデータ転送ＡＰＩを呼び出して、データ転送データを当該ピアノードのデータ転送台帳に入力するステップと、
ｃ．当該ピアノードの同意台帳のデータ転送データを、他の各ピアノードと同期させるステップと、を含む方法。
【請求項１５】
請求項１４に記載の方法であって、前記複数のピアノードの１つで第３の同意ＡＰＩを呼び出して、当該ノードから前記消費者の同意を取得するステップをさらに含むことを特徴とする方法。
【請求項１６】
消費者がオプトアウトする方法であって、
ａ．元のデータサーバにおいて、当該消費者に関連する消費者データの使用に対するオプトアウトを要求する消費者メッセージを受信するステップと、
ｂ．複数のピアノードのうちの第１のピアノードで第１の同意アプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出して、第１のピアノードで同意台帳にオプトアウトおよび消費者識別子（消費者ＩＤ）を入力するステップであって、第１のピアノードは、分散型ピアノードネットワークを形成する複数のピアノードのうちの１つである、ステップと、
ｃ．前記第１のピアノードの同意台帳にあるオプトアウトを、他のピアノードのそれぞれと同期するステップと、
ｄ．第２の購読ＡＰＩを使用して、第２のピアノードの第２の同意台帳において、消費者がオプトアウトしたことを検出し、第２の購読ＡＰＩを介して、転送先サーバにオプトアウトメッセージを送信するステップであって、第１のピアノードおよび第２のピアノードは、同一のピアノードである、ステップと、
ｅ．第３のピアノードの第３の同意台帳で、第３の購読ＡＰＩを使用して、消費者がオプトアウトしたことを検出し、第３の購読ＡＰＩを介して広告サーバにオプトアウトメッセージを送信するステップであって、第１、第２、および第３のピアノードのいずれかまたはすべてが同じピアノードである、ステップと、
を含む方法。
【請求項１７】
請求項１６に記載の消費者のオプトアウト方法であって、第２または第３のノードがダウンしているために、第２または第３の購読ＡＰＩのいずれかがダウンしている場合、第４のピアノードで第４の購読ＡＰＩを介してオプトアウトメッセージを送信し、第４のピアノードは、第２または第３のピアノードがダウンしている場合のバックアップノードであることを特徴とする消費者のオプトアウト方法。
【請求項１８】
請求項１７に記載の消費者がオプトアウトするための方法であって、さらに、
ａ．広告サーバーにおいて、レギュレータサーバーから監査要求を受信するステップと、
ｂ．第５のピアノードにおいて、レギュレータサーバから監査要求を受信し、広告サーバによって使用されるすべての消費者データが対応する有効な同意データを有することを検証するために、第５の同意アプリケーションプログラミングインターフェース（ＡＰＩ）に監査要求を送信するステップであって、第５のピアノードは、ピアノードネットワークを形成する複数のピアノードの１つである、ステップと、
を含む方法。
【国際調査報告】
2022500756.tif 000007
2022500756.tif 000008
2022500756.tif 000009