JP2024512406A - リソースの管理権を安全に設定するシステム及び方法 - Google Patents

Abstract

分散台帳におけるリソースの管理権を安全に設定するためのコンピュータ実装方法及びシステムが開示される。分散台帳は、第１のシステムの１又は２以上の第１のプロセッサ（複数可）上にインスタンス化された第１のシャードを備える。第１のシャードは、第１の当事者を起点とするから命令に応答するように構成される。分散台帳は、１又は２以上の第２のプロセッサ（複数可）上にインスタンス化され、第２の当事者を起点とする命令に応答するように構成された第２のシャードをさらに備える。本方法は、第１のシステムによるレコードの公開によって、リソースを作成するステップを含み、レコードの公開は、第１の当事者を起点とする命令に応答して生じ、レコードの公開は、分散台帳の第１のシャードに対するものであり、レコードの公開は、リソースの管理権が第２の当事者に属することを設定する。【選択図】 図２

Description

（関連出願）
本発明は、２０２１年３月９日出願の欧州出願番号２１１６１４６９．８の優先権を主張し、その開示内容全体は引用により本明細書に組み込まれる。
（技術分野）
本発明は、一般に通信及び情報セキュリティの技術分野に属する。詳細には、本発明は、リソースの管理権を特定の当事者に安全に設定する方法に関する。

数多くの日常的なシナリオにおいて、リソースの管理権を特定の当事者に設定することが必要である。一般に、本発明の技術分野におけるリソースとは、そのようなリソースを管理する個人又は組織に、特定の権限、権利、特権、又は他の個人又は組織を潜在的に排除するさらなる管理権を提供する何らかのデータ又はデータ構造である。場合によっては、このようなデータ又はデータ構造の管理は、特定の個人又は組織に設定する必要がある。

１つの例は、ウェブサイト又はコンピュータシステムのソースコードである。このようなコードは、当事者を管理することでこのようなデータに対する管理権の形態を設定する手段があって初めてリソースとなるデータである。このような管理権の形態には、読み取り又は書き込みアクセス権、又はウェブサイトからの収益を特定の当事者に向ける能力などが含まれるが、これらに限定されるものではない。

さらに日常的な例として、リソースの管理権を特定の当事者に設定する必要性は、電子予防接種パス又は劇場チケットのような公的文書の準備及び配布時に生じる。一般的に、電子パス又は劇場チケットは、それぞれ中央当局又は公的チケット売り場によって又はそれらを代表して、おそらく個人による又は当局又は売り場が主導の又は別の方法での申請後に作成される。申請者から提供された情報又は当局の発行又は付与プロセスが照合されると、予防接種パス又は劇場チケットのデータ構造が作成され、次に、データ又はデータ構造がその有用性を果たしリソースとなるために、申請者に有利なるようにそれに対する管理権を設定する必要がある。結果として、申請者は、国境を越えて旅行することができる予防接種パスの所持者となる、又は、申請者は劇場公演に参加する権利を有する者となる。これらの例だけでなく、他の多くの例でも、申請者はフルネーム、場合によっては生年月日と出生地、顔写真、他のさまざまな潜在的に繊細で彼／彼女らが広範に広まるのを望まない複数の情報を提供する必要がある。予防接種パス又は劇場チケットは、このようなリソースを受け取った申請者にとっては有用であるが、そのようなリソースに対して管理権のない者にとっては、それほど有用ではない。

リソースの管理権を特定の当事者に設定する必要性の別の例は、航空交通管制のような地理的に分散されたシステムで生じ、このようなシステムでは、シフトの終了時又はフライトが空域を横切って移動する際に別の当事者に引きき継がれる前に、常に特定のフライト区域又はフライト中の特定の航空機の交通管制は、専用の当事者で行われる。

同様のニーズは、電力網システムの分散制御又は特定の分散協力型軍事防衛施設でも生じる。いずれの場合でも、当事者間での特定の管理権の設定及び移転は、他の目的の中でも、安全性及びその移転の最終的状態に関する要求の対象となる。

データ又はデータ構造の形でリソースを分散させるシステム、及びそれらに関連する管理について説明する多種多様の先行技術が存在する。予防接種パス又は劇場チケットの例を続けると、これらのリソースが作成されると、これらは、おそらくユーザが印刷できるようにユーザの電子メールアドレスに送られる。このような配布システムはそれなりに堅牢であり、おそらくは管理の連鎖（ｃｈａｉｎｓ ｏｆ ｃｕｓｔｏｄｙ）に依存するが、リソースに対する有効な管理権は、意図された当事者に到達する前に第３の当事者の手を通過する。例えば、電子メールが傍受され、劇場チケットが他の誰かによって印刷された場合、意図された当事者に対して有効な管理権は設定されない。また、チケットを受け取る前に劇場公演が行われた場合、又はフライトがすでに別の区域に入った後で、飛行管理が別の管理センター又は当事者に譲渡され、一時的に管理不能なフライトが引き起こされる場合など、リソースが役に立たなくなるほどリソースの伝送が遅れる場合もある。これらの欠点は、いずれもリソースの安全な伝送とそれに関連する管理権に対する重大なリスクを意味する。

上記の観点から、先行技術のシステムの欠点がない、リソースの管理権を特定の当事者に安全かつ短い遅延時間で設定する方法に対する必要性が存在する。

本発明の第１の態様によれば、分散台帳におけるリソースの管理権を安全に設定するコンピュータ実装方法が提供され、分散台帳は、第１のシステムの１又は２以上の第１のプロセッサ（複数可）上にインスタンス化された第１のシャードを備え、第１のシャードは、第１の当事者を起点とする命令に応答するように構成され、分散台帳は、第２のシャードをさらに備え、第２のシャードは、１又は２以上の第２のプロセッサ（複数可）上にインスタンス化され、第２のシャードは、第２の当事者を起点とする命令に応答するように構成され、本方法は、
第１のシステムによるレコードの公開によって、リソースを作成するステップを含み、
レコードの公開は、第１の当事者を起点とする命令に応答して生じ、
レコードの公開は、分散台帳の第１のシャードに対するものであり、
レコードの公開は、リソースの管理権が第２の当事者に属することを設定する。

本方法は、命令が第１の当事者を起点とすることを検証するステップをさらに含むことができ、随意的に、検証は第１のシステムに基づく。検証は、命令の起点を示す、パラメータ、データベースエントリ、又は分割台帳エントリの特定の値、又はパラメータ、データベースエントリ、又は分割台帳エントリの存在の照合とすることができる。これらのパラメータ、データベースエントリ、又は分割台帳エントリは、以前に決定された値と比較することができる。

リソースは、第２の当事者（人、人のグループ、会社、組織など）の識別情報の表示を含むことができる。この表示は、本方法のリソースの作成時に作成されるパラメータ、データベースエントリ、又は分割台帳エントリとすることができる。このようなパラメータは、分散台帳上のエントリ内のメタデータの一部を形成することができる。

第１のシャードは、第１の当事者に関連する１又は２以上のレコード（複数可）を含むことができる。第２のシャードは、第２の当事者に関連する１又は２以上のレコード（複数可）を含むことができる。場合によっては、第１のシャードは第１の当事者に関連する１又は２以上のレコード（複数可）を含み、さらに第２のシャードは第２の当事者に関連する１又は２以上のレコード（複数可）を含む。

本方法は、リソースの管理権が第２の当事者に属することを第２の当事者に示すステップをさらに含むことができる。リソースの管理権が第２の当事者に属することを第２の当事者に示すステップは、レコードの公開の通知（及びそれによって新たに作成されたリソースの管理権の設定の通知）を第２の当事者に送ることを含むことができる。通知を送ることは、第１のシステムに基づくことができる。いずれの場合も、第２の当事者が管理するリソースの設定は、そのような通知に先行するか、又はそのような通知と同時である。

１又は２以上の第２のプロセッサ（複数可）は、第２のシステムに含めることができる。このような場合、第２のシステムは、第１のシャード内のレコード（複数可）を検索することができる。

本方法は、第２のシャードの１又は２以上のプロセッサ（複数可）のいずれとも相互作用することなく、第１のシステムによって実行することができる。

本方法は、第１のシャードの１又は２以上のプロセッサ（複数可）だけで実行することができる。

