JP4197841B2 - 移動ステーションを周辺装置に接続するためのインテリジェントサービスインターフェイス及びメッセージプロトコル - Google Patents

Description

【０００１】
【技術分野】
本発明は、一般に、無線電話に係り、より詳細には、セルラーネットワークと共に動作できそして１つ以上の周辺装置に接続できるような無線電話又は移動ステーションに係る。
【０００２】
【背景技術】
インテリジェントアクセサリーを経てパーソナルコンピュータ（ＰＣ）やその他の装置に接続することにより情報を交換する一般的な装置として電話の役割が広がったために、音声会話のみを意味する電話の概念は時代遅れとなってきている。このような開発は、実際に装置の基礎となっている複雑なものをユーザから隠し、希望のサービスのみをユーザが見て利用できるようにしする必要性を生じさせたことが明らかである。
【０００３】
一部にはセルラー電話及びその関連市場が急成長したために、移動ステーションとも称するワイヤレス電話又は無線電話を、ワイヤード接続、又はワイヤレス接続、例えば、赤外線（ＩＲ）リンクや、低レベル高周波（ＲＦ）信号のような他のワイヤレス通信を経て、１つ以上のインテリジェントアクセサリに物理的に接続する必要性が生じている。ＷＯ９７／３２４３９及びＷＯ９４／２４７７５は、どちらも、セルラー電話のような通信装置に接続を与える公知解決策の一例である。
今日、この分野では、機能がある程度制限されるが、本発明者が知る限り既存の解決策は、ユーザを基礎的なハードウェア／ソフトウェアの複雑さから分離するという問題を満足に解消するものではない。
【０００４】
これまでに生じている更に別の問題は、移動ステーションに対して新規な及び改善された機能を与えるためのハードウェア、ソフトウェア及びインターフェイスの開発に係るものである。明らかなように、新たな外部装置とインターフェイスする能力を追加することが望まれるときに移動ステーション及び／又はアクセサリのソフトウェア部分を完全に又は部分的に再構成することは、多数の理由で望ましくない。
上記説明に関連して、１つの外部装置に接続された移動ステーションのようなポイント−ポイント構成から、移動ステーションを複数の外部装置に同時に接続すべきときのマルチポイント構成へと進むときに変更を必要とすることも望ましくない。
【０００５】
【発明の目的及び効果】
従って、本発明の第１の目的及び効果は、セルラー電話又はパーソナルコミュニケータのような移動ステーションと、１つ以上の外部装置との間の改良されたインターフェイスを提供することである。
本発明の別の目的及び効果は、選択された形式の移動ステーションインターフェイスを経て移動ステーションと１つ以上の外部装置との継ぎ目のない一体化を容易にするためのメッセージ通過ルータ及び接続機能を提供することである。
【０００６】
本発明の更に別の目的及び効果は、移動ステーションのメインプロトコルソフトウェアを大幅に変更する必要なく、異なる装置及びアプリケーション並びに物理的転送媒体を実施できるように確保するためのモジュラーソフトウェアプロトコルを提供することである。
本発明のもう１つの目的及び効果は、移動ステーションのマルチポイント接続能力を提供すると共に、ソフトウェアプロトコルをより融通性の高いものとする構成機能のグループを更に指定することである。
【０００７】
【発明の開示】
本発明の実施形態に基づく方法及び装置によって上記及び他の問題が解消されると共に本発明の目的が実現される。
無線トランシーバと、複数のオブジェクトと、複数のリンクとを含む無線ユニット装置を備え、少なくとも１つのリンクは、上記オブジェクト間にメッセージを転送するためのものである通信システムにおいて、上記無線ユニット装置は、更に、オブジェクトから登録要求を受け取り、要求を発しているオブジェクトを登録し、そして登録されたオブジェクトを記述する情報を維持するためのメッセージルータを備えたことを特徴とする通信システムが開示される。
【０００８】
メッセージの１つは、無線ユニット装置又は外部装置のリソースへのアクセスを得る希望を指示するためのリソース要求メッセージであり、そして別のメッセージは、リソースに対して責任を負うサーバからリソース要求メッセージの発信点へと送信される応答メッセージである。リソース要求メッセージは、アプリケーション又はサーバの一方により送信することができる。もう１つのメッセージは、リソースに対して責任を負うサーバからリソース要求メッセージの発信点へ送信される指示メッセージである。リソース要求メッセージは、アプリケーション又はサーバの一方により送信することができる。もう１つのメッセージは、リソースに関連した事象又は状態の一方を指示するために、リソースに対して責任を負うサーバから送信される指示メッセージである。更に別のメッセージは、リソース要求メッセージにより指令された動作を完了するための付加的な情報を要求するためにリソースに対して責任を負うサーバから送信される協議要求メッセージである。更に別のメッセージは、協議要求メッセージの受信に応答してリソース要求メッセージの発信点から送信される通知応答メッセージである。
【０００９】
又、本発明は、少なくとも１つの形式のワイヤレス通信ネットワークと共に動作できる無線ユニットを備えた形式の通信システムであって、上記無線ユニットが複数のアプリケーション及び複数の通信媒体より成る通信システムを動作する方法において、上記複数のアプリケーションと上記通信媒体との間に介在されたマスタールータ層及び接続層を上記無線ユニットに与え、スレーブルータ層を経て上記無線ユニットに外部アプリケーションを接続し、上記複数のアプリケーションの１つからメッセージを受信し、そしてその受信したメッセージを、上記マスタールータ層と共に、上記接続層、上記通信媒体の少なくとも１つ、及び上記スレーブルータ層を経て上記外部アプリケーションへルート指定するという段階を含むことを特徴とする方法も提供する。
【００１０】
又、本発明は、複数のオブジェクトと、これらオブジェクト間にメッセージを転送する複数のリンクとを備えた無線ユニット装置であって、オブジェクトから登録要求を受信するためのメッセージルータを更に備えた無線ユニット装置にも係る。
又、本発明は、少なくとも１つのワイヤレスインターフェイスを経て無線ユニット装置に両方向接続されるアクセサリ装置であって、リソース要求メッセージ又はリソース要求応答メッセージの少なくとも一方を上記無線ユニット装置に送信するために、メッセージルータ層を経て上記ワイヤレス又はワイヤードインターフェイスに接続される少なくとも１つのアプリケーションを備えたアクセサリ装置にも係る。
【００１１】
【発明を実施するための最良の形態】
以下、添付図面を参照して、本発明を詳細に説明する。
本発明の以下の説明、特に、電話及びネットワーク、周辺ホスト−オブジェクトネットワーク（ＰｈｏＮｅｔ）の説明を読むときに有用な省略形及び頭文字のリストを以下に示す。

【００１２】

【００１３】

【００１４】
本発明を実施するのに適したセルラー無線電話又はパーソナルコミュニケータ（これに限定されないが）のようなワイヤレスユーザターミナル又は移動ステーション１０を示す図１及び２について説明する。移動ステーション１０は、ベースサイト即ちベースステーション３０へ信号を送信し及びそこから信号を受信するためのアンテナ１２を備えている。ベースステーション３０は、移動交換センター（ＭＳＣ）３４を含むベースステーション移動交換センター／インターワーキングファンクション（ＢＭＩ）３２より成るセルラーネットワークの一部分である。ＭＳＣ３４は、移動ステーション３０がコールに含まれたときに地上ライントランクへの接続を与える。
【００１５】
移動ステーションは、変調器（ＭＯＤ）１４Ａと、送信器１４と、受信器１６と、復調器（ＤＥＭＯＤ）１６Ａと、送信器１４及び受信器１６へ信号を送信したりそこから信号を受信したりするコントローラ１８とを備えている。これらの信号は、適用可能なセルラー又は他のシステムのエアインターフェイス規格に基づくシグナリング情報と、ユーザスピーチ及び／又はユーザ発生データとを含む。エアインターフェイス規格それ自体は、本発明のオペレーション又はその理解に密接に関係するものではなく、従って、これ以上説明しない。
【００１６】
又、コントローラ１８は、移動ステーションの音声及び論理機能を実行するのに必要な回路も含むことを理解されたい。例えば、コントローラ１８は、マスター制御ユニット（ＭＣＵ）２１、通常は、マイクロプロセッサ装置と、ＭＣＵ／ＤＳＰインターフェイス（ＩＦ）を横切って互いに通信するデジタル信号プロセッサ（ＤＳＰ）２３とを含む。コントローラ１８は、更に、種々のアナログ／デジタルコンバータ、デジタル／アナログコンバータ、及び他のサポート回路も含む。移動ステーション１０の制御及び信号処理機能は、これらの装置間にそれらの各能力に応じて割り当てられる。
【００１７】
ＭＣＵ２１に接続された非同期メッセージバス（ＭＢＵＳ）１８Ａ、ＤＳＰ２３に接続された高速非同期メッセージバス（ＦＢＵＳ）１８Ｂ、及び赤外線（ＩＲ）又は低電力ＲＦリンクのようなワイヤレスバス１８Ｃのような複数のバスも、図２に示すアクセサリ装置２８のような外部装置へインターフェイスするために設けられる。アクセサリ装置２８は、例えば、パーソナルコンピュータや、パーソナルコミュニケータや、外部無線ユニットや、他の装置、例えば、音声レコーダ、ページャー、外部ハンドセット及び乗物アクセサリを含むが、これに限定されるものではない。以下に述べるように、移動ステーション１０には２つ以上のアクセサリ装置２８を接続することもできる。
【００１８】
ユーザインターフェイスは、従来のイヤホン又はスピーカ１７と、従来のマイクロホン１９と、ディスプレイ２０と、ユーザ入力装置、通常、キーパッド２２とを含み、これらは全てコントローラ１８に接続される。キーパッド２２は、従来の数字（０−９）及び関連キー（＃、＊）２２ａと、移動ステーション１０を操作するのに使用される他のキー２２ｂとを含む。これらの他のキー２２ｂは、例えば、ＳＥＮＤ（送信）キーと、種々のメニュースクロール及びソフトキーと、ＰＷＲキーとを含む。又、移動ステーション１０は、移動ステーションを動作するのに必要な種々の回路を付勢するためのバッテリ２６も含む。
【００１９】
又、移動ステーション１０は、メモリ２４として集合的に示された種々のメモリも含み、ここには、移動ステーションの動作中にコントローラ１８により使用される複数の定数及び変数が記憶される。例えば、メモリ２４は、種々のセルラーシステムパラメータ及び番号指定モジュール（ＮＡＭ）の値を記憶する。コントローラ１８の動作を制御するためのオペレーティングプログラムもメモリ２４（通常、ＲＯＭ装置）に記憶される。又、メモリ２４は、メッセージをユーザに表示する前にＢＭＩ３２から受け取ったユーザメッセージを含むデータも記憶する。移動ステーション１０のある情報を記憶するために取り外し可能なＳＩＭ２７も設けられる。
【００２０】
移動ステーション１０は、乗物に搭載することもできるし、ハンドヘルド装置であってもよいし、或いはパーソナルコンピュータ又は他の形式のコンピュータのスロット（例えば、ＰＣＭＣＩＡスロット）に差し込まれるカードのようないかなる適当な形態で実施されてもよい。
更に、移動ステーション１０は、１つ以上のエアインターフェイス規格、変調形式、及びアクセス形式、例えば、ＴＤＭＡ、ＣＤＭＡ及びアナログ（ＦＭ）で動作することもできる。
メモリ２４の動作プログラムは、以下に詳細に述べるようにＰｈｏＮｅｔシステムを実施するためのソフトウェアを含む。
【００２１】
図３を参照すれば、本発明によるＰｈｏＮｅｔは、ルータ層４０及び接続層４２と称する２つの別々のファンクション層を含み、これらは、一緒に接続層４１と称する。接続層４２は、制御モジュール４２Ａと、リンク特有の媒体モジュール、特に、ワイヤレス媒体モジュール４２Ｂ、ＦＢＵＳ媒体モジュール４２Ｃ、及びＭＢＵＳ媒体モジュール４２Ｄとを備えている。ルータ４０と、制御及び媒体モジュール４２Ａ−４２Ｄは、ＭＳＣ２１内にあり、一方、接続層４２の一部分でもあるフレームフィルタ層４２Ｅは、ＤＳＰ２３内にある。ワイヤレス（例えば、ＩＲ又はＲＦ）、ＦＢＵＳ及びＭＢＵＳハードウェア（ＨＷ）モジュール４３Ａ−４３Ｃは、必要なハードウェアと、外部装置への物理的インターフェイスとを与えるためにそれらの各バスに接続される。
図３に示す層構造は、ハードウェアの独立性を確保すると共に、ＰｈｏＮｅｔに対する所望のモジュール性を得るように定義される。
【００２２】
ルータ層４０は、ルータモジュールを備え、その主たる機能は、メッセージのルートと、接続された装置及びオブジェクトに関する情報とを与えると共に、精巧なコンフィギュレーション変更を行えるようにすることである。ルータ層４０は、異なる物理的転送媒体モジュール４３へ最適なやり方でメッセージを通すためのロジックを含む。
接続層４２の制御モジュール４２Ａは、制御メッセージを送信するためにＭＤＩを経てＤＳＰ ＳＷへ至るゲートとして働く。制御モジュール４２Ａは、リンク特有ではなくて全てのリンクに共通な共通コンフィギュレーションファンクションのグループを保持する。又、これは、以下に述べるように、個別の制御メッセージによるパイプ転送も許可する。又、異なる装置による考えられるプロトコルフィルタ使用も、制御モジュール４２Ａから決定することができる。
【００２３】
媒体モジュール４２Ｂ−４２Ｄは、一般的なルータ４０のメッセージを必要な物理的転送媒体に変換する。所与の媒体モジュールは、関連ハードウェアモジュール４３へのインターフェイスである。図３には３つの異なる媒体モジュールが示されているが、使用する数はこれより多くても少なくてもよく、必要に応じて新たな媒体モジュール４２及びその関連ハードウェアモジュール４３を定義することができる。媒体モジュール４２Ａ−４２Ｃは、メッセージ再送信及び確認特徴を含むのが好ましい。又、その各々は、リンクを通過するメッセージ及びデータを記憶するための必要なＩ／Ｏバッファも含む。
【００２４】
フレームフィルタモジュール４２Ｅは、ＰｈｏＮｅｔフレーム構造フォーマットを、必要に応じて別のフレーム構造に変換する。この変換は、高速ＤＳＰ２３ソフトウェアで行なわれるのが好ましい。
ルータ４０は、メッセージのルート指定を主たるサービスとして提供することによりＰｈｏＮｅｔのコアと考えることができる。又、ルータ４０は、コンフィギュレーションの変更及び問合わせのような他のサービスも行うと共に、接続された装置及びオブジェクトに関する情報も与える。
ＰｈｏＮｅｔは、ホストに関連した１つのメインルータ４０を有すると定義される。通常、メインルータ４０は、移動ステーション１０に配置される。完全なメッセージルート指定サービスを提供するのは、メインルータ４０だけである。ルータ４０は、物理的な転送媒体の使用を最適化する。ルータ４０は、物理的リンクの状態及び負荷レベルを監視し、そして所与のメッセージを通過するための最適な（最も高速の）やり方を選択することができる。多数のサブルーチン又はスレーブもシステムに接続できる。サブルーチンは、通常、メインルータ４０の機能のサブセットを有する。
【００２５】
コンフィギュレーション及び拡張可能なルータ４０の特徴は、次の通りである。
（Ａ）ルータ４０は、論理的アドレスから物理的アドレスへの変換を行う。
（Ｂ）ルータ４０は、１つの論理的アドレスを多数の物理的アドレスにマップできるようにする（例えば、移動ステーションのユーザインターフェイスは、１つのメッセージを複数のアプリケーションに送信することができる）。
（Ｃ）メインルータ４０は、ファンクションによりルートを与えることができる。
（Ｄ）ルータ４０は、デフォールトアドレスマッピング／動的コンフィギュレーション、並びにコンフィギュレーションの問合わせを行うことができる。
（Ｅ）ルータ４０は、物理的アドレス（媒体）に異なる優先順位をもたせることができる。
【００２６】
（Ｆ）ルータ４０は、ルータ層と接続層４２との間にシグナリングメカニズムを与える（例えば、媒体利用性及び状態）。
（Ｇ）ルータ４０は、ルータ４０と装置及びオブジェクトとの間、ルータ４０と接続層４２との間、及び接続層４２と物理的媒体４３との間に明確なインターフェイスを与える。
（Ｈ）ルータ４０は、ルータコンフィギュレーション変更及び問合わせに対して明確なインターフェイスを与える。
（Ｉ）ルータ４０は、接続された装置及びオブジェクトに関する情報を記憶すると共に、パラメータのカウント制限を伴わずにリモート手順コール（ＲＰＣ）も与える。
（Ｊ）ルータ４０は、切断に関する情報を所望のインターフェイスに与えるようにルータをコンフィギュレーションする能力も与える。
【００２７】
ホスト（例えば移動ステーション１０）に配置されたメインルータ４０の場合に、メッセージのルート指定は、基本的に、メッセージをファンクションに基づいてある論理的アドレスにルート指定し、そして論理的アドレスを、どんな物理的リンクを使用すべきかの情報を含む物理的アドレスに変換することを伴う。メッセージは、論理的アドレスを知らずにあるファンクションに送信することもできるし、又はある既知の論理的アドレスに直接送信することもできる。メインルータ４０は、（ａ）システムに使用できるリンク、（ｂ）接続された装置及びそれらのリンク、（ｃ）ログイン装置及びそれらのリンク優先順位に関する情報、（ｄ）ＩＳＩ、ＵＩ又はＣＳのようなオブジェクトタスクに対するルート情報、及び（ｅ）アクティブパイプに関する情報といった異なるファンクションに関する情報を更新する。
【００２８】
これらについて詳細に検討する。システムに使用できるリンク（ａ）については、リンクは、３つの異なる状態、即ち（１）アクティブ、（２）ビジー（使用不可）及び（３）利用できず、の１つをもつことができる。テーブル１は、リンク状態を例示するものである。

