特表 2023-502757 データセットネットワーク作成システム

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

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

(11)【公表番号】

(43)【公表日】2023-01-25

(54)【発明の名称】データセットネットワーク作成システム

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230118BHJP

   G06F 16/27 20190101ALI20230118BHJP

【ＦＩ】

G06F21/62 318

G06F16/27

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022529877

(86)(22)【出願日】2020-11-23

(85)【翻訳文提出日】2022-07-20

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

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

(87)【国際公開日】2021-05-27

(31)【優先権主張番号】62/939,504

(32)【優先日】2019-11-22

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

(31)【優先権主張番号】62/939,515

(32)【優先日】2019-11-22

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】522201624

【氏名又は名称】シンチー インク．

(74)【代理人】

【識別番号】100179970

【弁理士】

【氏名又は名称】桐山 大

(74)【代理人】

【識別番号】100071205

【弁理士】

【氏名又は名称】野本 陽一

(72)【発明者】

【氏名】カランジョ・シン

(72)【発明者】

【氏名】ダニエル・デマーズ

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175AA01

5B175BA01

(57)【要約】

以下は、データノードの共有ネットワークを作成するためのプラットフォームを提供する。各データノードは、自己記述型、自己接続型、及び自己保護型である。本明細書において教示されるデータネットワークはデータサイロ環境を防止することができる。各ノードは、バージョン管理されたデータを含むデータセットと、データセットへのユーザアクセスを制限するアクセス制御レイヤと、データセットの特徴を定義すると共に別のノードに接続するメタデータレイヤとを有する。データセットにおける変更がデータノードのネットワークにおける変更に影響を及ぼすように、データノードのネットワークを作成するべくノードを後続のノードと関連付けるために１つ以上のリンクが作成され、データノードのネットワークは、データセット及び後続のデータセットと情報をやりとりするためのクエリレイヤを備える。
【選択図】 図６

【特許請求の範囲】

【請求項1】

データノードのネットワークを作成するシステムであって、
データを含む第１のデータセットと、
前記第１のデータセットへのユーザアクセスを制限するアクセス制御レイヤと、
前記第１のデータセットの特徴を定義し、少なくとも１つの後続のノードに接続するメタデータレイヤと、
を有する第１のノードを備え、
前記後続のノードは、
更なるデータを含む後続のデータセットと、
前記第２のデータセットへのユーザアクセスを制限する後続のアクセス制御レイヤと、
前記後続のデータセットの特徴を定義するメタデータレイヤと、
を有し、
前記データノードのネットワークを作成するべく、前記第１のノードを前記後続のノードと関連付ける１つ以上のリンクが作成され、
前記データノードのネットワークは、前記第１のデータセット及び少なくとも１つの後続のデータセットと情報をやりとりするためのクエリレイヤを備え、
複数のアプリケーションが前記クエリレイヤを通じて前記ネットワーク内の前記データ及び前記更なるデータにアクセスする、
システム。

【請求項2】

前記内蔵されたデータセキュリティのレイヤは、前記データが前記ユーザに与えられる特定のレベルのエンタイトルメントを指定するために用いられるように、データレベルエンタイトルメントを備える、請求項１のシステム。

【請求項3】

前記データと直接的に情報をやりとりするためのユーザフレンドリなインターフェイスを更に備える、請求項２のシステム。

【請求項4】

レガシーデータを前記データセットのネットワークにリンクさせるための１つ以上のコネクタを更に備える、請求項２のシステム。

【請求項5】

前記クエリインターフェイスは、メタデータ駆動ＡＰＩ及びメタデータ駆動ＵＩを介して前記データセットのネットワークと情報をやりとりする、請求項１のシステム。

【請求項6】

前記データのソースの自動データバージョン管理を行うように構成され、前記ユーザは前記データセットのネットワークの前のバージョンにロールバックする能力を有する、請求項１のシステム。

【請求項7】

前記データ及び前記更なるデータはバージョン管理される、請求項１のシステム。

【請求項8】

前記内蔵されたデータ制御のレイヤは、前記データのソースにおいて、ＡＰＩ及びＵＩが前記内蔵されたデータ制御を自動的に順守することを強制されるように定義される、請求項１のシステム。

【請求項9】

前記データノードのネットワークは、スーパーネットワークを作成するために少なくとも１つの他のデータノードのネットワークに接続され得る、請求項１のシステム。

【請求項10】

