特許 6280123 マルチドメインアイデンティティ管理システム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6280123

(24)【登録日】2018年1月26日

(45)【発行日】2018年2月14日

(54)【発明の名称】マルチドメインアイデンティティ管理システム

(51)【国際特許分類】

   G06F 21/45 20130101AFI20180205BHJP

   G06F 21/62 20130101ALI20180205BHJP

【ＦＩ】

   G06F21/45

   G06F21/62

【請求項の数】24

【全頁数】81

(21)【出願番号】特願2015-531221(P2015-531221)

(86)(22)【出願日】2013年9月6日

(65)【公表番号】特表2015-531511(P2015-531511A)

(43)【公表日】2015年11月2日

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

(87)【国際公開番号】WO2014039772

(87)【国際公開日】20140313

【審査請求日】2016年9月1日

(31)【優先権主張番号】61/698,463

(32)【優先日】2012年9月7日

(33)【優先権主張国】US

(31)【優先権主張番号】61/698,413

(32)【優先日】2012年9月7日

(33)【優先権主張国】US

(31)【優先権主張番号】61/698,459

(32)【優先日】2012年9月7日

(33)【優先権主張国】US

(31)【優先権主張番号】61/785,299

(32)【優先日】2013年3月14日

(33)【優先権主張国】US

(31)【優先権主張番号】13/838,813

(32)【優先日】2013年3月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】スリニバサン，ウッピリ

(72)【発明者】

【氏名】アソックマル，バスキアマイヤー

【審査官】 岸野 徹

(56)【参考文献】

【文献】 特開２０１２−１０３８４６（ＪＰ，Ａ）

【文献】 特表２００８−５３８２４７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／００５４６２５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００６／０２１８６３０（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／４５

Ｇ０６Ｆ ２１／６２

(57)【特許請求の範囲】

【請求項1】

コンピュータにより実行される方法であって、前記方法は、
共有のアイデンティティ管理システムにより、共有のコンピューティング環境の複数の顧客のうち第１の顧客と関連付けられたユーザのアイデンティティの第１のセットを作成するステップを備え、前記共有のコンピューティング環境は、前記複数の顧客のそれぞれ顧客と関連付けられたユーザにサービスを提供すると、
前記共有のコンピューティング環境下で、前記ユーザのアイデンティティの第１のセットを特定し、かつ前記ユーザのアイデンティティの第１のセットと前記第１の顧客とを関連付けるデータを格納するステップと、
前記第１の顧客と、前記共有のコンピューティング環境内で利用可能な第１の複数のサービスとを関連付けるステップと、
前記第１の複数のサービスと前記第１の顧客との関連付けに基づいて、前記共有のアイデンティティ管理システムにより、前記ユーザのアイデンティティの第１のセットを前記第１の複数のサービス内のすべてのサービスにアクセス可能との決定をするステップと、
前記共有のアイデンティティ管理システムにより、前記複数の顧客の第２の顧客と関連付けられたユーザのアイデンティティの第２のセットを作成するステップと、
前記共有のコンピューティング環境下で、前記ユーザのアイデンティティの第２のセットを特定し、かつ前記ユーザのアイデンティティの第２のセットと前記第２の顧客とを関連付けるデータを格納するステップと、
前記第２の顧客と、前記共有のコンピューティング環境内で利用可能な第２の複数のサービスとを関連付けるステップと、
前記第２の複数のサービスと前記第２の顧客との関連付けに基づいて、前記共有のアイデンティティ管理システムにより、前記ユーザのアイデンティティの第２のセットを前記第２の複数のサービス内のすべてのサービスにアクセス可能との決定をするステップとを備え、
前記第１の複数のサービスは、前記第２の複数のサービスとは異なり、
前記共有のアイデンティティ管理システムは、前記第２の顧客でなく、前記第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記共有のアイデンティティ管理システムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、方法。

【請求項2】

前記共有のアイデンティティ管理システムを介して、（ａ）前記ユーザのアイデンティティの第１のセットの第１のユーザを（ｂ）前記第１の複数のサービスのサブセットに対して第１のアクセス許可にマッピングするステップと、
前記共有のアイデンティティ管理システムを介して、（ｃ）前記ユーザのアイデンティティの第２のセットの第２のユーザを（ｄ）前記第２の複数のサービスのサブセットに対して第２のアクセス許可にマッピングするステップとをさらに含み、
前記ユーザのアイデンティティの第１のセットは、前記第１の顧客である組織の人員のアイデンティティのセットであり、
前記ユーザのアイデンティティの第２のセットは、前記第２の顧客である組織の人員のアイデンティティのセットである、請求項１に記載のコンピュータにより実行される方法。

【請求項3】

前記共有のアイデンティティ管理システムを介して、（ａ）前記ユーザのアイデンティティの第１のセットの第１のユーザを（ｂ）前記第１の複数のサービスのサブセットに対して第１のアクセス許可にマッピングされた第１のロールにマッピングするステップと、
前記共有のアイデンティティ管理システムを介して、（ｃ）前記ユーザのアイデンティティの第２のセットの第２のユーザを（ｄ）前記第２の複数のサービスのサブセットに対して第２のアクセス許可にマッピングされた第２のロールにマッピングするステップとをさらに含む、請求項１または２に記載のコンピュータにより実行される方法。

【請求項4】

前記ユーザのアイデンティティの第１のセットにおけるユーザが、前記サービスの第１のセットでなく、前記サービスの第２のセットにおけるサービスに対するオペレーションを行なうことを防止するステップと、
前記ユーザのアイデンティティの第２のセットにおけるユーザが、前記サービスの第２のセットでなく、前記サービスの第１のセットにおけるサービスに対するオペレーションを行なうことを防止するステップとをさらに含む、請求項１〜３のいずれか一項に記載のコンピュータにより実行される方法。

【請求項5】

前記ユーザのアイデンティティの第１のセットの前記アイデンティティを、顧客により分割されたライトウェイトアクセスプロトコル（ＬＤＡＰ）ディレクトリの第１のパーティション内に格納するステップと、
前記ユーザのアイデンティティの第２のセットの前記アイデンティティを、前記ＬＤＡＰディレクトリの第２のパーティション内に格納するステップとをさらに含む、請求項１〜４のいずれか一項に記載のコンピュータにより実行される方法。

【請求項6】

特定のユーザが、ログインプロセスの一部として、前記特定のユーザがアクセスしようとしている前記共有のコンピューティング環境の特定のビューを識別できるユーザインターフェイス要素を含むユーザインターフェイスを提示するステップをさらに含む、請求項１〜５のいずれか一項に記載のコンピュータにより実行される方法。

【請求項7】

前記複数の顧客の特定の顧客と関連付けられたユーザのセットに対してユーザアイデンティティを追加および削除するための制御を提供するコンソールを提示するステップと、
アイデンティティドメイン管理者から前記コンソールを介してコマンドを受取るステップと、
前記アイデンティティドメイン管理者が所属するユーザの特定のセットを決定するステップと、
前記アイデンティティドメイン管理者により前記コンソールを介して前記ユーザの特定のセットに行なわれるユーザアイデンティティ追加および削除オペレーションを制限するステップとをさらに含む、請求項１〜６のいずれか一項に記載のコンピュータにより実行される方法。

【請求項8】

前記ユーザのアイデンティティの第１のセットの第１のユーザにアイデンティティドメイン管理者ロールを割り当てるステップをさらに含み、前記アイデンティティドメイン管理者ロールは、前記ユーザのアイデンティティの第１のセットにおけるアイデンティティを有する他のユーザにサービス管理者ロールを割り当てる能力を前記第１のユーザに付与し、前記方法はさらに、
アイデンティティドメイン管理者としての前記第１のユーザにより選択された前記ユーザのアイデンティティの第１のセットの第２のユーザに、第１のサービス管理者ロールを割り当てるステップを含み、前記第１のサービス管理者ロールは、前記第１の複数のサービスの第１のサービスを管理する能力を前記第２のユーザに付与し、前記方法はさらに、
前記アイデンティティドメイン管理者としての前記第１のユーザにより選択された前記ユーザのアイデンティティの第１のセットの第３のユーザに、第２のサービス管理者ロールを割り当てるステップを含み、前記第２のサービス管理者ロールは、前記第１の複数のサービスの第２のサービスを管理する能力を前記第３のユーザに付与する、請求項１〜７のいずれか一項に記載のコンピュータにより実行される方法。

【請求項9】

前記ユーザのアイデンティティの第１のセットにおけるユーザアイデンティティを有さないが、前記第１の顧客のアカウントと関連付けられた第１の人から、前記ユーザの第１のセットにおけるユーザアイデンティティを同様に有さない第２の人の電子メールアドレスを受取るステップと、
前記第１の人から、前記第１の人が前記第２の人を指名しているロールを受取るステップと、
前記第２の人の前記電子メールアドレスに、前記ユーザのアイデンティティの第１のセット内のユーザアイデンティティを作成するのに利用可能なウェブベースフォームへのハイパーリンクを含む電子メールメッセージを送信するステップと、
前記ウェブベースフォームを介して前記第２の人が供給した情報に基づいて、前記ユーザのアイデンティティの第１のセットに前記第２の人のアイデンティティを追加するステップと、
前記第２の人の前記アイデンティティに前記ロールを割り当てるステップとをさらに含む、請求項１〜８のいずれか一項に記載のコンピュータにより実行される方法。

【請求項10】

前記サービスの第１のセットに特定のサービスを追加する要求を受取るステップと、
前記要求に応じて前記サービスの第１のセットに前記特定のサービスを追加するステップと、
前記共有のコンピューティング環境内に、前記特定のサービスのタイプに基づいてロールの複数の階層から自動的に選択されたロールの階層を定義するステップとをさらに含む、請求項１〜９のいずれか一項に記載のコンピュータにより実行される方法。

【請求項11】

前記サービスの第１のセットにおけるサービスのインスタンスである特定のサービスインスタンスを、アイデンティティストアの第１のパーティションに結び付けるステップと、
前記特定のサービスインスタンスを、前記複数の顧客のそれぞれの顧客と関連付けられた複数のサービスインスタンスについてのポリシーを格納するポリシーストアの第２のパーティションに結び付けるステップとをさらに含み、
前記第１のパーティションは、前記第１の顧客と関連付けられたアイデンティティのみを含み、
前記第２のパーティションは、前記特定のサービスインスタンスに関係するポリシーのみを含む、請求項１〜１０のいずれか一項に記載のコンピュータにより実行される方法。

【請求項12】

１つ以上のプロセッサに特定されるオペレーションを行なわせることの可能な特定の命令を格納するコンピュータ読取可能ストレージメモリであって、前記特定の命令は、
共有のコンピューティング環境の複数の顧客のそれぞれの顧客と関連付けられたユーザにサービスを提供する前記共有のコンピューティング環境内に複数の顧客対サービス関連付けおよび複数の顧客対ユーザ関連付けを作成する命令と、
前記顧客対サービス関連付けおよび前記顧客対ユーザ関連付けに基づいて、前記共有のコンピューティング環境の複数のユーザの各特定のユーザ毎に、前記特定のユーザがアクセスを許可されるサービスのサブセットを決定する命令と、
前記複数の顧客対サービス関連付けの特定の顧客対サービス関連付けにサービスインスタンスを追加する命令と、
前記サービスインスタンスと、前記顧客対ユーザ関連付けの各々からのユーザについて
のアイデンティティを格納するアイデンティティストアの特定のパーティションとを関連付けるデータを格納する命令と、
前記サービスインスタンスと、前記顧客対サービス関連付けの各々からのサービスインスタンスについてのポリシーを格納するポリシーストアの特定のパーティションとを関連付けるデータを格納する命令と、
前記複数の顧客の第２の顧客でなく、前記複数の顧客の第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供する共有のアイデンティティ管理システムを提供する命令とを含み、
前記共有のアイデンティティ管理システムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、コンピュータ読取可能ストレージメモリ。

【請求項13】

装置であって、前記装置は、
１つ以上のプロセッサと、
特定の命令を格納するコンピュータ読取可能ストレージメモリとを備え、前記特定の命令は、
共有のコンピューティング環境の複数の顧客のそれぞれの顧客と関連付けられたユーザにサービスを提供する前記共有のコンピューティング環境下でシングルアイデンティティ管理（ＩＤＭ）システムを確立させる命令と、
前記シングルＩＤＭシステムに、前記共有のコンピューティング環境の第１の顧客と関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供させる命令と、
前記シングルＩＤＭシステムに、前記共有のコンピューティング環境の第２の顧客と関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供させる命令と、
前記シングルＩＤＭシステムに、前記第１の顧客と関連付けられたユーザが前記第２のサービスインスタンスにアクセスすることを防止させる命令と、
前記シングルＩＤＭシステムに、前記第２の顧客と関連付けられたユーザが前記第１のサービスインスタンスにアクセスすることを防止させる命令とを備え、
前記シングルＩＤＭシステムは、前記第２の顧客でなく、前記第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記シングルＩＤＭシステムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、装置。

【請求項14】

１つ以上のプロセッサに特定されるオペレーションを行わせるコンピュータ読取可能プログラムであって、前記コンピュータ読取可能プログラムは、
共有のコンピューティング環境の複数の顧客のそれぞれの顧客と関連付けられたユーザにサービスを提供する前記共有のコンピューティング環境内に複数の顧客対サービス関連付けおよび複数の顧客対ユーザ関連付けを作成する命令と、
前記顧客対サービス関連付けおよび前記顧客対ユーザ関連付けに基づいて、前記共有のコンピューティング環境の複数のユーザの各特定のユーザ毎に、前記特定のユーザがアクセスを許可されるサービスのサブセットを決定する命令と、
前記複数の顧客対サービス関連付けの特定の顧客対サービス関連付けにサービスインスタンスを追加する命令と、
前記サービスインスタンスと、前記顧客対ユーザ関連付けの各々からのユーザについてのアイデンティティを格納するアイデンティティストアの特定のパーティションとを関連付けるデータを格納する命令と、
前記サービスインスタンスと、前記顧客対サービス関連付けの各々からのサービスインスタンスについてのポリシーを格納するポリシーストアの特定のパーティションとを関連付けるデータを格納する命令と、
前記複数の顧客の第２の顧客でなく、前記複数の顧客の第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供する共有のアイデンティティ管理システムを提供する命令とを備え、
前記共有のアイデンティティ管理システムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、コンピュータ読取可能プログラム。

【請求項15】

前記アイデンティティストアに格納され、かつ特定の顧客対ユーザ関連付けにおいて特定される第１のユーザアイデンティティを有する第１のユーザに、ロールの階層から、第１のロールを割り当てる命令をさらに含み、
前記第１のロールは、前記第１のロールを有するユーザが、前記特定の顧客対サービス関連付けにおいて特定されるすべてのサービスインスタンスを管理することを可能にするロールであり、
前記アイデンティティストアに格納された第２のユーザアイデンティティを有する第２のユーザに、前記ロールの階層から、第２のロールを割り当てる命令を含み、
前記第２のロールは、前記第２のロールを有するユーザが、前記特定の顧客対サービス関連付けにおいて特定される単一のサービスインスタンスを管理することを可能にするロールである、請求項１４に記載のコンピュータ読取可能プログラム。

【請求項16】

前記第２のユーザに前記第２のロールを割り当てる命令は、前記第１のユーザが前記第２のユーザに前記第２のロールを委任することに応じて、前記第２のユーザに前記第２のロールを割り当てる命令を含む、請求項１５に記載のコンピュータ読取可能プログラム。

【請求項17】

前記サービスインスタンスを追加する命令は、特定のサービスインスタンスのタイプに関連付けられた複数のロールにより定義される第３のロールを、前記アイデンティティストアに格納され、前記特定の顧客対ユーザ関連付けにおいて特定される第３のアイデンティティを有する第３のユーザに割り当てる命令を含む、請求項１５または１６に記載のコンピュータ読取可能プログラム。

【請求項18】

前記第２のロールに、前記第３のロールと関連付けられたすべての許可を継承させる命令をさらに含み、前記第１のロールに、前記第２のロールにより継承されたすべての許可を継承させる命令を含む、請求項１７に記載のコンピュータ読取可能プログラム。

【請求項19】

特定される電子メールアドレスに電子メールメッセージを送信する命令をさらに含み、前記電子メールメッセージは、前記電子メールメッセージの受信者が、前記特定の顧客対ユーザ関連付け内に管理アイデンティティを確立できるメカニズムを提供する、請求項１４〜１８のいずれか一項に記載のコンピュータ読取可能プログラム。

【請求項20】

クラウドコンピューティング環境内にシングルアイデンティティ管理（ＩＤＭ）を含むシステムであって、前記システムは、
共有のコンピューティング環境の第１の顧客と関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供する手段と、
前記共有のコンピューティング環境の第２の顧客と関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供する手段と、
前記第１の顧客と関連付けられたユーザが前記第２のサービスインスタンスにアクセスすることを防止する手段と、
前記第２の顧客と関連付けられたユーザが前記第１のサービスインスタンスにアクセスすることを防止する手段とを備え、
前記第１のサービスインスタンスにＩＤＭ機能を提供する手段は、前記第２のサービスインスタンスにＩＤＭ機能を提供する手段であり、
前記第１のサービスインスタンスにＩＤＭ機能を提供する手段は、前記第２の顧客でなく、前記第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第２のサービスインスタンスにＩＤＭ機能を提供する手段は、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、システム。

【請求項21】

前記共有のコンピューティング環境内に維持される単一のアイデンティティストア内の前記第２の顧客でなく、前記第１の顧客と関連付けられたユーザアイデンティティを格納する手段と、
前記単一のアイデンティティストア内の前記第１の顧客でなく、前記第２の顧客と関連付けられたユーザアイデンティティを格納する手段と、
第１のクレデンシャルを生成する手段とをさらに含み、前記第１のクレデンシャルは、前記第１のサービスインスタンスが、前記第１の顧客と関連付けられないユーザアイデンティティを含む前記単一のアイデンティティストアの部分でなく、前記第１の顧客と関連付けられたユーザアイデンティティを含む前記単一のアイデンティティストアの部分と対話することを許可し、前記システムはさらに、
第２のクレデンシャルを生成する手段を含み、前記第２のクレデンシャルは、前記第２のサービスインスタンスが、前記第２の顧客と関連付けられないユーザアイデンティティを含む前記単一のアイデンティティストアの部分でなく、前記第２の顧客と関連付けられたユーザアイデンティティを含む前記単一のアイデンティティストアの部分と対話することを許可する、請求項２０に記載のシステム。

【請求項22】

前記共有のコンピューティング環境内に維持される単一のポリシーストア内の前記第２のサービスインスタンスでなく、前記第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納する手段と、
前記単一のポリシーストア内の前記第１のサービスインスタンスでなく、前記第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納する手段と、
第１のクレデンシャルを生成させる手段とをさらに含み、前記第１のクレデンシャルは、前記第１のサービスインスタンスが、前記第１のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む前記単一のポリシーストアの部分でなく、前記第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む前記単一のポリシーストアの部分と対話することを許可し、前記システムはさらに、
第２のクレデンシャルを生成させる手段を含み、前記第２のクレデンシャルは、前記第２のサービスインスタンスが、前記第２のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む前記単一のポリシーストアの部分でなく、前記第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む前記単一のポリシーストアの部分と対話することを許可する、請求項２０または２１に記載のシステム。

【請求項23】

コンピュータ読取可能記憶媒体であって、前記コンピュータ読取可能記憶媒体は、１つ以上のプロセッサにより実行されると、コンピュータに、
共有のコンピューティング環境の複数の顧客のそれぞれの顧客と関連付けられたユーザにサービスを提供する前記共有のコンピューティング環境内に複数の顧客対サービス関連付けおよび複数の顧客対ユーザ関連付けを作成させる命令と、
前記顧客対サービス関連付けおよび前記顧客対ユーザ関連付けに基づいて、前記共有のコンピューティング環境の複数のユーザの各特定のユーザ毎に、前記特定のユーザがアクセスを許可されるサービスのサブセットを決定させる命令と、
前記複数の顧客対サービス関連付けの特定の顧客対サービス関連付けにサービスインスタンスを追加させる命令と、
前記サービスインスタンスと、前記顧客対ユーザ関連付けの各々からのユーザについてのアイデンティティを格納するアイデンティティストアの特定のパーティションとを関連付けるデータを格納させる命令と、
前記サービスインスタンスと、前記顧客対サービス関連付けの各々からのサービスインスタンスについてのポリシーを格納するポリシーストアの特定のパーティションとを関連付けるデータを格納させる命令と、
前記複数の顧客の第２の顧客でなく、前記複数の顧客の第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供する共有のアイデンティティ管理システムを提供させる命令とを保持し、
前記共有のアイデンティティ管理システムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、コンピュータ読取可能記憶媒体。

【請求項24】

システムであって、前記システムは、
１つ以上のプロセッサと、
コンピュータ読取可能媒体とを備え、前記コンピュータ読取可能媒体は、前記１つ以上のプロセッサにより実行されると、コンピュータに、
共有のコンピューティング環境の複数の顧客のそれぞれの顧客と関連付けられたユーザにサービスを提供する前記共有のコンピューティング環境下でシングルアイデンティティ管理（ＩＤＭ）システムを確立させる命令と、
前記シングルＩＤＭシステムに、前記共有のコンピューティング環境の第１の顧客と関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供させる命令と、
前記シングルＩＤＭシステムに、前記共有のコンピューティング環境の第２の顧客と関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供させる命令と、
前記シングルＩＤＭシステムに、前記第１の顧客と関連付けられたユーザが前記第２のサービスインスタンスにアクセスすることを防止させる命令と、
前記シングルＩＤＭシステムに、前記第２の顧客と関連付けられたユーザが前記第１のサービスインスタンスにアクセスすることを防止させる命令とを保持し、
前記シングルＩＤＭシステムは、前記第２の顧客でなく、前記第１の顧客専用の第１のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記シングルＩＤＭシステムは、前記第１の顧客でなく、前記第２の顧客専用の第２のドメイン内にプロビジョニングされたサービスにアイデンティティ管理機能を提供し、
前記第１のドメインおよび前記第２のドメインは、前記共有のコンピューティング環境のドメインである、システム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、マルチテナンシアイデンティティ管理システムと題される２０１３年３月１３日に出願された米国特許出願番号第１３／８３８，８１３号の優先権を主張し、その内容全体があらゆる目的で引用によりこの明細書中に援用され；共有アイデンティティ管理アーキテクチャと題される２０１２年９月７日に出願された米国仮特許出願番号第６１／６９８，４６３号の優先権を主張し、その内容全体があらゆる目的で引用によりこの明細書中に援用され；テナント自動化システムと題される２０１２年９月７日に出願された米国仮特許出願番号第６１／６９８，４１３号の優先権を主張し、その内容全体があらゆる目的で引用によりこの明細書中に援用され；サービスデプロイメントインフラストラクチャと題される２０１２年９月７日に出願された米国仮特許出願番号第６１／６９８，４５９号の優先権を主張し；クラウドインフラストラクチャと題される２０１３年３月１４日に出願された米国仮特許出願番号第６１／７８５，２９９号の優先権を主張し、その内容全体があらゆる目的で引用によりこの明細書中に援用される。

【0002】

背景
以下の開示は概してコンピュータセキュリティに関し、より特定的には、さまざまな別個のアイデンティティドメインに分割されるクラウドコンピューティング環境内におけるアイデンティティ管理に関する。

【背景技術】

【0003】

クラウドコンピューティングは、ネットワーク（典型的にインターネット）上のサービスとして送達されるコンピューティングリソース（例えばハードウェアおよびソフトウェア）の使用を必要とする。クラウドコンピューティングはユーザのデータ、ソフトウェアおよび演算をリモートサービスに委託する。クラウドコンピューティングは、例えば、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）またはプラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）を提供するために用いることができる。ＳａａＳを用いるビジネスモデルにおいては、ユーザは、アプリケーションソフトウェアおよびデータベースに対してアクセス可能にされている。クラウドプロバイダは、アプリケーションが実行されているインフラストラクチャおよびプラットフォームを管理することができる。ＳａａＳプロバイダは一般にサブスクリプションフィーを用いてアプリケーションの価格設定を行なう。ＳａａＳは、ビジネスにおいて、ハードウェアおよびソフトウェアのメンテナンスおよびサポートをクラウドプロバイダに外部委託することによって、情報技術運用コストを減らす可能性を提供し得る。この外部委託により、ビジネスにおいて、情報技術運用コストをハードウェア／ソフトウェア費および人件費から他の情報技術目標の達成に再配分することが可能となり得る。さらに、アプリケーションが中心にホストされていれば、ユーザが新しいソフトウェアをインストールしなくても更新を公開することができる。しかしながら、ユーザのデータがクラウドプロバイダのサーバ上に格納されているので、そのデータが認証なしにアクセスされてしまう可能性があることについて懸念する組織もあるだろう。

【0004】

エンドユーザは、ウェブブラウザまたはライトウェイトデスクトップまたはモバイルアプリケーションによってクラウドベースのアプリケーションにアクセスすることができる。一方で、ビジネスソフトウェアおよびユーザのデータは、そのビジネスおよびそれらのユーザから遠隔の位置にあるサーバ上に格納することができる。クラウドコンピューティングは、少なくとも理論的には、管理しやすさを向上し、メンテナンスをより少なくすることで、エンタープライズがそれらのアプリケーションをより迅速にデプロイすることを可能にする。クラウドコンピューティングは、少なくとも理論的には、しばしば変動する予測不可能なビジネス要求を満たすために、情報技術マネージャがより迅速にリソースを調整することを可能にする。

【0005】

アイデンティティ管理（ＩＤＭ：Identity management）は、コンピュータシステムのユーザについての情報を制御するタスクである。このような情報は、このようなユーザのアイデンティティを認証する情報を含み得る。このような情報は、それらのユーザがアクセスする権限が与えられているのがどのデータであるのかを記述する情報を含み得る。このような情報は、それらのユーザがさまざまなシステムリソース（例えばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対して実行する権限が与えられているのがどの動作であるのかを記述する情報を含み得る。ＩＤＭはまた、各々のユーザについての記述情報、ならびに、その記述情報に対するアクセスおよび変更を誰が如何にして行ない得るかについての記述情報の管理を含み得る。

【0006】

場合によっては、クラウドコンピューティング環境は、クラウドコンピューティング環境を用いた各々の別個の組織のための別個のＩＤＭシステムまたはＩＤＭシステムの別個のインスタンスを含み得るだろう。しかしながら、このような方式は、労力を無駄に重ねてコンピューティングリソースを浪費するものとみなされる可能性がある。

【発明の概要】

【課題を解決するための手段】

【0007】

概要
本発明のいくつかの実施例は、クラウドコンピューティング環境において実現され、複数の別個のアイデンティティドメインに分割されるアイデンティティ管理（ＩＤＭ）システムを含む。

【0008】

本発明の実施例においては、一組の構築物がすべて整列することにより、シングルＩＤＭシステムの抽象化または「テナントスライスされた」ビューを作成する。このシングルＩＤＭシステムは複数の別個のコンポーネントまたはサブシステムを含み得る。ＩＤＭシステムは、より稠密に利用されるように、複数の独立した別個の「テナント」またはＩＤＭシステム顧客間で共有することができる。このため、別個のＩＤＭシステムを各々の別個の顧客のためにインスタンス化する必要はない。シングルＩＤＭシステムは、ＩＤＭシステムの各々のテナントのために、そのテナントに特有のＩＤＭシステムの仮想図をそのテナントのユーザに提示することができるように構成することができる。

【0009】

本発明の実施例は仮想化の概念を使用し得る。ＩＤＭシステムの別個のビューは、複数の別個の仮想マシンが単一のホストコンピューティング装置上で仮想化され得る態様と概念的に同様の態様で、シングルＩＤＭシステム内で仮想化することができる。この仮想化は、特定の態様でＩＤＭシステムを構成することによって達成することができる。ＩＤＭシステムは、概念的に垂直に順に積重ねられた上層と下層とを含む複数の別個の層を含み得る。上層は少なくとも分割することができる。ＩＤＭシステムにおいては、さまざまな異なるサービス（例えば認証および／または認可サービス）を、ＩＤＭシステムのさまざまな異なるテナントに関連付けることができる。ＩＤＭシステムは、各々のテナントが、そのテナント専用であるＩＤＭシステム「スライス」またはパーティションとしか対話できないようにするために、各々のテナントを分離することができる。こうして、ＩＤＭシステムは、テナント間における分離を実施することができる。

【0010】

本発明の例示的な実施例は、コンピュータにより実現される方法を提供し、当該方法は、クラウドコンピューティング環境内に複数のアイデンティティドメインを作成するステップと、複数のアイデンティティドメイン内のアイデンティティドメイン間の分離を実施するステップと、複数のアイデンティティドメインの特定のアイデンティティドメインにサービスインスタンスを追加するステップと、サービスインスタンスと、複数のアイデンティティドメインの各アイデンティティドメイン毎にアイデンティティを格納するアイデンティティストアの特定のパーティションとを関連付けるデータを格納するステップと、サービスインスタンスと、複数のアイデンティティドメインの異なるアイデンティティドメインと関連付けられた複数のサービスインスタンスについてのポリシーを格納するポリシーストアの特定のパーティションとを関連付けるデータを格納するステップとを含む。

【0011】

一例では、コンピュータにより実現される方法はさらに、アイデンティティストアに格納され、特定のアイデンティティドメインと関連付けられた第１のユーザアイデンティティを有する第１のユーザに、ロールの階層から、第１のロールを割り当てるステップを含み、第１のロールは、第１のロールを有するユーザが、特定のアイデンティティドメインと関連付けられたすべてのサービスインスタンスを管理することを可能にするロールであり、方法はさらに、アイデンティティストアに格納された第２のユーザアイデンティティを有する第２のユーザに、ロールの階層から、第２のロールを割り当てるステップを含み、第２のロールは、第２のロールを有するユーザが、特定のアイデンティティドメインと関連付けられた単一のサービスインスタンスを管理することを可能にするロールである。

【0012】

一例では、第２のユーザに第２のロールを割り当てるステップは、第１のユーザが第２のユーザに第２のロールを委任することに応じて、第２のユーザに第２のロールを割り当てるステップを含む。

【0013】

一例では、複数のアイデンティティドメインの特定のアイデンティティドメインにサービスインスタンスを追加するステップは、特定のサービスインスタンスのタイプに関連付けられた複数のロールにより定義される第３のロールを、アイデンティティストアに格納され、特定のアイデンティティドメインと関連付けられた第３のアイデンティティを有する第３のユーザに割り当てるステップを含む。

