JP6462134B2 - サービス層におけるリソースリンク管理 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０９７３２６号（２０１４年１２月２９日出願、名称「ＲＥＳＯＵＲＣＥ ＬＩＮＫ ＭＡＮＡＧＥＭＥＮＴ ＡＴ ＳＥＲＶＩＣＥ ＬＡＹＥＲ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

図１は、サービス層１０４をサポートする例示的プロトコルスタックを図示する。図１に示されるように、プロトコルスタックの観点から、サービス層は、アプリケーションプロトコル層の上方に位置し、付加価値サービスをアプリケーションまたは別のサービス層に提供し得る。

Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションを標的とした例示的サービス層である。図２は、ネットワーク内の例示的Ｍ２Ｍ／ＩｏＴサービス層展開を図示する。この例では、サービス層インスタンスは、サービス層の実現であって、いくつかのサービス層インスタンスが、付加価値サービスをネットワークアプリケーション、デバイスアプリケーション、ならびにネットワークノード自体に提供するために、種々のネットワークノード（例えば、ゲートウェイおよびサーバ）上に展開される。産業規格団体（例えば、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−０．８．０）は、インターネット、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションの統合に関連付けられた課題に対処するために、Ｍ２Ｍ／ＩｏＴサービス層を展開している。Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ指向能力の集合へのアプリケーションおよびデバイスアクセスを提供することができる。そのような能力のいくつかのは、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含む。これらの能力は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用する、アプリケーションプログラムインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能にされ得る。

ｏｎｅＭ２Ｍの目標は、世界中のＭ２Ｍアプリケーションサーバを用いて現地の様々なデバイスをサポートするために、ハードウェア装置およびソフトウェアモジュール内に容易に埋め込まれることができる共通サービス層へのニーズに対処する技術仕様を開発することである。ｏｎｅＭ２Ｍ共通サービス層は、図３に示されるように、登録１０１および位置特定１０３等の共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード（ＩＮ）、ミドルノード（ＭＮ）、およびアプリケーション特定ノード（ＡＳＮ））上にホストされることができる共通サービスエンティティ（ＣＳＥ）と称される。ＣＳＥは、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＡＳＮ−ＣＳＥと呼ばれ得る。図４のＡＥ、ＣＳＥ、およびＮＳＥエンティティは、ソフトウェアの形態で実装され、下層デバイスまたはプラットフォーム上で実行され、システム内のそれらのそれぞれの機能を行う論理エンティティである。ＡＥ、ＣＳＥ、およびＮＳＥエンティティは、ネットワーク内の独立型コンピューティングデバイス（例えば、サーバ）上にホストされる、またはＭ２Ｍゲートウェイ、Ｍ２Ｍデバイス、Ｍ２Ｍサーバ等のネットワーク内の既存のエンティティ上にホストされ得る、論理エンティティである。

図４は、ｏｎｅＭ２Ｍサービス層リソース指向アーキテクチャ（ＲＯＡ）を図示する。リソースは、アーキテクチャ内の固有にアドレス可能な要素であり、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ（ＣＲＵＤ）等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有する。これらのリソースは、ユニフォームリソース識別子（ＵＲＩ）を使用して、アドレス可能にされることができる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。属性は、別のリソースを指す１つ以上のＵＲＩを記憶し得る。

最近、Ｍ２Ｍサービスコンポーネントアーキテクチャが、図５に示されるように、ＲＥＳＴｆｕｌベースではない旧来の展開を考慮するために開発されており、それは、主に、インフラストラクチャドメインのために好適であり、ＣＳＥは、サービスコンポーネントの組として見なされる。それは、概して、図４に示されるサービス層アーキテクチャを再使用するが、サービス層内に、種々のＭ２Ｍサービスを含み、複数のサービスが、サービスコンポーネントにグループ化されることができる。既存の参照点に加え、図５におけるＣＳＥは、サービス間参照点Ｍｓｃを含む。Ｍ２Ｍサービスコンポーネント間の通信（Ｍｓｃ参照点を経由してパスされる）は、ウェブサービスアプローチを利用し得、それは、サービス指向アーキテクチャ（ＳｏＡ）ベースのシステムを構築するための一般的技術である。

リンクプロファイルに基づいて、１つ以上のリンク対応属性を動的に構成し得る、リンク管理サービス（ＬＭＳ）が本明細書において開示される。独立リンク管理および統合されたリンク管理等、ＬＭＳをサポートする複数のタイプのアーキテクチャが、存在し得る。

ある実施例では、デバイスは、プロセッサと、プロセッサと結合されるメモリとを備えている。メモリは、プロセッサによって実行されると、プロセッサに、第１のプロファイルを受信することであって、第１のプロファイルは、属性のリンクの構成を定義する命令を含み、属性のリンクは、第１のリソースに向けられている、ことと、属性を管理するための指示を受信することと、第１のプロファイルに基づいて、属性の構成を自動的に決定することとを含む動作を達成させる実行可能命令を含む。

別の実施例では、方法は、第１のリンクプロファイルを受信することであって、第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含み、第１のリソースのリンクは、第２のリソースに向けられている、ことと、リンクを管理するための指示を受信することと、第１のリンクプロファイルに基づいて、リンクの使用を自動的に管理することとを含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
リソースリンクを管理するデバイスであって、前記デバイスは、
プロセッサと、
前記プロセッサと結合されたメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含み、前記第１のリソースの前記リンクは、第２のリソースに向けられている、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目２）
前記リンクの使用を管理することは、時間に基づいてトリガされる、項目１に記載のデバイス。
（項目３）
前記動作は、ルールの組を受信することをさらに含み、前記ルールの組は、前記第１のリンクプロファイルおよび第２のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目１から２のいずれか１項に記載のデバイス。
（項目４）
前記動作は、前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目１から３のいずれか１項に記載のデバイス。
（項目５）
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも１つを含む、項目１から４のいずれか１項に記載のデバイス。
（項目６）
前記リンクは、ユニフォームリソース識別子である、項目１から５のいずれか１項に記載のデバイス。
（項目７）
前記リンクの使用を管理することは、前記第１のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づく、項目１から６のいずれか１項に記載のデバイス。
（項目８）
リソースリンク管理のための方法であって、前記方法は、
第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含む、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む、方法。
（項目９）
前記第１のリソースの前記リンクは、第２のリソースに向けられている、項目８に記載の方法。
（項目１０）
ルールの組を受信することをさらに含み、前記ルールの組は、前記第１のリンクプロファイルおよび第２のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目８から９のいずれか１項に記載の方法。
（項目１１）
前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目８から１０のいずれか１項に記載の方法。
（項目１２）
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも１つを含む、項目８から１１のいずれか１項に記載の方法。
（項目１３）
前記リンクは、ユニフォームリソース識別子である、項目８から１２のいずれか１項に記載の方法。
（項目１４）
前記リンクの使用を管理することは、前記第１のリソースに関連付けられたデバイスのコンテキスト情報に基づく、項目８から１３のいずれか１項に記載の方法。
（項目１５）
コンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピューティングデバイスによって実行されると、
第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含む、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む動作を前記コンピューティングデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
（項目１６）
前記第１のリソースの前記リンクは、第２のリソースに向けられている、項目１５に記載のコンピュータ読み取り可能な記憶媒体。
（項目１７）
前記動作は、ルールの組を受信することをさらに含み、前記ルールの組は、前記第１のリンクプロファイルおよび第２のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目１５から１６のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
（項目１８）
前記動作は、前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目１５から１７のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
（項目１９）
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも１つを含む、項目１５から１８のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
（項目２０）
前記リンクの使用を管理することは、前記第１のリソースに関連付けられたデバイスのコンテキスト情報に基づく、項目１５から１９のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、サービス層をサポートする例示的プロトコルスタックを図示する。 図２は、ネットワーク内の例示的Ｍ２Ｍ／ＩｏＴサービス層展開を図示する。 図３は、ｏｎｅＭ２Ｍサービス層内の例示的共通サービス機能（ＣＳＦ）を図示する。 図４は、例示的ｏｎｅＭ２Ｍサービス層リソース指向アーキテクチャを図示する。 図５は、例示的ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャを図示する。 図６は、属性を介して、２つのリソース間に構築される例示的リンクを図示する。 図７Ａは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ１＞リソースから＜ＡＥ１＞および＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ１＞リソースに発生する複数のリンクの例示的例証である。 図７Ｂは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ１＞リソースから＜ＡＥ１＞および＜ＡＥ２＞に発生する複数のリンクの例示的例証である。 図８は、ＬＭＳを実装する、例示的システムを図示する。 図９は、独立リンク管理の例示的アーキテクチャフレームワークを図示する。 図１０は、統合されたリンク管理の例示的アーキテクチャフレームワークを図示する。 図１１は、単一Ｍ２Ｍ／ＩｏＴノード上の統合されたリンク管理の例示的アーキテクチャフレームワークを図示する。 図１２は、リンク管理タスクを作成するための例示的メッセージフローを図示する。 図１３は、スケジュールベースのリンクプロファイルに基づいて、リンク管理を実施するための例示的メッセージフローを図示する。 図１４は、非スケジュールベースのリンクプロファイルに基づいて、リンク管理を実施するための例示的メッセージフローを図示する。 図１５は、リンク管理タスクを削除するための例示的メッセージフローを図示する。 図１６は、ＬＭＳを用いてリンク元リソースを削除するための例示的メッセージフローを図示する。 図１７は、ＳＬＭＰを提出する、更新する、または削除するための要求を受信するときのＬＭＳの関連アクションの例示的方法を図示する。 図１８は、リンクプロファイル、ＳＬＭＰ、およびＥＨＲ間の例示的相互作用を図示する。 図１９は、ｏｎｅＭ２Ｍサービス層内の例示的（ＬＭＳ）ＣＳＦを図示する。 図２０は、＜ｌｉｎｋＰｒｏｆｉｌｅ＞の例示的ＲＥＳＴｆｕｌリソースベースのインターフェースを図示する。 図２１は、＜ＳＬＭＰ＞の例示的ＲＥＳＴｆｕｌリソースベースのインターフェースを図示する。 図２２は、＜ＥＨＲ＞の例示的ＲＥＳＴｆｕｌリソースベースのインターフェースを図示する。 図２３は、例示的ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャを図示する。 図２４は、ＬＭＳ−ＳＬＭＰによって有効にされる付加価値サービスのための例示的メッセージフローを図示する。 図２５は、ＬＭＳ−リンクプロファイルによって有効にされる付加価値サービスのための例示的メッセージフローを図示する。 図２６は、＜ｇｒｏｕｐ＞リソースの「ｍｅｍｂｅｒＬｉｓｔ」におけるＬＭＳの例示的動作を図示する。 図２７は、リソースリンク管理を利用するための例示的ユーザインターフェースを図示する。 図２８Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２８Ｂは、図２８Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２８Ｃは、図２８Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２８Ｄは、図２８Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−０．８．０では、リンクがリソース間に構築されることができ、リソースは、別のリソースに向かう１つ以上のリンクを有することができることを示す。本明細書で検討されるリンクは、ＵＲＩを１つのリソースの属性内に記憶するとき、２つのリソース間に構築され得、リンクは、別のリソースに向かっている。例えば、リンクは、リソース−ＢのＵＲＩをリソース−Ａの属性（例えば、属性−１）に割り当てることによって、リソース−Ａからリソース−Ｂに構築されることができる。リンク管理タスクは、リンクプロファイルをＬＭＳに提出することを通して、エンティティによって構築されることができる。リンク管理タスクは、その（その共有）リンクプロファイルに基づいて、１つ以上の属性に対する構成を行うＬＭＳを参照し得る。タスクは、対応するリンクプロファイルがＬＭＳから削除された場合（エンティティによって）、ＬＭＳから削除され得る。図６は、２つのリソース間の例示的リンクを図示する。図６に示されるように、ロジックリンク１１２は、リソース−Ｂ １１３のＵＲＩをリソース−Ａ １１１の属性（属性−１ １１５）に割り当てることによって、リソース−Ａ １１１からリソース−Ｂ １１３に構築される。本明細書では、リソース−Ａ １１１は、リンク元リソース、リソース−Ｂ １１３は、リンク先リソース、属性−１ １１５は、ロジックリンク１１２のリンク対応リソース（属性−１ １１５内のＵＲＩの表現）と称される。図６に関する例によってサポートされるように、リンク元リソースは、別のリソース（例えば、リソース−Ｂ １１３）に向かうＵＲＩを含む属性等（例えば、属性−１ １１５）を記憶するリソース（例えば、リソース−Ａ １１１）である。リンク対応属性は、リソース（例えば、リソース−Ｂ １１３）にリンクし、別のリソース（例えば、リソース−Ａ １１１）内に位置するＵＲＩを記憶する属性等（例えば、属性−１ １１５）である。最後に、リンク先リソースは、リソース（例えば、リソース−Ａ １１１）内に位置するＵＲＩの宛先であるリソース（例えば、リソース−Ｂ １１３）である。