データノードのネットワークを作成する方法であって、
データを含む第１のデータセットと、
前記第１のデータセットへのユーザアクセスを制限するアクセス制御レイヤと、
前記第１のデータセットの特徴を定義するメタデータレイヤと、
を有する第１のノードを提供することと、
前記第１のノードを、
更なるデータを含む後続のデータセットと、
前記第２のデータセットへのユーザアクセスを制限する後続のアクセス制御レイヤと、
前記後続のデータセットの特徴を定義するメタデータレイヤと、
を有する少なくとも１つの後続のノードに接続することと、
前記第１のデータセット及び少なくとも１つの後続のデータセットと情報をやりとりするためのクエリレイヤを提供することと、
前記クエリレイヤを通じて前記ネットワーク内の前記データ及び前記更なるデータにアクセスすることと、
を備え、
前記第１のデータセットにおける変更が前記データノードのネットワークにおける変更に影響を及ぼすように前記データノードのネットワークを作成するべく、前記第１のノードを前記後続のノードと関連付ける１つ以上のリンクが作成される、
方法。

【請求項11】

前記内蔵されたデータセキュリティのレイヤは、前記データが前記ユーザに与えられる特定のレベルのエンタイトルメントを指定するために用いられるように、データレベルエンタイトルメントを備える、請求項１０の方法。

【請求項12】

前記データ及び前記更なるデータはバージョン管理される、請求項１１の方法。

【請求項13】

レガシーデータを前記データセットのネットワークにリンクさせるための１つ以上のコネクタを更に備える、請求項１１の方法。

【請求項14】

前記クエリインターフェイスは、メタデータ駆動ＡＰＩ及びメタデータ駆動ＵＩを介して前記データセットのネットワークと情報をやりとりする、請求項１０の方法。

【請求項15】

前記データのソースの自動データバージョン管理を行うように構成され、前記ユーザは前記データセットのネットワークの前のバージョンにロールバックする能力を有する、請求項１０の方法。

【請求項16】

無承認の変更を追跡するための第１のテーブル及び承認された変更を管理する第２のテーブルを備える２テーブルアーキテクチャを備える請求項１０の方法。

【請求項17】

前記内蔵されたデータ制御のレイヤは、前記データのソースにおいて、ＡＰＩ及びＵＩが前記内蔵されたデータ制御を自動的に順守することを強制されるように定義される、請求項１０の方法。

【請求項18】

前記データノードのネットワークは、スーパーネットワークを作成するために少なくとも１つの他のデータノードのネットワークに接続され得る、請求項１０の方法。

【発明の詳細な説明】

【技術分野】

【0001】

以下は、データファブリックのようなデータセットのネットワーク、そのようなネットワークを提供するためのプラットフォーム、並びにそのネットワーク、データセット、及びシステムを構築並びに使用する方法に関する。

【背景技術】

【0002】

従来、エンタープライズ（大企業、中堅企業、公官庁などの比較的規模の大きな法人を意味する）は、データサイロ環境で活動してきた。データサイロとは、例えば、１つのアプリケーションを通じてアクセス可能であるがその組織の残りからは隔離されている一群のデータセットである。データサイロは、通常は、データが解析ツールによって収集されること又はデータが業務アプリケーションによって生成されることの結果である。データサイロ環境には多くの欠点がある。

【0003】

例えば、データサイロは、組織内における大量の無駄時間をもたらすことがある。アプリケーション間でデータを自動的に効率化することができず、データが各アプリケーション内で隔離される。これは、あるチームが、自分たちの持っていないデータが必要であることを認識し、そのデータが組織内のどこにあるのかを見つけ、手動でそのデータにアクセスし、それから自分たちの目的のためにそのデータを解析するまで待たなければならないであろうことを意味する。データは、収集するまでに、もはや有効ではなくなっているかもしれない。

【0004】

データサイロは、記憶域スペースの無駄ももたらすことがある。例えば、組織の各被雇用者がデータのコピーを必要とし、それを自分たちの会社の記憶フォルダに保存する場合、大量の記憶域スペースを無駄にすることになり、非常にコストがかかり得る。

【0005】

データサイロ環境のもう１つの欠点は、データの正確性を維持できないという点である。隔離されたデータは、放置されるにつれて古くなり、よって不正確になり、使用に適さなくなる可能性が高い。

【0006】

データサイロはセキュリティの脆弱性も作り出すことがある。例えば、データが一旦コピーされると、データセットの所有者はもはやその機密性を、他のチームからの承諾に依存する困難でコストのかかるプロセスなしには担保することができない。データセットのコピーが各チームメイトのコンピュータ上に記憶されれば、よりハッキングされやすくなり得る可能性がある。

【0007】

データサイロは組織内の摩擦も生み出す。なぜなら、データサイロ環境においては、各チームが自分たち自身のデータにしかアクセスを有さず、したがってそれが自分たちの扱う唯一のデータであるからである。例えば、各チームは、協働してではなく独立して働き、分断された組織を作り出すことがある。

