JP6695832B2 - 機械対機械サービスレイヤ間の通信および送信ネットワーク - Google Patents

Description

関連出願に対する相互参照
本願は、２０１３年１月２４日に出願された米国仮出願第６１／７５６，３９７号、および２０１３年２月１４日に出願された米国仮出願第６１／７６４，９５３号の優先権を主張する。これら特許出願の全体は参照により本願に組み込まれる。

本願は、機械対機械（Ｍ２Ｍ）通信に関する。

Ｍ２Ｍ通信は、２つの異なるデバイス間の通信を含み、これはユーザによって明示的に開始されるものではない。デバイスは、有線接続または無線接続を用いてＭ２Ｍ通信を実施する。この通信は通常、ある機械上に搭載されたアプリケーションによって起動され、これにより情報を収集しまたは他の機械上の対応するアプリケーションに対して情報を送信する。現在のＭ２Ｍ通信技術は、この技術が提供する利点を必ずしもすべて享受することができない。これは、Ｍ２Ｍの典型的な実装におけるプロトコルスタックの層間の垂直統合が直面している課題に起因する。

本願は、Ｍ２Ｍデバイス間のユビキタス通信を促進する技術について記載している。相互運用を促進するため、アプリケーションプログラミングインターフェース（ＡＰＩ）プロファイルを定義する。このＡＰＩプロファイルは、デバイスがＯＮ／ＯＦＦいずれであるかを検出するなどの共通タスク、および特定変数（例えば現在のバッテリパワーや計測温度など）を照会することができるような特殊タスクを含む。

１側面において、Ｍ２Ｍ通信を促進する方法、システム、および装置は、１以上の規定機械対機械（Ｍ２Ｍ）アプリケーションプログラミングインターフェース（ＡＰＩ）プロファイルを実装したＭ２Ｍシステムを提供するステップ；前記Ｍ２Ｍシステムに対してネットワークインターフェースを提供するステップ；前記ネットワークインターフェースを介してプロファイルクエリを受信するステップ；前記１以上の規定Ｍ２Ｍ ＡＰＩプロファイルに関する情報を応答するステップ、を有する。

その他側面、およびその実装と変形例については、以下の図面、実施形態、および特許請求範囲に記載する。

無線ネットワークアーキテクチャの例を示す。

無線ネットワークで動作可能な無線デバイスのブロック図である。

ｅ２ｅ Ｍ２Ｍサービスの層構造の例を示す。

Ｍ２Ｍサービススタックの例を示す。 Ｍ２Ｍサービススタックの例を示す。 Ｍ２Ｍサービススタックの例を示す。 Ｍ２Ｍサービススタックの例を示す。

Ｍ２Ｍ ＳＤＯがサポートするインターフェースとＡＰＩの例を示す。

Ｍ２Ｍ通信を促進するプロセスのフローチャートである。

Ｍ２Ｍシステムの一部のブロック図を示す。

各図面における同様の符号は同様の要素を示す。

ｏｎｅＭ２Ｍ、ＥＴＳＩ ＴＣ Ｍ２Ｍ、ＴＩＡ ＴＲ−５０などの組織（Ｍ２Ｍ ＳＤＯ）が開発するサービスレイヤ規格は、様々な市場中心（垂直）組織がＭ２Ｍソリューションを効率的に配置することをサポートする必要がある。サービスレイヤにフォーカスすることにより、このような組織は送信ネットワークから独立したエンドトゥエンドサービスの見方を取っている。それでもこれら組織は、異なるタイプの送信ネットワークとのインターフェースを保つためサービスレイヤ規格が効率的に使われるようにしなければならない。この送信ネットワークは、３ＧＰＰ、３ＧＰＰ２、ＩＥＥＥ、ＩＥＴＦ、ＢＢＦなどが規定する無線および有線ネットワークを含むが、これに限られない。

送信ネットワーク規格を開発している組織は、Ｍ２Ｍサービスをサポートするためネットワークを拡張し最適化している。３ＧＰＰや３ＧＰＰ２などの送信ネットワーク規格開発団体は、Ｍ２Ｍサービスをサポートするアーキテクチャ拡張を定義しつつサービスレイヤに依拠しないアプローチをとっている。３ＧＰＰと３ＧＰＰ２は、複数のビジネスモデルを促進するＭ２Ｍ配置シナリオセットを規定している。この配置シナリオは、提供されるサービスタイプおよびＭ２Ｍエコシステムの“プレイヤ”間のやり取りの性質から発展したものである。

Ｅ２Ｅ Ｍ２Ｍエコシステムにおける複数の“プレイヤ”の役割を認識する一方で、Ｍ２Ｍ ＳＤＯ（規格開発組織）にとっては、Ｍ２Ｍ業界プレイヤが開発プラットフォームや相互やり取りするプレイヤに依拠することなくシステムとサービスをシームレスに統合することができるようにすることが重要である。これらプレイヤにとっては、プロトコルの詳細や相互通信するピアの細かな技術的事項を知る必要はない。これらＭ２Ｍエコシステムにおけるプレイヤは、自身のシステムを関連する業界標準へ移行することにより、既存の配置をサポートし続けることができる。

