JP7194736B2 - ＩｏＴ／Ｍ２Ｍサービス層のデータまたはサービスに対するコンテキストアウェア認証 - Google Patents

Description

関連出願の相互参照
本出願は、２０１７年１２月１８日に出願の米国特許仮出願番号第６２／６０７，００６号の利益を請求し、その全体が参照として本明細書に組み込まれる。

Ｍ２Ｍ／ＩｏＴサービス層は、特に、Ｍ２Ｍ／ＩｏＴデバイスおよびＭ２Ｍ／ＩｏＴアプリケーション向けに付加価値サービスを提供することを目的とする技術である。近年、いくつかの業界規格団体（例えば、ｏｎｅＭ２Ｍ、ＥＴＳＩ、ＯＣＦおよびＬＷＭ２Ｍ）は、インターネット／ウェブ、セルラー、企業ネットワーク、およびホームネットワークを伴う展開へのＭ２Ｍ／ＩｏＴデバイスおよびアプリケーションの統合に関連する課題に対処するＭ２Ｍ／ＩｏＴサービス層を開発している。

Ｍ２Ｍ／ＩｏＴサービス層により、アプリケーションおよびデバイスは、Ｍ２Ｍ／ＩｏＴ指向能力の集合体へアクセスできる。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続管理が挙げられる。これらの能力は、ＡＰＩを介して、アプリケーションに提供される場合があり、このＡＰＩは、Ｍ２Ｍ／ＩｏＴサービス層によってサポートされるメッセージフォーマット、リソース構造、およびリソース表現を利用する。

動的コンテキストアウェア認証のために、ＩｏＴ／Ｍ２Ｍサービス層がサービス層の登録者に提供することができる認証検証サービス（Authorization Verification Service：ＡＶＳ）について開示する。ＡＶＳは、サービスまたはデータへのアクセスを認可する場合の動的な制限を、ＩｏＴ／Ｍ２Ｍサービス層エンティティが定義できるようにすることができる。制限は、例えば、許可されるアクセス数を基準にして設定されてよい。ＩｏＴ／Ｍ２Ｍ登録者が、動的コンテキストアウェア認可をそれらに対して有しているデータまたはサービスをリクエストした場合、ＡＶＳは、残りの利用可能なアクセスの記録を保持していてもよい。要求元は、任意のＩｏＴ／Ｍ２Ｍサービス層登録者またはＩｏＴ／Ｍ２Ｍサービス層登録者向けのプロキシであってもよい。

例示的機能性、すなわち、既存の認証ポリシーの範囲内にある新しいデータおよびサービスに対する認証ポリシーを動的に適用することと、ＩｏＴ／Ｍ２Ｍサービス層登録者がＩｏＴ／Ｍ２Ｍサービス層に動的コンテキストアウェア認可期限を組み込むことを可能にすることと、これらの動的コンテキストアウェア認可期限に基づいてデータおよびサービスへのアクセスをＩｏＴ／Ｍ２Ｍサービス層によって管理することと、動的コンテキストアウェア認可期限の状態をＩｏＴ／Ｍ２Ｍサービス層によって更新することと、動的コンテキストアウェア認可期限の制限または条件が使い果たされると、アクセス権を無効にすることとが、提案されるＡＶＳによってサポートされ得る。しかし、ＡＶＳは、上述のこれらの機能性に限定されないものと理解される。

本明細書で記載される方法およびシステムを使用することによって、ＩｏＴ／Ｍ２Ｍセンサまたはアプリケーションが、ＩｏＴ／Ｍ２Ｍサービス層のデータおよびサービスにアクセスする認可を出す動的コンテキストアウェア認証ポリシーに、追加の特徴および能力を組み込むことが可能である。ポリシーを他のデータおよびサービスにどう適用することができるか、特定の操作を認可するときに、追加のシステムコンテキストをどのように考慮に入れることができるか、ならびに、デバイスまたはエンティティの考えられる動作および特性が、ＩｏＴ／Ｍ２Ｍサービス層によってどのように表現でき、かつ施行できるかを記述している規則が存在する場合がある。これらの発想により、より簡単な展開、より効果的な操作、よりセキュアな操作、およびより信頼性のある操作をもたらすことが可能である。

本願のより確固たる理解を促進するために、参照番号が添付の図面に記載されるが、この各図面において、同じ要素は同じ番号を用いて参照される。これらの図面は、本願を限定するものと解釈されるべきではなく、単に例証を意図したものである。

図１は、サービス層をサポートしている例示的プロトコルスタックを示す図である。 図２は、様々なタイプのネットワークノードに展開される例示的Ｍ２Ｍ／ＩｏＴサービス層を示す図である。 図３は、例示的ｏｎｅＭ２Ｍアーキテクチャを示す図である。 図４は、例示的ｏｎｅＭ２Ｍ共通サービス機能を示す図である。 図５は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる例示的構成を示す図である。 図６は、ｏｎｅＭ２Ｍ動的認証の例示的フロー図である。 図７は、ｏｎｅＭ２Ｍ分散型認証プロシージャの例示的フロー図である。 図８は、例示的ユースケースの現在のソリューションを示す図である。 図９は、認証検証サービスの一例を示す図である。 図１０は、認可範囲の例示的フロー図である。 図１１は、認可状態管理の例示的フロー図である。 図１２Ａは、１つまたは複数の開示する実施形態がその中で実装される可能性のある、例示的マシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）またはモノのインターネット（Internet of Things：ＩｏＴ）通信システムの系統図である。 図１２Ｂは、図１２Ａに示されているＭ２Ｍ／ＩｏＴ通信システム内で使用される可能性のある、例示的アーキテクチャの例示的系統図である。 図１２Ｃは、図１２Ａに示されている通信システム内で使用される可能性がある、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの例示的系統図である。 図１２Ｄは、図１２Ａの通信システムの態様がその中で具現化される可能性のある、例示的コンピュータシステムの例示的ブロック図である。

ＩｏＴ／Ｍ２Ｍサービス層アーキテクチャは、通信ネットワーク上のセンサまたは他のアプリケーションからのデータにアプリケーションがアクセスできるようにする付加価値的な特徴およびソリューションに焦点が当てられたものである。既存のサービス層は、例えば、要求元の位置が固定位置の１０メートル圏内の中にあることを必要とするコンテキストベースの認証を提供する場合がある。本明細書で記載される方法およびシステムは、システムの条件に基づいて認証コンテキストが動的に変更されることに対処できる。

プロトコルスタックの観点から、サービス層は典型的には、アプリケーションプロトコル層の上位に位置し、かつサポートしているアプリケーションに付加価値サービスを提供する。それゆえサービス層は、「ミドルウェア」サービスとして分類されることが多い。図１は、アプリケーションプロトコルとアプリケーションとの間に位置する例示的サービス層を示す。展開の観点から、Ｍ２Ｍ／ＩｏＴサービス層は、図２に示すようなサーバ、ゲートウェイ、およびデバイスなどの様々なタイプのネットワークノードで展開される場合がある。

