JP2014505382A - リソースの公表および公表取消しのためのマシン間（ｍ２ｍ）インタフェース手順 - Google Patents

Abstract

１つまたは複数のネットワークを介してリソースの公表および公表取消しを伝搬するシステム、方法、および機構が開示される。第１のエンティティは、ホスティングサービス能力層（ＳＣＬ）であり、リソースを公表する要求を発行者から受信する。第１のエンティティはリソースの表現を作成する。この表現を公表リソースと呼ぶ。第１のエンティティは、公表リソース要求を、第１のエンティティに登録された第２のエンティティ（例えば、公表先ＳＣＬ）に送信する。リソース公表要求は、ｍｉｄインタフェースを通じて送信される。第１のエンティティは、第２のエンティティが公表リソースを作成したことを知らせる第１の応答を、ｍｉｄインタフェースを通じて第２のエンティティから受信する。

Description

本発明は、リソースの公表および公表取消しを伝搬するための、システム、方法、および装置に関する。

関連出願の相互参照
本出願は、２０１０年１１月１９日に出願された米国仮特許出願第６１／４１５，４６０号、および２０１１年１月１０日に出願された米国仮特許出願第６１／４３１，２１２号の利益を主張し、それら出願の内容は参照により本明細書に組み込まれる。

Ｍ２Ｍ通信は、人間の介在を必要としないマシン間通信を言う。Ｍ２Ｍ通信はすでに様々な用途に取り入れられており、いくつかの将来の用途にも関与することが予想される。そのような用途のいくつかの例は、スマートメータを用いた電力計量、ホームオートメーション、ｅＨｅａｌｔｈ、およびフリート（ｆｌｅｅｔ）管理を含む。

Ｍ２Ｍ通信はマシン型通信（ＭＴＣ）エンティティによって実行される。ＭＴＣエンティティの例は、ＭＴＣ装置、ＭＴＣサーバ、ＭＴＣユーザ、ＭＴＣ契約者等を含む。ＭＴＣ装置の一例は、ＭＴＣ通信に対応したユーザ機器（ＵＥ）である。ＭＴＣサーバの一例は、ネットワークを通じて１つまたは複数のＭＴＣ装置と通信するエンティティである。ＭＴＣ契約者の一例は、１人または複数のＭＴＣユーザにＭ２Ｍサービスを提供するサービス提供者である。ＭＴＣサーバは、ネットワークとＭＴＣユーザ間のインタフェースとして動作する。

ＭＴＣエンティティの性能は、どのようにネットワークリソースが使用されるかによって決まる。現在、そのようなリソースの効率的な管理に問題がある。

この概要は、以下の例示的実施形態の詳細な説明でさらに説明する概念の一部を簡略化した形態で紹介するために提供される。この概要は、特許請求の範囲の主題の主要な特徴や必須の特徴を明らかにするものでも、特許請求の範囲の主題の範囲を限定するために使用されるものでもない。

１つまたは複数のネットワークを介してリソースの公表を伝搬するシステム、方法、および機構が開示される。第１のエンティティは、ホスティングサービス能力層（ＳＣＬ）であり、リソースを公表する要求を発行者から受信する。例えば、発行者は、リソースを他のＳＣＬに公表するために第１のエンティティに要求を送信する。第１のエンティティはリソースの表現を作成する。この表現を公表リソースと呼ぶ。公表リソースは、検索文字列、属性、またはその表現の元となったリソースのＵＲＩ、の１つまたは複数を含む。第１のエンティティは、リソース公表要求を、第１のエンティティに登録された第２のエンティティ（例えば、公表先ＳＣＬ）に送信する。リソース公表要求は、ｍＩｄインタフェースを通じて送信される。第１のエンティティは、ｍＩｄインタフェースを通じて、第２のエンティティから、第２のエンティティが公表リソースを作成したことを知らせる第１の応答を受信する。

第１のエンティティは、リソースのアクセス可能性に基づいて、第２のエンティティが公表対象のエンティティであると判断する。第１のエンティティは、既知のユニフォームリソース識別子（ＵＲＩ）の下で第２のエンティティに公表リソースを公開する。第１のエンティティは、第２のエンティティが公表リソースを作成したことを知らせる第２の応答を発行者に送信する（例えば第１の応答の受信後）。第１のエンティティは、公表先となる複数のＳＣＬを判断する。第１のエンティティは多数のＳＣＬに接続され、セキュリティ上の制約やアクセス制御等に基づいて、それら多数のＳＣＬの部分集合としてそれら複数のＳＣＬを選択する。

添付図面との関連で例として与えられる以下の説明から、より詳細な理解が得られる。
１つまたは複数の開示される実施形態が実施される例示的通信システムのシステム図である。 図１Ａに示す通信システム内で使用される例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示す通信システム内で使用される例示的無線アクセスネットワークおよび例示的コアネットワークのシステム図である。 図１Ａに示す通信システム内で使用される別の例示的無線アクセスネットワークおよび別の例示的コアネットワークのシステム図である。 図１Ａに示す通信システム内で使用される別の例示的無線アクセスネットワークおよび別の例示的コアネットワークのシステム図である。 例示的な終端間Ｍ２Ｍシステムアーキテクチャの図である。 例示的なサービス能力機能アーキテクチャ構造の図である。 例示的な公表リソース構造の図である。 リソースを公表する場合の例示的な呼び出しの流れを示す図である。 同期方式で公表リソースにアクセスする場合の例示的な呼び出しの流れを示す図である。 非同期方式で公表リソースにアクセスする場合の例示的な呼び出しの流れを示す図である。 リソースの公表を取り消す場合の例示的な呼び出しの流れを示す図である。 公表されたアプリケーションリソースを格納する例示的なリソース構造の図である。 公表先リソースを格納する例示的なリソース構造の図である。 リソースを公表する場合の例示的な呼び出しの流れを示す図である。 公表リソースを伝搬する場合の例示的な呼び出しの流れを示す図である。 公表リソースを伝搬する場合の例示的な呼び出しの流れを示す図である。 公表リソースを更新する場合の例示的な呼び出しの流れを示す図である。 リソースの公表を取り消す場合の例示的な呼び出しの流れを示す図である。

以下で図を参照して例示的実施形態を詳細に説明する。ただし、本発明は例示的な実施形態との関連で説明されるが、それらの実施形態に制限されず、他の実施形態が使用されてよく、または本発明から逸脱することなく本発明の同じ機能を行うために、記載の実施形態に変更または追加が加えられてよいことを理解されたい。また、図は呼び出しの流れを説明するが、例示的なものである。他の実施形態が使用されてよいことを理解されたい。流れの順序は適宜変更される。また、必要でない場合はフローが省略され、また追加的なフローが追加されてよい。

図１Ａは、１つまたは複数の開示される実施形態が実施される例示的通信システム１００の図である。通信システム１００は、音声、データ、映像、メッセージング、放送等のコンテンツを複数の無線ユーザに提供する多重接続システムである。通信システム１００は、複数の無線ユーザが、無線帯域等のシステム資源の共有を通じてそのようなコンテンツにアクセスすることを可能にする。例えば、通信システム１００は、符号分割多重接続（ＣＤＭＡ）、時分割多重接続（ＴＤＭＡ）、周波数分割多重接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つまたは複数のチャネルアクセス方法を用いる。

図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（総称的にまたはまとめてＷＴＲＵ１０２と呼ぶ）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むが、開示される実施形態は、任意数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが理解されよう。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線環境で動作および／または通信するように構成された任意種の装置である。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成され、ユーザ機器（ＵＥ）、移動局、固定型または移動型の加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、消費者家電等を含む。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含む。各基地局１１４ａ、１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線にインタフェースをとって、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２等の１つまたは複数の通信ネットワークへのアクセスを助けるように構成された任意種の装置である。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータ等である。図では基地局１１４ａ、１１４ｂはそれぞれ１つの要素として示すが、基地局１１４ａ、１１４ｂは、相互接続された任意数の基地局および／またはネットワーク要素を含むことが理解されよう。

