JP4456136B2 - 端末、および、メニューを無線通信ネットワーク用の端末内に生成する方法 - Google Patents

Description

本発明は、通信ネットワーク用の端末に関し、この端末は、複数のアプリケーションを支援することのできるものであって、ユーザ・メッセージを通信するための手段を有する。本発明は、また、送信端末と、複数のアプリケーションをサポートすることのできる受信端末とを備える通信ネットワークにおけるシステムにも関し、この両方の端末がユーザ・メッセージを通信する手段を有する。

現在、普通の移動局機能の他に、例えばカレンダーの維持、ファックス・メッセージの送出、および電子メールなどを可能にするデータ処理機能も有する通信機器(comunicator)が開発されつつある。それらの通信機器は、オーガナイザ形の装置のように異なる数種類のアプリケーションを有しあるいは支援することができる。例えばテキスト・メッセージなどをタイプしやすい在来の英数字キーボードに類似するキーボードを有するユーザインターフェースを備えた１種の通信機器が開示されている（例えば、特許文献１）。この公報では、キーボードはタッチ・ディスプレイによって実現されている。しかし、在来の移動電話機が発展するに従って、特にユーザインターフェースおよびディスプレイがさらに発展するに従って、在来の移動電話機のような装置によって、もっと進歩した動作が可能になろう。

米国特許第５４２２６５６号明細書

公報ＷＯ９４／２３３９４は、走査して例えば無線通信を使って類似の通信機器に送ることのできる種々のタイプのグリーティングカードを有する通信機器のための電子メール・サーバを備えた電子グリーティングカード通信システムを提示している。このシステムの欠点は、該当するグリーティングカードを類似の通信機器にしか送れないことである。従って、送出者は受信者がグリーティングカード通信システムをサポートする通信機器を持っているか否か知らなければならない。さらに、システムを実現するためには、種々のタイプのグリーティングカードを記憶しておくためのオフライン電子メール・サーバを当該サービスのためにネットワークに個別に接続しなければならない。このシステムは普通の無線通信でグリーティングカードを送信するので、通信機器の電話回線が送信中は話中になるということが別の欠点である。この公報に提示されている通信機器によって、手書きテキストを有するグラフィック・イメージを送信することもできる。その様なイメージあるいは単なる手書きメッセージの送信は、情報量が大きいために極めて低速である。公報ＷＯ９４／２３３９４は、１つのアプリケーションあるいはサービス、すなわちグリーティングカード・アプリケーション、に関する情報の送出について論じているだけである。通信機器類似の装置が異なる数個のアプリケーションを有するために、種々のアプリケーションに関連する情報をどの様に送出したり処理したりするかという問題が生じる。このＷＯ公報では、特定のグリーティングカード・サービスのために別々の電子メール・サーバが配置されている。しかし、通信機器の各アプリケーションのために別々の電子メール・サーバを設けるのは、どちらかというと複雑で高価な解決策となろう。さらに、例えば通信機器などの端末において種々のサービスに関連する情報をどの様に処理するかという問題に直面する結果となる。

本発明は、通信ネットワーク用の端末に関し、この端末は複数のアプリケーションを支援することができて、ユーザ・メッセージを通信するための手段を持っており、その端末は、そのアプリケーションのうちの１つと関連するデータおよびヘッダを有するユーザ・メッセージを受信するための手段と、このヘッダに従ってそれぞれのアプリケーションへ向けてデータをアドレス指定するための手段とを有する。従って端末は、複数の異なるアプリケーションを後の段階で端末に組み込むことができるようになっている。アプリケーションを後で追加することは、他の装置への無線での直接接触によって実行することができる。１つのユーザ・メッセージはヘッダが指示する１つのアプリケーションに関連するデータを含むことができ、あるいは、例えば特定のアプリケーションを指示するヘッダの後にそのアプリケーションに関連するデータが続くこととなるように、ユーザ・メッセージは種々のヘッダにより指示される数個のアプリケーションに関連するデータを含むことができる。

ユーザ・メッセージは、限られた量の情報を含んでいるので、素早く送信することができる。ユーザ・メッセージの１つのタイプはいわゆるショートメッセージである。本発明は、ショートメッセージのユーザにより実施されるのに特に適している。規格ＩＳ−１３６に準拠する移動電話システムは、類似のショートメッセージを送信するためにいわゆるＲデータ・フィールドを使用する。ＳＭＳ類似のメッセージも送ることのできるＧＳＭシステムで知られている他の種類のユーザ・メッセージ送信機能はＵＳＳＤ（Unstructured Supplementary Service Data : 無構造補助サービス・データ）であり、これはＧＳＭ仕様において、例えば次の文書、TS GSM 02.04、TS GSM 02.30、TS GSM 02.90、TS GSM 03.38、TS GSM 03.40、などで、詳しく定義されている。ＳＯＣ（Service Operator Code : サービス・オペレータ・コード）と呼ばれる類似のメッセージ送信形式(messaging form)が規格ＩＳ−１３６に準拠する移動電話システムに存在する。ＳＭＳ、Ｒデータ、ＵＳＳＤおよびＳＯＣのような通信形式を本書ではユーザ・メッセージ送信機能と称し、その様なメッセージをユーザだけでなくてオペレータが送信することもできるが、メッセージをユーザ・メッセージと称することにする。この種の通信の利点は、音声通話チャネルを全く保留しないか、あるいは少なくとも連続的には保留しないことである。

パケット交換通信にも同様の利点がある。移動通信ネットワークにおいてパケット交換情報を中継するためのＰＲＭＡ（Packet Reservation Multiple Access：パケット予約多元接続）に基づくプロトコルが知られている。これは「パケット無線（Packet Radio）」とも呼ばれる。ＰＲＭＡは、パケット書式のディジタル音声あるいはデータを多重化して時分割搬送波にするための技術である。パケット無線サービス、すなわちＧＳＭ移動無線システムのために開発中のＧＳＭ ＧＰＲＳ（General Packet Radio Service：一般パケット無線サービス）、を例として取り上げる。ＧＰＲＳは、ＧＳＭ加入者にパケット無線サービスを提供する新しいＧＳＭサービスである。ＧＰＲＳは、送信するべきものが何かあるときだけ無線資源を予約するものであり、従って同じ資源を全ての移動局が自分たちの必要に応じて共有できるようにするものである。従って、短時間だけ通信チャネルを保留するパケット無線通信をユーザ・メッセージ送信のために利用することができる。

本発明は如何なるユーザ・メッセージをも利用できることであるけれども、以下の記述では主としてショートメッセージを実例として参照する。高速で送出するということに加えて、音声チャネルを保留しないなどの、ショートメッセージ・サービスの利点を利用することができる。アプリケーション関連情報を端末装置のメモリ（固定記憶装置）に前もって記憶させておくこともできるが、ユーザは端末の手段によってサーバと連絡を取って端末のメモリ（キャッシュ・メモリ）にアプリケーション関連情報を記憶させることもできる。アプリケーションに応じて、ユーザはアプリケーションでユーザ入力を入力したり情報を修正したりすることができる。他のアプリケーションでは、アプリケーションに関連する情報をサービス・プロバイダにより送出することができ、その情報は、ユーザが修正できなくて、サービス・プロバイダに修正を依頼できるに過ぎないような情報であっても良い。アプリケーションで容易にプリントされる情報も送信することができる。受信側の端末がそのショートメッセージを普通のショートメッセージではなくて特定のアプリケーションに関連するアプリケーション向け情報を含むショートメッセージであると識別できるように、アプリケーションの種類の識別子またはヘッダを通信メッセージに付け加えるのが好都合である。その識別子は、ショートメッセージのアドレス・フィールドまたは制御フィールド中のコードであっても良いし、あるいはショートメッセージのメッセージ部分中のコードであっても良い。移動局システムに既に存在するショートメッセージ・サービスを利用してアプリケーションに関する情報を送出できることが分かっているので、例えば、公報ＷＯ９４／２３３９４に提示されているシステムなどでアプリケーション関連情報を送るためにオフライン・サーバを設定する必要が無いという利点がある。唯一のサーバすなわちＳＭＳサーバ（ショートメッセージ・サービス・センターＳＭ−ＳＣ）を使ってどの様なアプリケーションに関連する情報でも送出したり回送したりできるので、各アプリケーションのために別々のサーバを持つ必要はないということが特に有利である。ＳＭＳサーバはどんなメッセージでも回送し、端末はメッセージ中のヘッダまたは識別子に従って正しいアプリケーションへ向けて情報をアドレス指定する。また、ショートメッセージを回路結合接続（circuit-coupled connection）と同時に送れるので、例えば同時に入接続呼がある場合などに、アプリケーション関連情報の送出は端末の通信回線を話中にしない。ＧＳＭネットワークのようなネットワークは幾つかのオペレータによって維持され、普通は各オペレータが自分のＳＭＳサーバを少なくとも１つ持っている。この場合、当然に、どのＳＭＳサーバも、あるいは数個のサーバも、本発明のために使用することができる。

本発明は、第１の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの１つについての情報と、そのアプリケーションのうちの１つに関連するヘッダとを有するショートメッセージを受信するための手段と、そのヘッダに従ってそのアプリケーションのうちの１つに向けて情報をアドレス指定するための手段とを備えることを特徴とする。

本発明は、第２の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの１つに関連する情報を処理して記号に変換し、その処理済み情報をショートメッセージで送出するための手段と、そのショートメッセージにヘッダを付け加えるための手段とを有し、そのヘッダは、その情報が関連するアプリケーションを表示するものであることを特徴とする。

本発明の端末は、アプリケーション関連情報を簡単に送信および受信する方法を提供する。また本発明は、例えば前述のメニュー・アプリケーションを使って大量のサービスへのアクセスを有することができる端末を提供する。特にショートメッセージを通信書式として使用することによって宛先の到着が保証され、ユーザ・メッセージで一般に最適の電流消費が達成される。ユーザ・メッセージとの関連での承認トークンの使用は、ユーザ・メッセージにセキュリティを加える新しい方法を説明する。

次に添付図面と付録とを参照して本発明について詳しく説明する。

