JP6560442B2 - サービス層動的承認 - Google Patents

サービス層動的承認 Download PDF

Info

Publication number
JP6560442B2
JP6560442B2 JP2018510739A JP2018510739A JP6560442B2 JP 6560442 B2 JP6560442 B2 JP 6560442B2 JP 2018510739 A JP2018510739 A JP 2018510739A JP 2018510739 A JP2018510739 A JP 2018510739A JP 6560442 B2 JP6560442 B2 JP 6560442B2
Authority
JP
Japan
Prior art keywords
entity
service layer
resource
slda
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018510739A
Other languages
English (en)
Other versions
JP2018533857A (ja
Inventor
デール エヌ． シード，
デール エヌ． シード，
ビノッド クマー チョイ，
ビノッド クマー チョイ，
ウィリアム ロバード ザ フォース フリン，
ウィリアム ロバード ザ フォース フリン，
チュアン リー，
チュアン リー，
ドナルド エー． フレック，
ドナルド エー． フレック，
リチャード ピー． ゴーマン，
リチャード ピー． ゴーマン，
ニコラス ジェイ． ポディアス，
ニコラス ジェイ． ポディアス，
マイケル エフ． スターシニック，
マイケル エフ． スターシニック，
ホンクン リ，
ホンクン リ，
ズオ チェン，
ズオ チェン，
ヨゲンドラ シー． シャ，
ヨゲンドラ シー． シャ，
シャミム アクバル ラフマン，
シャミム アクバル ラフマン，
Original Assignee
コンヴィーダ ワイヤレス， エルエルシー
コンヴィーダ ワイヤレス， エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コンヴィーダ ワイヤレス， エルエルシー, コンヴィーダ ワイヤレス， エルエルシー filed Critical コンヴィーダ ワイヤレス， エルエルシー
Publication of JP2018533857A publication Critical patent/JP2018533857A/ja
Application granted granted Critical
Publication of JP6560442B2 publication Critical patent/JP6560442B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２１１，４７１号（２０１５年８月２８日出願）の利益を主張し、上記出願は、その全体が記載されている場合のように参照により本明細書に引用される。
プロトコルスタックの視点から、ミドルウェアサービス層は、典型的には、既存のネットワークプロトコルスタックの上で層状にされ、付加価値サービスをクライアントアプリケーションならびに他のサービスに提供する。故に、サービス層は、多くの場合、「ミドルウェア」サービス層として分類される。例えば、図１は、ＩＰネットワーキングスタックとアプリケーションとの間に位置するサービス層１０２を示す。別の例が、ＴＣＰまたはＵＤＰ等のトランスポートプロトコル、またはＳＯＡＰ等の非ＲＥＳＴｆｕｌプロトコルの真上でサービス層１０２を層状にすることを伴い得ることに留意されたい（図１に示されていない）。
ネットワーク内のミドルウェアサービス層インスタンスの例示的展開シナリオが、図２に示されている。この例では、サービス層インスタンスは、種々のネットワークノード（ゲートウェイおよびサーバ）上で展開され、付加価値サービスを、ネットワークアプリケーション、デバイスアプリケーション、およびネットワークノード自体に提供している。
Ｍ２Ｍ／ＩｏＴサービス層１０２は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを特に標的とする１つのタイプのミドルウェアサービス層の例である。近年、いくつかの業界規格団体、（例えば、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．１０．０、ＥＴＳＩ Ｍ２Ｍ Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ （Ｍ２Ｍ） Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、草案ＥＴＳＩ ＴＳ １０２ ６９０ １．１．１（２０１１−１０）に説明されるｏｎｅＭ２Ｍ、およびＯＭＡ Ｌｉｇｈｔｗｅｉｇｈｔ Ｍ２Ｍ（ＬＷＭ２Ｍ）技術仕様書、草案バージョン１．０（２０１３年３月１４日）に説明されるＯＭＡ ＬＷＭ２Ｍ）が、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するために、Ｍ２Ｍサービス層を開発している。
Ｍ２Ｍサービス層１０２は、サービス層１０２によってサポートされるＭ２Ｍ中枢能力の集合へのアクセスをアプリケーションおよびデバイスに提供することができる。いくつかの例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。これらの能力は、Ｍ２Ｍサービス層１０２によってサポートされるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。
ｏｎｅＭ２Ｍの目的および目標は、種々のハードウェアおよびソフトウェアプラットフォーム内に容易に埋め込まれ、分野内の多種多様なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために頼りにされることができる共通Ｍ２Ｍサービス層の必要性に対処する、技術的仕様を開発することである。
ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）（すなわち、サービス層）と称される。これらの共通機能は、図３に示されるように、Ｍｃａ、Ｍｃｃ、およびＭｃｎ参照点を介してエクスポーズされる。Ｍｃａ参照点が、アプリケーションエンティティ（ＡＥ）とＣＳＥとの間の通信フローを指定する一方で、Ｍｃｃ参照点は、同一のＭ２Ｍサービスプロバイダドメイン内の２つのＣＳＥの間の通信フローを指定する。ＭｃａおよびＭｃｃを横断する通信は、対にされた要求／応答メッセージを介して行われ、各要求は、標的ＣＳＥ上でホストされるリソースに特定のＲＥＳＴｆｕｌ動作（例えば、作成（Ｃｒｅａｔｅ）、読み出し（Ｒｅｔｒｉｅｖｅ）、更新（Ｕｐｄａｔｅ）、および削除（Ｄｅｌｅｔｅ））を行う。Ｍｃｃ’は、異なるＭ２Ｍ ＳＰのインフラストラクチャドメインの中に位置するＣＳＥ間に使用される。Ｍｃｎは、トランスポートおよび接続性以外のサービスのためにＣＳＥと下層ネットワークサービスエンティティ（ＮＳＥ）との間で使用される。
ＣＳＥは、「ノード」と称されるアーキテクチャのエンティティ上でホストされる。ノードは、ａ）１つのＣＳＥおよびゼロ以上のＡＥ、または、ｂ）１つ以上のＡＥを含む機能的エンティティである。ｏｎｅＭ２Ｍアーキテクチャは、図４に示されるような種々のタイプのノード構成をサポートする。
ｏｎｅＭ２Ｍによってサポートされる共通サービス機能（ＣＳＦ）の初期の組が、図５に示されている。特定のＣＳＥ実装は、全ての機能をサポートするわけではないこともあるが、完全な実装は、説明図の中の全ての機能を含むであろう。
ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャによると、ＣＳＦは、「リソース」の組として表される。リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する、アーキテクチャ内の一意にアドレス可能なエンティティである。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースと、属性とを含み得る。子リソースは、親リソースとの包含関係を有する、リソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースについての情報を記憶する、「属性」の組をサポートする。
認証は、サービス層登録者の識別が信頼できる証明情報に関連付けられることを確かめるプロセスである。認証プロセスを行う方法は、使用される認証機構に依存するであろう。例えば、認可証ベースの認証の場合、認証は、典型的には、デジタル署名を検証することを伴う。対称キー認証の場合、認証は、典型的には、メッセージ認証コード（ＭＡＣ）を検証することを伴う。相互認証は、登録者とそれが登録しているサービス層との間で起こる、双方向認証である。故に、相互認証は、サービス層が登録者の識別を確かめるとともに、登録者がサービス層の識別を確かめるプロセスである。
サービス層承認機構が、サービス層内でホストされるリソースおよび／またはサービスへのアクセスを制御するために使用される。承認は、典型的には、静的にプロビジョニングされた承認ポリシおよび割り当てられた役割に基づいて、認証された登録者がサービス層内でホストされるリソースならびにサービスにアクセスすることを可能にすることを伴う。承認ポリシは、所与のサービス層登録者がサービス層内でホストされる保護されたリソースまたはサービスにアクセスすることを許可されるかどうかを定義する、規則の組である。これらのポリシは、異なる機構に基づくことができる。３つの一般的なタイプの承認ポリシは、承認リスト（ＡＣＬ）、役割ベースの承認（ＲＢＡＣ）、およびサブスクリプションベースの承認（ＳＢＡＣ）である。
サービス層ＡＣＬは、いずれのサービス層登録者がいずれのリソースおよびサービスにアクセスすることを許可されるか、ならびにいずれの動作を所与のリソースまたはサービスに行うことが可能にされるかを定義する。例えば、登録者１２３は、リソースＡＢＣを（書き込むのではなく）読み取ることを可能にされる。
サービス層ＲＢＡＣは、登録者に割り当てられた特定の役割に基づいて、リソースまたはサービスに特定の動作を行う特権を定義する。例えば、登録者１２３が、「管理者」としての役割を有し得る一方で、登録者４５６は、「ユーザ」としての役割を有し得る。ＲＢＡＣは、「管理者」が特定のリソースへの読み取りおよび書き込みアクセスの両方を有する一方で、「ユーザ」が読み取りアクセスのみを有するという特権を定義し得る。
サービス層ＳＢＡＣは、登録者のサブスクリプションレベルに基づいて、リソースまたはサービスに特定の動作を行う特権を定義する。例えば、登録者１２３は、サブスクリプションの費用に基づいて、他のものではなく、あるタイプのサービスにアクセスする権利をそれに与えるサブスクリプションを有し得る。
ＡＣＬ、ＲＢＡＣ、およびＳＢＡＣ特権は、サービス層サブスクリプションモデルに基づいて事前プロビジョニングされる（すなわち、帯域外で構成される）ことができる。例えば、登録者がそれ自体とサービス層プロバイダとの間に事前確立したサービス層サブスクリプションのタイプに基づいて、サブスクリプションは、登録者がサービス層リソースおよびサービスにアクセスしようとするとき、登録者に付与される特権のタイプを決定することができる。
Ｍ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ、ＥＴＳＩ Ｍ２Ｍ、ＯＭＡ ＬＷＭ２Ｍ）は、上で説明されるもの等の承認機構をサポートするサービス層の例である。
本開示の焦点は、（識別および認証ではなく）サービス層承認に関連付けられる承認機能性の強化にあることに留意されたい。
ｏｎｅＭ２Ｍは、図６Ａに示されるような特権の構成された組をサポートする、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを定義する。特権は、いずれの認証されたサービス層登録者が＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースに関連付けられるリソースにアクセスするための特権を有するかを定義する承認規則（すなわち、ポリシ）の組で構成されることができる。構成されると、これらの特権は、典型的には、サービス層の視点から静的である。サービス層は、オンザフライで特権を動的に作成、更新、または削除しない。
現在まで、ｏｎｅＭ２Ｍは、ＡＣＬポリシに基づく定義された特権を有している。ｏｎｅＭ２Ｍは、特権属性内に記憶されることができる、アクセス・制御・規則タプルの組としてこのＡＣＬポリシを定義し、各タプルは、３つのコンポーネント、すなわち、ＡｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ、ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔから成る。
ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ−この承認ポリシに関連付けられるリソースにアクセスする権限を与えられているサービス層登録者の組（例えば、ＣＳＥ−ＩＤまたはＡＥ−ＩＤのリスト）。
ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ−各承認されたサービス層登録者が行う権限を与えられている動作の組（例えば、作成、読み出し、更新、および削除）。
ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔ−ｏｎｅＭ２Ｍは、現在、以下の３つのタイプの承認コンテキストを定義している。
ｏ ａｃｃｅｓｓＣｏｎｔｒｏｌＴｉｍｅＷｉｎｄｏｗｓ−その間要求が可能にされる時間窓。この時間外でこの承認ポリシに関連付けられるリソースに起こる要求は、拒否されるであろう。
ｏ ａｃｃｅｓｓＣｏｎｔｒｏｌＬｏｃａｔｉｏｎＲｅｇｉｏｎｓ−この承認ポリシに関連付けられるリソースにアクセスするとき、サービス層登録者が位置することを可能にされる場所のリスト。このリストの中にない場所からのサービス層登録者からの要求は、拒否されるであろう。
ｏ ａｃｃｅｓｓＣｏｎｔｒｏｌＩｐＡｄｄｒｅｓｓｅｓ−この承認ポリシに関連付けられるリソースにアクセスすることを可能にされるサービス層登録者のＩＰアドレス。このリストの中にないＩＰアドレスを有するサービス層登録者からの要求は、拒否されるであろう。
ＯＡｕｔｈ ２．０承認フレームワークは、第三者クライアントアプリケーションがリソース所有者の代わりにＨＴＴＰリソースへのアクセスを取得することを可能にする。ＯＡｕｔｈは、リソース所有者が、それらの証明情報を共有することなく、それらのリソースへの第三者アクセスを承認するためのプロセスを規定する。ハイパーテキスト転送プロトコル（ＨＴＴＰ）と連動するように特に設計され、ＯＡｕｔｈは、本質的に、リソース所有者の認可により、アクセストークンが承認サーバによって第三者クライアントアプリケーションに発行されることを可能にする。アプリケーションは、次いで、図６Ｂに示されるように、リソースサーバによってホストされる保護されたリソースにアクセスするために、アクセストークンを使用する。
図６ＢのステップＡでは、クライアントは、リソース所有者から承認を要求する。承認要求は、リソースに直接行われることができる。
図６ＢのステップＢでは、クライアントは、リソース所有者の承認を表す証明情報である承認付与情報を受信する。
図６ＢのステップＣでは、クライアントは、承認サーバを用いて認証し、承認付与情報を提示することによって、アクセストークンを要求する。
図６ＢのステップＤでは、承認サーバは、クライアントを認証し、承認付与情報を確認し、有効である場合、アクセストークンを発行する。
図６ＢのステップＥでは、クライアントは、リソースサーバから保護されたリソースを要求し、アクセストークンを提示することによって認証する。
図６ＢのステップＦでは、リソースサーバは、アクセストークンを確認し、有効である場合、要求に応える。
拡張可能ポリシベースのサービス層動的承認フレームワークは、登録者が現在アクセスする適切な特権を欠いている、サービス層によってホストされるリソースまたはサービスへのアクセスを登録者に付与もしくは拒否するかどうかをサービス層が決定することを可能にすることができる。方法は、同一の登録者から、および同一のリソースならびにサービスへの将来の要求が、動的承認が行われることを要求しないように、サービス層が（その動的承認結果を活用することによって）その静的に構成された承認特権を動的に更新することを可能にすることもできる。
サービス層が、次いで、登録者と相談し、そのリソースまたはサービスにアクセスするための特権を他のサービス層登録者に付与もしくは拒否するかどうかを決定するために使用し得る、そのリソースまたはサービスのための相談ベースの動的承認ポリシをサービス層登録者が規定することを可能にする方法が、使用されることができる。
サービス層が、次いで、他の登録者への動的承認をサポートするために使用し得る、そのリソースまたはサービスのための支払ベースの動的承認ポリシをサービス層登録者が規定するための方法が、使用されることができる。特権は、他のサービス層登録者がリソースまたはサービスにアクセスするために自発的に支払う料金に基づいて、付与もしくは拒否される。
サービス層登録者が、そのリソースまたはサービスのためのバータベースの動的承認ポリシを規定するための方法であって、これらのポリシは、それ自身のリソースまたはサービスへのアクセスと引き換えに、他の登録者のリソースおよびサービスへのアクセスを獲得することを所望する登録者の代わりに、サービス層が動的に交換することを可能にする、方法が、使用されることができる。
サービス層登録者が、そのリソースまたはサービスのためのセキュリティ査定ベースの動的承認ポリシを規定するための方法であって、これらのポリシは、サービス層が、他の登録者のリソースおよびサービスへのアクセスを獲得することを所望する登録者のセキュリティレベルを動的に査定し、そのセキュリティのレベルが動的承認要件を満たすかどうかを決定することを可能にする方法が、使用されることができる。
サービス層登録者が、そのリソースまたはサービスのための評判ベースの動的承認ポリシを規定するための方法であって、これらのポリシは、サービス層が、他の登録者のリソースおよびサービスへのアクセスを獲得することを所望する登録者の評判レベルを動的に査定し、その評判が動的承認要件を満たすかどうかを決定することを可能にする方法が、使用されることができる。
ｏｎｅＭ２Ｍベースのシステムのための提案されたサービス層動的承認特徴の実施形態が説明される。実施形態は、本開示によって定義されるサービス層動的承認特徴がｏｎｅＭ２Ｍシステムで実現されることができる方法を説明する、ｏｎｅＭ２Ｍアーキテクチャ、リソースレベル、メッセージングレベル、およびプロシージャのレベル提案を含む。
本開示で定義される方法および実施形態は、Ｍ２Ｍ／ＩｏＴサービス層に関して説明されるが、これらの着想は、他のタイプのサービス層にも適用され得ることに留意されたい。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態で一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
前記装置におけるサービス層において要求を受信することと、
前記サービス層において、前記要求の発信側が標的リソースにアクセスするための適切な静的特権を有するかどうかを決定することと、
前記要求の前記発信側が前記標的リソースにアクセスするための前記適切な静的特権を有していない場合、動的承認を使用して前記要求を評価し、前記動的承認に基づいて前記要求を許可すること、または拒否することと
を前記装置に行わせる、装置。
（項目２）
前記装置は、コンサルティングエンティティと相談し、動的承認を使用して前記要求を評価する、項目１に記載の装置。
（項目３）
前記サービス層は、前記コンサルティングエンティティのための連絡先情報を含むポリシで構成されている、項目２に記載の装置。
（項目４）
前記コンサルティングエンティティは、前記サービス層への応答において、付与された特権のリストおよび前記付与された特権に関連付けられた存続期間を送信する、項目２に記載の装置。
（項目５）
前記装置は、前記付与された特権のリストの中で規定されている要求側を追加することによって、静的ポリシを更新する、項目４に記載の装置。
（項目６）
前記要求側は、前記静的ポリシに一時的に追加されている、項目５に記載の装置。
（項目７）
前記装置は、動的承認ポリシを受信する、項目１に記載の装置。
（項目８）
前記装置は、要求側が支払を行ったという指示を受信した後、前記動的承認を行う、項目１に記載の装置。
（項目９）
前記装置は、要求側がバータ条件を満たしたという指示を受信した後、前記動的承認を行う、項目１に記載の装置。
（項目１０）
前記装置は、前記動的承認において、評判情報を使用して認証されたものの中の要求側についての評判情報を使用する、項目１に記載の装置。
（項目１１）
装置による使用のための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
前記装置におけるサービス層において要求を受信することと、
前記サービス層において、前記要求の発信側が標的リソースにアクセスするための適切な静的特権を有するかどうかを決定することと、
前記要求の前記発信側が前記標的リソースにアクセスするための前記適切な静的特権を有していない場合、動的承認を使用して前記要求を評価し、前記動的承認に基づいて前記要求を許可すること、または拒否することと
を含む方法の機能を果たす、方法。
（項目１２）
前記装置は、コンサルティングエンティティと相談し、動的承認を使用して前記要求を評価する、項目１１に記載の方法。
（項目１３）
前記サービス層は、前記コンサルティングエンティティのための連絡先情報を含むポリシで構成されている、項目１２に記載の方法。
（項目１４）
前記コンサルティングエンティティは、前記サービス層への応答において、付与された特権のリストおよび前記付与された特権に関連付けられた存続期間を送信する、項目１２に記載の方法。
（項目１５）
前記装置は、前記付与された特権のリストの中で規定されている要求側を追加することによって、静的ポリシを更新する、項目１４に記載の方法。
（項目１６）
前記要求側は、前記静的ポリシに一時的に追加されている、項目１５に記載の方法。
（項目１７）
前記装置は、動的承認ポリシを受信する、項目１１に記載の方法。
（項目１８）
前記装置は、要求側が支払を行ったという指示を受信した後、前記動的承認を行う、項目１１に記載の方法。
（項目１９）
前記装置は、要求側がバータ条件を満たしたという指示を受信した後、前記動的承認を行う、項目１１に記載の方法。
（項目２０）
前記装置は、前記動的承認において、評判情報を使用して認証されたものの中の要求側についての評判情報を使用する、項目１１に記載の方法。
より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明からもたらされ得る。
図１は、ミドルウェアサービス層をサポートするプロトコルスタックの略図である。 図２は、ネットワーク内の例示的ミドルウェアサービス層展開の略図である。 図３は、ｏｎｅＭ２Ｍアーキテクチャの略図である。 図４は、ｏｎｅＭ２Ｍアーキテクチャ構成の略図である。 図５は、ｏｎｅＭ２Ｍ ＣＳＦの略図である。 図６Ａは、ｏｎｅＭ２Ｍ＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの略図である。 図６Ｂは、ＯＡｕｔｈ ２．０承認フレームワークの略図である。 図７は、サービス層によってローカルで行われるサービス層動的承認の略図である。 図８は、相談を介して行われるサービス層動的承認の略図である。 図９は、サービス層動的承認機能の略図である。 図１０は、サービス層内でローカル機能として展開されるＳＬＤＡ９０２の略図である。 図１１は、サービス層とは別個に展開されるＳＬＤＡ９０２の略図である。 図１２は、サービス層とは別個に展開されるＳＬＤＡ９０２の略図である。 図１３は、サービス層とは別個に展開されるＳＬＤＡ９０２の略図である。 図１４は、静的および動的ポリシ管理の略図である。 図１５は、ポリシプロビジョニングプロセスの略図である。 図１６は、リソースのためのアクセスポリシを作成してホストすることの略図である。 図１７は、アクセス制御されたリソースを要求するクライアントの略図である。 図１８は、ＰＵＳＨモデルを使用するリソースアクセスの略図である。 図１９は、支払承認プロセスの略図である。 図２０は、ＰＵＬＬモデルに基づく承認の略図である。 図２１は、ＰＵＳＨ確認モデルに基づく承認の略図である。 図２２は、間接ＰＵＳＨモデルに基づく承認の略図である。 図２３は、ｏｎｅＭ２Ｍ ＭＥＦ２３０４、ＭＡＦ２３０２、またはＣＳＥエンティティ上で中央に展開されるＳＬＤＡ機能性の略図である。 図２４は、ｏｎｅＭ２Ｍ ＭＥＦ２３０４、ＭＡＦ２３０２、およびＣＳＥエンティティを横断して分散されて展開されるＳＬＤＡ機能性の略図である。 図２５は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞ｏｎｅＭ２Ｍリソースの略図である。 図２６は、ｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性を介して＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞にリンクすることの略図である。 図２７は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞の子リソースとしての＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞の略図である。 図２８は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞に追加されたｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性を介して＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞をリンクすることの略図である。 図２９は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞に合併された＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞属性の略図である。 図３０は、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞仮想リソースの略図である。 図３１は、ＣＳＥＢａｓｅの下でインスタンス化された＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞の略図である。 図３２は、＜ＡＥ＞リソースの下でインスタンス化された＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞の略図である。 図３３は、＜ｃｏｎｓｕｌｔ＞仮想リソースの略図である。 図３４は、サービス層動的承認ポリシの構成の略図である。 図３５は、自律サービス層動的承認処理の略図である。 図３６は、明示的サービス層動的承認要求ハンドリングの略図である。 図３７は、相談ベースのサービス層動的承認の略図である。 図３８は、支払ベースのサービス層動的承認の略図である。 図３９は、バータベースのサービス層動的承認の略図である。 図４０は、セキュリティ査定ベースのサービス層動的承認の略図である。 図４１は、サービス層サブスクリプション検証ベースの動的承認の略図である。 図４２は、評判ベースのサービス層動的承認の略図である。 図４３は、一実施形態のグラフィカルユーザインターフェースの略図である。 図４４Ａは、通信ネットワークを含むＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システムの略図である。 図４４Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイス、ならびに通信ネットワークのためのサービスを提供する、フィールドドメイン内の図示されるＭ２Ｍサービス層の略図である。 図４４Ｃは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、例示的デバイスの略図である。 図４４Ｄは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバのブロック図である。
ネットワークノードは、リソースまたはサービスをホストするネットワーク内のアドレス可能なエンティティであることができる。ネットワークノードは、ネットワーク内の物理的エンティティ（例えば、デバイス、ゲートウェイ、もしくはサーバ）または仮想エンティティ（例えば、仮想マシン）のいずれかであり得る。
リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有するアドレス可能なエンティティであることができる。
サービスは、サポートされたインターフェースを介してアクセスされる関連ソフトウェア機能性の組（例えば、データ記憶サービス）であることができる。
サービス層１０２は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通してサービス層登録者に利用可能にされるリソースおよびサービスをホストするソフトウェア層であることができる。
サービス層登録者は、サービス層に登録するエンティティであることができる。例えば、アプリケーション、個々のサービス、サービス層の別のインスタンスである。
一実施形態では、サービス層動的承認は、１）要求側が現在アクセスする適切な特権を欠いている、サービス層によってホストされるリソースまたはサービスにアクセスするための特権を付与すべきか、または拒否すべきか、２）同じ登録者からの同じリソースおよびサービスへの将来の要求が動的承認が行われることを要求しないように、動的承認結果で静的承認特権を更新するべきかどうかを含むことができる。
共通サービス機能（ＣＳＦ）は、サービス層によってサポートされるサービスのためのｏｎｅＭ２Ｍ用語である。共通サービスエンティティＣＳＥは、サービス層のためのｏｎｅＭ２Ｍ用語である。
既存のサービス層（例えば、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．１０．０、ＥＴＳＩ Ｍ２Ｍ Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ （Ｍ２Ｍ） Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、草案ＥＴＳＩ ＴＳ １０２ ６９０ １．１．１（２０１１−１０）に説明されるｏｎｅＭ２Ｍ、およびＯＭＡ Ｌｉｇｈｔｗｅｉｇｈｔ Ｍ２Ｍ（ＬＷＭ２Ｍ）技術仕様書、草案バージョン１．０（２０１３年３月１４日）に説明されるＯＭＡ ＬＷＭ２Ｍ）は、どのサービスまたはリソースにそれらの登録者（例えば、Ｍ２Ｍ／ＩｏＴデバイス）がアクセスすることを許可するか、および、登録者がこれらのリソースおよび／またはサービスに行うことが可能にされる動作のタイプを制御するための承認機構をサポートする。しかしながら、これらのサービス層承認機構は、典型的には、本質的に静的であるように構成され（例えば、事前プロビジョニングされ）、故に、以下の欠点を有する。
欠点＃１−新しい許可を動的に追加することによって、サービス層登録者が、アクセスする許可を有していないリソースへのアクセスを獲得することを可能にするサポートの欠如。結果として、登録者は、それらがアクセスするために静的に事前プロビジョニングされた承認ポリシを有するそれらのリソースおよび／またはサービスのみにアクセスすることに限定される。
欠点＃２−登録者が、登録者のリソースまたはサービスにアクセスしようとするがそうする適切な特権を有していない他の登録者にアクセスを付与したいか、拒否したいかを決定するために、登録者に対してサービス層によって行われる相談に関する承認を、サービス層内でホストされるリソースまたはサービスを所有もしくは管理する登録者が規定することを可能にする高度承認機構のためのサポートの欠如。結果として、登録者は、他の登録者がそれらのリソースまたはサービスにアクセスすることに関心があるかどうか、ひいては、そのような要求のためにアクセスを動的に承認すべきかどうかを検出することができない。
欠点＃３−サービス層内でホストされるリソースまたはサービスを所有もしくは管理する登録者が、要求登録者がアクセスのために自発的に支払う料金／手数料に関する承認を規定することを可能にする高度承認機構のためのサポートの欠如。結果として、登録者は、アクセスするために支払う他の登録者の意欲に基づいて、サービス層がアクセスを他の登録者に動的に承認することを可能にすることができない。
欠点＃４−サービス層内でホストされるリソースまたはサービスを所有もしくは管理する登録者が、要求登録者が自発的に合意するバータ協定に関する承認を規定することを可能にする高度承認機構のためのサポートの欠如。例えば、登録者が互いのリソースへのアクセスを付与するであろうという登録者間の二者間合意。結果として、登録者は、他の登録者のリソースまたはサービスへのアクセスを動的に獲得するために、商品としてそれらのリソースを交換して使用することができない。
欠点＃５−サービス層内でホストされるリソースまたはサービスを所有もしくは管理する登録者が、登録者が満たさなければならない要求されるセキュリティ査定レベルに関する承認を規定することを可能にする高度承認機構のためのサポートの欠如。例えば、登録者は、サービス層によって動的に行われるセキュリティレベル査定を他の登録者が満たすこと（例えば、プラットフォームがあるセキュリティ要件を満たす）に基づいて、そのリソースまたはサービスへのアクセスを他の登録者に動的に承認するようにサービス層を構成することができない。
欠点＃６−サービス層内でホストされるリソースまたはサービスを所有もしくは管理する登録者が、登録者が承認されるために満たさなければならない要求される評判査定レベルに関する承認を規定することを可能にする高度承認機構のためのサポートの欠如。例えば、登録者は、評判レベル査定を他の登録者が満たすこと（例えば、登録者の相互評価が「５つ星のうちの４つ」等のある満足度を満たす）に基づいて、そのリソースまたはサービスへのアクセスを他の登録者に動的に承認するようにサービス層を構成することができない。
以下のユースケースは、サービス層動的承認がサービス層によってサポートされることができる方法、ならびにその付加価値を説明する。このユースケースでは、アプリ＃１ ２０２は、サービス層内でホストされるＸＹＺと名付けられたリソースを作成する。アプリ＃１ ２０２は、次いで、静的アクセス特権の組でリソースＸＹＺのためのアクセス制御ポリシを構成する。静的アクセス特権は、リソースＸＹＺにアクセスすることを可能にされる他のアプリのリストと、他のアプリがリソースＸＹＺに対してどのような動作を行うことができる等の規則を定義する。これらの特権は、どのアプリがリソースにアクセスすることを可能にされるかと、どんな動作をそれらがリソースに行うことを可能にされるかとを制御するために、サービス層によって使用される。アプリ＃１ ２０２は、それが認識しており、アクセスを付与することを欲する既知のアプリでこれらの特権を構成することができる。アプリ＃１ ２０２は、リソースのための動的承認ポリシを構成することもできる。このポリシは、静的アクセス特権を動的に作成、更新、または削除することをサポートするためにサービス層によって使用されることができる規則を定義する。これは、新しい／異なるアプリがリソースにアクセスしようとするが、しかしながら、アプリ＃１ ２０２がこれらのアプリとの関係を事前に認識しておらず、故に、リソースへのアクセスをそれらに付与するための静的特権を構成していない場合をサポートするために特に有用である。
このユースケースでは、アプリ＃２ ２０４は、アプリ＃１が静的アクセス特権を付与していないアプリの例である。アプリ＃２ ２０４は、リソースＸＹＺへの要求を行う。サービス層は、最初に、静的アクセス特権をチェックし、アプリ＃２ ２０４が特権を与えられていないことを見出す。サービス層１０２は、次いで、動的承認ポリシが構成されているかどうかをチェックする。該当する場合、サービス層１０２は、静的アクセス特権を更新し、アクセス特権をこれらのアプリに付与するかどうかを査定する機能性をサポートすることができる。動的承認機能性は、図７に示されるような構成された動的承認ポリシを使用して、サービス層１０２によってローカルで行われることができる。代替として、サービス層１０２は、図８に示されるような動的承認を行うことにおいてサービス層１０２を支援させるように、システム内の他のエンティティ（例えば、承認サーバ）と相談することをサポートすることができる。
図７−８に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図７−９に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図７−８に図示されるステップを行う。図７−８に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（サービス層動的承認機能）
提案されたフレームワークは、図９に示されるようなサービス層動的承認（ＳＬＤＡ）機能９０２から成る。この機能は、要求側がアクセスするための特権をまだ事前確立していない、サービス層によってホストされる所望のリソースまたはサービスへのアクセス特権を要求側が付与されるものとするかどうかを決定するための要求に応じることをサポートする。この機能は、図９にも示される以下の４つのサブ機能から成る。
● ポリシ管理機能（ＳＬＤＡ−ＰＡ）９０４−サービス層動的承認ポリシを管理する。
● ポリシ決定点（ＳＬＤＡ−ＰＤ）９０８−サービス層動的承認決定を評価し、発行する。
● ポリシ施行点（ＳＬＤＡ−ＰＥ）９１０−サービス層リソースまたはサービスへの要求を途中で捕らえ、ＳＬＤＡ−ＰＤの決定を施行する。
● ポリシ情報点（ＳＬＤＡ−ＰＩ）９０６−セキュリティ、支払、場所、および評判査定等の追加のコンテキスト情報をＳＬＤＡ−ＰＤ９０８に提供する。
図９に図示される機能性は、以下で説明される図４４Ｃまたは図４４Ｄに図示されるもののうちの１つ等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。
（サービス層動的承認展開方式）
ＳＬＤＡ機能９０２は、いくつかの柔軟な展開方式をサポートする。ＳＬＤＡ機能９０２は、サービス層のローカル機能として展開されることができ、その場合、サービス層は、図１０に示されるように動的承認機能性を自然にサポートすることができる。
ＳＬＤＡ機能９０２は図１１に示されるように、サービス層とは別個に展開されることもできる。この場合、ＳＬＤＡ９０２は、ネットワーク内の独立型機能として展開されることができるか、または別のエンティティ（例えば、セキュリティサーバ）のサブ機能として展開されることができる。
ＳＬＤＡ９０２はまた、集中型様式で展開されることもでき、その場合、単一のＳＬＤＡ機能９０２は、複数のサービス層インスタンスならびにアプリケーションからの動的承認要求に応じることができる。この展開方式では、全ての動的承認管理、決定、ならびに施行は、図１２に示されるように、集中型ＳＬＤＡ９０２によって行われる。
逆に、ＳＬＤＡ９０２は、分散型様式で展開されることができ、その場合、ＳＬＤＡ９０２またはそのサブ機能は、ネットワークの全体を通して分散されることができる。例えば、ＳＬＤＡ−ＰＩ、ＳＬＤＡ−ＰＡ９０４、およびＳＬＤＡ−ＰＤ９０８サブ機能が、ネットワーク内の集中型ノード上に展開されることができる一方で、別個のＳＬＤＡ−ＰＥ９１０サブ機能は、図１３に示されるように、ネットワークの全体を通してサービス層インスタンスの各々内でローカルに展開されることができる。この分散型方式では、動的承認ポリシ情報、管理、および決定が、集中型ＳＬＤＡ−ＰＤ９０８によって行われることができる一方で、これらの決定の成果は、それらが処理する各要求のために個々のサービス層の個々のＳＬＤＡ−ＰＥによって施行されることができる。
図１０−１３に図示される機能性は、以下で説明される図４４Ｃまたは図４４Ｄに図示されるもののうちの１つ等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。
（サービス層動的承認プロセス）
承認プロセス：承認プロセスは、以下を伴う。
● 一般的承認規則のプロビジョニング
○ ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＥ１４１０、およびＳＬＳＡ−ＰＩ４１２への静的規則ならびにパラメータのプロビジョニング
○ ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、およびＳＬＤＡ−ＰＩ９０６２への動的規則ならびにパラメータのプロビジョニング
○ 静的規則と動的規則との間で調整する論理／規則のプロビジョニング
● 粒度の細かいリソース特定の承認規則の作成
○ リソースへのアクセスのための静的規則の作成
○ リソースへのアクセスのための動的規則の作成
● 承認されたエンティティにリソースへのアクセスを提供することは、以下を伴う
○ 動的承認規則をエンティティに伝える
○ エンティティが種々のレベルの承認（ＡｕｔｈＬｅｖｅｌ）を取得するための機構を提供する
○ 種々のタイプの動的承認（以下のうちの１つ以上のものの組み合わせ）を提供する：
・ 認証済み（単因子、多因子）
・ プラットフォーム完全性
・ アプリケーションまたはデバイスタイプ
・ 未認証
・ 支払またはサブスクリプションベース
・ 評判ベース
・ バータベース（データ／リソースの交換）
（承認規則のプロビジョニング）
図１４は、静的および動的ポリシの両方を伴うポリシ管理（プロビジョニング、決定、および施行）フレームワークを描写する。ＩｏＴサービスプロバイダは、既存の静的アクセスポリシ管理を有し得、動的承認の導入により、サービス層ポリシ調整機能（ＳＬ−ＰＣＦ）１４０８は、動的ポリシと静的ポリシとの調整、ならびにこれらのポリシの施行をハンドリングすることができる。動的ポリシおよび静的ポリシをそれぞれプロビジョニングするＳＬＤＡ−ＰＡ９０４およびＳＬＳＡ（サービス層静的承認）−ＰＡ１４０４が機能する。ＳＬＳＡ−ＰＡ１４０４は、適切なＰＤポリシ（セキュリティサーバ２において）と、それぞれのエンティティ（例えば、セキュリティゲートウェイ）におけるＰＥポリシとを構成する。
図１４に図示される機能性は、以下で説明される図４４Ｃまたは図４４Ｄに図示されるもののうちの１つ等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。
図１５は、ポリシプロビジョニングプロセスを描写し、ＳＬＤＡ−ＰＥ９１０、ＳＬＤＡ−ＰＤ９０８、およびＳＬＤＡ−ＰＩ９０６機能を実装するエンティティ１５０２は、適切なポリシをプロビジョニングされる。詳細なメッセージングが、以下で提供される。
適用可能であれば、セキュリティが重要である場合、エンティティと別のエンティティとの間で起こる全ての通信は、（例えば、ＴＬＳ／ＳＳＬ接続を使用して）セキュア通信チャネルを経由して起こり、エンドツーエンド様式で保護されることができる。
図１５のステップ１では、エンティティ１５０２は、ＰＥおよびＰＤに関するポリシの適切な組と、ＰＩのパラメータとの読み出しを要求する。読み出しプロセスは、周期的基準でトリガされ得るか、またはＳＬＤＡ−ＰＡ９０４を実装するポリシサーバ１５０４から帯域内もしくは帯域外シグナリングによってトリガされ得る。ポリシサーバ１５０４は、デバイス管理サーバのサービスを呼び出し得るか、またはそれと共同ホストされ得る。エンティティ１５０２は、リソースを識別する随意のポリシｉｄを含むことによって、ポリシに対する要求を送信する。
図１５のステップ２では、ＳＬＤＡ−ＰＡ９０４は、ポリシを取得する権限をエンティティ１５０２に与える既存の静的アクセス制御ポリシ（Ｓ−ＡＣＰ）があるかどうかを確認するためにチェックする。ＳＬＳＡ１４０２／ＳＬＤＡ９０２−ＰＡは、エンティティ１５０２がＰＤ／ＰＥ関連ポリシをプロビジョニングされる権限を与えられているかどうかをチェックするために、ＰＡに関連付けられるＳＡＰＤ−ＰＡ９０４（静的承認ポリシデータベース）をチェックする。エントリがエンティティ１５０２のために存在する場合、承認のレベルがポリシプロビジョニングの要件を満たすならば、処理は、ステップ１０に飛ぶ。
図１５のステップ３では、ＳＡＰＤの中にエンティティ１５０２のためのエントリがない場合、ＰＡは、エンティティ１５０２が承認されることが可能であり得る方法を決定するために、動的承認ポリシデータベース（ＤＡＰＤ）にクエリを行う。
図１５のステップ４では、ポリシサーバ１５０４は、動的承認規則（ＤＡＲ）を含む動的承認要求（ＤＡＲｅｑｕｅｓｔ）メッセージを行うようにエンティティ１５０２に要求する。規則は、以下を示し得る。
ａ． 承認レベル
ｂ． 明示的承認機構（例えば、認証、支払／サブスクリプション、プラットフォーム確認／完全性チェック等）
図１５のステップ５では、エンティティ１５０２は、以降の節で詳細に説明される、対応する動的承認有効化機能（ＤＡＥＦ）１８０２を用いて、要求される承認チェックプロセスを行う。実施されたチェックに基づいて、エンティティ１５０２は、対応するＤＡＥＦから動的承認パラメータ（ＤＡＰ）を取得するか、またはエンティティ１５０２によって決定もしくは生成され得る。ＤＡＰは、デジタル署名済み（例えば、署名された承認トークン、アクセストークン）、未署名、メッセージング（ＸＭＬメッセージング）、ＪＳＯＮデータ等である暗号証明情報であり得る。ＤＡＰが、種々の承認チェックの結果を含むパラメータを含み得るか、または、承認チェックの各々が、別個のＤＡＰをもたらし得る。
図１５のステップ６では、エンティティ１５０２は、次いで、動的承認応答（ＤＡＲｅｓｐｏｎｓｅ）メッセージを使用してＤＡＰをポリシサーバ１５０４／ＰＡに送信する。
図１５のステップ７では、ポリシサーバ１５０４／ＤＡは、ＤＡＰを検証し、ＤＡＲが満たされていることを確実にするためにチェックする。
図１５のステップ８では、ポリシサーバ１５０４は、エンティティｉｄ、ｒｅｓ−ｉｄ、可能にされる動作（例えば、読み出し）、ＤＡＰを識別するＤＡＰ−Ｉｄ、および可能にされる承認の持続時間を含むように、静的ポリシ（ＳＡＰＤ）を更新する。
図１５のステップ９では、ＳＡＰＤ−ＰＡは、次いで、ＰＥ規則、ＰＡ規則、およびＰＩデータ、ならびに認可された承認規則（ＡＡＲ）をプロビジョニングする。ＡＡＲは、以下についての情報を含み得る。
ａ．達成される承認レベル（ＡｕｔｈＬｅｖｅｌ）
ｂ．行われることができる動作のタイプ（作成／更新／読み出し／削除）
ｃ．動作が行われることができるリソース／リソースツリー
ｄ．承認の長さ（有効性／満了）
ｅ．ＡｕｔｈＬｅｖｅｌを強化するために行われる必要がある機構のリスト
ｆ．決して行われることができないリソース／動作
図１５に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１５に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１５に図示されるステップを行う。図１５に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（リソース特定の承認規則の作成）
リソースジェネレータまたは所有者であり得るエンティティ（エンティティＡ １６０２）は、リソースホスティング機能（ＲＨＦ１６０４）上へのデータのホスティングを要求する。ＲＨＦ１６０４は、ＳＬＤＡ機能性（ＰＥ、ＰＤ、およびＰＩ）を実装し得る。ここでは、エンティティに関連付けられる承認規則に関する全てのポリシが事前プロビジョニングされ、ＳＡＰＤ上にデータ投入されており、動的ポリシは、６．３．１に説明される機構に基づいてＤＡＰＤ上にプロビジョニングされることが仮定される。図示された図１６のメッセージング詳細が、続く。
図１６のステップ１では、エンティティは、関連付けられるリソースｉｄを有するリソースのホスティング／作成（ＴｅｍｐＲｅａｄｉｎｇ１）を要求し、それとともに、関連付けられる静的ＡＣＰ（Ｓ−ＡＣＰ）および動的ＡＣＰ（Ｄ−ＡＣＰ）が、リソース登録要求（ＲＲＲｅｑｕｅｓｔ）メッセージの一部として、ＳＬＤＡを実装するＲＨＦ１６０４に送信される。
図１６のステップ２では、ＲＨＦ１６０４は、ＳＡＰＤを用いて行われたチェックに基づいて、エンティティＡ １６０２が承認を有するかどうかを確認するようにチェックする。エントリが存在する場合、メッセージングは、ステップ９に飛ぶ。
図１６のステップ３では、いかなるＳ−ＡＣＰもエンティティからの要求に対して合致しない場合、ＲＨＦ１６０４は、ＤＡＰＤから動的承認規則を取得する。
図１６のステップ４では、ＲＨＦ１６０４は、動的承認要求（ＤＡＲ）メッセージを使用して規則（ＤＡＲ）をエンティティＡ １６０２に送信する。
図１６のステップ５では、エンティティＡ １６０２は、ＲＨＦ１６０４から取得されたＤＡＲに基づいて、種々の承認チェックを行う。エンティティＡ １６０２は、承認チェックを保証するＤＡＰを取得／生成する。
図１６のステップ６では、エンティティＡ １６０２は、ＤＡＲｅｓｐｏｎｓｅメッセージを使用してＤＡＰをＲＨＦ１６０４に送信する。
図１６のステップ７では、ＲＨＦ１６０４は、ＤＡＰに対するチェックを行い、それがＤＡＲに合致することを検証する。
図１６のステップ８では、ＤＡＰが成功裏に検証された場合、ＳＡＰＤは、エンティティｉｄ、可能にされる動作、アクセス可能なリソース、ＤＡＰ−Ｉｄ、有効性等を示す適切な値をデータ投入される。
図１６のステップ９では、ＲＨＦ１６０４は、エンティティＡ １６０２リソースを登録して作成し、Ｓ−ＡＣＰおよびＤ−ＡＣＰをエンティティＡ １６０２リソースに関連付ける。
図１６のステップ１０では、ＲＨＦ１６０４は、ＡＡＲを含むＲＲＲｅｓｐｏｎｓｅを転送する。
図１６に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１６に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１６に図示されるステップを行う。図１６に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（承認されたアクセスプロセス）
図１７は、ＲＨＦ１６０４上でホストされるリソースにアクセスすることを欲するクライアント１７０２を描写する。ＲＨＦ１６０４は、ＳＬＤＡ−ＰＥ９１０、ＰＩ、ＰＤ機能を実装し、加えて、ＰＡ機能もホストする。したがって、システム管理者は、インターフェースを使用して、ＰＡを用いてＲＨＦ１６０４上でＰＥおよびＰＤポリシを構成することができるであろう。メッセージフローは、図１６で描写され、６．３．２に説明された前のフローの継続と見なされ得る。メッセージング詳細が、続く。
図１７のステップ１では、クライアント１７０２は、リソースｉｄ、随意に、リソースの名称および要求される動作のタイプを含むリソースアクセス要求（ＲＡＲｅｑｕｅｓｔ）メッセージを送信する。それはまた、ある持続時間に対してリソースに明示的に要求し得、それは、随意である。
図１７のステップ２では、ＲＨＦ１６０４は、Ｓ−ＡＣＰに基づいて、クライアント１７０２が承認されているかどうかを決定する。それが承認されている場合、メッセージングは、ステップ１０に飛ぶ。
図１７のステップ３では、クライアント１７０２が承認されていない場合、ＲＨＦ１６０４は、動的承認ポリシ（Ｄ−ＡＣＰ）を決定し、ＤＡＲを作成する。「持続時間」値がＲＡＲｅｑｕｅｓｔ内に存在した場合、Ｄ−ＡＣＰは、「持続時間」値を満たすように調整され得る。持続時間「値」が閾値よりも高い場合、より高いレベルの承認が行われる必要があり得る。
図１７のステップ４では、ＲＨＦは、ＤＡＲを含むＤＡＲｅｑｕｅｓｔを送信する。
図１７のステップ５では、クライアント１７０２は、ＤＡＲを満たすために、適切なＤＡＥＦを用いて適切な承認チェックを行う。クライアント１７０２は、種々のチェックを保証するＤＡＰを取得または生成する。
図１７のステップ６では、クライアント１７０２は、ＤＡＰを含むＤＡＲｅｓｐｏｎｓｅメッセージを使用して、ＤＡＰをＲＨＦ１６０４に送信する。
図１７のステップ７では、ＲＨＦ１６０４は、ＤＡＰを検証し、ＤＡＲと比較する。
図１６のステップ８では、ＤＡＰがＤＡＲの要件を満たす場合、ＲＦＨは、クライアント−ｉｄ、ｒｅｓ−ｉｄ、ｏｐ、持続時間、ＤＡＰ−ＩｄでＳＡＰＤを更新し得る。
図１７のステップ９では、ＲＨＦ１６０４は、リソースおよびＡＡＲを含むＲＡＲｅｓｐｏｎｓｅメッセージを送信する。
図１７に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１７に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１７に図示されるステップを行う。図１７に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（分散型ポリシエンティティおよび承認モデル）
図１６および１７に関して、ＰＤおよびＰＥ等のポリシ機能は、同一のエンティティ（例えば、ＲＨＦ１６０４）上でホストされた。ここでは、ＳＬＤＡ−ＰＤ９０８／ＳＬＤＡ−ＰＩが、同一のエンティティ上でホストされ得る一方で、ＳＬＤＡ−ＰＥ９１０は、ＲＨＦ１６０４上でホストされる機構を提供する。加えて、種々の承認モデルをサポートするソリューションが追究される。
（ＰＵＳＨモデル）
ＰＵＳＨモデルは、ＲＨＦ１６０４が制約されたエンティティである一方で、クライアント１７０２が制約されていないデバイス、またはあまり制約されていないデバイスであると仮定されるとき、好適であり得る。前述のように、高度なセキュリティを要求する全ての通信は、（例えば、ＴＬＳ／ＳＳＬを使用して）機密性、完全性、および認証のために保護されるセキュア通信チャネルを経由してトランスポートされ得る。図１８は、ＰＵＳＨモデルを使用するリソースアクセスを図示する。メッセージング詳細が、続く。
図１８のステップ０では、ここで、クライアント１７０２が、リソースおよび関連付けられるリソースｉｄと、ＳＬＤＡ−ＰＤ９０８とを発見することが仮定され、ＳＬＤＡ−ＰＤは、クライアント１７０２がリソースにアクセスすることができるためにクライアント１７０２を承認することが可能であり得る。
図１８のステップ１では、クライアント１７０２は、クライアント−ｉｄおよびリソースｉｄ（Ｒｅｓ−ｉｄ）を含むＤＡＲｅｑｕｅｓｔを送信する。
図１８のステップ２では、ＳＬＤＡ−ＰＤ９０８は、プロビジョニングされた規則に基づいて、クライアント−ｉｄによって識別されるクライアント１７０２がＲｅｓ−ｉｄによって識別されるリソースにアクセスすることを可能にする動的承認ポリシを取得する。ＰＤは、ある場合、クライアント−ＩｄおよびＲｅｓ−ｉｄに基づいて、動的承認ポリシを生成する必要があり得る。
図１８のステップ３では、ＰＤは、各ＤＡＥＦ１８０２に関連付けられるＵＲＩのリストを含み、各承認チェックに関連付けられる承認レベル（ＡｕｔｈＬｅｖｅｌ）のリストも含む承認チェック要求（ＡＣＲｅｑｕｅｓｔ）を送信する。ＡｕｔｈＬｅｖｅｌの例が、以下で提供される。
ａ． 認証：ＡｕｔｈＬｅｖｅｌ＝高／中／低
ｂ． プラットフォーム完全性／確認：ＡｕｔｈＬｅｖｅｌ＝高／中／低
ｃ． サブスクリプション：ＡｕｔｈＬｅｖｅｌ＝プラチナ／ゴールド／シルバー
ｄ． 評判：ＡｕｔｈＬｅｖｅｌ＝高／中／低
図１８のステップ４では、クライアント１７０２は、６．３．４．２でもう少し詳細に説明される承認チェックプロセス（ＡＣＰｒｏｃｅｓｓ）を行う。クライアント１７０２は、提供されるＤＡＥＦ１８０２リストおよび各チェックに関連付けられるＡｕｔｈＬｅｖｅｌに基づいて、多因子認証サーバ、支払サーバ、プラットフォーム確認サーバ等とのチェックを行い得る。このプロセスは、帯域内プロセスであり得るか、または帯域外で実施され得る。シナリオおよびユースケースに基づいて、特に匿名アクセスが要求されるとき、認証が省略される可能性がある。
図１８のステップ５では、ＡＣＰｒｏｃｅｓｓの結果として、承認チェックの各々を確認する未加工データであるいくつかの承認チェック値（ＡＣＶ）が生成され得る。加えて、かつおそらく随意に、ＤＡＰが、各承認チェックのために作成され得る。ＤＡＰは、承認チェックを保証し、承認のために要求される関連情報のみを含むＡＣＶの濃縮バージョンと見なされることができる。クライアント１７０２は、ＡＣＶ／ＤＡＰをＰＤに送信する。
図１８のステップ６では、ＰＤが、真正性、完全性、および正確度に対してＡＣＶ／ＤＡＰを検証すると、ＰＤは、デジタル署名されるかまたは各ＤＡＰをデジタル署名する単一のＣ−ＤＡＰに全てのＤＡＰを統合し、それをクライアント１７０２に転送し得る。
図１８のステップ７では、クライアント１７０２は、Ｒｅｓ−ｉｄ、ｏｐ、およびＤＡＰを含むＲＡＲｅｑｕｅｓｔを作成し、ＲＨＦ１６０４に送信する。
図１８のステップ８では、クライアント１７０２がＤＡＰを送信したので、ＰＥを実装するＲＨＦ１６０４は、静的ポリシにエントリがないこともあることを推測し、したがって、ＳＡＰＤ−ＰＥをチェックせず、代わりに、ＤＡＰＤ−ＰＥの中のＤ−ＡＣＰをチェックすることによって、ＤＡＰがｒｅｓ−ｉｄに関連付けられる動的承認ポリシの要件に合致することをチェックする。
図１８のステップ９では、ＤＡＰが承認要件を満たす場合、ＰＥは、クライアント−ｉｄ、ｒｅｓ−ｉｄ、ｏｐ、持続時間、ＤＡＰ−Ｉｄ、随意に、ＤＡＰでＳＡＰＤ−ＰＥを更新する。ＤＡＰは、ＤＡＰのサイズが大きく、管理することが煩雑であり得るので、ＤＡＰ−Ｉｄによって別個に識別され、記憶され得る。
図１８のステップ１０では、ＲＨＦ１６０４は、リソースならびに関連付けられるＡＡＲをクライアント１７０２に送信する。
図１８に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１８に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１８に図示されるステップを行う。図１８に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（承認チェックプロセス（ＡＣプロセス））
図１９は、支払プロセスを伴うプロセスを伴うＡＣプロセスを描写する。クライアント１７０２は、ＤＡＥＦ−支払サーバを認識していない可能性があり得るが、しかしながら、クライアント１７０２は、ＳＬＤＡ−ＰＤ９０８を信頼し、ＳＬＤＡ−ＰＤ９０８は、ＤＡＥＦ−支払サーバを信頼している。メッセージング詳細は、以下。
図１９のステップ４ａでは、クライアント１７０２は、ＤＡＥＦ−支払への支払承認を要求する。クライアント１７０２は、ＳＬＤＡ−ＰＤ９０８によってリダイレクトされ得るか、ＳＬＤＡ−ＰＤ９０８によってＤＡＥＦ−支払サーバのＵＲＩを提供される、もしくはクライアント１７０２によって発見される。クライアント１７０２は、ＰａｙｍｅｎｔＲｅｑｕｅｓｔを行い、支払の通貨および金額（例えば、仮想通貨）、トランザクションをＳＬＤＡ−ＰＤ ＡＣＲｅｑｕｅｓｔと結び付ける要求−Ｉｄを提供する。
図１９のステップ４ｂでは、ＤＡＥＦ１８０２は、ＰａｙｍｅｎｔＴｒａｎｓａｃｔｉｏｎプロセスを開始し、金額は、クライアント１７０２によってＤＡＥＦ１８０２に送信される。
図１９のステップ４ｃでは、そのトランザクションを詳述するＡＣＶを生成し、随意に、支払およびトランザクションの検証を提供するＤＡＰを生成し得る。支払ＤＡＰは、ＪＳＯＮデータ、ＸＭＬ、ＣＢＯＲデータ、明示的メッセージ、ＪＳＯＮウェブトークン等を使用して表され得る。ＤＡＰ−支払の好ましいコンテンツのリストが、以下で提供される。
● トランザクション−Ｉｄ：５４２９１２３７９５４２３９５
● 要求−Ｉｄ：
● 買戻人−Ｉｄ：ＳＬＤＡ−ＰＤ−ＵＲＩ
● 日付：１３／１１／１５
● 時間：２３：２３時間
● 発行人：ＤＡＥＦ−Ｐａｙｍｅｎｔ−ＵＲＩ
● 発行先：クライアント
● 通貨：ビットコイン
● 金額：１００．００
● 発行元のデジタル署名：Ｄ２８Ｂ４５ＢＡ２３４Ｃ４５２ＤＢ・・・
図１９のステップ４ｄでは、ＤＡＥＦ１８０２は、ＤＡＰ／ＡＣＶをクライアント１７０２に転送する。随意に、ＤＡＰ−Ｉｄのみが、ＤＡＥＦ−支払によってクライアント１７０２に提供される。
図１９のステップ５では、クライアント１７０２は、ＤＡＰ、随意に、ＡＣＶを含むＡＣＲｅｓｐｏｎｓｅをＳＬＤＡ−ＰＤに送信する。このメッセージは、ＤＡＥＦ１８０２によってＳＬＤＡ−ＰＤ９０８にリダイレクトされ得るか、またはクライアント１７０２によって送信される。ＳＬＤＡ−ＰＤ９０８は、トランザクション−ｉｄ、支払情報、要求−Ｉｄ、および他の関連情報を登録し、適切な承認確認を提供する。ＳＬＤＡ−ＰＤ９０８は、支払ＤＡＰがクライアント１７０２によって再生されないことを確実にする必要がある。ＤＡＰ−Ｉｄのみがクライアント１７０２によって提供された場合、ＳＬＤＡ−ＰＤ９０８は、ＤＡＥＦ１８０２からＤＡＰをフェッチしなければならず、検証されると、ＤＡＥＦ１８０２が支払いを清算されていると見なし、トランザクションクレジットが再利用されることができないことを意味する「充足」としてトランザクションを行う。
図１９について上で説明される承認チェックプロセスは、支払承認を扱うが、しかしながら、類似機構が、他の承認チェック（例えば、多因子認証、プラットフォーム確認、サブスクリプション等）を行うために使用され得ることに留意されたい。図１９のステップ４ｂは、クライアントと他の承認チェックを行うために使用される対応するＤＡＥＦとの間のメッセージと置換され得る。ＯｐｅｎＩＤ、ＯｐｅｎＩＤ−Ｃｏｎｎｅｃｔ、ＥＡＰ、ＳＡＭＬ等のプロトコルフレームワークを活用することによって承認チェックを行い、これらの既存のプロトコルフレームワークの上にここで説明される機構をピギーバックすることも可能であり得る。
図１９に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１９に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１９に図示されるステップを行う。図１９に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（ＰＵＬＬモデル）
制約されたクライアント１７０２は、リソースへのアクセスを要求し、ＲＨＦ１６０４によって促進される承認を行い得る。メッセージング詳細が、図２０に関して以下で提供される。
図２０のステップ１では、クライアント１７０２は、ＲＲＲｅｑｕｅｓｔを使用して、Ｒｅｓ−ｉｄによって識別されるリソース、ＲＨＦ１６０４を用いたｏｐ＝”ｒｅｔｒｉｅｖｅ”を要求する。ＲＨＦ１６０４は、ＳＬＤＡ−ＰＥ９１０機能性を実装する。
図２０のステップ２では、ＲＨＦ１６０４は、静的ＳＡＰＤ−ＰＥをチェックすることによって、クライアント１７０２が承認されているかどうかを検証するためにＳ−ＡＣＰをチェックする。クライアント１７０２がリソースに動作を行う権限を与えられている場合、メッセージングは、ステップ１２に飛ぶ。
図２０のステップ３では、ＳＬＤＡ−ＰＥ９１０は、動的承認ポリシをチェックし、ＤＡＲを決定する。
図２０のステップ４では、ＳＬＤＡ−ＰＥ９１０は、ＤＡＲ、クライアント−Ｉｄ、およびＲｅｓ−Ｉｄを含むＤＡＲｅｑｕｅｓｔを作成し、それをＳＬＤＡ−ＰＤに送信する。代替として、ＰＥは、承認チェックの明示的リストＡＣＬｉｓｔ［］と、達成されることが期待される関連付けられるＡｕｔｈＬｅｖｅｌ［］とを提供する。
図２０のステップ５では、ＳＬＤＡ−ＰＤ９０８は、承認が実施され、ＡｕｔｈＬｅｖｅｌが達成されるためにコンタクトされる必要があろうＤＡＥＦを決定する。
図２０のステップ６では、ＳＬＤＡ−ＰＤ９０８は、クライアント−Ｉｄおよび関連付けられるＡＡＬを含むＡＣＲｅｑｕｅｓｔをＤＡＥＦの各々に送信する。
図２０のステップ７では、クライアント１７０２とＤＡＥＦの各々とは、承認チェック（例えば、支払、プラットフォーム確認、認証等）毎に６．３．３に説明されるＡＣＰｒｏｃｅｓｓを行う。クライアント１７０２とＤＡＥＦの各々との間のメッセージングは、ＲＨＦ１６０４を介して、または直接的様式で他の手段によって、帯域内もしくは帯域外メッセージングのいずれかで行われ得る。
図２０のステップ８では、ＡＣＰｒｏｃｅｓｓ、ＤＡＥＦの各々は、ＡＣＶ／ＤＡＰをＳＬＤＡ−ＰＤに送信する。
図２０のステップ９では、ＳＬＤＡ−ＰＤ９０８は、ＡＣＶ／ＤＡＰの各々を検証し、随意に、連結ＤＡＰ（Ｃ−ＤＡＰ）（それは、ＤＡＥＦ１８０２の各々から個々のＤＡＰの各々において提供される情報、ＳＬＤＡ−ＰＤ９０８によってデジタル署名されたＤＡＲｅｓｐｏｎｓｅを含む）を作成し、それは、ＤＡＲｅｓｐｏｎｓｅを使用してＲＨＦ１６０４に送信される。代替として、ＳＬＤＡ−ＰＤ９０８は、連結または署名を伴わずにＤＡＰの各々を送信する。
図２０のステップ１０では、ＳＬＤＡ−ＰＥ９１０は、ＤＡＰを検証し、それがリソースに関連付けられるＤ−ＡＣＰに合致することを確実にする。
図２０のステップ１１では、ＤＡＰが要件に合致する場合、ＳＬＤＡ−ＰＥ９１０は、クライアント−Ｉｄ、Ｒｅｓ−Ｉｄ、ｏｐ、持続時間、ＤＡＰ−Ｉｄ、ＤＡＰ（随意）でＳＡＰＤ−ＰＥ９１０の中の静的アクセスポリシを更新する。
図２０のステップ１２では、ＳＬＤＡ−ＰＥ９１０／ＲＨＦ１６０４は、リソースおよびＡＡＲをクライアントに送信する。
図２０に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図２０に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図２０に図示されるステップを行う。図２０に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（ＰＵＳＨ確認モデル）
ＰＵＳＨ確認モデルでは、ＰＵＳＨモデルに非常に厳密に従う。図示された図２１を反映するメッセージング詳細が、以下で提供される。
図２１のステップ１では、クライアント１７０２は、Ｒｅｓ−Ｉｄ、クライアント−Ｉｄ、ｏｐを含む、ＤＡＲｅｑｕｅｓｔを要求する。
図２１のステップ２では、クライアント−Ｉｄ、Ｒｅｓ−Ｉｄ、およびｏｐに基づいて、ＳＬＤＡ−ＰＤ９０８は、Ｄ−ＡＣＰの正しい組を決定する。
図２１のステップ３では、ＳＬＤＡ−ＰＤ９０８は、ＤＡＥＦ−ＵＲＩ［］のリストおよび関連付けられるＡＡＬ［］を含む、ＡＣＲｅｑｕｅｓｔを送信する。
図２１のステップ４では、クライアント１７０２は、ＤＡＥＦの各々を用いて、各承認チェックに関連付けられるＡＡＬに基づいて、ＡＣＰｒｏｃｅｓｓを行う。クライアント１７０２は、ＡＣＶもしくはＤＡＰではなく、ＡＣＶ−Ｉｄおよび／またはＤＡＰ−Ｉｄをプロビジョニングされる。
図２１のステップ５では、クライアント１７０２は、ＡＣＲｅｓｐｏｎｓｅを使用して、ＡＣＶ−Ｉｄおよび／またはＤＡＰ−ＩｄをＳＬＤＡ−ＰＤ９０８に転送する。
図２１のステップ６では、ＳＬＤＡ−ＰＤ９０８は、ＤＡＥＦ１８０２の各々とＡＣＶ−Ｉｄおよび／またはＤＡＰ−Ｉｄを含むＡＣＶ−要求を行う。
図２１のステップ７では、ＤＡＥＦは、ＡＣＶ−応答メッセージを使用して、対応するＡＣＶおよび／またはＤＡＰで応答する。
図２１のステップ８では、ＳＬＤＡ−ＰＤ９０８は、ＤＡＰジェネレータ機能（ＤＧＦ）２１０２へのＡＣＶ［］および／またはＤＡＰ［］を含むＤＡＰ生成要求（ＤＡＰＧＲｅｑｕｅｓｔ）メッセージを用いて、Ｃ−ＤＡＰの作成を要求する。
図２１のステップ９では、ＡＣＶ［］および／またはＤＡＰ［］に基づいて、ＤＧＦ２１０２は、Ｃ−ＤＡＰおよび関連付けられるＣ−ＤＡＰ−Ｉｄを生成し、ＤＡＰデータベース（ＤＡＰ−Ｄ）内にそれを記憶する。
図２１のステップ１０では、ＤＧＦ２１０２は、Ｃ−ＤＡＰ−ＩｄをＳＬＤＡ−ＰＤに送信する。
図２１のステップ１１では、ＳＬＤＡ９０２は、ＤＡＲｅｓｐｏｎｓｅメッセージを使用して、Ｃ−ＤＡＰ−Ｉｄをクライアント１７０２に送信する。
図２１のステップ１２では、クライアント１７０２は、ＲＨＦ１６０４へのＲｅｓ−Ｉｄ、ｏｐ、クライアント−Ｉｄ、Ｃ−ＤＡＰ−Ｉｄを含むＲＡＲｅｑｕｅｓｔを行う。
図２１のステップ１３では、ＲＨＦ１６０４は、ＤＡＰＲｅｑｕｅｓｔメッセージを使用して、Ｃ−ＤＡＰ−ＩｄをＤＧＦ２１０２に送信する。
図２１のステップ１４では、ＤＧＦ２１０２は、それにＣ−ＤＡＰをプロビジョニングする前に、ＲＨＦ１６０４の承認を検証し得る。
図２１のステップ１５では、ＲＨＦ１６０４は、Ｄ−ＡＣＰを用いてＣ−ＤＡＰを検証する。
図２１のステップ１６では、Ｃ−ＤＡＰが承認要件を満たす場合、ＲＨＦ１６０４は、クライアント−Ｉｄ、Ｒｅｓ−Ｉｄ、ｏｐ、持続時間、Ｃ−ＤＡＰ−Ｉｄ、およびＣ−ＤＡＰ（随意）でＳＡＰＤ−ＰＥを更新する。
図２１のステップ１７では、ＲＨＦ１６０４は、リソースおよびＡＡＲをクライアント１７０２に送信する。
図２１に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図２１に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図２１に図示されるステップを行う。図２１に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（間接的ＰＵＳＨ）
図２２には、間接的プッシュモデルに基づく承認が図示されている。メッセージング詳細が、続く。
図２２のステップ１−４は、図２１と同一である。
図２２のステップ５では、クライアント１７０２は、行われる各承認チェックのためにＡＣＶ［］および／またはＤＡＰ［］を取得／生成し、ＡＣＶおよびＤＡＰを含むＡＣＲｅｓｐｏｎｓｅをＳＬＤＡ−ＰＤ９０８に送信する。
図２２のステップ６では、ＳＬＤＡ−ＰＤ９０８は、ＡＣＶ［］および／またはＤＡＰ［］を検証し、それらが容認可能である場合、ＳＬＤＡ−ＰＤ９０８は、Ｃ−ＤＡＰを生成する。
図２２のステップ７では、ＳＬＤＡ−ＰＤ９０８は、Ｃ−ＤＡＰを含むＤＡＰプロビジョニング（ＤＡＰＰｒｏｖｉｓｉｏｎｉｎｇ）メッセージをＲＨＦ１６０４に送信する。ＲＨＦ１６０４のＵＲＩは、クライアント１７０２によって提供されたＲｅｓ−Ｉｄに基づいて決定される。
図２２のステップ８では、ＲＨＦ１６０４（ＳＬＤＡ−ＰＥ）は、Ｃ−ＤＡＰを検証し、Ｃ−ＤＡＰがリソースに関連付けられるＤ−ＡＣＰの要件を満たすことを確実にする。ＳＤＰＡ−ＰＥは、ＤＡＰ−Ｄｂの中へＣ−ＤＡＰを記憶する。
図２２のステップ９では、ＳＬＤＡ−ＰＥ９１０は、承認の「持続時間」がａｕｔｈｏｒｉｚａｔｉｏｎ＿ｄｕｒａｔｉｏｎ＿ｔｈｒｅｓｈｏｌｄを超える場合、ＡＣＰデータベース（ＳＡＰＤ−ＰＥ）の中へエントリを作成する。したがって、動的承認チェックは、承認持続時間が非常に大きいならば、静的承認規則を作成させる。
図２２のステップ１０では、ＤＡＰが容認可能である場合、ＳＬＤＡ−ＰＥ９１０は、「成功メッセージ」を含むＤＡＰＲｅｓｐｏｎｓｅメッセージを送信する。
図２２のステップ１１では、ＳＬＤＡ−ＰＤ９０８は、「成功メッセージ」を含むＤＡＲｅｓｐｏｎｓｅメッセージをクライアント１７０２に送信する。
図２２のステップ１２では、ＳＬＤＡ−ＰＤ９０８から「成功メッセージ」を受信すると、クライアント１７０２は、Ｒｅｓ−Ｉｄ、ｏｐ、クライアント−Ｉｄを含むＲＡＲｅｑｕｅｓｔを開始する。
図２２のステップ１３では、ＳＬＤＡ−ＰＥ９１０は、ＳＡＰＤ−ＰＥの中の静的Ｓ−ＡＣＰをチェックし、合致を見出す。
図２２のステップ１４では、ＲＨＦ１６０４は、リソースおよびＡＡＲをクライアント１７０２に送信する。
図２２に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図２２に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図２２に図示されるステップを行う。図２２に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（ｏｎｅＭ２Ｍサービス層動的承認実施形態）
以下の項は、ｏｎｅＭ２Ｍシステムが本開示で提案されるＳＬＤＡ機能性をサポートすることを可能にする、アーキテクチャ、リソース、およびプロシージャのレベル強化を提案する。
提案されるｏｎｅＭ２Ｍ強化の概要は、以下を含む。
１）どのタイプのｏｎｅＭ２Ｍエンティティ上にＳＬＤＡ機能性がホストされることができるか（例えば、ＭＥＦ２３０４、ＭＡＦ２３０２、およびＣＳＥ）を示すｏｎｅＭ２Ｍシステム内のＳＬＤＡ機能性のアーキテクチャレベル実施形態。
２）既存のｏｎｅＭ２Ｍ定義＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのいくつかの提案される強化。提案される強化は、特権リスト内の個々の特権の部分的アドレスを可能にする特権リスト内の個々の特権のための識別子と、各個々の特権の有効期限と、支払ベース、交換ベース、評判ベース、およびセキュリティ査定ベースの動的承認を伴うユースケースをサポートする新しいタイプの承認コンテキストの定義とを含む。
３）サービス層動的承認ポリシの構成をサポートするためのｏｎｅＭ２Ｍ＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースおよび属性の定義。
４）動的承認が行われるべきことを明示的に要求することをサポートするためのｏｎｅＭ２Ｍ＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースと対応する要求および応答メッセージフォーマットとの定義。
５）動的承認が行われるべきことを明示的に要求することを相談する能力をサポートするためのｏｎｅＭ２Ｍ＜ｃｏｎｓｕｌｔ＞リソースと対応する要求および応答メッセージフォーマットとの定義。
６）異なるタイプの動的承認機能性がｏｎｅＭ２Ｍシステム内でサポートされることができる方法のメッセージシーケンスレベル記述を提供するいくつかのｏｎｅＭ２Ｍプロシージャの定義。
（ｏｎｅＭ２Ｍサービス層動的承認アーキテクチャ）
本開示で提案されるＳＬＤＡ機能９０２は、随意に、図２３に示されるようなＣＳＥ、ＭＥＦ２３０４、またはＭＡＦ２３０２を含む種々のｏｎｅＭ２Ｍ定義エンティティ上でホストされることができる。ＳＬＤＡ機能９０２は、集中型であり、これらのｏｎｅＭ２Ｍ定義エンティティのうちの１つの上でその全体としてホストされることができるか、または代替として、ＳＬＤＡ機能９０２は、そのサブ機能（ＳＬＤＡ−ＰＡ、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、およびＳＬＤＡ−ＰＩ）が、図２４に示されるように複数のｏｎｅＭ２Ｍエンティティを横断して分散型様式でホストされ得るように、区分化されることができる。例えば、ＳＬＤＡ−ＰＩサブ機能は、ＭＥＦ２３０４上で、ＳＬＤＡ−ＰＤ９０８およびＳＬＤＡ−ＰＡ９０４サブ機能は、ＭＡＦ２３０２上で、ＳＬＤＡ−ＰＥ９１０サブ機能は、ＣＳＥ上でホストされることができる。分散型様式でホストされるとき、ＳＬＤＡ９０２サブ機能は、互いに調整し、動的承認機能を果たすことができる。
図２３−２４に図示される機能性は、以下で説明される図４４Ｃまたは図４４Ｄに図示されるもののうちの１つ等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。
（ｏｎｅＭ２Ｍサービス層動的承認リソース）
リソース構造を説明するための図式的表現は、以下である。
● 四角いボックスは、リソースおよび子リソースに使用される
● 楕円は、属性に使用される
● 「＜」および「＞」で区切られたリソース名は、リソースの作成中にリソースの名称が割り当てられることを示す
● 強調表示されたリソースおよび属性は、ＳＬＤＡ機能性をサポートするように本開示によって提案される新しいリソースおよび属性である
＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース
図２５に示される、提案される＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースは、動的承認規則でＳＬＤＡ機能９０２を構成するためのインターフェースとしての役割を果たすことができる。このリソースは、ＳＬＤＡ９０２ポリシを作成、読み出し、更新、および削除するために使用されることができる。１つ以上の＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースで構成されると、ＳＬＤＡ機能９０２は、ポリシ内で定義される規則を使用し、動的承認意思決定を行うことができる。
限定されないが、相談ベース、支払ベース、バータベース、セキュリティ査定ベース、および評判ベースのポリシを含む本開示によって定義されるもの等の種々のタイプの動的承認規則が、サポートされることができる。ｏｎｅＭ２Ｍシステムにおいて規則の各々を表す方法がさらに、以下の項で詳細に説明される。
動的承認規則に加えて、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースは、ｓｅｌｆａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性をサポートすることもできる。この属性は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース自体のためのアクセス特権を定義するアクセス制御ポリシを参照するために、使用されることができる。これらの特権は、どのエンティティが＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースおよびその属性にアクセスする（例えば、読み出す、更新する、または削除する）ことを可能にされるかを制御するために使用されることができる。
随意に、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースは、ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性をサポートすることもでき、この属性は、１つ以上の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへのリンクのリストで構成されることができ、ＳＬＤＡ機能９０２は、この＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースを使用し、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの静的特権を動的に作成、更新、または削除することができる。
＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースと明示的にリンクするためにａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性を使用する提案された明示的方法を使用するのではなく、いくつかのユースケース実施形態の使用を介して、暗示的方法も以下で定義される。
例えば、図２６に示されるように、ｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性が、既存のｏｎｅＭ２Ｍリソース（例えば、＜ｃｏｎｔａｉｎｅｒ＞リソース）に追加されることができる。この属性は、ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性を使用してｏｎｅＭ２Ｍリソースを＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞とリンクするためのｏｎｅＭ２Ｍの現在のサポートと同様に、ｏｎｅＭ２Ｍリソースを＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースとリンクするために使用されることができる。ＳＬＤＡ機能９０２は、ひいては、単純に、ｏｎｅＭ２ＭリソースによってサポートされるａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓおよびｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性を利用することによって、どの＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースどの＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースによって管理され得るかを決定することができる。例えば、図２６に示される＜ｃｏｎｔａｉｎｅｒ＞リソースにアクセスするために要求が行われる場合、コンテナのａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性によって参照される＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞が、要求側が所望の動作を行うことを可能にするための特権を有しているかどうかを決定するためにチェックが最初に行われ得る。該当する場合、要求が続行することを可能にされ得、動的承認は要求されないであろう。しかしながら、要求側が適切な特権を有していない場合、ＳＬＤＡ機能９０２は、動的承認を試行して行うためにトリガされ得る。ＳＬＤＡ機能９０２は、最初に、＜ｃｏｎｔａｉｎｅｒ＞リソースが、有効な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースにリンクするように構成されたｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性を有しているかどうかをチェックし得る。該当する場合、ＳＬＤＡ機能９０２は、次いで、ｄｙｎＡｕｔｈＲｕｌｅｓ属性にアクセスし、要求側に特権を付与するか、拒否するかを決定するためにそれを使用し得る。それは、この要求のためにのみならず、将来の要求のためにも特権を付与すべきかどうかを決定するために、ｐｒｉｖｉｌｅｄｇｅＬｉｆｅｔｉｍｅ属性を使用し得る。将来の要求の場合、それは、＜ｃｏｎｔａｉｎｅｒ＞によってリンクされる＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内の静的特権を更新し得る。ＳＬＤＡ機能９０２は、コンテナのａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性によってリンクされる＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの特権を更新することによって、これを行い得る。
代替として、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースは、代わりに、図２７に示されるように、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの子リソースとして作成され得る。要求側が標的リソースに所望の動作を行う適切な特権を有していないことが見出された場合／とき、ＳＬＤＡ機能９０２は、対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースが＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞子リソースを有しているかどうかをチェックし得る。該当する場合、ＳＬＤＡ機能９０２は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞子リソースによって規定される規則に基づいて、それが適切な特権を要求側に動的に付与し得るかどうかをチェックし得る。
さらに、別の代替として、ｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性が、代わりに、図２８に示されるように＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースに追加され得る。要求側が標的リソースに所望の動作を行う適切な特権を有していないことが見出された場合／とき、ＳＬＤＡ機能９０２は、次いで、対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースが構成されたｄｙｎＡｕｔｈＰｏｌｉｃｙＩＤｓ属性を有するかどうかをチェックし得る。該当する場合、ＳＬＤＡ機能９０２は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞子リソースによって規定される規則に基づいて、それが適切な特権を要求側に動的に付与し得るかどうかをチェックするために、対応する＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースを参照し得る。
さらに、別の代替として、新しい＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースを定義するのではなく、提案される属性が、代わりに、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースに追加され得る。
＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソース
本開示は図３０に示されるように＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースも定義する。このリソースは、属性を有していない仮想リソース（示されるような）として定義されることができるか、または属性を有する通常のリソース（図示せず）として定義されることができる。それは、特定のタイプのアクセス特権が１つ以上の所望のリソースもしくはサービスと関連する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞特権に動的に追加されることを要求するための明示的動的承認要求をＳＬＤＡ機能９０２に発行するために使用されることができる。このリソースは、要求側が所望のリソースまたはサービスへの適切なアクセス特権を欠いており、アクセス制御を更新し、それ自体を付与するための特権も欠いているシナリオのために有用であり得る。この場合、要求側は、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースを使用して、明示的要求をＳＬＤＡ機能９０２に送信し、所望のアクセス特権を試行して取得することができる。成功した場合、ＳＬＤＡ機能９０２は、標的リソースまたはサービスのためのアクセス制御ポリシを更新することにより、要求される特権を追加し、ステータスを要求側に返すことができる。成功した場合、要求側は、その後、所望のリソースまたはサービスにアクセスする要求を発行することができ、要求側は、アクセスを行うための適切な特権を有するであろう。
＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースは、ｏｎｅＭ２Ｍリソースツリー階層内の種々のレベルでインスタンス化されることができる。図３１に示される一実施形態では、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースは、＜ＣＳＥＢａｓｅ＞リソースの下でインスタンス化され、＜ＣＳＥＢａｓｅ＞リソースにアクセスするアクセス特権を有する任意のサービス層登録者に利用可能にされることができる。このタイプの実施形態は、サービス層登録者が、まだ事前構成されていないＣＳＥＢａｓｅサブリソースのうちのいずれかへの特権を明示的に要求する（すなわち、事前構成された特権に依拠するのではなく、オンザフライで特権を動的に要求する）ことを可能にするために、使用され得る。
代替として、図３２に示される別の実施形態では、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースは、＜ＡＥ＞等のｏｎｅＭ２Ｍリソースタイプの下でインスタンス化されることができる。同一のことが、＜ｃｏｎｔａｉｎｅｒ＞、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞、または＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞等の他の既存のｏｎｅＭ２Ｍリソースタイプのために行われ得る。そうすることで、動的承認要求の範囲は、これらのリソースへの既存のアクセス特権を有するこれらのサービス層登録者に限定されることができる。例えば、この例では＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞への既存のアクセス特権を有するサービス層登録者のみが、動的承認要求を＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞／＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞に発行し、＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞の下のサブリソースへのアクセス特権を試行して取得することができる。
このリソースを使用するために、本開示は、以下の表２および表３で定義されるようないくつかの提案されたパラメータを有する動的承認要求および応答メッセージ（すなわち、ｏｎｅＭ２Ｍプリミティブ）も定義する。明示的動的承認要求を開始するために、要求側は、それが取得したいアクセス特権のタイプに基づいて、定義されたパラメータを適切に初期化することによって、要求を形成することができる。そして、要求側は、要求メッセージを＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースに送信することができる。要求を受信すると、ＳＬＤＡ機能９０２は、それを処理する（すなわち、要求側が特権を取得したい標的リソースまたはサービスと対応するその構成された＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース規則に対して、要求メッセージパラメータを比較する）ことができる。成果に基づいて、ＳＬＤＡ機能９０２は、要求ごとにアクセス制御特権を修正するかどうかを決定することができる。ＳＬＤＡ９０２は、次いで、要求された特権のうちのどれが付与されたか、およびどれが拒否されたかを定義する、パラメータを有する応答を形成することができる。動的承認機能性がサポートされなかった場合（例えば、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースがサポートされなかった）、または標的リソースもしくはサービスが適切に構成された＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースを有していなかった場合、エラーが返されることができる。
＜ｃｏｎｓｕｌｔ＞リソース
本開示は図３３に示されるような＜ｃｏｎｓｕｌｔ＞リソースも定義する。このリソースは、属性を有していない仮想リソース（示されるような）、または属性を有する通常のリソース（図示せず）として定義されることができる。このリソースのＵＲＩは、ネットワーク内の別のエンティティとの相談を要求する動的承認を行うときにＳＬＤＡ機能９０２が使用し得る相談接点として使用されることができる。例えば、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞が、ｃｏｎｓｕｌｔａｔｉｏｎＣｏｎｔａｃｔを定義する相談ベースの規則で構成されるとき、＜ｃｏｎｓｕｌｔ＞リソースのＵＲＩが使用されることができる。＜ｃｏｎｓｕｌｔ＞リソースは、ＣＳＥ、ＡＥ、ＭＥＦ、およびＭＡＦ等の種々のｏｎｅＭ２Ｍ定義エンティティによってホストされることができる。加えて、このリソースは、場所機能、評判検証機能（例えば、ソーシャルメディアサーバ）、プラットフォーム確認および査定機能、支払機能、セキュリティ機能、ならびにサービスサブスクリプション検証機能４１０２等のｏｎｅＭ２Ｍによってまだ定義されていない他のタイプのエンティティによってホストされることもできる。
このリソースを使用するために、本開示は、以下の表４および５で定義されるようないくつかの提案されたパラメータを有する動的承認相談要求および応答メッセージ（すなわち、ｏｎｅＭ２Ｍプリミティブ）も定義する。相談を行うために、ＳＬＤＡ機能９０２は、承認要求メッセージを構築し、システム内のエンティティによってホストされる＜ｃｏｎｓｕｌｔ＞リソースに向けてこのメッセージを標的にすることができる。この要求を受信すると、エンティティは、相談のタイプに従ってそれを処理し、相談結果を用いて対応する応答メッセージを構築し、応答をＳＬＤＡ機能９０２に返すことができる。
＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース強化
上記の図６に関して説明されるように、ｏｎｅＭ２Ｍは、現在、ＡＣＬに基づいて、定義されたｐｒｉｖｉｌｅｄｇｅｓの組を有する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをサポートしている。このＡＣＬは、ｐｒｉｖｉｌｅｄｇｅｓ属性内に記憶されることができる、アクセス・制御・規則タプルの組であり、各タプルは、１）ＡｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ、２）ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ、および、３）ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔから成る、３つのコンポーネントから成る。
本開示は、以下で説明される、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの既存のｐｒｉｖｉｌｅｄｇｅｓ属性への３つの強化を提案する。
１）第４のコンポーネントが、ｐｒｉｖｉｌｅｄｇｅｓアクセス・制御・規則タプルに追加されており、ａｃｃｅｓｓＣｏｎｔｒｏｌＰｒｉｖｉｌｅｇｅＩＤと呼ばれる。この第４のコンポーネントは、個々のｐｒｉｖｉｌｅｄｇｅｓアクセス・制御・規則タプルを識別し、それにアドレスするために使用されることができる。この識別子は、個々のタプルの更新または削除をサポートするときに有用であり得る。そうでなければ、個々のタプルの更新または削除は、ｐｒｉｖｉｌｅｄｇｅｓアクセス・制御・規則タプルリスト全体を更新することを要求し、それは、低効率的であり得る。
２）第５のコンポーネントが、ｐｒｉｖｉｌｅｄｇｅｓアクセス・制御・規則タプルに追加されており、ａｃｃｅｓｓＣｏｎｔｒｏｌＥｘｐｉｒａｔｉｏｎＴｉｍｅと呼ばれる。このコンポーネントは、特定のアクセス・制御・規則タプルに関連付けられる存続期間を定義するために使用されることができる。これは、アクセス・制御・規則タプルが互いに対して異なる存続期間を有することを可能にし、それは、特権の視点から、さらなる融通性を提供することができる。
３）４つの追加のタイプのａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔも本開示によって定義されている。
● ａｃｃｅｓｓＣｏｎｔｒｏｌＰａｙｍｅｎｔＴｅｒｍｓ−サービス層登録者がこの承認ポリシに関連付けられるリソースにアクセスすることを可能にされる前に確立されなければならない支払い条件のリスト。
● ａｃｃｅｓｓＣｏｎｔｒｏｌＲｅｐｕｔａｔｉｏｎＬｅｖｅｌ−サービス層登録者がこの承認ポリシに関連付けられるリソースにアクセスすることを可能にされる前に有していなければならない要求される評判レベル。
● ａｃｃｅｓｓＣｏｎｔｒｏｌＢａｒｔｅｒＴｅｒｍｓ−サービス層登録者がこの承認ポリシに関連付けられるリソースにアクセスすることを可能にされる前に確立されなければならないバータ条件のリスト。
● ａｃｃｅｓｓＣｏｎｔｒｏｌＳｅｃｕｒｉｔｙＡｓｓｅｓｓｍｅｎｔ−サービス層登録者がこの承認ポリシに関連付けられるリソースにアクセスすることを可能にされる前に有していなければならない要求されるセキュリティのレベル。
（ｏｎｅＭ２Ｍサービス層動的承認プロシージャ）
（サービス層動的承認ポリシの構成）
動的承認ポリシは、図３４に示されるように、標的＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓ属性を作成／更新／削除することを介して構成されることができる。構成されると、ＳＬＤＡ機能９０２は、動的承認要求ハンドリングを行うために、これらのポリシを利用することができる。
図３４のステップ１では、ｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥ）は、それが構成することを欲する動的承認規則のタイプと、この規則のための対応する値とを決定する（相談ベースの規則、支払ベースの規則、バータベースの規則、セキュリティ査定ベースの規則、および評判ベースの規則等）。
図３４のステップ２では、ｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥ）は、ＳＬＤＡ機能９０２をホストする第２のｏｎｅＭ２Ｍエンティティ３４０４（例えば、ＣＳＥ、ＭＥＦ２３０４、またはＭＡＦ２３０２）を標的にする要求を送信する。要求は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース表現を含み、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓ属性は、ステップ１からの動的承認ポリシ規則で構成されることができる。
図３４のステップ３では、ｏｎｅＭ２Ｍエンティティ３４０４上でホストされるＳＬＤＡ機能９０２は、要求を受信し、要求側が標的＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースに規定動作を行うために適切な特権を有するかどうかをチェックする。このチェックは、要求側が、標的＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞に関連付けられる、対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内に構成されたｐｒｉｖｉｌｅｇｅｓを有するかどうかを確認することによって行われる。該当する場合、ＳＬＤＡ機能９０２は、要求の処理を続け、そうでなければ、ＳＬＤＡ機能９０２は、この動作を行うための特権の欠如を要求側に示すエラーを要求側に返す。
図３４のステップ４では、ＳＬＤＡ機能９０２は、要求を処理し、動作に基づいて、標的＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓ属性へ／から規定規則の作成、更新、または削除のいずれかを行う。
図３４のステップ５では、サービス層は、標的＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓ属性において規定規則を作成、更新、または削除する要求が成功したかどうかを示す応答を要求側に返す。
図３４に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３４に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３４に図示されるステップを行う。図３４に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（自律的サービス層動的承認）
サービス層動的承認は、図３５に示されるようにＳＬＤＡ機能９０２をホストするｏｎｅＭ２Ｍエンティティ３５０２によって、自律的にトリガされて行われることができる。このプロシージャを介して、ＳＬＤＡ機能９０２は、要求側がアクセスするための既存の特権を有していないリソースにアクセスするために行われる要求の処理中、オンザフライで特権を自律的に付与または拒否することをサポートすることができる。このプロシージャをサポートすることによって、要求側が確立された特権を有していないリソースのためのアクセス特権を明示的に要求する必要がないので、負担が要求側から除去されることができる。このプロシージャを介して、サービス層動的承認は、それが行われていることを要求側が認識することさえなく行われることができる。これは、特に、リソース制約されたデバイス（例えば、ＩｏＴデバイス上でホストされるセンサアプリケーション）を伴う使用のために、要求側におけるオーバーヘッドを低減させることができる。
このプロシージャは、事前に特権の組でアクセス制御ポリシを静的に事前構成する外部管理エンティティをネットワーク内に有する必要なく、ＳＬＤＡ９０２結果を活用して、アクセス制御ポリシがオンザフライで動的に作成または更新されるための機構を提供するので、サービス層自体のために有益であり得る。事前にアクセス制御ポリシを事前構成することは、煩雑で、融通が利かず、あまり拡張可能ではあり得ない。
図３５のステップ１では、要求ｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥまたはＣＳＥ）は、要求（すなわち、作成／読み出し／更新／削除／サブスクライブ／発見）を別のｏｎｅＭ２Ｍエンティティ３５０２に発行することができる。
図３５のステップ２では、受信ｏｎｅＭ２Ｍエンティティ３５０２（例えば、ＣＳＥ）は、標的リソースへのアクセスを検出する。受信エンティティは、（該当する場合）標的リソースに適用可能な対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをチェックし、要求側が所望のタイプのアクセスを行うことを可能にするように構成される十分な特権を有するかどうかを決定する。この例では、要求側は、十分なアクセス特権を欠いている。
図３５のステップ３では、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーを要求側に即時に返すのではなく、受信エンティティ３５０２は、受信エンティティ上またはシステム内の別のエンティティ上のいずれかでホストされることができるＳＬＤＡ機能性によって行われるように動的承認処理をトリガする。ＳＬＤＡ機能性は、複数のエンティティにわたって分割されることもでき、一部の機能性が、受信エンティティ上でホストされる。
図３５のステップ４では、受信エンティティ３５０２は、ＳＬＤＡ機能性を伴って有効にされている場合、動的承認処理を行い始める。受信エンティティがＳＬＤＡ機能性自体をホストするかどうかに応じて、ＳＬＤＡ処理が完全にローカルで行われるかどうか、または受信エンティティがシステム内のエンティティ３５０４および３５０６等の他のｏｎｅＭ２Ｍエンティティと通信し、それがＳＬＤＡ９０２を行うことを支援するであろうかどうかを決定するであろう。図２３および２４に関して説明されるように、異なる展開オプションが、異なるタイプのｏｎｅＭ２Ｍエンティティ（ＣＳＥ、ＭＥＦ２３０４、ＭＡＦ２３０２）がその全体または特定のＳＬＤＡ９０２サブ機能のいずれかでＳＬＤＡ９０２をホストすることを可能にする集中型または分散型様式でＳＬＤＡ機能性をホストするために存在する。いかなるＳＬＤＡ機能性も見出されない場合、ＳＬＤＡ９０２処理は、停止されることができ、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーが要求側に返されることができる。ＳＬＤＡ機能性が受信エンティティおよび／またはシステム内の他のエンティティのいずれかにホストされていることが見出された場合、この機能性は、標的リソースに適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定しようとするようにトリガされる。＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞が見出されることができない場合、ＳＬＤＡ９０２は、動的承認処理を中断し、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーを要求側に返すことができる。１つ以上の＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースが見出される場合、ＳＬＤＡ機能性は、見出される各リソースに対してｄｙｎＡｕｔｈＲｕｌｅｓ属性を使用し、要求側の要求に対して評価し、特権が動的に付与されることができるかどうかを決定することができる。
図３５の随意のステップ５では、適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓを評価している間、ＳＬＤＡ機能９０２は、規定されるｄｙｎＡｕｔｈＲｕｌｅｓのタイプに応じて、システム内のエンティティ３５０４および３５０６等の他のエンティティと相談する必要があり得る。相談は、ＳＬＤＡ機能９０２がアクセス特権を要求側に付与するか、または拒否するかを決定するために必要とする適切な情報を収集するために必要とされ得る。ＳＬＤＡ機能９０２が行うことができる、いくつかの提案されたタイプの相談が、図３７−４２に関してさらに詳細に説明される。この相談は、提案される＜ｃｏｎｓｕｌｔ＞リソース、および図３３に関してさらに詳細に説明されるその対応する要求ならびに応答プリミティブを使用して、行われることができる。
図３５のステップ６では、ｄｙｎＡｕｔｈＲｕｌｅｓに対して要求を評価することと、おそらく、その意思決定の要素に入れる追加の情報を取得するためにシステム内のエンティティ３５０４および３５０６等の他のエンティティと相談することとの結果に基づいて、ＳＬＤＡ機能性は、アクセスを要求側に付与することを決定する。結果として、受信エンティティ３５０２は、標的リソースに対して要求を行い、成功した応答を要求側３４０２に返す。要求側３４０２は、自律的ＳＬＤＡ９０２が行われたことを認識していない。それが認識していることは、その要求が成功裏に完了したことのみである。
図３５の随意のステップ７では、動的承認結果を使用して、ＳＬＤＡ機能９０２は、随意に、要求側のためのアクセス制御特権を追加するために、標的リソースに関連付けられる＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内のｐｒｉｖｉｌｅｇｅｓ属性を更新することを選定することができる。この決定は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース内で定義されるｄｙｎＡｕｔｈＲｕｌｅを介して制御されることができる。例えば、ｄｙｎＡｕｔｈＲｕｌｅは、ＳＬＤＡ機能９０２が＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの静的特権を追加または更新するかどうか、および該当する場合、この特権の有効期限の内容を制御するために、規則（例えば、特権存続期間規則）をサポートすることができる。結果として、ＳＬＤＡ機能９０２は、特権を更新または追加するかどうか、および該当する場合、有効期限を制御するために、この規則を使用することができる（例えば、これは、上で提案されるように特権のａｃｃｅｓｓＣｏｎｔｒｏｌＥｘｐｉｒａｔｉｏｎＴｉｍｅコンポーネントを使用して行われることができる）。これらの規則に基づいて、ＳＬＤＡ機能９０２は、特権を追加／更新するかどうか、およびそれらのそれぞれの存続期間を決定することができる。特権を更新することを選定することによって、要求側は、リソースへのアクセスを付与され、動的承認が繰り返される必要なく、同一の動作を行うことができる。
図３５のステップ８では、要求するｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥまたはＣＳＥ）は、要求（すなわち、作成／読み出し／更新／削除／サブスクライブ／発見）を同一のｏｎｅＭ２Ｍエンティティ上の同一のリソースに発行する。
図３５のステップ９では、受信するｏｎｅＭ２Ｍエンティティ３５０２（例えば、ＣＳＥ）は、標的リソースへのアクセスを検出する。受信するエンティティは、標的リソースに適用可能な対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをチェックし、ＳＬＤＡ機能９０２がステップ７の一部としてこれらの特権を追加したことの結果として、現在、要求側が十分なアクセス特権を有していることを検出する。
図３５のステップ１０では、受信エンティティ３５０２は、標的リソースに対して要求を行い、成功した応答を要求側に返す。
図３５に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３５に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３５に図示されるステップを行う。図３５に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（明示的サービス層動的承認要求ハンドリング）
本節は、要求側が、規定されたリソースにアクセスする所望の特権を試行して取得するために、動的承認要求を明示的に発行することを可能にするプロシージャを定義する。
図３６の随意のステップ１では、要求ｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥまたはＣＳＥ）は、要求（すなわち、作成／読み出し／更新／削除／サブスクライブ／発見）を別のｏｎｅＭ２Ｍエンティティ３６０２に発行することができる。
図３６の随意のステップ２では、受信ｏｎｅＭ２Ｍエンティティ３６０２（例えば、ＣＳＥ）は、標的リソースへのアクセスを検出する。受信エンティティ３６０２は、（該当する場合）標的リソースに適用可能な対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをチェックし、要求側３４０２が所望のタイプのアクセスを行うことを可能にするように構成される十分な特権を有するかどうかを決定する。この例では、要求側は、十分なアクセス特権を欠いている。
図３６の随意のステップ３では、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーを要求側に即時に返すのではなく、受信エンティティ３６０２は、サービス層動的承認をサポートするシステム内のエンティティ３５０２へのリンクを返す。このリンクは、ＳＬＤＡ機能９０２をサポートするエンティティによってホストされる、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのリンクであることができる。
図３６のステップ４では、要求ｏｎｅＭ２Ｍエンティティ３４０２は、明示的サービス層動的承認要求を編成して発行し、ネットワーク内のＳＬＤＡ機能９０２へ要求を標的化する。この要求は、ＳＬＤＡ機能９０２をサポートするエンティティによってホストされる＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースに標的化されることができる。要求は、全て上で定義されるｒｅｑｕｅｓｔＴｙｐｅ、ｒｅｑｕｅｓｔｄＰｒｉｖｉｌｅｇｅｓ、ｐａｙｍｅｎｔＩｎｆｏ、ｂａｒｔｅｒＩｎｆｏ、ｃｒｅｄｅｎｔｉａｌＩｎｆｏ、ｐｌａｔｆｏｒｍＩｎｆｏ、ｓｕｂｓｃｒｉｐｔｉｏｎＩｎｆｏ等の情報を含むことができる。
図３６のステップ５では、受信ｏｎｅＭ２Ｍエンティティ３６０２は、この要求を受信すると、標的ＵＴＩを点検し、それが＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースに標的化されていることを検出する。これに基づいて、エンティティは、要求を処理するためにＳＬＤＡ機能９０２をトリガすべきことを把握する。
図３６のステップ６では、ＳＬＤＡ機能９０２は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースが要求されている特権のために存在するかどうかをチェックする。これは、要求側がアクセス特権を要求しているリソースの場所を特定することによって行われる。見出されると、ＳＬＤＡ機能９０２は、次いで、これらのリソースがそれらと関連した対応する＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースを有するかどうかをチェックする。該当しない場合、エラー応答が、要求側に返されることができる。見出された場合、ＳＬＤＡ機能９０２は、処理を続けることができる。ＳＬＤＡ機能９０２は、次に、標的リソースと関連した各＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースのｄｙｎＡｕｔｈＲｕｌｅｓ属性を調査する。ｄｙｎＡｕｔｈＲｕｌｅｓは、最初に、要求が規則に従うかどうかを確認するために、要求側がその要求に含んだ情報（例えば、ｒｅｑｕｅｓｔＴｙｐｅ、ｒｅｑｕｅｓｔｄＰｒｉｖｉｌｅｇｅｓ、ｐａｙｍｅｎｔＩｎｆｏ、ｂａｒｔｅｒＩｎｆｏ、ｃｒｅｄｅｎｔｉａｌＩｎｆｏ、ｐｌａｔｆｏｒｍＩｎｆｏ、ｓｕｂｓｃｒｉｐｔｉｏｎＩｎｆｏ）に対して比較される。該当しない場合、エラーが返されない。そうでなければ、ＳＬＤＡ９０２は、以下のステップ＃７により動的承認処理を続ける。
図３６の随意のステップ７では、ＳＬＤＡ機能９０２は、システム内の他の機能と任意の相談を行う必要があるかどうかをチェックする。ＳＬＤＡ９０２は、ＳＬＤＡ機能９０２が支払、バータ、セキュリティ、サブスクリプション検証、評判検証、または承認機能と相談する必要があるかどうかを規定するｄｙｎＡｕｔｈＲｕｌｅｓを調査することによって、これを決定する。これは、これらの機能をホストするｏｎｅＭ２Ｍシステム内のエンティティ３６０４および３６０６等の他のエンティティと調整することを伴い得ることに留意されたい。相談は、図３７−４２に関するプロシージャを使用して行われることができる。
図３６のステップ８では、ＳＬＤＡ機能９０２は、応答を明示的動的承認要求側に返す。この応答では、ＳＬＤＡ機能９０２は、表２で定義されるｄｙｎＡｕｔｈＳｔａｔｕｓ、ｄｙｎＡｕｔｈＣｒｅｄｅｎｔｉａｌＩＤ、ｄｙｎＡｕｔｈＣｒｅｄｅｎｔｉａｌ、ｇｒａｎｔｅｄＰｒｉｖｉｌｅｇｅｓ、ｄｅｎｉｅｄＰｒｉｖｉｌｅｇｅｓ、ｐａｙｍｅｎｔＴｅｒｍｓ、ｂａｒｔｅｒＴｅｒｍｓ、およびｓｕｂｓｃｒｉｐｔｉｏｎＴｅｒｍｓ等の情報を返すことができる。
図３６の随意のステップ９では、動的承認結果を使用して、ＳＬＤＡ機能９０２は、随意に、要求側のためのアクセス制御特権を追加するために、標的リソースに関連付けられる＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内のｐｒｉｖｉｌｅｇｅｓ属性を更新することを選定することができる。この決定は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース内で定義されるｄｙｎＡｕｔｈＲｕｌｅを介して制御されることができる。例えば、ｄｙｎＡｕｔｈＲｕｌｅは、ＳＬＤＡ機能９０２が＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの静的特権を追加または更新するかどうか、および該当する場合、この特権の有効期限の内容を制御するように、規則（例えば、特権存続期間規則）をサポートすることができる。結果として、ＳＬＤＡ機能９０２は、特権を更新または追加するかどうか、および該当する場合、有効期限を制御するために、この規則を使用することができる（例えば、これは、上で提案されるように特権のａｃｃｅｓｓＣｏｎｔｒｏｌＥｘｐｉｒａｔｉｏｎＴｉｍｅコンポーネントを使用して行われることができる）。これらの規則に基づいて、ＳＬＤＡ機能９０２は、特権を追加／更新するかどうか、およびそれらのそれぞれの存続期間を決定することができる。特権を更新することを選定することによって、要求側は、リソースへのアクセスを付与され、動的承認が繰り返される必要なく、同一の動作を行うことができる。
図３６のステップ１０では、要求ｏｎｅＭ２Ｍエンティティ３４０２（例えば、ＡＥまたはＣＳＥ）は、要求（すなわち、作成／読み出し／更新／削除／サブスクライブ／発見）を別のｏｎｅＭ２Ｍエンティティに発行することができる。要求内で、要求側は、それがステップ８から取得した動的承認証明情報および／または識別子を含むことができる。
図３６のステップ１１では、受信ｏｎｅＭ２Ｍエンティティ３６０２（例えば、ＣＳＥ）は、標的リソースへのアクセスを検出する。受信エンティティは、（該当する場合）標的リソースに適用可能な対応する＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをチェックし、要求側が所望のタイプのアクセスを行うことを可能にするように構成される十分な特権を有するかどうかを決定する。この例では、要求側は、十分なアクセス特権を欠いている。
図３６のステップ１２では、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーを要求側に即時に返すのではなく、受信エンティティ３６０２は、要求が動的承認証明情報（例えば、トークン）またはそれためのＩＤを含むかどうかをチェックする。該当しない場合、「ａｃｃｅｓｓ ｄｅｎｉｅｄ」エラーが返される。
図３６のステップ１３では、実際の証明情報ではなく、動的承認証明情報ＩＤのみが含まれる場合、受信エンティティは、規定ＩＤに関連付けられる対応する動的承認証明情報のＳＬＤＡ機能９０２ルックアップをトリガする。
図３６の随意のステップ１４では、受信エンティティ３６０２は、動的承認証明情報にアクセスするための相談要求を形成する。要求は、ＳＬＤＡ機能９０２の＜ｃｏｎｓｕｌｔ＞リソースまたはシステム内の専用承認機能に送信される。これは、セキュアなネットワーク接続を経由して行われる。要求に、表４で定義されるｃｏｎｓｕｌｔａｔｉｏｎＩｎｆｏ等のパラメータが含まれる。
図３６の随意のステップ１５では、要求を受信すると、ＳＬＤＡ機能９０２は、それが＜ｃｏｎｓｕｌｔ＞リソースを標的にするので、相談要求であることを検出する。ＳＬＤＡ機能９０２は、（相談タイプパラメータをチェックすることによって）それが相談要求のタイプを検出するために要求を解析し、それが動的承認証明情報要求相談であることを検出する。ＳＬＤＡ９０２は、次いで、対応する証明情報を参照するために、要求に含まれる動的承認証明情報ＩＤを使用する。証明情報は、次いで、受信エンティティに返される。
図３６のステップ１６では、受信エンティティ３６０２（またはＳＬＤＡ機能９０２）は、要求の中で受信されるか、または上記の相談ステップを用いた相談を介して取得されるかのいずれかである動的承認証明情報を検証する。検証されると、ＳＬＤＡ機能９０２は、要求されるアクセス特権を要求側に付与することを選定することができる。受信エンティティは、要求を処理し、成功した応答を要求側に返す。
図３６のステップ１７では、受信エンティティ３６０２（またはＳＬＤＡ機能９０２）は、要求の中で受信されるか、または上記の相談ステップを用いた相談を介して取得されるかのいずれかである動的承認証明情報を検証する。検証されると、ＳＬＤＡ機能９０２は、要求されるアクセス特権を要求側に付与することを選定することができる。
図３６の随意のステップ１８では、動的承認結果を使用して、ＳＬＤＡ機能９０２は、随意に、要求側のためのアクセス制御特権を追加するために、標的リソースに関連付けられる＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内のｐｒｉｖｉｌｅｇｅｓ属性を更新することを選定することができる。この決定は、＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソース内で定義されるｄｙｎＡｕｔｈＲｕｌｅを介して制御されることができる。例えば、ｄｙｎＡｕｔｈＲｕｌｅは、ＳＬＤＡ機能９０２が＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの静的特権を追加または更新するかどうか、および該当する場合、この特権の有効期限の内容を制御するように、規則（例えば、特権存続期間規則）をサポートすることができる。結果として、ＳＬＤＡ機能９０２は、特権を更新または追加するかどうか、および該当する場合、有効期限を制御するために、この規則を使用することができる（例えば、これは、上で提案されるように特権のａｃｃｅｓｓＣｏｎｔｒｏｌＥｘｐｉｒａｔｉｏｎＴｉｍｅコンポーネントを使用して行われることができる）。これらの規則に基づいて、ＳＬＤＡ機能９０２は、特権を追加／更新するかどうか、およびそれらのそれぞれの存続期間を決定することができる。特権を更新することを選定することによって、要求側は、リソースへのアクセスを付与され、動的承認が繰り返される必要なく、同一の動作を行うことができる。
図３６に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３６に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３６に図示されるステップを行う。図３６に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（相談ベースのサービス層動的承認）
図３７は、相談ベースの動的承認のためのプロシージャを示す。
図３７のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図３７のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、「相談ベースの承認」が動的承認処理の一部として要求されることを規定する規則で構成されている。この規則は、システム内の承認機能３７０２と相談し、それが要求しているか、または必要とするアクセス特権を要求側に付与すべきか、または拒否すべきかにおいて介入させるように、ＳＬＤＡ機能９０２をトリガする。
図３７のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、承認機能３７０２によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、動的承認が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、要求側が明示的に求めているか、またはＳＬＤＡ機能９０２が、それが標的にしているリソースもしくはサービスに要求側がアクセスするために必要と見なしているかのいずれかである、要求される／必要とされる特権で構成される。
図３７のステップ４では、承認機能３７０２は、それが要求しているアクセス特権を要求側に付与または拒否するかどうかを査定する。この決定が行われる方法の詳細は、本開示の範囲外であり、承認機能３７０２がサポートするチェックのタイプに特定と考えられ、それは、展開ユースケースに応じて変動し得る。この動作の結果は、次いで、相談応答の形態でＳＬＤＡ９０２に返される。応答は、付与された特権および拒否された特権のリストを含む。応答は、要求側に着目され得るいくつかの他のリソースまたはサービスの特権を含むこともできる。
図３７のステップ５では、ＳＬＤＡ機能性は、相談ベースの承認結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図３７に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３７に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３７に図示されるステップを行う。図３７に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（支払ベースのサービス層動的承認）
図３８は、支払ベースの動的承認のためのプロシージャを示す。
図３８のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図３８のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、「支払検証を必要とする」が動的承認処理の一部として要求されることを規定する規則で構成されている。この規則は、システム内の支払機能３８０２と相談し、それに要求側の支払情報を検証させるように、ＳＬＤＡ機能９０２をトリガする。
図３８のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、支払機能によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、支払情報検証が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、要求側の支払情報、ならびに要求側の支払トークンおよび選好等の情報と、ポリシの支払条件とを含むことができる、支払ポリシで構成される。
図３８のステップ４では、支払機能３８０２は、支払情報を査定し、それが有効であることを検証し、ポリシの中の支払規則に対してそれをさらに査定する。この動作の結果は、次いで、相談応答の形態でＳＬＤＡ９０２に返される。応答は、支払情報検証ステータスを含む。
図３８のステップ５では、ＳＬＤＡ機能性は、支払情報検証結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図３８に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３８に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３８に図示されるステップを行う。図３８に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（バータベースのサービス層動的承認）
図３９は、バータベースの動的承認のためのプロシージャを示す。
図３９のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図３９のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、要求側がアクセス特権を付与されるために満たさなければならないバータ要件のリストである「必要とされるバータ条件」を規定する規則で構成されている。この規則は、ローカルバータ処理を行うか、またはシステム内のバータ機能３９０２と相談し、ＳＬＤＡ９０２の代わりにそれにバータ処理を行わせるかのいずれかのために、ＳＬＤＡ機能９０２をトリガする。
図３９のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、バータ機能３９０２によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、バータ処理が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、要求側のバータ情報、ならびに要求側がアクセス特権を付与されるために自発的に合意しなければならないバータ条件のタイプの情報を含むことができるバータポリシで構成される。例えば、標的リソース所有者によってアクセス特権を付与されることと引き換えでの要求側のリソースおよびサービスへのアクセスの相互関係である。
図３９のステップ４では、バータ機能３９０２は、要求側が自発的にこれらの条件に合意するかどうかを決定するために、ポリシならびに要求側によって定義されるバータ条件を査定する。バータ機能３９０２は、次いで、バータステータスと、合意条件のリストとを含む相談応答を介して、結果をＳＬＤＡ９０２に返す。
図３９のステップ５では、ＳＬＤＡ機能性は、バータ結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図３９に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図３９に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３９に図示されるステップを行う。図３９に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（セキュリティ査定ベースのサービス層動的承認）
図４０は、セキュリティ査定ベースの動的承認のためのプロシージャを示す。
図４０のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図４０のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、「セキュリティ査定を必要とする」を規定する規則で構成されている。この規則は、ローカルセキュリティ査定処理を行うか、またはシステム内のセキュリティ機能４００２と相談し、ＳＬＤＡ９０２の代わりにそれにセキュリティ査定処理を行わせるかのいずれかのために、ＳＬＤＡ機能９０２をトリガする。
図４０のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、セキュリティ機能４００２によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、セキュリティ査定処理が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、要求側のセキュリティ情報（ＩＤ、証明情報、サポートされるインターフェースセキュリティのタイプ、サポートされるプラットフォームセキュリティ、サポートされるコンテンツセキュリティ等）で構成される。要求は、ポリシによって定義される任意の要求されるセキュリティ査定レベルで構成されることもできる。
図４０のステップ４では、セキュリティ機能４００２は、要求側がセキュリティ査定要件を満たすかどうかを決定するために、ポリシの中で定義されるセキュリティ要件に対して要求側のセキュリティ情報を査定する。セキュリティ機能４００２は、次いで、セキュリティ査定ステータスを含む相談応答を介して、結果をＳＬＤＡ９０２に返す。
図４０のステップ５では、ＳＬＤＡ機能性は、セキュリティ査定結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図４０に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図４０に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図４０に図示されるステップを行う。図４０に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（サービス層サブスクリプション検証ベースの動的承認）
図４１は、サービス層サブスクリプションベースの動的承認のためのプロシージャを示す。
図４１のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図４１のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、「サービスサブスクリプション検証を必要とする」を規定する規則で構成されている。この規則は、ローカルサービスサブスクリプション検証処理を行うか、またはシステム内のサブスクリプション検証機能４１０２と相談し、ＳＬＤＡ９０２の代わりにそれにこの検証を行わせるかのいずれかのために、ＳＬＤＡ機能９０２をトリガする。
図４１のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、サブスクリプション検証機能４１０２によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、検証が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、利用可能である要求側の任意のサービスサブスクリプション情報（例えば、サービス層ＩＤ）、ならびに要求側がアクセス特権を付与されるために有していなければならない要求されるサービスプロバイダおよび／またはサービスプラン等の要件を定義するサービスサブスクリプションポリシ規則で構成される。
図４１のステップ４では、サブスクリプション検証機能４１０２は、要求側がポリシによって定義される要件を満たすかどうかを決定するために、要求側のサービスサブスクリプションに対して、ポリシによって定義されるサブスクリプション要件を査定する。サブスクリプション検証機能４１０２は、次いで、検証ステータスと、満たされている要件ならびに満たされていないどれでものリストとを含む相談応答を介して、結果をＳＬＤＡ９０２に返す。
図４１のステップ５では、ＳＬＤＡ機能性は、サブスクリプション検証結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図４１に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図４１に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図４１に図示されるステップを行う。図４１に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
（評判ベースのサービス層動的承認）
図４２は、評判ベースの動的承認のためのプロシージャを示す。
図４２のステップ１では、ＳＬＤＡ機能９０２は、明示的要求（すなわち、＜ｄｙｎＡｕｔｈＲｅｑｕｅｓｔ＞リソースへのアクセス）によって、またはＳＬＤＡ機能９０２自体によって（例えば、既存の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞静的特権上のチェックで不成功の結果の要求の検出を介して）自律的にトリガされる。
図４２のステップ２では、ＳＬＤＡ９０２は、（該当する場合）適用可能な＜ｄｙｎＡｕｔｈＰｏｌｉｃｙ＞リソースの場所を特定し、構成されている規則を決定するためにｄｙｎＡｕｔｈＰｏｌｉｃｙ属性を評価する。この例では、ｄｙｎＡｕｔｈＰｏｌｉｃｙ属性は、要求側がアクセス特権を動的に付与されるために要求側の評判が満たさなければならないランキングまたはレベルを定義する「必要とされる評判レベル」を規定する規則で構成されている。この規則は、ローカル評判検証処理を行うか、またはシステム内の評判検証機能４２０２と相談し、ＳＬＤＡ９０２の代わりにそれにこの検証を行わせるかのいずれかのために、ＳＬＤＡ機能９０２をトリガする。
図４２のステップ３では、ＳＬＤＡ機能９０２は、相談要求メッセージを形成する。メッセージは、評判検証機能によってホストされる＜ｃｏｎｓｕｌｔ＞リソースに標的化される。ｃｏｎｓｕｌｔＳｕｂｊｅｃｔは、検証が行われている要求側のＡＥ−ＩＤまたはＣＳＥ−ＩＤで構成される。要求のペイロードは、利用可能である要求側の任意の評判関連情報（例えば、サービス層ＩＤ）、ならびに要求側がアクセス特権を付与されるために有していなければならない要求される最小評判レベルまたはランキングを定義する評判ポリシ規則で構成される。
図４２のステップ４では、評判検証機能４２０２は、要求側がポリシによって定義される要件を満たすかどうかを決定するために、要求側の評判に対して、ポリシによって定義される評判要件を査定する。これは、多くの場合、そのような情報を記録するソーシャルメディアメディアアウトレットにインターフェースをとること等の方法を使用して、行われることができる。評判検証機能４２０２は、次いで、検証ステータスと、評判レベルまたはランキングとを含む相談応答を介して、結果をＳＬＤＡ９０２に返す。
図４２のステップ５では、ＳＬＤＡ機能性は、評判結果をチェックし、要求側にアクセス特権を付与または拒否するかどうかを決定するために、この成果をその動的承認意思決定の要素に入れる。
図４２に図示されるステップを行うエンティティは、図４４Ｃまたは図４４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図４２に図示される方法は、図４４Ｃまたは図４４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図４２に図示されるステップを行う。図４２に図示される任意の伝送することおよび受信することは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。
グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、サービス層動的承認に関連する機能性を制御および／または構成するためにユーザを支援するために、使用されることができる。図４３は、ユーザがサービス層動的承認を可能にすること、動的承認が静的承認として記憶されるサービス層動的承認期間を選択すること、および相談サーバまたはアプリケーションを構成することを可能にするインターフェース４３０２を図示する、略図である。
インターフェース４３０２は、本開示の表１の中のもの（ｄｙｎＡｕｔｈＲｕｌｅｓ参照）のような具体的動的承認規則を定義するために使用されることができる。インターフェース４３０２は、ユーザが、利用可能な規則のリストからチェックすること、または手動で規則に入力することのいずれかを行うことを可能にすることができる。
インターフェース４３０２は、以下で説明される図４４Ｃ−Ｄに示されるもの等のディスプレイを使用して生成され得ることを理解されたい。
（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法を達成するように、単独で、または互いと組み合わせて動作し得る。本明細書で使用される場合、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、同義的に使用され得る。
サービス層という用語は、ネットワークサービスアーキテクチャ内の機能層を指す。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層は、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークへのインターフェースも提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシ管理、アクセス制御、およびサービスクラスタ化を含む（サービス）能力または機能性の複数のカテゴリをサポートする。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するためにＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと称され得るサービス層によってサポートされる上記の能力もしくは機能性の集合または組へのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例は、種々のアプリケーションによって一般に使用されることができるセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含むが、それらに限定されない。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装され得、それらがそのような能力または機能を使用するために、種々のアプリケーションならびに／もしくはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）にエクスポーズされる（サービス）能力または機能性を提供する機能エンティティである。
図４４Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。
図４４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する多重アクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図４４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常は、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。
図４４Ｂを参照すると、フィールドドメイン内の図示されたＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図４４Ｃおよび４４Ｄに図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示されたＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。
図４４Ｂをさらに参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’は、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、ネットワーク１２を通して通信することも可能にする。
本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願の接続方法を含有し得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。
いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでもよく、また、他の開示されるシステムおよび方法と併せて使用され得る。
一実施形態では、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、図４４Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。
概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、もしくはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、もしくは１つ以上の既存のノードの一部としてのいずれかで実行する論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図４４Ｃまたは図４４Ｄで図示される一般アーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。
さらに、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。
図４４Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティを実行すること、または含むことができる。デバイス３０は、図４４Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部または非Ｍ２Ｍネットワークの一部であることができる。図４４Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装するノードであり得る。
プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を実施し得る。
図４４Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図４４Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内にともに統合され得ることが理解されるであろう。
伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む他のＭ２Ｍノードに信号を伝送するように、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
加えて、伝送／受信要素３６は、単一の要素として図４４Ｃで描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。例えば、プロセッサ３２は、上で説明されるように、セッションコンテキストをそのメモリの中に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行もしくは共有のステータスを反映する、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得る、または情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得るグラフィカルユーザインターフェースは、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にするように、ＡＰＩの上で層化され得る。
プロセッサ３２は、電源４８から電力を受電し得、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。
プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、バイオメトリック（例えば、指紋）センサ等の種々のセンサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。代替として、ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の装置もしくはデバイスを備え得る。
図４４Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。コンピューティングシステム９０は、サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティを実行すること、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む任意の他のノードであることができる。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明情報の受信またはセッション証明情報に基づく認証等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されたシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。
システムバス８０に結合されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られること、もしくは変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供し得る。したがって、第１のモードで起動するプログラムは、それ自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を通信する責任がある周辺機器コントローラ８３を含み得る。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子コンポーネントを含む。
さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図４４Ａおよび図４４Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含み得る。
ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。これは、ハンドヘルド電話、モバイルブロードバンドアダプタを装備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図４４Ａ−ＢのＭ２Ｍ端末デバイス１８または図４４Ｃのデバイス３０として実装されることができる。
本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。サービス層１０２、アプリ２０４および２０２、ＳＬＤＡ９０２、ＳＬＤＡ−ＰＡ９０４、ＳＬＤＡ−ＰＩ９０６、ＳＬＤＡ−ＰＤ９０８、ＳＬＤＡ−ＰＥ９１０、ＳＬＳＡ１４０２、ＳＬＳＡ−ＰＡ１４０４、ＳＬＳＡ−ＰＤ１４０６、ＳＬＳＡ−ＰＩ １４１２、ＳＬＳＡ−ＰＥ１４１０、ＳＬ−ＰＣＦ１４０８、エンティティ１５０２、１６０２、３４０２、３４０４、３５０２、３５０４、３５０６、３６０２、３６０４、３６０６、ポリシサーバ１５０４、ＲＨＦ１６０４、クライアント１７０２、ＤＡＥＦ１８０２およびＤＡＥＦ−支払、ＤＧＦ２１０２、ＭＡＦ２３０２、ＭＥＦ２３０４、承認機能３７０２、支払機能３８０２、バータ機能３９０２、セキュリティ機能４００２、サービス層サブスクリプション検証機能４１０２、評判検証機能４２０２、ならびに開示されるリソースを記憶し、その上で動作する論理エンティティ、およびインターフェース４３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令の形態で具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる任意の他の有形もしくは物理媒体を含むが、それらに限定されない。
図に図示されるような本開示の主題の好ましい実施形態を説明する上で、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る。そのような他の例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (20)

  1. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、通信ネットワークのサービス層エンティティを実装し、
    前記通信ネットワークの前記サービス層エンティティによって、前記サービス層エンティティによってホストされているリソースにアクセスするための要求を前記通信ネットワーク上の要求エンティティから受信することと、
    前記サービス層エンティティによって、前記要求されているリソースに関連付けられたアクセス制御ポリシに基づいて、前記要求エンティティが前記要求されているリソースにアクセスするための事前プロビジョニングされた特権を有していないことを決定することと、
    前記アクセス制御ポリシに基づき、かつ前記要求エンティティが事前プロビジョニングされた特権を有していないことを決定することに応答して、前記サービス層エンティティが前記要求エンティティの動的承認を行うことにおいて相談すべき前記通信ネットワークの別のエンティティを識別することと、
    前記別のエンティティとの通信において、前記要求されているリソースにアクセスするための新しい特権を前記要求エンティティに付与することを決定することと、
    前記要求されているリソースに関連付けられた新しいアクセス制御ポリシを作成することであって、前記新しいアクセス制御ポリシは、前記要求エンティティが前記要求されているリソースにアクセスするための前記新しい特権を有することを示す、ことと、
    前記新しい特権に基づいて前記要求エンティティにメッセージを送信することであって、前記メッセージは、前記要求エンティティの前記リソースにアクセスするための前記要求が認可されていることを示す、ことと
    を前記装置に行わせる、装置。
  2. 前記サービス層エンティティが前記要求エンティティの前記動的承認を行うことにおいて相談すべき前記別のエンティティの識別は、前記要求されているリソースに関連付けられた前記アクセス制御ポリシに関連付けられた動的承認ポリシにおいて提供される、請求項１に記載の装置。
  3. 前記別のエンティティは、前記動的承認を行った後、前記要求エンティティのための付与された特権のリストおよび前記付与された特権に関連付けられた存続期間を前記サービス層エンティティに送信する、請求項１に記載の装置。
  4. 前記新しいアクセス制御ポリシは、前記付与された特権のリストを含む、請求項３に記載の装置。
  5. 前記新しいアクセス制御ポリシは、一時的である、請求項４に記載の装置。
  6. 前記装置は、前記リソースのための前記動的承認ポリシを受信する、請求項２に記載の装置。
  7. 前記動的承認は、前記要求エンティティが支払を行ったという指示を受信した後、行われる、請求項１に記載の装置。
  8. 前記動的承認は、前記要求エンティティがバータ条件を満たしたという指示を受信した後、行われる、請求項１に記載の装置。
  9. 前記動的承認は、前記要求エンティティについての評判情報を評価することを含む、請求項１に記載の装置。
  10. 方法であって、前記方法は、
    装置におけるサービス層において、通信ネットワークのサービス層エンティティによって、前記サービス層エンティティによってホストされているリソースにアクセスするための要求を前記通信ネットワーク上の要求エンティティから受信することと、
    前記サービス層エンティティによって、前記要求されているリソースに関連付けられたアクセス制御ポリシに基づいて、前記要求エンティティが前記要求されているリソースにアクセスするための事前プロビジョニングされた特権を有していないことを決定することと、
    前記サービス層エンティティによって、前記アクセス制御ポリシに基づき、かつ前記要求エンティティが事前プロビジョニングされた特権を有していないことを決定することに応答して、前記サービス層エンティティが前記要求エンティティの動的承認を行うことにおいて相談すべき前記通信ネットワークの別のエンティティを識別することと、
    前記別のエンティティとの通信において、前記要求されているリソースにアクセスするための新しい特権を前記要求エンティティに付与することを決定することと、
    前記要求されているリソースに関連付けられた新しいアクセス制御ポリシを作成することであって、前記新しいアクセス制御ポリシは、前記要求エンティティが前記要求されているリソースにアクセスするための前記新しい特権を有することを示す、ことと、
    前記新しい特権に基づいて前記要求エンティティにメッセージを送信することであって、前記メッセージは、前記要求エンティティの前記リソースにアクセスするための前記要求が認可されていることを示す、ことと
    を含む、方法。
  11. 前記サービス層エンティティが前記要求エンティティの前記動的承認を行うことにおいて相談すべき前記別のエンティティの識別は、前記要求されているリソースに関連付けられた前記アクセス制御ポリシに関連付けられた動的承認ポリシにおいて提供される、請求項１０に記載の方法。
  12. 前記動的承認が行われた後、前記要求エンティティのための付与された特権のリストおよび前記付与された特権に関連付けられた存続期間を前記別のエンティティから受信することをさらに含む、請求項１０に記載の方法。
  13. 前記新しいアクセス制御ポリシは、前記付与された特権のリストを含む、請求項１２に記載の方法。
  14. 前記新しいアクセス制御ポリシは、一時的である、請求項１３に記載の方法。
  15. 前記サービス層エンティティによって、前記動的承認ポリシを受信することをさらに含む、請求項１１に記載の方法。
  16. 前記動的承認は、前記要求エンティティが支払を行ったという指示を受信した後、行われる、請求項１０に記載の方法。
  17. 前記動的承認は、前記要求エンティティがバータ条件を満たしたという指示を受信した後、行われる、請求項１０に記載の方法。
  18. 前記動的承認は、前記要求エンティティについての評判情報を評価することを含む、請求項１０に記載の方法。
  19. 前記コンピュータ実行可能命令は、前記サービス層エンティティによって、前記サービス層エンティティが前記要求エンティティの動的承認を行うことにおいて相談すべき前記通信ネットワークの前記別のエンティティに情報を送信することを前記装置にさらに行わせ、前記情報は、前記要求エンティティの識別、前記要求されているリソースに関連付けられたタイプの指示、前記要求されているリソースに対して行うべき動作の指示、前記要求エンティティのＩＰアドレス、前記要求エンティティの場所の指示、前記要求エンティティの役割の指示、および新しい特権が要求されている時間のスケジュールまたは窓の指示のうちの１つ以上を含む、請求項１に記載の装置。
  20. 前記サービス層エンティティによって、前記サービス層エンティティが前記要求エンティティの動的承認を行うことにおいて相談すべき前記通信ネットワークの前記別のエンティティに情報を送信することをさらに含み、前記情報は、前記要求エンティティの識別、前記要求されているリソースに関連付けられたタイプの指示、前記要求されているリソースに対して行うべき動作の指示、前記要求エンティティのＩＰアドレス、前記要求エンティティの場所の指示、前記要求エンティティの役割の指示、および新しい特権が要求されている時間のスケジュールまたは窓の指示のうちの１つ以上を含む、請求項１０に記載の方法。
JP2018510739A 2015-08-28 2016-08-26 サービス層動的承認 Active JP6560442B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562211471P 2015-08-28 2015-08-28
US62/211,471 2015-08-28
PCT/US2016/048938 WO2017040263A1 (en) 2015-08-28 2016-08-26 Service layer dynamic authorization

Publications (2)

Publication Number Publication Date
JP2018533857A JP2018533857A (ja) 2018-11-15
JP6560442B2 true JP6560442B2 (ja) 2019-08-14

Family

ID=56894280

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018510739A Active JP6560442B2 (ja) 2015-08-28 2016-08-26 サービス層動的承認

Country Status (6)

Country Link
US (1) US20170063931A1 (ja)
EP (2) EP3342125B1 (ja)
JP (1) JP6560442B2 (ja)
KR (1) KR102112106B1 (ja)
CN (2) CN113766507B (ja)
WO (1) WO2017040263A1 (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150131902A (ko) * 2014-05-16 2015-11-25 삼성전자주식회사 음성 호 서비스 품질을 높이는 방법 및 장치
CN108141447B (zh) 2015-09-01 2021-08-24 康维达无线有限责任公司 服务层注册
EP3398321B1 (en) * 2015-12-30 2021-08-18 Convida Wireless, LLC Semantics based content specification of iot data
US20180139090A1 (en) * 2016-11-15 2018-05-17 John Geiger Method for secure enrollment of devices in the industrial internet of things
FR3061390B1 (fr) 2016-12-28 2022-12-16 Overkiz Procede de configuration, de controle ou de supervision d’une installation domotique
FR3061400A1 (fr) * 2016-12-28 2018-06-29 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
FR3061399B1 (fr) 2016-12-28 2023-04-21 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
KR101768545B1 (ko) * 2017-03-28 2017-08-17 주식회사 한미이앤씨 배전선로의 전원 분산을 제어하는 장치
EP3432534B1 (en) * 2017-07-17 2021-02-24 Atos IT Solutions and Services GmbH Local authorization decision method
US10956551B2 (en) * 2017-08-07 2021-03-23 Clarius Mobile Health Corp. Systems and methods for securing operation of an ultrasound scanner
US11057362B2 (en) * 2017-10-05 2021-07-06 Ca, Inc. Adaptive selection of authentication schemes in MFA
KR102627115B1 (ko) * 2017-12-18 2024-01-23 콘비다 와이어리스, 엘엘씨 Iot/m2m 서비스 계층에서의 데이터 또는 서비스들에 대한 컨텍스트 인식 허가
US10776509B2 (en) * 2018-04-13 2020-09-15 Mastercard International Incorporated Computer-implemented methods, systems comprising computer-readable media, and electronic devices for secure multi-datasource query job status notification
US11847241B1 (en) * 2018-04-20 2023-12-19 Amazon Technologies, Inc. Management of service permissions
US11025425B2 (en) 2018-06-25 2021-06-01 Elasticsearch B.V. User security token invalidation
US11223626B2 (en) * 2018-06-28 2022-01-11 Elasticsearch B.V. Service-to-service role mapping systems and methods
US11196554B2 (en) 2018-07-27 2021-12-07 Elasticsearch B.V. Default password removal
US11023598B2 (en) 2018-12-06 2021-06-01 Elasticsearch B.V. Document-level attribute-based access control
US11297108B2 (en) * 2018-12-28 2022-04-05 Comcast Cable Communications, Llc Methods and systems for stateful network security
GB2582738B (en) * 2019-02-01 2021-07-07 Arm Ip Ltd Electronic device registration mechanism
KR102220762B1 (ko) * 2020-06-11 2021-02-25 박정훈 사물인터넷기기를 활용한 스트리밍 방송 후원 시스템
CN116325829A (zh) * 2020-10-09 2023-06-23 上海诺基亚贝尔股份有限公司 用于动态授权的机制
CN112540788A (zh) * 2020-12-03 2021-03-23 南方电网数字电网研究院有限公司 一种兼容多厂商无人机飞控应用app的方法
CN114826629A (zh) * 2021-01-22 2022-07-29 北京京东方技术开发有限公司 数据共享方法、装置、系统、服务器和计算机存储介质
CN112511569B (zh) * 2021-02-07 2021-05-11 杭州筋斗腾云科技有限公司 网络资源访问请求的处理方法、系统及计算机设备
CN113472778B (zh) * 2021-06-30 2023-04-07 中国人民解放军国防科技大学 一种信息网络安全防护信任系统及方法
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
US11310235B1 (en) * 2021-08-04 2022-04-19 Netfay Inc. Internet of things system based on security orientation and group sharing
WO2023180364A1 (en) 2022-03-23 2023-09-28 Curity Ab Graphql access authorization
CN115277145B (zh) * 2022-07-20 2023-05-02 北京志凌海纳科技有限公司 分布式存储访问授权管理方法、系统、设备和可读介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030191719A1 (en) 1995-02-13 2003-10-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US7370365B2 (en) * 2001-09-05 2008-05-06 International Business Machines Corporation Dynamic control of authorization to access internet services
US7746799B2 (en) * 2003-06-20 2010-06-29 Juniper Networks, Inc. Controlling data link layer elements with network layer elements
CN101453339B (zh) * 2006-11-20 2011-11-30 华为技术有限公司 一种网络融合策略计费控制架构的系统及处理方法
US7991902B2 (en) * 2006-12-08 2011-08-02 Microsoft Corporation Reputation-based authorization decisions
US20080147530A1 (en) * 2006-12-19 2008-06-19 Kwan Shu-Leung Programmatically transferring applications between handsets based on license information
US9043861B2 (en) * 2007-09-17 2015-05-26 Ulrich Lang Method and system for managing security policies
CN101453354A (zh) * 2007-11-29 2009-06-10 上海未来宽带技术及应用工程研究中心有限公司 一种基于atca架构的高可用性系统
US9124632B2 (en) * 2011-12-13 2015-09-01 At&T Intellectual Property I, L.P. Method and apparatus for providing privacy management in machine-to-machine communications
KR20130132050A (ko) * 2012-05-25 2013-12-04 한국전자통신연구원 농업용 환경제어 시스템을 위한 플랫폼 장치
KR101453155B1 (ko) * 2012-05-30 2014-10-23 모다정보통신 주식회사 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
CN103927316A (zh) * 2013-01-14 2014-07-16 崔晶渊 基于位置的检索系统
EP3651409B1 (en) * 2013-07-24 2022-11-09 Convida Wireless, LLC Service domain charging systems and methods
KR20150014345A (ko) * 2013-07-29 2015-02-06 주식회사 케이티 요청 메시지의 신뢰성을 확보하는 방법 및 장치
US9536065B2 (en) * 2013-08-23 2017-01-03 Morphotrust Usa, Llc System and method for identity management
US10021103B2 (en) * 2014-02-21 2018-07-10 Samsung Electronics Co., Ltd. Service authorization methods and apparatuses
US20190318348A1 (en) * 2018-04-13 2019-10-17 Dubset Media Holdings, Inc. Media licensing method and system using blockchain

Also Published As

Publication number Publication date
EP3342125B1 (en) 2022-04-27
EP3342125A1 (en) 2018-07-04
WO2017040263A1 (en) 2017-03-09
US20170063931A1 (en) 2017-03-02
CN113766507B (zh) 2024-02-23
CN108141446A (zh) 2018-06-08
CN108141446B (zh) 2021-10-15
JP2018533857A (ja) 2018-11-15
KR20180048766A (ko) 2018-05-10
KR102112106B1 (ko) 2020-05-18
EP4037360A1 (en) 2022-08-03
CN113766507A (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
JP6560442B2 (ja) サービス層動的承認
US11451555B2 (en) Resource-driven dynamic authorization framework
US11387978B2 (en) Systems and methods for securing access rights to resources using cryptography and the blockchain
US11637746B2 (en) Object identification for groups of IoT devices
JP6435057B2 (ja) サービス層における交渉サービスをサポートする方法
US11683353B2 (en) Automated service enrollment in a machine-to-machine communications network
JP7194736B2 (ja) ＩｏＴ／Ｍ２Ｍサービス層のデータまたはサービスに対するコンテキストアウェア認証
US20220263832A1 (en) Method and server for providing user consent to edge application

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190214

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190222

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190228

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190617

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190625

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190718

R150 Certificate of patent or registration of utility model

Ref document number: 6560442

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250