JP2017537422A - サービス層における交渉サービスをサポートする方法 - Google Patents

Abstract

本願は、サービス層属性について交渉するためのコンピュータ実装装置を対象とする。装置は、サービス属性について交渉するための交渉サービス層のためのその上に記憶された命令を含む不揮発性メモリを含む。装置は、不揮発性メモリに動作可能に結合されるプロセッサも含む。プロセッサは、被交渉側から受信される交渉可能なサービス層属性を精査する命令を実施するように構成される。プロセッサは、精査された属性に基づいて、交渉要求を被交渉側に送信する命令を実施するようにも構成される。プロセッサは、被交渉側から提示された提案を受信する命令を実施するようにも構成される。本願の別の側面は、コンピュータ実装被交渉側と、サービス層属性について交渉するためのコンピュータ実装交渉側とを含むネットワーク化システムを対象とする。

Description

（関連出願の引用）
本願は、米国仮出願第６２／９８６，１０２号（２０１４年１２月１日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

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

Ｍ２Ｍサービスノードおよびアプリケーションは、現在、Ｍ２Ｍサービス層からサービスを提供する／アクセスするために、静的構成または事前プロビジョニングに依拠する。すなわち、異なる時に特定のサービスの種々の特徴または機能性を動的に要求するため、非効率的なサポートしかない。例えば、既存のｏｎｅＭ２Ｍは、ミドルノード（ＭＮ）共通サービスエンティティ（ＣＳＥ）がインフラストラクチャノード（ＩＮ）−ＣＳＥから記憶容量を動的に要求するための機構を提供しない。さらに、ＩＮ−ＣＳＥは、ＩＮ−アプリケーションエンティティ（ＡＥ）が管理することができるデバイスの数および／またはＩＮ−ＡＥが要求をＩＮ−ＣＳＥに発行することができる頻度を管理するためのサービスを有していない。

静的構成は、スループットに直接影響を及ぼす。すなわち、サービスをＭ２Ｍアプリケーションに提供することにおけるＭ２Ｍサーバの柔軟性が、非常に限定される。したがって、事前構成されたサービスは、Ｍ２Ｍサーバおよび／またはＭ２Ｍデバイスのための最適な選択ではない場合がある。例えば、必要とされるサービスは、要件変更またはコンテキスト変更に起因して変化し得る（例えば、Ｍ２Ｍサーバが、より多くの登録されたデバイスを有すること、または、Ｍ２Ｍデバイスがより多くの通信制約を伴う新しい場所に移動すること）。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態における概要の選択を導入するように提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述の必要性は、Ｍ２Ｍサービス層における交渉サービスを向上させ、サービスを動的に要求するための能力を提供するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。

本願の一側面では、コンピュータ実装方法が説明される。方法は、被交渉側から受信される交渉可能なサービス層属性を精査するステップを含む。方法は、精査された属性に基づいて、交渉要求を被交渉側に送信するステップも含む。方法は、被交渉側から提示された提案を受信するステップも含む。一実施形態では、方法は、所定の交渉ポリシをチェックすることに応じて、提示された提案を選択するステップを含む。別の実施形態では、方法は、受信される提示された提案が、被交渉側の所定の交渉ポリシに対してチェックされるステップを含む。別の実施形態では、交渉要求のステップは、サービスｉｄ、提案を行うための入力、提案される提案、およびそれらの組み合わせから選択される情報を含む。別の実施形態によると、提示された提案は、提案、別の被交渉側との交渉推奨、およびそれらの組み合わせから選択される情報を含む。別の実施形態によると、交渉要求を送信するステップは、ブローカを介して被交渉側に送信される。さらなる実施形態によると、提示された提案を受信するステップは、ブローカを介して被交渉側から受信される。

本願の別の側面では、被交渉側から交渉可能なサービス層属性について交渉するためのポリシを受信するステップを含むコンピュータ実装方法が説明される。方法は、属性について交渉するための要求を交渉側から受信するステップも含む。方法は、要求が被交渉側ポリシの所定の基準に適合するかどうかを決定するステップも含む。さらに、方法は、提示された提案を交渉側に送信するステップを含む。一実施形態では、方法は、交渉側から交渉確認を受信するステップと、交渉確認の確認応答を被交渉側に送信するステップとを含む。

本願のさらに別の側面では、交渉側から交渉可能なサービス層属性に対する交渉要求を受信するステップを含むコンピュータ実装方法が説明されている。方法は、属性を有する被交渉側の場所を特定するステップも含む。方法は、交渉要求を被交渉側に送信するステップも含む。さらに、方法は、被交渉側から交渉可能なサービスに対する提示された提案を受信するステップを含む。ある実施形態によると、方法は、提示された提案を交渉側に送信するステップと、交渉側から交渉確認を受信するステップと、交渉確認の確認応答を被交渉側に送信するステップとを含む。

別の側面によると、コンピュータ実装装置が開示される。装置は、サービス属性について交渉するためのその上に記憶された命令を有する交渉サービス層を含む不揮発性メモリを含む。装置は、不揮発性メモリに動作可能に結合されるプロセッサも含む。プロセッサは、被交渉側から受信される属性を精査する命令を実施するように構成される。プロセッサは、精査された属性に基づいて、交渉要求を被交渉側に送信するようにも構成される。ある実施形態によると、プロセッサは、被交渉側から提示された提案を受信する命令を実施するようにさらに構成される。一実施形態では、コンピュータ実装装置は、不揮発性メモリおよびプロセッサに動作可能に接続されるユーザインターフェースを有するディスプレイを含む。

本願のさらに別の側面では、サービス属性の交渉のためのその上に記憶された命令を有する、交渉サービス層を含む不揮発性メモリを有するコンピュータ実装装置が説明される。装置は、不揮発性メモリに動作可能に結合され、（ｉ）被交渉側から属性について交渉するためのポリシを受信し、（ｉｉ）属性について交渉するための要求を交渉側から受信し、（ｉｉｉ）要求が被交渉側ポリシの基準に適合するかどうかを決定する命令を実施するように構成されているプロセッサも含む。ある実施形態によると、プロセッサは、提示された提案を交渉側に送信する命令を実施するようにさらに構成される。一実施形態では、不揮発性メモリは、共通属性、作成、読み出し、削除、更新、実行、標識、ブローカ、タイプ、提案を行うための入力、提案を選択するための入力、開始、ステータス、標的、参照、提示された提案、選択された提案、出力パラメータ、サブスクリプション、およびそれらの組み合わせから選択される交渉リソースを記憶する。別の実施形態では、プロセッサは、属性について交渉するために交渉リソースを使用する。別の実施形態では、メモリは、共通属性、標識、交渉タイプ、交渉側、被交渉側、条件、結果、規則の選択、サブスクリプション、およびそれらの組み合わせから選択されるポリシリソースを記憶する。さらなる実施形態では、プロセッサは、属性について交渉するためにポリシリソースを使用する。一段とさらなる実施形態では、メモリは、共通属性、標識、クライアント、現在の交渉ブローカ、新しい交渉ブローカ、委託有効化、開始時間、持続時間、結果、サブスクリプション、およびそれらの組み合わせから選択される委託リソースを記憶する。その上さらなる実施形態では、プロセッサは、属性について交渉するために委託リソースを使用する。

本願のさらなる側面は、コンピュータ実装ネットワークを説明する。ネットワークは、交渉側と、被交渉側とを含む。交渉側および被交渉側の各々は、データを送信ならびに受信するための送受信機を含む。交渉側および被交渉側の各々は、サービス層属性について交渉するためのその上に記憶された命令とともに交渉サービス層を有する不揮発性メモリも含む。交渉側および被交渉側の各々は、サービス層属性の交渉を行うように構成されている、不揮発性メモリに動作可能に結合されるプロセッサも含む。ある実施形態によると、交渉側および被交渉側のメモリは、交渉リソース、ポリシリソース、委託リソース、およびそれらの組み合わせから選択されるリソースを含む。

その詳細な説明がより深く理解され得るために、かつ当該技術に対する本願の寄与がより明確に認識され得るために、本発明のある実施形態が、かなり大まかに上記で概説されている。

本願のより確実な理解を促進するために、ここで、類似要素が類似数字で参照される、付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。
図１は、サービス層をサポートするプロトコルスタックを図示する。 図２は、共通サービスエンティティ（ＣＳＥ）および共通サービス機能（ＣＳＦ）を図示する。 図３Ａは、ｏｎｅＭ２Ｍサービス層アーキテクチャを図示する。 図３Ｂは、Ｍ２Ｍサービスコンポーネントアーキテクチャを図示する。 図４Ａは、マシンツーマシン（Ｍ２Ｍ）またはＩｏＴ通信システムの実施形態を図示する。 図４Ｂは、Ｍ２Ｍサービスプラットフォームの本願の実施形態を図示する。 図４Ｃは、例示的Ｍ２Ｍデバイスの系統図の本願の実施形態を図示する。 図４Ｄは、例示的コンピュータシステムのブロック図の本願の実施形態を図示する。 図５Ａは、本願のある側面による、交渉サービスを用いる動的サービスのアーキテクチャの図を図示する。 図５Ｂは、本願のある側面による、交渉ポリシを構成および表示するためのグラフィカルユーザインターフェースを図示する。 図６は、本願のある側面による、個々の交渉要求のためのサービス交渉プロトコルを図示する。 図７は、本願のある側面による、被交渉側において提案を行うための決定クエリを図示する。 図８は、本願のある側面による、交渉側において提案を選択するための決定クエリを図示する。 図９は、本願のある側面による、複数の交渉要求のためのサービス交渉のフローチャートを図示する。 図１０は、本願のある側面による、透過モードにおけるブローカベースのサービス交渉のフローチャートを図示する。 図１１は、本願の別の側面による、交渉の代理としてのブローカベースのサービス交渉のフローチャートを図示する。 図１２は、本願の別の側面による、認証および承認プロトコルを用いたブローカベースのサービス交渉のフローチャートを図示する。 図１３は、本願の別の側面による、交渉要求の組み合わせを用いるブローカベースのサービス交渉のフローチャートを図示する。 図１４は、本願の別の側面による、ブローカベースのサービス委託のフローチャートを図示する。 図１５は、ＣＳＦビットマップの例示的実施形態を図示する。 図１６は、ＣＳＦ特徴ビットマップの例示的実施形態を図示する。 図１７は、本願のある側面による、交渉サービス（ＮＧＳ）を含むｏｎｅＭ２Ｍアーキテクチャを図示する。 図１８は、本願のある側面による、ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲＯＡ）におけるＮＧＳ ＣＳＦを図示する。 図１９は、本願の別の側面による、ｏｎｅＭ２Ｍ ＲＯＡにおけるＮＧＳ ＣＳＦを図示する。 図２０は、本願のある側面による、ｏｎｅＭ２Ｍ＜ｎｇｔｎ＞リソースの構造を図示する。 図２１は、本願のある側面による、ｏｎｅＭ２Ｍ＜ｎｇｔｎＰｏｌｉｃｙ＞リソースの構造を図示する。 図２２は、本願のある側面による、ｏｎｅＭ２Ｍ＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞リソースの構造を図示する。 図２３は、本願のある側面による、ＭＮ−ＣＳＥとＩＮ−ＣＳＥとの間のサービス交渉の例示的実施形態を図示する。 図２４は、ｏｎｅＭ２Ｍサービス指向アーキテクチャ（ＳＯＡ）の中へ追加された交渉サービスの例示的実施形態を図示する。

発明を実施するための形態が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な実施例を提供するが、詳細は、実施例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。

本明細書における「一実施形態」、「ある実施形態」、「１つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。本明細書内の種々の場所における「実施形態」という用語は、必ずしも同一の実施形態を指しているわけでもない。つまり、いくつかの実施形態によって提案され得るが、他の実施形態によって提案されない、種々の特徴が説明される。