本文書は、Ｍ２Ｍサービススタックを開示する。異なる“レイヤ”は、Ｍ２Ｍエコシステムにおける異なるプレイヤを表す。サービススタックとこれに関連するフレームワークは、Ｍ２Ｍサービスにおける異なるレイヤが提供する機能を統合するための“接着剤”のようなものを提案する。トランスポートネットワークレイヤをＭ２ＭサービススタックのＭ２Ｍサービスレイヤコンポーネントと統合する手段を開発するアプローチについて、以下に説明する。

図１は、無線通信ネットワークまたはシステムの例を示す。この無線通信ネットワークは、１以上のベースステーション（ＢＳ）１０５、１０７および１以上の無線デバイス１１０を有する。ベースステーション１０５と１０７は、１以上の無線デバイス１１０に対してフォワードリンク（ＦＬ）上で信号（ダウンリンク（ＤＬ）信号として知られている）を送信することができる。無線デバイス１１０は、１以上のベースステーション１０５と１０７に対してリバースリンク（ＲＬ）上で信号（アップリンク（ＵＬ）信号として知られている）を送信することができる。無線通信システムは、１以上のネットワーク１２５を有し、１以上のベースステーション１０５と１０７を制御する。１以上のベースステーションは、無線アクセスネットワークを形成する。ベースステーションは、単独もしくは１以上のベースステーションとの組み合わせで無線デバイスに対して無線アクセスを提供するという性質上、アクセスポイント（ＡＰ）、アクセスネットワーク（ＡＮ）、またはｅＮｏｄｅＢと呼ばれる場合がある。本技術およびシステムを実装することができる無線通信システムの例としては、ＣＤＭＡ２０００ １ｘなどのＣｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＣＤＭＡ）、Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ＨＲＰＤ）、Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）、などに基づく無線通信システムが挙げられる。

図２は、無線デバイス、ベースステーション、またはその他無線通信モジュールを実装する無線トランシーバステーションの例を示す。無線ステーションの例は、図１のベースステーションと無線デバイスを含む。ベースステーションや無線デバイスなどの無線ステーション２０５は、マイクロプロセッサなどのプロセッサ電子部品２１０を備える。同プロセッサは、本文書で説明する１以上の技術などの方法を実装する。無線ステーション２０５は、トランシーバ電子部品２１５を備え、１以上のアンテナ２２０などのような１以上の通信インターフェース上で無線信号を送信および／または受信する。無線ステーション２０５は、データを送受信するその他通信インターフェースを備えてもよい。実装例において、無線ステーション２０５は１以上の有線通信インターフェースを備え、有線ネットワークと通信する。無線ステーション２０５は、１以上のメモリ２２５を備える。メモリ２２５は、データおよび／または命令などの情報を格納するように構成されている。実装例において、プロセッサ電子部品２１０は、トランシーバ電子部品２１５やメモリ２２５の少なくとも一部を備えてもよい。

実装例において無線ステーション２０５は、ＣＤＭＡまたはＧＳＭ(登録商標)ベースのインターフェースに基づき相互通信する。実装例において無線ステーション２０５は、ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ（ＯＦＤＭ）インターフェースに基づき相互通信する。これはＯｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ−Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＯＦＤＭＡ）インターフェースを含む。実装例において無線ステーション２０５は、１以上の無線技術を用いて通信することができる。この無線技術は例えば、ＣＤＭＡ２０００ １ｘ、ＨＲＰＤ、ＷｉＭＡＸ、ＧＳＭ(登録商標)、ＬＴＥ、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）である。

実装例において、無線ステーション２０５はさらに、８０２．１１（ａ／ｂ／ｇ／ｎ）インターフェースなどのローカルエリアネットワーク接続を備えるように構成することができる。このようなインターフェースを利用できることにより、ローカルエリア接続を介して無線ステーション２０５をインターネットと通信可能に接続することができる。例えばユーザは、ケーブルモデムネットワークやＤＳＬネットワークなどの固定ブロードバンドネットワークを経由して無線ローカルエリアネットワーク接続（例えば家庭Ｗｉ−Ｆｉアクセス）を介してサービスに接続することにより、自身のユーザ機器（ＵＥ）を介してサービスにアクセスすることができる。

エンドトゥエンドサービスの層構造

図３は、Ｍ２Ｍエコシステムにおける複数のプレイヤをエンドトゥエンド（ｅ２ｅ）Ｍ２Ｍサービスの“層構造”として見た例を示す。このｅ２ｅ構造は通常、Ｍ２Ｍアプリケーションサーバ（ＡＳ）が搭載するＭ２ＭアプリケーションとＭ２Ｍデバイス／ゲートウェイを備える。この層構造において、Ｍ２Ｍサービスプラットフォーム（Ｍ２Ｍ ＳＰ）はＭ２Ｍデータマネジメントおよび／またはＭ２Ｍサービス実現機能を提供する。基盤となるトランスポートネットワークは、Ｍ２Ｍデバイス／ゲートウェイが搭載するＭ２Ｍアプリケーションとアプリケーションサーバとの間のデータフローのための送信および通信サービスを提供する。

