JP2017531389A

JP2017531389A - サービス層を介する第三者サービスへのアクセスを可能にするシステムおよび方法

Info

Publication number: JP2017531389A
Application number: JP2017514864A
Authority: JP
Inventors: ウィリアムロバードザフォースフリン，; デールエヌ．シード，; シュウリ，; グアンルー，; リージュンドン，; ホンクンリ，; フィリップブラウン，; カタリーナエム．ムラディン，
Original assignee: コンヴィーダワイヤレス，エルエルシー
Priority date: 2014-09-17
Filing date: 2015-09-17
Publication date: 2017-10-19
Anticipated expiration: 2035-09-17
Also published as: US11240321B2; KR20170055530A; US20210211511A1; US20240171648A1; EP3195572B1; CN106797400B; EP3195572A1; US11616851B2; JP2019097185A; WO2016044581A1; JP6473500B2; US20220141295A1; US11882195B2; KR101984413B1; CN106797400A; US10931762B2; US20170310767A1; US20230199079A1

Abstract

Ｍ２Ｍサービス層が、第三者のサービスにアクセスし、データをこれらの第三者と交換するように拡張される。Ｍ２Ｍサービス層は、次いで、Ｍ２Ｍデバイスと第三者サービスとの間のプロキシとしての役割を果たすことが可能である。Ｍ２Ｍサービス層は、単一／一貫したインターフェース、すなわち、ＡＰＩをＭ２Ｍデバイスに提示可能であり、第三者サービスプロバイダの詳細をＭ２Ｍデバイスから隠す。一実施形態によると、サービス層は、ｏｎｅＭ２Ｍサービス層である。

Description

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

ウェブサービス（ＷＳ）は、ネットワークを経由して、コンピュータ間の相互動作可能な相互作用をサポートするように設計されたソフトウェアシステムを実装する方法である。ＷＳは、種々のプラットフォームおよびフレームワーク上で起動するソフトウェアアプリケーション間の相互動作の標準的手段を提供する。より厳密には、ＷＳは、リモートプロシージャコール（ＲＰＣ）の具体的実装技術であり、ＲＰＣは、あるプログラムがネットワーク内の異なるコンピュータに位置する別のプログラムからのサービスを要求し得る、ソフトウェア動作パラダイムである。ＷＳは、それらの優れた相互運用性および拡張性ならびに拡張マークアップ言語（ＸＭＬ）の使用によるそれらの機械読み取り可能な記述によって特徴付けられる。ＷＳは、疎結合方法で組み合わせられることにより、単純サービスを提供するプログラムが互いに相互作用し、高度な付加価値サービスを送達し得るように、複合動作を達成することができる。

プロトコルスタックの視点から、サービス層は、典型的には、既存のネットワークプロトコルスタックの上に層化され、付加価値サービスをクライアントアプリケーションに提供する。故に、サービス層は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図１は、ＩＰネットワーキングスタック１０４とアプリケーション１０６との間に層化された例示的サービス層１０２を図示する略図である。

図２は、ネットワーク内のサービス層インスタンスの例示的展開シナリオを図示する略図である。この例では、サービス層インスタンスは、種々のネットワークノード（ゲートウェイおよびサーバ）上に展開されて示され、付加価値サービスをネットワークアプリケーション、デバイスアプリケーション、ならびにネットワークノード自体に提供する。

マシンツーマシン（Ｍ２Ｍ）／モノのインターネット（ＩＯＴ）サービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを具体的に標的とする１つのタイプのサービス層の例である。最近、いくつかの産業標準化団体（例えば、ＥＴＳＩＭ２Ｍ、ｏｎｅＭ２Ｍ）が、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開の中へのＭ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍ／ＩｏＴサービス層を開発している。

Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ中央能力の集合体へのアプリケーションおよびデバイスアクセスを提供することができる。そのような能力のいくつかの例として、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。

サービス層の別の例は、モバイルネットワークデバイスのためのマルチメディアサービスを提供することを特に標的とするＩＰマルチメディアサブシステム（ＩＭＳ）サービス層である。

ｏｎｅＭ２Ｍの目的および目標は、種々のハードウェアおよびソフトウェア内に容易に埋め込まれ、かつ分野内の様々なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために信頼されることができる共通Ｍ２Ｍサービス層の必要性に対処する技術的仕様を開発することである。

図３は、ｏｎｅＭ２Ｍサービス層３００の全体的アーキテクチャを図示する略図である。ｏｎｅＭ２Ｍ共通サービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）３０２および３０４と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション特定のノード）上にホストされることができる。

ｏｎｅＭ２ＭＲＥＳＴｆｕｌアーキテクチャに従って、ＣＳＦは、「リソース」の組として表される。リソースは、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有する、アーキテクチャ内の固有にアドレス可能なエンティティである。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用して、アドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースとの包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースについての情報を記憶する、「属性」の組をサポートする。

図４は、Ｍ２ＭアプリケーションおよびＭ２Ｍサービスプロバイダに提供されるＭ２Ｍサービスを規定することによってｏｎｅＭ２Ｍ機能アーキテクチャを拡張する、Ｍ２Ｍサービスアーキテクチャ４００を図示する略図である。サービスエクスポージャコンポーネント４０２は、サービスをアプリケーションエンティティ（ＡＥ）４０４にエクスポーズする。ネットワークサービス利用コンポーネント４０６は、ネットワークサービスエンティティ（ＮＳＥ）４０８からのサービスを消費する。遠隔サービスエクスポージャコンポーネント４１０は、異なるＭ２Ｍ環境からのサービスを接続する。

Ｍ２Ｍサービス層は、第三者のサービスにアクセスし、データをこれらの第三者と交換するように拡張される。Ｍ２Ｍサービス層は、次いで、Ｍ２Ｍデバイスと第三者サービスとの間のプロキシとしての役割を果たすことが可能である。Ｍ２Ｍサービス層は、単一／一貫したインターフェース、すなわち、ＡＰＩをＭ２Ｍデバイスに提示可能であり、第三者サービスプロバイダの詳細をＭ２Ｍデバイスから隠す。

デバイスが、より多くのサービスにアクセスし、データをより多くのプラットフォームと交換することを可能にすることによって、アプリケーションおよびデバイスデベロッパは、モノのインターネットを用いて構築され得るものの観点から、より多くの可能性が提示される。言い換えると、より多くの情報交換が、可能性であり、デバイスが、より多くのサービスにアクセス可能となり、より広範囲のサービスが、作成されることができる。

説明される方法はまた、マシンツーマシン通信またはモノのインターネットに特有ではないサービス層にも適用されることができる。

Ｍ２Ｍサービス層が第三者サービスプロバイダからの付加価値サービスを統合する方法は、Ｍ２Ｍサービス層クライアントが第三者サービスとの通信方法を把握する必要がないように、プロキシ機構を通して使用される。

第三者サービスＡＰＩは、Ｍ２Ｍサービス層に規定、定義、または提供される。

サービス層クライアントは、Ｍ２Ｍサービス層を通して利用可能な第三者サービスを発見することができる。サービス層クライアントがこれらのサービスがホストＭ２Ｍサービス層の外部にあることを認知することは、必要ではない。

サービス層クライアントは、第三者サービスへのアクセスを要求すること、それへのアクセスのために登録すること、またはそれへのアクセスのためにプロビジョニングされることができる。

第三者サービスは、Ｍ２Ｍサービス層のネイティブプロトコルと一貫した様式でサービス層にアクセスすることができる。

Ｍ２Ｍベースのインターフェースは、第三者ＡＰＩに変換され、要求を第三者サービスにプロキシし、第三者サービスからの応答を受信し、ネイティブ応答を要求の発信側に送信することができる。

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

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。
図１は、ＩＰネットワーキングスタックとアプリケーションとの間に層化される例示的サービス層を図示する略図である。図２は、ネットワーク内のサービス層インスタンスの例示的展開シナリオを図示する略図である。図３は、ｏｎｅＭ２Ｍサービス層の全体的アーキテクチャを図示する略図である。図４は、Ｍ２ＭアプリケーションおよびＭ２Ｍサービスプロバイダに提供されるＭ２Ｍサービスを規定することによってｏｎｅＭ２Ｍ機能アーキテクチャを拡張する、Ｍ２Ｍサービスアーキテクチャを図示する略図である。図５は、第三者サービスを要求するための帯域外通信の使用を図示する略図である。図６は、Ｍ２Ｍサービス層が、第三者のサービスにアクセスし、データを第三者と交換することを可能にするシステムを図示する略図である。図７は、サービス層クライアントが第三者サービスにアクセスすることを可能にするためのステップを要約する略図である。図８は、ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲｏＡ）実施形態を示すフロー図である。図８は、ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲｏＡ）実施形態を示すフロー図である。図８は、ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲｏＡ）実施形態を示すフロー図である。図９は、サービスアクセスイネーブルメント（ＳＡＥ）コンポーネントを図示する略図である。図１０は、＜ｓｅｒｖｉｃｅｏｂｊｅｃｔ＞リソースを図示する略図である。図１１は、＜ｓｅｒｖｉｃｅｉｎｓｔａｎｃｅ＞オブジェクトを図示する略図である。図１２は、ｏｎｅＭ２Ｍサービスアーキテクチャ内のサービスアクセスイネーブルメントコンポーネントならびに新しい参照点Ｍｃｓの定義を図示する略図である。図１３は、メッセージキューテレメトリトランスポート（ＭＱＴＴ）実施形態を図示するフロー図である。図１３は、メッセージキューテレメトリトランスポート（ＭＱＴＴ）実施形態を図示するフロー図である。図１３は、メッセージキューテレメトリトランスポート（ＭＱＴＴ）実施形態を図示するフロー図である。図１４は、一実施形態のグラフィカルユーザインターフェースの略図である。図１５Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムの略図である。図１５Ｂは、図１５Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。図１５Ｃは、図１５Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。図１５Ｄは、図１５Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

Ｍ２Ｍサービス層は、制約され得るデバイスまたはセンサをサポートするための要件と、データレート、データ消費限界、および算出複雑性に関する限界を有し得るアプリケーションとともに展開されている。それらの制約性質に起因して、これらのサービス層クライアントは、可能な限り多くの処理をデバイスまたはアプリケーションの外部で行う必要があるであろう。クライアントは、多くの場合、処理を行うためにサービス層に頼るであろう。Ｍ２Ｍサービス層は、いくつかの付加価値処理サービスをネイティブにサポートし得る。しかしながら、一般に、Ｍ２Ｍサービス層は、展開されるデバイス、センサ、およびアプリケーションによって必要とされ得る、または所望され得る全ての可能なアプリケーション特定のサービスまたは機能性をサポート可能である可能性は低い。Ｍ２Ｍサービス層が所望のサービスまたは機能性をネイティブにサポートしない場合、サービス層クライアントは、それらの特徴をそれら自身で実装するか、またはそれらのサービスを第三者サービスから要求する必要がある。

