JP2019083544A - ドメインにわたるサービス層リソース伝搬 - Google Patents

Abstract

【課題】有線および無線通信システムを使用して、デバイスが相互とより直接的に通信することを可能にするマシンツーマシン（Ｍ２Ｍ）技術を提供する。【解決手段】１つのドメイン内のＭ２Ｍネットワークノードが、そのドメイン内でリソースまたはサービス能力層エンティティを宣伝する要求を生成し、かつ、ノード間のドメイン間基準点を介して別のドメイン内の別のＭ２Ｍネットワークノードに要求を伝送するステップと、そのノードのドメイン内でリソースを宣伝する要求を生成するステップと、ノード間のドメイン間基準点を介して別のドメイン内の別のマシンツーマシンネットワークノードに要求を伝送するステップとを含む。【選択図】図２

Description

（関連出願の引用）
本願は、“ＭＥＣＨＡＮＩＳＭ ＦＯＲ ＳＥＲＶＩＣＥ ＬＡＹＥＲ ＲＥＳＯＵＲＣＥ ＰＲＯＰＡＧＡＴＩＯＮ”と題され、２０１３年２月１５日に出願された、米国仮特許出願第６１／７６５，３２５号の利益を主張するものであり、その内容は、本明細書中に参照により援用される。

（背景）
マシンツーマシン（Ｍ２Ｍ）技術は、有線および無線通信システムを使用して、デバイスが相互とより直接的に通信することを可能にする。Ｍ２Ｍ技術は、一意的に識別可能なオブジェクトおよびインターネット等のネットワークを経由して相互と通信するそのようなオブジェクトの仮想表現のシステムである、モノのインターネット（ＩｏＴ）のさらなる実現を可能にする。ＩｏＴは、食料品店内の商品または家庭内の器具等のさらに日常的な毎日のオブジェクトとの通信を促進し、それによって、そのようなオブジェクトの知識を向上させることによって、費用および無駄を低減させ得る。例えば、店は、在庫にあり得る、または販売された場合がある、オブジェクトと通信するか、またはそこからデータを取得することができることによって、非常に精密な在庫データを維持してもよい。

Ｍ２Ｍエンティティ（例えば、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせによって実装され得る、デバイス、ゲートウェイ、サーバ／プラットフォーム等のＭ２Ｍ機能エンティティ）は、アプリケーションまたはサービスを提供してもよい。例えば、光センサは、検出された光レベルを示すデータを提供してもよく、またはサーモスタットは、温度データ、および空調制御を調整する能力を提供してもよい。このデータは、他のＭ２Ｍエンティティによってアクセスされ得、本質的に、Ｍ２Ｍエンティティ間でデータを交換する手段としての機能を果たす、「リソース」として利用可能にされてもよい。リソースは、ユニバーサルリソースインジケータ（ＵＲＩ）を使用してアドレス指定され得る、データの一意的にアドレス可能な表現であってもよい。そのようなリソースの可用性は、Ｍ２Ｍエンティティが、Ｍ２Ｍ通信システム内の利用可能なリソースを宣伝して発見することを可能にする、「公表」と呼ばれる機構を使用して、Ｍ２Ｍサービス能力層（ＳＣＬ）を介してこれらのエンティティの間で伝達されてもよい。Ｍ２Ｍ ＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装され得、基準点上で暴露される機能（すなわち、Ｍ２Ｍエンティティ間の機能インターフェース）を提供する、機能エンティティである。例えば、Ｍ２Ｍ ＳＣＬは、異なるＭ２Ｍアプリケーションおよび／またはサービスによって共有されるか、または一般的に使用される、共通（サービス）機能性を提供してもよい。これらの共通機能性は、オープンインターフェースのセットを使用して暴露されてもよい。例えば、Ｍ２Ｍサービス能力は、露出インターフェースのセット（例えば、３ＧＰＰ、３ＧＰＰ２、ＥＴＳＩ ＴＩＳＰＡＮ等によって特定される既存のインターフェース）を通して、セルラーコアネットワーク機能性を使用してもよく、また、１つまたはそれを上回る他のコアネットワークにインターフェース接続してもよい。リソースを提供するデバイスは、単純なデバイスであってもよいため、リソースを公表する通信は、多くの場合、元のリソースが常駐する場所であり得る、「ホスティング」ＳＣＬエンティティと称される、より知的なデバイスによって取り扱われる。ＳＣＬにおける他のＭ２Ｍ通信のように、物理的通信インターフェース、および任意の通信Ｍ２Ｍエンティティ間のアプリケーション層の下方の実際の通信経路から独立している、「基準点」と呼ばれる各エンティティにおける論理的通信インターフェースを使用して、リソース公表が行われる。

Ｍ２Ｍデバイスおよびエンティティは、典型的には、Ｍ２Ｍネットワークドメインに組織化される。多くの実装では、ネットワークＳＣＬエンティティ（ＮＳＣＬ）を伴って構成されるＭ２Ｍサーバは、同一のＭ２Ｍネットワークドメイン内の他のデバイス（例えば、他のＭ２ＭデバイスおよびＭ２Ｍゲートウェイ）によって使用するために、リソースおよびリソースデータを維持してもよい。しかしながら、現在のＭ２Ｍ実装では、ＳＣＬエンティティは、ＳＣＬに登録されたアプリケーションと関連付けられるリソースを、独自のネットワークドメイン内の他のＳＣＬエンティティに公表することしかできない。現在使用されている公表プロシージャは、ＳＣＬの公表も可能にするよりむしろ、ＳＣＬエンティティ（単純に「ＳＣＬ」と称され得る）によってアプリケーションリソースを公表することに限定され、リソースを公表するデバイスと同一のネットワークドメイン内でＮＳＣＬへの公表を促進するのみである。

本明細書で開示される実施形態は、１つのドメイン内のマシンツーマシンネットワークノードが、そのドメイン内でリソースまたはサービス能力層エンティティを宣伝する要求を生成し、かつノード間のドメイン間基準点を介して別のドメイン内の別のマシンツーマシンネットワークノードに要求を伝送するための方法を含む。

明細書で開示される実施形態はさらに、そのノードのドメイン内でリソースを宣伝する要求を生成するステップと、ノード間のドメイン間基準点を介して別のドメイン内の別のマシンツーマシンネットワークノードに要求を伝送するステップとを含む、動作を達成する命令を実行する、マシンツーマシンネットワークノードを含む。

明細書で開示される実施形態はさらに、実行されたときに、ノードのドメイン内でリソースを宣伝する要求を生成するステップと、ノード間のドメイン間基準点を介して別のドメイン内の別のマシンツーマシンネットワークノードに要求を伝送するステップとを含む、動作を達成する、その上に記憶されたコンピュータ可読命令を有する、コンピュータ可読媒体を含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本明細書は、例えば、以下を提供する。
（項目１）
通信ネットワーク内の第１のマシンツーマシンネットワークサービス能力層エンティティであって、
上記通信ネットワークで使用される機能性およびリソースの第１のセットを提供する実行可能命令を備える、メモリと、
プロセッサであって、上記実行可能命令を実行するときに、
上記機能性およびリソースの第１のセットを管理するステップと、
上記機能性およびリソースの第１のセットを第２のマシンツーマシンネットワークサービス能力層エンティティに公表することを判定するステップと、
上記第１のマシンツーマシンネットワークサービス能力層エンティティで利用可能な上記機能性およびリソースの第１のセットを宣伝する、上記機能性およびリソースの第１のセットの公表を生成するステップと、
上記機能性およびリソースの第１のセットの上記公表を上記第２のマシンツーマシンネットワークサービス能力層エンティティに伝送するステップと、
を含む、動作を達成する、プロセッサと、
を備える、第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目２）
上記第１のマシンツーマシンネットワークサービス能力層エンティティは、第１のネットワークドメイン内にあり、上記第２のマシンツーマシンネットワークサービス能力層エンティティは、第２のネットワークドメイン内にある、項目１に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目３）
上記動作はさらに、上記第２のマシンツーマシンネットワークサービス能力層エンティティから応答を受信するステップを含む、項目１に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目４）
上記機能性およびリソースの第１のセットは、上記第１のマシンツーマシンネットワークサービス能力層エンティティを表す、第２のサブリソースデータ構造を備える、第１のサブリソースデータ構造を備える、リソースデータ構造を備える、項目１に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目５）
上記動作はさらに、
機能性およびリソースの第３のセットを上記機能性およびリソースの第１のセットに登録する要求を、第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記機能性およびリソースの第３のセットは、上記第２のマシンツーマシンネットワークサービス能力層エンティティで利用可能である、ステップと、
上記機能性およびリソースの第３のセットを上記機能性およびリソースの第１のセットに登録するステップと、
を含む、項目１に記載の第１のマシンツーマシンネットワークエンティティ。
（項目６）
上記動作はさらに、
第３のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第３のセットを除去する要求を、上記第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記機能性およびリソースの第３のセットは、上記機能性およびリソースの第１のセットに登録される、ステップと、
上記機能性およびリソースの第１のセットから上記機能性およびリソースの第３のセットを除去するステップと、
を含む、項目１に記載の第１のマシンツーマシンネットワークエンティティ。
（項目７）
上記動作はさらに、
第３のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第３のセットを更新する要求を、上記第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記第３の機能性およびリソースの第３のセットは、上記機能性およびリソースの第１のセットに登録される、ステップと、
上記機能性およびリソースの第１のセットの中の上記機能性およびリソースの第３のセットを更新するステップと、
を含む、項目１に記載の第１のマシンツーマシンネットワークエンティティ。
（項目８）
通信ネットワーク内の第１のマシンツーマシンネットワークサービス能力層エンティティであって、
上記通信ネットワークで使用される機能性およびリソースの第１のセットを提供する実行可能命令を備える、メモリと、
プロセッサであって、上記実行可能命令を実行するときに、
上記機能性およびリソースの第１のセットを管理するステップと、
第２のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第２のセットを上記機能性およびリソースの第１のセットに登録する要求を、上記第２のマシンツーマシンサービス能力層エンティティから受信するステップと、
上記機能性およびリソースの第２のセットを上記機能性およびリソースの第１のセットに登録するステップと、
を含む、動作を達成する、プロセッサと、
を備える、第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目９）
上記第１のマシンツーマシンネットワークサービス能力層エンティティは、第１のネットワークドメイン内にあり、上記第２のマシンツーマシンネットワークサービス能力層エンティティは、第２のネットワークドメイン内にある、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１０）
上記動作はさらに、応答を上記第２のマシンツーマシンネットワークサービス能力層エンティティに伝送するステップを含む、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１１）
上記機能性およびリソースの第２のセットは、上記第２のマシンツーマシンネットワークサービス能力層エンティティを表す、第２のサブリソースデータ構造を備える、第１のサブリソースデータ構造を備える、リソースデータ構造を備える、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１２）
上記動作はさらに、
第３のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第３のセットを除去する要求を、上記第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記機能性およびリソースの第３のセットは、上記機能性およびリソースの第１のセットに登録される、ステップと、
上記機能性およびリソースの第１のセットから上記機能性およびリソースの第３のセットを除去するステップと、
を含む、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１３）
上記動作はさらに、
第２のデータリソースを第３のマシンツーマシンネットワークサービス能力層エンティティに公表することを判定するステップと、
上記第２のマシンツーマシンネットワークサービス能力層エンティティで利用可能な上記機能性およびリソースの第２のセットを宣伝する、上記第２のデータリソースの公表を生成するステップと、
上記第２のデータリソースの上記公表を上記第３のマシンツーマシンネットワークサービス能力層エンティティに伝送するステップと
を含む、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１４）
上記動作はさらに、
上記第２のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第２のセットを更新する要求を、上記第２のマシンツーマシンサービス能力層エンティティから受信するステップと、
上記機能性およびリソースの第１のセットの中の上記機能性およびリソースの第２のセットを更新するステップと、
を含む、項目８に記載の第１のマシンツーマシンネットワークサービス能力層エンティティ。
（項目１５）
プロセッサによって、機能性およびリソースの第１のセットを管理するステップと、
上記プロセッサによって、上記機能性およびリソースの第１のセットを第２のマシンツーマシンネットワークサービス能力層エンティティに公表することを判定するステップと、
上記プロセッサによって、第１のマシンツーマシンネットワークサービス能力層エンティティで利用可能な上記機能性およびリソースの第１のセットを宣伝する、上記機能性およびリソースの第１のセットの公表を生成するステップと、
上記プロセッサによって、上記機能性およびリソースの第１のセットの上記公表を上記第２のマシンツーマシンネットワークサービス能力層エンティティに伝送するように伝送機に命令するステップと、
を含む、方法。
（項目１６）
上記第１のマシンツーマシンネットワークサービス能力層エンティティは、第１のネットワークドメイン内にあり、上記第２のマシンツーマシンネットワークサービス能力層エンティティは、第２のネットワークドメイン内にある、項目１５に記載の方法。
（項目１７）
上記第３のマシンツーマシンネットワークサービス能力層エンティティから応答を受信するステップをさらに含む、項目１５に記載の方法。
（項目１８）
上記機能性およびリソースの第１のセットは、上記第１のマシンツーマシンネットワークサービス能力層エンティティを表す、第２のサブリソースデータ構造を備える、第１のサブリソースデータ構造を備える、リソースデータ構造を備える、項目１５に記載の方法。
（項目１９）
機能性およびリソースの第３のセットを上記機能性およびリソースの第１のセットに登録する要求を、第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記機能性およびリソースの第３のセットは、上記第２のマシンツーマシンネットワークサービス能力層エンティティで利用可能である、ステップと、
上記機能性およびリソースの第３のセットを上記機能性およびリソースの第１のセットに登録するステップと、
をさらに含む、項目１５に記載の方法。
（項目２０）
第３のマシンツーマシンネットワークサービス能力層エンティティで利用可能な機能性およびリソースの第３のセットを除去する要求を、上記第３のマシンツーマシンサービス能力層エンティティから受信するステップであって、上記機能性およびリソースの第３のセットは、上記機能性およびリソースの第１のセットに登録される、ステップと、
上記機能性およびリソースの第１のセットから上記機能性およびリソースの第３のセットを除去するステップと、
をさらに含む、項目１５に記載の方法。

