JP2018139144A - サービスイネーブラ機能 - 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. 請求項１７〜１９のいずれか１項に記載の装置と、
    アプリケーションドメインと
    を備えている、ネットワーク化されたシステム。