特表 2023-519302 共有クラウドプラットフォーム内のエンティティ中心のリソース指向データベースとして実装されたデータ管理者のための方法及びシステム

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

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

(11)【公表番号】

(43)【公表日】2023-05-10

(54)【発明の名称】共有クラウドプラットフォーム内のエンティティ中心のリソース指向データベースとして実装されたデータ管理者のための方法及びシステム

(51)【国際特許分類】

   G06F 16/13 20190101AFI20230428BHJP

   G06F 21/64 20130101ALI20230428BHJP

【ＦＩ】

G06F16/13

G06F21/64

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022558038

(86)(22)【出願日】2021-03-16

(85)【翻訳文提出日】2022-11-18

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

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

(87)【国際公開日】2021-10-07

(31)【優先権主張番号】16/833,548

(32)【優先日】2020-03-28

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＵＮＩＸ

２．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】522375235

【氏名又は名称】データペアレンシー，エルエルシー

【氏名又は名称原語表記】ＤＡＴＡＰＡＲＥＮＣＹ，ＬＬＣ

【住所又は居所原語表記】２４２９９ Ｂｒａｍｂｌｅｗｏｏｄ Ｄｒ．，Ｎｏｖｉ，ＭＩ ４８３７４（ＵＳ）

(74)【代理人】

【識別番号】110000659

【氏名又は名称】弁理士法人広江アソシエイツ特許事務所

(72)【発明者】

【氏名】シアー，ティモシー，エー．

(57)【要約】

高度に安全なデータベースプラットフォームは、エンティティ中心であり、エンティティ制御される。データの投稿、照会、及び取得は、標的エンティティに関連する文書への要求エンティティのアクセスを制御する一意の一方向性の関係識別子に結合される。データは、エンティティ及び関係に不変にマッピングされる。プラットフォームは、ドメイン分割され、スキーマに依存せず、順序維持型である。本発明は、人々、グループ、ビジネス、デバイス、及び／又はマイクロサービスに関するデータに容易に適合される、信頼できるプラットフォーム又はサービスを提示する。

【特許請求の範囲】

【請求項1】

ネットワークを介してデータを送受信するように構成されたデータベースプラットフォームに文書を記憶させる方法であって、
前記ネットワークを介して第１のエンティティを前記プラットフォームに接続するステップと、
前記ネットワークに接続されたサーバで、第２のエンティティとの関係を確立するための前記第１のエンティティからの要求を受信するステップと、
前記関係のための一意の一方向性の関係分散識別子（ＲＤＩＤ）を割り当てるステップと、
前記第２のエンティティに関連する文書を前記プラットフォーム上に投稿するために、ユニフォームリソースインジケータ（ＵＲＩ）パスに前記ＲＤＩＤを含めるように前記第１のエンティティに要求するステップと、
を含む方法。

【請求項2】

前記データベースプラットフォームは、サードパーティコンピュータアプリケーションを介して前記第１のエンティティから前記ＵＲＩを受信する、請求項１に記載の方法。

【請求項3】

前記サーバで投稿文書を取り込むステップをさらに含み、前記取り込みは、前記取り込まれた文書からのデータを前記第１のエンティティ及び前記第２のエンティティに不変に関連付けることを含む、請求項１に記載の方法。

【請求項4】

前記データベースプラットフォームは、前記取り込みステップの１つ以上を実行するために、前記ネットワークに接続されたクラウドベースのサービスを使用する、請求項３に記載の方法。

【請求項5】

前記サーバで投稿文書を取り込むステップであって、前記取り込みは、前記投稿文書を、共通階層フォーマット（ＣＨＦ：Ｃｏｍｍｏｎ Ｈｉｅｒａｒｃｈｉｃａｌ Ｆｏｒｍａｔ）を有する複数のデータコンポーネントに解析し、前記複数のデータコンポーネントはＣＨＦデータを含む、ステップと、
前記ＣＨＦデータに基づいてメタヘッダを生成するステップであって、前記メタヘッダは、前記ＵＲＩパスと、前記投稿文書を一意に識別する文書ＩＤ（ＤｏｃＩＤ）とに関するキー値（ＫＶ）情報を含む、ステップと、
前記ネットワークに接続された１つ以上のデータストアで前記ＣＨＦデータをＣＨＦ文書として記憶するステップと、
をさらに含む、請求項１に記載の方法。

【請求項6】

前記ＣＨＦ文書をシャーディングするさらなるステップを含み、前記記憶ステップは、２つ以上のデータストアで前記シャーディングされたＣＨＦ文書を記憶するステップをさらに含む、請求項５に記載の方法。

【請求項7】

前記ＵＲＩパスは、階層的であり、ドメイン及び少なくとも１つの下位コンポーネントを含み、前記プラットフォームは、前記ＣＨＦデータを前記ＲＤＩＤ、前記ドメイン、及び前記少なくとも１つの下位コンポーネントに不変に関連付ける、請求項５に記載の方法。

【請求項8】

第１のエンティティ識別情報及び第２のエンティティ識別情報を含む入力の組み合わせをハッシュすることによって前記ＲＤＩＤを生成するステップをさらに含む、請求項１に記載の方法。

【請求項9】

前記入力の組み合わせは、前記プラットフォームにのみ知られている秘密のシステム値をさらに含む、請求項８に記載の方法。

【請求項10】

前記ハッシュステップは、前記ＲＤＩＤをアイコンとして生成するために、複数の入力に対して動作する変換代数を使用することを含む、請求項８に記載の方法。

【請求項11】

データベースプラットフォームと通信している１つ以上のサーバに、
ネットワークを介して第１のエンティティを前記プラットフォームに接続する動作と、
前記第１のエンティティから、第２のエンティティとの関係を確立するための要求を受信する動作と、
前記関係のための一意の一方向性の関係分散識別子（ＲＤＩＤ）を割り当てる動作と、
前記第２のエンティティに関連する文書を前記プラットフォーム上に投稿するために、ユニフォームリソースインジケータ（ＵＲＩ）パスに前記ＲＤＩＤを含めるように前記第１のエンティティに要求する動作と、
フォーマットが決められたパーサを用いて、投稿文書を、共通階層フォーマット（ＣＨＦ：Ｃｏｍｍｏｎ Ｈｉｅｒａｒｃｈｉｃａｌ Ｆｏｒｍａｔ）を有する複数のデータコンポーネントに解析する動作であって、前記複数のデータコンポーネントはＣＨＦ文書を含む、動作と、
前記ネットワークに接続された第１のデータ記憶位置で、前記パスと、前記ＣＨＦ文書を一意に識別する文書ＩＤ（ＤｏｃＩＤ）とに関するキー値（ＫＶ）情報を記憶する動作と、
前記ネットワークに接続された１つ以上のデータストアを含む第２のデータ記憶位置で、前記ＣＨＦ文書を記憶する動作と、を実行させる命令を記憶している、非一時的なコンピュータ可読媒体。

【請求項12】

前記投稿文書の少なくとも一部をハッシュするステップをさらに含む、請求項１１に記載のコンピュータデバイス。

【請求項13】

前記ＣＨＦ文書は、ハッシュＣＨＦキーデータをもたらす前記自然キーのハッシュと、ハッシュＣＨＦ値データをもたらす前記自然値のハッシュとを含む、請求項１２に記載のコンピュータデバイス。

【請求項14】

前記投稿文書は、自然キー及び関連する自然値を含み、前記ＣＨＦ文書は、前記パス及び前記ＤｏｃＩＤに関する前記ＫＶ情報を含み、前記自然キーをそれらのハッシュＣＨＦキーデータに関連付け、前記自然値をそれらのハッシュＣＨＦ値データに関連付ける辞書をさらに含む、請求項１３に記載のコンピュータデバイス。

【請求項15】

前記ＣＨＦ文書は、記憶させる前に暗号化される、請求項１１に記載のコンピュータデバイス。

【請求項16】

前記データベースプラットフォームは、非リレーショナルデータベースである、請求項１１に記載のコンピュータデバイス。

【請求項17】

ネットワークを介してデータを送受信するように構成されたデータベースプラットフォーム内で文書データを安全に記憶及び取得する方法であって、
第１のエンティティから受信した第１のＵＲＩに応答して文書を取り込むステップであって、前記文書は自然キー及び自然値を含み、前記第１のＵＲＩは、前記第１のエンティティと第２のエンティティとの間の関係を一意に一方向に定義する第１のＲＤＩＤを含む、ステップと、
前記文書をＣＨＦデータコンポーネントに解析するステップと、
ハッシュＣＨＦデータコンポーネントを生成するために、前記自然データコンポーネントをハッシュするステップと、
前記ネットワークを介して前記プラットフォームに接続されたデータストアに前記ハッシュＣＨＦデータコンポーネントを記憶させるステップと、
を含む方法。

【請求項18】

前記記憶ステップの後に、前記取り込まれた文書内の前記自然キー及び自然値の一部又はすべてを取得するために、第２のＵＲＩを含む前記第１のエンティティからの照会を受信するステップであって、前記第２のＵＲＩは前記ＲＤＩＤを含む、ステップと、
前記ハッシュＣＨＦデータから、前記照会を満たす結果を導出するために前記記憶されたハッシュＣＨＦデータを検索するステップと、
を含む、請求項１７に記載の方法。

【請求項19】

前記検索ステップは、前記文書、及び前記文書の任意の自然なコピーを無視する、請求項１８に記載の方法。

【請求項20】

前記記憶ステップの後に、前記取り込まれた文書内の前記自然キー及び自然値の一部又はすべてを取得するために、第２のＵＲＩを含む前記第１のエンティティからの照会を受信するステップであって、
前記第２のＵＲＩは、ＲＤＩＤを含まないが、少なくともドメイン及びクラスを含む階層パスを含む、ステップと、
前記ハッシュＣＨＦデータから、前記照会を満たす結果を導出するために前記記憶されたハッシュＣＨＦデータを検索するステップと、
を含む、請求項１７に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、デジタルコンピュータによるデータ記憶及び処理に関し、具体的には、共有クラウドプラットフォーム上のデータベースシステムに関し、より具体的には、効率を損なうことなくデータセキュリティを保証する方法に関する。

【背景技術】

【0002】

利便性及び機能性を犠牲にすることなく、コンピュータデータベースのハッキング及びセキュリティ違反を防ぐために、多くの努力がなされてきた。堅牢な資格情報検証及びデータ暗号化など、ハッカーに打ち勝つためにセキュリティ対策を強化することに努力が集中してきたが、データベースは、セキュリティバリアの背後のデータを取得するための持続的で長期的な努力に対して脆弱なままである。従来技術のアプローチは、企図された違反に打ち勝つために城の周りにより高くより厚い壁を立てることに類似している。

【0003】

この問題は、技術がクラウドプラットフォームモデルに移行するにつれて新たな次元をとり、クラウドプラットフォームモデルは、ネットワークを通じて外側又は外部のエンドポイントへのアクセス及びサービスを公開するネットワークプラットフォームを通じてサービスを提供する。クラウドプラットフォームによってサポートされる典型的なサービスは、サービスとしてのデータベース（ＤａａＳ：Ｄａｔａｂａｓｅ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）、サービスとしてのインフラストラクチャ（ＩａａＳ：Ｉｎｆｒａｓｔｍｃｔｕｒｅ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）、サービスとしてのプラットフォーム（ＰａａＳ：Ｐｌａｔｆｏｒｍ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）、及び多くの他の「サービスとしての」提供物である。プラットフォームへのアクセスポイントが急増するにつれて、ハッキング及びランサムウェアなどの攻撃に対する防御がより困難になり、追加のセキュリティ層を積層することで、不便かつ非効率的になる可能性がある。

【0004】