ｏｎｅＭ２Ｍ規格は、Ｍ２Ｍ／ＩｏＴサービス層を規定している（ｏｎｅＭ２Ｍの、TS-0001 oneM2M Functional Architecture-V-3.6.0参照）。サービス層の目的は、ｅ－ヘルス、フリート管理、およびスマートホームなどの様々な「バーティカル」Ｍ２Ｍシステムおよびアプリケーションが利用することができる「ホリゾンタル」サービスを提供することである。ｏｎｅＭ２Ｍサービス層のアーキテクチャは、図３に示すように、４つの参照点をサポートする共通サービスエンティティ（Common Service Entity：ＣＳＥ）を画定する。Ｍｃａ参照点は、アプリケーションエンティティ（Application Entity：ＡＥ）とのインターフェースをとる場合があり、Ｍｃｃ参照点は、同じサービスプロバイダドメイン内の別のＣＳＥとのインターフェースをとる場合があり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとのインターフェースをとる場合があり、およびＭｃｎ参照点は、下位ネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とのインターフェースをとる場合がある。ＮＳＥは、デバイス管理、位置サービス、およびデバイストリガなどの下位ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、および「データ管理およびリポジトリ」などの共通サービス機能（Common Service Functions：ＣＳＦ）、と呼ばれる複数の論理機能を含む。図４は、ｏｎｅＭ２ＭによってサポートされるＣＳＦの例を示す。

ｏｎｅＭ２Ｍアーキテクチャは、分散型アーキテクチャであり、以下の例示的なタイプのノード全体にわたって分散して展開するＭ２Ｍ／ＩｏＴサービスをサポートする。

アプリケーションサービスノード（Application Service Node：ＡＳＮ）は、１つのＣＳＥを含み、かつ少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。一例では、ＡＳＮは、Ｍ２Ｍデバイス内に常駐する場合がある。

アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）は、少なくとも１つのＡＥを含むが、ＣＳＥは含まないノードである。一例では、アプリケーション専用ノードは、制限のあるＭ２Ｍデバイス内に常駐する場合がある。

中間ノード（Middle Node：ＭＮ）は、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。例えば、ＭＮは、Ｍ２Ｍゲートウェイに常駐する場合がある。

インフラストラクチャノード（Infrastructure Node：ＩＮ）は、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。ＩＮ内のＣＳＥは、他のノードタイプには適用されないＣＳＥ機能を含む場合がある。一例では、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ内に常駐する場合がある。

非ｏｎｅＭ２Ｍノード（Non-one M2M Node：ＮｏＤＮ）は、ｏｎｅＭ２Ｍエンティティを（ＡＥもＣＳＥもどちらも）含まないノードである。このようなノードは、管理を含む相互動作目的のために、ｏｎｅＭ２Ｍシステムに接続されたデバイスを意味する。

ｏｎｅＭ２Ｍシステム内でサポートされている種々のエンティティを相互接続した例示的構成を図５に示す。

ｏｎｅＭ２Ｍ動的認証モデルは、リソースオーナーに代わって、リソースに対する動的認証を提供する能力をサポートする。これは、図６に示すように、動的認証に対するポリシーを用いて構成され、かつ認可を出すトークンを発行するための証明書が提供される、動的認証システムサーバを含む場合がある。

ｏｎｅＭ２Ｍエンティティが、アクセスのための既存の権限を有していないリソースへのアクセスを試みると、動的認証プロシージャは、リクエストされた権限をＤＡＳサーバから取得することを試みるように構成される場合がある。

ｏｎｅＭ２Ｍ分散型認証プロシージャは、ｏｎｅＭ２Ｍエンティティがリソースへのアクセスを許されるべきかどうかを決定するための基本的ステップを定義する。図７に示し、かつ以下に記載するような、分散型認証プロシージャの構成要素（ＰＥＰ、ＰＲＰ、ＰＤＰおよびＰＩＰ）は、異なるノードにわたって分散されるか、単一のノード上ですべて一緒にされる場合がある。

ポリシー施行点（Policy Enforcement Point：ＰＥＰ）について、この構成要素は、リソースアクセスリクエストをインターセプトし、アクセス制御定義リクエストを行い、かつアクセス制御定義を施行することができる。ＰＥＰは、認証サービスを必要とするエンティティと共に存在する場合がある。

ポリシー定義点（Policy Decision Point：ＰＤＰ）について、この構成要素は、ＰＲＰおよびＰＩＰと相互に連絡をとり、各認証ポリシーをそれぞれ評価するために必要とされる適用可能な認証ポリシーおよび属性を得て、アクセス制御定義を行うために、認証ポリシーを使用して、アクセスリクエストを評価してもよい。

ポリシー検索点（Policy Retrieval Point：ＰＲＰ）について、この構成要素は、アクセス制御定義リクエストに応じて、適用可能な認証ポリシーを取得することができる。これらの適用可能なポリシーは、最終アクセス制御定義を得るために、組み合わされてもよい。

ポリシー情報点（Policy Information Point：ＰＩＰ）について、この構成要素は、認証ポリシーを評価するために必要とされる属性、例えば、要求元のＩＰアドレス、リソースの作成の時間、および現在の時間または位置などを提供することができる。

３つの例示的ユースケースについて、本明細書に記載する。

コンテキストアウェアアクセスユースケース＃１。新しいデバイス認証－ＩｏＴ／Ｍ２Ｍサービス層の標準化は、より簡単なアプリケーション開発を促進し、既存のシステムへの開発、展開および組み込みの費用効果をもたらすことを目的としたものである。センサまたはアクチュエータなどの新しいデバイスを追加するときに、それらのデバイスが属するシステムを管理するアプリケーションにそれらのデバイスを組み込むことは容易である必要がある。例えば、新しいスマート電球の追加は、各家族が住居の中でデバイスを管理するために用いるスマートホームアプリケーションに組み込みやすくする必要がある。電球が、居間にある場合、家族すべてが、スマート電球を制御できる必要がある。しかし、電球が親の主寝室にある場合、子供は、そのスマート電球にアクセスすることを認可されない場合がある。これらの異なる認証は、スマート電球の構成のコンテキストを考慮に入れて簡単に設定される必要がある。

コンテキストアウェアアクセスユースケース＃２。発信元以外のコンテキスト－一部のＩｏＴ／Ｍ２Ｍサービス層は、要求元／発信元のコンテキストによって決まるアクセスポリシーをサポートする。例えば、発信元からリクエストがきて、その発信元の位置が家から近い場合に、ドアロックにアクセスする認可を出す場合がある。発信元以外のエンティティのコンテキストを用いて、一部の対象のシナリオが展開される場合もある。例えば、ドアロックにアクセスする認可は、家のオーナーが家にいない場合にのみ、出されてもよい。

コンテキストアウェアアクセスユースケース＃３。誤動作デバイス－ＩｏＴ／Ｍ２Ｍデバイスは、ＩｏＴ／Ｍ２Ｍサービス層からデータを送信および検索する自律的センサまたはアプリケーションである場合がある。多数のセンサおよびアプリケーション販売業者による一般的な標準または専売ＩｏＴ／Ｍ２Ｍソリューションの使用により、誤作動または作為的設計によってデバイスが適切に動作しないといったことになり、結果としてシステム性能の低下につながる可能性がある。例えば、通過する車両をカウントする交差点のセンサは、１秒ごとに最大レートで、通過車両を示すメッセージを送信することが考えられる。しかし、メッセージを非常に高レートで送信するこのデバイスが何らかの理由で誤動作する場合、ＩｏＴ／Ｍ２Ｍサービス層全体に影響を与える可能性がある。例えば、これにより、ＩｏＴ／Ｍ２Ｍサービス層において停止問題が発生する可能性があり、センサ「オーナー」の予想外のデータ格納費用が生じる可能性があり、かつこのセンサを監視するアプリケーションで高データ使用を引き起こす可能性がある。

