特許 7554181 ブロックチェーン分散型台帳を使用した複雑な消費者データのサプライチェーンの同意の履歴と適合性の追跡

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

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

(11)【特許番号】

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

(45)【発行日】2024-09-19

(54)【発明の名称】ブロックチェーン分散型台帳を使用した複雑な消費者データのサプライチェーンの同意の履歴と適合性の追跡

(51)【国際特許分類】

   G06Q 30/015 20230101AFI20240911BHJP

【ＦＩ】

G06Q30/015

【請求項の数】 12

(21)【出願番号】P 2021513815

(86)(22)【出願日】2019-09-10

(65)【公表番号】

(43)【公表日】2022-01-04

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

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

(87)【国際公開日】2020-03-19

【審査請求日】2022-07-07

(31)【優先権主張番号】62/730,278

(32)【優先日】2018-09-12

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

(73)【特許権者】

【識別番号】519161872

【氏名又は名称】ライブランプ インコーポレーテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】弁理士法人浅村特許事務所

(72)【発明者】

【氏名】ハーシー、ジョー

(72)【発明者】

【氏名】レオン、ズー リン クリスティーナ

(72)【発明者】

【氏名】ルバロン、マット

(72)【発明者】

【氏名】コールマン、アーサー

【審査官】毛利 太郎

(56)【参考文献】

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

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

【文献】特開２０１６－０９１０６７（ＪＰ，Ａ）

【文献】特開２００７－２１３３７３（ＪＰ，Ａ）

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

【文献】米国特許第０９６３５０００（ＵＳ，Ｂ１）

【文献】特表２０１８－５３７０２２（ＪＰ，Ａ）

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

【文献】特開２００４－１０２８７２（ＪＰ，Ａ）

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

Ｇ０６Ｑ １０／００ － ９９／００

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

【請求項1】

消費者同意データを追跡するための分散型台帳システムであって、
ａ．複数の同意台帳であって、複数の同意台帳のそれぞれは、複数の同意台帳のうちの少なくとも１つの他の同意台帳と通信可能に接続されており、複数の同意台帳のそれぞれは、複数の消費者同意データを含み、複数の同意台帳のそれぞれは、前記消費者同意データの受信時に、消費者データを他の同意台帳のそれぞれにコピーするように構成されている、複数の同意台帳と、
ｂ．複数のデータ転送台帳であって、複数のデータ転送台帳のそれぞれが、複数の同意台帳のうちの少なくとも１つの他の台帳と通信可能に接続されており、複数のデータ転送台帳のそれぞれが、複数のデータ転送エントリを含み、複数のデータ転送台帳のそれぞれが、データ転送エントリの受信時に、データ転送エントリを他のデータ転送台帳のそれぞれにコピーするように構成されている、複数のデータ転送台帳と、
ｃ．複数の企業サーバであって、複数の企業サーバのそれぞれが、複数の同意台帳のうちの少なくとも１つと、複数のデータ転送台帳のうちの少なくとも１つと通信している、複数の企業サーバと、
を備える分散型台帳システム。

【請求項2】

請求項１に記載の分散型台帳システムであって、複数のピアノードをさらに備え、複数の同意台帳の１つと複数のデータ転送台帳の１つが、複数のピアノードのそれぞれに実装されていることを特徴とする分散型台帳システム。

【請求項3】

請求項２に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装された同意アプリケーションノードをさらに備え、前記同意アプリケーションノードは、元の消費者データを収集した複数の企業サーバのうちの１つから元の消費者同意メッセージを受信し、前記同意アプリケーションノードが通信している前記ピアノードのうちの当該１つ上の複数の同意台帳のうちの１つに消費者同意を書き込むように構成されていることを特徴とする分散型台帳システム。

【請求項4】

請求項３に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つの台帳サーバ上に実装されたデータ転送ノードをさらに備え、前記データ転送ノードは、前記複数の企業サーバのうちの別の１つから消費者データを受信した前記複数の企業サーバのうちの１つからデータ転送データを受信し、前記データ転送データを、前記データ転送ノードが通信している前記ピアノードのうちの当該１つ上の前記複数のデータ転送台帳のうちの１つに書き込むように構成されていることを特徴とする分散型台帳システム。