【0014】

一例では、コンピュータにより実現される方法はさらに、第２のロールに、第３のロールと関連付けられたすべての許可を継承させるステップと、第１のロールに、第２のロールにより継承されたすべての許可を継承させるステップとを含む。

【0015】

一例では、クラウドコンピューティング環境内に複数のアイデンティティドメインを作成するステップは、クラウドコンピューティング環境内に特定のアイデンティティドメインを作成するステップを含み、クラウドコンピューティング環境内に特定のアイデンティティドメインを作成するステップは、特定される電子メールアドレスに電子メールメッセージを送信するステップを含み、電子メールメッセージは、電子メールメッセージの受信者が、特定のアイデンティティドメイン内に管理アイデンティティを確立できるメカニズムを提供する。

【0016】

本発明の例示的な実施例は、コンピュータにより実現される方法を提供し、当該方法は、シングルアイデンティティ管理（ＩＤＭ）システムをクラウドコンピューティング環境下で確立させるステップと、シングルＩＤＭシステムに、クラウドコンピューティング環境内に定義され、かつクラウドコンピューティング環境内に定義された第２のアイデンティティドメインから分離された第１のアイデンティティドメインと関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供させるステップと、シングルＩＤＭシステムに、第２のアイデンティティドメインと関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供させるステップとを含む。

【0017】

一例では、コンピュータにより実現される方法はさらに、シングルＩＤＭシステムに、クラウドコンピューティング環境内に維持される単一のアイデンティティストア内の第２のアイデンティティドメインでなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを格納させるステップと、シングルＩＤＭシステムに、単一のアイデンティティストア内の第１のアイデンティティドメインでなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを格納させるステップと、シングルＩＤＭシステムに、第１のクレデンシャルを生成させるステップとを含み、第１のクレデンシャルは、第１のサービスインスタンスが、第１のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可し、方法はさらに、シングルＩＤＭシステムに、第２のクレデンシャルを生成させるステップを含み、第２のクレデンシャルは、第２のサービスインスタンスが、第２のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可する。

【0018】

一例では、コンピュータにより実現される方法はさらに、シングルＩＤＭシステムに、クラウドコンピューティング環境内に維持される単一のポリシーストア内の第２のサービスインスタンスでなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納させるステップと、シングルＩＤＭシステムに、単一のポリシーストア内の第１のサービスインスタンスでなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納させるステップと、シングルＩＤＭシステムに、第１のクレデンシャルを生成させるステップとを含み、第１のクレデンシャルは、第１のサービスインスタンスが、第１のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可し、方法はさらに、シングルＩＤＭシステムに、第２のクレデンシャルを生成させるステップを含み、第２のクレデンシャルは、第２のサービスインスタンスが、第２のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可する。

【図面の簡単な説明】

【0019】

【図1】発明の実施例に係る、テナントの視点から共有ＩＤＭシステムの例を概念的に示すブロック図である。

【図2】発明の実施例に係る、共有ＩＤＭシステムを介して複数の顧客についての複数のアイデンティティドメインを作成するための技術の例を示すフローチャートである。

【図3】発明の実施例に係る、階層状のクラウドベースのＩＤＭシステムの概略の一例を示すブロック図である。

【図4】発明の実施例に係る、クラウドセキュリティファンデーション層のサブシステムの例を示すブロック図である。

【図5】発明の実施例に係る、クラウド共有ＩＤＭ層のサブシステムの例を示すブロック図である。

【図6】発明の実施例に係る、オラクルＩＤＭ／セキュリティ層のサブシステムの例を示すブロック図である。

【図7】発明の実施例に係る、アイデンティティドメインを管理するためにロール階層を用いることができるクラウドベースのＩＤＭシステムの例を示すブロック図である。

【図8】発明の実施例に係る、アプリケーションインスタンス・ランタイムコンポーネントがアイデンティティドメイン内に定義されたアイデンティティにアクセスできるマルチテナントＩＤＭシステムを示すブロック図である。

【図9】本発明の実施例に従って用いられ得るシステム環境のコンポーネントを示す簡略ブロック図である。

【図10】本発明の実施例に従って用いられ得るコンピュータシステムの簡略ブロック図である。

【図11】発明の実施例に係る、マルチテナントＩＤＭシステムにおけるロール委任を示すブロック図である。

【図12】発明の実施例に係る、マルチテナントＩＤＭシステムにおける許可継承を示すブロック図である。

【図13】発明の実施例に係る、アイデンティティドメイン内のサービスインスタンスをプロビジョニングするためのシステムの例を示すブロック図である。

【図14】発明の実施例に係る、クラウドのハードウェアおよびソフトウェアリソースが、アイデンティティドメイン間で共有できるマルチテナントクラウドベースのシステムの例を示すブロック図である。

【図15】発明の実施例に係る、分離された顧客間でクラウドハードウェアの仮想的な「スライス」を共有するために、クラウドベースのシステムにおいて用いられることができるＪＡＶＡクラウドサービスアーキテクチャの例を示すブロック図である。

【図16】発明の実施例に係る、クラウドベースのＩＤＭシステムについてのマルチテナントＬＤＡＰディレクトリの構造の例を示す階層図である。

【図17】発明の実施例に係る、異なるサービスタイプについてのロールテンプレートに関係するＬＤＡＰディレクトリサブツリーの構造の例を示す階層図である。

【図18】発明の実施例に係る、同一のデータベースインスタンス内で複数のスキーマが用いることができるクラウドベースのシステムにおいて用いることができる、データベースクラウドサービス・マルチテナンシアーキテクチャの例を示すブロック図である。

【図19】発明の実施例に係る、Ｎｕｖｉａｑクラウドシステムの例を示すブロック図である。

【図20A】本発明の実施例に係るクラウドインフラストラクチャシステムの論理図である。

【図20B】本発明の実施例に係るクラウドインフラストラクチャシステムを実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。

【図21】図２０Ａに示されるクラウドインフラストラクチャシステムを実現するためのシステム環境の簡略ブロック図である。

【図22A】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールによって実行され得る処理を示す簡略化されたフローチャートを示す。

【図22B】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。

【図23】本発明の実施例に係るＴＡＳコンポーネントの例示的な分散デプロイメントを示す。

【図24】本発明の実施例に係るクラウドインフラストラクチャシステムにおける１つ以上のモジュールとのＳＤＩモジュールのインタラクションを示す簡略ブロック図である。

【図25】本発明の実施例に係るＳＤＩモジュールのサブモジュールの簡略化された高レベル図を示す。

【図26A】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＳＤＩコンポーネントによって実行され得る処理を示す簡略化されたフローチャートを示す。

【図26B】本発明の実施例に係るＮｕｖｉａｑシステムおよび他のクラウドインフラストラクチャコンポーネントとのその関係の高レベルアーキテクチャを示す簡略ブロック図を示す。

【図26C】本発明の実施例に係るＮｕｖｉａｑシステムを使用するプロビジョニングプロセスのステップを示す例示的なシーケンス図を示す。

【図26D】本発明の実施例に係るＮｕｖｉａｑシステムを使用するデプロイメントプロセスのステップを示す例示的なシーケンス図を示す。

【図26E】本発明の実施例に係るデータベースサービスのためにプロビジョニングされたデータベースインスタンスの例を示す。

【図27】本発明の一実施例に係るコンピューティング装置の機能ブロック図である。

【図28】本発明の別の実施例に係るコンピューティング装置の機能ブロック図である。

【図29】本発明のさらに別の実施例に係るコンピューティング装置の機能ブロック図である。

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

【0020】

詳細な説明
以下の説明では、本発明の実施例が十分に理解されるようにするために、説明の目的で具体的詳細を記載する。しかし、これらの具体的詳細がなくても本発明を実施できることは明らかであろう。

【0021】

本発明の特定の実施例は、クラウドインフラストラクチャシステムによって提供されるサービスのプロビジョニング、管理および追跡を自動化するための技術を提供する。

【0022】

特定の実施例では、クラウドインフラストラクチャシステムは、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。

【0023】

クラウドインフラストラクチャシステムは、クラウドインフラストラクチャシステムにおいてサービスおよびリソースについての顧客のサブスクリプションをプロビジョニング、管理および追跡する機能、クラウドインフラストラクチャシステムにおいてサービスを利用する顧客に予測可能な作業費用を提供する機能、クラウドインフラストラクチャシステムにおいて顧客のデータのロバストなアイデンティティドメインの分離および保護を提供する機能、クラウドインフラストラクチャシステムの設計の透過的なアーキテクチャおよび制御を顧客に提供する機能、データ保護の保証とデータプライバシ基準および規制の順守とを顧客に提供する機能、クラウドインフラストラクチャシステムにおいてサービスを構築およびデプロイするための統合された開発経験を顧客に提供する機能、ならびにクラウドインフラストラクチャシステムにおいてビジネスソフトウェア、ミドルウェア、データベースおよびインフラストラクチャサービスの間のシームレスな統合を顧客に提供する機能を含むがこれらに限定されない多くの機能を提供することができる。

【0024】

特定の実施例では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な複数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書ではサービスインスタンスと称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用可能なサービスはいずれも、クラウドサービスと称される。一般に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。例えば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得て、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。

【0025】

コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションまたは他のサービスへの保護されたコンピュータネットワークアクセスを含む。例えば、サービスは、インターネットを介したクラウド上のリモートストレージへの、パスワードによって保護されたアクセスを含んでいてもよい。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含んでいてもよい。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含んでいてもよい。

【0026】

図２０Ａは、本発明の一実施例に係るクラウドインフラストラクチャシステムの論理図である。クラウドインフラストラクチャシステム２０００は、クラウドまたはネットワーク化された環境を介してさまざまなサービスを提供し得る。これらのサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される１つ以上のサービスを含んでいてもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスをオーダーし得る。次いで、クラウドインフラストラクチャシステム２０００は、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。

【0027】

クラウドインフラストラクチャシステム２０００は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。例えば、サービスは、クラウドインフラストラクチャシステム２０００が（例えばオラクルによって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般的な公営企業またはさまざまな産業企業に利用可能であるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム２０００が単一の組織のために単独で運営され、当該組織内の１つ以上のエンティティにサービスを提供することができるプライベートクラウドモデルの下で提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム２０００およびシステム２００によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。

【0028】

図２０Ａに示されるように、クラウドインフラストラクチャシステム２０００は、クラウドインフラストラクチャシステム２０００によって提供されるサービスのプロビジョニングを可能にする、連携して動作する複数のコンポーネントを備えていてもよい。図２０Ａに示される実施例では、クラウドインフラストラクチャシステム２０００は、ＳａａＳプラットフォーム２００２と、ＰａａＳプラットフォーム２００４と、ＩａａＳプラットフォーム２０１０と、インフラストラクチャリソース２００６と、クラウド管理機能２００８とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。

【0029】

ＳａａＳプラットフォーム２００２は、ＳａａＳカテゴリに入るクラウドサービスを提供するように構成される。例えば、ＳａａＳプラットフォーム２００２は、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給するための機能を提供し得る。ＳａａＳプラットフォーム２００２は、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォーム２００２によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム２０００上で実行されるアプリケーションを利用することができる。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。

【0030】

さまざまな異なるＳａａＳサービスが提供され得る。例としては、大きな組織に販売実績管理、企業統合およびビジネスの柔軟性などのためのソリューションを提供するサービスが挙げられるが、これに限定されるものではない。一実施例では、ＳａａＳサービスは、顧客関係管理（Customer Relationship Management：ＣＲＭ）サービス２０１０（例えばオラクルクラウドによって提供されるフュージョンＣＲＭサービス）、人材管理（Human Capital Management：ＨＣＭ）／才能管理サービス２０１２などを含んでいてもよい。ＣＲＭサービス２０１０は、顧客への販売活動サイクルの報告および管理に向けられるサービスなどを含んでいてもよい。ＨＣＭ／才能サービス２０１２は、顧客へのグローバルな労働力ライフサイクル管理および才能管理サービスの提供に向けられるサービスを含んでいてもよい。

【0031】

標準化された、共有の、弾性的にスケーラブルなアプリケーション開発およびデプロイメントプラットフォームにおけるＰａａＳプラットフォーム２００４によって、さまざまな異なるＰａａＳサービスが提供され得る。ＰａａＳサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを（オラクルなどの）組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能が挙げられ得るが、これらに限定されるものではない。ＰａａＳプラットフォーム２００４は、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム２０００によって提供されるＰａａＳサービスを取得することができる。ＰａａＳサービスの例としては、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。

【0032】

ＰａａＳプラットフォーム２００４によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム２０００によってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施例では、クラウドインフラストラクチャシステム２０００によって提供されるＰａａＳサービスは、データベースクラウドサービス２０１４と、ミドルウェアクラウドサービス（例えばオラクルフュージョンミドルウェアサービス）２０１６と、Ｊａｖａクラウドサービス２０１７とを含んでいてもよい。一実施例では、データベースクラウドサービス２０１４は、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートし得て、ミドルウェアクラウドサービス２０１６は、さまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し、Ｊａｖａクラウドサービス２０１７は、クラウドインフラストラクチャシステム２０００においてＪａｖａアプリケーションをデプロイするために顧客にプラットフォームを提供する。図２０Ａに示されるＳａａＳプラットフォーム２００２およびＰａａＳプラットフォーム２００４におけるコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例では、ＳａａＳプラットフォーム２００２およびＰａａＳプラットフォーム２００４は、クラウドインフラストラクチャシステム２０００の顧客に追加のサービスを提供するための追加のコンポーネントを含んでいてもよい。

【0033】

ＩａａＳプラットフォーム２０１０によってさまざまな異なるＩａａＳサービスが提供され得る。ＩａａＳサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のために、ストレージ、ネットワークおよび他の基礎的なコンピューティングリソースなどの基本的なコンピューティングリソースの管理および制御を容易にする。

【0034】

特定の実施例では、クラウドインフラストラクチャシステム２０００は、クラウドインフラストラクチャシステム２０００の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース２００６を含む。一実施例では、インフラストラクチャリソース２００６は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め統合された、最適化された組み合わせを含む。

【0035】

特定の実施例では、クラウド管理機能２００８は、クラウドインフラストラクチャシステム２０００においてクラウドサービス（例えばＳａａＳ、ＰａａＳ、ＩａａＳサービス）の包括的な管理を提供する。一実施例では、クラウド管理機能２００８は、クラウドインフラストラクチャシステム２０００によって受取られた顧客のサブスクリプションをプロビジョニング、管理および追跡するための機能などを含む。

【0036】

図２０Ｂは、本発明の実施例に係るクラウドインフラストラクチャシステム２０００を実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。図２０Ｂに示される実現例は、図２０Ｂに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２０Ｂに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム２０００は、図２０Ｂに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。特定の実施例では、最適な性能を提供する垂直統合を提供するようにハードウェアおよびソフトウェアコンポーネントが積層される。

【0037】

さまざまなタイプのユーザがクラウドインフラストラクチャシステム２０００と対話し得る。これらのユーザは、例えば、デスクトップ、モバイル機器、タブレットなどのさまざまなクライアント装置を使用してクラウドインフラストラクチャシステム２０００と対話し得るエンドユーザ２０５０を含んでいてもよい。また、ユーザは、さまざまな統合された開発環境（integrated development environment：ＩＤＥ）を介して、および他のアプリケーションを介して、コマンドラインインターフェイス（command line interface：ＣＬＩ）、アプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）を使用してクラウドインフラストラクチャシステム２０００と対話し得る開発者／プログラマ２０５２を含んでいてもよい。また、ユーザは、オペレーションスタッフ２０５４を含んでいてもよい。これらは、クラウドサービスプロバイダのスタッフまたは他のユーザのスタッフを含んでいてもよい。

【0038】

アプリケーションサービス層２０５６は、クラウドインフラストラクチャシステム２０００によって提供され得るさまざまなクラウドサービスを特定する。これらのサービスは、サービス統合および連結層２０５８を介してそれぞれのソフトウェアコンポーネント２０６０（例えばＪａｖａサービスを提供するためのオラクルウェブロジックサーバ、データベースサービスを提供するためのオラクルデータベースなど）にマッピングされるか、または関連付けられ得る。

【0039】

特定の実施例では、クラウドインフラストラクチャシステム２０００のさまざまなコンポーネントまたはモジュールおよびクラウドインフラストラクチャシステム２０００によって提供されるサービスによって共有されるいくつかの内部サービス２０６２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、ＩＤＥにおいてクラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。

【0040】

ランタイムインフラストラクチャ層２０６４は、さまざまな他の層およびコンポーネントが構築されるハードウェア層を表わす。特定の実施例では、ランタイムインフラストラクチャ層２０６４は、ストレージ、処理およびネットワーキングリソースを提供するための１つのオラクルのＥｘａｄａｔａマシンを備えていてもよい。Ｅｘａｄａｔａマシンは、さまざまなデータベースサーバ、ストレージサーバ、ネットワーキングリソース、およびクラウドサービス関連のソフトウェア層をホストするための他のコンポーネントから構成され得る。特定の実施例では、Ｅｘａｄａｔａマシンは、ストレージ、演算、ネットワークおよびソフトウェアリソースの集合体を提供するエンジニアド・システムであるOracle Ｅｘａｌｏｇｉｃと連携するように設計され得る。ＥｘａｄａｔａおよびＥｘａｌｏｇｉｃの組み合わせは、クラウドサービスを提供するための高性能で、高可用性で、スケーラブルで、安全な、管理されたプラットフォームを与える完全なハードウェアおよびソフトウェアエンジニアドソリューションを提供する。

【0041】

図２１は、本発明の実施例に係る図２０Ａに示されるクラウドインフラストラクチャシステムを実現するためのシステム環境の簡略ブロック図である。示される実施例では、システム環境２１３０は、クラウドインフラストラクチャシステム２０００と対話するためにユーザによって使用され得る１つ以上のクライアントコンピューティング装置２１２４、２１２６および２１２８を含む。クライアント装置は、クラウドインフラストラクチャシステム２０００によって提供されるサービスを利用するためにクラウドインフラストラクチャシステム２０００と対話するようにクライアント装置のユーザによって使用され得る、ウェブブラウザ、プロプライエタリクライアントアプリケーション（例えばOracle Forms）またはその他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。

【0042】

図２１に示されるクラウドインフラストラクチャシステム２０００は、図２１に示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２１に示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム２０００は、図２１に示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。

【0043】

クライアントコンピューティング装置２１２４、２１２６および２１２８は、汎用パーソナルコンピュータ（一例として、マイクロソフトウィンドウズ（登録商標）および／またはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、（マイクロソフトウィンドウズモバイルなどのソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリーまたは使用可能な他の通信プロトコルである）携帯電話もしくはＰＤＡ、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されるものではない）のいずれかを実行するワークステーションコンピュータ、またはその他のコンピューティング装置であってもよい。例えば、クライアントコンピューティング装置２１２４、２１２６および２１２８は、ネットワークを介して通信することができるシン・クライアントコンピュータ、インターネットへの接続が可能なゲーム機および／またはパーソナルメッセージング装置などのその他の電子装置であってもよい。例示的なシステム環境２１３０が３つのクライアントコンピューティング装置とともに示されているが、いかなる数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置がクラウドインフラストラクチャシステム２０００と対話してもよい。

【0044】

ネットワーク２１３２は、クライアント２１２４、２１２６および２１２８とクラウドインフラストラクチャシステム２０００との間でのデータの通信および交換を容易にし得る。ネットワーク２１３２は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されるものではないさまざまな市販のプロトコルのいずれかを使用してデータ通信をサポートし得る、当業者になじみのある任意のタイプのネットワークであってもよい。単に一例として、ネットワーク２１３２は、イーサネット（登録商標）ネットワーク、トークン・リング・ネットワークなどのローカルエリアネットワーク（local area network：ＬＡＮ）、広域ネットワーク、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を含むがこれに限定されるものではない仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えばＩＥＥＥ８０２．１Ｘの一連のプロトコル、当該技術分野において公知のブルートゥース（登録商標）プロトコルおよび／またはその他の無線プロトコルのいずれかの下で動作するネットワーク）、ならびに／または、これらのおよび／もしくは他のネットワークの任意の組み合わせであってもよい。

【0045】

クラウドインフラストラクチャシステム２０００は、汎用コンピュータ、特化サーバコンピュータ（一例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式のサーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであり得る１つ以上のコンピュータおよび／またはサーバを備えていてもよい。クラウドインフラストラクチャシステム２０００を構成するコンピューティング装置は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、データベースサーバなどを含む、オペレーティングシステムまたはさまざまな追加のサーバアプリケーションおよび／もしくは中間層アプリケーションのいずれかを実行し得る。例示的なデータベースサーバとしては、オラクル、マイクロソフト、サイベース、ＩＢＭなどから市販されているものが挙げられるが、これらに限定されるものではない。

【0046】

さまざまな実施例では、クラウドインフラストラクチャシステム２０００は、クラウドインフラストラクチャシステム２０００によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。一実施例では、図２１に示されるように、クラウドインフラストラクチャシステム２０００におけるコンポーネントは、アイデンティティ管理（Identity Management：ＩＤＭ）モジュール２１００と、サービスモジュール２１０２と、テナント自動化システム（Tenant Automation System：ＴＡＳ）モジュール２１０４と、サービスデプロイメントインフラストラクチャ（Service Deployment Infrastructure：ＳＤＩ）モジュール２１０６と、エンタープライズマネージャ（Enterprise Manager：ＥＭ）モジュール２１０８と、ストアユーザインターフェイス（user interface：ＵＩ）２１１０、クラウドユーザインターフェイス（ＵＩ）２１１２およびサポートユーザインターフェイス（ＵＩ）２１１６などの１つ以上のフロントエンドウェブインターフェイスと、オーダー管理モジュール２１１４と、販売スタッフ２１１８と、オペレータスタッフ２１２０と、オーダーデータベース２１４２とを含む。これらのモジュールは、汎用コンピュータ、特化サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであり得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、またはそれらを使用して提供されてもよい。一実施例では、これらのモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム２０００におけるクラウド管理機能２００８またはＩａａＳプラットフォーム２０１０によって提供され得る。図２１に示されるクラウドインフラストラクチャシステム２０００のさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図２１に示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。

【0047】

例示的なオペレーションにおいて、（１）において、クライアント装置２１２４または２１２６などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム２０００によって提供されるさまざまなサービスをブラウズし、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスについてのサブスクリプションのオーダーを行なうことによって、クラウドインフラストラクチャシステム２０００と対話し得る。特定の実施例では、顧客は、ストアＵＩ２１１０またはクラウドＵＩ２１１２にアクセスし、これらのユーザインターフェイスを介してサブスクリプションオーダーを行ない得る。

【0048】

顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム２０００によって受取られるオーダー情報は、顧客と、顧客がサブスクライブする予定の、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスとを特定する情報を含んでいてもよい。単一のオーダーは、複数のサービスのオーダーを含んでいてもよい。例えば、顧客は、クラウドＵＩ２１１２にログインして、同一のオーダーにおいてＣＲＭサービスおよびＪａｖａクラウドサービスについてのサブスクリプションを要求し得る。

【0049】

さらに、オーダーは、オーダーされたサービスについての１つ以上のサービスレベルも含んでいてもよい。本明細書で使用され、以下でより詳細に説明されるように、サービスについてのサービスレベルは、ストレージの量、コンピューティングリソースの量、データ転送設備などの、サブスクリプションの文脈において要求されたサービスを提供するために割り当てられるリソースの量を決定する。例えば、ベーシックなサービスレベルは、最小レベルのストレージ、データ伝送またはユーザの数を提供することができ、より高いサービスレベルは、さらなるリソースを含み得る。

【0050】

また、いくつかの例では、クラウドインフラストラクチャシステム２０００によって受取られるオーダー情報は、顧客レベルおよびサービスが求められる期間を示す情報を含んでいてもよい。顧客レベルは、サブスクリプション要求を行なう顧客の優先度を規定する。一例では、優先度は、顧客とクラウドサービスのプロバイダとの間で合意されたサービスレベル合意書（Service Level Agreement：ＳＬＡ）によって規定されるようにクラウドインフラストラクチャシステム２０００が顧客に保証または約束するサービスの質に基づいて決定され得る。一例では、さまざまな顧客レベルは、ベーシックレベル、シルバーレベルおよびゴールドレベルを含む。サービスの期間は、当該サービスの開始日および時刻と、当該サービスが求められる期間とを規定し得る（例えばサービス終了日および時刻が規定されてもよい）。

【0051】

一実施例では、顧客は、ストアＵＩ２１１０を介して新たなサブスクリプションを要求するか、またはクラウドＵＩ２１１２を介してトライアルサブスクリプションを要求し得る。特定の実施例では、ストアＵＩ２１１０は、サービスプロバイダの電子商取引ストアフロントに相当し得る（例えばオラクルクラウドサービスのためのwww.oracle.com/store）。クラウドＵＩ２１１２は、サービスプロバイダのためのビジネスインターフェイスに相当し得る。顧客は、クラウドＵＩ２１１２を介して、利用可能なサービスを調査し、関心のあるサービスにサインアップすることができる。クラウドＵＩ２１１２は、クラウドインフラストラクチャシステム２０００によって提供されるトライアルサブスクリプションをオーダーするのに必要なユーザ入力を取込む。また、クラウドＵＩ２１１２は、アカウント機能を閲覧し、クラウドインフラストラクチャシステム２０００内に位置するランタイム環境を構成するために使用され得る。新たなサブスクリプションのオーダーを行なうことに加えて、ストアＵＩ２１１０は、サブスクリプションのサービスレベルの変更、サブスクリプションの期間の延長、サブスクリプションのサービスレベルの向上、既存のサブスクリプションの終了などの他のサブスクリプション関連のタスクを顧客が実行できるようにもし得る。

【0052】

（１）につきオーダーが行なわれた後、（２）において、ストアＵＩ２１１０またはクラウドＵＩ２１１２のいずれかを介して受取られるオーダー情報がオーダーデータベース２１４２に格納され、当該オーダーデータベース２１４２は、クラウドインフラストラクチャシステム２０００によって操作されて他のシステム要素と連携して利用されるいくつかのデータベースのうちの１つであり得る。オーダーデータベース２１４２は図２１では単一のデータベースとして論理的に示されているが、実際の実現例では、これは１つ以上のデータベースを備えていてもよい。

【0053】

（３）において、オーダーはオーダー管理モジュール２１１４に送られる。オーダー管理モジュール２１１４は、オーダーの検証および検証時のオーダーの予約などのオーダーに関連する課金およびアカウンティング機能を実行するように構成される。特定の実施例では、オーダー管理モジュール２１１４は、契約管理モジュールと、インストールベースモジュールとを含んでいてもよい。契約管理モジュールは、クラウドインフラストラクチャシステム２０００との顧客のサービスレベル合意書（ＳＬＡ）などの顧客のサブスクリプションオーダーに関連付けられた契約情報を格納し得る。インストールベースモジュールは、顧客のサブスクリプションオーダーにおけるサービスの詳細な説明を含み得る。オーダー情報に加えて、インストールベースモジュールは、サービスに関連するインストールの詳細、製品状態およびサービスに関連するサポートサービス履歴を追跡し得る。顧客が新たなサービスをオーダーするかまたは既存のものをアップグレードすると、インストールベースモジュールは、新たなオーダー情報を自動的に追加し得る。

【0054】

（４）において、オーダーに関する情報は、ＴＡＳモジュール２１０４に通信される。一実施例では、ＴＡＳモジュール２１０４は、顧客によって行なわれたオーダーについてのサービスおよびリソースのプロビジョニングをオーケストレート（orchestrate）するためにオーダー情報を利用する。（５）において、ＴＡＳコンポーネント２１０４は、ＳＤＩモジュール２１０６のサービスを使用してサブスクライブされたサービスをサポートするために、リソースのプロビジョニングをオーケストレートする。（６）において、ＴＡＳモジュール２１０４は、ＳＤＩモジュール２１０６から受取られた、プロビジョニングされたオーダーに関連する情報をサービスモジュール２１０２に提供する。いくつかの実施例では、（７）において、ＳＤＩモジュール２１０６は、顧客のサブスクリプションオーダーを実現するために必要なリソースを割り当てて構成するために、サービスモジュール２１０２によって提供されるサービスも使用し得る。

【0055】

（８）において、サービスモジュール２１０２は、オーダーの状態に関する通知をクライアント装置２１２４、２１２６および２１２８上の顧客に送る。

【0056】

特定の実施例では、ＴＡＳモジュール２１０４は、互いに関連付けられたビジネスプロセスを管理し、ビジネスロジックを適用してオーダーがプロビジョニングに進むべきか否かを決定するオーケストレーションコンポーネントとして機能する。一実施例では、新たなサブスクリプションのオーダーを受取ると、ＴＡＳモジュール２１０４は、リソースを割り当てて、当該サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、ＳＤＩモジュール２１０６に要求を送る。ＳＤＩモジュール２１０６は、顧客によってオーダーされたサービスのためのリソースの割当てを可能にする。ＳＤＩモジュール２１０６は、クラウドインフラストラクチャシステム２０００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。したがって、ＴＡＳモジュール２１０４は、サービスおよびリソースがオンザフライで実際にプロビジョニングされるか否か、または予めプロビジョニングされて要求時に単に配分／割り当てられるか否かなどの実装詳細から切離され得る。

【0057】

特定の実施例では、ユーザは、オーダー管理モジュール２１１４と直接対話して、オーダーの検証および検証時のオーダーの予約などの課金およびアカウンティング関連機能を実行するためにストアＵＩ２１１０を使用し得る。いくつかの実施例では、顧客がオーダーを行なう代わりに、（９）において、オーダーはその代わりに、顧客のサービス担当者または販売担当者などの顧客を代表する販売スタッフ２１１８によって行なわれてもよい。販売スタッフ２１１８は、オーダーを行なうためまたは顧客に見積もりを提供するためにオーダー管理モジュール２１１４によって提供されるユーザインターフェイス（図２１には図示せず）を介して、オーダー管理モジュール２１１４と直接対話し得る。例えば、これは、オーダーがオーダー管理モジュール２１１４を介して顧客の販売担当者によって行われ得る大口顧客のためになされ得る。販売担当者は、顧客を代表してサブスクリプションを準備し得る。

【0058】

