特表2025-503906 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン　ホールディングス　リミテッドの特許一覧

特表2025-503906許可管理のための方法およびシステム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3A
3B
4A
4B
5
6

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

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

(11)【公表番号】

(43)【公表日】2025-02-06

(54)【発明の名称】許可管理のための方法およびシステム

(51)【国際特許分類】

G06F 21/33 20130101AFI20250130BHJP

H04L 9/32 20060101ALI20250130BHJP

【ＦＩ】

G06F21/33 350

H04L9/32 200B

H04L9/32 200F

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024543289

(86)(22)【出願日】2023-01-31

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

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

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

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

(31)【優先権主張番号】2201292.6

(32)【優先日】2022-02-01

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

(31)【優先権主張番号】2201289.2

(32)【優先日】2022-02-01

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

(31)【優先権主張番号】2201290.0

(32)【優先日】2022-02-01

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

(31)【優先権主張番号】2201291.8

(32)【優先日】2022-02-01

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

【氏名又は名称】エヌチェーンライセンシングアーゲー

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(72)【発明者】

【氏名】ミー，アンドリュージェイムズ

(72)【発明者】

【氏名】ランド，リッキーチャールズ

(57)【要約】

本開示は、少なくとも許可を取り消すための方法、デバイス、システム、およびコンピュータプログラムを提案する。より詳細には、第１の態様の方法は、第１の許可証識別子を含む要求を受信するステップであって、第１の許可証識別子は第１の許可証を識別する、ステップと、第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、第１の許可証データは少なくとも１つの許可を示すデータを含み、少なくとも１つの許可は、第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または第１の許可証の保持者が行うことを許可されていることの指示を提供する、ステップとを含む。要求は、第１の許可証データの少なくとも許可のサブセットを取り消すための要求であり、方法は、許可のサブセットを取り消すステップをさらに含む。

【特許請求の範囲】

【請求項1】

少なくとも許可を取り消すためのコンピュータ実装方法であって、
第１の許可証識別子を含む要求を受信するステップであって、前記第１の許可証識別子は第１の許可証を識別する、ステップと、
前記第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、前記第１の許可証データは少なくとも１つの許可を示すデータを含み、前記少なくとも１つの許可は、前記第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または前記第１の許可証の前記保持者が行うことを許可されていることの指示を提供する、ステップと
を含み、
前記要求は、前記第１の許可証データの少なくとも許可のサブセットを取り消すための要求であり、前記方法は、許可のサブセットを取り消すステップをさらに含む、
方法。

【請求項2】

許可のサブセットを取り消す前記ステップは、前記許可をすべて取り消すステップである、請求項１に記載の方法。

【請求項3】

前記許可をすべて取り消す前記ステップは、前記第１の許可証を取り消すステップを含む、請求項２に記載の方法。

【請求項4】

前記要求は、取り消されるべき前記許可のサブセットに関する指示をさらに含む、請求項１に記載の方法。

【請求項5】

前記許可のサブセットに関する前記指示は、文字列である、請求項４に記載の方法。

【請求項6】

前記文字列はユーザによって生成される、請求項５に記載の方法。

【請求項7】

前記第１の許可証データの前記許可のサブセットを取り消す前記ステップは、
前記第１の許可証データ内のrevokedフィールドに値を設定するステップ
を含む、請求項１に記載の方法。

【請求項8】

前記値は時間値である、請求項７に記載の方法。

【請求項9】

前記revokedフィールドに設定された前記時間値は、現在の時間である、請求項８に記載の方法。

【請求項10】

前記revokedフィールドに設定された前記時間値は、前記要求内のtimeフィールドに設定される、請求項８に記載の方法。

【請求項11】

前記第１の許可証および／または前記第１の許可証の前記許可のサブセットは、前記revokedフィールド内の前記値に基づいて取り消されたとみなされる、請求項７に記載の方法。

【請求項12】

前記第１の許可証および／または前記第１の許可証の前記許可のサブセットは、現在の時間と前記revokedフィールドに設定された時間値との比較に基づいて取り消されたとみなされる、請求項１１に記載の方法。

【請求項13】

前記方法は、前記要求の有効性を決定するステップを含み、前記要求の前記有効性を決定するステップは、
前記要求の送信者が、前記第１の許可証の親に関連付けられたプロセスであるか、または前記第１の許可証の前記親の前記保持者によって送信されたプロセスであることを検証するステップ
を含む、請求項１に記載の方法。

【請求項14】

前記要求の前記送信者が前記第１の許可証の前記親でも親許可証の前記保持者でもない場合、前記要求は拒絶される、請求項１３に記載の方法。

【請求項15】

前記要求の前記送信者が前記第１の許可証の前記親に関連付けられた前記プロセスであると決定するステップは、
前記要求がセキュアコンピューティング環境内のコンピューティングモジュールから受信されたと決定するステップ
を含む、請求項１３に記載の方法。

【請求項16】

前記要求が前記セキュアコンピューティング環境内のコンピューティングモジュールから受信されたと決定するステップは、
前記受信された要求に含まれるプロセス識別子と、前記第１の許可証に関連付けられたさらなるプロセス識別子とを比較するステップ
を含む、請求項１５に記載の方法。

【請求項17】

前記要求の前記送信者が、前記第１の許可証の親に関連付けられた前記プロセスであるか、または前記第１の許可証の前記親の前記保持者によって送信された前記プロセスであることを検証するステップは、
前記要求の暗号署名を確認するステップ
を含む、請求項１３に記載の方法。

【請求項18】

暗号署名を確認するステップは、前記暗号署名が親許可証の前記保持者によって署名されたことを確認するステップを含む、請求項１７に記載の方法。

【請求項19】

前記要求の前記有効性を決定するステップは、前記要求に含まれる許可証識別子が前記第１の許可証データに記憶された親許可証識別子と一致するかどうかを決定するステップをさらに含む、請求項１３に記載の方法。

【請求項20】

前記第１の許可証の子孫をすべて取り消すステップ
をさらに含む、請求項１に記載の方法。

【請求項21】

前記第１の許可証の子孫をすべて取り消す前記ステップは、
前記第１の許可証データから子許可証のリストを取得するステップと、
前記子許可証がその子孫をすべて取り消すように、前記子許可証プロセスに対してさらなる取り消し要求を送信するステップと
を含む、請求項２０に記載の方法。

【請求項22】

前記さらなる取り消し要求は、受信時に、各子孫許可証が、請求項１に記載のステップを実行するように構築される、請求項２１に記載の方法。

【請求項23】

前記少なくとも１つの許可を示すデータは、少なくとも１つの名前－値ペアを含むオブジェクトである、請求項１に記載の方法。

【請求項24】

前記名前－値ペアの名前は、文字列によって表され、前記名前－値ペアの値は、文字列および／または少なくとも１つのさらなる名前－値ペアによって表される、請求項２３に記載の方法。

【請求項25】

前記文字列は、任意であり、および／またはユーザによって生成される、請求項２４に記載の方法。

【請求項26】

前記値は、任意であり、および／またはユーザによって生成される、請求項２４に記載の方法。

【請求項27】

前記要求は、セキュアコンピューティング環境に属するコンピューティングモジュールにのみ提供されるＡＰＩを介して受信される、請求項１に記載の方法。

【請求項28】

請求項１に記載の方法を実施するコンピューティングモジュールが、前記セキュアコンピューティング環境の一部である、請求項２７に記載の方法。

【請求項29】

前記第１の許可証は、許可証の階層の一部である、請求項１に記載の方法。

【請求項30】

前記第１の許可証データは、親許可証を示すデータを含む、請求項２９に記載の方法。

【請求項31】

前記第１の許可証データは、子許可証を示すデータを含む、請求項２９に記載の方法。

【請求項32】

前記第１の許可証データは、前記第１の許可証の子であるさらなる許可証が生成される可能性があるかどうかに関する指示を含む、請求項１に記載の方法。

【請求項33】

前記第１の許可証データは、少なくとも１つの名前空間を含み、各名前空間は、前記第１の許可証の子が有することができる許可の一部を定義する、請求項１に記載の方法。

【請求項34】

前記第１の許可証データは、前記第１の許可証が有することができる子孫の最大深さに関する指示を含む、請求項１に記載の方法。

【請求項35】

前記第１の許可証データは、前記第１の許可証が有することができる子許可証の最大数を含む、請求項１に記載の方法。

【請求項36】

前記第１の許可証データは、前記第１の許可証が異なる深さで有することができる子孫許可証の最大数を示すアレイを含む、請求項１に記載の方法。

【請求項37】

前記第１の許可証データは、前記許可証がいつから有効であるかを示す時間を含む、請求項１に記載の方法。

【請求項38】

前記第１の許可証データは、前記許可証がいつまで有効であるかを示す時間を含む、請求項１に記載の方法。

【請求項39】

前記第１の許可証識別子は、前記第１の許可証の前記保持者の身元を分からなくする、請求項１に記載の方法。

【請求項40】

前記第１の許可証識別子は、擬似ランダムに生成された文字列である、請求項１に記載の方法。

【請求項41】

ログに記憶するための前記要求を示すデータを送信するステップ
をさらに含む、請求項１に記載の方法。

【請求項42】

ブロックチェーンに含めるための前記要求を示すデータを送信するステップ
をさらに含む、請求項１に記載の方法。

【請求項43】

前記要求を示す前記データは、前記許可証の状態に関する指示を提供するように構成される、請求項４１に記載の方法。

【請求項44】

前記許可証との前の対話を示すデータのセットは、前記許可証の現在の状態に関する指示を提供するように構成される、請求項４３に記載の方法。

【請求項45】

システムであって、
第１の要求を生成するように構成された第１のコンピューティングモジュールと、
請求項１から４４のいずれか一項に記載の方法を実施するように構成された許可証コンピューティングモジュールと
を備えるシステム。

【請求項46】

前記許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する、請求項４５に記載のシステム。

【請求項47】

前記第１のコンピューティングモジュールは、さらなる許可証コンピューティングモジュールであり、前記さらなる許可証コンピューティングモジュールは、前記セキュアコンピューティング環境に属する、請求項４６に記載のシステム。

【請求項48】

前記第１のコンピューティングモジュールは、ユーザデバイスである、請求項４５に記載のシステム。

【請求項49】

プロセッサおよびメモリを備えるデバイスであって、前記メモリは、前記プロセッサによる実行の結果として、前記デバイスに、請求項１から４４のいずれか一項に記載のコンピュータ実装方法を実行させる実行可能命令を含む、デバイス。

【請求項50】

請求項１から４４のいずれか一項に記載の方法を実施するための、コンピュータによって実行可能なコンピュータプログラムコード命令を含む非一時的コンピュータ可読記憶媒体。

【請求項51】

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

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、許可証（permit）および許可システムの提供に関する。より詳細には、本開示は、身元と許可証との擬似匿名アソシエーションを可能にする柔軟な許可証、柔軟な許可（permission）の定義、取り消し、および追加、ならびにセキュリティの向上を提供する。

【背景技術】

【0002】

許可証とは、何かをすることを許可するものであり、所有して多くの場合持ち歩くものである。許可証には様々なものがあり、それらに関連付けられた許容性レベルも様々である。例えば、ある人が運転免許証を持っている場合、その人は運転許可を持っていることを意味する。運転免許証によって制限も異なり得る。例えば、仮運転免許証の場合、特定の時間の間のみ、特定のタイプの車両のみ、または別の完全に許可された運転者が同乗する場合のみ運転することができる。他の免許証としては、漁業を可能にする一方で、ある期間にわたって捕獲可能な魚の種類、サイズ、および／または数に制限を課すこともできる漁業ライセンスが挙げられる。

【0003】

許可証は、好ましくは、許可（任意選択で、それに関連付けられた追加の制限を伴う）と、許可に記載の事項を行うことを許可されている人物という２つの構成要素を含むことが分かる。

【0004】

許可証は、保持者と検証者との間に多大な信頼を必要とする場合がある。特に、検証者は、許可証の物理的な保持者が本人であること、許可証がいかなる方法でも偽造されておらず、信頼されるソースから発行されたものであること、および許可証によって保持者に許可されていることが正しいことを信頼しなければならない。

【0005】

したがって、改善された、多用途の、および／またはセキュアな許可証システムが必要であり、または少なくとも有用な代替手段を提供する必要がある。

【発明の概要】

【0006】

第１の態様では、本開示は、少なくとも許可を取り消すための方法、デバイス、システム、およびコンピュータプログラムを提案する。より詳細には、第１の態様の方法は、第１の許可証識別子を含む要求を受信するステップであって、第１の許可証識別子は第１の許可証を識別する、ステップと、第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、第１の許可証データは少なくとも１つの許可を示すデータを含み、少なくとも１つの許可は、第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または第１の許可証の保持者が行うことを許可されていることの指示を提供する、ステップとを含む。要求は、第１の許可証データの少なくとも許可のサブセットを取り消すための要求であり、本方法は、許可のサブセットを取り消すステップをさらに含む。

【0007】

ここで、開示される方法のいくつかの特定の構成要素および実施形態が、同様の参照番号が同様の特徴を指す添付の図面を参照して、例示として説明される。

【図面の簡単な説明】

【0008】

【図1】例示的なセキュア処理環境と、それと対話するように構成されたいくつかのデバイスとを示す。

【図2】例示的な階層的許可証構造を示す。

【図3A】例示的な階層的許可証構造を示す。

【図3B】例示的な階層的許可証構造を示す。

【図4A】新しい許可証および／または追加の拡張を生成するための例示的な方法を示す。

【図4B】新しい許可証および／または追加の拡張を生成するための例示的な方法を示す。

【図5】許可証および／または許可証の拡張を取り消すための例示的な方法を示す。

【図6】本開示の様々な態様および実施形態を実装することができるコンピューティング環境を示す概略図である。

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

【0009】

本明細書では、許可を含む許可証の作成、取り消し、拡張、確認（validate）、または他の形での対話を行うための方法、デバイス、システム、およびコンピュータプログラムが提供される。許可証は、好ましくは、識別情報（または許可証の保持者を識別するプロセスで使用することができる情報）と、保持者が行うことを許可されていることおよび／または保持者が取ることができるアクションの記述との両方を提供する。より好ましくは、許可証および／または許可証の子との対話は、要求を介して行われる。

【0010】

【0011】

一実施形態では、許可のサブセットを取り消すステップは、許可をすべて取り消すステップである。一実施形態では、許可をすべて取り消すステップは、第１の許可証を取り消すステップを含む。有利なことに、許可証の許可（および許可証自体）をすべて取り消す必要がある場合、許可のセットまたは個々の許可を繰り返して削除する／取り消す必要はないので、計算上効率的な方法が提示される。

【0012】

一実施形態では、要求は、取り消されるべき許可のサブセットに関する指示をさらに含む。一実施形態では、許可のサブセットに関するインジケータは文字列である。一実施形態では、文字列はユーザによって生成される。有利なことに、文字列で許可のグループを表すことができるようにすることで、ユーザが取り消すことを望むそれぞれの個々の許可をリストするのと比較して、それらを識別し、特に取り消す効率的な方法を提供するだけでなく、許可証全体を取り消すのと比較してより細かい制御も提供する。

【0013】

一実施形態では、第１の許可証データの許可のサブセットを取り消すステップは、第１の許可証データ内のrevokedフィールドに値を設定するステップを含む。一実施形態では、値は時間値である。一実施形態では、revokedフィールドに設定された時間値は、現在の時間であるか、または要求内のtimeフィールドである。一実施形態では、第１の許可証および／または第１の許可証の許可のサブセットは、revokedフィールド内の値に基づいて取り消されたとみなされる。一実施形態では、第１の許可証および／または第１の許可証の許可のサブセットは、現在の時間とrevokedフィールドに設定された時間値との比較に基づいて取り消されたとみなされる。revokedフィールド内のタイムスタンプを用いて、いつ許可証が取り消されたとみなされるかについての柔軟性がシステムに追加され、それによって、許可証が干渉を受ける可能性があるときの攻撃面も低減されるので、セキュリティも向上する。

