JP7179836B2 - 通信ネットワークにおける自動サービス登録 - Google Patents

Description

（関連出願の相互参照）
本出願は、２０１７年９月８日に出願された米国仮特許出願第６２／５５６，１６１号の利益を主張するものであり、その全体が本明細書に参照により援用される。

例えば、ｏｎｅＭ２Ｍ、欧州電気通信標準化機構（European Telecommunications Standards Institute：ＥＴＳＩ）およびオープンコネクティビティファウンデーション（Open Connectivity Foundation：ＯＣＦ）などの多くの標準化団体は、異なる業種からのものであるが、アプリケーション間のデータの交換および共有のための単一の水平プラットフォームを定義する、マシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）／モノのインターネット（Internet-Of-Things：ＩｏＴ）サービス層を開発している。

Ｍ２Ｍ／ＩｏＴサービス層は、サービス層によってサポートされる一群のＭ２Ｍ／ＩｏＴ指向能力（Ｍ２Ｍ／ＩｏＴサービス）に対するアプリケーションおよびデバイスのアクセスを提供してもよい。かかる能力は、アプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）を介し、アプリケーションが利用可能となり得る。例えば、Ｍ２Ｍ／ＩｏＴサービス層は、大量のＭ２Ｍ／ＩｏＴデータを維持していてもよく、このデータは、アプリケーション（適切なアクセス権を有するアプリケーション）によって発見、検索、および／または登録されてもよい。サービス層によって提供され得るＭ２Ｍ／ＩｏＴサービスのさらなる例としては、セキュリティ、課金、デバイス管理、プロビジョニングおよび接続性管理が挙げられる。

ｏｎｅＭ２Ｍ規格は、そのサービス層を「共通サービスエンティティ（Common Service Entity：ＣＳＥ）」の形態で実行する。ｏｎｅＭ２Ｍサービス層の目的は、異なる「垂直」Ｍ２Ｍシステムおよびアプリケーションによって利用可能な「水平」サービスを提供することである。ｏｎｅＭ２Ｍ ＣＳＥは、４個の参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（Application Entity：ＡＥ）とインターフェース接続する。Ｍｃｃ参照点は、同じサービスプロバイダドメイン中の別のＣＳＥとインターフェース接続し、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン中の別のＣＳＥとインターフェース接続する。Ｍｃｎ参照点は、基礎となるネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェース接続する。ＮＳＥは、基礎となるネットワークサービス、例えば、デバイス管理、位置サービスおよびデバイストリガをＣＳＥに提供する。ＣＳＥは、「共通サービス機能（Common Service Function：ＣＳＦ）」と呼ばれる複数の論理機能、例えば、「発見」および「データ管理＆保存」を含んでいてもよい。

ＩｏＴサービス登録者のためのサービス登録（enrollment）プロセスを自動化し、単純化するのに役立ち得るＩｏＴサービス能力を可能にし、消費者が、様々な種類のデバイスを購入し、消費者のネットワークに追加する自由を有し、種々のサービスプロバイダから提供されるサービスを発見し、使用する柔軟性を有することが可能な、さらに拡張可能なＩｏＴエコシステムを可能にするためのシステムおよび方法が本明細書に記載される。これらの能力によって、人間であるサービス登録者が、サービス登録者自身およびその物理的なＩｏＴデバイス、アプリケーション、データおよび認証ユーザ（例えば、家族の一員）を、登録者を表すソフトウェアプロファイル中で仮想化することが可能になり得る。仮想化されると、次いで、サービス登録者は、自身に代わり、自動ＩｏＴサービス登録ソフトウェア機能にサービス登録の複雑さおよび負荷を委ねてもよい。同様に、これらのＩｏＴサービス能力はまた、ＩｏＴサービスプロバイダのためのサービス登録プロセスを自動化するのに役立ち、サービスプロバイダが、サービスプロバイダ自身およびその登録プロセスを、自動ソフトウェア対応プロセス中で仮想化することも可能であってもよい。アーキテクチャも、新しく導入されたＩｏＴサービス登録能力のセットを組み込んだＩｏＴシステムのために導入される。

以下の新しい能力を本明細書に記載する：潜在的なサービス登録者が、潜在的なサービス登録者自身およびそのＩｏＴデバイス、アプリケーション、データおよびユーザを、その後にＩｏＴサービスプロバイダのプラットフォームに登録され得るソフトウェアエンティティ中で仮想化することを可能にする、ＩｏＴサービス能力および方法；ＩｏＴサービスプロバイダが、発見可能なＩｏＴサービス登録情報を、その分散されたＩｏＴサービスプラットフォームを介して公開することを可能にする、ＩｏＴサービス能力および方法（これにより、潜在的なサービス登録者が、そのＩｏＴサービスプラットフォームを介し、サービスプロバイダによって公開される利用可能なサービス登録オプションを照会および発見することも可能になる）；サービス登録者が、サービスプロバイダのプラットフォームとの安全な関連付け（セキュアアソシエーション）を確立し、この安全な関連付けを介し、サービスプロバイダに安全に登録／再登録／登録解除することを可能にするＩｏＴサービス能力および方法；被仮想化ＩｏＴサービス登録者が、被仮想化ＩｏＴサービス登録者自身およびそのＩｏＴデバイス、アプリケーション、データおよび認証ユーザをＩｏＴサービスプロバイダのプラットフォームに安全かつ動的に登録することを可能にする、ＩｏＴサービス能力および方法（これにより、ＩｏＴサービスプラットフォームが、登録者に、自動化された登録サービスのセット、例えば、登録者のための認証ポリシーの自動作成、登録者のＩｏＴデバイスおよびアプリケーションの自動利用登録（auto registration）および登録者データの自動インポートを提供することが可能になり得る）。

この概要は、以下の詳細な説明で詳しく説明する一連の概念を簡略化したものである。この概要は、特許請求の範囲の主題の主要な特徴または必須な特徴を特定することも、特許請求の範囲の主題の範囲を限定するために使用されることも意図していない。さらに、特許請求の範囲の主題は、本開示のいずれかの部分に示されるいずれかまたは全ての欠点を解決する限定事項に限定されない。

添付の図面と併せて例として、以下の記載からさらに詳細な理解が得られるだろう。

図１は、ＩｏＴサービス登録者の関係の階層を示す図である。 図２は、アプリケーションプロトコルとアプリケーションとの間にサービス層を有するプロトコルスタックの一例を示す図である。 図３は、Ｍ２Ｍ／ＩｏＴ配置の一例を示す図である。 図４は、ｏｎｅＭ２Ｍサービス層アーキテクチャの一例を示す図である。 図５は、ｏｎｅＭ２Ｍによって現時点で定義されているＣＳＦを示す図である。 図６は、ｏｎｅＭ２Ｍによってサポートされる構成例を示す図である。 図７は、ＩｏＴサービス登録を自動化するためのプロセスの一例を示すフロー図である。 図８は、自動ＩｏＴサービス登録アーキテクチャの配置の一例を示す図である。 図９は、自動ＩｏＴサービス登録アーキテクチャの配置の別の例を示す図である。 図１０は、自動ＩｏＴサービス登録クライアントの一例を示す図である。 図１１は、自動ＩｏＴサービス登録サーバの一例を示す図である。 図１２は、ｏｎｅＭ２Ｍサービス加入者登録アーキテクチャの一実施形態例を示す図である。 図１３は、ｏｎｅＭ２Ｍリソース属性の一例を示す図である。 図１４は、新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図１５は、ｏｎｅＭ２Ｍサービス登録オプションを公開する一例のシーケンス図である。 図１６は、ｏｎｅＭ２Ｍサービス登録オプションを発見する一例のシーケンス図である。 図１７は、サービス加入者クレデンシャルを管理するサービスプロバイダＡＰＩの一例を示す図である。 図１８は、サービス加入者クレデンシャルを作成する一例のシーケンス図である。 図１９は、ｏｎｅＭ２Ｍサービス加入者クレデンシャルブートストラップＡＰＩの一実施形態例を示す図である。 図２０は、クレデンシャルをブートストラップする一例のシーケンス図である。 図２１は、ｏｎｅＭ２Ｍサービス加入者登録情報リソースの一実施形態例を示す図である。 図２２は、サービス加入者がサービスプロバイダに登録する一例のシーケンス図である。 図２３は、新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２４は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２５は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２６は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２７は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２８は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２９は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図３０は、被仮想化サービス加入者の少なくとも１つのデバイスをサービス層エンティティに登録（enroll）および利用登録（register）するプロセスの一例を示すフロー図である。 図３１は、グラフィカルユーザインターフェースの一例を示す図である。 図３２Ａは、１つ以上の開示された実施形態が実装され得る、マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）またはモノのウェブ（Web Of Things：ＷｏＴ）通信システムの一例のシステム図である。 図３２Ｂは、図３２Ａで示されるＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム中で使用され得るアーキテクチャの一例のシステム図である。 図３２Ｃは、図３２Ａおよび図３２Ｂに示される通信システム中で使用され得る通信ネットワーク装置、例えば、Ｍ２Ｍ／ＩｏＴ／ＷｏＴデバイス、ゲートウェイまたはサーバの一例のシステム図である。 図３２Ｄは、図３２Ａおよび３２Ｂの通信システムのノードまたは装置が具現化され得る計算システムの一例のブロック図である。

ＩｏＴサービス登録によって、ＩｏＴサービスプロバイダのプラットフォームに、図１に示されるサービス登録者およびそのＩｏＴデバイス、アプリケーション、データおよび認証ユーザの間に存在する関係を知らせることが可能になる。ＩｏＴサービス登録者は、ＩｏＴサービス登録者に関連付けられた複数の認証ユーザを含んでいてもよい。これらのユーザは、Ｉｏｔデバイスにアクセスすることが認証されてもよい。これらのデバイスは、ＩｏＴアプリケーションをホストしてもよい。ＩｏＴアプリケーションは、データを作成し、データを消費してもよい。それぞれの登録者は、それぞれの登録者に関連付けられた１以上のＩｏＴデバイス、アプリケーション、ユーザおよび／またはデータセットを有していてもよい。

ＩｏＴアプリケーションは、ＩｏＴ使用事例に関するアプリケーション特有の機能（例えば、検知、駆動）を実行するソフトウェアエンティティであってもよい。

ＩｏＴサービスは、ＩｏＴアプリケーションおよびデバイスに能力（例えば、データ管理、セキュリティ、デバイス管理など）を提供するソフトウェアエンティティであってもよい。

ＩｏＴデバイスは、１つ以上のＩｏＴアプリケーションをホストし得るエンティティであってもよい。

ＩｏＴエンティティは、ＩｏＴアプリケーション、ＩｏＴサービスまたはＩｏＴデバイスであってもよい。

ＩｏＴサービスプラットフォームは、サービスプロバイダに代わり、ＩｏＴサービスの登録者およびそのＩｏＴデバイス、アプリケーション、データおよびユーザにＩｏＴサービスを提供するシステムであってもよい。

ＩｏＴサービスプロバイダは、ＩｏＴサービスプラットフォームの配置および管理を担うステークホルダー（例えば、企業）であってもよい。

ＩｏＴサービス登録者は、ＩｏＴサービスプロバイダのプラットフォームのサービスにアクセスし、使用するために、ＩｏＴサービスプロバイダのプラットフォームにサービス登録を確立するステークホルダー（例えば、人間）であってもよい。

被仮想化ＩｏＴサービス登録者は、ＩｏＴサービス登録者およびそのＩｏＴデバイス、アプリケーション、データおよびユーザを表すソフトウェアプロファイルであってもよい。

ＩｏＴサービス登録は、プロバイダのＩｏＴプラットフォームによって提供されるサービスにアクセスするために、ＩｏＴデバイス、アプリケーション、データおよび認証ユーザをＩｏＴサービスプロバイダに利用登録するＩｏＴサービス登録者の作業であってもよい。

ＩｏＴユーザは、ＩｏＴサービス登録者に関連付けられた認証ユーザであってもよい。ＩｏＴサービス登録者は、特定のユーザに、ＩｏＴサービスプロバイダのプラットフォームを介して特定のＩｏＴデバイス、アプリケーション、データおよびサービスにアクセスするための特定の権限を付与してもよい。

Ｍ２Ｍ／ＩｏＴサービス層（Service Layer：ＳＬ）は、具体的にはＭ２Ｍ／ＩｏＴデバイス、ＩｏＴアプリケーションおよびＩｏＴデータに付加価値サービスを提供することを目標とした技術である。近年、いくつかの業界標準化団体（例えば、ｏｎｅＭ２Ｍ、ＥＴＳＩ、ＯＣＦおよびＬＷＭ２Ｍ）は、Ｍ２Ｍ／ＩｏＴデバイス、アプリケーションおよびデータを、インターネット／ウェブ、セルラー、エンタープライズおよびホームネットワークを有する配置に統合することと関連する課題に対処するために、Ｍ２Ｍ／ＩｏＴ ＳＬを開発しつつある。

Ｍ２Ｍ／ＩｏＴ ＳＬにより、アプリケーションおよびデバイスは、一群のＭ２Ｍ／ＩｏＴ指向型の能力にアクセスできる。能力の例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性管理が挙げられ得る。かかる能力は、Ｍ２Ｍ／ＩｏＴ ＳＬによってサポートされるメッセージフォーマット、リソース構造およびリソース表現を活用するＡＰＩを介し、アプリケーションが利用可能となり得る。

プロトコルスタックの観点から、典型的には、複数のＳＬがアプリケーションプロトコル層の上に位置していてもよく、ＳＬがサポートするアプリケーションに付加価値サービスを提供してもよい。したがって、ＳＬは、しばしば「ミドルウェア」サービスに分類される。図２は、アプリケーションプロトコルとアプリケーションとの間の例示的なサービス層を示す。

配置の観点から、Ｍ２Ｍ／ＩｏＴ ＳＬは、図３に示したとおり、例えば、サーバ、ゲートウェイおよびデバイスを含む様々な種類のネットワークノードで配置されてもよい。

ｏｎｅＭ２Ｍ ＳＬのアーキテクチャは、図４に示したとおり、４個の参照点をサポートし得る共通サービスエンティティ（ＣＳＥ）を定義する。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェース接続していてもよい。Ｍｃｃ参照点は、同じサービスプロバイダドメイン中の別のＣＳＥとインターフェース接続していてもよく、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン中の別のＣＳＥとインターフェース接続していてもよい。Ｍｃｎ参照点は、基礎となるネットワークサービスエンティティ（ＮＳＥ）とインターフェース接続してもよい。ＮＳＥは、ＣＳＥに、基礎となるネットワークサービス、例えば、デバイス管理、位置サービスおよびデバイストリガを提供してもよい。ＣＳＥは、「発見」、「データ管理＆保存」などの「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含んでいてもよい。図５は、ｏｎｅＭ２ＭによってサポートされるＣＳＦを示す。

ｏｎｅＭ２Ｍアーキテクチャは、分散アーキテクチャであり、以下のノード型にわたる分散したＭ２Ｍ／ＩｏＴサービスの配置をサポートする。
・アプリケーションサービスノード（Application Service Node：ＡＳＮ）：ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含む、ノードである。一実施形態例では、ＡＳＮは、Ｍ２Ｍデバイス中に存在していてもよい。
・アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）：ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まない、ノードである。一実施形態例では、アプリケーション専用ノードは、制約されたＭ２Ｍデバイス中に存在していてもよい。
・ミドルノード（Middle Node：ＭＮ）：ＭＮは、１つのＣＳＥを含み、０個以上のＡＥを含む、ノードである。一実施形態例では、ＭＮは、Ｍ２Ｍゲートウェイ中に存在していてもよい。
・インフラストラクチャノード（Infrastructure Node：ＩＮ）：ＩＮは、１つのＣＳＥを含み、０個以上のＡＥを含む、ノードである。ＩＮ中のＣＳＥは、他のノード型に適用可能ではないＣＳＥ機能を含んでいてもよい。一実施形態例では、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ中に存在していてもよい。
・非ｏｎｅＭ２Ｍノード（Non-oneM2M Node：ＮｏＤＮ）：非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを含まない（ＡＥもＣＳＥも含まない）ノードである。かかるノードは、管理を含め、インターワーキング目的のためにｏｎｅＭ２Ｍシステムに接続するデバイスを表す。

ｏｎｅＭ２Ｍシステム中でサポートされる種々のエンティティを相互接続する可能な構成は、図６に示される。

既存のｏｎｅＭ２Ｍアーキテクチャは、Ｍ２Ｍ登録機能（M2M Enrollment Function：ＭＥＦ）を定義する。この機能は、識別子およびクレデンシャルを個々のｏｎｅＭ２Ｍデバイス（すなわち、ノード）およびアプリケーション（すなわち、ＡＥ）に提供することをサポートする。次いで、登録されると、アプリケーション（すなわち、ＡＥ）は、安全かつ個々にサービス層エンティティ（例えば、ＣＳＥ）に利用登録されてもよい。ｏｎｅＭ２Ｍアーキテクチャは、Ｍ２Ｍサービス加入（M2M Service Subscription）も定義する。Ｍ２Ｍサービス加入は、どのアプリケーションおよびデバイスが、ＣＳＥに利用登録可能かを定義する。しかし、ｏｎｅＭ２Ｍは、Ｍ２Ｍサービス加入がどのように確立されるかについてのプロセスを定義しない。このプロセスは、アウトオブバンドで行われることが想定される。

ｏｎｅＭ２Ｍエコシステムの一例では、種々の企業によって製造されるＩｏＴデバイスは、開放された柔軟性のあるエコシステムで利用可能となっている。このエコシステムでは、消費者は、種々の製造者製のデバイスを得て、これらのデバイスを（例えば、自身のホームネットワークへと）インストールし、これらのデバイスを共存させ、適切に機能させてもよい。このエコシステムでは、ＩｏＴサービスプロバイダは、消費者のＩｏＴデバイスの多様なセットを管理し、これらのセットとインタラクトするのに役立つように消費者にサービスを提供するという役割を果たしてもよい。例えば、サービスは、消費者が、消費者のデバイス上で実行されるソフトウェアのバージョンをアップデートしてソフトウェアを最新かつ現在のものに保ち、脅威を検出および／または攻撃を阻止するための是正措置をとることによって、消費者のデバイスのセキュリティが損なわれていないことを監視しおよび確保し、消費者のＩｏＴデバイスによって作成および収集されたデータを管理し、このデータを管理および調整して消費者にさらなる情報を与えるのに役立つよう提供されてもよい。