【００２９】
接続された装置及びそれらのリンク（ｂ）については、メインルータ４０は、利用できる全ての装置と、どの装置が現在アクティブであるかに関する情報を記憶する。又、所望のリンクに負荷がかかっている場合に、メッセージが別の利用可能なリンクへルート指定されるように、メッセージを通過する最適なやり方を与えるためのリンク負荷レベル情報も記憶する。テーブル２は、装置状態及び使用リンクに関する情報と、オブジェクトテーブルへのポインタとを示す。「ポインタ」の蘭は、状態情報を得るためのテーブル１へのポインタを含む。「媒体」蘭は、好ましい媒体（テーブル３参照）、又は好ましい媒体が与えられない場合は関連装置が最初に登録される媒体を指示する。

【００３０】
テーブル３は、装置ログインオブジェクト及びそれらのリンク優先順（ｃ）に関する情報を例示する。

【００３１】
ＩＳＩ、ＵＩ又はＣＳのような内部オブジェクトタスクに対するルート情報について、テーブル４は、１つの例示的コンフィギュレーションを示す。

【００３２】
説明上、所与のＰｈｏＮｅｔメッセージは、移動ステーション１０の「内部」オブジェクト、例えば、セルラーシステム（ＣＳ）モジュール、ユーザインターフェイス（ＵＩ）モジュール、音声ソフトウェアモジュール又はＩＳＩモジュールに供給できるものとする。これらのオブジェクトは、装置によって必ず所有されるものではなく、又、通信に対していずれのリンクも使用しないので、モジュールの論理的アドレスを物理的アドレスに変換することによりこれらモジュールと通信するために、特殊な内部オブジェクトテーブル（テーブル４）が設けられる。従って、テーブル４は、メッセージのファンクションが内部オブジェクトを参照するときにルータ４０により使用される。
【００３３】
最後に、アクティブなパイプに関する情報（ｅ）については、ルータ４０は、異なる装置又はオブジェクト間に高速メッセージリンク又はパイプを設定することができる。パイプは、ワイヤレス媒体、ＦＢＵＳ又はＭＢＵＳを使用して設定することができる。パイプがアクティブになると、２つのオブジェクトは、ルータ４０を含ませることなく互いに通信することができる。即ち、２つのオブジェクトは、ルータが確認するフレーム構造を使用せずに「純粋」なデータを転送することができる。一般に、ルータ４０は、アクティブなパイプに関する情報を記憶し、アクティブなパイプを制御し、そして要求を発している装置へのメッセージパイプの設定を許可する（パイプが利用できれば）。
【００３４】
テーブル５は、全てのＰｈｏＮｅｔパイプの現在状態の例示的「スナップショット」、即ち含まれる装置と、パイプが確立されるリンクとのアドレスを示す。

一般に、２つの異なる形式のパイプがある。第１の形式のパイプは、あるアクセサリから別のアクセサリへまっすぐに通る高速データ流を許す。第２の低速型のパイプは、装置からリンクホスト（含まれたＰｈｏＮｅｔルータＭＣＵ２１を必ずしも使用しない）を経て別の装置へ至るデータを供給する。
【００３５】
第１の形式のパイプは、例えば、２つのＤＳＰ（例えば、デジタル音声）間で高速データ転送を実行するためのメカニズムを与える。パイプを経ての通信は、ホストには見えない。むしろ、ホストは、アクティブなパイプに関する情報を個別のテーブルに維持する（図５及び６を参照）。
第２の形式のパイプは、受信者が保持していない媒体を経て到来するデータを変換するのに使用できる。例えば、ＩＲリンクしかもたないアクセサリは、ＲＦリンク又は他のバスしかもたないアクセサリへデータを転送することができる。例えば、ＤＳＰ２３ソフトウェアにより実施されるあるプロトコルコンバータにメッセージを通すことにより転送中にプロトコル変換を使用することができる。
【００３６】
パイプがもはや使用されないときは、パイプが解除されたことをホストに通知しなければならない。又、ホストは、所与のパイプを制御しそして中断することができる。所与の時間に２つ以上のアクティブなパイプをもつことができ、そして図５に示すように、同じ媒体を使用して２つ以上のアクティブなパイプをもつことができる。
図６は、制御がＭＣＵ２１（ルータ４０）によって実行されそして実際のパイプがＤＳＰ２３を経て２つの装置（例えば、装置３及び４）間に形成される一般的なパイプアーキテクチャーを示している。
【００３７】
所与のサブルータ（スレーブ装置に配置された）は、次の情報を更新する。即ち、それ自身の接続状態（登録、ログイン／アウト）、それ自身のリンクの状態（アクティブ／非アクティブ、負荷レベル等）、ホストの利用可能／アクティブリンク、及びメッセージルート。これらのタスクに関連した基本的なファンクションは、メインルータ４０のファンクションと同様であるが、論理的アドレスから物理的アドレスへのマッピングしか含まないので、メッセージルートは、より簡単である。
ルータ４０のコンフィギュレーションに関しては、重要なルータファンクション、即ちルート指定、及び論理的アドレス−物理的アドレス変換の両方についてデフォールト及び動的なルート指定機構が存在する。デフォールトのルート指定は、ソフトウェアのコンパイル段階中に定義され、一方、動的なルート指定は、実行時間に動的に変更することができる。内部オブジェクトの数は、コンパイルの時間に固定及び定義されるのが好ましい。
【００３８】
コンフィギュレーションの問合わせを使用して、現在のデフォールト又は動的なルート指定に関する情報を得ることができる。コンフィギュレーションの問合わせ及び変更に対して明確なインターフェイスファンクションが与えられる。インターフェイスは、基本的に、メッセージインターフェイス（コンフィギュレーションの目的のみで割り当てられた幾つかのファンクションを伴う）である。メッセージを形成するために、１組のサービスファンクションを設けることができる。
ルータ４０の幾つかの特徴は、システムの必要性に応じてルータを拡張できるように構成することができる。例えば、単一モードのＡＭＰＳセルラー電話は、ＧＳＭ又はＩＳ−１３６電話のような全特徴のデジタルセルラー電話に比して、非常に限定されたルータファンクションしかもたない。
【００３９】
アドレスに関して、本発明の好ましい実施形態は、２レベルのアドレスを使用する。論理的レベルアドレスは、装置番号（例えば、電話、ＰＣ等）と、内部オブジェクト番号（例えば、ＵＩ又はＣＳ）とを含む。物理的レベルアドレスは、使用される媒体に関する情報を物理的アドレスに追加する。
外部装置のアドレススペースは、２組に分割される。一方の組は、固定の装置アドレスを含み（即ち、装置は、予め定められたアドレスをもつことができ）、そして他方の組のアドレスは、ここに開示する動的な登録方法を用いる装置に対して指定される。
【００４０】
装置が固定アドレスを使用する場合には、装置がリンクの優先順等についてホストに通知しようとしない限り、メッセージを送信すれば、装置が接続されたことがホストに充分に通知されるので、装置をＰｈｏＮｅｔホストに実際に登録する必要はない。固定アドレスの使用は、高度なインテリジェンスを必要としない簡単な外部装置を使用できるようにする。例えば、いわゆるハンズフリーユニットのようなハードコードの固定アドレスを有する簡単且つ低コストの外部スレーブ装置にデジタル音声を送信することができる。
この場合の登録メッセージは、単に、受信者部分における固定のホストアドレスと、送信者部分における固定のスレーブ装置アドレスとを含むことができ、従って、登録応答は、受信者部分における固定のスレーブアドレスと、送信者部分における固定のホストアドレスとを含む。
【００４１】
動的な登録を使用する装置に説明を移すと、アドレス動作は、あるスレーブが固定の装置番号をもたないという意味で動的である。むしろ、装置番号は、登録段階においてＰｈｏＮｅｔホストにより動的に指定される。ホストは、常に、１つの固定の装置番号を所有する。又、グローバルな即ち放送形式のメッセージに対しても１つの固定アドレスがあり、全ての接続された装置は、その固定の放送アドレスにアドレスされたいかなるメッセージも受信する。
図４は、論理的アドレスフォーマットを示す。このアドレス機構によれば、ネットワークは、例えば、２５５個の接続された装置を含むことができ、各接続された装置は、最大２５６個の内部オブジェクトを保持することができる。各装置の内部オブジェクト番号は、ソフトウェアのコンパイル段階で固定されるのが好ましい。本発明の特徴によれば、各装置、及び装置内のオブジェクトは、別々にアドレスすることができ、且つ通信トランザクションに参加することができる。
【００４２】
装置のアドレスがとり得る状態は、空き、アクティブ又は保留の３つの異なる状態である。空きアドレスは、新たな装置に指定することができ、アクティブなアドレスは、ある接続された装置に指定されたアドレスであり、そして保留アドレスは、関連装置がログアウトしたという確認を待機しているアドレスである。指定されたアドレスは、対応する装置との通信が失敗したときに、ルータ４０により保留状態に入れられる。保留アドレスは、対応する装置が「ウェークアップ」した場合に再びアクティブ状態となるか、或いはある装置の回復ソフトウェアを実行した後又はある所定の時間切れの後に空き状態となる。
【００４３】
ルータ４０と物理的媒体（例えば、ＩＲリンク）との間の好ましいメッセージフォーマットがテーブル６に示されている。ここで、「ｂ」はビットを表わす。

