JP2018092665A - モノのインターネットのための知的交渉サービス - Google Patents

Abstract

【課題】モノのインターネットのための知的交渉サービスの提供。【解決手段】サービスとしてＩｏＴモノ、ＩｏＴエンティティ、および／またはＩｏＴアプリケーション間の交渉を提供するためのデバイス、方法、およびシステムが開示される。ＩｏＴエンティティは、標的サービスの場所を特定し、要求ＩｏＴエンティティの代わりに標的サービスからサービスを要求し得る、交渉サービスに受け入れられ得る。類似空間で類似機能を果たすデバイスのセットのための作業スケジュール、サービスの価格、およびサービスの持続時間等の種々のサービスおよび関連パラメータが交渉され得る。【選択図】図１

Description

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

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

ＩｏＴシステム内のエンティティは、通信し、エンティティのうちの１つによって提供されるサービスを使用し、差異を解決し、アクションを調整し、またはあるタイプの利点をエンティティの一方または両方に提供し得る他の活動を行うために、互に交渉し得る。しかしながら、個々のＩｏＴエンティティ間の直接交渉は、いくつかの理由で望ましくない場合がある。ＩｏＴデバイスは、限定された処理能力、メモリ、通信能力、および／またはバッテリ電力を有する、リソースが制約されたデバイスであり得る。したがって、別のデバイスと交渉を行うために必要とされる詳細情報を維持および生成することを各ＩｏＴエンティティに要求することは、実行可能ではない場合または効率的ではない場合がある。エンティティのうちの１つは、他のＩｏＴエンティティの認識の不足、または別のエンティティとの交渉の成功に必要とされる知識の不足等の種々の理由で、別のエンティティと交渉することができない、または交渉したがらない場合がある。

本明細書で開示される実施形態は、接続されたエンティティのネットワーク内の交渉サービスエンティティにおいて、第１のエンティティから交渉要求を受信し、第１のエンティティを交渉サービスエンティティに受け入れ、要求のための交渉標的エンティティを決定する方法を含む。次いで、標的交渉要求が、交渉標的エンティティに送信され得、交渉応答が、交渉標的エンティティから受信され得る。交渉結果が、交渉サービスから第１のエンティティに送信され得る。

本明細書で開示される実施形態はさらに、第１のエンティティから交渉要求を受信することと、第１のエンティティを交渉サービスエンティティに受け入れることと、交渉標的エンティティを決定することとを含む、動作を実行する、接続されたエンティティのネットワーク内の交渉サービスエンティティを含む。動作はさらに、標的交渉要求を交渉標的エンティティに伝送することと、交渉標的エンティティから交渉応答を受信することと、交渉結果を第１のエンティティに伝送することとを含み得る。

本明細書で開示される実施形態はさらに、第１のエンティティから交渉要求を受信することと、過去の交渉要求が第１のエンティティから受信されており、過去の交渉要求の受信に応答して、第１のエンティティが交渉サービスエンティティに受け入れられたことを決定することと、過去の交渉要求が第１のエンティティから受信されており、過去の交渉要求の受信に応答して、第１のエンティティが交渉サービスエンティティに受け入れられたことを決定することに応じて、第１のエンティティを交渉サービスエンティティに受け入れることとを含む、動作を実行する、接続されたエンティティのネットワーク内の交渉サービスエンティティを含む。動作はさらに、交渉標的エンティティを決定することと、標的交渉要求を交渉標的エンティティに伝送することと、交渉標的エンティティから交渉応答を受信することと、交渉結果を第１のエンティティに伝送することとを含み得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本明細書は、例えば、以下を提供する。
（項目１）
接続されたエンティティのネットワーク内の交渉サービスエンティティにおいて、第１のエンティティから交渉要求を受信することと、
上記第１のエンティティを上記交渉サービスエンティティに受け入れることと、
上記交渉サービスエンティティにおいて交渉標的エンティティを決定することと、
標的交渉要求を上記交渉サービスエンティティから上記交渉標的エンティティに伝送することと、
上記交渉サービスエンティティにおいて上記交渉標的エンティティから交渉応答を受信することと、
交渉結果を上記交渉サービスエンティティから上記第１のエンティティに伝送することと
を含む、方法。
（項目２）
上記交渉標的エンティティを決定することは、
サービスプロバイダ発見要求を発見サービスに伝送することと、
上記発見サービスから交渉標的エンティティ識別子を備えているサービスプロバイダ発見応答を受信することと
を含む、項目１に記載の方法。
（項目３）
上記交渉標的エンティティ識別子は、複数の交渉標的エンティティ識別子と、上記複数の交渉標的エンティティ識別子のうちの各それぞれの交渉標的エンティティ識別子に関連付けられたデータとを備えている、項目２に記載の方法。
（項目４）
各それぞれの交渉標的エンティティ識別子に関連付けられた上記データに基づいて、上記複数の交渉標的エンティティ識別子の間から上記交渉標的エンティティ識別子を選択することをさらに含む、項目３に記載の方法。
（項目５）
上記交渉要求の優先順位を決定することと、
上記交渉要求を待ち行列の中に配置し、上記交渉要求の上記優先順位に基づいて上記待ち行列から上記交渉要求を選択することと、
上記待ち行列から上記交渉要求を選択すると、交渉要求受理指示を上記第１のエンティティに伝送することと
をさらに含む、項目１に記載の方法。
（項目６）
上記交渉要求が受信されてからあとに上記第１のエンティティのコンテキストが変化したという通知を受信することと、
第２の交渉標的エンティティが上記交渉要求に関連付けられた要求サービスを提供すべきであることを決定することと、
第２の標的交渉要求を上記第２の交渉標的エンティティに伝送することと、
上記第２の交渉標的エンティティから第２の交渉応答を受信することと、
第２の交渉結果を上記第１のエンティティに伝送することと
をさらに含む、項目１に記載の方法。
（項目７）
上記交渉標的エンティティを決定することは、
上記交渉要求が上記交渉標的エンティティを含んでいないことを決定することと、
少なくとも１つの以前の交渉要求に基づいて上記交渉標的エンティティを決定することと
を含み、
上記少なくとも１つの以前の交渉要求は、上記第１のエンティティおよび上記交渉要求に関連付けられた要求サービスのうちの少なくとも１つに関連付けられている、
項目１に記載の方法。
（項目８）
接続されたエンティティのネットワーク内の交渉サービスエンティティであって、
コンピュータ読み取り可能な命令を実行するように適合されている第１のプロセッサと、
上記第１のプロセッサに通信可能に連結されている第１のメモリと
を備え、
上記第１のメモリは、コンピュータ読み取り可能な命令を記憶しており、上記命令は、上記第１のプロセッサによって実行されると、
第１のエンティティから交渉要求を受信することと、
上記第１のエンティティを上記交渉サービスエンティティに受け入れることと、
交渉標的エンティティを決定することと、
標的交渉要求を上記交渉標的エンティティに伝送することと、
上記交渉標的エンティティから交渉応答を受信することと、
交渉結果を上記第１のエンティティに伝送することと
を含む動作を上記プロセッサに行わせる、交渉サービスエンティティ。
（項目９）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
サービスプロバイダ発見要求を発見サービスに伝送することと、
上記発見サービスから交渉標的エンティティ識別子を備えているサービスプロバイダ発見応答を受信することであって、上記交渉標的エンティティ識別子は、上記第１のエンティティに近接する交渉標的エンティティに関連付けられている、ことと
を含む動作を上記プロセッサに行わせる、項目８に記載の交渉サービスエンティティ。
（項目１０）
上記第１のエンティティおよび上記第２のエンティティは、同一の機能を果たす、項目９に記載の交渉サービスエンティティ。
（項目１１）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
上記第１のエンティティおよび上記交渉標的エンティティのための作業スケジュールを決定することを含む動作を上記プロセッサに行わせる、項目９に記載の交渉サービスエンティティ。
（項目１２）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
コンテキスト要求を、コンテキスト認識サービスに伝送することと、
上記交渉標的エンティティに対するコンテキストと、上記第１のエンティティに対するコンテキストとを備えているコンテキスト応答を受信することと
を含む動作を上記プロセッサに行わせる、項目９に記載の交渉サービスエンティティ。
（項目１３）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
上記交渉標的エンティティに対する上記コンテキストおよび上記第１のエンティティに対する上記コンテキストに基づいて、上記第１のエンティティおよび上記交渉標的エンティティのための作業スケジュールを決定することを含む動作を上記プロセッサに行わせる、項目１２に記載の交渉サービスエンティティ。
（項目１４）
上記交渉応答は、交渉拒否を備えている、項目８に記載の交渉サービスエンティティ。
（項目１５）
接続されたエンティティのネットワーク内の交渉サービスエンティティであって、
コンピュータ読み取り可能な命令を実行するように適合されている第１のプロセッサと、
上記第１のプロセッサに通信可能に連結されている第１のメモリと
を備え、
上記第１のメモリは、コンピュータ読み取り可能な命令を記憶しており、上記命令は、上記第１のプロセッサによって実行されると、
第１のエンティティから交渉要求を受信することであって、上記交渉要求は、要求サービス指示を備えている、ことと、
上記交渉要求が上記交渉標的エンティティを含んでいないことを決定することと、
上記要求サービス指示に基づいて上記交渉標的エンティティを決定することと、
標的交渉要求を上記交渉標的エンティティに伝送することと、
上記交渉標的エンティティから交渉応答を受信することと、
交渉結果を上記第１のエンティティに伝送することと
を含む動作を上記プロセッサに行わせる、交渉サービスエンティティ。
（項目１６）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
第２のエンティティから第２の交渉要求を受信することと、
上記第２のエンティティが上記第１のエンティティより高い優先順位を有することを決定することと、
交渉サービスを上記第１のエンティティに提供する前に、交渉サービスを上記第２のエンティティに提供することと
を含む動作を上記プロセッサに行わせる、項目１５に記載の交渉サービスエンティティ。
（項目１７）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
上記交渉要求が受信されてからあとに上記第１のエンティティのコンテキストが変化したという通知を受信することと、
第２の交渉標的エンティティが上記交渉要求に関連付けられた要求サービスを提供すべきであることを決定することと、
第２の標的交渉要求を上記第２の交渉標的エンティティに伝送することと、
上記第２の交渉標的エンティティから第２の交渉応答を受信することと、
第２の交渉結果を上記第１のエンティティに伝送することと
を含む動作を上記プロセッサに行わせる、
項目１５に記載の交渉サービスエンティティ。
（項目１８）
上記第１のエンティティの上記コンテキストは、上記第１のエンティティの場所、上記第１のエンティティのメモリリソース、上記第１のエンティティの処理リソース、上記第１のエンティティの帯域幅能力、および上記第１のエンティティの作業スケジュールのうちの少なくとも１つを備えている、項目１７に記載の交渉サービスエンティティ。
（項目１９）
上記交渉サービスエンティティは、マシンツーマシンデバイス上で構成されている、項目１５に記載の交渉サービスエンティティ。
（項目２０）
上記第１のメモリは、コンピュータ読み取り可能な命令をさらに備え、上記命令は、上記第１のプロセッサによって実行されると、
上記標的交渉要求を上記交渉標的エンティティに伝送した後、かつ上記交渉標的エンティティから上記交渉応答を受信する前に、上記第１のエンティティから第２の交渉要求を受信することと、
上記第２の交渉要求が上記交渉要求の複製であることを示す第２の交渉結果を上記第１のエンティティに伝送することと
を含む動作を上記プロセッサに行わせる、
項目１５に記載の交渉サービスエンティティ。