付録１は、図８に例示されている、記号で表されたアプリケーション関連情報を例示する。

次に、ユーザ・メッセージ機能の１つの形式としてのショートメッセージ・サービスを実例として取り上げて、本発明を詳しく説明する。本発明を理解するために、始めに図１〜５を参照してショートメッセージに関連する従来技術を解説し、図７〜１２および付録１を参照して本発明の実施例について説明する。

ＧＳＭシステムのようなディジタル移動通信システムでは、いわゆるショートメッセージを送出することができる。ＧＳＭシステムでは、これはＳＭＳ（Short Message Service : ショートメッセージ・サービス）として知られている。この様に、電話コールおよびデータ転送の他に、ＧＳＭシステムはショートメッセージ・サービスの形式でページング・システムに類似するサービスも提供している。しかし、ＧＳＭシステムから知られているショートメッセージ・サービスは、普通のページング・システムより非常に進歩している。移動局により、テキスト・メッセージを他の移動局とやりとりすることができる。ＧＳＭシステムのショートメッセージ・サービスの１つの利点は、また、例えば通話中に、普通の回線結合通信が開始されているときに同時にショートメッセージを送出しあるいは受信することができることである。従って、ショートメッセージを送出しても、たとえ入接続呼がある場合でも移動局は話中状態に保たれない。

電話コールと比べたときのショートメッセージの利点は、ショートメッセージが送信されつつあるときには受信器と連絡を取れないにもかかわらずショートメッセージを受信器に送出することができるということである。これは、第１の移動局から第２の移動局へのショートメッセージの送信を図１に示されているように２つの部分に分割することによって実現される。すなわち送信側移動局ＭＳ１からＳＭ−ＳＣ（ショートメッセージ・サービス・センター）へ送出され、ここにショートメッセージが記憶されて、さらに実際の目的地すなわち受信側移動局ＭＳ２へ、連絡が取れ次第直ちに送出される。図２には、移動局システムへのショートメッセージ・サービス・センターＳＭ−ＳＣの接続が詳しく例示されている。以下に、従来技術について、公知である種々のインターフェース間でのショートメッセージの送信および流れについて図１〜５を参照して説明する。

移動局システムの構造と、ショートメッセージを送信するための接続とが図２に例示されている。移動局ＭＳは無線通信により基地局ＢＴＳに接続される。基地局ＢＴＳは、さらにいわゆるＡｂｉｓインターフェースを通して基地局コントローラＢＳＣに接続され、この基地局コントローラは数個の基地局を制御管理する。数個の基地局ＢＴＳ（通常、数十個の基地局）と、これらの基地局を制御する単一の基地局コントローラＢＳＣとで形成されるエンティティは、基地局システムＢＳＳと呼ばれている。特に、基地局コントローラＢＳＣは、無線通信チャネルとハンドオーバーとを管理する。一方、基地局コントローラＢＳＣは、いわゆるＡインターフェースを通して、移動局からの接続の形成および移動局への接続の形成の両方を調整する移動サービス交換センターＭＳＣに接続される。移動サービス交換センターＭＳＣを通して移動通信ネットワークの外部との接続がなされる。前述のショートメッセージ・サービス・センターＳＭ−ＳＣは移動サービス交換センターＭＳＣに結合される。

ユーザは、移動局ＭＳ１によってショートメッセージを送りたいときには（図１）、送信されるべきメッセージを（移動局のユーザインターフェースを使って）書き込み、そのメッセージが送られることになる移動局ＭＳ２の電話番号すなわち移動局ＭＳ２の識別子を与える。さらに、移動局は、連絡情報すなわちショートメッセージ・サービス・センターＳＭ−ＳＣの電話番号を有するべきである。普通は、これは移動局のメモリに記憶されており、その場合にはショートメッセージの送信に関する電話番号を個別に入力する必要はない。ショートメッセージを送るときには、メッセージは移動局ＭＳから基地局ＢＴＳに行き、そこから基地局コントローラＢＳＣおよび移動サービス交換センターＭＳＣを介して、さらにショートメッセージ・サービス・センターＳＭ−ＳＣに行く。ショートメッセージはショートメッセージ・サービス・センターＳＭ−ＳＣに記憶され、ここからショートメッセージはさらに受信側移動局ＭＳ２へ送出され、その場合にはメッセージのルートは送信時と同じであるが方向が逆である。移動局ＭＳ２がそのショートメッセージを受信したか否かがショートメッセージ・サービス・センターＳＭ−ＳＣに知らされる。従って、これは、もし何らかの理由で移動局ＭＳ２がそのショートメッセージを受け取っていなければ、それを送り直すことができる。

さらに、ショートメッセージをパソコンＰＣから送出することもできる。この場合には、移動サービス交換センターＭＳＣは、例えばインターネットとの接続を有するサーバＧＴＷ（ゲートウェイ）との接続を有する。従って、インターネットとの接続を有する（あるいは破線で図示されているようにサーバＧＴＷと直接接続している）コンピュータＰＣはインターネットからＷＷＷ（ワールドワイドウェブ）ページを引き出すことができ、それは物理的には例えばサーバＧＴＷから見つけることができる。随意的に、サービス・プロバイダまたはオペレータは、ショートメッセージあるいはその他のユーザ・メッセージを送出するために、移動サービス交換センターＭＳＣとの接続を有する独立のサーバＧＴＷを有していても良い。ショートメッセージを送出するためにそのようなＷＷＷページを使うときには、ユーザは受信側端末ＭＳ２の接続情報（例えば電話番号）と送出されるべきメッセージとを入力し、そのメッセージはインターネットとサーバＧＴＷとを介して移動サービス交換センターＭＳＣへ転送され、さらにショートメッセージ・サービス・センターＳＭ−ＳＣへ送られ、そこからそのメッセージは移動通信網を介して受信側端末ＭＳ２へ送られる。

ＧＳＭシステムのショートメッセージ・サービスＳＭＳによって、最大で１６０文字の長さのメッセージを一度に送ることができる。文字は７ビットのＡＳＣＩＩ（American National Standard Code for Information Interchange : 情報交換用米国標準コード）文字であり、従って、メッセージの最大長さはビット単位で１，１２０ビット、すなわち１４０バイトである。図３に例示されているような普通の移動局は、小型のディスプレイと進歩したキーボードとを持っており、これにより短いメッセージを書くことができる、すなわち種々の英数字を入力することができる。受信されたメッセージは、図３に例示されているように英数字を表示できる移動局のディスプレイで表示される。

用知の通り、ＧＳＭシステムでは通信メッセージはフレームに分割される。送信されるべきメッセージの長さが、フレームＦＲの許容最大長さを上回るときには、図４に例示されているようにメッセージＭを幾つかの部分Ｍ１〜Ｍ４に分割して数個のフレームＦＲ１〜ＦＲ４で送出しなければならない。受信時には、移動局は、図５に示されているように、数個のフレームＦＲ１〜ＦＲ４に分割されているメッセージＭを復元する。無線インターフェース（図２）では、フレームの最大長さは普通は１６８または１８４ビットであるので、最大長さが１、１２０ビットであるショートメッセージを数個のフレームにセグメント化しなければならない。図６は、普通は３つのフィールドに分割されている、無線インターフェースで送信されるフレームであるいわゆるＬＡＰＤｍフレーム（Link Access Protocol for the Dm channel ：Ｄｍチャネル用リンク・アクセス・プロトコル）を例示している。第１フィールドはアドレス・フィールドＡＤＤであり、これは数バイトで表示されるメッセージの宛先のアドレス（すなわち、受信側移動局の識別子）である。ＧＳＭシステムでは、対応するＬＡＰＤｍフレーム内でシグナリングメッセージも送信される。無線通信では、互いに無関係の２つのメッセージ、すなわちシグナリングメッセージとショートメッセージと、のフローが同時に存在できる。この２つの異なるフローは、アドレス・フィールドＡＤＤに付加されるサービス・アクセス・ポイント識別子ＳＡＰＩによって分離される。その値は、信号を示す３であるか、あるいはショートメッセージを示す０である。第２フィールドは制御フィールドＣＴＲＬであり、これは送信しているフレーム番号Ｎ（Ｓ）と受信しているフレーム番号Ｎ（Ｆ）とを含んでいる。第３フィールドは実際の情報あるいはデータを含むデータ・フィールドＩＮＦＯであり、これは最大で１６８ビットの情報すなわち実際のショートメッセージの内容を含んでいる。