上述した異なるユースケースは、ＩｏＴ／Ｍ２Ｍサービス層での、改良されたコンテキストベースの認証方法の必要性を強調するものである。図８は、これらのユースケースがどのように実装される可能性があるかの一部の例を示す。

ユースケース＃１のような、新しいデバイスを既存のシステムに追加する場合、デバイスまたはアプリケーションを組み込むために、様々な方法がある。例えば、ｏｎｅＭ２Ｍでは、スマート電球を使用する認可を出すプロシージャは、家の中のどのユーザが権限を有しているかを示す新しいアクセス制御ポリシーを追加することによって行われる場合がある。これにより、システム内のデバイスまたはアプリケーションごとにポリシーを有するように導くことができる。変形例は、複数のデバイスまたはアプリケーションに適用できるポリシーを作成することである場合がある。実際に起こり得ることとしては、認証が非常に制約的であり、単一のエンティティしか制御を行うことを許されていないか、または反対に、認証ポリシーに対してごくわずかな制約しか実装されないことである。

ユースケース＃２のような、データにアクセスする認可を出すための定義プロセスに発信元以外のエンティティに関連するコンテキストを追加することは、プライバシー問題、より多くのアプリケーション複雑性、およびポリシー制御の分散化につながる可能性がある。これらのアプローチは、信頼性に欠け、また場合によってはセキュリティリスクが増す可能性がある。

ユースケース＃３で記載したような、誤作動デバイスの場合、サービス層は、特定のデバイスまたはアプリケーションの考えられる操作特性を定義して、実際の操作特性をキャプチャし、かつ異常動作を検出／防止する方法を決定する必要がある場合がある。このことは、ＩｏＴ／Ｍ２Ｍサービス層を用いるすべてのデバイスおよびアプリケーションに対して行われる必要がある場合がある。現在、このことを行うためのメカニズムは規定されていない。

ＩｏＴ／Ｍ２Ｍサービス層アーキテクチャは、センサまたは他のアプリケーションからのデータにアプリケーションがアクセスできるようにする付加価値的な特徴およびソリューションに焦点が当てられたものである。既存のサービス層は、例えば、位置または要求元が固定位置の１０メートル圏内の中にあることを必要とする、コンテキストベースの認可を与える場合がある。本明細書で記載される方法およびシステムは、システムの条件に基づいて認証コンテキストが動的に変更されることに対処できる。

動的コンテキストアウェア認証のために、ＩｏＴ／Ｍ２Ｍサービス層がサービス層の登録者に提供することができる認証検証サービス（ＡＶＳ）について開示する。ＡＶＳは、サービスまたはデータへのアクセスを認可する場合の動的な制限を、ＩｏＴ／Ｍ２Ｍサービス層エンティティが定義できるようにすることができる。制限は、例えば、許可されるアクセス数を基準にして設定されてよい。ＩｏＴ／Ｍ２Ｍ登録者が、動的コンテキストアウェア認可をそれらに対して有しているデータまたはサービスをリクエストした場合、ＡＶＳは、残りの利用可能なアクセスの記録を保持していてもよい。要求元は、任意のＩｏＴ／Ｍ２Ｍサービス層登録者またはＩｏＴ／Ｍ２Ｍサービス層登録者向けのプロキシであってもよい。

例示的機能性、すなわち、既存の認証ポリシーの範囲内にある新しいデータおよびサービスに対する認証ポリシーを動的に適用することと、ＩｏＴ／Ｍ２Ｍサービス層登録者がＩｏＴ／Ｍ２Ｍサービス層に動的コンテキストアウェア認可期限を組み込むことを可能にすることと、これらの動的コンテキストアウェア認可期限に基づいてデータおよびサービスへのアクセスをＩｏＴ／Ｍ２Ｍサービス層によって管理することと、動的コンテキストアウェア認可期限の状態をＩｏＴ／Ｍ２Ｍサービス層によって更新することと、動的コンテキストアウェア認可期限の制限または条件が使い果たされると、アクセス権を無効にすることとが、提案されるＡＶＳによってサポートされる場合がある。しかし、ＡＶＳは、上述のこれらの機能性に限定されないものと理解される。

本明細書で記載される方法およびシステムを使用することによって、ＩｏＴ／Ｍ２Ｍセンサまたはアプリケーションが、ＩｏＴ／Ｍ２Ｍサービス層のデータおよびサービスにアクセスする認可を出す動的コンテキストアウェア認証ポリシーに追加の特徴および能力を組み込むことが可能である。ポリシーを他のデータおよびサービスにどう適用することができるか、特定の操作を認可するときに、追加のシステムコンテキストをどのように考慮に入れることができるか、ならびに、デバイスまたはエンティティの考えられる動作および特性が、ＩｏＴ／Ｍ２Ｍサービス層によってどのように表現され、かつ施行されるかを記述している規則が適用されてもよい。これらの特徴により、より簡単な展開、より効果的な操作、よりセキュアな操作、およびより信頼性のある操作をもたらすことが可能である。

一実施形態では、サービス層の認証検証サービスは、サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストをデバイスから受信することと、サービス層によって提供されるデータまたはサービスのうち少なくとも一方に関連付けられた認証ポリシーを決定することと、認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を決定することであって、ここで、該１つまたは複数のコンテキストアウェア状態は、サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスする場合の１つまたは複数の条件の標示を含み、かつ該１つまたは複数の条件は、サービス層によって提供されるデータまたはサービスのうち少なくとも一方への許可されるアクセス数を含むことと、１つまたは複数のコンテキストアウェア状態に関連付けられた１つまたは複数の条件が有効かどうかを判断することと、１つまたは複数のコンテキストアウェア状態に関連付けられた１つまたは複数の条件が有効であるという判断に基づいて、サービス層によって提供されるデータまたはサービスのうち少なくとも一方へのアクセスをデバイスに許可することと、を含む操作を実施するように構成されてもよい。

１つまたは複数のコンテキストアウェア状態に関連付けられた１つまたは複数の条件は、サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスする場合の時間長をさらに含んでもよい。１つまたは複数のコンテキストアウェア状態に関連付けられた１つまたは複数の条件は、サービス層によって提供されるデータまたはサービスのうち少なくとも一方へのアクセスを許可されるデバイスのタイプをさらに含んでもよい。１つまたは複数のコンテキストアウェア状態に関連付けられた１つまたは複数の条件は、デバイスおよびサービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストから独立していてもよい。認証検証サービスは、サービス層によって格納されている１つまたは複数のデータ、またはサービス層によって実施される操作に基づいてコンテキストアウェア状態を決定することができる。１つまたは複数のコンテキストアウェア状態は、認証ポリシーに書き込まれていてもよい。操作は、サービス層によって提供されるデータまたはサービスのうち少なくとも一方へのアクセスを許可することに基づいて、認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を更新することをさらに含んでもよい。

