JP7847985B2 - ブロックチェーンによってサポートされるプライバシー保護ＭａａＳ（Ｍｏｂｉｌｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ） - Google Patents

Description

本開示は、概して、分散型台帳を提供するための通信ネットワークノード、通信ネットワークおよび方法に関する。

一般的に、デジタル取引を記録するエンティティ、例えば、電子機器、サーバ等の複数のノード上で台帳を分散することが知られている。分散型台帳は、例えば、周知の暗号通貨ビットコイン、また、周知のイーサリアムプロジェクト等が基礎を置く周知のブロックチェーン技術に準拠することができる。一般的に、分散型台帳は、ブロックチェーン技術以外の他の技術で実現されてもよく、ブロックチェーンに基づかない分散型台帳プロジェクトの例としてＢｉｇｃｈａｉｎＤＢおよびＩＯＴＡ等がある。例えば、ＩＯＴＡは、互いに紐付けられたリストを用いる暗号通貨である。また、例えば、ユーザや乗客が自動車等を所有せずにサービスとしてのモビリティを利用する、ＭａａＳ（Mobility as a Service）が知られている。ＭａａＳは、関連する事業者または提供者からの公共（例えば、列車、バス等）および個人（例えば、カーシェア、自転車シェア等）交通サービスを組み合わせることができる。

周知のＭａａＳソリューションは、典型的には、中央の統一されたゲートウェイを含み、これを通じて、出張または旅行が計画および予約され、ユーザは、単一のアカウントで支払いを行うことができる。

分散型台帳およびＭａａＳを提供するための技術が存在するが、一般的に、分散型台帳を提供するための通信ネットワークノード、通信ネットワーク、および通信ネットワークを制御する方法を提供することが望ましい。