図１は、実施形態による、知的交渉サービスが実装され得る例示的なＩｏＴアーキテクチャを図示する。 図２は、実施形態による、知的交渉サービスを実装する例示的な方法を図示する。 図３は、実施形態による、例示的な知的交渉サービス信号フローを図示する。 図４は、実施形態による、例示的な知的交渉サービス信号フローを図示する。 図５は、実施形態による、知的交渉サービスを実装する例示的な方法を図示する。 図６は、実施形態による、例示的な知的交渉信号フローを図示する。 図７は、実施形態による、例示的なＩｏＴ知的交渉構成を図示する。 図８は、実施形態による、例示的な知的交渉信号フローを図示する。 図９は、実施形態による、例示的なＩｏＴ知的交渉構成を図示する。 図１０は、実施形態による、例示的な知的交渉信号フローを図示する。 図１１は、実施形態による、例示的なＩｏＴ知的交渉構成を図示する。 図１２は、実施形態による、知的交渉サービスが実装され得る例示的なＩｏＴアーキテクチャを図示する。 図１３は、実施形態による、例示的なＩｏＴ知的交渉構成を図示する。 図１４は、実施形態による、例示的な知的交渉信号フローを図示する。 図１５は、実施形態による、例示的な知的交渉信号フローを図示する。 図１６は、実施形態による、例示的なＩｏＴ知的交渉構成を図示する。 図１７は、実施形態による、知的交渉サービスのための例示的なＩｏＴ知的交渉構成を図示する。 図１８Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１８Ｂは、図１８Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１８Ｃは、図１８Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１８Ｄは、図１８Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

ＥＴＳＩ ＴＳ １０２ ６９０ １．１．１（２０１１−１０）の草稿で説明されるようなマシンツーマシン通信（Ｍ２Ｍ）機能アーキテクチャおよびその中で使用される用語、ならびにＥＴＳＩ ＴＳ １０２ ９２１ Ｖ０．８．２（２０１１−０９）の草稿で説明されるようなｍＩａ、ｄＩａ、およびｍＩｄ等のＭ２Ｍインターフェースおよびその中で使用される用語が、本明細書で便宜的に使用され得る。本開示は、開示される実施形態の理解に役立つように、本明細書において、これらの草稿を参照し、および／または理解されているように用語を使用し得る。しかしながら、当業者であれば、開示された実施形態が、ｏｎｅＭ２Ｍおよび他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることを認識するであろう。

本明細書に記載される実施形態は、表現状態転送（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ：ＲＥＳＴ）アーキテクチャに関して説明され、説明される構成要素およびエンティティは、ＲＥＳＴアーキテクチャ（ＲＥＳＴｆｕｌアーキテクチャ）の制約に従う。ＲＥＳＴｆｕｌアーキテクチャは、物理的構成要素の実装または使用される通信プロトコルに関するよりもむしろ、アーキテクチャで使用される構成要素、エンティティ、コネクタ、およびデータ要素に適用される制約に関して説明される。したがって、構成要素、エンティティ、コネクタ、およびデータ要素の役割および機能が説明されるであろう。ＲＥＳＴｆｕｌアーキテクチャでは、一意的にアドレス可能なリソースの表現が、エンティティ間で転送され得る。当業者であれば、本開示の範囲内にとどまりながら、本実施形態の実装が変動し得ることを認識するであろう。当業者であればまた、開示された実施形態が、例示的実施形態を説明するために本明細書で使用されるＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されないことも認識するであろう。開示された実施形態は、ｏｎｅＭ２Ｍ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得る。

実施形態では、ＩｏＴエンティティ間の交渉を促進するために、交渉サービスアーキテクチャが使用され得る。そのような交渉は、どのようにしてＩｏＴサービスを１つのエンティティによって別のエンティティに提供するか等のＩｏＴエンティティ間の種々の相互作用を決定するために使用され得る。ＩｏＴエンティティは、どのようにして、およびいつサービスを互に提供するかを決定するために、互に交渉し得る。例えば、交渉は、エンティティのための作業スケジュールを決定するため、サービスを提供する適切なエンティティを決定するため、（例えば、周期的に）データを取得するため等に使用され得る。図１は、例示的な交渉サービス１１０、およびそれに関連付けられ得る機能を図示する。これらの機能は、ＩｏＴエンティティ、ＩｏＴサービス、およびＩｏＴアプリケーションのための交渉サービスを提供することに役立ち得る。これらの機能の各々は、各他の機能、および交渉サービス１１０を実装する任意の他の機能と通信し得る。

交渉サービス１１０によって提供され得る機能の間には、ＩｏＴエンティティ１３０、ＩｏＴアプリケーション１２０、および／または他のＩｏＴサービス１４０から交渉要求を受信し得る、交渉要求処理機能１１１があり得る。ＩｏＴサービス１４０は、サービスを提供するために利用可能であるＩｏＴエンティティについての情報を決定して返信する、発見サービス１４１、サービスを促進および／または配信し得る、配信サービス１４２、他のＩｏＴエンティティによって使用され得るようにエンティティリソースを仮想化し得る、仮想化サービス１４３、コンテンツコピー、コンテンツ品質、およびコンテンツ形式を提供し得る、コンテンツ認識サービス１４４、ＩｏＴエンティティによって使用され得るＩｏＴエンティティに関するコンテキスト情報を提供し得る、コンテキスト認識サービス１４５、およびクラウドコンピューティングサービスを提供し得る、クラウドサービス１４６を含み得るが、それらに限定されない。交渉要求処理機能１１１は、着信交渉要求に対する受け入れ制御を行い、受理された着信要求をバッファに格納して優先順位をつけ、交渉要求の優先順位を調整し、それらのそれぞれの優先順位および／またはポリシーに基づいて交渉要求を予定に入れ得る。

交渉サービス１１０によって提供され得る別の機能は、（例えば、交渉要求処理機能１１１から受信される）交渉要求のための宛先を決定すること、交渉のための最良の方策を決定すること、および他の交渉決定等の交渉決定を行うことを可能にする、認知能力を含み得る、交渉意思決定機能１１２であり得る。そのような決定は、コンテキストおよびコンテンツ関連データ、ポリシー等のデータを含む、利用可能または取得可能なデータに基づいて行われ得る。

交渉サービス１１０によって提供され得る別の機能は、どのようにして交渉を現在の状況に適応させるかを決定するために、（例えば、交渉監視機能１１５から受信される）リアルタイム監視結果を使用し得る、交渉適応機能１１３であり得る。例えば、交渉適応機能１１３は、（例えば、交渉意思決定機能１１２によって決定されるような）以前の交渉に起因した方策を終了し、現在の交渉を再評価し、新しい交渉方策を形成し、新たに決定された相手と再交渉し得る。

交渉サービス１１０によって提供され得る別の機能は、（例えば、交渉意思決定機能１１２によって決定されるような）決定された交渉方策とともに、交渉要求を（例えば、交渉意思決定機能１１２によって決定されるような）選択された交渉相手に送信するための決定等の交渉決定を実行し得る、交渉実行機能１１４であり得る。

