JP2018152050A - ブロックチェーンバージョン制御システム - Google Patents

Abstract

【課題】 分散型バージョン制御システム、方法、及びコンピュータ読取可能媒体を提供する【解決手段】 分散型バージョン制御システム、方法、及びコンピュータ読取可能媒体が説明される。コンピュータシステムが、ソースコード及び／又はソースコードに関連づけられたアーチファクトを取得することによりバージョン制御ブロックチェーンシステムを実現することができる。コンピュータシステムは、ソースコード及び／又はアーチファクトをシリアル化して、シリアル化されたデータを取得することができ、シリアル化されたデータを暗号化して、現在ブロック識別子（ｃｂ＿ｉｄ）を取得することができる。コンピュータシステムは、ブロックを生成してｃｂ＿ｉｄを含めることができ、ブロックを検証すると、生成されたブロックをバージョン制御ブロックチェーンに追加することができる。他の実施形態が説明され、かつ／あるいは請求され得る。【選択図】 図２

Description

著作権通知
本特許文献の開示の一部は、著作権保護を受ける資料を含む。著作権者は、特許文献又は特許開示が米国特許商標庁の特許ファイル又は記録に出現する限り、何人によるそのファクシミリ複製に対しても異義を有さないが、そうでない場合は何であれすべての著作権を留保する。

１つ以上の実装が、一般に、ブロックチェーン分散データベースに関し、詳細には、ブロックチェーン技術に基づいて分散ソフトウェア開発のためにスキーマ進化を管理することに関する。

マルチテナントデータベースシステムにおいて、顧客組織（さらに、「テナント」としても参照される）は、１つの論理データベース内のデータベースリソースを共有することがある。データベースはそれ自体、典型的に共有され、各テナントは、各テナントに属する行又はレコードを識別するために使用できる組織識別子（ｏｒｇＩＤ）列又はフィールドに典型的に関連づけられる。各テナントは、その独自のカスタムデータを提供することがあり、このことは、カスタムオブジェクト及びカスタムフィールドを定義することと、カスタムインデックスフィールドとして動作するように１つ以上のカスタムフィールドを指定することとを含み得る。マルチテナントデータベースシステムのオーナ／オペレータは、ソフトウェア開発プラットフォーム（ＳＤＰ）、統合開発環境（ＩＤＥ）、ソフトウェア開発キット（ＳＤＫ）等を提供して、テナントがカスタムフィールドを指定し、かつその他の方法でマルチテナントデータベースシステム内に自身のテナント空間を構成することを可能にすることがある。マルチテナントデータベースシステムのオーナ／オペレータは、テナントのエージェントによる使用のためにプレビルトしたカスタマイズ可能なクエリアプリケーションをさらに提供することがあり、そのため、これらエージェントは、テナントのテナント空間内のデータにアクセスし、かつ／あるいは該データを編集することができる。これらの場合、マルチテナントデータベースシステムのオーナ／オペレータは、ＳＤＰ、ＩＤＥ、ＳＤＫ、及び／又はアプリケーションプログラミングインターフェース（ＡＰＩ）を提供して、テナントがクエリアプリケーションをカスタマイズすることを可能にすることがある。しかしながら、テナント空間構成に対するリビジョン及び／又はクエリアプリケーションに対するリビジョンを編成し、かつ／あるいは制御することは、特に、テナントが比較的大きいチームの開発者／管理者を用いてテナント空間及び／又はクエリアプリケーションをカスタマイズするとき、困難である可能性がある。

典型的なソースコード管理ソリューションは、開発者のチームがソースファイルに表わされたコード及び宣言構造の中央リポジトリを共有することを可能にすることができる。これら管理ソリューションは、さらに、開発者がソースファイルを変更し、他の開発者により作られた上記構造を含むファイルを一緒にマージし、ソフトウェアプロダクトをビルド及びリリースするシステムの必要を果たすことを可能にする。多くの場合、これら管理ソリューションは、ソースリポジトリに対するアクセスを有さない他のサードパーティ開発者がその独自のプロダクトを作成するのに使用する必要があるＳＤＰであり得る。しかしながら、典型的なソースコード管理ソリューションは、あるリリースから次のリリースへの変更／リビジョンの構造互換性を確保するルールが配慮されることを確保するためのメカニズムを含まない。こうしたルールを固守するのに失敗することは、「スキーマ進化」問題として参照されることがある。スキーマ進化問題に対するいくつかのソリューションには、開発者が開発ルールを順守したコードを開発することができるように開発ルールを公開することが含まれる。しかしながら、スキーマ進化ルールに永遠性を与えることは、これらがそれ自体、開発者によりソースとして修正されることがあり、互換性の保証を提供しないことを意味する。逆に、ソースコード管理プラットフォームは、集中型オンラインサービスを使用してソースファイルの様々なバージョンを取り込んで、開発ルールのテーブルに対してこれらを検証することができるが、こうしたソリューションは、すべての開発者にオンラインを強制する可能性があり、ゆえに、接続を切られた開発を除外する可能性がある。このことは、ソースファイルの正確なマニフェストが参照されることを確保するようにソースコードシステムの外部の分岐構造をモデル化するためのルールテーブルに負荷をかけるおそれがある。

含まれる図面は例示目的のものであり、開示される発明システム、装置、方法、及びコンピュータ読取可能記憶媒体のとり得る構造及び動作の例を提供する役割を果たす。これら図面は、開示される実現の主旨及び範囲から逸脱することなく当業者によりなされ得る形式及び詳細のいかなる変更も限定しない。
いくつかの実現による、オンデマンドデータベースサービスが使用され得る一例示的な環境のブロック図を示す。 いくつかの実現による、図１Ａの要素の例示的な実現とこれら要素間の例示的な相互接続とのブロック図を示す。 様々な実施形態に従う、ユーザシステムのコンポーネントがデータベースシステムのコンポーネントと対話する配置を示す。 様々な実施形態に従う、バージョン制御ブロックチェーンのブロックの例示的な要素を示す。 様々な実施形態に従う、バージョン制御ブロックチェーンに追加されるべきブロックを生成する処理を示す。 バージョン制御ブロックチェーンに含めるためにブロックを立証する処理を示す。

本明細書において論じられる実施形態は、ブロックチェーン技術に基づいて分散ソフトウェア開発環境のスキーマ進化を管理することに向けられる。実施形態において、ルールテーブルが、ブロックチェーン技術を用いて新しい又は編集されたレコードを検証する（validates）マルチテナントデータベースシステムなどの集中型オンラインサービスに対して外部で、シリアル化される（serialized）ことができる。ブロックチェーン技術を用いて、上記サービスは、前のバージョン及び互換性ルールのヒストリを配慮することなく変更のシーケンス（例えば、ブロックチェーン等）にアペンドすることについて、新しい／編集されたレコードが受け入れられ得ないことを確保することができる。いくつかの実施形態において、新しい／編集されたレコードは、ブロックチェーンのヒストリ全体が該新しい／編集されたレコードに含まれるときのみ受け入れられ得る。実施形態において、１つ以上のソースアーチファクトのリリースヒストリのスタンプ又は他の識別子を含むレコードが、データベースレコードとして表わされ、変更レコードのブロックにシリアル化されることができ、これらブロックは、次いで、改ざん不可能な鍵を用いて署名され、一緒に連鎖されることができる。こうして、開発者は、リリースの先頭に戻る連鎖されたレコードのヒストリを含まないレコードを追加又は変更することができない。

実施形態において、中央サービスは、これら変更を取り込むことができ、変更レコードの各ブロックに対してただ１つの後継が許可されるように、ルールテーブルを用いてロックステップにおいてソース変更の単一の幹（trunk）分岐が管理されることを確保することができる。このことは、インプリメンタへ戻る変更の調和を強制して、リリースヒストリが配慮されることを確保することができる。他の実施形態において、中央サービスは、所望に応じて、又は様々なスキーマ開発ポリシーに基づいて、他の分岐トポロジを許可してもよい。いくつかの実施形態において、１つ以上のユーザシステムが、例えば、ブロックチェーンに対する追加についてブロックを検証して、変更レコードの各ブロックに対してただ１つの後継が許可されるように分散型ルールテーブルに従ってソース変更の単一の幹分岐が管理されることを確保することなどによって集中型サービスのタスクを実行する、分散型アーキテクチャが実現されてもよい。

開示される実装によるシステム、装置、コンピュータ読取可能記憶媒体、及び方法の例が、本セクションで説明される。これら例は、単に開示される実装の文脈を追加し、その理解を支援するために提供されている。ゆえに、開示される実装は、提供される特定の詳細のうちいくつか又はすべてなしに実践され得ることが当業者に明らかであろう。他の例において、本明細書において「ブロック」としても参照される特定のプロセス又は方法の動作は、開示される実装を不要に分かりにくくすることを回避するために、詳細には説明されていない。他の実装及び用途がさらに可能であり、そのようなものとして、下記の例は、範囲又は設定のいずれかにおいて決定的又は限定的とみなされるべきでない。

下記の詳細な説明において、添付図面に対して参照が行われ、添付図面は説明の一部を形成し、添付図面内には例示として特定の実現が示される。これら開示される実現は当業者が上記実現を実践することが可能であるよう十分詳細に説明されるが、これら例は限定的でなく、そのため他の実現が使用されてもよく、開示される実現に対してその趣旨及び範囲から逸脱することなく変更が行われてもよいことが理解されるべきである。例えば、本明細書に図示及び説明される方法のブロックは、いくつかの他の実現において、必ずしも示された順序で実行されない。さらに、いくつかの他の実現において、開示される方法は、説明されるよりもより多くの又はより少ないブロックを含んでもよい。別の例として、本明細書において別個のブロックとして説明されるいくつかのブロックは、いくつかの他の実現において組み合わせられてもよい。逆に、本明細書において単一のブロックとして説明され得るものが、いくつかの他の実現において複数のブロックで実現されてもよい。さらに、接続詞「又は」は、別段示されない限り、適切な場合、包含的な意味を意図される。すなわち、フレーズ「Ａ、Ｂ、又はＣ」は、「Ａ」、「Ｂ」、「Ｃ」、「Ａ及びＢ」、「Ｂ及びＣ」、「Ａ及びＣ」、並びに「Ａ、Ｂ、及びＣ」の可能性を含むように意図される。

本明細書において説明及び参照されるいくつかの実現は、ユーザクエリを解決することに役立つアーティクル（articles）を識別するシステム、装置、コンピュータ実現方法、及びコンピュータ読取可能記憶媒体に向けられる。

データベースシステムは、顧客サポートクエリに関連づけられたケースを表示することがある。データベースシステムは、新しいケースに関連した他のケースについて検索を開始することができる。データベースシステムは、ターム重み付けアルゴリズム、例えばモアライクディス（more like this）（ＭＬＴ）などを用いて、新しいケース内に提供されたタイトル及び／又は説明から関連タームを抽出することができる。関連タームは、次いで、関連したケースを識別する検索クエリ内で使用される。

データベースシステムは、関連したケースにリンクされたアーティクルを識別し、アーティクルをランク付けし、ランク付けに基づく順序でリモートのユーザシステム上にアーティクルを表示させる。データベースシステムは、アーティクルにリンクされた関連したケースの数に基づいてアーティクルをランク付けすることができる。データベースシステムはまた、他のパラメータ、例えば関連したケースの関連度スコア、ケースに割り当てられたラベル、関連したケースの最後の修正日付などに基づいてアーティクルをランク付けしてもよい。

データベースシステムは、同様の語彙を使用して同様の顧客問題を説明する関連したケースを最初見つけることにより、より関連するアーティクルを識別することができる。データベースシステムは、次いで、前の問題を解決するのに役立つと前に判定されたアーティクルを識別する。ゆえに、データベースシステムは、問題を説明するために顧客により使用される語彙とこれら問題に対するソリューションを説明するためにアーティクル内で使用される語彙との間のギャップを埋めることができる。

いくつかの実現において、本明細書において説明されるユーザは、対話的オンライン「企業ソーシャルネットワーク」のユーザ（又は、「メンバ」）であり、上記「企業ソーシャルネットワーク」はさらに本明細書において「企業ソーシャルネットワーキングシステム」、「企業協働ネットワーク」として、あるいはより簡素に「企業ネットワーク」としても参照される。こうしたオンラインの企業ネットワークは、人々の間のやりとりを容易にする一般的方法にますますなっており、人々のうち誰もが、企業ユーザとして認識されることがある。オンライン企業ソーシャルネットワークの一例は、カリフォルニア州サンフランシスコのｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社により提供されるＣｈａｔｔｅｒ（登録商標）である。ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社は、企業ソーシャルネットワーキングサービス、顧客関係管理（ＣＲＭ）サービス、及び他のデータベース管理サービスのプロバイダであり、上記のうちいずれも、いくつかの実現において本明細書に開示される手法と関連してアクセスされ、使用されることができる。これらの様々なサービスは、本明細書において説明されるようにクラウドコンピューティング環境において、例えば、マルチテナントデータベースシステムの文脈において提供できる。説明される手法又はプロセスのいくつかは、ローカルでソフトウェアをインストールする必要なく、すなわち、クラウドを通じて利用可能なサービスと対話するユーザのコンピューティングデバイス上で実現できる。開示される実現は、Ｃｈａｔｔｅｒ（登録商標）とより一般的に企業ソーシャルネットワーキングとを参照して説明されることがあるが、開示される手法はＣｈａｔｔｅｒ（登録商標）にもｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社により提供されるいかなる他のサービス及びシステムにも限定されず、例えば、マルチテナントデータベースシステムの一部でもなく企業ソーシャルネットワーキングサービスも提供しないクラウドベースシステムなどの様々な他のデータベースシステムの文脈において実現されてもよいことを当業者は理解するべきである。

本明細書において用いられるとき、用語「テナント」は、ソフトウェアインスタンスに対して特定の特権で一般的アクセスを共有するユーザのグループを含むことができる。マルチテナントアーキテクチャ、例えば本明細書において論じられるものなどは、テナント固有データ、ユーザ管理、テナント固有機能性、構成、カスタマイズ、非機能的属性、関連づけられたアプリケーション等のうち１つ以上を典型的に含むソフトウェアインスタンスの専用共有分を、テナントに提供することができる。マルチテナンシーは、別個のソフトウェアインスタンスが異なるテナントのために動作するマルチインスタンスアーキテクチャと対照をなす。