一方、大多数のデータベースは、行及び列の表に配置される、例えば「姓」、「生年月日」、「血液型」などのスキーマを必要とする「リレーショナル」データベースとして構造化される。照会／取得言語ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造化言語）は、すべてのリレーショナルデータベースアクセスの基礎を形成する。このような設計及びアクセス制限は、現実世界のエンティティがデータを最適に記憶する能力を限定する可能性がある。このようなデータベースの一例は、特許文献１「Ｒｅｌａｔｉｏｎｓｈｉｐ－Ｂａｓｅｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ（関係に基づく承認）」（Ｂｅｃｋ）である。Ｂｅｃｋは、関係を記憶するために表の行及び列を使用し（例えば、図４の´７６８）、別の従来のデータベースに記憶された文書へのアクセスを制御するために、「フロントエンド」の一部としてこれらの関係を調べる。

【0005】

より新しいデータベース設計は、データコンポーネントが表としてではなく「値」に関連付けられた「キー」（「値」に関連付けられた「タグ」と呼ばれることもある）として編成される、ＭｏｎｇｏＤＢ、Ｃｏｕｃｈｂａｓｅ、ＣｏｕｃｈＤＢ、Ｍａｒｋｌｏｇｉｃ、ＡＷＳ ＤｙｎａｍｏＤＢ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ ＤＢ、及び他のＫｅｙ／Ｖａｌｕｅデータベース製品などの「ＮｏＳＱＬ」（ＳＱＬだけでなく）としてますます知られる非リレーショナルデータベースを含む。このようなデータベースモデルは、例えば、フェアビュー病院／患者／ジョン・スミス／検査結果など、ドメイン／クラス／エンティティ／コレクションのような、人間が使い慣れた編成の階層モードにより資する。しかしながら、ＭｏｎｇｏＤＢ及びＣｏｕｃｈＤＢなどのデータベースは、独自の欠点を有する。例えば、照会を加速するために、これらのデータベースは、インデックスするフィールドの先験的な定義を必要とする。これは、記憶されたデータがインデックスパラメータと一致することを必要とする。インデックス指定にフィールドを有していない文書は、インデックス照会に含まれない。言い換えると、ＭｏｎｇｏＤＢ及びＣｏｕｃｈＤＢを使用して構築されたデータベースは、スキーマ固有である。

【0006】

クラウドの攻撃対象領域及びアクセス可能性の低下、堅固なセキュリティ、柔軟でスキーマに依存しないアクセス、及びそのデータに対するエンティティ制御を提供するデータベースが必要とされている。

【発明の概要】

【0007】

エンティティ中心のドメイン分割可能な管理者制御データベースプラットフォームが開示される。データの投稿、照会、及び取得は、例えば標的エンティティに関する文書へのアクセスを要求するエンティティ間の関係アクセス特権を識別する一意の一方向性（一方向）の「関係識別子（ｒｅｌａｔｉｏｎｓｈｉｐ ｉｄｅｎｔｉｆｉｅｒｓ）」に結合される。例えば、エンティティ１が医師であり、エンティティ２が患者である場合、プラットフォームは、エンティティ２の臨床検査結果に関する文書を投稿するときに医師が使用する一意の関係分散識別子（Ｒｅｌａｔｉｏｎｓｈｉｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｉｄｅｎｔｉｆｉｅｒ、ＲＤＩＤ）を割り当てる。プラットフォームに取り込まれたすべての文書からの情報の各コンポーネントは、情報が取り込まれた時点で提供されたＲＤＩＤ及びエンティティ情報を保持する。したがって、データベースは、エンティティ中心、すなわちエンティティ及びそれらの関係の周りに構造化されているものとして提示する。

【0008】

プラットフォームへのアクセスは、一般に、好ましくは階層ＨＴＴＰユニフォームリソース識別子（ＵＲＩ）を使用するインターネット又はイントラネットなどのネットワークを介している。これにより、企業のデータの一貫性がありながら柔軟なデータモデリングのためのドメイン駆動設計が可能になる。例えば、プラットフォームは、使い慣れたＨＴＴＰ（又はＨＴＴＰＳ）動詞ＧＥＴ及びＰＯＳＴを使用して、標準的なＲＥＳＴリソース指向アプリケーションプログラムインターフェース（ＡＰＩ）によってアクセスすることができる。したがって、データ照会は、ＡＰＩ呼び出しにおける単純な「パス」定義とすることができる。これにより、例えばドメイン／クラス／ＲＤＩＤ／コレクションなどの階層パスにおいてＲＤＩＤを直接表現することができる。同様のデータ要素のコレクションは、人口統計、イベント、読み取り値などの特徴を含む、エンティティのデータ階層内の「アスペクト」として編成される。すべてのフィールドがアドレス指定可能であるため、インデックスパラメータを指定する必要がないので、本発明は、高速のアドホック照会を可能にする。

【0009】

データベースは、信頼できるデータ管理者プラットフォームによって監督される。データ管理者プラットフォームは、ローカルのエンティティ所有サービス、又はクラウドプロバイダによって提供される契約サービスであってもよい。データ管理者プラットフォームは、エンティティデータ、アクセス、及び更新を管理する。データ管理者プラットフォームは、任意のアクセス／更新動作においてプラットフォームが使用するエンティティからのプライバシー規則を受け入れる。これらのプライバシー規則は、データプラットフォームの（１つ又は複数の）エンティティデータストア（以下、「データストアセット」又は単に「データストア」）に送信された照会を含む、データベースに送信された照会から機密データを隔離するためにも使用することができ、要求元の役割にさらに依存してもよい。これにより、エンティティによって望まれるプライバシーの文脈を表しながら、エンティティデータに対する透明性を保証する。

【0010】

エンティティに関するデータは、エンティティドメインにルーティングする階層構造に配置されたリソース又はアドレス指定可能な値を含み、エンティティはその多くに属することができ、好ましくは表されている現実世界エンティティと一致する。これらのリソースは、「アスペクト」又はコレクションと呼ばれる関連するリソースのグループ又はセットにさらに編成される。加えて、アスペクトは「仮想」及び／又は「合成」であってもよく、複数の物理的又は仮想的アスペクトが組み合わされて命名された仮想的アスペクトになる。サンプルのアスペクトは、「人口統計」、すなわちエンティティの識別特性とすることができる。ここでも、フェアビュー病院／患者／ジョン・スミス／検査結果が一例である。デバイスの分野及びモノのインターネットからの一例は、ｘ社／温度－センサ／サーモ２６／読み取り値であり得る。

【0011】

要約すると、本発明は、ドメイン分割可能、エンティティに結合され、エンティティ関係中心、自己主権型アイデンティティ、順序維持型、不変、スキーマに依存せず、及びリソース指向であり、クラウドサービス上で使用することができ、人々、グループ、ビジネス、デバイス、及び／又はマイクロサービスに関するデータに容易に適合される、信頼できるプラットフォーム又はサービスを提示する。インフラストラクチャがエンティティ中心のプラットフォームからのデータ及びプライバシー／セキュリティを管理する必要性があるが、これはほとんど満たされていない。このようなインフラストラクチャから利益を得る産業は、ヘルスケアドメイン、顧客管理及び関係（ＣＲＭ）、個人財務及び銀行取引、ＤＬＴ（Ｄｉｓｔｒｉｂｕｔｅｄ ｌｅｄｇｅｒ Ｔｅｃｈｎｏｌｏｇｙ：分散型台帳技術）台帳、軍事及び防衛、並びにメディケア／メディケードなどの政府機関を含む。

【図面の簡単な説明】

【0012】

本発明のこれら及びその他の特徴及び利点は、以下の詳細な説明及び添付図面と併せて検討すると、より容易に理解されるだろう。

【0013】

【図1】それらの相互作用を示す、プラットフォームコンポーネントの概要を示す図である。

【0014】

【図2】データ管理者プラットフォームと構成インターフェースとの間の相互作用を示す別の図である。

【0015】

【図3】データベースコンポーネントの相互作用を示す別の図である。

【0016】

【図4】データ管理者トポロジーのいくつかの例を示す図である。

【0017】

【図5】パラメータを有する例示的なＵＲＩ要求を示す図である。

【0018】

【図6】照会（ＧＥＴ）及び更新（ＰＯＳＴ）の一般的なＨＴＴＰ要求フローを示す図である。

【0019】

【図7】システム及びＣＨＦデータ文書を使用してデータ照会をナビゲートするためのプロセスフローの表現である。

【0020】

【図8】直接ＤｏｃＩＤ照会のプロセスフローの図である。

【0021】

【図9】１つのＲＤＩＤに限定された照会のプロセスフローの図である。

【0022】

【図10】１つのＲＤＩＤに制限されない照会のフローの図である。

【0023】

【図11】プラットフォームとの分散型台帳技術統合の一例を示す図である。

【0024】

【図12】ハッシュキー及びハッシュ値の過程による割り当てを示す例示的なソース文書である。

【0025】

【図13】ハッシュキー及びハッシュ値のｔ配列並びに複数のノードを示す、図１２と同じ例である。

【0026】

【図14】データの安全な遠隔処理を対象とする本発明の別の態様を示す図である。

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

【0027】

一般的な参照によれば、本文及び添付図は、データベースシステム１０、データプラットフォーム１２、エンティティ１１、アプリケーションプログラムインターフェース１４、データストア１８、クライアントライブラリ２４、データベースアクセス層２６、及び他の参照に言及する。いくつかの図を通して類似の参照番号が類似の又は対応する部分を示す図を参照して、関係分散識別子（ＲＤＩＤ）及びドメイン駆動階層設計を使用してデータを管理する新しい方法が開示されている。ドメイン駆動設計は、一般に階層的であり、その点で、例えば「ユーザＸＹＺ／作業ファイル／顧客８８／見積など、従来のファイル管理システムに匹敵する。

【0028】

・システムコンポーネントの概要
図１、図２、及び図３は、データ管理者エンティティプラットフォーム（以下、「データプラットフォーム」又は単に「プラットフォーム」）１２を含むデータベースシステム１０の３つの表現を示す。データプラットフォームは、ローカルのエンティティ所有サービス、又はクラウドプロバイダによって提供される契約サービスであってもよい。データプラットフォームは、エンティティデータ、アクセス、及び更新を管理する。データベースシステム１０と相互作用するのはエンティティ１１である。エンティティ１１は、現実又は仮想の、人物（例えば、患者、顧客）、ビジネス、政府機関、デバイス、マイクロサービス、前述のいずれか又はすべてのグループ、１つ以上のグループのサブグループ、及び多くの他の現実世界のオブジェクトであってもよい。

【0029】

エンティティ１１は、通信プロトコルとして使い慣れたＨＴＴＰ又はＨＴＴＰＳを使用するＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）リソース指向アプリケーションプログラムインターフェース１４（ＡＰＩ）を使用してデータプラットフォーム１２と相互作用することができる。一実施形態では、エンティティユーザは、データプラットフォーム１２と相互作用するときに、ＨＴＴＰ動詞ＧＥＴ及びＰＯＳＴのみを使用することができる。エンティティはまた、１つ以上のサードパーティアプリケーション１６を使用してデータプラットフォーム１２と相互作用することもできる。所与の状況セットに適し得るアプリケーション１６の例は、ウェブブラウザ、ユーザインターフェースライブラリ、ＮＡＴＳ２．０などのパブリッシュ－サブスクライブシステム（ｐｕｂ／ｓｕｂ）、及びＫｕｂｅｍｅｔｅｓなどのマイクロサービスオーケストレータを含むタスクプロセッサを含む。アプリケーション１６は、メッセージング及びタスク処理サービスを含むことができ、アプリケーションが、プラットフォーム内で発生するイベントに関するプラットフォームからの通信を受信する場合、通信の受信が、プラットフォーム内でトリガされたイベントへのアプリケーションによってサブスクリプションの結果として発生する場合、トリガされたイベントが外部プラットフォームインターフェースを介して外部アプリケーションに通信される場合、アプリケーションがビジネスプロセス管理（ＢＰＭ）フレームワークを含む場合、ＢＰＭフレームワークが分析アプリケーションにデータを照会及び提供する用に構成されている場合を含む。アプリケーション１６は、ＴＩＢＣＯ Ｊａｓｐｅｒｓｏｆｔなどの分析データを受け入れるためのプラットフォーム、又は人工知能（ＡＩ）プラットフォームを含む分析アプリケーションであって、ＡＩプラットフォームはＴｅｎｓｏｒなどデータを受け入れるためのプラットフォームを含む、分析アプリケーション、又はデバイス読み取り値を認識するように構成された分析アプリケーションなど、１つ以上の別の分析アプリケーションを含むことができ、分析アプリケーションは、Ａｐｐｌｅ Ｈｅａｌｔｈｋｉｔなどのデータを受け入れるためのプラットフォームを含み、又は分析アプリケーションは、Ｓａｍｓｕｎｇ ＳＡＭＩなどのデータを受け入れるためのプラットフォームを含み、又は分析アプリケーションは、Ｖａｌｉｄｉｃなどのデータを受け入れるためのプラットフォームを含み、又は分析アプリケーションはモノのインターネット（ＩｏＴ）フレームワークを含み、又は分析アプリケーションは分散型台帳技術（ＤＬＴ）を含む。上記のアプリケーションは、データベースシステム１０と適切に組み合わせることができるアプリケーションを例証及び代表するように意図される。これらは限定することを意味するものではない。