既存のＩｏＴエコシステムは、主に、本質的に拡張可能性も柔軟性もないＩｏＴデバイスおよびサービスの配置を含む。例えば、住宅所有者が、サービスプロバイダからホームオートメーションパッケージを購入した場合、住宅所有者は、そのサービスプロバイダによって提供されるＩｏＴデバイスおよびサービスのみを使用しなければならない（すなわち、このシステムは、閉じられたシステムである）。住宅所有者は、自身の選択した他のＩｏＴベンダーからさらなるデバイスを購入し、これを追加する柔軟性を有しておらず、住宅所有者の既存のプロバイダによって提供されるサービスを補う他のサービスプロバイダによって提供されるさらなるサービスを追加する選択肢を有していない。

消費者が、異なるＩｏＴデバイスの組み合わせを配置して異なるサービスを使用する自由がある、さらに拡張可能で動的なＩｏＴエコシステムを可能にするための技術的な障害の１つは、多くのＩｏＴサービスプロバイダおよびそのＩｏＴサービスプラットフォームによって使用される、標準化されておらず、手動であり、拡張可能ではない登録プロセスである。

典型的には、サービスプロバイダのプラットフォームおよびそのＩｏＴサービスにアクセス可能になる前に、登録者は、まず、手動の登録プロセスを正常に完了させなければならない。かかるプロセスは、典型的には、サービス登録者自身と、そのＩｏＴデバイス、アプリケーション、データおよび認証ユーザをＩｏＴサービスプロバイダに登録するサービス登録者が関わっていてもよい。この登録プロセスの複雑さおよび負荷は、登録者（すなわち、顧客）自身の肩に直接かかってくる。従来、このプロセスは、このプロセスを完了するためにプロバイダとの接触（直接会って、電話で、ウェブを介してなど）を開始する登録者が関わる、手動かつアウトオブバンドのプロセスを用いて行われてきた。典型的には、かかるプロセスは、登録者が、自身のデバイス、アプリケーション、データおよび／または認証ユーザについての多くの詳細を最初に知ることが必要な場合がある。例えば、かかる詳細は、製造者、型式番号、シリアル番号、ソフトウェアのバージョン、ネットワークまたは物理的な位置、セキュリティクレデンシャルまたはパスワード、機能設定などを含んでいてもよい。登録者は、この情報を全て集めた後、次いで、この情報を手動で（手書きで、または電子的に）フォームに入力するか、またはこの情報を顧客サービス担当者に送らなければならない。多くの場合、登録者（または登録者のデバイス、アプリケーションまたはサービスのうち１つ以上）はまた、サービスプロバイダのプラットフォームが、自身のデバイス、アプリケーション、データセットおよび特定のユーザのそれぞれについての認証権などのさらなる情報で構成されるように、手動でプログラミングしなければならない。これらの全ての工程は、登録者にとって登録プロセスを複雑で困難なものにしてしまう場合がある。

さらに、最近のＩｏＴネットワーク配置のサイズおよび複雑さの増加に伴い、登録／再登録／登録解除の負荷は、登録者にとって、さらに厄介なことになりつつある。ますます多くのＩｏＴネットワークにおいて、多数のＩｏＴデバイスが配置されている。多くのデバイスは、デバイスと人間との相互作用がほとんどないか、または全くない状態で、遠隔および／または到達不可能な場所で配置される。これらのネットワークは、追加されることが必要な新しいデバイス、デバイスにアクセスすることが許可されることが必要な新しいユーザ、デバイスの所有権の変化などの動的な変化も発生する。これら全ての因子は、サービス登録者およびそのＩｏＴデバイス、アプリケーション、データおよびユーザをサービスプロバイダのＩｏＴプラットフォームに登録する、さらに複雑なタスクの一因となる。

ＩｏＴサービス登録者のためにサービス登録プロセスを自動化し、単純化するのに役立ち得るＩｏＴサービス能力を可能にするシステムおよび方法が本明細書で記載される。これらの能力によって、サービス登録者は、サービス登録者自身およびそのＩｏＴデバイス、アプリケーション、データおよびユーザを、サービス登録者を表すソフトウェアプロファイル中で仮想化することができる。仮想化されると、次いで、サービス加入者は、自身に代わって、サービス登録の複雑さおよび負荷を、自動ＩｏＴサービス登録ソフトウェア機能に委ねてもよい。同様に、これらのＩｏＴサービス能力は、ＩｏＴサービスプロバイダのためのサービス登録プロセスを自動化するのにも役立つ場合がある。これらの能力によって、サービスプロバイダは、自身およびその登録プロセスを、自動ソフトウェア対応プロセス中で仮想化することができる。

本明細書に記載されるのは、ＩｏＴサービスプロバイダに対するＩｏＴサービス登録者の登録を自動化するための少なくとも以下のＩｏＴサービス能力のセットを可能にする、ＩｏＴシステムのアーキテクチャである。

ＩｏＴサービス能力および方法は、潜在的なサービス登録者を、潜在的なサービス登録者自身およびそのＩｏＴデバイス、アプリケーション、データおよびユーザを後でＩｏＴサービスプロバイダのプラットフォームに登録し得るソフトウェアエンティティ中で仮想化することが可能なように導入される。

ＩｏＴサービス能力および方法は、ＩｏＴサービスプロバイダが、その分散されたＩｏＴサービスプラットフォームを介し、発見可能なＩｏＴサービス登録情報を公開することが可能なように導入される。この能力は、潜在的なサービス登録者が、サービスプロバイダによって、そのＩｏＴサービスプラットフォームを介して公開される利用可能なサービス登録オプションを照会し、発見することも可能にする場合がある。

ＩｏＴサービス能力および方法は、サービス登録者が、サービスプロバイダのプラットフォームとの安全な関連付け（セキュアアソシエーション）を確立し、この安全な関連付けを介し、サービスプロバイダに安全に登録／再登録／登録解除することが可能なように導入される。

ＩｏＴサービス能力および方法は、仮想化されたＩｏＴサービス登録者が、仮想化されたＩｏＴサービス登録者自身、そのＩｏＴデバイス、アプリケーション、データおよび認証ユーザをＩｏＴサービスプロバイダのプラットフォームに安全かつ動的に登録することが可能なように導入される。かかる方法によって、ＩｏＴサービスプラットフォームが、登録者に、例えば、登録者のための認証ポリシーの自動作成、登録者のＩｏＴデバイスおよびアプリケーションの自動利用登録、および登録者データの自動インポートなどの自動登録サービスのセットを提供することを可能にし得る。

上述のＩｏＴサービス登録能力は、ＩｏＴサービス登録機能の進化した特徴として実施されてもよい。かかる機能およびその能力は、ＩｏＴサービスプロバイダのＩｏＴプラットフォームのサポートされている特徴であってもよく、サービス登録者が、サービス登録者自身、そのデバイス、そのデータおよびその認証ユーザをプラットフォームに登録するプロセスを自動化するために使用してもよい。

また、本明細書に記載されるのは、かかる進化したＩｏＴサービス登録能力が、どのように既存のｏｎｅＭ２Ｍアーキテクチャに組み込まれ、ＡＥ、ＣＳＥ、ＭＥＦおよびＭＡＦなどのｏｎｅＭ２Ｍエンティティによって使用され得るのかを記載するｏｎｅＭ２Ｍの一実施形態である。

ｏｎｅＭ２Ｍは、どのようにＭ２Ｍサービス加入が確立されるかについてのプロセスを定義しないため、ｏｎｅＭ２Ｍアーキテクチャは、１つ以上のＩｏＴデバイス、アプリケーション、データセットおよび／または認証ユーザに対する所有権または管理者権限を有し、自身およびこれらのエンティティをサービスプロバイダに登録するサービス加入者の概念をサポートしない。

これに加え、サービスプロバイダが消費者およびそのＩｏＴデバイスに対するサービスの提供をオープンにし得るエコシステムのため、両立できるサービスを提供するサービスプロバイダを発見するさらに自動化された方法が必要である。また、消費者およびそのＩｏＴデバイスをこれらのサービスプロバイダに登録するための自動化された動的な方法がさらに必要とされる。これらのさらなる自動化された方法を提供することによって、消費者は、自身の機能要求に応じたＩｏＴデバイスを自由に購入することができ、次いで、これらのデバイスに適合するサービスを提供するサービスプロバイダを見つけて登録できる。

本明細書に記載の能力および実施形態例は、特に、上述の問題に対する解決策を提供し得る。具体的には、ＩｏＴサービス登録者およびサービスプロバイダがこれらの能力の使用することによって、ＩｏＴエコシステムがさらに拡張し得る。このエコシステムの中で、消費者は、自身の選択した種々のデバイス型を購入して自身のネットワークに追加する自由と、種々のサービスプロバイダから提供されるサービスを発見して使用する柔軟性を有することができる。

自動サービス登録（Automated Service Enrollment：ＡＳＥ）能力は、２つの論理機能として実施されてもよい。第１機能は、自動サービス登録クライアント（Automated Service Enrollment Client：ＡＳＥ－Ｃ）機能であってもよい。第２機能は、自動サービス登録サーバ（Automated Service Enrollment Server：ＡＳＥ－Ｓ）機能であってもよい。

ＡＳＥ－ＣおよびＡＳＥ－Ｓには複数の配置オプションが存在する。例えば、図８に示したとおり、ＡＳＥ－Ｃは、仮想化されたＩｏＴサービス登録者に機能として統合されてもよく、ＡＳＥ－Ｓは、ＩｏＴサービスプラットフォームに機能として統合されてもよい。これに代えて、図９に示したとおり、ＡＳＥ－Ｓは、自身のスタンドアロンサービスとして配置されてもよい。かかる場合には、ＡＳＥ－Ｃも、ＩｏＴサービスプラットフォームに組み込まれていてもよい。仮想化されたＩｏＴサービス登録者およびＩｏＴサービスプラットフォームにおけるＡＳＥ－Ｃを使用し、スタンドアロンＡＳＥ－Ｓに通信してもよい。

ＡＳＥの機能をクライアント（ＡＳＥ－Ｃ）およびサーバ（ＡＳＥ－Ｓ）に分割することは、ＡＳＥのロジックを構成要素にどのように分割するかを記載する、単なる一実施形態例であり、他の構成も可能である。

図１０は、本明細書に記載する自動サービス登録クライアント（ＡＳＥ－Ｃ）機能の一実施形態例を示す。かかる機能は、サービス登録者の仮想化を補助するために、新しく導入された能力のセットをサポートしてもよい。かかる能力は、以下のものを含んでいてもよい：サービス登録者仮想化能力、サービス登録照会及び発見クライアント能力、サービス登録セキュリティアソシエーションクライアント能力、およびサービス登録クライアント能力。

サービス登録者が仮想化された後、ＡＳＥ－Ｃ機能は、サービスプロバイダの発見を自動化し、サービスプロバイダとの安全な関連付け（セキュアアソシエーション）およびＩｏＴサービスプロバイダによって運営されるＩｏＴサービスプラットフォームへの仮想化されたＩｏＴサービス登録者の安全な登録を確立するような能力をサポートしていてもよい。

図１１は、本明細書に記載する自動サービス登録サーバ（ＡＳＥ－Ｓ）機能の一実施形態例を示す。かかる機能は、サービスの種類、データ保存の最大量、サポートされるデータの種類、デバイスの最大数、サポートされるデバイスの種類、アプリケーションの最大数、アプリケーションの種類、認証ユーザの最大数および所与の期間に許可される通知の最大数などのサポートされるサービスプロバイダ登録オプションの公開を自動化するために新しく導入された能力のセットをサポートしてもよい。ＡＳＥ－Ｓは、サービス登録者からのサービスプロバイダ発見リクエストに応じること、ならびに、サービス登録者との安全な関連付け（セキュアアソシエーション）、およびＩｏＴサービスプロバイダによって運営されるＩｏＴサービスプラットフォームに対するＩｏＴサービス登録者の登録を確立することもサポートしてもよい。かかる能力は、以下のものを含んでいてもよい：サービス登録公開能力、サービス登録照会及び発見サーバ能力、サービス登録セキュリティアソシエーションサーバ能力、およびサービス登録サーバ能力。ＡＳＥ－ＳとＡＳＥ－Ｃとはともに、ＩｏＴサービス登録者がＩｏＴサービスプロバイダプラットフォームに登録するための自動化された安全な方法を提供してもよい。

ＩｏＴサービスプロバイダのプラットフォームへのＩｏＴサービス登録者およびそのＩｏＴデバイス、アプリケーション、データおよび認証ユーザの登録を自動化するための方法が導入される。図７は、新規サービス登録能力のセットによって実行可能なプロセスを示すフロー図である。

工程１で、ＡＳＥ－Ｓの新規サービス登録公開能力を用い、ＩｏＴサービスプロバイダのプラットフォームは、プロバイダのサポートされるサービス登録オプションのリスト、例えば、サービスの種類、データ保存の最大量、サポートされるデータの種類、デバイスの最大数、サポートされるデバイスの種類、アプリケーションの最大数、アプリケーションの種類、認証ユーザの最大数および所与の期間に許可される通知の最大数を公開してもよい。

工程２で、ＡＳＥ－Ｃの新規サービス登録者仮想化能力を用い、人間であるＩｏＴサービス登録者自身がソフトウェア表現中で仮想化されてもよく、同様に、そのＩｏＴデバイス、アプリケーション、データセットおよび認証ユーザも、これらのソフトウェア表現中で仮想化されてもよい。この仮想化に関するさらなる詳細は、以下に記載される。

工程３で、ＡＳＥ－Ｃの新規サービス登録照会及び発見能力を用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、その要求を満たすサービス登録オプションを提供する利用可能なＩｏＴサービスプロバイダを発見するように照会を行ってもよい。かかる照会は、ＡＳＥ－Ｓに対して行われてもよい。ＡＳＥ－Ｓは、ＩｏＴサービスプロバイダによって、そのプラットフォーム中の機能として、またはＩｏＴデバイス製造者のウェブサイトなどの他のエンティティによって配置されてもよい。発見結果は、提案されるＩｏＴサービスプロバイダ、サービス登録オプション、サービスプロバイダセキュリティアソシエーション能力およびブートストラップするサーバアドレスまたはアイデンティティのリストを含んでいてもよい。発見結果に基づき、次いで、仮想化されたサービス登録者は、その要求を満たすサービスプロバイダを選択してもよい。

工程４で、ＡＳＥ－ＣおよびＡＳＥ－Ｓの新規サービスプロバイダセキュリティアソシエーション能力を用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、ＩｏＴサービスプロバイダに対してブートストラップ操作を行ってもよい。ブートストラップによって、仮想化されたサービス登録者および選択したサービスプロバイダのプラットフォームにサービス登録クレデンシャルおよび識別子が提供され得る。

工程５で、工程４で得られたクレデンシャルを用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、ＩｏＴサービスプロバイダのＡＳＥ－Ｓの認証を行い、また逆にＩｏＴサービスプロバイダのＡＳＥ－Ｓが仮想化されたＩｏＴサービス登録者の認証を行い、これらの間のセキュリティアソシエーションを確立してもよい。

工程６で、工程５で確立された安全な関連付け（セキュアアソシエーション）を用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、自身を１つ以上のＩｏＴサービスプロバイダのＡＳＥ－Ｓに登録してもよい。

工程７で、新規サービス登録者登録能力を用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、（必要な場合および必要な時に）自身を１以上のＩｏＴサービスプロバイダに再登録してもよい。例えば、かかるプロセスは、修正が必要なときに行われてもよい（例えば、新規ＩｏＴデバイス、アプリケーション、データセットまたはユーザを追加する）。同様に、ＩｏＴサービスプロバイダは、（必要な場合および必要な時に）再登録を開始してもよい。例えば、再登録は、登録者のデバイス、アプリケーション、データセットまたは認証ユーザのうち１つ以上が、サービスプロバイダによって定義されるポリシーおよび規則を遵守していない場合に必要となることがある。

工程８で、新規サービス登録能力を用い、仮想化されたＩｏＴサービス登録者（すなわち、サービス登録者の代わりに作業するＡＳＥ－Ｃ）は、（必要な場合および必要な時に）１つ以上のＩｏＴサービスプロバイダから自身を登録解除してもよい。例えば、かかるプロセスは、サービス登録者がＩｏＴサービスプロバイダとの関係を停止することを決定した場合に行われてもよい（例えば、プロバイダを変える場合）。同様に、ＩｏＴサービスプロバイダは、（必要な場合および必要な時に）登録解除を開始してもよい。例えば、かかるプロセスは、登録者（すなわち、デバイス所有者）が、サービスプロバイダの規則またはポリシーを遵守していない場合に必要となることがある。

本明細書に記載するのは、ＩｏＴサービス登録者を、登録者および登録者自身のＩｏＴデバイス、アプリケーション、データセットおよび認証ユーザを表すソフトウェアプロファイル中で仮想化する能力である。かかるソフトウェアプロファイルは、登録者のサービス登録情報および嗜好、ならびに、登録者自身のＩｏＴデバイス、アプリケーション、データセットおよび認証ユーザに関する情報、およびこれらの間に存在する関係を効果的に捕捉してもよい（すなわち、図１で捕捉されるように）。ＩｏＴサービス登録者を仮想化する能力により、ＩｏＴサービスプロバイダのＩｏＴプラットフォームに対するサービス登録者の自動登録が容易になり得る。サービス登録者をサービス登録者のソフトウェアプロファイル中で仮想化することによって、サービス登録者とサービスプロバイダとの間で通常行われる手動かつ人が介入する作業は、自動化され、サービス登録者およびプロバイダの代わりに、ソフトウェアで行われてもよい。