【0008】

図１及び図２は、新たなデータサイロ２４及びデータの複製２６の作成を伴う、従来の新たな各カスタムアプリケーションの作成を示す。図１に示されるように、従来開発されるアプリケーション１０は、各々が独自のユーザインターフェイス１４と、ＡＰＩ１５（図１には図示しない）と、セキュリティ及び制御機能１６と、データ統合機能１８と、データ永続化機能２０と、データ公開機能２２とを含むようにプログラムされるであろう。

【0009】

また、各アプリケーション１０は独自のデータベース２４を必要とし、リンクされた又は関係するデータ２６がそのデータベース２４において作成、インポート、更新、維持などをされる。エンタープライズのレガシーデータ２８も、各アプリケーション１０に別途インポートされることが必要であろう。ユーザ１２は、別々のセキュリティ及び制御１６を用いて各アプリケーション１０へのアクセスを許可されるであろう。データはその後、例えば分析及び他のデータ処理動作を行うために、より大きなエンタープライズデータレイク３０に公開され得る。これらのアプリケーション１０はデスクトップツールにも大きく依存するかもしれず、新たなソリューションを効果的に配備するのに必要なこれらのツールの数百又は数千のインスタンスさえ必要とする。さらに、従来のデータサイロではデータ管理がしばしば不足していることがわかっており、あるアプリケーション又はデータサイロにおいて実装される管理は、別のアプリケーション又はデータサイロにおいては再利用可能でないことが多い。

【0010】

こうした非効率性及び冗長性に起因して、新たなアプリケーション１０及びソリューションを作成するには何週間もかかることが多く、配備するのに数か月かかることは更に多い。これらのソリューションが速やかに必要とされる環境においては、配備のための時間は、競争上の欠点、又は控えめに言っても資源の浪費と考えられ得る。

【発明の概要】

【0011】

一態様は、データノードの共有ネットワークを作成するシステムに関する。システムは少なくとも２つのノードを備え、各ノードはバージョン管理されたデータを含むデータセットと、データセットへのユーザアクセスを制限するアクセス制御レイヤと、データセットの特徴を定義し、別のノードに接続するメタデータレイヤとを有する。データセットにおける変更がデータノードのネットワークにおける変更に影響を及ぼすようにデータノードのネットワークを作成するべく、ノードを後続のノードと関連付ける１つ以上のリンクが作成され、データノードのネットワークは、データセット及び後続のデータセットと情報をやりとりするためのクエリレイヤを備える。各データノードは、自己記述型、自己接続型、及び自己保護型である。

【図面の簡単な説明】

【0012】

次に、実施形態を、添付の図面を参照して説明する。

【0013】

【図1】データサイロ環境における従来技術によるアプリケーション開発を示す模式図である。

【図2】データサイロ環境における従来技術によるアプリケーション開発を示す模式図である。

【図3】４つのアプリエクスペリエンスと共に示されるデータノードのネットワークの模式図である。

【図4】５つのアプリエクスペリエンスと共に示されるデータノードのネットワークの模式図である。

【図5】ノードの模式図である。

【図6】ノードのネットワークの模式図である。

【図7A】データセットノードの構築、データセットノードのネットワークの構築のため、及びそのようなネットワークと情報をやりとりするためのプラットフォームの模式図である。

【図7B】データセットノードのネットワークのネットワークの構築のため及びそのようなネットワークと情報をやりとりするためのプラットフォームの模式図である。

【図8a】ノード及びそのデータのスクリーンショットの一例である。

【図8b】データセットのデザインの一例を示すスクリーンショットの一例であり、そのノードのメタデータの定義を含む。

【図8c】現在のデータセットと別のデータセットとのリンクを定義するスクリーンショットの一例である。

【図8d】データのバージョンを表示するコラボレーションログのスクリーンショットの一例である。

【図8e】個々のノードに対する制御を構成するために用いられ得る制御ページのスクリーンショットの一例である。

【図9】スクリプト言語クエリの実行を示す概略フロー図である。

【図10】データネットワーク例と情報をやりとりするときの異なるユーザの視点を示す模式図である。

【図11】バージョン付きデータのスクリーンショットの一例である。

【図12】独立したアクセス制御許可を示すデータセットの一例である。

【図13a】第１の時刻のデータセットネットワークの一例である。

【図13b】第２の時刻のデータセットネットワークの一例である。

【図13c】第３の時刻のデータセットネットワークの一例である。

【図14】データサイロ環境における従来のアプリケーション開発を示す模式図である。

