特表 2024-531889 シングルタイプコンピューティングシステムにおけるマルチタイプユーザのサポート

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

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

(11)【公表番号】

(43)【公表日】2024-09-03

(54)【発明の名称】シングルタイプコンピューティングシステムにおけるマルチタイプユーザのサポート

(51)【国際特許分類】

   G06F 16/28 20190101AFI20240827BHJP

   G06F 21/62 20130101ALI20240827BHJP

   G06F 15/00 20060101ALI20240827BHJP

【ＦＩ】

G06F16/28

G06F21/62 318

G06F15/00 410Z

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024505169

(86)(22)【出願日】2022-05-23

(85)【翻訳文提出日】2024-01-26

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

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

(87)【国際公開日】2023-02-16

(31)【優先権主張番号】17/397,480

(32)【優先日】2021-08-09

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＨＤＭＩ

２．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】518249328

【氏名又は名称】サービスナウ， インコーポレイテッド

【氏名又は名称原語表記】ＳｅｒｖｉｃｅＮｏｗ， Ｉｎｃ．

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(74)【代理人】

【識別番号】100141553

【弁理士】

【氏名又は名称】鈴木 信彦

(72)【発明者】

【氏名】セガン ヴィンセント

(72)【発明者】

【氏名】ケイシー パトリック

(72)【発明者】

【氏名】シューマン デヴィッド

(72)【発明者】

【氏名】リー ス－シュアン

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

5B175

【Ｆターム（参考）】

5B175EA03

(57)【要約】

永続的ストレージは、親テーブルと１つまたは複数の子テーブルとを含み、親テーブルは、タイプを指定するクラスフィールドと、１つまたは複数のフィルタフィールドと、を含む。１つまたは複数のプロセッサは、第１のエンティティに関する第１のタイプの第１の情報を読み出すための第１のリクエストを受信することと、第１のエンティティに関する親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することと、第１のタイプと関連付けられている子テーブルから、第１の情報を取得することと、第２のエンティティに関する第２のタイプの第２の情報を読み出すための第２のリクエストを受信することと、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられているフィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することと、第２のエントリにおける一組の付加的なフィールドから、第２の情報を取得することと、を行ってもよい。

【特許請求の範囲】

【請求項1】

親テーブルと１つまたは複数の子テーブルとを含む永続的ストレージであり、前記親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、前記タイプがそれぞれ、前記１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、前記１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、前記タイプのうちの１つまたは複数と関連付けられている、永続的ストレージと、
第１のエンティティに関する第１のタイプの第１のタイプ固有情報を前記永続的ストレージから読み出すための第１のリクエストを受信することと、
前記第１のエンティティに関する前記親テーブルの第１のエントリにおいて、前記第１のタイプが前記クラスフィールドにおいて指定されているものと判定することと、
前記１つまたは複数の子テーブルのうちの特定の子テーブルから、前記第１のタイプ固有情報を取得することであり、前記特定の子テーブルが、前記第１のタイプと関連付けられている、ことと、
前記第１のリクエストに応答して、前記第１のタイプ固有情報を提供することと、
第２のエンティティに関する第２のタイプの第２のタイプ固有情報を前記永続的ストレージから読み出すための第２のリクエストを受信することと、
前記第２のエンティティに関する前記親テーブルの第２のエントリにおいて、前記第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記親テーブルの前記第２のエントリにおける一組の付加的なフィールドから、前記第２のタイプ固有情報を取得することであり、前記一組の付加的なフィールドが、前記特定のタイプ固有フィルタフィールドと関連付けられている、ことと、
前記第２のリクエストに応答して、前記第２のタイプ固有情報を提供することと、
を行うように構成されている１つまたは複数のプロセッサと、
を備える、システム。

【請求項2】

前記１つまたは複数のプロセッサが、
前記第１のエンティティに関する前記第２のタイプの第３のタイプ固有情報を前記永続的ストレージから読み出すための第３のリクエストを受信することと、
前記親テーブルの前記第１のエントリにおいて、前記特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記親テーブルの前記第１のエントリにおける前記一組の付加的なフィールドから、前記第３のタイプ固有情報を取得することと、
前記第３のリクエストに応答して、前記第３のタイプ固有情報を提供することと、
を行うようにさらに構成されている、請求項１に記載のシステム。

【請求項3】

前記１つまたは複数のプロセッサが、
前記第１のエンティティに関して前記親テーブルを検索することと、
前記第１のエントリが前記第１のエンティティと関連付けられているものと判定することと、
を行うようにさらに構成されている、請求項１に記載のシステム。

【請求項4】

前記１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、前記親テーブルにおける１つまたは複数の付加的なフィールドと関連付けられている、請求項１に記載のシステム。

【請求項5】

前記第１のエンティティが、第１のユーザであり、前記第２のエンティティが、第２のユーザであり、前記第１のタイプ固有情報および前記第２のタイプ固有情報がそれぞれ、前記システムへのログオン、前記永続的ストレージ中の特定のデータユニットへのアクセスの許可、またはグラフィカルユーザインターフェース上での素材の提示のうちの１つまたは複数に関連する、請求項１に記載のシステム。

【請求項6】

前記第１のタイプ固有情報を取得することが、前記第１のエンティティと関連付けられている前記特定の子テーブルのエントリのフィールドから、前記第１のタイプ固有情報を読み出すことを含む、請求項１に記載のシステム。

【請求項7】

前記第１のエンティティが、一意の識別子と関連付けられており、前記親テーブルの前記第１のエントリが、前記一意の識別子を含み、前記特定の子テーブルの前記エントリが、前記一意の識別子を含み、前記第１のタイプ固有情報を読み出すことが、
前記一意の識別子に関して前記特定の子テーブルのエントリを検索することと、
前記特定の子テーブルの前記エントリにおいて前記一意の識別子を特定することと、
を含む、請求項６に記載のシステム。

【請求項8】

前記１つまたは複数のプロセッサが、前記親テーブルの前記第２のエントリにおいて、前記第２のタイプが前記クラスフィールドにおいて指定されていないものと判定することであり、前記特定のタイプ固有フィルタフィールドが、前記第２のタイプが前記クラスフィールドにおいて指定されていないことに基づいて考慮される、ことを行うようにさらに構成されている、請求項１に記載のシステム。

【請求項9】

前記１つまたは複数のプロセッサが、
前記第１のエンティティに関する前記第１のタイプの第３のタイプ固有情報を前記永続的ストレージに書き込むための第３のリクエストを受信することと、
前記親テーブルの前記第１のエントリにおいて、前記第１のタイプが前記クラスフィールドにおいて指定されているものと判定することと、
前記第３のタイプ固有情報を前記特定の子テーブルに書き込むことと、
前記第２のエンティティに関する前記第２のタイプの第４のタイプ固有情報を前記永続的ストレージに書き込むための第４のリクエストを受信することと、
前記親テーブルの前記第２のエントリにおいて、前記第２のタイプと関連付けられている前記特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記第４のタイプ固有情報を前記親テーブルにおける前記一組の付加的なフィールドに書き込むことと、
を行うようにさらに構成されている、請求項１に記載のシステム。

【請求項10】

前記第１のタイプ固有情報を取得することが、前記第１のエンティティに関する前記親テーブルの前記第１のエントリにおいて、前記第１のタイプが前記クラスフィールドにおいて指定されているものと判定することに応答して発生し、前記第２のタイプ固有情報を取得することが、前記第２のエンティティに関する前記親テーブルの前記第２のエントリにおいて、前記第２のタイプと関連付けられている前記特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することに応答して発生する、請求項１に記載のシステム。

【請求項11】

第１のエンティティに関する第１のタイプの第１のタイプ固有情報を永続的ストレージから読み出すための第１のリクエストを受信することであり、前記永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、前記親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、前記タイプがそれぞれ、前記１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、前記１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、前記タイプのうちの１つまたは複数と関連付けられている、ことと、
前記第１のエンティティに関する前記親テーブルの第１のエントリにおいて、前記第１のタイプが前記クラスフィールドにおいて指定されているものと判定することと、
前記１つまたは複数の子テーブルのうちの特定の子テーブルから、前記第１のタイプ固有情報を取得することであり、前記特定の子テーブルが、前記第１のタイプと関連付けられている、ことと、
前記第１のリクエストに応答して、前記第１のタイプ固有情報を提供することと、
第２のエンティティに関する第２のタイプの第２のタイプ固有情報を前記永続的ストレージから読み出すための第２のリクエストを受信することと、
前記第２のエンティティに関する前記親テーブルの第２のエントリにおいて、前記第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記親テーブルの前記第２のエントリにおける一組の付加的なフィールドから、前記第２のタイプ固有情報を取得することであり、前記一組の付加的なフィールドが、前記特定のタイプ固有フィルタフィールドと関連付けられている、ことと、
前記第２のリクエストに応答して、前記第２のタイプ固有情報を提供することと、
を含む、コンピュータ実行方法。

【請求項12】

前記第１のエンティティに関する前記第２のタイプの第３のタイプ固有情報を前記永続的ストレージから読み出すための第３のリクエストを受信することと、
前記親テーブルの前記第１のエントリにおいて、前記特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記親テーブルの前記第１のエントリにおける前記一組の付加的なフィールドから、前記第３のタイプ固有情報を取得することと、
前記第３のリクエストに応答して、前記第３のタイプ固有情報を提供することと、
をさらに含む、請求項１１に記載のコンピュータ実行方法。

【請求項13】

前記第１のエンティティに関して前記親テーブルを検索することと、
前記第１のエントリが前記第１のエンティティと関連付けられているものと判定することと、
をさらに含む、請求項１１に記載のコンピュータ実行方法。

【請求項14】

前記第１のタイプ固有情報を取得することが、前記第１のエンティティと関連付けられている前記特定の子テーブルのエントリのフィールドから、前記第１のタイプ固有情報を読み出すことを含む、請求項１１に記載のコンピュータ実行方法。

【請求項15】

前記第１のエンティティが、一意の識別子と関連付けられており、前記親テーブルの前記第１のエントリが、前記一意の識別子を含み、前記特定の子テーブルの前記エントリが、前記一意の識別子を含み、前記第１のタイプ固有情報を読み出すことが、
前記一意の識別子に関して前記特定の子テーブルのエントリを検索することと、
前記特定の子テーブルの前記エントリにおいて前記一意の識別子を特定することと、
を含む、請求項１４に記載のコンピュータ実行方法。

【請求項16】

第１のエンティティに関する第１のタイプの第１のタイプ固有情報を永続的ストレージに書き込むための第１のリクエストを受信することであり、前記永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、前記親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、前記タイプがそれぞれ、前記１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、前記１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、前記タイプのうちの１つまたは複数と関連付けられている、ことと、
前記親テーブルの第１のエントリにおいて、前記第１のタイプが前記クラスフィールドにおいて指定されているものと判定することと、
前記第１のタイプ固有情報を前記１つまたは複数の子テーブルのうちの特定の子テーブルに書き込むことであり、前記特定の子テーブルが、前記第１のタイプと関連付けられている、ことと、
第２のエンティティに関する第２のタイプの第２のタイプ固有情報を前記永続的ストレージに書き込むための第２のリクエストを受信することと、
前記第２のエンティティに関する前記親テーブルの第２のエントリにおいて、前記第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記第２のタイプ固有情報を前記親テーブルの前記第２のエントリにおける一組の付加的なフィールドに書き込むことであり、前記一組の付加的なフィールドが、前記特定のタイプ固有フィルタフィールドと関連付けられている、ことと、
を含む、コンピュータ実行方法。

【請求項17】

前記第１のエンティティに関する前記第２のタイプの第３のタイプ固有情報を前記永続的ストレージに書き込むための第３のリクエストを受信することと、
前記親テーブルの前記第１のエントリにおいて、前記特定のタイプ固有フィルタフィールドにより、前記第２のタイプが存在するものとして示されるものと判定することと、
前記第３のタイプ固有情報を前記親テーブルの前記第１のエントリにおける前記一組の付加的なフィールドに書き込むことと、
をさらに含む、請求項１６に記載のコンピュータ実行方法。

【請求項18】

前記第１のエンティティに関して前記親テーブルを検索することと、
前記第１のエントリが前記第１のエンティティと関連付けられているものと判定することと、
をさらに含む、請求項１６に記載のコンピュータ実行方法。

【請求項19】

前記第１のタイプ固有情報を書き込むことが、前記第１のタイプ固有情報を、前記第１のエンティティと関連付けられている前記特定の子テーブルのエントリのフィールドに書き込むことを含む、請求項１６に記載のコンピュータ実行方法。

【請求項20】

前記第１のエンティティが、一意の識別子と関連付けられており、前記親テーブルの前記第１のエントリが、前記一意の識別子を含み、前記特定の子テーブルの前記エントリが、前記一意の識別子を含み、前記第１のタイプ固有情報を書き込むことが、
前記一意の識別子に関して前記特定の子テーブルのエントリを検索することと、
前記特定の子テーブルの前記エントリにおいて前記一意の識別子を特定することと、
を含む、請求項１９に記載のコンピュータ実行方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０２１年８月９日に出願された米国特許出願第１７／３９７，４８０号の優先権を主張するものであり、そのすべての内容を本明細書に援用する。

【背景技術】

【0002】

リモートネットワーク管理プラットフォームまたは別の形態のクラウドベースのプラットフォームに格納されているデータオブジェクトに関する従来の構成は、これらデータオブジェクトのタイプによる。特に、プラットフォームへのログインならびに／または他のアクセスもしくは使用を許可されたユーザのユーザＩＤは、タイプ（たとえば、顧客、ベンダー、または市民）に分類される。このようなユーザＩＤはデータベーステーブルにおいて表され、各タイプのユーザについて、少なくとも一部のデータが当該タイプ専用のテーブルにおいて表され得る。

【0003】

これらの環境においては、ユーザのタイプの利用によって、特定のデータへのアクセスもしくは特定のアプリケーションの使用の許可、ユーザがログインした場合にグラフィカルユーザインターフェース上でユーザに提示される情報等、プラットフォームによりユーザがアクセスし得る能力および機能を決定することができる。さらに、プラットフォーム上の標準およびカスタムのソフトウェアアプリケーションは、このようなテーブルのフォーマットおよび各ユーザがシングルタイプであるという概念に基づいて記述され得る。このため、シングルタイプユーザがプラットフォームの基本的側面と考えられる。

【0004】