別の実施形態では、サービス層の認証検証サービスは、サービス層のコアサービス機能から、サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストを受信することと、リクエストに対応する認証ポリシーを決定することと、認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を決定することと、１つまたは複数のコンテキストアウェア状態に基づいて、サービス層によって提供されるデータまたはサービスへのアクセスをサービス層エンティティに許可するかどうかを決定することと、を含む操作を実施するように構成されてもよい。

コンテキストアウェア状態は、対応する認証ポリシーに書き込まれていてもよい。一例では、認証ポリシーに関連付けられたコンテキストアウェア状態は、ポリシーの時間長またはポリシーへの許可されるアクセス数を含んでよい。認証検証サービスは、サービス層によって格納されているデータまたは、サービス層によって実施される操作に基づいてコンテキストアウェア状態を決定することができる。認証検証サービスは、コンテキストアウェア状態の１つまたは複数の条件が満たされたという判断に応じて、サービス層によって提供されるデータまたはサービスへのアクセスを許可してもよい。一例では、認証検証サービスは、認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を更新してもよい。認証ポリシーは、認可範囲プロシージャを使用して作成されてもよい。一例では、認証検証サービスは、コンテキストアウェア状態の１つまたは複数の条件が満たされていないという判断に応じて、サービス層によって提供されるデータまたはサービスへのアクセスを拒否してもよい。さらに、認証検証サービスは、認証ポリシーを削除するか、または１つまたは複数の動的認証プロシージャをトリガしてもよい。

ＩｏＴ／Ｍ２Ｍサービス層は、特定の認証に対する制限を、ＩｏＴ／Ｍ２Ｍサービス層でホストされるデータを作成または制御するＩｏＴ／Ｍ２Ｍサービス層登録者が定義することを可能にすることができる。例えば、認証は、１０アクセス、１００アクセスまたは無制限アクセスに対処できる。ＩｏＴ／Ｍ２Ｍサービス層のＡＶＳは、認証ポリシーのコンテキストを確認し、アクセスが認可されているかを検証してもよく、またポリシーに関連付けられた状態（コンテキストアウェア状態）を確認および更新し、特定の認証範囲を超えていないかを確かめてもよい。新しいサービスまたはデータが提供される場合、既存の認証ポリシーの自動適用のサポートが提供されてもよい。

リクエストが、ＩｏＴ／Ｍ２Ｍサービス層のサービスまたはリソースに対して行われるときに、リクエストは、それが、要求元に対して「認可される」べきか、「拒否される」べきかどうかについて定義する権限のセットと照合されてよい。既存の認証ポリシーが、そのリクエストは「認可される」と示す場合、ＩｏＴ／Ｍ２Ｍサービス層は、リソースまたはサービスへのアクセスを提供してもよい。一実施形態では、図９に示すように、「認証検証サービス」は、２つの構成要素を有する場合がある。第１に、リクエストが、リクエストされたデータまたはサービスに関連するポリシーによって「認可されなかった」場合、ＡＶＳは、検索し、認可を出す定義済み認可範囲（リクエストに先だって予め構成されているか、または予め準備されている）が存在するかどうかを確認してもよい。これは、前もって認可範囲が存在しない場合に、認可を出すプロセスではなく、このリクエストがその「認可範囲」に含まれる既存のポリシーを検索するプロセスである、という点に留意すべきである。第２に、リクエストを「認可した」ポリシーは、リクエストされた操作を認可するために満たされる必要がある可能性のある「動的コンテキスト」があるかどうかを確認するためにさらに検査されてもよい。

ポリシーは、リクエストが認可されるかどうかを決定するソフトウェアアルゴリズムによって処理され得る文書またはデータ構造として定義されてよい。リクエストが、ＩｏＴ／Ｍ２Ｍサービス層によってホストされているデータまたはサービスにアクセスするために行われる場合、リクエストの発信元に認可を出すポリシーがあるかどうかを認識するために確認が行われてよい。ＲＥＳＴｆｕｌシステムでは、各データ要素またはサービスは、この決定を行うために使用される既存のポリシーと見なされる場合がある。場合によっては、リクエストされているデータまたはサービスは、データまたはサービスの階層構造に基づいて既存のポリシーの参照を引き継ぐことが可能である。例えば、ＩｏＴ／Ｍ２Ｍエンティティは、ルート位置からの直系子孫として識別されるすべてのデータまたはサービスに対する認可が与えられてもよい。一実施形態では、ポリシーは、サービス層で格納されてもよい。例えば、ポリシーは、ＸＭＬまたはＪＳＯＮ文書として、またはサービス層で格納されているテーブルに格納されてよい。

データまたはサービスのグループへのアクセスの自動適用の方法は、「認可範囲」を定義することによって拡張されてもよい。認可範囲は、ポリシーで定義されるＩｏＴ／Ｍ２Ｍエンティティによってアクセスされる場合があるデータまたはサービスのセットを規定してもよい。一実施形態では、データおよびサービスの規定は、データおよびサービスの明確なリストであるか、またはデータまたはサービスに関連付けられたメタデータの値に基づくものである場合がある。認可範囲は、既存のポリシー定義の拡張であるか、あるいは、別個の、または新しいポリシータイプであってもよい。一実施形態では、認可範囲は、このポリシーが適用されるデータまたはサービスの識別情報、このポリシーが適用されるデータまたはサービスのメタデータの値、このポリシーが適用されるＩｏＴ／Ｍ２Ｍエンティティの識別情報、およびデータまたはサービスにアクセスするエンティティに付与される特定の権限、のうち１つまたは複数の構成要素を有していてもよい。このポリシーは、ＸＭＬまたはＪＳＯＮ文書として、またはサービス層で格納されているテーブルに格納されてよい。

例えば、ＩｏＴ／Ｍ２Ｍサービス層でホストされるデータのプロバイダ１は、プロバイダ１によって作成／所有され、かつデータがカテゴリーＡであると示すメタデータを有する全データに、ユーザ１がアクセスできると規定するポリシーを作成することができる。認可範囲を使用して、新しいデータがメタデータで規定されているカテゴリーＡを用いてプロバイダ１によって作成される場合、ユーザ１は、データの階層位置に関係なく新しいデータにアクセスすることを（望まれない限り）動的に認可されてよい。ＩｏＴ／Ｍ２Ｍアプリケーションでは、これにより、センサごとにＳＬ認証ポリシーを設定する必要なく、配備される新しいセンサからのデータへのアクセスを許可するプロセスを単純化できる。図１０は、「認可範囲」を実装するために必要とされるステップの例示的実施形態を示す。

ステップ１では、新しいリクエストが届くと、ＩｏＴ／Ｍ２Ｍサービス層は、リクエストされている特定のサービスまたはデータに適用する認証ポリシーを検索する。ポリシーが識別されると、発信ＩｏＴ／Ｍ２Ｍエンティティがリクエストした操作を実施することを認可されているかどうかを認識するために、それらポリシーは確認されてよい。そのリクエストが「許可される」と決定される場合、ＩｏＴ／Ｍ２Ｍサービス層は、データまたはサービスへのアクセスを提供してもよい。認可されない場合、プロシージャは、ＡＶＳにリクエストを発行することで、ステップ２に進む。「認可範囲リクエスト」メッセージ（２ａ）は、リクエストされたデータまたはサービスの識別子、要求元の識別子、およびリクエストされた操作の識別子のうち１つまたは複数を含んでもよい。