本願は、サービスノードおよびアプリケーションが他のサービスノードまたはアプリケーションからサービスを動的に要求すること、およびそれを調節することに役立つ、サービス層における交渉サービス（ＮＧＳ）等の新しい機能を用いるための技法を説明する。一実施形態では、交渉サービスによると、交渉側は、交渉要求を発行するＭ２Ｍエンティティであり、被交渉側は、交渉要求を受信し、提案を提供するＭ２Ｍエンティティである。被交渉側は、提案を行い、交渉側は、事前構成された交渉ポリシに基づいて、提案を選択する。これらのポリシベースの交渉プロセスは、Ｍ２Ｍシステムによく適しており、種々のサービスは、そのようなポリシベースの共通サービス機能を使用して、交渉されることができる。そのような機能は、提案を行うことと、異なるサービスについて交渉するために好適な提案を選択することとを含む。

一側面では、交渉側は、交渉プロセスを促進し、制約付きＭ２Ｍデバイスにとって特に有益である交渉オーバーヘッドを削減することに役立つ、ある提案を能動的に提案することができる。加えて、被交渉側は、交渉プロセス中、他の被交渉側を推奨することができ、それは、交渉成功率を向上させ、それはまた、全体的な交渉信号伝達オーバーヘッドを削減し得る。被交渉側は、全ての交渉側を満たすためのより知的な提案を行うために、複数の交渉側からの要求を組み合わせることもできる。

別の側面では、交渉ブローカは、交渉側および／または被交渉側の代理の役割を果たすことができるＭ２Ｍエンティティである。交渉ブローカは、交渉側と被交渉側との間で交渉関連メッセージを転送することもできる。これは、交渉タスクを交渉ブローカにオフロードすることによって、制約付きデバイスにおける交渉オーバーヘッドを軽減することに役立つ。一実施形態によると、交渉ブローカが対応する被交渉側を自動的に選定し得る、透過モードが説明される。透過モードにおいて、交渉ブローカは、制約付きＭ２Ｍデバイス（すなわち、交渉側）が被交渉側を自動的に選定することに役立ち得る。したがって、制約付きＭ２Ｍデバイスは、被交渉側の識別を把握する必要がない。透過モードでは、交渉ブローカは、制約付きＭ２Ｍデバイス（すなわち、交渉側）が被交渉側を自動的に選定することに役立つことができる。したがって、制約付きＭ２Ｍデバイスは、被交渉側を把握する必要がない。

代理モードにおいて、交渉ブローカは、交渉タスクを行う（例えば、提案を行う、提案を選択する）制約付きＭ２Ｍデバイスの代理の役割を果たすことができる。制約付きＭ２Ｍデバイスは、交渉結果を受信することのみを必要とする。提案されるブローカベースの交渉アプローチは、制約付きＭ２Ｍデバイスがより容易な様式で交渉を行うことに役立つ。このアプローチは、制約付きデバイスへ／からの通信オーバーヘッドを軽減することができる。

別の実施形態では、交渉ブローカが被交渉側の代わりに提案を行う、被交渉側のための代理が説明される。代理モードでは、交渉ブローカは、交渉タスクを行う（例えば、提案を行う、提案を選択する）制約付きＭ２Ｍデバイスの代理の役割を果たすことができる。

別の実施形態では、交渉ブローカ委託が、１つの交渉ブローカから別の交渉ブローカに交渉機能を委託するために提案される。被交渉側を推奨するための提案されるアイデアは、交渉成功率を向上させ、それにしたがってオーバーヘッドを削減することに役立つことができる。ある側面によると、複数の交渉要求を組み合わせて処理するための提案されるアイデアは、種々のＭ２Ｍアプリケーションからの交渉要求を共同で処理することができ、ひいては、交渉成功率を向上させ、交渉オーバーヘッドを低減させることに役立つ。

（サービス層）
プロトコルスタックの観点から、サービス層は、典型的には、アプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。したがって、サービス層は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図１は、ＩＰネットワークスタックとアプリケーションとの間の例示的サービス層を示す。

Ｍ２Ｍサービス層は、Ｍ２Ｍ型デバイスおよびアプリケーションのための付加価値サービスを提供することに向けて特に標的化された１つのタイプのサービス層の実施例である。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍは、インターネット／ウェブ、セルラー、企業、ならびにホームネットワーク等の展開へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に関連付けられる課題に対処するためのＭ２Ｍサービス層を開発している。

Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ指向能力の集合へのアクセスをアプリケーションおよびデバイスに提供することができる。いくつかの実施例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含むが、それらに限定されない。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージ形式、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。

（ＯｎｅＭ２Ｍサービス層アーキテクチャ）
ＯｎｅＭ２Ｍは、共通Ｍ２Ｍサービス層に対する必要性に対処する技術仕様を開発するための新しい規格であり、共通Ｍ２Ｍサービス層は、種々のハードウェアおよびソフトウェア内に容易に組み込まれ、現場の多種多様なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために依拠されることができる。

ｏｎｅＭ２Ｍ共通サービス層は、図２に示されるように、共通サービス機能（ＣＳＦ）、すなわち、サービス能力の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード、例えば、インフラストラクチャノード、中間ノード、特定用途向けノード上にホストされることができる共通サービスエンティティ（ＣＳＥ）と称される。ＯｎｅＭ２Ｍは、図３Ａに示されるリソース指向アーキテクチャ（ＲＯＡ）および図３Ｂに示されるサービス指向アーキテクチャ（ＳＯＡ）と呼ばれる２つのアーキテクチャのアプローチでサービス層を開発している。

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

ＳＯＡアーキテクチャは、ＲＥＳＴｆｕｌベースでない旧来の展開を考慮するように開発されている。図３Ｂに示されるように、それは、大部分は同一のサービス層機能アーキテクチャを再利用する。サービス層は、種々のＭ２Ｍサービスを含み、複数のサービスが、サービスコンポーネントにグループ化されることができる。既存の参照点に加えて、それは、サービス間参照点Ｍｓｃを導入する。Ｍｓｃ参照点を経由してパスされるＭ２Ｍサービスコンポーネント間の通信は、ウェブサービスアプローチ、例えば、ウェブサービスメッセージ交換パターン（ＭＥＰ）を利用する。

（ＯｎｅＭ２Ｍ ＣＳＦ）
Ｍ２ＭサーバまたはエンドポイントＭ２Ｍデバイス等のＣＳＥによって、他のＣＳＥもしくはＡＥに提供されることができる、以下の１２個のＣＳＦが、現在、ｏｎｅＭ２Ｍで定義されている。これらは、図２に示されている。

アプリケーションおよびサービス層管理（ＡＳＭ）：ＣＳＥならびにＡＥの機能を構成、トラブルシュート、およびアップグレードする管理能力を提供する。

通信管理および配信取扱（ＣＭＤＨ）：通信、例えば、ＣＳＥ間通信を配信するための具体的通信接続を使用すべきとき、必要かつ許可される場合、後に転送されることができるように通信要求をバッファリングするときを決定する。

データ管理およびリポジトリ（ＤＭＲ）：データ記憶および仲介機能を提供する責任がある。それは、大量のデータを集約し、このデータを規定形式に変換し、分析およびセマンティック処理のためにそれを記憶する目的で、データを収集する能力を含む。

デバイス管理（ＤＭＧ）：ＭＮ（例えば、Ｍ２Ｍゲートウェイ）、ＡＳＮおよびＡＮＤ（例えば、Ｍ２Ｍデバイス）、ならびにＭ２Ｍエリアネットワーク内に常駐するデバイスについてのデバイス能力の管理を提供する。

発見（ＤＩＳ）：属性およびリソースに含まれるようなアプリケーションならびにサービスについての情報を検索する。

グループ管理（ＧＭＧ）：グループ関連要求を取り扱う責任がある。要求は、グループおよびそのメンバシップを管理するために、ならびにグループによってサポートされる一括動作のために送信される。

場所（ＬＯＣ）：ＡＥが場所ベースのサービスのためのノード（例えば、ＡＳＮ、ＭＮ）の地理的場所情報を取得することを可能にする。

ネットワークサービスエクスポージャ、サービス実行、およびトリガ（ＮＳＳＥ）：Ｍｃｎ参照点を経由してネットワークサービス機能にアクセスするための下層ネットワークとの通信を管理する。

登録（ＲＥＧ）：登録されたエンティティがレジストラＣＳＥによって提供されるサービスを使用することを可能にするために、ＡＥまたは別のＣＳＥからのレジストラＣＳＥに登録する要求を処理する。

セキュリティ（ＳＥＣ）：極秘データ取扱、セキュリティ管理、セキュリティ関連付け確立、識別／認証／承認を含むアクセス制御、および識別管理等の機能性を備えている。

サービス課金および会計（ＳＣＡ）：サービス層のための課金機能を提供する。これは、オンラインリアルタイムクレジット制御も含む、異なる課金モデルをサポートする。

サブスクリプションおよび通知（ＳＵＢ）：リソース上の変更、例えば、リソースの委託を追跡する、サブスクリプションに関する通知を提供する。

（サービス層交渉）
以下の既存サービスおよび／またはプロトコルが、サービス層交渉で使用されることができる：
交渉要求承認：交渉サービスは、関連コンテキスト、ならびに過去の要求および交渉結果の履歴に基づいて、要求側からの交渉要求を受理すべきかどうかを決定することができる。交渉サービスは、交渉の緊急性に基づいて、要求の優先順位を設定することもできる。

交渉関係者制御：交渉サービスは、交渉を行うべき相手を決定することができる。交渉関係者は、要求側によって知らされるか、または利用可能なＩｏＴサービスプロバイダ等における発見結果に基づいて認知能力によって決定されることができる。

交渉計画制御：交渉サービスは、要求側の代わりに交渉計画を選定することができる。交渉サービスは、常に、要求側の入力交渉目標に基づいて、要求側の最善の利益を考慮する。

交渉適合：交渉サービスは、ポリシ変更またはコンテキスト変更に起因して適合され得る。交渉サービスポリシは、コンテキスト、ソフトウェア定義設定、および他のサービスからの入力等のものに基づいて、動的に適合されることができる。ポリシの動的適合を介して、順に、決定が動的に適合されることができる。コンテキスト認識サービスは、交渉適合のために交渉サービスに関連コンテキストを動的に更新し得るか、または交渉サービスは、コンテキスト認識サービスから関連コンテキストを先を見越して読み出すことができる。

交渉一般化：交渉サービスは、過去の交渉プロセスから要約される一般化された共通交渉計画を作成することができ、それは、後に交渉要求側によって使用され、各要求側のための交渉計画を決定することにおける認知能力のオーバーロードを減少させ得る。

交渉サブスクリプション：任意の適合が加入者に通知されることができるように、交渉結果へのサブスクリプションが提供される。このサブスクリプション機構は、自律適合を可能にする。加入者が、加入するものの同一交渉結果を使用している場合、加入交渉結果への任意の変更が、それを自動的に適合するように加入者をトリガすることができる。交渉サブスクリプションがないと、他のエンティティは、交渉結果を再利用し、それに従うことができない。本開示はまた、提案される知的交渉サービスのコンポーネント、ならびに他のＩｏＴサービス、ＩｏＴエンティティ、およびＩｏＴアプリケーションへのインターフェースも説明する。

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

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

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

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

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

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

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保険および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の産業での用途を含み得る。上記のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能に、Ｍ２Ｍアプリケーション２０および２０’を提供する。また、Ｍ２Ｍサービス層はまた、本願で議論され、図に図示されるように、ＵＥ、ＳＣＳ、およびＭＭＥ等の他のデバイスとインターフェースをとるように構成され得る。