この点、複数タイプのユーザをサポートするため、プラットフォームは、当該ユーザに対して異なるユーザＩＤ（各タイプに１つ）を設定可能であるが、これでは、ユーザ当たりのレコードが追加となって記憶容量が浪費されるため、非効率である。また、マルチタイプユーザがすべての能力にアクセスするには、複数のパスワードを記憶して、これらのユーザＩＤを切り替える必要もある。

【発明の概要】

【0005】

本明細書に記載の実施態様は、マルチタイプユーザに対して後方互換性のあるサポートを提供することにより、この従来の設計の制限を（および、場合により他の制限も）克服する。特に、これらの実施態様によれば、少なくとも一部の既存のソフトウェアアプリケーションがシングルタイプユーザを前提として動作を継続可能となる一方、他のソフトウェアアプリケーションは、マルチタイプユーザをサポート可能となる。これは、専用テーブルのほか、親ユーザテーブルに格納されているメタデータにおけるユーザタイプの定義を同時にサポートすることによって達成される。結果として、リモートネットワーク管理プラットフォーム（または、他種のプラットフォーム）は、記憶容量を節約するとともに、より直感的かつユーザ負担の少ないユーザ体験を提供する。

【0006】

したがって、第１の例示的な実施形態は、第１のエンティティに関する第１のタイプの第１のタイプ固有情報（ｔｙｐｅ－ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）を永続的ストレージから読み出すための第１のリクエストを受信することであり、永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、タイプがそれぞれ、１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、タイプのうちの１つまたは複数と関連付けられている、ことを含んでいてもよい。また、第１の例示的な実施形態は、第１のエンティティに関する親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することを含んでいてもよい。また、第１の例示的な実施形態は、１つまたは複数の子テーブルのうちの特定の子テーブルから、第１のタイプ固有情報を取得することであり、特定の子テーブルが、第１のタイプと関連付けられている、ことを含んでいてもよい。また、第１の例示的な実施形態は、第１のリクエストに応答して、第１のタイプ固有情報を提供することを含んでいてもよい。また、第１の例示的な実施形態は、第２のエンティティに関する第２のタイプの第２のタイプ固有情報を永続的ストレージから読み出すための第２のリクエストを受信することを含んでいてもよい。また、第１の例示的な実施形態は、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールド（ｔｙｐｅ－ｓｐｅｃｉｆｉｃ ｆｉｌｔｅｒ ｆｉｅｌｄ）により、第２のタイプが存在するものとして示されるものと判定することを含んでいてもよい。また、第１の例示的な実施形態は、親テーブルの第２のエントリにおける一組の付加的なフィールドから、第２のタイプ固有情報を取得することであり、一組の付加的なフィールドが、特定のタイプ固有フィルタフィールドと関連付けられている、ことを含んでいてもよい。また、第１の例示的な実施形態は、第２のリクエストに応答して、第２のタイプ固有情報を提供することを含んでいてもよい。

【0007】

第２の例示的な実施形態は、第１のエンティティに関する第１のタイプの第１のタイプ固有情報を永続的ストレージに書き込むための第１のリクエストを受信することであり、永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、タイプがそれぞれ、１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、タイプのうちの１つまたは複数と関連付けられている、ことを含んでいてもよい。また、第２の例示的な実施形態は、親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することを含んでいてもよい。また、第２の例示的な実施形態は、第１のタイプ固有情報を１つまたは複数の子テーブルのうちの特定の子テーブルに書き込むことであり、特定の子テーブルが、第１のタイプと関連付けられている、ことを含んでいてもよい。また、第２の例示的な実施形態は、第２のエンティティに関する第２のタイプの第２のタイプ固有情報を永続的ストレージに書き込むための第２のリクエストを受信することを含んでいてもよい。また、第２の例示的な実施形態は、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することを含んでいてもよい。また、第２の例示的な実施形態は、第２のタイプ固有情報を親テーブルの第２のエントリにおける一組の付加的なフィールドに書き込むことであり、一組の付加的なフィールドが、特定のタイプ固有フィルタフィールドと関連付けられている、ことを含んでいてもよい。

【0008】

第３の例示的な実施形態において、製造品は、コンピューティングシステムによる実行によって、第１および／または第２の例示的な実施形態に記載の動作をコンピューティングシステムに実行させるプログラム命令が格納された非一時的コンピュータ可読媒体を含んでいてもよい。

【0009】

第４の例示的な実施形態において、コンピューティングシステムは、少なくとも１つのプロセッサのほか、メモリおよびプログラム命令を備えていてもよい。プログラム命令は、メモリに格納され、少なくとも１つのプロセッサによる実行の際に、第１および／または第２の例示的な実施形態に記載の動作をコンピューティングシステムに実行させるようにしてもよい。

【0010】

第５の例示的な実施形態において、システムは、第１および／または第２の例示的な実施形態の動作それぞれを実行するためのさまざまな手段を備えていてもよい。

【0011】

当業者には、必要に応じて添付の図面を参照しつつ、以下の詳細な説明を読むことにより、上記および他の実施形態、態様、利点、および代替案が明らかとなるであろう。さらに、本概要ならびに本明細書に記載の他の説明および図面は、一例として実施形態を示す意図しかないため、多くの変形例が可能である。たとえば、構造要素およびプロセスステップについて、特許請求の範囲のような実施形態の範囲内に維持しつつ、再配置、結合、分配、除去、あるいは変更を加えることができる。

【図面の簡単な説明】

【0012】

【図1】例示的な実施形態に係る、コンピュータ機器の模式図である。

【図2】例示的な実施形態に係る、サーバ機器クラスタの模式図である。

【図3】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを示した図である。

【図4】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む通信環境を示した図である。

【図5A】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む別の通信環境を示した図である。

【図5B】例示的な実施形態に係る、フローチャートである。

【図6】例示的な実施形態に係る、データベーススキーマを示した図である。

【図7】例示的な実施形態に係る、別のデータベーススキーマを示した図である。

【図8】例示的な実施形態に係る、さらに別のデータベーススキーマを示した図である。

【図9A】例示的な実施形態に係る、データベースから読み出すプロセスを示した図である。

【図9B】例示的な実施形態に係る、データベースに書き込むプロセスを示した図である。

【図10A】例示的な実施形態に係る、フローチャートである。

【図10B】例示的な実施形態に係る、フローチャートである。

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

【0013】

本明細書には、例示的な方法、機器、およびシステムを記載している。本明細書において、単語「例（ｅｘａｍｐｌｅ）」および「例示的（ｅｘｅｍｐｌａｒｙ）」は、「一例、事例、または実例として機能する」ことを意味するものとして使用していることが了解されるものとする。「例」または「例示的」として本明細書に記載の任意の実施形態または特徴は、その旨の記載のない限り、他の実施形態または特徴よりも好適または有利であるとは必ずしも解釈されない。このため、本明細書に提示の主題の範囲から逸脱することなく、他の実施形態を利用可能であるとともに、他の変更を加えることができる。

【0014】

したがって、本明細書に記載の例示的な実施形態は、何ら限定を意味するものではない。本明細書の全体に記載するとともに図面に示すような本開示の態様は、多種多様な異なる構成での配置、置換、結合、分離、および設計が可能であることが容易に了解される。たとえば、「クライアント」および「サーバ」コンポーネントへの機能の分離は、多くの方法で実行可能である。

【0015】

さらに、文脈上の別段の示唆のない限り、図面それぞれに示す特徴は、相互に組み合わせて使用可能である。このため、図面は一般的に、１つまたは複数の全体的な実施形態の構成要素の態様として捉えるべきであり、図示の特徴のすべてが各実施形態に必要であるとは限らないことが了解される。

【0016】

また、本明細書または特許請求の範囲における要素、ブロック、またはステップの如何なる列挙も、明瞭化を目的としたものである。したがって、このような列挙は、これらの要素、ブロック、またはステップの特定の配置の順守または特定の順序での実行の要求または暗示を行うものと解釈すべきではない。

【0017】

Ｉ．導入
大企業は、相互に関連する多くの業務を抱える複雑なエンティティである。これらの中には、人事（ＨＲ）、サプライチェーン、情報技術（ＩＴ）、および財務等、企業の各所で見られるものもある。ただし、各企業は、必要不可欠な能力の提供および／または競争優位性の構築につながるそれ自体の一意の業務も有する。

【0018】

幅広く実施される業務をサポートするため、企業は通常、顧客関係管理（ＣＲＭ）および人材管理（ＨＣＭ）パッケージ等、既製のソフトウェアアプリケーションを使用する。ただし、企業自体の一意の要件を満たすには、カスタムのソフトウェアアプリケーションも必要となる場合がある。大企業では、これらのカスタムソフトウェアアプリケーションを何十または何百と有することが多い。これに対して、本明細書の実施形態が提供する利点は、大企業に限定されず、あらゆる規模の企業または他種の組織に適用可能と考えられる。

【0019】

このような多くのソフトウェアアプリケーションは、企業内の個々の部門により開発される。これらは、単純なスプレッドシートから、特注のソフトウェアツールおよびデータベースにまで及ぶ。ただし、他部門との連携のないカスタムソフトウェアアプリケーションの普及には多くの欠点がある。これは、企業による業務の運営および成長の能力、技術革新、ならびに規制要件への対応に悪影響を及ぼす。企業は、そのサブシステムおよびデータを統合する単一のシステムがないことから、業務の統合、合理化、および強化を困難と感じる場合がある。

【0020】

カスタムアプリケーションを効率的に生成するため、企業は、不要な開発の複雑さを排除するリモートホスト型のアプリケーションプラットフォームから恩恵を受けることになる。このようなプラットフォームの目標は、時間を要する繰り返しのアプリケーション開発タスクを減らして、ソフトウェアエンジニアおよび他の任務の個人が価値の高い一意の機能の開発に専念できるようにすることである。

【0021】

この目標を達成するため、ａＰａａＳ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）の概念の導入によって、企業全体のワークフローを知的に自動化する。ａＰａａＳシステムは、企業からリモートでホストされるが、セキュアな接続によって、企業内のデータ、アプリケーション、およびサービスにアクセス可能である。このようなａＰａａＳ一ステムには、多くの有利な機能および特性がある。これらの利点および特性によって、ＩＴ、ＨＲ、ＣＲＭ、顧客サービス、アプリケーション開発、およびセキュリティに関して、企業の業務およびワークフローを改善可能と考えられる。

【0022】

ａＰａａＳシステムは、モデル・ビュー・コントローラ（ＭＶＣ）アプリケーションの開発および実行をサポートし得る。ＭＶＣアプリケーションは、それぞれの機能を３つの相互接続部（モデル、ビュー、およびコントローラ）に分割して、情報がユーザに提示される様態から情報の表現を分離することにより、効率的なコードの再利用および並行開発を可能にする。これらのアプリケーションは、ウェブベースで、作成、読み取り、更新、および削除（ＣＲＵＤ）の機能を提供し得る。これにより、共通のアプリケーションインフラ上で新たなアプリケーションを構築可能となる。

【0023】

ａＰａａＳシステムは、グラフィカルユーザインターフェース（ＧＵＩ）開発のための標準化された一組のウィジェット等、標準化されたアプリケーションコンポーネントをサポートし得る。このように、ａＰａａＳシステムを用いて構築されたアプリケーションは、外観および雰囲気が共通する。他のソフトウェアコンポーネントおよびモジュールについても同様に、標準化されていてもよい。場合によっては、企業のカスタムロゴおよび／または配色によって、この外観および雰囲気をブランディングまたはスキニングすることも可能である。

【0024】

ａＰａａＳシステムは、メタデータを使用してアプリケーションの動作を設定する機能をサポートし得る。これによって、特定のニーズを満たすように、アプリケーションの動作を素早く適応させることができる。このような手法によって、開発時間が短縮されるとともに柔軟性が増す。さらに、ａＰａａＳシステムは、メタデータの作成および管理を容易化してメタデータのエラーを抑えるＧＵＩツールをサポートし得る。

【0025】

ａＰａａＳシステムは、アプリケーション間の明確に規定されたインターフェースをサポートし得るため、ソフトウェア開発者が不要なアプリケーション間依存関係を回避することができる。このため、ａＰａａＳシステムは、永続的な状態情報等のデータが格納されるサービス層を実装することができる。

【0026】

ａＰａａＳシステムが豊富な一組の統合機能をサポートし得るため、システム上のアプリケーションは、レガシーアプリケーションおよびサードパーティアプリケーションと相互作用可能である。たとえば、ａＰａａＳシステムは、レガシーＨＲ、ＩＴ、および会計システムと統合されるカスタム従業員研修システムをサポートし得る。

【0027】

ａＰａａＳシステムは、企業レベルのセキュリティをサポートし得る。さらに、ａＰａａＳシステムは、リモートでホストされ得ることから、企業のシステムまたは企業の外側でホストされたサードパーティネットワークおよびサービスと相互作用する場合に、セキュリティ手順も利用すべきである。たとえば、ａＰａａＳシステムは、企業等の当事者間でデータを共有することにより、共通のセキュリティ脅威を検出および識別するように構成されていてもよい。

【0028】

また、ａＰａａＳシステムの他の特徴、昨日、および利点も存在し得る。この説明は、例示を目的としており、何ら限定の意図はない。

【0029】

ａＰａａＳ開発プロセスの一例として、ソフトウェア開発者は、ａＰａａＳシステムを使用して新たなアプリケーションを作成するように命じられる場合がある。開発者は最初に、アプリケーションが使用するデータの種類およびそれぞれの間の関係を指定するデータモデルを規定し得る。開発者はその後、ａＰａａＳシステムのＧＵＩを介して、データモデルを入力する（たとえば、アップロードする）。ａＰａａＳシステムは、対応するデータベーステーブル、フィールド、および関係をすべて自動的に作成するが、これらには、オブジェクト指向サービス層を介してアクセス可能となる。

【0030】

また、ａＰａａＳシステムは、クライアント側のインターフェースおよびサーバ側のＣＲＵＤロジックを伴う完全に機能的なＭＶＣアプリケーションを構築可能である。この生成アプリケーションは、ユーザの別途開発の基礎として機能し得る。開発者は、アプリケーションの基本機能に多くの時間を費やす必要がないため都合が良い。さらに、アプリケーションは、ウェブベースであってもよいため、任意のインターネット対応クライアント機器からアクセス可能である。この代替または追加として、たとえばインターネットサービスが利用可能ではない場合に、アプリケーションのローカルコピーへのアクセスが可能となっていてもよい。

【0031】

また、ａＰａａＳシステムは、アプリケーションに追加できる豊富な一組の所定の機能をサポートし得る。これらの機能には、検索、電子メール、テンプレート、ワークフロー設計、レポート、分析、ソーシャルメディア、スクリプト記述、モバイル向けの出力、およびカスタマイズＧＵＩのサポートを含む。