基地局１１４ａはＲＡＮ１０３／１０４／１０５の一部であり、それらのＲＡＮも、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノード等のネットワーク要素（図示せず）を含む。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）とも呼ばれる特定の地理的領域内で無線信号を送信および／または受信するように構成される。セルはさらにセルセクタに分割される。例えば、基地局１１４ａに関連付けられたセルが３つのセクタに分割される。したがって、一実施形態では、基地局１１４ａは、セルのセクタごとに１つ、すなわち計３つのトランシーバを含む。別の実施形態では、基地局１１４ａは多入力多出力（ＭＩＭＯ）技術を用い、したがってセルのセクタごとに複数のトランシーバを利用する。

基地局１１４ａ、１１４ｂは、エアインタフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信し、エアインタフェースは、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光等）である。エアインタフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立される。

より具体的には、上記のように、通信システム１００は多重接続システムであり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ等の１つまたは複数のチャネルアクセス方式を用いる。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、総合移動遠隔通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）等の無線技術を実装し、その場合、エアインタフェース１１５／１１６／１１７は広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用して確立する。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）等の通信プロトコルを含む。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含む。

別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、発展型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）等の無線技術を実装し、その場合は長期間発展（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインタフェース１１５／１１６／１１７を確立する。

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちマイクロ波アクセスのための世界規模の相互動作性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ ＩＸ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動通信のための世界規模システム（ＧＳＭ（登録商標））、ＧＳＭ発展のための増大データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）等の無線技術を実装する。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであり、職場、住宅、乗り物、大学構内等の限定された領域内で無線接続を容易にする適当なＲＡＴを利用する。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１等の無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立する。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄはＩＥＥＥ８０２．１５等の無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立する。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラー方式のＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ等）を利用してピコセルまたはフェムトセルを確立する。図１Ａに示すように、基地局１１４ｂはインターネット１１０への直接の接続を有する。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がない。

ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信状態にあり、コアネットワークは、音声、データ、アプリケーション、および／またはインターネットプロトコルによる音声伝送（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成された任意種のネットワークである。例えば、コアネットワーク１０６／１０７／１０９は、呼の制御、課金サービス、モバイル位置を利用したサービス、料金前払いの通話、インターネット接続、映像配信等を提供する、かつ／またはユーザ認証等の高レベルのセキュリティ機能を行う。図１Ａには示さないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを用いる他のＲＡＮと直接または間接的に通信することが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用するＲＡＮ１０３／１０４／１０５に接続されるのに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を用いる別のＲＡＮ（図示せず）とも通信状態にある。

コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイの役割も果たす。ＰＳＴＮ１０８は、従来型の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含む。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートの伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル（ＩＰ）等の共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよび装置からなる世界規模のシステムを含む。ネットワーク１１２は、他のサービス提供者に所有および／または運営される有線または無線の通信ネットワークを含む。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを用いる１つまたは複数のＲＡＮに接続された別のコアネットワークを含む。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、多モード能力を備える。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々の無線リンクを通じて種々の無線ネットワークと通信するための複数のトランシーバを含む。例えば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラー方式の無線技術を用いる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を用いる基地局１１４ｂと通信するように構成される。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取外し不能メモリ１３０、取外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機能１３８を備える。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上述の要素のサブコンビネーションを含むことが理解されよう。また、各実施形態は、基地局１１４ａおよび１１４ｂおよび／またはその基地局１１４ａおよび１１４ｂが表すノード（これらに限定されないが、とりわけトランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、発展型ホームノードＢ（ｅノードＢ）、ホーム発展型ノードＢ（ＨｅＮＢ）、ホーム発展型ノードＢゲートウェイ、およびプロキシノード等）が、図１Ｂに示され、本明細書に記載される要素の一部またはすべてを含むことを企図する。

プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途集積回路（ＡＳＩＣ）、利用者書き換え可能ゲートアレイ（ＦＰＧＡ）回路、任意の他の種の集積回路（ＩＣ）、状態機械等である。プロセッサ１１８は、信号の符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする他の機能を行う。プロセッサ１１８はトランシーバ１２０に結合され、トランシーバ１２０は送信／受信要素１２２に結合される。図１Ｂではプロセッサ１１８とトランシーバ１２０を別個の構成要素として示すが、プロセッサ１１８とトランシーバ１２０は電子パッケージやチップに共に一体化されてもよいことが理解されよう。

送信／受信要素１２２は、エアインタフェース１１５／１１６／１１７を通じて基地局（例えば基地局１１４ａ）との間で信号を送信または受信するように構成される。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナである。別の実施形態では、送信／受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器である。さらに別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送受信するように構成される。送信／受信要素１２２は、各種無線信号の任意の組合せを送信および／または受信するように構成されることが理解されよう。

また、図１Ｂでは送信／受信要素１２２を１つの要素として示すが、ＷＴＲＵ１０２は任意数の送信／受信要素１２２を含む。より具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を用いる。そのため、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１５／１１６／１１７を通じて無線信号を送受信するために２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含む。

トランシーバ１２０は、送信／受信要素１２２から送信される信号を変調し、送信／受信要素１２２に受信された信号を復調するように構成される。上記のように、ＷＴＲＵ１０２は多モード能力を有する。そのため、トランシーバ１２０は、ＷＴＲＵ１０２が例えばＵＴＲＡやＩＥＥＥ８０２．１１等の複数種のＲＡＴを介して通信することを可能にする複数のトランシーバを含む。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば液晶ディスプレイ（ＬＣＤ）表示装置や有機発光ダイオード（ＯＬＥＤ）表示装置）に結合され、それらからユーザ入力データを受け取る。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力する。また、プロセッサ１１８は、取外し不能メモリ１３０および／または取外し可能メモリ１３２等の任意種の適切なメモリの情報にアクセスし、データを記憶する。取外し不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または他の任意種のメモリ記憶装置を含む。取外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含む。他の実施形態では、プロセッサ１１８は、サーバや家庭コンピュータ（図示せず）等、物理的にＷＴＲＵ１０２にないメモリの情報にアクセスし、データを記憶する。

プロセッサ１１８は、電源１３４から電力を受け取り、その電力をＷＴＲＵ１０２中の他の構成要素に配布および／または制御するように構成される。電源１３４は、ＷＴＲＵ１０２に電力を供給するのに適した任意の装置である。例えば、電源１３４は、１つまたは複数の乾電池（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含む。

プロセッサ１１８はＧＰＳチップセット１３６にも結合され、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば経度および緯度）を提供するように構成される。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１５／１１６／１１７を介して位置情報を受信し、かつ／または、２つ以上の近隣の基地局から信号が受信されるタイミングに基づいて自身の位置を判定する。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切な位置判定方法で位置情報を取得することが理解されよう。

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

図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上記のように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を用いてエアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する。ＲＡＮ１０３は、コアネットワーク１０６とも通信状態にある。図１Ｃに示すように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含み、各ノードＢは、エアインタフェース１１５を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを備える。ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられる。ＲＡＮ１０３はＲＮＣ１４２ａ、１４２ｂも含む。ＲＡＮ１０３は実施形態との整合性を保ちながら、任意数のノードＢおよびＲＮＣを含むことが理解されよう。

図１Ｃに示すように、ノードＢ１４０ａ、１４０ｂはＲＮＣ１４２ａと通信状態にある。また、ノードＢ１４０ｃはＲＮＣ１４２ｂと通信状態にある。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインタフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信する。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインタフェースを介して相互と通信する。各ＲＮＣ１４２ａ、１４２ｂは、それぞれが接続されたノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成される。また、各ＲＮＣ１４２ａ、１４２ｂは、外部ループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティ、セキュリティ機能、データの暗号化等の他の機能を実行または支援するように構成される。