交渉サービス１１０によって提供され得るさらに別の機能は、要求側が決定された方策を用いてその交渉目標を達成するかどうかを監視することによって、交渉相手が満足させられることを確実にするために、（例えば、交渉実行機能１１４によって実行されるような）交渉方策実行を監視し、交渉サービスを向上させるためにフィードバックを使用し得る、交渉監視機能１１５であり得る。

実施形態では、交渉サービス１１０は、コンテンツ、状況コンテキスト、およびポリシー情報を分析することに基づいて、講じるべき措置の知識を蓄積して維持する、認知能力または人工知能を含み得る。そのような認知能力は、過去の状況、観察、決定、および措置から学習し、将来の決定を行うために、この知識を使用し得る。交渉サービス１１０の認知能力は、人間の認知プロセスに近い認知モデルに依拠し得る。この認知モデルは、把握および意思決定（すなわち、知識）機能性の範囲を定義し得る。交渉サービス１１０の認知能力は、交渉要求受け入れを決定するために交渉要求処理機能１１１によって、交渉相手および交渉方策を決定するために交渉意思決定機能１１２によって、交渉適応を決定するために交渉適応サービス１１３によって、および任意の他の決定または他の分析を行うために任意の他の交渉サービス機能によって、使用され得る。

交渉サービス１１０は、ＩｏＴサービス、ＩｏＴエンティティ、およびＩｏＴアプリケーショと相互作用するために種々のインターフェースを使用し得る。例えば、インターフェース１２１は、関連交渉機能による新しい交渉、交渉監視、および／または交渉適応をトリガし得るＩｏＴアプリケーション１２０から交渉要求を受信するために使用され得る。インターフェース１３１は、同様に関連交渉機能による新しい交渉、交渉監視、および／または交渉適応をトリガし得るＩｏＴエンティティ１３０から交渉要求を受信するために使用され得る。

実施形態では、インターフェース１５１は、種々のＩｏＴサービスと相互作用するために交渉サービス１１０によって使用され得る。例えば、交渉サービス１１０は、コンテンツ認識サービス１４５、コンテキスト認識サービス、仮想化サービス１４３等の他のサービスを決定するために、発見サービス１４１と相互作用し得る。インターフェース１５１はまた、協調および交渉に含まれ得る同一のサービスまたはサービスの部分を提供し得る、サービスプロバイダを発見するために使用され得る。

インターフェース１５１はまた、特定の職務スケジュールでサービスを提供するサービスプロバイダと交渉するように配信サービス１４２と相互作用するために、交渉サービス１１０によって使用され得る。例えば、配信サービス１４２は、サービスが要求されているときに、勤務中サービスプロバイダによって配信されることを確実にするように、インターフェース１５１を介して交渉サービス１１０と相互作用し得る。インターフェース１５１はまた、例えば、価格および他のサービス配信関連サービス品質（ＱｏＳ）パラメータを取り決めることによって、競合しているが同一のサービスを提供しているサービスプロバイダと交渉し、サービスを要求側に配信しようとしているサービスを決定するために、配信サービス１４２との相互作用のために使用され得る。インターフェース１５１はまた、途中ノード（すなわち、サービスプロバイダとサービス要求側との間の経路上のノード）がサービスの部分を進んで配信し、完全なサービスを提供することに役立つように、途中ノードの間で交渉するために、配信サービス１４２との相互作用のために使用され得る。

インターフェース１５１はまた、ＩｏＴサービス上でホストされる仮想化されたＩｏＴオブジェクトへのアクセスを取り決めるため、別のＩｏＴサービス上への仮想化されたＩｏＴオブジェクトのミラーリングを取り決めるため、１つのＩｏＴサービスから別のＩｏＴサービスへの仮想化されたＩｏＴオブジェクトのオフロードおよび／または移動を取り決めるため、ＩｏＴアプリケーションの要件を満たすように仮想化されたＩｏＴオブジェクトを適応させるためにＩｏＴサービスと交渉するため、および／またはエンティティあるいはサービスを仮想化するかどうか、および／または仮想化するときを決定するように適用可能なポリシーを取り決めるために、交渉サービス１１０によって仮想化サービス１４３との相互作用のために使用され得る。

インターフェース１５１はまた、コンテンツコピー、コンテンツ品質、およびコンテンツ形式を活用するために、交渉サービス１１０によってコンテンツ認識サービス１４４との相互作用のために使用され得る。例えば、ＩｏＴエンティティ１３０のうちの１つは、適合性のあるコンテンツサービスが、それに、他のＩｏＴエンティティから配信されることを要求し得る。適合性は、ＩｏＴエンティティのローカルコンテンツ、および／またはＩｏＴエンティティのローカルコンテンツと適合性があるコンテンツサービスを提供するＩｏＴエンティティの認識に基づいて、ＩｏＴエンティティによって、または交渉サービス１１０によって決定され得る。適合性が決定されると、適合コンテンツサービスが、再度、ＩｏＴエンティティによって、または交渉サービス１１０によってのいずれかで決定され得、ＩｏＴエンティティは、それに、適合サービスを提供する１つまたは複数の決定されたＩｏＴエンティティから、適合コンテンツサービスが配信されることを要求し得る。交渉サービス１１０は、要求ＩｏＴエンティティの代わりに、コンテンツ品質、コンテンツ形式、および／またはコンテンツ価格について、適合サービスを提供する１つまたは複数の決定されたＩｏＴエンティティと交渉し得る。さらなる交渉は、サービス負荷および要求ＩｏＴエンティティからの距離等の種々の要因に基づいて、コンテンツを配信することになるエンティティについて交渉することを含み得る。コンテンツの認識に基づいて、ネットワーク内の１つ以上の中間ＩｏＴエンティティは、コンテンツをキャッシュに格納するか、または記憶し得る。中間ＩｏＴエンティティは、記憶効率を向上させるように、エンティティの利用可能な記憶装置に基づいて、どのエンティティがコンテンツをキャッシュに格納するかを交渉し得る。

インターフェース１５１はさらに、交渉サービス１１０によって、コンテキスト認識サービス１４５との相互作用のために使用され得る。互にアクセス可能にされ得るサービスを取り決めるために、コンテキスト情報がＩｏＴエンティティおよびＩｏＴサービスによって使用され得る。例えば、ＩｏＴエンティティ１３０の第２のエンティティが、ＩｏＴエンティティ１３０の第３のエンティティにより近い、ネットワーク内の遠隔場所に位置し、第３のエンティティが第１のエンティティと同一のタイプのサービスを提供することをＩｏＴエンティティ１３０の第１のエンティティが認識している場合、第１のエンティティは、第２のエンティティへのサービスを拒否し、第３のエンティティがそれのより近くに常駐し、同一のサービスを提供することを第２のエンティティに通知し得る。

コンテキスト情報はまた、各々がいつこのサービスをネットワーク内の他のＩｏＴエンティティに利用可能にするであろうか関して、互に交渉するために、同一のサービスをホストするＩｏＴエンティティによって使用され得る。そうすることによって、ＩｏＴエンティティは、それぞれのサービスを調整してスケジュールに入れ、それによって、冗長サービス、および同一のサービスをホストするＩｏＴエンティティの各々への負荷を最小限化し得る。例えば、ＩｏＴエンティティ１３０のうちの第１のＩｏＴエンティティおよび第２のＩｏＴエンティティの両方が第１のサービスをホストする場合、第１のＩｏＴエンティティは、それが第１のサービスをホストすることを第２のＩｏＴエンティティに公表するか、または別様に発表し得る。次いで、第２のＩｏＴエンティティは、順に、それが利用可能であることを第１のＩｏＴエンティティに知らせ、第１のサービスのためのその好ましいサービススケジュールを提供するために、交渉メッセージを第１のＩｏＴエンティティに送信し得る。第１のサービスをホストするＩｏＴエンティティはまた、それらのそれぞれのサービス負荷を、第１のサービスをホストする他のエンティティに発表または公表し得る。第１のサービスをホストするＩｏＴエンティティは、各ＩｏＴエンティティが、サービスを要求するネットワーク内の他のＩｏＴエンティティにいつ第１のサービスを提供することができるかのスケジュールについて合意に達するように、メッセージを交換するか、または別様に相互作用し得る。交渉サービス１１０は、サービスのためのコンテキストの変化に基づいて適応し得ることに留意されたい。

インターフェース１５１はさらに、クラウド・ホスト交渉方策をサポートするために、ならびにＱｏＳおよび価格についてＩｏＴエンティティと交渉するために、交渉サービス１１０によってクラウドサービス１４６との相互作用のために使用され得る。

実施形態では、ＩｏＴエンティティは、交渉サービスへの受け入れを要求し得る。そのような交渉要求は、いくつかの形態のうちのいずれかを成し得る。実施形態では、交渉要求は、要求に含まれる要求目標を伴う交渉サービスへの受け入れに対する要求であり得る。

代替として、交渉要求は、１つ以上の適切な交渉相手を選択して返信する交渉サービスに対する要求であり得る。要求ＩｏＴエンティティ（本明細書では同義的に「要求側」と称され得る）は、交渉サービスから交渉相手情報を受信した後、交渉サービスがそれの代わりに交渉プロセスを実行することを要求するか、単独で交渉相手と交渉するか、または交渉を控えるかどうかを決定し得る。

