(57)【特許請求の範囲】
【請求項１】
コンピュータシステムであって、
１つ以上のコンピューティングプロセッサと、
前記１つ以上のコンピューティングプロセッサに通信可能に結合されているコンピューティングメモリと
を備え、
前記コンピューティングメモリは、実行可能な命令を記憶しており、前記命令は、実行時、
前記コンピュータシステム上で実行する第１のサービスオーケストレーション管理機能が、サービスのオーケストレーションが行われるべきことを検出することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、第１のオーケストレーションプロファイルを処理することにより、オーケストレーションのためのサービスノード、サービス層エンティティー、または、サービス能力を識別することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、サービスノードのネットワークにわたって分散されている１つ以上のサービス層エンティティーにわたるサービス能力の混合を自動的に調整することによって、前記第１のオーケストレーションプロファイルを使用して、オーケストレーションのための所望のサービス構成を決定することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、前記第１のオーケストレーションプロファイルが第２のオーケストレーションプロファイルを識別していることを決定することであって、前記第２のオーケストレーションプロファイルは、第２のサービスオーケストレーション管理機能に関連付けられている、ことと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、前記第２のオーケストレーションプロファイルを使用してサービスのオーケストレーションを行うための要求を前記第２のサービスオーケストレーション管理機能に伝送することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、前記第２のオーケストレーションプロファイルを使用する前記要求されたオーケストレーションが行われたという指示を前記第２のサービスオーケストレーション管理機能から受信することと
を含む動作を前記コンピュータシステムに行わせる、コンピュータシステム。
【請求項２】
前記コンピューティングメモリは、実行時、前記第１のオーケストレーションプロファイルを受信することを含むさらなる動作を前記コンピュータシステムに行わせる実行可能な命令を記憶している、請求項１に記載のコンピュータシステム。
【請求項３】
前記第１のオーケストレーションプロファイルを受信することは、オーケストレーションに対する要求を受信することを含み、前記オーケストレーションに対する要求は、前記第１のオーケストレーションプロファイルを含む、請求項２に記載のコンピュータシステム。
【請求項４】
サービスのオーケストレーションが行われるべきことを検出することは、オーケストレーションを行うための要求を受信することを含む、請求項１に記載のコンピュータシステム。
【請求項５】
サービスのオーケストレーションが行われるべきことを検出することは、前記コンピュータシステムが、オーケストレーションをトリガするイベントを検出することを含む、請求項１に記載のコンピュータシステム。
【請求項６】
前記コンピューティングメモリは、実行時、サービスのオーケストレーションが行われるべきことを検出することに応答して、前記第１のオーケストレーションプロファイルを解析し、前記第１のオーケストレーションプロファイルのさらなる処理における使用のためのセマンティック情報を識別することを含むさらなる動作を前記コンピュータシステムに行わせる実行可能な命令を記憶している、請求項１に記載のコンピュータシステム。
【請求項７】
前記第１のオーケストレーションプロファイルを解析し、セマンティック情報を識別することは、セマンティック情報を含むメモリ場所へのコンピュータリンクを識別することを含む、請求項６に記載のコンピュータシステム。
【請求項８】
前記コンピューティングメモリは、実行時、サービスのオーケストレーションが行われるべきことを検出することに応答して、前記第１のオーケストレーションプロファイルを処理することにより、前記第１のオーケストレーションプロファイルにおいて、オーケストレーションが行われるべきときを規定するスケジューリング情報、オーケストレーションが行われるべきことを決定するための規則を規定するポリシー情報、および、前記サービスを受信すべきクライアントについての情報を識別するコンテキスト情報のうちの１つ以上のものを識別することを含むさらなる動作を前記コンピュータシステムに行わせる実行可能な命令を記憶している、請求項１に記載のコンピュータシステム。
【請求項９】
前記第１のオーケストレーションプロファイルを使用して、所望のサービス構成を決定することは、オーケストレーション標的が、サービスノードのネットワーク、サービスノード、サービス層エンティティー、または、サービス能力であることを識別することを含む、請求項１に記載のコンピュータシステム。
【請求項１０】
オーケストレーション標的が、サービスノードのネットワーク、サービスノード、サービス層エンティティー、または、サービス能力であることを識別することは、プロファイルタイプを解析することを含む、請求項９に記載のコンピュータシステム。
【請求項１１】
前記コンピューティングメモリは、実行時、前記第１のオーケストレーションプロファイルを使用して、サービスオーケストレーションを適格とする規則およびコンテキストを決定することを含むさらなる動作を前記コンピュータシステムに行わせる実行可能な命令を記憶している、請求項１に記載のコンピュータシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
（関連出願の引用）
本願は、米国仮特許出願第６２／０１１，７７０号（２０１４年６月１３日出願）の米国特許法§１１９（ｅ）の下での利益を主張し、上記出願の内容は、その全体が参照により本明細書に引用される。
【０００２】
（背景）
サービスとは、ネットワーク環境で利用可能かつアクセス可能にされる、定義された組の機能性または能力を指す。デバイスおよび／またはソフトウェアアプリケーションは、特定のデバイスもしくはアプリケーションのために所望の機能を果たすサービスに要求を伝送する。
【０００３】
サービスは、多種多様の技術的環境で採用される。例えば、サービスは、ウェブ関連技術で広範囲に使用される。特定の機能を伴うウェブサービスは、特定のネットワークアドレスにおいて利用可能にされ得る。特定の機能性を必要とするシステムは、ウェブを介して、要求をウェブサービスに伝送し得、そして、ウェブサービスは、所望の機能を果たす。例示的シナリオでは、ウェブサービスが、そうでなければ適合性のないシステムとデータを交換するために、１つのシステムによって採用され得る。
【０００４】
サービスは、マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）技術の関連でも広く使用される。マシンツーマシン（Ｍ２Ｍ）は、人間の手動支援を伴わずに、ネットワークデバイスが情報を交換し、動作を行うことを可能にする技術を説明するために使用される広義の標識である。モノのインターネット（ＩｏＴ）とは、マシンおよびマシンの構成要素を含むオブジェクトが、一意の識別子と、人間／人間または人間／コンピュータの相互作用を必要とすることなくネットワークを経由してオブジェクト間でデータを自動的に転送する能力とを提供されるシナリオを指す。サービスは、例えば、セキュリティ、課金、およびデータ管理に関連するものを含むＭ２Ｍ能力へのアクセスを提供するために使用される。
【０００５】
サービスは、ネットワークアーキテクチャの「サービス層」内に存在すると考えられる。サービス層は、ネットワーク層の上に位置付けられ、それは、サービス層内のサービスがネットワーク層の能力を利用することを可能にする。サービス層は、クライアントアプリケーション層の下方に位置付けられる。クライアントアプリケーションは、サービスによって利用可能にされる機能性にアクセスするために、サービス層内のサービスに要求を行う。したがって、サービス層は、一組のアプリケーションプログラミングインターフェースおよび下層ネットワーキングインターフェースを通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。
【０００６】
いくつかの組織が、サービス動作のための規格を定義しようとしてきた。例えば、Ｍ２Ｍ通信およびサービスに関して、ｏｎｅＭ２Ｍ、Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）、およびＯＭＡ  Ｌｉｇｈｔｗｅｉｇｈｔ  Ｍ２Ｍ（ＬＷＭ２Ｍ）が、サービス実装の側面を標準化しようと努めてきた。これらの既存のＭ２Ｍ／ＩｏＴサービス層規格（例えば、ｏｎｅＭ２Ｍ、ＯＭＡ、ＬＷＭ２Ｍ）は、ネットワーク内のサービスノード（例えば、サーバ、ゲートウェイ、デバイス）によってホストされる個々のサービス層によってサポートされ得る一組のサービス能力を定義する。
【０００７】
サービスの使用が広く採用されているが、サービスを管理することは、大部分が手動の活動である。サービスを作成および修正することは、多くの場合、所望のサービスを提供するために、適切なデータおよびソフトウェアを個々のマシンにプロビジョンする人間の介入を必要とする。
【発明の概要】
【課題を解決するための手段】
【０００８】
出願人らは、本明細書では、サービスの自動オーケストレーションのためのシステムおよび方法を開示する。開示されるシステムおよび方法は、所望のサービスを提供するように、サービスノードおよびサービス層を自動的に構成し、調整する。オーケストレーションは、ネットワーク内のノード、サービスノード上でホストされるサービス層、サービス層内のサービス能力、および／またはサービス能力の特徴のうちのいずれかならびに／もしくは全てを自動的に構成すること、および調整することを伴い得る。
【０００９】
例示的実施形態では、サービスを定義する情報は、コンピューティングメモリに記憶され、サービスオーケストレーションプロファイルと称される。オーケストレーションプロファイルは、サービスのオーケストレーションを調整するために使用されるメタデータを含む。例示的実施形態では、サービスオーケストレーションプロファイルは、ネットワークレベル、サービスノードレベル、サービスレベル、およびサービス能力レベルを含むサービスアーキテクチャのいくつかの異なるレベルの各々においてサービス構成を定義する属性を記憶する。例示的実施形態では、ネットワークサービスオーケストレーションプロファイルは、サービスノードのネットワークによって提供されるサービスを記述する情報を記憶し得る。別の例示的実施形態では、サービスノードオーケストレーションプロファイルは、１つ以上のサービス層をホストする単一のサービスノードによって提供されるサービスを記述し得る。さらに別の実施例では、サービス層オーケストレーションプロファイルは、単一のサービス層によって提供されるサービスを記述し得る。なおも別の実施例では、サービス能力オーケストレーシンプロファイルは、サービス層内の単一のサービス能力によって提供される特徴を記述する。プロファイル情報は、任意の好適な形式で記憶され、例えば、ＸＭＬ、ＷＳＤＬ、および／またはＪＳＯＮを含む任意の好適な技術を使用し得る。
【００１０】
開示される実施形態の側面によると、オーケストレーションプロファイルは、階層が最高であるネットワークサービスオーケストレーションプロファイル、および階層内が最低レベルであるサービス能力オーケストレーションプロファイルを伴って、互いに階層的に関連し得る。階層内のプロファイルは、階層内でそれの上方の１つ以上の親プロファイルにリンクされ得る。同様に、一番下に常駐するサービス能力オーケストレーションプロファイルを除いて、各プロファイルは、階層内でより低くそれにリンクされたプロファイルを有し得る。
【００１１】
例示的実施形態では、１つ以上のオーケストレーション管理機能が、オーケストレーションプロファイルに記憶されるような所望のサービスについての情報を使用して、サービスのオーケストレーションを行うために、採用される。オーケストレーション管理機能は、コンピューティングハードウェア上で実行され、サービスの能力、レベル、およびネットワークを構成するために動作する、ソフトウェアアプリケーションである。一例示的実施形態では、単一のオーケストレーション管理機能は、複数の構成ファイルで定義されるようなサービスの構成を行う責任があり得る。別の実施形態では、各々が特定のオーケストレーションプロファイルの中で規定される構成を行う複数のオーケストレーション管理機能が、ネットワーク内で分散され得る。
【００１２】
例示的シナリオでは、サービスレベルノードのネットワーク内のいくつかのノードの各々は、コンピューティングメモリに記憶されたオーケストレーション管理プロファイルを有し、その上で実行されるオーケストレーション管理機能を有し得る。オーケストレーション管理機能は、オーケストレーション管理プロファイルの中の情報と一致するサービスのオーケストレーションを行うように協働する。例示的シナリオでは、第１のコンピュータシステムまたはノード上で実行される第１のサービスオーケストレーション管理機能もしくはアプリケーションは、サービスのオーケストレーションが行われるべきことを検出する。例示的シナリオでは、第１のコンピュータシステムは、オーケストレーションを行うための要求を受信する結果として、オーケストレーションが必要とされることを検出し得る。要求は、要求される構成を規定する第１のサービスオーケストレーションプロファイルを含み得る。代替実施形態では、オーケストレーション管理機能は、ノードにおける状況の変化の結果として、オーケストレーションが必要とされることを検出し得る。特定の状況は、特定のノード上に記憶されているオーケストレーションプロファイルの中で定義され得る。
【００１３】
サービスオーケストレーションが行われるべきことを検出することに応答して、第１のコンピュータシステム上で実行する第１のサービスオーケストレーション管理アプリケーションは、第１のオーケストレーションプロファイルを処理し、行われるべき構成に関する情報を識別する。上記のように、第１の構成プロファイルは、要求とともに受信されていることもある。代替として、第１の構成プロファイルは、第１のノード上で前もって記憶されていることもある。例示的実施形態では、第１のサービスオーケストレーション管理アプリケーションは、構成に関する情報を識別するために、第１のサービスオーケストレーションプロファイルの中の情報を解析する。情報は、例えば、プロファイル情報のコンテンツの記述を規定する情報、オーケストレーション情報が適用される標的マシンまたは層、スケジューリング情報、ポリシー情報、コンテキスト情報、所望のサービスに関する情報、およびサービスのオーケストレーションに関連する任意の他の情報を含み得る。
【００１４】
第１のコンピュータシステム上で実行する第１のサービスオーケストレーション管理アプリケーションは、第１のオーケストレーションプロファイルを使用して、オーケストレーションのための所望のサービス構成を識別する。例えば、第１のサービスオーケストレーション管理アプリケーションは、オーケストレーションプロファイルがネットワーク内のサービスノード構成の所望の混合および分布を規定することを決定し得る。さらなる実施例として、アプリケーションは、オーケストレーションプロファイルが、サービスノードの所望の構成、サービス層の所望の構成、またはサービス能力の所望の構成を規定することを決定し得る。
【００１５】
第１のサービスオーケストレーション管理機能は、所望のサービス構成を実装するために、コンピュータシステム上で適切な措置を講じる。例えば、第１のサービスオーケストレーション管理アプリケーションは、第１のコンピュータシステム上のサービス層インスタンスの数を修正し得る。別の例示的シナリオでは、第１のサービスオーケストレーション管理アプリケーションは、特定のサービス層に関連付けられる能力を修正し得る。なおも別の例示的シナリオでは、第１のサービスオーケストレーション管理アプリケーションは、特定のサービス能力に関連付けられる特徴を修正し得る。
【００１６】
ある場合には、第１のサービスオーケストレーション管理機能は、要求されたオーケストレーションが別のオーケストレーション管理機能によるオーケストレーションを必要とすることを決定し得る。上で説明されるように、各プロファイルが提供されたサービスの構成のいくつかの側面を規定する、サービス層ネットワークで使用される複数のオーケストレーションプロファイルがあり得る。さらに、サービスプロファイルは、より高いレベルのプロファイルが、より低いレベルのプロファイルによって提供されるオーケストレーションに依拠するように、関連し得る。したがって、オーケストレーションプロファイルの処理中、第１のサービスオーケストレーション管理機能は、オーケストレーションが第２のオーケストレーション管理機能によるオーケストレーションを必要とすることを決定し得る。例示的シナリオでは、第１のオーケストレーション管理機能は、必要オーケストレーションを実装するために第２のオーケストレーション管理機能が必要とされるという指示を提供する、第１のオーケストレーションプロファイルの中の第２のオーケストレーションプロファイルの参照を見出し得る。
【００１７】
例示的実施形態では、第１のサービスオーケストレーション管理アプリケーションは、要求を第２のサービスオーケストレーション管理アプリケーションに伝送する。第２のサービスオーケストレーション管理アプリケーションは、同一の物理的ノードまたはマシン上に位置し得るか、もしくは物理的に別個のノードまたはマシン上に位置し得る。
【００１８】
要求を受信すると、第２のサービスオーケストレーション管理アプリケーションは、第２のサービスオーケストレーションプロファイルを参照し、所望のサービスを決定する。第２のサービス管理アプリケーションは、第２のサービスオーケストレーションプロファイルと一致するサービス関連特徴を構成する。例えば、第２のサービス管理アプリケーションは、サービス能力に関連付けられる組の特徴を修正し得る。別の実施例では、第２のサービス管理アプリケーションは、特定のサービス層に関連付けられる能力を修正し得る。
【００１９】
第２のサービスプロファイルの中の情報と一致するサービス関連特徴の構成を完了すると、第２のサービスオーケストレーション管理機能は、状態または応答を生成し、第１のサービスオーケストレーション管理機能に伝送する。応答は、例えば、要求されたオーケストレーションが失敗なく完了したかどうかを含む、任意の関連情報を含む。
【００２０】
第２のサービスオーケストレーション管理機能からの応答の受信時、かつ任意の他のサービス構成を完了した後、第１のサービスオーケストレーション管理機能は、別のマシンまたはオーケストレーション管理機能からの要求に応答して、オーケストレーションが行われた程度に、応答を生成して伝送する。
【００２１】
本明細書に開示されるような自動サービスオーケストレーションは、ネットワーク内のアプリケーションがサービス層を構成／カスタマイズすることを可能にすること、および各サービス層インスタンス上でホストされる組のサービス能力を調整するようにサービス層インスタンスが互いに協力することを可能にすること等の付加価値特徴をサポートするために使用され得る。そうすることで、サービスオーケストレーションは、例えば、個々のアプリケーションの必要性を満たすために構成され得る、仮想サービス層を作成するために使用されることができる。
【００２２】
開示されるシステムおよび方法は、例えば、ウェブベースのサービスおよびマシンツーマシンサービスを含む、任意のネットワークサービスと関連して使用され得る。さらに、開示されるシステムおよび方法は、例えば、ＯｎｅＭ２Ｍ、ＯＭＡ、およびＬＷＭ２Ｍを含む、任意の関連規格を使用して実装され得る。
【００２３】
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。他の特徴が、以下で説明される。
本発明は、例えば、以下を提供する。
（項目１）
コンピュータシステムであって、
１つ以上のコンピューティングプロセッサと、
前記１つ以上のコンピューティングプロセッサに通信可能に連結されているコンピューティングメモリと
を備え、
前記コンピューティングメモリは、実行可能命令を記憶しており、前記命令は、実行時、
前記コンピュータシステム上で実行する第１のサービスオーケストレーション管理機能が、サービスのオーケストレーションが行われるべきことを検出することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、第１のオーケストレーションプロファイルを処理し、オーケストレーションのためのサービスノード、サービス層、またはサービス能力を識別することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、前記第１のオーケストレーションプロファイルを使用して、オーケストレーションのための所望のサービス構成を決定することと、
前記コンピュータシステム上で実行する前記第１のサービスオーケストレーション管理機能が、前記第１のオーケストレーションプロファイルが第２のオーケストレーションプロファイルを識別していることを決定することであって、前記第２のオーケストレーションプロファイルは、第２のサービスオーケストレーション管理機能に関連付けられている、ことと、
前記第１のサービスオーケストレーション管理機能が、前記第２のオーケストレーションプロファイルを使用してサービスを編成するための要求を前記第２のサービスオーケストレーション管理機能に伝送することと、
前記第２のオーケストレーションプロファイルを使用する前記要求されたオーケストレーションが行われたという指示を前記第２のサービスオーケストレーション管理機能から受信することと
を含む動作を前記システムに行わせる、コンピュータシステム。
（項目２）
前記コンピューティングメモリは、実行時、前記第１のオーケストレーションプロファイルを受信することを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１に記載のコンピュータシステム。
（項目３）
前記第１のオーケストレーションプロファイルを受信することは、オーケストレーションに対する要求を受信することを含み、前記要求は、前記第１のオーケストレーションプロファイルを含む、項目２に記載のコンピュータシステム。
（項目４）
サービスのオーケストレーションが行われるべきことを検出することは、オーケストレーションを行うための要求を受信することを含む、項目１に記載のコンピュータシステム。
（項目５）
サービスのオーケストレーションが行われるべきことを検出することは、前記コンピュータシステムが、オーケストレーションをトリガするイベントを検出することを含む、項目１に記載のコンピュータ実装方法。
（項目６）
前記コンピューティングメモリは、実行時、サービスのオーケストレーションが行われるべきことを検出することに応答して、前記第１のオーケストレーションプロファイルを解析し、前記オーケストレーションプロファイルのさらなる処理における使用のためのセマンティック情報を識別することを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１に記載のコンピュータシステム。
（項目７）
前記第１のオーケストレーションプロファイルを解析し、セマンティック情報を識別することは、セマンティック情報を含むメモリ場所へのコンピュータリンクを識別することを含む、項目６に記載のコンピュータシステム。
（項目８）
前記コンピューティングメモリは、実行時、サービスのオーケストレーションが行われるべきことを検出することに応答して、前記第１のオーケストレーションプロファイルを処理し、前記第１のオーケストレーションプロファイルにおいて、前記オーケストレーションが行われるべきときを規定するスケジューリング情報、オーケストレーションが行われるべきことを決定するための規則を規定するポリシー情報、および、前記サービスを受信すべきクライアントについての情報を識別するコンテキスト情報のうちの１つ以上のものを識別することを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１に記載のコンピュータシステム。
（項目９）
前記第１のオーケストレーションプロファイルを使用して、所望のサービス構成を決定することは、オーケストレーション標的が、サービスノードのネットワーク、サービスノード、サービス層、またはサービス能力であることを識別することを含む、項目１に記載のコンピュータシステム。
（項目１０）
オーケストレーション標的が、サービスノードのネットワーク、サービスノード、サービス層、またはサービス能力であることを識別することは、プロファイルタイプを解析することを含む、項目９に記載のコンピュータシステム。
（項目１１）
前記コンピューティングメモリは、実行時、前記第１のオーケストレーションプロファイルを使用して、サービスオーケストレーションを適格とする規則およびコンテキストを決定することを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１に記載のコンピュータシステム。
（項目１２）
システムであって、
１つ以上のコンピューティングプロセッサと、
前記１つ以上のコンピューティングプロセッサに通信可能に連結されているコンピューティングメモリと
を備え、
前記コンピューティングメモリは、複数のサービスオーケストレーションプロファイルを記憶しており、前記複数のサービスオーケストレーションプロファイルの各々は、サービス構成を記述する情報を含み、前記コンピューティングメモリは、実行可能命令をさらに記憶しており、前記命令は、実行時、
前記複数のサービスオーケストレーションプロファイルのうちの第１のものから、修正されるべき第１のサービスを識別することと、
前記識別された第１のサービスを修正するための要求を生成することと、
前記複数のサービスオーケストレーションプロファイルのうちの前記第１のものから、前記第１のオーケストレーションプロファイルに関連する第２のオーケストレーションプロファイルを識別することと、
前記第２のオーケストレーションプロファイルと一致する第２のサービスを修正するための要求を生成することと
を含む動作を前記システムに行わせる、システム。
（項目１３）
前記コンピューティングメモリは、実行時、サービスを編成するための要求を受信することであって、前記要求は、前記複数のサービスオーケストレーションプロファイルのうちの前記第１のものを含む、ことを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１２に記載のシステム。
（項目１４）
前記複数のサービスオーケストレーションプロファイルのうちの第１のものから、修正されるべき第１のサービスを識別することは、サービスノードのネットワーク、サービスノード、サービス層、またはサービス能力における修正されるべきサービスを識別することを含む、項目１２に記載のシステム。
（項目１５）
前記識別されたサービスを修正するための要求を生成することは、前記複数のサービスオーケストレーションプロファイルのうちの前記第１のものにおいて規定されている情報を使用して、要求を生成することを含む、項目１２に記載のシステム。
（項目１６）
前記複数のサービスオーケストレーションプロファイルのうちの前記第１のものから、第２のオーケストレーションプロファイルを識別することは、前記第２のオーケストレーションプロファイルと一致する第２のサービスを修正することを要求するために識別することを含む、項目１２に記載のシステム。
（項目１７）
システムであって、
１つ以上のコンピューティングプロセッサと、
前記１つ以上のコンピューティングプロセッサに通信可能に連結されているコンピューティングメモリと
を備え、
前記コンピューティングメモリは、サービスに対するサービス属性を定義する情報を含む第１のサービスプロファイルを記憶しており、前記コンピューティングメモリは、実行可能命令をさらに記憶しており、前記命令は、実行時、
第１のサービスを構成することを決定することと、
前記第１のサービスに対するサービス属性を定義する情報のために、前記第１のサービスプロファイルを処理することと、
前記サービス属性と一致する前記第１のサービスの構成を要求することと
を含む動作を前記システムに行わせる、システム。
（項目１８）
第１のサービスを構成することを決定することは、前記第１のサービスを構成するための要求を受信することを含む、項目１７に記載のシステム。
（項目１９）
前記第１のサービスを構成するための要求を受信することは、前記第１のサービスプロファイルを受信することを含む、項目１８に記載のシステム。
（項目２０）
第１のサービスを構成することを決定することは、前記第１のサービスを構成するイベントトリガを検出することを含む、項目１７に記載のシステム。
（項目２１）
前記第１のサービスプロファイルは、第２のサービスプロファイルを識別する情報を含み、
前記コンピューティングメモリは、実行時、前記第２のサービスプロファイルに一致する第２のサービスを構成するための要求を生成することを含むさらなる動作を前記システムに行わせる実行可能命令を記憶している、項目１７に記載のシステム。
【００２４】
先の概要および以下の例証的実施形態の追加の説明は、添付図面と併せて熟読することによって、より理解され得る。開示されたシステムおよび方法の潜在的実施形態は、描写されるものに限定されないことが理解される。
【図面の簡単な説明】
【００２５】
【図１】図１は、サービス層の相対的位置付けを描写する、例示的プロトコルスタックを描写する。
【図２】図２は、ネットワーク内の例示的サービス層展開を描写する。
【図３】図３は、例示的ｏｎｅＭ２Ｍアーキテクチャを描写する略図である。
【図４】図４は、例示的サービスアーキテクチャを描写する略図である。
【図５】図５は、例示的サービスアーキテクチャを描写する略図である。
【図６】図６は、例示的サービスアーキテクチャを描写する略図である。
【図７】図７は、例示的サービスアーキテクチャを描写する略図である。
【図８】図８は、例示的サービスオーケストレーションアーキテクチャを描写する略図である。
【図９Ａ】図９Ａは、サービスプロファイルの階層配列を描写する略図である。
【図９Ｂ】図９Ｂは、例示的ユーザインターフェースを描写する略図である。
【図１０Ａ】図１０Ａ−１０Ｂは、サービスオーケストレーション中に行われる処理のフロー図を提示する。
【図１０Ｂ】図１０Ａ−１０Ｂは、サービスオーケストレーション中に行われる処理のフロー図を提示する。
【図１１】図１１は、サービスプロファイル公開中に行われる処理のフロー図である。
【図１２】図１２は、サービスプロファイル発見中に行われる処理のフロー図である。
【図１３】図１３は、サービスオーケストレーションのために適合される例示的ｏｎｅＭ２Ｍアーキテクチャを描写する略図である。
【図１４】図１４は、サービスオーケストレーションのために適合される例示的ｏｎｅＭ２Ｍアーキテクチャを描写する略図である。
【図１５】図１５は、共通サービスエンティティに含まれる例示的共通サービス機能を描写する略図である。
【図１６】図１６−２０は、ｏｎｅＭ２Ｍ表記を使用して図示される例示的サービスプロファイルの略図である。
【図１７】図１６−２０は、ｏｎｅＭ２Ｍ表記を使用して図示される例示的サービスプロファイルの略図である。
【図１８】図１６−２０は、ｏｎｅＭ２Ｍ表記を使用して図示される例示的サービスプロファイルの略図である。
【図１９】図１６−２０は、ｏｎｅＭ２Ｍ表記を使用して図示される例示的サービスプロファイルの略図である。
【図２０】図１６−２０は、ｏｎｅＭ２Ｍ表記を使用して図示される例示的サービスプロファイルの略図である。
【図２１Ａ】図２１Ａ−２１Ｂは、ＣＳＥ上でＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２１Ｂ】図２１Ａ−２１Ｂは、ＣＳＥ上でＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２２Ａ】図２２Ａ−２２Ｄは、ＣＳＥのネットワークにわたってＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２２Ｂ】図２２Ａ−２２Ｄは、ＣＳＥのネットワークにわたってＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２２Ｃ】図２２Ａ−２２Ｄは、ＣＳＥのネットワークにわたってＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２２Ｄ】図２２Ａ−２２Ｄは、ＣＳＥのネットワークにわたってＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。
【図２３Ａ】図２３Ａは、本明細書に説明されるシステムおよび方法を実装するために使用され得る、例示的コンピュータ端末またはゲートウェイデバイスの略図である。
【図２３Ｂ】図２３Ｂは、本明細書に説明されるシステムおよび方法を実装するために使用され得る、例示的コンピュータシステムの略図である。
【発明を実施するための形態】
【００２６】
出願人らは、本明細書では、自動サービスオーケストレーションのためのシステムおよび方法の例示的実施形態を開示する。サービスオーケストレーションプロファイルは、所望のサービスを定義する属性を規定する。サービスオーケストレーションプロファイルは、ノードの間で分散され、互いに階層的に関連し得る。サービスオーケストレーション管理機能は、所望のサービスを実装するために、サービスオーケストレーションプロファイルの中の情報を処理する。
【００２７】
（例示的サービスアーキテクチャ）
ネットワークおよびアーキテクチャの視点から、サービスは、「サービス層」内に存在すると考えられ得る。図１は、サービス層の相対的場所を図示する例示的プロトコルスタックの略図を提供する。示されるように、サービス層１１０は、種々のトランスポートおよびネットワーク層１１２の上に位置する。これは、サービス層内のサービスが、サービスを提供することにおいてネットワーク層内の能力を利用することを可能にする。サービス層は、クライアントアプリケーション層１１４の下方に存在すると考えられ得る。クライアントアプリケーションは、サービスによって利用可能にされる機能性にアクセスするために、サービス層内のサービスに要求を行う。したがって、サービス層は、サービスによって提示される機能および能力へのアクセスを提供するミドルウェアとして動作する。
【００２８】
図２は、その中に展開されたサービス層のインスタンスを有する例示的ネットワークトポロジを図示する。図２を参照すると、ネットワークアプリケーションドメイン２１０の中に存在するユーザアプリケーションは、特定の機能が果たされることを要求し得る。ユーザアプリケーションは、図２３Ａに関連して以下で説明されるもの等のデバイス３０上で実行され得る。一例として、ネットワーク内のデバイスを管理することに専念するユーザアプリケーションは、デバイスの現在の状態についての情報を必要とし得る。別の実施例では、ユーザアプリケーションは、ウェブアプリケーションであり得、別のデータフォーマッティング規格を使用する別のアプリケーションにデータを伝達する必要があり得る。
【００２９】
アプリケーションは、特定のサービスに対する要求をネットワークサービスドメイン２１２に伝達する。示されるように、ネットワークサービスドメイン２１２は、種々のネットワークノード２２０を備えている。ネットワークノード２２０は、ネットワーク内のネットワークアドレス可能エンティティである。ネットワークノード２２０は、例えば、デバイス、ゲートウェイ、またはサーバ等の物理的アイテムであり得るか、もしくは、例えば、ＶＭｗａｒｅ等の仮想化ソフトウェアを使用して作成される、例えば、仮想マシン等の仮想エンティティであり得る。図２の例示的実施形態では、ネットワークノード２２０は、例えば、ディレクトリサーバ、アプリケーションサーバ、記憶サーバ、管理サーバ、およびサービスサーバを含む種々のサーバタイプを備えている。ネットワークノード２２０は、例えば、図２３Ｂに関連して以下で説明されるもの等の任意の好適なコンピュータシステムによって実装され得る。図２の実施形態では、種々のネットワーク２２２へのアクセスが、ゲートウェイ２２６を介して提供される。ゲートウェイは、例えば、図２３Ａに関連して以下で説明されるもの等の任意の好適なコンピュータシステムによって実装され得る。
【００３０】
サーバ２２０およびゲートウェイ２２６は、サービス層２３０を有する。サービス層２３０は、一組のアプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワークインターフェースを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。特定のサービス機能を果たすためのネットワークアプリケーションドメイン２１０内のアプリケーションからの要求は、特定のサービス層２３０にルーティングされ、そこで受信される。サービス層２３０は、要求を処理し、要求されたサービスの結果を要求側アプリケーションに返す。１つ以上のサービス能力をサポートするサービス層をホストするネットワークノードは、サービスノードと称される。
【００３１】
図２を参照すると、サービス層２３０内のサービスはまた、デバイスアプリケーションドメイン２１４の中に存在するもの等のデバイスアプリケーションによって要求され得る。したがって、例えば、センサまたはアクチュエータ等の特定のデバイスが特定の機能性が果たされることを要求する場合、そのデバイスは、要求をネットワークサービスドメイン２１２内のサービス層のうちの１つの中に存在する適切なサービスに伝送し得る。サービス層２３０は、要求を処理し、要求されたサービスの結果を要求側デバイスに返す。デバイスアプリケーションドメイン２１４の中のデバイスは、例えば、以下の図２３Ａに関連して説明されるもの等の任意の好適なコンピュータシステムを使用して実装され得る。
【００３２】
ある場合には、ネットワークサービスドメイン内のサービスは、他のサービスのうちの１つによって提供される機能性を必要とし得る。したがって、サービス層２３０内のサービスは、要求を別のサービス層２３０内に存在するサービスに伝送し得る。要求を受信したサービスは、その処理を完了すると、応答を要求側サービスに伝送する。
【００３３】
サービス層２３０は、任意のタイプのサービス層であり得る。例えば、サービス層２３０のうちの１つ以上のものは、モバイルネットワークデバイスのためのマルチメディアサービスを提供することに特に標的化される、ＩＰマルチメディアサブシステム（ＩＭＳ）サービス層であり得る。さらなる例として、サービス層２３０のうちの１つ以上のものは、Ｍ２Ｍ／ＩｏＴサービス層であり得る。Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することに向けて特に標的化される１つのタイプのサービス層の例である。近年、いくつかの業界規格団体（例えば、ＥＴＳＩ  Ｍ２Ｍ、ｏｎｅＭ２Ｍ、およびＯＭＡ  ＬＷＭ２Ｍ）が、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開にＭ２Ｍ／ＩｏＴタイプのデバイスならびにアプリケーションを組み込むことに関連付けられる課題に対処するために、Ｍ２Ｍ／ＩｏＴサービス層を開発してきた。
【００３４】
Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ中心の能力の集合へのアクセスをアプリケーションおよびデバイスに提供することができる。いくつかの例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージ形式、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。
【００３５】
ｏｎｅＭ２Ｍの目的および目標は、種々のハードウェアおよびソフトウェア内に容易に組み込まれ、フィールド内の多種多様なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために頼りにされ得る共通Ｍ２Ｍサービス層の必要性に対処する技術仕様を開発することである。
【００３６】
図３は、例示的な基本ｏｎｅＭ２Ｍアーキテクチャを図示する。示されるように、ｏｎｅＭ２Ｍアーキテクチャは、ｏｎｅＭ２Ｍソリューションにおいてアプリケーション論理を提供するアプリケーションエンティティ（ＡＥ）３１０を備えている。ｏｎｅＭ２Ｍ共通サービス層は、一組の共通サービス機能（ＣＳＦ）（すなわち、サービス能力）をサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中央ノード、アプリケーション特定のノード）上でホストされ得る共通サービスエンティティ（ＣＳＥ）３１２と称される。サービス機能は、基準点Ｍｃａ３２０およびＭｃｃ３２２を通して他のエンティティに提示される。基準点Ｍｃｎ３３０は、下層ネットワークサービスエンティティにアクセスするために使用される。ネットワークサービスエンティティ（ＮＳＥ）３４０は、サービスをＣＳＥに提供する。Ｍ２Ｍサービスの実施例は、デバイス管理、場所サービス、およびデバイストリガを含む。下層ＮＳＥ３４０は、例えば、３ＧＰＰベースのネットワークであり得る。
【００３７】
ｏｎｅＭ２Ｍアプリケーションは、典型的には、表現状態転送（ＲＥＳＴｆｕｌ）アーキテクチャを使用して実装される。そのような場合において、ＣＳＦは、一組のＲＥＳＴｆｕｌ「リソース」として表される。リソースは、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有する、アーキテクチャ内の一意にアドレス可能なエンティティである。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースの参照を含む。子リソースの有効期限は、親のリソースの有効期限によって限定される。各リソースは、リソースについての情報を記憶する一組の「属性」をサポートする。
【００３８】
（サービス記述）
アプリケーションまたは別のサービスが特定のサービスを呼び出すことができるために、アプリケーションまたは他のサービスは、特定のサービスについての情報を有する必要がある。そのような情報を提供するための１つの一般的に使用されている機構は、サービス記述である。サービス記述は、サービスがそれら自体についての情報を公開するための手段、および見込みクライアントがこの情報を発見するための手段を提供する。サービスプロファイルは、典型的には、ＵＲＩ、メディアタイプ、サポートされたプロトコル、サポートされたサービス等の統合機械読み取り可能な一組の情報を提供する。既存のサービス記述技術の一例は、ウェブサービス記述言語（ＷＳＤＬ）である。
【００３９】
ＷＳＤＬは、ウェブサービスのインターフェースを記述するために使用される、ＸＭＬベースのウェブサービス記述言語である。ＷＳＤＬファイルは、ウェブサービスが、どのようにして呼び出されることができるか、どのようなパラメータを予期するか、およびどのようなデータ構造を返すかという機械読み取り可能な記述を提供する。以下は、例示的ＷＳＤＬテンプレートである。
【００４０】
【数１】
0006560259.tif 000002
【００４１】
例示的テンプレートでは、ルート要素は、「記述」要素である。４つの子要素、すなわち、‘ｔｙｐｅｓ’、‘ｉｎｔｅｒｆａｃｅ’、‘ｂｉｎｄｉｎｇ’、および‘ｓｅｒｖｉｃｅ’は、特定のサービスに関する詳細を提供する。
【００４２】
‘ｔｙｐｅｓ’要素は、ウェブサービスのメッセージを記述するＸＭＬスキーマ要素およびタイプ定義の全てを含む。（ＸＳＤとしても公知である）ＸＭＬスキーマ言語が、この目的のために使用（インラインまたは参照）され得る。
【００４３】
‘ｉｎｔｅｒｆａｃｅ’要素は、サービスにおよびサービスからパスされる特定の入力、出力、および障害メッセージと、メッセージがパスされる順序とを含むウェブサービス動作を定義する。
【００４４】
‘ｂｉｎｄｉｎｇ’要素は、クライアントがウェブサービスと通信することができる様式を定義する。ＲＥＳＴウェブサービスの場合、バインディングは、クライアントがＨＴＴＰを使用して通信できることを規定する。ＳＯＡＰの場合、バインディングは、クライアントがＳＯＡＰ  ＲＰＣバインディングスタイルおよびプロトコルを使用してサービスと通信できることを規定する。
【００４５】
‘ｓｅｒｖｉｃｅ’要素は、ウェブサービスのためのアドレスを特定のインターフェースおよびバインディングに関連付ける。‘ｓｅｒｖｉｃｅ’はまた、ウェブベースのプロトコルに提示されている一組のシステム機能も含む。
【００４６】
例示的ＷＳＤＬリストは、以下の通りである。
【００４７】
【数２】
0006560259.tif 000003
【００４８】
【数３】
0006560259.tif 000004
【００４９】
ＷＳＤＬは、サービス記述を提供するための有用な技術であるが、多くの他の技術が代替として使用され得ることが理解されるであろう。例えば、代替的なサービス記述技術は、ドメイン名システム−サービス発見（ＤＮＳ−ＳＤ）である。
【００５０】
（サービスプロファイリング）
出願人らは、例えば、ＷＳＤＬおよびＤＮＳ−ＳＤ等の既存のサービス記述技術が、サービスの公開および発見をサポートするが、サービスのオーケストレーションをサポートしないことに留意している。
【００５１】
出願人らはまた、既存のサービス層技術（例えば、ＥＴＳＩ  Ｍ２Ｍ、ｏｎｅＭ２Ｍ、およびＯＭＡ  ＬＷＭ２Ｍ）がサービス能力のオーケストレーションをサポートしないことにも留意している。例えば、既存のサービス層技術は、サービスノードのネットワークにわたってサービスを編成することをサポートしない。既存のＭ２Ｍ／ＩｏＴサービス層は、ネットワーク全体の様式で、ネットワークサービスノード（例えば、デバイス、ゲートウェイ、およびサーバ）によってホストされるアクティブサービス層インスタンス、ならびに各サービス層インスタンスによってサポートされているサービス能力を動的に調整しないであろう。
【００５２】
図４は、システムにサービスノードのネットワークにわたってサービスを編成する能力を欠いている例示的サービスアーキテクチャを図示する。示されるように、個々のサービスノード４１０は、互いに異なるサービス（ＳＣ１、ＳＣ２、ＳＣ３、ＳＣ４、ＳＣ５、ＳＣ６）の組み合わせを有するサービス層４１２をホストする。典型的シナリオでは、複数のサービスノード４１０は、異なる物理的リソース（例えば、メモリ、ＭＩＰ、ネットワーク帯域幅等）を有し得、異なる時間に、様々な量の利用可能なリソースを有し得る。したがって、ノードがサポートするサービスを動的に変更することが望ましくあり得る。しかしながら、既存のシステムでは、サービスノード４１０は、それらのサービスを互いに動的に調整する能力を欠いており（例えば、どのノードがどのような条件下でどのサービスをサポートすべきか）、したがって、これらの動的変更は、調整された様式で行われることができない。ある状況下では、サービスノード４１０は、エンドツーエンドサービスを提供するために、ネットワーク内の各サービスノードにわたってサービスの一貫した構成を有する必要があり得る。他の状況にある間に、各サービスノード４１０上でホストされる、異なるが相補的な組のサービスを有することが望ましくあり得る。いずれの場合も、所望の様式でサービスが適切に編成されることを可能にするためのサービスノード４１０間の調整は、付加価値があり得る。
【００５３】
既存のサービス層技術はまた、サービス層４１２間でサービスを編成することをサポートしない。より具体的には、例えば、Ｍ２Ｍ／ＩｏＴ等の既存のサービス層技術は、サービス層４１２が互いに調整すること、およびどのサービス層４１２がどのサービス能力を提供すべきかを決定することを可能にしない。例えば、既存のサービス層４１２は、サービスの全体的混合がサービス層４１２にわたって平衡を保たれ、良好に分散されるように、各サービス層４１２によって提供される組のサービス能力を調整する機構を提供しない。
【００５４】
既存のサービス層技術はまた、サービス能力の自己オーケストレーションをサポートしない。例えば、既存のＭ２Ｍサービス層ノードは、それらのサポートされたサービス層の自律的かつ動的な修正のサポートを欠いている。同様に、既存のサービス層は、その組のサービス能力の自己オーケストレーションをサポートしない。さらに、既存のシステムでは、典型的には、サービス層によってサポートされる特定のタイプのサービスであるサービス能力は、その組のサポートされた特徴の自己オーケストレーションのサポートを欠いている。既存のサービス層技術は、一部を特定のクライアントに提供するように、または（例えば、ネットワーク条件、クライアント規定コンテキスト等の基準に基づいて）ある時間の間もしくはある観察された条件の間のみに、あるサービス能力を提供するようにその組のサービス能力をフィルタ処理すること、または、特定のクライアントのために異なるモードで動作するようにそのサービス能力を構成することをサポートしない。
【００５５】
既存のサービス層技術はまた、アプリケーション特定のサービスオーケストレーションを提供することをサポートしない。例えば、既存のＭ２Ｍ／ＩｏＴサービス層４１２は、アプリケーションが、サービス層が（サービス層ノードによってサポートされている全体的な組のサービス能力から）アプリケーションに提供すべき所望の組のサービス能力を選択的に選別することを可能にするためのサポートを欠いている。加えて、既存のサービス層技術は、アプリケーションが入力をサービス層に提供することを可能にし、サービス層がアプリケーションの個別化された必要性を満たす組のサービス能力をカスタマイズすることを可能にするサポートを欠いている。
【００５６】
図５は、サービスノードに、その個々のクライアントのためのそのサービス層の動的オーケストレーションのための能力を欠いている例示的状況を図示する。描写される実施例では、サービスノード５１０は、異なるタイプ／構成のサービス層５１２、５１４をその個々のクライアント５２０に提供するように、（例えば、そのクライアント５２０によって）動的に編成されるための能力を欠いている。代わりに、図５の実施例では、クライアントは、静的サービス層構成に制約される。
【００５７】
図６は、サービス層に、その個々のクライアント６２０のためのそのサービス能力の動的オーケストレーションのための能力を欠いている別の例示的シナリオを図示する。描写される実施例では、サービス層は、個々のクライアントのための区別された組のサービス能力６１０、６１２を可能にする能力を欠いている。代わりに、全てのクライアントは、全てのクライアントにわたって共通構成を有する共通の組のサービスに制約される。
【００５８】
図７は、その個々のサービス能力のうちの１つによってサポートされる特徴の動的オーケストレーションのための能力の欠如を図示するさらに別の例示的シナリオを描写する。描写される実施例では、サービス層は、個々のサービス能力７１０（すなわち、ＳＣ１）の特徴（Ｆ１、Ｆ２、Ｆ３、Ｆ４、およびＦ５）の異なるグループ７１２、７１４をその個々のクライアント７２０に提供するために動的に編成される能力を欠いている。代わりに、全てのクライアントは、サービスのための共通の組の特徴を提供される。例示的実施形態では、特徴は、サービス能力がキャッシングの有効または無効、ストアアンドフォワードの有効または無効、暗号化の有効または無効等をサポートし得る異なる動作モードを含み得る。
【００５９】
したがって、サービスノードの現在のネットワーク展開は、典型的には、それらのサポートされたサービス層および対応するサービス能力の動的オーケストレーションのための能力を欠いている。結果として、サービスノードは、典型的には、それらがホストするサービス層およびそれらが全てのそれらのクライアントに利用可能にするサービス能力のために、単一の静的構成をサポートすることに限定される。
【００６０】
（自動サービスオーケストレーション）
出願人らは、本明細書では、サービスの自動オーケストレーションのためのシステムおよび方法を開示する。開示されるシステムおよび方法は、所望のサービスを提供するように、ノードおよびサービス層を構成して調整する。例えば、オーケストレーションは、ネットワーク内のノード、サービスノード上でホストされるサービス層、サービス層内のサービス能力、および／またはサービス能力の特徴のうちのいずれかならびに／もしくは全てを自動的に構成して調整することを伴い得る。
【００６１】
図８は、例示的サービスオーケストレーションアーキテクチャを描写する。示されるように、例示的アーキテクチャは、複数のノード８１０を備えている。サービスノード８１０は、ネットワーク内のネットワークアドレス可能エンティティであり、任意の好適なネットワーキングおよび通信技術を使用して、互いに通信可能に連結されている。サービスノード８１０は、ネットワーク内の物理的デバイス（例えば、デバイス、ゲートウェイ、もしくはサーバ）または仮想エンティティ（例えば、ＶＭ）のいずれかであり得る。サービスノード８１０は、任意の好適なコンピューティングハードウェアを使用して実装され得ることが理解されるであろう。例えば、ネットワーク内のサーバとして機能するサービスノード８１０は、図２３Ｂに関連して以下で説明されるようなコンピュータシステムを使用して実装され得る。ゲートウェイとして、または端末デバイスとして機能するサービスノード８１０は、図２３Ａに関連して以下で説明されるようなコンピュータシステムを使用して実装され得る。
【００６２】
描写されたサービスノード８１０の各々は、１つ以上のサービス能力８１４をサポートするサービス層８１２をホストする。サービス能力８１４は、サービス層によってサポートされる特定のタイプのサービスである。以下で議論されるように、各サービス能力８１４は、１つ以上のサービス機能８４０を備えている。
【００６３】
サービスノード８１０上に記憶されるサービスオーケストレーションプロファイル８２０は、サービスの属性を定義する。サービスオーケストレーションプロファイル８２０は、サービスオーケストレーションならびにサービス発見等の他の機能のために使用され得るサービス関連属性（すなわち、メタデータ）の交換のための機構を提供する。図８に図示されるように、例示的実施形態では、サービスオーケストレーションプロファイル８２０は、サービス階層内の複数のレベルに存在し得る。例えば、プロファイル８２０は、特定のサービス能力８１４のサービス機能を定義するためにプロビジョンされ得る。同様に、プロファイル８２０は、特定のサービス層８１２の属性を定義するために、サービス層８１２のためにプロビジョンされ得る。同様に、プロファイルは、特定のサービスノード８１０によって提供されるサービスの属性を定義するように、サービスノード８１０のためにプロビジョンされ得る。例示的シナリオでは、プロファイル８２０は、階層内の種々のレベルのためのサービスプロビジョニングを調整するように動作する集中ノード８５０においてプロビジョンされ得る。
【００６４】
サービスノード８１０上で実行される、サービスオーケストレーション管理機能８４０は、サービスオーケストレーションプロファイル８２０に記憶された属性と一致する所望のサービスを実装するために採用される。サービスオーケストレーション管理機能８４０は、関連オーケストレーションプロファイル８２０の中の情報を処理し、プロファイル８２０で規定されるようなサービスを実装するために、適切な措置を講じる。
【００６５】
例示的実施形態では、サービスプロファイル８２０と同様に、サービスオーケストレーション管理機能８４０は、サービス階層内の複数のレベルに存在し得る。例えば、サービスオーケストレーション管理機能８４０は、ネットワーク、サービスノード８１０、サービス層８１２、およびサービス能力８１４において実行され、それら内のサービスのオーケストレーションを行い得る。サービスオーケストレーション管理機能８４０の別個のインスタンスは、ネットワークにわたって分散され、個々のサービスノード、サービス層、および／またはサービス能力によってホストされ得る。分散型管理機能を採用する実施形態は、ウェブ／インターネット等の広範囲ネットワークにわたるサービスのオーケストレーションのためのより高い拡張可能性を提供し得る。
【００６６】
別の例示的実施形態では、サービスオーケストレーション管理機能８４０は、集中ノード８５０においてプロビジョンされ得る。管理機能８４０およびサービスオーケストレーションプロファイル８２０の集中展開は、特定のサービスプロバイダによって所有および操作されるサービス、またはあるネットワークドメインもしくは領域内で展開されるサービスのオーケストレーションに適し得る。
【００６７】
例えば、アプリケーションまたは管理エンティティであり得るサービスオーケストレーションクライアント８３０は、サービスのオーケストレーションを開始および管理するために、サービスオーケストレーション管理機能８４０と通信する。サービスオーケストレーション管理機能８４０が集中ノード８５０に位置している実施形態では、オーケストレーションクライアント８３０は、オーケストレーションを開始するために、集中ノード８５０上のオーケストレーション管理機能８４０と通信する。例示的シナリオでは、通信は、所望されるサービスオーケストレーションを記述する情報を含むサービスプロファイル８２０を含み得る。サービスオーケストレーション管理機能８４０が個々のノード８１０に分散されている実施形態では、サービスオーケストレーションクライアント８３０は、サービスのオーケストレーションを開始および管理するために、個々のノード上のサービスオーケストレーション管理機能８４０と通信し得る。ここでは、同様に、通信は、所望されるサービスオーケストレーションを記述する情報を含むサービスプロファイル８２０を含み得る。
【００６８】
サービスプロファイル８２０およびサービス管理機能８４０は、互いに階層的に関連する。したがって、サービスを編成するための要求が受信されると、サービス管理機能８４０は、所望のサービスオーケストレーションを実装するために、他のサービス管理機能８４０において構成ステップを開始し得る。
【００６９】
サービスオーケストレーションは、多くの場合、クライアント８３０からの要求の結果として開始され得るが、オーケストレーションは、明示的要求がなくても行われ得る。サービスオーケストレーションは、サービス層によって自動的にトリガされることができる（すなわち、自己オーケストレーション）。例えば、サービスオーケストレーション管理機能８４０は、外部から促すことなくオーケストレーションをトリガし得る。トリガは、あるサービスに対するサービス層への要求であり得るか、または、トリガは、サービス層が自己オーケストレーションを行うようにサービス層内の統計に基づき得る。
【００７０】
図８の例示的実施形態は、全てのノード８１０上で分散されるサービスオーケストレーション管理機能８４０およびサービスオーケストレーションプロファイル８２０を描写するが、サービスオーケストレーション管理機能の展開は、随意の様式で行われることができ、サービスオーケストレーション管理機能は、ネットワーク内の随意の特徴であり、および／またはネットワーク内の全てのサービスノードによってサポートされることを要求されない。サービス管理機能８４０が存在する場合において、サービスオーケストレーションがサポートされることができる。サービス管理機能８４０が存在しないシナリオにおいて、サービスオーケストレーションがサポートされないこともある。
【００７１】
（サービスオーケストレーションプロファイル）
図８に図示されるように、オーケストレーションプロファイル８２０は、プロファイルが関係するサービスの側面、例えば、サービス能力、サービス層、サービスノード等に応じて、サービスノード８１０のネットワーク内のいくつかの異なる場所のうちのいずれかに位置付けられ得る。プロファイル８２０は、互いを参照し得、それによって、拡張可能な階層を提示すると見なされ得る。組織化の目的で、プロファイル８２０は、プロファイルが関係する、サービスオーケストレーション内の特定のレベルに従って分類され得る。例えば、プロファイル８２０は、ネットワークサービスオーケストレーションプロファイル、サービスノードオーケストレーションプロファイル、サービス層オーケストレーションプロファイル、およびサービス能力オーケストレーションプロファイルとして分類され得る。
【００７２】
例示的実施形態では、ネットワークオーケストレーションプロファイル８２０は、サービスノード８１０のネットワークによって提供されるサービスを記述し、各サービスノード８１０は、１つ以上のサービス層８１２をホストする。このプロファイルは、サービスノードのネットワークにわたって分散される複数のサービス層８４２にわたるサービス能力（ＳＣ１、ＳＣ２、ＳＣ３、ＳＣ４、ＳＣ５）の混合を調整するために、サービスオーケストレーション管理機能８４０によって使用されることができる。
【００７３】
サービスノードオーケストレーションプロファイル８１０は、１つ以上のサービス層８１２をホストする単一のサービスノード８１０によって提供される、サービスを記述する。このプロファイル８２０は、単一のサービスノード８１０上でホストされる１つ以上のサービス層８１２にわたるサービス能力の混合を調整するために、サービスオーケストレーション管理機能によって使用されることができる。
【００７４】
サービス層オーケストレーションプロファイルは、単一のサービス層８１２によって提供されるサービスを記述する。このプロファイルは、単一のサービス層８１２によってサポートされているサービス能力の混合を調整するために、サービスオーケストレーション管理機能８４０によって使用されることができる。
【００７５】
サービス能力オーケストレーションプロファイルは、サービス層８１２内の単一のサービス能力（ＳＣ１）によって提供される特徴を記述する。このプロファイルは、特定のサービス能力によってサポートされる特徴の混合を調整するために、サービスオーケストレーション管理機能によって使用されることができる。
【００７６】
図９Ａは、階層的に配列されている例示的な組のオーケストレーションプロファイルを描写する。示されるように、ネットワークサービスオーケストレーションプロファイル９１０は、最上レベルに常駐し、その後に、サービスノードオーケストレーションプロファイル９１２、サービス層オーケストレーションプロファイル９１４、および一番下に常駐するサービス能力オーケストレーションプロファイル９１６が続く。一番上に常駐するネットワークサービスオーケストレーションプロファイル９１０を除いて、階層内の各プロファイルは、階層内でそれの上方の１つ以上の親プロファイルにリンクされることができる。一番下に常駐するサービス能力オーケストレーションプロファイル９１６を除いて、各プロファイルは、階層内でより低くそれにリンクする子プロファイルを有することができる。展開の使用事例シナリオに応じて、プロファイルの完全な階層が使用されることができるか、または代替として、階層の一部のみが使用されることができる。
【００７７】
階層的に関連するオーケストレーションプロファイルは、複数のサービス能力（ＥＴＳＩ  Ｍ２Ｍ、ｏｎｅＭ２Ｍ、およびＯＭＡ  ＬＷＭ２Ｍによって定義されるもの等）をサポートする分散型サービス層から成る、サービスのネットワークを編成するために特に適している。開示された階層的に関連するオーケストレーションプロファイルは、拡張可能であり、分散型の組のサービスのプロファイリングをサポートする。階層的に関連するプロファイルは、単一のサービス能力のための特徴のプロファイリングをサポートするように縮小され得、それはまた、サービスノードのネットワークにわたって分散されるプロファイルサービスに拡大され得る。サービス層によってサポートされているサービス能力が、サービスノードのネットワークにわたってホストされる例示的シナリオでは、プロファイルの階層全体が使用され得る。単一のサービス能力インスタンスの特徴がオーケストレーションを必要とする別の例示的シナリオでは、個々のサービス能力オーケストレーションプロファイルが十分であり得る。
【００７８】
サービスオーケストレーションプロファイルの提案された階層を活用することによって、オーケストレーションは、例えば、サービスオーケストレーション管理機能によって行われ得るプロファイルを分散することによって、動的に行われることができる。代替実施形態では、プロファイルは、おそらく、例えば、製造中または展開中に、事前構成／事前プロビジョンされることができる。
【００７９】
（サービスオーケストレーションプロファイル属性）
サービスオーケストレーションプロファイルは、所望のサービスを記述する情報を含む。プロファイルの形式およびコンテンツは、それが実装され得るように、サービスを記述するために好適である任意のものであり得る。例えば、サービスプロファイルは、ＸＭＬまたはＪＳＯＮ形式を使用して実装され得る。例示的実施形態では、プロファイルは、一組の定義された属性に対応する情報を含む。
【００８０】
例示的実施形態では、サービスオーケストレーションプロファイルは、それらの各々が以下で議論される、以下の属性に対応する情報を含み得る：プロファイル識別子、プロファイルセマンティクス、プロファイルタイプ、サービスオーケストレーション標的、サービスオーケストレーションスケジュール、サービスオーケストレーションポリシー、サービスオーケストレーションコンテキスト、所望のサービス、およびサポートされたサービス。
【００８１】
プロファイル識別子属性は、プロファイルの識別子を規定する。プロファイルが他のプロファイルに階層的にリンクされる場合に対して、プロファイル識別子は、プロファイルが他のプロファイルによって参照されてリンクされ得るように、アドレスとしての機能を果たすことができる。例示的実施形態では、プロファイル識別子は、所望のサービスについての情報が取得され得る場所を指定するＵＲＩまたはＵＲＬであり得る。プロファイルが独立型様式で使用されるシナリオでは、この識別子は、必要とされないこともある。
【００８２】
プロファイルセマンティック属性は、セマンティック記述、またはプロファイル内に含まれるサービスオーケストレーション属性を記述するセマンティック記述へのアドレス／リンクを規定する。換言すると、プロファイルセマンティック属性は、プロファイル情報を処理することにおいて使用され得る、プロファイル属性に関するコンテキスト情報を提供する。
【００８３】
プロファイルタイプ属性は、プロファイルのタイプを規定する。例示的実施形態では、プロファイルタイプ属性は、２つの異なるプロファイルタイプのうちの１つであり得る。第１のプロファイルのタイプは、標的上に編成されるべき所望の組のサービスを規定する。第２のプロファイルのタイプは、オーケストレーション標的によってサポートされている組のサービスを規定する。
【００８４】
サービスオーケストレーション標的属性は、サービスオーケストレーションが行われるべき標的の随意のリストを規定する。例えば、サービスオーケストレーション標的に対応する情報は、サービスノード、サービス層、およびサービス能力インスタンスのうちの１つ以上のものを規定し得る。例示的シナリオでは、サービスオーケストレーション標的情報は、クライアントが１つ以上の規定された標的上にサービスオーケストレーションを行うための要求の中にプロファイルを含む場合、オーケストレーションプロファイルに含まれ得る。代替的シナリオでは、クライアントは、オーケストレーションプロファイルの中のオーケストレーション標的のリストを規定せず、代わりに、標的を決定するようにサービスオーケストレーション管理機能に頼ることを選定し得る。
【００８５】
サービスオーケストレーションスケジュール属性は、サービスオーケストレーションが行われるとき、および／またはプロファイルが有効である持続時間のスケジューリング情報を規定する。
【００８６】
サービスオーケストレーションポリシー属性は、サービスオーケストレーションを行うことを適格とするポリシーを規定する。ポリシーは、サービスオーケストレーションが行われるべき場合／ときに関する規則、または、異なる標的上で、もしくは異なるクライアントによって行われ得る異なるタイプのサービスオーケストレーションに関する規則を含み得る。これらの規則は、サービスオーケストレーションコンテキスト次第であり得る。例えば、ポリシーは、特定のイベントまたはトリガ条件（例えば、ネットワークまたはノードが負荷がある閾値に達したこと、特定のエラー条件の発生、隣接するサービスノードのクライアントによって発行されるオーケストレーション要求等）が検出されたとき、特定のタイプのサービスオーケストレーションが行われるべきことを規定し得る。
【００８７】
サービスオーケストレーションコンテキスト属性は、サービスオーケストレーションに適用可能であるコンテキスト情報を規定する。例えば、コンテキスト情報は、クライアントの識別、場所、サービス品質の所望のレベル、利用可能性のスケジュール、用途のタイプ等を規定し得る。コンテキスト情報は、例えば、サービスオーケストレーションポリシー属性等の他の属性によって参照され得る。
【００８８】
所望のサービス属性は、オーケストレーションクライアントが規定された標的上に編成されるべきことを要求しているサービス構成を規定する。所望のサービス属性は、概して、オーケストレーションプロファイルが、標的を編成するためのクライアント要求で使用されている場合／ときのみ適用可能である。プロファイルが、例えば、サポートされた組のサービスを公開すること等の他の目的で使用されている場合、この属性は、適用可能でないこともある。例示的実施形態では、所望のサービス属性は、それらの各々が以下で議論される、以下のタイプのうちの任意のものを有し得る：所望のネットワークサービス、所望のサービスノード、所望のサービス層、および所望のサービス能力。
【００８９】
所望のネットワークサービスタイプは、ネットワーク内のサービスノード構成の所望の混合および分布を規定する。例示的実施形態では、所望のネットワークサービスタイプは、例えば、以下のうちの任意のものを規定し得る：サービスノードの所望の数、サービスノードの所望の場所、各サービスノードに割り付けられる所望のコンピューティングおよびネットワークリソース、サービスノードにわたるサービス層構成の所望の混合および分布、サービスノードにわたって使用される所望のネットワークセキュリティ方式、ならびに個々のサービスノードを編成するために使用されるべき子サービスノードオーケストレーションプロファイルへのリンク。
【００９０】
所望のサービスノードタイプは、サービスノードの所望の構成を規定する。例示的実施形態では、所望のサービスノードタイプは、例えば、以下のうちの任意のものを規定し得る：サービスノード上でホストされるべきサービス層インスタンスの所望の数、各所望のサービス層インスタンスのタイプ、サービスノードによってサポートされる所望のセキュリティ方式、サービスノード上の各サービス層インスタンスに割り付けられる所望のコンピューティングおよびネットワークリソース、サービスノードが協働すべき所望のピアサービスノード、ならびにこのサービスノードによってサポートされる個々のサービス層インスタンスを編成するために使用されるべき所望の子サービス層オーケストレーションプロファイルへのリンク。
【００９１】
所望のサービス層タイプは、サービス層の所望の構成を規定する。例示的実施形態では、所望のサービス層タイプは、例えば、以下のうちの任意のものを規定し得る：サービス層によって有効にされるべき所望の組のサービス能力インスタンス、サービス層を使用する所望の費用、サービス層の所望のセキュリティ／プライバシープロファイル、サービス層によってサポートされる各サービス能力インスタンスに割り付けられる所望のコンピューティングおよびネットワークリソース、このサービス層が協働すべき所望のピアサービス層、ならびにこのサービス層によってサポートされる個々のサービス能力インスタンスを編成するために使用されるべき所望の子サービス能力オーケストレーションプロファイルへのリンク。
【００９２】
所望のサービス能力タイプは、サービス能力の所望の構成を規定する。規定される情報のタイプのいくつかの例示的実施形態は、サービス能力によって有効にされるべき所望の組の特徴、サービス能力を使用する所望の費用等を含むことができるが、それらに限定されない。
【００９３】
再度、サービスオーケストレーションプロファイルに含まれる属性を参照すると、サポートされたサービス属性は、オーケストレーション標的がサポートする、組のサポートされたサービスを規定する。この属性は、サービスオーケストレーションプロファイルがサポートされたサービスを公開／宣伝するための要求で（または発見応答で）使用されている場合／ときのみ適用可能であることに留意されたい。プロファイルが（例えば、標的のオーケストレーションを要求するためにオーケストレーションクライアントによって）他の目的で使用されている場合、この属性は、適用可能でないこともある。例示的実施形態では、サポートされたサービス属性は、それらの各々が以下で議論される、以下のタイプのうちの任意のものを有し得る：サポートされたネットワークサービス、サポートされたサービスノード、サポートされたサービス層、およびサポートされたサービス能力。
【００９４】
サポートされたサービス属性のためのサポートされたネットワークサービスタイプは、ネットワーク内のサポートされたサービスノードの簡潔な記述を規定する。サポートされたネットワークサービスタイプのために含まれ得る情報の例は、以下を含むが、それらに限定されない：サービスノードのサポートされた数、場所、アドレス、およびそれらの対応する子プロファイルへのリンク、各サービスノードに割り付けられるサポートされたコンピューティングおよびネットワークリソース、サービスノードにわたるサービス層構成のサポートされた混合および分布、ならびにサービスノードにわたって使用されるサポートされたネットワークセキュリティ方式。
【００９５】
サポートされたサービス属性のためのサポートされたサービスノードタイプは、サービスノードによってサポートされているサービス層の簡潔な記述を規定する。サポートされたサービスノードタイプのために含まれ得る情報の例は、以下を含むが、それらに限定されない：サービスノード上でホストされるサービス層インスタンスのサポートされた数、タイプ、場所、およびアドレス、ならびにそれらの対応する子プロファイルへのリンク、サービスノードによってサポートされるサポートされたセキュリティ方式、サービスノードのサポートされたインターフェース記述（例えば、ＡＰＩ）、ピアサービスノード、サポートされたサービス層オーケストレーションプロファイルへのリンク、サービスノードを所有／管理するサービスプロバイダ、サービスノードの費用情報、ならびにサービスノードの性能／リソース構成。
【００９６】
サポートされたサービス属性のためのサポートされたサービス層タイプは、サービス層によってサポートされているサービス能力の簡潔な記述を規定する。サポートされたサービス層タイプのために含まれ得る情報の例は、以下を含むが、それらに限定されない：サービス層インスタンスによってサポートされている組のサービス能力インスタンスおよびそれらの対応する子プロファイルへのリンク、サービス層のサポートされたインターフェース記述（例えば、ＡＰＩ）、サービス層を使用することに関連付けられる費用、サポートされたセキュリティ／プライバシー方式、各サービス能力インスタンスに割り付けられるコンピューティングおよびネットワークリソース、このサービス層が協働するピアサービス層、ならびにサービス層のサポートされた動作モード（例えば、高性能、低費用、低エネルギー消費等）。
【００９７】
サポートされたサービス属性のためのサポートされたサービス能力タイプは、サービス能力によってサポートされる特徴の簡潔な記述を規定する。サポートされたサービス能力タイプのために含まれ得る情報の例は、以下を含むが、それらに限定されない：サービス能力インスタンスによってサポートされる組の特徴、サービス能力のサポートされたインターフェース記述（例えば、ＡＰＩ）、サービス能力を使用することに関連付けられる費用、サービス能力のサポートされたセキュリティ／プライバシー方式、このサービス能力が協働するピアサービス能力、ならびにサービス能力のサポートされた動作モード（例えば、高性能、低費用、低エネルギー消費等）。
【００９８】
（サービスオーケストレーション管理機能）
サービスオーケストレーション管理機能８４０は、サービスノードのネットワークのオーケストレーション、個々のサービスノードのオーケストレーション、個々のサービス層のオーケストレーション、および／または個々のサービス能力のオーケストレーションを含むいくつかのタイプのサービスオーケストレーションをサポートする。機能８４０がネットワーク内で展開される場所に応じて、機能８４０は、これらのタイプのオーケストレーションのうちの１つ以上のものをサポートし得る。これらのタイプのサービスオーケストレーションを行うために、機能８４０は、上で議論されるようなサービスオーケストレーションプロファイルの使用を頼りにする。サービスオーケストレーション管理機能８４０は、要求内に含まれるサービスオーケストレーションプロファイルを解析し、サービスオーケストレーションプロファイル属性を抽出することによって、サービスオーケストレーション要求を処理することをサポートする。
【００９９】
サービスオーケストレーション管理機能８４０は、それらの対応するサービスオーケストレーションプロファイルと同様に、階級様式で展開されることができる。換言すると、サービスオーケストレーション管理機能は、ネットワーク、ノード、サービス層、および／またはサービス能力の粒度において展開されることができる。これらのレベルの各々においてプロファイルを活用することによって、機能は、異なる形態のサービスオーケストレーションをサポートすることができる。
【０１００】
サービスオーケストレーション管理機能８４０によってサポートされる第１のオーケストレーションは、１つ以上のサポートされたネットワークサービスノードを動的にインスタンス化し（例えば、新しいＶＭを生成し、ＶＭ上で新しいサービスノードをインスタンス化し）、それらがネットワーク内の他のサービスノードに適合性があり、補完するように、それらの構成を調整することである。例えば、サービスオーケストレーション管理機能は、生成される各仮想マシン（ＶＭ）が、適合性のあるタイプおよびバージョンのサービス層ソフトウェア（例えば、ｏｎｅＭ２Ｍ  ｖ１．０）がインストールされることを確実にするように調整し得る。
【０１０１】
サービスオーケストレーション管理機能８４０によってサポートされる別のオーケストレーションは、ネットワーク内のサービスノード上でサポートされたサービス層の１つ以上のインスタンスを動的にインスタンス化して起動すること、およびそれらがネットワーク内の他のサービス層インスタンスの構成に適合性があり補完するように、サービス層インスタンスの構成を調整することである。例えば、サービスオーケストレーション管理機能８４０は、ｏｎｅＭ２Ｍサービス層インスタンスをインスタンス化し、特定の役割（例えば、インフラストラクチャノード、中央ノード、アプリケーション特定のノード等）で機能し、それらのインターフェースが互いに適合性があることを確実にする（例えば、特定のポート番号およびプロトコルを使用する）ように、これらのインスタンスを構成し得る。
【０１０２】
サービスオーケストレーション管理機能８４０によってサポートされる別のオーケストレーションは、ネットワークの全体を通して種々のサービスノード上でホストされる各サービス層インスタンスによってサポートされる、特定のタイプのサービス能力（例えば、ｏｎｅＭ２Ｍ  ＣＳＦまたはＥＴＳＩ  Ｍ２Ｍ  ＳＣ）の有効化、無効化、および構成を動的に調整することである。例えば、サービスオーケストレーション管理機能は、互いに相互運用するために特定のグループのサービス層によって必要とされる必須の組のサービス能力の有効化および構成を調整し得る。さらなる例として、サービスオーケストレーション管理機能は、サービス層にわたる負荷バランシングおよび見込みクライアントへの利用可能性のための適切な混合を確実にするようために能力が分散されるように、ネットワークの全体を通した種々のサービス層上の付加価値サービス能力の有効化、無効化、ならびに構成を調整し得る。
【０１０３】
サービスオーケストレーション管理機能８４０によってサポートされる別のオーケストレーションは、ネットワークの全体を通して種々のサービス層内の各サービス能力によってサポートされる特定のタイプの特徴（例えば、ｏｎｅＭ２Ｍ  ＣＭＤＨ  ＣＳＦのストアアンドフォワード特徴）の有効化、無効化、および構成を動的に調整することである。例えば、サービスオーケストレーション管理機能８４０は、サービス能力をサポートするネットワーク内の異なるサービス層インスタンスにわたってサービス能力相互運用性を確実にするために必要とされる、必須の組の特徴の有効化および構成を調整し得る。さらなる実施例として、サービスオーケストレーション管理機能は、サービス層にわたる適切な負荷バランシングおよび見込みクライアントへの利用可能性を確実にするために機能が分散されるように、特定のサービス能力の付加価値特徴の有効化、無効化、ならびに構成を調整し得る。
【０１０４】
サービスオーケストレーション管理機能８４０は、１つ以上のインターフェースをサポートすることができ、１つ以上のインターフェースは、要求をオーケストレーションクライアント、オーケストレーション標的、およびネットワーク内の他のサービスオーケストレーション管理機能に送信すること／そこから受信することを可能にする。例示的実施形態では、サービスーケストレーションインターフェースは、要求されたプロファイルに基づいて、機能８４０に規定タイプのサービスオーケストレーションを行わせるために、クライアント（例えば、ネットワーク内のアプリケーションまたは管理エンティティ）から要求を受信するように適合され得る。それに応答して、管理機能８４０は、サービスノードのネットワーク、特定のサービスノード、特定のサービス層、または特定のサービス能力上でオーケストレーションを行う。別の例示的実施形態では、管理機能は、潜在的オーケストレーション標的から、それらのサービスオーケストレーションプロファイルを公開するための要求を受信するように適合され得る。それに応答して、管理機能は、サービス層／サービス能力／特徴のそのサポートされたセットを宣伝し、またはサービスオーケストレーションコンテキストもしくはポリシーを機能に提供する。さらに別の実施形態では、管理機能８４０は、ネットワーク内の他のサービスオーケストレーション管理機能からサービスオーケストレーションを調整するための要求を受信するように適合され得る。例えば、例示的シナリオでは、サービスノード上でホストされる機能は、サービス層のサービスオーケストレーションを行うように、ノード上でホストされるサービス層内の機能に要求し得る。そのような要求に応答して、オーケストレーション管理機能は、サービス能力のうちの１つの中の機能がサービス能力上でサービスオーケストレーションを行うことを要求し得る。
【０１０５】
サービスオーケストレーション管理機能８４０は、編成されるサービスの所望の側面をユーザが規定し得るユーザインターフェースを生成して表示し得ることが理解されるであろう。サービスオーケストレーション管理機能８４０は、規定されたユーザ入力と一致するプロファイルを構成するために、ユーザインターフェースを介して入力される情報を使用する。図９Ｂは、サービスオーケストレーション管理機能８４０によって提供され得る例示的ユーザインターフェース９５０を描写する。示されるように、ユーザインターフェース９５０は、所望のサービスパネル９５２を備え、ユーザは、ユーザが編成させることに関心がある特定のサービスを規定し得る。パネル９５４を使用して、ユーザは、規定された組サービスが有効にされるべき特定の標的サーバ、ゲートウェイ、デバイス等を規定し得る。パネル９５６は、オーケストレーションが行われる場合／ときを決定付ける特定のポリシーをユーザが規定することを可能にする。例えば、パネル９５６を使用して、ユーザは、オーケストレーションが特定の時間に、または特定のスケジュールで行われるべきことを選択し得る。代替として、パネル９５６を使用して、ユーザは、場所に応じてオーケストレーションが行われるべきことを規定し得る。別の実施形態では、ユーザインターフェースは、ユーザが、加えて、または代替として、所望されるサービスの質に基づいて、オーケストレーションが行われるべきことを規定することを可能にし得る。ユーザが、特定の時間またはスケジュールに基づいて、オーケストレーションが行われるべきことを決定付けるポリシーを選択する、シナリオでは、ユーザは、パネル９５８を使用して時間またはスケジュールの詳細を規定し得る。ユーザが、パネル９６０を使用して、場所に基づいてオーケストレーションが行われるべきことを決定付けるポリシーを選択するシナリオでは、ユーザは、オーケストレーションを行うかどうかを決定するためのコンテキストを提供する場所を規定し得る。同様に、サービスの質がオーケストレーションポリシーとして規定された場合、ユーザインターフェースは、所望のサービスの質に関する関連詳細を規定するための対応する場所を提供するであろう。ユーザがインターフェース９５０を使用して所望のレベルのサービスに関する詳細を規定した後、サービスオーケストレーション管理機能８４０は、規定された様式で所望のサービスを実装するように、プロファイル情報を更新するために規定された詳細を使用し得る。
【０１０６】
（サービスを編成する方法）
図１０Ａ−１０Ｂは、サービスオーケストレーションを行うための要求の例示的処理を図示するフロー図を提示する。処理は、階層的に関連し得、かつ階層的に関連し得るサービスオーケストレーションプロファイル８２０を処理するサービスオーケストレーション管理機能によって行われる。
【０１０７】
図１０Ａを参照すると、ステップ１では、サービスオーケストレーション管理機能８４０が、サービスオーケストレーションプロファイル８２０で構成される。この構成は、サービスノードがプロビジョンされる時間に事前プロビジョニングを介して行われることができ、または例えば、要求がオーケストレーションクライアントから、もしくは別のサービスオーケストレーション管理機能から受信されると、動的に生じ得る。サービスオーケストレーション機能８４０を構成することに先立って、サポートされている利用可能な組のサービスを識別するために、事前発見ステップが採用され得ることが理解されるであろう。
【０１０８】
図１０Ａを参照すると、ステップ２では、オーケストレーショントリガが生じる。例えば、サービスオーケストレーション管理機能８４０は、所望のタイプのオーケストレーションを行うための要求をクライアントから受信し得る。要求は、所望のサービスを記述するプロファイル８２０を備え得るか、またはそれによって先行され得る。別のシナリオでは、サービスオーケストレーション管理機能８４０は、オーケストレーションプロファイル８２０の中で規定されるポリシーまたは規則に基づいて、自己オーケストレーションが行なわれるようにトリガするイベントを検出し得る。
【０１０９】
図１０Ａを参照すると、ステップ３では、任意の関連サービスオーケストレーションが、サービスオーケストレーション管理機能によって処理される。例えば、機能８４０は、トリガに関連付けられる対応するサービスオーケストレーションプロファイルを処理する。
【０１１０】
図１０Ａを参照すると、ステップ４では、サービスオーケストレーション管理機能８４０は、それがセマンティック記述または他の場所に記憶されたセマンティック記述へのリンクであるかどうかを決定するために、「プロファイルセマンティクス」属性（存在する場合）を解析する。
【０１１１】
図１０Ａを参照すると、ステップ５Ａでは、サービスオーケストレーション管理機能が、「プロファイルセマンティクス」属性がリンクであることを決定する場合、サービスオーケストレーション管理機能は、ステップ５Ｂで、リンクを採用し、セマンティック記述をフェッチする。
【０１１２】
ステップ６では、サービスオーケストレーション管理機能８４０は、セマンティック認識技法を使用して、プロファイル８２０の個々の属性を解析して理解するためにセマンティック記述を採用する。
【０１１３】
図１０Ａのステップ７では、サービスオーケストレーション管理機能８４０は、「プロファイルタイプ」属性を解析し、意図されたオーケストレーション標的が、サービスノードのネットワークであるか、サービスノードであるか、サービス層であるか、またはサービス能力であるかを決定する。
【０１１４】
図１０Ｂで描写されるステップ８では、サービスオーケストレーション管理機能８４０は、それが要求されたタイプのサービスオーケストレーションを行うことが可能であるかどうかを検証する。もし可能でなければ、それは、ステップ１３に関連して以下で記述されるようにエラー状態でクライアントに応答する。そうでなければ、オーケストレーション管理機能８４０は続いて、要求を処理する。
【０１１５】
図１０Ｂのステップ９では、サービスオーケストレーション管理機能８４０は、「サービスオーケストレーションスケジュール」属性を解析し、要求されたサービスオーケストレーションを行うべきとき（例えば、日付および時間）に関するスケジューリング情報を決定する。
【０１１６】
図１０Ｂのステップ１０では、サービスオーケストレーション管理機能８４０は、「サービスオーケストレーションポリシー」および「サービスオーケストレーションコンテキスト」属性を解析し、サービスオーケストレーションをさらに適格とする任意の規定規則およびコンテキストがあるかどうかを決定する。例えば、サービスオーケストレーション管理機能８４０は、サービスオーケストレーションが行われるべき場合／とき、許可される／許可されないサービスオーケストレーションのタイプ、またはサービスオーケストレーションが調節もしくは反復される必要がある条件を決定し得る。ポリシーは、「サービスオーケストレーションコンテキスト」属性への従属／参照を含み得る。このコンテキストに対する更新が検出されると、サービスオーケストレーション管理機能８４０は、任意の適用可能なポリシーを再評価し、サービス再オーケストレーションが必要とされる場合／ときを決定することができる。
【０１１７】
図１０Ｂのステップ１１では、サービスオーケストレーション管理機能８４０は、「所望のサービス」属性を解析し、プロファイルが１つ以上の標的上で編成されるべきことを定義する所望の組のサービス、および管理機能８４０が行わなければならない対応する動作を決定する。機能８４０はまた、この要求にサービス提供することが、同一のサービスノード上でローカルにホストされるか、またはネットワーク内の他の場所にあるかのいずれかである任意の他のサービスオーケストレーション管理機能と協働することを要求するであろうかどうかも決定する。それは、任意の追加のサービスオーケストレーションプロファイル８２０が「所望のサービス」プロファイル属性において参照されている（すなわち、リンクされている）か、またはその中に含まれているかどうかを確認するためにチェックすることによって、これを行う。例えば、サービス層プロファイル内の「所望のサービス」属性は、１つ以上の子サービス能力プロファイル８２０を参照することができる。
【０１１８】
図１０Ｂのステップ１２では、子サービスオーケストレーションプロファイル８２０が「所望のサービス」属性の中に含まれていたか、または参照されていた場合、サービスオーケストレーション管理機能８４０は、子サービスオーケストレーション管理機能へのそれ自身の要求を開始する。子サービスオーケストレーションプロファイル８２０がプロファイルの中に明示的に含まれていない場合、サービスオーケストレーション管理機能８４０は、それが維持する情報に基づいて、それ自身の組の子機能を選択することができる。親サービスオーケストレーション管理機能８４０はまた、その子について新しいプロファイルを作成し得、そして、それをトリガすることができる。そうすることで、機能は、（例えば、これらの子機能に利用可能にするサービスオーケストレーションプロファイルを調整することによって）子サービスオーケストレーション管理機能によって行われるサービスオーケストレーションを調整することができる。要求を受信すると、これらの機能は、ここで説明されているものと同一の方法を使用して、それを取り扱う。結果として、サービスオーケストレーション要求を処理する調整された階層方法が達成される。
【０１１９】
図１０Ｂのステップ１３では、それ自身の組のサービスオーケストレーション動作を完了し、任意の子サービスオーケストレーション動作が失敗なく行われたことを確認した後、サービスオーケストレーション管理機能８４０は、それが行うようにトリガされた全体的サービスオーケストレーション動作の状態を計算する。この状態は、明示的なクライアント要求がオーケストレーションをトリガした場合、クライアントに返されることができる。この応答に基づいて、クライアントは、オーケストレーションが成功したか、失敗したか、または部分的に成功した（すなわち、一部のサービスオーケストレーションが完了したが、一部は完成しなかった）かを決定し得る。この情報を使用して、この応答に基づき、次いで、クライアントは、その次の動作（例えば、オーケストレーションをもう１回行う、またはこれらの結果で間に合わせる）を選択し得る。
【０１２０】
（サービス公開および発見）
その対応するサービスノードのネットワーク、サービスノード、サービス層、またはサービス能力のためにサービスを編成することに加えて、サービスオーケストレーション管理機能８４０はまた、利用可能なサービスの目録を保ち、サービスオーケストレーションプロファイル８２０を介してこの目録を公開する方法もサポートする。サービスオーケストレーション管理機能８４０はさらに、公開されたサービスオーケストレーションプロファイル８２０の発見をサポートする。サービスオーケストレーションプロファイル８２０の公開および発見は、これらのプロファイルを動的に発見し、対応するサービスノードのネットワーク、サービスノード、サービス層、またはサービス能力の現在の構成を決定する能力をサービスオーケストレーションクライアント（例えば、アプリケーションならびにネットワーク内の他のサービスオーケストレーション管理機能等）が有することを可能にする。そうすることで、クライアントは、現在の構成が適切であるかどうか、またはオーケストレーションが保証されているかどうかを決定することができる。
【０１２１】
サービスオーケストレーションは、基礎的有効化技術としてサービス発見を活用することができるが、それ自身をサービス発見と区別する。サービスオーケストレーションは、典型的には、サービス発見の後に来るステップであり、特定のサービスノード上で、またはサービスノードのネットワークにわたってホストされるサービスの動的配列、管理、および調整等の特徴をサポートする。サービスオーケストレーションはまた、ネットワーク内のどのサービスノード上のどのサービスが、異なるクライアント（例えば、アプリケーションならびに他のサービス）によって使用され得るかを調整および制御すること等の特徴をサポートすることもできる。
【０１２２】
図１１は、サービスオーケストレーションプロファイルを公開することに関連して行われる処理のフローチャートを描写する。図１１を参照すると、ステップ１では、サービスオーケストレーション管理機能８４０が、サービスオーケストレーショントリガ（例えば、クライアントからの要求）を受信する。
【０１２３】
図１１のステップ２では、サービスオーケストレーション管理機能８４０が、トリガからサービスオーケストレーションプロファイル８２０を抽出することができる。
【０１２４】
図１１のステップ３では、サービスオーケストレーション管理機能８４０が、規定された標的に対して所望のサービスオーケストレーションを行う。例えば、管理機能８４０は、対応するサービスオーケストレーションプロファイル８２０とともに、要求をその子サービスオーケストレーション管理機能に伝送し得る。
【０１２５】
図１１のステップ４では、サービスオーケストレーション管理機能８４０は、オーケストレーションプロファイル８２０を公開することが許可されているかどうかを決定する。例えば、オーケストレーション管理機能８４０は、それがクライアントによって許可されているかどうかを決定し得る。クライアントによって許可されていない場合、オーケストレーション管理機能８４０は、ステップ８でプロファイルを公開しない。
【０１２６】
クライアントによって許可された場合、図１１のステップ５では、サービスオーケストレーション管理機能８４０は、それが失敗なく規定された標的上に編成した組のサポートされたサービスを公開するサービスプロファイルを作成する。これらのプロファイル内で、上で議論される「サポートされたサービス」属性の中で提案されるもの等、各個々のプロファイルに対するサポートされたサービスが公開されることができる。代替として、サービスオーケストレーション管理機能８４０は、どのようにしてクライアントがオーケストレーションを行い得るかに関する情報をクライアントに提供する、サービスプロファイルテンプレートを公開することができる。例えば、公開されたサービスプロファイルテンプレートは、新しいサービスプロファイルを作成する方法、または作成され得る新しいサービスプロファイルのタイプを記述し得る。
【０１２７】
ステップ６では、サービスオーケストレーション管理機能８４０は、発見するために見込みオーケストレーションクライアントに利用可能にされるように、サービスプロファイルを公開する。サービスオーケストレーション管理機能８４０は、サービスオーケストレーション適用可能コンテキスト情報を、それが公開するプロファイルに追加／更新し得る。例えば、サービスオーケストレーション管理機能は、所与のプロファイルに関連付けられる現在の性能／負荷測定基準、プロファイルのために課金されている現在の料金等を含むように、プロファイル情報を追加または更新し得る。
【０１２８】
図１１のステップ７では、サービスオーケストレーション管理機能８４０は、現在アクティブであり、サービスノードのネットワーク、サービスノード、サービス層、またはサービス能力によってサポートされているサービスプロファイルの目録を維持する。結果として、サービスオーケストレーション管理機能８４０は、もはやアクティブではない、任意の有効期限切れのプロファイルを非公開にする（すなわち、除去する）ことができる。
【０１２９】
図１２は、サービスオーケストレーションプロファイルの発見に関連して行われる処理のフローチャートを描写する。図１２を参照すると、ステップ１では、オーケストレーションクライアントが、上で議論されるように、サービスオーケストレーションプロファイル８２０内で定義される属性を含むクエリから成るサービス発見クエリを生成する。
【０１３０】
図１２のステップ２では、サービスオーケストレーションクライアントが、任意の適用可能なサービスノード、サービス層、またはサービス能力がクエリ属性に合致するサービスプロファイルを有するかどうかを発見するために、発見要求を１つ以上の標的サービスオーケストレーション管理機能８４０に伝送する。
【０１３１】
図１２のステップ３では、サービスオーケストレーション管理機能８４０が、発見要求を受信し、発見クエリ文字列を抽出する。
【０１３２】
図１２のステップ４では、クエリ文字列の中で規定される属性に対して、の公開された組のサービスプロファイルを照会し、サービスオーケストレーション管理機能８４０は、任意の合致プロファイルが存在するかどうかを決定する。
【０１３３】
図１２のステップ５では、サービスオーケストレーション管理機能８４０が、リストまたは任意の合致サービスプロファイルのリスト、またはそれへのリンクを返す。
【０１３４】
（ｏｎｅＭ２Ｍサービスオーケストレーション実施形態）
サービスオーケストレーションのためのシステムおよび方法は、サービスを利用するいくつかの異なるネットワーク技術のうちのいずれかに適用され得る。開示されるシステムおよび方法は、Ｍ２ＭおよびＩｏＴ技術への特定の適用可能性を有する。例えば、開示されるシステムおよび方法は、ｏｎｅＭ２Ｍアーキテクチャで実装され得る。
【０１３５】
図１３は、本明細書に説明されるようなサービスオーケストレーションを提供するように適合される、例示的ｏｎｅＭ２Ｍアーキテクチャを開示する。図１３の特定の実施形態では、集中サービスオーケストレーション管理機能１３１０が、ネットワーク内の集中ノード上に常駐し、オーケストレーションクライアント１３１２（例えば、ＡＥおよびＣＳＥ）ならびにオーケストレーション標的１３２０（例えば、ＣＳＥ）にアクセス可能にされる。オーケストレーションプロファイルは、同様に、集中ノード上に記憶され、そこで処理される。新しい基準点（Ｍｓｏ）が、この集中サービスオーケストレーション管理機能１３１０にインターフェース接続するために定義される。基準点は、図１０、１１、および１２に関連して上で議論される、提案された要求をサポートすることができる。この集中アーキテクチャを使用して、個々のサービスノード、ＣＳＥ、もしくはＣＳＦ、ならびにサービスノードＣＳＥ、および／またはＣＳＦのネットワークのオーケストレーションが、サポートされることができる。
【０１３６】
ｏｎｅＭ２Ｍアーキテクチャはまた、上で議論されるようなサービスオーケストレーションの分散型実装もサポートする。図１４は、サービスオーケストレーションの分散型実装を図示する。図１４に示されるように、サービスオーケストレーション管理機能１４４０は、個々のサービスノードのオーケストレーションならびにサービスノードのネットワークの調整されたオーケストレーションをサポートする目的で、各サービスノード（例えば、インフラストラクチャノード１４１８、中央ノード１４２２、およびアプリケーション特定のノード１４２４）上で実行される。オーケストレーション管理機能は、サービスオーケストレーションを実装することに関連して上で説明されるようなオーケストレーションプロファイル１４２０を処理する。サービスオーケストレーション管理機能１４４０および対応するオーケストレーションプロファイル１４２０はまた、サービスノード上で実行するＣＳＥ１４３０上でホストされ得る。例示的実施形態では、サービスオーケストレーション管理機能１４４０は、ＣＳＥオーケストレーションをサポートする目的で新しいサービスオーケストレーション管理ＣＳＦとして実装され得る。
【０１３７】
図１５は、共通サービスエンティティ（ＣＳＥ）１５０６上でホストされる種々の共通サービス機能（ＣＳＦ）１５０８を描写する略図である。図１５で描写されるＣＳＥ１５０６では、サービスオーケストレーション管理機能１５４０および対応するプロファイル１５２０は、ＣＳＦ１５０８上でホストされ、図１０、１１、および１２に関連して上で説明されるように動作する。したがって、共通サービス機能およびプロファイルは、ＣＳＥ１５０６に関連付けられるＣＳＦ１５０８内で分散され得る。一実施形態では、図１５でも図示されるように、オーケストレーションを行うために集中ノードとして動作する、新しい共通サービスオーケストレーションＣＳＦ１５１２が作成され得る。特定の実装要件に応じて、これらの実施形態の一方または両方のいずれかが、ＣＳＦを編成するために使用され得る。
【０１３８】
（ｏｎｅＭ２Ｍサービスオーケストレーションリソース）
ｏｎｅＭ２Ｍアプリケーションは、頻繁に、表現状態転送（ＲＥＳＴｆｕｌ）アーキテクチャを使用して実装される。そのような場合において、ＣＳＦは、一組のＲＥＳＴｆｕｌ「リソース」として表される。リソースは、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有する、アーキテクチャ内の一意にアドレス可能なエンティティである。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースの参照を含む。子リソースの有効期限は、親のリソースの有効期限によって限定される。各リソースは、リソースについての情報を記憶する一組の「属性」をサポートする。
【０１３９】
本明細書に説明されるようなサービスオーケストレーション処理は、サービスオーケストレーション管理機能のためのＲＥＳＴｆｕｌリソースベースのプログラミングインターフェースを使用して実装され得る。オーケストレーションクライアントは、異なるタイプのサービスオーケストレーションを行うサービスオーケストレーション管理機能を開始するために、ＲＥＳＴｆｕｌリソースベースのリソースを使用し得る。リソースはまた、サービスオーケストレーション管理機能によって、および／またはオーケストレーション標的がサポートするサービスオーケストレーションプロファイルを公開するため、ならびにサービスオーケストレーション管理機能の間の協働（例えば、サービスオーケストレーションプロファイルの交換）のために、使用され得る。
【０１４０】
例示的実施形態では、上で議論されるオーケストレーションプロファイルに対応する＜ｐｒｏｆｉｌｅ＞リソースは、サービスオーケストレーション管理機能が規定されたオーケストレーション標的に対してサービスオーケストレーションを行うことを要求するために使用され得る。＜ｐｒｏｆｉｌｅ＞リソースはまた、管理機能が責任を負う対応するサービスノード、ＣＳＥ、またはＣＳＦのサービスオーケストレーション属性を公開するために、サービスオーケストレーション管理機能によって使用され得る。同様に、＜ｐｒｏｆｉｌｅ＞リソースはまた、別のサービスノード、ＣＳＥ、またはＣＳＦの公開されたサービスオーケストレーション属性を発見するためにも使用され得る。
【０１４１】
図１６は、本明細書で議論されるようなオーケストレーションプロファイルに対応する＜ｐｒｏｆｉｌｅ＞リソースの例示的実施形態を図示する略図である。図１６（および図１７−２０）に関連して、ｏｎｅＭ２Ｍ表記の典型である、以下の表記が、概して適用さる：四角いボックスがリソースおよび子リソースに使用される；丸い角を伴う四角いボックスが属性に使用される；平行四辺形がリソースの集合に使用される；各属性および子リソースの多様性が定義される；「＜”ａｎｄ“＞」で区切られたリソース名は、リソースの作成中に割り当てられる名前を示す。図１６に示されるように、＜ｐｒｏｆｉｌｅ＞リソースは、それに関連付けられる例示的属性を有する。属性は、オーケストレーションプロファイルに関連して上で説明される種々の属性に対応する。図１６は、変数「ｎ」を介して、＜ｐｒｏｆｉｌｅ＞リソースが属性と多様性関係を有することを示す。換言すると、表記は、＜ｐｒｏｆｉｌｅ＞に対して「ｎ」個の特定の属性があり得ることを示す。以下のチャートは、上で議論される種々のオーケストレーションプロファイル属性について、ＲＥＳＴｆｕｌ＜ｐｒｏｆｉｌｅ＞とともに存在し得る多様性を示す。例えば、以下のチャートで記述されるように、特定の＜ｐｒｏｆｉｌｅ＞に対して１つのｐｒｏｆｉｌｅＩＤ属性のみがあろう。同様に、特定の＜ｐｒｏｆｉｌｅ＞に対して１つのタイプのみがあり得る。しかしながら、ｏｒｃｈｅｓｔｒａｔｉｏｎＴａｒｇｅｔｓおよびｓｕｐｐｏｒｔｅｄＳｅｒｖｉｃｅｓ等の他の属性に関して、ゼロから複数の値までのいずれかがあり得る。
【０１４２】
【表１】
0006560259.tif 000005
【０１４３】
サービスオーケストレーション管理機能がＣＳＥの外側に、またはそれから独立してホストされる実施形態（すなわち、集中サービスオーケストレーション管理機能）に関して、＜ｐｒｏｆｉｌｅ＞リソースは、ｏｎｅＭ２Ｍ定義ＣＳＥリソースツリーから独立してインスタンス化されることができる。例えば、＜ｐｒｏｆｉｌｅ＞リソースは、集中サービスオーケストレーション管理機能のための別個のリソースツリーの中でインスタンス化されることができ、集中サービスオーケストレーション管理機能は、ネットワーク内のそれ自身のノード上でそれ自身によってホストされる。
【０１４４】
サービスオーケストレーション管理機能がＣＳＥ内またはＣＳＦ内でホストされる実施形態に関して、＜ｐｒｏｆｉｌｅ＞リソースは、ｏｎｅＭ２Ｍ  ＣＳＥリソースツリー内で種々のレベルにおいてインスタンス化されることができる。一例示的実施形態では、＜ｐｒｏｆｉｌｅ＞リソースは、図１７に示されるように＜ｎｏｄｅ＞リソースの下でインスタンス化されることができる。本実施形態は、サービスノードのオーケストレーションに適している。例えば、この特定の＜ｐｒｏｆｉｌｅ＞リソースは、サービスノードによってサポートされるＣＳＥおよび／またはＣＳＦの数ならびにタイプを編成するために使用され得る。本実施形態はまた、ノードのサービスプロファイルを公開および／または発見するためにも使用され得る。
【０１４５】
別の実施形態では、＜ｐｒｏｆｉｌｅ＞リソースは、図１８に示されるように、ＣＳＥ＜ｂａｓｅＵＲＩ＞リソースの下または＜ｒｅｍｏｔｅＣｓｅ＞リソースの下でインスタンス化されることができる。本実施形態は、ＣＳＥが共通／一般構成をそのクライアントの全てに提供することができるように、ＣＳＥ（すなわち、サービス層）のオーケストレーション（すなわち、ＣＳＥの非アプリケーション特定のオーケストレーション）に適している。本実施形態はまた、ＣＳＥサービスプロファイルを公開および／または発見するために使用されることもできる。
【０１４６】
別の実施形態では、＜ｐｒｏｆｉｌｅ＞リソースは、図１９に示されるように、＜ａｐｐｌｉｃａｔｉｏｎ＞リソースまたは＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎ＞リソースの下でインスタンス化されることができる。本実施形態は、区別されたサービスを、全てのアプリケーションにわたる共通構成ではなく、その登録されたアプリケーションの各々に提供するように、ＣＳＥのオーケストレーションに適している。本実施形態はまた、ＣＳＥアプリケーション特定のサポートされたサービスプロファイルを公開および／または発見するために使用されることもできる。
【０１４７】
さらに別の実施形態では、＜ｐｒｏｆｉｌｅ＞リソースは、図２０に示されるように、１つ以上のＣＳＦ特定のリソースの下でインスタンス化されることができる。本実施形態では、＜ｃｓｆＮ＞は、特定のＣＳＦインスタンスに適用可能であるｏｎｅＭ２Ｍ定義リソースを提示するように意図されていることに留意されたい。例えば、既存のｏｎｅＭ２Ｍ仕様は、ＤＭＲ  ＣＳＦのための＜ｃｏｎｔａｉｎｅｒ＞リソース、ＣＭＤＨ  ＣＳＦのための＜ｄｅｌｉｖｅｒｙ＞リソース、およびＧＭＧ  ＣＳＦのための＜ｇｒｏｕｐ＞リソース等のＣＳＦ特定のリソースを定義する。ＣＳＦ特定のリソースの下で＜ｐｒｏｆｉｌｅ＞サブリソースをサポートすることによって、本実施形態は、特定のＣＳＦおよびそれがサポートする特徴のオーケストレーションに使用されることができる。本実施形態はまた、ＣＳＦのサポートされたサービスプロファイルを公開および／または発見するために使用されることもできる。
【０１４８】
（そのローカルＣＳＥ上でＣＳＦを編成するアプリケーション）
図２１Ａ−２１Ｂは、ローカルＣＳＥ上でＣＳＦを編成することに関連付けられる例示的処理を描写する略図を提示する。例示的シナリオでは、メッセージングは、図１３に関連して上で記述されるＭｓｏ基準点を経由して行われる。
【０１４９】
図２１Ａを参照すると、ステップ１では、ＣＳＥ上のサービスオーケストレーション管理機能（例えば、図１３の１３１０）が、上で開示される方法を使用して、利用可能なＣＳＥサービスプロファイルをローカルリソース（例えば、ｂａｓｅＵＲＩ／＜ｐｒｏｆｉｌｅ＞）に公開する。
【０１５０】
図２１Ａのステップ２では、アプリケーションが、そのローカルＣＳＥへのｏｎｅＭ２Ｍ登録を失敗なく行う。図２１Ａに示されるように、この処理は、ステップ２Ａで、アプリケーションが特定の要求（例えば、ＣＲＥＡＴＥ  ｂａｓｅＵＲＯ／＜ａｐｐｌｉｃａｔｉｏｎ＞）を送信することを伴い得、その特定の要求は、受信され、ステップ２Ｂで、対応するリソース（例えば、ｂａｓｅＵＲＩ／ａｐｐｌｉｃａｔｉｏｎ）を作成することによって、サービス層に登録される。成功を示す応答が、ステップ２ＣでＣＳＥによってアプリケーションに伝送され得る。
【０１５１】
２１Ａのステップ３では、アプリケーションが、ＣＳＥサービスプロファイル発見要求をそのローカルＣＳＥに送信し、それをサポートし得る任意の利用可能なＣＳＥサービスプロファイルを見出そうとする。図２１Ａに示されるように、例示的シナリオでは、アプリケーションは、ＲＥＴＲＩＥＶＥ  ｂａｓｅＵＲＩ？ｓｅａｒｃｈＳｔｒｉｎｇ＝“Ｐｒｏｆｉｌｅ  Ｔｙｐｅ＝ＣＳＥ  Ｐｒｏｆｉｌｅ”等の要求を作成して伝送し得る。
【０１５２】
図２１Ａのステップ４では、ＣＳＥ上のサービスオーケストレーション管理機能は、“Ｐｒｏｆｉｌｅ  Ｔｙｐｅ＝ＣＳＥ  Ｐｒｏｆｉｌｅ”に構成されたｓｅａｒｃｈＳｔｒｉｎｇ属性を有するリソースを探すリソース発見を行うことによって、サービスプロファイル発見要求を処理する。
【０１５３】
図２１Ｂのステップ５では、ＣＳＥサービスオーケストレーション管理機能が、＜ｐｒｏｆｉｌｅ＞リソースへのリンクのリストでアプリケーションに応答する。各リンクは、ＣＳＥが現在サポートしているサービスプロファイルを表す。リンクは、ＵＲＩならびにプロファイルを記述する追加のサービスプロファイル属性等の情報を含むことができる。
【０１５４】
図２１Ｂのステップ６では、アプリケーションが、随意に、プロファイルについての追加の情報を入手するために、１つ以上のプロファイルをフェッチする。アプリケーションは、プロファイルのうちのいずれかがアプリケーションの要件を満たすかどうかを決定する。
【０１５５】
図２１Ｂのステップ７では、既存のプロファイルのうちのいずれもアプリケーションの要件を満たさない場合、アプリケーションは、ＣＳＥ内でホストされるサポートされたアプリケーション規定のＣＳＦの構成でＣＳＥを構成するための新しいサービスオーケストレーションプロファイルを作成する。
【０１５６】
図２１Ｂのステップ８では、アプリケーションが、サービスオーケストレーションプロファイルを含むサービスオーケストレーション要求を生成し、そのローカルＣＳＥに伝送する。この要求は、新しい＜ｐｒｏｆｉｌｅ＞リソースを作成する（ＣＲＥＡＴＥ）要求内でＣＳＥに送信されることができる。この要求のＵＲＩは、オーケストレーションがアプリケーション特定のＣＳＥのオーケストレーションであるために、ｂａｓｅＵＲＩ／＜ａｐｐｌｉｃａｔｉｏｎ＞／＜ｐｒｏｆｉｌｅ＞を標的にすることができる。
【０１５７】
図２１Ｂのステップ９では、ＣＳＥの中のサービスオーケストレーション管理機能が、図１０Ａ−１０Ｂに関連して上で説明されるようにサービスオーケストレーションプロファイルを解析することによって、サービスオーケストレーション要求を処理する。このアプリケーション特定のオーケストレーションは、ＣＳＥが、それに登録する各アプリケーションのための区別されたサービス（例えば、異なるＣＳＦ構成）をサポートすることを可能にすることができる。
【０１５８】
図２１Ｂのステップ１０では、ＣＳＥは、サービスオーケストレーション要求が成功したかどうかを示す応答で、アプリケーションに応答する。
【０１５９】
（ＣＳＥのネットワークにわたってＣＳＦを編成する）
図２２Ａ−２２Ｄは、ＣＳＥのネットワークにわたってＣＳＦを編成することに関連付けられる例示的処理を描写する略図である。
【０１６０】
図２２Ａを参照すると、ステップ１では、ＡＥまたはＣＳＥが、互いに調整されたＣＳＥ構成でネットワーク内のサービスノードを構成するための新しいサービスオーケストレーションプロファイルを作成する。例えば、プロファイルは、同一のタイプであるＣＳＥをサポートし、相補的構成およびＣＳＦをサポートするサービスノードを構成すべきであり得る。
【０１６１】
図２２Ａのステップ２Ａでは、ＡＥまたはＣＳＥが、サービスオーケストレーション要求を生成し、ネットワーク内の集中サービスオーケストレーション管理機能に伝送する。この要求は、サービスオーケストレーション管理機能上で新しい＜ｐｒｏｆｉｌｅ＞リソースを作成する要求（例えば、ＣＲＥＡＴＥ／＜ｐｒｏｆｉｌｅ＞Ｐａｌｐａｄ：Ｓｅｒｖｉｃｅ  Ｏｒｃｈｅｓｔｒａｔｉｏｎ  Ｐｒｏｆｉｌｅ）内で送信されることができる。
【０１６２】
図２２Ａのステップ３では、サービスオーケストレーション管理機能が、図１０Ａ−１０Ｂに関連して上で議論されるように、サービスオーケストレーションプロファイルを解析し、ネットワーク内の各適用可能サービスノードに対してサービスオーケストレーション要求を開始することによって、サービスオーケストレーション要求を処理する。
【０１６３】
図２２Ａのステップ４Ａでは、集中サービスオーケストレーションノード上のサービスオーケストレーション管理機能が、サービスオーケストレーション要求を生成し、ネットワーク内のインフラストラクチャサービスノードに伝送する。例示的シナリオでは、要求は、以下の通り、すなわち、ペイロード：サービスオーケストレーションプロファイルを伴うＣＲＥＡＴＥ＜ｎｏｄｅ＞／＜ｐｒｏｆｉｌｅ＞であり得る。ステップ４Ｂでは、インフラストラクチャサービスノード上のサービスオーケストレーション管理機能が、要求を処理し、図１０Ａ−１０Ｂに関連して上で説明される処理と一致して、ノードのＣＳＥを構成する。例えば、インフラストラクチャサービスノード上のサービスオーケストレーション管理機能は、関連オーケストレーションプロファイルを解析し、上で説明されるような関連オーケストレーションを行なり得る。図２２Ｃのステップ４Ｃでは、インフラストラクチャサービスノードが、処理の状態を提供する応答を送信する。例示的シナリオでは、インフラストラクチャサービスノードは、オーケストレーションが成功であったことを示す。
【０１６４】
図２２Ｃのステップ５Ａでは、集中サービスノードのサービスオーケストレーション管理機能が、サービスオーケストレーション要求を生成し、ネットワーク内の中央サービスノードに伝送する。例示的シナリオでは、要求は、以下の通り、すなわち、ペイロード：サービスオーケストレーションプロファイルを伴うＣＲＥＡＴＥ＜ｎｏｄｅ＞／＜ｐｒｏｆｉｌｅ＞であり得る。図２２Ｄのステップ５Ｂでは、中央サービスノード上のサービスオーケストレーション管理機能が、要求を処理し、図１０Ａ−１０Ｂに関連して上で説明される処理と一致して、ノードのＣＳＥを構成する。例えば、中央サービスノード上のサービスオーケストレーション管理機能は、受信されたオーケストレーションプロファイルを解析し、対応するオーケストレーションを行なり得る。図２２Ｄのステップ５Ｃでは、中央サービスノードが、処理の状態を提供する応答を送信する。例示的シナリオでは、中央サービスノードは、オーケストレーションが成功であったことを示す。
【０１６５】
図２２Ｃのステップ６Ａでは、集中サービスノードのサービスオーケストレーション管理機能が、サービスオーケストレーション要求を生成し、ネットワーク内のアプリケーション特定のサービスノードに伝送する。例示的シナリオでは、要求は、以下の通り、すなわち、ペイロード：サービスオーケストレーションプロファイルを伴うＣＲＥＡＴＥ＜ｎｏｄｅ＞／＜ｐｒｏｆｉｌｅ＞であり得る。図２２Ｄのステップ６Ｂでは、アプリケーション特定のサービスノード上のサービスオーケストレーション管理機能が、要求を処理し、図１０Ａ−１０Ｂに関連して上で説明される処理と一致して、ノードのＣＳＥを構成する。例えば、アプリケーションサービスノード上のサービスオーケストレーション管理機能は、受信されたオーケストレーションプロファイルを解析し、対応するオーケストレーションを行なり得る。図２２Ｄのステップ６Ｃでは、アプリケーションサービスノードが、処理の状態を提供する応答を送信する。例示的シナリオでは、アプリケーションサービスノードは、オーケストレーションが成功であったことを示す。
【０１６６】
図２２Ｃのステップ２Ｂでは、集中サービスノードのサービスオーケストレーション管理機能が、状態応答を生成し、最初にオーケストレーションを要求したＡＥまたはＣＳに伝送する。例示的シナリオでは、集中サービスノードは、オーケストレーションが成功したことを示す。
【０１６７】
（ＸＭＬベースのサービスオーケストレーションプロファイル階層）
上で説明されるサービスオーケストレーションプロファイルは、任意の好適な形式で実装され、任意の好適な技術を採用し得る。例えば、サービスオーケストレーションプロファイルは、ＸＭＬまたはＷＳＤＬフォーマットファイルであり得る。以下では、ＸＭＬでフォーマットされる例示的オーケストレーションファイルが列挙される。この特定の実施例は、ある一定の組のＣＳＦをクライアントに利用可能にするためのｏｎｅＭ２Ｍ  ＣＳＥのオーケストレーションを要求するために、例えば、クライアント（例えば、アプリケーション）によって作成され得るオーケストレーションプロファイルを示す。この特定の例示的実施形態では、上で議論されるサービスオーケストレーションプロファイル属性の一部のみが適用可能である。例示的ＸＭＬ符号化プロファイルは、プロファイルタイプ（すなわち、ＣＳＥ＿ＯＲＣＨＥＳＴＲＡＴＥ）、編成されるべき標的ＣＳＥ（すなわち、ｃｓｅＸＹＺ）、オーケストレーション（すなわち、２０１４−１０−２４−０６：００）を行うべき予定に入れられた時間、オーケストレーションを適格とするポリシー（すなわち、ＣＳＥが公的に利用可能なＣＳＥである場合にサービスオーケストレーションのみを行う）、および各サービスについての情報（例えば、タイトル、プロファイルへのリンク、費用、アクセス、性能、ピア等）を含む所望の組のサービス（すなわち、ｏｎｅＭ２Ｍ  ＣＭＤＨ、ＲＥＧ、およびＤＭＲサービス）等の属性を含む。示される各ＸＭＬ要素に対して、サービスオーケストレーションプロファイル属性の例示的値が、追加明確性および読みやすさのために示される。
【０１６８】
【数４】
0006560259.tif 000006
【０１６９】
【数５】
0006560259.tif 000007
【０１７０】
【数６】
0006560259.tif 000008
【０１７１】
（ＪＳＯＮベースのサービスオーケストレーションプロファイル階層）
サービスオーケストレーションプロファイルは、ＪＳＯＮを使用してフォーマットされ得る。以下では、ＪＳＯＮフォーマットプロファイルの実施例が列挙される。この特定の例示的実施形態は、例えば、アプリケーション、サービスオーケストレーション管理機能等のネットワーク内の他のエンティティによって発見および／または使用されることができるように、公開のためにＣＳＥによって作成され得るものである。この特定の実施例は、プロファイルの意図された用途に適用可能である潜在的サービスオーケストレーションプロファイル属性の特定の一部を含む。この特定の例示的プロファイルでは、ＪＳＯＮ符号化プロファイルは、プロファイルタイプ（すなわち、ＣＳＥ）、編成される標的ＣＳＥ（すなわち、ｃｓｅＸＹＺ）、サービスオーケストレーションコンテキスト（すなわち、ＣＳＥがオーケストレーション要求を現在受け入れている）、および各サービスについての情報（例えば、タイトル、プロファイルへのリンク、費用、アクセス、性能、ピア等）を含むサポートされた組のサービス（すなわち、ｏｎｅＭ２Ｍ  ＣＭＤＨ、ＲＥＧ、およびＤＭＲサービス）等の属性を含む。示される各ＪＳＯＮ要素に対して、サービスオーケストレーションプロファイル属性の例示的値が、追加明確性および読みやすさのために示される。
【０１７２】
【数７】
0006560259.tif 000009
【０１７３】
【数８】
0006560259.tif 000010
【０１７４】
【数９】
0006560259.tif 000011
【０１７５】
（ＷＳＤＬベースのサービスオーケストレーションプロファイル階層）
サービスプロファイルはまた、ＷＳＤＬを使用して符号化され得る。ＷＳＤＬを使用してフォーマットされる、第１の例示的オーケストレーションプロファイルでは、子要素が、ＷＳＤＬテンプレート内のルート‘ｄｅｓｃｒｉｐｔｉｏｎ’要素の下に追加され得る。例えば、子要素は、以下のリストに示されるように、‘ｐｒｏｆｉｌｅ’と呼ばれ得る。‘ｐｒｏｆｉｌｅ’要素の下で、上で説明されるオーケストレーションサービスプロファイル属性の各々に対応する、子要素が定義される。
【０１７６】
【数１０】
0006560259.tif 000012
【０１７７】
【数１１】
0006560259.tif 000013
【０１７８】
ＷＳＤＬを使用してフォーマットされる、第２の例示的実施形態では、新しい子要素が、対応するサービスオーケストレーションプロファイル属性の各々に対して既存のＷＳＤＬ要素の下に追加される。例えば、サービスオーケストレーションプロファイルを選択する属性が、‘ｔｙｐｅｓ’、‘ｉｎｔｅｒｆａｃｅ’、‘ｂｉｎｄｉｎｇ’、および／または‘ｓｅｒｖｉｃｅ’要素の下に追加され得る。サービスオーケストレーションプロファイル属性の種々の順列および組み合わせが、サービスオーケストレーション能力を用いてＷＳＤＬをさらに高めるために、１つ以上のＷＳＤＬ子要素の下に散在させられ得る。以下で列挙される例示的実施形態では、属性が、‘ｓｅｒｖｉｃｅ’要素の下に追加される。
【０１７９】
【数１２】
0006560259.tif 000014
【０１８０】
【数１３】
0006560259.tif 000015
【０１８１】
（例示的コンピューティング環境）
図２３Ａは、例えば、端末デバイス、ユーザ機器（ＵＥ）、またはゲートウェイデバイスであり得る、例示的無線デバイス３０の系統図である。例えば、デバイス３０は、ネットワークアプリケーションドメイン２１０内でユーザによって採用され、図２に関連して参照されるようにネットワークサービスドメイン２１２内のシステムと、かつこのアプリケーションの全体を通してデータを通信する、その上で実行されるアプリケーションを有し得る。さらなる非限定的実施例として、無線デバイス３０は、図２に関連するものを含む、本明細書の全体を通して説明されるゲートウェイ２２６のうちのいずれかであり得る。さらに、デバイス３０は、図２に関連して、かつ本明細書の他の場所で参照されるように、デバイスアプリケーションドメイン２１４内でデバイスを実装するために使用され得る。デバイス３０は、通信ネットワークまたは直接無線リンクを介して信号を伝送および受信するように適合される。図２３Ａに示されるように、デバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。例示的実施形態では、ディスプレイ／タッチパッド／インジケータ４２は、ユーザインターフェースの一部として動作する、１つ以上のインジケータを備え得る。デバイス４０は、実施形態と一致したままで、先述の要素の任意の部分組み合わせを含み得ることが理解されるであろう。このデバイスは、システム間移動性システムおよび方法のための開示されるサービングゲートウェイ拡張を使用する、デバイスであり得る。
【０１８２】
プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプおよび数の集積回路（ＩＣ）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結され得る。図２３Ａは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。
【０１８３】
伝送／受信要素３６は、ｅＮｏｄｅ−Ｂ、Ｈｏｍｅ  ｅＮｏｄｅ−Ｂ、ＷｉＦｉアクセスポイント等に信号を伝送し、および／またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦならびに光信号の両方を伝送および受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
【０１８４】
加えて、伝送／受信要素３６は、単一の要素として図２３Ａで描写されているが、デバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、デバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、デバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
【０１８５】
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、デバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、デバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
【０１８６】
プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。
【０１８７】
プロセッサ３０は、電源４８から電力を受電し得、デバイス３０内の他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、デバイス３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。
【０１８８】
プロセッサ３２はまた、デバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成され得る、ＧＰＳチップセット５０に連結され得る。デバイス３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
【０１８９】
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る、他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
【０１９０】
図２３Ｂは、本明細書に説明されるシステムおよび方法を実装するために使用され得る、例示的なコンピュータシステム１０００のブロック図を描写する。例えば、コンピュータシステム１０００は、例えば、本明細書で参照されるようなサービスノード、サーバ、およびアプリケーションシステムとして動作する、デバイスを実装するために使用され得る。具体的には、コンピュータシステム１０００は、図２に関連して、かつ本明細書の全体を通して説明されるサーバ２２０を実装するために使用され得る。コンピュータシステム１０００は、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。コンピュータ読み取り可能な命令は、コンピュータ読み取り可能な命令自体を記憶し、それらにアクセスするためのコンピュータシステム１０００の命令を含み得る。そのようなソフトウェアは、コンピュータシステム１０００にそれに関連付けられるプロセスまたは機能を行わせるように、中央処理装置（ＣＰＵ）１０１０内で実行され得る。多くの公知のコンピュータサーバ、ワークステーション、パーソナルコンピュータ等では、ＣＰＵ１０１０は、マイクロプロセッサと呼ばれるマイクロ電子チップＣＰＵによって実装され得る。
【０１９１】
動作中、ＣＰＵ１０１０は、命令をフェッチ、復号、および／または実行し得、主要データ転送経路またはシステムバス１００５を介して、他のリソースに、およびそこから情報を転送し得る。そのようなシステムバスは、コンピュータシステム１０００内の構成要素を接続し得、データ交換のための媒体を定義し得る。コンピュータシステム１０００はさらに、システムバス１００５に連結されるメモリデバイスを含み得る。例示的実施形態によると、メモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）１０２５と、読み取り専用メモリ（ＲＯＭ）１０３０とを含み得る。ＲＡＭ１０２５およびＲＯＭ１０３０は、情報が記憶されて読み出されることを可能にする回路を含み得る。一実施形態では、ＲＯＭ１０３０は、修正されることができない、記憶されたデータを含み得る。加えて、ＲＡＭ１０２５に記憶されたデータは、典型的には、ＣＰＵ１０１０または他のハードウェアデバイスによって読み取られ、もしくは変更され得る。ＲＡＭ１０２５および／またはＲＯＭ１０３０へのアクセスは、メモリコントローラ１０２０によって制御され得る。メモリコントローラ１０２０は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。
【０１９２】
加えて、コンピュータシステム１０００は、ＣＰＵ１０１０からプリンタ１０４０、キーボード１０４５、マウス１０５０、およびデータ記憶ドライブ１０５５等の周辺機器に命令を伝達する責任があり得る、周辺機器コントローラ１０３５を含み得る。コンピュータシステム１０００はさらに、ディスプレイコントローラ１０６３によって制御され得るディスプレイ１０６５を含み得る。ディスプレイ１０６５は、コンピュータシステム１０００によって生成される視覚出力を表示するために使用され得る。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、ビデオ等を含み得る。ディスプレイコントローラ１０６３は、ディスプレイ１０６５に送信され得るビデオ信号を生成する、電子構成要素を含み得る。さらに、コンピュータシステム１０００は、コンピュータシステム１０００をネットワーク１０９０等の外部通信ネットワークに接続するために使用され得る、ネットワークアダプタ１０７０を含み得る。
【０１９３】
したがって、出願人らは、サービスを編成するための例示的システムおよび方法を開示している。例示的システムおよび方法では、サービスオーケストレーションプロファイルは、所望のサービスを定義する属性を規定する。サービスオーケストレーションプロファイルは、ノードの間で分散され、互いに階層的に関連し得る。サービスオーケストレーション管理機能は、所望のサービスを決定するためにサービスオーケストレーションプロファイルの中の情報を処理し、所望のサービスを実装するために情報を使用する。開示されるシステムおよび方法は、単一のサービスノードまたは分散型サービスノードのネットワーク（例えば、クラウドベースの展開またはウェブベースのサービス展開）によってサポートされているサービスの自動および動的調整、構成、配列ならびに管理を提供する。
【０１９４】
例証的実施形態が開示されているが、潜在的な実施形態の範囲は、明示的に立案されるものに限定されないことが理解されるであろう。例えば、システムは、ｏｎｅＭ２Ｍアーキテクチャを主に参照して説明されているが、想定された実施形態は、特定のアーキテクチャまたは技術を使用する実装を超えて広がる。例えば、潜在的な実施形態はまた、ウェブサービス実施形態も実装する。潜在的な実装は、全てのタイプのサービス層アーキテクチャ、システム、および実施形態に広がる。
【０１９５】
本明細書で説明される種々の技法は、ハードウェアまたはソフトウェア、もしくは適切である場合、両方の組み合わせに関連して実装され得ることを理解されたい。したがって、本明細書で説明される主題の方法および装置、またはそれらのある側面もしくは部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または任意の他の機械読み取り可能な記憶媒体等の有形媒体で具現化されるプログラムコード（すなわち、命令）の形態を成し得、プログラムコードがコンピュータ等の機械にロードされ、それによって実行されるとき、機械は、本明細書で説明される主題を実践するための装置になる。プログラムコードが媒体上に記憶される場合において、問題になっているプログラムコードが、問題になっている動作を集合的に行う１つ以上の媒体上に記憶され、すなわち、１つ以上の媒体が、まとめて、動作を行うコードを含む場合であり得るが、２つ以上の媒体がある場合、コードの任意の特定の部分が任意の特定の媒体上に記憶されるという要件はない。プログラマブルコンピュータ上のプログラムコード実行の場合、コンピュータデバイスは、概して、プロセッサ、（揮発性ならびに不揮発性メモリおよび／または記憶要素を含む）プロセッサによって読み取り可能なである記憶媒体、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。１つ以上のプログラムは、例えば、ＡＰＩ、再利用可能制御等の使用を通して、本明細書で説明される主題に関連して説明されるプロセッサを実装または利用し得る。そのようなプログラムは、好ましくは、コンピュータシステムと通信するように、高レベル手続き型またはオブジェクト指向プログラミング言語で実装される。しかしながら、プログラムは、所望であれば、アセンブリまたは機械言語で実装することができる。いずれの場合でも、言語は、コンパイラ型またはインタープリタ型言語であり得、ハードウェア実装と組み合わせられ得る。
【０１９６】
例示的実施形態は、１つ以上の独立型コンピュータシステムもしくはデバイスに関連して本明細書で説明される主題の側面を利用することを参照し得るが、本明細書で説明される主題は、そのように限定されず、むしろ、ネットワークまたは分散型コンピューティング環境等の任意のコンピューティング環境に関連して実装され得る。なおもさらに、本明細書で説明される主題の側面は、複数の処理チップまたはデバイスで、もしくはそれらにわたって実装され得、記憶が、同様に複数のデバイスにわたって影響を受けてもよい。そのようなデバイスは、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパーコンピュータ、または自動車および航空機等の他のシステムに組み込まれるコンピュータを含み得る。
【０１９７】
以下は、上の説明で出現し得るサービスレベル技術に関する頭字語のリストである。
Ｅ２Ｅ    エンドツーエンド
ＩｏＴ    モノのインターネット
ＩＰ    インターネットプロトコル
Ｍ２Ｍ    マシンツーマシン
ＳＣ    サービス能力
ＳＣＬ    サービス能力層
ＣＳＦ    能力サービス機能
ＣＳＥ    能力サービスエンティティ
ＡＳＮ    アプリケーションサービスノード
ＶＭ    仮想マシン
本主題は、構造的特徴および／または方法の行為に特定の言語で説明されているが、添付の請求項で定義される主題は、必ずしも上で説明される具体的な特徴もしくは行為に限定されないことを理解されたい。むしろ、上で説明される具体的な特徴および行為は、請求項を実装する例示的形態として開示される。
【図１】
0006560259.tif 000016
【図２】
0006560259.tif 000017
【図３】
0006560259.tif 000018
【図４】
0006560259.tif 000019
【図５】
0006560259.tif 000020
【図６】
0006560259.tif 000021
【図７】
0006560259.tif 000022
【図８】
0006560259.tif 000023
【図９Ａ】
0006560259.tif 000024
【図９Ｂ】
0006560259.tif 000025
【図１０Ａ】
0006560259.tif 000026
【図１０Ｂ】
0006560259.tif 000027
【図１１】
0006560259.tif 000028
【図１２】
0006560259.tif 000029
【図１３】
0006560259.tif 000030
【図１４】
0006560259.tif 000031
【図１５】
0006560259.tif 000032
【図１６】
0006560259.tif 000033
【図１７】
0006560259.tif 000034
【図１８】
0006560259.tif 000035
【図１９】
0006560259.tif 000036
【図２０】
0006560259.tif 000037
【図２１Ａ】
0006560259.tif 000038
【図２１Ｂ】
0006560259.tif 000039
【図２２Ａ】
0006560259.tif 000040
【図２２Ｂ】
0006560259.tif 000041
【図２２Ｃ】
0006560259.tif 000042
【図２２Ｄ】
0006560259.tif 000043
【図２３Ａ】
0006560259.tif 000044
【図２３Ｂ】
0006560259.tif 000045