図面 (/)

技術 機械対機械サービスレイヤ間の通信および送信ネットワーク

出願人 ゼットティーイー(ユーエスエー)インコーポレーテッド
発明者 バッラ,ラジェッシュ
出願日 2017年7月27日 (4年1ヶ月経過) 出願番号 2017-145039
公開日 2018年1月25日 (3年7ヶ月経過) 公開番号 2018-014720
状態 特許登録済
技術分野 計算機・データ通信 電話通信サービス 移動無線通信システム
主要キーワード 垂直統合 プロファイルセット 任意形態 共通タスク 規格開発 スリープモード動作 ロジックフロー 有線通信インターフェース
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年1月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (11)

課題

M2Mデバイス間のユビキタス通信を促進する技術を提供する。

解決手段

機械対機械(M2M)通信を促進する技術は、1以上の規定機械対機械(M2M)アプリケーションプログラミングインターフェースAPI)プロファイル実装したM2Mシステムを提供するステップ、前記M2Mシステムに対してネットワークインターフェースを提供するステップ、前記ネットワークインターフェースを介してプロファイルクエリを受信するステップ及び前記1以上の規定M2M APIプロファイルに関する情報を応答するステップを有する。

概要

背景

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

概要

M2Mデバイス間のユビキタス通信を促進する技術を提供する。機械対機械(M2M)通信を促進する技術は、1以上の規定機械対機械(M2M)アプリケーションプログラミングインターフェースAPI)プロファイルを実装したM2Mシステムを提供するステップ、前記M2Mシステムに対してネットワークインターフェースを提供するステップ、前記ネットワークインターフェースを介してプロファイルクエリを受信するステップ及び前記1以上の規定M2M APIプロファイルに関する情報を応答するステップを有する。

目的

1側面において、M2M通信を促進する方法、システム、および装置は、1以上の規定機械対機械(M2M)アプリケーションプログラミングインターフェース(API)プロファイルを実装したM2Mシステムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

機械対機械(M2Mサービスを提供するシステムであって、標準M2MアプリケーションプログラミングインターフェースAPI)の第1セットを介してネットワークおよび通信サービスを提供するように構成された第1サービスレイヤ、前記標準M2MAPIの前記第1セットを介して前記第1サービスレイヤと接続された第2サービスレイヤであって、複数のM2Mアプリケーションに対して共通タスクと特別タスクを含む複数のタスクについてのサービス機能を提供することにより、前記第2サービスレイヤが提供する前記ネットワークおよび通信サービスを用いて、前記複数のM2Mアプリケーションのうち第1M2Mアプリケーションと第2M2Mアプリケーションとの間のデータフローを実現するように構成された、第2サービスレイヤ、を有することを特徴とするシステム。

請求項2

前記第2サービスレイヤは、標準M2MAPIの第2セットを介して、前記複数のタスクについてのサービス機能を提供するように構成されていることを特徴とする請求項1記載のシステム。

請求項3

前記第1サービスレイヤと前記第2サービスレイヤはそれぞれ、異なるビジネスエンティティを表していることを特徴とする請求項2記載のシステム。

請求項4

標準M2MAPIの前記第1セットと前記第2セットは、複数のビジネスエンティティ間で標準化されていることを特徴とする請求項3記載のシステム。

請求項5

前記第1サービスレイヤは、前記複数のM2Mアプリケーションと通信してユーザデータトラフィックを送信するように構成されていることを特徴とする請求項1記載のシステム。

請求項6

前記共通タスクは、アプリケーション固有データを取り扱わない機能を含むことを特徴とする請求項1記載のシステム。

請求項7

前記特別タスクは、アプリケーション固有データを取り扱う機能を含むことを特徴とする請求項1記載のシステム。

請求項8