本願で議論されるようにサービスを動的に要求する方法は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、ＵＥ ＰＳＭモードを制御および協調する方法を含み得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、トラックを確保する方法を含み得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）、例えば、サービス能力の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード、例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード等の上にホストされ得る、ＳＣＳ等の共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願で説明されるような交渉側と被交渉側との間でサービスについて交渉する方法は、本願による、サービスを動的に要求するためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

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

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。

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

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

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

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

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。ディスプレイ８６は、組み込みセマンティック名を使用して、ファイルまたはフォルダ内の感覚データを表示し得る。さらに、コンピュータシステム９０は、図４Ａおよび４Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

本願のある側面によると、ＮＧＳは、Ｍ２Ｍエンティティが、さらなる柔軟性で動的かつ効率的にサービスを要求することを可能にする。例えば、図５Ａは、どのようにしてＮＧＳが３つのシナリオをサポートすることができるかを図示する。ＮＧＳは、それらのサービス層の新しい機能として、Ｍ２ＭデバイスおよびＭ２Ｍサーバの両方の中に常駐する。「シナリオ１」として示される、例示的実施形態では、Ｍ２ＭデバイスのＮＧＳは、それらの間にあるようなサービス交渉を果たすように、Ｍ２ＭサーバのＮＧＳと相互作用する。「シナリオ２」として示される、別の例示的実施形態では、Ｍ２Ｍ Ａｐｐ Ａ（またはＡｐｐ Ｂ）は、Ｍ２Ｍ Ａｐｐ Ａ（またはＡｐｐ Ｂ）による要求に応じて、サービスについて交渉するようにＭ２ＭサーバのＮＧＳと通信する。「シナリオ３」として示される、さらなる例示的実施形態では、Ｍ２Ｍ Ａｐｐ ＡおよびＭ２Ｍ Ａｐｐ Ｂは、Ｍ２Ｍサーバを介して互いにサービスについて交渉する。すなわち、両方のアプリケーションが、Ｍ２ＭサーバのＮＧＳと通信し、それは、ひいては、両方のアプリケーションがサービス交渉を行うことに役立つ。

一実施形態では、例えば、図５Ｂに示されるようなグラフィカルユーザインターフェース（ＧＵＩ）が、Ｍ２Ｍデバイス、ゲートウェイ、またはサーバにおいて交渉ポリシを構成／表示するために使用されることができる。例えば、ＧＵＩは、交渉ポリシの構成を表示するためのテキストボックスを含む、領域を含み得る。ＧＵＩはまた、交渉ポリシおよび結果を表示するためのテキストボックスを含む、領域を含み得る。例示的実施形態では、ユーザは、タッチスクリーンインターフェースを介してＧＵＩと相互作用することができる。

（個々の交渉要求のためのプロシージャ）
ある実施形態によると、図６は、個々の交渉要求のためのサービス交渉プロセスを図示する。図６のステップの各々は、ローマ数字によって表される。被交渉側Ａは、交渉側に交渉可能なサービスを示すか、または通知する。ここでは、交渉可能なサービスは、その特徴または構成が動的に交渉され、異なるＭ２Ｍエンティティに提供されることができる場合の任意のサービスとして定義される。例えば、Ｍ２Ｍサーバによって提供されるデータ管理サービスは、異なるＭ２Ｍデバイスの記憶サイズおよび課金率が動的に交渉されて割り付けられることができる場合、交渉可能である。しかしながら、Ｍ２Ｍサーバによって提供される登録サービスは、各Ｍ２Ｍデバイスが常に、Ｍ２Ｍサーバに関連付けるために同一の登録サービスを使用する必要がある場合、交渉可能ではないであろう。

交渉側は、被交渉側Ａと提案される交渉プロセスを行う。交渉側は、一実施形態では、サービスの組について交渉し得る。別の実施形態では、交渉側は、特定のサービスの特徴について交渉し得る。この交渉プロセスから２つの結果が生じる：１）交渉側および被交渉側Ａが、合意に達する、または、２）被交渉側Ａが、交渉側の要件を満たすことができず、別の被交渉側、例えば、被交渉側Ｂを推奨する。交渉プロセスの一部として、交渉側は、随意に、被交渉側Ａによって認証され得、随意に、被交渉側Ａは、交渉側によって認証され得る。認証プロセスの一部として、交渉側および被交渉側Ａは、事前構成された証明書を使用して認証され得る。追加の証明書、例えば、メッセージ認証／完全性保護のためのキーが提供され得、それは、交渉側と被交渉側Ａとの間の将来のメッセージ交換中に認証目的で使用され得る。交渉側および／または被交渉側のいずれか一方によるキーの保有を確実にすることは、１つの形態の暗示的認証であり得る。随意に、交渉されたサービスにアクセスするために使用されることができる承認証明書が、交渉側にプロビジョンされ得る。

上で議論される代替実施形態によると、被交渉側Ａと合意を有していない場合、交渉側は、被交渉側Ａによって推奨されるような別の被交渉側Ｂと交渉を行い得る。交渉側と被交渉側Ａとの間の認証プロセスまたは随意の相互認証プロセスと同様に、認証および承認プロセスが、交渉側と被交渉側Ｂとの間で実行され得る。

図７のステップの各々は、ローマ数字によって表される。例えば、ステップ０−１では、交渉側が、「交渉可能なサービスへのサブスクリプション」を被交渉側Ａに発行する。結果として、交渉側は、サービスが交渉可能になる場合、ステップ０−２で被交渉側Ａから自動通知を受信するであろう。これは、その部分的または全体的特徴／機能性が、動的に要求、変更、および／または構成され得ることを意味する。交渉側は、このステップで、標的サービスのリスト等の種々のサブスクリプション基準を備え得る。サブスクリプション基準はまた、現在交渉可能ではない場合がある特徴を含み得る。代替として、交渉側は、例えば、ＲＥＳＴｆｕｌ ＲＥＴＲＩＥＶＥ動作を使用して、被交渉側Ａにおいて交渉可能なサービスのリストを発見するか、または読み出すために、具体的メッセージを被交渉側に送信することができる。したがって、被交渉側Ａは、それが提供する交渉可能なサービスのリストで交渉側に応答するであろう。

ある後の段階で、そのサービスのうちのいずれかが交渉可能になり、変更が０−１におけるサブスクリプション基準を満たす場合、被交渉側Ａは、「交渉可能なサービスについての通知」メッセージを交渉側に送信する。このメッセージの目的は、被交渉側Ａにおける交渉可能なサービスのリストを交渉側に知らせることである。このメッセージは、以下の情報を含み得る：
ＬｉｓｔＯｆＮｅｇｏｔｉａｂｌｅＳｅｒｖｉｃｅ：各交渉可能なサービスの名称、識別子、および／または説明、例えば、ＳｅｒｖｉｃｅＩＤを含む。各交渉可能なサービスに対して、被交渉側Ａは、サービスのうちのどの特徴が交渉可能であるかと、サービスおよびその特徴が利用可能になるであろう期間とを示し得る。被交渉側Ａはまた、各交渉可能なサービスのための交渉側からの予期される入力を規定し得る。

次に、ステップ１では、交渉側が、交渉を開始するための「交渉要求」メッセージを被交渉側Ａに送信する。このメッセージは、以下の情報を含み得る：
ＳｅｒｖｉｃｅＩＤ：被交渉側Ａと交渉されるべきサービスの名称、識別子、および／または説明。交渉されるべき各サービスに対して、交渉側は、このサービスの１つ以上の特徴について交渉することを明示的に要求し得る。交渉側は、ステップ０−２からこの情報を把握することができるであろう。例えば、サービスＩＤは、交渉側がより多くまたは高速の記憶容量を獲得したいことを示し得る：
ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎ：交渉側が、必要な入力を提供し、それは、ステップ２で提案を行うために被交渉側Ａによって活用されるであろう。基本的に、このステップでは、被交渉側Ａは、各交渉ポリシの適用可能性をチェックするために、このパラメータを使用して、各交渉ポリシの中の「条件」パラメータに対して比較する。交渉側は、ステップ０−２からどんな入力情報が提供されるべきかを把握することができるであろう。例えば、サービスＩＤが、交渉側がより多くおよび／または高速の記憶容量を獲得したいことを示す場合、ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎＩＤは、どれだけの記憶が必要とされるか、またはどのような記憶のアクセス速度が必要とされるかを示し得る：
ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓ：交渉側は、ある提案を被交渉側Ａに提案し得、これは、被交渉側Ａにおける動作を単純化し、交渉プロセスを促進することに役立ち得る。基本的に、ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓパラメータは、被交渉側Ａで維持される各交渉ポリシの中の「結果」パラメータの同一の意味を有する。ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓは、交渉側が容認可能と見出すであろう、サービスの実施例を表す。

次いで、ステップ２では、被交渉側Ａが、そのローカルポリシに基づいて提案を行うための入力として、ステップ１からの情報をとる。このステップの出力は、ステップ３で交渉側に送信されるＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓである。図７は、どのようにして被交渉側がこれらの提案を行うことに取り掛かり得るかについてのプロシージャを提供する。被交渉側Ａは、そのポリシをチェックすることなく、またはいかなる適用可能なポリシもない場合、単純に交渉側からＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓを受理し得ることに留意されたい。

次に、ステップ３では、被交渉側Ａが、「交渉応答」メッセージを交渉側に送信する。このメッセージは、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓを含む。このパラメータは、交渉側への複数の提案を含み得るか、または現在行われている交渉ラウンドの数が被交渉側Ａにおける事前構成された閾値を超える場合、単純に別の被交渉側Ｂを示し得る。被交渉側ＡおよびＢが、同一のサービスドメイン内に常駐し得ることに留意されたい。被交渉側Ａはまた、把握している場合、被交渉側ＢにおけるＬｉｓｔＯｆＮｅｇｏｔｉａｂｌｅＳｅｒｖｉｃｅｓを示し得、例えば、被交渉側Ａおよび被交渉側Ｂは、前もってステップ０−１およびステップ０−２を行い、互いの交渉可能なサービスを把握し得る。ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓが別の被交渉側Ｂのみを含む場合、交渉側は、現在の交渉を中止し、直接、被交渉側Ｂと新しい交渉プロセスを開始するであろう。この場合、ステップ４、ステップ５、およびステップ６は、省略されるであろう。

「交渉応答」メッセージを受信した後、交渉側は、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓに満足していない場合、別の交渉ラウンドを開始するためにステップ１を繰り返し得る。そうでなければ、交渉側は、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓに含まれる、ある提案に満足している場合、ステップ４を行う。繰り返されるステップ１では、交渉側は、ＳｅｒｖｉｃｅＩＤ、ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎ、およびＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓの新しいパラメータ値を提出し得る。

ステップ４では、交渉側が、それが維持する交渉ポリシに基づいて、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓから適切な提案を選択する。交渉側は、そのポリシをチェックすることなく、またはいかなる適用可能なポリシもない場合、単純に受信されたＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓを選定し得ることに留意されたい。ステップ５では、交渉側が、「交渉確認」メッセージを被交渉側Ａに送信する。このメッセージは、ステップ４からのＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓおよびＳｅｒｖｉｃｅＩＤを含む。ＳｅｒｖｉｃｅＩＤは、ステップ１におけるものと同一またはその一部であり得る。ステップ６では、被交渉側Ａが、「確認応答」メッセージを交渉側に送信し得る。結果として、交渉側および被交渉側Ａは、交渉されているサービスについて合意に達する。交渉側は、繰り返される交渉ラウンド、すなわち、繰り返されるステップ１、２、および３の最大数の閾値を設定し得る。代替として、被交渉側Ａは、繰り返される要求、すなわち、ステップ１の数が、事前構成された閾値より大きい場合、交渉側の要求を拒否し得る。行われた交渉ラウンドの数がこの閾値を超える場合、および交渉側と被交渉側Ａ（またはＢ）との間に依然としていかなる合意もない場合、交渉側は、交渉プロセスを停止し得るか、またはその交渉ポリシを変更し得る。別の実施形態によると、ユーザが決定を行っている場合、いかなるポリシも採用されないことが想定される。