Ｍ２Ｍサービスのこのような層構造により、Ｍ２Ｍアプリケーションサーバ、Ｍ２Ｍデバイス／ゲートウェイ、Ｍ２Ｍサービスプラットフォーム、およびトランスポートネットワークは、ｅ２ｅ Ｍ２Ｍサービススタックにおける異なる“層”とみなすことができる。各“層”はさらに、異なるビジネス主体を表しているとみなすことができる。各層は、機能セットを提供し、さらに他層と通信するためのインターフェースおよび／またはＡＰＩセットを提供する。別のサービスや別のビジネスモデルをサポートするため、別の態様で“層”を重ねることもできる。これら“層”を別の態様で重ねることは、別の配置シナリオを表し、通信層間の別のインターフェースおよび／またはＡＰＩタイプをサポートすることが必要になることを表す。

図４Ａは、“直接”通信モデルを表すＭ２Ｍサービススタックの例である。ＡＳは、Ｍ２Ｍサービスプラットフォームを用いずにトランスポートネットワークと直接通信する。ＡＳにおけるアプリケーションは、トランスポートネットワークが提供するサービスを利用する。トランスポートネットワークが提供するサービスは、当該トランスポートネットワーク固有のＡＰＩセットによって抽象化することができる。このＡＰＩは、トランスポートネットワークの運用業者によって定義されアプリケーション開発者がこれを利用可能となり、またはＭ２Ｍ ＳＤＯ、ＯＭＡなどの組織が定義するオープンＡＰＩセットとして定義され、および／またはネットワーク運用業者が定義するＡＰＩとオープンＡＰＩの組み合わせである。

図４Ｂ、図４Ｃ、図４Ｄは、“間接”通信モデルの例である。ＡＳにおけるアプリケーションは、Ｍ２Ｍサービスプラットフォームが提供するサービスを介してトランスポートネットワークと通信する。このＭ２Ｍサービスプラットフォームが提供する機能やサービスは、アプリケーションデータマネジメント、デバイスマネジメント、接続マネジメントなどのサービスを含む。本例におけるこれら機能やサービスは、それぞれデータマネジメントサブレイヤとサービス実現サブレイヤが提示するインターフェースおよび／またはＡＰＩセットによって抽象化することができる。Ｍ２Ｍ ＳＤＯとそのパートナー組織はこのようなインターフェースおよび／またはＡＰＩを識別し特定することをリードするであろうことが想定される。

図４Ａ〜図４Ｄには示していないが、“ハイブリッド”通信モデルをサポートすることもできる。“ハイブリッド”通信モデルにおいて、ＡＳはユーザデータトラフィックを送信する際に、トランスポートネットワークと通信するため、“直接”モデルを用いる。同時にＡＳは、デバイス管理に関するサービス、デバイストリガリングなどの付加価値サービスのために、Ｍ２Ｍサービスプラットフォームが提供するサービスを用いる。“直接”および“間接”通信モデルと同様に、“ハイブリッド”通信モデルにおける異なる“レイヤ”間の通信は、ピア通信レイヤがサポートするインターフェースおよび／またはＡＰＩを利用する。

Ｍ２Ｍ ＳＤＯの役割

サービスレイヤにフォーカスすることにより、Ｍ２Ｍ ＳＤＯはエンドトゥエンドサービスを送信ネットワークから切り離してみると想定される。ただしＭ２Ｍ ＳＤＯは、異なるタイプの送信ネットワークとのインターフェースを保つためにサービスレイヤ規格が効率的に使われるようにしなければならない。

このような送信ネットワークから独立したアプローチにより、Ｍ２Ｍサービススタックは２つの独立した機能セットとして様々に表すことができる：トランスポートネットワークレイヤが提供する機能とＭ２Ｍサービスレイヤが提供する機能である。これら２つのレイヤは、ピアエンティティがこれらレイヤの機能やリソースを用いることによって効率的に通信するように、同機能やリソースを提示するインターフェースおよび／またはＡＰＩセットを提供することが想定される。

これら２つの“レイヤ”が提供する機能セットは、同じビジネスエンティティによってまたは別のビジネスエンティティによって提供することができる。１つのビジネスエンティティが双方の機能を提供するシナリオにおいて、関連するインターフェースおよび／またはＡＰＩは、そのビジネスエンティティ内のものである。そのようなシナリオはここでの議論の対象外である。これら２つのレイヤが提供する機能が異なるビジネスエンティティによって提供される場合、ピアレイヤが効率的に通信するため用いることができる、標準化されたインターフェースおよび／またはＡＰＩセットを規定することが望ましい。