機械対機械(M2M)通信の方法であって、第1M2Mアプリケーションをホストするように構成された第1M2Mデバイスから、標準M2Mアプリケーションプログラミングインターフェース(API)の第1セットを介して、共通タスクと特別タスクを含む複数のタスクについてのサービス機能を照会するリクエストを送信するステップであって、前記複数のタスクについてのサービス機能はM2Mシステムの第1サービスレイヤが提供する、ステップ、前記第1M2Mデバイスにおいて、前記サービス機能についての情報を受信するステップ、前記サービス機能についての情報を用いて、第2M2Mアプリケーションをホストするように構成された第2M2Mデバイスと通信するステップであって、前記通信は、前記M2Mシステムの第2サービスレイヤが提供するネットワークおよび通信サービスを用いるステップを含む、ステップ、を有することを特徴とする方法。

請求項9

前記ネットワークおよび通信サービスを用いるステップは、前記第2サービスレイヤが提供する標準M2MAPIの第2セットを介して実施されることを特徴とする請求項8記載の方法。

請求項10

前記第1サービスレイヤと前記第2サービスレイヤはそれぞれ、異なるビジネスエンティティを表していることを特徴とする請求項9記載の方法。

請求項11

標準M2MAPIの前記第1セットと前記第2セットは、複数のビジネスエンティティ間で標準化されていることを特徴とする請求項10記載の方法。

請求項12

前記ネットワークおよび通信サービスを用いるステップは、ユーザデータトラフィックを送信するステップを含むことを特徴とする請求項8記載の方法。

請求項13

前記共通タスクは、アプリケーション固有データを取り扱わない機能を含むことを特徴とする請求項8記載の方法。

請求項14

前記特別タスクは、アプリケーション固有データを取り扱う機能を含むことを特徴とする請求項8記載の方法。

技術分野

0001

関連出願に対する相互参照
本願は、2013年1月24日に出願された米国仮出願第61/756,397号、および2013年2月14日に出願された米国仮出願第61/764,953号の優先権を主張する。これら特許出願の全体は参照により本願に組み込まれる。

0002

本願は、機械対機械(M2M通信に関する。

背景技術

0003

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

課題を解決するための手段

0004

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

0005

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

0006

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

図面の簡単な説明

0008

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

0009

e2eM2Mサービス層構造の例を示す。

0010

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

0011

M2MSDOサポートするインターフェースとAPIの例を示す。

0012

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

0013

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

実施例

0014

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

0015

oneM2M、ETSI TC M2M、TIA TR−50などの組織(M2M SDO)が開発するサービスレイヤ規格は、様々な市場中心(垂直)組織がM2Mソリューションを効率的に配置することをサポートする必要がある。サービスレイヤにフォーカスすることにより、このような組織は送信ネットワークから独立したエンドトゥエンドサービスの見方を取っている。それでもこれら組織は、異なるタイプの送信ネットワークとのインターフェースを保つためサービスレイヤ規格が効率的に使われるようにしなければならない。この送信ネットワークは、3GPP、3GPP2、IEEE、IETF、BBFなどが規定する無線および有線ネットワークを含むが、これに限られない。

0016

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

0017

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

0018

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

0019

図1は、無線通信ネットワークまたはシステムの例を示す。この無線通信ネットワークは、1以上のベースステーションBS)105、107および1以上の無線デバイス110を有する。ベースステーション105と107は、1以上の無線デバイス110に対してフォワードリンクFL)上で信号(ダウンリンク(DL)信号として知られている)を送信することができる。無線デバイス110は、1以上のベースステーション105と107に対してリバースリンク(RL)上で信号(アップリンク(UL)信号として知られている)を送信することができる。無線通信システムは、1以上のネットワーク125を有し、1以上のベースステーション105と107を制御する。1以上のベースステーションは、無線アクセスネットワークを形成する。ベースステーションは、単独もしくは1以上のベースステーションとの組み合わせで無線デバイスに対して無線アクセスを提供するという性質上、アクセスポイント(AP)、アクセスネットワーク(AN)、またはeNodeBと呼ばれる場合がある。本技術およびシステムを実装することができる無線通信システムの例としては、CDMA2000 1xなどのCode Division Multiple Access(CDMA)、High Rate Packet Data(HRPD)、Long−Term Evolution(LTE)、Universal Terrestrial Radio Access Network(UTRAN)、Worldwide Interoperability for Microwave Access(WiMAX)、などに基づく無線通信システムが挙げられる。