【図15】従来のアプリケーション対データセットネットワークエクスペリエンスの概略図である。

【図16A】サイロ化されたデータベースを用いる従来のアプリケーション開発のセキュリティ及び制御を示す概略図である。

【図16B】データネットワークを活用するアプリケーション開発を示す概略図である。

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

【0014】

以下は、データノードの共有ネットワークを作成するためのプラットフォームを提供する。各データノードは、自己記述型、自己接続型、及び自己保護型である。本明細書において教示されるデータネットワークは、大規模な（例えばエンタープライズレベルの）データ管理ソリューションを構築するのに必要な時間及び労力を低減することができる。いくつかの利点として、データサイロ環境の予防、適合可能なアプリケーションプログラミングインターフェイス（ＡＰＩ）統合レイヤを通じた柔軟なエンタープライズアラインメント、及びアプリケーション間でのデータの再利用に基づく最小の労力での単純化されたデータ統合を含み、従来の意味での「アプリケーション」を開発する必要を効果的に低減又は無くす。各ノードは、バージョン管理されたデータを含むデータセットと、データセットへのユーザアクセスを制限するアクセス制御レイヤと、データセットの特徴を定義すると共に別のノードに接続するメタデータレイヤとを有する。データセットにおける変更がデータノードのネットワークにおける変更に影響を及ぼすように、データノードのネットワークを作成するべくノードを後続のノードと関連付けるために、１つ以上のリンクが作成され、データノードのネットワークは、データセット及び後続のデータセットと情報をやりとりするためのクエリレイヤを備える。

【0015】

後述するように、このシステムは従来の意味でのアプリケーション開発の必要を事実上無くし、よって、データコラボレーションネットワーク及びそのネットワークの個々のデータノードは、データへのアクセスを有するエンティティが従来のアプリケーション開発及びデータサイロ作成に関連する有意な労力を必要とせずに同じデータを利用できるようにすることによって、アプリケーションの必要を無くす。したがって、システムは、各ソリューション又はアプリケーションについて１回限りのコードを書くのではなく、データをＵＩから分離すること及びデータの周辺のセキュリティ及び制御レイヤの構成を可能にすることによって、ソリューションのより迅速なデリバリを可能にする。また、別々の組織内のデータコラボレーションネットワークが互いにリンクされてネットワークのネットワークを作成してもよく、隔離されたデータサイロではなく、リンクされたデータのスーパーネットワークを作り出す。

【0016】

図２は、新たなデータベース２４及びデータの複製２６の作成を伴う新たなカスタムアプリケーションの各々の従来の作成を示す。従来開発されたアプリケーション１０の各々は自己のデータベース２４を必要とし、リンクされた又は関係するデータ２６がそのデータベース２４において作成、インポート、更新、維持などをされるであろう。データベース２４の各々は、アプリケーション１０によってアクセスされるデータ２６のコピーを記憶する。従来のアプリケーションはデータセットを埋め込まれている。従来、データは、個々のアプリケーション１０の裏でデータサイロ２４にデータのコピーとして記憶される。これが不利益になり得るデータサイロのような環境を生じさせる。

【0017】

図３は、データノードのネットワークの模式図を示す。データネットワーク３４は、個々のノード３６を、データノードのネットワーク３４を形成するように接続することによって作成される。生データ又はデータのレコード３５はクエリインターフェイス３３を介してアクセス可能であり、これはデータノードのネットワーク３４に接続する。例えば、図３は、いずれも同じデータネットワークからのデータを用いる４つの異なるアプリケーションエクスペリエンス３２ａ，３２ｂ，３２ｃ，及び３２ｄを示す。これは、別々のデータベースを作成し、インポートし、更新し、維持する必要を無くすだけでなく、各アプリケーションのセキュリティ及び制御システム１６、データ統合システム１８、データ永続化システム２０、及びデータ公開システム２２を管理する必要も無くす。

【0018】

よって、新たなアプリケーションエクスペリエンス３２を追加することは比較的容易である。図４は、図３に示される既存のアーキテクチャに新たなアプリケーションエクスペリエンス３２ｅが追加されているところを示す。新たなアプリケーションエクスペリエンス３２ｅの追加は、追加的なセキュリティ及び制御機能１６、データ統合機能１８、データ永続化機能２０、及びデータ公開機能２２を必要としない。アプリケーションエクスペリエンス３２は、データと情報をやりとりするためのカスタムユーザインタフェースとして作用する。

【0019】