Ｍ２Ｍサービスレイヤ（例えばＭ２Ｍサービスプラットフォーム）が提供する機能は送信ネットワークから独立しているが、Ｍ２Ｍサービスレイヤは基盤となるトランスポートネットワークのプロトコルや詳細事項について知っておくべきである。したがって、Ｍ２Ｍサービスレイヤとトランスポートネットワークとの間のインターフェースおよび／またはＡＰＩセットは、基盤トランスポートネットワークがサポートする技術に固有のものであるべきである。説明目的のため、および読み易くするため、トランスポートネットワーク固有インターフェースおよび／またはＡＰＩセットそれぞれを、トランスポートネットワーク固有コンバージェンスレイヤと呼ぶ。

コンバージェンスレイヤ

トランスポートネットワーク固有コンバージェンスレイヤの定義は、インターフェースセットおよび／またはＡＰＩセットの規定を含む。トランスポートネットワーク固有コンバージェンスレイヤは、Ｍ２Ｍ ＳＤＯと、関連する送信ネットワーク技術を指定する組織との共同作業を通じて定義される。例えば３ＧＰＰと３ＧＰＰ２は、Ｍ２Ｍサービスプラットフォームと３ＧＰＰおよび３ＧＰＰ２それぞれとの間のインターフェースとして、ＴｓｐとＭ２Ｍｓｐを指定している。これらインターフェース（ＴｓｐとＭ２Ｍｓｐ）は、Ｍ２Ｍ ＳＤＯと３ＧＰＰ／３ＧＰＰ２との間の共同作業を通じて定義され、本文書の対象ではない。本文書の対象は、Ｍ２Ｍサービスプラットフォーム（Ｍ２Ｍサービスレイヤとして抽象化されている）と基盤トランスポートネットワークとの間で用いることができるＡＰＩセットを定義するためＭ２Ｍ ＳＯＤが用いるアプローチである。

オープンネットワークＡＰＩ

Ｍ２Ｍ ＳＤＯは、様々な市場中心（垂直）組織がＭ２Ｍソリューションを効率的に配置することをサポートする機能セットを提供することができる。専用ＡＰＩが増えて業界が断片化されることを避けるため、Ｍ２ＭアプリケーションとＭ２Ｍサービスプラットフォームの開発者は、標準化された基盤送信ネットワークの既存の機能セットにアクセスできることが望ましい。このとき開発者は、同ネットワークのプロトコルや技術詳細部分について知識を有している必要がないことが望ましい。

１例として、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）ネットワークＡＰＩにより、送信ネットワークはオープンかつプログラム可能な態様で、自ネットワークの機能とリソースを抽象化して提示することができる。これにより、（開発プラットフォームから独立して、さらにＯＭＡ ＡＰＩをサポートする事業者およびサービスから独立して）アプリケーションやコンテンツを生成するため必要な開発コストおよび時間を削減することができる。

同様に、ＧＳＭＡ ＯｎｅＡＰＩプロジェクトはＯＭＡと共同作業して、Ｐａｒｌａｙ Ｘ Ｗｅｂ ＡＰＩを簡易化し、ＲＥＳＴｆｕｌバインディングとより簡易なＪＳＯＮ／ＸＭＬレスポンスの選択を提供することにより同ＡＰＩを改良している。その結果得られたＧＳＭＡ ＯｎｅＡＰＩプロファイルは、アプリケーション開発者に対してＷｅｂアプリケーション経由でモバイルネットワーク機能およびリソースについての情報を提示するＡＰＩセットである。アプリケーション開発者は例えば、単一のＷｅｂサービスリクエストを発行して、モバイルネットワークにおけるデバイスのロケーションを取得し、音声コールを発信することができる。このようなアプリケーションは、ネットワークタイプやネットワーク技術をまたがって移植することができる。アプリケーション開発を簡易化することに加えて、ＯｎｅＡＰＩプロファイルの利点としては以下が挙げられる：

ＯｎｅＡＰＩプロファイルは、ネットワーク事業者が既に提供しているＡＰＩを破棄することを必要としない。ＯｎｅＡＰＩは、他のＡＰＩサービスと共存することができる。

ＯｎｅＡＰＩプロファイルは、ネットワーク事業者が互いのＡＰＩリクエストを提供するための基盤を提供する。例えば、他事業者を訪れたローミングユーザからのロケーションリクエストを充足することができる。

ＯｎｅＡＰＩプロファイルにより、開発者が用いるＡＰＩを設計する時間とコストを事業者が投資する必要がなくなる。

ＯｎｅＡＰＩプロファイルの共通ベンダ実装から得られる規模の経済の利益がある。

本提案は、Ｍ２Ｍ ＳＤＯがＯｎｅＡＰＩ Ｉｎｉｔｉａｔｉｖｅと同様に用いることができるアプローチである。Ｍ２Ｍ ＳＤＯは、パートナーおよび組織（例えばＯＭＡ）と共同作業して、Ｍ２Ｍアプリケーション開発者およびＭ２Ｍサービスプラットフォーム開発者が用いることができるＭ２Ｍ ＡＰＩプロファイルセットを開発する。このＭ２Ｍ ＡＰＩプロファイルセットにより、開発者がＭ２Ｍアプリケーションやコンテンツを生成するコストや時間を削減することができる。アプリケーションは、異なる市場中心（垂直）組織にまたがって、および送信ネットワーク事業者にまたがって、移植することができる。Ｍ２Ｍ ＡＰＩプロファイルセットにより、送信ネットワーク事業者は自ネットワークと複数機器ベンダからのＭ２Ｍサービスプラットフォームをシームレスに統合することができる。

