JP2017533523A - マシンツーマシンシステムにおけるアプリケーション関係の管理 - Google Patents

Abstract

アプリケーション関係が、アプリケーション関係を作成すること、アプリケーション関係を更新すること、アプリケーション関係を読み出すこと、アプリケーション関係を削除すること、またはアプリケーション関係を発見すること等のサービス層において分類および管理され得る。サービスは、アプリケーション関係認識に基づき得る。一実施形態において、関係は、グラフィカルユーザインターフェース上に表示される。さらに、一実施形態において、関係は、第１のリソース内の第１のアプリケーション関係属性を更新することを含む。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０７３，５８２号（２０１４年１０月３１日出願、名称「ＭＡＮＡＧＩＮＧ ＡＰＰＬＩＣＡＴＩＯＮ ＲＥＬＡＴＩＯＮＳＨＩＰＳ ＩＮ ＭＡＣＨＩＮＥ−ＴＯ−ＭＡＣＨＩＮＥ ＳＹＳＴＥＭＳ」）に対する優先権を主張し、上記出願は、その全体が参照により本明細書に引用される。

ＯｎｅＭ２Ｍ機能的アーキテクチャベースライン（参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１−Ｖ−２０１４−０８）は、とりわけ、コネクテッドカーまたはスマートヘルス等の異なるマシンツーマシン（Ｍ２Ｍ）アプリケーションをサポートするために、種々のハードウェアおよびソフトウェア内に容易に組み込まれることができる共通サービス層（ＣＳＬ）を規定する。ＣＳＬとしてのｏｎｅＭ２Ｍは、共通サービス機能（ＣＳＦ）（例えば、登録ＣＳＦ）の組を定義する。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、または特定用途向けノード）上でホストされることができる共通サービスエンティティ（ＣＳＥ）と称される。

図１は、ｏｎｅＭ２Ｍ機能的アーキテクチャを図示する。アプリケーションエンティティ（ＡＥ）１０１またはＡＥ１０３は、それぞれ、インフラストラクチャドメイン１０７もしくはフィールドドメイン１０５内に常駐し得る異なるＭ２Ｍアプリケーションを指す。ｏｎｅＭ２Ｍ−ＴＳ−００１１−Ｄｅｆｉｎｉｔｉｏｎｓ ａｎｄ Ａｃｒｏｎｙｍｓ−Ｖ０．７．０によると、フィールドドメイン１０７が、「Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、感知および作動（Ｓ＆Ａ）機器、ならびにＭ２Ｍエリアネットワークから成る」一方で、インフラストラクチャドメイン１０５は、「アプリケーションインフラストラクチャおよびＭ２Ｍサービスインフラストラクチャから成る」。ＡＥ１０１は、Ｍｃａインターフェース１０８を介してＣＳＥ１０９内のＣＳＦにアクセスし、それを利用することができる。加えて、ＣＳＥ１０９は、一式のＣＳＦを提供し、ＣＳＥ１０９は、Ｍｃｃインターフェース１１０を介して別のＣＳＥ１１１と通信することができる。ＣＳＥ１０９は、Ｍｃｎインターフェース１１２を介して下層ネットワークからのネットワークサービスエンティティ（ＮＳＥ）１１３を利用することもできる。

ｏｎｅＭ２Ｍ機能的アーキテクチャベースラインによると、ｏｎｅＭ２Ｍ基準点は、Ｍｃａ１０８、Ｍｃｃ１１０、Ｍｃｃ’１１４、およびＭｃｎ１１２を含む。Ｍｃａ基準点１０８（Ｍｃａインターフェースとしても公知である）は、ＡＥ（例えば、ＡＥ１０１）とＣＳＥ（例えば、ＣＳＥ１０９）との間の通信フローを指定する。Ｍｃａ基準点１０８は、ＡＥ１０１がＣＳＥ１０９によって提供されるサービスを使用し、ＣＳＥ１０９がＡＥ１０１と通信することを可能にする。Ｍｃｃ基準点１１０は、２つのＣＳＥ（例えば、ＣＳＥ１０９およびＣＳＥ１１１）間の通信フローを指定する。Ｍｃｃ基準点１１０は、必要機能性を提供するために、ＣＳＥ１０９がＣＳＥ１１１のサービスを使用することを可能にする。Ｍｃｃ基準点１１０を介して提供されるサービスは、ＣＳＥ１０９およびＣＳＥ１１１によってサポートされる機能性に依存している。

Ｍｃｃ’基準点１１４は、ｏｎｅＭ２Ｍに準拠し、かつ異なるＭ２Ｍ ＳＰドメイン内に常駐するインフラストラクチャノード内の２つのＣＳＥの間の通信フローを指定する。したがって、それは、Ｍ２Ｍサービスプロバイダのネットワークドメイン内に常駐するインフラストラクチャノード１０５のＣＳＥ１１１が、そのサービスを使用するために、別のＭ２Ｍサービスプロバイダ１１５のネットワークドメイン内に常駐する別のインフラストラクチャノード（図示せず）のＣＳＥと通信すること、および逆も同様に可能にする。Ｍｃｎ基準点１１２は、ＣＳＥ１０９と下層ＮＳＥ１１３との間の通信フローを指定する。Ｍｃｎ基準点１１２は、必要機能性を提供するために、ＣＳＥ１０９が下層ＮＳＥ１１３によって提供される（トランスポートおよびコネクティビティサービス以外の）サービスを使用することを可能にする。

登録（ＲＥＧ）ＣＳＦ、アプリケーションおよびサービス層管理（ＡＳＭ）ＣＳＦ、デバイス管理（ＤＭ）ＣＳＦ、データ管理およびレポジトリ（ＤＭＲ）ＣＳＦ、通信およびメッセージ配信処理（ＣＭＤＨ）ＣＳＦ、サービス課金および会計（ＳＣＡ）ＣＳＦ等を含むいくつかの共通サービス機能（ＣＳＦ）が、ｏｎｅＭ２Ｍ機能的アーキテクチャベースラインの中でＣＳＥ１０９またはＣＳＥ１１１内で定義されている。例えば、ＣＳＥ（例えば、Ｍ２Ｍサービス層エンティティ）は、ＣＳＥによって提供される他のＣＳＦを利用するために、ＡＥが最初にそれ自体をＣＳＥに登録することができるように、ＲＥＧ ＣＳＦを提供する。このアーキテクチャは、複数のＡＥが同一のＣＳＥに独立して登録することを可能にする。登録が成功した後、ＣＳＥは、各ＡＥのための別個のリソース（例えば、＜ａｐｐｌｉｃａｔｉｏｎ＞リソース）を作成する。従来のｏｎｅＭ２Ｍ機能的アーキテクチャベースラインは、異なるアプリケーション間の関係をサポートする機能を欠いている。

従来のｏｎｅＭ２Ｍアーキテクチャは、異なるＭ２Ｍアプリケーション（例えば、ＡＥ）間のリソースアクセスおよびメッセージをサポートする。このアーキテクチャは、複数のＡＥが同一のＣＳＥに登録することを可能にするが、各ＡＥは、独立してＣＳＥへのアプリケーション登録を行う。従来のＭ２Ｍ／ＩｏＴサービス層（例えば、ｏｎｅＭ２Ｍ機能的アーキテクチャベースライン、ｏｎｅＭ２Ｍ−ＴＳ−０００１−Ｖ−２０１４−０８）は、異なるアプリケーション間の関係を効率的にサポートし、利用する機能を欠いている。本明細書では、Ｍ２ＭまたはＩｏＴサービス層内でアプリケーション関係（例えば、親／子）を利用する方法が開示される。

本明細書では、アプリケーション関係を作成すること、アプリケーション関係を更新すること、アプリケーション関係を読み出すこと、アプリケーション関係を削除すること、またはアプリケーション関係を発見すること等のサービス層における共通サービスとしてのアプリケーション関係分類およびアプリケーション関係管理が議論される。サービスは、アプリケーション関係認識に基づき得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することも、請求された主題の範囲を限定するために使用されることも意図していない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

図１は、例示的ｏｎｅＭ２Ｍ機能的アーキテクチャを図示する。 図２は、例示的なジム使用事例を図示する。 図３は、例示的な環境監視使用事例を図示する。 図４Ａは、例示的親／子アプリケーション関係を図示する。 図４Ｂは、例示的複合／入力アプリケーション関係を図示する。 図５Ａは、例示的アプリケーション関係記録リソースを図示する。 図５Ｂは、例示的アプリケーション関係記録リソースを図示する。 図６は、アプリケーション関係を作成する例示的方法を図示する。 図７は、例示的親／子アプリケーション関係作成を図示する。 図８は、既存の登録されたアプリケーション間のアプリケーション関係を読み出すための例示的方法を図示する。 図９は、既存の登録されたアプリケーション間のアプリケーション関係を更新する例示的方法を図示する。 図１０は、既存の登録されたアプリケーション間のアプリケーション関係を削除する例示的方法を図示する。 図１１は、既存の登録されたアプリケーション間のアプリケーション関係を発見する例示的方法を図示する。 図１２は、例示的親／子アプリケーション登録プロセスを図示する。 図１３は、例示的親／子アプリケーション登録プロセスを図示する。 図１４は、複合／入力アプリケーション登録のための例示的方法を図示する。 図１５は、親／子アプリケーション登録解除のための例示的方法を図示する。 図１６は、複合／入力アプリケーション登録解除のための例示的方法を図示する。 図１７は、親／子アプリケーション発表のための例示的方法を図示する。 図１８は、関係認識親／子アプリケーションソフトウェア管理のための例示的方法を図示する。 図１９は、関係認識複合／入力アプリケーションソフトウェア管理のための例示的方法を図示する。 図２０は、関係認識アプリケーション発見のための例示的方法を図示する。 図２１は、アプリケーション関係の加入および通知のための例示的方法を図示する。 図２２は、ＣＳＦとしてアプリケーション関係管理（ＡＲＭ）を図示する。 図２３は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞リソースの構造を図示する。 図２４は、＜ａｐｐｌｉｃａｔｉｏｎ＞リソースの構造を図示する。 図２５は、＜ａｐｐｌｉｃａｔｉｏｎ＞リソースの構造を図示する。 図２６は、例示的グラフィカルユーザインターフェースを図示する。 図２７Ａは、１つ以上の開示された実施例が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）もしくはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２７Ｂは、図２７Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２７Ｃは、図２７Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２７Ｄは、図２７Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