図１Ａは、いくつかの実現に従うオンデマンドデータベースサービスが使用され得る環境１０の一例のブロック図を示す。環境１０は、ユーザシステム１２と、ネットワーク１４と、データベースシステム１６（さらに、本明細書において「クラウドベースシステム」としても参照される）と、プロセッサシステム１７と、アプリケーションプラットフォーム１８と、ネットワークインターフェース２０と、テナントデータ２３を記憶するテナントデータベース２２と、システムデータ２５を記憶するシステムデータベース２４と、システム１６の様々な機能を実現するプログラムコード２６と、データベースシステムプロセス及びテナント固有プロセスを実行し、例えば、アプリケーションホスティングサービスの一部としてアプリケーションを実行するプロセス空間２８とを含む。いくつかの他の実現において、環境１０は、これらコンポーネント又はシステムのすべてを有さなくてもよく、あるいは、上記でリストアップされたコンポーネントに対して代わりに又は追加で他のコンポーネント又はシステムを有してもよい。

いくつかの実現において、環境１０は、オンデマンドデータベースサービスが存在する環境である。オンデマンドデータベースサービス、例えば、システム１６を用いて実現できるサービスなどは、システム１６に対するアクセスを所有、維持、又は提供する、企業の外部のユーザに対して利用可能にされるサービスである。上記で説明されたように、こうしたユーザは、一般に、システム１６を構築又は維持することに関与する必要がない。代わりに、システム１６により提供されたリソースは、ユーザがシステム１６により提供されるサービスを必要とするとき、すなわちユーザの要望に応じて、こうしたユーザの使用に対して利用可能であり得る。いくつかのオンデマンドデータベースサービスは、１つ以上のテナントからの情報を共通のデータベースイメージのテーブルに記憶してマルチテナントデータベースシステム（ＭＴＳ）を形成することができる。用語「マルチテナントデータベースシステム」は、データベースシステムのハードウェア及びソフトウェアの様々な要素が１以上の顧客又はテナントにより共有され得るシステムを参照することができる。例えば、所与のアプリケーションサーバが、多数の顧客の要求を同時に処理してもよく、所与のデータベーステーブルが、潜在的にさらにより多数の顧客のフィードアイテムなどのデータの行を記憶してもよい。データベースイメージには、１つ以上のデータベースオブジェクトを含むことができる。関係データベース管理システム（ＲＤＢＭＳ）又はその均等物は、データベースオブジェクトに対して情報の記憶及び取り出しを実行することができる。

アプリケーションプラットフォーム１８は、システム１６のアプリケーションが実行することを可能にするフレームワーク、例えば、システム１６のハードウェア又はソフトウェアインフラストラクチャなどであり得る。いくつかの実現において、アプリケーションプラットフォーム１８は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム１２を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム１２を介してオンデマンドデータベースサービスにアクセスするサードパーティアプリケーション開発者により開発された１つ以上のアプリケーションの作成、管理、及び実行を可能にする。

いくつかの実現において、システム１６は、ウェブベース顧客関係管理（ＣＲＭ）システムを実現する。例えば、いくつかのこうした実現において、システム１６は、ＣＲＭソフトウェアアプリケーションを実現及び実行し、ユーザシステム１２への及びユーザシステム１２からの関連したデータ、コード、フォーム、レンダリング可能なウェブページ及び文書、並びに他の情報を提供し、かつ、関連したデータ、オブジェクト、及びウェブページコンテンツをデータベースシステムに記憶し、データベースシステムから取り出すように構成された、アプリケーションサーバを含む。いくつかのＭＴＳ実現において、複数のテナントのためのデータが、テナントデータベース２２内の同じ物理データベースオブジェクトに記憶されてもよい。いくつかのこうした実現において、テナントデータは、こうしたデータが明白に共有されない限り、あるテナントが別のテナントのデータに対するアクセスを有さないように、あるテナントのデータが他のテナントのデータとは論理的に別個に保持されるようにテナントデータベース２２の記憶媒体内に配列される。システム１６はまた、ＣＲＭアプリケーション以外の、又はＣＲＭアプリケーションに対して追加のアプリケーションを実現する。例えば、システム１６は、ＣＲＭアプリケーションを含む複数のホストされた（標準及びカスタムの）アプリケーションに対するテナントアクセスを提供することができる。ＣＲＭを含んでもよく含まなくてもよい、ユーザ（又は、サードパーティ開発者）アプリケーションが、アプリケーションプラットフォーム１８によりサポートされてもよい。アプリケーションプラットフォーム１８は、アプリケーションの１つ以上のデータベースオブジェクトへの作成及び記憶と、システム１６のプロセス空間における１つ以上の仮想マシン内でのアプリケーションの実行とを管理する。

いくつかの実現によれば、各システム１６は、ウェブページ、フォーム、アプリケーション、データ、及びメディアコンテンツをユーザ（クライアント）システム１２に提供して、システム１６のテナントとしてのユーザシステム１２によるアクセスをサポートするように構成される。そのようなものとして、システム１６は、データが共有されない限り各テナントのデータを別個に保持するようにセキュリティメカニズムを提供する。２つ以上のＭＴＳが使用される場合、これらは互いに近接して（例えば、単一の建物又はキャンパス内に位置するサーバファーム内に）位置してもよく、あるいは、これらは互いから遠隔の位置（例えば、市Ａに位置する１つ以上のサーバと、市Ｂに位置する１つ以上のサーバ）に分散されてもよい。本明細書において用いられるとき、各ＭＴＳは、ローカルで分散されているか又は１つ以上の地理的位置にわたる、１つ以上の論理的又は物理的に接続されたサーバを含むことがある。さらに、用語「サーバ」は、当分野において周知である処理ハードウェア及びプロセス空間と、メモリデバイス又はデータベースなどの関連づけられた記憶媒体と、いくつかの例ではデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）とを含むコンピューティングデバイス又はシステムを参照するように意図される。さらに、「サーバシステム」と「サーバ」とは本明細書においてしばしば置き換え可能に用いられることが理解されるべきである。同様に、本明細書において説明されるデータベースオブジェクトは、単一のデータベース、分散型データベース、分散型データベースの集合、冗長オンライン若しくはオフラインバックアップ又は他の冗長性を有するデータベース等の一部として実現されてもよく、分散型データベース又はストレージネットワークと関連づけられた処理インテリジェンスとを含むことができる。

ネットワーク１４は、互いに通信するシステム又はデバイスの任意のネットワーク又はネットワークの組み合わせであり、あるいはこれらを含んでもよい。例えば、ネットワーク１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、テレフォンネットワーク、ワイヤレスネットワーク、セルラーネットワーク、ポイントツーポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク、又は他の適切な構成のうち任意の１つ又は任意の組み合わせであり、あるいはこれらを含んでもよい。ネットワーク１４は、ＴＣＰ／ＩＰ（トランスファーコントロールプロトコル及びインターネットプロトコル）ネットワーク、例えば、（大文字の「Ｉ」を用いて）「インターネット」としてしばしば参照されるネットワークのグローバルインターネットワークなどを含んでもよい。インターネットは、本明細書における例のうち多くで用いられる。しかしながら、ＴＣＰ／ＩＰは頻繁に実現されるプロトコルであるが、開示される実現が使用できるネットワークはそのように限定されないことが理解されるべきである。

ユーザシステム１２は、ＴＣＰ／ＩＰと、より高いネットワークレベルではＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの通信するための他の一般的インターネットプロトコルとを用いて、システム１６と通信することができる。ＨＴＴＰが使用される一例において、各ユーザシステム１２は、システム１６のＨＴＴＰサーバへの及びＨＴＴＰサーバからのＨＴＴＰ信号を送信及び受信するために、「ウェブブラウザ」又は簡素に「ブラウザ」として一般に参照されるＨＴＴＰクライアントを含むことができる。こうしたＨＴＴＰサーバは、システム１６とネットワーク１４との間の単独のネットワークインターフェース２０として実現されてもよく、しかし、これら手法に対して追加で又は代わりに他の手法が用いられてもよい。いくつかの実現において、システム１６とネットワーク１４との間のネットワークインターフェース２０は、ロードシェアリング機能性、例えば、ロードのバランスをとり、かつ入来ＨＴＴＰ要求を複数のサーバにわたり均等に分散するラウンドロビンＨＴＴＰ要求分配器などを含む。ＭＴＳ実現では、サーバの各々がＭＴＳデータに対するアクセスを有することができ、しかしながら、他の代替的な構成が代わりに用いられてもよい。

ユーザシステム１２は、データベースシステム１６にアクセスするためにユーザにより使用可能な任意のコンピューティングデバイス又は他のデータ処理装置若しくはシステムとして実現されてよい。例えば、ユーザシステム１２のうち任意のものが、デスクトップコンピュータ、ワークステーション、ラップトップコンピュータ、タブレットコンピュータ、ハンドヘルドコンピューティングデバイス、モバイルセルラーフォン（例えば、「スマートフォン」）、若しくは任意の他のＷｉ‐Ｆｉ（登録商標）対応デバイス、ワイヤレスアクセスプロトコル（ＷＡＰ）対応デバイス、又はインターネット若しくは他のネットワークに直接又は間接的にインターフェースをとることができる他のコンピューティングデバイスであってもよい。用語「ユーザシステム」及び「コンピューティングデバイス」は本明細書において、互いに、及び用語「コンピュータ」と置き換え可能に用いられる。上記で説明されたように、各ユーザシステム１２は、ＨＴＴＰクライアント、例えば、ＷｅｂＫｉｔプラットフォームに基づくウェブブラウザ、Ｍｉｃｒｏｓｏｆｔ（登録商標）のインターネットエクスプローラブラウザ、Ａｐｐｌｅ（登録商標）のＳａｆａｒｉ（登録商標）、Ｇｏｏｇｌｅ（登録商標）のＣｈｒｏｍｅ（登録商標）、Ｏｐｅｒａ（登録商標）のブラウザ、又はＭｏｚｉｌｌａ（登録商標）のＦｉｒｅｆｏｘ（登録商標）ブラウザなどのウェブブラウジング（又は、簡素に「ブラウジング」）プログラムを典型的に実行して、ユーザシステム１２のユーザ（例えば、システム１６により提供されるオンデマンドサービスの加入者）がネットワーク１４を通じてシステム１６からの自身に利用可能な情報、ページ、及びアプリケーションにアクセスし、かつこれらを処理し、閲覧することを可能にする。

各ユーザシステム１２はまた、システム１６又は他のシステム若しくはサーバにより提供されたページ、フォーム、アプリケーション、及び他の情報と関連してユーザシステム１２のディスプレイ（例えば、他の可能性の中でもモニタ画面、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ）上にブラウザにより提供されたグラフィカルユーザインターフェース（ＧＵＩ）と対話するように、１つ以上のユーザ入力デバイス、例えばキーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン、又はスタイラスなどを典型的に含む。例えば、ユーザインターフェースデバイスが使用されて、システム１６によりホストされたデータ及びアプリケーションにアクセスし、記憶されたデータに対して検索を実行し、その他の方法でユーザがユーザに提示され得る様々なＧＵＩページと対話することを可能にすることができる。上記で論じられたように、実現は、インターネットとの使用に適するが、他のネットワークがインターネットに対して代わりに又は追加で使用されてもよく、例えば、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースネットワーク、任意のＬＡＮ又はＷＡＮなどである。

ユーザシステム１２のユーザは、そのそれぞれのキャパシティにおいて異なってもよく、特定のユーザシステム１２のキャパシティは、こうしたユーザシステムの現在のユーザに対するパーミッション（パーミッションレベル）によって全体的に決定されてもよい。例えば、販売員が特定のユーザシステム１２を使用してシステム１６と対話している場合、そのユーザシステムは、上記販売員に割り振られたキャパシティを有することができる。しかしながら、管理者がそのユーザシステム１２を使用してシステム１６と対話する間、そのユーザシステムは管理者に割り振られたキャパシティを有することができる。階層的ロールモデルが使用される場合、あるパーミッションレベルのユーザは、より低いパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ、及びデータベース情報に対するアクセスを有することができ、しかし、より高いパーミッションレベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報、及びデータに対するアクセスを有さないことがある。ゆえに、異なるユーザは、ユーザのそれぞれのセキュリティ又はパーミッションレベル（さらに、「承認」としても参照される）に依存して、アプリケーション及びデータベース情報にアクセスすること及びこれらを修正することに関して異なる能力を一般に有することになる。

いくつかの実現によれば、各ユーザシステム１２、及びそのコンポーネントのうちいくつか又はすべてが、Ｉｎｔｅｌ（登録商標） Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどの中央処理ユニット（ＣＰＵ）を用いて実行されるコンピュータコードを含むブラウザなどのアプリケーションを用いてオペレータ構成可能である。同様に、システム１６（及び、２つ以上が存在する場合のＭＴＳのさらなるインスタンス）、及びそのコンポーネントのすべてが、プロセッサシステム１７を用いて動作するコンピュータコードを含むアプリケーションを用いてオペレータ構成可能であってもよく、プロセッサシステム１７は、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどを含み得るＣＰＵ、又は複数のＣＰＵを含むように実現されてもよい。