0020

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

0021

実装例において無線ステーション205は、CDMAまたはGSM(登録商標)ベースのインターフェースに基づき相互通信する。実装例において無線ステーション205は、orthogonal frequency−division multiplexing(OFDM)インターフェースに基づき相互通信する。これはOrthogonal Frequency−Division Multiple Access(OFDMA)インターフェースを含む。実装例において無線ステーション205は、1以上の無線技術を用いて通信することができる。この無線技術は例えば、CDMA2000 1x、HRPD、WiMAX、GSM(登録商標)、LTE、Universal Mobile Telecommunications System(UMTS)である。

0022

実装例において、無線ステーション205はさらに、802.11(a/b/g/n)インターフェースなどのローカルエリアネットワーク接続を備えるように構成することができる。このようなインターフェースを利用できることにより、ローカルエリア接続を介して無線ステーション205をインターネットと通信可能に接続することができる。例えばユーザは、ケーブルモデムネットワークやDSLネットワークなどの固定ブロードバンドネットワークを経由して無線ローカルエリアネットワーク接続(例えば家庭Wi−Fiアクセス)を介してサービスに接続することにより、自身のユーザ機器(UE)を介してサービスにアクセスすることができる。

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

M2MSDOの役割

0030

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

0031

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

0032

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

0033

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

0034

コンバージェンスレイヤ

0035

トランスポートネットワーク固有コンバージェンスレイヤの定義は、インターフェースセットおよび/またはAPIセットの規定を含む。トランスポートネットワーク固有コンバージェンスレイヤは、M2MSDOと、関連する送信ネットワーク技術を指定する組織との共同作業を通じて定義される。例えば3GPPと3GPP2は、M2Mサービスプラットフォームと3GPPおよび3GPP2それぞれとの間のインターフェースとして、TspとM2Mspを指定している。これらインターフェース(TspとM2Msp)は、M2M SDOと3GPP/3GPP2との間の共同作業を通じて定義され、本文書の対象ではない。本文書の対象は、M2Mサービスプラットフォーム(M2Mサービスレイヤとして抽象化されている)と基盤トランスポートネットワークとの間で用いることができるAPIセットを定義するためM2M SODが用いるアプローチである。

0037

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

0038

1例として、OMA(Open Mobile Alliance)ネットワークAPIにより、送信ネットワークはオープンかつプログラム可能な態様で、自ネットワークの機能とリソースを抽象化して提示することができる。これにより、(開発プラットフォームから独立して、さらにOMA APIをサポートする事業者およびサービスから独立して)アプリケーションやコンテンツを生成するため必要な開発コストおよび時間を削減することができる。

0039

同様に、GSMA OneAPIプロジェクトはOMAと共同作業して、Parlay X Web APIを簡易化し、RESTfulバインディングとより簡易なJSON/XMLレスポンスの選択を提供することにより同APIを改良している。その結果得られたGSMA OneAPIプロファイルは、アプリケーション開発者に対してWebアプリケーション経由でモバイルネットワーク機能およびリソースについての情報を提示するAPIセットである。アプリケーション開発者は例えば、単一のWebサービスリクエスト発行して、モバイルネットワークにおけるデバイスのロケーションを取得し、音声コール発信することができる。このようなアプリケーションは、ネットワークタイプやネットワーク技術をまたがって移植することができる。アプリケーション開発を簡易化することに加えて、OneAPIプロファイルの利点としては以下が挙げられる:

0040

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

0041

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

0042

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

0043

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

0044

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

0045

M2MSDOは、GSMA OneAPI Initiativeによる成果にならって、OneAPIプロファイルを評価することが想定される。GSMA OneAPIプロファイルは、M2Mサービスが必要とする送信ネットワーク機能を抽象化するM2M固有APIプロファイルを定義することによって、強化することができる。下記セクションは、GSMA OneAPIプロファイルのスナップショットステータスを提示する。OneAPIプロファイルの利用可能セットによって提供される機能と、M2M SDO固有サービスレイヤの包括的実装が必要とする機能との間のギャップ分析することにより、フォーカスすることが必要な領域が分かる。特定したフォーカス領域とギャップは、M2M SDO単独、および/またはパートナーや業界組織(例えばOMA、BBFなど)との共同作業によって対処され、より完全なM2M APIプロファイルスイートが開発される。