従来のｏｎｅＭ２Ｍアーキテクチャは、それらの不可欠な機能性を含む種々のＣＳＦを定義すること、およびそれらが他のＣＳＥまたはＡＥによって実装され、利用される方法に焦点を合わせる。従来のｏｎｅＭ２Ｍアーキテクチャはまた、異なるＭ２Ｍアプリケーション（例えば、ＡＥ）間のリソースアクセスおよびメッセージ交換もサポートする。このアーキテクチャは、複数のＡＥが同一のＣＳＥに登録することを可能にするが、各ＡＥは、独立してＣＳＥへのアプリケーション登録を行う。従来のＭ２Ｍ／ＩｏＴサービス層（例えば、ｏｎｅＭ２Ｍ機能的アーキテクチャベースライン、ｏｎｅＭ２Ｍ−ＴＳ−０００１−Ｖ−２０１４−０８）は、異なるアプリケーション間の関係を効率的にサポートし、かつそれを利用する機能を欠いている。本明細書では、Ｍ２ＭまたはＩｏＴサービス層（以降では「Ｍ２Ｍサービス層」）においてアプリケーション関係（例えば、親／子）を利用する方法が開示される。

Ｍ２Ｍ使用事例は、スマートトランスポーテーション、スマートホーム、スマートヘルス、スマートグリッド、スマートシティ等を含み得る。各使用事例は、（例えば、Ｍ２Ｍアプリケーションサーバ内の）インフラストラクチャドメインおよび（例えば、Ｍ２Ｍデバイス内の）フィールドドメインの両方において複数の関連アプリケーションを生成し得る。これらのＭ２Ｍアプリケーションは、異なるバーティカルドメインからのアプリケーションに対してさえも、完全には互いから独立していない。以下で説明されるジム使用事例および環境監視事例は、関係が異なるＭ２Ｍアプリケーション間に存在し得ることを実証する。

図２は、親／子関係があり得る、顧客のモバイルデバイス上に３つのアプリケーションがあるジム使用事例を図示する。ＡＥ１３４は、モバイルデバイス１３２とタブレット１３７（例えば、コーチ）との間のトレーニングアプリケーションである。ＡＥ１３３は、モバイルデバイス１３２とトレッドミル１３６との間のトレッドミルアプリケーションである。ＡＥ１３５は、モバイルデバイス１３２と自転車１３８との間の自転車アプリケーションである。ＡＥ１３３、ＡＥ１３４、およびＡＥ１３５は、それら自体をジムゲートウェイ１３１（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）に登録する。ＡＥ１３４は、タブレット１３７からトレーニング計画にアクセスするために使用される。そして、顧客は、ＡＥ１３４によって提供されるようなトレーニングプログラムで指定される機器（例えば、トレッドミル１３６および自転車１３８）との相互作用のために、ＡＥ１３３またはＡＥ１３５を使用する。例えば、顧客は、ＡＥ１３３を介してトレッドミル１３６を動的に減速または加速するコマンドを送信することができる。この例では、ＡＥ１３４は、情報（例えば、トレーニングプログラム）をＡＥ１３３およびＡＥ１３５に提供する、親アプリケーションと見なされ得る。ＡＥ１３３およびＡＥ１３５は、子アプリケーションと見なされ得、両方とも、フィードバックとしてトレーニング結果をＡＥ１３４に提供し得る。加えて、ＡＥ１３４は、ＡＥ１３３またはＡＥ１３５の動作を制御するためのアクセス権、およびオーバーライドさえするためのアクセス権を有し得る。

図３は、複合／入力関係の例を含む環境監視のための使用事例を図示する。図３では、いくつかのタイプのセンサ（例えば、湿度センサ１４５、煙センサ１４２、温度センサ１４４、および風センサ１４３）が、物理的領域１４１内に展開される。センサは、異なる密度で異なる場所に配置され得る。各センサは、それ自体をセンサアプリケーションとしてＭ２Ｍゲートウェイ１４９に登録する。センサは、Ｍ２Ｍゲートウェイ１４９を通してインターネットからアクセスされ得る。

図３を続けて参照すると、１つの展開では、Ｍ２Ｍゲートウェイ１４９は、異なる目的のために２つのゲートウェイアプリケーション（例えば、ＡＥ１４７およびＡＥ１４８）をインストールするが、両方ともセンサアプリケーションに依存し得る。例えば、ＡＥ１４７は、気象予測のために、湿度センサ１４５の湿度センサアプリケーションおよび温度センサ１４４の温度センサアプリケーションの組み合わせを利用し得る。一方で、ＡＥ１４８は、火災予測のために、温度センサ１４４の温度センサアプリケーション、煙センサ１４２の煙センサアプリケーション、および風センサ１４３の風センサアプリケーションの組み合わせを利用し得る。センサアプリケーションは、出力を生成するためにゲートウェイアプリケーション（複合アプリケーション）が依存する入力である。個々のセンサアプリケーションは、インターネットから他のネットワークアプリケーションによって利用され得る。

従来のＭ２Ｍサービス層（例えば、ＯｎｅＭ２Ｍ機能的アーキテクチャベースライン、ｏｎｅＭ２Ｍ−ＴＳ−０００１−Ｖ−２０１４−０８）は、異なるアプリケーション間の関係を効率的にサポートし、かつそれを利用する機能を欠いている。従来のｏｎｅＭ２Ｍでは、Ｍ２Ｍアプリケーション（例えば、ＡＥ）は、単純に、Ｍｃａインターフェースを介して、独立してサービスプラットフォーム（例えば、ＣＳＥ）に登録し、ＭｃａまたはＭｃａ／Ｍｃｃ／Ｍｃａインターフェースの組み合わせを介して、他のＭ２Ｍアプリケーションと通信する。Ｍ２Ｍアプリケーション間の依存性または関係は、ｏｎｅＭ２Ｍアーキテクチャにおけるアプリケーション登録または他のアプリケーション関連プロシージャ（例えば、アプリケーション加入）ではサポートされない。

従来のＭ２Ｍサービス層におけるアプリケーション関係無認識は、複数の欠点を有し得る。第１に、継承されるかまたは要求されるアプリケーション関係を伴う使用事例（例えば、図２のジム使用事例）をサポートするために、従来のＭ２Ｍサービス層は、対応するサービスを提供せず、アプリケーションレベルでそれに対処するようにアプリケーション自体に頼り、それは、アプリケーションの負担（例えば、増加したアプリケーション開発複雑性および減少したソフトウェア再利用可能性）を増加させ得る。第２に、従来のＭ２Ｍサービス層に対して、アプリケーション関係の動的変化は、アプリケーション自体によって効率的にサポートされない場合がある。

本明細書で開示されるように、Ｍ２Ｍサービス層における共通サービス（例えば、ｏｎｅＭ２Ｍにおける登録サービス）は、異なるアプリケーションの関係が管理されるとき、強化され得る（例えば、メッセージオーバーヘッドの低減）。アプリケーション関係管理は、とりわけ、アプリケーション関係を作成すること、アプリケーション関係を更新すること、アプリケーション関係を読み出すこと、アプリケーション関係を削除すること、またはアプリケーション関係を発見することを行う共通サービス層機能を必要とし得る。

図４Ａは、例示的親／子関係を図示する。子アプリケーションとしてのＡＥ１５２およびＡＥ１５３は、親アプリケーションＡＥ１５１の一部である。ＡＥ１５１は、ＡＥ１５２およびＡＥ１５３への実質的なアクセスならびにそれらの制御を有し得る。子アプリケーションＡＥ１５２およびＡＥ１５３の登録は、親アプリケーションＡＥ１５１の成功した登録に依拠し得る。ＡＥ１５１は、ＡＥ１５２およびＡＥ１５３の前に登録または起動され得る。代替として、親／子関係は、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３が独立して登録した後に確立され得る。例えば、ＡＥ１５２およびＡＥ１５３は、たとえ親アプリケーションＡＥ１５１がまだ登録されていなくても登録することを許可され得るが、ＡＥ１５２およびＡＥ１５３のある機能性（例えば、アクセス権）は、適用可能ではない場合、または有効にされない場合がある。ＡＥ１５１が登録すると、ＡＥ１５２およびＡＥ１５３は、ＡＥ１５１を発見し、ＡＥ１５１は、ＡＥ１５２およびＡＥ１５３との関係を確立し得る。したがって、そして、無効にされた機能性が有効にされ得る。一方、子アプリケーションＡＥ１５２およびＡＥ１５３は、親アプリケーションＡＥ１５１が削除または登録解除されると、自動的に除去され得る。親アプリケーションＡＥ１５１ならびに子アプリケーションＡＥ１５２およびＡＥ１５３は両方とも、同一のローカルサービス層インスタンスに登録し得るが、同一の物理的Ｍ２Ｍデバイス、ゲートウェイ、またはサーバ上に常駐する場合も、常駐しない場合もある。要約すると、親アプリケーションＡＥ１５１は、子アプリケーションＡＥ１５２およびＡＥ１５３を実質的に制御し得、ＡＥ１５２およびＡＥ１５３は、ＡＥ１５１に依拠し、ＡＥ１５１にサービス提供し得る。本明細書では、親アプリケーションが任意の数の子アプリケーションを有し得ることが想定される。

図４Ｂは、例示的複合／入力関係を図示する。ＡＥ１５６は、入力アプリケーションと称されるＡＥ１５４およびＡＥ１５５上に構築される。ＡＥ１５６は、入力またはリソースのためにＡＥ１５４およびＡＥ１５５に依拠するが、それらに対して実質的な制御を有していない。ＡＥ１５６は、複合アプリケーションと称され得る。例えば、複合アプリケーションＡＥ１５６は、入力アプリケーションＡＥ１５４およびＡＥ１５５のリソースにアクセスし得るが、ＡＥ１５６の除去または登録解除は、ＡＥ１５４もしくはＡＥ１５５の自動削除につながらない場合がある。しかしながら、ＡＥ１５４またはＡＥ１５５の除去もしくは登録解除は、複合アプリケーションＡＥ１５６に影響を及ぼす。概して、複合アプリケーションは、複数の入力アプリケーションを有し得、複合アプリケーションは、別の複合アプリケーションへの入力アプリケーションであり得る。