本発明では、ショートメッセージを例として取り上げると、各アプリケーション関連情報の送信は、特別のコードすなわち識別子によって識別され、それは受信側端末が受信したメッセージを処理して、受信したデータを含む指定されたアプリケーションに直接入れることを可能にするものである。その識別子は好適にはＡＳＣＩＩ文字を使用してショートメッセージ送信フレームの情報フィールド、すなわち実際のショートメッセージを文字の形で含むフィールドＩＮＦＯ（図６）で実現される。代わりに、ショートメッセージを送出するためにデータはいずれにせよビットに変換されるので、識別子は他の何らかの文字またはビット等のストリング・コード(string code）の形であっても良い。アプリケーションに関連する情報はショートメッセージで送信されるので、そのアプリケーション・サービスをサポートしないがショートメッセージを送信しおよび／または受信することのできる普通の移動局で、そのショートメッセージを受信することもできる。アプリケーション識別子をフィールドＩＮＦＯに置けば、このタイプのアプリケーション・サービスをサポートしないけれどもショートメッセージを送信しおよび／または受信することのできる普通の移動局において、そのアプリケーション識別子が端末、例えば通信機器のユーザに表示され、従ってユーザは普通のショートメッセージではなくて特定のアプリケーションに関連する情報を受信したということに気づくという利点もある。また、このタイプの普通の移動局のユーザは、始めにメッセージに当該アプリケーションの識別子を記号で書き、そして正しく分割された情報の残りを書くことによって、前述したメッセージ等のメッセージを送信することもできる。本発明に従って、端末装置によってこの通信メッセージを受信すれば、完全に受信されたアプリケーション関連情報記録が得られる。

代わりに、アプリケーション識別子はショートメッセージのアドレスまたは情報フィールド（図６を参照）において、特定のビット・コードとして形成される。さらに、この場合、普通の移動局は特定のアプリケーションに関連する送信された情報を受信することができるが、ユーザは、そのメッセージに関して、受信したメッセージが特定のアプリケーションのための情報であるということを知ることはできない。この場合、特定のコマンドを入力すると、移動局が前述のビット・コードを付加することとなるように移動局を改造しなければ、その普通の移動局はアプリケーション識別子を知らせることはできないので、この種のアプリケーションのための情報を普通の移動局で送信することはできない。

図７は、端末装置に予め記憶されるアプリケーション記録を有するアプリケーションの例を例示しており、それにユーザ入力された情報（アプリケーション記録）は、ショートメッセージとして別の端末に送出されることができる。このアプリケーションのタイプは“ビジネス・カード”と呼ばれる。このアプリケーションは、ビジネス・カードの内容を走らせるものであって、氏名、職名、会社名、連絡情報、などの情報を含んでいる。各情報がそれ自身のフィールドに置かれても良く、あるいはアプリケーションがフィールドを１つだけ有して、その中に全ての情報が置かれても良い。図７は、アプリケーションに関する情報の、ショートメッセージとしての送信も示している。この場合、アプリケーションのタイプの識別子は例えば図に例示されるように“ＢＣ”または“Business Card ”である。本発明の端末は、このアプリケーション識別子を（例えば文字あるいはその他の形で）始めに送信されるショートメッセージの情報フィールドの冒頭に付け加える。種々のフィールドの内容は自動的に改行文字で終わる。この文字に基づいて、受信側の端末は、受信した情報をアプリケーションの対応するフィールドに分割することができる。このタイプのメッセージが普通の移動局からショートメッセージとして送信されるのであれば、ユーザは、そのメッセージの冒頭にアプリケーション識別子、すなわち、図７の場合には「Business Card 」とを書き、その後に改行文字[cr]を書き、その後にアプリケーションに関する情報を（アプリケーション仕様に応じて）次々にあるいはフィールド毎に、すなわち始めに氏名フィールドを、次に改行文字を書く、等の手続きをする。受信した「Business Card 」を端末のメモリに記憶することができ、従ってそれにビジネス・カードを電子形式で記憶して、ビジネス・カード・アプリケーションでメモリからそれらを検索してみることができる。ビジネス・カード・アプリケーションの情報は、もちろん、装置に依存して変わる。或る端末では、それは、例えば、ショート・ダイヤル・アプリケーションとして使用することのできる氏名および電話番号だけを意味する。従って、ショート・ダイヤル・アプリケーションの内容を更新するために本発明を利用することができる。このようにして、ユーザは、内容をサービス・センターに送って記憶してもらうことによってショート・ダイヤル・アプリケーションの内容のバックアップを作ることができる。もし端末（例えば移動電話機）が後に紛失したり盗まれたりあるいは壊れたりして、ユーザが新しい端末を取得しなければならないことになっても、ユーザは、端末を起動することに加えて、ショート・ダイヤル・アプリケーションの内容全部をその端末にダウンロードする（引き込む）ことができる。もちろん、同じ解決策を端末のどのアプリケーションの内容にも使用することができる。ここで、他のいくつかのアプリケーションについて説明する。

以下では、例として、他のタイプのアプリケーションについて論議する。それらのアプリケーションを端末に前もって記憶しても良く、あるいは後の段階で（プログラミングにより）端末に組み込んでも良い。

「コール・ミー・バック（Call Me Back、折り返し電話をかけてください）」というアプリケーションは、人の氏名、電話番号、アドレス等と、その人が折り返し電話をするべきであるというメッセージとを含むことができる。この情報は、別個のフィールドに分割されても良く、あるいは、前述のように同じフィールドに置かれても良い。折り返し電話せよという前述のメッセージを「コール・ミー・バック」アプリケーションに密接に組み合わせても良く、および／または普通の移動局のディスプレイでも表示される（文章としての）“コール・ミー・バック”を識別子として書いても良く、その場合にはそのメッセージを受け取った当該移動局のユーザは、それが折り返し電話をすることを要求することであることを知ることができる。「コール・ミー・バック」アプリケーション関連情報の送信を出接続呼に結びつけて、もし宛先の端末が応答しなければ送信側のすなわち呼を発する側の端末がユーザ（発呼者）に「コール・ミー・バック」通知子を送出すべきか否か尋ねるようにしても良く、その場合には、そのユーザの応答が肯定であれば、それは予めアプリケーション・データ・フィールドに入力されている発呼者の電話番号（それは例えば自分のＳＩＭカード、加入者識別モジュールからアクセスできる）で当該アプリケーションをディスプレイ上で走らせる。ユーザは、「コール・ミー・バック」アプリケーションで、情報の残りを入力し、ディスプレイ上でそれを修正することができる。アプリケーション関連情報がショートメッセージとして送出されるときには、端末は受信者の電話番号をそのメッセージの宛先として自動的に提供し、それを端末は未応答のままになっている呼についての情報から選び出すことができる。

アプリケーション「Meeting Proposal、会合申し込み」の識別子は「Meeting Proposal」であって良く、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含むことができる。もし、端末に、電子カレンダー・アプリケーションもあるならば、このタイプのアプリケーション（会合申し込み）に関連する情報の送信に対する応答として、当該時間における会合の予約をカレンダーに設けるように、当該アプリケーション関連情報の送信をカレンダー・アプリケーションの動作と結びつけることができる。この特定のアプリケーションは、好適には、会合の時間をアプリケーションから選び出して、会合の場所および主題等の、そのアプリケーションに関する他の情報を招集者の氏名とともにカレンダーの当該時間の箇所に入力する。それに相応して、この種のアプリケーション関連情報を受け取ったときには、端末は自動的に当該時間について既に合意がなされているかも知れないものについての陳述を（もしカレンダーに入力されているならば）カレンダーから探す。従って、受信者は、会合申し込みに「イエス」と答えるか「ノー」と答えるか、素早く決めることができる。その回答を送出するとき、端末はアプリケーション「会合申し込み回答」を確立するが、その識別子は例えば「Meeting Proposal Answer 」であり、このアプリケーションの情報は、受信者の氏名、会合の時間および場所、主題、回答（イエス／ノー）、およびコメントを含むことができる。この場合、受信者、すなわち会合申し込みの送信者、の端末のカレンダー・アプリケーションは、カレンダーに設けられている予約を確認するかあるいは取り消すように調整される。

さらに、「会合申し込み」アプリケーションの続きとして、端末にアプリケーション「会合確認」があっても良く、その識別子は例えば「Meeting Confirmation」であり、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含んでもよい。端末は、好適には、会合申し込みに「イエス」と回答した人たち全員にこのアプリケーション関連情報を自動的に送出するように申し出る。この場合、このアプリケーションに関連する情報を受信した移動局または通信機器は、カレンダーの中の当該予約を確認する。

それに相応して、「会合申し込み」アプリケーションと同じ方法で、例えばアプリケーション「空き時間問い合わせ(Free Time Query）」などの、他の類似のアプリケーションを端末に設けることができ、その識別子は例えば「Free Time Query 」であり、このアプリケーションの情報は、送信者の氏名、時間、場所、および主題を含んでもよく、それはユーザが自由に書き込むことのできるものであって、例えばテニス、ディナーなどである。

端末は、好適には、この関係では送信および受信の両方で、会合申し込みアプリケーションの場合と対応的に機能する。すなわち、端末は、カレンダーに予約を記入し、別のアプリケーションによって問い合わせに回答できるようにし、さらに、受け入れられるという確認あるいは取り消しをカレンダーに記入する。

アプリケーション「サービスＤＴＭＦコマンド」により、例えば、ネットワークのオペレータから提供されるサービスを利用するためにそのオペレータから情報を受け取ることができる。アプリケーション識別子は「Service DTMF Commands 」であって良く、それは送信者の氏名、ＤＴＭＦコマンド、および説明フィールドを持つことができる。コマンドは、例えば、パスワード、ユーザ識別子、あるいはその他の、オペレータから提供されるサービスに関連する何らかのものである。ユーザは、提供されるサービスを利用するときに、例えばパスワード等の、受信したコマンドを使用することができ、その場合には当該アプリケーション（またはそのアプリケーションの中の情報）からパスワードを直接得ることができるので、ユーザはキーボードを通してパスワードを入力しなくてもよい。ネットワークのオペレータから情報を受信することのできる他のアプリケーションは、端末においてアプリケーションを使用する前に何らかの設定を必要とするアプリケーションである。例としては「インターネット・アクセスポイント」アプリケーションであり、これは端末が例えばＷＷＷブラウザを使用するために必要な情報を含む。その情報は、プロバイダの名称、電話番号、モデム初期設定情報、サーバ情報、ＩＰアドレス（Internet Protocol ：インターネット・プロトコル）であってもよい。何らかの設定を必要とするアプリケーションの別の例は、ファックス・ボックス・アプリケーションである。ファックス・ボックスは、例えばサーバで実現されるサービスであり、これは特定のユーザ宛の全てのファックスを受信する。ユーザはそのファックスをファックス・ボックスから回収することができる。ファックスを回収するために、端末はサーバ宛の連絡情報を有する必要がある。端末がファックス・ボックスに宛てられた新しいファックスを受信したときに、受信したファックスのユーザ・メッセージで端末が通知を受信するが、そのユーザ・メッセージがさらにＵＩＤ情報（Unique Identifier ：固有識別番号）すなわちファックス・ボックス・サーバ宛の連絡情報と、ファックスのファイル名および所要のパスワード等の他の所要の情報とも含むこととなるように、それを実現することができる。ファックス・ボックス・アプリケーションは、マニュアルで、すなわちユーザにより実行されて機能しても良く、あるいは、ユーザ通知メッセージに含まれている識別情報に従って受信されたファックスを自動的に回収するために端末がファックス・ボックス・サーバと連絡を取るように、そのアプリケーションが自動的に機能し得るようになっていても良い。ファックスを回収するためのファックス・コールとして連絡を取ることができる。随意的に、サーバが後に受信したファックスをファックス・コールを介して端末に送出するために端末と連絡を取ることができるように、その連絡は、識別情報をサーバに端末のファックス接続番号と共に送出するユーザ・メッセージであっても良い。

本発明を使用する別の環境には、移動局に類似した装置を端末として使用するインテリジェント交通システムに関する解決策がある。本発明の端末は、その場合、種々の交通関連アプリケーションを有する。例としては「位置（Position）」アプリケーションであり、これで位置要求および応答を本発明に従ってユーザ・メッセージで送出／受信することができる。位置を確定するための種々の解決策がある。アプリケーション「位置」は、興味ある特定のアドレスまたは地点についての位置情報と、対応する位置についての記述、送信の理由あるいはモードを記述したフラグ、および、応答メッセージの場合には参照番号を含むことができる。受信した情報を対応するフィールドに分割した後、受信側端末は、受信した「位置」アプリケーション記録をローカルメモリに記憶する。端末は、自分自身の位置あるいは記憶されている位置情報をユーザ・メッセージで他の端末装置またはサーバに送ることもできる。これを例えば緊急事態の場合には自動的に実行することもできる。緊急事態のために、端末は独立の“緊急事態表示”あるいは“パニック表示”アプリケーションを有することができ、このアプリケーションは、自分の車両および自分の位置並びに緊急事態に必要なその他の関連情報についての送信者に関する情報を自動的に包含することができ、これを送信者はこのアプリケーションで修正することができる。

交通目的の付加したアプリケーションは、例えば、「旅行要求（Trip Request）」および「旅行応答（Trip Responsel）」アプリケーションであり（あるいは一般的に「旅（Travel）」アプリケーション）、これは旅行支援アプリケーションである。このアプリケーションで、端末は、好適には出発地点としての端末の実際の位置と、その旅行の目的地として記憶されている位置アプリケーション記録から選択された位置と、を含む旅行要求を送り出すことができる。旅行要求に対する応答として、端末は「旅行応答」メッセージを受信することができ、それは、方向転換指示や公共輸送機関の接続などの、その旅行についての指示を含むことができる。

また端末は、この端末のオリジナルの通し番号、製造月、修理月、および改造がなされた月（例えばソフトウェアの改造）などの、サービス目的のために重要であるかも知れない情報を伴うサービス・アプリケーションを有しても良い。このサービス・アプリケーション中の情報は、ユーザ・メッセージで端末から例えばオペレータまたはサービス・ステーションに送られることができる。

実現可能な別のアプリケーションは、電話帳サービスを管理するサービス・プロバイダに電話番号問い合わせを送出するための電話帳アプリケーションである。その問い合わせは、氏名、在住地の市名、地上線／移動電話番号、などの情報を含むことができる。応答としてサービス・プロバイダは、電話番号と例えば元はユーザが送出した情報とを有するユーザ・メッセージを送出する。

付加的なサービスおよびアプリケーションを有する多様な可能性を端末に与える別のタイプアプリケーションは「メニュー（Menu）」アプリケーションであり、これに端末は受信したユーザ・メッセージに従って端末でメニューを作ることのできるアプリケーションを含む。そのメニューは、好適には、該端末でいつまでも使用することのできるメニューを作るために、図１０のメモリ１４等の固定記憶装置に記憶される。ユーザ・メッセージは、それに応じて「メニュー」アプリケーションが端末のメニューを作ったり更新したりできるような情報を含む。これにより、無線経由で、すなわちユーザがサービス場所へ端末を持ち込む必要なく、オペレータがユーザの端末で更新することのできる非常に多様なサービスへのアクセスが可能となる。オペレータには、その加入者が使用するハンドセットを個人専用のものとするための非常に強力なツールが与えられることになる。このツールは、必要ならば加入者毎に異なることのあるハンドセット(handset）の、オペレータ固有のメニュー構造である。そのメニュー構造はユーザによる支援無しで無線経由で動的に更新されることができる。創作されたり更新されたりして、メニュー中のコマンドを起動することによりアクセスすることのできる付加的サービスをユーザに提供することのできるメニューの実例を下に挙げる。本来は、端末は何らかの基本メニューを包含することもできるが、メニューを全く包含していなくても良い。下記の実例において示されている全てのメニューおよびサブメニューは、メニュー・アプリケーションに関連するユーザ・メッセージを送出することによって作ることのできるものである。

したがって、メニューあるいは各メニューは上記の様にメインメニューとサブメニューとを含むことができ、ここではメインメニューすなわちオペレータ・サービス、地域サービス、および個人向けサービスはサブメニューを含む。それらのサブメニューはさらにサブメニューに分割されても良く、例えばサブメニュー呼び出し音ダウンロード（Download Ringing Tones）は、呼び出し音のメロディ（Rock around the clock 、Those were the days 、Smoke on the water) によるサブメニューに分かれていても良く、特定のサブメニューを選択してそれをコマンドとして起動することによって、それらを呼び出し音として選ぶことができる。そのコマンドは本発明に従ってユーザ・メッセージとしてサービス・プロバイダに送出され、そのユーザ・メッセージに対する応答としてオペレータはユーザ・メッセージに符号化された呼び出し音を送出することができ、それは端末のおよび呼び出し音メモリに記憶されることができる。

サブメニューでなされる選択は多様な動作を引き起こす。サブメニューのエントリーにＵＲＬ（Uniform Resource Locater）情報を付随させることができ、これを使ってインターネットから情報を引き出したりｅ−メールをインターネットの受取人に送出したりすることができる。さらに、それらのエントリーから補足的サービスを直接開始させることもできる。特別の形式のＵＲＬを使って補足的サービス関連情報またはコールまたはユーザ・メッセージを伝えることができる。動作がネットワーク・エンティティによって情報を端末に送出させることもあり、例えば前述したように呼び出し音の選択とその後のダウンロードとを可能にする。その場合、オペレータ・サービス・メニューはＵＲＬ情報に基づいてインターネットから情報を引き出させることができ、ｅ−メール・メッセージを受取人に送出させることができ、オペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを開始させることができる。地域サービス・メニューは、特定地域向けのサービスをサポートする。一定地域で一定時間に利用することのできる「変わりやすい」サービスからメニュが生成さられる。ユーザはそれらのサービスをあさって、興味のあるものを選び出すことができる。この便宜は、ある地域を旅行している電話ユーザ宛てに情報（あるいはサービスの広告）を送るための簡単な手段を提供する。例えば、電話ユーザがダラス地域で州間高速自動車道（Interstate highway）７５号線に近づくと、それらのサービスのうちの１つ、「Traffic at Dallas Ｉ−７５」を利用できるようになる。このサービスをメニューから選択すると、その時点での交通情報を得ることができる。「個人向けサービス」メニューは、通常のＷＷＷブラウザ（ワールドワイドウェブ）におけるブックマーク・リストにたとえることができる。電話ユーザはリストにアイテムを付け加えたり、それらを編集したり、それらを削除したりすることができる。この個人向けサービス・メニューによって、ユーザは多様なサービスを起動させることができる。サービス情報をオペレータ固有のあるいは地域サービスのリストから個人用サービス・リストに移すことができる。個人向けサービスメニューは、ＵＲＬ情報に基づいてインターネットから情報を引き出させることができ、ｅ−メール・メッセージを受取人に送出させることができ、あるいはオペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを実行することができ、あるいはユーザ・メッセージを送出させることができる。例えばサブメニュー・コマンド「ＵＳ気象（US weather）」は、端末に米国の気象に関する情報を受信させるということになる。

次に、メニューの作成についてさらに詳しく説明する。メニュー作成は、プロセッサと、メモリに記憶されてそのプロセッサにより動かされるメニュー・アプリケーションにより制御され実現される。次に、プロトコルについて説明するが、このプロトコルに従ってメニュー・アプリケーションはプロセッサにより動かされるソフトウェアとして実行されることができる。後に図１０と関連して端末について詳しく説明する。

このプロトコルは所定のコマンドを定義し、それに従ってメニューの作成と変更およびメニュー構造が制御される。このプロトコルには４つのアイテム・プリミティブ(Item primitives）があり、それは追加、削除、リスト、およびアイテム能力である。これらのアイテム・プリミティブには、後述するように他のアイテム定義が伴う。

第１のプリミティブ・アイテムはitem-addであり、これはメニューまたはサブメニューを追加する。コマンド・シーケンスは次の定義を含むことができ、それをユーザ・メッセージで端末に送ることができる。

定義menu-item-token は、セキュリティが必要な場合にサーバが承認(authorization）目的に使用するオプションのコマンドであり、不要ならば省略しても良い。メニュー・アイテムが、セットされたmenu-item-token と共に送出されたならば、同じmenu-item-token が無しで既存のmenu-item を変更したり削除したりするコマンドを発することはできない。この種の承認の特徴を、メニュー・アプリケーションと関連して使用するだけではなく、ここに説明した他のアプリケーションと関連させて使用することもできる。例えば、呼び出し音は、menu-item-token のような正しい承認ワードまたはコードを伴っている場合に限って更新される。定義menu-group-name は、menu-item-nameという名称を持ったメニュー・アイテムがその中に入れられるメニュー・グループを明示する。もし同じ名称を持ったメニュー・アイテムが同じグループ内に既に存在するならば（そしてサーバが正しいmenu-item-token でそのメニュー・アイテムを更新することを承認されたならば）、既に存在するメニュー・アイテムは新しいものと置き換えられる。メニュー・グループの名称は、定義と関連してアポストロフィーの中に置かれる。

定義menu-item-nameは、メニュー・グループ（またはメインメニュー）に属するsub-menuの名称またはコマンドを定義する。同様に、sub-menuの名称は定義と関連してアポストロフィーの中に置かれる。

menu-group-name およびmenu-item-nameは共に「: 」という予約文字を有しており、これはメニュー・グループ・名称の中での改行という特別の意味を持っている、すなわち、「phone:settings」は、端末において「phone 」を１行目に表示し、「settings」を２行目に表示する。また、menu-group-name は「; 」という予約文字を持っており、これは複数階層メニューにおける階層レベルの変更を示すという特別の意味を持っている。

menu-item-typeは、メニュー・アイテムのタイプが何かを示す。メニュー・アイテムは、「通常」、「変わりやすい（volatile）」、「選択された（変わりやすい）」、および「リンク」、というタイプを有することができ、その意味は下記の通りである：

通常メニュー・アイテムは通常はハンドセットに記憶される。

変わりやすいメニュー・アイテムは複数選択メニュー・アイテムについての、メニュー選択アイテムの１つ（one-of-menu selection items ）である。

選択された（変わりやすい）メニュー・アイテムは現在アクティブな変わりやすいメニュー・アイテムを示す。

リンク・メニュー・アイテムは、サーバから変わりやすい選択項目を要求しなければならないことを端末装置に示す。

定義menu-item-helpは、ハンドセットのユーザが現在のメニュー・アイテムに関してヘルプを必要とするときに表示されるテキスト・ストリングである。それはハンドセット固有であり、ハンドセットは例えばアイドル・タイマーが満了したときにヘルプ・テキストを自動的に表示する。menu-group-name およびmenu-item-nameについて前述したように、類似の付加的定義をmenu-item-helpと結びつけることができる。

定義menu-action-listは、メニューから起動することのできる動作（アクション）のリストである。アクションは例えばaction-send-message のタイプ、あるいはaction-call-control のタイプである。action-send-message は、多くの方法のうちの１つでユーザ・メッセージを送出させる。その方法はメッセージのタイプによるが、それは前に明示したようにどんなユーザ・メッセージであっても良い（ＳＭＳ、ＵＳＳＤ、Ｒデータ、ＳＯＣ、パケット無線）。action-call-control は、多くの方法のうちの１つでコールを行わせる。方法はcall-control-type に依存し、それは音声コール、データ・コール、ファックス・コール、あるいはｓｓ（補足的サービス・ストリングがネットワークに送出される）であって良い。

第２のプリミティブ・アイテム・コマンドであるitem-remove は、（menu-item-token または承認リストに基づく）承認が欠けてはいないことを条件として、menu-group-name およびmenu-item-name) により識別されるメニュー・アイテムを端末から削除させる。コマンド・シーケンスは下記の通りであって良い。

第３のプリミティブ・アイテム・コマンドであるitem-list は、このコマンドを当初に送出したサーバへmenu-item-nameのリストを端末から送出させる。サーバは、どのアイテムのリストが要求されているかについてのメニューを明示することができる。menu-item-token が与えられたとき、マッチしたトークンを持ったアイテムだけが返される。コマンド・シーケンスは下記の通りであって良い。

第４のプリミティブ・アイテム・コマンドであるitem-capability を使って臨時の能力をメニュー・アイテムに付け加えたり除去したりすることができる。このコマンドを使って、例えば、明示された能力に応じてメニュー・アイテムにアイコンを付け加えることができる。コマンド・シーケンスは下記の通りであって良い。

メニュー変更の承認を承認プリミティブによってより厳密に定義することができる。３つの承認プリミティブがあり、それは追加、除去、およびリストである。特にオペレータ・メニューおよび製造者メニューのために承認リストを使用することができる。これは、端末が何個のエントリーを各メニューの承認リストに記憶することができるかはその実現により固有である。承認プリミティブおよびそれらを端末に入力するためのコマンドを、menu-item プリミティブについて上述したのと同様にして実現することができる。承認コマンドは、その承認コマンドがアクティブな承認リストを伴うメニューについてのみ、既に承認されているサーバから送出されたときに限って、容認されるという意味で、特権を持っている。

第１のプリミティブ承認コマンドであるauthorization-add を使って、与えられたメニュー（menu-group-name)について承認済みサーバのリストに１つ以上の新しい承認済みサーバを追加することができる。menu-authorization-server-listは、１つあるいはそれより多い情報行を備え、その各々が１つの承認済みサーバを定義する。ＧＳＭ／ＳＭＳについては、承認済みサーバはショートメッセージ・サービス・センターおよびサーバの、対の定義アイデンティティー（pair defining identity）例えばＳＭ−ＳＣについての移動加入者国際ＩＳＤＮ番号であるＳＭＳＣのＭＳ−ＩＳＤＮと承認済みサーバについての移動加入者国際ＩＳＤＮ番号であるサーバのＭＳ−ＩＳＤＮによって定義される。コマンド・シーケンスは下記の通りであって良い。

第２のプリミティブ承認コマンドであるauthorization-removeを使って、与えられたメニュー（menu-group-name)について承認済みサーバのリストから１つあるいはそれより多い承認済みサーバを除去することができる。コマンド・シーケンスは下記の通りであって良い。

第３のプリミティブ承認コマンドであるauthorization-listを使って、要求されたメニュー（menu-group-name)についての特権を有するサーバのリストを送出するようにハンドセットに要求することができる。このコマンドを利用可能性はハンドセットの実現による。コマンド・シーケンスは下記の通りであって良い。