ステップ２では、ＡＶＳは、規定されている「認可範囲」を有するポリシーを検索する。リクエストされたデータまたはサービス、リクエストを行ったＩｏＴ／Ｍ２Ｍエンティティ、およびリクエストされた操作に適用する、定義されている「認可範囲」を有するポリシーが見つかる場合、リクエストは、「認可される」ことが決定される。リクエストされたデータまたはサービスの（記述的、構造的および管理上の）メタデータは、この「認可範囲」評価が行われるときに考慮され得る。例えば、ポリシーは、リクエストされたデータまたはサービスのタグまたはラベルが、特定の値またはトークンを含むことを必要とする場合がある。

ステップ３では、「認可範囲」は、リクエストされたサービス／データに対して新しいポリシーが作成される（３ａ）べきかどうか、もしくは現在のポリシーまたは別の既存のポリシーをサービス／データに割り当てられる（３ｂ）べきかどうかを定義し得る。ＩｏＴ／Ｍ２Ｍサービス層は、ステップ２で見つかったポリシーを反映する、またはこのステップで後のリクエスト向けに考慮されて作成されたリクエストされたデータまたはサービスに関連付けられたメタデータを更新してもよい。例えば、データまたはサービスに付属するメタデータまたは属性は、新しいポリシーへの指示子を用いて更新される場合がある。

ステップ１から３は、実装形態では、統合されてもよいものと理解される。

これらの新しいポリシーの態様を使用して、ＩｏＴ／Ｍ２Ｍサービス層が簡単な呼出フローを伴う先進の能力を提供することを可能にする認証ポリシーの有効期間を管理してもよい。例えば、最大１０個の認可を許すポリシーの定義を有効にするように新しい特徴が拡張されて、認可が使い果たされた後に、自動的にポリシーを削除することができる。あるいは、ポリシーは、日ごとに、日々の制限を規定する能力を提供することをリセットすることができる。新しいポリシーの例示的情報は、表１に一覧で記載され、かつ「サービス／データ更新」メッセージに含まれてもよい。

表１に記載したコンテキストのいくつかを使用するための追加の説明またはプロシージャについて以下に説明する。

timeDuration態様を使用して、ポリシーがどれくらいの間、効力を持続できるかを規定してもよい。これは、認可範囲プロシージャが新しいポリシーを作成するときに、新しいポリシーが作成される場合に使用されてよい。timeDuration値は、新しいポリシーの満了時間を規定するために、現在の時間（新しいポリシーの作成時間）に追加されてもよい。

resetCondition態様を使用して、現在の動的状態がゼロなどの初期値にリセットされるときの時間または条件を規定してもよい。resetCondition態様の使用の一例では、ＩｏＴ／Ｍ２Ｍサービス層は、毎時間１２のアップロードをＩｏＴ／Ｍ２Ｍエンティティが実施することを認可するように要求してもよい。ＩｏＴ／Ｍ２Ｍサービス層は、各アップロード後に、count動的コンテキストを更新して、countLimitよりもcountが小さい場合、リクエストを認可してもよい。毎時間、ＩｏＴ／Ｍ２Ｍサービス層は、ゼロにcount動的コンテキストをリセットしてもよい。

deleteWhenExhausted動的コンテキストは、アプリケーションおよびＩｏＴ／Ｍ２Ｍサービス層向けの動的コンテキストアウェア認証の管理を容易にするために使用される。これにより、無効となり有用ではなくなったポリシーを削除するメカニズムが可能になる。この値が、「真」として規定されて、動的コンテキスト確認が認可を出さず、かつリセット条件が規定されない場合、ポリシーは、ＩｏＴ／Ｍ２Ｍサービス層によって削除されてよい。

認証ポリシーが、ユーザがリソースにアクセスするために存在する場合、動的コンテキストアウェア認証は、ポリシーに関連付けられた条件付きのコンテキストがあるかどうか評価してもよい。認証ポリシーは、プロビジョニングを通してユーザ向けに存在するか、または本明細書に記載された「認可範囲」プロシージャによって作成されてもよい。動的コンテキストアウェア認証が適用されると決定される場合、ＡＶＳは、特定のコンテキストに対応する状態を修正してもよい。

図１１は、コンテキストアウェア認証状態に関連付けられた状態を管理するＡＶＳの呼出フローを示す。

ステップ１では、コンテキストアウェア状態が認証ポリシーで規定されている場合に、ＡＶＳは、それらを受け取る。コンテキストを確認するために必要な情報が、認証ポリシーに記述されている場合がある。動的状態は、ポリシーに書き込まれる場合があるか、もしくは状態およびコンテキストを決定するために、他のＩｏＴ／Ｍ２Ｍサービス層のデータまたは操作の確認が必要である場合がある。

ステップ２では、現在のコンテキストアウェア状態が、ポリシーによって規定されているすべての条件を満たす場合、認可が出されてもよい。条件を満たさない場合、認可は出されない。認可判断は、サービス層に返されてもよい。これによりまた、認可範囲プロシージャをトリガできる。

ステップ３では、コンテキストアウェア状態が規定されている場合、ＡＶＳは、それらを調整する。これは、カウンタ属性に加算すること、またはカウントダウン属性から減算することを含んでもよい。動的コンテキストアウェア状態が、ペイロードサイズを基準にしている場合、応答がユーザに送信された後に、この調整が行われてもよい。例えば、ペイロードの後に、応答で送信されるmaxDownload状態が使用される場合、情報は、「ダウンロードカウンタ」を更新するために利用されてもよい。

コンテキストアウェア状態が、アクセスを許可する条件を満たさない場合、ＡＶＳは、動的認証プロシージャをトリガするか、コンテキストアウェア認証ポリシーを削除または無効にすることができる。

認証は、概して、ＣＲＵＤ（ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥおよびＤＥＬＥＴＥ）の基本的操作に適用される。認証はまた、例えば、ＮＯＴＩＦＹおよびＤＩＳＣＯＶＥＲＹ（ｏｎｅＭ２Ｍによる例のような）のＣＲＵＤから派生する操作に適用することができる。ＩｏＴ／Ｍ２Ｍエンティティは、特定のサービスまたはデータに対するＲＥＴＲＩＥＶＥ認可を与えられてもよい。これは、概して、静的認可、またはめったに変更されない認可である。本明細書で記載される情報要素は、認可が出されるかどうかを決定するときに、動的条件が考慮されることを可能にする。例えば、ＩｏＴ／Ｍ２Ｍエンティティは、「オーナー」が家にいない場合のみ、一度だけ家のドアの「開錠」を許可されてもよい。コンテキストアウェア認証情報の欠如は、無制限のアクセスを意味する。表２にコンテキストウェア認証フィールドの説明を示す。

uploadCount動的コンテキストの使用例は、ＩｏＴ／Ｍ２Ｍエンティティによって、どれくらいのデータがＩｏＴ／Ｍ２Ｍサービス層に作成または格納できるかの定義として規定される値を使用することである。ＩｏＴ／Ｍ２Ｍサービス層は、操作を認可するために、このポリシーを使用するたびにuploadCountを更新してもよい。uploadCountがmaxUpload値を上回る場合、ＣＲＥＡＴＥまたはＵＰＤＡＴＥ操作は、認可されない場合がある。ＩｏＴ／Ｍ２Ｍエンティティによってリクエストされる操作が、ＲＥＴＲＩＥＶＥまたはＤＥＬＥＴＥである場合、maxUpload確認は、却下される場合があるが、依然として適用される可能性もある。ＲＥＴＲＩＥＶＥまたはＤＥＬＥＴＥ操作の場合は、uploadCountは、更新されない場合がある。

