特許 6821609 リソース駆動動的承認フレームワーク

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6821609

(24)【登録日】2021年1月8日

(45)【発行日】2021年1月27日

(54)【発明の名称】リソース駆動動的承認フレームワーク

(51)【国際特許分類】

   G06F 21/62 20130101AFI20210114BHJP

   G06F 13/00 20060101ALI20210114BHJP

   G06F 21/33 20130101ALI20210114BHJP

【ＦＩ】

   G06F21/62

   G06F13/00 510A

   G06F21/33 350

【請求項の数】10

【全頁数】65

(21)【出願番号】特願2017-568195(P2017-568195)

(86)(22)【出願日】2016年6月30日

(65)【公表番号】特表2018-525722(P2018-525722A)

(43)【公表日】2018年9月6日

(86)【国際出願番号】US2016040395

(87)【国際公開番号】WO2017004373

(87)【国際公開日】20170105

【審査請求日】2019年6月26日

(31)【優先権主張番号】62/188,157

(32)【優先日】2015年7月2日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】チョイ， ビノッド クマー

(72)【発明者】

【氏名】ワン， チョンガン

(72)【発明者】

【氏名】ラフマン， シャミム アクバル

(72)【発明者】

【氏名】リー， チュアン

(72)【発明者】

【氏名】リ， シュウ

(72)【発明者】

【氏名】チェン， ズオ

(72)【発明者】

【氏名】ディ ジローラモ， ロッコ

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２０１４−１０６６５２（ＪＰ，Ａ）

【文献】 特開２００８−０８４２６６（ＪＰ，Ａ）

【文献】 特開２００５−３３９１７９（ＪＰ，Ａ）

【文献】 特開２００６−２４４４７３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１５／００８９６２３（ＵＳ，Ａ１）

【文献】 SEITZ LUDWIG ET AL，Authorization framework for the Internet-of-Things，2013 IEEE 14TH INTERNATIONAL SYMPOSIUM ON A WORLD OF WIRELESS, MOBILE AND MULTIMEDIA NETWORKS，米国，IEEE，２０１３年 ６月 ４日，1-6

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ２１／３３

(57)【特許請求の範囲】

【請求項1】

プロセッサとメモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
リソースリストからリソースについての情報を取得することであって、前記情報は、承認に関連し、サポートされるモデルのリストを含む、ことと、
前記情報を評価することと、
サーバが前記装置におけるクライアントが承認されているかどうかを決定することができるように、前記サーバと相互作用することと、
前記サーバが承認する場合、別のサーバにおいて前記リソースにアクセスすることと
を前記装置に行わせる、装置。

【請求項2】

承認に関連する前記情報は、プロキシ認証が可能にされるかどうかを含む、請求項１に記載の装置。

【請求項3】

前記サーバとの前記相互作用は、前記サーバが、前記クライアントがそうであると主張するエンティティであるかどうかを決定することを可能にする、請求項１に記載の装置。

【請求項4】

前記サーバとの前記相互作用は、前記サーバが、前記クライアントが適切なセキュリティ挙動に従うかどうかを決定することを可能にする、請求項１に記載の装置。

【請求項5】

前記サーバは、承認の前に必要な支払が行われているかどうかをチェックする、請求項１に記載の装置。

【請求項6】

装置による使用のための方法であって、前記装置は、プロセッサとメモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
リソースリストからリソースについての情報を取得することであって、前記情報は、承認に関連し、サポートされるモデルのリストを含む、ことと、
前記情報を評価することと、
サーバが前記装置におけるクライアントが承認されているかどうかを決定することができるように、前記サーバと相互作用することと、
前記サーバが承認する場合、別のサーバにおいて前記リソースにアクセスすることと
を含む方法の機能を果たす、方法。

【請求項7】

承認に関連する前記情報は、プロキシ認証が可能にされるかどうかを含む、請求項６に記載の方法。

【請求項8】

前記サーバとの前記相互作用は、前記サーバが、前記クライアントがそうであると主張するエンティティであるかどうかを決定することを可能にする、請求項６に記載の方法。

【請求項9】

前記サーバとの前記相互作用は、前記サーバが、前記クライアントが適切なセキュリティ挙動に従うかどうかを決定することを可能にする、請求項６に記載の方法。

【請求項10】

前記サーバは、承認の前に必要な支払が行われているかどうかをチェックする、請求項６に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の引用）
本願は、米国仮特許出願第６２／１８８．１５７号（２０１５年７月２日出願）の利益を主張し、上記出願の内容は、それらの全体が記載されている場合のように参照により本明細書に引用される。

【背景技術】

【0002】

より動的な承認を提供するために、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）は、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）フレームワーク（Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ，ＩＥＴＦ−ＲＦＣ ６７４９）を開発した。ＯＡｕｔｈフレームワークは、インターネット内の著名なアイデンティティプロバイダ（例えば、Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ）のうちのいくつかによって広く展開されている、トークンベースのフレームワークである。これは、たとえクライアントがエンティティに関連付けられる証明書を有していないことがあっても、クライアントがそのエンティティによってホストされるリソースにアクセスすることを可能にする。クライアントのアイデンティティプロバイダとリソースをホストするエンティティとの間の静的に事前構成された信頼関係が、クライアントを承認するために活用される。

【0003】

ＯＡｕｔｈは、人間の関与が概して仮定される、インターネットベースの使用事例からの要件に基づいて開発されている。加えて、リソースにアクセスするデバイスは、計算、メモリ、またはバッテリ等のデバイス特定の制約を有していないこともある。ＩＥＴＦの制約された環境のための認証および承認（ＡＣＥ）作業グループは、ＯＡｕｔｈの動的性を利用するが、同時にそれをマシンツーマシン（Ｍ２Ｍ）通信／モノのインターネット（ＩｏＴ）システムの必要性に合わせることによって、規格およびソリューションを開発しようとしてきた。種々の候補承認モデルが、参考文献「Ｃｏｍｐａｒｉｓｏｎ ｏｆ ｄｉｆｆｅｒｅｎｔ ｐｒｏｐｏｓａｌｓ ｆｏｒ ＡＣＥ」、「Ｄｅｌｅｇａｔｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ（ＤＣＡＦ）」、および「Ｄｅｌｅｇａｔｅｄ ＣｏＡＰ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ（ＤＣＡＦ）」で研究ならびに比較されている。そのような候補承認モデルは、以下で議論される。

【0004】

情報セキュリティでは、アクセス制御は、エンティティ（人間、アプリケーション、またはハードウェア）が１つのデータもしくは情報にアクセスすることを制限するプロセスである。手短に言えば、「オブジェクト」にアクセスすることから「対象」を制御するプロセスである。概して、アクセス制御は、アクセス制御リスト（ＡＣＬ）としても公知である堅固な静的テーブルを使用して行われ、テーブルには、対象がリストの一員であり、対象がオブジェクトに行い得る動作が明示的に記述されている。一時的アクセスは殆ど提供されず、提供されたとしても、他の管理ドメインに属したリソース／データまで至らなかった。役割ベースのアクセス機構等の対象およびオブジェクトのクラスは、ある程度の融通性を提供したが、ドメインに属する種々のエンティティからのユーザアプリケーションがシームレスな様式で他のドメインからのアプリケーションと相互作用することができる動的ウェブ環境のために要求される融通性を提供しない。

【0005】

トークンベースのアクセス機構は、より融通性のある承認機構を提供し、リソース所有者は、ある持続時間にわたってリソース所有者の証明書を公開することなく、オブジェクトへの一時的アクセスをエンティティ（対象）に提供し得る。ＯＡｕｔｈは、１つのそのような広く展開されている承認フレームワークである。

【0006】

ＯＡｕｔｈフレームワークは、信頼される第三者によって提供されるサービスを使用することによって、クライアントが、リソース所有者から間接的にサービス／リソースへのアクセスを取得することを可能にするための機構を説明する。クライアントは、限定された時間量にわたってリソースにアクセスするために承認され得るか、またはアクセスは、ある時間量後に無効にされ得る。リソース所有者は、クライアントにそれ自身の証明書を提供する必要はないが、クライアントは、リソースへのアクセスを取得するための一時的証明書をプロビジョニングされる。信頼される第三者は、クライアントがリソースへのアクセスを取得することを可能にする。加えて、クライアントは、完全なリソースにアクセスすることを制約され得、信頼される第三者によって、その一部にアクセスするためにのみ承認され得る。

【0007】

承認層は、クライアント１０２の役割とリソース所有者１０４の役割とを分離する。リソース所有者１０４は、承認許可をクライアント１０２に発行し得る。クライアント１０２は、承認サーバ（ＡＳ）１０６から承認トークン（ＡＴ）の形態で承認を取得する。ＡＴは、リソース所有者（ＲＯ）１０４の承認に基づいてＡＳ１０６によって発行される。クライアントは、リソースへのアクセスを取得するためにＡＴを使用する。プロトコルによって定義される４つの主要な役割は、以下である。
● リソース所有者（ＲＯ）１０４
● リソースサーバ（ＲＳ）１０８
● クライアント１０２
● 承認サーバ（ＡＳ）１０６
（ＯＡＵＴＨプロトコルフローおよび動的承認モデル）
図１のステップ１では、クライアント１０２は、ＲＯ１０４から承認許可を要求する。クライアント１０２による要求は、ＲＯ１０４に直接行われるか、またはＡＳ１０６を介して間接的に行われることができる。

【0008】

図１のステップ２では、クライアント１０２は、ＲＯ１０４から承認許可を受信する。ＲＯ１０４は、いくつかの手段を使用して許可を提供し得る。許可タイプは、承認コード、暗示的手段の使用、リソース所有者のパスワード証明書、およびクライアント証明書であり得る。

【0009】

図１のステップ３では、クライアント１０２は、ＲＯから取得された承認許可を提示した後、ＡＳ１０６からアクセストークンを取得することを要求する。クライアント１０２とＡＳ１０６とは、ＡＴ要求プロセスの一部として互いを認証し得る。

【0010】

図１のステップ４では、ＡＳ１０６は、承認許可を検証した後、続いて、随意であり得る、クライアント１０２を認証した後、ＡＴをクライアント１０２に発行する。

【0011】

図１のステップ５では、クライアント１０２は、ＡＴをＲＳに提示することによって、保護されたリソースへのアクセスを要求する。

【0012】

図１のステップ６では、ＲＳ１０８は、ＡＴの正当性を検査し、それが正当と見なされる場合、クライアント１０２にリソースへのアクセスを提供する。

【0013】

異なる承認モデルのハイレベル説明が、図２−６で提供される。

【0014】

ＰＵＳＨメッセージングモデルが、図２に関して説明される。

【0015】

図２のステップ１では、クライアント１０２は、ＲＳ上に位置するリソースへのアクセスのために、ＡＳ１０６からＡＴを要求する。

【0016】

図２のステップ２では、ＡＳ１０６は、ＡＴをクライアント１０２に送信する。クライアント１０２およびＡＳ１０６は、ＡＴがクライアント１０２に送信される前に、互いに相互認証していることもある。ＡＴは、セキュアな接続を経由して送信され得る。

【0017】

図２のステップ３では、クライアント１０２は、リソースアクセス要求を使用して、ＡＴをＲＳ１０６に送信する。

【0018】

図２のステップ４では、ＲＳ１０８は、ＡＴを検証し、リソースアクセス応答をクライアント１０２に返す。

【0019】

ＰＵＬＬモデルでは、全ての相互作用は、ＲＳ１０８を介して行われる。ＰＵＬＬモデルは、一般的サービスアクセスプロセス（例えば、ＷｉＦｉアクセス要求）に従う。これは、ＲＳ１０８が制約される場合、あまり好適ではないこともある。図３のメッセージング詳細が、以下に提供される。

【0020】

図３のステップ１では、クライアント１０２は、ＲＳ１０８上に位置するリソースにアクセスしようとする。

【0021】

図３のステップ２では、ＲＳ１０８は、ＡＳ１０６と通信し、クライアント１０２の承認を要求する。ＲＳ１０８は、ＡＳ１０６と同一の管理ドメインに属し得るか、またはＡＳと強固な信頼関係を有し得る。

【0022】

図３のステップ３では、ＡＳ１０６は、承認を許可または拒否する。ＡＳ１０６は、クライアント１０２と認証を行い得る。

【0023】

図３のステップ４では、ＡＳからの応答に基づいて、ＲＳ１０８は、リソースへのアクセスを許可または拒否する。

【0024】

エージェントモデルでは、クライアント１０２は、ＡＳ１０６を用いてリソースへのアクセスを要求する。クライアント１０２は、それ自体とＡＳ１０６との間に強固な信頼関係を有することが仮定される。ＡＳ１０６は、クライアント１０２のためのアイデンティティプロバイダであり得る。メッセージング詳細が、以下に提供される。

【0025】

図４のステップ１では、クライアント１０２は、リソースアクセス要求をＡＳに転送する。

【0026】

図４のステップ２では、ＡＳ１０６は、クライアント１０２のアクセス権をチェックし、次いで、リソースアクセス要求をＲＳ１０８に送信する。ＡＳ１０６は、ＲＳへのその要求内にＡＴを含む。

【0027】

図４のステップ３では、ＲＳ１０８は、ＡＴを検証し、次いで、リソースを含むリソースアクセス応答でＡＳに応答する。

【0028】

図４のステップ４では、ＡＳ１０６は、応答をクライアント１０２に転送する。

【0029】

ＰＵＳＨ確認モデルが、図５に図示され、メッセージング詳細が、以下に提供される。

【0030】

図５のステップ１では、クライアント１０２は、ＡＳからＡＴを取得するための要求を送信する。

【0031】

図５のステップ２では、ＡＳ１０６は、クライアント１０２との随意の認証プロセス後、ＡＴ識別子をクライアント１０２に送信する。

【0032】

図５のステップ３では、クライアント１０２は、ＡＴ識別子をＲＳ１０８に送信する。

【0033】

図５のステップ４では、ＲＳ１０８は、ＡＳ１０６からＡＴを取得するために、ＡＴ識別子をＡＳにサブミットする。

【0034】

図５のステップ５では、ＡＳ１０６は、ＡＴ識別子をチェックし、関連付けられるＡＴでＲＳ１０８に応答する。

【0035】

図５のステップ６では、ＲＳ１０８は、ＡＴを検証し、次いで、リソースを伴う応答をクライアント１０２に送信する。

【0036】

間接ＰＵＳＨモデルが、図６に図示され、メッセージング詳細が、以下に提供される。

【0037】

図６のステップ１では、クライアント１０２は、特定のリソースに対する承認要求をＡＳ１０６に送信する。

【0038】

図６のステップ２では、ＡＳ１０６は、要求を検証し、ＡＴをＲＳ１０８に送信する。

【0039】

図６のステップ３では、ＲＳ１０８は、ＡＴを記憶し、応答をＡＳに送信する。

【0040】

図６のステップ４では、ＡＳ１０６は、承認応答をクライアント１０２に返送する。

【0041】

図６のステップ５では、クライアント１０２は、ＡＴ識別子を含み得るリソースアクセス要求をＲＳ１０８に送信する。

【0042】

図６のステップ６では、ＲＳ１０８は、要求およびＡＴ識別子を検証し、次いで、リソースでクライアント１０２に応答する。

【0043】

クライアント観点からの種々のモデルの簡潔な比較が、表１で提供される。クライアントメッセージング観点（メッセージの数および可能なプロトコルサポート）から、ＰＵＳＨモデルが、最高オーバーヘッド影響を及ぼす一方、ＰＵＬＬおよびエージェントモデルは、制約されたクライアントにより少ない影響を及ぼすことが観察され得る。

【0044】

【表1】

【0045】

ＲＳ観点からの種々のモデルの簡潔な比較が、表２で提供される。ＰＵＳＨモデルは、ＲＳ１０８に少ない影響を及ぼすが、最高の融通性も提供し、したがって、制約されたＲＳ１０８によって好まれ得る。

【0046】

【表2】

【0047】

図７を参照すると、委託ＣｏＡＰ認証および承認フレームワーク（ＤＣＡＦ）７００は、クライアント承認マネージャ（ＣＡＭ）７０２およびＤＣＡＦ−サーバ承認マネージャ（Ｄ−ＳＡＭ）７０４を用いて、クライアント１０２の委託認証を提供する。クライアント１０２は、より高価な認証および承認プロセスをＣＡＭ７０２に委託し得る。ＣＡＭ７０２は、Ｄ−ＳＡＭ７０４との信頼関係を有し、ＣＡＭ７０２は、Ｄ−ＳＡＭ７０４を用いて、クライアント１０２に代わって認証を行う。ＤＣＡＦプロシージャは、任意の関連モデルに適用可能であり得る。メッセージングフローが、以下に提供される。

【0048】

図７のステップ１では、クライアント１０２は、リソースへのアクセスを要求し、ＲＳ１０８は、次いで、承認を行うようにクライアント１０２に要求する。

【0049】

図７のステップ２では、クライアント１０２は、承認プロセスをＣＡＭ７０２に委託する。

【0050】

図７のステップ３では、ＣＡＭ７０２は、Ｄ−ＳＡＭ７０４を用いて承認プロセスを開始し、クライアント１０２に代わって承認を行う。

【発明の概要】

【発明が解決しようとする課題】

【0051】