サービス登録者の仮想化を可能にするために、本明細書に記載されるのは、サービス登録者およびサービス登録者自身の関連付けられたＩｏＴデバイス、アプリケーション、データおよびユーザの仮想化プロセスの自動化を可能にする新規能力である。かかる能力は、本質的に分散されていてもよく、新規ＡＳＥ－Ｃ機能によってホストされる構成要素と、新規ＡＳＥ－Ｓサーバ機能によってホストされる構成要素とを含んでいてもよい。かかる能力は、サービス登録者がより容易に自身およびそのＩｏＴデバイス、アプリケーション、データおよびユーザを仮想化することを可能にするユーザインターフェースをサポートしてもよい。このユーザインターフェース自体は、サービス登録者の仮想化プロセスを自動化するのに役立つような特徴をサポートしてもよい。このインターフェースの特徴は、ＩｏＴサービス登録者仮想化の自動化のための写真の使用であってもよい。一実施形態例では、サービス登録者の写真、および免許証、クレジットカードまたは公共料金請求書などのサービス登録者の識別情報の写真を使用し、登録者についてのサービス登録情報を集めてもよい。別の実施形態例では、サービス登録者の家族の一員および／または友人の写真またはその識別情報の写真も使用し、認証ユーザのサービス登録者のリストに関する登録情報を集めてもよい。さらに別の実施形態例では、サービス登録者のＩｏＴデバイスの写真を使用し、そのＩｏＴデバイス、これらのデバイスでホストされるアプリケーションの種類、またはこれらのデバイスによって作成または消費されるデータに関する登録情報を集めてもよい。例えば、ＩｏＴデバイス上のステッカーまたはラベルの写真を使用し、シリアル番号、ＩＭＥＩ、ＩＭＳＩ、ＭＡＣ ＩＤ、ＱＲコード（登録商標）、ＵＲＬ、バーコードなどのデバイスについての識別情報を捕捉してもよい。これに加え、他の識別情報は、デバイス上で見ることが可能であってもよく、デバイス筐体の内部のみで見ることが可能であってもよく、またはデバイスメモリ内に提供され、購入時に顧客に与えられてもよい。

かかるユーザインターフェースは、サービス登録者が写真を撮影および／またはアップロードすることを可能にする機構をサポートしていてもよい。かかる機構は、この能力をカメラと共同ホスト（co-host）することによって可能となり得る（例えば、カメラも内蔵するスマートフォン上のアプリケーションとして）。ＩｏＴデバイスの写真が撮影またはアップロードされた後、この能力により、写真からＩｏＴサービス登録に関する情報が抽出され得る。

一実施形態例では、デバイスの構成、型式およびシリアル番号などの情報が、写真から抽出されてもよい。別の実施形態例では、これらのデバイス上でホストされるか、もしくは、これらのデバイスによって作成または消費されるアプリケーションおよびデータの種類などの情報は、デバイスの構成および型式がわかれば推測されるものであってもよい。サービスの種類、またはさらに、適合するサービスベンダーなどのさらなる情報も決定されてもよい。かかる情報は、ＩｏＴデバイスのパッケージ上に印刷された情報から抽出されてもよい（例えば、バーコード、ＱＲコード、ＵＲＬ、製造者番号およびシリアル番号など）。これに代えて、この能力は、ローカルデータベース、または一般的なＩｏＴデバイス画像の遠隔でホストされたデータベースとの通信のいずれかをサポートしてもよい（例えば、ＩｏＴレジストリまたは種々の製造者がホストするデータベースを照会する）。この能力は、写真中のＩｏＴデバイスの画像とその写真から抽出され得る追加情報を、これらのデータベース中に格納された一般的なＩｏＴデバイスの画像および情報と比較することによって、一致するものを検索して見つけることをサポートしてもよい。一致が見つかったら、ＩｏＴデバイスの構成および型式、デバイスによってホストされるソフトウェアの種類、および、デバイスによって作成または消費されるデータの種類などの情報が決定されてもよい。この機能は、複数のサブコンポーネントレベルのＩｏＴデバイス（例えば、複数のセンサまたはアクチュエータ）をホストするより複雑なデバイスを検出及び登録する能力もサポートするようにさらに拡張されてもよい。例えば、複雑な工場機械の一部が、それぞれが異なる機能を有し、異なる製造者によって製造されたか、または異なる型式またはバージョンを有するいくつかのＩｏＴセンサおよびアクチュエータをホストしてもよい。かかる能力は、一致を見つけようと試みるために、一般的なＩｏＴデバイスの写真および情報を含むデータベースをスキャンすることによって、複雑なデバイスの識別をサポートしてもよい。一致が見つかった場合、このより複雑なデバイスにホストされるサポートされるコンポーネントレベルのＩｏＴデバイスのセットに関する情報は、自動で見つけられてもよい。サービスプロバイダのプラットフォームに登録する際に、この複雑なデバイスに関する情報が提供されてもよく、そのサブコンポーネントレベルのＩｏＴデバイスそれぞれに関する情報も提供されてもよい。

別の実施形態例では、デバイスの配置周囲環境などのさらなるコンテキスト情報も、この能力によって抽出されてもよい。例えば、ＩｏＴデバイス自体の写真に加え、ＩｏＴサービス登録を自動化するのに役立つように、その配置周囲環境の写真も撮影し、使用してもよい。一実施形態では、ＩｏＴデバイスの物理的な周囲環境の写真がこの能力によって使用され、デバイスが配置される位置（例えば、台所または浴室に配置される）、ＩｏＴデバイスが集めることが可能な情報の種類（例えば、家の上階または下階の温度）およびデバイスが実行し得る作業の種類（例えば、スイッチによって、電灯をオン／オフにする、またはガレージのドアを開ける／閉じる）などのさらなるコンテキストを集めてもよい。この抽出された情報を活用することにより、この能力は、ＩｏＴデバイスの周囲環境を処理し、その位置またはその機能について推測を行ってもよい。例えば、この能力は、電灯スイッチがコンロ付近にある写真から抽出する場合、ＩｏＴデバイスが台所の電灯スイッチであると推測してもよく、これに対し、電灯スイッチがトイレ付近にあると検出する場合、ＩｏＴデバイスが浴室の電灯スイッチであると推測してもよい。かかる抽出された情報を使用し、そのデバイスの名称または識別子を作成してもよい。例えば、抽出された情報を使用し、デバイスを「台所出口」または「玄関ドアのロック」と名前を付けてもよい。グラフィカルユーザインターフェース（Graphical User Interface：ＧＵＩ）は、登録前（または後）に、登録者に、提案される名称、場所または機能を変更するオプションを与えてもよい。したがって、この情報は、登録者に確認を求める自動化された提案として機能してもよい。

サービス登録者仮想化能力は、写真間のコンテキスト情報中の一致（例えば、壁面のポートレートまたはテーブル上のランプの一致）を検出するために、ＩｏＴデバイスの写真と、さらなるサービス登録者の写真とを比較する能力をサポートしてもよい。その際、この能力は、複数の写真から集められた情報を使用してもよい。複数の写真は、その周囲環境および配置位置におけるＩｏＴデバイスの種類および機能を推測するために、その全てがＩｏＴデバイス自体を含んでいなくてもよく、または同時に撮影されていなくてもよい。これにより、より豊富でより拡張されたコンテキスト情報の集合が可能になり、次いで、この能力は、そこからＩｏＴサービス登録情報を抽出できる。一実施形態例では、かかる能力は、ローカルデータベース（例えば、スマートフォンに共同ホストされている）中のサービス登録者の写真をスキャンすることをサポートしてもよい。別の実施形態例では、この能力は、サービス登録者のクラウドアカウントでホストされている写真をスキャンしてもよい。さらに別の実施形態例では、この能力は、サービス登録者のソーシャルメディアアカウント、もしくは、家族の一員や友人または近隣に居合わせ、この能力を自由に利用できる有効なソーシャルメディアアカウントを有するその他のサービス登録者のアカウントのうち１つ以上から写真をスキャンしてもよい。

サービス登録者仮想化能力は、サービス登録を自動化するのに役立つように、写真から抽出された情報を追加のサービス登録者に関連するメタデータで補ってもよい。一実施形態例では、サービス登録者のＩｏＴデバイスの位置情報が補われてもよい。例えば、位置情報は、サービス登録者仮想化能力と共にホストされているＧＰＳ能力、およびサービス登録者のＩｏＴデバイスの近くで写真を撮影するために使用されるカメラから得られてもよい。別の実施形態例では、サービス登録者仮想化能力によって、サービス登録者が、デバイスの相対位置を定義することが可能になり得る。これは、「玄関ドアのロック」または「裏口のロック」などの説明文を入力するか、またはサムネイルなどの写真を添付することによって行われてもよく、これを使用してＩｏＴデバイスを説明してもよい。

本明細書に記載する別の方法は、登録者がそのＩｏＴネットワーク図を作成することを可能にし得るＧＵＩをサポートするために、登録者、そのＩｏＴデバイス、アプリケーション、データおよびユーザの仮想化を自動化するための方法である。かかる図面は、登録者の家の部屋のレイアウト、これらの部屋の中のデバイスの位置、デバイス情報、アプリケーション情報、データ情報およびユーザ情報などの詳細を含んでいてもよい。ＧＵＩは、描画ツール、ウィジェット、アイコンおよびメニューを提供することによって登録者を補助し、描画プロセスを自動化することをサポートしてもよい。ＧＵＩは、外部で（例えば、他の描画ツールによって）作成された図面のアップロードもサポートしてもよい。

別の実施形態例では、ＩｏＴサービス登録者およびそのデバイスを仮想化するために用いられるカメラおよび写真ではなく、ＮＦＣ技術が使用されてもよい。かかる方法は、ＮＦＣ対応ユーザデバイスと共にＮＦＣ能力を共同ホストすることによって実行可能であってもよい（例えば、ＮＦＣ機能もサポートするスマートフォン上のＡＳＥ－Ｃとして）。登録者は、ＩｏＴデバイス付近のＮＦＣ対応ユーザデバイスをスワイプしてもよく、関連情報が、ＡＳＥ－Ｃに移されてもよい（例えば、構成、型式など）。これに加えて、またはこれに代えて、ＮＦＣ情報は、ＩｏＴデバイス情報をどこで見つけるかを登録ツールに伝えてもよい（例えば、製造者のウェブサイトまたはデータベース）。登録者情報について、ＡＳＥ－Ｃは、セルラーネットワークを照会し、登録者情報と、登録者の現在位置などの他のコンテキストを得てもよい。

この新規能力を介し、サービス登録者のサービス登録に関連する情報を集めることによってサービス登録者が仮想化された後、次いで、この情報は、ＡＳＥ－Ｃ機能およびＡＳＥ－Ｓ機能によってサポートされる他の新規能力へと引き継がれてもよい。その際、サービスプロバイダへのサービス登録者の登録は、自動化されてもよく、サービス登録者またはプロバイダからの手動での介入をもはや必要としなくてもよい。

かかるサービス登録者の仮想化能力を用い、サービス登録者は、サービス登録のポリシーまたは規則も作成してもよく、これを使用し、サービス登録者および／またはサービスプロバイダの代わりにサービス登録の選択を行う際に、ＡＳＥ－Ｃ機能およびＡＳＥ－Ｓ機能を導いてもよい。かかるポリシーは、仮想化プロセス中に、および／またはこの能力のユーザインターフェースを介し、サービス登録者によって構成されてもよい。インターフェースは、サービス登録ポリシーの構成特徴をサポートしてもよい。一実施形態例では、この能力は、サービス登録者が選択できるあらかじめ構成されたサービス登録ポリシーの選択肢のセット（すなわち、メニュー）をサポートしてもよい。例えば、サービス登録ポリシーの選択肢は、サービスの種類、データ保存の最大量、サポートされるデータの種類、デバイスの最大数、サポートされるデバイスの種類、アプリケーションの最大数、アプリケーションの種類、認証ユーザの最大数および所与の期間に許可される通知の最大数を含んでいてもよい。

新規サービス登録公開、照会、および発見の能力を使用し、利用可能なＩｏＴサービスプロバイダ、およびこれらのプロバイダおよびそのＩｏＴサービスプラットフォームによってサポートされるサービス登録オプションを発見してもよい。かかる能力は、本質的に分散されていてもよく、新規ＡＳＥ－Ｃ機能によってホストされる構成要素と、新規ＡＳＥ－Ｓサーバ機能によってホストされる構成要素とを含んでいてもよい。

サービス登録公開、照会、および発見の能力によって、ＩｏＴサービスプロバイダが、プロバイダが提供するサービスおよび登録者が使用可能なオプションに関する発見可能なＩｏＴサービス登録情報を公開することが可能になり得る。この能力は、サービス登録公開ＡＰＩをサポートしていてもよく、サービス登録公開ＡＰＩは、サービスプロバイダおよび第三者のアプリケーション／サービスプロバイダが、サービス登録に関連する情報をそのＩｏＴサービスプラットフォームにプログラムによって公開することを可能にし得る。プロバイダによってＩｏＴサービスプラットフォームに公開されるサービス登録情報の種類としては、限定されないが、以下のもののうち１つ以上が挙げられる：
・ＩｏＴサービスプラットフォームによってサポートされるＩｏＴサービスの種類およびアイデンティティ。
・ＩｏＴサービスプラットフォームおよびプロバイダによってサポートされる自動登録オプションおよび手順に関する情報であり、以下のものを含んでいてもよい。
－１つ以上のサービスの自動サービス登録がサポートされているか否か、
－サービスにアクセスするための登録方法についての自動登録指示。
・１つ以上のサポートされているＩｏＴサービスが利用可能でオンライン上で使用できる予定時間（例えば、一日のうちの時間帯、週または月）。
・提供されているサービスのうちどれが、一般利用のために開放されるかについての情報。
・提供されているサービスのうちどれが、アクセスにサービス登録計画を必要とするかについての情報。
・提供されているサービスのうちどれが、アクセスにサービス登録計画を必要とする前に一般利用のために開放される初期のトライアル期間を有するかについての情報。
・ベンダーおよび／または製造者がサービスプロバイダによってサポートまたは登録可能なＩｏＴデバイス、アプリケーションおよびデータの種類。
・サービス登録を必要とするサービスについて、以下を含むアクセスの状況または条件に関する情報：
－サービスにアクセスする際になんらかのスケジュール制限があるか（例えば、１時間あたり１回のアクセス、１日の特定の時間中のみのアクセスなど）、
－サービスにアクセスする際になんらかのデータ利用制限があるか（例えば、１リクエストあたり１００バイト）、
－サービスにアクセスする際になんらかの位置制限があるか（例えば、特定のネットワークドメインまたは地理的な領域内のサービスのみにアクセス）、
－サービスにアクセスする際になんらかのプロトコルまたはデータモデルの制限があるか（例えば、特定のプロトコルまたはデータモデルが使用される場合にのみアクセスが許可される）、
－サービスに関連付けられたプライバシーポリシー、
－サービスを共有することができる個人ユーザの数。

サービスプロバイダのセキュリティクレデンシャル（公開鍵証明書）は、公開され、クライアントがサービスプロバイダを（オプションとして）認証できるよう発見応答に含まれていてもよい。これに加えて、かかるクレデンシャルは、サービスプロバイダとの安全な関連付け（セキュアアソシエーション）を確立する際に、サービス登録者によって使用されてもよい。

このサービス登録公開、照会、および発見能力は、仮想化ＩｏＴサービス登録者が、利用可能なサービスプロバイダを発見するためにサービス登録クエリを発行することも可能にし得る。例えば、仮想化されたＩｏＴサービス登録者（すなわち、ＡＳＥ－Ｃ）は、ＡＳＥ－Ｓにクエリを発行してもよい。例えば、かかるＡＳＥ－Ｓは、サービスプロバイダのＩｏＴプラットフォーム中の一機能として、またはアドレスが仮想化されたＩｏＴサービス登録者に提供され得るデバイス製造者のウェブサイトまたはデータベースの一機能として配置されてもよい。このクエリは、サービスプロバイダ登録オプションと、そのサービスプロバイダ登録オプションがサービス登録者の要求を満たすか否かを発見するために使用してもよい。この能力は、サービス登録発見ＡＰＩをサポートしていてもよく、サービス登録発見ＡＰＩは、サービス登録者が、利用可能なＩｏＴサービスプラットフォームおよびそのプロバイダからサービス登録に関連する情報をプログラムによって発見することを可能にし得る。かかるリクエストは、登録者（すなわち人間）の手動介入を行わずに、ＡＳＥ－Ｃによって、自動およびプログラムでなされてもよい。この自動化された機械中心の発見機構は、多くのＩｏＴ使用事例および配置にとって重要な要求事項であってもよい。仮想化されたサービス登録者がクエリ中で特定し得るサービス登録発見基準の種類としては、限定されないが、以下のうち１つ以上が挙げられる：
・アクセスにサービス登録を必要としない、サービスプロバイダによって提供されるサービスを発見する。
・特定のベンダーまたは製造者製のＩｏＴデバイス、アプリケーションまたはデータ（すなわち、登録者が登録しようと試みるデバイス、アプリケーション、データ、ユーザの種類のリスト）によってそのサービスの利用を提供するＩｏＴサービスを発見する。
・サービス登録を必要とするが、登録者の以下のサービス登録の要求のうち１つ以上を満たす、サービスプロバイダによって提供されるサービスを発見する：
－特定の時間中にサービスへのアクセスを提供するＩｏＴサービス、
－サービスへのアクセスが開放されている試用期間を設けているＩｏＴサービス、
－特定の時間間隔中にアクセス数が最小であるＩｏＴサービス、
－登録されるＩｏＴデバイス、アプリケーション、ユーザの数が最小であるＩｏＴサービス、
－リクエストあたり、所与の時間間隔あたり、ＩｏＴデバイスあたり、ＩｏＴユーザあたり、ＩｏＴアプリケーションあたりなどのいずれかのデータ使用量が最小であるＩｏＴサービス、
－位置制限のないサービス利用、または特定のネットワーク内または地理的領域内などの特定の位置領域内での使用を提供するＩｏＴサービス、
－特定のシリアライゼーションスキーム、データモデル、スキーマまたはオントロジーをサポートするＩｏＴデバイス、アプリケーションまたはサービスによるＩｏＴサービスの利用を提供するＩｏＴサービス、
－特定の伝送プロトコルをサポートするＩｏＴデバイス、アプリケーションまたはサービスによるＩｏＴサービスの利用を提供するＩｏＴサービス、
－例えば、エンドツーエンドセキュリティ、コンテンツまたはオブジェクトに基づくセキュリティ、特定のセキュリティプロトコル、セキュリティアルゴリズムおよびセキュリティクレデンシャルブートストラップ機構など、特定のセキュリティ機構をサポートするＩｏＴデバイス、アプリケーションまたはサービスによるＩｏＴサービスの利用を提供するＩｏＴサービス、
－ＩｏＴデバイスまたはデータへの他の登録者のアクセスを許可する必要なく、ＩｏＴサービスの利用を提供するＩｏＴサービス、
－特定のプライバシーポリシーを有するＩｏＴサービス、
－特定のベンダーまたは製造者製のＩｏＴデバイス、アプリケーションまたはデータによるＩｏＴサービスの利用を提供するＩｏＴサービス。

