JP2024106320A - プラットフォームインテリジェンスの設定および展開のための統合フレームワーク - Google Patents

Abstract

【課題】新規な機能の定義を決定する方法を提供する。【解決手段】方法は、機能の定義を決定することであり、定義が、入力、出力、および機能が入力に実行して出力を生成する演算を示す、ことを含む。また、この方法は、機能を提供するように構成されている複数のモデルを決定することと、機能のモデル非依存表現を提供するように構成されているアプリケーションビルダに機能の定義を提供することと、上記モデルの各モデルそれぞれについて、アプリケーションビルダを使用して規定されたソフトウェアアプリケーションに機能を実行時に提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示すマッピングを決定することであり、マッピングが、アプリケーションビルダにより変更不可能である、ことと、を含む。この方法は、機能を提供するためのリクエストのソフトウェアアプリケーションからの受信に応答して、機能をマッピングに従ってソフトウェアアプリケーションに提供することをさらに含む。【選択図】図８

Description

機械学習モデルおよび／または他種のモデルを利用するソフトウェアアプリケーションの開発には、ソフトウェアアプリケーションの一部としてのこれらモデルの実装を可能にするため、このようなモデルがどのように動作するかの理解を伴う場合がある。モデルのアプリケーション固有バージョンをソフトウェアアプリケーションの一部として実装すること、および／または、既存のモデルをソフトウェアアプリケーションの一部として統合することは、プログラミング集約的なプロセスおよび／または時間のかかるプロセスとなり得るため、ソフトウェアアプリケーションの開発に伴う労力および／または時間が増大する可能性もある。したがって、さまざまなモデルを容易に利用可能な場合であっても、モデルの選択、開発、および／または統合には、特にローコードおよび／またはノーコードソフトウェア開発者によるこれらモデルの利用の遅延または妨害という困難を伴う可能性がある。

ソフトウェア開発者によるさまざまなモデルの利用は、ソフトウェアアプリケーションがこれらのモデルを利用する様態を標準化するモデル統合層（ｍｏｄｅｌ ｉｎｔｅｇｒａｔｉｏｎ ｌａｙｅｒ）を提供することによって促進され得る。モデル統合層は、モデルおよびソフトウェアアプリケーションの相互接続を容易化するフレームワークを構成し得る。モデル統合層は、ソフトウェアアプリケーション（ローコードおよび／またはノーコードアプリケーションビルダを使用して開発されたソフトウェアアプリケーションを含む）への統合のための複数の機能（ｃａｐａｂｉｌｉｔｉｅｓ）を提供し得る。各機能は複数のモデルにより提供され得るが、これらのモデル、それぞれ固有の実装詳細、および／または選択プロセスは、ソフトウェアアプリケーションビルダおよび／またはソフトウェアアプリケーションから見えない場合もある。このため、ソフトウェアアプリケーションビルダは、機能のモデル非依存表現（ｍｏｄｅｌ－ｉｎｄｅｐｅｎｄｅｎｔ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を利用するように構成されている場合もある。特定の機能の表現には、その１つもしくは複数の入力、その１つもしくは複数の出力、ならびに入力に実行されて出力を生成する演算の記述を含み得るが、その基礎となるモデルに関する詳細を含まない場合もある。

モデル統合層によれば、ソフトウェアアプリケーションは、機能固有フォーマットの入力データを提供して、機能固有フォーマットの出力データを生成することが可能となり、それぞれが標準化され、経時的に一定に保たれ得る。これらの機能固有データフォーマットが、機能提供のために選択されたモデルが利用する対応するモデル固有データフォーマットと異なる場合、モデル統合層は、機能固有フォーマットとモデル固有フォーマットとの間（および、その逆）で変換を実行し、機能のモデル非依存実行の体裁をソフトウェアアプリケーションに与えるように構成され得る。

また、モデル統合層は、実行時に決定された１つまたは複数の属性値に対するモデル選択を調節するマッピングも含み得る。これらの実行時属性値（ｒｕｎｔｉｍｅ ａｔｔｒｉｂｕｔｅ ｖａｌｕｅ）は、ソフトウェアアプリケーション、ソフトウェアアプリケーションビルダ、モデル統合層、モデル、および／またはモデルを提供するコンピュータシステムの特性を示し得る。実行時属性値に基づくモデル選択によれば、モデル統合層は、たとえばモデル精度、モデル演算複雑性、現在の機能／モデル要求（すなわち、システム処理負荷）、ソフトウェアアプリケーションが予想するサービスの品質、および／または実行時に存在する他の条件の考慮に基づくモデル選択を実行可能となり得る。マッピングは、これらの機能を利用するソフトウェアアプリケーションの能力に影響を及ぼすことなく、モデル統合層によって変更可能となり得る。

このため、各ソフトウェアアプリケーションが標準化された様態で所与の機能と相互作用し得るものの、マッピングによれば、上記機能は、さまざまな程度の精度、レイテンシ、演算リソース利用、および／または他の性能パラメータで出力データを提供可能となり得る。さらに、機能を提供するように構成されている特定の一組のモデルが経時的に変化する場合であっても、ソフトウェアアプリケーションが同じ機能を使用し続けられるため、ソフトウェアアプリケーションへの大きな影響なくモデル統合層での変更が可能となる。このようなモデル統合層での変更を可能にすることにより、ソフトウェア開発者は、標準化された機能インターフェースに影響を及ぼすことなく、ひいては、ソフトウェアアプリケーションビルダにより機能を利用するローコードおよび／またはノーコード開発者の側での動作の必要なく、モデルの追加、変更、および／または置き換えが可能となり得る。

したがって、第１の例示的な実施形態は、機能の定義を決定することを含んでいてもよい。定義は、機能の入力、機能の出力、および機能が入力に実行して出力を生成する演算を示していてもよい。また、第１の例示的な実施形態は、機能を提供するように構成されている複数のモデルを決定することと、機能のモデル非依存表現を提供するように構成されているアプリケーションビルダに機能の定義を提供することと、を含んでいてもよい。また、第１の例示的な実施形態は、複数のモデルの各モデルそれぞれについて、アプリケーションビルダを使用して規定されたソフトウェアアプリケーションに機能を実行時に提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示すマッピングを決定することを含んでいてもよい。マッピングは、アプリケーションビルダにより変更不可能であってもよい。さらに、第１の例示的な実施形態は、機能を提供するためのリクエストのソフトウェアアプリケーションからの受信に応答して、機能をマッピングに従ってソフトウェアアプリケーションに提供することを含んでいてもよい。

第２の例示的な実施形態は、ソフトウェアアプリケーションから、機能をソフトウェアアプリケーションに提供するためのリクエストを受信することを含んでいてもよい。リクエストは、機能の入力データを含んでいてもよい。機能は、入力データに演算を実行して出力データを生成するように構成されていてもよい。ソフトウェアアプリケーションは、当該ソフトウェアアプリケーションへの統合のため、機能のモデル非依存表現を提供するように構成されているアプリケーションビルダを使用して規定されていてもよい。また、第２の例示的な実施形態は、機能を提供するためのリクエストの受信に応答して、ソフトウェアアプリケーションと関連付けられている少なくとも１つの実行時属性値を決定することと、少なくとも１つの実行時属性値およびマッピングに基づいて、機能を提供するように構成されている複数のモデルから第１のモデルを選択することと、を含んでいてもよい。マッピングは、複数のモデルの各モデルそれぞれについて、ソフトウェアアプリケーションに対して機能を実行時に提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示していてもよい。マッピングは、アプリケーションビルダにより変更不可能であってもよい。また、第２の例示的な実施形態は、第１のモデルにソフトウェアアプリケーションから受信した入力データを処理させることと、第１のモデルから出力データを受信することと、出力データのモデル非依存表現をソフトウェアアプリケーションに提供することと、を含んでいてもよい。

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

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

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

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

例示的な実施形態に係る、コンピュータ機器の模式図である。 例示的な実施形態に係る、サーバ機器クラスタの模式図である。 例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを示した図である。 例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む通信環境を示した図である。 例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む別の通信環境を示した図である。 例示的な実施形態に係る、モデル統合層を示した図である。 例示的な実施形態に係る、メッセージフロー図である。 例示的な実施形態に係る、メッセージフロー図である。 例示的な実施形態に係る、フローチャートである。 例示的な実施形態に係る、フローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

場合によっては、プロキシサーバ３１２の補助により、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００が使用するパブリッククラウドネットワーク３４０の態様を検出および管理することも可能となり得る。図３には示していないものの、パブリッククラウドネットワーク３４０のいずれに１つまたは複数のプロキシサーバ３１２を配置することによって、この検出および管理を容易化するようにしてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

格納または送信に際して、設定項目は、当該設定項目が表すハードウェアまたはソフトウェアを特性化する属性のリストであってもよい。これらの属性には、製造者、ベンダー、場所、所有者、一意の識別子、説明、ネットワークアドレス、動作状態、シリアル番号、最終更新時間等を含み得る。設定項目のクラスは、設定項目に対して存在する属性の部分集合を決定し得る（たとえば、ソフトウェアおよびハードウェアの設定項目は、異なる属性リストを有し得る）。

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

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

本項では、マネージドネットワーク３００に実行される検出を記載するが、パブリッククラウドネットワーク３４０上でも同一または同様の検出手順が用いられるようになっていてもよい。このため、いくつかの環境において、「検出」は、マネージドネットワークならびに／または１つもしくは複数のパブリッククラウドネットワーク上での設定項目および関係の検出を表し得る。

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

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

図５においては、ＣＭＤＢ５００、タスクリスト５０２、および識別・調停エンジン（ＩＲＥ）５１４の配設および／または動作が演算インスタンス３２２内で行われる。タスクリスト５０２は、演算インスタンス３２２とプロキシサーバ３１２との間の接続点を表す。タスクリスト５０２は、キューと称する場合もあるし、より詳細には、外部通信チャネル（ＥＣＣ）キューと称する場合もある。タスクリスト５０２は、キュー自体のみならず、キューの情報の追加、削除、および／または操作等、任意の関連する処理も表し得る。

検出が行われると、演算インスタンス３２２は、プロキシサーバ３１２が１つまたは複数のバッチでこれらのタスクを要求するまで、プロキシサーバ３１２が実行すべき検出タスク（ジョブ）をタスクリスト５０２に格納するようにしてもよい。タスクをタスクリスト５０２に配置することは、プロキシサーバ３１２がそれぞれの検出動作を開始することのトリガあるいはきっかけとなり得る。たとえば、プロキシサーバ３１２がタスクリスト５０２を定期的または随時ポーリングするようにしてもよいし、その他何らかの方法でタスクリスト５０２の検出コマンドをプロキシサーバ３１２に通知するようにしてもよい。この代替または追加として、検出がトリガイベントに基づいて手動または自動でトリガされるようになっていてもよい（たとえば、１日に１回、特定の時間に、検出が自動的に開始となってもよい）。