図１Ｃに示すコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センター（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含む。上記の各要素はコアネットワーク１０６の一部として図示するが、これらの要素の任意の１つはコアネットワークの運営者以外のエンティティにより所有および／または運営されてもよいことが理解されよう。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続される。ＭＳＣ１４６はＭＧＷ１４４に接続される。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上回線通信機器との間の通信を容易にする。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインタフェースを介してコアネットワーク１０６のＳＧＳＮ１４８にも接続される。ＳＧＳＮ１４８はＧＧＳＮ１５０に接続される。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応機器との間の通信を容易にする。

上記のように、コアネットワーク１０６はネットワーク１１２にも接続され、ネットワーク１１２は、他のサービス提供者に所有および／または運営される他の有線または無線のネットワークを含む。

図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上記のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を用いて、エアインタフェース１１６を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する。ＲＡＮ１０４はコアネットワーク１０７とも通信状態にある。

ＲＡＮ１０４はｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むが、ＲＡＮ１０４は実施形態との整合性を保ちながら任意数のｅノードＢを含むことが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインタフェース１１６を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含む。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはＭＩＭＯ技術を実装する。したがって、例えばｅノードＢ１６０ａは、複数のアンテナを使用してＷＴＲＵ１０２ａとの間で無線信号を送受信する。

各ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、特定のセル（図示せず）に関連付けられ、無線リソース管理に関する決定、ハンドオーバーの決定、アップリンクおよび／またはダウンリンクのユーザのスケジューリング等を処理するように構成される。図１Ｄに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはＸ２インタフェースを通じて相互と通信する。

図１Ｄに示すコアネットワーク１０７は、移動性管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含む。図では上述の各要素はコアネットワーク１０７の一部として示すが、それらの要素のいずれか１つは、コアネットワークの運営者以外のエンティティによって所有および／または運営されることが理解されよう。

ＭＭＥ１６２は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃ各々に接続され、制御ノードの役割を果たす。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初のアタッチ時の特定サービングゲートウェイの選択等を担う。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭやＷＣＤＭＡ等の他の無線技術を用いる他のＲＡＮ（図示せず）とを切替えるための制御プレーン機能も提供する。

サービングゲートウェイ１６４は、Ｓ１インタフェースを介してＲＡＮ１０４内の各ｅノードＢ１６０ａ、１６０ｂ、１６０ｃに接続される。サービングゲートウェイ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットを送信および転送する。サービングゲートウェイ１６４は、他の機能、例えば、ｅノードＢ間のハンドオーバー時にユーザプレーンを固定する、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに入手可能なダウンリンクデータがある時にページングをトリガする、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテクストを管理および記憶する等も行う。

サービングゲートウェイ１６４はＰＤＮゲートウェイ１６６にも接続されて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置間の通信を容易にする。ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを提供する。

コアネットワーク１０７は、他のネットワークとの通信を容易にする。例えば、コアネットワーク１０７は、ＰＳＴＮ１０８等の回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信装置との間の通信を容易にする。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８間のインタフェースとして機能するＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそれと通信する。また、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにネットワーク１１２へのアクセスを提供することができ、ネットワーク１１２は、他のサービス提供者に所有および／または運営される他の有線または無線ネットワークを含む。

図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を使用してエアインタフェース１１７を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）である。下記でさらに述べるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の異なる機能エンティティ間の通信リンクが基準点として定義される。

図１Ｅに示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含むことができるが、ＲＡＮ１０５は、実施形態との整合性を保ちながら任意数の基地局およびＡＳＮゲートウェイを含むことが理解されよう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれＲＡＮ１０５内の特定のセル（図示せず）に関連付けられ、それぞれエアインタフェース１１７を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含む。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃはＭＩＭＯ技術を実装する。そのため、例えば基地局１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間で無線信号を送受信する。基地局１８０ａ、１８０ｂ、１８０ｃは、ハンドオフのトリガ、トンネルの確立、無線リソース管理、トラフィックの分類、サービス品質（ＱｏＳ）ポリシーの施行等の移動性管理機能も提供する。ＡＳＮゲートウェイ１８２はトラフィック集約点として機能し、ページング、加入者プロファイルの保存、コアネットワーク１０９へのルーティング等を担う。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインタフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義される。また、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃはそれぞれ、コアネットワーク１０９との間に論理インタフェース（図示せず）を確立する。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インタフェースは、認証、権限付与、ＩＰホスト設定管理、および／または移動性管理に使用されるＲ２基準点として定義される。

各基地局１８０ａ、１８０ｂ、１８０ｃ間の通信リンクは、ＷＴＲＵのハンドオーバーおよび基地局間のデータ転送を容易にするプロトコルを含むＲ８基準点として定義される。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２間の通信リンクは、Ｒ６基準点として定義される。Ｒ６基準点は、各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに関連する移動事象に基づく移動性管理を容易にするプロトコルを含む。

図１Ｅに示すように、ＲＡＮ１０５はコアネットワーク１０９に接続される。ＲＡＮ１０５とコアネットワーク１０９間の通信リンクは、例えばデータ転送および移動性管理機能を容易にするプロトコルを含むＲ３基準点として定義される。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証、権限付与、課金（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含む。上述の各要素はコアネットワーク１０９の一部として図示するが、これらの要素のいずれか１つはコアネットワークの運営者以外のエンティティにより所有および／または運営されることが理解されよう。

ＭＩＰ−ＨＡは、ＩＰアドレス管理を担い、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが異なるＡＳＮ間および／または異なるコアネットワーク間を移動することを可能にする。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応装置との間の通信を容易にする。ＡＡＡサーバ１８６は、ユーザ認証およびユーザサービスの支援を担う。ゲートウェイ１８８は、他のネットワークとの相互動作を容易にする。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の陸線通信装置との間の通信を容易にする。また、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービス提供者によって所有および／または運営される他の有線または無線ネットワークを含むネットワーク１１２へのアクセスを提供する。

図１Ｅには示さないが、ＲＡＮ１０５は他のＡＳＮに接続され、コアネットワーク１０９は他のコアネットワークに接続されることが理解されよう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクはＲ４基準点として定義され、ＲＡＮ１０５と他のＡＳＮ間のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの移動性を司るプロトコルを含む。コアネットワーク１０９と他のコアネットワーク間の通信リンクはＲ５基準点として定義され、Ｒ５基準点は、ホームコアネットワークと移動先で利用される（ｖｉｓｉｔｅｄ）コアネットワーク間の相互動作を容易にするプロトコルを含む。

１つまたは複数のネットワークにわたってリソースの公表を伝搬するシステム、方法、および機構が開示される。第１のエンティティは、ホスティングサービス能力層（ＳＣＬ）であり、リソースを公表する要求を発行者から受信する。例えば、発行者は、リソースを他のＳＣＬに公表するために、第１のエンティティに要求を送信する。第１のエンティティはリソースの表現を作成する。この表現を公表リソースと呼ぶ。公表リソースは、検索文字列、属性、またはその表現の元となったリソースのＵＲＩ、の１つまたは複数を含む。第１のエンティティは、リソース公表要求を、第１のエンティティに登録された第２のエンティティ（例えば、公表先ＳＣＬ）に送信する。リソース公表要求は、ｍＩｄインタフェースを通じて送信される。第１のエンティティはｍＩｄインタフェースを通じて、第２のエンティティから、第２のエンティティがリソースを作成したことを知らせる第１の応答を受信する。

第１のエンティティは、リソースのアクセス可能性に基づいて、第２のエンティティが公表対象のエンティティであると判断する。第１のエンティティは、既知のユニフォームリソース識別子（ＵＲＩ）の下で第２のエンティティにリソースを公開する。第１のエンティティは、第２のエンティティがリソースを作成したことを知らせる第２の応答を発行者に送信する（例えば第１の応答の受信後）。第１のエンティティは、公表先となる複数のＳＣＬを判断する。第１のエンティティは多数のＳＣＬに接続され、セキュリティ上の制約やアクセス制御等に基づいて、それら多数のＳＣＬの部分集合として複数のＳＣＬを選択する。

図２に、例示的な終端間Ｍ２Ｍシステムのアーキテクチャを示す。このＭ２Ｍシステムアーキテクチャは、Ｍ２Ｍ装置領域、ならびにネットワークおよびアプリケーション領域を含む。