【請求項5】

請求項４に記載の分散型台帳システムであって、前記複数のピアノードのうちの少なくとも１つを備えた台帳サーバ上に実装された購読ノードをさらに備え、前記購読ノードは、前記複数の企業サーバのうちの少なくとも１つから購読要求を受信し、前記複数のピアノードのうちの１つにおける変更に応答して、前記複数の企業サーバのうちの購読している１つに消費者アウトデータ、消費者変更データ、またはその両方を送信するように構成されることを特徴とする分散型台帳システム。

【請求項6】

請求項５に記載の分散型台帳システムであって、前記複数の消費者同意データは、消費者のグループから特定の消費者に係るデータに一意に対応する同意識別子（同意ＩＤ）からなることを特徴とする分散型台帳システム。

【請求項7】

請求項６に記載の分散型台帳システムであって、前記複数の消費者同意データは、転送イベントからなることを特徴とする分散型台帳システム。

【請求項8】

請求項７に記載の分散型台帳システムであって、前記消費者同意データは、前記消費者同意データに関連する消費者に関する個人識別情報（ＰＩＩ）を含まないことを特徴とする分散型台帳システム。

【請求項9】

請求項８に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、前記購読ノード、またはそれらの任意の組み合わせが、アプリケーションプログラミングインターフェース（ＡＰＩ）として実装されていることを特徴とする分散型台帳システム。

【請求項10】

請求項９に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信する企業内部の同意管理システムをさらに備えることを特徴とする分散型台帳システム。

【請求項11】

請求項１０に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するプライバシーポータルをさらに備えることを特徴とする分散型台帳システム。

【請求項12】

請求項１１に記載の分散型台帳システムであって、前記同意アプリケーションノード、前記データ転送ノード、および前記購読ノードのうちの１つ以上と通信するレギュレータサーバをさらに備えることを特徴とする分散型台帳システム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１８年９月１２日に出願された米国仮特許出願第６２／７３０，２７８号の利益を主張するものである。当該出願は、その全体が参照により本明細書に組み込まれる。

【背景技術】

【0002】

現在、多くの企業（特にマーケティング・広告業界）は、外部ソースから消費者データを取得し、広告のパーソナライズなどの目的で消費者データを他の企業に渡している。このようなデータの多くは、消費者の明示的な同意の履歴や、データを収集した元の時点へのリンクが付いていない。さらに、このような情報は、データサプライチェーンを流れる間、通常、同意の履歴を含んでいない。このようなデータは、データの保存場所を特定する簡単な方法がないため、ＥＵの一般データ保護規則（ＧＤＰＲ：Ｇｅｎｅｒａｌ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ Ｒｅｇｕｌａｔｉｏｎ）のような新しいプライバシー規制に準拠することが非常に困難である。

【0003】

同意の保存方法は、企業によって異なる場合がある。これには２つの要素がある。１つ目は、特定の企業（そのオントロジー）がどのような同意データを保持しているか、２つ目はそのデータのレイアウト（フィールド名、フィールド定義、データタイプなど）である。同意は企業から企業へと受け渡されなければならないため、標準化されていないということは、すべての企業が他のすべての企業とカスタム統合を行わなければならないことを意味する。

【0004】

同意を使用する際のもう一つの問題は、複雑なデータサプライチェーンにおいて、消費者が知らないうちに、あるチャネルを通じてベンダーに自分のデータの特定の用途について同意を与え、同じベンダーに同じデータの別の用途について同意を与える可能性がある。そのため、各企業は同意のソースを追跡し、矛盾点を探さなければならず、これは非常に手間とコストのかかる作業になる。

【0005】

３つ目の問題は、企業が同意をどのように保存するか、また、どの同意に優先順位をつけるかについてのルールが、企業ごとに異なることである。そのため、データのサプライチェーン全体で消費者の同意を一貫して把握することはほとんど不可能である。

【0006】