それにも関わらず、演算インスタンス３２２は、要求に応じて、これらの検出コマンドをプロキシサーバ３１２に送信するようにしてもよい。たとえば、プロキシサーバ３１２は、タスクリスト５０２を繰り返し問い合わせ、その中の次のタスクを取得し、タスクリスト５０２が空になるか、または、別の停止条件が達成されるまで、このタスクを実行するようにしてもよい。検出コマンドの受信に応答して、プロキシサーバ３１２は、マネージドネットワーク３００中のさまざまな機器、構成要素、アプリケーション、および／またはサービス（簡略化のため、図５においては機器５０４、５０６、５０８、５１０、および５１２で表される）への問い合わせを行うようにしてもよい。これらの機器、構成要素、アプリケーション、および／またはサービスは、それぞれの構成、動作、および／または状態に関する応答をプロキシサーバ３１２に与えるようにしてもよい。これに対して、プロキシサーバ３１２はその後、この検出情報をタスクリスト５０２に提供するようにしてもよい（すなわち、タスクリスト５０２は、プロキシサーバ３１２により要求されるまで検出コマンドを保持するための送信キューと、検出情報を読み出されるまで保持するための受信キューと、を有し得る）。

ＩＲＥ５１４は、タスクリスト５０２から検出情報を取り出し、この検出情報を（たとえば、マネージドネットワーク３００上で検出された機器、構成要素、アプリケーション、および／またはサービスを表す）設定項目およびそれぞれの間の関係として編成するソフトウェアモジュールであってもよい。そして、ＩＲＥ５１４は、これらの設定項目および関係を格納のためＣＭＤＢ５００に与えるようにしてもよい。ＩＲＥ５１４の動作については、以下により詳しく説明する。

このように、ＣＭＤＢ５００に格納された設定項目は、マネージドネットワーク３００の環境を表す。一例として、これらの設定項目は、一組の物理および／または仮想機器（たとえば、クライアント機器、サーバ機器、ルータ、または仮想マシン）、これら（たとえば、ウェブサーバ、電子メールサーバ、データベース、またはストレージアレイ）の上で実行されるアプリケーションのほか、複数の個々の設定項目を含むサービスを表し得る。関係は、設定項目間の配置または依存関係のペア定義であってもよい。

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

検出には、水平および垂直（トップダウン）という２つの一般的な種類が存在する。それぞれを以下に論じる。

Ａ．水平検出
水平検出は、マネージドネットワーク３００をスキャンし、機器、構成要素、および／またはアプリケーションを探索した後、これらの機器、構成要素、および／またはアプリケーションを表す設定項目をＣＭＤＢ５００に入力するのに用いられる。また、水平検出では、設定項目間の関係を生成する。たとえば、ソフトウェアアプリケーションを表す設定項目とそれが実行されるサーバ機器を表す設定項目との間の「実行」関係が可能である。通常、水平検出ではサービスを認識しておらず、動作するサービスに基づいて設定項目間の関係を生成することはない。

水平検出には２つのバージョンが存在する。一方がプローブおよびセンサに依拠する一方、他方はパターンも採用する。プローブおよびセンサは、機器上で検出情報を収集および処理した後、これに応じてＣＭＤＢ５００を更新する（たとえば、ＪＡＶＡＳＣＲＩＰＴ（登録商標）で書かれた）スクリプトであってもよい。より具体的には、プローブがマネージドネットワーク３００上の機器を探索または調査し、センサがプローブから返された検出情報を分析する。

パターンもスクリプトであって、１つまたは複数の機器上のデータを収集および処理して、ＣＭＤＢを更新する。パターンは、特定の検出プログラミング言語で書かれており、より一般的なプローブおよびセンサでは確実な検出が不可能である（または、一切検出できない）ことが多い特定の機器、構成要素、および／またはアプリケーション上で詳細な検出手順を実行するのに用いられる点において、プローブおよびセンサと異なる。特に、パターンは、特定の配置の機器、構成要素、および／またはアプリケーションの検出方法と、使用する認証情報と、この検証の結果としての設定項目を入力するＣＭＤＢテーブルと、を規定する一連の動作を指定することができる。

いずれのバージョンも、スキャン、分類、識別、および探索という４つの論理的な段階を踏むことができる。また、いずれのバージョンも、検出が行われるマネージドネットワーク３００上のＩＰアドレスの１つまたは複数の範囲の指定を要する場合がある。各段階には、マネージドネットワーク３００上の機器とプロキシサーバ３１２との間のほか、プロキシサーバ３１２とタスクリスト５０２との間の通信を含み得る。いくつかの段階では、一部または予備の設定項目をＣＭＤＢ５００に格納し得るが、これは、後の段階で更新され得る。

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

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

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

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

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

パターンは、識別段階および探索段階においてのみ使用される。パターンベースの検出では、プローブおよびセンサが使用される場合のようにスキャン段階および分類段階が作用する。分類段階の完了後は、識別に使用するプローブとしてパターンプローブが指定される。その後、パターンプローブおよびそれが指定するパターンが起動される。

パターンは、検出プログラミング言語によって、プローブおよびセンサを使用する検出では利用不可能または実現困難な多くの機能をサポートする。たとえば、パターンベースの検出を使用することにより、パブリッククラウドネットワークにおける機器、構成要素、および／またはアプリケーションの検出のほか、設定ファイルの追跡の実現がはるかに容易となる。さらに、これらのパターンは、プローブおよびセンサよりも容易に、ユーザがカスタマイズ可能である。また、パターンは、特定の機器、構成要素、および／またはアプリケーションにより焦点を合わせているため、プローブおよびセンサが使用するより一般的な手法よりも高速に実行可能である。

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

さらに、ＣＭＤＢ５００は、設定項目間の関係に関するエントリを含んでいてもよい。より具体的には、サーバ機器が多くのハードウェアコンポーネント（たとえば、プロセッサ、メモリ、ネットワークインターフェース、ストレージ、およびファイルシステム）を含み、これらにおいて複数のソフトウェアアプリケーションがインストールまたは実行されるものとする。構成要素とサーバ機器との間の関係（たとえば、「包含」関係）およびソフトウェアアプリケーションとサーバ機器との間の関係（たとえば、「実行」関係）は、ＣＭＤＢ５００においてそのように表され得る。

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

このように、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００上で展開されて提供されるハードウェアおよびソフトウェアを検出して一覧化することができる。

Ｂ．垂直検出
垂直検出は、ウェブサービス等の全体サービスの一部である設定項目の探索およびマッピングに用いられる技術である。たとえば、垂直検出では、ウェブサーバアプリケーション、ＬＩＮＵＸ（登録商標）サーバ機器、およびウェブサービス用のデータを格納するデータベース間の関係を示すことによって、ウェブサービスをマッピングすることができる。通常は、設定項目およびそれらの間の基本的関係を見出すために水平検出が最初に実行された後、サービスを構成する設定項目間の関係を確立するために垂直検出が実行される。

パターンの使用によって、特定の種類のサービスを検出することができる。これらのパターンは、サービスの展開の様子に関する記述に適合するハードウェアおよびソフトウェアの特定の配置を探索するようにプログラム可能なためである。この代替または追加として、トラフィック分析（たとえば、機器間のネットワークトラフィックの調査）の使用により、垂直検出を容易化することも可能である。場合によっては、垂直検出の補助となるように、サービスのパラメータを手動で設定することも可能である。

一般的に、垂直検出では、機器、構成要素、および／またはアプリケーション間の特定の種類の関係を見つけようとする。これらの関係のうちのいくつかは、設定ファイルから推測され得る。たとえば、ウェブサーバアプリケーションの設定ファイルは、それが依拠するデータベースのＩＰアドレスおよびポート番号を表し得る。垂直検出パターンは、このような参照の探索およびそれによる関係の推測を行うようにプログラム可能である。また、機器間のトラフィックから関係を推測することも可能である。たとえば、負荷分散器とウェブサーバをホストする機器との間で大量のウェブトラフィック（たとえば、ＴＣＰポート８０または８０８０）が往来している場合は、負荷分散器およびウェブサーバが何らかの関係を有すると考えられる。

垂直検出により見出される関係は、さまざまな形態であってもよい。一例として、電子メールサービスは、それぞれが異なるハードウェア機器設定項目にインストールされた電子メールサーバソフトウェア設定項目およびデータベースアプリケーションソフトウェア設定項目を含み得る。電子メールサービスがこれらのソフトウェア設定項目との「依存」関係を有し得る一方、ソフトウェア設定項目は、電子メールサービスと「使用」の相互関係を有する。このようなサービスは、水平検出手順では完全に決定できない可能性もあるため、代わりに、垂直検出および場合によりある程度の手動設定に依拠していてもよい。

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

別の例においては、データベースアプリケーションがサーバ機器上で実行されており、また、このデータベースアプリケーションが従業員研修サービスのほか、給与計算サービスで使用されるものとする。このため、サーバ機器が保守のため稼働を停止した場合は、従業員研修サービスおよび給与計算サービスが明らかに影響を受けることになる。同様に、設定項目間の依存および関係は、特定のハードウェア機器が故障した場合に影響を受けるサービスを表し得ると考えられる。

一般的に、設定項目および／または設定項目間の関係は、ウェブベースのインターフェースに表示され、階層として表され得る。このインターフェースによって、ＣＭＤＢにおける上記のような設定項目および／または関係の修正が達成され得る。

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

Ｖ．ＣＭＤＢ識別ルールおよび調停
ＣＭＤＢ５００等のＣＭＤＢは、設定項目および関係のレポジトリを提供する。適正に規定された場合は、演算インスタンス内で展開されたより高位のアプリケーションまたは演算インスタンスを含むより高位のアプリケーションにおいて、重要な役割を担うことができる。これらのアプリケーションは、企業のＩＴサービス管理、業務管理、資産管理、設定管理、法令順守等に関連し得る。

たとえば、ＩＴサービス管理アプリケーションは、ＣＭＤＢの情報を使用して、機能不全、機能停止、または高負荷の構成要素（たとえば、サーバ機器）の影響を受ける可能性があるアプリケーションおよびサービスを決定するようにしてもよい。同様に、資産管理アプリケーションは、ＣＭＤＢの情報を使用して、特定の企業アプリケーションのサポートに使用されるハードウェアおよび／またはソフトウェアコンポーネントを決定するようにしてもよい。ＣＭＤＢの重要性の結果として、そこに格納される情報は、正確で一貫性があり、最新であることが望ましい。