Ｍ２Ｍ規格では、Ｍ２Ｍサービス層を介した第三者サービスへのアクセスの要求に対するサポートはない。故に、Ｍ２Ｍサービス層に関連付けられたデバイス、センサ、およびアプリケーションは、代わりに、図５に描写されるように、帯域外通信プロシージャを使用して、このサービスを要求しなければならない。図５は、第三者サービスを要求するための帯域外通信の使用を示す略図である。

例示的展開が、図５に示されており、「センサ」５０２および「アプリケーション」５０４は、Ｍ２Ｍサービス層５０６を介して互いに接続され、Ｍ２Ｍサービス層定義プロトコルを使用して通信する。例は、セキュリティシステムであろう。

小型セキュリティカメラ（図５におけるセンサ５０２）が、写真を撮影し、画像をサービス層５０６に送信し、そこで、それらは記憶される。未加工画像に加え、セキュリティシステムはまた、以下の特徴を提供する。
１．運動検出アルゴリズムを画像に適用し、結果をサービス層に記憶する。
２．運動が検出される場合、ＳＭＳアラートをユーザのモバイルデバイスに発生させる。
３．画像の圧縮バージョンを提供し、帯域幅要件を低減させる。
４．顔認識を提供し、画像内の人物を識別する。

既存のＭ２Ｍサービス層５０６を使用してこのセキュリティシステムを実装するために、以下のオプションのいずれかが、システム分析およびトレードオフに基づいて実装されることができる。
１．所望の特徴の各々がデバイス上に実装されるように、センサ５０２を構築する。
２．センサ５０２が第三者サービス５０８を介してこれらの特徴を要求し得るように、センサ５０２を構築する。
３．所望の特徴のうちのいくつかをエンドユーザアプリケーション上で行う。
４．エンドユーザアプリケーションが第三者サービスを介してこれらの特徴を要求し得るように、エンドユーザアプリケーションを構築する。

このアプローチのいくつかの問題が存在する（図５に番号が付与されたアイテムは、以下のリストに対応する）。
１）Ｍ２Ｍ／ＩｏＴデバイスまたはセンサ５０２は、非常に制約されたデバイスであることが意図または予期される。それらのデバイスまたはセンサが、第三者サービス５０８にアクセスするために、計算上複雑な動作を行うか、またはＭ２Ｍサービス層へのインターフェースの他に、別のインターフェースを実装する必要がある場合、それは、それらのデバイスまたはセンサのサイズ、複雑性、およびコストを増加させるであろう。
２）同様に制約され得るエンドユーザアプリケーション５０４は、１つ以上の第三者サービス５０８とインターフェースをとり、それからの応答を調整する必要があり得る。これは、それらのアプリケーションに複雑性を加える。
３）第三者サービス５０８は、デバイス、センサ、およびアプリケーションからのさらに多くの接続をサポートする必要があり、それは、第三者サービス５０８に関する複雑性およびスケーラビリティ問題につながり得る。加えて、所与の第三者サービス５０８は、複数のアプリケーションが同一データについてのサービスを要求する場合、同一データについてのサービスを複数回行い得る。同一データについての複数の要求は、例えば、複数のエンドユーザアプリケーションが同一画像の圧縮を要求する場合、要求の数が増えるので、要求が応答を得る前により長い待ち時間を有し得ることによって、低品質のサービスにつながり得る。
４）デバイス、センサ５０２、およびアプリケーション５０４は、外部サービスに対するより多くのＡＰＩをサポートすることを要求され、これらの追加のＡＰＩは、デバイスが周期的ソフトウェア更新を要求するであろう可能性を増加させる。例えば、第三者サービスプロバイダがそのＡＰＩに変更を行う場合、これは、展開されるデバイス、センサ、およびアプリケーションの全てに更新を要求し得る。

図６は、Ｍ２Ｍサービス層６０４が、第三者のサービスにアクセスし、データを第三者６０６と交換することを可能にする、システムの使用を図示する略図である。そして、Ｍ２Ｍサービス層６０４は、センサ６０２およびアプリケーション６０８等のＭ２Ｍデバイスと第三者サービスとの間のプロキシとして作用可能である。Ｍ２Ｍサービス層は、単一／一貫したインターフェース、すなわち、ＡＰＩをＭ２Ｍデバイスに提示し、第三者サービス６０６の詳細をＭ２Ｍデバイスから隠すことが可能である。

図６は、例示的セキュリティシステムがＭ２Ｍ展開においてこれらのプロシージャから利益を享受する方法を図示する。小型セキュリティカメラ６１２は、写真を撮影し、画像をサービス層６０４に送信し、そこで、それは記憶される。各画像がサービス層６０４に到着すると、それは、Ｍ２Ｍサービス層６０４によって第三者サービス６０６に送信され、そこで、運動検出が、この画像について行われ、結果も、サービス層６０４内に記憶される。結果が運動が存在することを示す場合、ＳＭＳアラートが、ユーザのモバイルデバイスに信号伝達される。ユーザアプリケーション６０８が画像を読み出すとき、（オリジナルの完全分解能画像ではなく）オリジナル画像の圧縮バージョンが、応答として送信される。ユーザアプリケーション６０８は、画像内の人物を識別するために使用される顔認識サービスの結果へのアクセスも有する。

本明細書に定義された方法を使用することによって、いくつかの利点が、本システムにおける種々の当事者にもたらされる。

デバイスおよびセンサ製造業者は、特定の感知機能専用のセンサ６０２を構築可能であり、第三者サービス６０６によって提供される追加の処理を行うための追加のハードウェアおよびソフトウェア能力を追加する必要はない。これは、低複雑性、より小さいサイズ、より短いスケジュール、およびコスト削減に直接つながる。

デバイスおよびセンサ製造業者は、既存のＭ２Ｍサービス層６０４プロトコルを使用して第三者サービス６０６にアクセス可能であり、他のウェブサービスプロトコルをサポートするために要求され得る追加のハードウェアおよび／またはソフトウェアを追加する必要はない。これは、低複雑性、より小さいサイズ、より短いスケジュール、およびコスト削減に直接つながる。

デバイスおよびセンサ製造業者は、あるタイプのデバイス管理機能性を使用するのではなく、Ｍ２Ｍサービス層６０４内の構成を変更することによって、第三者によって提供される特徴に対する更新を提供可能である。これは、低複雑性、より小さいサイズ、より短いスケジュール、およびコスト削減に直接つながる。

アプリケーション６０８は、Ｍ２Ｍサービス層６０４を介して利用可能な第三者サービス６０６を使用することによって、はるかに低複雑性で、より特徴が豊富な機能を提供することができる。これは、より優れた性能およびアプリケーションの保全性に直接つながるであろう。

アプリケーション６０８は、利用可能な特徴を使用するために、個々の第三者サービスプロトコルを認知する必要はない。これは、アプリケーションにおける低複雑性に直接つながるであろう。

第三者サービス６０６は、サービス層６０４がサービス層クライアントのための「プロキシ」であるので、より少ない接続を通して、そのサービスをより多数のクライアントに提供可能である。これは、低複雑性、改良された性能、およびより優れたスケーラビリティに直接つながる。

第三者サービスは、サービスのディレクトリからのＭ２Ｍサービス層の組み込み特徴としてアドバタイズされることができる。

デバイス、センサ、およびアプリケーションデベロッパは、サポートされるサービスを発見するため、サービスを選択するため、おそらく新しいサービスを要求するか、またはさらに新しいサービスの必要性を認識するために、サービス特徴のディレクトリを使用することができる。これは、全当事者にもたらされる改良された能力に直接つながる。

Ｍ２Ｍサービス層６０４は、それらを内部で開発する必要なく、より高度なサービスを提供可能である。これは、低複雑性に直接つながる。

本開示はまた、これらのプロシージャが、ｏｎｅＭ２Ｍサービス層内に実装され、サービス層クライアントが、通常のサービス層ＡＰＩコールを介して、第三者サービス６０６にアクセスすることを可能にし得る方法に関する実施形態も定義する。

３つの主要な方法が、定義される：
・Ｍ２Ｍサービス層６０４に第三者サービス６０６へのアクセス方法の詳細をプロビジョニングすること。
・Ｍ２Ｍサービス層クライアントがこれらの利用可能な第三者サービス６０６を発見することをイネーブルにすること。
・第三者サービス６０６への要求をトリガする、Ｍ２Ｍサービス層インターフェースを実装すること。

図７は、サービス層クライアント６０２が第三者サービス６０６にアクセスことを可能にするためのステップを要約する、略図であり、ステップ１は、Ｍ２Ｍサービス層によって把握されるべき第三者サービスＡＰＩおよびプロトコルのための方法である。この情報がサービス層に利用可能となると、ステップ２は、サービス層クライアント（またはそのデベロッパ）がこれらの第三者サービス６０６についての情報を発見する方法である。第三者サービスの使用を欲するサービス層クライアントは、ステップ３における既存のサービス層プロトコルと一貫した様式で使用パラメータを設定する必要がある。その時点で、サービス層クライアントが、ステップ４において、第三者サービス６０６へのＭ２Ｍサービス層インターフェースにアクセスすると、サービス層６０４は、ステップ５において、要求を第三者サービス６０６に変換またはプロキシし、それは、第三者サービス６０６からの出力応答を得るために必要な通信の全てのハンドリングを含み、ステップ６において、サービス層６０４は、オリジナル要求側またはＭ２Ｍサービス層またはサービス層クライアントによって定義される他の宛先にその応答を戻す。

サービスオブジェクトは、第三者サービス６０６のために、またはそれによって作成されることができる。サービスオブジェクトは、典型的には、サービス層内に位置し、例えば、ｏｎｅＭ２Ｍ実施形態では、サービスオブジェクトは、新しいリソースとして表される。それらは、第三者サービスがもたらすものの詳細および第三者サービスとインターフェースをとる方法を含むことができる。サービスオブジェクトを実際に表す方法は、実装依存性である。いくつかの例示的実装は、Ｊａｖａ（登録商標）もしくはＣ＋＋クラスもしくは構造、データベース記録、ｘｍｌドキュメント、またはサービス層リソースのようなプログラミング言語構造であることができる。

所与のサービス層内に実装される方法にかかわらず、サービスオブジェクトは、Ｍ２Ｍサービス層クライアントが、オブジェクトによって記述される第三者サービスを発見、構成、および使用することを可能にするために必要な情報の組、ならびにオブジェクトに基づいてまたはそれによって行われる方法またはプロシージャである。

サービスオブジェクトの記述は、３つのタイプの情報にグループ化されることができる（但し、必ずしも限定されない）。サービスオブジェクトは、最初に、ここで定義され、そして、サービスオブジェクトの定義は、本開示の方法が説明されることに応じて拡張される。

サービスオブジェクト情報は、第三者サービス情報、第三者サービス発見およびアクセス情報、ならびにサービスインターフェース情報を含むことができる。