メニュー・アプリケーションは種々のコマンドの意味を記憶している。これを例えば端末においてソフトウェアとしてのスクリプト解釈プログラム(script interpreters）の形式で行うことができる。スクリプト解釈プログラムの１例は、特定のプログラミング言語を理解する解釈プログラムである。従って、特定のコマンドまたはコマンドのシーケンスが本発明のユーザ・メッセージで受信されたとき、メニュー・アプリケーションはそれに応じて、追加または除去メニューおよび／またはサブメニューなどの動作を実行する。上記は実例と見なされなければならない。当然に、上記以外の種々のコマンドを使用することができ、それらは、１つのユーザ・メッセージに（例えばショートメッセージに）より多くのコマンドをはめ込むために、もっと短くても良い。

ショートメッセージに対してメニュー・アプリケーションを使用するときには、ユーザ・メッセージをメニュー・アイテムによって起動するときに、そのメッセージが特定のショートメッセージ・サービス・センターを介してあるいは特定のリストのいずれかのＳＭ−ＳＣへ送出されることとなるように、１個または数個のショートメッセージ・サービス・センター（ＳＭ−ＳＣ）の番号をメニューに関連づけることができる。例えばメニューが作成されあるいは更新されるときに、特定のあるいは種々のＳＭ−ＳＣの番号をネットワークから端末へユーザ・メッセージで送出することができる。この様にすれば、特定のメニュー・コマンドを介してアクセスすることのできる特別のサービスが（あるいはそのサービスを提供するサーバが）特定のサービス・センターに接続されるとき、サービスの可能性が増え、ユーザ・メッセージの送信がより速くかつ信頼できるものとなる。

ユーザがディスプレイ上に見るものを例示するディスプレイのシーケンスとして、呼び出し音のためのメニューを作成する例が図１１に示されている。最新の呼び出し音を要求するためにコマンド「NEW RINGING TONES 」がユーザ・メッセージで呼び出し音サービス・プロバイダのサーバに送出される。応答として、サーバはメニューを作成するためのメニュー・アプリケーションに関連する情報を含むユーザ・メッセージを送出し、それからユーザは新しい呼び出し音を選択することができる。ユーザは望ましい呼び出し音をメニューの中から選択する（呼び出し音「Popcorn 」を選ぶ）。この選択で、サーバに送出すべき、所望の呼び出し音を示すユーザ・メッセージが起動される。しばらくして端末はその呼び出し音をサーバから受信する。受信された呼び出し音は、「RINGING TONE RECEIVED （呼び出し音受信）」通知によってユーザに示される。ユーザはその呼び出し音を容認しあるいは拒絶することができる。ユーザが容認を表示すると、「Save（保存）」および「Playback（再生）」というオプションのある選択メニューが表示される。ユーザがSaveオプションを選ぶと、受信された呼び出し音は電話機に保存され、それは呼び出し音オプション・メニューに現れる。保存動作は、「SAVED （保存済み）」確認記号を表示することによってユーザに表示され、その後に電話機はアイドル状態となる。もしユーザがPlaybackオプションを選ぶと、受信された呼び出し音が再生され、その後に元の選択リストが再び表示される。もしユーザが新しい呼び出し音を拒絶すると、受信された呼び出し音は捨てられて、選択リストがスクリーンから除去され、電話機はアイドル状態になる。

次に、端末において機能を生成するコマンドのアプリケーションの別の例について、図１２を参照して説明する。この例は、ある飛行便の時刻表を問い合わせることに関する。まず、ユーザはこの目的のために作られたメニュー・コマンドを既に端末に持っていると仮定するが、そのコマンドは端末が本発明に従って受信したものであって良い。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLE（フィンエアー飛行便時刻表）は、要求が送出されるべきサーバの連絡情報を有しており、あるいは、もし端末が特別の交信をしたならば、要求はその交信から、要求されるべきサービス、すなわちフライトスケジュールのあるサーバに回送される。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLEを起動すると、第１のユーザ・メッセージは要求を送信することを示すコードまたは記号を有し、例えば、１）最初に送られるユーザ・メッセージは下記の通りである。

???FLIGHTS

ここで「???FLIGHTS」は、それがフィンエアー飛行便時刻表を求める要求であることを受信側サーバに示すコマンドである。ユーザは、そのメッセージの内容は見ず、要求が送信されること、それが送信されたこと、および回答が来るまでユーザが待たなければならないこと、を示すディスプレイ上の記号を見る。それらの記号が図１２においてステップ１）の後に示されている。この後、端末はサービス・プロバイダからユーザ・メッセージを受信する。例えば、

２）第１の受信したユーザ・メッセージは下記の通りである。

++Finnair flight queryCR
<From:CR
<To:CR
<+Date:CR

ここで++は、端末に回答を待つように指示するものであり、その後のテキストはしばらくの間端末のスクリーンで表示され、CR（Carriage Return ：キャリッジリターン）はコマンド行を終了させる。記号「< 」は文字入力モードを示し、この'<' 記号の後のテキストは、図１２に示されているように端末のスクリーンで表示され、これはユーザが文字を入力することを可能にする。この例では、要求がオウル（Oulu）市からのフライトに関するものであることを示すOUL が入力される。ユーザは所定のコマンド（例えば特定のキーを押すことなど）で入力を終了する。同様に行き先を示す次の入力モードがディスプレイで表示され、ユーザは要求がヘルシンキ市への飛行便に関するものであることを示すHEL を入力する。記号「<+」は、数字入力モードを示しており、この記号の後のテキストは、図１２に示されているように端末のスクリーンで表示され、これはユーザが数字を入力することを可能にするものであって、この場合には要求された飛行便の日付である。最後のコマンドに達すると、端末は書式が完成したか否か、そして要求を送出することができるか否かを尋ね、もしそうならば端末は入力情報を含む第２のユーザ・メッセージを作成して送信する。例えば、

３）２番目に送るユーザ・メッセージは下記の通りである。

++Finnair flight queryCR
<From:OULCR
<To:HELCR
<+Date:041296CR

これをサービス・プロバイダ（サーバ）は所定コマンドに従って解釈することができる。この場合にもユーザはこのユーザ・メッセージの内容を見ず、所定の記号が端末のスクリーンで表示される。この要求に対する応答として端末はサービス・プロバイダから２番の受信したユーザ・メッセージを受信する。例えば、

４）２番目に受信されたユーザ・メッセージは下記の通りである。

Finnair flights frm OUL to HEL 04/12/96:CRAY3434, 06:05 AY3436, 07:00 AY3438, 07:30 AY3440, 10:15

端末は、関連情報（アプリケーション固有のコードではない）を、図１２に示されているようにユーザに表示し、ユーザが（例えば矢印キーあるいはその他のスクロール手段で）情報をスクロールできるようにし、ユーザインターフェースからのクイットコマンド（a quit command）に応答して、元のメニュー・コマンドを表示する状態に戻る。

上記の、図１２に図示されている例は、所定のコマンドに対応する所定の記号を有することによって、新しいサービスを移動電話機等の端末に提供するために本発明のユーザ・メッセージをどのように使えるかを示している。これらの記号およびコマンドは、ユーザの端末装置（例えば移動電話機）あるいはサービス・プロバイダの端末装置（例えばコンピュータ）の、メモリに記憶することができ、その所定コマンドを実行するためにプロセッサにより動かされるソフトウェアで実現することができる。この様にして端末が特定の方法で機能するようにプログラムすることもまたできる。メニュー・アプリケーションは新しいアプリケーションを端末に導入することを可能にする。例えば、第１のメニュー（例えばメニュー「電話帳」）を作るサービス・プロバイダから、第１のユーザ・メッセージによって前述した電話帳アプリケーションを端末に導入することができ、その後、要求をサービス・プロバイダに送出するときに端末は最初に前述したように関連電話番号を得るのに必要な情報を送るためにメニュー構造を受信し、関連情報を送った後に端末はその電話番号を含む応答を受け取る。この処理手順は、フライトの時刻表を問い合わせるための、図１１と関連して前に説明した処理手順と同様である。

次に、端末に前もって記憶されていない他のアプリケーションについて図８〜１０、および付録１を参照して説明する。端末により、移動通信ネットワークを通して電子メールを送出することができる。これに対応して、端末により、移動通信ネットワークを通してインターネットとの通信リンクを確立することができる。データ・カードによって、コンピュータを移動局に接続することにより、この通信リンクを確立することができ、この場合には、そのコンピュータのユーザインターフェースを使ってインターネット上のページおよびサービスを読むことができる。代わりにインターネットとの通信リンクを通信機器によって確立しても良く、それは、インターネット上のページおよびサービスを読むためのユーザインターフェースを備える。この種の通信機器が１９９６年２月２６日に出願されたフィンランド特許出願第９６０８９４号に提示されており、この特許出願からの優先権を主張して１９９７年１月２７日にＥＰＯに対応する特許出願が出願番号第９７１０１１８４．６号で出願されており、米国では１９９７年１月２３日に出願されており、その説明を参照により本件に取り入れたものとする。インターネット上の種々のページとの通信リンクを確立することを可能にすると共に、インターネット上でのいわゆるサーフィンを可能にするコンピュータ・プログラムは、ＷＷＷ（ワールドワイドウェブ）ブラウザと呼ばれている。現在、幾つかの会社が自分のサービス・ページをインターネット上に持っており、それを通してユーザはサービスに関する情報を注文したりあるいは注文を出して予約をすることができる。これは、その様なサービス・ページとの通信を確立して、そのサービスのプロバイダから要求するものに関する情報を入力することによって達成される。この情報はテキストまたは選択ボックス／キーであって良く、これによって「適当なボックスにチェックする（tick the appropriate box）」原理に従って選択を行う。このようなサービス・ページの例が図８に示されており、この図はバスの時刻表についての問い合わせページを示しており、これをユーザは例えばインターネット等の電気通信ネットワークを通してディスプレイにダウンロードすることができる。この場合、ページはそのページが使用される間はその通信機器のメモリ（例えば隠されたメモリ：hidden memory)に記憶されており、それをオフラインコマンドによって固定記憶装置に記憶することができる。そのページ上で、ボックスで選択を行うことができると共に、追加した要求と、例えば、フィードバックのための連絡情報とをそのページ上で利用できるスペースに書き込むことができる。代わりに、「コール・ミー・バック」アプリケーションと関連して前述したように、通信機器が、自分の電話番号を、フィードバックのためのアドレスとして自動的に提供しても良い。公知のように、インターネット上のページをＨＴＭＬ（Hyper Text Markup Language：ハイパーテキストマークアップ言語）で表示することができる。インターネットからのサービス・ページをＨＴＭＬ言語に変換し表示することはＷＷＷブラウザから知られる。