Ｍ２Ｍ ＳＤＯは、ＧＳＭＡ ＯｎｅＡＰＩ Ｉｎｉｔｉａｔｉｖｅによる成果にならって、ＯｎｅＡＰＩプロファイルを評価することが想定される。ＧＳＭＡ ＯｎｅＡＰＩプロファイルは、Ｍ２Ｍサービスが必要とする送信ネットワーク機能を抽象化するＭ２Ｍ固有ＡＰＩプロファイルを定義することによって、強化することができる。下記セクションは、ＧＳＭＡ ＯｎｅＡＰＩプロファイルのスナップショットとステータスを提示する。ＯｎｅＡＰＩプロファイルの利用可能セットによって提供される機能と、Ｍ２Ｍ ＳＤＯ固有サービスレイヤの包括的実装が必要とする機能との間のギャップを分析することにより、フォーカスすることが必要な領域が分かる。特定したフォーカス領域とギャップは、Ｍ２Ｍ ＳＤＯ単独、および／またはパートナーや業界組織（例えばＯＭＡ、ＢＢＦなど）との共同作業によって対処され、より完全なＭ２Ｍ ＡＰＩプロファイルスイートが開発される。

補足−ＧＳＭＡ ＯｎｅＡＰＩプロファイルのステータス

ＧＳＭＡ ＯｎｅＡＰＩプロジェクトは、ＯＭＡと共同作業して、Ｐａｒｌａｙ Ｘ Ｗｅｂ ＡＰＩを簡易化し、対応するＲＥＳＴｆｕｌバインディングを提供することにより同ＡＰＩを改良している。最初のＯｎｅＡＰＩバージョン１は、支払、ロケーション、メッセージングなどのネットワーク機能にフォーカスしている。ＧＳＭＡ ＯｎｅＡＰＩバージョン２は、デバイス機能判定、ベアラー識別、音声／コールサービスの機能を追加した。バージョン３は、より進化した機能を目指している。例えばＱｏＳ、映像コール、識別、フェムトセルサポートなどである。

以下はＯｎｅＡＰＩプロファイルのＡＰＩリストである。実際のモバイル事業者のＡＰＩサポートは、事業者ネットワーク機能に依拠する。

支払

ユーザに課金する

ユーザに返金する

後の課金のため積み立てる

積み立てを増やす

積み立てに対して課金する

積み立てを解消する

ＳＭＳ：

ＳＭＳを送信する

ＳＭＳ配信ステータスを照会する

ＳＭＳ配信ステータスのサブスクリプションを開始する

ＳＭＳ配信ステータスのサブスクリプションを停止する

ＳＭＳを受信する

ＳＭＳ受信のサブスクリプションを開始する

ＳＭＳ受信のサブスクリプションを停止する

ＭＭＳ：

ＭＭＳを送信する

ＭＭＳ配信ステータスを照会する

ＭＭＳ配信ステータスのサブスクリプションを開始する

ＭＭＳ配信ステータスのサブスクリプションを停止する

ＭＭＳメッセージリストを受信する

フルＭＭＳメッセージ（コンテンツ）を受信する

ＭＭＳ受信のサブスクリプションを開始する

ＭＭＳ受信のサブスクリプションを停止する

ロケーション：

モバイル端末のロケーションを照会する

音声コール制御：

２以上の参加者間でコールを生成する

コールに対して参加者を追加しまたは削除する

参加者についての情報を得る

既存のコールについての情報を得る

コールを終了する

コール内の特定イベントの通知を受け取る

自身の通知条件を見る

通知の受信を停止する

音声メッセージを再生する

音声メッセージを停止する

音声メッセージのステータスを取得する（誰に対して再生されているか）

音声ファイルを再生して参加者をコールし、キーパッド操作を収集する

音声メッセージ／キーパッド操作を終了する

参加者から自身の音声メッセージに対する任意のキーパッド操作について通知を受ける

キーパッド通知の受信を停止する

データ収集プロファイル：

端末の接続タイプ（３Ｇ、ＧＰＲＳなど）をリクエストする

端末のローミングステータスを取得する

デバイス機能：

モバイルアカウントのデバイス機能を取得する

ＯＭＡ文書“ＯＭＡ−ＴＳ−ＲＥＳＴ＿ＮｅｔＡＰＩ＿ＯｎｅＡＰＩＰｒｏｆｉｌｅ−Ｖ３＿０−２０１２０３２７−Ｃ”は、ＲＥＳＴｆｕｌネットワークＡＰＩのＯｎｅＡＰＩプロファイルバージョン３．０の候補である。先に述べたように、ＧＳＭＡ ＯｎｅＡＰＩプロジェクトは、３ｒｄパーティーアプリケーションの配置と動作問題に取り組んでおり、Ｐａｒｌａｙ ＸおよびＯＭＡ ＲＥＳＴｆｕｌネットワークＡＰＩのサブセットを用いてＲＥＳＴｆｕｌネットワークＡＰＩのＯｎｅＡＰＩプロファイルを抽象化している。