別の実施形態では、要求は、適切な交渉方策を選択して返信する交渉サービスに対する要求であり得る。要求側は、交渉方策情報を受信した後、交渉サービスがそれの代わりに交渉プロセスを実行することを要求するか、単独で交渉相手と交渉するか、または交渉を控えるかどうかを決定し得る。

別の実施形態では、要求は、要求側がそれの代わりに交渉を実行するように交渉サービスに頼るであろうという指示を含み得る。次いで、交渉サービスは、続けて交渉相手および交渉方策を選択し、要求側の代わりに合意に達するように、選択された方策を使用して、選択された交渉相手と交渉し得る。

別の実施形態では、要求は、要求側を含む過去の類似交渉シナリオから交渉サービスがまとめた一般化交渉結果に要求側が進んで従うという指示を含み得る。

さらに別の実施形態では、要求は、交渉サービスが記憶している場合がある、別の交渉要求側の交渉方策に要求側が従いたいという指示を含み得る。他方の要求側は、ＩｏＴサービス、ＩｏＴエンティティ、またはＩｏＴアプリケーションであり得る。

実施形態では、要求は、１つ以上の特定条件が満たされる場合またはときに、加入要求側に交渉通知を送信してもらう目的のために要求側が交渉サービスに加入することを可能にし得る、加入情報を含み得る。そのような要求の中の加入情報は、ＩｏＴ交渉サービスが交渉通知をトリガすべき条件（例えば、ポリシー）を含み得る。代替として、加入要求の中に条件情報がないこともある。

図２は、交渉要求の受信時に、交渉サービスおよび／またはそのようなサービスを実行あるいはホストするエンティティによって行われ得る、例示的な受け入れ要求プロセス２００を図示する。図２に関して説明される機能、活動、およびプロセスのうちのいずれか、ならびに本明細書で開示される任意の他のプロセスまたは方法は、任意の順序で、任意の他の機能、活動、およびプロセスと併せて、ならびに分離して行われ得ることに留意されたい。図２に関して説明される機能、活動、およびプロセスのうちの任意のサブセット、ならびに本明細書で開示される任意の他のプロセスまたは方法は、説明される残りの機能、活動、およびプロセスを行わずに行われ得る。全てのそのような実施形態は、本開示の範囲内と見なされる。

ブロック２１０では、交渉サービスにおいて、交渉要求がＩｏＴエンティティから受信され得る。ブロック２２０では、要求受け入れ制御が、図３および４ならびに関連テキストでさらに詳細に記載にされるように行われ得る。ブロック２３０では、要求が受理されるかどうかが決定され得る。要求が受理されない場合、ブロック２３５では、要求が拒否されたことを示す応答が、要求エンティティに送信され得る。要求が受理された場合、ブロック２４０では、優先順位が、要求について決定され得、要求が、交渉サービスによるサービスのためのサービス待ち行列の中に配置され得る。ブロック２５０では、要求が拒否されたことを示す応答が、要求エンティティに送信され得る。

図３は、交渉要求受け入れプロセス中にいくつかの実施形態で使用され得る、例示的な信号フロー３００を図示する。実施形態では、交渉サービス３１０は、認知能力３１１を含み得る。交渉サービス３１０は、ＩｏＴエンティティ、ＩｏＴサービス、およびＩｏＴアプリケーションから交渉要求を選択的に受理し得る。交渉サービス３１０は、過去の要求および関連交渉結果の履歴を維持し得る。交渉サービス３１０は、交渉要求を受け入れるかどうかを決定するために、過去の要求および結果の記憶された履歴を活用し得る。

一実施例では、交渉要求側３２０は、交渉要求３２１を交渉サービス３１０に送信し得る。交渉サービス３１０は、ブロック３２２で、要求および交渉の記憶された履歴に照らして要求をチェックし、交渉要求側３２０からの同一または類似要求を有さないことを決定し得る。交渉サービス３１０は、認可されたエンティティ、アプリケーション、またはサービスのある個別のものあるいはそれらのグループのみが、交渉サービスを使用するように受け入れられることを可能にし得る、それに対して構成されたアクセス権に照らして交渉要求側３２０をチェックし得る。そのようなアクセス権は、受け入れられるエンティティ、アプリケーション、またはサービスのリスト（「ホワイトリスト」）、ブロックされるエンティティ、アプリケーション、またはサービスのリスト（「ブラックリスト」）、あるいはそれらの組み合わせとして、交渉サービス３１０において構成され得る。交渉サービスへのアクセスを制限することの任意の他の形態が、本開示の範囲内と見なされる。

交渉サービス３１０が交渉要求側３２０からの要求の履歴を有さないことを決定すると、交渉サービス３１０は、交渉要求側３２０を交渉サービスに対して受け入れるべきかどうかという決定のために、受け入れ要求３２３を認知能力３１１に提供し得る。この要求は、交渉要求３２１に含まれるデータの全て、一部を含み得るか、または全く含まないこともある。認知能力３１１は、本明細書に記載されるものを含む、任意の基準および方法を使用して、交渉要求側３２０を受け入れるかどうかに関する決定を行い得る。受け入れ決定を行うと、認知能力３１１は、受け入れ応答３２４を交渉サービス３１０に提供し得る。

交渉要求側３２０が交渉サービス３１０を使用することを許可される場合、交渉サービスへの受け入れを示す交渉応答３２５が、交渉要求側３２０に伝送され得る。次いで、交渉が、交渉サービス３１０と交渉相手３３０との間で、３２６において本明細書で開示されるように行われ得る。交渉相手３３０は、配信サービス３４０と同一のエンティティであり得るか、または交渉相手３３０は、別の交渉サービス等の配信サービス３４０の代わりに交渉する権限を与えられている別個のエンティティであり得ることに留意されたい。

交渉要求側３２０は、要求サービスを受信する前に、交渉要求３２１と実質的に同一である複製交渉要求３３１を交渉サービス３１０に送信し得る。交渉サービス３１０は、ブロック３３２で、要求および交渉の記憶された履歴に照らして要求をチェックし、以前に交渉要求側３２０から交渉要求３２１を受信し、交渉要求３２１が交渉要求３３１と実質的に同一であることを決定し得る。交渉サービス３１０はまた、交渉要求側３２０を交渉サービスに対して受け入れるかどうかの決定のために、別の受け入れ要求３３３を認知能力３１１に提供し得、受け入れ応答３３４を受信し得る。交渉要求３３１が重複要求であることを決定すると、交渉サービス３１０は、交渉要求の拒否を示す交渉応答３３５を交渉要求側３２０に伝送し得る。その一方で、３２７で、交渉要求側３２０は、要求されたサービスを受信し始めている。

交渉サービスは、交渉サービスを待つサービス待ち行列の中に受け入れられた交渉要求を配置し得る。しかしながら、サービス待ち行列は、制限または交渉サービスの構成により、満杯になり得る。交渉サービスは、交渉の緊急性または優先順位に基づいて、交渉要求の優先順位を決め得る。例えば、緊急イベント公表要求側と公表サービスとの間の交渉は、公表サービスとの交渉に対する他の要求より高い優先順位を与えられ得る。サービス待ち行列は、交渉要求のサービスの順序を定義するとともに、交渉要求がサービスを提供されるであろう様式も決定し得る。

図４は、交渉要求受け入れプロセス中にいくつかの実施形態で使用され得る、例示的な信号フロー４００を図示する。実施形態では、交渉サービス４１０は、認知能力４１１を含み得る。交渉サービス４１０は、ＩｏＴエンティティ、ＩｏＴサービス、およびＩｏＴアプリケーションから交渉要求を選択的に受理し得る。交渉サービス４１０は、過去の要求および関連交渉結果の履歴、ならびにＩｏＴエンティティ、ＩｏＴサービス、およびＩｏＴアプリケーションの特定のまたはグループに関連付けられる優先順位を維持し得る。

一実施例では、交渉要求側４２０は、交渉要求４２１を交渉サービス４１０に送信し得る。交渉サービス４１０は、ブロック４２２で、要求がサービスを提供され得るかどうかを決定するために、上で説明されるような要求の記憶された履歴に照らして、交渉サービス４１０において構成される任意のアクセス権、およびサービス待ち行列に照らして、要求をチェックし得る。これは、サービス待ち行列の現在の状態が交渉サービスに対する交渉要求側４２０の受け入れを可能にするであろうかどうかの決定のために、受け入れ要求４２３を認知能力４１１に提供することによって、行われ得る。この要求は、交渉要求４２１に含まれるデータの全て、一部を含み得るか、または全く含まないこともある。認知能力４１１は、受け入れ応答４２４を交渉サービス４１０に提供し得る。本実施例では、受け入れ応答４２４は、この時点で、交渉要求側４２０が受け入れられることを可能にされないことを示し得る。次いで、交渉要求４２１が拒否されることを示す、交渉応答４２５が、交渉要求側４２０に送信され得る。