【0014】

一実施形態では、方法は、要求の有効性を決定するステップを含み、要求の有効性を決定するステップは、要求の送信者が、第１の許可証の親に関連付けられたプロセスであるか、または第１の許可証の親の保持者によって送信されたプロセスであることを検証するステップを含む。一実施形態では、要求の送信者が第１の許可証の親でも親許可証の保持者でもない場合、要求は拒絶される。一実施形態では、要求の送信者が第１の許可証の親に関連付けられたプロセスであると決定するステップは、要求がセキュアコンピューティング環境内のコンピューティングモジュールから受信されたと決定するステップを含む。一実施形態では、要求がセキュア環境内のコンピューティングモジュールから受信されたと決定するステップは、受信された要求に含まれるプロセス識別子と、第１の許可証に関連付けられたさらなるプロセス識別子とを比較するステップを含む。一実施形態では、要求の送信者が、第１の許可証の親に関連付けられたプロセスであるか、または第１の許可証の親の保持者によって送信されたプロセスであることを検証するステップは、要求の暗号署名を確認するステップを含む。一実施形態では、暗号署名を確認するステップは、署名が親許可証の保持者によって署名されたことを確認するステップを含む。有利なことに、暗号手段を用いて、または要求が既知のセキュアなプロセスから発信されたものであることを保証することで、許可証または許可のサブセットを取り消すための無効な要求が拒絶されるので、システムのセキュリティが向上する。

【0015】

一実施形態では、要求の有効性を決定するステップは、要求に含まれる許可証識別子が第１の許可証データに記憶された親許可証識別子と一致するかどうかを決定するステップをさらに含む。有利なことに、このようにして親許可証のみが子許可証を修正することができるようにすることで、セキュリティがさらに向上する。

【0016】

一実施形態では、本方法は、第１の許可証の子孫をすべて取り消すステップをさらに含む。一実施形態では、第１の許可証の子孫をすべて取り消すステップは、第１の許可証データから子許可証のリストを取得するステップと、子許可証がその子孫をすべて取り消すように、子許可証プロセスに対してさらなる取り消し要求を送信するステップとを含む。一実施形態では、さらなる取り消し要求は、受信時に、子孫がすべて取り消されるまで、各子孫許可証が本態様のステップを再帰的に行うように構築される。有利なことに、これにより、親許可証の子孫も取り消されることが保証される。これにより、許可証階層およびシステムの全体的なセキュリティが向上し、さらに、呼び出された側（called）が実際にすべての子許可証識別子の知らなくても、すべての子許可証を取り消す効率的な方法が提供される。

【0017】

一実施形態では、少なくとも１つの許可を示すデータは、少なくとも１つの名前－値ペアを含むオブジェクトである。一実施形態では、名前－値ペアの名前は、文字列によって表され、名前－値ペアの値は、文字列および／または少なくとも１つのさらなる名前－値ペアによって表される。一実施形態では、文字列は、任意であり、および／またはユーザによって生成される。一実施形態では、値は、任意であり、および／またはユーザによって生成される。有利なことに、名前－値ペア、特にユーザによって生成された名前－値ペアを使用することで、セキュリティ許可証システムの設計により大きな柔軟性を持たせることができ、さらに、後述するような名前空間機能が可能になる。

【0018】

一実施形態では、要求は、セキュアコンピューティング環境に属するコンピューティングモジュールにのみ提供されるＡＰＩを介して受信される。一実施形態では、前述の実施形態のいずれか１つまたは複数の実施形態の方法を実施するコンピューティングモジュールは、セキュアコンピューティング環境の一部である。有利なことに、要求がセキュアコンピューティング環境から発信される場合、要求は、多くの場合、有効であると推定することができる。要求が有効であると推定することによって、他のチェック（署名確認、認可、要求自体の確認、および他のチェックなど）がスキップされ、それによって、要求を処理するために必要とされる処理時間およびコンピューティングリソースが低減し得るので、処理時間を節約することができる。

【0019】

一実施形態では、第１の許可証は、許可証の階層の一部である。一実施形態では、第１の許可証データは、親許可証を示すデータを含む。一実施形態では、第１の許可証データは、子許可証を示すデータを含む。有利なことに、階層的許可証構造は、許可証の代替的および改善された管理を可能にする。一実施形態では、階層は、親許可証が取り消されると、その子も取り消されるようになっている。親および子を有することで、好ましくは、階層的なツリー構造が提供される。さらに有利なことに、階層構造により、親と子の関係が可能になり、それによって、名前空間、子作成制限、およびカスケーディング取り消し（cascading revocation）に関して後述する利点が可能になる。

【0020】

先行する請求項のうちの１つまたは複数による方法では、第１の許可証データは、少なくとも１つの名前空間を含み、各名前空間は、第１の許可証の子が有することができる許可の一部を定義する。有利なことに、これは、子許可証および／または親許可証が何らかの形で危険にさらされた場合に、子許可証が、他の許可証で生成および／または受信することができるさらなる許可が制限されるように、許可証が行うことができることを制限する方法を提供する。

【0021】

一実施形態では、第１の許可証データは、第１の許可証の子であるさらなる許可証が生成される可能性があるかどうかに関する指示を含む。一実施形態では、第１の許可証データは、第１の許可証が有することができる子孫の最大深さに関する指示を含む。一実施形態では、第１の許可証データは、第１の許可証が有することができる子許可証の最大数を含む。一実施形態では、第１の許可証データは、第１の許可証が異なる深さで有することができる子孫許可証の最大数を示すアレイを含む。有利なことに、許可証が作成することができる子の数（ゼロでも可）、子の深さ、および／または異なる深さでの子の数を制限すると、これらの制限により、親許可証保持者は、危険にさらさる可能性のある、および／または敵対的な第1の許可証保持者が行うことができることを制限することができるので、セキュリティが向上する。

【0022】

一実施形態では、第１の許可証データは、許可証がいつから有効であるかを示す時間を含む。一実施形態では、第１の許可証データは、許可証がいつまで有効であるかを示す時間を含む。有利なことに、許可証がいつからまたはいつまで有効であるかについての時間値を提供することで、許可証がいつ有効であるかを親許可証保持者が選択するのにより大きな柔軟性を持たせることができる。さらに、許可証が有効である時間を制限することによってシステムのセキュリティが向上する。許可証が有効である時間を制限することで、敵対的なサードパーティが許可証に干渉することができる時間量を制限する。

【0023】

一実施形態では、第１の許可証識別子は、第１の許可証の保持者の身元を分からなくする（obliviate）。一実施形態では、第１の許可証識別子は、擬似ランダムに生成された文字列である。有利なことに、許可証に関連付けられたユーザを許可証識別子によって識別されないようにすることで、識別子へのアクセスを有する敵対的なサードパーティが、関連するユーザを識別すること、なりすますこと、近づくこと、および／または他の形で対話することがはるかに困難になるので、セキュリティがさらに向上する。

【0024】

一実施形態では、本方法は、ログに記憶するための、またはブロックチェーンに含めるための要求を示すデータを送信するステップをさらに含む。好ましくは、要求を示すデータは、許可証の状態に関する指示を提供するように構成される。より好ましくは、許可証との前の対話を示すデータのセットは、許可証の現在の状態に関する指示を提供するように構成される。

【0025】

有利なことに、許可証の作成を含む許可証とのすべて対話（特に、許可証を修正する任意の「送信」対話）を記憶することで、対話のセットを使用して許可証を再構築することができる。この再構築を許可証の現在のステータスと比較して、許可証に関して何も改竄されていないことを保証することができ、それによって、セキュリティがさらに向上し、サードパーティが許可証のセキュアなステータスに依存する能力を高めることができる。ブロックチェーンは、追加のセキュリティを提供し、対話のログの公開性、検証可能性、非可鍛性を提供するので、ブロックチェーンを使用して対話を記録することで、さらにセキュリティが向上する。

【0026】

より詳細には、第１の態様のシステムは、第１の要求を生成するように構成された第１のコンピューティングモジュールと、第１の態様の方法の実施形態のいずれか１つを実施するように構成された許可証コンピューティングモジュールとを備える。一実施形態では、許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。一実施形態では、第１のコンピューティングモジュールは、さらなる許可証コンピューティングモジュールであり、さらなる許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。

【0027】

有利なことに、デバイスがすべて同じセキュアコンピューティング環境内で実行されている場合、これは、要求がセキュアソースから発信されており、したがって（多くの場合）有効であると推定することができることを確かめるための方法として働くことができる。要求が有効であると推定することによって、他のチェック（署名確認、認可、要求自体の確認、および他のチェックなど）がスキップされ、それによって、要求を処理するために必要とされる処理時間およびコンピューティングリソースが低減し得るので、処理時間を節約することができる。

【0028】

一実施形態では、第１のコンピューティングモジュールは、ユーザデバイスである。有利なことに、それによって、他のユーザが許可証と対話することが可能になる。

【0029】

より詳細には、本態様のデバイスは、プロセッサとメモリとを備え、メモリは、プロセッサによる実行の結果として、デバイスに、第１の態様の方法の実施形態のいずれか１つによるコンピュータ実装方法を実行させる実行可能命令を含む。

【0030】

第１の態様によれば、第１の態様の方法の実施形態のいずれかを実施するための、コンピュータによって実行可能なコンピュータプログラムコード命令を含む非一時的コンピュータ可読記憶媒体も説明される。

【0031】

第２の態様では、本開示は、許可証を確認するための方法、デバイス、システム、およびコンピュータプログラムを提案する。より詳細には、第２の態様の方法は、第１の許可証識別子を含む要求を受信するステップであって、第１の許可証識別子は第１の許可証を識別する、ステップと、第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、第１の許可証データは少なくとも１つの許可を示すデータを含み、少なくとも１つの許可は、第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または第１の許可証の保持者が行うことを許可されていることの指示を提供する、ステップとを含み、要求は、第１の許可証の少なくとも１つの許可に関連付けられた表現を確認するための要求であり、要求は、表現を示すデータを含む。

【0032】

有利なことに、許可証に関連付けられたプロセスにおいて要求を受信して処理することで、サードパーティが許可証と対話して確認することができ、ユーザの許可のセキュアでプログラム的な確認を可能にする。さらなる利点は、各任意選択の実施形態の次に、ならびに、各実施形態が説明されるにつれて本明細書全体を通して以下で提供される。

【0033】

一実施形態では、本方法は、許可証がさらなる許可を示すデータと一致する許可を含むかどうかを決定するステップをさらに含む。好ましくは、本方法は、一致する許可の決定の結果を送信者に返すステップをさらに含む。有利なことに、許可証の異なる許可を確認することを望むサードパーティが特定の許可を参照することを可能にすることで、許可証の構築により大きな柔軟性を持たせることができるとともに、許可がどのように対話されるかにより大きな柔軟性を持たせることができる。

【0034】

一実施形態では、本方法は、第１の許可証が取り消されたかどうかの決定に基づいて、要求の処理を継続するステップをさらに含む。有利なことに、取り消しにより、（すべて無効とみなされるので）残りの許可チェックをスキップすることができ、それによって処理効率が向上する。

【0035】

一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、第１の許可証データ内のrevokedフィールドをチェックするステップを含む。有利なことに、revokedフィールドを許可証データ自体に記憶することで、取り消されたかどうかを許可証自体が報告することが可能になり、信頼できない可能性がある、かつ／または対話および結果の記憶に余分なリソースを必要とする可能性があるさらなるリソース（取り消しリストなど）またはサードパーティに依存しないので、効率性が得られる。

【0036】

一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、revokedフィールドに記憶された第１の時間が現在の時間よりも前であるかどうかをチェックするステップを含む。revokedフィールド内のタイムスタンプを用いて、いつ許可証が取り消されたとみなされるかについての柔軟性がシステムに追加され、それによって、許可証が干渉を受ける可能性があるときの攻撃面も低減されるので、セキュリティも向上する。

【0037】

一実施形態では、表現は、第１の許可証に関連付けられた許可の特徴を問い合わせるように構成されたデータを含む。一実施形態では、本方法は、表現を評価するステップをさらに含む。一実施形態では、本方法は、表現の評価の結果を要求の送信者に返すステップをさらに含む。有利なことに、表現を用いて、および、許可証の許可に関して表現を評価することができることによって、許可証の作成者および要求者は、許可証の対話方法および許可証に記憶することができる機能の種類を適合させ、拡張する柔軟性を有する。

【0038】

一実施形態では、本方法は、許可のサブセットが有効であるかどうかを決定するステップをさらに含む。一実施形態では、本方法は、現在の時間を許可のサブセットに関連付けられた有効性範囲と比較するステップをさらに含む。

【0039】

一実施形態では、要求は、許可のサブセットを識別するためのデータを含む。一実施形態では、表現を評価するステップは、データに基づいて問い合わせされている１つまたは複数の許可を識別またはアクセスして、許可のサブセットを識別するステップを含む。

【0040】

一実施形態では、本方法は、許可証の保持者によって署名された署名を確認するためのさらなる要求を受信するステップをさらに含む。一実施形態では、さらなる要求は、署名と、署名が適用されたメッセージとを含む。一実施形態では、本方法は、署名を検証するステップであって、署名の検証は、第１の許可証データ、署名、およびデータから取得された第１の許可証の公開鍵に基づく、ステップを含む。一実施形態では、検証の結果は、さらなる要求の送信者に提供される。一実施形態では、要求およびさらなる要求の送信者は同じである。有利なことに、暗号的にセキュアな技術を使用して許可証側面の「誰」部分を保証することで、許可証は、全体的な方法および許可証の使用のセキュリティを向上させることができる。

【0041】

【0042】

一実施形態では、要求は、セキュアコンピューティング環境に属するコンピューティングモジュールにのみ提供されるＡＰＩを介して受信される。一実施形態では、本明細書の実施形態のいずれか１つまたは複数の実施形態の方法を実施するコンピューティングモジュールは、セキュアコンピューティング環境の一部である。有利なことに、要求がセキュアコンピューティング環境から発信される場合、要求は、多くの場合、有効であると推定することができる。要求が有効であると推定することによって、他のチェック（署名確認、認可、要求自体の確認、および他のチェックなど）がスキップされ、それによって、要求を処理するために必要とされる処理時間およびコンピューティングリソースが低減し得るので、処理時間を節約することができる。

【0043】

【0044】

一実施形態では、第１の許可証データは、少なくとも１つの名前空間を含み、各名前空間は、第１の許可証の子が有することができる許可の一部を定義する。有利なことに、これは、子許可証および／または親許可証が何らかの形で危険にさらされた場合に、子許可証が、他の許可証で生成および／または受信することができるさらなる許可が制限されるように、許可証が行うことができることを制限する方法を提供する。

【0045】

【0046】

【0047】

一実施形態では、第１の許可証識別子は、第１の許可証の保持者の身元を分からなくする。一実施形態では、第１の許可証識別子は、擬似ランダムに生成された文字列である。有利なことに、許可証に関連付けられたユーザを許可証識別子によって識別されないようにすることで、識別子へのアクセスを有する敵対的なサードパーティが、関連するユーザを識別すること、なりすますこと、近づくこと、および／または他の形で対話することがはるかに困難になるので、セキュリティがさらに向上する。

【0048】

【0049】