ＲＥＳＴｆｕｌネットワークＡＰＩのＯｎｅＡＰＩプロファイルのバージョン３．０は、以下のＡＰＩのサブセットを定義している。

RESTful Network API for Short Messaging V 1.0

RESTful Network API for Messaging V 1.0

RESTful Network API for Terminal Location V 1.0

RESTful Network API for Payment V 1.0

RESTful Network API for Device Capabilities V 1.0

RESTful Network API for Terminal Status V 1.0

RESTful Network API for Third Party Call V 1.0, Call Notification V 1.0 and Audio Call V 1.0 (まとめてCall Control APIと呼ぶ)

図６は、機械対機械（Ｍ２Ｍ）通信を促進するプロセス３００のフローチャートである。

ステップ３０２において、Ｍ２Ｍシステムが提供される。Ｍ２Ｍシステムは、例えば開発者、製造者、サービスプロバイダ、またはネットワーク事業者によって提供され、有線または無線ネットワークにおいて使用および配置される。Ｍ２Ｍシステムは、１以上の規定機械対機械（Ｍ２Ｍ）アプリケーションプログラミングインターフェース（ＡＰＩ）プロファイルを実装している。補足Ａで述べるように、これらプロファイルは、１以上の業界標準団体またはイニシアチブによって定義される。

ステップ３０４において、Ｍ２Ｍシステムのプロバイダは、Ｍ２Ｍシステムのネットワークインターフェースを提供する。ネットワークインターフェースは、設計、製造、設置によって提供される。これらに加えて、ネットワークインターフェースはＭ２Ｍシステムが所与のネットワーク上で動作することを認可することにより提供することもできる（例えば設定、サブスクリプション、サービスアグリーメントなど）。

ステップ３０６において、Ｍ２Ｍシステムはネットワークインターフェース上でプロファイルクエリを受信する。クエリは例えば、ネットワーク内の他のＭ２Ｍシステムから受信される。

ステップ３０８において、Ｍ２Ｍシステムは、１以上の規定のＭ２Ｍ ＡＰＩプロファイルの実装についての情報を応答する。

実装例において、１以上のＭ２Ｍ ＡＰＩプロファイルは、ネットワークインターフェースが用いる送信プロトコルに依拠しない第１モジュール、およびネットワークインターフェースが用いる送信プロトコルを用いて信号を送受信する第２モジュールを有するように実装される。

実装例において、プロセス３００はさらに、管理情報データベース（ＭＩＢ）内に、１以上の規定Ｍ２Ｍ ＡＰＩプロファイルのうちいずれかに対応する情報を格納するステップを有する。ＭＩＢは、ローカルメモリにおいて個別にアドレス割当することができるメモリ領域群の形態で実装することができる。ＭＩＢエントリは、トランザクション履歴、ハードウェア識別パラメータ、アラーム条件、エラーをマスクできるか否か、スリープモード動作（例えばデバイスがスリープできる頻度および長さ）、などのエントリを含む。

実装例において、１以上の規定Ｍ２Ｍ ＡＰＩプロファイルが指定するルールにしたがって、他システムによって情報を読み書き可能にすることができる。

図７は、機械対機械（Ｍ２Ｍ）通信を促進する装置４００のブロック図である。モジュール４０２は、１以上の規定機械対機械（Ｍ２Ｍ）アプリケーションプログラミングインターフェース（ＡＰＩ）プロファイルを実装したＭ２Ｍシステムを提供する。モジュール４０４は、Ｍ２Ｍシステムのネットワークインターフェースを提供する。モジュール４０６は、ネットワークインターフェース上でプロファイルクエリを受信する。モジュール４０６は、１以上の規定Ｍ２Ｍ ＡＰＩプロファイルの実装についての情報を応答する。

実装例において、Ｍ２Ｍ通信システムは、本文書が開示する技術に基づき動作させることができる。同システムは、ネットワークを介して第２Ｍ２Ｍシステムと通信可能に接続された第１Ｍ２Ｍシステムを備える。第１Ｍ２Ｍシステムは、Ｍ２Ｍアプリケーションプログラミングインターフェース（ＡＰＩ）クエリを送信し、第２Ｍ２ＭシステムのＭ２Ｍ ＡＰＩ機能を受信するように構成されている。第２Ｍ２Ｍシステムは、ネットワーク上でＭ２Ｍ ＡＰＩ機能を送信するように構成されている。