図１は、デバイスおよび基準点を含む、例示的なＭ２Ｍシステムを図示する。 図２は、ドメイン内でリソースを公表するプロシージャの例示的な信号フローを図示する。 図３は、例示的なリソース構造を図示する。 図４は、別の例示的なリソース構造を図示する。 図５は、別の例示的なリソース構造を図示する。 図６は、ネットワークドメイン間でリソースを公表するプロシージャの例示的な信号フローを図示する。 図７は、ネットワークドメイン間でＳＣＬを公表するプロシージャの例示的な信号フローを図示する。 図８は、ネットワークドメイン間でリソースを更新するプロシージャの例示的な信号フローを図示する。 図９は、ネットワークドメイン間でリソースを削除するプロシージャの例示的な信号フローを図示する。 図１０は、ＳＣＬリソースを公表するプロシージャの例示的な信号フローを図示する。 図１１は、例示的なリソースツリー構造を図示する。 図１２は、例示的なリソースツリー構造を図示する。 図１３は、公表されたＳＣＬリソースのサブリソースを公表するプロシージャの例示的な信号フローを図示する。 図１４は、例示的なリソースツリー構造を図示する。 図１５は、例示的なリソースツリー構造を図示する。 図１６Ａは、１つまたはそれを上回る開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１６Ｂは、図１６Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１６Ｃは、図１６Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１６Ｄは、図１６Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

ＥＴＳＩ Ｍ２Ｍ ＴＳ １０２ ６９０ Ｖ２．０．１２（本明細書では「ＥＴＳＩ
Ｍ２Ｍ仕様」）は、１つのサービス層エンティティがそのリソースを他のエンティティに宣伝することを可能にし、それによって、複数のエンティティによるリソースの使用を促進する、「公表」と呼ばれる機構を定義する。本開示は、本明細書を指し、および／または開示された実施形態の理解に役立つように本明細書では理解されるため、用語を使用してもよい。

本明細書に記載される実施形態は、表現状態転送（ＲＥＳＴ）アーキテクチャに関して説明され、説明される構成要素およびエンティティは、ＲＥＳＴアーキテクチャ（ＲＥＳＴｆｕｌアーキテクチャ）の制約に従う。ＲＥＳＴｆｕｌアーキテクチャは、物理的構成要素の実装または使用される通信プロトコルに関するよりもむしろ、アーキテクチャで使用される構成要素、エンティティ、コネクタ、およびデータ要素に適用される制約に関して説明される。したがって、構成要素、エンティティ、コネクタ、およびデータ要素の役割および機能が説明されるであろう。ＲＥＳＴｆｕｌアーキテクチャでは、一意的にアドレス可能なリソースの表現が、エンティティ間で転送される。ＥＴＳＩ Ｍ２Ｍ仕様は、ＳＣＬ上に常駐するリソース構造を標準化している。ＲＥＳＴｆｕｌアーキテクチャでリソースを取り扱うとき、作成（子リソースを作成する）、回収（リソースのコンテンツを読み取る）、更新（リソースのコンテンツを書き込む）、または削除（リソースを削除する）等のリソースに適用され得る基本的方法がある。当業者であれば、本開示の範囲内にとどまりながら、本実施形態の実装が変動し得ることを認識するであろう。当業者であればまた、開示された実施形態が、例示的実施形態を説明するために本明細書で使用されるＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されないことも認識するであろう。開示された実施形態は、１つのＭ２Ｍ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装されてもよい。

背景技術の節において上記で議論されるように、現在のＭ２Ｍ実装では、ＳＣＬエンティティは、アプリケーションと関連付けられるリソースを、独自のネットワークドメイン内の他のＳＣＬエンティティに公表することしかできない。また、現在使用されている公表プロシージャは、ＳＣＬを表すリソース（単純に「ＳＣＬリソース」と称され得る）の公表も可能にするよりむしろ、ＳＣＬエンティティ（単純に「ＳＣＬ」と称され得る）によってアプリケーションと関連付けられるリソース（単純に「リソース」と称され得る）を公表することに限定され、リソースを公表するエンティティと同一のネットワークドメイン内でＮＳＣＬへの公表を促進するのみである。以降で説明される実施形態は、既存の公表機構を改良し、ＳＣＬがＳＣＬリソースおよびそのサブリソースを他のＳＣＬに公表することを可能にする。例えば、ＮＳＣＬは、ＮＳＣＬのドメイン内のリソースおよびＳＣＬリソースを、異なるドメイン内の１つまたはそれを上回る他のＮＳＣＬに宣伝してもよい。代替として、ゲートウェイＳＣＬ（ＧＳＣＬ）およびデバイスＳＣＬ（ＤＳＣＬ）等の他のＳＣＬもまた、リソースおよびＳＣＬリソースを、同一または異なるドメイン内の１つまたはそれを上回る他のＮＳＣＬに宣伝してもよい。これは、異なるネットワークドメイン内のＭ２Ｍエンティティによる、ＳＣＬリソースおよび１つのネットワークドメイン内のリソースへのアクセスを可能にする。

図１は、いくつかの開示された実施形態で使用され得る、例示的なＥＴＳＩ Ｍ２Ｍシステム１００を図示する。この例示的システムは、開示された主題の説明を促進するように簡略化され、本開示の範囲を限定することを目的としていないことに留意されたい。システム１００等のシステムに加えて、またはその代わりに、本明細書で開示される実施形態を実装するために、他のデバイス、システム、および構成が使用されてもよく、全てのそのような実施形態は、本開示の範囲内と考慮される。

システム１００は、ネットワークドメイン１１０および１２０内のＭ２Ｍデバイスおよびエンティティを含んでもよい。ＮＳＣＬ１１１は、ドメイン１１０内にあり、Ｍ２＜サーバプラットフォーム１１５にネットワークアプリケーション（ＮＡ）１１２を伴って構成されてもよい。ＮＡ１１２およびＮＳＣＬ１１１は、基準点ｍＩａ１１３を介して通信してもよい。ｍＩａ基準点は、ＮＡがＭ２Ｍドメイン内のＮＳＣＬから利用可能なＭ２Ｍサービス能力にアクセスすることを可能にしてもよい。また、ネットワークドメイン１００内には、Ｍ２Ｍゲートウェイデバイス１４０で構成され得る、ＧＳＣＬ１４１およびゲートウェイアプリケーション（ＧＡ）１４２があってもよい。ＧＳＣＬ１４１およびＧＡ１４２は、基準点ｄＩａ１４３を使用して通信してもよい。さらに、ネットワークドメイン１００内には、Ｍ２Ｍデバイス１５０で構成され得る、ＤＳＣＬ１５１およびデバイスアプリケーション（ＤＡ）１５２があってもよい。ＤＳＣＬ１５１およびＤＡ１５２は、基準点ｄＩａ１５３を使用して通信してもよい。ＧＳＣＬ１４１およびＤＳＣＬ１５１のそれぞれは、基準点ｍＩｄ１６０を使用してＮＳＣＬ１１１と通信してもよい。一般に、ｄＩａ基準点は、デバイスおよびゲートウェイアプリケーションが、それぞれのローカルサービス能力（すなわち、それぞれ、ＤＳＣＬおよびＧＳＣＬで利用可能なサービス能力）と通信することを可能にする。ｍＩｄ基準点は、Ｍ２Ｍデバイス（例えば、ＤＳＣＬ１５１）またはＭ２Ｍゲートウェイ（例えば、ＧＳＣＬ１４１）に常駐するＭ２Ｍ ＳＣＬが、ネットワークドメイン内のＭ２Ｍサービス能力と通信することを可能にし、逆も同様である（例えば、ＮＳＣＬ１１１）。

ＮＳＣＬ１２１は、ＮＡ１２２とともにドメイン１２０内にあってもよい。ＮＡ１２２およびＮＳＣＬ１２１は、ｍＩａ基準点１２３を介して通信してもよい。ｍＩｍ基準点１３０は、ネットワークドメイン１１０内のＮＳＣＬ１１１およびネットワークドメイン１２０内のＮＳＣＬ１２１等の異なるネットワークドメイン内のＭ２Ｍネットワークノードが、相互と通信することを可能にする、ドメイン間基準点であってもよい。以降で説明される方法および装置の実施形態では、そのようなドメイン間通信は、ドメインにわたってリソースおよびＳＣＬリソースを公表するために使用されてもよい。

ＳＣＬは、それが登録されており、公表要求を受け入れることができる、ＳＣＬのみにリソースを公表してもよい。実施形態では、リソースを全ての潜在的な「公表先ＳＣＬ」に公表するために使用されるプロシージャは、関連ｍＩａまたはｄＩａおよびｍＩｄ基準点の一方または両方を使用してもよい。公表先ＳＣＬは、コンテンツがホスティングＳＣＬによってホストされる元のリソースを指し得る、「公表されたリソース」を含有するＳＣＬである。公表されたリソースは、別のＳＣＬ（ホスティングＳＣＬ）によってホストされる元のリソースへのリンク、検索文字列、およびアクセス権等の属性の限定されたセットのみから成り得る、実際のリソースである。公表されたリソースは、発見要求の発行元が元のリソースを見つけるために全てのＳＣＬに連絡する必要がないように、ホスティングＳＣＬによってホストされる元のリソースの発見を促進する。公表の元の発行元が、ＧＡ１４２、ＤＡ１５２、またはＮＡ１２２等のアプリケーションである場合には、公表は、それぞれのｍＩａまたはｄＩａ基準点上でトリガされてもよい。例えば、ｄＩａ１４３は、ＧＡ１４２のための公表をトリガするために使用されてもよく、ｄＩａ１５３は、ＤＡ１５２のための公表をトリガするために使用されてもよい。次いで、公表は、ｍＩｄ１６０を使用してＮＳＣＬ１１１に送信（実行）されてもよい。公表要求の元の発行元が、ＧＳＣＬ１４１またはＤＳＣＬ１５１等のＳＣＬである場合には、公表は、ｍＩｄ１６０上でトリガされるとともに実行されてもよい。公表要求の元の発行元が、ＧＳＣＬ１４１またはＤＳＣＬ１５１等のＳＣＬである場合には、アプリケーションが、公表の状態を通知されるように要求してもよい。アプリケーションは、リソースにアクセスするために、ＳＣＬに公表される情報を使用してもよい。例えば、公表されたアプリケーションのためのリンクおよび／または検索文字列が、公表されたアプリケーションと通信するために別のアプリケーションによって使用されてもよい。