表１は、リンクを構築するために使用され得る、ｏｎｅＭ２Ｍ仕様からの例示的属性を提供する。図７Ａは、表１から得られたリンク対応属性を伴う実施例を図示する。図７Ａに示されるように、＜ｓｕｂｓｃｒｉｐｔｉｏｎ１＞リソースの２つの属性（例えば、「ｐａｒｅｎｔＩＤ」および「ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ」）が、それぞれ、＜ＡＥ１＞および＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ１＞リソースのＵＲＩで設定されている。２つのリンクは、故に、＜ｓｕｂｓｃｒｉｐｔｉｏｎ１＞と２つのリソース（例えば、＜ＡＥ１＞および＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ１＞）との間に構築される。図７Ｂは、図７Ａに類似しており、非スケジュールベースのリンクプロファイルリンクプロファイルに関して以下により詳細に論じられるであろう。

リンクプロファイルに基づいて１つ以上のリンク対応属性を動的に構成し得るリンク管理サービス（ＬＭＳ）が開示される。独立リンク管理および統合されたリンク管理等、ＬＭＳをサポートする複数のタイプのアーキテクチャが、存在し得る。独立リンク管理および統合されたリンク管理は、本明細書により詳細に論じられる。

図８は、ＬＭＳを実装する、例示的システムを図示する。Ｍ２Ｍサーバ１２４は、リンク管理に関連付けられた発信側１２３を含み得る。発信側１２３は、Ｍ２Ｍサーバ１２４内に位置し、他のデバイスの中でもとりわけ、Ｍ２Ｍゲートウェイ１２２、Ｍ２Ｍデバイス１２５、Ｍ２Ｍデバイス１２６、およびＭ２Ｍデバイス１２７に通信可能に接続され得る。発信側１２３は、サービスのためのアプリケーション（例えば、アプリケーションエンティティ−ＡＥ）であり得る。発信側１２３は、１）リンクプロファイル（例えば、リンクプロファイル１２８）をＬＭＳ１２１に提出すること、２）リンクプロファイルを更新すること、または、３）リンクプロファイルをＬＭＳ１２１から削除または登録解除することに対する要求を開始することができる。要するに、発信側１２３は、リンク管理関連要求を初期化する。発信側１２３は、リンク管理関連要求を開始するための許可を有するべきである。代替として、発信側１２３は、リソースの所有者であるので、リンク対応属性（例えば、属性−１ １１５）が属するリンク元リソース（例えば、リソース−Ａ １１１）を作成する、エンティティであり得る。発信側１２３は、ある属性に対するリンク管理を開始し得る任意の数のエンティティまたはデバイス（例えば、ＡＥ、共通サービスエンティティ−ＣＳＥ、ネットワークサービスエンティティ−ＮＳＥ、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、Ｍ２Ｍデバイス等）であり得る。

Ｍ２Ｍゲートウェイ１２２は、ＬＭＳ１２１を含むことができる。ＬＭＳ１２１は、リンクプロファイル１２８を含み、他のデバイスの中でもとりわけ、発信側１２３およびＭ２Ｍデバイス１２５、Ｍ２Ｍデバイス１２６、およびＭ２Ｍデバイス１２７と通信可能に接続され得る。ＬＭＳ１２１は、発信側１２３によって提出されたリンクプロファイル１２８に基づいて、属性−１ １１５のためのリンク管理を実施する責任がある。ＬＭＳ１２１は、リンクホストＣＳＥまたは別のＣＳＥ上に常駐し得る。リンクホストＣＳＥは、リンク元リソース（例えば、リソース−Ａ １１１）およびそのリンク対応属性（例えば、属性−１ １１５）がホストされている場所である。ＬＭＳ１２１は、本明細書に定義されるようなあるプロシージャを通して同様に更新／削除され得るリンクプロファイル１２８内に含まれる命令に基づいてリンク構成を実施する実行側としての役割を果たす。Ｍ２Ｍデバイス１２５、Ｍ２Ｍデバイス１２６、およびＭ２Ｍデバイス１２７は、Ｍ２Ｍゲートウェイ１２２およびそのサブコンポーネントと通信可能に接続され、Ｍ２Ｍサーバ１２４およびそのサブコンポーネントとも通信可能に接続され得る。各Ｍ２Ｍデバイスは、Ｍ２Ｍデバイス１２５内に見出されるようなリンク対応属性（例えば、属性−１ １１５）を有するリンク元リソース（例えば、リソース−Ａ １１１）を有し得る。

図８を継続して参照すると、以下は、芝手入れサービスに関してＬＭＳを使用する例である。例えば、Ｍ２Ｍデバイス１２６、Ｍ２Ｍデバイス１２７、およびＭ２Ｍデバイス１２５は、風力センサ、湿度センサ、または温度センサ等のセンサであり得る。感覚データに関する通知を送信するために、各Ｍ２Ｍデバイス（１２５、１２６、および１２７）によってホストされる＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース（例えば、リソース−Ａ １１１）が、存在し得る。リンクプロファイル（例えば、リンクプロファイル１２８）が、Ｍ２Ｍデバイス（１２５、１２６、および１２７）上にホストされる＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ」属性（例えば、属性−１ １１５）のために生成され得る。リンクプロファイルは、いつ、どのように、またはどの通知が、芝手入れサービス（例えば、発信側１２３）によって行われる芝手入れスケジュールのために必要とされるかをカスタマイズすることに役立ち得る情報を有し得る。これらのリンクプロファイルは、ＬＭＳ１２１に提出され、ＬＭＳ１２１は、リンクプロファイルに基づいて、リンクを管理する。

図９および図１０は、リンク管理のアーキテクチャフレームワークを図示する。図９は、独立リンク管理を図示する。要するに、独立リンク管理は、リンクプロファイル（例えば、リンクプロファイル１２８）に基づいて、リンク管理を実行するが、リンクプロファイル間の衝突を考慮しない。図９に示されるように、リンクプロファイル１２８は、ＬＭＳ１２１に提出される。加えて、リンクプロファイル１２８は、リソース−Ａ １１１の属性−１ １１５を定義する。ＬＭＳ１２１は、提出されたリンクプロファイル１２８に基づいて、属性−１ １１５を構成する。