但し、媒体は、例えば、ＩＲ、ＦＢＵＳ、ＭＢＵＳであり、受信者は、装置アドレスであり、送信者は、装置アドレスであり、ファンクションは、メッセージの形式識別子であり、長さは、データバイトの数であり、オブジェクトは、低レベルアドレス、例えば、ＰＣアプリケーションアドレスであり、そしてデータは、転送されるべきデータである。
【００４４】
装置は、システムの始動時、装置がシステムに接続されるとき、及びメインルータ４０により必要とされるときに、登録することができる。登録は、装置により選択された物理的転送媒体を用いて行なわれる。選択された媒体が、何らかの理由で利用できないか又は機能しない場合には、他の物理的媒体を試みることができる。登録技術は、登録に使用するための好ましい媒体と、その好ましい媒体が利用できないか又は機能しない場合に他の媒体を使用するための優先順位とを選択できるように完全に構成することができる。
【００４５】
登録メッセージにおいて、登録する装置は、実際の装置アドレスがメインルータ４０により指定されるまで一時的なアドレスを使用する。登録メッセージは、その装置に対して利用できる物理的な転送媒体に関する情報を含む。又、登録メッセージは、装置の形式のような固定の部分と、あるランダムに発生される部分とを含む。ランダムに発生される部分は、装置がそれら自身の登録確認を識別しようと試みるときに競合を回避するのに使用される。又、装置は、好ましい装置番号を示唆することもできる。ホスト（メインルータ４０）は、要求された装置番号を、その装置番号が空いている場合に指定する。
【００４６】
より詳細には、装置からホストに送信される登録メッセージは、次のものを含む。
− 受信者としての固定のホストアドレス、
− 一時的な装置送信者アドレス、
− 装置形式識別子、
− ランダム番号、
− 利用できる場合に指定されるべき好ましい装置番号、及び
− 利用可能なリンクに関する情報。
登録確認メッセージにおいて、メインルータ４０は、指定された装置番号を登録装置に与えると共に、どんな物理的媒体を利用できるか装置に通知する。
【００４７】
より詳細には、ホストからスレーブ（装置）へ送信される登録確認メッセージは、次のものを含む。
− 受信者としての一時的なアドレス、
− 送信者としての固定のホストアドレス、
− 装置形式識別子（登録メッセージから）、
− ランダム番号（登録メッセージから）、
− ホストにより指定された装置番号、及び
− ホストにおいて利用できるリンクに関する情報。
又、装置に所有される外部オブジェクトをシステムにログインすることもできる。外部オブジェクトが、例えば、そのルートを変更することを望む場合には、装置と同様に先ずそれ自身をホストに識別する。又、このオブジェクトは、それがどんな物理的リンクを使用したいかもホストに通知することができる。オブジェクト登録メッセージは、基本的に、好ましいリンク情報しか含まない。２つの外部オブジェクト間にパイプを設定するために、各オブジェクトをホストにログインしなければならない。
【００４８】
装置接続の監視は、ＰｈｏＮｅｔ接続層４２において行なわれる。接続層４２は、１つのある装置が切断したことを検出すると、ＰｈｏＮｅｔルータ４０に通知する。次いで、ルータ４０は、その装置及びそれが所有する全ての外部装置が切断されたことを表示する。装置に使用されるアドレスは、装置がＰｈｏＮｅｔシステムから実際にログオフ即ち切断されたことをルータ４０が保証するまで、このアドレスを他の装置に指定できないことを指示するために、先ず保留状態に切り換えられる。装置がログアウトしたことをルータ４０が確認すると、アドレスが空き状態に切り換えられ、別の装置に再指定することができる。
【００４９】
ルータ４０は、任意の装置の接続情報を得るためのサービスを提供する。いずれのオブジェクトも、装置（１つ又は複数）が切断された場合にオブジェクトに自動的に通知するようにルータ４０に要求することができる。又、オブジェクトがルータ４０のサービスファンクションを使用して、必要なオブジェクト／装置が切断されたか接続されたかを最初に決定することもできる。
全てのルータ（メインルータ及びサブルータ）は、論理的アドレスから物理的アドレスへの変換をサポートする。１つの論理的アドレスを多数の物理的アドレスにマップすることができる。デフォールト及び動的コンフィギュレーションの両方が与えられる。
【００５０】
メインルータ４０は、メッセージをそのファンクションに基づいてルート指定することができ、即ち受信者のアドレスは未知でもよい。コール形成メッセージは、その一例である。というのは、コール形成メッセージは、コール成形がどこで行なわれるか又はどのＣＳ（マルチＣＳ電話の場合）が特定の瞬間にアクティブであるかを知らずに発生できるからである。しかしながら、メインルータ４０は、メッセージを正しい論理的アドレスにルート指定する。このルート指定は、例えば、ＣＳサービスが別のシステムに切り換えられた場合に、それに応じてルートが変更されるように、完全に構成することができる。
【００５１】
ＰｈｏＮｅｔシステムは、個別のセキュリティチェックモジュールを備えている。各論理的アドレス及びルートファンクションは、もし所望であれば、セキュリティ確保することができる。例えば、あるファンクション又は論理的アドレスは、それをコマンドでロックすることによりセキュリティ確保することができ、そしてあるセキュリティオペレーションを実行するだけでロックを開くことができる。
接続層４２は、ＦＢＵＳ、ＩＲ又はＲＦのような実際の物理的リンクに対する経路を与える。各物理的媒体は、ある媒体モジュールにインターフェイスするためのそれ自身の低レベルドライバを有する。又、ＯＳも、１つの転送媒体とみなされるが、物理的媒体と同様ではない。
【００５２】
接続層４２は、上記のプロトコルコンバータモジュール（即ちフレームフィルタ４２Ｅ）を備え、これにより、メッセージは、必要なフレーム構造に適合される。この処理は、メッセージを媒体モジュール４３に通過する前に行なわれる。又、接続層４２は、多数のＰｈｏＮｅｔメッセージを１つの物理的層フレームにパックできるように最適なメッセージ通過を与えることもできる。
一般に、接続層４２は、次のような特徴及び効果を発揮する。
（ａ）物理的媒体を経て確実なメッセージ転送を与える。
（ｂ）リンクの見失い／発見情報をルータ４０に報告する役目を果たす。
（ｃ）必要に応じて低レベルプロトコルへのフレームマッピングを与える。
（ｄ）各低レベル媒体モジュール４３に対して等しくそして固定されたルータ
４０へのインターフェイスを与える。
（ｅ）低レベル媒体をＰｈｏＮｅｔシステムに容易に追加できる。
（ｆ）媒体モジュール４３がリンクファンクションの診断（例えば、再送信、
ビットエラー率、バッファ状態等）を更新するメカニズムを与える。
（ｇ）上記フレームフィルタ４２Ｅが、必要に応じて、ＰｈｏＮｅｔフレーム構造を他の構造にそしてそれとは逆に変換できるようにする。
【００５３】
図７は、ＰｈｏＮｅｔメインルータ４０及び複数の媒体駆動メッセージリンクの相互接続を例示するもので、ＯＳ４２Ｆメッセージサービスは、１つの媒体とみなされる。
図８は、「コール形成」メッセージに対する装置とメインルータとの間のメッセージの流れを例示する。この場合に、コール形成メッセージは、スレーブ装置０３のサブルーチン４０’を介して、ＩＲリンクを経てメインルータ４０（装置００）へ通され、このメインルータは、ＯＳ４２Ｆを経てＣＳへコール形成メッセージをルート指定する。この例では、論理的アドレス００．００に対して２つの物理的媒体を利用することができ、ＦＢＵＳよりもＩＲの方が好ましい。
【００５４】
図９は、オブジェクト（アプリケーション）から、ルータ層４０及び接続層４２を経て、ＭＣＵ／ＤＳＰインターフェイス（ＩＦ）を横切って、必要な物理的媒体（例えば、ＩＲハードウェア４３Ａ）へ至るメッセージの流れを例示する。特に、次のような段階が行なわれる。
１．ＩＳＩのようなオブジェクトが、ルート指定されるべきメッセージを送信
する。
２．ＰｈｏＮｅｔルータ４０は、次のものを定義する。
-where: device + object
-how: physical media
３．ルータ４０は、メッセージを物理的媒体モジュール（例えば、ＩＲ ＨＷ
４３Ａ）に送信し、これは、次により必要なプロトコルを実行する。
− バッファ動作、
− メッセージのナンバリング、
− 確認、
− 再送信、
− ルータ４０への欠陥報告の送信、及び
− 他の全ての低レベルタスク。
【００５５】
４．媒体モジュールファンクションは、ＭＣＵ２１とＤＳＰ２３との間で区画化することができる。一般的に、全ての必要な制御は、ＭＣＵ２１により実行され、ＤＳＰ２３は、ある付加的な情報をフレームに追加するが、主たるファンクションは、物理的な媒体を「駆動」することである。通常、ＭＣＵ２１は、高速バスを駆動するには遅過ぎる。所与の媒体モジュールは、１つ又は多数の異なる物理的媒体を「駆動」することができる（例えば、ワイヤレス媒体モジュール４２Ｂは、各々のハードウェアインターフェイスを経てＩＲ及びＲＦリンクの両方を駆動することができる）。
５．メッセージは、要求された物理的媒体（ＩＲ）を用いて送信される。
【００５６】
本発明の概要を以上に説明したが、本発明を更に詳細に説明する。
移動ステーション１０は、多数の基本的な能力を有する。これらは、セルラー（及びおそらくコードレス）システムに関連した能力（例えば、コールを発信、受信及び管理する能力）、及びシステムに関連しない能力（例えば、電話帳エントリを記憶及び検索する能力）を含む。移動ステーション１０は、電話の特徴を与えるためにコヒレントなやり方で一体化されたこれら全ての基本的能力を備えている。
インテリジェントソフトウェアアーキテクチャー（ＩＳＡ）は、移動ステーションの基本的な能力を論理的なグループ即ちリソースに分割する。ＩＳＡにおいて、移動ステーションのリソースは、サーバにより制御される。各リソースは、サーバを有する。サーバは、多数のアプリケーションがリソースを使用できるようにするインターフェイスを与える。サーバの目的は、それが制御するリソースをサーバインターフェイスにおいてカプセル化することである。サーバ及びサーバインターフェイスは、それを使用するアプリケーションに直接関与せずに設計及び実施される。
【００５７】
アプリケーションは、移動ステーション１０のリソースを、移動ステーションの特徴を形成するロジックと一緒にリンクする。アプリケーションは、サーバを経て任意の数のリソースを使用して、それらの特徴を形成することができる。アプリケーションは、接続層４１（図３）を経て「リソース要求」を形成し、これは、この目的のために、ルータ４０及び接続層４２の機能を含むと考えられる。接続層４１は、ルータ４０を使用して、「リソース要求」メッセージを適当なサーバへ供給し、このサーバが、要求されたりソースを制御する。サーバは、要求された動作を遂行し、そして適当な応答メッセージを、接続層４１を経て、要求を発しているアプリケーションに返送する。接続層４１は、アプリケーションが、リソース又はリソースを制御するサーバがいかに又はどこで実施されるかを知らずに、移動電話ターミナルのリソースを使用できるようにする間接的メッセージ通過メカニズムを与える。アプリケーションは、リソースの特性及びそれを使用できるインターフェイスを知るだけでよい。接続層４１は、リソースを動的に構成することができる。これは、リソース及び移動ステーション１０の能力を動的に変更できることを意味する。アプリケーションは、必要に応じてこのような変更を知ることができる。
【００５８】
接続層４１は、ＰｈｏＮｅｔのプロトコルソフトウェアと、制御モジュール４２Ａで実施できる通信マネージャーとを含む。接続層４１は、ＰｈｏＮｅｔメッセージフォーマットに従うインテリジェントサービスインターフェイス（ＩＳＩ）メッセージを取り扱う。メッセージ及びＰｈｏＮｅｔは、あるバスハードウェアには結合されない。通信マネージャーは、事象を内部アプリケーション、サーバ及びパネルに分配し、そしてアプリケーション間の通信を維持する役目を果たす。アプリケーションマネージャーは、アプリケーションの登録を取り扱う。パネルは、アプリケーションにより形成された情報を所望のユーザインターフェイス形式でユーザに表示するのに使用される。従来の移動ステーションソフトウェアアーキテクチャーに勝る１つの顕著な相違は、ユーザインターフェイスソフトウェアをアプリケーションとサーバに分割することである。サーバは、接続層４１及びＩＳＩインターフェイスを使用して移動ステーションの外部からコールすることができる。同じサーバを用いるアプリケーションは、接続層４１及びＩＳＩインターフェイスを使用して、無線モジュール内、又は移動ステーション１０の外部のいずれに存在することもできる。同じサーバを用いるアプリケーションは、無線モジュール内又はその外部のいずれに存在することもでき、例えば、ＰＣ又はアクセサリ装置に存在することができる。従来のあるソフトウェアアーキテクチャーでは、ＭＣＵ ＳＷがサブシステムに分割され、その各々は、他のサブシステムへの特定のサービスを伴うＭＣＵソフトウェアの自律的部分である。ＩＳＡには、従来のサブシステムが依然として最も存在するが、アプリケーション（ＵＩ）とサブシステムとの間にはサーバが導入される。
【００５９】
ＩＳＡの目的は、次のものを含む。即ち、基本的リソースの制御を特徴の制御及びロジックから分離し、サービスを要求及び提供するエンティティ（アプリケーション及びサーバ）を分離し、サーバがアプリケーションにサービスを提供できるようにするインターフェイスを形成し、アプリケーションに影響せずにサーバを変更できるようにするインターフェイス（デカップリング）を形成し、サービスを利用するアプリケーションについてサーバが何も知る必要がないよう確保し、即ちサーバに影響せずに新たなアプリケーションを導入できるようにするインターフェイスを形成し、そしてアプリケーション及びサーバの位置を多数のプロセッサ間に隠す（分配する）ことを目的とする。
【００６０】
アーキテクチャーを示す多数の図について以下に説明する。展開図（図１０）は、ソフトウェアの構造、その区画及び層を集中的に示す。物理的図（図１１）は、システムコンフィギュレーションを示す。タスク図（図１２）は、エンティティのＯＳタスク割り当てを示す。その後のメッセージシーケンスチャートは、アプリケーションと、接続層４１と、サーバとの間の通信を説明するためのものである。
ソフトウェアの構造を示す展開図である図１０を参照すれば、移動ステーションのリソース又はサブシステム４８、並びにアクセサリ装置２８のリソース又はサブシステムは、サーバ５０によって制御され、このサーバは、ＩＳＩインターフェイスを与えると共に、アプリケーション５２が移動ステーションサブシステム４８を使用できるようにする。アプリケーション５２は、ＩＳＩメッセージを使用して接続層４１へリソース要求を発する。接続層４１は、上述したように、ＰｈｏＮｅｔ及び通信マネージャー４１Ａを備えている。通信マネージャー４１Ａの一部分であってもよいアプリケーションマネージャー５４は、アプリケーション５２の登録を取り扱う役割を果たす。これも、通信マネージャー４１Ａの一部分であってもよい事象サーバ５６は、サーバ５０からアプリケーション５２への事象分布を取り扱う。パネル５８は、アプリケーション５２のＩＯ機能を果たし、そして関連パネルサーバ６０を有している。同じプロセッサ内の種々のサブシステム４８は、互いに直接通信することもできる。
【００６１】
図１１の物理的図は、移動ステーション１０（無線ユニットとも称する）を、例えば、アクセサリ装置２８、パーソナルコンピュータ（ＰＣ）６０、第２のＰＣ６０に接続されたＰＣＭＣＩＡカード６２のようなＰＣカード、ＤＣＳ電話用のＡＭＰＳパックのような外部無線ユニット６４、及びセルラーネットワーク６６へ、そしてこのセルラーネットワーク６６を経て、オーバー・ジ・エア（ＯＴＡ）特徴のようなネットワークアプリケーション、例えば、電話番号問合わせ、インターネットリンク等へ接続するためのシステムバス（ＦＢＵＳ、ＭＢＵＳ、ＩＲ）の使用を示す。移動ステーション１０は、この例では、付加価値サービス（ＶＡＳ）アプリケーション７０及びハンドポータブルユーザインターフェイスアプリケーション７２を備えている。
【００６２】
図１２のタスク図（図１０の展開図と同様の）は、ＭＣＵ２１ソフトウェアのＯＳタスク７４割り当てを示す。各ＯＳタスク７４は、破線四角形として示されている。ユーザインターフェイスタスクは、アプリケーション５２と、サーバ５０と、アプリケーションマネージャー５４（その機能は通信マネージャー４１Ａに組み込まれてもよい）と、パネル５８とを備えている。他のアプリケーションは、他のＭＣＵ２１のＯＳタスクに存在し得る。サーバ５０は、サブシステムと同じタスクに配置されてもよいし又は分離されてもよく、一方、最も複雑なサブシステム（例えば、ＣＳ）は、多数のＯＳタスクを含む。ＰｈｏＮｅｔは、それ自身のＯＳタスクを有する。アプリケーション又はサーバのいずれかを含む各タスクは、それ自身の通信マネージャー４１Ａを有している。
【００６３】
全体的なアーキテクチャーを説明したが、エンティティについて以下に説明する。エンティティとは、アプリケーション５２、サーバ５０、接続層４１、又はサブシステム４８のいずれかを意味するものとする。ＩＳＡは、ソフトウェアをアプリケーション５２とサーバ５０とに分割する。アーキテクチャーの正しい区画化を確保するためには、サーバ５０とアプリケーション５２との間の差を識別できることが必要である。この情報は、特定のエンティティが何を行うか理解しそして新たな機能が追加されるときにシステムを区画化するために有効である。
サーバ５０の特徴は、次のものを含む。即ち、サーバは、リソースを制御し、サーバ５０は、それが制御するリソースへの他のエンティティのアクセスを許すインターフェイスを与え（このインターフェイスは、ＩＳＩ仕様に合致すると仮定する）、サーバ５０は、有効なリソースアドレスを用いて接続層４１を経て行なわれたリソース要求でしかアクセスすることができず、サーバ５０しかリソース要求にサービスできず、所与のサーバ５０は、１つ以上の他のサーバ５０により提供されるサービスを利用してそれ自身のサービスを構成することができ、そしてサーバ５０は、パネル５８を経てユーザに情報を与えない。
【００６４】
アプリケーション５２の特徴は、次の通りである。即ち、アプリケーション５２は、リソースを制御せず、アプリケーション５２は、ＩＳＩインターフェイスを経てサービスを提供せず、アプリケーション５２は、接続層４１を経て行なわれたリソース要求によりアクセスすることができず、アプリケーション５２は、１つ以上のサーバ５０のサービスを利用して特徴を形成し、そしてアプリケーション５２は、パネル５８を経てユーザに特徴を表示できるが、この機能を実行する必要はない。
トランザクションにおいてエンティティが演じる役割については、サーバ５０が、それ自身のリソースと、他のサーバ５０により与えられるサービスとを利用して、それ自身のサービスを形成することが考えられる。例えば、ＧＳＭ移動ステーションにおけるメモリサーチ特徴について考える。この例では、パネルサーバ６０及び電話帳サーバ５０により与えられるサービスを利用してメモリサーチ特徴を形成するアプリケーション５２がハンドポータブルユーザインターフェイスに存在する。このアプリケーション５２は、電話帳のエントリに名前を一致させるように電話帳サーバ５０に要求する。電話帳サーバは、その要求を処理し、そして最も近い一致のエントリ又はエラー指示で、その要求を発しているアプリケーション５２に応答する。
【００６５】
アプリケーションの要求を処理する際に、サーバ５０は、それ自身のリソース、例えば、電話機自身の電話帳メモリと、別のサーバのリソース、例えば、電話帳エントリがＳＩＭ２７に保持される場合にはＳＩＭサーバ５０とを使用することが要求される。この場合、アプリケーションの要求を処理するときに、電話帳サーバ５０は、それ自身で、ＳＩＭサーバ５０にリソース要求を発して、ＳＩＭ２７に記憶された電話帳エントリにアクセスしなければならない。最初のリソース要求を発したアプリケーション５２は、そのリソース要求を処理したサーバ５０がその要求を完了するためにそれ自身のリソース要求を行なわねばならないことを知らず、又、知る必要がない。
この形式の状態では、所与のエンティティがあるトランザクションにおいて受け持つ役割を識別するのが有用である。
【００６６】
トランザクションは、一連の通信、即ち２つのエンティティ間に通されるメッセージで構成される。各トランザクションにおいて、一方のエンティティがクライアントの役割を受け持ち、そして他方のタスクがサーバの役割を受け持つ。クライアントの役割は、リソース要求を発し、応答、指示又は協議要求を受け取り、或いは通知応答メッセージを送信するエンティティによって受け持たれる。アプリケーション５２又はサーバ５０として分類されるエンティティは、トランザクションにおいてクライアントの役割を受け持つ。サーバ５０の役割は、リソース要求にサービスし、協議要求を発し、指示メッセージを送信し、又は通知応答メッセージを受け取るエンティティにより受け持たれる。サーバ５０の役割は、サーバ５０として分類されるエンティティでしか受け持つことができない。アプリケーション５２は、サーバ５０の役割を決して受け持たない。あるエンティティは、１つのトランザクションにおいてサーバ５０の役割を受け持ち、例えば、リソース要求にサービスし、そして次のトランザクションにおいてアプリケーション５２の役割を受け持ち、即ちリソース要求を発すると考えられる。
【００６７】
アプリケーション５２は、１つ以上のサーバ５０の助けによりソフトウェアに対する特徴を実施する。移動ステーション１０の内部及び外部のアプリケーション５２は、同じサーバ５０インターフェイスを使用する。一般に、アプリケーション５２は、サーバ５０により与えられるリソースを使用する。サーバ５０は、接続層４１、即ち通信マネージャー４１Ａ及びＰｈｏＮｅｔを経て使用することができる。アプリケーション５２は、他のアプリケーション５２又は外部装置から事象を受け取る。アプリケーション５２は、ユーザとの入力及び出力オペレーションを実行するためにパネル５２を形成することができる。
【００６８】
本発明のここに示す好ましい実施形態ではその機能が通信マネージャー４１Ａに組み込まれたアプリケーションマネージャー（ＡＭ）５４は、タスク内のアプリケーション５２及びサーバ５０を管理する役割を果たす。アプリケーションマネージャー５４の多数のインスタンスがあり、その各々は、個別のＯＳタスクにおいて実行される。アプリケーションマネージャー５４（１つ又は複数）の役割は、新たなアプリケーション５２／サーバ５０を登録し、アプリケーション５２／サーバ５０を要求に応じて除去し、タスク内のアプリケーション５２／サーバ５０からの事象予約を管理し、予約するアプリケーション５２／サーバ５０へ事象を通し、そしてアプリケーションマネージャー５４の特定のインスタンスに関連した最初のアプリケーション５２（１つ又は複数）／サーバ５０（１つ又は複数）をスタートさせることを含む。
【００６９】
又、アプリケーションマネージャー５４に維持されるアプリケーション５２／サーバ５０のリストは、特定のタスクに対して通信マネージャー４１Ａでも使用される。たとえ所与のタスクが１つのアプリケーション５２又はサーバ５０しか含まなくても、アプリケーションマネージャー５４のインスタンスは依然として与えられる。
上記で参照したＶＡＳアプリケーション７０は、固定のアプリケーション、動的なアプリケーション及びダウンロード可能なアプリケーションに分割することができる。固定のアプリケーションとは、移動ステーション１０の外部からある情報を受信する永久的なアプリケーションであり、例えば、ネットワーク６６から受け取られるメッセージにより、新たなリンギングトーンが移動ステーション１０にプログラムされる（図１１参照）。動的なアプリケーションは、ネットワーク６６、例えば、インターネットブラウザとのより多くの相互作用を有する。ダウンロード可能なアプリケーションは、エアインターフェイスを経てネットワーク６６から移動ステーション１０へプログラムされるスクリプト言語又はオブジェクトコードで構成される。
【００７０】
外部アプリケーション（ＭＣＵ２１の外部）は、ハンドポータブルＵＩアプリケーションと同様であるが、別のプロセッサで実行される。それらは、ＩＳＩメッセージにより移動ステーション１０のパネル５８及びサーバ５０と通信する。その例として、パーソナルコミュニケータ型アプリケーション及び音声レコーダアプリケーションが含まれる。
ネットワークアプリケーションは、空気中を経て移動ステーションのリソースを使用する。移動ステーションのリソースの使用は、例えば、移動ステーション１０のＶＡＳアプリケーション７０によって制御される。
サーバ５０の種々の分類が存在する。一般に、サーバ５０は、１組のサービスを（任意の）アプリケーション５２に与える。サーバ５０は、移動ステーション１０の内部にあってもよいし外部にあってもよい。サーバ５０は、次のように、多数の分類に分けることができる。
【００７１】
デフォールトサーバ：サーバ５０は、あるリソースに対し全てのリソース要求がその特定のサーバに供給されるように接続層４１が構成されたときにそのリソースに対するデフォールトサーバである。
マルチサーバ：移動ステーション１０は、２つ以上の同様のリソース、即ち同じ形式のリソースを含むことができる。この場合に、各リソースは、それ自身のサーバ５０を有し、これは、移動ステーション１０及びそのアクセサリにおいて特定のリソース形式に対して２つ以上のサーバ５０が存在することを意味する。
例えば、多数の電話帳があってもよい。移動ステーション１０のパーソナルコミュニケータ実施形態では、パーソナルコミュニケータユニット及び無線ユニットの両方に電話帳が存在する。これらの電話帳は、両方とも、それ自身のサーバを有する。
【００７２】
更に、例えば、マルチモード移動ステーションにおいては、サポートされる各セルラー／コードレスシステム（例えば、ＡＭＰＳ及びＩＳ−１３６）に対して１つづつ、２種類のコールリソースがある。これら２つのコールリソースの各々は、それ自身のサーバ５０を有する。
動的サーバ：動的サーバは、コンパイル／構築時間の後にシステムに追加されるサーバである。動的サーバは、移動ステーション１０の内部に存在してもよいし（例えば、ダウンロード可能なソフトウェア）、又は移動ステーション１０に接続された他の装置に存在してもよい。
ディレクタ：移動ステーション１０及びそのアクセサリに多数のサーバ５０が存在する場合には、多数のサーバ５０間を裁定するために高い方の制御レベルに１つのエンティティが指定され、例えば、多数のサーバのどれがデフォールトサーバであるか定義する。このエンティティを、ここでは、ディレクタと称する。ディレクタは、多数のサーバ５０の１つであってもよいし、独立したエンティティであってもよい。
【００７３】
本発明のここに示す好ましい実施形態ではその機能が通信マネージャー４１Ａに組み込まれた事象サーバ５６は、サーバ５０からアプリケーション５２への事象分配を取り扱う。事象サーバ５６は、次の機能を有する。
アプリケーション５２は、事象サーバ５６の機能を使用して、特定リソースの事象を予約する（例えば、タイムキーピングリソースからのタイミング割り込み）。又、事象サーバ５６は、どのアプリケーション５２がどの事象に対して登録されるかの情報も記憶する。事象サーバ５６は、サーバ５０から全ての事象を受け取り、そしてそれら事象を受け取るように登録された全てのアプリケーション５２にそれらの事象を分配する。
【００７４】
アプリケーション５２は、１組のパネル５８を使用して、そのＩ／Ｏ機能を与える。パネルサーバ６０の目的は、アプリケーション５２から形式特有の情報を抽出して、それらのポータブル性を増大することである。アプリケーション５２とパネル５８との間のインターフェイスは、アプリケーション５２が移動ステーション１０の外部であってもよいことに基づくメッセージである。
従って、パネルサーバ６０は、アプリケーション５２とパネル５８との間の通信を取り扱うのに使用される。これは、パネル５８を形成及び削除する方法を与える。パネルサーバ６０は、現在パネル５８及び各パネルの相対的な優先順位を示す情報を含むスタックを記憶する。外部アプリケーション５２は、パネルサーバ６０からパネル（１つ又は複数）５８を指定することにより移動ステーションのキーボード２２及びディスプレイ２０を使用することができる。外部アプリケーション５２は、カスタマイズされたパネル又は予め定められたパネル５８を形成することができる。
【００７５】
最も関心の高い特殊なサーバについて説明すれば、システムモード制御（ＳＭＣ）サーバは、マルチモード移動ステーションの制御を取り扱う特殊なサーバである。マルチモード移動ステーションの一般的な目的は、２つあり、即ち異なるセルラー（又はコードレス）システムを１つに結合して、カバレージ及び容量に関して最適な性能を与え（移動ステーション１０は、１つの電話番号しか有していないが、異なるシステムをサポートする）、そして２つの異なる独立したシステムを１つに結合して、ユーザに１つのターミナルにおいて２つのシステムを与えることである。この後者のケースでは、移動ステーション１０は、各システムごとに電話番号を有する。
【００７６】
ＩＳＡにおけるＳＭＣサーバの役割は、外部（ＭＳＣ２１の外部、例えば、図１１に示すように、ＤＣＳ用のバッテリパックのＡＭＰＳ、ユニット６６）、及び内部（ＭＣＵ２１の内部、例えば、ＤＥＣＴ＋ＧＳＭ又はＰＤＳ＋ＰＨＳ）で実施することのできるセルラー（又はコードレス）システムソフトウェアの選択を制御することである。ＳＭＣサーバは、単一モードの移動ステーション（例えば、ＡＭＰＳ又はＧＳＭのみ）に含まれる必要はない。
ＳＭＣサーバは、マルチモード機能を特定のサーバ５０から分離するように働く。システム特有のサーバ５０は、例えば、コールサーバ、ショートメッセージサービス（ＳＭＳ）サーバ、補足サービス（ＳＳ）サーバ及びネットワーク選択（ＮＳ）サーバ５０を含む。この分離は、接続層４１の柔軟なコンフィギュレーションによって行なわれると共に、ルータ４０により確認されそれに作用する特殊なルート指定メカニズムを接続層４１に追加することによって行なわれるのが好ましい。
【００７７】
異なるシステムは、外部及び内部の両システムに対して同じアーキテクチャーを与える個別のシステムサーバ５０において実施される。更に、それらは、異なるシステムの完全な分離を与え、これは、システムコンフィギュレーションのモジュール性も向上させる。
図２２Ａ及び２２Ｂは、システム選択ルールを組み込んだシステムモード制御（ＳＭＣ）サーバ５０Ａの２つの実施形態と、アプリケーション５２及びシステムサーバ５０、特に、第１システムサーバ５０Ｂ及び第２システムサーバ５０Ｃへのその接続とを示している。図２２Ａの実施形態において、ＳＭＣサーバ５０Ａは、接続層４１を経て動作して、システムサーバ５０Ｂ及び５０Ｃの一方又は他方へのアプリケーション５２の接続を制御する。ＳＭＣサーバ５０Ａの動作は、単極双投（ＳＰＤＴ）スイッチ４１Ｂとして概略的に示されている。現在好ましいものである図２２Ｂの実施形態では、アプリケーション５２が接続層４１を経てＳＭＣサーバ５０Ａに接続され、次いで、ＳＭＣサーバ５０Ａは、又、接続層４１を経てシステムサーバ５０Ｂ及び５０Ｃの選択された一方に接続される。
【００７８】
図２２Ａの実施形態では、アプリケーション５２は、一般的なメッセージをシステムサーバ５０Ｂ又は５０Ｃに送信する。ＳＭＣサーバ５０Ａは、メッセージのルート指定に直接作用するように接続層４１のスイッチ４１Ａを制御する。
ルート指定の制御に加えて、ＳＭＣサーバ５０Ａは、他の多数のファンクションを実行する。これらは、どのシステムをアクティブにしなければならないか（システムの保留及び再開）を制御し、システムの１つをオフに切り換えるときに必要となる全てのファンクション（例えば、コール再送、オペレータセンターへの自動ダイヤル）を開始し、非アクティブなシステムにおける操作手順を制御し（例えば、各５分）、異なるシステムの選択を制御し（システムの優先順位に基づいて）、図２２Ａの実施形態において接続層４１のスイッチを制御し（ルートの制御）、ユーザが制御する動作（例えば、非アクティブなシステムへのコールの強制的設定、ユーザが開始する走査）を取り扱い、そしてアプリケーション５２、接続層４１、及びシステム特有のサーバ５０Ｂ及び５０Ｃと相互作用して、マルチモードの要求を満足させることを含む。
【００７９】
一般に、アプリケーション５２は、ＩＳＩサーバインターフェイスを経て移動ステーション１０のリソースを使用することによりそれらの特徴を形成する。アプリケーション５２は、接続層４１にリソース要求を行う。接続層４１は、各リソース要求を、そのリソースに対してアクティブであるように現在構成されたサーバ５０、通常、デフォールトサーバへマップする。このような全てのサーバコンフィギュレーションテーブルは、ＭＣＵ２１により接続層４１に記憶及び維持される。リソース−サーバマッピングのデフォールトコンフィギュレーションはコンパイル時に定義されるが、実行時間中にマッピングを変更できる。サポートされていないシステムリソースを使用するよう試みるアプリケーション５２は、応答メッセージにおいて「非サポート」指示を受け取る。要約すると、上述したように、接続層４１は、接続されたサーバ５０及びアプリケーション５２を検出し、登録しそしてアドレスする役割を果たす。又、接続層４１は、リソース名からリソースの論理的アドレスへの、そして論理的アドレスから物理的アドレスへのメッセージルート指定を取り扱う。送信者は、メッセージが同じプロセッサのエンティティに向かっているか、ある物理的バスの後方にあるアクセサリ装置のエンティティに向かっているかを知る必要がない。接続層４１は、ＩＳＩインターフェイスの後方の実際の物理的位置をマスクする。
【００８０】
アプリケーション５２及びサーバ５０は、通信のために通信マネージャー４１Ａを使用する。通信マネージャー４１Ａは、通信のターゲットが同じＯＳタスクに位置しているかどうか決定するチェックを行う。もしそうであれば、通信がそのターゲットにルート指定される。ターゲットが同じＯＳタスクに存在しない場合には、通信マネージャー４１Ａは、その要求をＩＳＩメッセージとしてＰｈｏＮｅｔへ通す。次いで、ＰｈｏＮｅｔは、適当なＯＳタスクのメールボックスにメッセージを供給するか、又はターゲットが別の装置に位置している場合には、シリアルＩＲバス１８Ｃのような適当な媒体を経てその装置へメッセージを通す。応答メッセージは、同様に、通信マネージャー４１Ａにより送信者へ直接ルート指定されるか、又はＰｈｏＮｅｔにより送信者のＯＳタスクの通信マネージャーへルート指定される。アプリケーション５２又はサーバ５０のいずれかを含む各ＯＳタスクごとに通信マネージャー４１Ａの１つのインスタンスがある。
【００８１】
エンティティ（アプリケーション５２及びサーバ５０）間の通信は、メッセージをベースとするものである。これらメッセージは、タスクからタスクへのＯＳメッセージであるか、又はある物理的バス（例えば、ＦＢＵＳ、ＩＲリンク）を経て送信されるメッセージである。メッセージは、ＩＳＩ要求、応答及び指示である。
アプリケーション５２とサーバ５０との間の通信は、次のグループに分割される。
リソース要求は、移動ステーション１０の１つのリソースを使用するよう要求するアプリケーション５２によって発生される。リソース要求は、接続層４１によりアプリケーション５２からサーバ５０へ通される。リソース要求によって開始されたオペレーションの結果をその要求を発したアプリケーション５２へ返送するためにサーバ５０により応答が送られる。
【００８２】
サーバ５０が制御するリソースに関する状態情報を１つ以上のアプリケーション５２へ通すために、ここで通知又は事象とも称される指示がサーバ５０により送信される。
この状態情報は、アプリケーション（１つ又は複数）５２へ事象を報告するためにサーバ５０により送信することができ、この事象は、サーバ５０が制御するリソースに生じたものである。この場合に、事象は、アプリケーション５２からのリソース要求によって直接生じたものではない。このような事象の一例は、コールサーバにより受信された入呼びである。
【００８３】
状態情報は、オペレーションの進行状態をアプリケーション（１つ又は複数）５２へ報告するためにサーバ５０により送信することができる。この特定の状態情報は、オペレーションの結果ではなく、応答メッセージにおいて与えられる。
又、状態情報は、アプリケーション５２からサーバ５０へ発せられるリソース要求により生じたオペレーションに応答して送信されてもよい。オペレーションは、サーバ５０が制御するリソースにおいて行なわれる。
又、アプリケーション５２とサーバ５０との間の通信は、次のものも含む。
【００８４】
協議要求は、アプリケーション５２によりなされたリソース要求で開始された動作を遂行するサーバ５０により送信される。サーバ５０の処理を続けるためには、その要求を開始したアプリケーション５２からある情報を必要とする。その必要な情報は、例えば、サーバ５０がアプリケーション５２に事象を通知し且つアプリケーション５２と「ハンドシェーク」する（例えば、サーバが処理を続行すべきかどうか要求するために）必要があるというものである。又、協議要求は、アプリケーション５２からより多くの情報を得て処理を続行できるようにするために、サーバ５０によって送信されてもよい。
【００８５】
最後に、サーバ５０から受信した協議要求に応答するために、通知応答がアプリケーション５２によって送信される。この通知応答は、サーバ５０により要求される追加情報を含むことができる。
メッセージの性質を指示するために全てのメッセージ識別子に次のサフィックスが添付される。
＿ＲＥＱ リソース要求
＿ＲＥＳＰ リソース要求に対する応答
＿ＩＮＤ 指示
＿ＣＯＮＳ 協議要求
＿ＩＮＦ 通知応答
【００８６】
アプリケーション５２と、接続層４１（通信マネージャー４１Ａ及びＰｈｏＮｅｔ）と、サーバ５０と、種々のサブシステムとの間の通信は、図１３、１４及び１５に示すメッセージシーケンスチャートを参照して説明する。これらの図において、アプリケーション５２及びサーバ５０は、ＭＣＵ２１の内部又は外部にある。各図において、同じプロトコルが説明され、即ちアプリケーション５２はリソース要求を送信し、そしてリソースをサポートするサーバ５０は、リソース要求を受信し、その要求を発しているアプリケーション５２へ応答を返送する。
図中に使用される幾つかの省略形は、ｆ.コール＝ファンクションコール、ＩＦ＝インターフェイス、ＭＳＧ＝メッセージ、ｒ.値＝返送値（ファンクションの）、ＲＥＱ＝要求、ＲＥＳＰ＝応答、ＣＭ＝通信マネージャーである。
【００８７】
先ず、図１３を参照すれば、アプリケーション５２及びサーバ５０は、同じＯＳタスクにあり、ＣＭ４１Ａは、アプリケーション５２からＩＳＩメッセージの形態でリソース要求を受け取る。ＣＭ４１Ａは、このリソース要求にサービスするサーバ５０が同じＯＳタスクに位置していると決定する。ＣＭ４１Ａは、リソース要求をサーバ５０に供給する。もし必要であれば、サーバ５０は、リソース要求を解読して、サブシステム４８のインターフェイスファンクションコールに変換する。サブシステムの応答は、ＯＳメッセージであるか、又はインターフェイスファンクションの返送値である。サーバ５０は、ここで、応答メッセージを形成するのに必要なデータをもつ。サーバ５０は、リソース要求に対する応答をＣＭ４１Ａへ通し、次いで、ＣＭ４１Ａは、その応答を、要求を発しているアプリケーション５２へ通す。
【００８８】
図１４を参照すれば、アプリケーション５２及びサーバ５０は、同じプロセッサ（ＭＣＵ２１）内に位置するが、異なるＯＳタスクにあり、第１のＣＭ４１Ａ（ＣＭ＃１）は、ＩＳＩメッセージの形態でアプリケーション５２からリソース要求を受信する。ＣＭ＃１は、このリソース要求にサービスするサーバ５０が同じＯＳタスクに位置していないことを決定する。ＣＭ＃１は、リソース要求をＰｈｏＮｅｔへ通し、そしてＰｈｏＮｅｔは、そのリソースに対しサーバ５０を含むように構成されたタスクのＯＳメールボックスにそのメッセージを供給する。
そのタスクの第２のＣＭ４１Ａ’（ＣＭ＃２）は、ＯＳメールボックスを読み取り、そしてメッセージをサーバ５０へ供給する。もし必要であれば、サーバ５０は、リソース要求を解読し、そしてそれをターゲットサブシステム４８のインターフェイスファンクションコール（１つ又は複数）に変換する。サブシステムの応答は、ＯＳメッセージであるか、又はインターフェイスファンクションの返送値である。サーバ５０は、ここで、応答メッセージを形成するのに必要なデータをもつ。応答メッセージは、最初に送信されたリソース要求メッセージのヘッダに含まれたＯＳタスクにアドレスされる（上記のテーブル６を参照）。サーバ５０は、リソース要求に対する応答をＣＭ＃２へ返送し、ＣＭ＃２は、その応答メッセージをＰｈｏＮｅｔへ供給し、そしてＰｈｏＮｅｔは、その応答をＣＭ＃１へ転送する。アプリケーション５２のタスクに位置するＣＭ＃１は、そのメッセージを受け取り、そして要求を発しているアプリケーション５２に応答を返送する。
【００８９】
図１５を参照すれば、アプリケーション５２及びサーバ５０は、異なるプロセッサに位置する。先ず、ＣＭ＃１は、アプリケーション５２からＩＳＩメッセージの形態でリソース要求を受信する。ＣＭ＃１は、このリソース要求にサービスするサーバ５０が同じＯＳタスクに位置していないことを決定する。ＣＭ＃１はリソース要求をＰｈｏＮｅｔ＃１へ通す。ＰｈｏＮｅｔ＃１は、リソース要求メッセージを、リソースを含むように構成された装置へ供給する。ＰｈｏＮｅｔ＃１は、例えば、上記のようにＰｈｏＮｅｔ＃１で登録したときに装置により指定された好ましいリンクから決定されたＩＲリンク１８Ｃのような適当なリンクを経てリソース要求メッセージを供給する。装置のＰｈｏＮｅｔ＃２は、選択されたリンクからリソース要求メッセージを受け取り、そしてそのメッセージを、そのリソースに対してサーバ５０を含むように構成されたタスクのＯＳメールボックスに供給する。そのタスクのＣＭ＃２は、メールボックスを読み取り、そしてサーバ５０にメッセージを供給する。もし必要であれば、サーバ５０は、リソース要求を解釈し、そしてそれをサブシステムインターフェイスファンクションコール（１つ又は複数）に変換する。サブシステムの応答は、ＯＳメッセージであるか、又はインターフェイスファンクションの返送値である。サーバ５０は、ここで、応答メッセージを形成するに必要なデータを有し、このメッセージは、リソース要求メッセージのヘッダに含まれた装置及びオブジェクトにアドレスされる。サーバ５０は、応答メッセージをＣＭ＃２へ返送し、ＣＭ＃２は、応答メッセージをＰｈｏＮｅｔ＃２へ供給し、そしてＰｈｏＮｅｔ＃２は、応答メッセージを元の装置のＰｈｏＮｅｔ＃１へ供給する。ＰｈｏＮｅｔ＃１は、応答メッセージを受信し、そしてその応答メッセージをＯＳメッセージとしてターゲットタスクにルート指定する。ＣＭ＃１は、このＯＳメッセージを受け取り、そして応答メッセージを、その要求を発しているアプリケーション５２に返送する。
【００９０】
本発明の特徴によるインテリジェントサービスインターフェイス（ＩＳＩ）について以下に詳細に説明する。
ＩＳＩサーバ５０は、そのサーバ５０とクライアントとの間にインターフェイスを「所有」する（クライアントは、アプリケーション５２、又はＩＳＩサーバを使用する別のサーバ５０である）。従って、ＩＳＩサーバへ及びそこから送信されるメッセージは、常に、ＩＳＩサーバの所望のフォーマットで表わされるのであって、要求を発しているクライアントのフォーマットで表わされるのではない。これは、ＩＳＩサーバインターフェイスが、それを使用するクライアントとは独立して定義され、それ故、いかなるクライアントでもＩＳＩサーバのサービスを利用できるように確保する。
【００９１】
ＩＳＩメッセージのサフィックスは、メッセージを、それが使用されるコンテクストを示すやり方で定義できるようにする。サフィックスを理解することから得られる情報は、誰がメッセージの送信者であり、クライアントであり又はＩＳＩサーバであるか、誰がメッセージの意図された受信者であり、クライアントであり又はＩＳＩサーバであるか、そしてどんなコンテクストにおいてメッセージが送信されたかを含む。即ち、そのメッセージは、手前のメッセージの結果であるか、又はメッセージが新たな要求を開始したかを含む。
ＩＳＩサーバとそのクライアントとの間の通信に使用されるメッセージは、リソース要求、応答、指示、協議要求、及び通知応答メッセージを含むように上記で定義された。
各ＩＳＩメッセージは、メッセージヘッダを含む。このメッセージヘッダは、ＰｈｏＮｅｔメッセージヘッダに続くものである。メッセージのデータ部分の第１部分は、全てのＩＳＩメッセージ間で共通である。
【００９２】
基本的なＩＳＩメッセージフォーマットを次のテーブルに示す。第１の蘭のＨ又はＤは、フィールドがメッセージのヘッダ部分であるかデータ部分であるかを示す。