一実施形態例では、サービス登録公開、照会、および発見能力のＡＰＩは、本質的にＲＥＳＴｆｕｌであってもよく、サービスプロバイダが発見可能なサービス登録情報によって作成（ＣＲＥＡＴＥ）し、アップデート（ＵＰＤＡＴＥ）し得る１つ以上のリソースを含んでいてもよく、次いで、サービス登録者は、サービス登録オプションおよび一致するサービス登録を検索（ＲＥＴＲＩＥＶＥ）し、発見してもよい。

新規サービス登録者とプロバイダとのセキュリティアソシエーション能力を使用し、仮想化されたＩｏＴサービス登録者とＩｏＴサービスプロバイダのプラットフォームとの間のセキュリティアソシエーションを確立してもよい。かかる能力は、仮想化されたサービス登録者がＩｏＴサービスプロバイダのプラットフォームにサービス登録するために必要なＩｏＴサービス登録クレデンシャルおよび識別子を安全にブートストラップするための機能をサポートしていてもよい。このブートストラップは、クライアント構成要素とサーバ構成要素とを含んでいてもよい。クライアント構成要素は、ＡＳＥ－Ｃによってサポートされていてもよい。サーバ構成要素は、ＡＳＥ－Ｓによってサポートされていてもよい。

ＡＳＥ－Ｓ機能を使用し、ＡＳＥ－Ｃ機能に対し、ＩｏＴサービス登録識別子およびクレデンシャルをブートストラップしてもよい。かかるブートストラップは、サービス登録の必要事項を満たし、後でＡＳＥ－Ｃが登録すると決定するＩｏＴサービスプロバイダのプラットフォームを照会および発見した後に、ＡＳＥ－Ｃ機能によって開始されてもよい。

サービス登録者とプロバイダとのセキュリティアソシエーション能力は、ＩｏＴサービスプロバイダが、利用可能なＩｏＴサービス登録識別子およびクレデンシャルの集合を構成するのを可能にし得る。この利用可能なＩｏＴサービス登録識別子およびクレデンシャルの集合は、その後、所与のＩｏＴサービスプロバイダのプラットフォームに登録したいと望むサービス登録者にブートストラップされてもよい。この能力は、サービスプロバイダが、利用可能なサービス登録クレデンシャルおよび識別子の集合をプログラムによって公開することが可能であり得るＡＰＩをサポートしてもよい。ＩｏＴサービスプロバイダが、自身のＡＳＥ－Ｓ機能をそのＩｏＴプラットフォームのサービスとしてホストしている場合、このサービス登録クレデンシャルおよび識別子のブートストラップ能力は、この機能の一部として含まれていてもよい。しかし、サービスプロバイダが、自身のＡＥＳ－Ｓ機能をホストせず、代わりに第三者の機能に依存している場合、サービスプロバイダは、まず、利用可能なＩｏＴサービス登録識別子およびクレデンシャルの集合を構成するためにこのＡＰＩを用いる前に、その第三者との安全な関連付け（セキュアアソシエーション）を確立する必要があるだろう。

このサービス登録者とプロバイダとのセキュリティアソシエーション能力により、仮想化されたＩｏＴサービス登録者は、１つ以上のＩｏＴサービスプロバイダプラットフォームによって提供されるサービスに登録するのに必要な、必須のサービス登録識別子およびクレデンシャルを用いてブートストラップ可能になり得る。かかるブートストラップは、仮想化されたサービス登録者によってトリガおよび開始されてもよい。一実施形態例では、本明細書に記載するＡＳＥ－Ｃ機能は、サービスプロバイダおよび両者の要求基準の一致の正常な発見などのトリガイベントに基づき、サービス登録者に代わり、このブートストラップを自動的に開始してもよい。ＡＳＥ－Ｓ機能は、ＡＳＥ－Ｃ機能が、１つ以上のＩｏＴサービスプロバイダのＩｏＴプラットフォームにサービス登録するのに必要な、必須のサービス登録クレデンシャルおよび識別子を用いて自身をプログラムによってブートストラップすることを可能にし得るＡＰＩをサポートしてもよい。なお、ＡＳＥ－Ｓが第三者によってホストされている場合、セキュリティアソシエーションは、代わりに、仮想化されたＩｏＴサービス登録者のＡＳＥ－Ｃと、この第三者によってホストされているＡＳＥ－Ｓとの間に確立されてもよい。次いで、ＡＳＥ－Ｓは、ＡＳＥ－Ｓ自身とサービスプロバイダプラットフォームのＡＳＥ－Ｃ機能との間の安全な関連付け（セキュアアソシエーション）を有していてもよい。ＡＳＥ－Ｓは、この安全な関連付け（セキュアアソシエーション）を使用し、登録情報を、仮想化されたＩｏＴサービス登録者のＡＳＥ－ＣとサービスプロバイダプラットフォームのＡＳＥ－Ｃとの間で送受信してもよい。

サービス登録者とプロバイダとのセキュリティアソシエーション能力は、仮想化されたＩｏＴサービス登録者とＩｏＴサービスプロバイダのプラットフォームとの間の安全な関連付け（セキュアアソシエーション）を作成してもよい。ＡＳＥ－Ｃ機能は、ＩｏＴサービス登録識別子およびクレデンシャルの正常に完了したブートストラップをトリガとして使用し、対応するＩｏＴサービスプロバイダのプラットフォームとの安全なサービス登録関連付けを自動的に確立してもよい。その際、対応するサービス登録者およびプロバイダは、ブートストラップされたサービス登録クレデンシャルおよび識別子に基づき、お互いに安全かつ信頼性のある関係を形成してもよい。

一実施形態例では、上述したセキュリティアソシエーションは、ＡＳＥ－Ｃ機能とＩｏＴサービスプロバイダのプラットフォームとの間の一方向および双方向の認証ハンドシェイクを含んでいてもよい。かかるハンドシェイクは、ブートストラップされたサービス登録クレデンシャルおよび識別子に基づくセキュリティチャレンジを含んでいてもよい。ＡＳＥ－Ｃ機能がセキュリティアソシエーションを開始する場合、ＡＳＥ－Ｃは、サービス登録識別子およびセキュリティクレデンシャルをハンドシェイクの一部として渡してもよい。このサービス登録識別子を受信した場合、ＩｏＴサービスプラットフォームは、サービス登録識別子および対応するサービス登録クレデンシャルを見つけるための検索を行ってもよい。プラットフォームが自身のＡＳＥ－Ｓ機能をサポートする場合、この検索は、ローカルリクエストであってもよい。しかし、ＩｏＴサービスプラットフォームがローカル機能をサポートしていない場合、ＩｏＴサービスプラットフォームは、遠隔のＡＳＥ－Ｓ機能に対するリクエストを開始してもよい。このリクエストは、サービス登録識別子を含んでいてもよい。このリクエストに対する応答は、ＡＳＥ－ＣがＡＳＥ－Ｓ機能によって認証されてサービス登録識別子を用いてブートストラップされたか否かの決定を含んでいてもよい。この応答は、識別子に関連する対応するサービス登録クレデンシャルおよびクライアントに関連する他のサービス登録情報も含んでいてもよい。

ＩｏＴサービスプラットフォームが、ＡＳＥ－Ｓ機能からサービス登録クレデンシャルを受信した後、ＩｏＴサービスプラットフォームは、安全な（例えば、暗号化され、整合性保護された）チャレンジリクエストを作成し、これをＡＳＥ－Ｃに返してもよい。このチャレンジを受信する際、ＡＳＥ－Ｃは、必要に応じ、このリクエストを復号し、ＩｏＴサービスプラットフォームに返す自身のチャレンジリクエストも含み得る応答によって、このチャレンジに応答してもよい。かかるチャレンジハンドシェイク終了時に、ＡＳＥ－ＣとＩｏＴサービスプラットフォームとの間のサービス登録関連付けは、正常に確立されてもよく、または、ＡＳＥ－ＣまたはＩｏＴサービスプロバイダのプラットフォームのいずれかによって拒否されてもよい。

新規サービス登録能力を使用し、仮想化されたＩｏＴサービス登録者が、ＩｏＴサービスプロバイダのプラットフォームに自動で登録できるようにしてもよい。ＡＳＥ－Ｃ機能が、ＩｏＴサービスプラットフォームとのサービス登録セキュリティアソシエーションを正常に作成した後、ＡＳＥ－Ｃは、ＡＳＥ－Ｃが代わりに作業する仮想化されたサービス登録者の登録を自動的にトリガしてもよい。かかるサービス登録能力は、ＡＳＥ－ＣおよびＡＳＥ－Ｓによってサポートされ得るサービス登録機能を含んでいてもよい。

ＡＳＥ－Ｃサービス登録機能によって、仮想化されたサービス登録者およびその仮想化されたＩｏＴデバイス、アプリケーション、データおよびユーザの自動登録が可能になり得る。ＡＳＥ－Ｃは、この登録を行うためにＡＳＥ－Ｓにリクエストを発してもよい。ＡＳＥ－Ｓは、ＡＳＥ－Ｃがサービス登録リクエストをプログラムによって発し、それを、種々の基礎となるネットワークプロトコルを用いてカプセル化し、ＡＳＥ－ＣとＡＳＥ－Ｓとの間で交換できるようにするサービス登録ネットワークＡＰＩをサポートしていてもよい。これらのリクエストの中に、ＡＳＥ－Ｃは、仮想化されたサービス登録者および仮想化されたサービス登録者自身のＩｏＴデバイス、アプリケーション、データおよびユーザについての種々のサービス登録中心の情報を含んでいてもよい。ＡＳＥ－Ｓは、このリクエスト中の登録情報を調べ、登録が許可されるか否かに関する決定を行うことによって、これらの登録リクエストを処理してもよい。許可された場合、ＡＳＥ－Ｓは、登録リクエストで提供される情報ごとに、適切な登録者に特有の設定も決定してもよい。これらの登録者に特有の設定はまた、登録者の特定の要求に基づき、登録者に提供される個々のサービスの種類それぞれの粒度でカスタマイズされてもよい。

ＡＳＥ－ＣがＡＳＥ－Ｓに対して発行した登録リクエストに含まれ得るサービス登録中心の情報の種類は、限定されないが、以下の１つ以上を含んでいてもよい：
・所与のサービス登録者およびサービス登録とリクエストとを関連付けるためのサービス登録識別子。ＡＳＥ－ＣがＡＳＥ－Ｓとブートストラップされる場合、かかる識別子は、ＡＳＥ－Ｓから得られてもよい。
・登録するようにリクエストするサービス登録者についての情報（例えば、アイデンティティの証明）。ＡＳＥ－ＣがＡＳＥ－Ｓとブートストラップされる場合、かかる情報は、ＡＳＥ－Ｓから得られてもよい。これに代えて、かかる情報は、登録者にあらかじめ提供されていてもよい。
・サービス登録者が登録するようにリクエストするそれぞれのＩｏＴデバイスに関する情報。ＩｏＴデバイスについての情報の種類は、限定されないが、以下のものを含んでいてもよい：
－デバイスでホストされるデバイス識別子、製造者、構成、型式、シリアル番号、ネットワークアドレス、ファームウェア／ＯＳバージョン、アプリケーションＳＷなど。
－誰が、いつ、どこで、どのようにデバイスにアクセスできるかを特定するデバイスについてのポリシー。
・サービス登録者が登録するようにリクエストするそれぞれのＩｏＴアプリケーションに関する情報。ＩｏＴアプリケーションについての情報の種類は、限定されないが、以下のものを含んでいてもよい：
－アプリケーションがホストされるデバイスインスタンスまたはデバイスの種類のリスト。かかるリストは、デバイス識別子、例えば、ＩＭＥＩ、ＭＡＣ ＩＤ、外部ＩＤ、ＩＰアドレスまたはＩＭＳＩを含んでいてもよい。
－このアプリケーションによってサポートされるデータモデルまたは情報モデル、セマンティックオントロジーモデル、コンテンツシリアライゼーションフォーマットまたは伝送プロトコル。
－このアプリケーションが、サービスのリクエストを作成する頻度（例えば、センサ報告頻度）およびリクエストあたりのデータサイズ／帯域幅に関する要求。
－このアプリケーションがプラットフォームからのリクエストに応じ得る最大頻度（例えば、通知頻度）。
－このアプリケーションのスリープスケジュール。
－誰が、いつ、どこで、どのようにアプリケーションにアクセスできるかを特定するアプリケーションのポリシー。
・サービス登録者がサービスプロバイダのプラットフォームへの登録をリクエストする、それぞれのＩｏＴデータセットに関する情報。ＩｏＴデータセットの情報の種類としては、限定されないが、以下のものを含んでいてもよい：
－データセットの種類（例えば、駐車場データなど）。
－データセットの情報モデル、セマンティックオントロジーモデル、コンテンツシリアライゼーションフォーマット。
－データセットのサイズ、例えば、そのセット中の個々のデータインスタンスあたりの合計サイズおよび／または平均サイズ、
－データセットにアクセスすることが許可されている人物およびそのデータセットで実行することが許可されている操作、そのデータへのアクセスをいつ、どの位置から、どの時間に、どのくらい長く、またはどのデバイスまたはデバイスの種類を用いて行うことが許可されるかを特定するポリシー、
－データセットが現時点でホストされているネットワークアドレス、
－登録者がサービスプラットフォームにデータセットをインポートすることを望んでいるか、あるいは、別の場所でホストされているデータセットにリンクさせることを望んでいるか否かについての表示。この表示には、どのようにデータがインポートされるべきかについての指示が含まれ得る。これは、データがインポートされるべきリソースの種類、リソースの階層またはそれぞれのリソースのスキーマ定義を含んでいてもよい。
－データセットに関連付けられたプライバシーポリシー（すなわち、データを第三者に公開するか否か）。
・選択されたサービス登録選択項目およびその所望な設定のリスト、例えば、所望のデータ保存容量、所望の１ヶ月あたりの通知数など。
・サービス登録に適合し得る、ＩｏＴサービスプラットフォームが提供するサービスへのアクセスの承認および同意。
・提案されたサービス登録の有効期間。
・サービス登録者のＩｏＴデバイス、アプリケーションおよび／またはデータセットにアクセスが許可され得る特定の認証ユーザおよびそのそれぞれの権限のリスト。
－ユーザのリストは、ＩｏＴサービス登録者ＩＤまたはＩｏＴサービス登録ＩＤのリストとして表現されていてもよく、サービス登録者ＩＤは、登録者の固有ＩＤであり、サービス登録ＩＤは、登録者とサービスプロバイダとの間の登録関係を識別するためのＩＤである。いくつかの実施形態例では、かかるＩＤは、互いに等価であってもよい。しかし、他の実施形態例では、登録者が１つのプロバイダと複数の有効なサービス登録を有することも可能であり得る。
－ユーザがどのＩｏＴデバイス、アプリケーションまたはデータに対して、どの操作をいつ、どこで行い得るかを制限するアクセスコントロール規則を特定する、ユーザのアクセスコントロール権限。
・サービス登録者が特定のサービスへのアクセスをリクエストできる、所望のまたは所要のサービススケジュール。
・ＡＳＥ－Ｓが、サービス登録者に対する警告となり得るステイタスアップデートおよび通知をＡＳＥ－Ｃに送信可能にする、サービス登録者の連絡先情報（ｅメール、テキストなど）。

別の実施形態例では、サービス登録者は、サービス登録者の登録の際に前もってＩｏＴデバイス、アプリケーション、データセットおよびユーザの全てに関する登録情報の全てを一度に特定することを必要としなくてもよく、またはこれに限定されなくてもよい。むしろ、ＩｏＴデバイス、アプリケーション、データセットおよびユーザについてのさらなる登録情報は、登録者のデバイス、アプリケーション、データセットまたはユーザがそれぞれ登録されるときなどに特定してもよい。例えば、ユーザが登録された場合、そのデバイス、アプリケーションおよびデータが登録されてもよく、デバイスが登録された場合、そのアプリケーションおよびデータが登録されてもよい。これにより、登録プロセスに拡張性とスケーラビリティがもたらされる。

ＡＳＥ－ＳからＡＳＥ－Ｃに返される登録応答に含まれ得るサービス登録中心の情報の種類としては、限定されないが、以下の１つ以上を含んでいてもよい：
・サービス登録が正常に完了しているか否かを示す全体的な登録ステイタス。登録が正常に完了していない場合は、その理由。
・登録が正常に完了および／または失敗であったＩｏＴデバイス、アプリケーション、データセットまたは認証ユーザのリスト。特定のデバイス、アプリケーション、データセットまたは認証ユーザの登録が正常に完了していない場合は、その理由。
・サービス登録者のＩｏＴデバイス、アプリケーション、データセットおよびユーザの許可されたサービス登録者の関係の表示。例えば、サービスプロバイダは、所与のデバイスに対して特定のアプリケーションまたはデータフォーマットをサポートしないことがある。
・サービス登録の有効期間。この期間が経過する前に再登録が行われない場合、サービス登録は延長されてもよい。
・登録者がサービスプラットフォームと相互作用するために使用し得るサービスプロバイダ機能に関する情報、例えば、登録／ブートストラップサーバＰｏＣ、認証サーバＰｏＣ、ＤＭサーバＰｏＣ。
・サービス登録者およびそのＩｏＴエンティティがＩｏＴサービスプラットフォームと通信するために使用し得るプロトコルに関連する要求のリスト。
・サービススケジュール情報（例えば、サービス登録者が特定のサービスの使用をいつ許可されるか）。

上述した自動サービス登録（ＡＳＥ）機能のｏｎｅＭ２Ｍ実施形態の例を以下に記載する。新規ＡＳＥ能力を使用することにより、ｏｎｅＭ２Ｍサービス加入者（すなわち、登録者）の仮想化、ｏｎｅＭ２Ｍサービス加入者による１つ以上の利用可能なｏｎｅＭ２Ｍサービスプロバイダの発見、および１つ以上のｏｎｅＭ２ＭサービスプロバイダへのｏｎｅＭ２Ｍサービス加入者の登録が可能になり得る。