ＥＭモジュール２１０８は、クラウドインフラストラクチャシステム２０００における顧客のサブスクリプションの管理および追跡に関連するアクティビティをモニタリングするように構成される。ＥＭモジュール２１０８は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップ時間およびシステムダウン時間の量などのサブスクリプションオーダーにおけるサービスについての使用統計を収集する。（１０）において、クラウドインフラストラクチャシステム２０００のプロバイダの従業員であってもよいホストオペレータスタッフ２１２０は、サービスがクラウドインフラストラクチャシステム２０００内でプロビジョニングされるシステムおよびリソースを管理するために、エンタープライズマネージャユーザインターフェイス（図２１には図示せず）を介してＥＭモジュール２１０８と対話し得る。

【0059】

アイデンティティ管理（ＩＤＭ）モジュール２１００は、クラウドインフラストラクチャシステム２０００においてアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成される。一実施例では、ＩＤＭモジュール２１００は、クラウドインフラストラクチャシステム２０００によって提供されるサービスを利用したい顧客についての情報を制御する。このような情報は、このような顧客のアイデンティティを認証する情報、および、さまざまなシステムリソース（例えばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを実行することが認可されるかを表わす情報を含み得る。また、ＩＤＭモジュール２１００は、各顧客についての記述的情報および当該説明的情報がどのようにして誰によってアクセスおよび修正され得るかについての記述的情報の管理を含み得る。

【0060】

一実施例では、アイデンティティ管理モジュール２１００によって管理される情報は、別個のアイデンティティドメインを作成するために分割可能である。特定のアイデンティティドメインに属する情報は、すべての他のアイデンティティドメインから分離されることができる。また、アイデンティティドメインは、複数の別個のテナントによって共有可能である。各々のこのようなテナントは、クラウドインフラストラクチャシステム２０００においてサービスにサブスクライブする顧客であり得る。いくつかの実施例では、顧客は、１つまたは多くのアイデンティティドメインを有することができ、各アイデンティティドメインは、１つ以上のサブスクリプションに関連付けられ得て、各サブスクリプションは、１つまたは多くのサービスを有する。例えば、単一の顧客は大規模事業体に相当し得て、この大規模事業体内の部門／部署についてアイデンティティドメインが作成されてもよい。さらに、ＥＭモジュール２１０８およびＩＤＭモジュール２１００は、クラウドインフラストラクチャシステム２０００において顧客のサブスクリプションを管理および追跡するために、それぞれ（１１）および（１２）においてオーダー管理モジュール２１１４と対話し得る。

【0061】

一実施例では、（１３）において、サポートＵＩ２１１６を介してサポートサービスも顧客に提供され得る。一実施例では、サポートＵＩ２１１６は、サポートスタッフが（１４）においてサポートサービスを実行するようにサポートバックエンドシステムを介してオーダー管理モジュール２１１４と対話することを可能にする。クラウドインフラストラクチャシステム２０００におけるサポートスタッフおよび顧客は、サポートＵＩ２１１６を介して、バグ報告を提出し、これらの報告の状態を確認することができる。

【0062】

図２１に図示されない他のインターフェイスもクラウドインフラストラクチャシステム２０００によって提供されてもよい。例えば、アイデンティティドメイン管理者は、ドメインおよびユーザアイデンティティを構成するためにＩＤＭモジュール２１００へのユーザインターフェイスを使用し得る。また、顧客は、利用したい各サービスのための別個のインターフェイスにログインし得る。特定の実施例では、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスにサブスクライブしたい顧客は、さまざまなロールおよび任務も割り当てられ得る。一実施例では、顧客に割り当てられ得るさまざまなロールおよび任務は、バイヤ、アカウント管理者、サービス管理者、アイデンティティドメイン管理者、またはクラウドインフラストラクチャシステム２０００によって提供されるサービスおよびリソースを利用するユーザのロールおよび任務を含んでいてもよい。さまざまなロールおよび任務は、以下の図２３にさらに十分に示されている。

【0063】

図２２Ａは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールによって実行され得る処理を示す簡略化されたフローチャート２２００を示す。図２２Ａに示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（例えばコード、命令、プログラム）、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、（例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の）メモリに格納されてもよい。図２２Ａに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図２２Ａに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図２２Ａに示される処理は、図２２Ｂに詳細に示されるように、ＴＡＳコンポーネント２１０４における１つ以上のコンポーネントによって実行され得る。

【0064】

２２０２において、顧客のサブスクリプションオーダーが処理される。当該処理は、一例ではオーダーの認証を含んでいてもよい。オーダーの認証は、顧客がサブスクリプションの代金を支払ったことを保証すること、および、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、（ＣＲＭサービスの場合など）許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。また、処理は、クラウドインフラストラクチャシステム２０００によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。

【0065】

２２０４において、オーダーに関連付けられたビジネスプロセスが特定される。いくつかの例では、複数のビジネスプロセスがオーダーについて特定され得る。各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。一例として、第１のビジネスプロセスは、オーダーのための物理的リソースのプロビジョニングに関連する１つ以上のステップを特定し得て、第２のビジネスプロセスは、オーダーについての顧客アイデンティティとともにアイデンティティドメインを作成することに関連する１つ以上のステップを特定し得て、第３のビジネスプロセスは、ユーザについての顧客記録の作成などのバックオフィス機能の実行、オーダーに関連するアカウンティング機能の実行などに関連する１つ以上のステップを特定し得る。特定の実施例では、オーダーにおけるさまざまなサービスを処理するためにさまざまなビジネスプロセスも特定されてもよい。例えば、ＣＲＭサービスおよびデータベースサービスを処理するためにさまざまなビジネスプロセスが特定されてもよい。

【0066】

２２０６において、２２０４でオーダーについて特定されたビジネスプロセスが実行される。オーダーに関連付けられたビジネスプロセスの実行は、ステップ２２０４において特定されたビジネスプロセスに関連付けられた一連のステップのオーケストレートを含んでいてもよい。例えば、オーダーのための物理リソースのプロビジョニングに関連するビジネスプロセスの実行は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、ＳＤＩモジュール２１０６に要求を送ることを含んでいてもよい。

【0067】

２２０８において、プロビジョニングされたオーダーの状態に関する通知が顧客に送られる。ステップ２２０２、２２０４、２２０６および２２０８の実行に関連するさらなる説明については、図２２Ｂに詳細に記載されている。

【0068】

図２２Ｂは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。一実施例では、図２２Ｂに示されるモジュールは、図２２Ａに示されるステップ２２０２〜３０８に記載された処理を実行する。示される実施例では、ＴＡＳモジュール２１０４は、オーダー処理モジュール２２１０と、ビジネスプロセス識別子２２１２と、ビジネスプロセスエクセキュータ２２１６と、超過フレームワーク２２２２と、ワークフロー特定モジュール２２２４と、バンドルされたサブスクリプション生成モジュール２２２６とを備える。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図２２Ｂに示されるＴＡＳモジュールのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図２２Ｂに示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。

【0069】

一実施例では、オーダー処理モジュール２２１０は、顧客からのオーダーを１つ以上の入力ソース２２２１から受取る。例えば、オーダー処理モジュール２２１０は、一実施例ではクラウドＵＩ２１１２またはストアＵＩ２１１０を介してオーダーを直接受取ってもよい。代替的に、オーダー処理モジュール２２１０は、オーダー管理モジュール２１１４またはオーダーデータベース２１４２からオーダーを受取ってもよい。次いで、オーダー処理モジュール２２１０は、オーダーを処理する。特定の実施例では、オーダーの処理は、サービスタイプ、サービスレベル、顧客レベル、リソースのタイプ、サービスインスタンスに割り当てられるリソースの量、およびサービスが求められる期間などのオーダーについての情報を含む顧客記録の生成を含む。処理の一部として、オーダー処理モジュール２２１０は、オーダーが有効なオーダーであるか否かも決定する。これは、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、（フュージョンＣＲＭサービスの場合など）許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。

【0070】

また、オーダー処理モジュール２２１０は、オーダーについてのさらなる処理を実行し得る。処理は、クラウドインフラストラクチャシステム２０００によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。一実施例では、オーダー処理モジュール２２１０は、オーダーに関係するいくつかの状態を特定するために各オーダーを処理し得る。一例では、オーダーのさまざまな状態は、初期化状態、プロビジョニング状態、アクティブ状態、管理が必要な状態、エラー状態などであり得る。初期化状態は、新たなオーダーの状態を指し、プロビジョニング状態は、オーダーについてのサービスおよびリソースがプロビジョニングされた時点のオーダーの状態を指す。オーダーがＴＡＳモジュール２１０４によって処理され、その趣旨の通知が顧客に与えられると、オーダーはアクティブ状態になる。問題を解決するために管理者による介入が必要な場合、オーダーは管理が必要な状態である。オーダーを処理できない場合、オーダーはエラー状態である。オーダー進捗状態の維持に加えて、オーダー処理モジュール２２１０は、プロセスの実行中に遭遇するいかなる障害についても詳細な情報を維持する。他の実施例では、以下で詳細に記載されるように、オーダー処理モジュール２２１０によって実行されるさらなる処理は、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、サブスクリプションの期間の延長、およびサブスクリプションのキャンセルまたはサブスクリプションにおけるさまざまな期間にわたるさまざまなサービスレベルの指定も含んでいてもよい。

【0071】

オーダーがオーダー処理モジュール２２１０によって処理された後、オーダーがプロビジョニングに進むべきか否かを決定するためにビジネスロジックが適用される。一実施例では、オーダーのオーケストレートの一部として、ビジネスプロセス識別子２２１２は、処理されたオーダーをオーダー処理モジュール２２１０から受取って、ビジネスロジックを適用して、処理中のオーダーで使用されるべき特定のビジネスプロセスを特定する。一実施例では、ビジネスプロセス識別子２２１２は、オーダーで使用されるべき特定のビジネスプロセスを決定するために、サービスカタログ２２１４に格納されている情報を利用し得る。一実施例では、図２２Ａに示されるように、オーダーについて複数のビジネスプロセスが特定されてもよく、各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。別の実施例では、上記のように、ＣＲＭサービスまたはデータベースサービスなどのさまざまなタイプのサービスまたはサービスの組み合わせについてさまざまなビジネスプロセスが規定されてもよい。一実施例では、サービスカタログ２２１４は、オーダーを特定のタイプのビジネスプロセスにマッピングする情報を格納し得る。ビジネスプロセス識別子２２１２は、処理中のオーダーについての特定のビジネスプロセスを特定するためにこの情報を使用し得る。

【0072】

ビジネスプロセスが特定されると、ビジネスプロセス識別子２２１２は、実行されるべき特定のビジネスプロセスをビジネスプロセスエクセキュータ２２１６に通信する。次いで、ビジネスプロセスエクセキュータ２２１６は、クラウドインフラストラクチャシステム２０００における１つ以上のモジュールと連携して動作することによって、特定されたビジネスプロセスのステップを実行する。いくつかの実施例では、ビジネスプロセスエクセキュータ２２１６は、ビジネスプロセスに関連付けられたステップを実行するためのオーケストレータのロールを果たす。例えば、ビジネスプロセスエクセキュータは、オーダーに関連するワークフローを特定して、オーダーにおけるサービスの超過を決定するか、またはオーダーに関連するサービスコンポーネントを特定するビジネスプロセスにおけるステップを実行するようにオーダー処理モジュール２２１０と対話し得る。

【0073】

一例では、ビジネスプロセスエクセキュータ２２１６は、サブスクリプションオーダーにおいて要求されたサービスのためにリソースを割り当ててプロビジョニングするためのビジネスプロセスにおけるステップを実行するようにＳＤＩモジュール２１０６と対話する。この例では、ビジネスプロセスにおける各ステップ毎に、ビジネスプロセスエクセキュータ２２１６は、リソースを割り当てて、特定のステップを実現するために必要なリソースを構成するために、ＳＤＩコンポーネント２１０６に要求を送信し得る。ＳＤＩコンポーネント２１０６は、リソースの実際の割当てを担当する。オーダーのビジネスプロセスのすべてのステップが実行されると、ビジネスプロセスエクセキュータ２２１６は、サービスコンポーネント２１０２のサービスを利用することによって、処理されたオーダーの通知を顧客に送信し得る。通知は、処理されたオーダーの詳細を有する電子メール通知を顧客に送ることを含んでいてもよい。また、電子メール通知は、顧客がサブスクライブされたサービスにアクセスすることを可能にするための、オーダーに関連するデプロイメント情報も含んでいてもよい。

【0074】

特定の実施例では、ＴＡＳモジュール２１０４は、ＴＡＳモジュール２１０４がクラウドインフラストラクチャシステム２０００における他のモジュールと対話し、他のモジュールがＴＡＳモジュール２１０４と対話することを可能にする１つ以上のＴＡＳアプリケーションプログラミングインターフェイス（Application Programming Interface：ＡＰＩ）２２１８を提供し得る。例えば、ＴＡＳ ＡＰＩは、顧客のサブスクリプションオーダーのためのリソースをプロビジョニングするために、非同期シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol：ＳＯＡＰ）ベースのウェブサービスコールを介してＳＤＩモジュール２１０６と対話するシステムプロビジョニングＡＰＩを含んでいてもよい。一実施例では、ＴＡＳモジュール２１０４は、システムおよびサービスインスタンスの作成および削除を達成し、サービスインスタンスを向上したサービスレベルに切替え、サービスインスタンスを関連付けるためにも、システムプロビジョニングＡＰＩを利用し得る。この一例は、安全なウェブサービス通信を可能にするためのフュージョンアプリケーションサービスインスタンスへのＪａｖａサービスインスタンスの関連付けである。また、ＴＡＳ ＡＰＩは、処理されたオーダーを顧客に通知するためにサービスモジュール２１０２と対話する通知ＡＰＩも含んでいてもよい。特定の実施例では、ＴＡＳモジュール２１０４は、サブスクリプション情報、機能停止および通知（例えば計画されたダウンタイム）もサービスコンポーネント２１０２に定期的に伝える。

【0075】

特定の実施例では、ＴＡＳモジュール２１０４は、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などのプロビジョニングされたサービスの各々についての使用統計をＥＭモジュール２１０８から定期的に受取る。超過フレームワーク２２２２は、サービスの過剰使用が生じたか否かを決定し、生じた場合には超過に対してどれぐらい課金されるかを決定するために当該使用統計を利用し、この情報をオーダー管理モジュール２１１４に提供する。

【0076】

特定の実施例では、ＴＡＳモジュール２１０４は、顧客のサブスクリプションオーダーの処理に関連付けられた１つ以上のワークフローを特定するように構成されるオーダーワークフロー特定モジュール２２２４を含む。特定の実施例では、ＴＡＳモジュール２１０４は、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスについてのサブスクリプションオーダーを顧客が行なうと顧客のためにサブスクリプションオーダーを生成するためのサブスクリプションオーダー生成フレームワーク２２２６を含んでいてもよい。一実施例では、サブスクリプションオーダーは、当該サブスクリプションオーダーにおいて顧客によって要求されたサービスを提供することを担当する１つ以上のサービスコンポーネントを含む。

【0077】

さらに、ＴＡＳモジュール２１０４は、もしあれば顧客が利用可能な履歴情報を考慮に入れながら、顧客によってサブスクライブされた１つ以上のサービスのためのリソースのプロビジョニングを可能にするために、テナント情報システム（Tenant Information System：ＴＩＳ）データベース２２２０などの１つ以上のさらなるデータベースとも対話し得る。ＴＩＳデータベース２２２０は、顧客によってサブスクライブされたオーダーに関係する履歴オーダー情報および履歴使用情報を含んでいてもよい。

【0078】

ＴＡＳモジュール２１０４は、さまざまなデプロイメントモデルを使用してデプロイされ得る。特定の実施例では、デプロイメントは、１つ以上の分散されたコンポーネントと遣り取りする中心コンポーネントを含む。分散されたコンポーネントは、例えばさまざまなデータセンタとしてデプロイされてもよく、したがってデータセンタコンポーネントとも称されてもよい。中心コンポーネントは、クラウドインフラストラクチャシステム２０００においてオーダーを処理してサービスをまとめるための機能を含み、データセンタコンポーネントは、サブスクライブされたサービスにリソースを提供するランタイムシステムをプロビジョニングして動作させるための機能を提供する。

【0079】

図２３は、本発明の実施例に係るＴＡＳモジュールの例示的な分散型デプロイメントを示す。図２３に示される実施例では、ＴＡＳモジュール２１０４の分散型デプロイメントは、ＴＡＳ中心コンポーネント２３００と、１つ以上のＴＡＳデータセンタ（Data Center：ＤＣ）コンポーネント２３０２、２３０４および２３０６とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。

【0080】

一実施例では、ＴＡＳ中心コンポーネント２３００の任務は、顧客オーダーを受取って、新たなサブスクリプションの作成、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、およびサブスクリプションの期間の延長、またはサブスクリプションのキャンセルなどのオーダー関連のビジネスオペレーションを実行するための集中型コンポーネントを提供することを含むが、これに限定されるものではない。また、ＴＡＳ中心コンポーネント２３００の任務は、クラウドインフラストラクチャシステム２０００によって必要とされるサブスクリプションデータを維持および供給すること、ならびに、すべてのバックオフィスインタラクションに対処するためにオーダー管理モジュール２１１４、サポートＵＩ２１１６、クラウドＵＩ２１１２およびストアＵＩ２１１０と遣り取りすることも含んでいてもよい。

【0081】

一実施例では、ＴＡＳ ＤＣ２３０２、２３０４および２３０６の任務は、顧客によってサブスクライブされた１つ以上のサービスのためのリソースのプロビジョニングをオーケストレートするためのランタイムオペレーションを実行することを含むが、これに限定されるものではない。また、ＴＡＳ ＤＣ２３０２、２３０４および２３０６は、サブスクリプションオーダーのロッキング、アンロッキング、イネーブルまたはディスエーブル、オーダーに関連するメトリクスの収集、オーダーの状態の決定、およびオーダーに関連する通知イベントの送信などのオペレーションを実行するための機能も含む。

【0082】

図２３に示される分散型ＴＡＳシステムの例示的なオペレーションでは、ＴＡＳ中心コンポーネント２３００は、最初に、クラウドＵＩ２１１２、ストアＵＩ２１１０を介して、オーダー管理システム２１１４を介して、またはオーダーデータベース２１４２を介して、顧客からオーダーを受取る。一実施例では、顧客は、財務情報ならびにサブスクリプションをオーダーおよび／または変更するための権限を有するバイヤに相当する。一実施例では、オーダー情報は、顧客、顧客がサブスクライブしたいサービスのタイプ、および要求への対処を担当するアカウント管理者を特定する情報を含む。特定の実施例では、アカウント管理者は、クラウドインフラストラクチャシステム２０００によって提供される１つ以上のサービスへのサブスクリプションについてのオーダーを顧客が行なうと、顧客によって任命され得る。オーダー情報に基づいて、ＴＡＳ中心コンポーネント２３００は、オーダーが発生するアメリカ、ＥＭＥＡまたはアジア太平洋などの世界のデータ領域、およびオーダーをプロビジョニングするためにデプロイされる特定のＴＡＳ ＤＣ（例えば２３０２、２３０４または２３０６）を特定する。一実施例では、オーダーをプロビジョニングするためにデプロイされる（例えばＤＣ２３０２、２３０４または２３０６の中からの）特定のＴＡＳ ＤＣは、要求が発生した地理的なデータ領域に基づいて決定される。

【0083】

次いで、ＴＡＳ中心コンポーネント２３００は、オーダー要求についてのサービスをプロビジョニングするためにオーダー要求を特定のＴＡＳ ＤＣに送る。一実施例では、ＴＡＳ ＤＣ２３０２、２３０４または２３０６は、特定のＴＡＳ ＤＣにおいてオーダー要求を処理することを担当するサービス管理者およびアイデンティティドメイン管理者を特定する。サービス管理者およびアイデンティティ管理者は、サブスクリプションオーダーにおいて特定されるアカウント管理者によって任命され得る。ＴＡＳ ＤＣ２３０２、２３０４または２３０６は、オーダーのための物理リソースのプロビジョニングをオーケストレートするためにＳＤＩモジュール２１０４と通信する。それぞれのＴＡＳ ＤＣ２３０２、２３０４または２３０６におけるＳＤＩコンポーネント２１０４は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成する。

【0084】

特定の実施例では、ＴＡＳ ＤＣ２３０２、２３０４または２３０６は、サブスクリプションに関連付けられたアイデンティティドメインを特定する。ＳＤＩコンポーネント２１０６は、既存のアイデンティティドメインの特定または新たなアイデンティティドメインの作成のためにアイデンティティドメイン情報をＩＤＭコンポーネント２００（図２１に図示）に提供し得る。オーダーがそれぞれのＴＡＳ ＤＣ２３０２、２３０４または２３０６におけるＳＤＩモジュールによってプロビジョニングされると、ＴＡＳ中心コンポーネント２３００は、サポートシステムにおけるプロビジョニングされたリソースに関する情報をサポートＵＩ２１１６を介して配置し得る。情報は、例えばサービスに関連するリソースメトリクスおよびサービスの使用統計の表示を含んでいてもよい。

【0085】

オペレーション時に、各データセンタにおいて、ＥＭモジュール２１０８は、当該データセンタにおいてプロビジョニングされたプロビジョニングされたサービスの各々について、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などの使用統計を定期的に収集する。これらの統計は、ＥＭモジュール２１０８にローカルな（すなわち、同一のデータセンタにおける）ＴＡＳ ＤＣに提供される。実施例では、ＴＡＳ ＤＣは、サービスの過剰使用が生じたか否かを決定し、生じた場合には超過に対してどれぐらい課金されるかを決定するために使用統計を使用し、課金情報をオーダー管理システム２１１４に提供し得る。

【0086】

図２４は、本発明の実施例に係るクラウドインフラストラクチャシステムにおける１つ以上のモジュールとのＳＤＩモジュールのインタラクションを示す簡略ブロック図である。一実施例では、ＳＤＩモジュール２１０６は、ＴＡＳモジュール２１０４によって受取られたサブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするためにＴＡＳモジュール２１０４と対話する。特定の実施例では、図２４に示されるモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム２０００内のモジュールであってもよい。他の実施例では、ＳＤＩモジュール２１０６と対話するモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム２０００の外側にあってもよい。また、代替的な実施例は、図２４に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。

【0087】

一実施例では、ＳＤＩモジュール２１０６におけるモジュールは、クラウドインフラストラクチャシステム２０００内のＳａａＳプラットフォーム２００２およびＰａａＳプラットフォーム２００４における１つ以上のモジュールを含んでいてもよい。さまざまなサービスのためのリソースのプロビジョニングを行なうために、ＳＤＩモジュール２１０６は、各々が特定のタイプのサービスのためのリソースのプロビジョニングに役立つようにカスタマイズされるさまざまな他のモジュールと対話し得る。例えば、図２４に示されるように、ＳＤＩモジュール２１０６は、ＪａｖａクラウドサービスをプロビジョニングするためにＪａｖａサービスプロビジョニング制御モジュール２４００と対話し得る。一実施例では、Ｊａｖａサービスプロビジョニング制御コンポーネント２４００は、Ｊａｖａクラウドサービスをプロビジョニングするために実行される一組のタスクを含むＳＤＩモジュール２１０６によって規定されるＪａｖａクラウドサービス（Java Cloud Service：ＪＣＳ）アセンブリをデプロイし得る。次いで、インフラストラクチャリソース２００６は、Ｊａｖａクラウドサービスをプロビジョニングするために必要なリソースを決定する。

【0088】

他の例として、ＳＤＩモジュール２１０６は、バーチャル・アセンブリ・ビルダ（Virtual Assembly Builder：ＶＡＢ）モジュール２４０２、アプリケーション・エクスプレス（Application Express：ＡＰＥＸ）デプロイヤモジュール２４０４、仮想マシン（Virtual Machine：ＶＭ）モジュール２４０６、ＩＤＭモジュール２１００およびデータベースマシンモジュール２０１８などの１つ以上のモジュールと対話し得る。ＶＡＢモジュール２４０２は、完全な複数層アプリケーション環境を構成およびプロビジョニングするための機能を含む。一実施例では、ＶＡＢモジュール２４０２は、ＶＭモジュール２４０６によって提供されるサービスを使用してクラウドインフラストラクチャシステム２０００においてミドルウェア（Middleware：ＭＷ）サービスをプロビジョニングするために、ＳＤＩモジュール２１０６によって規定されるＭＷサービスアセンブリをデプロイする。ＡＰＥＸデプロイヤモジュール２４０４は、データベースサービスを構成およびプロビジョニングするための機能を含む。一実施例では、ＡＰＥＸデプロイヤモジュール２４０４は、インフラストラクチャリソース２００６によって提供されるリソースを使用してクラウドインフラストラクチャシステム２０００においてデータベースサービスをプロビジョニングするために、ＳＤＩモジュール２１０６によって規定されるデータベースサービスアセンブリをデプロイする。ＳＤＩモジュール２１０６は、クラウドインフラストラクチャシステム２０００において複数のアプリケーションにまたがるアクセス管理などのアイデンティティサービスを提供するためにＩＤＭモジュール２１００と対話する。

【0089】

図２５は、本発明の実施例に係るＳＤＩモジュールのサブモジュールの簡略化された高レベル図を示す。図２５に示される実施例では、ＳＤＩモジュール２１０６は、ＳＤＩ−ウェブサービス（Web Service：ＷＳ）モジュール２５００と、ＳＤＩ要求コントローラモジュール２５０２と、ＳＤＩタスクマネージャモジュール２５０４と、ＳＤＩモニタリングモジュール２５０６と、ＳＤＩデータアクセスモジュール２５０８と、ＳＤＩ共通ライブラリモジュール２５１０と、ＳＤＩコネクタモジュール２５１２とを含む。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図２５に示されるＳＤＩモジュール２１０６およびそのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図２５に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールおよびそれらの機能については、以下で詳細に説明する。

【0090】

ＳＤＩ−ＷＳモジュール２５００は、ＴＡＳコンポーネント２１０４のビジネスプロセスエクセキュータ２２１６から、オーダーに関連付けられたビジネスにおけるステップを受取るための機能を含む。一実施例では、ＳＤＩ−ＷＳモジュール２５００は、ビジネスプロセスの各ステップを構文解析し、当該ステップをＳＤＩモジュール２１０６によって使用される内部表現に変換する。一実施例では、オーダーに関連付けられたビジネスプロセスの各ステップは、ＳＤＩ−ＷＳモジュール２５００へのＳＯＡＰ要求の形態で、ウェブサービス処理層を介して（例えば図２２Ｂに示されるシステムプロビジョニングＡＰＩを介して）到着する。

【0091】

ＳＤＩ要求コントローラモジュール２５０２は、ＳＤＩモジュール２１０６における内部要求処理エンジンであり、非同期要求処理、同時要求処理、同時タスク処理、オーダー要求に関連するフォールト・トレラントな回復およびプラグインサポートを実行するための機能を含む。一実施例では、ＳＤＩ要求コントローラモジュール２５０２は、オーダーに関連付けられたビジネスプロセスの各ステップをＳＤＩ−ＷＳモジュール２５００から受入れ、当該ステップをＳＤＩタスクマネージャモジュール２５０４に提出する。

【0092】

ＳＤＩタスクマネージャモジュール２５０４は、ビジネスプロセスにおいて規定された各ステップを、特定のステップをプロビジョニングするための一連のタスクに変換する。特定のステップのための一組のタスクがプロビジョニングされると、ＳＤＩタスクマネージャモジュール２５０４は、特定のステップを実現するためにプロビジョニングされたリソースの詳細を有するオーダーペイロードを含むオペレーション結果により、ＴＡＳモジュール２１０４におけるビジネスプロセスエクセキュータ２２１６に応答する。ＳＤＩタスクマネージャモジュール２５０４は、オーダーに関連付けられた特定のビジネスプロセスのすべてのステップが完了するまで、このプロセスを繰返す。

【0093】

特定の実施例では、ＳＤＩタスクマネージャモジュール２５０４は、ＳＤＩコネクタモジュール２５１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。ＳＤＩコネクタモジュール２５１２は、オーダー要求に関連する１つ以上のサービスをプロビジョニングするために、ＳＤＩタスクマネージャモジュール２５０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含む。特定の実施例では、コネクタのうちの１つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、ＳＤＩコネクタモジュール２５１２は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム２０００における外部モジュール（図２４に図示）のうちの１つ以上と遣り取りする一組のコネクタ（ラッパーＡＰＩ）を含む。例えば、アプリケーション・エクスプレス（ＡＰＥＸ）コネクタ２５１４は、データベースサービスをプロビジョニングするために、ＡＰＥＸデプロイヤモジュール２４０４と遣り取りする。ウェブセンタコネクタ２５１６（Web Center Connector：ＷＣＣ）は、ウェブサービスをプロビジョニングするために、クラウドインフラストラクチャシステム２０００におけるウェブセンタモジュールと遣り取りする。ウェブセンタモジュールは、ユーザエンゲージメントプラットフォームであり、クラウドインフラストラクチャシステム２０００において人々と情報とのコネクティビティを与えるための機能を含む。

【0094】

特定の実施例では、ミドルウェアアプリケーション（Middleware Application：ＭＡ）コネクタ２５１８は、ミドルウェアアプリケーションサービスをプロビジョニングするために、クラウドインフラストラクチャシステム２０００におけるＶＡＢモジュール２４０２と遣り取りする。ＮＵＶＩＡＱコネクタ２５２０は、Ｊａｖａサービスをプロビジョニングするために、ＶＡＢモジュール２４０２と遣り取りする。ＩＤＭコネクタ２５２２は、クラウドインフラストラクチャシステム２０００においてサービスおよびリソースにサブスクライブするユーザにアイデンティティおよびアクセス管理を提供するために、ＩＤＭモジュール２１００と遣り取りする。バーチャル・アセンブリ・ビルダ（ＶＡＢ）コネクタ２５２４は、完全な複数層アプリケーション環境を構成およびプロビジョニングするために、クラウドインフラストラクチャシステム２０００におけるＶＡＢモジュール２４０２と遣り取りする。プラグインコネクタ２５２６は、クラウドインフラストラクチャシステム２０００におけるコンポーネントを管理およびモニタリングするために、ＥＭモジュール２１０８と遣り取りする。ＨＴＴＰサーバコネクタ２５２８は、クラウドインフラストラクチャシステム２０００においてユーザに接続サービスを提供するために、ＰａａＳプラットフォームにおける１つ以上のウェブサーバと遣り取りする。