【0030】

データベースシステム１０は、エンティティ１１に関するキー値（ＫＶ）データを記憶するための１つ以上のデータストア１８を含む。プラットフォームは、プラットフォーム上で発生しているイベントを受信及び／又はこれに反応する様々な外部プラットフォームインターフェース２０に接続され得る。プラットフォームは、ローカルで、又はネットワーク接続を通じて、データストア１８にアクセスすることができる。図３に示される実施形態では、ローカル接続は、ボックスで囲まれたデータストアによって示されている。少なくとも１つのサーバは、手続き呼び出しを通じて任意のデータストア１８とインターフェースしてもよく、又はネットワークインターフェース層を通じてインターフェースしてもよい。当業者は、ＫＶデータを記憶することができる真のＫＶデータストア以外のデータストアがあることを理解するだろう。本明細書及び特許請求の範囲の目的のために、「データストア」は、キー値データストア及びＫＶデータと互換性のあるデータストアの両方を含む。同様に、プラットフォームは、プラットフォーム１２データに関する内部データ及び命令を受信、応答、及び／又は生成する、１つ以上の内部プラットフォームインターフェース２２を含むことができる。プラットフォーム１２は、特に外部サービスとインターフェースするためのクライアントライブラリ２４をさらに含むことができる。クライアントライブラリ２４の一例は、ユーザをシステムに入力するのに有用であり得るＭｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙである。

【0031】

各データストア１８は、データベースアクセス層２６を通じて外部からアクセスすることができる。好適な実施形態では、データベースアクセス層２６は、データストア１８とデータプラットフォーム１２との間のＡＰＩ層として実装される。別の実施形態では、ＤＢアクセス層２６は、内部ライブラリインターフェースを通じて（１つ又は複数の）データストア１８に呼び出しを引き渡すことができる。単一エンティティ読み取り要求は、そのエンティティに割り当てられた次の利用可能なマスタ／ミラーデータストア１８にマッピングされてもよい。２つ以上のエンティティをカバーする照会は、利用可能なデータストアセットのすべてのデータストア１８にブロードキャストされてもよい。次いで、ＤＢアクセス層２６は、プラットフォームにデータを返すためにすべての応答を集約することができる。システムは、プライバシー規則を有するプライバシーモデル２８をさらに含む。プライバシーモデルは、ＤＢアクセス層２６を通じた結果の返送を制限するために、照会の結果として取得されたデータに対して適用することができる。同様に、書き込み要求は、エンティティに割り当てられたすべてのデータストアセット１８にブロードキャストされてもよい。ＤＢアクセス層２６は、すべてのセットからの応答を監視し、一定数のデータストア１８応答が受信されたときにのみ返信する。これにより、一貫性を可能にし、現存のデータストア１８のいずれか１つからの読み取りアクセスを可能にする。

【0032】

図１に示されるように、システムはまた、データベースシステム１０、並びにエンティティ及びアスペクトに適合された階層ドメインを設計するのに有用なメタモデル開発プラットフォーム３０も含むことができる。開発プラットフォーム３０は、Ｅｃｌｉｐｓｅ、ＩｎｔｅｌｌｉＪ／Ｗｅｂ Ｓｔｏｒｍ／ＧｏＬａｎｄなどのような既存のフレームワーク上に構築することができる。データベースシステム１０は、メタモデル開発を他のアプリケーション開発機能に組み込むためのメタモデルプラグイン３２をさらに含むことができる。例えば、メタモデルプラグイン３２は、プライバシーモデル２８と協働して、エンティティのデータの特定の定義されたアスペクトへのアクセスを制御するための機能を考案することができる。一実施形態では、開発プラットフォーム３０及びメタモデルプラグイン３２は、文書のクラス内又はクラス間の文書のアスペクトを設計及び／又は指定することができ、以下でさらに論じられるように、一部のデータをアクセスに利用できないようにするために、プライバシーモデル２８に準拠するメンバーノード又は値を定義することができる。エクスポートされたプライバシーモデル２８は、エンティティプライバシー設定のためのソースになり得る。プライバシーモデル２８におけるプライバシー設定及び規則は、（１つ又は複数の）データストア１８内の所与のエンティティにアクセス可能なデータタグ及び／又は値のみならず、アクセスを許可されたユーザによるエンドポイントロールの条件も含むことができる。また、主要なエンティティプライバシーモデル２８に加えて、サブエンティティは、「エンティティＸＹＺによって要求された場合にのみ私のＨＩＶ検査結果の返信として照会の結果を返す」など、個々の関係に併せて調整された所望のプライバシー規則を課すことを含む、それらの情報へのアクセスを定義し、さらに制限することができる。これらのプライバシー規則はその後、エンティティデータの階層に組み込まれてもよい。

【0033】

・階層ドメイン駆動設計の背景及び概要
事前に、本明細書及び特許請求の範囲で使用される「文書」という用語は「データ」を意味する。文脈が特に逆の構成を要求しない限り、「文書」は、静的データ値（例えば、姓＝ｊｏｎｅｓ、生年月日＝０６／３０／１９９４、現在の温度＝１８８°Ｃ）、及び実行可能コード、呼び出しルーチン、又はＫｕｂｅｒｎｅｔｅｓなどのマイクロサービスオーケストレータの呼び出しなど、データベースシステム１０のコンポーネントによってリソースとして使用されるデータの両方を意味する。好適な実施形態では、文書（データ）は、「共通階層フォーマット（Ｃｏｍｍｏｎ Ｈｉｅｒａｒｃｈｉｃａｌ Ｆｏｒｍａｔ）」（ＣＨＦ）に解析される。ＣＨＦは、キー及び関連する値を含み、平坦化された階層として表すことができるフォーマットである。例えば、キーは配列に関連付けられ、配列は複数の値（例えば、「１年生の生徒」：［「サリー」、「ディック」、「ジェーン」］）を有すると仮定する。配列［］は親値であり、そのメンバーは子、又は子値である。この階層は、ノードの階層順配列として表すことができ、ノードは、以下でさらに論じられるように、文書内に見られるタグ及び値を含む。ＣＨＦに解析されたデータの一例が図１２の上のボックスに示されており、キー及び値、例えば「発行者」（キー（又はタグ））及び「ｈｔｔｐｓ：／／ｓａｎｄｂｏｘ．ｂｌｕｅｂｕｔｔｏｎ．ｃｍｓ．ｇｏｖ」（「発行者」キーに関連付けられた値）を示している。以下でさらに記載されるように、ＣＨＦ文書は、容易に照会され、様々な他の文書フォーマットへの照会出力を可能にする形式でデータを保持する。一実施形態では、ＣＨＦデータは、図１２に示されるようにＪａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）としてフォーマットされる。図１３は、図１２からのＣＨＦデータの階層的特徴を表す複数のノード１０４を示す。ＸＭＬ、ＹＡＭＬ、又はバイナリ表現など、ユースケースに応じて他のフォーマットを使用することができる。一実施形態では、パーサはストリーム型である。好適な実施形態では、パーサは、自然キー－自然値の関連性を維持する。ここでも、本明細書で使用される「文書」及び「データ」は、静的なキー値、並びにデータベースシステム１０の任意のコンポーネントに内部に向けられたトリガ又はコンピュータ命令又は外部に向けられた命令を含むデータの両方をカバーすることが強調される。

【0034】

図４は、ドメインＡ（３４）、ドメインＢ（３６）、及びドメインＣ（３８）の３つのドメインに分類可能な、それに関する複数の文書４０を有するエンティティ１１を示す。ドメインＡは２つのクラスで構成され、第１のクラスは３つのアスペクトを有し、第２のクラスは２つのアスペクトを有する。５つのアスペクトの各々は、１つ以上の文書で構成される。ドメインＢは１つのクラスで構成されるが、そのクラス内には多くのコレクション「Ｃ」があり、各コレクションは１つ以上の文書を含む。ドメインＣは、単一の「イベント」コレクションを有する単一のクラスで構成され、イベントコレクションは複数の文書を有する。これら３つの例は、当然ながら単なる例示であり、限定ではない。エンティティはいくつのドメインに属してもよく、エンティティはいくつのクラスを有してもよく、クラスはいくつのアスペクト又はコレクションを有してもよい。さらに、図４は、各々３つのサブコンポーネントを有する３つの最上位コンポーネント（ドメインＡ、Ｂ、及びＣ）を示しているが、エンティティは、エンティティの好みに応じて所与のドメインの下に配置された、３つより未満又は３つを超えるサブコンポーネントを有してもよい。

【0035】

好適な実施形態では、プラットフォームは、ワールドワイドウェブ（ＷＷＷ）のプロトコルとして誰もが知っているユニフォームリソースインジケータ（ＵＲＩ）を使用して、文書（リソースを含む）の要求（ＧＥＴ及びＰＯＳＴの両方）を受信する。図５を参照すると、例示的なＵＲＩは、ＨＴＴＰＳ（又はＨＴＴＰ）プロトコル４２（ＨＴＴＰＳ：／／）、サービスアクセスエンドポイント及びポート４４（ａｐｉ．ｄａｔａｐａｒｅｎｃｙ．ｃｏｍ）、ドメイン名４６（ヘルスケア）、エンティティタイプ名４８（患者）、ＲＤＩＤアクセストークン５０（１２３４５６７８）、アスペクト名５２（ケアプラン）、及び任意の照会修飾子５４（？ＳｔａｒｔＤａｔｅ＝´´２０１５－０４－３０´´）を含む複数の部分で構成される。したがって、データ照会は、ＡＰＩ呼び出しにおける単純な「パス」定義とすることができる。以下で論じられるように、ＲＤＩＤアクセストークン５０は、ドメイン及びアスペクト内のすべてのアクセス許可されたエンティティにわたる照会のために空であってもよい。（この機能は、標準照会言語ＳＱＬにおける´ＳＥＬＥＣＴ＊´コマンドと同様である。）

【0036】

ＰＯＳＴ要求に対する追加のオプションは、例えば、「失効」照会修飾子を指定することによって時間が経過したとき（例えば、「？失効＝６０」［６０秒後に削除］）、又はエンティティ全体の照会を許可するか否か（例えば、「？ｅｎｔｉｔｙＡｃｃｅｓｓ＝ｐｒｉｖａｔｅ」）によって、データの削除を可能にする。失効機能は、例えば１０秒の有効期限を有するロック文書を投稿し、ロック状態を調査するためにこの文書に問い合わせることによって、「ロック」プロトコルを実装するために使用することができる。ロック文書が失効して削除されると、さらなる処理を進めることができる。

【0037】