第三者サービス情報は、サービス層６０４と第三者サービス６０６との間で通信するために必要とされる情報を含むことができる。これは、第三者サービスによって使用される記述言語（ＷＳＤＬ等）または他の標準的もしくは非標準的インターフェース方法を含むことができる。それは、カスタム通信プロトコルの仕様を含むこともできる。図７のステップ１および５は、これを示す。

第三者サービス発見およびアクセス情報は、Ｍ２Ｍサービス層がサービスをＭ２Ｍサービス層クライアントまたはエンティティにアドバタイズもしくはアナウンスするために使用する情報を含むことができる。これは、特徴の一般的高レベル記述、特徴のコスト、第三者サービスプロバイダの名称、サービスの使用方法に関する情報へのリンク等を含むことができる。加えて、これは、これらの第三者サービス６０６を使用するためのアクセスを要求する手段を含むことができる。図７のステップ１および２は、これを示す。

サービスインターフェース情報は、Ｍ２Ｍサービス層に特定であることができる。それは、第三者サービスコールのために必要とされるパラメータおよび入力の全てとともに、Ｍ２Ｍサービス層クライアントが、変換またはプロキシコールをトリガする要求またはコールを第三者サービス６０６に対して行うべき方法を記述する。図７のステップ３、４、および６は、これを示す。

このサービスオブジェクトは、直接使用のために、サービス層クライアントに直接利用可能にされ得る。代替として、サービスオブジェクトの一部のみが、利用可能にされ、「サービス層」対応インターフェースのみをエクスポーズすることができる。

以下の節は、サービスオブジェクト情報に基づいて行われるプロシージャを説明する。

第三者インターフェースのプロビジョニングの詳細。ウェブサービス６０６は、それらの利用可能なサービスにアクセスするために任意の数の異なるプロトコルを有することができる。本開示に説明される方法を通して、それらは、利用可能な場合、すでに使用しているウェブサービスプロトコルに対応する、それらのインターフェースの記述を記述言語で提供可能である。

サービス層６０４は、この情報を使用して、サービス層クライアント６０８の代わりに、第三者サービス６０６にアクセスすることができる。サービス層６０４は、第三者サービス６０６のプロトコルを使用して、第三者サービス６０６と通信し、それによって、第三者サービス６０６が、要求の発信側によって使用されるサービス層プロトコルを「認知しない」ままであることを可能にする。サービスオブジェクトのための追加の詳細は、この情報を記憶するように定義される。

サービスオブジェクト第三者サービス情報は、サービスＡＰＩを有することができる。第三者サービスＡＰＩは、Ｍ２Ｍサービス層が、メッセージを第三者サービスに送信し、規定されたサービスを要求するために必要とする情報である。これは、Ｍ２Ｍサービス層６０４と第三者サービス６０６との間で必要とされるコールフローを含む。さらに、含まれるのは、アドレス指定情報（ＦＱＤＮまたはＩＰアドレスおよびポート）、トランスポートプロトコル（ＵＤＰ、ＴＣＰ等）、およびメッセージフォーマット（ＸＭＬ、ｐｎｇ等）である。

第三者サービス情報を提供する方法は、種々の具体的実装を有することができる。例示的実装は、プロビジョニングステップであることができ、情報は、手動で、または非自動的方法で、サービスオブジェクトデータベースまたは記憶デバイス／プロシージャに入力される。別の例は、ＡＰＩの展開であることができ、サービス記述言語は、そのインターフェースを定義するために、第三者サービス６０６によって使用されることができる。この場合、ＡＰＩは、実施例１に示されるＷＳＤＬ等の任意の数のプロトコル記述をサポートすることができる。別の例は、Ｍ２Ｍサービス層が第三者サービス６０６の利用可能な記述の読み出しを開始する方法であることができる。

（実施例１−ＷＳＤＬドキュメント構造：）
＜ｄｅｆｉｎｉｔｉｏｎｓ＞
＜ｔｙｐｅｓ＞
ｄｅｆｉｎｉｔｉｏｎｏｆｔｙｐｅｓ．．．．．．．．
＜／ｔｙｐｅｓ＞

＜ｍｅｓｓａｇｅ＞
ｄｅｆｉｎｉｔｉｏｎｏｆａｍｅｓｓａｇｅ．．．．
＜／ｍｅｓｓａｇｅ＞

＜ｐｏｒｔＴｙｐｅ＞
＜ｏｐｅｒａｔｉｏｎ＞
ｄｅｆｉｎｉｔｉｏｎｏｆａｏｐｅｒａｔｉｏｎ．．．．．．．
＜／ｏｐｅｒａｔｉｏｎ＞
＜／ｐｏｒｔＴｙｐｅ＞

＜ｂｉｎｄｉｎｇ＞
ｄｅｆｉｎｉｔｉｏｎｏｆａｂｉｎｄｉｎｇ．．．．
＜／ｂｉｎｄｉｎｇ＞

＜ｓｅｒｖｉｃｅ＞
ｄｅｆｉｎｉｔｉｏｎｏｆａｓｅｒｖｉｃｅ．．．．
＜／ｓｅｒｖｉｃｅ＞

＜／ｄｅｆｉｎｉｔｉｏｎｓ＞

以下の実施例２は、解析され、ネイティブＭ２Ｍサービス層プロトコルにマップされることができるサンプルＷＳＤＬドキュメントを示す。

（実施例２−温度変換サービス記述：）
＜？ｘｍｌｖｅｒｓｉｏｎ＝"１．０" ｅｎｃｏｄｉｎｇ＝"ｕｔｆ−８"？＞
＜ｗｓｄｌ：ｄｅｆｉｎｉｔｉｏｎｓｘｍｌｎｓ：ｔｍ＝"ｈｔｔｐ：／／ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｗｓｄｌ／ｍｉｍｅ／ｔｅｘｔＭａｔｃｈｉｎｇ／" ｘｍｌｎｓ：ｓｏａｐｅｎｃ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｅｎｃｏｄｉｎｇ／" ｘｍｌｎｓ：ｍｉｍｅ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｗｓｄｌ／ｍｉｍｅ／" ｘｍｌｎｓ：ｔｎｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ＮＥＴ／" ｘｍｌｎｓ：ｓｏａｐ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｗｓｄｌ／ｓｏａｐ／" ｘｍｌｎｓ：ｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ" ｘｍｌｎｓ：ｓｏａｐ１２＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｗｓｄｌ／ｓｏａｐ１２／" ｘｍｌｎｓ：ｈｔｔｐ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｗｓｄｌ／ｈｔｔｐ／" ｘｍｌｎｓ：ｗｓｄｌ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｗｓｄｌ／" ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ＮＥＴ／"＞
＜ｗｓｄｌ：ｔｙｐｅｓ＞
＜ｓ：ｓｃｈｅｍａｅｌｅｍｅｎｔＦｏｒｍＤｅｆａｕｌｔ＝"ｑｕａｌｉｆｉｅｄ"
ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ＮＥＴ／"＞
＜ｓ：ｅｌｅｍｅｎｔｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐ"＞
＜ｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｓ：ｓｅｑｕｅｎｃｅ＞
＜ｓ：ｅｌｅｍｅｎｔｍｉｎＯｃｃｕｒｓ＝"１" ｍａｘＯｃｃｕｒｓ＝"１"
ｎａｍｅ＝"Ｔｅｍｐｅｒａｔｕｒｅ" ｔｙｐｅ＝"ｓ：ｄｏｕｂｌｅ"／＞
＜ｓ：ｅｌｅｍｅｎｔｍｉｎＯｃｃｕｒｓ＝"１" ｍａｘＯｃｃｕｒｓ＝"１"
ｎａｍｅ＝"ＦｒｏｍＵｎｉｔ" ｔｙｐｅ＝"ｔｎｓ：ＴｅｍｐｅｒａｔｕｒｅＵｎｉｔ"／＞
＜ｓ：ｅｌｅｍｅｎｔｍｉｎＯｃｃｕｒｓ＝"１" ｍａｘＯｃｃｕｒｓ＝"１"
ｎａｍｅ＝"ＴｏＵｎｉｔ" ｔｙｐｅ＝"ｔｎｓ：ＴｅｍｐｅｒａｔｕｒｅＵｎｉｔ"／＞
＜／ｓ：ｓｅｑｕｅｎｃｅ＞
＜／ｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｓ：ｅｌｅｍｅｎｔ＞
＜ｓ：ｓｉｍｐｌｅＴｙｐｅｎａｍｅ＝"ＴｅｍｐｅｒａｔｕｒｅＵｎｉｔ"＞
＜ｓ：ｒｅｓｔｒｉｃｔｉｏｎｂａｓｅ＝"ｓ：ｓｔｒｉｎｇ"＞
＜ｓ：ｅｎｕｍｅｒａｔｉｏｎｖａｌｕｅ＝"ｄｅｇｒｅｅＣｅｌｓｉｕｓ"／＞
＜ｓ：ｅｎｕｍｅｒａｔｉｏｎｖａｌｕｅ＝"ｄｅｇｒｅｅＦａｈｒｅｎｈｅｉｔ"／＞
＜ｓ：ｅｎｕｍｅｒａｔｉｏｎｖａｌｕｅ＝"ｄｅｇｒｅｅＲａｎｋｉｎｅ"／＞
＜ｓ：ｅｎｕｍｅｒａｔｉｏｎｖａｌｕｅ＝"ｄｅｇｒｅｅＲｅａｕｍｕｒ"／＞
＜ｓ：ｅｎｕｍｅｒａｔｉｏｎｖａｌｕｅ＝"ｋｅｌｖｉｎ"／＞
＜／ｓ：ｒｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓ：ｓｉｍｐｌｅＴｙｐｅ＞
＜ｓ：ｅｌｅｍｅｎｔｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐＲｅｓｐｏｎｓｅ"＞
＜ｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｓ：ｓｅｑｕｅｎｃｅ＞
＜ｓ：ｅｌｅｍｅｎｔｍｉｎＯｃｃｕｒｓ＝"１" ｍａｘＯｃｃｕｒｓ＝"１"
ｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐＲｅｓｕｌｔ" ｔｙｐｅ＝"ｓ：ｄｏｕｂｌｅ"／＞
＜／ｓ：ｓｅｑｕｅｎｃｅ＞
＜／ｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｓ：ｅｌｅｍｅｎｔ＞
＜ｓ：ｅｌｅｍｅｎｔｎａｍｅ＝"ｄｏｕｂｌｅ" ｔｙｐｅ＝"ｓ：ｄｏｕｂｌｅ"／＞
＜／ｓ：ｓｃｈｅｍａ＞
＜／ｗｓｄｌ：ｔｙｐｅｓ＞
＜ｗｓｄｌ：ｍｅｓｓａｇｅｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐＳｏａｐＩｎ"＞
＜ｗｓｄｌ：ｐａｒｔｎａｍｅ＝"ｐａｒａｍｅｔｅｒｓ" ｅｌｅｍｅｎｔ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐ"／＞
＜／ｗｓｄｌ：ｍｅｓｓａｇｅ＞
＜ｗｓｄｌ：ｍｅｓｓａｇｅｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐＳｏａｐＯｕｔ"＞
＜ｗｓｄｌ：ｐａｒｔｎａｍｅ＝"ｐａｒａｍｅｔｅｒｓ"
ｅｌｅｍｅｎｔ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐＲｅｓｐｏｎｓｅ"／＞
＜／ｗｓｄｌ：ｍｅｓｓａｇｅ＞
＜ｗｓｄｌ：ｐｏｒｔＴｙｐｅｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅＳｏａｐ"＞
＜ｗｓｄｌ：ｏｐｅｒａｔｉｏｎｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐ"＞
＜ｗｓｄｌ：ｉｎｐｕｔｍｅｓｓａｇｅ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐＳｏａｐＩｎ"／＞
＜ｗｓｄｌ：ｏｕｔｐｕｔｍｅｓｓａｇｅ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐＳｏａｐＯｕｔ"／＞
＜／ｗｓｄｌ：ｏｐｅｒａｔｉｏｎ＞
＜／ｗｓｄｌ：ｐｏｒｔＴｙｐｅ＞
＜ｗｓｄｌ：ｂｉｎｄｉｎｇｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅＳｏａｐ"
ｔｙｐｅ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅＳｏａｐ"＞
＜ｓｏａｐ：ｂｉｎｄｉｎｇ
ｔｒａｎｓｐｏｒｔ＝"ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｈｔｔｐ"／＞
＜ｗｓｄｌ：ｏｐｅｒａｔｉｏｎｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐ"＞
＜ｓｏａｐ：ｏｐｅｒａｔｉｏｎ
ｓｏａｐＡｃｔｉｏｎ＝"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ＮＥＴ／ＣｏｎｖｅｒｔＴｅｍｐ"
ｓｔｙｌｅ＝"ｄｏｃｕｍｅｎｔ"／＞
＜ｗｓｄｌ：ｉｎｐｕｔ＞
＜ｓｏａｐ：ｂｏｄｙｕｓｅ＝"ｌｉｔｅｒａｌ"／＞
＜／ｗｓｄｌ：ｉｎｐｕｔ＞
＜ｗｓｄｌ：ｏｕｔｐｕｔ＞
＜ｓｏａｐ：ｂｏｄｙｕｓｅ＝"ｌｉｔｅｒａｌ"／＞
＜／ｗｓｄｌ：ｏｕｔｐｕｔ＞
＜／ｗｓｄｌ：ｏｐｅｒａｔｉｏｎ＞
＜／ｗｓｄｌ：ｂｉｎｄｉｎｇ＞
＜ｗｓｄｌ：ｓｅｒｖｉｃｅｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅ"＞
＜ｗｓｄｌ：ｐｏｒｔｎａｍｅ＝"ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅＳｏａｐ"
ｂｉｎｄｉｎｇ＝"ｔｎｓ：ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅＳｏａｐ"＞
＜ｓｏａｐ：ａｄｄｒｅｓｓｌｏｃａｔｉｏｎ＝
"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅｘ．ｎｅｔ／ＣｏｎｖｅｒｔＴｅｍｐｅｒａｔｕｒｅ．ａｓｍｘ"／＞
＜／ｗｓｄｌ：ｐｏｒｔ＞
＜／ｗｓｄｌ：ｓｅｒｖｉｃｅ＞
＜／ｗｓｄｌ：ｄｅｆｉｎｉｔｉｏｎｓ＞