ＣＭＤＢへの入力は、さまざまな方法で行うことができる。上述の通り、検出手順では、設定項目および関係を含む情報をＣＭＤＢに自動的に格納するようにしてもよい。ただし、ＣＭＤＢへの入力の全部または一部は、手動入力、設定ファイル、およびサードパーティデータソースにより行うことも可能である。複数のデータソースがいつでもＣＭＤＢを更新可能となり得る点を所与として、あるデータソースが別のデータソースのエントリを上書き可能である。また、２つのデータソースがそれぞれ、同じ設定項目に対してわずかに異なるエントリを生成するようにしてもよく、その結果、ＣＭＤＢが重複データを含むことになる。これらのいずれかが発生すると、ＣＭＤＢの健全性および有用性が低下し得る。

この状況を緩和するため、これらのデータソースは、設定項目を直接はＣＭＤＢに書き込まない可能性もある。代わりに、ＩＲＥ５１４の識別・調停アプリケーションプログラミングインターフェース（ＡＰＩ）に書き込むようにしてもよい。その後、ＩＲＥ５１４が一組の設定可能な識別ルールを使用することにより、設定項目を一意に識別するとともに、ＣＭＤＢへの書き込みの有無およびその方法を判定するようにしてもよい。

一般的に、識別ルールは、この一意の識別に使用可能な一組の設定項目属性を指定する。また、識別ルールには優先順位があり、優先順位の高いルールが優先順位の低いルールの前に考慮されるようになっていてもよい。また、ルールは、設定項目を他の設定項目とは独立に識別する点において、独立したものと考えられる。あるいは、ルールは、最初にメタデータルールを使用して依存する設定項目を識別する点において、依存したものと考えられる。

メタデータルールは、特定の設定項目に含まれる他の設定項目または特定の設定項目が展開されるホストを記述する。たとえば、ネットワークディレクトリサービス設定項目がドメインコントローラ設定項目を含み得る一方、ウェブサーバアプリケーション設定項目は、サーバ機器設定項目にホストされていてもよい。

各識別ルールの目標は、設定項目を他のすべての設定項目から明確に区別することができ、設定項目の存続期間に変化しないと予想される属性の組み合わせを使用することである。例示的なサーバ機器に対して考え得る属性としては、シリアル番号、場所、オペレーティングシステム、オペレーティングシステムバージョン、メモリ容量等が挙げられる。設定項目を一意に識別しない属性をルールが指定する場合は、ＣＭＤＢにおいて、複数の構成要素が同じ設定項目として表される可能性もある。また、特定の設定項目に対して変化する属性をルールが指定する場合は、重複設定項目が生成される可能性もある。

したがって、データソースが設定項目に関する情報をＩＲＥ５１４に提供する場合、ＩＲＥ５１４は、この情報を１つまたは複数のルールと照合しようとする可能性がある。一致が見られる場合は、設定項目がＣＭＤＢに書き込まれるか、ＣＭＤＢに既存の場合は更新される。一致が見られない場合は、設定項目が別途分析のため保持され得る。

権限のあるデータソースのみがＣＭＤＢの設定項目データの上書きを許可されるように、設定項目調停手順が用いられるようになっていてもよい。この調停についても、ルールベースであってもよい。たとえば、特定の設定項目種別および一組の属性に対して特定のデータソースが権限を有するように調停ルールが指定してもよい。そして、この権限のあるデータソースによる特定の設定項目への書き込みのみをＩＲＥ５１４が許可する可能性もあり、不正なデータソースによる書き込みが防止され得る。このように、正規のデータソースは、特定の設定項目に関する唯一の真実の情報源となる。場合によっては、不正なデータソースが設定項目を生成している場合、または、書き込んでいる属性が空である場合に、設定項目への書き込みを許可される可能性がある。

また、複数のデータソースが同じ設定項目またはその属性に対する権限を有する場合もある。明瞭化のため、これらのデータソースには、設定項目の書き込み時に考慮される優先権が割り当てられていてもよい。たとえば、第１位の権限を有するデータソースが設定項目の属性に書き込むまで、第２位の権限を有するデータソースがこの属性に書き込み可能となっていてもよい。その後は、第２位の権限を有するデータソースによる属性へのさらなる書き込みが阻止されるようになっていてもよい。

場合によっては、重複設定項目のＩＲＥ５１４による自動検出または別の方法での検出が可能である。これらの設定項目は、手動での重複排除のため消去されるようになっていてもよいし、フラグ付けされるようになっていてもよい。

ＶＩ．例示的なモデル統合層
図６は、１つまたは複数のアプリケーションビルダを使用して開発されたソフトウェアアプリケーションへの複数の異なる機能の統合を容易化するように構成されている例示的なモデル統合層６００を示している。具体的に、モデル統合層６００は、機能６１０から機能６２２まで（すなわち、機能６１０～６２２）をアプリケーションビルダ６０２からアプリケーションビルダ６０４まで（すなわち、アプリケーションビルダ６０２～６０４）に提供するようにしてもよい。機能６１０～６２２は、モデル統合層６００に代わって、コンピュータシステム６５０からコンピュータシステム６６０まで（すなわち、コンピュータシステム６５０～６６０）が実行するようにしてもよい。このため、モデル統合層６００は、アプリケーションビルダ６０２～６０４とコンピュータシステム６５０～６６０との間のインターフェースを提供するようにしてもよく、このインターフェースは、アプリケーションビルダ６０２～６０４を使用して開発されたソフトウェアアプリケーションによる機能６１０～６２２の使用を容易化するように標準化されていてもよい。

アプリケーションビルダ６０２～６０４の各アプリケーションビルダはそれぞれ、ソフトウェアアプリケーションを規定するためのグラフィカルユーザインターフェースを提供するようにしてもよい。グラフィカルユーザインターフェースは、さまざまな演算を表す複数のグラフィックコンポーネントを含んでいてもよく、これらのグラフィックコンポーネントは、ユーザインターフェースによるドラッグ、クリック、相互接続、および／または他の変更が可能であって、ローコードおよび／またはノーコードのユーザインターフェース操作の使用によるソフトウェアアプリケーションの規定を可能にする。複数のグラフィックコンポーネントの各コンポーネントはそれぞれ、対応するソースコードを表していてもよい。対応するソースコードは、テキストとして明示的には示されない場合もあるが、代わりに、対応するアイコンによるグラフィカルな集約によって、ソフトウェアアプリケーションのローコードおよび／またはノーコード実装を容易化し得る。場合により、各アプリケーションビルダは、数ある可能性の中でもとりわけ、デスクトップアプリケーション、モバイルアプリケーション、および／または仮想アシスタントアプリケーション等、特定の種類および／またはクラスのソフトウェアアプリケーションに固有であってもよい。

モデル統合層６００は、アプリケーションビルダ６０２～６０４および／またはこれにより開発されたソフトウェアアプリケーションによる別個の実施の必要なく、アプリケーションビルダ６０２～６０４による機能６１０～６２２の共有を可能にし得る。機能６１０～６２２の各機能はそれぞれ、対応する入力、対応する出力、対応する入力に実行されて対応する出力を生成する対応する演算、対応する演算を実行するように構成されている１つもしくは複数の対応するモデル、ならびに各機能が有効化されたビルダの対応する指標を含んでいてもよい。たとえば、機能６１０は、入力６１２、出力６１４、演算６１６、モデル６１８、および有効化ビルダ６２０を含んでいてもよい。機能６２２は、入力６２４、出力６２６、演算６２８、モデル６３０、および有効化ビルダ６３２を含んでいてもよい。

入力６１２～６２４は、機能６１０～６２２がそれぞれ予想する入力データのフォーマット、構造、データ型、および／またはサイズ／長さを規定していてもよい。出力６１４～６２６は、機能６１０～６２２がそれぞれ生成する出力データのフォーマット、構造、データ型、および／またはサイズ／長さを規定していてもよい。演算６１６～６２８は、機能６１０～６２２がそれぞれ適用する関数、変換、および／または変更を表していてもよい。モデル６１８～６３０は、演算６１６～６２８をそれぞれ実行することにより機能６１０～６２２をそれぞれ提供するように構成されている特定のソフトウェアおよび／またはハードウェア構造を表していてもよい。いくつかの実施態様においては、対応する演算を提供するようにトレーニングされた人工ニューラルネットワーク等の機械学習モデルとして、モデル６１８～６３０の一部または全部が実装されていてもよい。有効化ビルダ６２０～６３２は、アプリケーションビルダ６０２～６０４のうちの所与のアプリケーションビルダにおける使用に対して、機能６１０～６２２がそれぞれ有効化されているかを示していてもよい。

機能６１０～６２２の各機能はそれぞれ、対応する複数のモデルを使用して実行されるようになっていてもよい。たとえば、機能６１０がモデル６１８を使用して実行され、機能６２２がモデル６３０を使用して実行されるようになっていてもよい。アプリケーションビルダ６０２～６０４の各アプリケーションビルダは、機能６１０～６２２のモデル非依存表現を提供するように構成されていてもよい。たとえば、アプリケーションビルダ６０２は、当該アプリケーションビルダ６０２に対して有効化された機能６１０～６２２の第１の部分集合のモデル非依存機能表現６０６を提供するように構成されていてもよい。アプリケーションビルダ６０４は、当該アプリケーションビルダ６０４に対して有効化された機能６１０～６２２の第２の部分集合のモデル非依存機能表現６０８を提供するように構成されていてもよい。モデル非依存機能表現６０６～６０８は、機能６１０～６２２を表していてもよいが、実行されて機能６１０～６２２を提供する基礎的モデルの詳細の記述を与えていない場合もある。たとえば、モデル非依存機能表現６０６～６０８は、モデル６１８および６３０の一覧化および／または記述を行っていない場合もある。このため、モデル非依存機能表現６０６～６０８は、機能６１０～６２２を提供するモデルの低レベル実装の詳細を省略することによって、ローコードおよび／またはノーコードアプリケーション開発を容易化するようにしてもよい。

マッピング６５４は、対応する機能を提供するように所与のモデルが実行される条件を規定していてもよい。具体的に、マッピング６５４は、モデル統合層６００が利用する各モデルそれぞれについて、実行時に存在する場合に、対応する機能を提供するようにそれぞれのモデルを実行させるように構成されている１つまたは複数の属性値を示していてもよい。機能６１０～６２２の各機能がそれぞれ、対応する複数のモデルを使用して実行され得ることから、マッピング６５４は、各機能の出力データを生成するためのこれらモデルの個別および／または組み合わせでの使用方法を示していてもよい。