・プラットフォームセキュリティ
データベースシステム１０は、複数のレベルで保護されている。始めに、データプラットフォーム１２へのアクセスは一般に、ただし排他的ではなく、ウェブプロトコルＨＴＴＰＳによるものである。ＨＴＴＰＳは、様々な企画で表されるトランスポート層セキュリティ（ＴＬＳ）プロトコルを通じてインターネット内のデータの安全なデータの輸送を提供する、一般的なネットワークプロトコルである。プラットフォームとのすべての相互作用は、ＨＴＴＰＳトランスポート、又は安全な輸送の他の補助的な方法によって保護される。

【0038】

また、すべてのデータは、好ましくは、輸送中及び静止中の両方において、暗号化されたプラットフォームのコンポーネント間で転送される。一実施形態では、データプラットフォームは、サーバ公開暗号キー及びサーバプライベート暗号キーを含む暗号キーペアを受信するコンピュータサーバを含む。好適な実施形態では、サーバ暗号キーペアは、楕円曲線暗号（ＥＣＣ）サーバ暗号キーペアを含む。サーバＥＣＣキーペアは、例えばＣｕｒｖｅ２５５１９、ＡＥＳ－ＣＢＣ－２５６、及びＨＭＡＣ－ＳＨＡ－２５６上でモデル化することができる。

【0039】

サーバ暗号キーペアに加えて、データプラットフォーム１２上に登録された各エンティティには、エンティティ公開キー及びエンティティプライベートキーを含むエンティティキーペアも割り当てられる。一実施形態では、データは、エンティティが最初に登録されたときに作成された一意の公開／プライベートキーペアによって暗号化／復号される。このプライベートキーペアは、プラットフォーム１２の外部には知られず、したがってプラットフォーム内のデータのセキュリティを強化する。

【0040】

一実施形態では、データプラットフォーム１２は、暗号化形式で投稿されるデータを受信し、暗号化は、エンティティ登録時に通過してエンティティシステムプロファイルに記憶されたキーペアからの一意のキーのエンティティ使用から生じる。一実施形態では、データプラットフォーム１２は、以下に記載されるようにこれらを解析及び記憶する前に、受信した文書４０を復号することができる。復号は、エンティティのキーペアを使用することによって達成され得る。

【0041】

好適な実施形態では、データは、セキュリティを強化するためにハッシュされる。ハッシュされるデータは、プラットフォーム上のデータ、並びにエンティティ分散識別子（ＥＤ ＩＤ）及び関係分散識別子（ＲＤＩＤ）など、プラットフォームによって生成された内部値を含む。ハッシュは、当業者にとって既知の任意の方法を使用して行うことができる。以下に記載されるプロセスにしたがって生成されるアイコンを含むハッシュは、一方向性（一方向）である。ハッシュもアイコンも、元データを確認するために「復号（デコード）」することはできない。

【0042】

一実施形態では、投稿されるデータは、一実施形態において線形代数符号化方式を使用する、アイコンジェネレータ（ＩＧ）を使用してアイコン化される。アイコンを生成することは、参照によりその全体が本明細書に組み込まれる、Ｄｉｒｅｅｎの米国特許第６，４９３，８１３号明細書「Ｍｅｔｈｏｄ ｆｏｒ Ｆｏｒｍｉｎｇ ａ Ｈａｓｈｉｎｇ Ｃｏｄｅ（ハッシュコードを形成する方法）」の教示を採用することができる。ＩＧは、性能を最大化するために表とともに実装された線形フィードバックシフトレジスタを含むことができる。ＩＧは、一実施形態では６４ビットである固定幅を有するアイコンを生成することができる。ＩＧは、カオス分布を利用し、入力データの長さ又はそれが有する病理にかかわらずアイコン幅が表すことができる値の範囲にわたって均一に分布する英数字アイコンを生成することができる。一実施形態では、ＩＧは、順次入力値のブロックがアイコンフィールドにわたって広く分散されることを保証する。別の実施形態では、ＩＧは、あらゆる可能な６４ビット値が変換（アイコン化）された場合、結果として得られたアイコンも同様に、ただし異なる順序で、あらゆる可能な６４ビット値に変換されるように、完全な変換を生成する。入力が６４ビット以下であれば、２つの入力が同じアイコン値を生成することはない。より長い長さの入力データは不完全な変換をもたらすことになるが、これはほとんどすべての用途において依然として有用である。

【0043】

別の実施形態では、変換はフラクタルである。別の実施形態では、変換は拡張可能である。ＩＧは、６４ビットを超えるコードを生成するために使用することができる。６４ビットコードと同じ品質を有する長いコードを一つずつ生成することもできるため、ＩＧを再プログラミングすることなく任意の所望の長さのコードを生成することができる。別の実施形態では、ＩＧは、可変長入力データを変換することができる。好適なＩＧは、一度に１バイトの入力データを処理するため、アイコンをいつでも読み取ることができ、したがって（１つ又は複数の）任意の入力データ長に基づくコードを生成することができる。

【0044】

連想処理ユニット（ＡＰＵ：Ａｓｓｏｃｉａｔｉｖｅ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）は、アイコン代数をサポートするＩＧに接続されてもよい。アイコンは組み合わせ的に処理することができ、元の入力データが変換前に操作されていれば、同じ結果を生成する。例えば、「ヴィンス」が変換され、次いで「ロンバルディ」が変換された場合、「ヴィンス・ロンバルディ」から生成されたであろうものと同じアイコンを生成するために、２つの結果的なアイコンを組み合わせることができる。好適なＡＰＵは、連結（上記の例のような）、入力データの先頭又は末尾からのデータの削除；入力データの組み合わせ（ＸＯＲ）、又は入力データのコンポーネントの変更を含む、様々な仮想機能を達成することができる。アイコン代数の主な利点は、ＡＰＵが、入力データを再処理する代わりに、短い固定長アイコン上でこれらの機能を迅速に達成することである。アイコンは、入力データの任意の大きさのブロックの代わりになる。

【0045】

本発明の別の非常に重要なセキュリティ機能は、上記で論じられ、以下でより詳細に論じられるように、ＵＲＩ ＰＯＳＴ及びＧＥＴ要求内の一意の一方向性関係識別子（ＲＤＩＤ）を、文書及びデータコンポーネントに結合することである。プラットフォームへのアクセスを制限するために使用される、ＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）又はＯＡｕｔｈ ２．０、又はそれ以降などの様々な識別、承認、及び認証技術の使用によって、追加のセキュリティが維持される。好適な実施形態では、プラットフォームへのアクセスは、アクセスを得る前にエンティティ名及びエンティティパスコードをシステムに提供するための要件など、追加のセキュリティ対策によって保護される。当業者は、アクセス制御及びデータ暗号化に関して本明細書に記載されるセキュリティ対策は、単に代表的なものであり、限定するものではないことを理解するだろう。

【0046】

・プラットフォームの動作
・データの投稿
簡単にするために、第１のエンティティが、第２のエンティティに関する１つ以上の文書を投稿又は取得することを望んでいると仮定する。システムにアクセスするために、第１のエンティティは、データベースシステム１０に登録し、第２のエンティティとの関係を確立していなければならない。データプラットフォーム１２は、最初に、その関係を管理するＲＤＩＤを第１のエンティティに割り当てている。ＲＤＩＤは、その関係に対して一意であり、要求エンティティから一方向性、すなわち一方向である。この例では、要求元は第１のエンティティであり、第２のエンティティは標的である。第１のエンティティは、第２のエンティティとの関係（及びそれが関係する任意の他のエンティティとの関係）について、そのＲＤＩＤを知っている。

【0047】

例えば、第１のエンティティが病院であり、第２のエンティティが人物であると仮定する。これら２つのエンティティは、１つ、２つ、３つ、４つ、又はさらに多くのＲＤＩＤを有することができる。プラットフォーム１２は、患者としての人物に関連するこれらの文書に関する第１の関係に関する第１のＲＤＩＤを割り当てることができる。病院は、患者に関する文書を投稿又は取得したい場合に、このＲＤＩＤを使用する。第２のエンティティがたまたま医師であったと仮定する。プラットフォーム１２は、医師の役割に関連する病院と人物との間のこの第２の関係に関する第２のＲＤＩＤを割り当てることができる。又は、同じ人物が、病院の患者としての役割において自分の血液に対して行われた臨床検査の結果を見たいと望んでいると仮定する。これは、第３のＲＤＩＤを必要とする第３の関係となる。又は、その人物が、病院受け入れ方針に関する情報を望んでいると仮定する。これは、第４のＲＤＩＤを必要とする第４の関係となる。別のエンティティは、その第２のエンティティがメンバーである病院の産科病棟で診療している医師のグループであってもよく、これにより、３つのエンティティ間の関係の様々な組み合わせをカバーするさらに多くのＲＤＩＤの割り当てを示す。

【0048】

図６は、第２のエンティティに関連する文書に関する第１のエンティティから生じるＰＯＳＴ及びＧＥＴコマンドを処理する方法の好適な実装形態の簡略化されたフローである。第１のエンティティは、ＲＥＳＴ ＡＰＩインターフェース１４を通じてデータプラットフォーム１２にｈｔｔｐｓ（又はｈｔｔｐ）要求によってＰＯＳＴ又はＧＥＴコマンドを送信する（「ｐｏｓｔ－ＵＲＩ」又は「ｇｅｔ－ＵＲＩ」）。ＰＯＳＴコマンドは、ＴＬＳプロトコルを通じて保護され、及び／又は輸送中に暗号化され、及び／又は静止中に暗号化されてもよい。投稿コマンドは、プラットフォーム暗号化フィールドを有する第２のＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎなどの第２の認証技術によってさらに保護され、及び／又はＯＡｕｔｈ ２．０以上を含むことができる。第２の認証技術はまた、エンティティのＥＤＩＤ（後述）を含むことができる。一実施形態では、データプラットフォーム１２は、ＡＰＩから投稿コマンドを受信する。別の実施形態では、投稿コマンドは、ＲＥＳＴアーキテクチャスタイルにしたがってプラットフォーム１２で受信され、及び又はウェブサービスを介してプラットフォーム１２で受信される。ＰＯＳＴ要求は、ＵＲＩの形態であり、ＵＲＩは、ＲＤＩＤアクセストークン５０及び他のコンポーネント、例えばドメイン／クラス／ＲＤＩＤ／コレクションのコンポーネントを含む。

【0049】

後述されるように、ＲＤＩＤは、要求元エンティティ及びデータプラットフォーム１２の両方によって使用される値である。一実施形態では、ＲＤＩＤアクセストークン５０は、プラットフォーム１２によって使用される、より長い及び／又はより複雑な「システムＲＤＩＤ」値から導出される。この実施形態では、「システムＲＤＩＤ」は、例えば投稿及び照会要求を検証するために、及び以下でより詳細に記載されるように値をマッピングするために、プラットフォーム１２によって実際に使用される値である。好適な実施形態では、実際のシステムＲＤＩＤは、要求元エンティティに提供されない。代わりに、ＲＤＩＤアクセストークン５０が要求元エンティティに提供される。ＲＤＩＤアクセストークン５０は、例えば、より長いシステムＲＤＩＤの１２８ビットハッシュ、ベース６２符号化ストリングであってもよい。要求元エンティティがＵＲＩにＲＤＩＤアクセストークン５０を含むとき、プラットフォーム１２は、ＲＤＩＤアクセストークン５０から「実」システムＲＤＩＤの値を導出する。両方とも同じＲＤＩＤ値を表すが、一方はより短く、システムユーザにとってより便利になるように符号化（エンコード）される。

【0050】

当業者は、プラットフォーム１２がこれらのプロセスのためにシステムによって採用されたＲＤＩＤ値をＲＤＩＤアクセストークン５０から導出し得る様々な方法があることを、理解するだろう。文脈が異なる構成を指示しない限り、本明細書及び特許請求の範囲における「ＲＤＩＤ」への言及は、その値が符号化されるか符号化されないかにかかわらず、２つのエンティティ間の関係に割り当てられた一意で一方向性の値を意味する（一方のエンティティは複数の他のエンティティからなってもよいことを想起する）。