Ｍ２Ｍ装置領域は、Ｍ２Ｍ装置、Ｍ２Ｍエリアネットワーク、またはＭ２Ｍゲートウェイ、の１つまたは複数を含む。Ｍ２Ｍ装置は、Ｍ２Ｍサービス能力（ＳＣ）およびネットワーク領域機能を使用してＭ２Ｍアプリケーションを実行する装置である。Ｍ２Ｍ装置は、１つまたは複数の（順次または並列）ゲートウェイを介して直接または間接的にＭ２Ｍコアに接続する。Ｍ２Ｍエリアネットワークは、Ｍ２Ｍ装置とＭ２Ｍゲートウェイ間の接続性を提供する。Ｍ２Ｍエリアネットワークの例は、個人エリアネットワーク技術、例えば、ＩＥＥＥ ８０２．１５．ｘ、Ｚｉｇｂｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ、ＩＥＴＦ ＲＯＬＬ、ＩＳＡ１００．１１ａ等を含む。Ｍ２Ｍゲートウェイは、Ｍ２Ｍサービス能力を使用して、Ｍ２Ｍ装置間の相互動作と、ネットワークおよびアプリケーション領域への相互接続を保証する。Ｍ２ＭゲートウェイもＭ２Ｍアプリケーションを実行する。

ネットワークおよびアプリケーション領域は、アクセスネットワーク、トランスポートネットワーク、またはＭ２Ｍコア、の１つまたは複数を含む。アクセスネットワークは、Ｍ２Ｍ装置領域がコアネットワークと通信することを可能にする。アクセスネットワークの例は、ｘＤＳＬ、ＨＦＣ、ＰＬＣ、衛星、ＧＥＲＡＮ、ＵＴＲＡＮ、ｅＵＴＲＡＮ、Ｗ−ＬＡＮ、またはＷｉＭＡＸ、の１つまたは複数を含む。トランスポートネットワークは、ネットワークおよびアプリケーション領域内のデータの移送を可能にする。Ｍ２Ｍコアは、コアネットワークおよびサービス能力から構成される。コアネットワークは、ＩＰ接続および可能性としては他の接続手段と、サービスおよびネットワーク制御機能と、（例えば、他のネットワークとの）相互接続と、またはローミングと、の１つまたは複数を提供する。コアネットワークの例は、３ＧＰＰ ＣＮ、ＥＴＳＩ ＴＩＳＰＡＮ ＣＮ、または３ＧＰＰ２ ＣＮ、の１つまたは複数を含む。Ｍ２Ｍサービス能力（ＳＣ）の例は、ネットワークアプリケーション実行可能化（ＮＡＥ）能力と、ネットワーク汎用通信（ＮＧＣ）能力と、ネットワーク到達性と、アドレス指定およびリポジトリ（ＮＲＡＲ）能力と、ネットワーク通信選択（ＮＣＳ）能力と、ネットワークリモートエンティティ管理（ＮＲＥＭ）能力と、ネットワークセキュリティ（ＮＳＥＣ）能力と、ネットワーク履歴およびデータ保持（ＮＨＤＲ）能力と、ネットワークトランザクション管理（ＮＴＭ）能力と、ネットワーク相互動作プロキシ（ＮＩＰ）能力と、またはネットワーク通信事業者公開（ＮＴＯＥ）能力と、の１つまたは複数を含む。

リソースの公表および公表取消しのためのＭ２Ｍインタフェース手順に関連するシステム、方法、および機構が開示される。例示的なリソースは、これらに限定されないが、スマートメータから収集されるデータを含むスマートメータ、および医療機器（例えば血圧監視機器）を含む。図３に、本明細書に開示される実施形態により利用されるサービス能力機能のアーキテクチャ構造の例示的なブロック図を示す。図３を参照すると、ゲートウェイ（Ｇ）は、ＥＴＳＩ Ｍ２Ｍ装置のＭ２Ｍエリアネットワークを管理するＥＴＳＩ Ｍ２Ｍ装置である。ゲートウェイはＥＴＳＩ Ｍ２Ｍコアネットワークと通信する。装置（Ｄ）は、ＥＴＳＩ Ｍ２ＭコアネットワークまたはＥＴＳＩ Ｍ２Ｍゲートウェイと通信するＥＴＳＩ Ｍ２Ｍ装置である。装置’（Ｄ’）は、ＥＴＳＩ Ｍ２Ｍサービス能力を実装しないＥＴＳＩ Ｍ２Ｍ装置である。装置’（Ｄ’）は、Ｍ２Ｍゲートウェイ（Ｇ）のサービス能力を使用することによりＭ２Ｍコアと間接的に対話する。ゲートウェイ’（Ｇ’）は、ＤおよびＤ’装置両方への接続性を提供するＥＴＳＩ Ｍ２Ｍゲートウェイである。ＥＴＳＩ Ｍ２Ｍに準拠した装置またはゲートウェイエンティティによって管理されるエリアネットワークに属するＥＴＳＩ Ｍ２Ｍ非準拠装置（「ｄ」）がある可能性がある。装置ｄは、Ｍ２Ｍサービス能力に直接アクセスすることができない。

公表リソースはＭ２Ｍサービス能力層（ＳＣＬ）で使用されるリソースであり、この層にそれらの公表リソースがホストされて、そのＳＣＬで発見することが可能なリモート（公表元）リソース（例えばリモートＳＣＬにあるリソース）を常に監視する。公表リソースは、公表元リソースへのリンクを含む。公表リソースの可視性は、そのリソースがその完全なＵＲＬを介してアクセスされる時に限られる。他の場合、例えば発見時や親集合リソースの列挙時には、リモート／公表元リソースへの直接の参照が返される。集合リソースと公表リソースとの間には包含関係があり、例えば集合リソースが除去されると、それに含まれるリソースも、それがローカルリソースに相当しても、公表リソースに相当しても除去される。そのような場合、公表元リソース（公表リソースが参照するリソース）は除去されない。公表元リソースが除去されると、公表リソースを除去することはリモートＳＣＬの役割となる。公表リソースの除去が行われないと、発見の結果存在しないリモートリソースへの参照が生じることがある。

公表リソースには種々の種類がある。これは、例えば、公表リソースは、同じ子集合リソースを、それらの公表リソースが表すリソースとして共有する場合があるためである。後者は、公表リソースの子孫として明示的に子リソース（例えばグループ、アクセス権、コンテナ等）を作成することを可能にする。これは通常の包含関係であるため、そのような子リソースは、公表リソースが除去されると（例えばリモートリソースの公表が取り消されると）除去される。

エンティティはＳＣＬまたはアプリケーションである。発行者は、例えば公表リソースに関連する要求を行う行為者である。発行者は、アプリケーションまたはＳＣＬである。公表リソースは、ミラー（ｍｉｒｒｏｒｅｄ）リソースとも呼ばれ、別のＳＣＬによってホストされるリソース（例えばマスタ／元のリソース）を参照する内容を有する。公表リソースは、限定された属性のセット、例えば検索文字列、元のリソースへのリンク（例えばＵＲＩ）等を備える実際のリソースである。公表リソースの目的は、元のリソースの発見を容易にして、発見の発行者がリソースを見つけるために多数のＳＣＬに接触せずに済むようにすることである。

ローカル（例えば、登録）ＳＣＬは、アプリケーション／ＳＣＬが登録するＳＣＬである。ローカルＳＣＬは、要求の最初の発行者（アプリケーションまたはＳＣＬ）からの要求を受け取るＳＣＬである。ＮＡが最初の発行者である場合、ローカルＳＣＬはＮ−ＳＣＬになる。さらに、ＧＡが最初の発行者である場合、ローカルＳＣＬはＧ−ＳＣＬになる。Ｄ装置におけるＤＡが最初の発行者である場合、ローカルＳＣＬはＤ−ＳＣＬになる。Ｄ’装置のＤＡが最初の発行者である場合、ローカルＳＣＬはＧ−ＳＣＬになる。Ｄ装置のＤ−ＳＣＬが最初の発行者である場合、ローカルＳＣＬはＧ−ＳＣＬまたはＮ−ＳＣＬとなる。Ｇ−ＳＣＬが最初の発行者である場合、ローカルＳＣＬはＮ−ＳＣＬになる。