ＬＭＳは、異なるリソースの複数のリンク対応属性に対して統合されたリンク構成を実施する能力も有する。統合されたリンク管理（図１０）は、それらの複数のリンク対応属性に対する構成が、互いに影響および相関され得、したがって、リンク対応属性に対する構成は、その関連付けられたリンクプロファイルを参照するだけでなく、存在する場合、あるシステム全体にわたるポリシに準拠する必要もあることを提供する。例えば、ＬＭＳは、ソースが別のＣＳＥに移行されると、全リソースの親ＩＤ属性を更新する責任があり得る。加えて、ＬＭＳは、それに提出されるカスタマイズされたポリシ、または既存もしくは将来的規格仕様に準拠するポリシに従い得ることに留意されたい。

図１０は、リンク管理のための例示的拡張または統合されたフレームワークを図示する。この例では、統合されたフレームワークは、例外ハンドリングルール（ＥＨＲ）１３１と、サービス層全体にわたるリンク管理ポリシ（ＳＬＭＰ）１３３と、複数のリンクプロファイル（例えば、リンクプロファイル１２８およびリンクプロファイル１３６）と、ＬＭＳ１２１と、属性−１ １３５を伴うリソース−Ｚ １３４と、属性−１ １１５を伴うリソース−Ａ １１１とを含む。図１１は、Ｍ２ＭまたはＩｏＴノード（例えば、Ｍ２Ｍゲートウェイ１２２）のサービス層内に限られる、図１０に示される概念を図示する。リンク管理フレームワークの異なるコンポーネントは、以下により詳細に論じられる。ＬＭＳ１２１に関して、ＬＭＳ１２１は、そのリンクプロファイルに従って、異なるリンク対応属性を管理する責任がある。例えば、ＬＭＳ１２１では、リンクプロファイルが提出された後、提出されたリンクプロファイルの各々に対応する特定のリンク管理タスクが、構築され得る。例えば、リンク管理タスクをＬＭＳ１２１において構築することに関して、プロファイルは、最新の温度について異なるアプリに知らせるための＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性等の属性を構成する方法を含み得る。従われるべき構成命令は、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩが、９ａｍ−３ｐｍの間、ＷｅａｔｈｅｒＲｅｐｏｒｔＡｐｐのＵＲＩに設定され、３ｐｍ−１１ｐｍの間、ＴｒｉｐＰｌａｎｎｉｎｇＡｐｐのＵＲＩに設定されるであろうことを含み得る。ＬＭＳは、対応するデバイスを初期化し、そのリンクプロファイル内に規定された前述の命令に従うことによって、前述のリンク構成を実施するための動作を実行し得る。

典型的には、リソース−Ａ １１１の属性−１ １１５のためのリンクプロファイル１２８は、リソース−Ａ １１１および属性−１ １１５がすでに作成されている場合、生成され、ＬＭＳ１２１に提出されることができる。その後、作成されたリンク対応属性（例えば、属性−１ １１５）の値を自ら構成することを他のエンティティに要求する代わりに、ＬＭＳ１２１は、前述のようなその必要性に基づいて、あるエンティティによって生成され得るリンクプロファイル（例えば、リンクプロファイル１２８およびリンクプロファイル１３６）内に含まれる仕様に基づいて、作成されたリンク対応属性をそれらのエンティティの代わりに構成することができる。他のエンティティは、その必要性に基づいて、動的リンク管理動作のためにＬＭＳを使用するＣＳＥまたはアプリケーション関連ソフトウェアインスタンスのいずれかであり得る。例えば、依然として、前述のＷｅａｔｈｅｒＲｅｐｏｒｔ Ａｐｐの例を使用すると、温度デバイスを管理する責任があるソフトウェアインスタンス（他のエンティティ）は、温度センサからの最新更新について異なるアプリ（例えば、ＷｅａｔｈｅｒＲｅｐｏｒｔ ＡｐｐまたはＴｒｉｐＰｌａｎｎｉｎｇ Ａｐｐ）に知らせるために、特定の＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ」属性のためのリンクプロファイルを構築することができる。ＬＭＳ１２１と属性−１ １１５（管理されるべきリンク対応属性）とが、同じ場所に位置する（例えば、リソース−Ａ １１１が、ＬＭＳを本質的にサポートするＣＳＥ上にある）場合、属性−１ １１５は、ＣＳＥの内側に構成され、それは、通信オーバーヘッドの削減につながる。加えて、ＬＭＳ１２１は、コンピューティングリソースが存在する限り、任意のノード（例えば、ＡＳＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＩＮ−ＣＳＥ）上に展開されることができる。属性−１ １１５は、そのリンクプロファイル１２８に従ってＬＭＳ１２１によって動的に構成される現在の有効な値を記憶する。ＬＭＳ１２１によってリンクがどのように構成されるかは、属性−１ １１５の値を読み出すための許可がない限り、隠され得る。

ＳＬＭＰ１３３は、関連属性（例えば、属性−１ １１５および属性−１ １３５）に対するリンク構成が、そのリンクプロファイルに加え、さらに準拠する必要がある規制または制約の組である。ＳＬＭＰは、それらの属性に対して独立構成を実施するために使用されるリンクプロファイルに加え、異なる属性におけるリンク構成がどのように互いに影響され得るかについての全体的規制および制約の組である。リンクプロファイル１２８と同様に、ＳＬＭＰ１３３も、それが許可されたエンティティによって、ＬＭＳ１２１に提出されることができる。ＳＬＭＰ１３３に関する例は、ｏｎｅＭ２Ｍの「ｐａｒｅｎｔＩＤ」に関連し得る。ＳＬＭＰ１３３は、いくつかのアプリケーション特定のセキュリティ理由に起因して、ある組のリソース（例えば、リソース−Ｚ １３４）が、同一親を別の組のリソース（例えば、リソース−Ａ １１１）と共有することが不可能であるというルールを含み得る。

図１１および統合されたリンク管理を継続して参照すると、ＥＨＲ１３１は、リンク構成における例外に対処するために使用される、ルールを有する。所与のＳＬＭＰに対して、同様に、例外ハンドリングルールの対応する組が、存在し得、それらは、そうすることを許可されたエンティティによってＬＭＳ１２１に提出され得る。ＬＭＳ１２１が、あるリンク対応属性（例えば、属性−１ １１５または属性−１ １３５）を構成すると、ＬＭＳ１２１は、関連リンクプロファイル（例えば、リンクプロファイル１２８およびリンクプロファイル１３６）だけでなく、関わるＳＬＭＰも考慮し、任意の衝突が存在する場合、ＥＨＲを適用する。ＥＨＲは、リンクプロファイル内に含まれる独立構成がＳＬＭＰと衝突を有するときに使用されるルールの組である。

時として、好ましい実装は、ｍＣＳＥによってホストされるリソースの全部または大部分のリンク対応属性のリンクプロファイルを同一ＬＭＳ（例えば、ＬＭＳ１２１）に提出させ得、そのようなＬＭＳは、関連ＳＬＭＰおよびＥＨＲの組も保持するであろう。

論じられるように、リンクプロファイルは、このリンク対応属性が属するリンク元リソースを生成するエンティティによって生成され、ＬＭＳに提出され、リンク管理タスクを初期化することができる。代替として、リンクプロファイルは、リンクプロファイルが、いくつかの属性に関連付けられ得、それらの属性に対する全てのリンク構成（リンクプロファイルによって規定される）が、グループ動作のようなものとなるであろうという意味で、２つ以上のリンク対応属性を構成するために使用されることもできる。提示を簡略化するために、本明細書の節に詳細を導入するとき、基本的な例に焦点が当てられる。

以下に論じられるのは、スケジュールベースのリンクプロファイルおよび非スケジュールベースのリンクプロファイルである。以下に論じられる２つのタイプのリンクプロファイルは、例である。種々のリンクプロファイルが、異なるアプリケーションシナリオに応じて、作成されることができる（例えば、イベントまたは条件ベースのリンクプロファイル）。表２は、異なるタイプのリンクプロファイルに関する共通アイテムを列挙する。表２にさらに説明されるように、ｔｐｒｏｆｉｌｅＴｙｐｅ（例えば、１＝スケジュールベースのプロファイル、２＝非スケジュールベースのプロファイル）、ｌｉｎｋＯｒｉｇｉｎＵＲＩ（例えば、属性−１ １１５のためのＵＲＩ）、および各リンクプロファイルタイプのためのａｔｔｒｉｂｕｔｅＮａｍｅが、存在し得る。

スケジュールベースのリンクプロファイルに関して、リンク対応属性が、スケジュールベースのリンクプロファイルに関連付けられる場合、この属性を通して構築されるリンクは、特定の時間間隔の間、有効であり得る。スケジュールベースのリンクプロファイルは、スリーピノード（例えば、定期的にスリープタイプモードに入り得るデバイス）が存在するシナリオをサポートするために有用であり得る。表３は、スケジュールベースのリンクプロファイルのためのｄｅｓｔＵＲＩＬｉｓｔおよびｖａｌｉｄＴｉｍｅＩｎｔｅｒｖａｌｓを含む、例示的アイテムを提供する。

非スケジュールベースのリンクプロファイルに関して、リンク対応属性が、非スケジュールベースのリンクプロファイルに関連付けられる場合、この属性を通して構築されるリンクは、システム内のリアルタイムコンテキストおよびそのリンクプロファイル内に定義された関連ルールに基づいて構成され得る。