図７は、どのようにして被交渉側が提案を行い得るか、例えば、図６のステップ２を図示する。被交渉側は、提案を行うためにポリシベースのアプローチを使用する。つまり、被交渉側は、全ての交渉可能なサービスのためのある交渉ポリシを維持する。各交渉ポリシは、以下の情報またはパラメータを有し得る：
ＳｅｒｖｉｃｅＩＤ：この交渉ポリシが適用可能であるサービスの名称、識別子、および／または説明を示す
Ｃｏｎｄｉｔｉｏｎ：この交渉ポリシが適用されることができる状況を示す
Ｒｅｓｕｌｔｓ：「条件」が満たされた場合に作成される提案を示す
Ｎｅｇｏｔｉａｔｏｒ：この交渉ポリシが適用可能である交渉側のリストを示す。ポリシ実施例が、表１で挙げられる。例として、被交渉側としての機能を果たすＭ２Ｍサーバは、より柔軟なデバイス管理サービスを提供するために、これらのポリシを維持し得る。これらのポリシは、Ｍ２Ｍサーバ自体によって、または特殊な管理者アプリケーションによって作成され得る。

以下のステップは、被交渉側が提案を行うために必要とされる。被交渉側は、全ての潜在的提案を取得するように、受信された「交渉要求」の中のパラメータ値を、そのローカル交渉ポリシと比較するための入力としてとる。ポリシが適用可能である場合、例えば、「ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎ」がポリシの中の「条件」に一致する場合、ポリシの「結果」は、潜在的提案であろう。ポリシ候補が図７でチェックされるが、被交渉側は、随意に、ある数のポリシ候補をチェックし得ることが想定される。図７のステップの各々は、ローマ数字によって表される。

ステップ１では、被交渉側が、受信された「交渉要求」メッセージを入力としてとる。このメッセージは、３つのパラメータ、すなわち、ＳｅｒｖｉｃｅＩＤ、ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎ、およびＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓを含むことに留意されたい。ステップ２では、被交渉側が、現在の「交渉要求」のためにそのローカル交渉ポリシデータベースからポリシ候補を見つけるために、「ＳｅｒｖｉｃｅＩＤ」を使用する。ローカルポリシは、「ＳｅｒｖｉｃｅＩＤ」が「交渉要求」に含まれる「ＳｅｒｖｉｃｅＩＤ」を対象にする場合、ポリシ候補になる。被交渉側は、ポリシをフィルタ処理するために、およびポリシ候補リストをより正確にするために、「交渉側」情報を使用し得る。このステップの出力は、受信された「交渉要求」に潜在的に適用可能なあるポリシを含むポリシ候補の組である。ポリシは、事前プロビジョンされた証明書に基づいて、被交渉側が交渉側を認証するかどうかを決定付け得る。交渉側は、随意に、同様に被交渉側を認証し得る。

ステップ３によると、被交渉側は、ステップ２で見出される任意のポリシ候補があるかどうかをチェックする。「はい」である場合、ステップ４に移動することができ、そうでなければ、ステップ１３に進む。ステップ４では、被交渉側は、ステップ２で発見されるようなポリシ候補の組の中の第１のポリシとして、ＣｕｒｒｅｎｔＰｏｌｉｃｙを設定する。そして、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓを空に設定する。ステップ５では、被交渉側は、ＣｕｒｒｅｎｔＰｏｌｉｃｙが現在の「交渉要求」へのその適用可能性について決定を行うことをチェックする。ステップ６では、ＣｕｒｒｅｎｔＰｏｌｉｃｙが適用可能であるかどうか、チェックが行われる。もしそうであれば、被交渉側は、提案を行うためにステップ７に進む。そうでなければ、被交渉側は、いずれかが利用可能である場合、次のポリシをチェックするためにステップ９に移動する。例えば、候補ポリシは、期限切れになるか、または交渉側のために許可されない。

ステップ７によると、被交渉側が、ＣｕｒｒｅｎｔＰｏｌｉｃｙに基づいて提案を行う。ステップ７．１では、ＮＧＳが、ＩｎｐｕｔＦｏｒＭａｋｅＳｕｇｇｅｓｔｉｏｎをＣｕｒｒｅｎｔＰｏｌｉｃｙの「条件」と比較する。両方が互いに一致する場合、ＣｕｒｒｅｎｔＰｏｌｉｃｙが適用されるであろう。そうでなければ、ＣｕｒｒｅｎｔＰｏｌｉｃｙは、提案を行うことに影響を及ぼさない。「条件」は、被交渉側のローカルコンテキスト情報に関連するある情報を含み得る。この場合、被交渉側はまた、「条件」に対してその現在のコンテキスト情報をチェックし得る。

ステップ７．２では、ＣｕｒｒｅｎｔＰｏｌｉｃｙの「結果」が、ｎｅｗＳｕｇｇｅｓｔｉｏｎｓとして選ばれるであろう。ステップ７．３では、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓが、単純に、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓ上にｎｅｗＳｕｇｇｅｓｔｉｏｎｓを追加することであり得る関数ｆ（ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓ，ｎｅｗＳｕｇｇｅｓｔｉｏｎ）に従って更新されるであろう。ステップ７．４では、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓへの変更がない。

次に、ステップ８では、被交渉側は、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓが交渉側からの「ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓ」を含むかどうかをチェックする。「はい」である場合、ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓは、「ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓ」として設定されるであろう（ステップ１３）。ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓとＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓとの共通部分は、交渉側のための最終ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓとして選定されるであろう。

提案を行うプロセスが終了する。「いいえ」である場合、ステップ９は、他のポリシ候補をチェックする。被交渉側は、単純に、交渉側のＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓを無視し得る。

ステップ９では、被交渉側が、ＣｕｒｒｅｎｔｔＰｏｌｉｃｙがポリシ候補の組の中の最後のポリシであるかどうかをチェックする。「いいえ」である場合には、ポリシ候補の組の中の次のポリシが、ＣｕｒｒｅｎｔｔＰｏｌｉｃｙとして選定されるであろう（ステップ１０）。そして、プロセスは、ステップ５に戻る。

「はい」である場合、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓが空であるかどうか、チェックが行われる。「いいえ」である場合、出力は、提示された提案（ステップ１２）である。「はい」である場合、被交渉側は、ポリシのうちのどれも受信された「交渉要求」に適用可能ではないことを見出し、別の被交渉側を交渉側に推奨し得る（ステップ１４）。

（交渉側において提案を選択する）
図８は、交渉側によって行われる提案を選択することの詳細を図示する。これは、図６のステップ４に関連する。本開示では、交渉側が提案を選択するためにポリシベースのアプローチを使用することが提案される。基本的に、交渉側は、ある交渉ポリシを維持する。各交渉ポリシは、以下の情報またはパラメータを有し得る：
ＳｅｒｖｉｃｅＩＤ：この交渉ポリシが適用可能である、サービスの名称、識別子、および／または説明を示す
Ｃｏｎｄｉｔｉｏｎ：この交渉ポリシが適用されることができる状況を示す。例えば、条件は、交渉されているサービスがどのようなプロトコルを使用するかを含み得るか、または示し得る
Ｒｅｓｕｌｔｓ：「条件」が満たされる場合に選択されるべき提案を示す
Ｎｅｇｏｔｉａｔｅｅ：この交渉ポリシが適用可能である被交渉側のリストを示す。

いくつかのポリシ実施例が、表２で挙げられる。例として、交渉側としてのＭ２Ｍデバイスが、より柔軟なデバイス管理サービスを要求するために、これらのポリシを維持し得る。これらのポリシは、Ｍ２Ｍデバイス上のアプリケーションによって、または特殊管理者アプリケーションによって作成されることができる。交渉側は、上で議論される類似プロシージャに従うことによって、ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓを取得するために、これらのポリシを使用することもできる。

以下のステップは、交渉側が図８の提案を選択するために必要とされる。交渉側は、適切な提案を選択するために、受信された「交渉応答」の中のパラメータ値を、そのローカル交渉ポリシと比較するための入力としてとる。ポリシが適用可能である場合、例えば、「ＩｎｐｕｔＦｏｒＳｅｌｅｃｔＳｕｇｇｅｓｔｉｏｎ」がポリシの中の「条件」に一致する場合、ポリシの「結果」は、ＳｅｌｅｃｔｅｄＳｕｇｇｅｔｉｏｎｓであろう。全てのポリシ候補が図８でチェックされるが、交渉側は、随意に、ある数のポリシ候補のみをチェックし得る。

ステップ１では、交渉側が、以下のパラメータを入力としてとる：
被交渉側からの「交渉応答」メッセージの中で受信されたＳｅｒｖｉｃｅＩＤ
被交渉側からの「交渉応答」メッセージの中で受信されたＯｆｆｅｒｅｄＳｕｇｇｅｔｉｏｎｓ
交渉側によって決定および維持されるローカルパラメータであるＩｎｐｕｔＦｏｒＳｅｌｅｃｔＳｕｇｇｅｔｉｏｎ。このパラメータは、ポリシ依存性であることに留意されたい。表２のポリシに対して、ＩｎｐｕｔＦｏｒＳｅｌｅｃｔＳｕｇｇｅｔｉｏｎは、「管理されるデバイスの数」であろう。交渉側は、適切な提案を決定して選択するために、このパラメータを各ポリシ候補の「条件」に対して比較する。

次に、ステップ２では、交渉側が、そのローカル交渉ポリシデータベースからポリシ候補を見つけるために、「ＳｅｒｖｉｃｅＩＤ」を使用する。ローカルポリシは、「ＳｅｒｖｉｃｅＩＤ」がステップ１における「ＳｅｒｖｉｃｅＩＤ」を対象にする場合、ポリシ候補になる。交渉側はさらに、より無関係のポリシを除外するために、「被交渉側」情報を使用し得る。このステップの出力は、受信された「交渉応答」に潜在的に適用可能なあるポリシを含む、ポリシ候補の組である。

ステップ３では、交渉側が、ステップ２で見出される任意のポリシ候補があるかどうかをチェックする。「はい」である場合、プロシージャは、交渉側が、ステップ２で見出されるようなポリシ候補の組の中の第１のポリシとしてＣｕｒｒｅｎｔＰｏｌｉｃｙを設定するステップ４に移動する。そして、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓを空の組に設定する。そうでなければ、ステップ１１に進む。

ステップ５では、交渉側が、現在の「交渉応答」へのその適用可能性についてＣｕｒｒｅｎｔＰｏｌｉｃｙをチェックする。ステップ６では、ＣｕｒｒｅｎｔＰｏｌｉｃｙが適用可能である場合、交渉側は、ＣｕｒｒｅｎｔＰｏｌｉｃｙに基づいて提案を選択するためにステップ７に進む。

ステップ７．１では、ＮＧＳが、ＩｎｐｕｔＦｏｒＳｅｌｅｃｔＳｕｇｇｅｓｔｉｏｎをＣｕｒｒｅｎｔＰｏｌｉｃｙの「条件」と比較する。両方が互いに一致する場合、ＣｕｒｒｅｎｔＰｏｌｉｃｙが適用されるであろう。そうでなければ、ＣｕｒｒｅｎｔＰｏｌｉｃｙは、提案を選択することに影響を及ぼさない。「条件」は、交渉側のローカルコンテキスト情報に関連するある情報を含み得る。この場合、交渉側はまた、「条件」に対してその現在のコンテキスト情報をチェックし得る。ステップ７．２では、ＣｕｒｒｅｎｔＰｏｌｉｃｙの「結果」が、ＮｅｗＳｅｌｅｃｔｉｏｎｓとして選定されるであろう。ステップ７．３では、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓが、単純に、ＮｅｗＳｅｌｅｃｔｉｏｎｓおよびＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓの共通部分を現在のＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓに追加することであり得る、関数ｆ（ＮｅｗＳｅｌｅｃｔｉｏｎｓ，ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓ，ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓ）に従って更新されるであろう。ステップ７．４では、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓへの変更がない。