上で説明される種々のＯＡＵＴＨベースのモデルは、クライアントならびにＲＳの両方によって使用され得る融通性を提供することができる。しかしながら、ＲＳまたはクライアントのいずれかが適切なモデルを選択し、ＩｏＴ環境に好適である、より動的な動作プロシージャを作成するための機構を提供する現在の包括的なフレームワークがない。

【課題を解決するための手段】

【0052】

以下は、リソースに関連付けられるセキュリティ値に基づいて動的承認をリソースに提供するフレームワークおよび機構を説明する。セキュリティ分類プロセス、および分類／要件およびセキュリティ機構のリスティングも説明される。制約されたクライアントならびにリソースサーバを扱う際の正しいモデル、適切な査定、および融通性も説明される。ハイレベル革新的発想のうちのいくつかが、取り込まれている。

【0053】

セキュリティ分類プロセス（ＳＣＰ）：ＳＣＰは、セキュリティ値の観点から、未加工データ、未加工データから抽出される情報、コンテンツまたはコードを分類するプロセスである。ＳＣＰ中、リソースホスティングエンティティ（ＲＨＥ）は、セキュリティ観点から、どのようにしてデータ／情報がハンドリングされなければならないかを決定する。分類プロセスの結果として、セキュリティ値（ＳＶ）／セキュリティクラス（ＳＣ）が、データ／情報に割り当てられる。分類は、経時的に変化し得、さらに、コンテキスト情報（例えば、場所、計画された使用法等）が、リソースに関連付けられるセキュリティ値を決定し得る。

【0054】

セキュリティ達成能力決定プロセス（ＳＡＤＰ）：割り当てられているＳＶ／ＳＣに基づいて、ＲＨＥは、セキュリティ要件と、どのようにしてセキュリティ要件が達成され得るかとを決定し得る。ＲＨＥは、殆どの場合、リソース所有者と共に、セキュリティ要件を満たし、それによって、データに関連付けられるＳＶ／ＳＣを満たすために要求され得る詳細なセキュリティ機構を決定する。
○ セキュリティ達成能力機構（ＳＡＭ）と呼ばれる、セキュリティ機構の詳細かつ粒度の細かいリストが、定義される。
○ ＳＡＭは、（セキュリティ関連ではないこともある）承認するために融通性のあるアプローチについての情報も提供する：プロキシ認証およびプロキシ承認、サポートされる承認モデル（ＰＵＳＨ、ＰＵＬＬ、間接ＰＵＳＨ等）。

【0055】

セキュリティ達成能力リスティングプロセス（ＳＡＬＰ）：ＳＡＬＰ中、ＲＨＥは、リソースリスティングエンティティ（ＲＬＥ）上に、ＲＨＥ上のリソースの場所のユーザリソース識別子（ＵＲＩ）、リソースに関連付けられるＳＡＭ、随意に、リソースに関連付けられるデジタル証明をアップロードする。

【0056】

ＳＡＭ査定プロセス（ＳＡＭＡＰ）：このプロセス中、クライアントは、発見プロセス（ＤＰ）の一部として提供されたＳＡＭを満たすために実施されなければならないセキュリティ機構を評価する。クライアントは、その内側で定義される１つ以上の機構を使用して、要件を満たすためにＳＡＭに基づいて適切な措置を講じる。
○ クライアントが、リソースに関連付けられるセキュリティレベルについて決定する
○ クライアントが、ＳＡＭで提供される、サポートされたモデルの可能なリストから、その必要性に最も良く適する承認モデルについて決定する
○ （ＰＵＳＨモデルの場合）承認のためにコンタクトされる必要があるＡＳ
○ プロキシ認証／読み出しを行う能力
セキュリティ達成能力有効化プロセス（ＳＡＥＰ）：ＲＬＥから取得されるＳＡＭに基づいて、クライアントは、ガイドラインとしてＳＡＭを使用して、要件を満たすためにセキュリティプロシージャを開始し得る。クライアントは、認証、承認、支払を開始し、信頼される第三者機能またはエンティティであり得るセキュリティ達成能力イネーブラ機能（ＳＡＥＦ）から、セキュアな挙動のアサーションを取得することを要求され得る。
○ ＳＡＥＦは、実施されなければならない査定のタイプを決定する
○ 編成され、コンタクトされなければならない機能
○ 生成されるトークンのタイプ
プロキシ認証検証プロセスおよび適切なトークンの生成
リソースアクセスプロセス（ＲＡＰ）：クライアントは、信頼性および／または支払情報を明らかにするアサーションもしくはトークンをＲＨＥに提示する。ＲＨＥは、クライアントがＳＡＭを満たすセキュリティ機構を行ったかどうかを検証し、該当する場合、同意された条件に基づいてデータへのアクセスを承認する。ＲＡＰプロセスは、以下のためのサポートを含むであろう。
○ ＳＡＭ内の全ての要件が達成されたかどうかを検証する能力
○ ＳＡＭ要件の一部のみが達成された場合、リソースへの制限されたアクセスを提供する能力
○ 異なるタイプのトークン（例えば、プロキシ認証トークン）の検証
○ プロキシ読み出しモードでリソースへのアクセスを提供する能力
○ トークン、トークン使用法、およびトークンに関連付けられる有効性を追跡する能力
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

【図面の簡単な説明】

【0057】

より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明からもたらされ得る。

【図1】図１は、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡＵＴＨ）プロトコルフローを図示する略図である。

【図2】図２は、ＰＵＳＨモデルを図示する略図である。

【図3】図３は、ＰＵＬＬモデルを図示する略図である。

【図4】図４は、エージェントモデルを図示する略図である。

【図5】図５は、ＰＵＳＨ確認モデルを図示する略図である。

【図6】図６は、間接ＰＵＳＨモデルを図示する略図である。

【図7】図７は、委託制約アプリケーションプロトコル（ＣｏＡＰ）承認フレームワークを図示する略図である。

【図8】図８は、リソースサーバを用いたリソースアクセスを図示する略図である。

【図9】図９は、プロキシ認証およびプロキシ読み出しを描写する、略図である。

【図10】図１０は、動的承認のための能力を提供することに関与するプロセスの略図である。

【図11】図１１は、セキュリティ分類プロセスを図示する略図である。

【図12】図１２は、リソースおよびセキュリティ達成能力公開プロセスを図示する略図である。

【図13】図１３は、リソースリスティングエンティティ（ＲＬＥ）上へのリソースのリスティングのためのメッセージ交換を描写する、略図である。

【図14】図１４は、異なるＲＬＥ上で公開されるリソースおよびセキュリティリスティングを図示する略図である。

【図15】図１５は、公開されたリソースおよびセキュリティ達成能力機構（ＳＡＭ）を図示する略図である。

【図16】図１６は、単純なリソース発見プロセスを図示する略図である。

【図17】図１７は、リソースおよびクライアント能力のクラスの発見を図示する略図である。

【図18】図１８は、クライアントによるＳＡＭの処理を説明するフローチャートである。

【図19】図１９は、例示的支払トークンを図示する略図である。

【図20】図２０は、セキュリティ達成能力査定プロセスのフローチャートである。

【図21】図２１は、（セキュリティ達成能力有効化プロセス）ＳＡＥＰに関連付けられるハイレベルコールフローである。

【図22】図２２は、リソースホスティングエンティティ（ＲＨＥ）におけるリソースアクセスプロシージャのためのフローチャートである。

【図23】図２３は、リソースアクセスプロセス（ＲＡＰ）を描写するコールフローである。

【図24】図２４は、リソースアクセスに関与するステップを図示する略図である。

【図25】図２５は、詳細なリソースアクセス機構を図示する略図である。

【図26】図２６は、詳細なリソースアクセス−プロキシ認証を図示する略図である。

【図27】図２７は、プロキシ読み出しプロセスを図示する略図である。

【図28】図２８は、リソースに関連付けられるＳＡＭの登録をサポートするリソースディレクトリ（ＲＤ）拡張を図示する略図である。

【図29】図２９は、ＲＨＥ／ＳＣＦにおいて種々のセキュリティ関連パラメータを構成するために使用されるグラフィカルユーザインターフェース（ＧＵＩ）を図示する略図である。

【図30】図３０は、ＡＳにおいて組み込まれ得るＧＵＩを図示する略図である。

【図31A】図３１Ａは、ＩｏＴイベント管理システムおよび方法の１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）もしくはモノのインターネット（ＩｏＴ）通信システムの略図である。

【図31B】図３１Ｂは、図３１Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。

【図31C】図３１Ｃは、図３１Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。

【図31D】図３１Ｄは、図３１Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

【発明を実施するための形態】

【0058】

ＩｏＴ／Ｍ２Ｍセンサおよびアプリケーションによって生成され得るデータ（リソース）のアクセス制御を管理することは、煩雑となっており、現在の静的アクセス制御機構は、そのようなアプリケーションに適していない。それらは、複数の理由により、好適ではない。

【0059】

クライアントは、ある期間にわたってリソースアクセスを要求し得る。アクセスが許可されると、次いで、アクセスのための有効性は、１時間または数分さえも持続し得る。

【0060】

リソース所有者とクライアントとは、事前の関係を有していないこともある。

【0061】

リソース／リソース所有者は、クライアントとパスワードを共有する必要がなく、リソースへのアクセスを要求し、それによって、高価で、ある時はセキュアではないパスワード管理プロシージャを回避する。

【0062】

ＩｏＴシステムの動的性および特有の要件は、制御された企業様環境のために概して開発されている機構を使用して満たされることができず、企業様環境において、リソースアクセスは、中央制御され、動的アクセスのための要件が殆ど必要とされない。クライアントおよびリソースサーバは、概して、制約されていないと見なされ、実際に、ＩｏＴクライアントおよびＲＳと異なり、非常に高い計算、メモリ、およびバッテリ能力を有する。

【0063】

（使用事例１）
Ｍｅｇｈａｎは、夕食に出かけることを望み、駐車係サービスを使用する駐車場建物に自分の車を駐車することを望む。夜のある時点で、駐車場の不足に起因して、駐車係が駐車スペースを最適化しようとし、Ｍｅｇｈａｎの車の後ろに駐車されている車を取り出し、それを出すことを望む。Ｍｅｇｈａｎは、遠隔で車を開けて始動させる能力を有し、したがって、自分の車の鍵またはアクセスコードを駐車係に提供しなかった。駐車係は、ドアハンドル上に位置するクイックレスポンス（ＱＲ）コードをスキャンすることによって、Ｍｅｇｈａｎの車を開けようとする。ＱＲコード（登録商標）は、アプリケーションを駐車係のデバイス上で起動し、アプリケーションは、ブラウザ／アプリケーションを、アクセス制御機能を管理するサーバに向かわせ、サーバは、次いで、Ｍｅｇｈａｎのスマートフォンへの通知をトリガする。Ｍｅｇｈａｎは、通知を見ることも、見ないこともあり、Ｍｅｇｈａｎが通知を見た場合、承認プロセスをトリガし、駐車係は、承認サーバを用いて認証／承認を行うように要求される。Ｍｅｇｈａｎが通知を見ない場合、駐車係、駐車係のデバイス、場所情報等の認証および査定のより精巧なプロセスが実施される。全てのチェックがパスする場合、駐車係は、ＡＳ１０６によって承認トークン（ＡＴ）を提供される。図８には、ＲＳ１０８が、車上に位置し、駐車係が、クライアント／クライアントアプリケーションとして表され、ＡＳ１０６が、駐車係の真正性を保証することができるエンティティであるシナリオの概念図が図示されている。駐車係のデバイス上のアプリケーションは、ＡＴを車上に位置するＲＳ１０８に提示する。ＲＳ１０８は、ＡＴを検証し、次いで、車を解錠し、始動させる。車上のアプリケーションは、走行距離計読み取り値ならびに車からのビデオをサーバ上にアップロードし得る。ＡＴは、その後に車のエンジンが動作停止し、ドアを自己施錠するであろう、有効存続時間を有する。ＡＴは、全てのコンテキスト情報がアクセス要求に一致する場合のみにＲＳ１０８によって処理され得る。Ｍｅｇｈａｎは、車が駐車されてスイッチをオフにされ、走行距離計読み取り値の指示ならびにビデオへのリンクがサーバ上に記憶されると、通知を入手する。現在の機構は、以下を提供しない。
● リソース所有者（例えば、Ｍｅｇｈａｎ）がリソースに関連付けられるセキュリティプロファイルを定義するための能力
● 駐車係がアクセスされているリソースに関連付けられるセキュリティ要件を発見する能力
● クライアントがリソースにアクセスすることができるために行われることが期待される詳細なセキュリティ機構を取得するための能力。例えば、認証／承認サーバの場所
● リソース所有者と事前の関係を有していないこともあるクライアントが、管理の関与を伴わずに、シームレスな様式でリソースを取得するための能力。

【0064】

図８に図示される機能性は、以下に説明される図３１Ｃまたは３１Ｄに図示されるもののうちの１つ等の無線デバイスもしくは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得ることが理解される。図８に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。

【0065】

（使用事例２）
建物の火災は、消防署に消防士を建物に送らせる。本使用事例のための概念的シナリオが、図９に図示されている。消防署長は、通常時に制限されたエリアにアクセスするために承認されていないので、建物の「制限アクセスエリア」に進入するためのアクセス承認要求を開始する。制限されたエリア自体は、火災の影響を受けていないが、しかしながら、建物のための制御センターとして動作し、非常に強固なアクセス制御プロシージャを要求する。迅速な措置を提供するが、同時にリソース（ここでは「制限アクセスエリア」である）に関連付けられるセキュリティ要件を維持するために、消防署長は、自分のチームのコアグループのみがエリアに新入することを求め得るが、同時に、アクセスプロシージャが迅速に行われることを望む。加えて、グループメンバは、制約され得るデバイスを有し得る。消防署長は、グループメンバのリストを使用してプロキシ承認要求を要求し、リストは、署長のデバイス内のローカルに記憶されたファイルから引き出され、ＲＳ１０８に送信される。リストは、グループメンバについての情報、デバイスｉｄ（例えば、インターネットプロトコル（ＩＰ）アドレス）、および、随意に、リソースへのアクセスを要求している一意のアプリケーションｉｄを含む。要求されるアクセスが、高セキュリティアセットと見なされるリソースに対するものであるので、署長は、自分の真正性の高レベルの確実性を提供することを要求され得、多因子認証（例えば、自分のスマートフォン上のセンサ１０８を使用する指紋認証、および加入者識別モジュール（ＳＩＭ）またはデバイス証明等を用いたスマートフォン自体の検証）を提供することを要求される。建物所有者／管理および消防署によって互いに信頼されている承認サーバ（ＡＳ）は、消防署長を承認し、消防署長（そのデバイス上のアプリケーションに）ならびにそのチームにトークンを発行する。各トークンは、一意のｉｄを有し、承認が有効であり得る持続時間に対する制限を有する。トークンが無効になると、クライアントは、「制限されたエリア」ならびにエリア内に位置するアセットにアクセスするためにそれらを使用することができない。火災の重大性、存在するクライアントの数、場所情報、アセット値等のコンテキスト情報が、トークンの数および有効性を決定することにおいて使用され得る。

【0066】

わずかに変化した使用事例は、プロキシ承認と、プロキシリソースアクセス（プロキシ読み出し）プロセスとを伴い得、単一のトークンのみが消防署長に発行されるが、消防署長は、有限数のクライアントとそれを共有することを可能にされ、その有限数は、ポリシ、アセット値、消防署長の信頼性、そのデバイス等を考慮してＡＳ１０６によって決定される。この使用事例は、クライアントデバイスが制約され得るか、またはシナリオが制約されたＲＳ１０８を伴う場合、特に適用可能であり得る。クライアントおよびＲＳ１０８におけるメッセージングおよび処理要件は、大いに低減させられ得る。

【0067】

現在の機構は、以下を提供しない。
● 消防署長のアプリケーションまたはデバイスが自分のグループに代わってプロキシ承認を行うことができる能力。クライアント観点から処理およびメッセージングを低減させ、したがって、制約されたクライアントに好適であり得る。
● 消防署長のアプリケーションまたはデバイスが自分のグループメンバに代わってプロキシ読み出しを行う能力。クライアントおよびＲＳ１０８における処理ならびにメッセージングを低減させ、したがって、制約されたＲＳ１０８およびクライアントに好適である。
● 署長のデバイスまたはアプリケーションが、ＡＳ１０６がプロキシ承認を行う機構を提供することを発見する能力
● 署長のデバイスまたはアプリケーションが、リソースがプロキシ読み出しを使用してアクセスされ得るかどうかを発見する能力
ある他のシナリオでは、リソースは、購入され（認証は随意であり得る）、家族のデバイス間で共有され得る。そのような場合、リソース（アセット）は、共有トークン、または別個かつ一意のトークンを使用して、家族の各一員によってアクセスされ得る。現在の機構は、以下を提供しない。
● リソースを購入し、承認フレームワークの一部としてそれを統合する能力
● 匿名で購入を行い、したがって、プライバシーを保つ能力。一部のリソース所有者は、金銭的利益のみに興味があり、したがって、識別／認証について関心を持たないこともある。

【0068】