図５Ａおよび図５Ｂは、アプリケーションリソースおよび対応する関係を記述し、リンクするためのアプローチを図示する。図５Ａは、リンクするための特別なアプリケーション関係記録リソースを用いるアプローチを図示する。図５Ａに示されるように、各アプリケーション関係は、アプリケーション関係管理（ＡＲＭ）機能によって記録されるアプリケーション関係として作成および捕捉され得る。本明細書でさらに詳細に開示されるように、ＡＲＭは、アプリケーション関係記録を記憶するための特別なデータベースを維持する。そして、アプリケーションが、他のアプリケーションとのその関係を記述する対応する関係記録にリンクするために、新しい属性（例えば、リンキング）が導入される。アプリケーション関係記録データベースが、ＡＲＭによってサービス層において維持される。データベースは、異なるアプリケーションによってアクセスまたは利用されることができる一般的機能である。ＡＲＭは、アクセスされ得る記録、またはアプリケーションと共有され得る記録の制御を有し得る。例えば、アプリケーションは、それ自体をサービス層に登録した後、他のアプリケーションに関する特定のアプリケーション関係記録に対してデータベースを検索することができる。別の実施例では、アプリケーションは、別のアプリケーションとのその関係を示すための新しいアプリケーション関係記録を追加することによって、データベースを更新し得る。

図５Ｂは、特別なアプリケーション関係記録リソースを用いないアプローチを図示する。各アプリケーション関係は、対応するアプリケーションリソースに添付される追加情報または属性として作成される。例えば、アプリケーション関係は、ｏｎｅＭ２Ｍアーキテクチャとの関連において、新しい属性を＜ａｐｐｌｉｃａｔｉｏｎ＞リソースに追加することによって、記述されることができる。このアプローチでは、ＡＲＭは、図５Ａのアプローチ１のようにいかなる関係記録も維持する必要がない。

図５Ｂのアプローチを続けて参照すると、随意に、既存のアプリケーションリソース（例えば、ｏｎｅＭ２Ｍにおける＜ａｐｐｌｉｃａｔｉｏｎ＞）が、別のアプリケーションリソース（例えば、ｏｎｅＭ２Ｍにおける別の＜ａｐｐｌｉｃａｔｉｏｎ＞）のサブリソースとして追加され、アプリケーションリソースの階層構造を形成することができ、それがアプリケーション関係を示唆し、アプリケーション関係を明示的に示すために新しい属性を必要としないこともある。アプリケーションは、そのサブリソース（例えば、子アプリケーション）として、その親アプリケーションを追加することを制限され得ることに留意されたい。この制限を達成するために、アプリケーションは、追加される新しいサブリソース（例えば、子アプリケーション）が階層構造上に出現していないことを保証するために、階層構造全体をチェックすることができる。階層構造の深度は、潜在的ループ関係を回避するために限定され得ることに留意されたい。

アプリケーション関係記録に対して、サービス層（例えば、ＡＲＭサービス）は、アプリケーション関係記録を維持する責任があり得る。アプリケーション関係記録は、随意に、アプリケーションリソースのサブリソースまたは属性として追加され得る。表１に示されるように、各アプリケーション関係記録は、とりわけ、アプリケーション関係記録識別子（ＡＲＲＩ）フィールド、アプリケーション関係タイプフィールド、アプリケーションのリストフィールド、主要アプリケーションフィールド、関係存続期間フィールド、または許可されたエンティティのリストフィールド等のフィールドを含み得る。ＡＲＲＩは、各アプリケーション関係記録の識別子である。それは、記録が記憶され、アクセスされることができる場所を示すユニバーサルリソース識別子（ＵＲＩ）であり得る。アプリケーション関係に関与するアプリケーションは、それの属性として１つ以上のＡＲＲＩを追加することができ、それによって、アプリケーションについての全てのアプリケーション関係は、ＡＲＲＩに基づいて読み出され得る。

表１は、アプリケーション関係記録に使用され得る、異なるフィールドを示す。アプリケーション関係タイプフィールドは、アプリケーション関係のタイプ（例えば、親／子関係または複合／入力関係）を示す。このパラメータは、他の関係タイプを対象とするように拡張され得る。アプリケーションのリストフィールドは、直接関係している全てのアプリケーションの名称、標識、または識別子を示す。識別子は、ＵＲＩの形態であり得る。主要アプリケーションフィールドは、親／子関係のための親アプリケーションまたは複合／入力関係のための複合アプリケーションの名称、標識、もしくは識別子を示す。関係存続期間フィールドは、アプリケーション関係の存続期間を示す。許可されたエンティティのリストフィールド（表１では明示的に示されていない）は、アプリケーション関係記録にアクセスすることを許可されるアプリケーションまたは他のＭ２Ｍエンティティ（例えば、Ｍ２Ｍ／ＩｏＴサーバ、ゲートウェイ、デバイス等）のリストである。ＡＲＭサービスは、アプリケーション関係記録データベース全体に１つの「許可されたエンティティのリスト」を使用し得る。

表１は、図４Ａおよび図４Ｂによる、２つの例示的アプリケーション関係記録を示す。図４Ａと対応する表１の第１の記録は、＜ＵＲＩ１＞を介してアクセスされ得る。このアプリケーション関係では、ＡＥ１５１が、親アプリケーションである一方で、ＡＥ１５２およびＡＥ１５３は、子アプリケーションである。図４Ｂに対応する表１の第２の記録は、＜ＵＲＩ２＞を介してアクセスされ得る。このアプリケーション関係では、ＡＥ１５６が、複合アプリケーションである一方で、ＡＥ１５４およびＡＥ１５５は、入力アプリケーションである。

アプリケーション関係属性（ＡＲＡ）は、アプリケーションが他のアプリケーションと有し得る関係を記述するために定義され得る。ＡＲＡは、各アプリケーションリソース（例えば、図２４および図２５に示されるようなｏｎｅＭ２Ｍにおける＜ａｐｐｌｉｃａｔｉｏｎ＞）のための属性として追加され得、次に、各属性は、それを通してアクセスされ得るアドレス（例えば、ＵＲＩ）を有し得る。例えば、ＡＲＡは、ｐａｒｅｎｔＡｐｐ、ｃｈｉｌｄＡｐｐ、ｓｉｂｌｉｎｇＡｐｐ、ｉｎｐｕｔＡｐｐ、ｃｏｍｐｏｓｉｔｅＡｐｐ、またはｒｅｌａｔｉｏｎｓｈｉｐＬｉｆｅｔｉｍｅを含み得る。ｐａｒｅｎｔＡｐｐは、親アプリケーション名称または識別子のリストであり得、ｃｈｉｌｄＡｐｐは、子アプリケーション名称または識別子のリストであり得、ｓｉｂｌｉｎｇＡｐｐは、兄弟アプリケーション名称または識別子のリストであり得、ｉｎｐｕｔＡｐｐは、入力アプリケーション名称または識別子のリストであり得、ｃｏｍｐｏｓｉｔｅＡｐｐは、複合アプリケーション名称または識別子のリストであり得、ｒｅｌａｔｉｏｎｓｈｉｐＬｉｆｅｔｉｍｅは、各存続期間が個別アプリケーション関係のためのものである、存続期間情報のリストであり得る。

Ｍ２Ｍアプリケーションがそれら自体をサービス層（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）に登録するので、サービス層は、アプリケーション関係を管理するために使用され得る。アプリケーション関係管理（ＡＲＭ）サービスは、既存のアプリケーションまたは新たに登録されたアプリケーション間の関係を管理するために、一般的動作を行うことを促進するＭ２Ｍサービス層における新しい共通サービスと見なされ得る。動作は、新しいアプリケーション関係を作成すること、既存のアプリケーション関係を読み出すこと、既存のアプリケーション関係を更新すること、既存のアプリケーション関係を削除すること、および既存のアプリケーション関係の発見を含み得る。ＡＲＭサービスは、アプリケーション関係に関連してはいるが、サポートし得、かつ種々のアプリケーションによって使用され得る一般的機能を提供し得る。なぜなら、ＡＲＭサービスは、１）本明細書に開示されるタイプのアプリケーション関係が十分に一般的であり（異なるアプリケーション特定ではない）、２）前述の一般的ＡＲＭ動作が特定のアプリケーションに依存せず、同様に一般的であるからである。

一般的動作は、新しいアプリケーション関係を作成することを伴い得る。例えば、Ｍ２Ｍ／ＩｏＴサーバ（以降ではＭ２Ｍサーバ）は、Ｍ２Ｍサーバに登録された２つ以上のアプリケーションのために、親／子もしくは複合／入力関係を作成することに役立ち得る。したがって、新しいアプリケーション関係記録が、図５Ａのアプローチに従って、Ｍ２Ｍサーバによって維持されるアプリケーション関係記録データベースの中へ追加されるか、または新しい属性／リンクが、図５Ｂのアプローチに従って、他の関与するアプリケーションのために作成されるであろう。これらのプロセスは、既存のアプリケーション関係を読み出すこと、更新すること、削除すること、および発見することを行うために使用され得る。

図６−図２１に、および全体を通して図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等のデバイス、ゲートウェイ、サーバ、もしくはコンピュータシステムのメモリに記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることが本明細書で想定される。換言すると、図６−図２１に、および全体を通して図示される方法は、図２７Ｃまたは図２７Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリに記憶される、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図６−図２１等に図示される任意のステップを行う。

図６は、一組の既存の登録されたアプリケーション間のアプリケーション関係を作成する例示的方法を図示する。ステップ１７４では、要求側１７１（例えば、ｏｎｅＭ２Ｍ ＡＥまたはｏｎｅＭ２Ｍ ＣＳＥ）が、アプリケーション関係を作成するための要求（例えば、アプリケーション関係作成要求）をサービス層１７２（例えば、ＡＲＭサービスを伴うｏｎｅＭ２Ｍ ＣＳＥ）に送信する。ステップ１７４の要求は、アプリケーション関係タイプ、サービス層１７２に登録されるアプリケーションのリスト、主要アプリケーション、または関係存続期間に関するＡＲＡを備え得る。ステップ１７５では、ステップ１７４で受信される情報に基づいて、サービス層１７２は、対応するアプリケーション関係リソースを作成し得る。アプリケーション関係リソースは、表１に図示されるようなアプリケーション関係記録であり得る。代替として、ステップ１７４に関して列挙されるもの等の対応するＡＲＡが、各関与するアプリケーションに追加され得る。ステップ１７６では、サービス層１７２が、応答を要求側１７１に返信し得る。このメッセージは、作成されたアプリケーションリソース（例えば、アプリケーション関係記録またはＡＲＡ）の識別子（例えば、そのＵＲＩ）を含み得る。ステップ１７７では、サービス層１７２が、通知をステップ１７４のアプリケーションのリスト上の他のアプリケーションに送信する。