ホスティングＳＣＬは、アドレス指定された（例えば実際の）リソースが存在するＳＣＬである。公表先ＳＣＬは、公表リソースを備えるＳＣＬである。リソースは複数のＳＣＬに公表される。リソース発見の文脈では、「リンク」は、「ＵＲＩ」または「帰属されたリソース参照の集まり」である。

リソースは、複数の異なるＳＣＬに格納される。リソースの重複を減らし、またリソース発見にかかる時間を短縮するために、実際のリソースは１つのＳＣＬに格納され、その実際のリソースの表現またはコピーが他のＳＣＬに格納される。公表手順は、ＳＣＬが自身のリソース表現またはリソースを他のＳＣＬに伝搬するために使用される。公表取消しの手順は、ＳＣＬが以前に伝搬したリソースを他のＳＣＬから削除するために使用される。

図４に、例示的な公表リソース構造を示す。公表リソースは、実際のリソースの表現である。リソースタイプ識別子を使用して、リソースが公表リソースであることを識別する。

公表リソースは、１つまたは複数のＳｅａｒｃｈＳｔｒｉｎｇを含む。ＳｅａｒｃｈＳｔｒｉｎｇは、アクセス要求中の検索文字列を照合するために使用される。ＳｅａｒｃｈＳｔｒｉｎｇは、人間が読めるリソース名、リソースからとられたテキスト等である。

図４の例に示すように、公表リソースは１つまたは複数の属性を備える。属性の例は、アクセス可能性（読み出し／書き込み）、存続期間（例えばその公表リソースが有効な時間の長さを示す値）、リソースのサイズ、または媒体種類、の１つまたは複数を含む。公表リソースは、例えば「ブロードキャスト」「マルチキャスト」または「ユニキャスト」として公表される（例えばホスティングＳＣＬにより）。ブロードキャストは、そのリソースがどのＳＣＬまたはアプリケーションに公表されてもよいことを意味する。マルチキャストは、リソースの公表が、許可されたＳＣＬおよび／またはアプリケーションのグループに限定されることを意味する。ユニキャストは、リソース公表が特定の１つのＳＣＬまたはアプリケーションに限定されることを意味する。元のリソースのＡｃｃｅｓｓＲｉｇｈｔは、元のリソースから継承される。

一部の属性は検索可能であるため、ＳｅａｒｃｈＳｔｒｉｎｇとして使用される。別のＳＣＬにあるリソースを参照する際、公表リソースの内容はそのリソースのＵＲＩを含む。

エンティティ（例えば、発行者）は、リソースをＳＣＬなどの他のエンティティに公表する。この公表は、最初／初回の公表および以後の更新を含む。発行者は、自身の利用可能なリソースを他のＳＣＬに公表することを要求するアプリケーションまたはＳＣＬである。公表手順のトリガは、ホスティングＳＣＬの初期化、新しいリソースの作成、リソースの更新、ホスティングＳＣＬが新しいＳＣＬを発見した等の１つまたは複数を含む。発行者はリソースを周期的に公表してもよい。アプリケーションがリソースを作成または更新すると、アプリケーションは、アプリケーションがそのリソースをどのように見えるようにしたいかに基づいてそのリソースを公表してよいかどうかを指示する。アプリケーションは、リソースの表現がどのように構成されるべきかを指示する。

発行者からの要求に基づいて、ホスティングＳＣＬは、公表リソースの形で、例えば他のＳＣＬにリソースを公表する。公表手順の発行者はホスティングＳＣＬ自体の場合もある。ホスティングＳＣＬは、リソースの表現を形成し（例えば図５に示すように公表リソースを作成し）、対象ＳＣＬに「公表リソース」要求を送信する。ホスティングＳＣＬは、リソースのアクセス可能性に従って、公表すべき対象ＳＣＬを決定する。公表リソースをブロードキャストできない場合、公表先ＳＣＬは、ホスティングＳＣＬに登録している必要がある。セキュリティやアクセス制御などの理由により、ホスティングＳＣＬは、公表できるＳＣＬが制限される（例えば、ホスティングＳＣＬが接続されているすべてのＳＣＬに公表できるとは限らない）。公表先ＳＣＬは公表リソースをローカルに作成する。

ＳＣＬは、公表リソースを、既知のＵＲＩの下で別のＳＣＬに公開する（例えば公表手順の一部として）。発行者（例えばアプリケーションまたはＳＣＬ）は、ＳＣＬに対して既知のＵＲＩへのＧＥＴを行って、利用可能な公表リソースを取得する。例えば、ＣｏＡＰで、リソース発見のための既知の／コアＵＲＩを定義する。

公表先ＳＣＬは、公表リソースを、そのＳＣＬが接続されている他のＳＣＬに伝搬する。公表先ＳＣＬは、属性の一部を取り出し、簡略化した新たな公表リソースを他のＳＣＬに伝搬する。

図５に、リソースを公表する例示的な流れ図を示す。図５を参照すると、ＳＣＬ−１またはアプリケーション（例えば発行者）は、公表要求をＳＣＬ−２（例えばローカルＳＣＬ／ホスティングＳＣＬ）に通信し、ＳＣＬ−２にリソースが格納（例えば作成）される。ＳＣＬ−２による格納／作成は、実際のリソースの表現を格納／作成することを含み、その表現を公表リソースと呼ぶ（例えば図４参照）。その通信に応答して、ＳＣＬ−２は、自身のリソース（例えば公表リソース）を公表するようにトリガされ、リソースの公表は、リソース公表通信をＳＣＬ−３（例えば公表先ＳＣＬ）に送信することを含む。ＳＣＬ−３は、公表リソースを格納（例えば作成）する。図５に示すように応答が通信される。

公表リソースはアクセスされる。例えば、発行者は、公表リソースへのアクセスを望むエンティティである。発行者は、自身のローカル（登録）ＳＣＬに対する要求メッセージを作成して、リソースを要求する。要求は、１つまたは複数のＳｅａｒｃｈＳｔｒｉｎｇを含む。ローカルＳＣＬは公表先ＳＣＬである場合もそうでない場合もあり、すなわち、要求されるリソースについての情報を持っている場合もそうでない場合もある。ローカルＳＣＬが公表先ＳＣＬでない場合は、ローカルＳＣＬは、公表先ＳＣＬに到達するまで、自身が接続されている他のＳＣＬに要求を伝搬する。一実施形態によると、ネットワークへの余分な負荷を減らし、そのような要求のホップ回数を制限するために、リソースアクセス要求中にＳＣＬの最大数を指示するか、またはホップの制限回数が種々のエンティティで事前に設定される。

公表先ＳＣＬは、発行者のアクセス権を確認し、公表リソースへのアクセスが許可されない場合は、公表先ＳＣＬは、例えばアクセスが拒否されたことを示すステータスコードを返す。発行者が公表リソースへのアクセスを許される場合は、公表先ＳＣＬは、例えば下記の例の１つを使用してアクセスを提供する。

同期方式では、公表先ＳＣＬがアクセス要求をホスティングＳＣＬに転送する。同期方式の使用例の１つは、実際のリソースのＵＲＩが発行者からは見えず、そのため、公表先ＳＣＬがＵＲＩを発行者に返すことができない場合である。代わりに、公表先ＳＣＬは、発行者に代わって取得動作を行い、リソースの実際の内容を発行者に返す必要がある。非同期方式では、公表先ＳＣＬが公表リソースのＵＲＩを発行者に返し、発行者がホスティングＳＣＬにマスタ／元のリソースを照会する。

実際のリソースにアクセスするための要求をホスティングＳＣＬが受け取ると、ホスティングＳＣＬは発行者のアクセス権を確認し、許可される場合は、ホスティングＳＣＬは成功ステータスの応答を送信する。許可されない場合は、アクセス拒否を返す（例えばステータスコードを介して）。