【００９３】
ＩＳＩメッセージ仕様は、各メッセージごとに完全なＩＳＩメッセージ記述を含む必要がない。というのは、メッセージヘッダにおける多くのフィールドが全てのメッセージに対して同様に取り扱われるからである。ＩＳＩメッセージ仕様は、ＩＳＩメッセージを記述するために次のフォーマットを使用する。

【００９４】
各ＩＳＩメッセージごとに次のＩＳＩメッセージフィールドが指定される。
リソース − このフィールドは、メッセージが属するリソース（ひいては、サーバ５０）、例えば、ＩＳＩ＿ＰＮＤ（電話番号ディレクトリ）、ＩＳＩ＿ＣＡＬＬ、ＩＳＩ＿ＭＥＮＵ、等を示す。
独特なトランザクションＩＤ（ＵＴＩＤ） − このフィールドは、どのトランザクションにメッセージが属するかを識別するのに使用される。
メッセージＩＤ − このフィールドは、リソース内の特定のメッセージを示す。
メッセージデータ − これらのバイトは、特定のメッセージ仕様で示されたメッセージの内容である。
例えば、リソース要求メッセージに対しＩＳＩメッセージを形成するために、リソース要求（ｍｅｓｓａｇｅ ｔｙｐｅ＿ＲＥＱ）は、接続層４１の「ソースによるルート」特徴を使用して、要求を発しているアプリケーション５２からのリソース要求を、その要求にサービスするための適当なサーバ５０へ供給する。これは、要求を発しているアプリケーション５２が、ＩＳＩリソース要求メッセージを形成するときに受信者の装置及びオブジェクトアドレスを知る必要がないことを意味する。
【００９５】
以下のテーブルは、リソース要求を形成するのに使用されるＩＳＩメッセージを形成するための特定情報を示す。