ｏｎｅＭ２Ｍアーキテクチャの中で、本明細書に記載されるＡＳＥ－Ｓ能力は、図１２に示したとおり、共通サービスエンティティ（ＣＳＥ）の新規共通サービス機能（ＣＳＦ）として実行されてもよい。かかる新規ＣＳＦを使用することにより、ｏｎｅＭ２Ｍシステム中のＡＳＥ－Ｓサポートが可能になり得る。これに代えて、ＡＳＥ－Ｓはまた、既存のｏｎｅＭ２Ｍ ＣＳＦ（例えば、セキュリティＣＳＦ）の能力として、またはｏｎｅＭ２Ｍが定義したＭ２Ｍ登録機能（ＭＥＦ）またはＭ２Ｍ認証機能（M2M Authentication Function：ＭＡＦ）の能力として実行されてもよい。

ＡＳＥ－Ｃ機能は、ｏｎｅＭ２Ｍアプリケーションエンティティ（ＡＥ）およびｏｎｅＭ２Ｍ ＣＳＥによってサポートされてもよい。一実施形態例では、ＡＥは、ＡＳＥ－Ｃを介して自動登録リクエストを開始し、かかるリクエストを、ＭＥＦ、ＭＡＦまたはＣＳＥによってホストされるＡＳＥ－Ｓに送ってもよい。

現時点で、ｏｎｅＭ２Ｍは、登録者を、汎用アプリケーション（すなわち、ｏｎｅＭ２Ｍ ＡＥ）または汎用デバイス（すなわち、ｏｎｅＭ２Ｍノード）として定義する。登録者が、１つ以上のＩｏＴデバイス、ＩｏＴアプリケーション、ＩｏＴデータセットおよび／または認証ユーザにわたって所有権および／または管理者権限を有するｏｎｅＭ２Ｍサービス加入者となることを可能にするｏｎｅＭ２Ｍ登録手順の改良が本明細書に記載される。一実施形態例では、本明細書に記載するとおり、ＡＳＥのサービス登録者仮想化能力を使用し、サービス加入者のアイデンティティおよびそのＩｏＴデバイス、アプリケーション、データセット、認証ユーザ、ならびにサービス登録嗜好およびポリシーについての知識を有する特殊な種類のｏｎｅＭ２Ｍ ＡＥ中でｏｎｅＭ２Ｍサービス加入者を仮想化してもよい。

これに加え、仮想化されたサービスプロバイダは、サービスプロバイダのアイデンティティ、サービスプロバイダの登録オプションに関する情報、およびサービスプロバイダに代わって仮想化されたサービス加入者の登録を管理する権限についての知識を有する、ｏｎｅＭ２Ｍ登録機能（ＭＥＦ）、ｏｎｅＭ２Ｍ認証機能（ＭＡＦ）、またはｏｎｅＭ２Ｍ ＣＳＥであってもよい。

ソフトウェア仮想化ｏｎｅＭ２Ｍサービス加入者は、サービスプロバイダに自身を登録するだけではなく、加入者の個々のＩｏＴデバイス、ＩｏＴアプリケーション、ＩｏＴデータセットおよび／または認証ユーザも登録するために、改良されたサービス登録手順を使用してもよい。これは、それぞれのｏｎｅＭ２Ｍアプリケーション（ＡＥ）およびデバイス（ノード）が個々に登録されるのを必要とする既存のｏｎｅＭ２Ｍ登録プロセスを自動化し、単純化する１つの登録手順で行われてもよい。さらなる利点は、サービス加入者を、そのＩｏＴデバイス、ＩｏＴアプリケーション、ＩｏＴデータセットおよび／または認証ユーザとの関連付けを有するｏｎｅＭ２Ｍシステム中の仮想化されたエンティティとして表すことができる点である。既存のｏｎｅＭ２Ｍアーキテクチャでは、サービス加入者自身についてのアウェアネスまたはサポートは存在せず、個々のＩｏＴアプリケーションおよびデバイスについてのみサポートが存在する。この能力を導入することによって、ｏｎｅＭ２Ｍサービス層は、さらなる種類の自動登録サービスをサービス加入者に提供することが可能になり得る（例えば、サービス加入者とその登録されたデバイスおよびアプリケーションの自動利用登録、ならびに、これらのエンティティのアクセスコントロール権の自動構成）。

ｏｎｅＭ２Ｍ ＣＳＥ、ＭＥＦまたはＭＡＦは、本明細書に記載したＡＳＥのサービス登録公開、照会及び発見サーバ能力をサポートしてもよい。リソースまたは属性は、ＣＳＥ、ＭＥＦまたはＭＡＦによって使用され、対応するサービスプロバイダがサポートするサービス登録オプションの種類の記述を公開してもよい。この記述は、ＡＳＥのサービス登録公開、照会及び発見サーバ能力によってサポートされる１種類以上の情報を含んでいてもよい。

一実施形態例では、サービス登録オプションは、リソース属性中に保存されていてもよい。例えば、図１３に示したとおり、＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、＜ＭＥＦＢａｓｅ＞または＜ＭＡＦＢａｓｅ＞などのｏｎｅＭ２Ｍが定義するリソース型のうち１つ以上のｅｎｒｏｌｌｍｅｎｔＯｐｔｉｏｎｓ属性であってもよい。

これに代えて、またはこれに加えて、かかる情報は、新規なｏｎｅＭ２Ｍが定義するリソース型に保存されていてもよい。例えば、この情報は、図１４に示したとおり、ｏｎｅＭ２Ｍが定義するリソース型、例えば、＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、＜ＭＥＦＢａｓｅ＞または＜ＭＡＦＢａｓｅ＞のうち１つ以上の新規ｅｎｒｏｌｌｍｅｎｔＯｐｔｉｏｎｓ子リソース中に保存されていてもよい。

この新規属性またはリソースを使用し、図１５に示したとおり、ｏｎｅＭ２Ｍサービスプロバイダ登録オプションを公開してもよい。

工程１で、ｏｎｅＭ２Ｍサービスプロバイダは、サポートするサービス登録オプションを定義してもよい。

工程２で、ｏｎｅＭ２ＭサービスプロバイダＡＥは、そのサービスプラットフォーム中のＭＥＦ、ＭＡＦまたはＣＳＥに、サポートされるサービス登録オプションを公開してもよい。この公開は、サービス登録オプションを伴うＭＥＦ、ＭＡＦまたはＣＳＥでホストされるリソースまたは属性の作成またはアップデートを含んでいてもよい。

工程３で、ＭＥＦ、ＭＡＦまたはＣＳＥは、サービス登録オプションを伴う、リクエストされたリソースの作成またはアップデートによって、そのリクエストに応えてもよい。

工程４で、ＭＥＦ、ＭＡＦまたはＣＳＥは、そのリクエストを開始したサービスプロバイダＡＥに応答を返してもよい。ステイタスは、そのリクエストが正常に完了したか否かを示す応答に含まれていてもよい。

公開されたら、次いで、登録オプションは、図１６に示したとおり、ｏｎｅＭ２Ｍサービス加入者の要求を満たすサービス登録オプションを提供するｏｎｅＭ２Ｍサービスプロバイダを見つけようとし得る潜在的なｏｎｅＭ２Ｍサービス加入者によって照会および発見されてもよい。

工程１で、ｏｎｅＭ２Ｍサービス加入者は、自身が求めるサービスプロバイダの種類を定め得るサービス登録要求を定義してもよい。

工程２で、ｏｎｅＭ２Ｍサービス加入者ＡＥは、自身が必要とする要求をサポートするｏｎｅＭ２Ｍサービスプロバイダを発見するためのクエリを発行してもよい。かかるクエリは、特定のＭＥＦ、ＭＡＦまたはＣＳＥに向けられてもよい。これに代えて、クエリは、所与のドメインまたは位置で利用可能なサービスプロバイダを発見するためのブロードキャストまたはマルチキャストであってもよい。

工程３で、ＭＥＦ、ＭＡＦまたはＣＳＥは、このクエリを処理してもよい。クエリを処理するために、ＭＥＦ、ＭＡＦまたはＣＳＥは、その代表となるサービスプロバイダが基準に一致するどうかを決定するためにクエリ条件を分析してもよい。これに代えて、またはこれに追加して、ＭＥＦ、ＭＡＦまたはＣＳＥは、登録オプションの完全なリストを提供し、どの関連情報がＡＥにとって重要であるかをＡＥに決定させてもよい。

工程４で、ＭＥＦ、ＭＡＦまたはＣＳＥは、クエリを開始したサービス加入者ＡＥに応答を返してもよい。ステイタスは、発見が正常に処理されたか否か、および、一致するサービスプロバイダが見つかったか否かを示す応答に含まれていてもよい。これに加えて、サービスプロバイダクレデンシャル（例えば、公開証明書）も応答に含まれていてもよい。

上述したｏｎｅＭ２Ｍサービス登録手順の改良を可能にするために、仮想化されたサービス加入者（すなわち、サービス加入者を表すｏｎｅＭ２Ｍ ＡＥ）と仮想化されたサービスプロバイダ（すなわち、サービスプロバイダを表すｏｎｅＭ２Ｍ ＭＥＦ、ＭＡＦまたはＣＳＥ）との間に確立され得る新規な種類のｏｎｅＭ２Ｍセキュリティアソシエーションが導入されてもよい。この新規な種類のｏｎｅＭ２Ｍセキュリティアソシエーションにより、仮想化されたサービス加入者と仮想化されたサービスプロバイダとの間で信頼の確立が可能になり得る。かかる信頼は、仮想化されたサービスプロバイダが真のサービスプロバイダであり、加入者が発見して登録を決定した仮想化されたサービスプロバイダであることを認証する仮想化されたサービス加入者によって確立されてもよい。同様に、サービスプロバイダは、サービス加入者を認証して、加入者のアイデンティティが真であり、信頼できることを保証してもよい。仮想化されたサービス加入者とサービスプロバイダとの間のこの新規なｏｎｅＭ２Ｍセキュリティアソシエーションをさらに可能にするために、いくつかのＡＳＥが定義する特徴の実施形態の一例が、ｏｎｅＭ２Ｍアーキテクチャに導入される。

ｏｎｅＭ２Ｍサービス加入者およびｏｎｅＭ２Ｍサービスプロバイダが、互いを認証して信頼することを可能にするこのような特徴の１つは、ｏｎｅＭ２Ｍサービス加入者クレデンシャルおよびｏｎｅＭ２Ｍサービスプロバイダクレデンシャルといった２つの新規なｏｎｅＭ２Ｍが定義するクレデンシャルの導入である。一実施形態例では、これらのクレデンシャルは、仮想化されたサービス加入者ＡＥと仮想化されたサービスプロバイダＭＥＦ、ＭＡＦまたはＣＳＥとの間に提供および共有され得る事前共有対称鍵の形態をしていてもよい。別の実施形態例では、新規なｏｎｅＭ２Ｍ証明書プロファイルは、ｏｎｅＭ２Ｍサービス加入者のために導入されてもよく、別のｏｎｅＭ２Ｍ証明書プロファイルは、ｏｎｅＭ２Ｍサービスプロバイダのために導入されてもよい。ｏｎｅＭ２Ｍサービス加入者証明書プロファイルにおいて、ｏｎｅＭ２Ｍサービス加入識別子が証明書に含まれていてもよく、これにより、ｏｎｅＭ２Ｍサービス加入者証明書となり得る。例えば、ｏｎｅＭ２Ｍサービス加入識別子は、サービス加入者のＳＳＬ証明書のｓｕｂｊｅｃｔＡｌｔＮａｍｅ拡張フィールド内に含まれていてもよい。同様に、ｏｎｅＭ２Ｍサービスプロバイダ証明書プロファイルにおいて、ｏｎｅＭ２Ｍサービスプロバイダ識別子は証明書内に構成されてもよく、これにより、ｏｎｅＭ２Ｍサービスプロバイダ証明書となり得る。

別の特徴は、サービス加入者とプロバイダとのセキュリティアソシエーションの確立のために前提条件として必要とされるサービス加入者およびプロバイダの識別子およびクレデンシャルを用い、仮想化されたサービス加入者ＡＥおよび仮想化されたサービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥを管理し、遠隔でブートストラップするためのＡＰＩの導入である。

ＲＥＳＴｆｕｌ ＡＰＩは、図１７および図１８において、ｏｎｅＭ２Ｍサービスプロバイダに１つ以上の登録クレデンシャルの構成を管理させるために導入される。サービスプロバイダは、このＡＰＩを使用し、ｏｎｅＭ２Ｍ ＭＥＦ、ＭＡＦまたはＣＳＥ内に登録クレデンシャルの集合を作成してもよい。クレデンシャルの集合が作成された後、ＭＥＦ、ＭＡＦまたはＣＳＥは、サービスプロバイダの代わりに登録者へのクレデンシャルの配布、およびクレデンシャルの有効期間管理（例えば、使用有効期限の管理など）を管理してもよい。ＡＰＩは、ＡＰＩリソースをホストするｏｎｅＭ２Ｍエンティティに応じたベースリソース、例えば、＜ＭＥＦＢａｓｅ＞、＜ＭＡＦＢａｓｅ＞または＜ＣＳＥＢａｓｅ＞を含んでいてもよい。それぞれのｏｎｅＭ２Ｍサービスプロバイダは、自身のリソース（すなわち、＜ＳＰＢａｓｅ＞）を、ＡＰＩのベースリソースの下の子リソースとして有していてもよい。＜ＳＰＢａｓｅ＞リソースは、サービスプロバイダ識別子で構成された属性などの複数の属性を有していてもよい。＜ＳＰＢａｓｅ＞リソースは、子リソース、例えば、サービスプロバイダが潜在的な登録者のために作成する集合クレデンシャル中のそれぞれのクレデンシャルのためのリソースも有していてもよい。集合中のそれぞれのクレデンシャルは、自身のリソース（すなわち、＜ｃｒｅｄｅｎｔｉａｌＩｎｆｏ＞）を有していてもよい。かかるリソースは、所与のクレデンシャルの属性を含んでいてもよい。ある属性は、サポートされるｏｎｅＭ２Ｍ証明書または鍵の種類で構成され得るクレデンシャルの種類（すなわち、ｃｒｅｄｅｎｔｉａｌＴｙｐｅ）であってもよい。これに代えて、クレデンシャルをさらに秘密かつ安全に保持するために、クレデンシャルは、隠されたままであり、個々のリソースに保存されなくてもよい。その代わりに、リソースは、クレデンシャルの作成およびブートストラップを可能にするようにエントリーポイント（例えば、バーチャルリソース）として定義されてもよい。なお、このさらに安全なオプションは、以下の図１７－１８には示されていないが、＜ｃｒｅｄｅｎｔｉａｌＩｎｆｏ＞リソースをバーチャルリソースと置き換えることを含んでいてもよい。他の属性は、以下のうち１つ以上を含んでいてもよい：クレデンシャルが登録者に割り当てられているか否かを示すために、例えば、未割り当てであるか、または割り当てられた値で構成され得るクレデンシャルの状態（すなわち、ｃｒｅｄｅｎｔｉａｌＳｔａｔｅ）；クレデンシャルの固有の識別子で構成され得るクレデンシャルの識別子（すなわち、ｃｒｅｄｅｎｔｉａｌＩＤ）；登録者のｏｎｅＭ２Ｍ準拠鍵または証明書で構成され得るクレデンシャルそのもの（すなわち、ｃｒｅｄｅｎｔｉａｌ）；および、クレデンシャルが割り当てられたエンティティの識別子で構成され得るクレデンシャルの割当担当者（すなわち、ａｓｓｉｇｎｅｅ）。

図１８は、サービス加入者クレデンシャルを作成するための手順の一例を示す。

工程１で、ｏｎｅＭ２Ｍサービスプロバイダは、サービス加入者クレデンシャルおよび識別子の集合を作成してもよい。

工程２で、集合中のそれぞれのクレデンシャルについて、ｏｎｅＭ２Ｍサービスプロバイダは、＜ｃｒｅｄｅｎｔｉａｌＩｎｆｏ＞リソースを作成するよう、そのサービスプラットフォーム内のＭＥＦ、ＭＡＦまたはＣＳＥに対して作成リクエストを発してもよい。

工程３で、ＭＥＦ、ＭＡＦまたはＣＳＥは、サービスプロバイダのために＜ｃｒｅｄｅｎｔｉａｌＩｎｆｏ＞リソースを作成することによって、このリクエストに応えてもよい。

工程４で、ＭＥＦ、ＭＡＦまたはＣＳＥは、このリクエストを開始したサービスプロバイダＡＥに応答を返してもよい。ステイタスは、そのリクエストが正常に完了したか否かを示す応答に含まれていてもよい。

さらなるＲＥＳＴｆｕｌ ＡＰＩは図１９および図２０に示してあり、これにより、仮想化されたサービス加入者ＡＥは、自身とサービスプロバイダとの間の安全な関連付け（セキュアアソシエーション）を確立するために必要な、必須のサービス加入者およびプロバイダの識別子およびクレデンシャルを用いて安全にブートストラップすることが可能となる。このＡＰＩは、ｏｎｅＭ２Ｍ ＭＥＦ、ＭＡＦまたはＣＳＥによってサポートされるクレデンシャルプロビジョニング特徴を含んでいてもよい。かかるプロビジョニング特徴によって、仮想化されたサービス加入者ＡＥは、サービス加入者クレデンシャルプロビジョニングリクエストをＭＥＦ、ＭＡＦまたはＣＳＥに発することが可能となり得る。このＡＰＩを使用するために、仮想化されたサービス加入者ＡＥは、まず、あらかじめプロビジョニングされたブートストラップクレデンシャル（例えば、製造者などによってあらかじめプロビジョニングされたものなど）を用い、ＭＥＦ、ＭＡＦまたはＣＳＥとの安全な関連付け（セキュアアソシエーション）を確立することを要求され得る。ＡＰＩは、仮想化されたサービス加入者ＡＥによるブートストラップリクエストを対象とするために使用可能なバーチャルリソース（すなわち、＜ｂｏｏｔｓｔｒａｐ＞）をサポートしていてもよい。このリクエスト中に、仮想化されたサービス加入者ＡＥは、登録することに興味があるサービスプロバイダの識別子などの情報を含んでいてもよい。このリクエストを受信した場合、ＭＥＦ、ＭＡＦまたはＣＳＥは、対象のサービスプロバイダに代わってＭＥＦ、ＭＡＦまたはＣＳＥが作業し得るか否かを決定してもよい。そうであれば、ＭＥＦ、ＭＡＦまたはＣＳＥは、対象としたサービスプロバイダのため、利用可能なクレデンシャルの集合のうち利用可能なクレデンシャルおよび識別子を割り当ててもよい（存在する場合）。次いで、ＭＥＦ、ＭＡＦまたはＣＳＥは、必要とされ得る任意のサービスプロバイダクレデンシャル（例えば、サービスプロバイダの公開鍵／証明書）と共に、この識別子およびクレデンシャルをサービス加入者に返してもよい。