図７は、親／子アプリケーション関係を作成する例示的方法を図示する。同様に図４Ａに図示されるように、ＡＥ１５１が親アプリケーションである一方で、ＡＥ１５２およびＡＥ１５３は、子アプリケーションである。ステップ１８４では、ＡＥ１５１が、サービス層１７２（例えば、ｏｎｅＭ２Ｍ ＣＳＥ−ＡＲＭサービス）に登録する。ステップ１８５では、サービス層１７２が、ＡＥ１５１のためのリソースを作成する。ステップ１８６では、ＡＥ１５２が、サービス層１７２に登録する。ステップ１８７では、サービス層１７２が、ＡＥ１５２のためのリソースを作成する。ステップ１８８では、ＡＥ１５３が、サービス層１７２に登録する。ステップ１８９では、サービス層１７２が、ＡＥ１５３のためのリソースを作成する。ｏｎｅＭ２Ｍのための従来のアプリケーション登録プロシージャが、ステップ１８４からステップ１８９に利用され得る。

ステップ１９０では、要求側１７１が、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の親／子関係を作成または更新するためのプリケーション関係作成要求メッセージをサービス層１７２に送信する。要求側１７１は、ＡＥ１５１、ＡＥ１５２、ＡＥ１５３、別のアプリケーション、または別のサービス層１７２エンティティ（例えば、別のＣＳＥ）であり得る。同じサービス層１７２も、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の親／子関係を確立するためにトリガし得、この場合、ステップ１９０は、省略され得る。アプリケーション関係作成要求メッセージは、以下の情報を含み得る：ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の関係；ステップ１８５、ステップ１８７、およびステップ１８９においてそれぞれ作成される、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３のためのリソースへのリンク；および、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の名称、標識、または識別子。ステップ１９１では、サービス層１７２が、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３アプリケーションの間の親／子関係を確立するために、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３のためのリソースを更新し得る。ＡＥ１５１のリソースは、ＡＥ１５２およびＡＥ１５３のためのリソースに接続する子ポインタまたはリンクを追加され得る。ＡＥ１５２（またはＡＥ１５３）のリソースは、ＡＥ１５１のためのリソースに接続する親ポインタまたはリンクを追加され得る。子ポインタまたはリンクは、ＡＥ１５１のリソースの新しい属性もしくはサブリソースとなり、その値は、ＡＥ１５２およびＡＥ１５３のためのリソースのＵＲＩである。同様に、追加された親ポインタまたはリンクは、ＡＥ１５２（またはＡＥ１５３）のリソースの新しい属性もしくはサブリソースとなり、その値は、ＡＥ１５１のためのリソースのＵＲＩである。ＡＥ１５２（またはＡＥ１５３）のリソースは、ＡＥ１５３（またはＡＥ１５２）のためのリソースに接続する兄弟ポインタもしくはリンクを追加され得る。この兄弟ポインタまたはリンクは、ＡＥ１５２およびＡＥ１５３がアプリケーション関係に関与し、同一の親アプリケーションを有することを示すために使用され得る。新しい属性またはサブリソースとしてＡＥ１５２のリソースに追加される兄弟ポインタもしくはリンクは、ＡＥ１５３のリソースのＵＲＩの値を有する。新しい属性またはサブリソースとしてＡＥ１５３のリソースに追加される兄弟ポインタもしくはリンクは、ＡＥ１５２のリソースのＵＲＩの値を有する。

ステップ１９２では、サービス層１７２が、ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の親／子関係の成功した作成を通知するための応答を要求側１７１に返信し得る。ステップ１９３では、サービス層１７２が、アプリケーション関係通知をＡＥ１５１に送信する。ステップ１９３のアプリケーション関係通知は、以下の情報を有し得る：ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の関係；ステップ１８７およびステップ１８９においてそれぞれ作成されたＡＥ１５２およびＡＥ１５３のためのリソースへのリンク；または、ＡＥ１５２およびＡＥ１５３の名称、標識、もしくは識別子。ステップ１９４では、サービス層１７２が、アプリケーション関係通知をＡＥ１５２に送信し得る。ステップ１９４のアプリケーション関係通知は、以下の情報を含み得る：ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の関係；ステップ１８５およびステップ１８９においてそれぞれ作成されたＡＥ１５１およびＡＥ１５３のためのリソースへのリンク；または、ＡＥ１５１およびＡＥ１５３の名称、標識、もしくは識別子。ステップ１９５では、サービス層１７２が、アプリケーション関係通知をＡＥ１５３に送信し得る。このメッセージは、以下の情報を含み得る：ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３の間の関係；ステップ１８５およびステップ１８７においてそれぞれ作成されたＡＥ１５１およびＡＥ１５２のためのリソースへのリンク；または、ＡＥ１５１およびＡＥ１５２の名称、標識、もしくは識別子。

図７に示されるものに類似するプロシージャが、ＡＥ１５６、ＡＥ１５４、およびＡＥ１５５の間の複合／入力アプリケーション関係を作成するように適用され得、ＡＥ１５６は、複合アプリケーションであり、ＡＥ１５４およびＡＥ１５５は、入力アプリケーションである。

別の一般的動作は、既存のアプリケーション関係を読み出すことを伴い得る。例えば、Ｍ２Ｍアプリケーションは、図５Ａのアプローチ１に従って、特定のアプリケーション関係を読み出すために、Ｍ２Ｍサーバにおいて維持されるアプリケーション関係記録データベースにアクセスし得るか、または図５Ｂのアプローチ２に従って、関与するアプリケーションのために作成される新しい属性／リンクにアクセスし得る。図８は、既存の登録されたアプリケーション間のアプリケーション関係を読み出すための例示的方法を図示する。ステップ１９７では、要求側１７１（例えば、ｏｎｅＭ２Ｍ ＡＥ、ｏｎｅＭ２Ｍ ＣＳＥ）が、アプリケーションの１つ以上の関係を読み出すための要求（例えば、アプリケーション関係読み出し要求）をサービス層１７２（例えば、ＡＲＭサービスを伴うｏｎｅＭ２Ｍ ＣＳＥ）に送信し得る。アプリケーション関係読み出し要求は、ＡＲＲＩ（例えば、読み出されるべきアプリケーション関係記録の識別子）等のアプリケーション関係リソースのアドレスを含み得るか、または本明細書で定義されるようなＡＲＡのアドレスを含み得る。ステップ１９８では、ステップ１９７で受信される情報に基づいて、サービス層１７２が、表１に示される情報等の対応するアプリケーション関係記録の場所を特定する。ステップ１９９では、サービス層１７２が、応答を要求側１７１に返信し得る。ステップ１９９の応答は、所望のアプリケーション関係記録またはＡＲＡの表現を含み得る。

別の一般的動作は、既存のアプリケーション関係を更新することを伴い得る。例えば、Ｍ２Ｍアプリケーションは、図５Ａのアプローチに従って、既存のアプリケーション関係を更新するために（例えば、子アプリケーションまたは入力アプリケーションを変更するために）、Ｍ２Ｍサーバにおいて維持されるアプリケーション関係記録データベースを更新し得るか、または図５Ｂのアプローチに従って、関与するアプリケーションのために作成される新しい属性／リンクを更新し得る。図９は、既存の登録されたアプリケーション間のアプリケーション関係を更新する例示的方法を図示する。ステップ２０１では、要求側１７１が、アプリケーション関係を更新するための要求（例えば、アプリケーション関係更新要求）をサービス層１７２に送信し得る。アプリケーション関係更新要求は、以下の情報を含み得る：ＡＲＲＩ（例えば、更新されるアプリケーション関係記録の識別子）、アプリケーションのリスト等の所望のアプリケーション関係記録に対して更新されるべき他の属性、または本明細書で議論されるようなＡＲＡのアドレスもしくは値。ステップ２０２では、ステップ２０１で受信される情報に基づいて、サービス層１７２が、ステップ２０１における要求のように、対応するアプリケーション関係記録またはＡＲＡの場所を特定し、更新し得る。ステップ２０３では、サービス層１７２が、応答を要求側１７１に返信し得る。ステップ２０３の応答は、更新されたアプリケーション関係記録またはＡＲＡの表現を含み得る。ステップ２０４では、サービス層１７２が、アプリケーション関係記録またはＡＲＡの変更について、更新されたアプリケーションのリスト上の関与するアプリケーション２０５に通知を送信し得る。

一般的動作は、既存のアプリケーション関係を削除することを伴い得る。例えば、Ｍ２Ｍアプリケーションは、図５Ａのアプローチに従って、Ｍ２Ｍサーバにおいて維持されるようなアプリケーション関係記録データベースから、その既存のアプリケーション関係を削除するか、または図５Ｂのアプローチに従って、関与するアプリケーションのために作成された新しい属性／リンクを削除することができる。図１０は、既存の登録されたアプリケーション間のアプリケーション関係を削除する例示的方法を図示する。ステップ２０６では、要求側１７１が、アプリケーション関係を削除するための要求（例えば、アプリケーション関係削除要求）をサービス層１７２に送信する。このアプリケーション関係削除要求は、ＡＲＲＩ（例えば、削除されるアプリケーション関係記録の識別子）またはアプリケーション関係属性のアドレスを含み得る。ステップ２０６では、要求側１７１が、ＡＲＲＩを明示的に示さないが、削除されるべきアプリケーション関係記録についてある基準を与えることを選定し得る。例えば、１つ以上の特定のアプリケーション（例えば、ＡＥ１５１）が関与するアプリケーション関係記録を削除すること。ステップ２０７では、ステップ２０６で受信される情報に基づいて、サービス層１７２が、対応するアプリケーション関係記録またはＡＲＡの場所を特定して削除する。ステップ２０８では、サービス層１７２が、応答を要求側１７１に返信する。ステップ２０８のこの応答は、削除結果（例えば、成功または失敗）を含み得る。ステップ２０９では、サービス層１７２が、通知をアプリケーション（例えば、親／子または複合／入力アプリケーション）のリスト上の全ての関与するアプリケーション（例えば、アプリケーション１７３）に送信し得る。