ステップ６からの返答が「いいえ」である場合、交渉側は、該当する場合、次のポリシをチェックするためにステップ８に移動する。例えば、候補ポリシは、期限切れになり得るか、または「交渉応答」を送信した被交渉側のために許可されない。ステップ８では、交渉側が、ＣｕｒｒｅｎｔｔＰｏｌｉｃｙがポリシ候補の組の中の最後のポリシであるかどうかをチェックする。「いいえ」である場合、プロシージャは、ポリシ候補の組の中の次のポリシが、ＣｕｒｒｅｎｔｔＰｏｌｉｃｙとして選定されるであろう、ステップ９に移動する。次いで、プロセスは、ＣｕｒｒｅｎｔｔＰｏｌｉｃｙをチェックするために、ステップ５に戻る。

ステップ８からの返答が「はい」である場合、交渉側が、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓが空であるかどうかをチェックするステップ１０に進む。「はい」である場合、プロシージャは、ステップ１２に移動し、交渉側は、ポリシのうちのいずれも受信された「交渉応答」に適用可能ではないことを見出す。ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓは、空であろう。交渉側は、新しい交渉ラウンドを開始し得る。そうでなければ、ステップ１０からの返答が「いいえ」である場合、ステップ１１に進む。ここで、交渉側は、全てのポリシ候補をチェックした後にこのステップに至り、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓを出力する。交渉側によって選定されるＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓは、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎの一部でないこともあり、すなわち、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓとＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎとの間にいかなる共通部分もない。この場合、交渉側は、新しい「交渉要求」を再送すること、すなわち、図６のステップ１を再開し、ＳｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓは、ＰｒｏｐｏｓｅｄＳｕｇｇｅｓｔｉｏｎｓとして新しい「交渉要求」に含まれ得る。

（複数の交渉要求のためのプロシージャ）
図６に図示されるように、被交渉側（ＡまたはＢのいずれか一方）は、各交渉要求もしくは交渉側を独立して扱う。実際に、異なる交渉側からの複数の要求を合同で考慮することによって、特に、複数の交渉側が互いに論理的に関連付けられ得る場合（例えば、同一場所から）、同一タイプのサービスを要求し得る場合、同一タイプのデバイスを有し得る場合、過去に類似交渉履歴および挙動を有し得る場合等のシナリオに対して、被交渉側は、交渉側により良好な提案を行い得る。一実施例では、同一のＳｅｒｖｉｃｅＩＤを伴う交渉要求は、合同で考慮され得る。被交渉側は、そのような組み合わせを行うために、受信された交渉要求をバッファリングし得る。被交渉側は、複数の要求が合同で考慮されるときにのみ適用可能である特殊ポリシを構成し得る。この目的のために、基本的サービス交渉のための代替的プロシージャが図９で開発され、被交渉側は、２つの交渉側ＡおよびＢからの交渉要求を合同で考慮することによって提案を行う。図９のステップの各々は、ローマ数字によって表される。

ステップ１Ａでは、交渉側Ａが、「交渉要求」を被交渉側に送信する。ステップ１Ｂでは、交渉側Ｂが、「交渉要求」を被交渉側に送信する。ステップ２では、被交渉側が、交渉側ＡおよびＢからの両方の要求を考慮して、提案を行う。被交渉側は、最初に、ＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓの２つの値を得るために、交渉側Ａおよび交渉側Ｂについて図７のプロシージャを独立して行い得る。次いで、最終的なＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓは、これら２つの値の共通部分であろう。共通部分がない場合、被交渉側は、ただ単純に、２つのＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓ値（交渉側Ａに１つ、交渉側Ｂにもう１つ）を提案し得る。

共通部分がない場合、被交渉側は、これら２つのＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓのうちの１つをとり、それを両方の交渉側に送信し得る。共通部分がない場合、被交渉側は、次回、２つのＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓの共通部分に潜在的に到達し得るように、それらの次回の交渉要求を変更するように両方の交渉側に通知し得る。

代替として、被交渉側は、最初に、交渉側Ａおよび交渉側Ｂの両方のために適用可能であるポリシを見つけ得る。そして、被交渉側は、図７の同一のプロシージャに従って、これらのポリシに基づいて提案を行う。交渉側Ａおよび交渉側ＢのためのＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓは、被交渉側がＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓを決定するために使用するポリシに応じて、異なり得る可能性が高い。

ステップ３Ａでは、被交渉側が、「交渉応答」を交渉側Ａに送信する。ステップ３Ｂでは、被交渉側が、「交渉応答」を交渉側Ｂに送信する。

ステップ４Ａでは、交渉側Ａが、ステップ３ＡにおけるＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓから提案を選択する。ステップ４Ｂでは、交渉側Ｂが、ステップ３ＢにおけるＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓから提案を選択する。ステップ５Ａでは、交渉側Ａが、「交渉確認」を被交渉側に送信する。ステップ５Ｂでは、交渉側Ｂが、「交渉確認」を被交渉側に送信する。ステップ６Ａでは、被交渉側が、「確認応答」を交渉側Ａに送信する。ステップ６Ｂでは、被交渉側が、「確認応答」を交渉側Ｂに送信する。

（ブローカベースのサービス交渉）
提案を行う、または提案を選択するプロセスは、制約付きＭ２Ｍデバイスにとって過剰に重くなり得る。この問題を解決するために、交渉ブローカが被交渉側の代わりに提案を行うこと、および／または交渉側の代わりに提案を選択することに役立つブローカベースのサービス交渉が説明される。交渉ブローカは、一方のブローカから他方のブローカに委託されることもできる。図１０および１１によると、交渉側が、交渉ブローカが取り扱うことができる交渉可能なサービスのリストについて自動通知を入手し得るように、図６に示されるようなステップ０−１およびステップ０−２が、交渉側と交渉ブローカとの間で使用されることができる。

透過モードでは、交渉ブローカは、提案を行うことも、提案を選択することもしないが、交渉側が適切な被交渉側を見出すこと、例えば（要求を、リストが要求に適合する被交渉側に転送すること、または軽い負荷を伴う被交渉側に転送すること、および、単純に、交渉関連メッセージを交渉側と被交渉側との間で転送すること）に役立つ。以下のステップが、図１０に示されるように導入される。

ステップ１では、被交渉側が、「交渉要求のためのサブスクリプション」を交渉ブローカに送信する。メッセージは、基本的に、被交渉側がＳｅｒｖｉｃｅＩＤによって表されるサービスについて交渉できることを交渉側ブローカに伝える。ステップ２では、交渉ブローカが、「応答」を被交渉側に送信する。各サービスに対して、交渉ブローカは、サービスに関心があり、それのための交渉を提供することができる被交渉側のリストを維持するであろう。そして、ステップ３では、交渉側が、「交渉要求」を交渉ブローカに送信する。ステップは、図６のステップ１と同一である。ステップ４では、交渉ブローカが、受信された「交渉要求」のための適切な被交渉側を見出すために、「交渉要求」に含まれる「ＳｅｒｖｉｃｅＩＤ」を使用する。

ステップ５によると、交渉ブローカは、ステップ１におけるサブスクリプションへの応答として、「通知」を対応する被交渉側に送信する。この通知は、実際に、「交渉要求」を転送することである。ステップ６では、被交渉側は、提案を行う。さらに、ステップ７では、被交渉側が、交渉ブローカを介して「交渉応答」を交渉側に送信する。一実施形態では、交渉ブローカは、交渉側によって設定される事前構成されたポリシに対して、提示された提案をチェックする。

交渉側は、ステップ８で提案を選択する。ステップ９では、交渉側が、交渉ブローカを介して「交渉確認」を被交渉側に送信する。ステップ１０では、被交渉側が、交渉ブローカを介して「確認応答」を交渉側に送信する。

ステップ１およびステップ２は、複数の被交渉側があり得るので、１回以上の回数で起こり得る。ステップ１および２の各組は、個々の被交渉側のためのものである。ステップ５、ステップ６、およびステップ７は、複数の被交渉側があり得るため、１回以上の回数で起こり得る。ステップ５、ステップ６、およびステップ７の各組は、個々の被交渉側のためのものである。

別の実施形態によると、図１１は、交渉ブローカが被交渉側の代理の役割を果たすシナリオを図示する。ステップ１では、被交渉側が、「交渉代理要求」を交渉ブローカに送信する。被交渉側は、このステップで、その交渉ポリシを交渉ブローカにパスし得る。被交渉側は、その交渉ブローカにおいてその交渉ポリシを作成するために、別個のプロシージャを使用し得る。

ステップ２では、交渉ブローカが、「交渉代理応答」を被交渉側に送信する。このステップは、省略され得、ステップ９が、被交渉側への最終応答であろうことに留意されたい。ステップ１および２は、被交渉側が交渉ブローカにすでに登録されているか、または関連付けられている場合、必要とされないこともあり、デフォルトで、交渉ブローカは、被交渉側のための代理機能を果たすであろう。ステップ１および２は、被交渉側と交渉ブローカとの間の発見ならびにアソシエーション段階に先行され得る。アソシエーション段階の一部として、交渉ブローカおよび被交渉側は、以降の段階で認証に使用され得る、認証証明書をプロビジョンされ得るか、または導出し得る。

次に、ステップ３では、交渉側が、「交渉要求」を交渉ブローカに送信する。このステップは、図６のステップ１と同一である。「交渉要求」メッセージを送信することに先立って、交渉側は、交渉ブローカによって認証され得るか、または代替として、交渉側および被交渉側は、確立された証明書に基づいて、互いに認証し得る。代替として、認証／相互認証は、「交渉要求」段階中に実行され得、正しい証明書の保有は、暗号プロシージャを使用して、「交渉要求」メッセージの一部として検証される。

ステップ４では、交渉ブローカが、ステップ１で送信される交渉ポリシに従って、被交渉側の代わりに提案を行う。このステップは、図６のステップ２と同一である。ステップ５では、交渉ブローカが、「交渉応答」を交渉側に送信する。このステップは、図６のステップ３と同一である。交渉側がステップ５に含まれるＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓに満足していない場合、ステップ３、ステップ４、およびステップ５が繰り返され得る。

ステップ６によると、交渉側が、適切な提案を選択する。このステップは、図６のステップ４と同一である。ステップ７では、交渉側が、「交渉確認」を交渉ブローカに送信する。このステップは、図６のステップ５と同一である。ステップ８では、交渉ブローカが、「確認応答」を交渉側に送信する。このステップは、図６のステップ６と同一である。次に、ステップ９では、交渉ブローカが、「交渉通知」を被交渉側に送信する。このメッセージは、以下の情報、すなわち、（ｉ）交渉側の名称または識別子、（ｉｉ）交渉されているサービスの名称、識別子、および／または説明、ならびに（ｉｉｉ）交渉側による選択された提案を含み得る。さらに、ステップ１０では、被交渉側が、「確認応答」を交渉ブローカに送信する。

ステップ１およびステップ２は、複数の被交渉側があり得るため、複数回起こり得ることに留意されたい。ステップ１および２の各組は、個々の被交渉側のためのものである。ステップ９およびステップ１０も、複数の被交渉側があり得るので、複数回起こり得る。ステップ９および１０の各組は、個々の被交渉側のためのものである。

別の実施形態によると、図１２は、交渉ブローカが交渉側の代理の役割を果たすシナリオを図示し、認証および承認機能が、関与するエンティティに追加される。ステップ１では、交渉側が、「交渉代理要求」を交渉ブローカに送信する。交渉側は、このステップで、その交渉ポリシを交渉ブローカにパスし得る。交渉側は、その交渉ブローカにおいてその交渉ポリシを作成するために、別個のプロシージャを使用し得る。交渉側は、認証、承認、および安全な通信を可能にするために、あるセキュリティ機構ならびに機能を要求し得る。代替として、セキュリティ機能の設定の要求は、ステップ２で交渉ブローカによって行われ得る。交渉要求は、安全な通信チャネルを経由して送信され得る。