【００９６】
更に、例えば、他の全ての形式のメッセージに対してＩＳＩメッセージを形成するために、メッセージ形式＿ＲＥＳＰ.＿ＩＮＤ.＿ＣＯＮＳ及び＿ＩＮＦは、全て、接続層４１の「受信者アドレスによるルート」特徴を使用する。これは、メッセージを送信するエンティティ（アプリケーション５２又はサーバ５０）が受信者のアドレスを予め知らねばならないことを意味する。一般に、受信者のアドレスは、トランザクション又は以前のトランザクションにおける早期の通信により送信者に知られる。以前の通信又は以前のトランザクションは、図１３−１５の例を参照して上述したように、これらメッセージ形式の性質によって行われる。
【００９７】
以下のテーブルは、受信者へ直接送信されるべきＩＳメッセージを形成するための情報を与える。

【００９８】
ＩＳＩは、非同期メッセージ通過システムである。ＩＳＩメッセージを使用して通信するエンティティは、分配することができる。エンティティは、同じプロセッサ又は別々のプロセッサにおいて同じＯＳタスク又は別々のＯＳタスク内に位置する。エンティティは、同時に１つ以上のエンティティを伴う送信及び受信メッセージである。アプリケーション５２は、多数のサーバ５０のサービスを利用することができ、そしてサーバ５０は、それらのサービスを多数のアプリケーション５２に提供することができる。
インターフェイスが非同期であることは、エンティティが、それらが送信したメッセージに対する応答をいつ受け取るか確かめられないことを意味する。エンティティを分散できることにより、メッセージ送信待ち時間は、行先の位置と、メッセージを供給する媒体とに基づいて、メッセージごとに異なる。アプリケーション５２とサーバ５０との間の関係は、所与のエンティティが一度に多数のエンティティとの多数の通信をアクティブにすることを意味する。
【００９９】
上記の特性により、ＩＳＩシステムは、非同期通信、分散型通信及び多数の同時通信の作用を容易に取り扱えるように、アプリケーション５２及びサーバ５０がそれらの通信を編成できるようにするサポートを与える。
ＩＳＩは、メッセージの通過を編成するためのトランザクションを使用する。トランザクションは、２つのエンティティ間に通される通信（即ちメッセージ）のシーケンスである。各トランザクションにおいて、一方のエンティティがクライアントの役割を受け持ち、そして他方のエンティティがサーバの役割を受け持つ。クライアントの役割は、リソース要求を発し、応答、指示又は協議要求を受け取り、或いは通知応答メッセージを送信するエンティティによって受け持たれる。アプリケーション５２又はサーバ５０として分類されるエンティティは、トランザクションにおいてクライアントの役割を受け持つことができる。サーバの役割は、リソース要求にサービスし、協議要求を発し、指示メッセージを送信し、又は通知応答メッセージを受信するエンティティによって受け持たれる。サーバの役割は、サーバ５０として分類されるエンティティでしか受け持つことができない。定義により、アプリケーション５２は、サーバの役割を決して受け持たない。
【０１００】
あるエンティティは、１つのトランザクションにおいてサーバの役割を受け持ち、例えば、リソース要求にサービスし、そして次のトランザクションにおいてクライアントの役割を受け持ち、即ちリソース要求を発することが考えられる。
次の形式のトランザクションは、ＩＳＩメッセージに対し本発明の教示により包含される。
− リソース要求トランザクション、
− 事象指示トランザクション、
− 後続動作を伴う事象指示トランザクション、及び
− 協議要求トランザクション。
リソース要求トランザクションは、アプリケーション５２がリソース要求メッセージを送信するときにスタートする。上述したように、リソース要求メッセージは、接続層４１により、要求を発しているアプリケーション５２から、要求にサービスする適当なサーバ５０へ通される。次いで、サーバ５０は、その要求を満足させる。サーバ５０は、要求を処理するときに、要求を発しているアプリケーション５２に要求の進行を通知する指示メッセージで応答するか、或いは要求を発しているアプリケーション５２に協議要求を発しそしてその応答として通知応答を受け取ることもできる。リソース要求トランザクションは、サーバ５０が、リソース要求を発するアプリケーション５２に応答メッセージで応答するときに終了となる。
【０１０１】
例１：
図１６は、アプリケーション５２がリソース要求を電話番号ディレクトリ（ＰＮＤ）サーバ５０へ発することを含むリソース要求トランザクションの一例を示す。ＰＮＤサーバ５０は、その要求を処理し、そしてその要求を発しているアプリケーション５２に応答メッセージを送信する。これで、リソース要求トランザクションが終了となる。
例２：
図１７は、アプリケーション５２がリソース要求をコールサーバ５０に発することを含むリソース要求トランザクションの一例を示す。コールサーバ５０は、その要求を処理する。コールサーバ５０は、要求を発しているアプリケーション５２に指示メッセージ（例えば、コール処理、コール呼出し、コール接続等）を送信することによりその要求の進行を報告する。最終的に、リソース要求が完了し、そしてコールサーバ５０は、要求を発しているアプリケーション５２に応答（ＲＥＳＰ）メッセージを送信する。これで、リソース要求トランザクションが終了となる。
【０１０２】
例３：
図１８は、アプリケーション５２がリソース要求をＰＮＤサーバ５０に発することを含むリソース要求トランザクションの一例を示す。ＰＮＤサーバ５０は、その要求を処理する。要求の処理中に、ＰＮＤサーバ５０は、外部メモリを読み取らねばならないので、要求を発しているアプリケーション５２から進行すべきかどうかチェックしなければならないことを発見する。ＰＮＤサーバ５０は、協議要求（ＣＯＮＳ）をアプリケーション５２に発する。アプリケーション５２は、外部メモリからの読み取りに対して許可を与える通知応答（ＩＮＦ）メッセージで協議要求サーバ５０に応答する。次いで、ＰＮＤサーバ５０は、リソース要求を完了する。ＰＮＤサーバ５０は、要求を発しているアプリケーション５２に応答メッセージを送信する。これで、リソース要求トランザクションが終了となる。
【０１０３】
事象指示トランザクションは、サーバ５０が事象の指示を１つ以上のアプリケーション５２に指示メッセージの形態で送信するときにスタートする。アプリケーション５２（１つ又は複数）は、指示を受信するように既に登録している。事象指示は、事象が生じたサーバ５０からアプリケーション５２へ通される。事象指示トランザクションは、事象指示（１つ又は複数）を受信するよう登録されたアプリケーション５２（１つ又は複数）に事象指示メッセージが送られたときに終了となる。
例４：
図１９は、サーバ５０がＣａｌｌ＿Ｃｏｍｉｎｇ＿ＩＮＤをアプリケーション５２（１つ又は複数）へ送信するときに開始される事象指示トランザクションの一例を示す。次いで、このトランザクションが完了する。アプリケーション５２は、サーバ５０から事象指示を受信するように既に登録されている。
【０１０４】
事象指示トランザクションは、図１９に示すように、事象指示メッセージがアプリケーション５２へ首尾良く供給されたときに終了となる。しかしながら、事象指示トランザクションが継続することが考えられる。この場合に、トランザクションは、後続動作を伴う事象指示トランザクションとなる。
事象指示メッセージを受け取るアプリケーション５２は、リソース要求を発することにより指示メッセージに反応し、そしてその後のリソース要求トランザクションを、受け取った事象指示トランザクションと結合しようとする。このようになるのは、サーバ５０が多数の事象指示を送信し、そしてアプリケーション５２が、どの指示に対して「応答」するか明確にしたいためである。この場合に、その後のリソース要求トランザクションは、後続動作を伴う事象指示トランザクションの一部分であるとみなされる。後続動作を伴う事象指示トランザクションは、サーバ５０が、アプリケーション５２により発せられたリソース要求に対して応答メッセージを送信するときに終了すると考えられる。
【０１０５】
アプリケーション５２は、リソース要求を発することにより指示メッセージに反応しようとするが、リソース要求を指示メッセージに直接結合しようとはしない。この場合に、その後のリソース要求は、通常のリソース要求トランザクションとして行なわれる。
例５：
図２０は、セキュリティ（ＳＥＣ）サーバ５０が、事象指示を受け取るように既に登録されたアプリケーション５２（１つ又は複数）にＳＥＣ＿Ｃｏｄｅ＿Ｒｅｑｕｉｒｅｄ＿ＩＮＤメッセージを送信するときに開始される後続動作を伴う事象指示トランザクションの一例を示す。事象指示を受け取る１つのアプリケーション５２は、次いで、事象指示に結合されるリソース要求を発する。リソース要求はＳＥＣ＿Ｃｏｄｅ＿Ｖｅｒｉｆｙ＿ＲＥＱである。ＳＥＣサーバ５０は、要求を発しているアプリケーション５２に応答メッセージ（ＳＥＣ＿Ｃｏｄｅ＿Ｖｅｒｉｆｙ＿ＯＫ＿ＲＥＳＰ）で応答する。これで、後続動作を伴う事象指示トランザクションが終了となる。
【０１０６】
協議要求トランザクションは、サーバ５０が協議要求をアプリケーション５２へ送信するときにスタートし、協議要求は、進行中のリソース要求トランザクションの一部分ではない。協議要求メッセージは、接続層４１により協議要求サーバ５０から適当なアプリケーション５２へ通される。アプリケーション５２は、必要な動作を実行する。協議要求トランザクションは、アプリケーション５２が、協議要求を行ったサーバ５０に通知応答メッセージで応答するときに終了となる。
例６：
図２１は、メニューサーバ５０が、メニューサーバ５０のサービスを利用するように既に登録されたアプリケーション５２へ協議要求メッセージを送信するときに開始される協議要求トランザクションの一例を示す。アプリケーション５２は、協議要求サーバ５０に対して通知応答で協議要求に応答する。これで、協議要求トランザクションは終了となる。登録の後に、アプリケーション５２は、ＭＥＮＵ＿Ｅｎｔｒｙ＿Ａｄｄ＿ＲＥＱ（リソース要求）をメニューサーバ５０に送信し、そしてその応答において、メニューサーバ５０からＭＥＮＵ＿Ｅｎｔｒｙ＿Ａｄｄ＿ＯＫ＿ＲＥＳＰを受け取る。ユーザが、例えば、移動ステーション１０のキーパッド２２及びディスプレイ２０のユーザインターフェイスとの相互作用によりメニューを選択した後に、実際の協議要求トランザクションが開始される。
【０１０７】
上述したように、各トランザクションは、独特のトランザクションＩＤ（ＵＴＩＤ）を有する。このＵＴＩＤは、トランザクションに含まれるエンティティにより、メッセージを特定のトランザクションに一致させるために使用される。これは、アプリケーション５２及びサーバ５０が２つ以上のトランザクションにおいて２つ以上のエンティティと同時にアクティブになるようにし、しかも、要求及び応答メッセージを適宜に一致させられるようにする。
各トランザクションにおいて、通信エンティティの１つは、トランザクションの発信者として指定される。この発信者は、トランザクションに対してＵＴＩＤを割り当てそしてその割り当てられたＵＴＩＤをトランザクションの第１メッセージに含ませる役割を果たす。次いで、発信者及び他の通信エンティティは、割り当てられたＵＴＩＤをそのトランザクションの各後続メッセージに使用する。
【０１０８】
発信者は、行なわれるトランザクションの形式に基づいて指定され、トランザクションにおいて通信する第１のエンティティである。次のテーブルは、各トランザクション形式における発信者を示す。
トランザクション 発信者
リソース要求 要求を発するアプリケーション５２
事象指示 指示サーバ５０
後続動作を伴う事象指示 指示サーバ５０
協議要求 協議要求サーバ５０
ＩＳＩを経て通信しようとする各エンティティは、それ自身のＵＴＩＤカウントを維持する。あるエンティティが、あるトランザクションにＵＴＩＤを割り当てるときには、それ自身のＵＴＩＤカウントを増加し、そしてそしてそれを、トランザクションを開始するメッセージのメッセージヘッダの独特なトランザクションＩＤフィールドに含ませる。ＵＴＩＤは、例えば、８ビット値である。ＭＳＢは、ＵＴＩＤがクライアントにより所有されるかサーバ５０により所有されるかを指示するのに使用される。残りの７ビットは、エンティティのＵＴＩＤカウント値を含む。エンティティは、それらのＵＴＩＤカウントを設定時に全てゼロに初期化する。
【０１０９】
エンティティは、メッセージと、それが属するトランザクションを、ＵＴＩＤ、他の通信エンティティのアドレス、リソース及びメッセージＩＤの組み合せを使用して識別することができる。ほとんどの場合に、メッセージがどのトランザクションに属するかを識別するのに、幾つかのこれら要素の組合せしか必要とされない。次のテーブルは、多数の例を示す。