一般的動作は、既存のアプリケーション関係を発見することを伴い得る。例えば、Ｍ２Ｍアプリケーションは、図５Ａのアプローチに従って、それが他のアプリケーションと有するアプリケーション関係を発見するために、Ｍ２Ｍサーバにおいて維持されるアプリケーション関係記録データベースにアクセスするか、または対応するアプリケーション関係を発見するために、図５Ｂのアプローチに従って、関与するアプリケーションのために作成された新しい属性／リンクにアクセスすることができる。図１１は、既存の登録されたアプリケーション間のアプリケーション関係を発見する例示的方法を図示する。ステップ２１１では、要求側１７１が、アプリケーション関係を発見するための要求（例えば、アプリケーション関係発見要求）をサービス層１７２に送信する。このアプリケーション関係発見要求は、特定のアプリケーション名称／識別子に関連付けられるアプリケーション関係を発見すること、一組の特定のアプリケーション間のアプリケーション関係を発見すること、特定のタイプのアプリケーション関係を発見すること、または特定の数の関与するアプリケーションを有するアプリケーション関係を発見すること等のある検索基準を含み得る。ステップ２１２では、ステップ２１１で受信される情報に基づいて、サービス層１７２が、対応するアプリケーション関係記録またはアプリケーション関係属性の場所を特定する。ステップ２１３では、サービス層１７２が、応答を要求側１７１に返信する。ステップ２１３の応答は、発見されたアプリケーション関係記録またはＡＲＡ（例えば、それらの識別子もしくはアドレス）のリストを含み得る。

以下では、強化アプリケーション登録サービス、強化アプリケーション発表サービス、強化アプリケーションソフトウェア管理サービス、関係認識アプリケーション発見、またはアプリケーション関係の加入および通知等、アプリケーション関係（例えば、親／子関係および複合／入力関係）を使用し得るいくつかの新しい付加価値（強化）サービスが議論されている。強化アプリケーション登録は、親／子アプリケーション、複合／入力アプリケーション、および他の関係に適用され得る強化登録プロシージャならびに登録解除プロシージャを含み得る。強化登録プロセス中、アプリケーション関係記録またはＡＲＡは、自動的に作成され得る。強化登録解除プロセス中、アプリケーション関係記録またはＡＲＡは、自動的に更新もしくは除去され得る。例では、親アプリケーションおよび子アプリケーションは、ジム使用事例におけるもの等、同一のＭ２Ｍデバイス、ゲートウェイ、またはサーバにおける同一場所に位置し得る。登録を行う前、アプリケーションは、最初に、それら自体とサービス層との間に個々のセキュアな接続をブートストラップし、確立し得る。このブートストラッププロセスでは、親アプリケーションは、それ自身のセキュリティブートストラッププロセス中、子アプリケーションがサービス層とのそれらのセキュアな接続を確立することを助け得る。

図１２は、親／子アプリケーション登録プロセスのための例示的方法を図示する。ＡＥ１５１が、親アプリケーションである一方で、ＡＥ１５２およびＡＥ１５３は、子アプリケーションである。ステップ２１５では、ＡＥ１５１が、アプリケーションを登録するための要求（例えば、アプリケーション登録要求）をサービス層１７２に送信する。このアプリケーション登録要求は、以下の情報を含み得る：ＡＥ１５１、ＡＥ１５２、およびＡＥ１５３等の関係；ＡＥ１５１、ＡＥ１５２、またはＡＥ１５３の記述；または、ＡＥ１５１、ＡＥ１５２、またはＡＥ１５３の名称、標識、または識別子。ステップ２１６では、サービス層１７２が、ＡＥ１５１、ＡＥ１５２、またはＡＥ１５３のための対応するリソースを作成する。ステップ２１７では、サービス層１７２が、対応するアプリケーション関係記録またはＡＲＡを作成し得る。作成されたＡＲＡは、各作成されたアプリケーションリソースのための属性を作成するために使用され得る。例えば、ＡＥ１５１のための作成されたリソースは、ＡＥ１５２およびＡＥ１５３のためのリソースに接続する子ポインタまたはリンクを有し得る。別の実施例では、ＡＥ１５１（またはＡＥ１５３）のための作成されたリソースは、ＡＥ１５２のためのリソースに接続する親ポインタもしくはリンクを有し得る。別の実施例では、ＡＥ１５２（またはＡＥ１５３）のための作成されたリソースは、ＡＥ１５３（またはＡＥ１５２）のためのリソースに接続する、兄弟ポインタもしくはリンクを有し得る。ステップ２１８では、サービス層１７２が、ＡＥ１５１、ＡＥ１５２、またはＡＥ１５３のために作成されたリソースのリンクを含み得る応答をＡＥ１５１に返信する。

図１３は、親／子アプリケーション登録のための別の例示的方法を図示する。ＡＥ１５１が、親アプリケーションであり得る一方で、ＡＥ１５２およびＡＥ１５３は、子アプリケーションである。ステップ２２０では、ＡＥ１５１が、ＡＥ１５１のみを登録するために、アプリケーション登録要求をサービス層１７２に送信し得る。ステップ２２１では、サービス層１７２が、ＡＥ１５１のための対応するリソースを作成し得る。ステップ２２２では、サービス層１７２が、応答をＡＥ１５１に返信する。ステップ２２２における応答は、ＡＥ１５１のためのリソースを作成することの結果、例えば、成功または失敗、ならびに作成されたリソースのコンテンツを含み得る。ステップ２２３では、ＡＥ１５１が、ＡＥ１５１を登録するために、別のアプリケーション登録要求をサービス層１７２に送信し得る。ステップ２２３のアプリケーション登録要求は、ステップ２２１において作成されるＡＥ１５１のためのリソースへのリンク、ＡＥ１５１とＡＥ１５２との間の関係、ＡＥ１５２の記述、またはＡＥ１５１およびＡＥ１５２の名称、標識、もしくは識別子等の情報を含み得る。ステップ２２４では、サービス層１７２が、ＡＥ１５２のための対応するリソースを作成する。ステップ２２５では、サービス層１７２が、対応するアプリケーション関係記録またはＡＲＡを作成する。作成されたＡＲＡは、各作成されたアプリケーションリソースの新しい属性を作成するために使用され得る。ＡＥ１５２のための作成されたリソースは、ＡＥ１５１のためのリソースに接続する親ポインタまたはリンクを有し得る。サービス層１７２は、ＡＥ１５２のためのリソースに接続する子ポインタまたはリンクを追加するために、ＡＥ１５１のリソースを更新し得る。

ステップ２２６では、サービス層１７２が、応答をＡＥ１５１に送信し得る。ステップ２２６のこの応答は、ＡＥ１５２のために作成されたリソースのリンクを含み得る。ステップ２２７では、ＡＥ１５１が、ＡＥ１５３を登録するために、別のアプリケーション登録要求をサービス層１７２に返信し得る。ステップ２２７のこのアプリケーション登録要求は、ステップ２２１において作成されるＡＥ１５１のためのリソースへのリンク、ＡＥ１５１とＡＥ１５３との間の関係、ＡＥ１５３の記述、またはＡＥ１５１およびＡＥ１５３の名称、標識、もしくは識別子等の情報を含み得る。ステップ２２８では、サービス層１７２が、ＡＥ１５３のための対応するリソースを作成する。ステップ２２９では、サービス層１７２が、ステップ１９１において作成されるようなアプリケーション関係記録またはＡＲＡを更新する。ＡＲＡは、各作成されたアプリケーションリソースのための属性に使用され得る。ＡＥ１５３のための作成されたリソースは、ＡＥ１５１のためのリソースに接続する親ポインタまたはリンクを有し得る。サービス層１７２は、ＡＥ１５３のためのリソースに接続する子ポインタまたはリンクを追加するために、ＡＥ１５１のためのリソースを更新し得る。ステップ２３０では、サービス層１７２が、応答をＡＥ１５１に返信し得る。ステップ２３０の応答は、ＡＥ１５３のために作成されるリソースのリンクを含み得る。

図１４は、複合アプリケーション登録のための例示的方法を図示する。ＡＥ１５６が、複合アプリケーションである一方で、ＡＥ１５４およびＡＥ１５５は、入力アプリケーションである。また、この登録プロセスは、ＡＥ１５５のための初めての登録ではないこともあり、ＡＥ１５６は、ＡＥ１５４およびＡＥ１５５についての知識を有し得る。ステップ２３３からステップ２３６では、ＡＥ１５４およびＡＥ１５５が、それらをサービス層１７２に独立して登録する。ステップ２３３では、サービス層１７２（例えば、ＡＲＭ）が、ＡＥ１５４のための登録メッセージを交換し得る。ステップ２３４では、サービス層１７２が、ＡＥ１５４のためのリソースを作成し得る。ステップ２３５では、サービス層１７２が、ＡＥ１５５のための登録メッセージを交換し得る。ステップ２３６では、サービス層１７２が、ＡＥ１５５のためのリソースを作成し得る。ステップ２３７では、ＡＥ１５６が、それ自体（ＡＥ１５６）を登録するためのアプリケーション登録要求をサービス層１７２に送信し得、その間に、ＡＥ１５６が２つの入力アプリケーションとしてＡＥ１５４およびＡＥ１５５を伴う複合アプリケーションであることをサービス層１７２に知らせる。ステップ２３７のアプリケーション登録要求は、ＡＥ１５６、ＡＥ１５４、およびＡＥ１５５の間の関係、ＡＥ１５６、ＡＥ１５４、およびＡＥ１５５の記述、ＡＥ１５６、ＡＥ１５４、およびＡＥ１５５の名称、標識、または識別子、もしくは、ステップ２３４ならびにステップ２３６においてそれぞれ作成される、ＡＥ１５４またはＡＥ１５５のリソースへのリンク等の情報を含み得る。ＡＥ１５６がこの情報を取得するための１つの方法は、発見機能（例えば、ｏｎｅＭ２Ｍにおける発見ＣＳＦ）を使用することである。