実施例２におけるＷＳＤＬドキュメントは、温度をある測定単位から別の単位に変換するサービスに対するＡＰＩを記述する。ＷＤＳＬドキュメントは、解析され、Ｍ２Ｍサービス層によって要求されるＡＰＩパラメータをＭ２Ｍサービス層にネイティブな対応するパラメータにマップするために必要とされる以下の不可欠な情報を抽出することができる。

このサービス記述ドキュメントによって定義されたＭ２Ｍサービス層６０４からのサンプル要求は、実施例３に示される。

（実施例３：温度変換要求）
＜ｓｏａｐ：Ｅｎｖｅｌｏｐｅｘｍｌｎｓ：ｓｏａｐ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００３／０５／ｓｏａｐ−ｅｎｖｅｌｏｐｅ"
ｘｍｌｎｓ：ｗｅｂ＝"ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅｒｖｉｃｅＸ．ＮＥＴ／"＞
＜ｓｏａｐ：Ｈｅａｄｅｒ／＞
＜ｓｏａｐ：Ｂｏｄｙ＞
＜ｗｅｂ：ＣｏｎｖｅｒｔＴｅｍｐ＞
＜ｗｅｂ：Ｔｅｍｐｅｒａｔｕｒｅ＞４０＜／ｗｅｂ：Ｔｅｍｐｅｒａｔｕｒｅ＞
＜ｗｅｂ：ＦｒｏｍＵｎｉｔ＞ｄｅｇｒｅｅＣｅｌｓｉｕｓ＜／ｗｅｂ：ＦｒｏｍＵｎｉｔ＞
＜ｗｅｂ：ＴｏＵｎｉｔ＞ｄｅｇｒｅｅＦａｈｒｅｎｈｅｉｔ＜／ｗｅｂ：ＴｏＵｎｉｔ＞
＜／ｗｅｂ：ＣｏｎｖｅｒｔＴｅｍｐ＞
＜／ｓｏａｐ：Ｂｏｄｙ＞
＜／ｓｏａｐ：Ｅｎｖｅｌｏｐｅ＞

Ｍ２Ｍサービスは、ＣｏｎｖｅｒｔＴｅｍｐデータタイプから、実施例３に示されるＷＳＤＬドキュメントからのこの要求における３つのパラメータを識別することができる。これらの入力からＭ２Ｍサービス層タイプへのマッピングタイプは、ドキュメントから導出されることができ、「ｗｅｂ：Ｔｅｍｐｅｒａｔｕｒｅ」パラメータは、「ｓ：ｄｏｕｂｌｅ」として定義され、「ｗｅｂ：ＦｒｏｍＵｎｉｔ」および「ｗｅｂ：ＴｏＵｎｉｔ」パラメータは、「ｔｎｓ：ＴｅｍｐｅｒａｔｕｒｅＵｎｉｔ」に定義された組からの値の選択肢として定義される。

第三者サービス６０６にアクセスする方法の記述を得ることに加え、サービス層６０４は、第三者サービス６０６にアクセスするために必要とされる証明書を規定する手段を得る。例えば、Ｍ２Ｍサービス層６０４は、全サービス層クライアント６０８がＭ２Ｍサービス層６０４の証明書を使用して第三者サービス６０６にアクセスすることを可能にする証明書をセキュア化可能であり得る。この場合、Ｍ２Ｍサービス層６０４は、Ｍ２Ｍサービス層クライアント６０８にパスされるか、または付加価値サービスとして提供され得るサービスの使用を請求するための合意を確立していることもある。別の例は、Ｍ２Ｍサービス層６０８クライアントが、このサービスを使用するためのそれ自身の証明書を有し、サービスの各使用に対してこの情報を提供することが必要である（例えば、特定の製造業者からの全デバイスが第三者サービスプロバイダによって製造業者に提供される具体的証明書を使用する）ようなものであり得る。この場合、請求は、データ使用または他の合意された取り決め以外、Ｍ２Ｍサービス層６０４の範囲外であることができる。

第三者サービスインターフェース定義がサービス層６０４によって記憶されると、これらのサービスをサービス層クライアントに知らせ、アクセス可能にする方法が、存在する。サービス層６０４は、これらのサービスをサービス層クライアント６０８に「アドバタイズ」し、要求を第三者サービス６０６にトリガするサービス層６０４定義インターフェースを「記述」することができる。

サービス層６０４は、サービス層クライアント６０８が、利用可能なサービスを理解し、それらのサービスの使用方法の詳細を要求するために読み取ることができる、サービスのディレクトリを提供する。サービスオブジェクトのための追加の詳細が、この情報を記憶するために定義される。

サービスオブジェクト第三者サービス発見およびアクセス情報は、提供されるサービスの記述であるサービス記述を有することができる。これのコンテンツおよびフォーマットは、種々の具体的実装を有することができる。例えば、それは、展開または機器／アプリケーション設定中、提供されるサービスを記述するためにデベロッパまたはエンドユーザによって確認されることが意図されたＨＴＭＬ記述であることができる。これは、特徴、コスト、使用要件等に関連する任意のタイプの情報を含むことができる。サービス記述情報はまた、キーまたはインデックスを定義する方法を含み、したがって、サービス層クライアントは、特定のタイプの検索を見つけるための検索を行うことができる。例えば、
ＧＥＴｓｅｒｖｉｃｅ？ｔｙｐｅ＝ｉｍａｇｅ＿ｃｏｍｐｒｅｓｓｉｏｎ
である。

上で提供される情報を使用して、サービス層クライアントデベロッパは、価値をそれら自身の能力に追加し得るサービスを検索し、ネイティブサービス層プロトコルを通してそのサービスを使用するための許可を要求することが可能である。

Ｍ２Ｍサービス層クライアント６０８が、第三者サービス６０６の使用を欲すると、Ｍ２Ｍサービス層６０４は、サービスＡＰＩ情報を使用して、第三者サービス６０６へのメッセージまたは複数のメッセージを適切に形成する。本開示に説明される方法を通して、サービス層６０４は、サービス層クライアント６０８がサービス層にネイティブなプロトコルを使用して第三者サービス６０６にアクセスすることを可能にする、インターフェースを定義する。

サービスオブジェクトのための追加の詳細が、この情報を記憶するために定義される。サービスオブジェクト第三者サービスインターフェース情報は、サービス層クライアントが第三者サービス６０６にアクセスするために使用するためのサービス層定義インターフェースを含むことができる。この情報は、入力パラメータ、出力パラメータ、アクセス証明書、および第三者サービス６０６によって必要とされる任意の他の情報を規定する方法を含む。この情報はまた、サービス層クライアントの代わりに、第三者サービスに要求を開始させ、またはそれを行わせるために、サービス層６０４をトリガする方法を規定する。サービス層６０４は、サービスＡＰＩ情報を評価または解析し、ＡＰＩパラメータの各々をネイティブサービス層インターフェースまたは特性にマップすることによって、このインターフェースを定義し、例えば、画像を入力パラメータとして要求する第三者サービスＡＰＩは、第三者サービスが読み出すことができる画像のＵＲＩにマップされ得る。Ｍ２Ｍサービス層アプリケーションデベロッパは、この情報を使用して、第三者サービス６０６にアクセスすることができる。