【0095】

ＳＤＩモジュール２１０６におけるＳＤＩモニタリングモジュール２５０６は、Ｊａｖａ管理拡張（Java Management Extensions：ＪＭＸ）要求を受取るためのインバウンドインターフェースを提供する。また、ＳＤＩモニタリングモジュール２５０６は、クラウドインフラストラクチャシステム２０００においてアプリケーション、システムオブジェクトおよび装置を管理およびモニタリングするためのツールも提供する。ＳＤＩデータアクセスモジュール２５０８は、Ｊａｖａデータベースコネクティビティ（Java Database Connectivity：ＪＤＢＣ）要求を受取るためのインバウンドインターフェースを提供する。ＳＤＩデータアクセスモジュール２５０８は、クラウドインフラストラクチャシステム２０００において、データアクセスをサポートし、オブジェクト関係マッピング、ｊａｖａトランザクションＡＰＩサービス、データアクセスオブジェクトおよび接続プーリングを提供する。ＳＤＩ共通ライブラリモジュール２５１０は、ＳＤＩモジュール２１０６におけるモジュールのための構成サポートを提供する。

【0096】

上記の図２５の実施例は、本発明の実施例に係るＳＤＩモジュールにおけるモジュールを記載している。図２６Ａは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＳＤＩモジュールのモジュールによって実行され得る処理を示す簡略化されたフローチャート２６００を示す。図２６Ａに示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（例えばコード、命令、プログラム）、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、（例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の）メモリに格納されてもよい。図２６Ａに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図２６Ａに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図２６Ａに示される処理は、図２５に詳細に示されるＳＤＩモジュール２１０６における１つ以上のモジュールによって実行され得る。

【0097】

２６０２において、サブスクリプションオーダーに関連付けられたビジネスプロセスが受取られる。一実施例では、ＳＤＩモジュール２１０６におけるＳＤＩ−ＷＳモジュール２５００は、サブスクリプションオーダーに関連付けられたビジネスプロセスにおける１つ以上のステップをビジネスプロセスエクセキュータ２２１６から受取る。２６０４において、ビジネスプロセスにおける各ステップは、サブスクリプションオーダーのためのリソースをプロビジョニングするための一連のタスクに変換される。一実施例では、ＳＤＩモジュール２１０６におけるＳＤＩタスクマネージャモジュール２５０４は、ＳＤＩコネクタモジュール２５１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。２６０６において、サブスクリプションオーダーは、一連のタスクに基づいてプロビジョニングされる。一実施例では、図２５に示されるように、ＳＤＩコネクタモジュール２５１２は、サブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするために、ＳＤＩタスクマネージャモジュール２５０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含む。

【0098】

図２５に関して上記したように、ＳＤＩタスクマネージャモジュール２５０４は、ＳＤＩコネクタモジュール２５１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換し、ＳＤＩコネクタモジュール２５１２は、オーダー要求に関連する１つ以上のサービスをプロビジョニングするために、ＳＤＩタスクマネージャモジュール２５０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含んでいてもよい。コネクタのうちの１つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、ＳＤＩコネクタモジュール２５１２は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム２０００における外部モジュール（図２４に図示）のうちの１つ以上と遣り取りする一組のコネクタ（ラッパーＡＰＩ）を含む。例えば、ＮＵＶＩＡＱコネクタ２５２０は、ＪａｖａサービスをプロビジョニングするためにＶＡＢモジュール２４０２と遣り取りする。

【0099】

図２６Ｂは、本発明の実施例に係るＮｕｖｉａｑシステム２６１０および他のクラウドインフラストラクチャシステムとのその関係の高レベルアーキテクチャを示す簡略ブロック図を示す。図２６Ｂに示されるＮｕｖｉａｑシステム２６１０は、図２６Ｂに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２６Ｂに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、Ｎｕｖｉａｑシステム２６１０は、図２６Ｂに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。

【0100】

特定の実施例では、Ｎｕｖｉａｑシステム２６１０は、ＰａａＳオペレーションをオーケストレートするためのランタイムエンジンを提供するように構成され得る。Ｎｕｖｉａｑシステム２６１０は、他の製品およびサービスとの統合を容易にするためにウェブサービスＡＰＩを提供し得る。また、Ｎｕｖｉａｑシステム２６１０は、システムプロビジョニング、アプリケーションデプロイメントおよび関連付けられたライフサイクルオペレーションにおける複雑なワークフローのためのサポートを提供し、管理およびモニタリングソリューションと統合する。

【0101】

図２６Ｂに示される実施例では、Ｎｕｖｉａｑシステム２６１０は、Ｎｕｖｉａｑプロキシ２６１２と、Ｎｕｖｉａｑマネージャ２６１４と、Ｎｕｖｉａｑデータベース２６１６とを備える。特定の実施例では、Ｎｕｖｉａｑマネージャ２６１４は、Ｎｕｖｉａｑシステム２６１０へのエントリポイントを提供し、ウェブサービスＡＰＩを介してＰａａＳオペレーションへの安全なアクセスを提供する。内部では、Ｎｕｖｉａｑマネージャ２６１４は、データベースにおいてシステム状態を追跡し、ワークフローエンジン上でのジョブの実行を制御する。パブリッククラウドでは、Ｎｕｖｉａｑマネージャ２６１４は、プロビジョニングオペレーションおよびデプロイメントオペレーションをそれぞれ駆動するために、テナントプロビジョニングシステム（ＳＤＩ２１０６）およびテナントコンソールによってアクセスされ得る。

【0102】

一実施例では、Ｎｕｖｉａｑマネージャ２６１４は、内部ワークフローエンジンを介して非同期にジョブを実行する。ジョブは、所与のＰａａＳワークフローに特有のアクションのシーケンスであってもよい。アクションは、順番に実行されてもよく、任意のステップにおける障害は、結果としてジョブ全体の障害になる。多くのワークフローアクションは、ＥＭコマンドラインインターフェース（ｃｌｉ）などのワークフローに関連する外部システムに権限を委任する。一実現例では、Ｎｕｖｉａｑマネージャ２６１４アプリケーションは、ファイアウォール内で実行される関連付けられたＨＴＴＰサーバ（例えばオラクルＨＴＴＰサーバまたはＯＨＳ）インスタンスを有する２１ノードウェブロジッククラスタにおいてホストされ得る。

【0103】

特定の実施例では、Ｎｕｖｉａｑプロキシ２６１２は、Ｎｕｖｉａｑ ＡＰＩへのパブリックアクセスポイントである。一実施例では、パブリックＡＰＩのみがここで公開され得る。プロキシ２６１２によって受取られた要求は、Ｎｕｖｉａｑマネージャ２６１４に送られ得る。一実施例では、Ｎｕｖｉａｑプロキシ２６１２はファイアウォールの外側で実行される一方、マネージャ２６１４はファイアウォール内で実行される。一実現例では、Ｎｕｖｉａｑプロキシ２６１２アプリケーションは、ファイアウォールの外側で実行されるウェブロジッククラスタ上で実行される。

【0104】

特定の実施例では、Ｎｕｖｉａｑデータベース２６１６は、プラットフォームインスタンス、デプロイメント計画、アプリケーション、ウェブロジックドメイン、ジョブ、アラーとなどであるがこれらに限定されないさまざまなドメインエンティティを追跡する。必要に応じて、主キーがサービスデータベースと整合させられてもよい。

【0105】

一実施例では、プラットフォームインスタンス２６１８は、所与のテナントのためのウェブロジックサービスに必要なすべてのリソースを含んでいてもよい。

【0106】

Ｎｕｖｉａｑシステム２６１０は、ウェブロジッククラウドサービスによって使用されるワークフローを実行するために、クラウドインフラストラクチャシステム２０００のさらなるシステムに依拠し得る。これらの依存性は、ＳＤＩ２１０６、ＩＤＭ２１００、ウイルススキャンシステム、サービスデータベース、ＣＲＭインスタンスなどへの依存性を含んでいてもよい。例えば、Ｎｕｖｉａｑシステム２６１０は、ＳＤＩ２１０６におけるアセンブリデプロイヤによって実行される機能に依存し得る。一実施例では、アセンブリデプロイヤは、ＯＶＡＢ（Oracle Virtual Assembly builder：オラクルバーチャル・アセンブリ・ビルダ）およびＯＶＭ（Oracle Virtual Machine：オラクル仮想マシン）とのインタラクションを管理するためのシステムである。Ｎｕｖｉａｑシステム２６１０によって使用されるアセンブリデプロイヤの機能は、アセンブリをデプロイするための機能、アセンブリをアンデプロイするための機能、アセンブリデプロイメントを説明するための機能、アプライアンスをスケーリングするための機能などを含み得るが、これらに限定されるものではない。一実現例では、Ｎｕｖｉａｑシステム２６１０は、ウェブサービスＡＰＩを介してアセンブリデプロイヤにアクセスする。

【0107】

特定の実施例では、セキュリティポリシは、アプリケーションにデプロイされる前に特定のアーティファクトがウイルススキャンされることを必要とし得る。クラウドインフラストラクチャシステム２０００は、この目的でウイルススキャンシステムを提供し得て、パブリッククラウドの複数のコンポーネントのためのサービスとしてスキャンを提供する。

【0108】

特定の実施例では、パブリッククラウドインフラストラクチャは、テナント（例えば顧客）およびそれらのサービスサブスクリプションについての情報を含むサービスデータベースを維持し得る。Ｎｕｖｉａｑワークフローは、テナントもサブスクライブする他のサービスに対するクライアントとしてウェブロジックサービスを適切に構成するために、このデータにアクセスし得る。

【0109】

Ｎｕｖｉａｑシステム２６１０は、そのセキュリティ統合のためにＩＤＭ２１００に依存し得る。特定の実施例では、Ｊａｖａサービスインスタンスは、ＣＲＭインスタンスに関連付けられ得る。当該関連付けにより、Ｊａｖａサービスインスタンスにデプロイされたユーザプリケーションは、ウェブサービスコールを介してＣＲＭインスタンスにアクセスできる。

【0110】

Ｎｕｖｉａｑシステム２６１０によって提供されるサービスをさまざまなエンティティが使用し得る。Ｎｕｖｉａｑシステム２６１０のこれらのクライアントは、プラットフォームインスタンス上でアプリケーションを管理するために顧客がアクセスし得る管理サーバ（例えばオラクル管理サーバ）ベースのユーザインターフェイスであるテナントコンソールと、アプリケーションライフサイクル管理オペレーションへのアクセスを提供するように拡張されたオラクルＩＤＥ（JDeveloper、NetBeansおよびＯＥＰＥ）などのいくつかのＩＤＥと、プラットフォームインスタンス上のライフサイクルオペレーションにアクセスするために利用可能な１つ以上のコマンドラインインターフェイス（Command Line Interface：ＣＬＩ）とを含んでいてもよい。

【0111】

Ｎｕｖｉａｑシステム２６１０についてのプロビジョニング使用事例、すなわちプロビジョニングプラットフォームインスタンスの使用事例は、Ｎｕｖｉａｑ ＡＰＩの作成プラットフォームインスタンスオペレーションによって実現される。クラウドインフラストラクチャシステム２０００の文脈では、Ｎｕｖｉａｑシステムに対するサービスインスタンスは、Ｎｕｖｉａｑプラットフォームインスタンスに対応する。プラットフォームインスタンスは、このインスタンスに関連するすべての後続のオペレーション上で使用されるユニークな識別子を割り当てられる。作成プラットフォームインスタンスアクションに提供されるプラットフォームデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにプラットフォームインスタンスの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい：
プロパティ＃１：oracle.cloud.service.weblogic.size
値：ベーシック、標準、エンタープライズ
説明：サブスクリプションタイプを規定する。これは、サーバの数、データベース限度およびサービス設定の質に影響を及ぼす。

【0112】

プロパティ＃２：oracle.cloud.service.weblogic.trial
値：真、偽
説明：これがトライアルサブスクリプションであるか否かを示す。

【0113】

プロパティ＃３：oracle.cloud.service.weblogic.crm
値：ＣＲＭサービスＩＤ
説明：このウェブロジックサービスインスタンスに関連付けられるべきＣＲＭサービスを特定する。

【0114】

図２６Ｃは、本発明の実施例に係るＮｕｖｉａｑシステムを使用するプロビジョニングプロセスのステップを示す例示的なシーケンス図を示す。図２６Ｃに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。

【0115】

インストール／更新アプリケーションの使用事例、すなわちインストールアプリケーションオペレーションは、アプリケーションアーカイブがパブリッククラウドのセキュリティ要件を満たすことを確認した後に、実行中のウェブロジックサーバにアプリケーションをデプロイする。一実施例では、インストールアプリケーションアクションに提供されるアプリケーションデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにアプリケーションの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい：
プロパティ：oracle.cloud.service.weblogic.state
値：実行、停止
説明：デプロイメント後のアプリケーションの初期状態を規定する。

【0116】

図２６Ｄは、本発明の実施例に係るＮｕｖｉａｑシステムを使用するデプロイメントプロセスのステップを示す例示的なシーケンス図を示す。図２６Ｄに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。

【0117】

したがって、特定の実施例では、協働して動作するＴＡＳ２１０４およびＳＤＩ２１０６は、クラウドインフラストラクチャシステム２０００によって提供される一組のサービスから顧客によってオーダーされた１つ以上のサービスのためにリソースをプロビジョニングすることを担当する。例えば、一実施例では、データベースサービスをプロビジョニングするために、自動化されたプロビジョニングフローは、有料サブスクリプションについては以下のようなものであってもよい：
（１）顧客は、ストアＵＩ２１１０を介して、サービスの有料サブスクリプションのオーダーを行なう。

【0118】

（２）ＴＡＳ２１０４がサブスクリプションオーダーを受取る。
（３）サービスが利用可能であると、ＴＡＳ２１０４は、ＳＤＩ２１０６のサービスを使用することによってプロビジョニングを開始する。ＴＡＳ２１０４は、ビジネスプロセスのオーケストレーションを実行してもよく、関連のビジネスプロセスを実行してオーダーのプロビジョニング局面を完了する。一実施例では、ＴＡＳ２１０４は、プロビジョニングに関わるステップをオーケストレートして、ライフサイクルオペレーションを処理するために、ＢＰＥＬ（ビジネスプロセス実行言語：Business Process Execution Language）プロセスマネージャを使用し得る。

【0119】

（４）一実施例では、データベースサービスをプロビジョニングするために、ＳＤＩ２１０６は、要求を行っている顧客にスキーマを関連付けるようにＣＬＯＵＤ＿ＵＩにおけるＰＬＳＱＬ ＡＰＩを呼出し得る。

【0120】

（５）顧客へのスキーマの関連付けが成功した後、ＳＤＩはＴＡＳに知らせて、ＴＡＳは、データベースサービスが現在顧客によって使用可能な状態にあるという通知を顧客に送る。

【0121】

（６）顧客は、（例えばcloud.oracle.comなどのＵＲＡＬを使用して）クラウドインフラストラクチャシステム２０００にログインし、サービスを起動し得る。

【0122】

いくつかの実施例では、顧客は、トライアルベースでサービスにサブスクライブすることも許可されてもよい。例えば、このようなトライアルオーダーは、（例えばcloud.oracle.comを使用して）クラウドＵＩ２１１２を介して受取られ得る。

【0123】

特定の実施例では、クラウドインフラストラクチャシステム２０００は、顧客またはテナント同士の間で基本的なハードウェアおよびサービスインスタンスが共有されることを可能にする。例えば、データベースサービスは、一実施例では、図２６Ｅに示されるようにプロビジョニングされ得る。図２６Ｅは、複数のＥｘａｄａｔａ演算ノード２６３０および２６３２を示し、演算ノード２６３０および２６３２の各々が、データベースサービスのためにプロビジョニングされたデータベースインスタンスを提供する。例えば、演算ノード２６３０は、データベースサービスのためのデータベース２６３４を提供する。各々のＥｘａｄａｔａ演算ノードは、複数のデータベースインスタンスを有していてもよい。

【0124】

特定の実施例では、各データベースインスタンスは、複数のスキーマを備えていてもよく、当該スキーマは、異なる顧客またはテナントに関連付けられてもよい。例えば、図２６Ｅでは、データベース２６３４は、２つのスキーマ２６３６および２６３８を提供し、スキーマ２６３６および２６３８の各々は、それ自体の表を有する。スキーマ２６３６は、データベースサービスにサブスクライブする第１の顧客またはテナントに関連付けられ得て、スキーマ２６３８は、データベースサービスにサブスクライブする第２の顧客またはテナントに関連付けられ得る。各テナントは、完全に切離されたスキーマを得る。各スキーマは、関連付けられたテナントについての表、ビュー、格納されたプロシージャ、トリガなどを含むデータベースオブジェクトを管理できる容器のように動作する。各スキーマは、１つの専用の表領域を有し得て、各々の表領域は、１つのデータファイルを有する。

【0125】

このように、単一のデータベースインスタンスは、複数のテナントにデータベースサービスを提供することができる。これは、基本的なハードウェアリソースの共有を可能にするだけでなく、テナント同士の間でのサービスインスタンスの共有も可能にする。

【0126】

特定の実施例では、このようなマルチテナンシシステムは、ＩＤＭ２１００によって容易になり、これにより、各々がそれ自体の別個のアイデンティティドメインを有する複数の別個の顧客が、クラウドにおいて共有されるハードウェアおよびソフトウェアを使用することが有利に可能になる。その結果、各顧客が自身の専用のハードウェアまたはソフトウェアリソースを有する必要がなくなり、場合によっては、特定の時点で一部の顧客によって使用されていないリソースが、他の顧客によって使用可能になり、それによってそれらのリソースが無駄になることを防止する。例えば、図２６Ｅに示されるように、データベースインスタンスは、各々がそれぞれのアイデンティティドメインを有する複数の顧客に供給されることができる。各々のこのようなデータベースサービスインスタンスは、多くの別個のアイデンティティドメインの中で共有される単一の物理的なマルチテナントデータベースシステムの別個の抽象化またはビューであり得るが、各々のこのようなデータベースサービスインスタンスは、各々の他のデータベースサービスインスタンスが有するものとは別個の、場合によっては異なるスキーマを有することができる。したがって、マルチテナントデータベースシステムは、顧客別のデータベーススキーマとそれらのデータベーススキーマが関係するアイデンティティドメインとの間のマッピングを格納し得る。マルチテナントデータベースシステムは、特定のアイデンティティドメインのためのデータベースサービスインスタンスに、当該特定のアイデンティティドメインにマッピングされるスキーマを使用させ得る。

【0127】

また、マルチテナンシは、Ｊａｖａサービスなどの他のサービスに拡張可能である。例えば、複数の顧客は、それぞれのアイデンティティドメイン内に配置されたＪＡＶＡサービスインスタンスを有し得る。各々のこのようなアイデンティティドメインは、ハードウェアの仮想的な「スライス」とみなされることができるＪＡＶＡ仮想マシンを有し得る。一実施例では、ジョブモニタリングサービス（例えばハドソン）は、各々の別個のアイデンティティドメインがＪＡＶＡエンタプライズエディションプラットフォームのそれ自体の別個の仮想的な「スライス」を有することを可能にするように、クラウドにおけるＪＡＶＡエンタプライズエディションプラットフォーム（例えばオラクルウェブロジック）と組み合わせられてもよい。このようなジョブモニタリングサービスは、例えばオペレーティングシステムの時間ベースのジョブスケジューラによって実行されるソフトウェアプロジェクトまたはジョブの構築などの繰返されるジョブの実行をモニタリングし得る。このような繰返されるジョブは、ソフトウェアプロジェクトの連続的な構築および／またはテストを含んでいてもよい。さらにまたは代替的に、このような繰返されるジョブは、ジョブモニタリングサービスが実行されるマシンから離れたマシン上で実行されるオペレーティングシステム起動ジョブの実行のモニタリングを含んでいてもよい。

【0128】

上述のように、シングルＩＤＭシステムは、複数の層および複数のサブシステムを含み得る。これらのサブシステムの少なくとも一部は、水平に互いに対して概念的に指向され得る（conceptually oriented）ため、これらはＩＤＭシステムの同一層内に概念的に位置している。しかしながら、ＩＤＭシステムの異なるコンポーネントは、これらの異なる層間に位置し得る。概念的に最底の層には、ＩＤＭシステムのアイデンティティデータが格納され得る。他の種類の情報のうち、アイデンティティデータは、ユーザアイデンティティおよび定義を含み得る。アイデンティティデータは、ＩＤＭシステムにより知られるすべてのエンティティのアイデンティティを、それらのエンティティが制限される（confined）特定のパーティションまたはアイデンティティドメインにかかわらず含み得る。このようなエンティティは、ＩＤＭシステムと対話する人間を含み得る。このようなエンティティは、人間以外のシステムを含み得る。

【0129】

アイデンティティデータ内に格納されたアイデンティティは、ディレクトリとして編成され得る。ＩＤＭシステムと対話するさまざまな製品は、ディレクトリに対する認識（awareness）を有するように構成および設計され得る。このような製品は、例えば、シングルサインオン（single sign-on: ＳＳＯ）機能を実現するアイデンティティマネージャおよび／またはアクセスマネージャを含み得る。実施例では、ＩＤＭシステムについてのアイデンティティのすべてがＩＤＭシステムの概念的に最底の層に格納され得るが、これらのアイデンティティは、互いに分離されるパーティションに編成されることもできる。ある意味、アイデンティティデータは、ＩＤＭシステムのコアとして想像され得る。数多くのさまざまなアイデンティティ管理サービスは、このパーティショニングにより達成される分離に依拠し得る。これらのアイデンティティ管理サービスは、テナンシの抽象化を提供し得る。ＩＤＭシステムの各特定の層において、その特定の層内に存在するサブシステムは、直下の層（最底層を除く）内に存在するサブシステムにより提供されるテナンシの抽象化に依拠し得、その特定の層内のサブシステムは、直上の層（最上層を除く）内に存在するサブシステムにテナンシの抽象化を提供し得る。

【0130】

発明の実施例は、シングルＩＤＭシステムを複数の別個のアイデンティティドメインに分割し得る。ＩＤＭシステムにより管理されるデータは、アイデンティティドメインにより分割され得る。特定のアイデンティティドメインに所属するデータは、他のすべてのアイデンティティドメインから分離され得る。上述のように、ＩＤＭシステムは、複数の別個のテナントにより共有され得る。このような各テナントは、ＩＤＭシステム内に自身の組織についてアイデンティティドメインを作成した顧客であり得る。したがって、アイデンティティドメインは、セキュリティ的観点から分離の単位としてみなされてもよい。アイデンティティドメイン、またはテナンシは、そのテナントについてセキュリティ分離を提供し得る。一実施例では、単一の顧客は、ＩＤＭシステム内の複数の別個のアイデンティティドメイン、またはテナンシを作成し得る。例えば、単一の顧客は、ＩＤＭシステムプロバイダから、テスト目的専用の１つのアイデンティティドメインと、本番（production）目的専用の別のアイデンティティドメインを購入する可能性がある。

【0131】

発明の実施例では、下層アイデンティティストアを利用する上層サブシステムは、アイデンティティドメインがアイデンティティストアにマッピングされるか態様に対する認識を有するように設計され得る。これらの上層サブシステムは、アイデンティティストアからアイデンティティドメインハンドルを受取り得る。これらの上層サブシステムは、このようなアイデンティティドメインハンドルを用いて、アイデンティティドメインとアイデンティティストアとの間のマッピングを作成し得る。ＩＤＭシステムの各層において、その層内のサブシステムは、ＩＤＭシステムの他の層からの情報のコンシューマとなり得る。各サブシステムは、そのアイデンティティドメインハンドルを用いて、アイデンティティストアのそのパーティションに関係する情報を管理することができる。特定の層内のサブシステムは、そのアイデンティティドメインハンドルを直下の下層内のサブシステムに引渡して、それらのサブシステムがアイデンティティストアの正確なパーティションと対話することを保証することができる。

【0132】

さまざまな異なるサブシステムは、マルチテナントＩＤＭシステムを作成する際に役割を果たし得る。例えば、ＳＳＯサブシステムは、ＩＤＭシステム内の複数の別個のＳＳＯデプロイメントの出現を招くように設計され得る。各サブシステムは、そのメタデータが含まれているランタイムコンポーネントおよびレポジトリを含み得る。このような各ランタイムコンポーネントは、マルチテナント環境下で別個のアイデンティティドメインと対話するように設計され得る。

【0133】

アプリケーションも同様に、マルチテナント環境下で別個のアイデンティティドメインと対話するように設計され得る。例えば、このような環境下の２つの異なるアプリケーションが互いと対話でき、このようなアプリケーションの両方がマルチテナント・アウェア（multi-tenant aware）であり得る。このような状況下では、ユーザがアプリケーションの第１のアプリケーションと対話すると、第１のアプリケーションは、ユーザが所属する（アイデンティティドメインのセットからの）アイデンティティドメインを決定することができる。この決定を行った後、次に、第１のアプリケーションは、ユーザのアイデンティティドメインを第２のアプリケーションに通信することができる。次に、第２のアプリケーションは、データを得るときのユーザのアイデンティティドメインに関係する、第２のアプリケーションのレポジトリ内の、適正なデータパーティションに問合せることができる。概念的には、アイデンティティドメインは、マルチテナント・アウェアなアプリケーションインスタンスにわたって情報の１つのスライスを相関付けることとして想像され得る。

【0134】

クラウドコンピューティング環境下では、一部のアプリケーションはマルチテナント・アウェアであり得、他のアプリケーションはマルチテナント・アウェアでない可能性がある。本明細書中では、マルチテナント・アウェアでないアプリケーションを「シングルテナントアプリケーション」と呼び、マルチテナント・アウェアなアプリケーションを「マルチテナントアプリケーション」と呼ぶ。一実施例では、特定のアイデンティティドメイン専用のシングルテナントアプリケーションのインスタンスは、その特定のアイデンティティドメインに所属するエンティティによってのみ用いられ得る。例えば、オラクルフュージョンアプリケーションの別個のインスタンスは、そのアプリケーションがプロビジョニングされた各アイデンティティドメインにインスタンス化され、当該アイデンティティドメイン専用となり得る。特定のサービスインスタンスは、特定のアイデンティティドメイン専用となり得るため、各別個のアイデンティティドメインは、その特定のサービスのそれ自身の専用インスタンスを有し得る。クラウドコンピューティング環境内に生じる各トランザクションは、そのトランザクションに関わるアプリケーションがシングルテナントアプリケーションまたはマルチテナントアプリケーションかどうかにかかわらず、アイデンティティドメインのコンテキストで行われ得る。

【0135】

図１は、発明の実施例に係る、テナントの視点から共有のＩＤＭシステム１００の例を概念的に示すブロック図である。共有ＩＤＭシステム１００は、共有のＩＤＭおよびセキュリティインフラストラクチャ１０２と、アイデンティティドメイン１１０Ａ、１１０Ｂおよび１１０Ｃにおけるサービスインスタンスと、テナントユーザ１１２Ａ、１１２Ｂ、および１１２Ｃとを含み得る。なお、テナントＡユーザ１１２Ａは、アイデンティティドメインＡ １１０Ａにおけるサービスインスタンスを使用でき、テナントＢユーザ１１２Ｂは、アイデンティティドメインＢ １１０Ｂにおけるサービスインスタンスを使用でき、テナントＣユーザ１１２Ｃは、アイデンティティドメインＣ １１０Ｃにおけるサービスインスタンスを使用できる。各アイデンティティドメインは、共有ＩＤＭシステム１００において互いから分離され得るため、各テナントのユーザは、そのテナントのアイデンティティドメインにおけるサービスインスタンスのみを使用することが許可され得る。上述のように、共有ＩＤＭシステム１００のプロバイダの特定の顧客は、クラウドコンピューティング環境内に、１つ以上のテナンシ、またはアイデンティティドメインを作成することができる。

【0136】

共有ＩＤＭシステム１００における各アイデンティティドメインは、別個の、場合によっては異なるセットのサービスインスタンスを含み得る。特定のアイデンティティドメイン内にサービスインスタンスの特定のセットを含むことは、その特定のアイデンティティドメインの顧客が共有ＩＤＭシステム１００のプロバイダからそれらのサービスインスタンスの使用を購入またはリースした結果であり得る。顧客がその顧客自身のネットワーク中にアプリケーションをデプロイすることのできる態様と同様に、顧客は、クラウドコンピューティング環境内でのサービスインスタンスの使用を購入またはリースすることができる。したがって、このようなサービスインスタンスは、顧客自身により所有または所持されないハードウェア、ソフトウェア、および／またはネットワークを介して提供され得る。アイデンティティドメインＡ １１０Ａにおけるサービスインスタンスは、データベースサービスインスタンス１１６Ａ、ＪＡＶＡサービスインスタンス１１８Ａ、およびフュージョン顧客関係管理（ＣＲＭ）サービスインスタンス１２０Ａを含み得る。アイデンティティドメインＢ １１０Ｂにおけるサービスインスタンスは、データベースサービスインスタンス１１６ＢおよびＪＡＶＡサービスインスタンス１１８Ｂを含み得る。アイデンティティドメインＣ １１０Ｃにおけるサービスインスタンスは、データベースサービスインスタンス１１６Ｃ、フュージョンＣＲＭサービスインスタンス１２０Ｃ、およびソーシャルネットワークサービス１２２Ｃを含み得る。一部のサービスインスタンスは、実際には各アイデンティティドメインにおける別個のシングルテナントインスタンスであり得るが、他のサービスインスタンスは、同一の単一のマルチテナントサービスインスタンスの現れ（manifestations）であり得る。例えば、データベースサービスインスタンス１１６Ａ、１１６Ｂおよび１１６Ｃはすべて、同一の単一のマルチテナントデータベースサービスインスタンスの現れであり得る。

【0137】