付録１はインターネットのページを記号で表すためにＨＴＭＬ言語に変換された図８のインターネット・ページを例示している。これらの文字をショートメッセージで送ることができる。ＧＳＭシステムでは、最長で１６０文字の長さのメッセージをショートメッセージで送出することができる。従って、本発明では、ページ全体を好適には送信することはできなくて、その中のある情報だけが送られる。このサービス・ページ上のＨＴＭＬコードでは、ディスプレイで表示されるべき情報と、隠された情報との両方が指定されている。種々のタイプのデータが前もってセットされたコードを有する。本発明に従ってこのページを送出するために、アプリケーション関連情報を送出するのに必要な情報が、そのページのＨＴＭＬコードに付け加えられ、この情報はユーザには秘密にされる、すなわち、それはそのページのグラフィック表示には含まれない。その情報は好適にはサービスのプロバイダによってページ上で配置されている。このようなサービス・ページをショートメッセージとして送信するために、サービスのプロバイダは、当該ページに特別の情報、少なくともメッセージを送出する相手の電話番号、を含ませることによって問題の機会を与えるべきである。付録１に例示されている矢印Ａ〜Ｊの箇所に、本発明に従ってページの情報をショートメッセージで送出するためにＨＴＭＬコードに付け加えられる情報が表示されている。例えば、矢印Ａでは、表示されている仕様によって符号化方法を示すことができる。矢印Ｂは書式のタイプが問い合わせであることを示している。矢印Ｃは、サービス・プロバイダの名称あるいは略号を示している。矢印Ｄは、当該サービスのタイプを示している。矢印Ｅは、サービス・ページの名称を表示している。矢印Ｆは、回答を表示するために端末が使用するべき書式を示している。矢印Ｇは、受信者すなわちサービス・プロバイダの電話番号を表示している。矢印Ｈは、このメッセージの送信で経由されるショートメッセージ・サービス・センターの電話番号を表示している。矢印ＧおよびＨにより示されている情報は、少なくとも不可欠である。矢印ＩおよびＪは、必要に応じてＨＴＭＬページに付け加えることのできる他の仕様を表示している。矢印Ｊの後に、当該ＷＷＷページを形成する実際のＨＴＭＬコードが続いている。