第三者サービス６０６とインターフェースをとる方法の詳細を使用して、サービス層６０４は、ネイティブサービス層オブジェクトまたはリソースを第三者サービスが規定した入力にマップし、第三者サービス６０６によってサポートされるウェブサービスプロトコルを使用して要求を送信する。サービス層６０４はまた、第三者サービス６０６からの結果または応答をハンドリングし、それを適切なネイティブサービス層応答に逆マップする。

図８は、ｏｎｅＭ２ＭＲｏＡ実施形態を示すフロー図である。この図は、本開示に説明される方法およびプロシージャがｏｎｅＭ２Ｍアーキテクチャ内に実装され得る１つの方法を示す。

ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２は、本実施形態に定義されたサービスオブジェクトをプロビジョニングするためのユーティリティであることができる。このアプリケーションは、ｏｎｅＭ２Ｍサービス層へのウェブサービスＡＰＩおよび記述の送信をサポートするｏｎｅＭ２Ｍアプリケーションである。この例では、ＰｕｎｙＰＮＧウェブサービス８０４の発見が、行われる。それは、ウェブ検索を介して見つけられるサービスであることができるか、または、それは、このサービスを使用するアプリケーションエンティティに特定のカスタム実装サービスであることができ、例えば、セキュリティカメラ製造業者は、そのカメラのみがアクセスするためのウェブサービスをホストすることができる。ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２は、Ｍｃａ参照点を介して、ＣＳＥと通信することができる。

この例では、ＰｕｎｙＰＮＧウェブサービス８０４は、ｐｎｇフォーマットされた画像における限定された無料圧縮とサブスクリプション料金に対する追加のサービスとを提供するアクティブウェブサービスである。ＰｕｎｙＰＮＧウェブサービス８０４は、アカウントを作成することによって入手するアクセスキーの使用を要求することができる。ＰｕｎｙＰＮＧウェブサービス８０４は、第三者サービスにネイティブのプロトコルを介して、ＣＳＥ８０６と通信することができる。これは、ｏｎｅＭ２Ｍアーキテクチャ内の新しい参照点であることができる。この新しい参照点Ｍｃｓは、図１２に示される。

ＣＳＥ８０６は、本開示および本実施形態に定義された方法をサポートするｏｎｅＭ２Ｍ共通サービスエンティティのインスタンスである。

アプリケーションエンティティ＃１８０８は、画像をｏｎｅＭ２ＭＣＳＥ８０６の中に設置するデバイスまたはアプリケーションである。この例では、それは、サービスオブジェクト発見および設定プロシージャを行う。このステップは、多くの場合、ハードウェアまたはデバイスを伴う設定アプリケーション等の別個のエンティティによって行われることができる。アプリケーションエンティティ＃１８０８は、写真を構成されたレートで撮影する遠隔セキュリティカメラであることができる。アプリケーションエンティティ＃１８０８は、Ｍｃａ参照点を介して、ＣＳＥ８０６と通信することができる。

アプリケーションエンティティ＃２８１０は、アプリケーションエンティティ＃１８０８によって提供される画像の圧縮バージョンを読み出すアプリケーションであることができる。アプリケーションエンティティ＃２８１０は、最新の画像をｏｎｅＭ２ＭＣＳＥ８０６から周期的に入手するウェブベースのアプリケーションであることができる。アプリケーションエンティティ＃２８１０は、Ｍｃａ参照点を介して、ＣＳＥ８０６と通信することができる。

図８では、本開示に説明される方法およびプロシージャは、Ｍ２Ｍサービス層アーキテクチャを使用するアクタに対して示される。主要メッセージの各々は、その特定のメッセージの詳細な記述に対応する上付き文字で注釈される。

図８のステップ１では、サービスオブジェクトプロビジョニングツール８０２が、サービスオブジェクトリソースおよびＰｕｎｙＰＮＧウェブサービス８０４のインスタンスを作成する。作成プリミティブは、サービスＡＰＩ情報ならびにサービス記述情報を含む。

この例では、サービス証明書は、サービス層にプロビジョニングされず、サービス層は、第三者サービス定義プロシージャを使用してそれら自身のＡＰＩ＿ＫＥＹを要求するようにサービス層クライアントに要求する。これは、サービス層と第三者サービスとの間の展開決定である。異なる展開オプションでは、ｏｎｅＭ２Ｍサービス層は、サービス層が全クライアントに対して単一キーを使用することを可能にする、第三者サービスとの取り決めを有し得ることに留意されたい。これは、以下に示される結果のうちのいくつかを若干変化させ得るが、プロセスは、変化しない。
Ｍｅｔｈｏｄ：ＣＲＥＡＴＥ／ｃｓｅｂａｓｅ／ｐｕｎｙＰｎｇＳｅｒｖｉｃｅＯｂｊｅｃｔ
Ｐａｙｌｏａｄ：
＜ｓｅｒｖｉｃｅＯｂｊｅｃｔｉｄ＝"ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ"＞
＜ｄｅｓｃｒｉｐｔｉｏｎ＞
＜ｂｏｄｙ＞
＜ｈ１＞ｐｕｎｙｐｎｇ＜／ｈ１＞
＜ｈ２＞
ＩｍａｇｅＣｏｍｐｒｅｓｓｏｒｆｏｒＤｅｓｉｇｎｅｒｓａｎｄＤｅｖｅｌｏｐｅｒｓ
＜／ｈ２＞
＜ｈ２＞Ｓｕｐｐｏｒｔｓ：ＪＰＧ，ＧＩＦａｎｄＰＮＧ．＜／ｈ２＞
＜ｈ２＞ＧｏｔｏＰｕｎｙＰＮＧ．ｃｏｍｔｏｒｅｑｕｅｓｔａｎＡＰＩＫｅｙ＜／ｈ２＞
＜／ｂｏｄｙ＞
＜／ｄｅｓｃｒｉｐｔｉｏｎ＞
＜ｓｅｒｖｉｃｅＡｐｉ＞
＜ｒｅｑｕｅｓｔ＞
ｈｔｔｐ：／／ｗｗｗ．ｐｕｎｙｐｎｇ．ｃｏｍ／ａｐｉ／ｏｐｔｉｍｉｚｅ？ｉｍｇ＝ｉｍａｇｅ．ｐｎｇ＆ｋｅｙ＝ＡＰＩ＿ＫＥＹ
＜／ｒｅｑｕｅｓｔ＞
＜ｒｅｓｐｏｎｓｅ＞
｛"ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ，"ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ"：ｖａｌｕｅ，"ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ"：ｕｒｌ，"ｇｒｏｕｐ＿ｉｄ"：ｎｕｌｌ，"ｓａｖｉｎｇｓ＿ｐｅｒｃｅｎｔ"：ｖａｌｕｅ，"ｓａｖｉｎｇｓ＿ｂｙｔｅｓ"：ｖａｌｕｅ｝
＜／ｒｅｓｐｏｎｓｅ＞
＜ｒｅｑｕｅｓｔ＞
"ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ"：ｕｒｌ
＜／ｒｅｑｕｅｓｔ＞
＜ｒｅｓｐｏｎｓｅ＞
｛ｃｏｎｔｅｎｔ｝
＜／ｒｅｓｐｏｎｓｅ＞
＜／ｓｅｒｖｉｃｅＡｐｉ＞
＜／ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞

ｏｎｅＭ２Ｍサービス層は、要求内に提供されるサービスＡＰＩを分析し、サービス層内の＜ｓｅｒｖｉｃｅＩｎｔｅｒｆａｃｅ＞リソースにマップする。マッピングプロセスは、サービス層において、ウェブサービス記述言語または手動構成を使用して行われることができる。例示的要求／応答対は、以下のサービス層情報を生成することができる。
Ｒｅｑｕｅｓｔ１ｕｒｌ：ｈｔｔｐ：／／ｗｗｗ．ｐｕｎｙｐｎｇ．ｃｏｍ／ａｐｉ／ｏｐｔｉｍｉｚｅ
Ｒｅｑｕｅｓｔ１ｐａｒａｍｅｔｅｒ：ｉｍｇ＝ｉｍａｇｅ．ｐｎｇ
Ｒｅｑｕｅｓｔ１ｐａｒａｍｅｔｅｒ：ｋｅｙ＝ＡＰＩ＿ＫＥＹ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ "：ｕｒｌ ← ＴｈｉｓｕｒｌｉｓｕｓｅｄｉｎＲｅｑｕｅｓｔ２
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｇｒｏｕｐ＿ｉｄ "：ｎｕｌｌ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｓａｖｉｎｇｓ＿ｐｅｒｃｅｎｔ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｓａｖｉｎｇｓ＿ｂｙｔｅｓ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ
Ｒｅｑｕｅｓｔ２ｕｒｌ： "ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ "：ｕｒｌ＜− Ｔｈｉｓｕｒｌｃａｍｅｆｒｏｍｒｅｓｐｏｎｓｅ１
Ｒｅｓｐｏｎｓｅ２： “ｃｏｎｔｅｎｔ”：ｖａｌｕｅ

この第三者サービスＡＰＩでは、サービス層インターフェースにマップされる２つの入力パラメータおよび６つの出力パラメータを生成する、２つの要求／応答対が存在する。追加の入力パラメータは、サービス層によって、動作がサービスをトリガすることができる構成を可能にするために規定される。

この時点において、サービス層は、サービス層クライアントによる使用の準備ができたこの第三者サービスのためのサービスオブジェクトインスタンスを有する。

図８のステップ２では、サービス層クライアントは、パブリッシュされたサービスを発見する。アプリケーションデベロッパは、サービス層発見プロシージャを使用して画像圧縮を行うサービスを発見する。発見要求の結果は、所望の特徴を行うサービスのＵＲＩを含む一方、第２の要求は、サービスの記述を入手する。それは、以下のようにＨＴＭＬビューア内に表示されることができる。
ＰｕｎｙＰＮＧ
ＩｍａｇｅＣｏｍｐｒｅｓｓｏｒｆｏｒＤｅｓｉｇｎｅｒｓａｎｄＤｅｖｅｌｏｐｅｒｓ
Ｓｕｐｐｏｒｔｓ：ＪＰＧ，ＧＩＦａｎｄＰＮＧ．
Ｍａｘ１５０ＫＢｅａｃｈ，ｕｐｔｏ１５ｆｉｌｅｓ
ＧｏｔｏＰｕｎｙＰＮＧ．ｃｏｍｔｏｒｅｑｕｅｓｔａｎＡＰＩＫｅｙ