図６に、同期方式で公表リソースにアクセスする場合の例示的な流れ図を示す。図６を参照すると、ＳＣＬ−１またはアプリケーション（例えば、発行者）が、リソースにアクセスするための通信をＳＣＬ−２（例えば、ローカルＳＣＬ）に送信する。それに応答して、ＳＣＬ−２は要求を確認し、そのリソースを持っていない場合は次のＳＣＬを調べる。そのような場合、ＳＣＬ−２は、リソースにアクセスするための通信をＳＣＬ−３（例えば、公表先ＳＣＬ）に送信する。ＳＣＬ−３が公表リソースを持っている場合は、ＳＣＬ−３はリソースアクセス通信をＳＣＬ−４（例えば、ホスティングＳＣＬ）に送信する。ホスティングＳＣＬはアクセス権を調べ、許可される場合は、リソースにアクセスし、成功の通知で応答を返す。そうでない場合、ホスティングＳＣＬはエラーで応答する。応答は図示するように通信される。

図７に、非同期方式で公表リソースにアクセスする場合の例示的な流れ図を示す。図７を参照すると、ＳＣＬ−１またはアプリケーション（例えば発行者）は、リソースにアクセスするための通信をＳＣＬ−２（例えばローカルＳＣＬ）に送信する。それに応答して、ＳＣＬ−２は要求を確認し、そのリソースを持っていない場合は次のＳＣＬを調べる。この場合、ＳＣＬ−２は、リソースにアクセスするための通信をＳＣＬ−３（例えば、公表先ＳＣＬ）に送信する。その通信およびＳＣＬ−３が公表リソースを持っていると判定されるのに応答して、ＳＣＬ−３はリソースのＵＲＩで応答を返し、リソースＵＲＩを知らせる応答メッセージがＳＣＬ−２およびＳＣＬ−１に通信される。ＳＣＬ−１がホスティングＳＣＬからリソースを取得することを決定すると、ＳＣＬ−１は、リソースＵＲＩを使用してリソースアクセスメッセージをＳＣＬ−４（例えば、ホスティングＳＣＬ）に送信する。それに応答して、ホスティングＳＣＬはアクセス権を確認し、許可される場合は、リソースにアクセスし、成功の通知で応答を返す。そうでない場合、ホスティングＳＣＬはエラーで応答を返す。応答は図示するようにＳＣＬ−１に通信される。

公表リソースは公表を取り消すことができる。例えば公表リソースに失効時間がある場合には、公表の取消しは暗黙的に行われる。発行者は、以前に公表したリソースの公表取消しを要求する。公表取消しのトリガとなるのは、例えば、リソースがホスティングＳＣＬに存在しなくなったか、または公表手順の発行者（例えば、ホスティングＳＣＬまたはアプリケーション）が自身のリソースの公表を望まなくなったためかのいずれかである。

発行者からのトリガにより、ホスティングＳＣＬは、以前に公表したリソースの公表を取り消すことを決定する。ホスティングＳＣＬ自身が発行者である場合もある。ホスティングＳＣＬは、公表先ＳＣＬに「公表取消し」要求メッセージを送信して、１つまたは複数のリソースの「公表取消し」をする。公表取消し要求で、ホスティングＳＣＬは、１つまたは複数の公表リソースを指示する。各公表リソースは識別子で指示される。公表取消しメッセージを受信すると、公表先ＳＣＬは、公表リソースを削除し、削除のステータスの応答をホスティングＳＣＬに送信する。公表先ＳＣＬが公表リソースを他のＳＣＬに伝搬していた場合は、公表先ＳＣＬは、それらのリソースの公表を取り消すための公表取消し要求も伝搬する。

一実施形態により、図８に、リソース公表取消しの例示的流れ図を示す。図８を参照すると、ＳＣＬ−１またはアプリケーション（例えば、発行者）が、公表取消しのための通信をＳＣＬ−２（例えば、ローカルＳＣＬ）に送信する。ＳＬＣ−２がそのリソースを持っている場合、ＳＣＬ−２は要求リソースの公表取消しをトリガし、公表取消しの通信をＳＣＬ−３（例えば、公表先ＳＣＬ）に送信する。それに応答して、ＳＣＬ−３は、発行者からの公表リソースを削除する。応答は図示するようにＳＣＬ−１に通信される。

公表／公表取消しには構造および／または規則が関連付けられる。ｓｅａｒｃｈＳｔｒｉｎｇ属性を持つリソースは、公表されることが可能である。公表可能な各リソースについて、属性で、そのリソースを公表すべきか否かを定義する。公表できる場合は、リソースは、どのように公表するかについての規則に関連付けられる（例えば存続期間、最新化等）。

公表される各リソースは、そのリソースをホストするＳＣＬ（例えば、ホスティングＳＣＬ）がどのように公表を管理するかに関する情報、例えば公表規則を必要とする。その情報は、リソースに関連する属性のリスト、属性リストを備えるリソースに関連するデータ構造、リソースのサブリソース、それらの何らかの組合せ等に含められる。

公表情報は、アプリケーションリソースに結び付けられたリスト属性に含められる。例えば、下記の表１にリソースの例示的な属性を示す。記号「^＊」は公表属性を表す。

下記は、「アプリケーション」リソースに関連する公表情報の一例である。同様の形式が他のリソースタイプ、すなわち「ｇｒｏｕｐ」リソース、「ｃｏｎｔａｉｎｅｒ」リソース、「ａｃｃｅｓｓＲｉｇｈｔ」リソース等に適用される。

発行者がアプリケーションの場合は、上記表で必須と示された属性は任意となり、最終的な決定はホスティングＳＣＬに委ねられる。ホスティングＳＣＬは、元のリソースを作成したアプリケーションによって定義された公表規則を実行する。規則がアプリケーションによって定義されない場合は（例えば、アプリケーションは自身のリソースがどのように公表されるかについて関与しない場合もある）、ホスティングＳＣＬが、上記表で必須の項目として定義された規則を履行する。

公表情報は、例えば下記のように、アプリケーションリソースのサブリソースとして含められる。記号「^＊」は公表属性を意味する。

公表先リソースを格納するための構造が提供される。例えば、図９に、<sclBase>/scls/scl/applications/applicationAnncにある公表アプリケーションリソースを格納するための例示的なリソース構造を示す。

公表先リソースは、ｓｃｌＢａｓｅの下に格納される。公表の目的は、リソースを発見することである。公表リソースを集中化された場所に置くことにより、リソースの発見を最適化する。例えば、<sclBasel>./announcedToに対するＧＥＴ要求で公表リソース（例えば、すべての公表リソース）を取得する。要求元が特定の公表先リソースを得る必要がある場合、それらのリソースは異なるタイプの下に格納されている可能性がある。公表先リソースは、特定のリソースを見つけるために使用される検索文字列属性を有する。図１０に、公表先リソースを格納する例示的なリソース構造を示す。図１０を参照すると、アプリケーション１からの公表先リソースは、<sclBasel>/announcedTo/applicationAnnc/application1 Anncから取得される。

公表先リソースの属性が提供される。公表リソースは、元のリソースに戻るリンク（例えば図４参照）と、元のリソースの発見を助けるｓｅａｒｃｈＳｔｒｉｎｇを含む。公表リソースは、例えば下記表に示される記号（「^＊」）で示される追加的な属性を含む。伝搬が許可される場合は、元のリソースの公表属性が公表リソースに含められる。

公表／公表取消しの更新が提供される。リソースを公表する手順を使用して、可能性のある公表先ＳＣＬにリソースを公表し、手順はｍＩａ／ｄＩａにおける対話とｍＩｄにおける対話とに分けられる。ｓｅａｒｃｈＳｔｒｉｎｇを持ち、ＵＲＩでアドレス指定できるリソースが公表される。ＳＣＬは、自身が登録されているＳＣＬであって、公表要求を受け付けることが可能なＳＣＬにリソースを公表する。

