電子ビジネス・カードを転送する方法、および、端末
【課題】アプリケーション関連情報を簡単に送信および受信する方法を実現する。
【解決手段】第1の装置と第2の装置との間で電子ビジネス・カードを転送する方法であって、第2の装置は、第1の装置から遠方にあり、第1および第2の装置の両者は、移動通信ネットワークを介して通信することができる移動局、および移動通信ネットワークへの接続を有するコンピュータのうちの1つである方法は、いくつかのデータ・フィールドを各々有する複数の電子ビジネス・カードを含む第1の装置のビジネス・カード・アプリケーションから、電子ビジネス・カードを検索するステップと、ビジネス・カードを、移動通信ネットワークを介して第2の装置へ送信するステップと、受信したビジネス・カードを、第2の装置のビジネス・カード・アプリケーション内に記憶するステップと、を備える。
【解決手段】第1の装置と第2の装置との間で電子ビジネス・カードを転送する方法であって、第2の装置は、第1の装置から遠方にあり、第1および第2の装置の両者は、移動通信ネットワークを介して通信することができる移動局、および移動通信ネットワークへの接続を有するコンピュータのうちの1つである方法は、いくつかのデータ・フィールドを各々有する複数の電子ビジネス・カードを含む第1の装置のビジネス・カード・アプリケーションから、電子ビジネス・カードを検索するステップと、ビジネス・カードを、移動通信ネットワークを介して第2の装置へ送信するステップと、受信したビジネス・カードを、第2の装置のビジネス・カード・アプリケーション内に記憶するステップと、を備える。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信ネットワーク用の端末に関し、この端末は、複数のアプリケーションを支援することのできるものであって、ユーザ・メッセージを通信するための手段を有する。本発明は、また、送信端末と、複数のアプリケーションをサポートすることのできる受信端末とを備える通信ネットワークにおけるシステムにも関し、この両方の端末がユーザ・メッセージを通信する手段を有する。
【背景技術】
【0002】
現在、普通の移動局機能の他に、例えばカレンダーの維持、ファックス・メッセージの送出、および電子メールなどを可能にするデータ処理機能も有する通信機器(comunicator)が開発されつつある。それらの通信機器は、オーガナイザ形の装置のように異なる数種類のアプリケーションを有しあるいは支援することができる。例えばテキスト・メッセージなどをタイプしやすい在来の英数字キーボードに類似するキーボードを有するユーザインターフェースを備えた1種の通信機器が開示されている(例えば、特許文献1)。この公報では、キーボードはタッチ・ディスプレイによって実現されている。しかし、在来の移動電話機が発展するに従って、特にユーザインターフェースおよびディスプレイがさらに発展するに従って、在来の移動電話機のような装置によって、もっと進歩した動作が可能になろう。
【0003】
【特許文献1】米国特許第5422656号明細書
【特許文献2】特開平7−236179号公報
【特許文献3】特開平7−202931号公報
【特許文献4】特開平7−84858号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
公報WO94/23394は、走査して例えば無線通信を使って類似の通信機器に送ることのできる種々のタイプのグリーティングカードを有する通信機器のための電子メール・サーバを備えた電子グリーティングカード通信システムを提示している。このシステムの欠点は、該当するグリーティングカードを類似の通信機器にしか送れないことである。従って、送出者は受信者がグリーティングカード通信システムをサポートする通信機器を持っているか否か知らなければならない。さらに、システムを実現するためには、種々のタイプのグリーティングカードを記憶しておくためのオフライン電子メール・サーバを当該サービスのためにネットワークに個別に接続しなければならない。このシステムは普通の無線通信でグリーティングカードを送信するので、通信機器の電話回線が送信中は話中になるということが別の欠点である。この公報に提示されている通信機器によって、手書きテキストを有するグラフィック・イメージを送信することもできる。その様なイメージあるいは単なる手書きメッセージの送信は、情報量が大きいために極めて低速である。公報WO94/23394は、1つのアプリケーションあるいはサービス、すなわちグリーティングカード・アプリケーション、に関する情報の送出について論じているだけである。通信機器類似の装置が異なる数個のアプリケーションを有するために、種々のアプリケーションに関連する情報をどの様に送出したり処理したりするかという問題が生じる。このWO公報では、特定のグリーティングカード・サービスのために別々の電子メール・サーバが配置されている。しかし、通信機器の各アプリケーションのために別々の電子メール・サーバを設けるのは、どちらかというと複雑で高価な解決策となろう。さらに、例えば通信機器などの端末において種々のサービスに関連する情報をどの様に処理するかという問題に直面する結果となる。
【課題を解決するための手段】
【0005】
本発明は、通信ネットワーク用の端末に関し、この端末は複数のアプリケーションを支援することができて、ユーザ・メッセージを通信するための手段を持っており、その端末は、そのアプリケーションのうちの1つと関連するデータおよびヘッダを有するユーザ・メッセージを受信するための手段と、このヘッダに従ってそれぞれのアプリケーションへ向けてデータをアドレス指定するための手段とを有する。従って端末は、複数の異なるアプリケーションを後の段階で端末に組み込むことができるようになっている。アプリケーションを後で追加することは、他の装置への無線での直接接触によって実行することができる。1つのユーザ・メッセージはヘッダが指示する1つのアプリケーションに関連するデータを含むことができ、あるいは、例えば特定のアプリケーションを指示するヘッダの後にそのアプリケーションに関連するデータが続くこととなるように、ユーザ・メッセージは種々のヘッダにより指示される数個のアプリケーションに関連するデータを含むことができる。
【0006】
ユーザ・メッセージは、限られた量の情報を含んでいるので、素早く送信することができる。ユーザ・メッセージの1つのタイプはいわゆるショートメッセージである。本発明は、ショートメッセージのユーザにより実施されるのに特に適している。規格IS−136に準拠する移動電話システムは、類似のショートメッセージを送信するためにいわゆるRデータ・フィールドを使用する。SMS類似のメッセージも送ることのできるGSMシステムで知られている他の種類のユーザ・メッセージ送信機能はUSSD(Unstructured Supplementary Service Data : 無構造補助サービス・データ)であり、これはGSM仕様において、例えば次の文書、TS GSM 02.04、TS GSM 02.30、TS GSM 02.90、TS GSM 03.38、TS GSM 03.40、などで、詳しく定義されている。SOC(Service Operator Code : サービス・オペレータ・コード)と呼ばれる類似のメッセージ送信形式(messaging form)が規格IS−136に準拠する移動電話システムに存在する。SMS、Rデータ、USSDおよびSOCのような通信形式を本書ではユーザ・メッセージ送信機能と称し、その様なメッセージをユーザだけでなくてオペレータが送信することもできるが、メッセージをユーザ・メッセージと称することにする。この種の通信の利点は、音声通話チャネルを全く保留しないか、あるいは少なくとも連続的には保留しないことである。
【0007】
パケット交換通信にも同様の利点がある。移動通信ネットワークにおいてパケット交換情報を中継するためのPRMA(Packet Reservation Multiple Access:パケット予約多元接続)に基づくプロトコルが知られている。これは「パケット無線(Packet Radio)」とも呼ばれる。PRMAは、パケット書式のディジタル音声あるいはデータを多重化して時分割搬送波にするための技術である。パケット無線サービス、すなわちGSM移動無線システムのために開発中のGSM GPRS(General Packet Radio Service:一般パケット無線サービス)、を例として取り上げる。GPRSは、GSM加入者にパケット無線サービスを提供する新しいGSMサービスである。GPRSは、送信するべきものが何かあるときだけ無線資源を予約するものであり、従って同じ資源を全ての移動局が自分たちの必要に応じて共有できるようにするものである。従って、短時間だけ通信チャネルを保留するパケット無線通信をユーザ・メッセージ送信のために利用することができる。
【0008】
本発明は如何なるユーザ・メッセージをも利用できることであるけれども、以下の記述では主としてショートメッセージを実例として参照する。高速で送出するということに加えて、音声チャネルを保留しないなどの、ショートメッセージ・サービスの利点を利用することができる。アプリケーション関連情報を端末装置のメモリ(固定記憶装置)に前もって記憶させておくこともできるが、ユーザは端末の手段によってサーバと連絡を取って端末のメモリ(キャッシュ・メモリ)にアプリケーション関連情報を記憶させることもできる。アプリケーションに応じて、ユーザはアプリケーションでユーザ入力を入力したり情報を修正したりすることができる。他のアプリケーションでは、アプリケーションに関連する情報をサービス・プロバイダにより送出することができ、その情報は、ユーザが修正できなくて、サービス・プロバイダに修正を依頼できるに過ぎないような情報であっても良い。アプリケーションで容易にプリントされる情報も送信することができる。受信側の端末がそのショートメッセージを普通のショートメッセージではなくて特定のアプリケーションに関連するアプリケーション向け情報を含むショートメッセージであると識別できるように、アプリケーションの種類の識別子またはヘッダを通信メッセージに付け加えるのが好都合である。その識別子は、ショートメッセージのアドレス・フィールドまたは制御フィールド中のコードであっても良いし、あるいはショートメッセージのメッセージ部分中のコードであっても良い。移動局システムに既に存在するショートメッセージ・サービスを利用してアプリケーションに関する情報を送出できることが分かっているので、例えば、公報WO94/23394に提示されているシステムなどでアプリケーション関連情報を送るためにオフライン・サーバを設定する必要が無いという利点がある。唯一のサーバすなわちSMSサーバ(ショートメッセージ・サービス・センターSM−SC)を使ってどの様なアプリケーションに関連する情報でも送出したり回送したりできるので、各アプリケーションのために別々のサーバを持つ必要はないということが特に有利である。SMSサーバはどんなメッセージでも回送し、端末はメッセージ中のヘッダまたは識別子に従って正しいアプリケーションへ向けて情報をアドレス指定する。また、ショートメッセージを回路結合接続(circuit-coupled connection)と同時に送れるので、例えば同時に入接続呼がある場合などに、アプリケーション関連情報の送出は端末の通信回線を話中にしない。GSMネットワークのようなネットワークは幾つかのオペレータによって維持され、普通は各オペレータが自分のSMSサーバを少なくとも1つ持っている。この場合、当然に、どのSMSサーバも、あるいは数個のサーバも、本発明のために使用することができる。
【0009】
本発明は、第1の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの1つについての情報と、そのアプリケーションのうちの1つに関連するヘッダとを有するショートメッセージを受信するための手段と、そのヘッダに従ってそのアプリケーションのうちの1つに向けて情報をアドレス指定するための手段とを備えることを特徴とする。
【0010】
本発明は、第2の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの1つに関連する情報を処理して記号に変換し、その処理済み情報をショートメッセージで送出するための手段と、そのショートメッセージにヘッダを付け加えるための手段とを有し、そのヘッダは、その情報が関連するアプリケーションを表示するものであることを特徴とする。
【発明の効果】
【0011】
本発明の端末は、アプリケーション関連情報を簡単に送信および受信する方法を提供する。また本発明は、例えば前述のメニュー・アプリケーションを使って大量のサービスへのアクセスを有することができる端末を提供する。特にショートメッセージを通信書式として使用することによって宛先の到着が保証され、ユーザ・メッセージで一般に最適の電流消費が達成される。ユーザ・メッセージとの関連での承認トークンの使用は、ユーザ・メッセージにセキュリティを加える新しい方法を説明する。
【発明を実施するための最良の形態】
【0012】
次に添付図面と付録とを参照して本発明について詳しく説明する。
【0013】
付録1は、図8に例示されている、記号で表されたアプリケーション関連情報を例示する。
【0014】
次に、ユーザ・メッセージ機能の1つの形式としてのショートメッセージ・サービスを実例として取り上げて、本発明を詳しく説明する。本発明を理解するために、始めに図1〜5を参照してショートメッセージに関連する従来技術を解説し、図7〜12および付録1を参照して本発明の実施例について説明する。
【0015】
GSMシステムのようなディジタル移動通信システムでは、いわゆるショートメッセージを送出することができる。GSMシステムでは、これはSMS(Short Message Service : ショートメッセージ・サービス)として知られている。この様に、電話コールおよびデータ転送の他に、GSMシステムはショートメッセージ・サービスの形式でページング・システムに類似するサービスも提供している。しかし、GSMシステムから知られているショートメッセージ・サービスは、普通のページング・システムより非常に進歩している。移動局により、テキスト・メッセージを他の移動局とやりとりすることができる。GSMシステムのショートメッセージ・サービスの1つの利点は、また、例えば通話中に、普通の回線結合通信が開始されているときに同時にショートメッセージを送出しあるいは受信することができることである。従って、ショートメッセージを送出しても、たとえ入接続呼がある場合でも移動局は話中状態に保たれない。
【0016】
電話コールと比べたときのショートメッセージの利点は、ショートメッセージが送信されつつあるときには受信器と連絡を取れないにもかかわらずショートメッセージを受信器に送出することができるということである。これは、第1の移動局から第2の移動局へのショートメッセージの送信を図1に示されているように2つの部分に分割することによって実現される。すなわち送信側移動局MS1からSM−SC(ショートメッセージ・サービス・センター)へ送出され、ここにショートメッセージが記憶されて、さらに実際の目的地すなわち受信側移動局MS2へ、連絡が取れ次第直ちに送出される。図2には、移動局システムへのショートメッセージ・サービス・センターSM−SCの接続が詳しく例示されている。以下に、従来技術について、公知である種々のインターフェース間でのショートメッセージの送信および流れについて図1〜5を参照して説明する。
【0017】
移動局システムの構造と、ショートメッセージを送信するための接続とが図2に例示されている。移動局MSは無線通信により基地局BTSに接続される。基地局BTSは、さらにいわゆるAbisインターフェースを通して基地局コントローラBSCに接続され、この基地局コントローラは数個の基地局を制御管理する。数個の基地局BTS(通常、数十個の基地局)と、これらの基地局を制御する単一の基地局コントローラBSCとで形成されるエンティティは、基地局システムBSSと呼ばれている。特に、基地局コントローラBSCは、無線通信チャネルとハンドオーバーとを管理する。一方、基地局コントローラBSCは、いわゆるAインターフェースを通して、移動局からの接続の形成および移動局への接続の形成の両方を調整する移動サービス交換センターMSCに接続される。移動サービス交換センターMSCを通して移動通信ネットワークの外部との接続がなされる。前述のショートメッセージ・サービス・センターSM−SCは移動サービス交換センターMSCに結合される。
【0018】
ユーザは、移動局MS1によってショートメッセージを送りたいときには(図1)、送信されるべきメッセージを(移動局のユーザインターフェースを使って)書き込み、そのメッセージが送られることになる移動局MS2の電話番号すなわち移動局MS2の識別子を与える。さらに、移動局は、連絡情報すなわちショートメッセージ・サービス・センターSM−SCの電話番号を有するべきである。普通は、これは移動局のメモリに記憶されており、その場合にはショートメッセージの送信に関する電話番号を個別に入力する必要はない。ショートメッセージを送るときには、メッセージは移動局MSから基地局BTSに行き、そこから基地局コントローラBSCおよび移動サービス交換センターMSCを介して、さらにショートメッセージ・サービス・センターSM−SCに行く。ショートメッセージはショートメッセージ・サービス・センターSM−SCに記憶され、ここからショートメッセージはさらに受信側移動局MS2へ送出され、その場合にはメッセージのルートは送信時と同じであるが方向が逆である。移動局MS2がそのショートメッセージを受信したか否かがショートメッセージ・サービス・センターSM−SCに知らされる。従って、これは、もし何らかの理由で移動局MS2がそのショートメッセージを受け取っていなければ、それを送り直すことができる。
【0019】
さらに、ショートメッセージをパソコンPCから送出することもできる。この場合には、移動サービス交換センターMSCは、例えばインターネットとの接続を有するサーバGTW(ゲートウェイ)との接続を有する。従って、インターネットとの接続を有する(あるいは破線で図示されているようにサーバGTWと直接接続している)コンピュータPCはインターネットからWWW(ワールドワイドウェブ)ページを引き出すことができ、それは物理的には例えばサーバGTWから見つけることができる。随意的に、サービス・プロバイダまたはオペレータは、ショートメッセージあるいはその他のユーザ・メッセージを送出するために、移動サービス交換センターMSCとの接続を有する独立のサーバGTWを有していても良い。ショートメッセージを送出するためにそのようなWWWページを使うときには、ユーザは受信側端末MS2の接続情報(例えば電話番号)と送出されるべきメッセージとを入力し、そのメッセージはインターネットとサーバGTWとを介して移動サービス交換センターMSCへ転送され、さらにショートメッセージ・サービス・センターSM−SCへ送られ、そこからそのメッセージは移動通信網を介して受信側端末MS2へ送られる。
【0020】
GSMシステムのショートメッセージ・サービスSMSによって、最大で160文字の長さのメッセージを一度に送ることができる。文字は7ビットのASCII(American National Standard Code for Information Interchange : 情報交換用米国標準コード)文字であり、従って、メッセージの最大長さはビット単位で1,120ビット、すなわち140バイトである。図3に例示されているような普通の移動局は、小型のディスプレイと進歩したキーボードとを持っており、これにより短いメッセージを書くことができる、すなわち種々の英数字を入力することができる。受信されたメッセージは、図3に例示されているように英数字を表示できる移動局のディスプレイで表示される。
【0021】
用知の通り、GSMシステムでは通信メッセージはフレームに分割される。送信されるべきメッセージの長さが、フレームFRの許容最大長さを上回るときには、図4に例示されているようにメッセージMを幾つかの部分M1〜M4に分割して数個のフレームFR1〜FR4で送出しなければならない。受信時には、移動局は、図5に示されているように、数個のフレームFR1〜FR4に分割されているメッセージMを復元する。無線インターフェース(図2)では、フレームの最大長さは普通は168または184ビットであるので、最大長さが1、120ビットであるショートメッセージを数個のフレームにセグメント化しなければならない。図6は、普通は3つのフィールドに分割されている、無線インターフェースで送信されるフレームであるいわゆるLAPDmフレーム(Link Access Protocol for the Dm channel :Dmチャネル用リンク・アクセス・プロトコル)を例示している。第1フィールドはアドレス・フィールドADDであり、これは数バイトで表示されるメッセージの宛先のアドレス(すなわち、受信側移動局の識別子)である。GSMシステムでは、対応するLAPDmフレーム内でシグナリングメッセージも送信される。無線通信では、互いに無関係の2つのメッセージ、すなわちシグナリングメッセージとショートメッセージと、のフローが同時に存在できる。この2つの異なるフローは、アドレス・フィールドADDに付加されるサービス・アクセス・ポイント識別子SAPIによって分離される。その値は、信号を示す3であるか、あるいはショートメッセージを示す0である。第2フィールドは制御フィールドCTRLであり、これは送信しているフレーム番号N(S)と受信しているフレーム番号N(F)とを含んでいる。第3フィールドは実際の情報あるいはデータを含むデータ・フィールドINFOであり、これは最大で168ビットの情報すなわち実際のショートメッセージの内容を含んでいる。
【0022】
本発明では、ショートメッセージを例として取り上げると、各アプリケーション関連情報の送信は、特別のコードすなわち識別子によって識別され、それは受信側端末が受信したメッセージを処理して、受信したデータを含む指定されたアプリケーションに直接入れることを可能にするものである。その識別子は好適にはASCII文字を使用してショートメッセージ送信フレームの情報フィールド、すなわち実際のショートメッセージを文字の形で含むフィールドINFO(図6)で実現される。代わりに、ショートメッセージを送出するためにデータはいずれにせよビットに変換されるので、識別子は他の何らかの文字またはビット等のストリング・コード(string code)の形であっても良い。アプリケーションに関連する情報はショートメッセージで送信されるので、そのアプリケーション・サービスをサポートしないがショートメッセージを送信しおよび/または受信することのできる普通の移動局で、そのショートメッセージを受信することもできる。アプリケーション識別子をフィールドINFOに置けば、このタイプのアプリケーション・サービスをサポートしないけれどもショートメッセージを送信しおよび/または受信することのできる普通の移動局において、そのアプリケーション識別子が端末、例えば通信機器のユーザに表示され、従ってユーザは普通のショートメッセージではなくて特定のアプリケーションに関連する情報を受信したということに気づくという利点もある。また、このタイプの普通の移動局のユーザは、始めにメッセージに当該アプリケーションの識別子を記号で書き、そして正しく分割された情報の残りを書くことによって、前述したメッセージ等のメッセージを送信することもできる。本発明に従って、端末装置によってこの通信メッセージを受信すれば、完全に受信されたアプリケーション関連情報記録が得られる。
【0023】
代わりに、アプリケーション識別子はショートメッセージのアドレスまたは情報フィールド(図6を参照)において、特定のビット・コードとして形成される。さらに、この場合、普通の移動局は特定のアプリケーションに関連する送信された情報を受信することができるが、ユーザは、そのメッセージに関して、受信したメッセージが特定のアプリケーションのための情報であるということを知ることはできない。この場合、特定のコマンドを入力すると、移動局が前述のビット・コードを付加することとなるように移動局を改造しなければ、その普通の移動局はアプリケーション識別子を知らせることはできないので、この種のアプリケーションのための情報を普通の移動局で送信することはできない。
【0024】
図7は、端末装置に予め記憶されるアプリケーション記録を有するアプリケーションの例を例示しており、それにユーザ入力された情報(アプリケーション記録)は、ショートメッセージとして別の端末に送出されることができる。このアプリケーションのタイプは“ビジネス・カード”と呼ばれる。このアプリケーションは、ビジネス・カードの内容を走らせるものであって、氏名、職名、会社名、連絡情報、などの情報を含んでいる。各情報がそれ自身のフィールドに置かれても良く、あるいはアプリケーションがフィールドを1つだけ有して、その中に全ての情報が置かれても良い。図7は、アプリケーションに関する情報の、ショートメッセージとしての送信も示している。この場合、アプリケーションのタイプの識別子は例えば図に例示されるように“BC”または“Business Card ”である。本発明の端末は、このアプリケーション識別子を(例えば文字あるいはその他の形で)始めに送信されるショートメッセージの情報フィールドの冒頭に付け加える。種々のフィールドの内容は自動的に改行文字で終わる。この文字に基づいて、受信側の端末は、受信した情報をアプリケーションの対応するフィールドに分割することができる。このタイプのメッセージが普通の移動局からショートメッセージとして送信されるのであれば、ユーザは、そのメッセージの冒頭にアプリケーション識別子、すなわち、図7の場合には「Business Card 」とを書き、その後に改行文字[cr]を書き、その後にアプリケーションに関する情報を(アプリケーション仕様に応じて)次々にあるいはフィールド毎に、すなわち始めに氏名フィールドを、次に改行文字を書く、等の手続きをする。受信した「Business Card 」を端末のメモリに記憶することができ、従ってそれにビジネス・カードを電子形式で記憶して、ビジネス・カード・アプリケーションでメモリからそれらを検索してみることができる。ビジネス・カード・アプリケーションの情報は、もちろん、装置に依存して変わる。或る端末では、それは、例えば、ショート・ダイヤル・アプリケーションとして使用することのできる氏名および電話番号だけを意味する。従って、ショート・ダイヤル・アプリケーションの内容を更新するために本発明を利用することができる。このようにして、ユーザは、内容をサービス・センターに送って記憶してもらうことによってショート・ダイヤル・アプリケーションの内容のバックアップを作ることができる。もし端末(例えば移動電話機)が後に紛失したり盗まれたりあるいは壊れたりして、ユーザが新しい端末を取得しなければならないことになっても、ユーザは、端末を起動することに加えて、ショート・ダイヤル・アプリケーションの内容全部をその端末にダウンロードする(引き込む)ことができる。もちろん、同じ解決策を端末のどのアプリケーションの内容にも使用することができる。ここで、他のいくつかのアプリケーションについて説明する。
【0025】
以下では、例として、他のタイプのアプリケーションについて論議する。それらのアプリケーションを端末に前もって記憶しても良く、あるいは後の段階で(プログラミングにより)端末に組み込んでも良い。
【0026】
「コール・ミー・バック(Call Me Back、折り返し電話をかけてください)」というアプリケーションは、人の氏名、電話番号、アドレス等と、その人が折り返し電話をするべきであるというメッセージとを含むことができる。この情報は、別個のフィールドに分割されても良く、あるいは、前述のように同じフィールドに置かれても良い。折り返し電話せよという前述のメッセージを「コール・ミー・バック」アプリケーションに密接に組み合わせても良く、および/または普通の移動局のディスプレイでも表示される(文章としての)“コール・ミー・バック”を識別子として書いても良く、その場合にはそのメッセージを受け取った当該移動局のユーザは、それが折り返し電話をすることを要求することであることを知ることができる。「コール・ミー・バック」アプリケーション関連情報の送信を出接続呼に結びつけて、もし宛先の端末が応答しなければ送信側のすなわち呼を発する側の端末がユーザ(発呼者)に「コール・ミー・バック」通知子を送出すべきか否か尋ねるようにしても良く、その場合には、そのユーザの応答が肯定であれば、それは予めアプリケーション・データ・フィールドに入力されている発呼者の電話番号(それは例えば自分のSIMカード、加入者識別モジュールからアクセスできる)で当該アプリケーションをディスプレイ上で走らせる。ユーザは、「コール・ミー・バック」アプリケーションで、情報の残りを入力し、ディスプレイ上でそれを修正することができる。アプリケーション関連情報がショートメッセージとして送出されるときには、端末は受信者の電話番号をそのメッセージの宛先として自動的に提供し、それを端末は未応答のままになっている呼についての情報から選び出すことができる。
【0027】
アプリケーション「Meeting Proposal、会合申し込み」の識別子は「Meeting Proposal」であって良く、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含むことができる。もし、端末に、電子カレンダー・アプリケーションもあるならば、このタイプのアプリケーション(会合申し込み)に関連する情報の送信に対する応答として、当該時間における会合の予約をカレンダーに設けるように、当該アプリケーション関連情報の送信をカレンダー・アプリケーションの動作と結びつけることができる。この特定のアプリケーションは、好適には、会合の時間をアプリケーションから選び出して、会合の場所および主題等の、そのアプリケーションに関する他の情報を招集者の氏名とともにカレンダーの当該時間の箇所に入力する。それに相応して、この種のアプリケーション関連情報を受け取ったときには、端末は自動的に当該時間について既に合意がなされているかも知れないものについての陳述を(もしカレンダーに入力されているならば)カレンダーから探す。従って、受信者は、会合申し込みに「イエス」と答えるか「ノー」と答えるか、素早く決めることができる。その回答を送出するとき、端末はアプリケーション「会合申し込み回答」を確立するが、その識別子は例えば「Meeting Proposal Answer 」であり、このアプリケーションの情報は、受信者の氏名、会合の時間および場所、主題、回答(イエス/ノー)、およびコメントを含むことができる。この場合、受信者、すなわち会合申し込みの送信者、の端末のカレンダー・アプリケーションは、カレンダーに設けられている予約を確認するかあるいは取り消すように調整される。
【0028】
さらに、「会合申し込み」アプリケーションの続きとして、端末にアプリケーション「会合確認」があっても良く、その識別子は例えば「Meeting Confirmation」であり、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含んでもよい。端末は、好適には、会合申し込みに「イエス」と回答した人たち全員にこのアプリケーション関連情報を自動的に送出するように申し出る。この場合、このアプリケーションに関連する情報を受信した移動局または通信機器は、カレンダーの中の当該予約を確認する。
【0029】
それに相応して、「会合申し込み」アプリケーションと同じ方法で、例えばアプリケーション「空き時間問い合わせ(Free Time Query)」などの、他の類似のアプリケーションを端末に設けることができ、その識別子は例えば「Free Time Query 」であり、このアプリケーションの情報は、送信者の氏名、時間、場所、および主題を含んでもよく、それはユーザが自由に書き込むことのできるものであって、例えばテニス、ディナーなどである。
【0030】
端末は、好適には、この関係では送信および受信の両方で、会合申し込みアプリケーションの場合と対応的に機能する。すなわち、端末は、カレンダーに予約を記入し、別のアプリケーションによって問い合わせに回答できるようにし、さらに、受け入れられるという確認あるいは取り消しをカレンダーに記入する。
【0031】
アプリケーション「サービスDTMFコマンド」により、例えば、ネットワークのオペレータから提供されるサービスを利用するためにそのオペレータから情報を受け取ることができる。アプリケーション識別子は「Service DTMF Commands 」であって良く、それは送信者の氏名、DTMFコマンド、および説明フィールドを持つことができる。コマンドは、例えば、パスワード、ユーザ識別子、あるいはその他の、オペレータから提供されるサービスに関連する何らかのものである。ユーザは、提供されるサービスを利用するときに、例えばパスワード等の、受信したコマンドを使用することができ、その場合には当該アプリケーション(またはそのアプリケーションの中の情報)からパスワードを直接得ることができるので、ユーザはキーボードを通してパスワードを入力しなくてもよい。ネットワークのオペレータから情報を受信することのできる他のアプリケーションは、端末においてアプリケーションを使用する前に何らかの設定を必要とするアプリケーションである。例としては「インターネット・アクセスポイント」アプリケーションであり、これは端末が例えばWWWブラウザを使用するために必要な情報を含む。その情報は、プロバイダの名称、電話番号、モデム初期設定情報、サーバ情報、IPアドレス(Internet Protocol :インターネット・プロトコル)であってもよい。何らかの設定を必要とするアプリケーションの別の例は、ファックス・ボックス・アプリケーションである。ファックス・ボックスは、例えばサーバで実現されるサービスであり、これは特定のユーザ宛の全てのファックスを受信する。ユーザはそのファックスをファックス・ボックスから回収することができる。ファックスを回収するために、端末はサーバ宛の連絡情報を有する必要がある。端末がファックス・ボックスに宛てられた新しいファックスを受信したときに、受信したファックスのユーザ・メッセージで端末が通知を受信するが、そのユーザ・メッセージがさらにUID情報(Unique Identifier :固有識別番号)すなわちファックス・ボックス・サーバ宛の連絡情報と、ファックスのファイル名および所要のパスワード等の他の所要の情報とも含むこととなるように、それを実現することができる。ファックス・ボックス・アプリケーションは、マニュアルで、すなわちユーザにより実行されて機能しても良く、あるいは、ユーザ通知メッセージに含まれている識別情報に従って受信されたファックスを自動的に回収するために端末がファックス・ボックス・サーバと連絡を取るように、そのアプリケーションが自動的に機能し得るようになっていても良い。ファックスを回収するためのファックス・コールとして連絡を取ることができる。随意的に、サーバが後に受信したファックスをファックス・コールを介して端末に送出するために端末と連絡を取ることができるように、その連絡は、識別情報をサーバに端末のファックス接続番号と共に送出するユーザ・メッセージであっても良い。
【0032】
本発明を使用する別の環境には、移動局に類似した装置を端末として使用するインテリジェント交通システムに関する解決策がある。本発明の端末は、その場合、種々の交通関連アプリケーションを有する。例としては「位置(Position)」アプリケーションであり、これで位置要求および応答を本発明に従ってユーザ・メッセージで送出/受信することができる。位置を確定するための種々の解決策がある。アプリケーション「位置」は、興味ある特定のアドレスまたは地点についての位置情報と、対応する位置についての記述、送信の理由あるいはモードを記述したフラグ、および、応答メッセージの場合には参照番号を含むことができる。受信した情報を対応するフィールドに分割した後、受信側端末は、受信した「位置」アプリケーション記録をローカルメモリに記憶する。端末は、自分自身の位置あるいは記憶されている位置情報をユーザ・メッセージで他の端末装置またはサーバに送ることもできる。これを例えば緊急事態の場合には自動的に実行することもできる。緊急事態のために、端末は独立の“緊急事態表示”あるいは“パニック表示”アプリケーションを有することができ、このアプリケーションは、自分の車両および自分の位置並びに緊急事態に必要なその他の関連情報についての送信者に関する情報を自動的に包含することができ、これを送信者はこのアプリケーションで修正することができる。
【0033】
交通目的の付加したアプリケーションは、例えば、「旅行要求(Trip Request)」および「旅行応答(Trip Responsel)」アプリケーションであり(あるいは一般的に「旅(Travel)」アプリケーション)、これは旅行支援アプリケーションである。このアプリケーションで、端末は、好適には出発地点としての端末の実際の位置と、その旅行の目的地として記憶されている位置アプリケーション記録から選択された位置と、を含む旅行要求を送り出すことができる。旅行要求に対する応答として、端末は「旅行応答」メッセージを受信することができ、それは、方向転換指示や公共輸送機関の接続などの、その旅行についての指示を含むことができる。
【0034】
また端末は、この端末のオリジナルの通し番号、製造月、修理月、および改造がなされた月(例えばソフトウェアの改造)などの、サービス目的のために重要であるかも知れない情報を伴うサービス・アプリケーションを有しても良い。このサービス・アプリケーション中の情報は、ユーザ・メッセージで端末から例えばオペレータまたはサービス・ステーションに送られることができる。
【0035】
実現可能な別のアプリケーションは、電話帳サービスを管理するサービス・プロバイダに電話番号問い合わせを送出するための電話帳アプリケーションである。その問い合わせは、氏名、在住地の市名、地上線/移動電話番号、などの情報を含むことができる。応答としてサービス・プロバイダは、電話番号と例えば元はユーザが送出した情報とを有するユーザ・メッセージを送出する。
【0036】
付加的なサービスおよびアプリケーションを有する多様な可能性を端末に与える別のタイプアプリケーションは「メニュー(Menu)」アプリケーションであり、これに端末は受信したユーザ・メッセージに従って端末でメニューを作ることのできるアプリケーションを含む。そのメニューは、好適には、該端末でいつまでも使用することのできるメニューを作るために、図10のメモリ14等の固定記憶装置に記憶される。ユーザ・メッセージは、それに応じて「メニュー」アプリケーションが端末のメニューを作ったり更新したりできるような情報を含む。これにより、無線経由で、すなわちユーザがサービス場所へ端末を持ち込む必要なく、オペレータがユーザの端末で更新することのできる非常に多様なサービスへのアクセスが可能となる。オペレータには、その加入者が使用するハンドセットを個人専用のものとするための非常に強力なツールが与えられることになる。このツールは、必要ならば加入者毎に異なることのあるハンドセット(handset)の、オペレータ固有のメニュー構造である。そのメニュー構造はユーザによる支援無しで無線経由で動的に更新されることができる。創作されたり更新されたりして、メニュー中のコマンドを起動することによりアクセスすることのできる付加的サービスをユーザに提供することのできるメニューの実例を下に挙げる。本来は、端末は何らかの基本メニューを包含することもできるが、メニューを全く包含していなくても良い。下記の実例において示されている全てのメニューおよびサブメニューは、メニュー・アプリケーションに関連するユーザ・メッセージを送出することによって作ることのできるものである。
【0037】
【表1】
【0038】
したがって、メニューあるいは各メニューは上記の様にメインメニューとサブメニューとを含むことができ、ここではメインメニューすなわちオペレータ・サービス、地域サービス、および個人向けサービスはサブメニューを含む。それらのサブメニューはさらにサブメニューに分割されても良く、例えばサブメニュー呼び出し音ダウンロード(Download Ringing Tones)は、呼び出し音のメロディ(Rock around the clock 、Those were the days 、Smoke on the water) によるサブメニューに分かれていても良く、特定のサブメニューを選択してそれをコマンドとして起動することによって、それらを呼び出し音として選ぶことができる。そのコマンドは本発明に従ってユーザ・メッセージとしてサービス・プロバイダに送出され、そのユーザ・メッセージに対する応答としてオペレータはユーザ・メッセージに符号化された呼び出し音を送出することができ、それは端末のおよび呼び出し音メモリに記憶されることができる。
【0039】
サブメニューでなされる選択は多様な動作を引き起こす。サブメニューのエントリーにURL(Uniform Resource Locater)情報を付随させることができ、これを使ってインターネットから情報を引き出したりe−メールをインターネットの受取人に送出したりすることができる。さらに、それらのエントリーから補足的サービスを直接開始させることもできる。特別の形式のURLを使って補足的サービス関連情報またはコールまたはユーザ・メッセージを伝えることができる。動作がネットワーク・エンティティによって情報を端末に送出させることもあり、例えば前述したように呼び出し音の選択とその後のダウンロードとを可能にする。その場合、オペレータ・サービス・メニューはURL情報に基づいてインターネットから情報を引き出させることができ、e−メール・メッセージを受取人に送出させることができ、オペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを開始させることができる。地域サービス・メニューは、特定地域向けのサービスをサポートする。一定地域で一定時間に利用することのできる「変わりやすい」サービスからメニュが生成さられる。ユーザはそれらのサービスをあさって、興味のあるものを選び出すことができる。この便宜は、ある地域を旅行している電話ユーザ宛てに情報(あるいはサービスの広告)を送るための簡単な手段を提供する。例えば、電話ユーザがダラス地域で州間高速自動車道(Interstate highway)75号線に近づくと、それらのサービスのうちの1つ、「Traffic at Dallas I−75」を利用できるようになる。このサービスをメニューから選択すると、その時点での交通情報を得ることができる。「個人向けサービス」メニューは、通常のWWWブラウザ(ワールドワイドウェブ)におけるブックマーク・リストにたとえることができる。電話ユーザはリストにアイテムを付け加えたり、それらを編集したり、それらを削除したりすることができる。この個人向けサービス・メニューによって、ユーザは多様なサービスを起動させることができる。サービス情報をオペレータ固有のあるいは地域サービスのリストから個人用サービス・リストに移すことができる。個人向けサービスメニューは、URL情報に基づいてインターネットから情報を引き出させることができ、e−メール・メッセージを受取人に送出させることができ、あるいはオペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを実行することができ、あるいはユーザ・メッセージを送出させることができる。例えばサブメニュー・コマンド「US気象(US weather)」は、端末に米国の気象に関する情報を受信させるということになる。
【0040】
次に、メニューの作成についてさらに詳しく説明する。メニュー作成は、プロセッサと、メモリに記憶されてそのプロセッサにより動かされるメニュー・アプリケーションにより制御され実現される。次に、プロトコルについて説明するが、このプロトコルに従ってメニュー・アプリケーションはプロセッサにより動かされるソフトウェアとして実行されることができる。後に図10と関連して端末について詳しく説明する。
【0041】
このプロトコルは所定のコマンドを定義し、それに従ってメニューの作成と変更およびメニュー構造が制御される。このプロトコルには4つのアイテム・プリミティブ(Item primitives)があり、それは追加、削除、リスト、およびアイテム能力である。これらのアイテム・プリミティブには、後述するように他のアイテム定義が伴う。
【0042】
第1のプリミティブ・アイテムはitem-addであり、これはメニューまたはサブメニューを追加する。コマンド・シーケンスは次の定義を含むことができ、それをユーザ・メッセージで端末に送ることができる。
【0043】
【表2】
【0044】
定義menu-item-token は、セキュリティが必要な場合にサーバが承認(authorization)目的に使用するオプションのコマンドであり、不要ならば省略しても良い。メニュー・アイテムが、セットされたmenu-item-token と共に送出されたならば、同じmenu-item-token が無しで既存のmenu-item を変更したり削除したりするコマンドを発することはできない。この種の承認の特徴を、メニュー・アプリケーションと関連して使用するだけではなく、ここに説明した他のアプリケーションと関連させて使用することもできる。例えば、呼び出し音は、menu-item-token のような正しい承認ワードまたはコードを伴っている場合に限って更新される。定義menu-group-name は、menu-item-nameという名称を持ったメニュー・アイテムがその中に入れられるメニュー・グループを明示する。もし同じ名称を持ったメニュー・アイテムが同じグループ内に既に存在するならば(そしてサーバが正しいmenu-item-token でそのメニュー・アイテムを更新することを承認されたならば)、既に存在するメニュー・アイテムは新しいものと置き換えられる。メニュー・グループの名称は、定義と関連してアポストロフィーの中に置かれる。
【0045】
定義menu-item-nameは、メニュー・グループ(またはメインメニュー)に属するsub-menuの名称またはコマンドを定義する。同様に、sub-menuの名称は定義と関連してアポストロフィーの中に置かれる。
【0046】
menu-group-name およびmenu-item-nameは共に「: 」という予約文字を有しており、これはメニュー・グループ・名称の中での改行という特別の意味を持っている、すなわち、「phone:settings」は、端末において「phone 」を1行目に表示し、「settings」を2行目に表示する。また、menu-group-name は「; 」という予約文字を持っており、これは複数階層メニューにおける階層レベルの変更を示すという特別の意味を持っている。
【0047】
menu-item-typeは、メニュー・アイテムのタイプが何かを示す。メニュー・アイテムは、「通常」、「変わりやすい(volatile)」、「選択された(変わりやすい)」、および「リンク」、というタイプを有することができ、その意味は下記の通りである:
【0048】
通常メニュー・アイテムは通常はハンドセットに記憶される。
【0049】
変わりやすいメニュー・アイテムは複数選択メニュー・アイテムについての、メニュー選択アイテムの1つ(one-of-menu selection items )である。
【0050】
選択された(変わりやすい)メニュー・アイテムは現在アクティブな変わりやすいメニュー・アイテムを示す。
【0051】
リンク・メニュー・アイテムは、サーバから変わりやすい選択項目を要求しなければならないことを端末装置に示す。
【0052】
定義menu-item-helpは、ハンドセットのユーザが現在のメニュー・アイテムに関してヘルプを必要とするときに表示されるテキスト・ストリングである。それはハンドセット固有であり、ハンドセットは例えばアイドル・タイマーが満了したときにヘルプ・テキストを自動的に表示する。menu-group-name およびmenu-item-nameについて前述したように、類似の付加的定義をmenu-item-helpと結びつけることができる。
【0053】
定義menu-action-listは、メニューから起動することのできる動作(アクション)のリストである。アクションは例えばaction-send-message のタイプ、あるいはaction-call-control のタイプである。action-send-message は、多くの方法のうちの1つでユーザ・メッセージを送出させる。その方法はメッセージのタイプによるが、それは前に明示したようにどんなユーザ・メッセージであっても良い(SMS、USSD、Rデータ、SOC、パケット無線)。action-call-control は、多くの方法のうちの1つでコールを行わせる。方法はcall-control-type に依存し、それは音声コール、データ・コール、ファックス・コール、あるいはss(補足的サービス・ストリングがネットワークに送出される)であって良い。
【0054】
第2のプリミティブ・アイテム・コマンドであるitem-remove は、(menu-item-token または承認リストに基づく)承認が欠けてはいないことを条件として、menu-group-name およびmenu-item-name) により識別されるメニュー・アイテムを端末から削除させる。コマンド・シーケンスは下記の通りであって良い。
【0055】
【表3】
【0056】
第3のプリミティブ・アイテム・コマンドであるitem-list は、このコマンドを当初に送出したサーバへmenu-item-nameのリストを端末から送出させる。サーバは、どのアイテムのリストが要求されているかについてのメニューを明示することができる。menu-item-token が与えられたとき、マッチしたトークンを持ったアイテムだけが返される。コマンド・シーケンスは下記の通りであって良い。
【0057】
【表4】
【0058】
第4のプリミティブ・アイテム・コマンドであるitem-capability を使って臨時の能力をメニュー・アイテムに付け加えたり除去したりすることができる。このコマンドを使って、例えば、明示された能力に応じてメニュー・アイテムにアイコンを付け加えることができる。コマンド・シーケンスは下記の通りであって良い。
【0059】
【表5】
【0060】
メニュー変更の承認を承認プリミティブによってより厳密に定義することができる。3つの承認プリミティブがあり、それは追加、除去、およびリストである。特にオペレータ・メニューおよび製造者メニューのために承認リストを使用することができる。これは、端末が何個のエントリーを各メニューの承認リストに記憶することができるかはその実現により固有である。承認プリミティブおよびそれらを端末に入力するためのコマンドを、menu-item プリミティブについて上述したのと同様にして実現することができる。承認コマンドは、その承認コマンドがアクティブな承認リストを伴うメニューについてのみ、既に承認されているサーバから送出されたときに限って、容認されるという意味で、特権を持っている。
【0061】
第1のプリミティブ承認コマンドであるauthorization-add を使って、与えられたメニュー(menu-group-name)について承認済みサーバのリストに1つ以上の新しい承認済みサーバを追加することができる。menu-authorization-server-listは、1つあるいはそれより多い情報行を備え、その各々が1つの承認済みサーバを定義する。GSM/SMSについては、承認済みサーバはショートメッセージ・サービス・センターおよびサーバの、対の定義アイデンティティー(pair defining identity)例えばSM−SCについての移動加入者国際ISDN番号であるSMSCのMS−ISDNと承認済みサーバについての移動加入者国際ISDN番号であるサーバのMS−ISDNによって定義される。コマンド・シーケンスは下記の通りであって良い。
【0062】
【表6】
【0063】
第2のプリミティブ承認コマンドであるauthorization-removeを使って、与えられたメニュー(menu-group-name)について承認済みサーバのリストから1つあるいはそれより多い承認済みサーバを除去することができる。コマンド・シーケンスは下記の通りであって良い。
【0064】
【表7】
【0065】
第3のプリミティブ承認コマンドであるauthorization-listを使って、要求されたメニュー(menu-group-name)についての特権を有するサーバのリストを送出するようにハンドセットに要求することができる。このコマンドを利用可能性はハンドセットの実現による。コマンド・シーケンスは下記の通りであって良い。
【0066】
【表8】
【0067】
メニュー・アプリケーションは種々のコマンドの意味を記憶している。これを例えば端末においてソフトウェアとしてのスクリプト解釈プログラム(script interpreters)の形式で行うことができる。スクリプト解釈プログラムの1例は、特定のプログラミング言語を理解する解釈プログラムである。従って、特定のコマンドまたはコマンドのシーケンスが本発明のユーザ・メッセージで受信されたとき、メニュー・アプリケーションはそれに応じて、追加または除去メニューおよび/またはサブメニューなどの動作を実行する。上記は実例と見なされなければならない。当然に、上記以外の種々のコマンドを使用することができ、それらは、1つのユーザ・メッセージに(例えばショートメッセージに)より多くのコマンドをはめ込むために、もっと短くても良い。
【0068】
ショートメッセージに対してメニュー・アプリケーションを使用するときには、ユーザ・メッセージをメニュー・アイテムによって起動するときに、そのメッセージが特定のショートメッセージ・サービス・センターを介してあるいは特定のリストのいずれかのSM−SCへ送出されることとなるように、1個または数個のショートメッセージ・サービス・センター(SM−SC)の番号をメニューに関連づけることができる。例えばメニューが作成されあるいは更新されるときに、特定のあるいは種々のSM−SCの番号をネットワークから端末へユーザ・メッセージで送出することができる。この様にすれば、特定のメニュー・コマンドを介してアクセスすることのできる特別のサービスが(あるいはそのサービスを提供するサーバが)特定のサービス・センターに接続されるとき、サービスの可能性が増え、ユーザ・メッセージの送信がより速くかつ信頼できるものとなる。
【0069】
ユーザがディスプレイ上に見るものを例示するディスプレイのシーケンスとして、呼び出し音のためのメニューを作成する例が図11に示されている。最新の呼び出し音を要求するためにコマンド「NEW RINGING TONES 」がユーザ・メッセージで呼び出し音サービス・プロバイダのサーバに送出される。応答として、サーバはメニューを作成するためのメニュー・アプリケーションに関連する情報を含むユーザ・メッセージを送出し、それからユーザは新しい呼び出し音を選択することができる。ユーザは望ましい呼び出し音をメニューの中から選択する(呼び出し音「Popcorn 」を選ぶ)。この選択で、サーバに送出すべき、所望の呼び出し音を示すユーザ・メッセージが起動される。しばらくして端末はその呼び出し音をサーバから受信する。受信された呼び出し音は、「RINGING TONE RECEIVED (呼び出し音受信)」通知によってユーザに示される。ユーザはその呼び出し音を容認しあるいは拒絶することができる。ユーザが容認を表示すると、「Save(保存)」および「Playback(再生)」というオプションのある選択メニューが表示される。ユーザがSaveオプションを選ぶと、受信された呼び出し音は電話機に保存され、それは呼び出し音オプション・メニューに現れる。保存動作は、「SAVED (保存済み)」確認記号を表示することによってユーザに表示され、その後に電話機はアイドル状態となる。もしユーザがPlaybackオプションを選ぶと、受信された呼び出し音が再生され、その後に元の選択リストが再び表示される。もしユーザが新しい呼び出し音を拒絶すると、受信された呼び出し音は捨てられて、選択リストがスクリーンから除去され、電話機はアイドル状態になる。
【0070】
次に、端末において機能を生成するコマンドのアプリケーションの別の例について、図12を参照して説明する。この例は、ある飛行便の時刻表を問い合わせることに関する。まず、ユーザはこの目的のために作られたメニュー・コマンドを既に端末に持っていると仮定するが、そのコマンドは端末が本発明に従って受信したものであって良い。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLE(フィンエアー飛行便時刻表)は、要求が送出されるべきサーバの連絡情報を有しており、あるいは、もし端末が特別の交信をしたならば、要求はその交信から、要求されるべきサービス、すなわちフライトスケジュールのあるサーバに回送される。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLEを起動すると、第1のユーザ・メッセージは要求を送信することを示すコードまたは記号を有し、例えば、1)最初に送られるユーザ・メッセージは下記の通りである。
【0071】
???FLIGHTS
【0072】
ここで「???FLIGHTS」は、それがフィンエアー飛行便時刻表を求める要求であることを受信側サーバに示すコマンドである。ユーザは、そのメッセージの内容は見ず、要求が送信されること、それが送信されたこと、および回答が来るまでユーザが待たなければならないこと、を示すディスプレイ上の記号を見る。それらの記号が図12においてステップ1)の後に示されている。この後、端末はサービス・プロバイダからユーザ・メッセージを受信する。例えば、
【0073】
2)第1の受信したユーザ・メッセージは下記の通りである。
【0074】
++Finnair flight queryCR
<From:CR
<To:CR
<+Date:CR
【0075】
ここで++は、端末に回答を待つように指示するものであり、その後のテキストはしばらくの間端末のスクリーンで表示され、CR(Carriage Return :キャリッジリターン)はコマンド行を終了させる。記号「< 」は文字入力モードを示し、この'<' 記号の後のテキストは、図12に示されているように端末のスクリーンで表示され、これはユーザが文字を入力することを可能にする。この例では、要求がオウル(Oulu)市からのフライトに関するものであることを示すOUL が入力される。ユーザは所定のコマンド(例えば特定のキーを押すことなど)で入力を終了する。同様に行き先を示す次の入力モードがディスプレイで表示され、ユーザは要求がヘルシンキ市への飛行便に関するものであることを示すHEL を入力する。記号「<+」は、数字入力モードを示しており、この記号の後のテキストは、図12に示されているように端末のスクリーンで表示され、これはユーザが数字を入力することを可能にするものであって、この場合には要求された飛行便の日付である。最後のコマンドに達すると、端末は書式が完成したか否か、そして要求を送出することができるか否かを尋ね、もしそうならば端末は入力情報を含む第2のユーザ・メッセージを作成して送信する。例えば、
【0076】
3)2番目に送るユーザ・メッセージは下記の通りである。
【0077】
++Finnair flight queryCR
<From:OULCR
<To:HELCR
<+Date:041296CR
【0078】
これをサービス・プロバイダ(サーバ)は所定コマンドに従って解釈することができる。この場合にもユーザはこのユーザ・メッセージの内容を見ず、所定の記号が端末のスクリーンで表示される。この要求に対する応答として端末はサービス・プロバイダから2番の受信したユーザ・メッセージを受信する。例えば、
【0079】
4)2番目に受信されたユーザ・メッセージは下記の通りである。
【0080】
Finnair flights frm OUL to HEL 04/12/96:CRAY3434, 06:05 AY3436, 07:00 AY3438, 07:30 AY3440, 10:15
【0081】
端末は、関連情報(アプリケーション固有のコードではない)を、図12に示されているようにユーザに表示し、ユーザが(例えば矢印キーあるいはその他のスクロール手段で)情報をスクロールできるようにし、ユーザインターフェースからのクイットコマンド(a quit command)に応答して、元のメニュー・コマンドを表示する状態に戻る。
【0082】
上記の、図12に図示されている例は、所定のコマンドに対応する所定の記号を有することによって、新しいサービスを移動電話機等の端末に提供するために本発明のユーザ・メッセージをどのように使えるかを示している。これらの記号およびコマンドは、ユーザの端末装置(例えば移動電話機)あるいはサービス・プロバイダの端末装置(例えばコンピュータ)の、メモリに記憶することができ、その所定コマンドを実行するためにプロセッサにより動かされるソフトウェアで実現することができる。この様にして端末が特定の方法で機能するようにプログラムすることもまたできる。メニュー・アプリケーションは新しいアプリケーションを端末に導入することを可能にする。例えば、第1のメニュー(例えばメニュー「電話帳」)を作るサービス・プロバイダから、第1のユーザ・メッセージによって前述した電話帳アプリケーションを端末に導入することができ、その後、要求をサービス・プロバイダに送出するときに端末は最初に前述したように関連電話番号を得るのに必要な情報を送るためにメニュー構造を受信し、関連情報を送った後に端末はその電話番号を含む応答を受け取る。この処理手順は、フライトの時刻表を問い合わせるための、図11と関連して前に説明した処理手順と同様である。
【0083】
次に、端末に前もって記憶されていない他のアプリケーションについて図8〜10、および付録1を参照して説明する。端末により、移動通信ネットワークを通して電子メールを送出することができる。これに対応して、端末により、移動通信ネットワークを通してインターネットとの通信リンクを確立することができる。データ・カードによって、コンピュータを移動局に接続することにより、この通信リンクを確立することができ、この場合には、そのコンピュータのユーザインターフェースを使ってインターネット上のページおよびサービスを読むことができる。代わりにインターネットとの通信リンクを通信機器によって確立しても良く、それは、インターネット上のページおよびサービスを読むためのユーザインターフェースを備える。この種の通信機器が1996年2月26日に出願されたフィンランド特許出願第960894号に提示されており、この特許出願からの優先権を主張して1997年1月27日にEPOに対応する特許出願が出願番号第97101184.6号で出願されており、米国では1997年1月23日に出願されており、その説明を参照により本件に取り入れたものとする。インターネット上の種々のページとの通信リンクを確立することを可能にすると共に、インターネット上でのいわゆるサーフィンを可能にするコンピュータ・プログラムは、WWW(ワールドワイドウェブ)ブラウザと呼ばれている。現在、幾つかの会社が自分のサービス・ページをインターネット上に持っており、それを通してユーザはサービスに関する情報を注文したりあるいは注文を出して予約をすることができる。これは、その様なサービス・ページとの通信を確立して、そのサービスのプロバイダから要求するものに関する情報を入力することによって達成される。この情報はテキストまたは選択ボックス/キーであって良く、これによって「適当なボックスにチェックする(tick the appropriate box)」原理に従って選択を行う。このようなサービス・ページの例が図8に示されており、この図はバスの時刻表についての問い合わせページを示しており、これをユーザは例えばインターネット等の電気通信ネットワークを通してディスプレイにダウンロードすることができる。この場合、ページはそのページが使用される間はその通信機器のメモリ(例えば隠されたメモリ:hidden memory)に記憶されており、それをオフラインコマンドによって固定記憶装置に記憶することができる。そのページ上で、ボックスで選択を行うことができると共に、追加した要求と、例えば、フィードバックのための連絡情報とをそのページ上で利用できるスペースに書き込むことができる。代わりに、「コール・ミー・バック」アプリケーションと関連して前述したように、通信機器が、自分の電話番号を、フィードバックのためのアドレスとして自動的に提供しても良い。公知のように、インターネット上のページをHTML(Hyper Text Markup Language:ハイパーテキストマークアップ言語)で表示することができる。インターネットからのサービス・ページをHTML言語に変換し表示することはWWWブラウザから知られる。
【0084】
付録1はインターネットのページを記号で表すためにHTML言語に変換された図8のインターネット・ページを例示している。これらの文字をショートメッセージで送ることができる。GSMシステムでは、最長で160文字の長さのメッセージをショートメッセージで送出することができる。従って、本発明では、ページ全体を好適には送信することはできなくて、その中のある情報だけが送られる。このサービス・ページ上のHTMLコードでは、ディスプレイで表示されるべき情報と、隠された情報との両方が指定されている。種々のタイプのデータが前もってセットされたコードを有する。本発明に従ってこのページを送出するために、アプリケーション関連情報を送出するのに必要な情報が、そのページのHTMLコードに付け加えられ、この情報はユーザには秘密にされる、すなわち、それはそのページのグラフィック表示には含まれない。その情報は好適にはサービスのプロバイダによってページ上で配置されている。このようなサービス・ページをショートメッセージとして送信するために、サービスのプロバイダは、当該ページに特別の情報、少なくともメッセージを送出する相手の電話番号、を含ませることによって問題の機会を与えるべきである。付録1に例示されている矢印A〜Jの箇所に、本発明に従ってページの情報をショートメッセージで送出するためにHTMLコードに付け加えられる情報が表示されている。例えば、矢印Aでは、表示されている仕様によって符号化方法を示すことができる。矢印Bは書式のタイプが問い合わせであることを示している。矢印Cは、サービス・プロバイダの名称あるいは略号を示している。矢印Dは、当該サービスのタイプを示している。矢印Eは、サービス・ページの名称を表示している。矢印Fは、回答を表示するために端末が使用するべき書式を示している。矢印Gは、受信者すなわちサービス・プロバイダの電話番号を表示している。矢印Hは、このメッセージの送信で経由されるショートメッセージ・サービス・センターの電話番号を表示している。矢印GおよびHにより示されている情報は、少なくとも不可欠である。矢印IおよびJは、必要に応じてHTMLページに付け加えることのできる他の仕様を表示している。矢印Jの後に、当該WWWページを形成する実際のHTMLコードが続いている。
【0085】
それに相応して、HTMLコードの特定の識別子を発見するように端末を前もってセットしておくことができ、それを端末はHTMLコードから見つけだして、送出されるメッセージのデータ・フィールドINFOにそれを文字として添付する(図6を参照)。例えば、選択された時間は、矢印Kにより指示されている行の中に変数c/o としてわかり、その後にその選択された時間が表示されており、それはSENDボタンを押す動作に対する応答として得られる。図8に例示されているように、一番上の選択ボックス「1B1 」に印が付けられており、それは付録1のHTMLコードでは矢印Lで指示されているチェック付きコードとして行の中に示されている。一番上の選択ボックスが選択されているとすると、ユーザがSENDボタンを押せば、変数opt1は、アイコンを押したときに選択された選択ボックスの値すなわち「1B1 」を得る。
【0086】
図8および付録1に例示されている例では、通信機器等の端末は、このようにして、矢印C、D、G、H、K、およびLにより指示されている行の中のHTMLコードから情報を選び出す。端末は、冒頭に、アプリケーションのタイプを示す識別子を、ここでは識別子「WWWSMS」として、置くであろう。さらに、矢印Cにより指示されるポイントから、サービス・プロバイダ識別子を前に置くことができ、これに基づいて受信者は当該情報、例えば、ここでは記号Cを認識する。さらに、それに相応して、サービス名を矢印Dのポイントから置くことができ、送信者の電話番号を矢印Gのポイントから置くことができ、受信者の電話番号を矢印Dのポイントから置くことができ、選択はユーザにより、矢印KおよびLのポイントから行われるが、それは、このページ上の全ての変数(ここでは変数c/o およびopt1)がメッセージ中に配置されることとなるように、機能する。変数の値は、好適には、送出コマンドに対する応答として、すなわちSENDアイコンを押す動作に対する応答として、得られる。この場合、ショートメッセージで送られるデータは、例えば、次の通りである。
【0087】
WWWSMS[cr]
CErSa[f]
DTre Bus[f]
G+358505337397[f]
H+358508771010[f]
08:00 1B1
【0088】
ここで[cr]文字は改行を意味し、[f] 文字はフィールド区切り符号(field separator)であってフィールドの終わりを示すものであり、最後の行でユーザによりなされた全ての選択が表示される。すなわち、ユーザが08:00 時後に出発する路線1B1(Holvasti-Keskustori )のバスの時刻表に関する情報を求めていることが表示される。これに基づいて、サービス・プロバイダは、当該バス路線の時刻表に関する情報をユーザに送出することができる。
【0089】
このタイプのサービス・ページをインターネットからダウンロードしたならば、それを端末のメモリに記憶して、後にインターネットとの通信リンクを確立せずにそれを再利用することができる。それに相応して、端末に前もって記憶されているアプリケーション関連情報に関して、図8および付録1に例示されているアプリケーションに関する情報の送出と関連して、特定の識別子をメッセージに添付することができ、それは、アプリケーションがインターネットからダウンロードされたサービス・ページであることを示すものであり、例えば前述の例のように識別子「WWWSMS」あるいは「WWWSMS45」であり、その冒頭部はこれがサービス・ページであることを示し、最後の2つの記号は、例えば、サービス・プロバイダを示すことができる。
【0090】
本発明によってサービス・ページの情報をショートメッセージで送出すると、端末の電力消費量が相当節約され、従ってその実用寿命が長くなるが、これは電池駆動式装置における重要な目標である。さらに、問い合わせ情報をショートメッセージと共に送出できるときには、電話コールの費用が節約されることになる。システム全体が図9にいっそう詳しく例示されている。本発明の端末が参照番号1で指示されており、これによりインターネットINTとの通信リンク(参照番号101)を確立することができる。本発明によるアプリケーションに関する情報を処理してショートメッセージにするための手段を有する装置によって本発明を実施することもでき、それは装置を普通の移動局に結合することによってその移動局を通して送出される。その様な装置は、例えば、コンピュータである。事柄を単純にするために、本発明の端末の例としてここでは通信機器のみについて論じる。通信機器1によってインターネットとの通信リンクが確立されると、サービス・プロバイダのサービス・ページをインターネットからそのメモリおよびユーザインターフェースにダウンロードする(参照番号102)ことができる。従来技術の公知の解決策により、ユーザは、そのページに書き込みをした後、そのサービス・ページを通信機器1によってサービス・プロバイダのサーバSERVへ、すなわちルート101−101’に沿って、送出することができる。このことは、インターネットとの通信リンクが送信のためにオープンでなければならないことを意味する。本発明のシステムでは、サービス・ページに関する情報はショートメッセージでショートメッセージ・サービス・センターSM−SCに送られ(参照番号103)、このセンターはそれをさらにサービス・プロバイダのサーバSERVに送る(参照番号104)。従来技術によるインターネット経由でのサービス・ページの送信はショートメッセージの送信より相当長く続くので、本発明により、より短い送信時間が達成されることになり、従って、通信機器では特に送信および受信が他の機能と比べて大量の電力を消費するので、電力が節約されることになる。さらに、従来技術の解決策では、回線結合接続が送信時に使用され、この場合には通信機器は送信中は話中になる。一方、ショートメッセージの送信は回線結合接続を話中にせず、メッセージの送信中にサービス・プロバイダの電話番号がたまたま届かなかったならば、ショートメッセージ・サービス・センターSM−SCが後でそのメッセージを受信者に送出するという付加的利点もある。
【0091】
ユーザがこのようにしてサービス・プロバイダに問い合わせを送ると、そのサービス・プロバイダはそれを解釈して、それに対して応答する。サービス・プロバイダも応答をショートメッセージとして送出することができ(参照番号105−106)、それはサービス・ページの送信の場合と同じ方法でHTMLコードを含むことができ、これを通信機器は解釈してユーザが読みやすい形式に変換する。従って、応答の送出にも問い合わせの送出の場合と同じ利点がある。応答のために、インターネットからダウンロードされたオリジナルのサービス・ページを、そのページに応答のために使用できるスペース(フィールド)ができるように、HTMLコード・ページを動かすアプリケーションによりディスプレイ上で配置することができる。ユーザは、問い合わせをサービス・プロバイダに送出するとき、そのページを通信機器に記憶する。応答は、送信の場合と同じ方法で、特別の識別子を有し、その場合には応答が到達すると、通信機器はその特定のアプリケーションを動かせてディスプレイ上に当該ページを開いて、そのために設けられている領域にその応答を置くので、ユーザの見地からは状況はあたかもユーザがその応答を含むWWWページを受け取ったかのように見える。サービス・プロバイダからの応答は、例えばアプリケーション「DTMFサービス・コマンド」あるいはそれに相当する書式であっても良い。
【0092】
アプリケーション識別子は、ショートメッセージにおいて(データ・フィールドINFOにおいて)コードとして表示される代わりに、ショートメッセージのアドレス・フィールドADDにおいて表示されても良く、その場合にはそれはビットで表示される。ショートメッセージの送信フレームのアドレス・フィールドの一定のバイトは、GSM仕様でGSM 03.40 および03.38 として明定されているいわゆるTPデータ符号化方式(TD-Data-Coding-Scheme)である。そのバイトの下位4ビットは自由に使えるビットであり、これを本発明に従って送出されるべきアプリケーションのタイプを示すために使用することができる。下記の表で与えられる例に従ってこれら4ビットにより種々のタイプのアプリケーションを表示することができるが、ここでビットには符号b3〜b0が付けられていて、b0は前述のバイトの最下位ビット(LSB)である:
【0093】
【表9】
【0094】
このやり方でアプリケーションを特定すれば、メッセージの文字長(最大で160文字)のために予約されているスペースを使わなくても良い。このタイプの識別を使えば、普通の移動局によって送信されたアプリケーションに関する情報を受信することも可能であるが、この場合には、ユーザは、そのメッセージに関して、この情報が移動局でプログラムされたものでなければ、それが特別のアプリケーションからの情報であることを知ることはできない。また、ユーザはこのタイプの識別子をメッセージに付け加えることはできないので、普通の移動局によってこのタイプのアプリケーションに関する情報を送出することはできない。当然に、普通の移動電話機は種々のアプリケーションをサポートしない。
【0095】
次に、端末、この場合には本発明の無線端末の実現と、アプリケーション関連情報を送信および受信するときのその動作と、を図10を参照してさらに詳しく説明する。
【0096】
図10は、本発明の端末の実現のブロック図であり、それはこの図では移動電話機等の無線による送信のための手段も有する装置として示されている。しかし、類似の実現をサービス・プロバイダの端末装置に使っても良いけれども、それは普通は直接無線周波数送信のための手段を有してなくて、図2に示されるような手段(例えば移動局)にネットワークを介して接続される(例えば、パソコンPCまたはサーバGTW)。端末は好適には移動電話機または通信機器であり、それは種々のアプリケーションを処理できるようにする回路とユーザインターフェースとを持っている。図10の端末1は、無線通信を使う通信を行うために、無線ユニットRU(この参照符号は図には付されていない)を備え、それは、普通の移動局とは区別される送信器ブランチ(transmitter branch)2(符号化、インターリーブ、暗号化、変調、および送信、を実現するブロックを備える)と、受信側ブランチ(receiving branch)3(受信、復調、解読、インターリーブ解除、および実行、のブロックを備える)と、を備えており、また無線通信を使う送信のために、受信されたメッセージと送信されるメッセージとを区別する双方向フィルター(duplex filter)4とアンテナ5とを備える。この端末は、その動作を制御する主制御回路6を有する。さらに、主制御回路6は、普通の移動局の機能の制御機能を実行するRUコントローラ7も有する。さらに、端末の主制御回路6は、端末のデータ処理ユニットの機能を実行すると共にアプリケーション関連情報を本発明に従ってショートメッセージとして送信する、ためのブロック8〜12を有する。従って、ブロック8〜12は、端末のデータ処理ユニットDUを形成するものであると言うことができる。無線ユニットRUの制御部および端末のデータ処理ユニットDUを主制御回路に統合する必要はなく、代わりにそれらを別々に実現することもできて、RU制御回路7を無線ユニットの側に置き、データ処理ユニットの側にはDUプロセッサ8を置くことができ、それは、無線ユニットとデータ処理ユニットとの間の通信を確立するためにRU制御回路と接続される。
【0097】
図9に例示されている実現では、第1のメモリ13は主制御回路6に結合されている。第1のメモリは例えばRAM等の揮発性メモリであって良く、これに主制御回路は使用中のデータを記憶しておく。さらに、端末は第2のメモリ14を有し、これは好適には固定記憶装置14であって、種々のサービスを実行すると共に種々のアプリケーションを動作させる端末のアプリケーション・プログラムと、端末の動作に不可欠の他のデータと、ユーザが永久的に記憶しておきたい他のデータと、が第2のメモリに記憶される。あるいは、端末に結合され、そこから主制御回路6に接続される外付けスマートカードのメモリにアプリケーション関連情報をオフラインで記憶しても良い。このタイプのスマートカードは、例えばGSM移動通信システムからSIMカード(Subscriber Identity Module:加入者識別モジュール)として知られており、それは普通は例えば電話番号を記憶させておくための記憶装置(storase)を持っている。この場合、スマートカードのメモリを単に更新することによって新しいアプリケーションを端末において更新することができる。
【0098】
アプリケーションを見るために、端末はディスプレイ15を有しており、データを入力するためにキーボードやその他の、例えばタッチ・ディスプレイ等の入力装置16を持っている。
【0099】
データ処理ユニットDUおよび無線ユニットRUが、機能に関して独立しているユニットとして実現される場合にも、その両方が、共通のあるいは別々のメモリ13、14とユーザインターフェースUIとを有するべきである。これらのユニット間の通信はDUプロセッサ8とRU制御回路7との接続によって確立され、それはこの関係では外付け制御インターフェースECIと呼ばれる。
【0100】
次に、アプリケーション関連情報を送信するときの、端末装置の実現と端末の動作とについて説明する。ユーザインターフェースUIによって、所要のアプリケーションが端末のディスプレイにもたらされ、その場合には入力装置からの16種類のコマンドに基づいて、制御回路7は、アプリケーション関連情報をプログラマブルに取り扱うアプリケーション17、18が記憶されているメモリ14から、これに記憶されている選択されたアプリケーションをディスプレイ15に取りだし、あるいは前述したように電気通信ネットワークからサービスを取り出す。サービスに関連するアプリケーションはDUプロセッサ8で処理されるが、これは、無線ユニットRUの動作を制御するRU制御回路7との交信を保つことによってアプリケーション関連情報の送信も制御する。アプリケーションは、図7に例示されているように、情報を含んでいる。その情報は1つあるいはそれより多いフィールドの中にあり、そのフィールドは(もし既に情報を含んでいるアプリケーションの記録がメモリから取り出されたならば)すでに満たされているか、あるいはそのデータ・フィールドは空であり、その場合にはユーザは入力装置16によってそのフィールドに情報を入力したり、あるいはそのフィールドの中の情報を修正したりすることができる。アプリケーションが所要の情報を含んでいて、ユーザが入力装置によってアプリケーション関連情報を送出するコマンドを入力すると、DUプロセッサ8は、そのアプリケーションに関する情報から記号の行を形成し、そのプロセッサは、その行の冒頭にアプリケーション識別子を置き(もしその識別子がアドレス・フィールドで表示されていなければ)、そしてその後に、例えば、改行文字で区切られた種々のフィールドに含まれている情報を、記号間にありえるのスペースも含む英数字文字で作り変えて、配置する。従って、DUプロセッサ8は、文字の処理のために、ワードプロセッサ・プログラムに類似する機能を備えており、それはプログラミングにより実現されてメモリ14に記憶されており、そこからDUプロセッサ8はそのプログラムを取りだして、そのプログラムに従って機能を実行する。DUプロセッサ8は、形成された文字の行をSMS送信コントローラ10へ転送し、そのコントローラは、そのメッセージにアドレス情報を、すなわち、宛先に関する情報を、ユーザが入力した情報に基づいて、あるいはそれを例えば前述したようにカレンダー・アプリケーションなどの別のアプリケーションから取りだして、付け加える。従って、この種のSMS送信コントローラは一種のビットおよび/または文字生成器である。カレンダーは好適には、DUプロセッサ8により使用されるメモリ14に記憶されるアプリケーション・プログラムとして実現される。したがって、2つの異なるアプリケーション17および18の間の通信はDUプロセッサによって確立され、このプロセッサは、例えば、1つのアプリケーションから取り出された時間情報に基づいて、他方のアプリケーションを開いたりそれに情報を入れたりする(例えば当該時間にカレンダーの中に)。
【0101】
アドレス情報がSMS送信コントローラ10で追加されているときには、そのメッセージはアウトボックス11へ転送され、これはそのメッセージを送出しようと試みるものであって、バッファを有しており、送信が失敗した場合にはその中に該メッセージが記憶される。送信が失敗したら、アウトボックス11はもう一度メッセージを送出しようと試みる。無線ユニットRUがメッセージを送出できる状態になっていることにDUコントローラ8が気づいたとき、そのメッセージはメッセージ転送動作回路12へ転送され、この回路は、妥当性情報(validity information)(これは、そのメッセージがどの方向に進むのか、すなわち、移動局からメッセージ・サービス・センターへ進むのか、あるいはその逆に進むのか、を示す)などの、当該移動通信システムに関連する情報をそのメッセージに付け加え、アドレス情報を処理して移動通信システムが必要とする書式に変換し、メッセージ・サービス・センターのアドレスとショートメッセージ識別子(SAPI)とをそのメッセージに付け加え、送信されるべき情報から例えば送信器2のためのディジタル信号を形成し、そのメッセージを無線ユニットRUの無線送信器ブランチ2に送出する。アプリケーション識別子がビットの形でアドレス・フィールドADDに置かれる場合には、動作回路12はそのメッセージに当該識別子を付け加える。送信器ブランチ2は、移動通信システムの仕様に従って信号を符号化し、自分が動作回路12から受信した信号に基づいて、送信されるべきフレームを作成し、これを送信器は無線通信を使ってショートメッセージ・サービス・センターSM−SCに送出し、そこから該フレームはさらに受信者に送出される(図1を参照)。送信器ブランチ2では、移動通信システムに応じてメッセージが処理される。すなわち、符号化、インターリーブ、暗号化、バースト形成、変調、および送信が行われる。
【0102】
次に、アプリケーション関連情報を受信するときの端末の実現および動作について説明する。端末がアプリケーションについての情報を含むショートメッセージを受信するとき、そのメッセージは始めに無線ユニットRUに到着する。その受信側ブランチ3で、受信、復調、解読、インターリーブ解除、および復号などの処理が移動通信システムに従ってそのメッセージに対して行われる。もし受信されたフレーム識別子(SAPI)が、そのメッセージがショートメッセージであることを示しているならば、それはデータ処理ユニットのインボックス9へ転送されるが、これは該メッセージを記憶しておくためのメモリであって良い。もし受信されたメッセージが普通のショートメッセージであれば、DUプロセッサ8は受信されたメッセージを伝える。それがアプリケーション関連情報であることを示す識別子をそのメッセージが有していれば、DUプロセッサ8は当該アプリケーション17、18を送り出して、受信されたメッセージからの情報を、受信されたメッセージのマーキングに従ってアプリケーションの中に置く。従って、ユーザ・メッセージ(例えばショートメッセージ)の受信は、受信されたアプリケーション関連情報としてユーザに表示される。
【0103】
本件は、本発明の実現および実施例を例示しながら提示している。本発明が前述の実施例の詳細には制限されないこと、そして本発明の特徴から逸脱せずに別の実施例で本発明を実現し得ることは当業者にとっては明白なことである。従って、提示した実施例は例示としてみなされ制限をするものではないと解されなければならない。従って、本発明を実現し利用する可能性は、特許請求項によってのみ限定されるに過ぎない。それに相応して、クレームにより決まる本発明のいろいろな実現のオプションは、その同等の実現も含めて、本発明の範囲に属する。
【0104】
付録1
【0105】
【表10】
【0106】
【表11】
【図面の簡単な説明】
【0107】
【図1】一方の移動局からもう一方の移動局へのショートメッセージの流れを例示する。
【図2】ショートメッセージ・サービス・センターへの移動局システムの接続を例示する。
【図3】普通の移動電話機のユーザインターフェースを例示する。
【図4】送信時のメッセージのフレームへのセグメント化を例示する。
【図5】受信時のメッセージの復元を例示する。
【図6】ショートメッセージのフレームを例示する。
【図7】本発明の1つのアプリケーションを例示する。
【図8】別のアプリケーションを例示する。
【図9】システムの見地からの、図8に例示されているアプリケーション関連情報の送信を例示する。
【図10】本発明の端末の実現を例示する。
【図11】本発明の端末における1アプリケーションの機能を順に例示する。
【図12】本発明の端末における1アプリケーションの機能を順に例示する。
【符号の説明】
【0108】
1 端末
2 送信器ブランチ
3 受信側ブランチ
4 双方向フィルター
5 アンテナ
6 主制御回路
7 RU制御回路
8 DUプロセッサ
9 インボックス
10 SMS送信コントローラ
11 アウトボックス
12 メッセージ転送動作回路
13 第1のメモリ
14 第2のメモリ
15 ディスプレイ
16 入力装置
17 アプリケーション
18 アプリケーション
【技術分野】
【0001】
本発明は、通信ネットワーク用の端末に関し、この端末は、複数のアプリケーションを支援することのできるものであって、ユーザ・メッセージを通信するための手段を有する。本発明は、また、送信端末と、複数のアプリケーションをサポートすることのできる受信端末とを備える通信ネットワークにおけるシステムにも関し、この両方の端末がユーザ・メッセージを通信する手段を有する。
【背景技術】
【0002】
現在、普通の移動局機能の他に、例えばカレンダーの維持、ファックス・メッセージの送出、および電子メールなどを可能にするデータ処理機能も有する通信機器(comunicator)が開発されつつある。それらの通信機器は、オーガナイザ形の装置のように異なる数種類のアプリケーションを有しあるいは支援することができる。例えばテキスト・メッセージなどをタイプしやすい在来の英数字キーボードに類似するキーボードを有するユーザインターフェースを備えた1種の通信機器が開示されている(例えば、特許文献1)。この公報では、キーボードはタッチ・ディスプレイによって実現されている。しかし、在来の移動電話機が発展するに従って、特にユーザインターフェースおよびディスプレイがさらに発展するに従って、在来の移動電話機のような装置によって、もっと進歩した動作が可能になろう。
【0003】
【特許文献1】米国特許第5422656号明細書
【特許文献2】特開平7−236179号公報
【特許文献3】特開平7−202931号公報
【特許文献4】特開平7−84858号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
公報WO94/23394は、走査して例えば無線通信を使って類似の通信機器に送ることのできる種々のタイプのグリーティングカードを有する通信機器のための電子メール・サーバを備えた電子グリーティングカード通信システムを提示している。このシステムの欠点は、該当するグリーティングカードを類似の通信機器にしか送れないことである。従って、送出者は受信者がグリーティングカード通信システムをサポートする通信機器を持っているか否か知らなければならない。さらに、システムを実現するためには、種々のタイプのグリーティングカードを記憶しておくためのオフライン電子メール・サーバを当該サービスのためにネットワークに個別に接続しなければならない。このシステムは普通の無線通信でグリーティングカードを送信するので、通信機器の電話回線が送信中は話中になるということが別の欠点である。この公報に提示されている通信機器によって、手書きテキストを有するグラフィック・イメージを送信することもできる。その様なイメージあるいは単なる手書きメッセージの送信は、情報量が大きいために極めて低速である。公報WO94/23394は、1つのアプリケーションあるいはサービス、すなわちグリーティングカード・アプリケーション、に関する情報の送出について論じているだけである。通信機器類似の装置が異なる数個のアプリケーションを有するために、種々のアプリケーションに関連する情報をどの様に送出したり処理したりするかという問題が生じる。このWO公報では、特定のグリーティングカード・サービスのために別々の電子メール・サーバが配置されている。しかし、通信機器の各アプリケーションのために別々の電子メール・サーバを設けるのは、どちらかというと複雑で高価な解決策となろう。さらに、例えば通信機器などの端末において種々のサービスに関連する情報をどの様に処理するかという問題に直面する結果となる。
【課題を解決するための手段】
【0005】
本発明は、通信ネットワーク用の端末に関し、この端末は複数のアプリケーションを支援することができて、ユーザ・メッセージを通信するための手段を持っており、その端末は、そのアプリケーションのうちの1つと関連するデータおよびヘッダを有するユーザ・メッセージを受信するための手段と、このヘッダに従ってそれぞれのアプリケーションへ向けてデータをアドレス指定するための手段とを有する。従って端末は、複数の異なるアプリケーションを後の段階で端末に組み込むことができるようになっている。アプリケーションを後で追加することは、他の装置への無線での直接接触によって実行することができる。1つのユーザ・メッセージはヘッダが指示する1つのアプリケーションに関連するデータを含むことができ、あるいは、例えば特定のアプリケーションを指示するヘッダの後にそのアプリケーションに関連するデータが続くこととなるように、ユーザ・メッセージは種々のヘッダにより指示される数個のアプリケーションに関連するデータを含むことができる。
【0006】
ユーザ・メッセージは、限られた量の情報を含んでいるので、素早く送信することができる。ユーザ・メッセージの1つのタイプはいわゆるショートメッセージである。本発明は、ショートメッセージのユーザにより実施されるのに特に適している。規格IS−136に準拠する移動電話システムは、類似のショートメッセージを送信するためにいわゆるRデータ・フィールドを使用する。SMS類似のメッセージも送ることのできるGSMシステムで知られている他の種類のユーザ・メッセージ送信機能はUSSD(Unstructured Supplementary Service Data : 無構造補助サービス・データ)であり、これはGSM仕様において、例えば次の文書、TS GSM 02.04、TS GSM 02.30、TS GSM 02.90、TS GSM 03.38、TS GSM 03.40、などで、詳しく定義されている。SOC(Service Operator Code : サービス・オペレータ・コード)と呼ばれる類似のメッセージ送信形式(messaging form)が規格IS−136に準拠する移動電話システムに存在する。SMS、Rデータ、USSDおよびSOCのような通信形式を本書ではユーザ・メッセージ送信機能と称し、その様なメッセージをユーザだけでなくてオペレータが送信することもできるが、メッセージをユーザ・メッセージと称することにする。この種の通信の利点は、音声通話チャネルを全く保留しないか、あるいは少なくとも連続的には保留しないことである。
【0007】
パケット交換通信にも同様の利点がある。移動通信ネットワークにおいてパケット交換情報を中継するためのPRMA(Packet Reservation Multiple Access:パケット予約多元接続)に基づくプロトコルが知られている。これは「パケット無線(Packet Radio)」とも呼ばれる。PRMAは、パケット書式のディジタル音声あるいはデータを多重化して時分割搬送波にするための技術である。パケット無線サービス、すなわちGSM移動無線システムのために開発中のGSM GPRS(General Packet Radio Service:一般パケット無線サービス)、を例として取り上げる。GPRSは、GSM加入者にパケット無線サービスを提供する新しいGSMサービスである。GPRSは、送信するべきものが何かあるときだけ無線資源を予約するものであり、従って同じ資源を全ての移動局が自分たちの必要に応じて共有できるようにするものである。従って、短時間だけ通信チャネルを保留するパケット無線通信をユーザ・メッセージ送信のために利用することができる。
【0008】
本発明は如何なるユーザ・メッセージをも利用できることであるけれども、以下の記述では主としてショートメッセージを実例として参照する。高速で送出するということに加えて、音声チャネルを保留しないなどの、ショートメッセージ・サービスの利点を利用することができる。アプリケーション関連情報を端末装置のメモリ(固定記憶装置)に前もって記憶させておくこともできるが、ユーザは端末の手段によってサーバと連絡を取って端末のメモリ(キャッシュ・メモリ)にアプリケーション関連情報を記憶させることもできる。アプリケーションに応じて、ユーザはアプリケーションでユーザ入力を入力したり情報を修正したりすることができる。他のアプリケーションでは、アプリケーションに関連する情報をサービス・プロバイダにより送出することができ、その情報は、ユーザが修正できなくて、サービス・プロバイダに修正を依頼できるに過ぎないような情報であっても良い。アプリケーションで容易にプリントされる情報も送信することができる。受信側の端末がそのショートメッセージを普通のショートメッセージではなくて特定のアプリケーションに関連するアプリケーション向け情報を含むショートメッセージであると識別できるように、アプリケーションの種類の識別子またはヘッダを通信メッセージに付け加えるのが好都合である。その識別子は、ショートメッセージのアドレス・フィールドまたは制御フィールド中のコードであっても良いし、あるいはショートメッセージのメッセージ部分中のコードであっても良い。移動局システムに既に存在するショートメッセージ・サービスを利用してアプリケーションに関する情報を送出できることが分かっているので、例えば、公報WO94/23394に提示されているシステムなどでアプリケーション関連情報を送るためにオフライン・サーバを設定する必要が無いという利点がある。唯一のサーバすなわちSMSサーバ(ショートメッセージ・サービス・センターSM−SC)を使ってどの様なアプリケーションに関連する情報でも送出したり回送したりできるので、各アプリケーションのために別々のサーバを持つ必要はないということが特に有利である。SMSサーバはどんなメッセージでも回送し、端末はメッセージ中のヘッダまたは識別子に従って正しいアプリケーションへ向けて情報をアドレス指定する。また、ショートメッセージを回路結合接続(circuit-coupled connection)と同時に送れるので、例えば同時に入接続呼がある場合などに、アプリケーション関連情報の送出は端末の通信回線を話中にしない。GSMネットワークのようなネットワークは幾つかのオペレータによって維持され、普通は各オペレータが自分のSMSサーバを少なくとも1つ持っている。この場合、当然に、どのSMSサーバも、あるいは数個のサーバも、本発明のために使用することができる。
【0009】
本発明は、第1の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの1つについての情報と、そのアプリケーションのうちの1つに関連するヘッダとを有するショートメッセージを受信するための手段と、そのヘッダに従ってそのアプリケーションのうちの1つに向けて情報をアドレス指定するための手段とを備えることを特徴とする。
【0010】
本発明は、第2の面においては、情報を表示して処理するための複数のアプリケーションをサポートすることができて、記号の形の情報を有するショートメッセージを伝達するための無線通信手段を有する移動局を提供するものであり、この移動局は、そのアプリケーションのうちの1つに関連する情報を処理して記号に変換し、その処理済み情報をショートメッセージで送出するための手段と、そのショートメッセージにヘッダを付け加えるための手段とを有し、そのヘッダは、その情報が関連するアプリケーションを表示するものであることを特徴とする。
【発明の効果】
【0011】
本発明の端末は、アプリケーション関連情報を簡単に送信および受信する方法を提供する。また本発明は、例えば前述のメニュー・アプリケーションを使って大量のサービスへのアクセスを有することができる端末を提供する。特にショートメッセージを通信書式として使用することによって宛先の到着が保証され、ユーザ・メッセージで一般に最適の電流消費が達成される。ユーザ・メッセージとの関連での承認トークンの使用は、ユーザ・メッセージにセキュリティを加える新しい方法を説明する。
【発明を実施するための最良の形態】
【0012】
次に添付図面と付録とを参照して本発明について詳しく説明する。
【0013】
付録1は、図8に例示されている、記号で表されたアプリケーション関連情報を例示する。
【0014】
次に、ユーザ・メッセージ機能の1つの形式としてのショートメッセージ・サービスを実例として取り上げて、本発明を詳しく説明する。本発明を理解するために、始めに図1〜5を参照してショートメッセージに関連する従来技術を解説し、図7〜12および付録1を参照して本発明の実施例について説明する。
【0015】
GSMシステムのようなディジタル移動通信システムでは、いわゆるショートメッセージを送出することができる。GSMシステムでは、これはSMS(Short Message Service : ショートメッセージ・サービス)として知られている。この様に、電話コールおよびデータ転送の他に、GSMシステムはショートメッセージ・サービスの形式でページング・システムに類似するサービスも提供している。しかし、GSMシステムから知られているショートメッセージ・サービスは、普通のページング・システムより非常に進歩している。移動局により、テキスト・メッセージを他の移動局とやりとりすることができる。GSMシステムのショートメッセージ・サービスの1つの利点は、また、例えば通話中に、普通の回線結合通信が開始されているときに同時にショートメッセージを送出しあるいは受信することができることである。従って、ショートメッセージを送出しても、たとえ入接続呼がある場合でも移動局は話中状態に保たれない。
【0016】
電話コールと比べたときのショートメッセージの利点は、ショートメッセージが送信されつつあるときには受信器と連絡を取れないにもかかわらずショートメッセージを受信器に送出することができるということである。これは、第1の移動局から第2の移動局へのショートメッセージの送信を図1に示されているように2つの部分に分割することによって実現される。すなわち送信側移動局MS1からSM−SC(ショートメッセージ・サービス・センター)へ送出され、ここにショートメッセージが記憶されて、さらに実際の目的地すなわち受信側移動局MS2へ、連絡が取れ次第直ちに送出される。図2には、移動局システムへのショートメッセージ・サービス・センターSM−SCの接続が詳しく例示されている。以下に、従来技術について、公知である種々のインターフェース間でのショートメッセージの送信および流れについて図1〜5を参照して説明する。
【0017】
移動局システムの構造と、ショートメッセージを送信するための接続とが図2に例示されている。移動局MSは無線通信により基地局BTSに接続される。基地局BTSは、さらにいわゆるAbisインターフェースを通して基地局コントローラBSCに接続され、この基地局コントローラは数個の基地局を制御管理する。数個の基地局BTS(通常、数十個の基地局)と、これらの基地局を制御する単一の基地局コントローラBSCとで形成されるエンティティは、基地局システムBSSと呼ばれている。特に、基地局コントローラBSCは、無線通信チャネルとハンドオーバーとを管理する。一方、基地局コントローラBSCは、いわゆるAインターフェースを通して、移動局からの接続の形成および移動局への接続の形成の両方を調整する移動サービス交換センターMSCに接続される。移動サービス交換センターMSCを通して移動通信ネットワークの外部との接続がなされる。前述のショートメッセージ・サービス・センターSM−SCは移動サービス交換センターMSCに結合される。
【0018】
ユーザは、移動局MS1によってショートメッセージを送りたいときには(図1)、送信されるべきメッセージを(移動局のユーザインターフェースを使って)書き込み、そのメッセージが送られることになる移動局MS2の電話番号すなわち移動局MS2の識別子を与える。さらに、移動局は、連絡情報すなわちショートメッセージ・サービス・センターSM−SCの電話番号を有するべきである。普通は、これは移動局のメモリに記憶されており、その場合にはショートメッセージの送信に関する電話番号を個別に入力する必要はない。ショートメッセージを送るときには、メッセージは移動局MSから基地局BTSに行き、そこから基地局コントローラBSCおよび移動サービス交換センターMSCを介して、さらにショートメッセージ・サービス・センターSM−SCに行く。ショートメッセージはショートメッセージ・サービス・センターSM−SCに記憶され、ここからショートメッセージはさらに受信側移動局MS2へ送出され、その場合にはメッセージのルートは送信時と同じであるが方向が逆である。移動局MS2がそのショートメッセージを受信したか否かがショートメッセージ・サービス・センターSM−SCに知らされる。従って、これは、もし何らかの理由で移動局MS2がそのショートメッセージを受け取っていなければ、それを送り直すことができる。
【0019】
さらに、ショートメッセージをパソコンPCから送出することもできる。この場合には、移動サービス交換センターMSCは、例えばインターネットとの接続を有するサーバGTW(ゲートウェイ)との接続を有する。従って、インターネットとの接続を有する(あるいは破線で図示されているようにサーバGTWと直接接続している)コンピュータPCはインターネットからWWW(ワールドワイドウェブ)ページを引き出すことができ、それは物理的には例えばサーバGTWから見つけることができる。随意的に、サービス・プロバイダまたはオペレータは、ショートメッセージあるいはその他のユーザ・メッセージを送出するために、移動サービス交換センターMSCとの接続を有する独立のサーバGTWを有していても良い。ショートメッセージを送出するためにそのようなWWWページを使うときには、ユーザは受信側端末MS2の接続情報(例えば電話番号)と送出されるべきメッセージとを入力し、そのメッセージはインターネットとサーバGTWとを介して移動サービス交換センターMSCへ転送され、さらにショートメッセージ・サービス・センターSM−SCへ送られ、そこからそのメッセージは移動通信網を介して受信側端末MS2へ送られる。
【0020】
GSMシステムのショートメッセージ・サービスSMSによって、最大で160文字の長さのメッセージを一度に送ることができる。文字は7ビットのASCII(American National Standard Code for Information Interchange : 情報交換用米国標準コード)文字であり、従って、メッセージの最大長さはビット単位で1,120ビット、すなわち140バイトである。図3に例示されているような普通の移動局は、小型のディスプレイと進歩したキーボードとを持っており、これにより短いメッセージを書くことができる、すなわち種々の英数字を入力することができる。受信されたメッセージは、図3に例示されているように英数字を表示できる移動局のディスプレイで表示される。
【0021】
用知の通り、GSMシステムでは通信メッセージはフレームに分割される。送信されるべきメッセージの長さが、フレームFRの許容最大長さを上回るときには、図4に例示されているようにメッセージMを幾つかの部分M1〜M4に分割して数個のフレームFR1〜FR4で送出しなければならない。受信時には、移動局は、図5に示されているように、数個のフレームFR1〜FR4に分割されているメッセージMを復元する。無線インターフェース(図2)では、フレームの最大長さは普通は168または184ビットであるので、最大長さが1、120ビットであるショートメッセージを数個のフレームにセグメント化しなければならない。図6は、普通は3つのフィールドに分割されている、無線インターフェースで送信されるフレームであるいわゆるLAPDmフレーム(Link Access Protocol for the Dm channel :Dmチャネル用リンク・アクセス・プロトコル)を例示している。第1フィールドはアドレス・フィールドADDであり、これは数バイトで表示されるメッセージの宛先のアドレス(すなわち、受信側移動局の識別子)である。GSMシステムでは、対応するLAPDmフレーム内でシグナリングメッセージも送信される。無線通信では、互いに無関係の2つのメッセージ、すなわちシグナリングメッセージとショートメッセージと、のフローが同時に存在できる。この2つの異なるフローは、アドレス・フィールドADDに付加されるサービス・アクセス・ポイント識別子SAPIによって分離される。その値は、信号を示す3であるか、あるいはショートメッセージを示す0である。第2フィールドは制御フィールドCTRLであり、これは送信しているフレーム番号N(S)と受信しているフレーム番号N(F)とを含んでいる。第3フィールドは実際の情報あるいはデータを含むデータ・フィールドINFOであり、これは最大で168ビットの情報すなわち実際のショートメッセージの内容を含んでいる。
【0022】
本発明では、ショートメッセージを例として取り上げると、各アプリケーション関連情報の送信は、特別のコードすなわち識別子によって識別され、それは受信側端末が受信したメッセージを処理して、受信したデータを含む指定されたアプリケーションに直接入れることを可能にするものである。その識別子は好適にはASCII文字を使用してショートメッセージ送信フレームの情報フィールド、すなわち実際のショートメッセージを文字の形で含むフィールドINFO(図6)で実現される。代わりに、ショートメッセージを送出するためにデータはいずれにせよビットに変換されるので、識別子は他の何らかの文字またはビット等のストリング・コード(string code)の形であっても良い。アプリケーションに関連する情報はショートメッセージで送信されるので、そのアプリケーション・サービスをサポートしないがショートメッセージを送信しおよび/または受信することのできる普通の移動局で、そのショートメッセージを受信することもできる。アプリケーション識別子をフィールドINFOに置けば、このタイプのアプリケーション・サービスをサポートしないけれどもショートメッセージを送信しおよび/または受信することのできる普通の移動局において、そのアプリケーション識別子が端末、例えば通信機器のユーザに表示され、従ってユーザは普通のショートメッセージではなくて特定のアプリケーションに関連する情報を受信したということに気づくという利点もある。また、このタイプの普通の移動局のユーザは、始めにメッセージに当該アプリケーションの識別子を記号で書き、そして正しく分割された情報の残りを書くことによって、前述したメッセージ等のメッセージを送信することもできる。本発明に従って、端末装置によってこの通信メッセージを受信すれば、完全に受信されたアプリケーション関連情報記録が得られる。
【0023】
代わりに、アプリケーション識別子はショートメッセージのアドレスまたは情報フィールド(図6を参照)において、特定のビット・コードとして形成される。さらに、この場合、普通の移動局は特定のアプリケーションに関連する送信された情報を受信することができるが、ユーザは、そのメッセージに関して、受信したメッセージが特定のアプリケーションのための情報であるということを知ることはできない。この場合、特定のコマンドを入力すると、移動局が前述のビット・コードを付加することとなるように移動局を改造しなければ、その普通の移動局はアプリケーション識別子を知らせることはできないので、この種のアプリケーションのための情報を普通の移動局で送信することはできない。
【0024】
図7は、端末装置に予め記憶されるアプリケーション記録を有するアプリケーションの例を例示しており、それにユーザ入力された情報(アプリケーション記録)は、ショートメッセージとして別の端末に送出されることができる。このアプリケーションのタイプは“ビジネス・カード”と呼ばれる。このアプリケーションは、ビジネス・カードの内容を走らせるものであって、氏名、職名、会社名、連絡情報、などの情報を含んでいる。各情報がそれ自身のフィールドに置かれても良く、あるいはアプリケーションがフィールドを1つだけ有して、その中に全ての情報が置かれても良い。図7は、アプリケーションに関する情報の、ショートメッセージとしての送信も示している。この場合、アプリケーションのタイプの識別子は例えば図に例示されるように“BC”または“Business Card ”である。本発明の端末は、このアプリケーション識別子を(例えば文字あるいはその他の形で)始めに送信されるショートメッセージの情報フィールドの冒頭に付け加える。種々のフィールドの内容は自動的に改行文字で終わる。この文字に基づいて、受信側の端末は、受信した情報をアプリケーションの対応するフィールドに分割することができる。このタイプのメッセージが普通の移動局からショートメッセージとして送信されるのであれば、ユーザは、そのメッセージの冒頭にアプリケーション識別子、すなわち、図7の場合には「Business Card 」とを書き、その後に改行文字[cr]を書き、その後にアプリケーションに関する情報を(アプリケーション仕様に応じて)次々にあるいはフィールド毎に、すなわち始めに氏名フィールドを、次に改行文字を書く、等の手続きをする。受信した「Business Card 」を端末のメモリに記憶することができ、従ってそれにビジネス・カードを電子形式で記憶して、ビジネス・カード・アプリケーションでメモリからそれらを検索してみることができる。ビジネス・カード・アプリケーションの情報は、もちろん、装置に依存して変わる。或る端末では、それは、例えば、ショート・ダイヤル・アプリケーションとして使用することのできる氏名および電話番号だけを意味する。従って、ショート・ダイヤル・アプリケーションの内容を更新するために本発明を利用することができる。このようにして、ユーザは、内容をサービス・センターに送って記憶してもらうことによってショート・ダイヤル・アプリケーションの内容のバックアップを作ることができる。もし端末(例えば移動電話機)が後に紛失したり盗まれたりあるいは壊れたりして、ユーザが新しい端末を取得しなければならないことになっても、ユーザは、端末を起動することに加えて、ショート・ダイヤル・アプリケーションの内容全部をその端末にダウンロードする(引き込む)ことができる。もちろん、同じ解決策を端末のどのアプリケーションの内容にも使用することができる。ここで、他のいくつかのアプリケーションについて説明する。
【0025】
以下では、例として、他のタイプのアプリケーションについて論議する。それらのアプリケーションを端末に前もって記憶しても良く、あるいは後の段階で(プログラミングにより)端末に組み込んでも良い。
【0026】
「コール・ミー・バック(Call Me Back、折り返し電話をかけてください)」というアプリケーションは、人の氏名、電話番号、アドレス等と、その人が折り返し電話をするべきであるというメッセージとを含むことができる。この情報は、別個のフィールドに分割されても良く、あるいは、前述のように同じフィールドに置かれても良い。折り返し電話せよという前述のメッセージを「コール・ミー・バック」アプリケーションに密接に組み合わせても良く、および/または普通の移動局のディスプレイでも表示される(文章としての)“コール・ミー・バック”を識別子として書いても良く、その場合にはそのメッセージを受け取った当該移動局のユーザは、それが折り返し電話をすることを要求することであることを知ることができる。「コール・ミー・バック」アプリケーション関連情報の送信を出接続呼に結びつけて、もし宛先の端末が応答しなければ送信側のすなわち呼を発する側の端末がユーザ(発呼者)に「コール・ミー・バック」通知子を送出すべきか否か尋ねるようにしても良く、その場合には、そのユーザの応答が肯定であれば、それは予めアプリケーション・データ・フィールドに入力されている発呼者の電話番号(それは例えば自分のSIMカード、加入者識別モジュールからアクセスできる)で当該アプリケーションをディスプレイ上で走らせる。ユーザは、「コール・ミー・バック」アプリケーションで、情報の残りを入力し、ディスプレイ上でそれを修正することができる。アプリケーション関連情報がショートメッセージとして送出されるときには、端末は受信者の電話番号をそのメッセージの宛先として自動的に提供し、それを端末は未応答のままになっている呼についての情報から選び出すことができる。
【0027】
アプリケーション「Meeting Proposal、会合申し込み」の識別子は「Meeting Proposal」であって良く、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含むことができる。もし、端末に、電子カレンダー・アプリケーションもあるならば、このタイプのアプリケーション(会合申し込み)に関連する情報の送信に対する応答として、当該時間における会合の予約をカレンダーに設けるように、当該アプリケーション関連情報の送信をカレンダー・アプリケーションの動作と結びつけることができる。この特定のアプリケーションは、好適には、会合の時間をアプリケーションから選び出して、会合の場所および主題等の、そのアプリケーションに関する他の情報を招集者の氏名とともにカレンダーの当該時間の箇所に入力する。それに相応して、この種のアプリケーション関連情報を受け取ったときには、端末は自動的に当該時間について既に合意がなされているかも知れないものについての陳述を(もしカレンダーに入力されているならば)カレンダーから探す。従って、受信者は、会合申し込みに「イエス」と答えるか「ノー」と答えるか、素早く決めることができる。その回答を送出するとき、端末はアプリケーション「会合申し込み回答」を確立するが、その識別子は例えば「Meeting Proposal Answer 」であり、このアプリケーションの情報は、受信者の氏名、会合の時間および場所、主題、回答(イエス/ノー)、およびコメントを含むことができる。この場合、受信者、すなわち会合申し込みの送信者、の端末のカレンダー・アプリケーションは、カレンダーに設けられている予約を確認するかあるいは取り消すように調整される。
【0028】
さらに、「会合申し込み」アプリケーションの続きとして、端末にアプリケーション「会合確認」があっても良く、その識別子は例えば「Meeting Confirmation」であり、このアプリケーションの情報は、招集者の氏名、会合の時間および場所、およびその主題を含んでもよい。端末は、好適には、会合申し込みに「イエス」と回答した人たち全員にこのアプリケーション関連情報を自動的に送出するように申し出る。この場合、このアプリケーションに関連する情報を受信した移動局または通信機器は、カレンダーの中の当該予約を確認する。
【0029】
それに相応して、「会合申し込み」アプリケーションと同じ方法で、例えばアプリケーション「空き時間問い合わせ(Free Time Query)」などの、他の類似のアプリケーションを端末に設けることができ、その識別子は例えば「Free Time Query 」であり、このアプリケーションの情報は、送信者の氏名、時間、場所、および主題を含んでもよく、それはユーザが自由に書き込むことのできるものであって、例えばテニス、ディナーなどである。
【0030】
端末は、好適には、この関係では送信および受信の両方で、会合申し込みアプリケーションの場合と対応的に機能する。すなわち、端末は、カレンダーに予約を記入し、別のアプリケーションによって問い合わせに回答できるようにし、さらに、受け入れられるという確認あるいは取り消しをカレンダーに記入する。
【0031】
アプリケーション「サービスDTMFコマンド」により、例えば、ネットワークのオペレータから提供されるサービスを利用するためにそのオペレータから情報を受け取ることができる。アプリケーション識別子は「Service DTMF Commands 」であって良く、それは送信者の氏名、DTMFコマンド、および説明フィールドを持つことができる。コマンドは、例えば、パスワード、ユーザ識別子、あるいはその他の、オペレータから提供されるサービスに関連する何らかのものである。ユーザは、提供されるサービスを利用するときに、例えばパスワード等の、受信したコマンドを使用することができ、その場合には当該アプリケーション(またはそのアプリケーションの中の情報)からパスワードを直接得ることができるので、ユーザはキーボードを通してパスワードを入力しなくてもよい。ネットワークのオペレータから情報を受信することのできる他のアプリケーションは、端末においてアプリケーションを使用する前に何らかの設定を必要とするアプリケーションである。例としては「インターネット・アクセスポイント」アプリケーションであり、これは端末が例えばWWWブラウザを使用するために必要な情報を含む。その情報は、プロバイダの名称、電話番号、モデム初期設定情報、サーバ情報、IPアドレス(Internet Protocol :インターネット・プロトコル)であってもよい。何らかの設定を必要とするアプリケーションの別の例は、ファックス・ボックス・アプリケーションである。ファックス・ボックスは、例えばサーバで実現されるサービスであり、これは特定のユーザ宛の全てのファックスを受信する。ユーザはそのファックスをファックス・ボックスから回収することができる。ファックスを回収するために、端末はサーバ宛の連絡情報を有する必要がある。端末がファックス・ボックスに宛てられた新しいファックスを受信したときに、受信したファックスのユーザ・メッセージで端末が通知を受信するが、そのユーザ・メッセージがさらにUID情報(Unique Identifier :固有識別番号)すなわちファックス・ボックス・サーバ宛の連絡情報と、ファックスのファイル名および所要のパスワード等の他の所要の情報とも含むこととなるように、それを実現することができる。ファックス・ボックス・アプリケーションは、マニュアルで、すなわちユーザにより実行されて機能しても良く、あるいは、ユーザ通知メッセージに含まれている識別情報に従って受信されたファックスを自動的に回収するために端末がファックス・ボックス・サーバと連絡を取るように、そのアプリケーションが自動的に機能し得るようになっていても良い。ファックスを回収するためのファックス・コールとして連絡を取ることができる。随意的に、サーバが後に受信したファックスをファックス・コールを介して端末に送出するために端末と連絡を取ることができるように、その連絡は、識別情報をサーバに端末のファックス接続番号と共に送出するユーザ・メッセージであっても良い。
【0032】
本発明を使用する別の環境には、移動局に類似した装置を端末として使用するインテリジェント交通システムに関する解決策がある。本発明の端末は、その場合、種々の交通関連アプリケーションを有する。例としては「位置(Position)」アプリケーションであり、これで位置要求および応答を本発明に従ってユーザ・メッセージで送出/受信することができる。位置を確定するための種々の解決策がある。アプリケーション「位置」は、興味ある特定のアドレスまたは地点についての位置情報と、対応する位置についての記述、送信の理由あるいはモードを記述したフラグ、および、応答メッセージの場合には参照番号を含むことができる。受信した情報を対応するフィールドに分割した後、受信側端末は、受信した「位置」アプリケーション記録をローカルメモリに記憶する。端末は、自分自身の位置あるいは記憶されている位置情報をユーザ・メッセージで他の端末装置またはサーバに送ることもできる。これを例えば緊急事態の場合には自動的に実行することもできる。緊急事態のために、端末は独立の“緊急事態表示”あるいは“パニック表示”アプリケーションを有することができ、このアプリケーションは、自分の車両および自分の位置並びに緊急事態に必要なその他の関連情報についての送信者に関する情報を自動的に包含することができ、これを送信者はこのアプリケーションで修正することができる。
【0033】
交通目的の付加したアプリケーションは、例えば、「旅行要求(Trip Request)」および「旅行応答(Trip Responsel)」アプリケーションであり(あるいは一般的に「旅(Travel)」アプリケーション)、これは旅行支援アプリケーションである。このアプリケーションで、端末は、好適には出発地点としての端末の実際の位置と、その旅行の目的地として記憶されている位置アプリケーション記録から選択された位置と、を含む旅行要求を送り出すことができる。旅行要求に対する応答として、端末は「旅行応答」メッセージを受信することができ、それは、方向転換指示や公共輸送機関の接続などの、その旅行についての指示を含むことができる。
【0034】
また端末は、この端末のオリジナルの通し番号、製造月、修理月、および改造がなされた月(例えばソフトウェアの改造)などの、サービス目的のために重要であるかも知れない情報を伴うサービス・アプリケーションを有しても良い。このサービス・アプリケーション中の情報は、ユーザ・メッセージで端末から例えばオペレータまたはサービス・ステーションに送られることができる。
【0035】
実現可能な別のアプリケーションは、電話帳サービスを管理するサービス・プロバイダに電話番号問い合わせを送出するための電話帳アプリケーションである。その問い合わせは、氏名、在住地の市名、地上線/移動電話番号、などの情報を含むことができる。応答としてサービス・プロバイダは、電話番号と例えば元はユーザが送出した情報とを有するユーザ・メッセージを送出する。
【0036】
付加的なサービスおよびアプリケーションを有する多様な可能性を端末に与える別のタイプアプリケーションは「メニュー(Menu)」アプリケーションであり、これに端末は受信したユーザ・メッセージに従って端末でメニューを作ることのできるアプリケーションを含む。そのメニューは、好適には、該端末でいつまでも使用することのできるメニューを作るために、図10のメモリ14等の固定記憶装置に記憶される。ユーザ・メッセージは、それに応じて「メニュー」アプリケーションが端末のメニューを作ったり更新したりできるような情報を含む。これにより、無線経由で、すなわちユーザがサービス場所へ端末を持ち込む必要なく、オペレータがユーザの端末で更新することのできる非常に多様なサービスへのアクセスが可能となる。オペレータには、その加入者が使用するハンドセットを個人専用のものとするための非常に強力なツールが与えられることになる。このツールは、必要ならば加入者毎に異なることのあるハンドセット(handset)の、オペレータ固有のメニュー構造である。そのメニュー構造はユーザによる支援無しで無線経由で動的に更新されることができる。創作されたり更新されたりして、メニュー中のコマンドを起動することによりアクセスすることのできる付加的サービスをユーザに提供することのできるメニューの実例を下に挙げる。本来は、端末は何らかの基本メニューを包含することもできるが、メニューを全く包含していなくても良い。下記の実例において示されている全てのメニューおよびサブメニューは、メニュー・アプリケーションに関連するユーザ・メッセージを送出することによって作ることのできるものである。
【0037】
【表1】
【0038】
したがって、メニューあるいは各メニューは上記の様にメインメニューとサブメニューとを含むことができ、ここではメインメニューすなわちオペレータ・サービス、地域サービス、および個人向けサービスはサブメニューを含む。それらのサブメニューはさらにサブメニューに分割されても良く、例えばサブメニュー呼び出し音ダウンロード(Download Ringing Tones)は、呼び出し音のメロディ(Rock around the clock 、Those were the days 、Smoke on the water) によるサブメニューに分かれていても良く、特定のサブメニューを選択してそれをコマンドとして起動することによって、それらを呼び出し音として選ぶことができる。そのコマンドは本発明に従ってユーザ・メッセージとしてサービス・プロバイダに送出され、そのユーザ・メッセージに対する応答としてオペレータはユーザ・メッセージに符号化された呼び出し音を送出することができ、それは端末のおよび呼び出し音メモリに記憶されることができる。
【0039】
サブメニューでなされる選択は多様な動作を引き起こす。サブメニューのエントリーにURL(Uniform Resource Locater)情報を付随させることができ、これを使ってインターネットから情報を引き出したりe−メールをインターネットの受取人に送出したりすることができる。さらに、それらのエントリーから補足的サービスを直接開始させることもできる。特別の形式のURLを使って補足的サービス関連情報またはコールまたはユーザ・メッセージを伝えることができる。動作がネットワーク・エンティティによって情報を端末に送出させることもあり、例えば前述したように呼び出し音の選択とその後のダウンロードとを可能にする。その場合、オペレータ・サービス・メニューはURL情報に基づいてインターネットから情報を引き出させることができ、e−メール・メッセージを受取人に送出させることができ、オペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを開始させることができる。地域サービス・メニューは、特定地域向けのサービスをサポートする。一定地域で一定時間に利用することのできる「変わりやすい」サービスからメニュが生成さられる。ユーザはそれらのサービスをあさって、興味のあるものを選び出すことができる。この便宜は、ある地域を旅行している電話ユーザ宛てに情報(あるいはサービスの広告)を送るための簡単な手段を提供する。例えば、電話ユーザがダラス地域で州間高速自動車道(Interstate highway)75号線に近づくと、それらのサービスのうちの1つ、「Traffic at Dallas I−75」を利用できるようになる。このサービスをメニューから選択すると、その時点での交通情報を得ることができる。「個人向けサービス」メニューは、通常のWWWブラウザ(ワールドワイドウェブ)におけるブックマーク・リストにたとえることができる。電話ユーザはリストにアイテムを付け加えたり、それらを編集したり、それらを削除したりすることができる。この個人向けサービス・メニューによって、ユーザは多様なサービスを起動させることができる。サービス情報をオペレータ固有のあるいは地域サービスのリストから個人用サービス・リストに移すことができる。個人向けサービスメニューは、URL情報に基づいてインターネットから情報を引き出させることができ、e−メール・メッセージを受取人に送出させることができ、あるいはオペレータ固有の補足的サービスのストリングをネットワークに送出させることができ、あるいはコールを実行することができ、あるいはユーザ・メッセージを送出させることができる。例えばサブメニュー・コマンド「US気象(US weather)」は、端末に米国の気象に関する情報を受信させるということになる。
【0040】
次に、メニューの作成についてさらに詳しく説明する。メニュー作成は、プロセッサと、メモリに記憶されてそのプロセッサにより動かされるメニュー・アプリケーションにより制御され実現される。次に、プロトコルについて説明するが、このプロトコルに従ってメニュー・アプリケーションはプロセッサにより動かされるソフトウェアとして実行されることができる。後に図10と関連して端末について詳しく説明する。
【0041】
このプロトコルは所定のコマンドを定義し、それに従ってメニューの作成と変更およびメニュー構造が制御される。このプロトコルには4つのアイテム・プリミティブ(Item primitives)があり、それは追加、削除、リスト、およびアイテム能力である。これらのアイテム・プリミティブには、後述するように他のアイテム定義が伴う。
【0042】
第1のプリミティブ・アイテムはitem-addであり、これはメニューまたはサブメニューを追加する。コマンド・シーケンスは次の定義を含むことができ、それをユーザ・メッセージで端末に送ることができる。
【0043】
【表2】
【0044】
定義menu-item-token は、セキュリティが必要な場合にサーバが承認(authorization)目的に使用するオプションのコマンドであり、不要ならば省略しても良い。メニュー・アイテムが、セットされたmenu-item-token と共に送出されたならば、同じmenu-item-token が無しで既存のmenu-item を変更したり削除したりするコマンドを発することはできない。この種の承認の特徴を、メニュー・アプリケーションと関連して使用するだけではなく、ここに説明した他のアプリケーションと関連させて使用することもできる。例えば、呼び出し音は、menu-item-token のような正しい承認ワードまたはコードを伴っている場合に限って更新される。定義menu-group-name は、menu-item-nameという名称を持ったメニュー・アイテムがその中に入れられるメニュー・グループを明示する。もし同じ名称を持ったメニュー・アイテムが同じグループ内に既に存在するならば(そしてサーバが正しいmenu-item-token でそのメニュー・アイテムを更新することを承認されたならば)、既に存在するメニュー・アイテムは新しいものと置き換えられる。メニュー・グループの名称は、定義と関連してアポストロフィーの中に置かれる。
【0045】
定義menu-item-nameは、メニュー・グループ(またはメインメニュー)に属するsub-menuの名称またはコマンドを定義する。同様に、sub-menuの名称は定義と関連してアポストロフィーの中に置かれる。
【0046】
menu-group-name およびmenu-item-nameは共に「: 」という予約文字を有しており、これはメニュー・グループ・名称の中での改行という特別の意味を持っている、すなわち、「phone:settings」は、端末において「phone 」を1行目に表示し、「settings」を2行目に表示する。また、menu-group-name は「; 」という予約文字を持っており、これは複数階層メニューにおける階層レベルの変更を示すという特別の意味を持っている。
【0047】
menu-item-typeは、メニュー・アイテムのタイプが何かを示す。メニュー・アイテムは、「通常」、「変わりやすい(volatile)」、「選択された(変わりやすい)」、および「リンク」、というタイプを有することができ、その意味は下記の通りである:
【0048】
通常メニュー・アイテムは通常はハンドセットに記憶される。
【0049】
変わりやすいメニュー・アイテムは複数選択メニュー・アイテムについての、メニュー選択アイテムの1つ(one-of-menu selection items )である。
【0050】
選択された(変わりやすい)メニュー・アイテムは現在アクティブな変わりやすいメニュー・アイテムを示す。
【0051】
リンク・メニュー・アイテムは、サーバから変わりやすい選択項目を要求しなければならないことを端末装置に示す。
【0052】
定義menu-item-helpは、ハンドセットのユーザが現在のメニュー・アイテムに関してヘルプを必要とするときに表示されるテキスト・ストリングである。それはハンドセット固有であり、ハンドセットは例えばアイドル・タイマーが満了したときにヘルプ・テキストを自動的に表示する。menu-group-name およびmenu-item-nameについて前述したように、類似の付加的定義をmenu-item-helpと結びつけることができる。
【0053】
定義menu-action-listは、メニューから起動することのできる動作(アクション)のリストである。アクションは例えばaction-send-message のタイプ、あるいはaction-call-control のタイプである。action-send-message は、多くの方法のうちの1つでユーザ・メッセージを送出させる。その方法はメッセージのタイプによるが、それは前に明示したようにどんなユーザ・メッセージであっても良い(SMS、USSD、Rデータ、SOC、パケット無線)。action-call-control は、多くの方法のうちの1つでコールを行わせる。方法はcall-control-type に依存し、それは音声コール、データ・コール、ファックス・コール、あるいはss(補足的サービス・ストリングがネットワークに送出される)であって良い。
【0054】
第2のプリミティブ・アイテム・コマンドであるitem-remove は、(menu-item-token または承認リストに基づく)承認が欠けてはいないことを条件として、menu-group-name およびmenu-item-name) により識別されるメニュー・アイテムを端末から削除させる。コマンド・シーケンスは下記の通りであって良い。
【0055】
【表3】
【0056】
第3のプリミティブ・アイテム・コマンドであるitem-list は、このコマンドを当初に送出したサーバへmenu-item-nameのリストを端末から送出させる。サーバは、どのアイテムのリストが要求されているかについてのメニューを明示することができる。menu-item-token が与えられたとき、マッチしたトークンを持ったアイテムだけが返される。コマンド・シーケンスは下記の通りであって良い。
【0057】
【表4】
【0058】
第4のプリミティブ・アイテム・コマンドであるitem-capability を使って臨時の能力をメニュー・アイテムに付け加えたり除去したりすることができる。このコマンドを使って、例えば、明示された能力に応じてメニュー・アイテムにアイコンを付け加えることができる。コマンド・シーケンスは下記の通りであって良い。
【0059】
【表5】
【0060】
メニュー変更の承認を承認プリミティブによってより厳密に定義することができる。3つの承認プリミティブがあり、それは追加、除去、およびリストである。特にオペレータ・メニューおよび製造者メニューのために承認リストを使用することができる。これは、端末が何個のエントリーを各メニューの承認リストに記憶することができるかはその実現により固有である。承認プリミティブおよびそれらを端末に入力するためのコマンドを、menu-item プリミティブについて上述したのと同様にして実現することができる。承認コマンドは、その承認コマンドがアクティブな承認リストを伴うメニューについてのみ、既に承認されているサーバから送出されたときに限って、容認されるという意味で、特権を持っている。
【0061】
第1のプリミティブ承認コマンドであるauthorization-add を使って、与えられたメニュー(menu-group-name)について承認済みサーバのリストに1つ以上の新しい承認済みサーバを追加することができる。menu-authorization-server-listは、1つあるいはそれより多い情報行を備え、その各々が1つの承認済みサーバを定義する。GSM/SMSについては、承認済みサーバはショートメッセージ・サービス・センターおよびサーバの、対の定義アイデンティティー(pair defining identity)例えばSM−SCについての移動加入者国際ISDN番号であるSMSCのMS−ISDNと承認済みサーバについての移動加入者国際ISDN番号であるサーバのMS−ISDNによって定義される。コマンド・シーケンスは下記の通りであって良い。
【0062】
【表6】
【0063】
第2のプリミティブ承認コマンドであるauthorization-removeを使って、与えられたメニュー(menu-group-name)について承認済みサーバのリストから1つあるいはそれより多い承認済みサーバを除去することができる。コマンド・シーケンスは下記の通りであって良い。
【0064】
【表7】
【0065】
第3のプリミティブ承認コマンドであるauthorization-listを使って、要求されたメニュー(menu-group-name)についての特権を有するサーバのリストを送出するようにハンドセットに要求することができる。このコマンドを利用可能性はハンドセットの実現による。コマンド・シーケンスは下記の通りであって良い。
【0066】
【表8】
【0067】
メニュー・アプリケーションは種々のコマンドの意味を記憶している。これを例えば端末においてソフトウェアとしてのスクリプト解釈プログラム(script interpreters)の形式で行うことができる。スクリプト解釈プログラムの1例は、特定のプログラミング言語を理解する解釈プログラムである。従って、特定のコマンドまたはコマンドのシーケンスが本発明のユーザ・メッセージで受信されたとき、メニュー・アプリケーションはそれに応じて、追加または除去メニューおよび/またはサブメニューなどの動作を実行する。上記は実例と見なされなければならない。当然に、上記以外の種々のコマンドを使用することができ、それらは、1つのユーザ・メッセージに(例えばショートメッセージに)より多くのコマンドをはめ込むために、もっと短くても良い。
【0068】
ショートメッセージに対してメニュー・アプリケーションを使用するときには、ユーザ・メッセージをメニュー・アイテムによって起動するときに、そのメッセージが特定のショートメッセージ・サービス・センターを介してあるいは特定のリストのいずれかのSM−SCへ送出されることとなるように、1個または数個のショートメッセージ・サービス・センター(SM−SC)の番号をメニューに関連づけることができる。例えばメニューが作成されあるいは更新されるときに、特定のあるいは種々のSM−SCの番号をネットワークから端末へユーザ・メッセージで送出することができる。この様にすれば、特定のメニュー・コマンドを介してアクセスすることのできる特別のサービスが(あるいはそのサービスを提供するサーバが)特定のサービス・センターに接続されるとき、サービスの可能性が増え、ユーザ・メッセージの送信がより速くかつ信頼できるものとなる。
【0069】
ユーザがディスプレイ上に見るものを例示するディスプレイのシーケンスとして、呼び出し音のためのメニューを作成する例が図11に示されている。最新の呼び出し音を要求するためにコマンド「NEW RINGING TONES 」がユーザ・メッセージで呼び出し音サービス・プロバイダのサーバに送出される。応答として、サーバはメニューを作成するためのメニュー・アプリケーションに関連する情報を含むユーザ・メッセージを送出し、それからユーザは新しい呼び出し音を選択することができる。ユーザは望ましい呼び出し音をメニューの中から選択する(呼び出し音「Popcorn 」を選ぶ)。この選択で、サーバに送出すべき、所望の呼び出し音を示すユーザ・メッセージが起動される。しばらくして端末はその呼び出し音をサーバから受信する。受信された呼び出し音は、「RINGING TONE RECEIVED (呼び出し音受信)」通知によってユーザに示される。ユーザはその呼び出し音を容認しあるいは拒絶することができる。ユーザが容認を表示すると、「Save(保存)」および「Playback(再生)」というオプションのある選択メニューが表示される。ユーザがSaveオプションを選ぶと、受信された呼び出し音は電話機に保存され、それは呼び出し音オプション・メニューに現れる。保存動作は、「SAVED (保存済み)」確認記号を表示することによってユーザに表示され、その後に電話機はアイドル状態となる。もしユーザがPlaybackオプションを選ぶと、受信された呼び出し音が再生され、その後に元の選択リストが再び表示される。もしユーザが新しい呼び出し音を拒絶すると、受信された呼び出し音は捨てられて、選択リストがスクリーンから除去され、電話機はアイドル状態になる。
【0070】
次に、端末において機能を生成するコマンドのアプリケーションの別の例について、図12を参照して説明する。この例は、ある飛行便の時刻表を問い合わせることに関する。まず、ユーザはこの目的のために作られたメニュー・コマンドを既に端末に持っていると仮定するが、そのコマンドは端末が本発明に従って受信したものであって良い。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLE(フィンエアー飛行便時刻表)は、要求が送出されるべきサーバの連絡情報を有しており、あるいは、もし端末が特別の交信をしたならば、要求はその交信から、要求されるべきサービス、すなわちフライトスケジュールのあるサーバに回送される。メニュー・アイテムFINNAIR FLIGHTS TIME-TABLEを起動すると、第1のユーザ・メッセージは要求を送信することを示すコードまたは記号を有し、例えば、1)最初に送られるユーザ・メッセージは下記の通りである。
【0071】
???FLIGHTS
【0072】
ここで「???FLIGHTS」は、それがフィンエアー飛行便時刻表を求める要求であることを受信側サーバに示すコマンドである。ユーザは、そのメッセージの内容は見ず、要求が送信されること、それが送信されたこと、および回答が来るまでユーザが待たなければならないこと、を示すディスプレイ上の記号を見る。それらの記号が図12においてステップ1)の後に示されている。この後、端末はサービス・プロバイダからユーザ・メッセージを受信する。例えば、
【0073】
2)第1の受信したユーザ・メッセージは下記の通りである。
【0074】
++Finnair flight queryCR
<From:CR
<To:CR
<+Date:CR
【0075】
ここで++は、端末に回答を待つように指示するものであり、その後のテキストはしばらくの間端末のスクリーンで表示され、CR(Carriage Return :キャリッジリターン)はコマンド行を終了させる。記号「< 」は文字入力モードを示し、この'<' 記号の後のテキストは、図12に示されているように端末のスクリーンで表示され、これはユーザが文字を入力することを可能にする。この例では、要求がオウル(Oulu)市からのフライトに関するものであることを示すOUL が入力される。ユーザは所定のコマンド(例えば特定のキーを押すことなど)で入力を終了する。同様に行き先を示す次の入力モードがディスプレイで表示され、ユーザは要求がヘルシンキ市への飛行便に関するものであることを示すHEL を入力する。記号「<+」は、数字入力モードを示しており、この記号の後のテキストは、図12に示されているように端末のスクリーンで表示され、これはユーザが数字を入力することを可能にするものであって、この場合には要求された飛行便の日付である。最後のコマンドに達すると、端末は書式が完成したか否か、そして要求を送出することができるか否かを尋ね、もしそうならば端末は入力情報を含む第2のユーザ・メッセージを作成して送信する。例えば、
【0076】
3)2番目に送るユーザ・メッセージは下記の通りである。
【0077】
++Finnair flight queryCR
<From:OULCR
<To:HELCR
<+Date:041296CR
【0078】
これをサービス・プロバイダ(サーバ)は所定コマンドに従って解釈することができる。この場合にもユーザはこのユーザ・メッセージの内容を見ず、所定の記号が端末のスクリーンで表示される。この要求に対する応答として端末はサービス・プロバイダから2番の受信したユーザ・メッセージを受信する。例えば、
【0079】
4)2番目に受信されたユーザ・メッセージは下記の通りである。
【0080】
Finnair flights frm OUL to HEL 04/12/96:CRAY3434, 06:05 AY3436, 07:00 AY3438, 07:30 AY3440, 10:15
【0081】
端末は、関連情報(アプリケーション固有のコードではない)を、図12に示されているようにユーザに表示し、ユーザが(例えば矢印キーあるいはその他のスクロール手段で)情報をスクロールできるようにし、ユーザインターフェースからのクイットコマンド(a quit command)に応答して、元のメニュー・コマンドを表示する状態に戻る。
【0082】
上記の、図12に図示されている例は、所定のコマンドに対応する所定の記号を有することによって、新しいサービスを移動電話機等の端末に提供するために本発明のユーザ・メッセージをどのように使えるかを示している。これらの記号およびコマンドは、ユーザの端末装置(例えば移動電話機)あるいはサービス・プロバイダの端末装置(例えばコンピュータ)の、メモリに記憶することができ、その所定コマンドを実行するためにプロセッサにより動かされるソフトウェアで実現することができる。この様にして端末が特定の方法で機能するようにプログラムすることもまたできる。メニュー・アプリケーションは新しいアプリケーションを端末に導入することを可能にする。例えば、第1のメニュー(例えばメニュー「電話帳」)を作るサービス・プロバイダから、第1のユーザ・メッセージによって前述した電話帳アプリケーションを端末に導入することができ、その後、要求をサービス・プロバイダに送出するときに端末は最初に前述したように関連電話番号を得るのに必要な情報を送るためにメニュー構造を受信し、関連情報を送った後に端末はその電話番号を含む応答を受け取る。この処理手順は、フライトの時刻表を問い合わせるための、図11と関連して前に説明した処理手順と同様である。
【0083】
次に、端末に前もって記憶されていない他のアプリケーションについて図8〜10、および付録1を参照して説明する。端末により、移動通信ネットワークを通して電子メールを送出することができる。これに対応して、端末により、移動通信ネットワークを通してインターネットとの通信リンクを確立することができる。データ・カードによって、コンピュータを移動局に接続することにより、この通信リンクを確立することができ、この場合には、そのコンピュータのユーザインターフェースを使ってインターネット上のページおよびサービスを読むことができる。代わりにインターネットとの通信リンクを通信機器によって確立しても良く、それは、インターネット上のページおよびサービスを読むためのユーザインターフェースを備える。この種の通信機器が1996年2月26日に出願されたフィンランド特許出願第960894号に提示されており、この特許出願からの優先権を主張して1997年1月27日にEPOに対応する特許出願が出願番号第97101184.6号で出願されており、米国では1997年1月23日に出願されており、その説明を参照により本件に取り入れたものとする。インターネット上の種々のページとの通信リンクを確立することを可能にすると共に、インターネット上でのいわゆるサーフィンを可能にするコンピュータ・プログラムは、WWW(ワールドワイドウェブ)ブラウザと呼ばれている。現在、幾つかの会社が自分のサービス・ページをインターネット上に持っており、それを通してユーザはサービスに関する情報を注文したりあるいは注文を出して予約をすることができる。これは、その様なサービス・ページとの通信を確立して、そのサービスのプロバイダから要求するものに関する情報を入力することによって達成される。この情報はテキストまたは選択ボックス/キーであって良く、これによって「適当なボックスにチェックする(tick the appropriate box)」原理に従って選択を行う。このようなサービス・ページの例が図8に示されており、この図はバスの時刻表についての問い合わせページを示しており、これをユーザは例えばインターネット等の電気通信ネットワークを通してディスプレイにダウンロードすることができる。この場合、ページはそのページが使用される間はその通信機器のメモリ(例えば隠されたメモリ:hidden memory)に記憶されており、それをオフラインコマンドによって固定記憶装置に記憶することができる。そのページ上で、ボックスで選択を行うことができると共に、追加した要求と、例えば、フィードバックのための連絡情報とをそのページ上で利用できるスペースに書き込むことができる。代わりに、「コール・ミー・バック」アプリケーションと関連して前述したように、通信機器が、自分の電話番号を、フィードバックのためのアドレスとして自動的に提供しても良い。公知のように、インターネット上のページをHTML(Hyper Text Markup Language:ハイパーテキストマークアップ言語)で表示することができる。インターネットからのサービス・ページをHTML言語に変換し表示することはWWWブラウザから知られる。
【0084】
付録1はインターネットのページを記号で表すためにHTML言語に変換された図8のインターネット・ページを例示している。これらの文字をショートメッセージで送ることができる。GSMシステムでは、最長で160文字の長さのメッセージをショートメッセージで送出することができる。従って、本発明では、ページ全体を好適には送信することはできなくて、その中のある情報だけが送られる。このサービス・ページ上のHTMLコードでは、ディスプレイで表示されるべき情報と、隠された情報との両方が指定されている。種々のタイプのデータが前もってセットされたコードを有する。本発明に従ってこのページを送出するために、アプリケーション関連情報を送出するのに必要な情報が、そのページのHTMLコードに付け加えられ、この情報はユーザには秘密にされる、すなわち、それはそのページのグラフィック表示には含まれない。その情報は好適にはサービスのプロバイダによってページ上で配置されている。このようなサービス・ページをショートメッセージとして送信するために、サービスのプロバイダは、当該ページに特別の情報、少なくともメッセージを送出する相手の電話番号、を含ませることによって問題の機会を与えるべきである。付録1に例示されている矢印A〜Jの箇所に、本発明に従ってページの情報をショートメッセージで送出するためにHTMLコードに付け加えられる情報が表示されている。例えば、矢印Aでは、表示されている仕様によって符号化方法を示すことができる。矢印Bは書式のタイプが問い合わせであることを示している。矢印Cは、サービス・プロバイダの名称あるいは略号を示している。矢印Dは、当該サービスのタイプを示している。矢印Eは、サービス・ページの名称を表示している。矢印Fは、回答を表示するために端末が使用するべき書式を示している。矢印Gは、受信者すなわちサービス・プロバイダの電話番号を表示している。矢印Hは、このメッセージの送信で経由されるショートメッセージ・サービス・センターの電話番号を表示している。矢印GおよびHにより示されている情報は、少なくとも不可欠である。矢印IおよびJは、必要に応じてHTMLページに付け加えることのできる他の仕様を表示している。矢印Jの後に、当該WWWページを形成する実際のHTMLコードが続いている。
【0085】
それに相応して、HTMLコードの特定の識別子を発見するように端末を前もってセットしておくことができ、それを端末はHTMLコードから見つけだして、送出されるメッセージのデータ・フィールドINFOにそれを文字として添付する(図6を参照)。例えば、選択された時間は、矢印Kにより指示されている行の中に変数c/o としてわかり、その後にその選択された時間が表示されており、それはSENDボタンを押す動作に対する応答として得られる。図8に例示されているように、一番上の選択ボックス「1B1 」に印が付けられており、それは付録1のHTMLコードでは矢印Lで指示されているチェック付きコードとして行の中に示されている。一番上の選択ボックスが選択されているとすると、ユーザがSENDボタンを押せば、変数opt1は、アイコンを押したときに選択された選択ボックスの値すなわち「1B1 」を得る。
【0086】
図8および付録1に例示されている例では、通信機器等の端末は、このようにして、矢印C、D、G、H、K、およびLにより指示されている行の中のHTMLコードから情報を選び出す。端末は、冒頭に、アプリケーションのタイプを示す識別子を、ここでは識別子「WWWSMS」として、置くであろう。さらに、矢印Cにより指示されるポイントから、サービス・プロバイダ識別子を前に置くことができ、これに基づいて受信者は当該情報、例えば、ここでは記号Cを認識する。さらに、それに相応して、サービス名を矢印Dのポイントから置くことができ、送信者の電話番号を矢印Gのポイントから置くことができ、受信者の電話番号を矢印Dのポイントから置くことができ、選択はユーザにより、矢印KおよびLのポイントから行われるが、それは、このページ上の全ての変数(ここでは変数c/o およびopt1)がメッセージ中に配置されることとなるように、機能する。変数の値は、好適には、送出コマンドに対する応答として、すなわちSENDアイコンを押す動作に対する応答として、得られる。この場合、ショートメッセージで送られるデータは、例えば、次の通りである。
【0087】
WWWSMS[cr]
CErSa[f]
DTre Bus[f]
G+358505337397[f]
H+358508771010[f]
08:00 1B1
【0088】
ここで[cr]文字は改行を意味し、[f] 文字はフィールド区切り符号(field separator)であってフィールドの終わりを示すものであり、最後の行でユーザによりなされた全ての選択が表示される。すなわち、ユーザが08:00 時後に出発する路線1B1(Holvasti-Keskustori )のバスの時刻表に関する情報を求めていることが表示される。これに基づいて、サービス・プロバイダは、当該バス路線の時刻表に関する情報をユーザに送出することができる。
【0089】
このタイプのサービス・ページをインターネットからダウンロードしたならば、それを端末のメモリに記憶して、後にインターネットとの通信リンクを確立せずにそれを再利用することができる。それに相応して、端末に前もって記憶されているアプリケーション関連情報に関して、図8および付録1に例示されているアプリケーションに関する情報の送出と関連して、特定の識別子をメッセージに添付することができ、それは、アプリケーションがインターネットからダウンロードされたサービス・ページであることを示すものであり、例えば前述の例のように識別子「WWWSMS」あるいは「WWWSMS45」であり、その冒頭部はこれがサービス・ページであることを示し、最後の2つの記号は、例えば、サービス・プロバイダを示すことができる。
【0090】
本発明によってサービス・ページの情報をショートメッセージで送出すると、端末の電力消費量が相当節約され、従ってその実用寿命が長くなるが、これは電池駆動式装置における重要な目標である。さらに、問い合わせ情報をショートメッセージと共に送出できるときには、電話コールの費用が節約されることになる。システム全体が図9にいっそう詳しく例示されている。本発明の端末が参照番号1で指示されており、これによりインターネットINTとの通信リンク(参照番号101)を確立することができる。本発明によるアプリケーションに関する情報を処理してショートメッセージにするための手段を有する装置によって本発明を実施することもでき、それは装置を普通の移動局に結合することによってその移動局を通して送出される。その様な装置は、例えば、コンピュータである。事柄を単純にするために、本発明の端末の例としてここでは通信機器のみについて論じる。通信機器1によってインターネットとの通信リンクが確立されると、サービス・プロバイダのサービス・ページをインターネットからそのメモリおよびユーザインターフェースにダウンロードする(参照番号102)ことができる。従来技術の公知の解決策により、ユーザは、そのページに書き込みをした後、そのサービス・ページを通信機器1によってサービス・プロバイダのサーバSERVへ、すなわちルート101−101’に沿って、送出することができる。このことは、インターネットとの通信リンクが送信のためにオープンでなければならないことを意味する。本発明のシステムでは、サービス・ページに関する情報はショートメッセージでショートメッセージ・サービス・センターSM−SCに送られ(参照番号103)、このセンターはそれをさらにサービス・プロバイダのサーバSERVに送る(参照番号104)。従来技術によるインターネット経由でのサービス・ページの送信はショートメッセージの送信より相当長く続くので、本発明により、より短い送信時間が達成されることになり、従って、通信機器では特に送信および受信が他の機能と比べて大量の電力を消費するので、電力が節約されることになる。さらに、従来技術の解決策では、回線結合接続が送信時に使用され、この場合には通信機器は送信中は話中になる。一方、ショートメッセージの送信は回線結合接続を話中にせず、メッセージの送信中にサービス・プロバイダの電話番号がたまたま届かなかったならば、ショートメッセージ・サービス・センターSM−SCが後でそのメッセージを受信者に送出するという付加的利点もある。
【0091】
ユーザがこのようにしてサービス・プロバイダに問い合わせを送ると、そのサービス・プロバイダはそれを解釈して、それに対して応答する。サービス・プロバイダも応答をショートメッセージとして送出することができ(参照番号105−106)、それはサービス・ページの送信の場合と同じ方法でHTMLコードを含むことができ、これを通信機器は解釈してユーザが読みやすい形式に変換する。従って、応答の送出にも問い合わせの送出の場合と同じ利点がある。応答のために、インターネットからダウンロードされたオリジナルのサービス・ページを、そのページに応答のために使用できるスペース(フィールド)ができるように、HTMLコード・ページを動かすアプリケーションによりディスプレイ上で配置することができる。ユーザは、問い合わせをサービス・プロバイダに送出するとき、そのページを通信機器に記憶する。応答は、送信の場合と同じ方法で、特別の識別子を有し、その場合には応答が到達すると、通信機器はその特定のアプリケーションを動かせてディスプレイ上に当該ページを開いて、そのために設けられている領域にその応答を置くので、ユーザの見地からは状況はあたかもユーザがその応答を含むWWWページを受け取ったかのように見える。サービス・プロバイダからの応答は、例えばアプリケーション「DTMFサービス・コマンド」あるいはそれに相当する書式であっても良い。
【0092】
アプリケーション識別子は、ショートメッセージにおいて(データ・フィールドINFOにおいて)コードとして表示される代わりに、ショートメッセージのアドレス・フィールドADDにおいて表示されても良く、その場合にはそれはビットで表示される。ショートメッセージの送信フレームのアドレス・フィールドの一定のバイトは、GSM仕様でGSM 03.40 および03.38 として明定されているいわゆるTPデータ符号化方式(TD-Data-Coding-Scheme)である。そのバイトの下位4ビットは自由に使えるビットであり、これを本発明に従って送出されるべきアプリケーションのタイプを示すために使用することができる。下記の表で与えられる例に従ってこれら4ビットにより種々のタイプのアプリケーションを表示することができるが、ここでビットには符号b3〜b0が付けられていて、b0は前述のバイトの最下位ビット(LSB)である:
【0093】
【表9】
【0094】
このやり方でアプリケーションを特定すれば、メッセージの文字長(最大で160文字)のために予約されているスペースを使わなくても良い。このタイプの識別を使えば、普通の移動局によって送信されたアプリケーションに関する情報を受信することも可能であるが、この場合には、ユーザは、そのメッセージに関して、この情報が移動局でプログラムされたものでなければ、それが特別のアプリケーションからの情報であることを知ることはできない。また、ユーザはこのタイプの識別子をメッセージに付け加えることはできないので、普通の移動局によってこのタイプのアプリケーションに関する情報を送出することはできない。当然に、普通の移動電話機は種々のアプリケーションをサポートしない。
【0095】
次に、端末、この場合には本発明の無線端末の実現と、アプリケーション関連情報を送信および受信するときのその動作と、を図10を参照してさらに詳しく説明する。
【0096】
図10は、本発明の端末の実現のブロック図であり、それはこの図では移動電話機等の無線による送信のための手段も有する装置として示されている。しかし、類似の実現をサービス・プロバイダの端末装置に使っても良いけれども、それは普通は直接無線周波数送信のための手段を有してなくて、図2に示されるような手段(例えば移動局)にネットワークを介して接続される(例えば、パソコンPCまたはサーバGTW)。端末は好適には移動電話機または通信機器であり、それは種々のアプリケーションを処理できるようにする回路とユーザインターフェースとを持っている。図10の端末1は、無線通信を使う通信を行うために、無線ユニットRU(この参照符号は図には付されていない)を備え、それは、普通の移動局とは区別される送信器ブランチ(transmitter branch)2(符号化、インターリーブ、暗号化、変調、および送信、を実現するブロックを備える)と、受信側ブランチ(receiving branch)3(受信、復調、解読、インターリーブ解除、および実行、のブロックを備える)と、を備えており、また無線通信を使う送信のために、受信されたメッセージと送信されるメッセージとを区別する双方向フィルター(duplex filter)4とアンテナ5とを備える。この端末は、その動作を制御する主制御回路6を有する。さらに、主制御回路6は、普通の移動局の機能の制御機能を実行するRUコントローラ7も有する。さらに、端末の主制御回路6は、端末のデータ処理ユニットの機能を実行すると共にアプリケーション関連情報を本発明に従ってショートメッセージとして送信する、ためのブロック8〜12を有する。従って、ブロック8〜12は、端末のデータ処理ユニットDUを形成するものであると言うことができる。無線ユニットRUの制御部および端末のデータ処理ユニットDUを主制御回路に統合する必要はなく、代わりにそれらを別々に実現することもできて、RU制御回路7を無線ユニットの側に置き、データ処理ユニットの側にはDUプロセッサ8を置くことができ、それは、無線ユニットとデータ処理ユニットとの間の通信を確立するためにRU制御回路と接続される。
【0097】
図9に例示されている実現では、第1のメモリ13は主制御回路6に結合されている。第1のメモリは例えばRAM等の揮発性メモリであって良く、これに主制御回路は使用中のデータを記憶しておく。さらに、端末は第2のメモリ14を有し、これは好適には固定記憶装置14であって、種々のサービスを実行すると共に種々のアプリケーションを動作させる端末のアプリケーション・プログラムと、端末の動作に不可欠の他のデータと、ユーザが永久的に記憶しておきたい他のデータと、が第2のメモリに記憶される。あるいは、端末に結合され、そこから主制御回路6に接続される外付けスマートカードのメモリにアプリケーション関連情報をオフラインで記憶しても良い。このタイプのスマートカードは、例えばGSM移動通信システムからSIMカード(Subscriber Identity Module:加入者識別モジュール)として知られており、それは普通は例えば電話番号を記憶させておくための記憶装置(storase)を持っている。この場合、スマートカードのメモリを単に更新することによって新しいアプリケーションを端末において更新することができる。
【0098】
アプリケーションを見るために、端末はディスプレイ15を有しており、データを入力するためにキーボードやその他の、例えばタッチ・ディスプレイ等の入力装置16を持っている。
【0099】
データ処理ユニットDUおよび無線ユニットRUが、機能に関して独立しているユニットとして実現される場合にも、その両方が、共通のあるいは別々のメモリ13、14とユーザインターフェースUIとを有するべきである。これらのユニット間の通信はDUプロセッサ8とRU制御回路7との接続によって確立され、それはこの関係では外付け制御インターフェースECIと呼ばれる。
【0100】
次に、アプリケーション関連情報を送信するときの、端末装置の実現と端末の動作とについて説明する。ユーザインターフェースUIによって、所要のアプリケーションが端末のディスプレイにもたらされ、その場合には入力装置からの16種類のコマンドに基づいて、制御回路7は、アプリケーション関連情報をプログラマブルに取り扱うアプリケーション17、18が記憶されているメモリ14から、これに記憶されている選択されたアプリケーションをディスプレイ15に取りだし、あるいは前述したように電気通信ネットワークからサービスを取り出す。サービスに関連するアプリケーションはDUプロセッサ8で処理されるが、これは、無線ユニットRUの動作を制御するRU制御回路7との交信を保つことによってアプリケーション関連情報の送信も制御する。アプリケーションは、図7に例示されているように、情報を含んでいる。その情報は1つあるいはそれより多いフィールドの中にあり、そのフィールドは(もし既に情報を含んでいるアプリケーションの記録がメモリから取り出されたならば)すでに満たされているか、あるいはそのデータ・フィールドは空であり、その場合にはユーザは入力装置16によってそのフィールドに情報を入力したり、あるいはそのフィールドの中の情報を修正したりすることができる。アプリケーションが所要の情報を含んでいて、ユーザが入力装置によってアプリケーション関連情報を送出するコマンドを入力すると、DUプロセッサ8は、そのアプリケーションに関する情報から記号の行を形成し、そのプロセッサは、その行の冒頭にアプリケーション識別子を置き(もしその識別子がアドレス・フィールドで表示されていなければ)、そしてその後に、例えば、改行文字で区切られた種々のフィールドに含まれている情報を、記号間にありえるのスペースも含む英数字文字で作り変えて、配置する。従って、DUプロセッサ8は、文字の処理のために、ワードプロセッサ・プログラムに類似する機能を備えており、それはプログラミングにより実現されてメモリ14に記憶されており、そこからDUプロセッサ8はそのプログラムを取りだして、そのプログラムに従って機能を実行する。DUプロセッサ8は、形成された文字の行をSMS送信コントローラ10へ転送し、そのコントローラは、そのメッセージにアドレス情報を、すなわち、宛先に関する情報を、ユーザが入力した情報に基づいて、あるいはそれを例えば前述したようにカレンダー・アプリケーションなどの別のアプリケーションから取りだして、付け加える。従って、この種のSMS送信コントローラは一種のビットおよび/または文字生成器である。カレンダーは好適には、DUプロセッサ8により使用されるメモリ14に記憶されるアプリケーション・プログラムとして実現される。したがって、2つの異なるアプリケーション17および18の間の通信はDUプロセッサによって確立され、このプロセッサは、例えば、1つのアプリケーションから取り出された時間情報に基づいて、他方のアプリケーションを開いたりそれに情報を入れたりする(例えば当該時間にカレンダーの中に)。
【0101】
アドレス情報がSMS送信コントローラ10で追加されているときには、そのメッセージはアウトボックス11へ転送され、これはそのメッセージを送出しようと試みるものであって、バッファを有しており、送信が失敗した場合にはその中に該メッセージが記憶される。送信が失敗したら、アウトボックス11はもう一度メッセージを送出しようと試みる。無線ユニットRUがメッセージを送出できる状態になっていることにDUコントローラ8が気づいたとき、そのメッセージはメッセージ転送動作回路12へ転送され、この回路は、妥当性情報(validity information)(これは、そのメッセージがどの方向に進むのか、すなわち、移動局からメッセージ・サービス・センターへ進むのか、あるいはその逆に進むのか、を示す)などの、当該移動通信システムに関連する情報をそのメッセージに付け加え、アドレス情報を処理して移動通信システムが必要とする書式に変換し、メッセージ・サービス・センターのアドレスとショートメッセージ識別子(SAPI)とをそのメッセージに付け加え、送信されるべき情報から例えば送信器2のためのディジタル信号を形成し、そのメッセージを無線ユニットRUの無線送信器ブランチ2に送出する。アプリケーション識別子がビットの形でアドレス・フィールドADDに置かれる場合には、動作回路12はそのメッセージに当該識別子を付け加える。送信器ブランチ2は、移動通信システムの仕様に従って信号を符号化し、自分が動作回路12から受信した信号に基づいて、送信されるべきフレームを作成し、これを送信器は無線通信を使ってショートメッセージ・サービス・センターSM−SCに送出し、そこから該フレームはさらに受信者に送出される(図1を参照)。送信器ブランチ2では、移動通信システムに応じてメッセージが処理される。すなわち、符号化、インターリーブ、暗号化、バースト形成、変調、および送信が行われる。
【0102】
次に、アプリケーション関連情報を受信するときの端末の実現および動作について説明する。端末がアプリケーションについての情報を含むショートメッセージを受信するとき、そのメッセージは始めに無線ユニットRUに到着する。その受信側ブランチ3で、受信、復調、解読、インターリーブ解除、および復号などの処理が移動通信システムに従ってそのメッセージに対して行われる。もし受信されたフレーム識別子(SAPI)が、そのメッセージがショートメッセージであることを示しているならば、それはデータ処理ユニットのインボックス9へ転送されるが、これは該メッセージを記憶しておくためのメモリであって良い。もし受信されたメッセージが普通のショートメッセージであれば、DUプロセッサ8は受信されたメッセージを伝える。それがアプリケーション関連情報であることを示す識別子をそのメッセージが有していれば、DUプロセッサ8は当該アプリケーション17、18を送り出して、受信されたメッセージからの情報を、受信されたメッセージのマーキングに従ってアプリケーションの中に置く。従って、ユーザ・メッセージ(例えばショートメッセージ)の受信は、受信されたアプリケーション関連情報としてユーザに表示される。
【0103】
本件は、本発明の実現および実施例を例示しながら提示している。本発明が前述の実施例の詳細には制限されないこと、そして本発明の特徴から逸脱せずに別の実施例で本発明を実現し得ることは当業者にとっては明白なことである。従って、提示した実施例は例示としてみなされ制限をするものではないと解されなければならない。従って、本発明を実現し利用する可能性は、特許請求項によってのみ限定されるに過ぎない。それに相応して、クレームにより決まる本発明のいろいろな実現のオプションは、その同等の実現も含めて、本発明の範囲に属する。
【0104】
付録1
【0105】
【表10】
【0106】
【表11】
【図面の簡単な説明】
【0107】
【図1】一方の移動局からもう一方の移動局へのショートメッセージの流れを例示する。
【図2】ショートメッセージ・サービス・センターへの移動局システムの接続を例示する。
【図3】普通の移動電話機のユーザインターフェースを例示する。
【図4】送信時のメッセージのフレームへのセグメント化を例示する。
【図5】受信時のメッセージの復元を例示する。
【図6】ショートメッセージのフレームを例示する。
【図7】本発明の1つのアプリケーションを例示する。
【図8】別のアプリケーションを例示する。
【図9】システムの見地からの、図8に例示されているアプリケーション関連情報の送信を例示する。
【図10】本発明の端末の実現を例示する。
【図11】本発明の端末における1アプリケーションの機能を順に例示する。
【図12】本発明の端末における1アプリケーションの機能を順に例示する。
【符号の説明】
【0108】
1 端末
2 送信器ブランチ
3 受信側ブランチ
4 双方向フィルター
5 アンテナ
6 主制御回路
7 RU制御回路
8 DUプロセッサ
9 インボックス
10 SMS送信コントローラ
11 アウトボックス
12 メッセージ転送動作回路
13 第1のメモリ
14 第2のメモリ
15 ディスプレイ
16 入力装置
17 アプリケーション
18 アプリケーション
【特許請求の範囲】
【請求項1】
第1の装置と第2の装置との間で電子ビジネス・カードを転送する方法であって、前記第2の装置は、前記第1の装置から遠方にあり、前記第1および第2の装置の両者は、移動通信ネットワークを介して通信することができる移動局、および前記移動通信ネットワークへの接続を有するコンピュータのうちの1つである方法において、前記方法は、
いくつかのデータ・フィールドを各々有する複数の電子ビジネス・カードを含む前記第1の装置のビジネス・カード・アプリケーションから、電子ビジネス・カードを検索するステップと、
前記ビジネス・カードを、前記移動通信ネットワークを介して前記第2の装置へ送信するステップと、
受信したビジネス・カードを、前記第2の装置のビジネス・カード・アプリケーション内に記憶するステップと、を備える方法。
【請求項2】
前記データ・フィールドは、前記第2の装置により認識され得るフィールド区切り符号によって分離される請求項1に記載の方法。
【請求項3】
前記電子ビジネス・カードは、少なくとも前記データ・フィールドの1つとして名称を有すると共に前記データ・フィールドの他の1つとして電話番号を有する請求項1に記載の方法。
【請求項4】
前記送信ステップは、前記ビジネス・カードをユーザ・メッセージで送信することを含む請求項1に記載の方法。
【請求項5】
前記ユーザ・メッセージは、該ユーザ・メッセージを電子ビジネス・カードであると特定する識別子を含み、受信したビジネス・カードは、前記識別子に基づいて前記第2の装置の前記ビジネス・カード・アプリケーションへアドレス指定される請求項4に記載の方法。
【請求項6】
無線通信のための手段を有する端末であって、
いくつかのデータ・フィールドを各々有する電子ビジネス・カードを記憶しておくメモリと、
移動通信ネットワークを介して電子ビジネス・カードを送信する手段と、
前記移動通信ネットワークを介して電子ビジネス・カードを受信して、受信した電子ビジネス・カードを前記メモリに記憶する手段と、を備える端末。
【請求項7】
前記電子ビジネス・カードをユーザ・メッセージにて送信する手段をさらに備える請求項6に記載の端末。
【請求項8】
前記ユーザ・メッセージは、ショートメッセージ、規格化SMSメッセージに従ったメッセージ、規格化Rデータフィールドメッセージに従ったメッセージ、規格化USSDメッセージに従ったメッセージ、規格化SOCメッセージに従ったメッセージ、及びワイヤレスパケット無線サービスに従ったメッセージのうちの1つである請求項7に記載の端末。
【請求項9】
前記ユーザ・メッセージは、アスキー(ASCII)文字を備える請求項6に記載の端末。
【請求項10】
前記ユーザ・メッセージは、該ユーザ・メッセージを電子ビジネス・カードであると特定する識別子を備える請求項6に記載の端末。
【請求項11】
前記端末は、移動通信ネットワークを介して通信することができる移動局、および前記移動通信ネットワークへの接続を有するコンピュータのうちの1つである請求項6〜10のいずれか一項に記載の端末。
【請求項1】
第1の装置と第2の装置との間で電子ビジネス・カードを転送する方法であって、前記第2の装置は、前記第1の装置から遠方にあり、前記第1および第2の装置の両者は、移動通信ネットワークを介して通信することができる移動局、および前記移動通信ネットワークへの接続を有するコンピュータのうちの1つである方法において、前記方法は、
いくつかのデータ・フィールドを各々有する複数の電子ビジネス・カードを含む前記第1の装置のビジネス・カード・アプリケーションから、電子ビジネス・カードを検索するステップと、
前記ビジネス・カードを、前記移動通信ネットワークを介して前記第2の装置へ送信するステップと、
受信したビジネス・カードを、前記第2の装置のビジネス・カード・アプリケーション内に記憶するステップと、を備える方法。
【請求項2】
前記データ・フィールドは、前記第2の装置により認識され得るフィールド区切り符号によって分離される請求項1に記載の方法。
【請求項3】
前記電子ビジネス・カードは、少なくとも前記データ・フィールドの1つとして名称を有すると共に前記データ・フィールドの他の1つとして電話番号を有する請求項1に記載の方法。
【請求項4】
前記送信ステップは、前記ビジネス・カードをユーザ・メッセージで送信することを含む請求項1に記載の方法。
【請求項5】
前記ユーザ・メッセージは、該ユーザ・メッセージを電子ビジネス・カードであると特定する識別子を含み、受信したビジネス・カードは、前記識別子に基づいて前記第2の装置の前記ビジネス・カード・アプリケーションへアドレス指定される請求項4に記載の方法。
【請求項6】
無線通信のための手段を有する端末であって、
いくつかのデータ・フィールドを各々有する電子ビジネス・カードを記憶しておくメモリと、
移動通信ネットワークを介して電子ビジネス・カードを送信する手段と、
前記移動通信ネットワークを介して電子ビジネス・カードを受信して、受信した電子ビジネス・カードを前記メモリに記憶する手段と、を備える端末。
【請求項7】
前記電子ビジネス・カードをユーザ・メッセージにて送信する手段をさらに備える請求項6に記載の端末。
【請求項8】
前記ユーザ・メッセージは、ショートメッセージ、規格化SMSメッセージに従ったメッセージ、規格化Rデータフィールドメッセージに従ったメッセージ、規格化USSDメッセージに従ったメッセージ、規格化SOCメッセージに従ったメッセージ、及びワイヤレスパケット無線サービスに従ったメッセージのうちの1つである請求項7に記載の端末。
【請求項9】
前記ユーザ・メッセージは、アスキー(ASCII)文字を備える請求項6に記載の端末。
【請求項10】
前記ユーザ・メッセージは、該ユーザ・メッセージを電子ビジネス・カードであると特定する識別子を備える請求項6に記載の端末。
【請求項11】
前記端末は、移動通信ネットワークを介して通信することができる移動局、および前記移動通信ネットワークへの接続を有するコンピュータのうちの1つである請求項6〜10のいずれか一項に記載の端末。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2008−11569(P2008−11569A)
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願番号】特願2007−234656(P2007−234656)
【出願日】平成19年9月10日(2007.9.10)
【分割の表示】特願2004−46563(P2004−46563)の分割
【原出願日】平成9年2月21日(1997.2.21)
【出願人】(398012616)ノキア コーポレイション (1,359)
【Fターム(参考)】
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願日】平成19年9月10日(2007.9.10)
【分割の表示】特願2004−46563(P2004−46563)の分割
【原出願日】平成9年2月21日(1997.2.21)
【出願人】(398012616)ノキア コーポレイション (1,359)
【Fターム(参考)】
[ Back to top ]