【0051】

投稿要求を処理する前に、プラットフォーム１２は、ステップ５６において、使用中のＲＤＩＤが有効であるか否か、すなわち投稿ＵＲＩ５４で渡された情報がＲＤＩＤ内の情報と一致するか否か、並びに第１のエンティティが第２のエンティティ（又は複数のエンティティ）に関連する文書の投稿及び／又は照会を許可するために不可欠な関係特権を実際に有するか否かを判定するために、ＵＲＩのＲＤＩＤコンポーネントを評価する。一実施形態では、検証ステップは、投稿ＵＲＩ５４に収容されたＲＤＩＤアクセストークン５０から導出可能な情報を、データストア１８から取得された第２のエンティティ資格情報から導出可能な情報と比較することを含む。ＲＤＩＤが有効化されていない場合、要求は中止され、プラットフォーム１２はエラーを返す。ＲＤＩＤが要求されたアクセス特権に対して有効化されている場合、プラットフォーム１２は次のステップに進み、これは文書を投稿すること、又はＧＥＴ要求を介して照会を発行することであってもよい。

【0052】

ＲＤＩＤを検証した後、データプラットフォーム１２は、ステップ５８において、要求がＰＯＳＴであるかＧＥＴコマンドであるかを評価する。好適な実施形態では、ＲＥＳＴ ＡＰＩインターフェース１４は、２つのＨＴＴＰ要求動詞、ＧＥＴ（照会）及びＰＯＳＴ（記憶）のみに応答する。オリジン間リソース共有（ＣＯＲＳ）を実装するためのＯＰＴＩＯＮＳ動詞を除き、他のすべてのＨＴＴＰ動詞は、未発見（４０４）戻りコードを返す。したがって、既存のデータを削除又は修正し、こうして不変のデータベースを提供することは不可能である。

【0053】

最初にＰＯＳＴパスを見ると、取り込みのために投稿ＵＲＩ５４がデータプラットフォーム１２で受信される。（便宜上、図６はＰＯＳＴ及びＧＥＴコマンドの両方を処理するいくつかの態様を組み合わせている。図６の上部のＨＴＴＰＳの矢印は、以下に記載されるような投稿ＵＲＩ５４又は取得ＵＲＩ７０とすることができる。）取り込みは、投稿文書がサポートされているフォーマットタイプであるか否かを最初に判定することを含むことができる。フォーマットがサポートされている場合、データプラットフォーム１２は、ステップ６０において、記憶要求で指定されたフォーマットのパーサを使用して複数のデータコンポーネントへの文書を共通階層フォーマット（ＣＨＦ）に解析することができる。データコンポーネントは、（それらのハッシュ値に関連付けられたハッシュキーとは対照的に）それらの自然値に関連付けられた自然キーを含むことができる。解析されたデータコンポーネントはまた、解析動作自体から生じるか又はこれに関連するフォーマットデータを含むことができる。解析はＣＨＦデータを生成し、これは一実施形態ではＪＳＯＮとしてフォーマットされる。ＣＨＦデータは、バイナリ表現でもフォーマットされ得る。再び図１２を参照すると、上のボックスは、キー及び値、例えばそれぞれ「発行者」及び「ｈｔｔｐｓ：／／ｓａｎｄｂｏｘ．ｂｌｕｅｂｕｔｔｏｎ．ｃｍｓ．ｇｏｖ」を示す、ＣＨＦに解析されたデータの一例である。解析が行われる時間、又はその付近で、ＣＨＦデータは、例えばアイコンジェネレータを使用して上述されたように、ハッシュされてもよい。

【0054】

ステップ６２において、プラットフォーム１２は、同時に又はほぼ同時にいくつかの動作、すなわち、文書の一意の文書識別（ｄｏｃＩＤ）を構築すること、及び図６に「ドメイン／エンティティキー」として記されるＵＲＩパスに関する１つ以上のキーを使用してＣＨＦ文書を記憶することを実行する。

【0055】

一実施形態では、プラットフォーム１２は、投稿ＵＲＩ５４のパスで指定されたドメイン／クラス／コレクションへのアクセスを有するエンティティのリスト９０を取得する。投稿ＵＲＩ５４へのアクセスを有するエンティティを列挙するエンティティリスト９０にアクセスするために、プラットフォーム１２は、まず、対象のドメイン／クラス／コレクション内の文書へのアクセスを有するエンティティのデータを収容する文書を取得するための「エンティティリストキー」（「ｅｌ－ｋｅｙ」）８８を最初に生成することができる。ｅｌ－ｋｅｙ８８は、投稿ＵＲＩパスから導出することができ、投稿ＵＲＩ５４のパスで指定されたドメイン／クラス／コレクションへのアクセスを有するエンティティのリストに関連付けられたキー値（ＫＶ）エンティティストア１８内の「ｅｌ－ＵＲＩ」アドレスに対応することができる。好適な実施形態では、データストア１８に記憶されたエンティティのリストは値であり、ｅｌ－ｋｅｙも値も人間が読み取ることはできない。一実施形態では、ｅｌ－ｋｅｙ及び値は、１２８ビットキーを使用してハッシュされる。別の実施形態では、ｅｌ－ｋｅｙ及び値は暗号化される。

【0056】

判定ステップは、ｅｌ－ＵＲＩアドレスからアクセス可能なエンティティリスト９０を取得するために投稿ＵＲＩ５４から生成されたｅｌ－ｋｅｙを使用し、次いで、第２のエンティティがｅｌ－ＵＲＩアドレスにおけるエンティティのリストに含まれるか否かを判定することを含むことができる。第２のエンティティがまだリストされていない場合、プラットフォーム１２は、文書が関連するエンティティのリストに第２のエンティティを追加し、更新されたエンティティリスト９０をデータストア１８に記憶させることができる。生成されたｅｌ－ＵＲＩにエンティティリストが存在しない場合には、プラットフォーム１２は、第１のエンティティを含むそのｅｌ－ＵＲＩに関連付けられた新しいエンティティリスト９０を作成し、次いで、この新しいエンティティリスト９０をデータストア１８に記憶させることができる。

【0057】

判定ステップは、投稿ＵＲＩのパスで指定されたドメイン／クラス／コレクションを共通に有する文書のリストを取得し、次いで、投稿ＵＲＩパスから導出される「文書リストキー」（ｄｌ－ｋｅｙ）を生成することをさらに含むことができる。ｅｌ－ｋｅｙと同様に、ｄｌ－ｋｅｙは、投稿ＵＲＩパスで指定されたドメイン／クラス／コレクション内の文書のリストに関連付けられたデータストア１８内のｄｌ－ＵＲＩアドレスに対応することができる。ｄｌ－ｋｅｙは、データストア１８に記憶された文書の文書リスト７８に対するキーであってもよく、文書リスト７８は、対象の文書内のメタデータで構成された文書エントリのリストに加えて、文書内のキー及び値で構成された辞書で構成されてもよい。好適な実施形態では、キーも値も人間が読み取ることはできず、辞書内のキー及び値はハッシュされる。一実施形態では、キー及び値のハッシュは６４ビットアイコンである。

【0058】

新しい文書エントリについて文書リスト７８を更新することは、位置＃０において文書リスト７８に文書エントリを追加することと、任意の既存のエントリを１つ下の位置まで移動させることとを含むことができる。文書リスト７８は暗号化されてもよい。判定ステップは、ｄｌ－ＵＲＩアドレスからアクセス可能な文書リスト７８を記憶するために、投稿ＵＲＩから生成されたｄｌ－ｋｅｙを使用することをさらに含むことができる。ｄｌ－ＵＲＩに文書リスト７８が存在しない場合、取り込みは、位置＃０に投稿文書エントリを含むｄｌ－ＵＲＩに関連付けられた新しい文書リスト７８を作成することをさらに含むことができる。この文書リスト７８は、同様に暗号化され、ｄｌ－ｋｅｙアドレスにおいてデータストア１８に記憶されてもよい。

【0059】

上述のように、ステップ６０における解析活動は、投稿文書を複数のデータコンポーネントに解析することを含むことができ、解析されたデータコンポーネントは、それらの自然値に関連付けられた自然キーを含み、「自然」は、ハッシュ又はアイコン化の前に投稿文書内に提示されたキー、値を意味する。（これらのキーは、上記で論じられたｅｌ－ｋｅｙ及びｄｌ－ｋｅｙと混同されるべきではない。この分野の当業者に知られているように、「キー」という用語は、文脈に応じて異なる意味を有する。）上述のように、データコンポーネントは、好ましくはＣＨＦデータを生成するためにＣＨＦフォーマットに解析される。ＣＨＦデータは、ＪＳＯＮとして、又は他のフォーマット（ＸＭＬ、ＹＡＭＬ、バイナリなど）でフォーマットされてもよい。好適な実施形態では、ＣＨＦデータはハッシュされ、別の好適な実施形態では、ＣＨＦデータはアイコン化される。アイコン化ＣＨＦデータはストリング値を含むことができ、アイコン化ＣＨＦデータは６４ビットなどの一定の幅を有することができる。

【0060】

好適な実施形態では、取り込みは、投稿文書内に提示されたデータコンポーネントの辞書１００を策定することをさらに含み、辞書１００は、１）自然キーをそれらの対応するハッシュＣＨＦキーデータに関連付け、２）自然値をそれらの対応するハッシュＣＨＦ値データに関連付け、３）フォーマットデータをそれらの対応するハッシュＣＨＦデータストリングに関連付ける。図１３を参照すると、上のボックスは、１０個の自然値に関連付けられた１０個の自然キーを有するソース文書を表している。このソース文書の辞書１００は、図１２の下部に示されている（右下の参照番号１００を参照）。第１の自然キー１１０は、第１のキー関連性１２０として示される、第１のハッシュキー１１１に関連付けられる。第１の自然値１１２は、第１の値関連性１２２として示される第１のハッシュ値１１３に関連付けられる。同様に、第２の自然キー１１４は、第２のキー関連性１２４として示される第２のハッシュキー１１５に関連付けられる。第２の自然値１１６は、第２の値関連性１２６として示される第２のハッシュ値１１７に関連付けられる。このように、辞書１００は、自然キーをそれらの対応するハッシュキーに関連付け、自然値をそれらの対応するハッシュ値に関連付ける。図１２に示されるように、ハッシュは、アイコン化された６４ビットＣＨＦデータストリングであってもよい。

【0061】

これを念頭に置いて、取り込みステップは、ハッシュＣＨＦデータコンポーネントを含むハッシュキー及びハッシュ値の配列（「ｔ配列」－「タグ配列」の略語）を生成することを含むことができる。ｔ配列は、ＣＨＦデータコンポーネントがパーサから受信される順序で構築されてもよい。図１３を参照すると、第１の自然キー１１０は、ｔ配列１０２の「ゼロ」位置に現れる第１のハッシュキー１１１に関連付けられている。第１の自然値１１２は、ｔ配列１０２の「第１の」位置に現れる第１のハッシュ値１１３に関連付けられている。同様に、第２の自然キー１１４は、ｔ配列１０２の第６の位置に現れる第２のハッシュキー１１５に関連付けられており、第２の自然値１１６は、ｔ配列１０２の第７の位置に現れる第２のハッシュ値１１７に関連付けられている。ｔ配列１０２はまた、内部配列ナビゲーション命令のハッシュも含むことができる。

【0062】

ｔ配列１０２は、複数のデータノード１０４を使用してインデックスされてもよい。一実施形態では、複数のノード１０４は、データノード（「ｄｎｏｄｅ」）を含む。好適な実施形態では、各ｄｎｏｄｅは、１つのキー及びそのキーに関連付けられた少なくとも１つの値に関連する。キー（例えば、「ミドルネーム」）は、これに関連する値を有していない場合がある。本明細書及び特許請求の範囲で使用される際に、「関連する値」は、空のセット、「ヌル値」、又は「値なし」を含む。