したがって、任意の数のノード３６並びにアプリケーションエクスペリエンス３２がネットワーク３４に追加され得ることが理解されるであろう。より新しいアプリケーションエクスペリエンス３２が追加されるにつれて、データセットのネットワーク３４は成長し、新たなデータセット２６の間により新しいリンクが形成される。

【0020】

データセットノード、データノードのネットワーク、及びプラットフォーム実装

【0021】

次に図５及び図６について見ると、本明細書に記載されるプラットフォームはデータ３５をデータノードのネットワーク３４として管理するように構成されている。図５はデータセットノード３６の一例を示し、図６はノード３６のネットワーク３４の一例を示す。各データセット２６はデータ３５を備える。データセットはバージョン管理３８され、第１のバージョン３５ａ、第２のバージョン３５ｂ、及び第３のバージョン３５ｃのようなデータのバージョンを含む。任意の数のバージョンが可能であることは理解されるであろう。データセット２６の上にはアクセス制御レイヤ３９が構築される。アクセス制御レイヤ３９の上にはメタデータレイヤ３７が構築される。図５に示される単一のノード３６に見られるように、ノードのコアにはデータ３５のレコードがある。データ３５のレコードは、まずメタデータレイヤ３７及びアクセス制御レイヤ３９を通り抜けることなしにはアクセスされ得ない。ノード３６は、ノード３７を自己記述型及び自己接続型にするメタデータレイヤ３７を備える。したがって、各データセット２６は独自のメタデータレイヤ３７を備えており、そのメタデータレイヤは、現在のノードの任意のレコードを他のノードの１つ以上のレコードと関係付けるデータと併せて、特性及び他のノードとの関係（すなわちリンク）に関する情報など、データセットについての情報を含む。

【0022】

ノード３６は、データの保全性を保証するため、並びにデータバージョン管理３８及び変更承認などのガバナンス管理を提供するための内蔵された制御レイヤ３９を有することによって、自己制御型であり得る。データバージョン管理３８は図１１に示されており、以下で更に詳述される。ノード３６が自己保護型であり得るとは、そのノードがエンタイトルメントを管理するための内蔵されたセキュリティレイヤを有することを意味する。ノードは、プラットフォームのメタデータ駆動ユーザインターフェイス又はＡＰＩのいずれを通じてもアクセス可能である。

【0023】

典型的には、データのセキュリティ及び制御１６は、図１の従来技術例に示される個々のアプリケーション１０に存在していた。これは危険であり得る。なぜなら、セキュリティ及び制御は個々のアプリケーションにリンクされており、したがってデータがコピーされるときにデータを追跡しないであろうからである。したがって、データはコピーされると攻撃されやすく又はアンセキュアになるであろう。

【0024】

本発明によって示されるシステムにおいては、セキュリティ及び制御は各データセット２６に組み込まれる。これは、データがどのように用いられるかにとらわれない普遍的な実施を保証するので、はるかに効率的且つセキュアであることが理解されるであろう。図１において、データ統合を行うことの一部としてアプリケーション間でデータがコピーされるのであれば、セキュリティ及び制御はデータを追跡せず、各アプリケーションによって再実装されるはずである。アクセス制御レイヤ３９はデータセット２６の上のレイヤとして構築されるので、これは回避される。

【0025】

次に図６について見ると、第１のノード３６ａが第２のノード３６ｂ及び第３のノード３６ｃに接続され得ることがわかる。これはデータノードのネットワーク３４を形成する。ノード３６は、ノード３６間の関係であるリンク４０を介して接続される。リンク４０は、データノードのネットワーク３４の基礎を形成する、ノードのメタデータレイヤ３７内に定義される。リンク４０はデータノード内のデータレコード３５を関係付け、個々のリンク４０は、第１のノード３６ａのデータレコードを別のノード３６ｂ，３６ｃの１つ以上のデータレコードに関係付ける能力を有する。

【0026】

各ノード３６は自己記述型、自己接続型、及び自己保護型であるため、ネットワーク３４内のデータセット２６はアプリケーションの境界によって制限されはしない。データはもはや、図１に示される従来技術の図示におけるようにサイロ化されなくなる。これは、図１に示されるアプリケーションによって管理されるデータベースの必要を無くし、データセットのより単純でより効果的な使い方を生み出す。

【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】

無承認の変更の追跡に特化したテーブルとそれ自体承認されたマスタテーブルである別のテーブルという２つの別々のテーブルを管理することが、変更承認のために用いられ得ることがわかった。この２テーブルアーキテクチャ内のプロセスは、アプリケーションレイヤにおけるオンザフライ及び情報交換レイヤ外の変更を計算することを含め、マスタテーブルと無承認変更テーブルとの間で変更が行われた特定のフィールドを比較及び識別するために実行された。これは各マスタデータ列についての変更を識別するための持続フラグ（persisting flag）に基づくプロセスに繋がり、許容可能なパフォーマンス及び記憶要求特性（storage requirement characteristic）を届けると共にプラットフォームの全体アーキテクチャの一部として内蔵された。