図２０は、サービス加入者がクレデンシャルをブートストラップする手順の一例を示す。

工程１で、ｏｎｅＭ２Ｍサービス加入者は、サービス加入者クレデンシャルをブートストラップしたいサービスプロバイダを決定してもよい。この決定は、サービス加入者が行うサービスプロバイダ発見手順の結果であってもよい。

工程２で、ｏｎｅＭ２Ｍサービス加入者ＡＥは、ｏｎｅＭ２Ｍサービスプロバイダにブートストラップリクエストを発してもよい。このリクエストは、このサービスプロバイダと関連付けられた特定のＭＥＦ、ＭＡＦまたはＣＳＥに向けられ、サービス加入者が行い得るサービスプロバイダ発見手順中に発見されてもよい。これに代えて、このリクエストは、所与のドメインまたは位置で利用可能なサービスプロバイダにブロードキャストまたはマルチキャストされてもよい。このブートストラッププロセスを確保するために、ブートストラップクレデンシャルは、サービス加入者ＡＥによって必要とされてもよい。一実施形態例では、ブートストラップクレデンシャルは、サービスプロバイダ発見手順中に得られてもよい。

工程３で、ＭＥＦ、ＭＡＦまたはＣＳＥは、サービス加入者ＡＥを認証し、次いで、ブートストラップリクエストに応えてもよい。このリクエストを処理するために、ＭＥＦ、ＭＡＦまたはＣＳＥは、このリクエスト中の特定のサービスプロバイダ識別子を分析し、サービスプロバイダの代わりにブートストラップリクエストに応え得るプロバイダであるか否かを決定してもよい。

工程４で、ＭＥＦ、ＭＡＦまたはＣＳＥは、ブートストラップリクエストを開始したサービス加入者ＡＥに応答を返してもよい。ステイタスは、ブートストラップが正常に処理されたか否かを示す応答に含まれていてもよい。ブートストラップが正常に処理された場合には、クレデンシャル情報も、この応答に含まれていてもよく、サービス加入者のクレデンシャルおよび識別子ならびにサービスプロバイダクレデンシャル情報（例えば、サービスプロバイダの公開鍵／証明書）を含んでいてもよい。

ｏｎｅＭ２Ｍサービス加入者とプロバイダとの間のセキュリティアソシエーションが正常に確立された後、セキュリティアソシエーションは、予約され、ｏｎｅＭ２Ｍサービス加入者（またはその認証ユーザの１人）とサービスプロバイダとの間でのみ行うことが許されている、特権登録操作のセットを行うために使用される。この操作は、この確立された信頼性のある安全な関連付けの上位で安全に行われてもよい。

サービス加入者登録は、仮想化されたｏｎｅＭ２Ｍサービス加入者ＡＥによって開始されてもよい。このリクエストは、本明細書に記載する１つ以上の種類の情報を含んでいてもよい。この情報の交換は、新規ｏｎｅＭ２Ｍが定義するリソースおよび／または属性の実施形態例をＭＥＦ、ＭＡＦまたはＣＳＥに追加することによって可能となり得る。次いで、仮想化されたサービス加入者ＡＥは、これらの新しく定義したリソース／属性をそのサービス加入者登録プロセスの一環として作成またはアップデートしてもよい。この新規リソース、属性および手順は、図２１および図２２に示される。

サービス加入者は、ＭＥＦ、ＭＡＦまたはＣＳＥ上で登録情報リソース（例えば、＜ｍｅｆＣｌｉｅｎｔＲｅｇ＞、＜ｍａｆＣｌｉｅｎｔＲｅｇ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＲｅｇ＞）を作成することによって、登録を開始してもよい。このリソースの作成は、ＭＥＦ、ＭＡＦまたはＣＳＥをトリガして、リクエストをサービス加入者登録リクエストとして処理してもよい。このリソースは、サービス加入者が、サービスプロバイダへの登録に含ませたい自身に関する情報（すなわち、ｅｎｒｏｌｌｅｅＩｎｆｏ）、そのＩｏＴデバイスに関する情報（すなわち、ｄｅｖｉｃｅＩｎｆｏ）、そのアプリケーションに関する情報（すなわち、ａｐｐＩｎｆｏ）、そのデータに関する情報（すなわち、ｄａｔａＩｎｆｏ）およびそのユーザに関する情報（すなわち、ｕｓｅｒＩｎｆｏ）で構成し得るいくつかの属性をサポートしていてもよい。このリソースは、サービス加入のための識別子で構成され得る属性も含んでいてもよい。この属性は、登録リクエストが正常に処理され、サービス加入のための識別子が作成された結果として、ＭＥＦ、ＭＡＦまたはＣＳＥによって構成されてもよい。

図２２は、サービス加入者がサービスプロバイダに登録する手順の一例を示す。

工程１で、ｏｎｅＭ２Ｍサービス加入者は、所与のサービスプロバイダに登録するＩｏＴデバイス、アプリケーション、データおよびユーザを決定してもよい。この決定は、本明細書に記載するＡＳＥのサービス登録者仮想化能力の上述の機能性のうち少なくともいくつかを利用して行われてもよい。

工程２で、ｏｎｅＭ２Ｍサービス加入者ＡＥは、ｏｎｅＭ２Ｍサービスプロバイダに対して登録リクエストを発してもよい。このリクエストは、登録リソースの作成（ＣＲＥＡＴＥ）であってもよい。リソースは、登録したいサービス加入者のデバイス、アプリケーション、データおよびユーザに関連する登録情報を含んでいてもよい。このリクエストは、発見され、セキュリティアソシエーションが確立されたサービスプロバイダに関連付けられた特定のＭＥＦ、ＭＡＦまたはＣＳＥに向けられていてもよい。

工程３で、ＭＥＦ、ＭＡＦまたはＣＳＥは、この登録リクエストに応えてもよい。このリクエストを処理するために、ＭＥＦ、ＭＡＦまたはＣＳＥは、このリクエスト中の特定のサービスプロバイダ識別子を分析し、このサービスプロバイダが、ＭＥＦ、ＭＡＦまたはＣＳＥが代わりに登録リクエストに応え得るプロバイダであるか否かを決定してもよい。ＭＥＦ、ＭＡＦまたはＣＳＥは、本明細書に記載するＡＳＥのサービス登録能力によって導入される様式で、このリクエストを処理してもよい。この処理は、以下に記載する進化した特徴をいくつか含んでいてもよく、以下のものを含んでいてもよい：登録者のＩＮ－ＣＳＥまたはレジストラＣＳＥ上の、ｏｎｅＭ２Ｍサービス加入に関連するリソースの自動作成（例えば、＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＮｏｄｅ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＡｐｐＲｕｌｅ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＵｓｅｒ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＤａｔａＲｕｌｅ＞）、登録者のためのアクセスコントロールポリシーの自動作成（例えば、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの作成およびａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓの設定）、および登録者のＩｏＴデータセットのインポートおよび保存のためのデータコントロールポリシーおよびリソースの自動作成。

工程４で、ＭＥＦ、ＭＡＦまたはＣＳＥは、登録リクエストを開始したサービス加入者ＡＥに応答を返してもよい。ステイタスは、登録が正常に処理されたか否かを示す応答に含まれていてもよい。

別の実施形態例では、仮想化されたｏｎｅＭ２Ｍサービス加入者ＡＥから受信し得る登録リクエストを処理するｏｎｅＭ２ＭサービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥは、本明細書に記載するＡＳＥのサービス登録能力によって導入される進化した操作のうち１つ以上をトリガおよび実行してもよい。

一実施形態例では、サービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥは、登録を認証し、登録されたサービス加入者のＩｏＴデバイス、アプリケーション、データへのアクセスを認証するためにレジストラＣＳＥによって使用され得る一群のリソースを、サービスプロバイダの代わりに自動作成してもよい。これらのリソースは、システムへのアクセスが許可され得るデバイス、アプリケーションおよびデータの識別子、およびデバイス、アプリケーションおよびデータへのアクセスが許可され得るエンティティの識別子などの情報で構成されてもよい。登録時にＭＥＦ、ＭＡＦまたはＣＳＥによって自動作成され得る認証に関連するリソースのセットは、いくつかの既存のｏｎｅＭ２Ｍリソース型および本明細書に記載するいくつかの新規リソース型を含んでいてもよい。既存のリソースのセットは、＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＮｏｄｅ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＡｐｐＲｕｌｅ＞および＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を含んでいてもよい。新規リソースのセットは、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＵｓｅｒ＞、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＤａｔａＲｕｌｅ＞および＜ｄａｔａＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を含んでいてもよい。これらそれぞれのリソースの例は、対応する以下の図面に示される。なお、既存のｏｎｅＭ２Ｍリソース型について、新しく導入されたか、または修正された属性のみが示されている。これらのリソースの自動作成は、サービス加入者ＡＥの正常に完了した登録によってトリガされてもよい。これらのリソースの属性内で構成された情報は、その登録リクエスト中のサービス加入者によって提供される情報および／またはサービスプロバイダによってＭＥＦ、ＭＡＦまたはＣＳＥ中で構成されるポリシーに左右され得る。

図２３は、サービス加入者の登録が正常に完了したときに自動作成され得る改良された＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞リソースを示す。新規＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＲｅｇ＞リソース中の情報を使用し、対応する＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞リソースを自動作成してもよい。新規ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＩＤ属性は、加入を一意に識別し、追跡するために導入される。ｄｅｆａｕｌｔＡＣＰＩＤｓ属性が導入され、ｄｅｆａｕｌｔＡＣＰＩＤｓ属性は、登録者がその登録リクエスト中で定義し得る権限で構成され得る＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよい。これらの権限は、サービス加入の下で登録されるＩｏＴデバイス、アプリケーションおよびデータのデフォルトとして作用し得る。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＵｓｅｒ＞子リソースが導入され、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＵｓｅｒ＞子リソースは、このサービス加入と関連付けられた認証ユーザのための情報を含んでいてもよい。このリソースのインスタンスは、認証ユーザごとに作成されてもよい。

図２４は、サービス加入者がＩｏＴデバイスの登録を正常に完了したときに自動作成され得る改良された＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＮｏｄｅ＞リソースを示す。ｄｅｆａｕｌｔＡＣＰＩＤｓ属性が導入され、ｄｅｆａｕｌｔＡＣＰＩＤｓ属性は、登録者がその登録リクエスト中で定義し得る権限で構成され得る＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよい。これらの権限は、この特定のノードに関連付けられるＩｏＴアプリケーションおよびデータのデフォルトとして作用し得る。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。

図２５は、サービス加入者の登録が正常に完了したときに自動作成され得る改良された＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＡｐｐＲｕｌｅ＞リソースを示す。ｄｅｆａｕｌｔＡＣＰＩＤｓ属性が導入され、ｄｅｆａｕｌｔＡＣＰＩＤｓ属性は、登録者がその登録リクエスト中で定義し得る権限で構成され得る＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよい。これらの権限は、これに関連付けられる所与のＩｏＴアプリケーションおよびデータのデフォルトとして作用し得る。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。ｒｕｌｅＬｉｎｋｓ属性も導入される。この属性は、１つ以上の＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＤａｔａＲｕｌｅ＞リソースへのリンクで構成されてもよい。

図２６は、サービス加入者の登録が正常に完了するときに自動作成され得る改良された＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを示す。ｐｒｉｖｉｌｅｇｅｓおよびｓｅｌｆＰｒｉｖｉｌｅｇｅｓの属性に対する改良は、ユーザ識別子のサポートを追加するために導入される。本明細書に記載したとおり、アクセスコントロール権限は、ユーザ識別子で定義されてもよい。その際、特定のユーザから受信したリクエストは、認証され、アクセスが許可され得る。また、本明細書に記載するのは、ｏｎｅＭ２Ｍリクエストプリミティブに対する改良であり、これにより＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞権限と照合できるよう、リクエストパラメータにＵｓｅｒ－ＩＤを含めることが可能となり得る。一実施形態例では、Ｕｓｅｒ－ＩＤは、リクエストパラメータの既存のｏｎｅＭ２Ｍに含まれていてもよい。別の実施形態例では、Ｕｓｅｒ－ＩＤは、新規リクエストパラメータとして追加されてもよい。

図２７は、サービス加入者の登録が正常に完了するときに自動作成され得る新しく導入された＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＵｓｅｒ＞リソースを示す。Ｕｓｅｒ－ＩＤ属性が導入され、ユーザの識別子で構成されてもよい。ｄｅｆａｕｌｔＡＣＰＩＤｓ属性が導入され、ｄｅｆａｕｌｔＡＣＰＩＤｓ属性は、登録者がその登録リクエスト中で定義し得る権限で構成され得る＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよい。これらの権限は、所与のユーザのデフォルトとして作用し得る。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。ｄｅｆａｕｌｔＤＣＰＩＤｓ属性も導入される。この属性は、＜ｄａｔａＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよく、登録者がその登録リクエスト中で定義し得る権限で構成されてもよい。これらの権限は、所与のユーザのデフォルトとして作用し得る。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。ｒｕｌｅＬｉｎｋｓ属性も導入される。この属性は、１つ以上の＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＡｐｐＲｕｌｅ＞または＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＤａｔａＲｕｌｅ＞リソースへのリンクで構成されてもよい。この属性は、ユーザがアクセスを許可され得るアプリケーションおよびデータに関する規則を特定する別の機構として作用してもよい。

図２８は、サービス加入者の登録が正常に完了するときに自動作成され得る新しく導入された＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＤａｔａＲｕｌｅ＞リソースを示す。ｄｅｆａｕｌｔＤＣＰＩＤｓ属性が導入され、登録者がその登録リクエスト中で定義し得る権限で構成され得る＜ｄａｔａＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクで構成されてもよい。さらなる権限は、これらのデフォルトを上書きするように定義されてもよい。

図２９は、サービス加入者の登録が正常に完了するときに自動作成され得る新しく導入された＜ｄａｔａＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを示す。いくつかの属性が導入される。ｒｅｓｏｕｃｅＴｙｐｅ属性は、このポリシーが適用可能な１つ以上のｒｅｓｏｕｃｅＴｙｐｅで構成されてもよい。ｓｐｅｃｉａｌｉｚａｔｉｏｎＴｙｐｅ属性は、このポリシーが適用可能な＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞特化型の１つ以上の型で構成されてもよい。ｍａｘＮｒＯｆＩｎｓｔａｎｃｅｓ属性は、所与のｃｏｎｔａｉｎｅｒまたはｔｉｍｅＳｅｒｉｅｓにおいて許可されるｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓまたはｔｉｍｅＳｅｒｉｅｓＩｎｓｔａｎｃｅｓの最大数に対するポリシー制限で構成されてもよい。ｍａｘＢｙｔｅＳｉｚｅ属性は、データ保存リソース、例えば、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞または＜ｔｉｍｅＳｅｒｉｅｓ＞に保存され得る最大バイト数で構成されてもよい。ｍａｘＩｎｓｔａｎｃｅＡｇｅ属性は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞または＜ｔｉｍｅＳｅｒｉｅｓＩｎｓｔａｎｃｅ＞リソースの最長寿命で構成されてもよい。ｓｕｐｐｏｒｔｅｄＳｃｈｅｍａｓ属性は、データ保存リソース中に保存されることが許可されるコンテンツの１つ以上の許可されるスキーマで構成されてもよい。ｓｕｐｐｏｒｔｅｄＯｎｔｏｌｏｇｉｅｓ属性は、データ保存リソース中に保存されることが許可されるコンテンツの１つ以上の許可されるオントロジーで構成されてもよい。

別の実施形態例では、サービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥは、その登録されるＩｏＴデバイスおよび／またはＩｏＴアプリケーションそれぞれについて、仮想化されたサービス加入者の代わりに、ｏｎｅＭ２Ｍ＜ｎｏｄｅ＞および／または＜ＡＥ＞リソースを自動作成してもよい。その際、ＩｏＴデバイスおよびアプリケーションは、より単純であり、自身でこれらの工程を行わなくてもよい。加入者のアプリケーションまたはデバイスが明示的に＜ＡＥ＞または＜ｎｏｄｅ＞リソースを作成する場合にサービス加入者にＡＥ－ＩＤおよびノード－ＩＤが返されるのではなく、これらの識別子は、登録応答中に返されてもよい。例えば、リソース制限があるデバイスは、ｏｎｅＭ２Ｍ ＡＥ利用登録を行う必要がない場合がある。なぜなら、この利用登録は、サービス加入者登録時に、そのデバイスに代わって自動的に行われ得るからである。

別の実施形態例では、サービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥは、ｏｎｅＭ２Ｍデータ保存ポリシーと、仮想化されたサービス加入者の登録されたＩｏＴデータセットのインポートおよび保存のためのリソースを自動作成してもよい。その際、ＩｏＴデバイスおよびアプリケーションは、より単純であり、自身でこれらの工程を行わなくてもよい。例えば、適用可能な種類のｏｎｅＭ２Ｍ保存系リソースは、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞、＜ｔｉｍｅＳｅｒｉｅｓ＞または＜ｔｉｍｅＳｅｒｉｅｓＩｎｓｔａｎｃｅ＞）を含んでいてもよい。