このような問題があるため、企業は現在、法的保護を利用して、データ供給者（サプライヤ）との契約書を書き換え、供給されるデータが消費者の同意を得たものであることを明記している。データ提供者は、自社のデータ提供者との契約を書き換え、これが消費者データのサプライチェーン全体に及んでいる。異なる業界、あるいは同一業界の異なる部分で、同意の取り扱いに関する矛盾した基準、プロトコル、プロセスが開発されている。

【0007】

一方、ＧＤＰＲなどの規制では、消費者が企業に対してＳＡＲ（Ｓｕｂｊｅｃｔ Ａｃｃｅｓｓ Ｒｅｑｕｅｓｔ）を行使して、企業が保有する消費者に関するデータのコピーを入手できるだけでなく、消費者が「オプトアウト」（データを削除して使用しないこと）できるようにしなければならない。現在、企業は、オプトアウトを行った消費者のサプレッションリストを社内で作成することで、オプトアウトのサポートを行っている。消費者データの次の更新時に、その消費者のデータがまだ存在しているように、オプトアウトを元のデータソースに伝搬させる標準的な方法はない。一方、消費者は、それぞれの企業に「オプトアウト」を依頼しに行かなければならないだけでなく、どの企業が自分のデータを持っているのかを簡単に知る方法がないため、どこにオプトアウトの依頼を送ればよいのかわからないのが現状である。上記の問題を解決するために、従来の中央集権的な同意のクリアリングハウス（清算機関）を作るためのインセンティブシステムはない。

【0008】

背景技術で言及されている文献は、本発明に関する先行技術であるとは認識されていない。

【発明の概要】

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

【0009】

本発明は、企業がＧＤＰＲなどのプライバシー規制を遵守し、いつでも、どの目的で、どの環境で、どの消費者の同意が最も正しいのか、単一の一貫した真実の情報源を得ることを可能にする分散型のシステムおよび方法に関するものである。消費者データを保有・利用する企業は、そのデータが他社から提供されたものであっても、最新の消費者からの明示的な同意を得ていることを保証することができる。データの同意には、一意のユニバーサルな同意識別子（同意ＩＤ）が生成される。同意ＩＤはデータと一緒に渡すことができるため、データを受信したサプライチェーン上の誰もが元の同意履歴を参照することができる。これにより、データの履歴が共有された分散型台帳に保存され、データの履歴を簡単に照会できるようになる。また、同意ＩＤは、消費者が、自分のデータがデータサプライチェーンの中でどのように移動したかを照会できるようにする。個人を特定できる情報（ＰＩＩ：Ｐｅｒｓｏｎａｌｌｙ Ｉｄｅｎｔｉｆｉａｂｌｅ Ｉｎｆｏｒｍａｔｉｏｎ）を含む消費者のデータ自体はブロックチェーンに保存されず、同意とデータ転送イベントのみが保存されるが、同意ＩＤにより、データを対応するデータ履歴情報とリンクさせることができる。

【0010】

特定の実装では、オープンソースの分散型台帳技術であるＨｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ（ハイパーレジャーファブリック）上に、ＪａｖａでコーディングされたＡＰＩの定義された仕様と、ｎｏｄｅ．ｊｓを使用したクライアントアプリケーションで構成されている。これらの実装におけるＡＰＩは、主に３つのセクションで構成されている。
１．同意ＡＰＩ：同意ＡＰＩは、元の消費者データを収集した企業が、元の消費者の同意を同意台帳に入力できるようにするものである。同意台帳は、Ｈｙｐｅｒｌｅｄｇｅｒの不変的な分散型データストア内に実装される。実際の消費者データは書き込まれず、消費者がどのようなデータや利用に同意したかを記述したメタデータのみが書き込まれる。このＡＰＩでは、企業は同意ＩＤに基づいて同意を検索することもできる。
２．データ転送ＡＰＩ：消費者データがある企業から別の企業に転送されるたびに、データ転送ＡＰＩにより、企業はデータ転送台帳（Ｈｙｐｅｒｌｅｄｇｅｒの不変的分散データストア内にも実装されている）にデータ転送エントリを書き込むことができる。このデータ転送エントリには、関連する同意ＩＤが含まれている。このようにして、消費者データがどこに伝播しても、消費者データのサプライチェーンに沿った企業は、元の同意に直接リンクすることになる。
３．購読ＡＰＩ：購読ＡＰＩにより、企業は与えられた同意に変更があった場合に通知を受信することができる。したがって、ユーザーが同意を解除したり、元の同意を変更したりすると、通知を購読しているすべての企業に通知される。
本発明の主要な構成要素は、特定の実装においては、上述の３つのＡＰＩ、分散型台帳データストア、企業固有の内部同意管理システム、プライバシーポータル、および監査ポータルである。