ｄＩａ／ｍＩａにおける公表の手順が提供され、これは、発行者を、そのリソースの該当する属性を変更することにより他のＳＣＬへのリソース公表を要求するアプリケーション（ＤＡ、ＧＡ、ＮＡ）として指定する。公表手順のトリガとなるのは、発行者のローカルＳＣＬへの登録、ローカルＳＣＬにおける新しいリソースの作成、ローカルＳＣＬにおけるリソースの更新等である。

発行者は、自身が要求する公表の種類の詳細を示す公表属性リストがある場合は、そのリストを提供する。属性リストは、公表リソースの存続期間と、公表の範囲（例えば、公表は特定のＳＣＬに行うべきか、またはその決定がローカルＳＣＬに委ねられるかどうか）と、公表動作を発行者に対して確認する必要があるかどうかと、または公表の有効化（例えばＡＣＴＩＶＥまたはＩＮＡＣＴＩＶＥ）（その場合属性リストを埋めることは可能であるが、公表は行わない）と、の１つまたは複数を指示する。属性リストは、例えば登録時にアプリケーションによって提供され、そのローカルＳＣＬに発行者によって作成されたリソース、および／またはローカルＳＣＬで発行者によって作成された各リソースに適用することができる。

発行者は、リソースに対するＵＰＤＡＴＥを使用して公表属性リストに変更を加える。公表のための属性リストは、リソース構造を変更することを必要とする場合がある。リソース構造は、現在の定義に加えて上記の項目を含む。「ａｎｎｏｕｎｃｅｄＴｏ」属性は、特定のサブリソース、すなわちグループ、コンテナ、アクセス権等の下で配布される。

ローカルＳＣＬは、受信した要求の有効性を検査する。ローカルＳＣＬは、ａｃｃｅｓｓＲｉｇｈｔに照らして発行者に受信した要求を行う権限がある場合は、ｍＩｄにおける公表手順をトリガする。ローカルＳＣＬは、汎用的な応答を返す。

ホスティングＳＣＬを指定する、ｍＩｄにおける公表手順が提供される。公表属性リストに基づいて、ホスティングＳＣＬは、ＣＲＥＡＴＥを使用して、ｍＩｄで公表先ＳＣＬにリソースを公表する。ホスティングＳＣＬはリソースの表現を形成し、その表現、ホスティングＳＣＬの識別、検索文字列、失効時間等を含む「公表リソース」要求を公表先ＳＣＬに送信する。ホスティングＳＣＬは、同じリソースを複数のＳＣＬに公表することが可能である。公表属性リストで指定されない限り、ホスティングＳＣＬが、公表対象のＳＣＬを決定する。

公表先ＳＣＬは、受信した要求の有効性を検査し、指定された属性を持つ公表リソースを作成する。作成は、定義されたａｃｃｅｓｓＲｉｇｈｔに照らしてホスティングＳＣＬに子リソースを作成する権限がある場合に許可される。作成が成功すると、公表先ＳＣＬは、ホスティングＳＣＬに成功の応答を返し、応答は作成された公表リソースの識別子（例えばＵＲＩ）を含む。作成が成功しない場合、公表先ＳＣＬは、該当するエラーメッセージを返す。汎用的な応答が提供される。

下記のように、応答メッセージには代替法がある。発行者がアプリケーションであり、公表対象のＳＣＬを指示しない場合、ホスティングＳＣＬは、要求を受信すると発行者に応答を送信し、要求がホスティングＳＣＬに受け付けられたことを知らせる。ホスティングＳＣＬは、公表する時間と公表するＳＣＬを決定する。発行者がアプリケーションであり、公表対象のＳＣＬを指示している場合、ホスティングＳＣＬは、リソースの公表が完了した後に応答し、それにより発行者に、公表されたリソースのステータスの通知を提供する（例えば図１１に示すように）。

Ｋ個のＳＣＬへの公表が失敗した場合は、複数の確認が処理される。タイマが開始し、確認を待つ。タイマが満了すると、各確認を組み合わせて１つの応答にし、かつ／または各公表に個別に受信通知が返される。失敗した公表については、ホスティングＳＣＬは、周期的に公表の試みを続ける。ホスティングＳＣＬはＮＡＣＫを返送し、アプリケーションに次にとる行動を決定させる。これは、何らかの閾値（または成功した公表の割合）、または何らかの公表の優先順位付けしたリスト（例えばあるＡＣＬが公表先としてより重要である場合）に基づく。公表要求は、確認が必要でないことを指示することもでき、その場合は応答を送信する必要はない。発行者がどのＳＣＬにリソースが公表されるのかを知りたい場合は、公表イベントに登録する。

図１１に、リソース公表の例示的な呼び出しの流れを示す。図１１を参照すると、アプリケーションが公表要求をＳＣＬ−２に対して発行し、ＳＣＬ−２はローカルＳＣＬおよび／またはホスティングＳＣＬである。リソースはＳＣＬ−２に格納される。アプリケーションに応答が提供される。それに応答して、ＳＣＬ−２はリソースを公表し、リソース公表メッセージをＳＣＬ−３に送信するようにトリガされ、ＳＣＬ−３は図に示すように応答する。

リソースの発見を支援するために公表リソースを伝搬する必要がある事例がある。例えば、図１２に、公表リソースを伝搬する使用事例の例示的な図を示す。図１２を参照すると、Ｇ−ＳＣＬ１は、Ｄ’２と呼ばれるＤ’タイプ装置に対応するローカルＳＣＬ（例えば登録ＳＣＬ）であり、ＤＡ２のホスティングＳＣＬである。Ｇ−ＳＣＬ１は、ＤＡ２のリソースをＮ−ＳＣＬに公表し、それによりＮ−ＳＣＬが第１の公表先ＳＣＬになる。Ｎ−ＳＣＬは、公表リソースをＧ−ＳＣＬ２に伝搬する（それにはＧ−ＳＣＬ２がＮ−ＳＣＬに登録されていることが前提となる）。Ｎ−ＳＣＬはコアであるため、アクセス権およびセキュリティ、ならびに伝搬できる相手についての知識を十分に持っている。そしてＧ−ＳＣＬ２が第２の公表先ＳＣＬになる。この仕組みにより、ＤＡ３は、Ｇ−ＳＣＬ１にあるリソースを発見する。上記の仕組みに合致する場合は、以下が公表手順に含められる。

公表先ＳＣＬは、自身が接続されている他のＳＣＬに公表リソースを伝搬する。許可される場合は、公表先ＳＣＬは公表リソースを他のＳＣＬに伝搬する。公表先ＳＣＬは、公表リソースの属性の一部を取り出し、簡略化した公表リソースを伝搬する。公表リソースの作成がループすることを回避するために、公表リソースは、「公表先ＳＣＬ」のリストを含む属性を有する。

図１３に、公表リソースを伝搬する場合の例示的な呼び出しの流れを示す。発行者（例えばＤＡ２）が公表を要求し、それによりＧ−ＳＣＬ１がトリガされてリソースを公表する。Ｎ−ＳＣＬは、公表リソースを作成し、公表リソースを図示のように伝搬する。

公表リソースを更新する手順が提供され、以前に公表したリソースを更新する。更新は、ｍＩｄインタフェースで行われるか、または元のリソースの変更の結果公表リソースに変更が生じた場合はｄＩａ／ｍＩａインタフェースが関与する。

ｄＩａ／ｍＩａで公表リソースを更新する手順が提供され、この手順は、アプリケーションがローカルＳＣＬ（ホスティングＳＣＬ）にある自身が作成したリソースの変更を要求すると、ホスティングＳＣＬがトリガされて公表リソースを更新することを指示する。この更新は、元のリソースのｓｅａｒｃｈＳｔｒｉｎｇ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、またはＵＲＩが変化した時に必要となる。例えば、元のリソースに内容の変更がある場合があり、それにより公表リソースのｓｅａｒｃｈＳｔｒｉｎｇに変更が生じる。