特定の顧客が特定のアイデンティティドメインと関連付けられたサービスインスタンスの特定のセットを望む場合、その特定の顧客は、特定の顧客がそのサービスインスタンスの特定のセットを購入またはリースするときに、その意向を共有ＩＤＭシステム１００のプロバイダに示すことができる。特定のアイデンティティドメイン内の（例えばユーザなどの）アイデンティティはすべて、その特定のアイデンティティドメインについての１つ以上のアイデンティティドメイン管理者により中心で管理され得る。例えば、特定のアイデンティティドメインは、３つの異なるユーザについてのアイデンティティを含む可能性がある。特定のアイデンティティドメインについてのアイデンティティ管理者は、第１のユーザがその特定のアイデンティティドメインのサービスインスタンスの第１のサブセットにアクセスできること、第２のユーザがその特定のアイデンティティドメインのサービスインスタンスの第２の異なるサブセットにアクセスできること、さらに、第３のユーザがその特定のアイデンティティドメインのサービスインスタンスの第３のさらに異なるサブセットにアクセスできることを特定することができる。したがって、ユーザの各々は、特定のアイデンティティドメインについてのアイデンティティドメイン管理者によりすべて特定されるとおりに、特定のアイデンティティドメインのサービスインスタンスの異なるサブセットにアクセスできる。

【0138】

一実施例では、特定のアイデンティティドメイン内のサービスインスタンスはすべて、ユーザのアイデンティティの同一の定義を用いることができる。典型的なエンタープライズシステムと同様に、アイデンティティドメイン内の各ユーザのアイデンティティが一旦作成され得る。次に、そのアイデンティティドメイン内に含まれるアプリケーションおよびサービスが、そのアイデンティティドメイン内に作成されたユーザアイデンティティに関する情報を得ることができる。アイデンティティドメイン管理者は、ユーザアイデンティティをアプリケーションおよびサービスにマッピングするためのさまざまな技術を使用することができる。例えば、このようなマッピングは、ロール、群、規則などの使用により構築され得る。アイデンティティドメインにおいて、関連付けられた許可および認可を有するロールが作成され得る。各ロールは、そのロールと関連付けられたユーザによりアクセス可能な異なるセットのアプリケーションおよびサービスと関連付けられ得る。次に、アイデンティティドメイン管理者は、各ロールを異なるセットのユーザアイデンティティと関連付けることにより、あるセットのアイデンティティドメインのユーザに、あるセットへのアイデンティティドメイン内のアプリケーションおよびサービスへのアクセスを付与することができる。代替的には、アイデンティティドメイン管理者は、あるユーザアイデンティティに直接、顧客指定のセットのアイデンティティドメインのアプリケーションおよびサービスへのアクセスを直接付与することもできる。発明の一実施例では、ロール自体が、共有ＩＤＭシステム１００のアイデンティティストア内にアイデンティティとしてフォーマットされ、格納されることができる。ユーザは、さまざまな異なるロールと関連付けられ得る。

【0139】

上述のように、一実施例では、共有ＩＤＭシステム１００について作成されたアイデンティティのすべては、同一のアイデンティティストア内に格納され得るが、このアイデンティティストアは、異なる「スライス」に分割され得、各スライスは、異なるアイデンティティドメインと関連付けられる。したがって、テナントＡユーザ１１２Ａのアイデンティティは、第１のスライスにおいて存在し得、テナントＢユーザ１１２Ｂのアイデンティティは、第２のスライスにおいて存在し得、テナントＣユーザ１１２Ｃのアイデンティティは、第３のスライスにおいて存在し得る。発明の一実施例では、共有ＩＤＭシステム１００のアイデンティティストアにおける各アイデンティティは、属性として、そのアイデンティティが所属するアイデンティティドメインを示すことができる。

【0140】

共有ＩＤＭシステム１００に含まれるアイデンティティドメインの各々は、それぞれオラクルプラットフォームセキュリティサービス１１２Ａ、１１２Ｂおよび１１２Ｃとして示される、オラクルプラットフォームセキュリティサービスの対応するインスタンスを含み得る。オラクルプラットフォームセキュリティサービス１１２Ａ、１１２Ｂおよび１１２Ｃの各々は、アイデンティティ情報へのアクセスを可能にするように設計されたアプリケーションプログラミングインターフェース（application programming interfaces: ＡＰＩｓ）の集合であり得る。共有のＩＤＭおよびセキュリティインフラストラクチャ１０２は、アイデンティティ管理モジュール１０４、ディレクトリサービスおよびポリシーストア１０６、ならびにアクセス管理モジュール１０８などの多くのさまざまなコンポーネントを含み得る。一実施例では、インフラストラクチャ１０２内のこのような各コンポーネントは、オラクルプラットフォームセキュリティサービス１１２Ａ、１１２Ｂおよび１１２ＣのＡＰＩを実現する。これらのＡＰＩは、アイデンティティドメインの各々を有するサービスインスタンスに、それらのサービスインスタンスがインフラストラクチャ１０２内のコンポーネントにアクセスして利用するために呼び出すことのできる方法を公開する（expose）ことができる。

【0141】

発明の一実施例では、特定の顧客が共有ＩＤＭシステム１００のプロバイダからサービスインスタンスを初めて購入またはリースするときに、その顧客について少なくとも１つのアイデンティティドメインが明示的にまたは暗黙的に作成される。代替的には、特定の顧客について、当該顧客と関連付けられて少なくとも１つのアイデンティティドメインが既に作成されている場合、共有ＩＤＭシステム１００のメカニズムは、顧客が、その特定の顧客について、当該顧客と関連付けられて既に作成されたアイデンティティドメインに新たに購入されるまたはリースされるサービスインスタンスが追加されることを望むかどうかを顧客に尋ねることができる。顧客がＹＥＳと答えた場合、共有ＩＤＭシステム１００は、新たに購入されるまたはリースされるサービスインスタンスを、既存のアイデンティティドメインと既に関連付けられた既存のサービスインスタンスのセットに追加することができる。このように、特定の顧客のサービスインスタンスは、それが特定の顧客の意図である場合には、すべて同一のアイデンティティドメインと関連付けられるようにできる。このようなサービスインスタンスは、例えば、さまざまなＳａａＳおよびＰａａＳインスタンスを含み得る。

【0142】

発明の一施例では、顧客は、当該顧客が集中型ストアを介してクラウドベースのサービスを購入することができるように、集中型ストアによるアカウントを確立することができる。このアカウントを用いて集中型ストアを介してサービスを購入すると、クラウドコンピューティング環境内にその顧客についてアイデンティティドメイン特有のアカウント（identity domain-specific account）が作成され得る。このアイデンティティドメイン特有のアカウントは、顧客が集中型ストアを介してクラウドベースのサービスを初めて購入した際に、顧客について作成されたアイデンティティドメインと関連付けられ、当該アイデンティティドメインに分離され得る。したがって、１つのアカウントは、集中型ストアと対話するように作成され得、別の別個のアカウントは、共有ＩＤＭシステム１００を介して作成されるアイデンティティドメインを管理し、処理するように作成され得る。

【0143】

一実施例では、アイデンティティドメインが顧客について作成されるとき、顧客は、顧客がそのアイデンティティドメインと、同一の顧客について作成された可能性のある他のアイデンティティドメインとを区別できるように、共有ＩＤＭシステム１００に、特定される名称および／またはユニフォーム・リソース・ロケーター（ＵＲＬ）をそのアイデンティティドメインに結び付けるように命令することができる。顧客およびそのユーザは、クラウドコンピューティング環境下で、結び付けられたＵＲＬを用いて、対応するアイデンティティドメイン、およびその含まれるサービスインスタンスにアクセスすることができる。

【0144】

インフラストラクチャ１０２のコンポーネントは、どの顧客について作成されたどの単一のアイデンティティドメインにも所属しない。インフラストラクチャ１０２は、代わりに、クラウドコンピューティング環境全体に所属しているとして想像され得る。しかしながら、発明の一実施例では、インフラストラクチャ１０２は、全体としてのクラウドコンピューティング環境についてのアイデンティティドメインと関連付けられ得る。この包括的なクラウドアイデンティティドメイン（「オペレーションアイデンティティドメイン」と呼ぶこともある）は、顧客と関連付けられたアイデンティティドメインと区別され得る。クラウドアイデンティティドメインに所属するユーザは、顧客のアイデンティティドメインのいずれか内のサービスインスタンスにアクセスし、当該サービスインスタンスを管理する権限を付与されることができる。本明細書中では、このようなユーザを「オペレーションユーザ」と呼ぶ。顧客サービス代表（customer service representatives: ＣＳＲ）は、ＣＳＲのために作成され、クラウドアイデンティティドメインと関連付けられたオペレーションユーザアイデンティティを有し得る。したがって、クラウドアイデンティティドメインは、ＣＳＲアイデンティティドメインとして見なされ得る。共通のセキュリティモデルは、アイデンティティドメインのユーザのそれらに対応するアイデンティティドメインへの分離を支配するだけでなく、すべてのアイデンティティドメインを中心で管理するのに必要なインタラクションを容易にすることもできる。したがって、共有ＩＤＭシステム１００は、顧客のアイデンティティドメインと関連付けられたユーザが、それらのアイデンティティドメインの外部のリソースに対するオペレーションを行なうのを防止するだけでなく、クラウドドメインと関連付けられたオペレーションユーザが、顧客のアイデンティティドメインにわたるリソースに対するオペレーションを行なうことを可能にすることもできる。したがって、テナンシの目的には、少なくとも次の２つの面がある。第１に、テナンシを互いから分離すること、第２に、（クラウドアイデンティティドメインの場合）他のテナンシを管理することである。

【0145】

図２は、発明の実施例に係る、共有ＩＤＭシステムを介して複数の顧客についての複数のアイデンティティドメインを作成するための技術２００の例を示すフローチャートである。技術２００は、ある順に行なわれるあるオペレーションを含むように示されているが、発明の代替的実施例は、異なる順で行なわれてもよい追加の、より少ない、または代替的なオペレーションを含み得る。ブロック２０２では、第１の顧客が共有ＩＤＭシステムを介して第１のアイデンティティドメインを作成する。ある実施例では、共有ＩＤＭシステムは、第１のアイデンティティドメインを作成するために第１のアイデンティティドメインをユニークに定義するメタデータを格納する。ブロック２０４では、第１の顧客が、共有ＩＤＭシステムを介してまたは共有ＩＤＭシステムに関連してサービスインスタンスの第１のセットを購入する。ブロック２０６では、サービスインスタンスの第１のセットにおけるサービスインスタンスが第１のアイデンティティドメインにマッピングされる。ある実施例では、共有ＩＤＭシステムは、第１の複数のサービスと第１のアイデンティティドメインとの間のマッピングを作成することにより、第１の複数のサービスと第１のアイデンティティドメインとを関連付ける。例えば、共有ＩＤＭシステムは、このようなマッピングをコンピュータ読取可能ストレージメモリ内に永久的に格納してもよい。なお、以下にさらに見られるように、いくつかの顧客の各々は、別個の分離されたアイデンティティドメインを確立する際に、同一の共有ＩＤＭシステムを利用することができるため、別個のＩＤＭシステムが顧客毎にインスタンス化される必要がない。ブロック２０８では、ユーザアイデンティティの第１のセットが共有ＩＤＭシステムを介して第１のアイデンティティドメイン内に作成される。ユーザアイデンティティの第１のセットにおけるユーザアイデンティティは、第１のアイデンティティドメインにマッピングされる。

【0146】

ブロック２１０では、第２の顧客が、共有ＩＤＭシステムを介して第２のアイデンティティドメインを作成する。ある実施例では、共有ＩＤＭシステムは、第２のアイデンティティドメインを作成するために第２のアイデンティティドメインをユニークに定義するメタデータを格納する。ブロック２１２では、第２の顧客が、共有ＩＤＭシステムを介してまたは共有ＩＤＭシステムに関連してサービスインスタンスの第２のセットを購入する。ブロック２１４では、サービスインスタンスの第２のセットにおけるサービスインスタンスが、第２のアイデンティティドメインにマッピングされる。ある実施例では、共有ＩＤＭシステムは、第２の複数のサービスと第２のアイデンティティドメインとの間のマッピングを作成することにより、第２の複数のサービスと第２のアイデンティティドメインとを関連付ける。例えば、共有ＩＤＭシステムは、このようなマッピングをコンピュータ読取可能ストレージメモリ内に永久的に格納してもよい。したがって、いくつかの顧客の各々は、別個の分離されたアイデンティティドメインを確立する際に、同一の共有ＩＤＭシステムを利用することができるため、別個のＩＤＭシステムが顧客毎にインスタンス化される必要がない。ブロック２１６では、ユーザアイデンティティの第２のセットが、共有ＩＤＭシステムを介して第２のアイデンティティドメイン内に作成される。ユーザアイデンティティの第２のセットにおけるユーザアイデンティティは、第２のアイデンティティドメインにマッピングされる。

【0147】

ブロック２１８では、共有ＩＤＭシステムが、ユーザインスタンスの第２のセット間でなく、サービスインスタンスの第１のセット間でユーザアイデンティティの第１のセットにおけるユーザアイデンティティを共有する。ある実施例では、共有ＩＤＭシステムは、各ユーザベースのマッピング（per-user-based mappings）に少なくとも一部基づいて、ユーザの第１のセットのアイデンティティを共有する。ブロック２２０では、共有ＩＤＭシステムが、ユーザインスタンスの第１のセット間でなく、サービスインスタンスの第２のセット間でユーザアイデンティティの第２のセットにおけるユーザアイデンティティを共有する。ある実施例では、共有ＩＤＭシステムは、各ユーザベースのマッピングに少なくとも一部基づいて、ユーザの第２のセットのアイデンティティを共有する。ユーザアイデンティティの第１および第２のセットは、いずれも同一の共有ＩＤＭシステムの同一のアイデンティティストアに格納されてもよい。ブロック２２２では、第１のアイデンティティドメインについての第１のアイデンティティドメイン管理者が、共有ＩＤＭシステムを用いてユーザアイデンティティの第１のセットを管理する。ブロック２２４では、第２のアイデンティティドメインについての第２のアイデンティティドメイン管理者が、共有ＩＤＭシステムを用いてユーザアイデンティティの第２のセットを管理する。ユーザアイデンティティの管理は、例えば、ユーザアイデンティティを追加する、ユーザアイデンティティを消去する、ユーザアイデンティティの属性を修正する、ユーザアイデンティティおよびロールおよび／または群の間の関連付けを追加または削除する、ロールおよび／または群を作成する、ユーザ、ロール、および／または群に対してサービスインスタンスアクセス許可を付与するまたは削除すること等を含み得る。発明の一実施例では、このような管理は、共有ＩＤＭシステムにより提供される管理者インターフェイスを介して行なうことができる。さまざまな異なるアイデンティティドメインの管理は、このような管理者インターフェイスを介して行なうことができる。したがって、共有ＩＤＭシステム１００は、それぞれのユーザに割り当てられた１つ以上のサービスを定義するマッピングに少なくとも一部基づいて、ユーザの第１のセットにおけるユーザが、サービスの第１のセットでなく、サービスの第２のセットにおけるサービスに対するオペレーションを行なうことを防止する。

【0148】

発明の一実施例では、さまざまなポリシーが共有ＩＤＭシステム内に特定され得る。このような各ポリシーは、そのポリシーが全体として満たされる場合に満たされなければならない規則のセットを含み得る。あるポリシーは、そのポリシーの規則がすべて満たされた場合にのみサービスインスタンスまたはシステムリソースへのアクセスが付与されることを特定し得る。特定のユーザが顧客のアイデンティティドメインのサービスインスタンスにアクセスするためには、その特定のユーザのアイデンティティが同一のアイデンティティドメインに所属しなければならないという暗黙的なポリシーも存在し得る。しかしながら、この暗黙的なポリシーは、任意の顧客のアイデンティティドメインの外部に存在し得るオペレーションユーザが、任意の顧客のアイデンティティドメインのサービスインスタンスにアクセスすることを許可することができる。マルチテナントＩＤＭシステムでは、各ポリシーは、特定のアイデンティティドメインと関連付けられたサービスインスタンスが、その特定のアイデンティティドメイン内に分離されるという意向を反映するように作られ得る。

【0149】

例えば、クラウドコンピューティング環境は、ディレクトリおよびＳＳＯシステムなどのアクセス管理システムを含んでもよい。ＳＳＯシステムは、数多くのＵＲＬを保護することができる。ＳＳＯシステムは、特定されるセットのＵＲＬを保護するが、特定されるセット内にないＵＲＬは保護しないように構成され得る（すなわち、後者のＵＲＬは保護されない）。クラウドコンピューティング環境内の単一のホストマシンは、複数の異なるＵＲＬに関連付けられ得る。概念的には、クラウドコンピューティング環境内の各ホストマシンは、そのホストマシンとそのホストマシンにアクセスしたいユーザとの間に立っているマルチプルゲートを有するとして想像され得る。ユーザが特定のホストマシンと関連付けられたＵＲＬにアクセスしようとするとき、ＳＳＯシステムは、そのユーザを適切なホストマシンに転送することができる。ホストマシンを保護するゲートは、ホストマシンにアクセスするために用いられている完全修飾ＵＲＬを調べることができる。このゲートは、ユーザをＳＳＯサーバに転送するか、またはそのホストマシンおよびＵＲＬに関係するポリシーを参照して実行することができる。このようなポリシーは、ユーザが認証されるべきであること、ユーザの属性が発見されるべきであること、さらに、ユーザの属性に基づいて、ユーザがＵＲＬを用いてホストマシンにアクセスすることを許されるか否かについて決定するべきであることを示し得る。発明の一実施例では、このようなポリシーは、共有ＩＤＭシステムにより定義されるアイデンティティドメインの境界を反映するために向上され得る。

【0150】

図３は、発明の実施例に係る、階層型クラウドベースのＩＤＭシステム３００の概略の例を示すブロック図である。クラウドベースのＩＤＭシステム３００は、クラウドセキュリティファンデーション層３０２、クラウド共有ＩＤＭ層３０４、およびオラクルＩＤＭ／セキュリティ層３０６などの複数の層を含み得る。一実施例では、クラウドセキュリティファンデーション層３０２は、クラウド共有ＩＤＭ層３０４と遣り取りし、クラウド共有ＩＤＭ層３０４は、オラクルＩＤＭ／セキュリティ層３０６と遣り取りする。オラクルＩＤＭ／セキュリティ層３０６は、「生の」アイデンティティ管理システムを実現できる。クラウド共有ＩＤＭ層３０４は、各テナントのデータを分離するためのモデルを含み、これにより、複数のテナントおよび分離されたアイデンティティドメインの概念を支持する「生の」アイデンティティシステムの抽象化を作成することができる。各層は、複数のサブ層およびサブシステムを含み得る。これらの一部を以下にさらに説明する。

【0151】

図４は、発明の実施例に係る、クラウドセキュリティファンデーション層４００のサブシステムの例を示すブロック図である。図４のクラウドセキュリティファンデーション層４００は、図３のクラウドセキュリティファンデーション層３０２に相当し得る。セキュリティファンデーション層４００は、テナント管理委任モデル４０４、クラウドインフラストラクチャライフサイクル＆ランタイムモデル４０６、オペレーションユーザライフサイクル４０８、共通ポリシー４１０、クラウド公開キーインフラストラクチャ（ＰＫＩ）キープロビジョニング４１２、ならびにアイデンティティストアおよびポリシーストアについてのデータセキュリティ４１４などの複数のサブシステムを含み得る。

【0152】

テナント管理委任モデル４０４は、アイデンティティドメインのアーキテクチャの存在および、それらのアイデンティティドメインとサービスインスタンスとの関連付けを考慮したモデルであり得る。このモデルは、アイデンティティドメインに関連付けられたさまざまなユーザが、アイデンティティドメインまたはその中の要素に対して有するロールを特定するために用いられ得る。モデルは、各ロールに付与される（例えば、サービスインスタンス、ユーザ、ロールなどに対する）許可を特定することができる。テナント管理委任モデル４０４は、アイデンティティドメインを購入した顧客が、ユーザをそのアイデンティティドメインについてのアイデンティティドメイン管理者に任命することを可能にし得る。一実施例では、このような顧客は、クラウドセキュリティファンデーション層４００のコンポーネントを用いて、ロールの階層を作成することができる。このような階層は、アイデンティティドメインの最初の作成時に暗黙的に作成され得、具体的には、その作成が階層の作成を招いたアイデンティティドメインに関係し得る。したがって、各アイデンティティドメインは、別個の、場合によっては異なるロールの階層に関連付けられ得る。一実施例では、階層のトップまたはルートに暗黙的に作成されたロールは、アイデンティティドメインについてのアイデンティティドメイン管理者のロールである。各アイデンティティドメインは、１つ以上のアイデンティティドメイン管理者を有し得る。アイデンティティドメイン管理者は、アイデンティティドメイン内に存在するすべてのサービスインスタンス、ユーザ、および他のロールを含む、アイデンティティドメインを全体的に管理するのに十分な許可および権限（authorities）を有し得る。

【0153】

ロール階層のアイデンティティドメイン管理者の下に、サービス管理者を置くことができる。本明細書中では、「サービス管理者」という用語は、アイデンティティドメイン内のサービスインスタンスを管理する許可を有するロールの分類を記載するために用いられるが、「サービス管理者」と呼ばれるロールは必ずしも存在せず、むしろ、「サービス管理者」の分類にすべて該当するさまざまな特定のロールが存在し得る。例えば、各タイプのサービスインスタンスは、そのサービスを管理するサービス管理者ロールのタイプを有し得る。サービス管理者ロールの例としては、ＪＡＶＡサービス管理者、データベースサービス管理者、フュージョンアプリケーション管理者などが挙げられる。アイデンティティドメイン管理者は、クラウドセキュリティファンデーション層４００のコンポーネントを用いて、そのアイデンティティドメインと関連付けられた１つ以上のユーザをサービス管理者に任命することができる。「サービス管理者」は、ロール自体ではなくロールの分類であり得ることから、アイデンティティドメイン管理者が他のユーザをサービス管理者ロールに任命するために用いるユーザインターフェイスは、アイデンティティドメイン管理者がユーザを任命することの可能な各特定のタイプのサービス管理者ロール（例えば、ＪＡＶＡサービス管理者、データベースサービス管理者、フュージョンアプリケーション管理者など）を列挙してもよい。各サービス管理者は、そのアイデンティティドメイン内の特定のサービスインスタンスを処理し、管理するために必要な許可および権限を有し得る。各サービス管理者は、当該サービス管理者が管理する特定のサービスインスタンスに特定的に関連し、範囲が限定されたロールを管理するために必要な許可および権限を有し得る。しかしながら、特定のサービス管理者は、他のサービスインスタンスを管理する、またはアイデンティティドメインを全体的に処理するための権限を必ずしも有さない。各サービスインスタンスは、それ自体の別個のサービス管理者を有し得る。場合によっては、同一のユーザが、同一のアイデンティティドメインにおける複数のサービスインスタンスについてのサービス管理者に任命されることもあり得る。アイデンティティドメイン管理者は、サービス管理者が実行できる機能のすべてを実行することができる。なぜなら、アイデンティティドメイン管理者は、ロール階層においてより高い階層にあっても、その逆ではないためである。一実施例では、アイデンティティドメインにおいてサービスインスタンスが作成され得る各サービスの設計者は、そのサービスと関連付けられたサービス設計者により定義されるロールの階層が、典型的には階層のルートにおいて、そのサービス全体についてのサービス特有のサービス管理者ロールを含むことを保証する任務を与えられる。

【0154】

図７は、発明の実施例に係る、アイデンティティドメインを管理するためにロール階層を用いることができるクラウドベースのＩＤＭシステム７００の例を示すブロック図である。図７は、顧客（ストアアカウント管理者）７０２、顧客アイデンティティドメイン７０４、およびクラウドアイデンティティドメイン７０８を示す。顧客７０２は、実際にはどのアイデンティティドメイン内にも必ずしも存在するわけではない。代わりに、顧客７０２は、オンラインストアによるストアを有し得る。したがって、顧客７０２は、完全にクラウドベースのシステムの外側のアカウントであり得るストアアカウントの管理者である。顧客７０２は、このアカウントを用いて、顧客アイデンティティドメイン７０４などの１つ以上のアイデンティティドメインを購入し、さらに、このようなアイデンティティドメイン内にデプロイされるサービスインスタンスを購入することができる。顧客７０２は、バイヤとして行動することができる。顧客７０２は、アイデンティティドメイン内のユーザアイデンティティを必ずしも有さないため、オンラインストアを介して顧客アイデンティティドメイン７０４を購入するとき、顧客７０２は、顧客アイデンティティドメイン７０４についてのアイデンティティドメイン管理者７１０（以下にさらに詳しく説明する）に別のユーザを（例えば、その別のユーザの電子メールアドレスをオンラインストアに特定することにより）指名することができる。このように、顧客アイデンティティドメイン７０４内のユーザアイデンティティを有するユーザは、顧客７０２がこのようなユーザアイデンティティを有していなくても、顧客アイデンティティドメイン７０４にアクセスすることができる。

【0155】

顧客アイデンティティドメイン７０４は、顧客アイデンティティドメイン７０４内の範囲にあり、どの他のアイデンティティドメインにもわたらないさまざまなロールを割り当てられたユーザを含む。これらのロールの中には、上記のアイデンティティドメイン管理者７１０のロールがあり得る。アイデンティティドメイン管理者７１０は、顧客７０２により指名され得る。アイデンティティドメイン管理者７０２は、そのロールの一部として、自身が有する許可および権限の少なくとも一部を、顧客アイデンティティドメイン７０４内の他のロールに委任することができる。これらの他のロールは、アイデンティティ管理者７１２、ＪＡＶＡサービス管理者７１４、データベースサービス管理者７１６、およびフュージョンアプリケーション管理者７１８などのサービスおよびアプリケーション管理者ロールを含み得る。これらのサービス管理者の各々は、限定されないが、顧客アイデンティティドメイン７０４内の特定のサービスインスタンスに対するユーザおよびロールの処理および管理に必要な許可および権限を有し得る。

【0156】

アイデンティティ管理者７１２は、顧客アイデンティティドメイン７０４内のロール管理７２０およびユーザ管理７２２のタスクを行なう許可を有し得る。アイデンティティ管理者７１２は、ロール管理７２０およびユーザ管理７２２を顧客アイデンティティドメイン７０４内の他のユーザアイデンティティにロールとして委任することができる。これらの許可により、例えば、顧客アイデンティティドメイン７０４に関係するユーザアイデンティティおよびロールアイデンティティが管理され得る（例えば、パスワードリセットオペレーションなど）。アイデンティティ管理者７１２は、アイデンティティドメイン管理者７１０と同一のユーザであり得る。ＪＡＶＡサービス管理者７１４は、ＪＡＶＡ管理者７２４のタスクを行なう許可を有し得る。ＪＡＶＡサービス管理者７１４は、ＪＡＶＡ管理者７２４を顧客アイデンティティドメイン７０４内の他のユーザアイデンティティにロールとして委任することができる。これらの許可により、ＪＡＶＡ仮想マシンは、例えば、インスタンス化され、修正され、消去されることができる。データベースサービス管理者７１６は、データベース特有のロールを顧客アイデンティティドメイン７０４内の他のユーザに割り当てる許可を有し得る。これらのデータベース特有のロールは、ユーザ７２６、開発者７２８、および管理者７３０のロールを含み得る。このような各ロールは、データベースサービスインスタンスに対する異なる許可を有し得る。例えば、ユーザ７２６は、ユーザ７２６がデータベースのテーブルに格納されたデータに問合せるおよび、さもなければ使用することを可能にする許可に限定され得る。開発者７２８は、開発者７２８が、例えばシステムパラメータを含む、データベースのコンフィグレーションを修正することを可能にする許可を追加的に有し得る。管理者７３０は、データベースサービスインスタンスに対する他のユーザの管理を含む、そのサービスインスタンスに対するアクションをすべて行なう許可を有し得る。管理者７３０は、データベースサービス管理者７１６と同一のユーザであり得る。フュージョンアプリケーション管理者７１８は、フュージョンアプリケーションインスタンスによる使用のためのＣＲＭ階層７３２を作成し、修正する許可を有し得る。これらの許可を用いて、フュージョンアプリケーション管理者は、顧客アイデンティティドメイン７０４内のユーザアイデンティティを有するユーザをＣＲＭ階層７３２内に置くことができる。フュージョンアプリケーション管理者７１８は、ＣＲＭ階層７３２における各ポジションについてのロールおよび対応する許可を定義する許可を有し得、このような各ロールは、フュージョンアプリケーションインスタンスに対するオペレーションの実行に限定されている。他のサービス管理者ロールを定義し、割り当てることもできる。

【0157】

一実施例では、上述のように、（典型的には、顧客アイデンティティドメイン７０４の作成の際に）顧客７０２により指名されたアイデンティティドメイン管理者７１０は、許可およびサービスインスタンスロールを顧客アイデンティティドメイン７０４内の他のユーザに委任することができる。さらに、一実施例では、顧客７０２は、顧客アイデンティティドメイン７０４内のユーザを、それらのサービスインスタンスロールを有するサービス管理者になるように直接指名することができる。例えば、一実施例では、顧客７０２は、アイデンティティドメイン管理者７１０、アイデンティティ管理者７１２、ＪＡＶＡサービス管理者７１４、データベースサービス管理者７１６、およびフュージョンアプリケーション管理者７１８の各々を直接指名することができる。一実施例では、顧客７０２は、これらの他のユーザをサービスインスタンスロールに、それらのロールが関係するサービスインスタンスの購入の一部として指名することができる。例えば、顧客７０２は、サービスインスタンスを購入するとき、当該サービスインスタンスが購入されているオンラインストアに、顧客７０２がそのサービスインスタンスについてのサービスインスタンス管理者に指名しているユーザの１つ以上の電子メールアドレスを特定することができる。顧客７０２により特定されたアイデンティティドメイン内に、これらの電子メールアドレスを有するユーザについてユーザアイデンティティが自動的に作成され得、これらのユーザは、顧客７０２により特定されたサービスインスタンスについてのサービス管理者ロールを割り当てられ得る。

【0158】