システム１６は、本明細書に説明されるプロセスの実現のいくつかを実行するためにサーバ又は他のコンピューティングシステム（又は、こうしたサーバ若しくはコンピューティングシステムの集合）により実行可能であり、あるいは該サーバ又は他のコンピューティングシステムをプログラムするために使用される、非一時的命令を記憶させた有形のコンピュータ読取可能媒体を含む。例えば、コンピュータプログラムコード２６は、本明細書に説明されるようにウェブページ、アプリケーション、並びに他のデータ及びメディアコンテンツを相互通信及び処理するようにシステム１６を操作及び構成する命令を実現することができる。いくつかの実現において、コンピュータコード２６はダウンロード可能であり、ハードディスクに記憶されてもよいが、プログラムコード全体又はこれらの一部はまた、ＲＯＭ又はＲＡＭなどの周知である任意の他の揮発性又は不揮発性のメモリ媒体又はデバイスに記憶されてもよく、あるいは、プログラムコードを記憶することができる任意の媒体、例えば、フロッピーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライブ、及び磁気光ディスクを含む任意タイプの回転媒体、並びに磁気若しくは光学カード、ナノシステム（分子メモリＩＣを含む）、又は、命令若しくはデータを記憶するのに適した任意の他タイプのコンピュータ読取可能媒体若しくはデバイス上で提供されてもよい。さらに、プログラムコード全体又はその一部は、周知のように送信媒体を通じて、例えばインターネットを通じてソフトウェアソースから、又は別のサーバから、送信され、ダウンロードされてもよく、あるいは、周知の任意の通信媒体及びプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）等）を用いて、周知の任意の他の既存のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮ等）を通じて送信されてもよい。さらに、開示される実現のコンピュータコードは、サーバ又は他のコンピューティングシステム上で実行できる任意のプログラミング言語、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、任意の他のマークアップ言語、Ｊａｖａ^ＴＭ（登録商標）、Ｊａｖａｓｃｒｉｐｔ（登録商標）、ＡｃｔｉｖｅＸ（登録商標）、任意の他のスクリプティング言語、例えばＶＢＳｃｒｉｐｔなどにおいて具現化されてもよく、周知である多くの他のプログラミング言語が使用されてもよい（Ｊａｖａ^ＴＭはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社の商標である。）。

図１Ｂは、いくつかの実現による図１Ａの要素の例示的な実現とこれら要素間の例示的な相互接続とのブロック図を示す。すなわち、図１Ｂもまた環境１０を例示し、しかし図１Ｂでは、システム１６の様々な要素とこうした要素間の様々な相互接続とが、いくつかのより特定の実現に従ってさらなる特定性で示される。さらに、図１Ｂにおいて、ユーザシステム１２は、プロセッサシステム１２Ａ、メモリシステム１２Ｂ、入力システム１２Ｃ、出力システム１２Ｄ、及び通信システム１２Ｅを含む。プロセッサシステム１２Ａは、１つ以上のプロセッサ、例えば、シングルコア又はマルチコアプロセッサを含む１つ以上の中央処理ユニット（ＣＰＵ）、１つ以上のグラフィックス処理ユニット（ＧＰＵ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は、算術的、論理的、及び／又は入力／出力オペレーションを実行するようにプログラムコード及び／又はソフトウェアモジュールを実行することができる任意の他の電子回路などの、任意の適切な組み合わせを含むことができる。メモリシステム１２Ｂは、１つ以上のメモリデバイス、例えば、揮発ストレージデバイス（例えば、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）等）及び不揮発メモリデバイス（例えば、読取専用メモリ（ＲＯＭ）、フラッシュメモリ等）などの、任意の適切な組み合わせを含むことができる。入力システム１２Ｃは、入力デバイス、例えば、１つ以上のタッチスクリーンインターフェース、キーボード、マウス、トラックボール、スキャナ、カメラ、又はネットワークに対するインターフェースなどの、任意の適切な組み合わせを含むことができる。出力システム１２Ｄは、出力デバイス、例えば、１つ以上のディスプレイデバイス、プリンタ、ネットワークに対するインターフェースなどの、任意の適切な組み合わせを含むことができる。通信システム１２Ｅは、無線ネットワーク又は有線ネットワークと通信する回路を含むことができる。通信システム１２Ｅは、リンク１５（さらに、「チャネル１５」、「ネットワーキングレイヤトンネル１５」などとして参照される）を確立するために使用されてもよく、リンク１５を通して、ユーザシステム１２はデータベースシステム１６と通信することができる。通信システム１２Ｅは、特定の無線通信プロトコル（例えば、Ｗｉ‐Ｆｉ及び／又はＩＥＥＥ８０２．１１プロトコル）、セルラー通信プロトコル（例えば、ロングタームエボリューション（ＬＴＥ（登録商標））など）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）プロトコル（例えば、ＩＥＥＥ８０２．１５．４〜８０２．１５．５プロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ（ＢＬＥ）等）、及び／又は有線の通信プロトコル（例えば、イーサネット、ファイバ分散データインターフェース（ＦＤＤＩ）、ポイントツーポイント（ＰＰＰ）等）に対して専用にされた１つ以上のプロセッサ（例えば、ベースバンドプロセッサ等）を含んでもよい。通信システム１２Ｅは、固体又は非固体の媒体を通して変調された電磁放射を用いて無線／有線ネットワーク及び／又は他のユーザシステム１２との通信を可能にするハードウェアデバイスをさらに含んでもよい。こうしたハードウェアデバイスは、スイッチ、フィルタ、増幅器、アンテナ素子などを含んで、電波を生成し又はその他の方法で生じさせてデータを１つ以上の他のデバイスに送信することと、受信した信号をデジタルデータなどの使用可能な情報にコンバートすることとによって、無線での又はワイヤを通しての通信を容易にしてもよく、上記情報は、ユーザシステム１２の１つ以上の他のコンポーネントに提供されてもよい。データベースシステム１６と通信する（例えば、送信する／受信する）ために、ユーザシステム１２は、通信システム１２Ｅを用いて、データベースシステム１６のネットワークインターフェース２０とのリンク１５を確立してもよい。

図１Ｂにおいて、ネットワークインターフェース２０は、一組のＨＴＴＰアプリケーションサーバ１００_１〜１００_Ｎとして実現される。各アプリケーションサーバ１００は、さらに本明細書において「アプリサーバ」としても参照され、テナントデータベース２２及びその中のテナントデータ２３、並びにシステムデータベース２４及びその中のシステムデータ２５と通信して、ユーザシステム１２から受信した要求を果たすように構成される。テナントデータ２３は、個々のテナントストレージ空間１１２に分割されることができ、テナントストレージ空間１１２は、物理的又は論理的に配置又は分割されてもよい。各テナントストレージ空間１１２内で、ユーザストレージ１１４及びアプリケーションメタデータ１１６が、各ユーザについて同様に割り当てられることができる。例えば、ユーザの最も最近使用した（ＭＲＵ）アイテムのコピーが、ユーザストレージ１１４に記憶されてもよい。同様に、テナントである組織全体のＭＲＵアイテムのコピーが、テナントストレージ空間１１２に記憶されてもよい。

プロセス空間２８は、システムプロセス空間１０２、個々のテナントプロセス空間１０４、及びテナント管理プロセス空間１１０を含む。アプリケーションプラットフォーム１８は、アプリケーション開発者のアプリケーションの作成及び管理をサポートするアプリケーションセットアップメカニズム３８を含む。こうしたアプリケーション及びその他が、例えば、テナント管理プロセス１１０により管理される１つ以上のテナントプロセス空間１０４として、加入者による実行のために、保存ルーチン３６によりメタデータとしてテナントデータベース２２に保存されてもよい。こうしたアプリケーションに対する起動は、ＰＬ／ＳＯＱＬ３４を用いてコード化されてもよく、ＰＬ／ＳＯＱＬ３４は、ＡＰＩ３２に対するプログラミング言語スタイルインターフェース拡張である。いくつかのＰＬ／ＳＯＱＬ言語実現の詳細な説明が、Craig WeissmanによるMETHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICEと題され2010年6月1日に発行された、本明細書においてその全体を参照により及びすべての目的のために援用される、本発明の譲受人に譲渡された米国特許第7,730,478号で論じられている。アプリケーションに対する起動は、１つ以上のシステムプロセスにより検出でき、上記システムプロセスは、起動を行い、かつ仮想マシン内でアプリケーションとしてメタデータを実行する加入者のために、アプリケーションメタデータ１１６を取り出すことを管理する。

図１Ｂのシステム１６は、ユーザシステム１２におけるユーザ又は開発者に対する、システム１６常駐プロセスへのユーザインターフェース（ＵＩ）３０及びアプリケーションプログラミングインターフェース（ＡＰＩ）３２をさらに含む。いくつかの他の実現において、環境１０は、上記でリストアップされた要素と同じ要素を有さなくてもよく、あるいは、上記でリストアップされた要素に対して代わりに又は追加で他の要素を有してもよい。

各アプリケーションサーバ１００は、異なるネットワーク接続を介して、例えばテナントデータ２３及びシステムデータ２５に対するアクセスをそれぞれ有するテナントデータベース２２及びシステムデータベース２４に、通信可能に結合されることができる。例えば、１つのアプリケーションサーバ１００_１はネットワーク１４（例えば、インターネット）を介して結合でき、別のアプリケーションサーバ１００_Ｎ‐１は直接ネットワークリンクを介して結合でき、別のアプリケーションサーバ１００_Ｎはさらに異なるネットワーク接続によって結合できる。トランスファーコントロールプロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ１００とシステム１６との間で通信するために使用できる典型的なプロトコルの例である。しかしながら、使用されるネットワーク相互接続に依存してシステム１６を最適化するように他のトランスポートプロトコルが使用されてもよいことが当業者に明らかであろう。

いくつかの実現において、各アプリケーションサーバ１００は、システム１６のテナントである任意の組織に関連づけられた任意のユーザの要求を扱うように構成される。任意の時間に様々な理由のためにサーバプールからのアプリケーションサーバ１００を追加及び削除できることが望ましい可能性があるため、いくつかの実現において、特定のアプリケーションサーバ１００に対するユーザ又は組織のサーバアフィニティが存在しない。いくつかのこうした実現において、ロードバランシング機能（例えば、Ｆ５ Ｂｉｇ‐ＩＰロードバランサ）を実現するインターフェースシステムが、アプリケーションサーバ１００とユーザシステム１２との間に通信可能に結合されて、アプリケーションサーバ１００に対する要求を分配する。１つの実現において、ロードバランサは、最小接続アルゴリズムを使用して、アプリケーションサーバ１００に対するユーザ要求をルーティングする。ロードバランシングアルゴリズムの他の例、例えば、ラウンドロビン及び観察された応答時間などが、使用されてもよい。例えば、いくつかの例において、同一ユーザからの３つの連続した要求が３つの異なるアプリケーションサーバ１００に至ることがあり、異なるユーザからの３つの要求が同一のアプリケーションサーバ１００に至ることがある。このようにして、例として、システム１６はマルチテナントシステムであり得、このシステム１６は、いろいろなユーザ及び組織にわたる異なるオブジェクト、データ、及びアプリケーションの記憶とこれらに対するアクセスとを扱う。

１つの例示的なストレージ使用事例において、あるテナントが、各販売員がシステム１６を使用して自身の態様を管理するところの販売陣（sales force）を採用する会社であり得る。ユーザは、すべてがユーザ個人の販売プロセスに適用可能である連絡先データ、リードデータ、顧客フォローアップデータ、パフォーマンスデータ、ゴール及び進捗データ等を（例えば、テナントデータベース２２の中に）維持することができる。ＭＴＳ配置の一例において、アクセス、閲覧、修正、報告、送信、算出等すべきデータ及びアプリケーションのすべてが、ネットワークアクセスを超えるものを有さないユーザシステム１２により維持され、アクセスされることができるため、ユーザは、自身の販売努力及びサイクルを多くの種々のユーザシステムのうちいずれかから管理することができる。例えば、販売員が顧客を訪問し、顧客がそのロビーにおいてインターネットアクセスを有する場合、販売員は、ロビーで顧客が到着するのを待つ間に、この顧客に関する重要なアップデートを得ることができる。

各ユーザの雇用主にかかわらず、各ユーザのデータは他のユーザのデータとは別個に記憶できるが、いくつかのデータは、テナントである所与の組織の複数のユーザ又はユーザ全員によって共有されるか又はアクセス可能である組織範囲のデータであってもよい。ゆえに、テナントレベルで割り当てられたシステム１６により管理されるいくつかのデータ構造が存在し得ると同時に、他のデータ構造がユーザレベルで管理されてもよい。ＭＴＳが、あり得る競合他社を含む複数のテナントをサポートすることができるため、ＭＴＳは、データ、アプリケーション、及びアプリケーション使用を別個に保持するセキュリティプロトコルを有してもよい。さらに、多くのテナントが、自身の独自システムを維持するよりもＭＴＳへのアクセスを選ぶ可能性があるため、冗長性、アップタイム、及びバックアップが、ＭＴＳにおいて実現され得るさらなる機能である。ユーザ固有データ及びテナント固有データに加えて、システム１６は、複数のテナントにより使用可能なシステムレベルのデータ又は他のデータをさらに維持してもよい。こうしたシステムレベルのデータには、複数テナント間で共有可能な産業レポート、ニュース、投稿メッセージ等を含むことができる。

いくつかの実現において、ユーザシステム１２（これは、さらにクライアントシステムであり得る）は、アプリケーションサーバ１００と通信して、システム１６からのシステムレベル及びテナントレベルのデータを要求し、更新する。こうした要求及び更新は、１つ以上のクエリをテナントデータベース２２又はシステムデータベース２４に送信することを含んでもよい。システム１６（例えば、システム１６の中のアプリケーションサーバ１００）は、所望の情報にアクセスするように設計された１つ以上のＳＱＬステートメント（例えば、１つ以上のＳＱＬクエリ）を自動的に生成することができる。システムデータベース２４は、データベースからの要求されたデータにアクセスするためのクエリプランを生成してもよい。用語「クエリプラン」は、データベースシステム内の情報にアクセスするために使用される１つ以上のオペレーションを一般に参照する。

各データベースは、所定の又はカスタマイズ可能なカテゴリに合わせられたデータを含む、一組の論理テーブルなどのオブジェクトの集合として一般に見ることができる。「テーブル」はデータオブジェクトの一表現であり、本明細書において、いくつかの実現に従うオブジェクト及びカスタムオブジェクトの概念的説明を簡素化するのに使用されることがある。「テーブル」及び「オブジェクト」は本明細書において置き換え可能に使用され得ることが理解されるべきである。各テーブルは、可視のスキーマの中の列又はフィールドとして論理的に配置された１つ以上のデータカテゴリを一般に含む。テーブルの各行又は要素は、フィールドによって定義された各カテゴリについてのデータのインスタンスを含むことができる。例えば、ＣＲＭデータベースが、名前、住所、電話番号、ファックス番号などの基本的な連絡先情報のフィールドで顧客を説明するテーブルを含んでもよい。別のテーブルが、顧客、プロダクト、販売価格、日付などの情報のフィールドを含む購入注文を記述してもよい。いくつかのＭＴＳ実現において、すべてのテナントによる使用のために、標準のエンティティテーブルが提供されてもよい。ＣＲＭデータベースアプリケーションについて、こうした標準のエンティティには、ケース、アカウント、連絡先、リード、及び機会のデータオブジェクトのテーブルを含み、各々が、予め定義されたフィールドを含んでもよい。本明細書において用いられるとき、用語「エンティティ」もまた、「オブジェクト」及び「テーブル」と置き換え可能に使用されることがある。