コンテキスト情報を考慮し得る、非スケジュールベースのリンクプロファイルに関するさらなる観点のために、あるシナリオが、図７Ｂを参照して論じられる。この使用例に関するシナリオのうちの１つは、図７Ｂに示される：ＭＮ−ＣＳＥノード上にホストされる＜ＣＳＥＢａｓｅ１＞の子リソースである、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ１＞）。特に、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性は、両方とも＜ＣＳＥＢａｓｅ１＞に関心があるので、＜ＡＥ２＞（ＡＳＮ−ＣＳＥ１によってホストされる）または＜ＡＥ３＞（ＡＳＮ−ＣＳＥ２によってホストされる）のＵＲＩのいずれかを保持し得る。しかしながら、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩの設定方法は、コンテキスト情報（例えば、ほぼリアルタイム条件）または任意のユーザ定義もしくはアプリケーション特定のルールに基づき得る。例えば、＜ＡＥ１＞は、一次通知受信側（例えば、＜ＡＥ１＞のＵＲＩをｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性に割り当てること）であり得、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩは、＜ＡＥ１＞が到達不可能になると常に、＜ＡＥ２＞のＵＲＩに動的に設定され得る。

従来のサービス層実装は、明示的更新動作を通して以外、前述のリンク対応属性（例えば、図７ＢにおけるｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性）を介して動的に構成するための機構を提供しない。特に、従来の実装では、それらの更新動作の開始側が、管理されるべきリソースおよび対応する属性をホストする、ＣＳＥ（例えば、図７ＢにおけるＭＮ−ＣＳＥ）から離れている場合、そのような頻繁な更新動作は、大幅な通信オーバーヘッドを生じさせ得る。

ｏｎｅＭ２Ｍに関して、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞の従来の実装は、高度な特徴のサポートするための試みにおいて「重い」。例えば、ｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ子リソースおよびｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性が、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を有効にし、通知のためのある程度の知能を有することを有効にするために使用される。ますます多くの新しい属性を新しい特徴（前述のようなｎｏｔｉｆｉｃａｔｉｏｎＵＲＩを動的に構成する等）のために従来の様式において定義すると、リソースは、さらに重くなり得る。開示されるリンク管理サービスは、概して、よりスケーラブルな実装を可能にする。

表４は、非スケジュールベースのリンクプロファイルのためのｄｅｓｔＵＲＩＣａｎｄｉｄａｔｅＬｉｓｔ、ｃｏｎｔｅｘｔＩｎｆｏＵＲＩ、およびｌｉｎｋＳｅｌｅｃｔｉｏｎＲｕｌｅｓを含む、例示的アイテムを提供する。

図１２−図１６等の本明細書に図示されるステップを行うエンティティは、図２８Ｃまたは図２８Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。ある実施例では、Ｍ２Ｍデバイスの相互作用に関するさらなる詳細を以下に伴うが、図１２の発信側１２３（例えば、ＡＥ）は、図２８ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１２のＣＳＥ１０９は、図２８ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図１２−図１７に関して以下に論じられるのは、リンク管理のためのプロシージャである。図１２は、ＬＭＳによる属性のＵＲＩの管理のためのリンク管理タスクを作成するための例示的フローを図示する。ステップ２０３では、発信側１２３は、属性−１ １１５のためのリンク管理タスクを作成するために使用され得る要求をＣＳＥ１０９に送信する。メッセージは、リンクプロファイル１２８と、関連付けられたデータ（例えば、リンクプロファイルタイプに関する関連付けられたデータ）とを含む。ステップ２０３のメッセージは、発信側１２３におけるアプリケーションロジックによってトリガされ得る。別の実施例では、ＬＭＳ１２１は、リンクプロファイルを先を見越して収集し得る。ＬＭＳ１２１は、リンクプロファイルを異なるエンティティから能動的に要求するか、またはパブリッシュもしくはサブスクライブ機構を使用し得る。さらに別の例では、ＬＭＳ１２１は、システムステータスを観察することによって、リンクプロファイル１２８を先を見越して作成し得る。例えば、ＬＭＳ１２１が、発信側１２３（例えば、アプリケーションエンティティ）が時々オフラインになることを観察する場合、ＬＭＳ１２１は、発信側１２３が属する＜ｇｒｏｕｐ＞リソースの「メンバリスト」に対して、発信側１２３が利用不可能になると、リンクプロファイル１２８が発信側１２３のＵＲＩ（例えば、属性−１ １１５）が「メンバリスト」内からなくなるであろうような構成につながるであろうように、リンクプロファイル１２８を設定し得る。結果として、グループ動作は、そのオフライン時間の間、発信側１２３に及ばず、不必要な通信は、故に、削減されることになり得る。

ステップ２０４では、ＣＳＥ１０９は、ステップ２０３の要求を検証する。例えば、ＣＳＥ１０９は、リソース−Ａ １１１および属性−１ １１５が存在するかどうか、発信側１２３がそのような動作のための許可を有するかどうか等を決定し得る。それらのいずれにも当てはまらない場合、要求は、ＬＭＳ１２１にコンタクトすることなくＣＳＥ１０９によって拒否され得る。ステップ２０５では、ＣＳＥ１０９は、リンクプロファイル１２８をＬＭＳ１２１に送信する。ステップ２０６では、ＬＭＳは、リンクプロファイル１２８を検証する。例えば、ＬＭＳ１２１は、属性−１ １１５がすでに別の以前に提出されたリンクプロファイルに関連付けられて管理されているかどうかを決定する。該当する場合、ステップ２０５の要求は、この新しい提出されたプロファイル（リンクプロファイル１２８）が既存のリンクプロファイルに取って代わらない場合、ＬＭＳによって拒否され得る。そうでなければ、ＬＭＳ１２１は、以下を行い得る：１）あるルール／条件が満たされると、ＬＭＳ１２１が対応するリンク構成動作を実行し得るように、リンクプロファイル１２８に従って、新しいトリガを定義すること、２）属性−１ １１５に関連する任意の他のリンクプロファイルが将来提出された場合、ＬＭＳが、古いリンクプロファイル１２８の置換もしくは更新すること、または新しいものを拒否すること等の動作を実施できるように、属性−１ １１５を「管理済み」（または別の用語またはマーキング）としてマークすること、３）リンク管理ＩＤ（値は、任意の命名スキームに基づき得る）をこのリンク管理タスクのためのグローバル参照（例えば、エンティティは、リンク管理ＩＤを規定することによって、既存のリンク管理タスクを削除するための要求を送信し得る）として生成すること。以下の説明は、リンク管理ＩＤを使用すべき時間または場所に関するさらなる議論を提供する。

ステップ２０７では、ＬＭＳ１２１は、リンク管理タスクがリンク管理ＩＤとともに正常に確立されたことを示す確認をＣＳＥ１０９に送信する。ステップ２０８では、ＬＭＳ１２１が属性を操作するためのアクセスを有し、必要に応じて他のエンティティに対するアクセスを制限するように、ＣＳＥ１０９は、属性−１ １１５に特定の別個のアクセスポリシを作成し得るか、または、ＣＳＥ１０９は、既存のアクセス制御ポリシを修正し得る。それらの特定のアクセス制御ポリシも、リンク管理ＩＤに関連付けられ得、リンク管理ＩＤは、証明書検証のために使用されることができ、その要求内にリンク管理ＩＤを規定し得る者のみ、属性−１ １１５における構成を行うことが可能にされるであろう。ステップ２０９では、ＣＳＥ１０９はさらに、リンク管理ＩＤとともに確認を発信側１２３に返信し、それによって、発信側１２３は、属性−１ １１５のステータスを認識し得る。

図１３は、スケジュールベースのリンクプロファイルを使用してリンク管理を実施するための例示的方法を図示する。ステップ２１１では、ＬＭＳ１２１は、スケジュールベースのリンクプロファイル（例えば、リンクプロファイル１２８）に基づいてトリガされる。例えば、ＬＭＳ１２１は、タイマによってトリガされ、属性−１ １１５の値を更新し得る。ステップ２１２では、ＬＭＳ１２１は、属性−１ １１５のリンクプロファイル１２８に従って属性−１ １１５のＵＲＩを更新するための要求をＣＳＥ１０９に送信する。リンク管理タスク確立中に生成されるリンク管理ＩＤが、ＣＳＥ１０９が属性−１ １１５に対する動作許可をチェックできるように、要求内に含まれ得る。ステップ２１３では、ＣＳＥ１０９は、ステップ２１２において提案された動作が許可されるかどうかを決定する。該当する場合、属性−１ １１５の値は、ステップ２１２の要求内の値で更新され得る。ステップ２１４では、ＣＳＥ１０９は、要求される動作の成功または失敗に関して、メッセージをＬＭＳ１２１に返信する。

図１４は、非スケジュールベースのリンクプロファイルを使用してリンク管理を実施するための例示的方法を図示する。ステップ２２１では、ＬＭＳ１２１は、どのコンテキスト情報が非スケジュールベースのリンクプロファイル（例えば、リンクプロファイル１２８）に基づいて収集される必要があるかどうかを決定する。ステップ２２３では、ＬＭＳ１２１は、コンテキスト情報に対するクエリを送信する（リアルタイムであり得る）。コンテキスト情報は、とりわけ、デバイスへの帯域幅配分、通信セッションの待ち時間（例えば、アプリケーションの遅延公差に関連付けられる）、デバイスの場所もしくはランニングステータス、デバイスの電力制御要件の分類、またはビジネスロジックに影響を及ぼし得る関連情報を含み得る。ＬＭＳ１２１は、代替として、要求されるリアルタイム情報のプロバイダとサブスクリプション関係を確立し得る。本明細書では、コンテキスト情報を収集する、いくつかのエンティティが存在すると仮定される。ステップ２２５では、コンテキストプロバイダ１０５は、ステップ２２３の要求に基づいて、関連コンテキスト情報を返す。ステップ２２６では、ＬＭＳ１２１は、コンテキスト情報と非スケジュールリンクプロファイル内に規定された関連ルールとを比較し、それは、ＬＭＳ１２１が属性−１ １１５を再構成するようにトリガする。ステップ２２７では、ＬＭＳ１２１は、属性−１ １１５の値を更新するための要求をＣＳＥ１０９に送信する。ステップ２２８では、ＣＳＥ１０９は、ステップ２２７の受信された要求をチェックし、要求に応じて、属性−１ １１５における更新動作を実行する。ステップ２２９では、ＣＳＥ１０９は、メッセージを送信し、ステップ２２８に関連付けられた動作のステータスを中継し得る。