ｍＩｄで公表リソースを更新する手順が提供され、この手順では、発行者（ホスティングＳＣＬ）がｍＩｄインタフェースのＵＰＤＡＴＥ動詞を使用して公表リソースを更新する要求メッセージを作成することが指示される。以前にリソースを公表したホスティングＳＣＬが、公表リソースを更新するエンティティである必要がある。

公表先ＳＣＬは、その要求に従って公表リソースを更新する。公表リソースの更新が成功すると、公表先ＳＣＬは成功コードを発行者（ホスティングＳＣＬ）に返す。そうでない場合はエラーコードを返す。

図１４に、公表リソースを更新する場合の例示的な呼び出し流れ図を示す。図１４の例では、発行者がホスティングＳＣＬであり、行われる動作は図示の通りである。

以前に公表したリソースの公表取消しを指示する、リソースの公表を取り消す手順が提供される。公表取消しは、公表リソースに失効時間がある場合は暗黙的に行われる。以前に公表したリソースの公表取消しは、元のリソースに影響を及ぼさない。

ｄＩａ／ｍＩａにおける公表取消しの手順が提供され、以前に公表したリソースの公表取消しを要求する発行者（例えば、アプリケーションＤＡ、ＧＡ、ＮＡ）を指定する。公表取消しのトリガとなるのは、発行者が元のリソースの更新または削除を行ったことである。

ローカルＳＣＬは、受信した要求の有効性を検査する。ａｃｃｅｓｓＲｉｇｈｔに照らして発行者に受信要求を行う権限がある場合は、ローカルＳＣＬがｍＩｄにおける公表取消し手順をトリガする。ローカルＳＣＬは、汎用的な応答を発行者に返す。ローカルＳＣＬは、ｍＩｄインタフェースからの結果を待たずに、公表取消し要求に応答する。公表取消しが元のリソースの削除によってトリガされる場合、ｍＩｄで公表取消しが完了した後に元のリソースがもはや利用可能でない場合もあるため、ローカルＳＣＬはそのような応答法を使用する。ホスティングＳＣＬは、ｍＩｄのリソースの公表取消しを完了した後に応答し、それにより、公表が取り消されたリソースのステータスに関する通知を発行者に提供する（図１５に示すように）。

ｍＩｄで公表取消しする手順が提供され、この手順では、公表が失効した結果、または発行者からのトリガ（例えば公表属性リストの変更）等に基づいて、リソースの公表取消しを決定することが可能なホスティングＳＣＬを指定する。ホスティングＳＣＬは、ｍＩｄインタフェースを通じてＤＥＬＥＴＥを使用して「公表取消し」要求メッセージを公表先ＳＣＬに送信して、以前に公表したリソースの公表を取り消す。公表取消し要求で、ホスティングＳＣＬは、１つまたは複数の公表リソースを指示する。公表リソースを削除するのはホスティングＳＣＬの役割である。

公表先ＳＣＬは受信した要求の有効性を検査し、指定された属性を持つ公表リソースを削除する。削除は、定義されたａｃｃｅｓｓＲｉｇｈｔに照らしてホスティングＳＣＬに子リソースを削除する権限がある場合に許可される。削除が成功すると、公表先ＳＣＬは、成功の応答をホスティングＳＣＬに返す。削除が成功しなかった場合は、公表先ＳＣＬは該当するエラーメッセージを返す。

公表リソースに失効時間がある場合、公表取消しは暗黙的に行われる。応答メッセージがホスティングＳＣＬ（公表元ＳＣＬ）に送信されて、公表リソースの公表が取り消されることを知らせる。ホスティングＳＣＬ（公表元ＳＣＬ）がサーバ機能を持たない場合は、サブスクリプション機構が使用される。

図１５に、リソースの公表を取り消す場合の例示的な呼び出しの流れを示す。発行者がリソースの公表取消しを要求し、それによりＳＣＬ−２がトリガされて要求されるリソースの公表を取り消す。ＳＣＬ−２はリソースを削除し、ＳＣＬ−３にリソース公表取消し要求を送信し、ＳＣＬ−３がリソースを削除する。応答は図示のように行われる。

公表リソースを伝搬してよいことが合意されている場合は、次の手順が使用される。公表先ＳＣＬが公表リソースを他のＳＣＬに伝搬している場合は、それらのリソースの公表を取り消すための公表取消し要求も伝搬する。

上記では特定の組合せで特徴および要素について説明したが、当業者は、各特徴または要素は単独で、または他の特徴および要素と任意の組合せで使用できることを認識されよう。また、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアとして実装される。コンピュータ可読媒体の例は、電子信号（有線または無線接続を通じて伝送される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、これらに限定されないが、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクや取外し可能ディスク等の磁気媒体、光磁気媒体、およびＣＤ−ＲＯＭディスクやデジタル多用途ディスク（ＤＶＤ）等の光学媒体を含む。ソフトウェアと関連したプロセッサが使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、またはホストコンピュータで使用するための無線周波トランシーバを実装する。

Claims (14)

1. 第１のエンティティがリソースの公表を１つまたは複数のネットワークを介して伝搬するための方法であって、
   リソースを公表する要求を発行者から受信するステップと、
   公表リソースを作成するステップであって、前記公表リソースは前記リソースの表現を含む、ステップと、
   ｍＩｄインタフェース上で第２のエンティティにリソース公表要求を送信するステップと、
   前記第２のエンティティが前記公表リソースを作成したことを示す第１の応答を、前記ｍＩｄインタフェース上で前記第２のエンティティから受信するステップと
   を具えたことを特徴とする方法。
2. 前記発行者はサービス能力層またはアプリケーションの一方であることを特徴とする請求項１記載の方法。
3. 前記第２のエンティティは前記第１のエンティティに登録していることを特徴とする請求項１記載の方法。
4. 前記表現は、検索文字列、属性、または前記リソースのＵＲＩ、の１つまたは複数を含むことを特徴とする請求項１記載の方法。
5. 前記リソースのアクセス可能性に基づいて前記第２のエンティティが公表対象のエンティティであると判定するステップをさらに具えたことを特徴とする請求項１記載の方法。
6. 前記第１のエンティティは、前記公表リソースを既知のＵＲＩの下で前記第２のエンティティに公表することを特徴とする請求項３記載の方法。
7. 前記第２のエンティティが前記公表リソースを作成したことを示す第２の応答を前記発行者に送信するステップをさらに具えたことを特徴とする請求項１記載の方法。
8. １つまたは複数のネットワークを通じてリソースの公表を伝搬するように構成された第１のエンティティであって、
   リソースを公表する要求を発行者から受信するように構成された受信機と、
   公表リソースを作成するように構成されたプロセッサであって、前記公表リソースは前記リソースの表現を含む、プロセッサと、
   ｍＩｄインタフェース上で第２のエンティティにリソース公表要求を送信するように構成された送信機と
   を具え、
   前記受信機は、前記第２のエンティティが前記公表リソースを作成したことを示す第１の応答を、前記ｍＩｄインタフェース上で前記第２のエンティティから受信するようにさらに構成されたことを特徴とする第１のエンティティ。
9. 前記発行者はサービス能力層またはアプリケーションの一方であることを特徴とする請求項８記載の方法。
10. 前記第２のエンティティは前記第１のエンティティに登録していることを特徴とする請求項８記載の方法。
11. 前記表現は、検索文字列、属性、または前記リソースのＵＲＩ、の１つまたは複数を含むことを特徴とする請求項８記載の方法。
12. 前記プロセッサは、前記リソースのアクセス可能性に基づいて前記第２のエンティティが公表対照のエンティティであると判定するようにさらに構成されたことを特徴とする請求項８記載の方法。
13. 前記第１のエンティティは、前記公表リソースを既知のＵＲＩの下で前記第２のエンティティに公表することを特徴とする請求項１０記載の方法。
14. 前記送信機は、前記第２のエンティティが前記公表リソースを作成したことを示す第２の応答を前記発行者に送信するようにさらに構成されたことを特徴とする請求項８記載の方法。

Images