たとえば、機能６１０を提供するモデル６１８は、モデル６３４からモデル６３６まで（すなわち、モデル６３４～６３６）を含んでいてもよい。属性値６３８が実行時に決定された場合にモデル６３４が実行され、属性値６４０が実行時に決定された場合にモデル６３６が実行され、（省略記号により示される）他の対応する属性値が実行時に決定された場合にモデル６１８のうちの（省略記号により示される）他のモデルが実行されるようになっていてもよい。機能６２２を提供するモデル６３０は、モデル６４２からモデル６４４まで（すなわち、モデル６４２～６４４）を含んでいてもよい。属性値６４６が実行時に決定された場合にモデル６４２が実行され、属性値６４８が実行時に決定された場合にモデル６６４４が実行され、（省略記号により示される）他の対応する属性値が実行時に決定された場合にモデル６３０のうちの（省略記号により示される）他のモデルが実行されるようになっていてもよい。

モデル６１８～６３０は、コンピュータシステム６５０～６６０によりホストされていてもよい。具体的には、コンピュータシステム６５０がモデル６３４からモデル６５２まで（すなわち、モデル６３４～６２５）をホストし、コンピュータシステム６６０がモデル６３６からモデル６６２まで（すなわち、モデル６３６～６６２）をホストしていてもよい。モデル６３４～６５２および６３６～６６２は、コンピュータシステム６５０～６６０において機能非依存的に分散していてもよい。すなわち、コンピュータシステム６５０のモデル６３４～６５２は、単一の機能ではなく、複数の異なる機能を提供するように構成されていてもよい。このため、機能６１０を提供するモデル６３４がコンピュータシステム６５０により提供され、同じく機能６１０を提供するモデル６３６がコンピュータシステム６６０により提供されていてもよい。

いくつかの実施態様においては、コンピュータシステム６５０～６６０のうちの少なくとも１つがモデル統合層６００と同じネットワークに存在していてもよい。たとえば、モデル統合層６００は、リモートネットワーク管理プラットフォーム３２０および／またはその演算インスタンスによりホストされていてもよい。このため、モデル統合層６００は、既存のネットワーク内モデルのソフトウェアアプリケーションへの統合を容易化するように構成されていてもよい。他の実施態様においては、コンピュータシステム６５０～６６０のうちの１つまたは複数がモデル統合層６００と異なるネットワークに存在していてもよい。たとえば、コンピュータシステム６５０～６６０のうちの上記１つまたは複数は、実行のための１つまたは複数の対応するモデル（専用であってもよいし、オープンソースであってもよい）を提供するサードパーティコンピュータシステム（たとえば、マネージドネットワーク３００またはパブリッククラウドネットワーク３４０）を表していてもよい。このため、モデル統合層６００は、既存のサードパーティモデルのソフトウェアアプリケーションへの統合を容易化するように構成されていてもよい。以上から、モデル統合層６００によれば、既存のネットワーク内モデルおよび既存のサードパーティモデルの独立した実装および／または再実行の必要なく、このようなモデルの両者をソフトウェアアプリケーションが利用可能となるため、ソフトウェア開発プロセスを大幅に高速化可能である。

いくつかの実施態様においては、属性値６３８～６４０が相互に排他的であってもよいため、モデル６１８から１つのモデルを選択することにより、機能６１０が実行時に提供され得る。したがって、機能６１０の出力データは、選択モデルの出力データに等しいと考えられる。他の実施態様においては、属性値６３８～６４０が重複していてもよいため、モデル６１８から１つまたは複数のモデルを選択することにより、機能６１０が実行時に提供され得る。たとえば、複数のモデルが選択されるようになっていてもよく、また、各モデルが入力データを処理して対応する出力データを生成するように構成されていてもよい。複数の選択モデルは、集合体を構成していてもよい。モデル統合層６００は、集合体の各モデルの対応する出力データを組み合わせる（たとえば、平均値、中央値、最小値、最大値等を決定する）ことにより、最終出力データを生成するように構成されていてもよく、また、これをソフトウェアアプリケーションに提供するようにしてもよい。同様に、属性値６４６～６４８が相互に排他的であってもよいし、重複していてもよい。

マッピング６５４は、モデル統合層６００が提供するユーザインターフェースにより変更可能であってもよい。ただし、マッピング６５４は、アプリケーションビルダ６０２～６０４による変更および／またはアプリケーションビルダ６０２～６０４に対する視覚化が可能とならない場合もある。このため、アプリケーションビルダ６０２～６０４およびこれにより開発されたソフトウェアアプリケーションは、機能６１０～６２２を要求するように構成されていてもよいが、これらの機能の提供方法を制御できない場合もある。すなわち、アプリケーションビルダ６０２～６０４およびこれにより開発されたソフトウェアアプリケーションは、実行されて機能６１０～６２２を提供する特定のモデルを選択できない場合もあり、代わりに、モデル統合層６００に依拠してモデル選択を実行するようにしてもよい。変更可能なマッピング６５４と組み合わせて、機能６１０～６２２の標準化されたモデル非依存かつ時間的に一定の表現に依拠することにより、モデル統合層６００は、ソフトウェアアプリケーションビルダおよび／またはソフトウェアアプリケーションでの如何なる変更の実行の必要もなく、当該モデル統合層６００でのモデルの更新を可能にし得る。

属性値６３８～６４０および／または属性値６４６～６４８は、実行時に決定し得るさまざまなパラメータおよび／または変数を含む複数の異なる属性の値を表していてもよい。属性は、機能を要求するソフトウェアアプリケーション、ソフトウェアアプリケーションの規定に使用されたアプリケーションビルダ、モデル統合層６００、および／またはコンピュータシステム６５０～６６０と関連付けられていてもよい。このため、モデル統合層６００は、マッピング６５４を使用して、当該モデル統合層６００により実行時にそれぞれ決定可能となり得る複数の異なる変数に対するモデル選択を調節するようにしてもよい。各組の属性値６３８～６４０および６４６～６４８は、複数の異なる属性の値のさまざまな線形および／または非線形の組み合わせを表していてもよい。

一例として、属性には、ソフトウェアアプリケーションの識別子、ソフトウェアアプリケーションのユーザの識別子、ソフトウェアアプリケーションの規定に使用されたアプリケーションビルダの識別子、および／またはソフトウェアアプリケーションと関連付けられている地理的位置の識別子等、１つまたは複数の機能リクエストソース識別子を含んでいてもよい。このため、機能６１０のためのリクエストと関連付けられているソース識別子に応じて、モデル６１８のうちの異なるモデルにより機能６１０が提供されていてもよく、マッピング６５４は、１つまたは複数のソース識別子の特定に組み合わせに対して使用されるモデルを示している。

別の例として、属性は、ソフトウェアアプリケーションおよび／またはソフトウェアアプリケーションの規定に使用されたアプリケーションビルダと関連付けられているサービスレベルの品質、目標レイテンシ、および／または目標精度等、サービスの品質を表していてもよい。このため、たとえば、低レイテンシのソフトウェアアプリケーションによる出力データの受信が予想される場合にはモデル６３４（小型化および／または並行化がなされている場合もある）により機能６１０が提供され、高レイテンシのソフトウェアアプリケーションによる出力データの受信が予想される場合にはモデル６３６（大型化および／または順次実行がなされている場合もある）により機能６１０が提供されるようになっていてもよい。以上から、機能６１０～６２２の少なくとも一部について、各機能を提供するモデルは、サイズ、精度、レイテンシ、および／または基礎となるハードウェアが異なっていてもよいため、数ある特性の中でもとりわけ、結果の精度、実行速度、および／または演算リソースの利用が異なっていてもよい。

別の例として、属性は、実行時の演算リソース（モデル統合層６００および／またはコンピュータシステム６５０～６６０の演算リソースを含む）の利用を表していてもよい。このため、モデル統合層６００は、所与の機能を提供するように構成されている複数のモデル間で当該機能のためのリクエストを負荷分散するように構成されていてもよい。たとえば、モデル統合層６００は、数ある可能性の中でもとりわけ、ラウンドロビン割り当て、最小接続割り当て、リソースベースの割り当て、ハッシュベースの割り当て、および／またはこれらの重み付け変形を使用することにより、モデル６３０間で機能６２２のためのリクエストを分散するように構成されていてもよい。この代替または追加として、モデル統合層６００は、大略的および／もしくは実質的に等しく、ならびに／または、単一のコンピュータシステムの過負荷なく、異なるコンピュータシステムのモデルおよび／または演算リソースが利用されるように、コンピュータシステム６５０～６６０間で異なる機能のためのリクエストを負荷分散するように構成されていてもよい。

さらに別の例として、属性には、モデル固有の入力データを含んでいてもよい。たとえば、機能６１０～６２２のうちの所与の機能の入力データには、１つもしくは複数の所要入力ならびにゼロ以上の任意選択としての入力を含んでいてもよい。所与の機能のモデルの第１の部分集合が所要入力のみを処理するように構成される一方、所与の機能のモデルの第２の部分集合が所要入力および任意選択としての入力の両者を処理するように構成されていてもよい。このため、実行時に少なくとも１つの任意選択としての入力が与えられている場合、マッピング６５４は、第２の部分集合からのモデルの選択により、出力データの生成において、任意の所要入力および少なくとも１つの任意選択としての入力を選択モデルが考慮し得るように構成されていてもよい。

いくつかの実施態様において、所与の機能の異なるモデルの入力および／または出力は、異なっていてもよい。したがって、所与の機能に対する標準化されたインターフェースを提供するため、モデル統合層６００は、（ｉ）所与の機能に対する標準化された機能固有入力を選択モデルのモデル固有入力に変換し、（ｉｉ）選択モデルからのモデル固有出力を当該機能に対する標準化された機能固有出力に変換するように構成されていてもよい。すなわち、モデル統合層６００は、アプリケーションビルダ６０２～６０４および／またはこれにより開発されたソフトウェアアプリケーションに対して、如何なるモデル固有変形も明らかとならないように、入力データおよび／または出力データのフォーマットを変更するように構成されていてもよい。

ＶＩＩ．例示的な機能定義および実行
図７Ａは、モデル統合層６００が提供する機能の定義と関連する演算のメッセージフロー図であり、図７Ｂは、機能の実行と関連する演算のメッセージフロー図である。図７Ａは、アプリケーションビルダ６０２～６０４の代表例としてアプリケーションビルダ６０２を示しており、図７Ｂは、モデル６１８～６３０の代表例としてモデル７０２を示している。

