(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-08
(45)【発行日】2022-03-16
(54)【発明の名称】サービス層のためのアクセス制御ポリシーの同期
(51)【国際特許分類】
G06F 16/955 20190101AFI20220309BHJP
G06F 16/28 20190101ALI20220309BHJP
G06F 21/62 20130101ALI20220309BHJP
【ＦＩ】
G06F16/955
G06F16/28
G06F21/62
【請求項の数】
20
(21)【出願番号】P 2019516947
(86)(22)【出願日】2017-09-29
(65)【公表番号】
(43)【公表日】2019-12-19
(86)【国際出願番号】 US2017054255
(87)【国際公開番号】W WO2018064455
(87)【国際公開日】2018-04-05
【審査請求日】2020-09-23
(31)【優先権主張番号】62/401,623
(32)【優先日】2016-09-29
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】515222713
【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー
(74)【代理人】
【識別番号】110002147
【氏名又は名称】特許業務法人酒井国際特許事務所
(72)【発明者】
【氏名】ワン，チョンガン
(72)【発明者】
【氏名】リ，ホンクン
(72)【発明者】
【氏名】リ，シュウ
(72)【発明者】
【氏名】シード，デイル，エヌ．
(72)【発明者】
【氏名】リ，クァン
(72)【発明者】
【氏名】ムラディン，カタリナ，ミハエラ
【審査官】甲斐 哲雄
(56)【参考文献】
【文献】特開平０３－００６６４０（ＪＰ，Ａ）
【文献】特表２０１３－５３６５０６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１０／００２３９９７（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
Ｇ０６Ｆ ２１／６０－２１／８８
(57)【特許請求の範囲】
【請求項1】
サービス層のためのアクセスポリシーの同期のための装置であって、プロセッサと、
前記プロセッサに接続されたメモリと、を備え、
前記メモリは実行可能な命令を備え、前記実行可能な命令は前記プロセッサによって実行される場合、前記プロセッサに
アクセス制御ポリシーのためのリソースをアプリケーションによって作成するための要求メッセージを受信することと、
前記アプリケーションは前記リソースを作成するためのアクセス権を持つという決定に基づいて前記リソースを作成することと、
前記リソースおよび、前記アクセス制御ポリシーのオントロジーに基づいて、前記リソースおよび前記オントロジーに関連付けられたトリプルを生成することと、
前記トリプルをセマンティックグラフストアに送信するための命令を与えることと、
を含む動作を実現させる、装置。
【請求項2】
前記動作は、前記セマンティックグラフストアのアドレスを前記リソースに追加することをさらに含む、請求項１に記載の装置。
【請求項3】
前記動作は、前記リソースに対する前記セマンティックグラフストアのアドレスを新しい属性に追加することをさらに含む、請求項１に記載の装置。
【請求項4】
前記動作は、前記要求メッセージに基づき、前記アプリケーションに、前記リソースのユニフォームリソース識別子を含む応答メッセージを送信する命令を与えることをさらに含む、請求項１に記載の装置。
【請求項5】
前記要求メッセージは、作成対象である前記リソースの表現を有する、請求項１に記載の装置。
【請求項6】
前記要求メッセージは、作成対象であるリソースの表現を有し、前記表現は特権属性の値である、請求項１に記載の装置。
【請求項7】
前記リソースは、複数のアクセス制御ルールを有する特権属性を含む、請求項１に記載の装置。
【請求項8】
前記装置はホスト側共通サービスエンティティである、請求項１に記載の装置。
【請求項9】
サービス層のためのアクセスポリシー同期の方法であって、アクセス制御ポリシーのためであるリソースを、アプリケーションによって作成するための要求メッセージを受信することと、
前記アプリケーションは前記リソースを作成するためのアクセス権を持つという決定に基づいて、前記リソースを作成することと、
前記リソースおよび、前記アクセス制御ポリシーのオントロジーに基づいて、前記リソースおよび前記オントロジーに関連付けられたトリプルを生成することと、
前記トリプルをセマンティックグラフストアに送信するための命令を与えることと、
を含む、方法。
【請求項10】
前記方法は、前記要求メッセージの受信に応答して、前記リソースのユニフォームリソース識別子を有する応答メッセージを、前記アプリケーションに送信する命令を与えることをさらに含む、請求項９に記載の方法。
【請求項11】
前記要求メッセージは、作成対象である前記リソースの表現を有する、請求項９に記載の方法。
【請求項12】
前記要求メッセージは、作成対象であるリソースの表現を有し、前記表現は特権属性の値である、請求項９に記載の方法。
【請求項13】
前記リソースは、複数のアクセス制御ルールを有する特権属性を含む、請求項９に記載の方法。
【請求項14】
前記方法は、前記セマンティックグラフストアのアドレスを前記リソースに付与することをさらに含む、請求項９に記載の方法。
【請求項15】
前記方法は、前記リソースに対する前記セマンティックグラフストアのアドレスを新しい属性に付与することをさらに含む、請求項９に記載の方法。
【請求項16】
前記サービス層のためのアクセスポリシー同期を行う装置はホスト側共通サービスエンティティである、請求項９に記載の方法。
【請求項17】
実行可能な命令を格納するコンピュータ可読記憶媒体であって、前記実行可能な命令はコンピューティングデバイスによって実行される場合、前記コンピューティングデバイスに、アクセス制御ポリシーのためであるリソースを、アプリケーションによって作成するための要求メッセージを受信することと、
前記アプリケーションは前記リソースを作成するためのアクセス権を持つという決定に基づいて、前記リソースを作成することと、
前記リソースおよび、前記アクセス制御ポリシーのオントロジーに基づいて、前記リソースおよび前記オントロジーに関連付けられたトリプルを生成することと、
前記トリプルをセマンティックグラフストアに送信するための命令を与えることと、
を含む動作を実現させる、コンピュータ可読記憶媒体。
【請求項18】
前記動作は、前記リソースに前記セマンティックグラフストアのアドレスを追加することをさらに含む、請求項１７に記載のコンピュータ可読記憶媒体。
【請求項19】
前記動作は、前記リソースに対する前記セマンティックグラフストアのアドレスを新しい属性に追加することをさらに含む、請求項１７に記載のコンピュータ可読記憶媒体。
【請求項20】
前記動作は、前記要求メッセージに基づき、前記アプリケーションに、前記リソースのユニフォームリソース識別子を含む応答メッセージを送信する命令を与えることをさらに含む、請求項１７に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本出願は、「サービス層のためのアクセス制御ポリシーの同期」と題する２０１６年９月２９日出願の米国仮特許出願第６２／４０１，６２３号の利益を主張する。上記出願の内容は参照により全体が本明細書に組み込まれる。
本出願は、「サービス層のためのアクセス制御ポリシーの同期」と題する２０１６年９月２９日出願の米国仮特許出願第６２／４０１，６２３号の利益を主張する。上記出願の内容は参照により全体が本明細書に組み込まれる。
【背景技術】
【0002】
（セマンティックウェブ）
セマンティックウェブは、ワールドワイドウェブコンソーシアム（World Wide Web Consortium:W3C）による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク（Resource Description Framework:RDF）を促進する。
セマンティックウェブは、ワールドワイドウェブコンソーシアム（World Wide Web Consortium:W3C）による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク（Resource Description Framework:RDF）を促進する。
【0003】
セマンティックウェブは、データのために特に設計された言語、すなわちリソース記述フレームワーク（RDF）、ウェブオントロジー言語（Web Ontology Language:OWL）、および拡張マークアップ言語（Extensible Markup Language:XML）でパブリッシュすることを伴う。これらの技術を組み合わせて、リンクされたデータのウェブを介してウェブ文書のコンテンツを補足または置換する記述を提供する。したがって、コンテンツはそれ自体を、ウェブアクセス可能データベース内に記憶される記述データとして、または特に、XMLが組み込まれた拡張HTML（Extensible HTML:XHTML）文書、もしくはより多くの場合、別個に記憶されるレイアウトまたはレンダリングの指図を伴う純粋なXML文書におけるマークアップとして現し得る。
【0004】
（セマンティックウェブスタック）
セマンティックウェブスタックは、図１に示されるように、W3Cによって規定されたセマンティックウェブのアーキテクチャを例示する。コンポーネントの機能および関係は、図１に示され、以下に説明する。XMLは、文書内のコンテンツ構造のための基本的な構文を提供するが、その中に含まれるコンテンツの意味にセマンティクスを関連付けしない。Turtle等の代替構文が存在するため、XMLは現在、ほとんどの場合でセマンティックウェブ技術に必要なコンポーネントではない。Turtleは事実上の業界標準だが、正式な標準化プロセスを経ていない。XMLスキーマは、XML文書内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。RDFは、データモデルを表すための単純な言語であり、主語－述語－目的語、例えば、S-P-OトリプルまたはRDFトリプルの形態でオブジェクト（「ウェブリソース」）およびその関係を参照する。RDFベースのモデルは、種々の構文、例えば、RDF/XML、N3、TurtleおよびRDFaで表され得る。RDFは、セマンティックウェブの基本的な規格である。
セマンティックウェブスタックは、図１に示されるように、W3Cによって規定されたセマンティックウェブのアーキテクチャを例示する。コンポーネントの機能および関係は、図１に示され、以下に説明する。XMLは、文書内のコンテンツ構造のための基本的な構文を提供するが、その中に含まれるコンテンツの意味にセマンティクスを関連付けしない。Turtle等の代替構文が存在するため、XMLは現在、ほとんどの場合でセマンティックウェブ技術に必要なコンポーネントではない。Turtleは事実上の業界標準だが、正式な標準化プロセスを経ていない。XMLスキーマは、XML文書内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。RDFは、データモデルを表すための単純な言語であり、主語－述語－目的語、例えば、S-P-OトリプルまたはRDFトリプルの形態でオブジェクト（「ウェブリソース」）およびその関係を参照する。RDFベースのモデルは、種々の構文、例えば、RDF/XML、N3、TurtleおよびRDFaで表され得る。RDFは、セマンティックウェブの基本的な規格である。
【0005】
RDFグラフは、エッジがRDFトリプルの「述語」を表すのに対し、グラフのノードは、RDFトリプルの「主語」および／または「目的語」を表す有向グラフである。すなわち、RDFトリプルに記述されるリンク構造は、そのような有向RDFグラフを形成する。RDFスキーマ（例えば、RDF Schema 1.1）は、プロパティおよびクラスの一般化された階層のためのセマンティクスを用いてRDFベースのリソースのプロパティおよびクラスを記述するための語彙であり、RDFを拡張する。OWLは、プロパティおよびクラス、とりわけ、クラス間の関係（例えば、離接）、基数（例えば、「正確に１つ」）、相等性、より豊富なタイプのプロパティ、プロパティの特性（例えば、対称性）、および列挙されたクラスを記述するために、より多くの語彙を追加する。
【0006】
SPARQL（例えば、SPARQL 1.1）は、ウェブ上またはRDFストア（例えば、セマンティックグラフストア）においてRDFグラフのコンテンツ（例えば、RDFトリプル）をクエリおよび操作するための、セマンティックウェブデータソースのためのプロトコルおよびクエリ言語である。SPARQL1.1クエリは、RDFグラフのためのクエリ言語であり、データがRDFとしてネイティブに記憶されているか、またはミドルウェアを介してRDFとして見なされるかにかかわらず、多様なデータソースにわたるクエリを表すために使用され得る。SPARQLは、その論理積および論理和と一緒に、必要とされるグラフパターンおよび随意のグラフパターンをクエリするための機能を含む。SPARQLは、集約、サブクエリ、否定、式による値の作成、拡張値試験、およびソースRDFグラフによるクエリの制約もサポートする。SPARQLクエリの結果は、結果のセットまたはRDFグラフであり得る。SPARQL1.1更新は、RDFグラフのための更新言語である。SPARQL1.1更新は、RDFのためにSPARQLクエリ言語由来の構文を使用する。更新動作は、セマンティックグラフストアにおけるグラフの集合に対して行われる。動作は、セマンティックグラフストア内のRDFグラフを更新、作成、および除去するために提供される。RIFは、W3Cルール交換フォーマットである。RIFは、コンピュータが実行可能なウェブルールを表すためのXML言語である。RIFは、ダイアレクトと呼ばれる複数のバージョンを提供する。ダイアレクトは、RIF基本論理ダイアレクト（RIF Basic Logic Dialect:RIF-BLD）およびＲＩＦ生成ルールダイアレクト（RIF Production Rules Dialect：RIF PRD）を含む。
【0007】
（セマンティック検索とセマンティッククエリ）
リレーショナルデータベースは、データ間の関係を暗示的に含む。例えば、（２つのコンテンツテーブルに格納され、追加のリンクテーブルと連結された）顧客と製品との関係は、開発者によって書かれたクエリステートメント（例えば、リレーショナルデータベースの場合、SQLが使用される）にのみ現れる。クエリを書くにはデータベーススキーマの正確な知識が要求される。多くのリレーショナルデータベースは、データがツリー構造に構成される階層型データベースとしてモデル化される。データは、リンクを介して互いに連結されるレコードとして格納される。階層型データベースモデルにおけるレコードは、リレーショナルデータベースモデルの行（またはタプル）に対応し、エンティティタイプは、テーブル（または親子関係）に対応する。レコードのサーチまたはクエリは、SQLまたは非SQLサーチエンジンによって実施され得る。
リレーショナルデータベースは、データ間の関係を暗示的に含む。例えば、（２つのコンテンツテーブルに格納され、追加のリンクテーブルと連結された）顧客と製品との関係は、開発者によって書かれたクエリステートメント（例えば、リレーショナルデータベースの場合、SQLが使用される）にのみ現れる。クエリを書くにはデータベーススキーマの正確な知識が要求される。多くのリレーショナルデータベースは、データがツリー構造に構成される階層型データベースとしてモデル化される。データは、リンクを介して互いに連結されるレコードとして格納される。階層型データベースモデルにおけるレコードは、リレーショナルデータベースモデルの行（またはタプル）に対応し、エンティティタイプは、テーブル（または親子関係）に対応する。レコードのサーチまたはクエリは、SQLまたは非SQLサーチエンジンによって実施され得る。
【0008】
図２に示されるように、階層型データベースモデルは、各子レコードは１つの親のみ有し得る一方で各親レコードは１つ以上の子レコードを有し得ることを要求する。データをある階層型データベースから検索するためには、ルートノードから開始してツリー全体を走査する必要がある。この構造は単純であるが、関係が１対多の関係に制限されるので、非柔軟である。
【0009】
リンクされたデータは、明示的にデータ間のすべての関係を含む。リレーショナルデータベースにおいて記述される前述の例では、クエリコードは、書き込まれる必要がない。各顧客のための正しい製品は、自動的にフェッチすることができる。この単純例は、ささいなものであるが、リンクされたデータの真の力が発揮されるのは、情報のネットワーク（都市、州、および国のようなそれらのジオスペース情報を伴う顧客、サブカテゴリおよびスーパーカテゴリ内でのカテゴリを伴う製品）が作成される場合である。ここで、システムは、特定の場所と製品カテゴリとの接続を探す、より複雑なクエリおよび解析に自動的に回答することができる。このクエリのための開発努力は、省略される。セマンティッククエリの実行は、情報のネットワーク上を移動して調べ、一致を見出すことによって実施される（データグラフ走査とも呼ばれる）。
【0010】
セマンティック検索は、検索者の意図と、ウェブ上であるかクローズドシステム内であるかにかかわらず、検索可能なデータ空間内に現れるときの文脈上の意味とを理解することによって検索精度を改善して、より関連性の高い結果を生成しようとする。セマンティック検索システムは、検索の文脈、場所、意図、単語、同義語、一般化および特殊クエリ、概念一致、および自然言語クエリの変形例を含む種々の点を考慮し、関連する検索結果を提供する。GoogleおよびBingのような主要なウェブ検索エンジンは、セマンティック検索のいくつかの要素を取り込んでいる。セマンティック検索は、セマンティクスを使用して、非常に関連性の高い検索結果を生成する。ほとんどの場合、その目標は、大まかに関連したキーワード結果のリストをユーザに分類させるのではなく、ユーザがクエリした情報を届けることである。例えば、セマンティクスは、リレーショナルデータベース内の記録検索またはクエリを強化するために使用され得る。
【0011】
セマンティッククエリは、連想的および文脈的性質のクエリおよび分析を可能にする。セマンティッククエリは、データ内に含まれる構文情報、セマンティック情報および構造情報に基づいて、明示的に導かれる情報および暗示的に導かれる情報の両方の探索を可能にする。セマンティッククエリは、正確な結果（おそらく、ただ１つの情報の独特の選択）を届けるように、またはパターン照合およびデジタル推論を通してより制限のない質問に回答するように設計される。
【0012】
セマンティッククエリは、名前付きグラフ、リンクされたデータまたはトリプルに働きかける。このことにより、クエリが、情報間の実際の関係を処理し、データのネットワークからの回答を推測することを可能にする。これは、セマンティック検索とは対照的であり、セマンティック検索は、セマンティックを非構造化されたテキストにおいて使用し、より良好な検索結果を生成する（例えば、自然言語処理）。
【0013】
技術的観点から、セマンティッククエリは、データベースクエリとよく似た正確なリレーション型の動作である。セマンティッククエリは、構造化されたデータに働きかける。したがって、演算子（例えば、＞、＜、および＝）、名前空間、パターン照合、サブクラス化、推移関係、セマンティックルール、および文脈全文検索のような広範囲の特徴を利用する可能性を有する。W3Cのセマンティックウェブ技術スタックは、セマンティッククエリをSQLに類似した構文で公式化するためのSPARQLを提供する。セマンティッククエリは、トリプルストア、グラフデータベース、セマンティックウィキ、自然言語および人工知能システムにおいて使用される。
【0014】
セマンティッククエリの別の側面は、関係のタイプをシステムへの知能の組み込みに使用する場合があることである。顧客と製品との関係は、近隣地域とその都市との関係とは基本的に異なる性質を有する。後者は、セマンティッククエリエンジンが、マンハッタンに住んでいる顧客がニューヨーク市にも住んでいることを推測することを可能にする一方、他の関係は、より複雑なパターンおよび「文脈分析」を有し得る。このプロセスは、推測または推論と呼ばれ、所与の事実に基づいて新しい情報を導くくめのソフトウェアの能力である。
【0015】
（oneM2Mファンクショナルアーキテクチャ）
開発中のoneM2M規格（oneM2M-TS-0001 oneM2M Functional Architecture －V2.9.0）は、共通サービスエンティティ（common service entity:CSE）と呼ばれるサービス層を定義する。サービス層の目的は、異なる「垂直」M2Mシステムおよびアプリケーションによって利用可能な「水平」サービスを提供することである。CSEは、図３に示されるように、複数の参照点をサポートする。Mca参照点は、アプリケーションエンティティ（Application Entity:AE）とインタフェースをとる。Mcc参照点は、同一サービスプロバイダドメイン内の別のCSEとインタフェースをとり、Mcc’参照点は、異なるサービスプロバイダドメイン内の別のCSEとインタフェースをとる。Mcn参照点は、下層ネットワークサービスエンティティ（Network Service Entity:NSE）とインタフェースをとる。NSEは、デバイス管理、場所サービスおよびデバイストリガ等の下層ネットワークサービスをCSEに提供する。
開発中のoneM2M規格（oneM2M-TS-0001 oneM2M Functional Architecture －V2.9.0）は、共通サービスエンティティ（common service entity:CSE）と呼ばれるサービス層を定義する。サービス層の目的は、異なる「垂直」M2Mシステムおよびアプリケーションによって利用可能な「水平」サービスを提供することである。CSEは、図３に示されるように、複数の参照点をサポートする。Mca参照点は、アプリケーションエンティティ（Application Entity:AE）とインタフェースをとる。Mcc参照点は、同一サービスプロバイダドメイン内の別のCSEとインタフェースをとり、Mcc’参照点は、異なるサービスプロバイダドメイン内の別のCSEとインタフェースをとる。Mcn参照点は、下層ネットワークサービスエンティティ（Network Service Entity:NSE）とインタフェースをとる。NSEは、デバイス管理、場所サービスおよびデバイストリガ等の下層ネットワークサービスをCSEに提供する。
【0016】
CSEは、「発見」、「データ管理およびリポジトリ」等の「共通サービス機能（Common Service Function:CSF）」と呼ばれる、複数の論理機能を含む。図４は、oneM2Mによって規定されるCSFをいくつか図示している。
【0017】
oneM2Mアーキテクチャは、図３に示すように以下のタイプのノードを可能にする。アプリケーションサービスノード（Application Service Node:ASN）は、１つのCSEを含み、少なくとも１つのアプリケーションエンティティ（AE）を含むノードである。ASNは、M2Mデバイス内に常駐し得る。アプリケーション専用ノード（Application Dedicated Node:ADN）：ADNは、少なくとも１つのAEを含むが、CSEを含まないノードである。ゼロ以上のADNが、oneM2Mシステムのフィールドドメイン内に存在し得る。物理的マッピングの例：アプリケーション専用ノードは、制約付きM2Mデバイス内に常駐し得る。中間ノード（Middle Node:MN）MNは、１つのCSEを含み、ゼロ以上のAEを含むノードである。ゼロ以上のMNが、oneM2Mシステムのフィールドドメイン内に存在し得る。MNは、M2Mゲートウェイ内に常駐し得る。インフラストラクチャノード（Infrastructure Node:IN）INは、１つのCSEを含み、ゼロ以上のAEを含むノードである。INは、oneM2Mサービスプロバイダごとにインフラストラクチャドメイン内に１つだけ存在する。IN内のCSEは、他のノードタイプには適用できないCSE機能を含み得る。物理的マッピングの例：INは、M2Mサービスインフラストラクチャ内に常駐し得る。非oneM2Mノード（NoDN）は、oneM2Mエンティティ（AEまたはCSEのいずれでもない）を含まないノードである。このようなノードは、管理を含む、インターワーク目的のために、oneM2Mシステムにアタッチされたデバイスを表す。
【0018】
（oneM2Mにおけるアクセス制御ポリシー）
図５に示すように、＜accessControlPolicy＞リソースは、privilegesおよびselfPrivileges属性を備え、それらは（accessControlOriginatorsによって定義される）どのエンティティが（accessControlContextsによって定義される）指定されたコンテキスト内で（accessContolOperationsによって定義される）所定の動作を実行するprivilegesを有し、特定のリソースに対するアクセス決定を行うためCSEによって使用されるか、を定義するアクセス制御ルールのセットを表す。特定のprivileges属性について、アクセス制御ルールはどのAE/CSEがどの動作を許可されるかを定義する。したがって、アクセス制御ルールのセットに対して、動作がセット内の１つ以上のアクセス制御ルールによって許可される場合、その動作が許可される。＜accessControlPolicy＞リソースタイプではないリソースについて、そのようなリソースの共通属性accessControlPolicyIDsは、そのリソースを＜accessControlPolicy＞リソースにリンクする識別子のリストを含む。そのようなリソースのためのＣＳＥアクセス決定は、＜accessControlPolicy＞リソース内に定義されたprivileges属性によって表されるアクセス制御ルールのセットの評価に従うものとする。selfPrivileges属性は、＜accessControlPolicy＞リソース自体のためのアクセス制御ルールのセットを表す。＜accessControlPolicy＞リソースのためのCSEアクセス決定は、＜accessControlPolicy＞リソース自体に定義されたselfPrivileges属性によって表されるアクセス制御ルールのセットの評価に従うものとする。
図５に示すように、＜accessControlPolicy＞リソースは、privilegesおよびselfPrivileges属性を備え、それらは（accessControlOriginatorsによって定義される）どのエンティティが（accessControlContextsによって定義される）指定されたコンテキスト内で（accessContolOperationsによって定義される）所定の動作を実行するprivilegesを有し、特定のリソースに対するアクセス決定を行うためCSEによって使用されるか、を定義するアクセス制御ルールのセットを表す。特定のprivileges属性について、アクセス制御ルールはどのAE/CSEがどの動作を許可されるかを定義する。したがって、アクセス制御ルールのセットに対して、動作がセット内の１つ以上のアクセス制御ルールによって許可される場合、その動作が許可される。＜accessControlPolicy＞リソースタイプではないリソースについて、そのようなリソースの共通属性accessControlPolicyIDsは、そのリソースを＜accessControlPolicy＞リソースにリンクする識別子のリストを含む。そのようなリソースのためのＣＳＥアクセス決定は、＜accessControlPolicy＞リソース内に定義されたprivileges属性によって表されるアクセス制御ルールのセットの評価に従うものとする。selfPrivileges属性は、＜accessControlPolicy＞リソース自体のためのアクセス制御ルールのセットを表す。＜accessControlPolicy＞リソースのためのCSEアクセス決定は、＜accessControlPolicy＞リソース自体に定義されたselfPrivileges属性によって表されるアクセス制御ルールのセットの評価に従うものとする。
【0019】
＜accessControlPolicy＞リソースは、表１に示される属性を含む。privilegesおよびselfPrivileges属性において表されるアクセス制御ルールのセットは、以下に説明される３つのタプル、accessControlOriginators、accessControlContexts、accessControlOperations、を備える。
【表1】
【0020】
accessControlOriginatorsはaccess-control-rule-tupleの必須パラメータであり、このアクセス制御ルールを使用することを許可される発信側のセットを表す。発信側のセットは、パラメータのリストとして記述され、該パラメータのタイプは、該リスト内で変動し得る。表２は、accessControlOriginatorsにおいてサポートされるパラメータのタイプを記述する。
【表2】
【0021】
originatorIDが、＜AE＞または＜remoteCSE＞をメンバとして含む、＜group＞リソースのresource-IDであるとき、リソースのホスト側CSEは、要求の発信側が＜group＞リソースのmemberID属性内のメンバのうちの１つに一致するかどうかを決定する（例えば、＜group＞リソースを検索することによって）。＜group＞リソースが、検索されることができない、または存在しない場合、要求は、否認されるものとする。
【0022】
accessControlContextsは、リストを含む、access-control-rule-tuple内の任意のパラメータであり、リストの各要素は、存在するとき、本アクセス制御ルールを使用することが許可されるコンテキストを表す。各要求コンテキストは、パラメータのセットによって記述され、パラメータのタイプは、セット内で変動し得る。表３は、accessControlContexts内でサポートされるタイプのパラメータを記述する。
【0023】
以下の従来の発信側accessControlContextsは、CSEによるアクセス制御ポリシーチェックのために考慮されるものとする。
【表3】
【0024】
accessControlOperationsは、このアクセス制御ルールを用いて権限付与される動作のセットを表すaccess-control-rule-tupleにおいて必須パラメータである。表４は、accessControlOperationsによって権限付与される動作のサポートされたセットを記述する。
【0025】
以下のaccessControlOperationsは、CSEによってチェックされるアクセス制御ポリシーについて考慮するものとする。
【表4】
【0026】
accessControlPolicyIDsは、oneM2M-TS-0001 oneM2M Functional Architecture－V2.9.0において定義される、多くのoneM2Mリソースの共通属性である。この属性は、＜accessControlPolicy＞リソースの識別子のリストを含む。参照される＜accessControlPolicy＞リソースにおいて定義されるprivileges（特権）属性は、誰が、特定目的（例えば、検索、更新、削除など）のためこの属性を含むリソースにアクセスすることを許可されているか決定する。
【0027】
リソースタイプがaccessControlPolicyIDs属性定義を持たない場合、該リソースのaccessControlPolicyIDsは、異なるやり方で管理される、例えば、親に関連付けられたaccessControlPolicyIDsは、accessControlPolicyIDs属性定義を持たない子リソースに適用してもよい、または、アクセスの特権はシステムによって固定される。このような場合にアクセス制御を扱う方法については、対応するリソースタイプ定義および手順を参照されたい。
【0028】
リソースタイプがaccessControlPolicyIDs属性の定義を持つが、（任意の）accessControlPolicyIDs属性は設定されない場合、または、有効な、既存の＜accessControlPolicy＞リソースに対応しない値に設定される場合、または、到達不可能な（例えば、オフラインまたは到達不可能であるリモートCSE上に位置しているため）＜accessControlPolicy＞リソースを参照する場合、システムのデフォルトのアクセスprivilegesを適用することとする。
【0029】
privileges（すなわち、＜accessControlPolicy＞リソースのprivilegesまたはSelfPrivileges属性として格納される）がそれを許可する場合、および許可しさえすれば、すべてのリソースはアクセス可能であり、したがって、すべてのリソースは、関連するAccessControlPolicyIDs属性を、明示的（リソース自体に属性を設定する）または暗黙的（親privilegesまたはシステムのデフォルトポリシーのいずれかを使用することによる）に、有することとする。このことは、リソースの作成中発信側が特定のaccessControlPolicyIDsを提供しない場合システムがデフォルトのアクセスprivilegesを提供することを意味する。
【0030】
（oneM2Mにおけるセマンティック使用可能性）
図６に示す＜semanticDescriptor＞リソースは、リソースおよび場合によりサブリソースに関するセマンティック記述を記憶するために使用される。このような記述は、オントロジーに従って提供され得る。セマンティック情報は、oneM2Mシステムのセマンティック機能によって使用され、アプリケーションまたはCSEにも利用可能である。＜semanticDescriptor＞リソースは、表５に規定される属性を含むものとする。
図６に示す＜semanticDescriptor＞リソースは、リソースおよび場合によりサブリソースに関するセマンティック記述を記憶するために使用される。このような記述は、オントロジーに従って提供され得る。セマンティック情報は、oneM2Mシステムのセマンティック機能によって使用され、アプリケーションまたはCSEにも利用可能である。＜semanticDescriptor＞リソースは、表５に規定される属性を含むものとする。
【表5】
【0031】
（oneM2Mにおけるセマンティックフィルタリング提案）
一般フィルタリングは、要求動作に規定されたフィルタ基準を有することによってサポートされる（oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0第8.1.2節）。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値がoneM2M TR-0007-Study＿on＿Abstraction＿and＿Semantics＿Enablement-V2.11.0第8.5.4節に提案されており、定義は、以下の表６に示される。複数のインスタンスが、フィルタ基準を評価するための一般的ルールに従い使用されてもよく、そのことは「OR」セマンティクスが適用される、すなわち、セマンティックフィルタのうちの１つ以上のものがセマンティック記述に一致する場合、セマンティックフィルタ基準のための全体的結果が真であることを意味する。なお、以下の表におけるセマンティクスは、oneM2M TR-0007-Study＿on＿Abstraction＿and＿Semantics＿Enablement-V2.11.0において定義され、oneM2M-TS-0001 oneM2M Functional Architecture－V2.9.0における要求パラメータsemanticFilterに対応することに留意されたい。前記semanticFilterパラメータに含まれるSPAQRLクエリが、親リソースの複数の＜semanticDescriptor＞子リソースのうちの１つにおいてセマンティックトリプルに一致する場合、このセメンティックフィルタリングは成功であり、対応する親リソースがリターンされることを意味する。
一般フィルタリングは、要求動作に規定されたフィルタ基準を有することによってサポートされる（oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0第8.1.2節）。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値がoneM2M TR-0007-Study＿on＿Abstraction＿and＿Semantics＿Enablement-V2.11.0第8.5.4節に提案されており、定義は、以下の表６に示される。複数のインスタンスが、フィルタ基準を評価するための一般的ルールに従い使用されてもよく、そのことは「OR」セマンティクスが適用される、すなわち、セマンティックフィルタのうちの１つ以上のものがセマンティック記述に一致する場合、セマンティックフィルタ基準のための全体的結果が真であることを意味する。なお、以下の表におけるセマンティクスは、oneM2M TR-0007-Study＿on＿Abstraction＿and＿Semantics＿Enablement-V2.11.0において定義され、oneM2M-TS-0001 oneM2M Functional Architecture－V2.9.0における要求パラメータsemanticFilterに対応することに留意されたい。前記semanticFilterパラメータに含まれるSPAQRLクエリが、親リソースの複数の＜semanticDescriptor＞子リソースのうちの１つにおいてセマンティックトリプルに一致する場合、このセメンティックフィルタリングは成功であり、対応する親リソースがリターンされることを意味する。
【表6】
【0032】
上記の提案は、以下の仮定を使用する。セマンティック記述は、RDFトリプル（表現、例えば、RDF/XML、Turtle、oneM2M内にまだ完全に規定されていない記述フォーマット）として規定され、セマンティックフィルタ基準は、セマンティック記述に対して実行されるべきSPARQL要求のために使用されるであろう。
【0033】
以下は、oneM2M TR-0007に示されているセマンティックフィルタリング例である。
【表7】
【0034】
これは、my:myDevice1によって記述されるAEリソースは結果セットに含まれるが、my:myDevice2によって記述されるAEリソースは含まれないことを意味する。
【0035】
単一検索のための関連セマンティック情報は、異なる＜semanticDescriptor＞リソース間に分散され得る場合がある。図７に示される例は、このケースを図示する。ボックスはセマンティックフィルタの範囲を表す、すなわち、これはセマンティックフィルタを評価するために必要な情報である。主語－述語－目的語関係を表すセマンティックグラフが示されており、このグラフの異なる部分（卵形によって表される）は、異なる＜semanticDescriptor＞リソース内に記憶されている。セマンティックフィルタリングは、完全なセマンティックグラフ（の一部）に適用される必要があり、そのことによって、グラフの異なる複数の部分をセマンティック動作の実行のため一緒に置かなければならないという問題が生じる。
【0036】
この問題は概して、セマンティックウェブの領域では明らかではない。クラスインスタンスを識別するURIが直接デリファレンスし得ることから、概念（例えば、クラス、関係）情報をそのURIに基づいて発見し得るからである。oneM2Mの場合、アクセスされ得るリソースおよびセマンティクスのみが、リソースのコンテンツとして記憶される。
【0037】
現在SPARQL1.1は、SERVICEキーワードを使用してフェデレーテッドクエリをサポートし、遠隔SPARQLエンドポイントのURLが指定され得る。このアプローチに関して、要求側は、どのセマンティック記述子が検索に要求されるセマンティックインスタンスを含むかを予め把握しているであろう。したがって、セマンティック記述子がリソースツリー内に分散されている場合、このアプローチは一般に適用できなくなる。
【0038】
TR-0007に提示される＜semanticDescriptor＞リソースをまたいで記憶されているセマンティック記述に対してセマンティックフィルタリングを可能にするための解決策は、resourceDescriptorLink OWL注釈プロパティの形態で注釈リンクを導入する。この注釈プロパティは、任意のクラスインスタンスのために指定でき、その値は、＜semanticDescriptor＞リソースのURLであり、所与のクラスインスタンスのための追加のRDFトリプルが見出され得る。以下の例は、図９のグラフを作成するために、oneM2Mベースオントロジー（図８）に定義されたクラスおよび関係を用いる。
【0039】
この解決策は、受信側におけるSPARQLベースのセマンティックフィルタリングエンジンのための以下の機能フローを伴う。１）SPARQL要求として公式化されるセマンティックフィルタは、候補リソースのセマンティック記述子リソースのコンテンツに対して実行される。２）実行の過程において、１つ以上のresourceDescriptorLink注釈を伴うクラスインスタンスに遭遇する場合、実行は停止される。３）semanticDescriptorLinkが参照する各々の＜semanticDescriptor＞リソースのコンテンツが、SPARQL要求が実行されているコンテンツに追加される（遅延評価、代替案として、実行前にすべてをフェッチするが、結果として不必要な情報をフェッチすることになり得る）。４）SPARQL要求の実行は、拡大されたコンテンツに対して継続される。５）データリソースおよびセマンティックトリプルのアクセス制御であり、階層的に積層される。
【0040】
本章は、セマンティックトリプルとして提供されるセマンティック情報のアクセス制御を説明する。本章の内容は、現行のoneM2M TR-0007において支持される。現行のoneM2M構築図はもっぱらリソースに基づいているが、これらのリソースは異なるやり方で実装することができる。特にセマンティックトリプルを管理するために、トリプルストアは単純な選択である。トリプルストアは、リソースおよびトリプルに対するアクセス制御を扱う方法に関連する。本章では、セマンティック層とデータ層とで分割される階層的構造を想定した、種々の実装オプションについて記述する。
【0041】
図１０および図１１に示されるように、データベースリソースおよびセマンティックトリプルは、データ層がデータベースリソースおよび関連する機能を含み、セマンティック層がセマンティックトリプルおよび関連するセマンティック機能を含む状態で、階層的積層アーキテクチャに統合され得る。
【0042】
上位層、すなわち図１０のデータ層および図１１のセマンティック層、は複数のアクセス制御ポリシー（Access Control Policy:ACP）を制御および管理する。下位層、すなわち図１０のセマンティック層および図１１のデータ層、はそれぞれセマンティックグラフまたは生データによって上位層をサポートする。これらの層は、異なるCSEに常駐してもよいが、同じCSE上での統合はパフォーマンス効率を向上し得る。
【0043】
図１０は、M2Mシナリオのための従来のデータリソースベースのスキームを示す。データリソースツリーを介したリソース発見は、セマンティック層においてセマンティックリーブ（例えば、分散グラフストア）によってサポートされ得る。ACPは、データ層において＜semanticDescriptor＞リソースに従って保持される。
【0044】
図１１は、セマンティックウェブシナリオのための従来のセマンティックベースのスキームを示す。セマンティッククエリは、データ層におけるデータリソースのURIまたはURLのリターンによってセマンティック層で実行され得る。セマンティックリソース発見も、これらの２層間の適切なマッピングを介してデータ層におけるデータリソースのリターンによって実現されてもよい。セマンティック層におけるトリプルは、それらの特定ACPに関連付けられる。データ層におけるデータリソースは、ACPに関連付けられたトリプル（例えば、そのURIまたはURL）によってアドレスされる。
【0045】
（データベースリソースおよびセマンティックトリプルのためのアクセス制御（パラレル））
現行でサポートされているセマンティック機能よりも、さらに高度なアーキテクチャが必要であり得る。セマンティックマッシュアップのような高度な機能およびセマンティックウェブのような他のセマンティックプラットフォームとの可能なインタラクションをサポートする、種々の構成で使用し得る、データエンティティおよびセマンティックエンティティのコンセプトを以下に紹介する。
現行でサポートされているセマンティック機能よりも、さらに高度なアーキテクチャが必要であり得る。セマンティックマッシュアップのような高度な機能およびセマンティックウェブのような他のセマンティックプラットフォームとの可能なインタラクションをサポートする、種々の構成で使用し得る、データエンティティおよびセマンティックエンティティのコンセプトを以下に紹介する。
【0046】
図１２は、より高度なデータおよびセマンティック特性または機能を備える、インテリジェントIoTシナリオのための例示的スキームを示す。図１２に示すように、パラレルアーキテクチャは、データエンティティおよびセマンティックエンティティを持ち得る。データエンティティまたはセマンティックエンティティはそれぞれ、その範囲内でのアクセス制御を管理するための独自のアクセス制御ポリシー（ACP）を持ってもよい。データエンティティにおけるセマンティックトリプルまたはデータリソースは、特定のACPを関連付けてセマンティックエンティティにエクスポーズされ得る。例えば、データエンティティにおけるセマンティックパブリケーション機能は、セマンティックトリプルを、対応するACPをトリプルに関連付けて、セマンティックエンティティにおけるセントラルグラフストアにエクスポーズし得る。または、例えば、データエンティティにおけるデータアノテーション機能は、データおよび関連するACPをセントラルグラフストーブに、セマンティックエンティティにおけるローカルテンポラリまたはキャッシングリレーショナルデータベース管理システム（Relational Data Base Management System:RDBMS）およびセマンティック推論およびマッピング機能を介して、エクスポーズし得る。
【0047】
セマンティックエンティティにおけるデータリソースおよびセマンティックトリプルも、特定のACPを関連付けて、データエンティティにエクスポーズし得る。例えば、セマンティックエンティティにおけるセマンティックメッシュアップ機能は、該セマンティックメッシュアップからの新しいデータリソースおよび関連ACPを、データエンティティにエクスポーズし得る。または、例えば、セマンティックエンティティにおけるセマンティックアノテーション機能は、セマンティックトリプルおよび関連ACPを、データエンティティにおける＜semanticDescriptor＞リソースにエクスポーズし得る。
【0048】
図１２は、データエンティティおよびセマンティックエンティティが異なるCSEに常駐し得ることを示す。しかし、データエンティティおよびセマンティックエンティティは、同じCSEにも常駐し得る。図１３は、データエンティティおよびセマンティックエンティティの両方を備える論理リソースツリーを示す。
【0049】
（集中管理グラフストアのためのリソースツリーを介した間接アクセス制御）
別のアプローチは実際上、グラフストアに基づくセマンティックフィルタリングである。このアプローチでは、アクセス制御は、まずoneM2Mリソースツリーに対して実施され、許可された＜semanticDescriptor＞リソースを見つける。ただし、このステップは、すべての＜semanticDescriptor＞リソースがアクセス制御ポリシーに対して検索されるため、多くのオーバーヘッドが生じるであろう。許可された＜semanticDescriptor＞は、SPARQLのクエリパターンに追加される。その後、新しいSPARQLはセマンティックグラフストアについて実行される。このソリューションにおいてはいくつかの仮定を考慮する。１）すべての＜semanticDescriptor＞においてトリプルを格納するための集中管理グラフストアが存在する。２）リソースツリーにターゲットURLまたはURIがある状態でクエリ要求に基づいて、クエリの範囲は、該ターゲットURLに従うサブツリーの子リソースとしての＜semanticDescriptor＞および該ターゲットURLに従う＜semanticDescriptor＞にリンクされた関連＜semanticDescriptor＞の両方におけるトリプルに、制限される。
別のアプローチは実際上、グラフストアに基づくセマンティックフィルタリングである。このアプローチでは、アクセス制御は、まずoneM2Mリソースツリーに対して実施され、許可された＜semanticDescriptor＞リソースを見つける。ただし、このステップは、すべての＜semanticDescriptor＞リソースがアクセス制御ポリシーに対して検索されるため、多くのオーバーヘッドが生じるであろう。許可された＜semanticDescriptor＞は、SPARQLのクエリパターンに追加される。その後、新しいSPARQLはセマンティックグラフストアについて実行される。このソリューションにおいてはいくつかの仮定を考慮する。１）すべての＜semanticDescriptor＞においてトリプルを格納するための集中管理グラフストアが存在する。２）リソースツリーにターゲットURLまたはURIがある状態でクエリ要求に基づいて、クエリの範囲は、該ターゲットURLに従うサブツリーの子リソースとしての＜semanticDescriptor＞および該ターゲットURLに従う＜semanticDescriptor＞にリンクされた関連＜semanticDescriptor＞の両方におけるトリプルに、制限される。
【0050】
このソリューションにおいて、＜semanticDescriptor＞のトリプルは、グラフストアの１つのグラフに格納される。リソースツリーにおいてACPの効果を保持するためには、＜semanticDescriptor＞をアンカーとして用いて、リソースツリーにおけるACPを、セマンティックリポジトリについてのクエリ中に使用されるアクセス制御にリンクする。このソリューションの手順を以下に記述する。
【0051】
（セマンティッククエリプロセス前のプレステップ）
１． グラフストアをホストするCSEは、内部オントロジーをクラスSemanticDescriptorおよびatomDescription、およびプロパティdescribedIn、hasSubject、hasObjectおよびhasPropertyによって作成する。
２． ACPがリソースツリーにある各＜semanticDescriptor＞について、グラフストアをホストするCSEは、それぞれの＜semanticDescriptor＞のIRI/URIを用いてセマンティックグラフストアに、対応するセマンティック記述子インスタンスを作成する。セマンティック記述子インスタンスは、定義済みクラスSemanticDescriptorのインスタンスである。
３． グラフストアをホストするCSEは、＜semanticDescriptor＞で見つけられたセマンティックトリプルを、作成された記述子インスタンスに関連付けるために、セマンティックグラフストアにトリプルを追加する。他のCSEのリソースツリーにおける＜semanticDescriptor＞のトリプルは、グラフストアをホストするCSEに通知されることとする。異なるACPを持つ複数の＜semanticDescriptor＞に１つの主語を記述できることを考慮すると、該関連付けは、分類のための各トリプルで実装されることとし、該関連付けトリプルは、＜semanticDescriptor＞に記述される各トリプルに基づいて追加される。図１４は、トリプルとセマンティック記述子インスタンスとの関連付けを示す。
１． グラフストアをホストするCSEは、内部オントロジーをクラスSemanticDescriptorおよびatomDescription、およびプロパティdescribedIn、hasSubject、hasObjectおよびhasPropertyによって作成する。
２． ACPがリソースツリーにある各＜semanticDescriptor＞について、グラフストアをホストするCSEは、それぞれの＜semanticDescriptor＞のIRI/URIを用いてセマンティックグラフストアに、対応するセマンティック記述子インスタンスを作成する。セマンティック記述子インスタンスは、定義済みクラスSemanticDescriptorのインスタンスである。
３． グラフストアをホストするCSEは、＜semanticDescriptor＞で見つけられたセマンティックトリプルを、作成された記述子インスタンスに関連付けるために、セマンティックグラフストアにトリプルを追加する。他のCSEのリソースツリーにおける＜semanticDescriptor＞のトリプルは、グラフストアをホストするCSEに通知されることとする。異なるACPを持つ複数の＜semanticDescriptor＞に１つの主語を記述できることを考慮すると、該関連付けは、分類のための各トリプルで実装されることとし、該関連付けトリプルは、＜semanticDescriptor＞に記述される各トリプルに基づいて追加される。図１４は、トリプルとセマンティック記述子インスタンスとの関連付けを示す。
【0052】
例えば、＜semanticDescriptor＞に“classX property classZ”（S-P-O）として記述される、SDオリジナルトリプルについて、以下の関連付けトリプル（すなわちSD関係トリプル）を追加してこのSDオリジナルトリプルと＜semanticDescriptor＞リソースとの関係を定義する必要がある。
atomDescriptionA hasSubject classX
atomDescriptionA hasObject classZ
atomDescriptionA hasProperty propertyY
atomDescriptionA describedIn SemanticDescriptorA
atomDescriptionA hasSubject classX
atomDescriptionA hasObject classZ
atomDescriptionA hasProperty propertyY
atomDescriptionA describedIn SemanticDescriptorA
【0053】
（SPARQL文によってセマンティッククエリ要求を受信後のプロセス）
１．受信側CSEは、発信側（AE IDまたはCSE ID）が、リソースツリーにおけるACPおよび要求のターゲットURIに基づいてクエリするために用いることを許可されている、＜semanticDescriptor＞を見つける。
２．受信側CSEは、セマンティックグラフストアにおける対応するSemanticDescriptorインスタンス（＜semanticDescriptor＞を持つ同じIRI／URI）を識別する。
３．受信されたオリジナルSPAQRLセマンティッククエリステートメントにおいて、受信側CSEは、ターゲット変数トリプルは識別されたSemanticDescriptorインスタンスに、以下のとおり関連付けられていることを記述するために新しい文を追加する。１）SPARQLクエリにおいて変数およびそれらの関連トリプルを見つける。２）クエリに変数のある各トリプルについてatomDescription変数を作成する。３）各トリプルを備えるatomDescription変数をクエリにおける変数に関連付けてから、atomDescription変数と識別されたSemanticDescriptorインスタンスを関連付けるために文を追加する。図１５は、変数を持つトリプルとsemanticDescriptorインスタンスとの関連付けを示す。
例えば、オリジナルSPAQRLクエリは以下のとおりである。
アクセス制御ポリシーを実施後の許可されたSemanticDescriptorインスタンスがSemanticDescriptorA，である場合、修正されたSPAQRLクエリは以下のようになる。
４．受信側CSEは、グラフストアをクエリするために、修正されたSPARQLセマンティッククエリステートメントを、グラフストアをホストするCSEに送信する。
５．受信側CSEは、グラフストアをホストするCSEから受信されるセマンティッククエリ結果に基づいて応答をコンパイルする。
１．受信側CSEは、発信側（AE IDまたはCSE ID）が、リソースツリーにおけるACPおよび要求のターゲットURIに基づいてクエリするために用いることを許可されている、＜semanticDescriptor＞を見つける。
２．受信側CSEは、セマンティックグラフストアにおける対応するSemanticDescriptorインスタンス（＜semanticDescriptor＞を持つ同じIRI／URI）を識別する。
３．受信されたオリジナルSPAQRLセマンティッククエリステートメントにおいて、受信側CSEは、ターゲット変数トリプルは識別されたSemanticDescriptorインスタンスに、以下のとおり関連付けられていることを記述するために新しい文を追加する。１）SPARQLクエリにおいて変数およびそれらの関連トリプルを見つける。２）クエリに変数のある各トリプルについてatomDescription変数を作成する。３）各トリプルを備えるatomDescription変数をクエリにおける変数に関連付けてから、atomDescription変数と識別されたSemanticDescriptorインスタンスを関連付けるために文を追加する。図１５は、変数を持つトリプルとsemanticDescriptorインスタンスとの関連付けを示す。
例えば、オリジナルSPAQRLクエリは以下のとおりである。
【表8】
【表9】
５．受信側CSEは、グラフストアをホストするCSEから受信されるセマンティッククエリ結果に基づいて応答をコンパイルする。
【0054】
（集中管理セマンティックグラフストアを介したセマンティッククエリのための直接アクセス制御）
＜semanticDescriptor＞のaccessControlPolicyIDs属性によって記述される＜accessControlPolicy＞を、SPARQL動作をセマンティッククエリの一部として実行時、セマンティックグラフストアにおける直接アクセス制御のために使用してもよい。１つの既存のアプローチは、アクセス制御ポリシーをセマンティックグラフストアに直接実装することであり、これによって、集中管理セマンティックグラフストアへのアクセスを制御することがより効率的でスケーラブルになる。このアプローチは以下の主工程を含む。
１）セマンティックグラフストアにおいて＜accessControlPolicy＞によって指定されるアクセス制御ルールを構築する。なお、＜accessControlPolicy＞は＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性によって指定されることに留意されたい。
２）それぞれのaccessControlPolicyIDsまたは＜accessControlPolicy＞を備えるターゲットされたSDオリジナルトリプル（すなわち＜semanticDescriptor＞の記述子属性によって記述されるとおりであるがセマンティックグラフストアに格納されるRDFトリプル）を関連アクセス制御ルールに関連付ける。
３）セマンティックトリプル動作は、発信側に動作を許可するアクセス制御ルールに関連付けられた選択されたセマンティックトリプルで実行される。
＜semanticDescriptor＞のaccessControlPolicyIDs属性によって記述される＜accessControlPolicy＞を、SPARQL動作をセマンティッククエリの一部として実行時、セマンティックグラフストアにおける直接アクセス制御のために使用してもよい。１つの既存のアプローチは、アクセス制御ポリシーをセマンティックグラフストアに直接実装することであり、これによって、集中管理セマンティックグラフストアへのアクセスを制御することがより効率的でスケーラブルになる。このアプローチは以下の主工程を含む。
１）セマンティックグラフストアにおいて＜accessControlPolicy＞によって指定されるアクセス制御ルールを構築する。なお、＜accessControlPolicy＞は＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性によって指定されることに留意されたい。
２）それぞれのaccessControlPolicyIDsまたは＜accessControlPolicy＞を備えるターゲットされたSDオリジナルトリプル（すなわち＜semanticDescriptor＞の記述子属性によって記述されるとおりであるがセマンティックグラフストアに格納されるRDFトリプル）を関連アクセス制御ルールに関連付ける。
３）セマンティックトリプル動作は、発信側に動作を許可するアクセス制御ルールに関連付けられた選択されたセマンティックトリプルで実行される。
【0055】
以下の図１６は、２つのアクセス制御ポリシー（すなわち＜accessControlPolicy1＞および＜accessControlPolicy2＞）を備える、２つの＜semanticDescriptor＞リソースのアクセス制御ポリシーの例である。＜semanticDescriptor1＞に対するアクセスは、＜accessControlPolicy1＞および＜accessControlPolicy2＞によって制御される一方、＜semanticDescriptor2＞に対するアクセスは、＜accessControlPolicy2＞によってのみ制御される。
【0056】
図１７に示す既存のオントロジーは、oneM2M＜accessControlPolicy＞リソースに基づきACPトリプルを構築するよう提案され、２つの新しいクラスaccessControlPolicyおよびaccessControlRuleを定義する。さらに、５つの新しいプロパティ（すなわちhasACPRule、hasACOriginator、hasACOperations、hasACContextsおよびappliedTo）が定義される。hasACPRuleは、accessControlPolicyインスタンスをaccessControlRuleインスタンスにリンクするために用いられる。プロパティhasACOriginator、hasACOperationsおよびhasACContexts（オプション）は基本的にaccessControlRuleインスタンスを記述し、誰がどの条件に従ってどの動作を発行することができるのか指定するために用いられる。プロパティappliedToは、どの＜semanticDescriptor＞リソースにaccessControlPolicyインスタンスを適用する（すなわち＜accessControlPolicy＞および＜semanticDescriptor＞をバインドする）ことができるか記述するために用いられる。なお、このオントロジーは、oneM2M＜accessControlPolicy＞リソースを、accessControlOriginators、accessControlOperationsおよびaccessControlContextsなどのパラメータからaccess－control－rule－tupleが成っているoneM2M－TS－0001において、どのように指定するかに従って、定義されることに留意されたい。
【発明の概要】
【発明が解決しようとする課題】
【0057】
oneM2Mサービス層は、トリプルにおけるセマンティック情報をレギュラリソースにアノテーションするための＜semanticDescriptor＞リソースを提供する。各＜semanticDescriptor＞リソースのトリプルは、セマンティックグラフストア（Semantic Graph Store:SGS）に格納され得る。oneM2Mリソースに対するアクセス制御は、アクセス制御ポリシー（Access Control Policies:ACP）を定義する＜accessControlPolicy＞によって管理される一方、SGSにおけるトリプルへのアクセスは、追加ACPトリプルを、SGSに追加することによって直接制御することができる。ACPトリプルは基本的に、＜accessControlPolicy＞リソースにおいて定義されるACPをモデル化する。現行では、リソースツリーにおける＜accessControlPolicy＞をどのようにSGSにおいてACPトリプルに同期させるかはいまだ未決の問題である。強化ACPオントロジー、ACPトリプルの管理、SD関連トリプルの管理、ACP関連およびSD関連トリプルのプロキシベースの管理、およびセマンティッククエリのパフォーマンスなどの、これらの問題のいくつかに取り組み得る方法、システム、装置を本開示に記載する。
【課題を解決するための手段】
【0058】
強化ACPオントロジーについては、新しいプロパティが既存のACPオントロジーにおけるaccessControlPolicyクラスのために開示される。この新しいプロパティによって、accessControlPolicyインスタンスを個別のSDオリジナルトリプルに関連付けることができる。
【0059】
ACPトリプルを管理することに関して、ホスト側CSEの＜accessControlPolicy＞リソースとSGSのACPトリプルとの同期を保持する方法、システム、装置を本開示に記載する。方法例では、同期を保持するために、ホスト側CSEは以下を実施する。１）新しい＜accessControlPolicy＞リソースを作成時、ホスト側CSEはACPオントロジーに係る新しいACPオントロジーを生成し、これらの新しいACPトリプルをSGSに格納する。２）既存の＜accessControlPolicy＞リソースのprivileges属性を更新時、ホスト側CSEも新しいACPトリプルを生成し、それに従いSGSでの対応する古いACPトリプルを更新する。３）既存の＜accessControlPolicy＞リソースを削除時、ホスト側CSEは、同じ＜accessControlPolicy＞リソースに関連しているものがSGSにあって削除される場合、対応するACPトリプルおよびACPバインドトリプルを除去する。必要な場合のみ、＜accessControlPolicy＞リソースのACPトリプルを作成および更新することもここで考慮する。SD関連トリプルの管理に関して、ACP－SDトリプル、SD関係トリプル、SDオリジナルトリプルをいつどのように作成／更新／削除するかを含む。
【0060】
ACP関連およびSD関連トリプルのプロキシベースの管理については、SPARQLをサポートしSGSに対するインタフェースを持つ、ホスト側CSEは（SGSに対するインタフェースは持たない）他のホスト側CSEのプロキシとして動作し得る。このホスト側CSEは、これらの他のホスト側CSEのSGSに対してACP関連およびSD関連トリプルを追加または更新することに対して責任がある。
【0061】
セマンティッククエリのパフォーマンスについては、クエリイニシエータ（例えば、oneM2M AEまたはCSE）がセマンティッククエリ要求をホスト側CSEに送信時、ホスト側CSEは、このセマンティッククエリ要求（RESTful検索動作またはSPARQL要求であり得る）を新しいSPARQL要求に変換する。この翻訳の一部として、クエリイニシエータの識別子は新しいSPARQL要求のクエリパターンに追加し得る。その後、ホスト側CSEは新しいSPARQL要求をSGSにトランジットする。
【0062】
この概要は、発明を実施するための形態において以下でさらに説明される概念の選択を簡単な形式で紹介するために提供されている。この概要は、特許請求される主題の重要な特徴または本質的な特徴を特定することを意図しておらず、また特許請求される主題の範囲を限定するために用いられることを意図していない。さらに、特許請求される主題は、本開示の任意の部分に記述される任意のまたはすべての不都合を解決する制限に限定されない。
【図面の簡単な説明】
【0063】
添付の図に関連した例の以下の記述からより詳細な理解が得られよう。
【0064】
【発明を実施するための形態】
【0065】
セマンティッククエリのアクセス制御、アクセス制御ポリシーの同期、セマンティッククエリを本開示に記載する。つまり、以下の本開示の対象が記載される。１）accessControlPolicyインスタンスを個別のセマンティック記述子（SD）オリジナルトリプルに適用できるようにする、アクセス制御ポリシー（access control policy:ACP）オントロジーのaccessControlPolicyクラスのプロパティ、２）ACPトリプルの作成、ACPトリプルの更新、ACPトリプルの削除、をいつどのように実施するかを含む、ACPトリプルの管理、３）ACP－SDトリプル、SD関係トリプル、SDオリジナルトリプル、の作成／更新／削除をいつどのように実施するかを含む、SD関連トリプルの管理、４）ACP関連およびSD関連トリプルのプロキシベースの管理、５）SGSに対するインタフェースがあり、該SGSに対するトークは直接なくてもよい他のCSEのプロキシとして、それらのCSEのACP関連およびSD関連トリプルを管理するために動作し得る、ホスト側CSE、６）SPARQL要求ヘ翻訳される際のセマンティッククエリのパフォーマンス。
【0066】
表７は本開示で共通に使用される用語の定義を示す。
【表10-1】
【表10-2】
【0067】
サービス層におけるアクセス制御ポリシー（ACP）の同期の方法、システム、装置に関連付けられる環境の追加的なコンテキストを以下に記述する。図１８に示すように、RDFトリプルの形式（例えば、セマンティック記述子）でのセマンティック記述は、集中管理RDFトリプルデータベース（例えば、セマンティックグラフストア）に置かれる。例えば、医師１５１および医師１５１の患者（例えば、患者１５２および患者１５３）は、それらのセマンティック記述子を集中管理RDFトリプルストアまたはセマンティックグラフストア１５０（SGS１５０）に格納してもよい。医師１５１、患者１５２、患者１５３は、医師および患者のそれぞれの集団によってアクセスし得る、また特に、制御し得るアプリケーションである。医師１５１は自分の患者のセマンティック記述子にわたってセマンティッククエリを、医師１５１がそうすることを患者が許可する場合、実行し得る。患者１５２または患者１５３も、医師１５１が患者１５２または患者１５３に対し許可する場合、彼ら自身のセマンティック記述子および医師１５１のセマンティック記述子の一部にわたって、セマンティッククエリを実行し得る。医師１５１および患者１５２は、許可が与えられない場合、他のセマンティック記述子のそれぞれにわたってセマンティッククエリを実行し得ない。医師１５１は、自分のセマンティック記述子および、患者１５２または患者１５３によって許可が与えられている場合、患者１５２または患者１５３のセマンティック記述子の一部を、更新または削除し得る。患者１５２または患者１５３は、自分自身のセマンティック記述子および、医師１５１によって許可が与えられている場合、医師１５１のセマンティック記述子の一部を更新または削除し得る。図１８には不図示だが、患者１５２および患者１５３の健康関連の実データは、サービス層（例えば、M2Mサーバ）において保持される。つまり、それらの実健康データのACPもまたサービス層に格納される。サービス層においてACPが変更される場合、SGS１５０が、その保持されたトリプルのACPをサービス層に格納された実健康データのACPと同期させるように、SGS１５０を新しいACPで更新する必要がある。
【0068】
図１９は、共通サービスエンティティ（common service entity:CSE）でのリソースツリーを保持する一方で、SGSにセマンティックトリプルを格納する、従来の構成を図示する。リソースツリーは、＜semanticDescriptor＞および＜accessControlPolicy＞などの、種々のリソースを含む。＜accessControlPolicy＞は、＜semanticDescriptor＞リソースにアクセスするためのアクセス制御ルールを定義する。SGSに格納されたセマンティックトリプルは、セマンティック記述子（semantic descriptor:SD）オリジナルトリプル＜semanticDescriptor＞リソースから来る）、SD関係トリプル、ACPトリプル、ACP－SDバインドトリプルを含む。SD関係トリプルは、リソースツリーを介してセマンティック発見の間接的アクセス制御を容易化するために導入された一方で、ACPトリプルおよびACP－SDバインドトリプルは、バックグラウンドで記述されるように、セマンティック発見の直接アクセス制御のため提案される。
【0069】
セマンティックトリプルに対するアクセスを制御するための従来のソリューションがある一方で、既存の問題は、サービス層とSGSとの間のACP同期などのACP機能をどのように実現するかということである。以下の問題をより詳細に論じる。１）SGSにおいていつどのようにACPトリプルを作成するか。２）SGSにおいていつどのようにACPバインドトリプルを作成するか。３）SGSにおいていつどのようにACPトリプルを更新するか。４）SGSにおいていつどのようにACP－SDバインドトリプルを更新するか。５）SGSにおいていつどのようにSD関係トリプルを更新するか。または、６）SGSにおいていつどのようにセマンティッククエリをトリガし実行するか。
【0070】
図２０は、サービス層に格納されたリソースを図示する。該サービス層は、レギュラリソース１６１、セマンティックリソース１６２、ACPリソース１６３などの、多重型のリソースを保持し得る。レギュラリソース１６１は他のサービス層機能を実装しレギュラデータを保持するリソースである。レギュラリソース１６１は、１つ以上のセマンティックリソース１６２またはACPリソース１６３に、それらを子リソースとして付与することによって、またはそれらのユニフォームリソース識別子（URIs）をその属性として付与することによって、関連付けてもよい。例えば、レギュラリソース１６１がセマンティックリソース１６２をその子リソースとして持つ場合、セマンティックリソース１６２は基本的に、レギュラリソース１６１についての余分なセマンティック情報をアノテーションする。直接的にセマンティックリソースを子リソースとして付与するのではなく、レギュラリソース１６１は、セマンティックリソース１６２を指し示すリンクを代替的に付与し得る（例えば、セマンティックリソース１６２のURIをレギュラリソース１６１の属性として付与する）。同様に、レギュラリソース１６１は、ACPリソース１６３をその子リソースとして持ち得る。そこでレギュラリソース１６１へのアクセスはACPリソース１６３に記述されたアクセス制御ポリシーによって制御し得る。その子リソースとしてACPリソース１６３を直接付与するのではなく、レギュラリソース１６１はACPリソース１６３を指し示すリンクを代替的に付与してもよい（例えば、ACPリソース１６３のURIをレギュラリソース１６１の属性として付与する）。
【0071】
引き続き図２０を参照すると、セマンティックリソース１６２は、レギュラリソース１６１を記述するためのセマンティック情報（例えば、RDFトリプル）を保持するリソースである。セマンティックリソース１６２は、その子リソースとしてそれらを付与することによって、またはその属性としてそれらのURIを付与することによって、１つ以上のACPリソースに関連付け得る。例えば、セマンティックリソース１６２はACPリソース１６３をその子リソースとして持ち得る。そこでセマンティックリソース１６２へのアクセスはACPリソース１６３に記述されたアクセス制御ポリシーによって制御されるであろう。ACPリソース１６３を直接その子リソースとして付与するのではなく、セマンティックリソース１６２はACPリソース１６３を指し示すリンクを代替的に付与してもよい（例えば、ACPリソース１６３のURIをセマンティックリソース１６２の属性として付与する）。
【0072】
ACPリソース１６３は、例えば、レギュラリソース１６１にアクセスするためまたはセマンティックリソース１６２にアクセスするための、アクセス制御ポリシーを定義するリソースである。ACPリソース１６３は、その子リソースとしてそれらを付与することによって、またはその属性としてそれらのURIを付与することによって、１つ以上のレギュラリソース１６１またはセマンティックリソース１６２に関連付け得る。例えば、ACPリソース１６３はセマンティックリソース１６２をその子リソースとして持ち得る。そこでセマンティックリソース１６２へのアクセスはACPリソース１６３に記述されたアクセス制御ポリシーによって制御されるであろう。セマンティックリソース１６２直接その子リソースとして付与するのではなく、ACPリソース１６３は、セマンティックリソース１６２を指し示すリンクを代替的に付与してもよい（例えば、セマンティックリソース１６２のURIをACPリソース１６３の属性として付与する）。
【0073】
図２１は、トリプルにはこれらのサービス層リソース（例えば、セマンティックリソース１６２またはACPリソース１６３）に基づいて生成され、SGS１５０に格納し得るものがあることを図示する。ACPトリプル１６４は、ACPリソース１５６に基づいて生成される。すなわち、ACPトリプル１６４はACPリソース１６３をモデリングするために用いてもよい。セマンティックトリプル１６５は、セマンティックリソース１６２から来ている。さらに、追加トリプル（例えば、セマンティックトリプル１６５）はセマンティックリソース１６２とそれが含む各トリプルとの関係を記述するために生成され得る。ACP－セマンティックトリプル１６６（例えば、ACP－セマンティックバインドトリプル）はACPリソース１６３間またはセマンティックリソース１６２間の関係を記述するために用いられる。ACP－セマンティックトリプル１６６はどのACPリソース１６３がどのセマンティックリソース１６２に適用可能であるか記述し得る。
【0074】
図２２～図３７などに図示されたステップを実行するエンティティは論理エンティティであり得ることを理解されたい。こうしたステップは図３９Ｃまたは図３９Ｄに図示されるような、装置、サーバ、またはコンピュータシステムのメモリに格納され、またそのプロセッサ上で実行し得る。一実施例において、以下でより詳細に論じられるM2Mデバイスのインタラクションに関して図２４および２９のACPイニシエータ１７２またはSDイニシエータ１７３は図３９ＡのM2M端末デバイス１８に常駐してもよく、一方図２４および図２９のホスト側CSE１７１およびSGS１７０は、図３９ＡのM2Mゲートウェイデバイス１４に常駐してもよい。CSE１７１およびSGS１７０はM2Mサーバ上に常駐し得る。
【0075】
図２２および図２３は、本書でより詳細に論じるように、サービス層とSGSとの同期を実現するためにACP関連トリプルおよびセマンティック関連トリプルを管理するための方法を図示する。セマンティック関連トリプルは「セマンティックトリプル（例えば、SDオリジナルトリプル）」、「SD関係トリプル」、「ACP－SDバインドトリプル」を含み得る。「セマンティック関連」トリプルは「セマンティックトリプル」よりも多くなり得る。ACP関係トリプルは「ACPトリプル」および「ACP－SDバインドトリプル」を含み得る。サービス層でホストされるACPリソース上の動作は、SGSにおけるACP関連トリプルの管理をトリガする（例えば、ACP関連トリプルを作成、ACP関連トリプルを更新、またはACP関連トリプルを削除）。対照的に、サービス層でホストされるセマンティックリソース上の動作は、SGSにおけるセマンティック関連トリプルの管理をトリガする（例えば、セマンティック関連トリプルを作成、セマンティック関連トリプルを更新、またはセマンティック関連トリプルを削除）。なお、図２２および図２３のどちらのSGSも別のサービス層または別のサービス層の特殊機能として、実装し得ることに留意されたい。SGSは、その一部または全体としてなど、別のサービス層に常駐し得る。
【0076】
再び図２２は、ACPトリプル（およびACP－セマンティックトリプル）を管理するための一般的手順を図示する。サービス層１８１で、サービス層１６９はACPリソースを動作させる要求を要求側１６８から受信する。要求側１６８はアプリケーションまたは別のサービス層であり得る。第１のシナリオにおいて、サービス層１８１での要求は新しいACPリソースを作成するためであり得る。サービス層１８１の要求は作成対象であるACPリソースのリソース表現を含み得る。第２のシナリオにおいて、サービス層１８１での要求は既存のACPリソースを更新することであり得る。そこでサービス層１８１での要求は更新対象である既存のACPリソースの属性の値または子リソース表現を含み得る。第３のシナリオにおいて、サービス層１８１での要求は、既存のACPリソースを削除することであり得る。そこでサービス層１８１での要求は除去対象である既存のACPリソースの識別子（例えば、名前）またはURIを含み得る。
【0077】
ステップ１８２で、サービス層１６９はサービス層１８１からの要求を処理する。要求がシナリオ１の場合（例えば、前述の第１のシナリオ）、サービス層１６９はサービス層１８１のリソース表現を用いて、要求されたACPリソースを作成する。要求がシナリオ２の場合（例えば、前述の第２のシナリオ）、サービス層１６９はサービス層１８１の属性値または子リソース表現を用いて、要求されたACPリソースを更新する。要求がシナリオ３の場合（例えば、前述の第３のシナリオ）、サービス層１６９はサービス層１８１の識別子またはURIによって識別されるとおり、要求されたACPリソースを更新する。サービス層１８３で、サービス層１６９は、ステップ１８２の実行結果を通知するために要求側１６８に応答を送信し得る。ステップ１８４で、サービス層１６９は、シナリオ（例えば、シナリオ１またはシナリオ２）に依存する新しいACPトリプルを作成し得る。シナリオ１の場合、ステップ１８２で作成された新しいACPリソースをモデル化するために、ACPトリプルが生成される。シナリオ２の場合、ステップ１８２で更新されたACPリソースをモデル化するためにACPトリプルが生成される。
【0078】
引き続き図２２を参照すると、ステップ１８５で、サービス層１８５は、ACPリソースがセマンティックリソース子リソースを持つ場合、またはACPリソースがセマンティックリソースを指し示すまたは参照する属性を持つ場合、第１のシナリオまたは第２のシナリオに対して、新しいACP－セマンティックトリプルを作成し得る。ステップ１８６で、サービス層１６９はSPARQLクエリをSGS１７０に送信し得る。第１のシナリオを参照すると、ステップ１８６のSPARQLクエリを、SGS１７０において、（ステップ１８４からの）新しいACPトリプルを付与する、または（ステップ１８５からの）新しいACPセマンティックトリプルを付与するために使用し得る。第２のシナリオに対して、ステップ１８６のSPARQLクエリを、SGS１７０において、（ステップ１８４からの）ACPトリプルおよび（ステップ１８５からの）ACPセマンティックトリプルを更新するために使用し得る。第３のシナリオに対して、SGS１７０において、ステップ１８６のSPARQLクエリを、（ステップ１８４からの）ACPトリプルを除去する、または（ステップ１８５からの）ACPセマンティックトリプルを除去するために使用し得る。
【0079】
ステップ１８７で、SGS１７０はステップ１８６のSPARQLクエリを処理する。すなわち、SGS１７０は新しいACPトリプルおよび新しいACP－セマンティックトリプルを付与（シナリオ１）、既存のACPトリプルおよびACP－セマンティックトリプルを更新（シナリオ２）、または既存のACPトリプルおよびACP－セマンティックトリプルを削除する（シナリオ３）。ステップ１８８で、SGS１７０はサービス層１６９に応答を送信する。該応答はステップ１８７のSPARQL実行結果を含み得る。
【0080】
図２３は、セマンティックトリプル（およびACP－セマンティックトリプル）を管理するための一般的手順を図示する。ステップ１９１で、サービス層１６９はセマンティックリソースを動作させる要求を要求側１６８から受信する。要求側１６８は、アプリケーションまたは別のサービス層であり得る。第４のシナリオに対して、ステップ１９１での要求は新しいセマンティックリソースを作成することであり得る。ステップ１９１での要求は、作成対象であるセマンティックリソースのリソース表現を含み得る。第５のシナリオに対して、ステップ１９１での要求は既存のセマンティックリソースを更新することであり得る。そこでステップ１９１での要求は更新対象である既存のセマンティックリソースの属性の値または子リソース表現を含み得る。第６のシナリオに対して、ステップ１９１での要求は、既存のセマンティックリソースを削除することであり得る。そこでステップ１９１での要求は、除去対象である既存のセマンティックリソースの識別子（例えば、名前）またはURIを含み得る。
【0081】
ステップ１９２で、サービス層１６９はステップ１９１からの要求を処理する。要求がシナリオ４の場合（例えば、前述の第４のシナリオ）、サービス層１６９はステップ１９１のリソース表現を用いて、要求されたセマンティックリソースを作成する。要求がシナリオ５の場合（例えば、前述の第５のシナリオ）、サービス層１６９はステップ１９１の属性値または子リソース表現を用いて、要求されたＡＣＰリソースを更新する。要求がシナリオ６の場合（例えば、前述の第６のシナリオ）、サービス層１６９は、ステップ１９１のその識別子またはURIによって識別される、要求されたセマンティックリソースを更新する。ステップ１９３で、サービス層１６９は、ステップ１９２の実行結果を通知するために要求側１６８に応答を送信し得る。ステップ１９４で、サービス層１６９は、シナリオ（例えば、シナリオ４またはシナリオ５）に依存する新しいセマンティックトリプルを作成し得る。シナリオ４の場合、ステップ１９２で作成された新しいセマンティックリソースをモデル化するためにセマンティックトリプルを作成し得る。シナリオ５の場合、ステップ１９２の更新されたセマンティックリソースをモデル化するためにセマンティックトリプルを生成し得る。
【0082】
引き続き図２３を参照すると、セマンティックリソースがセマンティックリソース子リソースを持つ場合、またはセマンティックリソースが、セマンティックリソースを指し示すまたは参照する属性を持つ場合、ステップ１９５で、サービス層１９５は、第４のシナリオまたは第５のシナリオに対して新しいACP－セマンティックトリプルを作成し得る。ステップ１９６で、サービス層１６９はSPARQLクエリをSGS１７０に送信し得る。第４のシナリオを参照すると、ステップ１９６のSPARQLクエリを、SGS１７０において、（ステップ１９４からの）新しいセマンティックトリプルを付与する、および（ステップ１９５からの）新しいACP－セマンティックトリプルを付与するために使用し得る。第５のシナリオに対して、ステップ１８６のSPARQLクエリを、SGS１７０において、（ステップ１９４からの）セマンティックトリプルを更新する、および（ステップ１９５からの）ACP－セマンティックトリプルを更新するために使用し得る。第６のシナリオに対して、ステップ１９６のSPARQLクエリを、SGS１７０において、（ステップ１９４からの）セマンティックトリプルを除去する、および（ステップ１９５からの）ACP－セマンティックトリプルを除去するために使用し得る。
【0083】
ステップ１９７で、SGS１７０はステップ１９６のSPARQLクエリを処理する。それに従ってSGS１７０は新しいセマンティックトリプルおよび新しいACP－セマンティックトリプルを付与し（シナリオ４）、既存のACPトリプルおよびACP－セマンティックトリプルを更新（シナリオ５）、または既存のセマンティックトリプルおよびACP－セマンティックトリプルを削除する（シナリオ６）。ステップ１９８で、SGS１７０は応答をサービス層１６９に送信する。該応答は、ステップ１９７のSPARQL実行結果を含み得る。
【0084】
高度なACPオントロジーを以下に説明する。oneM2M TR－0007－Study＿on＿Abstraction＿and＿Semantics＿Enablement－V2.11.0に説明されるように従来のACPオントロジーにおいては、semanticDescriptorレベルのアクセス制御のみをサポートし、そのことは、同じsemanticDescriptorのすべてのSDオリジナルトリプルは同じアクセス制御ポリシーを持つことを意味する。なぜならば、それは、acp:appliedToプロパティを介して、acp:accessControlPolicyクラスインスタンスを＜semanticDescriptor＞リソースインスタンスに対してのみ、バインドするからである。
【0085】
新しいプロパティacp:appliedToTripleがacp:accessControlPolicyクラスについて公開される。以下を参照してこの新しいプロパティacp:appliedToTripleをコンテキストに入れることができよう。
【表11】
【0086】
該sd:sdOriginalTripleは単一のSDオリジナルトリプルを定義するためのオントロジークラスである。該acp:accessControlPolicyは、oneM2M＜accessControlPolicy＞リソースをモデル化するためのオントロジークラスである。この新しいプロパティ（例えば、acp:appliedToTriple）によって、＜semanticDescriptor＞の各SDオリジナルトリプルは、個別にacp:accessControlPolicyクラスインスタンスにバインドされ得る。この特性によって、異なる＜semanticDescriptor＞リソースからのセマンティックトリプルを扱うセマンティッククエリに対し、SGSにおけるアクセス制御の実施が可能になる。換言すると、この新しいプロパティによって、異なるACPを＜semanticDescriptor＞における異なるトリプル（例えば、トリプルレベルACP）に適用し得るような、より精密な細分性を達成することができる。また、従来、サービス層はSD（第１のトリプルおよび第２のトリプルを含んでよい）に適用し得るが、本書に記載されるように、現在サービス層はより精密な細分性でACPをトリプルに適用し得る。
【0087】
以下はACPトリプルを管理することに関する考慮である。図２４はホスト側CSEで＜accessControlPolicy＞リソースを作成することをACPイニシエータが要求する場合、SGSにおいてACPトリプルを作成するための方法を図示する。ステップ２０１で、ACPイニシエータ１７２は、「Create＜accessControlPolicy＞Resource」要求をホスト側CSE１７１に送信する。このメッセージは、作成対象である＜accessControlPolicy＞の表現（例えば、privileges属性の値）を含む。ステップ２０２で、ホスト側CSE１７１はステップ２０１での要求を受信し、ACPイニシエータがリソースを作成するためのアクセス権を確認する。アクセス権が許可されている場合、それに従いホスト側CSE１７１は要求された＜accessControlPolicy＞リソースを作成する（＜acp1＞と呼ばれる）。
【0088】
ステップ２０２に関連付けられた仮定は、以下を含む。作成された＜accessControlPolicy＞のURIは「acp1URI」とする。さらに、＜acp1＞のprivileges属性は１つのアクセス制御ルール（acr11と呼ぶ）しか持たないとし、privileges属性は複数のアクセス制御ルールを含み得るがprivileges属性にアクセスするURIは「acr11URI」であるとする。図２５は、＜acp1＞リソースのACPトリプルの一例を図示する。この例では、acr11によってAE（そのIDは「AE－ID－1」）がDISCOVERY動作を実行できるとする。ステップ２０３で、ホスト側CSE１７１は、ステップ２０１における要求が正常に実行されているかを通知するために、ACPイニシエータに応答を送信する。正常である場合、「acp1URI」がステップ２０３の応答に含まれるであろう。
【0089】
ステップ２０４で、ステップ２０２で作成された＜acp1＞リソースおよびACPオントロジーに基づいて、ホスト側CSE１７１は対応するACPトリプルを生成する。ステップ２０４で生成されたACPトリプルは、＜accessControlPolicy＞のprivileges属性に含まれているように各ACPルールを十分に記述でき、また各ACPルールと＜accessControlPolicy＞リソースとの関連付けを記述できることとする。ステップ２０１で作成された＜acp1＞リソースについてのACPトリプルの一例を図２５に示す。図２５では、line#1のトリプルは、一例として単純にプレフィクス「acp」を定義する。プレフィクス「acp」はline#2からline#6までで使用される。図２５では、line#2のトリプルは、ステップ２で作成された＜acp1＞リソースについて新しいacp:accessControlPolicyクラスインスタンスを定義する。このトリプルの主語の値（すなわちacp:acp1）は、ステップ２の仮定に基づいて「acp1URI」である。換言すると、このトリプルの主語の値に基づくと、対応する＜acp1＞リソースをロケートすることが可能である。さらに、ホスト側CSE１７１は“acp1URI”を用いてSGS１７０において対応するトリプルをロケートすることができる。このことは、ホスト側CSE１７１が既存のACPトリプルを更新する必要がある場合、必要である。基本的に、acp1に関連したACPトリプルはSGSに格納され、acp1のURI（例えば、acp1URI）に関連付けられる。結果として、ホスト側CSE１７１がacp1のURI（例えば、acp1URI）を知っている場合、このURIに対応するすべてのACPトリプルを見つけるためこれを使用し得る。したがって該URIの検索があり得る。
【0090】
図２５で、line#3のトリプルは、acp:acp1インスタンスが関連付けられたアクセス制御ルールacr11を持つことを定義する。このトリプルの目的語の値（すなわちacp:acr11）は、ステップ２０２の仮定に基づいて「acr11URI」である。換言すると、このトリプルの目的語の値に基づいて、＜acp1＞リソースの対応するprivileges属性をロケートすることが可能である。さらに、ホスト側CSE１７１は、SGS１７０において対応するトリプルをロケートするために「acr11URI」を用いることができる。このことは、ホスト側CSE１７１が既存のACPを更新する必要がある場合、必要である。図２５で、line#4のトリプルは、acp:acr11（すなわちline#3の目的語）がacp:accessControlRuleクラスインスタンスであることを定義する。図２５で、line#5およびline#6のトリプルは、ステップ２０２における仮定に基づいて、acp:acr11の２つのプロパティの値を与える。基本的に、line#4から#6までのトリプルは、アクセス制御ルールacr11を定義する。＜acp1＞がより多くのアクセス制御ルールを持つ場合、追加アクセス制御ルールは同様にline#4から#6まで、のように定義される。
【0091】
引き続き図２４を参照すると、ステップ２０５で、ホスト側CSE１７１はSGS１７０のアドレスを、新しい属性においてステップ２０２で作成された＜accessControlPolicy＞リソース（例えば、＜acp1＞）に追加し得る。ステップ２０６で、ホスト側CSE１７１は、ステップ２０４４で作成されたACPトリプルを格納するためのSPARQL要求を、選択されたSGS１７０に送信する。図２５に示すACPトリプルは、一例のように、SPARQL要求に含まれ得る。ステップ２０７で、SGS１７０はSPARQL要求を受信し、処理し、ACPトリプルをそのグラフストアに保存する。ステップ２０８で、SGS１７０は、ステップ２０６での要求が正常に実行されているかを確認するためにホスト側CSE１７１に応答を返送する。
【0092】
oneM2Mにおいて、アクセス制御ルールは、＜accessControlPolicy＞リソースの単一の属性privilegesに記述されることを理解されたい。換言すると、これらのアクセス制御ルールは、同じURI（例えば、「…／＜accessControlPolicy＞／privileges」）を用いてアクセスされ得る。ただし、ACPオントロジーにおいて、各アクセス制御ルールは、異なるURIを持つ異なるインスタンスとしてモデル化される。この問題に取り組む１つの方法は、SGS１７０で用いられるであろう、各アクセス制御ルールインスタンスの新しいURIとして、privileges属性のURIに連番（などの差別化要素）を追加することである。例えば、＜accessControlPolicy＞のprivilegesにアクセスするためのURIはprivilegesURIであり、該privilegesは３つのアクセス制御ルールを定義すると仮定する。すると、SGS１７０においてACPトリプルで用いられる各アクセス制御ルールのURIは、それぞれprivilegesURI／1、privilegesURI／2、privilegesURI／3になり得る。
【0093】
図２６は、SGS１７０においてACPトリプルを更新する方法を図示し、これは、既存の＜accessControlPolicy＞リソースのprivileges属性を更新するためのACPイニシエータ１７２または直接ホスト側CSE１７１によってトリガされ得る。この例では、ACPイニシエータ１７２は、図２４の方法に従って作成された＜acp1＞リソースのprivileges属性を更新することを要求する。ステップ２１１で、ACPイニシエータ１７２は「＜accessControlPolicy＞リソースを更新」をホスト側CSE１７１に送信する。ここで、ACPイニシエータ１７２は、＜acp1＞リソースのprivileges属性を新しいaccessControlOperationsとして「DISCOVERY」および「RETRIEVE」で更新しようとする。なお、図２４および図２５に関連付けられたprivileges属性のaccessControlOperationsは、ただ「DISCOVERY」のみと考えられ得ることに留意されたい。ステップ２１２で、ホスト側CSE１７１は＜acp1＞リソースを更新するためにステップ２１１で与えられた新しいprivileges属性値を用いる。ステップ２１３で、ホスト側CSE１７１は、ステップ２１１において要求された更新が正常に実行されているかを通知するために、ACPイニシエータ１７２に応答を送信する。
【0094】
ステップ２１４で、ステップ２１１で与えられた＜acp1＞リソースのprivileges属性の新しい値に基づき、ホスト側CSE１７１は＜acp1＞リソースのprivileges属性にこの変更を反映するための新しいACPトリプルを生成する。例えば、ホスト側CSE１７１は新しいトリプル「acp:acr11 acp:hasACOperations 「RETRIEVE」」を単純に追加し得る。あるいは、ホスト側CSE１７１は図２５のLine#6 のトリプルを新しいトリプル「acp:acr11 acp:hasACOperations 「DISCOVERY」、「RETRIEVE」」に置換し得る。ステップ２１５で、ホスト側CSE１７１は、ステップ２１１で要求されている変更を反映するために＜acp1＞リソースに関連した既存のACPトリプルを更新するためにSPARQL要求をSGS１７０に送信する。ステップ２１４に記述されるように、これを実施する複数のオプションがある。以下に示すように、第１のオプションとして、ホスト側CSE１７１は単純に新しいトリプルを追加する。SPARQLは以下のようであってもよい。
第２のオプションでは、ホスト側CSE１７１は図２５のLine#6を置換することを決定する。そのSPARQLは以下のようであってもよい。
【表12】
【表13】
【0095】
ステップ２１６で、SGS１７０は、ステップ２１５の受信されたSPARQL要求を処理し、対応するACPトリプルを更新する。ステップ２１７で、SGS１７０は、ステップ２１５における要求が正常に実行されているかを通知するために、ホスト側CSE１７１に応答を送信する。
【0096】
図２７は、SGS１７０においてACPトリプルおよびACP－SDバインドトリプルを削除する手順を図示し、これは、既存の＜accessControlPolicy＞リソースを削除するためのACPイニシエータ１７２または直接ホスト側CSE１７１によってトリガされ得る。この例では、ACPイニシエータ１７２は、図２４の方法に従って作成された＜acp1＞リソースを削除することを要求する。ステップ２２１で、ACPイニシエータ１７２は＜acp1＞リソースを削除するために「＜accessControlPolicy＞リソースを削除」をホスト側CSE１７１に送信する。ステップ２２２で、ホスト側CSE１７１は、＜acp1＞リソースを更新するためステップ２２１で与えられた新しいprivileges属性を用いる。ステップ２２３で、ホスト側CSE１７１は、ステップ２２１における要求された削除は正常に実行されているかを通知するために、ACPイニシエータ１７２に応答を送信する。ステップ２２４で、ホスト側CSE１７１は、＜acp1＞リソースに関連した既存のACPトリプルおよびACP－SDバインドトリプルを削除するために、SPARQL要求をSGS１７０に送信する。このSPARQLは以下のようであってもよい。
【表14】
【0097】
ステップ２２５で、SGS１７０は、ステップ２２４の受信されたSPARQL要求を処理し、要求されたACPトリプルおよびACP－SDバインドトリプルを除去する。ステップ２２６で、SGS１７０は、ステップ２２４での要求が正常に実行されているかを通知するために、ホスト側CSE１７１に応答を送信する。
【0098】
ACPトリプルの管理のパフォーマンスを向上し得る、追加の方法、システム、装置を以下に示す。これまで図２４から図２７までを参照し、＜accessControlPolicy＞リソースが作成、更新、削除されるとACPトリプルがどのように作成、更新、削除されるかを説明した。このような＜accessControlPolicy＞リソースに対する動作が頻繁である場合、対応するACPトリプルの管理（例えば、作成、更新、削除）は、SGS１７０に対し高いオーバーヘッドを発生する。しかも、＜semanticDescriptor＞のaccessControlPolicyIDs属性を介して＜accessControlPolicy＞リソースに関連付けられる＜semanticDescriptor＞リソースが存在しない場合、これは不必要であり得る。公開された属性（例えば、syncFlag、syncTime、sdList）および、とりわけ本書で詳細に説明されている、該属性を更新する方法は、頻繁で不必要な、ACPトリプルの管理を減少することに役立ち得る。
【0099】
syncFlagは、＜accessControlPolicy＞の対応するACPトリプルはSGS１７０に格納され同期している（例えば、syncFlag＝1）か（例えば、syncFlag＝0）否かを示す。syncTimeは、この＜accessControlPolicy＞のACPトリプルが最後にSGS１７０に同期した時刻を示す。sdListは、次の条件を満たし得る＜semanticDescriptor＞リソースのリストを示す。１）それらのaccessControlPolicyIDsの属性がこの＜accessControlPolicy＞リソースを指し示す。または２）それらの対応するSDオリジナルトリプルまたはSD関係トリプルがSGS１７０に格納されている。
【0100】
ホスト側CSE１７１は、各＜accessControlPolicy＞リソースごとにこれらの３つの属性の値を動的に更新する。＜accessControlPolicy＞リソースのsyncFlag属性のデフォルト値は０である（すなわちFALSE）。この＜accessControlPolicy＞リソースのACPトリプルがSGS１７０に格納されSGS１７０に同期している場合、syncFlag属性の値は、１（すなわちTRUE）に変更し得る。＜accessControlPolicy＞が更新されるたびに、ホスト側CSE１７１はまずsyncFlagを０（すなわちFALSE）に変更する。その新しいACPトリプルがSGS１７０に格納されSGS１７０に再び同期された後、syncFlagは再び１（すなわちTRUE）に変更され得る。
【0101】
＜accessControlPolicy＞リソースのsyncTime属性のデフォルト値はゼロである。＜accessControlPolicy＞リソースのACPトリプルがSGS１７０に同期された後（例えば、時刻t1で）この＜accessControlPolicy＞リソースのsyncTime属性はt1に設定され得る。
【0102】
ここで、＜semanticDescriptor＞リソースのSDオリジナルトリプルまたはSD関係トリプルは、SGS１７０に格納されている。この＜semanticDescriptor＞リソースのaccessControlPolicyIDsが設定される（またはその親リソースのaccessControlPolicyIDsまたは任意のシステムデフォルト＜accessControlPolicy＞を使用する）たび、この＜semanticDescriptor＞リソースは、対応する＜accessControlPolicy＞リソースのsdList属性に、accessControlPolicyIDs（または親リソースのaccessControlPolicyIDs）に示されるとおりに、追加され得る。この＜semanticDescriptor＞リソースのaccessControlPolicyIDsが除去または変更され空になるたび、この＜semanticDescriptor＞リソースは、該accessControlPolicyIDsに示されるとおりに、対応する＜accessControlPolicy＞リソースのsdList属性から除去され得る。この＜semanticDescriptor＞リソースのaccessControlPolicyIDsが更新される場合、この＜semanticDescriptor＞リソースは、古い＜accessControlPolicy＞リソースのsdList属性のリストから除去され、新しく作成される場合、＜accessControlPolicy＞リソースのsdList属性に追加され得る。
【0103】
以下に、syncFlag、syncTime、またはsdList属性に基づいてACPトリプルを動的に管理するホスト側CSE１７１を詳細に説明する。＜accessControlPolicy＞が初めて作成される場合、ホスト側CSE１７１は対応するACPトリプルを作成または、SGS１７０に格納し得ない。そのようにする場合は、ホスト側CSE１７１は単純にそのsyncFlag＝0、syncTime＝0、sdList＝emptyを設定する。＜accessControlPolicy＞が時刻t2で更新される場合、ホスト側CSE１７１は、以下の動作を実行し得る。１）sdListが空の場合、何もせずsyncFlag＝0を設定する。または２）sdListが空ではなく、かつsyncTimeがゼロより大きいがt2に満たない場合、ホスト側CSE１７１はSGS１７０においてACPトリプルを更新するために図２６に関連付けられた方法を使用し得る。その後syncFlag＝1およびsyncTime＝t2を設定する。＜accessControlPolicy＞リソースのsdList属性が「空」から「空でない」に変わる場合、ホスト側CSE１７１は、以下の動作を実行し得る。１）syncFlag＝1の場合、何もしない。または、２）syncFlag＝0の場合、ホスト側CSE１７１は、この＜accessControlPolicy＞リソースのACPトリプルを作成し、それらをSGS１７０に格納するため、図２４または図２５に関連付けられた方法を使用し得る。ここで、ホスト側CSE１７１はこの動作を時刻t3、その後syncFlag＝1およびsyncTime＝t3で完了する。
【0104】
＜accessControlPolicy＞リソースのSyncFlag属性およびsyncTime属性は、この＜accessControlPolicy＞リソースをホストするホスト側CSE１７８によって更新される。しかし、この＜accessControlPolicy＞のsdList属性は、以下のような異なるケースで更新され得る。第１のケースでは、＜accessControlPolicy＞リソースを用いる＜semanticDescriptor＞リソースがこのホスト側CSE１７８にも格納される場合、該ホスト側CSE１７８はsdListを更新することに責任がある。第２のケースでは、この＜accessControlPolicy＞リソースを用いる＜semanticDescriptor＞リソースがホスト側CSE－Bに格納される場合、該ホスト側CSE―Bは、この＜accessControlPolicy＞リソースのsdList属性を更新するためにホスト側CSE１７８に要求を送信する（図２８）。
【0105】
図２８は、前述の第２のケースのコンテキストにおいて、＜accessControlPolicy＞リソースのsdList属性を更新するための例示的方法を図示する。この例では、以下が与えられる。１）CSE１７９は＜semanticDescriptor＞リソース（＜sd1＞と呼ばれる）をホストする。２）CSE１７８は、＜accessControlPolicy＞リソース（＜acp1＞と呼ばれる）をホストする。３）CSE１７７は＜accessControlPolicy＞リソース（＜acp2＞と呼ばれる）をホストする。ステップ２３１で、時刻t4で、＜sd1＞リソースが作成されそのaccessControlPolicyIDs属性が＜acp1＞リソースに設定される。ステップ２３２で、CSE１７９は＜acp1＞リソースのsdList属性を更新するためにCSE１７８に要求を送信する。ステップ２３３で、それに従いCSE１７８は、＜acp1＞リソースのsdList属性を更新し、CSE１７９に応答を返送する。該応答は、CSE１７９に、要求２３２が受信および処理されたこと、および処理の結果（例えば、成功または不成功など）を通知する。ステップ２３４で、時刻t5で、＜sd1＞のaccessControlPolicyIDs属性は＜acp1＞から＜acp2＞に変更される。それに従い＜sd1＞は＜acp1＞のsdListから除去され（ステップ２３５）、＜acp2＞のsdList（ステップ２３７）に追加される。ステップ２３５で、CSE１７９は、＜acp1＞のsdList属性から＜sd1＞を除去するためにCSE１７８に要求を送信する。ステップ２３６で、CSE１７８は、＜sd1＞を＜acp1＞のsdList属性から除去し、CSE１７９に応答を送信する。該応答は、該要求が受信および処理されたこと、および処理の結果（例えば、成功または不成功など）を通知する。ステップ２３７で、CSE１７９は、＜acp2＞のsdList属性に＜sd1＞を追加するためにCSE１７７に要求を送信する。ステップ２３８で、CSE１７７は、＜sd1＞を＜acp2＞のsdList属性に追加し、CSE１７９に応答を送信する。該応答は、該要求が受信および処理されたこと、および処理の結果（例えば、成功または不成功など）を通知する。
【0106】
以下は＜semanticDescriptor＞リソースに関連した（例えば、作成、更新、削除）トリプルを管理することに関する考慮である。図２９は、SGSにおいて、ACP－SDバインドトリプルおよびSD関係トリプルを作成することに関連付けられた例示的方法を図示する。図３０は、SD関係トリプルを図示する。図２９において、SDイニシエータ１７３（例えば、oneM2M AEまたはCSE）は、ホスト側CSE１７１で新しい＜semanticDescriptor＞リソースを作成することを要求する。アクセス権および他の関連セキュリティ機能を確認後、ホスト側CSE１７１は、＜semanticDescriptor＞リソースをローカルに作成する（SD1および、ここではsd1URIとして識別されるそのURIと呼ばれる）。その後、ホスト側CSE１７１は、SD1リソースの記述子属性に記述されるようにセマンティックトリプルをSGS１７０に格納する。なお、ホスト側CSE１７１は、SD関係トリプルおよびACP－SDバインドトリプルを生成し、それらもSGS１７０に格納することに留意されたい。なお、SD1がaccessControlPolicyIDs属性を持たない場合、ACP－SDバインドトリプルは生成され得ないことに留意されたい。これをふまえ、図２９を参照すると、ステップ２４１で、SDイニシエータ１７３は、「＜semanticDescriptor＞リソースを作成」する要求をホスト側CSE１７１に送信する。ここで、＜semanticDescriptor＞リソースの記述子属性およびaccessControlPolicyIDs属性の値は、要求メッセージの中で与えられる。この例では、記述子属性は、１つのSDオリジナルトリプル「S1 P1 O1」のみを含む。ここで、S1は、このトリプルの主語、P1はこのトリプルの述語、O1はこのトリプルの目的である。さらに、accessControlPolicyIDsの値は、「acp1URI」（ここでは図２４および図２５に関連付けられる）である。換言すると、アクセス制御ポリシーacp1は、この＜semanticDescriptor＞リソースへのアクセスを制御するために適用される。
【0107】
引き続き図２９を参照すると、ステップ２４２で、ホスト側CSE１７１はそれに従って＜semanticDescriptor＞リソース（sd1と呼ばれる）を作成する。sd1のURIは、sd1URIである。ステップ２４３で、ホスト側CSE１７１はSDイニシエータ１７３に、ステップ２４１で要求された＜semanticDescriptor＞リソースが正常に作成されたかを通知するための応答を送信する。ステップ２４４で、sd1の記述子属性に含まれるSDオリジナルトリプルに従って、ホスト側CSE１７１はSD関係トリプルを生成する。ステップ２４１に従って、１つのSDオリジナルトリプルのみが存在する。したがって、図３０に示されるSD関係トリプルが生成される。ステップ２４５で、sd1のaccessControlPolicyIDs属性がacp1リソースを指し示すため、ホスト側CSE１７１は図３１に示すとおり、ACP－SDバインドトリプルを生成する。図３１のLine#5は、SGS１７０のアクセス制御ポリシー「acp:acp1」は、SGS１７０におけるセマンティック記述子「sd:sd1」に適用されることを示す。ステップ２４５で、ホスト側CSE１７１はSGS１７０ に、これらのSD関係トリプルおよびACP－SDバインドトリプルをSGS１７０に格納するためにSPARQL要求を送信する。ステップ２４７で、SGS１７０は、SPARQL要求を処理し、対応するSD関係トリプルおよびACP－SDバインドトリプルをSGS１７０に格納する。ステップ２４８で、SGS１７０は、ステップ２４６のSPARQL要求が正常に実行されているかを通知するための応答メッセージをホスト側CSE１７１に送信する。図２９のコンテキストにおいて、ステップ２４２で作成される＜semanticDescriptor＞リソースsd1が、設定されるaccessControlPolicyIDs属性を持たない、またはそのaccessControlPolicyIDs属性は有効＜accessControlPolicy＞リソースに対応しないことが、可能である。この場合、sd1の親リソースのaccessControlPolicyIDs属性が用いられると、新しいACP－SDバインドトリプルも、その親リソースのaccessControlPolicyIDs属性を用いて生成される。システムのデフォルトアクセスprivilegesが適用される場合、新しいACP－SDバインドトリプルはこのデフォルトprivilegesに基づいて生成される。
【0108】
図３２は、＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性が変更される場合、ACP－SDバインドトリプルを更新することに関連付けられる例示的方法を図示する。この例では、図２９に関連して作成されたsd1リソースのaccessControlPolicyIDsは、acp1から別の＜accessControlPolicy＞リソース（acp2と呼ばれる）に変更される。この例では、リソースacp2のACPトリプルは以下のように作成される。
【表15】
【0109】
図３２を参照すると、ステップ２５１で、SDイニシエータ１７３は、リソースsd1のaccessControlPolicyIDsを、リソースacp1のURIからリソースacp2のURIに更新する要求を送信する。リソースacp2のURI（例えば、acp2URI）は、この要求に含まれる。リソースsd1のURI（すなわちsd1URI）も、ステップ２５１での要求に含まれる。ステップ２５２で、ホスト側CSE１７１はアクセス権を確認する。アクセス権が許可されている場合、ホスト側CSE１７１は、sd1のaccessControlPolicyIDsを、ステップ２５１で与えられたacp2のURIで更新する。ステップ２５３で、ホスト側CSE１７１は、SDイニシエータ１７３に、ステップ２５１での要求が正常に実行されているかを通知する応答を返送する。ステップ２５４で、sd1のaccessControlPolicyIDsが変更されるため、ホスト側CSE１７１はこの変更を反映するための新しいACP－SDバインドトリプル（「acp:acp2 acp:appliedTo sd:sd1」）を生成する。この新しいACP－SDバインドトリプルは、古いACP－SDバインドトリプルを置換する（例えば、「acp:acp1 acp:appliedTo sd:sd1」）
・（新しいACP－SDバインドトリプル） acp:acp2 acp:appliedTo sd:sd1
・（古いACP－SDバインドトリプル）acp:acp1 acp:appliedTo sd:sd1
・（新しいACP－SDバインドトリプル） acp:acp2 acp:appliedTo sd:sd1
・（古いACP－SDバインドトリプル）acp:acp1 acp:appliedTo sd:sd1
【0110】
ステップ２５５で、ホスト側CSE１７１は、SGS１７０における古いACP－SDバインドトリプルを、前述のステップ２５４に示すように新しいACP－SDバインドトリプルに置換するためにSPARQL要求を送信する。このSPARQL要求は以下のようになり得る。
【表16】
【0111】
ステップ２５６で、SGS１７０はSPARQL要求を処理し、ステップ５において指定されたACP－SDバインドトリプルを更新する。ステップ２５７で、SGS１７０は、ホスト側CSE１７１に、ステップ２５５でのSPARQL要求が正常に実行されているかを通知する応答を送信する。図３２を参照し、＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性が空で開始した場合、その親リソースのaccessControlPolicyIDsは実行されることを理解されたい。ホスト側CSEは、それを追跡し更新に基づいてこのステップを親リソースのaccessControlPolicyIDs属性に適用する。
【0112】
図３３は、＜semanticDescriptor＞リソースの記述子属性が変更される場合、SD関係トリプルを更新することに関連付けられた例示的方法を図示する。この例では、図２９に関連付けられて作成されたsd1リソースの記述子が、２つのSDオリジナルトリプル（古い方が「S1 P1 O1」、新しい方が「S2 P2 O2」）を持つように変更される。なお、記述子属性のトリプルの更新は、SPARQLクエリを備えた＜semanticDescriptor＞親リソースのsemanticOpExec属性をターゲットにすることによっても実行し得る。このSPARQLクエリが実行される場合、新しいSDオリジナルトリプルは＜semanticDescriptor＞リソースのdescriptor属性に追加され得る。したがって、図３３のステップ２６４から２６７が実行される。より具体的には、SPARQL更新は、DELETEまたはADD動作を含み得るため、古いオリジナルトリプルに関連付けられたSD関係トリプルは削除され、新しいオリジナルトリプルに関連付けるための新しい関係トリプルが作成される。
【0113】
図３３を参照すると、ステップ２６１で、SDイニシエータ１７３は１つの新しいSDオリジナルトリプル（すなわち「S2 P2 O2」）を含むためにリソースsd1の記述子を更新する要求を送信する。リソースsd1のURI（例えば、sd1URI）もこの要求に含み得る。ステップ２６２で、ホスト側CSE１７１は、アクセス権を確認する。アクセス権が許可されている場合、ホスト側CSE１７１は、sd1の記述子属性を、１つの新しいSDオリジナルトリプル（すなわち［S2 P2 O2］）を付与することによって、更新する。ステップ２６３で、ホスト側CSE１７１は、SDイニシエータ１７３に、Step 1での要求が正常に実行されているかを通知する応答を返送する。ステップ２６４で、sd1の記述子属性は変更されるので、ホスト側CSE１７１はこの変更を反映するために以下の新しいSD関係トリプルを生成する。
【表17】
【0114】
ステップ２６５で、ホスト側CSE１７１は、SGS１７０において、古いSD関係トリプルを置換する、または新しいSD関係トリプルを追加するためのSPARQL要求を、ステップ２６４で生成された新しいSD関係トリプルとともに送信する。このSPARQL要求は以下のようになり得、ホスト側CSE１７１は単純に新しいトリプルを追加する。
【表18】
【0115】
ステップ２６６で、SGS１７０はSPARQL要求を処理し、ステップ２６５に含まれた新しいSD関係トリプルを追加する。ステップ２６７で、SGS１７０は、ホスト側CSE１７１に、ステップ２６５でのSPARQL要求が正常に実行されているかを通知するための、応答を送信する。なお、古いSDオリジナルトリプルが除去される、または新しいSDオリジナルトリプルによって更新される場合、この古いSDオリジナルトリプルに関連した対応するSD関係トリプルは、SGS１７０から除去されるであろう。
【0116】
図３４は、SD関係トリプルおよびACP－SDバインドトリプルをSGS１７０から削除する例示的方法を図示し、＜semanticDescriptor＞リソースを削除するためにAE／CSEまたはホスト側CSE１７１をイニシエートすることによってトリガされ得る。この例では、図２９に関連付けられて作成されたsd1リソースが除去される。なお、＜semanticDescriptor＞リソースのsemanticOpExec属性は、SPARQLクエリを含む。このSPARQLクエリが実行されると、既存のSDオリジナルトリプルは、＜semanticDescriptor＞リソースの記述子属性から削除されてもよく、したがって、図３４のステップ２７４から２７６までが実行されるであろう。
【0117】
ステップ２７１で、SDイニシエータ１７３は、すべてのリソースを削除するため「＜semanticDescriptor＞リソースを削除」をホスト側CSE１７１に送信する。sd1リソースのURI（例えば、sd1URI）は、この要求に含まれる。ステップ２７２で、ホスト側CSE１７１は、sd1リソースをローカルに削除する。ステップ２７３で、ホスト側CSE１７１は、SDイニシエータ１７３に、ステップ２７１での削除要求は正常に実行されているか通知するため応答を送信する。ステップ２７４で、ホスト側CSE１７１は、SGS１７０に、sd1に関連したSD関係トリプルおよびACP－SDバインドトリプルを除去するためにSPARQL要求を送信する。SPARQLは以下のようになり得る。
【表19】
【0118】
ステップ２７５で、SGS１７０はステップ２７４でのSPARQL用求を処理し、対応するSD関係トリプルおよびACP－SDバインドトリプルを除去する。ステップ２７６で、SGS１７０は、ホスト側CSE１７１に、ステップ２７４でのSPARQL要求が正常に実行されているか通知するための応答を送信する。
【0119】
図３５は、ACP関連およびSD関係トリプルのプロキシベースの管理の例示的方法を図示する。ホスト側CSE１７１はSPARQLインタフェースをサポートできない場合があり、これによりSGS１７０との直接のインタラクションを実施することが困難になる。その代わり、このホスト側CSE１７１は、ACP関連トリプルおよびそれに代わってSD関連トリプルを管理するためにSGS１７０と直接インタラクションし得る、他の複数のホスト側CSE１７１をレバレッジし得る。図３５は、以下のような場合の例を図示する。１）ホスト側CSE１７１がSPARQLインタフェースをサポートとし、SGS１７０との直接インタラクションがある。２）ホスト側CSE１７４はSPARQLインタフェースをサポートせず、SGS１７０に直接トークすることができない。３）ホスト側CSE１７４は、ホスト側CSE１７４でホストされた＜accessControlPolicy＞または＜semanticDescriptor＞リソースに関連したACP関連およびSD関連トリプルを管理するためにプロキシとしてホスト側CSE１７１をレバレッジする。
【0120】
図３５を参照すると、ステップ２８１で、ホスト側CSE１７１は、ホスト側CSE１７４に「ACP／SDサブスクリプション要求」を送信する。このメッセージは、ホスト側CSE１７４に、ホスト側CSE１７４でホストされた＜accessControlPolicy＞または＜semanticDescriptor＞メッセージに変更がある場合、自動通知がホスト側CSE１７１に送信されることを通知し得る。ステップ２８２で、＜accessControlPolicy＞または＜semanticDescriptor＞リソースに変更が発生する。ステップ２８３で、ホスト側CSE１７４は、「ACP／SD通知」をホスト側CSE１７１に送信する。このメッセージは＜accessControlPolicy＞または＜semanticDescriptor＞リソースへの変更を含む。例えば、それは、新しい＜accessControlPolicy＞の表現、＜accessControlPolicy＞のprivileges属性の新しい値、新しい＜semanticDescriptor＞の表現、または＜semanticDescriptor＞の記述子属性の新しい値にし得る。ステップ２８４で、ホスト側CSE１７１は、ステップ２８３でどの変更が受信されるかに依存して、いくつかの新しいトリプルを生成する（例えば、新しいACPトリプル、新しいACP－SDバインドトリプル、新しいSD関係トリプル、または新しいSDオリジナルトリプル）。ここでは詳細をACPトリプルの管理およびSD関連トリプルの管理に関して説明してきた。
【0121】
引き続き図３５を参照すると、ステップ２８５で、ホスト側CSE１７１は、これらの新しいトリプルをステップ２８４からSGS１７０に付与する、またはそれらをSGS１７０における対応する古いトリプルと置換するために使用するための、SPARQLメッセージを生成する。ここでは詳細をACPトリプルの管理およびSD関連トリプルの管理に関して説明してきた。ステップ２８６で、ホスト側CSE１７１は、SPARQLメッセージをステップ２８５からSGS１７０に送信する。ステップ２８７で、SGS１７０は受信されたSPARQLメッセージを処理する。ステップ２８８で、SGS１７０は、ホスト側CSE１７１に応答を送信する。応答は、ホスト側CSE１７１に、ステップ２８６のSPARQL要求が正常に実行されているかを通知する。
【0122】
図３６は、アクセス制御によるSGSに対するセマンティッククエリを実行するための例示的方法を図示する。ステップ２９１で、クエリイニシエータ１７５（例えば、oneM２M AEまたはCSE）は、SPARQL要求または、SPARQL要求を含むRESTful検索動作をホスト側CSE１７１に送信する。この例では、以下が考慮される。１）ステップ２９１の要求は「DISCOVERY」動作のためである。２）クエリイニシエータ１７５は、oneM2M AEであり、その識別子は「AE－ID－1」である。クエリイニシエータ１７５の識別子は、ステップ２９１のこの要求メッセージに含まれる。ステップ２９１の要求は、この要求が以下であるかを示す、新しいパラメータsparqlTypeを含み得る。１）＜semanticDescriptor＞リソースに含まれるトリプルまたは情報を直接発見する（例えば、sparqlType＝1）または２）＜semanticDescriptor＞子リソースがSPARQL要求のクエリパターンに一致するリソースを間接的に発見する（例えば、sparqlType＝2）。
【0123】
引き続き図３６を参照すると、ステップ２９１で、ホスト側CSE１７１はSPARQLクエリメッセージを、ステップ２９１で受信された要求から抽出する。ステップ２９３で、ホスト側CSE１７１は、ステップ２９１で含まれたクエリイニシエータ１７５の識別子に基づいて以下のACPクエリパターンを生成する。
【表20】
【0124】
ステップ２９４で、ホスト側CSE１７１はACPクエリパターンを、ステップ２９２で抽出されたSPARQLメッセージに付与する。ステップ２９１での要求がRESTful動作の場合、ホスト側CSE１７１は、一般的にRESTful動作メッセージをステップ２９１から標準SPARQLメッセージに変換する。ここでステップ２９３およびステップ２９４が実施されない場合、どのSPARQLクエリがどのイニシエータからのものかSGSは知り得ないことが理解されよう。ステップ２９３および２９４がスキップされた場合、オリジナルSPARQL要求はステップ２９５に送信され、従ってSGS１７０はこのクエリがどのイニシエータからのものかわからず、適切なアクセス制御ポリシーを実施し得ない。
【0125】
ステップ２９５で、ホスト側CSE１７１は、新しいSPARQLメッセージをSGS１７０に送信する。ステップ２９６で、SGS１７０は、受信されたSPARQLメッセージを処理し実行する。ステップ２９７で、SGS１７０はクエリ結果とともに応答をホスト側CSE１７１に送信する。ステップ２９１のsparqlTypeが、ステップ２９１の要求はリソースを発見することであると示す場合、クエリ結果は＜semanticDescriptor＞リソースのリストを含む。そうでない場合、クエリ結果は、ステップ２９１に含まれるSPARQLメッセージのSELECT結果の節に示されるように選択された変数の値を含む。
【0126】
ステップ２９８で、ステップ１のsparqlTypeがステップ２９１のSPARQL要求は間接的にリソース（例えば、sparqlType＝2）を発見することであると示す場合、ステップ２９７の「クエリ結果」は＜semanticDescriptor＞リソースのURIのリストである。その後このステップ２９８は、ホスト側CSE１７１がこれらの＜semanticDescriptor＞リソースの親リソースをロケートするために必要であり得る。これらの親リソースのURIは、ステップ２９９の応答に含まれ得る。このステップ２９８において、ホスト側CSE１７１はステップ２９７での受信された応答をステップ２９１での要求の応答メッセージに変換する。ステップ２９８において、ホスト側CSE１７１は、１）ステップ２９７においてクエリ結果として返送される＜semanticDescriptors＞リソースの親リソースをロケートする。または２）単純にステップ２９７においてクエリ結果を受理する。どのアクションを行うかはステップ２９１に含まれるsparqlTypeパラメータに依存し得る。ステップ２９１における要求の応答メッセージのフォーマットは、ステップ２９７における受信された応答のフォーマットと異なる。ステップ２９９で、ホスト側CSE１７１は、ステップ２９１における要求の応答としてクエリイニシエータ１７５に結果を送信する。結果は、以下のうちの１つを含み得る。１）ステップ２９８が実行される場合、ステップ２９８で識別されるとおりの親リソースのリスト、または２）ステップ２９８が実行されない場合、ステップ２９７に含まれるとおりのクエリ結果。図３６のこの方法の実装オプションは、以下のようにsparqlTypeによって提供される情報を用い得る。１）ステップ２９１においてsparqlType＝1の場合、ホスト側CSE１７１は、図３６に示されるようにクエリとして処理されるようにSGS１７０に送信する、または、２）ステップ２９１においてsparqlType＝2の場合、ホスト側CSE１７１は、代わりに、SGS１７０にコンタクトすることなく、リソースツリーにおける直接アクセス制御に基づく発見としてローカルに、ステップ２９１における要求メッセージを処理し得る。
【0127】
以下にoneM2Mを考慮した追加的な例を示す。表８は使用し得る３つの属性を示し、より詳細に説明する。
【表21】
【0128】
oneM2Mについて、sparqlTypeなどの新しい要求パラメータが存在し得る。sparqlTypeは、oneM2M要求メッセージに含まれ得る新しいパラメータとして提案される。sparqlTypeは、この要求に含まれるSPARQLメッセージはoneM2Mリソースを発見するためであるか、＜semanticDescriptor＞リソースに含まれるようにトリプルおよび関連情報をクエリするためであるか、を示す。要求メッセージがSPARQLメッセージを含むたび、sparqlTypeも要求に含まれ得る。一例として、sparqlTypeの値は以下のように設定され得る。
○ sparqlType＝0は、その＜semanticDescriptor＞子リソースに含まれるセマンティック情報に基づいてoneM2Mリソースを発見するためのものである。
○ sparqlType＝1は、＜semanticDescriptor＞リソースに含まれるセマンティック情報を発見するためのものである。
○ sparqlType＝0は、その＜semanticDescriptor＞子リソースに含まれるセマンティック情報に基づいてoneM2Mリソースを発見するためのものである。
○ sparqlType＝1は、＜semanticDescriptor＞リソースに含まれるセマンティック情報を発見するためのものである。
【0129】
図３７は、イニシエート側AE／CSE（イニシエータ３０１）、ホスト側CSE３０２、SGS３０３の例示的ユーザインタフェースを図示する。イニシエータ３０１のユーザインタフェース（例えば、ACPイニシエータ１７２、SDイニシエータ１７３）は、ブロック３１１に示すように、ホスト側CSE３０２に送信される要求を表示するように設計されている。送信される各要求について、示されたパラメータが表示され得る。パラメータ「ホスト側CSE」は、ホスト側CSE３０２のアドレスを示し、パラメータ「アクション」は、要求によって表されるアクションを示す（例えば、＜accessCotrolPolicy＞リソースを作成、＜accessControlPolicy＞リソースを更新、＜accessControlPolicy＞リソースを削除、＜semanticDescriptor＞リソースを作成、＜semanticDescriptor＞リソースの記述子属性を更新、＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性を更新、＜semanticDescriptor＞リソースを削除）。
【0130】
引き続き図３７を参照すると、ホスト側CSE３０２のユーザインタフェース３１２は、イニシエータ３０１から受信された要求を表示するように設計され得る。送信される各要求について、ブロック３１２に示されるようにパラメータは表示され得る。パラメータ「要求側」は、イニシエータ３０１のアドレスを表し、パラメータ「アクション」は、要求によって表されるアクションを表す（例えば、＜accessCotrolPolicy＞リソースを作成、＜accessControlPolicy＞リソースを更新、＜accessControlPolicy＞リソースを削除、＜semanticDescriptor＞リソースを作成、＜semanticDescriptor＞リソースの記述子属性を更新、＜semanticDescriptor＞リソースのaccessControlPolicyIDs属性を更新、＜semanticDescriptor＞リソースを削除）。SGS１７０のユーザインタフェース３１３は、グラフにおいてACP関連およびSD関連トリプルの関係を示すように設計され得る。
【0131】
図３８は、本開示の方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインタフェース）を図示する。ディスプレイインタフェース９０１（例えば、タッチスクリーンディスプレイ）は、表７および表８など、アクセス制御ポリシーの同期または本開示に記載の他のセマンティクス事項に関連付けられたブロック９０２にテキストを提供し得る。別の例では、本開示のステップのいずれかの進捗（例えば、送信されたメッセージまたはステップの成功）がブロック９０２に表示され得る。さらに、グラフ出力９０３がディスプレイインタフェース９０１に表示され得る。グラフ出力９０３は、アクセス制御ポリシーの同期または本開示に記載の他のセマンティクス事項、またはとりわけ、本開示の任意の方法またはシステムの進捗のグラフ出力における、デバイスのトポロジーであってもよい。
【0132】
本開示の特許請求の範囲、解釈または適用を不当に制限することなく、本開示の１つ以上の実施例の技術的効果は、本開示に記載されるようにセマンティックACP同期に備えることである。セマンティックACP同期（セマンティックACP syncとしても開示される）は、セマンティック機能がM2M／IoTサービス層に導入される場合に発生し得る新しい問題である。したがって、これは従来のシステム（例えば、従来のセマンティックシステムまたは従来のM2M／IoTサービス層）では一般的に問題ではなかった。開示されたセマンティックACP syncによって、セマンティック動作を実行しながらセマンティックトリプルストアにおける直接アクセス制御が可能になり、（例えば、アクセス制御による結果として生じる実行時間の点で）最初にセマンティックトリプルストアでセマンティック動作を動作させた後、M2M／IoTサービス層でアクセス制御を実施するよりも効率的で高度になり得る。さらに、従来のM2M／IoTサービス層では、アクセス制御はそのサービス層リソースツリーで実施され、セマンティックトリプルストアでは実施されない。したがって、従来、セマンティック動作がセマンティックトリプルストアで実行される場合、対応するサービス層アクセス制御ポリシーは実施され得ず、実際に犯される場合がある。このことは、セマンティックトリプルストアに格納されたトリプルは、サービスアクセス制御ポリシーに従ってアクセスすべきではないにもかかわらず、アクセスされる場合があることを意味する。従来のシステムは、サービス層リソースツリー上のアクセス制御に依拠し得る。
【0133】
図３９Ａは、マシンツーマシン（machine-to machine:M2M）、モノのインターネット（Internet of Things:IoT）、またはモノのウェブ（Web of Things:WoT）の、アクセス制御ポリシーの同期または本開示に記載の他のセマンティクス事項に関連付けられた１つ以上の開示された概念を実装し得る、通信システム１０の一実施例の図である（例えば、図２０～図３８およびそれらの説明）。一般に、Ｍ２Ｍ技術は、IoT／WoTのブロックの構築を実現し、任意のM2Mデバイス、M2MゲートウェイまたはM2Mサービスプラットフォームは、IoT／WoTサービス層などと同様IoT／WoTのコンポーネントであり得る。
【0134】
図３９Ａに示すように、M2M／IoT／WoT通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ethernet（登録商標）、ファイバ、ISDN、PLC等）または無線ネットワーク（例えばWLAN、セルラー等）または異種ネットワークからなるネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージ通信、放送等のコンテンツを複数のユーザに提供する多元接続ネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access:CDMA）、時分割多元接続（Time Division Multiple Access:TDMA）、周波数分割多元接続（Frequency Division Multiple Access:FDMA）、直交FDMA（Orthogonal FDMA:OFDMA）、単一キャリアFDMA（Single-Carrier FDMA:SC－FDMA）等の１つまたは複数のチャネルアクセス方式を採用し得る。さらに、通信ネットワーク１２は、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、家庭用ネットワーク、または企業ネットワーク等の他のネットワークを含んでもよい。
【0135】
図３９Ａに示すように、M2M／IoT／WoT通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインとはエンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは通常M2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ１４および端末デバイス１８を含む。必要に応じて、任意の数のM2Mゲートウェイデバイス１４およびM2M端末デバイス１８がM2M／IoT／WoT通信システム１０に含まれ得ることが理解されよう。M2Mゲートウェイデバイス１４およびM2M端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成されている。M2Mゲートウェイデバイス１４により、無線M2Mデバイス（例えばセルラーおよび非セルラー）ならびに固定ネットワークM2Mデバイス（例えばPLC）は通信ネットワーク１２または直接無線リンク等のオペレータネットワークを介して通信できる。例えば、M2Mデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介してM2Mアプリケーション２０またはM2Mデバイス１８にデータを送信し得る。M2Mデバイス１８はまた、M2Mアプリケーション２０またはM2Mデバイス１８からデータを受信し得る。さらに、以下に説明するように、データおよび信号は、M2Mサービス層２２を介してM2Mアプリケーション２０に送受信され得る。M2Mデバイス１８およびゲートウェイ１４は、例えば、セルラー、WLAN、WPAN（例えば、Zigbee（登録商標）、6LoWPAN、Bluetooth（登録商標））、直接無線リンク、および有線を含む種々のネットワークを介して通信し得る。
【0136】
図３９Ｂを参照すると、フィールドドメインにおいて図示されたM2Mサービス層２２（例えば、ここに記載されるようなホスト側共通サービスエンティティ１７１）は、M2Mアプリケーション２０（例えば、SDイニシエータ１７３またはACPイニシエータ１７２）、M2Mゲートウェイデバイス１４、端末デバイス１８，通信ネットワーク１２のサービスを提供する。M2Mサービス層２２は任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス１４、M2M端末デバイス１８、通信ネットワーク１２と、所望の通信をし得ることが理解されよう。M2Mサービス層２２は、１つ以上のサーバ、コンピュータ、などによって実装し得る。M2Mサービス層２２は、M2M端末デバイス１８、M2Mゲートウェイデバイス１４およびM2Mアプリケーション２０に適用するサービス能力を提供する。M2Mサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークにおいて、クラウドにおいて、など種々のやり方で実装し得る。
【0137】
図示されたM2Mサービス層２２と同様に、インフラストラクチャドメイン内にM2Mサービス層２２’がある。M2Mサービス層２２’は、インフラストラクチャドメインにおいてM2Mアプリケーション２０’および下層通信ネットワーク１２’にサービスを提供する。M2Mサービス層２２’はさらに、フィールドドメインにおいてM2Mゲートウェイデバイス１４およびM2M端末デバイス１８にサービスを提供する。M2Mサービス層２２’は、任意の数のM2Mアプリケーション、M2MゲートウェイデバイスおよびM2M端末デバイスと通信し得ることが理解されよう。M2Mサービス層２２’は、異なるサービスプロバイダによってサービス層と対話し得る。M2Mサービス層２２’は、１つまたは複数のサーバ、コンピュータ、仮想マシン（例えば、クラウド／コンピュータ／ストレージファーム等）等によって実装され得る。
【0138】
さらに図３９Ｂを参照すると、M2Mサービス層２２および２２’は、多様なアプリケーションおよび垂直が活用し得るサービス提供機能のコアセットを提供する。これらのサービス機能により、M2Mアプリケーション２０および２０’は、デバイスと対話し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を実行することが可能になる。基本的に、これらのサービス機能により、アプリケーションにこれらの機能を実装する負担が加わらなくなるため、アプリケーション開発を簡素化し、製品化までの費用および時間を削減する。サービス層２２および２２’によってさらに、M2Mアプリケーション２０および２０’はサービス層２２および２２’が提供するサービスに関連する種々のネットワーク１２および１２’を介して通信できる。
【0139】
実施例のなかには、M2Mアプリケーション２０および２０’は、ここに記載されるように、アクセス制御ポリシーの同期または他のセマンティクス事項を用いて通信する所望のアプリケーションを含み得るものがある。M2Mアプリケーション２０および２０’は、運輸、健康維持管理、コネクテッドホーム、エネルギー管理、資産管理、安全監視などを含むがこれらに限定されない、各種産業におけるアプリケーションを含み得る。前述したように、M2Mサービス層は、複数デバイス、ゲートウェイ、システムのその他サーバ上で実行し、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、レガシーシステム統合、などの機能をサポートし、これらの機能をM2Mアプリケーション２０および２０’に対するサービスとして提供する。
【0140】
アクセス制御ポリシーの同期または本願に記載の他のセマンティクス事項は、サービス層の一部として実装し得る。サービス層は、アプリケーションプログラミングインタフェース（API）および基調となるネットワーキングインタフェースのセットを介して、追加価値サービス能力をサポートするミドルウェア層である。M2Mエンティティ（例えば、デバイス、ゲートウェイ、ハードウェアに実装されるサービス／プラットフォームなどのM2M機能エンティティ）は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mのどちらもアクセス制御ポリシーの同期または本願に記載の他のセマンティクス事項を含み得るサービス層を用いる。oneM2Mサービス層は、共通サービス機能（Common Service Function:CSF）のセット（すなわちサービス能力）をサポートする。１つ以上の特定のタイプのCSFのセットのインスタンシエーションは、共通サービスエンティティ（Common Services Entity:CSE）と呼ばれ、種々のタイプのネットワークノード上でホストすることができる（例えば、インフラストラクチャノード、アプリケーション固有ノード）。さらに、アクセス制御ポリシーの同期または本願に記載の他のセマンティクス事項は、アクセス制御ポリシーの同期または本願に記載の他のセマンティクス事項などのサービスにアクセスするためのサービス指向アーキテクチャ（Service Oriented Architecture:SOA）またはリソース指向アーキテクチャ（resource-oriented architecture:ROA）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。
【0141】
本明細書に開示されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は典型的には、HTTP、CoAPまたはMQTT等のアプリケーションプロトコル層上に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層はまた、例えば制御層およびトランスポート／アクセス層等のより低いリソース層でコアネットワークへのインタフェースを提供する。サービス層は、サービス定義、サービスランタイムの有効化、ポリシー管理、アクセス制御およびサービスクラスタリングを含む、複数のカテゴリの（サービス）能力または機能をサポートする。近年、いくつかの業界標準化団体、例えば、oneM2Mは、インターネット／ウェブ、セルラー、企業、および家庭用ネットワーク等の展開へのM2Mタイプのデバイスおよびアプリケーションの統合に関連する課題を解決するためにM2Mサービス層を開発している。M2Mサービス層は、CSEまたはSCLと呼ばれ得るサービス層によってサポートされる上述の能力または機能の集合またはセットへのアクセスにより、種々のデバイスにアプリケーションに提供し得る。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性管理（種々のアプリケーションによって共通して用いられ得る）が挙げられるが、これらに限定されない。これらの能力または機能は、M2Mサービス層によって定義されたメッセージフォーマット、リソース構造およびリソース表現を利用するAPIを介してそのような種々のアプリケーションで利用可能となる。CSEまたはSCLは、ハードウェアまたはソフトウェアによって実装され得、かつ種々のアプリケーションまたはデバイス（例えば機能エンティティ間の機能インタフェース）が（サービス）能力または機能を使用するために、それらに公開されるそのような能力または機能を提供する機能エンティティである。
【0142】
図３９Ｃは、例えば（ACPイニシエータ１７２または医師１５１を含み得る）M2M端末デバイス１８または（ホスト側CSE１７１を含み得る）M2Mゲートウェイデバイス１４などの、例示的M2Mデバイス３０のシステムズである。図３９Ｃに示すように、M2Mデバイス３０はプロセッサ３２，トランシーバ３４、要素を送信／受信３６、スピーカ／マイクロフォン３８，キーパッド４０、ディスプレイ／タッチパッド４２，非リムーバブルメモリ４４、リムーバブルメモリ４６，電源４８、全地球無線測位システム（global positioning system:GPS）チップセット５０、その他周辺機器５２を含み得る。M2Mデバイス３０は、開示された対象と一致しながら、前述の要素の任意の部分的組み合わせを含み得ることが理解されるであろう。M2Mデバイス３０（例えば、ACPイニシエータ１７２、患者１５２、医師１５１、ホスト側CSE１７１など）は、サービス層におけるアクセス制御ポリシーの同期のための開示されたシステムおよび方法またはここに記載されたその他セマンティクス事項を実施する例示的実装であり得る。
【0143】
プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor:DSP）、複数のマイクロプロセッサ、DSPコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit:ASIC）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array:FPGA）回路、任意の他のタイプの集積回路（Integrated Circuit:IC）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、出力制御、入力／出力処理、またはM2Mデバイス３０が無線環境で動作することを可能にする他の任意の機能を実行し得る。プロセッサ３２はトランシーバ３４と結合され得、トランシーバ３４は送信／受信要素３６と結合され得る。図３９Ｃは、プロセッサ３２およびトランシーバ３４を別個のコンポーネントとして図示しているが、プロセッサ３２およびトランシーバ３４は、電子パッケージまたはチップに一緒に統合されてもよいことが理解され得る。プロセッサ３２は、アプリケーション層プログラム（例えばブラウザ）または無線アクセス層（RAN）プログラムまたは通信を実行し得る。プロセッサ３２は、例えばアクセス層またはアプリケーション層等での認証、セキュリティ鍵合意または暗号操作等のセキュリティ操作を実行し得る。
【0144】
送信／受信要素３６は、M2Mサービスプラットフォーム２２に信号を送信するか、またはM2Mサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、送信／受信要素３６は、RF信号を送信または受信するように構成されたアンテナであり得る。送信／受信要素３６は、WLAN、WPAN、セルラー等の種々のネットワークおよび電波インタフェースをサポートし得る。一例では、送信／受信要素３６は、例えばIR、UVまたは可視光信号を送信または受信するように構成されたエミッタ／検出器であり得る。さらに別の例では、送信／受信要素３６は、RF信号および光信号の両方を送信および受信するように構成され得る。送信／受信要素３６は、無線信号または有線信号の任意の組み合わせを送信または受信するように構成され得ることが理解され得る。
【0145】
加えて、送信／受信要素３６は図３９Ｃに単一の要素として図示されているが、M2Mデバイス３０は、任意の数の送信／受信要素３６を備え得る。より具体的には、M2Mデバイス３０は、MIMO技術を採用し得る。したがって、一例では、M2Mデバイス３０は、無線信号を送信および受信するための２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を備え得る。
【0146】
トランシーバ３４は、送信／受信要素３６によって送信される信号を変調し、送信／受信要素３６によって受信される信号を復調するように構成され得る。上述のように、M2Mデバイス３０はマルチモード機能を有し得る。したがって、トランシーバ３４は、M2Mデバイス３０が、例えばUTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数のトランシーバを含み得る。
【0147】
プロセッサ３２は、非リムーバブルメモリ４４またはリムーバブルメモリ４６などの任意の好適なメモリからの情報にアクセスし、またそのメモリへデータを格納し得る。非リムーバブルメモリ４４はランダムアクセスメモリ（random-access memory:RAM）、リードオンリーメモリ（read-only memory:ROM）、ハードディスク、または他のタイプのメモリストレージデバイスを含み得る。リムーバブルメモリ４６は、加入者識別モジュール（subscriber identity module:SIM）カード、メモリスティック、SD（secure digital:SD）メモリカードなどを含み得る。他の実施例において、プロセッサ３２は、サーバまたはホームコンピュータなどの、M2Mデバイス３０に物理的に設置されないメモリからの情報にアクセスし、またそのメモリへデータを格納し得る。プロセッサ３２は、アクセス制御ポリシーの同期または実施例のいくつかにおいてここに記載されたその他セマンティクス事項が成功か不成功かに応答してディスプレイまたはインジケータ４２の照明パターン、イメージ、または色を制御する（例えば、アクセスポリシー制御リソースを更新する）、さもなければサービス層におけるアクセス制御ポリシーの同期またはここに記載されたその他セマンティクス事項および関連するコンポーネントのステータスを示すように、構成され得る。ディスプレイまたはインジケータ４２の照明パターン、イメージ、または色の制御は、ここに図示または記載の任意の方法フローまたはコンポーネントのステータスの反映になり得る（例えば、図１８～図３８など）。アクセス制御ポリシーの同期またはここに記載されたその他セマンティクス事項のメッセージおよび手順が、本開示に記載されている。メッセージおよび手順を拡張して、ユーザが、サービス層における属性またはリソースまたはアクセス制御ポリシーの同期またはここに記載されたその他セマンティクス事項に関連付けられた情報を、入力ソース（例えば、スピーカ／マイクロフォン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して要求し、さらに、とりわけディスプレイ４２に表示され得るもののうち、アクセス制御ポリシーの同期またはここに記載されたその他セマンティクス事項に関連付けられた情報を要求し、構成し、クエリするための、インタフェース／APIを提供することができる。
【0148】
プロセッサ３２は、電源４８から電力を受け取ることができ、M2Mデバイス３０内の他のコンポーネントに電力を分配または制御するように構成され得る。電源４８は、M2Mデバイス３０に電力供給する任意の適切なデバイスであり得る。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケル－カドミウム（NiCd）、ニッケル－亜鉛（NiZn）、ニッケル水素（NiMH）、リチウムイオン（Liイオン）等）、太陽電池、燃料電池等を挙げることができる。
【0149】
プロセッサ３２はさらに、M2Mデバイス３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されたGPSチップセット５０と結合され得る。M2Mデバイス３０は、本明細書に開示された情報と整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得し得ることが理解され得る。
【0150】
プロセッサ３２はさらに、他の周辺機器５２と結合され得、他の周辺機器５２としては、追加の特徴、機能または有線もしくは無線接続性を提供する１つまたは複数のソフトウェアまたはハードウェアモジュールを挙げることができる。例えば、周辺機器５２としては、種々のセンサ、例えば、加速度計、バイオメトリクス（例えば指紋）センサ、ｅ－コンパス、衛星トランシーバ、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus:USB）ポート、または他の相互接続インタフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（Frequency Modulated:FM）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を挙げることができる。
【0151】
送信／受信要素３６は、センサ、家庭用電化製品、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療デバイスまたはｅヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、電車または航空機等の車両のような他の装置またはデバイスに組み込まれ得る。送信／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インタフェース等の１つまたは複数の相互接続インタフェースを介してそのような装置またはデバイスの他のコンポーネント、モジュールまたはシステムに接続し得る。
【0152】
図３９Ｄは、例示的コンピューティングシステム９０のブロック図であり、例えば、図３９Ａおよび図３９ＢのM2Mサービスプラットフォーム２２が実装され得る。コンピューティングシステム９０（例えば、M2M端末デバイス１８またはM2Mゲートウェイデバイス１４）は、コンピュータまたはサーバを備えてもよく、何らかの手段によってそのような命令が格納またはアクセスされる、コンピュータ可読命令によって本質的に制御され得る。このようなコンピュータ可読命令は中央処理装置（central processing unit:CPU）９１内で実行され、コンピューティングシステム９０を作動させ得る。多くの周知のワークステーション、サーバ、パーソナルコンピュータにおいて、CPU９１は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンにおいて、CPU９１は複数のプロセッサを備えてもよい。コプロセッサ８１は、メインCPU９１と区別され、追加機能を実行する、またはCPU９１を助ける、任意のプロセッサである。CPU９１またはコプロセッサ８１は、サービス層におけるアクセス制御ポリシーの同期または、ユニフォームリソースインジケータの生成などのここに記載されたその他セマンティクス事項のための、開示されたシステムおよび方法に関連したデータを受信、生成、および処理し得る。
【0153】
動作中、CPU９１は、命令をフェッチし、復号し、実行し、コンピュータのメインデータ転送経路であるシステムバス８０を介して他のリソースとの間で情報を転送する。このようなシステムバスはコンピューティングシステム９０のコンポーネント同士を接続し、データ交換用の媒体を規定する。典型的には、システムバス８０は、データを送信するデータ回線、アドレスを送信するアドレス回線、および割込みを送信し、システムバスを動作させる制御回線を備える。そのようなシステムバス８０の例は、PCI（Peripheral Component Interconnect）バスである。
【0154】
システムバス８０に結合されたメモリデバイスは、ランダムアクセスメモリ（RAM）８２および読み取り専用メモリ（ROM）９３を含む。このようなメモリは、情報を記憶および検索することを可能にする回路機構を備える。ROM９３は一般に、容易に修正できない記憶データを含む。RAM８２に記憶されたデータは、CPU９１または他のハードウェアデバイスによって読み取りまたは変更され得る。RAM８２またはROM９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されるときに仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、システムプロセスをユーザプロセスから隔離するメモリ保護機能を提供し得る。したがって、第１のモードで動作しているプログラムは、それ自身のプロセス仮想アドレス空間によってマップされたメモリのみにアクセスでき、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス空間内のメモリにはアクセスできない。
【0155】
さらに、コンピューティングシステム９０は、CPU９１からの命令をプリンタ９４、キーボード８４、マウス９５およびディスクドライブ８５等の周辺機器に伝達する役割を果たす周辺機器コントローラ８３を備え得る。
【0156】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用され得る。そのような視覚的出力としては、テキスト、グラフィックス、動画およびビデオを挙げることができる。ディスプレイ８６は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイまたはタッチパネルを用いて実現され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するのに必要な電子部品を備える。
【0157】
さらに、コンピューティングシステム９０は、コンピューティングシステム９０を図５１Ａおよび図５１Ｂのネットワーク１２等の外部通信ネットワークに接続するために使用され得るネットワークアダプタ９７を備え得る。
【0158】
本明細書に記載のシステム、方法およびプロセスのいずれかまたはすべては、コンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令（例えばプログラムコード）の形で具現化され得、この命令は、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等の機械により実行されたときに、本明細書に記載のシステム、方法およびプロセスを実行または実施することを理解されたい。具体的には、上記のステップ、操作または機能のいずれも、そのようなコンピュータ実行可能命令の形で実施され得る。コンピュータ可読記憶媒体は、情報を記憶するための任意の方法または技術において実装される揮発性および不揮発性、取り外し可能および取り外し不能の媒体の両方を含むことができるが、そのようなコンピュータ可読記憶媒体は信号自体を含まない。本明細書の説明から明らかなように、記憶媒体は法定で定められた主題であると解釈されるべきである。コンピュータ可読記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD－ROM、デジタル汎用ディスク（Digital Versatile Disk:DVD）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を格納するために使用可能で、コンピュータによってアクセス可能な任意の他の物理的媒体が挙げられる。コンピュータ可読記憶媒体には、コンピュータプログラムが記憶されていてもよい。コンピュータプログラムは、データ処理ユニットにロード可能であり得、コンピュータプログラムがデータ処理ユニットによって実行されるときにデータ処理ユニットに方法ステップを実行させるように構成され得る。
【0159】
本開示の対象の推奨される方法、システム、または装置、すなわちサービス層におけるアクセス制御ポリシーの同期またはここに記載されたその他セマンティクス事項、の記述において、図示されるように、明確化のため特定の用語が使用される。ただし、特許請求される対象は、そのように選択された特定の用語に限定されることを意図されず、特定の要素のそれぞれは、同様の目的を達成するための同様のやり方で動作するすべての技術的同等物を含むことが理解されよう。SPARQL要求などが本開示にわたって言及されているが、関連するRESTful動作を本書において使用し得ることが考慮されている。本書において使用される用語は、図示の目的のためだけに使用され、所定の機能は将来の実装において異なる名前を持ち得る。
【0160】
本明細書に記載の種々の技術は、ハードウェア、ファームウェア、ソフトウェア、または適切な場合にはそれらの組み合わせと関連して実施され得る。そのようなハードウェア、ファームウェアおよびソフトウェアは、通信ネットワークのさまざまなノードに配置されている装置に常駐し得る。装置は、本明細書に記載の方法を実現するために、単独でまたは互いに組み合わせて動作し得る。本明細書で使用されるとき、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」等は同じ意味で用いられ得る。さらに、「または」という語の使用は、本明細書で別段の定めがない限り、一般に包括的に用いられる。
【0161】
本書は、ベストモードを含め、本発明を開示する、および、任意のデバイスまたはシステムを作成および使用し任意の取り込まれた方法を実施することを含め、当業者に本発明を実施させるための、複数の実施例を用いる。本発明の特許性のある範囲は、請求項によって限定され、当業者に対して発生する他の実施例を含み得る（例えば、本開示に記載の例示的方法の間でのステップのスキップ、ステップの組み合わせ、またはステップの追加）。このような他の実施例は、それらが請求項の文字通りの文言と異ならない構造要素を持つ場合、または請求項の文字通りの文言との実質的でない違いがある等価構造を含む場合、請求項の範囲に入るとされている。
【0162】
本開示に記載の、とりわけ、方法、システム、装置は、サービス層のためのアクセスポリシーの同期の手段に備え得る。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションによってリソースを作成するための要求メッセージを受信する手段を有し、該リソースは、アクセス制御ポリシー、アプリケーションにリソースを作成するアクセス権があるという決定に基づいてリソースを作成すること、該リソースおよび、アクセス制御ポリシーのオントロジーに基づいて、該リソースおよび該オントロジーに関連付けられたトリプルを生成すること、および、格納のためセマンティックグラフストアに該トリプルを送信するための命令を提供すること、のためのものである。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションに、リソースに対してユニフォームリソース識別子を含む応答メッセージを送信する命令を与える手段を持ち、これは要求メッセージに対する応答であり得る、または要求メッセージに基づき得る。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティックグラフストアのアドレスをリソースに付与する手段を持つ。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティックグラフストアのアドレスを新しい属性に付与する手段を持つ。要求メッセージは、作成対象であるリソースの表現を含む。該表現は、privileges属性の値であり得る。該リソースは、複数のアクセス制御ルールを含むprivileges属性を含み得る。該リソースは、syncFlag属性、syncTime属性、またはsdList属性を含み得る。このパラグラフのすべての組み合わせ（ステップの除去または付与を含む）は、その他の箇所の詳細な記述と一致するように考慮される。
【0163】
ここに記載される、とりわけ、方法、システム、装置は、サービス層のためのアクセスポリシー同期の手段に備え得る。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションから、リソースの第１のアクセス制御ポリシー識別子を備える属性を更新するための要求メッセージを受信する手段を持ち、該リソースは、アクセス制御ポリシー、アプリケーションにリソースを更新するアクセス権があるという決定に基づいて第１のアクセス制御ポリシー識別子ではなく第２のアクセス制御ポリシー識別子を含むように該リソースを更新すること、および、該リソースを更新することに基づいて該アクセス制御ポリシーおよびセマンティック記述子に関連付けられた新しいバインドトリプルを生成すること、のためのものである。方法、システム、コンピュータ可読記憶媒体、または装置は、グラフィカルユーザインタフェース上にアプリケーションのリソースのステータスを表示するための命令を与える手段を持つ。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティックグラフストア上での古いバインドトリプルの置換を確認するセマンティックグラフストアからのメッセージを受信する手段を持つ。方法、システム、コンピュータ可読記憶媒体、または装置は、グラフィカルユーザインタフェース上にアプリケーションのリソースのステータスを表示する手段を持つ。新しいバインドトリプルは、第１のアクセス制御ポリシー識別子に関連付けられた古いバインドトリプルを置換し得る。第１のアクセス制御ポリシー識別子は、第１のユニフォームリソース識別子によって示されてもよい。第２のアクセス制御ポリシー識別子は、第２のユニフォームリソース識別子によって示されてもよい。属性は、セマンティック記述子の属性であってもよい。装置は、ホスト側共通サービスエンティティであってもよい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39A】
【図39B】
【図39C】
【図39D】