有利なことに、許可証の作成を含む許可証とのすべて対話（特に、許可証を修正する任意の対話）を記憶することで、対話のセットを使用して許可証を再構築することができる。この再構築を許可証の現在のステータスと比較して、許可証に関して何も改竄されていないことを保証することができ、それによって、セキュリティがさらに向上し、サードパーティが許可証のセキュアなステータスに依存する能力を高めることができる。ブロックチェーンは、追加のセキュリティを提供し、対話のログの公開性、検証可能性、非可鍛性を提供するので、ブロックチェーンを使用して対話を記録することで、さらにセキュリティが向上する。

【0050】

より詳細には、第２の態様のシステムは、第１の要求を生成するように構成された第１のコンピューティングモジュールと、第２の態様の方法の実施形態のいずれか１つを実施するように構成された許可証コンピューティングモジュールとを備える。一実施形態では、許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。一実施形態では、第１のコンピューティングモジュールは、さらなる許可証コンピューティングモジュールであり、さらなる許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。

【0051】

【0052】

【0053】

より詳細には、第２の態様のデバイスは、プロセッサとメモリとを備え、メモリは、プロセッサによる実行の結果として、デバイスに、第２の態様の方法の実施形態のいずれか１つによるコンピュータ実装方法を実行させる実行可能命令を含む。

【0054】

第２の態様によれば、第２の態様の方法の実施形態のいずれかを実施するための、コンピュータによって実行可能なコンピュータプログラムコード命令を含む非一時的コンピュータ可読記憶媒体も説明される。

【0055】

第３の態様では、本開示は、許可証を作成するための方法、デバイス、システム、およびコンピュータプログラムを提案する。より詳細には、本方法は、第１の許可証識別子を含む要求を受信するステップであって、第１の許可証識別子は第１の許可証を識別する、ステップと、第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、第１の許可証データは少なくとも１つの許可を示すデータを含み、少なくとも１つの許可は、第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または第１の許可証の保持者が行うことを許可されていることの指示を提供する、ステップとを含み、要求は、さらなる許可証を作成するための要求であり、要求は、さらなる許可証を示すデータを含む。

【0056】

有利なことに、子許可証の作成は、許可証システム内の階層構造を可能にする。階層構造は、後述するような効率的な取り消し方法を可能にする。さらに、許可証保持者が要求のコンテンツを用いて子許可証を構築することができるように、許可証作成のセキュアで柔軟な方法が提供される。

【0057】

一実施形態では、本方法は、第１の許可証を確認するステップと、さらなる許可証を示すデータに基づいてさらなる許可証を作成するステップと、さらなる許可証が第１の許可証の子として記録されるように、第１の許可証データにさらなる許可証への参照を記録するステップとをさらに含む。有利なことに、子許可証への参照を使用することで、階層的許可証構造のトラバーサルおよびそれに関連付けられたすべての利点がさらに可能になる。

【0058】

一実施形態では、第１の許可証データを確認するステップは、第１の許可証が取り消されたかどうかを決定するステップを含む。一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、第１の許可証データ内のrevokedフィールドをチェックするステップを含む。有利なことに、取り消しにより、（取り消された許可証は新しい子許可証を作成することができないので）許可証作成に関連付けられた残りのチェックをスキップすることができ、それによって処理効率が向上する。さらに、revokedフィールドを許可証データ自体に記憶することで、取り消されたかどうかを許可証自体が報告することが可能になり、信頼できない可能性がある、かつ／または対話および結果の記憶に余分なリソースを必要とする可能性があるさらなるリソース（取り消しリストなど）またはサードパーティに依存しないので、効率性が得られる。

【0059】

一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、revokedフィールドに記憶された第１の時間を現在の時間と比較するステップを含む。好ましくは、第１の時間が現在の時間と比較して過去である場合、第１の許可証は取り消されたとみなされる。好ましくは、第１の許可証が取り消されたとみなされる場合、さらなる許可証は作成されず、および／または要求の処理は停止する。revokedフィールド内のタイムスタンプを用いて、いつ許可証が取り消されたとみなされるかについての柔軟性および追加のセキュリティがシステムに追加される。

【0060】

一実施形態において、本方法は、第１の許可証が子許可証を作成することができることを確認するステップを含む。一実施形態では、第１の許可証が子許可証を作成することができることを確認するステップは、第１の許可証に関連付けられた子許可証の最大数を超えていないことを確認するステップ、および／または第１の許可証に関連付けられた子許可証の最大深さを超えていないことを確認するステップのうちのいずれか１つまたは複数を含む。許可証が子を作成することができるかどうかを示すデータを親許可証自体に記憶することで、別個のリソースを管理または参照する必要がなくなり、計算効率が向上する。さらに、子の作成を制限するこれらの方法は、第１の許可証の作成者が、第１の許可証の存続期間中遵守しなければならない子の作成制限を設定することができるので、柔軟でありながらセキュアなシステムをもたらす。

【0061】

一実施形態では、本方法は、さらなる許可証を示すデータを検証するステップをさらに含む。一実施形態では、要求は署名をさらに含み、さらなる許可証を示すデータを検証するステップは、署名が有効であり、第１の許可証保持者の私有鍵を使用して署名されていることを検証するステップを含む。有利なことに、署名の暗号的にセキュアな確認は、システムの全体的なセキュリティを向上させ、サードパーティが許可証保持者を装うことを制限または完全に禁止する。

【0062】

一実施形態では、さらなる許可証を示すデータを検証するステップは、さらなる許可証の有効性範囲が第１の許可証の有効性範囲内にあることを検証するステップを含む。好ましくは、さらなる許可証の有効性範囲が第１の許可証の有効性範囲内にあることを検証するステップは、さらなる許可証の有効性範囲の開始点が第１の許可証の開始点と同じかまたはそれ以降であることを決定するステップと、さらなる許可証の有効性範囲の終了点が第１の許可証の終了点と同じかまたはそれ以前であることを決定するステップとを含む。有利なことに、許可証の有効性範囲を提供することで、サードパーティが不正アクセスした場合の許可証と対話し得る時間が短縮されるので、セキュリティが向上する。

【0063】

一実施形態では、さらなる許可証を示すデータを検証するステップは、さらなる許可証の１つまたは複数の許可が、親許可証が作成することを許可されている許可の範囲内にあることを検証するステップを含む。一実施形態では、さらなる許可証の１つまたは複数の許可は、要求に含まれる。一実施形態では、さらなる許可証の任意の許可が、親許可証が作成することができる許可の範囲内にあることを検証するステップは、親許可証が作成することを許可されている１つまたは複数の名前空間を決定するステップと、さらなる許可証の１つまたは複数の許可の１つまたは複数の名前空間を決定するステップと、さらなる許可証の１つまたは複数の許可の１つまたは複数の名前空間が、親許可証が作成することを許可されている１つまたは複数の名前空間と同じものであるか、またはそれがプレフィックスされていると決定するステップとを含む。有利なことに、これにより、階層的な側面または次元が許可に提供され、それによって、例えば、組織の許可された許可の範囲内にない許可を作成することができないので、セキュリティも向上する。

【0064】

一実施形態では、さらなる許可証を作成するステップは、許可証に基づいてさらなる許可証データインスタンスを作成するステップを含み、さらなる許可証データは、第１の許可証識別子に設定された親許可証値を含む。

【0065】

一実施形態では、本方法は、要求の送信者にさらなる許可証識別子を提供するステップをさらに含む。一実施形態では、さらなる許可証識別子のみが、要求の送信者に提供される。有利なことに、許可証識別子は、識別子のみでは許可証に関連付けられたユーザを識別することができないという点で、許可証と擬似匿名的に対話するために使用される。

【0066】

【0067】

【0068】

【0069】

【0070】

【0071】

一実施形態では、第１の許可証データは、有効性範囲を含む。一実施形態では、第１の許可証データは、許可証がいつから有効であるかを示す時間を含む。一実施形態では、第１の許可証データは、許可証がいつまで有効であるかを示す時間を含む。有利なことに、許可証がいつからまたはいつまで有効であるかについての時間値を提供することで、許可証がいつ有効であるかを親許可証保持者が選択するのにより大きな柔軟性を持たせることができる。さらに、許可証が有効である時間を制限することによってシステムのセキュリティが向上する。許可証が有効である時間を制限することで、敵対的なサードパーティが許可証に干渉することができる時間量を制限する。

【0072】

【0073】

【0074】

【0075】

より詳細には、第３の態様のシステムは、第１の要求を生成するように構成された第１のコンピューティングモジュールと、第３の態様の方法の実施形態のいずれか１つを実施するように構成された許可証コンピューティングモジュールとを備える。一実施形態では、許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。一実施形態では、第１のコンピューティングモジュールは、さらなる許可証コンピューティングモジュールであり、さらなる許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。

【0076】

【0077】

【0078】

より詳細には、第３の態様のデバイスは、プロセッサとメモリとを備え、メモリは、プロセッサによる実行の結果として、デバイスに、第３の態様の方法の実施形態のいずれか１つによるコンピュータ実装方法を実行させる実行可能命令を含む。

【0079】

第３の態様によれば、第３の態様の方法の実施形態のいずれかを実施するための、コンピュータによって実行可能なコンピュータプログラムコード命令を含む非一時的コンピュータ可読記憶媒体も説明される。

【0080】

第４の態様では、本開示は、第１の許可証にさらなる許可を追加するための方法、デバイス、システム、およびコンピュータプログラムを提案する。より詳細には、第４の態様の方法は、第１の許可証識別子を含む要求を受信するステップであって、第１の許可証識別子が第１の許可証を識別する、ステップと、第１の許可証識別子に基づいて第１の許可証データを取得するステップであって、第１の許可証データは少なくとも１つの許可を示すデータを含み、少なくとも１つの許可は、第１の許可証の保持者が取ることができる１つまたは複数のアクション、および／または第１の許可証の保持者が行うことを許可されていることの指示を提供する、ステップとを含み、要求は、さらなる許可のセットを第１の許可証に追加するためのものであり、要求は、さらなる許可のセットを含む。

【0081】

一実施形態では、本方法は、要求の送信者が親許可証に関連付けられたコンピューティングモジュールおよび／または親許可証の保持者であると決定するステップを含み、親許可証は第１の許可証の親許可証である。一実施形態では、要求の送信者が親許可証でも親許可証の保持者でもない場合、要求は処理されない。一実施形態では、要求の送信者が親許可証に関連付けられたコンピューティングまたは親許可証の保持者であると決定するステップは、受信した要求に含まれる許可証識別子と、第１の許可証データに含まれる親識別子とを比較し、その比較に基づいて、要求の送信者が親許可証に関連付けられたコンピューティングまたは親許可証の保持者であることを確かめるステップを含む。一実施形態では、要求の送信者が第１の許可証の親に関連付けられたプロセスであると決定するステップは、要求の暗号署名を確認するステップを含む。一実施形態では、暗号署名を確認するステップは、署名が親許可証の保持者によって署名されたことを確認するステップを含む。有利なことに、暗号手段を用いて、または要求が既知のセキュアなプロセスから発信されたものであることを保証することで、許可証または許可のサブセットを取り消すための無効な要求が拒絶されるので、システムのセキュリティが向上する。

【0082】

一実施形態では、第１の許可証が取り消されたかどうかの決定に基づいて、要求の処理を継続するステップ。一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、第１の許可証データ内のrevokedフィールドをチェックするステップを含む。一実施形態では、第１の許可証が取り消されたかどうかを決定するステップは、revokedフィールドに記憶された第１の時間が現在の時間よりも前であるかどうかをチェックするステップを含む。

【0083】

一実施形態では、本方法は、さらなる許可のセットを追加しても許可のセットの最大数を超えないと決定し、その決定に基づいて要求の処理を継続するステップをさらに含む。一実施形態では、少なくとも１つの許可は、許可証に関連付けることができる許可の最大数を示すデータを含む。有利なことに、許可証にはカスタマイズ可能な制限が組み込まれており、それによって、許可証自体のセキュリティが向上する。

【0084】

一実施形態では、要求は、さらなる許可のセットを識別するための文字列を含む。一実施形態では、文字列はユーザによって生成される。有利なことに、文字列で許可のグループを表すことができるようにすることで、ユーザが取り消すことを望むそれぞれの個々の許可をリストするのと比較して、それらを取り消す効率的な方法を提供する。さらに、それらの識別子によって許可のグループを参照することで、各許可を個々に参照したり許可のグループにわたって反復したりする必要がなくなり、効率性が得られる。

【0085】

一実施形態では、本方法は、さらなる許可のセットを許可証に追加するステップをさらに含む。

【0086】

【0087】

【0088】

【0089】

【0090】

【0091】

【0092】

【0093】

【0094】

有利なことに、許可証の作成を含む許可証とのすべて対話（特に、許可証を修正することができる任意の「送信」対話）を記憶することで、対話のセットを使用して許可証を再構築することができる。この再構築を許可証の現在のステータスと比較して、許可証に関して何も改竄されていないことを保証することができ、それによって、セキュリティがさらに向上し、サードパーティが許可証のセキュアなステータスに依存する能力を高めることができる。ブロックチェーンは、追加のセキュリティを提供し、対話のログの公開性、検証可能性、非可鍛性を提供するので、ブロックチェーンを使用して対話を記録することで、さらにセキュリティが向上する。

【0095】

より詳細には、第４の態様のシステムは、第１の要求を生成するように構成された第１のコンピューティングモジュールと、第４の態様の方法の実施形態のいずれか１つを実施するように構成された許可証コンピューティングモジュールとを備える。一実施形態では、許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。一実施形態では、第１のコンピューティングモジュールは、さらなる許可証コンピューティングモジュールであり、さらなる許可証コンピューティングモジュールは、セキュアコンピューティング環境に属する。

【0096】

【0097】

【0098】

より詳細には、第４の態様のデバイスは、プロセッサとメモリとを備え、メモリは、プロセッサによる実行の結果として、デバイスに、第４の態様の方法の実施形態のいずれか１つによるコンピュータ実装方法を実行させる実行可能命令を含む。

【0099】

第４の態様によれば、第４の態様の方法の実施形態のいずれかを実施するための、コンピュータによって実行可能なコンピュータプログラムコード命令を含む非一時的コンピュータ可読記憶媒体も説明される。

【0100】

当業者であれば、上記で説明した態様が互いとの任意の組合せで使用され得ることを理解するであろう。例えば、第１および第２の態様は、１つの許可証の確認および別の許可証の削除を行う１つの方法が存在するように組み合わされてもよい。

【0101】

例示的なシステムの概要
図１は、本明細書で説明されるような許可証を実装するための例示的なシステム１００を示す。システムは、セキュア処理環境１０８の内部にあるいくつかのコンピューティングモジュール１０２、１０４、１０６を備える。セキュア処理環境の外部には、いくつかのクライアントデバイス１１０、１１２がある。クライアントデバイス１１０、１１２は、セキュア処理環境のコンピューティングモジュール１０２、１０４、１０６のうちのいくつかと対話するように構成される。好ましくは、コンピューティングモジュール１０４、１０６は、関連するアドレスを有し、そのアドレスを含む要求を受信することができる。任意選択で、コンピューティングモジュール１０２は、クライアントデバイス１１０、１１２から要求を受信し、要求に記憶されたアドレスにしたがってそれらを正しいコンピューティングモジュール１０４、１０６に転送するように構成されたゲートウェイモジュールである。

【0102】

好ましくは、コンピューティングモジュール１０２、１０４、１０６は、セキュア処理環境１０８内で実行されるマイクロサービスとして実装される。任意選択で、セキュア処理環境は、コンピュータネットワーク内の単一のサーバまたはサーバの単一の集合である。代替的に、コンピューティングモジュールは、サーバレスシステムの一部として実装され、サーバレスシステムは、セキュア処理環境を定義する。例示的なサーバレス環境には、ＡＷＳＬａｍｂｄａ（登録商標）が含まれる。

【0103】