次いで、交渉要求側４３０が、交渉要求４２６を交渉サービス４１０に送信し得る。交渉要求４２６は、交渉要求４２１より高い優先順位を有し得る。この優先順位は、交渉要求４２６の中で示され得、および／または交渉要求側４３０によって提供されるサービスに基づき得る。交渉サービス４１０は、ブロック４２７で、要求４２６がサービスを提供され得るかどうかを決定するように、上で説明されるような要求の記憶された履歴に照らして、交渉サービス４１０において構成される任意のアクセス権、およびサービス待ち行列に照らして、要求をチェックし得る。これは、サービス待ち行列の現在の状態が交渉サービスに対する交渉要求側４３０の受け入れを可能にするであろうかどうかの決定のために、受け入れ要求４３１を認知能力４１１に提供することによって、行われ得る。この要求は、交渉要求４２６に含まれるデータの全て、一部を含み得るか、または全く含まないこともある。認知能力４１１は、受け入れ応答４３２を交渉サービス４１０に提供し得る。本実施例では、受け入れ応答４３２は、この時点で、交渉要求側４３０が受け入れられることを可能にされることを示し得る。これは、要求４２６および／または交渉要求側４３０の緊急状態または優先順位に基づき得る。次いで、交渉要求４２６が許可されていることを示す、交渉応答４３３が交渉要求側４３０に送信され得る。交渉応答４３３は、交渉要求側４３０が高い優先順位を与えられていることを示し得る。次いで、交渉が、交渉サービス４１０と交渉相手４４０との間で、４３４において本明細書で開示されるように行われ得る。

交渉要求がサービスを提供される準備ができている、すなわち、それが受け入れられており、現在はサービス待ち行列の先頭にあることを決定すると、交渉サービスプロセスが開始し得る。図５は、交渉要求にサービスを提供するための例示的なプロセス５００を図示する。ブロック５０５では、交渉サービスが、そのサービス待ち行列の先頭にある交渉要求を選択し得る。ブロック５１０では、交渉サービスは、要求が加入要求であるかどうかを決定し得る。もしそうであれば、交渉サービスは、ブロック５１５で、本明細書でさらに説明されるように加入および通知条件を確立し得る。加入確立の成功または失敗を示す応答もまた、要求側に送信され得る。

要求が任意の他のタイプの交渉要求である場合、ブロック５２０で、要求が交渉目標を含むかどうかを決定することによって、要求の妥当性が検証され得る。要求で特定された交渉目標がない場合、ブロック５２５で、交渉サービスは、交渉相手および／または方策が交渉要求で提供されているかどうかを決定し得る。もしそうでなければ、ブロック５３０で、要求が拒否されたことを示す拒否メッセージが、要求側に送信され得る。拒否の理由は、拒否メッセージの中で示され得る。

ブロック５２５で、交渉相手および方策が要求側によって指定されていることが決定された場合、交渉サービスは、ブロック５８５で、要求側の代わりに交渉を行う。

ブロック５２０を再度参照すると、要求が交渉目標（例えば、標的交渉相手および／または方策）を含まない場合には、ブロック５３５で、要求側が、本明細書でさらに詳細に説明されるような過去の類似交渉シナリオから、交渉サービスによってまとめられる一般化交渉方策を進んで使用するかどうかに関して、決定が行われ得る。一般化交渉方策および／または標的相手の受理の指示は、要求に含まれ得るか、または要求が交渉目標を含むことができない場合に仮定され得る。要求側が一般化交渉方策を進んで使用する場合、交渉サービスは、ブロック５６０で、一般化交渉方策および相手を使用し、ブロック５５０で、この要求のための交渉相手および方策を決定するためにその認知能力に問い合わせを行う必要がない。

ブロック５３５で、要求側が一般化交渉方策を進んで使用しないと決定された場合には、ブロック５４０で、過去の交渉が使用され得るかどうかに関して決定が行われる。これは、あるピアＩｏＴアプリケーション、エンティティ、またはサービスの交渉方策を使用することを含み得る。もしそうであれば、ブロック５５５で、交渉サービスは、過去の交渉方策および相手を決定し、ブロック５５０で、決定された交渉相手および方策としてそれらを使用する。ブロック５４０で、過去の交渉が使用されないであろうとの決定が行われた場合、ブロック５４５で、交渉サービスは、この要求のための交渉相手および方策を決定するためにその認知能力に問い合わせを行い、ブロック５５０で、決定された交渉相手および方策を使用する。

交渉サービスは、交渉相手および方策を決定した後、要求側が要求側の代わりに交渉を実行するようにそれに要求するかどうかを決定し得る。このプロセスは、要求側が交渉相手を要求するかどうかを交渉サービスが決定する、ブロック５６５から始まる。もしそうであれば、決定された交渉相手が要求側に送信される。交渉相手が、要求側が要求した唯一の情報である場合、交渉サービスは、認知能力を使用しないこともあり、交渉方策が別様に決定されるであろうブロック５４５を飛ばし得ることに留意されたい。

要求側がブロック５７５で決定されるような交渉方策を要求する場合、決定された交渉方策が、ブロック５８０で要求側に提供され得る。交渉方策が、要求側が要求した唯一の情報である場合、交渉サービスが認知能力を使用しないこともあり、交渉相手が別様に決定されるであろうブロック５４５を飛ばし得ることに留意されたい。また、要求側が単独で交渉を実行するために方策および相手を要求し得、そのような実施形態では、図５のプロセスが完了し得ることにも留意されたい。要求側がそれの代わりに交渉サービスに交渉を実行してもらいたい場合、交渉は、ブロック５８５で交渉サービスによって行われ、交渉の結果が、ブロック５９０で要求側に提供される。

図６は、交渉相手を決定するためにいくつかの実施形態で使用され得る、例示的な信号フロー６００を図示する。実施形態では、交渉サービス６１０は、認知能力６１１を含み得る。一実施例では、交渉要求側６３０は、交渉要求６２１を交渉サービス６１０に送信し得る。要求が許可されるべきことを決定すると、交渉要求６２１が受理されることを示す交渉応答６２５が、交渉要求側６３０に送信され得る。

実施形態では、要求６２１は、要求側６３０がそれの代わりに交渉サービス６１０に交渉してもらいたい相手の指示を含み得る。要求６２１が交渉相手の指示を含まない場合、６２６で、交渉サービスは、要求されたＩｏＴサービスを提供するＩｏＴエンティティを発見するために、発見サービス６２０への要求を開始し得る。次いで、交渉サービスは、認知能力が、６２７で、交渉相手としての機能を果たすべきＩｏＴエンティティを発見結果から決定することを、６３１で要求し得る。決定された交渉相手は、６３２で返信され、次いで、交渉が、交渉サービス６１０と交渉相手６４０との間で、６３４において本明細書で開示されるように行われ得る。

交渉サービスが、交渉要求側の代わりに交渉方策を制御し得る。方策が、その中で提供されている場合、それは、要求側から受信される要求から決定され得る。代替として、交渉サービスは、いずれか一方のエンティティに対する利用可能なリソース（例えば、処理能力、メモリ、帯域幅等）、いずれか一方のエンティティに対するオンラインおよびオフラインスケジュール等のＩｏＴサービスプロバイダおよび要求側のコンテキストに基づいて、方策を決定するために、その認知能力を使用し得る。図７は、例示的なセンサノードおよび交渉サービス構成７００を図示する。本実施形態では、センサノード７２１−７２５の各々は、光センサ、温度センサ、運動検出器等の任意のタイプのセンサノードであり得る。これらのセンサノードのカバー領域は、カバー領域の完全検出を提供するために、全てが同時に動作している必要がないように重複し得る。したがって、センサノードは、依然としてカバー領域の完全検出があることを確実にする、各センサノードがオンおよびオフになるであろうときのスケジュールを取り決めることを所望し得る。各センサノードが各他のセンサノードと直接交渉する（それは、１つのセンサにつき４回の交渉セッションを必要とする）よりもむしろ、センサノード７２１−７２５は、交渉サービス７１０を使用し、１つのセンサにつき単一の交渉セッションを有し得る。実施形態では、交渉プロセスは、センサノード７０１が、指定交渉相手（例えば、センサノード７０２等の他のセンサノードのうちの１つ）および交渉方策（例えば、最低受信可能範囲冗長性を達成する）とともに交渉要求を送信するときに開始され得る。

図８は、例えば、図７に関して説明されるもの等の状況の必要性に対処し得る、交渉方策を決定するために、いくつかの実施形態で使用され得る、例示的な信号フロー８００を図示する。実施形態では、交渉サービス８１０は、認知能力８１１を含み得る。交渉サービス８１０は、センサノード８０１から交渉要求を受信し得、８２１で応答を送信し得る。交渉サービス８１０は、８２２で、認知能力８１１が交渉の相手を決定することを要求し得る。交渉サービス８１０は、実施形態では、認知能力８１１を介して、発見サービス８２０が、センサノード１と同じ領域内の隣接センサノードのリストを返信することを要求し得、８２３で、要求されたリストを受信し得る。本実施例では、同じ領域内の他のセンサノードは、センサノード８０２、８０３、８０４、および８０５である。このリストに基づいて、認知能力８１１は、８２４で、センサノード８０２−８０５が標的センサノードであることを決定し得、８２５で、この情報を交渉サービス８１０に提供し得る。

示される８２１で、要求として交渉通知のみをセンサノード８０２に送信する代わりに、交渉サービス８１０は、交渉通知８２６をセンサノード８０２に送信して応答８２７を受信し、交渉通知８２８をセンサノード８０５に送信して応答８２９を受信し、センサノード８０１と同じ領域内の各センサに対してそのようにする。センサノードの各々は、そのバッテリレベルが低い等のために、交渉通知を拒否し得、またはスリープモードであるため応答しないこともある。例えば、センサノード８０２、８０３、および８０４が、交渉受理確認を返信し得る一方で、センサノード８０５は、交渉拒否確認を送信することによって交渉に参加することを拒否し得る。受理および拒否確認は、含まれる交渉者を決定するために、交渉サービス８１０によって８３１で使用され得る。８３２では、交渉サービス８１０が、方策を決定する要求とともに、この情報を認知能力８１１に提供し得る。