実施形態では、公表要求の発行元がアプリケーション（例えば、ＮＡ１２２、ＧＡ１４２、ＤＡ１５２）である場合、アプリケーションは、リソースの適切な属性を変更することによって、リソースを他のＳＣＬに公表するように要求してもよい。公表プロシージャを開始するトリガは、そのローカルＳＣＬへの発行元の登録であってもよい。例えば、ＧＡ１４２がネットワークドメイン１１０内でＧＳＣＬ１４１に登録するとき、登録は、ＧＡ１４２のリソースを公表するプロセスの開始をトリガしてもよい。代替として、ネットワークドメイン１１０内のＤＳＣＬ１５１上のＤＡ１５２のための新しいリソースの作成等のローカルＳＣＬ上の新しいリソースの作成、またはネットワークドメイン１２０内のＮＳＣＬ１２１上のＮＡ１２２と関連付けられるリソースの更新等のローカルＳＣＬ上のリソースの更新は、それぞれのアプリケーションのリソースを公表するプロセスの開始をトリガしてもよい。

図２は、リソース公表プロシージャの信号フローを図示する。アプリケーション（例えば、ＮＡ、ＧＡ、またはＤＡ）と関連付けられるリソースの公表を要求するために、発行元２１０は、ｍＩａまたはｄＩａ基準点２４０を介して、ホスティングＳＣＬでもあり得るが、その必要はない、ローカルＳＣＬであり得る、ＳＣＬ２２０に公表要求２１１を伝送してもよい。公表要求２１１は、ＳＣＬ２２０への発行元２１０の登録時に生成される、作成要求であってもよい。代替として、公表要求２１１は、ＳＣＬ２２０上で発行元２１０のための新しいリソース（すなわち、ＳＣＬ２２０上で発行元２１０のために以前に作成されていないリソース）の作成を要求することであってもよい。別の代替案では、公表要求２１１は、ＳＣＬ２２０上で発行元２１０のための既存のリソース（すなわち、発行元２１０のためのＳＣＬ２２０によってすでにホストされているリソース）の更新を要求する、更新要求であってもよい。

公表要求２１１は、「公表属性リスト」と称される、リストの中で提供される１つまたはそれを上回る公表属性を含んでもよく、各属性は、公表の範囲に関する情報を含む。そのような属性は、要求されている公表のタイプを含んでもよい。属性はさらに、発行元が、公表属性リストまたは公表要求２１１でこれらのＳＣＬを一覧化することによって、公表が行われる特定のＳＣＬを判定するであろうことを示してもよく、または、ローカルＳＣＬが、公表が行われるＳＣＬの判定を行うものであることを示してもよい。属性はさらに、公表動作が発行元に確認される必要があるかどうかを示してもよい。公表動作確認は、全てのインターフェースプロシージャ、またはそのようなプロシージャの一部のみに使用されてもよい。これらの属性は、公表が可能にさせられる（例えば、アクティブまたは非アクティブである）かどうかを示してもよい。非アクティブ属性を使用することによって、公表属性リストは、ローカルＳＣＬ（例えば、ＳＣＬ２２０）でデータ投入されてもよいが、公表は、ローカルＳＣＬから他のＳＣＬ（例えば、ＳＣＬ２３０）に行われなくてもよい。非アクティブ属性を使用することは、リソース作成のみにおいて可能にされてもよく、アクティブ属性が受信されるまで、ＳＣＬがリソースを公表することを防止するために使用されてもよい。いくつかの実施形態では、いったん公表がアクティブとして示されると、非アクティブ属性の使用が許可または容認されなくてもよい。

属性リストは、発行元２１０がＳＣＬ２２０上で作成または更新を要求し得る、全ての公表可能なリソースに適用可能であり得る。ＳＣＬ２２０への登録時に発行元２１０によって提供される属性リストは、発行元２１０のデフォルト属性リストと称されてもよい。発行元２１０の公表可能なリソースはまた、独自のそれぞれの属性リストを提供してもよく、その場合、発行元２１０のデフォルト属性リストは、その特定のリソースに使用されなくてもよい。発行元２１０によるデフォルト属性リストへの更新または変更は、ＳＣＬ２２０上の以前に作成された公表可能なリソースに伝搬されないが、発行元２１０の任意の新しい公表可能なリソースが、更新されたデフォルト属性リストを使用して要求されてもよい。ＳＣＬ２２０上の既存のリソースの属性を変更するために、発行元２１０は、更新された属性リストを含む、リソースのための更新をＳＣＬ２２０に伝送してもよい。

ＳＣＬ２２０は、発行元２１０がリソースを公表する権限を与えられた発行元のリスト上にあると判定することによって、受信した公表要求２１１の正当性を立証してもよい。このリストは、「ａｃｃｅｓｓＲｉｇｈｔｓ」と標識されてもよい。（例えば、発行元２１０がＳＣＬ２２０で登録されていない、発行元２１０がＳＣＬ２２０上で要求されたリソースを作成または更新する権限を与えられていない、または公表要求２１１に含まれる属性が許容可能ではないため）正当性が立証されない場合、ＳＣＬ２２０は、公表プロシージャのうちのいずれも行わなくてもよく、いくつかの実施形態では、エラーメッセージを発行元２１０に返信してもよい。正当性が立証された場合、ブロック２２１で、ＳＣＬ２２０は、アプリケーション（例えば、ＮＡ、ＧＡ、またはＤＡ）を表すリソースを作成または更新してもよい。公表要求２１１の中で提供される属性がない場合、ＳＣＬ２２０は、新しい要求されたリソースを作成する際に、発行元２１０のための現在のデフォルト属性リストを使用してもよい。応答２２２が、ｍＩａまたはｄＩａ基準点２４０を介して発行元２１０に伝送されてもよく、発行元２１０がＳＣＬ２２０上でリソースの作成を要求する権限を与えられていることを確認する。ＳＣＬ２２０は、公表プロシージャの完了に先立って、または完了後に、この応答を送信してもよい。

発行元２１０がアプリケーションであり、公表要求２１１において、ＳＣＬ２２０が公表するべきであるＳＣＬを示さない、実施形態では、ＳＣＬ２２０は、以下で説明されるｍＩｄ基準点２５０を使用して、公表プロシージャの完了に先立って、ｍＩａまたはｄＩａ基準点２４０を介して、応答２２２を発行元２１０に送信することに留意されたい。本実施形態では、ＳＣＬ２２０は、いつ、およびどのＳＣＬにリソースを公表するかを決定する。発行元２１０がアプリケーションであり、公表要求２１１が、ＳＣＬ２２０が公表するべきであるＳＣＬを示す、別の実施形態では、ＳＣＬ２２０は、リソースを全ての示されたＳＣＬに公表することを完了した後に、（ｍＩａまたはｄＩａ基準点２４０を介して）応答２２２を発行元２１０に送信する。本実施形態では、応答２２２は、公表されたリソースの状態（すなわち、リソースが示されたＳＣＬのそれぞれで作成されることに成功したかどうか）を発行元２１０に示してもよい。本実施形態では、応答２２２は、公表されることに成功したＳＣＬのリストを含んでもよい。別の実施形態では、公表要求２１１は、確認が必要とされないことを示してもよく、したがって、本実施形態では、応答２２２が送信されなくてもよい。公表要求２１１が作成要求よりもむしろ更新要求であり、確認が必要とされないという指標が公表要求２１１に含まれる、他の実施形態では、応答２２２が送信されないが、公表要求２１１が作成要求であるときは、関係なく応答２２２が伝送される。

公表要求２１１が有効であるという判定に応答して、ＳＣＬ２２０は、ブロック２２３で公表プロシージャ処理を継続し、いつ、およびどのＳＣＬに新たに作成または更新されたリソースを公表するかを判定してもよい。

リソース公表要求２２４が、基準点ｍＩｄ２５０を介して、公表先ＳＣＬ２３０に伝送されてもよい。リソース公表要求２２４は、単純に「公表」と称されてもよく、リソースの作成を要求する「作成」要求であってもよい。公表２２４は、検索文字列、および作成されたリソースへのリンクを含んでもよい。

公表先ＳＣＬ２３０は、実施形態では、公表要求２１１の正当性を立証するためにＳＣＬ２２０によって使用されるプロセスと同様に、公表２２４の正当性を立証してもよいが、検証の代替的な方法を使用する他の実施形態が、本開示の範囲内と考慮される。実施形態では、ＳＣＬ２２０が、リソースを公表先ＳＣＬ２３０に公表する権限を与えられたエンティティの公表先ＳＣＬ２３０のａｃｃｅｓｓＲｉｇｈｔリストに含まれる場合のみ、リソースの作成が許可されてもよい。

ブロック２３１では、公表先ＳＣＬ２３０は、ＳＣＬ２２０の正当性の立証が成功した場合に、要求されたリソース、例えば、特定属性を伴うアプリケーション（ＮＡ、ＧＡ、またはＤＡ）のアクティブ公表を表す、公表されたリソースを作成しようとしてもよい。ＳＣＬ２２０がリソースを公表先ＳＣＬ２３０に公表することを許可されたことを公表先ＳＣＬ２３０が判定する場合、公表先ＳＣＬ２３０は、公表されたリソースデータを含有するようにメモリスペースを生成してデータ投入し、リソースの公表を準備して行うために必要とされる任意の他のステップを講じることを進めるであろう。

ブロック２３１での処理の完了時に、公表先ＳＣＬ２３０は、公表されたリソースの作成が成功したか、または成功しなかったかどうかを示し得る、応答２３２を伝送してもよい。（例えば、ＳＣＬ２２０が公表先ＳＣＬ２３０で登録されていない、ＳＣＬ２２０が公表先ＳＣＬ２３０上で要求されたリソースを作成する権限を与えられていない、または要求２２４に含まれる属性が許容可能ではないため）公表されたリソースが公表先ＳＣＬ２３０で作成されなかった場合、ＳＣＬ２２０は、公表プロシージャのうちのいずれかを行わなくてもよく、いくつかの実施形態では、エラーメッセージを発行元２１０に返信してもよい。公表先ＳＣＬ２３０での公表されたリソースの作成が成功した場合、応答２３２は、公表されたリソースの識別子（例えば、ユニフォームリソース識別子（ＵＲＩ））を含む。

ＳＣＬ２２０はまた、公表２２４を他のＳＣＬにも送信し得、したがって、鎖線のボックス２６０内のステップは、ＳＣＬ２２０が公表されるべきであると判定した全てのＳＣＬにリソースが公表されるまで繰り返され得ることに留意されたい。公表要求２１１に含まれる公表属性リストで特定されない限り、ＳＣＬ２２０は、リソースが公表されるべきであるＳＣＬを判定してもよい。ＳＣＬ２２０はまた、リソースの対応する有効期限を提供してもよい。

既存のＭ２Ｍ公表プロセスと比べた改良として、実施形態では、図１を再度参照すると、ＮＳＣＬ１１１は、公表可能なサブリソースを含む、ＳＣＬリソースを公表するように構成されてもよい。別のＳＣＬ（例えば、ＧＳＣＬ１４１、ＤＳＣＬ１５１）から、またはアプリケーション（例えば、ＮＡ１１２、ＧＡ１４２、ＤＡ１５２）から受信される公表属性リストに基づいて、ＮＳＣＬ１１１は、ｍＩｍ基準点１３０を経由して公表（例えば、作成要求）を送信することによって、ｍＩｍ基準点１３０を介して、リソースをドメイン１２０内のＮＳＣＬ１２１等の公表先ＮＳＣＬに公表してもよい。リソースがＮＳＣＬ１１１によってホストされる（例えば、ＮＡ１１２を起源とするリソース）場合、ＮＳＣＬ１１１は、公表されたリソースを作成し、例えば、検索文字列および元のリソースへのリンクを含有する、公表されたリソースを含む、「リソース公表」要求をＮＳＣＬ１２１に送信してもよい。リソースが別のＳＣＬ（例えば、ＧＳＣＬ１４１、ＤＳＣＬ１５１）によってＮＳＣＬ１１１に公表された場合、リソースは、ＮＳＣＬ１１１での公表されたリソースであり、ＮＳＣＬ１１１は、ＮＳＣＬ１１１によって受信されたリソースを作成する要求を伴った、属性リストに含まれた、公表が行われる特定のＳＣＬのリストに従って、それをＮＳＣＬ１２１に公表してもよい。この属性またはリストは、リソースの「ａｎｎｏｕｎｃｅＴｏ」属性と称され得ることに留意されたい。

