(57)【特許請求の範囲】
【請求項１】
端末機器に接続するデータ通信装置であって、
少なくとも１つのサービスメッセージを発生するための少なくとも１つのサービスエンティティ、ここにおいて、前記少なくとも１つのサービスメッセージは第１のパラメータを具備し、前記第１のパラメータは、
前記第１のパラメータのタイプを識別する第１のタイプフィールドと、
前記第１のタイプフィールドにおいて識別されたタイプに関連する値を指定する第１の値フィールドと、
前記第１の値フィールドの長さを指定する第１のレングスフィールドと、
を具備する、
ここにおいて、前記第１の値フィールドは第２のパラメータを具備し、前記第２のパラメータは、前記第２のパラメータのタイプに関連する値を指定する少なくとも第２の値フィールドを具備する、
マルチプレクッスメッセージを発生するためのマルチプレックスモジュール、前記マルチプレクッスメッセージは：
前記少なくとも１つのサービスメッセージ；
前記少なくとも１つのサービスメッセージに関連する少なくとも１つの制御ポイントを識別するためのクライアントＩＤフィールド；
前記少なくとも１つのサービスメッセージに関連する前記少なくとも１つのサービスエンティティを識別するためのサービスタイプフィールド；
を具備する、
未使用のクライアントＩＤ値が利用可能である場合、前記クライアントＩＤフィールドに関するクライアントＩＤ値を前記接続された端末機器上の制御ポイントに割り当て、前記接続された端末機器上の前記制御ポイントがもはや前記少なくとも１つのサービスエンティティと通信する必要が無い場合、前記割り当てられたクライアントＩＤ値をリリースし、前記接続された端末機器のサービスメッセージバージョンを取得するための制御サービスモジュール
を具備する、データ通信装置。
【請求項２】
前記クライアントＩＤフィールド内の前記クライアントＩＤ値は、前記少なくとも１つのサービスメッセージに関連するすべての制御ポイントを識別する、請求項１のデータ通信装置。
【請求項３】
前記クライアントＩＤ値は、前記少なくとも１つのサービスメッセージに関連するすべての制御ポイントを識別するために特定の値に設定される、請求項１のデータ通信装置。
【請求項４】
前記データ通信装置上に複数の前記少なくとも１つのサービスエンティティをさらに備える、請求項１のデータ通信装置。
【請求項５】
前記少なくとも１つのサービスメッセージはさらに応答メッセージを備え、前記マルチプレックスメッセージはさらに、前記マルチプレックスメッセージが前記応答メッセージを備えることを識別するためのメッセージタイプフィールドを備える、請求項１のデータ通信装置。
【請求項６】
前記マルチプレックスメッセージは、前記マルチプレクッスメッセージが表示メッセージを備えることを識別するメッセージタイプフィールドをさらに備える、請求項１のデータ通信装置。
【請求項７】
前記マルチプレックスモジュールはさらに、少なくとも１つの受信されたサービスメッセージと、
前記少なくとも１つの受信されたサービスメッセージに関連する制御ポイントを識別するクライアントＩＤを記憶するクライアントＩＤフィールドと、
前記少なくとも１つの受信されたサービスメッセージに関連する前記サービスエンティティを識別するサービスタイプを記憶するサービスタイプフィールドとを備えたマルチプレックスメッセージを受信するようにさらに構成され、
前記少なくとも１つのサービスエンティティは、前記マルチプレクッスモジュールから前記少なくとも１つの受信されたサービスメッセージを受信するようにさらに構成される、請求項１のデータ通信装置。
【請求項８】
前記少なくとも１つのサービスエンティティは、前記マルチプレックスモジュールから複数の受信されたサービスメッセージを受信する前記少なくとも１つのサービスエンティティに応答して複数のサービスメッセージを発生するようにさらに構成され、前記マルチプレックスモジュールは前記発生された複数のサービスメッセージを備えたマルチプレックスメッセージを発生するようにさらに構成される、請求項７のデータ通信装置。
【請求項９】
前記複数の受信されたサービスメッセージに応答して発生された前記複数のサービスメッセージは、前記複数の受信されたサービスメッセージの受信順序に従って順序付けられる、請求項８のデータ通信装置。
【請求項１０】
前記少なくとも１つのサービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答してエラーサービスメッセージを発生するように構成される、請求項９のデータ通信装置。
【請求項１１】
前記少なくとも１つのサービスエンティティは、複数の制御ポイントの中の衝突を解決するための共有状態変数を維持するように構成される、請求項７のデータ通信装置。
【請求項１２】
前記少なくとも１つのサービスエンティティは、複数の制御ポイントの各１つのための一意的な状態変数を維持するように構成される、請求項７のデータ通信装置。
【請求項１３】
前記データ通信装置は、無線エアーインターフェースを介して通信するように構成される、請求項１のデータ通信装置。
【請求項１４】
前記少なくとも１つのサービスエンティティは装置管理サービスエンティティである、請求項１のデータ通信装置。
【請求項１５】
前記少なくとも１つのサービスエンティティは無線データサービスエンティティである、請求項１のデータ通信装置。
【請求項１６】
前記少なくとも１つのサービスエンティティはネットワークアクセスサービスエンティティである、請求項１のデータ通信装置。
【請求項１７】
前記少なくとも１つのサービスエンティティはロケーションベースサービスエンティティである、請求項１のデータ通信装置。
【請求項１８】
前記少なくとも１つの受信されたサービスメッセージの各々は、下記を具備する請求項７のデータ通信装置：
前記少なくとも１つの受信されたサービスメッセージを識別するためのメッセージＩＤフィールド；
前記少なくとも１つの受信されたサービスメッセージの一部の長さを指定するためのメッセージレングスフィールド；
メッセージ値フィールド。
【請求項１９】
前記少なくとも１つの受信されたサービスメッセージの前記メッセージ値フィールドは、下記を具備する第１のタイプレングス値（ＴＬＶ）フィールドを備えた請求項１８のデータ通信装置：
前記第１のＴＬＶのタイプを識別するための第１のＴＬＶタイプフィールド；
前記第１のＴＬＶタイプに関連する値を指定するための第１のＴＬＶ値フィールド；
前記第１のＴＬＶ値フィールドのレングスを指定するための第１のＴＬＶレングスフィールド。
【請求項２０】
前記第１のＴＬＶは、前記少なくとも１つの受信されたサービスメッセージのための必須のＴＬＶである、請求項１９のデータ通信装置。
【請求項２１】
前記第１のＴＬＶ値フィールドは複数の値フィールドを備える、請求項２０のデータ通信装置。
【請求項２２】
前記少なくとも１つの受信されたサービスメッセージの前記メッセージ値フィールドはさらなるＴＬＶをさらに備える、請求項１９のデータ通信装置。
【請求項２３】
前記さらなるＴＬＶはオプションＴＬＶを備える、請求項２２のデータ通信装置。
【請求項２４】
前記オプションＴＬＶは、前記少なくとも１つの受信されたサービスメッセージを暗号化するための少なくとも１つの暗号化パラメーターを備える、請求項２３のデータ通信装置。
【請求項２５】
前記オプションＴＬＶは、前記少なくとも１つの受信されたサービスメッセージを認証するための少なくとも１つの認証パラメーターを備える、請求項２３のデータ通信装置。
【請求項２６】
前記オプションＴＬＶは前記少なくとも１つの受信されたサービスメッセージの前記完全性を検証するための少なくとも１つの完全性保護パラメーターを備える、請求項２３のデータ通信装置。
【請求項２７】
前記少なくとも１つのサービスエンティティは、前記少なくとも１つのサービスエンティティによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージ内の認識されないオプションＴＬＶをスキップするように構成される、請求項１１のデータ通信装置。
【請求項２８】
前記少なくとも１つのサービスエンティティは、前記少なくとも１つのサービスエンティティによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する認識されない受信されたサービスメッセージを受信することに応答して、前記認識されない受信されたサービスメッセージを無視するように構成される、請求項７のデータ通信装置。
【請求項２９】
前記少なくとも１つのサービスエンティティは、前記少なくとも１つのサービスエンティティによりサポートされるよりもより低い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージのサービスバージョンと同じかまたは低いサービスバージョンを有するサービスメッセージのみを発生するように構成される、請求項７のデータ通信装置。
【請求項３０】
前記少なくとも１つのサービスエンティティは認識されない受信されたサービスメッセージを受信することに応答して前記認識されない受信されたサービスメッセージをリジェクトするように構成される、請求項７のデータ通信装置。
【請求項３１】
前記少なくとも１つのサービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答して、前記認識されない受信されたサービスメッセージを無視するように構成される、請求項７のデータ通信装置。
【請求項３２】
前記マルチプレックスメッセージは、前記マルチプレックスメッセージに関連するトランザクションＩＤを記憶するためのトランザクションＩＤフィールドをさらに備える、請求項１のデータ通信装置。
【請求項３３】
データチャネルを提供するための論理装置ドライバーと、前記マルチプレックスメッセージのための制御チャネルであって前記データチャネルとは独立した制御チャネルをさらに備えた、請求項１のデータ通信装置。
【請求項３４】
前記論理装置ドライバーはユニバーサルシリアルバス（ＵＳＢ）で動作するように構成される、請求項３３のデータ通信装置。
【請求項３５】
前記端末機器はパーソナルコンピューターである、請求項１のデータ通信装置。
【請求項３６】
前記マルチプレックスメッセージはさらに前記少なくとも１つの制御ポイントが制御ポイントかまたはサービスエンティティかを示す制御フラッグフィールドをさらに備える、請求項１のデータ通信装置。
【請求項３７】
前記装置は、前記少なくとも１つのサービスエンティティにより発生されたサービスメッセージを備えた非マルチプレックスメッセージを発生するようにさらに構成される、請求項１のデータ通信装置。
【請求項３８】
前記少なくとも１つのサービスメッセージはＡＴコマンドメッセージを備える、請求項１のデータ通信装置。
【請求項３９】
データ通信装置を端末機器にインターフェースするための方法において、
前記データ通信装置に、または前記データ通信装置から少なくとも１つのサービスメッセージを供給することと、
ここにおいて、前記少なくとも１つのサービスメッセージは第１のパラメータを具備し、
前記第１のパラメータは、
前記第１のパラメータのタイプを識別する第１のタイプフィールドと、
前記第１のタイプフィールドにおいて識別された前記タイプに関連した値を指定する第１の値フィールドと、
前記第１の値フィールドの長さを指定する第１のレングスフィールドと、
を具備し、
前記第１の値フィールドは、第２のパラメータのタイプに関連した値を指定する少なくとも第２の値フィールドを含む第２のパラメータを具備する、
マルチプレックスメッセージを発生することと、ここにおいて、前記マルチプレックスメッセージは、
前記少なくとも１つのサービスメッセージと、
前記少なくとも１つのサービスメッセージに関連した制御ポイントを識別するクライアントＩＤフィールドと、
前記少なくとも１つのサービスメッセージに関連したサービスエンティティを識別するサービスタイプフィールドと、
を具備し、
未使用のクライアントＩＤ値が利用可能である場合、前記データ通信装置と関連した制御サービスモジュールによって、前記クライアントＩＤフィールドに関するクライアントＩＤ値を前記端末機器上の制御ポイントに割り当てることと、
前記端末機器上の前記制御ポイントがもはや前記サービスエンティティと通信する必要が無い場合、前記割り当てられたクライアントＩＤ値をリリースすることと、
前記端末機器のサービスメッセージバージョンを取得することと、
を具備する方法。
【請求項４０】
前記マルチプレックスメッセージは、前記少なくとも１つのサービスメッセージのメッセージのメッセージタイプを識別するためのメッセージタイプフィールドをさらに具備する、請求項３９の方法。
【請求項４１】
前記メッセージタイプは要求メッセージタイプである、請求項４０の方法。
【請求項４２】
受信されたマルチプレックスメッセージを逆多重化することをさらに具備し、前記受信されたマルチプレックスメッセージは下記を具備する、請求項３９の方法： 
少なくとも１つの受信されたサービスメッセージ；
前記少なくとも１つの受信されたサービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤ値を記憶するためのクライアントＩＤフィールド；
前記少なくとも１つの受信されたサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプを記憶するサービスタイプフィールド。
【請求項４３】
複数の逆多重化された要求サービスメッセージの各々に対して、関連した応答サービスメッセージを供給することをさらに具備する、請求項４２の方法。
【請求項４４】
対応する逆多重化された要求サービスメッセージが受信された順番に各関連した応答サービスメッセージを多重化することをさらに具備する、請求項４３の方法。
【請求項４５】
認識されない受信された要求サービスメッセージに関連するエラー応答サービスメッセージを発生することをさらに具備する、請求項４３の方法。
【請求項４６】
前記マルチプレックスメッセージは、前記マルチプレックスメッセージに関連したトランザクションＩＤを記憶するトランザクションＩＤフィールドをさらに備える、請求項４２の方法。
【請求項４７】
マルチプレックスメッセージが発生されるごとに前記トランザクションＩＤをインクリメントすることをさらに具備する、請求項４６の方法。
【請求項４８】
前記マルチプレクッスメッセージのための独立制御チャネル、および独立データチャネルを供給することをさらに具備する、請求項３９の方法。
【請求項４９】
認識されない受信されたサービスメッセージをスキップすることをさらに具備する、請求項４２の方法。
【請求項５０】
前記スキップすることは、認識されないサービスメッセージを受信することに応答する、請求項４９の方法。
【請求項５１】
前記少なくとも１つの受信されたサービスメッセージの同じまたは低いサービスバージョンを有するサービスメッセージのみを発生することをさらに具備する、請求項４２の方法。
【請求項５２】
前記少なくとも１つのサービスメッセージは下記を具備する、請求項３９の方法：
前記少なくとも１つのサービスメッセージを識別するためのメッセージＩＤフィールド；
前記少なくとも１つのサービスメッセージの一部の長さを指定するためのメッセージレングスフィールド；
メッセージ値フィールド。
【請求項５３】
前記少なくとも１つの受信されたサービスメッセージは、
前記少なくとも１つの受信されたサービスメッセージを識別するメッセージＩＤフィールドと、
前記少なくとも１つの受信されたサービスメッセージの一部の長さを指定するメッセージレングスフィールドと、
メッセージ値フィールドと、
を具備する、請求項４２の方法。
【請求項５４】
前記少なくとも１つの受信されたサービスメッセージの前記メッセージ値フィールドは、第１のタイプのタイプレングス値（ＴＬＶ）フィールドを具備し、前記ＴＬＶフィールドは、
前記第１のＴＬＶのタイプを識別する第１のＴＬＶタイプフィールドと、
前記第１のＴＬＶタイプに関連した値を指定する第１のＴＬＶ値フィールドと、
前記第１のＴＬＶ値フィールドの長さを指定する第１のＴＬＶ長さフィールドと、
を具備する、請求項５３の方法。
【請求項５５】
前記第１のＴＬＶは、前記少なくとも１つのサービスメッセージに関する必須のＴＬＶである、請求項５４の方法。
【請求項５６】
前記第１のＴＬＶ値フィールドは、複数の値フィールドを具備する、請求項５５の方法。
【請求項５７】
前記少なくとも１つの受信されたサービスメッセージの前記メッセージ値フィールドは、さらなるＴＬＶを具備する、請求項５４の方法。
【請求項５８】
前記さらなるＴＬＶはオプションのＴＬＶを具備する、請求項５７の方法。
【請求項５９】
前記オプションのＴＬＶは、前記少なくとも１つの受信されたサービスメッセージを暗号化する少なくとも１つの暗号パラメータを具備する、請求項５８の方法。
【請求項６０】
前記オプションＴＬＶは、前記少なくとも１つの受信されたサービスメッセージを認証する少なくとも１つの認証パラメータを具備する、請求項５８の方法。
【請求項６１】
前記オプションＴＬＶは、前記少なくとも１つの受信されたサービスメッセージの完全性を検証する少なくとも１つの完全性保護パラメータを具備する、請求項５８の方法。
【請求項６２】
前記サービスエンティティは、前記サービスエンティティによりサポートされるよりも高い比較的重要でないサービスバージョン(minor service version)を有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージ内の認識されないオプションのＴＬＶをスキップするように構成される、請求項４２の方法。
【請求項６３】
前記サービスエンティティは、前記少なくとも１つのサービスエンティティによりサポートされるよりも高い比較的重要でないサービスバージョンを有する認識されない受信されたサービスメッセージを受信することに応答して、前記認識されない受信されたサービスメッセージを無視するように構成される、請求項４２の方法。
【請求項６４】
前記サービスエンティティは、前記少なくとも１つのサービスエンティティによりサポートされるよりも低い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージのサービスバージョンと同じかまたは低いサービスバージョンを有するサービスメッセージのみを発生するように構成される、請求項４２の方法。
【請求項６５】
前記サービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答して、前記認識されない受信されたサービスメッセージをリジェクトするように構成される、請求項４２の方法。
【請求項６６】
前記サービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答して、前記認識されない受信されたサービスメッセージを無視するように構成される、請求項４２の方法。
【請求項６７】
データ通信装置を端末機器にインターフェースする装置において、
前記データ通信装置に、または前記データ通信装置から少なくとも１つのサービスメッセージを供給する手段と、ここにおいて、前記少なくとも１つのサービスメッセージは、第１のパラメータを具備し、前記第１のパラメータは、
前記第１のパラメータのタイプを識別する第１のタイプフィールドと、       
前記第１のタイプフィールド内で識別されたタイプに関連する値を指定する第１の値フィールドと、
前記第１の値フィールドの長さを指定する第１のレングスフィールドと、
を具備し、
前記第１の値フィールドは、第２のパラメータを具備し、前記第２のパラメータは、前記第２のパラメータのタイプに関連する値を指定する少なくとも第２の値フィールドを具備する、
マルチプレックスメッセージを発生する手段、ここにおいて、前記マルチプレックスメッセージは、
前記少なくとも１つのサービスメッセージと、
前記少なくとも１つのサービスメッセージに関連する制御ポイントを指定するクライアントＩＤフィールドと、
前記少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するサービスタイプフィールドと、
を具備し、
未使用のクライアントＩＤ値が利用可能である場合、前記データ通信装置と関連する制御サービスモジュールによって、前記クライアントＩＤフィールドに関するクライアントＩＤ値を前記端末機器上の制御ポイントに割り当て、前記端末機器上の前記制御ポイントがもはや前記サービスエンティティと通信する必要が無い場合、前記割り当てられたクライアントＩＤ値をリリースし、前記端末機器のサービスメッセージバージョンを取得する手段、
を具備する、装置。
【請求項６８】
データ通信装置を端末機器にインターフェースするコンピュータプログラム製品であって、前記コンピュータプログラム製品は、非トランジトリなコンピュータ読み取り可能記録媒体を具備し、前記コンピュータ読み取り可能記録媒体は、
コンピュータに、前記データ通信装置に、または前記データ通信装置から少なくとも１つのサービスメッセージを供給させるコードの第１のセットと、ここにおいて、前記少なくとも１つのサービスメッセージは、第１のパラメータを具備し、前記第１のパラメータは、
前記第１のパラメータのタイプを識別する第１のタイプフィールドと、
前記第１のタイプフィールドにおいて識別された前記タイプに関連する値を指定する第１の値フィールドと、
前記第１の値フィールドの長さを指定する第１のレングスフィールドと、
を具備し、
前記第１の値フィールドは、第２のパラメータを具備し、前記第２のパラメータは、
前記第２のパラメータのタイプに関連する値を指定する少なくとも第２の値フィールドを具備する、
前記コンピュータに、マルチプレックスメッセージを発生させるコードの第２のセットと、ここにおいて、前記マルチプレックスメッセージは、
前記少なくとも１つのサービスメッセージと、
前記少なくとも１つのサービスメッセージに関連する制御ポイントを識別するクライアントＩＤフィールドと、
前記少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するサービスタイプフィールドと、
を具備し、
前記データ通信装置に関連する制御サービスモジュールに、未使用のクライアントＩＤ値が利用可能である場合、前記クライアントＩＤフィールドに関するクライアントＩＤ値を前記端末機器上の制御ポイントに割り当てさせ、前記端末機器上の前記制御ポイントがもはや前記サービスエンティティと通信する必要が無い場合、前記割り当てられたクライアントＩＤ値をリリースさせ、前記端末機器のサービスメッセージバージョンを取得させるコードの第３のセットと、
を具備する、コンピュータプログラム製品。
【請求項６９】
端末機器にインターフェースする、データ通信装置における少なくとも１つのプロセッサにおいて、前記少なくとも１つのプロセッサは、
前記データ通信装置に、または前記データ通信装置から少なくとも１つのサービスメッセージを供給する第１のハードウエアモジュールと、ここにおいて、前記少なくとも１つのサービスメッセージは、第１のパラメータを具備し、前記第１のパラメータは、
前記第１のパラメータのタイプを識別する第１のタイプフィールドと、
前記第１のタイプフィールドで識別されたタイプに関連する値を指定する第１の値フィールドと、
前記第１の値フィールドの長さを指定する第１のレングスフィールドと、
を具備し、
前記第１の値フィールドは、第２のパラメータを具備し、前記第２のパラメータは、前記第２のパラメータのタイプに関連する値を指定する少なくとも第２の値フィールドを具備する、
マルチプレックスメッセージを発生する第２のモジュールと、ここにおいて、前記マルチプレックスメッセージは、
前記少なくとも１つのサービスメッセージと、
前記少なくとも１つのサービスメッセージに関連する制御ポイントを指定するクライアントＩＤフィールドと、
前記少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するサービスタイプフィールドと、
を具備し、
未使用のクライアントＩＤ値が利用可能である場合、前記クライアントＩＤフィールドに関するクライアントＩＤ値を前記端末機器上の制御ポイントに割り当て、前記端末機器上の前記制御ポイントがもはや前記サービスエンティティと通信する必要が無い場合、前記割り当てられたクライアントＩＤ値をリリースし、前記端末機器のサービスメッセージバージョンを取得する第３のモジュールと、
を具備する、少なくとも１つのプロセッサ。
【請求項７０】
前記少なくとも１つのサービスメッセージは、
前記少なくとも１つのサービスメッセージを識別するメッセージＩＤフィールドと、
前記第１のパラメータを具備する第２の値フィールドと、
前記第２の値フィールドの長さを指定する第２のレングスフィールドと、
をさらに具備する、請求項１のデータ通信装置。
【請求項７１】
前記第２の値フィールドは、複数のパラメータを具備する、請求項７０のデータ通信装置。
【請求項７２】
前記第１の値フィールドは、複数の値フィールドを具備する、請求項１のデータ通信装置。
【請求項７３】
前記第１の値フィールドは、複数の値フィールドと、各々が前記複数の値フィールドのそれぞれ１つの長さを指定する複数のレングスフィールドとを具備する、請求項１のデータ通信装置。
【請求項７４】
前記少なくとも１つのサービスメッセージは、
前記少なくとも１つのサービスメッセージを識別するメッセージＩＤフィールドと、
前記第１のパラメータを具備する第２の値フィールドと、
前記第２の値フィールドの長さを指定する第２のレングスフィールドと、
を具備する、請求項３９の方法。
【請求項７５】
前記第２の値フィールドは、複数のパラメータを具備する、請求項７４の方法。
【請求項７６】
前記第１の値フィールドは、複数の値フィールドを備える、請求項３９の方法。
【請求項７７】
前記第１の値フィールドは、複数の値フィールドと、各々が前記複数の値フィールドのそれぞれ１つの長さを指定する複数のレングスフィールドとを具備する、請求項３９の方法。
【請求項７８】
前記サービスタイプフィールドは、前記少なくとも１つのサービスメッセージ内に含まれない、請求項１のデータ通信装置。
【請求項７９】
前記サービスタイプフィールドは、前記少なくとも１つのサービスメッセージ内に含まれない、請求項３９の方法。
【請求項８０】
前記クライアントＩＤフィールドによって識別される前記少なくとも１つの制御ポイントは、アプリケーション、アプリケーションクライアント、ドライバー、カーネルモジュール、またはライブラリである、請求項１のデータ通信装置。
【請求項８１】
前記クライアントＩＤフィールドによって識別される前記少なくとも１つの制御ポイントは、アプリケーション、アプリケーションクライアント、ドライバー、カーネルモジュール、またはライブラリである、請求項３９の方法。
【請求項８２】
コンピュータに、請求項３９−６６の１つに従って前記方法を実行させるプログラム。
【請求項８３】
プログラムが記録されたコンピュータ読み取り可能記録装置であって、前記プログラムがコンピュータに、請求項３９−６６の１つに従って前記方法を実行させる、コンピュータ読み取り可能記録装置。
【発明の詳細な説明】
【関連技術】
【０００１】
３５Ｕ．Ｓ．Ｃ．§１１９の下の優先権主張
この特許出願は、本明細書の譲受人に譲渡され参照することにより本明細書に明示的に組み込まれる、２００５年８月８日に出願した仮出願シリアル番号６０／７０６，７１１の優先権を主張する。
【技術分野】
【０００２】
この発明はデジタル電子装置におけるデータ処理に関し、特に、一人以上のアプリケーションクライアントと１つ以上のサービスエンティティとの間のメッセージの通信に関する。
【背景技術】
【０００３】
パーソナルコンピューター、ラップトップ、およびパーソナルデジタルアシスタントのような現代の計算装置は、ＩＥＥＥ８０２．１１、符号分割多元接続（ＣＤＭＡ）、ジェネラルパケットラジオサービス（ＧＰＲＳ）、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）のようなインターフェースを介して計算装置を通信可能にするモデムのようなデータ通信装置にしばしば拘束される。計算装置上で動作するオペレーティングシステムは、データを送信および受信するためにデータ通信装置により供給される通信能力を使用する接続マネージャークライアントのようなソフトウエアアプリケーションクライアントを典型的にサポートする。データ通信装置自体は、ネットワークシステムステータスをアクセスするためのネットワークアクセスサービス、無線リンクを介してデータを送信および受信する無線データサービス、装置識別および電力レベルステータスをアクセスするための装置管理サービスのような、計算装置上で動作するソフトウエアアプリケーションに多数のサービスを供給してもよい。
【０００４】
物理層において、計算装置とデータ通信装置との間の通信は、ＵＳＢ、ＲＳ−２３２、ＰＣＩおよびＰＣＭＣＩＡを含むシリアルバスまたはブルートゥース(Bluetooth)（登録商標）およびＩＥＥＥ８０２．１１を含む無線インターフェースのような物理相互接続を介して行うことができる。計算装置上で動作するアプリケーションクライアントとデータ通信装置上で動作するサービスとの間の上位層通信、すなわち、クライアントーサービスインターフェースの場合、従来技術で利用されていたプロトコルは、Ｗ−ＣＤＭＡ３ＧＰＰ端末（ユーザー機器のためのＡＴコマンドセット、リリース１９９９、３ＧＰＰＴＳ２７．００７  Ｖ３．１３．０（２００３）のためのＡＴコマンド参照）およびＣＤＭＡ３ＧＰＰ２端末（スペクトル拡散システムのためのデータサービスオプション：ＡＴコマンド処理およびＲｍインターフェース、３ＧＰＰ２  Ｃ．Ｓ００１７−００３−Ａ）、リモートネットワークドライバーインターフェース仕様（ＲＮＤＩＳ）およびユニバーサルプラグアンドプレイ（ＵＰｎＰ）のために仕様が定められたＡＴコマンドセットを含む。
【０００５】
最近、計算装置は増えつつある通信アプリケーションをサポートしており、一方データ通信装置は、次第に複数の通信技術をサポートすることができるようになってきている。例えば、ラップトップコンピューターは、ウエブブラウザ、ｅメール、およびブルートゥース、ＩＥＥＥ８０２．１１、およびＣＤＭＡをサポートするモデムを用いたカレンダーシンクロナイゼーション(calendar synchronization)のような通信アプリケーションを実行してもよい。このタイプのシナリオは、従来技術において容易に発見できないあるクライアント−サービスインターフェース特徴の増大する必要性をもたらした。
【発明の概要】
【０００６】
本発明の１つの観点は、少なくとも１つのサービスメッセージを発生する制御モジュールと；前記少なくとも１つのサービスメッセージと、少なくとも１つのサービスメッセージに関連する少なくとも１つの制御ポイントを識別するためのクライアントＩＤフィールドと；少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールドとを備えた多重メッセージを発生するための多重モジュールとを備えた装置を提供する。
【０００７】
本発明の他の観点は、少なくとも１つのサービスメッセージを発生するための制御手段と；共通チャネルを介して複数の制御モジュールにより発生されたサービスメッセージを多重化する多重化手段とを備えた装置を提供する。
【０００８】
本発明のさらに他の観点は、複数の装置をインターフェースするための方法を提供する。前記方法は、少なくとも１つのサービスメッセージを供給することと；少なくとも１つのサービスメッセージと、少なくとも１つのサービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤフィールドと、少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールドを備えた多重メッセージを発生することとを備える。
【図面の簡単な説明】
【０００９】
【図１】図１は、本発明の一実施形態に従う装置間の通信のために採用することができる階層化メッセージングアーキテクチャを示す。
【図２】図２は、本発明の一実施形態に従うサービスエンティティの使用を要求する個々の制御ポイントにクライアントＩＤを割り当てるためのデータ通信装置のための手続を記載する。
【図３】図３は、本発明の一実施形態に従うサービスメッセージのための好適メッセージフォーマットを示す。
【図４】図４は、本発明の一実施形態に従う図１に記載された階層化メッセージングアーキテクチャに使用されてもよいペイロードフォーマットの一実施形態を示す。
【図５】図５は、本発明の一実施形態に従う、多重メッセージを備えた制御チャネルメッセージの一実施形態を示す。
【図６】図６は、本発明の一実施形態に従うセパレートデータチャネルと制御チャネルを備えた本発明の一実施形態を示す。
【図７】図７は、本発明の一実施形態に従って複数の装置をインターフェースするための方法を示す。
【発明を実施するための形態】
【００１０】
現代のＴＥ’ｓおよびＤＣＤ’ｓの特徴は、従来技術において容易に見出しえないあるクライアント−サービスインターフェース特徴の増大した必要性をもたらした。例えば、アプリケーションクライアントソフトウエアの実施を容易にするために、データ通信装置により使用される特定の技術と独立したクライアント−サービスインターフェースに対して定義された一連のサービスコマンドを持つことは望ましいであろう。さらに、制御の柔軟性のために、同時のデータおよび制御のセッションをサポートすることができる計算装置とデータ通信装置との間に通信チャネルを持つことが望ましいであろう。さらに、単一または複数の通信装置上で動作する複数のサービスと通信する単一または複数の計算装置上の複数のクライアントを同時にサポートすることができる多重化プロトコルを持つことが望ましいであろう。
【００１１】
図１は端末装置（ＴＥ）１１８上のアプリケーションクライアントとデータ通信装置（ＤＣＤ）１１９上で動作するサービスエンティティとの間の通信のために採用することができる階層化メッセージングアーキテクチャを示す。一実施形態において、データ通信装置は多数の特定用途向け集積回路（ＡＳＩＣｓ）を備えたモデムであってもよい。端末装置は、ＤＣＤ１１９上で動作するサービスエンティティ１１４、１１５と通信するソフトウエアまたはハードウエアアプリケーションクライアントまたは制御ポイント１０１、１０２、１０３として知られるデバイスドライバーをサポートしてもよい。アプリケーションクライアントの例は、コネクションマネージャー、ボイスオーバーＩＰアプリケーション、または通信デバイスドライバーを含む。サービスエンティティの例は、無線リンクを介してデータを送信および受信する無線データサービスエンティティ、ネットワークシステムステータスをアクセスするためのネットワークアクセスサービスエンティティ、およびデバイス識別およびデバイス電力レベルステータスをアクセスするためのデバイス管理サービスエンティティを含む。また、この明細書とクレームにおいて、アプリケーションクライアントおよびサービスエンティティは集合的に制御モジュールと呼んでもよい。
【００１２】
図１に示すように、サービスインターフェース１０７、１０８、１０９を介して制御ポイント１０１、１０２、１０３とサービスエンティティ１１４、１１５との間に送信されたピアツーピアメッセージは、一般にサービスインターフェースメッセージまたはサービスメッセージと呼ぶことができる。各サービスエンティティはサポートされた一連のサービスメッセージとサービスメッセージフォーマットを定義する。一実施形態において、サービスインターフェースメッセージのフォーマットは、この明細書において後に記載される一般化サービステンプレートに従って指定されてもよい。そのようなテンプレートは単一の統合されたインターフェースを用いてＤＣＤによりサポートされる種々のサービスをアプリケーションクライアントが制御可能にする。
【００１３】
一実施形態において、サービスメッセージは、論理制御チャネルを介して制御ポイントとサービスエンティティとの間の上位層のアプリケーションプログラムインターフェース（ＡＰＩ）をカプセル化する制御メッセージであってもよい。そのようなＡＰＩメッセージは各アプリケーションクライアントに対して特有であってもよい。一実施形態において、サービスインターフェースメッセージは、ＡＰＩメッセージをカプセル化する必要はなく、各特定のサービスエンティティに対して別々に定義することができる。
【００１４】
特別のＣＴＬ制御エンティティ１０４およびＣＴＬサービス１１３は、クライアントＩＤをネゴシエートすることおよびＴＥおよび／またはＤＣＤのサービスメッセージバージョンを取得することのような機能のために端末装置１１８およびＤＣＤ１１９上のクライアントまたはドライバーにより使用されてもよい。端末装置１１８上において、ＣＴＬ制御１０４はドライバーの一部としてまたは別個のエンティティとして実施されてもよいことに留意する必要がある。
【００１５】
図２はサービスエンティティの使用を要求する個々の制御ポイントにＤＣＤがクライアントＩＤを割り当てるための手続を記載する。ドライバーは最初にブロック２０１においてクライアントＩＤのための要求をＤＣＤに送信する。ブロック２０２において利用可能な未使用のクライアントＩＤがあるなら、要求されたサービスエンティティのためのハンドラーは、ブロック２０３においてクライアントＩＤを制御ポイントに割り当ててもよい。制御ポイントはドライバー、カーネルモジュール、ライブラリ、またはユーザーアプリケーション内で実施されてもよい。一実施形態において、各ドライバーに１つの制御ポイントがあり各アプリケーションにおいて１つ以上の制御ポイントがある。同じタイプのサービスを使用する複数のドライバーがあるなら、各ドライバーは専用の物理相互接続チャネル、例えば専用ＵＳＢチャネルを介して自身にそのクライアントＩＤ割り当てを送信することができる。利用可能なクライアントＩＤが無いなら、ハンドラーは、ブロック２０４においてすべてのクライアントＩＤがサービスエンティティのために使い果たされたというメッセージをドライバーに送信してもよい。ドライバーがもはやサービスエンティティと通信する必要が無いなら、ドライバーは、リリースクライアントＩＤ要求を送信することによりクライアントＩＤをリリースすることができることに留意する必要がある。
【００１６】
再び図１を参照すると、サービスインターフェース１０７、１０８、１０９を介して送信されたサービスメッセージは、ＴＥ上のＭＵＸモジュール１０５およびＤＣＤ上のＭＵＸモジュール１１６により実施されるように、ＭＵＸ層を介してトランスポートのためにさらにカプセル化されてもよい。ＭＵＸ層（「ＭＵＸ」）は、ユニバーサルシリアルバス（ＵＳＢ）のような単一の物理相互接続を介してサービスインターフェースメッセージの多重化を可能にする。また、ＭＵＸは特定のメッセージを送信したエンティティタイプ（例えば、サービスまたは制御）を識別してもよい。また、各サービスエンティティに対して、ＭＵＸはクライアントＩＤフィールドを指定することにより複数の制御ポイントをサポートしてもよく、従って、複数のクライアントが単一のサービスエンティティを利用することを可能にする。
【００１７】
複数のクライアントを同時にサポートする能力は、サービスが、各制御ポイントに対して別個の通信経路を割り当てることを可能にすることに留意する必要がある。これは、例えば、制御ポイントが認証信任状をサービスエンティティと別個に交換することを可能とし、これにより、サービスがオーソライズされたクライアントに対してのみアクセスすることを可能とし、逆もまた同様である。さらに、サービスは、完全性保護および機密性保護のために各制御ポイントと暗号鍵をネゴシエートすることができる。リソースマネージメントの場合、サービスはまた同時にサービスをアクセスするクライアントの数を追跡し制限することができる。また、サービスは、各クライアントのためのクライアント特定状態情報を追跡し並びに複数のクライアントから受信した要求を調停することができる。上述した特徴の列挙は、複数の同時クライアントをサポートするこの発明の一実施形態の利点のいくつかを例証するように意図されているにすぎないことに留意する必要がある。特徴の列挙は、そのような特徴を有する実施形態のみにこの発明の範囲を限定することを意図していない。
【００１８】
ＭＵＸメッセージは、デバイス層モジュール１０６および１１７により実施されるデバイス層を介したトランスポートのためにさらに処理されてもよい。デバイス層は、ＵＳＢ、ＲＳ−２３２、ＰＣＩ、およびＰＣＭＣＩＡのような物理相互接続を介してまたはブルートゥース、ＩＥＥＥ８０２．１１および共有メモリインターフェースのような無線リンクを介してデバイスインターフェース１１２を駆動する、機能ドライバー（図示せず）、論理デバイス（図示せず）、およびバスドライバー（図示せず）のようなモジュールを含んでいてもよい。一実施形態において、各論理デバイスはまたサービスエンティティと通信するための独立したデータチャネル（図示せず）を備えていてもよい。独立したデータチャネルは、制御チャネルと同時に動作することができる。例えば、データチャネルおよび制御チャネル並びに独立したフロー制御機構および独立したデータ送信スケジュールに対して別個の送信および受信経路キューイングが提供されてもよい。一実施形態において、ユニバーサルシリアルバス（ＵＳＢ）インターフェース上のさらなるエンドポイントペアを利用して別個のデータチャネルおよび制御チャネルが実施される。データチャネルは、ＩＥＥＥ８０２．３イーサネット（登録商標）データリンク層プロトコルのような標準データリンク層プロトコルを採用することができる。データチャネルのためのリンク層フレーミングは物理相互接続ドライバー、例えばＵＳＢドライバー内で実施されてもよい。パケットの終端はゼロレングスＵＳＢフレームにより区切られる。一実施形態において、物理層（例えば、ＵＳＢ）がそのようなＩＰパケットのフレーミングおよび境界検出をサポートすることができるなら、インターネットプロトコル（ＩＰ）パケットはデータチャネルを介して直接送信することができる。特に、物理層フレームサイズは、ＩＰパケット全体を含むように十分な長さでなければならない。一方物理層ドライバーは、正確に１ＩＰパケットを含むようにフレーム境界をマークすることができなければならない。
【００１９】
図６は、別個のデータチャネルおよび制御チャネルを介してＤＣＤ６３０と通信する端末装置６００の一実施形態を示す。アプリケーション１に関連する制御ポイント６０１、アプリケーション２に関連する制御ポイント６０２、アプリケーション３に関連する制御ポイント６０３、アプリケーション４に関連する制御ポイント６０４は、サービスメッセージ６１２、６１３、６１４を発生し受信しているように図示されている。サービスメッセージ６１２、６１３、６１４は、論理装置６１８、６１９へ／から渡される。論理装置６１８は別個のデータチャネル６２１および制御チャネル６２４を提供し、論理装置６１９は別個のデータチャネル６２２および制御チャネル６２５を提供する。ＤＣＤ６３０上で、対応する機能ヒエラルキーが実施されてもよい。例えば、各々が別個のデータチャネルおよび制御チャネルを駆動するための論理装置６４１、６４２、サービスエンティティ６６０、６６１、６６２と通信するためのサービスメッセージング６５０、６５１、６５２が実施されてもよい。
【００２０】
また、端末装置６００は、対応する論理装置６２０、データチャネル６２３、および制御チャネル６２６と共に、カスタムＡＰＩ／サービスフレームワークを介してサービスメッセージを発生し受信するアプリケーション６０５、６０６を含んでいてもよい。そのようなカスタムアプリケーションは、制御ポイント６０１、６０２、６０３、６０４と同じ物理相互接続層を共有してもよいし、またはカスタムアプリケーションは別個の物理相互接続を備えることができる。また、ＤＣＤ６３０上には、対応する論理装置６４３と共にカスタムＡＰＩ／サービスフレームワーク６５３が、サービスエンティティ６６３、６６４と通信するために設けられてもよい。論理装置６１８、６１９、６２０は各々この実施形態において、別個のデータチャネルおよび制御チャネルをサポートするように示されているけれども、他の実施形態において、論理装置は、データと制御の両方をトランスポートするために単一のチャネルのみをサポートしてもよいことに留意する必要がある。
【００２１】
一実施形態において、ＤＣＤは、カリフォルニア州、サンディエゴのQualcomm(r) Inc.から入手可能なモバイルステーションモデム（ＭＳＭ）チップセットであり得、端末装置は、パーソナルコンピューター（ＰＣ）、ノートブックコンピューター、パーソナルデジタルアシスタント（ＰＤＡ）、またはスマートフォンのような装置であり得る。図１および図６に示す実施形態は、例証に過ぎず、この発明の範囲を限定することを意図していない。例えば、通信の終端はＤＣＤおよび端末装置である必要はない。むしろ、ハードウエアまたはソフトウエア内で動作するアプリケーションとサービスとの間の任意の通信はこの発明の技術を採用してもよい。例えば、ＵＳＢケーブルを介してＭＰ３プレーヤーに接続されたパーソナルコンピューター、または、任意の標準のプロセス間通信（ＩＰＣ）機構を介して通信する、異なるプロセッサー上の同じ装置で動作する制御ポイントおよびサービスさえも採用してもよい。さらに、図１および６に明示的に示されるメッセージングプロトコル層を超えるさらなるメッセージングプロトコル層が存在してもよい。例えば、ＭＵＸ層と装置層との間にさらなるトランスポート層が存在してもよい。
【００２２】
上に示したアーキテクチャを容易にするためのメッセージングプロトコルについて記載する。図１を再び参照すると、端末装置１１８上で動作しているアプリケーションを表す制御ポイント１０１は、サービスメッセージを用いてサービスインターフェース１０７を介してＤＣＤ１１９上で動作するサービスエンティティ１１５と通信することができる。一実施形態において、サービスメッセージは３つのタイプの１つであり得る。要求メッセージ、応答メッセージおよび表示メッセージ。特定のメッセージのタイプは、メッセージと一緒に送信される対応するフィールドで示すことができる。
【００２３】
要求メッセージは制御ポイントにより発行され、サービスエンティティにおけるパラメーター値、サービスエンティティからの問い合わせパラメーター値を設定してもよく、または、サービスエンティティにより表示メッセージの発生を構成してもよい。有効な要求は、一般的にサービスエンティティから対応する応答を引き出すであろう。制御ポイントは、新しい要求を送信する前に以前に送信した要求に対する応答を待つ必要は無い。これは、クライアントとサービスとの間の非同期動作を可能にする。
【００２４】
応答メッセージは、受信された要求メッセージに応答してサービスエンティティにより発行される。応答は、要求された動作に応じて、成功、失敗、またはエラーステータスを示す結果コードを含んでいてもよい。要求に関連した他のデータを通信するために応答内にさらなるフィールドが存在していてもよい。
【００２５】
表示メッセージは、要求に応答してまたは制御ポイントによる任意の教唆なしにサービスエンティティにより発行されてもよい。表示はすべての制御ポイントにブロードキャストしてもよいしまたは特定の制御ポイントにユニキャストしてもよい。ブロードキャスト表示は、その状態について並びに任意の関連するユーザーインターフェースの状態について制御ポイントを更新するために、例えばサービスエンティティにより使用されてもよい。他方、ユニキャスト表示は、特に目標とされる制御ポイントに配信されてもよい。ユニキャスト表示を発行するためにイベントがサービスを生じると、サービスは、メッセージ定義内の表示に関連する任意の要求をチェックしてもよく、関連する要求を発行した各制御ポイントにユニキャスト表示を送ってもよい。ユニキャスト表示が関連した要求を有さないなら、サービスはそれにもかかわらず、ユニキャスト表示、例えばクライアントＩＤを無効にするためのメッセージを適切な制御ポイントに発行してもよい。一実施形態において、制御ポイントは、制御ポイントが受信する任意のサポートされていない表示を無視してもよい。
【００２６】
メッセージングプロトコルの１つの観点によれば、単一のクライアントから単一のサービスエンティティへのいくつかのサービスメッセージは、通信リンクを効率的に使用するために１つの送信に一緒に束ねてもよい。束ねられた送信はペイロードの形態であってもよい。これはまた、束ねられた送信に関連した他の制御パラメーターを運んでもよい。一実施形態において、いくつかのサービスメッセージが論理的にユニット、例えば単一のＡＰＩコマンドを実施するのに必要なメッセージのセットまたは周期的に発行されたステータス問い合わせ要求のセットを形成するなら、それらは一緒に束ねられてもよい。一実施形態において、ペイロードは、例えば、メッセージが要求メッセージ、応答メッセージ、または表示メッセージであろうとなかろうと、束ねられたサービスメッセージのメッセージタイプを特定するフィールドを備えていてもよい。他の実施形態において、ペイロードはまた制御ポイントにより発行された各ペイロードに一意的に関連することができるトランザクションＩＤフィールドを指定してもよい。その後、サービスエンティティは同じトランザクションＩＤを要求メッセージに関連する応答メッセージに付加することができる。一実施形態において、制御ポイントは新しい要求メッセージが送信されるたびにトランザクションＩＤをインクリメントする。
【００２７】
一実施形態において、サービスエンティティは束ねられた要求メッセージ内の各要求を処理し、束ねられた要求に受信されたのと同じ順番で単一の束ねられた応答メッセージにすべての対応する応答を戻す。認識されていない要求がバンドル(bundle)に含まれているなら、サービスエンティティは要求に応答して送信されたバンドルにエラーメッセージを含んでいてもよい。束ねられた要求内の要求の長さが不正確に受信されるなら、サービスエンティティは、束ねられた応答内に、認識されていない受信された要求を示す単一のエラーメッセージ応答で束ねられた、間違いを含む要求に先行する任意の成功裏に処理された要求に対するすべての応答を含んでいてもよい。最後に、サービスメッセージが正しく受信されるが、サービスメッセージ内のパラメーターが間違いを含むなら、一般的なエラーメッセージまたはサービスメッセージに特有のエラーメッセージを戻してもよい。
【００２８】
メッセージングプロトコルの多重化観点において、異なるサービスエンティティを対象にした異なる制御ポイントからのペイロード、逆もまた同様は、マルチプレックス(multiplex)メッセージを形成するために、各ペイロードに、関連するクライアントＩＤフィールドおよびサービスタイプフィールドを添付することにより同じ物理相互接続を介して送信することができる。例えば、図１において、サービスインターフェース１０７を介して制御ポイント１０１とサービスエンティティ１１５との間に送信された束ねられたサービスメッセージは、１に設定されたクライアントＩＤと２に設定されたサービスタイプを有していてもよい。同様に、サービスインターフェース１０８を介して制御ポイント１０２とサービスエンティティ１１４との間に送信されたペイロードは、１に設定されたクライアントＩＤと１に設定されたサービスタイプを有していてもよく、一方、サービスインターフェース１０８を介して制御ポイント１０３とサービスエンティティ１１４との間に送信されたペイロードは、２に設定されたクライアントＩＤと１に設定されたサービスタイプセットを有していてもよい。このように、すべてのサービスメッセージは、同じＭＵＸ層を介して送信されてもよい。特に留意する点は、メッセージングプロトコルのこの観点は、各制御ポイントにユニークなクライアントＩＤを割り当てることにより単一のサービスエンティティと、複数の制御ポイントが通信することを可能にする点である。
【００２９】
一実施形態において、制御フィールドはまた、メッセージの発生源が制御ポイントかまたはサービスエンティティかどうかを示す制御フィールドをペイロードに付加してもよい。これは、サービスと制御ポイントが端末装置とＤＣＤの両方に互換的に位置することを可能にする。
【００３０】
クライアントＩＤフィールド、サービスタイプフィールドおよび制御フラッグフィールドのいずれかまたはすべてはプリアンブルまたはポストアンプルとしてペイロードに付加してもよく、または、それらはそのようなロケーションが特定のメッセージに従ってあらかじめ定義されている限り、ペイロード内のどこかに位置していてもよい。メッセージングプロトコルのための送信機の実施は、物理相互接続を介して送信する前にこれらのパラメーターをペイロードに付加してもよい。同様に、受信機実施がメッセージを受信すると、受信機はペイロードからフィールドを取り去り、ペイロードを指定された制御ポイントまたはサービスエンティティに送ってもよい。
【００３１】
一般に、複数の制御ポイントは、上述した多重化スキームを用いて単一のサービスエンティティとインターフェースしてもよい。ＤＣＤ上の共通リソースを共有する複数の制御ポイントの中の可能な衝突を解決するために、サービスエンティティはサービス共有状態変数を維持してもよい。サービスエンティティはポーリング（例えば、要求メッセージおよび応答メッセージ）、および／またはイベントベース表示メッセージを介して状態変数に制御ポイント情報を供給してもよい。代わりの実施形態において、サービスエンティティは各クライアントに割り当てるために、例えばサービスの質（ＱｏＳ）フローを維持するために複数のリソースを割り当てることができる。この場合、各制御ポイントは各制御ポイントに対して別個のサービス状態変数を維持してもよい。
【００３２】
メッセージングプロトコルの他の観点は、制御ポイントとサービスエンティティとの間のサービスメッセージフォーマットバージョンにおける差を処理することを提供する。実際の装置動作間において、制御ポイントによりサポートされるサービスメッセージが、サービスエンティティによりサポートされるサービスメッセージと異なる（すなわち、早いまたは遅い）バージョンである場合が起こる。特に、特定のメッセージフォーマットが以前のメッセージフォーマットと互換性が無くなるようにサービスが変化されると、主要なサービスバージョン差を生じる。主要なバージョンをインクリメントさせるであろう変化は、これに限定されないが、既存のメッセージの意味を変化させること、定義されたメッセージのリストからメッセージを完全に除去すること、メッセージＩＤに関連する必須パラメーターを除去すること、メッセージＩＤに関連する任意のパラメーターの意味を変化させること、任意の必須の意味論をメッセージフォーマットに追加することを含む。
【００３３】
対照的に、同じ主要なバージョンの以前の仕様との下位互換性を破壊せずにサービス仕様が変化されるとき、比較的重要でないバージョンの差を生じる。これは、例えば、新しい特徴がサービスに追加されるとき生じてもよい。比較的重要でないバージョンをインクリメントするであろう変化は、これに限定されないが、新しいメッセージを追加すること、新しいオプションパラメーターを既存のメッセージに追加すること、新しいエラーコードを既存のメッセージに追加すること、既存の値の適用を変化させることなく既存のパラメーターに新しい値を追加することを含む。
【００３４】
サービスエンティティがポール(poll)（要求／応答）メッセージングまたは表示メッセージングを介して、そのバージョンを示すとき、制御ポイントとサービスエンティティとの間のバージョン差を決定してもよい。異なるメッセージフォーマットバージョンを有する制御ポイントとサービスエンティティの相互運用を容易にするために、メッセージングプロトコルはそのようなバージョン差を処理する方法を指定してもよい。一実施形態によれば、制御ポイントは、異なる主要なバージョン番号を利用したサービスエンティティと相互運用しないであろう、逆もまた同様である。しかしながら、制御ポイントは、同じ主要なバージョンを利用するが異なる比較的重要でないバージョンを利用するサービスエンティティと相互運用してもよい。そのような相互運用は以下のように達成してもよい。
【００３５】
制御ポイントの比較的重要でないバージョンがサービスエンティティの比較的重要でないバージョンより大きい（すなわち、新しい）場合には、制御ポイントとサービスエンティティは、ある動作ルールを守る。最初に、制御ポイントはサービスの（より古い）比較的重要でないバージョンを検出し、互換性のあるメッセージおよび／またはパラメーターのみを発行してもよい。サービスエンティティにおいてサポートされていない機能性をトリガーしてもよいより新しい制御メッセージはディスエーブルにしてもよい。例えば、一実施形態において、クライアントにおけるサポートされていないグラフィカルユーザーインターフェースボタンはディスエーブルにしてもよい。第２に、制御ポイントは、サービスの比較的重要でないバージョンを無視してもよく、より新しい要求を盲目的に発行してもよい。次に、サービスエンティティは、認識されていない要求を拒絶し、認識されていないパラメーターを無視するであろう。しかしながら、サービスエンティティがメッセージを認識し、すべての含まれるパラメーターが有効なら、サービスエンティティは要求を実行してもよい。第３に、応答するオプションパラメーターの欠落またはサービスエンティティからの表示メッセージが制御ポイントの適切な動作を中断しないように制御ポイントを構成することができる。また、第４に、サービスからの新しい表示メッセージの欠落が制御ポイントの適切な動作を中断しないように、制御ポイントを構成することができる。
【００３６】
制御ポイントの比較的重要でないバージョンがサービスエンティティの比較的重要でないバージョンより少ない（すなわち、より古い）場合には、制御ポイントとサービスエンティティは、ある他の手続に従って動作することができる。より古い要求を発行する制御ポイントに応答して、サービスエンティティは、より古いパラメーターおよびより新しいパラメーターの両方に応答してもよい。この場合、制御ポイントは単により新しい認識されないパラメーターを無視してもよく、より古いサービスバージョンの下でするであろうより古いパラメーターを処理してもよい。また、制御ポイントは、より高いサービスバージョンである任意の表示メッセージを無視してもよい。
【００３７】
上述した動作ルールは、例えば、単に、サポートされていないメッセージバージョンに対応する認識できないパラメーターまたはフィールドを処理することにより、物理相互接続により導入される破損により、受信されたメッセージが認識できないオプションパラメーターまたはフィールドを含むときはいつでも適用してもよいことに留意する必要がある。
【００３８】
一実施形態において、異なる比較的重要でないサービスバージョンを利用する装置がそれにもかかわらず運用可能であることを保証するために、サービス仕様を定義する際に以下のルールを守ってもよい。第１に、サービスバージョンが指定された後は、必須のパラメーターは追加されたりまたは除去されたりしない。第２にオリジナル値が異なる方法で表されるように、または異なる意味を呈するように、オプションパラメーターは変化されない。
【００３９】
一実施形態において、メッセージングプロトコルに対して定義されたサービスメッセージは、ＤＣＤによりサポートされた複数の技術にわたって共通のコマンドセットを提供してもよい。例えば、すべてのサポートされた技術に対してＤＣＤからの信号強度ステータスを同時に検索するために、"get signal strength"コマンドを発行してもよい。このように、アプリケーションは技術特有のコマンドを発行する必要はなく、アプリケーションソフトウエアの実施を緩和する。共通コマンドセットに加えて、定義されたサービスメッセージはまたさらなる技術特有のコマンド、例えば各データセッションに対して技術特有のプロファイルの構成を可能にするコマンドを含んでいてもよい。一実施形態において、ＤＣＤは、記憶された技術特有のプロファイルのセットを使用してもよいし、または二者択一的に共通コマンドメッセージのみを採用する装置デフォルトプロファイルを使用してもよい。アプリケーションまたはＤＣＤはどのプロファイルを使用するかを決めてもよい。
【００４０】
一実施形態において、メッセージングプロトコルに対して定義されたサービスメッセージは、ＡＴコマンドプロトコルのような他のプロトコルに従って指定されたコマンドとともに使用されてもよい。これは、全体のＭＵＸメッセージは、ＡＴコマンドプロトコルのような他のプロトコルに従って定義されフォーマットされることを示すために、ＭＵＸ層を介して送信されたメッセージのインターフェースタイプフィールドの値を設定することにより達成してもよい。代わりの実施形態において、ＭＵＸフォーマットは保存されてもよいが、サービスタイプフィールドは、対応するペイロードは他のプロトコルに従って定義されたメッセージを運ぶことを示す値に設定されてもよい。これは標準化団体により定義された良く知られたプロトコルであってもよいし、またはあらかじめ定義された独自仕様のプロトコルであってもよい。
【００４１】
以下、サービスインターフェースメッセージおよびＭＵＸ層メッセージに対して使用されてもよいメッセージフォーマットの実施形態について記載する。この開示において記載したメッセージングプロトコルは本明細書に記載された特定のＭＵＸフォーマットを採用する必要は無く、種々の並べ替え、削除、追加、及び／又は開示されたＭＵＸフォーマット内のフィールドの代替ビット長はまた、意図されたメッセージングアーキテクチャおよびプロトコルの範囲内に入る。
【００４２】
図３は図１に示されるサービスインターフェース１０７、１０８、１０９を介して交換されたメッセージのようなサービスメッセージｎのための好適メッセージフォーマットを示す。図３において、バイトで表されたフィールドの長さは、対応するフィールドの上の数字により示される。図示されたフィールド長は好適フィールド長に過ぎず、フィールド長は一般に特定のＭＵＸメッセージフォーマット実施において任意の長さであり得る。好適実施形態において、ＭＵＸメッセージ内のすべてのビットは、「リトルエンディアン」フォーマット、すなわち、最下位ビットを最初に設定するフォーマットで送信してもよい。この明細書において、ビットナンバリングのためのしきたりは、ビット０が最下位ビットであるということである。
【００４３】
各サービスメッセージはタイプレングス値（ＴＬＶ）構造を持つことができる。ＴＬＶ構造は、どのメッセージが送信されるかを識別するメッセージＩＤ３０１と、レングスフィールドのすぐ後に続く値フィールド３０３の長さを指定するレングスフィールド３０２とを備える。一般に、タイプフィールドはＴＬＶ構造においてどのパラメーターが指定されるかの弁別を可能にする。一実施形態において、タイプフィールドの意味は所定のサービスメッセージ内のすべてのＴＬＶパラメーターにわたって一意的であるが、サービスエンティティ内のすべてのメッセージにわたって、またはすべてのサービスエンティティにわたって一意的である必要はない。一実施形態において、値フィールドは別段の定めが無い限り、正のバイナリ値を含む。このように、バイナリデータは、このメッセージフォーマットにより本来的にサポートすることができる。
【００４４】
特別のサービスメッセージに依存して、値フィールド３０３自身はさらに多数のＴＬＶパラメーター３１９および３２０を備えていてもよく、各々は関連するタイプ、レングス、および値を有することに留意する必要がある。値フィールドの内容はさらにより多くのＴＬＶパラメーター等を備えていてもよい。図３に図解される第１のＴＬＶパラメーター３１９は、さらなるレングスサブフィールド３１５、３１７を有する値フィールドを示し、第１のＴＬＶ３１９の値フィールド３０６内の可変長パラメーターをサポートする。値サブフィールド３１４はメッセージ定義において与えられた固定長値なら、関連する長さを必要としなくてもよいことに留意する必要がある。
【００４５】
従って、複数のパラメーターが単一のサービスメッセージ内に含まれていてもよく、タイプ、レングス、および値は各パラメーターに対して明示的に指定されてもよい。ＴＬＶフォーマットは、特定のサービスメッセージの定義がほかのものを指定していない限り、一般にサービスメッセージ内のパラメーターの任意の順序付けを容易にする。この場合、パラメーターが現れる順番はそのタイプを示してもよい。各パラメーターは必須であってもよいし、オプションであってもよい。必須パラメーターは特定のメッセージＩＤのメッセージ内に常に存在するパラメーターであり、一方オプションパラメーターは、特定のメッセージＩＤのメッセージ内に存在していてもよいし存在していなくてもよいパラメーターである。一実施形態において、サービスメッセージ内のオプションパラメーターの欠落はエラーを生じないしまたは制御ポイントまたはサービスエンティティの適切な動作を中断しない。サービスエンティティはメッセージを処理してもよいし、すべての必須のパラメーターが有効である限り、すべての示された行動を実行してもよい。一実施形態において、サービスメッセージ内のすべての必須のパラメーターはすべてのオプションパラメーターの前に配置される。
【００４６】
一実施形態において、オプションＴＬＶの提供はサービスメッセージの選択的暗号化をサポートする能力を可能にする。例えば、ＣＴＬサービスは、イニシャライゼーションの期間に暗号鍵パラメーターをネゴシエートすることができる。一方、暗号化される特定のサービスメッセージは、暗号化されたサービスメッセージの存在を示すオプションＴＬＶを含むことができる。定義によりオプションＴＬＶは、サービスメッセージ毎に供給される必要はないので、これはメッセージ毎に選択的暗号化を可能にする。サービスメッセージは、メッセージの送信者を認証するためにオプションＴＬＶをメッセージに付加することにより、類似の機構を用いて選択的に認証することができる。また、選択的インテグリティ保護は、オプションＴＬＶをメッセージに付加し、例えば、ハッシュ関数を適用する結果をメッセージのビットに付加することによりメッセージが改ざんされていないことを検証することにより実施することができる。
【００４７】
特定のサービスメッセージで運ばれた任意の情報は、任意の数のＴＬＶパラメーターの間で分割されてもよいことに留意する必要がある。一実施形態において、データ構造のすべての論理的に結合されたデータエレメントに対して単一のＴＬＶが使用される。
【００４８】
一実施形態において、サービスメッセージ内の各ＴＬＶのためのタイプフィールドは１バイトの長さである。タイプフィールドの最初の１６の値（すなわち、０ｘ００乃至０ｘ０ｆ）は、同じサービスタイプのすべてのメッセージにわたって共通である予約された意味を有していてもよい。各メッセージに対するオプションＴＬＶおよびさらなるＴＬＶは０ｘ０ｆより大きなタイプフィールド値で始まってもよい。
【００４９】
例えば、対応する値フィールドが必須パラメーターのセットを持っていることを示すためにすべての要求メッセージにおいてタイプ０ｘ０１が使用されてもよい。図３において、第１のＴＬＶパラメーター３１９のタイプフィールド３０４は、０ｘ０１に設定されてもよく、対応する値フィールド３０６はさらに一連のパラメーターを備えていてもよい。それは各々値フィールド３１４、３１６、３１８およびレングスフィールド３１５、３１７により指定されてもよい。メッセージに対して定義された必須のパラメーターが無いなら、それは必須のＴＬＶを省略してもよい。（メッセージＩＤに対して定義されるなら）オプションパラメーターは、必須のＴＬＶに続いてもよい。
【００５０】
一実施形態において、応答タイプメッセージは各々、０ｘ０２に設定されたタイプフィールドを有した結果コードＴＬＶとして知られる必須の第１のＴＬＶを含んでいてもよい。受信された各要求に対して、サービスエンティティは、成功または失敗を示す値フィールドを有した結果コードＴＬＶを戻してもよい。失敗が戻されるなら、エラーステータス値が戻されてもよく、次にメッセージは任意の次の必須のＴＬＶパラメーターを省略してもよい。（そのメッセージＩＤに対して定義されるなら）応答メッセージに対する他の必須のフィールドは、結果コードＴＬＶに続いて０ｘ０１に設定されたタイプを有する必須のＴＬＶ内に含まれてもよい。そうでなければ、応答メッセージは、必須のＴＬＶを省略してもよい。オプションパラメーターは個々のＴＬＶとして必須のＴＬＶに続いてもよい。
【００５１】
一実施形態において、表示タイプメッセージが必須のパラメーターを有するなら、これらのパラメーターは必須ＴＬＶの一部として第１のＴＬＶの値フィールド内に含まれる。タイプフィールドは０ｘ０１に設定される。必須パラメーターが無いなら、表示メッセージは必須のＴＬＶを省略してもよい。任意のオプションパラメーターは個々のＴＬＶとして必須のＴＬＶに続いてもよい。
【００５２】
図４は図１に記載された階層化メッセージングアーキテクチャにおいて使用されてもよいペイロードフォーマットの一実施形態を示す。
【００５３】
一実施形態において、いくつかのサービスメッセージ４０４、４０５、４０６は、図４に示すように単一のペイロードに一緒に束ねられてもよい。ペイロード４０１は一連のサービスメッセージ４０４、４０５、４０６の後に続いて、コントロールフラッグ４０２、トランザクションＩＤ４０３のようなフィールドを備えていてもよい。コントロールフラッグフィールド４０２およびトランザクションＩＤフィールド４０３は集合的に汎用サービスメッセージヘッダー４０７と呼んでもよい。一般に、ペイロードは任意の数のサービスメッセージをサポートするように構成されてもよいことに留意する必要がある。
【００５４】
制御フラッグフィールド４０２は、ペイロードメッセージ内に含まれるサービスメッセージに関連するメッセージタイプ、例えば、要求、応答、または表示を指定してもよい。
【００５５】
トランザクションＩＤフィールド４０３は、送信されたメッセージをインデックスするために、および／または応答メッセージを所定のクライアントＩＤのための対応する要求メッセージと関連づけるために使用することができる数値の識別子である。
【００５６】
以下、図１のＭＵＸ層１０５、１１６のために採用することができる特定のＭＵＸメッセージフォーマットについて記載する。ペイロードは図５に示すように制御チャネルメッセージ内に埋め込まれていてもよい。制御チャネルメッセージ５０１はＭＵＸ  ＭＳＧ５０２およびインターフェースタイプフィールド５０４を備えていてもよい。制御チャネルメッセージ５０１は、どのタイプのＭＵＸフォーマットが使用されているかまたはＭＵＸフォーマットが全く使用されないかどうかを指定するインターフェースタイプフィールド５０４を有していてもよい。インターフェースタイプフィールドは０ｘ０１の１６進値に設定されてもよく、以下のメッセージは、本明細書に記載された好適ＭＵＸフォーマットに従ってフォーマットされることを示してもよい。それは代替フォーマットの使用を示すために別の値に設定されてもよい。このように、他の制御プロトコルとの相互運用を達成することができる。例えば、ＡＴコマンドは、インターフェースタイプフィールド５０４に異なる値を指定することにより制御チャネルメッセージ５０１にカプセル化してもよい。ＭＵＸメッセージ５０２自体は、レングス５０５、制御フラッグ５０６、サービスタイプ５０７、クライアントＩＤ５０８、およびペイロード５０９のようなフィールドを備えていてもよい。レングス５０５、制御フラッグ５０６、サービスタイプ５０７、およびクライアントＩＤ５０８の各フィールドは、集合的にＭＵＸヘッダーフィールド５０３と呼ばれてもよい。
【００５７】
一実施形態において、レングスフィールド５０５は、バイトでＭＵＸメッセージの全長を指定してもよい。他の実施形態において、レングスフィールド５０５は、ペイロードフィールド５０９のみの長さを指定してもよい。
【００５８】
制御フラッグフィールド５０６は関心のある種々の制御パラメーターを指定してもよい。好適実施形態において、制御フラッグフィールド５０６のビット７は、メッセージの送信者がサービス（１に設定されたビット７）か、または制御ポイント（０に設定されたビット７）かを指定してもよい。制御フラッグフィールド５０６内の未使用ビットは、０に設定されてもよい。
【００５９】
サービスタイプフィールド５０７はペイロードフィールド内に存在するメッセージのサービスエンティティタイプを指定してもよい。例えば、ＤＣＤ上の装置マネージメントサービスエンティティへ通信されたまたは装置マネージメントサービスエンティティから通信されたメッセージは値０ｘ０１に設定されたサービスタイプフィールド５０７を有していてもよい。
【００６０】
クライアントＩＤフィールド５０８は、メッセージが関連するアプリケーションクライアントを識別してもよい。好適実施形態において、このフィールドを０ｘｆｆの値に設定することにより、表示メッセージは、サービスタイプフィールド５０７で指定されたサービスタイプを利用するすべての制御ポイントまたはクライアントに、サービスエンティティによりブロードキャストされてもよい。
【００６１】
ペイロードフィールド５０９は、図１の制御ポイント１０１、１０２、１０３とサービスエンティティ１１４、１１５との間で交換される実際のサービスインターフェースメッセージ１０７、１０８、１０９を持っていてもよい。
【００６２】
図７は、ブロック７０１において少なくとも１つのサービスメッセージを供給するステップと、ブロック７０１で発生された少なくとも１つのサービスメッセージを備えたブロック７０２において複数のメッセージを発生するステップと、少なくとも１つのサービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤフィールド７０３と、少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド７０４を備えた、この発明に従う複数の装置をインターフェースするための方法を示す。
【００６３】
本明細書に記載された技術は、ＣＤＭＡおよびＵＭＴＳファミリー技術、８０２．１１、ブルートゥース、等のような種々の技術をサポートするデータ通信装置のために使用されてもよい。また、これらの技術は他の既存のおよび将来の無線ネットワーク技術に使用されてもよい。一般に、この技術は、単一無線ネットワーク技術をサポートする単一モード無線装置および複数の無線ネットワーク技術をサポートする複数モードの無線装置に対して使用されてもよい。
【００６４】
本明細書に記載された技術は種々の手段により実施されてもよい。例えば、これらの技術は、ハードウエア、ソフトウエア、またはそれらの組み合わせ内で実施されてもよい。ハードウエア実施の場合、システム選択をサポートするために使用される処理ユニットは、１つ以上の特定用途向け集積回路（ＡＳＩＣｓ）、デジタルシグナルプロセッサー（ＤＳＰｓ）、デジタルシグナル処理装置（ＤＳＰＤｓ）、プログラマブルロジックデバイス（ＰＬＤｓ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、プロセッサー、コントローラー、マイクロコントローラー、マイクロプロセッサー、本明細書に記載された機能を実行するように設計された他の電子ユニット、またはそれらの組み合わせ内で実施されてもよい。
【００６５】
ソフトウエア実施の場合、システム選択技術は、本明細書に記載した機能を実行するモジュール（例えば、手続、機能等）で実施されてもよい。ソフトウエアコードはメモリユニットに記憶されプロセッサーにより実行されてもよい。メモリユニットはプロセッサー内部またはプロセッサー外部で実施されてもよい。プロセッサー外部で実施される場合、メモリユニットは、技術的に知られた種々の手段を介してプロセッサーに通信可能に接続することができる。
【００６６】
開示された実施形態の上述の記載は、当業者がこの発明を製作または使用可能にするために提供される。これらの実施形態への種々の変更は当業者には容易に明白であり、本明細書で定義される包括的原理は、この発明の範囲から逸脱することなく他の実施形態に適用されてもよい。従って、この発明は、ここに示される実施形態に限定されることを意図したものではなく、ここに開示された原理および新規な特徴と一致する最も広い範囲が許容されるべきである。
以下に他の実施形態を示す。
［１］下記を具備する装置：
少なくとも１つのサービスメッセージを発生するための制御モジュール；
マルチプレクッスメッセージを発生するためのマルチプレックスモジュール、前記マルチプレクッスメッセージは下記を具備する：
前記少なくとも１つのサービスメッセージ；
前記少なくとも１つのサービスメッセージに関連する少なくとも１つの制御ポイントを識別するためのクライアントＩＤフィールド；
前記少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド。
［２］前記クライアントＩＤフィールドは、前記少なくとも１つのサービスメッセージに関連するすべての制御ポイントを識別する、［１］の装置。
［３］前記クライアントＩＤフィールドは、前記少なくとも１つのサービスメッセージに関連するすべての制御ポイントを識別するために特定の値に設定される、［１］の装置。
［４］前記制御モジュールは前記装置上の第１の制御ポイントである、［１］の装置。
［５］前記少なくとも１つのサービスメッセージは要求メッセージを備え、前記マルチプレックスメッセージはさらに、前記マルチプレックスメッセージが要求メッセージを備えることを識別するためのメッセージタイプフィールドを備える、［４］の装置。
［６］前記装置上に複数の制御ポイントをさらに備え、各制御ポイントは、少なくとも１つのサービスメッセージを発生するように構成可能である、［４］の装置。
［７］前記制御モジュールは前記装置上の第１のサービスエンティティである、［１］の装置。
［８］前記装置上に複数のサービスエンティティをさらに備え、各サービスエンティティは、少なくとも１つのサービスメッセージを発生するように構成可能である、［７］の装置。
［９］前記少なくとも１つのサービスメッセージは応答メッセージを備え、前記マルチプレックスメッセージは、前記マルチプレクッスメッセージが応答メッセージを備えることを識別するためのメッセージタイプフィールドをさらに備える、［７］の装置。
［１０］前記少なくとも１つのサービスメッセージは、表示メッセージを備え、前記マルチプレックスメッセージは、前記マルチプレクッスメッセージが表示メッセージを備えることを識別するメッセージタイプフィールドをさらに備える、［７］の装置。
［１１］前記マルチプレックスモジュールはさらに、少なくとも１つの受信されたサービスメッセージと、
前記少なくとも１つの受信されたサービスメッセージに関連する制御ポイントを識別するクライアントＩＤを記憶するクライアントＩＤフィールドと、
前記少なくとも１つの受信されたサービスメッセージに関連するサービスエンティティを識別するサービスタイプを記憶するサービスタイプフィールドとを備えたマルチプレックスメッセージを受信するためにさらに構成可能であり、
前記制御モジュールは、前記マルチプレクッスモジュールから前記少なくとも１つの受信されたサービスメッセージを受信するためにさらに構成可能である、［１］の装置。
［１２］前記制御モジュールはサービスエンティティである、［１１］の装置。
［１３］前記サービスエンティティは、前記マルチプレックスモジュールから複数の受信されたサービスメッセージを受信する前記サービスエンティティに応答して複数のサービスメッセージを発生するようにさらに構成可能であり、前記マルチプレックスモジュールは前記発生された複数のサービスメッセージを備えたマルチプレックスメッセージを発生するようにさらに構成可能である、［１２］の装置。
［１４］前記複数の受信されたサービスメッセージに応答して発生された前記複数のサービスメッセージは、前記複数の受信されたサービスメッセージのシーケンスに従って順序付けられる、［１３］の装置。
［１５］前記サービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答してエラーサービスメッセージを発生するように構成可能である、［１４］の装置。
［１６］前記サービスエンティティは、複数の制御ポイントの中の衝突を解決するための共有状態変数を維持するように構成可能である、［１２］の装置。
［１７］前記サービスエンティティは、複数の制御ポイントの各１つのための一意的な状態変数を維持するように構成可能である、［１２］の装置。
［１８］前記制御モジュールは制御ポイントである、［１１］の装置。
［１９］前記装置は、第２の装置マルチプレックスメッセージを発生するように動作可能な第２の装置にさらに接続され、前記第２の装置は： 
少なくとも１つの第２の装置サービスメッセージを発生するためのサービスエンティティと；
下記を具備する第２の装置マルチプレクッスメッセージを発生するための第２の装置マルチプレックスモジュールと：
前記サービスエンティティにより発生された前記少なくとも１つの第２の装置サービスメッセージと；
前記サービスエンティティにより発生された前記少なくとも１つの第２の装置サービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤフィールドと；
前記サービスエンティティにより発生された前記少なくとも１つの第２の装置サービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールドと；
を備えた［１８］の装置。
［２０］前記第２の装置はデータ通信装置である、［１９］の装置。
［２１］前記データ通信装置は、無線エアーインターフェースを介して通信するように動作可能である、［２０］の装置。
［２２］前記サービスエンティティは装置管理サービスエンティティである、［１９］の装置。
［２３］前記サービスエンティティは無線データサービスエンティティである、［１９］の装置。
［２４］前記サービスエンティティはネットワークアクセスサービスエンティティである、［１９］の装置。
［２５］前記サービスエンティティはロケーションベースサービスエンティティである、［１９］の装置。
［２６］前記制御モジュールは前記クライアントＩＤに関連する制御ポイントである、［１１］の装置。
［２７］前記少なくとも１つのサービスメッセージの各々は、下記を具備する［１１］１の装置：
前記サービスメッセージを識別するためのメッセージＩＤフィールド；
前記サービスメッセージの一部の長さを指定するためのメッセージレングスフィールド；
メッセージ値フィールド。
［２８］前記少なくとも１つのサービスメッセージの前記少なくとも１つの前記メッセージ値フィールドは、下記を具備する第１タイプレングス値（ＴＬＶ）フィールドを備えた［２７］の装置：
前記第１のＴＬＶのタイプを識別するための第１のＴＬＶタイプフィールド；
前記第１のＴＬＶタイプに関連する値を指定するための第１のＴＬＶ値フィールド；
前記第１のＴＬＶ値フィールドのレングスを指定するための第１のＴＬＶレングスフィールド。
［２９］前記第１のＴＬＶは、前記少なくとも１つのサービスメッセージの前記少なくとも１つのための必須のＴＬＶである、［２８］の装置。
［３０］前記第１のＴＬＶ値フィールドは複数の値フィールドを備える、［２９］の装置。
［３１］前記少なくとも１つのサービスメッセージの少なくとも１つの前記メッセージ値フィールドはさらなるＴＬＶをさらに備える、［２８］の装置。
［３２］前記さらなるＴＬＶはオプションＴＬＶを備える、［３１］の装置。
［３３］前記オプションＴＬＶは、前記少なくとも１つのサービスメッセージの前記少なくとも１つを暗号化するための少なくとも１つの暗号化パラメーターを備える、［３２］の装置。
［３４］前記オプションＴＬＶは、前記少なくとも１つのサービスメッセージの前記少なくとも１つを認証するための少なくとも１つの認証パラメーターを備える、［３２］の装置。
［３５］前記オプションＴＬＶは前記少なくとも１つのサービスメッセージの前記少なくとも１つのインテグリティを検証するための少なくとも１つのインテグリティプロテクションパラメーターを備える、［３２］の装置。
［３６］前記制御モジュールは、前記制御モジュールによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージ内の認識されないオプションＴＬＶをスキップするように構成可能である、［１１］の装置。
［３７］前記制御モジュールは、前記制御モジュールによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージを無視するように構成可能である、［１１］の装置。
［３８］前記制御モジュールは、前記制御モジュールによりサポートされるよりもより低い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージと同じかまたは低いサービスバージョンを有するサービスメッセージのみを発生するように構成可能である、［１１］の装置。
［３９］前記制御モジュールは認識されない受信されたサービスメッセージに応答して前記受信されたサービスメッセージをリジェクトするように構成可能である、［１１］の装置。
［４０］前記制御モジュールは、認識されない受信サービスメッセージに応答して、前記受信されたサービスメッセージを無視するように構成可能である、［１１］の装置。
［４１］前記マルチプレックスメッセージは、前記マルチプレクッスメッセージに関連するトランザクションＩＤを記憶するためのトランザクションＩＤフィールドをさらに備える、［１］の装置。
［４２］データチャネルを提供するための論理装置ドライバーと、前記マルチプレックスメッセージのための制御チャネルであって前記データチャネルとは独立した制御チャネルをさらに備えた、［１］の装置。
［４３］前記制御チャネルは、ＡＴコマンドを発生するように構成可能であり、前記論理装置の前記制御チャネルは、前記制御モジュールにより発生された前記ＡＴコマンドをトランスポートするように構成可能である、［４２］の装置。
［４４］前記論理装置ドライバーはユニバーサルシリアルバス（ＵＳＢ）で動作するように構成可能である、［４２］の装置。
［４５］前記第１の制御ポイントのための割り当てられたクライアントＩＤを受信するＣＴＬモジュールをさらに具備し、前記ＣＴＬモジュールは前記マルチプレックスモジュールのためのサービスメッセージを発生するように構成可能である、［４］の装置。
［４６］前記ＣＴＬモジュールはサービスエンティティのサービスメッセージバージョンを得るようにさらに動作可能である、［４５］の装置。
［４７］前記装置はパーソナルコンピューターである、［１］の装置。
［４８］前記マルチプレックスメッセージはさらに前記制御モジュールが制御ポイントかまたはサービスエンティティかを示す制御フラッグフィールドをさらに備える、［１］の装置。
［４９］前記装置は、前記制御モジュールにより発生されたサービスメッセージを備えた非マルチプレックスメッセージを発生するようにさらに動作可能である、［１］の装置。
［５０］前記サービスメッセージはＡＴコマンドメッセージを備える、［４９］の装置。
［５１］下記を具備する装置：
少なくとも１つのサービスメッセージを発生するための制御手段；
共通チャネルを介して前記複数の制御モジュールにより発生された前記サービスメッセージを多重化するマルチプレックス手段。
［５２］複数のサービスメッセージを受信し、前記受信されたサービスメッセージを前記複数の制御モジュールの関連するモジュールに配信するデマルチプレックス手段をさらに具備する、［５１］の装置。
［５３］前記装置は、さらに少なくとも１つの制御モジュールを備えた第２の装置と、複数の制御モジュールにより発生されたサービスメッセージを多重化するマルチプレックス手段と、複数のサービスメッセージを受信し、前記受信したサービスメッセージを前記複数の制御モジュールの関連したモジュールに配信するデマルチプレックス手段とにさらに接続する、［５２］の装置。
［５４］クライアントＩＤを前記複数の制御モジュールの１つに割り当てるＣＴＬ手段をさらに備えた、［５１］の装置。
［５５］前記制御モジュールは、前記デマルチプレックス手段から異なるバージョンのサービスメッセージを受信することに応答して、サービスメッセージを発生するサービスバージョン差処理手段をさらに具備する、［５２］の装置。
［５６］前記制御モジュールは制御ポイントである、［５１］の装置。
［５７］前記制御モジュールはサービスエンティティである、［５１］の装置。
［５８］複数の装置をインターフェースするための方法において、前記方法は下記を具備する：
少なくとも１つのサービスメッセージを供給する；
下記を具備するマルチプレックスメッセージを発生する；
前記少なくとも１つのメッセージ；
前記少なくとも１つのサービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤフィールド；
前記少なくとも１つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド。
［５９］前記マルチプレックスメッセージは、前記少なくとも１つのサービスメッセージのメッセージタイプを識別するためのメッセージタイプフィールドをさらに具備する、［５８］の方法。
［６０］前記メッセージタイプは要求メッセージタイプである、［５９］の方法。
［６１］受信されたマルチプレックスメッセージを逆多重化することをさらに具備し、前記受信されたマルチプレックスメッセージは下記を具備する、［５８］の方法： 
少なくとも１つの受信されたサービスメッセージ；
前記少なくとも１つの受信されたサービスメッセージに関連する制御ポイントを識別するためのクライアントＩＤを記憶するためのクライアントＩＤフィールド；
前記少なくとも１つの受信されたサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプを記憶するサービスタイプフィールド。
［６２］複数の逆多重化された要求サービスメッセージの各々に対して、関連した応答サービスメッセージを供給することをさらに具備する、［６１］の方法。
［６３］対応する要求サービスメッセージが受信された順番に各応答サービスメッセージを多重化することをさらに具備する、［６２］の方法。
［６４］認識されない受信された要求サービスメッセージに関連するエラー応答サービスメッセージを発生することをさらに具備する、［６３］の方法。
［６５］前記マルチプレックスメッセージは、前記マルチプレックスメッセージに関連するトランザクションＩＤを記憶するトランザクションＩＤフィールドをさらに具備する、［６１］の方法。
［６６］マルチプレックスメッセージが発生されるごとに前記トランザクションＩＤをインクリメントすることをさらに具備する、［６５］の方法。
［６７］前記マルチプレクッスメッセージのための独立制御チャネル、および独立データチャネルを供給することをさらに具備する、［５８］の方法。
［６８］ＡＴコマンドを発生し、前記ＡＴコマンドを前記独立制御チャネルを介してトランスポートすることをさらに具備する、［６７］の方法。
［６９］認識されない受信されたサービスメッセージをスキップすることをさらに具備する、［６１］の方法。
［７０］前記スキップすることは、認識されないサービスメッセージを受信することに応答する、［６９］の方法。
［７１］前記少なくとも１つの受信されたサービスメッセージのバージョンと同じまたは低いサービスバージョンを有するサービスメッセージのみを発生することをさらに具備する、［５８］の方法。
［７２］前記少なくとも１つのサービスメッセージの少なくとも１つは下記を具備する、［６９］の方法：
前記サービスメッセージを識別するためのメッセージＩＤフィールド；
前記サービスメッセージの一部の長さを指定するためのメッセージレングスフィールド；
メッセージ値フィールド。
【図１】
0005384578.tif 000002
【図２】
0005384578.tif 000003
【図３】
0005384578.tif 000004
【図４】
0005384578.tif 000005
【図５】
0005384578.tif 000006
【図６】
0005384578.tif 000007
【図７】
0005384578.tif 000008