さらに、上述のように、クラウドベースのＩＤＭシステム７００は、顧客アイデンティティドメイン７０４などの顧客アイデンティティドメインに加えて、クラウドアイデンティティドメイン７０８などの包括的なクラウドアイデンティティドメインも含み得る。クラウドアイデンティティドメイン７０８は、上述のオペレーションユーザを含み得る。クラウドアイデンティティドメイン７０８は、どの顧客にも所属しておらず、どの顧客からも独立して存在する。クラウドアイデンティティドメイン７０８におけるユーザは、顧客アイデンティティドメイン７０４などの顧客アイデンティティドメイン（同様に、クラウドベースＩＤＭシステム７００内に存在し得る図示されない他の顧客アイデンティティドメイン）内のロール、ユーザ、およびサービスインスタンスを管理する許可を有し得る。オペレーションロール階層（operational role hierarchy）７３４がクラウドアイデンティティドメイン７０８内に定義され得る。オペレーションロール階層７３４は、クラウドアイデンティティドメイン７０８におけるオペレーションユーザの各々について、そのオペレーションユーザにより所有される許可、権限、およびロールを定義することができる。クラウドアイデンティティドメイン７０８内に定義されたポリシーは、あるオペレーションロールがどの顧客アイデンティティドメインにアクセス可能であるか、および、あるオペレーションロールがそれらの顧客アイデンティティドメイン内のサービス、ユーザ、およびリソースに対して行なうことのできるオペレーションのタイプに限定を設けることができる。例えば、クラウドアイデンティティドメイン７０８内のオペレーションユーザアイデンティティ（operational user identities）のサブセットは、アイデンティティ管理機能の実行のロールおよび／またはポリシーによって限定され得るが、これらのオペレーションユーザアイデンティティは、クラウドベース環境下でどの顧客アイデンティティドメインにおいても定義されるアイデンティティに対してこのようなアイデンティティ管理機能を実行する能力を有してもよい。各アイデンティティドメインでは、ランタイムインスタンスがこのようなポリシーを実施し得る。

【0159】

クラウドベースのＩＤＭシステム７００では、ロールは階層的に定義され得る。階層における下位レベルのロールに利用可能な権限および許可は、その階層における上位レベルのロールにより継承され得る。ロール階層における別のロールの親または先祖ロールは、子どもまたは子孫ロールに利用可能な権限および許可を継承し得る。したがって、アイデンティティ管理者７１２は、ロール管理７２０およびユーザ管理７２２ロールのロールおよび対応する許可ベースの能力を継承し得、アイデンティティドメイン管理者７１０は、アイデンティティ管理者７１２のロールおよび対応する許可ベースの能力を継承し得るが、継承は、階層において反対方向には流れない。一実施例では、ロール階層は、各サービスインスタンスについて、当該サービスインスタンスがアイデンティティドメインに追加されるときに自動的に作成され、後に、そのロール階層内のロールは、それを行なう許可を有するユーザにより割り当てられるおよび／または修正され得る。各サービスインスタンスのロール階層は、他のサービスインスタンスについてのロール階層に定義されるロールとは異なるロールを定義することができる点で異なり得る。

【0160】

一実施例では、サービスインスタンスについて予め定義された（場合によっては何千もの）ロールが、アイデンティティドメインに追加されているサービスインスタンスのタイプに基づいて自動的にアイデンティティドメイン内に作成され得、ユーザは、必ずしも各ロール階層における各ロールを手動で定義する必要はない。各タイプのサービスは、そのサービスの任意のインスタンスの任意のアイデンティティドメインへの追加の前に、サービスの作成者により予め定義され、かつサービスインスタンスがアイデンティティドメインに追加されるときに自動的に作成され得るサービスタイプロール階層と関連付けられ得る。例えば、データベースサービスは、予め定義されたデータベースサービスロール階層と関連付けられ得、ＪＡＶＡサービスは、予め定義されたＪＡＶＡサービスロール階層と関連付けられ得る。したがって、各タイプのサービスは、そのタイプのサービスについて、階層的に関連するロールの、別個の場合によっては異なる予め定義された「テンプレート」と関連付けられ得る。アイデンティティドメイン管理者７１０などの一部のロールは、クラウドワイドのロールモデル内に予め定義され得る（かつ、場合によっては不変の定義を有し得る）が、他のサービスインスタンス特有のロールは、適切な許可を有するものにより、特定のサービスインスタンスに対する顧客の許可を有するように作成され、手動で定義され得る。

【0161】

予め定義されたサービスタイプ特有のロール階層において関連付けられた許可は、クラウドワイドのモデル内に定義された階層的により高いロールにより継承され得る。例えば、特定のタイプのサービス（例えば、データベースサービス）についての各サービス管理者ロールは、その特定のタイプのサービス特有のロール階層において予め定義されたすべてのロール（および関連付けられた許可）を継承し得る。アイデンティティドメイン管理者ロールは、アイデンティティドメインにおけるすべてのサービス管理者ロールにより継承されるすべてのロール（および関連付けられた許可）を継承し得る。したがって、アイデンティティドメイン管理者７１０は、ロール継承により、サービス管理者７１２〜７１８のすべてが行なうことができるオペレーションのすべてを行なうことが可能となるが、アイデンティティ管理者７１２は、他のサービス管理者７１４〜７１８が行なうことができるオペレーションを必ずしも行なうことはできない。アイデンティティ管理者７１２は、どの特定のサービスインスタンスにも特有でない、アイデンティティドメイン内の一般的なアイデンティティベースのオペレーションを行なうことに限定され得る。一実施例における顧客７０２は、アイデンティティドメインの外部にあるため、どのロールも継承しない。

【0162】

一実施例では、顧客７０２がオンラインストアを用いて、顧客アイデンティティドメイン７０４内の特定のロールを有するようにアイデンティティドメイン管理者７１０またはサービス管理者７１２〜７１８のいずれかなどの誰かを指名すると、オンラインストアは、それに応答して、その指名された人の電子メールアドレスに電子メールメッセージを送ることができる。顧客７０２は、指名プロセスの一部として、オンラインストアに電子メールアドレスを提供することができる。指名された人の電子メールアドレスに送信される電子メールメッセージは、クラウドコンピューティング環境内のウェブサーバにより供給されるウェブベースフォームを指すハイパーリンクを含み得る。ウェブベースフォームは、入力可能なフィールドを含み得、これを介してメッセージ受信者は、ユーザ名、パスワード、および、顧客アイデンティティドメイン７０４内の指名された人についてのユーザアイデンティティを作成するのに役立つ他の情報を特定することができる。指名された人が、入力したウェブベースフォームをウェブサーバに提出すると、ウェブサーバは、指名された人のユーザイデンティを顧客アイデンティティドメイン７０４内に作成させることができ、さらに、特定されるロールをそのユーザアイデンティティに割り当てさせることができる。指名は、アイデンティティドメインの外部のエンティティがアイデンティティドメイン内のユーザアイデンティティにロールを割り当てるプロセスとして見なされ得るが、委任は、アイデンティティドメイン内のユーザアイデンティティが、そのユーザアイデンティティドメイン内の別のユーザアイデンティティに、（アイデンティティドメインにおける自身のロールにより）前者のユーザが割り当てる権限を有するロールを割り当てるプロセスとして見なされ得る。

【0163】

図１１は、発明の実施例に係る、上述のようなマルチテナントＩＤＭシステムにおけるロール委任をさらに示すブロック図である。システム１１００は、オンラインストア１１０２および顧客のアイデンティティドメイン１１０４を含み得る。顧客（ストアアカウント管理者）１１０６は、オンラインストア１１０２内のアカウントを有し得る。顧客１１０６は、図１１中の破線矢印により示されるように、アイデンティティドメイン１１０４内のアイデンティティを有するさまざまなユーザをさまざまなロールに指名することができる。例えば、顧客１１０６は、このようなユーザを、アイデンティティドメイン管理者１１０８、および／または異なるサービスインスタンスについてサービス管理者１１１２および１１１４に指名することができる。このような指名は、顧客１１０６がオンラインストア１１０２からアイデンティティドメイン１１０４を購入するときに起こり得る。次に、アイデンティティドメイン１１０４内のアイデンティティを有するこれらのユーザは、図１１中の実線矢印により示されるように、さまざまなロールをアイデンティティドメイン１１０４内のアイデンティティを有する他のユーザに委任することができる。例えば、アイデンティティドメイン管理者１１０８は、他のユーザに、アイデンティティドメインセキュリティ管理者１１１０、および／または異なるサービスインスタンスについてサービス管理者１１１２および１１１４などのロールを委任することができる。これらの他のユーザは、アイデンティティドメイン１１０４内のアイデンティティを有するさらに他のユーザにロールをさらに委任することができる。例えば、アイデンティティドメインセキュリティ管理者１１１０は、他のユーザに、アイデンティティドメインユーザ／ロール管理ロール１１１６を委任することができる。別の例については、１つのサービスインスタンスについてのサービス管理者１１１２は、他のユーザに、そのサービスインスタンスについてのサービスインスタンス特有のロール１１１８を委任することができる。さらに別の例については、別のサービスインスタンスについてのサービス管理者１１４は、他のユーザに、その別のサービスインスタンスについてのサービスインスタンス特有のロール１１２０を委任することができる。

【0164】

図１２は、発明の実施例に係る、上述のようなマルチテナントＩＤＭシステムにおける許可継承をさらに示すブロック図である。システム１２００は、オンラインストア１２０２および顧客のアイデンティティドメイン１２０４を含み得る。顧客（ストアアカウント管理者）１２０６は、オンラインストア１２０２内のアカウントを有し得る。一実施例では、顧客１２０６はアイデンティティドメイン１２０４内のアイデンティティではないので、顧客１２０６は許可を継承しない。アイデンティティドメイン１２０４内では、アイデンティティドメインセキュリティ管理者１２１０は、アイデンティティドメインユーザ／ロール管理ロール１２１６から許可を継承することができる。１つのサービスインスタンスについてのサービス管理者１２１２は、その同一のサービスについてのサービスインスタンス特有のロール１２１８から許可を継承することができる。別のサービスインスタンスについてのサービス管理者１２１４は、その別のサービスについてのサービスインスタンス特有のロール１２２０から許可を継承することができる。次に、アイデンティティドメイン管理者１２０８は、アイデンティティドメインセキュリティ管理者１２１０、ならびにサービス管理者１２１２および１２１４の各々から許可を継承することができる。したがって、一実施例では、アイデンティティドメイン管理者１２０８は、アイデンティティドメイン１２０４におけるすべてのサービスインスタンスを管理する許可を継承することができる。

【0165】

図５は、発明の実施例に係る、クラウド共有ＩＤＭ層５００のサブシステムの例を示すブロック図である。図５のクラウド共有ＩＤＭ層５００は、図３のクラウド共有ＩＤＭ層３０４に相当し得る。クラウド共有ＩＤＭ層５００は、テナントおよびサービスプロビジョニング自動化ＡＰＩ５０２と、ＩＤＭライフサイクルオペレーションツール５０４と、テナント・アウェアＩＤＭコンポーネント拡張５０６と、テナント分離データモデル５２０とを含み得る。テナント・アウェアＩＤＭコンポーネント拡張５０６は、マルチテナントログインユーザインターフェース（ＵＩ）および認証スキーム５０８と、クラウドＩＤＭコンソール５１０と、アイデンティティフェデレーションマルチテナント拡張５１２と、クラウドインフラストラクチャ証明書サービス５１４と、ユーザ／ロールＡＰＩ５１６と、アプリケーションプラグインモジュールマルチテナント拡張５１８とを含み得る。

【0166】

一実施例では、共有ＩＤＭシステムの各コンポーネントは、アイデンティティドメイン間の分離を実施するために、そのアーティファクトについてのテナント分離コンストラクトを含み得る。このような各テナント分離コンストラクトは、テナント分離データモデル５２０に従い得る。アクセス管理製品は、例えば、アイデンティティ管理サービスおよび対応するポリシーを必要とする可能性がある。これらのポリシーが異なり、カスタマイズ可能となり、顧客毎に区別され得るように、各顧客は、共有ＩＤＭシステムのポリシーストアのそれ自身の「スライス」を有し得る。したがって、発明の一実施例では、共有ＩＤＭシステムのポリシーストア内のポリシーがアイデンティティドメインにより分割され得る。ポリシーを格納し、管理するためのメカニズムは、テナント特有であり得る。テナント分離データモデル５２０は、アイデンティティドメイン間の分離を実施するために、テナント・アウェアＩＤＭコンポーネント拡張５０６内のサブシステムの各々によって従われ得る。テナント分離データモデル５２０に従うことにより、各共有ＩＤＭ製品は、アイデンティティドメイン・アウェア特徴を所有することができる。

【0167】

例えば、マルチテナントログインＵＩおよび認証スキーム５０８は、それを介してユーザがアクセスしようとしている特定のアイデンティティドメインを識別できるＵＩフィールドを提供することにより、テナント分離データモデル５２０に従うことができる。この特徴により、ユーザがクラウドコンピューティング環境内の特定のアイデンティティドメインにログインすることが可能となる。次に、マルチテナントログインＵＩおよび認証スキーム５０８は、特定のアイデンティティドメインを、それに対してユーザが認証されるものとして選ぶことができる。特に、認証スキームは、ログインプロセス中に供給されるユーザアイデンティティと関連付けられる実際のパスワードを参照するときに正確なパーティションに問合せるために、特定のアイデンティティドメインを用いることができる。承認されていない（unqualified）ユーザアイデンティティは、アイデンティティドメイン内でユニークである必要があり得るが、このようなユーザアイデンティティは、場合によっては別個のアイデンティティドメインにわたって重複され得る。発明の一実施例では、完全に承認されているユーザアイデンティティは、それらのユーザアイデンティティが所属するアイデンティティドメインを特定することができ、このような完全に承認されているユーザアイデンティティは、別個のアイデンティティドメインにわたって重複されない。したがって、発明の実施例は、認証プロセスがマルチテナント・アウェアとなるメカニズムを提供する。このようなメカニズムは、ユーザのアイデンティティドメインを決定し得、そのアイデンティティドメインに特有のデータに基づいてユーザを認証し得る。

【0168】

一実施例では、クラウドＩＤＭコンソール５１０は、テナント分離データモデル５２０に従う、テナント・アウェアコンポーネント拡張５０６のうちであり得る。クラウドＩＤＭコンソール５１０は、ユーザパスワードを変更し、例えば、他のユーザアイデンティティ管理機能を行なうために用いられ得る。クラウドＩＤＭコンソール５１０は、それを介して、コンソールオペレーションが行なわれるアイデンティティドメインを決定することができる制御を含み得る。したがって、アイデンティティドメイン管理者がクラウドＩＤＭコンソール５１０を用いてユーザアイデンティティを追加または削除するとき、クラウドＩＤＭコンソール５１０は、アイデンティティドメイン管理者が所属するアイデンティティドメインを決定し得、ユーザアイデンティティの追加または削除をそのアイデンティティドメインのみに制限し得る。

【0169】

テナントおよびサービスプロビジョニング自動化ＡＰＩ５０２は、購入されたサービスインスタンスを、それらのサービスインスタンスが購入されたアイデンティティドメインにプロビジョニングするために用いられ得る。ＩＤＭライフサイクルオペレーションツール５０４は、データ（例えば、パッチアプリケーションなど）をアイデンティティドメインにアップロードする、アイデンティティドメインからダウンロードする、さらにアイデンティティドメイン内に同期させるために用いられ得る。

【0170】

図６は、発明の実施例に係る、オラクルＩＤＭ／セキュリティ層６００のサブシステムの例を示すブロック図である。図６のオラクルＩＤＭ／セキュリティ層６００は、図３のオラクルＩＤＭ／セキュリティ層３０６に相当し得る。オラクルＩＤＭ／セキュリティ層６００は、オラクルプラットフォームセキュリティサービス（Oracle platform security services: ＯＰＳＳ）およびオラクルウェブサービスマネージャ（Oracle web services manager: ＯＷＳＭ）６０２と、オラクルインターネットディレクトリ（Oracle Internet directories: ＯＩＤ）６０４と、オラクルアイデンティティフェデレーション（Oracle identity federation: ＯＩＤ）モジュール６０６と、オラクルアイデンティティマネージャ（Oracle identity manager: ＯＩＭ）６０８とを含み得る。発明の一実施例では、共有ＩＤＭシステムにおける各アイデンティティドメインに関連付けられたアイデンティティは、ＯＩＤ６０４内に格納され得る。ＯＩＤ６０４は、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）ディレクトリを実現し得る。したがって、一実施例では、共有ＩＤＭシステムにおけるすべてのユーザのアイデンティティのすべてが、アイデンティティドメインにより分割されるＬＤＡＰディレクトリに格納され得る。

【0171】

各アイデンティティドメインについてのアクセス制御サブシステムは、保護されたサービスまたはリソースへのアクセスが、そのアイデンティティドメイン内に定義され、かつその保護されたサービスまたはリソースに関連付けられたポリシーが満たされる場合のみに付与されるという意味で、ポリシー駆動式（policy-driven）である。各アイデンティティドメインは、そのアイデンティティドメイン内に定義されたポリシーを実施するランタイムインスタンスを有し得る。一実施例では、すべてのアイデンティティドメインについてのすべてのポリシーは、共通のクラウドワイドのポリシーストアに格納され得るが、このポリシーストアは、アイデンティティドメインにより分割され得る。

【0172】

上述のように、発明の一実施例では、顧客は、アイデンティティドメインをクラウドベースの環境下で作成させることができ、さらに、オンラインストアから、そのアイデンティティドメイン内で利用可能となる１つ以上のサービスインスタンスを購入することができる。発明の一実施例では、マルチテナントクラウドベースのＩＤＭシステムについてのＡＰＩは、サービスインスタンスプロビジョニングオペレーションが正確な順に行なわれることを保証するように定義される。典型的には、アイデンティティドメインに対して行なわれる第１のオペレーションは、クラウドベースのＩＤＭシステムにおけるそのアイデンティティドメインの作成である。ＡＰＩ方法の一つは、アイデンティティドメインについての名称を受取り、クラウドベースのＩＤＭシステム内の任意のアイデンティティドメインが既にその名称を有しているかを決定し得る。その名称を有するアイデンティティドメインが現在存在しない場合、ＡＰＩ方法は、（一部、そのアイデンティティドメインを定義するメタデータを格納することにより）そのアイデンティティドメインを作成し得る。アイデンティティドメインがＡＰＩ方法の呼出しの以前に存在していたかにかかわらず、ＡＰＩ方法は、名付けられたアイデンティティドメインに関する情報を、ＡＰＩ方法を呼び出したエンティティに戻し得る。エンティティは、この情報を用いてＡＰＩのさらなる方法を呼出し、サービスインスタンス追加などの名付けられたアイデンティティドメインに対するオペレーションを行なうことができる。

【0173】

図１３は、発明の実施例に係る、アイデンティティドメイン内のサービスインスタンスをプロビジョニングするためのシステム１３００の例を示すブロック図である。例示のオペレーションは、顧客がアイデンティティドメインとそのアイデンティティドメインについてのサービスインスタンスとを同時に購入している状況を想定している。例えば、サービスインスタンスは、フュージョンＣＲＭアプリケーションのインスタンスである可能性がある。（Ａ）において、グローバルシングルインスタンス（ＧＳＩ）モジュール１３０２は、承認された顧客オーダーをＴＡＳモジュール１３０４に送信し得る。（Ｂ）において、ＴＡＳモジュール１３０４は、ＳＤＩモジュール１３０６にサービスインスタンスを作成するように命令し得る。（Ｃ）において、ＳＤＩモジュール１３０６は、サービスインスタンスが作成されるべきであるアイデンティティドメイン自体がまだ作成されていないと決定し得るため、ＳＤＩモジュール１３０６は、ＩＤＭプロビジョニングＡＰＩ１３０８に、アイデンティティドメイン作成要求を送信し得る。この要求に応じて、ＩＤＭドメインプロビジョニングＡＰＩ１３０８は、顧客アイデンティティドメイン１３１０を作成させ得る。（Ｄ）において、ＩＤＭドメインプロビジョニングＡＰＩ１３０８は、ＳＤＩモジュール１３０６に、アイデンティティドメイン作成応答を送信し得る。このアイデンティティドメイン作成応答は、アイデンティティドメインが正常に作成されたことを示し、かつ、ＳＤＩモジュール１３０６が、ＩＤＭドメインプロビジョニングＡＰＩ１３０８との後のトランザクションにおいて新たに作成されたアイデンティティドメイン（顧客アイデンティティドメイン１３１０）を指すために用いることのできるリンケージ情報を含む。（Ｅ）においては、ＳＤＩモジュール１３０６は、サービスインスタンス作成要求をＩＤＭドメインプロビジョニングＡＰＩ１３０８に送信し得る。この要求において、ＳＤＩモジュール１３０６は、新たに作成されたアイデンティティドメイン（顧客アイデンティティドメイン１３１０）を、サービスインスタンスが作成されるべきであるアイデンティティドメインとして指し得る。この要求に応じて、ＩＤＭドメインプロビジョニングＡＰＩ１３０８は、作成されたサービスインスタンス（例えば、フュージョンＣＲＭアプリケーション）に特有の、ＩＤＭシステム１３１２におけるサービスインスタンスフットプリントを作成し得る。（Ｆ）において、ＩＤＭドメインプロビジョニングＡＰＩ１３０８は、ＳＤＩモジュール１３０６に、サービスインスタンス作成応答を送信し得る。（Ｇ）において、ＳＤＩモジュール１３０６は、顧客アイデンティティドメイン１３１０内に、作成されたサービスインスタンスのタイプ（例えば、フュージョンＣＲＭアプリケーション）についてのサービスインスタンスシードＩＤＭシステムアーティファクト１３１４を「リハイドレート（re-hydrate）」し得る。このようなリハイドレーションは、そのサービスインスタンスのタイプの格納された総括的な「イメージ」のコピーを作成し、サービスインスタンスとアイデンティティドメインとを接続し、かつ、そのアイデンティティドメインについてのサービスインスタンスをカスタマイズするするリンケージ情報を生成および格納することを含み得る。（Ｈ）において、ＳＤＩモジュール１３０６は、ＴＡＳモジュール１３０４に、サービスインスタンスが顧客アイデンティティドメイン１３１０内に正常にインスタンス化されたことを示すサービスインスタンス作成確認応答を送信し得る。

【0174】

以下の表１は、発明の実施例に係る、図１３を参照して上に説明したさまざまなクラウドベースのイベントについて、クラウドベースのマルチテナントＩＤＭシステムの異なるコンポーネントおよびクラウドベースのマルチテナントＩＤＭシステム内の異なるエンティティが、それらのイベントの一部として、互いに通信し得る種類の情報を示す。

【0175】

【表1】

【0176】

アイデンティティドメインへのサービスインスタンスの追加は、クラウドベースの環境下での１つ以上の仮想マシンのインスタンス化を含み得る。そのタイプのサービスについての仮想マシンは、アイデンティティドメインにサービスインスタンスを追加することの一部としてインスタンス化され得る。一実施例では、このような仮想マシン、または「サービスインスタンスランタイムコンポーネント」のインスタンス化は、このような仮想マシンが適切なアイデンティティドメインと関連付けられる、または「接続される」ことを保証するコンフィグレーションオペレーションにより達成され得る。さらに、このような仮想マシンのインスタンス化は、このような仮想マシンが適切なポリシーベースの境界と関連付けられる、または「接続される」ことを保証するコンフィグレーションオペレーションにより達成され得る。発明の一実施例では、特定されるタイプのサービスインスタンスを作成するためのＡＰＩ方法は、クラウドベースのＩＤＭシステム内で実現される。このサービスインスタンス作成ＡＰＩ方法の呼出しは、クラウドベースのＤＭシステムに、サービスインスタンス仮想マシンと適切なアイデンティティドメインとの間の関連付けを確立させるために用いられ得るハンドルを作成させ得る。このようなハンドルは、適切なアイデンティティドメインの名称、ユーザ名、パスワード等の調整情報を含み得る。サービスインスタンス仮想マシンは、クラウドベースのＩＤＭシステムに接続するためにこのようなユーザ名およびパスワードを用いることができ、接続プロセス中、そのコンテキストにおいてサービスインスタンス仮想マシンが実行されるであろうアイデンティティドメインの名称を特定し得る。サービスインスタンス作成ＡＰＩ方法は、そのハンドルにより特定されるユーザ名およびパスワードが、どの他のサービスインスタンス仮想マシンについて作成されたハンドルにおいても重複していないことを保証し得る。このため、他のアイデンティティドメインのサービスインスタンスについての仮想マシンは、それ自身のアイデンティティドメイン以外のアイデンティティドメインに対して接続することが不適当に許可されない。したがって、サービスインスタンス作成ＡＰＩ方法は、その方法を呼び出したエンティティに、サービスインスタンスをインスタンス化するために必要なデータをすべて含む情報のベクターを戻すことができる。

【0177】

各サービスインスタンス仮想マシンは、そのコンテキストにおいてサービスインスタンス仮想マシンが実行されるアイデンティティドメイン内に定義されたアイデンティティにアクセスすることができる。このアクセスは、例えば、サービスインスタンス仮想マシンがユーザを認証し、アイデンティティドメインに関係するロールを参照できるように付与され得る。図８は、発明の実施例に係る、アプリケーションインスタンスランタイムコンポーネントがアイデンティティドメイン内に定義されたアイデンティティにアクセスできるマルチテナントＩＤＭシステム８００を示すブロック図である。図示される例において、アプリケーションインスタンスランタイムコンポーネントは、フュージョン（ＣＲＭ）アプリケーションのインスタンス用である。システム８００は、フュージョンアプリケーションサービス８０２、フュージョンミドルウェア８０４、ポリシーストア８０６、アイデンティティストア８０８、およびデータベース８１０を含み得る。フュージョンアプリケーションサービス８０２およびフュージョンミドルウェア８０４は、ともにフュージョンアプリケーションランタイムコンポーネントを構築する。ポリシーストア８０６およびアイデンティティストア８０８は、例えば、オラクルインターネットディレクトリ（ＯＩＤ）または他のＬＤＡＰディレクトリとして実現され得る。さまざまな別個のアイデンティティドメインからのポリシーを格納し得るポリシーストア８０６は、ポリシーストアルートノード８２６を含み得、ポリシーストアルートノード８２６から論理セキュリティストアノード８２４が階層的に降下し得、論理セキュリティストアノード８２４からポリシー８１６、８１８、８２０および８２２が階層的に降下し得る。ポリシー８１６、８１８および８２０は、１つのアイデンティティドメインであるドメインＡに関係し得、ポリシー８２２は、別のアイデンティティドメインであるドメインＢに関係し得る。ポリシー８１６および８１８は、ＪＡＶＡサービスの別個のインスタンスに関係し得、ポリシー８２０および８２２は、フュージョンアプリケーションサービスの別個のインスタンスに関係し得る。さまざまな別個のアイデンティティドメインからのアイデンティティを格納し得るアイデンティティストア８０８は、ＬＤＡＰルートノード８２８を含み得、ＬＤＡＰルートノード８２８からさまざまなアイデンティティドメイン８３０についてのノードが階層的に降下し得、アイデンティティドメイン８３０からアイデンティティドメインＡ ８３２に関係するアイデンティティおよびアイデンティティドメインＢ ８３４に関係するアイデンティティが階層的に降下し得る。データベース８１０は、フュージョンオンライントランザクション処理（on-line transaction processing: ＯＬＴＰ）データ８１２および（場合によっては、フュージョンミドルウェアスキーマおよび他のデータベーススキーマを含み得る）スキーマ８１４などのフュージョンアプリケーションサービス８０２およびフュージョンミドルウェア８０４により使用されるデータを格納し得る。

【0178】

フュージョンアプリケーションは、マルチテナントＩＤＭシステム８００内に存在する、シングルテナントアプリケーションの一例であり得る。したがって、フュージョンアプリケーションサービス８０２およびフュージョンミドルウェア８０４の特定のインスタンスは、特定のアイデンティティドメインに特有であり得る。この例において、これらはアイデンティティドメインＡに特有である。アイデンティティストア８０８は、その葉ノードに向かって、マルチテナントＩＤＭシステム８００における別個のアイデンティティドメインに関係するさまざまな別個のサブツリーを含むＬＤＡＰディレクトリツリーとして構築され得る。フュージョンアプリケーションランタイムコンポーネントについてのアイデンティティストアハンドルは、アイデンティティドメインＡ ８３２に関係するアイデンティティを含むＬＤＡＰサブツリーのルートノードであるＬＤＡＰアイデンティティ階層のノードのみを指す。したがって、フュージョンアプリケーションランタイムコンポーネントについてのアイデンティティストアハンドルは、アイデンティティドメインＡ専用のアイデンティティストア８０８の「スライス」のみを指す。このポインタは、フュージョンアプリケーションランタイムコンポーネントを起点とし、ＬＤＡＰサブツリー８３２で終了する図８の矢印として示される。このようなポインタは、フュージョンアプリケーションサービスがアイデンティティドメインＡに追加されるときにＡＰＩ方法を呼び出した結果として確立され得る。ＡＰＩ方法により戻されたハンドルは、マルチテナントＩＤＭシステム８００内で認識され、かつアイデンティティドメインＡと特定的に関連付けられた特定のユーザ名およびパスワードを特定するクレデンシャルを含み得る。したがって、このクレデンシャルは、アイデンティティドメインＡに関係するアイデンティティストア８０８の適切な「スライス」、またはパーティションに結び付けられ得る。フュージョンアプリケーションランタイムコンポーネントは、この特定のユーザ名およびパスワードを用いて、アイデンティティストア８０８の適切なパーティションにアクセスし得る。ＯＩＤ（アイデンティティストア８０８を実現するために用いられ得る）の内部のアクセス制御は、フュージョンアプリケーションランタイムコンポーネントの視認性（visibility）をアイデンティティストア８０８の適切なパーティションのみに制限（confine）し得るため、フュージョンアプリケーションランタイムコンポーネントは、アイデンティティドメインＡ以外のアイデンティティドメインに所属するアイデンティティにアクセスすることができない。

【0179】

マルチテナントＩＤＭシステム８００における各別個のサービスインスタンスは、クラウドワイドのポリシーストア８０８内に、そのサービスインスタンスに関係するそれ自身の別個のセットのポリシーを格納し得る。ポリシーストア８０８は、各アイデンティティドメインについてのサブツリー、および各アイデンティティドメインのサブツリー内のサービスインスタンスについてのポリシーノードを含むＬＤＡＰツリーとして構築され得る。フュージョンアプリケーションランタイムコンポーネントについてのポリシーストアハンドルは、アイデンティティドメインＡに所属するフュージョンアプリケーションランタイムインスタンスに関係するポリシーを含むＬＤＡＰサブツリーのルートノードであるＬＤＡＰポリシー階層のノードのみを指す。このポインタは、フュージョンアプリケーションランタイムコンポーネントを起点とし、ＬＤＡＰポリシーエントリ８２０で終了する矢印として図８に示される。このようなポインタは、フュージョンアプリケーションサービスがアイデンティティドメインＡに追加されるときにＡＰＩ方法を呼び出した結果として確立され得る。したがって、フュージョンアプリケーションランタイムコンポーネントは、アイデンティティドメインＡに所属するフュージョンアプリケーションサービスに関係するポリシーに特定的に関係するポリシーストア８０８の特定のパーティションに結び付けられるまたは「接続され」る。その結果、フュージョンアプリケーションランタイムコンポーネントがポリシーストア８０８に問合せるとき、この問合せは、まさしくフュージョンアプリケーションランタイムコンポーネントが結び付けられたポリシーストア８０８の特定のパーティションに対して実行され得る。