それに相応して、ＨＴＭＬコードの特定の識別子を発見するように端末を前もってセットしておくことができ、それを端末はＨＴＭＬコードから見つけだして、送出されるメッセージのデータ・フィールドＩＮＦＯにそれを文字として添付する（図６を参照）。例えば、選択された時間は、矢印Ｋにより指示されている行の中に変数c/o としてわかり、その後にその選択された時間が表示されており、それはＳＥＮＤボタンを押す動作に対する応答として得られる。図８に例示されているように、一番上の選択ボックス「1B1 」に印が付けられており、それは付録１のＨＴＭＬコードでは矢印Ｌで指示されているチェック付きコードとして行の中に示されている。一番上の選択ボックスが選択されているとすると、ユーザがＳＥＮＤボタンを押せば、変数opt1は、アイコンを押したときに選択された選択ボックスの値すなわち「1B1 」を得る。

図８および付録１に例示されている例では、通信機器等の端末は、このようにして、矢印Ｃ、Ｄ、Ｇ、Ｈ、Ｋ、およびＬにより指示されている行の中のＨＴＭＬコードから情報を選び出す。端末は、冒頭に、アプリケーションのタイプを示す識別子を、ここでは識別子「WWWSMS」として、置くであろう。さらに、矢印Ｃにより指示されるポイントから、サービス・プロバイダ識別子を前に置くことができ、これに基づいて受信者は当該情報、例えば、ここでは記号Ｃを認識する。さらに、それに相応して、サービス名を矢印Ｄのポイントから置くことができ、送信者の電話番号を矢印Ｇのポイントから置くことができ、受信者の電話番号を矢印Ｄのポイントから置くことができ、選択はユーザにより、矢印ＫおよびＬのポイントから行われるが、それは、このページ上の全ての変数（ここでは変数c/o およびopt1）がメッセージ中に配置されることとなるように、機能する。変数の値は、好適には、送出コマンドに対する応答として、すなわちＳＥＮＤアイコンを押す動作に対する応答として、得られる。この場合、ショートメッセージで送られるデータは、例えば、次の通りである。

WWWSMS[cr]
CErSa[f]
DTre Bus[f]
G+358505337397[f]
H+358508771010[f]
08:00 1B1