ステップ２では、交渉ブローカが、「交渉代理応答」を交渉側に送信する。このステップは、省略され得、ステップ１０が、交渉側への最終応答であろうことに留意されたい。ステップ１および２は、交渉側が交渉ブローカにすでに登録されているか、または関連付けられている場合、必要とされないこともあり、デフォルトで、交渉ブローカは、交渉側のための代理機能を果たすであろう。

ステップ３では、交渉側が、「交渉要求」を交渉ブローカに送信する。このステップは、図６のステップ１と同一である。加えて、交渉側および交渉ブローカは、互いに認証し得る。随意に、交渉要求メッセージの一部として、交渉側は、被交渉側または第三者エンティティによって交渉側にプロビジョンされた、セッションベースの承認パラメータを送信し得る。

ステップ４では、交渉ブローカが、承認パラメータとともに、交渉要求を被交渉側に転送する。被交渉側の観点から、被交渉側は、このメッセージが交渉ブローカからであると考える。ステップ５では、被交渉側が承認パラメータを検証することに基づいて、次いで、被交渉側が、提案を行う。このステップは、図６のステップ２に類似する。ステップ６は、図６のステップ３に類似する。交渉側ブローカがステップ６に含まれるＯｆｆｅｒｅｄＳｕｇｇｅｓｔｉｏｎｓに満足していない場合、ステップ４、ステップ５、およびステップ６が繰り返され得る。

ステップ７によると、交渉側ブローカが、適切な提案を選択する。このステップは、図６のステップ４に類似する。ステップ８では、交渉ブローカが、「交渉確認」を被交渉側に送信する。このステップは、図６のステップ５に類似する。その後、ステップ９では、被交渉側が、「確認応答」を交渉ブローカに送信する。このステップは、図６のステップ６と同一である。次に、ステップ１０では、交渉ブローカが、「交渉応答」を交渉側に送信する。このメッセージは、図６のステップ３に類似する。さらに、ステップ１１では、交渉側が、「確認応答」を交渉ブローカに送信する。上で説明されるセキュリティ機構（認証、承認、および安全な通信）ならびに機能は、第三者信頼が必要とされ得る、他の実施形態に使用され、適用可能であり得る。

図１３に図示される、さらなる実施形態によると、交渉ブローカは、複数の交渉要求を組み合わせ得、交渉効率を向上させるために、複合交渉要求を被交渉側に送信する。図１３は、２つの交渉側を示すが、交渉ブローカは、２つより多くの交渉側からの交渉要求を組み合わせることができる。図１３は、実際に図１２と同一である、交渉側と交渉ブローカとの間の「交渉代理要求および応答」を示さないことに留意されたい。以下のステップが、図１３について説明される。

ステップ１では、交渉側ＡおよびＢが、それぞれ、交渉要求を交渉ブローカに送信する。ステップ２では、交渉ブローカが、被交渉側に送信される新しい複合交渉要求の中に、これら２つの交渉要求を入れることによって、両方を組み合わせる。ステップ３では、被交渉側が、提案を行う。このステップは、図６のステップ２に類似する。ステップ４では、被交渉側が、「交渉応答」を交渉ブローカに送信する。このステップは、図６のステップ３に類似する。次に、ステップ５では、交渉ブローカが、両方の交渉側の代わりに提案を選択する。このステップは、図６のステップ４と同一である。後に、ステップ６では、交渉ブローカが、「交渉確認」を被交渉側に送信する。このステップは、図６のステップ５に類似する。

ステップ７では、被交渉側が、「確認応答」を交渉ブローカに送信する。このステップは、図６のステップ６と同一である。ステップ８によると、交渉ブローカは、２つの「交渉応答」を、それぞれ、交渉側ＡおよびＢに送信する。このステップは、図６のステップ１０と同一である。次いで、ステップ９では、交渉側ＡおよびＢは、それぞれ、「確認応答」を交渉ブローカに送信する。このステップは、図６のステップ１１に類似する。図１３は、複数の被交渉側を示さないが、ステップ２からステップ７は、交渉ブローカと別の被交渉側との間の相互作用に適用されることができる。

別の実施形態によると、交渉ブローカは、過負荷になり得、ひいては、それは、その機能を別の交渉ブローカに委託することができる。そのようなブローカ委託は、（交渉側／被交渉側が、現在の交渉ブローカが委託される必要があることを把握することができる場合、および／または新しい交渉ブローカを決定することができる場合に）交渉側／被交渉側によって、もしくは現在の交渉ブローカによって能動的に開始され得る。図１４は、現在の交渉ブローカＡから新しい交渉ブローカＢへのブローカ委託のためのプロシージャを図示する。

ステップ１によると、交渉側（または被交渉側）が、「ブローカ委託要求」を現在の交渉ブローカＡに送信する。このメッセージは、新しい交渉ブローカＢのアドレス、名称、および／または識別子を含み得るが、それらに限定されない。代替として、現在の交渉ブローカＡは、交渉側／被交渉側のための新しい交渉ブローカを選定し得る。このステップは、ブローカ委託が現在の交渉ブローカＡによって能動的にトリガされる場合、随意である。

ステップ２では、現在の交渉ブローカＡが、「ブローカ委託要求」を新しい交渉ブローカＢに送信する。このメッセージは、以下の情報、すなわち、交渉側／被交渉側のアドレス、名称、および識別子、現在の交渉ブローカＡが交渉側／被交渉側のための合法ブローカであるかどうかを検証するために使用されることができる、認証情報、新しい交渉ブローカＢが交渉側／被交渉側のために有効になる開始時間、新しい交渉ブローカＢが交渉側／被交渉側のためのブローカの役割を果たすための持続時間を含み得るが、それらに限定されない。

ステップ３では、新しい交渉ブローカＢが、「ブローカ委託応答」を現在の交渉ブローカＡに送信する。新しい交渉ブローカＢが委託要求を拒否する場合、以下のステップ４および５は、省略され、ブローカ委託は、成功しない。ステップ４によると、現在の交渉ブローカＡが、「交渉コンテキスト転送」を新しい交渉ブローカＢに送信する。このメッセージは、交渉側／被交渉側のための交渉ポリシ等の必要なコンテキスト情報を新しい交渉ブローカＢに転送するために使用される。ステップ５によると、新しい交渉ブローカＢが、「交渉コンテキスト応答」を現在の交渉ブローカＡに送信する。

次に、ステップ６では、現在の交渉ブローカＡが、「ブローカ委託応答」を交渉側／被交渉側に送信する。このメッセージは、以下の情報、すなわち、新しい交渉ブローカＢのアドレス、名称、および／または識別子、新しい交渉ブローカＢが交渉側／被交渉側の代理の役割を果たすであろう、開始時間ならびに持続時間を含み得る。さらに、ステップ７では、交渉側／被交渉側が、新しい交渉ブローカＢとサービス交渉を行うために、説明されるような類似プロシージャを使用する。

さらに別の実施形態によると、交渉側がサービス交渉プロセスを開始するための種々のトリガが説明される。例えば、Ｍ２Ｍデバイスが、全てのデータをローカルに記憶することができない場合がある、増加したデータ量を生成し始めるとき、より多くの記憶容量を得るように、そのＭ２Ｍサーバと交渉プロセスを開始し得る。Ｍ２Ｍデバイスが、データをアップロードする速度を増加させなければならないことを見出す場合、記憶されたデータへのより頻繁な動作を要求するために、再度、Ｍ２Ｍサーバと交渉し得る。

デバイス管理のためのＭ２Ｍアプリケーションは、新しいＭ２Ｍデバイスがシステムの中へ追加されるとき、より多くのＭ２Ｍデバイスを管理することを要求するために、そのＭ２Ｍサーバと交渉し始め得る。Ｍ２Ｍアプリケーションは、それ自体と別のＭ２Ｍアプリケーションとの間のエンドツーエンド遅延が増加したことを見出す。例示的実施形態では、通信は、Ｍ２Ｍサーバによって中継される。Ｍ２Ｍアプリケーションは、Ｍ２Ｍサーバにおいてその要求メッセージをバッファリングするための時間を短縮するために、Ｍ２Ｍサーバとサービス交渉を開始することを希望し得る。

（交渉可能なサービス）
ｏｎｅＭ２Ｍアーキテクチャとの関連で、どのＭ２Ｍサービスがどんな方法で交渉されることができるかを説明する実施例が開示される。基本的に、２つのレベルのサービス交渉がある。

レベル１では、Ｍ２Ｍデバイスは、それが使用する必要がある所望のＣＳＦについてＭ２Ｍサーバと交渉する。換言すると、Ｍ２Ｍデバイスは、Ｍ２Ｍサーバによって提供されるＣＳＦの一部を使用することを要求し得る。レベル１サービス交渉に対して、図１５に示されるような１６ビットＣＳＦビットマップが、その選好を示すためにＭ２Ｍデバイスによって、および承認されたＣＳＦを示すためにＭ２Ｍサーバによって活用され得る。各ビットは、ＣＳＦを表し、最後の４つのビットは、将来の使用のために保留される。ＲＥＧ ＣＳＦは、他のＣＳＦを使用するためにＭ２Ｍデバイスが選定する必要がある、デフォルトＣＳＦであることに留意されたい。

レベル２では、Ｍ２Ｍデバイスはまた、各個々のＣＳＦの特徴または機能性についてＭ２Ｍサーバと交渉し得る。レベル２サービス交渉に対して、各ＣＳＦは、交渉されることができる、異なる特徴および機能性を有する。例えば、Ｍ２Ｍデバイスは、Ｍ２Ｍサーバによって提供される全てのＤＭ機能性を使用する必要がないこともあるので、所望のＤＭＧ機能性についてＭ２Ｍサーバと交渉することができる。さらなる実施例および詳細が、表３に挙げられる。ＣＳＦビットマップの実施例と同様に、図１６は、ＣＳＦがＭ個の特徴を有し、Ｍビットを必要とすると、各特徴、例えば、ＣＳＦのＦ１、Ｆ２が、１ビットによって表される、ＣＳＦ特徴ビットマップの実施例を図示する。

シナリオ１では、Ｍ２Ｍデバイスがより多くのデータを生成するとき、より多くの記憶容量を得るように、Ｍ２Ｍサーバとの交渉プロセスを開始し得る。以降で、Ｍ２Ｍデバイスが、データが過剰に速く変化し、より頻繁なデータ更新を必要とすることを決定する場合、記憶されたデータへのより頻繁な動作を要求するために、再度、Ｍ２Ｍサーバと交渉し得る。

（新しいＣＳＦ：交渉サービス（ＮＧＳ））
図１７は、現在のｏｎｅＭ２Ｍ機能アーキテクチャに基づいて、提案される交渉サービスを新しいＣＳＦとして実装するための例示的実施形態を示す。代替として、いくつかのＮＧＳ機能が、デバイスブートストラップ、デバイスファームウェアアップロード等の間に起こり得るか、または必要とされ得る、デバイス管理関連交渉を行うために、ＤＭＧ ＣＳＦの一部として追加されることができる。

一実施形態では、このＮＧＳ機能は、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２Ｍノードによってホストされる、Ｍ２Ｍサービス層インスタンス内でホストされ得る。例えば、ＮＧＳは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

図１８の実施形態に示されるように、提案されるＮＧＳ ＣＳＦは、ＭＮ−ＣＳＥ、ＡＳＮ−ＣＳＥ、またはＩＮ−ＣＳＥの中に常駐することができる。ＮＧＳ ＣＳＦは、上で説明されるように、交渉側、交渉ブローカ、および／または被交渉側の機能性を有するであろう。サービス交渉は、以下の方法で行われることができる。