【0063】

図１３に示されるように、複数のノード１０４は、ｔ配列１０２の位置０及び１のハッシュがキー：値の関係を有することを示す第１のｄｎｏｄｅ１２８を含む。（ノード内の最後の位置は、元の投稿文書の階層を再構成するために使用され得る、ｄｎｏｄｅ内のｄｎｏｄｅ親インデックスを示す。）同様に、ｄｎｏｄｅ１３０は、位置６及び位置７のハッシュ値がｔ配列１０２においてキー：値の関係を有することを示す。複数のノード１０４は、ｔ配列ノードの一部又はすべてのエンティティへのアクセスを制限する、又は他のエンティティによる許容可能な照会パラメータを制限する内部命令を含む１つ以上のセキュリティノード１３２（「ｓｎｏｄｅ」）をさらに含むことができる。図示される例では、ｓｎｏｄｅ１３２は、これらのＣＨＦデータコンポーネントの１つ以上のノードによるアクセスグループ「ｍｙＤｏｃｔｏｒｓ」及び「ｍｙＮｕｒｓｅ」へのアクセスを制限することができる。要約すると、複数のノード１０４は、キー：値の関連性を有するｔ配列内の少なくとも２つのハッシュＣＨＦデータストリングを指すノードを含み、関連性は、自然キーと自然値との間の関連性に対応する。

【0064】

取り込みステップは、投稿文書から解析されたＣＨＦデータに基づいてメタヘッダを生成することをさらに含むことができる。一実施形態では、メタヘッダは、投稿ＵＲＩパスの個々のコンポーネントのハッシュ又はアイコンを含む、階層投稿ＵＲＩに関するキー値（ＫＶ）情報を含むことができる。メタヘッダはまた、ＣＨＦ文書が作成された時間に関するＫＶ情報も含むことができる。一実施形態では、作成時間はＵＮＩＸエポックナノ秒で測定される。好適な実施形態では、メタヘッダは、投稿ＵＲＩパス内のＲＤＩＤに関するＫＶ情報を含む。メタヘッダは、好ましくは、投稿文書を一意に識別する文書ＩＤ（ＤｏｃＩＤ）に関するＫＶ情報をさらに含む。メタヘッダはまた、文書バージョンに関するＫＶ情報、コンテンツタイプに関するＫＶ情報、及び投稿文書にアクセスすることが許可されたグループに関するＫＶ情報も含むことができる。メタヘッダは、その後にＣＨＦデータが失効すると見なされてデータストア１８から削除される、ナノ秒の持続時間として表される有効期限を含む有効期限をさらに含むことができる。したがって、図７に示されるように、ＣＨＦ文書６６（「投稿文書」とは区別される）は、そのコンポーネント（作成日、ＲＤＩＤ、ｄｏｃＩＤなど）の各々を有するメタヘッダ、辞書、ｔ配列、及び複数のデータノードを含むことができる。

【0065】

取り込みステップはまた、投稿文書から解析されたＣＨＦデータを暗号化することも含むことができる。一実施形態では、暗号化は、第１のエンティティ公開キーを使用することを含む。別の実施形態では、暗号化は、暗号化されたヘッダがプラットフォーム１２によってのみ取得可能であるように、サーバ公開暗号キーを使用してメタヘッダを暗号化することを含む。別の実施形態では、暗号化されたメタヘッダは、ＤＬＴ台帳にトランザクションを追加するために使用される。追加されたトランザクションは、コンセンサスを記録するために利用することができる。追加されたトランザクションは、ＣＨＦ文書６６を取得するために使用することができる。別の実施形態では、追加されたトランザクションは、台帳に対してプライベートデータを明らかにしない。

【0066】

次いで、データプラットフォーム１２は、取り込みプロセスを完了し、データストア１８にＣＨＦ文書を記憶させることができる。データプラットフォーム１２は、好ましくはネットワークの範囲を超えて、ＣＨＦ文書の基礎となる投稿文書を破棄するか、又はこれをアーカイブしてもよい。セット内の各データストア１８は、それに割り当てられた１つから多数のエンティティからのデータを収容する。データストアルーティングは、ＲＤＩＤから取得されたプライベートエンティティキーによって決定することができる。上述のように文書リスト７８が修正された場合、修正された文書リスト７８は、データストア１８のｄｌ－ＵＲＩアドレスに記憶される。新しいＣＨＦ文書が作成された場合、文書エントリは、位置＃０において新しい文書リスト７８に追加され、任意の既存のエントリは１つ下の位置に移動することができる。前述のように、ＣＨＦ文書のすべて又は一部はアイコン化ＣＨＦデータとして記憶されてもよく、ＣＨＦデータはストリング値を含む。上記の説明と一致して、アイコン化されたデータは一定の幅を有することができ、アイコン幅は６４ビットであってもよい。

【0067】

次いで、投稿文書のｄｌ－ＵＲＩに関連付けられた文書リスト７８は、ＣＨＦ文書からの情報のサブセットを追加するように好ましく修正される。追加された情報のサブセットは、文書を投稿した第１のエンティティに対応するｄｏｃＩＤ、タイムスタンプ、ソースＩＤを含むことができる。情報のサブセットはアクセシビリティフィールドをさらに含むことができ、アクセシビリティフィールドの値は、第２のエンティティがＣＨＦ文書内のデータをどの程度広く照会させるかを示す、「公開」及び「プライベート」を含む。サブセットは、有効期限及びｔ配列をさらに含むことができる。繰り返し上述されたセキュリティの強調と一致して、一実施形態では、文書リスト７８自体が、上述の技術を使用してサーバ公開暗号キーによって暗号化される。

【0068】

取り込みは、ＣＨＦ文書を複製することと、複製されたＣＨＦデータを少なくとも１つのデータストア１８に記憶させることとをさらに含むことができ、複製されたデータは、複数のデータストア１８に記憶される。別の実施形態では、取り込みは、投稿文書から解析されたＣＨＦデータコンポーネントの一部又はすべてをエンティティ上でシャーディングすることによって決定されたデータベース内にＣＨＦデータを記憶させることを含んでもよい。取り込みステップは、サーバレスプラットフォーム内のエンティティデータに結合された「サーバレス」機能にエンティティごとの記憶（ストレージ）を指示することをさらに含むことができる。サーバレスプラットフォームの一例は、ＡＷＳ Ｌａｍｂｄａである。取り込みは、投稿文書から解析されたＣＨＦデータを複数のデータベースのうちの１つ以上に割り当てることをさらに含むことができ、複数の１つ以上のデータベースは分散型台帳技術（ＤＬＴ）台帳を含む。（１つ又は複数の）特定のデータストア１８の一部又はすべては、同様にＤＬＴ台帳の分散データストアを含むことができる外部バックアップサイトに反映することができる。データストア及び／又は外部バックアップサイトは、分散ストアであってもよく、分散ブロックデータストアであってもよい。

【0069】

解析されたＣＨＦデータ及び／又はＣＨＦ文書の一部又はすべては、複数のネットワークノードにおける処理及び／又は永続化のために、ネットワークプロトコルを通じてネットワークに接続された１つ以上の受信機に送信することができる。したがって、ＣＨＦは、メモリのみの表現として使用することができ、ＣＨＦが永続化される方法で照会されてもよい。任意選択的に、ＰＯＳＴ動作から返されたメタヘッダは、サーバプライベート暗号キーによって暗号化されて返されることが可能であり、したがってデータプラットフォーム１２によってのみ取得可能である。暗号化されたメタヘッダは、分散型台帳技術の当業者によって理解される特徴及び用途を示す図１１に示されるように、投稿によってプライベートデータを台帳に対して明らかにすることなく、コンセンサスの目的でＤＬＴ台帳に文書トランザクションを投稿するために使用することができる。上述のように、メタヘッダは、投稿ＵＲＩパス、記憶時間に関する情報を含むことができる。これはまた、取り込まれた投稿文書のハッシュ、及び必要に応じて他の情報も含むことができる。メタヘッダ情報は、検証のためにサーバ公開暗号キーによって暗号化されたＣＨＦ文書を含む、特別にフォーマットされたＣＨＦ文書に記憶されてもよい。

【0070】

図６に戻ると、ステップ６４は、投稿及び作成動作が成功したか否か、作成時間、取り込み中に作成されたｄｏｃＩＤ、及び／又はｄｏｃＶｅｒｓｉｏｎなど、メタヘッダに収容された情報の一部を含む情報を、文書を投稿した第１のエンティティに返すことができる。ＣＨＦ文書は、第１のエンティティ、並びに投稿ＵＲＩ５４で指定されるドメイン及び下位コンポーネントに不変に関連付けられる。

【0071】

・データの照会
図６は、データベースシステム１０に記憶された第２のエンティティに関する情報の第１のエンティティの照会に関する一般的なステップを示す。図示される実施形態では、ＰＯＳＴコマンドについて上述されたのと同じ検証ステップ５６が、照会を検証すること、具体的には、ＲＤＩＤが有効化否かを判定するためにＵＲＩのＲＤＩＤコンポーネントを参照することによってアクセス特権を検証することに適用される。

【0072】

図７は、プラットフォーム１２が、第２のエンティティ（標的）に関連する文書に関する第１のエンティティ（要求元）によって発行された照会の少なくとも３つのカテゴリ、特定の文書からのデータを要求する直接ｄｏｃＩＤ照会、第２のエンティティとの１つの固有の関係に基づく第１のエンティティにアクセス可能な文書のコレクションにわたるＲＤＩＤ照会、及びこれらのエンティティと第１のエンティティとの間の特定のＲＤＩＤによって管理されてもされなくてもよい多くのエンティティに関連する文書に関する非ＲＤＩＤ照会を処理する実施形態を示す。

【0073】

・ＤｏｃＩＤ照会
照会は、ＨＴＴＰ（Ｓ）ＧＥＴコマンドを介してデータプラットフォーム１２で受信される。図６及び図７を参照すると、第１のエンティティは、第２のエンティティに関連する所望のＣＨＦ文書へのアクセスを得るために、直接ＤｏｃＩＤ照会６８を発行することができる。所望のＣＨＦ文書は、静的データ又はコンピュータ命令又は任意の種類のデータを含むことができる。文書を投稿するプロセスと同様に、照会は、ＵＲＩフォーマットのＨＴＴＰＳプロトコルを介してデータプラットフォーム１２で受信したＨＴＴＰフォーマットのＧＥＴコマンドの形態であってもよい。上述のＰＯＳＴコマンドと同様に、ＧＥＴコマンドは、例えばＴＬＳプロトコルを通じて保護されてもよく、輸送中に暗号化され、及び／又は静止中に暗号化されてもよい。ＰＯＳＴコマンドと同様に、照会コマンドは、第２の認証技術、例えばプラットフォーム暗号化フィールドを有する第２のＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎによって保護され得る。認証技術は、第１のエンティティのエンティティ分散識別子（以下でさらに論じられる）及び／又はＲＤＩＤアクセストークン５０及び／又は照会で使用されているその導関数に基づく認証など、ＯＡｕｔｈ ２．０以上を含むことができる。

【0074】

一実施形態では、データプラットフォーム１２に接続されたサーバは、ＲＥＳＴ ＡＰＩインターフェースであってもよいＡＰＩインターフェースからデータを取得する要求を受信する。取得要求は、ＨＴＴＰＳプロトコルを使用する取得コマンドとしてフォーマットされてもよく、好ましくはドメイン駆動階層フォーマットを使用するＵＲＩとして構造化される。この取得ＵＲＩ７０は、ＲＥＳＴアーキテクチャスタイルにしたがってプラットフォーム１２で受信されてもよく、所望の文書の取得ＵＲＩ７０は階層パスを含んでもよい。図８に示される例に示されるように、取得ＵＲＩ７０の階層パスは、ホスト：ポート、ドメイン、クラス、エンティティタイプ、ＲＤＩＤ、カテゴリ、アスペクト、及び／又はコレクションを含むことができる。直接ＤｏｃＩＤ照会では取得ＵＲＩ要求は、上述のＤｏｃＩＤを含む。取得ＵＲＩのドメイン及び下位コンポーネントの一部又はすべては、ハッシュ又はアイコン化されてもよい。好適な実施形態では、ＤｏｃＩＤはハッシュもアイコン化もされない。