【0032】

このようなａＰａａＳシステムは、さまざまな方法でＧＵＩを表し得る。たとえば、ａＰａａＳシステムのサーバ機器は、ＨＴＭＬおよびＪＡＶＡＳＣＲＩＰＴ（登録商標）の組み合わせを使用してＧＵＩの表現を生成するようにしてもよい。ＪＡＶＡＳＣＲＩＰＴ（登録商標）は、クライアント側の実行可能コード、サーバ側の実行可能コード、または両者を含み得る。サーバ機器がこの表現をクライアント機器に送信あるいは提供することにより、ローカルに規定された外観および雰囲気に従って、クライアント機器が画面に表示するようにしてもよい。あるいは、ＧＵＩの表現は、クライアント機器がグラフィック出力を直接生成するのに使用可能な中間形態（たとえば、ＪＡＶＡ（登録商標）バイトコード）等、他の形態であってもよい。それ以外の可能性もある。

【0033】

さらに、ボタン、メニュー、タブ、スライダ、チェックボックス、トグル等のＧＵＩ要素とのユーザ相互作用をそれぞれの「選択」、「起動」、または「作動」と称する場合もある。これらの用語は、ＧＵＩ要素との相互作用がキーボードによるか、ポインティングデバイスによるか、タッチスクリーンによるか、または別の機構によるかに関わらず使用され得る。

【0034】

ａＰａａＳアーキテクチャは、企業のネットワークと統合され、このようなネットワークの管理に用いられる場合に特に効果を発揮する。以下の実施形態では、例示的なａＰａａＳシステムのアーキテクチャおよび機能的態様のほか、それぞれの特徴および利点を説明する。

【0035】

ＩＩ．例示的なコンピュータ機器およびクラウドベースのコンピュータ環境
図１は、コンピュータ機器１００を例示する簡易ブロック図であって、コンピュータ機器に含まれ、本明細書の実施形態に従って動作するように構成された構成要素の一部を示している。コンピュータ機器１００としては、クライアント機器（たとえば、ユーザが能動的に操作する機器）も可能であるし、サーバ機器（たとえば、演算サービスをクライアント機器に提供する機器）も可能であるし、その他何らかの種類の演算プラットフォームも可能である。サーバ機器の中には、特定の操作を実行するために時折クライアント機器として動作するものがあり、クライアント機器の中には、サーバ機能を組み込んだものがある。

【0036】

本例において、コンピュータ機器１００は、プロセッサ１０２、メモリ１０４、ネットワークインターフェース１０６、および入力／出力ユニット１０８を具備しており、これらがすべて、システムバス１１０または類似の機構により結合されていてもよい。いくつかの実施形態において、コンピュータ機器１００は、他の構成要素および／または周辺機器（たとえば、取り外し可能なストレージ、プリンタ等）を具備していてもよい。

【0037】

プロセッサ１０２は、中央演算処理装置（ＣＰＵ）、コプロセッサ（たとえば、数学、グラフィックス、または暗号化コプロセッサ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、ならびに／またはプロセッサ動作を実行する集積回路もしくはコントローラの形態等、任意の種類のコンピュータ処理要素のうちの１つまたは複数であってもよい。場合により、プロセッサ１０２は、１つまたは複数のシングルコアプロセッサであってもよい。他の場合に、プロセッサ１０２は、複数の独立した処理ユニットを伴う１つまたは複数のマルチコアプロセッサであってもよい。また、プロセッサ１０２には、実行対象の命令および関連データを一時的に格納するためのレジスタメモリのほか、最近使用された命令およびデータを一時的に格納するためのキャッシュメモリを含み得る。

【0038】

メモリ１０４は、如何なる形態のコンピュータ使用可能メモリであってもよく、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ならびに不揮発性メモリ（たとえば、フラッシュメモリ、ハードディスクドライブ、半導体ドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、および／もしくはテープストレージ）が挙げられるが、これらに限定されない。このため、メモリ１０４は、メインメモリユニットおよび長期ストレージの両者を表す。他種のメモリとしては、生物学的メモリが挙げられる。

【0039】

メモリ１０４は、プログラム命令および／またはプログラム命令が動作し得るデータを格納していてもよい。一例として、メモリ１０４は、プロセッサ１０２による実行によって、本明細書または添付の図面に開示の方法、プロセス、または動作のいずれかを実行可能となるように、これらのプログラム命令非一時的コンピュータ可読媒体に格納するようにしてもよい。

【0040】

図１に示すように、メモリ１０４は、ファームウェア１０４Ａ、カーネル１０４Ｂ、および／またはアプリケーション１０４Ｃを含んでいてもよい。ファームウェア１０４Ａは、コンピュータ機器１００の一部または全部の起動あるいは開始に用いられるプログラムコードであってもよい。カーネル１０４Ｂは、メモリ管理、プロセッサのスケジューリングおよび管理、入力／出力、ならびに通信のためのモジュールを含むオペレーティングシステムであってもよい。また、カーネル１０４Ｂは、オペレーティングシステムによるコンピュータ機器１００のハードウェアモジュール（たとえば、メモリユニット、ネットワークインターフェース、ポート、およびバス）との通信を可能にするデバイスドライバを含んでいてもよい。アプリケーション１０４Ｃは、ウェブブラウザまたは電子メールクライアント等の１つまたは複数のユーザ空間ソフトウェアプログラムのほか、これらのプログラムで使用される任意のソフトウェアライブラリであってもよい。また、メモリ１０４は、上記および他のプログラムおよびアプリケーションで使用されるデータを格納するようにしてもよい。

【0041】

ネットワークインターフェース１０６は、イーサネット（たとえば、ファーストイーサネット、ギガビットイーサネット）等の１つまたは複数の有線インターフェースの形態であってもよい。また、ネットワークインターフェース１０６は、同軸ケーブルもしくは電力線等の１つもしくは複数の非イーサネット媒体または同期光ネットワーキング（ＳＯＮＥＴ）もしくはデジタル加入者線（ＤＳＬ）技術等の広域媒体を介した通信をサポートし得る。また、ネットワークインターフェース１０６は、ＩＥＥＥ ８０２．１１（Ｗｉｆｉ）、ＢＬＵＥＴＯＯＴＨ（登録商標）、全地球測位システム（ＧＰＳ）、または広域無線インターフェース等の１つまたは複数の無線インターフェースの形態であってもよい。ただし、他の形態の物理層インターフェースならびに他種の標準もしくは専用通信プロトコルがネットワークインターフェース１０６を介して用いられるようになっていてもよい。さらに、ネットワークインターフェース１０６には、複数の物理インターフェースを含み得る。たとえば、コンピュータ機器１００のいくつかの実施形態には、イーサネット、ＢＬＵＥＴＯＯＴＨ（登録商標）、およびＷｉｆｉインターフェースを含み得る。

【0042】

入力／出力ユニット１０８は、ユーザおよび周辺機器のコンピュータ機器１００との相互作用を容易化し得る。入力／出力ユニット１０８には、１つまたは複数の種類の入力装置（キーボード、マウス、タッチスクリーン等）を含み得る。同様に、入力／出力ユニット１０８には、１つまたは複数の種類の出力装置（画面、モニタ、プリンタ、ならびに／または１つもしくは複数の発光ダイオード（ＬＥＤ）等）を含み得る。この追加または代替として、コンピュータ機器１００は、たとえばユニバーサルシリアルバス（ＵＳＢ）または高精細マルチメディアインターフェース（ＨＤＭＩ）ポートインターフェースを使用することにより他の機器と通信することができる。

【0043】

いくつかの実施形態においては、コンピュータ機器１００等の１つまたは複数のコンピュータ機器の展開によって、ａＰａａＳアーキテクチャをサポートしていてもよい。これらのコンピュータ機器の厳密な物理的位置、接続性、および設定は、クライアント機器に既知および／または重要ではない場合もある。したがって、コンピュータ機器は、さまざまなリモートデータセンタの場所で収容し得る「クラウドベース」機器と称する場合もある。

【0044】

図２は、例示的な実施形態に係る、クラウドベースのサーバクラスタ２００を示している。図２においては、コンピュータ機器（たとえば、コンピュータ機器１００）の動作がサーバ機器２０２、データストレージ２０４、およびルータ２０６間に分散していてもよく、これらがすべて、ローカルクラスタネットワーク２０８により接続されていてもよい。サーバクラスタ２００におけるサーバ機器２０２、データストレージ２０４、およびルータ２０６の数は、サーバクラスタ２００に割り当てられた演算タスクおよび／またはアプリケーションによって決まり得る。

【0045】

たとえば、サーバ機器２０２は、コンピュータ機器１００のさまざまな演算タスクを実行するように構成可能である。このため、１つまたは複数のサーバ機器２０２に演算タスクを分配可能である。これらの演算タスクを並列実行可能な限りにおいて、このようなタスクの分配により、これらのタスクを完了して結果を返すまでの合計時間が短縮され得る。簡素化のため、サーバクラスタ２００および個々のサーバ機器２０２の両者を「サーバ機器」と称する場合もある。この命名は、１つまたは複数の異なるサーバ機器、データ記憶装置、およびクラスタルータがサーバ機器の動作に関与し得ることの暗示として了解されるものとする。

【0046】

データストレージ２０４は、複数群のハードディスクドライブおよび／または半導体ドライブに対する読み書きアクセスを管理するように構成されたドライブアレイコントローラを含むデータストレージアレイであってもよい。また、ドライブアレイコントローラは、１つまたは複数のサーバ機器２０２がデータストレージ２０４のユニットにアクセスできなくなるドライブ故障または他種の故障に対する保護のため、単独またはサーバ機器２０２と併せて、データストレージ２０４に格納されたデータのバックアップまたは冗長コピーを管理するように構成されていてもよい。ドライブ以外の他種のメモリが用いられるようになっていてもよい。

【0047】

ルータ２０６は、内部および外部通信をサーバクラスタ２００に提供するように構成されたネットワーク設備を含み得る。たとえば、ルータ２０６には、（ｉ）ローカルクラスタネットワーク２０８を介したサーバ機器２０２とデータストレージ２０４との間のネットワーク通信、および／または、（ｉｉ）ネットワーク２１２への通信リンク２１０を介したサーバクラスタ２００と他の機器との間のネットワーク通信を提供するように構成された１つまたは複数のパケットスイッチングおよび／またはルーティング機器（スイッチおよび／またはゲートウェイを含む）を含み得る。

【0048】

また、ルータ２０６の構成は、サーバ機器２０２およびデータストレージ２０４のデータ通信要件、ローカルクラスタネットワーク２０８のレイテンシおよびスループット、通信リンク２１０のレイテンシ、スループット、およびコスト、ならびに／またはシステムアーキテクチャのコスト、速度、耐障害性、回復力、効率、および／もしくは他の設計目標に寄与し得る他の要因に少なくとも部分的に基づき得る。

【0049】

考え得る一例として、データストレージ２０４には、構造化照会言語（ＳＱＬ）データベース等の任意の形態のデータベースを含み得る。このようなデータベースにおいては、さまざまな種類のデータ構造が情報を格納可能であり、テーブル、アレイ、リスト、ツリー、およびタプルが挙げられるが、これらに限定されない。さらに、データストレージ２０４の任意のデータベースがモノリシックであってもよいし、複数の物理的機器に分散していてもよい。

【0050】

サーバ機器２０２は、データストレージ２０４へのデータの送信および／またはデータストレージ２０４からのデータの受信を行うように構成されていてもよい。この送信および読み出しはそれぞれ、ＳＱＬクエリもしくは他種のデータベースクエリの形態ならびにこのようなクエリの出力の形態であってもよい。同様に、テキスト、イメージ、ビデオ、および／またはオーディオが追加で含まれていてもよい。さらに、サーバ機器２０２は、受信データをウェブページまたはウェブアプリケーションの表現として編成するようにしてもよい。このような表現は、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）等のマークアップ言語、または他の何らかの標準化フォーマットもしくは専用フォーマットの形態であってもよい。さらに、サーバ機器２０２は、さまざまな種類のコンピュータ化スクリプト言語を実行可能であってもよく、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰ Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）等が挙げられるが、これらに限定されない。これらの言語で書かれたコンピュータプログラムコードは、クライアント機器へのウェブページの提供のほか、クライアント機器のウェブページとの相互作用を容易化し得る。この代替または追加として、ウェブページの生成の容易化および／またはウェブアプリケーション機能の提供のため、ＪＡＶＡ（登録商標）が用いられるようになっていてもよい。

【0051】

ＩＩＩ．例示的なリモートネットワーク管理アーキテクチャ
図３は、例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを示している。このアーキテクチャには、マネージドネットワーク３００、リモートネットワーク管理プラットフォーム３２０、およびパブリッククラウドネットワーク３４０という３つの主要な構成要素を含み、すべてがインターネット３５０により接続されている。

【0052】

Ａ．マネージドネットワーク
マネージドネットワーク３００は、たとえば演算および通信タスクのほか、データのストレージのためのエンティティが使用する企業ネットワークであってもよい。このため、マネージドネットワーク３００は、クライアント機器３０２、サーバ機器３０４、ルータ３０６、仮想マシン３０８、ファイアウォール３１０、および／またはプロキシサーバ３１２を具備していてもよい。クライアント機器３０２は、コンピュータ機器１００により具現化されていてもよく、サーバ機器３０４は、コンピュータ機器１００またはサーバクラスタ２００により具現化されていてもよく、ルータ３０６は、如何なる種類のルータ、スイッチ、またはゲートウェイであってもよい。

【0053】

仮想マシン３０８は、コンピュータ機器１００およびサーバクラスタ２００のうちの１つまたは複数により具現化されていてもよい。一般的に、仮想マシンは、コンピューティングシステムのエミュレーションであり、物理的なコンピュータの機能（たとえば、プロセッサ、メモリ、および通信リソース）を模倣する。サーバクラスタ２００等の１つの物理的なコンピューティングシステムが最大で数千もの個々の仮想マシンをサポート可能である。いくつかの実施形態において、仮想マシン３０８は、個々の仮想マシンに対する物理的な演算リソースの割り当てのほか、性能およびエラー報告を容易化する集中サーバ機器またはアプリケーションにより管理されるようになっていてもよい。企業は、仮想マシンを採用することにより、必要に応じて演算リソースを効率的に割り当てることが多い。仮想化コンピューティングシステムのプロバイダには、ＶＭＷＡＲＥ（登録商標）およびＭＩＣＲＯＳＯＦＴ（登録商標）を含む。

【0054】