現在のアクセス制御および承認機構の欠点は、それらが制約されていないデバイスを使用して制御およびアクセスされるある固定され、中央制御されたアクセス制御システムを仮定することである。しかしながら、ＩｏＴの場合、アクセス制御システムは、分散され、多様なリソース所有者によって制御され得、それと同時に、デバイスは、制約され得る。リソース所有者は、集中型の融通性のないアクセス制御プロシージャに依拠することなく、それらのリソースへのアクセスを提供し得、より開放した様式でそれらを収益化することができる。要約すると、本願で対処されている問題は、以下を含む。
１． リソースへのアクセスは、事前の信頼関係で中央制御されており、したがって、事前に確立された信頼関係が存在しないこともあるＩｏＴシステム内で要求されるような動的アクセスのための機構を提供しない。
２． 制約されたエンティティへのリソースアクセスケータリングのための断片的ソリューションは存在するが、しかしながら、完全に開発された動的承認フレームワークがない。
３． トランザクションの支払および匿名性を統合する能力等の他の特徴が、承認のためのソリューションを開発するときに考慮されていない。

【0069】

完全な動的承認フレームワークを提供することへの一般的なハイレベルアプローチは、以下を行う能力を含み得る。
● セキュリティ観点からデータを取得し、分類すること
● エンティティがセキュリティ分類を達成するために行う必要があり得る機構を決定すること
● 関連付けられるセキュリティ要件／機構とともに、リスティングまたはディレクトリサービスを使用してデータをリストアップ／公開すること
● データにアクセスすることを望むクライアントが、リスティングサービスを使用し、リソースの場所（リソースをホストするサーバのＵＲＩ）、リソースにアクセスすることができるために実施されなければならないセキュリティ機構についての情報を取得すること
● クライアント１０２、クライアントのデバイス、クライアントアプリケーション、クライアントプラットフォーム、セキュリティプロトコルのためのサポート、支払等の複数の査定に基づいて、信頼される第三者から、（例えば、トークンを用いて）必要な承認を取得すること
● クライアント１０２が承認されると、クライアント１０２がエンティティをホストするリソースに承認の証拠（トークン）を提示すること：承認がリソースに関連付けられるセキュリティ（随意に、支払）要件を満たす場合、クライアント１０２がリソースへのアクセスを提供されること。

【0070】

図９に図示される機能性は、以下に説明される図３１Ｃまたは３１Ｄに図示されるもののうちの１つ等の無線デバイスもしくは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。図９に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。

【0071】

プロシージャは、図１０で描写されるような以下のプロセスおよび相互作用に分類され得る。ユーザ機器上またはサーバ上でホストされる他のアプリケーションとともにエンティティ上に常駐するソフトウェアであり得る関連機能のリストが、以下に列挙される。これらの機能は、専用ハードウェアエンティティ上に常駐し得、したがって、本願の全体を通して、機能およびエンティティという用語は、同義的に使用され得る。動的承認を提供するために要求されるコア機能／エンティティの要約が、以下に列挙される。

【0072】

データソース（ＤＳ）１００２：ＤＳ１００２は、データまたは情報の任意のソースであり得、センサデータを収集するセンサまたはエンティティ、もしくは未加工データから情報を作成することが可能である任意のエンティティを含み得る。データは、最も未加工の形態（例えば、温度読み取り値、他のセンサ読み取り値等）であり得るか、またはそれに関連付けられる追加のメタデータを伴う未加工データであり得るか、もしくはデータの集合であり得る。データは、未加工データから抽出されたある情報でもあり得る。データまたは情報は、機械実行可能コンテンツ（例えば、コンピュータプログラム、バイナリコード、コンパイルまたは翻訳されていることもある実行可能機械／アセンブリコード、コンピュータプログラムスクリプト等）、コンピュータ関連構成パラメータ、動作ポリシ（例えば、セキュリティポリシ）または再生可能コンテンツ（例えば、ビデオ、オーディオ等）、文書、ｘｌｓシート、またはある通貨、（例えば、国家または会社の秘密に関する）方略、もしくは知的価値を有し得るあらゆるもの等のコンテンツでもあり得る。以後、残りの文書に関して、データまたは情報もしくはコンテンツは、概して、リソース（Ｒ）と称されるであろう。Ｒは、大域的に一意のリソース識別子（ＵＲＩ）によって識別され得るか、またはローカルで識別可能であり得る。ＵＲＩは、リソースがホストされる場所の物理的場所を提供し得る。随意に、リソースは、一意のデジタル証明（Ｃｅｒｔ）に関連付けられ得る。

【0073】

クライアント（Ｃ）１０２：クライアント１０２は、ユーザのデバイス上に常駐するアプリケーション、マシンまたは専用ハードウェア上に常駐するアプリケーション、もしくはクラウドベースのアプリケーションであり得る。クライアント１０２は、プラットフォーム内で、または分散様式で一緒に動作するアプリケーションのグループの一部でもあり得る。クライアント１０２は、人間によって制御されることも、されないこともある。クライアント１０２は、概して、リソースにアクセスするために要求を開始する。クライアント１０２がマシンによって制御され、動作させられる場合において、要求をトリガする開始が、マシンによって行われる。Ｒにアクセスするためにクライアント１０２が要求を送信するためのトリガが、ユーザ／人間によって、マシンまたは他のアプリケーションによって、もしくは他のクライアント１０２によって開始され得る。

【0074】

リソースホスティングエンティティ（ＲＨＥ）１００４：ＲＨＥ１００４は、リソースをホストし、好ましくは、クライアント１０２がＲＨＥ上でホストされるＲにアクセスすることを望むときにアクセス制御チェックを行い得る。ＲＨＥは、クライアント１０２がＲにアクセスするために承認されることができるために、セキュリティ機構を定義し、説明する責任があり得る。ＲＨＥ１００４は、サーバファームの一部であり、大域的に分散され、種々のサーバシステム上に実装され得るか、または仮想マシンを使用して実装され得る。ＩｏＴシナリオでは、ＲＨＥ１００４が制約されたデバイス上でホストされることが可能であり得る。多くの場合、ＤＳ１００２およびＲＨＥ１００４は両方とも、同一のエンティティ上でホストされ得る。ＲＨＥは、Ｒに関連付けられるリソース識別子も管理し得、共同設置されて自己署名され得る証明機関（ＣＡ）と共に、または第三者ＣＡサービスを使用して、リソースに関連付けられるデジタル証明を提供する責任もあり得る。リソースの組は、代替として、証明内に列挙される識別が検証されることができるならば、単一の証明を共有し得る。

【0075】

セキュリティ分類機能（ＳＣＦ）１００６：ＳＣＦ１００６は、ＤＳ１００２またはＲＨＥ１００４の一部として常駐し得るか、もしくは信頼されるセキュリティサービスエンティティ／ドメイン上に常駐する独立セキュリティ機能であり得る。信頼される第三者は、サービスとしてのセキュリティ分類（ＳＣａａＳ）を提供し得る。ＳＣＦ１００６の役割は、リソースのセキュリティ要件を査定し、そのリソースに関連付けられるセキュリティ値（ＳＶ）またはセキュリティクラス（ＳＣ）を割り当てることである。

【0076】

リソースリスティングエンティティ（ＲＬＥ）１００８：ＲＬＥ１００８は、Ｒに関する情報が発見可能であり得る場所である。ＲＬＥ１００８は、Ｒの場所（例えば、ＵＲＩ）を列挙する責任がある。リストは、異なるＲＨＥからアクセス可能であり得る、同一のＲのための複数のリストを有し得る。さらに、Ｒは、サブコンポーネントで構成され得る。各サブコンポーネントが、異なるＲＨＥ上でホストされることが可能であり得る。加えて、Ｒにアクセスすることができるために要求されるセキュリティ機構は、随意に、Ｒに関連付けられるデジタル証明と一緒に列挙される。

【0077】

セキュリティ達成能力（Ａｃｈｉｅｖａｂｉｌｉｔｙ）有効化機能（ＳＡＥＦ）１０１０：この機能は、クライアント１０２機能が、セキュリティ達成能力機構（ＳＡＭ）内で規定されるような要件を、その内側で説明される機構を使用して達成できることを可能にすることに責任がある。ＳＡＥＦ１０１０は、ＲＨＥ１００４と同一の管理ドメインに属し得るか、またはサービスとしてのセキュリティ（ＳａａＳ）を提供する別個の信頼される第三者エンティティであり得る。ＳＡＥＦ１０１０は、認証、承認、セキュリティ妥当性検査、および試験サービスを提供するための能力を保有し得る。ＳＡＥＦ１０１０は、随意に、支払機能（ＰＦ）２１０８をホストし得るか、または異なるドメイン内に位置するＰＦと連係して動作し得る。

【0078】

動的承認を行う能力を提供することに関与するプロセスは、以下のプロセスに分類され得る（図１０参照）。

【0079】

図１０のステップ１−データアップロードプロセス（ＤＵＰ）：このプロセスの一部として、センサデータ等のデータソース（ＤＳ）１００２から収集されるデータは、リソースホスティングエンティティ（ＲＨＥ）１００４にアップロードされる。アップロードされるデータは、未加工データ、未加工データから抽出される情報、またはコンテンツであり得る。トランスポート層セキュリティ（ＴＬＳ）またはデータグラムトランスポート層セキュリティ（ＤＴＬＳ）等のプロトコルを使用するセキュア通信チャネルが、データをＲＨＥ１００４上に転送するために使用され得る。あるシナリオでは、ＲＨＥ１００４がＤＳ１００２と共同設置され得ることが想定されることができる。

【0080】

図１０のステップ２−セキュリティ分類プロセス（ＳＣＰ）：データを受信するＲＨＥ１００４は、未加工データをホストし得るか、または、随意に、データからリソースを作成し、未加工データに基づくデータまたは情報のメタデータを作成する。ＳＣＰ中、ＲＨＥ１００４は、セキュリティ観点から、どのようにしてデータ／情報がハンドリングされなければならないかを決定する。分類プロセスの結果として、セキュリティ値（ＳＶ）／セキュリティクラス（ＳＣ）が、データ／情報に割り当てられる。ＳＶ／ＳＣは、セキュリティ観点から、どのようにしてデータが記憶、伝送、および／または消費される必要があるかを決定し得る。加えて、それは、プラットフォーム（例えば、信頼されるコンピューティンググループ（ＴＣＧ）規格に準拠するセキュアなプラットフォームが、プラットフォーム完全性を実証するための信頼されるプラットフォームモジュール（ＴＰＭ）を実装する）、そのプラットフォーム上で消費され得るデータ、そのプラットフォームを用いるエンティティ、期間（持続時間）、場所、データ（リソース）が再分配可能であるかどうか等を規定し得る。ＳＣＰは、セキュリティ分類機能（ＳＣＦ）１００６によって実施され得る。ＳＣＦ１００６は、ＲＨＥ１００４と同一のプラットフォーム内でＲＨＥインフラストラクチャ／ドメインの一部として常駐し得るか、またはＤＳ１００２にさえも常駐し得る。ＳＣＦ１００６がＤＳ１００２ドメインに常駐するとき、次いで、図１０のステップ２は、ＤＵＰが実施される前、ＤＳ１００２によって行われ得る。さらに、ＳＣＰがＤＳ１００２によって実施された場合、ステップ１中、ＤＳ１００２は、データならびにデータに関連付けられるＳＶ／ＳＣの両方をＲＨＥ１００４上にアップロードする。前述のように、ＤＳ１００２、ＳＣＦ１００６、およびＲＨＥ１００４機能は、同一のエンティティ上に常駐し得、そのような場合、ステップ１および２は、内部プロセスとして行われ、種々の機能性間のプロセス間通信を使用して通信される。

【0081】

図１０のステップ３−セキュリティ達成能力決定プロセス（ＳＡＤＰ）：データに割り当てられているＳＶ／ＳＣに基づいて、ＲＨＥ１００４は、単独で、または（運営および管理プロセスによって開始される）他の場所に常駐する機能性を使用して、セキュリティ要件と、セキュリティ要件が達成され得る方法とを決定するプロセスを開始し得る。ＲＨＥ１００４は、セキュリティ要件を満たし、それによって、データに関連付けられるＳＶ／ＳＣを満たすために要求され得る詳細なセキュリティ機構を決定する。我々は、この詳細かつ粒度の細かいセキュリティ機構をセキュリティ達成能力機構（ＳＡＭ）として定義する。

【0082】

図１０のステップ４−セキュリティ達成能力リスティングプロセス（ＳＡＬＰ）：ＳＡＬＰ中、ＲＨＥ１００４は、リソースリスティングエンティティ（ＲＬＥ）１００８上にＳＡＭをアップロードし、ＲＨＥ１００４上に記憶されたデータの場所情報（例えば、ＵＲＩ）を提供する。あるＩｏＴ実装では、ＲＬＥ１００８は、ＲＨＥ１００４と同一のエンティティ上で共同ホストされることが可能であり得る。そのような場合、図１０のステップ４は、プロセス間通信を使用して、エンティティ（ノード）内で内部に行われ得る。

【0083】

図１０のステップ５−発見プロセス（ＤＰ）：このプロセスの一部として、データを発見することを望むクライアント１０２は、リソースリスティングエンティティ（ＲＬＥ）１００８にクエリを行い得る。ＲＬＥ１００８は、概して、いかなるデータ／情報もホストしないが、関連付けられるＳＡＭとともにリソースの場所をリストアップするのみである。ＲＬＥ１００８は、着目データ／リソースの場所を含む応答で発見要求に応答し、ＳＡＭも提供する。ＲＬＥ１００８は、分散され得、複数のエンティティ上でリソースリストをホストし得る。

【0084】

図１０のステップ６−ＳＡＭ査定プロセス（ＳＡＭＡＰ）：このプロセス中、クライアント１０２は、ＤＰの一部として提供されたＳＡＭによって定義される要件／機構を満たすために実施されなければならないセキュリティ機構を評価する。クライアント１０２は、ＳＡＭの要件に準拠するように、それが通信する必要があり得る適切なエンティティ／機能、使用、ダウンロード等されるべきプロトコルを決定する。例として、ＳＡＭに基づいて、クライアント１０２は、サポートされる承認モデル（例えば、ＰＵＳＨ、ＰＵＬＬ等）を決定し、故に、互いに信頼可能（クライアント１０２とＲＨＥ１００４との間）である適切なＡＳ１０６を選択する。クライアント１０２は、それがＤＴＬＳを使用する必要があることも決定し得、したがって、随意に、ＤＴＬＳの最新バージョンをダウンロードしてインストールし得る。別の例は、クライアント１０２が、現在のバッテリリソースに基づいて、それが制約されていることを決定し、したがって、ＳＡＭによってサポートされている場合にＰＵＬＬモデルを選択する場合である。クライアント１０２が、ＳＡＭによってサポートされている場合、ＰＵＬＬモデルと、プロキシ認証およびプロキシ読み出しプロセスとの両方を選択し得ることも可能である。

【0085】

図１０のステップ７−セキュリティ達成能力有効化プロセス（ＳＡＥＰ）：ＲＬＥ１００８から取得されるＳＡＭに基づいて、クライアント１０２は、認証、承認、支払を開始し、セキュリティ達成能力イネーブラ機能（ＳＡＥＦ）１０１０から、セキュアな挙動のアサーションを取得することを要求され得、ＳＡＥＦは、認証、承認、および／または支払機能を果たす信頼される第三者機能もしくはエンティティであり得る。

【0086】

図１０のステップ８−リソースアクセスプロセス（ＲＡＰ）：クライアント１０２は、信頼性および／または支払情報を明らかにするアサーションもしくはトークンをＲＨＥ１００４に提示する。ＲＨＥ１００４は、クライアント１０２がＳＡＭを満たすセキュリティおよび／または支払機構を行ったかどうかを検証し、該当する場合、同意された条件に基づいてデータへのアクセスを承認する。

【0087】

図１０に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１０に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１０に図示されるステップを行う。図１０に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１０に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0088】

（データアップロードプロセス（ＤＵＰ）：）
センサデータ等のデータソース（ＤＳ）１００２から収集されるデータは、リソースホスティングエンティティ（ＲＨＥ）１００４にアップロードされる。アップロードされるデータは、未加工データ、未加工データから抽出される情報、またはコンテンツであり得る。他のＲＨＥ１００４からのデータまたは情報も、分散アクセスを提供するためにアップロードされ得る。セキュア通信チャネル（例えば、ＴＬＳまたはＤＴＬＳ）が、データをＲＨＥ１００４上にアップロードするために使用され得る。ＤＳ１００２は、随意に、ＲＨＥ１００４上にアップロードされる前にリソース（データ／コンテンツ／情報）を分類し得る。

【0089】