ＥＴＳＩＭ２Ｍ仕様は、＜ｓｃｌ＞リソースを記憶するＳＣＬで登録される、遠隔ＳＣＬを表す＜ｓｃｌ＞リソースを定義する。この仕様はさらに、＜ｓｃｌＢａｓｅ＞が位置するＳＣＬ上で登録される全てのＳＣＬ（すなわち、＜ｓｃｌＢａｓｅ＞リソースを記憶するＳＣＬで登録される全てのＳＣＬ）を表す（またはＳＣＬが登録される）、全ての＜ｓｃｌ＞リソースを含有する、集合リソース（すなわち、ゼロまたはそれを上回る他のリソースを表すリソース）「ｓｃｌｓ」を含む、＜ｓｃｌＢａｓｅ＞リソースを記憶するＳＣＬに常駐し、利用可能である、全てのリソース（「サブリソース」と称され得る）を含んだ、ルートリソースである＜ｓｃｌＢａｓｅ＞を画定する。したがって、ＳＣＬの＜ｓｃｌＢａｓｅ＞に登録される各遠隔ＳＣＬは、そのＳＣＬの＜ｓｃｌＢａｓｅ＞リソースの中の＜ｓｃｌ＞リソースによって表される。同様に、各登録先ＳＣＬもまた、登録ＳＣＬの＜ｓｃｌＢａｓｅ＞の中のサブセット＜ｓｃｌ＞リソースとして表される。例えば、図１を再度参照すると、ＥＴＳＩリソース表記を使用して、ＧＳＣＬ１４１がＮＳＣＬ１１１に登録するとき、２つの＜ｓｃｌ＞リソースが作成され、ＧＳＣＬ１４１の中に１つ、すなわち、＜ｓｃｌＢａｓｅ１４１＞／ｓｃｌｓ／＜ｓｃｌ１１１＞リソース、およびＮＳＣＬ１１１に中の１つ、すなわち、＜ｓｃｌＢａｓｅ１１１＞／ｓｃｌｓ／＜ｓｃｌ１４１＞リソースがある。

図３は、図１に関して説明されるもの等のいくつかの実施形態で説明されるＳＣＬを表し得る、例示的＜ｓｃｌ＞リソース３００の構造を図示する。＜ｓｃｌ＞リソース３００は、１つまたはそれを上回る属性３０５と、ゼロまたはそれを上回るサブリソースコンテナ３１０、グループ３１５、アプリケーション３２０、ａｃｃｅｓｓＲｉｇｈｔｓ３２５、購読３３０、ｍｇｍｔＯｂｊｓ３３５、ｎｏｔｉｆｉｃａｔｉｏｎｓＣｈａｎｎｅｌｓ３４０、ｍ２ｍＰｏｃｓ３４５、およびａｔｔａｃｈｅｄＤｅｖｉｃｅｓ３５０のそれぞれを含んでもよい。いくつかの実施形態では、他のサブリソースおよびリソースパラメータが使用されてもよい一方で、他の実施形態では、図３に示されるサブリソースおよびリソースパラメータの全てが使用されるわけではない場合がある。

既存のＭ２Ｍ公表プロシージャへの改良として、実施形態では、＜ｓｃｌ＞リソースの下には、公表されたＳＣＬをそれぞれ表すリソースのセット、および集合リソースが位置するエンティティのものとは異なるネットワークドメイン内にあり得る、利用可能なそのサブリソースを表す、集合リソースも含まれてもよい。この集合リソースは、いくつかの実施形態では、「ｓｃｌＡｎｎｃｓ」と称されてもよい。この集合リソースの実施例は、図３の＜ｓｃｌ＞リソース３００の下でｓｃｌＡｎｎｃｓ３５５として示される。また、属性３０５の間には、この＜ｓｃｌ＞リソース３００の公表が行われるべきであるＳＣＬのリストである、「ａｎｎｏｕｎｃｅＴｏ」属性があってもよい。＜ｓｃｌ＞リソース３００が構成されるＳＣＬは、リソースをａｎｎｏｕｎｃｅＴｏリスト内のＳＣＬに公表しようとするであろう。上記のように、リソースを公表するエンティティのリストが、ｍＩａまたはｄＩａ基準点を経由して受信される公表要求の中で提供されない場合、ローカルＳＣＬが、リソースが公表されるであろう場所を決定するであろう。また、属性３０５の間には、＜ｓｃｌ＞リソース３００を伴って構成されるＳＣＬに登録されるＳＣＬのリストである、「ｒｅｇｉｓｔｅｒｅｄＳｃｌｓ」属性があってもよい。（例えば、図１では、ＧＳＣＬ１４１が、＜ｓｃｌ＞リソース３００を伴って構成されるＮＳＣＬ１１１に登録する場合には、ＧＳＣＬ１４１は、ＮＳＣＬ１１１のｒｅｇｉｓｔｅｒｅｄＳｃｌｓの要素である。）

ｓｃｌＡｎｎｃｓリソース３５５は、それぞれ＜ｓｃｌＡｎｎｃ＞リソースと称され得る、ゼロまたはそれを上回るサブリソース（例えば、ＳＣＬのリソース）を含んでもよい。各＜ｓｃｌＡｎｎｃ＞リソース、すなわち、公表されたＳＣＬリソースは、ＳＣＬのアクティブ公表を表す。ＳＣＬは、ｓｃｌＡｎｎｃｓリソース３５５が構成されるＳＣＬのものとは異なるネットワークドメイン内の登録されたＳＣＬであってもよい。＜ｓｃｌＡｎｎｃ＞リソースは、いくつかの実施形態では、ｍＩｍ基準点を経由した、ＳＣＬから他のＳＣＬへのＳＣＬリソースの公表に使用される。

図４は、図３の例示的＜ｓｃｌ＞リソース３００のｓｃｌＡｎｎｃｓリソース３５５等のｓｃｌＡｎｎｃｓリソースを表すために使用され得る、例示的ｓｃｌＡｎｎｃｓ集合リソース４００のデータ構造を図示する。ｓｃｌＡｎｎｃｓリソース４００は、本明細書で記載される任意の属性または任意の他の属性であり得る、属性４０５を有してもよい。例えば、ｓｃｌＡｎｎｃｓリソース４００の属性４０５は、「ａｃｃｅｓｓＲｉｇｈｔ」リソースと称され得る、アクセス権リソースのＵＲＩを示す、ａｃｃｅｓｓＲｉｇｈｔＩＤ属性を含んでもよい。ａｃｃｅｓｓＲｉｇｈｔＩＤ属性において参照されるａｃｃｅｓｓＲｉｇｈｔリソースで定義される許可は、この属性を含有するリソース（本実施例ではｓｃｌＡｎｎｃｓリソース４００）にアクセスすることが許可されるエンティティ、および果たされ得る機能（例えば、回収、更新、削除等）を判定してもよい。リソースタイプがａｃｃｅｓｓＲｉｇｈｔＩＤ属性定義を有さない場合には、ａｃｃｅｓｓＲｉｇｈｔＩＤ属性定義を有さない子リソースのための親リソースと関連付けられる許可を使用することによって、または固定許可を使用することによって等、他の方法で、そのタイプのリソースの許可が判定されてもよい。

ｓｃｌＡｎｎｃｓリソース４００の属性４０５はまた、ｓｃｌＡｎｎｃｓリソース４００の作成の時間を示す、「作成時間」属性を含んでもよい。ｓｃｌＡｎｎｃｓリソース４００の属性４０５はさらに、ｓｃｌＡｎｎｃｓリソース４００のごく最近の更新または修正の時間を示す、「ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ」属性を含んでもよい。ｓｃｌＡｎｎｃｓリソース４００はまた、ｓｃｌＡｎｎｃｓリソース４００が購読され得るかどうかを示す、購読４１５を含んでもよい。

ｓｃｌＡｎｎｃｓリソース４００はまた、ｓｃｌＡｎｎｃｓリソース４００が構成されるＳＣＬに公表される、異なるネットワークドメイン内にあり得る（遠隔）ＳＣＬのアクティブ公表をそれぞれ表す、ゼロまたはそれを上回るサブリソース＜ｓｃｌＡｎｎｃ＞４１０を含んでもよい。

図５は、図４の例示的ｓｃｌＡｎｎｃｓリソース４００の＜ｓｃｌＡｎｎｃ＞リソース４１０等の＜ｓｃｌＡｎｎｃ＞リソースを表し得る、例示的＜ｓｃｌＡｎｎｃ＞リソース５００のデータ構造を図示する。このリソースは、別のネットワークドメイン内の登録されたＳＣＬのアクティブ公表を表す。本明細書で説明される、改良型ドメインツードメイン公表能力によると、例えば、ｍＩｍ基準点（例えば、図１のｍＩｍ１３０）を経由して公表を伝送するために、＜ｓｃｌＡｎｎｃ＞リソース５００が使用されてもよい。

＜ｓｃｌＡｎｎｃ＞リソース５００は、属性５０５と、ゼロまたはそれを上回る＜ｃｏｎｔａｉｎｅｒＡｎｎｃ＞リソースを含有し得るサブリソースコンテナ５１０、＜ｇｒｏｕｐＡｎｎｃ＞リソースを含有し得るグループ５１５、別のＳＣＬの中の登録されたアプリケーションのアクティブ公表を表し得、元のリソースへのリンクを維持し得る、＜ａｐｐｌｉｃａｉｔｏｎＡｎｎｃ＞リソースを含有し得るアプリケーション５２０、およびそれぞれが集合リソースであり得る、＜ａｃｃｅｓｓＲｉｇｈｔＡｎｎｃ＞リソースを含有し得るａｃｃｅｓｓＲｉｇｈｔｓ５２５とを含有してもよい。これらのサブリソースのそれぞれは、＜ｓｃｌＡｎｎｃ＞リソース５００にリンクされる寿命および範囲を有してもよい。例えば、公表された＜ｓｃｌＡｎｎｃ＞リソース５００の子孫として作成される各リソースは、＜ｓｃｌＡｎｎｃ＞リソース５００と関連付けられるＳＣＬが公表解除されるとき、またはＳＣＬの公表が満了するときに、自動的に削除されてもよい。公表ＳＣＬは、公表されるリソースと同期化されるリソースと関連付けられる、ａｃｃｅｓｓＲｉｇｈｔＩＤおよび任意のｓｅａｒｃｈＳｔｒｉｎｇｓ（リソースを発見するための鍵として使用されるトークン）を保ってもよい。

コンテナ５１０は、＜ｃｏｎｔａｉｎｅｒＡｎｎｃ＞リソースのゼロまたはそれを上回る表現を含有してもよく、それぞれ、その下に＜ｓｃｌＡｎｎｃ＞リソース５００および＜ｓｃｌＡｎｎｃ＞リソース５００の親ｓｃｌＡｎｎｃｓリソースが位置する、＜ｓｃｌ＞リソースによって表されるＳＣＬに位置するコンテナを表す。グループ５１５は、＜ｇｒｏｕｐＡｎｎｃ＞リソースのゼロまたはそれを上回る表現を含有してもよく、それぞれ、その下に＜ｓｃｌＡｎｎｃ＞リソース５００および＜ｓｃｌＡｎｎｃ＞リソース５００の親ｓｃｌＡｎｎｃｓリソースが位置する、＜ｓｃｌ＞リソースによって表されるＳＣＬに位置するグループリソースを表してもよい。アプリケーション５２０は、＜ａｐｐｌｉｃａｔｉｏｎＡｎｎｃ＞リソースのゼロまたはそれを上回る表現を含有してもよく、それぞれ、その下に＜ｓｃｌＡｎｎｃ＞リソース５００および＜ｓｃｌＡｎｎｃ＞リソース５００の親ｓｃｌＡｎｎｃｓリソースが位置する、＜ｓｃｌ＞リソースによって表されるＳＣＬに位置するアクティブアプリケーションを表してもよい。ＡｃｃｅｓｓＲｉｇｈｔｓ５２５は、＜ａｃｃｅｓｓＲｉｇｈｔＡｎｎｃ＞リソースのゼロまたはそれを上回る表現を含有してもよく、それぞれ、別のＳＣＬの中の＜ａｃｃｅｓｓＲｉｇｈｔ＞リソースを表し、元のリソースへのリンクを含んでもよい。表されたＳＣＬは、その下に＜ｓｃｌＡｎｎｃ＞リソース５００および＜ｓｃｌＡｎｎｃ＞リソース５００の親ｓｃｌＡｎｎｃｓリソースが位置する、＜ｓｃｌ＞リソースによって表されるＳＣＬにアクセスすることが許可される、エンティティであってもよい。