本方法は、第１の当事者がリソースの作成を命令する権限を有することを検証するステップをさらに含むことができる。本方法は、第１の当事者がリソースの作成を命令する能力があることを検証するステップをさらに含むことができる。場合によっては、本方法は、第１の当事者がリソースの作成を命令する権限を有することを検証するステップと、第１の当事者がリソースの作成を命令する能力を有することを検証するステップの両方を含む。

分散台帳の第１のシャード及び第２のシャードの各々は、共有メモリ空間に存在することができ、第１のシステムは、共有メモリ空間にアクセスするように構成することができる。シャードメモリ空間は、論理共有メモリ空間とすることができる。

分散台帳は、ブロックチェーンを含むことができる。

分散台帳は、パブリックとすることができる。

本発明の第２の態様によれば、実行されると、１又は２以上のプロセッサ（複数可）に上述の方法のいずれかを実行させる命令を含む、コンピュータプログラム製品が提供される。

本発明の第３の態様によれば、実行されると、１又は２以上のプロセッサ（複数可）に上述の方法のいずれかを実行させる命令を含む、コンピュータ可読媒体が提供される。

本発明の第４の態様によれば、分散台帳におけるリソースの管理権を安全に設定するシステムが提供され、分散台帳は、第１のシステムの１又は２以上の第１のプロセッサ（複数可）上にインスタンス化された第１のシャードを備え、第１のシャードは、第１の当事者を起点とする命令に応答するように構成され、分散台帳は、第２のシャードをさらに備え、第２のシャードは、１又は２以上の第２のプロセッサ（複数可）上にインスタンス化され、第２のシャードは、第２の当事者を起点とする命令に応答するように構成され、本システムは、第１のシステムによるレコードの公開によって、リソースを作成する第１のシステムを含み、
レコードの公開は、第１の当事者を起点とする命令に応答して生じ、
レコードの公開は、分散台帳の第１のシャードに対するものであり、
レコードの公開は、リソースの管理権が第２の当事者に属することを設定する。

本発明は、添付の図面を参照して以下に説明される。

従来技術によるリソースの管理権を設定する方法を表すブロック図である。 本発明によるリソースの管理権を安全に設定する方法を表すブロック図である。 本発明の実施形態による実施構成を表すブロック図である。

以下の詳細な開示は、本発明の実施形態の特徴を概説する。さらに、本発明の範囲に属するが実施される可能性のある実施形態のいくつかの変形例についても説明する（しかし全てではない）。

本明細書で説明する方法及び方法を実行するためのシステムの用途は多様である。理解を容易にし、簡潔にするために、以下の詳細な説明は、いくつかの定義及び概要を含み、その後に、チケットを含むリソースの管理権の設定を含むシナリオ（従来技術の構成との比較を含む）の説明が続く。その例に続いて、本発明が同様に有利であるいくつかのさらなる実施形態についても簡単に概説する。しかしながら、これらの個々のシナリオはいずれも限定的なものと見なされるものではなく、むしろ、本発明の利点を概説するための文脈として使用されるものであり、本発明は、ここで特に概説されていない他の文脈にも適用可能であることを理解されたい。

以下に概説する本発明の原理を理解するために、図１から図３のそれぞれに示す特徴を具体的に参照すべきである。それでもやはり、本発明は特許請求の範囲によってのみ定義される。

定義
本明細書で使用される場合、用語「分散台帳」は、データベースなどのデータ構造であり、共有可能であるもの及び／又は複数の当事者（第１の当事者及び第２の当事者の１又は２以上を含む）によってアクセス可能であるものを意味する。アクセスは複数の場所にわたって同期させることができる。データ構造は合意に基づいて確立することができる。分散台帳は、文脈に応じて、パブリック、プライベート、又はそれらの組み合わせのいずれかとすることができ、論理共有メモリ空間などの共有メモリ空間を使用して動作することができ又はそうではない場合もある。

本明細書で使用される場合、用語「シャード」は、分散台帳などのデータ構造の一部を指す。通常、計算負荷を分散するため又は他の理由で、第１のシャードはプロセッサ又はプロセッサ上にインスタンス化され、第２のシャードは異なるプロセッサ又はプロセッサ上にインスタンス化される。計算負荷は必ずしも均等に分散される必要はなく、データ構造の２つのシャードが同じサイズである必要も同じ機能を提供する必要もない。場合によっては、シャードは、データ構造の該当部分を特定の権限を与えられた又は指定された当事者のみがレビューできるように、セキュリティ保護及び／又は暗号化される。他の例では、シャードは、誰でも見ることができる。さらに、場合によっては、シャードは誰でも見ることができるが、一部のエントリは暗号化すること又はその他の方法で冗長化又は制限することができ、そのようなエントリの内容は、見ることが制限される又はプレーンテキストとして明らかになることが制限されるようになっている。以下の例では２つのシャードが存在するが、本発明では任意の数のシャードが存在することができる。

本明細書で使用される場合、用語「リソース」は、何らかの用途のために当事者による管理を受けるデータオブジェクトを意味する（データ構造内の特定のデータ又はデータ構造自体などであるが、これらに限定されない）。リソースは、秘密にしておく必要がある機密情報を含むことができる。特定の文脈では、データオブジェクトは、特定の当事者にとってはリソースであり、別の当事者にとってはリソースでない場合がある。例えば、第１の当事者がリソースを管理することができ、第２の当事者がリソースの管理人（ｃｕｓｔｏｄｉａｎ）として機能する。

本明細書で使用される場合、用語「作成」は、以前は存在しなかったものを新しく作る行為を意味する。リソースの作成とは、既存のリソースを修正することではなく、新しいリソースを作成することであり、新しいリソースは、それが作成される時点より前に又はその時点も含めて、以前に作成された他のリソースと共存することができる。

本明細書で使用される場合、表現「第１の当事者を起点とする命令」は、第１の当事者を最終起点とする命令を意味する。命令は第１の当事者から直接受け取ることができる。あるいは、第１の当事者は、１又は２以上の仲介者を介して間接的に命令を与えることができる。さらに別の方法として、第１の当事者自体は、さらなる当事者の代わりに活動するよう契約された又は委任されたエンティティとすることができ、第１の当事者は、さらなる当事者からのその当事者に代わって活動する権限を有する。

本明細書で使用される場合、表現「リソースの管理権が第２の当事者に属する設定」は、設定の結果として、第２の当事者がリソースに対する管理権を、詳細にはそこに含まれる情報及び権限を、自己の裁量で使用して行使することができることを意味する。管理権が設定されると、第２の当事者はリソースの使用時期及び使用方法を指示することができ、それによってリソースに対する所定の管理権を行使することができる。

概要
以下、本発明の実施形態について説明するが、本発明の実施形態は、リソースの管理権を第２の当事者に安全に設定する改良されたシステム及び方法を提供し、その方法は、シャード化された分散台帳上で実行される。

通信及び電子システム制御の文脈において、本発明の方法及びシステムは、第１の当事者が第２の当事者にリソースの管理権を設定するために、シャード間の伝送の必要性を排除することによって、分散台帳のアーキテクチャ内の異なるシャード間で送られるシャード間の伝送（すなわち、シャード間のデータトラフィック）を削減する。第２の当事者に管理権を設定する目的でシャード間の伝送がないことは、アトミックにコミットされた方法で伝送情報を準備、送信、受信、及び確認するための計算要件を低減することで、又は、送信シャード及び受信シャードの両方で、第２の当事者に管理権を設定する前にデータをコピー又はキャッシュする必要性を一時的にでも低減することで、いくつかの利点をもたらす。同時に、シャード間の伝送で必要となる可能性のあるネットワーク要件及び帯域幅も削減される。さらに、シャード間の伝送情報の準備、配信、及び／又は受信の必要性によって導入される何らかの遅延は除去され、結果として、リソースの管理権は、より迅速に、より低遅延で、より堅牢に、より安価に、より安全に確立することができる。

データ構造の２つのシャード間で管理権付与伝送情報などの伝送情報を送信する必要性をなくすことによって、第２の当事者にリソースの管理権を設定するために、２つのシャード間（すなわち、データ構造の２つの部分間）の接続を確立する必要性が取り除かれる。通信の遅延、ノイズ、帯域幅の要件など、潜在的な伝送上の問題が低減又は取り除かれる。また、２つのシャード間の伝送情報を受信する必要性を取り除くことは、伝送情報中の間違った順序のリスク及びデータが輻輳したりするリスクもなくなる。さらに、第２の当事者に対するリソースの管理権の設定に関与する構成要素の数が減るため、システムの耐障害性が向上する。管理権は、１つのシャードの動作で設定することができる。