【0075】

上述のように第２のエンティティに関連する文書へのアクセスの第１のエンティティの要求を検証した後、データプラットフォーム１２は、上述のように、ハッシュ演算を実行するか、又は投稿されたときに文書をハッシュするために使用されたのと同じ式を使用して送信された照会パラメータ上にアイコンを生成する。したがって、照会の結果的なハッシュ（又はアイコン）は、ＣＨＦ文書６６に記憶されたキー及び値と同じ「言語」である。

【0076】

図８を参照すると、一実施形態では、プラットフォーム１２は、取得ＵＲＩ７０パスから「文書識別子キー」（ｄｉｄ－ｋｅｙ）７２を導出する。ｄｉｄ－ｋｅｙ７２は、データストア１８に記憶された特定のＣＨＦ文書６６へのパスを確認するために、取得ＵＲＩアドレス７０から導出される。次いで、プラットフォーム１２は、所望のＣＨＦ文書６６に関連付けられたＣＨＦデータをデータストア１８から取得するために、ｄｉｄ－ｋｅｙ７２を使用することができる。

【0077】

直接ＤｏｃＩＤ６８照会は、第１のエンティティへのアクセスを制限する、又は第１のエンティティの照会のパラメータを制限する値を求めてＣＨＦデータｔ配列１０２を検索することを含むことができる。アクセスが許可されていると仮定すると、今説明された解析ステップで生成された第１のエンティティの照会のためのハッシュキー又はハッシュ値を使用して、プラットフォーム１２は、一致するハッシュ又はアイコンを探してｔ配列１０２を検索することができ、見つかった場合には、照会と一致するＣＨＦ結果を組み立てるために、付随する複数のノード１０４をトラバースすることができる。取得ステップは、一致するＣＨＦノードから照会結果を収集することと、ＣＨＦ文書６６に関連する地所を使用して自然キー及び自然値を構造化することと、所望のフォーマットで出力ノードを構築することとをさらに含むことができる。取得ステップは、所望のフォーマットの結果を第１のエンティティに返すことをさらに含むことができる。

【0078】

・ＲＤＩＤ照会
図６及び図９を参照すると、第２のエンティティとの関係を有する第１のエンティティは、「ＲＤＩＤ照会」７４によって第１のエンティティがアクセスを有するその第２のエンティティに関する複数の文書を照会する。上述の直接ＤｏｃＩＤ照会と同様に、プラットフォーム１２は、ＨＴＴＰＳ（又はＨＴＴＰ）ＧＥＴコマンド及び階層「照会ＵＲＩ」７６の形態の第２のエンティティに関連する文書へのアクセスを要求するＲＤＩＤ照会を、第１のエンティティから受信する。一実施形態では、照会ＵＲＩ７６は、ドメイン、クラス、及びＲＤＩＤを含む。別の実施形態では、照会ＵＲＩは、エンティティタイプ、カテゴリ、アスペクト、及びコレクション、又は上記の一部又はすべての組み合わせを含むことができる。照会は、１つ以上の所望のキー（すなわち「タグ」）、及び／又は１つ以上の所望の値、又は所望のキーと所望の値との組み合わせを含むことができる。照会用語は、図６に示されるように、ステップ７７で解析することができる。直接ｄｏｃＩＤ照会６８と同様に、データプラットフォーム１２は、ハッシュ演算を実行するか、又は文書が投稿されたときにＣＨＦデータコンポーネントをハッシュするために使用されたのと同じ式を使用して送信された照会パラメータ上にアイコンを生成することができる。したがって、照会パラメータの結果的なハッシュ（又はアイコン）は、ＣＨＦ文書６６に記憶されたキー及び値と同じ「言語」である。

【0079】

ＲＤＩＤ照会７４を受信すると、データプラットフォーム１２は、指示されたドメイン及び／又はエンティティに関連する文書リスト７８を取得する。文書リスト７８は、照会パラメータを満たすＣＨＦデータを有することができるＲＤＩＤによって示されるように第１のエンティティにアクセス可能なすべての文書のリストである。一実施形態では、プラットフォーム１２が照会ＵＲＩ７６を受信すると、これは照会ＵＲＩ７６のパスから導出される「文書リストキー」（ｄｌ－ｋｅｙ）８０を生成する。このｄｌ－ｋｅｙは、好ましくは、照会ＵＲＩ７６のパスで指定されたドメイン／クラス／コレクション内の文書のリスト（文書リスト７８）に関連付けられたデータストア１８内のｄｌ－ＵＲＩアドレスを含む。ｄｌ－ｋｅｙ８０は、例えば、そのドメインのハッシュに加えて、照会ＵＲＩ７６を含むクラスのハッシュをハッシュ又は結合することによって、照会ＵＲＩ７６のパスから導出することができ、固定幅１２８ビットアイコンであってもよい。ｄｌ－ｋｅｙ８０によって到達されるアドレスは、ＲＤＩＤ照会７４に応答するデータストア１８内の１つ以上の文書のリストを含むことができる。要約すると、データプラットフォーム１２は、ｄｌ－ＵＲＩアドレスからアクセス可能な文書リスト７８を照会ＵＲＩ７６から生成するために、ｄｌ－ｋｅｙ８０を使用することができる。データストア１８に記憶された文書リスト７８は、キー及び値を有するデータを含み、上述のように、メタヘッダ、ｔ配列、及び辞書を含むことができる。一実施形態では、キー及び値はハッシュされ、人間が読み取ることはできない。別の実施形態では、ｄｌ－ｋｅｙ８０は１２８ビットである。別の実施形態では、キー及び値は暗号化される。

【0080】

ＲＤＩＤ照会７４におけるさらなるステップは、文書リスト７８上の最初の文書が当事者による照会を許可するか否か、すなわち、第１のエンティティが課せられた照会の許可を有するか否かを判定することである。この許可チェックは、リストされた文書が第１のエンティティのＲＤＩＤ照会７６にアクセス可能であるか否かを判定するために、文書リスト７８上の文書ごとに繰り返される。第１のエンティティの照会にアクセス可能な各文書について、ステップ８２で、プラットフォーム１２は、照会されたキー及び／又は値（これらのハッシュされたバージョン）を、文書リスト７８上の各アクセス可能文書に付随するｔ配列に収容されたキー及び値と比較する。図示される実施形態では、照会されたキー及び／又は照会された値がｔ配列内にある場合、プラットフォーム１２は、ステップ８４で一致及びインデックス位置を判定するためにインデックスノードをトラバースし、次いで、（１つ又は複数の）応答ＣＨＦ文書６６を使用して照会に対する完全な応答を組み立て、次いで、照会応答を完了するために、ステップ８５で結果文書を第１のエンティティに返す。

【0081】

・非ＲＤＩＤ照会
時々、第１のエンティティは、ひょっとすると関係のあるものを含み、ひょっとするといくつかは関係のない、複数のエンティティにわたって照会することを望む場合がある。あるいは、ことによると、第１のエンティティは、すべての関係者との関係を有するが、個々のＲＤＩＤに対して難解も繰り返すのではなく１回だけ照会を走らせることを好む。このような照会は、非ＲＤＩＤ照会８６である。図７に示されるように、非ＲＤＩＤ照会８６は、ＲＤＩＤ照会７４及び直接ＤｏｃＩＤ照会６８と同じ原理、並びに同じステップ及び特徴の多くを含む。照会は、第２のエンティティとの登録された関係を有していないエンティティに到達する可能性があるため、非ＲＤＩＤ照会８６は、上述の照会よりも複雑である。それでもなお、登録された関係を有していないこれらのエンティティは、第２のエンティティによる照会を許可するプライバシー規則を有する可能性がある。

【0082】

解決策の一実施形態が図１０に示されている。データプラットフォーム１２は、任意の数のエンティティに関連する文書へのアクセスを要求するクエリを第１のエンティティから受信する。照会は、ＨＴＴＰＳ ＧＥＴコマンド及び階層照会ＵＲＩ７６を含むことができる。照会ＵＲＩ７６は、ドメイン、クラス、エンティティタイプ、アスペクト、コレクション、カテゴリ、及び上記の一部又はすべての組み合わせを含むことができる。別の実施形態では、照会ＵＲＩ７６は、１つ以上の所望のキー、及び／又は１つ以上の所望の値を含むことができ、又は所望のタグと所望の値との組み合わせを含むことができる。図１０に示される実施形態では、照会ＵＲＩ７６はＲＤＩＤコンポーネントを含まない。ＲＤＩＤ照会と同様に、ステップ７７で照会用語が解析され、データプラットフォーム１２は、ハッシュ演算を実行するか、又は文書が投稿されたときにＣＨＦデータコンポーネントをハッシュするために使用されたのと同じ式を使用して送信された照会パラメータ上にアイコンを生成することができる。したがって、照会パラメータの結果的なハッシュ（又はアイコン）は、ＣＨＦ文書６６に記憶されたキー及び値と同じ「言語」である。

【0083】

プラットフォーム１２は、照会ＵＲＩ７６のパスから導出された「エンティティリストキー」（ｅｌ－ｋｅｙ）８８を生成し、ｅｌ－ｋｅｙ８８は、照会ＵＲＩ７６で指定されたドメイン／クラス／コレクションへのアクセスを有するエンティティのリストに関連付けられたデータストア１８内のｅｌ－ＵＲＩアドレスに対応する。Ｅｌ－ｋｅｙ８８は、クラス及びコレクションなど、照会ＵＲＩ７６内のコンポーネントから導出されたハッシュ又はアイコンであってもよい。Ｅｌ－ｋｅｙ８８は、照会ＵＲＩ７６のパスに含まれてデータストア１８に記憶されたＣＨＦ文書６６を有するエンティティを含む、データストア１８に記憶されたエンティティのリスト９０へのキーである。好適な実施形態では、エンティティリスト９０内のキーも値も人間が読み取ることはできない。別の実施形態では、エンティティリスト９０内のキー及び値はハッシュされる。ハッシュは１２８ビットであってもよい。エンティティリスト９０のキー及び値もまた暗号化され得る。

【0084】

次のステップで、データプラットフォーム１２は、照会ＵＲＩ７６のパスで指定されたドメイン／クラス／コレクションから導出されたｅｌ－ｋｅｙ８８を使用してエンティティリスト９０を取得することができる。次いで、プラットフォーム１２は、エンティティリスト９０に記憶された値から、エンティティリスト９０とともに記憶された、各リストされたエンティティの内部エンティティキーを導出することができる。次いで、内部エンティティキーごとに、プラットフォーム１２は、各エンティティの内部エンティティキーの導出を照会ＵＲＩパスと組み合わせることによって、エンティティリスト９０上の各エンティティについて文書キー（ｄｌ－ｋｅｙ）８０を生成することができる。この結果、エンティティごとに１つのｄｌ－ｋｅｙ８０が、投稿ＵＲＩパスで指定されたドメイン／クラス／エンティティタイプ／コレクション内の文書のリストに関連付けられたデータストア１８内のｄｌ－ＵＲＩアドレスに対応することになる。言い換えると、エンティティリスト９０のすべてのエンティティのために生成された異なるｄｌ－ｋｅｙ８０が存在することになる。エンティティリスト９０の各エンティティについて、非ＲＤＩＤ ＵＲＩ８６を満たす文書リスト７８を取得するために、ｄｌ－ｋｅｙ８０が作成される。以前と同様に、ｅｌ－ｋｅｙ８８及びｄｌ－ｋｅｙ８０は１２８ビットであってもよい。