ステップ２３８では、サービス層１７２が、ＡＥ１５１のためのリソースを作成し、ＡＥ１５４およびＡＥ１５５のためのリソースを更新し得る。ステップ２３９では、サービス層１７２が、対応するアプリケーション関係記録またはＡＲＡを作成し得る。作成されたＡＲＡは、以下等の各作成されたアプリケーションリソースのための属性を有し得る：ＡＥ１５４およびＡＥ１５５のためのリソースに接続する入力ポインタまたはリンクを含むＡＥ１５６のためのリソース；ＡＥ１５６のためのリソースに接続する複合リンクを含むＡＥ１５４のためのリソース；または、ＡＥ１５６のためのリソースに接続する複合リンクを含むＡＥ１５５のためのリソース。ステップ２４０では、サービス層１７２が、アプリケーション登録応答をＡＥ１５６に送信し得る。ステップ２４１では、サービス層１７２が、アプリケーション関係通知をＡＥ１５４に送信し得る。このアプリケーション関係通知は、ＡＥ１５６とＡＥ１５４との間の関係、ＡＥ１５６のためのリソースへのリンク、またはＡＥ１５６の名称、標識、もしくは識別子等の情報を含み得る。ステップ２４２では、サービス層１７２が、アプリケーション関係通知をＡＥ１５５に送信し得る。このアプリケーション関係通知は、ＡＥ１５６とＡＥ１５５との間の関係、ＡＥ１５６のためのリソースへのリンク、ＡＥ１５６の名称、標識、または識別子等の情報を含み得る。

図１５は、親／子アプリケーション登録解除のための例示的プロシージャを示す。ここでは、ＡＥ１５１が、親アプリケーションである一方で、ＡＥ１５２およびＡＥ１５３は、子アプリケーションである。ブロック２４３が、子アプリケーションを登録解除することを伴う一方で、ブロック２５１は、親アプリケーションを登録解除することを伴う。ステップ２４５では、ＡＥ１５１が、子アプリケーション（例えば、ＡＥ１５２）のうちの１つを登録解除するために、サービス層からアプリケーションを登録解除するための要求（例えば、アプリケーション登録解除要求）をサービス層１７２に送信する。ステップ２４５のこのアプリケーション登録解除要求は、登録解除されるべき子アプリケーションの名称、標識、または識別子、もしくは登録解除される子アプリケーションのリソースへのリンク等の情報を含み得る。ステップ２４６では、サービス層１７２が、登録解除されるべき子アプリケーションのリソース（例えば、ＡＥ１５２のリソース）を除去する。サービス層１７２はまた、ＡＥ１５１のリソースから、ＡＥ１５２に接続する子ポインタまたはリンクを除去し得る。サービス層１７２はまた、ＡＥ１５３のリソースから、ＡＥ１５２に接続する兄弟ポインタまたはリンクを除去し得る。加えて、サービス層１７２はまた、対応するアプリケーション関係記録を更新し得る。ステップ２４７では、サービス層１７２が、応答をＡＥ１５１に返信し得る。

図１５のブロック２５１において親アプリケーションを登録解除することに対して、ステップ２５２では、ＡＥ１５１が、それ自体（ＡＥ１５１）を登録解除するために、アプリケーション登録解除要求をサービス層１７２に送信する。ステップ２５３では、ＡＥ１５３がＡＥ１５１の子アプリケーションであるので、サービス層１７２が、ＡＥ１５１およびＡＥ１５３のためのリソースを除去し得る。サービス層１７２はまた、対応するアプリケーション関係記録を除去し得る。ステップ２５４では、サービス層１７２が、応答をＡＥ１５１に送信し得る。ブロック２４３またはブロック２５１に示されるステップの代替として、子アプリケーションが、それ自体を登録解除し、そして、その親アプリケーションに通知し得る。

図１６は、複合アプリケーション登録解除のための例示的方法を図示する。ここでは、ＡＥ１５６が、複合アプリケーションである一方で、ＡＥ１５４およびＡＥ１５５は、入力アプリケーションである。ブロック２６１が、入力アプリケーションを登録解除することを伴う一方で、ブロック２６６は、複合アプリケーションを登録解除することを伴う。ステップ２６２では、ＡＥ１５５が、それ自体を登録解除するために、アプリケーション登録解除要求をサービス層１７２に送信し得る。このアプリケーション登録解除要求は、登録解除されるべき入力アプリケーションの名称、標識、または識別子、もしくは登録解除される入力アプリケーションのリソースへのリンク等の情報を含み得る。ステップ２６３では、サービス層１７２が、登録解除されるべき入力アプリケーションのリソース（例えば、ＡＥ１５５のリソース）を除去し得る。サービス層１７２はまた、ＡＥ１５６のリソースから、ＡＥ１５５に接続する入力ポインタまたはリンクを除去し得る。サービス層１７２はまた、対応するアプリケーション関係記録を更新し得る。ステップ２６４では、サービス層１７２が、応答をＡＥ１５５に返信し得る。ステップ２６５では、サービス層１７２が、アプリケーション関係通知をＡＥ１５６に送信し得る。このアプリケーション関係通知は、登録解除された入力アプリケーション（例えば、ＡＥ１５５）の名称、標識、または識別子、もしくは登録解除された入力アプリケーションのリソース（例えば、ＡＥ１５５のリソース）へのリンク等の情報を含み得る。

図１６のブロック２６６に関して、ステップ２６７では、ＡＥ１５６が、それ自体（ＡＥ１５６）を登録解除するために、アプリケーションが登録解除するための要求（例えば、アプリケーション登録解除要求）をサービス層１７２に送信し得る。ステップ２６８では、サービス層１７２が、ＡＥ１５６のリソースを除去し得る。サービス層１７２はまた、ＡＥ１５４のリソースから、ＡＥ１５６に接続する複合ポインタまたはリンクを除去し得る。加えて、サービス層１７２は、対応するアプリケーション関係記録を除去し得る。ステップ２６９では、サービス層１７２が、応答をＡＥ１５６に送信する。ステップ２７０では、サービス層１７２が、アプリケーション関係通知をＡＥ１５４に送信し得る。このアプリケーション関係通知は、登録解除された複合アプリケーション（例えば、ＡＥ１５６）の名称、標識、または識別子、登録解除された複合アプリケーションのリソース（例えば、ＡＥ１５６のリソース）へのリンク等の情報を含み得る。図１６に関する別の実施例では、サービス層１７２は、ステップ２６４後に（例えば、入力アプリケーションが登録解除された後、またはある数の入力アプリケーションが登録解除された後に）複合アプリケーションＡＥ１５６を自動的に登録解除し得る。

強化アプリケーション発表は、親／子アプリケーションまたは複合／入力アプリケーションを発表するためのプロシージャを指し得る。図１７は、親／子アプリケーション発表のための例示的プロシージャを図示する。ここでは、アプリケーションブロック２７２が、親／子関係（例えば、図４Ａ）、複合／入力関係（例えば、図４Ｂ）等を伴うアプリケーションを表すことが仮定される。ステップ２７４では、アプリケーションブロック２７２のアプリケーションが、それら自体をサービス層１７２に登録し得、それは、本明細書に議論されるプロシージャを用いて完了され得る。ステップ２７５では、サービス層１７２が、アプリケーション発表要求をサービス層２７３に送信し得る。ステップ２７５のこのアプリケーション発表要求は、アプリケーションブロック２７２のアプリケーションの関係、アプリケーションブロック２７２のアプリケーションの名称、標識、または識別子、もしくはアプリケーションブロック２７２のアプリケーションのリソースへのリンク等の情報を含み得る。ステップ２７６では、サービス層２７３が、ブロック２７２のアプリケーションのための発表リソースを作成し得る。作成された発表リソースは、ブロック２７２のアプリケーションの関係が組み込まれた、１つの階層リソースであり得る。別の実施例では、作成された発表リソースは、それぞれ、ブロック２７２のアプリケーションに対して各アプリケーションのために別個であるが、相互参照されたリソースであり得る。ステップ２７７では、サービス層２７３が、応答をサービス層１７２に送信する。

サービス層は、オープンモバイルアライアンス（ＯＭＡ）ソフトウェアコンポーネント管理オブジェクト（ＳＣＯＭＯ）等のデバイス管理（ＤＭ）技術に基づいて、アプリケーションソフトウェアを管理（例えば、アップグレード）し得る。以下は、アプリケーションソフトウェア管理を増進するために、アプリケーション関係を利用し得る。図１８は、親／子アプリケーションに対する等、関係を認識しているソフトウェア管理のための例示的方法を図示する。ステップ２８４では、サービス層１７２が、Ｍ２Ｍデバイス２８１上に位置する子アプリケーション２８３のためのソフトウェアを読み出す。ソフトウェアは、サービス層１７２と同一の装置、または示されていない別の装置（例えば、サーバ）上に位置し得る。ここで、子アプリケーション２８３は、サービス層１７２の援助を受けてソフトウェアをダウンロードする。ステップ２８５では、サービス層１７２が、対応する親アプリケーション（例えば、親アプリケーション２８２）を発見するために、アプリケーション関係記録またはＡＲＡを分析し得る。ステップ２８６では、サービス層１７２が子アプリケーションのためのソフトウェアの読み出しに役立った後（ソフトウェアが子アプリケーション２８３のためにまだインストールされていない）、サービス層１７２が、通知をＭ２Ｍデバイス２８１の親アプリケーション２８２に送信し得る。通知は、以下の情報を含み得る：１）ダウンロードされた新しいソフトウェアを伴う子アプリケーションの名称、標識、または識別子、または、２）新しいソフトウェアバージョン。ステップ２８７では、親アプリケーション２８２が、新しいソフトウェアをインストールするように子アプリケーション２８３をトリガし得る。ステップ２８７のこのトリガは、インストールされるべきソフトウェアバージョンを含み得る。この例では、親アプリケーション２８２は、子アプリケーション２８３へのダウンロードされたソフトウェアのインストールを可能にするための許可を与えることを決定し得る。許可を与える決定は、ダウンロードされたソフトウェアがインストールされた場合、悪影響または他の問題があるかどうかを決定することに基づき得る。インストールの効果は、親アプリケーション２８２、子アプリケーション２８３、または親アプリケーション２８２の他の関連子アプリケーション（図示せず）に直接であり得る。ステップ２８８では、子アプリケーション２８３が、対応するアプリケーションをインストールし得る。ステップ２８９では、親アプリケーション２８２が、確認メッセージをサービス層１７２に送信し得る。ステップ２８９におけるメッセージは、子アプリケーション２８３の最新ソフトウェアバージョンの指示、またはステップ２８４のソフトウェアがインストールされたという指示を含み得る。