accessTechnology動的コンテキストを使用して、ＩｏＴ／Ｍ２Ｍサービス層と通信するために用いられるアクセスのタイプに基づいて認可を制約してもよい。例示的ユースケースでは、ＩｏＴ／Ｍ２Ｍエンティティは、ＩｏＴ／Ｍ２Ｍサービス層へのリクエストを送信する複数の方法を用いる場合がある。しかし、リクエストが、そのリクエストのためにブルートゥース（登録商標）技術を用いる場合、ＩｏＴ／Ｍ２Ｍは、ＩｏＴ／Ｍ２Ｍエンティティが特定のデバイスのみで操作を実施することを認可することがある。

outOfVicinityおよびinVicinity動的コンテキストを使用して、ＩｏＴ／Ｍ２Ｍエンティティが配置されている場所に基づいて認可を制約してもよい。この値は、リクエストを行っているＩｏＴ／Ｍ２Ｍエンティティに適用することができる。加えて、この値は、本明細書で記載される方法およびシステムを使用して、任意のＩｏＴ／Ｍ２Ｍエンティティに適用されてよい。これにより、ＩｏＴアクチュエータおよびアプリケーションの開発を簡単にできる可能性がある。例えば、遠隔で大規模な機械に電源を入れる能力を備える製造工場では、機械の周囲の安全区域内に、人がいない、または物体がないことを確認する実装形態がある場合がある。アプリケーションは、まず安全区域を確認し、かつ安全区域がクリアな場合のみ、機械に電源を入れる信号を送信してもよい。この安全区域確認を認証ポリシーに組み込むことは、アプリケーションを簡略化し、かつアプリケーションでのエラーが信号を送ることを許し、安全区域の確認なしに機械に電源を入れる可能性を減らすことでセキュリティを強化する。

ポリシーが適用される特定のデータまたはサービスにリクエストするのとはまったく異なり、requestorCriteria動的コンテキストを使用して、ＩｏＴ／Ｍ２Ｍサービス層の全体にわたって実施されたことのあるＩｏＴ／Ｍ２Ｍサービス層操作に基づいて認可を制約してもよい。例えば、ｏｎｅＭ２Ｍでは、要求元が、特定のリソースで１００のcontentInstanceをまだ作成していない場合に、contentInstance作成操作が認可される場合がある。

ｏｎｅＭ２Ｍサービス層認証システムは、以下の例示的論理機能で構成されていてもよい。

認可範囲管理（Authorization Scope Management：ＡＳＭ）について、この機能は、ターゲットリソースおよびリクエストの発信元を含むauthenticationScope属性を有する既存の<accessControlPolicy>があるかどうかを判断する。見つかる場合、既存の<accessControlPolicy>を含むためにacpiは更新されてよい。ｏｎｅＭ２Ｍの分散型認証が実装されている場合、ＡＳＭの機能性はＰＲＰに含まれる場合がある。

認証コンテキスト機能（Authorization Context Function：ＡＣＦ）について、この機能は、<accessControlPolicy>によって定義される任意のコンテキスト情報を収集するが、この情報は、発信元によって送信されるリクエストプリミティブからは導出できないものである。例えば、<accessControlPolicy>は、このリクエストが認可されるかどうかを評価するために、ＡＥＨｏｍｅＯｗｎｅｒの位置が必要とされることを規定してもよい。ＡＣＦは、ＡＥＨｏｍｅＯｗｎｅｒの位置を取得してもよい。ＡＣＦは、ｏｎｅＭ２ＭのＰＩＰに実装される場合がある。

調整認可状態（Adjust Authorization State：ＡＡＳ）について、この機能は、リクエストされた／認可された操作に関連する状態を含む<accessControlPolicy>属性を更新する。<accessControlPolicy>の更新の後に発生するいずれの警告または他のアクションも、ＡＡＳによって実施されてよい。例えば、alertThresholdCountが達する場合、ＡＡＳは、通知を開始することができる。ＡＡＳは、ｏｎｅＭ２ＭのＰＩＰまたはＰＤＰに実装される場合がある。

コンテキストアウェア認証状態の本実装形態は、ｏｎｅＭ２Ｍの、TS-0001 oneM2M Functional Architecture-V-3.6.0で規定されている既存のｏｎｅＭ２Ｍ<accessControlPolicy>に、新しい属性を追加する。以下に一覧で記載されるリソース定義は、概して、本明細書で提示される着想に関連する属性および子リソースのみを示す。本明細書に示されていない他の属性および子リソースも、実際の実施形態に、存在する場合がある。

ｏｎｅＭ２Ｍは、どのｏｎｅＭ２Ｍエンティティが、<accessControlPolicy>に関連するリソースにアクセスできるかを規定する<accessControlPolicy>リソースを定義している。例えば、privileges属性が、アクセス制御規則のセットによって規定されてもよい。アクセス制御規則は、本明細書にて開示されるような属性およびプロシージャを用いて拡張される、サブ属性、accessControlContexts、およびaccessControlObjectDetailsを有していていもよい。

以下の新しいaccessControlContextsが、ＣＳＥによって確認されるアクセス制御ポリシーに関して考慮されてよい。表３にaccessControlContexts内のパラメータの新しいタイプを示す。

accessControlLocationRegionは、国コードまたは、緯度、経度、および半径範囲を表す３つの値のセットとして規定されてよい。本開示では、操作を認可することを決定するときに、エンティティが定義された領域の内側にあるか、または定義された領域の外側にあることを示す指定子を追加する。一例では、エンティティのリストを規定して、発信元以外のエンティティが、位置条件を満たす必要があることを示すことができる。いずれのエンティティも提示されない場合、デフォルト動作は、位置比較を発信元の位置に適用することであってもよい。複数の領域がエンティティに対して定義された場合、１つの領域に対してのみ、条件を真にする必要がある場合がある。複数のエンティティが定義される場合、全エンティティに対して、条件を真にする必要がある場合がある。

accessControlLimitまたはaccessControlDataLimitが規定されている場合、この<accessControlPolicy>リソースが、使用された回数が、構成されたaccessControlLimitを超えるか、または伝送されたデータの量がaccessControlDataLimitを超える場合、操作を実施する認可が与えられない場合がある。アクセス数のカウントは、accessControlLimitに書き込まれてもよく、また伝送されるデータ量は、accessControlDataLimitに書き込まれてもよい。リクエストが、この特定の認証ポリシーに基づいて許可されるときに、これらのカウントは、リソースの読み取り専用属性として書き込まれてよく、かつこれらの値は、ホストＣＳＥによって更新される。

ｏｎｅＭ２Ｍは、アクセス制御規則の任意選択のパラメータとして、accessControlObjectDetailsを定義する。それは、アクセス制御規則が適用されるターゲットリソースの子リソースタイプのサブセットを規定する。

本開示中に記載された着想の実施形態は、以下の新しい属性を含むために、accessControlObjectDetailsの定義を拡張することができる。表４にaccessControlObjectDetails内のパラメータの新しいタイプを示す。