好ましくは、コンピューティングモジュール１０２、１０４は、関連するプロセス識別子を有する。プロセス識別子は、セキュア処理環境１０８内の許可証に関連付けられたすべてのプロセスについて同じである。ここで、プロセス識別子は、類似のコンピューティングモジュールのクラスを識別する。コンピューティングモジュールはまた、本明細書において、「instanceId」の「instance identifiers」を有するインスタンスとしても記述される。任意選択で、プロセス識別子は、許可証データインスタンスに記憶される。

【0104】

以下に「許可証との対話」の見出しの下で説明されるように、各許可証は、関連するコンピューティングモジュールを含む（各コンピューティングモジュールが関連する許可証を有するという逆も真であると考えられ得る）。したがって、許可証に対して動作が行われるとき、これは好ましくは、許可証に関連付けられたコンピューティングモジュールと対話することを含む。好ましくは、対話は、関連性のある許可証に関連付けられたコンピューティングモジュールに要求を送信することによって行われる。

【0105】

任意選択で、セキュア処理環境１０８内にコンピューティングモジュールマネージャ１１４が存在する。好ましくは、このコンピューティングモジュールマネージャ１１４は、セキュア処理環境１０８内に新しいプロセスを作成するように構成される。

【0106】

許可証および許可証のコンテンツ
許可証は、ユーザを識別し、許可証保持者が何を行うことを許可されているかを明記する方法を提供する。識別の側面は、公開鍵暗号を用いて行われ、「保持者が何をすることができるか」は、本明細書で説明されるような許可を用いて行われる。

【0107】

一実施形態では、各許可証は、関連する許可証データインスタンス（関連する許可証データまたは許可証データとしても記述される）を有する。許可証データインスタンスは、許可証自体についてのデータと、許可証の保持者が何をすることができるかを示す許可とを含む。好ましくは、各許可証は、少なくとも１つの許可を含み、より好ましくは、複数の許可を含む。許可は、許可の保持者が何を行うことを許可されているかを決定するように構成される。好ましくは、許可は、名前－値（鍵－値とも呼ばれる）ペアによって定義される。好ましくは、名前は文字列である。より好ましくは、文字列は人間が読めるものであり、許可が何に関連するかについての指示を提供する。好ましくは、値は、文字列、数字、またはデータ構造であり、データ構造は、１つまたは複数の名前－値ペアである。許可は、好ましくは、以下の「許可」の見出しの下でさらに詳細に説明されるような形態である。本明細書で使用されるような１つまたは複数の許可を含む許可証を指す場合、これは、好ましくは、名前－値許可を含む許可証データインスタンスを指す。許可は、好ましくは、セットまたはグループ（本明細書で説明される例では、permissionSetsと呼ばれる）で提供される。好ましくは、許可（複数可）のグループは、「拡張」として各許可証の一部である。拡張については、以下の「拡張」の見出しの下でさらに説明する。

【0108】

各許可証は、許可証の保持者の身元を検証することができるようなデータも含む。好ましくは、許可証は、許可証の保持者に関連付けられた公開鍵を含む。許可証保持者の身元の検証は、保持者が自身の私有鍵でメッセージ（または任意のデータ）に署名することによって決定することができ、その後、許可証保持者の身元を検証する当事者は、許可証保持者に関連付けられた公開鍵に対して署名とメッセージを比較することができる。好ましくは、許可証保持者に関連付けられた公開鍵は、関連する許可証データインスタンスに記憶される。

【0109】

好ましくは、各許可証は、許可証識別子によって識別される。好ましくは、許可証識別子は、許可証のコンテンツについての指示を提供しない。好ましくは、許可証識別子は、擬似ランダムに生成された文字列である。

【0110】

一実施形態では、本システムは、ユーザの署名を許可証に照らして検証し、したがって、ユーザが許可証の保持者であるか否かを検証する方法を提供する。好ましくは、検証は、「署名の検証」の見出しの下で説明される方法にしたがって実行される。

【0111】

好ましくは、許可証は階層の一部である。図２を参照すると、許可証の階層２００が示されている。すべての許可証（ルート２０２を除く）は、親許可証と、任意選択で１つまたは複数の子許可証とを有する。好ましくは、子許可証は、２つ以上の親を有することはできない。結果として得られる許可証階層構造はツリーである。親許可証は、子許可証を作成することができる（許可証自体に課される様々な制限を受けるが、これらについては、以下で、特に「子許可証の追加」の見出しの下でより詳細に説明する）。好ましくは、親が取り消されると、その子も取り消される。より好ましくは、このプロセスは、親許可証の子孫もすべて取り消されるように再帰的である。これは、親許可証から開始するカスケーディング取り消しとみなすことができる。

【0112】

好ましくは、許可証は、許可証保持者が、所与の「ドメイン」または「名前空間」内であるが、他のドメインまたは名前空間にまたがらない許可を含む子許可証を作成することを可能にするルールのセットを含む。これらの名前空間を使用することで、別個の組織が、許可証システムを使用する他の組織と干渉することを防止する。ルールのセットは、以下に説明する特別な許可に記載されている。

【0113】

さらに、ルールのセットは、子許可証への権限の委譲を可能にして、任意選択の深さと総数の制限を条件として、ドメインまたは名前空間内に孫を作成する権利を子許可証に与える。これらの制限は、子が好ましくは親の権限の同じまたはより制限的な委譲を継承するという点で再帰的である。

【0114】

トップレベルのルート許可証２０２は、ほとんどまたは全く制限なく、多数のまたはさらには無制限の数の子許可証を作成する能力を有する。このような幅広い能力により、ルート許可証の作成に使用される私有／公開鍵ペアは、好ましくは、セキュアに管理される。好ましくは、ルート許可証に関連付けられた私有鍵は、セキュアなデバイス上でオフラインに保たれる。

【0115】

トップレベルのルート許可証２０２（組織レベルのルート許可証２０６、２０８、２１０ではない）の作成は、１回限りのプロセスである。本方法は、子許可証の作成と同様であるが、参照する親許可証がないので、親の許可、認証、認可、および他の特徴のチェックに関するすべてのチェックはスキップされるか、または他の形で無視される点が異なる。本実施形態では、これは好ましくは一度実行され、再び実行されることはない。

【0116】

図２の例示的な許可証階層２００では、許可証を使用している４つの異なる組織が存在する。ｎＣｈａｉｎ（ＴＭ）はルート許可証の保持者であり、ＯｒｇＡＢＣ、ＯｒｇＰＱＲ、およびＯｒｇＸＹＺはすべて、ｎＣｈａｉｎの許可証の子である許可証を使用している。当業者であれば、特定の会社は例として使用されているにすぎないことを理解するであろう。さらに、そのような許可証システムには任意の数の組織が存在してもよい。図２に示される例示的な階層および組織は、本明細書で説明されるいくつかの本実施形態を使用したときの許可証構築の柔軟性を例証する。

【0117】

この例を続けると、ＯｒｇＡＢＣは、組織レベルのルート許可証２０６を有する。これは、ＯｒｇＡＢＣの許可証のルートであるという点でルート許可証であり、ツリー全体のトップレベルのルート２０２ではない。ＯｒｇＡＢＣは、少なくとも２つの子許可証２１２、２１４を作成している。これらの子許可証は、異なる顧客および／またはエンドユーザのためのものである。

【0118】

ＯｒｇＸＹＺはルート許可証２１０を有する。ＯｒｇＸＹＺは、国ごとに許可証がある異なる階層構造を有することを選択している。ＸＹＺＵＫ許可証２１６は、メンバーおよび／またはエンドユーザのための少なくとも２つの許可証２１８、２２０と共に示されている。

【0119】

一実施形態では、ルート許可証の保持者は、同じ保持者を有するいくつかの子許可証２０４を作成する。これらの子許可証は、システムの他のユーザのためにさらなる子許可証２０６、２０８、２１０を作成することができるように構成される。こうすることで、新しいユーザまたは組織が許可証を望むたびに、トップレベルのルート許可証２０２を使用してさらなる許可証を作成する必要がなくなる。したがって、攻撃が発生する機会が減少し、ルート許可証のセキュリティが向上する。

【0120】

好ましくは、すべての許可証は、その親への参照と、１つまたは複数の名前付き許可とを含む。作成時、親は、許可のセットを示すデータと、許可証保持者に関連付けられた公開鍵（holderPubKey）とを供給する。以下の例示的な許可証データインスタンスに見られるように、許可は、デフォルトでextensions[“default”]オブジェクトの下に記憶される。許可証の作成については、「子許可証の追加」の見出しの下でより詳細に説明する。

【0121】

好ましくは、許可証情報は、許可証データインスタンスまたは許可証データと呼ばれるデータ構造で追跡される。データ構造は、以下の表に示される以下の要素のうちの少なくともいくつかを含む。好ましくは、すべての要素が必要である。要素に対する値のいくつかは、ヌル、ゼロ、またはゼロ長に設定することができる。より好ましくは、parentは必須であり、ヌルではない。

【0122】

任意選択で、許可証は、現在の時間から終了日時まで有効である。好ましくは、終了日時は、「revoked」要素の下の許可証データインスタンスにおいて設定される。一旦取り消されると、許可証を再アクティブ化することはできない。許可証（またはその許可のサブセット）を一時的に非アクティブ化するためには、以下の「拡張」の見出しの下で説明されるように拡張の取り消しおよび追加を使用することができる。

【表1】

【0123】

好ましくは、許可証が取り消されたか否かを決定することは、現在の時間に依存する。各許可証は、時間を含む「revoked」要素を含む。許可証が取り消されたとみなされるためには、現在の時間が、許可証に記憶された取り消し時間の後でなければならない。より好ましくは、およびさらなる実施形態によれば、許可証が将来のある時点で提供され、その時点で有効であるか否かを返す方法が提供される。

【0124】

好ましくは、名前付き許可のマップは、拡張マップ内のそれらの名前によって参照される。初期の拡張を記憶するときには「default」という名前が使用される。

【0125】

代替的に、拡張マップは使用されず、許可の１つのセットのみが許可証に関連付けられる。

【0126】

各拡張は、いくつかの要素を含む。拡張の例示的要素を以下の表２に示す。好ましくは、それらのすべてが必要である。

【表2】

【0127】

すべての要素が使用されている（ただし、一部はヌルに設定されている）例示的な許可証データインスタンスをＪＳＯＮフォーマットで以下に示す。

【数1】

【0128】

当業者であれば、上記が例示的な許可証であり、この許可証データインスタンスのいくつかの特徴は、本明細書で説明される特定の実施形態に応じて、削除されたり、使用されなかったり、変更されたりし得ることを理解するであろう。当業者であれば、ＪＳＯＮが、ここでは許可証を表す例として提供されることをさらに理解するであろう。許可証およびそのコンテンツは、ＸＭＬ、バイナリ符号化フォーマット、または任意の他の適切なフォーマットなどの他のフォーマットを使用して表され得る。

【0129】

図３Ａを参照すると、単純な例が示されている（最終的なトップレベルのルート許可証は省略されている）。ここで、組織のルート許可証３０２は、少なくとも２つの子許可証３０４、３０６を有する。組織は、漁業許可証（fishing permit）３０４、３０６（本例では釣り人に限定）を発行するＮＢＷ（National Bureau of Waterways）である。任意選択で、ＮＢＷは、保持者の許可証に対する識別子と、許可証の保持者が許可証を保持していることを立証できるようにする秘密鍵とを保持するモバイルアプリケーションを提供する。各釣り人の許可証３０４、３０６は、「org.nbw.angler.rights」と呼ばれる許可を含み、好ましくは、以下の構造を有する：

【数2】

【0130】

任意選択で、会員番号およびユーザ名など、個人の身元に関連付けられた他の許可が存在する。

【0131】

使用の際、ユーザ（第１の子許可証３０４を保持しているFred Bassなど）が正しいタイプの用具で釣りをしており、正しいタイプの魚を釣っていることを確かめることを望む釣り検査官は、この許可証を使用して確かめることができる。検査官は、許可証識別子（好ましくは、ＱＲコード（登録商標）を介してFred Bassの電話から取得される）を使用することができる。この許可証識別子を用いて、検査官は、許可証インスタンス自体に問い合わせて、許可（Fred Bassがロッドを使用しており、コイ、テンチ、またはキタカワカマスだけを釣っていること）と身元（Fredが実際に許可証の保持者であり、他の誰かの許可証識別子をコピーしていないこと）の両方を確認することができる。

【0132】

許可
好ましくは、許可は名前空間化される（namespaced）。より好ましくは、許可は、名前－値ペアの名前を何にすることができるかを制限することによって、名前空間化される。好ましくは、名前空間は、「．」（ピリオド）によって分離される逆ＤＮＳドメイン状構造を使用する。名前空間のいくつかの例を以下に示す：

【数3】

【0133】

このように、これらの名前空間は、左から右に構築されており、左端のプレフィックスは、最も具体性の低い特徴であり、右端のサフィックスは、最も具体性の高い特徴である。

【0134】

好ましくは、これらの許可の名前－値ペアの名前と値の両方がカスタマイズ可能である（名前が親許可証の許容可能な名前空間内にある限り）。好ましくは、名前と値は両方とも任意の値とすることができる。好ましくは、名前と値は両方とも許可証システムのユーザによって供給される。したがって、名前および値はユーザによって生成される。ユーザによって生成されたおよび／またはカスタマイズ可能な名前および値を提供することで、許可証のユースケースは非常に柔軟になり、それによって、非常に多くの異なるアプリケーションでの使用が可能になる。

【0135】

好ましくは、名前空間は、長くなることのみ可能である。これは、子許可証の許可が、親許可（複数可）にしたがって許可されるもののサブセットにしかなり得ないということとも理解することができる。好ましくは、名前空間は、許可が階層に構造化されることを可能にする（これは、付加的なものであり、多くの場合一致するが、許可証も階層的であることとは別である）。

【0136】

好ましくは、許可階層は、許可証と同じ構造に従う。これは、各子許可証が、親の（名前空間に関する）サブセットである許可を含むことも理解することができる。

【0137】

「$」名前空間がプレフィックスされた特別な許可のセットは、許可証自体についての情報および／または制限を提供する。「$」名前空間は、これらの許可証がどの許可を子許可証に追加することができるかについての制限を提供する。これらの制限は以下を含むことができる：
・子内のすべての許可に対する１つまたは複数の名前空間プレフィックスの実施、
・所与の深さまで再帰的に、子へのさらなる許可証を作成する権利の委譲、
・作成することができる子およびさらなる子孫の数の制限、および／または
・作成することができる拡張の数の制限（以下で「拡張」の見出しの下で説明）。

【0138】

代替的に、これらの特別な許可に記憶された情報（すなわち、許可証の制限および他の情報）は、特別な許可に記憶されるのではなく、許可証データインスタンスに記憶される。好ましくは、制限の各々が、許可証データインスタンスにそれ自体の要素として記憶される。当業者であれば、これらの制限を、許可証に関連付けられた任意の数の異なる場所に記憶することができることを理解するであろう。

【0139】

任意選択で、「$」名前空間は、許可証の有効性範囲を定義するためにも使用される。

【表3】

【0140】

特別な（$）名前空間は、上記記載のような「$.children.namespace」ルールに準拠する必要はない。好ましくは、特別な許可の特定のセットのみを作成することが可能である。より好ましくは、上記のセットは、許可証が有することができる唯一の特別な許可である。

【0141】

好ましくは、$.valid.afterおよび$.valid.before許可は現地時間を使用する。好ましくは、許可は任意選択であり、必須ではない。好ましくは、$.valid.afterおよび$.valid.beforeは、許可証および／または拡張の有効性を定義する。好ましくは、親が$.valid.afterおよび$.valid.after許可セットのいずれかを有する場合、それから作成される子はいずれも、同じまたはより狭い時間ウィンドウを伝えなければならない。したがって、子許可証の有効性範囲は、その親許可証の有効性範囲を超えることができないことが分かる。