【0065】

よって、本明細書においては、無承認のデータベース変更を効果的にバージョン管理及び追跡するために、無承認の変更の追跡に特化したテーブルとそれ自体承認されたマスタテーブルである別のテーブルという２つの別々のテーブルを管理する２テーブルデータ構造が提供されている。これは、パフォーマンス及び記憶要求特性に悪影響を与えることなく各マスタデータ列についての変更を識別する、前述した持続フラグを含み得る。

【0066】

データ駆動エンタイトルメント
全てのアクセス方法（例えばＡＰＩ又はＵＩ）にわたり一貫してデータベースにより実行され得るユーザ／グループベースの列レベルエンタイトルメントに加え、本明細書に記載されるプラットフォームは、データ駆動エンタイトルメントを可能にするようにも構成され得る。データがやはり断片化及び複製される必要があろうことは、無条件に理解されている。例えば、ある人が会社の全員の肩書及び名前を見たいと欲したとしても、その人自身の電話番号及び住所しか見ることはできず、またその人自身及びその人の監督者しかその人の給料を見ることはできない。この情報が同じテーブルに存在するためには、プラットフォームが、テーブル内のデータに基づいてアクセスを制御することを可能にすることであろう別個の条件を適用する。

【0067】

情報交換レイヤを作成すること及びバックエンドに送信される前にクエリを書き換えることによって、列レベルエンタイトルメントが適用され得る。これはユーザの許可をユーザが実行中のクエリと組み合わせたものである。ユーザのクエリの「ｗｈｅｒｅ句」が任意の追加的な条件を含むようにリッチ化され得る一方で、場合によっては、これは、例えば更新を行うときに、ｗｈｅｒｅ句を含むようにクエリを完全に作り直すことを意味することがわかっている。しかしこれはデータ駆動エンタイトルメントを行うには不十分であり得る。なぜなら、ユーザのエンタイトルメントはユーザがアクセスを有さないデータに基づき得るからである。プラットフォームは、クエリ全体をそのユーザのコンテキスト下で実行し得る。例えば、あるユーザが、Ｎａｍｅ（名前）、Ｔｉｔｌｅ（肩書）、Ｐｈｏｎｅ Ｎｕｍｂｅｒ（電話番号）、及びＡｄｄｒｅｓｓ（住所）のテーブルにおいてＮａｍｅ及びＴｉｔｌｅにしかアクセスを有さない場合、プラットフォームはそのユーザの許可を適用して、ユーザが取得するデータをＮａｍｅ及びＴｉｔｌｅに戻すように制限し得る。データ駆動エンタイトルメントによれば、ユーザが住所フィールドへのアクセスを有さないときに、プラットフォームが、住所が特定の州又は地域にある全ての被雇用者をユーザが閲覧することを可能にし得る。

【0068】

そのプラットフォームは、異なる列に影響を与える複数のエンタイトルメントを合わせて階層化できるようにも構成され得る（例えば、自身の名前、肩書、電話番号、及び住所は見ることができるが、他の被雇用者の名前及び肩書しか見ることができない）。ｗｈｅｒｅ句を動的に書き換えることによって、プラットフォームは、条件を個々の列に分離することができないかもしれない。したがって、プラットフォームの書き換えロジックは、条件がこのカテゴリに該当するとき、条件の位置付けを適応するように拡張され得る。

【0069】

テーブル間にリンクがある場合には、現在のデータセットの制御に加えて、リンクされたテーブルの制御が適用されるべきであるとも認識された。リンクは他のリンクを指し得、したがって１つだけではなく潜在的に複数の追加的な条件の組を含み得るので、これはかなり複雑になり得る。また、リンクは、１対多数の関係を可能にするようにプラットフォームの内部で複数選択をサポートする。ユーザがデータのサブセットへのアクセスを有する環境においては、プラットフォームは、複数の選択がある場合、ユーザには見ることを許されたものしか見えないことを保証するように構成され得る。これは、これらの条件を動的に説明するための書き換えロジックをさらに複雑化し得る。

【0070】

データ駆動のシナリオを可能にするために、プラットフォームは、エンタイトルメント条件の内部のユーザが現在のユーザについて及びそのユーザがどのグループのメンバーであるのかについての情報にアクセスすることを可能にするようにも構成され得る。これは、そのようなファンクションをサポートするようにクエリ言語を拡張することによって行われ得る。