【0011】

他のブロックチェーンシステムと同様に、このシステムの価値は、ネットワーク効果現象の特性に従う。システムに参加する企業が多ければ多いほど（つまり、同意やデータ転送を台帳に記録する企業が多ければ多いほど）、システムの価値は高くなる。システムが分散型であることから、参加者が分散型ノードの運営コストを分担し、同意やデータ転送をシステムに記録することを約束するコンソーシアム方式が必要となる。

【0012】

本発明を使用すると、ＧＤＰＲなどのプライバシー規制への対応が大幅に容易になるため、消費者データやその他のデータの供給者にもメリットがある。また、広告主やマーケティング担当者にとっても、マーケティングキャンペーンの一環として提供されるデータの履歴を検証することができるというメリットがある。最後に、本発明は、消費者が自分の個人データへのアクセスや使用をより簡単に監視・制御できるようになるため、消費者にもメリットがある。

【0013】

本発明のこれらおよびその他の特徴、目的、および利点は、以下の好ましい実施形態の詳細な説明および添付の特許請求の範囲を、以下に記載する図面と併せて検討することにより、よりよく理解されるであろう。

【図面の簡単な説明】

【0014】

【図1】図１は、本発明の特定の実装のための全体的なシステムアーキテクチャを示す図である。

【図2】図２は、本発明の特定の実装において、同意を伝播する方法を示すデータフロー図である。

【図3】図３は、本発明のある実施形態における同意の取り消し（オプトアウト）の方法を示すデータフロー図である。

【図4】図４は、本発明のある実施形態における同意を検証する方法を示すデータフロー図である。

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

【0015】

本発明の一実施態様によるシステムの全体的なアーキテクチャを図１に示す。図１のサンプルアーキテクチャは、Ｈｙｐｅｒｌｅｄｇｅｒの分散型台帳システムのピアノード１６、１８、２０、２２、２４（この場合は５つであるが、任意の数を使用することができる）を示しており、すべてがＣｏｕｃｈＤＢデータベース２６に実装されているファブリック世界の状態に接続されている。各ピアノード上で動作するＲｅｓｔ ＡＰＩは、コンセント（同意）、データ転送、サブスクリプション（購読）の各ＡＰＩを実装している。クライアントアプリケーション１０、１２、１４（例えば、内部同意管理システム、プライバシーポータル、レギュレータポータル）は、希望するピアノード上のＡＰＩサービスを呼び出すが、任意のピアノードでも同じ機能を提供し、代替的に使用することができる。このサンプルの実装アーキテクチャでは、クライアントアプリケーション１０、１２、１４はｎｏｄｅ．ｊｓで記述されているが、ピアノード１６、１８、２０、２２、２４のＲｅｓｔ ＡＰＩを呼び出すことができる任意の技術を使用して実装することができる。より堅牢（ロバスト）な実装では、クライアントアプリケーションとＲｅｓｔ ＡＰＩサービス（図示せず）の間にＡＰＩゲートウェイやルーティングサービスが存在することになるが、それらはシステムが機能するために必要ではない。

【0016】

ここで、図２を参照して、同意がシステムを介して伝播される方法を、一例に従って説明することができる。なお、各ピアはＡＰＩサービスを有しているので、ピアノードがブロックチェーン台帳方式で相互に同期するため、任意のピアを呼び出すことができる。ステップ２８で、Ａ社のシステムは、該当する消費者から同意を収集し、消費者データを収集する。Ａ社のウェブサイトは、ピアノード１６の同意ＡＰＩを呼び出して、同意台帳に新しい同意を入力する。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期し、すべてのノードが新しい同意を得るようにする。