（セキュリティ分類機能（ＳＣＦ）１００６）
ＳＣＦ１００６は、Ｒ１１０２に関連付けられる適切なセキュリティ値（ＳＶ）を決定するか、または、おそらくＲ１１０２をセキュリティクラス（ＳＣ）に分類する責任がある。殆どの場合、ＳＣは、国家セキュリティの場合を除いたＲ１１０２に関連付けられる相対金額、評判への影響、またはセキュリティ値を測定すること、もしくはＲ１１０２の侵害の間接的または長期的セキュリティ影響を査定することが困難であり得る他のシナリオに依存し得る。ＳＶは、リソースＲ１１０２上にセキュリティ攻撃があった場合、影響（通貨、評判、国家セキュリティ等）と考えられ得る。そのようなセキュリティ攻撃の例は、適時におけるＲへの承認されたエンティティのアクセスを拒否すること、無承認エンティティへのＲの漏洩、無承認エンティティによるＲの修正、または他の攻撃であり得る。異なる視点から見た場合、それは、機密性、完全性、および利用可能性に関連する攻撃からＲを保護するために費やされなければならない比例値（例えば、金額）である。あまり粒度の細かくないアプローチは、関連付けられるあるＳＣをリソースに割り当てることである。例として、Ｒは、関連付けられるＳＣ＝高、中、または低を有し得る。ＳＣ／ＳＶは、リソースにアクセスすることを望む任意のクライアント１０２のために達成されなければならない関連付けられるセキュリティ要件（ＳＲ）を有し得る。クライアント１０２がＲに行うことを望む動作のタイプに基づいて、Ｒに関連付けられるＳＶ／ＳＣは、リソースを保護するために要求され得るセキュリティ要件の非常に粒度の細かい組に変換され得る。図１１に図示されるように、Ｒ１１０２は、一般的ポリシであり得る、データハンドリングポリシ１１０４と、データ特定のポリシとに基づいて、分類される。一般的データハンドリングポリシの例は、未知の商業的供給源が起源である任意のデータが、「低」として分類され得る一方、政府機関が起源である同一タイプのデータは、「中」または「高」と見なされ得ることを伴うであろう。データ特定のポリシは、データのタイプ（例えば、家族の個人情報）によって決定される。

【0090】

図１１に図示される機能性は、以下に説明される図３１Ｃまたは３１Ｄに図示されるもののうちの１つ等の無線デバイスもしくは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得ることが理解される。図１１に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。

【0091】

表３は、例示的ＳＣを描写する。

【0092】

【表3】

【0093】

（セキュリティ達成能力決定プロセス（ＳＡＤＰ））
ＳＣ／ＳＶが決定され、割り当てられ、関連付けられた要件が決定された後、ＲＨＥ１００４は、Ｒに関連付けられるＳＶ／ＳＣ（セキュリティ要件）を達成するためにクライアント１０２によって実施されなければならないセキュリティ機構を決定するためのセキュリティ達成能力決定プロセスを開始し得る。ＲＨＥ１００４は、セキュリティ達成能力機構（ＳＡＭ）のリストを立案し、それは、クライアント１０２を承認するために使用される。ＳＡＭは、セキュリティ要件のメタデータとＲを保護する連付けられる機構とを提供する。リソース所有者／ＲＨＥ１００４がリソースにアクセスするために満たされるべきと決定する機構のうちのいくつかは、クライアント１０２が以下であることを確実にすることを伴い得る。
● リソースの代金が支払われること
● 承認されたエンティティのリストに属すること
● 承認プロセスに基づいて、ある時間量にわたって承認されたエンティティのリストの一部になることができること
● 委託承認されたエンティティの一部であること
エンティティが承認された場合、動作は、時間、場所、またはクライアント１０２が動作することが可能であり得るリソースに関連付けられる属性のリストによって限定され得る。動作のタイプは、特定のリソース（例えば、タイムズスクエアのバンクオブアメリカキオスクを使用する人の数）を読み出すことを伴い得る。ある国に住むクライアント１０２は、そのリソースにアクセスすることが可能ではないこともある。別の例は、ある期間にわたって建物内の「制限アクセスエリア」への物理的アクセスを有する能力であろう。それは、以前に説明された使用事例２に適用可能である。

【0094】

決定されるＳＡＭは、それらがリソースに関連付けられるＳＶ／ＳＣを満たすか、またはそれを上回ることを確実にしなければならない。同じことが、クライアント１０２がリソースにアクセスするための融通性を提供するために使用され得る、委託アクセス／認証等の機構に該当し、ＳＶ／ＳＣが満たされる、または超えられることを確実にしなければならない。ＲＨＥ１００４によって立案され得るＳＡＭの例示的ハイレベル概要が、以下に提供される（以下のリストは、包括的リストではない場合があり、他の機構が、リストに追加され得る）。
● コアセキュリティ要件：
○ 移動中のセキュリティ要件：
■ サポートされるプロトコル（例えば、ＯＡＵＴＨ、ＳＡＭＬ等）、ＤＴＬＳ／ＴＬＳ等を定義する
■ 暗号化：暗号アルゴリズム（暗号化、認証／完全性）、使用されるキー長
■ 人間の関与またはマシンに基づくクライアント認証のための要件
○ 静止しているセキュリティ：
■ アクセス制御：静止しているＲにアクセスしようとするエンティティの認証
■ リソースのセキュアな記憶：Ｒを暗号化して完全性保護する
■ セキュアな処理環境の存在：セキュア要素（ＳＥ）、信頼される実行環境（ＴＥＥ）、または信頼されるプラットフォームモジュール（ＴＰＭ）
● 融通性を提供するためのオプション
○ 互いに信頼可能な認証／承認サーバ（ＡＳ）を発見する能力
○ あるＳＣまたはＳＶに属するリソースに関連付けられるセキュリティ要件を満たすために、セキュリティ機能の履行をアサートする能力
○ リソースへのアクセスに向けた支払の履行をアサートする能力
○ 委託様式（グループシナリオ）で果たされているアクセス制御機能に基づいて、リソースが複数のエンティティによってアクセスされる能力
■ 委託／プロキシ認証
■ 委託／プロキシ読み出し
○ 複数のリソース所有者を扱う能力
ＳＡＭは、随意に、その秘密キーを使用するＲＨＥ１００４によって、または信頼される第三者と見なされる任意の他のエンティティ／機能によって、もしくはリソースジェネレータの秘密キーを使用してデジタル署名され得るか、または、代替として、各Ｒが、ＳＡＭを署名するために使用される関連付けられる秘密キーを有し得る。秘密キーは、公開キーベースの証明（Ｒ＿Ｃｅｒｔ）に関連付けられ得るか、または自己署名のために使用される未加工公開／秘密キーペアであり得る。例示的ＳＡＭが、追加の支払およびＩｏＴ特定の要件とともに、表４に列挙されている。簡単にするため、かつ容易な解読のために、ＳＡＭ属性および値、ならびに支払、融通性属性およびパラメータが全て、一緒にリストアップされる。

【0095】

【表4-1】

【0096】

【表4-2】

【0097】

（セキュリティ達成能力リスティングプロセス（ＳＡＬＰ））
ＲＨＥ１００４は、クライアント１０２がＲにアクセスすることが可能であり得る場所（例えば、ＵＲＩ）と関連付けられるＳＡＭとをＲＬＥ１００８上に公開する。ＳＡＭは、ＲのＵＲＩとともに、異なる符号化フォーマット（例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）ファイル、Ｃｏｎｓｔｒａｉｎｅｄ Ｂｉｎａｒｙ Ｏｂｊｅｃｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（ＣＢＯＲ））を使用して公開され得る。ＲのためのＵＲＩが、ＲＬＥ１００８上に公開される一方、別のＵＲＩは、異なるＲＬＥ１００８上に位置するＲに関連付けられるＳＡＭを指し示すことが可能である。

【0098】

例示的リスティングプロセスが、図１２に図示されている。ＲＨＥ１００４（ｒｈｅ１．ｃｏｍ）は、ＲＬＥ１００８（ｒｌｅ１．ｃｏｍ）を用いてＲを公開してリストアップすることを望む。ステップは、以下の通りである。

【0099】

図１２のステップ０では、ＲＬＥ１００８およびＲＨＥ１００４は、相互認証を行い、随意に、互いにセキュアな接続を確立し得る。

【0100】

図１２のステップ１では、ＲＨＥ１００４は、次いで、ＳＡＬＰ要求を送信し、Ｒ−ｉｄ、リソースのための一意の識別子、および関連付けられるＲ−ＵＲＩ（リソースの場所）を提供する。殆どの場合、Ｒ−ｉｄ＝Ｒ−ＵＲＩであるが、Ｒが複数のＲＨＥ上でホストされる場合において、Ｒ−ｉｄは、Ｒを一意に識別し、Ｒ−ＵＲＩは、Ｒがホストされる場所であろう。そのような場合、Ｒ−ｉｄは、異なるＲ−ＵＲＩに記憶されるそれの複数のインスタンス化を有し得る。ＲＨＥ１００４はまた、Ｒに関連付けられるＲ＿ＳＡＭ、随意に、Ｒおよび／またはＲ＿ＳＡＭの真正性を検証するために使用され得るＲ＿Ｃｅｒｔも含む。Ｒ＿Ｃｅｒｔは、リストアップされるように要求されているＲが信頼されるソースから作成または取得されていることを確実にするために、ＲＬＥ１００８によって使用され得る。さらに、クライアント１０２は、ある時点で、Ｒ＿Ｃｅｒｔを使用してＲの真正性を検証することが可能であり得る。Ｒに関連付けられるＲ＿ＳＡＭはまた、随意に、Ｒ＿Ｃｅｒｔを使用してデジタル署名され得る。これは、Ｒ＿ＳＡＭの悪意のある、または悪意のない修正が検出可能であることを確実にする。

【0101】

図１２のステップ２では、ＲＬＥ１ １００８は、ＲＨＥ１がＲのためのリストを作成するために承認されているかどうかを検証し、該当する場合、Ｒ−ｉｄ、Ｒ−ＵＲＩ、Ｒ＿ＳＡＭ、およびＲ＿Ｃｅｒｔを含むリストが、ＲＬＥ１ １００８において作成され得る。

【0102】

図１２のステップ３では、ＲＬＥ１ １００８は、成功または失敗を示すａｃｋをＲＨＥ１に返送する。

【0103】

図１２に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１２に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１２に図示されるステップを行う。図１２に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１２に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0104】

より分散されたリソースホスティングおよびリスティング機構が、図１３に図示されている。これは、異なるＲＨＥが起源であるリソースのリスティングのための可能なオプションを図示する。リソースＲ１は、各々がそれ自身のＳＡＭ情報を有するサブコンポーネントＲ１_１およびＲ１_２を有する。リソースは、互いに結び付けられ得るが、異なるセキュリティプロファイルを有する。例えば、Ｒ１_２は、政府施設が起源であり、Ｒ１_１よりも高いセキュリティ要件を有し得、したがって、Ｒ１_１＿ＳＡＭは、Ｒ１_２＿ＳＡＭと異なり得る。２つのセキュリティ要件のうちの高い方を取り込むが、あるシナリオでは、融通性を提供しないこともある単一のＲ１＿ＳＡＭのみを有することが可能であり得る。ＲＨＥとＲＬＥとの間の全ての通信が（例えば、ＴＬＳ／ＤＴＬＳ機構を使用して）完全性および／または機密性のために保護されることを理解されたい。メッセージングステップが、以下に示される。

【0105】

図１３のステップ１では、ＲＨＥ１は、リソースサブコンポーネントｉｄ Ｒ１_１−ｉｄ、リソースが位置する場所、すなわち、[e-mail]、関連付けられるＳＡＭを含む、ＳＡＬＰ要求をＲＬＥ１ １００８に送信する。それは、それがサブコンポーネントのうちの１つであることも明示的に示す。

【0106】

図１３のステップ２では、ＲＬＥ１ １００８は、ＲＨＥ１がＲ１_１のリスティング要求を行うために承認されているかどうかを確認するためにチェックし、該当する場合、リソースおよび関連付けられるＳＡＭをリストアップする。

【0107】

図１３のステップ３では、ＲＬＥ１ １００８は、ＳＡＬＰ応答をＲＬＥ１ １００８に送信する。

【0108】

図１３のステップ４では、ＲＨＥ２ １３０４は、Ｒ１_２に関する情報を含むメッセージＡに類似するＳＡＬＰ要求をＲＬＥ１ １００８に送信する。

【0109】

図１３のステップ５では、ＲＨＥ２ １３０４の承認をチェックし、また、Ｒ１_１およびＲ１_２がウェブリンクされ、適切にインデックス化されるべきかどうかを確認するためにチェックし得る。

【0110】

図１３のステップ６では、ＲＬＥ１ １００８は、ＳＡＬＰ ａｃｋをＲＨＥ２ １３０４に送信する。

【0111】

図１３に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１３に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１３に図示されるステップを行う。図１３に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１３に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0112】

図１４は、リソースがＲＬＥ１ １００８上でリストアップされるが、ＳＡＭがＲＬＥ２ １３０２上に記憶される一方、Ｒ２＿ＣｅｒｔがＲＨＥ２ １３０４上に記憶される、シナリオを描写する。そのようなシナリオは、ＳＡＭおよびＣｅｒｔが、リソースのクラスに再利用され得るときに起こり得、リソースは、同一のアプリケーションクラスに属するが、それの異なるインスタンス化を有する。メッセージ詳細が、以下に提供される。

【0113】

図１４のステップ１では、ＲＨＥ１は、リソースｉｄ Ｒ２−ｉｄと、リソースが位置する場所：[e-mail]と、Ｒ２＿ＳＡＭおよびＲ２＿Ｃｅｒｔが位置する場所：それぞれ、[e-mail]および[e-mail]とを含むＳＡＬＰ要求をＲＬＥ１ １００８に送信する。

【0114】

図１４のステップ２では、ＲＬＥ１ １００８は、ＲＨＥ１がＲ２のリスティング要求を行うために承認されているかどうかを確認するためにチェックし、該当する場合、リソースをリストアップし、ｒｌｅ２．ｃｏｍおよびｒｈｅ２．ｃｏｍにそれぞれ位置するＲ２＿ＳＡＭならびにＲ２＿Ｃｅｒｔへの場所リンクを提供する。

【0115】

図１４のステップ３では、ＲＬＥ１ １００８は、成功した検証およびリスティングを示すＳＡＬＰ応答をＲＬＥ１ １００８に送信する。

【0116】

図１４に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１４に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１４に図示されるステップを行う。図１４に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１４に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0117】

リスティングプロセスの結果として、リソースおよび関連付けられるＳＡＭ、Ｃｅｒｔは、図１５に図示されるような様式で、リンクおよびホストされ得る。ＩＥＴＦ−ＲＦＣ ５９８８に規定されるウェブリンキングプロトコル等のリソースリンキングプロトコルが、リソースを一緒に関連付けるために使用され得、同様に、ウェブリンキングプロトコルが、リソースおよびＳＡＭ／Ｃｅｒｔを一緒にリンクするためにも使用され得る。

【0118】

図１５に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１５に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１５に図示されるステップを行う。図１５に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１５に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0119】

ＲＬＥ１ １００８において起こり得るリンキングを図示する、ＲＬＥ１ １００８において維持される例示的表が、以下に示されている。Ｒ３＿ＣｅｒｔもＲＨＥ上でホストされ得ることを図示するように、追加のリソースＲ３が追加されている。ある場合、ＲＨＥは、証明レポジトリとして機能し得、したがって、全てのリソースが、ＲＨＥ上に記憶され得る一方、別のＲＨＥは、関連付けられるＣｅｒｔをホストし、別のＲＨＥは、関連付けられるＳＡＭをホストする。融通性のタイプ、ならびにＲＳ１０８またはクライアントが制約され得るシナリオに基づいて、リスティングモデルが変動し得る。クライアント１０２がＣｅｒｔにアクセスすることを望む場合、アクセス制御制限がないこともある。代替物として、ＳＡＭは、アクセス制御制限が適用され得るセキュアなＲＨＥ上でホストされ得る。これは、企業または政府制御型エンティティ／機能の場合であり得る。しかしながら、これは、循環アクセス制御問題につながり得、おそらく、適切に設計されていない場合、オーバーヘッドを追加する。

【0120】

【表5】

【0121】

（発見プロセス（ＤＰ））
リソースを発見することを望むクライアント１０２は、ＲＬＥ１００８と相互作用し得る。クライアント１０２は、ＲＬＥ１００８の予備知識を有し得るか、または、リソースの検索を行い得、それは、クライアント１０２をＲＬＥ１００８に向かわせる。他の実装では、リソース上のＱＲコード（登録商標）が、クライアント１０２によってスキャンされ得、それは、クライアント１０２をＲＬＥ１００８に向かわせ得る。クライアントは、リソースおよび／またはリソースリスティング機能についての情報を取得するために、リソースまたはサービス発見プロセスを使用し得る。

【0122】

図１６は、単純な発見プロセスを図示し、クライアント１０２は、リソース情報をホストしているＲＬＥ１００８（例えば、ＲＬＥ１ １００８のＵＲＩ）を知っており、リソースｉｄ（Ｒ２−ｉｄ）も知っている。メッセージング詳細：
図１６のステップ１では、クライアント１ １０２は、リソースｉｄ（Ｒ２）を含む発見要求を送信する。この要求の一部として、クライアント１０２は、ＳＡＭおよび／またはＲ２に関連付けられるＣｅｒｔ等のセキュリティパラメータも明示的に要求し得る。

【0123】

図１６のステップ２では、ＲＬＥ１００８は、随意に、場所、時間、クライアントｉｄ等に基づいて、クライアント１ １０２が支払われたクライアント、サブスクライブされたクライアント、または承認されたクライアントであるかどうかを決定するために承認チェックを行い得る。ＲＬＥ１ １００８は、リソースがホストされる場所のＵＲＩ（ｒｈｅ１．ｃｏｍ／Ｒ２）で応答し、Ｒ２に関連付けられるＲ２＿ＳＡＭを送信し、随意に、Ｒ２＿Ｃｅｒｔを送信し得る。

【0124】

図１６に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１６に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１６に図示されるステップを行う。図１６に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１６に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0125】