ここで[cr]文字は改行を意味し、[f] 文字はフィールド区切り符号(field separator）であってフィールドの終わりを示すものであり、最後の行でユーザによりなされた全ての選択が表示される。すなわち、ユーザが08:00 時後に出発する路線１Ｂ１（Holvasti-Keskustori ）のバスの時刻表に関する情報を求めていることが表示される。これに基づいて、サービス・プロバイダは、当該バス路線の時刻表に関する情報をユーザに送出することができる。

このタイプのサービス・ページをインターネットからダウンロードしたならば、それを端末のメモリに記憶して、後にインターネットとの通信リンクを確立せずにそれを再利用することができる。それに相応して、端末に前もって記憶されているアプリケーション関連情報に関して、図８および付録１に例示されているアプリケーションに関する情報の送出と関連して、特定の識別子をメッセージに添付することができ、それは、アプリケーションがインターネットからダウンロードされたサービス・ページであることを示すものであり、例えば前述の例のように識別子「WWWSMS」あるいは「WWWSMS45」であり、その冒頭部はこれがサービス・ページであることを示し、最後の２つの記号は、例えば、サービス・プロバイダを示すことができる。

本発明によってサービス・ページの情報をショートメッセージで送出すると、端末の電力消費量が相当節約され、従ってその実用寿命が長くなるが、これは電池駆動式装置における重要な目標である。さらに、問い合わせ情報をショートメッセージと共に送出できるときには、電話コールの費用が節約されることになる。システム全体が図９にいっそう詳しく例示されている。本発明の端末が参照番号１で指示されており、これによりインターネットＩＮＴとの通信リンク（参照番号１０１）を確立することができる。本発明によるアプリケーションに関する情報を処理してショートメッセージにするための手段を有する装置によって本発明を実施することもでき、それは装置を普通の移動局に結合することによってその移動局を通して送出される。その様な装置は、例えば、コンピュータである。事柄を単純にするために、本発明の端末の例としてここでは通信機器のみについて論じる。通信機器１によってインターネットとの通信リンクが確立されると、サービス・プロバイダのサービス・ページをインターネットからそのメモリおよびユーザインターフェースにダウンロードする（参照番号１０２）ことができる。従来技術の公知の解決策により、ユーザは、そのページに書き込みをした後、そのサービス・ページを通信機器１によってサービス・プロバイダのサーバＳＥＲＶへ、すなわちルート１０１−１０１’に沿って、送出することができる。このことは、インターネットとの通信リンクが送信のためにオープンでなければならないことを意味する。本発明のシステムでは、サービス・ページに関する情報はショートメッセージでショートメッセージ・サービス・センターＳＭ−ＳＣに送られ（参照番号１０３）、このセンターはそれをさらにサービス・プロバイダのサーバＳＥＲＶに送る（参照番号１０４）。従来技術によるインターネット経由でのサービス・ページの送信はショートメッセージの送信より相当長く続くので、本発明により、より短い送信時間が達成されることになり、従って、通信機器では特に送信および受信が他の機能と比べて大量の電力を消費するので、電力が節約されることになる。さらに、従来技術の解決策では、回線結合接続が送信時に使用され、この場合には通信機器は送信中は話中になる。一方、ショートメッセージの送信は回線結合接続を話中にせず、メッセージの送信中にサービス・プロバイダの電話番号がたまたま届かなかったならば、ショートメッセージ・サービス・センターＳＭ−ＳＣが後でそのメッセージを受信者に送出するという付加的利点もある。

ユーザがこのようにしてサービス・プロバイダに問い合わせを送ると、そのサービス・プロバイダはそれを解釈して、それに対して応答する。サービス・プロバイダも応答をショートメッセージとして送出することができ（参照番号１０５−１０６）、それはサービス・ページの送信の場合と同じ方法でＨＴＭＬコードを含むことができ、これを通信機器は解釈してユーザが読みやすい形式に変換する。従って、応答の送出にも問い合わせの送出の場合と同じ利点がある。応答のために、インターネットからダウンロードされたオリジナルのサービス・ページを、そのページに応答のために使用できるスペース（フィールド）ができるように、ＨＴＭＬコード・ページを動かすアプリケーションによりディスプレイ上で配置することができる。ユーザは、問い合わせをサービス・プロバイダに送出するとき、そのページを通信機器に記憶する。応答は、送信の場合と同じ方法で、特別の識別子を有し、その場合には応答が到達すると、通信機器はその特定のアプリケーションを動かせてディスプレイ上に当該ページを開いて、そのために設けられている領域にその応答を置くので、ユーザの見地からは状況はあたかもユーザがその応答を含むＷＷＷページを受け取ったかのように見える。サービス・プロバイダからの応答は、例えばアプリケーション「ＤＴＭＦサービス・コマンド」あるいはそれに相当する書式であっても良い。

アプリケーション識別子は、ショートメッセージにおいて（データ・フィールドＩＮＦＯにおいて）コードとして表示される代わりに、ショートメッセージのアドレス・フィールドＡＤＤにおいて表示されても良く、その場合にはそれはビットで表示される。ショートメッセージの送信フレームのアドレス・フィールドの一定のバイトは、ＧＳＭ仕様でGSM 03.40 および03.38 として明定されているいわゆるＴＰデータ符号化方式(TD-Data-Coding-Scheme）である。そのバイトの下位４ビットは自由に使えるビットであり、これを本発明に従って送出されるべきアプリケーションのタイプを示すために使用することができる。下記の表で与えられる例に従ってこれら４ビットにより種々のタイプのアプリケーションを表示することができるが、ここでビットには符号ｂ３〜ｂ０が付けられていて、ｂ０は前述のバイトの最下位ビット（ＬＳＢ）である：

このやり方でアプリケーションを特定すれば、メッセージの文字長（最大で１６０文字）のために予約されているスペースを使わなくても良い。このタイプの識別を使えば、普通の移動局によって送信されたアプリケーションに関する情報を受信することも可能であるが、この場合には、ユーザは、そのメッセージに関して、この情報が移動局でプログラムされたものでなければ、それが特別のアプリケーションからの情報であることを知ることはできない。また、ユーザはこのタイプの識別子をメッセージに付け加えることはできないので、普通の移動局によってこのタイプのアプリケーションに関する情報を送出することはできない。当然に、普通の移動電話機は種々のアプリケーションをサポートしない。

次に、端末、この場合には本発明の無線端末の実現と、アプリケーション関連情報を送信および受信するときのその動作と、を図１０を参照してさらに詳しく説明する。

図１０は、本発明の端末の実現のブロック図であり、それはこの図では移動電話機等の無線による送信のための手段も有する装置として示されている。しかし、類似の実現をサービス・プロバイダの端末装置に使っても良いけれども、それは普通は直接無線周波数送信のための手段を有してなくて、図２に示されるような手段（例えば移動局）にネットワークを介して接続される（例えば、パソコンＰＣまたはサーバＧＴＷ）。端末は好適には移動電話機または通信機器であり、それは種々のアプリケーションを処理できるようにする回路とユーザインターフェースとを持っている。図１０の端末１は、無線通信を使う通信を行うために、無線ユニットＲＵ（この参照符号は図には付されていない）を備え、それは、普通の移動局とは区別される送信器ブランチ（transmitter branch）２（符号化、インターリーブ、暗号化、変調、および送信、を実現するブロックを備える）と、受信側ブランチ（receiving branch）３（受信、復調、解読、インターリーブ解除、および実行、のブロックを備える）と、を備えており、また無線通信を使う送信のために、受信されたメッセージと送信されるメッセージとを区別する双方向フィルター(duplex filter）４とアンテナ５とを備える。この端末は、その動作を制御する主制御回路６を有する。さらに、主制御回路６は、普通の移動局の機能の制御機能を実行するＲＵコントローラ７も有する。さらに、端末の主制御回路６は、端末のデータ処理ユニットの機能を実行すると共にアプリケーション関連情報を本発明に従ってショートメッセージとして送信する、ためのブロック８〜１２を有する。従って、ブロック８〜１２は、端末のデータ処理ユニットＤＵを形成するものであると言うことができる。無線ユニットＲＵの制御部および端末のデータ処理ユニットＤＵを主制御回路に統合する必要はなく、代わりにそれらを別々に実現することもできて、ＲＵ制御回路７を無線ユニットの側に置き、データ処理ユニットの側にはＤＵプロセッサ８を置くことができ、それは、無線ユニットとデータ処理ユニットとの間の通信を確立するためにＲＵ制御回路と接続される。

図９に例示されている実現では、第１のメモリ１３は主制御回路６に結合されている。第１のメモリは例えばＲＡＭ等の揮発性メモリであって良く、これに主制御回路は使用中のデータを記憶しておく。さらに、端末は第２のメモリ１４を有し、これは好適には固定記憶装置１４であって、種々のサービスを実行すると共に種々のアプリケーションを動作させる端末のアプリケーション・プログラムと、端末の動作に不可欠の他のデータと、ユーザが永久的に記憶しておきたい他のデータと、が第２のメモリに記憶される。あるいは、端末に結合され、そこから主制御回路６に接続される外付けスマートカードのメモリにアプリケーション関連情報をオフラインで記憶しても良い。このタイプのスマートカードは、例えばＧＳＭ移動通信システムからＳＩＭカード（Subscriber Identity Module：加入者識別モジュール）として知られており、それは普通は例えば電話番号を記憶させておくための記憶装置(storase）を持っている。この場合、スマートカードのメモリを単に更新することによって新しいアプリケーションを端末において更新することができる。

アプリケーションを見るために、端末はディスプレイ１５を有しており、データを入力するためにキーボードやその他の、例えばタッチ・ディスプレイ等の入力装置１６を持っている。

データ処理ユニットＤＵおよび無線ユニットＲＵが、機能に関して独立しているユニットとして実現される場合にも、その両方が、共通のあるいは別々のメモリ１３、１４とユーザインターフェースＵＩとを有するべきである。これらのユニット間の通信はＤＵプロセッサ８とＲＵ制御回路７との接続によって確立され、それはこの関係では外付け制御インターフェースＥＣＩと呼ばれる。

次に、アプリケーション関連情報を送信するときの、端末装置の実現と端末の動作とについて説明する。ユーザインターフェースＵＩによって、所要のアプリケーションが端末のディスプレイにもたらされ、その場合には入力装置からの１６種類のコマンドに基づいて、制御回路７は、アプリケーション関連情報をプログラマブルに取り扱うアプリケーション１７、１８が記憶されているメモリ１４から、これに記憶されている選択されたアプリケーションをディスプレイ１５に取りだし、あるいは前述したように電気通信ネットワークからサービスを取り出す。サービスに関連するアプリケーションはＤＵプロセッサ８で処理されるが、これは、無線ユニットＲＵの動作を制御するＲＵ制御回路７との交信を保つことによってアプリケーション関連情報の送信も制御する。アプリケーションは、図７に例示されているように、情報を含んでいる。その情報は１つあるいはそれより多いフィールドの中にあり、そのフィールドは（もし既に情報を含んでいるアプリケーションの記録がメモリから取り出されたならば）すでに満たされているか、あるいはそのデータ・フィールドは空であり、その場合にはユーザは入力装置１６によってそのフィールドに情報を入力したり、あるいはそのフィールドの中の情報を修正したりすることができる。アプリケーションが所要の情報を含んでいて、ユーザが入力装置によってアプリケーション関連情報を送出するコマンドを入力すると、ＤＵプロセッサ８は、そのアプリケーションに関する情報から記号の行を形成し、そのプロセッサは、その行の冒頭にアプリケーション識別子を置き（もしその識別子がアドレス・フィールドで表示されていなければ）、そしてその後に、例えば、改行文字で区切られた種々のフィールドに含まれている情報を、記号間にありえるのスペースも含む英数字文字で作り変えて、配置する。従って、ＤＵプロセッサ８は、文字の処理のために、ワードプロセッサ・プログラムに類似する機能を備えており、それはプログラミングにより実現されてメモリ１４に記憶されており、そこからＤＵプロセッサ８はそのプログラムを取りだして、そのプログラムに従って機能を実行する。ＤＵプロセッサ８は、形成された文字の行をＳＭＳ送信コントローラ１０へ転送し、そのコントローラは、そのメッセージにアドレス情報を、すなわち、宛先に関する情報を、ユーザが入力した情報に基づいて、あるいはそれを例えば前述したようにカレンダー・アプリケーションなどの別のアプリケーションから取りだして、付け加える。従って、この種のＳＭＳ送信コントローラは一種のビットおよび／または文字生成器である。カレンダーは好適には、ＤＵプロセッサ８により使用されるメモリ１４に記憶されるアプリケーション・プログラムとして実現される。したがって、２つの異なるアプリケーション１７および１８の間の通信はＤＵプロセッサによって確立され、このプロセッサは、例えば、１つのアプリケーションから取り出された時間情報に基づいて、他方のアプリケーションを開いたりそれに情報を入れたりする（例えば当該時間にカレンダーの中に）。

アドレス情報がＳＭＳ送信コントローラ１０で追加されているときには、そのメッセージはアウトボックス１１へ転送され、これはそのメッセージを送出しようと試みるものであって、バッファを有しており、送信が失敗した場合にはその中に該メッセージが記憶される。送信が失敗したら、アウトボックス１１はもう一度メッセージを送出しようと試みる。無線ユニットＲＵがメッセージを送出できる状態になっていることにＤＵコントローラ８が気づいたとき、そのメッセージはメッセージ転送動作回路１２へ転送され、この回路は、妥当性情報（validity information）（これは、そのメッセージがどの方向に進むのか、すなわち、移動局からメッセージ・サービス・センターへ進むのか、あるいはその逆に進むのか、を示す）などの、当該移動通信システムに関連する情報をそのメッセージに付け加え、アドレス情報を処理して移動通信システムが必要とする書式に変換し、メッセージ・サービス・センターのアドレスとショートメッセージ識別子（ＳＡＰＩ）とをそのメッセージに付け加え、送信されるべき情報から例えば送信器２のためのディジタル信号を形成し、そのメッセージを無線ユニットＲＵの無線送信器ブランチ２に送出する。アプリケーション識別子がビットの形でアドレス・フィールドＡＤＤに置かれる場合には、動作回路１２はそのメッセージに当該識別子を付け加える。送信器ブランチ２は、移動通信システムの仕様に従って信号を符号化し、自分が動作回路１２から受信した信号に基づいて、送信されるべきフレームを作成し、これを送信器は無線通信を使ってショートメッセージ・サービス・センターＳＭ−ＳＣに送出し、そこから該フレームはさらに受信者に送出される（図１を参照）。送信器ブランチ２では、移動通信システムに応じてメッセージが処理される。すなわち、符号化、インターリーブ、暗号化、バースト形成、変調、および送信が行われる。

次に、アプリケーション関連情報を受信するときの端末の実現および動作について説明する。端末がアプリケーションについての情報を含むショートメッセージを受信するとき、そのメッセージは始めに無線ユニットＲＵに到着する。その受信側ブランチ３で、受信、復調、解読、インターリーブ解除、および復号などの処理が移動通信システムに従ってそのメッセージに対して行われる。もし受信されたフレーム識別子（ＳＡＰＩ）が、そのメッセージがショートメッセージであることを示しているならば、それはデータ処理ユニットのインボックス９へ転送されるが、これは該メッセージを記憶しておくためのメモリであって良い。もし受信されたメッセージが普通のショートメッセージであれば、ＤＵプロセッサ８は受信されたメッセージを伝える。それがアプリケーション関連情報であることを示す識別子をそのメッセージが有していれば、ＤＵプロセッサ８は当該アプリケーション１７、１８を送り出して、受信されたメッセージからの情報を、受信されたメッセージのマーキングに従ってアプリケーションの中に置く。従って、ユーザ・メッセージ（例えばショートメッセージ）の受信は、受信されたアプリケーション関連情報としてユーザに表示される。

本件は、本発明の実現および実施例を例示しながら提示している。本発明が前述の実施例の詳細には制限されないこと、そして本発明の特徴から逸脱せずに別の実施例で本発明を実現し得ることは当業者にとっては明白なことである。従って、提示した実施例は例示としてみなされ制限をするものではないと解されなければならない。従って、本発明を実現し利用する可能性は、特許請求項によってのみ限定されるに過ぎない。それに相応して、クレームにより決まる本発明のいろいろな実現のオプションは、その同等の実現も含めて、本発明の範囲に属する。

付録１

一方の移動局からもう一方の移動局へのショートメッセージの流れを例示する。 ショートメッセージ・サービス・センターへの移動局システムの接続を例示する。 普通の移動電話機のユーザインターフェースを例示する。 送信時のメッセージのフレームへのセグメント化を例示する。 受信時のメッセージの復元を例示する。 ショートメッセージのフレームを例示する。 本発明の１つのアプリケーションを例示する。 別のアプリケーションを例示する。 システムの見地からの、図８に例示されているアプリケーション関連情報の送信を例示する。 本発明の端末の実現を例示する。 本発明の端末における１アプリケーションの機能を順に例示する。 本発明の端末における１アプリケーションの機能を順に例示する。

符号の説明

１ 端末
２ 送信器ブランチ
３ 受信側ブランチ
４ 双方向フィルター
５ アンテナ
６ 主制御回路
７ ＲＵ制御回路
８ ＤＵプロセッサ
９ インボックス
１０ ＳＭＳ送信コントローラ
１１ アウトボックス
１２ メッセージ転送動作回路
１３ 第１のメモリ
１４ 第２のメモリ
１５ ディスプレイ
１６ 入力装置
１７ アプリケーション
１８ アプリケーション

Claims (7)

1. 少なくとも１つのメニュー・アイテムを有するメニューを無線通信ネットワーク用の端末内に生成する方法であって、前記端末は、メニュー・アイテム間のスクロールおよびメニュー・アイテムの選択を可能とする、方法において、前記方法は、
   第１の所定コマンドを含む第１のユーザ・メッセージを、前記無線通信ネットワークを介して装置から前記端末へと送信するステップと、
   これに応答して、前記第１のユーザ・メッセージを前記端末にて受信するステップと、
   前記第１の所定コマンドに従ってメニュー・アイテムを前記端末内に生成するステップと、
   前記メニュー・アイテムを前記端末のディスプレイ上に表示するステップと、
   生成されたメニュー・アイテムの選択を可能とするステップと、
   前記メニュー・アイテムを将来の使用のために前記端末内に格納するステップと、を備え、
   前記第１のユーザ・メッセージは複数のアプリケーションのうちの１つに関連する情報およびヘッダを有し、
   前記情報を前記ヘッダに従ってそれぞれのアプリケーションに向けてアドレス指定し、
   メニュー・アプリケーションに関連する前記第１の所定コマンドを、前記第１のユーザ・メッセージ中の情報として受信し、前記メニュー・アプリケーションは、前記第１の所定コマンドを備える前記第１のユーザ・メッセージの受信に応答して前記メニュー・アイテムを生成する、方法。
2. 前記端末は、移動通信ネットワークの移動局であり、前記装置は、前記移動通信ネットワークへの接続を有するサーバである、請求項１に記載の方法。
3. 前記した前記メニュー・アイテムを将来の使用のために前記端末内に格納するステップは、前記メニュー・アイテムを前記端末のメニュー構造におけるメインメニューのレベルで格納するステップである、請求項１に記載の方法。
4. 前記した前記メニュー・アイテムを将来の使用のために前記端末内に格納するステップは、前記メニュー・アイテムを前記端末のメニュー構造におけるメインメニュー下のサブメニューのレベルで格納するステップである、備える請求項１に記載の方法。
5. 前記メニュー・アイテムの選択を可能とした後、前記端末から、生成されたメニュー・アイテムを削除するステップをさらに備える請求項１に記載の方法。
6. 生成されたメニュー・アイテムが選択されると、第２のユーザ・メッセージを前記端末から前記装置へと送信するステップをさらに備える請求項１に記載の方法。
7. 第３のユーザ・メッセージを前記端末へ送信することにより、前記の生成されたメニュー・アイテムを変更または削除可能とするステップであって、前記第３のユーザ・メッセージは、第２の所定コマンドを含むステップをさらに備える請求項１に記載の方法。

Images