ファイアウォール３１０は、マネージドネットワーク３００を起点とする正規の通信を許可しつつ、内部の機器、アプリケーション、およびサービスへの不正なアクセス試行からマネージドネットワーク３００を保護する１つまたは複数の専用ルータまたはサーバ機器であってもよい。また、ファイアウォール３１０は、侵入検出、ウェブフィルタリング、ウイルススキャン、アプリケーション層ゲートウェイ、ならびに他のアプリケーションもしくはサービスを提供し得る。図３には示していないいくつかの実施形態において、マネージドネットワーク３００は、リモートネットワーク管理プラットフォーム３２０（以下参照）と通信するための１つまたは複数の仮想プライベートネットワーク（ＶＰＮ）ゲートウェイを具備していてもよい。

【0055】

また、マネージドネットワーク３００は、１つまたは複数プロキシサーバ３１２を具備していてもよい。プロキシサーバ３１２の一実施形態は、マネージドネットワーク３００、リモートネットワーク管理プラットフォーム３２０、およびパブリッククラウドネットワーク３４０間のデータの通信および移動を容易化するサーバアプリケーションであってもよい。特に、プロキシサーバ３１２は、リモートネットワーク管理プラットフォーム３２０の１つまたは複数の演算インスタンスとのセキュアな通信セッションを構築および維持可能であってもよい。このようなセッションにより、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００およびその構成要素のアーキテクチャおよび設定の態様を検出および管理可能となり得る。場合によっては、プロキシサーバ３１２の補助により、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００が使用するパブリッククラウドネットワーク３４０の態様を検出および管理することも可能となり得る。

【0056】

ファイアウォール３１０等のファイアウォールは通常、上記のようなセッションが最終的にファイアウォールの背後（すなわち、マネージドネットワーク３００上の機器）を起点とするわけでもなく、当該ファイアウォールがセッションをサポートするように明示的に構成されているわけでもない限り、インターネット３５０を経由して着信するすべての通信セッションを拒否する。プロキシサーバ３１２をファイアウォール３１０の背後に配置することにより（たとえば、マネージドネットワーク３００内に配置してファイアウォール３１０で保護することにより）、ファイアウォール３１０を通じて、プロキシサーバ３１２がこれらの通信セッションを開始可能となり得る。これにより、ファイアウォール３１０は、リモートネットワーク管理プラットフォーム３２０からの着信セッションをサポートするように特別な構成とする必要がなくなる可能性もあるため、マネージドネットワーク３００に対する潜在的なセキュリティリスクを回避することができる。

【0057】

場合により、マネージドネットワーク３００は、少数の機器および少数のネットワークから成っていてもよい。他の展開において、マネージドネットワーク３００は、複数の物理的な場所におよび、数百のネットワークおよび数十万の機器を含んでいてもよい。このため、図３に示すアーキテクチャは、桁違いの規模の拡大または縮小が可能である。

【0058】

さらに、マネージドネットワーク３００のサイズ、アーキテクチャ、および接続性に応じて、内部に展開するプロキシサーバ３１２の数を変えることができる。たとえば、プロキシサーバ３１２はそれぞれ、マネージドネットワーク３００の一部に関してリモートネットワーク管理プラットフォーム３２０との通信を担うようにしてもよい。この代替または追加として、このようなマネージドネットワーク３００の部分に対する複数組の２つ以上のプロキシサーバの割り当てによって、負荷分散、冗長性、および／または可用性の向上を図るようにしてもよい。

【0059】

Ｂ．リモートネットワーク管理プラットフォーム
リモートネットワーク管理プラットフォーム３２０は、ユーザ、特に、マネージドネットワーク３００のオペレータにａＰａａＳサービスを提供するホストされた環境である。これらのサービスは、たとえば前述のウェブベースの技術を使用するウェブベースのポータルの形態であってもよい。このため、ユーザは、たとえばクライアント機器３０２または可能性としてマネージドネットワーク３００の外側のクライアント機器から、リモートネットワーク管理プラットフォーム３２０へのセキュアなアクセスが可能である。ウェブベースのポータルにより、ユーザは、アプリケーションの設計、テスト、および展開、レポートの生成、分析の確認、ならびに他のタスクの実行が可能となる。また、リモートネットワーク管理プラットフォーム３２０は、マルチアプリケーションプラットフォームと称する場合もある。

【0060】

図３に示すように、リモートネットワーク管理プラットフォーム３２０は、４つの演算インスタンス３２２、３２４、３２６、および３２８を含む。これらの演算インスタンスはそれぞれ、ａＰａａＳソフトウェアの専用コピーを運用する１つもしくは複数のノードならびに／または１つもしくは複数のデータベースノードを表し得る。物理的なサーバ機器および／または仮想マシン上では、サーバおよびデータベースの柔軟な配置が可能であり、企業のニーズに基づいて変更するようにしてもよい。組み合わせにより、これらのノードは、特定の企業が利用可能な一組のウェブポータル、サービス、およびアプリケーション（たとえば、完全に機能するａＰａａＳシステム）を提供することができる。場合によっては、単一の企業が複数の演算インスタンスを使用するようにしてもよい。

【0061】

たとえば、マネージドネットワーク３００は、リモートネットワーク管理プラットフォーム３２０の企業顧客であってもよく、また、演算インスタンス３２２、３２４、および３２６を使用するようにしてもよい。１つの顧客に複数の演算インスタンスを提供する理由として、顧客は、そのアプリケーションおよびサービスの独立した開発、テスト、および展開を望む場合がある。このため、演算インスタンス３２２がマネージドネットワーク３００と関連するアプリケーション開発専用であってもよく、演算インスタンス３２４がこれらのアプリケーションのテスト専用であってもよく、演算インスタンス３２６がテスト済みアプリケーションおよびサービスのライブ運用専用であってもよい。また、演算インスタンスは、ホストされたインスタンス、リモートインスタンス、顧客インスタンスと称する場合もあるし、他の何らかの呼称となる場合もある。演算インスタンスに展開された如何なるアプリケーションも、演算インスタンス内のデータベースへのアクセスが内部の特定の要素（たとえば、１つもしくは複数の特定のデータベーステーブルまたは１つもしくは複数のデータベーステーブル内の特定の行）に制限され得る点において、スコープアプリケーション（ｓｃｏｐｅｄ Ａｐｐｌｉｃａｔｉｏｎ）と考えられる。

【0062】

簡素化のため、本明細書の開示では、アプリケーションノード、データベースノード、これらの上で実行されるａＰａａＳソフトウェア、および基礎となるハードウェアの構成を「演算インスタンス」と称する。なお、ユーザは口語的に、上記により提供されるグラフィカルユーザインターフェースを「インスタンス」と称する場合がある。ただし、本明細書における別段の定義のない限り、「演算インスタンス」は、リモートネットワーク管理プラットフォーム３２０内に配設されたコンピューティングシステムである。

【0063】

リモートネットワーク管理プラットフォーム３２０のマルチインスタンスアーキテクチャは、従来のマルチテナントアーキテクチャとは対照的に、複数の利点を奏する。マルチテナントアーキテクチャにおいては、異なる顧客（たとえば、企業）からのデータが単一のデータベースにおいて混合される。これらの顧客のデータは相互に分離されているが、この分離は、単一のデータベースを運用するソフトウェアによって強制されている。結果として、このシステムにおけるセキュリティ侵害が顧客のすべてのデータに影響を及ぼし、特に政府、医療、および／または金融の規制を受けるエンティティにとっては、付加的なリスクとなる。さらに、１つの顧客に影響を及ぼす任意のデータベース運用は、当該データベースを共有するすべての顧客に影響を及ぼす可能性がある。このため、ハードウェアまたはソフトウェアのエラーに起因する停止の場合、この停止は、このようなすべての顧客に影響を及ぼす。同様に、データベースは、１つの顧客のニーズを満たすようにアップグレードされる場合、アップグレードプロセスにおいて、すべての顧客が利用不可能となる。このような保守時間枠は、共有データベースのサイズに起因して長くなることが多い。

【0064】

これに対して、マルチインスタンスアーキテクチャは、専用の演算インスタンスにおいて、各顧客にそれ自体のデータベースを提供する。これにより、顧客データの混合が防止され、各インスタンスの独立管理が可能となる。たとえば、ある顧客のインスタンスがエラーまたはアップグレードによって停止となった場合でも、他の演算インスタンスは影響を受けない。データベースに１つの顧客のデータしか含まないため、保守のダウンタイムは限られる。さらに、マルチインスタンスアーキテクチャのより簡素な設計によって、各顧客データベースおよびインスタンスの冗長コピーが地理的に多様に展開され得る。これにより、高い可用性が促進され、障害の検出または保守の実行時に、顧客のインスタンスのライブバージョンを移動可能となる。

【0065】

いくつかの実施形態において、リモートネットワーク管理プラットフォーム３２０は、このプラットフォームを動作させるエンティティにより制御される１つまたは複数の中央インスタンスを含んでいてもよい。演算インスタンスと同様に、中央インスタンスは、いくつかの物理的サーバ機器または仮想マシン上に配設されたいくつかのアプリケーションおよびデータベースノードを含み得る。このような中央インスタンスは、演算インスタンスのほか、演算インスタンスの少なくとも一部で共有され得るデータの特定の構成に対するレポジトリとして機能し得る。たとえば、演算インスタンス上で発生し得る一般的なセキュリティ脅威の定義、演算インスタンス上で一般的に検出されるソフトウェアパッケージ、および／または演算インスタンスに展開可能なアプリケーション用のアプリケーションストアが中央インスタンスに存在していてもよい。演算インスタンスは、このデータを得るために明確に規定されたインターフェースによって、中央インスタンスと通信するようにしてもよい。

【0066】

複数の演算インスタンスを効率的にサポートするため、リモートネットワーク管理プラットフォーム３２０は、複数のこれらインスタンスを単一のハードウェアプラットフォーム上で実行するようにしてもよい。たとえば、ａＰａａＳシステムは、サーバクラスタ２００等のサーバクラスタ上で実行されている場合、さまざまな量の演算、ストレージ、および通信リソースをインスタンスに割り当てる仮想マシンを動作させるようにしてもよい。ただし、サーバクラスタ２００の完全な仮想化は必要とされず、他のメカニズムによって、インスタンスを分離するようにしてもよい。いくつかの例において、各インスタンスは、サーバクラスタ２００上に専用アカウントならびに１つもしくは複数の専用データベースを有していてもよい。あるいは、演算インスタンス３２２等の演算インスタンスが複数の物理的機器に及んでいてもよい。

【0067】

場合によっては、リモートネットワーク管理プラットフォーム３２０の単一のサーバクラスタが複数の独立した企業をサポートし得る。さらに、後述の通り、リモートネットワーク管理プラットフォーム３２０は、負荷分散、冗長性、および／または高い可用性を促進するため、地理的に多様なデータセンタに展開された複数のサーバクラスタを具備していてもよい。

【0068】

Ｃ．パブリッククラウドネットワーク
パブリッククラウドネットワーク３４０は、外部委託演算、データストレージ、通信、およびサービスホスティング業務に使用可能なリモートサーバ機器（たとえば、サーバクラスタ２００等の複数のサーバクラスタ）であってもよい。これらのサーバは、仮想化されていてもよい（すなわち、仮想マシンであってもよい）。パブリッククラウドネットワーク３４０の例としては、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（登録商標）およびＭＩＣＲＯＳＯＦＴ（登録商標） ＡＺＵＲＥ（登録商標）が挙げられる。リモートネットワーク管理プラットフォーム３２０と同様に、負荷分散、冗長性、および／または高い可用性を目的として、パブリッククラウドネットワーク３４０をサポートする複数のサーバクラスタが地理的に多様な場所に展開されていてもよい。

【0069】

マネージドネットワーク３００は、１つまたは複数のパブリッククラウドネットワーク３４０を使用して、アプリケーションおよびサービスをそのクライアントおよび顧客に展開するようにしてもよい。たとえば、マネージドネットワーク３００がオンライン楽曲ストリーミングサービスを提供している場合、パブリッククラウドネットワーク３４０は、楽曲ファイルを格納するとともに、ウェブインターフェースおよびストリーミングの機能を提供するようにしてもよい。このように、マネージドネットワーク３００の企業は、これらの業務に対して、それ自体のサーバを構築および保守する必要がない。

【0070】

リモートネットワーク管理プラットフォーム３２０は、パブリッククラウドネットワーク３４０との統合によって、内部の仮想マシンおよびマネージドサービスをマネージドネットワーク３００に公開するモジュールを具備していてもよい。これらのモジュールによれば、ユーザは、仮想リソースの要求、割り当てられたリソースの検出、およびパブリッククラウドネットワーク３４０への柔軟な報告が可能となり得る。この機能を確立するため、マネージドネットワーク３００のユーザは、最初にパブリッククラウドネットワーク３４０でアカウントを開設し、一組の関連するリソースを要求する可能性もある。その後、ユーザは、アカウント情報をリモートネットワーク管理プラットフォーム３２０の適当なモジュールに入力するようにしてもよい。その後、これらのモジュールが自動的に、アカウントの管理可能なリソースを検出するとともに、使用、性能、および課金と関連するレポートを提供するようにしてもよい。

【0071】

Ｄ．通信サポートおよび他のオペレーション
インターネット３５０は、グローバルなインターネットの一部を表し得る。ただし、インターネット３５０は代替として、プライベートワイドエリアまたはローカルエリアパケット交換ネットワーク等、異なる種類のネットワークを表し得る。

【0072】

図４は、マネージドネットワーク３００と演算インスタンス３２２との間の通信環境をさらに示しており、付加的な特徴および代替実施形態を紹介するものである。図４においては、演算インスタンス３２２の全部または一部がデータセンタ４００Ａおよび４００Ｂの両者で複製されている。これらのデータセンタは、地理的に相互に離れていてもよく、おそらくは異なる都市または異なる国にある。各データセンタは、マネージドネットワーク３００のほか、リモートユーザとの通信を容易化するサポート設備を具備する。

【0073】