図７Ａを参照して、モデル統合層６００は、ブロック７０４で示すように、機能の定義を決定するように構成されていてもよい。機能の定義には、少なくとも機能の入力、機能の出力、および入力に実行されて出力を生成する演算を含んでいてもよい。機能固有入力データフォーマットとの入力の関連付けおよび／または機能固有出力データフォーマットとの出力の関連付けが可能である。機能の定義は、モデル統合層６００により利用可能な機能を追跡するため、モデル統合層６００と関連付けられているデータベースに格納されていてもよい。

ブロック７０４における機能の定義の決定に基づいて、および／または、ブロック７０４における機能の定義の決定に応答して、モデル統合層６００は、ブロック７０６で示すように、機能を提供するように構成されている複数のモデルを決定するように構成されていてもよい。複数のモデルを決定することは、モデル統合層６００と関連付けられているネットワークならびに／または１つもしくは複数のサードパーティネットワークの検索によって、機能を提供するように構成され、機能の提供に利用可能なモデルを識別することを含んでいてもよい。いくつかの実施態様において、ブロック７０６および７０４の演算は、機能の決定前にモデルが識別された状態で予約されていてもよい。

また、複数のモデルを決定することは、複数のモデルの各モデルについて、機能固有入力データフォーマットと各モデルと関連付けられているモデル固有入力データフォーマットとの間の入力データ変換、および／または、各モデルと関連付けられているモデル固有出力データフォーマットと機能固有出力データフォーマットとの間の出力データ変換を規定することを含んでいてもよい。このような入力および出力データ変換によれば、モデル統合層６００は、均一なインターフェースを提供可能となる一方、特定の機能を提供するモデル間で実装を異ならせることができるようになる。

ブロック７０６における複数のモデルの決定に基づいて、および／または、ブロック７０６における複数のモデルの決定に応答して、モデル統合層６００は、ブロック７０８で示すように、機能を提供する複数のモデルのマッピングを決定するように構成されていてもよい。ブロック７０８で決定されるマッピングは、マッピング６５４と同一または同様であってもよい。このため、マッピングは、複数のモデルの各モデルそれぞれについて、機能を提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示していてもよい。ブロック７０８におけるマッピングの決定に基づいて、および／または、ブロック７０８におけるマッピングの決定に応答して、モデル統合層６００は、ブロック７１０で示すように、１つまたは複数のアプリケーションビルダに対して機能を有効化するように構成されていてもよい。

アプリケーションビルダ６０２は、矢印７１２で示すように、当該アプリケーションビルダ６０２に対して有効化された利用可能な機能の表現をモデル統合層６００に要求するように構成されていてもよい。利用可能な機能の表現を要求することは、モデル統合層６００が提供するＡＰＩに対して、第１のＵＲＬにアドレス指定され、アプリケーションビルダ６０２を識別する第１のパラメータを含む第１のリクエストを送信することを含んでいてもよい。矢印７１２におけるリクエストの受信に基づいて、および／または、矢印７１２におけるリクエストの受信に応答して、モデル統合層６００は、矢印７１４で示すように、利用可能な機能の表現をアプリケーションビルダ６０２に提供するように構成されていてもよい。たとえば、モデル統合層６００は、アプリケーションビルダ６０２に対して有効化された機能のリストをデータベースから読み出すように構成されていてもよい。

矢印７１４での利用可能な機能の表現の受信に基づいて、および／または、矢印７１４での利用可能な機能の表現の受信に応答して、アプリケーションビルダ６０２は、ブロック７１６で示すように、機能を選択するように構成されていてもよい。機能は、たとえばアプリケーションビルダ６０２のユーザに利用可能な機能を表示するように構成されているユーザインターフェースによって選択されるようになっていてもよい。この代替または追加として、アプリケーションビルダ６０２は、利用可能な機能をすべて選択するように構成されていてもよい。

ブロック７１６における機能の選択に基づいて、および／または、ブロック７１６における機能の選択に応答して、アプリケーションビルダ６０２は、矢印７１８で示すように、機能の定義をモデル統合層６００に要求するように構成されていてもよい。機能の定義を要求することは、モデル統合層６００が提供するＡＰＩに対して、第２のＵＲＬにアドレス指定され、ブロック７１６で選択された機能を識別する第２のパラメータを含む第２のリクエストを送信することを含んでいてもよい。

矢印７１８におけるリクエストの受信に基づいて、および／または、矢印７１８におけるリクエストの受信に応答して、モデル統合層６００は、矢印７２０で示すように、機能の定義をアプリケーションビルダ６０２に提供するように構成されていてもよい。たとえば、矢印７２０において機能６２２の定義が要求された場合、モデル統合層６００は、たとえばＸＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、および／または別の所定のフォーマットを使用して、少なくとも入力６２４、出力６２６、および演算６２８の表現を提供するように構成されていてもよい。

アプリケーションビルダ６０２は、ブロック７２２で示すように、機能を含むソフトウェアアプリケーションを規定するように構成されていてもよい。アプリケーションビルダ６０２は、ユーザの操作によって機能をソフトウェアアプリケーションに追加するとともに、機能をソフトウェアアプリケーションの他のコンポーネントと相互接続することができるグラフィックアイコンを使用して、機能を表すようにしてもよい。たとえば、アプリケーションビルダ６０２は、ソフトウェアアプリケーションの１つまたは複数の先行コンポーネントを出力を入力として機能に提供することと、機能の出力を入力としてソフトウェアアプリケーションの１つまたは複数の後続コンポーネントに提供することと、を可能にするようにしてもよい。

ソフトウェアアプリケーションの規定に基づいて、および／または、ソフトウェアアプリケーションの規定に応答して、アプリケーションビルダ６０２は、矢印７２４で示すように、ソフトウェアアプリケーションの実行時設定をモデル統合層６００に要求するように構成されていてもよい。実行時設定を要求することは、モデル統合層６００が提供するＡＰＩに対して、第３のＵＲＬにアドレス指定され、機能の定義の一部としてモデル統合層６００が要求する任意のパラメータを含む第３のリクエストを送信することを含んでいてもよい。たとえば、第３のリクエストには、数ある可能性の中でもとりわけ、機能、ソフトウェアアプリケーション、および／またはアプリケーションビルダ６０２の識別子を含んでいてもよい。このため、実行時設定のリクエストは、実行時に、機能を提供するモデルの選択に使用される属性値の少なくとも一部の決定を明確化および／または容易化し得る。

矢印７２４のリクエストの受信に基づいて、および／または、矢印７２４のリクエストの受信に応答して、モデル統合層６００は、ブロック７２６で示すように、実行時設定を生成するように構成されていてもよい。実行時設定は、ソフトウェアアプリケーションを機能の１つまたは複数の実行パラメータにリンクさせるようにしてもよい。すなわち、ソフトウェアアプリケーションが機能の性能を要求する場合は、実行時設定へのアクセスによって、１つまたは複数の実行パラメータを決定するようにしてもよく、また、これら１つまたは複数の実行パラメータに従って、機能が実行されるようになっていてもよい。たとえば、１つまたは複数の実行パラメータは、機能の提供に際してモデル統合層６００が利用するように構成されている演算リソースの量を示していてもよい。また、いくつかの実施態様において、実行時設定の識別子は、特定のアプリケーションが所与の機能へのアクセスを許可されているかをモデル統合層６００が判定できるようにする認証トークンとして動作するようになっていてもよい。

ブロック７２６における実行時設定の生成に基づいて、および／または、ブロック７２６における実行時設定の生成に応答して、モデル統合層６００は、矢印７２８で示すように、実行時設定の識別子をアプリケーションビルダ６０２に提供するように構成されていてもよい。矢印７２８における識別子の受信に基づいて、および／または、矢印７２８における識別子の受信に応答して、アプリケーションビルダ６０２は、ブロック７３０で示すように、識別子をソフトウェアアプリケーションに提供するように構成されていてもよい。識別子は、アプリケーション固有であってもよいため、機能のためのリクエストに際して、ソフトウェアアプリケーションが実行時設定の参照に使用するようにしてもよい。

図７Ｂを参照して、ソフトウェアアプリケーション７００は、図７Ａのブロック７２２において規定されたソフトウェアアプリケーションを表していてもよい。ソフトウェアアプリケーション７００は、矢印７３２で示すように、機能のためのリクエストをモデル統合層６００に提供するように構成されていてもよい。機能のためのリクエストは、機能の入力データおよび実行時設定の識別子を含んでいてもよい。入力データは、機能の機能固有入力データフォーマットにて提供されるようになっていてもよい。

いくつかの実施態様において、矢印７３２におけるリクエストの受信に基づいて、および／または、矢印７３２におけるリクエストの受信に応答して、モデル統合層６００は、矢印７３４で示すように、制御をソフトウェアアプリケーション７００に返すように構成されていてもよい。すなわち、ソフトウェアアプリケーション７００は、モデル統合層６００および／またはモデル７０２に対して非同期的に動作するように構成されていてもよい。他の実施態様において、モデル統合層６００は、要求された機能の出力データが利用可能となるまで、ソフトウェアアプリケーション７００をブロックするように構成されていてもよい。すなわち、ソフトウェアアプリケーション７００は、モデル統合層６００および／またはモデル７０２に対して同期的に動作するように構成されていてもよいため、少なくとも矢印７３２でリクエストを行ったスレッドの制御を取り戻す前に、出力データが利用可能となるまで待つようにしてもよい。

矢印７３２におけるリクエストの受信および／もしくは矢印７３４における制御の返戻に基づいて、ならびに／または、矢印７３２におけるリクエストの受信および／もしくは矢印７３４における制御の返戻に応答して、モデル統合層６００は、ブロック７３６で示すように、実行時属性値を決定するように構成されていてもよい。実行時属性値には、図６に関して論じた属性のいずれかの値を含んでいてもよい。いくつかの実施態様において、モデル統合層６００は、実行時設定の識別子を使用して、実行時属性値の少なくとも一部を決定するように構成されていてもよく、これは、ソフトウェアアプリケーション７００の実行時設定の一部として格納されるようになっていてもよい。

上記の追加または代替として、モデル統合層６００は、実行時設定の識別子を使用して、機能が有効化されたアプリケーションビルダを使用して規定された有効な実行時設定に識別子が対応するかを判定することにより、ソフトウェアアプリケーション７００がモデル統合層６００の使用を許可されているかを判定するように構成されていてもよい。したがって、実行時設定およびその識別子は、制御および／またはセキュリティのための追加層を提供可能であるとともに、許可されていないアプリケーションによるモデル統合層６００の機能の誤用および／または乱用を防止可能である。