図１７は、より精巧なリソース発見プロセスを図示し、クライアントは、リソースのクラス、またはある場合、一意の名称であり得るリソースの名称を提供する。そのようなリソース名の例は、「東京空港における温度」、または「タイムズスクエアのバンクオブアメリカキオスクを訪れる人の数」等のよりセキュリティに敏感なリソース、もしくは「遠心分離機１の中の温度」等のさらにセキュリティに敏感なリソースであり得る。ＲＬＥ１００８がそれと利用可能なリソースについての全ての関連情報を有していない場合、クライアントは、適切なＲＬＥ１００８に向かわせられ得る。代替として、ＲＬＥ１００８は、別のＲＬＥにクエリを行い、リソース場所およびリソースに関連付けられるセキュリティパラメータ（ＳＡＭ、Ｃｅｒｔ）を取得し得る。クライアントは、ＲＬＥ１００８が、（リソースが制約されているか、またはされていない）クライアントの能力に基づいて適切なリソース情報を提供することができるために、クライアント情報をＲＬＥ１００８に提供し得る。クライアントが制約されると見なされる場合、ＲＬＥ１００８は、他のＲＬＥにクエリを行うことによって、その代わりにリソース発見を行う。

【0126】

図１７のステップ０では、クライアント１とＲＬＥ１ １００８とは、互いに相互認証し、随意に、それらの間にセキュア通信チャネルを設定し得る。このステップは、随意であり、ある場合、ステップ１の後まで延期され得る。

【0127】

図１７のステップ１では、クライアント１は、リソース情報「Ｒ２」を含む発見要求を送信し、クライアント１がリソースｉｄを有する場合、それも提供し得る。加えて、クライアント１は、そのクライアント情報を送信する。クライアント情報は、計算能力、メモリ、バッテリ制限、ＳＥの存在、クライアントの証明、クライアントのＯＳ等のクライアントの能力についての情報を含み得る。

【0128】

ＲＬＥ１ １００８は、前の節で説明された機構と同様に承認チェックを行う。

【0129】

図１７のステップ３では、ＲＬＥ１ １００８は、リソースの場所のＵＲＩ、関連付けられるＳＡＭ、およびＣｅｒｔで応答する。クライアント情報および要求されるタイプまたはリソースに基づいて、ＲＬＥ１００８は、クライアントに好適であり得る、適切なリソースを選択し得る。ＲＬＥ１は、２つのリソース場所および関連付けられるＳＡＭならびにＣｅｒｔを送信する。リソースは両方とも、同一のＣｅｒｔを共有するが、異なるＳＡＭを有し得ることが可能である。前述のように、ＳＡＭおよびＣｅｒｔは、同一のＲＬＥ１００８または異なるＲＬＥにおいてホストされ得る。ある場合、Ｃｅｒｔは、証明レポジトリの役割を果たし得る、ＲＨＥに位置し得る。

【0130】

図１７に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１７に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１７に図示されるステップを行う。図１７に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１７に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0131】

（セキュリティ達成能力機構査定プロセス（ＳＡＭＡＰ））
クライアントは、随意に、Ｃｅｒｔの真正性を検証し、ＲＬＥ１００８から取得されたＳＡＭの真正性を検証するためにＣｅｒｔを使用し得る。ＳＡＭが検証されると、次いで、クライアントは、ＳＡＭの査定および他の要件（支払、使用のための融通性、ＩｏＴ特定のサポート等）の査定を行う。クライアントが、ＳＡＭで定義されるセキュリティ機構を達成することが可能ではないであろうと考える場合、クライアントは、ＲＬＥ１００８によって送信されるリソースリストから異なるＲを選択し得る。ＲＬＥ１００８によって送信された、Ｒの要求に基づいて送信された１つのＵＲＩしかない場合、クライアントは、プロセスを放棄し得るか、異なるＲＬＥ１００８にクエリを行い得るか、または同一のＲＬＥ１００８から異なるリソースを要求し得る。

【0132】

査定プロセスの一部として、クライアントは、その必要性に最も適する承認モデル（例えば、ＰＵＳＨ、ＰＵＬＬ、およびエージェント）を選択する。いくつかのシナリオでは、ＲＨＥは、使用されることができるモデル（例えば、ＰＵＳＨモデル）を義務付け得、そのような場合、クライアントは、モデルに対して多くの選択肢を残されない。査定プロセスの終了時、クライアントは、以下を決定していることもある。
● 移動中および静止時にリソースをセキュアにするために使用されなければならないセキュリティプロトコル（セキュア記憶プロセス）。
● 認証、承認、および／またはプラットフォーム妥当性検査を行うためにコンタクトされなければならない、信頼できるサーバ
● 使用されることができるモデル（例えば、ＰＵＳＨ／ＰＵＬＬ）
● クライアントが動作し得るモード（プロキシ認証および／またはプロキシ読み出し）
● リソースにアクセスするコストおよび可能な支払オプション
査定プロセスが、図１８に説明されている。ステップは、以下の通りである。

【0133】

図１８のステップ１では、ＲＬＥ１００８からリソースに関連付けられるＳＡＭを受信すると、クライアントは、随意に、Ｃｅｒｔを使用し、リソースＲに関連付けられる秘密キー（Ｒ＿Ｃｅｒｔに利用可能）を使用してＳＡＭ上に生成される署名を検証することによって、ＳＡＭの真正性を検証し得る。ＳＡＭが真正であると見なされると、次いで、クライアントは、リソースにアクセスすることができるために、クライアントに期待される種々のセキュリティ機構／要件の評価プロセスを行い始める。

【0134】

図１８のステップ２では、クライアントは、支払要件があるかどうかを確認するためにチェックし得、ある場合、クライアントが適切な通貨（例えば、ドル、ビットコイン）を使用してリソースにアクセスする代金を支払う能力を有するかどうかを検証し得る。それは、それが、ＳＡＭにリストアップされる信頼できる支払機能のうちの１つと信頼関係を有するかどうかを確認するためにチェックし得る。

【0135】

図１８のステップ３では、クライアントは、移動中または静止時、悪意のある、もしくは悪意のないエンティティによって、改ざん、盗聴されることからリソースを保護することができるために要求されるセキュリティのレベルをクライアントが満たすことができるかどうかを確認するためにチェックする。そうではない場合、プロセスは、中断される。

【0136】

図１８のステップ４では、クライアントは、リソースを保護することができるために、セキュリティ観点から要求されるプラットフォーム、ソフトウェア、ミドルウェア、プロトコル、およびハードウェアを有するかどうかを確認するためにチェックする。ここで行われる要件チェックは、ステップ３で行われるチェックのより粒度の細かい査定と見なされ得る。ステップ３におけるチェックが、リソースに関連付けられるセキュリティ要件についてである一方、ここでのチェックは、クライアントの能力を査定することである。

【0137】

図１８のステップ５では、「信頼できるＳＡＥＦ」または「信頼できる機能」のリストの中から、クライアントは、クライアントが信頼関係を有し得るか、または信頼関係を築くことが可能である、適切なＳＡＥＦ／機能を選ぶ。加えて、それは、セキュリティ機構要件に応じて、ＳＡＥＦ１０１０を選び得るか、または複数の機能を選び得る。支払が要求されない場合、支払機能の選択が省略され、同様に、ＳＡＭが認証を特定のリソースにアクセスするために必要と見なさない場合、認証機能が省略され得る。クライアントのためのより好ましいオプションは、ＳＡＭにより要求され得る種々の査定を編成することが可能であるＳＡＥＦ１０１０を選ぶことであり得る。

【0138】

図１８のステップ６では、クライアントが、ＳＡＭ内にリストアップされているいかなる他のＳＡＥＦまたは機能とも信頼関係を有していない場合、クライアントは、信頼関係が、リストアップされた機能のうちのいずれか１つとクライアント自身の信頼される機能／エンティティ（例えば、クライアントに関連付けられるアイデンティティプロバイダ）との間に確立され得るように、動的信頼構築プロセスを構築することを要求し得る。

【0139】

図１８のステップ７では、信頼される機能／ＳＡＥＦ１０１０を決定することが完了すると、クライアントは、リストから好適であり得る適切なモデルを選択する。以前に議論されたように、ＰＵＳＨモデルは、ＲＨＥが制約されている場合、より適切と考えられる一方、クライアントが制約されている場合、ＰＵＬＬモデルが好ましくあり得る。ＳＡＭは、ＲＨＥによってサポートされるモデルの優先順位リストを提供し、クライアントは、それ自身の制限に密接に適合し得るモデルを選ぶ。加えて、クライアントは、それが、委託認証モード（プロキシ認証）で動作することができるかどうか、または著しく制約されたクライアント／ＲＨＥに好適であり得るプロキシ読み出しプロセスを使用しできるかどうかも決定し得る。

【0140】

図１８のステップ８では、クライアントが、要求される適用可能なセキュリティ要件、モデル、支払等のうちの任意のもの満たすことが可能ではないと見なす場合、承認プロセスは、中断され得るか、または異なるセキュリティ要件を有し得る異なるＲＨＥ／ＲＬＥ１００８からサービスを要求し得る。

【0141】

図１８に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図１８に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１８に図示されるステップを行う。図１８に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図１８に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0142】

（セキュリティ達成能力有効化プロセス（ＳＡＥＰ））
ＳＡＥＰプロセスは、クライアントとＳＡＥＦ１０１０との間で実施される。ＳＡＥＰプロセスの目標は、高度な確実性で、クライアントが以下であるかどうかを決定することである。
● それがそうであると主張する同一のエンティティであること（認証査定）
● クライアントが、リソースにアクセスするためにそれに期待される適切なセキュリティ挙動を有すること（プラットフォーム妥当性検査／セキュリティ体制査定を決定する）
○ クライアントがセキュアなプラットフォーム（ＯＳ、カーネル、ドライバ、ハードウェア等）を有するかどうかを決定すること
■ セキュアな環境、ＴＰＭ、ＴＥＥ
■ セキュアにされおよび測定されたブートプロセス
■ アプリケーションのセキュアな実行時完全性
○ クライアントがセキュリティアプリケーションの正しい組（例えば、マルウェア保護機構：アンチウイルス（ＡＶ））、セキュアな通信のためのプロトコル（例えば、ＴＬＳ）、セキュアな記憶機構、適切な暗号機能、セキュアなポリシ等を有するかどうかを決定する
● そのＳＡＭがクライアントによって一致せられるか、または超えられるリソースへのアクセスを要求していること（承認査定）
● 適用可能である度に、クライアントがリソースにアクセスするために支払を行ったかどうかを検証する能力
ＳＡＥＦ１０１０は、クライアントに対してチェックを行うために委託機構を使用し得る。あるエンティティ／機能が、認証査定を行い得る一方、別のエンティティは、承認査定、妥当性検査査定等を行う。クライアントがアクセスしようとしているリソースが低いＳＣ／ＳＶを有し得るか、またはクライアントが制約されたエンティティであり得ることを考慮して、全ての査定が実施されるわけではないこともあることが留意されなければならない。例として、クライアントが、モバイルネットワークオペレータ（ＭＮＯ）（例えば、Ｖｅｒｉｚｏｎ、ＡＴＴ、ＮＴＴ ＢＴ）またはオーバーザトップ（ＯＴＴ）プロバイダ（例えば、ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ）等のアイデンティティプロバイダによって認証され得る一方、プラットフォーム妥当性検査は、Ａｎｄｒｏｉｄ、ＲＩＭ、またはＡＲＭ等のプラットフォームベンダによって行われる。査定の各々は、有効存続期間を有することが可能であり得、有効存続期間は、ＳＡＥＦ１０１０によって追跡される。新しいＳＡＥＰが要求される場合、ＳＡＥＦ１０１０は、前の査定の既存の有効性をチェックし得る。査定が前もって実施されていない場合、または前もって行われた査定の有効性が満了した場合のみ、新しい査定が行われる。これは、クライアントが制約され得、集約的暗号またはセキュリティプロトコルを頻繁に行うことを回避することを好むであろう場合、特に重要である。

【0143】

ＳＡＥＰプロセスの終わりに、ＳＡＥＦ１０１０は、ＳＡＥＦ１０１０によってクライアントに対して行われたチェックの真実性をアサートするアサーションまたはトークンを発行し得る。ＳＡＥＦ１０１０は、トークンの形態で累積アサーションを作成し、それをクライアントに送信し得る。累積アサーションは、行われた種々の査定の結果の組み合わせであり得る。手短に言えば、これは、査定を証明するトークンのグループ、または行われた全ての査定を明らかにする単一のトークンであり得る。生成されるトークンは、ＯＡｕｔｈトークンの形態（例えば、アクセストークン、ベアラトークン）または他の形態のトークン（例えば、ＳＡＭＬトークン）であり得ることが留意され得る。図２０は、種々の査定を編成することにおいてＳＡＥＦ１０１０によって行われるステップを詳述するフローチャートを図示する。ステップが、説明される。

【0144】

図２０のステップ１では、ＳＡＭは、概して、クライアントによってＳＡＥＦ１０１０に一般に直接提供されるＳＡＥＦ１０１０によって取得される。代替として、クライアントは、ＳＡＭへのリンク（例えば、ＳＡＭをホストするＲＬＥ１００８のＵＲＩ）を提供し得、そして、ＳＡＭは、ＳＡＥＦ１０１０によってフェッチされる。さらに、ＳＡＭがＳＡＥＦ１０１０によって取得される機構は、クライアントによって選択されるモデルに基づいて決定され得る。関連付けられるＲ＿Ｃｅｒｔも、ＳＡＥＦ１０１０によって取得され得る。

【0145】

図２０のステップ２では、ＳＡＭに基づき、かつ、随意に、Ｃｅｒｔの真正性を検証し、随意に、ＳＡＭの完全性を検証するためにＣｅｒｔを使用した後、ＳＡＥＦ１０１０は、ＳＡＭを処理する。ＳＡＥＦ１０１０は、関連属性を分析することによってＳＡＭを処理し、ＳＡＭを満たすために要求される必要な査定を開始し得る。

【0146】

図２０のステップ３では、認証査定：認証査定が要求されるかどうかを決定するためにチェックが行われる。このステップは、リソースが匿名様式でアクセスされることができる場合、省略され得る。

【0147】

図２０のステップ４では、それは、認証因子が新しく、満了していないかどうかを確認するためにもチェックする。

【0148】

図２０のステップ５では、認証査定も、ＳＡＭ要件を満たす新しく、かつ有効な認証が満たされる場合、省略され得る。例として、パスワードベースの認証、デバイス認証、およびバイオメトリック認証をそれぞれ伴い得る、「クライアントが何を把握しているか」、「クライアントが何を有するか」、および「クライアントが何であるか」の査定を行うことによって、クライアントの真正性および確実性レベルを決定する多因子認証が実施され得る。図２０のステップ５では、認証査定中、特にクライアントアプリケーションが人間によって制御されている場合、多因子認証が実施される必要があり得るかどうかの決定が行われる。人間の認証査定は、他の認証因子（パスワードベース、デバイス、バイオメトリクス等）を伴い得る。認証が実施されるエンティティは、「信頼できる認証機能のリスト」が提供されている、ＳＡＭ内のエントリに基づいて決定され得る。ＳＡＥＦ１０１０または代替としてクライアントは、リストからの「信頼できる認証機能」を用いる認証査定をトリガし得る。多因子認証が実施される場合、各々が認証因子に関連付けられた複数の信頼できる認証機能（例えば、「何を保有しているか」という認証を検証するために使用され得るＭＮＯ）を含み得ることが可能である。ＳＡＥＦ１０１０が外部認証機能に依拠することなくそれ自身で認証を行うことが可能であることも可能であり得る。

【0149】

図２０のステップ６では、新しい認証が実施された場合、有効性（鮮度）情報が、対応する認証因子のために更新される。

【0150】

図２０のステップ７では、ステップ２で行われたＳＡＭの分析に基づいて、プラットフォーム妥当性検査が要求されるかどうかを決定するために、決定が行われる。次いで、新しい（満了していない）妥当性検査査定が存在するかどうか決定が行われる。プラットフォーム妥当性検査査定が要求される場合、かつ現在の最新の査定が利用可能ではない場合のみ、新しい査定が実施され、そうでなければ、プラットフォーム妥当性検査が省略される。

【0151】

図２０のステップ８では、クライアントのデバイス／アプリケーションは、完全性妥当性検査チェックを行い、それは、ＳＡＥＦ１０１０と同一の管理ドメイン内に常駐する「信頼できる妥当性検査機能」によって、またはＳＡＥＦ１０１０ドメインの外側に常駐し得るＲＨＥによって提供されたＳＡＭ内にリストアップされたエンティティによって、トリガされ得る。プラットフォーム妥当性検査の結果は、ＳＡＥＦ１０１０において維持される表において更新される。プラットフォーム妥当性検査は、セキュアにされ、および測定されたプロセスを伴うクライアントのデバイスの遠隔妥当性検査プロセスおよび／またはローカルプラットフォーム妥当性検査を伴い得、その後、プラットフォーム上でホストされるアプリケーションの完全性の査定が続く。加えて、プラットフォームの実行時完全性チェックのスナップショットが行われ得る。ここでは、ＳＡＥＦ１０１０は、セキュアプロトコル、アルゴリズム、ＳＥ／ＴＥＥの存在、およびＳＡＭ内で必要と見なされている他の「クライアントセキュリティ要件」の利用可能性を検証することができると仮定される。

