(57)【特許請求の範囲】
【請求項１】
アプリケーションサービスレイヤ（ＡＳＬ）でサービスをサポートする方法であって、
Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）サービス能力レイヤ（ＳＣＬ）リソース構造内のリソースを使用してエンティティから要求のバッチを受信するステップであって、前記要求は、別のＳＣＬにターゲットされている、ステップと、
前記ＲＥＳＴｆｕｌ  ＳＣＬリソース構造に属性を作成するステップであって、前記属性は前記要求を表している情報を含み、および、前記リソースもまた、前記要求を処理するための制限時間を指定する属性を含む、ステップと、
前記要求を処理するステップであって、前記処理するステップは、前記別のＳＣＬに前記要求を送るステップを含む、ステップと、
要求の前記バッチを受信することに応答して、前記エンティティに応答を送るステップと
を備えたことを特徴とする方法。
【請求項２】
前記応答を前記送るステップは、
要求の前記バッチにおいて示された前記要求の各々への別個の応答を前記エンティティに送るステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求の少なくとも２つに対して、前記要求の少なくとも２つを前記処理するステップにおいて実行される動作は同一の動作であり、および、前記動作は前記要求の前記少なくとも２つに対して１回指定されるのみであることを特徴とする請求項１に記載の方法。
【請求項４】
要求の前記バッチにおいて示された前記要求の少なくとも２つに対して、前記要求の前記少なくとも２つを前記処理するステップにおいて実行されることになる２つの異なる動作は、前記要求の前記少なくとも２つの一部として示されることを特徴とする請求項１に記載の方法。
【請求項５】
前記応答を前記送るステップは、
前記要求の各々を前記処理するステップから受信された応答をバッチ化し、応答のバッチを生成するステップと、
前記エンティティに応答の前記バッチを送るステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
要求の前記バッチの一部である属性、および、要求の前記バッチがアドレス指定されたアドレスに関連付けられた属性の少なくとも１つに基づいて、要求の前記バッチに関連付けられた属性を決定するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項７】
前記ＡＳＬは、サービス能力レイヤ（ＳＣＬ）であることを特徴とする請求項１に記載の方法。
【請求項８】
それぞれ前記要求の各々の動作は、作成、検索、更新、および削除の少なくとも１つであることを特徴とする請求項１に記載の方法。
【請求項９】
前記エンティティは、アプリケーション、マシンツーマシンアプリケーション、マシンツーマシンデバイス、および別のＡＳＬのうちの１つであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記要求を前記処理するステップは、前記別のＳＣＬから、複数の要求への応答を受信するステップをさらに含み、
および前記応答を送るステップは、前記エンティティに前記受信された応答を送るステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１１】
サービスをサポートするコンピュータシステムであって、
Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）サービス能力レイヤ（ＳＣＬ）リソース構造を有するＲＥＳＴｆｕｌ  ＳＣＬを備え、前記ＲＥＳＴｆｕｌ  ＳＣＬは、
前記ＲＥＳＴｆｕｌ  ＳＣＬ内のリソースを使用してエンティティから要求のバッチを受信し、前記要求は、別のＳＣＬにターゲットされており、
前記ＲＥＳＴｆｕｌ  ＳＣＬリソース構造における属性を作成し、前記属性は前記要求を表している情報を含み、および、前記リソースもまた、前記要求を処理するための制限時間を指定する属性を含み、
前記要求を処理し、前記処理することは、前記別のＳＣＬに前記要求を送ることを含み、
要求の前記バッチを受信することに応答して、前記エンティティに応答を送る
ように構成されたことを特徴とするコンピュータシステム。
【請求項１２】
前記ＲＥＳＴｆｕｌ  ＳＣＬは、要求の前記バッチにおいて示された前記要求の各々への個別の応答を前記エンティティに送るようにさらに構成されたことを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１３】
前記要求の少なくとも２つに対して、前記要求の少なくとも２つを前記処理することにおいて実行される動作は同一の動作であり、および、前記動作は前記要求の前記少なくとも２つに対して１回指定されるのみであることを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１４】
前記ＲＥＳＴｆｕｌ  ＳＣＬは、前記要求を前記処理することから受信された応答をバッチ化し、および、前記エンティティに応答のバッチを送るようにさらに構成されたことを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１５】
前記要求の少なくとも１つの動作は、作成、検索、更新、および削除のうちの１つであることを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１６】
前記エンティティは、アプリケーション、マシンツーマシンアプリケーション、マシンツーマシンデバイス、および別のＲＥＳＴｆｕｌ  ＳＣＬのうちの１つであることを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１７】
前記ＲＥＳＴｆｕｌ  ＳＣＬは、前記別のＳＣＬから前記要求への応答を受信することにより前記要求を処理するようにさらに構成され、前記ＲＥＳＴｆｕｌ  ＳＣＬは、前記エンティティに前記受信された応答を送るようにさらに構成されたことを特徴とする請求項１１に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＲＥＳＴｆｕｌバッチサービスのための方法および装置に関する。
【背景技術】
【０００２】
マシンツーマシン（Ｍ２Ｍ）通信は、２つのマシン間の通信を指す。ますます多くのデータが検知器(sensor)から自動的に収集されることによって、および、マシンがますます知的になることによって、Ｍ２Ｍはより重要になりつつある。
【０００３】
マシンは、互いに無線の、または配線されるシステムによって通信し得る。しばしば、検知器またはメータなどのマシンは、温度または在庫レベルなどのデータを生成する事象を捕捉する。データは、ネットワークによってアプリケーションに通信され得る。
【０００４】
しばしば、これらのＭ２Ｍ通信は、要求されるサービスを遂行するために多くのメッセージを要する。
【発明の概要】
【０００５】
アプリケーションサービスレイヤ（ＡＳＬ：application service layer）でサービスをサポートする装置、コンピュータ可読メディア、および、方法が開示される。方法は、バッチ化される要求をエンティティから受信することに対して、バッチ化される要求を処理することと、バッチ化される要求への応答をエンティティに送ることとにより応答するステップを含み得る。方法は、バッチ化される要求で示される各々の要求への個別の応答をエンティティに送るステップ、または、バッチ化される応答を送るステップを含み得る。２つ以上のバッチ化される要求は、同じ動作を有し得るものであり、動作は、２つ以上のバッチ化される要求に対して１回指定されるのみであり得る。動作は、バッチ化される要求の名、または、バッチ化される要求の属性に基づいて決定され得る。要求は、バッチ化される要求の名、バッチ化される要求に関連付けられる属性、または、バッチ化される要求がアドレスされるアドレスに基づくバッチ要求であるように決定され得る。
【０００６】
サービスをサポートするためのコンピュータシステムが開示される。コンピュータシステムは、エンティティから受信されるバッチ化される要求を処理するように構成され、バッチ化される要求への応答をエンティティに送るように構成されるアプリケーションサービスレイヤ（ＡＳＬ）を含み得る。
【０００７】
ＡＳＬは、バッチ化される要求で示される各々の要求への個別の応答をエンティティに送るように構成され得る。ＡＳＬは、バッチ化される要求で示される各々の要求を処理するように構成され得る。
【０００８】
一部の実施形態では、バッチ化される要求の２つ以上は、同一の動作を示すが、動作を２つ以上の要求に対して１回指定するのみであり得る。
【０００９】
一部の実施形態では、バッチ化される要求の２つ以上は、異なる動作であり得る。
【００１０】
ＡＳＬは、サービス能力レイヤ（ＳＣＬ：service capability layer）であり得る。ＳＣＬは、欧州電気通信標準化機構（ＥＴＳＩ）Ｍ２Ｍ  ＳＣＬであり得る。
【図面の簡単な説明】
【００１１】
より詳細な理解は、付随する図面と併せて例として与えられる、後に続く説明から得られ得る。
【００１２】
【図１Ａ】１または複数の開示される実施形態が実行され得る、例通信システムのシステム線図である。
【図１Ｂ】図１Ａで例示される通信システムの内部で使用され得る、例無線送受信ユニット（ＷＴＲＵ）のシステム線図である。
【図１Ｃ】実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム線図である。
【図２】サービス能力レイヤ（ＳＣＬ）であり得るアプリケーションサービスレイヤ（ＡＳＬ）を含むプロトコルスタックを例示する図である。
【図３】２つのアプリケーションが、ＳＣＬであり得る共通ＡＳＬによって互いに通信する例を例示する図である。
【図４Ａ】一部の実施形態による、Ｍ２Ｍシステム４００を例示する図である。
【図４Ｂ】一部の実施形態による、Ｍ２Ｍアーキテクチャを例示する図である。
【図５】リソース構造の例を例示する図であり、リソース構造は、ＲＥＳＴｆｕｌリソース構造であり得る。
【図６】ＨＴＴＰバッチ化される要求または応答の例を例示する図である。
【図７】サービス能力レイヤに登録し、４つのコンテナリソースを作成する、デバイスアプリケーションの方法の例を例示する図である。
【図８】サービス能力レイヤに登録し、４つのコンテナリソースを作成する、デバイスアプリケーションの方法の例を例示する図である。
【図９】一部の実施形態による、バッチ要求リソースを伴うリソース構造の例を例示する図である。
【図１０】一部の実施形態による、バッチ要求リソースを伴うリソース構造の例を例示する図である。
【図１１Ａ】バッチプリミティブに対する異なる実施形態を例示する図である。
【図１１Ｂ】バッチプリミティブに対する異なる実施形態を例示する図である。
【図１１Ｃ】バッチプリミティブに対する異なる実施形態を例示する図である。
【図１２】バッチ要求リソースに送られるバッチ要求に対するバッチ要求プリミティブハンドリングのための方法を例示する図である。
【図１３Ａ】開示される実施形態による、バッチ応答プリミティブハンドリングを例示する図である。
【図１３Ｂ】開示される実施形態による、バッチ応答プリミティブハンドリングを例示する図である。
【図１４】開示される実施形態による、バッチサービスの方法を例示する図である。
【図１５】開示される実施形態による、バッチサービスの方法を例示する図である。
【図１６】開示される実施形態による、バッチサービスの方法を例示する図である。
【図１７】開示される実施形態による、バッチサービスの方法を例示する図である。
【図１８】開示される実施形態による、バッチサービスの方法を例示する図である。
【発明を実施するための形態】
【００１３】
図１Ａは、１または複数の開示される実施形態が実行され得る、例通信システム１００の線図である。通信システム１００は、ボイス、データ、ビデオ、メッセージング、ブロードキャスト、その他などのコンテンツを多重の無線ユーザに提供する多重アクセスシステムであり得る。通信システム１００は、多重の無線ユーザが、無線帯域幅を含むシステムリソースの共有によって、そのようなコンテンツにアクセスすることを可能にし得る。例えば通信システム１００は、コード分割多重アクセス（ＣＤＭＡ）、時間分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、および類するものなどの、１または複数のチャネルアクセス方法を用い得る。
【００１４】
図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ラジオアクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話ネットワーク（ＰＳＴＮ）１０８、インターネット１１０、および、他のネットワーク１１２を含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／または、ネットワーク要素を企図するということが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境で動作および／または通信するように構成される任意のタイプのデバイスであり得る。例の方途によりＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成され得るものであり、ユーザ機器（ＵＥ）、移動局、固定された、または移動の加入者ユニット、ページャ、セルラー電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線検知器、消費者電子機器、および類するものを含み得る。
【００１５】
通信システム１００はさらには、基地局１１４ａおよび基地局１１４ｂを含み得る。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェイス接続して、コアネットワーク１０６、インターネット１１０、および／または、他のネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを容易にするように構成される、任意のタイプのデバイスであり得る。例の方途により基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノード−Ｂ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータ、および類するものであり得る。基地局１１４ａ、１１４ｂは各々、単一の要素として図示されるが、基地局１１４ａ、１１４ｂは、任意の数の相互接続される基地局および／またはネットワーク要素を含み得るということが認識されよう。
【００１６】
基地局１１４ａは、ＲＡＮ１０４の部分であり得るものであり、そのＲＡＮ１０４はさらには、基地局コントローラ（ＢＳＣ）、ラジオネットワークコントローラ（ＲＮＣ）、中継ノード、その他などの、他の基地局および／またはネットワーク要素（図示せず）を含み得る。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼称され得る特定の地理的領域の内部で無線信号を送信および／または受信するように構成され得る。セルは、セルセクタにさらに分割され得る。例えば、基地局１１４ａに関連付けられるセルは、３つのセクタに分割され得る。したがって１つの実施形態では基地局１１４ａは、３つのトランシーバを、すなわち、セルの各々のセクタに対して１つを含み得る。別の実施形態では基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を用い得るものであり、したがって、セルの各々のセクタに対して多重のトランシーバを利用し得る。
【００１７】
基地局１１４ａ、１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と、エアインターフェイス１１６によって通信し得るものであり、そのエアインターフェイス１１６は、任意の適した無線通信リンク（例えば、ラジオ周波数（ＲＦ）、マイクロウェーブ、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、その他）であり得る。エアインターフェイス１１６は、任意の適したラジオアクセス技術（ＲＡＴ）を使用して確立され得る。
【００１８】
より具体的には、上記で記載されたように通信システム１００は、多重アクセスシステムであり得るものであり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ、および類するものなどの、１または複数のチャネルアクセススキームを用い得る。例えば、ＲＡＮ１０４内の基地局１１４ａ、および、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェイス１１６を確立し得る、ユニバーサル移動電気通信システム（ＵＭＴＳ）地上ラジオアクセス（ＵＴＲＡ）などのラジオ技術を実行し得る。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＥｖｏｌｖｅｄ  ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含み得る。
【００１９】
別の実施形態では、基地局１１４ａ、および、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−アドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェイス１１６を確立し得る、Ｅｖｏｌｖｅｄ  ＵＭＴＳ地上ラジオアクセス（Ｅ−ＵＴＲＡ）などのラジオ技術を実行し得る。
【００２０】
他の実施形態では、基地局１１４ａ、および、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ：Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ：Enhanced Data rates for GSM Evolution）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）、および類するものなどのラジオ技術を実行し得る。
【００２１】
図１Ａでの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、または、アクセスポイントであり得るものであり、仕事の場所、ホーム、乗物、構内、および類するものなどの局限されたエリアで無線接続性を容易にするために、任意の適したＲＡＴを利用し得る。１つの実施形態では、基地局１１４ｂ、および、ＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などのラジオ技術を実行して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立し得る。別の実施形態では、基地局１１４ｂ、および、ＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などのラジオ技術を実行して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立し得る。さらに別の実施形態では、基地局１１４ｂ、および、ＷＴＲＵ１０２ｃ、１０２ｄは、セルラーに基づくＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、その他）を利用して、ピコセルまたはフェムトセルを確立し得る。図１Ａに示されるように基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって基地局１１４ｂは、コアネットワーク１０６によってインターネット１１０にアクセスすることを要され得ない。
【００２２】
ＲＡＮ１０４は、コアネットワーク１０６との通信の状態にあり得るものであり、そのコアネットワーク１０６は、ボイス、データ、アプリケーション、および／または、ボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成される、任意のタイプのネットワークであり得る。例えばコアネットワーク１０６は、呼制御、ビリングサービス、移動位置に基づくサービス、プリペイド呼、インターネット接続性、ビデオ分配、その他を提供し得るものであり、および／または、ユーザ認証などの高レベルセキュリティ機能を遂行し得る。図１Ａには示されないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴを、または異なるＲＡＴを用いる他のＲＡＮとの、直接または間接の通信の状態にあり得るということが認識されよう。例えば、Ｅ−ＵＴＲＡラジオ技術を利用している場合があるＲＡＮ１０４に接続されていることへの追加で、コアネットワーク１０６はさらには、ＧＳＭラジオ技術を用いる別のＲＡＮ（図示せず）との通信の状態にあり得る。
【００２３】
コアネットワーク１０６はさらには、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または、他のネットワーク１１２にアクセスするためのゲートウェイとしてサービングし得る。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含み得る。インターネット１１０は、相互接続されるコンピュータネットワークおよびデバイスのグローバルシステムを含み得るものであり、それらのコンピュータネットワークおよびデバイスは、送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および、インターネットプロトコル（ＩＰ）などの、ＴＣＰ／ＩＰインターネットプロトコルスイートの形での共通通信プロトコルを使用するものである。ネットワーク１１２は、他のサービスプロバイダにより所有される、および／または動作させられる、配線される、または無線の通信ネットワークを含み得る。例えばネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴを、または異なるＲＡＴを用い得る、１または複数のＲＡＮに接続される別のコアネットワークを含み得る。
【００２４】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、マルチモード能力を含み得るものであり、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクによって異なる無線ネットワークと通信するための多重のトランシーバを含み得る。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーに基づくラジオ技術を用い得る基地局１１４ａと、および、ＩＥＥＥ８０２ラジオ技術を用い得る基地局１１４ｂと通信するように構成され得る。
【００２５】
図１Ｂは、例ＷＴＲＵ１０２のシステム線図である。図１Ｂに示されるようにＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電力源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、および、他の周辺装置１３８を含み得る。ＷＴＲＵ１０２は、実施形態と矛盾しないままで、前述の要素の任意の副組み合わせを含み得るということが認識されよう。
【００２６】
プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアとの関連付けの状態にある１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および類するものであり得る。プロセッサ１１８は、信号コード化、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を遂行し得る。プロセッサ１１８はトランシーバ１２０に結合され得るものであり、そのトランシーバ１２０は送受信要素１２２に結合され得る。図１Ｂはプロセッサ１１８およびトランシーバ１２０を個別の構成要素として図示するが、プロセッサ１１８およびトランシーバ１２０は、電子パッケージまたはチップ内に一体に集積され得るということが認識されよう。
【００２７】
送受信要素１２２は、エアインターフェイス１１６によって、信号を基地局（例えば、基地局１１４ａ）に送信する、または、信号をその基地局から受信するように構成され得る。例えば１つの実施形態では送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されるアンテナであり得る。別の実施形態では送受信要素１２２は、例えばＩＲ信号、ＵＶ信号、または、可視光信号を、送信および／または受信するように構成される放射器／検出器であり得る。さらに別の実施形態では送受信要素１２２は、ＲＦ信号および光信号の両方を、送信および受信するように構成され得る。送受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成され得るということが認識されよう。
【００２８】
追加で、送受信要素１２２は、単一の要素として図１Ｂで図示されるが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含み得る。より具体的にはＷＴＲＵ１０２は、ＭＩＭＯ技術を用い得る。したがって１つの実施形態ではＷＴＲＵ１０２は、エアインターフェイス１１６によって無線信号を送信および受信するための、２つ以上の送受信要素１２２（例えば、多重のアンテナ）を含み得る。
【００２９】
トランシーバ１２０は、送受信要素１２２により送信されることになる信号を変調するように、および、送受信要素１２２により受信される信号を復調するように構成され得る。上記で記載されたようにＷＴＲＵ１０２は、マルチモード能力を有し得る。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの多重のＲＡＴによって通信することを可能にするための多重のトランシーバを含み得る。
【００３０】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、または、有機光放射ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得るものであり、ユーザ入力データを、それらのスピーカ／マイクロホン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８から受信し得る。プロセッサ１１８はさらには、ユーザデータを、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８に出力し得る。追加で、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２などの任意のタイプの適したメモリからの情報にアクセスし、データをそのメモリに記憶し得る。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または、任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および類するものを含み得る。他の実施形態ではプロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されないメモリからの情報にアクセスし、データをそのメモリに記憶し得る。
【００３１】
プロセッサ１１８は、電力を電力源１３４から受信し得るものであり、ＷＴＲＵ１０２内の他の構成要素に対する電力を分配および／または制御するように構成され得る。電力源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適したデバイスであり得る。例えば電力源１３４は、１または複数のドライセルバッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）、その他）、ソーラーセル、燃料セル、および類するものを含み得る。
【００３２】
プロセッサ１１８はさらには、ＧＰＳチップセット１３６に結合され得るものであり、そのＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報への追加で、またはその情報の代わりに、ＷＴＲＵ１０２は、位置情報をエアインターフェイス１１６によって基地局（例えば、基地局１１４ａ、１１４ｂ）から受信し、および／または、その位置を、２つ以上の付近の基地局から受信されている信号のタイミングに基づいて決定し得る。ＷＴＲＵ１０２は、実施形態と矛盾しないままで、任意の適した位置決定方法の方途により位置情報を獲得し得るということが認識されよう。
【００３３】
プロセッサ１１８は、他の周辺装置１３８にさらに結合され得るものであり、それらの他の周辺装置１３８は、追加的な特徴、機能性、および／または、配線される、もしくは無線の接続性を提供する、１または複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば周辺装置１３８は、加速度メータ、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および類するものを含み得る。
【００３４】
図１Ｃは、実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム線図である。上記で記載されたようにＲＡＮ１０４は、Ｅ−ＵＴＲＡラジオ技術を用いて、エアインターフェイス１１６によってＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０４はさらには、コアネットワーク１０６との通信の状態にあり得る。
【００３５】
ＲＡＮ１０４は、ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃを含み得るが、ＲＡＮ１０４は、実施形態と矛盾しないままで、任意の数のｅノード−Ｂを含み得るということが認識されよう。ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは各々、エアインターフェイス１１６によってＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１または複数のトランシーバを含み得る。１つの実施形態ではｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実行し得る。したがってｅノード−Ｂ１４０ａは、例えば、多重のアンテナを使用して、無線信号をＷＴＲＵ１０２ａに送信し、無線信号をＷＴＲＵ１０２ａから受信し得る。
【００３６】
ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃの各々は、特定のセル（図示せず）に関連付けられ得るものであり、ラジオリソース管理判断、ハンドオーバ判断、アップリンクおよび／またはダウンリンクでのユーザのスケジューリング、ならびに類するものをハンドリングするように構成され得る。図１Ｃに示されるようにｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェイスによって互いに通信し得る。
【００３７】
図１Ｃに示されるコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、および、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含み得る。前述の要素の各々はコアネットワーク１０６の部分として図示されるが、これらの要素の任意のものが、コアネットワークオペレータ以外のエンティティにより所有され得る、および／または動作させられ得るということが認識されよう。
【００３８】
ＭＭＥ１４２は、Ｓ１インターフェイスによってＲＡＮ１０４内のｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃの各々に接続され得るものであり、制御ノードとしてサービングし得る。例えばＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、特定のサービングゲートウェイをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチの間に選択すること、および類することに対して責任を負い得る。ＭＭＥ１４２はさらには、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他のラジオ技術を用いる他のＲＡＮ（図示せず）との間で交換するための、制御プレーン機能を提供し得る。
【００３９】
サービングゲートウェイ１４４は、Ｓ１インターフェイスによってＲＡＮ１０４内のｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃの各々に接続され得る。サービングゲートウェイ１４４は一般的に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からのユーザデータパケットをルーティングおよびフォワーディングし得る。サービングゲートウェイ１４４はさらには、ｅノード−Ｂ間ハンドオーバの間にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに対して利用可能であるときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶すること、ならびに類することなどの、他の機能を遂行し得る。
【００４０】
サービングゲートウェイ１４４はさらには、ＰＤＮゲートウェイ１４６に接続され得るものであり、そのＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰが可能にされたデバイスとの間の通信を容易にし得る。無線ローカルエリアネットワーク（ＷＬＡＮ）１５５のアクセスルータ（ＡＲ）１５０は、インターネット１１０との通信の状態にあり得る。ＡＲ１５０は、ＡＰ１６０ａ、１６０ｂ、および、１６０ｃ間の通信を容易にし得る。ＡＰ１６０ａ、１６０ｂ、および、１６０ｃは、ＳＴＡ１７０ａ、１７０ｂ、および、１７０ｃとの通信の状態にあり得る。ＳＴＡ１７０は、ＷＴＲＵ１０２などの無線デバイスであり得る。
【００４１】
コアネットワーク１０６は、他のネットワークとの通信を容易にし得る。例えばコアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従前の陸線通信デバイスとの間の通信を容易にし得る。例えばコアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェイスとしてサービングする、ＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含み得る、または、そのＩＰゲートウェイと通信し得る。追加で、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のネットワーク１１２へのアクセスを提供し得るものであり、それらの他のネットワーク１１２は、他のサービスプロバイダにより所有される、および／または動作させられる、他の配線される、または無線のネットワークを含み得るものである。
【００４２】
一部の実施形態ではＷＴＲＵ１０２は、水道メータ、発明者検出器、ドア検知、温度検知器、ビデオカメラ、その他などの、データを生成するデバイスであり得る。
【００４３】
図２は、サービス能力レイヤ（ＳＣＬ）であり得るアプリケーションサービスレイヤ（ＡＳＬ）を含むプロトコルスタックを例示する。図２で例示されるのは、物理（ＰＨＹ）プロトコルレイヤ２０２、メディアアクセス制御（ＭＡＣ）プロトコルレイヤ２０４、ネットワークプロトコルレイヤ２０６、トランスポートプロトコルレイヤ２０８、アプリケーションプロトコルレイヤ２１０、ＳＣＬ２１２、および、アプリケーション２１４である。ＳＣＬ２１２は、アプリケーション２１４に対するサポートレイヤを提供し得るものであり、機能のコレクションが、再使用可能な、およびモジュール式の方式で実行され得る。例えばＳＣＬ２１２は、アプリケーション２１４に、より低いプロトコルレイヤにある機能およびサービスへのアクセスと同じほどに良好に、アプリケーションプロトコルレイヤ２１０の機能のコレクションまたはライブラリへのアクセスを提供する、アプリケーションプログラミングインターフェイス（ＡＰＩ）をサポートし得る。ＳＣＬ２１２は、例えば、アプリケーションブートストラッピング、登録、発見、管理、ならびに、アプリケーションメッセージの一般的な送信および受信、または類するものものなどのサービスを提供し得る。ＳＣＬ２１２のサービスは、定義されたメッセージフォーマット、リソース構造、および、リソース表現を使用し得るＡＰＩによって、アプリケーション２１４に利用可能に行われ得る。
【００４４】
図３は、２つのアプリケーションが、ＳＣＬであり得る共通ＡＳＬによって互いに通信する例を例示する。図３で例示されるのは、ネットワーク３００、デバイスＡ３０２、デバイスＢ３０４、および、通信３０６である。デバイスＡ３０２およびデバイスＢ３０４は、ＷＴＲＵ１０２などの無線デバイス、または、通信ネットワークに直接配線されるデバイスであり得る。デバイスＡ３０２およびデバイスＢ３０４は、互いに通信しているデバイスまたはマシンであるので、デバイスＡ３０２およびデバイスＢ３０４は、マシンツーマシン（Ｍ２Ｍ）デバイス３０２、３０４と称され得る。例えばデバイスＡ３０２およびデバイスＢ３０４は、インターネット１１０、または、他のネットワーク１１２に直接配線され得る。通信３０６は、デバイスＡ３０２のアプリケーション２１４と、デバイスＢ３０４のアプリケーション２１４との間の通信３０６であり得る。通信３０６は、ＡＳＬ２１２を利用して、ＡＳＬ２１２により提供されるプロトコルおよびサービスを使用して互いに通信する、デバイスＡ３０２のアプリケーション２１４、および、デバイスＢ３０４のアプリケーション２１４を例示する。
【００４５】
図４Ａは、一部の実施形態による、Ｍ２Ｍシステム４００を例示する。欧州電気通信標準化機構（ＥＴＳＩ）マシンツーマシン（Ｍ２Ｍ）通信機能アーキテクチャは、Ｍ２Ｍアプリケーションと、Ｍ２Ｍデバイス、ゲートウェイ、および、サーバとの間の通信を可能にするために具体的に修整される、標準化されたアプリケーションサービスレイヤ（ＡＳＬ）を定義する。図４Ａは、Ｍ２Ｍサーバ４０２、Ｍ２Ｍゲートウェイ４０４、Ｍ２Ｍデバイス１０２、および、Ｍ２Ｍアプリケーション（例示されない）からなる総体的なＭ２Ｍシステム４００を例示する。一部の実施形態では図４Ａは、ＥＴＳＩ  Ｍ２Ｍシステム４００であり得る。ＥＴＳＩ  Ｍ２Ｍ専門用語では、ＡＳＬは、サービス能力レイヤ（ＳＣＬ）と呼称され得る。Ｍ２Ｍデバイス１０２は、ＷＬＡＮ１５５、Ｂｌｕｅｔｏｏｔｈ、３ＧＰＰ、その他によってサーバ４０２と通信し得る。Ｍ２Ｍゲートウェイ４０４は、セルラーおよび非セルラーＭ２Ｍデバイス１０２を、オペレータネットワーク、１０６、１１２、１１０による通信に対して可能にする。Ｍ２Ｍサーバは、サービス能力レイヤであり得るアプリケーションサービスレイヤ２１２を提供する。
【００４６】
一部の実施形態ではシステム４００は、表現状態遷移（ＲＥＳＴｆｕｌ：Representational State Transfer）システム４００であり得る。ＲＥＳＴｆｕｌは、クライアントサーバに基づくモデルに依拠するソフトウェアアーキテクチャであり得る。クライアントは、サーバ上でホストされるリソースへの要求を行う。リソースは、統一リソース識別子（ＵＲＩ）によってアドレスされ得る。クライアントは、コマンドの簡便な、および統一のセットを使用して、リソースへの要求を行い得る。これらのコマンドは、しばしばＣＲＵＤ動作と呼称される。ＣＲＵＤ動作は、作成（ＰＯＳＴ）、検索（ＧＥＴ）、更新（ＰＵＴ）、および、削除を含み得る。Ｚｉｇｂｅｅ（登録商標）ＩＰ  Ｓｍａｒｔ  Ｅｎｅｒｇｙ（商標）２．０ＳＣＬ、および、ＥＴＳＩ  Ｍ２Ｍ  ＳＣＬは、ＲＥＳＴｆｕｌ  ＳＣＬを使用し得る。
【００４７】
図４Ｂは、一部の実施形態による、Ｍ２Ｍアーキテクチャを例示する。図４Ｂで例示されるのは、アプリケーション４５０、Ｍ２Ｍサーバ４０２、ネットワーク４５４、Ｍ２Ｍゲートウェイ４５８、Ｍ２Ｍエリアネットワーク４６２、Ｍ２Ｍデバイス４６４ａ、アプリケーション４５６、Ｍ２Ｍデバイス４６４ｂ、ならびに、インターフェイスｄＩａ、ｍＩｄ、および、ｍＩａであり、ただし、ｄはデバイスを表象し、ｍはサービスを表象し、ａはアプリケーションを表象する。
【００４８】
Ｍ２Ｍサーバ４０２は、サービス能力レイヤ（ＳＣＬ）４５２を含み得る。Ｍ２Ｍゲートウェイ４５８は、サービス能力レイヤ（ＳＣＬ）４６０を含み得る。Ｍ２Ｍデバイス４６４ｂは、アプリケーション４６８およびサービス能力レイヤ（ＳＣＬ）４６６を含み得る。一部の実施形態ではＭ２Ｍアーキテクチャは、ＥＴＳＩ  Ｍ２Ｍアーキテクチャであり得る。一部の実施形態ではＳＣＬ４５２は、Ｍ２Ｍサーバ４０２、ゲートウェイ４５８、または、デバイス４６４ｂ上でホストされ得る。ＳＣＬ４５２は、ＡＳＬであり得る。
【００４９】
アプリケーション４６８、４５０、４５６は、Ｍ２Ｍサーバ４０２、ゲートウェイ４５８、または、Ｍ２Ｍデバイス４６４ｂ上でホストされる、１または複数のＳＣＬ４６０、４５２、４６６に登録し、それらのＳＣＬとインターフェイス接続し得る。一部の実施形態では、インターフェイスｍＩａ、ｍＩｄ、ｄＩａが使用され得る。ＥＴＳＩ  Ｍ２Ｍは、互いに通信するためにＳＣＬ４５２、４６０、４６６、および、アプリケーション４５６、４６８、４５０により使用される方法を含み得る、インターフェイスｍＩａ、ｍＩｄ、ｄＩａを定義し得る。Ｍ２Ｍデバイス４６４ａは、ＳＣＬを有さない場合があり、その事例ではＭ２Ｍデバイス４６４ａは、Ｍ２Ｍゲートウェイ４５８と通信し得る。一部の実施形態ではアプリケーション４５０、４５６、４６８は、Ｍ２Ｍデバイス４６４ａおよびＭ２Ｍゲートウェイ４５８と通信して、Ｍ２Ｍデバイス４６４ａとＭ２Ｍサーバ４０２との間の通信を容易にし得る。アプリケーション４５６は、デバイス４７０によりホストされ得る。
【００５０】
ＳＣＬ４６０、４５２、４６６は、本明細書で開示されるようなリソース構造９００、１０００を含み得る。ＳＣＬ４６０、４５２、４６６の１または複数は、ＳＣＬの部分的機能面のみを含み得る。Ｍ２Ｍデバイス４６４ａは、非ＥＴＳＩ  Ｍ２Ｍデバイスであり得る。Ｍ２Ｍデバイス４６４ａは、Ｍ２Ｍゲートウェイ４５８および／またはＭ２Ｍサーバ４０２が準拠する、１または複数の標準に準拠しないＳＣＬを含み得る。Ｍ２Ｍデバイス４６４ａ、４６４ｂ、および、アプリケーション４５６は、Ｍ２Ｍエリアネットワーク４６２と、および／または、ネットワーク４５４と（例示されない）通信し得る。図４Ｂで例示される要素の各々の２つ以上のものが存し得る。
【００５１】
図５は、リソース構造５００の例を例示する。リソース構造５００は、ＲＥＳＴｆｕｌリソース構造であり得る。
【００５２】
リソース構造５００は、ｓｃｌＢａｓｅ５０２を含み得るものであり、そのｓｃｌＢａｓｅ５０２は、リソースの、後に続く群："ａｔｔｒｉｂｕｔｅ"５０４、ｓｃｌｓ５０６、ａｐｐｌｉｃａｔｉｏｎｓ５０８、ｃｏｎｔａｉｎｅｒｓ５１０、ｇｒｏｕｐｓ５１２、ａｃｃｅｓｓＲｉｇｈｔ５１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ５１６、および、ｄｉｓｃｏｖｅｒｙ５１８の、１または複数を含み得る。一部の実施形態では、"ａｔｔｒｉｂｕｔｅ"５０４、ｓｃｌｓ５０６、ａｐｐｌｉｃａｔｉｏｎｓ５０８、ｃｏｎｔａｉｎｅｒｓ５１０、ｇｒｏｕｐｓ５１２、ａｃｃｅｓｓＲｉｇｈｔ５１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ５１６、および、ｄｉｓｃｏｖｅｒｙ５１８は、ＥＴＳＩ  Ｍ２Ｍで開示されるようなものであり得る。ＳＣＬ４５２（図４Ｂ）は、リソース構造５００を含み得る。
【００５３】
アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（図４Ｂで例示されない）は、ＳＣＬ４５２により提供されるサービスを使用するように構成され得る。アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（例示されない）は、ＲＥＳＴｆｕｌ  ＣＲＵＤ動作（作成、検索、更新、削除）を使用して、リソース構造５００の内部のリソースと対話し得る。
【００５４】
ＲＥＳＴｆｕｌ  ＣＲＵＤ動作は、ＥＴＳＩ  Ｍ２Ｍアーキテクチャで開示されるように構成され得る。ＲＥＳＴｆｕｌ  ＣＲＵＤ動作は、プリミティブ（例示されない）を使用するように構成され得る。例えばプリミティブは、ＲＥＳＴｆｕｌメッセージ（例示されない）であり得る。プリミティブは、動作が、ＲＥＳＴｆｕｌリソース構造５００の内部でホストされる特定のリソースで遂行される、標準方途を提供し得る。一部の実施形態ではプリミティブは、ＳＣＬ  ＲＥＳＴｆｕｌリソース構造５００によって、単一のリソースで単一のＲＥＳＴｆｕｌ  ＣＲＵＤ動作を遂行することをサポートする。
【００５５】
図６は、ＨＴＴＰバッチ化される要求または応答６００の例を例示する。ＨＴＴＰバッチ化される要求または応答６００は、ＨＴＴＰヘッダ６０２、ＨＴＴＰオプション６０４、および、ＨＴＴＰペイロード６０６を含み得る。ＨＴＴＰペイロード６０６は、１または複数のＨＴＴＰ要求または応答６０８を含み得る。各々のＨＴＴＰ要求または応答６０８は、ＨＴＴＰヘッダ６１０．１、ＨＴＴＰオプション６１２．１、および、ＨＴＴＰペイロード６１４．１を含み得る。ＨＴＴＰバッチ化される要求または応答６００は、パースされ得るものであり、ＨＴＴＰペイロード６０６内のＨＴＴＰ要求または応答６０８の各々は、別々になるように抽出および処理され得る。一部の実施形態では、ＨＴＴＰ要求または応答６０８の各々は、完全形のＨＴＴＰ要求または応答である。
【００５６】
図７は、サービス能力レイヤに登録し、４つのコンテナリソースを作成する、デバイスアプリケーションの方法７００の例を例示する。
【００５７】
ＤＡ７０２は、デバイスのアプリケーションであり得る。例えばＤＡ７０２は、アプリケーション４６８（図４Ｂを確認されたい）であり得る。デバイスは、デバイス４６４ｂであり得る。デバイス４６４ｂは、温度（temperature）、圧力（pressure）、湿度（humidity）、および、風（wind）などの４つの検知器をサポートする検知器であり得る。これらの検知器は、周期的測定値をとり、それらを、デバイス４６４ｂのネットワークインターフェイス（例示されない）によって利用可能にし得る。デバイス４６４ｂは、それが個々の検知器読み取り値の履歴を記憶することを妨げる、制限される量のローカルメモリを有し得る。
【００５８】
サービス能力レイヤ（ＳＣＬ）７０４は、ＳＣＬ４５２（図４Ｂを確認されたい）であり得る。方法７００は、ＳＣＬへ登録するＤＡ７０２によって始まり得る（７０６）。ＤＡ７０２は、ＳＣＬ７０４に登録し得る。方法７００は、/scl/application/da1を作成すること（７０８）によって継続し得る。ＳＣＬ７０４は、ＤＡ７０２に対するアプリケーションリソースを作成し得る。例えばＳＣＬ７０４は、リソース構造５００（図５）内でアプリケーション５０８の下に、ＤＡ７０２に対するアプリケーションリソース「ｄａ１」を作成し得る。方法７００は、応答  −  作成された（Created）（７１０）によって継続し得る。ＳＣＬ７０４は、アプリケーションリソースが作成されたという応答を、ＤＡ７０２に送り得る。
【００５９】
方法７００は、ＤＡがＳＣＬ内にコンテナｔｅｍｐを作成すること（７１２）によって継続し得る。例えばアプリケーション４６８は、作成をＳＣＬ４５２に送り得る。方法７００は、/scl/application/da1/containers/tempを作成すること（７１４）によって継続し得る。例えばＳＣＬ４５２は、「ｃｏｎｔａｉｎｅｒｓ」５１０リソースの下にリソース「ｔｅｍｐ」を作成し得る。方法７００は、応答  −  作成された（７１６）によって継続し得る。例えばＳＣＬ４５２は、「ｔｅｍｐ」コンテナが作成されたという応答を、アプリケーション４６８に送り得る。
【００６０】
方法７００は、ＤＡがＳＣＬ内にコンテナｐｒｅｓｓｕｒｅを作成すること（７１８）によって継続し得る。例えばアプリケーション４６８は、作成をＳＣＬ４５２に送り得る。方法７００は、/scl/application/da1/containers/pressureを作成すること（７２０）によって継続し得る。例えばＳＣＬ４５２は、「ｃｏｎｔａｉｎｅｒｓ」５１０リソースの下にリソース「ｐｒｅｓｓｕｒｅ」を作成し得る。方法７００は、応答  −  作成された（７２２）によって継続し得る。例えばＳＣＬ４５２は、「ｐｒｅｓｓｕｒｅ」コンテナが作成されたという応答を、アプリケーション４６８に送り得る。
【００６１】
方法７００は、ＤＡ７０２がＳＣＬ内にコンテナｈｕｍｉｄｉｔｙを作成すること（７２４）によって継続し得る。例えばアプリケーション４６８は、作成をＳＣＬ４５２に送り得る。方法７００は、/scl/application/da1/containers/humidityを作成すること（７２６）によって継続し得る。例えばＳＣＬ４５２は、「ｃｏｎｔａｉｎｅｒｓ」５１０リソースの下にリソース「ｈｕｍｉｄｉｔｙ」を作成し得る。方法７００は、応答  −  作成された７２８によって継続し得る。例えばＳＣＬ４５２は、「ｈｕｍｉｄｉｔｙ」コンテナが作成されたという応答を、アプリケーション４６８に送り得る。
【００６２】
方法７００は、ＤＡがＳＣＬ内にコンテナｗｉｎｄを作成すること７３０によって継続し得る。例えばアプリケーション４６８は、作成をＳＣＬ４５２に送り得る。方法７００は、/scl/application/da1/containers/windを作成すること７３２によって継続し得る。例えばＳＣＬ４５２は、「ｃｏｎｔａｉｎｅｒｓ」５１０リソースの下にリソース「ｔｅｍｐ」を作成し得る。方法７００は、応答  −  作成された７３４によって継続し得る。例えばＳＣＬ４５２は、「ｔｅｍｐ」コンテナが作成されたという応答を、アプリケーション４６８に送り得る。
【００６３】
アプリケーション７０２は今や、データを、作成された温和なコンテナ、圧力コンテナ、湿度コンテナ、および、風コンテナに送ることが可能である。一部の実施形態では方法７００は、ＥＴＳＩ  Ｍ２Ｍによるものであり得る。
【００６４】
図８は、サービス能力レイヤに登録し、４つのコンテナリソースを作成する、デバイスアプリケーションの方法８００の例を例示する。
【００６５】
ＤＡ８０２は、デバイスのアプリケーションであり得る。例えばＤＡ８０２は、アプリケーション４６８（図４Ｂを確認されたい）であり得る。デバイスは、デバイス４６４ｂであり得る。デバイス４６４ｂは、温度、圧力、湿度、および、風などの４つの検知器をとりサポートする検知器であり得る。これらの検知器は、周期的測定値をとり、それらを、デバイス４６４ｂのネットワークインターフェイス（例示されない）によって利用可能にし得る。デバイス４６４ｂは、それが個々の検知器読み取り値の履歴を記憶することを妨げる、制限される量のローカルメモリを有し得る。サービス能力レイヤ（ＳＣＬ）８０４は、ＳＣＬ４５２（図４Ｂを確認されたい）であり得る。
【００６６】
方法８００は、ＤＡ８０２が、バッチ要求を使用してＳＣＬ上のコンテナを登録および作成すること８０６によって始まり得る。例えばアプリケーション４６８は、表１で例示されるｂａｔｃｈＲｅｑｕｅｓｔをＳＣＬ４５２に送り得る。
【００６７】
【表１】
0006473697.tif 000002
【００６８】
方法８００は、/scl/application/da1を作成すること８１０によって継続し得る。ＳＣＬ７０４は、ＤＡ７０２に対するアプリケーションリソースを作成し得る。例えばＳＣＬ８０４は、リソース構造５００（図５）内でアプリケーション５０８の下に、ＤＡ８０２に対するアプリケーションリソース「ｄａ１」を作成し得る。
【００６９】
方法８００は、/scl/application/da1/containers/tempを作成すること８１２によって継続し得る。例えばＳＣＬ４５２は、「コンテナ」５１０リソースの下にリソース「ｔｅｍｐ」を作成し得る。方法８００は、/scl/application/da1/containers/pressureを作成すること８１４によって継続し得る。例えばＳＣＬ４５２は、「コンテナ」５１０リソースの下にリソース「ｐｒｅｓｓｕｒｅ」を作成し得る。方法８００は、/scl/application/da1/containers/humidityを作成すること８１６によって継続し得る。例えばＳＣＬ４５２は、「コンテナ」５１０リソースの下にリソース「ｈｕｍｉｄｉｔｙ」を作成し得る。方法８００は、scl/application/da1/containers/windを作成すること８１８によって継続し得る。例えばＳＣＬ４５２は、「コンテナ」５１０リソースの下にリソース「ｗｉｎｄ」を作成し得る。
【００７０】
方法８００は、バッチＲＥＳＰＯＮＳＥ  −  作成された８２０によって継続し得る。例えばＳＣＬ４５２は、バッチ応答  −  作成された、を、アプリケーション４６８に送り得る。
【００７１】
方法８００は、図７の方法７００より少ない、ＤＡ８０２とＳＣＬ８０４との間のメッセージを有し得るということが、当業者により理解されるべきである。
【００７２】
図９は、一部の実施形態による、バッチ要求リソースを伴うリソース構造９００の例を例示する。リソース構造９００は、ＲＥＳＴｆｕｌリソース構造であり得る。
【００７３】
リソース構造９００は、ｓｃｌＢａｓｅ９０２を含み得るものであり、そのｓｃｌＢａｓｅ９０２は、リソースの、後に続く群："ａｔｔｒｉｂｕｔｅ"９０４、ｓｃｌｓ９０６、ａｐｐｌｉｃａｔｉｏｎｓ９０８、ｃｏｎｔａｉｎｅｒｓ９１０、ｇｒｏｕｐｓ９１２、ａｃｃｅｓｓＲｉｇｈｔ９１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ９１６、ｄｉｓｃｏｖｅｒｙ９１８、および、ｂａｔｃｈＲｅｑｕｅｓｔ９２０の、１または複数を含み得る。一部の実施形態では、"ａｔｔｒｉｂｕｔｅ"９０４、ｓｃｌｓ９０６、ａｐｐｌｉｃａｔｉｏｎｓ９０８、ｃｏｎｔａｉｎｅｒｓ９１０、ｇｒｏｕｐｓ９１２、ａｃｃｅｓｓＲｉｇｈｔ９１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ９１６、および、ｄｉｓｃｏｖｅｒｙ９１８は、ＥＴＳＩ  Ｍ２Ｍで開示されるようなものであり得る。ＳＣＬ４５２（図４Ｂ）は、リソース構造５００を含み得る。
【００７４】
アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（図４Ｂで例示されない）は、ＳＣＬ４５２により提供されるサービスを使用するように構成され得る。アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（例示されない）は、ＲＥＳＴｆｕｌ  ＣＲＵＤ動作（作成、検索、更新、削除）を使用して、リソース構造５００の内部のリソースと対話し得る。
【００７５】
ｂａｔｃｈＲｅｑｕｅｓｔ９２０は、ＳＣＬが、バッチ化される要求にサービス提供するために、アプリケーションまたは別のＳＣＬにより対象とされ得るリソースであり得る。ｂａｔｃｈＲｅｑｕｅｓｔ９２０は、仮想リソースであり得る。ｂａｔｃｈＲｅｑｕｅｓｔ９２０は、ＥＴＳＩ  Ｍ２Ｍ  ＳＣＬリソース構造で定義される仮想リソースであり得る。一部の実施形態ではｂａｔｃｈＲｅｑｕｅｓｔ９２０は、何らのアドレス可能サブリソースまたは属性も、サポートまたは維持しないリソースであり得る。ｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースは、ＳＣＬリソース構造９００内の単一のアドレス可能位置を提供し得るものであり、バッチ化される要求は、その位置を、アプリケーションまたは他のＳＣＬから向かう対象とされ得る。
【００７６】
ＳＣＬは、ｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースを対象とする要求を受信することに応答するように構成され得る。ＳＣＬは、次いで、要求を、それが受信する他の非バッチ要求から区別し、それを、バッチ化される要求としてハンドリングし得る。一部の実施形態ではｂａｔｃｈＲｅｑｕｅｓｔ９２０は、仮想およびＲＥＳＴｆｕｌであり得るものであり、そのためそれは、状態（例えば、リソース属性）を含まない場合がある。一部の実施形態では、多重および同時の要求が、ｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースに対して行われ得る。一部の実施形態では、ｂａｔｃｈＲｅｑｕｅｓｔ９２０への要求は、冪等および非競合の様式で行われ得る。一部の実施形態ではｂａｔｃｈＲｅｑｕｅｓｔ９２０は、リソース構造９００の根レベルにあり得る。リソース構造９００の根レベルにあることにより、ｂａｔｃｈＲｅｑｕｅｓｔ９２０は、アプリケーションおよび他のＳＣＬにより決定され得る、標準化された位置にあり得る。
【００７７】
一部の実施形態ではｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースは、リソース構造９００の異なる位置にあり得る。一部の実施形態では、２つ以上のｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースが存し得るものであり、異なるｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースが、リソース構造９００の異なる位置にあり得る。例えばｂａｔｃｈＲｅｑｕｅｓｔ９２０リソースは、バッチ化される要求をサポートするリソースとともにのみで、リソース構造９００に含まれ得る。
【００７８】
図１０は、一部の実施形態による、バッチ要求リソースを伴うリソース構造１０００の例を例示する。リソース構造１０００は、ＲＥＳＴｆｕｌリソース構造であり得る。リソース構造１０００は、ＥＴＳＩ  Ｍ２Ｍリソース構造であり得る。
【００７９】
リソース構造１０００は、ｓｃｌＢａｓｅ１００２を含み得るものであり、そのｓｃｌＢａｓｅ１００２は、リソースの、後に続く群："ａｔｔｒｉｂｕｔｅ"１００４、ｓｃｌｓ１００６、ａｐｐｌｉｃａｔｉｏｎｓ１００８、ｃｏｎｔａｉｎｅｒｓ１０１０、ｇｒｏｕｐｓ１０１２、ａｃｃｅｓｓＲｉｇｈｔ１０１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ１０１６、ｄｉｓｃｏｖｅｒｙ１０１８、および、ｂａｔｃｈＲｅｑｕｅｓｔ１０２０の、１または複数を含み得る。一部の実施形態では、"ａｔｔｒｉｂｕｔｅ"１００４、ｓｃｌｓ１００６、ａｐｐｌｉｃａｔｉｏｎｓ１００８、ｃｏｎｔａｉｎｅｒｓ１０１０、ｇｒｏｕｐｓ１０１２、ａｃｃｅｓｓＲｉｇｈｔ１０１４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ１０１６、および、ｄｉｓｃｏｖｅｒｙ１０１８は、ＥＴＳＩ  Ｍ２Ｍで開示されるようなものであり得る。ＳＣＬ４５２（図４Ｂ）は、リソース構造５００を含み得る。
【００８０】
アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（図４Ｂで例示されない）は、ＳＣＬ４５２により提供されるサービスを使用するように構成され得る。アプリケーション４５０、４５６、４６８、および／または、別のＳＣＬ（例示されない）は、ＲＥＳＴｆｕｌ  ＣＲＵＤ動作（作成、検索、更新、削除）を使用して、リソース構造５００の内部のリソースと対話し得る。
【００８１】
ＢａｔｃｈＲｅｑｕｅｓｔ１０２０は、コレクションであり得る。ＢａｔｃｈＲｅｑｕｅｓｔ１０２０は、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースの１または複数のインスタンスを含み得る。＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２の各々は、１または複数の属性１０２４を有し得る。＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２は、ＳＣＬによるバッチ化される要求の起動およびサービス提供をサポートするために使用される、サブリソースを含み得る。ｂａｔｃｈＲｅｑｕｅｓｔ１０２０は、仮想リソースでない場合があり、アドレスされ得る。
【００８２】
一部の実施形態では、バッチ化される要求を起動するために、要求が、ｂａｔｃｈＲｅｑｕｅｓｔ１０２０コレクションの内部の＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースを作成または更新するように行われ得る。＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースを作成または更新することの行為は、ＳＣＬが、バッチ化される要求にサービス提供することを開始することをトリガし得る。
【００８３】
一部の実施形態では＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースは、対応するＳＣＬが＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースを処理することを開始することをトリガするための、特定の属性１０２４をサポートし得る。例えば、執行と呼ばれる属性１０２４が定義され得る。＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースは、ｂａｔｃｈＲｅｑｕｅｓｔ１０２０コレクションで維持され、後続のバッチ化される要求を遂行するために再使用または再呼び出しされ得る。例えば、同じ発信する要求側、または異なる要求側は、同じ＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２を呼び出しし得る。一部の実施形態ではアプリケーションは、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースを更新し、次いで、ＳＣＬが、更新される＜ｂａｔｃｈＲｅｑｕｅｓｔ＞リソース１０２２に関連付けられる、対応するバッチ要求にサービス提供することを開始することをトリガし得る。一部の実施形態ではＳＣＬは、値が追加されたパラメータまたは属性をサポートして、要求側が、どのようにＳＣＬが＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２にサービス提供すべきであるかに対するその選好を構成することを可能とし得る。例えば要求側は、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２にサービス提供することに対して、各々の要求に対する優先度、または、各々の要求にサービス提供することに対する最大遅延を指定し得る。
【００８４】
＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２リソースの属性１０２４およびサブリソースは、応答ハンドリングのためにＳＣＬにより使用され得る。例えば応答は、または応答へのリンクさえも、リソースとして、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２の属性１０２４および／またはサブリソースに記憶され得る。これらの応答は、要求側にアクセス可能であり得るものであり、ＳＣＬによりキャッシュおよび再使用され得る。例えばキャッシュされる応答は、同じ要求側からの、または、異なる要求側によるもののいずれかの将来要求にサービス提供するために、ＳＣＬにより使用され得る。要求側は、ＳＣＬ内の＜ｂａｔｃｈｅｄＲｅｑｕｅｓｔ＞１０２２のセットを待ち行列に入れ得る。ＳＣＬは、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２にサービス提供し、応答をＳＣＬリソース構造１０００に記憶し得る。要求側は、結果を、それらがＳＣＬにより生成した後に検索し得る。一部の実施形態では応答は、リソース構造１０００内の他のリソース、または、別のリソース構造に記憶され得る。
【００８５】
一部の実施形態ではＳＣＬは、要求側により、すべてのバッチ化される要求が完了したときに要求側に通知するように構成され得る。要求側は、ＳＣＬを、加入／通知機能性によって構成し得る。応答は、要求側が検索するために、通知に含まれ得る、または、リソース構造１０００に記憶され得る。
【００８６】
一部の実施形態では要求側は、ＳＣＬを、どのようにＳＣＬが応答をハンドリングするかに対する選好に対して構成し得る。例えば要求側は、ＳＣＬを、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２への個々の応答の所望される数、各々の個々の応答の最大サイズ、または、＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２が起動された時間に相対的な応答に対する最大遅延に対して構成し得る。一部の実施形態ではＳＣＬは、選好に対するデフォルト構成を有し得る。
【００８７】
一部の実施形態では＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０コレクションは、リソース構造１０００の根レベルにあり得る。一部の実施形態では＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０は、＜ｓｃｌＢａｓｅ＞１００２リソースの下で、ＥＴＳＩ  Ｍ２Ｍリソース構造１０００の根レベルにあり得る。根レベルにある＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０コレクションは、すべてのＳＣＬを意識している要求側により使用され得る位置を提供し得る。一部の実施形態では、１または複数の＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０コレクションは、リソース構造１００２内の他の位置に配置され得る。例えば＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０は、ＥＴＳＩ  Ｍ２Ｍリソース構造１０００内の＜ｓｃｌＢａｓｅ＞／アプリケーション／＜アプリケーション＞／ｂａｔｃｈＲｅｑｕｅｓｔに配置され得る。リソース構造１０００内のリソースは、リソースに関連付けられるアクセス権を有し得る。＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０をリソース構造１０００内のリソースの下にプットすることにより、リソースへのアクセス権を有する要求側のみが、リソースの下に含まれる＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２０にアクセスすることが可能であり得る。
【００８８】
表２は、サブリソースとしてタイプ分けされている例ｂａｔｃｈＲｅｑｕｅｓｔを例示する。例えば、図１０の＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２は、サブリソースのタイプを有し得る。
【００８９】
【表２】
0006473697.tif 000003
【００９０】
表３は、ｂａｔｃｈＲｅｑｕｅｓｔリソースに対する例属性を例示する。例えば、図１０の＜ｂａｔｃｈＲｅｑｕｅｓｔ＞１０２２は、表３内の属性の１または複数を有し得る。
【００９１】
【表３】
0006473697.tif 000004
【００９２】
図１１Ａ、１１Ｂ、および、１１Ｃは、バッチプリミティブに対する異なる実施形態を例示する。
【００９３】
バッチプリミティブに対する異なる実施形態は、バッチ動作をサポートするためのメッセージに対するプリミティブであり得る。バッチプリミティブに対する異なる実施形態は、単一の要求プリミティブに、一体にバッチ化されるＲＥＳＴｆｕｌ  ＣＲＵＤ動作を遂行することをサポートするためのメッセージに対するＳＣＬプリミティブであり得る。
【００９４】
図１１Ａは、各々のプリミティブが、対応する要求および応答し得る、バッチプリミティブに対する実施形態を例示する。図１１Ａで例示されるのは、ｂａｔｃｈＣｒｅａｔｅＲｅｑｕｅｓｔ１１０２、ｂａｔｃｈＣｒｅａｔｅＲｅｓｐｏｎｓｅ１１０３、ｂａｔｃｈＤｅｌｅｔｅＲｅｑｕｅｓｔ１１０４、ｂａｔｃｈＤｅｌｅｔｅＲｅｓｐｏｎｓｅ１１０５、ｂａｔｃｈＲｅｔｒｉｅｖｅＲｅｑｕｅｓｔ１１０６、ｂａｔｃｈＲｅｔｒｉｅｖｅＲｅｓｐｏｎｓｅ１１０７、ｂａｔｃｈＵｐｄａｔｅＲｅｑｕｅｓｔ１１０８、および、ｂａｔｃｈＵｐｄａｔｅＲｅｓｐｏｎｓｅ１１０９である。
【００９５】
図１１Ｂは、単一のバッチ要求および単一のバッチ応答が使用され得る、バッチプリミティブに対する実施形態を例示する。図１１Ｂで例示されるのは、ｂａｔｃｈＲｅｑｕｅｓｔ１１１０およびｂａｔｃｈＲｅｓｐｏｎｓｅ１１１１である。属性１１１２は、ｂａｔｃｈＲｅｑｕｅｓｔ１１１０に関連付けられ得る。属性１１１３は、ｂａｔｃｈＲｅｓｐｏｎｓｅ１１１１に関連付けられ得る。属性１１１２および属性１１１３は、それぞれ、ｂａｔｃｈＲｅｑｕｅｓｔ１１１０およびｂａｔｃｈＲｅｓｐｏｎｓｅ１１１１で示される、バッチ化される要求および応答で遂行するための動作を示し得る。動作は、ＣＲＵＤ動作であり得る。
【００９６】
図１１Ｃは、属性がバッチ処理をサポートするために使用される、バッチプリミティブに対する実施形態を例示する。
【００９７】
図１１Ｃで例示されるのは、要求１１１４、応答１１１５、属性１１１６、および、属性１１１７である。属性１１１６および属性１１１７は、バッチ処理に対する要求１１１４、および、バッチ処理に対する応答１１１５をサポートするための属性であり得る。属性１１１６および属性１１１７は、上記の表３からの属性、および、バッチ処理をサポートするための他の属性を含み得る。
【００９８】
提案されるプリミティブを使用して、（プリミティブの単一のインスタンスを使用して）多重のリソースでＲＥＳＴｆｕｌ動作を遂行するためのサポートが実現され得る。
【００９９】
図１１Ａ、１１Ｂ、または、１１Ｃで開示される実施形態の１つを使用して、要求側は、バッチ要求プリミティブを使用して、ＳＣＬへの多重の要求を一体にバッチ化し得る。図１１Ａ、１１Ｂ、または、１１Ｃで開示される実施形態の１つを使用して、ＳＣＬは、バッチ応答プリミティブを使用して、１または複数の要求への応答で要求側に戻すための多重の応答を一体にバッチ化し得る。要求および応答は、Ｍ２Ｍ  ＲＥＳＴｆｕｌ動作であり得る。
【０１００】
図１２は、バッチ要求リソースに送られるバッチ要求に対するバッチ要求プリミティブハンドリングのための方法１２００を例示する。
【０１０１】
図１２で例示されるのは、要求側１２０２およびＳＣＬ１２０４である。方法１２００は、要求側１２０２が、１２１０で、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６をＳＣＬ１２０４に送ることによって始まり得る。ｂａｔｃｈＲｅｑｕｅｓｔは、ｂａｔｃｈＲｅｑｕｅｓｔリソースを識別し得る。例えば要求側１２０２は、アプリケーション４５０、４５６、４６８（図４）、または、別のＳＣＬ（例示されない）であり得る。識別されるｂａｔｃｈＲｅｑｕｅｓｔリソースは、ｂａｔｃｈＲｅｑｕｅｓｔリソース９２０（図９）またはｂａｔｃｈＲｅｑｕｅｓｔリソース１０２２（図１０）であり得る。
【０１０２】
方法１２００は、１２１２で、ｂａｔｃｈＲｅｑｕｅｓｔの動作を抽出すること１２０８によって継続し得る。ｂａｔｃｈＲｅｑｕｅｓｔ１２０６を受信することを基に、ＳＣＬ１２０４は、それがｂａｔｃｈＲｅｑｕｅｓｔリソースを対象とするので、それを、バッチ化される要求として検出し得る。ＳＣＬ１２０４は、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６の動作を決定し得る。動作は、ＣＲＵＤ動作であり得る。
【０１０３】
一部の実施形態ではＳＣＬ１２０４は、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６のプリミティブ名を使用することにより、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６の動作を決定し得る。例えば、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６のプリミティブ名は、図１１Ａで開示されるような４つのプリミティブ名の１つであり得る。別の例では、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６に関連付けられる属性が、ｂａｔｃｈＲｅｑｕｅｓｔ１２０６に対する動作を決定するために使用され得る。例えば方法プリミティブ属性は、図１１ＢのｂａｔｃｈＲｅｑｕｅｓｔ１１１０に対して使用され得る。例えばｂａｔｃｈＲｅｑｕｅｓｔ１１１０の属性１１１２は、下記の表４で論考されるような方法プリミティブ属性であり得る。
【０１０４】
方法１２００は、ｂａｔｃｈＬｉｓｔ属性をパースすること１２１０によって継続し得る。ＳＣＬ１２０４は、情報を、一体にバッチ化される個々の要求の各々に対して抽出し得る。ＳＣＬ１２０４は、要求の各々により対象とされるリソース（例示されない）で、対応する動作を遂行し得る。
【０１０５】
図１３Ａおよび１３Ｂは、開示される実施形態による、バッチ応答プリミティブハンドリングを例示する。
【０１０６】
図１３Ａおよび１３Ｂで例示されるのは、要求側１３０２およびＳＣＬ１３０４である。図１３Ａの方法１３００は、要求側１３０２が、１３１０で、ｂａｔｃｈＲｅｑｕｅｓｔ１３０６を送ることによって始まり得る。ｂａｔｃｈＲｅｑｕｅｓｔ１３０６は、どのように要求側１３０２が、ｂａｔｃｈＲｅｑｕｅｓｔ１３０６への応答を受信することを好むことになるかの表示を含み得る。方法１３００は、プロセスｂａｔｃｈＲｅｑｕｅｓｔ１３０８によって継続し得る。方法１３００は、１３１４で、ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２によって継続し得る。例えばＳＣＬ１３０４は、ｂａｔｃｈＲｅｑｕｅｓｔを処理し（１３０８）、すべての応答を、要求側１３０２に戻るように、ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２で送り得る。
【０１０７】
ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２は、応答表現が、要求側に送られることを要されない、動作作成および削除に対して、要求側１３０２により要求され得る、または、ＳＣＬ１３０４により使用され得る。ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２は、応答表現が、単一の応答の内部で適合するように、たやすく連結または集約され得るときに、要求側１３０２により要求され得る、または、ＳＣＬ１３０４により使用され得る。ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２は、実際のリソース表現を含む代わりに、リソース表現へのリンクが、単一のｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２に含まれ得るときに、要求側１３０２により要求され得る、または、ＳＣＬ１３０４により使用され得る。例えばＳＣＬ１３０４は、表現をリソース構造９００、１０００に記憶し、記憶される表現へのリンクを提供し得る。
【０１０８】
一部の実施形態ではｂａｔｃｈＲｅｓｐｏｎｓｅ１３１４は、ＳＣＬ１３０４が、ｂａｔｃｈＲｅｑｕｅｓｔ１３０６への応答を、一部の実施形態では要求側１３０２により指定され得るリソースの内部に記憶したということの表示であり得る。例えばｂａｔｃｈＲｅｑｕｅｓｔ１３０６は、異なる時間に応答する対象デバイス４６４がデータに対して照会されるということを要求するアプリケーション４５０からのものであり得る。ＳＣＬ１３０４は、リソース構造９００、１０００の内部のユニバーサルリソース識別子（ＵＲＩ）でのデバイスからのすべての応答を集約し得る。デバイス４６４からのすべての応答が受信および記憶されたとき、ＳＣＬ１３０４は、ｂａｔｃｈＲｅｓｐｏｎｓｅ１３１２を送って、要求側１３０２に、応答は準備が整っているということを通知し得る。
【０１０９】
図１３Ｂの方法１３５０は、要求側１３０２が、１３６０で、ｂａｔｃｈＲｅｑｕｅｓｔ１３５６を送ることによって始まり得る。ｂａｔｃｈＲｅｑｕｅｓｔ１３５６は、どのように要求側１３０２が、ｂａｔｃｈＲｅｑｕｅｓｔ１３５６への応答を受信することを好むことになるかの表示を含み得る。方法１３５０は、プロセスｂａｔｃｈＲｅｑｕｅｓｔ１３５８によって継続し得る。方法１３５０は、１３６４で、応答１３６２．１によって継続し得る。例えばＳＣＬ１３０４は、ｂａｔｃｈＲｅｑｕｅｓｔを処理し（１３５８）、応答の一部を、要求側１３０２に戻るように、応答１３６２．１で送り、応答の一部を、要求側１３０２に戻るように、１または複数の応答１３６２．Ｎで送り得る。応答１３６２．１から１３６２．Ｎは、ｂａｔｃｈＲｅｓｐｏｎｓｅまたは個々の応答のいずれかであり得る。
【０１１０】
例えば、両方とも単一のｂａｔｃｈＲｅｑｕｅｓｔ１３５６への応答でのバッチ応答である、２つの応答１３６２．１および１３６２．２が送られ得る。１つのバッチ応答１３６２．１は、成功裏に完了したすべてのバッチ化される要求に対する応答を内包し得るものであり、別のバッチ応答１３６２．２は、エラーに遭遇したｂａｔｃｈＲｅｑｕｅｓｔ１３５６の応答を内包し得る。別の例では、単一のバッチ応答が応答のサイズに起因して充分でない場合に、多重のバッチ応答１３６２．１から１３６２．Ｎが送られ得る。
【０１１１】
一部の実施形態では、応答１３６２．１から１３６２．Ｎは、ｂａｔｃｈＲｅｑｕｅｓｔ１３５６のバッチ化される要求への個々の応答であり得る。一部の実施形態では個々の応答は、それらはｐｒｏｃｅｓｓＲｅｑｕｅｓｔ１３５８の間に利用可能になるので送られ得る。一部の実施形態では、一部の応答１３６２．１から１３６２．Ｎは、バッチ化される応答であり得るものであり、一部は個々の応答であり得る。
【０１１２】
表４は、属性のリストを例示するものであり、それらの属性の１または複数は、バッチ要求プリミティブの部分として含まれ得るものである。追加的な属性およびサブリソースが含まれ得る。異なるバッチプリミティブが、異なるＣＲＵＤ動作に対して定義され得るものであり、または、単一のプリミティブが、すべてのＣＲＵＤ動作に対して使用され得る。単一のプリミティブが使用されるならば、ＣＲＵＤ動作は、専用化される属性を使用することによりプリミティブ属性の内部で、または、ｂａｔｃｈＬｉｓｔ属性の内部で指定され得る。
【０１１３】
【表４】
0006473697.tif 000005
【０１１４】
表５は、属性のリストを例示するものであり、それらの属性の１または複数は、バッチ応答プリミティブの部分として含まれ得るものである。追加的な属性およびサブリソースが含まれ得る。
【０１１５】
異なるバッチプリミティブが、異なるＣＲＵＤ動作に対して定義され得るものであり、または、単一のプリミティブが、すべてのＣＲＵＤ動作に対して使用され得る。単一のプリミティブが使用されるならば、ＣＲＵＤ動作は、専用化される属性を使用することによりプリミティブ属性の内部で、または、ｂａｔｃｈＬｉｓｔ属性の内部で指定され得る。
【０１１６】
【表５】
0006473697.tif 000006
【０１１７】
表６は、ｂａｔｃｈＬｉｓｔ要求パラメータを例示するものであり、それらのパラメータの１または複数は、ｂａｔｃｈＬｉｓｔリソースのｂａｔｃｈＬｉｓｔ要求の、要求の部分として含まれ得るものである。一部の実施形態では、ｂａｔｃｈＬｉｓｔ属性はリストであり得る。リストの内部の各々の要素は、単一の要求に対応し得る。一部の実施形態では、要求であり得る個々のリスト要素は、アドレスされ得るものであり、動作がそれらで遂行され得る。例えば、新しい要求がリストに追加され得るものであり、要求がリストから削除され得るものであり、要求がリスト内で更新され得るものであり、要求がリストから検索され得る。リスト内の各々の要求は関連付けられるパラメータのセットを有し得る。
【０１１８】
【表６−１】
0006473697.tif 000007
【０１１９】
【表６−２】
0006473697.tif 000008
【０１２０】
ｂａｔｃｈＬｉｓｔ属性は、バッチ要求の内部の個々の要求の各々に対する情報を含み得る。ｂａｔｃｈＬｉｓｔ属性は、バッチ要求の要求側により初期化され、バッチ要求を遂行するために必要とされるリソースおよび属性を抽出するために、対象とされるＳＣＬにより処理され得る。
【０１２１】
ｂａｔｃｈＬｉｓｔ属性は、プリミティブ属性またはリソース属性であり得る。ｂａｔｃｈＬｉｓｔ属性は、プリミティブ属性としてのバッチ要求プリミティブの部分であり得る。ＳＣＬは、ｂａｔｃｈＬｉｓｔプリミティブを処理し得る。一部の実施形態ではｂａｔｃｈＬｉｓｔは、リソース属性であり得るものであり、ｂａｔｃｈＲｅｑｕｅｓｔリソース属性としてＳＣＬの内部で維持され得る。ｂａｔｃｈＬｉｓｔリソースは、要求側によりアドレスされ得る。要求側は、ｂａｔｃｈＬｉｓｔリソースが更新および検索されるということを要求し得る。ｂａｔｃｈＬｉｓｔリソースがＳＣＬ  ｂａｔｃｈＲｅｑｕｅｓｔリソースの内部で作成されると、ｂａｔｃｈＬｉｓｔ属性は、ｂａｔｃｈＬｉｓｔ属性をバッチ要求プリミティブに含むよりむしろ、要求側によりアドレスされ得る。
【０１２２】
一部の実施形態ではｂａｔｃｈＬｉｓｔは、ｂａｔｃｈＲｅｑｕｅｓｔが仮想ｂａｔｃｈＲｅｑｕｅｓｔリソースとして実行されるときに、プリミティブ属性として実行され得る。一部の実施形態ではｂａｔｃｈＬｉｓｔは、仮想ｂａｔｃｈＲｅｑｕｅｓｔリソースがｂａｔｃｈＬｉｓｔリソース属性をサポートしないならば、プリミティブ属性として実行され得る。
【０１２３】
ＳＣＬは、ｂａｔｃｈＬｉｓｔの内部に内包されるパラメータを使用して、ｂａｔｃｈＲｅｑｕｅｓｔに内包される要求の各々を処理し得る。例えばＳＣＬは、どのリソースを対象とすべきか、どの動作をリソースで遂行すべきか、どのように応答をハンドリングすべきか、その他を、ｂａｔｃｈＬｉｓｔプリミティブ属性またはｂａｔｃｈＬｉｓｔリソース属性から決定し得る。ｂａｔｃｈＬｉｓｔプリミティブ属性およびｂａｔｃｈＬｉｓｔリソース属性は、追加的に、ＥＴＳＩ  Ｍ２Ｍリソースおよび／またはプリミティブ属性によりサポートされるパラメータを含み得る。
【０１２４】
表７は、ｂａｔｃｈＬｉｓｔ属性およびパラメータを構造化するための実施形態を例示する。
【０１２５】
【表７】
0006473697.tif 000009
【０１２６】
表７で、例１および２で例示されるのは、プリミティブ検索である。例１および２の両方は４つの要求を含み、それらの要求の各々は、検索であり、ｂａｔｃｈＬｉｓｔ属性に一体にバッチ化される。その後、例１および２の両方でのｂａｔｃｈＬｉｓｔ属性は、個々の要求に対する動作を内包しない。例１および２では検索である、プリミティブにより指定される動作は、各々の個々の要求に対して遂行するための動作として使用される。一部の実施形態では、個々の要求に対する動作は、「ｒｏ」パラメータなどの、動作を示すためのパラメータを使用して含められ得る。
【０１２７】
一部の実施形態ではｂａｔｃｈＬｉｓｔは、プレーンテキストストリングとしてフォーマットされ得る。一部の実施形態では各々の要求は、コンマなどの区切り文字により分離され得る。要求に関連付けられる各々のパラメータは、セミコロンなどの異なる区切り文字により分離され得る。パラメータは、名／値対からなり得るものであり、各々の名は、一意的であり得るものであり、値を割り当てられ得る。
【０１２８】
例１の各々の要求は、対象とされるリソースパラメータ（ｉｄ）、指定されるトークンパラメータ（ｔｋ）、および、個別の応答が要されるということが示される応答選好（ｒｐ）を含む。
【０１２９】
例２ではｂａｔｃｈＬｉｓｔは、プレーンテキストＣｏＲＥリンクフォーマット説明ストリングとしてフォーマットされる。パス、リソースタイプ（ｒｔ）、および、インターフェイス（ｉｆ）などのＣｏＲＥリンクフォーマットの内部の既存のフィールドは、それぞれ、ｉｄ、ｒｔ、および、ｒｉなどの、表６で定義される対応するパラメータを搬送し得る。一部の実施形態では新しいフィールドが、表６内のパラメータなどの追加的なパラメータに対して、ＣｏＲＥリンクフォーマット説明に追加され得る。
【０１３０】
図１４は、開示される実施形態による、バッチサービスの方法１４００を例示する。図１４で例示されるのは、アプリケーション１４０２およびＳＣＬ１４０４である。アプリケーション１４０２は、図４Ｂに関して説明されるようなアプリケーション４５６、４６８、または、４５０であり得る。アプリケーション１４０２は、ＥＴＳＩ  Ｍ２Ｍアプリケーションであり得る。ＳＣＬ１４０４は、図４Ｂに関して説明されるようなＳＣＬ４５３、４５２であり得る。ＳＣＬ１４０４は、ＥＴＳＩ  Ｍ２Ｍ  ＳＣＬであり得る。
【０１３１】
方法１４００は、アプリケーション１４０２が、バッチ要求１４０６を使用してＳＣＬに登録することによって始まり得る。バッチ要求１４０６は、ｂａｔｃｈＣｒｅａｔｅＲｅｑｕｅｓｔＩｎｄｉｃａｔｉｏｎプリミティブを伴ってｇｓｃｌ／ｂａｔｃｈＲｅｑｕｅｓｔ仮想リソースに送られ得る。表８は、メッセージ１４０６の例を例示する。ペイロードに含まれるのは、作成されることになる各々のリソース、および、その関連付けられる属性をリストアップする、ｂａｔｃｈＬｉｓｔ属性である。例えばアプリケーション１４０２は、アプリケーション４６８であり得るものであり、Ｍ２Ｍデバイス４６４ｂは、対応するＳＣＬコンテナがそれに対して作成される必要がある多重の測定値リソースをサポートし得る。ＳＣＬ１４０４は、ＳＣＬ４５３であり得る。仮想リソースは、図９で例示されるｂａｔｃｈＲｅｑｕｅｓｔ９２０であり得る。
【０１３２】
【表８】
0006473697.tif 000010
【０１３３】
方法１４００は、/gscl/applications/da1を作成すること１４０８によって継続し得る。例えばＳＣＬ１４０４は、ｂａｔｃｈＣｒｅａｔｅＲｅｑｕｅｓｔＩｎｄｉｃａｔｉｏｎプリミティブを受信し、ペイロードを通してパースして、作成するためのリソースのリストを内包するｂａｔｃｈＬｉｓｔ属性を手に入れる。ｂａｔｃｈＬｉｓｔの内部の各々のリソースに対して、リソースタイプおよびアプリケーションＩＤは、ＳＣＬ１４０４に、何のリソースを作成すべきか、および、何のＩＤを使用すべきかを伝えるために提供される。
【０１３４】
ＳＣＬ１４０４は、リソースツリー内のどこにリソースを作成すべきかを、リソースタイプ、および／または、ＵＲＩパス（ＩＤに存在するならば）に基づいて決定する。ＳＣＬ１４０４は、ｂａｔｃｈＬｉｓｔで提供される属性を使用して、新しく作成されるＳＣＬリソース内の対応する属性を構成し得る。表７で例示される属性名は、省略された名である。一部の実施形態では、全体の属性名が使用され得る。全体の属性名は、ＥＴＳＩ  Ｍ２Ｍ標準などの標準からのものであり得る。ＳＣＬ１４０４は、ｂａｔｃｈＬｉｓｔで見出される各々のリソースを処理し、ＳＣＬ１４０４は、各々のプロセス要求の成功または失敗の経過を記録し得る。
【０１３５】
ＳＣＬ１４０４がｂａｔｃｈＬｉｓｔ内のすべてのリソース要求にサービス提供したとき、それは、すべてのリソースが成功裏に作成されたならば、成功裏のｂａｔｃｈＣｒｅａｔｅＲｅｓｐｏｎｓｅＣｏｎｆｉｒｍプリミティブを生成し得る。何らかのリソースが適正に作成されなかったならば、ＳＣＬは、不成功裏のｂａｔｃｈＣｒｅａｔｅＲｅｓｐｏｎｓｅＣｏｎｆｉｒｍメッセージを生成することになる。
【０１３６】
方法は、バッチ応答  −  作成された１４１６によって継続し得る。例えばＳＣＬ１４０４は、バッチ要求１４０６で指定されるすべてのリソースが成功裏に作成されたということを示す、バッチ応答  −  作成された、を送り得る。
【０１３７】
図１５は、開示される実施形態による、バッチサービスの方法１５００を例示する。図１５で例示されるのは、非ＥＴＳＩデバイス１５０２、ＥＴＳＩ  Ｍ２Ｍインターネットワーキングプロキシ１５０４、および、ゲートウェイサービス能力レイヤ（ＧＳＣＬ）１５０６である。非ＥＴＳＩデバイス１５０２は、ＥＴＳＩ準拠デバイスでないデバイスであり得る。例えばＭ２Ｍデバイス４６４ａ（図４Ｂ）は、非ＥＴＳＩデバイス１５０２であり得る。ＥＴＳＩ  Ｍ２Ｍインターネットワーキングプロキシ１５０４は、非ＥＴＳＩデバイス１５０２とＧＳＣＬ１５０６との間でインターフェイス接続するアプリケーションであり得る。例えばＥＴＳＩ  Ｍ２Ｍインターネットワーキングプロキシ１５０４は、図４ｂのアプリケーション４５６または４５０であり得る。
【０１３８】
方法１５００は、非ＥＴＳＩ  Ｍ２ＭデバイスがＩＰＵに登録すること１５０８によって始まり得る。例えばアプリケーション４６８は、Ｍ２Ｍゲートウェイ４５８によってＭ２Ｍデバイス４６４ａを登録し得る。
【０１３９】
方法１５００は、ＩＰＵがデバイスリソースをＧＳＣＬに登録すること１５１０によって継続し得る。例えばアプリケーション４６８は、バッチ要求をＭ２Ｍゲートウェイ４５８に送り得る。表９は、アプリケーション４６８がＭ２Ｍゲートウェイ４５８に送り得る例バッチ要求を例示する。
【０１４０】
【表９】
0006473697.tif 000011
【０１４１】
方法１５００は、ＧＳＣＬがバッチ要求を処理すること１５１２によって継続し得る。例えばＭ２Ｍゲートウェイ４５８は、図１５で例示される例作成動作１５１２．１、１５１２．２、１５１２．３、および、１５１２．４を遂行し得る。方法１５００は、バッチ応答、作成された１５１４によって継続し得る。例えばＭ２Ｍゲートウェイ４５８は、バッチ応答１５１４をアプリケーション４６８に送り得る。バッチ応答１５１４は、図１５での例バッチ応答１５１４で例示されるような情報を含み得る。バッチ応答１５１４は、バッチ要求１５１０の内部の要求が成功裏であった、または、そうではなかったか否かを、および、バッチ要求１５１０内の要求を遂行することの成功または失敗に関係付けられる情報を示し得る。
【０１４２】
しばしばＩＰＵは、エリアネットワークの内部でいくつもの非ＥＴＳＩ  Ｍ２Ｍデバイス１５０２を発見し得るものであり、それは次いで、それらの非ＥＴＳＩ  Ｍ２Ｍデバイス１５０２を（非ＥＴＳＩ  Ｍ２Ｍデバイス１５０２のために）ゲートウェイＳＣＬ１５０６に登録する必要がある。
【０１４３】
図１６は、開示される実施形態による、バッチサービスの方法１６００を例示する。図１６で例示されるのは、ＮＳＣＬ１６０２およびＮＡ１６０４である。ＮＳＣＬ１６０２は、ネットワーキングされたＳＣＬ１６０２であり得る。例えばＮＳＣＬ１６０２は、図４ＢのＳＣＬ４５２であり得る。ＮＡ１６０４は、アプリケーション４５０またはアプリケーション４５６であり得る。
【０１４４】
方法１６００は、ＮＡ１６０４がバッチ要求１６０６を送ることによって始まり得る。バッチ検索１６０６は、ＮＳＣＬ１６０２に、多重のリソースから検索することを示すバッチ要求１６０６であり得る。１６０６に対する例メッセージが、表１０で例示される。
【０１４５】
【表１０】
0006473697.tif 000012
【０１４６】
方法１６００は、ＮＳＣＬ１６０２サービス個々の要求によって継続し得、バッチ化される応答１６０８を作成する。例えばＳＣＬ４５２は、バッチ要求を処理し、バッチ化される応答１６０８を作成し得る。ＳＣＬ４５２は、データをＭ２Ｍデバイスから検索し得る。
【０１４７】
方法１６００は、ＮＳＣＬ１６０２が、１６０８で、バッチ化される応答１６０６をＮＡ１６０４に送ることによって継続し得る。例えばＳＣＬ４５２は、データの検索を立証するバッチ応答を、データとともに送り得る。バッチ応答１６０８の例が、表１１で例示される。
【０１４８】
【表１１】
0006473697.tif 000013
【０１４９】
図１７は、開示される実施形態による、バッチサービスの方法１７００を例示する。
【０１５０】
図１７で例示されるのは、メータデバイス１７０２、ＧＳＣＬ１７０４、ＮＳＣＬ１７０６、および、ＮＡ１７０８である。メータデバイス１７０２は、非ＥＴＳＩ  Ｍ２Ｍデバイス４６４ａなどのデバイスであり得る。ＧＳＣＬ１７０４は、Ｍ２Ｍゲートウェイ４５８であり得る。ＮＳＣＬ１７０６は、Ｍ２Ｍサーバ４０２であり得る。ＮＡ１７０８は、アプリケーション４５０であり得る。
【０１５１】
ＮＳＣＬ１６０２は、ネットワーキングされたＳＣＬ１６０２であり得る。例えばＮＳＣＬ１６０２は、図４ＢのＳＣＬ４５２であり得る。ＮＡ１６０４は、アプリケーション４５０またはアプリケーション４５６であり得る。
【０１５２】
方法１７００は、ＮＡ１７０８がバッチ要求１７１０をＮＳＣＬ１７０６に送ることによって始まり得る。例えばバッチ要求１７１０は、データをメータデバイス１７０２から収集するためのバッチ要求であり得る。表１２は、例メッセージ１７１０である。「＊」は、多重のメータを示すためのワイルドカード文字であり得る。
【０１５３】
【表１２】
0006473697.tif 000014
【０１５４】
方法１７００は、ＮＳＣＬ１７０６がバッチ要求メッセージ１７１２をＧＳＣＬ１７０４に送ることによって継続し得る。例えばＭ２Ｍサーバ４０２は、バッチ要求をＭ２Ｍゲートウェイ４５８に送り得る。Ｍ２Ｍサーバ４０２は、バッチ要求１７１０で示されるデバイスがＥＴＳＩ  Ｍ２Ｍデバイスでない（または、標準準拠デバイスでない）と決定し得る。Ｍ２Ｍサーバ４０２は次いで、Ｍ２Ｍゲートウェイ４５８がデータを収集する必要があると決定し得る。例バッチ要求１７１２メッセージが、表１３で例示される。
【０１５５】
【表１３】
0006473697.tif 000015
【０１５６】
方法１７００は、ＧＳＣＬ１７０４が、１７１４で、個別の取得要求をメータデバイス１７０２に送ることによって継続し得る。例えばＭ２Ｍゲートウェイ４５８は、個別の取得要求を複数の非ＥＴＳＩ  Ｍ２Ｍデバイス４６４ａに送って、メータデバイス読み取り値を毎月検索すること１７１４をし得る。
【０１５７】
方法１７００は、ＧＳＣＬ１７０４が応答を取得すること１７１６によって継続し得る。例えばメータデバイス１７０２は、１７１６で、測定値をＧＳＣＬ１７０４に送り得る。例えば、複数の非ＥＴＳＩ  Ｍ２Ｍデバイス４６４ａ（図１７で例示されるような４つのデバイス）は、測定値をとり、または、すでにとられた測定値を報告し、それらをＧＳＣＬ１７０４に異なる時間に報告し得る。ＧＳＣＬ１７０４は、測定値を収集し得る。
【０１５８】
取得要求１７１４は、すべてが取得応答１７１６の前であるように例示されるが、取得要求１７１４および取得応答１７１６は、交錯させられ得る。例えば取得応答１７１６．２は、ＧＳＣＬ１７０４により、取得要求１７１４．２が送られる前に受信され得る。
【０１５９】
方法１７００は、ＧＳＣＬ１７０４からＮＳＣＬ１７０６へのバッチ応答１７１８によって継続し得る。例えばＧＳＣＬ１７０４は、バッチ応答１７１８をＮＳＣＬ１７０６に送り得る。図４Ｂからの例によって継続すると、Ｍ２Ｍゲートウェイ４５８は、バッチ応答をＳＣＬ４５３に送り得る。例バッチ応答メッセージ１７１８は、「＜メータ１読み取り値＞、＜メータ２読み取り値＞、その他」である。したがってメッセージは、各々のメータに対するメータ識別情報および読み取り値を伴うメッセージである。
【０１６０】
方法１７００は、ＮＳＣＬ１７０６がバッチ応答１７２０をＮＡ１７０８に送ることによって継続し得る。例えばＳＣＬ４５３は、バッチ応答１７２０をアプリケーション４５０に送り得る。例バッチ応答メッセージ１７２０は、「＜メータ１読み取り値＞、＜メータ２読み取り値＞、その他」である。したがってメッセージは、各々のメータに対するメータ識別情報および読み取り値を伴うメッセージである。方法１７００は終了し得る。
【０１６１】
図１８は、開示される実施形態による、バッチサービスの方法１８００を例示する。図１８で例示されるのは、ＧＳＣＬ１８０２、ＮＳＣＬ１８０４、および、ＮＡ１８０６である。ＧＳＣＬ１７０４は、Ｍ２Ｍゲートウェイ４５８であり得る。ＮＳＣＬ１７０６は、Ｍ２Ｍサーバ４０２であり得る。ＮＡ１７０８は、１または複数のアプリケーション４５０であり得る。
【０１６２】
方法１８００は、要求１８０８によって始まり得る。例えばアプリケーション４５０は、取得要求、削除要求、および、プット要求をＭ２Ｍサーバ４０２に送り得る。例要求メッセージ１８０８が、表１４で例示される。
【０１６３】
【表１４】
0006473697.tif 000016
【０１６４】
方法１８００は、ＮＳＣＬ１８０４が要求を集約すること１８１０によって継続し得る。方法１８００は、ＮＳＣＬ１８０４が、１８１２で、バッチ要求１８１２をＧＳＣＬ１８０２に送ることによって継続し得る。表１５は、表１４の要求メッセージに基づく例バッチ要求メッセージ１８１２を例示する。図４Ｂからの例によって継続すると、Ｍ２Ｍサーバ４０２は、バッチ要求をＭ２Ｍゲートウェイ４５８に送り得る。
【０１６５】
【表１５】
0006473697.tif 000017
【０１６６】
方法１８００は、ＧＳＣＬサービスバッチ要求１８１４によって継続し得る。例えばＧＳＣＬ１８０２は、表１５のバッチ要求内の個々の要求を、要求で指定されるデバイスに送り得る。
【０１６７】
方法１８００は、応答１８１６によって継続し得る。例えばＧＳＣＬ１８０２は、デバイスからの応答を、応答がＧＳＣＬ１８０２から受信されるように送り得る。表１６は、表１５内の要求を外に送ることから、ＧＳＣＬにより受信され得る例応答を例示する。
【０１６８】
【表１６】
0006473697.tif 000018
【０１６９】
方法１８００は、応答１８１８によって継続し得る。例えばＮＳＣＬ１８０４は、ＧＳＣＬ１８０２から受信される応答１８１６をＮＡ１８０６に再送り得る。方法１８００は終了し得る。一部の実施形態ではＮＳＣＬ１８０４は、応答１８１６を集約し、次いで、バッチ応答をＮＡ１８０６に送り得る。一部の実施形態ではＧＳＣＬ１８０２は、応答を集約し、バッチ応答をＮＳＣＬ１８０４に送り得る。
【０１７０】
特徴および要素が上記で、特定の組み合わせで説明されているが、当業者は、各々の特徴または要素が、単独で、または、他の特徴および要素との任意の組み合わせで使用され得るということを認識するであろう。追加で、本明細書で説明された方法は、コンピュータまたはプロセッサによる執行のためにコンピュータ可読メディアに組み込まれる、コンピュータプログラム、ソフトウェア、または、ファームウェアで実行され得る。コンピュータ可読メディアの例は、電子信号（配線される、または無線の接続によって送信される）、および、コンピュータ可読記憶メディアを含む。コンピュータ可読記憶メディアの例は、読み取りのみのメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気メディア、磁気光学メディア、ならびに、ＣＤ−ＲＯＭディスクおよびデジタルバーサタイルディスク（ＤＶＤ）などの光学メディアを含むが、それらに制限されない。ソフトウェアとの関連付けの状態にあるプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または、任意のホストコンピュータでの使用のためのラジオ周波数トランシーバを実行するために使用され得る。
【０１７１】
実施形態
【０１７２】
実施形態１．アプリケーションサービスレイヤ（ＡＳＬ）でサービスをサポートするための方法であって、バッチ化される要求をエンティティから受信することに応答して、バッチ化される要求を処理するステップと、バッチ化される要求への応答をエンティティに送るステップとを備える方法。
【０１７３】
実施形態２．応答を送るステップは、バッチ化される要求において示される各要求への個別の応答をエンティティに送るステップをさらに含む実施形態１の方法。
【０１７４】
実施形態３．バッチ化される要求を処理するステップは、バッチ化される要求において示された各要求を処理するステップをさらに含む実施形態１または２の方法。
【０１７５】
実施形態４．バッチ化される要求のうちの少なくとも２つに対して、バッチ化される要求のうちの少なくとも２つの動作は、同一の動作であり、動作は、バッチ化される要求のうちの少なくとも２つに対して１回指定されるのみである実施形態１乃至３のいずれかの方法。
【０１７６】
実施形態５．バッチ化される要求で示される要求のうちの少なくとも２つに対して、２つの異なる動作は、少なくとも２つの要求の一部として示される実施形態１乃至４のいずれかの方法。
【０１７７】
実施形態６．応答を送るステップは、各動作の処理するステップから受信された、エンティティへの応答をバッチ化するステップと、バッチ化された応答をエンティティに送るステップとをさらに含む実施形態１乃至５のいずれかの方法。
【０１７８】
実施形態７．受信することに応答しては、バッチ化される要求が、バッチ化される要求の名、バッチ化される要求に関連付けられた属性、および、バッチ化される要求がアドレスされるアドレスのうちの少なくとも１つに基づいてバッチ化されることを決定するステップをさらに含む実施形態１乃至６のいずれかの方法。
【０１７９】
実施形態８．バッチ化される要求を処理するステップは、バッチ化される要求の名、およびバッチ化される要求の属性のうちの少なくとも１つに基づいて、バッチ化される要求のうちの少なくとも２つの要求で実行するための動作を決定するステップをさらに含む実施形態１乃至７のいずれかの方法。
【０１８０】
実施形態９．バッチ化される要求に関連付けられた属性を、バッチ化される要求の一部である属性、およびバッチ化される要求がアドレスされるアドレスに関連付けられた属性のうちの少なくとも１つに基づいて決定するステップをさらに含む実施形態１乃至８のいずれかの方法。
【０１８１】
実施形態１０．ＡＳＬは、サービス能力レイヤ（ＳＣＬ）である実施形態１乃至９のいずれかの方法。
【０１８２】
実施形態１１．バッチ化される要求のうちの少なくとも１つの要求の動作は、作成、検索、更新、および削除のうちの１つである実施形態１乃至１０のいずれかの方法。
【０１８３】
実施形態１２．エンティティは、アプリケーション、マシンツーマシンアプリケーション、マシンツーマシンデバイス、および別のＡＳＬのうちの１つである実施形態１乃至１１のいずれかの方法。
【０１８４】
実施形態１３．バッチ化される要求を処理するステップは、バッチ化される要求を第２のＡＳＬに送るステップと、バッチ化される要求への応答を第２のＡＳＬから受信するステップとを含み、応答を送るステップは、バッチ化される要求への受信した応答をエンティティに送るステップを含む実施形態１乃至１２のいずれかの方法。
【０１８５】
実施形態１４．サービスをサポートするコンピュータシステムであって、
エンティティから受信されバッチ化される要求を処理し、およびバッチ化される要求への応答をエンティティに送るように構成されたアプリケーションサービスレイヤ（ＡＳＬ）
を備えるコンピュータシステム。
【０１８６】
実施形態１５．ＡＳＬは、バッチ化される要求において示され各要求への個別の応答をエンティティに送るようにさらに構成される実施形態１４のコンピュータシステム。
【０１８７】
実施形態１６．ＡＳＬは、バッチ化される要求において示された各要求を処理するようにさらに構成される実施形態１４または１５のコンピュータシステム。
【０１８８】
実施形態１７．バッチ化される要求のうちの少なくとも２つに対して、バッチ化される要求のうちの少なくとも２つの動作は、同一の動作であり、動作は、バッチ化される要求のうちの少なくとも２つに対して１回指定されるのみである実施形態１４乃至１６のいずれかのコンピュータシステム。
【０１８９】
実施形態１８．ＡＳＬは、各動作の処理から受信された、エンティティへの応答をバッチ化し、およびバッチ化された応答をエンティティに送るようにさらに構成される実施形態１４乃至１７のいずれかのコンピュータシステム。
【０１９０】
実施形態１９．ＡＳＬは、バッチ化される要求が、バッチ化される要求の名、バッチ化される要求に関連付けられた属性、およびバッチ化される要求がアドレスされるアドレスのうちの少なくとも１つに基づいてバッチ化されることを決定するようにさらに構成される実施形態１４乃至１８のいずれかのコンピュータシステム。
【０１９１】
実施形態２０．ＡＳＬは、サービス能力レイヤ（ＳＣＬ）である実施形態１４乃至１９のいずれかのコンピュータシステム。
【０１９２】
実施形態２１．バッチ化される要求のうちの少なくとも１つの要求の動作は、作成、検索、更新、および削除のうちの１つである実施形態１４乃至２０のいずれかのコンピュータシステム。
【０１９３】
実施形態２２．エンティティは、アプリケーション、マシンツーマシンアプリケーション、マシンツーマシンデバイス、および別のＡＳＬのうちの１つである実施形態１４乃至２１のいずれかのコンピュータシステム。
【０１９４】
実施形態２３．ＡＳＬは、バッチ化される要求を、バッチ化される要求を第２のＡＳＬに送り、およびバッチ化される要求への応答を第２のＡＳＬから受信することにより処理するようにさらに構成され、ならびにＡＳＬは、バッチ化される要求への受信された応答をエンティティに送るようにさらに構成される実施形態１４乃至２２のいずれかのコンピュータシステム。
【図１Ａ】
0006473697.tif 000019
【図１Ｂ】
0006473697.tif 000020
【図１Ｃ】
0006473697.tif 000021
【図２】
0006473697.tif 000022
【図３】
0006473697.tif 000023
【図４Ａ】
0006473697.tif 000024
【図４Ｂ】
0006473697.tif 000025
【図５】
0006473697.tif 000026
【図６】
0006473697.tif 000027
【図７】
0006473697.tif 000028
【図８】
0006473697.tif 000029
【図９】
0006473697.tif 000030
【図１０】
0006473697.tif 000031
【図１１Ａ】
0006473697.tif 000032
【図１１Ｂ】
0006473697.tif 000033
【図１１Ｃ】
0006473697.tif 000034
【図１２】
0006473697.tif 000035
【図１３Ａ】
0006473697.tif 000036
【図１３Ｂ】
0006473697.tif 000037
【図１４】
0006473697.tif 000038
【図１５】
0006473697.tif 000039
【図１６】
0006473697.tif 000040
【図１７】
0006473697.tif 000041
【図１８】
0006473697.tif 000042