ブロック７３６における実行時属性値の決定に基づいて、および／または、ブロック７３６における実行時属性値の決定に応答して、モデル統合層６００は、ブロック７３８で示すように、実行時属性値に基づいて、機能の実行に利用可能な複数のモデルのうちの１つまたは複数のモデルを選択するように構成されていてもよい。ブロック７３８で選択された１つまたは複数のモデルには、モデル７０２を含んでいてもよい。ブロック７３８における１つもしくは複数のモデルの選択に基づいて、および／または、ブロック７３８における１つもしくは複数のモデルの選択に応答して、モデル統合層６００は、矢印７４０で示すように、入力データをモデル７０２に提供するように構成されていてもよい。モデル７０２のモデル固有入力データフォーマットとは異なる機能固有入力データフォーマットにて入力データが提供される場合、モデル統合層６００は、入力データのモデル７０２への提供に先立って、対応する入力データ変換を入力データに適用するように構成されていてもよい。

入力データの受信に基づいて、および／または、入力データの受信に応答して、モデル７０２は、ブロック７４２で示すように、入力データに基づいて出力データを生成するように実行するよう構成されていてもよい。ブロック７４２におけるモデルの実行に基づいて、および／または、ブロック７４２におけるモデルの実行に応答して、モデル７０２は、矢印７４４で示すように、出力データをモデル統合層６００に提供するように構成されていてもよい。

いくつかの実施態様において、ブロック７３８においては、２つ以上のモデルが選択されるようになっていてもよい。したがって、矢印７４０、ブロック７４２，および矢印７４４の演算は、矢印７４６で示すように、他の任意のモデルに対して繰り返されるようになっていてもよい。モデル統合層６００は、ブロック７３８で選択された２つ以上のモデルの各モデルそれぞれから対応する出力データを受信して組み合わせるとともに、各モデルそれぞれからの対応する出力データの組み合わせ（たとえば、平均値、中央値、最小値、最大値等）を表す最終出力データを生成するように構成されていてもよい。

いくつかの実施態様において、矢印７３２におけるリクエストは、複数の機能を同時に指定するとともに、複数の機能間の１つまたは複数の依存関係を示すようにしてもよい。たとえば、矢印７３２におけるリクエストは、（ｉ）入力データを伴う第１の機能、（ｉｉ）第１の機能の出力データを処理するように構成されている第２の機能、および（ｉｉｉ）入力データを伴う第３の機能を指定するようにしてもよい。したがって、第２の機能の実行が第１の機能の出力に依存し得る一方、第３の機能は、第１の機能および第２の機能に依存せず実行可能となり得る。この代替または追加として、いくつかの複数演算機能は、相互に依存する２つ以上の単一演算機能で構成されていてもよい。このため、モデル統合層６００は、矢印７３２において要求される複数の機能間の１つまたは複数の依存関係を表す依存関係グラフを決定するように構成されていてもよく、また、依存関係グラフに従ってこれらの機能を実行するようにしてもよい。具体的には、依存する機能が依存関係の順序で順次実行される一方、依存しない機能は、並行して実行されるようになっていてもよい。

矢印７４４における出力データの受信および／もしくは２つ以上のモデルの対応する出力データの組み合わせに基づいて、ならびに／または、矢印７４４における出力データの受信および／もしくは２つ以上のモデルの対応する出力データの組み合わせに応答して、モデル統合層６００は、矢印７４８で示すように、出力データのモデル非依存表現をソフトウェアアプリケーション７００に提供するように構成されていてもよい。モデル７０２により、モデル統合層６００の機能固有出力データフォーマットとは異なるモデル固有出力データフォーマットにて出力データが提供される場合、モデル統合層６００は、出力データのソフトウェアアプリケーション７００への提供に先立って、出力データ変換を出力データに適用するように構成されていてもよい。

矢印７３４で制御がソフトウェアアプリケーション７００に返されなかった同期実行において、出力データのモデル非依存表現は、矢印７３２でのリクエストに対する応答として提供されるようになってもよい。矢印７３４で制御がソフトウェアアプリケーション７００に返された非同期実行において、出力データのモデル非依存表現は、出力データを非同期で取り扱うためにソフトウェアアプリケーション７００が示すコールバック先に提供されるようになっていてもよい。たとえば、コールバック先は、実行時設定の一部および／または矢印７３２におけるリクエストの一部として指定されていてもよい。この代替または追加として、モデル統合層６００は、ブロック７５０で示すように、出力データのモデル非依存表現をデータベースに格納するように構成されていてもよく、出力データのモデル非依存表現には、ソフトウェアアプリケーション７００および／または他のソフトウェアアプリケーションがアクセス可能であってもよい。

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

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

図８を参照して、ブロック８００は、機能の定義を決定することを含んでいてもよい。定義は、機能の入力、機能の出力、および機能が入力に実行して出力を生成する演算を示していてもよい。

ブロック８０２は、機能を提供するように構成されている複数のモデルを決定することを含んでいてもよい。

ブロック８０４は、機能のモデル非依存表現を提供するように構成されているアプリケーションビルダに機能の定義を提供することを含んでいてもよい。

ブロック８０６は、複数のモデルの各モデルそれぞれについて、アプリケーションビルダを使用して規定されたソフトウェアアプリケーションに機能を実行時に提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示すマッピングを決定することを含んでいてもよい。マッピングは、アプリケーションビルダにより変更不可能であってもよい。

ブロック８０８は、機能を提供するためのリクエストのソフトウェアアプリケーションからの受信に応答して、機能をマッピングに従ってソフトウェアアプリケーションに提供することをさらに含んでいてもよい。

いくつかの実施形態において、機能の定義をアプリケーションビルダに提供することは、複数のアプリケーションビルダから、機能を有効にする１つまたは複数のアプリケーションビルダを選択することを含んでいてもよい。機能は、ビルダ非依存であってもよい。複数のアプリケーションビルダの各アプリケーションビルダはそれぞれ、機能の対応するモデル非依存表現を提供することにより、それぞれのアプリケーションビルダを使用して規定された対応する種類のソフトウェアアプリケーションに機能を含み得るように構成されていてもよい。機能の定義は、１つまたは複数のアプリケーションビルダの各アプリケーションビルダが付加的な機能の統合体を受信する際に使用するように構成されているフォーマットを規定するビルダ設定に従って、各ビルダに提供されるようになっていてもよい。

いくつかの実施形態において、アプリケーションビルダは、ソフトウェアアプリケーションにより実行可能な複数の候補演算の複数のグラフィック表現のユーザ操作に基づいてソフトウェアアプリケーションを規定するためのグラフィカルユーザインターフェースを提供するように構成されていてもよい。機能の定義の受信は、アプリケーションビルダに機能のグラフィック表現をグラフィカルユーザインターフェースに追加させるように構成されていてもよい。

いくつかの実施形態において、複数のモデルを決定することは、複数のモデルの特定のモデルについて、特定のモデルの対応するモデル固有入力を決定することを含んでいてもよい。特定のモデルの１つまたは複数の属性値は、特定のモデルの対応するモデル固有入力が実行時に提供されるかを示していてもよい。

いくつかの実施形態において、１つまたは複数の属性値は、（ｉ）ソフトウェアアプリケーションの識別子、（ｉｉ）ソフトウェアアプリケーションのユーザの識別子、（ｉｉｉ）ソフトウェアアプリケーションの規定に使用されたアプリケーションビルダの識別子、（ｉｖ）ソフトウェアアプリケーションと関連付けられているサービスレベルの品質、（ｖ）ソフトウェアアプリケーションと関連付けられている目標レイテンシ、（ｖｉ）ソフトウェアアプリケーションと関連付けられている地理的位置、または（ｖｉｉ）実行時の演算リソースの利用のうちの１つまたは複数を表していてもよい。

いくつかの実施形態において、複数のモデルは、機能を提供するようにそれぞれが構成されている複数の異なる機械学習モデルを含んでいてもよい。

いくつかの実施形態においては、アプリケーションビルダをホストするネットワークとは異なるサードパーティネットワークによって、複数のモデルのうちの少なくとも１つのモデルがホストされていてもよいし、（ｉ）アプリケーションビルダならびに（ｉｉ）複数のモデルのうちの１つまたは複数のモデルがそれぞれ、同じネットワーク上でホストされていてもよい。

いくつかの実施形態において、機能のモデル非依存表現は、機能の単一共有記述を使用して複数のモデルを記述していてもよい。単一共有記述は、複数のモデルのうちの異なるモデル間の差異の記述を含まなくてもよい。

いくつかの実施形態において、機能をソフトウェアアプリケーションに提供することは、機能を提供するためのリクエストの受信に応答して、ソフトウェアアプリケーションと関連付けられている少なくとも１つの実行時属性値を決定することを含んでいてもよい。機能を提供するためのリクエストは、機能の入力データを含んでいてもよい。少なくとも１つの実行時属性値およびマッピングに基づいて、複数のモデルのうちの第１のモデルが選択されるようになっていてもよい。第１のモデルに入力データを処理させるようにしてもよい。第１のモデルから、出力データが受信されるようになっていてもよい。また、出力データのモデル非依存表現がソフトウェアアプリケーションに提供されるようになっていてもよい。

いくつかの実施形態において、第１のモデルを選択することは、少なくとも１つの実行時属性値およびマッピングに基づいて、複数のモデルのうちの２つ以上のモデルを含むモデル集合体を選択することを含んでいてもよい。第１のモデルに入力データを処理させることは、モデル集合体の各モデルに入力データを処理させることを含んでいてもよい。出力データのモデル非依存表現を受信することは、（ｉ）モデル集合体の各モデルから対応する出力データを受信することと、（ｉｉ）モデル集合体の各モデルからの対応する出力データに基づいて、最終出力データを決定することと、を含んでいてもよい。出力データを提供することは、最終出力データのモデル非依存表現を提供することを含んでいてもよい。

いくつかの実施形態においては、機能を提供するためのリクエストの受信に応答して、制御がソフトウェアアプリケーションに返されるようになっていてもよい。出力データのモデル非依存表現を提供することは、第１のモデルからの出力データの受信に応答して、出力データを非同期で取り扱うためにソフトウェアアプリケーションが示すコールバック先に出力データのモデル非依存表現を提供することを含んでいてもよい。

いくつかの実施形態において、ソフトウェアアプリケーションは、機能を提供するためのリクエストを送信した後に出力データを待つように構成されていてもよい。出力データのモデル非依存表現を提供することは、第１のモデルからの出力データの受信に応答して、機能を提供するためのリクエストへの応答として出力データのモデル非依存表現を提供することを含んでいてもよい。