【0152】

図２０のステップ９では、ＳＡＭを使用して、提供される情報に基づいて支払が要求されるかどうかを確認するためにチェックし、また、支払のタイプ（例えば、ビットコイン、イーサ、米ドル等を使用する）も決定する。

【0153】

図２０のステップ１０では、支払が要求される場合、ＳＡＥＦ１０１０と同一のドメイン内に、またはそれの外側に常駐し得る、「信頼できる支払機能」との支払プロセスを開始し、使用されるべき支払またはサブスクリプション方法を満たす。

【0154】

図２０のステップ１１では、ＳＡＥＦ１０１０は、種々の査定を行った後、最終的に承認チェックを行う。大まかに、ＳＡＥＦ１０１０は、ＳＡＭ内の全「適用可能」エントリを比較し、「要求される」／「適用可能」および関連付けられる特徴／属性／値が満たされているかどうかを確認するためにチェックする。ＳＡＥＦ１０１０は、（例えば、ＧＰＳ／ＩＰアドレス等を使用する）クライアントの物理的場所、要求が行われた時刻等の環境チェックも行い得る。

【0155】

図２０のステップ１２では、全ての査定がパスされた場合、ＳＡＥＦ１０１０がトークンを発行する。その最も単純な形態で、トークンは、ＳＡＭからの要件が満たされていることを示し得る。このトークンは、ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋで説明されるようなベアラトークン、またはＳＡＥＦ１０１０によって検証／査定されているハイレベル要件を基本的に説明するより複雑なトークンであり得る。トークンは、ＳＡＥＦ１０１０によってデジタル署名され得、メッセージ認証コード（ＭＡＣ）トークンと類似する特性を有し得る。ＳＡＥＦ１０１０によって発行されるトークンが、ＳＡＥＦの秘密キーを使用して作成されるＳＡＥＦのデジタル署名を持つことが推奨される。各発行されたトークンは、トークンによって説明される関連付けられる存続期間を有し得、トークンは、存続期間の満了後に価値がないと見なされる。代替として、単一のトークンは、複数のサブトークンから成り得る。例として、サブトークンは、「信頼できる認証機能」によって発行され得、別のサブトークンは、「信頼できる妥当性検査機能」によって発行され得る等。ＳＡＥＦ１０１０は、全てのトークンを、ＳＡＥＦ１０１０によってデジタル署名されるトークンの組に統合し得るか、または、代替として、全てのトークンを同様にＳＡＥＦ１０１０によってデジタル署名され得る単一のトークンに組み合わせる。後者の場合、ＳＡＥＦ１０１０のデジタル署名のみが存在し得る一方、最初の場合、信頼できる機能のそれぞれからのトークンが、依然として存在し得、それらは、トークンの発行者（例えば、認証機能、信頼できる妥当性検査機能）のデジタル署名を持ち得る。署名され、支払が行われたことを表示する例示的トークン（ＪＳＯＮフォーマットである、またはＣＢＯＲ等の他のフォーマットが使用され得る）が、図１９に図示されている。

【0156】

支払トークン（ＰＴ）は、＄２００の支払がリソース「Ｒ−ｉｄ」に行われたこと、それが発行された時間／日付「２０１５年１月１日２０時」、それが８６４００秒で満了することを確認する、「ｓａｅｆ１．ｃｏｍ」によって発行されたＪＷＴである。ＰＴの主要請求の後には、その秘密キーを使用してｓａｅｆ１．ｃｏｍによって署名される、発行者「ｓａｅｆ１．ｃｏｍ」のデジタル署名が続く。

【0157】

図２０に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２０に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２０に図示されるステップを行う。図２０に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２０に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0158】

図２１は、クライアントがＰＵＬＬまたはＰＵＳＨモデルを選択し得る、ＳＡＥＰプロセスに関連付けられるハイレベルコールフローを図示する。選択されるモデルにかかわらず、クライアントとＳＡＥＦ１０１０との間の相互作用は、ハイレベルにおいて非常に類似したままであり、査定は、クライアントとＳＡＥＦ１０１０との間で直接実施される。ＰＵＬＬモデルを使用する場合、いくつかの最適化が可能である。なぜなら、前述のように相互作用がＲＨＥによって促進され、制約されたクライアントを扱う場合のより適切なモデルであり得るが、制約されたＲＨＥを扱う場合、好適ではないからである。ステップ：
図２１のステップ０では、ＴＬＳまたはＤＴＬＳを使用して、クライアント１とＳＡＥＦ１０１０との間にセキュア通信チャネルを設定する。クライアント１およびＳＡＥＦ１０１０は、プロセスの一部として、互いに相互認証していることもある。相互認証プロセスを行う要件は、特に、クライアントがデータへの匿名アクセスを要求し得る場合、随意であり得る。しかしながら、クライアントは、それがＳＡＥＦ１０１０を認証することができることを要求し得る。

【0159】

図２１のステップ１では、クライアントは、Ｒ−ｉｄ、関連付けられるＲ＿ＳＡＭ、および随意に、リソースに関連付けられるＲ＿Ｃｅｒｔを含むＳＡＥＰ要求を送信する。

【0160】

図２１のステップ２では、ＳＡＥＦ１０１０は、随意に、Ｒ＿Ｃｅｒｔの有効性チェックを行い得、Ｒ＿ＳＡＭを検証する。ＳＡＥＦ１０１０は、ＳＡＭを処理し、それが「信頼できるＳＡＥＦ」のうちの１つであるかどうかをチェックする。該当する場合、それは、実施される必要があり得る査定のタイプを識別する。ＳＡＭが、要求される認証確実性レベルが「高」であることを要求する場合、ＳＡＥＦ１０１０が、クライアントが人間によって制御されるかどうかを決定することができるならば、多因子認証が実施される必要があり得る。ＳＡＥＦ１０１０とクライアント１との間の信頼関係があるという仮定があるので、ＳＡＥＦ１０１０は、クライアント１に関連付けられるプロファイルを使用して、クライアント１についての情報を取得することが可能であり得る。クライアント１とＳＡＥＦ１０１０との間に直接信頼関係がなく、ＳＡＥＦ１０１０がクライアント１の信頼されるエンティティとの推移信頼を作成する必要があり得る場合、ＳＡＥＦ１０１０は、その信頼されるエンティティからプロファイルを取得することが可能であり得る。要求される認証レベルが低くあり得る場合、かつ認証がステップ０で起こった場合、ＳＡＥＦ１０１０は、クライアント１の別の認証を行うことを要求しないこともある。種々の査定が実施される順序は、ＳＡＭ、およびＳＡＥＦ１０１０の動作を統制するポリシに基づき得る。例として、ＳＡＥＦ１０１０は、認証査定が制約されたデバイスに少ない影響を及ぼすことを決定し得、したがって、残りの査定を行う前にそれを開始し得る。したがって、認証が失敗する場合、他の査定が実施されないこともある。一方、ＳＡＥＦ１０１０が、最も重要な査定がプラットフォーム妥当性検査であることを決定する場合、それは、任意の他の査定が行われる前に実施され得る。

【0161】

図２１のステップ３では、ここでは、ＳＡＥＦ１０１０は、任意の他の査定の前に、最初に認証査定を開始することが仮定される。認証査定は、ａ）．ＳＡＭ（匿名アクセス）に基づいて認証が要求されない場合、ｂ）．「要求されるセキュリティレベル」を満たす既存の有効かつ新しい認証が存在する場合、または、ｃ）．セキュアな接続を設定するために実施されたＴＬＳ／ＤＴＬＳ認証が「セキュリティレベル」を満たす場合、省略され得る。認証査定は、以下の様式で実施され得る。

【0162】

ステップ３ａでは、ＳＡＥＦ１０１０は、認証プロセスを開始するために、クライアント１、または認証機能（ＡＦ）のいずれかをトリガし得、認証機能は、多様な認証因子を行うことが可能である多因子認証機能（ＭＦＡＦ）２１０４でもあり得る。認証プロセスは、Ｏｐｅｎ Ｉｄｅｎｔｉｔｙ（ＯｐｅｎＩＤ）／ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ／ＳＡＭＬ／Ｋｅｒｂｅｒｏｓ／ＧＢＡ／ＥＡＰ等の確立したプロトコルに従い得る。１つのそのような実施形態では、クライアント１は、認証査定を行うためにＭＦＡＦに向け直され得る。

【0163】

ステップ３ｂでは、クライアント１とＭＦＡＦ２１０４とは、認証に関連付けられる「要求されるセキュリティレベル」を満たすか、またはそれを上回るために、多因子認証を行い得る。認証プロセスの一部として、クライアントデバイスは、デバイス証明を使用して、またはクライアントアプリケーション証明を使用して、認証され得る。随意に、クライアントデバイスは、共有秘密（例えば、ＳＩＭカード内に記憶された秘密を使用して）またはセキュアに記憶された共有秘密を有し得るクライアントアプリケーションを使用しても、認証され得る。クライアントが人間によって制御される場合、個人は、（何を「ユーザが把握しているか」という機構、例えば、パスワード）および／またはバイオメトリクスを使用して、認証され得る。ＭＦＡＦ２１０４は、因子の各々に関連付けられる証明書が異なるＡＦに記憶され得るので、種々の認証査定を調整するために他のＡＦを使用し得る。デバイス認証は、クライアント１（加入者の証明書）を記憶し得るＡＡＡ／Ｄｉａｍｅｔｅｒ／ＨＳＳ等のモバイルネットワークオペレータ（ＭＮＯ）のコアネットワーク機能と相互作用することをＭＦＡＦ２１０４に要求し得る。

【0164】

ステップ３ｃでは、ＭＦＡＦ２１０４は、種々のＡＦから結果を取得し、次いで、クライアント１の認証を保証するアサーションまたはトークンを作成する。これは、クライアント１によって達成される認証レベルを示し得る。トークンは、各々がＡＦから取得されるサブトークンで構成され得る。ＭＦＡＦ２１０４は、アサーション／トークンをＳＡＥＦ１０１０に送信する。

【0165】

図２１のステップ４では、ＳＡＥＦ１０１０は、次いで、ＳＡＭ情報と新しくかつ有効なプラットフォーム妥当性検査査定の利用可能性とに基づいて、プラットフォーム妥当性検査が要求されるかどうかを決定する。要求される場合、ＳＡＥＦ１０１０は、プラットフォーム妥当性検査機能（ＰＶＦ）２１０６とのプラットフォーム妥当性検査査定プロセスをトリガする。プラットフォーム妥当性検査プロセスの査定に加えて、ＳＡＥＦ１０１０は、あるセキュリティプロトコルがサポートされているかどうか（例えば、ＳＡＭＬまたはＩＰＳｅｃ等）、マルウェア検出／一掃アプリケーションの存在および現在の起動、アンチウイルス（ＡＶ）、適切な構成パラメータ等のより粒度の細かいチェックがＳＡＭ要件を満たすこと要求し得る。ＰＶＦ２１０６は、妥当性検査プロセスに基づいて、実施された査定の成功を保証するアサーション／トークンを送信する。

【0166】

図２１のステップ５では、ＳＡＥＦ１０１０は、必要であると見なされる場合、ＰＦ２１０８との支払査定を開始し得る。ＰＦ２１０８は、支払プロセスが完了すると、ＰＴ（支払トークン）をＳＡＥＦ１０１０に送信し、前述のように、ＰＴは、支払いが成功したか、または行われた実際の支払であったかどうかを示し得る。ある事例では、ＰＴは、領収証として使用され得、Ｒ−ｉｄに関連付けられ得る。ＰＴが、特に、匿名トランザクションを要求するトランザクションに対して、Ｒ−ｉｄを含まないことも可能である。ＰＴは、実施された支払いトランザクションの成功を保証し得る。

【0167】

図２１のステップ６では、ＳＡＥＦ１０１０は、ＳＡＭ内にリストアップされる全ての残りの要件が達成されており、適切な機構が利用されているかどうかを決定するために、承認機能（ＡｕｔｈＦ）２１０２のサービスを使用し得る。加えて、ＡｕｔｈＦ２１０２は、アクセス制御に関連付けられる制限を伝える責任があり、制限は、以下を含み得る（包括的ではない例示的リストが以下に提供される）。

【0168】

リソースＲ−ｉｄへのアクセスの有効性：ＡＴが有効である期間（例えば、秒単位で）。

【0169】

場所。その場所からＲへのアクセスが許可され得る（例えば、ＩＰ＠ｒａｎｇｅ、地理的場所制限、時刻）。

【0170】

プロキシ読み出しまたはグループアクセスの可能性（グループメンバの数の制限）：リソースが他のクライアントに代わってプロキシによってアクセス可能であるか
再配布可能：リソースが他のクライアントに再配布可能であり得る場合、クライアントの数および／またはさらにクライアントに関連付けられるＩＰアドレス／アプリケーション。ＤＲＭ保護されたコンテンツ。

【0171】

図２１のステップ７では、種々の査定の終わりに、ＳＡＥＦ１０１０は承認トークン（ＡＴ）を作成し、ＡＴは、ＳＡＥＦ１０１０によってデジタル署名され得るか、またはＲＨＥによって検証可能であり得るトークンのＭＡＣを含み得る。ＡＴは、ＳＡＭによって実施された全ての関連査定（請求）の統合であり得るか、査定についてのハイレベル請求のみを単に含み得るか、または代替として、種々の査定機能によって発行された全トークンを含み得る。

【0172】

図２１のステップ８では、トークンは、次いで、好ましくは、セキュア通信チャネル（例えば、ＴＬＳ／ＤＴＬＳ）を使用して、クライアント１に送信される。トークンは、行われた種々の査定を証明する個々のトークンであり得るか、または適切な請求を含む単一のトークンであり得る。全ての査定が暗号論的にチャネルバウンドであり得ることが留意されなければならない。

【0173】

図２１に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２１に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２１に図示されるステップを行う。図２１に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２１に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0174】

（リソースアクセスプロセス（ＲＡＰ））
ＲＡＰ中、クライアント１は、セキュアな接続を使用して、ＳＡＥＦ１０１０から取得されたＡＴをＲＨＥに送信する。

【0175】

ＲＨＥは、リソースに関連付けられるＲ＿ＳＡＭが「信頼できるＳＡＥＦ」のための要件を有しているかどうかを確認するためにチェックする。該当する場合、ＲＨＥは、ＳＡＥＦ１０１０に関連付けられるデジタル証明を取得するか、またはＳＡＥＦ１０１０に関連付けられる事前共有秘密を取得する。そして、ＳＡＥＦ１０１０は、ＡＴの一部として送信されるデジタル署名またはＭＡＣを検証する。ＲＨＥは、次いで、ＳＡＭ要件が満たされているかどうかをチェックするために、残りのＡＴを検証し、ＳＡＭで説明される適切な機構がＳＡＥＦ１０１０によってクライアント１を承認することにおいて使用されているかどうかを決定するためにチェックする。上で説明されるステップを図示するフローチャートが、図２２に示されている。

【0176】

図２２のステップ２では、ＳＡＭは、ＡｕｔｈＴが認証される必要があるかどうかを確認するためにチェックされる。

【0177】

該当する場合、図２２のステップ３では、ＳＡＥＦに関連付けられる共有キーまたは証明が取得され、図２２のステップ４では、ＭＡＣまたはデジタル署名（ＤＳ）が計算される。図２２のステップ５では、ＡｕｔｈＴ内のＭＡＣまたは署名が正確であるかどうかがチェックされる。

【0178】

ＡｕｔｈＴ内のＭＡＣまたは署名が正確ではない場合、図２２のステップ７では、信頼できないトークンを示すメッセージが、クライアントに送信される。

【0179】

ＡｕｔｈＴ内のＭＡＣまたは署名が正確である場合（もしくはＡｕｔｈＴが認証される必要がない場合）、図２２のステップ８では、ＡｕｔｈＴが処理され、ＳＡＭが満たされているか、または超えられているかどうかがチェックされる。

【0180】

ＳＡＭが満たされているか、または超えられている場合、図２２のステップ９では、成功を示すメッセージが、クライアントに送信され、アクセスが、リソースに提供される。

【0181】

ＳＡＭが満たされていない、または超えられていない場合、図２２のステップ１０では、承認不完全を示すメッセージが、クライアントに送信される。一実施形態では、リソースへの制限されたアクセスが提供される。

【0182】

図２２に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２２に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２２に図示されるステップを行う。図２２に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２２に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0183】

メッセージ交換を描写するコールフローが、図２３に図示されている。

【0184】

図２３のステップ０では、クライアント１とＲＨＥ１とは、互いに相互認証し、それらの間にセキュアな接続を確立する。このステップは、随意であるが、しかしながら、好ましくあり得る。匿名認証が要求される場合において、認証ステップは、省略され得る。クライアント１が、ＳＡＥＦ１０１０によって認証されているＡＴをプロビジョニングされた場合にも、クライアント１の認証は、省略され得る。しかしながら、クライアント１は、ＲＨＥ１がそれによって認証されることを要求し得る。

【0185】

