oneM2M−TS−0001 oneM2M機能アーキテクチャ−V−0.8.0では、リンクがリソース間に構築されることができ、リソースは、別のリソースに向かう1つ以上のリンクを有することができることを示す。本明細書で検討されるリンクは、URIを1つのリソースの属性内に記憶するとき、2つのリソース間に構築され得、リンクは、別のリソースに向かっている。例えば、リンクは、リソース−BのURIをリソース−Aの属性(例えば、属性−1)に割り当てることによって、リソース−Aからリソース−Bに構築されることができる。リンク管理タスクは、リンクプロファイルをLMSに提出することを通して、エンティティによって構築されることができる。リンク管理タスクは、その(その共有)リンクプロファイルに基づいて、1つ以上の属性に対する構成を行うLMSを参照し得る。タスクは、対応するリンクプロファイルがLMSから削除された場合(エンティティによって)、LMSから削除され得る。図6は、2つのリソース間の例示的リンクを図示する。図6に示されるように、ロジックリンク112は、リソース−B 113のURIをリソース−A 111の属性(属性−1 115)に割り当てることによって、リソース−A 111からリソース−B 113に構築される。本明細書では、リソース−A 111は、リンク元リソース、リソース−B 113は、リンク先リソース、属性−1 115は、ロジックリンク112のリンク対応リソース(属性−1 115内のURIの表現)と称される。図6に関する例によってサポートされるように、リンク元リソースは、別のリソース(例えば、リソース−B 113)に向かうURIを含む属性等(例えば、属性−1 115)を記憶するリソース(例えば、リソース−A 111)である。リンク対応属性は、リソース(例えば、リソース−B 113)にリンクし、別のリソース(例えば、リソース−A 111)内に位置するURIを記憶する属性等(例えば、属性−1 115)である。最後に、リンク先リソースは、リソース(例えば、リソース−A 111)内に位置するURIの宛先であるリソース(例えば、リソース−B 113)である。
表1は、リンクを構築するために使用され得る、oneM2M仕様からの例示的属性を提供する。図7Aは、表1から得られたリンク対応属性を伴う実施例を図示する。図7Aに示されるように、<subscription1>リソースの2つの属性(例えば、「parentID」および「accessControlPolicyID」)が、それぞれ、<AE1>および<accessControlPolicy1>リソースのURIで設定されている。2つのリンクは、故に、<subscription1>と2つのリソース(例えば、<AE1>および<accessControlPolicy1>)との間に構築される。図7Bは、図7Aに類似しており、非スケジュールベースのリンクプロファイルリンクプロファイルに関して以下により詳細に論じられるであろう。
リンクプロファイルに基づいて1つ以上のリンク対応属性を動的に構成し得るリンク管理サービス(LMS)が開示される。独立リンク管理および統合されたリンク管理等、LMSをサポートする複数のタイプのアーキテクチャが、存在し得る。独立リンク管理および統合されたリンク管理は、本明細書により詳細に論じられる。
図8は、LMSを実装する、例示的システムを図示する。M2Mサーバ124は、リンク管理に関連付けられた発信側123を含み得る。発信側123は、M2Mサーバ124内に位置し、他のデバイスの中でもとりわけ、M2Mゲートウェイ122、M2Mデバイス125、M2Mデバイス126、およびM2Mデバイス127に通信可能に接続され得る。発信側123は、サービスのためのアプリケーション(例えば、アプリケーションエンティティ−AE)であり得る。発信側123は、1)リンクプロファイル(例えば、リンクプロファイル128)をLMS121に提出すること、2)リンクプロファイルを更新すること、または、3)リンクプロファイルをLMS121から削除または登録解除することに対する要求を開始することができる。要するに、発信側123は、リンク管理関連要求を初期化する。発信側123は、リンク管理関連要求を開始するための許可を有するべきである。代替として、発信側123は、リソースの所有者であるので、リンク対応属性(例えば、属性−1 115)が属するリンク元リソース(例えば、リソース−A 111)を作成する、エンティティであり得る。発信側123は、ある属性に対するリンク管理を開始し得る任意の数のエンティティまたはデバイス(例えば、AE、共通サービスエンティティ−CSE、ネットワークサービスエンティティ−NSE、M2Mサーバ、M2Mゲートウェイ、M2Mデバイス等)であり得る。
M2Mゲートウェイ122は、LMS121を含むことができる。LMS121は、リンクプロファイル128を含み、他のデバイスの中でもとりわけ、発信側123およびM2Mデバイス125、M2Mデバイス126、およびM2Mデバイス127と通信可能に接続され得る。LMS121は、発信側123によって提出されたリンクプロファイル128に基づいて、属性−1 115のためのリンク管理を実施する責任がある。LMS121は、リンクホストCSEまたは別のCSE上に常駐し得る。リンクホストCSEは、リンク元リソース(例えば、リソース−A 111)およびそのリンク対応属性(例えば、属性−1 115)がホストされている場所である。LMS121は、本明細書に定義されるようなあるプロシージャを通して同様に更新/削除され得るリンクプロファイル128内に含まれる命令に基づいてリンク構成を実施する実行側としての役割を果たす。M2Mデバイス125、M2Mデバイス126、およびM2Mデバイス127は、M2Mゲートウェイ122およびそのサブコンポーネントと通信可能に接続され、M2Mサーバ124およびそのサブコンポーネントとも通信可能に接続され得る。各M2Mデバイスは、M2Mデバイス125内に見出されるようなリンク対応属性(例えば、属性−1 115)を有するリンク元リソース(例えば、リソース−A 111)を有し得る。
図8を継続して参照すると、以下は、芝手入れサービスに関してLMSを使用する例である。例えば、M2Mデバイス126、M2Mデバイス127、およびM2Mデバイス125は、風力センサ、湿度センサ、または温度センサ等のセンサであり得る。感覚データに関する通知を送信するために、各M2Mデバイス(125、126、および127)によってホストされる<subscription>リソース(例えば、リソース−A 111)が、存在し得る。リンクプロファイル(例えば、リンクプロファイル128)が、M2Mデバイス(125、126、および127)上にホストされる<subscription>リソースの「notificationURI」属性(例えば、属性−1 115)のために生成され得る。リンクプロファイルは、いつ、どのように、またはどの通知が、芝手入れサービス(例えば、発信側123)によって行われる芝手入れスケジュールのために必要とされるかをカスタマイズすることに役立ち得る情報を有し得る。これらのリンクプロファイルは、LMS121に提出され、LMS121は、リンクプロファイルに基づいて、リンクを管理する。
図9および図10は、リンク管理のアーキテクチャフレームワークを図示する。図9は、独立リンク管理を図示する。要するに、独立リンク管理は、リンクプロファイル(例えば、リンクプロファイル128)に基づいて、リンク管理を実行するが、リンクプロファイル間の衝突を考慮しない。図9に示されるように、リンクプロファイル128は、LMS121に提出される。加えて、リンクプロファイル128は、リソース−A 111の属性−1 115を定義する。LMS121は、提出されたリンクプロファイル128に基づいて、属性−1 115を構成する。
LMSは、異なるリソースの複数のリンク対応属性に対して統合されたリンク構成を実施する能力も有する。統合されたリンク管理(図10)は、それらの複数のリンク対応属性に対する構成が、互いに影響および相関され得、したがって、リンク対応属性に対する構成は、その関連付けられたリンクプロファイルを参照するだけでなく、存在する場合、あるシステム全体にわたるポリシに準拠する必要もあることを提供する。例えば、LMSは、ソースが別のCSEに移行されると、全リソースの親ID属性を更新する責任があり得る。加えて、LMSは、それに提出されるカスタマイズされたポリシ、または既存もしくは将来的規格仕様に準拠するポリシに従い得ることに留意されたい。
図10は、リンク管理のための例示的拡張または統合されたフレームワークを図示する。この例では、統合されたフレームワークは、例外ハンドリングルール(EHR)131と、サービス層全体にわたるリンク管理ポリシ(SLMP)133と、複数のリンクプロファイル(例えば、リンクプロファイル128およびリンクプロファイル136)と、LMS121と、属性−1 135を伴うリソース−Z 134と、属性−1 115を伴うリソース−A 111とを含む。図11は、M2MまたはIoTノード(例えば、M2Mゲートウェイ122)のサービス層内に限られる、図10に示される概念を図示する。リンク管理フレームワークの異なるコンポーネントは、以下により詳細に論じられる。LMS121に関して、LMS121は、そのリンクプロファイルに従って、異なるリンク対応属性を管理する責任がある。例えば、LMS121では、リンクプロファイルが提出された後、提出されたリンクプロファイルの各々に対応する特定のリンク管理タスクが、構築され得る。例えば、リンク管理タスクをLMS121において構築することに関して、プロファイルは、最新の温度について異なるアプリに知らせるための<subscription>リソースのnotificationURI属性等の属性を構成する方法を含み得る。従われるべき構成命令は、notificationURIが、9am−3pmの間、WeatherReportAppのURIに設定され、3pm−11pmの間、TripPlanningAppのURIに設定されるであろうことを含み得る。LMSは、対応するデバイスを初期化し、そのリンクプロファイル内に規定された前述の命令に従うことによって、前述のリンク構成を実施するための動作を実行し得る。
典型的には、リソース−A 111の属性−1 115のためのリンクプロファイル128は、リソース−A 111および属性−1 115がすでに作成されている場合、生成され、LMS121に提出されることができる。その後、作成されたリンク対応属性(例えば、属性−1 115)の値を自ら構成することを他のエンティティに要求する代わりに、LMS121は、前述のようなその必要性に基づいて、あるエンティティによって生成され得るリンクプロファイル(例えば、リンクプロファイル128およびリンクプロファイル136)内に含まれる仕様に基づいて、作成されたリンク対応属性をそれらのエンティティの代わりに構成することができる。他のエンティティは、その必要性に基づいて、動的リンク管理動作のためにLMSを使用するCSEまたはアプリケーション関連ソフトウェアインスタンスのいずれかであり得る。例えば、依然として、前述のWeatherReport Appの例を使用すると、温度デバイスを管理する責任があるソフトウェアインスタンス(他のエンティティ)は、温度センサからの最新更新について異なるアプリ(例えば、WeatherReport AppまたはTripPlanning App)に知らせるために、特定の<subscription>リソースの「notificationURI」属性のためのリンクプロファイルを構築することができる。LMS121と属性−1 115(管理されるべきリンク対応属性)とが、同じ場所に位置する(例えば、リソース−A 111が、LMSを本質的にサポートするCSE上にある)場合、属性−1 115は、CSEの内側に構成され、それは、通信オーバーヘッドの削減につながる。加えて、LMS121は、コンピューティングリソースが存在する限り、任意のノード(例えば、ASN−CSE、MN−CSE、またはIN−CSE)上に展開されることができる。属性−1 115は、そのリンクプロファイル128に従ってLMS121によって動的に構成される現在の有効な値を記憶する。LMS121によってリンクがどのように構成されるかは、属性−1 115の値を読み出すための許可がない限り、隠され得る。
SLMP133は、関連属性(例えば、属性−1 115および属性−1 135)に対するリンク構成が、そのリンクプロファイルに加え、さらに準拠する必要がある規制または制約の組である。SLMPは、それらの属性に対して独立構成を実施するために使用されるリンクプロファイルに加え、異なる属性におけるリンク構成がどのように互いに影響され得るかについての全体的規制および制約の組である。リンクプロファイル128と同様に、SLMP133も、それが許可されたエンティティによって、LMS121に提出されることができる。SLMP133に関する例は、oneM2Mの「parentID」に関連し得る。SLMP133は、いくつかのアプリケーション特定のセキュリティ理由に起因して、ある組のリソース(例えば、リソース−Z 134)が、同一親を別の組のリソース(例えば、リソース−A 111)と共有することが不可能であるというルールを含み得る。
図11および統合されたリンク管理を継続して参照すると、EHR131は、リンク構成における例外に対処するために使用される、ルールを有する。所与のSLMPに対して、同様に、例外ハンドリングルールの対応する組が、存在し得、それらは、そうすることを許可されたエンティティによってLMS121に提出され得る。LMS121が、あるリンク対応属性(例えば、属性−1 115または属性−1 135)を構成すると、LMS121は、関連リンクプロファイル(例えば、リンクプロファイル128およびリンクプロファイル136)だけでなく、関わるSLMPも考慮し、任意の衝突が存在する場合、EHRを適用する。EHRは、リンクプロファイル内に含まれる独立構成がSLMPと衝突を有するときに使用されるルールの組である。
時として、好ましい実装は、mCSEによってホストされるリソースの全部または大部分のリンク対応属性のリンクプロファイルを同一LMS(例えば、LMS121)に提出させ得、そのようなLMSは、関連SLMPおよびEHRの組も保持するであろう。
論じられるように、リンクプロファイルは、このリンク対応属性が属するリンク元リソースを生成するエンティティによって生成され、LMSに提出され、リンク管理タスクを初期化することができる。代替として、リンクプロファイルは、リンクプロファイルが、いくつかの属性に関連付けられ得、それらの属性に対する全てのリンク構成(リンクプロファイルによって規定される)が、グループ動作のようなものとなるであろうという意味で、2つ以上のリンク対応属性を構成するために使用されることもできる。提示を簡略化するために、本明細書の節に詳細を導入するとき、基本的な例に焦点が当てられる。
以下に論じられるのは、スケジュールベースのリンクプロファイルおよび非スケジュールベースのリンクプロファイルである。以下に論じられる2つのタイプのリンクプロファイルは、例である。種々のリンクプロファイルが、異なるアプリケーションシナリオに応じて、作成されることができる(例えば、イベントまたは条件ベースのリンクプロファイル)。表2は、異なるタイプのリンクプロファイルに関する共通アイテムを列挙する。表2にさらに説明されるように、tprofileType(例えば、1=スケジュールベースのプロファイル、2=非スケジュールベースのプロファイル)、linkOriginURI(例えば、属性−1 115のためのURI)、および各リンクプロファイルタイプのためのattributeNameが、存在し得る。
スケジュールベースのリンクプロファイルに関して、リンク対応属性が、スケジュールベースのリンクプロファイルに関連付けられる場合、この属性を通して構築されるリンクは、特定の時間間隔の間、有効であり得る。スケジュールベースのリンクプロファイルは、スリーピノード(例えば、定期的にスリープタイプモードに入り得るデバイス)が存在するシナリオをサポートするために有用であり得る。表3は、スケジュールベースのリンクプロファイルのためのdestURIListおよびvalidTimeIntervalsを含む、例示的アイテムを提供する。
非スケジュールベースのリンクプロファイルに関して、リンク対応属性が、非スケジュールベースのリンクプロファイルに関連付けられる場合、この属性を通して構築されるリンクは、システム内のリアルタイムコンテキストおよびそのリンクプロファイル内に定義された関連ルールに基づいて構成され得る。
コンテキスト情報を考慮し得る、非スケジュールベースのリンクプロファイルに関するさらなる観点のために、あるシナリオが、図7Bを参照して論じられる。この使用例に関するシナリオのうちの1つは、図7Bに示される:MN−CSEノード上にホストされる<CSEBase1>の子リソースである、<subscription>リソース(例えば、<subscription1>)。特に、notificationURI属性は、両方とも<CSEBase1>に関心があるので、<AE2>(ASN−CSE1によってホストされる)または<AE3>(ASN−CSE2によってホストされる)のURIのいずれかを保持し得る。しかしながら、notificationURIの設定方法は、コンテキスト情報(例えば、ほぼリアルタイム条件)または任意のユーザ定義もしくはアプリケーション特定のルールに基づき得る。例えば、<AE1>は、一次通知受信側(例えば、<AE1>のURIをnotificationURI属性に割り当てること)であり得、notificationURIは、<AE1>が到達不可能になると常に、<AE2>のURIに動的に設定され得る。
従来のサービス層実装は、明示的更新動作を通して以外、前述のリンク対応属性(例えば、図7BにおけるnotificationURI属性)を介して動的に構成するための機構を提供しない。特に、従来の実装では、それらの更新動作の開始側が、管理されるべきリソースおよび対応する属性をホストする、CSE(例えば、図7BにおけるMN−CSE)から離れている場合、そのような頻繁な更新動作は、大幅な通信オーバーヘッドを生じさせ得る。
oneM2Mに関して、<subscription>の従来の実装は、高度な特徴のサポートするための試みにおいて「重い」。例えば、notificationSchedule子リソースおよびpendingNotification属性が、<subscription>を有効にし、通知のためのある程度の知能を有することを有効にするために使用される。ますます多くの新しい属性を新しい特徴(前述のようなnotificationURIを動的に構成する等)のために従来の様式において定義すると、リソースは、さらに重くなり得る。開示されるリンク管理サービスは、概して、よりスケーラブルな実装を可能にする。
表4は、非スケジュールベースのリンクプロファイルのためのdestURICandidateList、contextInfoURI、およびlinkSelectionRulesを含む、例示的アイテムを提供する。
図12−図16等の本明細書に図示されるステップを行うエンティティは、図28Cまたは図28Dに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(例えば、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることを理解されたい。ある実施例では、M2Mデバイスの相互作用に関するさらなる詳細を以下に伴うが、図12の発信側123(例えば、AE)は、図28AのM2M端末デバイス18上に常駐し得る一方、図12のCSE109は、図28AのM2Mゲートウェイデバイス14上に常駐し得る。
図12−図17に関して以下に論じられるのは、リンク管理のためのプロシージャである。図12は、LMSによる属性のURIの管理のためのリンク管理タスクを作成するための例示的フローを図示する。ステップ203では、発信側123は、属性−1 115のためのリンク管理タスクを作成するために使用され得る要求をCSE109に送信する。メッセージは、リンクプロファイル128と、関連付けられたデータ(例えば、リンクプロファイルタイプに関する関連付けられたデータ)とを含む。ステップ203のメッセージは、発信側123におけるアプリケーションロジックによってトリガされ得る。別の実施例では、LMS121は、リンクプロファイルを先を見越して収集し得る。LMS121は、リンクプロファイルを異なるエンティティから能動的に要求するか、またはパブリッシュもしくはサブスクライブ機構を使用し得る。さらに別の例では、LMS121は、システムステータスを観察することによって、リンクプロファイル128を先を見越して作成し得る。例えば、LMS121が、発信側123(例えば、アプリケーションエンティティ)が時々オフラインになることを観察する場合、LMS121は、発信側123が属する<group>リソースの「メンバリスト」に対して、発信側123が利用不可能になると、リンクプロファイル128が発信側123のURI(例えば、属性−1 115)が「メンバリスト」内からなくなるであろうような構成につながるであろうように、リンクプロファイル128を設定し得る。結果として、グループ動作は、そのオフライン時間の間、発信側123に及ばず、不必要な通信は、故に、削減されることになり得る。
ステップ204では、CSE109は、ステップ203の要求を検証する。例えば、CSE109は、リソース−A 111および属性−1 115が存在するかどうか、発信側123がそのような動作のための許可を有するかどうか等を決定し得る。それらのいずれにも当てはまらない場合、要求は、LMS121にコンタクトすることなくCSE109によって拒否され得る。ステップ205では、CSE109は、リンクプロファイル128をLMS121に送信する。ステップ206では、LMSは、リンクプロファイル128を検証する。例えば、LMS121は、属性−1 115がすでに別の以前に提出されたリンクプロファイルに関連付けられて管理されているかどうかを決定する。該当する場合、ステップ205の要求は、この新しい提出されたプロファイル(リンクプロファイル128)が既存のリンクプロファイルに取って代わらない場合、LMSによって拒否され得る。そうでなければ、LMS121は、以下を行い得る:1)あるルール/条件が満たされると、LMS121が対応するリンク構成動作を実行し得るように、リンクプロファイル128に従って、新しいトリガを定義すること、2)属性−1 115に関連する任意の他のリンクプロファイルが将来提出された場合、LMSが、古いリンクプロファイル128の置換もしくは更新すること、または新しいものを拒否すること等の動作を実施できるように、属性−1 115を「管理済み」(または別の用語またはマーキング)としてマークすること、3)リンク管理ID(値は、任意の命名スキームに基づき得る)をこのリンク管理タスクのためのグローバル参照(例えば、エンティティは、リンク管理IDを規定することによって、既存のリンク管理タスクを削除するための要求を送信し得る)として生成すること。以下の説明は、リンク管理IDを使用すべき時間または場所に関するさらなる議論を提供する。
ステップ207では、LMS121は、リンク管理タスクがリンク管理IDとともに正常に確立されたことを示す確認をCSE109に送信する。ステップ208では、LMS121が属性を操作するためのアクセスを有し、必要に応じて他のエンティティに対するアクセスを制限するように、CSE109は、属性−1 115に特定の別個のアクセスポリシを作成し得るか、または、CSE109は、既存のアクセス制御ポリシを修正し得る。それらの特定のアクセス制御ポリシも、リンク管理IDに関連付けられ得、リンク管理IDは、証明書検証のために使用されることができ、その要求内にリンク管理IDを規定し得る者のみ、属性−1 115における構成を行うことが可能にされるであろう。ステップ209では、CSE109はさらに、リンク管理IDとともに確認を発信側123に返信し、それによって、発信側123は、属性−1 115のステータスを認識し得る。
図13は、スケジュールベースのリンクプロファイルを使用してリンク管理を実施するための例示的方法を図示する。ステップ211では、LMS121は、スケジュールベースのリンクプロファイル(例えば、リンクプロファイル128)に基づいてトリガされる。例えば、LMS121は、タイマによってトリガされ、属性−1 115の値を更新し得る。ステップ212では、LMS121は、属性−1 115のリンクプロファイル128に従って属性−1 115のURIを更新するための要求をCSE109に送信する。リンク管理タスク確立中に生成されるリンク管理IDが、CSE109が属性−1 115に対する動作許可をチェックできるように、要求内に含まれ得る。ステップ213では、CSE109は、ステップ212において提案された動作が許可されるかどうかを決定する。該当する場合、属性−1 115の値は、ステップ212の要求内の値で更新され得る。ステップ214では、CSE109は、要求される動作の成功または失敗に関して、メッセージをLMS121に返信する。
図14は、非スケジュールベースのリンクプロファイルを使用してリンク管理を実施するための例示的方法を図示する。ステップ221では、LMS121は、どのコンテキスト情報が非スケジュールベースのリンクプロファイル(例えば、リンクプロファイル128)に基づいて収集される必要があるかどうかを決定する。ステップ223では、LMS121は、コンテキスト情報に対するクエリを送信する(リアルタイムであり得る)。コンテキスト情報は、とりわけ、デバイスへの帯域幅配分、通信セッションの待ち時間(例えば、アプリケーションの遅延公差に関連付けられる)、デバイスの場所もしくはランニングステータス、デバイスの電力制御要件の分類、またはビジネスロジックに影響を及ぼし得る関連情報を含み得る。LMS121は、代替として、要求されるリアルタイム情報のプロバイダとサブスクリプション関係を確立し得る。本明細書では、コンテキスト情報を収集する、いくつかのエンティティが存在すると仮定される。ステップ225では、コンテキストプロバイダ105は、ステップ223の要求に基づいて、関連コンテキスト情報を返す。ステップ226では、LMS121は、コンテキスト情報と非スケジュールリンクプロファイル内に規定された関連ルールとを比較し、それは、LMS121が属性−1 115を再構成するようにトリガする。ステップ227では、LMS121は、属性−1 115の値を更新するための要求をCSE109に送信する。ステップ228では、CSE109は、ステップ227の受信された要求をチェックし、要求に応じて、属性−1 115における更新動作を実行する。ステップ229では、CSE109は、メッセージを送信し、ステップ228に関連付けられた動作のステータスを中継し得る。
図15は、LMSによる属性のURIの管理のためのリンク管理タスクを削除するための例示的フローを図示する。ステップ231では、発信側123は、属性−1 115のためのリンク管理タスクを削除するための要求をCSE109に送信する。ステップ233では、CSE109は、ステップ231の要求を検証する。例えば、CSE109は、発信側123がそのような動作のための許可を有するかどうかを決定し得る。ステップ235では、CSE109は、リンク管理タスクを削除するための要求をLMS121に送信する。ステップ236では、LMS121は、リンクプロファイル128および関連トリガを削除する。ステップ237では、LMS121は、リンク管理IDを含み得る、リンク管理タスクが正常に削除されたことを示す確認をCSE109に送信する。ステップ238では、CSE109は、属性−1 115に特定の別個のアクセスポリシを削除し得る。属性−1 115は、リソース−A 111が削除されない限り、依然として、存在することができる。ステップ239では、CSE109は、属性−1 115のステータスを認識するために、リンク管理IDとともに確認を発信側123に返信し得る。
図16は、リンク元リソースを削除するための例示的フローを図示する。ステップ241では、発信側123は、リンク元リソース(例えば、リソース−A 111)を削除するための要求をCSE109に送信する。ステップ242では、CSE109は、ステップ241の要求を検証する。例えば、CSE109は、発信側123がそのような動作のための許可を有するかどうかを決定し得る。例えば、CSE109はまた、削除されるべきリソース−A 111のどの属性が現在LMS121によって管理されているかをチェックし得、それは、それらの属性(例えば、属性−1 115)に対するリンク管理動作に特別な全アクセス制御ポリシ(およびその関連付けられたリンク管理ID)を調べることによって行われることができる。それらのリンク管理IDは、次いで、LMS121に送信され得る。
ステップ243では、CSE109は、リソース−A 111を削除するための要求をLMS121に送信する。ステップ244では、LMS121は、受信されたリンク管理IDに対応する関連トリガおよび関連リンクプロファイル(例えば、リンクプロファイル128)を削除する。リソース削除動作は、他のリソースおよびリンクにも影響を及ぼし得るので、いくつかのサービス層全体にわたるリンク管理動作も、トリガされ得る。ステップ245では、LMS121は、リソース−A 111に関連するリンク管理タスクが正常に削除されたことを示す確認をCSE109に送信する。ステップ246では、CSE109は、リソースA111の属性のリンク管理動作に関連するリソース−A 111を削除する。ステップ247では、CSE109は、リソース−A 111の削除に関するステータスメッセージを返信し得る。
所与のリンクプロファイルPに関連する既存のリンク管理タスクに対して、更新プロシージャは、図12に関して提供される作成プロシージャに類似することに留意されたい。加えて、読み出し動作は、その対応するリンク管理IDを規定することによって、リンクプロファイル128をLMS121から読み出すことができる。SLMP133またはEHR131をLMS121に/から提出、更新、および削除する方法に関連するプロシージャは、リンクプロファイル128に関して開示されるものに類似する。
LMSによって使用されるSLMP、EHRおよびリンクプロファイル間の相互作用に関して、以下でさらに議論される。図17は、SLMPを提出する、更新する、または削除するための要求をLMS121が受信するときのLMS121との関連相互作用を図示する、例示的フロー図を図示し、これはまた、いくつかの簡単な修正後、EHRにも適用可能である。
ステップ250では、LMS121は、新しい/更新されたSLMP133を受信するか、またはLMS121に記憶される既存のSLMP133の削除要求を受信する。ステップ251では、LMS121は、要求のタイプを調べ(例えば、要求が、「作成」または「更新」であるかどうか確認する)、それは、新しいSLMP133を提出/作成すること(該当する場合、ステップ255に進む)、既存のSLMP133を更新すること(該当する場合、ステップ254に進む)、またはすでにLMS121に記憶されているSLMP133を削除すること(該当する場合、ステップ252に進む)であり得る。
ステップ252では、LMS121は、SLMP133に関連する登録されたリンクプロファイル(例えば、リンクプロファイル128およびリンクプロファイル136)を調べる。そのために、SLMP133のアプリケーションスコープが、利用され得、アプリケーションスコープは、どの属性にSLMP133が適用されることができるかを示す。例えば、削除されるべきSLMP133が、それぞれ、リソース−A 111およびリソース−Z 134の属性−1 115および属性−1 135に適用可能な場合、異なるリソースの属性−1のリンクプロファイルが、調べられ、ソートされるであろう。ステップ253では、LMS121は、SLMP133を削除するだけでなく、ステップ252においてソートされたリンクプロファイル(例えば、リンクプロファイル128およびリンクプロファイル136)に基づいて、関わるリンク対応属性(属性−1 115および属性−1 135)を再構成する。特に、SLMP133が現時点で存在しないので、それらの属性の値は、そのリンクプロファイルに基づいて、リセットされるであろう。次いで、ステップ251に進む。
ステップ254では、LMS121は、既存のSLMP133を新しく受信されたSLMPと置換する。代替として、既存のSLMP133は同様に、部分的にのみ更新され得る。ステップ255では、LMS121は、この新しく受信されたSLMPに関連する、全リンクプロファイルをソートし、詳細なプロセスは、ステップ252に説明されるものに類似する。
ステップ256では、LMS121は、現在のリンク構成がこのSLMP133に準拠するかどうかを評価する。例えば、LMS121は、それらのリンクプロファイルの関連付けられた属性に割り当てられるべき値がこのSLMP133によって規定されたポリシを満たすかどうかを評価し得る。「はい」である場合、ステップ260に進む。そうでなければ、いくつかのリソースの関連属性の値が、このSLMP133によって規定されたポリシと整合しないか、または衝突することを示す。故に、例外ハンドリングプロセスが、トリガされる(例えば、ステップ257に進む)。ステップ257では、LMS121は、EHR131が存在するかどうかをチェックする(典型的には、あるSLMP133がEHR131に関連付けられ得る)。「はい」である場合、ステップ258に進む。そうでなければ、ステップ259に進む。
ステップ258では、LMS121は、デフォルト例外ハンドリングルールを使用して、関連属性の値を再構成するだけではなく、この受信されたSLMP133に準拠しない、リンクプロファイルによって規定されたある構成をサポートするために使用されるいくつかのトリガを一時的に無効にし得る。ステップ259では、LMS121は、直接、対応するEHR131を参照することができ、関連動作は、ステップ258に類似する。
ステップ260では、LMS121は、将来、新しいリンクプロファイルが、SLMP133に関連する属性のために定義されるとき、最新SLMP133に従い、任意のさらなる衝突を回避し得るように、システム内の他のエンティティに、必要に応じて、最新SLMP133を知らせる。前述のステップは、主に、SLMP133における関連動作(作成、更新、または削除)によって影響され得る、既存のリソースにおけるリンク対応属性のための必要再構成を実行することに焦点が当てられている。
図18は、リンクプロファイル、SLMP、およびEHR間の相互作用の例示的例証である。この例では、リソース−A 111およびリソース−Z 134等の2つの<group>リソースがシステム内に存在する。属性−1 115および属性−1 135(例えば、<group>リソースのmemberList属性)は、それぞれ、リンクプロファイル128およびリンクプロファイル136に基づいて、LMS121によって構成される。アプリケーション特定の要件(例えば)に基づいて、リンクプロファイル128内の構成仕様のうちの1つは、図8の発信側123のURI(例えば、AEリソース−<AE>)が8AM−8:30AMの間に属性−1 115内に含まれるというものである。加えて、発信側123を指すURIは、8:20AM−9:30AMの間に属性−1 135内に含まれる。故に、発信側123を指すURIは、8:20AM−8:30AMの間、2つのリソース(<group>リソース)内でアクティブであろう。おそらく後に、LMS121は、ポリシが、発信側123を指すURIが2つ以上のグループの属性内に含まれることができないというものであるSLMP133も受信し得る。この例に対して、そのようなポリシは、リンクプロファイル128およびリンクプロファイル136内に含まれる前述の構成仕様に影響を及ぼし、衝突するであろう。その結果、EHR131が、衝突を解決するために、8:20AM−8:30AMの間、LMS121が、発信側123を指すURIをリソース−A 134の属性−1 115にのみ割り当てるであろうように、ここで利用されるであろう。ここでは、属性−1 115は、属性−1 135より高い優先順位を有すると仮定される。優先順位は、URI使用の頻度または時間の長さに関して、手動で割り当てられる優先順位または自動的に割り当てられる優先順位等の要因に基づき得る。例えば、時間の長さに関して、属性−1 115は、30分(8:00AM−8:30AM)が配分される一方、属性−1 135は、合計50分(8:20AM−9:30AM)が配分されるので、優先され得る。属性−1 135は、優先順位決定の結果に基づいてそのように行われるように制限された後でも、URIを使用するためのより長い時間フレームを有する。
以下に論じられるのは、oneM2M内にさらに統合され得る方法に関連してリンク管理を論じる例である。oneM2Mは、能力サービス機能(CSF)と称される能力を定義する。oneM2Mサービス層は、能力サービスエンティティ(CSE)と称される。故に、開示されるLMS121は、図19に示されるように、CSEによって実装されるCSFと見なされ得る。
好ましいシナリオでは、各CSEは、リソースリンク管理動作がそのLMSによって取り扱われ得るように、その独自のLMSを同一デバイス上に実装することが提案される。しかしながら、CSE(例えば、CSE109)が、非常に限定された能力を伴うリソース制約ノード上に展開される場合、別のCSEによって実装されるLMS(例えば、LMS121)に依拠することもできる。そのような場合でも、依然として、リンクが遠隔発信側(例えば、発信側123)によって構成される必要がある場合と比較して、低通信オーバーヘッドにつながることに留意されたい。開示されるLMSは、以下の方法において、oneM2Mサービス層における参照点に影響を及ぼし得る。
・ AEが、CSE(例えば、リンクホストCSE)によってホストされるリソースの属性に対してリンク管理タスクを開始するための要求(リンクプロファイルとともに)をCSEに送信する場合、mcaインターフェースを通過し得る。
・ CSE−1が、CSE−2(例えば、リンクホストCSE)によってホストされるリソースの属性に対してリンク管理タスクを開始するための要求(リンクプロファイルとともに)を別のCSE−2に送信する場合、mccインターフェースを通過し得る。
・ リンクホストCSEが、LMSにさらにコンタクトする必要がある場合、
− このCSEが、それ自体によって実装されるLMSを利用する場合、1つのM2Mデバイスまたは関連M2Mデバイスのグループにおいて内部処理を伴い得る。
− CSEが、別のCSEによって実装されるLMSを利用する場合、mccインターフェースを通過し得る。
図20−図22は、開示されるLMSのための例示的RESTfulリソースベースのインターフェースを図示する。以下の凡例は、図20−図22のために使用される。
・ 長方形ボックスは、リソースおよび子リソースのために使用される
・ 丸い角を伴う長方形ボックスは、属性のために使用される
・ 各属性および子リソースの多重度が、定義される
・ 「<」および「>」で区切られたリソース名は、リソースの作成中に割り当てられた名称を示す
本明細書に開示されるのは、<linkProfile>263の観点におけるリソースであり、<SLMP>264および<EHR>267は、図20−図22に示されるように定義され、それらのリソースの各々は、いくつかの属性を有する。例えば、<linkProfile>263における属性は、表2−表4に定義されるように、profileType、linkOriginURI、attributeName、destURI、validTimeIntervals、destURICandidateList、contextInfoURI、linkSelectionRules等のリンクファイル内に定義された異なるデータアイテムに対応する。同様に、<SLMP>264および<EHR>267における属性は、それぞれ、<SLMP>264のための関連付けられたEHRおよび<EHR>267のための関連付けられたSLMP、<SLMP>264のためのaffectedAttributeList(SLMP264が影響を及ぼすであろう属性)およびpolicyList、<EHR>267のためのruleListに関連する情報を含む。
図23は、oneM2Mサービスコンポーネントアーキテクチャ(例えば、oneM2M−TS−0007 oneM2M機能アーキテクチャ−V−0.3.0)におけるLMS121の実装アーキテクチャの例示的例証である。図23に示されるように、LMS121は、「Msc」参照点273を経由して他のコンポーネントと相互作用し得る、「リンク管理サービスコンポーネント」271と呼ばれる個々のサービスコンポーネントを差し込むことによって実装され得る。
以下に論じられるのは、「parentID」属性等のoneM2M属性、<subscription>リソース、および<group>リソースを考慮したリンク管理詳細である。
LMS121の使用によって、リソース−A 111は、必要に応じて、動的に異なるリソースの子リソースであり得る。そのために、リソース−A 111のparentIDが、本明細書に開示されるように、2つのタイプのリンクプロファイルによって構成されることができる。CSE109における複数のリソースのparentIDも、任意のアプリケーション要件をサポートするために、LMS121によって同様に管理されることができる。例えば、SLMP133は、「parentID」属性のために定義されることができ、それに基づいて、リソース階層が、所望に応じた様式で(許可される場合)、動的に再編成または再構成されることができる。任意のアプリケーション特定のポリシが、SLMP133として定義され、任意の既存または将来的oneM2M仕様(または任意の他の規格)によって可能にされる新しい特徴を有効にすることができることに留意されたい。例えば、以下の例示的ポリシも、「parentID」属性のためにSLMP133内に含まれることができる。
1. リソースの2つの組は、例えば、セキュリティ問題に起因して、(一方の組におけるリソースのparentIDを構成する方法が他方の組におけるリソースのそれらの構成に影響を及ぼすであろうように)同じ親を共有することができないというポリシ。
2. parentID属性は、リソースが2つ以上の親を有し得るように、同時に複数のURIを割り当てられることができるというポリシ。特に、図24は、そのようなポリシが<subscription>リソースの「parentID」属性に適用されるときの付加価値サービスを示す。
図24−図26等の本明細書に図示されるステップを行うエンティティは、論理エンティティであることを理解されたい。ステップは、図28Cまたは図28Dに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行され得る。ある実施例では、M2Mデバイスの相互作用に関するさらなる詳細を以下に伴うが、図26の発信側123は、図28AのM2M端末デバイス18上に常駐し得る一方、図26のCSE109は、図28AのM2Mゲートウェイデバイス14上に常駐し得る。
図24は、LMSを使用したparentID属性に関する方法の例示的例証である。図24に示されるように、開始時、既存のoneM2M仕様によって定義されるように、1つのリソースが、1つの親を有することができる。ステップ281では、IN−CSE107は、新しいSLMP133をLMS121に提出し得る。この要求は、1つのリソースが2つ以上の親を有することを可能にするために、アプリケーションによってトリガされ得る。ステップ282では、LMS121は、対応するSLMPを更新し、したがって、リソースの「parentID」は、2つ以上のURIを保持することが可能にされる。ステップ284では、LMS121は、このSLMP133に対して、システム内のエンティティ(例えば、発信側123およびCSE109)に知らせる。ステップ285では、発信側123(例えば、AE−1)は、それ(発信側123)がCSE109のリソース<AE−2>およびCSE109の<AE−3>に関心があるので、<subscription>リソースを作成するための要求をCSE109に送信し得る。しかしながら、<AE−2>および<AE−3>のための2つの別個の<subscription>リソースを作成する代わりに、新しいポリシを用いて、AE−1は、1つの<subscription>を作成し、そのparentIDを<AE−2>および<AE−3>の両方のURIで設定することのみ必要とする。ステップ286では、CSE109は、ステップ285の要求を検証する。ステップ287では、CSE109は、ステップ286において要求されたサブスクリプションのステータスに関して、通知を発信側123に送信し得る。ステップ288およびステップ289では、CSE109は、それぞれ、<AE−2>および<AE−3>に対する任意の変更に関して、通知を送信し得る。故に、発信側123は、<AE−2>リソースだけではなく、<AE−3>リソースにおける変更に関する通知を受信することもできる。
図25は、<subscription>リソースのparentIDのためにリンクプロファイルによって有効にされる付加価値サービスのための方法の例示的例証である。この例では、1つのリソースは、動的に異なるリソースの子リソースであることができる。図25では、1つのリソースは、1つのみの親を有することができると仮定される。しかしながら、発信側123(例えば、<AE−1>)は、そのparentID属性のためのリンクプロファイル128とともに、<subscription>リソースを作成するための要求をCSE109に送信し得る。前述の例(図24)におけるように、発信側123は、リソース<AE−2>および<AE−3>の両方に関心があるが、代替方法においてである。CSE109において、発信側123から受信された要求に基づいて、対応するリンクプロファイルP内に定義された仕様に基づいて、<subscription>リソースを作成し、そのparentIDが<AE−2>のURであるように設定する。故に、発信側123は、<AE−2>における変更に関する通知を受信することができる。別の時に、いくつかの条件が満たされると、LMSは、トリガされ、<subscription>リソースのparentIDが<AE−3>のURIであるように自動的に更新し、発信側123は、<AE−3>に対する変更に関する通知を受信するであろう。
LMSは、システム全体にわたるリンク管理のためのエンティティであることができるので、動作効率の観点からも利益を有する。例えば、LMSはまた、質問(リソースが属するグループの数等)に回答し得るが、それは、すぐに明白にならないか、またはリソースの属性にアクセスすることによって直接回答されることができない。開示される属性およびそれらの属性に対するリンク構築動作は、厳密に対称ではない。例えば、memberListIDは、<group>リソースのために定義されているが、リソースは、それが属するグループを保持することができるgroupList属性を有していない。確かに、そのような新しい属性は、既存のoneM2M仕様を拡張させることによって定義されることはできる。代替として、別の方法は、リンクがLMSによって管理される場合、LMSに助けを求めることであり、そこから、回答も、例えば、リンクプロファイルを調べることによって、容易に得られることができる。
図25を継続して参照すると、ステップ140では、発信側123は、<AE−2>および<AE−3>リソースに関心があるので、CSE109において<subscription>リソースを作成することを決定する。ステップ141では、発信側123(<AE1>)は、その「parentID」属性のためのリンクプロファイルとともに、CSE109において<subscription>リソースを作成するための要求を送信する。ステップ142では、CSE109は、発信側123からの要求の動作の正しさをチェックし、<subscription>リソースを作成し、<subscription>リソースにおいて、parentIDは、<AE−2>のURIの値を有するようにデフォルト化される。ステップ143では、CSE109は、リンクプロファイルをLMS121に登録するためのメッセージを送信する。ステップ144では、LMS121は、内部処理を実施する(例えば、受信されたリンクプロファイルに従って、新しいトリガを定義する)。ステップ145では、LMS121は、メッセージを送信し、<subscription>リソースに関連するリンク管理タスクのための登録成功に関してCSE109と確認する。ステップ146では、CSE109は、<subscription>リソースの作成成功に関して発信側123と確認する。147では、CSE109の<AE−2>が、変更された。ステップ148では、CSE109は、<AE−2>の変更に関して発信側123に通知する。ステップ149では、リンクプロファイル内に規定された<subscription>リソースの「parentID」属性の値を更新することに対するアクションをトリガする条件が、LMS121によってチェックされる。ステップ150では、LMS121は、parentIDの値を<AE−3>のURIに更新するための要求をCSE109に送信する。ステップ151では、CSE109は、ステップ150の要求をチェックし、<subscription>のparentIDが<AE−3>のURIの値を有するように、更新動作を実行する。ステップ152では、<AE−3>が、変更された。ステップ153では、CSE109は、parentIDの現在の値が、以前のリンク管理動作に起因して、<AE−3>のURIに設定されているので、<AE−3>の変更に関してAE−1に通知する。
図26は、最初に、<AE−1>リソースが、CSE109において作成されており、いくつかのグループに追加されたことを示す。後に、アプリケーション要件に起因して、例えば、発信側123が、どのグループのメンバであることも所望しないが、しかしながら、それは、それが現在属するグループを把握していない。故に、それは、本件に関して要求をLMSに送信し得る。システム内の全リンクがLMSによって構成されると仮定すると、LMSは、全<group>リソースの「memberList」属性に関連する全リンクプロファイルに迅速に目を通し、次いで、<AE−1>のURIをそれらのグループから排除し得る。例えば、「memberList」属性の値内にそのようなURIを含むことに関連する任意のリンク構成は、関連リンクプロファイルから削除されるであろう。そうすることによって、<AE−1>は、もはやどのグループにも属さないであろう。これは、開示されるLMSによって有効にされる付加価値サービスであり得る。特に、AEは、LMSが、このAEが現在属するグループを回答し得るように、クエリ要求をLMSに送信することができる。
図26を継続して参照すると、ステップ161では、発信側123は、CSE109において<AE−1>リソースを作成することを決定する。ステップ162では、発信側123(AE−1)は、CSE109において<AE−1>リソースを作成するための要求を送信する。ステップ163では、CSE109は、発信側123からの要求の動作をチェックし、<AE−1>リソースを作成する。ステップ164では、<AE−1>が、必要とされるビジネスロジックに基づいて(AE−1に知らせずに)、他のエンティティによって多くの<group>リソースの「memberList」に追加される。ステップ165では、発信側123は、どのグループのメンバであることも所望しない(例えば、アプリケーション要件に基づいて)が、それ(発信側123)は、それが現在属するグループを把握していないと決定する。ステップ166では、発信側123は、発信側123に関連付けられた<AE−1>をグループから除去することにおける支援に対する要求をLMS121に送信する。ステップ167では、LMS121は、<AE−1>のURIが含まれる「memberList」属性に関連するリンクプロファイルに目を通して、<AE−1>のURIをそれらの関連「memberList」属性の全てから削除する。ステップ168では、LMS121は、発信側123(AE−1)にそれがどのグループにも存在しないことを示すメッセージを発信側123に送信し得る。本明細書では、用語「発信側」および「AE」は、同じ意味で使用され得ることに留意されたい。発信側は、アプリケーションがロードされたデバイスであり得る(例えば、AE−1)、またはAE−1であり得る。
図27は、本明細書で論じられる方法およびシステムに基づいて生成され得る、例示的ディスプレイ(例えば、グラフィカルユーザインターフェース)を図示する。ディスプレイインターフェース901(例えば、タッチスクリーンディスプレイ)は、リソースリンク管理(例えば、LMS)に関連付けられたブロック902において、表1から表4に示されるようなパラメータを表示またはクエリするために使用され得るテキストを提供し得る。別の実施例では、図12−図16または図24−図26に示されるような明細書で論じられるステップのいずれかの進捗度(例えば、送信されるメッセージまたはステップの成功)が、表示され得る。加えて、グラフィカル出力903が、ディスプレイインターフェース901上に表示され得る。グラフィカル出力903は、リソースリンク管理(例えば、LMS)、本明細書で論じられる任意の方法またはシステムの進捗度のグラフィカル出力等に関する、デバイスのトポロジであり得る。
図27を継続して参照すると、ブロック902のグラフィカルユーザインターフェース(GUI)は、LMSにおいて起動中のタスクのリアルタイムステータスのチェックを可能にする。典型的には、LMSにおいて起動中のタスクの多くは、種々のリンクプロファイル、SLMP、またはEHRにおいて定義された仕様に基づくので、ブロック902のGUIは、それらのファイルがリンク管理タスク内でどのように使用されているかを監視することを可能にするであろう。リンクプロファイルを例として挙げると、チェックすべき一連のリンクプロファイル(例えば、全リンク管理タスク内で最も頻繁に使用されたもの、またはリンク管理タスク内で最も頻繁に使用されていないものであり得る)が、存在し得る。代替として、特定のリンクプロファイルをチェックすることが所望される場合、特定のリンクプロファイルIDが、入力され得る。リンクプロファイルのためのそのようなGUI使用は、LMSに記憶する他のタイプのエンティティ、例えば、SLMPおよびEHRにも適用可能である。
本明細書に表出する請求項の範囲、解釈、または用途をいかようにも限定するわけではないが、本明細書に開示される実施例のうちの1つ以上のものの技術的効果は、リンクが管理される方法に対して調節を提供することである。リンク構成(および関連知能)は、特別なエンティティによって取り扱われるか、または記憶され得る。本明細書に開示される概念のうちの1つ以上のものの別の技術的効果は、従来の実装と比較して、CSEがparentID属性におけるリンク管理をサポートする場合、リソース階層がより柔軟な方法で編成され得るように、このCSEにおけるリソースが、次いで、リソースツリーを横断して移動させられることができる(例えば、異なるURI値をparentID属性に割り当てる)ことである。単なる例として、<container>リソースの「parentID」は、それらのAEが、必要に応じて、データを容易に共有および交換し得るように、異なるAEの1つ以上のURIを動的に割り当てられ得る。本明細書に開示されるLMSの別の技術的効果は、リソース(例えば、<subscription>リソース)が、定義された要件に基づいて、動的かつ選択的に、通知を2つ以上の受信側に送信し、したがって、新しい付加価値サービスを有効にすることができることである。
oneM2Mアーキテクチャが、本明細書で背景として説明され、後述される種々の概念を例証するために使用され得るが、本明細書に後述される概念の実装は、本開示の範囲内にとどまりながら、変動し得ることを理解されたい。当業者はまた、開示される概念が、前述のoneM2Mアーキテクチャを使用する実装に限定されず、むしろ、ETSI M2Mならびに他のM2Mシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステム内に実装され得ることを認識するであろう。
図28Aは、図8等の1つ以上の開示された実施例が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための構築ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT/WoTのコンポーネントならびにIoT/WoTサービス層等であり得る。
図28Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、Ethernet(登録商標)、ファイバ、ISDN、PLC等)または無線ネットワーク(例えば、WLAN、セルラー等)、あるいは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成ってもよい。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図28Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは、通常はM2Mゲートウェイの後ろにあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ14と、端末デバイス18とを含む。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じてM2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイデバイス14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20またはM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービスプラットフォーム22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2Mデバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図28Bを参照すると、フィールドドメイン内に例証されるM2Mサービス層22(例えば、サービス層104)は、M2Mアプリケーション20、M2Mゲートウェイデバイス14、ならびにM2M端末デバイス18および通信ネットワーク12のためのサービスを提供する。M2Mサービスプラットフォーム22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、1つ以上のサーバ、コンピュータ等によって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示したM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’がある。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および下層通信ネットワーク12’のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイデバイス14およびM2M端末デバイス18のためのサービスも提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス、およびM2M端末デバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによってサービス層と相互作用し得る。M2Mサービス層22’は、1つ以上のサーバ、コンピュータ、仮想マシン(例えば、クラウド/計算/記憶ファーム等)等によって実装され得る。
図28Bも参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアの組を提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
いくつかの実施例では、M2Mアプリケーション20および20’は、本明細書に論じられるように、リソースリンク管理(例えば、LMS)に関連付けられたメッセージを使用して通信する所望のアプリケーションを含み得る。M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
本願のリソースリンク管理(例えば、LMS)は、サービス層の一部として実装され得る。サービス層(例えば、サービス層104)は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。M2Mエンティティ(例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得る、デバイス、ゲートウェイ、またはサービス/プラットフォーム等のM2M機能的エンティティ)は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mは両方とも、本願のリソースリンク管理(例えば、LMS)を含み得る、サービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上でホストすることができる、共通サービスエンティティ(CSE)と称される。さらに、本願のリソースリンク管理(例えば、LMS)は、本願のリソースリンク管理(例えば、LMS)等のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装することができる。
図28Cは、例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14等の例示的M2Mデバイス30の系統図である。図28Cに示されるように、M2Mデバイス30は、プロセッサ32と、送受信機34と、伝送/受信要素36と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ/タッチパッド42と、非取り外し可能メモリ44と、取り外し可能メモリ46と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。M2Mデバイス30は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。M2Mデバイス30(例えば、M2Mゲートウェイ122、M2Mデバイス125、M2Mデバイス126、M2Mデバイス127、M2Mサーバ124、およびその他)は、リソースリンク管理(例えば、LMS)のための開示されるシステムおよび方法を実施する、例示的実装の一部であり得る。
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態マシン等であり得る。プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mデバイス30が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ32は、伝送/受信要素36に結合され得る、送受信機34に結合され得る。図28Cは、プロセッサ32および送受信機34を別個のコンポーネントとして描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/または無線アクセス層(RAN)プログラムおよび/または通信を実施し得る。プロセッサ32は、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー一致、および/または暗号化動作等のセキュリティ動作を実施し得る。
伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送するか、またはM2Mサービスプラットフォーム22から信号を受信するように構成され得る。例えば、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークおよびエアインターフェースをサポートし得る。実施例では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送および/または受信するように構成されるエミッタ/検出器であり得る。さらに別の実施例では、伝送/受信要素36は、RFおよび光信号の両方を伝送および受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図28Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、例えば、M2Mデバイス30は、無線信号を伝送および受信するための2つ以上の伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、加入者識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の実施例では、プロセッサ32は、サーバまたはホームコンピュータ上等のM2Mデバイス30上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ32は、本明細書に説明される実施例のうちのいくつかにおけるLMSが成功もしくは不成功(例えば、例外ハンドリング(EHR)、SLMP、もしくはリンクプロファイル提出等)であるかに応答して、ディスプレイまたはインジケータ42上の照明パターン、画像、または色を制御する、または別様に、リソースリンク管理(LMS)および関連付けられたコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ42上の照明パターン、画像、もしくは色の制御は、図に図示される、または本明細書で論じられる(例えば、図12−16および図24−図26等)、方法フローまたはコンポーネントのいずれかのステータスを反映し得る。
プロセッサ32は、電源48から電力を受け取り得、M2Mデバイス30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に電力供給するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含み得る。
プロセッサ32はまた、M2Mデバイス30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成されるGPSチップセット50に結合され得る。M2Mデバイス30は、本明細書に開示されるものと一致したままで、任意の好適な場所決定方法を介して場所情報を取得し得ることが理解されるであろう。
プロセッサ32はさらに、追加の特徴、機能性、および/または有線あるいは無線接続を提供する1つ以上のソフトウェアおよび/またはハードウェアモジュールを含み得る、他の周辺機器52に結合され得る。例えば、周辺機器52は、加速度計、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
図28Dは、例えば、図28Aおよび28BのM2Mサービスプラットフォーム22が実装され得る、例示的なコンピュータシステム90のブロック図である。コンピュータシステム90は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム90を稼働させるように、中央処理装置(CPU)91内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンでは、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たすか、またはCPU91を支援する、主要CPU91とは明確に異なる、随意的なプロセッサである。CPU91および/またはコプロセッサ81は、リンクプロファイルまたはEHRの受信等、リソースリンク管理(LMS)のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理し得る。
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送経路であるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス80の実施例は、PCI(周辺コンポーネント相互接続)バスである。
システムバス80に結合されるメモリデバイスは、ランダムアクセスメモリ(RAM)82および読み取り専用メモリ(ROM)93を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正することができない記憶されたデータを含む。RAM82に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られるか、または変更されることができる。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供し得る。したがって、第1のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピュータシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピュータシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。
さらに、コンピュータシステム90は、図28Aおよび28Bのネットワーク12等の外部通信ネットワークにコンピュータシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等のマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび/または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号自体を含まない。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CDROM、デジタル多用途ディスク(DVD)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。
図で図示されるような本開示の主題の好ましい実施例を説明する際に、明確にするために、特定のタームが採用される。しかしながら、請求された主題は、そのように選択された特定のタームに限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
本発明はさらに、例えば、以下を提供する。
(項目1)
リソースリンクを管理するデバイスであって、前記デバイスは、
プロセッサと、
前記プロセッサと結合されたメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
第1のリンクプロファイルを受信することであって、前記第1のリンクプロファイルは、第1のリソースのリンクの使用の構成を定義する命令を含み、前記第1のリソースの前記リンクは、第2のリソースに向けられている、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第1のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む動作を前記プロセッサに達成させる、デバイス。
(項目2)
前記リンクの使用を管理することは、時間に基づいてトリガされる、項目1に記載のデバイス。
(項目3)
前記動作は、ルールの組を受信することをさらに含み、前記ルールの組は、前記第1のリンクプロファイルおよび第2のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目1から2のいずれか1項に記載のデバイス。
(項目4)
前記動作は、前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目1から3のいずれか1項に記載のデバイス。
(項目5)
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも1つを含む、項目1から4のいずれか1項に記載のデバイス。
(項目6)
前記リンクは、ユニフォームリソース識別子である、項目1から5のいずれか1項に記載のデバイス。
(項目7)
前記リンクの使用を管理することは、前記第1のリソースに関連付けられたモバイルデバイスのコンテキスト情報に基づく、項目1から6のいずれか1項に記載のデバイス。
(項目8)
リソースリンク管理のための方法であって、前記方法は、
第1のリンクプロファイルを受信することであって、前記第1のリンクプロファイルは、第1のリソースのリンクの使用の構成を定義する命令を含む、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第1のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む、方法。
(項目9)
前記第1のリソースの前記リンクは、第2のリソースに向けられている、項目8に記載の方法。
(項目10)
ルールの組を受信することをさらに含み、前記ルールの組は、前記第1のリンクプロファイルおよび第2のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目8から9のいずれか1項に記載の方法。
(項目11)
前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目8から10のいずれか1項に記載の方法。
(項目12)
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも1つを含む、項目8から11のいずれか1項に記載の方法。
(項目13)
前記リンクは、ユニフォームリソース識別子である、項目8から12のいずれか1項に記載の方法。
(項目14)
前記リンクの使用を管理することは、前記第1のリソースに関連付けられたデバイスのコンテキスト情報に基づく、項目8から13のいずれか1項に記載の方法。
(項目15)
コンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピューティングデバイスによって実行されると、
第1のリンクプロファイルを受信することであって、前記第1のリンクプロファイルは、第1のリソースのリンクの使用の構成を定義する命令を含む、ことと、
前記リンクを管理するための要求を受信することと、
前記要求に応答して、前記第1のリンクプロファイルに基づいて、前記リンクの使用を管理することと
を含む動作を前記コンピューティングデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
(項目16)
前記第1のリソースの前記リンクは、第2のリソースに向けられている、項目15に記載のコンピュータ読み取り可能な記憶媒体。
(項目17)
前記動作は、ルールの組を受信することをさらに含み、前記ルールの組は、前記第1のリンクプロファイルおよび第2のリンクプロファイルに関連付けられたアクション間の衝突を解決するためのものである、項目15から16のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
(項目18)
前記動作は、前記ルールの組に基づいて、衝突を自動的に解決することをさらに含む、項目15から17のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
(項目19)
前記リンクを管理することは、前記リンクを削除することまたは前記リンクを更新することのうちの少なくとも1つを含む、項目15から18のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
(項目20)
前記リンクの使用を管理することは、前記第1のリソースに関連付けられたデバイスのコンテキスト情報に基づく、項目15から19のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。