実装例において、サービスレイヤはさらに、サービスレイヤ更新情報を提供する機能を備えることができる。例えば１動作シナリオにおいて、機械１は機械２と通信し、何らかのタスクを実施する（例えば、機械２が制御する照明の変化をリクエストする）。機械２が提供するサービスレイヤＡＰＩプロファイルに基づき、機械２は照明をＯＮ／ＯＦＦできるが照明暗くすることはできないことを、機械１は理解する。機械１は、機械２に対してリソース情報を提供する。この情報は、機械２が機能を拡張するためのコードアップデートを得られる場所についての情報を示す。コードアップデートは、機械が備えているべき実行量と記憶メモリを指定する。機械２はＭ２Ｍ ＡＰＩプロファイルを提供するサーバにアクセスし、サーバから新機能を取得する。新機能を受信すると、機械２は機械１にアクセスし、照明を暗くする要求タスクを完了する。実装例において、この手順全体はＭ２Ｍ通信によって実装される。すなわち人間は関与しない。

異なるアプリケーションエリアにおいてこれらデバイスを容易に配置することができるＡＰＩサービスプロファイルを実装することによってＭ２Ｍシステムを動作させる技術を開示したことが理解されるであろう。

上記およびその他実施形態と本文書が記載する機能的動作およびモジュールは、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、ハードウェア、本文書が開示する構造およびその等価構造、これら１以上の組み合わせに実装することができる。上記およびその他実施形態は、１以上のコンピュータ製品として実装することができる。すなわち、コンピュータ読取可能媒体上にコード化され、データ処理装置によって実行されまたはデータ処理装置の動作を制御する、１以上のコンピュータプログラム命令のモジュールである。コンピュータ読取可能媒体は例えば、機械読取可能記憶デバイス、機械読取可能記憶基板、メモリデバイス、機械読取可能伝搬信号を生じさせる組成物、またはこれら１以上の組み合わせである。“データ処理装置”は、装置、デバイス、データ処理マシンの全てを包含する。例えばプログラム可能プロセッサ、コンピュータ、マルチプロセッサもしくはマルチコンピュータ、を含む。装置は、ハードウェアに加えて、コンピュータプログラムの実行環境を生成するコードを含む。例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれら１以上の組み合わせを構成するコードである。伝搬信号は、人為的に生成した信号である。例えば、適当な受信装置に対して送信する情報をコード化するため生成された、機械生成電気信号、光信号、電磁信号である。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている）は、任意形態のプログラム言語で記述することができる。これは、コンパイル言語またはインタプリタ言語を含む。プログラムは、任意形態で配置することができる。これは、スタンドアロンプログラム、モジュール、コンポーネント、サブルーチン、その他コンピュータ環境において用いるのに適したユニットを含む。コンピュータプログラムは、ファイルシステムにおけるファイルと必ずしも対応している必要はない。プログラムは、その他プログラムやデータを保持するファイルの一部（例えばマークアップ言語文書に格納された１以上のスクリプト）、当該プログラム専用の単一ファイル、または複数の協調ファイル（例えば１以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）に格納することができる。コンピュータプログラムを配布して、単一のコンピュータ上、または１サイト上もしくは複数サイトに分散され通信ネットワークで相互接続された複数コンピュータ上で、実行することができる。

本文書が記載するプロセスおよびロジックフローは、入力データに対して動作し出力を生成する１以上のコンピュータプログラムを実行して機能を実施する１以上のプログラム可能プロセッサにより実施することができる。プロセスとロジックフローは、例えばＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）やＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）などの特定用途論理回路によって実施することもできる。装置はこれら回路として実装することもできる。

コンピュータプログラムを実行するのに適したプロセッサは、例えば汎用マイクロプロセッサおよび特定用途マイクロプロセッサ、あるいは任意種類のデジタルコンピュータの１以上のプロセッサである。一般にプロセッサは、読み取り専用メモリ、ランダムアクセスメモリ、またはこれら双方から命令やデータを受け取る。コンピュータの本質的要素は、命令を実施するプロセッサ、命令やデータを格納する１以上のメモリデバイスである。一般にコンピュータはさらに、１以上の大規模記憶デバイスを備え、または大規模記憶デバイスとの間でデータを送受信できるように接続されている。同記憶デバイスは、例えば磁気ディスク、光磁気ディスク、光ディスクなどである。しかしコンピュータは、これらデバイスを必ずしも備えていなくともよい。コンピュータプログラム命令やデータを格納するのに適したコンピュータ読取可能媒体は、全ての形態の不揮発メモリ、媒体、およびメモリデバイスを含む。例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリデバイスなどの半導体メモリデバイス、内部ハードディスクまたはリムーバブルディスクなどの磁気ディスク、光磁気ディスク、ＣＤ ＲＯＭおよびＤＶＤ−ＲＯＭディスクが挙げられる。プロセッサとメモリは、特定用途論理回路によって補足し、またはそのなかに組み込むことができる。

本文書は多くの詳細記述を含むが、これらは特許請求範囲に記載しまたは記載する可能性のある発明の範囲を限定するものと解釈すべきではない。むしろ特定実施形態の特徴に関する記載と解釈すべきである。本文書において別実施形態の文脈で記載している要素は単一実施形態における組み合わせとして実装することもできる。反対に単一実施形態の文脈で記載している様々な要素は、複数実施形態において個別に実装し、または適当なサブコンビネーションにおいて実装することもできる。上記要素は特定の組み合わせで動作しさらにそのように特許請求している場合もあるが、特許請求範囲の組み合わせにおける１以上の要素をその組み合わせから除去できる場合もある。また特許請求範囲の組み合わせは、サブコンビネーションまたはサブコンビネーションの変形とすることができる場合もある。同様に、図面の動作は特定の順序で記載しているが、これはその動作が図示する特定の順序で実施されなければならないものと解釈すべきではなく、また所望の結果を得るため全ての動作を実施しなければならないものと解釈すべきではない。