属性５０５は、公表され、＜ｓｃｌＡｎｎｃ＞リソース５００と関連付けられるリソースを参照するリンクである、リンク属性を含んでもよい。このリンクは、発見プロセス中に提供される参照であってもよい。属性５０５はまた、本明細書で説明されるようなアクセス権リソースのＵＲＩを示す、ａｃｃｅｓｓＲｉｇｈｔＩＤ属性を含んでもよい。属性５０５はまた、本明細書で説明されるように、関連リソースが公表されるべきであるＳＣＬのリストであり得る、ａｎｎｏｕｎｃｅＴｏ属性を含んでもよい。属性５０５はまた、リソースを発見するための鍵として使用され得るトークンを提供する、ｓｅａｒｃｈＳｔｒｉｎｇｓ属性を含んでもよい。属性５０５はさらに、その後に、それがホストされるＳＣＬによって＜ｓｃｌＡｎｎｃ＞リソース５００が削除されるであろう、時間（いくつかの実施形態では絶対時間）を定義するｅｘｐｉｒａｔｉｏｎＴｉｍｅ属性を含んでもよい。

ＥＴＳＩ表記を使用して、図１を再度参照すると、ＧＳＣＬ１４１がＮＳＣＬ１１１によってＮＳＣＬ１２１に公表される場合、（すなわち、ＧＳＣＬ１４１リソースのアクティブ公表を表す、公表されたＳＣＬリソースとしての）ＧＳＣＬ１４１への公表は、＜ｎｓｃｌ１２１Ｂａｓｅ＞／ｓｃｌｓ／＜ｎｓｃｌ１１１＞／ｓｃｌＡｎｎｃｓ／＜ｇｓｃｌ１４１Ａｎｎｃ＞として表されてもよい。

実施形態では、図１を参照すると、ＳＣＬおよびアプリケーションリソースを公表する公表が、ＮＳＣＬ１１１によって、ｍＩｍを経由してＮＳＣＬ１２１に送信されてもよい。そのような公表は、ＳＣＬおよびサブリソースのアクティブ公表を表す、ｓｃｌＡｎｎｃｓ集合リソースおよび＜ｓｃｌＡｎｎｃ＞リソースを使用して行われるべきである。ＮＳＣＬ１１１およびＮＳＣＬ１２１が相互に登録するとき、＜ｓｃｌ＞リソースがそれぞれの上で作成される（例えば、＜ｎｓｃｌ１１１Ｂａｓｅ＞／ｓｃｌｓ／＜ｎｓｃｌ１２１＞がＮＳＣＬ１１１で作成され、＜ｎｓｃｌ１２１Ｂａｓｅ＞／ｓｃｌｓ／＜ｎｓｃｌ１１１＞がＮＳＣＬ１２１で作成される）。公表されたＳＣＬは、登録後に作成される＜ｓｃｌ＞リソースの下に記憶されてもよい。例えば、ＮＳＣＬ１１１がＮＳＣＬ１２１に登録すると、ＧＳＣＬ１４１（ＮＳＣＬ１１１に登録される）は、任意のＳＣＬに、または少なくともＮＳＣＬ１２１に公表され得ることをＧＳＣＬ１４１が示した場合、ｍＩｍ基準点１３０を経由してＮＳＣＬ１２１に公表されてもよい。ＥＴＳＩ表記を使用して、公表されたＧＳＣＬ１４１リソース（すなわち、ＧＳＣＬ１４１リソースのアクティブ公表の表現）は、＜ｎｓｃｌ１２１Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ１１１＞／ｓｃｌＡｎｎｃｓ／＜ｇｓｃｌ１４１Ａｎｎｃ＞として、＜ｎｓｃｌ１２１Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ１１１＞／ｓｃｌＡｎｎｃｓ／の下に記憶される＜ＧＳＣＬ１４１Ａｎｎｃ＞であってもよい。いったんＮＳＣＬ１２１に公表されると、公表されたＧＳＣＬ１４１リソースは、ドメイン１２０内のエンティティに利用可能であり得る。

ＮＳＣＬ１１１等の公表ＮＳＣＬが、同一のリソースを、ネットワークドメイン１７０内のＮＳＣＬ１７１およびネットワークドメイン１８０内のＮＳＣＬ１８１等の複数の他のＮＳＣＬに公表してもよい。いったんＮＳＣＬに公表されると、公表されたリソースは、ドメイン１７０および１８０内のエンティティに、ならびにドメイン１１０内のエンティティの代わりに、利用可能であり得る。公表属性リストで特定されない限り、ＮＳＣＬ１１１は、どのＳＣＬに公表するかを決定してもよい。ＮＳＣＬ１１１上でホストされるリソースについて、ＮＳＣＬ１１１はまた、有効期限を提供してもよい。ＮＳＣＬ１１１に公表される（すなわち、ＮＳＣＬ１１１上でホストされない）リソースについて、ＮＳＣＬ１１１は、属性として、対応するリソースの公表において受信される有効期限を使用してもよい。

実施形態では、公表先ＮＳＣＬ１２１は、ＮＳＣＬ１１１からＳＣＬリソースの公表を受信し、特定属性を伴う公表されたＳＣＬリソース（例えば、＜ｇｓｃｌ１４１Ａｎｎｃ＞）を作成してもよい。リソースのために定義されるａｃｃｅｓｓＲｉｇｈｔに従って、ＮＳＣＬ１１１が子リソースを作成する権限を与えられていることを公表して、作成が許可されてもよい。作成が成功した場合、公表先ＮＳＣＬ１２１は、作成された公表ＳＣＬリソースの識別子（例えば、ＵＲＩ）を含み得る、成功を示す応答をＮＳＣＬ１２１に返信してもよい。作成が成功しなかった場合、ＮＳＣＬ１２１は、エラーメッセージをＮＳＣＬ１１１に返信してもよい。

図６は、図３−５に関して上記で説明されるように、データ構造およびそのような構造の要素を使用し得る、ドメインにわたってリソースを公表するためのリソース公表プロシージャの実施形態の信号フローを図示する。本実施形態では、公表発行元６１０は、限定されないが、本明細書で説明されるようなＮＡ、ＧＡ、またはＤＡ等のアプリケーションである。公表発行元６１０は、ｍＩａまたはｄＩａ基準点６４０を介して、公表要求６１１をドメイン１内のＮＳＣＬ６２０に伝送してもよい。代替として、公表発行元６１０は、ホスティングＳＣＬ（例えば、ＤＡをホストするＤＳＣＬ、またはＧＡをホストするＧＳＣＬ）を介して公表要求６１１をＮＳＣＬ６２０に送信する、アプリケーションであってもよい。そのような実施形態では、公表要求は、最初にｍＩａ／ｄＩａインターフェースを介してホスティングＳＣＬに送信されてもよく、ホスティングＳＣＬは、ｍＩｄインターフェースを介して公表要求をＮＳＣＬ６２０に伝送してもよい。公表要求６１１は、ＮＳＣＬ６２０への発行元６１０の登録時に生成される、作成要求であってもよい。代替として、公表要求６１１は、ＮＳＣＬ６２０上で発行元６１０のための新しいリソース（すなわち、ＮＳＣＬ６２０上で発行元６１０のために以前に作成されていないリソース）の作成を要求する、作成要求であってもよい。別の代替案では、公表要求６１１は、ＮＳＣＬ６２０上で発行元６１０のための既存のリソース（すなわち、発行元６１０のためのＮＳＣＬ６２０によってすでにホストされているリソース）の更新を要求する、「更新」要求であってもよい。

公表要求６１１は、それぞれ、図３、４、および５の属性３０５、４０５、および５０５について説明されるもの等の本明細書で説明されるような公表属性のうちのいずれかの１つまたはそれを上回るものを含む、公表属性リストを含んでもよい。公表属性リストは、発行元６１０がＮＳＣＬ６２０上で作成を要求し得る、全ての公表可能なリソースに適用可能であり得る。ＮＳＣＬ６２０への登録時に発行元６１０によって提供される属性リストは、発行元６１０のデフォルト公表属性リストと称されてもよい。発行元６１０の公表可能なリソースはまた、独自の公表属性リストを提供してもよく、その場合、発行元６１０のデフォルト公表属性リストは、その特定のリソースに使用されなくてもよい。発行元６１０によるデフォルト公表属性リストへの更新または変更は、ＮＳＣＬ６２０上の以前に作成された公表可能なリソースに伝搬されないが、発行元６１０の任意の新しい公表可能なリソースが、更新されたデフォルト公表属性リストを使用して要求されてもよい。ＮＳＣＬ６２０上の既存のリソースの属性を変更するために、発行元６１０は、更新された公表属性リストを含む、リソースのための更新をＳＣＬ６２０に伝送してもよい。

ＮＳＣＬ６２０は、例えば、発行元６１０がａｃｃｅｓｓＲｉｇｈｔｓリスト上にあると判定することによって、本明細書で説明される方法を使用して、受信した公表要求６１１の正当性を立証してもよい。（例えば、発行元６１０がＮＳＣＬ６２０で登録されていない、発行元６１０がＮＳＣＬ６２０上で要求されたリソースを作成または更新する権限を与えられていない、または公表要求６１１に含まれる属性が許容可能ではないため）正当性が立証されない場合、ＮＳＣＬ６２０は、公表プロシージャのうちのいずれも行わなくてもよく、いくつかの実施形態では、エラーメッセージを発行元６１０に返信してもよい。正当性が立証された場合、ブロック６２１で、ＮＳＣＬ６２０は、リソースを作成または更新してもよい。公表要求６１１の中で提供される属性がない場合、ＮＳＣＬ６２０は、新しい要求されたリソースを作成する際に、発行元６１０のための現在のデフォルト公表属性リストを使用してもよい。応答６２２が、ｍＩａまたはｄＩａ基準点６４０を介して発行元６１０に伝送されてもよい。応答６２２は、発行元６１０がＮＳＣＬ６２０上でリソースの作成を要求する権限を与えられていることを確認してもよい。ＮＳＣＬ６２０は、公表プロシージャの完了に先立って、または完了後に、この応答を送信してもよい。

発行元６１０が、公表要求６１１において、ＮＳＣＬ６２０が公表するべきであるＳＣＬを示さない、実施形態では、ＮＳＣＬ６２０は、以下で説明される公表プロシージャの完了に先立って、応答６２２を発行元６１０に送信することに留意されたい。本実施形態では、ＮＳＣＬ６２０は、いつ、およびどのＳＣＬにリソースを公表するかを決定する。公表要求６１１が、ＮＳＣＬ６２０が公表するべきであるＳＣＬを示す、別の実施形態では、ＮＳＣＬ６２０は、リソースを全ての示されたＳＣＬに公表することを完了した後に、ｍＩａまたはｄＩａ基準点６４０を介して応答６２２を発行元６１０に送信する。本実施形態では、応答６２２は、公表されたリソースの状態（すなわち、リソースが示されたＳＣＬのそれぞれで作成されることに成功したかどうか）を発行元６１０に示してもよい。本実施形態では、応答６２２は、公表されることに成功したＳＣＬのリストを含んでもよい。別の実施形態では、公表要求６１１は、確認が必要とされないことを示してもよく、したがって、本実施形態では、応答６２２が送信されなくてもよい。公表要求６１１が作成要求よりもむしろ更新要求であり、確認が必要とされないという指標が公表要求６１１に含まれる、他の実施形態では、応答６２２が送信されないが、公表要求６１１が作成要求であるときは、関係なく応答６２２が伝送される。

公表要求６１１が有効であるという判定に応答して、ＮＳＣＬ６２０は、ブロック６２３で公表プロシージャ処理を継続し、いつ、およびどのＳＣＬに、発行元６１０によって公表される、新たに作成または更新されたリソースを公表するかを判定してもよい。

公表６２４が、基準点ｍＩｍ６５０を介して、ＮＳＣＬ６２０のもの（ドメイン１）とは異なるドメイン（ドメイン２）内の公表先ＮＳＣＬ６３０に伝送されてもよい。公表６２４は、発行元６１０によって公表されるリソースのアクティブ公表を表す、公表されたリソースの作成を要求する、作成要求であってもよい。公表６２４は、公表先ＮＳＣＬ２３０が、本明細書で説明されるように、検索文字列および元のリソースへのリンクを含み得る、公表されたリソースを作成することを要求する。

公表先ＮＳＣＬ６３０は、実施形態では、公表要求６１１の正当性を立証するためにＮＳＣＬ６２０によって使用されるプロセスと同様に、公表６２４の正当性を立証してもよいが、検証の代替的な方法を使用する他の実施形態が、本開示の範囲内と考慮される。実施形態では、ＮＳＣＬ６２０が、リソースを公表先ＮＳＣＬ６３０に公表する権限を与えられたエンティティの公表先ＮＳＣＬ６３０のａｃｃｅｓｓＲｉｇｈｔリストに含まれる場合のみ、リソースの作成が許可されてもよい。