【0180】

より一般的には、発明の一実施例では、サービスインスタンスランタイムコンポーネント毎に境界が存在する。特定のサービスインスタンスランタイムコンポーネントについて、適切なアイデンティティドメインおよび適切なサービスインスタンスそれぞれに関係する、アイデンティティストア８０６およびポリシーストア８０８それぞれのパーティションのみを指すクレデンシャルが作成され得る。これらのクレデンシャルは、一旦作成されると、プロビジョニングシステムに引き渡され得、これにより、プロビジョニングシステムは、各々がクラウドコンピューティング環境下でさまざまなアイデンティティドメインにおいてさまざまなサービスインスタンスについてのデータを格納し得るアイデンティティストア８０６およびポリシーストア８０８の適切なパーティションにサービスインスタンスランタイムコンポーネントを結び付け得る。アイデンティティストア８０６は、ポリシーストア８０８とは別個に実現され得る。なぜなら、アイデンティティはサービス特有でないが、ポリシーはサービス特有であり得るためである。したがって、各タイプのデータに関連するセキュリティ境界は、範囲が異なり得る。同一のアイデンティティドメイン内の複数のサービスインスタンスは、すべてアイデンティティストア８０６の同一のＬＤＡＰサブツリーに結び付けられ得るが、各サービスインスタンスは、ポリシーストア８０８の異なるＬＤＡＰポリシーエントリに結び付けられ得る。

【0181】

一実施例では、アイデンティティストア８０６などの１つ以上の情報ストアが、ＯＩＤなどのＬＤＡＰディレクトリに格納され得る。このようなＬＤＡＰディレクトリは、典型的には階層的に編成される。一実施例では、単一のＬＤＡＰディレクトリは、クラウドベースのマルチテナントＩＤＭシステム内の複数の別個のアイデンティティドメインに関係する情報を格納し得る。図１６は、発明の実施例に係る、クラウドベースのＩＤＭシステムについてのマルチテナントＬＤＡＰディレクトリ１６００の構造の例を示す階層図である。ＬＤＡＰルート１６０２は、システム群ノード１６０４、システムアイデンティティノード１６０６、アイデンティティドメインノード１６０８、およびサービステンプレートノード１６１０などの複数のノードの親となり得る。システム群１６０４は、アイデンティティドメイン特有ではなく、クラウドシステムワイドなアイデンティティの群を表わすノードの親となり得る。システム群１６０４は、ａｐｐ ＩＤ群の親となり得、ａｐｐ ＩＤ群は、さまざまなアプリケーションアイデンティティを識別された群にともにグループ化し得る。システムアイデンティティ１６０６は、アイデンティティドメイン特有ではなく、クラウドシステムワイドな個々のアイデンティティを表わすノードの親となり得る。システムアイデンティティは、ａｐｐ ＩＤの親となり得、ａｐｐ ＩＤは、そのアイデンティティがアイデンティティドメイン特有ではなく、クラウドシステムワイドな個々のアプリケーションを識別し得る。アイデンティティドメイン１６０８は、顧客Ａアイデンティティドメイン１６１６Ａ、顧客Ｂアイデンティティドメイン１６１６Ｂ、およびＣＳＲ（またはオペレーション）アイデンティティドメイン１６１８などのさまざまな別個のアイデンティティドメインについてのノードの親となり得る。上述のように、これらのアイデンティティドメインノードの各々は、それぞれのアイデンティティドメイン内のロールおよびアイデンティティに関係する数多くの他のノードの親となり得る。さらに、図１６は、顧客（例えば、ＡおよびＢ）当たりの単一のアイデンティティドメインを示すが、代替的な実施例では、各顧客は、複数の別個のアイデンティティドメインを有し得る。サービステンプレート１６１０は、異なるサービスタイプについてのロール階層のルートである数多くのノードの親となり得る。上述のように、異なるサービスタイプは、予め定義されたロール階層にマッピングされ得、予め定義されたロール階層は、そのタイプのサービスがアイデンティティドメインに追加されるとアイデンティティドメインに自動的に追加され、ユーザがそのサービスについての当該ロールを手動で作成する手間が省かれ得る。

【0182】

図１７は、発明の実施例に係る、異なるサービスタイプについてのロールテンプレートに関係するＬＤＡＰディレクトリサブツリーの構造の例を示す階層図である。サービスコンテキストテンプレートノード１７０１は、図１６のサービステンプレートノード１６１０に相当し得る。サービスコンテキストテンプレートノード１７０１は、異なるサービスタイプについての数多くのノードの親となり得る。このようなノードは、例えば、ＪＡＶＡサービスノード１７０２、データベースサービスノード１７０４、およびオラクルソーシャルネットワーク（Oracle social network: ＯＳＮ）サービスノード１７０６を含み得る。ノード１７０２〜１７０６の各々は、そのサービスタイプについてのロールノードを含むサブツリーのルートであるノードの親となり得る。例えば、ロールテンプレートノード１７０８は、ＪＡＶＡサービスタイプを有するサービスについて予め定義されたロールを記述するノードのサブツリーのルートとなり得る。別の例として、ロールテンプレートノード１７１０は、データベースサービスタイプを有するサービスについて予め定義されたロールを記述するノードのサブツリーのルートとなり得る。さらに別の例として、ロールテンプレートノード１７１２は、ＯＳＮサービスタイプを有するサービスについて予め定義されたロールを記述するノードのサブツリーのルートとなり得る。これらのサブツリーは、アイデンティティドメイン管理者およびサービス管理者などのそれらのサービスのユーザおよび管理者がこのようなロールを手動で作成する必要はないものの、それらのアイデンティティドメイン内のユーザにこのようなロールを割り当てることができるように、そのサービスの設計者および作成者により定義され得る。

【0183】

発明の一実施例によれば、マルチテナンシＩＤＭシステムは、有利には、各々がそれら自身の別個のアイデンティティドメインを有する複数の別個の顧客が、クラウドにおいて共有されるハードウェアおよびソフトウェアを使用することを可能にする。その結果、各顧客がそれ自身の専用ハードウェアまたはソフトウェアリソースを有する必要がなく、いくつかの場合には、あるときに一部の顧客により使用されていないリソースが、他の顧客により使用可能となることにより、それらのリソースが無駄にされることを防止する。例えば、複数の顧客は、それぞれのアイデンティティドメイン内に配置されたＪＡＶＡサービスインスタンスを有し得る。このような各アイデンティティドメインは、ハードウェアの仮想的な「スライス」として見なされ得るＪＡＶＡ仮想マシンを有し得る。別の例としては、一実施例では、複数の顧客が、それぞれのアイデンティティドメイン内に配置されたデータベースサービスインスタンスを有し得る。このような各データベースサービスインスタンスは、多くの別個のアイデンティティドメイン間で共有される単一の物理的なマルチテナントデータベースシステムの別個の抽象化またはビューであり得るが、このような各データベースサービスインスタンスは、各他のデータベースサービスインスタンスが有するものとは別個の、場合によっては異なるスキーマを有し得る。したがって、マルチテナントデータベースシステムは、顧客により特定されたデータベーススキーマとそれらのデータベーススキーマが関係するアイデンティティドメインとの間のマッピングを格納し得る。マルチテナントデータベースシステムは、特定のアイデンティティドメインについてのデータベースサービスインスタンスに、当該特定のアイデンティティドメインにマッピングされたスキーマを使用させ得る。一実施例では、ジョブモニタリングサービス（例えばハドソン）は、クラウドにおいてＪＡＶＡエンタプライズエディションプラットフォーム（例えばオラクルウェブロジック）と組み合わされて、各々の別個のアイデンティティドメインがＪＡＶＡエンタプライズエディションプラットフォームのそれ自体の別個の仮想的な「スライス」を有することを可能にし得る。このようなジョブモニタリングサービスは、例えばオペレーティングシステムの時間ベースのジョブスケジューラによって実行されるソフトウェアプロジェクトまたはジョブの構築などの繰返されるジョブの実行をモニタリングし得る。このような繰返されるジョブは、ソフトウェアプロジェクトの連続的な構築および／またはテストを含んでいてもよい。さらにまたは代替的に、このような繰返されるジョブは、ジョブモニタリングサービスが実行されるマシンから離れたマシン上で実行されるオペレーティングシステム起動ジョブの実行のモニタリングを含んでいてもよい。

【0184】

図１４は、発明の実施例に係る、クラウドのハードウェアおよびソフトウェアリソースが、アイデンティティドメイン間で共有できるマルチテナントクラウドベースのシステム１４００の例を示すブロック図である。システム１４００は、オラクルＪＡＶＡクラウドサービス管理インターフェイス１４０２、アプリケーションエンドユーザ１４０４、オラクルクラウドサービスデプロイメントインフラストラクチャ１４０６、クラウドアプリケーションファンデーション１４０８、およびプロビジョニングされたシステム１４１０を含み得る。オラクルＪＡＶＡクラウドサービス管理インターフェイス１４０２は、ウェブベースのインターフェイスおよび／またはコマンドラインインターフェイスなどのさまざまなユーザインターフェイスを含み得る。これらのインターフェイスは、オラクルクラウドサービスデプロイメントインフラストラクチャ１４０６と対話するために用いられ得る。オラクルクラウドサービスデプロイメントインフラストラクチャ１４０６は、クラウドアプリケーションファンデーション１４０８と遣り取りし得る。一実施例では、クラウドアプリケーションファンデーション１４０８は、フュージョンミドルウェアコンポーネントを用いて構築され得る。一実施例では、クラウドアプリケーションファンデーション１４０８は、オラクルバーチャル・アセンブリ・ビルダ（ＯＶＡＢ）プール１４１０、データベースサーバ１４１２、ウェブティア（web tier）１４１４、ＩＤＭインフラストラクチャ１４１６、およびエンタープライズマネージャクラウド制御１４２２を含み得る。ＯＶＡＢプール１４１０は、ＪＡＶＡクラウドサービスアセンブリ１４１２Ａ−ＮおよびＣＲＭサービスアセンブリ１４１４Ａ−Ｎを含み得る。これらのアセンブリは、アイデンティティドメイン１４２４Ａ−Ｎの各々の各ＪＡＶＡクラウドサービスインスタンス１４２８についてのサービスプロビジョニングの際にインスタンス化され得る。このような各アセンブリは、そのアセンブリをエンタープライズマネージャクラウド制御１４２２およびウェブティア１４１４と関連付けることにより、その関連付けられたＪＡＶＡクラウドサービスインスタンス１４２８のためにパーソナライズされ得る。各アセンブリにアクセスするために用いられるエンドポイント情報が、電子メールによりアプリケーションエンドユーザ（例えば、アプリケーションエンドユーザ１４０４）に送信され得る。ＩＤＭインフラストラクチャ１４１６は、ディレクトリ１４１８およびアクセス管理モジュール１４２０を含み得る。プロビジョニングされたシステム１４１０は、アイデンティティドメイン１４２４Ａ−Ｎおよびオラクル仮想マシン１４２６を含み得る。アイデンティティドメイン１４２４Ａ−Ｎの各々は、それ自身のＩＤＭ／ＳＳＯモジュール１４２６、ＪＡＶＡクラウドサービス１４２８、ＣＲＭサービス１４３０、およびデータベースサーバ１４３２を含み得る。オラクルクラウドサービスデプロイメントインフラストラクチャ１４０６およびＩＤＭインフラストラクチャ１４１６は、プロビジョニングされたシステム１４１０と遣り取りし得る。

【0185】

図１５は、発明の実施例に係る、分離された顧客間でクラウドハードウェアの仮想的な「スライス」を共有するために、クラウドベースのシステムにおいて用いることができるＪＡＶＡクラウドサービスアーキテクチャ１５００の例を示すブロック図である。アーキテクチャ１５００は、ＪＡＶＡクラウドサービスインスタンス１５０２、Ｅｘａｌｏｇｉｃストレージ１５０４、およびデータベースクラウドサービスインスタンス１５０６を含み得る。ＪＡＶＡクラウドサービスインスタンス１５０２は、Ｅｘａｌｏｇｉｃ演算ノード１５０８Ａおよび１５０８Ｂなどの複数のＥｘａｌｏｇｉｃ演算ノードを含み得る。各Ｅｘａｌｏｇｉｃ演算ノードは、ＯＶＭインスタンス１５１０Ａおよび１５１０Ｂなどのオラクル仮想マシン（ＯＶＭ）インスタンスを含み得る。各ＯＶＭインスタンスは、マネージドサーバ１５１２Ａおよび１５１２Ｂなどのマネージドサーバを含み得る。各マネージドサーバは、複数の別個のアプリケーションを実行し得る。マネージドサーバ１５１２は、ともに高可用性を提供する顧客専用クラスタ１５１４を構成する。Ｅｘａｌｏｇｉｃ演算ノード１５０８は、Ｅｘａｌｏｇｉｃストレージ１５０４と遣り取りし得る。Ｅｘａｌｏｇｉｃストレージは、バイナリボリューム１５１８、コンフィグレーションボリューム１５２０、およびアプリケーションボリューム１５２２を含み得る。データベースサービスインスタンス１５０６は、Ｅｘａｄａｔａ（オラクルデータベーススキーマ−−リアルアプリケーションクラスタ（ＲＡＣ）ノード）１５１６を含み得る。一実施例では、ウェブロジックノードマネージャは、スレッドデッドロックおよびＪＡＶＡ仮想マシン（JAVA virtual machine: ＪＶＭ）クラッシュによるサーバ再起動のために構成され得る。ウェブロジッククラスタ化は、標準およびエンタープライズの提供に使用され得る。ＯＶＭインスタンス１５１０Ａ−ＢなどのサービスＯＶＭインスタンスは、Ｅｘａｌｏｇｉｃ演算ノード１５０８Ａ−Ｂなどの別個のｅｘａｌｏｇｉｃ演算ノード上で起動され得る。ＯＶＭが一つのＥｘａｌｏｇｉｃ演算ノード上で障害を起こすと、別のＥｘａｌｏｇｉｃ演算ノード上のＯＶＭが、前者のＥｘａｌｏｇｉｃ演算ノード上の障害を起こしたＯＶＭを再度起動し得る。データベースクラウドサービスインスタンス１５０６は、オラクルＲＡＣワンノードコンフィグレーションの中にあり得る。

【0186】

図１８は、発明の実施例に係る、同一のデータベースインスタンス内で複数のスキーマを用いることができるクラウドベースのシステムにおいて用いることができる、データベースクラウドサービスマルチテナンシアーキテクチャ１８００の例を示すブロック図である。用語の説明として、データベースインスタンスとは、問合せ実行およびリレーショナルデータ操作などのオペレーションを行なうことができるデータベースサーバとして集合的に機能するソフトウェアプロセスを実行する集合である。従来、単一の組織のためのエンタープライズ環境下では、データベースインスタンスは、そのデータベースインスタンスにより維持されるデータのすべてが編成されるリレーショナルテーブルなどのリレーショナル構造のフォーマットを特定する単一のデータベーススキーマを有していた。しかしながら、発明の一実施例によれば、クラウドコンピューティング環境下でホストされる単一のデータベースインスタンスは、複数の、別個の、場合によっては異なるスキーマを、各別個のアイデンティティドメイン（または「テナンシ」）当たり１つずつ維持し得る。有利には、この多くのスキーマ対１つのデータベースインスタンスのアプローチにより、複数の典型的には無関係の顧客（すなわち、テナント）が同一のセットの実行されるデータベースソフトウェアプロセス（単一のデータベースインスタンス）を利用できるようになるため、それらのデータベースソフトウェアプロセスの別個のインスタンスは、各顧客のアイデンティティドメイン毎にインスタンス化される必要がない。

【0187】

アーキテクチャ１８００は、Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂなどの複数のＥｘａｄａｔａ演算ノードを含み得る。Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂは、ハードウェア演算マシンであり得る。このような各マシンは、１つ以上のハードウェア処理ユニット（これらは、ソフトウェアにより特定される機械言語命令に基づいて、プロセッサレベルのフェッチ―デコード―実行オペレーションを行なう）を含み得る。このような各マシンは、クラウドベースのサービスのプロバイダにより所有され、作動される別個のサーバコンピューティング装置になり得る。したがって、一実施例では、Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂ上で実行されるデータベースソフトウェアにより提供されるデータベース機能をサブスクライブし、使用する顧客は、Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂを所有せずに、その上で実行されるソフトウェアプロセスを利用するに過ぎない。Ｅｘａｄａｔａ演算ノード１８０２Ａは、１つ以上のパケット化されたネットワークにより、Ｅｘａｄａｔａ演算ノード１８０２Ｂに通信により結合され得る。一実施例では、Ｅｘａｄａｔａ演算ノード１８０２Ｂは、冗長性目的で、Ｅｘａｄａｔａ演算ノード１８０２Ａ上のレプリカとして動作する。Ｅｘａｄａｔａ演算ノード１８０２Ａが障害を起こした場合、顧客は、Ｅｘａｄａｔａ演算ノード１８０２Ａが回復され得るまで、Ｅｘａｄａｔａ演算ノード１８０２Ｂに対するオペレーションを自動的に再開することができる。

【0188】

Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂは、データベースインスタンス１８０４Ａ−Ｂなどの別個のデータベースインスタンスをそれぞれ実行し得る。データベースインスタンス１８０４Ａ−Ｂの各々は、同一のデータベースソフトウェアコードセットから実行されるプロセスの別個の集合であり得る。データベースインスタンス１８０４Ａ−Ｂの各々は、複数の別個の、分離した、典型的には異なるデータベーススキーマを維持し得る。例えば、データベースインスタンス１８０４Ａは、データベーススキーマ１８０６ＡＡ−ＡＮを維持し得、データベースインスタンス１８０４Ｂは、データベーススキーマ１８０６ＢＡ−ＢＮを維持し得る。このような、発明の一実施例に係る、データベースインスタンス毎の複数のデータベーススキーマの維持は、従来の、データベースインスタンス毎に１つのスキーマのアプローチとは対照的である。データベーススキーマ１８０６ＡＡ−ＡＮの各々は、別個のアイデンティティドメインにマッピングされ得る。データベースインスタンス１８０４Ａ−Ｂの各々は、そのデータベーススキーマと、それらのデータベーススキーマが所属するアイデンティティドメインとの間のマッピングを特定するメタデータを維持し得る。本明細書中で説明される共有のＩＤＭアクセス制御により提供される分離メカニズムは、各アイデンティティドメインのスキーマが、そのアイデンティティドメインに関連付けられたユーザおよびサービスによってのみアクセスされ、使用可能となることを保証する。データベースインスタンス１８０４Ａ−Ｂは、アイデンティティドメイン間で共有され得るが、データベーススキーマ１８０６ＡＡ−ＡＮ（およびそれらのレプリカ１８０６ＢＡ−ＢＮ）は、個々のアイデンティティドメイン専門であり、他のすべてのアイデンティティドメインから分離され得るため、データベーススキーマ１８０６ＡＡ−ＡＮ（およびそれらのレプリカ１８０６ＢＡ−ＢＮ）は、代替的に「データベースサービスインスタンス」と呼ばれ得る。したがって、発明の一実施例によれば、本明細書中の「データベースサービスインスタンス」との記載は、データベースインスタンス単独ではなく、スキーマ−データベースインスタンス対を指す。

【0189】

各データベーススキーマは、複数の別個のリレーショナルテーブルを特定し得る。例えば、データベースインスタンス１８０４Ａ内では、データベーススキーマ１８０６ＡＡは、リレーショナルテーブル１８０８ＡＡＡ−１８０８ＡＡＮを特定し得、データベーススキーマ１８０６ＡＮは、リレーショナルテーブル１８０８ＡＮＡ−１８０８ＡＮＮを特定し得る。別の例として、データベースインスタンス１８０４Ｂ内では、データベーススキーマ１８０６ＢＡは、リレーショナルテーブル１８０８ＢＡＡ−１８０８ＢＡＮを特定し得、データベーススキーマ１８０６ＢＮは、リレーショナルテーブル１８０８ＢＮＡ−１８０８ＢＮＮを特定し得る。Ｅｘａｄａｔａ演算ノード１８０２Ｂは、Ｅｘａｄａｔａ演算ノード１８０２Ａのレプリカであり得るため、リレーショナルテーブル１８０８ＢＡＡ−１８０８ＢＮＮとともに、データベーススキーマ１８０６ＢＡ−ＢＮは、リレーショナルテーブル１８０８ＡＡＡ−１８０８ＡＮＮとともに、データベーススキーマ１８０６ＡＡ−ＡＮのレプリカであり得る。Ｅｘａｄａｔａ演算ノード１８０２Ａ上のデータベーススキーマまたはリレーショナルテーブルになされた変更は、Ｅｘａｄａｔａ演算ノード１８０２Ｂ上に自動的に伝えられ、複写され得る。各データベーススキーマは、別個のセットの格納されたプロシージャ、トリガなども特定し得る。

【0190】

アーキテクチャ１８００は、クラウドストレージ１８１０も含み得る。クラウドストレージ１８１０は、ハードディスクドライブなど、複数の、場合によっては別個であるが、相互に接続されたハードウェアストレージ装置により構成され得る。これらのストレージ装置は、必ずしもそうではないが、場合によってはＥｘａｄａｔａ演算ノード１８０２Ａ−Ｂと別個かつ異なり得る。Ｅｘａｄａｔａ演算ノード１８０２Ａ−Ｂによりアクセスされ、管理されるデータは、さまざまなストレージ装置間で分配され得るため、個々の演算ノードによりアクセスされ、管理されるデータの一部が複数の別個のストレージ装置間で分散され得る、および／または、１つの演算ノードによりアクセスされ、管理されるデータの少なくとも一部が、別の演算ノードによりアクセスされ、管理されるデータとして同一のストレージ装置の少なくとも一部に格納され得る。実際、一実施例では、Ｅｘａｄａｔａ演算ノード１８０２Ｂは、Ｅｘａｄａｔａ演算ノード１８０２Ａのレプリカであるため、これらの演算ノードの各々は、データベースデータの同一のコピーを共有し得る。このようなシナリオにおいては、データベースソフトウェアプロセスの実行などのコンピューティングリソース（computational resources）が複製され得るが、それらのプロセスによりアクセスされ、維持されるデータレコードは、レプリカ間で共有され得る。クラウドストレージ１８１０を構築するハードウェアストレージ装置は、クラウドサービスプロバイダにより所有され、作動され得、クラウドサービスプロバイダは、上述のように、典型的には、そのデータレコードがそれらのハードウェアストレージ装置に格納された顧客と別個かつ異なる。

【0191】

クラウドストレージ１８１０は、表領域１８１２Ａ−Ｎを格納し得る。一実施例では、各データベーススキーマは、そのデータベーススキーマに一致するデータが格納された別個の専用の表領域を有する。例えば、表領域１８１２Ａは、データベーススキーマ１８０６ＡＡ（およびそのレプリカとしてのデータベーススキーマ１８０６ＢＡ）に一致するデータの格納専用であり得、表領域１８１２Ｂは、データベーススキーマ１８０６ＡＮ（およびそのレプリカとしてのデータベーススキーマ１８０６ＢＮ）に一致するデータの格納専用であり得る。一実施例では、これらの表領域は、データベースインスタンス１８０４Ａ−Ｂを介してのみアクセス可能であるため、本明細書中で説明される共有のＩＤＭアクセス制御によりデータベースインスタンス１８０４Ａ−Ｂに課される分離メカニズムは、表領域１８１２Ａ−Ｎの各々が表領域１８１２Ａ−Ｎの各々から分離されることを保証するのに十分である。その結果、一実施例では、さまざまな表領域１８１２Ａ−Ｎが、それら自体は必ずしも厳密には個々のアイデンティティドメイン専用でない別個のハードウェアストレージ装置間に物理的に分配され、格納されていたとしても、特定のデータベーススキーマと同一のアイデンティティドメインに所属するユーザおよびサービスインスタンスのみが（さらに、ポリシーにより認可された場合に）、その特定のデータベーススキーマに一致するデータのいずれかにアクセスすることが許可される。言い換えれば、個々の物理的なストレージ装置が別個のアイデンティティドメイン専用であっても、表領域１８１２Ａ−Ｎが、それぞれそれらのアイデンティティドメインに所属するデータベーススキーマ専用であることを必ずしも保証するわけではない。

【0192】

表領域１８１２Ａ−Ｎの各々は、別個のデータファイルを格納できる。例えば、表領域１８１２Ａ−Ｎはそれぞれ、データファイル１８１４Ａ−Ｎをそれぞれ格納し得る。データファイル１８１４Ａ−Ｎの各特定のデータファイルは、その特定のデータファイルを格納する表領域の専用であるデータベーススキーマにより定義されるリレーショナルテーブル内に論理的に含まれるデータレコード（例えば、リレーショナルテーブル行）を物理的に含み得る。例えば、表領域１８１２Ａがデータベーススキーマ１８０６ＡＡ専用であると仮定すると、データファイル１８１４Ａは、リレーショナルテーブル１８０８ＡＡＡ−ＡＡＮに論理的に含まれる（かつ、それらのレプリカであるリレーショナルテーブル１８０８ＢＡＡ−ＢＡＮに論理的に含まれる）データレコードを物理的に含み得る。別の例として、表領域１８１２Ｂがデータベーススキーマ１８０６ＡＮ専用であると仮定すると、データファイル１８１４Ｂは、リレーショナルテーブル１８０８ＡＮＡ−ＡＮＮに論理的に含まれる（かつ、それらのレプリカであるリレーショナルテーブル１８０８ＢＮＡ−ＢＮＮに論理的に含まれる）データレコードを物理的に含み得る。

【0193】

図１９は、発明の実施例に係る、Ｎｕｖｉａｑクラウドシステム１９００の例を示すブロック図である。システム１９００は、テナントプロビジョニングシステム（ＳＤＩ）１９０２、テナントコンソール１９０４、統合開発環境（Integrated Development Environment: ＩＤＥ）１９０６、コマンドラインインターフェイス（ＣＬＩ）１９０８、ウェブゲート１９１０、Ｎｕｖｉａｑプロキシ１９１２、Ｎｕｖｉａｑマネージャ１９１８、Ｎｕｖｉａｑデータベース１９２４、プラットフォームインスタンス１９２６、ウイルススキャンモジュール１９３４、ＩＤＭシステム１９３６、ＣＲＭモジュール１９４２、およびアイデンティティ管理１９４０を含み得る。ともに、Ｎｕｖｉａｑプロキシ１９１２、Ｎｕｖｉａｑマネージャ１９１８、およびＮｕｖｉａｑデータベース１９２４は、概念的にＮｕｖｉａｑ１９５０を構成する。テナントプロビジョニングＡＰＩ１９０２およびテナントコンソール１９０４は、Ｎｕｖｉａｑプロキシ１９１２と遣り取りし得る。ＩＤＥ１９０６およびＣＬＩ１９０８は、Ｎｕｖｉａｑマネージャ１９１８と遣り取りし得る。ウェブゲート１９１０は、プラットフォームインスタンス１９２６と遣り取りし得る。Ｎｕｖｉａｑマネージャ１９１８は、Ｎｕｖｉａｑデータベース１９２４、ウイルススキャンモジュール１９３４、ＩＤＭシステム１９３６、およびプラットフォームインスタンス１９２６と遣り取りし得る。プラットフォームインスタンス１９２６は、ＣＲＭモジュール１９４２およびアイデンティティ管理１９４０と遣り取りし得る。Ｎｕｖｉａｑプロキシ１９１２は、オラクルハイパーテキスト転送プロトコルサーバ（Oracle Hypertext Transfer Protocol server: ＯＨＳ）１９１４およびウェブロジックサーバ１９１６Ａ−Ｎを含み得る。Ｎｕｖｉａｑマネージャ１９１８は、ＯＨＳ１９２０およびウェブロジックサーバ１９２２Ａ−Ｎを含み得る。プラットフォームインスタンス１９２６は、ウェブロジックサーバ１９２８Ａ−Ｎ、ウェブロジック管理サーバ１９３０、およびインスタンスデータベース１９３２を含み得る。

【0194】

一実施例では、Ｎｕｖｉａｑマネージャ１９１８は、システム１９００へのエントリポイントとして機能し得る。このようなエントリポイントとして、Ｎｕｖｉａｑマネージャ１９１８は、安全なウェブサービスＡＰＩを介してＰａａＳオペレーションへの安全なアクセスを提供し得る。Ｎｕｖｉａｑマネージャ１９１８は、Ｎｕｖｉａｑデータベース１９２４におけるシステム１９００の状態を追跡し得る。Ｎｕｖｉａｑマネージャ１９１８は、ジョブ実行を制御し得る。テナントプロビジョニングシステム（ＳＤＩ）１９０２は、Ｎｕｖｉａｑマネージャ１９１８にアクセスし、Ｎｕｖｉａｑマネージャ１９１８に、クラウドベースのコンピュータ環境下でプロビジョニングオペレーション（例えば、サービスインスタンスプロビジョニングオペレーション）を行なうように命令し得る。テナントコンソール１９１４は、Ｎｕｖｉａｑマネージャ１９１８にアクセスし、Ｎｕｖｉａｑマネージャ１９１８に、クラウドベースのコンピュータ環境下でデプロイメントオペレーション（例えば、サービスインスタンスデプロイメントオペレーション）を行なうように命令し得る。Ｎｕｖｉａｑマネージャ１９１８は、このようなオペレーションに関わるジョブを非同期に実行し得る。このようなジョブは、ＰａａＳワークフローに特有のアクションのシーケンスを含み得る。Ｎｕｖｉａｑマネージャ１９１８は、ジョブのアクションを順次行ない得る。このようなアクションは、エンタープライズマネージャ（ＥＭ）モジュールのコマンドラインインターフェイスなどの他のコンポーネントへのタスクの委任を含み得る。Ｎｕｖｉａｑマネージャ１９１８は、ＯＨＳ１９２０とともにウェブロジックサーバ１９２０Ａ−Ｎのクラスタ上で実行され得る。