図８のステップ３では、サービス層クライアントは、パブリッシュされたサービスへのアクセスを要求する。サービス層クライアントがその必要性を満たすサービスを見つけると、クライアントは、パブリッシュされたサービスへのアクセスを要求する。本例示的実施形態では、ｏｎｅＭ２Ｍサービス層は、定義されたような適切なインターフェースを実装する場合、全クライアントがアクセスを有するように、このリソースへのＲＥＡＤアクセスを可能にする。サービス層クライアントは、第三者サービスがアクセスされることができる方法を規定するインターフェース記述を読み出す。
＜ｓｅｒｖｉｃｅＩｎｔｅｒｆａｃｅ＞
＜ｉｎｐｕｔｓ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｉｍｇ＜／ｉｎｐｕｔ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｎａｍｅ＿ｖａｌｕｅ”＞ｋｅｙ＜／ｉｎｐｕｔ＞
＜ｔｒｉｇｇｅｒＯｐｅｒａｔｉｏｎ＝"ｏｐｅｒａｔｉｏｎ"／＞
＜／ｉｎｐｕｔｓ＞
＜ｏｕｔｐｕｔｓ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｃｏｍｐｒｅｓｓｅｄ＿ｉｍｇ＜／ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｏｒｉｇｉｎａｌ＿ｓｉｚｅ＜／ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ＜／ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｓａｖｉｎｇｓ＿ｐｅｒｃｅｎｔ＜／ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｓａｖｉｎｇｓ＿ｂｙｔｅｓ＜／ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔＴｙｐｅ＝”ｃｏｎｔａｉｎｅｒ”＞ｏｒｉｇｉｎａｌ＿ｓｉｚｅ＜／ｏｕｔｐｕｔ＞
＜／ｏｕｔｐｕｔｓ＞
＜ｄｅｓｃｒｉｐｔｉｏｎ＞
Ｔｈｅｒｅａｒｅ３ｉｎｐｕｔｓ：ｉｎｓｔａｎｃｅ，ｖａｌｕｅ，ａｎｄｔｒｉｇｇｅｒ．
ＩｍｇｍｕｓｔｃｏｎｔａｉｎｔｈｅＵＲＩｔｏａｃｏｎｔａｉｎｅｒｒｅｓｏｕｒｃｅ．
ＶａｌｕｅｉｓｔｈｅＫＥＹｔｏｕｓｅｔｈｉｓｓｅｒｖｉｃｅ．
Ｔｒｉｇｇｅｒｉｓｔｈｅａｃｔｉｏｎｏｎｔｈｅｆｉｒｓｔｉｎｐｕｔｔｈａｔｗｉｌｌｉｎｉｔｉａｔｅｔｈｅｓｅｒｖｉｃｅ．
Ｔｈｅｒｅａｒｅ６ｏｕｔｐｕｔｓ：ｃｏｍｐｒｅｓｓｅｄ＿ｉｍｇｉｓＭａｎｄａｔｏｒｙ，ｔｈｅｏｔｈｅｒｓａｒｅＯｐｔｉｏｎａｌ．ＥａｃｈｏｕｔｐｕｔｍｕｓｔｃｏｎｔａｉｎｔｈｅＵＲＩｔｏａｃｏｎｔａｉｎｅｒｒｅｓｏｕｒｃｅｗｈｅｒｅａｃｏｎｔｅｎｔｒｅｓｏｕｒｃｅｗｉｌｌｂｅｃｒｅａｔｅｄｗｉｔｈｔｈｅｉｎｄｉｃａｔｅｄｃｏｎｔｅｎｔ．
＜／ｄｅｓｃｒｉｐｔｉｏｎ＞
＜／ｓｅｒｖｉｃｅＩｎｔｅｒｆａｃｅ＞

図８のステップ４では、サービス層クライアントは、第三者サービスに対する使用を設定する。インターフェース記述からの情報を使用して、アプリケーションエンティティは、ｏｎｅＭ２Ｍサービス層によって定義されたインターフェースを実装するために必要とされるパラメータを用いて、＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞リソースを作成する。この例では、サービス層クライアントは、第三者サービスによって圧縮されることが可能な画像の場所（コンテナ）を規定する必要がある。さらに、必要とされるのは、サービス層クライアントのＡＰＩ＿ＫＥＹと第三者サービスの結果、この場合、圧縮画像のための場所とである。
＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅｉｄ＝"ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ"＞
＜ｓｅｒｖｉｃｅＯｂｊｅｃｔＵｒｉ＞／ｃｓｅｂａｓｅ／ｐｕｎｙＰｎｇＳｅｒｖｉｃｅＯｂｊｅｃｔ＜／ｓｅｒｖｉｃｅＯｂｊｅｃｔＵｒｉ＞
＜ｉｎｐｕｔｓ＞
＜ｉｎｐｕｔｐａｒａｍ＝"ｃｏｎｔａｉｎｅｒ"＞／ｃｓｅｂａｓｅ／ｍｙＰｉｃｔｕｒｅｓ＜ｉｎｐｕｔ＞
＜ｉｎｐｕｔｐａｒａｍ＝"ｋｅｙ"＞ＡＫＵ１ＦＹＹ１ＧＢＤＫＪＲＢ＜ｉｎｐｕｔ＞
＜ｉｎｐｕｔｐａｒａｍ＝"ｔｒｉｇｇｅｒ"＞ＣＲＥＡＴＥＤ＜ｉｎｐｕｔ＞

＜／ｉｎｐｕｔｓ＞
＜ｏｕｔｐｕｔｓ＞
＜ｏｕｔｐｕｔｐａｒａｍ＝"ｃｏｍｐｒｅｓｓｅｄ＿ｉｍｇ"＞／ｃｓｅｂａｓｅ／ｍｙＰｉｃｔｕｒｅｓＰｕｎｙ＜ｏｕｔｐｕｔ＞
＜ｏｕｔｐｕｔｐａｒａｍ＝"ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ"＞／ｃｓｅｂａｓｅ／ｍｙＰｉｃｔｕｒｅｓＰｕｎｙ＜ｏｕｔｐｕｔ＞
＜／ｏｕｔｐｕｔｓ＞
＜／ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞

図８のステップ５では、サービス層クライアントは、第三者サービスの使用をトリガする。アプリケーションエンティティ＃１は、我々の実施例では、画像を／ｃｅｓｂａｓｅ／ｍｙＰｉｃｔｕｒｅｓに「作成」する。画像の標的ＵＲＩは、標的ＵＲＩ上の「動作」とともに、第三者サービスにアクセスするためのサービス層プロシージャを開始するためのトリガである。この例では、リソースが／ｃｅｓｂａｓｅ／ｍｙＰｉｃｔｕｒｅｓ内で失敗なく「作成される」と、サービス層は、プロセスを開始することができる。

図８のステップ６では、サービス層は、ユーザデータを第三者サービスにプロキシする。サービス層クライアントによって作成された＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞リソースは、オリジナル＜ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞リソースを指し示す。＜ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞の「作成」（ステップ１）において提供されるサービスＡＰＩは、ウェブサービス要求のコンテンツおよびフォーマットを規定する。サービス層は、＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞リソース内に提供されるデータを使用して、規定された一連の要求および応答を行う。この時点において、サービス層は、ウェブサービスがサービス層および／またはサービスにアクセスするサービスクライアントを識別するために使用し得る課金識別子をウェブサービスに提供することができる。

サービス層は、結果をサービス層クライアントの＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞によって規定された場所の中に入れる。随意に、サービス層は、通知または応答メッセージをサービス層クライアントに送信し、結果の準備ができたことを知らせることができる（このオプションは、前述の図に示されない）。

図８のステップ７では、サービス層クライアントは、第三者サービスの結果へのアクセスを有する。サービス層が結果を規定された出力ＵＲＩの中に入れると、他のクライアントは、結果へのアクセスを有することができる。この例では、ＡＥ＃２は、オリジナル画像の代わりに、圧縮画像を読み出すことができる。

図８に図示されるステップを行うエンティティは、図１５Ｃまたは１５Ｄ（我々の２つの環境図）に図示されるもののうちの１つ等、デバイス、サーバ、または他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図８に図示される方法は、例えば、図１５Ｃまたは１５Ｄに図示されるデバイスまたはコンピュータシステム等、コンピューティングデバイスのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図８に図示されるステップを行う。

ｏｎｅＭ２Ｍサービス層における本実施形態は、２つの新しいリソース定義：＜ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞および＜ｓｅｒｖｉｃｅＩｎｓｔａｎｃｅ＞を定義する。

本書に提案される機能は、既存のｏｎｅＭ２Ｍ機能アーキテクチャへの追加として、新しく定義されたＣＳＦ実施形態に実装されることができる。図９は、ＣＳＥ９０４内の新しいＣＳＦであるサービスアクセスイネーブルメント（ＳＡＥ）９０２を図示する略図である。

図１０は、＜ｓｅｒｖｉｃｅｏｂｊｅｃｔ＞リソース１００２を図示する略図である。＜ｓｅｒｖｉｃｅｏｂｊｅｃｔ＞リソース１００２は、第三者サービスへのインターフェース定義をｏｎｅＭ２Ｍサービス層に記憶するためのコンテナを表す。それはサービス層クライアントへのサービスの記述と、第三者サービスを設定し、それにアクセスするためのインターフェースとを提供するためにも使用される。

図１１は、＜ｓｅｒｖｉｃｅｉｎｓｔａｎｃｅ＞オブジェクト１１０２を示す略図である。＜ｓｅｒｖｉｃｅｉｎｓｔａｎｃｅ＞リソース１１０２は、サービスインターフェース情報を記憶するためのコンテナを表す。このリソースは、＜ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞リソース１１０２内に定義された第三者サービスの使用を欲するサービス層クライアントによって作成される。＜ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞にリンクする属性１１０４と、サービス層によって「マップ」された入力および出力の各々に対する属性とが、存在する。サービス層は、これらの入力を第三者サービス要求へのパラメータとして使用することができる。サービス層は、第三者サービスの結果を記憶する場所のために、このリソース内に規定された出力を使用することもできる。

ｏｎｅＭ２ＭＲｏＡ実施形態のための前述の概念およびプロシージャは、ｏｎｅＭ２Ｍサービス指向アーキテクチャ（ＳｏＡ）にも実装され得る。

図１２は、ｏｎｅＭ２Ｍサービスアーキテクチャ１２００内のサービスアクセスイネーブルメントコンポーネント１２０２ならびに新しい参照点Ｍｃｓの定義を図示する略図である。リソースは、図９におけるものに類似する。

図１３は、メッセージキューテレメトリトランスポート（ＭＱＴＴ）実施形態のフロー図である。ＭＱＴＴは、ＴＣＰＩＰプロトコル上での使用のためのパブリッシュ−サブスクライブベースの「軽量」メッセージングプロトコルである。パブリッシュ−サブスクライブメッセージングパターンは、メッセージのトピックに基づいてメッセージを関与クライアントに配信することに責任があるＭＱＴＴブローカを使用する。本実施形態は、本開示に説明される方法およびプロシージャがＭＱＴＴアーキテクチャを使用して実装され得る１つの方法を示す。実施形態は、以下の例示的シナリオを用いて例証される。

ＭＱＴＴブローカ１３０２は、本開示および本実施形態に定義された方法をサポートする、ｏｎｅＭ２Ｍ共通サービスエンティティのインスタンスである。

