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

Description

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

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

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

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

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

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

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

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

図１は、ＩｏＴサービス登録者の関係の階層を示す図である。 図２は、アプリケーションプロトコルとアプリケーションとの間にサービス層を有するプロトコルスタックの一例を示す図である。 図３は、Ｍ２Ｍ／ＩｏＴ配置の一例を示す図である。 図４は、ｏｎｅＭ２Ｍサービス層アーキテクチャの一例を示す図である。 図５は、ｏｎｅＭ２Ｍによって現時点で定義されているＣＳＦを示す図である。 図６は、ｏｎｅＭ２Ｍによってサポートされる構成例を示す図である。 図７は、ＩｏＴサービス登録を自動化するためのプロセスの一例を示すフロー図である。 図８は、自動ＩｏＴサービス登録アーキテクチャの配置の一例を示す図である。 図９は、自動ＩｏＴサービス登録アーキテクチャの配置の別の例を示す図である。 図１０は、自動ＩｏＴサービス登録クライアントの一例を示す図である。 図１１は、自動ＩｏＴサービス登録サーバの一例を示す図である。 図１２は、ｏｎｅＭ２Ｍサービス加入者登録アーキテクチャの一実施形態例を示す図である。 図１３は、ｏｎｅＭ２Ｍリソース属性の一例を示す図である。 図１４は、新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図１５は、ｏｎｅＭ２Ｍサービス登録オプションを公開する一例のシーケンス図である。 図１６は、ｏｎｅＭ２Ｍサービス登録オプションを発見する一例のシーケンス図である。 図１７は、サービス加入者クレデンシャルを管理するサービスプロバイダＡＰＩの一例を示す図である。 図１８は、サービス加入者クレデンシャルを作成する一例のシーケンス図である。 図１９は、ｏｎｅＭ２Ｍサービス加入者クレデンシャルブートストラップＡＰＩの一実施形態例を示す図である。 図２０は、クレデンシャルをブートストラップする一例のシーケンス図である。 図２１は、ｏｎｅＭ２Ｍサービス加入者登録情報リソースの一実施形態例を示す図である。 図２２は、サービス加入者がサービスプロバイダに登録する一例のシーケンス図である。 図２３は、新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２４は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２５は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２６は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２７は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２８は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図２９は、別の新規なｏｎｅＭ２Ｍリソースの一実施形態例を示す図である。 図３０は、被仮想化サービス加入者の少なくとも１つのデバイスをサービス層エンティティに登録（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 S
ervice 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：ＦＤＭＡ）、直交ＦＤＭＡ（Ort
hogonal 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 Arr
ay：ＦＰＧＡ）回路、任意の他の種類の集積回路（Integrated Circuit：ＩＣ）、状態
機械などであってもよい。一般的に、プロセッサ３２は、ノードの種々の必要な機能を行
うために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）に保存され
たコンピュータ実行可能命令を実行してもよい。例えば、プロセッサ３２は、信号の符号
化、データ処理、電力制御、入力／出力処理および／またはノード３０が無線環境または
有線環境で機能することを可能にする任意の他の機能を行ってもよい。プロセッサ３２は
、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（
Radio Access-Layer：ＲＡＮ）プログラムおよび／または他の通信プログラムを実行し
てもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層で
、認証、セキュリティ鍵合意および／または暗号操作などのセキュリティ操作も行っても
よい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. プロセッサと、メモリと、を備える装置であって、前記装置は、さらに、前記装置の前記メモリに保存されたコンピュータ実行可能命令を含み、前記コンピュータ実行可能命令は、前記装置の前記プロセッサによって実行されると、前記装置に、アプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）および基礎となるネットワークインターフェースのセットを介してサービス能力をサポートするサービスを通信ネットワークにおいて提供させ、前記サービスに、
   前記通信ネットワークに接続され得る１つ以上のネットワークデバイスに関する情報と、前記１つ以上のネットワークデバイスのそれぞれに関する情報であって、前記１つ以上のネットワークデバイスのそれぞれの関連識別子と、前記１つ以上のネットワークデバイスのそれぞれが前記サービスの１つ以上のデータ保存リソース内に保存することが許可されたデータのスキーマ定義を含む前記１つ以上のネットワークデバイスのそれぞれについての関連データコントロールポリシーとを少なくとも含む前記１つ以上のネットワークデバイスのそれぞれに関する情報を含む電子プロファイルを受信させ、
   前記サービスのメモリにおいて、１つ以上のリソースを作成させ、前記１つ以上のリソース内に、前記１つ以上のネットワークデバイスのそれぞれに関する前記電子プロファイルに含まれる情報であって、前記１つ以上のネットワークデバイスのそれぞれの関連識別子と、前記１つ以上のネットワークデバイスのそれぞれの関連データコントロールポリシーとを含む情報を保存させ、
   前記通信ネットワークに接続したネットワークデバイスから、前記サービスの１つ以上のデータリソースで操作を実行するよう求める電子リクエストであって、リクエストするデバイスの第１識別子と該リクエストするデバイスが操作を実行することを求める１つ以上のデータリソースとを含むリクエストを受信させ、
   前記保存された電子プロファイルに基づき、前記リクエストするデバイスの前記第１識別子と前記電子プロファイル中の前記１つ以上のネットワークデバイスのうちの１つのネットワークデバイスの関連識別子とが一致すると決定させ、
   前記リクエストするデバイスの前記第１識別子が前記電子プロファイル中の前記１つ以上のネットワークデバイスのうちの１つのネットワークデバイスの関連識別子と一致し、前記リクエストに含まれるデータの種類が前記１つ以上のネットワークデバイスのうちの前記１つのネットワークデバイスの関連データコントロールポリシーのスキーマと一致すると決定させ、当該決定に基づいて前記データリソース内に前記データを保存させる、
   ことを特徴とする装置。