【0142】

これらの特別な許可は全体として許可証を参照するので、これらの特別な許可は、好ましくは、初期／デフォルト拡張にのみ記憶される。異なる拡張に記憶された任意の特別な許可は、無視されるか、または拒絶される。

【0143】

図３Ａの前の例を参照すると、ＮＢＷルート許可証３０２は、少なくとも以下の許可を含む：

【数4】

【0144】

これらの許可は、ＮＢＷルート許可証３０２の保持者が、子の許可が「org.nbw」で始まり、子が１レベルの深さのみである限り、必要なだけ多くの子許可証を作成することができることを示す。

【0145】

図３Ｂを参照すると、さらなる例示的な許可証構造３２０がここに示されている。この構造は、図３Ａを参照して説明したものと同様である。ＮＢＷルート許可証３０２は、２に等しい（またはそれ以上の）「$.children.levels」許可を有する。本例では、ＮＢＷ許可証３０２の保持者は、クラブがそれ自体のメンバーに許可証を作成することができるようにすることを望む。ＮＢＷ許可証３０２は、以下の許可を含むクラブ許可証BLFC３２２（Big Lake Fishing Club)）を作成する：

【数5】

【0146】

これらの許可は、ＢＬＦＣがそのメンバーに対して最大５０個の許可証を作成することを可能にするが、許可は名前空間「org.nbw.angler」内にあるものだけである。そのため、「org.nbw.club.id」のような許可は、いずれの子に対しても許可されず、したがって、子は、クラブ許可証の許可（例えば、子許可証が許可「org.nbw.club.id」を含む場合、子は、クラブ自体を装い、クラブに関連付けられたあらゆるアクションを行うことができる）または任意の他の同様の許可になりすますことはできない。

【0147】

ＢＬＦＣ許可証３２２は、少なくとも２つの子許可証３２４、３２６を作成する。これらの子許可証は、「org.nbw.angler」がプレフィックスされた許可を有していなければならない。

【0148】

拡張
好ましくは、許可は「extensions」に記憶される。好ましくは、拡張は、許可のセット（permissionSetsと呼ばれる）と、revoke要素と、holderPubKey要素とを含む。拡張は、拡張マップ内の許可証データインスタンスに記憶され、名前によって参照される。好ましくは、名前はユーザによって生成される。好ましくは、名前は人間が読めるものである。任意選択で、初期拡張および／またはデフォルト拡張は「default」とラベル付けされる。ここで、人間が読めるとは、人間が自然に読めるような任意の符号化である。好ましくは、符号化はＡＳＣＩＩまたはＵｎｉｃｏｄｅテキストである。

【0149】

拡張は、好ましくは、少なくとも１つの許可のグループを参照する方法を提供する。より好ましくは、許可は、少なくとも１つの許可のグループまたはセットを参照するための、人間が読める方法を提供する。表２で上述したように、各拡張は、許可のセットを含むいくつかの要素を含む。

【0150】

拡張はまた、拡張が属する許可証の許可のサブセットを含むもの、サブセットを定義するもの、またはサブセットであるものとして説明され得る。

【0151】

当業者であれば、拡張の構造およびフォーマット、ならびにそれらがどのように記憶されるかを厳密に厳守する必要はないことを理解するであろう。許可の拡張および／または集合には代替の構造が可能であり得る。代替例としては、拡張は拡張マップに厳密に記憶されなくてもよく、リストまたは他の適切なデータ構造に記憶されてもよいことであり得る。代替的に、本明細書で説明されるextensionオブジェクトは、許可のリストまたは許可参照のリストのみを含み、許可自体は許可証上の他の場所に記憶されるという点で、異なる構造を有していてもよい。

【0152】

許可証の存続期間中、拡張を使用して、許可のセットを追加および置換することができる。拡張は、親許可証によって追加されたり取り消されたりしてもよい。好ましくは、許可証に追加されるすべての許可は、親許可証の保持者によって署名される。

【0153】

許可証への拡張の追加は、「拡張の追加」の見出しの下でより詳細に説明される。拡張の取り消しは、「拡張の取り消し」の見出しの下でより詳細に説明する。

【0154】

一実施形態では、拡張は、許可証保持者が異なるデバイスを許可証に関連付けることを可能にする。例えば、許可証が、特定のリソース（任意選択で、コンピューティングリソース）へのアクセスのためのものである場合、単一許可証保持者は、自身のiPhone（登録商標）の対話を管理するための「iPhone」拡張と、自身のデスクトップコンピュータにとコンピューティングリソースとの対話を管理するための「desktop」拡張を有し得る。上述したように、拡張は取り消すことが可能である。有利なことに、ユーザが自分のiPhoneを紛失した場合、ユーザは、（このユーザの許可証を作成した親許可証を制御する）自身の許可証プロバイダに連絡を取り、ユーザの他のデバイスとサービスとの対話に影響を及ぼすことなくiPhone拡張を取り消すことができる。したがって、拡張システムは、リソースへのアクセスを提供／除去することに関して、改善された柔軟性および制御を提供することが分かる。これを、許可証の集中管理および／または証明書失効リスト（ＣＲＬ、「許可証の取り消し」の見出しの下でさらに説明する）の欠如と組み合わせると、関連性のある拡張内の許可を確認することに関して、そのようなリストの配布および維持が不要になるので、コンピューティングリソースを節約することができる。

【0155】

許可証との対話
上述したように、本明細書で説明される許可証システムは、好ましくは、要求を使用して対話される。好ましくは、要求はＨＴＴＰ要求である。より好ましくは、要求はＲＥＳＴエンドポイントに送信される。関連性のあるＲＥＳＴエンドポイントは２つある：
・子の作成および取り消しを含む許可証に対する動作を要求するための…/send、および
・許可証の有効性および許可をチェックするための…/query。

【0156】

好ましくは、いくつかの対話は、要求が署名を含むことを必要とし、したがって、作成、取り消し、または他の対話のために許可証と対話することを望む組織は、私有／公開鍵ペアをセットアップさせる必要がある。任意の要求はまた、関心のある許可証のインスタンスｉｄを含む必要がある。インスタンスｉｄおよび公開鍵は、公的に閲覧可能または知り得るものとすることができるが、私有鍵は秘密に保たなければならない。

【0157】

これらのエンドポイントに要求を送信することは、RESTful APIとして提示されるので、エンドポイントを「呼び出し（calling）」としても説明され得る。したがって、要求の送信者は、「呼び出し元（caller）」とみなすこともできる。

【0158】

好ましくは、「…/send」エンドポイントに送信されるあらゆる要求がログ記録される。好ましくは、ログ記録は、サードパーティが要求を監査することができるように、ブロックチェーン上で行われる。好ましくは、「…/query」エンドポイントに送信される要求はログ記録されない。

【0159】

任意選択で、通常「…/query」に送信される要求は、ログ記録のために「…/send」エンドポイントに送信されることができる。このオプションは、許可証（または許可証の許可）のチェックが重要であり、その後検証される必要がある場合に有用である。例えば、すべての許可証保持者が、ある場所に入る前に許可証をチェックする必要がある場合、チェックが実際に行われたことを保証するために、許可証がチェックされるたびにログ記録する必要がある可能性が高い。

【0160】

一実施形態では、「子許可証の作成」、「許可証の取り消し」、「拡張の取り消し」、および「拡張の追加」の見出しの下で説明される対話は、ブロックチェーン上にログ記録されるか、または少なくとも対話のサブセットがブロックチェーン上にログ記録される。好ましくは、これらの対話はすべてオフチェーンでログ記録され、対話のサブセットがブロックチェーン上にログ記録される。好ましくは、対話は対話の集合に記録され、対話の各集合は単一の許可証に関連する。対話の各集合はまた、ブロックチェーン上に（トランザクションを用いて）関連する表現を有する。したがって、関心のある許可証との対話を追跡することを望む監査人は、関心のある集合だけを監査することができる。

【0161】

好ましくは、ブロックチェーン上にログ記録された対話の各々は、（任意選択で、ブロックチェーン上にも記憶された）前の対話の不変の参照を含む。好ましくは、この参照は前の対話のハッシュである。好ましくは、すべての対話が前の対話への参照を含み、したがって、すべての対話の不変のチェーンを確立する。したがって、不変のログは、対話のサブセットのみがブロックチェーン上に記録されることを必要とする。任意選択で、最初と最後の対話のみがブロックチェーンに記録される。

【0162】

好ましくは、ログ記録は、各許可証のEvent Streamを使用して行われる。任意選択で、ログ記録の実施形態を提供するためにＡＰＩを介して対話されるログ記録サービスが存在する。Event Streamは、以下を参照して説明される：
・ nChain Holdings Limitedによって２０２１年２月１５日に出願されたＰＣＴ／ＩＢ２０２１／０５１２５８、
・ nChain Holdings Limitedによって２０２１年２月１５日に出願されたＰＣＴ／ＩＢ２０２１／０５１２６０、および
・ nChain Holdings Limitedによって２０２１年２月１７日に出願されたＰＣＴ／ＩＢ２０２１／０５１３３３。

【0163】

好ましくは、「子許可証の作成」、「許可証の取り消し」、「拡張の取り消し」、および「拡張の追加」の見出しの下で説明される対話はすべて、…/send ＡＰＩエンドポイントを使用して提供される。

【0164】

好ましくは、許可証との任意の対話を示すデータは、Event Stream APIを用いてEvent Streamに送信される。好ましくは、Event Stream APIは、RESTful APIである。許可証の現在の状態は、許可証とのすべての対話（その作成を含む）を取り、すべての対話ステップを再び実行／再生して「ダミー許可証（dummy permit）」を再作成することによって検証することができる（これは、新しい許可証が実際には作成されないという点で「ドライラン（dry run）」と説明することもできる）。「ダミー許可証」の最終状態は、実際の許可証と同じ現在の状態を有するべきである。中間状態が知られている場合、許可証の任意の中間状態を検証することについても同じことが言える。

【0165】

したがって、許可証との対話をログ記録することによって、許可証の状態がログ記録され、したがって、現在の状態または任意の前の状態が監査可能および検証可能となることが分かる。Event Streamを介してこれらの状態変更をブロックチェーンにサブミットすることによって、許可証は、永続的に監査可能および検証可能になり、データ完全性の高い信頼性が得られる。

【0166】

エンドポイントへのいくつかの例示的な要求は、ヘッダ内に以下の特徴を含み得る：

【数6】

【0167】

ここで、{AWS ID}はＡＷＳ（ＴＭ）エンドポイントのｉｄであり、{instance ID}は許可証識別子である。当業者であれば、他のＵＲＬおよびサービスが使用されてもよいことを理解するであろう。例えば、非ＡＷＳＵＲＬが使用されてもよい。当業者であれば、本明細書で提供される要求が例示的であり、異なる形態をとってもよいことを理解するであろう。要求は、要求が送信されている先のＵＲＬを含むものとして示されている。任意選択で、完全なＵＲＬはそのように提供されず、単にパスが提供される。

【0168】

任意選択で、要求ヘッダは、ＡＷＳＡＰＩキーも含む。

【0169】

好ましくは、ＰＯＳＴのボディは、送信されるメッセージまたは対話のために命名された単一のプロパティを含むＪＳＯＮオブジェクトであるべきである。好ましくは、要求に対する認証および認可は、送信者の私有鍵でパラメータに署名し、その結果を要求の署名プロパティに入れることによって行われる。例えば、以下である：

【数7】

【0170】

署名されている要求の部分は、ＪＳＯＮオブジェクト自体ではなく、要求のコンテンツの文字列表現として送信される必要があることに留意されたい。これは、要求の送信者と要求の受信者の両方が、署名を計算するためにオブジェクトの同じ表現（間隔、順序などは無関係である）を使用することを保証するためである。文字列化する代わりに、オブジェクトの正準構造を使用することもできる。この正準構造は、任意選択で、ＲＦＣ８７８５にしたがって定義される。正規化スキームは、送信者と受信者の両方によって合意されたものである。スキームは、事前に合意されてもよく、または、スキームは、どのスキームが使用されているかを受信者が理解するように、送信者によって識別される。

【0171】

好ましくは、正規化が使用される場合、要求のＪＳＯＮオブジェクトは、文字列化されず、任意の有効なＪＳＯＮ形態で送信され得る。

【0172】

好ましくは、上述の要求に対する応答には、結果プロパティおよび任意選択のメッセージが提供される。例えば、以下である：

【数8】

【0173】

メッセージ（msg）の正確なコンテンツは、要求のコンテキストおよびそれがどのように処理されるかに依存する。

【0174】

以下に、異なる対話許可証を説明するいくつかの異なる実施形態が提示される。好ましくは、任意の数のこれらの実施形態は、任意の数の異なる他の実施形態と共に使用され得る。当業者であれば、いくつかの実施形態がすべての考えられるシステムにおいて使用されなくてもよいことを理解するであろう。例えば、拡張が使用されないことがあり、したがって、拡張の作成または取り消しに関する対話は使用されなくてもよい。

【0175】

子許可証の作成
図４Ａおよび図４Ｂを参照すると、子許可証を作成する例示的な方法４００、４２０が示されている。好ましくは、第１の方法４００は、すでに保持している許可証の新しい子許可証を作成することを望むユーザ（組織など）によって、またはそのユーザの代わりに実行される。第２の方法４２０は、好ましくは、図１のコンピューティングモジュール１０４のような許可証コンピューティングモジュールによって実行される。当業者であれば、各方法のステップのいくつかが、異なる当事者によって実行されてもよく、どのメンバーがどのステップを実行するかを厳密に厳守する必要はないことを理解するであろう。

【0176】

好ましくは、作成されるべき新しい許可証の保持者の公開鍵は既知であるか、または取得される（４０２）。任意選択で、新しい公開鍵を取得することは、新しい私有／公開鍵ペアを生成することを含む。好ましくは、私有／公開鍵ペアの生成は、親許可証の保持者（および／または新しい許可証を作成するための要求の送信者）が新しい許可証の保持者の私有鍵の知識を得ないように、新しい許可証の保持者によって行われる。したがって、新しい許可証の所持者から新しい公開鍵が受信される。

【0177】

新しい許可証を作成するための要求が構築され（４０４）、要求は、新しい許可証を記述するいくつかの特徴を含む。好ましくは、新しい許可証を記述する特徴は、少なくとも、新しい許可証が有することとなる許可を示すデータと、新しい許可証保持者の保持者の公開鍵とを含む。任意選択で、新しい許可証を記述する特徴は、新しい許可証の有効性範囲をさらに含む。

【0178】

好ましくは、新しい許可証を記述する特徴は、親許可証の私有鍵を使用して署名される。より好ましくは、特徴は、文字列に変換され（「文字列化（stringified）」としても知られる）、および／または正準データ構造に変換され、結果として得られた文字列またはデータ構造が署名される。要求は署名を含む。

【0179】

任意選択で、新しい許可証を記述する特徴は、「permitContents」と呼ばれる。一例として、要求は以下の形態を有する：

【数9】

【0180】

事前に文字列化されたpermitContentsは、任意選択で、ＪＳＯＮ構造であり、以下のフォーマットを有する：

【数10】

【0181】

上述のように、文字列化されたpermitContents（または、本明細書で使用される任意の他の文字列化されたＪＳＯＮ）の代替として、ＪＳＯＮの正規化を使用することができ、要求のＪＳＯＮ構造は、通常の文字列化されていない形態であり得る。

【0182】

ＪＳＯＮの代替として、permitContentsおよび／または要求はＸＭＬフォーマットであってもよい。図３Ａおよび図３Ｂの釣りの例に戻ると、ＮＢＷがＦｒｅｄＢａｓｓに対する釣り許可証３０４を作成することを望む特定の例では、Ｆｒｅｄの許可証３０４を作成するためのpermissionContentsは、以下のようになる：