発信元が、ターゲットリソースでの操作を実施することが認可されていない場合、ホストＣＳＥは、ターゲットリソースの先祖リソースをＣＳＥＢａｓｅまで確認し、propagateACP属性が規定されている<accessControlPolicy>を探してもよい。<accessControlPolicy>が、リクエストされた操作の認可を見つける場合、ホストＣＳＥは、<accessControlPolicy>のリソース識別子を用いてターゲットリソースのaccessControlPolicyIDs属性をＵＰＤＡＴＥするか、または、見つけた<accessControlPolicy>の属性に基づいて、新しい<accessControlPolicy>をＣＲＥＡＴＥしてもよい。新しい<accessControlPolicy>作成時、expirationTimeが、timeLimitで規定された値に従って設定されてよく、またpropagateACPが、ｎｕｌｌに設定されてよい。ホストＣＳＥが、ターゲットリソースのaccessControlPolicyIDs属性を更新するときに、リストの中の任意の他のリソース識別子に<accessControlPolicy>リソース識別子を追加するか、この<accessControlPolicy>を、このリスト内の唯一のものとして設定してもよい。

図９から１１に示されているステップを実施する、ＡＶＳ、ＡＥ、ＣＳＥ、その他のＳＬエンティティなどのエンティティのいずれかは、論理エンティティであってもよく、そのエンティティは、図１２Ｃまたは図１２Ｄに示されるような無線および／またはネットワーク通信またはコンピュータシステム向けに構成された装置のメモリ内に記憶され、かつその装置のプロセッサで実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装される場合がある。すなわち、図９から１１に示される方法は、図１２Ｃまたは図１２Ｄに示される装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装される場合があり、このコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図９から１１に示されるステップを実施するものである。また、図９から１１に示される任意の伝送および受信ステップは、装置のプロセッサの制御および該プロセッサが実行するコンピュータ実行可能命令（例えば、ソフトウェア）下で、装置／エンティティの通信回路によって実施されてよいことも理解される。

図１２Ａは、１つまたは複数の開示する実施形態がその中で実装される可能性のある、マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（Web of Things：ＷｏＴ）通信システム１０の例の図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、かつ任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたは装置、ならびにＩｏＴ／ＷｏＴサービス層などであってよい。図２から７および図９から１１に示されるエンティティのいずれかは、図１２Ａから１２Ｄに示されるような通信システムのネットワーク装置を含んでもよい。

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

図１２Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣなど）または無線ネットワーク（例えば、ＷＬＡＮ、セルラーなど）、もしくは異種ネットワークのネットワークであってよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のユーザに提供する複数のアクセスネットワークで構成されてよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（Code Division Multiple Access：ＣＤＭＡ）、時分割多重アクセス（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多重アクセス（Frequency Division Multiple Access：ＦＤＭＡ）、直交ＦＤＭＡ（Orthogonal FDMA：ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（Single-Carrier FDMA：ＳＣ－ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を採用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含んでよい。

図１２Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含んでもよい。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、またフィールドドメインとは、通常は、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインとインフラストラクチャドメインの両方は、ネットワークの種々の異なるネットワーク装置（例えば、サーバ、ゲートウェイ、デバイスなど）を含んでよい。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４およびデバイス１８を含んでもよい。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれてもよいことが理解されよう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、通信回路を使用して信号を伝送および受信するように構成される。

Ｍ２Ｍゲートウェイデバイス１４は、通信ネットワーク１２などのオペレータネットワーク、または直接無線リンクのいずれかを通して、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が通信できるようにする。例えば、Ｍ２Ｍデバイス１８は、通信ネットワーク１２または直接無線リンクを介して、データを収集し、かつデータをＭ２Ｍアプリケーション２０または別のＭ２Ｍデバイス１８に送信してもよい。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信してもよい。さらに、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、データおよび信号はＭ２Ｍアプリケーション２０に送信され、かつそこから受信されてもよい。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信してもよい。Ｍ２Ｍデバイスの例としては、タブレット、スマートフォン、メディカルデバイス、気温・天候モニター、コネクテッドカー、スマートメーター、ゲームコンソール、携帯情報端末、健康・フィットネスモニター、照明、サーモスタット、機器、ガレージドアおよびその他のアクチュエータ式デバイス、セキュリティデバイスおよびスマートコンセントなどが挙げられるが、これらに限定されない。

図１２Ｂを参照すると、図示されているフィールドドメイン内のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８、ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、所望により、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信してよいことが理解されよう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを含むことがある、ネットワークの１つまたは複数のネットワーク装置によって実装される場合がある。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４およびＭ２Ｍアプリケーション２０に適用するサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドでなど、様々な方法で実装されてよい。

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

図１２Ｂをさらに参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルなシステムが活用することができるサービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互に連絡をとり、かつデータ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見などの機能を実施することを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除くので、アプリケーション開発を単純化し、かつ市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと連携して、ネットワーク１２などの種々のネットワークを通して通信することも可能にする。

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

概して、図１２Ｂに示されるサービス層２２および２２’などのサービス層は、アプリケーションプログラミングインターフェース（Application Programming Interfaces：ＡＰＩ）と下位ネットワークインターフェースとのセットを通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を画定する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を規定している。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（Service Capability Layer：ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノードで実装される場合がある。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（この場合、デバイスＳＣＬ（Device SCL：ＤＳＣＬ）と称される）、ゲートウェイ（この場合、ゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と称される）、および／またはネットワークノード（この場合、ネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と称される）内に実装される場合がある。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる可能性のある共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）は、マシンタイプコミュニケーション（Machine-Type Communication：ＭＴＣ）向けのアーキテクチャも規定している。そのアーキテクチャでは、サービス層およびサービス層が提供するサービス能力は、サービス能力サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＳＴＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬまたはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、もしくはネットワークの他のいくつかのノードで具現化される、サービス層のインスタンスは、サーバ、コンピュータおよび他のコンピューティングデバイスまたはノードを含むネットワーク内の１つまたは複数のスタンドアロンノードか、または１つまたは複数の既存のノードの一部としてのどちらかで実行する論理的エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として実装される場合がある。一例として、サービス層のインスタンスまたはそのコンポーネントは、図１２Ｃまたは１２Ｄに図示され、以下で説明される基本的なアーキテクチャを有するネットワーク装置（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で動作するソフトウェアの形態で実装される場合がある。

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