【0085】

ｄｌ－ｋｅｙ８０を使用して、プラットフォーム１２は、エンティティごとに１つ以上の文書リスト７８にアクセスすることができる。データストア１８に記憶された文書リスト７８は、キー及び値で構成される。好適な実施形態では、キーも値も人間が読み取ることはできず、むしろハッシュされる。別の実施形態では、キー及び値は１２８ビットである。別の実施形態では、キー及び値は暗号化される。このプロセスを使用して取得された文書リスト７８上のすべての文書の組み合わせは、候補文書リストを含むことができる。

【0086】

一実施形態では、候補文書リストは、上記の投稿セクションで説明されたＣＨＦ情報のサブセットを含む。文書リスト７８に列挙されたＣＨＦ文書６６ごとに、各候補は、そのＣＨＦ文書のｄｏｃＩＤ、そのタイムスタンプ、そのソースＩＤ、そのアクセス可能性、その有効期限、及びそのｔ配列を含むことができる。

【0087】

残りの非ＲＤＩＤ照会８６ステップは、上述のＲＤＩＤ照会７４ステップと同様である。簡潔には、一実施形態において、データプラットフォーム１２は、候補文書リスト７８を調べることによって、最初の候補文書が第１のエンティティによる照会を許可するか否かを判定する。このステップは、候補文書リスト上の各文書が第１のエンティティの照会にアクセス可能であるか否かを判定するために、候補文書ごとに繰り返される。ステップにおいてハッシュされた照会用語（投稿文書から解析された情報をハッシュするために使用されたプロセスと同一のプロセスを使用してハッシュする）を使用して、プラットフォーム１２は、照会されたキー及び／又は値（ハッシュされたバージョン）を、文書リスト７８に現れる各アクセス可能文書に付随するｔ配列に収容されたキー及び値と比較する。図１０に示される実施形態では、照会されたキー及び／又は照会された値がｔ配列内にある場合、プラットフォーム１２は、ステップ８４で一致及びインデックス位置を判定するためにインデックスノードをトラバースし、次いで、（１つ又は複数の）応答ＣＨＦ文書６６を使用して照会に対する完全な応答を組み立て、次いで、非ＲＤＩＤ照会応答を完了するために、ステップ８５で結果文書を第１のエンティティに返す。

【0088】

したがって、記載された実施形態では、プラットフォーム１２はスキーマに依存しない。照会を実行するために必要とされる「先験的な」データインデックス定義はない。

【0089】

・プラットフォーム上の登録：ＥＤＩＤ及びＲＤＩＤの生成
上記の説明は、エンティティ中心のドメイン分割可能な管理者制御データプラットフォーム１２を詳述している。上記の実施形態では、データの投稿、照会、及び取得は、データベースシステム１０によって生成される一意（ユニーク、ｕｎｉｑｕｅ）の一方向性（一方向、ｕｎｉｄｉｒｅｃｔｉｏｎａｌ）の関係分散識別子（ＲＤＩＤ）に結合される。システムに記憶されたデータは、行及び表を含むリレーショナルデータベース表に集中しておらず、すべてのデータが多くの一意のＲＤＩＤに結合されるので、極端に分散されている。

【0090】

先に論じられたように、データベースシステム１０を含む１つ以上のサーバは、サーバ公開暗号キー及びサーバプライベート暗号キーを受信することができる。一実施形態では、データプラットフォーム１２は、少なくとも部分的にサーバ公開暗号キーに基づいて、システム秘密アイコンを生成することができる。これは、システムにのみ知られている値を有する秘密アイコンである。

【0091】

プラットフォーム１２へのアクセスは、事前登録及び適切な資格情報を必要とする。第１のエンティティを登録するために、プラットフォーム１２は、プラットフォームに登録する要求を受信する。エンティティは、エンティティ名及び電子メールアドレスなどの識別情報、並びにエンティティの登録を許可するためにエンティティに提供されるパスコードを提供する。一実施形態では、パスコードを検証した後、プラットフォーム１２は、エンティティのためのプライベートｐａｓｓＣｏｄｅを生成し、エンティティにプライベートｐａｓｓＣｏｄｅを提供する。一実施形態では、パスコードは不変であり、システム管理者以外によって変更することはできない。

【0092】

プラットフォーム１２は、エンティティのためのエンティティ分散識別子（ＥＤ ＩＤ）を生成する。ＥＤＩＤ生成ステップは、どのエンティティが任意の所与のＥＤＩＤによって表されるかを任意の人物又はコンピュータがリバースエンジニアリングすることを実質的に不可能にするための一連のステップを含むことができる。ＥＤＩＤ生成ステップは、例えば、少なくとも部分的に第１の識別情報に基づいて第１のアイコンを生成することを含むことができ、表とともに実装された線形フィードバックシフトレジスタなどの変換方式を使用して追加のアイコンを生成することをさらに含むことができ、システム秘密アイコンであってもよいシステムアイコンと第１のアイコンをアルゴリズム的に組み合わせることをさらに含むことができ、ハッシュを組み合わせるためにバイトバッファを使用することをさらに含むことができ、後にＥＤＩＤとして機能するために任意の数の導関数アイコンを生成することをさらに含むことができる。一実施形態では、ＥＤＩＤは、ＡＳＣＩＩ文字を含み得る、固定幅１２８ビットアイコンである。ＥＤＩＤは、アプリケーションに応じてエンティティに提供されてもされなくてもよい。一実施形態では、プラットフォーム１２は、サーバ公開暗号キーを使用してエンティティＥＤＩＤを暗号化し、その後、エンティティ資格情報の一意のセットをデータストア１８に記憶させる。エンティティがデータプラットフォーム１２にアクセスすることを望むときに使用される資格情報は、少なくとも部分的に第１のエンティティＥＤＩＤから導出することができる。登録のプロセスでは、エンティティには、エンティティ公開キー及びエンティティプライベートキーを含む暗号キーペアも提供される。登録中、プラットフォーム１２はまた、システム管理者、ドメイン管理者、開発者、コホート、又はグループメンバーなど、第１のエンティティの役割を記録することもできる。プラットフォーム１２は、グループ内のエンティティのメンバーシップを記録してもよい。

【0093】

ＲＤＩＤを生成するために、プラットフォーム１２は、最初に、第２のエンティティとの関係を確立する要求を第１のエンティティから受信する。要求された関係は、第１のエンティティを要求元として分類し、第２のエンティティを標的として分類することなどの関係パラメータを含むことができる。関係パラメータは、第１のエンティティが第２のエンティティに関連する文書を投稿すること、及び／又は第２のエンティティに関連する文書を照会することなどを可能にする。関係の失効などの他の関係パラメータ、並びに役割、グループなどの他のアクセス制御パラメータも同様に定義することができる。

【0094】

一実施形態では、ＲＤＩＤは、第１のエンティティ及び第２のエンティティの値を符号化することに基づく。ＥＤＩＤ生成ステップと同様に、ＲＤＩＤ生成ステップは、第１の識別情報、第２の識別情報、システムアイコン、複数の２つ以上のアイコンを保持するバイトバッファの利用、第１のエンティティ及び／又は第２のエンティティのプライベートパスコード、及び／又はシステム秘密アイコンに少なくとも部分的に基づいて一連のアイコンを生成することを含むことができる。プラットフォームがＲＤＩＤを生成した後、プラットフォームは、例えばサーバ公開暗号キーを使用してこれを暗号化することができる。ＲＤＩＤによって証明される関係を作成するための承認は、第２のエンティティによる認可に続く一連のステップによって導出される。認可は明示的であってもよく、例えば、それによって第２のエンティティが、関係要求のプラットフォームからの通知並びに第２のエンティティが認可又は拒否できる第２のエンティティの特定のデータにアクセスしたいというその希望を受信する通知及びコールバック方法、投稿時にＣＨＦ文書６６に埋め込まれたアクセス特権などである。あるいは、認可は暗黙的であってもよく、例えば第１のエンティティの役割及び／又はグループメンバーシップに基づく事前認可を含む、第２のエンティティの登録時に与えられる事前承認などである。プラットフォームは、エンティティ及びそれらの関係パラメータを決定した後にそれを受信したときにプラットフォーム１２が分解（デコンストラクト）することができるＲＤＩＤアクセストークン５０を第１のエンティティに発行する。一実施形態では、ＲＤＩＤアクセストークン５０は、ＡＳＣＩＩ文字を含む１２８ビットの固定幅を有するベース６２内の固定長アイコンである。次いで、プラットフォーム１２は、プラットフォーム上で第１のＲＤＩＤを登録し、ＲＤＩＤをデータストア１８内の要求された関係パラメータに関連付けることができる。

【0095】

データベースシステム１０の利点は、単に対象のＲＤＩＤをシステムから削除することによって、いつでもエンティティによって関係を取り消すことができることである。データはエンティティに結合されているので、エンティティのデータがどこに記憶されているかを分析する必要はなく、あるいは無数のファイルを移動又は削除する必要もない。データがどこに記憶されていても、そのＲＤＩＤを通じてアクセスすることはできなくなる。この能力は、例えばＧＤＰＲの「忘れられる権利」規制に準拠するための実質的な節約を潜在的に表す。

【0096】

・安全な遠隔処理
別の態様では、本発明は、安全なアプリケーションをリモートワークに拡張するための信頼できるプラットフォームを開発するためのフレームワークを提示する。図１４に示される一実施形態では、リモートワーカは、上述の安全なデータ機能を関係に結合された透明性と組み合わせることによって、安全なアプリケーションに安全にアクセスすることができる。本発明の信頼できるデータプラットフォーム１２及びストア１８を使用して、リモートユーザは、安全なアプリケーションプラットフォームインターフェースに照会し、次いで暗号化されたデータの応答として照会の結果を受信することができる。一実施形態では、暗号化は、プラットフォームに登録されたエンティティに割り当てられた暗号キーペアに基づく。この暗号化ペアを使用して、そのリモートワーカのみが応答を復号することができる。別の実施形態では、安全なＧｏ言語に、すなわち、発明の技術を使用してリモートワーカのブラウザに結果を安全に提示する記述されたウェブサーバに返される。別の実施形態では、ローカルの安全なウェブサーバからブラウザによって受信されるまで、すべてのデータが暗号化される。

【0097】

別の実施形態では、応答データのすべての表示は、Ｊａｖａｓｃｒｉｐｔの関与なしにブラウザＨＴＭＬで管理される。これにより、安全なアプリケーションの主な弱みである、ウェブアプリケーションで通常使用されるＪａｖａｓｃｒｉｐｔを不要にするか又は排除する。ユーザによる応答（入力）は、好ましくはプラットフォームのユーザ暗号キーペアで暗号化される。この暗号化された応答は、安全なウェブサーバによって、アプリケーション処理のためにアプリケーション照会及び更新インターフェースに送信され得る。アプリケーションインターフェースは、アプリケーションのＪＳＯＮフォーマットされた応答をもたらす安全なアプリケーションへのＥＴＬ（Ｅｘｔｒａｃｔ－Ｔｒａｎｓｆｏｒｍ－Ｌｏａｄ）タイプの呼び出しを含むことができる。別の実施形態では、アプリケーションインターフェースは、リモートワーカの照会を、プラットフォーム自体にではなく処理のためのアプリケーションに提示することができる。処理のこの時点まで、すべてのデータが暗号化され得る。アプリケーションインターフェースからのデータは、任意の照会の結果をキャッシュするように、データベースシステム１０データストア１８に記憶され得る。

【0098】

上記の発明は、関連する法的基準にしたがって記載されており、したがって本説明は、本質的に限定的ではなく例示的である。開示された実施形態に対する変形例及び修正例は、当業者にとって明らかとなり、本発明の範囲に含まれる。

【先行技術文献】

【特許文献】

【0099】

【特許文献1】米国特許第８，７９３，７６８号明細書

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【国際調査報告】