いくつかのＭＴＳ実現において、テナントは、カスタムオブジェクトを作成し、記憶することを可能にされ、あるいは、例えばカスタムインデックスフィールドを含むカスタムフィールドを標準のオブジェクトに対して作成することにより、標準のエンティティ又はオブジェクトをカスタマイズすることを可能にされてもよい。WeissmanらによるCUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEMと題され2010年8月17日に発行された、本明細書においてその全体を参照により及びすべての目的のために援用される、本発明の譲受人に譲渡された米国特許第7,779,039号は、マルチテナントデータベースシステムにおいてカスタムオブジェクトを作成し、標準オブジェクトをカスタマイズするためのシステム及び方法を教示している。いくつかの実現において、例えば、すべてのカスタムエンティティデータ行が単一のマルチテナントの物理テーブルに記憶され、このテーブルは組織ごとに複数の論理テーブルを含むことがある。顧客の複数の「テーブル」が実際は１つの大きいテーブルに記憶されること、又は、顧客のデータが他の顧客のデータと同じテーブルに記憶され得ることは、顧客に対して透過的である。

図２は、様々な例示的実施形態に従う、ユーザシステム１２のコンポーネントがデータベースシステム１６のコンポーネントと対話する配置２００を示す。図示されるように、ユーザシステム１２は、図１Ａ及び図１Ｂに関して前に論じられたプロセッサシステム１２Ａ、メモリシステム１２Ｂ、入力システム１２Ｃ、出力システム１２Ｄ、及び通信システム１２Ｅを含むことができる。データベースシステム１６は、図１Ａ及び図１Ｂに関して前に論じられたようにプロセッサシステム１７、ネットワークインターフェース２０、データベース２２、及びプログラムコード２６を含むことができる。

ユーザシステム１２を参照し、メモリシステム１２Ｂは、オペレーティングシステム（ＯＳ）（図示されていない）、環境２０５、アプリケーション２１０、及び１つ以上のデータベース（図示されていない）を含むことができる。ＯＳは、コンピュータハードウェア及びソフトウェアリソースを管理し、ユーザシステム１２のアプリケーションに一般的サービスを提供することができる。ＯＳは、ハードウェアデバイスに対するインターフェースを提供する１つ以上のドライバ及び／又はＡＰＩを含んでもよく、これにより、ＯＳ及びアプリケーション２１０は、ハードウェア機能にアクセスすることが可能になる。いくつかの実施形態において、ＯＳは、２つ以上の別個のアプリケーションを接続し、あるいはＯＳ及び／又はドライバ／ＡＰＩから利用可能なコンポーネントを越えてアプリケーションを下層のハードウェアコンポーネントに接続することができる、ミドルウェアを含んでもよい。ＯＳは、汎用目的オペレーティングシステム、又は、具体的にユーザシステム１２のために書かれ又は適合されたオペレーティングシステムであってもよい。

アプリケーション２１０は、例えば、ユーザシステム１２がスマートフォン、タブレットコンピュータなどのモバイルデバイスで実現されるときなどに、ユーザシステム１２で動作するように設計されたソフトウェアアプリケーションであり得る。アプリケーション２１０を実現するプロセッサシステム１２Ａは、データベース１６からのデータを要求及び取得し、アプリケーション２１０のコンテナ又はウェブブラウザにグラフィカルユーザインターフェース（ＧＵＩ）をレンダリングすることができてもよい。様々な実施形態において、ウェブページ及び／又はＧＵＩは、データ解析ＧＵＩ、例えば、Ｓａｌｅｓｆｏｒｃｅ Ｗａｖｅ^ＴＭダッシュボードなどを含んでもよく、データ解析ＧＵＩは、企業クラウド内又はオンデマンドサービス環境内（例えば、データベースシステム１６内のテナント空間）に存在するデータの視覚的表現を提供することができる。アプリケーション２１０は、環境２０５を用いて開発されるネイティブアプリケーション、ウェブアプリケーション、又はハイブリッドアプリケーション（又は、これらの変形）であり得る。アプリケーション２１０はまた、他のツール／プログラミング言語、例えば本明細書において論じられるものなどで開発され（あるいは、これらと対話するように構成され）てもよい。

環境２０５は、ソフトウェア開発環境（ＳＤＥ）、統合開発環境（ＩＤＥ）、ソフトウェア開発キット（ＳＤＫ）、ソフトウェア開発プラットフォーム（ＳＤＰ）、又は、テナント開発者がテナント空間にアクセスするためのアプリケーション（例えば、アプリケーション２１０）を作成することを可能にする他の同様のプラットフォーム若しくはフレームワークであり得る。実施形態において、環境２０５は、ソースコードエディタ、ビルド自動化ツール、デバッガ、コンパイラ、インタプリタ、及び／又は、アプリケーションを構築することにおいて開発者を支援することができる他の同様のツールを含んでよい。実施形態において、環境２０５は、１つ以上のスキーマ３１３ｂ（例えば、図３参照）を開発及び編集するＧＵＩを提供することができるスキーマビルダをさらに含んでもよく、スキーマ３１３ｂは、１つ以上のデータベースオブジェクトの構造又は他の同様のデータ編成を説明する、グラフ又は他の同様の構造であり得る。スキーマビルダのＧＵＩは、開発者が１つ以上のデータベースオブジェクト内の様々なレコード、フィールド、及び要素間の関係を含むデータモデルを閲覧及び修正することを可能にすることができる。実施形態において、環境２０５は、開発者が１つ以上のアーチファクト（artifacts）３１３（例えば、図３参照）を生成及び修正することを可能にする様々なツール（例えば、モデリング言語アプリケーション等）を提供することができ、アーチファクト３１３には、ユース／ビジネスケース解析、プロジェクト計画、リスクアセスメント等；クラス図；フローチャート；システム図；コンパイルされたソースコード；スキーマ（例えば、拡張マークアップ言語（ＸＭＬ）スキーマ、文書型定義（Document Type Definitions）（ＤＴＤ）、リラクシング（Relax-NG）、スキマトロン（Schematron）、ＸＭＬスキーマ定義（XML Schema Definitions）（ＸＳＤ）等）；オブジェクトモデル（例えば、文書オブジェクトモデル（Document Object Model）（ＤＯＭ）、Ｊａｖａオブジェクトモデル、Ｒｕｂｙオブジェクトモデル等）；及び／又はソースコードに関連づけられた他の同様のアーチファクトを含むことができる。実施形態において、アーチファクト３１３は、さらに又は別法として、ソースコード自体を含んでもよい。

いくつかの実施形態において、環境２０５は、ウェブベース又はクラウドベースの環境であってもよく、この環境は、ネイティブアプリケーション、ウェブアプリケーション、又はハイブリッドアプリケーション（又は、これらの変形）であってもよい。ウェブベース又はクラウドベースの環境２０５は、ＧＵＩを含んでもよく、ＧＵＩは、ユーザシステムにより実現されるウェブブラウザ又はコンテナ内に、バックエンドサービス（例えば、データベースシステム１６、クラウドサービスプロバイダ等）により実現されるＳＤＥ／ＩＤＥ／ＳＤＫ／ＳＤＰをレンダリングする。ＧＵＩは、例えば本明細書に論じられる通信プロトコル及び／又はＡＰＩを用いて、開発者が様々な開発ツールにアクセスすることを可能にすることができる。ウェブベース又はクラウドベースの環境２０５のクライアント側部分は、サーバ側開発ツール及び／又はプログラミング言語、例えばＰＨＰ、Ｎｏｄｅ．ｊｓ、ＡＳＰ．ＮＥＴ、及び／又は、ＨＴＭＬをレンダリングする他の同様の技術などで；ウェブサイト開発ツール及び／又はプログラミング言語、例えばＨＴＭＬ、カスケーディングスタイルシート（ＣＳＳ）、Ｊａｖａｓｃｒｉｐｔ、ＪＱｕｅｒｙなどを用いて；及び／又は、プラットフォーム固有開発ツール及び／又はプログラミング言語（例えば、Ｖｉｓｕａｌｆｏｒｃｅ（登録商標） Ａｎｄｒｏｉｄ（登録商標） Ｓｔｕｄｉｏ^ＴＭ ＩＤＥ、Ａｐｐｌｅ（登録商標） ｉＯＳ（登録商標） ＳＤＫなど）を用いて開発されてもよい。用語「プラットフォーム固有」は、ユーザシステム１２により実現されるプラットフォーム、及び／又はデータベースシステム１６により実現されるプラットフォームを参照することがある。実施形態において、環境２０５は、カリフォルニア州サンフランシスコのｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社により提供されるＦｏｒｃｅ．ｃｏｍ ＩＤＥ（登録商標）であってもよい。

ＯＳ、データベース、環境２０５、及びアプリケーション２１０の適切な実現と、ユーザシステム１２の一般的機能性とは、知られているか又は市販されており、特に本明細書における開示を考慮し、当業者によって容易に実現される。しかしながら、環境２０５は、本明細書に論じられる様々な実施形態に従いブロックチェーン技術を用いて実現されるバージョン制御システム（又は、これらの一部）をさらに含むことができる。

典型的なソフトウェア開発プラットフォームモデルは、分散型バージョン制御システム（ＶＣＳ）、例えばＧＩＴ、マーキュリアル（Mercurial）などを通して、高度に分散化されたワークフローをサポートするように進化している。これらモデルは、ソースコードの完全なビューを開発者の独自のクライアントデバイスに提供することにより、開発者がリモートで作業することを可能にすることができる。このことは、開発者が自由に自身が好きな時間及び場所で作業できるようにするが、こうしたシステムにおける変更に対してガバナンスを強制することは、複雑かつ面倒になる可能性があり、なぜならば、上記ソースコードが、納入されるプロダクトのレコードの完全体系であるように取られるからである。ソフトウェアリリースのためのコードを構成するものに加えて、特定の導出された不変条件（invariants）を維持するために、様々な実施形態が、ソースコードに対してだけでなく、さらにソースコードを更新する／編集するための不変条件ルールに適用できる変更に対しても課される制約を用いて、ローカルに検証できる不変条件を表すように改ざん耐性メカニズムを提供する。

ソースコードを更新する／編集するための不変条件ルールは、追跡及び強制するのに特に重要である可能性があり、例えば、スキーマ進化及びＡＰＩ変更を統制するルールなどであり、なぜならば、ＡＰＩ変更が、これらＡＰＩに対してビルトインの依存関係を有する（例えば、テナントデータにアクセスするためにＡＰＩに依存する）様々なアプリケーション（例えば、テナントデータにアクセスするのに使用されるアプリケーション）に影響する可能性があるからである。アプリケーションのリリースされたインターフェースに対する変更は、該変更が実現又はリリースされた後にこうしたアプリケーションが内部的な一貫性を保有するときでさえ、テナント統合を破壊する可能性があり、回避されるべきである。従来のＶＣＳは、ソースコードの各バージョンに関連づけられたインデックスを記憶することができ、より新しいバージョンが、アプリケーションを破壊し及び／又は他のエラーを含むコードを含むとき、上記インデックスが使用されて、リリースされたソースコードのより古いバージョンに戻ることができる。しかしながら、インデックスが使用される場合でさえ、ソースコードのより古いバージョンは、依然として故意の又は不注意な改ざんにさらされ、このことは、リリースされたアプリケーションがユーザによりインストール及び使用されるまで、問題があることを発見することなく開発者が不変条件ルールを迂回することを可能にすることになる。様々な実施形態において、不変条件ルールの違反は、様々なソフトウェア開発段階の間、例えば接続を切られたビルドプロセスの間などに、立証可能及び強制可能であり得る。実施形態において、ルールの表現は、特定のプロジェクト又はアプリケーションで作業する様々な開発者に分散されることができる。不変条件ルールの配布なしでは、開発者は、その変更が不変条件ルールと調和できないことを認識することなく、相当な期間の時間、ソースコードに対する変更を行う可能性がある。

さらに、様々な実施形態が、リビジョン制御ツリーグラフ（さらに、「ツリー」としても参照される）の分岐上で変更が単調に行われ得ることを提供する。例えば、２以上の開発者が、正当であると独立して決定され得るソースコードに対する変更を行うとき、こうした変更が、並行してプロジェクト又はアプリケーションツリーにアペンドされる場合、これら変更は、バージョンヒストリ内に調和不能なフォークを作成する可能性がある。このことは、２以上のユーザがアプリケーションの異なるバージョンをインストールすることを結果としてもたらす可能性があり、各バージョンは、ツリー内の異なるフォークに基づく。これらバージョンが一緒にマージされるとき、互いに共存することができず、かつユーザのアップグレード可能性に影響することなしに調和できない変更が、存在する可能性があることになる。したがって、実施形態は、例えば、変更が順次的に及び／又はコンセンサスアルゴリズムの影響下で行われることを必要とすることにより、変更が単調に行われるべきであることを提供する。

様々な実施形態において、ブロックチェーン技術が使用されて、ソースコード及び編集／更新ルールが改ざん耐性であり、分散され、単調であることを確保することができる。ブロックチェーン（例えば、ブロックチェーン２１４）は、ブロック（例えば、ブロック２１２）と呼ばれる順序付けられたレコードのリストを維持することができる分散型データベースであってもよく、各ブロックは、ブロックチェーン内の前のブロックに対するリンクを含む。ブロックチェーンは、ブロックの垂直スタックとして視覚化されてもよく、第１のブロック（さらに、「起源ブロック（genesis block）」としても参照される）がスタックの土台の役割を果たすことができ、ブロックの「高さ」が第１のブロックからのブロックの距離を参照することができる。さらに、「トップブロック」又は「最上ブロック」は、ブロックチェーンに対する最も最近の追加であったブロックを参照することができる。