【数11】

【0183】

要求は、ユーザによって作成されて送信され（４０８）、親許可証によって受信される（４２２）。許可証との対話を参照して上述したように、要求は（好ましくはヘッダ内に）アドレスを含む。好ましくは、そのアドレスは、親許可証の許可証識別子を含む。したがって、要求は、親許可証に関連付けられたコンピューティングモジュールに送信され、そこで受信される。

【0184】

図４Ｂの方法４２０を参照すると、新しい許可証および親許可証の確認に関するステップが示されている。好ましくは、少なくともこれらのステップは、親許可証に関連付けられたコンピューティングモジュールによって行われる。

【0185】

要求の受信（４２２）の後、許可証インスタンスデータ（許可証データともいう）が取得される（４２４）。好ましくは、コンピューティングモジュールはすでにこの情報をメモリに記憶している。代替的に、コンピューティングモジュールは、他の許可証インスタンスデータを含むリポジトリおよび／またはデータベースから許可証インスタンスデータを取得する。

【0186】

本方法を参照して、ならびに確認および／または検証ステップを伴う他の実施形態を参照して以下で説明するように、要求および／または許可証のいくつかの特徴が正しいことを保証するためにいくつかの有効性チェックが行われる。本説明は、受信した要求および確認されているすべてのデータが正しいハッピーパスを詳述する。しかしながら、何かが無効または不正確であると分かった場合、コンピューティングモジュールは、この方法の最後のステップ４３２（または取り消し方法５００の最後のステップ５１８）にスキップし、応答を作成して送信者に送信する。この応答は、要求が失敗したことを示すためのものであり、任意選択で、要求の失敗理由を含む。

【0187】

許可証インスタンスデータにより、親許可証が子許可証を作成することができるかどうかに関する何らかの確認が親許可証自体に対して行われる（４２６）。好ましくは、親許可証の確認は、親許可証が取り消されたかどうかをチェックすることを含む（取り消された許可証は子を作成することができず、それの子はすべて取り消されたとみなされるので）。

【0188】

好ましくは、親許可証の確認は、子を作成することができるかどうかに関してそれ自体の許可をチェックすることを含む。好ましくは、これは、親許可証が、それ自体の下に作成することができる階層レベルの数が１以上であることを保証することを含む。上述した許可証データインスタンスの実施形態を参照すると、これは、「$.children.levels」許可が１以上であることをチェックすることを意味する。レベル値が設定されていない場合、これはゼロに等しいことと同じであり、親許可証は子を作成することができない。

【0189】

好ましくは、子を作成することができるかどうかに関してそれ自体の許可をチェックすることは、子の最大数を超えていないことをチェックすることを含む。上述した許可証データインスタンスの実施形態を参照すると、これは、「$.children.max」が、設定されていない（制限がないことを意味する）か、または許可証がすでに有している子の数よりも大きい数に設定されているか、またはアレイ（そのアレイ内の最初の数は、許可証がすでに有している子の数よりも大きい）に設定されていることを保証することを意味する。

【0190】

次に、要求およびそのコンテンツが確認される（４２８）。好ましくは、要求の署名を確認することで、許可証コンピューティングモジュールは、要求が許可証の保持者によって（または少なくとも親許可証の公開鍵に関連付けられた私有鍵を保持する者によって）署名されていることを確かめる。好ましくは、この署名の確認は、許可証のデータインスタンスに記憶された公開鍵を使用して行われる。

【0191】

任意選択で、新しい許可証について要求に有効性範囲が記憶されている場合、新しい許可証の有効性範囲が親許可証の有効性範囲を超えないことを保証するための確認ステップが行われる。

【0192】

好ましくは、新しい許可証の許可は、親が提供することを許可されている許可の範囲内にあるように確認される。上述した許可証データインスタンスの実施形態を参照すると、これは、新しい許可証に追加されている許可が、親の「$.children.namespace」に概説されるような名前空間内にあることを保証することを意味する。例えば、検証は、「org.nbw.angler.rights」の許可を有する新しい許可証を作成する場合、親許可証が「org.nbw.angler」を有する名前空間（または「org.nbw」もしくは「org」などのより広い名前空間）を含むことを保証することを含む。

【0193】

上記に加えて、子が作成することを許可されている許可証の名前空間も、親許可証と同じであるか、または同じ範囲内にあることが検証される。例えば、親の名前空間が[“org.nbw,angler”, “org.nbw.club”]である場合、子許可証は、親の名前空間よりも広いので名前空間[“org.nbw”]を有することはできない。

【0194】

好ましくは、以下のさらなる確認のうちのいずれか１つまたは複数が行われる：
（Ａ）親および／または子が有し得る総レベル、
（Ｂ）親または子が有し得る子の最大数、および
（Ｃ）子の有効性が、親と比較して同じかまたはより狭い範囲を有すること。

【0195】

これらの確認はすべて、子許可証が親許可証よりも広いまたは数が多い特徴を含まないことを保証するためのものであることに留意されたい。

【0196】

【0197】

次に、新しい許可証が作成される（４３０）。好ましくは、図１を参照して説明した実施形態と組み合わせて使用される場合、このステップは、コンピューティングモジュールマネージャ１１４にさらなる要求を送信することを含む。コンピューティングモジュールマネージャ１１４は、新しい許可証および新しい許可証識別子のための新しいコンピューティングモジュールを作成する。

【0198】

新しい許可証データインスタンスが、新しい許可証のためにまたは新しい許可証によって作成され、許可証の関連性のある新しいコンテンツがそれに追加される。例示的なコンテンツは、第１の方法４００の第２のステップ４０４において作成され、その後、第２の方法４２０において親許可証モジュールによって検証された新しい許可を含む。

【0199】

任意選択で、新しい許可証は、それを作成したプロセス（この場合、親許可証）が同じセキュア処理環境１０８の一部であることをチェックする。

【0200】

好ましくは、新しい許可証は、親許可証をその親として設定する。より好ましくは、これは、親許可証のインスタンスｉｄを新しい許可証のデータインスタンスの「parent」要素として記憶することによって行われる。

【0201】

新しい許可証プロセスが作成されると、新しい許可証は、それ自体の許可証識別子を親許可証に返す。親許可証は、子の許可証識別子を、自身の子のリストに追加する。好ましくは、これは、新しい許可証のインスタンスｉｄを親のデータインスタンスの「children」アレイ要素に追加することを意味する。

【0202】

最後に、要求の送信者への応答が生成され、送信者に送信される。この応答は、新しい許可証の作成に成功した（または作成に成功しなかった場合には、成功しなかった）という指示と、新しい許可証の識別子とを含む。好ましくは、新しい許可証の識別子は、必要なときに参照することができるように、新しい許可証の所有者にも提供される。

【0203】

当業者であれば、これらのステップのうちのいくつかが、使用状況、特に、セキュリティ状況に応じて任意選択であるとみなされ得ることを理解するであろう。例えば、親許可証は、有効な要求のみを生成するように構成されていることが分かっている送信者から要求が受信された場合、確認ステップ（署名を確認すること、または名前空間が正しいかどうかを確認することなど）の多くを行う必要がない場合がある。

【0204】

さらに、ここではステップが特定の順序で提示されているが、これは説明を容易にするためのものにすぎない。当業者であれば、これらのステップのいくつかは任意の順序でおよび／または同時に行うことができることを理解するであろう。

【0205】

許可証の取り消し
図５を参照すると、子許可証を取り消す一実施形態による方法５００が示されている。好ましくは、本方法は、親許可証によって行われ、ここでは、親許可証の所有者が、親許可証の子である許可証を取り消すことを望んでいる。

【0206】

好ましくは、許可証は、親許可証の所有者によってのみ取り消すことが可能である。任意選択で、許可証はさらに、任意の祖先によって取り消され得る。

【0207】

好ましくは、許可証が取り消されと、その子孫もすべて取り消される。

【0208】

有利なことに、システムのオペレータ、許可証の保持者、および／または任意の親許可証の保持者によって積極的に維持される各許可証に「revoked」フィールドを設けることによって、証明書失効リスト（ＣＲＬ）の必要がなくなる。ＣＲＬは、発行者によって取り消されたすべてのデジタル証明書のリストである。これにより、許可証が使用されるたびに、ユーザ／バリデータが、リストを取得し、それが最新であることを検証し、最後に、取り消された許可証の膨大な可能性のあるリストをトラバースする必要がなくなるので、許可証を、より時間効率およびリソース効率良く使用することができる。

【0209】

好ましくは、許可証の取り消しは元に戻すことができない。許可証の許可のサブセットの一時的な取り消しは、上記の「拡張」の見出しの下で説明した拡張の取り消しおよび追加を用いて行うことができる。

【0210】

許可証の取り消しは、任意選択で、子許可証の許可のサブセットを取り消すこととみなすことができ、ここでは、サブセットはすべての許可である。言い換えると、許可証を取り消すことで、許可証の許可もすべて取り消されるので、許可証は、何かを行う許可がない状態になる。許可のより小さなサブセットを取り消すことは、好ましくは、以下の「拡張の取り消し」の見出しの下で説明するように、拡張を取り消すことによって行われる。

【0211】

許可証は、好ましくは、その子許可証に関連付けられたコンピューティングモジュールにのみメッセージを直接送信することができる。子孫をすべて取り消すためには、許可証がそのすべての子に取り消しメッセージを送信し、各子が同様に行わなければならない。したがって、取り消しプロセスは再帰的なものである。

【0212】

好ましくは、子許可証は、取り消しメッセージがその親によって送信されたことを検証する。図１を参照して説明した実施形態と共に使用される場合、親を取り消したのが親コンピューティングモジュールであることを検証することは、呼び出し元の「instanceId」が子許可証のデータインスタンスに記憶された親のinstanceIdと一致することをチェックすることを含む。有利なことに、各許可証コンピューティングモジュールはセキュア処理環境１０８の一部であるので、このチェックは、呼び出し元が取り消しを行うのに適切な許可を有すると決定するのに十分である。任意選択で、呼がセキュア処理環境の外部からのものである場合、および／または図１に記載されたものの代替となるシステムが使用される場合、さらなるセキュリティが必要となる。取り消しメッセージは、メッセージの一部に署名することで生成された暗号署名も含む。次いで、取り消されるべき許可証は、メッセージの送信者が親許可証（および／または、任意選択で、親許可証の保持者）であることを、親の公開鍵に照らしてチェックすることによって、および／または暗号署名が所与のinstanceIdの公開鍵と一致することの検証を提供するさらなるサービスを使用することによって、暗号的に検証することができる。任意選択で、これは、「署名の検証」の見出しの下で説明される方法を用いて行われる。

【0213】

この方法５００が実行される前に、送信者（親許可証の所有者）は、取り消されるべき許可証についての許可証インジケータを含む要求を作成する。任意選択で、要求は、子許可証がいつ取り消されたとみなされることになるかに関する指示を含む。任意選択で、要求は、取り消されるべき特定の拡張に関する指示を含む。拡張の取り消しについては、「拡張の取り消し」の見出しの下でより詳細に説明する。

【0214】

好ましくは、拡張が提供される場合、子許可証の子孫は取り消されない。

【0215】

好ましくは、要求は、以下のフォーマットに従ったボディを有する：

【数12】

【0216】

好ましくは、ＪＳＯＮオブジェクトを作成し、それを文字列化し（または署名および検証ステップ中に正規化を使用して）、その後、データに署名する子許可証作成要求と同様のプロセスがここで使用される。

【0217】

好ましくは、revokeContents要素は、許可証識別子を含み、任意選択で、取り消し時間と、取り消されるべき拡張とを含む。revokeContentsの例示的なフォーマットは、以下の通りである：

【数13】

【0218】

呼び出し元は、取り消しを望んでいる許可証の親に要求を送信する。

【0219】

要求を受信すると、親許可証は、それ自体が取り消されていないことを検証する（５０４）。この親が取り消されている場合、そのすべての子がすでに取り消されており、この方法のこれ以上のステップを行わないことで処理時間を節約することができる。

【0220】

好ましくは、取り消された子許可証の送信者が親許可証の保持者であることのチェックがある（５０６）。好ましくは、これは、要求が許可証の保持者によって（または少なくとも、親許可証の公開鍵に関連付けられた私有鍵を保持し、したがって、許可証保持者の許可を有すると推定される者によって）署名されたことを確認することによって行われる。好ましくは、この署名確認は、許可証のデータインスタンスに記憶された公開鍵を使用して行われる。

【0221】

好ましくは、提供された子許可証識別子が実際に親許可証の子であることのチェックがある（５０８）。上述したように、親のみがその子を取り消すことができる。

【0222】

これらのチェックが完了すると、親許可証は、子許可証に対してさらなる取り消し要求を生成して送信する。さらなる取り消し要求は、任意選択で、子許可証を取り消す時間を含み、任意選択で、取り消されるべき拡張を含む。

【0223】

好ましくは、子許可証は、さらなる取り消し要求の送信者が親許可証からのものであることをチェックする。これは、要求が受信されたアドレスが、セキュア処理環境内のコンピューティングモジュールのみが使用することができる内部専用アドレスであることを確かめること、またはさらなる取り消し要求に関連付けられるかもしくは添付された暗号署名が親許可証によって正しく署名されたことを検証することを含む、いくつかの方法で行うことができる。当業者であれば、他の機能呼び出し元識別方法が可能であることを理解するであろう。

【0224】

好ましくは、子許可証は、取り消されたか否かチェックされる。好ましくは、このチェックは子許可証自体によって行われるが、親許可証がこのチェックを行ってもよい。子許可証がすでに取り消されている場合、これ以上のアクションは必要とされない。

【0225】

好ましくは、子が取り消される（５１４）。より好ましくは、子許可証は、子が取り消されることを示すデータを子許可証のデータインスタンスに追加することによって取り消される。より好ましくは、データは、許可証が有効であるとみなされなくなる時間値である。

【0226】

取り消し要求において時間が提供されない場合、現在の時間が決定され、現在の時間が、子許可証のデータインスタンスの「revoked」要素に対して記憶される。

【0227】

これらの時間値が設定されると、許可証は取り消されたとみなされるか、またはrevokedフィールドに設定された時間が過去となったときに取り消されたとみなされることになる。

【0228】

子許可証が取り消されると、次いで、子許可証は、その子（これらは元の親許可証の孫である）の各々に対して同様のさらなる取り消し要求を構築する。これらのさらなる取り消し要求は、各孫許可証に、それらの「revoked」要素に同じ時間を設定するという同じステップを踏ませるとともに、それらの子の取り消しをトリガする（以下同様）。したがって、異なるレベルの子に対して再帰的に同じ方法を用いることで、元の子許可証から始まる許可証の分岐全体が取り消されることとなる。これは、許可証が取り消された場合に、その子もすべて取り消されることを保証する。

【0229】

子許可証は、それが取り消されたことを親許可証に応答する。任意選択で、各許可証は、その子がすべて取り消されるまで待ち、親許可証は、子の子孫もすべて取り消されたことを示すメッセージを受信する。

【0230】

次いで、親許可証は、応答５１８を生成し、最初の取り消し要求の送信者に提供する。

【0231】

【0232】

さらに、ここではステップが特定の順序で提示されているが、これは説明を容易にするためのものにすぎない。当業者であれば、これらのステップのいくつかは任意の順序でまたは同時に行うことができることを理解するであろう。

【0233】

拡張の取り消し
上述したように、拡張を取り消す方法は、許可証を取り消す方法５００と同様である。そのため、２つの方法の違いのみを説明する。

【0234】

許可証自体ではなく拡張を取り消すためには、親許可証所有者からの要求に拡張の名前が含まれていなければならない。例示的な要求は、以下のオブジェクトの文字列化されたバージョンを含み得る（ここで、iPhoneは、取り消されるべき拡張の名前である）：