新たに管理する当事者にリソースの管理権を設定するために、シャードのペア間で伝送情報を送る又は通信を行う必要性がなくなることも、方法及びシステムの並列化を助ける。データ構造の第１のシャードとデータ構造の第２のシャードとの間で、アトミックにコミットされた方法でシャード間の伝送情報を準備、送信、受信、及び確認する必要がないため、第２のシャードは、第１のシャードから独立して動作することができ、その逆も同様である。その結果、データ構造に本質的に現れるキュリティ機能を損なうことなく、理由の如何を問わずシャード間の相互作用の必要性がなくなる。例えば、データ構造が分散台帳である場合、分散台帳の改ざん防止機能及びセキュリティ機能が維持される。加えて、シャードのペア間で伝送情報を送る必要がなくなるため、同じセキュリティ機能を維持しながら、方法及びシステムを拡張する柔軟性も得られる。以下に、第１及び第２の当事者と第１及び第２のシャードを含む例を概説するが、同じ方法及びシステムは、第１の当事者と第３のシャードなどに関連付けられた第３の当事者との間、及び第１の当事者と第ｎのシャードに関連付けられた第ｎの当事者との間でも、同様の様式で実施することができる。

さらに、情報セキュリティに関して、データトラフィックの減少は、第３の当事者が関連データに含まれる情報又は管理権限にアクセスする機会を必然的に少なくする。第２の当事者に対する管理権の設定の一部として生成されるデータへの参照又はデータのコピーの数が減少するため、そのデータ及びそのようなデータに対する管理権限、又はデータ内に含まれる管理権限のセキュリティが向上する。加えて、第１のシャードと第２のシャードとの間のシャード間の伝送情報及びデータトラフィック又は通信の減少は、他のエンティティによる通信の傍受のリスクを低減又は完全に防止し、それによりデータが悪人の手に渡るリスクが低減する。このようなセキュリティ上の利点は、シャード間の伝送情報又は通信情報を傍受しようとする、又はそれらの伝送情報又は通信情報に含まれる、データのコピー又は管理権限の１又は２以上の管理権を得ようとする第３の当事者が利用できる機会が減少するために生じる。

第２の当事者に対する新たに作成されたリソースの管理権の設定は、第２のシャード上又は（第１のシャード以外の）他のシャード上の１又は２以上のプロセッサを関与させる必要なしに生じるので、情報又は管理権付与オブジェクトの複数のコピーを他のシャード上のデータで又は他の方法で（一時的にでも）具現化する必要がない。データ又は管理権付与オブジェクトのコピーの数を減らすことは、第３の当事者がその情報をより少ない場所でしか見つけることができないので、第３の当事者がアクセスする可能性が低くなり、そのデータ又はオブジェクト、従って包含される情報又は管理権限のセキュリティが向上する。

一般に、リソースはパブリックリソースとすること又はプライベートリソースとすること、完全とすること又は部分的とすることができる。リソースは、機密とすること、秘密情報又は機密情報又は管理権限を含むこと、暗号化されること、期間限定又は無期限で安全に保持される必要のある情報を含むことができる。リソースは、ウェブページ又はデータベースエントリなどの文書とすること、及び、公的文書（予防接種パスポート、運転免許証、ビザなど）又は金融リソース（通貨又は通貨に類似したトークンなど）などの公的リソースとすること、又は、特定のコンテキストでそれを制御する又は所有する又は配布することによって利益が生み出される何らかの他のリソース（イベントチケット、電子証明書、トークンなど）とすることができる。リソースは再利用可能であり、第１の当事者、第２の当事者、又は特定のエンティティのグループに対して個人的なものとすることができる。各インスタンスにおいて、単一のリソースは単一の有効なコピーのみに存在し、識別子を含むことができる。

レコードの公開は、分散台帳などのデータ構造の第１のシャードに対して行われる。レコードは、第１の当事者の識別情報の表示、第２の当事者の識別情報の表示、タイムスタンプ、リソースに関連するメタデータ、及び識別子又はシリアル番号のうちの１又は２以上を含むことができる。また、他のパラメータは、存在する先行レコードの何らかのハッシュ値、及びレコードに含まれるデータのハッシュ値として含めることもできる。レコードの公開は、第２の当事者の使用のためのリソースを作成し、リソースに含まれる情報へのアクセスを第２の当事者に譲与／付与することによって、リソースを第２の当事者の管理下に置き、リソースによって伝えられる管理権限を第２の当事者に有利にする。

先行技術の例：物理的チケットの管理権を確立する
本発明に対する関連状況を提示するために、物理的チケットなどのリソースの管理権を確立するために使用される既存の先行技術システムの概要を図１に示す。このシナリオでは、チケットは、例えば、コンサートのようなイベントのチケットである。偽造チケットは、潜在的なチケット所持者にリスクを与え、チケット所持者は、会場に到着し、イベント係員にチケットを物理的に提示したときに、購入したチケットが無効である、偽造品である、又は破損していることに気付くことになる。加えて、チケットの配達失敗又は横取りは、チケットがチケット購入者のリソースとして実現されることを阻む。

理解されるように、以下のシナリオは、リソースを配布し、特定の当事者にそのリソースの管理権を設定する一般的な手段を例示するものである。リソースがイベントへのチケットであるという事実は、限定的と見なすべきではない。

有効なチケットは、チケット所有者がそこに含まれる情報に基づいて会場の入口を通過することを可能にし、さらにチケット所有者が入場するためにチケットを提示することができるので、チケット所有者がリソースに対する管理権を行使するのを可能にするという理由で、リソースである。チケット所有者は、会場の入口でチケットを使用することで、入場と引き換えに、チケットを処分することができる。

チケットのシナリオでは、チケットを購入する際、個人はイベント主催者（例えばチケット売り場１００）に個人情報を提供し、多くの場合、チケット売り場で直接会って、電話で、又はウェブサイトを介してチケットを購入する。個人情報には、個人の氏名、住所、ＱＲコード、１又は２以上の金銭的詳細などが含まれるが、これらに限定されない。これらの幾つかの情報の各々は、詐欺師が個人情報詐欺の目的などで入手しようとする場合がある、機密情報である可能性がある。購入を行うことで、第２の当事者（チケット購入者／将来のチケット保有者１０）は、第１の当事者（チケット売り場１００）によるリソースの作成を要求する。

この先行技術の例全体を通じて、購入者の情報は機密であり、チケット売り場１００の範囲内にある間は「セキュア」及び「安全」であると仮定される。

購入要求を受け取ると、チケット売り場１００は購入を処理し、購入が正当であると判断した場合、チケットの発行を許可する。この判断は、承認担当者又は部門１１０によって行うこと、又は有効な購入を照合して識別する承認アルゴリズムに基づいてコンピュータによって行うこと、又はそれ以外の方法で行うことができる。

承認されると、チケットは、承認部門１１０からチケット１１５を作成する命令を受け取った時点で、チケット作成部門１２０によって作成される。その後、チケットを作製又はインスタンス化する様々なステップが実施され、典型的には、ホログラム又は透かしのような様々なセキュリティ機能がチケットに提供される。チケットは、イベントの詳細を含むことができ、購入者にパーソナライズされ、結果として個人データを包含することができる。チケット５０が作成されると、作成部門１２０から配布部門１３０に送られ、そこで将来のチケット所持者１０に配布するために処理される。

図１では、承認部門１１０、作成部門１２０及び配布部門１３０が３つの異なる部門として示されているが、承認部門、作成部門及び配布部門のいずれか１又２以上は同じ又は実質的に同じとすることができ、命令１１５及びチケット５０の移動のいずれか一方又は両方は、単一の部門で内部的に行うことができる。チケット売り場１００の部門内又は部門間での購入者の情報の何らかの移動は、安全であるとみなされる。