図１２Ｃは、図２から７および図９から１１に示されるエンティティの１つなどの、ネットワークの装置の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図であり、そのような装置は、図１２Ａおよび１２Ｂに示されるような、Ｍ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイスまたは他のネットワーク装置として、作動する場合がある。図１２Ｄに示すように、ネットワーク装置３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、電源４８と、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。ネットワーク装置３０は、送受信機３４および伝送／受信要素３６などの通信回路も含んでもよい。ネットワーク装置３０は、実施形態と一致したままで、上述の要素の任意の副次的組み合わせを含んでよいことを理解されたい。このネットワーク装置は、図２から７および図９から１１に関連して示され、かつ記載される操作方法のような、本明細書に記載されるコンテキストアウェア認証方法を実装する装置であってもよい。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuits：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（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：ＣＰＵ）９１などのプロセッサ内で実行されてよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央演算処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央演算処理装置９１は、複数のプロセッサを含むことがある。コプロセッサ８１は、主要ＣＰＵ９１とは異なる、追加の機能を実施するか、またはＣＰＵ９１を支援する任意選択のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書を受信またはセッション証明書に基づく許可など、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのために、開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理してよい。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、またコンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ転送し、かつ他のリソースから転送する。このようなシステムバスは、コンピューティングシステム９０内のコンポーネント同士を接続し、かつデータ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、および割り込みを送信し、かつシステムバスを操作するための制御ラインを含む。このようなシステムバス８０の一例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に連結されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。このようなメモリは、情報の記憶および取得を可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られてよく、または変更されてもよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してよい。メモリコントローラ９２はまた、システム内のプロセスを隔離し、かつユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供してよい。したがって、第１のモードで起動するプログラムは、それ自体のプロセス仮想アドレス空間によってマップされているメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を伝達する役割を担う、周辺機器コントローラ８３を含んでもよい。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。このような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装される場合がある。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。ディスプレイ８６は、ＣＰＵ９１によって実行されるコンピュータ実行可能命令と組み合わされて、図１２Ｄおよびそれに伴って本明細書で示され、かつ記載されるグラフィカルユーザインターフェースを生成および操作してもよい。

さらに、コンピューティングシステム９０は、例えば、ネットワークアダプタ９７などの通信回路を含んでよく、このネットワークアダプタ９７を使用して、図１２Ａから１２Ｄのネットワーク１２などの外部の通信ネットワークに、コンピューティングシステム９０を接続して、コンピューティングシステム９０がネットワークの他の装置と通信できるようにしてもよい。通信回路を、単独で、またはＣＰＵ９１との組み合わせで使用して、本明細書（例えば、図２から７および９から１１）および特許請求の範囲で記載される伝送および受信ステップを実施してもよい。

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

以下に掲げるものは、上記の説明に出現する場合があるサービス層技術に関連する頭字語のリストである。特に指示がない限り、本明細書で使用される頭字語は、以下の表５に記載された対応する用語を指す。

以下に掲げるものは、上記の説明に出現する場合があるサービス層技術に関連する用語および定義のリストである。特に指示がない限り、本明細書で使用される用語および定義は、以下の表６に記載された対応する用語を指す。

本明細書は、最良の方式を含む本発明を開示するために、また当業者が任意のデバイスまたはシステムを作製かつ使用し、任意の組み込まれた方法を行うことを含む本発明を実践することを可能にするために、各例を使用する。本発明の特許性のある範囲は、特許請求の範囲によって定義され、かつ当業者に想起される他の実施例を含み得る。そのような他の実施例は、特許請求の範囲の文字通りの言葉とは異ならない構造要素を有する場合に、または特許請求の範囲の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、特許請求の範囲の範囲内であることを意図している。

Claims (20)

1. サービス層の認証検証サービスによって実装される方法であって、
   前記サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストをデバイスから受信することと、
   前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方に関連付けられた認証ポリシーを決定することと、
   前記認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を決定することであって、ここで、前記１つまたは複数のコンテキストアウェア状態は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の１つまたは複数の条件の標示を含み、かつ前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方への許可されるアクセス数を含むことと、
   前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効かどうかを判断することと、
   前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効であるという判断に基づいて、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスを前記デバイスに許可することと、
   を含む方法。
2. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の時間長をさらに含む、請求項１に記載の方法。
3. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスが許可されるデバイスのタイプをさらに含む、請求項１に記載の方法。
4. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記デバイス、および前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする前記リクエストから独立している、請求項１に記載の方法。
5. 前記認証検証サービスは、前記サービス層によって格納されている１つまたは複数のデータ、または前記サービス層によって実施される操作に基づいて前記コンテキストアウェア状態を決定する、請求項１に記載の方法。
6. 前記１つまたは複数のコンテキストアウェア状態は、前記認証ポリシーに書き込まれる、請求項１に記載の方法。
7. 前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスを許可することに基づいて、前記認証ポリシーに関連付けられた前記１つまたは複数のコンテキストアウェア状態を更新することをさらに含む、請求項１に記載の方法。
8. プロセッサおよびメモリを備える装置であって、前記メモリは、コンピュータ実行可能命令を記憶しており、前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、通信ネットワークのサービス層を実装し、
   前記サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストをデバイスから受信することと、
   前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方に関連付けられた認証ポリシーを決定することと、
   前記認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を決定することであって、ここで、前記１つまたは複数のコンテキストアウェア状態は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の１つまたは複数の条件の標示を含み、かつ前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方への許可されるアクセス数を含むことと、
   前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効かどうかを判断することと、
   前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効であるという判断に基づいて、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスを前記デバイスに許可することと、
   を含む操作を前記サービス層の認証検証サービスに実施させる、装置。
9. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の時間長をさらに含む、請求項８に記載の装置。
10. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスが許可されるデバイスのタイプをさらに含む、請求項８に記載の装置。
11. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記デバイス、および前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする前記リクエストから独立している、請求項８に記載の装置。
12. 前記認証検証サービスは、前記サービス層によって格納されている１つまたは複数のデータ、または前記サービス層によって実施される操作に基づいて前記コンテキストアウェア状態を決定する、請求項８に記載の装置。
13. 前記１つまたは複数のコンテキストアウェア状態は、前記認証ポリシーに書き込まれる、請求項８に記載の装置。
14. 前記命令は、実行されると、前記サービス層の前記認証検証サービスに、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスを許可することに基づいて、前記認証ポリシーに関連付けられた前記１つまたは複数のコンテキストアウェア状態を更新することを含む操作をさらに実施させる、請求項８に記載の装置。
15. コンピュータ実行可能命令を記憶しているコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、プロセッサによって実行されると、サービス層の認証検証サービスに、
    前記サービス層によって提供されるデータまたはサービスのうち少なくとも一方にアクセスするリクエストをデバイスから受信することと、
    前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方に関連付けられた認証ポリシーを決定することと、
    前記認証ポリシーに関連付けられた１つまたは複数のコンテキストアウェア状態を決定することであって、ここで、前記１つまたは複数のコンテキストアウェア状態は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の１つまたは複数の条件の標示を含み、かつ前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方への許可されるアクセス数を含むことと、
    前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効かどうかを判断することと、
    前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件が有効であるという判断に基づいて、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスを前記デバイスに許可することと、を含む操作を実施させる、コンピュータ可読記憶媒体。
16. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする場合の時間長をさらに含む、請求項１５に記載のコンピュータ可読記憶媒体。
17. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方へのアクセスが許可されるデバイスのタイプをさらに含む、請求項１５に記載のコンピュータ可読記憶媒体。
18. 前記１つまたは複数のコンテキストアウェア状態に関連付けられた前記１つまたは複数の条件は、前記デバイス、および前記サービス層によって提供される前記データまたはサービスのうち少なくとも一方にアクセスする前記リクエストから独立している、請求項１５に記載のコンピュータ可読記憶媒体。
19. 前記認証検証サービスは、前記サービス層によって格納されている１つまたは複数のデータ、または前記サービス層によって実施される操作に基づいて前記コンテキストアウェア状態を決定する、請求項１５に記載のコンピュータ可読記憶媒体。
20. 前記１つまたは複数のコンテキストアウェア状態は、前記認証ポリシーに書き込まれる、請求項１５に記載のコンピュータ可読記憶媒体。

Images