【０１１０】
以上、多数の物理的接続媒体（例えば、ＩＲ、ＲＦ又は有線）の選択によって無線電話と多数のアクセサリ装置の１つとの間で通信するためのインターフェイスが説明されたことが明らかである。本発明の特徴は、２つの別々の層、（１）メッセージをアクセサリ装置から／へルート指定し、インターフェイスの機能を制御し、そしてリンクの状態を追跡するためのルータ層、及び（２）ルータ層のメッセージを物理的接続に適したフォーマットに変換するための接続層、を有するＰｈｏＮｅｔインターフェイスを備えている。更に、接続層は、（１）制御ユニットと、（２）媒体モジュールと、（３）フレームフィルタとを備えている。ＩＳＩ（インテリジェントサービスインターフェイス）は、ＰｈｏＮｅｔインターフェイスを使用してメッセージをルート指定するためのメッセージ送信概念である。異なる物理的接続形式を有する個々のアクセサリ装置は、ＰｈｏＮｅｔ／ＩＳＩを経て互いに通信する。同様に、電話の個別のソフトウェアモジュールがＰｈｏＮｅｔ／ＩＳＩを経て通信することができる。電話のＰｈｏＮｅｔ／ＩＳＩインターフェイス、及びアクセサリ装置のＰｈｏＮｅｔ／ＩＳＩは、マスター／スレーブ関係を有する。ＰｈｏＮｅｔ／ＩＳＩは、モジュラーソフトウェアアーキテクチャＩＳＡをサポートするインターフェイスアーキテクチャーである。ＰｈｏＮｅｔは、全ての形式のアクセサリに対する普遍的電話インターフェイスであり、通常、電話又はバッテリパックに含まれたワイヤード又はワイヤレスコネクタに接続される。ＰｈｏＮｅｔの２つの個別層は、「プラグ及びプレイ」型操作の機能を与える。電話が既にサポートするものとは異なる物理的接続を伴う新たなアクセサリ装置は、新たな媒体モジュールを接続層にロードすることにより電話に接続することができる。
【０１１１】
好ましい実施形態について以上に説明したが、これらの教示に対して多数の変更がなされ得ることが当業者に明らかであろう。例えば、本発明の教示は、以上に述べた特定のメッセージフォーマット、プロトコル、フィールドサイズ、及びフィールドの順序のみに限定されるものではない。又、本発明の教示は、以上に述べたサーバ、サブシステム、リソース、及びアプリケーションの特定の１つのみに限定されるものでもない。更に、ワイヤード及びワイヤレスに加えて他の媒体形式も使用できるので、ＦＢＵＳ、ＭＢＵＳ及びワイヤレスバス１８Ａ−１８Ｂより多くのもの又はそれより少ないものを使用してもよい。例えば、あるアプリケーションでは、光ファイバリンクを使用することもできる。
従って、本発明の好ましい実施形態を図示して説明したが、当業者であれば、本発明の範囲及び精神から逸脱せずに、その形態及び細部に変更がなされ得ることが理解されよう。
【図面の簡単な説明】
【図１】 本発明により構成されて動作される移動ステーションのブロック図である。
【図２】 図１に示す移動ステーションの斜視図であり、移動ステーションがワイヤレスＲＦリンクを経て両方向接続されるセルラー通信システムも示す図である。
【図３】 本発明による電話及びネットワーク、周辺ホスト−オブジェクトネットワーク（ＰｈｏＮｅｔ）システムの一部分を形成するルータ層及び接続層を示す簡単なブロック図である。
【図４】 ＰｈｏＮｅｔシステムに使用される論理的アドレスのフォーマットを示す図である。
【図５】 ＰｈｏＮｅｔメッセージパイプの動作を理解する上で有用な図である。
【図６】 ＰｈｏＮｅｔメッセージパイプの動作を理解する上で有用な図である。
【図７】 ＯＳメッセージサービスを１つの媒体とみなして、ＰｈｏＮｅｔメインルータ及び１つ以上の媒体駆動メッセージリンクの相互接続例を示す図である。
【図８】 「コール形成」メッセージに対し装置とメインルータとの間のメッセージの流れを例示する図である。
【図９】 オブジェクト（アプリケーション）から、ルータ層及び接続層を経、ＭＣＵ／ＤＳＰインターフェイス（ＩＦ）を経て、要求された物理的媒体（例えば、ＩＲハードウェア（ＨＷ））へ至るメッセージの流れを例示する図である。
【図１０】 無線ユニットに接続されたアクセサリ装置を伴うＰｈｏＮｅｔシステムのソフトウェアアーキテクチャーを示す高レベル図である。
【図１１】 無線ユニットと、複数の異なる外部装置、例えば、パーソナルコンピュータ、外部無線ユニット、及びセルラーネットワークアプリケーションとを伴うＰｈｏＮｅｔシステムの物理的アーキテクチャーを示す高レベル図である。
【図１２】 ＰｈｏＮｅｔシステムのタスクの概要を示す高レベル図である。
【図１３】 アプリケーション及びサーバが同じタスク内にある場合のメッセージシーケンスを例示するチャートである。
【図１４】 アプリケーション及びサーバが同じプロセッサにあるが、異なるタスクにある場合のメッセージシーケンスを例示するチャートである。
【図１５】 アプリケーション及びサーバが異なるプロセッサにある場合のメッセージシーケンスを例示するチャートである。
【図１６】 アプリケーションが電話番号ディレクトリ（ＰＮＤ）サーバにリソース要求を発する場合のトランザクションを例示するチャートである。
【図１７】 アプリケーションがコールサーバにリソース要求を発する場合のトランザクションを例示するチャートである。
【図１８】 アプリケーションがＰＮＤサーバにリソース要求を発する場合のトランザクションを例示するチャートで、ＰＮＤが、進行すべきアプリケーションから許可を得なければならないことを決定するところを示す図である。
【図１９】 コールサーバから事象指示を受信するように既に登録されたアプリケーション（１つ又は複数）へコールサーバがＣａｌｌ_Ｃｏｍｉｎｇ_ＩＮＤを送信する場合の事象指示トランザクションを例示するチャートである。
【図２０】 事象指示に結合されるリソース要求をアプリケーションが行うような後続動作を含む事象指示トランザクションを例示するチャートである。
【図２１】 サーバが協議要求をアプリケーションに送信しそして協議要求が進行中のリソース要求トランザクションの部分でない場合の協議要求トランザクションを例示するチャートである。
【図２２Ａ】 システム選択ルールを組み込んだシステムモード制御（ＳＭＣ）サーバの実施形態と、アプリケーション及びシステムサーバへのその接続とを示す図である。
【図２２Ｂ】 システム選択ルールを組み込んだシステムモード制御（ＳＭＣ）サーバの実施形態と、アプリケーション及びシステムサーバへのその接続とを示す図である。