図１５は、ＬＭＳによる属性のＵＲＩの管理のためのリンク管理タスクを削除するための例示的フローを図示する。ステップ２３１では、発信側１２３は、属性−１ １１５のためのリンク管理タスクを削除するための要求をＣＳＥ１０９に送信する。ステップ２３３では、ＣＳＥ１０９は、ステップ２３１の要求を検証する。例えば、ＣＳＥ１０９は、発信側１２３がそのような動作のための許可を有するかどうかを決定し得る。ステップ２３５では、ＣＳＥ１０９は、リンク管理タスクを削除するための要求をＬＭＳ１２１に送信する。ステップ２３６では、ＬＭＳ１２１は、リンクプロファイル１２８および関連トリガを削除する。ステップ２３７では、ＬＭＳ１２１は、リンク管理ＩＤを含み得る、リンク管理タスクが正常に削除されたことを示す確認をＣＳＥ１０９に送信する。ステップ２３８では、ＣＳＥ１０９は、属性−１ １１５に特定の別個のアクセスポリシを削除し得る。属性−１ １１５は、リソース−Ａ １１１が削除されない限り、依然として、存在することができる。ステップ２３９では、ＣＳＥ１０９は、属性−１ １１５のステータスを認識するために、リンク管理ＩＤとともに確認を発信側１２３に返信し得る。

図１６は、リンク元リソースを削除するための例示的フローを図示する。ステップ２４１では、発信側１２３は、リンク元リソース（例えば、リソース−Ａ １１１）を削除するための要求をＣＳＥ１０９に送信する。ステップ２４２では、ＣＳＥ１０９は、ステップ２４１の要求を検証する。例えば、ＣＳＥ１０９は、発信側１２３がそのような動作のための許可を有するかどうかを決定し得る。例えば、ＣＳＥ１０９はまた、削除されるべきリソース−Ａ １１１のどの属性が現在ＬＭＳ１２１によって管理されているかをチェックし得、それは、それらの属性（例えば、属性−１ １１５）に対するリンク管理動作に特別な全アクセス制御ポリシ（およびその関連付けられたリンク管理ＩＤ）を調べることによって行われることができる。それらのリンク管理ＩＤは、次いで、ＬＭＳ１２１に送信され得る。

ステップ２４３では、ＣＳＥ１０９は、リソース−Ａ １１１を削除するための要求をＬＭＳ１２１に送信する。ステップ２４４では、ＬＭＳ１２１は、受信されたリンク管理ＩＤに対応する関連トリガおよび関連リンクプロファイル（例えば、リンクプロファイル１２８）を削除する。リソース削除動作は、他のリソースおよびリンクにも影響を及ぼし得るので、いくつかのサービス層全体にわたるリンク管理動作も、トリガされ得る。ステップ２４５では、ＬＭＳ１２１は、リソース−Ａ １１１に関連するリンク管理タスクが正常に削除されたことを示す確認をＣＳＥ１０９に送信する。ステップ２４６では、ＣＳＥ１０９は、リソースＡ１１１の属性のリンク管理動作に関連するリソース−Ａ １１１を削除する。ステップ２４７では、ＣＳＥ１０９は、リソース−Ａ １１１の削除に関するステータスメッセージを返信し得る。

所与のリンクプロファイルＰに関連する既存のリンク管理タスクに対して、更新プロシージャは、図１２に関して提供される作成プロシージャに類似することに留意されたい。加えて、読み出し動作は、その対応するリンク管理ＩＤを規定することによって、リンクプロファイル１２８をＬＭＳ１２１から読み出すことができる。ＳＬＭＰ１３３またはＥＨＲ１３１をＬＭＳ１２１に／から提出、更新、および削除する方法に関連するプロシージャは、リンクプロファイル１２８に関して開示されるものに類似する。

ＬＭＳによって使用されるＳＬＭＰ、ＥＨＲおよびリンクプロファイル間の相互作用に関して、以下でさらに議論される。図１７は、ＳＬＭＰを提出する、更新する、または削除するための要求をＬＭＳ１２１が受信するときのＬＭＳ１２１との関連相互作用を図示する、例示的フロー図を図示し、これはまた、いくつかの簡単な修正後、ＥＨＲにも適用可能である。

ステップ２５０では、ＬＭＳ１２１は、新しい／更新されたＳＬＭＰ１３３を受信するか、またはＬＭＳ１２１に記憶される既存のＳＬＭＰ１３３の削除要求を受信する。ステップ２５１では、ＬＭＳ１２１は、要求のタイプを調べ（例えば、要求が、「作成」または「更新」であるかどうか確認する）、それは、新しいＳＬＭＰ１３３を提出／作成すること（該当する場合、ステップ２５５に進む）、既存のＳＬＭＰ１３３を更新すること（該当する場合、ステップ２５４に進む）、またはすでにＬＭＳ１２１に記憶されているＳＬＭＰ１３３を削除すること（該当する場合、ステップ２５２に進む）であり得る。

ステップ２５２では、ＬＭＳ１２１は、ＳＬＭＰ１３３に関連する登録されたリンクプロファイル（例えば、リンクプロファイル１２８およびリンクプロファイル１３６）を調べる。そのために、ＳＬＭＰ１３３のアプリケーションスコープが、利用され得、アプリケーションスコープは、どの属性にＳＬＭＰ１３３が適用されることができるかを示す。例えば、削除されるべきＳＬＭＰ１３３が、それぞれ、リソース−Ａ １１１およびリソース−Ｚ １３４の属性−１ １１５および属性−１ １３５に適用可能な場合、異なるリソースの属性−１のリンクプロファイルが、調べられ、ソートされるであろう。ステップ２５３では、ＬＭＳ１２１は、ＳＬＭＰ１３３を削除するだけでなく、ステップ２５２においてソートされたリンクプロファイル（例えば、リンクプロファイル１２８およびリンクプロファイル１３６）に基づいて、関わるリンク対応属性（属性−１ １１５および属性−１ １３５）を再構成する。特に、ＳＬＭＰ１３３が現時点で存在しないので、それらの属性の値は、そのリンクプロファイルに基づいて、リセットされるであろう。次いで、ステップ２５１に進む。

ステップ２５４では、ＬＭＳ１２１は、既存のＳＬＭＰ１３３を新しく受信されたＳＬＭＰと置換する。代替として、既存のＳＬＭＰ１３３は同様に、部分的にのみ更新され得る。ステップ２５５では、ＬＭＳ１２１は、この新しく受信されたＳＬＭＰに関連する、全リンクプロファイルをソートし、詳細なプロセスは、ステップ２５２に説明されるものに類似する。

ステップ２５６では、ＬＭＳ１２１は、現在のリンク構成がこのＳＬＭＰ１３３に準拠するかどうかを評価する。例えば、ＬＭＳ１２１は、それらのリンクプロファイルの関連付けられた属性に割り当てられるべき値がこのＳＬＭＰ１３３によって規定されたポリシを満たすかどうかを評価し得る。「はい」である場合、ステップ２６０に進む。そうでなければ、いくつかのリソースの関連属性の値が、このＳＬＭＰ１３３によって規定されたポリシと整合しないか、または衝突することを示す。故に、例外ハンドリングプロセスが、トリガされる（例えば、ステップ２５７に進む）。ステップ２５７では、ＬＭＳ１２１は、ＥＨＲ１３１が存在するかどうかをチェックする（典型的には、あるＳＬＭＰ１３３がＥＨＲ１３１に関連付けられ得る）。「はい」である場合、ステップ２５８に進む。そうでなければ、ステップ２５９に進む。

ステップ２５８では、ＬＭＳ１２１は、デフォルト例外ハンドリングルールを使用して、関連属性の値を再構成するだけではなく、この受信されたＳＬＭＰ１３３に準拠しない、リンクプロファイルによって規定されたある構成をサポートするために使用されるいくつかのトリガを一時的に無効にし得る。ステップ２５９では、ＬＭＳ１２１は、直接、対応するＥＨＲ１３１を参照することができ、関連動作は、ステップ２５８に類似する。

ステップ２６０では、ＬＭＳ１２１は、将来、新しいリンクプロファイルが、ＳＬＭＰ１３３に関連する属性のために定義されるとき、最新ＳＬＭＰ１３３に従い、任意のさらなる衝突を回避し得るように、システム内の他のエンティティに、必要に応じて、最新ＳＬＭＰ１３３を知らせる。前述のステップは、主に、ＳＬＭＰ１３３における関連動作（作成、更新、または削除）によって影響され得る、既存のリソースにおけるリンク対応属性のための必要再構成を実行することに焦点が当てられている。