データセンタ４００Ａにおいては、外部機器に対するネットワークトラフィックがＶＰＮゲートウェイ４０２Ａまたはファイアウォール４０４Ａを通じて流れる。ＶＰＮゲートウェイ４０２Ａは、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）またはトランスポート層セキュリティ（ＴＬＳ）等のセキュリティプロトコルによって、マネージドネットワーク３００のＶＰＮゲートウェイ４１２とピアリングされていてもよい。ファイアウォール４０４Ａは、ユーザ４１４およびリモートユーザ４１６等の正規のユーザからのアクセスを許可するとともに、不正なユーザのアクセスを拒否するように構成されていてもよい。ファイアウォール４０４Ａによって、これらのユーザは、演算インスタンス３２２および場合により他の演算インスタンスにアクセスすることができる。負荷分散器４０６Ａは、演算インスタンス３２２をホストする１つまたは複数の物理または仮想サーバ機器間でのトラフィックの分配に用いられるようになっていてもよい。負荷分散器４０６Ａは、クライアント機器からデータセンタ４００Ａの内部構成（たとえば、演算インスタンス３２２）を隠すことにより、ユーザアクセスを簡素化することができる。たとえば、複数のデータベースへのアクセスを共有する複数の物理または仮想コンピュータ機器を演算インスタンス３２２が含む場合、負荷分散器４０６Ａは、あるコンピュータ機器またはデータベースがその他よりも著しく忙しい、ということがないように、これらのコンピュータ機器およびデータベース間でネットワークトラフィックおよび処理タスクを分配するようにしてもよい。いくつかの実施形態において、演算インスタンス３２２は、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、および負荷分散器４０６Ａを含んでいてもよい。

【0074】

データセンタ４００Ｂは、データセンタ４００Ａの構成要素に関するそれ自体のバージョンを具備していてもよい。このため、ＶＰＮゲートウェイ４０２Ｂ、ファイアウォール４０４Ｂ、および負荷分散器４０６Ｂがそれぞれ、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、および負荷分散器４０６Ａと同一または同様の動作を実行するようにしてもよい。さらに、リアルタイムまたは準リアルタイムのデータベース複製および／または他の動作によって、演算インスタンス３２２がデータセンタ４００Ａおよび４００Ｂにおいて同時に存在していてもよい。

【0075】

図４に示すようなデータセンタ４００Ａおよび４００Ｂは、冗長性および高い可用性を促進し得る。図４の構成においては、データセンタ４００Ａがアクティブで、データセンタ４００Ｂがパッシブである。このため、データセンタ４００Ａがマネージドネットワーク３００に対するすべてのトラフィックをサーブする一方、データセンタ４００Ｂの演算インスタンス３２２のバージョンは、準リアルタイムに更新される。両データセンタがアクティブである構成等、他の構成がサポートされていてもよい。

【0076】

データセンタ４００Ａが何らかの故障を起こしたり、ユーザが利用できなくなったりした場合は、データセンタ４００Ｂがアクティブなデータセンタとして引き継ぐことができる。たとえば、演算インスタンス３２２のドメイン名をデータセンタ４００Ａの１つまたは複数のインターネットプロトコル（ＩＰ）アドレスと関連付けるドメインネームシステム（ＤＮＳ）サーバは、ドメイン名をデータセンタ４００Ｂの１つまたは複数のＩＰアドレスと再度関連付けるようにしてもよい。この再関連付けが完了した後（１秒または数秒未満と考えられる）、ユーザは、データセンタ４００Ｂによって演算インスタンス３２２にアクセス可能となる。

【0077】

また、図４は、マネージドネットワーク３００の考え得る構成を示している。上述の通り、プロキシサーバ３１２およびユーザ４１４は、ファイアウォール３１０を通じて演算インスタンス３２２にアクセス可能である。また、プロキシサーバ３１２は、設定項目４１０にもアクセス可能である。図４において、設定項目４１０は、クライアント機器３０２、サーバ機器３０４、ルータ３０６、および仮想マシン３０８のいずれかまたはすべて、そこで実行される任意のアプリケーションまたはサービスのほか、機器、アプリケーション、およびサービス間の関係を表し得る。このため、用語「設定項目（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｔｅｍ）」は、任意の物理的もしくは仮想的機器、演算インスタンス３２２によるリモート検出または管理が可能な任意のアプリケーションもしくはサービス、または検出された機器、アプリケーション、およびサービス間の関係を表す略記であってもよい。設定項目は、演算インスタンス３２２の設定管理データベース（ＣＭＤＢ）において表され得る。

【0078】

上述の通り、ＶＰＮゲートウェイ４１２は、専用のＶＰＮをＶＰＮゲートウェイ４０２Ａに提供し得る。このようなＶＰＮは、マネージドネットワーク３００と演算インスタンス３２２との間に大量のトラフィックが存在する場合、あるいは、セキュリティポリシーがこれらのサイト間でのＶＰＮの使用を示唆または要求する場合に役立ち得る。いくつかの実施形態において、ＶＰＮを介して直接通信するマネージドネットワーク３００および／または演算インスタンス３２２の任意の機器には、パブリックＩＰアドレスが割り当てられる。マネージドネットワーク３００および／または演算インスタンス３２２の他の機器には、プライベートＩＰアドレス（たとえば、１０．０．０．０～１０．２５５．２５５．２５５または１９２．１６８．０．０～１９２．１６８．２５５．２５５の範囲から選択されたＩＰアドレスであって、それぞれがサブネット１０．０．０．０／８および１９２．１６８．０．０／１６として略記される）が割り当てられ得る。

【0079】

ＩＶ．例示的な機器、アプリケーション、およびサービス検出
リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００の機器、アプリケーション、およびサービスを管理するため、マネージドネットワーク３００に存在する機器、これらの機器の構成、および動作状態、ならびに機器が提供するアプリケーションおよびサービスのほか、検出された機器、アプリケーション、およびサービス間の関係を最初に決定するようにしてもよい。上述の通り、各機器、アプリケーション、サービス、および関係を設定項目と称する場合がある。マネージドネットワーク３００内の設定項目を規定するプロセスを検出と称するが、これは、プロキシサーバ３１２によって少なくとも部分的に容易化され得る。

【0080】

本明細書の実施形態のため、「アプリケーション」は、１つもしくは複数のプロセス、スレッド、プログラム、クライアントモジュール、サーバモジュール、または機器もしくは機器群上で実行されるその他任意のソフトウェアを表し得る。「サービス」は、相互に連携して作用する１つまたは複数の機器上で実行される複数のアプリケーションが提供する高度な機能を表し得る。たとえば、高度なウェブサービスには、ある機器上で実行され、別の機器上で実行されるデータベースアプリケーションからの情報にアクセスする複数のウェブアプリケーションサーバスレッドを含み得る。

【0081】

図５Ａは、設定項目が検出され得る様子のほか、検出された設定項目と関連する情報が格納され得る様子の論理的な描写である。簡素化のため、リモートネットワーク管理プラットフォーム３２０、パブリッククラウドネットワーク３４０、およびインターネット３５０は示していない。

【0082】

図５Ａにおいては、ＣＭＤＢ５００およびタスクリスト５０２が演算インスタンス３２２に格納されている。演算インスタンス３２２は、検出コマンドをプロキシサーバ３１２に送信するようにしてもよい。これに応答して、プロキシサーバ３１２は、マネージドネットワーク３００中のさまざまな機器、アプリケーション、およびサービスにプローブを送信するようにしてもよい。これらの機器、アプリケーション、およびサービスは、応答をプロキシサーバ３１２に送信するようにしてもよく、プロキシサーバ３１２はその後、検出された設定項目に関する情報を格納のためＣＭＤＢ５００に与えるようにしてもよい。ＣＭＤＢ５００に格納された設定項目は、マネージドネットワーク３００の環境を表す。

【0083】

タスクリスト５０２は、演算インスタンス３２２に代わってプロキシサーバ３１２が実行することになる行為のリストを表す。検出が発生すると、タスクリスト５０２への入力が行われる。プロキシサーバ３１２は、タスクリスト５０２を繰り返し問い合わせ、その中の次のタスクを取得し、タスクリスト５０２が空になるか、または、別の停止条件が達成されるまで、このタスクを実行する。

【0084】

検出を容易化するため、プロキシサーバ３１２には、当該プロキシサーバ３１２により到達可能なマネージドネットワーク３００中の１つまたは複数のサブネットに関する情報が設定されていてもよい。たとえば、プロキシサーバ３１２には、サブネットとしてＩＰアドレス範囲１９２．１６８．０／２４が与えられていてもよい。そして、演算インスタンス３２２は、この情報をＣＭＤＢ５００に格納し、これらのアドレスそれぞれにおけるデバイスの検出のため、タスクをタスクリスト５０２に配置するようにしてもよい。

【0085】

また、図５Ａは、マネージドネットワーク３００中の機器、アプリケーション、およびサービスを設定項目５０４、５０６、５０８、５１０、および５１２として示している。上述の通り、これらの設定項目は、一組の物理および／または仮想機器（たとえば、クライアント機器、サーバ機器、ルータ、または仮想マシン）、これら（たとえば、ウェブサーバ、電子メールサーバ、データベース、またはストレージアレイ）の上で実行されるアプリケーション、その間の関係のほか、複数の個々の設定項目を含むサービスを表す。

【0086】

タスクをタスクリスト５０２に配置することは、プロキシサーバ３１２が検出を開始することのトリガあるいはきっかけとなり得る。この代替または追加として、検出がトリガイベントに基づいて手動または自動でトリガされるようになっていてもよい（たとえば、１日に１回、特定の時間に、検出が自動的に開始となってもよい）。

【0087】

一般的に、検出は、スキャン、分類、識別、および探索という４つの論理的な段階を踏むことができる。検出の各段階には、マネージドネットワーク３００中の１つまたは複数の機器にプロキシサーバ３１２が送信しているさまざまな種類のプローブメッセージを含む。これらのプローブに対する応答がプロキシサーバ３１２により受信および処理されて、それぞれの表現がＣＭＤＢ５００へと送信されるようになっていてもよい。このように、各段階によって、より多くの設定項目が検出され、ＣＭＤＢ５００に格納され得る。

【0088】

スキャン段階において、プロキシサーバ３１２は、オープンな伝送制御プロトコル（ＴＣＰ）および／またはユーザデータグラムプロトコル（ＵＤＰ）ポートについて、ＩＰアドレスの指定された範囲内の各ＩＰアドレスをプローブすることにより、機器の一般的な種類を決定するようにしてもよい。このようなオープンポートがＩＰアドレスに存在することは、当該ＩＰアドレスが割り当てられた機器上で特定のアプリケーションが動作していることを示し、これによって、当該機器が使用するオペレーティングシステムを識別可能である。たとえば、ＴＣＰポート１３５がオープンな場合、この機器は、ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムを実行している可能性が高い。同様に、ＴＣＰポート２２がオープンな場合、この機器は、ＬＩＮＵＸ（登録商標）等のＵＮＩＸ（登録商標）オペレーティングシステムを実行している可能性が高い。ＵＤＰポート１６１がオープンな場合、この機器は、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を通じて別途識別可能となり得る。それ以外の可能性もある。特定のＩＰアドレスにおける機器およびそのオープンなポートの存在が検出されると、これらの設定項目がＣＭＤＢ５００に保存される。

【0089】

分類段階において、プロキシサーバ３１２は、各検出機器をさらにプローブして、そのオペレーティングシステムのバージョンを決定するようにしてもよい。特定の機器に使用されるプローブは、スキャン段階に当該機器に関して収集された情報に基づく。たとえば、ＴＣＰポート２２がオープンな機器が見つかった場合は、一組のＵＮＩＸ（登録商標）固有のプローブが用いられるようになっていてもよい。同様に、ＴＣＰポート１３５がオープンな機器が見つかった場合は、一組のＷＩＮＤＯＷＳ（登録商標）固有のプローブが用いられるようになっていてもよい。いずれの場合も、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器からの情報にログオンあるいはアクセス可能となる。たとえば、ＴＣＰポート２２がオープンな場合、プロキシサーバ３１２は、特定の機器に対するセキュアシェル（ＳＳＨ）接続を開始し、ファイルシステムの特定の場所から、機器上のオペレーティングシステムに関する情報を取得するように指示され得る。この情報に基づいて、オペレーティングシステムが決定されるようになっていてもよい。一例として、ＴＣＰポート２２がオープンなＵＮＩＸ（登録商標）機器は、ＡＩＸ（登録商標）、ＨＰＵＸ、ＬＩＮＵＸ（登録商標）、ＭＡＣＯＳ（登録商標）、またはＳＯＬＡＲＩＳ（登録商標）として分類される。この分類情報は、１つまたは複数の設定項目としてＣＭＤＢ５００に格納されていてもよい。

【0090】

識別段階において、プロキシサーバ３１２は、分類された機器に関する具体的詳細を決定するようにしてもよい。この段階において使用されるプローブは、分類段階に特定の機器に関して収集された情報に基づいていてもよい。たとえば、機器がＬＩＮＵＸ（登録商標）として分類された場合は、一組のＬＩＮＵＸ（登録商標）固有のプローブが用いられるようになっていてもよい。同様に、機器がＷＩＮＤＯＷＳ（登録商標）２０１２として分類された場合は、一組のＷＩＮＤＯＷＳ（登録商標）２０１２固有のプローブが用いられるようになっていてもよい。分類段階の場合と同様に、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器から、基本入力／出力システム（ＢＩＯＳ）情報、シリアル番号、ネットワークインターフェース情報、これらのネットワークインターフェースに割り当てられた媒体アクセス制御アドレス、特定の機器が使用するＩＰアドレス等の情報を世読み出し可能となる。この識別情報は、１つまたは複数の設定項目として、ＣＭＤＢ５００に格納されていてもよい。

【0091】

探索段階において、プロキシサーバ３１２は、分類された機器の動作状態に関する別途詳細を決定するようにしてもよい。この段階において使用されるプローブは、分類段階および／または識別段階に特定の機器に関して収集された情報に基づいていてもよい。この場合も、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器から、プロセッサ情報、メモリ情報、実行プロセス（アプリケーション）のリスト等の付加的な情報を読み出し可能となる。ここで再度、検出情報は、１つまたは複数の設定項目として、ＣＭＤＢ５００に格納されていてもよい。

【0092】

ルータ等のネットワーク機器上で検出を実行する場合は、ＳＮＭＰを利用するようにしてもよい。実行プロセスまたは他のアプリケーション関連情報のリストの決定の代替または追加として、検出では、ルータが既知の付加的なサブネットおよびルータのネットワークインターフェースの動作状態（たとえば、アクティブ、非アクティブ、キュー長、脱落パケット数等）を決定するようにしてもよい。付加的なサブネットのＩＰアドレスは、他の検出手順の候補となり得る。このため、検出は、反復的または再帰的に進行し得る。

【0093】