【数14】

【0235】

許可証取り消し方法５００における他の変更は、許可証を取り消すステップ（５１４）の代わりに、拡張のみが取り消されることである。これは、拡張データ構造を見つけ、拡張が取り消されたことを示すためのデータを「revoked」フィールドに追加することによって行われる。好ましくは、revokedフィールドに時間データが追加される。許可証取り消しと同様に、時間値は、取り消し要求において受信された値（存在する場合）、または現在の時間（時間値が存在しない場合）である。好ましくは、有効性範囲が定義される場合、有効性範囲の終わりが同じ時間値に設定される。

【0236】

子を取り消す（５１４）代わりに、拡張のみが取り消される（５２０）。

【0237】

上述したように、拡張のみを取り消す場合、それ以上の許可証または子許可証は取り消されず、したがって、子許可証に対して追加の取り消しメッセージを生成して送信すること（５１６）は行われない。

【0238】

拡張の追加
一実施形態では、許可証に拡張を追加する方法が提供される（好ましくは、「拡張」の見出しの下で説明されるように）。好ましくは、許可証の親および／または親許可証の保持者によってのみ拡張を追加することができる。許可証は、親許可証からの確認、親許可証から有効に送信されること、および／または親許可証の保持者から有効に送信されることなしに、それ自体に拡張を追加することはできない。

【0239】

好ましくは、拡張されるべき許可証の許可証保持者（この例示的な実施形態では、任意選択で子許可証と呼ばれる）は、新しい拡張のためのさらなる公開／私有鍵ペアを作成する。代替的に、デフォルト／初期拡張と同じ公開鍵が使用される。

【0240】

好ましくは、拡張を追加する際、新しい子許可証を作成するのと同様の方法が使用される。特に、親許可証の保持者は、文字列化して署名される、同様のpermitContents構造を作成する。結果として得られる要求のボディは次のようになり得る：

【数15】

【0241】

「createChild」の代わりに「extend」名が使用されることを除いて、構造は同じであることに留意されたい。事前に文字列化されたextendオブジェクトは、任意選択で、ＪＳＯＮ構造を有し、以下のフォーマットを有する：

【数16】

【0242】

したがって、要求は、好ましくは、子許可証識別子、拡張名、新しい拡張のための公開鍵、および拡張の許可を含む。要求を受信すると、親許可証は、親が依然として有効である（取り消されておらず、有効性範囲内にある）ことを検証すること、署名が親許可証の保持者によって正しく署名されていることを検証すること、許可の名前空間が親許可証の名前空間を超えないこと、および有効性範囲が親許可証の有効性範囲内にあることを検証することを含む、許可証を作成するのと同じまたは同様の確認ステップを行う。

【0243】

【0244】

これらの確認はすべて、新しい拡張が親許可証よりも広いまたは多い特徴を含まないことを保証するためのものであることに留意されたい。

【0245】

上記（Ａ）に関して、子が$.children.levelsを含む場合、親よりも小さくなければならない。上記（Ｂ）に関して、子が$.children.maxを含む場合、最初の要素を除いて、親のアレイ（もしあれば）のエンベロープ内に収まらなければならない。親にレベルがない場合、制限がないことを意味することに留意されたい。上記（Ｃ）に関して、$.valid.{before,after}は、少なくとも親と同じくらい狭くなければならない。拡張されるべき子許可証が実際に親の子であることのさらなる確認が存在する。これは、子許可証識別子が親許可証のデータインスタンスに記憶された子のリストにあることを保証することによって行われる。

【0246】

次に、さらなる拡張追加要求が作成され、子許可証に関連付けられたコンピューティングモジュールに送信される。好ましくは、子許可証は、許可証または拡張を取り消すことを説明する実施形態と同様の様式で、受信した要求を確認する。好ましくは、子許可証は、要求が親許可証から受信されたことを確認する。好ましくは、子は、要求がセキュアコンピューティング環境内から受信されたことを確認する。好ましくは、子は、現在取り消されていないことを確認する。

【0247】

好ましくは、新しい拡張の追加によって拡張の最大数を超えないことのチェックがある。好ましくは、これは子許可証自体によって行われる。代替的に、これは以下に同じ見出しの下で説明する「許可の検証」を用いて親許可証によって行われる。

【0248】

確認が完了すると、子許可証に新しい拡張が追加される。好ましくは、以下のステートメントに従う：

【数17】

【0249】

子は、適切な成功／失敗メッセージを親に返す。親許可証は、適切な成功／失敗メッセージを要求の元の送信者に返す。

【0250】

許可の確認
一実施形態では、許可を確認するための方法が提供される。好ましくは、本方法は、ＡＰＩとして任意の当事者に提供される。より好ましくは、本方法は、上記の「許可証との対話」の見出しの下で説明したように、「query」エンドポイントを介して提供される。

【0251】

本方法の呼び出し元は、好ましくは、許可証識別子と許可確認データとを含む要求を作成する。任意選択で、要求は、確認すべき許可の拡張を含む。任意選択で、複数の許可が確認される。

【0252】

確認されるべき許可を含む要求が送信される。

【0253】

好ましくは、許可証が取り消されたかどうかを決定するためにチェックが行われる。取り消されている場合、許可証は、許可証および／または許可が無効であることを示すエラーメッセージまたは無効メッセージで応答する。

【0254】

好ましくは、許可確認データは、確認されるべき許可の名前を含む。より好ましくは、許可確認データは表現を含む。好ましくは、許可確認データは、評価されたときに許可名に関連付けられた値（名前－値ペアの値）に作用する表現を含む。好ましくは、表現は、表現言語の形態である。好ましくは、表現言語は、許可証が実施する許可検索パターンを提供し、それによって、適切な許可（複数可）に照らして要求を確認する。

【0255】

好ましくは、表現言語は、許可証が許可の名前および値の様々な特徴をクエリすることを可能にする特徴を含む。表現言語および例の様々な特徴を以下に提供する。好ましくは、表現はＪＳＯＮフォーマットで提供される。

【0256】

許可証は、それ自体の許可証データインスタンスに照らして、したがって関連性のある許可（複数可）に照らして表現を評価し、次いでその結果を呼び出し元に提供する。

【0257】

特定の表現言語が以下で説明されるが、当業者であれば、正規表現などの他の表現言語を使用してもよいことを理解するであろう。

【0258】

任意選択で、要求は、拡張の言語に関する指示を含む。したがって、呼び出し元は、使用を望む言語において表現の柔軟性を有する。

【0259】

好ましくは、表現は、トップレベル演算子を定義する単一のプロパティを有するオブジェクトである。これが二項演算子である場合、オペランドは、オブジェクトのアレイにおいて演算子プロパティの値として定義される。これらのオブジェクトは、さらなる二項演算子、単一のオペランドオブジェクトを取る単項演算子、単純な値を取るリーフ項、または単なる単純な値であってもよい。表現「not」、「eq」、「permission」を含む例示的な表現を以下に示す：

【数18】

【0260】

分かりやすく言えば、これは、許可「com.acme.customer.type」が「wholesale」に等しくないかどうかを確認する表現である。

【0261】

追加的に、許可証（または拡張）が特定の許可を有するかどうかを決定するための表現が存在する。表現言語の基本的な用語には、「permission」および「has」が含まれる。

【表4】

【0262】

好ましくは、表現で使用することができるいくつかの比較演算子は以下である：equal to，not equal to，less than，less than or equal to，greater than，and greater than or equal to。

【表5】

【0263】

好ましくは、以下のクエリ演算子は、文字列マッチングで使用するためのものである：contains，starts with，matches，ends。

【表6】

【0264】

好ましくは、いくつかの単項演算子を表現において使用することができる：not，minus，length。

【表7】

「falsy」とは、偽、０、または空の文字列を意味することに留意されたい。

【0265】

好ましくは、いくつかのブール演算子を表現において使用することができる：and，or。

【表8】

「truthy」とは、真、非ゼロ数、または空ではない文字列を意味することに留意されたい。

【0266】

好ましくは、以下の数学的クエリ演算子を使用して、表現を構築することができる：add，subtract，divide，modulus。

【表9】

【0267】

好ましくは、セットクエリ演算子を用いて表現を強化することができる：includes，in。

【表10】

両者はほぼ同一であり、それらのオペランドの順序が異なるだけであることに留意されたい。

【0268】

以下に、いくつかの例示的な表現と、それらが何をチェックしているかについてのそれらの関連する分かりやすい説明とを提供する。

【数19】

これは、許可証が「isRoot」要素を含むことを確認する。これは、値をチェックしないことに留意されたい（本例では、値がある場合、必ず真に設定されるだけである）。

【数20】

これは、「com.example.foo」許可が文字列「bar」に等しいことを確認する。

【数21】

これは、「com.acme.region」許可が「Europe/」で始まることを確認する。

【数22】

これは、「gold」または「silver」のいずれかが「com.acme.customer.level」許可に存在すること、または「com.acme.customer.points」が１０００より大きいことを確認する。一方（または両方）が真である場合、表現は、トップレベルの「or」により、真と評価する。

【0269】

許可の取得
一実施形態では、１つまたは複数の許可を得るための方法が提供される。好ましくは、本方法は、ＡＰＩとして任意の当事者に提供される。より好ましくは、本方法は、上記の「許可証との対話」の見出しの下で説明したように、「query」エンドポイントを介して提供される。

【0270】

本方法の呼び出し元は、好ましくは、少なくとも自分が関心を持っている許可証の識別子を含む要求を作成する。要求は、関連性のある許可証に送信される。

【0271】

１つの許可にのみ関心がある場合、本方法の呼び出し元は、好ましくは、関心がある許可の名前を含む要求を作成する。

【0272】

任意選択で、要求は拡張を含む。拡張が提供される場合、関心のある特定の拡張が使用される。

【0273】

要求を受信すると、許可証は、特定の許可が提供されている場合は許可のコンテンツで応答し、許可のすべてのリストが要求されている場合はそれで応答する。

【0274】

任意選択で、許可証（および／または許可証の拡張）に関連付けられたすべての許可を得る方法は提供されない。そのような方法を提供しないことによって、許可証保持者が行うことを許可されているすべてをサードパーティが見ること（これは重要な情報を漏洩する可能性がある）ができないので、システムのセキュリティが向上する。これは、呼び出し元が特定の許可を要求する必要があるようなサービスまたは方法を提供するだけであると説明することもできる。

【0275】

有効性のチェック
一実施形態では、所与の許可証（および任意選択で、その祖先）がしばらくの間有効であるかどうかを外部当事者がチェックすることを可能にする方法が提供される。好ましくは、本方法は、ＡＰＩとして任意の当事者に提供される。より好ましくは、本方法は、上記の「許可証との対話」の見出しの下で説明したように、「query」エンドポイントを介して提供される。

【0276】

本方法の呼び出し元は、好ましくは、許可証識別子を含む要求を送信する。任意選択で、要求は、以下のうちのいずれか１つまたは複数を含む：
・有効性がチェックされる時間（時間が提供されていない場合、現在の時間が使用される）、
・（もしあれば）有効性をチェックすべき祖先の数を決定するための祖先識別子、および／または
・有効性をチェックすべき拡張。

【0277】

好ましくは、拡張が提供される場合、祖先はチェックされない。

【0278】

好ましくは、祖先識別子は、以下のうちの１つである：no，parent，grandparent，great-grandparent，root。

【0279】

好ましくは、要求は、チェックされている許可証に関連付けられたコンピューティングモジュールによって受信される。

【0280】

要求を受信すると、許可証は、提供された時間（特定の時間が提供されない場合には現在の時間となる）が許可証の有効性範囲内であることをチェックする。有効性範囲は、特別な許可「$.valid.before」および「$.valid.after」ならびに許可証インスタンスデータ構造の「revoked」要素内にあるものとして定義される。要求において拡張が提供される場合、存在する場合には所与の拡張内で同じフィールドがチェックされる。拡張が存在しない場合にはエラーが返される。

【0281】

要求が「no」以外の祖先識別子を含む場合、さらなる有効性要求が生成され、親許可証に送信される。親許可証は、各許可証のデータインスタンスに記憶されたparent要素にしたがって識別される。この要求は、許可証ツリーの適切なレベルがトラバースされるように構築される。各許可証は、１つ上のレベルについてしか知らないので、各親は、さらに別の有効性要求を送信し、ツリー許可証構造の関連性のある部分をトラバースする。有効性がチェックされた許可証は、その親から、要求されたすべての親許可証の有効性に関する指示を受け取る。

【0282】

許可証は、許可証の有効性に関する指示で応答する。応答はまた、要求された任意の祖先の有効性に関する指示を含む。

【0283】

署名の検証
一実施形態では、あるメッセージが所与の許可証の保持者によって署名されたことを検証するための方法が提供される。好ましくは、本方法は、ＡＰＩとして任意の当事者に提供される。より好ましくは、本方法は、上記の「許可証との対話」の見出しの下で説明したように、「query」エンドポイントを介して提供される。

【0284】

本方法の呼び出し元は、好ましくは、署名が適用されたメッセージと、署名自体と、許可証の識別子とを含む要求を送信する。任意選択で、許可証の識別子は要求のヘッダおよび／またはアドレスに含まれ、署名およびメッセージはボディにおいて提供される。

【0285】

任意選択で、拡張文字列も提供される。要求に拡張文字列が存在する場合、「default」拡張とは対照的に、特定の拡張のholderPubKeyが使用される。

【0286】

要求の受信者は、適切なholderPubKeyを見つけ、次いで、署名が関連する私有鍵（許可証の保持者のみが有するべきである）の保持者によって署名されたことを検証する。適切なholderPubKeyを見つけることは、好ましくは、正しい許可証データインスタンスを取得し、次いで、適切な拡張（使用される場合、使用されない場合は「デフォルト」拡張が使用される）を取得することを必要とする。好ましくは、要求は、上記の「許可証との対話」の見出しの下で説明したように、許可証識別子を含むアドレスを用いて、識別子（したがって、適切な許可証データインスタンス）に関連付けられた許可証コンピューティングモジュールにおいて受信される。

【0287】

好ましくは、署名を検証することは、メッセージをハッシュし、検証されるべきholderPubKeyを使用して署名を解読し、両者を比較することを含む。両者が同じである場合には、holderPubKeyに関連付けられた私有鍵のみを使用して署名を生成したことになる。より好ましくは、署名、したがって署名の検証は、ＲＦＣ６９７９に記載されているＥＣＤＳＡ署名およびＥＣＤＳＡ署名アルゴリズムを使用する。

【0288】

検証の結果は、応答で呼び出し元に戻される。好ましくは、応答はまた、応答が指定された許可証コンピューティングモジュールからのみ発信されたことを証明するために署名される。より好ましくは、署名は応答のヘッダにおいて提供され、検証結果はボディにおいて提供される。

【0289】

セッション
任意選択で、一実施形態では、上記の「許可証との対話」の見出しの下で列挙したもののような許可証との対話は、セッション認可が行われた後に行われる。

【0290】

許可証保持者は、…/sessionエンドポイント（または…/sendまたは…/query）を呼び出すことによってセッション鍵／トークンを要求し得る。例示的なセッション要求トヘッダは、以下を含み得る：

【数23】

【0291】

そのような要求が行われると、許可証は、それらに提供された適切なエンドポイント（例えば、session）と共に呼び出される。許可証は、以下の署名された命令を含む要求を受信すべきである：

【数24】

【0292】

好ましくは、「instruction」オブジェクトは、本明細書で説明したように既知のデータ構造に署名が適用されるように文字列化される。

【0293】

timestampは、好ましくは、リプレイ攻撃を防止するために現在の時間から約１分以内であり、periodは、秒単位のセッションの要求長さである。許可証は、（提供される場合、適切なextensionを使用して）署名を確認し、セッション許可証を要求の期間以下の任意の値に設定してもよい。