AL-ZABEN NASR他著"General Data Protection Regulation Complied Blockchain Architecture for Personally Identifiable Information Management"2018 INTERNATIONAL CONFERENCE ON COMPUTING, ELECTRONICS & COMMUNICATIONS ENGINEERING (ICCECE), IEEE,16 August 2018 (2018-08-16), page 77-82 Danny Yang他著"Survey of Confidentiality and Privacy Preserving Technologies for Blockchains"14 November 2016 (2016-11-14)(URL:https://z.cash/static/R3_Confidentiality_and_Privacy_Report.pdf) DAVID LOPEZ他著"A blockchain framework for smart mobility"ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853,16 September 2018 (2018-09-16) SHELLY GROSSMAN他著"Online Detection of Effectively Callback Free Objects with Applications to Smart Contracts"ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853,12 January 2018 (2018-01-12)

本発明は、分散型台帳を提供するための通信ネットワークノード、通信ネットワーク、および通信ネットワークを制御する方法を提供することを目的とする。

第1の態様によれば、本開示は、データを分散型台帳に提供するための通信ネットワークノードであって、機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、上記非機微ユーザデータを上記分散型台帳に提供するように構成される回路を有する通信ネットワークノードを提供する。

第２の態様によれば、本開示は、分散型台帳を提供するための複数のノードを有する通信ネットワークであって、上記複数のノードの少なくとも一のノードは、機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、上記非機微ユーザデータを上記分散型台帳に提供するように構成される回路を有する通信ネットワークを提供する。

第３の態様によれば、本開示は、分散型台帳を提供するための複数のノードを有する通信ネットワークを制御する方法であって、機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を用意し、上記非機微ユーザデータを上記分散型台帳に提供する方法を提供する。

さらなる態様が独立請求項、以下の説明および図面に記載される。

実施形態が添付の図面に関して例示として説明される。

図１は、ブロックチェーンを概略的に示す。 図２は、ブロックチェーンにおけるハッシュ化を概略的に示す。 図３は、コンセンサスプロトコルの一実施形態を示すフローチャートである。 図４は、ＭａａＳシステムにおけるデータフローを示す。 図５は、旅行ログデータを含むブロックチェーンの一実施形態を示す。 図６は、ブロックチェーンを提供するための通信ネットワークの一実施形態を示す。 図７は、機微および非機微データを分離する一実施形態を示す。 図８は、旅行データを含むブロックチェーンのそれぞれのブロックを示す。 図９は、乗客データの仮名化を示す。 図１０は、乗客データの匿名化を示す。 図１１は、ブロックチェーンにおけるデータ保護のそれぞれ異なる鍵を用いる一実施形態を示す。 図１２は、機微データが保護される、非機微データおよび機微データの分離を示す。 図１３は、データの第三者暗号化を示す。 図１４は、機微データが匿名化される、第三者によるデータへのアクセスを示す。 図１５は、ビッグデータ分析のための第三者によるアクセスのためのアプリケーションプログラミングインタフェースを示す。 図１６は、鍵を無効化することによってブロックチェーンからデータを消去する第一の実施形態を示す。 図１７は、ブロックを消去するによってブロックチェーンからデータを消去する第二の実施形態を示す。 図１８は、汎用コンピュータの一実施形態を示し、いくつかの実施形態において当該汎用コンピュータに基づいてネットワーク機器または通信デバイスが実現される。 図１９は、互いに通信するｅＮｏｄｅＢおよびユーザ機器の一実施形態を示す。

図１を参照して実施形態を詳細に説明する前に一般的な説明を行う。

冒頭で述べたように、一般的に、分散型台帳およびＭａａＳ（Mobility as a Service）が知られている。

本開示は概して、いくつかの実施形態または態様では、ＭａａＳアプリケーション、特に、二以上のサービス提供者（マルチモーダル輸送）間のＭａａＳに関するブロックチェーン／分散型台帳の用途に関する。

また、本開示は概して、いくつかの実施形態または態様では、本開示をブロックチェーンに限定することなく、分散型台帳または分散型台帳の一例としてのブロックチェーンの用途に関する。分散型台帳は、マルチプレイヤ、すなわち、複数のＭａａＳ提供者間の旅行履歴（または旅行データ）用の分散型データベースを必要とするため、分散型台帳またはブロックチェーンは、本開示のいくつかの態様に係るＭａａＳアプリケーションに適していると認識される。

いくつかの実施形態では、ＭａａＳブロックチェーンが多数の乗客を取り扱うこと、様々なタイプの旅行記録を記憶すること、大きなサイズのブロックを記憶すること、混雑時における処理のピークを記憶すること等を必要とし得る。

いくつかの実施形態では、一般的に、分散型台帳またはブロックチェーンは、複数のプレイヤ間の旅行履歴用の分散型データベースを提供するため、ＭａａＳアプリケーションに適している。

しかしながら、個人データは、典型的にはブロックチェーンの全てのメンバーに対してオープンであり、ユーザは、ブロック内の再コード化されたデータを削除／修正することができないため、個人データ保護はブロックチェーン／分散型台帳にとって困難であり得る。

したがって、いくつかの実施形態では、特にＭａａＳアプリケーションのために、ブロックチェーンベースの分散型台帳を用いてユーザのプライバシーを保護することが有用であり得ることが認識されている。さらに、乗客の旅行記録と乗客のプライバシー保護の要件は、いくつかの実施形態では、互いに対立する可能性がある。

いくつかの実施形態では、乗客の旅行を正確に記録することに関して、分散型台帳は、プレイヤ（モビリティサービス提供者を含む）間で共有することができ、不変であってもよい。このような特性は、いくつかの実施形態では、レベニューシェアの計算のような旅行の記録／証拠に適している。加えて、国の輸送機関は、特に航空旅行について知られているように、乗客情報の記録を保持することを要求し得る。

一方、いくつかの実施形態では、ＭａａＳ旅行記録が乗客がどこで、いつ、誰で、何をしているか等、機微な乗客情報に含めることができる。したがって、個人データ保護の観点から、匿名化および仮名化を適用することができる。いくつかの実施形態では、一般データ保護規則（ＧＤＰＲ）等の個人データを保護するための要件が存在する。

したがって、本開示では、いくつかの実施形態は、アクセス制御で個人データをどのように保護するか、および乗客のデータの匿名化および仮名化の方法をどのように提供するかという問題に関する。

したがって、いくつかの実施形態では、第三者がアクセスできないシステムのアクセス不能な部分に個人情報が限定される。また、いくつかの実施形態では、ユーザプロファイル／マルチモーダルパス情報の機微性が、ユーザと契約するモビリティサービス提供者によって保証され、一方、例えば、ユーザ固有ＩＤは、分散型台帳またはブロックチェーンで匿名化される。分散型台帳またはブロックチェーンに含まれる旅行ログはアクセス制御下にあってもよく、旅行ログの内容は仮名化されてもよい。

以下、いくつかの用語を定義する。これらの用語はいくつかの実施形態において適用され得る（なお、本開示は以下の定義に限定されることはない。これらの定義は本開示の理解を高めるために与える一例に過ぎず、ＭａａＳおよび分散型台帳の技術分野は非常に動的であり、定義は今後変化し得ることに留意されたい）。

用語「分散型台帳」は、Wikipediaから分かるように、「分散型台帳（共有台帳または分散型台帳技術（ＤＬＴ）とも呼ばれる）は複数のサイト、国、または機関に地理的に分布した、複製、共有、および同期化されたデジタルデータのコンセンサスであり、中央管理者または集中型データストレージは存在しない」と定義される。

分散型台帳およびその特別な例、すなわちブロックチェーンの技術についても、以下でさらに説明する。より一般的には、分散型台帳という用語がネットワークの複数のノードとデータベースを共有するデジタル的に記録されたデータの一種として用いられる。ピアツーピアネットワークで構成される場合がある。デジタル的に記録されたデータは、同じデータベース上の以前に記録されたデータからその一貫性を証明するための一種の情報を含んでもよい。

分散型台帳はパブリックであり、誰でもアクセス可能であるが、原則として、パブリックでなく、許可を有するユーザのみが分散型台帳にアクセスすることができてもよい。ここで、許可を有するエンティティ、ノード、人物、事業者、提供者等のグループは以下でさらに説明するように、「コンソーシアム」とも呼ばれることがある。また、階層化されたユーザ毎に、台帳のデータへのアクセス許可を区別することも可能である。

分散型台帳は例えば、ビットコインに用いられるようなブロックチェーン技術から知られているメカニズムを用いることができる。このようなメカニズムには、発見方法、コンセンサスメカニズム、データの一貫性を保つメカニズム等が含まれる。コンセンサスメカニズムは、分散型台帳のコピーを有する全てのノードまたは一定数より多いノード、一般的には電子機器が分散型台帳のコンテンツに関するコンセンサスに達することを保証する。いわゆる、暗号パズルの一種であり、例えば、ブロックチェーンの古いブロックが（容易に）変更され得ないことを保証する、いわゆる、プルーフオブワークメカニズムを含む、多くのコンセンサスメカニズムがある。例えば、ビットコインブロックチェーンのマイニング処理には、プルーフオブワークが用いられる。

分散型台帳またはブロックチェーンでは、マイニング処理と呼ばれる、参加ノードにおけるブロックチェーン上のデータ更新に関するコンセンサスを作成する確認処理は、確認データに以前に記録されたデータを含めることによって、ブロックチェーン上に記録された取引シーケンスの不可逆性を達成することができる。このようなマイニング処理は、新しい取引ブロックの分散タイムスタンプサーバを実現する。ビットコイン（したがって、いくつかの実施形態では）において、マイニング処理は、ＳＨＡ－２５６ハッシュ関数に基づく。ハッシュ関数の入力がブロックチェーンの現在のブロックおよびブロックチェーンに追加されるべき新しい取引ブロックに依存する一方で、マイニング処理に関与するブロックチェーンのノードは、予め定義された特性を有するハッシュ出力を検索する。

ハッシュ関数に基づくプルーフオブワーク計算は、分散型台帳の不可逆性を実現するために必要とされることを除いて、それ自体では有用ではない場合がある。

さらに、一般的に、様々なデータを記憶するためにブロックチェーンを用いることが知られている。例えば、画像、映像、測定値、テキストファイルは、取引の形式でブロックチェーンに記録することができる。

用語「ＭａａＳ（Mobility as a Service）」は、次のようにWikipediaで定義されている。「ＭａａＳ」は、個人所有の輸送形態から、サービスとして消費されるモビリティソリューションへの移行を表す。これは、公共および民間の輸送機関からの輸送サービスを、ユーザが単一のアカウントで支払いを行うことができる旅行を作成し管理する統一されたゲートウェイを介して組み合わせることによって可能になる。ユーザは旅行毎に代金を支払うことができ、または限られた距離に対して月額料金を支払うことができる。ＭａａＳの背後にある重要なコンセプトは、旅行ニーズに基づいて旅行者のモビリティソリューションを提供することである。

「パブリックブロックチェーン／分散型台帳」はいくつかの実施形態では、上記でも示したように、誰でも分散型データベース（台帳）を共有し、コンセンサスプロトコルを実行するために参加することができることを意味する。

これとは対照的に、「許可型ブロックチェーン／分散型台帳」とは許可されたメンバーのみが分散型データベース（台帳）を共有し、コンセンサスプロトコルに参加できることを意味し、ブロックチェーンにアクセスする許可を有する許可されたメンバーは上述のように「コンソーシアム」と呼ばれる。いくつかの実施形態では、許可／コンソーシアム型のブロックチェーンは、公開されておらず、したがって誰もアクセスすることができないため、ＭａａＳアプリケーションに適している。

用語「（モバイル）エッジコンピューティング」の定義もまたWikipediaで見つけることができ、次のように定義される。マルチアクセスエッジコンピューティング（ＭＥＣ）（旧モバイルエッジコンピューティング）」は、クラウドコンピューティング能力とＩＴサービス環境を、移動体通信ネットワーク^{［１］［２］}のエッジで、より一般的には、どのネットワークのエッジでも可能にするネットワークアーキテクチャの概念である。ＭＥＣの背後にある基本的な考え方は、アプリケーションを実行し、関連する処理作業を移動体通信顧客に近づけることで、ネットワーク輻輳が軽減され、アプリケーションのパフォーマンスが向上するということである。

用語「ノースバウンドＡＰＩ」は、通信事業者がソフトウェアベースのインタフェース（ＡＰＩ）を使用してネットワーク機能を設定でき、ネットワーク事業者が仮想インフラストラクチャ（仮想マシン等）と要求されたネットワーク機能／アプリケーション機能を設定できるという意味で、ネットワーク仮想化コンテキストで理解される。

用語「インスタンス」は、クラウド上で実行されるソフトウェア処理として理解される。分散型クラウド内のどこかに移動することがある。

「パブリッククラウド」は、次のように定義することができる。パブリッククラウドは、クラウドコンピューティングを展開する最も一般的な方法であり、クラウドリソース（サーバや記憶装置等）は、第三者であるクラウドサービス提供者によって所有され、運用され、インターネット上で配信される（https://azure.microsoft.com/en-gb/overview/what-are-private-public-hybrid-clouds/）。

いくつかの実施形態では、以下の用語が所与の理解において用いられる。

用語「マルチモーダル輸送パス」は、有効期間または利用可能な輸送、許可できないサービス等の特定の条件を有するマルチモビリティサービスに有効なパスとすることができる。例えば、１日チケット、１週間チケット、月次ＭａａＳサービスのサブスクリプション、シーズンチケット等である。

用語「モビリティサービス提供者」は、任意のタイプのサービス提供者ＭａａＳの総称とすることができる。いくつかの実施形態では、典型的には、鉄道会社、バス／長距離バス、トラムおよびタクシー、カーシェア、ライドシェア、バイクシェア等の輸送機関である。モビリティサービス提供者のいくつかは、実際の輸送手段を提供せず、旅行代理店またはオンライン予約サイト等に匹敵する予約／構成のみを提供してもよい。

用語「パス」は、トランジットパスまたはトラベルカード（英国）（https://en.wikipedia.org/wiki/Transit_pass）も参照）とすることができ、本開示においては、マルチモーダルパスが用語「パス」にも相当するものとする。これは、パスが複数の輸送事業者（またはモビリティサービス提供者）間で有効であることを意味し、従って、公共交通だけでなく、ライドシェア、バイクシェア等の他の種類のモビリティも対象とすることができる。パスは、許可される輸送、有効期間、およびチケット発行／輸送・乗車の任意の他の状況の情報を含むことができる。いくつかの実施形態では、ＭａａＳは、サービスレベルに関するいくつかのオプションを付けて月次サービスサブスクリプションを提供することができる。乗客またはユーザは、サービス加入料金または特定期間のパスの購入代金をパス発行者（通常、パスを発行するモビリティサービス提供者とすることができる）に支払うことができる。パスは、輸送事業者または旅行代理店、ＭａａＳサービス提供者等（全て、上記モビリティサービス提供者という用語に該当することがある）によって発行することができる。したがって、上述のように、パス発行者のうちの一部は、パスを販売するが、実際の輸送サービスまたは輸送手段を提供することはない場合がある。

用語「チケット」は、座席予約を伴う（または伴わない）片道の列車チケットのような特定の区間の片道旅行のためのチケットであってもよい。チケットは、いくつかの実施形態では、マルチモーダル輸送パスおよびその条件の下で発行されてもよく、選択された輸送、座席番号、価格等の情報を含んでもよい。いくつかの実施形態では、座席の予約が必要とされないか、または無制限の旅行が許可される場合であっても、チケットは複数のモビリティサービス提供者間での収益分配のために発行されてもよい。さらに、乗客（ユーザ）はチケット発行者に直接代金を支払うことはできないが、パス発行者は乗客の代わりにチケット発行者に代金を支払うことができ、チケットは、輸送事業者またはサービス提供者、すなわちモビリティサービス提供者によって発行され得る。

用語「旅行ログ」は、チケットに基づく片道旅行記録である旅行ログを含むことができる。乗車位置（location of embankment）、その日時、降車場所、その日時、チケットが使用されているか未使用であるか等に関する情報を含むことができ、これについても以下でさらに説明する。

用語「匿名化」は、Wikipediaに従って次のように定義することができる。データ匿名化がプライバシー保護を目的とする情報サニタイズの一種であり、データセットから個人的に識別可能な情報を暗号化または削除することによって、データが記述する人物が匿名のままであるようにする処理である（https://en.wikipedia.org/wiki/Data_anonymization）。

用語「仮名化」は、Wikipediaに従って次のように定義することができる。仮名化は、データレコード内の個人的に識別可能な情報項目が一または複数の人工識別子または仮名によって置き換えられる、データ管理および匿名化手順である。置き換えられた項目または置き換えられた項目の集合毎の単一の仮名は、データ解析およびデータ処理に適したままで、データレコードを識別不能にする（https://en.wikipedia.org/wiki/Pseudonymization）。

用語「非トレーサビリティ」は、誰も（例えば、エンティティ、ユーザ、人物等ではなく）アクションまたは挙動の履歴を追跡することができないという意味で理解され得る。例えば、ユーザが特定の日時に行った場所、ユーザが行ったこと、またはユーザが行っていないことを追跡不能にすることができる。

さらに、一般データ保護規則（ＧＤＰＲ）が要求され得る。「一般データ保護規則（ＥＵ）２０１６／６７９」（「ＧＤＰＲ」）は、ＥＵ（欧州連合）および欧州経済領域（ＥＥＡ）内の全ての個人用のデータ保護およびプライバシーに関するＥＵ法における規制である（https://en.wikipedia.org/wiki/General_Data_Protection_Regulationも参照）。

用語「個人データ」は、いくつかの実施形態では、次のような意味で理解され得る：「（１）「個人データ」は、識別されたまたは識別可能な自然人（「データ主体」）に関する任意の情報を意味する；識別可能な自然人は、特に、氏名、識別番号、位置データ、オンライン識別子等の識別子を参照することによって、またはその自然人の身体的、生理的、遺伝的、精神的、経済的、文化的、もしくは社会的アイデンティティに固有の一または複数の因子を参照することによって、直接的または間接的に識別され得る者である（例示的なhttps://gdpr-info.eu/art-4-gdpr/を参照）」

したがって、「ＧＤＰＲにおける仮名化」は、次のような意味で理解され得る：「（５）「仮名化」とは追加情報を用いることなく、個人データが特定のデータ主体に帰属することができなくなるような手段で個人データを処理することを意味する。ただし、当該追加情報は別個に格納され、特定されるまたは特定可能な自然人に当該個人データが帰属されないことを保証するための技術的および組織的措置が施されることを条件とする」

いくつかの実施形態では、用語「公開鍵暗号」は、Wikipediaでも定義されているように次のように理解される：「公開鍵暗号または非対称暗号は、対の鍵を用いる任意の暗号システムである：広く普及する可能性がある公開鍵と、所有者にしか知られていない秘密鍵の対を用いる任意の暗号システム。これは、対になった秘密鍵の保持者がメッセージを送信したことを確認する認証と、対になった秘密鍵の保持者のみが公開鍵で暗号化されたメッセージを復号できる暗号化の２つの機能を達成する」一方、「公開鍵暗号の最もよく知られた使用法の２つはメッセージが受信者の公開鍵で暗号化される公開鍵暗号化である。メッセージが受信者の公開鍵で暗号化される。当該メッセージは、一致する秘密鍵を持たない何人（つまり、一致する秘密鍵の所有者および公開鍵に関連付けられた人物であると推測される者）にも解読することができない。これは機微性を確保するために用いられる」および「メッセージが送信者の秘密鍵によって署名され、送信者の公開鍵にアクセスできる者なら誰でも当該メッセージを確認できるデジタル署名。この確認によって、送信者がそのプライベート鍵にアクセスしている、それゆえ、その公開鍵に関連付けられた人物である可能性が高いことが証明される。これにより、署名が元々共に作成されたメッセージに数学的にバインドされるため、メッセージが改竄されていないことも保証される。また、元のメッセージとどれだけ似ていても、実際上、任意の他のメッセージに対しての確認は失敗する（https://en.wikipedia.org/wiki/Public-key_cryptography）」

いくつかの実施形態では、用語「ソルト」は、Wikipediaに従って次のように定義することができる：「暗号では、ソルトは、データ、パスワード、またはパスフレーズを「ハッシュ」する一方向性関数への追加入力として用いられるランダムデータである。ソルトはノンスの概念に密接に関連している。ソルトの主な機能は、辞書攻撃に対する、またはそのハッシュされた等価物、つまり、予め計算されたレインボーテーブル攻撃に対する防御である（https://en.wikipedia.org/wiki/Salt_(cryptography)）」

以下では説明の一般的な概要を与える。ここで、本開示の４つの異なる態様のための実施形態を説明する。これらは別個の態様として実施または実現されてもよく、または任意の可能な組み合わせで互いに組み合わせられてもよい。

第１の態様によれば、機微データの分離（オフチェーン技術による）と、仮名化および匿名化（スクランブリングおよび／またはハッシュ化）のナイーブな方法とを含む、基本技術に関係するいくつかの実施形態が説明される。

第２の態様によれば、いくつかの実施形態はデータのアクセス制御に関するものであり、アクセス制御は、アクセス制御のレベル、異なるアクセス鍵によるブロック暗号化、および／またはオープンデータおよびＡＰＩを含み得る。

第３の態様によれば、いくつかの実施形態は例えば、鍵無効化および／またはブロック消去を含む機微データの消去に関する。

以下では、ブロックチェーンおよびその一般的なデータ構造を、図１を参照して説明する。ブロックチェーンの本実施形態では、特徴は、ネットワーク／トポロジー、コンセンサスアルゴリズム、ハッシュ関数、参加者認証、スケーラビリティ／ブロック構造およびパフォーマンスである。

図１は、ブロックチェーン１の一般的な構造を示す。ブロックチェーン１は複数のデータブロック２ａ、２ｂ、および２ｃのチェーンを含み、ブロック２ｂは現在のブロック（ブロック＃Ｎ）であり、ブロック２ａは先行のブロック（ブロック＃Ｎ－１）であり、ブロック２ｃは後続のブロック（ブロック＃N＋１）である。各ブロックは先行のブロックのハッシュ関数結果、主要なデータ構造、現在のブロックのハッシュ関数とハッシュ関数結果の入力値を含み、現在のブロック（２ｂ）のハッシュ関数結果は、常に次のブロック（２ｃ）への入力として用いられる。

また、各ブロックには、安全なブロックチェーン処理用の一回限りの乱数であり、リプレイ攻撃を防ぐことができる「一度だけ使用される数字」が含まれており、例えば、攻撃者が以前に送信したデータをコピーし、再度コピーしたデータをスプーフィングに再利用する場合、次のデータを別の「一度だけ使用される数字」によって使用しなければならないため、受信者はスプーフィングの通信を検出することができる。この乱数は、暗号通貨では「ノンス」と呼ばれることもある。

さらに、タイムスタンプは、ブロック２ａ、２ｂ、および２ｃのそれぞれに挿入されてもよい。ブロックチェーン１は例えば、いくつかの実施形態においてＭａａＳを提供するために使用され得る分散型台帳の一例である。

図２は、例えば、図１のブロックチェーン１に用いられるハッシュ関数の入出力を示す。

一般的に、ハッシュ関数は、特定のアルゴリズムで入力データを出力データにマッピングするために使用できる任意の関数である。入力データのサイズは大きく、様々とすることが可能であり、逆に、データの出力はコンパクトであり、固定サイズとすることができる。いくつかのブロックチェーンの実施形態において、ハッシュ化に利用される周知の（および有名である）アルゴリズムは米国国家安全保障機関（例えば、ＳＨＡ－２、ＳＨＡ－２５６）によって設計された安全ハッシュアルゴリズム（ＳＨＡ）である。

ハッシュ関数の入力は、以前のハッシュ出力、ノンス、および現在のブロック（例えば、図１のブロック２ｂ）内のデータ本体である。ハッシュ関数の出力は、入力値に対する一意の値応答である。誰かがデータ本体を改竄しようとすると、ハッシュ関数の出力に一貫性がなくなる。

本開示における分散型台帳（ブロックチェーン）の実施形態は、コンセンサスプロトコルまたはアルゴリズムを実現することができる。例えば、いくつかの実施形態では、ビザンチン・フォールトトレラント性（BFT：Byzantine Fault Tolerance）がコンセンサスプロトコルに使用され、これはデータベースのなりすましおよびハードウェアの障害に対して回復力を有する。

いくつかの実施形態で実現される周知のコンセンサスアルゴリズムは、いわゆるＰＢＦＴ（Practical Byzantine Fault Tolerance）である。

いくつかの実施形態では、許可ブロックチェーンが使用され、比較的少数の許可されたブロックチェーンノードがコンセンサス（ブロックの検証）を担当する。

図３は、ＰＢＦＴの処理１０を例示する。

リーダーノード（バリデーティングピアとも呼ばれる）は、１１において、ブロックチェーンを検証するように他のノードに要求する。１２において、要求された各ノード（ピアの検証）がハッシュ関数を使用してブロックチェーンの有効性を確認し、その結果を１３において他のノードに通知する。１４において、ノードは、複数の他のピアから有効性結果を受信し、所定の基準よりも有効な結果を受信した場合、ブロックチェーンのコンセンサスを確認する。コンセンサスがある場合、１５において、ノードはブロックチェーンを書き込み／終了する。リーダーピアは、他のノードにおける有効性確認の全体的な進行を確認し、１６においてブロックチェーン手順を終了する。

回復力のために、ノード総数はいくつかの実施形態では、３ｆ＋１を超え、ここで、ｆは許可される障害ノードの数である。例えば、ｆ＝１の場合、合計４のノードがある。ｆ＝３の場合、合計１０のノード等がある。

いくつかの実施形態では、ＰＢＦＴは、本明細書に記載するように、モビリティサービスブロックチェーン用の許可ブロックチェーンを有し、少なくとも部分的に以下の特徴を提供する。

セキュリティに関して、ＰＢＦＴには、いくつかの実施形態では、５１％攻撃というわずかなリスクがある。このことは、コンセンサスを担当するピアの許可が信頼されなければならないため、暗号通貨に共通している。プライバシーに関して、モビリティサービス提供者のみが（許可制ブロックチェーンのために）（ピア）ノードでブロックチェーンを処理し、エンドユーザがブロックチェーンにアクセスする許可を有しないことがあるため、エンドユーザはブロックチェーン全体にアクセスすることができない。パフォーマンスに関して、コンセンサスのための処理時間は、いくつかの実施形態では、高性能を有するピアの数が少ないため、非常に短い。柔軟性に関して、ブロックチェーンのブロックサイズおよびフォーマットは、いくつかの実施形態では、パブリックブロックチェーンと比較して柔軟であり得る。

以下、ＭａａＳシステム２０のデータフローを、全体的なデータフローを示す図４を参照して説明する。ＭａａＳシステム２０では、エンドユーザが例えば、スマートフォン（または他の任意のタイプの電子（モバイル）装置）等の自身の端末２１を有することを例示的に想定する。一部のユーザ（例えば、海外からの訪問者）はスマートフォン等を有しない場合があり、そのような場合、例えば、ユーザにゲートを提供する図４のプロキシ機能（プロキシ２２）に基づく代替の解決策を提供することができる。

図４は、ＭａａＳシステム２０のデータフロー図を示し、３つの主要部分、左側のエンドユーザ部、中央のモビリティサービス事業者／提供者部、および右側の他のエンティティ部が提供され、エンドユーザ部および他のエンティティ部は、中央のモビリティサービス提供者部と通信する。

ＭａａＳシステム２０の本実施形態では、モビリティサービス提供者が、顧客サービス用のWebサーバまたはクラウドを有するユーザ管理機能２３と、ユーザプロファイル管理機能２３ａと、乗客旅行管理機能２３ｂとを有するものとする。さらに、ブロックチェーン管理機能２４を有する。ブロックチェーン管理機能２４ａを有するブロックチェーン機能２４は、他のエンティティ部のブロックチェーン管理機能２５と通信する。座席予約／ライドシェア予約が予約センター２６によって提供される場合、中央予約サーバ／クラウドが提供される。

エンドユーザは、例えば、ＧＮＳＳ、ＮＦＣ等の例示的なユーザインタフェースおよびセンサを有する自身の端末、すなわち、本実施形態では、スマートフォン２１と通信する。

図４からも分かるように、エンドユーザは例えば、端末またはプロキシ２２を介して、サービスの加入／１日／１週間チケットの購入、列車の予約、カー／ライドシェアの予約、輸送の着陸許可／記録、到着後の後処理（例えば、顧客調査、返金または遅延の補償）等の行動を実行することができる。

ユーザプロファイル管理機能２３ａは静的データ、例えば、氏名、年齢、連絡先住所、支払い方法（例えば、クレジットカード）、サービス加入状況、輸送の好み、ＴＭＥＩのような任意の他の一意のＩＤ等を記憶し、端末２１と通信するように構成される。

乗客旅行管理機能２３ｂはいくつかの動作を実行し、端末２１と通信するように構成される。例えば、マルチモーダル輸送パスに関して、乗客旅行管理機能は、例えば、ＭａａＳの月次サービスのサブスクリプションと、１日チケット、１週間チケット等の購入とを管理する。旅行計画（または旅行計画者）に関して、乗客旅行管理機能は、目的地入力、経路選択／輸送オプション、予約／旅行構成を提供し、チケットを発行し、チケットＩＤを発行し、乗客のための旅程を生成し、旅程ＩＤ等を発行する。乗客／ユーザの旅行において、乗客旅行管理機能は、旅行を開始し、旅行（反復）の各区間毎に、保持してるパス／チケットを確認し、乗車を記録し、降車を記録し、旅行ログをブロックチェーンに追加し、旅行の終わりにそれを終了し、旅行日程を閉じるように構成される。

ブロックチェーン管理機能２４ａは、乗客旅行管理機能２３ｂおよび他のブロック管理２５と通信する。ブロックチェーン管理機能は、コンセンサスプロトコルを追加し、検証し／実行し、ブロックチェーンを読み取るように構成される。さらに、図４から分かるように、パス、チケット、および旅行ログ情報は、少なくとも乗客旅行管理機能２３ｂとブロックチェーン管理機能２４ａとの間、およびブロックチェーン管理機能２４ａと他のブロックチェーン管理２５との間で通信される。

以下、図５を参照して、乗客の旅行履歴を含むブロックチェーン３０の実施形態を説明する。

ブロックチェーン３０は図１の基準の下に一般的に説明されるように、いくつかのブロック３０ａ、３０ｂ、３０ｃを有し、ここで、図５において、ブロック３０ａ（ブロック＃Ｎ－１）を過ぎ、現在のブロック３０ｂ（ブロック＃Ｎ）および後続／未来のブロック３０ｃ（ブロック＃Ｎ＋１）が例示される。

ブロック３０ａ、３０ｂ、３０ｃの各々は、所与の最大ブロックサイズ内および関連するデータ構造内の取引における一または複数の乗客ログを含むことができる。図５において、左側のブロック３０ａ（ブロック＃Ｎ－１）は、２つの乗客ログ３１ａおよび３１ｂを取り扱う。Ｎ－１ブロック３０ａからのハッシュ出力は、次のＮブロック３０ｂ（現在のブロック）に与えられる。ブロック３０ｂ（ブロック＃Ｎ）は乗客ＡおよびＢの次の旅行ログ３２ａおよび３２ｂ、さらに、乗客Ｃの旅行の旅行ログ３２ｃを処理する。例えば、乗客Ｄが新たな旅行ログを発行するが、同時にブロックサイズ制限を超える場合、さらなる旅行ログは次のブロック、すなわち、本例のブロック３０ｃにおいて処理され、これは乗客Ｂのさらなる旅行ログ３３ａの入力、乗客Ｃのさらなる旅行ログの入力３ｃｂ、および乗客Ｄのさらなる旅行ログ３３ｃの入力を含み、ブロック３０ｃ（ブロックＮ＋１）は、乗客ＣおよびＤの次の旅行および乗客Ｄの残りのログを処理する。次に、ハッシュ出力（Ｎ＋１）は、次のブロック（Ｎ＋２）（図５には図示せず）に供給される。

一般的に、ブロックチェーン３０内の旅行ログは、以下の情報のうちの少なくとも１つを含むことができる。

・発行者：マルチモーダル輸送パス発行者、モビリティサービス提供者／輸送事業者、乗客ＩＤ（匿名化されたデータ）

・チケット情報：チケットの種類、輸送の種類（鉄道、ライドシェア等）、座席予約（列車／座席番号）、価格またはチケット、期限および条件

・乗車記録：乗車位置、その日時、降車場所、その日時、未使用／使用

・備考：特記事項（例えば、キャンセル、遅延）

いくつかの実施形態では、ＭａａＳのブロックチェーンが許可型ブロックチェーンを用いると想定される。許可型ブロックチェーンでは、（コンソーシアムを形成する）許可された事業者のみがブロックを追加する／読み取ることができ、限定された参加者は取引の検証（すなわち、信頼できるプレイヤとの合意）に参加することが許可される。したがって、いくつかの実施形態では、例えば、モビリティサービス提供者は、コンソーシアムに編成され、従った許可を有する者のみが許可された分散型台帳またはブロックチェーンにアクセスすることが許可され、悪意のある参加者または不正な参加者はブロックチェーンのコンソーシアムに参加することができない。

以下、図６を参照して、ＭａａＳ用の（許可された）ブロックチェーンを提供するための通信ネットワーク４０の実施形態について説明する。

回復力について、通信ネットワーク４０は、例えば、サーバの中央に強く依存している従来のシステムでは、通常、システムの弱点となる単一障害点（ＳＰＯＦ）のリスクを軽減する。

図６から分かるように、通信ネットワーク４０は、ＭａａＳサービス提供者、鉄道事業者、カーシェア／ライドシェア事業者、バイクシェア事業者、およびバス事業者等の異なる事業者またはモビリティサービス提供者に関連する複数のノード（またはエンティティ）４１（大きい円）を有する。

さらに、モビリティサービス提供者のノード４１と通信することができる複数の乗客４２（小さい円）が存在する。モビリティサービス提供者のノード４１は、ＭａａＳ用の許可型ブロックチェーン（例えば、図５のブロックチェーン３０）を提供する通信ネットワーク４０を一緒に形成することができる。

乗客４２は例えば、モビリティサービス提供者によって提供される月次ＭａａＳサービスに加入するか、または関連するモビリティサービス提供者とその端末（例えば、図４の端末２１）と通信することによって、マルチモーダル輸送サービス用の１日／１週間のパスを購入する。

モビリティサービス提供者４１は上述のように、自動車・鉄道会社、トラム事業者等の従来の輸送事業者に加えて、ＭａａＳ事業者（例えば、ライドシェア）、バイクシェアサービス提供者、旅行代理店等の新しいサービス提供者とすることができる。

モビリティサービス提供者４１は論理接続である通信ネットワークを介して互いに接続し、事業者またはモビリティサービス提供者間の直接接続は必ずしも必要ではないが、低遅延および高スループットを必要とする場合がある。

モビリティサービス提供者のエンティティまたはノード４１は様々な機能を有することができるが、図４についても上述したように、２つの主要な機能、すなわち、乗客管理機能およびブロックチェーン管理機能がある。乗客管理機能は、座席予約、ライドシェア／タクシー／レンタカーの予約／列車の座席予約、月次サブスクリプション、または１日券の購入等をサポートする。乗客管理機能は、通常の電子商取引サイトと同様に、ウェブサイトまたはスマートフォンバックエンド処理のユーザインタフェースを提供する。

一方、本実施形態では、ブロックチェーンは、エンドユーザには隠されるが、複数のモビリティサービス提供者によってアクセスされる。さらに、本実施形態では、コンソーシアム（許可型）ブロックチェーンがノード４１間に実現され、コンソーシアムのメンバーであるモビリティサービス提供者間でブロックチェーン台帳を検証する。

いくつかの実施形態では、この上述の例は、異なる地域における国際的なＭａａＳ動作またはＭａａＳ動作に拡張される。ブロックチェーンは、多層構造として定義される。第１の層のブロックチェーンは各国間または各地域間に構成され、第２の層のブロックチェーンは当該地域のコンソーシアム内に構成される。例えば、地域のコンソーシアムにおける代表的な提供者は第１の層のブロックチェーンに参加し、国際サービスを取り扱うことができる。

上述のように、いくつかの実施形態は、サービス加入／ユーザプロファイルにおけるユーザの個人情報の分離に関する。

いくつかの実施形態では、図７にも示されるように、第１のステップとして、機微情報の乗客（ユーザ）のマスター（フル）データ５０が分離される。ここで、全データ５０は個人情報（例えば、乗客、氏名、自宅住所、電話番号、番号、性別、年齢、旅券番号、クレジットカード番号等）と、旅行データまたは旅行の統計等の非機微データとを含む。図７に示すように、フルデータ５０は、非機微データ５０ａと機微データ５０ｂとに分割され、非機微データ５０ａと機微データとが互いに分離される。

ＭａａＳサービスの加入のために、乗客は、氏名、年齢、住所、電話番号、クレジットカード番号、旅券番号／旅行文書等の個人データを入力することを要求され得る。これらは、機微データと非機微（識別不要）データとを混ぜ合わされている可能性が高い。

したがって、本実施形態では、機微情報／データ５０ｂがフルデータ５０から分離され、機微データは余分な注意を払って取り扱われ、安全な場所に格納される。

例えば、モビリティサービス提供者がクレジットカード情報を有する場合、いくつかの実施形態では、モビリティサービス提供者が決済カード業界データセキュリティ規格（ＰＣＩ規格）等の業界セキュリティ規格に準拠しなければならない。したがって、このような実施形態では、データベースおよびネットワークがファイアウォールによって外部ネットワークから保護される。

これは、いくつかの実施形態では、機微情報用のデータベースもブロックチェーンノードおよびそのネットワーク（図６のノード４１およびネットワーク４０等）から切り離されることを意味する。

いくつかの実施形態では、この機微情報と非機微情報との分離は、図８にも示されるようにブロックチェーンのブロック５５および５５に示すオフチェーン技術を用いて実行される。

本実施形態では、乗客の個人データとブロックチェーンとの間の関係がアンバンドルされる。したがって、機微データ（図７の５０ｂ）は、ブロックチェーン（オフチェーンとも呼ばれる）に含まれない。個人データ（機微データ）はＭａａＳ提供者（例えば、データベース、ストレージ等）内に格納され、ブロックチェーンに追加されない。

図８は、ＭａａＳサービスのチケットおよび旅行記録の例を示す。チケットはチケットまたはパス発行者（例えば、輸送事業者）または他のＭａａＳサービス提供者によって発行されてもよい。ブロックチェーンでは乗客名または任意の個人データは含まれないが、ブロックチェーンのブロック５５および５６のデータ構造には、誰がモビリティサービス提供者であるチケットを発行したか（パス発行者＃１等）、ある乗客に関連するチケット番号の価格、および旅行ログ識別子等の他のデータとともに、（一意の）チケット番号のみが含まれる。

例えば、本実施形態では、ブロックチェーンは、コンソーシアムの他のメンバーに対してオープンであるが、乗客（ユーザ）の機微データではなく、チケット番号のみを見ることができる。ブロックチェーンには実際の乗客が誰であるかの手がかりはない。チケットまたはパス発行者（またはＭａａＳサービス提供者）のみが、実際の乗客名とＩＤを識別できる。これはデータベースに保存されている機微情報がブロックチェーンから分離され、チケット番号に関連付けられているためである。

しかしながら、一般的に、輸送産業または観光産業においては、乗客名称記録（ＰＮＲ）が必要とされる場合があることが知られている（Wikipedia https://en.wikipedia.org/wiki/Passenger_name_record）も参照されたい）。

したがって、例えば、航空券の氏名とパスポート上の氏名が一致しない場合、搭乗は通常許可されないため、例えば、モビリティサービスが提供する予約システムは、乗客の個人データを保持しなければならない。

前述のオフチェーン技術が適用される実施形態では、ブロックチェーンメンバーが例えば、乗客に関連付けられたチケット番号または他の識別された任意の情報に基づいて、乗客の個人データを有するＭａａＳ提供者から必要な情報を要求する。

しかしながら、いくつかの実施形態では、オフチェーン技術を適用することができず、したがって、いくつかの実施形態では、ブロックチェーン内の乗客の個人データが仮名化および／または匿名化の対象となる（以下の記載を参照）。

以下では、ブロックチェーンにおける個人データの仮名化および匿名化に関する実施形態について説明する。

上述のように、乗客名のような個人データがブロックチェーンのブロックに含まれる必要がある場合、氏名（または他の個人データ）は保護されるべきである。

いくつかの実施形態では、個人データが置き換えられ、仮名化の典型的な方法は機微部分を文字または数字、またはゼロパディングで置き換えるか、またはそれを削除することである。いくつかの実施形態では、例えば、フルネームの代わりにイニシャルまたは他の頭字語を用いてまたはフルネームの代わりにユーザＩＤ番号を用いて、個人データが削除される。しかしながら、個人情報を推測または導出可能であり、かつ／または、ユーザ情報を他の情報から追跡可能である可能性がある。

以下では、仮名化および匿名化に関してさらなる実施形態について説明する。

いくつかの実施形態では、スクランブリング（マスク）が実行され、このスクランブリングは図９にも示されており、ここではスクランブリングを伴う仮名化の方法６０が示されている。

入力データ６１は、２つの部分、すなわち、パス発行者情報を含む保護されていない部分６２と、個人データ、すなわち、乗客ＩＤを含む保護されている部分６３とに分割される。

保護されている部分６２のデータは、スクランブリング処理６４（「＋」）へのストリームとして入力される。スクランブリング処理６４では、保護データ６２とスクランブリングコード６５とが互いに適用される（数学的にＥｘ－ＯＲ算出）。出力データとして、仮名化された乗客データ６６が生成され、これが出力６７として保護されていない部分６２と組み合わされる。

それによって、コンソーシアム内の他のメンバー（例えば、モビリティサービス提供者）はスクランブリング後にブロックチェーン内の実際のユーザを識別することができないが、例えば、パス発行者（スクランブリングコードを知っているか、またはスクランブリングコードを知っている他の任意のエンティティ）だけは、乗客ＩＤをデスクランブリングし、アンマスクすることができる。

一般的に、スクランブリングコードを生成するための様々な方法が存在し、本開示はその点で特定の実装に限定されず、いくつかの実施形態では、線形帰還シフトレジスタ（ＬＦＳＲ）が用いられる。いくつかの実施形態では、スクランブリングコードも構成可能であり、これが暗号化鍵に類似するように、大量の候補コードの中からスクランブリングコードが選択される。

いくつかの実施形態では、スクランブリング技術によって単純なハードウェア／ソフトウェアアルゴリズムが可能とされ、スクランブリングは典型的には可逆である（少なくともスクランブリングコードが利用可能である限り）。必要に応じて、データの元のソースによってデータのデスクランブリングが可能である。

しかしながら、いくつかの実施形態では、可逆性は必要とされない場合がある。例えば、ブロックチェーンメンバーの中に悪意のあるメンバーが存在する場合、ユーザＩＤを識別し、情報を取得することが可能であり、したがって、いくつかの実施形態では、非可逆な実施態様が必要とされる。

以下では、鍵による暗号化を利用する実施形態について説明する。原則として、スクランブリングと暗号化は同様の処理であるが、その目的や設計は異なる。

スクランブリングの主な目的はデータマスクであり、鍵は存在しないが、コード番号のみが設定される（すなわち、シフトレジスタの初期値）。誰かが誤って同じコードを設定した場合、データをデスクランブリングすることは容易である。さらに、データのスクランブリングは全ての可能な組み合わせを試みることに対して脆弱であり得る、すなわち、総当たり攻撃に基づいてデスクランブリングが可能であり得る。しかし、スクランブリングは典型的には軽い処理負荷しか伴わず、取り扱いが容易であり、その結果、いくつかの実施形態では、信頼できるメンバー間で、例えば、信頼できるメンバーのコンソーシアムで実行される。

一方、暗号化の主な目的は、秘密裏にデータを提供することである。暗号化のアルゴリズムは一般的に誰に対してもオープンであり、例えば、暗号化解除用の公開鍵（ＰＫＩの場合）を用いることができる。これは、インターネットの場合のように、公開／信頼できないグループに対して特に有用である。

しかしながら、暗号化は暗号化解除の重い処理負荷、複雑なアルゴリズムを伴うことがあり、また、自由に利用可能ではないことがあるが、例えば、知的財産を条件として、保護されることがある。

上述のように、ＧＤＰＲは、匿名化されたデータに対して不可逆的な処理を必要とする。例えば、データがオープンに第三者に提供される場合、個人データは匿名化されなければならない。

データを匿名化する方法７０の一実施形態が図１０に示されており、ハッシュ関数７１がデータの匿名化のために用いられる。

一般的に、ハッシュ関数は、特定のアルゴリズムで入力データを出力データにマッピングするために使用できる任意の関数である。入力データのサイズは大きく、様々であることができ、逆に、データの出力はコンパクトであり、固定サイズを有することができる。

ハッシュ関数７１の入力は、個人データ７２（または必要とされる任意の保護データ）およびハッシュのソルト７３（または任意の初期化ランダム値）である。

ハッシュ関数の出力は入力値に対する一意の値応答である匿名化個人データ７４であり、このハッシュ出力７４は元に戻すことができない。

いくつかの実施形態では、ソルト７３が別々に格納され、保護される。

いくつかの実施形態では、この場合、入力が再び同じユーザＩＤであっても、出力が異なるため、つまり、異なるソルトが用いられるため、ソルト鍵は、匿名化を強化するように、例えば、アプリケーション上で毎回変更される。

したがって、本実施形態では、ハッシュ化を利用するために、データの匿名化は非可逆であり、それによって、扱いにくさも生じる。この追跡不能な特性は完全な匿名化に適しており、いくつかの実施形態では、ハッシュ出力後に元のデータにアクセスすることが不可能である。

したがって、この方法７０は例えば、データが統計／ビッグデータ解析のために第三者に提供される場合に、個人データを永久的に削除するためのいくつかの実施形態において特に有用である。

上述のように、いくつかの実施形態は、分散型台帳またはブロックチェーンへのアクセス制御に関する。

分散型台帳の一般的な利点は、全てのメンバーが分散型データベースにアクセスできることである。しかし、個人情報は保護されるべきであり、いくつかの実施形態では、制限なしに共有すべきではなく、したがって、いくつかの実施形態では、データ使用の目的に応じて、データアクセスが制限される。

一般的に、アクセス制御はデータの利用目的に応じて、以下のものを含んでいてもよく、かつ／または以下の特徴を（単独でまたは組み合わせて）有してもよい。

・サービス加入を担当するパス発行者または他のモビリティサービス提供者：係る提供者は、先にも説明したように、サービス加入／購入に関する顧客／乗客の機微情報を有する。個人データを含むこの機微情報は保護されるべきであり、ブロックチェーンのブロックに書き込むために仮名化が必要である。

・チケット発行者／輸送事業者：チケット発行者／輸送事業者は、輸送規則に従って関連情報を保持する。輸送のタイプ（例えば、航空路、鉄道、バス等）およびチケットのタイプ（例えば、登録された乗客のみ）に応じて、必要な情報は異なり得る。輸送事業者は不要な情報にアクセスしない。この場合、ブロックチェーンのブロックに書き込むために仮名化が必要である。

・第三者によるデータ解析：第三者は機微情報にアクセスしてはならない。したがって、第三者は、個人情報を識別可能であってはならず、仮名化されたデータにアクセスしてはならない。したがって、この場合、データアクセス前に匿名化が必要となる。

・乗客：乗客は自身の情報を制御する権利および情報を削除する権利を有するが、乗客は他の乗客情報にアクセスすることは許可されず、乗客はブロックチェーンまたは分散型台帳に直接アクセスすることはできない。

・緊急公共安全：公共安全当局は、緊急事態の場合、乗客のフル情報にアクセスすることができる。乗客のフル情報にアクセスするには、特別な暗号鍵が必要である。

上述のように、いくつかの実施形態では、許可型ブロックチェーンが実現され、許可型ブロックチェーン、例えば、コンソーシアムでは、許可されたエンティティのみが分散型台帳／ブロックチェーンにアクセスすることができる。

理論的には、コンソーシアムのセキュリティレベルが公共のブロックチェーンよりも高い。しかしながら、いくつかの実施形態では、別個の鍵による暗号化がアクセス制御にとっても有益である。

次に、図１１を参照して、暗号化を利用してブロックチェーンへのアクセス制御を行う方法８０の一実施形態について説明する。

第１に、機微データは、ユーザプロファイルデータに関連付けられたユーザと契約するＭａａＳ提供者にのみ知られている第１の鍵８１（マスター鍵）で暗号化されるべきである。この鍵は緊急事態を除き、他のＭａａＳ提供者または第三者と共有すべきではない。したがって、データは他のユーザと共有されない。この鍵は外部のサーバ／ネットワークに分散されないため、本実施形態では、秘密鍵暗号化が好ましい。ユーザ管理機能８２はユーザプロファイル管理機能８２ａおよび乗客旅行管理機能８２ｂを有し、乗客旅行データ（機微データ）および乗客旅行データ（機微データでないデータ）は、互いに分離され、別々に処理することもできる。

ユーザ管理機能８２はブロックチェーン管理機能８３と通信し、ブロックチェーン管理機能８３は一以上のブロックチェーン８４と通信する。

本実施形態では、機微データを保護するために、ユーザ管理機能８２とブロックチェーン管理機能８３との間にファイアウォール８５が設けられ、ユーザ管理機能８２およびブロックチェーン管理機能８３は異なるエンティティ、例えば、異なるサーバまたは他のコンピューティングデバイス上に配置することができる。上述したように、マスター鍵８１は機微データがファイアウォール８５および暗号化を介して保護されるように、機微データを暗号化するために用いられる。

第２に、ＭａａＳ提供者は、第２の鍵８６（サービス提供者鍵）を生成する。この第２の鍵８６は他のＭａａＳ提供者と共有することができ、ブロックチェーンに、すなわち、ブロックチェーン管理機能８３によってブロックチェーン８４内のブロックに格納されたデータの暗号化に用いることができる。

ブロックチェーン８４へのアクセスを有するメンバーが高度に信頼され、メンバー数がそれほど多くないか、または（例えば、コンソーシアムにおいて）メンバーが頻繁に変化しない場合、秘密鍵暗号化は依然として好ましい。

例えば、同じ鍵を長期間用いることができる。あるいは、いくつかの実施形態では、このような場合、鍵の分散を回避することができる、鍵を用いない特定のシーケンスジェネレータを用いたスクランブリングだけでも可能である。

メンバーが信頼できない場合、または、ブロックチェーンが海外に格納されている等、特定の理由がある場合は、公開鍵暗号化を利用する必要がある。

他のモビリティサービス提供者も、ファイアウォール８９を介して第三者のブロックチェーン管理機能８８から分離されたブロックチェーン管理機能８７を介してブロックチェーン８４にアクセスする。

さらに、第三者と共有される第３の鍵９０が提供され、第三者は、第３の鍵９０で保護されたブロックチェーンの情報にアクセスすることができる。

ここで、ブロックチェーンにおけるデータ保護の原理を、図１２を参照してより詳細に説明する。

ここでは、上述のように、ＭａａＳ事業者９５が乗客と契約を結んでいるものとするため、ＭａａＳ事業者９５も乗客の機微情報やデータを有する。

輸送事業者／輸送事業者＃１は乗客とのＭａａＳ事業者契約に基づいてチケット９６を発行するが、輸送事業者＃１は乗客情報の詳細を有していない。

ＭａａＳ事業者は乗客情報の詳細、すなわち機微情報を有し、輸送事業者＃１によって発行されたチケットに当該情報を挿入し、ここで、特定の輸送事業者、この場合は輸送事業者＃１の公開鍵暗号化で暗号化される。この情報は上述のように、ブロックチェーンのチケット９６を含むブロックに格納される。

図１２から分かるように、本実施形態では、各輸送事業者に対して、独自の公開鍵が提供され、ここではＭａａＳ事業者が全ての公開鍵を事前に有すると想定する。

輸送機関／事業者＃１は、ブロックチェーンから受信したブロック内の保護されたデータを、独自の秘密鍵で暗号化を解除することができる。秘密の秘密鍵は、他の輸送事業者と共有されていない。

したがって、他の輸送事業者または第三者であっても、本実施形態では、ブロックにアクセスすることができるが、その秘密の秘密鍵が異なるため、保護されたデータの暗号化を解除することはできない。

いくつかの実施形態では、原則として、データはオープンデータである。したがって、第３の鍵（図１１参照）はデータ解析（例えば、統計、ビッグデータ解析等）のために他の第三者と共有されるべきである。

以下では、図１３を参照して、第三者用のオープンデータアクセスに関する実施形態について説明する。

ここで、一般的に、輸送事業者は、オープンデータ用の第三者公開鍵１００を有する。第三者秘密鍵１００は、データ解析のためにデータの利用を望む複数の第三者と共有される。輸送事業者＃１は、ブロック１０１として示されているブロックに、第三者鍵に基づくオープンデータの暗号化と共にデータを挿入する。第三者の一以上はオープンデータのために、第三者秘密鍵１００を用いてオープンデータの暗号化を解除することができるが、上記のように、例えば、モビリティサービス提供者にのみ知られている秘密鍵を用いて暗号化されている保護データの暗号化を解除することはできない。

二以上の第三者鍵が用いられる場合、いくつかの実施形態では、（データ機微性のレベルに応じて）マルチレベルアクセス制御、または（第三者の属するグループに応じて）特定のグループのアクセス制御を行うことが可能である。

いくつかの実施形態では、ブロック内の保護されたデータ（すなわち、機微データ）を匿名化することができる。例えば、図１４にも示されるように、いくつかの実施形態では、匿名化されたデータおよびオープンデータがブロックチェーン内で組み合わされる。

ここで、輸送事業者＃１（チケット発行者）は、図１０を参照して説明したように、ソルトおよびハッシュ方法を用いて匿名化されたデータ（例えば、乗客名）を生成し、ブロックチェーン用のブロック１０５に入力される。このブロック１０５はまた、第３の公開鍵で暗号化されるオープンデータ（例えば、行き先）を有する。さらに、チケット番号およびチケット発行者＃１は、先にも説明したように、ブロックに格納される。

第３の公開／秘密鍵は他者と共有され、ブロック１０５内のオープンデータの暗号化解除に用いることができるが、匿名化されたデータは上述のように、暗号化を解除することができず、識別することもできない。

いくつかの実施形態は、図１５に示すＡＰＩ１１０等のアプリケーションプログラムインタフェース（ＡＰＩ）に関する。

図１５は基本的に図１１に対応し、同一の参照符号は、同一のエンティティおよび機能を示す。図１１の実施形態と図１５の実施形態との間の唯一の違いは、図１５の実施形態において、ビッグデータ解析機能１１１のために第三者によってアクセスされ得るＡＰＩも提供するビッグデータ用のデータベース１１０が提供されることである。

ビッグデータ用のデータベース１１０に記憶された輸送統計／データは、公共目的および商業目的に有用であり得る。例えば、政府は当該データを都市計画に用いることができ、民間企業は、当該データに基づいて新しい店舗の場所を決定することができる。本実施形態のビッグデータは一般的にアクセス可能であり、データは、より広い第三者用のオープンアプリケーションインタフェース（ＡＰＩ）１１０で利用可能である。

モビリティサービス提供者に代わって、モビリティサービス提供者または信頼できるデータベース提供者は、機微情報なしでデータベース１１０にデータを格納する。モビリティサービス提供者または信頼できるデータベース提供者は、外部の第三者にデータベースにアクセスするＡＰＩ１１０を提供する。外部の第三者は、鍵なし（オプションで鍵付き）でデータベース１１０にアクセスできる。

ＡＰＩ１１０は悪意のあるアクセスを防止するために、同一性確認を含んでもよい。例えば、ＡＰＩはＯＡｕｔｈ２．０（ＲＦＣ６７４９）（https://oauth.net/2/）等の認証プロトコルをサポートしてもよい。

いくつかの実施形態では、機微データをブロックチェーンから消去することができ、以下では機微データの消去に関する実施形態を図１６および図１７を参照して説明する。

一般的に、ブロックチェーンは、本来、永続的にデータを記憶することを意図しているため、データを消去することができないように実現される。

図１７にも示す第１の実施形態では、ブロックチェーンから機微データを消去する方法１１５によって、ブロックチェーン内の機微データまたは消去済みデータが保持されるが、鍵は無効化される。

ただし、データがブロックチェーン内に保留されている場合でも、暗号化を解除する鍵がない場合はデータを消去することと同等である。ただし、これは厳密な意味での消去ではない。これはデータがまだ存在するためであるが、暗号化を解除することはできなくなる。

本実施形態では、ブロックチェーンホスト管理１１６（典型的には乗客と契約するＭａａＳ提供者）があると想定する。あるメンバーは、１１７でデータの消去を要求し、他のメンバーはブロックチェーンとデータ解読用の鍵とを有する。

つまり、方法１１５の流れは以下の通りである。

１１７において、上述のように、モビリティサービス提供者のコンソーシアムのメンバーのうちの１人または複数が、ブロック内の個人データ（または任意の機微データ）をホスト１１６に削除するように要求する。

ホスト１１６は、１１８において、コンソーシアムの他のブロックチェーンメンバーに鍵の無効化の要求を送信／散布する。

１１９において、他のブロックチェーンメンバーは鍵を削除し、１２０において、ホスト１１６に肯定応答を送信する。

１２１において、ホストは、データ消去の確認を要求者に送信する。

鍵を無効化するための様々な方法が存在する。いくつかの実施形態では、鍵がタイマーまたは有効時間／日時を有し（またはデータ自体が有効時間タイマーを有する）、鍵は時間／日時が期限切れになった後に自動的に削除されてもよく、または暗号化解除アルゴリズムが時間／日時が期限切れになった後に鍵を拒絶してもよい。

ブロックチェーンから機微データを消去する方法１２５の別の実施形態が図１７に示されており、ブロックチェーンはコンソーシアムメンバーの合意の後に消去され、同一の参照符号は同一のエンティティおよび機能または方法ステップを示す。

有利には、許可ブロックチェーン（コンソーシアム型）ではコンソーシアムのメンバー内でブロックチェーンを自由に管理することが可能である。

図１６の実施形態について既に説明したように、ブロックチェーン管理ホスト１１６（典型的には、乗客と契約するＭａａＳ提供者）が存在すると想定する。

コンソーシアムのメンバーのうちの１人は（機微）データを消去することを要求し、別のメンバーは、ブロックチェーンおよびそのための関連の鍵を有する。

したがって、フローは以下の通りである。

１１７において、一（または複数）のメンバーが、ブロック内の個人データ（または任意の機微データ）をホスト１１６に削除することを要求する。

１１８'において、ホスト１１６はブロックの消去要求を他のブロックチェーンメンバーに送信／散布し、当該要求は、ブロックの特定の部分、複数のブロック、またはブロックチェーンの全ての部分（すなわち、ブロックチェーン全体）を消去することであってもよい。

他のブロックチェーンメンバーは、当該要求が許容可能であるか否かを確認する。許容可能であれば、１２６において、ホスト１１６にコンセンサスコマンドを送信する。例えば、収益分担計算がまだ終了していない場合、他のメンバーは拒絶または待機コマンドを送信することができる。

１２７において、１２６で受信されたコマンドに基づいて、コンセンサスがあるかどうかが確認される。ブロックの削除にコンセンサスがある場合、ホストはブロックを削除するためにそれぞれのコマンド１２７ａを送信／散布するが、それ以外の場合はブロックチェーンは消去されない。各メンバーは、１２７ｂのコマンドに従ってブロックを削除する。

１２８において、メンバーはブロック削除の成功応答をホスト１１６に送信し、１２９において、ホストは、データ消去の確認を要求者に送信する。

一般的に、上述したように、ハッシュ関数を用いたデータの匿名化が知られている。匿名化エンジンでは、ユーザＩＤや個人識別子を匿名化されたデータに変換することができる。匿名化されたデータは、集約され、中央モジュールに記憶され得る。匿名化によって、データマイニングを行う者によってデータ内の個人が識別されることが防止される。いくつかの実施形態では、本明細書に記載されるように、そのような匿名化はブロックチェーンまたは分散型台帳に適用される。

さらに、上述のように、機微データをブロックチェーンまたは分散型台帳に格納することが一般的に知られているが、本開示では、いくつかの実施形態において、データを機微部分と非機微部分とに分割し、機微部分をブロックチェーンに格納しないようにする。

以下では、汎用コンピュータ１３０の一実施形態を、図１８を参照して説明する。コンピュータ１３０は基本的に、本明細書で説明するように、任意のタイプのネットワーク機器、例えば、基地局または新しい無線基地局、送受信ポイント、またはユーザ機器（エンド）端末装置等の通信デバイスとして機能することができるように実現することができる。コンピュータは本明細書に記載されるように、ネットワーク装置および通信装置の回路のうちの任意の１つ等の回路を形成することができる構成要素１３１～１４１を有する。

ソフトウェア、ファームウェア、プログラム等を用いて本明細書に記載されている方法を実行する実施形態はコンピュータ１３０にインストールすることができ、これらは、次いで、具体的な実施形態に適するように構成される。

コンピュータ１３０は、例えば、ＲＯＭ（Read-Only Memory）１３２に記憶され、記憶部１３７に記憶され、かつＲＡＭ（Random Access Memory）１３３にロードされ、各駆動部１３９に投入可能な記録媒体１４０に記憶されるプログラムに従って、本明細書に記載されるような様々な手順および方法を実行するＣＰＵ（Central Processing Unit）１３１を有する。

ＣＰＵ１３１、ＲＯＭ１３２およびＲＡＭ１３３にはバス１４１が接続されており、入出力インタフェース１３４に接続されている。ＣＰＵ、メモリ、およびストレージの数は単に例示的なものであり、当業者であれば、コンピュータ１３０は、基地局としてまたはユーザ機器（エンド端末）として機能するときに生じる特定の要件を満たすように適応および構成され得ることが理解されるであろう。

入出力インタフェース１３４には、記録媒体１４０（コンパクトディスク、デジタルビデオディスク、コンパクトフラッシュメモリ等）を挿入することができる入力部１３５、出力部１３６、記憶部１３７、通信インタフェース１３８、および駆動部１３９のいくつかの構成要素が接続される。

入力部１３５は、ポインティングデバイス（マウス、グラフィックテーブル等）、キーボード、マイク、カメラ、タッチスクリーン等とすることができる。

出力部１３６は、ディスプレイ（液晶ディスプレイ、陰極線管ディスプレイ、発光ダイオードディスプレイ等）、スピーカ等とすることができる。

記憶部１３７は、ハードディスク、ソリッドステートドライブ等とすることができる。

通信インタフェース１３８は例えば、ローカルエリアネットワーク（ＬＡＮ）、無線ＬＡＮ（ＷＬＡＮ）、移動体電気通信システム（ＧＳＭ、ＵＭＴＳ、ＬＴＥ、ＮＲ等）、Ｂｌｕｅｔｏｏｔｈ、赤外線等を介して通信するように構成することができる。

上記の説明は、コンピュータ１３０の構成例にのみ関係することに留意されたい。代替の構成は、追加のまたは他のセンサ、記憶デバイス、インタフェース等を用いて実現されてもよい。例えば、通信インタフェース１３８は、言及されたＵＭＴＳ、ＬＴＥ、およびＮＲ以外の他の無線アクセス技術をサポートしてもよい。

コンピュータ１３０が基地局として機能する場合、通信インタフェース１３８はそれぞれのエアインタフェース（例えば、Ｅ－ＵＴＲＡプロトコルＯＦＤＭＡ（ダウンリンク）およびＳＣ－ＦＤＭＡ（アップリンク）を提供する）およびネットワークインタフェース（例えば、Ｓ１－ＡＰ、ＧＴＰ－Ｕ、Ｓ１－ＭＭＥ、Ｘ２－ＡＰ等のプロトコルを実現する）をさらに有することができる。さらに、コンピュータ１３０は、一または複数のアンテナおよび／またはアンテナアレイを有することができる。本開示は、係るプロトコルのいかなる特殊性にも限定されない。

図１９を参照して、本開示の実施形態を実現するために用いられる、ユーザ機器ＵＥ１５０およびｅＮＢ１５５（またはＮＲｅＮＢ／ｇＮＢ）、ならびにＵＥ１５０とｅＮＢ１５５との間の通信路１５４の実施形態について説明する。ＵＥ１５０は通信デバイスの一例であり、ｅＮＢは基地局（すなわち、ネットワーク機器）の一例であるが、この点に関して本開示を限定するものではない。

ＵＥ１５０は、送信部１５１、受信部１５２、および制御部１５３を有し、ここで、一般的に、送信部１５１、受信部１５２、および制御部１５３の技術的機能は当業者には周知であるため、その詳細な説明は省略する。

ｅＮＢ１５５は、送信部１５６と、受信部１５７と、制御部１５８とを有し、ここでも、一般的に、送信部１５６と、受信部１５７と、制御部１５８との機能は当業者には周知であるため、その詳細な説明は省略する。

通信路１５４は、ＵＥ１５０からｅＮＢ１５５へのアップリンク経路１５４ａと、ｅＮＢ１５５からＵＥ１５０へのダウンリンク経路１５４ｂとを有する。

動作中、ＵＥ１５０の制御部１５３は受信部１５２でダウンリンク経路１５４ｂを介してダウンリンク信号の受信を制御し、制御部１５３は送信部１５１を介してアップリンク経路１５４ａを介してアップリンク信号の送信を制御する。

同様に、動作中、ｅＮＢ１５５の制御部１５８は送信部１５６を介してダウンリンク経路１５４ｂを介してダウンリンク信号の送信を制御し、制御部１５８は受信部１５７においてアップリンク経路１５４ａを介してアップリンク信号の受信を制御する。

さらに要約すると、説明から明らかなように、いくつかの実施形態はデータを分散型台帳に提供する通信ネットワークノードに関し、ノードは機微ユーザデータ（例えば、乗客、氏名、住所、電話番号、性別、年齢、旅券番号、クレジットカード番号等）と非機微ユーザデータ（旅行データまたは旅行の統計等）とを分離し、非機微ユーザデータを分散型台帳に提供するためのユーザデータ管理部を提供するように構成される回路を有する。通信ネットワークノードは基地局、ｅＮｏｄｅＢ等のネットワーク機器であってもよいが、ノードはそれに応じて構成される回路を有するユーザ機器、（エンド）端末デバイス等（例えば、携帯電話、スマートフォン、コンピュータ、ラップトップ、ノートブック等）の通信デバイスとして構成されてもよい。

いくつかの実施形態では、回路は、機微ユーザデータをノードのデータベースに格納するようにさらに構成され、したがって、ノードはデータベースを含むことができ、またはデータベースに接続または関連付けることができる。

いくつかの実施形態では、分散型台帳は、ブロックチェーンを含み（またはブロックチェーンであり）、ブロックチェーンは複数のブロックを含むことができ、ブロックは非機微ユーザデータを含む。

したがって、いくつかの実施形態では、機微ユーザデータは、ノードのデータベースにのみ格納され、分散型台帳またはブロックチェーンは非機微データのみを含む。

いくつかの実施形態では、分散型台帳は、モビリティサービス用のデータを含む。

いくつかの実施形態では、分散型台帳へのアクセスが許可権に基づいて許可され、ノードはコンソーシアムの一部であってもよい。コンソーシアムは、モビリティサービス提供者によって提供されてもよく、ここで、各ノードは例えば、１つのモビリティサービス提供者に対応するか、またはそれに関連付けられてもよい。

いくつかの実施形態は分散型台帳を提供するための複数のノードを有する通信ネットワークに関し、少なくとも１つのノードは機微ユーザデータと非機微ユーザデータとを分離し、非機微ユーザデータを分散型台帳に提供するためのユーザデータ管理部を提供するように構成された回路を有する。

通信ネットワークは電気通信ネットワークとして構成することができ、電気通信ネットワークは、移動電気通信ネットワークとして構成することができる。通信ネットワークのノードは、分散型台帳を提供するように構成してもよい。

いくつかの実施形態では、上述のように、回路は、機微ユーザデータをノードのデータベースに格納するようにさらに構成される。

上述のように、分散型台帳はブロックチェーンを含むことができ、ブロックチェーンは複数のブロックを含むことができ、ブロックは非機微ユーザデータを含み、分散型台帳はモビリティサービス用のデータを含むことができる。したがって、いくつかの実施形態では、通信ネットワークとそのノードはＭａａＳを提供するように構成される。

いくつかの実施形態では、分散型台帳へのアクセスが許可権に基づいて許可され、ノードはコンソーシアム（例えば、ＭａａＳコンソーシアム）の一部であってもよい。

いくつかの実施形態では、分散型台帳内の個人ユーザデータ（例えば、ユーザを一意に識別する可能性のある氏名または他のデータ）は仮名化または匿名化される。個人ユーザデータは上述のように、例えば、航空券の場合、乗客名が搭乗のために知られているため、分散型台帳に入力することができる。

いくつかの実施形態では、個人ユーザデータが機微ユーザデータをスクランブリングすることによって仮名化され、個人ユーザデータはハッシュアルゴリズムを適用することに基づいて匿名化されてもよい。

いくつかの実施形態では、非機微データに対するアクセス制御が提供され、アクセス制御は鍵に基づいて実行されてもよく、鍵は非機微データの暗号化に用いられる。

いくつかの実施形態では、アクセス制御によって、それぞれ異なる団体がそれぞれ異なるレベルでアクセス可能なように、それぞれ異なる団体にそれぞれ異なる鍵が提供される。それぞれ異なる団体は、例えば、機微データを有するノード、分散型台帳にアクセスする他のノード（例えば、コンソーシアムの一部であってもよい）、機微データを有しない第三者、分散型台帳にアクセスしない第三者、またはコンソーシアムの一部ではない第三者であってもよく、ＭａａＳを提供しない、または、データ解析のためにデータを単に必要とする。

いくつかの実施形態では、アクセス制御によって、アプリケーションプログラムインタフェースを介して非機微データへのアクセスが可能である。

いくつかの実施形態では、（個人ユーザデータまたは非機微ユーザデータが少なくとも１つのノードからの要求に応じて消去することができ、データは鍵の無効化によって、または分散型台帳からのデータの消去（全てのデータの消去を含む）によって消去することができる。上述のように、分散型台帳はブロックチェーンを含むことができ、少なくとも１つのブロックを消去することができる（消去される個人データを含む）。

いくつかの実施形態は（本明細書に記載するように）分散型台帳を提供するための複数のノードを有する通信ネットワークを制御する方法に関し、当該方法は、上記で詳述したように、機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部分を提供することと、非機微ユーザデータを分散型台帳に提供することとを含む。例えば、通信ネットワークおよび／または通信ネットワークノードによって実行される、本明細書に記載の全てのステップは、当該方法の一部であってもよい。

本明細書に記載の方法はいくつかの実施形態では、コンピュータおよび／またはプロセッサおよび／または回路上で実行する場合、コンピュータおよび／またはプロセッサおよび／または回路に当該方法を実行させるコンピュータプログラムとしても実現される。いくつかの実施形態では、上述のプロセッサ等のプロセッサによって実行する場合、本明細書に記載の方法を実行させるコンピュータプログラム製品を記憶する、非一時的なコンピュータ可読記録媒体も提供される。

実施形態は、方法ステップの例示的な順序付けを伴う方法を説明することを理解されたい。しかしながら、方法ステップの特定の順序付けは、例示のみを目的としてなされたものであり、拘束力のあるものとして解釈されるべきではない。

本明細書に記載され、添付の特許請求の範囲に請求される全てのユニットおよびエンティティは別段の記載がない限り、例えば、チップ上の集積回路ロジックとして実現することができ、そのようなユニットおよびエンティティによって提供される機能は別段の記載がない限り、ソフトウェアによって実現することができる。

上述の開示の実施形態が少なくとも部分的に、ソフトウェア制御されたデータ処理装置を使用して実施される限り、そのようなソフトウェア制御を提供するコンピュータプログラム、およびそのようなコンピュータプログラムを提供する伝送装置、ストレージ、または他の媒体が、本開示の態様として想定されることが理解されるであろう。

なお、本技術は以下のような構成も採ることができる。
（１） データを分散型台帳に提供するための通信ネットワークノードであって、
機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、
上記非機微ユーザデータを上記分散型台帳に提供する
ように構成される回路
を有する
通信ネットワークノード。
（２） （１）に記載の通信ネットワークノードであって、
上記回路は、上記機微ユーザデータを上記ノードのデータベースに記憶するようにさらに構成される
通信ネットワークノード。
（３） （１）または（２）に記載の通信ネットワークノードであって、
上記分散型台帳は、ブロックチェーンを含む
通信ネットワークノード。
（４） （３）に記載の通信ネットワークノードであって、
上記ブロックチェーンは、上記非機微ユーザデータを含む複数のブロックを含む
通信ネットワークノード。
（５） （１）乃至（４）のいずれか一項に記載の通信ネットワークノードであって、
上記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含む
通信ネットワークノード。
（６） （１）乃至（５）のいずれか一項に記載の通信ネットワークノードであって、
上記分散型台帳へのアクセス許可権に基づいて許可される
通信ネットワークノード。
（７） （６）に記載の通信ネットワークノードであって、
上記ノードは、コンソーシアムの一部である
通信ネットワークノード。
（８） 分散型台帳を提供するための複数のノードを有する通信ネットワークであって、
上記複数のノードの少なくとも一のノードは、
機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、
上記非機微ユーザデータを上記分散型台帳に提供する
ように構成される回路を有する
通信ネットワーク。
（９） （８）に記載の通信ネットワークであって、
上記回路は、上記機微ユーザデータを上記ノードのデータベースに記憶するようにさらに構成される
通信ネットワーク。
（１０） （８）または（９）に記載の通信ネットワークであって、
上記分散型台帳は、ブロックチェーンを含む
通信ネットワーク。
（１１） （１０）に記載の通信ネットワークであって、
上記ブロックチェーンは、上記非機微ユーザデータを含む複数のブロックを含む
通信ネットワーク。
（１２） （８）乃至（１１）のいずれか一項に記載の通信ネットワークであって、
上記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含む
通信ネットワーク。
（１３） （８）乃至（１２）のいずれか一項に記載の通信ネットワークであって、
上記分散型台帳へのアクセス許可権に基づいて許可される
通信ネットワーク。
（１４） （１３）に記載の通信ネットワークであって、
上記ノードは、コンソーシアムの一部である
通信ネットワーク。
（１５） （８）乃至（１４）のいずれか一項に記載の通信ネットワークであって、
上記分散型台帳内の個人ユーザデータは、仮名化または匿名化される
通信ネットワーク。
（１６） （１５）に記載の通信ネットワークであって、
上記個人ユーザデータは、上記機微ユーザデータに対してスクランブリングを実行することによって仮名化される
通信ネットワーク。
（１７） （１５）に記載の通信ネットワークであって、
上記個人ユーザデータは、ハッシュアルゴリズムを適用することによって匿名化される
通信ネットワーク。
（１８） （８）乃至（１７）のいずれか一項に記載の通信ネットワークであって、
上記非機微データに対するアクセス制御が実行される
通信ネットワーク。
（１９） （１８）に記載の通信ネットワークであって、
上記アクセス制御は、上記非機微データの暗号化に用いられる鍵に基づいて実行される
通信ネットワーク。
（２０） （１９）に記載の通信ネットワークであって、
上記アクセス制御によって、それぞれ異なる団体に対してそれぞれ異なる鍵が提供される
通信ネットワーク。
（２１） （１８）乃至（２０）のいずれか一項に記載の通信ネットワークであって、
上記アクセス制御によって、アプリケーションプログラミングインタフェースを介して上記非機微データへのアクセスが可能とされる
通信ネットワーク。
（２２） （８）乃至（２１）のいずれか一項に記載の通信ネットワークであって、
個人ユーザデータまたは上記非機微ユーザデータは、少なくとも一のノードからの要求に応じて消去可能である
通信ネットワーク。
（２３） （２２）に記載の通信ネットワークであって、
データは、鍵の無効化によって消去される
通信ネットワーク。
（２４） （２２）に記載の通信ネットワークであって、
上記データは、データを上記分散型台帳から消去することによって消去される
通信ネットワーク。
（２５） （２４）に記載の通信ネットワークであって、
上記分散型台帳はブロックチェーンを含み、少なくとも一のブロックは消去される
通信ネットワーク。
（２６） 分散型台帳を提供するための複数のノードを有する通信ネットワークを制御する方法であって、
機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を用意し、
上記非機微ユーザデータを上記分散型台帳に提供する
方法。
（２７） （２６）に記載の方法であって、さらに
上記機微ユーザデータをノードのデータベースに記憶する
方法。
（２８） （２６）または（２７）に記載の方法であって、
上記分散型台帳は、ブロックチェーンを含む
方法。
（２９） （２８）に記載の方法であって、
上記ブロックチェーンは、上記非機微ユーザデータを含む複数のブロックを含む
方法。
（３０） （２６）乃至（２９）のいずれか一項に記載の方法であって、
上記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含む
方法。
（３１） （２６）乃至（３０）のいずれか一項に記載の方法であって、
上記分散型台帳へのアクセス許可権に基づいて許可される
方法。
（３２） （３１）に記載の方法であって、
上記ノードは、コンソーシアムの一部である
方法。
（３３） （２６）乃至（３２）のいずれか一項に記載の方法であって、
上記分散型台帳内の個人ユーザデータは、仮名化または匿名化される
方法。
（３４） （３３）に記載の方法であって、
上記個人ユーザデータは、上記機微ユーザデータに対してスクランブリングを実行することによって仮名化される
方法。
（３５） （３３）に記載の方法であって、
上記個人ユーザデータは、ハッシュアルゴリズムを適用することによって匿名化される
方法。
（３６） （２６）乃至（３５）のいずれか一項に記載の方法であって、
上記非機微データに対するアクセス制御が実行される
方法。
（３７） （３６）に記載の方法であって、
上記アクセス制御は、上記非機微データの暗号化に用いられる鍵に基づいて実行される
方法。
（３８） （３７）に記載の方法であって、
上記アクセス制御によって、それぞれ異なる団体に対してそれぞれ異なる鍵が提供される
方法。
（３９） （３６）乃至（３８）のいずれか一項に記載の方法であって、
上記アクセス制御によって、アプリケーションプログラミングインタフェースを介して上記非機微データへのアクセスが可能とされる
方法。
（４０） （２６）乃至（３９）のいずれか一項に記載の方法であって、
個人ユーザデータまたは上記非機微ユーザデータは、少なくとも一のノードからの要求に応じて消去可能である
方法。
（４１） （４０）に記載の方法であって、
データは、鍵の無効化によって消去される
方法。
（４２） （４０）に記載の方法であって、
上記データは、データを上記分散型台帳から消去することによって消去される
方法。
（４３） （４２）に記載の方法であって、
上記分散型台帳はブロックチェーンを含み、少なくとも一のブロックは消去される
方法。

Claims (23)

1. データを分散型台帳に提供するための通信ネットワークノードであって、
   前記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含み、
   データベースと回路を有し、
   前記回路は、
   機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、
   前記機微ユーザデータを前記データベースに記憶するように提供し、
   前記非機微ユーザデータを前記分散型台帳に提供し、
   前記機微ユーザデータの内、ユーザである乗客の個人情報を不可逆的に仮名化又は匿名化し、
   不可逆的に仮名化又は匿名化した前記個人情報を、前記ＭａａＳ用データに追加するように提供する
   ように構成される
   通信ネットワークノード。
2. 請求項１に記載の通信ネットワークノードであって、
   前記分散型台帳は、ブロックチェーンを含む
   通信ネットワークノード。
3. 請求項２に記載の通信ネットワークノードであって、
   前記ブロックチェーンは、前記非機微ユーザデータを含む複数のブロックを含む
   通信ネットワークノード。
4. 請求項１に記載の通信ネットワークノードであって、
   前記分散型台帳へのアクセスが許可権に基づいて許可される
   通信ネットワークノード。
5. 請求項４に記載の通信ネットワークノードであって、
   前記通信ネットワークノードは、コンソーシアムの一部である
   通信ネットワークノード。
6. 分散型台帳を提供するための複数のノードを有する通信ネットワークであって、
   前記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含み、
   前記複数のノードの少なくとも一のノードは、
   データベースと回路を有し、
   前記回路は、
   機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を提供し、
   前記機微ユーザデータを前記データベースに記憶するように提供し、
   前記非機微ユーザデータを前記分散型台帳に提供し、
   前記機微ユーザデータの内、ユーザである乗客の個人情報を不可逆的に仮名化又は匿名化し、
   不可逆的に仮名化又は匿名化した前記個人情報を、前記ＭａａＳ用データに追加するように提供する
   ように構成される
   通信ネットワーク。
7. 請求項６に記載の通信ネットワークであって、
   前記分散型台帳は、ブロックチェーンを含む
   通信ネットワーク。
8. 請求項７に記載の通信ネットワークであって、
   前記ブロックチェーンは、前記非機微ユーザデータを含む複数のブロックを含む
   通信ネットワーク。
9. 請求項６に記載の通信ネットワークであって、
   前記分散型台帳へのアクセスが許可権に基づいて許可される
   通信ネットワーク。
10. 請求項９に記載の通信ネットワークであって、
    前記ノードは、コンソーシアムの一部である
    通信ネットワーク。
11. 請求項６に記載の通信ネットワークであって、
    前記非機微ユーザデータに対するアクセス制御が実行される
    通信ネットワーク。
12. 請求項１１に記載の通信ネットワークであって、
    前記アクセス制御は、前記非機微ユーザデータの暗号化に用いられる鍵に基づいて実行される
    通信ネットワーク。
13. 請求項１１に記載の通信ネットワークであって、
    前記アクセス制御によって、それぞれ異なる団体に対してそれぞれ異なる鍵が提供される
    通信ネットワーク。
14. 請求項１１に記載の通信ネットワークであって、
    前記アクセス制御によって、アプリケーションプログラミングインタフェースを介して前記非機微ユーザデータへのアクセスが可能とされる
    通信ネットワーク。
15. 分散型台帳を提供するための複数のノードを有する通信ネットワークを制御する方法であって、
    前記分散型台帳は、ＭａａＳ（Mobility as a Service）用データを含み、
    機微ユーザデータと非機微ユーザデータとを分離するためのユーザデータ管理部を用意し、
    前記機微ユーザデータをデータベースに記憶するように提供し、
    前記非機微ユーザデータを前記分散型台帳に提供し、
    前記機微ユーザデータの内、ユーザである乗客の個人情報を不可逆的に仮名化又は匿名化し、
    不可逆的に仮名化又は匿名化した前記個人情報を、前記ＭａａＳ用データに追加するように提供する
    方法。
16. 請求項１５に記載の方法であって、
    前記分散型台帳は、ブロックチェーンを含む
    方法。
17. 請求項１６に記載の方法であって、
    前記ブロックチェーンは、前記非機微ユーザデータを含む複数のブロックを含む
    方法。
18. 請求項１５に記載の方法であって、
    前記分散型台帳へのアクセスが許可権に基づいて許可される
    方法。
19. 請求項１８に記載の方法であって、
    前記ノードは、コンソーシアムの一部である
    方法。
20. 請求項１５に記載の方法であって、
    前記非機微ユーザデータに対するアクセス制御が実行される
    方法。
21. 請求項２０に記載の方法であって、
    前記アクセス制御は、前記非機微ユーザデータの暗号化に用いられる鍵に基づいて実行される
    方法。
22. 請求項２１に記載の方法であって、
    前記アクセス制御によって、それぞれ異なる団体に対してそれぞれ異なる鍵が提供される
    方法。
23. 請求項２１に記載の方法であって、
    前記アクセス制御によって、アプリケーションプログラミングインタフェースを介して前記非機微ユーザデータへのアクセスが可能とされる
    方法。