いくつかの実施形態においては、機能を提供するためのリクエストの受信に応答して、制御がソフトウェアアプリケーションに返されるようになっていてもよい。出力データのモデル非依存表現を提供することは、第１のモデルからの出力データの受信に応答して、ソフトウェアアプリケーションと関連付けられているデータベースに出力データのモデル非依存表現を格納することを含んでいてもよい。

いくつかの実施形態において、機能をソフトウェアアプリケーションに提供することは、機能を提供するためのリクエストの受信に応答して、複数のモデルそれぞれによる演算リソースの実行時利用を示す少なくとも１つの実行時属性値を決定することを含んでいてもよい。また、機能をソフトウェアアプリケーションに提供することは、少なくとも１つの実行時属性値およびマッピングに基づいて、機能のソフトウェアアプリケーションへの提供に使用される複数のモデルのうちの第１のモデルを選択することを含んでいてもよい。第１のモデルの選択は、複数のモデルにわたる機能のためのリクエストの負荷分散に寄与するようになっていてもよい。

いくつかの実施形態において、機能の定義をアプリケーションビルダに提供することは、アプリケーションビルダから、アプリケーションプログラミングインターフェース（ＡＰＩ）により、アプリケーションビルダに利用可能な機能の識別のための第１のリクエストを受信することを含んでいてもよい。第１のリクエストの受信に基づいて、ＡＰＩにより、アプリケーションビルダに利用可能な複数の機能を識別する第１の応答がアプリケーションビルダに提供されるようになっていてもよい。複数の機能の各機能それぞれについて、アプリケーションビルダから、ＡＰＩにより、各機能の対応する定義の対応する第２のリクエストが受信されるようになっていてもよい。複数の機能の各機能それぞれについて、対応する第２のリクエストの受信に基づいて、ＡＰＩにより、各機能の対応する定義を含む対応する第２の応答がアプリケーションビルダに提供されるようになっていてもよい。対応する定義は、（ｉ）各機能の対応する入力、（ｉｉ）各機能の対応する出力、および（ｉｉｉ）各機能が対応する入力に実行して対応する出力を生成する対応する演算を示していてもよい。

いくつかの実施形態において、アプリケーションビルダから、ＡＰＩにより、ソフトウェアアプリケーションの実行時設定の生成のためのリクエストが受信されるようになっていてもよい。実行時設定は、ソフトウェアアプリケーションを機能の１つまたは複数の実行パラメータにリンクさせるようにしてもよい。実行時設定は、ソフトウェアアプリケーションに対して生成されるようになっていてもよい。ＡＰＩにより、ソフトウェアアプリケーションの実行時設定の識別子がアプリケーションビルダに送信されるようになっていてもよい。機能をソフトウェアアプリケーションに提供することは、ソフトウェアアプリケーションから、ＡＰＩにより、実行時設定と関連付けられている識別子を受信することと、１つまたは複数の実行パラメータに基づいて機能を実行することと、を含んでいてもよい。

いくつかの実施形態において、機能は、アプリケーションビルダに提供され、ソフトウェアアプリケーションに含まれる複数の機能のうちの１つであってもよい。機能をソフトウェアアプリケーションに提供することは、ソフトウェアアプリケーションから、複数の機能のうちの２つ以上の機能を実行するためのリクエストを受信することと、２つ以上の機能間の１つまたは複数の依存関係を決定することと、１つまたは複数の依存関係に基づく順序で２つ以上の機能を実行することと、を含んでいてもよい。

いくつかの実施形態において、複数のモデルを決定することは、複数のモデルの各モデルについて、（ｉ）機能の入力の機能固有入力データフォーマットと各モデルのモデル固有入力データフォーマットとの間の入力データ変換と、（ｉｉ）各モデルのモデル固有出力データフォーマットと出力の機能固有出力データフォーマットとの間の出力データ変換と、を決定することを含んでいてもよい。機能をソフトウェアアプリケーションに提供することは、ソフトウェアアプリケーションから受信した入力データの各モデルへの提供に先立って、入力データ変換を入力データに適用することと、出力データ変換を各モデルから受信した出力データに適用することと、を含んでいてもよい。

図９を参照して、ブロック９００は、ソフトウェアアプリケーションから、機能をソフトウェアアプリケーションに提供するためのリクエストを受信することを含んでいてもよい。リクエストは、機能の入力データを含んでいてもよい。機能は、入力データに演算を実行して出力データを生成するように構成されていてもよい。ソフトウェアアプリケーションは、当該ソフトウェアアプリケーションへの統合のため、機能のモデル非依存表現を提供するように構成されているアプリケーションビルダを使用して規定されていてもよい。

ブロック９０２は、機能を提供するためのリクエストの受信に応答して、ソフトウェアアプリケーションと関連付けられている少なくとも１つの実行時属性値を決定することを含んでいてもよい。

ブロック９０４は、少なくとも１つの実行時属性値およびマッピングに基づいて、機能を提供するように構成されている複数のモデルから第１のモデルを選択することを含んでいてもよい。マッピングは、複数のモデルの各モデルそれぞれについて、ソフトウェアアプリケーションに対して機能を実行時に提供するようにそれぞれのモデルを実行させる１つまたは複数の属性値を示していてもよい。マッピングは、アプリケーションビルダにより変更不可能であってもよい。

ブロック９０６は、第１のモデルにソフトウェアアプリケーションから受信した入力データを処理させることを含んでいてもよい。

ブロック９０８は、第１のモデルから出力データを受信することを含んでいてもよい。

ブロック９１０は、出力データのモデル非依存表現をソフトウェアアプリケーションに提供することを含んでいてもよい。

上述の通り、図８に関連する実施形態を含む上述の任意の実施形態の特徴を図９の特徴とさまざまに統合可能である。

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

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

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

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

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

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

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

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

１０１ コンピュータ機器
１０２ プロセッサ
１０４ メモリ
１０４Ａ ファームウェア
１０４Ｂ カーネル
１０４Ｃ アプリケーション
１０６ ネットワークインターフェース
１０８ 入力／出力ユニット
１１０ システムバス
２００ サーバクラスタ
２０２ サーバ機器
２０４ データストレージ
２０６ ルータ
２０８ ローカルクラスタネットワーク
２１０ 通信リンク
２１２ ネットワーク
３００ マネージドネットワーク
３０２ クライアント機器
３０４ サーバ機器
３０６ ルータ
３０８ 仮想マシン
３１０ ファイアウォール
３１２ プロキシサーバ
３２０ リモートネットワーク管理プラットフォーム
３２２ 演算インスタンス
３２４ 演算インスタンス
３２６ 演算インスタンス
３２８ 演算インスタンス
３４０ パブリッククラウドネットワーク
３５０ インターネット
４００Ａ データセンタ
４００Ｂ データセンタ
４０２Ａ ＶＰＮゲートウェイ
４０２Ｂ ＶＰＮゲートウェイ
４０４Ａ ファイアウォール
４０４Ｂ ファイアウォール
４０６Ａ 負荷分散器
４０６Ｂ 負荷分散器
４１０ 設定項目
４１２ ＶＰＮゲートウェイ
４１４ ユーザ
４１６ リモートユーザ
５００ ＣＭＤＢ
５０２ タスクリスト
５０４ 機器
５０６ 機器
５０８ 機器
５１０ 機器
５１２ 機器
５１４ ＩＲＥ
６００ モデル統合層
６０２ アプリケーションビルダ
６０４ アプリケーションビルダ
６０６ モデル非依存機能表現
６０８ モデル非依存機能表現
６１０ 機能
６１２ 入力
６１４ 出力
６１６ 演算
６１８ モデル
６２０ 有効化ビルダ
６２２ 機能
６２４ 入力
６２６ 出力
６２８ 演算
６３０ モデル
６３２ 有効化ビルダ
６３４ モデル
６３６ モデル
６３８ 属性値
６４０ 属性値
６４２ モデル
６４４ モデル
６４６ 属性値
６４８ 属性値
６５０ コンピュータシステム
６５２ モデル
６５４ マッピング
６６０ コンピュータシステム
６６２ モデル
７００ ソフトウェアアプリケーション
７０２ モデル

Claims (20)

1. 機能の定義を決定することであり、前記定義が、前記機能の入力、前記機能の出力、および前記機能が前記入力に実行して前記出力を生成する演算を示す、ことと、
   前記機能を提供するように構成されている複数のモデルを決定することと、
   前記機能のモデル非依存表現を提供するように構成されているアプリケーションビルダに前記機能の前記定義を提供することと、
   前記複数のモデルの各モデルそれぞれについて、前記アプリケーションビルダを使用して規定されたソフトウェアアプリケーションに前記機能を実行時に提供するように前記それぞれのモデルを実行させる１つまたは複数の属性値を示すマッピングを決定することであり、前記マッピングが、前記アプリケーションビルダにより変更不可能である、ことと、
   前記機能を提供するためのリクエストの前記ソフトウェアアプリケーションからの受信に応答して、前記機能を前記マッピングに従って前記ソフトウェアアプリケーションに提供することと、
   を含む、方法。
2. 前記機能の前記定義を前記アプリケーションビルダに提供することが、
   複数のアプリケーションビルダから、前記機能を有効にする１つまたは複数のアプリケーションビルダを選択することであり、前記機能が、ビルダ非依存であり、前記複数のアプリケーションビルダの各アプリケーションビルダがそれぞれ、前記機能の対応するモデル非依存表現を提供することにより、前記それぞれのアプリケーションビルダを使用して規定された対応する種類のソフトウェアアプリケーションに前記機能を含み得るように構成されている、ことと、
   前記１つまたは複数のアプリケーションビルダの各アプリケーションビルダが付加的な機能の統合体を受信する際に使用するように構成されているフォーマットを規定するビルダ設定に従って、前記機能の前記定義を前記各ビルダに提供することと、
   を含む、請求項１に記載の方法。
3. 前記アプリケーションビルダが、ソフトウェアアプリケーションにより実行可能な複数の候補演算の複数のグラフィック表現のユーザ操作に基づいて前記ソフトウェアアプリケーションを規定するためのグラフィカルユーザインターフェースを提供するように構成されており、前記機能の前記定義の受信が、前記アプリケーションビルダに前記機能のグラフィック表現を前記グラフィカルユーザインターフェースに追加させるように構成されている、請求項１に記載の方法。
4. 前記複数のモデルを決定することが、
   前記複数のモデルの特定のモデルについて、前記特定のモデルの対応するモデル固有入力を決定することであり、前記特定のモデルの前記１つまたは複数の属性値が、前記特定のモデルの前記対応するモデル固有入力が実行時に提供されるかを示す、ことを含む、請求項１に記載の方法。