ブロック６３１では、公表先ＮＳＣＬ６３０は、ＮＳＣＬ６２０の正当性の立証が成功した場合に、特定属性を伴う要求されたリソースを作成しようとしてもよい。

ブロック６３１での処理の完了時に、公表先ＮＳＣＬ６３０は、公表されたリソースの作成が成功したか、または成功しなかったかどうかを示し得る、応答６３２を伝送してもよい。（例えば、ＮＳＣＬ６２０が公表先ＮＳＣＬ６３０で登録されていない、ＮＳＣＬ６２０が公表先ＮＳＣＬ６３０上で要求されたリソースを作成する権限を与えられていない、または要求６２４に含まれる属性が許容可能ではないため）公表されたリソースが公表先ＮＳＣＬ６３０で作成されなかった場合、ＮＳＣＬ６２０は、公表プロシージャのうちのいずれかを行わなくてもよく、いくつかの実施形態では、応答６３２でエラーメッセージを発行元６１０に返信してもよい。公表先ＮＳＣＬ６３０でのリソースの作成が成功した場合、応答６３２は、リソースの識別子（例えば、ユニフォームリソース識別子（ＵＲＩ））を含んでもよい。

ＮＳＣＬ６２０はまた、公表６２４を他のＮＳＣＬにも送信し得、したがって、鎖線のボックス６６０内のステップは、公表要求６１１において公表される必要があるリソースが、ＮＳＣＬ６２０が公表されるべきであると判定した全てのＳＣＬに公表されるまで、繰り返され得ることに留意されたい。公表要求６１１に含まれる公表属性リストで特定されない限り、ＮＳＣＬ６２０は、リソースが公表されるべきであるＳＣＬを判定してもよい。ＮＳＣＬ６２０はまた、リソースの対応する有効期限を提供してもよい。

図７は、図３−５に関して上記で説明されるように、データ構造およびそのような構造の要素を使用し得る、ＳＣＬを公表するためのＳＣＬ公表プロシージャの実施形態の信号フローを図示する。本実施形態では、公表発行元７１０は、限定されないが、本明細書で説明されるようなＤＳＣＬまたはＧＳＣＬ等のＳＣＬである。公表発行元７１０は、ｍＩｄ基準点７４０を介して、ＳＣＬリソースをドメイン１内のＮＳＣＬ７２０に公表するように、公表要求７１１を伝送してもよい。この要求は、ＮＳＣＬ７２０への発行元７１０の登録時に生成される、作成要求であってもよい。代替として、公表要求７１１は、ＮＳＣＬ７２０上で発行元７１０のための新しいリソース（すなわち、ＮＳＣＬ７２０上で発行元７１０のために以前に作成されていないリソース）の作成を要求する、作成要求であってもよい。別の代替案では、公表要求７１１は、ＮＳＣＬ７２０上で発行元７１０のための既存のリソース（すなわち、発行元７１０のためのＮＳＣＬ７２０によってすでにホストされているリソース）の更新を要求する、「更新」要求であってもよい。

公表要求７１１は、それぞれ、図３、４、および５の属性３０５、４０５、および５０５について説明されるもの等の本明細書で説明されるような公表属性のうちのいずれかの１つまたはそれを上回るものを含む、公表属性リストを含んでもよい。公表属性リストは、ＮＳＣＬ７２０によって公表されるＳＣＬ発行元７１０の全ての公表に適用可能であり得る。発行元７１０は、独自の公表属性リストを提供してもよい。発行元７１０による公表属性リストへの更新または変更は、ＮＳＣＬ７２０に自動的に伝搬されなくてもよいが、そのような変更は、更新された公表属性リストを含む、ＳＣＬ７２０への更新の伝送によって、ＮＳＣＬ７２０に提供されてもよい。

ＮＳＣＬ７２０は、例えば、発行元７１０がａｃｃｅｓｓＲｉｇｈｔｓリスト上にあると判定することによって、本明細書で説明される方法を使用して、受信した公表要求７１１の正当性を立証してもよい。（例えば、発行元７１０がＮＳＣＬ７２０で登録されていない、発行元７１０がＮＳＣＬ７２０上で要求されたＳＣＬを作成する権限を与えられていない、または公表要求７１１に含まれる属性が許容可能ではないため）正当性が立証されない場合、ＮＳＣＬ７２０は、公表プロシージャのうちのいずれも行わなくてもよく、いくつかの実施形態では、エラーメッセージを発行元７１０に返信してもよい。正当性が立証された場合、ブロック７２１で、ＮＳＣＬ７２０は、ＮＳＣＬ７２０に記憶されたＳＣＬリソース（例えば、ＤＳＣＬリソースまたはＧＳＣＬリソース）を作成または更新してもよい。公表要求７１１の中で提供される属性がない場合、ＮＳＣＬ７２０は、新しい要求されたＳＣＬを作成する際に、発行元７１０のための現在のデフォルト公表属性リストを使用してもよい。応答７２２が、ｍＩｄ基準点７４０を介して発行元７１０に伝送されてもよい。応答７２２は、発行元７１０がＮＳＣＬ７２０上でＳＣＬの作成または更新を要求する権限を与えられていることを確認してもよい。ＮＳＣＬ７２０は、公表プロシージャの完了に先立って、または完了後に、この応答を送信してもよい。

発行元７１０が、公表要求７１１において、ＮＳＣＬ７２０が公表するべきであるＳＣＬを示さない、実施形態では、ＮＳＣＬ７２０は、以下で説明されるｍＩｍ基準点７５０上の公表プロシージャの完了に先立って、（ｍＩｄ基準点７４０を介して）応答７２２を発行元７１０に送信することに留意されたい。本実施形態では、ＮＳＣＬ７２０は、いつ、およびどのＳＣＬにリソースを公表するかを決定する。発行元７１０が、ＮＳＣＬ７２０が公表するべきであるＳＣＬを示す、別の実施形態では、ＮＳＣＬ７２０は、ＳＣＬを全ての示されたＳＣＬに公表することを完了した後に、ｍＩｄ基準点７４０を介して応答７２２を発行元７１０に送信する。本実施形態では、応答７２２は、公表される必要があるＳＣＬリソースの状態（すなわち、ＳＣＬリソースが示されたＳＣＬのそれぞれで作成されることに成功したかどうか）を発行元７１０に示してもよい。本実施形態では、応答７２２は、公表されることに成功したＳＣＬのリスト（すなわち、公表先ＳＣＬのリスト）を含んでもよい。別の実施形態では、公表要求７１１は、確認が必要とされないことを示してもよく、したがって、本実施形態では、応答７２２が送信されなくてもよい。公表要求７１１が作成要求よりもむしろ更新要求であり、確認が必要とされないという指標が公表要求７１１に含まれる、他の実施形態では、応答７２２が送信されないが、公表要求７１１が作成要求であるときは、関係なく応答７２２が伝送される。

公表要求７１１が有効であるという判定に応答して、ＮＳＣＬ７２０は、ブロック７２３で公表プロシージャ処理を継続し、いつ、およびどのＳＣＬに、新たに作成または更新されたリソースを公表するかを判定してもよい。

公表７２４が、基準点ｍＩｍ７５０を介して、ＮＳＣＬ７２０のもの（ドメイン１）とは異なるドメイン（ドメイン２）内の公表先ＮＳＣＬ７３０に伝送されてもよい。公表７２４は、発行元７１０によって公表される必要があるＳＣＬリソース（例えば、ＤＳＣＬまたはＧＳＣＬ）のアクティブ公表を表し得る、公表先ＮＳＣＬ７３０で公表されたＳＣＬリソースを作成する作成要求であってもよい。公表されたＳＣＬリソースは、図５に示されるような＜ｓｃｌＡｎｎｃ＞リソースを伴って構成されてもよく、本明細書で説明されるように、元のリソースへのリンク、ならびに有効期限、ａｃｃｅｓｓＲｉｇｈｔ情報、および／または検索文字列を含んでもよい。

公表先ＮＳＣＬ７３０は、実施形態では、公表要求７１１の正当性を立証するためにＮＳＣＬ７２０によって使用されるプロセスと同様に、公表７２４の正当性を立証してもよいが、検証の代替的な方法を使用する他の実施形態が、本開示の範囲内と考慮される。実施形態では、ＮＳＣＬ７２０が、ＳＣＬを公表先ＮＳＣＬ７３０に公表する権限を与えられたエンティティの公表先ＮＳＣＬ７３０のａｃｃｅｓｓＲｉｇｈｔリストに含まれる場合のみ、公表されたＳＣＬリソースの作成が許可されてもよい。

ブロック７３１では、公表先ＮＳＣＬ７３０は、ＮＳＣＬ７２０の正当性の立証が成功した場合に、特定属性を伴う要求された公表ＳＣＬリソースを作成しようとしてもよい。そのような属性、および公表先ＮＳＣＬ７３０によってリソースのために構成される他のデータは、元のリソースへのリンク、有効期限、ａｃｃｅｓｓＲｉｇｈｔ情報、および／または検索文字列等の公表７２４の中で提供されるデータを含んでもよい。

ブロック７３１での処理の完了時に、公表先ＮＳＣＬ７３０は、公表されたＳＣＬリソースの作成が成功したか、または成功しなかったかどうかを示し得る、応答７３２を伝送してもよい。（例えば、ＮＳＣＬ７２０が公表先ＮＳＣＬ７３０で登録されていない、ＮＳＣＬ７２０が公表先ＮＳＣＬ７３０上で公表されたＳＣＬリソースを作成する権限を与えられていない、または要求７２４に含まれる属性が許容可能ではないため）公表されたＳＣＬリソースが公表先ＮＳＣＬ７３０で作成されることに成功しなかった場合、ＮＳＣＬ７２０は、公表プロシージャのうちのいずれかを行わなくてもよく、いくつかの実施形態では、エラーメッセージを発行元７１０に返信してもよい。公表先ＮＳＣＬ７３０での公表されたＳＣＬリソースの作成が成功した場合、応答７３２は、公表されたＳＣＬの識別子（例えば、ユニフォームリソース識別子（ＵＲＩ））を含む。作成が成功しなかった場合、応答７３２は、エラーメッセージであってもよい。

ＮＳＣＬ７２０はまた、公表７２４を他のＮＳＣＬにも送信し得、したがって、鎖線のボックス７６０内のステップは、発行元７１０によって公表される必要があるＳＣＬリソースが、ＮＳＣＬ７２０が公表されるべきであると判定した全てのＳＣＬに公表されるまで、繰り返され得ることに留意されたい。図７に関して説明される例示的実施形態では、ＳＣＬリソースは、ｍＩｍ基準点を経由して、１つのＮＳＣＬから別のＮＳＣＬに公表される。しかしながら、他の実施形態では、ＳＣＬリソースが、ＧＳＣＬ、ＤＳＣＬの間、または異なるタイプのＳＣＬの任意の組み合わせの間等の他のタイプのＳＣＬの間で公表される、＜ｓｃｌＡｎｎｃ＞リソース構成（例えば、図３、４、および５参照）を利用する、類似ＳＣＬリソース公表機構が使用されてもよい。公表要求７１１に含まれる公表属性リストで特定されない限り、ＮＳＣＬ７２０は、ＳＣＬリソースが公表されるべきであるＳＣＬを判定してもよい。ＮＳＣＬ７２０はまた、リソースの対応する有効期限を提供してもよい。

図８は、図３−５に関して上記で説明されるように、データ構造およびそのような構造の要素を使用し得る、ドメインにわたって以前に公表されたリソース（例えば、図６および図７に関して説明される方法を通して作成される、公表されたリソース）を更新するためのリソース公表プロシージャの実施形態の信号フローを図示する。リソースへの変更または更新は、ｍＩｄ、ｄＩａ、またはｍＩａ基準点のうちのいずれかを経由して、ドメイン１内の公表ＮＳＣＬ８２０によって受信されてもよい。公表ＮＳＣＬ８２０は、ブロック８２１で、リソースを最初に記憶してもよく、または以前の更新に続いて、更新されたリソースを記憶してもよい。ブロック８２３では、ＮＳＣＬ８２０は、リソースを更新するトリガを検出してもよい。このトリガは、ｓｅａｒｃｈＳｔｒｉｎｇｓまたはａｃｃｅｓｓＲｉｇｈｔＩＤ属性の変更等の元のリソースの属性の変更によって生成されてもよい。この変更は、リソースの発行元から更新を受信することによって、または任意の他の手段によって、検出されてもよい。