チケット５０がチケット所持者１０に到着する時点まで、チケット５０の管理権はチケット所持者１０に設定されていない。チケット売り場１００の内部では、チケットは、作成部門すなわちシステム１２０又は配布部門すなわちシステム１３０の管理下にある。しかしながら、チケット５０が送られたが、まだチケット所持者１０に到着していない場合、チケットは、宅配業者１４０（その宅配業者は、チケットの有用な管理権を有する場合又は有していない場合もある）、又は他の同等の郵便又はメッセージングサービスの所有下にある。その後の時点で、宅配業者１４０は、チケット５０を配達することによってチケット所有者１０に渡す。この先行技術の例では、チケット５０をチケット所持者１０に渡す時点が、チケット所持者１０にチケットの管理権、及びそこに含まれる何らかの個人情報又はさらなる管理権限の管理権を設定する行為である。このシーケンス全体を通じて、リソースとしてのチケット５０、及びそこに含まれる情報又はさらなる管理権限は、このシナリオにおいてその時点でチケット５０を所持している誰かの完全な又は部分的な一時的管理下にある可能性がある。配達順序の結果として、チケット５０の管理権をチケット所持者１０設定するのに遅延が生じ、リソースとしてのチケット５０に対する管理権は、この遅延の間に宙ぶらりんになるか、又はチケット所持者１０とチケット売り場１００のいずれにも部分的に又は完全にないかのいずれかである。

これらの既存のシステムは、場合によっては問題なく機能するが、チケットの管理権をチケット所持者に設定するプロセスは、一連の情報及び管理のセキュリティの問題を提起する。場合によっては、詐欺師が、新たに作成された物理的なチケット５０がチケット売り場１００の配布部門１３０から出る際にアクセスする可能性がある。他の例では、詐欺師は、宅配業者又はメッセージングサービス１４０で輸送中のチケットを奪う可能性、又は宅配業者の仕分け又はルート設定オフィスの１つで奪う可能性がある。チケット５０は、宅配業者１４０が会場の入口を通過するために使用しない可能性があるため（例えば、チケット５０がチケット所有者１０にパーソナライズされている場合）、宅配業者１４０にとって必ずしもリソースではないが、詐欺師が宅配業者１４０を妨害して何らかの手段でチケットにアクセスした場合、そこに記録されている情報又はさらなる管理権限は、将来の詐欺の対象となる可能性がある。

上記のセキュリティリスクに加えて、先行技術のシステムはボトルネックにも悩まされる。通常、イベントのチケットは数に限りがあり、イベントが「完売」する前の短い時間内にしか入手できない。また、多くの場合、チケットは特定の日の特定の時間に発売され、特定の時間にイベントのチケットを購入しようとするチケット購入希望者が同時に殺到することが多い（例えば、複数のチケット売り場や発券オフィスから）。オンライン又はコールセンターで購入する場合でも、チケット購入希望者は、購入が処理される間に待ち行列に保持されるか又は「保留」にされる場合が多い。同時に大量のチケットが購入される場合、チケット購入の処理が困難になることがある。このような状況では、エージェントは集中型発券データベースを使用することが多いが、チケット購入希望者が大量に殺到するような状況で、このデータベースを十分に最新の状態に保つことは依然として困難である。このような販売時には、各発券エージェントは集中型発券データベースと通信する必要がある。このような通信には時間がかかり、コンピューティング資源を消費し、場合によっては、中央データベースを更新するための複数の同時アクセスにより、通信の遅延又は中断のために、同じチケットが２つの別々のエージェントによって偶発的に同時に２回販売されることにという結果になる可能性がある。

先行技術のシステムは、購入を１枚ずつ順次処理するか、又は代替的に、特定のチケットを特定の発券オフィスに割り当てる（これは、１つのオフィス又はベンダーが完売するが、別のオフィス又はベンダーが依然としてチケットを持っていることにつながる可能性がある）ことによって、同じチケットが２回販売されるリスクを軽減する。発券オフィス、発券エージェント、中央データベース間の通信が必要になるため、発券エージェントの数が増えるほど、中央発券データベースとの通信量が増え、中央発券データベースを最新の状態に保つことが難しくなる。従って、既存のシステムはある程度機能するが、これらのシステムは、購入の厳密な順序を維持する必要があるため、並行して運用することが困難であり、さらに中央発券データベースへの多数の同時アクセスに対して規模を拡大することが困難である。

先行技術の例：電子チケットの管理権の設定
物理的なチケットの文脈で上述したが、リソースが物理的なチケットではなく、むしろ電子的なもの（例えば、ｅ－チケット、ｅ－証明書又は同様のもの）である代替的なシナリオであっても、状況は変わらない。電子メール、テキストメッセージ、セキュアメッセージ、又は物理的な手段ではなく電子的な手段を介してリソースを送信することにより、そのリソースの管理権を設定することは、類似のセキュリティ問題を提供する。リソースの管理権を第２の当事者に設定する前に、リソース、情報、及びそこ担保されたさらなる管理権限は、第１の当事者とリソースを受け取る第２の当事者との間で依然として伝送する必要があり、その伝送は、悪意のある当事者による傍受を受けやすい又は伝送路ノイズ破損に晒されやすい。情報が暗号化されているとしても、悪意のある当事者によって解読される又は不正に改ざんされる可能性がある。さらに、宅配業者１４０によって運営される物理的な配送ネットワークに類似して、電子メールサービスプロバイダなどの第３の当事者は、チケット売り場とチケット所持者との間のその経路上で、ｅーチケットなどを（一時的に）管理することに頼る必要がある。加えて、短い時間窓で大量のチケットを迅速に発行する場合にも、同様のチケット処理の課題が発生し、単一の集中型発券データベースへの複数の同時アクセス及び更新の必要性によるボトルネックが存在する。

本発明によるチケットの管理権の設定
購入者に対する物理的又は電子的チケットの管理権の安全な設定は１つの例であり、本発明は、分散台帳のようなシャード化されたデータ構造において、特に、１つの当事者から別の当事者へリソースに対する管理権を渡す際のセキュリティ、待ち時間、及びリスクに関して、根本的な改善を提供する。図１に関連して説明した従来技術のスキームとは対照的に、図２のスキームはこのような改善を提供する。この発券コンテキストは、リソースの管理権を安全に設定するための方法及びシステムの例を形成するが、チケットに関連する例の特徴は、同じシステムアーキテクチャ、原理、及びデータ構造を使用して、異なるタイプのリソースに適用することができることを理解されたい。

以下により詳細に概説するように、本実施例では、購入後にチケット売り場でインスタンス化され、主にチケット売り場で使用される分散台帳のシャード上に電子チケットを作成する。この作成は、（ａ）作成されたチケットリソースの管理権が即座に購入者にあり、（ｂ）これらの管理権限が、１又は２以上の第３の当事者による又はチケット売り場のプライマリシャードの外部による、何らかの管理の連鎖又は他の形態のリスクのある伝送又は仲介を経由する必要がない方法で行われる。このことは、リソース管理権の安全な譲渡を行うために分散台帳の２以上のシャード上で何らかの操作を行うことを必要とすることとは対照的に、チケットの購入及びこのリソースに対する購入当事者の管理権の設定は、どちらもチケット売り場の同じシャード上で行われることを意味する。

チケット保有者は、例えば会場の入口で自分のチケットの管理権を行使したい場合、コンピュータ、ラップトップコンピュータ、スマートフォン、ＰＤＡ、タブレット、電話、又は所持している類似のデバイスを使用して、レコードを含むシャードを照会することでそれを行うことができる。チケット所有者は、会場に入場することを可能にする関連する暗号的に機密保護されたチケットの詳細情報にアクセスするために、自分のデバイスを使用して、インターネットなどのネットワークを介して、チケット売り場のシャードに存在する分散台帳のシャードに対して問い合わせを行う。

図２を参照すると、将来的な電子チケット所有者１０及び第２の当事者である購入者は、チケットをチケット売り場２００に申し込み、購入時に必要な情報をチケット売り場２００に提供する。チケットの申し込みに問題がないと見なされた場合、承認部門２１０は購入者に対するチケットの発行を承認する。購入プロセスには、例えば氏名、住所等の購入詳細情報に加えて、チケット所持者の公開鍵－秘密鍵ペアを生成するプロセスが含まれる場合もある。チケット発行の決定は、認証エージェント又は部門２１０によって行うことができ、又は、これは有効な購入を照合して識別する認証アルゴリズムに基づいて計算によって行うこともできる。このシナリオでは、チケット売り場２００（又はその部門の１つ、又はそのエージェント、又はチケット売り場に代わって働く請負業者）は、第１の当事者であると見なされ、購入者／将来のチケット保有者１０は、第２の当事者と見なされる。