様々な実施形態において、ソフトウェアアーチファクト（例えば、アーチファクト３１３）がパブリックに対してリリースされるとき、検証システム（例えば、ユーザシステム、及び／又は集中型ソースコードリポジトリとして動作するデータベースシステム）によりリリースされるアーチファクトに署名することが、アプリケーション（例えば、アプリケーション２１０）のサーフェスエリアに対する変更とブロックチェーンの公開とのログレコードのブロックをアペンドしてもよい。実施形態において、上記検証システム又は別の検証システムが、すでにアペンドされたブロックに後継ブロックがアペンドされることを可能にせず、単調さを提供してもよい。前のブロックは署名され、ブロックチェーンに含まれるため、検証システムは、変更のヒストリが変造されておらず、ゆえに改ざん耐性であることをさらに提供することができる。しかしながら、ブロックチェーンは、リリースヒストリを横断し、かつそれをアプリケーションに対するソースコードのアクティブ開発バージョンと比較するツールで、パブリックにされ、ローカルの開発ワークスペースにコピーされることがあるため、アプリケーションの完全性に対するチェックは、完全に集中型であるか、完全に分散型であるか、あるいは部分的に集中型であり及び／又は部分的に分散型である方法で、増分的に行われてもよい。

前に論じられたように、実施形態において、環境２０５は、開発者（例えば、ユーザシステム１２のユーザ）がアーチファクト３１３（例えば、図３参照）を生成することを可能にすることができる様々なツールを含み、あるいは該ツールに対するアクセスを提供することができる。プロセッサシステム１２Ａは、（例えば、図３により図示及び説明されるような）アーチファクト３１３、現在ブロック識別子（ｃｂ＿ｉｄ）、前ブロック識別子（ｐｂ＿ｉｄ）、及び／又は他の同様のコンテンツ又は情報をとりわけ含むブロック２１２（例えば、図２により示されるブロック２１２_ｎ＋１）を生成するように、環境２０５を（例えば、環境２０５のプログラムコード及び／又はソフトウェアモジュールを実行することによって）又は別個のブロック生成器（図２に示されていない）を実現することができる。ブロック２１２を生成するために、プロセッサシステム１２Ａは、アーチファクト３１３をシリアル化し、シリアル化されたアーチファクト３１３を暗号化して（encipher）ｃｂ＿ｉｄ及びｐｂ＿ｉｄを取得するように、環境２０５又はブロック生成器を実現することができる。実施形態において、ｃｂ＿ｉｄは、現在のブロックの識別子であり得、これは、暗号ハッシュアルゴリズム、例えば、セキュアハッシュアルゴリズム（ＳＨＡ）２の暗号ハッシュアルゴリズムのセット（例えば、ＳＨＡ‐２２６、ＳＨＡ‐２５６、ＳＨＡ‐５１２等）、ＳＨＡ３等における関数などを用いて生成されたハッシュであってもよい。他のハッシュアルゴリズム又は暗号関数が使用されてもよく、例えば、本明細書に論じられる任意タイプの鍵付き（keyed）若しくは鍵なし（unkeyed）暗号ハッシュ関数及び／又は任意の他の関数などである。ｐｂ＿ｉｄは、ｃｂ＿ｉｄを生成するのに使用されるのと同一又は同様の暗号ハッシュアルゴリズムを用いて生成されるハッシュであってもよく、しかし、前のブロック２１２（「親ブロック」、「前ブロック」などとして参照される）を参照するのに使用されてもよい。こうして、各ブロック２１２をその親ブロック２１２にリンクするＩＤのシーケンスが、起源ブロック２１２まで戻るチェーンを作成し得る。

プロセッサシステム１２Ａは、生成されたブロック２１２を含む要求メッセージ２１１（さらに、「メッセージ２１１」、「ユーザ発行メッセージ２１１」などとしても参照される）を生成するように環境２０５を実現することができ、生成されたブロック２１２を識別されたブロックチェーン２１４に含めるためにメッセージ２１１をデータベースシステム１６に送信するように通信システム１２Ｅを制御することができる。実施形態において、メッセージ２１１（又は、ブロック２１２）は、プロジェクト／特徴／アプリケーション識別子（ＩＤ）、ブロックチェーンＩＤ、テナント若しくは組織ＩＤ（ｏｒｇ＿ｉｄ）、ユーザＩＤ（ｕｓｅｒ＿ｉｄ）、認証クレデンシャル（例えば、鍵情報、デジタル署名、デジタル証明書等）、タイムスタンプ、及び／又は他の同様の識別子若しくは情報をさらに含んでもよい。プロジェクト／特徴／アプリケーションＩＤは、すべてのブロックチェーン２１４にわたりグローバルに一意のＩＤであってもよい。

さらに、プロセッサシステム１２Ａは、例えば、楕円曲線暗号（elliptic curve cryptographic）（ＥＣＣ）アルゴリズム、楕円曲線暗号デジタル署名アルゴリズム（Elliptic Curve cryptography Digital Signature Algorithm）（ＥＣＤＳＡ）、リベスト・シャミア・エーデルマン（Rivest-Shamir-Adleman）（ＲＳＡ）暗号、マークル（Merkle）署名スキーム、高度エンクリプションシステム（advanced encryption system）（ＡＥＳ）アルゴリズム、トリプルデータエンクリプションアルゴリズム（triple data encryption algorithm）（３ＤＥＳ）、前に論じられたＳＨＡのうち任意のもの、及び／又は同様のものを用いて、送信の前にブロック２１２及び／又はメッセージ２１１をデジタル署名し、かつ／あるいはエンクリプトする（encrypt）ことができる。

実施形態において、メッセージ２１１はＨＴＴＰメッセージであってもよく、ブロック２１２はＨＴＴＰメッセージのヘッダ又はボディ部分に位置してもよい。メッセージ２１１を伝達するために他のメッセージタイプが使用されてもよく、例えば、セッション開始プロトコル（ＳＩＰ）メッセージ、セキュアシェル（ＳＳＨ）メッセージ、若しくは図１Ａ〜図１Ｂに関して論じられたインターネットプロトコルメッセージのうち任意のもの、及び／又は具体的にユーザシステム１２とデータベース１６との間で通信するために使用される独占の又はプラットフォーム固有のメッセージタイプなどである。使用されるメッセージタイプ及び／又はエンクリプション方法にかかわらず、メッセージ２１１は、ブロック２１２の立証とブロック２１２をリポジトリ２５１に含めることとのためにデータベースシステム１６に送信されてよい。

データベースシステム１６のネットワークインターフェース２０は、メッセージ２１１を取得し、このメッセージをブロックチェーンエンジン２５０に提供することができ、ブロックチェーンエンジン２５０は、解析のためにメッセージ２１１からブロック２１２を抽出することができる。プログラムコード２６は、データベースシステム１６の様々な機能を実現するために使用されるプログラムコードに追加で、ブロックチェーンエンジン２５０を含むことができる。ブロックチェーンエンジン２５０のプログラムコードを含むプログラムコード２６は、プロセッサシステム１７により実行されてよい。ブロックチェーンエンジン２５０は、ブロックチェーン２１４に含まれるべきブロック２１２を取得し、１つ以上のルール２１５に対してブロック２１２を処理し／評価し、かつ潜在ブロック２１２をブロックチェーン２１４にアペンドする、プログラムコード及び／又はソフトウェアモジュールであり得る。

実施形態において、データベースシステム１６は、複数のユーザシステム１２からの対応するブロック２１２を含む複数のメッセージ２１１を取得することができる。図２により示される例において、ブロックチェーン２１４はブロック２１２_０乃至２１２_ｎを含むことができ、ここでｎは番号である。ブロックチェーン２１４は、「バージョン制御ブロックチェーン」などとして参照されることがある。ユーザシステム１２のユーザは、２１２_ｎの後にブロックチェーン２１４に含めるために、その独自のブロック２１２_ｎ＋１を各々生成することができる。こうした実施形態において、データベースシステム１６は、取得されたブロック２１２を認証し、かつ／あるいは立証し（verify）、ブロック２１４に含めるために競合ブロック２１２間の衝突を解決することができる。立証及び／又は衝突解決には、ブロック２１２のコンテンツを解析することと、ブロック２１２が不変条件ルール２１５（さらに、「ルール２１５」としても参照される）を順守するかどうかを決定することとを含むことができる。

ルール２１５（さらに、「不変条件ルール２１５」、「ブロック検証ルール２１５」、「検証ルール２１５」、「ブロック立証ルール２１５」、「立証ルール２１５」などとしても参照される）は、データ構造又はデータオブジェクト内に説明されるブロック２１２の要件又は基準であり得る。従来のブロックチェーンシステムにおいては、コンセンサスアルゴリズムが使用されて、ブロックチェーンに追加すべきブロックを検証することがある。例えば、ビットコインブロックチェーンは、ブロックを識別することを必要とするプルーフオブワーク（proof-of-work）（ＰｏＷ）システムであり、ブロックは、ＳＨＡ２５６を用いて２回ハッシュされたとき、ターゲット値より小さい数を生み出す。ターゲット値は、ブロックのハッシュ内のリーディングゼロビットの必要数である。

実施形態において、ルール２１５は、コンセンサスアルゴリズムに対して追加で、又は代わりに使用されてよい。ルール２１５は、ブロック２１２がブロックチェーン２１５に追加されるために満たさなければならない要件又は基準であってもよい。いくつかの実施形態において、ルール２１５のいくつかは、ブロック２１２がブロックチェーン２１４に追加され得る前にアーチファクト３１３が満足しなければならない要件又基準であってもよい。こうしたタイプのルール２１５は、「フォーマットルール」、「フォームルール」などとして参照されることがある。例えば、フォームルール２１５は、アーチファクト３１３に含まれなければならない様々なフォーマッティング、命名取り決め、機能タイプ等を含むことができる。実施形態において、フォーマットルール２１５は実行可能コードを含んでもよく、この実行可能コードは、フォーマット問題及び／又はリリース互換性問題のためにアーチファクト３１３を解析するソフトウェアモジュール又はアルゴリズム（例えば、解析手法／機能、システムルール、ポリシー定義等）を含むことができる。

いくつかの実施形態において、ルール２１５のいくつかは、立証デバイス（例えば、集中型ブロックチェーンＶＣＳにおけるデータベースシステム１６、及び／又は分散型ブロックチェーンＶＣＳにおけるユーザシステム１２）がブロック２１２を処理することを完了しなければならないという要件又は基準を含んでもよい。こうしたタイプのルール２１５は、「正当性ルール」、「立証ルール」、「検証ルール」などとして参照されることがある。実施形態において、正当性ルール２１５は実行可能コードを含むことができ、この実行可能コードは、立証手順の間にブロック２１２に適用されるべきソフトウェアモジュール又はアルゴリズム（例えば、ハッシュアルゴリズム、解析手法等）を含むことができる。立証ルール２１５は、例えば、解読された（deciphered）ｐｂ＿ｉｄが正しい形式であり、かつ／あるいは前のブロック２１２を正確に指し示すかどうかを決定すること、後継又は親ブロック２１２（例えば、ブロック２１２_ｎ）が現在のブロック２１２（例えば、ブロック２１２_ｎ＋１）についてすでに作成されたかどうかを決定すること、現在のブロック２１２により示されたリリースされたアプリケーションに対するソースコード変更、追加、及び／又は削除が後方互換性を破壊することになるかどうかを決定すること、及び／又は他の同様のルールを含むことができる。前に論じられた様々なルール２１５が、特定のブロックチェーン２１４のために個々に適合されてもよい。

図示されるように、データベースシステム１６は、ブロックチェーン２１４とブロックチェーン２１４に関連づけられたルール２１５とを記憶するリポジトリ２５１を含む。リポジトリ２５１は、ブロックチェーン技術を用いて同時的なアプリケーション開発により実現された変更を統合し、かつアプリケーションの異なるバージョンを分離する、データストア又はストレージシステムであり得る。図２は、単一のブロックチェーン２１４と単一のルール２１５のセットとを含むリポジトリ２５１を示すが、様々な実施形態において、リポジトリ２５１は、複数のブロックチェーン２１４と関連づけられたルール２１５とを含んでもよく、個々のブロックチェーン２１４は、１つ以上のテナントのための個々の特徴、プロジェクト、及び／又はアプリケーションを表現することができる。いくつかの実施形態において、リポジトリ２５１は、複数のブロックチェーン２１４を含むアプリケーションツリー構造を含んでもよく、各ブロックチェーン２１４は、アプリケーションツリー構造の分岐である。こうした実施形態において、各ブロックチェーン２１４は、個々の開発チーム又は他の同様のユーザグループにより生み出された／開発されたソースコードリビジョンを含むことができる。例えば、第１のブロックチェーン２１４が、第１のリリース日付にリリースされるべき第１のチームにより開発されたアプリケーションの第１の特徴であってもよく、第２のブロックチェーン２１４が、第２のリリース日付にリリースされるべき第２のチームにより開発されたアプリケーションの第２の特徴であってもよく、以下同様である。実施形態において、リポジトリ２５１は、複数のブロックチェーン２１４をマルチテナント方式で記憶するＭＴＣであってもよく、リポジトリ２５１のハードウェア及びソフトウェアの様々な要素は、１以上の顧客又はテナントにより共有され得る。