センサノード８０１−８０４の間の交渉のための向上した方策を決定するために、コンテキスト認識サービス８３０は、４つのセンサノードの各々のバッテリ寿命を提供することを８３３で認知能力８１１によって要求され得る。このコンテキスト情報および交渉の目標に基づいて、認知能力８１１は、８３４で、ノードが構成される領域のノードによる受信可能範囲の少なくとも最小限の冗長性を提供する、４つのセンサノードの間でノードの作業を分配するためのスケジュールを含む、方策を決定し得る。そのような交渉方策は、後に確認のためにセンサノード１、２、３、４に送信される。方策は、応答８３５で交渉サービス８１０に提供され得る。８３６では、交渉サービス８１０が、センサノード８０１の作業スケジュールをそのノードに送信し、そのノードから受信の確認を受信し得る。同様に、８３７、８３８、および８３９で、交渉サービス８１０は、それぞれ、センサノード８０２、８０３、および８０４のための作業スケジュールを送信し、各々から応答を受信し得る。

交渉サービスは、ポリシー変更またはコンテキスト変更により調整され得る。交渉サービスポリシーは、コンテキスト、ソフトウェア定義設定、他のサービスからの入力、ならびに任意の他の基準および条件に基づいて、動的に調整され得る。ポリシーが動的であり得るため、実施形態では、交渉決定およびパラメータもまた、ポリシーの変更に対処するように動的に調整され得る。

図９は、要求側の移動性に応答して交渉適応の実施例を提供する、例示的な構成９００を図示する。最初に、通信９０１で、交渉要求側９２０が、プロキシサービスのために交渉サービス９１０からの交渉サービスを要求し得る。要求された交渉は、サービス変更を伴ういくつかの実施形態では、要求側９２０がプロキシサービス９３１によるプロキシサービスを提供され得るように、９０２で行われ得る。本実施例では、交渉サービス９１０は、プロキシサービスのための交渉相手を決定し得る。交渉サービス９１０は、プロキシサービスプロバイダ（例えば、プロキシサービス９３１およびプロキシサービス９３２）を発見し得る。交渉サービス９１０の認知能力は、要求のコンテキストおよび／または要求側に基づいて、プロキシサービスプロバイダを決定し得る。本実施例では、関連コンテキストは、場所であり得る。交渉サービス９１０は、プロキシサービス９３１が任意の他のプロキシサービスより交渉要求側９２０に近いため、交渉要求側９２０の現在の場所コンテキストのための好ましいプロキシサービスプロバイダがプロキシサービス９３１であることを決定し得る。したがって、交渉サービス９１０は、交渉要求側９２０の代わりに、プロキシサービスのためにプロキシサービス９３１と交渉し得る。しかしながら、交渉要求側９２０は、新しい場所に移動し得る９０４。交渉サービス９１０は、コンテキスト認識サービスからコンテキスト変更を知らされ得る。交渉サービス９１０および／またはその認知能力は、プロキシサービス９３２が、利用可能なプロキシサービスの間で交渉要求側９２０に現在最も近接していることを決定することによって、コンテキスト変更に適応し得る。それに応答して、交渉サービス９１０は、９０５で、交渉要求側９２０の代わりに、プロキシサービスのためにプロキシサービス９３２と交渉し、通信９０４で、プロキシサーバの変更を交渉要求側９２０に通知し得る。

図１０は、図９に関して説明されるような交渉要求側の移動性等の変化する条件に交渉サービスを適応させるために、いくつかの実施形態で使用され得る、例示的な信号フロー１０００を図示する。実施形態では、交渉サービス１０１０は、認知能力１０１１を含み得る。交渉サービス１０１０は、交渉要求側１０２０から交渉要求を受信し得、１０２１で応答を送信し得る。交渉サービス１０１０は、１０２２で、認知能力１０１１が交渉の相手を決定することを要求し得る。交渉サービス１０１０は、実施形態では、認知能力１０１１を介して、コンテキスト認識サービス１０３０が要求側１０２０の場所の指示を返信することを要求し得、１０２３で指示を受信し得る。受信された場所に基づいて、認知能力１０１１は、１０２４で、交渉要求側１０２０が、利用可能なプロキシサービスプロバイダの間からプロキシサービスプロバイダ１０４０に最も近接している場所にあることを決定し得る。プロキシサービスプロバイダ情報は、１０２５で、交渉サービス１０１０に提供され得、交渉サービス１０１０は、交渉要求側１０２０の代わりに、１０２５で交渉要求側１０２０のためのプロキシサービスのために交渉し得る。

１０３１では、交渉要求側１０２０が、プロキシサービスプロバイダ１０４０よりプロキシサービスプロバイダ１０５０に近接し得る、異なる領域へ移動し得る。１０３２では、コンテキスト変更通知が、コンテキスト認識サービス１０３０によって交渉サービス１０１０に提供され得る。コンテキスト変更通知１０３２は、交渉要求側１０２０の現在の場所を含み得るか、または交渉サービス１０１０に交渉要求側１０２０に対する現在の場所を決定させる指標を含み得る。１０３３では、交渉サービス１０１０は、認知能力１０１１が１０３４で決定し得る、交渉要求側１０２０の現在の場所に基づいて、認知能力１０１１が現在の最良プロキシサービスプロバイダを決定することを要求し得る。プロキシサービスプロバイダ１０５０が、交渉要求側１０２０の現在の場所に基づいて、交渉要求側１０２０のための現在の最良プロキシサービスプロバイダであるという指示を含む、応答が、１０３５で交渉サービス１０１０に提供され得る。それに応答して、交渉サービス１０１０は、交渉要求側１０２０の代わりに、１０３６で交渉要求側１０２０のためのプロキシサービスのために交渉し得る。

交渉サービスは、過去の交渉プロセスで使用された、決定された交渉相手および交渉方策等の、過去の交渉からの交渉結果および関連データを記憶し得る。交渉サービスは、類似交渉要求が交渉要求側から受信されることを決定するときに、このキャッシュに格納された情報を使用し得る。交渉サービスはまた、交渉プロセスからのまとめられたデータに基づいて、一般化交渉方策を決定し得る。交渉サービスは、現在の交渉シナリオでパターンを検出し、類似する現在の交渉で過去の交渉パラメータおよびデータを使用して、これらのパターンを現在の交渉要求に関係付け得る。これは、交渉方策、相手等を決定するために、その認知能力を採用することから、交渉サービスを解放し得る。

図１１は、ＩｏＴエンティティおよび交渉サービスの例示的な構成１１００を図示する。データ消費者１１３１−１１３４は、消費者、小売店、キャリア、サービスプロバイダ、ネットワークプロバイダ等のデータの任意の消費者であり得る。本実施例では、データ消費者１１３１−１１３４は、医師１１３１、病院１１３２、医療保険１１３３、および医学研究員１１３４等の医療関連エンティティである。データプロバイダ１１２１−１１２５は、患者、顧客、消費者、家庭または事業内のセンサノード（例えば、温度センサ、運動センサ）等の任意のデータプロバイダであり得る。本実施例では、データプロバイダ１１３１−１１３４は、患者または別様に医師の保護下にある人々に関連付けられるデバイスまたはエンティティであり得る。

交渉サービス１１１０は、データプロバイダ１１２１−１１２５のうちの１つ等のデータプロバイダの代わりに、１つ以上の交渉プロセスを行った後に、交渉ポリシーを要約および／または一般化し得る。例えば、交渉サービス１１１０は、データ消費者およびデータプロバイダの各ペアに使用することができる、共通交渉方策を決定し得る。これは、データ消費者およびデータプロバイダのペアの間で取り扱われるデータに対する第１の要求において決定される、初期交渉方策に基づき得る。図１１の表１１４０は、交渉サービス１１１０が相互作用する各データ消費者に対してそれが維持し得る情報の例を提供する。このデータは、特定のデータプロバイダに対して特定のデータ消費者に提供されることも、提供されないこともある、データを示し得る。例えば、表１１４０が、データプロバイダ（例えば、患者）１１２２に関連付けられたデータ制限を表す場合、交渉サービス１１１０は、名前、年齢、郵便番号、および住所のみを保険プロバイダに提供する一方で、名前、年齢、郵便番号、住所、および薬剤情報をデータプロバイダ１１２２の医師に提供し得る。表１１４０または類似データは、交渉サービス１１１０と相互作用する全てのＩｏＴエンティティに適用されるように一般化され得る。この交渉一般化方法は、データプロバイダがサービスを要求するたびに交渉方策を決定することにおける認知能力の負荷を減少させ得る。

以前の交渉プロセスからの決定された交渉相手および方策等の交渉結果は、以前の交渉結果を生成した元の交渉に含まれたもの以外のサービスおよびクライアントによって加入され得る。類似交渉トピックに関心がある要求側が、この情報に加入するように要求し得る。加入された交渉活動への任意の適応が、加入者への通知を生成し得る。この加入機構は、新しい交渉条件への加入者の自律適応を可能にし得る。加入者が加入からの交渉結果を使用している場合、加入された交渉条件またはパラメータへの任意の変更が、新しい条件またはパラメータに自動的に適応するように加入者をトリガし得る。交渉加入により、他のエンティティが、交渉結果を再利用し、それに従うことができる。