基本ＭＱＴＴプロトコルは、メッセージ送達をサポートする。基本プロトコルのＭＱＴＴブローカ拡張機能は、ＨｉｖｅＭＱ等のカスタム修正をサポート可能な実装を要求する。サービスオブジェクト拡張機能１３０６は、ウェブサービスＡＰＩおよび記述の受信をサポートするブローカ拡張機能である。サービスオブジェクト拡張機能１３０６は、定義されたトピックパターンを伴うパブリッシュされたメッセージを受信し、サービスに関連するサービス層機能を行うことができる。

トピックディレクトリ拡張機能１３１０は、サービスオブジェクトトピックの発見をサポートするブローカ拡張機能である。それは、基本ＭＱＴＴプロトコルの特徴ではないので、他のトピックの発見も同様にサポートするように一般化されることができる。

ＰｕｎｙＰＮＧウェブサービス１３１２は、ｐｎｇフォーマットされた画像における限定された無料圧縮およびサブスクリプション料金に対する追加のサービスを提供するアクティブウェブサービスである。ＰｕｎｙＰＮＧウェブサービス１３１２は、アカウントを作成することによって入手するアクセスキーの使用を要求することができる。ＰｕｎｙＰＮＧウェブサービス１３１２は、第三者サービスにネイティブのプロトコルを介して、ＭＱＴＴブローカサービスオブジェクト拡張機能と通信する。

サービスオブジェクトプロビジョニングツール１３１４は、ＭＱＴＴブローカへのウェブサービスＡＰＩおよび記述の送信をサポートするアプリケーションである。サービスオブジェクトプロビジョニングツール１３１４は、本実施形態に定義されたサービスオブジェクトをプロビジョニングするためのユーティリティであることができる。本実施形態では、ＰｕｎｙＰＮＧウェブサービスの発見は、本開示の範囲外で生じる。それは、ウェブ検索を介して見つけられるサービスであることができるか、またはこのサービスを使用するアプリケーションエンティティに特定のカスタム実装サービスであることができる。例えば、セキュリティカメラ製造業者は、そのカメラのみがアクセスするためのウェブサービスをホストすることができる。

ＭＱＴＴクライアントセンサ１３１６は、画像をＭＱＴＴブローカの中に設置するデバイスまたはアプリケーションである。この例では、それは、サービスオブジェクト発見および設定プロシージャを行う。このステップは、多くの場合、ハードウェアまたはデバイスを伴う設定アプリケーション等の別個のエンティティによって行われることができる。ＭＱＴＴクライアントセンサ１３１６は、写真を構成されたレートで撮影する遠隔セキュリティカメラであることができる。

ＭＱＴＴクライアントアプリ１３１８は、ＭＱＴＴクライアントセンサによって提供される画像の圧縮バージョンにサブスクライブするアプリケーションであることができる。

図１３では、本開示に説明される方法およびプロシージャは、ＭＱＴＴブローカ１３０２を使用するアクタに対して示される。

図１３のステップ１は、第三者サービスプロビジョニング／パブリッシュ／構成ステップである。サービスオブジェクトプロビジョニングツール１３１４は、ＰｕｎｙＰＮＧウェブサービス１３１２のためのサービスオブジェクトのインスタンスを作成する。ＰＵＢトピックは、ＭＱＴＴブローカ拡張機能１３０６によって使用され、これをサービスオブジェクトとして識別する。メッセージペイロードは、サービスＡＰＩ情報ならびにサービス記述情報を含む。この例では、サービス証明書は、サービス層にプロビジョニングされず、第三者サービス定義プロシージャを使用してそれ自身のＡＰＩ＿ＫＥＹを要求するようにサービス層クライアントに要求する。これは、サービス層と第三者サービスとの間の展開決定である。

本実施形態では、トピックに対する規則は、ｓｅｒｖｉｃｅｏｂｊｅｃｔ．＜ｔｈｉｒｄ＿ｐａｒｔｙ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＞．＜ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ＞である。この規則は、異なり得る。
Ｍｅｔｈｏｄ：ＰＵＢｓｅｒｖｉｃｅｏｂｊｅｃｔ．ｐｕｎｙＰｎｇＳｅｒｖｉｃｅＯｂｊｅｃｔ．ｉｍｇ＿ｃｏｍｐｒｅｓｓｉｏｎ
Ｐａｙｌｏａｄ：
＜ｓｅｒｖｉｃｅＯｂｊｅｃｔｉｄ＝"ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ"＞
＜ｄｅｓｃｒｉｐｔｉｏｎ＞
＜ｂｏｄｙ＞
＜ｈ１＞ｐｕｎｙｐｎｇ＜／ｈ１＞
＜ｈ２＞
ＩｍａｇｅＣｏｍｐｒｅｓｓｏｒｆｏｒＤｅｓｉｇｎｅｒｓａｎｄＤｅｖｅｌｏｐｅｒｓ
＜／ｈ２＞
＜ｈ２＞Ｓｕｐｐｏｒｔｓ：ＪＰＧ，ＧＩＦａｎｄＰＮＧ．＜／ｈ２＞
＜ｈ２＞ＧｏｔｏＰｕｎｙＰＮＧ．ｃｏｍｔｏｒｅｑｕｅｓｔａｎＡＰＩＫｅｙ＜／ｈ２＞
＜／ｂｏｄｙ＞
＜／ｄｅｓｃｒｉｐｔｉｏｎ＞
＜ｓｅｒｖｉｃｅＡｐｉ＞
＜ｒｅｑｕｅｓｔ＞
ｈｔｔｐ：／／ｗｗｗ．ｐｕｎｙｐｎｇ．ｃｏｍ／ａｐｉ／ｏｐｔｉｍｉｚｅ？ｉｍｇ＝ｉｍａｇｅ．ｐｎｇ＆ｋｅｙ＝ＡＰＩ＿ＫＥＹ
＜／ｒｅｑｕｅｓｔ＞
＜ｒｅｓｐｏｎｓｅ＞
｛"ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ，"ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ"：ｖａｌｕｅ，"ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ"：ｕｒｌ，"ｇｒｏｕｐ＿ｉｄ"：ｎｕｌｌ，"ｓａｖｉｎｇｓ＿ｐｅｒｃｅｎｔ"：ｖａｌｕｅ，"ｓａｖｉｎｇｓ＿ｂｙｔｅｓ"：ｖａｌｕｅ｝
＜／ｒｅｓｐｏｎｓｅ＞
＜ｒｅｑｕｅｓｔ＞
"ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ"：ｕｒｌ
＜／ｒｅｑｕｅｓｔ＞
＜ｒｅｓｐｏｎｓｅ＞
｛ｃｏｎｔｅｎｔ｝
＜／ｒｅｓｐｏｎｓｅ＞
＜／ｓｅｒｖｉｃｅＡｐｉ＞
＜／ｓｅｒｖｉｃｅＯｂｊｅｃｔ＞

ＭＱＴＴサービスオブジェクト拡張機能１３１４は、規定されたトピック規則に一致するパブリッシュされたメッセージ、この場合、トピック名に「ｓｅｒｖｉｃｅｏｂｊｅｃｔ」を含む全メッセージをインターセプトする。

ＭＱＴＴサービスオブジェクト拡張機能１３１４は、要求内に提供されるサービスＡＰＩを分析し、セクションに説明されるようなペイロードフォーマットおよびトピック命名規則にマップする。

マッピングプロセスは、サービス層において、ウェブサービス記述言語または手動構成を使用して行われることができる。例示的要求／応答対は、以下のサービス層情報を生成することができる。
Ｒｅｑｕｅｓｔ１ｕｒｌ：ｈｔｔｐ：／／ｗｗｗ．ｐｕｎｙｐｎｇ．ｃｏｍ／ａｐｉ／ｏｐｔｉｍｉｚｅ
Ｒｅｑｕｅｓｔ１ｐａｒａｍｅｔｅｒ：ｉｍｇ＝ｉｍａｇｅ．ｐｎｇ
Ｒｅｑｕｅｓｔ１ｐａｒａｍｅｔｅｒ：ｋｅｙ＝ＡＰＩ＿ＫＥＹ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｐｔｉｍｉｚｅｄ＿ｓｉｚｅ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ "：ｕｒｌ＜− ＴｈｉｓｕｒｌｉｓｕｓｅｄｉｎＲｅｑｕｅｓｔ２
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｇｒｏｕｐ＿ｉｄ "：ｎｕｌｌ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｓａｖｉｎｇｓ＿ｐｅｒｃｅｎｔ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｓａｖｉｎｇｓ＿ｂｙｔｅｓ "：ｖａｌｕｅ
Ｒｅｓｐｏｎｓｅ１ｐａｒａｍｅｔｅｒ： "ｏｒｉｇｉｎａｌ＿ｓｉｚｅ"：ｖａｌｕｅ
Ｒｅｑｕｅｓｔ２ｕｒｌ： "ｏｐｔｉｍｉｚｅｄ＿ｕｒｌ "：ｕｒｌ＜− Ｔｈｉｓｕｒｌｃａｍｅｆｒｏｍｒｅｓｐｏｎｓｅ１
Ｒｅｓｐｏｎｓｅ２： “ｃｏｎｔｅｎｔ”：ｖａｌｕｅ

この第三者サービスＡＰＩでは、ＭＱＴＴトピック規則にマップされる２つの入力パラメータおよび６つの出力パラメータを生成する、２つの要求／応答対が存在する。

この時点において、ＭＱＴＴサービスオブジェクト拡張機能１３０６は、サービス層クライアントによる使用の準備ができたこの第三者サービスのためのサービスオブジェクトインスタンスを有する。

図１３のステップ２では、サービス層クライアントは、パブリッシュされたサービスを発見する。アプリケーションは、ＭＱＴＴトピック発見拡張機能１３０６を使用して画像圧縮を行うサービスを発見する。トピック発見拡張機能１３０６は、トピックトークン「発見」をＳＵＢメッセージの開始にプリペンドすることによってトリガされる。発見要求の結果は、所望の特徴に一致するサービスのトピックを含む。

アプリケーションは、随意に、返されるサービスの記述を要求する。例示的記述は、以下のようにＨＴＭＬビューア内に表示されることができる。
ＰｕｎｙＰＮＧ
ＩｍａｇｅＣｏｍｐｒｅｓｓｏｒｆｏｒＤｅｓｉｇｎｅｒｓａｎｄＤｅｖｅｌｏｐｅｒｓ
Ｓｕｐｐｏｒｔｓ：ＪＰＧ，ＧＩＦａｎｄＰＮＧ．
Ｍａｘ１５０ＫＢｅａｃｈ，ｕｐｔｏ１５ｆｉｌｅｓ
ＧｏｔｏＰｕｎｙＰＮＧ．ｃｏｍｔｏｒｅｑｕｅｓｔａｎＡＰＩＫｅｙ