実施形態において、ユーザシステム１２Ａのユーザから現在のブロック２１２（例えば、ブロック２１２_ｎ＋１）を受信すると、ブロックチェーンエンジン２５０を実現するプロセッサシステム１７は、メッセージ２１１をデクリプトし（decrypt）、ブロック２１２を解読して、ブロック２１２_ｎ＋１に含まれる情報（例えば、アーチファクト３１３、ｃｂ＿ｉｄ、ｐｂ＿ｉｄ等）を取得することができる。ブロックチェーンエンジン２５０は、次いで、解読されたブロック２１２_ｎ＋１に関連づけられたブロックチェーン２１４に対応するルールを取得するために、要求又はクエリ２１６をリポジトリ２５１に送信することができる。応答において、ブロックチェーンエンジン２５０は、解読されたブロック２１２_ｎ＋１に対応するルール２１５を含む指示２１７を取得することができ、ブロック２１２_ｎ＋１のコンテンツが取得されたルール２１５を順守するかどうかを決定することができる。解読されたブロック２１２_ｎ＋１が、ルール２１５を順守すると決定された場合、ブロックチェーンエンジン２５０は、指示２１８をリポジトリ２５１に送信することができ、これは、ブロック２１２_ｎ＋１と、前のブロック（例えば、ブロック２１２_ｎ）の後にブロック２１２_ｎ＋１をブロックチェーン２１４にアペンドするための命令／コマンドとを含むことができる。ブロック２１２_ｎ＋１がブロックチェーン２１４に追加された後、ブロックチェーンエンジン２５０は、ブロックチェーン２１４に対するブロック２１２_ｎ＋１の追加を示す指示２１９を取得することができる。いくつかの実施形態において、指示２１９は、ブロック２１２_ｎ＋１をブロックチェーン２１４にアペンドすることにおける失敗又はエラーが発生した場合、こうした失敗又はエラーを示してもよい。ひとたび指示２１９がブロックチェーンエンジン２５０により取得されると、ブロックチェーンエンジン２５０を実現するプロセッサシステム１７は、応答メッセージ２２０を生成し、応答メッセージ２２０（さらに、「応答２２０」としても参照される）をブロック２１２をサブミットしたユーザシステム１２に送信するようにネットワークインターフェース２０に命令することができる。実施形態において、応答２２０は、任意タイプのインターネットプロトコルメッセージ、例えば、前に論じられたもの、及び／又は具体的にユーザシステム１２とデータベースシステム１６との間で通信するために使用される独占の又はプラットフォーム固有のメッセージタイプなどであってよい。

ブロックチェーンエンジン２５０が、解読されたブロック２１２_ｎ＋１がルール２１５を順守しないと決定した場合、ブロックチェーンエンジン２５０を実現するプロセッサシステム１７は、ブロック２１２がブロックチェーン２１４にアペンドされなかったと示す応答メッセージ２２０（例えば、拒否メッセージ）と拒否の理由（例えば、正当性ルール２１５の不順守、フォーマットルール２１５の不順守、タイミング問題、処理問題、例えばデクリプション及び／又は解読失敗等）とを生成することができる。ブロックチェーンエンジン２５０により実行される衝突解決メカニズムの例が、図３〜図５に関して図示及び説明される。

応答メッセージ２２０（さらに、「応答２２０」としても参照される）は、ユーザインターフェースデータ２２１を含んでもよい。ユーザインターフェースデータ２２１は、出力システム１２Ｄにより視覚的表現２２２としてコンパイル及びレンダリングされ得る、コンピュータ読取可能な形式の様々なデータ又はデータオブジェクトを含むことができる。様々なデータ又はデータオブジェクトが使用されて、前に論じられた指示２１９及び／又は拒否メッセージを伝達することができる。一例において、ユーザインターフェースデータ２２１は、１つ以上の拡張マークアップ言語（ＸＭＬ）文書、１つ以上のＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（JavaScript Object Notation）（ＪＳＯＮ）文書、及び／又は、ユーザシステム１２によって実現される環境２０５のコンテナ及び／又はブラウザによりデコード及びレンダリングされ得る何らかの他の適切なデータフォーマットであり得る。ひとたび応答２２０がユーザシステム１２により受信されると、環境２０５を実現するプロセッサシステム１２Ａは、ユーザインターフェースデータ２２１を抽出し、視覚的表現２２２を生成することができ、これは、出力システム１２Ｄを用いて表示されてもよい。

図２により示される配置２００は、本明細書に論じられる様々な実施形態を実現するための集中型ＶＣＳの一例であり得る。他の実施形態において、配置２００は、ユーザシステム１２の１つ以上が検証システムとして動作することができる分散型ブロックチェーンＶＣＳであってもよい。こうした実施形態において、検証システムは、ブロックチェーンエンジン２５０のプログラムコードを含むことができ、前に説明された、ブロックチェーンエンジン２５０の機能を実行することができる。こうした実施形態において、検証システムは、前に論じられた様々な正当性及びフォーマット立証手順を実行するためのルール２１５の分散型バージョンと、ブロックチェーン２１４のローカルのコピーとをさらに含むことができる。いくつかの実施形態において、様々な正当性及びフォーマット立証手順は、コンセンサスアルゴリズム、例えば、ＰｏＷアルゴリズム、プルーフオブステーク（proof-of-stake）（ＰｏＳ）アルゴリズム、プルーフオブバーン（proof-of-burn）アルゴリズム、プルーフオブアクティビティ（proof-of-activity）アルゴリズム、プルーフオブキャパシティ（proof-of-capacity）アルゴリズム、実用的ビザンチンフォールトトレランス（practical byzantine fault tolerance）（ＰＢＦＴ）アルゴリズム、リップル（Ripple）プロトコルベースアルゴリズム、及び／又は同様のものなどと関連して実行されてもよい。コンセンサスアルゴリズムは、例えば、新しいルール２１５を採用し、かつ／あるいはルール２１５を変更するため、あるいはユーザシステム１２のユーザのアイデンティティを検証するために、分散型ブロックチェーンＶＣＳにおいて使用されてもよい。

分散型ブロックチェーンＶＣＳの一例において、ユーザシステム１２は、前に説明されたのと同一又は同様の仕方でブロック２１２_ｎ＋１及びメッセージ２１１を生成することができる。ユーザシステム１２は、次いで、メッセージ２１１を、１つ以上の検証システム、例えば、ホワイトリスト登録されたユーザシステム１２、特別な又は管理的な特権を有するユーザシステム１２などにブロードキャストすることができる。次いで、検証システムのいくつか又はすべてが、そのルール２１５のローカルコピーを用いて様々な立証手順を実行することにより、ブロック２１２_ｎ＋１を別個に立証することができる。いくつかの実施形態において、検証システムは、ブロック２１２_ｎ＋１を立証するために、コンセンサスアルゴリズムをさらに使用してもよい（例えば、ＰｏＷシステムにおいてハッシュをチェックするのに費やされるプロセッササイクル数をチェックすること、ＰｏＳシステムにおいてユーザにより作成又は変更されたコード／アーチファクト／スキーマの量をチェックすること等）。こうした実施形態において、使用されるべきコンセンサスアルゴリズムが、メッセージ２１１内に示されてもよい。

正当性／フォーマット立証手順を用いて、検証システムは、ブロック２１２_ｎ＋１が正しく立証されたと示す確認値を生成することができ、確認値を含む確認メッセージ（例えば、メッセージ２２０と同様）を他の検証システムにブロードキャストすることができる。他の検証システムは、次いで、確認メッセージ内の確認値を、検証手順を用いて生成されたその独自の確認値と比較することができる。確認値がマッチする場合、ブロック２１２_ｎ＋１は立証されたとみなされてよく、ひとたびブロック２１２_ｎ＋１が立証されると、各検証システムは、ブロック２１２_ｎ＋１をブロックチェーン２１４にアペンドすることができる。ひとたびブロック２１２_ｎ＋１が検証システムにより正しく検証されると、ブロック２１２_ｎ＋１は他のユーザシステム１２に送信されてもよく、そのため、ブロックチェーン２１４のそのローカルのバージョンに、ブロック２１２_ｎ＋１がアペンドされることができる。

さらに、又は別法として、ひとたびブロック２１２_ｎ＋１が検証システムにより正しく検証されると、ブロック２１２_ｎ＋１は、リポジトリ２５１に記憶するためにデータベースシステム１６に送信されてもよい。こうした実施形態は、「部分分散型ブロックチェーンＶＣＳ」又は「部分集中型ブロックチェーンＶＣＳ」として参照されることがある。

図３は、様々な実施形態に従う、ブロックチェーン２１４のブロック２１２の例示的な要素を示す。図示されるように、各ブロック２１２は、現在ブロック識別子（ｃｂ＿ｉｄ）３０５、前ブロック識別子（ｐｂ＿ｉｄ）３１０、アーチファクト３１３等を含むことができる。

ブロック０ ２１２_０は、ブロックチェーン２１４の起源ブロックであり得る。起源ブロック２１２_０は、ブロックチェーン２１４内のすべてのブロック２１２の共通の祖先であり得る。起源ブロック２１２_０は、アプリケーション又はその一部のオリジナルリリース（例えば、リリース１）のソースコード又はアーチファクト３１３_０を含むことができる。様々な実施形態において、起源ブロック２１２_０は、オリジナルリリースのスキーマ、オブジェクトモデル、又は何らかの他タイプのアーチファクト３１３の視覚的表現、及び／又はオブジェクト及び／又はデータベースオブジェクト間の関係の視覚的表現を含むことができる。起源ブロック２１２_０は、ｃｂ＿ｉｄ_０ ３０５_０とｐｂ＿ｉｄ_０ ３１０_０とをさらに含むことができる。実施形態において、ｃｂ＿ｉｄ_０及びｐｂ＿ｉｄ_０。実施形態において、ｃｂ＿ｉｄ_０ ３０５_０は、起源ブロック２１２_０のコンテンツのハッシュ（例えば、図３により示されるｈａｓｈ（３１３_０））を含むことができる。実施形態において、ｐｂ＿ｉｄ_０ ３１０_０は、起源ブロック識別子（ｇｂ＿ｉｄ）として参照されることがある。実施形態において、ｇｂ＿ｉｄは、起源ブロック２１２_０のコンテンツのハッシュ；所定の数；ゼロの値；ソースコードのタイムスタンプ、アーチファクト３１３_０；ソースコードの作成者に関連づけられたｏｒｇ＿ｉｄ、アーチファクト３１３_０；ソースコードの作成者に関連づけられたｕｓｅｒ＿ｉｄ、アーチファクト３１３_０；及び／又は同様のものであり得る。

実施形態において、ｃｂ＿ｉｄ_０ ３０５_０及びｐｂ＿ｉｄ_０ ３１０_０は、ブロック２１２_０のヘッダ部分に位置してもよく、アーチファクト３１３_０は、ブロック２１２_０のボディ又はペイロード部分に位置してもよい。図３には示されないが、いくつかの実施形態において、ブロック２１２は、ブロック２１２_０のヘッダ部分又はペイロード部分の中にｏｒｇ＿ｉｄ、ｕｓｅｒ＿ｉｄ、特徴／プロジェクト／ソースコードＩＤ、ブロックチェーンＩＤ、認証クレデンシャル、タイムスタンプ、及び／又は同様の情報を含むことができる。

ブロック１ ２１２_１は、アプリケーション又はその一部の第２のリリース（リリース２）のソースコード又はアーチファクト３１３_１を含むブロックであり得る。アーチファクト３１３_１は、起源ブロック２１２_０に含まれる第１のリリースのオリジナルソースコードに対する変更を含むことができる。例えば、アーチファクト３１３_１は、オブジェクトＡの追加フィールドｆを含むことができる。いくつかの実施形態において、ブロック２１２_１は、アーチファクト３１３_１により変造されたオブジェクト及び／又はデータベースオブジェクト間の関係の視覚的表現を含むことができる。ブロック２１２_１は、ｃｂ＿ｉｄ_１ ３０５_１をさらに含むことができ、これは、ブロック２１２のコンテンツのハッシュ（例えば、図３により示されるｈａｓｈ（３１３_１））であり得る。ブロック２１２_１は、ｐｂ＿ｉｄ_１ ３１０_１をさらに含むことができ、これは、前のブロック２１２のｃｂ＿ｉｄ（例えば、図３により示されるｈａｓｈ（３１３_０）又はｃｂ＿ｉｄ_０ ３０５_０）であり得る。ｐｂ＿ｉｄ_１ ３１０_１は、ブロック２１２_１を起源ブロック２１２_０にリンクすることができ、このことは、ブロック１ ２１２_１とブロック０ ２１２_０との間の矢印で示される。

起源ブロック２１２_０と同様に、実施形態において、ｃｂ＿ｉｄ_１ ３０５_１及びｐｂ＿ｉｄ_１ ３１０_１はブロック２１２_１のヘッダ部分に位置してもよく、アーチファクト３１３_１はブロック２１２_１のボディ又はペイロード部分に位置してもよい。さらに、ブロック２１２_１は、ブロック２１２_０と同じタイプのさらなる情報、例えば、ｏｒｇ＿ｉｄ、ｕｓｅｒ＿ｉｄ、特徴／プロジェクト／ソースコードＩＤ、ブロックチェーンＩＤ、認証クレデンシャル、タイムスタンプ、ルートハッシュ又は値（例えば、ｇｂ＿ｉｄ）、及び／又は同様の情報などを、ブロック２１２_１のヘッダ部分又はペイロード部分に含んでもよい。

ブロック２ ２１２‐１_２、２１２‐２_２、及び２１２‐３_２は各々、アプリケーション又はその一部の第３のリリース（例えば、リリース３）のソースコード又は個々のアーチファクト３１３_２を含むブロックであり得る。ブロック２１２‐１_２、２１２‐２_２、及び２１２‐３_２の各々は、ブロック２１２_１の子としてブロックチェーンに含めるために異なるユーザシステム１２によりサブミットされた競合ブロックであり得る。ブロック２１２‐１_２、２１２‐２_２、及び２１２‐３_２の各々は、その独自の対応するアーチファクト３１３_２、スキーマ３１３_２、及びｃｂ＿ｉｄ_２ ３０５_２を含むことができる。ブロック２１２‐１_２、２１２‐２_２、及び２１２‐３_２内のアーチファクト３１３_２が互いに異なるため、これらブロックのｃｂ＿ｉｄ_２ ３０５_２もまた、互いに異なり得る。しかしながら、ブロック２１２‐１_２、２１２‐２_２、及び２１２‐３_２がブロックチェーン２１４内の同じスポットについて競合しているため、各ブロック２１２‐１_２、２１２‐２_２、及び２１２‐３_２内のｐｂ＿ｉｄ_２ ３１０_２は、これらが同じ前のブロック２１２_１を各々指し示すので、同じ値を有し得る。前のブロック２１２_１と同様に、ｐｂ＿ｉｄ_２ ３１０‐１_２は、ブロック２１２‐１_２をブロック２１２_１にリンクすることができ、このことは、ブロック２ ２１２‐１_２とブロック１ ２１２_１との間の矢印で示される。