図１２は、いくつかの加入シナリオで使用され得る、例示的な非限定的構成１２００を図示する。ここでは、仮想化ポリシーへの加入である。仮想化サービス１２２０は、１２１２で、交渉サービス１２１０が仮想化ポリシーに対してＩｏＴオブジェクト１２６０と交渉することを要求し得る。ポリシーは、例えば、ＩｏＴオブジェクト１２６０の仮想化が起こり得るとき、およびＩｏＴオブジェクト１２６０が仮想化されるであろう場所等に関連付けられ得る。１２１４での交渉は、ＩｏＴオブジェクト１２６０と交渉サービス１２１０との間で起こり得る。仮想化サービス１２２０とＩｏＴオブジェクト１２６０との間で交渉合意に達した後、１２１８で、ＩｏＴオブジェクト１２６０は、仮想化ポリシーに基づいて、仮想化されたＩｏＴオブジェクト１２４１としてＩｏＴクラウドサーバ１２４０において仮想化され得る。

１２２６では、仮想化サービス１２２０が、ＩｏＴクラウドサーバ１２５０において、仮想化されたＩｏＴオブジェクト１２５１としてＩｏＴオブジェクト１２７０を仮想化し得る。ＩｏＴクラウドサーバ１２５０は、１２２２で要求により、仮想化されたＩｏＴオブジェクト１２５１によって使用されるものと同一の仮想化ポリシーに加入し、１２２４で同一の仮想化ポリシーを受信し得る。加入された仮想化ポリシーを変更する任意の交渉適応がある場合、ＩｏＴクラウドサーバ１２５０は、１２１２で交渉適応ポリシーが変更されるときに通知され得る。ＩｏＴクラウドサーバ１２５０は、１２１２で交渉適応ポリシーが変更されるときに通知され得る。それに応答して、ＩｏＴクラウドサーバ１２５０は、１２３０で、仮想化サービス１２２０が新しいポリシーに基づいて適応を行うことを要求し得る。

実施形態では、同一のサービスを提供する２つのサービスプロバイダが、サービス職務協調のために互に交渉し得る。一方のサービスプロバイダは、オンラインであるとき、両方が常にオンラインである必要がないように、他方の（おそらくオフラインの）サービスプロバイダに意図されたサービス要求を取り扱い得、したがって、電力等のリソースを節約する。

図１３は、サービス職務循環およびオフロードに使用される交渉サービスの実施例が実装され得る、例示的な構成１３００を図示する。ＩｏＴエンティティ１３１０は、ソフトウェア定義サービス１３１１を提供し得、ピアＩｏＴエンティティに、例えば、１３５１でＩＴエンティティ１３３０にそれを公表し得る。ソフトウェア定義サービスは、任意の数およびタイプの物理的デバイスによって行われ得るサービス、およびサービスを提供するように割り当てられる物理的デバイスが必要に応じて変化し得るサービスであり得るが、それは、現在使用されている物理的デバイス構成にかかわらず、一貫したソフトウェアインターフェースをユーザまたは他のエンティティに提供する。ソフトウェア定義サービス１３３１を提供するＩｏＴエンティティ１３３０は、１３５１でＩｏＴエンティティ１３１０からソフトウェア定義サービス１３３１の公表を受信することに基づいて、ソフトウェア定義サービス１３３１がソフトウェア定義サービス１３１１と同一または類似のサービスであることを決定し得る。それに応答して、ＩｏＴエンティティ１３３３は、１３５２でＩｏＴエンティティ１３１０との交渉を開始し、同一のソフトウェア定義サービスに対して、いつ、およびどれだけ、一方のエンティティが別のエンティティのサービス要求をオフロードするかを含む、ＩｏＴエンティティ１３１０と職務循環を確立し得る。例えば、エンティティは、一方または他方のエンティティが同一のサービスに対する全ての要求を取り扱うであろうとき、および／または要求側への近接性等の任意の基準に基づいて他方のエンティティへの要求をオフロードするときを決定し得る。

ＩｏＴエンティティ１３４０は、１３５３で、所望のソフトウェア定義サービスがＩｏＴエンティティ１３１０に位置することを、ＩｏＴエンティティ１３５０によって提供される発見サービス１３５１から発見し得る。ＩｏＴエンティティ１３４０は、１３５４で、ＩｏＴエンティティ１３１０から、ソフトウェア定義サービス１３１１を介して、所望のソフトウェア定義サービスの配信を要求し得る。しかしながら、ＩｏＴエンティティ１３４０は、ＩｏＴエンティティ１３１０から遠く離れている場合があり、つまり、これらのエンティティの間のトラフィックが移動しなければならない多くのネットワークノードがあり得る。代替として、これらのノードの間の距離、したがって、ネットワーク待ち時間は、ＩｏＴエンティティ１３４０と要求されたサービスを提供する別のエンティティとの間の距離よりはるかに大きくあり得る。ＩｏＴエンティティ１３１０は、要求側により近い、および／またはサービス要求をオフロードするために利用可能であるため、ＩｏＴエンティティ１３３０がサービスを要求側ＩｏＴエンティティ１３４０に送達する最も適切なエンティティであることを決定し得る。したがって、ＩｏＴエンティティ１３１０は、１３５５で、ＩｏＴエンティティ１３４０により近くあり得るＩｏＴエンティティ１３３０に要求をリダイレクトし得る。次いで、ＩｏＴエンティティ１３３０は、１３５６で、サービスをＩｏＴエンティティ１３４０に提供し得る。結果として、交渉サービスは、待ち時間および効率においてＩｏＴエンティティ１３４０の性能を大きく向上させる。

図１４は、図１３に関して説明される状況等の、サービス職務循環およびオフロードを確立するように交渉サービスを使用するために、いくつかの実施形態で使用され得る、例示的な信号フロー１４００を図示する。実施形態では、交渉サービス１４１０は、認知能力１４１１を含み得る。交渉サービス１４１０は、１４２１で、ＩｏＴエンティティ１４２０から交渉要求を受信し、それに応答し得る。交渉サービス１４１０は、１４２２で、認知能力１４１１が交渉方策を決定することを要求し得る。交渉サービス１４１０は、実施形態では、認知能力１４１１を介して、コンテキスト認識サービス１４３０がＩｏＴエンティティ１０２０の関連コンテキストの指示を返信することを要求し得、１４２３では、指示を受信し得る。このコンテキスト情報は、ＩｏＴエンティティ１４２０およびＩｏＴエンティティ１４５０の両方が、同一または実質的に類似のサービスを提供することを、認知能力１４１１が決定することを可能にする、情報を含み得る。この情報は、スマートＩｏＴサービスプロファイル、ＩｏＴエンティティ１４２０および１４５０の場所、提供されたサービスのオンラインスケジュール等を評価することによって、決定され得る。認知能力１４１１は、１４２４で、２つのエンティティ間の交渉のための協調詳細および実行可能な方策を決定し、１４２５で、それを交渉応答として交渉サービス１４１０に提供し得る。

交渉サービス１４１０は、１４２６で、協調提案とともに交渉結果要求をＩｏＴエンティティ１４５０に送信し得る。ＩｏＴエンティティ１４５０は、交渉サービス１４１０と直接交渉し得るか、または１４２７で、交渉要求をその選択された交渉サービス１４４０に送信し得る。後者の場合、交渉サービス１４４０が、１４２８でＩｏＴエンティティ１４５０から交渉要求を受け入れた後、認知能力は、交渉方策を決定する要求を受信し、１４２９で交渉要求を受理するか拒否するかどうかに関して交渉方策決定および決定を行い、１４３１で交渉サービス１４４０に方策を知らせる。利用可能なサービススケジュール、ＩｏＴエンティティ１４２０と共有するリソースの量およびタイプ、ＩｏＴエンティティ１４５０が提供し得る同時サービスタスクの数等の他の協調詳細も特定され得る。

１４３２では、交渉サービス１４４０が、交渉受理通知をＩｏＴエンティティ１４５０に提供する。ＩｏＴエンティティ１４５０は、通知１４３３を交渉サービス１４４０に送信することによって交渉受理を確認し、１４３４で交渉結果応答を交渉サービス１４１０に返信し得る。交渉サービス１４１０は、１４３５で、ＩｏＴエンティティ１４２０が１４３６で確認により応答し得るＩｏＴエンティティ１４２０に交渉受理確認の通知を送信し得る。

同一または実質的に類似するＩｏＴサービスをホストするが、消費者または他のユーザのために互に競合する、異なるＩｏＴエンティティがあり得る。実施形態では、顧客は、最低価格で所望のＱｏＳを達成するために、交渉サービスが潜在的なＩｏＴサービスプロバイダと交渉することを要求し得る。図１５は、交渉サービスを使用する、そのような交渉プロセスの一実施例を示す。本実施形態では、交渉サービス１５１０は、認知能力１５１１を含み得る。交渉サービス１５１０は、１５２１で、ＩｏＴエンティティ顧客１５２０から交渉要求を受信し、それに応答し得る。要求は、顧客１５２０が求めているサービスのタイプの指示、および顧客１５２０がサービスの代金を支払うために提供する価格を含み得る。他の情報も提供され得る。交渉サービス１５１０は、認知能力１５１１に交渉受け入れ要求を送信し得、そして、認知能力１５１１は、交渉要求を受け入れることを決定し得る。交渉サービス１５１０は、１５２２で、発見サービス１５２２からの、要求されたサービスを提供する潜在的なサービスプロバイダに関する情報を要求し、受信し得る。次いで、交渉する最も適切なサービスプロバイダを決定するために、交渉サービス１５１０は、１５２３で交渉相手要求を認知能力１５１１に送信し得る。