ＭＮ−ＣＳＥが、サービスについてＩＮ−ＣＳＥと直接交渉する場合、ＭＮ−ＣＳＥのＮＧＳは、提案を選択する交渉側であり、ＩＮ−ＣＳＥのＮＧＳは、提案を行う被交渉側であろう。ＭＮ−ＣＳＥが、サービスについてＩＮ−ＣＳＥを介してＡＳＮ−ＣＳＥと間接的に交渉する場合、ＭＮ−ＣＳＥのＮＧＳは、提案を選択する交渉側であろう。さらに、ＩＮ−ＣＳＥのＮＧＳは、透過モードでは交渉ブローカであろう。さらに、ＡＳＮ−ＣＳＥのＮＧＳは、提案を行う被交渉側であろう。

ＩＮ−ＡＥ１が、サービスについてＩＮ−ＣＳＥを介してＡＳＮ−ＣＳＥと間接的に交渉する場合、ＩＮ−ＡＥ１は、交渉側であり、ＩＮ−ＣＳＥのＮＧＳは、提案を選択するＩＮ−ＡＥ１の交渉ブローカであり、ＡＳＮ−ＣＳＥのＮＧＳは、提案を行う被交渉側であろう。

ＩＮ−ＡＥ２が、サービスについてＩＮ−ＣＳＥを介してＩＮ−ＡＥ１と間接的に交渉する場合、ＩＮ−ＡＥ２は、交渉側であり、ＩＮ−ＣＳＥのＮＧＳは、提案を行い、提案を選択する、ＩＮ−ＡＥ１およびＩＮ−ＡＥ１の両方のための交渉ブローカであり、ＩＮ−ＡＥ１は、被交渉側であろう。

図１９は、ＡＳＮ−ＣＳＥが、中間のＭＮ−ＣＳＥを介してサービスについてＩＮ−ＣＳＥと交渉する、別の例示的実施形態を示す。ＡＳＮ−ＣＳＥのＮＧＳは、交渉側であり、ＭＮ−ＣＳＥのＮＧＳは、交渉ブローカであり、ＩＮ−ＣＳＥのＮＧＳは、被交渉側であろう。

（ＮＧＳ ＣＳＦをサポートする新しいリソース／属性）
別の実施形態では、ＮＧＳ ＣＳＦサービスをサポートするためのｏｎｅＭ２Ｍリソース構造強化が提案される。リソース構造を説明するためのｏｎｅＭ２Ｍ定義図式表現は、以下である：ｉ）四角いボックスが、リソースおよび子リソースに使用され、（ｉｉ）丸い角を伴う四角いボックスが、属性に使用され、（ｉｉｉ）新しいリソース＜ｎｇｔｎ＞。

＜ｎｇｔｎ＞リソースは、Ｍ２Ｍエンティティが交渉要求を発行し、交渉応答を受信する／読み出すために定義される。各＜ｎｇｔｎ＞リソースは、２つのＭ２Ｍエンティティの間の特定の交渉要求または応答に対応する。それは、図６に図示されるように、交渉要求および交渉応答メッセージに含まれるような情報またはパラメータを維持する。

＜ｎｇｔｎ＞は、図２０および表４に示されるようないくつかの属性およびサブリソースを有する。＜ｎｇｔｎ＞の親リソースは、＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、および／または＜ｒｅｍｏｔｅＣＳＥ＞であり得る。例えば、ＩＮ−ＡＥは、そのホスティングＣＳＥと交渉を開始するために、そのホスティングＣＳＥ（例えば、Ｍ２Ｍサーバ）上のその＜ＡＥ＞の下に＜ｎｇｔｎ＞リソースを作成する。

例えば、ＭＮ−ＣＳＥは、そのホスティングＣＳＥと交渉を開始するために、そのホスティングＣＳＥ（例えば、Ｍ２Ｍサーバ）上のその＜ｒｅｍｏｔｅＣＳＥ＞の下に＜ｎｇｔｎ＞リソースを作成する。

代替として、ＩＮ−ＣＳＥおよびＩＮ−ＡＥからの交渉要求は全て、それらのホスティングＣＳＥの直下で作成されることができる。この場合、＜ｎｇｔｎ＞は、ホスティングＣＳＥの＜ＣＳＥＢａｓｅ＞のサブリソースとして作成されるであろう。

さらに別の実施形態によると、＜ｎｇｔｎＰｏｌｉｃｙ＞と呼ばれる新しいリソース、例えば、交渉ポリシが、１）被交渉側（またはそのブローカ）が、ポリシに基づいて提案を行う方法を特定するために、または、２）交渉側（またはそのブローカ）が、ポリシに基づいて提案を選択する方法を特定するために使用される。換言すると、２つのタイプのポリシ、すなわち、１）提案を行うためのポリシ、および、２）提案を選択するためのポリシがある。各交渉ポリシは、少なくとも２つの情報、すなわち、条件および結果を含む必要がある。すなわち、「条件」が満たされる場合、「結果」は、ポリシの出力であろう。２つのタイプのポリシがあるので、「結果」は、１）被交渉側またはそのブローカによって行われる提案、または、２）交渉側またはそのブローカによって選択される提案であり得る。

＜ｎｇｔｎＰｏｌｉｃｙ＞リソースは、図２１および以下の表５に示されるようないくつかの属性およびサブリソースを有する。＜ｎｇｔｎＰｏｌｉｃｙ＞の親リソースは、＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、および／または＜ｒｅｍｏｔｅＣＳＥ＞であり得る。＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、および＜ｒｅｍｏｔｅＣＳＥ＞は、参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ１．１．０（Ａｕｇｕｓｔ ２０１４）で説明されるように定義されることに留意されたい。

図２２および以下の表６に示されるようなさらなる実施形態によると、「交渉リソース」と呼ばれる新しいリソース、例えば、＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞が、本願で上に説明されるような交渉委託ブローカ機能をサポートするために提案される。各＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞は、交渉ブローカ委託要求に対応する。これは、＜ＡＥ＞、＜ｒｅｍｏｔｅＣＳＥ＞、または＜ＣＳＥＢａｓｅ＞リソースのサブリソースであり得る。

新しい属性「ｎｇｔｎＢｒｏｋｅｒ」が、＜ＡＥ＞または＜ｒｅｍｏｔｅＣＳＥ＞リソースの新しい属性として提案される。＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、および＜ｒｅｍｏｔｅＣＳＥ＞は、参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ１．１．０（Ａｕｇｕｓｔ ２０１４）で説明されるように定義されることに留意されたい。ｎｇｔｎＢｒｏｋｅｒが＜ＡＥ＞リソースの属性である場合、それは、＜ＡＥ＞の交渉ブローカを示す。ｎｇｔｎＢｒｏｋｅｒが＜ｒｅｍｏｔｅＣＳＥ＞リソースの属性である場合、それは、＜ｒｅｍｏｔｅＣＳＥ＞の交渉ブローカを示す。

ＣｓｆＢｉｔＭａｐが、＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、または＜ｒｅｍｏｔｅＣＳＥ＞リソースの新しい属性として提案される。＜ＡＥ＞、＜ＣＳＥＢａｓｅ＞、および＜ｒｅｍｏｔｅＣＳＥ＞は、参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ１．１．０（Ａｕｇｕｓｔ ２０１４）で説明されることに留意されたい。ｃｓｆＢｉｔＭａｐが＜ＡＥ＞リソースの属性である場合、それは、＜ＡＥ＞が使用することを要求するＣＳＦのリスト、および／または＜ＡＥ＞のホスティングＣＳＥによって承認されるＣＳＦのリストを意味する。ＡＥが、それ自体をそのホスティングＣＳＥに登録するとき、ＡＥは、その所望のＣＳＦを示すために、アプリケーション登録要求メッセージにｃｓｆＢｉｔＭａｐを含み得、順に、ホスティングＣＳＥは、ＡＥに割り付けられている、承認されたＣＳＦを示すために、承認されたｃｓｆＢｉｔＭａｐを返し得る。

ｃｓｆＢｉｔＭａｐが＜ｒｅｍｏｔｅＣＳＥ＞リソースの属性である場合、それは、＜ｒｅｍｏｔｅＣＳＥ＞が使用することを要求するＣＳＦのリスト、および／または＜ｒｅｍｏｔｅＣＳＥ＞のホスティングＣＳＥによって承認されるＣＳＦのリストを意味する。ＣＳＥが、それ自体をそのホスティングＣＳＥに登録するとき、ＣＳＥは、その所望のＣＳＦを示すために、ＣＳＥ登録要求メッセージにｃｓｆＢｉｔＭａｐを含み得、順に、ホスティングＣＳＥは、ＣＳＥに割り付けられている、承認されたＣＳＦを示すために、承認されたｃｓｆＢｉｔＭａｐを返し得る。ｃｓｆＢｉｔＭａｐが＜ＣＳＥＢａｓｅ＞の属性である場合、それは、このＣＳＥが保有するＣＳＦのリストを意味する。

（ＮＧＳ ＣＳＦをサポートするリソースプロシージャ）
以下の表９で提供されるプロトコルは、＜ｎｇｔｎ＞リソースを作成するために採用される。具体的には、このプロシージャは、ホスティングＣＳＥの中で特定の＜ｎｇｔｎ＞リソースを作成するために使用されるものとする。

さらに、表１０の中のプロトコルは、既存の＜ｎｇｔｎ＞リソースから情報を読み出すために使用されるものとする。

表１１の中の以下のプロトコルは、既存の＜ｎｇｔｎ＞リソースの情報を更新するために採用される。

表１２で提供されるプロトコルは、既存の＜ｎｇｔｎ＞リソースを削除するために使用されるものとする。

表１３で以下に提供されるプロトコルは、ホスティングＣＳＥ上で保留交渉要求＜ｎｇｔｎ＞を実行するために使用されるものとする。

以下の表１４で提供されるプロトコルは、ホスティングＣＳＥの中で特定の＜ｎｇｔｎＰｏｌｉｃｙ＞リソースを作成するために使用されるものとする。

以下の表１５で提供されるプロシージャは、既存の＜ｎｇｔｎＰｏｌｉｃｙ＞リソースから情報を受信するために使用されるものとする。

以下の表１６で提供されるプロシージャは、既存の＜ｎｇｔｎＰｏｌｉｃｙ＞リソースの情報を更新するために使用されるものとする。

以下の表１７の中のプロトコルは、既存の＜ｎｇｔｎＰｏｌｉｃｙ＞リソースを削除するために使用されるものとする。

以下の表１８の中のプロシージャは、ホスティングＣＳＥの中で特定の＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞リソースを作成するために使用されるものとする。

以下の表１９の中のプロトコルは、既存の＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞リソースから情報を読み出すために使用されるものとする。

以下の表２０の中のプロトコルは、既存の＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞リソースの情報を更新するために使用されるものとする。

以下の表２１の中のプロトコルは、既存の＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞リソースを削除するために使用されるものとする。

以下の表２２の中のプロトコルは、ホスティングＣＳＥ上で保留交渉ブローカ委託要求＜ｎｇｔｎＤｅｌｅｇａｔｉｏｎ＞を実行するために使用されるものとする。

図２３は、上で説明される提案されるプロシージャを使用して、サービス交渉の実施例を図示する。ステップの各々は、ローマ数字形態、例えば、００１、００２等で提供される。ここで、ＭＮ−ＣＳＥは、交渉側であり、ＩＮ−ＣＳＥは、被交渉側である。ステップ１によると、ＭＮ−ＣＳＥが、ＣＲＥＡＴＥ要求を発行する。これは、図６のステップ１に類似する。次に、ステップ２では、ＩＮ−ＣＳＥが、ＣＲＥＡＴＥ要求を処理する。次いで、ステップ３では、ＩＮ−ＣＳＥが、ＣＲＥＡＴＥ応答をＭＮ−ＣＳＥに送信する。その後、ステップ４では、ＭＮ−ＣＳＥが、上で説明されるように、作成された＜ｎｇｔｎ＞を実行するために、特別なＵＰＤＡＴＥ要求を発行する。これは、図６のステップ１に類似する。後に、ステップ５では、ＩＮ−ＣＳＥが、提案を行うためにＵＰＤＡＴＥ要求を処理する。これは、図６のステップ２に類似する。