いくつかの例と実装のみを開示した。開示した内容に基づき、説明した例および実装の変形、修正、拡張、およびその他実装をなすことができる。

Claims (12)

1. 機械対機械（Ｍ２Ｍ）サービスを提供するシステムであって、
   標準アプリケーションプログラミングインターフェース（ＡＰＩ）の第１セットを介してトランスポートネットワークサービスを提供するように構成された第１レイヤ、
   前記標準ＡＰＩの前記第１セットを介して前記第１レイヤと接続された第２レイヤであって、複数のＭ２Ｍアプリケーションに対して共通タスクと特別タスクを含む複数のタスクについてのサービス機能を提供することにより、前記複数のＭ２Ｍアプリケーションのうち第１Ｍ２Ｍアプリケーションと第２Ｍ２Ｍアプリケーションとの間のデータフローを実現するように構成された、第２レイヤ、
   を有し、
   前記第２レイヤは、前記標準ＡＰＩの第１セットとは異なる標準Ｍ２Ｍ ＡＰＩの第２セットを介して、前記複数のタスクについてのサービス機能を提供するように構成されていることにより、前記第１Ｍ２Ｍアプリケーションと前記第２Ｍ２Ｍアプリケーションが、（１）標準ＡＰＩの前記第１セットを直接的に経由して、前記第１レイヤが提供する前記トランスポートネットワークサービスを用いることができるようにするとともに、（２）標準Ｍ２Ｍ ＡＰＩの前記第２セットを間接的に経由して、前記トランスポートネットワークサービスと通信できるようにする
   ことを特徴とするシステム。
2. 前記第１レイヤと前記第２レイヤはそれぞれ、異なるビジネスエンティティを表している
   ことを特徴とする請求項１記載のシステム。
3. 標準ＡＰＩの前記第１セットと前記標準Ｍ２Ｍ ＡＰＩの第２セットは、複数のビジネスエンティティ間で標準化されている
   ことを特徴とする請求項２記載のシステム。
4. 前記第１レイヤは、前記複数のＭ２Ｍアプリケーションと通信してユーザデータトラフィックを送信するように構成されている
   ことを特徴とする請求項１記載のシステム。
5. 前記共通タスクは、アプリケーション固有データを取り扱わない機能を含む
   ことを特徴とする請求項１記載のシステム。
6. 前記特別タスクは、アプリケーション固有データを取り扱う機能を含む
   ことを特徴とする請求項１記載のシステム。
7. 機械対機械（Ｍ２Ｍ）通信の方法であって、
   第１Ｍ２Ｍアプリケーションをホストするように構成された第１Ｍ２Ｍデバイスから、標準Ｍ２Ｍ アプリケーションプログラミングインターフェース（ＡＰＩ）の第２セットを介して、共通タスクと特別タスクを含む複数のタスクについてのサービス機能を照会するリクエストを送信するステップであって、前記複数のタスクについてのサービス機能はＭ２Ｍシステムの第２レイヤが提供する、ステップ、
   前記第１Ｍ２Ｍデバイスにおいて、前記サービス機能についての情報を受信するステップ、
   前記サービス機能についての情報を用いて、第２Ｍ２Ｍアプリケーションをホストするように構成された第２Ｍ２Ｍデバイスと通信するステップであって、前記通信は、（１）標準Ｍ２Ｍ ＡＰＩの前記第２セットを介して前記第２レイヤを間接的に経由して、および（２）前記Ｍ２Ｍシステムの第１レイヤが提供する標準ＡＰＩの第１セットを直接的に経由して、前記Ｍ２Ｍシステムの前記第１レイヤが提供するトランスポートネットワークサービスを用いるステップを含み、標準Ｍ２Ｍ ＡＰＩの前記第２セットは標準ＡＰＩの前記第１セットとは異なる、ステップ、
   を有することを特徴とする方法。
8. 前記第１レイヤと前記第２レイヤはそれぞれ、異なるビジネスエンティティを表している
   ことを特徴とする請求項７記載の方法。
9. 標準Ｍ２Ｍ ＡＰＩの前記第２セットと標準ＡＰＩの前記第１セットは、複数のビジネスエンティティ間で標準化されている
   ことを特徴とする請求項８記載の方法。
10. 前記トランスポートネットワークサービスを用いるステップは、ユーザデータトラフィックを送信するステップを含む
    ことを特徴とする請求項７記載の方法。
11. 前記共通タスクは、アプリケーション固有データを取り扱わない機能を含む
    ことを特徴とする請求項７記載の方法。
12. 前記特別タスクは、アプリケーション固有データを取り扱う機能を含む
    ことを特徴とする請求項７記載の方法。

Images