【0294】

parentが存在する場合、要求は、許可証保持者ではなく親許可証の保持者からのものである。この場合、署名は、親の公開鍵に照らしてチェックされなければならない。好ましくは、このチェックは、上記の「署名の検証」の見出しの下で説明したように、「署名の検証」方法を使用して行われる。

【0295】

要求内にparentが存在するとき、いかなる拡張も無視される。

【0296】

任意選択で、成功した応答は、以下のようになる：

【数25】

【0297】

要求が、例えば悪い署名によって拒絶された場合、応答は次のようになり得る：

【数26】

【0298】

セッションperiodが（例えば２０秒から１週間など、許可証の構成および／またはセキュア処理環境の構成によって決定されるような）最小値よりも小さいかまたは最大値よりも大きい場合、セッション鍵は作成されない。

【0299】

セッションperiodが許容可能な範囲内にある場合、セッション鍵が作成され、応答のヘッダで返される。

【0300】

要求が正しく署名されているが、期間が短すぎる場合、期間は最小値まで増加され得る。

【0301】

セキュリティ
任意選択で、一実施形態では、さらなるsecurityエンドポイントが提供される。

【0302】

攻撃者が、観察者をだますために偽の許可証を生成することを望む可能性があり得る。この攻撃を軽減する１つの方法は、許可証から受信した応答のヘッダを検査することである。すべての真正の許可証は、「例示的なシステムの概要」で説明したように、同じ周知のプロセス識別子を有する。このプロセス識別子は、各メッセージのヘッダにおいて提供される。

【0303】

さらなるセキュリティが必要とされる場合、応答において暗号証拠を提供することもできる。したがって、許可証の公開鍵は、許可証によって署名された任意の応答の確認を可能にする/securityエンドポイントから利用可能である。

【0304】

例示的な要求は、以下のヘッダを含み得る：

【数27】

【0305】

そのようなＡＰＩ要求に対する応答は、任意選択で、以下の形態を有する：

【数28】

【0306】

したがって、公開鍵により、サードパーティは、自身のデバイスを使用して署名を確認することができる。

【0307】

コンピューティングモジュール
ここで図６を参照すると、本開示の少なくとも１つの実施形態を実施するために使用され得るコンピューティングデバイス２６００の例示的な簡略化されたブロック図が提供される。様々な実施形態では、コンピューティングデバイス２６００は、上記で図示および説明したシステムまたは方法のいずれかを実装するために使用され得る。例えば、コンピューティングデバイス２６００は、セキュアコンピューティング環境１０８を動作させ、いくつかのコンピューティングモジュール１０２、１０４、１０６をホストするように構成され得る。コンピューティングデバイス２６００は、許可証保持者に関連付けられた許可証保持デバイスとなるように構成され得る。コンピューティングデバイス２６００は、コンピューティングモジュール１０２、１０４、１０６自体となるように構成され得る。したがって、コンピューティングデバイス２６００は、ポータブルコンピューティングデバイス、パーソナルコンピュータ、サーバ、サーバの集合、または任意の電子コンピューティングデバイスであり得る。

【0308】

コンピューティングデバイス２６００がセキュアコンピューティング環境１０８を提供しているか、またはセキュアコンピューティング環境の一部を提供している場合、内部で動作するコンピューティングモジュール１０２、１０４が互いに通信するためのシステムおよび方法も提供する。任意選択で、これは、それ自体の内部ＤＮＳおよびルーティングシステムを通じて提供される。任意選択で、これはＩＰＣコールを通じて提供される。

【0309】

図６に示すように、コンピューティングデバイス２６００は、メインメモリ２６０８および永続ストレージ２６１０を含むストレージサブシステム２６０６と通信するように構成され得る、１つまたは複数のレベルのキャッシュメモリおよびメモリコントローラを有する１つまたは複数のプロセッサ（集合的に２６０２とラベル付けされる）を含み得る。メインメモリ２６０８は、図示のように、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）２６１８および読取り専用メモリ（ＲＯＭ）２６２０を含むことができる。ストレージサブシステム２６０６およびキャッシュメモリ２６０２は、本開示で説明されるようなトランザクションおよびブロックに関連付けられた詳細などの情報の記憶のために使用され得る。プロセッサ（複数可）２６０２は、本開示で説明されるような任意の実施形態のステップまたは機能を提供するために利用され得る。

【0310】

プロセッサ（複数可）２６０２はまた、１つまたは複数のユーザインターフェース入力デバイス２６１２、１つまたは複数のユーザインターフェース出力デバイス２６１４、およびネットワークインターフェースサブシステム２６１６と通信することができる。

【0311】

バスサブシステム２６０４は、コンピューティングデバイス２６００の様々な構成要素およびサブシステムが意図通りに互いに通信することを可能にするためのメカニズムを提供し得る。バスサブシステム２６０４は、単一のバスとして概略的に示されているが、バスサブシステムの代替の実施形態は、複数のバスを利用してもよい。

【0312】

ネットワークインターフェースサブシステム２６１６は、他のコンピューティングデバイスおよびネットワークへのインターフェースを提供し得る。ネットワークインターフェースサブシステム２６１６は、他のシステムからデータを受信し、コンピューティングデバイス２６００から他のシステムにデータを送信するためのインターフェースとして機能し得る。例えば、ネットワークインターフェースサブシステム２６１６は、データ技術者がデバイスをネットワークに接続することを可能にし、データ技術者が、データセンターなどの遠隔地にいても、デバイスにデータを送信し、デバイスからデータを受信することができるようにし得る。

【0313】

ユーザインターフェース入力デバイス２６１２には、キーボードなどの１つまたは複数のユーザ入力デバイス、統合マウス、トラックボール、タッチパッド、またはグラフィックタブレットなどのポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンなどのオーディオ入力デバイス、および他のタイプの入力デバイスが含まれ得る。一般に、「入力デバイス」という用語の使用は、コンピューティングデバイス２６００に情報を入力するためのすべての可能なタイプのデバイスおよびメカニズムを含むことを意図するものである。

【0314】

１つまたは複数のユーザインターフェース出力デバイス２６１４は、ディスプレイサブシステム、プリンタ、またはオーディオ出力デバイスのような非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）などのフラットパネルデバイス、発光ダイオード（ＬＥＤ）ディスプレイ、またはプロジェクションもしくは他のディスプレイデバイスであり得る。一般に、「出力デバイス」という用語の使用は、コンピューティングデバイス２６００から情報を出力するためのすべての可能なタイプのデバイスおよびメカニズムを含むことを意図するものである。１つまたは複数のユーザインターフェース出力デバイス２６１４は、例えば、説明されたプロセスおよびその中の変形形態を実行するアプリケーションとのユーザ対話を、そのような対話が適切であり得るときに、容易にするためのユーザインターフェースを提示するために使用され得る。

【0315】

ストレージサブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供し得る基本プログラミングおよびデータ構成を記憶するためのコンピュータ可読記憶媒体を提供し得る。アプリケーション（プログラム、コードモジュール、命令）は、１つまたは複数のプロセッサによって実行されると、本開示の１つまたは複数の実施形態の機能を提供し得、ストレージサブシステム２６０６に記憶され得る。これらのアプリケーションモジュールまたは命令は、１つまたは複数のプロセッサ２６０２によって実行され得る。ストレージサブシステム２６０６は、追加的に、本開示にしたがって使用されるデータを記憶するためのリポジトリを提供し得る。例えば、メインメモリ２６０８およびキャッシュメモリ２６０２は、プログラムおよびデータのための揮発性ストレージを提供することができる。永続ストレージ２６１０は、プログラムおよびデータのための永続（不揮発性）ストレージを提供することができ、フラッシュメモリ、１つまたは複数のソリッドステートドライブ、１つまたは複数の磁気ハードディスクドライブ、関連する取り外し可能な媒体を有する１つまたは複数のフロッピーディスクドライブ、関連する取り外し可能な媒体を有する１つまたは複数の光学ドライブ（例えば、ＣＤ－ＲＯＭまたはＤＶＤまたはブルーレイ）ドライブ、および他の同様の記憶媒体を含み得る。そのようなプログラムおよびデータは、本開示で説明されるような１つまたは複数の実施形態のステップを実行するためのプログラム、ならびに本開示で説明されるようなトランザクションおよびブロックに関連付けられたデータを含むことができる。

【0316】

コンピューティングデバイス２６００は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション、または以下で説明される任意の他のデバイスを含む、様々なタイプのものがあり得る。追加的に、コンピューティングデバイス２６００は、１つまたは複数のポート（例えば、ＵＳＢ、ヘッドフォンジャック、ライトニングコネクタなど）を介してコンピューティングデバイス２６００に接続され得る別のデバイスを含み得る。コンピューティングデバイス２６００に接続され得るデバイスは、光ファイバコネクタを受け入れるように構成された複数のポートを含み得る。したがって、このデバイスは、光信号を、処理のためにデバイスをコンピューティングデバイス２６００に接続するポートを介して送信され得る電気信号に変換するように構成され得る。コンピュータおよびネットワークの絶えず変化する性質により、図６に示されるコンピューティングデバイス２６００の説明は、デバイスの好ましい実施形態を例示するための特定の例としてのみ意図される。図６に示されるシステムよりも多いまたは少ない構成要素を有する多くの他の構成が可能である。

【0317】

上記で説明した様々な方法は、コンピュータプログラムによって実装され得る。コンピュータプログラムは、上記で説明した様々な方法のうちの１つまたは複数の方法の機能を実行するようにコンピュータに命令するように構成されたコンピュータコードを含み得る。そのような方法を実行するためのコンピュータプログラムおよび／またはコードは、１つまたは複数のコンピュータ可読媒体、またはより一般的にはコンピュータプログラム製品上で、コンピュータなどの装置に提供され得る。コンピュータ可読媒体は、一時的であっても非一時的であってもよい。１つまたは複数のコンピュータ可読媒体は、例えば、電子システム、磁気システム、光学システム、電磁気システム、赤外線システム、もしくは半導体システム、または、例えばインターネットを介してコードをダウンロードするためのデータ送信用の伝搬媒体とすることができる。代替的に、１つまたは複数のコンピュータ可読媒体は、半導体またはソリッドステートメモリ、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、剛性磁気ディスク、およびＣＤ－ＲＯＭ、ＣＤ－Ｒ／Ｗ、またはＤＶＤなどの光ディスクなど、１つまたは複数の物理コンピュータ可読媒体の形態をとることができる。

【0318】

一実装形態では、本明細書で説明されるモジュール、構成要素、および他の特徴は、個別の構成要素として実装されるか、またはＡＳＩＣ、ＦＰＧＡ、ＤＳＰ、もしくは同様のデバイスなどのハードウェア構成要素の機能に統合され得る。

【0319】

一実装形態では、本明細書で説明されるモジュールは、モノリシックサーバ上で実行されるプロセス、マイクロサービス、ラムダ関数などのコンピューティングプロセスとして実装することができる。コンピューティングモジュールへのアクセスは、本明細書で説明されるようなＡＰＩを用いて提供することができる。これらのモジュールは、任意選択で、他のコンピューティングモジュールおよび／またはコンピューティングデバイスとの間でデータを送受信するように構成されたサブモジュールを含む。好ましくは、モジュールは、データの一時的および／または永続的な記憶のためのメモリを備える。特に、メモリは、（後のアクセスのために）許可証自体の許可証データインスタンスを永続的に記憶するように構成される。

【0320】

「ハードウェア構成要素」または「ハードウェアモジュール」は、特定の動作を実行することが可能な有形（例えば、非一時的）物理構成要素（例えば、１つまたは複数のプロセッサのセット）であり、特定の物理的様式で構成または配置され得る。ハードウェア構成要素は、特定の動作を実行するように永続的に構成された専用回路またはロジックを含み得る。ハードウェア構成要素は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）またはＡＳＩＣなどの専用プロセッサであり得るか、またはそれを含み得る。ハードウェア構成要素はまた、特定の動作を実行するためにソフトウェアによって一時的に構成されるプログラマブルロジックまたは回路を含み得る。

【0321】

したがって、「ハードウェア構成要素」または「ハードウェアモジュール」という語句は、特定の様式で動作するように、または本明細書で説明される特定の動作を実行するように、物理的に構築されるか、永続的に構成される（例えば、ハードワイヤードされる）か、または一時的に構成される（例えば、プログラムされる）可能性のある有形のエンティティを包含するものと理解されるべきである。

【0322】

加えて、モジュールおよび構成要素は、ハードウェアデバイス内のファームウェアまたは機能回路として実装することができる。さらに、モジュールおよび構成要素は、ハードウェアデバイスとソフトウェア構成要素との任意の組合せで、またはソフトウェア（例えば、機械可読媒体または送信媒体において記憶されたかまたは場合によっては具現化されたコード）のみで実装することができる。

【0323】

別段に明記されていない限り、以下の説明から明らかなように、説明全体を通して、「determining（決定すること）」、「providing（提供すること）」、「calculating（計算すること）」、「computing（コンピューティングすること）」、「identifying（識別すること）」、「combining（組み合わせること）」、「establishing（確立すること）」、「sending（送信すること）」、「receiving（受信すること）」、「storing（記憶すること）」、「estimating（推定すること）」、「checking（チェックすること）」、「obtaining（取得すること）」などの用語を利用した説明は、コンピュータシステムのレジスタおよびメモリ内の物理（電子）量として表されるデータを操作し、コンピュータシステムメモリもしくはレジスタまたは他のそのような情報ストレージ、送信もしくはディスプレイデバイス内の物理量として同様に表される他のデータに変換する、プロセス、機能、マイクロサービス、コンピュータシステム、または同様の電子コンピューティングデバイスのアクションおよびプロセスを指すことを理解されたい。

【0324】

本明細書および特許請求の範囲で使用される「comprising」という用語は、「consisting at least in part of」を意味する。「comprising」という用語を含む本明細書および特許請求の範囲における各ステートメントを解釈する際、その用語が前置きされている１つまたは複数の特徴以外の特徴も存在し得る。「comprise」および「comprises」といった関連用語も同様に解釈されるべきである。

【0325】

本明細書に開示される数の範囲（例えば、１～１０）への言及は、その範囲内のすべての有理数（例えば、１、１．１、２、３、３．９、４、５、６、６．５、７、８、９、１０）、およびその範囲内の有理数の任意の範囲（例えば、２～８、１．５～５．５、３．１～４．７）への言及も包含するものであり、したがって、本明細書に明示的に開示されるすべての範囲のすべての部分範囲は、本明細書によって明示的に開示されることが意図される。これらは、具体的に意図されるものの例にすぎず、列挙される最低値から最高値までの数値のすべての可能な組合せが、同様に本出願に明示的に記載されているとみなされるべきである。

【0326】

本明細書で使用される場合、「and/or（および／または）」という用語は、「および」もしくは「または」または両方を意味する。

【0327】

本明細書で使用される場合、名詞に続く「(s)」は、その名詞の複数形および／または単数形を意味する。

【0328】

要素の単数への言及は、そのような要素の複数への言及を排除するものではなく、逆もまた同様である。

【0329】

上記の説明は、限定的ではなく例示的であることが意図されることを理解されたい。上記の説明を読んで理解すると、多くの他の実装形態が当業者に明らかになるであろう。本開示は、特定の例示的な実装形態を参照して説明されているが、本開示は、説明された実装形態に限定されるものではなく、添付の特許請求の範囲内の修正および変更を伴って実施され得ることが認識されよう。したがって、本明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。したがって、本開示の範囲は、添付の特許請求の範囲を参照して、そのような特許請求の範囲が権利を与えられる均等物の全範囲と共に決定されるべきである。

【図1】