【0017】

ステップ３０で、Ａ社はＢ社にデータを販売・転送する。Ａ社のシステムは、ピアノード１６のデータ転送ＡＰＩを呼び出して、データ転送台帳にデータ転送情報を入力する。ユーザーの同意ＩＤは、データ転送入力の一部である。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するので、すべてのノードが新しいデータ転送エントリを得ることになる。

【0018】

ステップ３２で、Ｂ社はＣ社に広告キャンペーン用のデータを送信する。Ｂ社のシステムは、ピアノード１６のデータ転送ＡＰＩを呼び出して、データ転送台帳にデータ転送情報を入力する。同意ＩＤは、この新しいデータ転送エントリに一緒に渡される。ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するため、すべてのノードが新しいデータ転送エントリを得ることになる。データを受信した後、Ｃ社はマーケティング目的でデータを使用することに消費者の明示的な同意があるかどうかを検証する。検証するために、Ｃ社のシステムはピアノード２０の同意ＡＰＩを呼び出して、同意の詳細を検索し、同意がマーケティング目的を許可していることを検証する。ピアノードのそれぞれがこの同じ機能を実行することができ、したがって、ピアノードに対して先ほど説明した呼び出しは、任意のピアノードに関して実行することができることに再度留意することができる。

【0019】

ここで、図３を参照して、消費者が本システムを使用してオプトアウトする方法を説明することができる。処理は、消費者３４が企業に連絡し、オプトアウトを要求することから始まる。ステップ３６で、ピアノード１６は、分散型台帳の同意プロトコルを使用して、分散型台帳上の他のすべてのピアノードと同期するので、すべてのノードが同意を取り消したことになる。

【0020】

ステップ３８で、ピアノード１８上の購読ＡＰＩは、同意が取り消されたことを検出し、以前にＢ社のシステムがその同意のために通知を購読していたので、Ｂ社のシステムに通知を送信する。

【0021】

ステップ４０で、ピアノード２０上の購読ＡＰＩは、同意が取り消されたことを検出し、以前にＣ社のシステムがその同意に対する通知を購読していたため、Ｃ社のシステムに通知を送信する。標準的な冗長性プロトコルを使用して、購読ＡＰＩはプライマリおよびセカンダリのピアノードがあり、１つのノードがダウンしても通知が送信されないことがないようにするが、これらの機能を実行する特定のノードが変わる可能性があることに留意してもよい。

【0022】

ここで、図４を参照して、システムが適合性をチェックすることによってレギュレータ機能を実行する方法を、特定の例を参照して説明することができる。Ｃ社がレギュレータ（規制者）によって監査されたとする。ステップ４２で、Ｃ社のシステムは、要求されたデータを関連する同意ＩＤとともにレギュレータに送信する。レギュレータは、ピアノード２２の同意ＡＰＩを呼び出して、すべてのデータに有効な同意があることを検証する。その後、ピアノード２２は、要求された検証データをレギュレータに返す。

【0023】

別段の記載がない限り、本明細書で使用されているすべての技術用語および科学用語は、本発明が属する技術分野の通常の技術者が一般的に理解しているものと同じ意味を持つ。本明細書に記載されているものと同様または同等の任意の方法および材料も、本発明の実施または試験に使用することができるが、本明細書では例示的な方法および材料を限定的に記載している。

【0024】

本明細書で使用されているすべての用語は、文脈と一致する可能な限り広範な方法で解釈されるべきである。本明細書でグループ化が使用される場合、グループのすべての個々のメンバー、ならびにグループの可能なすべての組み合わせおよびサブコンビネーションが、本開示に個別に含まれることが意図される。本明細書で引用されたすべての文献は、本明細書の開示と矛盾しない範囲で、参照により本明細書に組み込まれる。本明細書で範囲が表現されている場合、その範囲は、その範囲内のすべての副範囲およびその範囲内のすべての特定の点を包含し、開示することが意図されている。

【図1】

【図2】

【図3】

【図4】