図１８は、リンクプロファイル、ＳＬＭＰ、およびＥＨＲ間の相互作用の例示的例証である。この例では、リソース−Ａ １１１およびリソース−Ｚ １３４等の２つの＜ｇｒｏｕｐ＞リソースがシステム内に存在する。属性−１ １１５および属性−１ １３５（例えば、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＬｉｓｔ属性）は、それぞれ、リンクプロファイル１２８およびリンクプロファイル１３６に基づいて、ＬＭＳ１２１によって構成される。アプリケーション特定の要件（例えば）に基づいて、リンクプロファイル１２８内の構成仕様のうちの１つは、図８の発信側１２３のＵＲＩ（例えば、ＡＥリソース−＜ＡＥ＞）が８ＡＭ−８：３０ＡＭの間に属性−１ １１５内に含まれるというものである。加えて、発信側１２３を指すＵＲＩは、８：２０ＡＭ−９：３０ＡＭの間に属性−１ １３５内に含まれる。故に、発信側１２３を指すＵＲＩは、８：２０ＡＭ−８：３０ＡＭの間、２つのリソース（＜ｇｒｏｕｐ＞リソース）内でアクティブであろう。おそらく後に、ＬＭＳ１２１は、ポリシが、発信側１２３を指すＵＲＩが２つ以上のグループの属性内に含まれることができないというものであるＳＬＭＰ１３３も受信し得る。この例に対して、そのようなポリシは、リンクプロファイル１２８およびリンクプロファイル１３６内に含まれる前述の構成仕様に影響を及ぼし、衝突するであろう。その結果、ＥＨＲ１３１が、衝突を解決するために、８：２０ＡＭ−８：３０ＡＭの間、ＬＭＳ１２１が、発信側１２３を指すＵＲＩをリソース−Ａ １３４の属性−１ １１５にのみ割り当てるであろうように、ここで利用されるであろう。ここでは、属性−１ １１５は、属性−１ １３５より高い優先順位を有すると仮定される。優先順位は、ＵＲＩ使用の頻度または時間の長さに関して、手動で割り当てられる優先順位または自動的に割り当てられる優先順位等の要因に基づき得る。例えば、時間の長さに関して、属性−１ １１５は、３０分（８：００ＡＭ−８：３０ＡＭ）が配分される一方、属性−１ １３５は、合計５０分（８：２０ＡＭ−９：３０ＡＭ）が配分されるので、優先され得る。属性−１ １３５は、優先順位決定の結果に基づいてそのように行われるように制限された後でも、ＵＲＩを使用するためのより長い時間フレームを有する。

以下に論じられるのは、ｏｎｅＭ２Ｍ内にさらに統合され得る方法に関連してリンク管理を論じる例である。ｏｎｅＭ２Ｍは、能力サービス機能（ＣＳＦ）と称される能力を定義する。ｏｎｅＭ２Ｍサービス層は、能力サービスエンティティ（ＣＳＥ）と称される。故に、開示されるＬＭＳ１２１は、図１９に示されるように、ＣＳＥによって実装されるＣＳＦと見なされ得る。

好ましいシナリオでは、各ＣＳＥは、リソースリンク管理動作がそのＬＭＳによって取り扱われ得るように、その独自のＬＭＳを同一デバイス上に実装することが提案される。しかしながら、ＣＳＥ（例えば、ＣＳＥ１０９）が、非常に限定された能力を伴うリソース制約ノード上に展開される場合、別のＣＳＥによって実装されるＬＭＳ（例えば、ＬＭＳ１２１）に依拠することもできる。そのような場合でも、依然として、リンクが遠隔発信側（例えば、発信側１２３）によって構成される必要がある場合と比較して、低通信オーバーヘッドにつながることに留意されたい。開示されるＬＭＳは、以下の方法において、ｏｎｅＭ２Ｍサービス層における参照点に影響を及ぼし得る。
・ ＡＥが、ＣＳＥ（例えば、リンクホストＣＳＥ）によってホストされるリソースの属性に対してリンク管理タスクを開始するための要求（リンクプロファイルとともに）をＣＳＥに送信する場合、ｍｃａインターフェースを通過し得る。
・ ＣＳＥ−１が、ＣＳＥ−２（例えば、リンクホストＣＳＥ）によってホストされるリソースの属性に対してリンク管理タスクを開始するための要求（リンクプロファイルとともに）を別のＣＳＥ−２に送信する場合、ｍｃｃインターフェースを通過し得る。
・ リンクホストＣＳＥが、ＬＭＳにさらにコンタクトする必要がある場合、
− このＣＳＥが、それ自体によって実装されるＬＭＳを利用する場合、１つのＭ２Ｍデバイスまたは関連Ｍ２Ｍデバイスのグループにおいて内部処理を伴い得る。

− ＣＳＥが、別のＣＳＥによって実装されるＬＭＳを利用する場合、ｍｃｃインターフェースを通過し得る。

図２０−図２２は、開示されるＬＭＳのための例示的ＲＥＳＴｆｕｌリソースベースのインターフェースを図示する。以下の凡例は、図２０−図２２のために使用される。
・ 長方形ボックスは、リソースおよび子リソースのために使用される
・ 丸い角を伴う長方形ボックスは、属性のために使用される
・ 各属性および子リソースの多重度が、定義される
・ 「＜」および「＞」で区切られたリソース名は、リソースの作成中に割り当てられた名称を示す
本明細書に開示されるのは、＜ｌｉｎｋＰｒｏｆｉｌｅ＞２６３の観点におけるリソースであり、＜ＳＬＭＰ＞２６４および＜ＥＨＲ＞２６７は、図２０−図２２に示されるように定義され、それらのリソースの各々は、いくつかの属性を有する。例えば、＜ｌｉｎｋＰｒｏｆｉｌｅ＞２６３における属性は、表２−表４に定義されるように、ｐｒｏｆｉｌｅＴｙｐｅ、ｌｉｎｋＯｒｉｇｉｎＵＲＩ、ａｔｔｒｉｂｕｔｅＮａｍｅ、ｄｅｓｔＵＲＩ、ｖａｌｉｄＴｉｍｅＩｎｔｅｒｖａｌｓ、ｄｅｓｔＵＲＩＣａｎｄｉｄａｔｅＬｉｓｔ、ｃｏｎｔｅｘｔＩｎｆｏＵＲＩ、ｌｉｎｋＳｅｌｅｃｔｉｏｎＲｕｌｅｓ等のリンクファイル内に定義された異なるデータアイテムに対応する。同様に、＜ＳＬＭＰ＞２６４および＜ＥＨＲ＞２６７における属性は、それぞれ、＜ＳＬＭＰ＞２６４のための関連付けられたＥＨＲおよび＜ＥＨＲ＞２６７のための関連付けられたＳＬＭＰ、＜ＳＬＭＰ＞２６４のためのａｆｆｅｃｔｅｄＡｔｔｒｉｂｕｔｅＬｉｓｔ（ＳＬＭＰ２６４が影響を及ぼすであろう属性）およびｐｏｌｉｃｙＬｉｓｔ、＜ＥＨＲ＞２６７のためのｒｕｌｅＬｉｓｔに関連する情報を含む。

図２３は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（例えば、ｏｎｅＭ２Ｍ−ＴＳ−０００７ ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−０．３．０）におけるＬＭＳ１２１の実装アーキテクチャの例示的例証である。図２３に示されるように、ＬＭＳ１２１は、「Ｍｓｃ」参照点２７３を経由して他のコンポーネントと相互作用し得る、「リンク管理サービスコンポーネント」２７１と呼ばれる個々のサービスコンポーネントを差し込むことによって実装され得る。

以下に論じられるのは、「ｐａｒｅｎｔＩＤ」属性等のｏｎｅＭ２Ｍ属性、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース、および＜ｇｒｏｕｐ＞リソースを考慮したリンク管理詳細である。

ＬＭＳ１２１の使用によって、リソース−Ａ １１１は、必要に応じて、動的に異なるリソースの子リソースであり得る。そのために、リソース−Ａ １１１のｐａｒｅｎｔＩＤが、本明細書に開示されるように、２つのタイプのリンクプロファイルによって構成されることができる。ＣＳＥ１０９における複数のリソースのｐａｒｅｎｔＩＤも、任意のアプリケーション要件をサポートするために、ＬＭＳ１２１によって同様に管理されることができる。例えば、ＳＬＭＰ１３３は、「ｐａｒｅｎｔＩＤ」属性のために定義されることができ、それに基づいて、リソース階層が、所望に応じた様式で（許可される場合）、動的に再編成または再構成されることができる。任意のアプリケーション特定のポリシが、ＳＬＭＰ１３３として定義され、任意の既存または将来的ｏｎｅＭ２Ｍ仕様（または任意の他の規格）によって可能にされる新しい特徴を有効にすることができることに留意されたい。例えば、以下の例示的ポリシも、「ｐａｒｅｎｔＩＤ」属性のためにＳＬＭＰ１３３内に含まれることができる。
１． リソースの２つの組は、例えば、セキュリティ問題に起因して、（一方の組におけるリソースのｐａｒｅｎｔＩＤを構成する方法が他方の組におけるリソースのそれらの構成に影響を及ぼすであろうように）同じ親を共有することができないというポリシ。
２． ｐａｒｅｎｔＩＤ属性は、リソースが２つ以上の親を有し得るように、同時に複数のＵＲＩを割り当てられることができるというポリシ。特に、図２４は、そのようなポリシが＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｐａｒｅｎｔＩＤ」属性に適用されるときの付加価値サービスを示す。