起源ブロック２１２_０及び前のブロック２１２_１と同様に、実施形態において、ｃｂ＿ｉｄ_２ ３０５_２及びｐｂ＿ｉｄ_２ ３１０_２はブロック２１２_２のヘッダ部分に位置してもよく、アーチファクト３１３_２はブロック２１２_２のボディ又はペイロード部分に位置してもよい。さらに、ブロック２１２_２は、ブロック２１２_０及び２１２_１と同じタイプのさらなる情報、例えば、ｏｒｇ＿ｉｄ、ｕｓｅｒ＿ｉｄ、特徴／プロジェクト／ソースコードＩＤ、ブロックチェーンＩＤ、認証クレデンシャル、タイムスタンプ、及び／又は同様の情報などを、ブロック２１２_１のヘッダ部分又はペイロード部分に含んでもよい。いくつかの実施形態において、ブロック２１２_２は、ルート又はトップハッシュ、例えばｇｂ＿ｉｄ及び／又は同様のものなどをさらに含んでもよい。

図３により示される例は、ブロック２１２‐１_２と２１２‐２_２との間の一例示的な「レース状態」を含む。レース状態は、これらブロックが同様の時間にサブミットされることに基づいてもよく、一例として、ブロック２１２‐１_２は、（例えば、２１２‐１_２内のタイムスタンプで示されるように）ブロック２１２‐２_２の前に検証され、あるいは作成されている。このシナリオにおいて、ブロック２１２‐２_２は、ブロックチェーン２１４にアペンドされることを拒否されることがあり（図３の「Ｘ」矢印で示される）、なぜならば、ブロック２１２‐１_２がブロック２１２_１に対する後継ブロックとしてすでに作成されたからである。

図３に示される例は、ブロック２１２‐１_２と２１２‐３_２との間の不変条件変更／衝突状態をさらに含む。不変条件変更状態は、ユーザ／開発者が前のブロック２１２との後方互換性を破壊し得る方法でソースコード、アーチファクト３１３_２を変造しようとすることに基づいてもよい。図３に示される例において、ブロック２１２‐３_２は、さらなるアーチファクト３１３‐３_２「ｍ→ｍ（Ｓｔｒｉｎｇ）；」を含み得る。このシナリオにおいて、ブロック２１２‐３_２は、ブロックチェーン２１４にアペンドされることを拒否されることがあり（図３において「Ｘ」矢印で示される）、なぜならば、さらなるアーチファクト３１３‐３_２が、後方互換性破壊を結果としてもたらす可能性があるからである。

図４〜図５は、様々な例示的実施形態に従う、処理４００及び５００をそれぞれ示す。例示目的のために、処理４００〜５００の動作は、検証システムにより実行されているものとして説明され、該検証システムは、図１Ａ〜図１Ｂ及び図２に関して論じられたデータベースシステム１６及び／又はユーザシステム１２であり得る。しかしながら、多数の実現、配置、及び／又は環境において、他のコンピューティングデバイスが処理４００〜５００を動作させてもよいことが留意されるべきである。実施形態において、検証システムはプログラムコードを含むことができ、このプログラムコードは、プロセッサシステムにより実行されると、処理４００〜５００の様々な動作を検証システムに実行させる。動作の特定の例及び順序が図４〜図５に示されるが、様々な実施形態において、これら動作は再度順序付けられてもよく、さらなる動作に分離されてもよく、組み合わせられてもよく、あるいは完全に省略されてもよい。

図４は、様々な実施形態に従う、ブロックチェーン２１４に追加されるべきブロック２１２を生成する処理４００を示す。処理４００は動作４０５で開始することができ、動作４０５において、検証システムのプロセッサシステムが、ソースコード、アーチファクト３１３を取得することができる。検証システムがデータベースシステム１６である実施形態において、プロセッサシステム１７により実現されるブロックチェーンエンジン２５０が、ネットワークインターフェース２０を介してユーザシステム１２により送信されたメッセージ内のソースコード、アーチファクト、オブジェクトモデル、スキーマ等を取得することができる。こうした実施形態において、ユーザシステム１２のプロセッサシステム１２Ａが、環境２０５を実現することにより上記メッセージを生成し、送信することができる。検証システムがユーザシステム１２である実施形態においては、プロセッサシステム１２Ａにより実現されるブロックチェーンエンジン２５０が、例えば、ＡＰＩを介して環境２０５から、ソースコード、アーチファクト３１３を取得することができる。

動作４１０において、検証システムのプロセッサシステムは、ソースコード、アーチファクト、オブジェクトモデル、スキーマ等をシリアル化して、シリアル化されたデータを取得することができる。上記シリアル化は、ソースコード、アーチファクト、オブジェクトモデル、スキーマ等を、例えばデータベースオブジェクト、ファイル、バッファ等に記憶できるフォーマットに、及び／又はネットワーク１４を通じた送信のためにパケットフォーマットに、フォーマットすること又は翻訳することを含むことができる。

動作４１５において、検証システムのプロセッサシステムは、シリアル化されたデータを暗号化して、ｃｂ＿ｉｄ３０５を取得することができる。実施形態において、動作４１５は、シリアル化されたデータを、ハッシュ関数又は他の同様のアルゴリズム、例えば本明細書において論じられたものなどに入力することを含んでもよく、上記ハッシュ関数又は他の同様のアルゴリズムは、暗号又はコードを文字ストリング又は数として出力することができる。

動作４２０において、検証システムのプロセッサシステムは、ｃｂ＿ｉｄ３０５を含むようにブロック２１２を生成することができる。動作４２５において、検証システムのプロセッサシステムは、生成されたブロック２１２が起源ブロック２１２であるか否かを決定することができる。このことは、ソースコード、アーチファクト、オブジェクトモデル、スキーマ等の中からの指示、及び／又は環境２０５を通して取得される指示に基づいてもよい。動作４２５において、検証システムのプロセッサシステムが、生成されたブロック２１２が起源ブロック２１２であると決定した場合、検証システムのプロセッサシステムは動作４３０に進んで、ｇｂ＿ｉｄを取得し、ｇｂ＿ｉｄを生成されたブロック２１２に挿入することができる。このｇｂ＿ｉｄは、前に論じられたｇｂ＿ｉｄと同一又は同様であってもよい。動作４２５において、検証システムのプロセッサシステムが、生成されたブロック２１２が起源ブロック２１２でないと決定した場合、検証システムのプロセッサシステムは動作４３５に進んで、ｐｂ＿ｉｄ３１０を取得し、ｐｂ＿ｉｄを生成されたブロック２１２に挿入することができる。このｐｂ＿ｉｄ３１０は、前に論じられたｐｂ＿ｉｄ３１０と同一又は同様であってもよい。実施形態において、動作４２０〜４３５は、ｃｂ＿ｉｄ３０５、ｐｂ＿ｉｄ３１０、又はｇｂ＿ｉｄを、生成されたブロック２１２のヘッダ部分に挿入することを含んでもよい。

動作４３０又は４３５を実行した後、検証システムのプロセッサシステムは動作４４０に進んで、シリアル化されたデータを、生成されたブロック２１２に挿入することができる。シリアル化されたデータは、生成されたブロック２１２のボディ又はペイロード部分に挿入されてもよい。実施形態において、動作４４０及び／又は動作４３０〜４３５は、他の情報、例えば、タイムスタンプ、前に論じられた１つ以上の識別子、コンセンサスアルゴリズムなどを、ブロック２１２のヘッダ又はペイロード部分に挿入することをさらに含んでもよい。動作４４５において、検証システムのプロセッサシステムは、図２に関して論じられたメッセージ２１１を生成することができ、生成されたブロック２１２をメッセージ２１１に挿入することができる。さらに、又は別法として、様々な実施形態において、動作４４５は、他の情報、例えば、タイムスタンプ、前に論じられた１つ以上の識別子、コンセンサスアルゴリズムなどを、メッセージ２１１のヘッダ又はペイロード部分に挿入することをさらに含んでもよい。動作４５０において、検証システムのプロセッサシステムは、既知の手順に従ってメッセージ２１１（又は、メッセージ２１１のコンテンツ）をエンクリプトし、かつ／あるいはデジタル署名することができる。

動作４５５において、検証システムのプロセッサシステムは、ブロック２１２の立証のための、エンクリプトされたメッセージ２１１の別の検証システムに対する送信を制御することができる。検証システムがユーザシステム１２である実施形態において、プロセッサシステム１２Ａにより実現されるブロックチェーンエンジン２５０が、メッセージ２１１を送信するように通信システム１２Ｅを制御することができる。検証システムがデータベースシステム１６である実施形態においては、プロセッサシステム１７により実現されるブロックチェーンエンジン２５０が、ブロック２１２を別の検証システムに送信することなく、立証手順をそれ自体で実行することができる。さらに、又は別法として、プロセッサシステム１７により実現されるブロックチェーンエンジン２５０は、メッセージ２１１を別の検証システムに送信するようにネットワークインターフェース２０に命令してもよい。一例示的な立証手順が、図５に関して図示され、説明される。動作４５５の実行の後、処理４００は終了してもよく、あるいは必要に応じて繰り返してもよい。

図５は、様々な他の実施形態に従う、バージョン制御ブロックチェーン２１４に含めるためにブロック２１２を立証する処理５００を示す。処理５００は動作５０５で開始することができ、動作５０５において、検証システムのプロセッサシステムが、ブロックチェーン２１４に追加されるべきブロック２１２（さらに、「潜在ブロック２１２」などとしても参照される）を含むメッセージを取得することができる。動作５１０において、検証システムのプロセッサシステムは、メッセージ２１１（又は、メッセージ２１１のコンテンツ）をデクリプトして、潜在ブロック２１２を取得することができる。

動作５１５において、検証システムのプロセッサシステムは、潜在ブロック２１２を解読して、第１の値を取得することができる。いくつかの実施形態において、第１の値は、潜在ブロック２１２のヘッダ部分に含まれるｐｂ＿ｉｄ３１０であり得る。いくつかの実施形態において、第１の値は、潜在ブロック２１２に含まれる様々な識別子又は情報、例えば前に論じられた様々な識別子／情報などの、組み合わせであってもよい。動作５２０において、検証システムのプロセッサシステムは、ブロックチェーン２１４内の最上ブロック２１２に含まれるコンテンツに基づいて第２の値を生成することができる。実施形態において、プロセッサシステムは、潜在ブロック２１２の第１の値に基づいて最上ブロック２１２から第２の値を取得してもよい。例えば、第１の値が、潜在ブロック２１２のヘッダ部分に含まれるｐｂ＿ｉｄ３１０であるとき、第２の値は、最上ブロック２１２のヘッダ部分に含まれるｃｂ＿ｉｄ３０５であってもよい。

動作５２５において、検証システムのプロセッサシステムは、第１の値が第２の値に等しいかどうかを決定することができる。こうして、検証システムのプロセッサシステムは、潜在ブロック２１２が最上ブロック２１２に十分にリンクされているかどうかを決定することができる。動作５２５において、検証システムのプロセッサシステムが、第１の値が第２の値に等しくないと決定した場合、検証システムのプロセッサシステムは動作５６５に進んで、拒否メッセージを生成し、潜在ブロック２１２を提供したシステムに送信することができる。

動作５２５において、検証システムのプロセッサシステムが、第１の値が第２の値に等しいと決定した場合、検証システムのプロセッサシステムは動作５３０に進んで、ルール２１５を取得し、ブロック２１２に対して立証手順を実行することができる。立証手順は、潜在ブロック２１２に含まれるシリアル化されたデータのフォーマットが様々なフォーマッティングルールを順守するかどうかを決定すること、及び／又は、様々な互換性ルールを順守するかどうかを決定することなどを含んでもよい。いくつかの実施形態において、立証手順は、シリアル化されたデータをシリアル化解除すること（de-serializing）を含んでもよい。実施形態において、シリアル化されたデータは、動作５１５において潜在ブロック２１２が解読されたときに取得されてもよい。さらに、いくつかの実施形態において、動作５２０及び５２５は、立証手順の一部であるとみなされてもよい。

動作５３５において、検証システムのプロセッサシステムは、動作５３０において実行された立証手順に基づいて、潜在ブロック２１２が正当なブロック２１２であるか、あるいはその他の方法で正しく立証されているかどうかを決定することができる。動作５３５において、検証システムのプロセッサシステムが、潜在ブロック２１２が正当ブロック２１２でないと決定した場合、検証システムのプロセッサシステムは動作５６５に進んで、拒否メッセージを生成し、潜在ブロック２１２を提供したシステムに送信することができる。

動作５３５において、検証システムのプロセッサシステムが、潜在ブロック２１２が正当ブロック２１２であると決定した場合、検証システムのプロセッサシステムは動作５４０に進んで、確認メッセージを生成し、他の検証システムにブロードキャストすることができる。いくつかの実施形態において、確認メッセージは、確認値を含んでもよい。実施形態において、確認値は、第１の値と第２の値とが互いにマッチしたこと（例えば、動作５１５〜５２５参照）を示す数、文字、ストリング等であってもよく、他の実施形態において、確認メッセージが、第１の値及び／又は第２の値を含んでもよい。様々な実施形態において、確認メッセージは、潜在ブロック２１２が検証システムにより正しく立証されたと示す任意の情報を含むことができる。

動作５４５において、検証システムのプロセッサシステムは、別の検証システムにより生成された別の確認メッセージの受信を制御することができる。実施形態において、別の確認メッセージは、動作５０５〜５４０に関して前に論じられたのと同一又は同様の仕方で、別の検証システムにより生成され、ブロードキャストされてもよい。検証システムがユーザシステム１２である実施形態において、プロセッサシステム１２Ａにより実現されるブロックチェーンエンジン２５０が、確認メッセージを受信するように通信システム１２Ｅを制御することができる。検証システムがデータベースシステム１６である実施形態においては、プロセッサシステム１７により実現されるブロックチェーンエンジン２５０が、確認メッセージを受信するようにネットワークインターフェース２０を制御することができる。