図１９は、関係認識複合／入力アプリケーションソフトウェア管理のための例示的方法を図示する。ステップ２９３では、サービス層１７２が、入力アプリケーション２９２のソフトウェアを更新し得る。ステップ２９４では、サービス層１７２が、対応する複合アプリケーションを発見するために、アプリケーション関係記録またはＡＲＡを分析し得る。ステップ２９５では、サービス層１７２が、更新された新しいソフトウェアまたは新しいソフトウェアバージョンを伴う入力アプリケーション２９２の名称、標識、または識別子を知らせるための通知を複合アプリケーション２９１に送信し得る。複合アプリケーション２９１は、新しいバージョンの通知およびステップ２９５で受信される任意の他の詳細に基づいて、入力を受信する方法を変更するか、または他の動作を調節し得る。変更は、複合アプリケーション２９１のソフトウェアを更新することを含み得る。ステップ２９６では、複合アプリケーション２９１は、通知を承認する確認メッセージをサービス層１７２に送信し得、複合アプリケーション２９１に関する他の詳細を含み得る。詳細は、入力アプリケーション２９２との関係を終了させる通知を含み得、それは、ソフトウェアの不適合性に起因し得る。

図２０は、関係を認識しているという関連でのアプリケーション発見のための例示的プロシージャを図示する。ステップ３０１では、要求側１７１が、アプリケーションを発見するための要求（例えば、アプリケーション発見要求）をサービス層１７２に送信し得る。ステップ３０１のアプリケーション発見要求は、特定のアプリケーションの親アプリケーションを発見すること、特定のアプリケーションの子アプリケーションを発見すること、特定のアプリケーションの入力アプリケーションを発見すること、特定のアプリケーションの複合アプリケーションを発見すること、特定のアプリケーション関係内のアプリケーションを発見すること、または一組のアプリケーション関係内の共通プリケーションを発見すること等の検索基準を含み得る。ステップ３０２では、ステップ３０１において受信される情報に基づいて、サービス層１７２が、対応するアプリケーションの場所を特定する。ステップ３０３では、サービス層１７２が、応答を要求側１７１に送信する。ステップ３０３の応答は、発見されたアプリケーションのリスト（例えば、それらの識別子または名称）を含み得る。

図２１は、アプリケーション関係についての加入および通知のためのプロシージャを図示し、加入および通知を通して、アプリケーションは、それが他のアプリケーションと有する任意の新しい関係についての自動通知、または他のアプリケーションとのその既存の関係に対する任意の変更についての自動通知を受信し得る。ステップ３０５では、要求側１７１が、アプリケーション関係に基づいて加入するための要求（例えば、アプリケーション関係加入要求）をサービス層１７２に送信し得る。ステップ３０５の要求は、標的アプリケーションのリスト（例えば、それらの識別子または名称）を含み得る。ステップ３０６では、サービス層１７２が、加入要求が承認されているかどうかを示すためのアプリケーション関係加入応答メッセージを要求側３０７に送信し得る。ステップ３０７では、ある時間量後、標的アプリケーションについて、またはそれに関連する関係が変更される。例えば、新しい関係が、ステップ３０５のリストの中の標的アプリケーションのうちの１つと作成され得る。ステップ３０８では、サービス層１７２が、アプリケーション関係通知を要求側１７１に送信し得る。ステップ３０８の通知は、ステップ３０７に関して起こり得る関係変化を含み得る。

以下では、ｏｎｅＭ２Ｍアーキテクチャにおいて本明細書で議論される方法を適用または実装することに関する追加の詳細が開示されている。方法は、ｏｎｅＭ２Ｍ ＣＳＦ（例えば、図２２のアプリケーション関係管理（ＡＲＭ）ＣＳＦ）として実装され得る。図２２の構造は、以下でさらに詳述される。前述のプロシージャにおける「サービス層」アクタ（例えば、サービス層１７２）は、ＡＲＭ ＣＳＦと置換され得る。換言すると、ＡＲＭ ＣＳＦは、サービス層に関して本明細書に説明された機能性を果たす。前述のプロシージャにおける「要求側」（例えば、要求側１７１）は、ｏｎｅＭ２Ｍ ＡＥ、ＡＲＭ ＣＳＦ、またはｏｎｅＭ２Ｍ ＣＳＥであり得る。本明細書に開示される方法は、既存のｏｎｅＭ２Ｍ基準点（例えば、ＭｃａおよびＭｃｃ）に影響を及ぼし得る。換言すると、メッセージ交換は、ｏｎｅＭ２Ｍ基準点の一部として実装され得る。例えば、アプリケーションとサービス層（例えば、ＣＳＥ）との間のメッセージは、Ｍｃａ基準点を経由して移動し、別様にそれを伴い得る。別の例では、サービス層（例えば、ＣＳＥ）間のメッセージは、Ｍｃｃ基準点を伴い得る。

本明細書で議論される強化アプリケーション登録サービスは、機能性を増進するためのＲＥＧ ＣＳＦにおいて実装され得る。本明細書で議論されるソフトウェア管理方法は、例えば、ＤＭ ＣＳＦまたはＡＳＭ ＣＳＦにおいて実装され得る。

図２３および図２４は、強化または新しいリソースの例示的リソースツリーを図示する。アプリケーション関係記録（例えば、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１）は、提案されたアプリケーション関係管理を可能にし得る。＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１は、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースのサブリソースとして、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１が関与する記録アプリケーション関係に追加され得る。図２３に示されるように、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１は、ｄｅｓｃｒｉｐｔｉｏｎ３２２、ｌｉｆｅｔｉｍｅ３２３、ｔｙｐｅ３２４、ｌｉｆｅＯｆＡｐｐ３２５、およびｐｒｉｍａｒｙＡｐｐ３２６等の属性を有し得る。ｄｅｓｃｒｉｐｔｉｏｎ３２２は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１のテキスト記述の指示である。ｌｉｆｅｔｉｍｅ３２３は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１の存続期間の指示であり得る。ｔｙｐｅ３２４は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１のアプリケーション関係タイプ（例えば、親／子アプリケーションまたは複合／入力アプリケーション）の指示であり得る。ｌｉｓｔＯｆＡｐｐ３２５は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞に関与するアプリケーションのリストの指示であり得る。この属性の値は、リスト上のアプリケーションの名称、標識、または識別子であり得る。ｐｒｉｍａｒｙＡｐｐ３２６は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１の主要アプリケーション（例えば、親アプリケーションまたは複合アプリケーション）の指示である。

図２４は、新しい＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの例示的構造を図示する。＜ａｐｐｌｉｃａｔｉｏｎ＞３３１は、開示されるアプリケーション管理（例えば、アプリケーション登録、アプリケーション更新、アプリケーション登録解除、アプリケーション発表、およびアプリケーションソフトウェア管理）をサポートするサブリソースまたは属性を含み得る。＜ａｐｐｌｉｃａｔｉｏｎ＞３３１は、属性ａｒｒｉ３３３、ｐａｒｅｎｔＡｐｐ３３４、ｃｈｉｌｄＡｐｐ３３５、ｓｉｂｌｉｎｇＡｐｐ３３６、ｃｏｍｐｏｓｉｔｅＡｐｐ３３７、およびｉｎｐｕｔＡｐｐ３３８を有し得る。ａｒｒｉ３３３は、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１が関与し得る、ＡＲＲＩの指示であり得る。各ａｒｒｉ３３３は、＜ａｐｐＲｅｌａｔｉｏｎＲｅｃｏｒｄ＞３２１リソースを指し示す。ｐａｒｅｎｔＡｐｐ３３４は、該当する場合、本＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの親アプリケーションの指示であり得る。ｃｈｉｌｄＡｐｐ３３５は、該当する場合、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの子アプリケーションの指示であり得る。ｓｉｂｌｉｎｇＡｐｐ３３６は、該当する場合、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの兄弟アプリケーションの指示であり得る。ｃｏｍｐｏｓｉｔｅＡｐｐ３３７は、該当する場合、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの複合アプリケーションの指示であり得る。ｉｎｐｕｔＡｐｐ３３８は、該当する場合、＜ａｐｐｌｉｃａｔｉｏｎ＞３３１リソースの入力アプリケーションの指示であり得る。

図２５は、開示される階層＜ａｐｐｌｉｃａｔｉｏｎ＞構造の別の例示的構造を図示する。＜ａｐｐｌｉｃａｔｉｏｎ＞３４２は、アプリケーションを表す。ｌｉｆｅｔｉｍｅ３４３は、＜ａｐｐｌｉｃａｔｉｏｎ＞と＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞３４５との間のアプリケーション関係タイプの存続期間の指示であり得る。ｔｙｐｅ３４４は、＜ａｐｐｌｉｃａｔｉｏｎ＞３４１（第１のアプリケーション）と＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞３４４との間のアプリケーション関係タイプの指示であり得る。＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞３４５は、＜ａｐｐｌｉｃａｔｉｏｎ＞３４１の子アプリケーション（タイプ＝「親／子関係」である場合）または入力アプリケーション（タイプ＝「複合／入力関係」である場合）を示す。＜ａｐｐｌｉｃａｔｉｏｎ＞３４１は、そのサブリソースとして複数の＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞を有し得る。

図２５を続けて参照すると、＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞リソースは、そのサブリソースとして別の＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞リソース（例えば、＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞３４６）を有し得る。この場合、＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞は、上記で説明されるような「ｔｙｐｅ」属性を有し得る。＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞の値は、実際の＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞リソースにリンクする、ポインタまたはＵＲＩであり得る。＜ｓｕｂ−ａｐｐｌｉｃａｔｉｏｎ＞は、ａｒｒｉ、ｐａｒｅｎｔＡｐｐ、ｃｈｉｌｄＡｐｐ、ｓｉｂｌｉｎｇＡｐｐ、ｃｏｍｐｏｓｉｔｅＡｐｐ、およびｉｎｐｕｔＡｐｐを含む、図２４に示されるものと同一＜ａｐｐｌｉｃａｔｉｏｎ＞３３１の構造を有し得る。ＣｏＡＰを伴うｏｎｅＭ２Ｍアーキテクチャが、本明細書で背景として説明され、以降で説明される種々の実施例を例証するために使用され得るが、本開示の範囲内にとどまりながら、以降で説明される実施例の実装が変動し得ることが理解される。当業者は、開示された実施例は、上記で議論されるｏｎｅＭ２Ｍアーキテクチャを使用する実装に限定されないが、むしろＥＴＳＩ Ｍ２Ｍ、ＭＱＴＴ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることも認識するであろう。