図２４−図２６等の本明細書に図示されるステップを行うエンティティは、論理エンティティであることを理解されたい。ステップは、図２８Ｃまたは図２８Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行され得る。ある実施例では、Ｍ２Ｍデバイスの相互作用に関するさらなる詳細を以下に伴うが、図２６の発信側１２３は、図２８ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図２６のＣＳＥ１０９は、図２８ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図２４は、ＬＭＳを使用したｐａｒｅｎｔＩＤ属性に関する方法の例示的例証である。図２４に示されるように、開始時、既存のｏｎｅＭ２Ｍ仕様によって定義されるように、１つのリソースが、１つの親を有することができる。ステップ２８１では、ＩＮ−ＣＳＥ１０７は、新しいＳＬＭＰ１３３をＬＭＳ１２１に提出し得る。この要求は、１つのリソースが２つ以上の親を有することを可能にするために、アプリケーションによってトリガされ得る。ステップ２８２では、ＬＭＳ１２１は、対応するＳＬＭＰを更新し、したがって、リソースの「ｐａｒｅｎｔＩＤ」は、２つ以上のＵＲＩを保持することが可能にされる。ステップ２８４では、ＬＭＳ１２１は、このＳＬＭＰ１３３に対して、システム内のエンティティ（例えば、発信側１２３およびＣＳＥ１０９）に知らせる。ステップ２８５では、発信側１２３（例えば、ＡＥ−１）は、それ（発信側１２３）がＣＳＥ１０９のリソース＜ＡＥ−２＞およびＣＳＥ１０９の＜ＡＥ−３＞に関心があるので、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成するための要求をＣＳＥ１０９に送信し得る。しかしながら、＜ＡＥ−２＞および＜ＡＥ−３＞のための２つの別個の＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成する代わりに、新しいポリシを用いて、ＡＥ−１は、１つの＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を作成し、そのｐａｒｅｎｔＩＤを＜ＡＥ−２＞および＜ＡＥ−３＞の両方のＵＲＩで設定することのみ必要とする。ステップ２８６では、ＣＳＥ１０９は、ステップ２８５の要求を検証する。ステップ２８７では、ＣＳＥ１０９は、ステップ２８６において要求されたサブスクリプションのステータスに関して、通知を発信側１２３に送信し得る。ステップ２８８およびステップ２８９では、ＣＳＥ１０９は、それぞれ、＜ＡＥ−２＞および＜ＡＥ−３＞に対する任意の変更に関して、通知を送信し得る。故に、発信側１２３は、＜ＡＥ−２＞リソースだけではなく、＜ＡＥ−３＞リソースにおける変更に関する通知を受信することもできる。

図２５は、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｐａｒｅｎｔＩＤのためにリンクプロファイルによって有効にされる付加価値サービスのための方法の例示的例証である。この例では、１つのリソースは、動的に異なるリソースの子リソースであることができる。図２５では、１つのリソースは、１つのみの親を有することができると仮定される。しかしながら、発信側１２３（例えば、＜ＡＥ−１＞）は、そのｐａｒｅｎｔＩＤ属性のためのリンクプロファイル１２８とともに、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成するための要求をＣＳＥ１０９に送信し得る。前述の例（図２４）におけるように、発信側１２３は、リソース＜ＡＥ−２＞および＜ＡＥ−３＞の両方に関心があるが、代替方法においてである。ＣＳＥ１０９において、発信側１２３から受信された要求に基づいて、対応するリンクプロファイルＰ内に定義された仕様に基づいて、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成し、そのｐａｒｅｎｔＩＤが＜ＡＥ−２＞のＵＲであるように設定する。故に、発信側１２３は、＜ＡＥ−２＞における変更に関する通知を受信することができる。別の時に、いくつかの条件が満たされると、ＬＭＳは、トリガされ、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｐａｒｅｎｔＩＤが＜ＡＥ−３＞のＵＲＩであるように自動的に更新し、発信側１２３は、＜ＡＥ−３＞に対する変更に関する通知を受信するであろう。

ＬＭＳは、システム全体にわたるリンク管理のためのエンティティであることができるので、動作効率の観点からも利益を有する。例えば、ＬＭＳはまた、質問（リソースが属するグループの数等）に回答し得るが、それは、すぐに明白にならないか、またはリソースの属性にアクセスすることによって直接回答されることができない。開示される属性およびそれらの属性に対するリンク構築動作は、厳密に対称ではない。例えば、ｍｅｍｂｅｒＬｉｓｔＩＤは、＜ｇｒｏｕｐ＞リソースのために定義されているが、リソースは、それが属するグループを保持することができるｇｒｏｕｐＬｉｓｔ属性を有していない。確かに、そのような新しい属性は、既存のｏｎｅＭ２Ｍ仕様を拡張させることによって定義されることはできる。代替として、別の方法は、リンクがＬＭＳによって管理される場合、ＬＭＳに助けを求めることであり、そこから、回答も、例えば、リンクプロファイルを調べることによって、容易に得られることができる。

図２５を継続して参照すると、ステップ１４０では、発信側１２３は、＜ＡＥ−２＞および＜ＡＥ−３＞リソースに関心があるので、ＣＳＥ１０９において＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成することを決定する。ステップ１４１では、発信側１２３（＜ＡＥ１＞）は、その「ｐａｒｅｎｔＩＤ」属性のためのリンクプロファイルとともに、ＣＳＥ１０９において＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成するための要求を送信する。ステップ１４２では、ＣＳＥ１０９は、発信側１２３からの要求の動作の正しさをチェックし、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースにおいて、ｐａｒｅｎｔＩＤは、＜ＡＥ−２＞のＵＲＩの値を有するようにデフォルト化される。ステップ１４３では、ＣＳＥ１０９は、リンクプロファイルをＬＭＳ１２１に登録するためのメッセージを送信する。ステップ１４４では、ＬＭＳ１２１は、内部処理を実施する（例えば、受信されたリンクプロファイルに従って、新しいトリガを定義する）。ステップ１４５では、ＬＭＳ１２１は、メッセージを送信し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースに関連するリンク管理タスクのための登録成功に関してＣＳＥ１０９と確認する。ステップ１４６では、ＣＳＥ１０９は、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの作成成功に関して発信側１２３と確認する。１４７では、ＣＳＥ１０９の＜ＡＥ−２＞が、変更された。ステップ１４８では、ＣＳＥ１０９は、＜ＡＥ−２＞の変更に関して発信側１２３に通知する。ステップ１４９では、リンクプロファイル内に規定された＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｐａｒｅｎｔＩＤ」属性の値を更新することに対するアクションをトリガする条件が、ＬＭＳ１２１によってチェックされる。ステップ１５０では、ＬＭＳ１２１は、ｐａｒｅｎｔＩＤの値を＜ＡＥ−３＞のＵＲＩに更新するための要求をＣＳＥ１０９に送信する。ステップ１５１では、ＣＳＥ１０９は、ステップ１５０の要求をチェックし、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞のｐａｒｅｎｔＩＤが＜ＡＥ−３＞のＵＲＩの値を有するように、更新動作を実行する。ステップ１５２では、＜ＡＥ−３＞が、変更された。ステップ１５３では、ＣＳＥ１０９は、ｐａｒｅｎｔＩＤの現在の値が、以前のリンク管理動作に起因して、＜ＡＥ−３＞のＵＲＩに設定されているので、＜ＡＥ−３＞の変更に関してＡＥ−１に通知する。

図２６は、最初に、＜ＡＥ−１＞リソースが、ＣＳＥ１０９において作成されており、いくつかのグループに追加されたことを示す。後に、アプリケーション要件に起因して、例えば、発信側１２３が、どのグループのメンバであることも所望しないが、しかしながら、それは、それが現在属するグループを把握していない。故に、それは、本件に関して要求をＬＭＳに送信し得る。システム内の全リンクがＬＭＳによって構成されると仮定すると、ＬＭＳは、全＜ｇｒｏｕｐ＞リソースの「ｍｅｍｂｅｒＬｉｓｔ」属性に関連する全リンクプロファイルに迅速に目を通し、次いで、＜ＡＥ−１＞のＵＲＩをそれらのグループから排除し得る。例えば、「ｍｅｍｂｅｒＬｉｓｔ」属性の値内にそのようなＵＲＩを含むことに関連する任意のリンク構成は、関連リンクプロファイルから削除されるであろう。そうすることによって、＜ＡＥ−１＞は、もはやどのグループにも属さないであろう。これは、開示されるＬＭＳによって有効にされる付加価値サービスであり得る。特に、ＡＥは、ＬＭＳが、このＡＥが現在属するグループを回答し得るように、クエリ要求をＬＭＳに送信することができる。

図２６を継続して参照すると、ステップ１６１では、発信側１２３は、ＣＳＥ１０９において＜ＡＥ−１＞リソースを作成することを決定する。ステップ１６２では、発信側１２３（ＡＥ−１）は、ＣＳＥ１０９において＜ＡＥ−１＞リソースを作成するための要求を送信する。ステップ１６３では、ＣＳＥ１０９は、発信側１２３からの要求の動作をチェックし、＜ＡＥ−１＞リソースを作成する。ステップ１６４では、＜ＡＥ−１＞が、必要とされるビジネスロジックに基づいて（ＡＥ−１に知らせずに）、他のエンティティによって多くの＜ｇｒｏｕｐ＞リソースの「ｍｅｍｂｅｒＬｉｓｔ」に追加される。ステップ１６５では、発信側１２３は、どのグループのメンバであることも所望しない（例えば、アプリケーション要件に基づいて）が、それ（発信側１２３）は、それが現在属するグループを把握していないと決定する。ステップ１６６では、発信側１２３は、発信側１２３に関連付けられた＜ＡＥ−１＞をグループから除去することにおける支援に対する要求をＬＭＳ１２１に送信する。ステップ１６７では、ＬＭＳ１２１は、＜ＡＥ−１＞のＵＲＩが含まれる「ｍｅｍｂｅｒＬｉｓｔ」属性に関連するリンクプロファイルに目を通して、＜ＡＥ−１＞のＵＲＩをそれらの関連「ｍｅｍｂｅｒＬｉｓｔ」属性の全てから削除する。ステップ１６８では、ＬＭＳ１２１は、発信側１２３（ＡＥ−１）にそれがどのグループにも存在しないことを示すメッセージを発信側１２３に送信し得る。本明細書では、用語「発信側」および「ＡＥ」は、同じ意味で使用され得ることに留意されたい。発信側は、アプリケーションがロードされたデバイスであり得る（例えば、ＡＥ−１）、またはＡＥ−１であり得る。