2. 前記関連データコントロールポリシーは、デバイスが１つ以上のデータ保存リソースに構成可能な最長寿命の限度をさらに含む、
   請求項１に記載の装置。
3. 前記電子プロファイルは、１人以上の認証ユーザ、１つ以上の選択されたサービス登録選択項目、１つ以上の特定のアクセス権限、および１つ以上のサービス登録有効期間のうち少なくとも１つをさらに含む、
   請求項１に記載の装置。
4. 前記コンピュータ実行可能命令によって、さらに、前記サービスに、
   前記リクエストするデバイスの前記第１識別子を決定させ、
   前記リクエストするデバイスに前記操作を実行させない、
   請求項１に記載の装置。
5. 前記コンピュータ実行可能命令によって、さらに、前記サービスに、
   前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成させ、
   前記アクセスコントロールポリシーを、前記デバイスによって作成されたリソースにリンクさせ、
   これらのアクセスコントロールポリシー中で定義される前記１つ以上のアクセスコントロール権限に基づき、これらのリソースにアクセスすることが許可される複数のデバイスを決定させる、
   請求項１に記載の装置。
6. 前記コンピュータ実行可能命令によって、さらに、前記サービスに、
   前記電子プロファイル中で定義される１つ以上のアクセスコントロール権限に基づき、１つ以上のアクセスコントロールポリシーを作成させ、
   前記アクセスコントロールポリシーを、前記デバイスによって作成されたリソースにリンクさせ、
   これらのアクセスコントロールポリシー中で定義される前記１つ以上のアクセスコントロール権限に基づき、これらのリソースにアクセスすることが許可される複数のユーザを決定させる、
   請求項１に記載の装置。
7. 前記コンピュータ実行可能命令によって、さらに、前記サービスに、
   前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成させ、
   前記データコントロールポリシーを、前記デバイスによって作成された１つ以上のリソースにリンクさせ、
   これらのデータコントロールポリシーに基づき、リクエストの最大頻度、子リソースのインスタンスの最大数、またはリソース中に保存されることが許可される最大バイト数のうち少なくとも１つを決定させる、
   請求項１に記載の装置。
8. 前記コンピュータ実行可能命令によって、さらに、前記サービスに、
   前記電子プロファイル中で定義される１つ以上のデータコントロール権限に基づき、１つ以上のデータコントロールポリシーを作成させ、
   前記データコントロールポリシーを、前記デバイスによって作成された１つ以上のリソースにリンクさせ、
   これらのデータコントロールポリシーに基づき、リソースに保存されることが許可される１つ以上のデータスキーマを決定させる、
   請求項１に記載の装置。