図２３のステップ１では、クライアント１は、ＲＡＰ要求メッセージをＲＨＥ１に送信する。クライアント１は、セキュアな接続の内側で送信される要求内でＡＴを提供する。Ｒ−ｉｄがＡＴ内の請求として存在し得るので、それは、随意に、リソースｉｄ、Ｒ−ｉｄを含み得る。Ｒ−ｉｄが請求の一部として含まれない場合において、Ｒ−ｉｄは、ＲＡＰ要求メッセージの一部として含まれる必要がある。

【0186】

図２３のステップ２では、ＲＨＥ１は、次いで、以下を行う。

【0187】

（ステップ２ａ）そのローカルの記憶されたデータベースからＲ−ｉｄに関連付けられるＳＡＭをフェッチするか、または異なるＲＨＥからそれをフェッチする。

【0188】

（ステップ２ｂ）ＲＨＥが「信頼できるＳＡＥＦ」または他の「信頼できる機能」のリストを有する場合、ＳＡＭからこれらの情報を取得し、ＲＨＥ１に関連付けられるデータベースから、ＲＨＥ１とＳＡＥＦ１０１０との間の事前共有秘密またはＳＡＥＦ１０１０のデジタル証明も取得する。類似プロシージャが、他の機能に関連付けられる秘密または証明を取得するために使用され得る。

【0189】

（ステップ２ｃ）署名またはＭＡＣがリソースに関連付けられるＳＡＭに基づいて要求される場合、ＲＨＥは、ＡＴの一部として含まれた署名またはＭＡＣを検証し得る。ＪＳＯＮウェブトークン（ＪＷＴ）／ＪＳＯＮウェブ署名（ＪＷＳ）仕様書、ＪＳＯＮウェブトークン（ＪＷＴ）、ＩＥＴＦ−Ｄｒａｆｔ：ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｊｓｏｎ−ｗｅｂ−ｔｏｋｅｎ−３２（２０１４年１２月９日）に規定されるものに類似する機構が、検証に使用され得る。ＪＷＴは、ＳＡＥＦ１０１０または「信頼できる機能」によって提供される請求のアサーションのＪＳＯＮ表現である。手短に言えば、それは、ＡＴのＪＳＯＮバージョンであり、ＪＷＳは、署名されたＡＴである。

【0190】

（ステップ２ｄ）ＲＨＥ１は、次いで、クライアント１がＳＡＭにリストアップされるような要件／機構を満たしているかどうかを検証する。該当する場合、クライアント１は、リソースにアクセスするために承認されており、そうでなければ、ＲＨＥ１は、一致に基づいて、リソースへの部分アクセスが提供され得るかどうかを決定し得、そうでなければ、いかなるアクセスも全く提供されない。

【0191】

図２３のステップ３では、ＡＴ請求が満たされ、検証された場合、ＲＨＥ１は、リソースをクライアント１に送信する。

【0192】

図２３に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２３に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２３に図示されるステップを行う。図２３に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２３に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0193】

ＰＵＳＨモデルのみが、上で考慮されている。しかしながら、ここで説明される機構は、原理および論理が類似するので、他のモデル（ＰＵＬＬ、間接ＰＵＳＨ等）にも適用されることができる。

【0194】

（実施形態）
従来のリソースサーバ（ＲＳ）１０８は、上で説明されるより融通性がある動的な承認フレームワークをサポートするために、５．３で説明されるようなＲＨＥに関連付けられる機能性（例えば、ＳＣＦ１００６と相互作用する能力、ＳＡＭの作成、関連付けられるＳＡＭおよびＳ−Ｃｅｒｔの公開）およびメッセージング能力で強化され得る。同様に、リソースディレクトリ（ＲＤ）２４０４は、５．４で説明されているＲＬＥ１００８に関連付けられる追加の機能性（例えば、セキュリティパラメータ、高／中／低に基づいて、ＳＡＭ、Ｓ−Ｃｅｒｔ、プロセスクエリ要求を列挙する能力）およびメッセージング能力で強化され得る。

【0195】

ＳＡＭパラメータの適切な選択は、保護されているデータのタイプに依存するであろうことが留意されなければならない。低いＳＶ／ＳＣを有するデータ／リソースは、非常に単純なＳＡＭを使用して表されるが、リソースに対してＣ／ＳＶ＝高である場合、ＲＨＥ／ＲＳにおいて作成され、ホストされるリソースは、ＳＡＭを保持し、処理するために十分な容量を有することを考慮するべきである。同じことが、クライアントに該当するであろう。

【0196】

さらに、クライアントがあるモデル（例えば、ＰＵＬＬ）を扱うことができない場合、クライアントは、ＡＳ１０６と信頼関係を有していないこともあり、煩雑であり得る推移信頼が作成されなければならないか、または、ＰＵＳＨモデルをサポートし得る別のＲＨＥ／ＲＳ１０８を見出すためにＲＬＥ１００８／ＲＤ２４０４にクエリを行い得る。

【0197】

わずかに変化した実施形態では、それは、ＲＨＥ／ＲＳ１０８がＲＬＥ１００８／ＲＤ２４０４機能の一部を実装することを伴い得、したがって、クライアントは、直接的にＳＡＭに対してＲＳ１０８にクエリを行い得るか、または前の交換からの満了していないＳＡＭを有し得る。

【0198】

ある場合、リソースは、関連付けられるＳＣ／ＳＶ値のみを有し得、ＳＣ／ＳＶ値は、リソース特定のセキュリティプロファイル（ＲＳＳＰ）を描写し得る。これは、例えば、０（低）〜１０（高）に及び得る。

【0199】

ソリューションのハイレベル実施形態が、図２４に図示されている。それは、エンティティと、リソースサーバ（ＲＳ）等のＲＨＥによってホストされるリソースへのアクセスをクライアントに提供することができるために関与するステップとを描写する。

【0200】

（詳細なメッセージングを用いた実施形態）
従来のＲＳ１０８は、ＲＳ１０８がＲＨＥと同様に機能するために、本願で説明される機能性で強化されなければならない。クライアントは、適切なＳＡＭを取得し、適切なセキュリティ機構、セキュリティ要件、支払等を決定するために、ＲＬＥ１００８機能で強化されている従来のＲＤ２４０４を使用する。ＲＤ２４０４が、クライアントがここで説明される動的承認フレームワークを活用することができるために、ＲＬＥ１００８に対して説明される機能性で強化されなければならないことが、留意されなければならない。同様に、従来のＡＳ１０６は、ＳＡＥＦ１０１０によって果たされる機能で強化されなければならず、支払サーバ（ＰＳ）２４０２と共同ホストされ得る。

【0201】

図２４のステップ１では、センサは、ＤＵＰを行い、周期的に行われ得る。前述のように、作成されるリソースは、未加工データ、メタデータを伴う未加工データ、未加工データから抽出される情報、またはデータもしくは情報もしくはコンテンツの集合であり得る。いくつかのリソースは、ウェブリンキングプロセスを使用して、一緒にリンクされ得る。各データは、ＲＨＥによって計算されるか、または外部の信頼されるエンティティによってそれに提供される、ＳＣ／ＳＶを有し得る。加えて、異なる情報サーバによって作成されるリソースも、ＲＳ１０８上でホストされ得る。さらに、この新しい情報リソースは、ＲＳ１０８上でより新しいリソースを作成するために使用され得る。新しいＳＶが、作成される新しい情報の各インスタンスのために、ＲＳ１０８によって計算され得る。制約された環境では、これらのリソースが、より粒度の細かいＳＶよりもむしろクラスに割り当てられ得る。手短に言えば、ＲＳ上で作成される任意の新しいリソースのために、新しいＳＶが計算され得る。ＳＶの値は、例えば、０〜１０に及び得る：０−セキュリティ要件なし、１０−極めて高い。

【0202】

図２４のステップ２では、ＲＳ１０８は、次いで、ＲＬＥ１００８上へのリソースおよび関連付けられるＳＡＭ、随意に、Ｃｅｒｔのディレクトリリスティングまたは登録を行う。ＲＳ１０８は、ＲＳ１０８上でホストされるリソースの各々に関連付けられるＲ−ｉｄ、Ｒ＿ＳＡＭ、およびＲ＿Ｃｅｒｔを含む、ＳＡＬＰメッセージをＲＤ２４０４に送信する。前述のように、ＳＡＭは、ＲＳ１０８が信頼関係を有し得る「信頼できるＳＡＥＦ」または機能についての情報を含む。ＳＡＭは、承認プロセスを開始するときにクライアントが選択し得るモデルのタイプ（例えば、ＰＵＳＨ、ＰＵＬＬ等）についての情報もクライアントに提供する。加えて、ＲＳ１０８が制約されているかどうか、プロキシ認証、プロキシ読み出しプロセスが行われることができるかどうかについての情報も提供される。

【0203】

ＳＡＬＰメッセージを受信すると、ＲＤ２４０４は、ＲＳ１０８がＲＤ２４０４上のＲＳ１０８に関連付けられるリソースリスト／記録に更新動作を行うために承認されているかどうかを確認するための承認チェックを行い得る。該当する場合、ＲＤ２４０４は、リソースリストのためのエントリ（ＲＳ上のリソースの場所またはＵＲＩ）を作成し、関連付けられるＳＡＭが、ＲＤ２４０４上に記憶されるか、またはＳＡＭへのリンク（それが記憶され得る場所を示すＵＲＩ）が、リスティングの一部として提供される。同じことが、Ｒ＿Ｃｅｒｔに当てはまる。

【0204】

図２４のステップ３では、リソースにアクセスすることを望むクライアントは、ＣｏＲＥリソースディレクトリ（ＩＥＴＦ−ｄｒａｆｔ−ｓｈｅｌｂｙ−ｃｏｒｅ−ｒｅｓｏｕｒｃｅ−ｄｉｒｅｃｔｏｒｙ−０２、２０１４年１１月９日）で説明されるプロトコルを使用して、ＲＤ２４０４を用いてＤＰを行い得る。

【0205】

リソース発見の一部として、クライアントは、ＳＡＭ、リソースの場所情報（ＲＳを指し示すＵＲＩ）を提供され、適用可能である場合、Ｃｅｒｔも提供される。リソースの同一のコピーが複数のＲＳ１０８上に記憶されることが可能であり得る。加えて、ウェブリンキングプロトコル、ＩＥＴＦ−ＲＦＣ ５９８８で説明される、ウェブリンキングプロトコルを使用してウェブリンクされ得る、リソースに関する関連リストも、提供され得る。ＲＳ１０８は、リソース場所を周期的に更新し、および／または、収集されているデータの性質に応じて、もしくはある外部因子（例えば、新しいＳＡＥＦとの信頼関係）に基づいて変化していることもあるデータのセキュリティ体制に基づいて、関連付けられるＳＡＭを周期的に更新し得る。

【0206】

図２４のステップ４では、ＲＤ２４０４からクライアントによって取得された情報に基づいて、クライアントは、使用されるべきモデルを決定し、それがセキュリティ要件、支払要件をハンドリングすることができるかどうかを決定し、それがＳＡＥＦ１０１０または他のセキュリティ機能のうちの少なくとも１つとの信頼関係、プロキシ認証、プロキシ読み出しモードで起動する能力等を有するかどうかを決定し得る。要求される査定が、ＡＳ１０６／ＰＳ２４０２によって行われ、適切なトークンが、クライアント１０２に発行される。クライアントがコア要件のうちのいくつかを満たすことができない場合、ある他のパラメータを使用して、または異なるＲＤ２４０４を用いて、ＤＰを行い得る。

【0207】

図２４のステップ４では、この特定のシナリオで、クライアントがＳＡＭに基づいてＰＵＳＨモデルを選択し、次いで、既存の承認サーバ（ＡＳ）内で実装され得る適切なＳＡＥＦ１０１０を選択することが仮定される。現在のＡＳ１０６は、ＳＡＭを処理し、次いで、種々のセキュリティおよび支払機能、ならびに機能の各々によって生成される関連トークン（アサーション）を調整し、次いで、統合トークンを作成する能力を有することができるために、ＳＡＥＦ機能性で強化されなければならないことが、留意されなければならない。加えて、ＡＳ１０６は、前もっていかなる信頼関係も有していないこともある他のＡＳ１０６と推移関係を作成する必要があり得る。そのような場合、ＡＳ１０６は、ＡＰ内にリストアップされるＡＳ１０６と推移信頼関係を有し得るＡＳを発見するために、サービス発見を行う必要があり得る。代替として、ＡＰは、ＳＡＭ内で提供されるような要件を満たすＡＳ１０６のクラスのサービス発見を行う必要があり得る。選択されたＡＳ１０６は、ＡＦのサービスを使用して認証を行い得る。代替として、クライアントは、別のＡＳによって認証され得、そして、別のＡＳは、クライアントの識別を要求ＡＳ１０６にアサートする。要求ＡＳ１０６は、ＡＴを作成し、ＡＴは、クライアントにプロビジョニングされる。支払が行われた場合、ＰＳ２４０２が、支払トークン（ＰＴ）を生成する。ＳＡＭに基づいて、ＡＳ１０６は、認証プロセスが要求され得ないことを決定し得、そのような認証が省略され得る一方、他の査定（例えば、プラットフォーム妥当性検査、承認チェック）は、ＳＡＭによって決定付けられる要件に基づいて実行され得る。ＡＳ１０６は、統合トークンを作成し、それは、セキュアな接続を使用してクライアントに送信される。

【0208】

図２４のステップ５では、クライアントは、リソースにアクセスするために、トークンをＲＳ１０８にサブミットする。ＲＳ１０８は、トークンを検証し、随意に、トークンがＳＡＭによって規定される信頼されるＡＳ１０６によって発行されたことを検証するために、トークンの一部として提供される署名を検証する。ＲＳ１０８は、随意に、それがＰＳ２４０２によって発行された場合、支払トークンを検証し得る。代替として、単一のトークンは、承認成功ならびに成功した支払いの両方を示し得る。支払トークンは、支払わされた金額を示し得るか、または単に支払が正常に処理されたという指示を提供し得る。トークンは、ベアラトークン、認証トークン、またはＭＡＣトークン、もしくはカスタマイズされたトークン、またはＰＴであり得る。

【0209】

図２４に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２４に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２４に図示されるステップを行う。図２４に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２４に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。種々のエンティティ（例えば、クライアント１、ＲＤ１、ＲＳ１、およびＡＳ１）間の全ての通信は、通信チャネルに関与する２つのエンティティ間の一意のセキュアな接続（例えば、ＴＬＳ／ＳＳＬ）を用いて実施されることが仮定される。

【0210】

コールフローの詳細な実施形態が、図２５に図示されている。関与するステップ：
図２５のステップ１では、ＲＳ１０８は、ＲＳ１０８上でホストされるリソースＲ１のためのリストを作成するための要求をＲＤ２４０４上に送信する。リストは、Ｒ１＿ＳＡＭおよびＲ１＿Ｃｅｒｔも含む。

【0211】

図２５のステップ２では、ＲＤ２４０４は、関連付けられるＲ１＿ＳＡＭおよびＲ１＿Ｃｅｒｔとともに、Ｒ１のためのリストを作成する。ＲＤ２４０４は、随意に、ＲＳ１０８がリスティングを行うために承認されているかどうかを確認するためにチェックし得る。

【0212】

図２５のステップ３では、ＲＤ２４０４は、成功したリスティングについての２．０１「作成済」メッセージをＲＳ１０８に送信する。

【0213】

図２５のステップ４では、ある時点で、クライアントは、ＲＤ２４０４を使用して検索を行う。クライアントは、リソースＲ１を明示的に要求する。クライアントは、リソースのクラス、または、あるモデル／モード等を使用して動作し得るリソースを要求し得ることが可能である。

【0214】

図２５のステップ５では、ＲＤ２４０４は、Ｒ１−ＵＲＩ、Ｒ１＿ＳＡＭ、およびＲ１＿Ｃｅｒｔをクライアントに提供する。

【0215】

図２５のステップ６では、クライアントは、Ｃｅｒｔを使用してＳＡＭを検証し、選択されるべきモデルを決定し、信頼できるＳＡＥＦ（ＡＳ）も選択される。このコールフローでは、ＰＵＳＨモデルが選択される。

【0216】

図２５のステップ７では、クライアントは、ＡＳ１０６とセキュアな接続を確立する。クライアントとＡＳ１０６とは、互いに相互認証し得る。

【0217】

図２５のステップ８では、クライアントは、ＡＳ１０６に承認およびトークンを要求する。クライアントは、ＡＳ１０６にＲ１＿ＳＡＭも提供する。

【0218】

図２５のステップ９では、ＡＳ１０６は、実施される必要があろう査定（追加のユーザおよび／またはデバイス認証、支払、プラットフォーム妥当性検査等）を決定する。ここでは、多因子認証が実施される必要があろうことを決定する。

【0219】

図２５のステップ１０では、ＡＳ１０６は、クライアントを認証する。このステップは、多因子認証を伴い得る。

【0220】

図２５のステップ１１では、ＡＳ１０６は、承認チェックを行い、適切な請求と共にトークンＡＴをクライアントにプロビジョニングする。

【0221】

図２５のステップ１２では、クライアントは、ＡＴを記憶する。

【0222】

図２５のステップ１３では、クライアントは、ＲＳ１０８とセキュアな接続を確立する。

【0223】

図２５のステップ１４では、クライアントは、ＡＳ１０６によって発行されたＡＴをＲＳ１０８にポストする。

【0224】