図２７は、本明細書で論じられる方法およびシステムに基づいて生成され得る、例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９０１（例えば、タッチスクリーンディスプレイ）は、リソースリンク管理（例えば、ＬＭＳ）に関連付けられたブロック９０２において、表１から表４に示されるようなパラメータを表示またはクエリするために使用され得るテキストを提供し得る。別の実施例では、図１２−図１６または図２４−図２６に示されるような明細書で論じられるステップのいずれかの進捗度（例えば、送信されるメッセージまたはステップの成功）が、表示され得る。加えて、グラフィカル出力９０３が、ディスプレイインターフェース９０１上に表示され得る。グラフィカル出力９０３は、リソースリンク管理（例えば、ＬＭＳ）、本明細書で論じられる任意の方法またはシステムの進捗度のグラフィカル出力等に関する、デバイスのトポロジであり得る。

図２７を継続して参照すると、ブロック９０２のグラフィカルユーザインターフェース（ＧＵＩ）は、ＬＭＳにおいて起動中のタスクのリアルタイムステータスのチェックを可能にする。典型的には、ＬＭＳにおいて起動中のタスクの多くは、種々のリンクプロファイル、ＳＬＭＰ、またはＥＨＲにおいて定義された仕様に基づくので、ブロック９０２のＧＵＩは、それらのファイルがリンク管理タスク内でどのように使用されているかを監視することを可能にするであろう。リンクプロファイルを例として挙げると、チェックすべき一連のリンクプロファイル（例えば、全リンク管理タスク内で最も頻繁に使用されたもの、またはリンク管理タスク内で最も頻繁に使用されていないものであり得る）が、存在し得る。代替として、特定のリンクプロファイルをチェックすることが所望される場合、特定のリンクプロファイルＩＤが、入力され得る。リンクプロファイルのためのそのようなＧＵＩ使用は、ＬＭＳに記憶する他のタイプのエンティティ、例えば、ＳＬＭＰおよびＥＨＲにも適用可能である。

本明細書に表出する請求項の範囲、解釈、または用途をいかようにも限定するわけではないが、本明細書に開示される実施例のうちの１つ以上のものの技術的効果は、リンクが管理される方法に対して調節を提供することである。リンク構成（および関連知能）は、特別なエンティティによって取り扱われるか、または記憶され得る。本明細書に開示される概念のうちの１つ以上のものの別の技術的効果は、従来の実装と比較して、ＣＳＥがｐａｒｅｎｔＩＤ属性におけるリンク管理をサポートする場合、リソース階層がより柔軟な方法で編成され得るように、このＣＳＥにおけるリソースが、次いで、リソースツリーを横断して移動させられることができる（例えば、異なるＵＲＩ値をｐａｒｅｎｔＩＤ属性に割り当てる）ことである。単なる例として、＜ｃｏｎｔａｉｎｅｒ＞リソースの「ｐａｒｅｎｔＩＤ」は、それらのＡＥが、必要に応じて、データを容易に共有および交換し得るように、異なるＡＥの１つ以上のＵＲＩを動的に割り当てられ得る。本明細書に開示されるＬＭＳの別の技術的効果は、リソース（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）が、定義された要件に基づいて、動的かつ選択的に、通知を２つ以上の受信側に送信し、したがって、新しい付加価値サービスを有効にすることができることである。

ｏｎｅＭ２Ｍアーキテクチャが、本明細書で背景として説明され、後述される種々の概念を例証するために使用され得るが、本明細書に後述される概念の実装は、本開示の範囲内にとどまりながら、変動し得ることを理解されたい。当業者はまた、開示される概念が、前述のｏｎｅＭ２Ｍアーキテクチャを使用する実装に限定されず、むしろ、ＥＴＳＩ Ｍ２Ｍならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステム内に実装され得ることを認識するであろう。

図２８Ａは、図８等の１つ以上の開示された実施例が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

図２８Ｂを参照すると、フィールドドメイン内に例証されるＭ２Ｍサービス層２２（例えば、サービス層１０４）は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

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

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

いくつかの実施例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に論じられるように、リソースリンク管理（例えば、ＬＭＳ）に関連付けられたメッセージを使用して通信する所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

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

図２８Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図２８Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、Ｍ２Ｍゲートウェイ１２２、Ｍ２Ｍデバイス１２５、Ｍ２Ｍデバイス１２６、Ｍ２Ｍデバイス１２７、Ｍ２Ｍサーバ１２４、およびその他）は、リソースリンク管理（例えば、ＬＭＳ）のための開示されるシステムおよび方法を実施する、例示的実装の一部であり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される実施例のうちのいくつかにおけるＬＭＳが成功もしくは不成功（例えば、例外ハンドリング（ＥＨＲ）、ＳＬＭＰ、もしくはリンクプロファイル提出等）であるかに応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御する、または別様に、リソースリンク管理（ＬＭＳ）および関連付けられたコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色の制御は、図に図示される、または本明細書で論じられる（例えば、図１２−１６および図２４−図２６等）、方法フローまたはコンポーネントのいずれかのステータスを反映し得る。

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

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍデバイス３０は、本明細書に開示されるものと一致したままで、任意の好適な場所決定方法を介して場所情報を取得し得ることが理解されるであろう。

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

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

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

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

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

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

さらに、コンピュータシステム９０は、図２８Ａおよび２８Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

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

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

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

Claims (20)

1. リソースリンクを管理するデバイスであって、前記デバイスは、
   プロセッサと、
   前記プロセッサに結合されたメモリと
   を備え、
   前記メモリは、実行可能な命令を備え、前記命令は、前記プロセッサによって実行されると、
   第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含み、前記第１のリソースの前記リンクは、第２のリソースに向けられている、ことと、
   前記リンクを管理するための要求を受信することと、
   前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
   を含む動作を前記プロセッサに行わせ、
   前記管理することは、前記第１のリンクプロファイルに関連付けられた前記第１のリソースの前記リンクの使用と、第２のリンクプロファイルに関連付けられた前記第１のリソースのリンクの使用との間の衝突を解決することを含む、デバイス。
2. 前記リンクの使用を管理することは、時間に基づいてトリガされる、請求項１に記載のデバイス。
3. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づく、請求項１から２のいずれか１項に記載のデバイス。
4. 前記リンクを管理することは、前記リンクを削除することを含む、請求項１から３のいずれか１項に記載のデバイス。
5. 前記リンクを管理することは、前記リンクを更新することを含む、請求項１から４のいずれか１項に記載のデバイス。
6. 前記リンクは、ユニフォームリソース識別子である、請求項１から５のいずれか１項に記載のデバイス。
7. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づき、前記コンテキスト情報は、帯域幅を含む、請求項１から６のいずれか１項に記載のデバイス。
8. リソースリンク管理のための方法であって、前記方法は、
   第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含む、ことと、
   前記リンクを管理するための要求を受信することと、
   前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
   を含み、
   前記管理することは、前記第１のリンクプロファイルに関連付けられた前記第１のリソースの前記リンクの使用と、第２のリンクプロファイルに関連付けられた前記第１のリソースのリンクの使用との間の衝突を解決することを含む、方法。
9. 前記第１のリンクプロファイルに関連付けられた前記第１のリソースの前記リンクは、第２のリソースに向けられている、請求項８に記載の方法。
10. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づく、請求項８から９のいずれか１項に記載の方法。
11. 前記リンクを管理することは、前記リンクを削除することを含む、請求項８から１０のいずれか１項に記載の方法。
12. 前記リンクを管理することは、前記リンクを更新することを含む、請求項８から１１のいずれか１項に記載の方法。
13. 前記リンクは、ユニフォームリソース識別子である、請求項８から１２のいずれか１項に記載の方法。
14. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたデバイスのコンテキスト情報に基づき、前記コンテキスト情報は、帯域幅を含む、請求項８から１３のいずれか１項に記載の方法。
15. コンピュータ実行可能な命令を含むコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピューティングデバイスによって実行されると、
    第１のリンクプロファイルを受信することであって、前記第１のリンクプロファイルは、第１のリソースのリンクの使用の構成を定義する命令を含む、ことと、
    前記リンクを管理するための要求を受信することと、
    前記要求に応答して、前記第１のリンクプロファイルに基づいて、前記リンクの使用を管理することと
    を含む動作を前記コンピューティングデバイスに行わせ、
    前記管理することは、前記第１のリンクプロファイルに関連付けられた前記第１のリソースの前記リンクの使用と、第２のリンクプロファイルに関連付けられた前記第１のリソースのリンクの使用との間の衝突を解決することを含む、コンピュータ読み取り可能な記憶媒体。
16. 前記第１のリンクプロファイルに関連付けられた前記第１のリソースの前記リンクは、第２のリソースに向けられている、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
17. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づく、請求項１５から１６のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
18. 前記リンクを管理することは、前記リンクを削除することを含む、請求項１５から１７のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
19. 前記リンクを管理することは、前記リンクを更新することを含む、請求項１５から１８のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記リンクの使用を管理することは、前記第１のリソースに関連付けられたデバイスのコンテキスト情報に基づき、前記コンテキスト情報は、帯域幅を含む、請求項１５から１９のいずれか１項に記載のコンピュータ読み取り可能な記憶媒体。