9. 前記電子プロファイルが、前記通信ネットワーク内の登録機能から受信される、請求項１に記載の装置。
10. 前記サービスはＩｏＴサービスのためのサービス層に含まれる、請求項１に記載の装置。
11. 前記サービス層は、ＥＴＳＩ／ｏｎｅＭ２Ｍ規格に基づいて定義される、請求項１０に記載の装置。
12. 前記１つ以上のリソースそれぞれは、ＲＥＳＴｆｕｌ法によって操作可能な表現を有するリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）における一意にアドレス可能な要素である、
    請求項１に記載の装置。
13. 通信ネットワークのサービスを提供するコンピュータが実行する方法であって、
    前記通信ネットワークに接続され得る１つ以上のネットワークデバイスに関する情報と、前記１つ以上のネットワークデバイスのそれぞれに関する情報であって、前記１つ以上のネットワークデバイスのそれぞれの関連識別子と、前記１つ以上のネットワークデバイスのそれぞれが前記サービスの１つ以上のデータ保存リソース内に保存することが許可されたデータのスキーマ定義を含む前記１つ以上のネットワークデバイスのそれぞれについての関連データコントロールポリシーとを少なくとも含む前記１つ以上のネットワークデバイスのそれぞれに関する情報を含む電子プロファイルを受信する工程と、
    前記サービスのメモリにおいて、１つ以上のリソースを作成し、前記１つ以上のリソース内に、前記１つ以上のネットワークデバイスのそれぞれに関する前記電子プロファイルに含まれる情報であって、前記１つ以上のネットワークデバイスのそれぞれの関連識別子と、前記１つ以上のネットワークデバイスのそれぞれの関連データコントロールポリシーとを含む情報を保存する工程と、
    前記通信ネットワークに接続したネットワークデバイスから、前記サービスの１つ以上のデータリソースで操作を実行するよう求める電子リクエストであって、リクエストするデバイスの第１識別子と該リクエストするデバイスが操作を実行することを求める１つ以上のデータリソースとを含むリクエストを受信する工程と、
    前記保存された電子プロファイルに基づき、前記リクエストするデバイスの前記第１識別子と前記電子プロファイル中の前記１つ以上のネットワークデバイスのうちの１つのネットワークデバイスの関連識別子とが一致すると決定する工程と、
    前記リクエストするデバイスの前記第１識別子が前記電子プロファイル中の前記１つ以上のネットワークデバイスのうちの１つのネットワークデバイスの関連識別子と一致し、前記リクエストに含まれるデータの種類が前記１つ以上のネットワークデバイスのうちの前記１つのネットワークデバイスの関連データコントロールポリシーのスキーマと一致すると決定し、当該決定に基づいて前記データリソース内に前記データを保存する工程とを含む、
    ことを特徴とする方法。
14. 前記関連データコントロールポリシーは、デバイスが１つ以上のデータ保存リソースに構成可能な最長寿命の限度をさらに含む、
    請求項１３に記載の方法。
15. 前記電子プロファイルは、１人以上の認証ユーザ、１つ以上の選択されたサービス登録選択項目、１つ以上の特定のアクセス権限、および１つ以上のサービス登録有効期間のうち少なくとも１つをさらに含む、
    請求項１３に記載の方法。
16. 前記リクエストするデバイスの前記第１識別子を決定する工程と、
    前記リクエストするデバイスに前記操作を実行させない工程と、をさらに含む、
    請求項１３に記載の方法。
17. 前記電子プロファイルが、前記通信ネットワーク内の登録機能から受信される、請求項１３に記載の方法。
18. 前記サービスはＩｏＴサービスのためのサービス層に含まれる、請求項１３に記載の方法。
19. 前記サービス層は、ＥＴＳＩ／ｏｎｅＭ２Ｍ規格に基づいて定義される、請求項１８に記載の方法。
20. 前記１つ以上のリソースそれぞれは、ＲＥＳＴｆｕｌ法によって操作可能な表現を有するリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）における一意にアドレス可能な要素である、
    請求項１３に記載の方法。

Images