認知能力１５１１は、近接性、価格等を含む、任意の基準を使用して、顧客１５２０の代わりに交渉サービス１５１０が交渉するであろう２つのサービスプロバイダ、すなわち、ＩｏＴサービスプロバイダ１５５０（図１５の「ＩｏＴ ＳＰ１５５０」）およびＩｏＴサービスプロバイダ１５６０（図１５の「ＩｏＴ ＳＰ１５６０」）があることを決定し得る。この情報は、１５２６で交渉サービス１５１０に提供され得る。交渉サービス１５１０は、１５２６で、２つのサービスプロバイダと交渉するための交渉方策について認知能力１５１１に問い合わせを行い得る。認知能力１５１１は、交渉方策を開発するために使用され得る情報を取得するために、コンテキスト認識サービス１５３０に問い合わせを行い得る。このコンテキスト情報は、異なるＱｏＳを伴う各ＩｏＴサービスプロバイダの課金ポリシー、顧客１５２０にサービス提供するためにサービスプロバイダによって必要とされるリソース、各サービスプロバイダから顧客要求側までの距離等を含み得る。この情報を使用して、認知能力１５１１は、１５２８で方策を決定し、１５２９で方策を交渉サービス１５１０に提供し得る。次いで、交渉サービス１５１０は、サービスプロバイダ１５５０および１５６０の各々と、それぞれ、１５３１および１５３２で交渉し、ＩｏＴサービスプロバイダから両方の交渉応答を受信した後に、交渉および受信したデータに基づいてサービスプロバイダを選択し得る。交渉サービス１５１０は、１５３３で、選択されたサービスプロバイダデータを顧客に送信し得る。

提案された実施形態は、ＥＴＳＩ Ｍ２Ｍアーキテクチャ等の既存のＩｏＴシステムおよび規格に組み込まれ、実装され得る。そのような実施形態では、知的交渉サービスが、既存のサービス能力の上に追加の機能性を積み重ねることによって実装される交渉サービス能力であるようにマップされ得る。図１６は、そのような実施形態が実装され得る、例示的アーキテクチャ１６００を図示する。交渉サービス能力１６２０（図１６の「交渉ＳＣ１６２０」）は、ネットワーク１６１０（「クラウド」とも称され得る）に常駐し得、全てのＭ２Ｍデバイス、ゲートウェイ、サーバは、交渉サービス能力１６２０にアクセスするために使用され得る、図１６でインターフェース１６４１−１６４３として示される新しいサービスクラウドインターフェースをサポートし得る。ネットワークアプリケーション１６３４をサポートする、Ｍ２Ｍネットワークサービス能力層（ＮＳＣＬ）１６３１は、サービスクラウドインターフェース１６４１を介して、交渉サービス能力１６２０に直接アクセスし得る。ゲートウェイアプリケーション１６３５をサポートするＭ２Ｍゲートウェイサービス能力層（ＧＳＣＬ）１６３２は、ＮＳＣＬ１６３１への中間インターフェース１６５１を介して間接的に、またはサービスクラウドインターフェース１６４２を介して直接、交渉サービス能力１６２０にアクセスし得る。デバイスアプリケーション１６３６をサポートするＭ２Ｍデバイスサービス能力層（ＤＳＣＬ）１６３３は、ＮＳＣＬ１６３１への中間インターフェース１６５２を介して間接的に、またはサービスクラウドインターフェース１６４３を介して直接、交渉サービス能力１６２０にアクセスし得る。

Ｍ２Ｍサービス能力層（ＳＣＬ）は、交渉サービス能力１６２０とＭ２ＭＳＣＬとの間の相互作用のために使用され得る、交渉サービス能力１６２０へのサービスクラウドインターフェース（例えば、１６４１−１６４３）をサポートするように追加の機能性を含み得る。交渉サービス能力１６２０は、既存のＭ２Ｍ ＳＣＬ（例えば、ＮＳＣＬ１６３１、ＧＳＣＬ１６３２、ＤＳＣＬ１６３３）を発見し得る。交渉サービス能力１６２０は、新たに発見されたＳＣＬをＭ２Ｍ ＳＣＬに公表または発表し得る。交渉サービス能力１６２０はまた、その挙動を動的に構成し、そのリソースツリーにアクセスすることを含む、Ｍ２ＭＳＣＬにアクセスし、それを監視し、制御し得る。交渉サービス能力１６２０はさらに、複数の他のＭ２Ｍ ＳＣＬによって共有され、同時にアクセスされ得る。Ｍ２Ｍ
ＳＣＬは、クラウドから交渉サービス能力１６２０を発見し得る。Ｍ２Ｍ ＳＣＬ（特にＮＳＣＬ１６３１等のＮＳＣＬ）は、それ自体をクラウド内の交渉サービス能力１６２０に公表または発表し得る。Ｍ２Ｍ ＳＣＬは、それ自体またはそのホストされたＭ２Ｍ
ＳＣＬにサービス提供するように、クラウド内の交渉サービス能力１６２０にアクセスして活用し得る。

図１７の例示的な構成１７００によって図示される別の実施形態では、交渉サービス能力１７１０（図１７の「交渉ＳＣ１７１０」）は、各Ｍ２Ｍデバイス、ゲートウェイ、および／またはサーバ１７２０（例えば、ＮＳＣＬ、ＧＳＣＬ、ＤＳＣＬ）（図１７で「既存のＭ２Ｍ ＳＣ１７２０」において集合的に示される）において構成され得、サービス能力間の新しい直接インターフェース１７１１−１７１５が使用され得る。例えば、Ｍ２Ｍ ＮＳＣＬが交渉サービス能力１７１０をホストし得る一方で、他のＳＣＬ（例えば、ＧＳＣＬ、ＤＳＣＬ）は、独自の交渉サービス能力をローカルに有しないが、Ｍ２Ｍ ＮＳＣＬを使用することによって交渉サービス能力にアクセスする。

開示された実施形態によって行われ得る交渉は、Ｍ２ＭデバイスとＭ２Ｍゲートウェイとの間、Ｍ２ＭゲートウェイとＭ２Ｍサーバとの間等の登録プロファイルについての交渉を含み得る。開示された実施形態によって行われ得る別の交渉は、Ｍ２Ｍデバイスクラスタリングおよび作業スケジュールである。開示された実施形態によって行われ得る別の交渉は、Ｍ２ＭデバイスがデータをＭ２Ｍゲートウェイに送信する状況についてのＭ２ＭデバイスとそのＭ２Ｍゲートウェイとの間の交渉である。開示された実施形態によって行われ得るさらに別の交渉は、Ｍ２Ｍデバイスを管理することの協調についてのＭ２Ｍゲートウェイ間の交渉である。開示された実施形態によって行われ得るなおも別の交渉は、データ共有および価格決定のための異なるＭ２ＭサービスプロバイダのＭ２Ｍサーバ間の交渉である。開示された実施形態によって行われ得る別のさらなる交渉は、条件付き加入を可能にするための加入通知に対する条件の交渉である。

図１８Ａは、ＩｏＴ知的交渉サービスのためのシステムおよび方法の１つ以上の開示された実施形態が実装され得る、例示的Ｍ２ＭまたはＩｏＴ通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴの構成要素ならびにＩｏＴサービス層等であり得る。

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

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

図示したＭ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービスプラットフォーム２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍ端末デバイス１８およびＭ２Ｍゲートウェイデバイス１４の管理および監視等のサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２はまた、データを収集し、異なるタイプのＭ２Ｍアプリケーション２０と適合性があるようにデータを変換し得る。Ｍ２Ｍサービスプラットフォーム２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

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

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０は、ＩｏＴ知的交渉サービスのための開示されたシステムおよび方法を使用し得るデバイスを含む、１つ以上のピアツーピアネットワークの作成のための基礎を形成する、所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービス等のこれらの機能をＭ２Ｍアプリケーション２０に提供する。説明されたサービス層およびオブジェクトが相互作用するアプリケーションは、Ｍ２Ｍアプリケーション２０のもの等のアプリケーションであり得る。

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

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

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

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

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

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書で記載される実施形態のうちのいくつかで説明されるもの等の種々の条件およびパラメータに応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。例えば、プロセッサ３２は、本明細書で説明される実施形態のうちのいくつかにおけるＩｏＴ交渉サービスが成功したか、または成功していないかどうかという決定に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。

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

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

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

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

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

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

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

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

さらに、コンピュータシステム９０は、図１８Ａおよび１８Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。実施形態では、ネットワークアダプタ９７は、ＩｏＴ知的交渉サービスのための開示されたシステムおよび方法に関連するデータを受信および伝送し得る。

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

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

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

Claims (1)

1. 明細書に記載された発明。

Images