図１３のステップ３では、サービス層クライアント１３１６は、パブリッシュされたサービスへのアクセスを要求する。ＭＱＴＴクライアント１３１６がその必要性を満たすサービスを見つけると、クライアントは、パブリッシュされたサービスへのアクセスを要求する。本例示的実施形態では、サービス層クライアント１３１６は、第三者サービスがアクセスされ得る方法を規定する、インターフェース記述を読み出す。
＜ｓｅｒｖｉｃｅＩｎｔｅｒｆａｃｅ＞
＜ｔｏｐｉｃｓ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｒｅｑｕｉｒｅｄ”＞ｓｅｒｖｉｃｅｏｂｊｅｃｔ＜／ｉｎｐｕｔ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｒｅｑｕｉｒｅｄ”＞ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ＜／ｉｎｐｕｔ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｏｕｔｐｕｔＳｉｚｅ”＞ｐａｒａｍ１＜／ｉｎｐｕｔ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ＡＰＩ＿ＫＥＹ”＞ｐａｒａｍ２＜／ｉｎｐｕｔ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｏｕｔｐｕｔ＿ｔｏｐｉｃｓ”＞＊＜／ｉｎｐｕｔ＞
＜／ｔｏｐｉｃｓ＞
＜ｐａｙｌｏａｄ＞
＜ｉｎｐｕｔＴｙｐｅ＝”ｐｎｇ”＞ｉｍａｇｅ＜／ｉｎｐｕｔ＞
＜／ｐａｙｌｏａｄ＞
＜／ｓｅｒｖｉｃｅＩｎｔｅｒｆａｃｅ＞

図１３のステップ４では、サービス層クライアント１３１６は、第三者サービスに対する使用を設定する。インターフェース記述からの情報を使用して、ＭＱＴＴクライアントセンサは、サービスインターフェース内に定義されたトピックにパブリッシュされるメッセージを作成する。この例では、以下であることができる。
ｓｅｒｖｉｃｅｏｂｊｅｃｔ．ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ．２５６．ＡＫＵ１ＦＹＹ１ＧＢＤＫＪＲＢ．ｍｙＨｏｕｓｅ．ｆｒｏｎｔｄｏｏｒ
ここで、
「ｓｅｒｖｉｃｅｏｂｊｅｃｔ」および「ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ」は、２つの要求されるトピックであり、
「２５６」は、出力サイズパラメータであり、
「ＡＫＵ１ＦＹＹ１ＧＢＤＫＪＲＢ」は、ＡＰＩ＿ＫＥＹパラメータであり、
「ｍｙＨｏｕｓｅ．ｆｒｏｎｔｄｏｏｒ」は、ｏｕｔｐｕｔ＿ｔｏｐｉｃｓである。
このメッセージのペイロードは、「ｐｎｇ」フォーマットにおける画像でなければならない。

図１３のステップ５では、サービス層クライアント１３１６は、第三者サービスの使用をトリガする。我々の実施例におけるＭＱＴＴクライアントセンサは、前述のフォーマットに従って画像をパブリッシュする。

図１３のステップ６では、サービス層は、ユーザデータを第三者サービスにプロキシする。「ｓｅｒｖｉｃｅｏｂｊｅｃｔ」トピックは、このメッセージをサービスオブジェクト拡張機能にダイレクトするために使用される。「ｐｕｎｙＰｎｇＳｅｒｖｉｃｅ」トピックは、第三者サービスのためのサービスオブジェクトＡＰＩを見つけるために使用される。トピック名の残りにおけるパラメータは、第三者サービスＡＰＩによって要求されるパラメータにマップされる。サービスオブジェクト拡張機能は、パブリッシュされたメッセージ内に提供されるデータを使用して、規定された一連の要求および応答を行う。サービスオブジェクトは、結果を「ｏｕｔｐｕｔ＿ｔｏｐｉｃｓ」にパブリッシュする。

図１３のステップ７では、サービス層クライアント１６１６は、第三者サービスの結果へのアクセスを有する。これらのトピックの受信を望むクライアントアプリは、「ｏｕｔｐｕｔ＿ｔｏｐｉｃｓ」にサブスクライブし、第三者サービスに由来する圧縮画像を受信することができる。

図１３に図示されるステップを行うエンティティは、図１５Ｃまたは１５Ｄ（我々の２つの環境図）に図示されるもののうちの１つ等、デバイス、サーバ、または他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１３に図示される方法は、例えば、図１５Ｃまたは１５Ｄに図示されるデバイスまたはコンピュータシステム等、コンピューティングデバイスのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図１３に図示されるステップを行う。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、ユーザがサービス層を介して第三者サービスにアクセスすることをイネーブルにすることに関連する機能性を制御および／または構成することを補助するために使用されることができる。ＧＵＩは、対応するＭ２ＭＳＬネイティブプロトコル内の第三者サービスのＡＰＩを規定する方法を定義する第三者サービスをサポートし、第三者サービスの発見をサポートし、サービスの記述を提供し、サービスへのアクセスの要求を可能にすることができる。図１４は、例示的インターフェース１４０２、１４０４、および１４０６を図示する略図である。インターフェース１４０２は、ユーザが、提供されるサービスについての記述または追加の情報を入力することを可能にする。インターフェース１４０４は、ユーザが、要求ＡＰＩを入力し、予期される応答を示すことを可能にする。インターフェース１４０６は、第三者サービスの検索を可能にする。インターフェース１４０２、１４０４、および１４０６は、以下に説明される図１５Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図１５Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴだけではなく、ＩｏＴ／ＷｏＴサービス層等のコンポーネントまたはノードであり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の機能性および論理エンティティならびにインターフェース１４０２、１４０４および１４０６等のインターフェースを生成するための論理エンティティを含むことができる。

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

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

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図１５Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の機能性および論理エンティティならびにインターフェース１４０２、１４０４および１４０６等のインターフェースを生成するための論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図１５Ｃおよび１５Ｄで図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

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

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

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

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示されるシステムおよび方法と併せて使用され得る。

一実施形態では、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティは、図１５Ｂに示されるようなＭ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内にホストされ得る。例えば、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。前述のように、このシステムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩＭ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩＭ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩＭ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩＭ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、もしくは１つ以上の既存のノードの一部としてのいずれかで実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図１５Ｃまたは図１５Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で作動するソフトウェアの形態において実装され得る。

さらに、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図１５Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティを実行するか、または含むことができる。デバイス３０は、図１５Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部または非Ｍ２Ｍネットワークの一部であり得る。図１５Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させ得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

図１５Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に連結される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御し得る。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図１５Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内に一緒に統合され得ることが理解されるであろう。

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させる、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得る、または情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にし得る。

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

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

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

図１５Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等、Ｍ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティを実行するか、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２ＥＭ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

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

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

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

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

さらに、コンピューティングシステム９０は、例えば、図１５Ａおよび図１５Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にし得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。外部サービス６０６、センサ６０２のための論理エンティティ、Ｍ２Ｍサービス層６０４、アプリケーション６０８、ＣＳＥ８０６、ウェブサービス８０４および１３１２、ｏｎｅＭ２Ｍサービスオブジェクトプロビジョニングツール８０２、サービスアクセスイネーブルメント９０２、サービスコンポーネントサービスアクセスイネーブルメント１２０２、ＭＱＴＴクライアントセンサ１３１６、サービスオブジェクトＭＱＴＴ拡張機能１３０６、ＭＱＴＴブローカ１３０２、トピックディレクトリＭＱＴＴ拡張機能１３１０、ＭＱＴＴクライアントアプリケーション１３１８、およびサービスオブジェクトプロビジョニングツール１３１４等の論理エンティティならびにインターフェース１４０２、１４０４、および１４０６等のインターフェースを生成するための論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されるコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形または物理媒体を含むが、それらに限定されない。

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

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

Claims

プロセッサ、メモリ、および通信回路を備えているノードであって、前記サーバは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記サーバの前記プロセッサによって実行されると、
サービス層を使用して、外部サービスへのアクセスを提供することと、
アプリケーションが前記外部サービスに独立してコンタクトすることなく、前記サービス層を通して前記外部サービスからサービスをアプリケーションに提供することと
を前記ノードに行わせる、ノード。
前記サービス層は、ｏｎｅＭ２Ｍサービス層である、請求項１に記載のノード。
前記ｏｎｅＭ２Ｍサービス層は、共通サービスエンティティ（ＣＳＥ）内のサービスアクセスイネーブルメント共通サービス機能（ＣＳＦ）を使用する、請求項２に記載のノード。
前記ノードは、前記外部サービスによって提供されるアプリケーションプログラミングインターフェース（ＡＰＩ）を前記サービス層内のサービス層リソースにマップする、請求項１に記載のノード。
前記サービス層リソースは、前記アプリケーションによってアクセスされる、請求項４に記載のノード。
前記ノードは、データを前記アプリケーションのために前記サービス層から前記外部サービスにプロキシする、請求項１に記載のノード。
前記ノードは、前記サービス層において前記外部サービスから結果を受信し、前記結果を前記アプリケーションに利用可能にする、請求項６に記載のノード。
前記ノードは、前記サービス層において外部サービスの発見を可能にする、請求項１に記載のノード。
ネットワークに接続されたサーバによる使用のための方法であって、前記サーバは、プロセッサおよびメモリを備え、前記サーバは、前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、前記ネットワーク内のサーバの機能を実施し、前記方法は、
サービス層を使用して、外部サービスへのアクセスを提供することと、
アプリケーションが前記外部サービスに独立してコンタクトすることなく、前記サービス層を通して前記外部サービスからサービスを前記アプリケーションに提供することと
を含む、方法。
前記サービス層は、ｏｎｅＭ２Ｍサービス層である、請求項９に記載の方法。
前記ｏｎｅＭ２Ｍサービス層は、共通サービスエンティティ（ＣＳＥ）内のサービスアクセスイネーブルメント共通サービス機能（ＣＳＦ）を使用する、請求項１０に記載の方法。
前記外部サービスによって提供されるアプリケーションプログラミングインターフェース（ＡＰＩ）を前記サービス層内のサービス層リソースにマップすることをさらに含む、請求項９に記載の方法。
前記サービス層リソースは、前記アプリケーションによってアクセスされる、請求項１２に記載の方法。
データを前記アプリケーションのために前記サービス層から前記外部サービスにプロキシすることをさらに含む、請求項９に記載の方法。
前記サービス層において前記外部サービスから結果を受信し、前記結果を前記アプリケーションに利用可能にすることをさらに含む、請求項１４に記載の方法。
前記サービス層において外部サービスの発見を可能にすることをさらに含む、請求項９に記載の方法。
プロセッサ、メモリ、および通信回路を備えているノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記サーバのプロセッサによって実行されると、
アプリケーションを実装することと、
サービス層を使用して、外部サービスにアクセスすることと、
前記サービス層を通して前記外部サービスからデータを受信することと
を前記サーバに行わせる、ノード。
ネットワークに接続されたノードによる使用のための方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、プロセッサによって実行されると、前記ネットワーク内のアプリケーションの機能を行い、前記方法は、
サービス層を使用して、外部サービスにアクセスすることと、
前記サービス層を通して前記外部サービスからデータを受信することと
を含む、方法。