チケットの発行を承認するチケット売り場２００は、第１の当事者として機能し、最終的に、典型的にコンピュータ／サーバ上に存在する少なくとも１つのプロセッサ２３０上でインスタンス化されるチケット分散台帳の第１のシャード２４０上にチケット２５０の作成をもたらすことになる命令２１５を出す。チケット２５０の作成は、作成部門２２０で行われる。作成部門２２０は、チケット売り場内とすること、又は承認部門２１０から安全な命令２１５を受け取ることができる、チケット売り場に代わって作業する請負業者のコンピュータとすることができる。チケット売り場２００（及び存在する場合は請負業者）は、その中では購入者の情報が「安全」で「セキュア」であるとみなされるセキュアな境界内にあるとみなされる（上記のチケット売り場１００と比較すると）。この例ではチケット分散台帳のシャード２４０を参照しているが、異なる形式の分散台帳データ構造（及びそのシャード）も可能である。

承認部門２１０から出された命令２１５は、購入者の実名又は仮名識別情報、及び場合によってはその他の詳細情報を含み、さらに、命令が承認部門２１０、場合によっては承認部門２１０内の特定のコンピュータを起点とすることを示す識別子を含むことができる。他の例では、命令２１５がチケット売り場２００内から生じたことを確認するだけで十分な場合がある。命令２１５自体は、追加のセキュリティ層として暗号的に保護することができる。場合がある。

命令２１５を受け取ると、プロセッサ２３０は、作成ステップの前に命令２１５の起点を検証するアルゴリズムを実行し、それによって無効な命令からリソース作成が生じる可能性を低減することができる。命令２１５がすでに暗号化されていた場合、プロセッサ２３０は、命令を復号化することから始まることができる。

検証のいくつかの方法は、時間、場所、及び命令２１５が発信されたコンピュータの１又は２以上を識別するデジタル署名などの識別子（場合によっては一意の識別子）が存在するか否かの命令の検査又は照合を含む。他の例では、命令２１５に存在する別のパラメータが照合される。一例では、命令２１５を出す責任を負う承認部門２１０のコンピュータ又はプロセッサは、命令２１５の起点がそのプロセッサであることを識別する消去できない識別子を命令２１５に付加又は挿入することができる。その後、その起点は、「許可された」起点のリスト又はデータベースと照合することができる。命令はチケット売り場２００が起点であり他の当事者からのものではないことをプロセッサ２３０が検証するための代替機構を使用することができる。命令２１５の起点を検証することにより、チケット発行プロセスのセキュリティが向上する。

いくつかの例では、プロセッサ２３０とは異なる第１のシャード２４０上の別個のプロセッサは、命令の到着時に又はプロセッサ２３０の要求に応じて検証ステップを実行し、プロセッサ２３０が命令を受け取ると、この別個のプロセッサは結果として仲介者として機能し、プロセッサ２３０への命令をフィルタリングする。命令が無効であることが判明した場合、その命令は記録され、チケット売り場内のセキュリティ部門、又は例えば法執行機関に報告することができる。

命令２１５の起点の検証に加えて又はその代わりに、プロセッサ２３０は、その命令が、チケット売り場２００のエージェント、又は承認部門２１０内の（エージェントとして動作する）コンピュータのデジタル署名を有することを検証し、その個人又はコンピュータが、チケットを作成する命令を出すことが承認されていること及び／又はその資格があることを確認することができる。最初のエージェント又はコンピュータがその方法を実行する権限を有することを保証する照合は、命令２１５の起点の確認とは別に、エージェント又はコンピュータの品質を決定する。確認の方法は、命令２１５の起点の確認の方法と同様であるが、命令２１５がどこから来たかを照合するのではなく、この確認は誰が命令２１５を出したかを照合する。これは、承認の責任を負うエージェント／コンピュータの資格情報の消えない表示を命令２１５に付加するか又は含めることによって達成することができる。さらに、承認は、エージェント／コンピュータが承認命令２１５を出す能力があることを保証するために、必要な照合が全て完了していることを条件とすることができる。確認は、命令２１５、又は、チケットを作成する命令２１５の送信を承認する責任を負う承認エージェント又はコンピュータを識別するデジタル署名などの識別子の存在に関する内容の照会を含む。一例では、確認は、デジタル署名を承認されたエンティティのリスト又はデータベースと照合することを含むことができるが、誰が命令を出したかの識別情報を確認する他の機構も可能である。確認を行うことで、無許可の当事者がプロセッサに偽造チケットの作成を命令することを防ぐことができる。

いくつかの例では、プロセッサ２３０とは異なる別個のプロセッサが、命令の到着時に又はプロセッサ２３０が命令を受け取った後に、プロセッサ２３０の要求に応じて検証ステップを実行し、それによって別個のプロセッサが仲介者として機能し、プロセッサ２３０への命令をフィルタリングする。命令が未確認であることが判明した場合、その命令は記録され、チケット売り場内のセキュリティ部門又は例えば法執行機関に報告することができる。

いくつかの例では、命令２１５の起点を検証する責任を負う同じプロセッサが、誰が命令を送ったかを確認する責任も負う。命令２１５の検証及び確認は、命令２１５の真正性を保証するために、チケットが第３の当事者の販売業者によって販売される場合に特に関連する可能性がある。

命令２１５の検証及び／又は確認が成功した後、命令は、チケット２５０を作成するためにプロセッサ２３０によって使用される。図２に示すように、プロセッサ２３０は、その上にインスタンス化されるチケット分散台帳の第１のシャード２４０の一部である。プロセッサ２３０は、チケット分散台帳の第１のシャード２４０にレコードを公開することによって、チケット所有者１０のリソースとして新しいチケット２５０を作成する。このブロックチェーン上のレコードの公開は、以前に提供された情報からチケット所有者のリソースとしてのチケット２５０を作成し、公開の時点で、チケット所有者のリソースであることを可能にするその情報に関連付けられた管理権限（チケットがイベントのためのものであり、チケット所有者にイベントへの入場を得る能力を与えるという事実など）は、チケット売り場２００内のチケット分散台帳のシャード２４０上でチケット所有者に最終的に設定されるようになっている。チケットリソース２５０は、その公開の瞬間からチケット保有者が管理するために入手可能であり、それによってチケット保有者は、自分の裁量でチケット２５０を利用することができる。

公開されたレコードは、識別子、並びに購入者名などの購入者から提供された複数の情報の一部又は全部を含むことができ、これは、レコードのメタデータに含めることができる。また、他のパラメータは、チケットを付与する発券権限の表示、イベント及び会場の詳細情報などのメタデータに含めることができる。また、レコードは、チケットを作成するための命令２１５の検証された起点の表示を含むこと、及び／又はその命令２１５が確認された承認エージェント又はコンピュータの表示を含むことができる。加えて、レコードは、ブロックチェーン内の前のブロックのハッシュ値と並んで、上記で言及されたデータを含むレコード及びその内容の全てのハッシュ値を含むことができ、それによって、公開されたレコードの各々に関してブロックチェーンのセキュリティが利用可能であることが保証される。ブロックチェーンは、設計上、そこに含まれるデータの改ざんに強いので、第１のシャード上のチケット保有者のリソースとしてのチケットの作成のための永続的かつセキュアなレコードを提供することができる。さらに、リソースは、何らかの他のシャードとの相互作用を必要とすることなく作成される。

新しく作成されたチケットリソース２５０が付加される第１のシャード２４０は、一連の既存のチケットリソースを含むことができる。第１のシャード２４０は、有効期限が切れた、過去のイベントで使用された、又は他の理由で使用中止された、同じ購入者のための古いチケットを含むことができる。これらのリソースの各レコードは、暗号化することができ、復号化権限を有するチケット所持者１０などの、それぞれのチケット所持者のみが各レコードの内容を復号化できるようになっている。あるいは、第１のシャード２４０は、チケット所有者に関連する他のプレーンテキスト又は暗号化されたデータを含むことができる。