図２６は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース３５０（例えば、タッチスクリーンディスプレイ）は、表１のパラメータ、複合または親アプリケーションのリスト等のアプリケーション関係に関連付けられるブロック３５２の中でテキストを提供し得る。デバイスが制約されたデバイスであるかどうかに基づいて、デバイスが制約されたデバイスまたは簡略化されたインターフェースであるかどうかに対して、追加の情報（図示せず）があり得る。別の実施例では、本明細書で議論されるステップのうちのいずれかの進展（例えば、送信されたメッセージまたはステップの成功）が、ブロック３５２の中で表示され得る。加えて、グラフィカル出力３５４が、ディスプレイインターフェース３５０上に表示され得る。グラフィカル出力３５４は、アプリケーション関係、本明細書で議論される任意の方法またはシステムの進展のグラフィカル出力等に関する、デバイスまたはアプリケーションのトポロジであり得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、アプリケーション関係（例えば、親／子関係または複合／入力関係）に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色を制御するように構成され得る。例えば、ディスプレイ上の照明パターン、画像、もしくは色のうちのいくつかは、アプリケーション関係の能力、アプリケーション関係の成功した登録、適用可能な関係記録にリンクすること、ならびに既存のアプリケーション関係を読み出すこと、更新すること、削除すること、および発見することに関する他のもの等のアプリケーション関係を管理することのインジケータであり得る。

プロセッサ３２は、本明細書に説明される実施例のうちのいくつかにおけるＬＭＳが成功であるか不成功であるか（例えば、アプリケーション関係に加入すること、関係に基づいてアプリケーションを登録すること、関係を発見すること等）に応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するか、もしくは別様にアプリケーション関係および関連コンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、もしくは色は、図に図示されるか、または本明細書で議論される（例えば、図６−図２１等）方法フローもしくはコンポーネントのうちのいずれかのステータスを反映し得る。本ここでは、Ｍ２Ｍにおけるアプリケーション関係のメッセージおよびプロシージャが開示される。メッセージおよびプロシージャは、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、アプリケーション関係および管理コンポーネントを要求し、とりわけ、ディスプレイ４２上に表示され得るアプリケーション関係を要求、構成、またはクエリするために、インターフェース／ＡＰＩを提供するように拡張されることができる。

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

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

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

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

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

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

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

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

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

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

とりわけ、本明細書に説明されるような方法、システム、および装置は、とりわけ、アプリケーション関係を要求、構成、または決定するための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のアプリケーションのためのソフトウェアの読み出しを支援するための手段と、第２のアプリケーションに対する第１のアプリケーションの関係を決定するための手段であって、第２のアプリケーションは、親アプリケーションである、手段と、第２のアプリケーションに対する第１のアプリケーションの関係に基づいて、第１のメッセージを第２のアプリケーションに送信するための手段であって、メッセージは、第１のアプリケーションのためのソフトウェアの読み出しのアラートを含む、手段とを有する。第２のアプリケーションは、第１のアプリケーションに対する親アプリケーションであり得る。メッセージは、第２のアプリケーションに対する第１のアプリケーションの関係を含み得る。メッセージは、第１のアプリケーションの識別子またはソフトウェアのバージョンであり得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のアプリケーションのソフトウェアの直近でインストールされたバージョンの通知を受信することを含み得る、さらなる動作のための手段を有する。第１のアプリケーションは、第２のアプリケーションに対する入力アプリケーションであり得る。メッセージは、第１のアプリケーションが読み出されたソフトウェアをインスールしたことを第２のアプリケーションに通知し得る。第２のアプリケーションは、第１のアプリケーションが読み出されたソフトウェアをインスールしたという通知に基づいて、第１のアプリケーションからのデータを処理するためのプロセスを変更し得る。

方法、システム、ンピュータ読み取り可能な記憶媒体、または装置は、アプリケーション関係のためのリソースを作成するための要求を送信する手段であって、要求は、アプリケーション関係のタイプを含む、手段と、アプリケーション関係のためのリソースの作成を確認する応答を受信する手段であって、応答は、アプリケーション関係のためのリソースの識別子を含む、手段とを有する。要求はさらに、サービス層に登録されたアプリケーションのリスト、またはアプリケーション関係が存在した期間を含み得る。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１の登録要求に基づいて、第１のアプリケーションのための第１のリソースを作成する手段と、第２の登録要求に基づいて、第２のアプリケーションのための第２のリソースを作成する手段と、第１の要求を受信する手段であって、第１の要求は、第１のアプリケーションと第２のアプリケーションとの間の関係を作成するための要求を含む、手段と、第１の要求に基づいて、第１のアプリケーションと第２のアプリケーションとの間の関係を作成する手段とを有する。関係の作成は、第１のリソースおよび第２のリソースを更新することを含み得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、
第１のリソースを第２のリソースと接続するポインタで更新する手段であって、ポインタは、第１のアプリケーションが第２のアプリケーションの親であることを示、手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のアプリケーションと第２のアプリケーションとの間の関係の作成を第１のアプリケーションに通知する手段を有する。関係は、第１のアプリケーションと第２のアプリケーションとの間の親／子関係を含み得る。関係は、第１のアプリケーションと第２のアプリケーションとの間の複合／入力関係を含み得る。関係は、第１のリソース内の第１のアプリケーション関係属性を更新することを含み得る。第１の要求は、共通サービスエンティティのアプリケーション関係管理サービスにおいて受信され得る。

図に例証されるような本開示の主題の好ましい方法、システム、または装置を説明する際に、明確にするために具体的用語が採用される。しかしながら、請求される主題は、そのように選択される具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

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

Claims (20)

1. アプリケーション関係を管理するための装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
   第１の登録要求に基づいて、第１のアプリケーションのための第１のリソースを作成するための命令を提供することと、
   第２の登録要求に基づいて、第２のアプリケーションのための第２のリソースを作成するための命令を提供することと、
   第１の要求を受信することであって、前記第１の要求は、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成するための要求を含む、ことと、
   前記第１の要求に基づいて、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成するための命令を提供することであって、前記関係の前記作成は、前記第１のリソースおよび前記第２のリソースを更新することを含む、ことと、
   前記第２のリソースと接続するポインタで前記第１のリソースを更新することであって、前記ポインタは、前記第１のアプリケーションが前記第２のアプリケーションの親アプリケーションであることを示す、ことと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記動作は、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記関係の作成を前記第１のアプリケーションに通知することをさらに含む、請求項１に記載の装置。
3. 前記関係は、グラフィカルユーザインターフェース上に表示される、請求項１に記載の装置。
4. 前記動作は、前記関係に基づいてサービス層から登録解除することをさらに含む、請求項１に記載の装置。
5. 前記関係は、前記第１のリソース内の第１のアプリケーション関係属性を更新することを含む、請求項１に記載の装置。
6. 前記第１の要求は、共通サービスエンティティのアプリケーション関係管理サービスにおいて受信される、請求項１に記載の装置。
7. 前記装置は、マシンツーマシンデバイスまたはマシンツーマシンゲートウェイである、請求項１に記載の装置。
8. アプリケーション関係を管理する方法であって、前記方法は、
   第１の登録要求に基づいて、第１のアプリケーションのための第１のリソースを作成することと、
   第２の登録要求に基づいて、第２のアプリケーションのための第２のリソースを作成することと、
   第１の要求を受信することであって、前記第１の要求は、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成するための要求を含む、ことと、
   前記第１の要求に基づいて、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成することであって、前記関係の前記作成は、前記第１のリソースおよび前記第２のリソースを更新することを含む、ことと、
   前記第２のリソースと接続するポインタで前記第１のリソースを更新することであって、前記ポインタは、前記第１のアプリケーションが前記第２のアプリケーションの親アプリケーションであることを示す、ことと
   を含む、方法。
9. 前記第１のアプリケーションと前記第２のアプリケーションとの間の前記関係の作成を前記第１のアプリケーションに通知することをさらに含む、請求項８に記載の方法。
10. 前記関係は、グラフィカルユーザインターフェース上に表示される、請求項８に記載の方法。
11. 前記関係に基づいてサービス層から登録解除することをさらに含む、請求項８に記載の方法。
12. 前記関係は、前記第１のリソース内の第１のアプリケーション関係属性を更新することを含む、請求項８に記載の方法。
13. 前記第１の要求は、共通サービスエンティティのアプリケーション関係管理サービスにおいて受信される、請求項８に記載の方法。
14. マシンツーマシンゲートウェイが、前記関係を管理している、請求項８に記載の方法。
15. コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータデバイスによって実行されると、
    第１の登録要求に基づいて、第１のアプリケーションのための第１のリソースを作成することと、
    第２の登録要求に基づいて、第２のアプリケーションのための第２のリソースを作成することと、
    第１の要求を受信することであって、前記第１の要求は、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成するための要求を含む、ことと、
    前記第１の要求に基づいて、前記第１のアプリケーションと前記第２のアプリケーションとの間の関係を作成することと
    を含む動作を前記コンピュータデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
16. 前記関係の前記作成は、前記第１のリソースおよび前記第２のリソースを更新することを含む、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
17. 前記動作は、前記第２のリソースと接続するポインタで前記第１のリソースを更新することをさらに含み、前記ポインタは、前記第１のアプリケーションが前記第２のアプリケーションの親であることを示す、請求項１６に記載のコンピュータ読み取り可能な記憶媒体。
18. 前記動作は、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記関係の作成を前記第１のアプリケーションに通知することをさらに含む、請求項１６に記載のコンピュータ読み取り可能な記憶媒体。
19. 前記関係は、前記第１のアプリケーションと前記第２のアプリケーションとの間の親／子関係を含む、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記関係は、前記第１のアプリケーションと前記第２のアプリケーションとの間の複合／入力関係を含む、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。