ＩＮ−ＣＳＥは、ステップ６でＵＰＤＡＴＥ応答をＭＮ−ＣＳＥに送信する。これは、図６のステップ３に類似する。ステップ７では、ＭＮ−ＣＳＥが、適切な提案を選択するためにＵＰＤＡＴＥ応答を処理する。これは、図６のステップ４に類似する。次いで、ステップ８では、ＭＮ−ＣＳＥが、上で説明されるように＜ｎｇｔｎ＞／ｓｅｌｅｃｔｅｄＳｕｇｇｅｓｔｉｏｎｓを更新するために、通常のＵＰＤＡＴＥ要求を発行する。これは、図６のステップ５に類似する。次いで、ステップ９では、ＩＮ−ＣＳＥが、選択された提案を確認するためにＵＰＤＡＴＥ要求を処理する。さらに、ステップ１０では、ＩＮ−ＣＳＥが、ＵＰＤＡＴＥ応答をＭＮ−ＣＳＥに送信する。これは、図６のステップ６に類似する。

図２４は、交渉サービスが新しいサービスコンポーネントとして挿入される、参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００７，ｏｎｅＭ２ＭＳｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．４．０で提供されるようなｏｎｅＭ２Ｍ ＳｏＡアーキテクチャにおいて、提案される交渉サービスの実施形態を図示する。他のサービスコンポーネントは、Ｍｓｃ参照点を通して交渉サービスと通信し得る。ＮＧＳは、Ｍｃａ参照点に適用されることができ、本開示における提案されるデータ構造およびメッセージも、ＳＯＡアーキテクチャに適用されることができることに留意されたい。

本願による適用可能な使用事例では、Ｍ２Ｍサービスオペレータ、例えば、ＡＴ＆Ｔが、種々のＭ２Ｍサーバから成るスマート交通Ｍ２Ｍサービスプラットフォームを展開する。各Ｍ２Ｍサーバは、デバイス管理用のＤＭＧ等のサービスの一式を提供する。自動車レンタル会社、例えば、Ｈｅｒｔｚは、その車両を管理するために、このプラットフォームを使用してきた。現在、自動車会社は、より多くの新しいハイブリッド自動車を市場に出したい。新しいハイブリッド自動車は、デバイス管理の観点から、さらなる診断および監視機能を必要とする。この新しい要件および管理される新しい自動車の数に起因して、自動車会社のＭ２Ｍアプリケーションは、所望のＤＭＧ機能性、例えば、より高度な診断機能、グループデバイス管理、これらの新しい自動車のより頻繁な場所更新等についてオペレータと交渉する。

別の使用事例では、Ｍ２Ｍサービスオペレータ、例えば、Ｇｏｏｇｌｅが、顧客の家庭で、クラウド内のＭ２ＭサーバおよびＭ２Ｍゲートウェイから成るスマートホームＭ２Ｍサービスプラットフォームを展開する（例えば、Ｇｏｏｇｌｅ’ｓ ＮＥＳＴ）。Ｍ２ＭサーバおよびＭ２Ｍゲートウェイは両方とも、データ管理用のＤＭＲ等のサービスの一式を提供する。顧客は、ローカルで、例えば、家庭にインストールされたカメラから、センサデータを記憶するために、Ｍ２Ｍゲートウェイを使用していた。現在、夏期であり、顧客は、旅行をする計画であり、１ヶ月間家を留守にするであろう。顧客は、スマートフォンを介して、以前よりも頻繁にカメラデータにアクセスする必要がある。顧客はまた、カメラが任意の異常を検出する場合、オペレータのサービスプラットフォームから自動通知を受信したい。スマートフォン上の顧客のＭ２Ｍアプリケーションは、新しい必要性を満たすために、家庭のＭ２Ｍゲートウェイの代わりにクラウドの中にカメラデータを記憶／分析するかどうか、およびその方法について、オペレータのサービスプラットフォームと交渉する。ＮＧＳの機能性は、Ｍ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリに記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。

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

本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能記命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図６−１４および２３による、複数のコールフローにおいて上記で開示されるような１つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、上記の図４Ｃおよび４Ｄで開示される、メモリ内に記憶され、プロセッサによって実行され、Ｍ２Ｍデバイスならびにサーバを含むデバイス内で採用され得る。一実施形態では、図４Ｃおよび４Ｄで上記に説明されるように、不揮発性メモリおよびそこに動作可能に結合されるプロセッサを有する、コンピュータ実装ＵＥが、開示される。具体的には、装置は、サービス属性について交渉するためのその上に記憶された命令を有する、交渉サービス層を有する、不揮発性メモリを含む。

本願のさらなる側面は、コンピュータ実装ネットワーク化システムを説明する。ネットワークは、交渉側と、被交渉側とを含む。交渉側および被交渉側のそれぞれは、データを送信ならびに受信するための送受信機を含む。交渉側および被交渉側のそれぞれはまた、サービス層属性について交渉するためのその上に記憶された命令とともに交渉サービス層を有する、不揮発性メモリを含む。交渉側および被交渉側のそれぞれはまた、サービス層属性の交渉を行うように構成されている、非一過性メモリに動作可能に結合されたプロセッサも含む。ある実施形態によると、交渉側および被交渉側のメモリは、交渉リソース、ポリシリソース、委託リソース、ならびにそれらの組み合わせから選択されるリソースを含む。

システムおよび方法が、現在、具体的側面と見なされるものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正および類似配列を対象にすることが意図され、その範囲は、全てのそのような修正および類似構造を包含するよう、最も広い解釈を与えられるはずである。本開示は、以下の請求項のありとあらゆる側面を含む。

Claims (22)

1. コンピュータ実装装置であって、前記装置は、
   不揮発性メモリであって、前記不揮発性メモリは、その上に記憶された命令を含み、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
   前記不揮発性メモリに動作可能に結合されたプロセッサと
   を備え、
   前記プロセッサは、
   被交渉側から受信される前記属性を精査することと、
   前記精査された属性に基づいて、交渉要求を前記被交渉側に送信することと、
   前記被交渉側から提示された提案を受信することと
   を行う命令を実施するように構成されている、コンピュータ実装装置。
2. 前記プロセッサは、前記提示された提案を選択するようにさらに構成されている、請求項１に記載のコンピュータ実装装置。
3. 前記選択は、前記被交渉側の所定の交渉ポリシに対してチェックされる、請求項２に記載のコンピュータ実装装置。
4. 前記交渉要求を送信するステップは、ブローカを介して前記被交渉側に送信される、請求項１に記載のコンピュータ実装装置。
5. 前記提示された提案を受信するステップは、前記ブローカを介して前記被交渉側から受信される、請求項４に記載のコンピュータ実装装置。
6. 前記メモリおよび前記プロセッサに動作可能に接続されたグラフィカルユーザインターフェースを含むディスプレイをさらに備え、前記グラフィカルユーザインターフェース、は、前記提示された提案を表示するように構成されている、請求項１に記載のコンピュータ実装装置。
7. 前記ディスプレイ上の前記提示された提案は、提案、別の被交渉側との交渉推奨、およびそれらの組み合わせから選択される情報を含む、請求項１に記載のコンピュータ実装装置。
8. コンピュータ実装装置であって、前記装置は、
   不揮発性メモリであって、前記不揮発性メモリは、その上に記憶された命令を含み、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
   前記不揮発性メモリに動作可能に結合されたプロセッサと
   を備え、
   前記プロセッサは、
   被交渉側から前記属性について交渉するためのポリシを受信することと、
   前記属性について交渉するための要求を交渉側から受信することと、
   前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと
   を行う命令を実施するように構成されている、コンピュータ実装装置。
9. 前記プロセッサは、提示された提案を前記交渉側に送信するようにさらに構成されている、請求項８に記載のコンピュータ実装装置。
10. 前記不揮発性メモリは、共通属性、作成、読み出し、削除、更新、実行、標識、ブローカ、タイプ、提案を行うための入力、提案を選択するための入力、開始、ステータス、標的、参照、提示された提案、選択された提案、出力パラメータ、サブスクリプション、およびそれらの組み合わせから選択される交渉リソースを記憶し、
    前記プロセッサは、前記属性について交渉するために前記交渉リソースを用いる、
    請求項８に記載のコンピュータ実装装置。
11. 前記メモリは、共通属性、標識、交渉タイプ、交渉側、被交渉側、条件、結果、規則の選択、サブスクリプション、およびそれらの組み合わせから選択されるポリシリソースを記憶し、
    前記プロセッサは、前記属性について交渉するために前記ポリシリソースを用いる、
    請求項８に記載のコンピュータ実装装置。
12. 前記メモリは、共通属性、標識、クライアント、現在の交渉ブローカ、新しい交渉ブローカ、委託有効化、開始時間、持続時間、結果、サブスクリプション、およびそれらの組み合わせから選択される委託リソースを記憶し、
    前記プロセッサは、前記属性について交渉するために前記委託リソースを用いる、
    請求項８に記載のコンピュータ実装装置。
13. コンピュータ実装交渉側およびコンピュータ実装被交渉側を備えているネットワーク化システムであって、前記交渉側および前記被交渉側の各々は、
    データを送信および受信するための送受信機と、
    交渉サービス層を有する不揮発性メモリであって、前記不揮発性メモリは、その上に記憶されたサービス層属性について交渉するための命令を有する、不揮発性メモリと、
    前記不揮発性メモリに動作可能に結合されたプロセッサと
    を含み、
    前記プロセッサは、前記サービス層属性の交渉を行うように構成されている、
    ネットワーク化システム。
14. 前記プロセッサは、
    被交渉側から前記属性について交渉するためのポリシを受信することと、
    前記属性について交渉するための要求を交渉側から受信することと、
    前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと
    を行う命令を実施するように構成されている、請求項１３に記載のネットワーク化システム。
15. 前記不揮発性メモリは、交渉リソース、ポリシリソース、委託リソース、およびそれらの組み合わせから選択されるリソースを含む、請求項１３に記載のネットワーク化システム。
16. コンピュータ実装方法であって、前記方法は、
    被交渉側から受信される交渉可能なサービス層属性を精査することと、
    前記精査された属性に基づいて、交渉要求を前記被交渉側に送信することと、
    前記被交渉側から提示された提案を受信することと、
    前記提示された提案を選択することと
    含む、コンピュータ実装方法。
17. 前記受信される提示された提案は、前記被交渉側の所定の交渉ポリシに対してチェックされる、請求項１６に記載の方法。
18. 前記交渉要求は、サービスｉｄ、提案を行うための入力、提案される提案、およびそれらの組み合わせから選択される情報を含む、請求項１６に記載の方法。
19. コンピュータ実装方法であって、前記方法は、
    被交渉側から交渉可能なサービス層属性について交渉するためのポリシを受信することと、
    前記属性について交渉するための要求を交渉側から受信することと、
    前記要求が前記被交渉側ポリシの所定の基準に適合するかどうかを決定することと、
    提示された提案を前記交渉側に送信することと
    を含む、コンピュータ実装方法。
20. 前記交渉側から交渉確認を受信することと、
    前記交渉確認の確認応答を前記被交渉側に送信することと
    をさらに含む、請求項１９に記載の方法。
21. コンピュータ実装方法であって、前記方法は、
    交渉側から交渉可能なサービス層属性に対する交渉要求を受信することと、
    前記属性を有する被交渉側の場所を特定することと、
    前記交渉要求を前記被交渉側に送信することと、
    前記被交渉側から前記交渉可能なサービスに対する提示された提案を受信することと
    を含む、コンピュータ実装方法。
22. 前記提示された提案を前記交渉側に送信することと、
    前記交渉側から交渉確認を受信することと、
    前記交渉確認の確認応答を前記被交渉側に送信することと
    をさらに含む、請求項２１に記載の方法。