別の実施形態例では、サービスプロバイダのＭＥＦ、ＭＡＦまたはＣＳＥは、ｏｎｅＭ２Ｍ＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを自動作成してもよく、サービス加入者および／またはサービス加入者が登録しているＩｏＴデバイス、アプリケーション、データセットおよび／またはユーザの代わりに、これらのリソース内で認証権限を設定してもよい。リソースおよび権限の作成、設定およびリンク生成は、その登録リクエスト中のサービス加入者によって提供される情報（例えば、ポリシー）およびサービスプロバイダによって定義されるポリシーに左右され得る。＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースのこの自動作成、設定およびリンク作成は、他のリソース（例えば、＜ＡＥ＞、＜ｎｏｄｅ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞、＜ｔｉｍｅＳｅｒｉｅｓ＞、＜ｔｉｍｅＳｅｒｉｅｓＩｎｓｔａｎｃｅ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞）の自動作成が登録プロセス中にＭＥＦ、ＭＡＦまたはＣＳＥによって行われる場合に、トリガされ得る。これに加えて、トリガは、登録が完了した後、かつＡＥがさらなるリソースを作成したしばらく後に行われてもよい。これが行われた場合、ＭＥＦ、ＭＡＦも、同時にこの作業を行ってもよい。

図３０は、サービス層エンティティに仮想化されたサービス加入者の少なくとも１つのデバイスを登録および利用登録するためのプロセスの一例を示すフロー図である。

ブロック３０１０で、サービス層エンティティは、通信ネットワークに接続し得る複数のネットワークデバイスのユーザに関する情報と、複数のネットワークデバイスそれぞれに関する情報とを含む電子プロファイルを受信してもよい。それぞれのネットワークデバイスに関する情報は、ネットワークデバイスの関連識別子と、１つ以上の許可されたデータ型を含む関連データコントロールポリシーとを少なくとも含んでいてもよい。１つ以上の許可されたデータ型のうちの１つの許可されたデータ型は、データのフォーマットを含んでいてもよい。電子プロファイルは、以下のもののうち少なくとも１つをさらに含んでいてもよい：１つ以上の許可されたアプリケーション、１人以上の認証ユーザ、１つ以上の選択されたサービス登録選択項目、１つ以上の特定のアクセス権限、および１つ以上のサービス登録有効期間。

ブロック３０２０で、サービス層エンティティは、サービス層エンティティのメモリにおいて、１つ以上のリソースを作成してもよい。サービス層エンティティは、１つ以上のリソース内に、ユーザおよび複数のネットワークデバイスそれぞれに関し、電子プロファイル中のそれぞれのネットワークデバイスの関連識別子と関連データコントロールポリシーとを含む、電子プロファイル中に含まれる情報を保存してもよい。

ブロック３０３０で、サービス層エンティティは、通信ネットワークに接続したネットワークデバイスから、当該ネットワークデバイスをサービス層エンティティに利用登録するよう求める電子リクエストを受信してもよい。このリクエストは、リクエストするネットワークデバイスが通信ネットワーク上で送信するように構成されるデータの第１識別子と第１データ型とを含んでいてもよい。

ブロック３０４０で、サービス層エンティティは、１つ以上のリソースに基づき、リクエストするネットワークデバイスの第１識別子と、電子プロファイル中の複数のデバイスのうちの１つの関連識別子とが一致すると決定してもよい。

ブロック３０５０で、サービス層エンティティはまた、１つ以上のリソースに基づき、リクエストするデバイスの第１データ型と、電子プロファイル中で一致する識別子を有するデバイスの関連データコントロールポリシーの許可されたデータ型の１つとが一致すると決定してもよい。

ブロック３０６０で、サービス層エンティティは、この決定に基づき、リクエストするデバイスをサービス層エンティティに利用登録してもよい。

登録の後、サービス層エンティティは、リクエストするデバイスが第２データ型を作成し、第２のデータ型と、電子プロファイル中で一致する識別子を有するデバイスの関連データコントロールポリシーの許可されたデータ型の１つ以上とが一致しないと決定してもよい。次いで、サービス層エンティティは、リクエストするデバイスを登録解除してもよい。

図３１に示すユーザインターフェースは、サービス登録者による、サービス登録者自身およびそのＩｏＴデバイス、アプリケーション、データセットおよび認証ユーザのソフトウェア仮想化を補助するために実装されていてもよい。特に、インターフェースは、ユーザが、エンティティを設定および配置する間に、パラメータの所望の値を入力することまたはパラメータの値にアクセスすることが可能になるように、グラフィカルユーザインターフェース（ＧＵＩ）を有していてもよい。ユーザインターフェースは、ＩｏＴサービス登録者の仮想化を自動化するための写真の使用をサポートしてもよい。例えば、デバイスの製造者、型式およびシリアル番号などの情報は、写真、デバイス上に印刷された情報、または一致を見つけるためのＩｏＴデバイス画像のデータベースとデバイス画像との比較から抽出されてもよい。写真からさらに抽出または推測され得る他の種類の情報は、ＩｏＴデバイスの位置および使用であってもよい。どのユーザにデバイスへのアクセスおよび使用を許可するかなど、登録者にＩｏＴデバイスに関する質問をするために、ユーザインターフェースを使用してもよい。図３１に示すように、入力ボックスおよび／または選択ボタンを使用し、属性を入力または変更してもよい。

（環境例）
図３２Ａは、１つ以上の開示された実施形態が実装され得る、マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の一例の図である。一般的に、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのためのビルディングブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサーバまたはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴおよびＩｏＴ／ＷｏＴサービス層のコンポーネントまたはノードなどであってもよい。図１、３－６、８－１２、１５、１６、１８、２０または２２のいずれかに示されるクライアント、プロキシまたはサーバデバイスのいずれかは、通信システムのノード（例えば、図３２Ａ－Ｄに示されるもの）を含んでいてもよい。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であってもよい。サービス層は、典型的には、アプリケーションプロトコル層、例えば、ＨＴＴＰ、ＣｏＡＰまたはＭＱＴＴの上に配置され、クライアントアプリケーションに付加価値サービスを提供する。サービス層はまた、下位リソース層（例えば、コントロール層および伝送／アクセス層）で、コアネットワークへのインターフェースを提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシー管理、アクセスコントロールおよびサービスクラスタリングを含む、複数カテゴリーの（サービス）能力または機能性をサポートする。近年、いくつかの産業標準化団体（例えば、ｏｎｅＭ２Ｍ）は、Ｍ２Ｍ型のデバイスおよびアプリケーションを、インターネット／ウェブ、セルラー、エンタープライズおよびホームネットワークなどの配置に統合することに関連する課題に対処するために、Ｍ２Ｍサービス層を開発しつつある。Ｍ２Ｍサービス層は、サービス層（ＣＳＥまたはサービス能力層（Service Capability Layer：ＳＣＬ）と呼ばれる）によってサポートされる上述の能力または機能性の一群またはセットへのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例としては、限定されないが、種々のアプリケーションによって一般的に使用可能なセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造およびリソース表現を活用するＡＰＩを介し、かかる種々のアプリケーションが利用できるようになっている。ＣＳＥまたはＳＣＬは、機能エンティティであって、ハードウェアおよび／またはソフトウェアによって実装可能であり、種々のアプリケーションおよび／またはデバイス（すなわち、機能エンティティ間の機能インターフェース）が使用できるよう、種々のアプリケーションおよび／またはデバイスに対して公開されている（サービス）能力または機能性を提供する、機能エンティティである。

図３２Ａに示すとおり、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を備えている。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣなど）または無線ネットワーク（例えば、ＷＬＡＮ、セルラーなど）、または異種ネットワークのネットワークであってもよい。例えば、通信ネットワーク１２は、複数ユーザに対して音声、データ、映像、メッセージ、放送などのコンテンツを提供する多元接続ネットワークで構成されていてもよい。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access：ＣＤＭＡ）、時分割多元接続（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多元接続（Frequency Division Multiple Access：ＦＤＭＡ）、直交ＦＤＭＡ（Orthogonal FDMA：ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（Single-Carrier FDMA：ＳＣ－ＦＤＭＡ）などの１つ以上のチャネルアクセス方法を使用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、ホームネットワークまたはエンタープライズネットワークなどの他のネットワークを含んでいてもよい。

図３２Ａに示すとおり、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを備えていてもよい。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ配置のネットワーク側を指し、フィールドドメインは、エリアネットワークを指し、通常は、Ｍ２Ｍゲートウェイの背後にある。フィールドドメインとインフラストラクチャドメインは、両方とも、ネットワークの種々の異なるノード（例えば、サーバ、ゲートウェイ、デバイスなど）を備えていてもよい。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、デバイス１８とを備えていてもよい。必要に応じた任意の数のＭ２Ｍゲートウェイデバイス１４とＭ２Ｍデバイス１８がＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれていてもよいことが理解されるだろう。Ｍ２Ｍゲートウェイデバイス１４とＭ２Ｍデバイス１８のそれぞれは、通信ネットワーク１２または直接的な無線リンクを介し、通信回路を用いて信号を送受信するように構成されている。Ｍ２Ｍゲートウェイ１４によって、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）および固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）は、オペレータネットワーク、例えば、通信ネットワーク１２または直接的な無線リンクを介した通信が可能になる。例えば、Ｍ２Ｍデバイス１８は、通信ネットワーク１２または直接的な無線リンクを介し、データを集め、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８に送ることができる。Ｍ２Ｍデバイス１８は、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信することもできる。さらに、後述するように、データおよび信号は、Ｍ２Ｍサービス層２２を介し、Ｍ２Ｍアプリケーション２０へと送られ、Ｍ２Ｍアプリケーション２０から受信されてもよい。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、ジグビー、６ＬｏＷＰＡＮ、ブルートゥース（登録商標））、直接的な無線リンクおよび有線を含む、種々のネットワークを介して通信することができる。例示的なＭ２Ｍデバイスとしては、限定されないが、タブレット、スマートフォン、医療用デバイス、温度および気候モニタ、コネクティッド・カー、スマートメーター、ゲーム機、携帯端末、健康およびフィットネスモニタ、光源、サーモスタット、電化製品、ガレージのドアおよび他のアクチュエータで動作するデバイス、セキュリティデバイスおよびスマートコンセントが挙げられる。

図３２Ｂを参照すると、フィールドドメイン中に示されたＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８および通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、必要に応じた任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８および通信ネットワーク１２と通信してもよいことが理解されるだろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを含み得るネットワークの１つ以上のノードによって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４およびＭ２Ｍアプリケーション２０に適用するサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク中、クラウド中などの種々の様式で実装されてもよい。

図示されているＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン中にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン中のＭ２Ｍアプリケーション２０’および基礎となる通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン中のＭ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８にサービスを提供する。Ｍ２Ｍサービス層２２’が、任意の数のＭ２Ｍアプリケーション、Ｍ２ＭゲートウェイおよびＭ２Ｍデバイスと通信してもよいことが理解されるだろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによって、サービス層とインタラクトしてもよい。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／ストレージファーム）などを含み得るネットワークの１つ以上のノードによって実装されてもよい。

図３２Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用し得るサービス配信能力のコアセットを提供する。これらのサービス能力によって、Ｍ２Ｍアプリケーション２０および２０’は、デバイスとインタラクトし、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見などの機能を行うことができる。本質的に、これらのサービス能力によって、アプリケーションはこれらの機能性を実装する必要がなくなるため、アプリケーションの開発が単純になり、市場に出すまでの費用と時間が節約できる。サービス層２２および２２’によって、Ｍ２Ｍアプリケーション２０および２０’は、サービス層２２および２２’が提供するサービスに関連して、ネットワーク１２などの種々のネットワークを介して通信することができる。

Ｍ２Ｍアプリケーション２０および２０’は、例えば、限定されないが、輸送、ヘルスおよびウェルネス、コネクテッドホーム、エネルギー管理、資産管理、セキュリティおよび監視などの種々の産業におけるアプリケーションを含んでいてもよい。前述したとおり、システムのデバイス、ゲートウェイ、サーバおよび他のノードにわたるＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見およびレガシーシステムインテグレーションなどの機能をサポートし、これらの機能をサービスとして、Ｍ２Ｍアプリケーション２０および２０’に提供する。

一般的に、サービス層（例えば、図３２Ｂに示されるサービス層２２および２２’）は、アプリケーションプログラミングインタフェース（ＡＰＩ）および基礎となるネットワークインターフェースのセットを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは、両方ともサービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノードで実装されてもよい。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス内に実装されてもよく（デバイスＳＣＬ（ＤＳＣＬ）と呼ばれる）、ゲートウェイ内に実装されてもよく（ゲートウェイＳＣＬ（ＧＳＣＬ）と呼ばれる）、および／またはネットワークノード内に実装されてもよい（ネットワークＳＣＬ（ＮＳＣＬ）と呼ばれる）。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）のセット（すなわち、サービス能力）をサポートする。１つ以上の特定の種類のＣＳＦのセットのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と呼ばれ、異なる種類のネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション特有のノード）でホスティングされていてもよい。３ＧＰＰ（Third Generation Partnership Project）は、マシンタイプ通信（Machine-Type Communications：ＭＴＣ）のアーキテクチャも定義している。このアーキテクチャにおいて、サービス層と、サービス層が提供するサービス能力は、サービス能力サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬまたはＮＳＣＬで具現化されようと、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、またはネットワークのいくつかの他のノードで具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他の計算デバイスまたはノードを含む、ネットワーク内の１つ以上のスタンドアロンノードで、または１つ以上の既存のノードの一部としてのいずれかで実行する論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として実装されてもよい。一例として、サービス層のインスタンスまたはそのコンポーネントは、後述する図３２Ｃまたは図３２Ｄに示される一般的なアーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で実行されるソフトウェアの形態で実装されてもよい。

さらに、本明細書に記載する方法および機能性は、サービスにアクセスするためにサービス指向アーキテクチャ（Service Oriented Architecture：ＳＯＡ）および／またはリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されてもよい。

図３２Ｃは、例えば、図１、３－６、８－１２、１５、１６、１８、２０または２２に示されるクライアント、サーバまたはプロキシの１つなど、ネットワークのノードのハードウェア／ソフトウェアアーキテクチャの一例を示すブロック図であり、ノードは、Ｍ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイスまたは他のノード（例えば、図３２Ａおよび３２Ｂに示されるもの）として機能してもよい。図３２Ｃに示すとおり、ノード３０は、プロセッサ３２、ノンリムーバブルメモリ４４、リムーバブルメモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッドおよび／またはインジケータ４２、電源４８、グローバル・ポジショニング・システム（Global Positioning System：ＧＰＳ）チップセット５０および他の周辺機器５２を備えていてもよい。ノード３０は、通信回路、例えば、送受信機３４および送信／受信要素３６も備えていてもよい。ノード３０は、実施形態と一致したままで、前述の要素の任意の部分的な組み合わせを含んでいてもよいことが理解されるだろう。このノードは、例えば、図７、１５、１６、１８、２０、２２および３０について記載された方法、または図１－６、８－１４、１７、１９、２１または２３－２９のデータ構造、または特許請求の範囲に関連して、本明細書に記載の自動ＩｏＴサービス登録を実装するノードであってもよい。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタルシグナルプロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、任意の他の種類の集積回路（Integrated Circuit：ＩＣ）、状態機械などであってもよい。一般的に、プロセッサ３２は、ノードの種々の必要な機能を行うために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）に保存されたコンピュータ実行可能命令を実行してもよい。例えば、プロセッサ３２は、信号の符号化、データ処理、電力制御、入力／出力処理および／またはノード３０が無線環境または有線環境で機能することを可能にする任意の他の機能を行ってもよい。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（Radio Access-Layer：ＲＡＮ）プログラムおよび／または他の通信プログラムを実行してもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層で、認証、セキュリティ鍵合意および／または暗号操作などのセキュリティ操作も行ってもよい。

図３２Ｃに示すとおり、プロセッサ３２は、その通信回路（例えば、送受信機３４および送信／受信要素３６）に接続している。プロセッサ３２は、コンピュータ実行可能命令の実行によって、接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御してもよい。特に、プロセッサ３２は、本明細書（例えば、図７、１５、１６、１８、２０、２２および３０において）および特許請求の範囲に記載する送信工程および受信工程を行うために、通信回路を制御してもよい。図３２Ｃは、プロセッサ３２と送受信機３４を別個のコンポーネントとして示しているが、プロセッサ３２と送受信機３４は、電子パッケージまたはチップに一体化されていてもよいことが理解されるだろう。

送信／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む他のノードに信号を送信するか、またはこれらから信号を受信するように構成されていてもよい。例えば、一実施形態では、送信／受信要素３６は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。送信／受信要素３６は、種々のネットワークおよびエアインターフェース、例えば、ＷＬＡＮ、ＷＰＡＮ、セルラーなどをサポートしてもよい。一実施形態では、送信／受信要素３６は、例えば、ＩＲ光、ＵＶ光または可視光の信号を送信および／または受信するように構成されたエミッタ／検出器であってもよい。さらに別の実施形態では、送信／受信要素３６は、ＲＦ信号および光信号を両方とも送受信するように構成されていてもよい。送信／受信要素３６は、無線信号または有線信号の任意の組み合わせを送信および／または受信するように構成されていてもよいことが理解されるだろう。

これに加えて、送信／受信要素３６は、図３２Ｃでは１つの要素として示されているが、ノード３０は、任意の数の送信／受信要素３６を備えていてもよい。より具体的には、ノード３０は、ＭＩＭＯ技術を使用してもよい。したがって、一実施形態では、ノード３０は、無線信号を送受信するために、２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を備えていてもよい。

送受信機３４は、送信／受信要素３６によって送信される信号を変調し、送信／受信要素３６によって受信される信号を復調するように構成されていてもよい。前述したとおり、ノード３０は、多モード能力を有していてもよい。したがって、送受信機３４は、ノード３０が、複数ＲＡＴ、例えば、ＵＴＲＡおよびＩＥＥＥ ８０２．１１を介して通信できるよう、複数の送受信機を含んでいてもよい。

プロセッサ３２は、例えば、ノンリムーバブルメモリ４４および／またはリムーバブルメモリ４６などの任意の種類の適切なメモリから情報にアクセスし、当該メモリにデータを保存してもよい。例えば、プロセッサ３２は、前述したとおり、そのメモリにセッションコンテキストを保存してもよい。ノンリムーバブルメモリ４４としては、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、リードオンリーメモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他の種類のメモリ記憶デバイスが挙げられる。リムーバブルメモリ４６としては、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュア・デジタル（Secure Digital：ＳＤ）メモリカードなどが挙げられる。他の実施形態では、プロセッサ３２は、ノード３０（例えば、サーバまたはホームコンピュータ）上に物理的に配置されていないメモリから情報にアクセスし、このメモリにデータを保存してもよい。プロセッサ３２は、ノードのステイタスを反映するか、またはノード、特に、ノードと通信する、基礎となるネットワーク、アプリケーション、または他のサービスを構成するために、ディスプレイまたはインジケータ４２上の点灯パターン、画像または色を制御するように構成されていてもよい。一実施形態では、ディスプレイ／インジケータ４２は、図３１に示され、本明細書に記載されるグラフィカルユーザインターフェースを示していてもよい。