検出が完了となったら、ＣＭＤＢ５００において、各検出機器、アプリケーション、および／またはサービスのスナップショット表現が利用可能となる。たとえば、検出後は、マネージドネットワーク３００中のクライアント機器、サーバ機器、およびルータのオペレーティングシステムバージョン、ハードウェア構成、およびネットワーク構成詳細のほか、それらの上で実行されるアプリケーションが格納されるようになっていてもよい。これらの収集情報は、さまざまな方法でユーザに提示されることにより、機器のハードウェア構成および動作状態のほか、複数の機器およびアプリケーションに及ぶサービスの特性をユーザが確認可能となり得る。

【0094】

さらに、ＣＭＤＢ５００は、設定項目間の依存および関係に関するエントリを含んでいてもよい。より具体的には、特定のサーバ機器上で実行されているアプリケーションのほか、このアプリケーションに依拠するサービスがＣＭＤＢ５００においてこのように表され得る。たとえば、データベースアプリケーションがサーバ機器上で実行されており、また、このデータベースアプリケーションが新たな従業員研修サービスのほか、給与計算サービスで使用されるものとする。このため、サーバ機器が保守のため稼働を停止した場合は、従業員研修サービスおよび給与計算サービスが明らかに影響を受けることになる。同様に、設定項目間の依存および関係は、特定のルータが故障した場合に影響を受けるサービスを表し得ると考えられる。

【0095】

一般的に、設定項目間の依存および関係は、ウェブベースのインターフェースに表示され、階層として表され得る。したがって、このような依存および関係の追加、変更、または削除は、このインターフェースにより達成され得る。

【0096】

さらに、マネージドネットワーク３００のユーザは、検出された複数の機器にわたる特定の調整済み行為の実行を可能にするワークフローを開発することができる。たとえば、ＩＴワークフローによって、ユーザは、検出されたすべてのＬＩＮＵＸ（登録商標）機器の共通管理者パスワードを単一の操作で変更可能となる可能性もある。

【0097】

上述のような検出が行われるように、プロキシサーバ３１２、ＣＭＤＢ５００、ならびに／または１つもしくは複数の認証情報ストアには、検出対象の機器のうちの１つまたは複数の認証情報が設定されていてもよい。認証情報には、機器へのアクセスに必要な任意の種類の情報を含み得る。これらには、ユーザＩＤ／パスワードのペア、証明書等を含み得る。いくつかの実施形態において、これらの認証情報は、ＣＭＤＢ５００の暗号化フィールドに格納されていてもよい。プロキシサーバ３１２は、認証情報を用いた検出対象の機器へのログオンあるいはアクセスが可能となるように、これらの認証情報の復号キーを含んでいてもよい。

【0098】

図５Ｂには、検出プロセスをフローチャートとして示している。ブロック５２０において、演算インスタンスにおけるタスクリストには、たとえばさまざまなＩＰアドレスが入力される。ブロック５２２においては、スキャン段階が発生する。これにより、プロキシサーバは、ＩＰアドレスによって、これらのＩＰアドレスを使用する機器をプローブし、これらの機器で実行されているオペレーティングシステムの決定を試みる。ブロック５２４においては、分類段階が発生する。プロキシサーバは、検出された機器のオペレーティングシステムのバージョンの決定を試みる。ブロック５２６においては、識別段階が発生する。プロキシサーバは、検出された機器のハードウェアおよび／またはソフトウェア構成の決定を試みる。ブロック５２６においては、探索段階が発生する。プロキシサーバは、動作状態および検出された機器で実行されているアプリケーションの決定を試みる。ブロック５３０においては、検出された機器およびアプリケーションを表す設定項目の別途編集が発生し得る。この編集は、本質的に自動化および／または手動実行が可能である。

【0099】

図５Ｂにおいて表されるブロックは例である。検出は、高度に設定可能な手順であってもよく、段階の増減いずれかが可能であり、また、各段階の動作が異なっていてもよい。場合によっては、１つまたは複数の段階がカスタマイズされていてもよいし、上記の例示的な説明から逸脱していてもよい。

【0100】

このように、リモートネットワーク管理プラットフォームは、マネージドネットワーク上で展開されて提供されるハードウェア、ソフトウェア、およびサービスを検出して一覧化することができる。上述の通り、このデータは、関連する演算インスタンスのＣＭＤＢにおいて、設定項目として格納されていてもよい。たとえば、個々のハードウェアコンポーネント（たとえば、コンピュータ機器、仮想サーバ、データベース、ルータ等）がハードウェア設定項目として表される一方、その上でインストールおよび／または実行されるアプリケーションがソフトウェア設定項目として表されるようになっていてもよい。

【0101】

ハードウェア設定項目においてインストールまたは実行されるソフトウェア設定項目の関係は、ホスティング、実行、または依存等のさまざまな形態であってもよい。このため、サーバ機器にインストールされたデータベースアプリケーションは、サーバ機器と「ホスティング」の関係を有することにより、データベースアプリケーションがサーバ機器にホストされていることを示し得る。いくつかの実施形態において、サーバ機器は、データベースアプリケーションと「使用」の相互関係を有することにより、当該サーバ機器がデータベースアプリケーションにより使用されることを示し得る。これらの関係は、上述の検出手順を使用して自動的に見つけられるようになっていてもよいが、関係を手動で設定することも可能である。

【0102】

また、サービスと１つまたは複数のソフトウェア設定項目との間の関係は、さまざまな形態であってもよい。一例として、ウェブサービスは、それぞれが異なるハードウェア設定項目にインストールされたウェブサーバソフトウェア設定項目およびデータベースアプリケーションソフトウェア設定項目を含み得る。ウェブサービスがこれらのソフトウェア設定項目との「依存」関係を有し得る一方、ソフトウェア設定項目は、ウェブサービスと「使用」の相互関係を有する。サービスは、検出手順によって完全に決定され得るわけではなく、代わりに、サービスマッピング（たとえば、設定ファイルの調査および／または設定項目間のサービスレベル関係を決定するためのネットワークトラフィック分析の実行）および場合によりある程度の手動設定に依拠していてもよい。

【0103】

関係情報は、取得方法に関わらず、マネージドネットワークの運用に有益となり得る。とりわけ、ＩＴ担当者は、特定のソフトウェアアプリケーションが展開されている場所およびサービスを構成する設定項目を迅速に決定することができる。これにより、サービスの停止または劣化の根本原因を迅速に突き止めることができる。たとえば、２つの異なるサービスの応答時間が遅い場合は、（可能性として数ある行為の中でもとりわけ）ＣＭＤＢへの問い合わせによって、両サービスが使用するデータベースアプリケーションのプロセッサ利用率が高いことが根本原因であるものと判定することができる。このため、ＩＴ担当者は、サービスを構成する他の設定項目の健全性および性能の検討に時間を浪費することなく、データベースアプリケーションに対処することができる。

【0104】

Ｖ．マルチタイプユーザ用の例示的なデータベーススキーマ
上述の通り、演算インスタンスは、多数のユーザによる非常に多くのソフトウェアアプリケーションの使用を容易化し得る。各ユーザは、演算インスタンスにログオンしてこれらのソフトウェアアプリケーションにアクセスする際に使用可能な一意の識別子（たとえば、ユーザＩＤ）を有し得る。ユーザレコードは、ユーザおよびそれぞれの能力に関する情報を規定する１つまたは複数のデータベーステーブルのエントリとして格納され得る。各ユーザには、顧客（演算インスタンスを管理するエンティティの顧客の場合）、ベンダー（演算インスタンスを管理するエンティティのベンダーの場合）、または市民（演算インスタンスを管理する国または法域の国民または居住者の場合）等、特定のタイプまたはクラスが割り当てられ得る。

【0105】

演算インスタンスは（および、場合によりリモートネットワーク管理プラットフォーム全体も）、オブジェクト指向の階層的なデータの規定を可能にするテーブル・パー・クラス（ＴＰＣ）モデル（拡張モデルと称する場合もある）において動作するように設計されていてもよい。ユーザへの適用の場合、関連する実施態様は、すべてのユーザに関する情報のほか、各ユーザのタイプの指定を含む親テーブルの形態であってもよい。さらに、ユーザの各タイプは、それ自体のテーブル（子テーブル）を有していてもよく、これが当該クラスのユーザに固有の情報を規定する。このため、ユーザのタイプ（クラス）は場合により、子テーブルに対する１対１のマッピングを有し得るものの、このような関係は必須ではない。これらの子テーブルは、ユーザのサブタイプを別途指定するそれぞれ自体の付加的な子テーブルを有していてもよい。

【0106】

ここで、用語「タイプ（ｔｙｐｅ）」および「クラス（ｃｌａｓｓ）」は、文脈上の別段の示唆のない限り、同じ意味で使用され得る。「クラス」という専門用語は、採用可能なオブジェクト指向の階層を反映する一方、「タイプ」という専門用語は、より説明的であることから好まれることが多い。

【0107】

図６は、ユーザに対するＴＰＣモデルの考え得る一実施態様を示している。データベーススキーマ６００は、ユーザテーブル６０２（親）のほか、顧客テーブル６０４、ベンダーテーブル６０６、および市民テーブル６０８（子）という４つのテーブルを規定する。とりわけ、これは、クラスへのユーザの考え得る配置の１つに過ぎない。他種のクラス（たとえば、従業員および請負業者）も可能と考えられる。

【0108】

ユーザテーブル６０２は、ＩＤ（当該ユーザテーブル６０２のエントリごとの一意の識別子（たとえば、ユーザＩＤ））、名称（エントリと関連付けられている個人の名称）、電子メール（エントリと関連付けられている個人の電子メールアドレス）、および他のフィールド用の列を規定する。これら他のフィールドには、メーリングアドレス、ハッシュ化パスワード、シングルサインオン（ＳＳＯ）データ、デフォルトのユーザインターフェース表示オプション等、ユーザに関連する如何なる種類の情報も含み得る。

【0109】

ユーザテーブル６０２において表されるユーザの各タイプ（クラス）は、それ自体の子テーブルを有し、子テーブルはそれぞれ、当該タイプのユーザに関する別の情報を格納する。図６においては、ユーザテーブル６０２のエントリと顧客テーブル６０４、ベンダーテーブル６０６、および市民テーブル６０８のエントリとの間の関係を矢印付きの点線として示している。

【0110】

たとえば、ユーザテーブル６０２の最初のエントリは、ＩＤが００００１で、クラスが顧客である。したがって、このユーザのエントリは顧客テーブル６０４に存在する。当該エントリはＩＤが同じ００００１であり、顧客テーブル６０４のフィールドは、顧客アカウント番号等、ユーザの別の顧客固有情報を規定している。同様に、ユーザテーブル６０２の２番目のエントリは、ＩＤが００００２で、クラスがベンダーである。したがって、このユーザのエントリはベンダーテーブル６０６に存在する。当該エントリはＩＤが同じ００００２であり、ベンダーテーブル６０６のフィールドは、ベンダー名等、ユーザの別のベンダー固有情報を規定している。

【0111】

この階層構成は、多くのシステムにおいて妥当に機能する。ただし、ユーザごとに１種類の親クラスしかサポートしない、という制限がある。一方で、いくつかのユーザが複数のクラスに存在し得る非常に多くの種類のシステムが存在する。たとえば、エンティティの顧客は、当該エンティティのベンダーでもあり得る。同様に、行政体の市民は、当該行政体のベンダーでもあり得る。従来のＴＰＣモデルは、このような構成を反映するように拡張可能ではない。

【0112】

回避策として、複数のタイプを有するユーザには、タイプごとに１つずつ、システム上で複数のユーザＩＤが与えられていてもよい。これは、図６において反映されており、ユーザＪａｎ Ｓｍｉｔｈは、ユーザテーブル６０２において、顧客（ＩＤ ００００１）および市民（ＩＤ ００００３）としての２つのエントリを有する。したがって、（ＩＤ ００００３としての）Ｊａｎ Ｓｍｉｔｈのエントリが市民テーブル６０８に存在する。市民テーブル６０８のフィールドは、行政番号（たとえば、社会保障番号、運転免許証番号、またはその他何らかの種類の番号）等、Ｊａｎ Ｓｍｉｔｈの別の市民固有情報を規定している。ユーザテーブル６０２におけるＪａｎ Ｓｍｉｔｈの２つのエントリはそれぞれ、異なる電子メールアドレスを指定しており、これら２つのエントリの他のフィールドも異なり得る。

【0113】

この構成によって、マルチタイプユーザは、それぞれのタイプと関連付けられている情報すべてにアクセス可能となるが、煩雑になる可能性がある。ユーザは、演算インスタンスへのログオンに際していつでも、（タイプにより規定される）役割を追跡する必要がある。ユーザは、それぞれの役割のうちの異なる１つと関連付けられている情報にアクセスする必要がある場合、ログアウトして、当該別の役割と関連付けられている一組の認証情報を使用することにより、演算インスタンスに再ログインする必要がある（たとえば、Ｊａｎ Ｓｍｉｔｈは、自身の市民アカウントからのデータにアクセスするため、自身の顧客アカウントからログアウトした後に再ログインすることが必要となり得る）。

【0114】

この場合、マルチタイプユーザは、タイプごとに１つずつ、複数のログイン認証情報を記憶あるいは追跡する必要がある。これは特に、ユーザによっては３つ以上のタイプを有する場合もあることから、煩雑になり得る。さらに、同じユーザに関するユーザテーブル６０２の各エントリがデータベースにおける記憶空間を追加で占有することにより、そのユーザに関する何らかの重複情報を含む可能性もある。したがって、記憶の観点から、このようなマルチタイプユーザをサポートするための技術は非効率である。

【0115】

いくつかの環境においては、ユーザタイプの一部または全部を親テーブル（たとえば、ユーザテーブル６０２）に集約する改良モデルも可能と考えられる。これにより、子テーブルひいてはテーブルの階層が排除される可能性もある。たとえば、すべての子テーブルからのすべてのフィールドをユーザテーブル６０２に移すことも可能であり、また、フィルタフィールドの使用によって、ユーザが属するタイプを指定するようにしてもよい。あるタイプのフィルタフィールドによってユーザが当該タイプであることが示される場合は、当該タイプに固有のフィールドが有効であるものと仮定される。あるタイプのフィルタフィールドによってユーザが当該タイプでないことが示される場合は、当該タイプに固有のフィールドが無効であるものと仮定される。このため、場合によっては、タイプ固有フィルタフィールドとタイプとの間に１対１の関係が存在し得るものの、このような１対１の関係の存在は必須ではない。いくつかの実施態様においては、特定のタイプに対して、２つ以上のフィールドがフィルタフィールドとして用いられるようになっていてもよい（たとえば、ユーザが特定のタイプであるかを判定するための情報が複数のフィールドで分割されるようになっていてもよい）。

【0116】