動作５５０において、検証システムのプロセッサシステムは、別の確認メッセージに含まれる別の確認値が、動作５４０において確認メッセージで送信された確認値にマッチするかどうかを決定することができる。動作５５０において、検証システムのプロセッサシステムが、別の確認メッセージに含まれる別の確認値が、確認メッセージで送信された確認値にマッチしないと決定した場合、検証システムのプロセッサシステムは動作５６５に進んで、拒否メッセージを生成し、潜在ブロック２１２を提供したシステムに送信することができる。

動作５５０において、検証システムのプロセッサシステムが、別の確認メッセージに含まれる別の確認値が、確認メッセージで送信された確認値にマッチすると決定した場合、検証システムのプロセッサシステムは動作５５５に進んで、潜在ブロック２１２をブロックチェーン２１４にアペンドすることができる。検証システムがデータベースシステム１６である実施形態において、プロセッサシステム１７により実現されるブロックチェーンエンジン２５０が、潜在ブロック２１２をリポジトリ２１５に、リポジトリ２１５に記憶されたブロックチェーン２１４に潜在ブロックを追加するための命令と共に提供することができる。検証システムがユーザシステム１２である実施形態においては、プロセッサシステム１２Ａにより実現されるブロックチェーンエンジン２５０が、潜在ブロック２１２を、ブロックチェーン２１４のローカルの記憶されたバージョンにアペンドすることができる。いくつかの実施形態において、ブロックチェーン２１４のローカルのバージョンは、ローカルのソースコードリポジトリに記憶されてもよく、これは、前に論じられたリポジトリ２１５と同一又は同様であってもよい。

動作５６０において、検証システムのプロセッサシステムは、検証メッセージを生成し、潜在ブロック２１２を提供したシステム及び／又はネットワーク内の他のシステムに送信することができる。いくつかの実施形態において、例えば集中型ブロックチェーンＶＣＳ実現などにおいて、検証メッセージは、潜在ブロック２１２がブロックチェーン２１４に追加されたと示すことにより、確認の役割を単に果たしてもよい。いくつかの実施形態において、例えば分散型ブロックチェーンＶＣＳ及び／又は部分分散型ブロックチェーンＶＣＳ実現などにおいて、検証メッセージは、ネットワーク内の他のシステムに対しての、潜在ブロック２１２をブロックチェーン２１４のそのローカルのバージョンに追加するための、命令の役割を果たしてもよい。動作５６０又は動作５６５の実行の後、処理５００は終了してもよく、あるいは必要に応じて繰り返してもよい。

本明細書に論じられる実現の特定の態様の特定の詳細は、開示される実現の主旨及び範囲から逸脱することなしに任意の適切な仕方で組み合わせられてもよい。しかしながら、他の実現が、各個々の態様に関する特定の実現、又はこれら個々の態様の特定の組み合わせに向けられてもよい。さらに、開示された例は本明細書において、複数のテナントをサポートすることができるオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するシステムにおいてオンデマンドデータベースサービス環境が実現される実現を参照してしばしば説明されるが、本実現は、マルチテナントデータベース又はアプリケーションサーバ上の展開に限定されない。実現は、請求される実現の範囲から逸脱することなく、他のデータベースアーキテクチャ、すなわちＯＲＡＣＬＥ（登録商標）、ＩＢＭ（登録商標）によるＤＢ２（登録商標）などを用いて実践されてもよい。

さらに、開示された実現のいくつかは、制御論理の形式を含め、かつモジュール方式又は統合された方式のハードウェア又はソフトウェアを用いて、様々なタイプのハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせの形式で具現化できることが理解されるべきである。ハードウェア、並びにハードウェア及びソフトウェアの組み合わせを用いて、他の方法又はメソッドが可能である。さらに、本出願において説明されたソフトウェアコンポーネント又は関数のうち任意のものが、例えば、既存の又はオブジェクト指向の手法を用いて、任意の適切なコンピュータ言語、例えばＪａｖａ、Ｃ＋＋、又はＰｅｒｌなどを用いて、１つ以上のプロセッサにより実行されるソフトウェアコードとして実現されてもよい。ソフトウェアコードは、コンピュータ若しくはプロセッサ実行可能命令又はコマンドとして、物理的な非一時的なコンピュータ読取可能媒体に記憶されてもよい。適切な媒体の例には、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、磁気媒体、例えばハードドライブ若しくはフロッピーディスクなど、若しくは光学媒体、例えばコンパクトディスク（ＣＤ）若しくはＤＶＤ（デジタル多用途ディスク）など、フラッシュメモリ、及び同様のもの、又は上記記憶若しくは送信デバイスの任意の組み合わせが含まれる。

ソフトウェア／プログラムコードをエンコードされたコンピュータ読取可能媒体は、互換性のあるデバイスと共にパッケージ化されてもよく、あるいは他のデバイスから別個に（例えば、インターネットダウンロードを介して）提供されてもよい。任意のこうしたコンピュータ読取可能媒体が、単一のコンピューティングデバイス又はコンピュータシステム全体に又はこれらの中に存在してもよく、システム又はネットワーク内の他のコンピュータ読取可能媒体の間にあってもよい。コンピュータシステム、又は他のコンピューティングデバイスが、本明細書において言及された結果のうち任意のものをユーザに提供するモニタ、プリンタ、又は他の適切なディスプレイを含んでもよい。

いくつかの実現が本明細書において説明されたが、これらは限定でなく単に例として提示されたことが理解されるべきである。ゆえに、本出願の広さ及び範囲は、本明細書に説明された実現のいずれによっても限定されるべきでなく、下記の及び後に提出される請求項並びにその均等物に従ってのみ定義されるべきである。

Claims (20)

1. バージョン制御ブロックチェーンを実現するコンピュータプログラムであって、
   ソースコード又は前記ソースコードに関連づけられたアーチファクトを取得し、
   前記ソースコード又は前記アーチファクトをシリアル化してシリアル化されたデータを取得し、
   前記シリアル化されたデータを暗号化して現在ブロック識別子（ｃｂ＿ｉｄ）を取得し、
   ブロックを生成して前記ｃｂ＿ｉｄを含め、
   前記生成されたブロックを前記バージョン制御ブロックチェーンに追加する
   ように動作可能な命令セットを含むコンピュータプログラム。
2. 前記生成されたブロックが起源ブロックでないとき、前記命令セットは、
   前記バージョン制御ブロックチェーン内の前のブロックの前ブロック識別子（ｐｂ＿ｉｄ）を取得し、
   前記ブロックの生成において前記ｐｂ＿ｉｄを前記ブロックに挿入する
   ように動作可能である、請求項１に記載のコンピュータプログラム。
3. 前記命令セットは、
   前記暗号化されたシリアル化されたデータと前記ｐｂ＿ｉｄとを前記ブロックのヘッダセクションに挿入し、
   前記シリアル化されたデータを前記ブロックのペイロードセクションに挿入する
   ように動作可能である、請求項２に記載のコンピュータプログラム。
4. 前記ｐｂ＿ｉｄは、前記前のブロックの暗号化されたコンテンツを含む、請求項２に記載のコンピュータプログラム。
5. 前記ブロックが前記起源ブロックであるとき、前記命令セットは、
   前記ブロックの生成において起源ブロック識別子（ｇｂ＿ｉｄ）を前記ブロックに挿入することであって、前記ｇｂ＿ｉｄは所定の数、ゼロの値、前記ソースコード若しくは前記アーチファクトのタイムスタンプ、前記ソースコード若しくは前記アーチファクトの作成者に関連づけられた組織識別子、又は前記ソースコード若しくは前記アーチファクトの作成者に関連づけられたユーザ識別子であり、
   コンセンサスアルゴリズムを前記ブロックに挿入する
   ように動作可能である、請求項２に記載のコンピュータプログラム。
6. 前記命令セットは、前記ｐｂ＿ｉｄ又は前記ｇｂ＿ｉｄの前記ブロックへの挿入の後、メッセージを生成し、
   前記ブロックの前記メッセージへの挿入の後、前記メッセージをエンクリプトし、
   前記ブロックの前記バージョン制御ブロックチェーンへの追加の前、検証のために前記エンクリプトされたメッセージを別のデバイスに送信する
   ように動作可能である、請求項５に記載のコンピュータプログラム。
7. 前記命令セットは、
   別のメッセージを取得し、
   前記別のメッセージをデクリプトして別のブロックを取得し、
   前記別のブロックを検証し、
   前記別のブロックが正しく検証されたとき、前記別のブロックを前記バージョン制御ブロックチェーンに追加する
   ように動作可能である、請求項１に記載のコンピュータプログラム。
8. 前記別のブロックを検証するために、前記命令セットは、
   前記別のブロックから第１の値を取得し、
   前記バージョン制御ブロックチェーンの最上ブロックに基づいて第２の値を生成し、
   前記第１の値が前記第２の値に等しいとき、前記別のブロックが正当であると示す
   ように動作可能である、請求項７に記載のコンピュータプログラム。
9. ブロックチェーンバージョン制御システムを実現するデータベースシステムであって、
   ユーザシステムからメッセージを取得するネットワークインターフェースであって、前記メッセージはバージョン制御ブロックチェーンに追加されるべき潜在ブロックを含み、前記潜在ブロックのコンテンツはソースコード、前記ソースコードに関連づけられたアーチファクト、又は前記ソースコードに関連づけられたスキーマを含む、ネットワークインターフェースと、
   前記潜在ブロックから第１の値を決定し、
   前記バージョン制御ブロックチェーン内の最上ブロックから第２の値を取得し、
   ブロック立証ルールに基づいて前記ブロックチェーンのコンテンツを立証し、
   前記第１の値が前記第２の値にマッチし、かつ前記ブロックの前記コンテンツが正しく立証されたとき、前記潜在ブロックを前記バージョン制御ブロックチェーンに追加する
   プロセッサシステムと、
   を含むデータベースシステム。
10. 前記第１の値を決定するために、前記プロセッサシステムは、
    前記潜在ブロックをデクリプトして前記潜在ブロックのヘッダ部分内の前ブロック識別子（ｐｂ＿ｉｄ）を取得し、前記潜在ブロック内の前記ｐｂ＿ｉｄは前のブロックのハッシュ値を含む、
    請求項９に記載のデータベースシステム。
11. 前記第２の値を取得するために、前記プロセッサシステムは、
    前記最上ブロックのヘッダ部分から現在ブロック識別子（ｃｂ＿ｉｄ）を取得する、
    請求項１０に記載のデータベースシステム。
12. データストレージデバイスにより実現されたソースコードリポジトリ、をさらに含み、前記ソースコードリポジトリは前記バージョン制御ブロックチェーンを記憶する、
    請求項９に記載のデータベースシステム。
13. 前記潜在ブロックを前記バージョン制御ブロックチェーンに追加するために、前記プロセッサシステムは、
    前記潜在ブロックを前記ソースコードリポジトリに提供し、
    前記潜在ブロックを前記バージョン制御ブロックチェーンにアペンドするように前記ソースコードリポジトリに命令する、
    請求項１２に記載のデータベースシステム。
14. 前記プロセッサシステムは、
    前記ソースコードリポジトリから前記ブロック立証ルールを取得し、
    前記潜在ブロックを解読して前記潜在ブロックの前記コンテンツを取得する、
    請求項１２に記載のデータベースシステム。
15. 前記ブロック立証ルールはフォーマットルールを含み、前記潜在ブロックを立証するために、前記プロセッサシステムは、
    前記潜在ブロックの前記コンテンツが前記フォーマットルールを順守するかどうかを決定するように解析機能を実現する、
    請求項１４に記載のデータベースシステム。
16. ブロックチェーンバージョン制御システムを実現するユーザシステムであって、
    アプリケーションを開発する環境を実現するプロセッサシステムであり、前記環境は、
    １つ以上のユーザ入力に基づいて、ソースコード、前記ソースコードに関連づけられたアーチファクト、又は前記ソースコードに関連づけられたスキーマを取得し、
    前記ソースコード、前記アーチファクト、又は前記スキーマをシリアル化して、シリアル化されたデータを取得し、
    前記シリアル化されたデータを暗号化して現在ブロック識別子（ｃｂ＿ｉｄ）を取得し、
    バージョン制御ブロックチェーン内の前のブロックの前ブロック識別子（ｐｂ＿ｉｄ）を取得し、
    ブロックを生成して前記ｃｂ＿ｉｄ、前記ｐｂ＿ｉｄ、及び前記シリアル化されたデータを含める
    ように動作可能である、プロセッサシステムと、
    バージョン制御ブロックチェーンに含めるために前記生成されたブロックを検証システムに送信する通信システムと、
    を含むユーザシステム。
17. 前記プロセッサシステムは、
    前記ｃｂ＿ｉｄ及び前記ｐｂ＿ｉｄを前記ブロックのヘッダセクションに挿入し、
    前記シリアル化されたデータを前記ブロックのペイロードセクションに挿入する
    ように前記環境を実現する、請求項１６に記載のユーザシステム。
18. 前記プロセッサシステムは、
    前記ｐｂ＿ｉｄ及び前記ｃｂ＿ｉｄの前記ブロックへの挿入の後、前記メッセージを生成し、
    前記ブロックの前記メッセージへの挿入の後、前記メッセージをエンクリプトする
    ように前記環境を実現する、請求項１７に記載のユーザシステム。
19. 前記プロセッサシステムは、
    別のメッセージを取得し、
    前記別のメッセージをデクリプトして前記別のメッセージ内の別のブロックのコンテンツを取得し、
    前記別のブロックの前記コンテンツを立証し、
    前記別のブロックが正しく立証されたとき、前記別のブロックを前記バージョン制御ブロックチェーンのローカルに記憶されたバージョンに追加する
    ように前記環境を実現する、請求項１６に記載のユーザシステム。
20. 前記別のブロックの前記コンテンツを立証するために、前記プロセッサシステムは、
    前記別のブロックのヘッダ部分から別のｐｂ＿ｉｄを取得し、
    前記バージョン制御ブロックチェーンの最上ブロックのヘッダ部分から別のｃｂ＿ｉｄを取得し、
    前記別のｐｂ＿ｉｄが前記別のｃｂ＿ｉｄに等しいとき、前記別のブロックが正当であると示す
    ように前記環境を実現する、請求項１９に記載のユーザシステム。
    

Images