プロセッサ３２は、電源４８から電力を受け取ってもよく、ノード３０の他のコンポーネントに対して配電および／または電力制御するような構成であってもよい。電源４８は、ノード３０に電力を供給するのに適した任意のデバイスであってもよい。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケル－カドミウム（ＮｉＣｄ）、ニッケル－亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含んでいてもよい。

プロセッサ３２は、ＧＰＳチップセット５０にも接続していてもよく、ＧＰＳチップセット５０は、ノード３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するような構成である。ノード３０は、実施形態と一致したままで、任意の適切な位置決定方法によって位置情報を取得してもよいことが理解されるだろう。

プロセッサ３２は、さらに、他の周辺機器５２に接続していてもよく、他の周辺機器５２は、さらなる特徴、機能性および／または有線接続または無線接続を提供する１つ以上のソフトウェアおよび／またはハードウェアモジュールを含んでいてもよい。例えば、周辺機器５２としては、種々のセンサ、例えば、加速度計、生体認証（例えば、指紋）センサ、電子コンパス、衛星送受信機、センサ、デジタルカメラ（写真用または映像用）、ユニバーサル・シリアル・バス（Universal Serial Bus：ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デジタルミュージックプレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザなどが挙げられる。

ノード３０は、他の装置またはデバイス、センサ、家電製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療用デバイスまたはｅヘルスデバイス、ロボット、産業機械、ドローン、自動車、トラック、電車または航空機などの車両で具現化されてもよい。ノード３０は、１つ以上の相互接続インターフェース（例えば、周辺機器５２の１つを含んでいてもよい相互接続インターフェース）を介し、かかる装置またはデバイスの他のコンポーネント、モジュールまたはシステムに接続していてもよい。

図３２Ｄは、図１、３－６、８－１２、１５、１６、１８、２０または２２に示され、本明細書に記載されるクライアント、サーバまたはプロキシなどのネットワークの１つ以上のノードを実装するために使用される計算システム９０の一例を示すブロック図であり、ノードは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または図３２Ａおよび３２Ｂに示すＭ２Ｍネットワーク内の他のノードなどとして機能してもよい。

計算システム９０は、コンピュータまたはサーバを備えていてもよく、主にソフトウェアなどとしてのコンピュータ可読命令によって制御されてもよく、ソフトウェアの保存場所またはアクセス方法は問わない。かかるコンピュータ可読命令は、プロセッサ、例えば、中央処理装置（Central Processing Unit：ＣＰＵ）９１内で実行され、計算システム９０に処理を実行させてもよい。多くの既知のワークステーション、サーバおよびパーソナルコンピュータにおいて、中央処理装置９１は、マイクロプロセッサと呼ばれるシングルチップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを含んでいてもよい。コプロセッサ８１は、メインＣＰＵ９１と違って任意のプロセッサであり、追加の機能を実行またはＣＰＵ９１を補助する。ＣＰＵ９１および／またはコプロセッサ８１は、開示されるシステムおよびセッションクレデンシャルの受信やセッションクレデンシャルに基づく認証などＥ２Ｅ Ｍ２Ｍサービス層セッションの方法に関連するデータを受信し、作成し、処理してもよい。

操作中、ＣＰＵ９１は、命令を取り出し、解読し、実行し、コンピュータの主なデータ伝送経路であるシステムバス８０を介し、他のリソースへと、また他のリソースから情報を伝送する。かかるシステムバスは、計算システム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送るためのデータラインと、アドレスを送るためのアドレスラインと、割り込みを送り、システムバスを操作するためのコントロールラインとを備えている。かかるシステムバス８０の一例は、ペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスである。

システムバス８０に接続するメモリとしては、ランダムアクセスメモリ（ＲＡＭ）８２およびリードオンリーメモリ（ＲＯＭ）９３が挙げられる。かかるメモリは、情報の保存および検索を可能にする回路を含む。ＲＯＭ９３は、一般的に、容易に修正することができない保存データを含む。ＲＡＭ８２に保存されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、または変更されてもよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行されると、バーチャルアドレスを物理アドレスに変換するアドレス変換機能を提供してもよい。メモリコントローラ９２は、システム内でプロセスを隔離し、システムプロセスをユーザプロセスから隔離するメモリ保護機能も提供してもよい。したがって、第１モードで実行されるプログラムは、その自身のプロセスバーチャルアドレス空間によってマッピングされたメモリにのみアクセスすることが可能であり、プロセス間でメモリの共有が設定されていない限り、別のプロセスのバーチャルアドレス空間内のメモリにアクセスすることはできない。

これに加えて、計算システム９０は、ＣＰＵ９１から周辺機器（例えば、プリンタ９４、キーボード８４、マウス９５およびディスクドライブ８５）への命令を伝える役割を担う周辺機器コントローラ８３を備えていてもよい。

ディスプレイ８６は、ディスプレイコントローラ９６によって制御されており、計算システム９０によって作成された視覚的出力を表示するために使用される。かかる視覚的出力としては、テキスト、グラフィック、動画グラフィックおよび映像が挙げられる。ディスプレイ８６は、ＣＲＴ型ビデオディスプレイ、ＬＣＤ型フラットパネルディスプレイ、気体プラズマ型フラットパネルディスプレイまたはタッチパネルで実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送られる動画信号を作成するために必要な電子コンポーネントを備えている。ディスプレイ８６は、ＣＰＵ９１によって実行されるコンピュータ実行可能命令と組み合わせて、図２５に示されその付随する説明に記載されるグラフィカルユーザインターフェースを作成し、操作してもよい。

さらに、計算システム９０は、通信回路（例えば、ネットワークアダプタ９７）を含んでいてもよく、この通信回路を使用し、計算システム９０を外部通信ネットワーク（例えば、図３２Ａ－Ｄのネットワーク１２）に接続し、計算システム９０がネットワークの他の装置と通信することを可能にしてもよい。通信回路は、単独で、またはＣＰＵ９１と組み合わせて使用され、本明細書（例えば、図１、３、５－８、１１－１５、２０－２１、２４または２５）および特許請求の範囲に記載の送信工程および受信工程を行ってもよい。

本明細書に記載するシステム、方法およびプロセスのいずれかまたは全部は、コンピュータ可読媒体に保存されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で実装されてもよく、命令は、機械（例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む、Ｍ２Ｍネットワークの装置）によって実行されると、本明細書に記載のシステム、方法およびプロセスを実行および／または実装することが理解される。具体的には、上述の工程、操作または機能のいずれも、かかるコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読媒体としては、情報の保存のために任意の一時的でない（すなわち、実体がある、または物理的な）方法または技術で実装された揮発性および不揮発性のリムーバブルメディアおよびノンリムーバブルメディアの両方が挙げられるが、かかるコンピュータ可読媒体は、信号を含まない。コンピュータ可読記憶媒体としては、限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル・バーサタイル・ディスク（Digital Versatile Disk：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、または所望な情報を保存するために使用可能であり、コンピュータによってアクセス可能な任意の他の実体がある、または物理的な媒体が挙げられる。

以下は、上述の記載で現れ得るサービスレベル技術に関連する頭字語のリストである。特に明記していない限り、本明細書で使用される頭字語は、以下に列挙した対応する用語を指す。

この明細書は、ベストモードを含む本発明を開示するため、また、任意のデバイスまたはシステムを製造して使用し、任意の組み合わせられた方法を行うことを含む本発明を当業者が実施することを可能にするため、例を用いている。本発明の特許可能な範囲は、特許請求の範囲によって定義され、当業者が思い付く他の例を含んでいてもよい。かかる他の例は、特許請求の範囲の文字どおりの言葉と異ならない要素を有する場合、または特許請求の範囲の文字どおりの言葉とごくわずかに異なる等価な要素を含む場合には、特許請求の範囲内であることが意図される。

Claims (20)

1. プロセッサと、メモリと、を備える装置であって、前記装置は、通信ネットワークに接続され、前記装置は、さらに、前記装置の前記メモリに保存されたコンピュータ実行可能命令を含み、前記コンピュータ実行可能命令は、前記装置の前記プロセッサによって実行されると、前記装置に、前記通信ネットワーク上のサービス層エンティティを実装させ、前記サービス層エンティティに、
   前記通信ネットワークに接続可能な複数のネットワークデバイスのサービス加入者に関する情報と、前記複数のネットワークデバイスのそれぞれに関する情報であって、前記ネットワークデバイスの関連識別子と、前記ネットワークデバイス上でホストされる１つ以上のアプリケーションそれぞれの識別子と、１つ以上の許可されたデータ型を含む前記１つ以上のアプリケーションそれぞれについての関連データコントロールポリシーとを少なくとも含むそれぞれのネットワークデバイスに関する情報を含む電子プロファイルを受信させ、
   前記サービス層エンティティの前記メモリにおいて、１つ以上のリソースを作成させ、前記１つ以上のリソース内に、前記サービス加入者に関し、前記複数のネットワークデバイスそれぞれに関する前記電子プロファイルに含まれる情報であって、それぞれのネットワークデバイス上でホストされる前記１つ以上のアプリケーションそれぞれの関連識別子と、それぞれのネットワークデバイス上でホストされる前記１つ以上のアプリケーションそれぞれの関連データコントロールポリシーとを含む情報を保存させ、
   前記通信ネットワークに接続したネットワークデバイス上でホストされるアプリケーションから、当該アプリケーションを前記サービス層エンティティに利用登録するよう求める電子リクエストであって、リクエストするアプリケーションが前記通信ネットワーク上で送信するように構成される第１識別子と第１データ型のデータとを含むリクエストを受信させ、
   前記１つ以上のリソースに基づき、前記リクエストするアプリケーションの前記第１識別子と前記電子プロファイル中の前記複数のアプリケーションの１つの関連識別子とが一致すると決定させ、
   前記１つ以上のリソースに基づき、前記リクエストするアプリケーションの前記第１データ型と、前記電子プロファイル中で一致する識別子を有するアプリケーションの関連データコントロールポリシーの許可されたデータ型の１つとが一致すると決定させ、
   前記決定に基づき、前記リクエストするアプリケーションを前記サービス層エンティティに利用登録させる、
   ことを特徴とする装置。
2. 前記命令によって、さらに、前記サービス層エンティティに、
   前記リクエストするアプリケーションが第２データ型を作成すると決定させ、
   前記第２データ型が、前記電子プロファイル中の一致する識別子を有するアプリケーションの関連データコントロールポリシーの許可されたデータ型の１つ以上と一致しないと決定させ、
   前記リクエストするアプリケーションを利用登録させない、
   請求項１に記載の装置。
3. 前記電子プロファイルは、１人以上の認証ユーザ、１つ以上の選択されたサービス登録選択項目、１つ以上の特定のアクセス権限、および１つ以上のサービス登録有効期間のうち少なくとも１つをさらに含む、
   請求項１に記載の装置。
4. 前記１つ以上の許可されたデータ型のうちの１つの許可されたデータ型は、１つ以上のサポートされたリソース型、１つ以上のサポートされたスキーマ型、データのインスタンスの最大数、データの最大バイト数のうち少なくとも１つを含む、
   請求項１に記載の装置。
5. 前記命令によって、さらに、前記サービス層エンティティに、
   前記リクエストするアプリケーションがホストされるデバイスの識別子を決定させ、
   前記デバイスの識別子と、前記電子プロファイル中の前記アプリケーションに関連する１つ以上の許可されたデバイス識別子とが一致しないと決定させ、
   前記リクエストするアプリケーションを利用登録させない、
   請求項１に記載の装置。
6. 前記命令によって、さらに、前記サービス層エンティティに、
   前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成させ、
   前記アクセスコントロールポリシーを、前記利用登録されたアプリケーションによって作成されたリソースにリンクさせ、
   これらのアクセスコントロールポリシー中で定義される前記権限に基づき、これらのリソースにアクセスすることが許可される複数のアプリケーションを決定させる、
   請求項１に記載の装置。
7. 前記命令によって、さらに、前記サービス層エンティティに、
   前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成させ、
   前記アクセスコントロールポリシーを、前記利用登録されたアプリケーションによって作成されたリソースにリンクさせ、
   これらのアクセスコントロールポリシー中で定義される前記権限に基づき、これらのリソースにアクセスすることが許可される複数のユーザを決定させる、
   請求項１に記載の装置。
8. 前記命令によって、さらに、前記サービス層エンティティに、
   前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成させ、
   前記データコントロールポリシーを、前記利用登録されたアプリケーションによって作成された１つ以上のリソースにリンクさせ、
   これらのデータコントロールポリシーに基づき、子リソースのインスタンスの最大数、またはリソース中に保存されることが許可される最大バイト数のうち少なくとも１つを決定させる、
   請求項１に記載の装置。
9. 前記命令によって、さらに、前記サービス層エンティティに、
   前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成させ、
   前記データコントロールポリシーを、前記利用登録されたアプリケーションによって作成された１つ以上のリソースにリンクさせ、
   これらのデータコントロールポリシーに基づき、リソースに保存されることが許可される１つ以上のデータスキーマを決定させる、
   請求項１に記載の装置。
10. 前記電子プロファイルが、前記通信ネットワーク内の登録機能から受信される、
    請求項１に記載の装置。
11. 通信ネットワークのサービス層エンティティによって行われる方法であって、
    前記通信ネットワークに接続可能な複数のネットワークデバイスのサービス加入者に関する情報と、前記複数のネットワークデバイスのそれぞれに関する情報であって、前記ネットワークデバイスの関連識別子と、前記ネットワークデバイス上でホストされる１つ以上のアプリケーションそれぞれの識別子と、１つ以上の許可されたデータ型を含む前記１つ以上のアプリケーションそれぞれについての関連データコントロールポリシーとを少なくとも含むそれぞれのネットワークデバイスに関する情報を含む電子プロファイルを受信する工程と、
    前記サービス層エンティティのメモリにおいて、１つ以上のリソースを作成し、前記１つ以上のリソース内に、前記サービス加入者に関し、前記複数のネットワークデバイスそれぞれに関する前記電子プロファイルに含まれる情報であって、それぞれのネットワークデバイス上でホスとされる前記１つ以上のアプリケーションそれぞれの関連識別子と、それぞれのネットワークデバイス上でホストされる前記１つ以上のアプリケーションそれぞれの関連データコントロールポリシーとを含む情報を保存する工程と、
    前記通信ネットワークに接続したネットワークデバイス上でホストされるアプリケーションから、当該アプリケーションを前記サービス層エンティティに利用登録するよう求める電子リクエストであって、リクエストするアプリケーションが前記通信ネットワーク上で送信するように構成される第１識別子と第１データ型のデータとを含むリクエストを受信する工程と、
    前記１つ以上のリソースに基づき、前記リクエストするアプリケーションの前記第１識別子と前記電子プロファイル中の前記複数のアプリケーションの１つの関連識別子とが一致すると決定する工程と、
    前記１つ以上のリソースに基づき、前記リクエストするアプリケーションの前記第１データ型と、前記電子プロファイル中で一致する識別子を有するアプリケーションの関連データコントロールポリシーの許可されたデータ型の１つとが一致すると決定することと、
    前記決定に基づき、前記リクエストするアプリケーションを前記サービス層エンティティに利用登録する工程とを含む、
    ことを特徴とする方法。
12. 前記リクエストするアプリケーションが第２データ型を作成すると決定する工程と、
    前記第２データ型が、前記電子プロファイル中の一致する識別子を有するアプリケーションの関連データコントロールポリシーの許可されたデータ型の１つ以上と一致しないと決定する工程と、
    前記リクエストするアプリケーションを利用登録させない工程と、を含む、
    請求項１１に記載の方法。
13. 前記電子プロファイルは、１人以上の認証ユーザ、１つ以上の選択されたサービス登録選択項目、１つ以上の特定のアクセス権限、および１つ以上のサービス登録有効期間のうち少なくとも１つをさらに含む、
    請求項１１に記載の方法。
14. 前記１つ以上の許可されたデータ型のうちの１つの許可されたデータ型は、１つ以上のサポートされたリソース型、１つ以上のサポートされたスキーマ型、データのインスタンスの最大数、データの最大バイト数のうち少なくとも１つを含む、
    請求項１１に記載の方法。
15. 前記リクエストするアプリケーションがホストされるデバイスの識別子を決定する工程と、
    前記デバイスの識別子と、前記電子プロファイル中の前記アプリケーションに関連する１つ以上の許可されたデバイス識別子とが一致しないと決定する工程と、
    前記リクエストするアプリケーションを利用登録させない工程と、を含む、
    請求項１１に記載の方法。
16. 前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成する工程と、
    前記アクセスコントロールポリシーを、前記利用登録されたアプリケーションによって作成されたリソースにリンクする工程と、
    これらのアクセスコントロールポリシー中で定義される前記権限に基づき、これらのリソースにアクセスすることが許可される複数のアプリケーションを決定する工程と、を含む、
    請求項１１に記載の方法。
17. 前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成する工程と、
    前記アクセスコントロールポリシーを、前記利用登録されたアプリケーションによって作成されたリソースにリンクする工程と、
    これらのアクセスコントロールポリシー中で定義される前記権限に基づき、これらのリソースにアクセスすることが許可される複数のユーザを決定する工程と、を含む、
    請求項１１に記載の方法。
18. 前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成する工程と、
    前記データコントロールポリシーを、前記利用登録されたアプリケーションによって作成された１つ以上のリソースにリンクする工程と、
    これらのデータコントロールポリシーに基づき、子リソースのインスタンスの最大数、またはリソース中に保存されることが許可される最大バイト数のうち少なくとも１つを決定する工程と、を含む、
    請求項１１に記載の方法。
19. 前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成する工程と、
    前記データコントロールポリシーを、前記利用登録されたアプリケーションによって作成された１つ以上のリソースにリンクする工程と、
    これらのデータコントロールポリシーに基づき、リソースに保存されることが許可される１つ以上のデータスキーマを決定する工程と、を含む、
    請求項１１に記載の方法。
20. 前記電子プロファイルが、前記通信ネットワーク内の登録機能から受信される、
    請求項１１に記載の方法。

Images