【0071】

（これらの制御が各リクエストの解析に追加した複雑性及び基盤となるデータベースに対して発せられる最終的なクエリによる）潜在的なパフォーマンスの問題に対処するために、プラットフォームは、プラットフォームのクエリエンジンによってステートメントが処理される回数を低減させ得るカスタムキャッシュレイヤも実装し得る。

【0072】

したがって、プラットフォームは、データレベルアクセス制御のためのプロセスを提供して、現在のユーザの証明書ではなくシステムユーザを通じて書き換えられたクエリを運用することによってデータ駆動エンタイトルメントを可能にすると共に、複数のエンタイトルメントを合わせて階層化することができる。

【0073】

データ同期／コネクタアーキテクチャ
Ｅｘｔｒａｃｔ Ｔｒａｎｓｆｏｒｍ Ｌｏａｄ（抽出・変換・ロード、ＥＴＬ）ツールは、一般に、新たなデータを挿入するため又はスクリプトを実行して既存のデータをクリアするためのコンポーネントを提供するが、本明細書に記載されるプラットフォームは、既存のデータをそのままにしてデルタを適用してバージョン履歴を保存するデータ同期を作成しようとするものである。プラットフォームはこれを、データ同期アーキテクチャがソース又はターゲットに無関係であったように行うことが意図されている。このようにすれば、単純なコネクタが、インターフェイスに対して、プラットフォームに関係なくより短い時間、例えば１～２日の期間での新たなコネクタの作成を可能にするように、並びに、同期がどのように動作するか及び公開するフィーチャに一貫性を持たせるように、構築され得る。

【0074】

同期を実装する第１のステップは、調整ロジックを確立することである。プラットフォームはパーティション分割を実装するように構成され得、これはカスタムインデックス作成及び並べ替え戦略に依存するカスタムアルゴリズムを作成することによって比較的効果的になることがわかった。すると、プラットフォームの同期ユーティリティとウェブアプリケーションとの間での転送時のデータのシリアル化及び逆シリアル化にボトルネックがシフトすることがわかった。例えばＧｏｏｇｌｅによって提供されるＰｒｏｔｏｃｏｌ Ｂｕｆｆｅｒｓなど、様々なシリアル化プロトコルが用いられ得る。Ｐｒｏｔｏｃｏｌ Ｂｕｆｆｅｒｓは、典型的には固定ペイロード構造に整合されることが認められるが、プラットフォームによれば、やり取りされるデータは固定スキーマには従わない。よって、プラットフォームは、動的構造をそのタイプのモデルに合わせるように構成された。

【0075】

したがって、プラットフォームは、同期エンジンからソース及びターゲットを抽出し得る。つまり、プラットフォームは、新たなコネクタを追加するとき、ソースとターゲットとの各組み合わせについてソリューションを実装するのではなく、データを標準的な中間フォーマットに変換するように書かれたコードを有しさえすればよい。

【0076】

ネットワーク成長
図１３ａから図１３ｃは、経時的なデータセットネットワーク３４の開発を示す。具体的には、図１３ａは、データが依然として開発されているところである初期段階の３４データセットネットワークを示す。初期段階においては、より少数のノード３６並びにノード３６間のより少数のリンク４０が存在する。データセットが開発されるにつれて、ユーザは更なるデータをデータセットネットワーク３４に追加し、ネットワークを成長させる。図１３ｂは、初期段階よりも後の段階におけるデータセットネットワーク３４を示す。この段階では、データセットネットワークは、より多くのノード３６及びノード間のより多くのリンク４０を有している。図１３ｃは、図１３ｂに示される段階よりも更に後の段階におけるデータセットネットワークを示す。この段階では、データセットネットワークは、多数のノード３６及びノード３６間の多数のリンク４０を有している。

【0077】

図１４及び図１５は、従来のアプリケーション対データセットネットワーク３４の概略図を提供する。図１４及び図１５は、ＵＩ１４、ＡＰＩ１５、Ｌｏｇｉｃ（ロジック）、制御１６、永続化２０を備え、それから演算デバイスのオペレーティングシステム１８と統合される、従来のアプリケーション（又は「アプリ」）を示す。その一方で、データセットネットワーク３４は、自己記述型、自己接続型、及び自己保護型であるノード３６を備えている。よって、ＵＩ１４、ＡＰＩ、又はオペレーティングシステム１８との統合の必要はない。ＡＰＩ４１又はアプリケーションエクスペリエンス３２は、クエリインターフェイス３３を介してデータネットワーク３４から直接的にデータ２５を取得する。これは、別々のデータベースを作成、インポート、更新、及び管理する必要を無くす。これは、各アプリケーションのセキュリティ及び制御システム１６、データ統合システム１８、データ永続化システム２０、及びデータ公開システム２２を管理する必要も無くす。