あるいは、シャード２４０内のチケット分散台帳の個々のエントリを暗号化するのではなく、シャードレベルでアクセスを制御することもできる。シャード２４０は、単一の当事者に属するリソースレコード（この例では、チケット）のみを含むことができるので、シャード２４０全体へのアクセスは、同じチケット所有者１０に排他的に認めることができる。このシナリオでは、シャードへのアクセスは、プロセッサ２３０が、「ゲートキーパー」として機能することを可能にする確認アルゴリズムを実行することによって管理することができ、そのようなアクセスを認めるか否かを決定するために、第１のシャード２４０へのアクセスに対する各要求に対して確認アルゴリズムを実行する。

さらなる代替案として、第１のシャードは、異なるチケット所有者のための異なるチケットの複数のリソース及び他のレコードを含むことができ、各レコードは暗号化され、それぞれのチケット所有者のみが識別できる。これらのレコードの各々は、暗号化すること及び異なる公開鍵－秘密鍵ペア又は同様のものを使用して暗号化することができるので、正しい秘密鍵を所有するチケット所有者１０などのそれぞれのチケット所有者のみが、特定のレコードの内容を復号化し、それによって、そこに含まれる情報へアクセスして、その情報を制御する能力を得ることができる。

さらなる代替案では、新しいチケットリソース２５０の作成は、チケット２５０の作成前又は作成の瞬間にインスタンスを作成された、プロセッサ２３０上の新しいシャード２４０のインスタンス化を含むこともできる。このようなシナリオで、チケット分散台帳を保護するためにブロックチェーンが使用される場合、ジェネシスブロック（ｇｅｎｅｓｉｓ ｂｌｏｃｋ）を生成することができ、ジェネシスブロックは、システムパラメータなどのシャードに関連する情報を含み、チケットレコードがジェネシスブロックのハッシュ値を含むことを許可するために、シャードのインスタンス化と同時に生成することができる。

チケットのレコードを第１のシャード２４０に公開することによってチケット２５０が作成されると、チケットは、チケット所有者１０が使用するリソースとなる。図１に関連して説明したように、その後、チケット５０をチケット所有者１０が使用するために宅配業者１４０によってチケット所有者１０に送る必要がある既存の方法とは対照的に、図２のシステムでは、チケット２５０は、第１のシャード２４０にレコードが公開された瞬間に（実際には、チケットが作成されたことにチケット所有者１０が気付く前に）、チケット所有者のためのリソースとして存在する。チケットの管理権を設定するこの方法の１つの利点は、そのような輸送が必要ないため、作成されたチケット２５０が、プロセッサ２３０とチケット所持者１０との間の輸送中に奪われる可能性がないことである。その結果、詐欺師による横取りは不可能である。加えて、チケット分散台帳の第１のシャード２４０上のレコードとしてチケットを公開する結果として、チケット２５０の作成の即時レコード（改ざん防止機能付き、永続的、及び公然とすることができ）が作られる。さらに、チケットが例えば公開鍵－秘密鍵のペアを用いて適切に暗号化されている場合、チケットの所有者だけが、内容を確認し、チケットを管理するために必要な秘密鍵を持っており、それによって追加のセキュリティレベルが提供される。

レコードが第１のシャード２４０に公開された時点で、チケット所有者１０は、チケットの作成が完了したことを必ずしも知らない。例えば、チケット所持者１０は、チケットの購入を確認することができる。その時点以降、購入の瞬間と第１のシャード２４０へのレコードの公開の瞬間との間に、チケット売り場２００内のプロセッサ２３０がチケット２５０を準備する何らかの内部処理時間が存在する可能性がある。しかしながら、公開の瞬間、チケット、及びそのチケットに含まれる何らかの情報（パーソナライズされる可能性がある）、及びそのチケットに関連する何らかの管理権限は、その瞬間からチケット保有者が使用できるようになるが、その理由は、チケット所持者は、（理論的に）レコードが公開されると直ぐに自分の裁量でチケットを使用するからである。従って、リソースとしてのチケットのチケット所持者に対する管理権は、第１のシャード２４０への公開時に設定される。チケット２５０の管理権をチケット所有者１０に設定するために、さらなる又は中間的なステップは必要ない。作成後、チケット所有者１０が第１のシャード２４０を調べると、チケット２５０は使用可能な状態になる。

以上の結果、図２のシステム及び方法では、チケット２５０に対する管理権は（公開時に一旦作成されると）、他のエンティティの連携又は同意なしに（実際には、チケット所有者１０の連携又は同意さえなしに）、チケット所有者１０に設定される。これは、図１及び先行技術における、リソースとしてのチケット５０の管理権の設定には、まずチケット５０が第３の当事者の宅配業者１４０を介してチケット所有者１０に発送され、そのチケット２５０が配送されるまでの発送期間中、チケット所有者１０がチケットに対する管理権を持たない状況とは対照的である。同様に、電子リソース（たとえばｅ－チケットなど）の先行技術の場合、リソースを使用するためにはリソースの受け取り（例えば電子メールによる）が必要であり、その都度、チケットをチケット所有者１０に通信する必要があり、それによって待ち時間が増加し、その通信が第３の当事者によって傍受されるリスクがある。

さらなる利点として、チケットの管理権をチケット所有者１０に設定するためのチケット２５０の公開は、シャード間の通信を必要としない。その代わりに、各シャードは、チケットの作成に関して互いに本質的に独立して動作することができる。このようなアーキテクチャは、チケット分散台帳（又は他のブロックチェーン又は同様のデータ構造）がシャーディングすることができるので、購入の殺到が予想されるシナリオにおいて価値がある。チケット２５０の管理権がチケット保有者１０に設定される間に、厳密にはシャード間通信は必要ない。リソースの管理権を別のシャードに送る必要はない。加えて、このようなシャード間通信にコンピューティング資源を割り当てる必要もない。これにより、チケット２５０の管理権をチケット所有者に設定する目的で、システムの並列化及びスケーラビリティの両方は、セキュリティを損なうことなく改善される。

チケットの管理権を設定するために必要ではないが、チケット２５０が作成されると、通知２６０のような表示は、プロセッサ２３０によって、チケット２５０が作成され、既にチケット所有者１０の管理下にあることをチケット所有者１０に送ることができる。通知２６０は、チケット２５０を使用する準備ができていることを示すためにチケット保有者１０に送られる、電子メール、セキュアメッセージ、レター、電話、自動電話、又は他の通信の形態とすることができる。通知２６０自体は、通知がチケット保有者１０によってのみ復号化できるように暗号化される場合がある。通知を受け取ると、チケット所持者１０は、チケットが使用可能になったことに気付く。この通知２６０は、従来の何らかの手段で送ることができるが、チケット２５０に記録されている機密情報は、必ずしも通知２６０内に含まれていないため、通知が傍受されたとしても、チケット５０自体が宅配業者１４０又は電子メールで配布される状況とは対照的に、アイデンティティ詐欺を可能にする情報は利用できない。あるいは、通知を受け取る前に、チケット所持者１０は、チケットの入手可能性に気付く可能性もある。

先行技術の方法では、データオブジェクトは、このデータオブジェクトとそれに対する管理権が作成され、その後、意図された第２の当事者に送られ、しっかりと保管された時点で、第２の当事者にとってのリソースとなる。このような場合、データオブジェクトとそれに対する管理権（両方ともリソースの作成に必要）を第２の当事者に送るステップは、最終的にデータオブジェクトをリソースとして設定するステップに先行する。これは特に、管理権の伝送が仲介者を経由して流れるか、又は宙ぶらりんの状態にしばらくの間、留まる必要があることを意味する。本発明の分野における先行技術の方法は、（１）「データオブジェクトを作成する」、（２）「データオブジェクト又はそのメッセージを送る」、（３）「リソースとしてのデータオブジェクトに対する管理権を第２の当事者に設定する」というシーケンスに沿って動作する。本発明は、このシーケンスを根本的に（１）「データオブジェクトを作成する」、（２）「リソースとしてのデータオブジェクトに対する管理権を第２の当事者に設定する」、（３）「その有効な管理権を第２の当事者に通知する」に変更する。データオブジェクトがリソースとなるためには管理権が本質的（ｃｏｎｓｔｉｔｕｔｉｏｎａｌ）であるにもかかわらず、本発明の分野における先行技術の方法では、この管理権そのものが多種のリスクにさらされ（上記のいくつかの例を用いて説明した）、増え続けるコンピュータハードウェアのスピードによって根本的に是正することができない不必要な遅延にさらされ、連鎖の管理にもさらされ、分散台帳とそれに関連するブロックチェーンが効率的にシャーディングすることができず、従ってそもそも拡張できない。これとは対照的に、本発明では、データオブジェクトに対する管理権を第２の当事者に設定し、結果としてリソースを作成することは、通信、通知、送信、又は同様のステップの前に行われる。これらのアプローチは、記載される先行技術の欠点に対処するものである。