Claims (33)

1. 無線トランシーバ(12,14,16)、複数のオブジェクト(52)及び複数のリンク(41,18A,18B,18C,42,43A,43B,43C)を含む無線ユニット装置(10)を備え、少なくとも１つのリンクは上記オブジェクト間にメッセージを転送するためのものである通信システムにおいて、上記無線ユニット装置は、更に、オブジェクトから登録要求を受け取り、その要求を発しているオブジェクトを登録し、そして登録されたオブジェクトを記述する情報を維持するためのメッセージルータ(40)を含むことを特徴とする通信システム。
2. メッセージは、メッセージの行先の論理的アドレスを含み、上記ルータは、メッセージの受信に応答して、論理的アドレスを少なくとも１つの物理的アドレスに変換すると共に、リンクを経て少なくとも１つの物理的アドレスにメッセージを向ける請求項１に記載の通信システム。
3. メッセージは、メッセージの行先の機能的記述を含み、上記ルータは、メッセージの受信に応答して、機能的記述を少なくとも１つの物理的アドレスに変換すると共に、リンクを経て少なくとも１つの物理的アドレスにメッセージを向ける請求項１に記載の通信システム。
4. 上記ルータは、接続を確立する要求に応答し、上記複数のリンクの１つを使用して、上記複数のオブジェクトの２つの間に直接的通信パイプを設定する請求項１ないし３のいずれかに記載の通信システム。
5. 上記複数のリンクの少なくとも１つを経て上記無線ユニット装置に接続された少なくとも１つの外部アプリケーション(52)より成る少なくとも１つの外部装置(28,60,62,64,68)を更に備え、上記メッセージルータは、上記少なくとも１つの外部装置及び上記少なくとも１つの外部アプリケーションから登録要求を受け取るように動作できる請求項１ないし４のいずれかに記載の通信システム。
6. 上記メッセージルータは、更に、登録要求により指定された好ましいリンクの認識、又は登録要求が受信されたところのリンクの認識の少なくとも一方を記録するように動作できる請求項５に記載の通信システム。
7. 上記登録要求の少なくとも１つの形式は、登録するアプリケーションに対するリンクの優先順を含む請求項１ないし６のいずれかに記載の通信システム。
8. 上記外部装置は、メッセージサブルータ(40')を含む請求項５ないし７のいずれかに記載の通信システム。
9. 上記メッセージの１つは、上記無線ユニット装置又は上記外部装置のリソースへのアクセスを得る希望を指示するためのリソース要求メッセージであり、そして別のメッセージは、リソースに対して責任を負うサーバ(5)から上記リソース要求メッセージの発信点へ送信される応答メッセージである請求項５ないし８のいずれかに記載の通信システム。
10. 上記メッセージの１つは、上記リソースに関連した事象又は状態の１つを指示するために、上記リソースに対して責任を負う上記サーバから送信される指示メッセージである請求項９に記載の通信システム。
11. 上記メッセージの１つは、上記リソース要求メッセージにより指令された動作を完了するための付加的な情報を要求するために、上記リソースに対して責任を負う上記サーバから送信される協議要求メッセージである請求項９又は１０に記載の通信システム。
12. 上記メッセージの１つは、上記協議要求メッセージの受信に応答して上記リソース要求メッセージの発信点から送信される通知応答メッセージである請求項１１に記載の通信システム。
13. 上記リソース要求メッセージは、アプリケーション又はサーバの１つによって送信される請求項９に記載の通信システム。
14. 上記メッセージの１つは、上記リソースに関連した事象又は状態の１つを指示するために、上記リソースに対して責任を負う上記サーバから送信される指示メッセージであり、上記メッセージの別の１つは、上記リソース要求メッセージにより指令された動作を完了するための付加的な情報を要求するために、上記リソースに対して責任を負う上記サーバから送信される協議要求メッセージであり、そして上記指示メッセージ及び上記協議要求メッセージ各々は、上記リソース要求メッセージのアドレスフィールドから得られる行先アドレスフィールドを含む請求項９に記載の通信システム。
15. 上記指示メッセージ及び上記協議要求メッセージ各々は、上記リソース要求メッセージの独特のトランザクション識別フィールドから得られる独特のトランザクション識別フィールドを更に含む請求項１４に記載の通信システム。
16. 上記メッセージの１つは、上記リソースに関連した事象の発生を指示するために、上記リソースに対して責任を負う上記サーバから送信される指示メッセージであり、この指示メッセージは、事象の発生が通知されるべき要求を以前に登録した少なくとも１つの行先へと送信される請求項９に記載の通信システム。
17. 更に、上記無線ユニットは、複数のアプリケーション(52)と、無線ユニットのリソースに各々関連した複数のサーバ(50)と、上記アプリケーションを上記サーバへ選択的に接続するために上記複数のアプリケーションと上記複数のサーバとの間に介在された接続層(41)とを含み、上記通信システムは、更に、上記接続層を経て上記無線ユニットに接続された少なくとも１つのアクセサリ装置(28)を備え、該少なくとも１つのアクセサリ装置は、そのアクセサリ装置のリソース(48)に関連した少なくとも１つのアプリケーション(52)及び少なくとも１つのサーバ(50)を備え、上記無線ユニットの少なくとも１つのアプリケーション又はサーバは、上記無線ユニットの上記少なくとも１つのアプリケーション又はサーバから送信されたリソース要求メッセージに応答して上記接続層を経て上記アクセサリー装置の上記少なくとも１つのサーバ又は上記無線ユニットのサーバに接続することができ、上記リソース要求メッセージは、上記接続層を経てルート指定される請求項１に記載の通信システム。
18. 上記複数のサーバの少なくとも１つは、上記無線ユニットへのユーザインターフェイスを与える少なくとも１つのパネルに接続されたパネルサーバ(60)である請求項１７に記載の通信システム。
19. 上記システムは、事象の指示を受け取るように登録された上記アプリケーションの所定のものへ事象の指示を与える事象サーバ(56)を含む請求項１７又は１８に記載の通信システム。
20. 上記複数のサーバの少なくとも１つは、複数の異なる無線通信システムの個々のシステムに両方向接続できる能力を上記無線ユニットに与えるためのシステムモードコントローラ(50A)である請求項１７ないし１９のいずれかに記載の通信システム。
21. 別のメッセージは、上記リソースに対して責任を負う上記サーバから、上記接続層を経て、上記リソース要求メッセージを発信したアプリケーション又はサーバへと送信される応答メッセージである請求項１７ないし２０のいずれかに記載の通信システム。
22. 別のメッセージは、上記リソースに関連した事象又は状態の一方を指示するために、上記リソースに対して責任を負う上記サーバから送信される指示メッセージである請求項１７ないし２１のいずれかに記載の通信システム。
23. 別のメッセージは、上記リソース要求メッセージにより指令された動作を完了するための付加的な情報を要求するために、上記リソースに対して責任を負う上記サーバから送信される協議要求メッセージである請求項１７ないし２２のいずれかに記載の通信システム。
24. 別のメッセージは、上記協議要求メッセージの受信に応答して上記リソース要求メッセージの発信点から送信される通知応答メッセージである請求項２３に記載の通信システム。
25. 更に、ワイヤレスインターフェイス(18C,43A)又はワイヤードインターフェイス(18A,43C,18B,43B)の少なくとも一方を経て上記無線ユニット装置に両方向接続されるアクセサリ装置(28)を備え、上記無線ユニット装置は、複数のリソース(48)を含み、上記アクセサリ装置は、リソース要求メッセージ又はリソース要求応答メッセージの少なくとも一方を上記無線ユニット装置に送信すると共に、上記無線ユニット装置の上記メッセージルータ(40)を経て特定の無線ユニット装置のリソース(48)に関連したリソースサーバ(50)へ送信するために、メッセージルータ層(41)を経て上記ワイヤレス又はワイヤードインターフェイスに接続された少なくとも１つのアプリケーション(52)を含み、これにより、上記アクセサリ装置の少なくとも１つのアプリケーションは、上記複数の無線ユニット装置リソースの少なくとも１つと共に動作できるようにされた請求項１ないし２４のいずれかに記載の通信システム。
26. 少なくとも１つの形式のワイヤレス通信ネットワークと共に動作できる無線ユニットを含む形式の通信システムを動作する方法であって、上記無線ユニットは複数のアプリケーション及び複数の通信媒体より成り、上記方法は、
    上記無線ユニットにマスタールータ層及び接続層を設け、これらの層は、上記複数のアプリケーションと上記通信媒体との間に介在され、
    スレーブルータ層を経て上記無線ユニットに外部アプリケーションを接続し、
    上記複数のアプリケーションの１つからメッセージを受け取り、そして
    その受け取ったメッセージを、上記マスタールータ層により、上記接続層、少なくとも１つの上記通信媒体及び上記スレーブルータ層を経て上記外部アプリケーションへルート指定する、
    という段階を含むことを特徴とする方法。
27. 上記マスタールータ層は、登録要求メッセージの受信に応答して、登録を要求するエンティティにアドレスを動的に指定する請求項２６に記載の方法。
28. ワイヤレスインターフェース（１８Ｃ、４３Ａ）又はワイヤードインターフェイス（１８Ａ、４３Ｃ、１８Ｂ、４３Ｂ）の少なくとも一方を経て複数のリソース（４８）を備える無線ユニット装置（１０）に両方向接続されるアクセサリ装置（２８）において、該アクセサリ装置のメッセージルータ（４０）層を経て上記ワイヤレスまたはワイヤードインターフェイスに接続され登録要求メッセージ、およびリソース要求メッセージおよびリソース要求応答メッセージの少なくとも一方を、上記無線ユニット装置（１０）へ送信し、且つ上記無線ユニット装置のメッセージルータ（４０）を経て特定の無線ユニット装置のリソース（４８）に関連したリソースサーバ（５０）へ送信するために、少なくとも１つのアプリケーション（５２）を備えており、該アクセサリ装置（２８）の少なくとも１つのアプリケーション（５０）は、上記無線ユニット装置（１０）の複数のリソース（４８）の１つと共に動作できるようにされたことを特徴とするアクセサリ装置。
29. 該アクセサリ装置（２８）のリソース（４８）と関連した少なくとも１つのサーバ（５０）を備えており、上記無線ユニット装置（１０）のサーバ（４８）又はアプリケーション（５２）の少なくとも一方は、上記無線ユニット装置のサーバ又は上記少なくとも１つのアプリケーションから送られるリソース要求メッセージに応答し、接続層（４１）を経て上記無線ユニット装置のサーバ又は該アクセサリ装置の上記少なくとも１つのサーバ（４８）へ接続され得て、上記リソース要求メッセージは、上記接続層（４１）を経てルート指定される請求項２８に記載のアクセサリ装置。
30. 上記無線ユニット装置（１０）の上記メッセージルータ（４０）は、該アクセサリ装置（２８）から、および少なくとも１つの外部オブジェクトから登録要求を受け取り且つ上記登録要求により指定された好ましいリンクの認識又は登録要求が受信されたところのリンクの認識の少なくとも一方を記録するように動作できる請求項２８または２９に記載のアクセサリ装置。
31. 登録要求の少なくとも１つの形式は、登録オブジェクトに対するリンクの優先順を含む請求項３０に記載のアクセサリ装置。
32. メッセージサブルータおよび少なくとも１つの外部オブジェクトを備えており、該アクセサリ装置（２８）は、複数のリンクの少なくとも１つに両方向接続され、上記無線ユニット装置（１０）の上記メッセージルータ（４０）は、上記内部オブジェクト、上記少なくとも１つの外部装置および少なくとも１つの外部オブジェクトから登録要求を受け取る請求項２８または２９に記載のアクセサリ装置。
33. 少なくとも１つの登録要求は、登録する装置又はオブジェクトのリンクの優先順より成る請求項３２に記載のアクセサリ装置。

Images