図７は、このようなシングルテーブル構造を使用するデータベーススキーマ７００を示している。ユーザテーブル７０２においては、複数のタイプを有し得る単一のユーザと各エントリが関連付けられている。顧客、ベンダー、および市民のタイプについて、３つのブール型フィルタフィールドが存在する。ユーザが関連するタイプのうちの１つのメンバーである場合は、当該タイプのフィルタフィールドが「はい」に設定される。それ以外の場合は、フィルタフィールドが「いいえ」に設定される。

【0117】

先の例を続けると、ユーザＪａｎ Ｓｍｉｔｈは、顧客および市民のタイプであるため、ユーザテーブル７０２の自身のエントリの顧客および市民のフィルタフィールドが「はい」に設定されている。Ｊａｎ Ｓｍｉｔｈはベンダーのタイプではないため、自身のエントリのベンダーのフィルタフィールドが「いいえ」に設定されている。逆に、ユーザＲｏｂ Ｊｏｎｅｓは、顧客および市民のタイプではないため、ユーザテーブル７０２の自身のエントリの顧客および市民のフィルタフィールドが「いいえ」に設定されている。Ｒｏｂ Ｊｏｎｅｓはベンダーのタイプであるため、自身のエントリのベンダーのフィルタフィールドが「はい」に設定されている。

【0118】

フィルタフィールドが「はい」に設定されている場合は、１つまたは複数の付加的なフィールドが有効となり得る。ユーザテーブル７０２において、顧客のフィルタフィールドが「はい」に設定されていることは、顧客アカウントフィールドが有効であることを示し、ベンダーのフィルタフィールドが「はい」に設定されていることは、ベンダー名フィールドが有効であることを示し、市民のフィルタフィールドが「はい」に設定されていることは、行政番号フィールドが有効であることを示す。これらの付加的なフィールドのいずれかが有効でない場合は、表記「Ｎ／Ａ」でその旨が示され、データベースにおいては空の文字列またはヌル値により表されるようになっていてもよい。

【0119】

したがって、Ｊａｎ Ｓｍｉｔｈの顧客アカウントを判定しようとするソフトウェアアプリケーションは最初に、顧客のフィルタフィールドが「はい」であることを確認した後、顧客アカウントフィールドから値を読み出すことになる。同様に、Ｊａｎ Ｓｍｉｔｈの行政番号を判定しようとするソフトウェアアプリケーションは最初に、市民のフィルタフィールドが「はい」であることを確認した後、行政番号フィールドから値を読み出すことになる。

【0120】

一般的に、ユーザテーブル７０２には、特定のフィルタフィールドが「はい」に設定されている場合にのみ有効な１つまたは複数の付加的なフィールドを含む他のフィールドが存在していてもよい。ユーザテーブル７０２は、例示を目的として、シングルテーブルの一実施態様の簡素化された実例となることが意図される。

【0121】

図７の背景において記載のデータベース構造および関連する動作は、マルチタイプユーザをサポートする効果的な方法ではあるが、その有用性は、演算インスタンスにおけるユーザエントリのインストールベースが大規模になることが多い、という事実により制限される。たとえば、展開されたリモートネットワーク管理プラットフォームは、それぞれが数百、数千、または数万ものユーザをサポートする非常に多くの演算インスタンスをサポートする場合もある。

【0122】

さらに、スキーマ６００に従ってユーザ情報が配置されているプラットフォームにインストールされている独創的なソフトウェアアプリケーションおよびカスタマイズされたソフトウェアアプリケーションの両者が当該スキーマのマルチテーブル手法で動作するように記述されている場合もある。したがって、演算インスタンスをスキーマ７００で展開しようとしたり、演算インスタンスをスキーマ６００からスキーマ７００にアップグレードしようとしたりすると、非常に多くのソフトウェアアプリケーションがデータベースにおいてユーザエントリを特定できなくなる可能性がある。結果として、ユーザがプラットフォームにログオンできなくなる可能性もあり、事実上使用不可能となる。このため、より洗練された手法が求められている。

【0123】

このことから、図８はデータベーススキーマ８００を示すが、これは、シングルテーブルおよびマルチテーブルの組み合わせ構造の使用により、スキーマ６００のＴＰＣモデルに対して後方互換性のあるマルチタイプユーザをサポートする。とりわけ、スキーマ８００は、ユーザテーブル６０２および７０２のすべてのフィールドを有するユーザテーブル８０２を含む。したがって、ユーザテーブル８０２は、クラスフィールド、顧客フィルタフィールド、ベンダーフィルタフィールド、および市民フィールドのほか、顧客テーブル８０４、ベンダーテーブル８０６、および市民テーブル８０８においても指定されている任意の付加的なフィールドを含む。これら３つの子テーブルに関しては、顧客テーブル８０４が顧客固有フィールドを含み、ベンダーテーブル８０６がベンダー固有フィールドを含み、市民テーブル８０８が市民固有フィールドを含む。したがって、これらのテーブルとしては、図６の対応するテーブルと同じものが可能である。さらに、すべてではないがいくつかの実施形態においては、タイプ固有フィルタフィールドと当該タイプの子テーブルとの間に１対１の関係が存在していてもよい。

【0124】

ユーザに関連するタイプ固有情報は、ユーザテーブル８０２または当該タイプと関連付けられている子テーブルに現れ得る。この区別は、ユーザテーブル８０２のクラスフィールドが入力されているかに基づく。これが当てはまる場合、当該クラスに関連するタイプ固有情報は、関連する子テーブルにある。当てはまらないものの、当該タイプのタイプ固有フィルタが「はい」に設定されている場合は、ユーザテーブル８０２において、当該クラスに関連するタイプ固有情報が当該タイプの付加的なフィールドに現れ得る。ユーザテーブル８０２のクラスフィールドが入力されておらず、当該タイプのタイプ固有フィルタが「いいえ」に設定されている場合、当該タイプのタイプ固有情報は存在しない（したがって、ユーザは当該タイプではない）。

【0125】

一例として、ユーザテーブル８０２におけるＪａｎ Ｓｍｉｔｈのエントリは、クラスフィールドのタイプに顧客が入力されている。これは、顧客テーブル８０４にＪａｎ Ｓｍｉｔｈのエントリが存在することを示す。このエントリは、Ｊａｎ Ｓｍｉｔｈに関連する付加的な顧客固有情報（たとえば、彼女の顧客アカウント）を提供する。したがって、Ｊａｎ Ｓｍｉｔｈの顧客フィルタは「いいえ」に設定されており、ユーザテーブル８０２における顧客アカウントフィールドは、有効ではない。

【0126】

Ｊａｎ Ｓｍｉｔｈのベンダーフィルタフィールドも「いいえ」に設定されており、これは、ユーザテーブル８０２における彼女のベンダー名フィールドも無効であることを示す。なお、ユーザテーブル８０２におけるＪａｎ Ｓｍｉｔｈのクラスフィールドが顧客の値を有することから、ベンダーテーブル８０６には彼女のエントリが存在しないものと考えられる。

【0127】

Ｊａｎ Ｓｍｉｔｈの市民フィルタフィールドは「はい」に設定されており、これは、ユーザテーブル８０２における彼女の行政番号フィールドが有効であることを示す。したがって、ユーザテーブル８０２においては当該フィールドが入力されている。この場合も、ユーザテーブル８０２におけるＪａｎ Ｓｍｉｔｈのクラスフィールドが顧客の値を有することから、市民テーブル８０８には彼女のエントリが存在しないものと考えられる。

【0128】

このように、ユーザテーブル８０２と顧客テーブル８０４とでＪａｎ Ｓｍｉｔｈの情報が分割されている。この構成は、彼女の顧客固有情報の指定に従来のデータベーススキーマ（たとえば、スキーマ６００）が使用されている環境をサポートすることから、従来のソフトウェアアプリケーションとの後方互換性を目的として、当該データはそのままにすべきである。ただし、彼女の市民固有情報については、ユーザテーブル８０２に維持されている。これにより、新たなアプリケーションに対しては、Ｊａｎ Ｓｍｉｔｈを事実上マルチタイプとすることができる。

【0129】

これに対して、Ｒｏｂ Ｊｏｎｅｓは１つのタイプ、ベンダーに過ぎないため、彼のベンダー固有情報はすべて、ユーザテーブル８０２に格納されている。当該テーブルにおいては、彼のクラスフィールドがヌルまたはデフォルト値に設定されており、これは、彼のエントリが子テーブルには存在せず、彼の顧客フィルタフィールド、ベンダーフィルタフィールド、および市民フィルタフィールドの値を調べることにより彼のタイプが決定され得ることを示している。当然のことながら、彼のベンダーフィルタフィールドのみが「はい」に設定されている。したがって、彼の顧客固有および市民固有フィールドの値が有効である一方、彼のベンダー固有フィールドの値は有効である。ユーザテーブル８０２の適当な付加的なフィールドを使用することにより、任意のユーザに対して、より多くのタイプを追加することができる。

【0130】

スキーマ８００は、ユーザテーブル８０２または子テーブルを使用して、所与のタイプのユーザに固有のすべての情報を格納することを示しているが、情報をテーブル間で分割する他の構成も可能である。さらに、マルチタイプユーザは、それぞれのタイプ固有情報がすべて、ユーザテーブル８０２に格納されていてもよい。また、他の構成も可能である。

【0131】

スキーマ８００が従来のソフトウェアアプリケーションと後方互換であることを所与として、アプリケーションに対する特定の関心タイプのタイプ固有情報がすべて子テーブルに存在する限りは、スキーマ８００との連携を続けるために上記従来のアプリケーションを修正する必要はない。ただし、従来のソフトウェアアプリケーション以外の場合は、この情報に関して、親テーブルおよびタイプ固有の子テーブルの両者を確認できる必要がある。図９Ａおよび図９Ｂは、読み出しおよび書き込みそれぞれについて、確認の方法を示している。

【0132】

図９Ａは、読み出しリクエストに応答して演算インスタンスが実行する処理を示したフローチャートである。特に、ステップ９００においては、タイプ固有の読み出しリクエストが演算インスタンスに到着する。この読み出しリクエストは、ユーザＵについて、タイプＴのタイプ固有情報を取得しようとするものである。

【0133】

ステップ９０２において、演算インスタンスは、ユーザＵが親テーブル（たとえば、ユーザテーブル８０２）に存在するかを判定する。存在しない場合は、ユーザＵがシステムに存在しないため、ステップ９０４において、演算インスタンスがエラーを返す。

【0134】

ユーザＵが親テーブルに存在する場合、ステップ９０６において、演算インスタンスは、親テーブルのクラスフィールドにおいてタイプＴが指定されているかを判定する。これが当てはまる場合、ステップ９０８において、演算インスタンスは、タイプＴと関連付けられている子テーブルから、ユーザＵのタイプ固有情報を読み出す。

【0135】

親テーブルのクラスフィールドにおいてタイプＴが指定されていない場合、ステップ９１０において、演算インスタンスは、親テーブルにおいてタイプＴのフィルタフィールドが設定されているか（たとえば、「はい」の値を有するか）を判定する。設定されていない場合は、ユーザＵがタイプＴではないため、ステップ９１２において、演算インスタンスがエラーを返す。設定されている場合、ステップ９１４において、演算インスタンスは、タイプＴと関連付けられている親テーブル中の付加的なフィールドからタイプ固有情報を読み出す。

【0136】

図９Ｂは、書き込みリクエストに応答して演算インスタンスが実行する処理を示したフローチャートである。特に、ステップ９５０においては、タイプ固有の書き込みリクエストが演算インスタンスに到着する。この書き込みリクエストは、ユーザＵについて、タイプＴのタイプ固有情報を格納しようとするものである。

【0137】

ステップ９５２において、演算インスタンスは、ユーザＵが親テーブル（たとえば、ユーザテーブル８０２）に存在するかを判定する。存在しない場合は、ユーザＵがシステムに存在しないため、ステップ９５４において、演算インスタンスがエラーを返す。

【0138】

ユーザＵが親テーブルに存在する場合、ステップ９５６において、演算インスタンスは、親テーブルのクラスフィールドにおいてタイプＴが指定されているかを判定する。これが当てはまる場合、ステップ９５８において、演算インスタンスは、タイプＴと関連付けられている子テーブルにユーザＵのタイプ固有情報を書き込む。

【0139】

親テーブルのクラスフィールドにおいてタイプＴが指定されていない場合、ステップ９６０において、演算インスタンスは、親テーブルにおいてタイプＴのフィルタフィールドが設定されているかを判定する。設定されていない場合は、ユーザＵがタイプＴではないため、ステップ９６２において、演算インスタンスがエラーを返す。設定されている場合、ステップ９６４において、演算インスタンスは、タイプＴと関連付けられている親テーブル中の付加的なフィールドにタイプ固有情報を書き込む。

【0140】

とりわけ、図９Ａおよび図９Ｂの手順は、条件のうちのいくつかが確認される順序のほか、スキーマにおける情報の場所に関して、ある程度異なり得る。したがって、これらの手順は、例示を目的として与えられる。さらに、これらの手順および本明細書の他の開示内容の使用によって、ユーザのみならず他の形態のマルチタイプデータもサポートすることができる。たとえば、本明細書の実施態様に類似する実施態様を採用することにより、階層型オブジェクト指向および／またはＴＰＣフレームワークを使用してモデル化された任意のデータ項目に後方互換性の複数のタイプをサポートさせることができる。

【0141】

ＶＩ．例示的なオペレーション
図１０Ａは、例示的な一実施形態を示したフローチャートである。図１０Ａにより示されるプロセスは、コンピュータ機器１００等のコンピュータ機器および／またはサーバクラスタ２００等のコンピュータ機器のクラスタにより実行されるようになっていてもよい。ただし、このプロセスは、他種の機器または機器サブシステムによっても実行可能である。たとえば、このプロセスは、リモートネットワーク管理プラットフォームまたはラップトップもしくはタブレット機器等の携帯型コンピュータの演算インスタンスにより実行することも可能である。

【0142】

図１０Ａの実施形態は、そこに示される特徴のいずれか１つまたは複数を除去することによって簡略化することができる。さらに、これらの実施形態は、先の図のいずれかあるいは本明細書に記載の特徴、態様、および／または実施態様と組み合わされるようになっていてもよい。

【0143】

ブロック１０００は、第１のエンティティに関する第１のタイプの第１のタイプ固有情報を永続的ストレージから読み出すための第１のリクエストを受信することであり、永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、タイプがそれぞれ、１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、タイプのうちの１つまたは複数と関連付けられている、ことを含んでいてもよい。

【0144】

ブロック１００２は、第１のエンティティに関する親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することを含んでいてもよい。