【0078】

データセットネットワーク３４は、追加的なセキュリティ及び制御機能１６、データ統合機能１８、データ永続化機能２０、及びデータ公開機能２２を必要としない。クエリインターフェイス３３が利用可能であるため、データと情報をやりとりするためのカスタムユーザインタフェースを作成することも任意である。

【0079】

したがって、任意の数のデータセットノード３６並びにアプリケーションエクスペリエンスがネットワーク３４に追加され得ることが理解されるであろう。より新しいアプリケーションが追加されるにつれて、データのネットワークは成長し、新たなデータセットの間により新しいリンクが形成される。

【0080】

図１６Ａは、サイロ化されたデータベースを用いる従来のアプリケーション開発のセキュリティ及び制御１６を示す概略図である。図１６Ｂは、データネットワーク３４を用いるアプリケーション開発のアクセスレイヤ３９を介したセキュリティ及び制御を示す概略図である。図１６Ｂにおいては、データ２６は、図１６Ａに示されるようにアプリケーションのサービスアカウントを通じてではなく、ユーザのクレデンシャルを通じてアクセスされる。データネットワーク３４のセキュリティ及び制御３９は、従来行われてきたように各アプリケーション１０においてではなく、データセット２６毎に定義される。これは、データに対する真の、アプリケーションを跨いだセキュリティ及び制御を可能にすると共に、データ複製を無くす。ユーザ１２は、常にアプリケーションを通じてではなく、任意選択的にデータネットワークユーザインターフェイス４２を介して直接的にデータと情報をやりとりすることもできる。

【0081】

説明を単純及び明瞭にするため、適切と考えられる場合には、参照番号が、対応する又は類似の要素を示すために、複数の図において繰り返され得る。また、本明細書に記載される例の完全な理解を提供するために、多くの具体的詳細が述べられる。しかしながら、当業者には、本明細書に記載される例はこれらの具体的詳細なしに実行され得ることが理解されるであろう。他の事例では、本明細書に記載される例を不明瞭にしないように、周知の方法、手順、及びコンポーネントは詳細には記載されていない。また、記載は、本明細書に記載される例の範囲を限定するものとして考えられるべきではない。

【0082】

本明細書において用いられる例及び対応する図は説明のみを目的としていることは理解されるであろう。本明細書に表される原理から逸脱することなく、異なる構成及び用語が用いられ得る。例えば、これらの原理から逸脱することなく、コンポーネント及びモジュールが追加され、削除され、修正され、又は異なる接続で配置され得る。

【0083】

また、本明細書において例示される、命令を実行する任意のモジュール又はコンポーネントは、記憶媒体、コンピュータ記憶媒体、又は例えば磁気ディスク、光ディスク、もしくはテープなどの（着脱可能及び／又は着脱不可能な）データ記憶デバイスのような、コンピュータ可読媒体を含み得るか又はこれへのアクセスを有し得る。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータのような、情報の記憶のための任意の方法又は技術で実装された、揮発性及び不揮発性の、着脱可能及び着脱不可能な媒体を含み得る。コンピュータ記憶媒体の例は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、又は所望の情報を記憶するために用いることができアプリケーション、モジュール、もしくはその両方によってアクセスされ得る任意の他の媒体を含む。そのようなコンピュータ記憶媒体はいずれも、プラットフォームの一部であり得、プラットフォームのいずれかのもしくはプラットフォームに関係する任意のコンポーネントなどであり得、又はプラットフォームにアクセス可能もしくは接続可能であり得る。本明細書に記載されるアプリケーション又はモジュールはいずれも、そのようなコンピュータ可読媒体によって記憶され又は保持され得るコンピュータ可読／実行可能命令を用いて実装され得る。

【0084】

本明細書に記載されるフローチャート及び図中のステップ又は動作は例に過ぎない。これらのステップ又は動作には、上述の原理から逸脱することなく、多くのバリエーションが存在し得る。例えば、ステップは異なる順序で行われてもよく、又はステップが追加、削除、又は修正されてもよい。

【0085】

上記の原理を特定の具体例を参照して記載してきたが、当業者には、添付の特許請求の範囲に述べられるように、様々な修正が自明であろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8a】

【図8b】

【図8c】

【図8d】

【図8e】

【図9】

【図10】

【図11】

【図12】

【図13a】

【図13b】

【図13c】

【図14】

【図15】

【図16A】

【図16B】

【国際調査報告】