本発明のいくつかの例では、通知２６０は、プロセッサ２３０以外の別のプロセッサ、例えば、第１のシャード２４０へのレコードの公開を「観察」するアルゴリズムを実行するチケット売り場２００内の別のプロセッサによって送ることができる。この別のプロセッサは、定期的に又はオンデマンドで変更に関して第１のシャード２４０を監視することができ、変更がもたらされるたびに通知２６０を送ることができる。有利には、チケット分散台帳のシャード上のレコードが永続的でセキュアである場合、チケット２５０内のデータに対するいかなる変更も、そのデータのハッシュ値における変更をもたらすことになり、これは、「観察」アルゴリズムを実行するプロセッサ、又は他の観察エンティティに直ちに明らかになるであろう。

さらなる代替案として、上記の通知２６０イベントは、代わりに、レコードの公開及びチケット２５０の作成の副作用として生じる場合があり、有利には、例えば、チケット保有者１０又は他のエンティティが、第１のシャード２４０の内容を観察する「観察」当事者である場合、プロセッサ２３０によるさらなる処理又は計算を必要としない場合がある。

代替案として、又はチケット保有者に通知２６０を送ることに加えて、チケット保有者１０は、チケット２５０が作成されたか否かを確認する目的で、プロセッサ３０などの自分の管理下にあるデバイスを使用して、第１のシャード２４０の定期的な又はオンデマンドの作成検索２７０を実施することができる。チケット保有者は、プロセッサ３０上で検索アルゴリズムを実行して、タイムスタンプ、シリアル番号などの識別子、及び別のパラメータのうちの１又は２以上に基づいて、チケットブロックチェーンの第１のシャード２４０上に公開されたレコードを検索すること、又は、チケット保有者の名前又はチケット保有者を識別する別の情報、例えば暗号化された仮名を含むエントリをメタデータから検索することができる。作成検索２７０が、チケットが作成されたことを示す場合、通知はチケット所有者１０に送ることができる。通知２６０と同様に、通知はチケットの情報内容を含まないが、チケット所有者が管理するリソースとしてのチケット２５０の存在の指示を含む。

第１のシャード２４０の作成検索２７０を許可するために、プロセッサ２３０は、検索アルゴリズムを実行するプロセッサ３０から受け取った要求を確認することができる。あるいは、別のプロセッサは、検証ルーチンを実行して、プロセッサ２３０への要求を確認された検索要求のみとなるようにフィルタリングすることができる。

第１のシャード２４０上でのチケット２５０の作成後、その後の通知がチケット保有者１０に送られた否か、及びチケット２５０の作成が完了したことをチケット保有者１０に示すことになる作成検索２７０が発生したか否かにかかわらず、チケット保有者１０がチケット２５０を使用して会場に入場することを希望する場合、これは、例えばプロセッサ３０によって実行されるアルゴリズムによって達成することができる。

プロセッサ３０は、チケットを使用する必要がある時点でチケット所持者１０が所持しているコンピュータ、スマートフォン、ＰＤＡ、タブレット、又は何らかの類似のデバイス内に構成される。プロセッサ３０は、その上に分散台帳の第２のシャード４０をインスタンス化することができる、又はチケット分散台帳の一部として第２のシャードに接続することができる。

プロセッサ３０は、チケット２５０を使用するために、アクセス検索２８０を実行することができる。実際には、アクセス検索２８０は、チケット２５０が作成されたことをチケット所有者１０に示すために使用される作成検索２７０と同じ検索ルーチンとすることができる。しかしながら、アクセス検索２８０は、チケット２５０が作成されたか否かを決定するためではなく、チケット２５０を使用したいときに、チケット保有者１０（又は別のエンティティ）によって臨機応変に（ａｄ－ｈｏｃ ｂａｓｉｓ）に開始される。アクセス検索２８０は、タイムスタンプ、シリアル番号のような識別子、別のパラメータに基づいて、チケット分散台帳の第１のシャード２４０に公開されているレコードを検索すること、又は彼／彼女の名前又は別の識別情報、例えば仮名を含むエントリをメタデータから検索することができる。アクセス検索２８０は、チケット所持者１０がそれ使用して会場に入場することができるように、チケット２５０から情報を検索するために使用することができる。いくつかの例では、アクセス検索２８０の各使用は、チケット２５０のアクセスの即時の、セキュアな、永続的な及び公然のレコードを提供するために、第２のシャード上のブロックチェーンにレコード６０を公開させる。

作成検索２７０又はアクセス検索２８０が実行された時点でレコードが作成されていない（すなわちチケット２５０が作成されていない）場合、チケット保有者１０にこのことを示すさらなる通知を送るアルゴリズムを実行することができる。

作成検索２７０及びアクセス検索２８０を使用することができる１つの実施構成は、図３に示されるように、第１のシャード２４０及び第２のシャード４０の各々が共有論理メモリ空間３００上にインスタンス化される場合である。共有メモリ空間３００において、チケット２５０は、プロセッサ２３０及びプロセッサ３０によって（少なくとも一時的に）アクセス可能な共通のメモリアドレスに配置される（このようなレコードが存在する場合、レコード６０についても同様とすることができる）。共有メモリ空間３００は、プロセッサ２３０及びプロセッサ３０の両方によってアクセス可能な任意のメモリ空間、例えば、チケット売り場２００でホストされるサーバメモリ、又はセキュアな環境でホストされるクラウドベースのシステムの形態をとることができる。共有メモリ空間３００へのアクセスは監視することができ、各アクセスは、アクセスが許可される前に確認して競合を解消することができる。共有メモリ空間への各アクセスは、第１のシャード２４０又は第２のシャード４０などのシャード上に又は分散台帳の別のシャード上に記録することができる。

いくつかの例では、１又は２以上のさらなるプロセッサ９３０上にインスタンス化された１又は２以上のさらなるシャード９４０など、第１のシャード２４０及び第２のシャード４０を超えるシャードが存在する場合がある。さらなるプロセッサ９３０は、第１のプロセッサ２３０と同じ様式で、又はプロセッサ３０と同じ様式で動作することができる。あるいは、プロセッサ９３０は、異なる様式で動作することができる。また、プロセッサ９３０上にインスタンス化されたさらなるシャード９４０は、共有メモリ空間３００にアクセスできる。さらなるシャード９４０は、それに公開されたさらなるレコード９６０を有することができる。

他の代替案では、分散台帳の一部のシャードは論理的に共有されたメモリ空間にアクセスできるが、他のシャードはアクセスできない。場合によっては、各シャードが共有メモリ空間３００にアクセスできるレベルは、各シャードに与えられた特定の権限によって異なる場合がある。

他のシナリオでの管理権の設定
上述の例のリソースは電子チケットであるが、リソースの管理権を第２の当事者に設定する本方法及びシステムの利点は、チケットのシナリオに限定されない。別のシナリオでは、利点は、ワクチンパスポートのような公的文書の管理権の設定で得ることができる。このようなシナリオでは、申請者は公的な医療機関からワクチンパスポートを求める。医療機関は、申請者がワクチン接種を受けたことを確認し、第１のシャード（参照：第１のシャード２４０）にワクチンパスポート（参照：チケット２５０）を公開する。公開の時点で、ワクチンパスポートはパスポート所持者の個人リソースを形成し、パスポート所持者はモバイル機器を使用してアクセスすることができる。チケットのシナリオと同様の様式で、ワクチンパスポートは、医療機関のシャード上のレコードとして存在するため、ワクチンパスポートの通信（及び関連する遅延又は傍受のリスク）は存在しない。

データセキュリティ及び通信の利点が得られる別のシナリオは、文書のバージョン管理のコンテキストで見出され、この場合、文書の最初のバージョンは、最初のユーザ（第１の当事者）の管理下にある第１のシャードにインスタンス化されたレコードのメタデータに存在することができる。第１のユーザが自分の編集を完了すると、第１のユーザは、セキュアな様式で文書の管理権を第２のユーザ（第２の当事者）に設定する必要がある。上記のチケットの例と同様の様式で、第１のユーザは自分の変更を保存し、自分の管理下にある第１のシステム上にインスタンス化された第１のシャードに、文書のさらなるレコードを公開することができる。そのレコードの公開時、文書の管理権は第２のユーザに設定することができ、それによって、その文書にアクセスしてさらに編集を行うことができる第２のユーザのためのリソースを作成することができる。