図２５のステップ１５では、ＲＳ１０８は、トークンおよびトークンに含まれるＡＳの署名、実施された査定を検証し、査定がＲ１＿ＳＡＭで説明される要件および機構に一致したことを確実にする。

【0225】

図２５のステップ１６では、ＲＳ１０８は、ＡＴ内の請求に基づいて、かつＲ１＿ＳＡＭによって規定されるように承認された持続時間にわたって、リソースＲ１への適切なアクセスをクライアントに提供する。

【0226】

図２５に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２５に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２５に図示されるステップを行う。図２５に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２５に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0227】

プロキシ認証シナリオを実証する実施形態が、図２６に示されている。クライアント１は、マスタクライアントとして動作し、他のクライアントに代わってＡＳ１０６との認証／承認を行う。委託認証機能として動作するクライアント１は、他のクライアントに代わって、より集約的な認証および暗号動作を行う。クライアント１は、他のクライアントに代わって承認要求を受信するように事前構成されていることもある。クライアント２およびクライアント３は、クライアント１と新たに認証されており、クライアント２とクライアント１との間、さらに、クライアント３とクライアント１との間に個々のセキュアな接続を設定していることもあることに留意されたい。メッセージング詳細：
クライアント１は、すでに発見プロセスを行い、Ｒ１＿ＵＲＩおよびＲ１＿ＳＡＭを取得していると仮定される。代替的シナリオでは、発見プロセス自体も、クライアント２およびクライアント３に代わってクライアント１によって、プロキシ様式で行われ得る。

【0228】

図２６のステップ０では、クライアント１および２の各々は、セキュアな接続（例えば、ＴＬＳ／ＳＳＬ）を使用して、ＰＯＳＴメッセージをクライアント１に送信する。ＰＯＳＴメッセージ内のコンテンツは、リソースＲ１に対する承認要求を有する。

【0229】

図２６のステップ１では、クライアント１は、ＰＯＳＴメッセージが実際にはＡＳ１０６のために標的化されていることを決定し、クライアント２および３がプロキシ認証モードを使用するために承認されていることも決定する。前もって取得されたＳＡＭに基づいて、クライアント１は、ＡＳ１が信頼できる機能のリスト中にあり、ＡＳ１がプロキシ認証を容認することも決定する。クライアント１ １０２は、ＡＳ１ １０６とＴＬＳ／ＤＴＬＳ接続を確立する。

【0230】

図２６のステップ２では、クライアント１は、それ自身のための承認、および、Ｒ１＿ＳＡＭとともに他のクライアントのための承認も要求する。クライアント１は、ＰＯＳＴメッセージ内に他のクライアントの識別をリストアップする。いくつかの実施形態では、クライアント１は、要求を検証するために、他のクライアントから取得され、他のクライアントによってデジタル署名されていることもある元の要求をリストアップし得る。

【0231】

図２６のステップ３では、クライアント１は、ＡＳ１によって認証され得、さらに、クライアント１がそうすべき様式で挙動していることを決定するために、プラットフォーム妥当性検査およびセキュアプロトコル査定が行われ得る。クライアント１が、ユーザが関与していない単なる別のマシンまたはアプリケーションである場合、プラットフォーム妥当性検査チェックとデバイス認証との組み合わせが行われ得る。そのような場合、ユーザ認証は、実施されない。支払査定が行われる必要がある場合において、クライアント１は、Ｒ１＿ＳＡＭに基づいて全てのクライアントに代わって支払を行う必要があろう。

【0232】

図２６のステップ４では、ＡＳ１は、３つ全てのクライアントのためのトークンを発行する。トークン内の請求がクライアントを明示的に識別するであろうため、したがって、これらのクライアントのみが、トークンを使用することができるであろう。トークンは、デジタル署名されるので、修正されることができない。クライアント１のみが、あるクレジットを有し、したがって、支払査定が、部分的にのみ履行され、そのような場合、限定数のトークンのみが発行され得る（例えば、この場合、２つまたはそれ未満のトークンが発行されるであろう）ことが可能であり得る。

【0233】

図２６のステップ５では、クライアント１は、適切なトークンを、クライアント２およびクライアント３に提供する。

【0234】

図２６のステップ６では、クライアントの各々は、ＴＬＳ／ＤＴＬＳを使用して、ＲＳ１とセキュアな接続を確立する。

【0235】

図２６のステップ７では、クライアント１は、以下を処理する。

【0236】

ステップ７ａでは、クライアント１は、ＰＯＳＴメッセージを使用して、そのトークンＡＴ１をＲＳ１にサブミットする。

【0237】

ステップ７ｂでは、ＲＳ１は、トークン、トークン起源を検証し、存在した場合、署名も検証し、有効性を書き留める。加えて、ＲＳ１は、プロキシ承認プロセスがトークンを生成するために使用されたことをトークンから推論し得る。ＲＳ１は、合計３つのトークンが発行されたことを推論することも可能であり得る。

【0238】

ステップ７ｃでは、ＲＳ１は、リソースＲ１をクライアント１に送信する。

【0239】

図２６のステップ８では、クライアント２は、読み出しプロセスを開始し、サブプロシージャ８ａ、８ｂ、および８ｃは、プロシージャ７ａ、７ｂ、および７ｃについて説明されるものに類似するプロセスに従う。

【0240】

図２６のステップ９では、クライアント３は、７および８のような類似プロセスに従い、セキュアな接続を通してコンテンツを送信する。

【0241】

図２６に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２６に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２６に図示されるステップを行う。図２６に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２６に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0242】

プロキシ読み出しシナリオを実証する実施形態が、図２７に示されている。実施形態は、プロキシ認証ならびにプロキシ読み出しを両方とも使用する。認証は、特に、クライアントが制約されていない場合において、非プロキシ様式で実施され得ることが可能であり得る。しかしながら、ＲＳ１０８が制約されている場合、プロキシ読み出しが採用され得る。クライアントおよびＲＳ１０８が両方とも制約されている場合、プロキシ承認ならびにプロキシ読み出しが両方とも行われ得る。メッセージング詳細：
図２７のメッセージ０−６は、前述のプロキシ承認シナリオに非常に類似する。そのクライアント２およびクライアント３は、クライアント１と新たに相互認証されており、クライアント２とクライアント１との間、さらに、クライアント３とクライアント１との間に個々のセキュアな接続を設定していることもある。微妙な変化のうちのいくつかは、ＲＳ１０８がプロキシ読み出しを容認するかどうかの決定を含み、該当する場合、それは、ＳＡＭ内で示され得る。クライアント１は、承認プロセス中、他のクライアントに代わってプロキシ読み出しを行っていることをＡＳ１に示し、したがって、支払査定プロセス中、クライアント１は、プロキシ読み出しの料金を請求され得るが、１つだけのトークンが発行される。

【0243】

図２７のメッセージ７では、ＲＳ１は、トークン内の請求に基づいて、クライアント１がプロキシ読み出しを行っていることを検証し得る。ＲＳ１は、クライアント１がプラットフォーム妥当性検査査定を正常にパスし、必要な支払を行ったことも検証する。

【0244】

図２７のメッセージ８では、コンテンツＲ１が、クライアント１１０２に送信される。

【0245】

図２７のメッセージ９では、クライアント１がリソースＲ１を受信すると、セキュアな接続を使用して、リソースのコピーを両方のクライアントに送信する。

【0246】

図２７に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２７に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２７に図示されるステップを行う。図２７に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２７に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0247】

（プロトコル強化および拡張）
既存のＲＤプロトコルＣｏＲＥリソースディレクトリならびにＣｏＡＰプロトコル［Ｔｈｅ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ），ＩＥＴＦ−ＲＦＣ ７２５２］への強化および拡張の説明が、説明される。ＲＳ１０８がＳＡＭをリストアップし、クライアントがＳＡＭを発見することができるための能力が、提供される必要がある。加えて、クライアントがＣｏＡＰを使用して適切な承認およびリソース読み出しを要求することができるための能力が説明される。加えて、ここで説明される機構は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）またはウェブソケットもしくは任意の他の適用可能なプロトコル等のプロトコルを経由して使用され得る。

【0248】

（ＳＡＭをサポートするＲＤ拡張）
ＣｏＲＥリンクフォーマットＩＥＴＦ−ＲＦＣ ６６９０は、ＲＳ１０８（すなわち、エンドポイント）上に提供されるリソースを説明するためのいくつかの属性を定義する。ＲＳ１０８は、他のデバイスまたはアプリケーションがＲＤ２４０４を介してリソースを発見することができるように、それらの関連付けられる属性を含むそのリソースをリソースディレクトリ（ＲＤ）２４０４上に登録する制約されたデバイスであり得る。

【0249】

リソース登録プロセスは、リソースに関連付けられるセキュリティ要件／機構を説明するＳＡＭ（リソース特定のセキュリティプロファイル）のリスティングをサポートするように拡張されることができる。さらに、クライアントがリソースを発見するための能力は、あるセキュリティプロファイルに基づく。我々は、２つの新しいリンク属性を定義する。
● セキュリティ達成能力機構（ＳＡＭ）：この属性は、詳細なセキュリティ達成能力機構を示す。これは、例えば、ＪＳＯＮ、ＸＭＬ、またはＣＢＯＲを使用して表され得る。
● 証明（Ｃｅｒｔ）：各リソースは、自己署名され得るか、または第三者によって発行され得る、デジタル証明に関連付けられ得る。加えて、ＳＡＭは、ＳＡＭの真正性を提供するために証明に関連付けられ得る。

【0250】

図２８は、拡張リソース登録の例示的プロシージャを図示する。

【0251】

図２８のステップ１では、エンドポイントは、「リソース登録」メッセージをＲＤ２４０４に送信する。このメッセージは、登録されるリソースのリストを含む。各リソースは、そのリンクフォーマット説明（すなわち、リンク属性）を有する。特に、各リソースは、２つの新しい属性「ｓａｍ」および「ｃｅｒｔ」を有する。

【0252】

○ 例えば、／ｒｅｓｏｕｒｃｅｓ／Ｒ１リソースは、以下の属性を有する。

【0253】

■ リソースタイプ（ｒｔ）は、「ｔｅｍｐｅｒａｔｕｒｅ−ｃ」である
■ ＳＡＭ（ｓａｍ）は、「Ｒ１＿ＳＡＭ」である
■ ＳＡＭに関連付けられる証明（ｃｅｒｔ）は、「Ｒ１＿Ｃｅｒｔ」である
○ 別の例では、／ｒｅｓｏｕｒｃｅｓ／Ｒ２リソースは、以下の属性を有する。

【0254】

■ リソースタイプ（ｒｔ）は、「ｓｔｒｅａｍｉｎｇ」である
■ リソース特定のセキュリティプロファイル（ｒｓｓｐ）は、「Ｒ２＿ｒｓｓｐ」である
■ リソースのための証明（ｃｅｒｔ）は、「Ｒ２＿Ｃｅｒｔ」である。

【0255】

図２８のステップ２では、ＲＤ２４０４は、「応答」メッセージをエンドポイントに返送する。

【0256】

導入された新しい属性「ｓａｍ」、「ｒｓｓｐ」、および「ｃｅｒｔ」を用いると、クライアント（例えば、ＩｏＴアプリケーション）は、より多くのクエリをＲＤ２４０４に発行できることに留意されたい。例えば、
● クエリを行い、あるｒｓｓｐ値＝”ＬＯＷ”を伴うリソースをホストするエンドポイントを発見すること
図２８に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置もしくは図３１Ｃまたは図３１Ｄに図示されるもの等のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが理解される。すなわち、図２８に図示される方法は、図３１Ｃまたは図３１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図２８に図示されるステップを行う。図２８に図示される機能性は、仮想化ネットワーク機能の組として実装され得ることも理解される。ネットワーク機能は、必ずしも直接通信しないこともあり、むしろ、それらは、転送またはルーティング機能を介して通信し得る。図２８に図示される任意の伝送および受信ステップは、装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置の通信回路によって行われ得ることも理解される。

【0257】

（非プロキシ認証、プロキシ認証、およびプロキシ読み出しをサポートするＣｏＡＰ拡張）
動的承認フレームワーク、ならびにプロキシ承認およびプロキシ読み出し等の前述の最適化をサポートすることを可能にするＣｏＡＰオプションを提示する。ＣｏＡＰオプションの概要が、表６で提供される。

【0258】

【表6-1】

【0259】

【表6-2】

【0260】

（グラフィカルユーザインターフェース（ＧＵＩ））
グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、サービス層課金相関に関連する機能性を制御および／または構成するようにユーザを支援するために使用されることができる。図２９および３０は、本願のシステムとともに使用されることができるインターフェースを図示する略図である。以下に説明される図３１Ｃ−Ｄに示されるもの等のディスプレイを使用して、そのようなＧＵＩが生成され得ることを理解されたい。

【0261】

セキュリティポリシ、要件、プロトコル、パラメータ、および適切なセキュリティ値を構成するためのＧＵＩの使用は、ＲＨＥにおいて、ならびにＡＳにおいて実施され得る。図２９に図示されるような、ＳＣＦ１００６における、またはＲＨＥにおけるＧＵＩ２９０２は、以下を行うために使用され得る。
● 一般的セキュリティポリシを構成する
● ＳＶおよびＳＣの構成
○ ＳＶ／ＳＣがリソースに割り当てられることができるような構成パラメータ
○ 要件を同等のＳＶ／ＳＣにマップするセキュリティ表の構成
● ＳＡＭに関連付けられるＳＶの構成
● サポートされるべき承認モデル
● 信頼されるエンティティの構成（例えば、ＡＳ１０６／ＰＳ２４０２の名称およびＵＲＩ）
● 予期されるアサーションパラメータの構成
ＡＳ／ＰＳ２４０２において承認および支払関連セキュリティパラメータを構成するために使用されるＧＵＩ３００２が、図３０に図示されている。ＧＵＩ３００２は、以下の構成を行うために、ＡＳ／ＰＳ２４０２において使用され得る。
● 実施される必要があり得る認証のタイプを構成すること（多因子認証：バイオメトリック、デバイスベース等）
● 認証が実施されるために他のＡＳ１０６の達成能力に関連する情報の構成
● 認証の因子への確実性レベルのマッピング
● ＰＳ２４０２に関する情報の構成
（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法を達成するように、単独で、または互いに組み合わせて動作し得る。本明細書で使用される場合、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、同義的に使用され得る。

【0262】

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

【0263】

図３１Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。

【0264】

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

【0265】

図３１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送ならびに受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍ端末デバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む種々のネットワークを介して通信し得る。

【0266】

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

【0267】

図３１Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信ネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図３１Ｃおよび３１Ｄで図示されるデバイスを含む１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

【0268】

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。

【0269】

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

【0270】

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

【0271】

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、また、他の開示されるシステムおよび方法と併せて使用され得る。

【0272】

一実施形態では、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティは、図３１Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

【0273】

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

【0274】

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、もしくはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、もしくは１つ以上の既存のノードの一部としてのいずれかで実行する論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）で実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図３１Ｃまたは図３１Ｄに図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。

【0275】

さらに、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

【0276】

図３１Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティを実行するか、または含むことができる。デバイス３０は、図３１Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であることができる。図３１Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０は、送受信機３４および伝送／受信要素３６等の通信回路も含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装するノードであり得る。

【0277】

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号動作等のセキュリティ動作を行い得る。

【0278】

図３１Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図３１Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に統合され得ることが理解されるであろう。

【0279】

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

【0280】

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

【0281】

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

【0282】

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上で説明されるように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行もしくは共有のステータスを反映するか、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから取得するか、または情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にするように、ＡＰＩの上で層化され得る。

【0283】

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

【0284】

プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

【0285】

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、バイオメトリック（例えば、指紋）センサ等の種々のセンサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

【0286】

ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。代替として、ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の装置もしくはデバイスを備え得る。

【0287】

図３１Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。コンピューティングシステム９０は、クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティを実行するか、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む任意の他のノードであることができる。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

【0288】

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

【0289】

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

【0290】

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を通信する責任がある、周辺機器コントローラ８３を含み得る。

【0291】

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。

【0292】

さらに、コンピューティングシステム９０は、例えば、図３１Ａおよび図３１Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にし得る。

【0293】

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。それは、ハンドヘルド携帯電話、モバイルブロードバンドアダプタを具備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図３１Ａ−ＢのＭ２Ｍ端末デバイス１８または図３１Ｃのデバイス３０として実装されることができる。

【0294】

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。クライアント１０２、ＲＯ１０４、ＡＳ１０６、ＲＳ１０８、ＣＡＭ７０２、Ｄ−ＳＡＭ７０４等のＳＡＭ、センサ８０２等のセンサ、ＳＡＥＦ１０１０、ＲＬＥ１００８、ＲＨＥ１００４、ＳＣＦ１００６、ＤＳ１００２、リソース１１０２、ＤＨＰ１１０４、ＡｕｔｈＦ２１０２、ＭＦＡＦ２１０４、ＰＶＦ２１０６、ＰＦ２１０８、ＰＳ２４０２、ＲＤ２４０４、ＳＡＥＰ、ＲＡＰ、および図２９ならび３０のＧＵＩを生成する論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令の形態で具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる、任意の他の有形もしくは物理媒体を含むが、それらに限定されない。

【0295】

図に図示されるような本開示の主題の好ましい実施形態を説明する上で、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する全ての技術的均等物を含むことを理解されたい。

【0296】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31A】

【図31B】

【図31C】

【図31D】