トリガの検出に応答して、ＮＳＣＬ８２０は、更新要求８２４を生成し、ｍＩｍ基準点８５０を介して、要求８２４をドメイン２内の公表先ＮＳＣＬ８３０に送信してもよい。いくつかの実施形態では、リソースを最初に公表した公表ＮＳＣＬのみが、公表されたリソースを更新することを許可され得ることに留意されたい。

要求８２４の受信時に、公表先ＮＳＣＬ８３０は、本明細書で記載される任意の方法または手段を使用して、受信した要求の正当性を立証してもよく、次いで、検証の成功時に、ブロック８３１で、要求８２４で特定される属性を用いて、公表されたリソースを更新してもよい。公表されたリソースの更新が成功した場合、ＮＳＣＬ８３０は、ｍＩｍ基準点８５０を介して、公表された（ＳＣＬ）リソースの成功した更新を示す応答８３２をＮＳＣＬ８２０に伝送してもよい。そうでなければ、ＮＳＣＬ８３０は、ｍＩｍ基準点８５０を介して、リソースの更新が成功しなかったことを示す応答８３２をＮＳＣＬ８２０に伝送してもよい。

いくつかの実施形態では、リソースは、１つまたはそれを上回るＳＣＬから除去されるか、または「公表解除される」必要があり得る。図９は、図３−５に関して上記で説明されるように、データ構造およびそのような構造の要素を使用し得る、ドメインにわたって以前に公表されたリソースを公表解除するためのリソース公表解除プロシージャの実施形態の信号フローを図示する。図９に関して説明される例示的実施形態は、ＳＣＬリソースを含む、任意のタイプのリソースを公表解除するために使用され得ることに留意されたい。リソースが削除されたため、リソースの満了（すなわち、リソースのｅｘｐｉｒａｔｉｏｎＴｉｍｅ属性の中で提供される時間に到達した）の結果として、またはｍＩｄ、ｄＩａ、またはｍＩａ基準点９４０のうちのいずれかを経由して受信される、発行元９１０から更新要求９１１において受信されるリソースのための公表属性リストへの変更（すなわち、以前に公表されるものであったＳＣＬの除去）の結果として、ドメイン１内のＮＳＣＬ９２０は、リソースが公表解除されるものであると判定してもよい。別の実施形態では、公表解除要求９１１は、発行元９１０から受信されるリソース削除要求であってもよい。ＮＳＣＬ９２０は、本明細書で記載される任意の手段または方法を使用して、あるいは別様に、公表解除要求９１１の正当性を立証してもよい。

公表解除要求９１１の正当性の立証が成功しなかった場合、ＮＳＣＬ９２０は、公表解除要求９１１の正当性が立証されなかったことを発行元９１０に知らせる応答９２２を発行元９１０に送信してもよい。これは、エラーメッセージの形態を成してもよい。公表解除要求９１１の正当性の立証が成功した場合、公表ＮＳＣＬ９２０は、リソースがＮＳＣＬ９２０から削除されるものであれば、ブロック９２１でリソースを削除してもよい。代替として、リソースが、ＳＣＬのサブセットから削除されるのみであるか、またはＳＣＬのサブセットによってもはや公表されなくなる場合、ＮＳＣＬ９２０は、公表解除要求をそのようなＳＣＬに伝送してもよい。公表ＮＳＣＬ９２０はまた、または代わりに、例えば、公表解除される必要があるリソースの公表属性リストを更新することによって、ブロック９２１で、リソースのための公表属性リストを更新してもよい。発行元９１０が、公表解除要求９１１において要求される公表解除動作を行う権限を与えられていることを確認する、応答９２２が、発行元９１０に送信されてもよい。応答９２２は、公表解除プロシージャの完了に先立って、または公表解除プロシージャが完了した後に送信され得ることに留意されたい。

ブロック９２３では、ＮＳＣＬ９２０は、リソースが公表解除されるＳＣＬ（すなわち、公表先ＳＣＬ）を判定し、基準点ｍＩｍ９５０を介して、公表解除９２４を、ＮＳＣＬ９２０のもの（ドメイン１）とは異なるドメイン（ドメイン２）内にあり得る公表先ＮＳＣＬ９３０に伝送してもよい。公表解除９２４は、公表解除９１１の中の削除要求に基づいて公表された（いくつかの実施形態ではＳＣＬ）リソースの削除を要求する、削除要求、または公表解除される必要があるリソースの公表属性リストから公表先ＮＳＣＬ９３０を除去する、要求９１１の中の更新要求であってもよい。

公表先ＮＳＣＬ９３０は、本明細書で開示される任意の手段または方法を使用して、あるいは別様に、公表解除９２４の正当性を立証してもよい。ブロック９３１では、公表先ＮＳＣＬ９３０は、公表解除９２４の正当性の立証が成功した場合にリソースを削除しようとしてもよい。

ブロック９３１での処理の完了時に、公表先ＮＳＣＬ９３０は、リソースの削除が成功したか、または成功しなかったかどうかを示し得る、応答９３２を伝送してもよい。（例えば、ＮＳＣＬ９２０が公表先ＮＳＣＬ９３０で登録されていない、ＮＳＣＬ９２０が公表先ＮＳＣＬ９３０上で要求されたリソースを削除する権限を与えられていない、または要求９２４に含まれる属性が許容可能ではないため）リソースが公表先ＮＳＣＬ９３０から削除されることに成功しなかった場合、ＮＳＣＬ９３０は、リソースを削除しなくてもよく、エラーメッセージを含有する応答９３２をＮＳＣＬ９２０に返信してもよい。公表先ＮＳＣＬ９３０でのリソースの削除が成功した場合、応答は、リソースの成功した削除をＮＳＣＬ９２０に確認してもよい。

ＮＳＣＬ９２０はまた、公表解除９２４を他のＮＳＣＬにも送信し得、したがって、鎖線のボックス９６０内のステップは、ＮＳＣＬ９２０が公表解除されるべきであると判定した全てのＮＳＣＬにリソースが公表解除されるまで、繰り返され得ることに留意されたい。図９に関して説明される例示的実施形態では、（ＳＣＬまたは別様の）リソースは、ｍＩｍ基準点を使用して、２つのＮＳＣＬの間で公表解除される。しかしながら、他の実施形態では、ＳＣＬリソースが、ＧＳＣＬ、ＤＳＣＬの間、または異なるタイプのＳＣＬの任意の組み合わせの間等の他のタイプのＳＣＬの間で公表解除される、＜ｓｃｌＡｎｎｃ＞リソース構成（例えば、図３、４、および５参照）を利用する、類似リソース公表解除機構が使用されてもよい。

図１０は、実施形態による、リソースとして＜ｓｃｌＡｎｎｃ＞（例えば、図３、４、および５参照）を利用するＳＣＬリソースの公表を実証する、例示的な信号フロー１０００を図示する。ネットワークドメイン１０１０内には、ＤＡ１０１１、ＧＳＣＬ１０１２、ＮＡ１０１３、およびＮＳＣＬ１０１４があってもよい。ネットワークドメイン１０２０内には、ＤＡ１０２１、ＧＳＣＬ１０２２、ＮＡ１０２３、およびＮＳＣＬ１０２４があってもよい。本実施例では、ＧＳＣＬ１０１２は、ドメイン１０２０内のエンティティに発見可能にされるであろう。ブロック１０３１では、ＮＳＣＬ１０１４がＮＳＣＬ１０２４に登録し、ＮＳＣＬ１０２４がＮＳＣＬ１０１４に登録する。ＮＳＣＬ１０２４がＮＳＣＬ１０１４に登録するとき、ＮＳＣＬ１０１４によって作成されている登録されたＮＳＣＬ１０２４を表す＜ｓｃｌ＞リソースである、ＮＳＣＬ１０１４で作成された＜ＮＳＣＬ １０２４＞リソースがある（すなわち、＜ＮＳＣＬ １０１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ １０２４＞）。同様に、ＮＳＣＬ１０１４がＮＳＣＬ１０２４に登録するとき、ＮＳＣＬ１０２４によって作成されている登録されたＮＳＣＬ１０１４を表す＜ｓｃｌ＞リソースである、ＮＳＣＬ１０２４で作成された＜ＮＳＣＬ １０１４＞リソースがある（すなわち、＜ＮＳＣＬ １０２４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ １０１４＞）。

ブロック１０３２では、ＧＳＣＬ１０１２がＮＳＣＬ１０１４に登録する。それに応答して、ＮＳＣＬ１０１４が、＜ＮＳＣＬ １０１４ Ｂａｓｅ＞／ｓｃｌｓ／の下の登録されたＧＳＣＬ１０１２を表す＜ｓｃｌ＞リソースである、＜ＧＳＣＬ １０１２＞を作成する（すなわち、＜ＮＳＣＬ １０１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＧＳＣＬ １０１２＞）。登録時に、ＧＳＣＬ１０１２は、それがＮＳＣＬ１０１４によって任意の他のＳＣＬに公表され得ることを示してもよい。代替として、ＧＳＣＬ１０１２は、ＮＳＣＬ１０１４がＧＳＣＬ１０１２を公表し得る、特定のＳＣＬを示してもよい。

ブロック１０３３では、ＮＳＣＬ１０１４が、いつ、およびどのＳＣＬにＧＳＣＬ１０１２を公表するかを判定してもよく、そのような公表は、ｍＩｍインターフェースを経由して伝送されてもよい。ＮＳＣＬ１０１４がＧＳＣＬ１０１２の公表をＮＳＣＬ１０２４に送信した後、ブロック１０３４では、ＮＳＣＬ１０２４が、ＮＳＣＬ１０２４のリソースツリー内の＜ＮＳＣＬ １０２４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ １０１４＞下のＧＳＣＬ１０１２リソースのアクティブ公表を表す、＜ｓｃｌＡｎｎｃ＞リソースを伴って構成される公表されたＳＣＬリソースである、＜ＧＳＣＬ １０１２ Ａｎｎｃ＞を作成してもよい（すなわち、＜ＮＳＣＬ １０２４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ
１０１４＞／ｓｃｌＡｎｎｃｅｓ／＜ＧＳＣＬ １０１２ Ａｎｎｃ＞）。リソース＜ＧＳＣＬ １０１２ Ａｎｎｃ＞は、ＮＳＣＬ１０１４に記憶されたＧＳＣＬ１０１２リソースのＵＲＩへのリンクを含有してもよい。したがって、ＧＳＣＬ１０１２はここで、ドメイン１０２０内のＳＣＬおよびアプリケーションに発見可能である。

図１１は、ＮＳＣＬ１０１４で図１０の信号フローによって生成された例示的リソースツリー１１００を図示する。ブロック１１０１は、その下にアプリケーション分岐１１０３およびｓｃｌｓ分岐１１０２が位置し得る、＜ＮＳＣＬ １０１４ Ｂａｓｅ＞である。アプリケーション分岐１１０３から、＜ＮＡ １０１３＞リソースの表現を含有するブロック１１０６があってもよい。ｓｃｌｓ分岐１１０２から、連絡先情報およびリソースへのリンクを含み得る、データ１１０７を含有し得る、＜ＧＳＣＬ １０１２＞ＳＣＬリソースの表現を含有するブロック１１０４があってもよい。また、ｓｃｌｓ分岐１１０２から、連絡先情報およびリソースへのリンクを含み得る、データ１１０８を含有し得る、ドメイン１０２０内の＜ＮＳＣＬ １０２４＞ＳＣＬリソースの表現を含有するブロック１１０５があってもよい。

図１２は、ＮＳＣＬ１０１４で図１０の信号フローによって生成された例示的リソースツリー１２００を図示する。ブロック１２０１は、その下にアプリケーション分岐１２０３およびｓｃｌｓ分岐１２０２が位置し得る、＜ＮＳＣＬ １０２４ Ｂａｓｅ＞である。アプリケーション分岐１２０３から、＜ＮＡ １０２３＞リソースの表現を含有するブロック１２０６があってもよい。ｓｃｌｓ分岐１２０２から、連絡先情報およびリソースへのリンクを含み得る、データ１２０７を含有し得る、＜ＧＳＣＬ １０２２＞ＳＣＬリソースの表現を含有するブロック１２０４があってもよい。また、ｓｃｌｓ分岐１２０２から、連絡先情報およびリソースへのリンクを含み得る、データ１２０８を含有し得る、ドメイン１０１０内の＜ＮＳＣＬ １０１４＞ＳＣＬリソースの表現を含有するブロック１２０５があってもよい。ブロック１２０５の下には、その下にＧＳＣＬ１０１４リソースを＜ＧＳＣＬ １０１４ Ａｎｎｃ＞として表すブロック１２１０が位置し得る、ｓｃｌＡｎｎｃｓ分岐１２０９があってもよい。ブロック１２１０は、ブロック１２１１で示されるようなＧＳＣＬ１０１２リソースへのリンクを含んでもよい（例えば、＜ＮＳＣＬ
１０１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＧＳＣＬ １０１２＞のＵＲＩまたは＜ＧＳＣＬ１０１２Ｂａｓｅ＞のＵＲＩ）。