【0195】

一実施例では、Ｎｕｖｉａｑプロキシ１９１２は、他のシステムがＡＰＩを介して遣り取りし得るアクセスポイントとなり得る。Ｎｕｖｉａｑプロキシ１９１２は、このＡＰＩを介して他のシステムから要求を受取り、それらの要求をＮｕｖｉａｑマネージャ１９１８へ転送し得る。一実施例では、Ｎｕｖｉａｑプロキシ１９１２は、その内部にＮｕｖｉａｑマネージャ１９１８が位置するファイアウォールの外部に位置し得る。Ｎｕｖｉａｑプロキシ１９１２は、ＯＨＳ１９１４とともにウェブロジックサーバ１９１６Ａ−Ｎのクラスタ上で実行され得る。

【0196】

一実施例では、Ｎｕｖｉａｑデータベース１９２４は、プラットフォームインスタンス１９２６ならびにデプロイメント計画、アプリケーション、ウェブロジックドメイン、ジョブ、およびアラートに関係するデータを追跡し得る。Ｎｕｖｉａｑデータベース１９２４内に格納された主キーは、顧客（または「テナント」）と、それらのアイデンティティドメイン（または「テナンシ」）と、それらの顧客がサブスクライブしたサービスインスタンスとの間のマッピングを含むクラウドワイドのサービスデータベース（図示せず）内に格納されたキーと整合されてもよい。

【0197】

一実施例では、プラットフォームインスタンス１９２６は、特定のアイデンティティドメインにウェブロジックサービスリソースを提供する。したがって、別個のプラットフォームインスタンス１９２６が、クラウドベースの環境下で、各別個のアイデンティティドメインについてインスタンス化され、当該アイデンティティドメイン専用となり得る。しかしながら、このような各プラットフォームインスタンス１９２６は、Ｎｕｖｉａｑマネージャ１９１８により中心で管理され得るため、Ｎｕｖｉａｑマネージャ１９１８のたった１つのインスタンスがインスタンス化されればよいだけである。一実施例では、Ｎｕｖｉａｑマネージャ１９１８は、各アイデンティティドメインについての各別個のプラットフォームインスタンス１９２６を作成するコンポーネントである。プラットフォームインスタンス１９２６は、ウェブロジックサーバのアイデンティティドメイン専用の「スライス」として想像され得る。Ｎｕｖｉａｑ１９５０により処理された一部のワークフローは、サービスデータベース内に格納されたマッピングにより示されるように、ウェブロジック「スライス」を、顧客がサブスクライブしたさまざまな他のサービスインスタンスへのクライアントとして機能するように構成するために、上述のサービスデータベースへのアクセスを含み得る。テナントコンソール１９０４は、アイデンティティドメイン内の任命された管理者に、それらの管理者が、そのアイデンティティドメイン内に含まれるプラットフォームインスタンス１９２６上で実行されているアプリケーションを管理できるようにするユーザインターフェイスを提供し得る。さらに、このようなアプリケーションを管理するためにＣＬＩ１９０８が用いられ得る。各プラットフォームインスタンス１９２６には、クラウドコンピューティング環境内でユニークな識別子が割り当てられ得、このユニークな識別子を用いて、そのプラットフォームインスタンス１９２６を利用するオペレーションにおいてプラットフォームインスタンス１９２６を参照することができる。

【0198】

一実施例では、Ｎｕｖｉａｑ１９５０は、ウェブロジックワークフローを行なうためにＮｕｖｉａｑ１９５０外部のコンポーネントとともに動作し得る。これらの外部コンポーネントのうち、テナントプロビジョニングモジュール（ＳＤＩ）１９０２は、アセンブリデプロイヤサブシステムを含み得る。アセンブリデプロイヤサブシステムは、Ｎｕｖｉａｑ１９５０とオラクルバーチャル・アセンブリ・ビルダ（ＯＶＡＢ）とオラクル仮想マシン（ＯＶＭ）との間のインタラクションを管理し得る。Ｎｕｖｉａｑ１９５０は、アセンブリデプロイヤサブシステムを用いて、アセンブリをデプロイする、アセンブリをアンデプロイする、アセンブリデプロイメントを記述する、さらに、アプライアンスをスケーリングすることができる。Ｎｕｖｉａｑ１９５０は、ウェブサービスＡＰＩを介してアセンブリデプロイヤサブシステムにアクセスし得る。

【0199】

さらに、外部コンポーネントのうち、ウイルススキャンモジュール１９３４は、ウイルスおよび他の有害な実行可能命令がないかさまざまなアーティファクトをスキャンした後に、それらのアーティファクトがクラウドコンピューティング環境における任意のアプリケーションにデプロイされることを許可する。ウイルススキャンモジュール１９３４は、クラウドコンピューティング環境における複数の別個のコンポーネントに「サービスとしてのスキャン」を提供し得る。一実施例では、ウイルススキャンモジュール１９３４は、複数の別個のアイデンティティドメイン内のコンポーネントにそのサービスを提供し得るため、アイデンティティドメイン毎に別個のウイルススキャンモジュールがインスタンス化される必要がない。詳細を上述したＩＤＭシステム１９３６は、Ｎｕｖｉａｑ１９５０により行なわれるジョブにセキュリティを提供し得る。ＣＲＭモジュール１９４２は、さまざまなアイデンティティドメイン内に配置されたＪＡＶＡサービスインスタンスと対応付けられ得る。これらのＪＡＶＡサービスインスタンスとＣＲＭモジュール１９４２とのこのような対応付けは、このようなＪＡＶＡサービスインスタンスにより実行されるアプリケーションが、ＣＲＭモジュール１９４２にウェブサービスコールを行なうことにより、ＣＲＭモジュール１９４２のＣＲＭ機能を行なうことを可能にする。

【0200】

ハードウェア概略
図９は、本発明の実施例に従って用いられ得るシステム環境９００のコンポーネントを示す簡略ブロック図である。図示されるように、システム環境９００は、固有のクライアントアプリケーションや、場合によってはウェブブラウザなどの他のアプリケーションなどを含むクライアントアプリケーションを動作させるように構成された１つ以上のクライアントコンピューティング装置９０２、９０４、９０６および９０８を含む。さまざまな実施例においては、クライアントコンピューティング装置９０２、９０４、９０６および９０８はサーバ９１２と対話し得る。

【0201】

クライアントコンピューティング装置９０２、９０４、９０６および９０８は、汎用パーソナルコンピュータ（一例として、マイクロソフトウィンドウズ（登録商標）および／またはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、（マイクロソフトウィンドウズモバイルなどのソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリーまたは使用可能な他の通信プロトコルである）携帯電話もしくはＰＤＡ、ならびに／または、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されるものではない）のいずれかを実行するワークステーションコンピュータであってもよい。代替的には、クライアントコンピューティング装置９０２、９０４、９０６および９０８は、ネットワーク（例えば、以下に記載のネットワーク９１０）を介して通信することができるシン・クライアントコンピュータ、インターネットへの接続が可能なゲーム機および／またはパーソナルメッセージング装置などのその他の電子装置であってもよい。例示的なシステム環境９００が４つのクライアントコンピューティング装置とともに示されているが、いかなる数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置がサーバ９１２と対話してもよい。

【0202】

システム環境９００はネットワーク９１０を含み得る。ネットワーク９１０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されるものではないさまざまな市販のプロトコルのいずれかを使用してデータ通信をサポートし得る、当業者になじみのある任意のタイプのネットワークであってもよい。単に一例として、ネットワーク９１０は、イーサネット（登録商標）ネットワーク、トークン・リング・ネットワークなどのローカルエリアネットワーク（local area network：ＬＡＮ）、広域ネットワーク、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を含むがこれに限定されるものではない仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えばＩＥＥＥ８０２．１１の一連のプロトコル、当該技術分野において公知のブルートゥース（登録商標）プロトコルおよび／またはその他の無線プロトコルのいずれかの下で動作するネットワーク）、ならびに／または、これらのおよび／もしくは他のネットワークの任意の組み合わせであってもよい。

【0203】

システム環境９００はまた１つ以上のサーバコンピュータ９１２を含む。サーバコンピュータ９１２は、汎用コンピュータ、特化サーバコンピュータ（一例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式のサーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであり得る。さまざまな実施例においては、サーバ９１２は、１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。

【0204】

サーバ９１２は、市販のサーバオペレーティングシステムに加えて、上述のうちいずれかを含むオペレーティングシステムを実行し得る。サーバ９１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、データベースサーバなどを含む、さまざまな追加のサーバアプリケーションおよび／もしくは中間層アプリケーションのいずれかを実行し得る。例示的なデータベースサーバとしては、オラクル、マイクロソフト、サイベース、ＩＢＭなどから市販されているものが挙げられるが、これらに限定されるものではない。

【0205】

システム環境９００はまた１つ以上のデータベース９１４および９１６を含み得る。データベース９１４および９１６はさまざまな位置に存在してもよい。一例として、データベース９１４および９１６のうち１つ以上は、サーバ９１２に対してローカルな（および／またはサーバ９１２に常駐する）非一時的な記憶媒体上に存在してもよい。代替的には、データベース９１４および９１６は、サーバ９１２から離れており、ネットワークベースの接続または専用の接続を介してサーバ９１２と通信してもよい。一組の実施例においては、データベース９１４および９１６は、当業者になじみのあるストレージエリアネットワーク（ＳＡＮ：storage-area network）に存在していてもよい。同様に、サーバ９１２に起因する機能を実行するのに必要な如何なるファイルも、適宜、サーバ９１２上にローカルに格納および／または遠隔に格納され得る。一組の実施例においては、データベース９１４および９１６は、ＳＱＬでフォーマットされたコマンドに応じてデータを格納、更新および検索するように適合されたリレーショナルデータベース、例えばオラクルによって提供されるデータベースなど、を含み得る。

【0206】

図１０は、本発明の実施例に従って用いられ得るコンピュータシステム１０００の簡略ブロック図である。例えば、サーバ９１２またはクライアント９０２、９０４、９０６もしくは９０８はシステム１０００などのシステムを用いて実現されてもよい。バス１０２４を介して電気的に接続され得るハードウェア要素を含むコンピュータシステム１０００が示される。ハードウェア要素は、１つ以上の中央処理装置（ＣＰＵ：central processing unit）１００２、１つ以上の入力装置１００４（例えばマウス、キーボードなど）、および１つ以上の出力装置１００６（例えば表示装置、プリンタなど）を含み得る。コンピュータシステム１０００はまた１つ以上の記憶装置１００８を含み得る。一例として、記憶装置１００８は、ディスクドライブ、光学記憶装置、およびソリッドステート記憶装置、例えば、プログラム可能、フラッシュ更新可能などであり得るランダムアクセスメモリ（ＲＡＭ：random access memory）および／またはリードオンリメモリ（ＲＯＭ：read-only memory）などの記憶装置を含んでいてもよい。

【0207】

コンピュータシステム１０００は、コンピュータ読取可能記憶媒体リーダ１０１２、通信サブシステム１０１４（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信装置など）、ならびに、上述のＲＡＭ装置およびＲＯＭ装置を含み得るワーキングメモリ１０１８を付加的に含み得る。いくつかの実施例においては、コンピュータシステム１０００はまた、デジタル信号プロセッサ（ＤＳＰ：digital signal processor）、専用プロセッサなどを含み得る処理加速ユニット１０１６を含んでもよい。

【0208】

さらに、コンピュータ読取可能記憶媒体リーダ１０１２は、ともに（および任意に、記憶装置１００８と組み合わせて）一時的および／またはより永久的にコンピュータ読取可能な情報を含むためのリモートの、ローカルの、固定されたおよび／または取外し可能な記憶装置プラス記憶媒体を包括的に表わすコンピュータ読取可能記憶媒体１０１０に接続可能である。通信システム１０１４は、ネットワーク９１０および／またはシステム環境９００に関して上述された他のいずれかのコンピュータとのデータの交換を許可し得る。

【0209】

コンピュータシステム１０００はまた、オペレーティングシステム１０２０および／または他のコード１０２２、例えば（クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、ＲＤＢＭＳなどであり得る）アプリケーションプログラムなどを含むワーキングメモリ１０１８内にその時点で位置するように示されたソフトウェア要素を含み得る。具体的な実施例においては、ワーキングメモリ１０１８は、上述のようなマルチテナントクラウドベースＩＤＭシステムのために用いられる実行可能コードおよび関連データ構造を含み得る。コンピュータシステム１０００の代替的な実施例は、上記のものからの複数の変更例を有し得ることが理解されるべきである。例えば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素がハードウェア、（アプレットなどの高移植性ソフトウェアを含む）ソフトウェアまたはそれら両方で実現されてもよい。さらに、ネットワーク入力／出力装置などの他のコンピューティング装置への接続が利用されてもよい。

【0210】

コードまたはコードの一部を含むための記憶媒体およびコンピュータ読取可能媒体は、記憶媒体を含む当該技術分野において公知のまたは使用される任意の適切な媒体を含み得て、当該媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納および／または情報の伝達のための任意の方法または技術において実現される揮発性および不揮発性の（非一時的な）、取外し可能および取外し不可能な媒体などであって、所望の情報を格納または伝送するために使用可能であり、コンピュータによってアクセス可能であるＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、またはその他の媒体を含むが、これらに限定されない。

【0211】

図２７、図２８および図２９は、それぞれ、上述のとおり本発明の原理に従って構成されるコンピューティング装置２７００、２８００、２９００の機能ブロック図を示す。コンピューティング装置の機能ブロックは、本発明の原理を実行するために、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアとの組み合わせによって実現されてもよい。当業者であれば、図２７、図２８および図２９において記載される機能ブロックを組み合わせるかまたはサブブロックに分割して上述のような本発明の原理を実現し得ることを理解する。したがって、この明細書中の記載は、この明細書中に記載された機能ブロックのいかなる実現可能な組み合わせまたは分割またはさらなる定義をもサポートし得る。

【0212】

図２７に示されるように、コンピューティング装置２７００は、第１の作成ユニット２７０２、第１の関連付けユニット２７０４、第１の共有ユニット２７０６、第２の作成ユニット２７０８、第２の関連付けユニット２７１０、および第２の共有ユニット２７１２を含む。

【0213】

第１の作成ユニット２７０２は、共有のアイデンティティ管理システムを介して第１のアイデンティティドメインを作成し得る。第１の関連付けユニット２７０４は、第１の複数のサービスを第１のアイデンティティドメインと関連付け得る。第１の共有ユニット２７０６は、第１の複数のサービスの間で、共有のアイデンティティ管理システムにより管理されるユーザの第１のセットのアイデンティティを共有し得る。第２の作成ユニット２７０８は、共有のアイデンティティ管理システムを介して、第１のアイデンティティドメインから分離された第２のアイデンティティドメインを作成し得る。第２の関連付けユニット２７１０は、第２の複数のサービスを第２のアイデンティティドメインと関連付け得る。第２の共有ユニット２７１２は、第２の複数のサービスの間で、共有のアイデンティティ管理システムにより管理されるユーザの第２のセットのアイデンティティを共有し得る。

【0214】

コンピューティング装置２７００は、第１および第２のマッピングユニット２７１４および２７１６をさらに含み得る。第１のマッピングユニット２７１４は、共有のアイデンティティ管理システムを介して、（ａ）ユーザの第１のセットの第１のユーザを（ｂ）第１の複数のサービスのサブセットに対する第１のアクセス許可にマッピングし得る。第２のマッピングユニット２７１６は、共有のアイデンティティ管理システムを介して、（ｃ）ユーザの第２のセットの第２のユーザを（ｄ）第２の複数のサービスのサブセットに対する第２のアクセス許可にマッピングし得る。

【0215】

コンピューティング装置２７００は、第３および第４のマッピングユニット２７１８および２７２０をさらに含み得る。第３のマッピングユニット２７１８は、共有のアイデンティティ管理システムを介して、（ａ）ユーザの第１のセットの第１のユーザを（ｂ）第１の複数のサービスのサブセットに対する第１のアクセス許可にマッピングされた第１のロールにマッピングし得る。第４のマッピングユニット２７２０は、共有のアイデンティティ管理システムを介して、（ｃ）ユーザの第２のセットの第２のユーザを（ｄ）第２の複数のサービスのサブセットに対する第２のアクセス許可にマッピングされた第２のロールにマッピングし得る。

【0216】

コンピューティング装置２７００はさらに、第１および第２の防止ユニット２７２２、２７２４と、許可ユニット２７２６とを含み得る。第１の防止ユニット２７２２は、ユーザの第１のセットにおけるユーザが、サービスの第１のセットでなく、サービスの第２のセットにおけるサービスに対するオペレーションを行なうことを防止し得る。第２の防止ユニット２７２４は、ユーザの第２のセットにおけるユーザが、サービスの第２のセットでなく、サービスの第１のセットにおけるサービスに対するオペレーションを行なうことを防止し得る。許可ユニット２７２６は、ユーザが、サービスの第１のセットにおけるサービスおよびサービスの第２のセットにおけるサービスの両方に対するオペレーションを行なうことを可能にし得る。

【0217】

コンピューティング装置２７００はさらに、アイデンティティドメインにより分割されるライトウェイトアクセスプロトコル（ＬＤＡＰ）ディレクトリの第１のパーティション内にユーザの第１のセットのアイデンティティを格納する第１の格納ユニット２７２８と、ＬＤＡＰディレクトリの第２のパーティション内にユーザの第２のセットのアイデンティティを格納する第２の格納ユニット２７３０とを含み得る。

【0218】

コンピューティング装置２７００はさらに、特定のユーザが、ログインプロセスの一部として、当該特定のユーザがアクセスしようとしている特定のアイデンティティドメインを識別できるユーザインターフェイス要素を含むユーザインターフェイスを提示する第１の提示ユニット２７３２をさらに含み得る。

【0219】

コンピューティング装置２７００はさらに、アイデンティティドメインに対してユーザアイデンティティを追加および削除するための制御を提供するコンソールを提示する第２の提示ユニット２７３４と、コンソールを介してアイデンティティドメイン管理者からコマンドを受取る第１の受取ユニット２７３６と、アイデンティティドメイン管理者が所属する特定のアイデンティティドメインを決定する決定ユニット２７３８と、アイデンティティドメイン管理者によりコンソールを介して特定のアイデンティティドメインに行なわれるユーザアイデンティティ追加および削除オペレーションを制限する制限ユニット２７４０とを含み得る。

【0220】

コンピューティング装置２７００はさらに、第１、第２および第３の割当てユニット２７４２、２７４４および２７４６を含み得る。第１の割当てユニット２７４２は、ユーザの第１のセットの第１のユーザに、ユーザの第１のセットにおける他のユーザにサービス管理者ロールを割り当てる能力を第１のユーザに付与するアイデンティティドメイン管理者ロールを割り当て得る。第２の割当てユニット２７４４は、アイデンティティドメイン管理者としての第１のユーザにより選択されたユーザの第１のセットの第２のユーザに、第１の複数のサービスの第１のサービスを管理する能力を第２のユーザに付与する第１のサービス管理者ロールを割り当て得る。第３の割当てユニット２７４６は、アイデンティティドメイン管理者としての第１のユーザにより選択されたユーザの第１のセットの第３のユーザに、第１の複数のサービスの第２のサービスを管理する能力を第３のユーザに付与する第２のサービス管理者ロールを割り当て得る。

【0221】

コンピューティング装置２７００はさらに、第１のアイデンティティドメインにおけるユーザアイデンティティを有さないが、第１のアイデンティティドメインが購入されたアカウントと関連付けられた第１の人から、第１のアイデンティティドメインにおけるユーザアイデンティティを同様に有さない第２の人の電子メールアドレスを受取る第２の受取ユニット２７４８と、第１の人から、第１の人が第１のアイデンティティドメイン内の第２の人を指名しているロールを受取る第３の受取ユニット２７５０と、第２の人の電子メールアドレスに、第１のアイデンティティドメイン内のユーザアイデンティティを作成するのに利用可能なウェブベースフォームへのハイパーリンクを含む電子メールメッセージを送信する送信ユニット２７５２と、ウェブベースフォームを介して第２の人が供給した情報に基づいて、ユーザの第１のセットのアイデンティティに第２の人のアイデンティティを追加する第１の追加ユニット２７５４と、第１のアイデンティティドメイン内の第２の人のアイデンティティにそのロールを割り当てる第４の割当てユニット２７５６とを含み得る。

【0222】

コンピューティング装置２７００はさらに、サービスの第１のセットに特定のサービスを追加する要求を受取る第４の受取ユニット２７５８と、要求に応じてサービスの第１のセットに特定のサービスを追加する第２の追加ユニット２７６０と、第１のアイデンティティドメイン内に、特定のサービスのタイプに基づいて複数のロールの階層から自動的に選択されたロールの階層を定義する定義ユニット２７６２とを含み得る。

【0223】

コンピューティング装置２７００はさらに、サービスの第１のセットにおけるサービスのインスタンスである特定のサービスインスタンスを、クラウドコンピューティング環境下で定義された複数のアイデンティティドメインについてのアイデンティティを格納するアイデンティティストアの第１のパーティションに結び付ける第１のバインドユニット２７６４と、特定のサービスインスタンスを、クラウドコンピューティング環境下で定義された異なるアイデンティティドメインに所属する複数のサービスインスタンスについてのポリシーを格納するポリシーストアの第２のパーティションに結び付ける第２のバインドユニット２７６６とを含み得る。第１のパーティションは、第１のアイデンティティドメインに所属するアイデンティティのみを含み、第２のパーティションは、特定のサービスインスタンスに関係するポリシーのみを含む。

【0224】

図２８を参照して、コンピューティング装置２８００は、作成ユニット２８０２、実施ユニット２８０４、追加ユニット２８０６、第１の格納ユニット２８０８および第２の格納ユニット２８１０を含む。作成ユニット２８０２は、クラウドコンピューティング環境内の複数のアイデンティティドメインを作成し得る。実施ユニット２８０４は、複数のアイデンティティドメイン内のアイデンティティドメイン間の分離を実施し得る。追加ユニット２８０６は、複数のアイデンティティドメインの特定のアイデンティティドメインにサービスインスタンスを追加し得る。第１の格納ユニット２８０８は、サービスインスタンスと、複数のアイデンティティドメインの各アイデンティティドメイン毎にアイデンティティを格納するアイデンティティストアの特定のパーティションとを関連付けるデータを格納し得る。第２の格納ユニット２８１０は、サービスインスタンスと、複数のアイデンティティドメインの異なるアイデンティティドメインと関連付けられた複数のサービスインスタンスについてのポリシーを格納するポリシーストアの特定のパーティションとを関連付けるデータを格納し得る。

【0225】

コンピューティング装置２８００はさらに、第１の割当てユニット２８１２および第２の割当てユニット２８１４を含み得る。第１の割当てユニット２８１２は、アイデンティティストアに格納され、特定のアイデンティティドメインと関連付けられた第１のユーザアイデンティティを有する第１のユーザに、ロールの階層から、第１のロールを割り当て得る。第１のロールは、第１のロールを有するユーザが、特定のアイデンティティドメインと関連付けられたすべてのサービスインスタンスを管理することを可能にするロールである。第２の割当てユニット２８１４は、アイデンティティストアに格納された第２のユーザアイデンティティを有する第２のユーザに、ロールの階層から、第２のロールを割り当て得る。第２のロールは、第２のロールを有するユーザが、特定のアイデンティティドメインと関連付けられた単一のサービスインスタンスを管理することを可能にするロールである。

【0226】

一例では、第２の割当てユニット２８１４は、第１のユーザが第２のユーザに第２のロールを委任することに応じて、第２のユーザに第２のロールを割り当て得る。

【0227】

一例では、追加ユニット２８０６はさらに、特定のサービスインスタンスのタイプに関連付けられた複数のロールにより定義される第３のロールを、アイデンティティストアに格納され、特定のアイデンティティドメインと関連付けられた第３のアイデンティティを有する第３のユーザに割り当てる第３の割当てユニット２８１６を含み得る。

【0228】

コンピューティング装置２８００はさらに、第１の継承ユニット２８１８および第２の継承ユニット２８２０を含み得る。第１の継承ユニット２８１８は、第２のロールに、第３のロールと関連付けられたすべての許可を継承させ得る。第２の継承ユニット２８２０は、第１のロールに、第２のロールにより継承されるすべての許可を継承させ得る。

【0229】

一例では、作成ユニット２８０２は、クラウドコンピューティング環境内に特定のアイデンティティドメインを作成し得る。この場合、作成ユニット２８０２はさらに、特定される電子メールアドレスに電子メールメッセージを送信する送信ユニット２８２２を含み得、電子メールメッセージは、電子メールメッセージの受信者が、特定のアイデンティティドメイン内に管理アイデンティティを確立できるメカニズムを提供する。

【0230】

図２９を参照して、コンピューティング装置２９００は、確立ユニット２９０２、第１の提供ユニット２９０４および第２の提供ユニット２９０６を含む。確立ユニット２９０２は、シングルアイデンティティ管理（ＩＤＭ）システムをクラウドコンピューティング環境下で確立させ得る。第１の提供ユニット２９０４は、シングルＩＤＭシステムに、クラウドコンピューティング環境内に定義され、かつクラウドコンピューティング環境内に定義された第２のアイデンティティドメインから分離された第１のアイデンティティドメインと関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供させ得る。第２の提供ユニット２９０６は、シングルＩＤＭシステムに、第２のアイデンティティドメインと関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供させ得る。

【0231】

コンピューティング装置２９００はさらに、第１および第２の格納ユニット２９０８、２９１０と、第１および第２の生成ユニット２９１２、２９１４とを含み得る。第１の格納ユニット２９０８は、シングルＩＤＭシステムに、クラウドコンピューティング環境内に維持される単一のアイデンティティストア内の第２のアイデンティティドメインでなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを格納させ得る。第２の格納ユニット２９１０は、シングルＩＤＭシステムに、単一のアイデンティティストア内の第１のアイデンティティドメインでなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを格納させ得る。第１の生成ユニット２９１２は、シングルＩＤＭシステムに、第１のクレデンシャルを生成させ得、第１のクレデンシャルは、第１のサービスインスタンスが、第１のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可する。第２の生成ユニット２９１４は、シングルＩＤＭシステムに、第２のクレデンシャルを生成させ得、第２のクレデンシャルは、第２のサービスインスタンスが、第２のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可する。

【0232】

コンピューティング装置２９００はさらに、第３および第４の格納ユニット２９１６、２９１８と、第３および第４の生成ユニット２９２０、２９２２とを含み得る。第３の格納ユニット２９１６は、シングルＩＤＭシステムに、クラウドコンピューティング環境内に維持される単一のポリシーストア内の第２のサービスインスタンスでなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納させ得る。第４の格納ユニット２９１８は、シングルＩＤＭシステムに、単一のポリシーストア内の第１のサービスインスタンスでなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納させ得る。第３の生成ユニット２９２０は、シングルＩＤＭシステムに、第１のクレデンシャルを生成させ得、第１のクレデンシャルは、第１のサービスインスタンスが、第１のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可する。第４の生成ユニットは、シングルＩＤＭシステムに、第２のクレデンシャルを生成させ得、第２のクレデンシャルは、第２のサービスインスタンスが、第２のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可する。

【0233】

本発明の特定の実施例について説明してきたが、さまざまな変形例、変更例、代替的な構成および等価物も本発明の範囲内に包含される。本発明の実施例は、特定の具体的なデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自由に動作できる。さらに、特定の一連のトランザクションおよびステップを使用して本発明の実施例について説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されるものではないということが当業者に明らかであるべきである。

【0234】

さらに、ハードウェアおよびソフトウェアの特定の組み合わせを使用して本発明の実施例について説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本発明の範囲内であることが認識されるべきである。本発明の実施例は、ハードウェアのみで実現されてもよく、またはソフトウェアのみで実現されてもよく、またはそれらの組み合わせを使用して実現されてもよい。

【0235】

さらに、本発明のある実施例は、機能的に次のように定義され得る。具体的には、クラウドコンピューティング環境内にシングルアイデンティティ管理（ＩＤＭ）を含むシステムが提供される。システムは、クラウドコンピューティング環境内に定義され、かつクラウドコンピューティング環境内に定義された第２のアイデンティティドメインから分離された第１のアイデンティティドメインと関連付けられた第１のサービスインスタンスにＩＤＭ機能を提供する手段と、第２のアイデンティティドメインと関連付けられた第２のサービスインスタンスにＩＤＭ機能を提供する手段とを含む。

【0236】

好ましくは、システムはさらに、クラウドコンピューティング環境内に維持される単一のアイデンティティストア内の第２のアイデンティティドメインでなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを格納する手段と、単一のアイデンティティストア内の第１のアイデンティティドメインでなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを格納する手段と、第１のクレデンシャルを生成する手段とをさらに含み、第１のクレデンシャルは、第１のサービスインスタンスが、第１のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第１のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可し、システムはさらに、第２のクレデンシャルを生成する手段を含み、第２のクレデンシャルは、第２のサービスインスタンスが、第２のアイデンティティドメインと関連付けられないユーザアイデンティティを含む単一のアイデンティティストアの部分でなく、第２のアイデンティティドメインと関連付けられたユーザアイデンティティを含む単一のアイデンティティストアの部分と対話することを許可する。

【0237】

好ましくは、システムはさらに、クラウドコンピューティング環境内に維持される単一のポリシーストア内の第２のサービスインスタンスでなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納する手段と、単一のポリシーストア内の第１のサービスインスタンスでなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを格納する手段と、第１のクレデンシャルを生成させる手段とをさらに含み、第１のクレデンシャルは、第１のサービスインスタンスが、第１のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第１のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可し、システムはさらに、第２のクレデンシャルを生成させる手段を含み、第２のクレデンシャルは、第２のサービスインスタンスが、第２のサービスインスタンスと関連付けられないセキュリティアクセスポリシーを含む単一のポリシーストアの部分でなく、第２のサービスインスタンスと関連付けられたセキュリティアクセスポリシーを含む単一のポリシーストアの部分と対話することを許可する。

【0238】

したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかしながら、追加、削減、削除ならびに他の変形および変更が、より広範な精神および範囲から逸脱することなく、これらになされてもよいことは明白であろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20A】

【図20B】

【図21】

【図22A】

【図22B】

【図23】

【図24】

【図25】

【図26A】

【図26B】

【図26C】

【図26D】

【図26E】

【図27】

【図28】

【図29】