0046

補足−GSMA OneAPIプロファイルのステータス

0047

GSMA OneAPIプロジェクトは、OMAと共同作業して、Parlay X Web APIを簡易化し、対応するRESTfulバインディングを提供することにより同APIを改良している。最初のOneAPIバージョン1は、支払、ロケーション、メッセージングなどのネットワーク機能にフォーカスしている。GSMA OneAPIバージョン2は、デバイス機能判定、ベアラー識別、音声コールサービスの機能を追加した。バージョン3は、より進化した機能を目指している。例えばQoS、映像コール、識別、フェムトセルサポートなどである。

0048

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

0049

支払

0050

ユーザに課金する

0051

ユーザに返金する

0052

後の課金のため積み立て

0053

積み立てを増やす

0054

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

0055

積み立てを解消する

0056

SMS:

0057

SMSを送信する

0058

SMS配信ステータスを照会する

0059

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

0060

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

0061

SMSを受信する

0062

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

0063

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

0064

MMS

0065

MMSを送信する

0066

MMS配信ステータスを照会する

0067

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

0068

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

0069

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

0070

フルMMSメッセージ(コンテンツ)を受信する

0071

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

0072

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

0073

ロケーション:

0074

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

0075

音声コール制御:

0076

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

0077

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

0078

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

0079

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

0080

コールを終了する

0081

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

0082

自身の通知条件を見る

0083

通知の受信を停止する

0084

音声メッセージ再生する

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0092

端末接続タイプ(3G、GPRSなど)をリクエストする

0093

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

0094

デバイス機能:

0095

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

0096

OMA文書“OMA−TS−REST_NetAPI_OneAPIProfile−V3_0−20120327−C”は、RESTfulネットワークAPIのOneAPIプロファイルバージョン3.0の候補である。先に述べたように、GSMA OneAPIプロジェクトは、3rdパーティーアプリケーションの配置と動作問題に取り組んでおり、Parlay XおよびOMA RESTfulネットワークAPIのサブセットを用いてRESTfulネットワークAPIのOneAPIプロファイルを抽象化している。

0097

RESTfulネットワークAPIのOneAPIプロファイルのバージョン3.0は、以下のAPIのサブセットを定義している。

0098

RESTful NetworkAPI for Short Messaging V 1.0

0099

RESTful NetworkAPI for Messaging V 1.0

0100

RESTful NetworkAPI for Terminal Location V 1.0

0101

RESTful NetworkAPI for Payment V 1.0

0102

RESTful NetworkAPI for Device Capabilities V 1.0

0103

RESTful NetworkAPI for Terminal Status V 1.0

0104

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

0105

図6は、機械対機械(M2M)通信を促進するプロセス300のフローチャートである。

0106

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

0107

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

0108

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

0109

ステップ308において、M2Mシステムは、1以上の規定のM2MAPIプロファイルの実装についての情報を応答する。

0110

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

0111

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

0112

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

0113

図7は、機械対機械(M2M)通信を促進する装置400のブロック図である。モジュール402は、1以上の規定機械対機械(M2M)アプリケーションプログラミングインターフェース(API)プロファイルを実装したM2Mシステムを提供する。モジュール404は、M2Mシステムのネットワークインターフェースを提供する。モジュール406は、ネットワークインターフェース上でプロファイルクエリを受信する。モジュール406は、1以上の規定M2M APIプロファイルの実装についての情報を応答する。

0114

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

0115

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

0116

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

0117

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

0118

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

0119

本文書が記載するプロセスおよびロジックフローは、入力データに対して動作し出力を生成する1以上のコンピュータプログラムを実行して機能を実施する1以上のプログラム可能プロセッサにより実施することができる。プロセスとロジックフローは、例えばFPGA(field programmable gate array)やASIC(application specific integrated circuit)などの特定用途論理回路によって実施することもできる。装置はこれら回路として実装することもできる。

0120

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

0121

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

0122

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