図１３は、実施形態による、公表されたＳＣＬリソースのサブリソースとしてアプリケーションの公表を実証する、例示的な信号フロー１３００を図示する。ネットワークドメイン１３１０内には、ＤＡ１３１１、ＧＳＣＬ１３１２、ＮＡ１３１３、およびＮＳＣＬ１３１４があってもよい。ネットワークドメイン１３２０内には、ＤＡ１３２１、ＧＳＣＬ１３２２、ＮＡ１３２３、およびＮＳＣＬ１３２４があってもよい。本実施例では、ＤＡ１３１１は、ドメイン１３２０内のエンティティに発見可能にされるであろう。ブロック１３３１では、ＤＡ１３１１が、ＧＳＣＬ１３１２に登録し、ＧＳＣＬ１３１２がＤＡ１３１１１を任意のＳＣＬに公表し得ることを示す。代替として、ＤＡ１３１１は、ＧＳＣＬ１３１２がＤＡ１３１１を公表し得る、特定のＳＣＬを示してもよい。ＧＳＣＬ１３１２は、ＤＡ１３１１を、ＮＳＣＬ１３１４、およびＤＡ１３１１を公表することが許可され得る、ドメイン１３１０内の任意の他のＳＣＬに公表する。

ＧＳＣＬ１３１２がＤＡ１３１１をＮＳＣＬ１３１４に公表したとき、ブロック１３３２で、ＮＳＣＬ１３１４は、ＮＳＣＬ１３１４でＤＡ１３１１の公表されたリソースを表すように、＜ＮＳＣＬ １３１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＧＳＣＬ １３１２＞／ａｐｐｌｉｃａｔｉｏｎｓ／の下でＤＡ１３１１のアクティブ公表を表す、公表されたリソースである、＜ＤＡ １３１１ Ａｎｎｃ＞を作成した（すなわち、＜ＮＳＣＬ １３１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＧＳＣＬ １３１２＞／ａｐｐｌｉｃａｔｉｏｎｓ／＜ＤＡ １３１１ Ａｎｎｃ＞）。ブロック１３３４では、ＮＳＣＬ１３１４が、例えば、図１０で実証されるように、ＧＳＣＬ１３１２をＮＳＣＬ１３２４に公表する。ＧＳＣＬ１３１２に登録されたアプリケーションがあるため、ＮＳＣＬ１３１４は、ＧＳＣＬ１３１２に登録されたこれらのアプリケーションをＮＳＣＬ１３２４に公表してもよい。ＤＡ１３１１は、１つそのようなアプリケーションの実施例である。ブロック１３３５では、ＮＳＣＬ１３１４が、ＮＳＣＬ１３２４がＤＡ１３１１を公表することを要求する、公表要求をＮＳＣＬ１３２４に送信する。ブロック１３３６では、ＮＳＣＬ１３２４が、＜ＮＳＣＬ １３２４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ １３１４＞／ｓｃｌＡｎｎｃｓ／＜ＧＳＣＬＡｎｎｃ＞／ａｐｐｌｉｃａｔｉｏｎｓ／の下で、ＤＡ１３１１の公表されたリソース、すなわち、＜ＤＡ １３１１ Ａｎｎｃ＞を作成する（すなわち、＜ＮＳＣＬ
１３２４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＮＳＣＬ １３１４＞／ｓｃｌＡｎｎｃｓ／＜ＧＳＣＬＡｎｎｃ＞／ａｐｐｌｉｃａｔｉｏｎｓ／＜ＤＡ １３１１ Ａｎｎｃ＞）。このステップの完了時に、ブロック１３３７では、最初はゲートウェイの後ろのアプリケーションとしてＧＳＣＬ１３１２のみで「可視的」であるＤＡ１３１１が、ＮＳＣＬ１３１４で、次いで、ドメイン１３２０内のＮＳＣＬ１３２４で、可視的にされる。したがって、ＤＡ１３１１は、ドメイン１３２０内のＳＣＬおよびアプリケーションに発見可能となる。

図１４は、ＮＳＣＬ１３１４で図１３の信号フローによって生成された例示的リソースツリー１４００を図示する。ブロック１４０１は、その下にアプリケーション分岐１４０３およびｓｃｌｓ分岐１４０２が位置し得る、＜ＮＳＣＬ １３１４ Ｂａｓｅ＞である。アプリケーション分岐１４０３から、＜ＮＡ １３１３＞リソースの表現を含有するブロック１４０６があってもよい。ｓｃｌｓ分岐１４０２から、データ１４０７を含有し得る、ＮＳＣＬ１３１４に登録される＜ＧＳＣＬ １３１２＞ＳＣＬリソースの表現を含有するブロック１４０４があってもよい。データ１４０７は、ＧＳＣＬ１３１２が公表され得るＳＣＬのリストを含む、このＳＣＬリソースの属性を含んでもよい。また、ｓｃｌｓ分岐１４０２から、ドメイン１３２０内の＜ＮＳＣＬ １３２４＞ＳＣＬリソースの表現を含有するブロック１４０５があってもよい。

＜ＧＳＣＬ １３１２＞ＳＣＬリソースを表すブロック１４０４の下には、アプリケーションリソースの集合リソースである、アプリケーション分岐１４０８があってもよい。アプリケーション分岐１４０８の下には、ＤＡ１３１１リソースのアクティブ公表を表す公表されたリソースである、リソース＜ＤＡ １３１１ Ａｎｎｃ＞であり得るブロック１４０９があってもよい。このリソースは、＜ＧＳＣＬ １３１２ Ｂａｓｅ＞／Ａｐｐｌｉｃａｔｉｏｎｓ／＜ＤＡ １３１１＞等の元のリソースへのリンクを含んでもよい。

図１５は、ＮＳＣＬ１３２４で図１３の信号フローによって生成された例示的リソースツリー１５００を図示する。ブロック１５０１は、その下にアプリケーション分岐１５０３およびｓｃｌｓ分岐１５０２が位置し得る、＜ＮＳＣＬ １３２４ Ｂａｓｅ＞である。アプリケーション分岐１５０３から、＜ＮＡ １５２３＞リソースの表現を含有するブロック１５０６があってもよい。ｓｃｌｓ分岐１５０２から、連絡先情報およびリソースへのリンクを含み得る、データ１５０７を含有し得る、＜ＧＳＣＬ １３２２＞ＳＣＬリソースの表現を含有するブロック１５０４があってもよい。また、ｓｃｌｓ分岐１５０２から、連絡先情報およびリソースへのリンクを含み得る、データ１５０８を含有し得る、ドメイン１３１０内の＜ＮＳＣＬ １３１４＞ＳＣＬリソースの表現を含有するブロック１５０５があってもよい。ブロック１５０５の下には、その下に、ＧＳＣＬ１３１２リソースのアクティブ公表を表す公表されたＳＣＬリソースである、ＧＳＣＬ１３１２リソースを＜ＧＳＣＬ １３１２ Ａｎｎｃ＞として表すブロック１５１０が位置し得る、公表されたＳＣＬリソースの集合リソースである、ｓｃｌＡｎｎｃｓ分岐１５０９があってもよい。ブロック１５１０は、ＧＳＣＬ１３１２リソースへのリンクをブロック１５１１で含んでもよい（例えば、＜ＮＳＣＬ １３１４ Ｂａｓｅ＞／ｓｃｌｓ／＜ＧＳＣＬ １３１２＞のＵＲＩまたは＜ＧＳＣＬ１３１２Ｂａｓｅ＞のＵＲＩ）。公表されたＧＳＣＬ１３１２ＳＣＬリソースを表すブロック１５１０の下には、その下に、ＤＡ１３１１リソースのアクティブ公表を＜ＤＡ １３１１ Ａｎｎｃ＞として表す公表されたリソースである、ブロック１５１３が位置し得る、アプリケーションブロック１５１２（アプリケーションリソースの集合）があってもよい。＜ＤＡ １３１１ Ａｎｎｃ＞は、ブロック１５１４で示されるようなそのリソースへのリンクを含んでもよい。

図１６Ａは、ＳＣＬリソースの公表または公表解除等のサービス層リソース伝搬のためのシステムおよび方法の１つまたはそれを上回る開示された実施形態が実装され得る、例示的Ｍ２ＭまたはＩｏＴ通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴの構成要素ならびにＩｏＴサービス層等であってもよい。

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

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

図示したＭ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービスプラットフォーム２２は、１つまたはそれを上回るサーバ、コンピュータ、または同等物によって実装されてもよい。Ｍ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍ端末デバイス１８およびＭ２Ｍゲートウェイデバイス１４の管理および監視等のサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２はまた、データを収集し、異なるタイプのＭ２Ｍアプリケーション２０と互換性があるようにデータを変換してもよい。Ｍ２Ｍサービスプラットフォーム２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装されてもよい。

図１６Ｂも参照すると、Ｍ２Ｍサービスプラットフォームは、典型的には、多様なアプリケーションおよび垂直線が活用することができる、サービス配信能力のコアセットを提供する、サービス層２６（例えば、本明細書で説明されるようなネットワークサービス能力層（ＮＳＣＬ））を実装する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２６はまた、Ｍ２Ｍアプリケーション２０が、サービス層２６が提供するサービスと関連して、種々のネットワーク１２を通して通信することも可能にする。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０は、ＳＣＬリソースの公表または公表解除等のサービス層リソース伝搬のための開示されたシステムおよび方法を使用し得るデバイスを含む、１つまたはそれを上回るピアツーピアネットワークの作成のための基礎を形成する、所望のアプリケーションを含んでもよい。Ｍ２Ｍアプリケーション２０は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含んでもよい。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービス等のこれらの機能をＭ２Ｍアプリケーション２０に提供する。説明されたサービス層およびオブジェクトが相互作用するアプリケーションは、Ｍ２Ｍアプリケーション２０のもの等のアプリケーションであってもよい。

図１６Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図１６Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ（例えば、１つまたはそれを上回る発光ダイオード（ＬＥＤ））４２と、非可撤性メモリ４４と、可撤性メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。Ｍ２Ｍデバイス４０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、ＳＣＬリソースの公表または公表解除等のサービス層リソース伝搬のための開示されたシステムおよび方法を使用する、デバイスであってもよい。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、１つまたはそれを上回る特定用途向け集積回路（ＡＳＩＣ）、１つまたはそれを上回るフィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプおよび数の集積回路（ＩＣ）、状態機械、および同等物であってもよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結されてもよい。図１６Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を行ってもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行ってもよい。

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

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

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

プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。プロセッサ３２は、本明細書で説明される実施形態のうちのいくつかにおけるリソース伝搬（例えば、ＳＣＬリソースの公表または公表解除）が成功したか、または成功していないかどうかに応じて、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、あるいは別様にリソース伝搬プロセスの状態を示すように構成されてもよい。

プロセッサ３２は、電源４８から電力を受容してもよく、Ｍ２Ｍデバイス３０内の他の構成要素への電力を分配および／または制御するように構成されてもよい。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。

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

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

図１６Ｄは、例えば、図１６Ａおよび１６ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備えてもよく、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ可読命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行されてもよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、ＳＣＬリソースの公表または公表解除等のサービス層リソース伝搬のための開示されたシステムおよび方法に関係付けられる、データを受信、生成、および処理してもよい。

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

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

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

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

さらに、コンピュータシステム９０は、図１６Ａおよび１６Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含有してもよい。実施形態では、ネットワークアダプタ９７は、ＳＣＬリソースの公表または公表解除等のサービス層リソース伝搬のための開示されたシステムおよび方法に関係付けられるデータを受信および伝送してもよい。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、物理的デバイスまたは装置として具現化されるコンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。そのような命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス、または同等物等の機械あるいは機械の中で構成されるプロセッサによって実行されたときに、本明細書で説明されるシステム、方法、およびプロセスを達成し、行い、および／または実装する。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスクまたは他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

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

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

Claims (1)

1. 明細書に記載された発明。