【0145】

ブロック１００４は、１つまたは複数の子テーブルのうちの特定の子テーブルから、第１のタイプ固有情報を取得することであり、特定の子テーブルが、第１のタイプと関連付けられている、ことを含んでいてもよい。

【0146】

ブロック１００６は、第１のリクエストに応答して、第１のタイプ固有情報を提供することを含んでいてもよい。

【0147】

ブロック１００８は、第２のエンティティに関する第２のタイプの第２のタイプ固有情報を永続的ストレージから読み出すための第２のリクエストを受信することを含んでいてもよい。

【0148】

ブロック１０１０は、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することを含んでいてもよい。

【0149】

ブロック１０１２は、親テーブルの第２のエントリにおける一組の付加的なフィールドから、第２のタイプ固有情報を取得することであり、一組の付加的なフィールドが、特定のタイプ固有フィルタフィールドと関連付けられている、ことを含んでいてもよい。

【0150】

ブロック１０１４は、第２のリクエストに応答して、第２のタイプ固有情報を提供することを含んでいてもよい。

【0151】

いくつかの実施形態は、第１のエンティティに関する第２のタイプの第３のタイプ固有情報を永続的ストレージから読み出すための第３のリクエストを受信することと、親テーブルの第１のエントリにおいて、特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することと、親テーブルの第１のエントリにおける一組の付加的なフィールドから、第３のタイプ固有情報を取得することと、第３のリクエストに応答して、第３のタイプ固有情報を提供することと、をさらに含んでいてもよい。

【0152】

いくつかの実施形態は、第１のエンティティに関して親テーブルを検索することと、第１のエントリが第１のエンティティと関連付けられているものと判定することと、をさらに含んでいてもよい。

【0153】

いくつかの実施形態において、１つまたは複数のタイプ固有フィルタフィールドはそれぞれ、親テーブルにおける１つまたは複数の付加的なフィールドと関連付けられている。

【0154】

いくつかの実施形態において、第１のエンティティは、第１のユーザであり、第２のエンティティは、第２のユーザであり、第１のタイプ固有情報および第２のタイプ固有情報はそれぞれ、ログオン、永続的ストレージ中の特定のデータユニットへのアクセスの許可、またはグラフィカルユーザインターフェース上での素材の提示のうちの１つまたは複数に関連する。

【0155】

いくつかの実施形態において、第１のタイプ固有情報を取得することは、第１のエンティティと関連付けられている特定の子テーブルのエントリのフィールドから、第１のタイプ固有情報を読み出すことを含む。

【0156】

いくつかの実施形態において、第１のエンティティは、一意の識別子と関連付けられており、親テーブルの第１のエントリは、一意の識別子を含み、特定の子テーブルのエントリは、一意の識別子を含み、第１のタイプ固有情報を読み出すことは、一意の識別子に関して特定の子テーブルのエントリを検索することと、特定の子テーブルのエントリにおいて一意の識別子を特定することと、を含む。

【0157】

いくつかの実施形態は、親テーブルの第２のエントリにおいて、第２のタイプがクラスフィールドにおいて指定されていないものと判定することであり、特定のタイプ固有フィルタフィールドが、第２のタイプがクラスフィールドにおいて指定されていないことに基づいて考慮される、ことをさらに含んでいてもよい。

【0158】

いくつかの実施形態は、第１のエンティティに関する第１のタイプの第３のタイプ固有情報を永続的ストレージに書き込むための第３のリクエストを受信することと、親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することと、第３のタイプ固有情報を特定の子テーブルに書き込むことと、第２のエンティティに関する第２のタイプの第４のタイプ固有情報を永続的ストレージに書き込むための第４のリクエストを受信することと、親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することと、第４のタイプ固有情報を親テーブルにおける一組の付加的なフィールドに書き込むことと、をさらに含んでいてもよい。

【0159】

いくつかの実施形態において、第１のタイプ固有情報を取得することは、第１のエンティティに関する親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することに応答して発生し、第２のタイプ固有情報を取得することは、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することに応答して発生する。

【0160】

図１０Ｂは、例示的な一実施形態を示したフローチャートである。図１０Ｂにより示されるプロセスは、コンピュータ機器１００等のコンピュータ機器および／またはサーバクラスタ２００等のコンピュータ機器のクラスタにより実行されるようになっていてもよい。ただし、このプロセスは、他種の機器または機器サブシステムによっても実行可能である。たとえば、このプロセスは、リモートネットワーク管理プラットフォームまたはラップトップもしくはタブレット機器等の携帯型コンピュータの演算インスタンスにより実行することも可能である。

【0161】

図１０Ｂの実施形態は、そこに示される特徴のいずれか１つまたは複数を除去することによって簡略化することができる。さらに、これらの実施形態は、先の図のいずれかあるいは本明細書に記載の特徴、態様、および／または実施態様と組み合わされるようになっていてもよい。

【0162】

ブロック１０５０は、第１のエンティティに関する第１のタイプの第１のタイプ固有情報を永続的ストレージに書き込むための第１のリクエストを受信することであり、永続的ストレージが、親テーブルと１つまたは複数の子テーブルとを含み、親テーブルが、（ｉ）タイプを指定するクラスフィールドと、（ｉｉ）１つまたは複数のタイプ固有フィルタフィールドと、を含み、タイプがそれぞれ、１つまたは複数の子テーブルからの異なるテーブルと関連付けられており、１つまたは複数のタイプ固有フィルタフィールドがそれぞれ、タイプのうちの１つまたは複数と関連付けられている、ことを含んでいてもよい。

【0163】

また、ブロック１０５２は、親テーブルの第１のエントリにおいて、第１のタイプがクラスフィールドにおいて指定されているものと判定することを含んでいてもよい。

【0164】

また、ブロック１０５４は、第１のタイプ固有情報を１つまたは複数の子テーブルのうちの特定の子テーブルに書き込むことであり、特定の子テーブルが、第１のタイプと関連付けられている、ことを含んでいてもよい。

【0165】

また、ブロック１０５６は、第２のエンティティに関する第２のタイプの第２のタイプ固有情報を永続的ストレージに書き込むための第２のリクエストを受信することを含んでいてもよい。

【0166】

ブロック１０５８は、第２のエンティティに関する親テーブルの第２のエントリにおいて、第２のタイプと関連付けられている特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することを含んでいてもよい。

【0167】

ブロック１０６０は、第２のタイプ固有情報を親テーブルの第２のエントリにおける一組の付加的なフィールドに書き込むことであり、一組の付加的なフィールドが、特定のタイプ固有フィルタフィールドと関連付けられている、ことを含んでいてもよい。

【0168】

いくつかの実施形態は、第１のエンティティに関する第２のタイプの第３のタイプ固有情報を永続的ストレージに書き込むための第３のリクエストを受信することと、親テーブルの第１のエントリにおいて、特定のタイプ固有フィルタフィールドにより、第２のタイプが存在するものとして示されるものと判定することと、第３のタイプ固有情報を親テーブルの第１のエントリにおける一組の付加的なフィールドに書き込むことと、をさらに含んでいてもよい。

【0169】

いくつかの実施形態は、第１のエンティティに関して親テーブルを検索することと、第１のエントリが第１のエンティティと関連付けられているものと判定することと、を含んでいてもよい。

【0170】

いくつかの実施形態において、第１のタイプ固有情報を書き込むことは、第１のタイプ固有情報を、第１のエンティティと関連付けられている特定の子テーブルのエントリのフィールドに書き込むことを含む。

【0171】

いくつかの実施形態において、第１のエンティティは、一意の識別子と関連付けられており、親テーブルの第１のエントリは、一意の識別子を含み、特定の子テーブルのエントリは、一意の識別子を含み、第１のタイプ固有情報を書き込むことは、一意の識別子に関して特定の子テーブルのエントリを検索することと、特定の子テーブルのエントリにおいて一意の識別子を特定することと、を含む。

【0172】

いくつかの実施形態において、１つまたは複数のタイプ固有フィルタフィールドはそれぞれ、親テーブルにおける１つまたは複数の付加的なフィールドと関連付けられている。

【0173】

いくつかの実施形態において、第１のエンティティは、第１のユーザであり、第２のエンティティは、第２のユーザであり、第１のタイプ固有情報および第２のタイプ固有情報はそれぞれ、ログオン、永続的ストレージ中の特定のデータユニットへのアクセスの許可、またはグラフィカルユーザインターフェース上での素材の提示のうちの１つまたは複数に関連する。

【0174】

ＶＩＩ．結論
本開示は、種々態様の説明を意図した本願に記載の特定の実施形態の観点で限定されるものではない。当業者には明らかなように、その範囲から逸脱することなく、多くの改良および変形が可能である。以上の説明から、本明細書に記載したもののほか、本開示の範囲内の機能的に同等な方法および装置が当業者には明らかとなるであろう。このような改良および変形についても、添付の特許請求の範囲に含まれることになる。

【0175】

上記詳細な説明では、添付の図面を参照しつつ、開示のシステム、機器、および方法のさまざまな特徴および動作を記述している。本明細書および図面に記載の例示的な実施形態は、何ら限定を意味するものではない。本明細書に提示の主題の範囲から逸脱することなく、他の実施形態を利用可能であるとともに、他の変更を加えることができる。本明細書の全体に記載するとともに図面に示すような本開示の態様は、多種多様な異なる構成での配置、置換、結合、分離、および設計が可能であることが容易に了解される。

【0176】

図中のメッセージフロー図、シナリオ、およびフローチャートのいずれかまたはすべてに関して、本明細書に論じる通り、各ステップ、ブロック、および／または通信は、例示的な実施形態に係る情報の処理および／または情報の伝送を表し得る。これらの例示的な実施形態の範囲には、代替実施形態が含まれる。これらの代替実施形態において、たとえば、ステップ、ブロック、伝送、通信、リクエスト、応答、および／またはメッセージとして記述された動作は、関与する機能に応じて、図示または説明の順序から外れて実行可能である（実質的に同時または逆順を含む）。さらに、本明細書に論じるメッセージフロー図、シナリオ、およびフローチャートのいずれにおいても、使用するブロックおよび／または動作の数を増やすことも減らすことも可能であり、これらのメッセージフロー図、シナリオ、およびフローチャートの一部または全部を相互に結合可能である。

【0177】

情報の処理を表すステップまたはブロックは、本明細書に記載の方法または技術の特定の論理的機能を実行するように構成され得る回路に対応可能である。この代替または追加として、情報の処理を表すステップまたはブロックは、プログラムコード（関連データを含む）のモジュール、セグメント、または一部に対応可能である。プログラムコードは、上記方法または技術における特定の論理的操作または動作を実行するためにプロセッサによって実行可能な１つまたは複数の命令を含み得る。プログラムコードおよび／または関連データは、ＲＡＭ、ディスクドライブ、半導体ドライブ、または別の記憶媒体を含む記憶装置等の如何なる種類のコンピュータ可読媒体にも格納可能である。

【0178】

また、コンピュータ可読媒体には、レジスタメモリおよびプロセッサキャッシュ等、データを短期間にわたって格納する非一時的コンピュータ可読媒体等の非一時的コンピュータ可読媒体を含み得る。非一時的コンピュータ可読媒体には、プログラムコードおよび／またはデータを長期間にわたって格納する非一時的コンピュータ可読媒体をさらに含み得る。したがって、非一時的コンピュータ可読媒体には、たとえばＲＯＭ、光もしくは磁気ディスク、半導体ドライブ、またはコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）等の二次的または永続的な長期ストレージを含み得る。また、非一時的コンピュータ可読媒体としては、その他任意の揮発性または不揮発性記憶システムも可能である。非一時的コンピュータ可読媒体は、たとえばコンピュータ可読記憶媒体または有形の記憶装置と考えられる。

【0179】

さらに、１つまたは複数の情報伝送を表すステップまたはブロックは、同じ物理的機器におけるソフトウェアおよび／またはハードウェアモジュール間の情報伝送に対応し得る。ただし、他の情報伝送としては、異なる物理的機器におけるソフトウェアモジュールおよび／またはハードウェアモジュール間も可能である。

【0180】

図面に示す特定の配置は、何ら限定的なものと捉えるべきではない。他の実施形態では、所与の図面に示す各要素の数を増やすことも減らすことも可能であることが了解されるものとする。さらに、図示の要素の一部の結合も可能であるし、省略も可能である。さらには、図面に示していない要素を例示的な一実施形態が含むことも可能である。

【0181】

本明細書においては、種々態様および実施形態を開示しているが、当業者には他の態様および実施形態も明らかとなるであろう。本明細書に開示の種々態様および実施形態は、例示を目的としたものであって、何ら限定を意図せず、真の範囲は以下の特許請求の範囲により示される。

【符号の説明】

【0182】

１００ コンピュータ機器
１０２ プロセッサ
１０４ メモリ
１０４Ａ ファームウェア
１０４Ｂ カーネル
１０４Ｃ アプリケーション
１０６ ネットワークインターフェース
１０８ 入力／出力ユニット
１１０ システムバス
２００ サーバクラスタ
２０２ サーバ機器
２０４ データストレージ
２０６ ルータ
２０８ ローカルクラスタネットワーク
２１０ 通信リンク
２１２ ネットワーク
３００ マネージドネットワーク
３０２ クライアント機器
３０４ サーバ機器
３０６ ルータ
３０８ 仮想マシン
３１０ ファイアウォール
３１２ プロキシサーバ
３２０ リモートネットワーク管理プラットフォーム
３２２ 演算インスタンス
３２４ 演算インスタンス
３２６ 演算インスタンス
３２８ 演算インスタンス
３４０ パブリッククラウドネットワーク
３５０ インターネット
４００Ａ データセンタ
４００Ｂ データセンタ
４０２Ａ ＶＰＮゲートウェイ
４０２Ｂ ＶＰＮゲートウェイ
４０４Ａ ファイアウォール
４０４Ｂ ファイアウォール
４０６Ａ 負荷分散器
４０６Ｂ 負荷分散器
４１０ 設定項目
４１２ ＶＰＮゲートウェイ
４１４ ユーザ
４１６ リモートユーザ
５００ ＣＭＤＢ
５０２ タスクリスト
６００ データベーススキーマ
６０２ ユーザテーブル
６０４ 顧客テーブル
６０６ ベンダーテーブル
６０８ 市民テーブル
７００ データベーススキーマ
７０２ ユーザテーブル
８００ データベーススキーマ
８０２ ユーザテーブル
８０４ 顧客テーブル
８０６ ベンダーテーブル
８０８ 市民テーブル

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10A】

【図10B】

【国際調査報告】