本発明がリソースの管理権を第２の当事者に設定することを可能にする別のシナリオは、第１の当事者から第２の当事者への管理権の譲渡が仲介者の連鎖を経由しないことが重要な場合に現れる。これは、例えば、同盟国間で共同運用される軍事防衛システムに適用され、防衛リソースの管理権は、当初、ハードウェアのシステムシャード上の第１の当事者にあり、その後に、第１の当事者によって、そのシステムシャード上で第２の当事者によって管理されるリソースとして設定される。運用状況に応じて、第２の当事者は、リソース及びその管理権を第１の当事者のシステムシャード上に統合すること、又は代替的に第２の当事者が選択した時点で、第２の当事者のシステムシャードに転送することもできる。このアーキテクチャでは、その後、軍事防衛システムの効率的制御が中断又は仲介されることはなく、マルチシャード分散型ハードウェア上のこの制御の固定は、状況認識及びその時点での制御者のニーズに応じて適合させることができる。

データセキュリティ及び通信の利点が生じるさらなるシナリオは、通貨単位又は口座の管理権を、第２の当事者に安全に設定する必要がある金融環境で見出される（例えば贈答品として又は支払いの一部として）。この場合、第１のユーザ（第１の当事者）は、第１のシャードに通貨単位又は口座リソースを保持し、その後、第１の当事者によって元々保持されていたリソースを消滅させながら、第１のシャード上に第２のユーザ（第２の当事者）のリソースを作成して公開することによって、この通貨単位又は口座リソースを渡すことができる。このレコードが公開されると、通貨単位の管理権は第２のユーザに設定され、それによってその第２のユーザのためのリソースが作成され、第２のユーザは自分の裁量で通貨単位を使用することができる。

本発明はまた、工業的又は電子的プロセスにおいて、タイムクリティカルで、高度に分散化された、共同又は協働的な制御移行が必要とされる関連状況において、並列化の利点を提供する。第１の当事者のシステムシャード内で、最終的状態で第１の当事者から第２に当事者にリソースを移行する能力は、効果的な並列化の基礎となる。例えば、将来の自動車交通管理システムでは、自動車は互いにネットワーク化され、路側センサ及び交通報告システムともネットワーク化される。中央で最適化された様式の車両経路決定におけるリソース及び制御管理は、一般に、自動車交通の複雑さ及びリアルタイムの要求に矛盾した計算遅延に悩まされることになる。その代わり、各自動車は、道路ネットワークの形の有限のリソースを共有し、これらは、様々な道路リソースへのアクセスを取り決める及び調整する必要のある独立した当事者（ａｃｔｏｒ）である。このような道路リソースの調整は、リソース転送のスループットが非常に高く（この並列化は高めることができる）、自動車間のリソース受け渡しの遅延時間が非常に短く、仲介者がいない技術的能力を必要とする。本発明は、これらの要求に対応する。

リソースの管理権を第２の当事者に設定するための方法及びシステムの通信及びデータセキュリティの利点を得るさらなるシナリオは当業者には明らかであり、本明細書で概説した個々のリソース又は個々のシナリオは、限定的と考えるべきではない。

１０ チケット所有者
３０ プロセッサ
４０ 第２のシャード
６０ レコード
２００ チケット売り場
２１０ 承認部門
２１５ 命令
２２０ 作成部門
２３０ プロセッサ
２４０ 第１のシャード
２５０ チケット
２８０ アクセス検索
２７０ 作成検索
２６０ 通知

Claims (15)

1. 分散台帳におけるリソースの管理権を安全に設定するコンピュータに実装された方法であって、前記分散台帳は、第１のシステムの１又は２以上の第１のプロセッサ（複数可）上にインスタンス化された第１のシャードを備え、前記第１のシャードは、第１の当事者を起点とする命令に応答するように構成され、前記分散台帳は、第２のシャードをさらに備え、前記第２のシャードは、１又は２以上の第２のプロセッサ（複数可）上にインスタンス化され、前記第２のシャードは、第２の当事者を起点とする命令に応答するように構成され、前記方法は、
   第１のシステムによるレコードの公開によって、前記リソースを作成するステップ、
   を含み、
   前記レコードの公開は、前記第１の当事者を起点とする命令に応答して生じ、
   前記レコードの公開は、前記分散台帳の前記第１のシャードに対するものであり、
   前記レコードの公開は、前記リソースの管理権が前記第２の当事者に属することを設定する、方法。
2. 前記命令は、前記第１の当事者を起点とすることを検証するステップをさらに含み、随意的に、前記検証は、前記第１のシステムに基づく、請求項１に記載の方法。
3. 前記リソースは、前記第２の当事者の識別情報の表示を含む、請求項１又は２に記載の方法。
4. 前記第１のシャードは、前記第１の当事者に関連する１又は２以上のレコード（複数可）を含み、
   及び／又は、
   前記第２のシャードは、前記第２の当事者に関連する１又は２以上のレコード（複数可）を含む、
   請求項１から３のいずれかに記載の方法。
5. 前記リソースの前記管理権が前記第２の当事者に属することを前記第２の当事者に示すステップをさらに含む、請求項１から４のいずれかに記載の方法。
6. 前記リソースの前記管理権が前記第２の当事者に属することを前記第２の当事者に示すステップは、前記レコードの公開の通知を前記第２の当事者に送ることを含み、随意的に、前記送ることは、前記第１のシステムに基づく、請求項５に記載の方法。
7. 前記１又は２以上の第２のプロセッサ（複数可）は、第２のシステムに含まれ、随意的に、前記方法は、前記第２のシステムによって、前記第１のシャード内の前記レコード（複数可）を検索するステップをさらに含む、請求項１から６のいずれかに記載の方法。
8. 前記リソースの管理権を安全に設定する方法は、
   前記第２のシャードの前記１又は２以上のプロセッサ（複数可）の何れとも相互作用することなく実行される、
   及び／又は、
   前記第１のシャードの前記１又は２以上のプロセッサ（複数可）だけで実行される、請求項１から４のいずれかに記載の方法。
9. 前記第１の当事者が前記リソースの作成を命令する権限を有することを検証するステップ、
   及び／又は、
   前記第１の当事者が前記リソースの作成を命令する能力があることを検証するステップ、
   をさらに含む、請求項１から８のいずれかに記載の方法。
10. 前記分散台帳の前記第１のシャード及び前記第２のシャードの各々は、共有メモリ空間に存在し、前記第１のシステムは、前記共有メモリ空間にアクセスするように構成されている、請求項１から９のいずれかに記載の方法。
11. 前記分散台帳は、ブロックチェーンを含む、請求項１から１０いずれかに記載の方法。
12. 前記分散台帳は、パブリックである、請求項１から１１のいずれかに記載の方法。
13. 実行されると、１又は２以上のプロセッサに請求項１から１２のいずれかに記載の方法を実行させる命令を含む、コンピュータプログラム製品。
14. 実行されると、１又は２以上のプロセッサに請求項１から１２のいずれかに記載の方法を実行させる命令を含む、コンピュータ可読媒体。
15. 分散台帳におけるリソースの管理権を安全に設定するためのシステムであって、前記分散台帳は、第１のシステムの１又は２以上の第１のプロセッサ（複数可）上にインスタンス化された第１のシャードを備え、前記第１のシャードは、第１の当事者を起点とする命令に応答するように構成され、前記分散台帳は、第２のシャードをさらに備え、前記第２のシャードは、１又は２以上の第２のプロセッサ（複数可）上にインスタンス化され、前記第２のシャードは、第２の当事者を起点とする命令に応答するように構成され、前記システムは、レコードの公開によって、前記リソースを作成する第１のシステムを備え、
    前記レコードの公開は、前記第１の当事者を起点とする命令に応答して生じ、
    前記レコードの公開は、前記分散台帳の前記第１のシャードに対するものであり、
    前記レコードの公開は、前記リソースの管理権が前記第２の当事者に属することを設定する、システム。

Images