5. 前記１つまたは複数の属性値が、（ｉ）前記ソフトウェアアプリケーションの識別子、（ｉｉ）前記ソフトウェアアプリケーションのユーザの識別子、（ｉｉｉ）前記ソフトウェアアプリケーションの規定に使用された前記アプリケーションビルダの識別子、（ｉｖ）前記ソフトウェアアプリケーションと関連付けられているサービスレベルの品質、（ｖ）前記ソフトウェアアプリケーションと関連付けられている目標レイテンシ、（ｖｉ）前記ソフトウェアアプリケーションと関連付けられている地理的位置、または（ｖｉｉ）実行時の演算リソースの利用のうちの１つまたは複数を表す、請求項１に記載の方法。
6. 前記複数のモデルが、前記機能を提供するようにそれぞれが構成されている複数の異なる機械学習モデルを含む、請求項１に記載の方法。
7. 前記複数のモデルのうちの少なくとも１つのモデルが、前記アプリケーションビルダをホストするネットワークとは異なるサードパーティネットワークによりホストされるか、または、
   （ｉ）前記アプリケーションビルダならびに（ｉｉ）前記複数のモデルのうちの１つまたは複数のモデルがそれぞれ、同じネットワーク上でホストされる、請求項１に記載の方法。
8. 前記機能の前記モデル非依存表現が、前記機能の単一共有記述を使用して前記複数のモデルを記述しており、前記単一共有記述が、前記複数のモデルのうちの異なるモデル間の差異の記述を含まない、請求項１に記載の方法。
9. 前記機能を前記ソフトウェアアプリケーションに提供することが、
   前記機能を提供するための前記リクエストの受信に応答して、前記ソフトウェアアプリケーションと関連付けられている少なくとも１つの実行時属性値を決定することであり、前記機能を提供するための前記リクエストが、前記機能の入力データを含む、ことと、
   前記少なくとも１つの実行時属性値および前記マッピングに基づいて、前記複数のモデルのうちの第１のモデルを選択することと、
   前記第１のモデルに前記入力データを処理させることと、
   前記第１のモデルから、出力データを受信することと、
   前記出力データのモデル非依存表現を前記ソフトウェアアプリケーションに提供することと、
   を含む、請求項１に記載の方法。
10. 前記第１のモデルを選択することが、前記少なくとも１つの実行時属性値および前記マッピングに基づいて、前記複数のモデルのうちの２つ以上のモデルを含むモデル集合体を選択することを含み、
    前記第１のモデルに前記入力データを処理させることが、前記モデル集合体の各モデルに前記入力データを処理させることを含み、
    前記出力データを受信することが、（ｉ）前記モデル集合体の各モデルから対応する出力データを受信することと、（ｉｉ）前記モデル集合体の各モデルからの前記対応する出力データに基づいて、最終出力データを決定することと、を含み、
    前記出力データの前記モデル非依存表現を提供することが、前記最終出力データのモデル非依存表現を提供することを含む、請求項９に記載の方法。
11. 前記機能を提供するための前記リクエストの受信に応答して、制御が前記ソフトウェアアプリケーションに返され、前記出力データの前記モデル非依存表現を提供することが、
    前記第１のモデルからの前記出力データの受信に応答して、前記出力データを非同期で取り扱うために前記ソフトウェアアプリケーションが示すコールバック先に前記出力データの前記モデル非依存表現を提供することを含む、請求項９に記載の方法。
12. 前記ソフトウェアアプリケーションが、前記機能を提供するための前記リクエストを送信した後に前記出力データを待つように構成されており、前記出力データの前記モデル非依存表現を提供することが、
    前記第１のモデルからの前記出力データの受信に応答して、前記機能を提供するための前記リクエストへの応答として前記出力データの前記モデル非依存表現を提供することを含む、請求項９に記載の方法。
13. 前記機能を提供するための前記リクエストの受信に応答して、制御が前記ソフトウェアアプリケーションに返され、前記出力データの前記モデル非依存表現を提供することが、
    前記第１のモデルからの前記出力データの受信に応答して、前記ソフトウェアアプリケーションと関連付けられているデータベースに前記出力データの前記モデル非依存表現を格納することを含む、請求項９に記載の方法。
14. 前記機能を前記ソフトウェアアプリケーションに提供することが、
    前記機能を提供するための前記リクエストの受信に応答して、前記複数のモデルそれぞれによる演算リソースの実行時利用を示す少なくとも１つの実行時属性値を決定することと、
    前記少なくとも１つの実行時属性値および前記マッピングに基づいて、前記機能の前記ソフトウェアアプリケーションへの提供に使用される前記複数のモデルのうちの第１のモデルを選択することであり、前記第１のモデルの選択が、前記複数のモデルにわたる前記機能のためのリクエストの負荷分散に寄与する、ことと、
    を含む、請求項１に記載の方法。
15. 前記機能の前記定義を前記アプリケーションビルダに提供することが、
    前記アプリケーションビルダから、アプリケーションプログラミングインターフェース（ＡＰＩ）により、前記アプリケーションビルダに利用可能な機能の識別のための第１のリクエストを受信することと、
    前記第１のリクエストの受信に基づいて、前記ＡＰＩにより、前記アプリケーションビルダに利用可能な複数の機能を識別する第１の応答を前記アプリケーションビルダに提供することと、
    前記複数の機能の各機能それぞれについて、
    前記アプリケーションビルダから、前記ＡＰＩにより、前記各機能の対応する定義の対応する第２のリクエストを受信することと、
    前記対応する第２のリクエストの受信に基づいて、前記ＡＰＩにより、前記各機能の対応する定義を含む対応する第２の応答を前記アプリケーションビルダに提供することであり、前記対応する定義が、（ｉ）前記各機能の対応する入力、（ｉｉ）前記各機能の対応する出力、および（ｉｉｉ）前記各機能が前記対応する入力に実行して前記対応する出力を生成する対応する演算を示す、ことと、
    を含む、請求項１に記載の方法。
16. 前記アプリケーションビルダから、アプリケーションプログラミングインターフェース（ＡＰＩ）により、前記ソフトウェアアプリケーションの実行時設定の生成のためのリクエストを受信することであり、前記実行時設定が、前記ソフトウェアアプリケーションを前記機能の１つまたは複数の実行パラメータにリンクさせる、ことと、
    前記ソフトウェアアプリケーションの前記実行時設定を生成することと、
    前記ＡＰＩにより、前記ソフトウェアアプリケーションの前記実行時設定の識別子を前記アプリケーションビルダに送信することであり、前記機能を前記ソフトウェアアプリケーションに提供することが、
    前記ソフトウェアアプリケーションから、前記ＡＰＩにより、前記実行時設定と関連付けられている前記識別子を受信することと、
    前記１つまたは複数の実行パラメータに基づいて前記機能を実行することと、
    を含む、ことと、
    をさらに含む、請求項１に記載の方法。
17. 前記機能が、前記アプリケーションビルダに提供され、前記ソフトウェアアプリケーションに含まれる複数の機能のうちの１つであり、前記機能を前記ソフトウェアアプリケーションに提供することが、
    前記ソフトウェアアプリケーションから、前記複数の機能のうちの２つ以上の機能を実行するためのリクエストを受信することと、
    前記２つ以上の機能間の１つまたは複数の依存関係を決定することと、
    前記１つまたは複数の依存関係に基づく順序で前記２つ以上の機能を実行することと、
    を含む、請求項１に記載の方法。
18. 前記複数のモデルを決定することが、
    前記複数のモデルの各モデルについて、（ｉ）前記機能の前記入力の機能固有入力データフォーマットと前記各モデルのモデル固有入力データフォーマットとの間の入力データ変換と、（ｉｉ）前記各モデルのモデル固有出力データフォーマットと前記出力の機能固有出力データフォーマットとの間の出力データ変換と、を決定することであり、前記機能を前記ソフトウェアアプリケーションに提供することが、
    前記ソフトウェアアプリケーションから受信した入力データの前記各モデルへの提供に先立って、前記入力データ変換を前記入力データに適用することと、
    前記出力データ変換を前記各モデルから受信した出力データに適用することと、
    を含む、ことを含む、請求項１に記載の方法。
19. コンピュータシステムによる実行の際に、
    機能の定義を決定することであり、前記定義が、前記機能の入力、前記機能の出力、および前記機能が前記入力に実行して前記出力を生成する演算を示す、ことと、
    前記機能を提供するように構成されている複数のモデルを決定することと、
    前記機能のモデル非依存表現を提供するように構成されているアプリケーションビルダに前記機能の前記定義を提供することと、
    前記複数のモデルの各モデルそれぞれについて、前記アプリケーションビルダを使用して規定されたソフトウェアアプリケーションに前記機能を実行時に提供するように前記それぞれのモデルを実行させる１つまたは複数の属性値を示すマッピングを決定することであり、前記マッピングが、前記アプリケーションビルダにより変更不可能である、ことと、
    前記機能を提供するためのリクエストの前記ソフトウェアアプリケーションからの受信に応答して、前記機能を前記マッピングに従って前記ソフトウェアアプリケーションに提供することと、
    を含む動作を前記コンピュータシステムに実行させるプログラム命令が格納されている、非一時的コンピュータ可読媒体。
20. ソフトウェアアプリケーションから、機能を前記ソフトウェアアプリケーションに提供するためのリクエストを受信することであり、前記リクエストが、前記機能の入力データを含み、前記機能が、前記入力データに演算を実行して出力データを生成するように構成されており、前記ソフトウェアアプリケーションが、前記ソフトウェアアプリケーションへの統合のため、前記機能のモデル非依存表現を提供するように構成されているアプリケーションビルダを使用して規定されている、ことと、
    前記機能を提供するための前記リクエストの受信に応答して、前記ソフトウェアアプリケーションと関連付けられている少なくとも１つの実行時属性値を決定することと、
    前記少なくとも１つの実行時属性値およびマッピングに基づいて、前記機能を提供するように構成されている複数のモデルから第１のモデルを選択することであり、前記マッピングが、前記複数のモデルの各モデルそれぞれについて、前記ソフトウェアアプリケーションに前記機能を実行時に提供するように前記それぞれのモデルを実行させる１つまたは複数の属性値を示し、前記マッピングが、前記アプリケーションビルダにより変更不可能である、ことと、
    前記第１のモデルに前記ソフトウェアアプリケーションから受信した前記入力データを処理させることと、
    前記第１のモデルから前記出力データを受信することと、
    前記出力データのモデル非依存表現を前記ソフトウェアアプリケーションに提供することと、
    を含む方法。

Images