(57)【特許請求の範囲】
【請求項１】
無線電話ネットワーク（１１０、１１１）を介してポケットサイズ携帯端末（７００）と接続され、かつ有線ネットワーク（１２０、１３０、１４０）を介してサーバ（５４２、５４３）と接続されるネットワークトランスレータ（５００）を含む双方向データ通信システムにおけるネットワーク・トランスレータ（５００）において、
該ネットワークトランスレータ（５００）は、該無線電話ネットワークを介して該ポケットサイズ携帯端末と通信する第１の通信インターフェース（１２０２）、該有線ネットワークを介して該サーバと通信をする第２の通信インターフェース（１２０３）、及びプロセッサ（１２０４）とからなり、そして該無線電話ネットワークを介して該ポケットサイズ携帯端末に提供する複数の関連ページからなる１グループを生成する機能を有し、
該プロセッサは、該無線電話ネットワークを介して該ポケットサイズ携帯端末からのリクエストを受信し、１つのリクエストに対して該無線電話ネットワークを介して該ポケットサイズ携帯端末に複数の関連ページからなる１グループを提供でき、
該ページの各々は該ポケットサイズ携帯端末により解釈されて、該ページ毎に該ポケットサイズ携帯端末上に別々の対話的ユーザインターフェーススクリーン表示を発生し、
前記関連ページからなるグループはユーザにより該ポケットサイズ携帯端末上で、該有線ネットワーク上のサーバ内のリソースに対する追加リクエストを発生することなく内部的に該グループの特定のページの選択表示の操作がされ得るものであり、
該ポケットサイズ携帯端末は該対話的ユーザインターフェーススクリーン表示の少なくとも１つから該有線ネットワーク上のサーバ内のリソースに対する追加リクエストを発生していることを特徴とする、ネットワークトランスレータ。
【請求項２】
請求項１に記載のネットワークトランスレータを含む双方向データ通信システムにおけるネットワークトランスレータにおいて、前記有線ネットワークはコンピュータネットワークであることを特徴とする、ネットワークトランスレータ。
【請求項３】
請求項１又は２に記載のネットワークトランスレータを含む双方向データ通信システムにおけるネットワークトランスレータにおいて、前記リソースはマークアップ言語リソースであり、そして、ネットワークトランスレータのプロセッサは前記ポケットサイズ携帯端末のインタプリターによる該リソースの簡易な構文解析が可能なように該リソースを変換していることを特徴とする、ネットワークトランスレータ。
【請求項４】
請求項１、２又は３に記載のネットワークトランスレータを含む双方向データ通信システムにおけるネットワークトランスレータにおいて、該ネットワークトランスレータは、ポケットサイズ携帯端末の情報である顧客データ（１２１３）、サーバの情報であるサーバデータ（１２１２）及び該ポケットサイズ携帯端末と指定されたサーバとの間の交信情報であるトランザクションデータ（１２１１）を有するデータベース（１２１０）を更に含むことを特徴とする、ネットワークトランスレータ。
【請求項５】
請求項２に記載のネットワークトランスレータを含む双方向データ通信システムにおけるネットワークトランスレータにおいて、前記コンピュータネットワークはインターネットであることを特徴とする、ネットワークトランスレータ。
【請求項６】
ネットワーク処理システム（ＡＮＴ）の動作を用いた双方向データ通信方法において、
該ネットワーク処理システム（ＡＮＴ）は、無線電話ネットワークを介してポケットサイズ携帯端末に提供する複数の関連ページからなる１グループを生成する機能を有し、該無線電話ネットワーク（１１０、１１１）を介して、該ポケットサイズ携帯端末（７００）からのリクエストを受信し、１つのリクエストに対して該無線電話ネットワークを介して複数の関連ページからなる１グループを該ポケットサイズ携帯端末に提供でき、該関連ページのグループについて該ポケットサイズ携帯端末上でユーザにより、有線ネットワーク（１２０、１３０、１４０）上のサーバ（１４１、５４２、５４３）にあるリソースへの追加リクエストを発生することなく内部的に該グループの特定のページの選択表示の操作がされるよう、該ページの各々は該ポケットサイズ携帯端末により解釈されて該ページ毎に該ポケットサイズ携帯端末上の別々の対話的ユーザインターフェーススクリーン表示を発生し、
該対話的ユーザインターフェーススクリーン表示の少なくとも１つから有線ネットワーク（１２０、１３０、１４０）上のサーバ（１４１、５４２、５４３）にあるリソースへの追加リクエストを該ポケットサイズ携帯端末が発生することができるようにしている双方向データ通信方法。
【請求項７】
請求項６に記載の方法において、前記有線ネットワークはコンピュータネットワークであることを特徴とする、ネットワーク処理システムの動作を用いた双方向データ通信方法。
【請求項８】
請求項７に記載の方法において、前記コンピュータネットワークはインターネットであることを特徴とする、ネットワーク処理システムの動作を用いた双方向データ通信方法。
【請求項９】
請求項６、７又は８に記載の方法において、前記リソースはマークアップ言語リソースであり、
ネットワーク処理システムが、前記ポケットサイズ携帯端末のインタプリターによる前記リソースの構文解析を簡易化するような変換を該リソースに行い、該変換されたリソースを該ポケットサイズ携帯端末へ送信していることを特徴とする、ネットワーク処理システムの動作を用いた双方向データ通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般にデータ通信に関し、特に、携帯電話機、双方向ページャー、及びユーザがコンピュータネットワーク上のサーバとインタフェースをとり、対話できるようにする電話を含む双方向データ通信デバイスに関する。
【０００２】
【従来の技術】
少なくとも過去５年以上にわたって、無線通信業界はコンピュータの使用と無線通信とを統合させることに努力を傾注してきた。この産業における幅広い努力により、一般的な電話機とともに、携帯電話機、双方向ページャー等の移動無線装置を含む電気通信装置にソフトウェアインテリジェンスを導入することが期待できることになった。
【０００３】
過去数年間にわたり、モトローラ、ＡＴＴ、ソニー、松下、フィリップス、及びＩＢＭ等のこの技術分野におけるいくつかの巨大企業が巨額の投資を行い、研究開発を行ってきたが、その成果は芳しいものではなかった。このような努力の成果であるインテリジェント通信デバイスには、典型的にはコンピュータ処理モジュールに必要不可欠なハードウェア及び無線通信モジュール用のハードウェアが含まれる。このような製品の例を挙げると、ＩＢＭ社及びBell South社が共同開発したSimon 、ソニー製のMagicLink 、及びモトローラ製のEnvoy 等がある。
【０００４】
このようなインテリジェント通信デバイスの設計者が採用したアプローチを直接の原因とする基礎的な設計上の問題及びコストの問題から、その市場の拡大には限界があった。無線通信モジュールとコンピュータ処理モジュールを組み合わせることにより、このデバイスの寸法は大きくなり過ぎ、コストは嵩み過ぎ、このデバイスは市場の要求に対処するには著しく柔軟性を欠くものとなった。
【０００５】
この２つのモジュールを組み合わせたデバイスは、ユーザのポケットに収めるには大き過ぎ、重過ぎる。小型であることは、移動通信装置市場における非常に重要な要請であって、前述のデバイスはこの要請を満たすものではない。
【０００６】
更に、これらのデバイスのコストは、コンピュータ処理モジュールのコストと通信モジュールのコストとの合計に近いものであって、それぞれのコストは消費者価格で１千ドル程度である。また、市場調査の結果が示すところによれば、インテリジェント無線通信デバイスの市場における適切な価格は３００ドル内外である。たとえ毎年２０％価格を引き下げても、両モジュールの組み合わせの価格が現在の消費者の要求する水準に達するには５年かかることになる。従って、コンピュータと無線モジュールを組み合わせたこのデバイスでは、いかに小型化し、価格を下げようとも、この１０年間で価格についての市場の要求を満たすことは困難である。
【０００７】
市場価格の面で成功を収めるためには、インテリジェント無線通信デバイスは、各市場区分に合わせたさまざまなアプリケーションの支援が可能でなければならない。典型的には、消費者がデバイスの購入後に、これらのアプリケーションをデバイスに付加できなければならない。従って、このデバイスは、初期アプリケーションをロードし、更にそのアプリケーションを更新する方法を提供するものでなければならない。
【０００８】
インテリジェント通信デバイスの価格感受性及びサイズの制限が意味するのは、インテリジェント通信デバイスが、コンピュータにおいて一般にみられる主メモリ（ＲＡＭ）、ハードディスクまたは書き換え不能メモリ、若しくは旧来のフロッピーディスクドライブの容量を支援できないということである。このような限界により、インテリジェント通信デバイスに、新たなアプリケーションをロードし、またはアプリケーションの更新を行う道が閉ざされることになる。
【０００９】
この結果、インテリジェント通信デバイスの現時点での成果は、工場で書込んだアプリケーション、またはスロットに差し込んで使用するＲＯＭカードに書込まれたアプリケーションをいくつか走らせることしかできない。このスキームは、市場の多種多様な要求に対処するのに必要な多くのアプリケーションを走らせるのに必要な柔軟性を欠いており、デバイスの販売後にアプリケーションを更新する方法が皆無である。
【００１０】
電話に対するインテリジェンス機能付加指向の他の通信技術を２つ挙げると、Short Messaging Service（ＳＭＳ）と、Analog Display Service Interface（ＡＤＳＩ）とがある。ＳＭＳは、携帯電話間でどのようにメッセージが行き来しているか、及び携帯電話機がどのようにメッセージを格納すべきかを規定する。ＳＭＳは、メッセージに埋め込まれた電話番号の呼出しのような、携帯電話機がメッセージ上で実行し得るいくつかの簡単な処理も定めている。
【００１１】
ＳＭＳのアーキテクチャはページングネットワークのものと類似しており、異なる点は、ＳＭＳアーキテクチャを実現するデバイスが携帯電話ネットワークの制御チャネル上で動作するという点である。ＳＭＳは、初めにヨーロッパにおいてＧＳＭネットワーク上で配備された。
【００１２】
ＳＭＳメッセージはリアルタイムで届けられない。待ち時間は３０秒から１０分であって、このためＳＭＳはリアルタイムで動作するアプリケーションには適さないものとなっている。ＳＭＳの主たる目的は、メッセージの送達である。ＳＭＳは、アプリケーションプロトコルまたは携帯電話アプリケーションモジュールについては規定しておらず、このため携帯電話機上でアプリケーションを走らせることに関しても有用性が限定されてしまう。ヨーロッパにおいて２、３年配備された後、ＳＭＳのインプリメンテーションは、双方向ページング通知サービス及び音声メール通知サービスのような通知サービスに、その使用範囲が限られることになった。
【００１３】
媒体としてのＳＭＳは、情報の検索、編集、及び格納が可能なアプリケーションの構築には適さない。このため、業界の大企業は、携帯電話機にインテリジェンス機能を付加する技術の開発のなかで、ＳＭＳには目を向けず、一貫してコンピュータモジュールと無線通信モジュールとの統合を目指してきたのである。
【００１４】
ＡＤＳＩは、Interactive Voice Responce Systemsの拡張機能として設計された。ＡＤＳＩによって、小型のディスプレイを備えた情報処理機能付（smart）電話機において、ユーザのオプション選択の補助となるプロンプトの表示が可能になる。使用勝手の悪い音声プロンプトの代わりに目で見ることのできるプロンプトを使用することにより、ＡＤＳＩがインタラクティブ音声サービスの使用を簡単かつ迅速にするものと思われた。
【００１５】
ＡＤＳＩにより、サービスプロバイダから情報を電話機に送り、そこでスクリーン上に表示することが可能になる。また、ＡＤＳＩにより、電話機において、押しボタンを押して、全て英数字文字で記述された特定の符号の信号を送ることを通して応答することが可能になる。ＡＤＳＩでは、電話機は主として受動装置として使用される。サービスプロバイダは電話機にテキストスクリーンデータを送り、電話機はテキストスクリーンから作られたユーザの選択を示す短い列データを返送する。
【００１６】
ＡＤＳＩでは、電話機において処理を行う機能は設けられていない。この結果ＡＤＳＩでは、各ユーザの入力が処理のためにサービスプロバイダに返送されることから、電話回線網上でのトラヒックが大きくなる。このため少なくて貴重なバンド幅を利用する無線ネットワークには、ＡＤＳＩは適さない。また、“電波の効率的利用（air efficiency）”は最も求められている特質の１つである。ＡＤＳＩは電話機側に処理能力がなく大きなバンド幅を必要とするため、業界においては、これをインテリジェント無線通信デバイスに用いることは考えられなかった。
【００１７】
現在に至るまで、インテリジェント通信デバイスは、コンピュータ処理モジュールと無線通信モジュールとの統合という形で実現されてきた。しかし、このようなデバイスが広く使用されるようにするために、処理能力及びさまざまな異なるユーザのアプリケーションを走らせる能力を備えた双方向データ通信デバイスが必要である。更に、そのようなデバイスは、携帯電話機に匹敵するサイズ及び重量を有するものであるべきである。
【００１８】
【発明が解決しようとする課題】
従って、本発明の主な目的は、携帯電話機、双方向ページャー等の軽量の移動式双方向データ通信デバイスをクライアントとして使用可能な双方向データ通信ネットワークシステムを提供することである。
【００１９】
【課題を解決するための手段】
本発明の原理により、コンピュータ処理モジュールと無線通信モジュールとの統合スキームにおいて生じた従来技術の限界が克服される。特に、本発明による携帯電話機、双方向ページャー、または電話機等の双方向データ通信デバイスは、双方向データ通信ネットワークを通してサーバコンピュータとの通信を行うクライアントモジュールを有している。本発明の原理は、さまざまな双方向データ通信ネットワークと共に用いることができる。例えば、携帯電話機用の双方向データ通信ネットワークには、ＴＤＭＡ、ＣＤＭＡ、及びＧＳＭ回路データ交換網に加えて、セルラーデジタルパケットデータネットワーク（ＣＤＰＤネットワーク）や、モデムと共に用いられるＡＭＰＳアナログセルラーネットワークが含まれる。同様に、双方向ページャーについては、この双方向データ通信ネットワークは、ＡＴＴ社の承認した新たな双方向ページング規格であるＰＡＣＴ、若しくはデータ処理対応型の他の有線式双方向ページングネットワークを含む。このような、電話と共に用いられる双方向データ通信ネットワークは、公的な電話交換網である。
【００２０】
クライアントモジュールを備えた双方向通信デバイスを用いることにより、ユーザはサーバコンピュータに情報を供給し、サーバコンピュータの情報を取出し、サーバコンピュータ上のアプリケーションにそこで用いられるデータを供給し、その双方向通信デバイスに情報を供給し、若しくは他の場所に情報を送ることができる。つまり双方向通信デバイスのユーザにとっての機能的な面での制約は、双方向データ通信ネットワーク上でユーザがアクセスできるサーバコンピュータ上で使用可能なアプリケーションによってのみもたらされることになる。
【００２１】
本発明により、携帯電話機、双方向ページャー、及び電話機のような双方向通信デバイスが、初めてアプリケーションプラットホームに対して開かれ得るようになった。このアプリケーションプラットホームにおいて、ソフトウェア開発者は、本発明の原理を組み入れた双方向通信デバイスに対して、付加価値アプリケーションやサービスを与えることができる。これは、電話や双方向ページャーが閉じられた個人所有のシステムである現在の状態と比較すれば大きな変化である。この結果、双方向通信デバイス及び双方向通信ネットワークの新たな使用方法を考案する場が市場に対して形成されることになる。企業から個人に至る任意のエンティティが、本発明を組み込んだ双方向データ通信デバイスにインストールし使用することのできる新たなアプリケーションを、物理的な変形若しくは別の双方向通信装置の追加を行うことなく作成することが可能となる。デバイス購入後、数年を経ても、本発明を組み込んだ双方向通信デバイスは、その購入後に開発された全てのアプリケーションを走らせることも可能となるのであ。
【００２２】
更に、これらの全てのアプリケーションは、エンドユーザが双方向通信デバイスに何物かを追加したり、または何らかの変形を施すことなく使用することができる。また、アプリケーションは双方向データ通信ネットワークからは独立している。このアプリケーションは、双方向データ通信ネットワークの特性から独立しているのである。従って、これらのアプリケーションは、双方向データ通信ネットワークで起こった変化に影響を受けないことになる。
【００２３】
また、サーバコンピュータ上のアプリケーションは、サーバコンピュータが通信を行う双方向データ通信デバイスから独立している。サーバコンピュータ上のアプリケーションは、本発明のクライアントモジュールと双方向データ通信ネットワークからデータを受け取ることができ、かつ、データを伝送するためのネットワークインタフェースモジュールとを含む双方向データ通信デバイスと通信を行うことができる。これらの２つの特徴は、アプリケーションの開発のための投資の効果が、双方向データ通信デバイスの進歩、または双方向データ通信ネットワーク技術の進歩の何れからも独立して発揮されることを意味している。
【００２４】
上述のように、本発明の双方向データ通信デバイスは、クライアントモジュールを用いて、ユーザにより選択されたリソースの位置情報であるリソースロケータを含むメッセージを、コンピュータネットワーク上の双方向データ通信ネットワークを通して、コンピュータネットワーク上のサーバコンピュータ上のサーバに伝送する。例えば、コンピュータネットワークは、ワイドエリアネットワーク、ローカルエリアネットワーク、インターネット、または任意のコンピュータネットワーク同士の組み合わせであり得る。
【００２５】
サーバはメッセージを処理する。例えば、リソースロケータによってアドレス指定されたアプリケーションを実行したり、双方向データ通信ネットワークを通して双方向データ通信デバイスに応答を送りその双方向データ通信デバイスのメモリにその応答が格納されるようにする。クライアントモジュールはその応答を翻訳し、その応答内の情報を用いてユーザインタフェースを生成する。一実施例においては、このユーザインタフェースは少なくとも１つの、リソースロケータに関連するユーザデータ入力オプションを含む。別の実施例では、ユーザインタフェースはディスプレイに表示される。
【００２６】
少なくとも１つのユーザデータ入力オプションに関連するこのリソースロケータは、様々なオブジェクトの任意の１つをアドレス指定することができる。一実施例では、少なくとも１つのユーザデータ入力オプションに関連するこのリソースロケータは応答を転送するサーバコンピュータ上のオブジェクトをアドレス指定する。別の実施例では、このリソースロケータは双方向データ通信ネットワークに接続された他のサーバコンピュータ上のオブジェクトをアドレス指定する。更に別の実施例では、このリソースロケータは双方向通信デバイス内に格納されたオブジェクトをアドレス指定する。
【００２７】
ユーザが少なくとも１つのユーザデータ入力オプションを選択したとき、クライアントモジュールはその選択を翻訳して、必要ならば、その少なくとも１つのユーザデータ入力オプションに関連するリソースロケータへ任意の入力データを追加する。このクライアントモジュールは、任意の追加された入力データを有するリソースロケータを含むメッセージを、サーバコンピュータに伝送する。別の形態として、任意の追加されたデータを有するリソースロケータが、別のサーバコンピュータにアドレス指定され得るもの、若しくは双方向通信デバイス内に格納されたオブジェクトにアドレス指定するものがある。リソースロケータがサーバコンピュータ上のオブジェクトをアドレス指定した場合、クライアントモジュールはメッセージをネットワークインタフェースモジュールに送り、ここでそのメッセージは双方向データ通信ネットワークに伝送される。
【００２８】
従って、この実施例においては、双方向データ通信デバイスに初めに伝送されたメッセージには、クライアントモジュールがユーザインタフェースを発生し、ユーザの選択及び任意の入力データを特定のリソースロケータに関連付け、更にその適当なリソースロケータを次のメッセージとともに伝送するのに必要な全ての情報が含まれている。クライアントモジュールはメッセージ内の情報を処理するインタプリタを含んでいる。このメッセージがクライアントモジュールが必要とする全ての情報を含んでいたことから、メッセージを伝送したサーバコンピュータは、そのメッセージに関連する状態情報を保持していない。従って、サーバコンピュータは無状態サーバコンピュータとして定義される。
【００２９】
本発明の重要な側面は、クライアントモジュールがユーザインタフェースを発生するのに必要な全ての情報を含んでおり、特定のユーザインタフェースが他のユーザインタフェースとは無関係であり得るということである。そこからの選択を行う所定のメニューをユーザに与え、若しくはユーザが使用可能なフォーマットが電子メール上のものに限定されていた従来技術と異なり、本発明の原理によれば、ユーザインタフェース及びユーザが実行できる対話は、その開発者が使用可能にしたアプリケーションのみによって決まる。１つのアプリケーションにおける実行可能な対話及び使用されるユーザインタフェースは、他のアプリケーションにおける実行可能な対話及び使用されるユーザインタフェースとは全く異なっており、無関係なものであり得る。従って、携帯電話機、双方向ページャー、及び電話機は全てプラットフォームに対して真の意味で開かれた状態となる。
【００３０】
本発明のこれらの特徴は、従来技術のシステムから著しい進歩をもたらすものである。典型的には、従来技術においては、特定のプラットフォーム上で特定のアプリケーションを使用するためには、そのアプリケーションがプラットフォーム上のオペレーティングシステムと互換性を有することが必要であった。更に、アプリケーションのバージョンが更新される度に、ユーザはそれまでのアプリケーションの使用をやめて、ユーザのプラットホーム上でのアプリケーションの更新を行う必要があった。更に、そのプラットホームのユーザがオペレーティングシステムのバージョンの更新時にオペレーティングシステムを変更しなかった場合、そのプラットホームは、現在のバージョンのオペレーティングシステムが必要な新しいバージョンのアプリケーションの処理を行うことができなくなった。本発明により、このような問題はなくなる。前に説明したように、双方向データ通信デバイス上のクライアントモジュールはインタプリタとして機能する。サーバコンピュータ上のアプリケーションが、このインタプリタが双方向データ通信デバイス上にユーザインタフェースを発生し、ユーザの選択またはユーザインタフェースを用いたデータの入力に応答してメッセージを適当なサーバ、例えば元々の情報を送信したサーバ若しくは他のサーバに送るのに必要な全ての情報を供給する。
【００３１】
従って、クライアントモジュールはこの情報を翻訳し、双方向データ通信デバイスのハードウェアと適当な対話することのみを行う。この結果、アプリケーションの更新には、サーバコンピュータ上の変更のみが必要となり、サーバコンピュータとやり取りする双方向データ通信デバイスのそれぞれは変える必要がない。本発明は、アプリケーションソフトウェアの配布の通常の必要性を無くし、かつ双方向データ通信デバイスのエンドユーザがアプリケーションソフトウェアの更新をする必要が無くなる。
【００３２】
一実施例においては、サーバコンピュータと、携帯電話機、双方向ページャー、及び電話からなるグループから選択された１つの双方向データ通信デバイスとの間の双方向データ通信システムは、双方向データ通信ネットワーク、双方向データ通信ネットワークに接続されたサーバコンピュータ、及び双方向データ通信ネットワークに接続された双方向データ通信デバイスを含む。このサーバコンピュータは、双方向データ通信ネットワークに接続された双方向データ通信インタフェースモジュール、及び双方向データ通信インタフェースモジュールに接続されたサーバを有する。このサーバは、双方向データ通信ネットワークからのリソースロケータを含むメッセージを受け取る。このリソースロケータは、サーバコンピュータ及びそのサーバコンピュータ上のアプリケーションのアドレスを有している。このサーバは、リソースロケータを用いてこのメッセージを処理する。この実施例においては、サーバはメッセージに対する応答を双方向データ通信ネットワークを通して伝送する。
【００３３】
携帯電話機、双方向ページャー、及び電話機からなるグループから選択された双方向データ通信デバイスは、双方向データ通信ネットワークに接続されたネットワークインタフェースモジュール、及びネットワークインタフェースモジュールに接続されたクライアントモジュールを有する。クライアントモジュールはリソースロケータを含むメッセージを双方向データ通信ネットワークを通してサーバに伝送した。クライアントモジュールは、サーバからのメッセージに対する応答の処理も行う。この応答は、双方向データ通信ネットワーク上でのユーザの対話のための情報を含む。
【００３４】
本発明のクライアントモジュールは軽量で、従って双方向データ通信デバイスにおけるリソースも軽量なものとなる。この結果、クライアントモジュールは、このようなデバイスにおいて存在するリソースを用いることが可能となり、従って双方向データ通信デバイスのコストを高めることはない。
【００３５】
一実施例においては、クライアントモジュール内のインタプリタは、双方向データ通信デバイスのディスプレイに接続されたユーザインタフェースマネージャを含む複数のマネージャを有する。このユーザインタフェースマネージャは双方向データ通信デバイスにおいてディスプレイとの対話を取り扱う。ユーザインタフェースマネージャは、双方向データ通信デバイスのキーパッドにも接続されており、キーパッドとの対話の取り扱いも行う。ここで、キーパッドは電話用キーパッド、双方向ページャーにみられるキー、若しくは双方向データ通信デバイスの他のデータ入力インタフェースであり得る。
【００３６】
一実施例においては、サーバコンピュータで生成された応答は、複数のリソースロケータを含み、複数のリソースロケータのうち少なくとも１つは通信ネットワークに接続された他のサーバのアドレスを有する。
【００３７】
本発明の原理によれば、サーバコンピュータと通信を行うべく携帯電話機、双方向ページャー、及び電話機からなるグループから選択された双方向データ通信デバイスを使用する方法であって、
双方向データ通信ネットワークに接続された前記双方向データ通信デバイスのユーザによって入力されたデータに応じて、前記双方向データ通信デバイスのマイクロコントローラ上で動作するクライアントモジュールにより、サーバコンピュータを特定するリソースロケータを含むメッセージを発生する過程と、
前記メッセージを、前記双方向データ通信デバイスを通して前記サーバコンピュータへ伝送する過程と、
前記メッセージに対する応答を生成すべく、前記サーバコンピュータ上のアプリケーションを実行する過程と、
前記応答を、前記アプリケーションにより特定されたロケーションへ伝送する過程とを有することを特徴とする、サーバコンピュータと通信を行うべく携帯電話機、双方向ページャー、及び電話機からなるグループから選択された双方向データ通信デバイスを使用する方法が提供される。
【００３８】
上述のように、前記ロケーションは双方向データ通信デバイス、他のサーバコンピュータ、若しくは前記サーバコンピュータに接続された他のデバイスであり得る。
【００３９】
【発明の実施の形態】
本発明の原理によれば、新規な無線通信ネットワーク１５０、即ち双方向データ通信ネットワークが、それぞれ本発明の機構を含む双方向データ通信デバイス１００、１０１、若しくは１０２の何れか１つ、または何れか２つの組み合わせ、あるいはその全てと、様々なコンピュータネットワーク１２０、１３０、及び１４０とを相互接続する実施例が考えられる。後に詳述するように、各データ通信デバイス１００、１０１、及び１０２は、コンピュータネットワーク１２０、１３０、及び１４０上のコンピュータ群の所望の組み合わせとのデータのやり取りができるように構成され得る。無線通信ネットワーク１５０は、双方向データ通信デバイスから双方向データ通信デバイスのユーザがアクセスする特定のコンピュータへの双方向データ通信経路をなす。
【００４０】
本発明の機構を含む各無線通信デバイス１００は、無線通信ネットワーク（airnet network）１５０を通して、デバイス１００内に備えられた本発明のプロセスと通信若しくは対話する少なくとも１つのアプリケーションを含む、無線通信ネットワーク１５０上のサーバコンピュータ１２１、１３１、及び１４１と通信を行うことができる。従って、デバイス１００はコンピュータネットワーク上の情報にアクセスし、かつコンピュータネットワークに情報を提供することができる。同様に、本発明の機構を備えた双方向ページャー１０１、及びモデム１０３を備えた電話機１０２も、無線通信ネットワーク１５０を通して、デバイス１０１及び１０２内に備えられた本発明のプロセスとの通信及び対話を行う少なくとも１つのアプリケーションを含むサーバコンピュータ１２１、１３１、及び１４１と通信を行うことができる。
【００４１】
後に更に詳述するように、サーバコンピュータ上のアプリケーションは、サーバコンピュータと通信可能な任意の双方向データ通信デバイスがアクセスすることができる。このアプリケーションは、それにアクセスするのに用いられる双方向データ通信デバイスの特定のタイプを選ばず、かつ用いられる特定の双方向データ通信ネットワークからも独立している。このことは、ユーザがサーバコンピュータと通信可能な双方向データ通信デバイスを有している限り、ユーザはどこからでもアプリケーションにアクセスできるということを意味している。
【００４２】
一実施例においては、無線通信デバイス１００上のプロセスは、クライアントプロセスとして構成されており、クライアントプロセスとやり取りを行う無線通信ネットワーク１５０上のサーバコンピュータ１２１、１３１、及び１４１上のアプリケーションはサーバプロセスである。このようなアーキテクチャにより、いくつかの処理を携帯電話機１００から、無線通信ネットワーク１５０を介して、無線通信ネットワーク１５０上の任意のコンピュータ上のサーバモジュールへと移動させることが可能となる。
【００４３】
具体的には、例えば、携帯電話機のような無線通信デバイス１００で、電話機上のキーパッドを備えたものが、データ対応型携帯電話ネットワーク１１０、例えばセルラーデジタルパケットデータ（ＣＤＰＤ）電話回線を介して、データ対応型携帯電話ネットワーク１１０に対するインタフェースを有するコンピュータネットワーク上のサーバコンピュータ上のアプリケーションと通信を行うのである。例えば、このコンピュータネットワークは、一つの会社内に設けられたネットワークであり得る。
【００４４】
同様に、双方向ページャー１０１は、双方向ページャーネットワーク１１１を介して、双方向ページャーネットワーク１１１に対するインタフェースを有するコンピュータネットワーク上のサーバコンピュータ上のアプリケーションと通信を行う。また、例えば、このコンピュータネットワークは、ワイドエリアネットワーク１２０、ローカルエリアネットワーク１３０、若しくはインターネット１４０であり得る。最後に、電話機１０２は、モデム１０３及び好適な電話交換網１１２を介して、好適な電話交換網１１２に対するインタフェースを有するコンピュータネットワーク上のサーバコンピュータ上のアプリケーションと通信を行う。他の双方向データ通信デバイスの場合のように、このコンピュータネットワークは、例えば、ワイドエリアネットワーク１２０、ローカルエリアネットワーク１３０、若しくはインターネット１４０であり得る。
【００４５】
双方向データ通信デバイス１００、１０１、及び１０２のそれぞれにおいて、クライアントプロセスは、デバイス内のクライアントモジュールとして格納され、デバイス内のマイクロコントローラ上でのクライアントモジュールの実行は、クライアントプロセスと称されることがある。このクライアントプロセスは、重要な処理関数をローカルに実行する。これによって、以下単にクライアントと称することもあるクライアントプロセスと、以下単にサーバと称することもあるサーバプロセスとの間の通信が最小限となり、サーバに対するコンピュータ処理の要求の増加率が、クライアント、例えばユーザの数の増加量に対して緩慢なものとなる。
【００４６】
クライアントモジュールは例えば６４キロバイト以下の小さなものであり、必要とする処理能力が、携帯電話機１００、双方向ページャー１０１、及び電話機１０２のような双方向データ通信デバイスにおける組み込まれたマイクロコントローラ及びメモリチップに相当する小さな処理能力で済む。従って、従来技術のインテリジェント電話機の場合と異なり、携帯電話機、双方向ページャー、若しくは電話機の何れも、本発明を組み込むことでそのコスト、サイズ、及びバッテリの寿命が悪影響を受けない。
【００４７】
クライアント／サーバアーキテクチャはコンピュータネットワークにおいて広く用いられてきたが、携帯電話機１１０、双方向ページャー１０１、若しくは電話機１０２のような双方向データ通信デバイスを用いて実現されるクライアント／サーバアーキテクチャは、期待以上の新しい効果を生み出す。本発明により、必ずしもこれらに限られるものではないが、携帯電話機、双方向ページャー及び電話機を含む様々な双方向データ通信デバイスが、初めてアプリケーションプラットホームに対して開かれることになり、このアプリケーションプラットホームにおいて、ソフトウェア開発者が、付加価値アプリケーション及びサービスを、本発明の原理を組み込んだ双方向データ通信デバイスに対して供給することができるようになった。
【００４８】
これは、携帯電話機、双方向ページャー及び電話機が閉じられた個人所有のシステムである現状からの大きな変化がもたらされるということである。この結果、携帯電話機及びデータ処理対応型携帯電話ネットワークや、双方向ページャー及び双方向ページャーネットワークや、好適な交換網上の電話機の新たな使用方法を考案する場が、市場に対して形成されることになる。
【００４９】
企業から個人に至る任意の存在が本発明を含むデータ処理対応型携帯電話機、双方向ページャー及び電話機にインストールされ使用することのできる新たなアプリケーションを作成することが可能となる。デバイス購入後数年を経ても、本発明を組み込んだ双方向データ通信デバイスはその購入後に開発された全てのアプリケーションを走らせることができるのである。更に、これら全てのアプリケーションは、ユーザが双方向データ通信デバイスに何物かを追加したり、または何らかの変更を加えることなく使用することができる。本発明のこのような特徴は、従来技術のシステムからの著しい進歩をもたらす。典型的には、従来は、特定のプラットホーム上で特定のアプリケーションを使用するためには、そのアプリケーションがプラットホーム上のオペレーティングシステムと互換性を有することが必要であった。更に、アプリケーションの新バージョンが出てくる度に、ユーザは、ユーザのプラットホーム上のアプリケーションを更新する手間をとる必要があった。更に、プラットホームのユーザがオペレーティングシステムを新しいバージョンのものに変更しなかった場合は、しばらくすると、そのプラットホームではオペレーティングシステムの現在バージョンに対応する新しいバージョンのアプリケーションを処理することが不可能になっていた。
【００５０】
また、携帯電話機若しくはページャーのような小型のデバイスは、カード用スロット、フロッピーまたはハードディスクドライブ、若しくは他のアプリケーション追加若しくは更新用のコンピュータに一般にみられる手段を有していないのが普通である。このため、従来では、インテリジェント通信デバイスは、固定機能の閉じられたシステムにならざるを得なかった。このようなデバイスは、市場の要求の急激な変化を取り入れることも、または取り入れられることもできず、市場における成功を望めるようなものではなかった。
【００５１】
本発明によりこれらの問題がなくなる。双方向データ通信デバイスにおけるクライアントプロセスは、インタプリタとして機能する。サーバコンピュータ上のアプリケーションは、このインタプリタが双方向データ通信デバイス上にユーザインタフェースを発生し、かつこのユーザインタフェースを用いたユーザの選択若しくはデータ入力に応じて、適当なサーバ、例えばもとの情報を送ってきたサーバまたは他のサーバにメッセージを送るのに必要な全ての情報を供給する。
【００５２】
従って、クライアントプロセスは、この情報を翻訳し、双方向データ通信デバイスのハードウェアと適当な対話を行うだけですむ。この結果、アプリケーションの更新には、サーバコンピュータ上での変化のみが必要となり、サーバコンピュータと通信を行う各双方向データ通信デバイスにおける変更は一切必要なくなる。本発明により通常のアプリケーションソフトウェアの配布の必要性がなくなり、かつ双方向データ通信デバイスのエンドユーザがアプリケーションソフトウェアを更新する必要がなくなる。
【００５３】
例えば、双方向ページャー１０１がワイドエリアネットワーク１２０上のサーバコンピュータ１２１上のアプリケーションからメッセージに対する応答を受け取った場合は、双方向ページャー１０１におけるインタプリタがそのメッセージ内の情報を用いてディスプレイスクリーン１０６上にユーザインタフェースを発生する。後により詳しく述べるように、ユーザインタフェース内のオプションにより、ユーザが情報にアクセスし、ネットワーク１２０、１３０、及び１４０の何れか１つ、または何れか２つの組み合わせ、若しくはその全てに対し情報を供給することが可能となる。
【００５４】
具体的には、双方向ページャー１０１からのメッセージに対する応答において、サーバコンピュータ１２１上で初めにアクセスされるアプリケーションは、各ネットワーク１２０、１３０、１４０上のアプリケーションに対するリソースロケータを含んでおり、このリソースロケータは典型的には共通ゲートウェーインタフェースプログラムであって、ユーザインタフェースを生成するのに必要な情報と共にページャー１０１のユーザがアクセス可能なプログラムである。即ち、ユーザが特定の選択を行うかデータの入力を行ったとき、インタプリタは適当なリソースロケータにアクセスし、任意の必要なデータをリソースロケータに追加する。クライアントはリソースロケータを含むメッセージを適当なサーバへ転送する。
【００５５】
この例によって示されるように、ネットワーク１２０、１３０、及び１４０上のアブケーションはユーザインタフェースを発生し、全てのユーザ入力を処理するのに必要な全ての情報を双方向データ通信デバイスに送る。この結果、双方向データ通信デバイスに供給される情報を更新するのに、変更が必要なのはアプリケーションのみということになる。
【００５６】
更に、クライアントがユーザインタフェースを生成するのに必要な全ての情報、及びクライアントプロセスが、任意の入力データに対して応答するのに必要な全ての情報がメッセージの中に含まれていることから、コンピュータサーバはクライアントプロセスに伝送された情報に関連する任意の状態（state ）情報を保持しない。従って、コンピュータサーバは無状態（stateless ）である。
【００５７】
無線通信ネットワーク１５０を利用する双方向データ通信デバイス１００、１０１、及び１０２のそれぞれは、データ通信能力を有し、好ましくは多段式であるディスプレイスクリーンを備え、本発明のプロセス及び処理されるメッセージをオンボードメモリ内に記憶しておく能力を有する。例えばセルラーデジタルパケットデータ（ＣＤＰＤ）ネットワークを利用する電話機のようなデータ処理対応型携帯電話機のほとんど全ては、過大なオンボードメモリ能力及び多段式ディスプレイスクリーンを有している。このようなハードウェアリソースは可用であるが、メモリチップパッケージの不可分性のためにデータ処理対応型携帯電話機では使用されないことが多い。従って、このような携帯電話機に本発明のプロセスを組み込んだとしても、携帯電話機のコスト、サイズ、及び電力消費にはほとんど影響を与えることはない。同様に、マイクロコントローラ及びメモリを有する双方向ページャー及び電話機に、本発明のプロセスを組み込んだとしても、これらのデバイスのコスト、サイズ、及び電力消費にはほとんど影響を与えることがない。
【００５８】
従って、１つのパッケージ内においてコンピュータモジュールと無線通信モジュールとを結合しようとした従来のアプローチと異なり、本発明のこの実施例では、好ましくは、携帯電話機１００、双方向ページャー１０１、電話機１０２、若しくは他の無線または有線式双方向データ通信デバイス内に既に存在するメモリ及び処理能力を利用している。この方法を採用することにより、完成したデバイスのコストは制限され、従来技術のデバイスの方法で生じた多くの問題点を克服できる。例えば、双方向データ通信デバイスのサイズ及び重量に変化はなく、前に説明したように、携帯電話機１００、双方向ページャー１０１、及び電話機１０２においてユーザアプリケーションを更新する必要がなくなる。
【００５９】
特に、従来のように、コンピュータ処理モジュールと無線通信機モジュールとを結合することによって、製造されたデバイスとは異なり、本発明を組み込んだ双方向データ通信デバイスは一般の音声通信のみの電話機に匹敵するサイズ及びコストであり、インテリジェント携帯電話機に対し市場で求められている、例えばコスト及びサイズについての要求を初めて満たすことができる。
【００６０】
携帯電話機１００、双方向ページャー１０１、及び電話機１０２上の対話式アプリケーションをサポートするためのコストの上昇は、せいぜい、ユーザにアプリケーションを表示するのに必要なやや大きめのスクリーンにかかるコスト程度に抑えられる。これは、例えば携帯電話機に完全なコンピュータモジュールを追加するのにかかるコストのごく一部分である。
【００６１】
本発明をサポートするのに必要な電力消費の増加もごくわずかであって、メモリ及びスクリーンを大きくするのに必要な電力消費の増加量は、セルラー無線装置自体にかかる電力消費に比較してごくわずかである。本発明の原理に基づくインテリジェント双方向データ通信デバイスは、例えば一般的な携帯電話機または双方向ページャーと比較してバッテリ寿命の著しい短縮も起こり得ない。
【００６２】
双方向データ通信デバイス１００、１０１、及び１０２におけるクライアントプロセスの構成及び処理は、デバイスが通信を行う双方向データ通信ネットワーク及びデバイス自体の相違を考えれば、類似したものといえる。従って、以下の説明においては、データ処理対応型携帯電話機１００の動作を例にとって考えるものとする。同様の若しくは類似した動作は、双方向データ通信デバイス１０１及び１０２の上でも実行され得る。主な相違点は、クライアントモジュール内のデバイス固有の特徴のいくつかを、双方向通信デバイス内で使用される特定のハードウェアを受容できるように変更しなければならない点である。しかし、本発明のクライアントモジュールアーキテクチャでは、後に詳細に述べるように、行わなければならない変更の数を限られたものにしている。
【００６３】
上述のように、ユーザが与える処置に応答して、無線通信デバイス１００はメッセージ、典型的にはデータリクエストをコンピュータネットワーク１２０上のサーバコンピュータ１２１に送り、そのメッセージに対する応答を受け取る。別の形態として、ユーザが与える処置により、コンピュータネットワーク１２０上のサーバコンピュータ１２１に対して、メッセージに対する応答を他のロケーションまたは他のユーザに送るように指示を与えられることもあり得る。また、無線通信デバイス１００は、無線通信ネットワーク１５０に接続されたコンピュータの任意の１つからのメッセージを受け取ることもできる。
【００６４】
本発明の重要な側面は、無線通信デバイス１００におけるクライアントモジュールインタプリタが、ユーザインタフェースを発生し、これによりユーザが初期化や、様々なアプリケーションからのメッセージを受け取るようにすることができるという点である。対話はリアルタイムで行われ、クライアントモジュールインタプリタによって制限を受けない。無線通信デバイス１００の使用が制限されるのは、サーバコンピュータ上のアプリケーションの可用性のみによる。
【００６５】
使用可能なアプリケーションは、アプリケーションの開発者によって決定される。本発明の一実施例をより詳細に論ずる前に、本発明の原理に基づき実現されうるアプリケーションの例をいくつか説明したい。これらのアプリケーションは、本発明の説明のみを目的として記述されるものであり、本発明の範囲をここに記述される特定のアプリケーション及び機構に限定しようとするものではない。１つの使用例をあげると、ユーザは携帯電話機１００がＸＹＺ社のワイドエリアネットワーク１２０上のサーバコンピュータ１２１にアクセスできるようにその携帯電話機を設定する。ユーザからのアクセスに応じて、サーバコンピュータ１２１は、データ処理対応型携帯電話ネットワーク１１０を介して携帯電話機１００にカードデック（card deck ）を転送する。後に詳細に述べるように、カードデックは１または２以上の、処理及び表示データのパッケージであるカード（card）を有し、各カードはクライアントモジュールによって翻訳されて、ユーザインタフェーススクリーンが生成される。
【００６６】
図２Ａに示された実施例においては、携帯電話機１００に伝送された最初のカードデックには、内容紹介表示カード及び選択カード（choice card ）が含まれる。図２Ａは、携帯電話機１００内のクライアントプロセスは表示カードを翻訳することによってディスプレイスクリーン１０５上に生成された内容紹介スクリーンディスプレイ２００の一例である。ここで用いられているように、ディスプレイスクリーンは双方向データ通信デバイスにおける物理的ディスプレイ装置である。スクリーンディスプレイはディスプレイスクリーン上に映像を提示する。
【００６７】
この実施例においては、ディスプレイスクリーン１０５はグラフィックスを表示する画素ディスプレイである。別の実施例においては、ディスプレイスクリーン１０５はテキストのみを表示し、グラフィックスはディスプレイスクリーン１０５上には表示されない。スクリーンディスプレイ２００及び後に詳細に説明する他のスクリーンディスプレイは、水平方向の矢印、即ち現在デックが別のカードを有していることをユーザを示すマルチカードデックインディケータを含む。ユーザとのやり取りを行うためのマルチカードデックインディケータのようなスクリーンインディケータは所望に応じて設けられる。本発明の機能性はこのようなスクリーンインディケータとは無関係である。
【００６８】
ユーザが所定のキーを押した場合、若しくは所定のキーシーケンスを押したとき、携帯電話機１００内のクライアントプロセスがカードデック内の次のカード、例えば選択カードを翻訳し、更にユーザがアクセスし得るアイテムからなるメニュー２０１（図２Ｂ参照）が生成される。この実施例においては、ユーザが、メニューの各アイテムをサーバコンピュータ１２１上で使用することができる。この例では、ユーザはＡＢＣデザイン社（ABC Designs ）を訪ねるＸＹＺ社（XYZ corporation）の代表者である。
【００６９】
後により詳細に述べるように、各メニューアイテムは、そのメニューアイテムに関連する特定のオブジェクトのアドレスを含むリソースロケータに結び付いている。この特定のオブジェクトのアドレスとは、典型的にはサーバコンピュータ１２１上の共通ゲートウェイインターフェイスプログラムのアドレスである。一般に、リソースロケータはアドレスを含み、更に付属のデータを含んでいてもよい。このアドレスは、その双方向データ通信デバイス内にあるローカルオブジェクト、もしくは、サーバコンピュータ上の遠隔オブジェクトであり得る。当業者には知られているように、共通ゲートウェイインターフェイスは例えばカードのような情報を動的に生成するのに用いられるインターネット規格である。ここに開示した内容の観点から言えば、動的なカード生成のための他の技術も用いられ得る。
【００７０】
初めに、メニュー２０１の第１行目の強調表示はなされていない。携帯電話機１００のキーパット上のキーの１つが押されたとき、そのキーに対応するメニューアイテムがスクリーン１０５上で強調表示される。従って、メニュー２０１は、ユーザが１番のキーを押し、第１アイテムが強調表示されたことを示している。しかし、選択されたアイテムの強調表示はこの実施例に特有の特徴ではなく、本発明の実現に一般に必要なものではない。所望に応じて、ディスプレイスクリーン１０５上に選択されたものを指示する矢印を表示するようなユーザの選択表示を使用する方法を用いることもできる。
【００７１】
１番のキーがおされた後、ユーザは所定のキー、例えばエンターキーを押して、その選択を確認する。別の実施例においては、その代わりに、その選択の確認は不要である。両実施例においては、その選択に対するリソースロケータは携帯電話機１００内のクライアントプロセスによって、データ処理対応型携帯電話ネットワーク１１０を通してサーバコンピュータ１２１に伝送される。この選択に応答して、サーバコンピュータ１２１はその選択に含まれるメッセージを処理し、この実施例においては、別のカードデックを携帯電話機１００に伝送する。
【００７２】
携帯電話機１００内のクライアントプロセスは、サーバコンピュータ１２１から受け取ったデックにおける第１カード、即ち選択カードを翻訳し、図２Ｃに示すような第２メニューを含むスクリーンディスプレイ２０２をディスプレイスクリーン１０５上に生成する。初めに、第２メニュー内のアイテムは何れも強調表示されていない。
【００７３】
スクリーンディスプレイ２０２が、ユーザがスクリーンディスプレイ２０１上で行った選択が記述されているヘッダと、ユーザが選択可能な第２メニューとが含まれていることに注意されたい。この実施例においては下向きの方向を指している指の絵で表示されているハンドアイコンである多段ディスプレイスクリーンカードインディケータ２０３は、現在の選択カードに関連するスクリーンが、ディスプレイスクリーン１０５には示されていなかった追加的なアイテムを含んでいることを示している。ここで、スクリーンは、この実施例のディスプレイスクリーン１０５上で使用可能な行数よりも大きいものでもよく、このときユーザはスクリーン全体を見るためにスクリーンディスプレイをスクロールしなければならない。
【００７４】
従って、追加的なアイテムを見るために、ユーザは携帯電話機１００上の第１スクリーンスクロールキー、例えばＮｅｘｔキーを押す。この実施例においては、第１スクリーンスクロールキーが押された場合、ディスプレイの各行は１行ずつロールアップする。メニュー全体が２枚のスクリーンディスプレイで表示し得る場合は、この結果のディスプレイ表示は上方向を指さす指の絵であるアイコンを表示していることになる（図示せず）。メニュー全体を見るために２枚のスクリーンディスプレイで足りない場合は、メニューの第２スクリーンディスプレイは２つのアイコン、即ち１つは上向きを指さす指、もう１つは下向きを指さす指の両方が表示されることになる。第２メニュー内の幾つかの行の間のスクロールを行うためには、ユーザが第１スクリーンスクロールキーと第２スクリーンスクロールキーを用いる。
【００７５】
ユーザがカードの最終行を表示している場合、即ち第２メニューの最終行を表示する場合は、第１スクリーンスクロールキーを押しても何の変化も起こらない。この実施例においては、ユーザは次のカードが使用可能となる前に選択を行わなければならない。
【００７６】
スクリーンディスプレイ２０２には、２つのソフトキー、即ちＨｏｍｅキー２０４とＩｎｆｏキー２０５が表示されている。この実施例においては、これにソフトキーはスクリーンディスプレイ２０２を発生するのに用いられるカードに対してのみ定義されている。ユーザは所定のキーシーケンスを押したとき、Ｈｏｍｅキーが強調表示されてその選択を示す。その実施例においては、このＨｏｍｅキーが選択されると、ユーザはスクリーンディスプレイ２００に戻る。別の実施例では、ユーザが無線通信ネットワーク１５０上で使用するために携帯電話機１００を起動するたびに表示されるホームスクリーンディスプレイに戻り得る。
【００７７】
Ｈｏｍｅキーは、一実施例においては、リソースロケータであるポインタに関連しており、このポインタによってアドレス指定されたカードは、ユーザだＨｏｍｅキーを選択したときクライアントプロセスによって表示される。具体的には、ポインタが現在デックにおけるカードを指定している場合、クライアントプロセスは、端にそのカードを表示する。ポインタが現在デック内のカード以外を指定している場合は、携帯電話機１００内のクライアントプロセスはポインタによって特定されたロケーションのカードを含むデックを検索する。このロケーションは、例えば、携帯電話機１００内のメモリか、コンピュータ１２１内のメモリであり得る。
【００７８】
同様に、ユーザが他の所定のキーシーケンスを押したとき、Ｉｎｆｏキーが強調表示されて、その選択を示す。この実施例においては、Ｉｎｆｏキーが選択されると、ユーザに可能な選択を示すヘルプスクリーンが表示される。ヘルプスクリーンの特定の内容は、サービスのプロバイダによって決められている。具体的には、ポインタがＩｎｆｏキーに関連しており、ユーザがＩｎｆｏキーから指を放すと、ポインタによって特定されたロケーションに格納された情報が、携帯電話機１００内のクライアントプロセスによって検索され翻訳される。
【００７９】
図２Ｃのメニューに戻ると、命令の状態を決定するために、ユーザは携帯電話機１００のキーパット上の２つのキーを押す。キーを押したことに応答して、メニューの第２選択肢が、図２Ｃに示すように強調表示される。キーを押したことの確認、例えばユーザが所定のキーシーケンスを押したことに応答して、携帯電話機１００はコンピュータ１２１に、チェックオープンオーダーリクエスト（ｃｈｅｃｋ  ｏｐｅｎ  ｏｒｄｅｒ  ｒｅｑｕｅｓｔ）を伝送する。即ち、クライアントプロセスが２つのキーを押したとこによって選択されたメニューアイテムに関連するリソースロケータを含むメッセージを伝送する。
【００８０】
チェックオープンオーダリクエストに応じて、コンピュータ１２１は更に別のカードデックを携帯電話機１００に送ってくる。携帯電話機１００内のクライアントプロセスは、入力カードであるこのデックを翻訳して、さらに、ディスプレイスクリーン１０５上に購入注文（ｐｕｒｃｈａｓｅ  ｏｒｄｅｒ：Ｐ．Ｏ．）番号入力スクリーンディスプレイ２０６（図２Ｄ参照）を生成する。スクリーンディスプレイ２０６が、前に述べたソフトキー２０７及びＦａｘソフトキー２０８を有することに注意されたい。また、これらのソフトキーのそれぞれは、関連するポインタを有し、ユーザがそのソフトキーを選択したとき、クライアントプロセスがそのポインタによって特定されたロケーションに格納された情報を検索し翻訳する。
【００８１】
この実施例においては、ユーザはソフトキーを選択せず、携帯電話機１００のキーパッドを用いて図２Ｅに示すような購入注文番号を入力している。ユーザは、単に幾つかの番号を入力するのみである。クライアントプロセスは、この番号のフォーマットを整えて、図２Ｅに示すように番号の間に−を挿入する。
【００８２】
購入注文が入力されたのち、ユーザが所定のキーシーケンスを押して、購入注文番号の入力が終了したことをクライアントプロセスに示す。ユーザがデータの入力を行っており、単にメニューアイテムの選択を行っただけではないということに注意されたい。このユーザが携帯電話機１００を、それがネットワーク１２０に接続されたコンピュータであるかのように使用しているが、後に詳細に述べるように、携帯電話機１００は、データ処理対応型携帯電話ネットワーク１１０上で通信が行える標準的なデジタルデータ対処型携帯電話機と類似したものである。具体的には、携帯電話機１００は従来技術においてインテリジェント電話を形成するときに採用された方法のようにコンピュータモジュールと無線通信モジュールとを組み合わせたものではない。
【００８３】
更に、ユーザは標準的な携帯電話機のキーパットのみを用いてデータを入力している。従って、携帯電話機１００はコンピュータのキーボードや、ポインタの動きを認識する先進的なタッチスクリーンを必要としていない。この点は、携帯電話機１００のサイズ、重量、及び電力消費を一般の音声のみの携帯電話機と同程度のものに維持するために重要なことである。一実施例においては、データ入力を容易にするために、後に詳述するように、携帯電話機１００はテキストデータの入力に必要なキーストロークの回数を減らすテキスト予測プロセスを含んでいる。この実施例においては、テキスト予測プロセスが各入力カードに対してオンオフされる。
【００８４】
購入注文番号の入力に応答して、クライアントプロセスはサーバコンピュータ１２１に、特定の購入注文のためのリクエストを伝送する。つまり、クライアントプロセスは入力されたデータにリソースロケータをつけて、リソースロケータを含んだメッセージをサーバコンピュータ１２１に伝送するのである。サーバコンピュータ１２１は、このメッセージに応じて、適当な購入注文を検索し、購入注文をカードデックの形で無線通信ネットワーク１５０を通して、携帯電話機１００のクライアントプロセスに転送する。
【００８５】
クライアントプロセスは、そのカードデックを翻訳し、スクリーンディスプレイ２０９を生成する（図２Ｆ参照）。初めに、Ｆａｘキー２０８はスクリーンディスプレイ２０９上で強調表示されていない。
【００８６】
スクリーンディスプレイ２０９には多段ディスプレイスクリーンカードインディケータ２０３が含まれており、ユーザに購入注文スクリーンがディスプレイスクリーン１０５上に一度に表示され得る情報よりも多くの情報を含んでいることを示している。
【００８７】
ユーザが購入注文を見直した後、ユーザはＦａｘキー２０８に対するキーシーケンスを押して、それに応じてＦａｘキー２０８が図２Ｆに示すように強調表示される。
【００８８】
Ｆａｘキー２０８の選択に応じて、クライアントプロセスはＦａｘキー２０８に関連するポインタによって特定されたロケーションにおいてカードデックを検索する。このロケーションがサーバコンピュータ１２１上にある場合は、クライアントプロセスはリソースロケータを含むメッセージをサーバコンピュータ１２１に伝送し、このメッセージに応じて、サーバコンピュータ１２１は別のカードデックを送り返してくる。このロケーションがサーバコンピュータ１２１以外のサーバコンピュータ上に存在する場合は、クライアントプロセスはリソースロケータを含むメッセージをそのサーバコンピュータに伝送し、このメッセージに応じて、そのサーバコンピュータは別のカードデックを送り返してくる。ポインタによって特定されたこのロケーションが携帯電話機１００内に存在する場合は、クライアントプロセスは単にそのデックを検索する。どちらの場合においても、入力カードであるＦａｘフォーム２１０（図２Ｇ参照）は、携帯電話機１００によってディスプレイスクリーン１０５上に表示される。この例は、クライアントプロセスによってアクセスされる情報が様々な場所に存在し得るということを具体的に示している。Ｆａｘキーに関連するリソースロケータはその適切なロケーションを特定する。
【００８９】
Ｆａｘフォーム２１０が表示されているとき、ユーザは、図２Ｈに示すように、携帯電話機のキーパットを用いてＡＢＣデザイン社のＦａｘ番号を入力する。この実施例においては、このＦａｘ番号はクライアントプロセスによって自動的にフォーマットを整えられる。電話番号の入力が終了した後、クライアントプロセスはこの電話番号にリソースロケータをつけてこの情報をサーバコンピュータ１２１に伝送する。
【００９０】
サーバコンピュータ１２１がこの情報を受け取ったとき、サーバコンピュータ１２１はこのリソースロケータによって指定された共通ゲートウェイインターフェイスアプリケーション（ＣＧＩ）を実行する。このＣＧＩアプリケーションは必要な情報を取り込んで、その情報を電子メールを介してＦａｘゲートウェイに転送する。Ｆａｘゲートウェイは、電子メールを受け取ったとき、その情報をＦａｘ情報に変換してその情報を特定の電話番号に送る。従って、携帯電話機１００をプリンタもしくはプリンタドライブへ接続する必要はなく、ＡＢＣデザイン社のＦａｘキーを用いてプリントすることができるのである。
【００９１】
この実施例に示すように、携帯電話機１００は特定の購入注文のリクエストを伝送し、このリクエストに応答するデータの、データをプリントする能力を有するローカルマシンへの伝送のスケジューリングを行った。従って、後に詳細に述べるように、データ処理対応型携帯電話ネットワーク１１０とともに携帯電話機１００内で行われる本発明の処理及びサーバコンピュータ１２１によって、携帯電話機１００がその内部に存在するマイクロコントローラのみを用いて、且つ従来のような別個のコンピュータモジュールを必要とせずに、ネットワーク１２０上のサーバコンピュータ１２１上のアプリケーションを効果的に利用することが可能となる。
【００９２】
更に、サーバコンピュータ１２１から送られた情報、即ちカードを用いてクライアントプロセスは図２Ａ〜図２Ｈに示すような様々なユーザインターフェイスを生成する。様々なユーザインターフェイスの特定の形状は、カードデックの形で伝送される、処理及び表示データパッケージであるカードによって定められる。この結果、ユーザインターフェイスは電子メール型フォーマットのような特定の１種類のフォーマットに固定されず可変となり、クライアントプロセスによって翻訳される各カードにより定義を変更することが可能となる。また、一般に、サーバコンピュータ上の１つのアプリケーションに対するユーザインターフェイスは、そのサーバコンピュータ上の別のアプリケーション用にユーザインターフェイスからは独立している。
【００９３】
具体的には、サーバコンピュータ１２１によってアクセスされるアプリケーションはカードデックを生成し、様々なユーザインターフェイスをそれぞれ定めている。各ユーザインターフェイスによりユーザが特定の選択を識別することが可能となる。特定の選択のそれぞれによって選択ごとに異なるユーザインターフェイスが生成され得ることになる。従って、そのユーザインターフェイスは双方向データ通信デバイスがアクセス可能なアプリケーションによってのみ限定されることになる。
【００９４】
以下に示すように、様々なアプリケーションがサーバコンピュータ上に提供され得る。様々なアプリケーションの翻訳においてクライアントモジュールが破壊されることは殆どないのにもかかわらず、典型的にはクライアントプロセスは軽量であり、従って軽量のリソース、例えば、６０ＫバイトのＲＯＭ、１０ＫバイトのＲＡＭ、及び１秒当たり１００万個未満の命令数（１ＭＩＰＳ以下）の処理能力ですむ。クライアントプロセスが双方向データ通信デバイスにおけるこのような軽量のリソースのみを必要とすることから、クライアントはこのようなデバイス内に現存するリソースを使用することができ、従ってデータ処理対応型携帯電話機１００のような双方向データ通信デバイスのコストを上昇させることはない。
【００９５】
別の実施例においては、ユーザは携帯電話機１００がローカルエリアネットワーク１３０上のサーバコンピュータ１３１にアクセスできるように設定し得る。ユーザによるアクセスに応じて、コンピュータ１３１はホームカード（図示せず）を携帯電話機１００に送り、ここでディスプレイスクリーン１０５上にホームスクリーンディスプレイが生成される。
【００９６】
ユーザがホームスクリーンディスプレイ、または、ホームカードに関連する次のスクリーンディスプレイ上で個人情報（personal information）を選択したとき、個人情報デックのリソースロケータを含むメッセージが携帯電話機１００からコンピュータ１３１に伝送される。このメッセージに応じて、コンピュータ１３１は表示カード及び選択カードを含むカードデックを携帯電話機１００に伝送する。これらの例においては、このカードデックは３０のカード、即ち表示カード、選択カード、及び入力カードの１つを含むように記述されている。しかし、これらの例は本発明を説明するためのものであり、本発明の範囲をこのようなカードを用いる特定の実施例に限定しようとするものではない。この開示内容を参照することにより、当業者は、所望に応じてこれらのタイプのカードを組み合わせたり、他のタイプのカードを新たに定めたりすることができよう。
【００９７】
携帯電話機１００におけるクライアントプロセスは映像データ及びテキストデータを含む表示カードを翻訳し、ディスプレイスクリーン１０５上にスクリーンディスプレイ３００を生成する（図３Ａ参照）。スクリーンディスプレイ３００はＨｏｍｅキー３０１，及びＩｎｆｏキー３０２を有する。ユーザがＨｏｍｅキー３０１を選択すると、ユーザはホームスクリーンに戻ることになる。Ｉｎｆｏキー３０１は上述のＩｎｆｏキー２０５と同様の機能を有する。
【００９８】
ユーザが所定のキーを押すと、クライアントプロセスは選択カードを翻訳し、第２スクリーンディスプレイ３０４（図３Ｂ参照）がディスプレイスクリーン１０５上に表示される。スクリーンディスプレイ３０４は、携帯電話機１００のユーザが使用できるようにサーバコンピュータ１３１上に格納された個人情報のメニューである。多段ディスプレイスクリーンカードインディケータ２０３、例えば下向きに指さした指の絵が、ユーザに次のスクリーンディスプレイに追加的なアイテムを有するリストが存在することを示している。スクリーンディスプレイ３０４は、ユーザに待機中の電子メールメッセージ、Ｆａｘ及び音声メールメッセージの数も示している。
【００９９】
ユーザはスクリーンディスプレイ３０５がディスプレイスクリーン１０５上に表示されるまで、スクリーンディスプレイを１行ずつスクロールする。メニュー内の第４アイテムは初めは強調表示されていない。この例においては、ユーザのスケジュールを見るためにユーザは携帯電話機１００のキーパット上の４のキーを押す。キーを押したこと、即ちキープレスに応答して、携帯電話機１００におけるクライアントモジュールは４のキーを押すことによって選択されたメニューアイテムに関連するリソースロケータを含むメッセージをデータ処理対応型携帯電話ネットワーク１１０及びローカルエリアネットワーク１３０を用いてサーバコンピュータ１３１に送る。
【０１００】
このメッセージに応じて、サーバコンピュータ１３１はこのリソースロケータで特定されたアプリケーションを実行する。このアプリケーションの実行が終了すると、サーバコンピュータ１３１は、ローカルエリアネットワーク１３０及びデータ処理対応型携帯電話ネットワーク１１０を通して、携帯電話機１００にその日のユーザのスケジュールを記述した選択カードを含むカードデックを送ってくる。
【０１０１】
この実施例においては、サーバコンピュータ１３１がこの伝送を終了すると、サーバコンピュータ１３１はメッセージに対する応答を終了し、全ての必要な情報を携帯電話機１００に伝送したことになる。従って、サーバコンピュータ１３１は伝送した情報に関する何らかの状態情報を保持しておくことはなく、無状態サーバコンピュータ１３１と称される。この実施例においては、クライアントプロセスはカードデックのリクエストのみを行うことができる。しかしながら、ここで示したように、本発明の双方向データ通信システム及びカードデックはユーザに対して、新たなレベルの処理能力を与えている。
【０１０２】
携帯電話機１００がカードデックを受け取ったとき、携帯電話機１００におけるクライアントプロセスは選択カードを翻訳し、ディスプレイスクリーン１０上にスクリーンディスプレイ３０６（図３Ｄ参照）を表示する。スクリーンディスプレイ３０６内のメニューの第１アイテムは、初めには強調表示されていない。ユーザが携帯電話機１００のキーパッド上の１のキーを押したとき、携帯電話機１００はメニュー内の第１アイテムを強調表示する。携帯電話機１００は次にユーザが所定のキーを押したとき、スクリーンディスプレイ３０８（図３Ｅ参照）を生成する。スクリーンディスプレイ３０８にはスケジュールキー３０９が含まれており、これが選択されるとユーザをスクリーンディスプレイ３０６（図３Ｄ参照）に戻す。スクリーンディスプレイ３０８には、１０：００Ａ．Ｍ．ミーティング（meeting ）というスケジュールに関する詳細な表示も含まれている。
【０１０３】
スクリーンディスプレイ３０８がアクティブ状態にある間、ユーザが所定のキーを押した場合、ユーザはスクリーンディスプレイ３１０（図３Ｆ参照）上に選択肢を提示される。スクリーンディスプレイ３１０における第２アイテムは初めは強調表示されていない。
【０１０４】
この例においては、ユーザは携帯電話機１００のキーパッド上の２のキーを押し、携帯電話機１００がリソースロケータを含むメッセージをサーバコンピュータ１３１に送り、ビル・スミス（Bill Smith）氏に午前１０時のミーティングの予定を確認（confirm ）する電子メールメッセージを送っている。サーバコンピュータ１３１がリソースロケータによってアドレス指定されたアプリケーションを実行すると、電子メールメッセージが送られる。
【０１０５】
別の例においては、携帯電話機１００のユーザが、データ処理対応型携帯電話ネットワーク１１０を用いて、インターネット１４０上のインターネットサービスプロバイダコンピュータ１４１に接続する。携帯電話機１００が接続すると、サービスプロバイダ１４１は携帯電話機１００にカードデックを伝送し、図４Ａ〜図４Ｃに示すような表示を生成する。
【０１０６】
携帯電話機１００におけるクライアントプロセスはコンピュータ１４１からのカードデックにおける第１カードを翻訳し、スクリーンディスプレイ４００（図４Ａ参照）を生成する。ユーザが所定のキーを押すと、携帯電話機１００はスクリーンディスプレイ４０１（図４Ｂ参照）を表示する。スクリーンディスプレイ４０１は、サービスをグループ化した一連の選択肢をアルファベット順にユーザに示している。
【０１０７】
ユーザが携帯電話機１００のキーパッド上の７のキーを押すと、携帯電話機１００にはサービス名の第１文字がＰ、Ｒ、若しくはＳであるサービスのリストが表示される。この実施例においては、スクリーンディスプレイ４０１及び４０２は、１枚のカード、即ち１枚のスクリーンからなる。１つのキーに関連する様々なサービスのそれぞれはインデックスを有しており、ユーザが特定の選択を行うと、その選択がインデックスを定める。次に、クライアントプロセスはユーザの選択によって定められたインデックスに一致するインデックスを有する全てのサービスを表示する。
【０１０８】
スクリーンディスプレイ４０２においては、ユーザにはタブ７の下位にあるユーザの使用可能なサービスの一連の選択肢が表示される。スクリーンディスプレイ４０２における第３アイテムは初めは強調表示されていない。この例においては、ユーザが携帯電話機１００のキーパッド上の３のキーを押して、“株式市況（stock quotes）”を選択し、スクリーンディスプレイ４０２内の第３アイテムが強調表示される。
【０１０９】
この選択に応じて携帯電話機１００は株式市況のリクエスト、例えばリソースロケータを含むメッセージを、携帯電話ネットワーク１００及びインターネット１４０を介して、サービスプロバイダ１４１に伝送する。このリクエストに応じて、サービスプロバイダコンピュータ１４１は、リソースロケータによってアドレス指定されたアプリケーションを実行する。このアプリケーションはカードデックを取出し、次に携帯電話機１００にそれを伝送する。カードデックには、表示カード及び入力カードが含まれている。
【０１１０】
カードデックを受け取ると、携帯電話機１００のクライアントプロセスは、表示カードを翻訳し、スクリーンディスプレイ４０３（図４Ｄ参照）を生成する。ユーザが所定のキーを押したとき、携帯電話機１００のディスプレイスクリーン１０５上には入力スクリーンディスプレイ４０６（図４Ｅ参照）が生成される。
【０１１１】
スクリーンディスプレイ４０６内の文字ＳＵＮＷが記されたボックスは初めは何も表示されていない。このＳＵＮＷという文字は、ユーザがボックスに入力したものであり、ユーザが情報を必要としている株式の銘柄のチッカー記号（ticker symbol）を示している。ユーザがその株式の銘柄のチッカー記号を入力した後、ユーザは入力が終了したことを示すために所定のキーを押す。  ユーザの入力に応じて、クライアントモジュールは株式のチッカー記号にリソースロケータを付して、そのリソースロケータをサービスプロバイダコンピュータ１４１に伝送する。このサービスプロバイダコンピュータにおいてリソースロケータによってアドレス指定されたアプリケーションが実行され、株式のチッカー記号に対する最新の株式市場情報を取出す。サービスプロバイダ１４１は取出された情報を用いて、その情報を含むカードデックを生成し、続いてそのカードデックを携帯電話機１００に転送する。
【０１１２】
携帯電話機１００内のクライアントプロセスは、そのデック内の第１カードを翻訳し、スクリーンディスプレイ４０９（図４Ｆ参照）説明の便宜上、図４Ｆ〜図４Ｉはひとまとめにして示されており、点線で分割されて示されている。しかし、この実施例においては、ある時間においてディスプレイスクリーン１０５が表示できるのは任意の４つの隣り合った行であり、図４Ｆ〜図４Ｉのひとまとめにされた複数の行は、単にクライアントプロセスにより取出され、表示され得る情報のレベルを具体的に示しているものに過ぎない。４行のディスプレイスクリーンを用いるのは１つの例に過ぎない。本発明のクライアントプロセスは、任意のサイズのディスプレイスクリーンを用いて機能を発揮することができ、たとえ１行しか表示できないディスプレイスクリーンでも機能を発揮できる。しかし、多段式ディスプレイスクリーンの方が好ましい。
【０１１３】
前述の説明において参照した図面において、ディスプレイスクリーンは画素ディスプレイであって、画像を表示することができる。別の実施形態では、ディスプレイスクリーンはテキストのみを表示することができ、サイズはより小さいものである。このような実施例に対しては、様々な入力は短縮され、テキストのみが表示されるが、動作の概要は上述のものと同一である。また、さまざまなコンピュータネットワークを相互にリンクして、１つのコンピュータネットワークにアクセスしているユーザが、他のコンピュータネットワーク上の情報を得られるようにすることも可能である。更に、上述の実施例は単なる例示に過ぎない。本発明の重要な側面の１つは、携帯電話機１００が、携帯電話機１００内のクライアントプロセスと通信及び対話ができるように構成された任意のタイプのサーバアプリケーションと対話が可能であるという点である。従って、ユーザが受けられるサービスは、電話交換網上のプロバイダによって与えられた数少ないサービスに限定されることはもはや無くなるのである。
【０１１４】
図１において、携帯電話機のユーザは異なるサービスにアクセスするために目的の各コンピュータにアドレス指定、即ち接続しなければならない。従って、各コンピュータは携帯電話機１００との通信に必要な情報を必要とする。別の実施例においては、ここでは図示しないが、携帯電話機１００が、データ処理対応型携帯電話ネットワーク１１０を通して１つの中央コンピュータと接続する。このコンピュータは図１に示す他のネットワークのそれぞれに接続されている。この結果、携帯電話機１００のユーザはリソースロケータを含むメッセージを中央コンピュータに送り、中央コンピュータがそのメッセージを処理して図１に示す適当なネットワークから、リソースロケータによってアドレス指定された情報を取出す。必要な情報が取出された後、中央コンピュータはカードデックを生成し、そのカードデックを携帯電話機１００に伝送する。この実施例においては、携帯電話機１００と通信できるように構成されなければならないコンピュータはただ１つである。しかし、同じコンピュータは、携帯電話機１００のユーザが使用する他の全てのコンピュータと通信できるようにも構成されていなければならない。
【０１１５】
従って、本発明の原理によれば、双方向データ通信デバイス上のクライアントプロセスは、特定のサーバコンピュータとの対話を行うことができる。サーバコンピュータは、（ｉ）ユーザインタフェースを生成するべくクライアントプロセスに情報を伝送し、（ii）ユーザがユーザインタフェースから選択できる各選択肢に対するリソースロケータを伝送する。このリソースロケータは、サーバコンピュータ上のアプリケーション、複数のサーバコンピュータ上の亘って存在するアプリケーション、若しくは他のサーバコンピュータにアクセスするサーバコンピュータ上のアプリケーションをアドレス指定し得る。この結果、双方向データ通信デバイスのユーザが使用できるアプリケーションは、このサーバコンピュータ上に存在するアプリケーションのみに限定されないことになる。
【０１１６】
更に、ユーザは、サーバコンピュータ上のアプリケーションを変えることにより、新規な処理能力及び／若しくは更新された処理能力を得ることができる。この場合、新規なまたは更新されたアプリケーションのためにクライアントプロセスを変更する必要はない。クライアントプロセスは、アプリケーションから受け取った情報を翻訳し、追加的な情報のためにメッセージを伝送するだけでよい。このような処理内容は、新規なまたは更新されたアプリケーションによって影響を受けない。従って、上述のように、本発明によれば、双方向データ通信デバイスのエンドユーザが更新されたアプリケーションの配布を受けたり、新規なアプリケーションを入手する必要はない。
【０１１７】
図５に示すのは、無線通信ネットワーク１５０の別の実施例である。この実施例においては、双方向データ通信デバイス、例えばデバイス１００、１０１、及び１０２からのメッセージが無線通信ネットワークトランスレータ５００に向けられている。無線通信ネットワークトランスレータ５００及び特定の双方向データ通信デバイス、即ちデバイス１００、１０１、及び１０２の何れかは、その通信において、無線通信ネットワークトランスレータ５００及びその双方向データ通信デバイスにリンクした特定のネットワーク上におけるポイントツーポイント方式通信用のプロトコルを用いる。例えば、データ処理対応型携帯電話ネットワーク１１０がセルラーデジタルパケットデータ（ＣＤＰＤ）ネットワークである場合は、使用され得るプロトコルは、トランスミッションコントロールプロトコル（the transmission control protocol）（ＴＣＰ）か、ユーザデータグラムプロトコル（the user datagram protocol）（ＵＤＰ）かの何れかである。
【０１１８】
無線通信ネットワークトランスレータ５００は、通信経路を確認し、後に詳しく述べるように、必要ならばコンピュータネットワークに伝送されるメッセージを暗号化した後、双方向データ通信デバイスと選択されたコンピュータネットワークとの間でデータの伝送を行う。更に、無線通信ネットワークトランスレータ５００は、双方向データ通信デバイスと指定されたコンピュータネットワークとの間の通信に関するトランザクション情報及び課金情報を収集する。具体的には、無線通信ネットワークトランスレータ５００は、有料サービスのためのアクセスのコントロール、及び課金のためのロギング（ｌｏｇｇｉｎｇ）機構を提供する。無線通信ネットワークトランスレータ５００は、ユーザに対する直接のサービスも提供しうる。
【０１１９】
図６は、典型的なＧＳＭデジタル携帯電話機のブロック図である。携帯電話機６００の各ハードウェア構成要素は、当業者にはよく知られたものであり、従ってここではハードウェア構成要素については詳しく説明は行わない。コンパイルされ、リンクされた本発明のプロセスは、クライアントモジュール６０２及びサポートモジュール６０３としてＲＯＭ６０１内に格納される。キーパッドを用いて所定のキーシンケンスを入力すると、ここではマイクロコントローラと称することもある物理層プロセッサ６１０が、ＲＯＭ６０１内のクライアントモジュール６０２を用いてクライアントプロセスを回避する。
【０１２０】
この実施例では、クライアントモジュール６０２は、後に詳しく述べるように、一定の処理を行う機能単位である複数のマネージャモジュールを含む。使用される特定のマネージャモジュールは、クライアントモジュール６０２が実行される特定の携帯電話機１００の特性によって決定される。クライアントモジュール６０２は、携帯電話機１００内の特定のハードウェアを制御するモジュールとインタフェースをとるマネージャモジュール、携帯電話機１００によって使用される特定の携帯電話ネットワークプロトコルとインタフェースをとるための、及び受け取ったカードデックを翻訳するためのマネージャモジュールとを含んでいなければならない。従って、ここで説明する特定のマネージャモジュールは、本発明の原理を説明することのみを目的として記述されたものであって、以下に詳述する特定のモジュールに本発明の範囲を限定しようとするものではない。
【０１２１】
この実施例においては、クライアントプロセスはディスプレイモジュール、キーパッドモジュール、及びネットワーク及び端末コントロールモジュールのような、前に集合的にサポートモジュール６０３として説明した、ＲＯＭ６０１内に格納された複数の携帯電話機従属サポートプロセスの処理を制御する。クライアントプロセス、ディスプレイプロセス、キーパッドプロセス、及びネットワーク及び端末コントロールプロセスの組み合わせは、携帯電話機６００におけるマイクロカーネルによるフォアグラウンドタスクと考えられる。またここで、モジュールなる用語及びプロセスなる用語は交換可能に用いられるが、当業者はこのモジュールが携帯電話機６００のメモリ、好ましくはＲＯＭに格納されたコンピュータプログラムソフトウェアであり、対応するプロセスが携帯電話機６００のマイクコントローラにより実行されるものであるということを理解されよう。また、本発明は個別のプロセッサを必要とはせず、上述のように本発明のクライアントプロセスは軽量であることから、携帯電話機６００内に既に存在する処理能力を用いることができるということに注意されたい。
【０１２２】
携帯電話機６００のユーザインタフェースは、ＲＯＭ６０１に格納されたユーザインタフェースマネージャモジュールのバージョンによって決まる。一実施例においては、ユーザインタフェースレベルを規定するのに用いられるパラメータは、ディスプレイ解像度、ディスプレイの画素アクセス、及びソフトキーのサポートである。ユーザインタフェースレベルの規定の１つを表１に示す。
【０１２３】
【表１】
0004274661.tif 000002
【０１２４】
このユーザインタフェースマネージャモジュールは、ディスプレイモジュールにデータを提供し、ディスプレイモジュールはディスプレイスクリーン６０５を駆動し、ディスプレイスクリーン６０５上でユーザが入力したデータを捕捉する。この情報に応じて、ネットワークマネージャモジュールによって伝送するべくメッセージが準備される。
【０１２５】
無線通信ネットワーク１５０上で実行される処理をより詳細に説明するために、図７においては、本発明の一実施例における携帯電話機７００のさまざまな構成要素を示したブロック図が示されている。当業者は、携帯電話機７００が携帯電話機６００のものに類似した、携帯電話機７００によってサポートされた音声及びデータ処理のための回路及びソフトウェアを有し、無線通信ネットワーク７５０上での処理のためのモジュールを有していることを理解されよう。同様に、サーバコンピュータ７４３は、当業者によく知られた他のソフトウェア及びハードウェアを有し、従って、図７においてはこれらについては明示されていない。
この実施例においては、デジタル携帯電話機７００におけるクライアントモジュール７０２は、携帯電話機のマイクロコントローラ上で実行され、セルラーデジタルパケットデータ（ＣＤＰＤ）ネットワーク７１０を介してサーバコンピュータ７４３と通信を行う。ＣＤＰＤネットワーク７１０は双方向データ通信ネットワークの一例として用いられている。本発明の原理は、様々な双方向データ通信ネットワークと共に使用され得る。例えば、使用され得る携帯電話用の他の双方向データ通信ネットワークを挙げると、ＴＤＭＡ、ＣＤＭＡ、及びＧＳＭ回路データ交換網、及びモデムと共に用いられるＡＭＢＳアナログセルラーネットワークなどがある。同様に、双方向ページャー用としては、使用される双方向データ通信ネットワークにはＰＡＣＴ、若しくは他の、データ伝送能力を有する優先順位式双方向ページングネットワークなどが挙げられる。
【０１２６】
無線通信ネットワーク７５０のこの構成の動作についてより詳細に考察する前に、本発明の別の側面について説明を行う。具体的には、デジタル携帯電話機７００からサーバコンピュータ７４３上のサーバアプリケーションへの命令の伝送、及び逆方向の命令の伝送に必要な技術について説明する。
【０１２７】
電話間対話記述言語（telephone interaction description language）（ＰＩＤＬ）がサービス開発者による使用のために規定される。端末間対話記述言語（ＴＩＬ）は、電話間対話記述言語の粋を抜き出したもの（distillation）であって、電話間対話記述言語がコンピュータ７４３用として記述するのと同様の対話を、デジタル携帯電話機７００用として記述するものである。
【０１２８】
後に詳しく説明する例外が存在するが、端末間対話言語における処理は、電話間対話記述言語において記述される同じ処理を圧縮したものである。端末間対話記述言語により、双方向データ通信デバイス上のパージングが容易になり、これによってクライアントを、人間が読むことができるが、機械によるパージングに対しては最適化されていない電話間対話記述言語用のクライアントよりも小さなものにすることができる。
【０１２９】
カードの中にコンピュータ処理されたカードがあり、予めコンパイルすることができないことから、電話間対話記述言語から端末間対話記述言語への圧縮は、コンパイル実行時に行われるのが普通である。電話間対話記述言語から端末間対話記述言語へ転換するのに用いられる技術にはさまざまなものがあり得る。重要な点は、携帯電話ネットワークにおけるバンド幅が限られている場合に、電話間対話記述言語の圧縮形態が用いられるという点である。
【０１３０】
各データタイプは、双方向データ通信ネットワーク上の最適な伝送を容易に実現するために圧縮されるのが好ましい。例えば、電話間対話記述言語における動詞は、二進トークン化処理（binary tokenization）を用いて圧縮される。グラフィックスはランレングス制限圧縮法を用いて、テキストは圧縮のためのよく知られた技術の１つを用いて圧縮される。電話間対話記述言語の圧縮においては、本発明の原理を利用する必要はないが、圧縮によりネットワークのバンド幅がより効率的に使用されるようになることから、本発明がより効果的なものとして実現されることになる。
【０１３１】
電話間対話記述言語及び端末間対話記述言語における命令は、データパッケージであるカード及びデックにまとめられる。各デックは、１または２以上のカードを含む。１枚のカードには、情報、例えばスクリーンを発生するのに必要な電話間対話記述言語の命令セットが含まれている。上述のように、スクリーンはディスプレイスクリーンの行数よりも大きなものであり得る。カードの別の名称は、ページ若しくはアトミックインタラクションである。従って、カードデックは単なるスクリーン表示データのグループに過ぎない。１つのカードデックにおけるカード数は、双方向データ通信デバイス及び無線通信ネットワークにおけるリソースを効率的に利用することができるように選択される。
【０１３２】
単純化のため、この実施例においては、各カードが１つの処理を含むものとする。ここで、１つの処理は関連する処理のセットとして規定され、このときユーザは１つの処理から次の処理への移動において予期しない遅れに出会うことはない。即ちクライアントモジュール７０２がコンピュータ７４３から別のカードデックを取出す間にユーザが待機することがないようにされている。また、デックの１つがアクティブ状態にあるとき、即ち携帯電話機のマイクロコントローラによって実行されている間に、有効な状態にあるソフトキーを含んでいることがある。
【０１３３】
コンピュータ７４３は、格納されたスタティックな電話間対話記述言語デックを含んでいてもよい。コンピュータ７４３が、携帯電話機７００のユーザからのデータ、もしくはユーザによる選択に応じて電話間対話記述言語デックを発生することもある。
【０１３４】
図７に示す実施例においては、コンピュータ７４３は、電話間対話記述デックを端末間対話言語デックに変換し、この端末間対話言語デックは携帯電話機７００に伝送される。端末間対話言語は、デックが携帯電話機７００のメモリ７１６に、変更されることなく格納され、パージングを殆ど行うことなく直接参照され得る。コンピュータ７４３上の電話間対話記述言語デックが画像の参照を含んでいることもあるが、端末間対話言語デックはデックの最後に画像を含んでいる。従って、特定の双方向データ通信デバイスは画像の表示をサポートしていない場合は、その画像はデックが特定の双方向データ通信デバイスに伝送される前に、端末間対話言語デックから容易に取り除かれる。
【０１３５】
上述のように、携帯電話機７００のユーザとの各対話は、デックまたは一連のデックによって記述される。論理的には、ユーザは、端末間対話言語デックをＣＤＰＤネットワーク７１０を介してコンピュータ７４３から受け取った後、携帯電話機７００のメモリ７１６に格納された端末間対話言語デックの検索を行うことになる。ユーザがデックにおけるカードによって表示された情報を見直して、例えば図２Ａ〜図２Ｈに関連して上述したように、選択を行うか要求された情報を入力し、次に別のデックを要求する。
【０１３６】
ユーザがデックを受け取ったとき、情報の第１カードはディスプレイスクリーン７０５上に表示される。典型的には、前に示したように、第１カードはテキスト、画像、または画像とテキストの組み合わせである。ユーザが第１カードを見なおした後、ユーザはＮＥＸＴキーを押して、デック内の次のカードを見ることができる。同様に、ユーザはＰＲＥＶキーを用いることによりデック内の前のカードに戻ることもできる。従って、ＮＥＸＴキー及びＰＲＥＶキーを用いて、ユーザはデック内を前後に動くことができる。１つのカード内において、ユーザはスクロールキーまたはカードの表示部分内を上下に移動するためのキーを用いる。デック内及びカード内を動くために使用する特定の方法についてのこれらの記述は、本発明の実施例で利用される特定の方法を示したものであって、本発明をこれに限定しようとするものではない。この開示内容を参照することにより、当業者はデック及びカード内を移動するための様々な方法を用いることができよう。
【０１３７】
この実施例においては、カードは３つのタイプ、即ち表示カード、選択カード、及び入力カードの何れかである。カードのタイプとは無関係に、カードはテキスト及び画像を含み得る。更に、本発明においてはカードのタイプはこれらの３つの特定のタイプに限定されるものではない。カードのタイプをこれらの特定の３つのタイプに定めたのは、本発明を説明し、アプリケーションの開発者の助けにすることを意図したものである。
【０１３８】
表示カードは、ユーザに対する可読情報を与える。表示内容には、テキスト、画像、及びソフトキーの何れか１つ若しくは何れかの組み合わせが含まれ得る。ソフトキーは表示カードがアクティブ状態にあるときのみ機能を発揮する。
【０１３９】
選択カードは、ユーザに対して選択肢のリストを表示する。この選択肢は、自動的に選択カード上で定められた書式に整えられて提示される。本明細書の後ろの部分に記載されている、【ＰＩＤＬ及びＴＩＬの記述】の項を参照されたい。前述のように、ユーザは選択肢に対応するキーを押すことにより選択を行う。
【０１４０】
入力カードはユーザからの入力データを得るのに用いられる。入力カードは１または２以上の入力行を表示する。典型的には、入力行は、一連の複数の行からなる。入力行は、この実施例では、数字またはテキストデータの何れかを表示し得る。
【０１４１】
この実施例では、選択カード及び入力カードは、ユーザが必要な情報を入力するまで次のカードに移行することができないようになっている。ユーザがデックにおける最終カードに達し、ＮＥＸＴキーを押したときは、新たなデックの呼び出しが開始される。呼び出されるデックは、ユーザが処理を行ったデックかユーザによる選択によって決定される。また、デックの処理が終了すると、ユーザによる選択及び／もしくは入力データは、新たなデータのリクエストとともにコンピュータ７４３に伝送されるのが普通である。
【０１４２】
【ＰＩＤＬ及びＴＩＬの記述】の項に記載されているのは、本発明の電話間対話記述言語及び端末間対話言語のシンタックスの１実施例である。電話間対話記述言語は、一実施例においては、一般化された規格言語のサブセットを用いて記述される。一般化された規格言語のサブセットのみが使用されるので、電話間対話記述言語パーザー（parser）も、ｌｅｘ及びｙａｃｃ等の単純なツールを用いて容易に記述され得る。
【０１４３】
無線通信ネットワーク７５０上での処理に戻ると、携帯電話機７００はディスプレイモジュール７１２、キーボードモジュール７１１、クライアントモジュール７０２、及びＵＤＰインタフェースモジュール７１４を有する。この実施例においては、モジュール７０２は携帯電話機７００の非揮発性メモリ（図示せず）に格納されており、携帯電話機７００のマイクロコントローラ（図示せず）によって実行される。モジュール７１１、７１２、及び７１４は、クライアントモジュール７０２の制御の下で動作する。
【０１４４】
クライアントモジュール７０２は、携帯電話機７００内のマイクロコントローラに、後に、図８〜図１１を参照して詳しく説明するような処理を実行するように指示する命令を含む。この処理には、均一リソースロケータ（uniform resource locator）（ＵＲＬ）リクエストを、ハイパーテキストトランスファープロトコル（HyperText Transfer Protocol）（ＨＴＴＰ）サーバ７４９に送る処理と、ＨＴＴＰサーバ７４９によって送り返されたＴＩＬデックをパージングし表示する処理と、ユーザの押したキーに基づいて新たなＵＲＬを生成する処理とが含まれる。ＨＴＴＰサーバソフトウェアの記述及びＨＴＴＰサーバソフトウェアを走らせることができるプラットホームについては、例えば、ニューヨーク州のJohn Wiley & Sons社より１９９５年出版されたIan S.Graham著“The HTML Sourcebook”第８章を参照されたい。
ユーザデータグラムプロトコル（ＵＤＰ）インタフェースモジュール７１４は、ＣＤＰＤネットワーク７１０をクライアントモジュール７０２に接続し、クライアントモジュール７０２がＣＤＰＤネットワーク７１０を通してＵＤＰを用いて通信を行えるようにする。ユーザデータグラムプロトコルは当業者にはよく知られたものである。ＵＤＰインタフェースモジュール７１４は、コネクションパートナー（connection partners）間の単純な独立型メッセージの伝送をサポートする。
【０１４５】
ディスプレイモジュール７１２は、クライアントモジュール７０２とディスプレイスクリーン７０５とを結合するディスプレイドライバであって、これにより、クライアントモジュール７０２がディスプレイスクリーン７０５上に提供される情報を特定できるようにする。クライアントモジュール７０２内のユーザインタフェースマネージャモジュールは、一枚のカードにおけるディスプレイ情報をディスプレイモジュール７０４に対する命令に変換し、ディスプレイモジュール７０４は、ディスプレイスクリーン７０５の動作を制御するハードウェアを駆動する信号を供給する。例えば、ＴＩＬデックが画像を含む場合、ユーザインタフェースマネージャモジュールは、アクティブ状態のカードが画像の表示を要求するか否かを決定する。アクティブ状態のカードがユーザインタフェースマネージャモジュールに画像を表示することを命じた場合は、ユーザインタフェースマネージャモジュールは、メモリ７１６内の画像データをディスプレイモジュール７１２に送り、ディスプレイモジュール７１２はディスプレイスクリーン７０５上に画像を表示する。
【０１４６】
キーボードモジュール７０５は、キーパッド７１５とクライアントモジュール７０２を接続し、物理的キーパッド７１５上のユーザが押したキーを表すデータを、メモリ７１６に格納する。キーパッドモジュール７０５はユーザがキーを押したとき、そのことをクライアントモジュール７０２に通知する。
【０１４７】
クライアントモジュール７０２が、キーを押したこと、即ちキープレスの通知を受けたとき、入力カードがアクティブ状態にあれば、クライアントモジュール７０２内のユーザインタフェースマネージャモジュールは、押されたキーに関する情報をディスプレイモジュール７１２に送り、ディスプレイモジュール７１２は適当な文字をディスプレイスクリーン７０５上に表示する。ユーザインタフェースマネージャモジュールが、選択カードがアクティブ状態にあり、選択肢の１つに対応するキーが押されたことを判定した場合は、ユーザインタフェースマネージャモジュールは、ディスプレイモジュール７１２に命令を送り、例えば、前に説明したように強調表示することによって、ユーザに特定された選択肢を示す。
【０１４８】
ＨＴＴＰサーバ７４９に加えて、ホストコンピュータ７４３は、ＵＤＰインタフェースモジュール７４８、ホストコンピュータ７４３のメモリ７５５内に格納されたＣＧＩプログラム７６１、及びメモリ７５５内に格納さたＴＩＬデック７６０を含む。
【０１４９】
ＨＴＴＰサーバ７４９は、ＵＤＰインタフェースモジュール７４８を用いてＣＤＰＤネットワーク７１０にデータを送り、かつそこからデータを受け取る。ＴＩＬデック７６０はＨＴＴＰサーバ７４９がアクセス出来るＴＩＬデックである。ＰＩＤＬデックを含むスタティックファイルはＨＴＴＰサーバ７４９上で一度だけＴＩＬデックに変換される。ＣＧＩプログラム７６１は、ＴＩＤＬデックを生成する共通ゲートウェイインタフェースプログラムであって、ＰＩＤＬデックはＨＴＴＰサーバ７４９がＴＩＬデックを生成するのに用いられ、ＴＩＬデックはＵＤＰインタフェースモジュール７４８及び７１４及び携帯電話ネットワーク７１０を介してクライアントモジュール７０２に伝送される。この実施例においては、無線通信ネットワーク７５０を介して使用可能なサービスは、インターネット１４０上のＨＴＴＰサーバ７４９がアクセス可能なアプリケーションであって、そのためにサービス開発者はＰＩＬデックまたはＣＧＩスクリプト（ｓｃｒｉｐｔ）を記す。ＣＧＩスクリプトはさらにＰＩＤＬデックを生成しコンピュータ７４３に格納される。
【０１５０】
図７のアーキテクチャは、本発明の重要な側面の幾つかを具体的に示している。第１に、この実施例におけるアプリケーション、ＰＩＤＬデック、及びＣＧＩスクリプトは、特定の双方向データ通信ネットワークから独立している。ＨＴＴＰサーバ７４９が、ＵＤＰをサポートしていない異なる双方向データ通信ネットワークを通して通信を行うために変更されなければならないのは、ＵＤＰインタフェースモジュール７４８のみである。このアプリケーションはこのような変化によって影響を受けない。
【０１５１】
第２に、ＨＴＴＰサーバ７４９上のアプリケーションは、ＨＴＴＰサーバ７４９が対話を行う双方向データ通信デバイスからは独立している。ＨＴＴＰサーバ７４９上のアプリケーションは、適当なクライアント及び双方向データ通信ネットワークを通してデータのやりとりを行うためのモジュールを含む任意の双方向データ通信デバイスと通信を行うことができる。この２つの事実が意味するのは、アプリケーションの開発に対する投資が、双方向データ通信デバイスの進歩や双方向データ通信ネットワーク技術の進歩から切り離されたということである。図８〜図１１は、全体として本発明の一実施例のプロセス流れ図である。初めに、ユーザが、無線通信ネットワーク７５０を介して通信を開始したとき、クライアントモジュール７０２は、携帯電話機７００のメモリ７１６における作業スペースを初期化し、次にｇｅｔ  ｈｏｍｅ  ＵＲＬプロセス８０１において、ＵＲＬを作業スペースに格納する。本発明の原理によれば、その一実施例においては、無線通信ネットワークを利用する各携帯電話機は、携帯電話機のためにホームカードデックを検索するのに用いられる非揮発性メモリに格納されたｈｏｍｅＵＲＬを有する。別の実施形態では、携帯電話機は、サーバ７４９からｈｏｍｅ  ＵＲＬを得る。従って、ｇｅｔ  ｈｏｍｅ  ＵＲＬプロセス８０１において、クライアントモジュール７０２はｈｏｍｅ  ＵＲＬを得る。ここで、ＵＲＬはリソースロケータの特定の実施例である。
【０１５２】
例えば、ｇｅｔ  ｈｏｍｅ  ＵＲＬプロセス８０１において、クライアントモジュール７０２はｈｏｍｅ  ＵＲＬを１つ得るが、このようなｈｏｍｅ  ＵＲＬは、例えば、
http://www.libris.com/airnet/home.cgi
であって、さらにクライアントモジュール７０２はこのｈｏｍｅ  ＵＲＬを作業スペースに格納する。ｈｏｍｅ  ＵＲＬの一部、http:/www.libris.comは、ワールドワイドウェブ上の特定のＨＴＴＰサーバ、例えばサーバ７４９を特定している。ＵＲＬの一部分/airnet/home.cgiは、ＣＧＩプログラム７６１内の特定の共通ゲートウェイインタフェースプログラムを特定している。ワールドワイドウェブ上のサーバを指定するＵＲＬを使用するのは、本発明の説明のための例示に過ぎず、本発明において使用されるアプリケーションをワールドワイドウェブ上のアプリケーションに限定するものではない。一般に、携帯電話機７００は、携帯電話機が初めに無線通信ネットワーク７５０上でアクティブ状態になり、リソースロケータを作業スペース内に格納したとき、サーバによって実行されるホームサーバ上のホームアプリケーションの識別子、即ちリソースロケータを得る。
【０１５３】
次に、ＨＴＴＰリクエスト生成プロセス８０２において、クライアントモジュール７０２は、作業スペース内のＵＲＬをＨＴＴＰリクエストに変換する。例えば、上述のＵＲＬに対しては、ＨＴＴＰリクエスト生成プロセス８０２で、以下のようなメソッドフィールドが生成される。
GET /airnet/home.cgi  HTTP/1.0
ＧＥＴメソッドはＨＴＴＰの一部である。従って、ＧＥＴメソッドに対するフォーマットは、当業者には既知となっているものである。また、このメソッドの特定のサーバコネクションが携帯電話機７００によって確立され、サーバの識別が不要であることから用いられるものである。それにもかかわらず、このコマンドは、要するにサーバ７４９にアプリケーションｈｏｍｅ．ｃｇｉを実行することを命令するものであり、アプリケーションｈｏｍｅ．ｃｇｉの実行により、ホームデックが生成され、ついでそのホームデックが携帯電話機７００に伝送される。ＨＴＴＰ／１．０は、携帯電話機７００のクライアントモジュール７０２によって使用されるＨＴＴＰのバージョンを特定している。
【０１５４】
メソッドフィールドに加えて、クライアントモジュール７０２は、プロセス８０２において、クライアントモジュール処理能力に関連する情報もサーバ７４９に送るための、適当なＨＴＴＰリクエストフィールドの生成も行うことができる。このリクエストフィールドは、クライアントが受け入れることができるＭＩＭＥコンテントタイプ（MINE content-types）のリスト、クライアントが受け入れることができるデータ符号化タイプのリスト、サーバに対するユーザの認証及び暗号化スキーム情報サーバに送られるメッセージのバイト長、及びサーバにアクセスするユーザのインターネットメールアドレスのような情報を含み得る。これらの情報のリストは、本発明を説明するために挙げたものであり、本発明の範囲を上述の特定のリクエストフィールドに限定しようとするものではない。ＨＴＴＰによって規定された任意のリクエストフィールドは、クライアントモジュール７０２によって使用され得る。しかし、この実施例では、デフォルト値が使用され、ＨＴＴＰリクエストフィールドは生成されない。
【０１５５】
ＨＴＴＰリクエスト生成プロセス８０２において生成され得る典型的なＨＴＴＰメソッドは、サーバ７４９からのＴＩＬデックか、もしくはサーバ７４９上での共通ゲートウェイインタフェースプログラムの実行をリクエストするＧＥＴメソッド、および共通ゲートウェイインタフェースプログラムに、ＵＲＬに添付された照会ストリングのようなデータをリクエストするＧＥＴメソッドである。何れの場合においても、ＵＲＬは特定のメッセージ内のサーバ７４９へ伝送される。ＨＴＴＰリクエスト生成プロセス８０２が終了した後、クライアントプロセスはリクエスト伝送プロセス８０４に進む。
【０１５６】
しかし、伝送制御プロトコルがＵＤＰの代わりに用いられる場合は、クライアントモジュール７０２は、サーバコネクション確立プロセス８０３において、ＵＤＰモジュール７１４に取って代わるＴＰＣモジュールにアクセスする。この実施例においては、ＵＤＰが使用されることから、コネクション確立プロセス８０３は図８において点線で囲まれて示されており、即ちこのプロセスがＵＤＰを使用する場合は不必要であることが示されている。
【０１５７】
サーバコネクション確立プロセス８０３においては、ＴＣＰインタフェースモジュール７１４とＨＴＴＰサーバ７４９におけるＴＣＰインタフェースモジュールとの間の仮想コネクションがＣＤＰＤネットワーク７１０上に形成され、ＴＣＰを用いたコンピュータ７４３と携帯電話機７００との間のデータ伝送が可能となり、即ち、データ交換をサポートするバッファが規定される。ＴＣＰコネクションの確立は、よく知られた技術であり、ここではこれ以上の説明は行わない。図８において、点線がサーバコネクション確立プロセス８０３とクライアントコネクション確立プロセス８０６との間を結合しており，クライアントコネクション確立プロセス８６０もまた点線で示されており、これはＨＴＴＰサーバ７４９によって実行される。このことは、クライアントモジュール７０２とサーバ７４９との双方が、プロセス８０３の実行を必要としているということを示している。
【０１５８】
ＴＣＰ仮想コネクションが確立されたとき、クライアントモジュール７０２は、処理をサーバコネクション確立プロセス８０３からリクエスト伝送プロセス８０４へと進める。同様に、サーバ７４９は、リクエスト受け取りチェックプロセス８６１へ進み、ここではサーバ７４９がリクエストを受け取るまで待機する。クライアントコネクション確立プロセス８６０はＵＤＰに対しては不要であり、ＨＴＴＰサーバ７４９は処理をリクエスト受け取りチェックプロセス８６１から開始する。プロセス８６０は、点線で示されており、これはこのプロセスがＴＣＰの場合にのみ使用されることを示している。
【０１５９】
リクエスト伝送プロセス８０４においては、ＨＴＴＰリクエストは、電話機７００内の作業領域からＨＴＴＰサーバ７４９に送られる。また、クライアントモジュール７０２のプロセス８０４とＨＴＴＰサーバ７４９によって実行されるリクエスト受け取りチェックプロセス８６１とは点線で結ばれており、これはこのチェックプロセスがクライアントモジュール７０２からの情報に従属していることを示している。リクエストの伝送が終了したとき、クライアントモジュール７０２は処理を応答受け取りチェックプロセス８０６に進める。
【０１６０】
ＨＴＴＰリクエストを受け取り格納したとき、リクエスト受け取りチェックプロセス８６１から、処理はリクエストサービスプロセス８６２に進み、ここではＨＴＴＰサーバ７４９が受け取ったリクエストのサービスを開始する。リクエストサービスプロセス８６２においては、ＨＴＴＰリクエストが静的デックの伝送をシークするのみの場合は、ＨＴＴＰサーバ７４９はＴＩＬデック７６０からリクエストされた静的デックを検索する。逆に、リクエストがサーバ７４９にインターネットからデータを得ることや、特定のファイルにデータを追加することを要求している場合は、サーバ７４９はリクエストにおいてアドレス指定された共通ゲートウェイインタフェースアプリケーションの実行を開始し、ＨＴＴＰリクエスト内のデータを、更に処理を行うためにこのアプリケーションに送る。
【０１６１】
例えば、携帯電話機７００のユーザが図２Ｆに示すようなＦＡＸ番号をリクエストした場合は、ＨＴＴＰリクエストは電話番号を入力データとして受け取り、ファクスされる情報を取り込むＣＧＩプログラム７６１内の共通ゲートウェイインタフェースアプリケーションを特定する。ＣＧＩアプリケーションは、ファクスゲートウェイに電子メール伝送データを生成する。同様に、株式市況の場合は、サーバ７４９が、ＨＴＴＰリクエストに応じて、インターネット１４０を介して株式市況サービスプロバイダに株式市況データを送る共通ゲートウェイインタフェースアプリケーションを起動する。このときサーバ７４９による入力データとしてチッカー記号が用いられ、これが共通ゲートウェイインタフェースアプリケーションに送られる。株式市況の応答を受け取ったとき、共通ゲートウェイインタフェースアプリケーションは株式市況に対する応答データを含むＰＩＤＬデックを構築する。
【０１６２】
リクエストのサービスが終了すると、ＨＴＴＰサーバ７４９は応答伝送プロセス８６３において、ＰＩＤＬデックをＴＩＬデックに変換し、このＴＩＬデックをＵＤＰを用いてクライアントモジュール７０２に戻す。応答伝送プロセス８６３はクライアントモジュール７０２における応答受け取りチェックプロセス８０６と点線で結ばれて示されている。ＴＩＬデックが伝送されると、クライアントモジュール７０２はこのデックをメモリ７１６に格納する。
【０１６３】
ＴＩＬデックが伝送された後、ＨＴＴＰサーバ７４９は携帯電話機７００からのメッセージに応答するためのプロセスを終了する。クライアントモジュール７０２がディスプレイスクリーン７０５上にユーザインタフェースを生成するが、ユーザインタフェースに示された任意の選択若しくはデータ入力に対する応答のために必要な全てのデータはＴＩＬデックに含まれている。従って、次のメッセージをＨＴＴＰサーバ７４９に伝送するためにクライアントモジュール７０２が行わなければならないのは、ＴＩＬデックの翻訳と、ユーザ入力の翻訳のみである。ＨＴＴＰサーバの状態は次のメッセージにおいて定められる。従って、ＨＴＴＰサーバ７４９は、メッセージが伝送された後にメッセージの応答に関連する状態情報を保持しないことから、無状態であるといえる。
【０１６４】
しかし、別の実施例（図示せず）においては、サーバは各クライアントモジュールとの対話に関連する状態情報を保持し得る。例えば、サーバが選択カードをクライアントモジュールに転送した場合、サーバは選択がクライアントモジュールからペンディングされていることを示す状態情報を保持する。この実施例においては、ユーザが選択を行ったとき、例えば２を選択するべく２のキーを押したとき、その選択はサーバへ伝送され、そこで選択２に関連するＵＲＬへのアクセスが行われる。このＵＲＬが別のアプリケーションをアドレス指定した場合、サーバはそのアプリケーションを実行する。従って、この実施例においては、サーバはクライアントモジュールとの各対話に関する状態情報を保持する。ここに開示した内容を参照することにより、当業者は、クライアント／サーバの組み合わせが有利である場合は、状態情報を保持するサーバを用いるような本発明の実施形態を実現できよう。
【０１６５】
もとの実施例に戻ると、ＴＴＬデックを受け取ったとき、クライアントモジュール７０２は応答受け取りチェックプロセス８０６を離れ、プロセス第１カード８０８に進む。しかし、ＵＤＰの代わりにＴＣＰが使用されている場合は、クライアントモジュール７０２は、プロセス８０６が終了すると、伝送終了プロセス８０７において仮想ＴＣＰコネクションを閉じる。仮想ＴＣＰコネクションを閉じると、処理はプロセス第１カード８０８に進む。また、伝送終了プロセス８０７は、点線で囲まれて示されており、これはプロセス８０７がＴＣＰの場合にのみ使用されることを示している。
【０１６６】
プロセス第１カード８０８においては、クライアントモジュール７０２がＴＩＬデックをパージングし、第１カードの翻訳を行う。処理は、プロセス第１カード８０８からディスプレイ生成プロセス８０９に進む。
【０１６７】
ディスプレイ生成プロセス８０９においては、クライアントモジュール７０２が第１カードにおいて表示されるデータをディスプレイモジュール７１２に送る。ディスプレイモジュール７１２は、このデータに応答して、データにおけるテキスト及び画像を、ディスプレイスクリーン７０５上に表示されるようにする。ディスプレイ生成プロセス８０９から、処理はノード８１３を通ってキープレスチェックプロセス８２０に進む。図８〜図１１において、同じ符号を有する円で示されたノードは、同じノードであることを表している。円で示されたノードは、図８〜図１１のメソッドにおける様々なプロセス間の結合が、図面ごとに切れ目無く続いていることを示すために用いられている。
【０１６８】
クライアントモジュール７０２は、ユーザが携帯電話機７００のキーパッド７１５上のキーを押すまでキープレスチェックオペレーション８２０において待機する。この実施例においては、携帯電話機７００が、２つのソフトキー、スクロールアップキー、スクロールダウンキー、前画面キー（ＰＲＥＶキー）、次画面キー（ＮＥＸＴキー）、及び一般的な電話のキーパッドの配置で配置された０〜９の数字キーをサポートしていることが仮定されている。以下の開示内容を参照することにより、これらのキーのうち、１または２以上のキーが存在していない場合は、当業者は、携帯電話機のキーパッドの特定の配置、若しくは双方向データ通信デバイスの他のキーパッドの配置を用いるように変形することが可能であろう。例えば、携帯電話機がｈｏｍｅキーを含んでいた場合は、後により詳しく説明するキープレス処理は、ｈｏｍｅキーが押されたとき、それを検出し、ｇｅｔ  ｈｏｍｅ  ＵＲＬプロセス８０１にその情報を伝送するチェックプロセスを含むことになる。
【０１６９】
要するに、図９〜図１０に示すプロセスは、ユーザによって押されたキーを識別し、要求されている動作を特定し、次いで処理を要求されている動作を実行するプロセスである。具体的には、キーパッド上のキーが押されたとき、キーパッドモジュール７１１は、そのキーの識別データを作業メモリ７１６に格納し、クライアントモジュール７０２にキーが押されたことを通知する。キーパッドモジュール７１１からの通知を受け取ると、クライアントモジュール７０２は、作業メモリ７１６におけるデータ格納位置を読み出し、キーが押されたか否かを判定して、処理をキープレスチェックプロセス８２０からスクロールキーチェックプロセス８２１に進める。
【０１７０】
スクロールキーチェックプロセス８２１においては、クライアントモジュール７０２は、ユーザがスクロールキーを押したか否かを判定する。スクロールキーが押されていた場合は、処理はディスプレイ調節プロセス８２２に進み、そうでない場合は表示カードチェックプロセス８２３に進む。
【０１７１】
ディスプレイ調節プロセス８２２においては、クライアントモジュール７０２は、スクロールアップキーまたはスクロールダウンキーの何れが押されたかを判定する。クライアントモジュール７０２は，次に、ディスプレイモジュール７１２に情報を送り、現在の表示が、１行スクロールアップされるか、若しくは１行スクロールダウンされる。スクロールキーが現在カードの境界を越えて表示を動かす場合は、スクロールキーが押されたことはディスプレイ調節プロセス８２２においては無視される。
【０１７２】
クライアントモジュール７０２からの情報に応答して、ディスプレイモジュール７１２は、ディスプレイスクリーン７０５上のスクリーンディスプレイを調節する。クライアントモジュール７０２は、処理をディスプレイ調節プロセス８２２からノード８１３を通してキープレスチェックプロセス８２０に進める。
【０１７３】
スクロールキーが押されなかった場合は、処理はスクロールキー調節プロセス８２１を通過して、ディスプレイカードチェック調節プロセス８２３に進む。クライアントモジュール７０２は、ディスプレイスクリーン７０５に現在表示されているカードの特定のタイプに従って動作を行う。現在カードが表示カードである場合は、クライアントモジュール７０２は表示カードチェック調節プロセス８２３を通して、ソフトキーチェックプロセス８２８に処理を進め、そうでない場合は選択カードチェックプロセス８２４に処理を進める。
【０１７４】
現在カードが表示カードでない場合を仮定すると、選択カードチェックプロセス８２４では、現在カードが選択カードであるか否かを判定する。現在カードが選択カードである場合は、クライアントモジュール７０２は、処理を選択カードチェックプロセス８２４を通過させて、選択キーチェックプロセス８２６に進める。そうでない場合は処理をデータキーチェックプロセス８２６に処理を進める。
【０１７５】
現在カードが表示カードでも選択カードでもない場合を仮定すると、この実施例ではカードのタイプとして３種類だけが規定されていることから、現在カードは入力カードであるということになる。従って、クライアントモジュール７０２は、入力カードに対するチェックは行わない。逆に、データキーチェックプロセス８２６では、有効データキーが押されたか否かが判定される。この実施例においては、データキーはキーパッド上の０から９の数字キー及び＃キーである。他の実施例においては、キーの別の組み合わせがデータキーとして規定される。押されたキーがデータキーの何れかである場合は、データキー６から処理はデータ入力プロセス８２７に進み、そうでない場合はソフトキーチェックプロセス８２８に進む。
【０１７６】
データ入力プロセス８２７においては、クライアントモジュール７０２は、予測テキスト入力プロセスがオン状態にあるか否かを知っている。というのは、【ＰＩＤＬ及びＴＩＬの記述】の項に記載されているように、入力カード上のパラメータの１つが予測テキスト入力プロセスを用いているか否かを特定しているからである。
【０１７７】
予測テキスト入力プロセスがオン状態にない場合は、クライアントモジュール７０２は、データ入力プロセス８２７において、作業メモリ７１６内のテキスト入力バッファの適当な位置に押されたキーの値を入力する。また、クライアントモジュール７０２は、ディスプレイモジュール７１２に情報を送り、ディスプレイモジュール７１２によって、押されたキーの値がディスプレイスクリーン７０５上の適当な位置に表示される。
【０１７８】
予測テキスト入力プロセスがオン状態にある場合は、クライアントモジュール７０２は、データ入力プロセス８２７において新規な予測テキスト入力プロセスを用いて、後に図１２、図１３〜図３２、及び図３３を参照しつつ詳しく説明するように、押されたキーに関連する文字の組から選択すべき文字を決定する。予測テキスト入力プロセスが適当な文字を決定した後、その文字を表す値が作業メモリ７１６内のテキスト入力バッファにおける適当な位置に格納される。また、クライアントモジュール７０２は、ディスプレイモジュール７１２に情報を送り、ディスプレイスクリーン７０５上の適当な位置にその文字が表示されることになる。データ入力プロセス８２７が終了すると、クライアントモジュール７０２は、処理をノード８１３を通してキープレスチェックプロセス８２０に進める。
【０１７９】
前の説明においては、現在カードが入力カードであることが仮定されていたが、現在カードが選択カードである場合は、選択カードチェックプロセス８２４から処理が選択キーチェックプロセス８２６に進む。選択カードに対するディスプレイ生成プロセス８０４において、各選択肢は、選択カード上の情報に基づいてラベル付けされ、選択肢の一部若しくは全てが、ディスプレイスクリーン７０５上に表示される。従って、選択キーチェックプロセス８２６では、押されキーが選択肢の１つに対応しているか否かが判定される。押されたキーが選択肢の１つである場合は、クライアントモジュール７０２は、一実施例においては、情報をディスプレイモジュール７１２に送り、選択去れた選択肢を表示させる。クライアントモジュール７０２は、選択キーチェックプロセス８２６からノード８３１を通して、処理を識別子格納プロセス８５０（図１１参照）に進める。このプロセス８５０については後に詳述する。逆に、押されたキーが選択肢の１つに相当しない場合は、選択キーチェックプロセス８２６から、処理はソフトキーチェックプロセス８２８に進む。
【０１８０】
ソフトキーは、１つのデック全体と各カードの双方に対して特定され得る。即ち、キーパッド上の物理的キーが、後に【ＰＩＤＬ及びＴＩＬの記述】の項において詳述するように、ソフトキーのように特定される。各ソフトキーの指定内容には、ソフトキーが押されたとき行われる動作を定める識別子が含まれている。
ソフトキーが１つのデックに対して特定されるとき、ソフトキーはデック全体に対して有効な状態にある。しかし、ソフトキーが１つのカードに対して特定されるときは、そのカードソフトキー指定内容は、対応するデックソフトキー指定内容、即ち、ディスプレイスクリーン７０５上に表示されているそのカードソフトキー指定内容と同じ物理的キーのデックソフトキー指定内容に一時的に優先する。このキーの優先機能は、２つのソフトキーに対してそれぞれ別個に与えられる。従って、押されたキーが２つの使用可能な物理的ソフトキーの何れか一方である場合、ソフトキーチェックプロセスから、処理は第１ソフトキーチェックプロセス８２９に進む。逆に、２つの使用可能な物理的ソフトキーの何れもがユーザによってなされない場合は、ソフトキーチェックプロセス８２８から、処理はＮＥＸＴキーチェックプロセス８４０（図１０参照）に進む。
【０１８１】
第１ソフトキーチェックプロセス８２９において、クライアントモジュール７０２は、第１ソフトキーに相当するキーが押されたか否かを判定する。押されたキーが第１ソフトキーである場合は、チェックプロセス８２９から、ノード８３１を通して識別子格納プロセス８５０に第１ソフトキーに対するアクティブ識別子が送られる。逆に押されたキーが第１ソフトキーでない場合は、処理はチェックプロセス８２９から第２、ソフトキーチェックプロセス８３０に進む。
【０１８２】
押されたキーが第２ソフトキーである場合は、チェックプロセス８３０から、ノード８３１を通して識別子格納プロセス８５０に第２ソフトキーに対すアクティブ識別子が送られる。逆に、押されたキー第２ソフトキーでない場合、即ちソフトキーとして規定され得る物理的キーが押されたが、現在デック及び現在カードの何れもが、その物理的キーに対するソフトキーを規定していない場合、処理は、チェックプロセス８３０からノード８１３を通してキープレスチェックプロセス８２０に進む。
【０１８３】
処理がＮＥＸＴキーチェックプロセス８４０に進んだとき、クライアントモジュール７０２は押されたキーがＮＥＸＴキーか否かを判定する。ＮＥＸＴキーが押された場合は、処理は表示カードチェックプロセス８４１に進み、そうでない場合はＰＲＥＶキーチェックプロセス８４６に進む。
【０１８４】
表示カードが現在カードである場合は、そのＮＥＸＴキーはデック内の別のカード、若しくはその代わりに別のデックに移動するために使用される。従って、表示カードが現在カードである場合は、処理は表示カードチェックプロセス８４１から最終カードチェックプロセス８４２に進み、そうでない場合は入力カードチェックプロセス８４３に進む。
【０１８５】
最終カードチェックプロセス８４２では、現在カードがデック内の最終カードか否かが判定される。現在表示されているカードがデック内の最終カードでない場合は、最終カードチェックプロセス８４２から、処理は次カード読み出しプロセス８４５に進み、ここではデック内の次カードの読み出しが行われ、ノード８１２を通して次のディスプレイ生成プロセス８０９に進む。
【０１８６】
現在カードがデック内の最終カードである場合は、デックはその最終カードから進むべき先の位置を特定する識別子を含む。この識別子は、例えば、別のデックへの、共通ゲートインタフェースプログラムへの、若しくは現在デック内の１つのカードのアドレスへのＵＲＬであり得る。従って、現在表示カードがデック内の最終カードであるときは、最終カードチェックプロセス８４２から、処理はノード８３１を通して識別子格納プロセス８５０に進む。
【０１８７】
現在カードが表示カードではないが、入力カードである場合は、表示カードチェックプロセス８４１から、処理は入力カードチェックプロセス８４３に進む。この実施例では、ＮＥＸＴキーが入力カード上の全てのデックが入力されたことを示すのに使用される。従って、現在カードが入力カードである場合は、入力カードチェックプロセス８４３から、処理はデータ格納プロセス８４４に進む。
【０１８８】
データ格納プロセス８４４では、現在入力カードにおいて特定されたメモリ内の適当な位置に入力されたデータを格納する。典型的には、引数としてＵＲＬと結合され、格納される。処理が終了すると、データ格納プロセス８４４から、処理はノード８１０を通してＨＴＴＰリクエスト生成プロセス８０２（図８参照）に進む。
【０１８９】
ＮＥＸＴキーが押されたとき、現在カードが表示カードでも入力カードでもない場合は、現在カードは選択カードである。しかし、上述のように、この実施例においては、クライアントモジュール７０２はユーザが選択を行うことを要求し、ＮＥＸＴキーを用いることができないようにしている。従って、現在カードが入力カードでない場合は、入力カードチェックプロセス８４３から、処理はノード８１３を通してキープレスチェックプロセス８２０に進む。
【０１９０】
前述の議論においては、ＮＥＸＴキーが押され、ＮＥＸＴキーチェックプロセス８４０から処理が表示カードチェックプロセス８４１に進んだことを仮定していた。しかし、ＮＥＸＴキーが押されなかった場合は、ＮＥＸＴキーチェックプロセス８４０から、処理はＰＲＥＶキーチェックプロセス８４６に進む。ＰＲＥＶキーが押された場合は、チェックプロセス８４６から、処理は第１カードチェックプロセス８４７に進み、そうでない場合はキープレスチェックプロセス８２０に戻る。
【０１９１】
第１カードチェックプロセス８４７では、現在カードがデックの第１カードであるか否かが判定される。現在カードが第１カードでない場合は、処理は第１カードチェックプロセス８４７から前カード読み出しプロセス８４９に進み、ここでは前カードの読み出しが行われ、処理はノード８１３を通してディスプレイ生成プロセス８０９に進む。逆に、現在カードが第１カードである場合は、処理はホームデックチェックプロセス８４８に進む。
【０１９２】
現在カードが、ホームデックにおける第１カードである場合は、前カードは存在せず、ホームデックチェックプロセスから、処理はキープレスチェックプロセス８２０にノード８１３を通して進み、ＰＲＥＶキーが押されたことは無視される。現在デックがホームデックでない場合は、ホームデックチェックプロセス８２８において、前デックに対する識別子が検索され、処理はノード８３１を通して識別子格納プロセス８５０に進む。
【０１９３】
処理はいくつかの異なる点からノード８３１を通して識別子格納プロセス８５０に達する。識別子格納プロセス８５０における処理は、プロセス８５０に進んでくる前の特定のプロセスに関係なく同一である。どのプロセスから来る場合でも、識別子は識別子格納プロセス８５０に送られ、プロセス８５０ではその識別子を作業メモリ７１６内に格納する。この識別子は、例えば、現在カード内の別の位置に対するポインタ、現在デック内の別のカードのアドレス、作業メモリ７１６に格納されたデックへのＵＲＬ、コンピュータ７４３上のＴＩＬデック７６０におけるＴＩＬデックへのＵＲＬ、またはコンピュータ７４３上のＣＧＩプログラム７６１における共通ゲートウェイインタフェースプログラムへのＵＲＬであり得る。従って、プロセス８００では、格納された識別子がチェックされ、必要な処理が確認される。
【０１９４】
具体的には、現在デックプロセス８５１への識別子においては、クライアントモジュール７０２は、その識別子が現在デック内のカードに対するものか否かを判定する。その識別子が現在デックを指定するものである場合は、チェックプロセス８５１から処理はデータ検索プロセス８５２に進み、そうでない場合は、その識別子はローカルデックチェックプロセス８５３へのＵＲＬである。
【０１９５】
データ検索プロセス８５２においては、クライアントモジュール７０２が作業メモリ７１６からの識別子によって示された位置に格納された情報を検索し、その情報を処理する。データ検索プロセス８５２から、処理はノード８１２を介して上述のディスプレイ生成プロセス８０９（図８参照）に進む。
【０１９６】
ローカルデックチェックプロセス８５３へのＵＲＬは、識別子が、作業メモリ７１６に格納された、即ちキャッシュされたデックへのＵＲＬであるか否かを決定する。このデックがローカルに格納されている場合は、チェックプロセス８５３から、処理はローカルデック検索プロセス８５４に進み、ここでローカルデックが現在デックに対する格納位置に移動させられる。ローカルデック検索プロセス８５４から、処理はノード８１１を通って、上述の第１カード処理プロセス８０８（図８参照）に進む。
【０１９７】
識別子が現在デックの位置に対するものでも、ローカルデックの１つに対するものでもない場合は、この識別子はコンピュータ７４３上のオブジェクトに対するＵＲＬである。従って、この場合、チェックプロセス８５３から、処理はノード８１０を通してＨＴＴＰリクエスト生成プロセス８０４に進む。
【０１９８】
処理８００は与えられた情報をユーザ側に入力し処理している限り続行される。この実施例においては、処理８００は、例えば、ユーザが携帯電話機７００の電源を切るか、クライアントモジュール７０２の動作を停止させる選択肢若しくは入力カードを選択するか、タイムアウト時間より長い時間非アクティブ状態におかれ、クライアントモジュール７０２は自動的にオフ状態になることによって終了する。
【０１９９】
処理８００における個々のプロセスについて更に説明する。プロセス８０２によって生成されたＨＴＴＰリクエストに応答するＴＩＬデックとして、クライアントモジュール７０２に戻る以下の例を考えられたい。呼び出し可能性については、表２はＰＩＤＬにおけるデックを表している。この例では全ての選択肢が同じサーバ上のアプリケーションに対応している。しかし、別の実施例においては、各ＵＲＬは所望のサーバの組み合わせをアドレス指定し得る。
【０２００】
【表２】
0004274661.tif 000003
【０２０１】
第１カード処理プロセス８０８においては、クライアントモジュール７０２は表２における情報を翻訳し、処理をディスプレイ生成プロセス８０９に進める。ディスプレイ生成プロセス８０９においては、クライアントモジュール７０２は情報をディスプレイモジュール７１２に送り、ユーザに対しディスプレイスクリーン７０５上の３つの選択肢のリストを表示する。即ち、例えば、
１．ニュース（News）
２．天気予報（Weather）
３．スポーツ（Sports）
のような選択カードのユーザインタフェースが生成される。
【０２０２】
ディスプレイ生成プロセス８０９（図８参照）から、処理はキープレスチェックプロセス８２０（図９参照）に進む。ユーザがキーパッド７１５上の２のキーを押したとき、キープレスチェックプロセス８２０から、処理はチェックプロセス８２１を通って、表示カードチェックプロセス８２３に進む。
【０２０３】
現在カードが選択カードであることから、チェックプロセス８２３から、処理は選択カードチェックプロセス８２４に進み、ここで更に処理は選択キーチェックプロセス８２６に進む。第２のキーが押され、そのキーが選択キーであることから、チェックプロセス８２６から、処理は識別子格納プロセス８５０（図１１参照）に進む。プロセス８５０においては、クライアントモジュール７０２は、２に対応するＵＲＬを格納する。即ち、作業メモリ７１６に、
URL=http://wwwlibris.com/airnet/www  が格納される。
【０２０４】
このＵＲＬがコンピュータ７４３上のオブジェクトに対するものであることから、処理は、チェックプロセス８５１及び８５３を通って、ＨＴＴＰリクエスト生成プロセス８０２に進み、ここでリクエストが生成される。プロセス８０４に関連して上述したように、ＨＴＴＰリクエストがサーバ７４９に送られると、サーバ７４９は、サービスリクエストプロセス８６２において、ＴＩＬデック７６０からデックＷＷＷを検索する。デックの例は表３において示されている。また、可撓性のために、デックはＰＩＤＬで示されている。
【０２０５】
【表３】
0004274661.tif 000004
表３のデックは携帯電話機７００に送られ、プロセス８０６に関連して上述したように、メモリ７１６内に格納される。選択カードはプロセス８０８において処理され、プロセス８０９において表示される。プロセス８０９の結果、ユーザには、例えば、
１．世界（World）
２．国内（National）
３．州（State）
４．ローカル（Local）
のような選択肢のリストが提示される。
【０２０６】
ユーザが他の選択肢を選択したとき、第１選択カードに対して上述したのと同様の処理のシーケンスがクライアントモジュール７０２によって実行され、サーバ７４９上のプログラムを指定する別のＵＲＬが格納されて、所望の天気予報情報が検索され、その情報のデックが生成される。このデックは携帯電話機７００に転送され、表示される。
【０２０７】
上述のように、現在カードが入力カードであり、キーが押された場合は、クライアントプロセス７０２は処理をデータキープレスチェックプロセス８２６（図９参照）に進める。押されたキーが有効データである場合は、チェックプロセス８２６から処理はデータ入力処理プロセス８２７に進む。
【０２０８】
１実施例においては、データ入力処理プロセス８２７は、テキスト入力に対して新規な予測テキスト入力プロセスを利用する。典型的な電話のキーパッド上において、キーに数字と２または３の文字が付してあることを思い出されたい。例えば、２のキーにはａｂｃなる文字が記入されている。このことによって電話のキーパッドを用いてテキストを入力した場合多少の曖昧さが伴うことになる。ユーザが２のキーを押したときａ、ｂ、ｃのうちどの文字を表すつもりでいたのであろうか。
【０２０９】
従来の方法においては、テキストの各文字を入力するために２回のキーストロークが必要であった。第１キーストロークは第１キーを特定し、第２キーストロークは第１キー上の特定の所望の文字を特定していた。例えば、文字ｓを入力するために、ユーザは初めに文字ｐ、ｒ、ｓを有する７のキーを押す。次に、ユーザは３のキーをおして文字ｓを選択する。この方法は３つか４つの文字からなる短い文字列に対しては有効であったが、英語の文章を入力するのには不向きである。例えば、ユーザがすでにｔｈと入力しており、次に文字ｄ、ｅ、ｆをラベル付けされた３のキーを押す場合、次に押したい文字は文字ｅであることが多い。従って、ユーザが２のキーを押すことは余分な不必要なステップである。
【０２１０】
本発明のクライアントモジュール７０２は新規の予測テキスト入力プロセスを利用して、電話のキーパッド、若しくは例示したキーパッドを用いてテキストを入力するのに必要なキーストローク数を低減している。このプロセスを用いることにより、殆どの場合一回のキーストロークで１つの文字を入力することができるようになる。
【０２１１】
本発明のこの実施例は、電話キーパッドを用いる場合について述べているが、本発明の原理は電話のキーパッドに限定されるものではない。一般に以下に詳述するプロセスは、１つのキーが２もしくはそれ以上の文字を入力するのに用いられるような任意のキーパッドに対して拡張され得る。更に、このプロセスは文字に限定されず、１つのキーが２もしくはそれ以上のキャラクタを表すのに用いられるような任意のキーパッドに対して適用可能である。以下の開示内容を参照することにより、当業者はこの予測テキスト入力プロセスの原理を、様々な応用対象に適用することができるであろう。
【０２１２】
予測テキスト入力に対するシステムは、本実施例においてはクライアントモジュール７０２に含まれている予測テキスト入力モジュール９０１、キーボードモジュール７１１、及びクライアントモジュール７０２が動作状態にあるときメモリ７１６にロードされる文字頻度テーブル９０２を有する。予測テキスト入力モジュール９０１は、現在入力カードによって特定され、データ入力処理プロセス８２７において用いられる。予測テキスト入力モジュール９０１は、ルーチンバッファ管理プロセスを実行するが、このプロセスは当業者にはよく知られたものであり、重要な処理の説明から話が逸れるのを避けるためここでは説明しない。予測テキスト入力モジュール９０１は、メモリ７１６内のテキストバッファ９０１に、入力された各文字に対する文字入力を格納する。この実施例においては、文字Ｑ及びＺは１のキーに割り当てられており、０キーは、スペース、ピリオド、及びカンマを入力するのに用いられる。即ち、０キーは句読点を表す。しかし、このような割り当ては１つの例であって本発明をこの特定の実施例に限定しようとするものではない。
【０２１３】
入力された第１の文字は、バッファの左端に配置される。また、これに追加される各文字はバッファ９０３内の使用されていない空間の左端にそれぞれ配置される。従って、テキストバッファ９０３に入力された最後の文字は、最も右側に配置された文字である。予測文字エントリテーブルと称されることもある文字頻度テーブル９０２は、ルックアップテーブルであって、ここではテーブル内の各エントリが３つのインデックスによりアドレス指定される。初めの２つのインデックスは、テキストバッファ９０３に最後に入力された２つの文字を表し、第３のインデックスは、押されたキーを表す。文字頻度テーブル９０２に格納された各予測文字エントリは、前の２つの文字が与えられているとき、押されたキーに関連するどの文字が使用されるかを規定する。例えば、“ｔｈｅ”は一般によく現れる文字列であることから、（ｔ，ｈ，３）によりアドレス指定されたテーブル９０２内のエントリは、“ｅ”となり、もしくは更に正確に言えば、予測文字エントリ“２”は、３つのキーに関連する文字のグループｄ、ｅ、ｆの第２の文字が予測された文字であることを表すことになる。当然、文字頻度テーブル９０２は、複数の文字を解すように変更され得る。
【０２１４】
この実施例においては、文字頻度テーブル９０２は、電子メールにおける文章を用いて経験的に生成されたものである。図４５〜図５０のコンピュータプログラムリストは、図１３〜図３２に示す文字頻度テーブル９０２を生成するのに用いられたコンピュータプログラムリストである。要するに、このコンピュータプログラムはデータの供給から、（ｉ）キーパッド上の各キーに対して対応し得る各文字に対し、最も可能性の高い文字を決定し、（ｉｉ）キーパッド上の各キーにおける可能性のある２つの文字の組み合わせのそれぞれに対して、最も可能性の高い文字を決定する過程に至る、連続的なプロセスを実現したものである。この実施例においては、最も可能性の高い文字はその１つの文字の次に続く頻度が最も高い文字である。同様に、この最も可能性の高い文字は、その２つの文字の組み合わせの後に続く頻度が最も高い文字である。頻度において結びつきが存在する場合は、そのキーに関連する第１の文字が選択される。当然、他の可能性の測定値を、テーブル９０２におけるエントリを生成するのに用いることもできる。
【０２１５】
従って、図１３〜図３２において、始めの１０列、即ち最も左側の列は、２つの文字の列を表し、第１行、即ち最上部の行はテキストを入力するのに用いられたキーパッド上のキーである。第１列におけるエントリの組み合わせ及び最上行におけるキーは、予測されたテキスト入力を選択するのに使用される。従って、“ｔｈ”の例を用いると、この２つのキー列は、図１３〜図３３のそれぞれにおける第１列に現れる。３つのキーが押されたとき、第１エントリとして“ｔｈ”を有する行における文字及び第１エントリとして、３、即ち“ｅ”を有する列における文字が検索される。別の形態として、４つのキーが押された場合、文字ｉがテーブルから検索される。
【０２１６】
この実施例においては、テーブル９０２は２ビットの数のバッファである。各２ビットの数は０〜３の範囲内の値を有し、この２ビットの数はその押されたキーに対する予測された文字を表す。従って、文字Ａ、Ｂ、Ｃがラベル付けされた２つのキーに対しては、０はＡを表し、１はＢを表し、２はＣを表す。一般に、使用されるビット数は文字の数の最大値を表すキーによって決定される。この実施例においては、キーによって表される使用される文字の数の最大値は３である。必要な格納ビット数は整数Ｓであり、ここでＳは２のＳ乗が、キーによって表される文字数の最大値以上であるように定められた最小の数である。
【０２１７】
この実施例においては、３つのインデックスｉ０、ｉ１、及びｉ２がテーブルインデックスを生成するのに用いられ、テーブルインデックスは２ビットの数のテーブル９０２における特定の予測文字エントリにアクセスするのに使用される。各文字は数、即ち文字Ａが０、文字Ｂが１、文字Ｃが２、そして文字Ｚが２５であるような文字入力として表される。スペース要素はスペース要素値２６として割り当てられる。従って、この実施例では、２７個の使用可能な文字が存在する。
【０２１８】
処理１１００（図３３参照）に初期入力があったとき、文字インデックスｉ０、ｉ１、及びｉ２は入力カードの始めの処理において２６にセットされ、テキストバッファが空であることを示すようにされる。また、後に詳細に述べるように、テキストの各文字が入力されたとき、文字インデックスｉ０、ｉ１は更新され、メモリ７１６に格納される。
【０２１９】
しかし、別の実施例においては、初期化インデックスプロセスは予測テキスト入力プロセス１１００における初めのオペレーションである。この実施例においては、第１の文字の入力に対して、文字インデックスｉ０及びｉ１が２６にセットされ、第２の文字が入力された場合、文字インデックスｉ０は２６にセットされ、文字インデックスｉ１は、テキストバッファ９０３における文字値にセットされ、初めの２つの文字が入力された後全ての文字が入力されたとき、テキストバッファ９０３におけるその次の文字から最後の文字に関連する値は、文字インデックスｉ０に割り当てられ、テキストバッファ９０３における最後の文字に関連する値は文字インデックスｉ１に割り当てられる。
【０２２０】
句読点キーチェックプロセス１１０１で、０キーが押されたか否か、即ち句読点を表すキーが選択されたか否かが判定される。
【０２２１】
０キーが押された場合は、処理は、チェックプロセス１１０１からプロセス句読点入力プロセス１１０２に進む。プロセス句読点入力プロセス１１０２では、インデックスｉ２を２６にセットし、スペース要素値を文字表示プロセス１１０８に送る。文字表示プロセス１１０８では、スペース要素値をディスプレイモジュール７１２に送り、ここでディスプレイスクリーン７０５上に文字入力におけるスペースを表示させる。これにより、０キーを押したことに対するデータ入力プロセスが終了し、処理はキープレスチェックプロセス８２０に戻る。
【０２２２】
０キーが押されなかった場合は、処理は、データ入力プロセス１１００における句読点キーチェックプロセス１１０１を通って、キー１〜９チェックプロセス１１０３に進み、即ちデータ入力キーチェックプロセスに進む。押されたキーが１のキーから９のキーの何れかである場合は、チェックプロセス１１０３から、文字インデックスセットプロセス１１０４に進み、そうでない場合は最終入力回転プロセス１１０９に進む。
【０２２３】
文字インデックスセットプロセス１１０４において、押されたキーの数値から１が引かれ、計算結果の値はインデックスｉ２に割り当てられる。インデックスセットプロセス１１０４から、処理はテーブルインデックス生成プロセス１１０５に進む。
【０２２４】
テーブルインデックス生成プロセス１１０５では、インデックスｉ０、ｉ１、およびｉ２を結合して、テーブルインデックスを生成する。この実施例においては、テーブルインデックスＴＡＢＬＥ ＩＮＤＥＸが以下のように定義される。
ＴＡＢＬＥ ＩＮＤＥＸ＝（（（ｉ０＊２７）＋ｉ１）＊９）＋ｉ２
ＴＡＢＬＥ ＩＮＤＥＸ生成プロセス１１０５が終了すると、テキスト入力生成プロセス１１０６において、テーブル内のＴＡＢＬＥ ＩＮＤＥＸにより規定された位置における２つのビット値が検察され、この２つのビット値はそのビット値で表される文字に変換される。
【０２２５】
テキスト入力生成プロセス１１０６から、処理はインデックス更新プロセス１１０７に進み、ここでは文字インデックスｉ１の値が、文字インデックスｉ０として格納され、文字インデックスｉ１における検察された文字の値が格納され、テキストバッファ９０３における予測された文字が格納される。この処理ステップでは、文字インデックスｉ０、ｉ１が格納され処理８２７において毎回アクセスされることが仮定されているが、別の形態として、テキストバッファ９０３における最後の２つの文字が検索され、それぞれ上述のようにインデックスｉ０及びｉ１に割り当てられる場合もあり得る。
【０２２６】
インデックス更新プロセス１１０７から、処理は文字表示プロセス１１０８に進む。文字表示プロセス１１０８では情報をディスプレイモジュール７１２に送り、そこで予測された文字をディスプレイスクリーン７０５上に発生する。
【０２２７】
押されたキーが１から９までのキーの１つでない場合、即ちデータ入力キーでない場合は、処理はチェックプロセス１１０３から最終入力交替プロセス１１０９に進む。データキーチェックプロセス８２６において押されたキーが０から９までのキーもしくは＃キーの何れかであるか否かが判定されたことを想起されたい。従って、チェックプロセス１１０１〜１１０３では、０から９までのキーが押されていないことが判定されたことから、押されたキーとして残っているのは＃キー、即ち入力交替キーのみであり、これはユーザがテキストバッファ９０３に最後に入力されたものとは異なる文字の入力を希望していることを示している。最終入力交替プロセス１１０９においては、最終文字、即ちテキストバッファ９０３において最も右側にある文字が、＃キーが押される前に押された最後のキーに割り当てられた文字のセットにおける次に文字によって書き換えられる。また、＃キーの使用は本発明の１つの実施例を示すものであり、本発明の範囲を入力を交替させるのに特定のキーを使用するものに限定しようとするものではない。
【０２２８】
例えば、テキストバッファ９０３における最後の文字がＴであり、＃キーが押された場合は、処理１１０９においてｔがｕに変更される。＃キーがもう一度押された場合は、ｕがｖに変更される。別の実施形態においては、テキストバッファ９０３における最後の文字がｕであり、＃キーが押された場合は、処理１１０９において、ｕがｖに置き換えられる。テキストバッファ９０３における最後の文字がｖであり、＃キーが押された場合は、処理１１０９において、ｖはｔに置き換えられる。インデックスｉ１が格納されている場合は、テキストバッファ９０３における最終文字が交替されたとき、インデックスｉ１は更新される。
【０２２９】
異なる言語またはコンテキストで入力された携帯電話機７００におけるテキスト入力は、異なる文字頻度テーブルを用いることによりサポートされ得る。例えば、配管工事用としては、予測テーブルは、配管の手順に関するテキストに基づいたものであり得る。フランス人用としては、予測テーブルはフランス語のテキストに基づいたものであり得る。また、携帯電話機７００に多重文字頻度テーブルを格納したり選択的に伝送したり、特定の文字頻度テーブルが入力カード上で選択されるようにすることもできる。
【０２３０】
更に、テーブル内のエントリは１つ以上の文字からなるものであり得、従ってより多くのキーストロークを節約することもできる。例えば、テキストバッファが“ｓｃｈｅ”を含んでいる場合、次に３をタイプすると、単に文字ｂが戻ってくるのではなく、“ｄｕｌｅ”が戻ってくるようにすることが可能である。更に、テキスト入力のこの新規な方法は、携帯電話機以外にも使用することが可能である。この方法は、キーパッド上の１つのキーにいくつかの文字が割り当てられたあらゆるデバイスに適用可能である。
【０２３１】
上述の実施例においては、文字セットとして英語のアルファベット及びスペース要素が使用された。従って、テーブルインデックスを規定するのに使用された数２７は、文字セットになった文字の数Ｎと同じである。同様に、テーブルインデックスを規定するのに使用された数９は、２またはそれ以上の異なる文字を表すキーパッドにおけるキーの数Ｍと同じである。従って、本発明の予測テキスト入力方法は、文章に限定されず、各キーが複数の異なる文字を表すような任意のキーパッドに直接適用することが可能である。
【０２３２】
図７〜図１２の実施例においては、クライアントモジュール７０２及びサーバモジュール７４９は、ＣＤＰＤネットワーク７１０を通して通信を行う。しかし、このアーキテクチャは本発明の原理を説明するための例であり、本発明の範囲をここに記述する特定のアーキテクチャに限定しようとするものではない。クライアントモジュール７０２及びサーバモジュール７４９は、様々な双方向データ通信リンクにおいて、リソースロケータ、即ちＵＲＬ及びＴＩＬデックを交換するのに使用され得る。例えば、この通信リンクは、クライアントモジュール７０２及びサーバモジュール７４９がモデムを使用した通信を行うような音声回路に切り替えることが可能である。別の実施形態では、この通信リンクは、クライアントモジュール７０２がサーバモジュール７４９へリクエストを行うことができ、かつサーバモジュール７４９がクライアントモジュールにデータを返すことができる限り、他のパケット交換ネットワークにする事ができる。更に、ＨＴＴＰサーバ７４９の代わりに特別な目的のサーバを使用することができる。例えば、本発明の原理は、回路交換データ及びパケット交換データを含む様々なデータ伝送機構において使用され得る。このようなデータ伝送機構はＧＳＭ、ＴＤＭＡ、及びＣＤＭＡを含むほとんどのセルラーネットワーク基準を満たすように規定され実現される。
【０２３３】
無線通信ネットワーク７５０（図７参照）の構成においては、クライアントモジュール７０２はサーバコンピュータ７４３と直接通信を行っていた。別の実施形態においては、図５に示すように、双方向データ通信デバイスが初めに無線通信ネットワークトランスレータ５００と通信を行い、そこで適当なサーバとの通信が行われていた。この実施例では、双方向データ通信デバイス１００、１０１、及び１０２の動作が、プロセス８０２において生成されるリクエストにおけるメソッドフィールドが異なる形態である点を除いて、上述の携帯電話機７００に類似している。例えば、前述のものと同じ情報を用いると、この実施例におけるメソッドフィールドは、
GET http://www.libris.com/airnet/home.cgi?&cost=1 ANTP/1.0
となる。このメソッドフィールドには、サーバの全アドレス、サービスにかかるコスト、及び無線通信ネットワークトランスレータ５００との通信に使用されるプロトコルのバージョンが含まれている。双方向データ通信デバイスは、完全なＵＲＬを含むＨＴＴＰリクエストを、無線通信ネットワークトランスレータ５００に伝送する。
【０２３４】
図３４は、本発明の原理に基づく、無線通信ネットワークトランスレータ５００の一実施例の構造を示すより詳細なブロック図である。この実施例においては、無線通信ネットワークトランスレータ５００が、ＣＤＰＤネットワーク７１０に対するインタフェースを有するＵＮＩＸオペレーティングシステムのもとで動作するコンピュータである。このようなコンピュータは、当業者にはよく知られたものである。従って、ここではこのようなコンピュータに追加されなければならない構造及び処理についてのみ記述するものとする。
【０２３５】
無線通信ネットワークトランスレータ５００は、ＣＤＰＤネットワーク７１０を介してそのトランスレータ５００がやり取り可能な各コンピュータネットワークに対するインターネットプロトコル（ＩＰ）コネクションをサポートする。この実施例においては、ネットワークトランスレータ５００における各モジュールはコンピュータ内のプロセッサによって実行されるプロセスである。コントロールモジュール１２０１は、ＣＤＰＤネットワーク７１０からのＩＰコネクションを通した伝送をすべて傍受する守護神（daemon）である。コントロールモジュール１２０１が伝送を傍受したとき、コントロールモジュール１２０１はＡＮＴリクエストプロセッサ１２０４を起動する。このＡＮＴリクエストプロセッサ１２０４は、本実施例においては、上述のように１つのプロセスである。図３４においてはＡＮＴリクエストプロセッサ１２０４がただ１つだけ示されているが、コントロールモジュール１２０１が受け取る各伝送に対して生成された（spawned）ＡＮＴリクエストプロセッサが存在し、ＡＮＴリクエストプロセッサは、通信が終了するまでアクティブ状態を維持する。
【０２３６】
図３５は、ＡＮＴリクエストプロセッサ１２０４の動作を説明するためのプロセス流れ図である。このプロセス流れ図は、ＴＣＰ／ＩＰ及びＵＤＰ／ＩＰの双方を利用する伝送を考慮に入れている。しかし、ＴＣＰ／ＩＰのみに特定されたプロセスは、点線で囲まれた部分において示されている。ＴＣＰ／ＩＰに対して起動したとき、確立されたコネクションプロセス１３００において、ＡＮＴリクエストプロセッサ１２０４はサーバ内のＴＣＰモジュールを用いて、ＣＤＰＤネットワーク７１０を介してクライアントモジュールとＴＣＰコネクションを確立する。コネクションが確立された後、処理はプロセス１３００からリクエスト受け取りチェックプロセス１３０１に進む。
【０２３７】
ＵＤＰが使用されている場合、ＡＮＴリクエストプロセッサ１２０４が生成されたとき、リクエスト受け取りチェックプロセス１３０１の処理が開始される。チェックプロセス１３０１において、ＡＮＴリクエストプロセッサ１２０４は、携帯電話機７００からのリクエスト（図３４参照）が受け取られ、メモリ１２１０に格納されたか否かが判定される。メモリ１２１０はこの実施例においては、ＲＡＭ及び非揮発性メモリの双方を表す。リクエストが受け取られ格納されたとき、処理は、チェックプロセス１３０１からデータ検索プロセス１３０２に進む。
【０２３８】
データ検索プロセス１３０２において、ＡＮＴリクエストプロセッサ１２０４は、カスタマーデータベース１２１３から、ＵＲＬソース、即ち携帯電話機７００のクライアントモジュール７０２に関する情報を検索し、ＵＲＬにおいて特定された行き先、即ち指定されたサーバに関する情報を、サーバデータベース１２１２から検索する。同データベース１２１２及び１２１３は、メモリ１２１０に格納される。データベース１２１３におけるカスタマーレコードは、例えば、キャリアアドレス、例えば、ＩＰ番号、無線通信ネットワークトランスレータ口座番号、支払い情報、及びサーバサブスクリプトを含む。データベース１２１２におけるサーバレコードには、サーバＩＰアドレス、名前、カテゴリ、及びサービスのクラスが含まれる。サービスのクラスは、サービスの料金、例えば基本サービス料、サービス手数料、若しくは従量制サービス料に関係する。他の料金体系を他のインプリメーションにおいてサポートするようにすることも可能である。この情報は、そのサーバ、及びＵＲＬにおいて特定されたサービス、及びカスタマーに対して検察され、このとき処理は有効リクエストチェックプロセス１３０３に進む。
【０２３９】
有効リクエストチェックプロセス１３０３においては、ＡＮＴリクエストプロセッサ１２０４が、例えば、クライアントモジュール７０２、即ちカストマーが無線通信ネットワークトランスレータ５００にアクセスする許可を得られたか否か、クライアントモジュール７０２がＵＲＬにおいて特定されたサーバにアクセスする許可を得られたか否か、特定のサーバがトランスレータ５００を通して使用可能であるか否か、及び特定のサーバが要求されたサービスをサポートしているか否かが判定される。従って、有効リクエストチェックプロセス１３０３では、クライアント、サーバ、及びクライアント／サーバの組が有効にされる。また、見積もられたコストがリクエストに含まれていることから、カストマーの口座の状態及び限度額がチェックされ、見積もられたコストが許容範囲にあるか否かが判定されうる。全てのチェックの結果が真である場合は、処理は、ＨＴＴＰリクエスト生成プロセス１３０６に進む。逆に、チェックの何れかが偽である場合は、有効リクエストチェックプロセス１３０３において、エラー情報がエラー戻しプロセス１３０４に送られる。
【０２４０】
エラー戻しプロセス１３０４では、メモリ１２１０に格納されたＣＧＩプログラムを受け取った情報に基づいて開始し、適当な情報をＣＧＩプログラムに送る。ＣＧＩプログラムは、エラーを記述している適当なＰＩＤＬデックを構築し、このＰＩＤＬデックを上述のようにＴＩＬデックに変換する。エラーを記述したＴＩＬデックが終わったきと、エラー戻しプロセス１３０４から、処理は後に詳細に説明する取引記述プロセス１３１５に進む。
【０２４１】
有効リクエストチェックプロセス１３０３における全てのチェックが真である場合は、ＨＴＴＰリクエスト生成プロセス１３０６においてメモリ１２１１内のリクエストを特定されたサーバに対するリクエストに変換するが、この実施例においてはこのリクエストはＨＴＴＰリクエストである。例えば、上述のリクエストに対しては、ＨＴＴＰリクエスト生成プロセス１３０６において
GET /airnet/home.cgi?&client=xyz&cost=1 HTTP/1.0
なるメソッドフィールドが生成される。この実施例においては、このメソッドフィールドは上述の実施例と同じ情報を含み、更に、このメソッドフィールドはクライアント識別情報及び見積もりコスト情報を含む。
【０２４２】
ＨＴＴＰリクエスト生成プロセス１３０６が終了した後、ＡＮＴリクエストプロセッサ１２０４は、サーバコネクション確立プロセス１３０７において、ＴＣＰ／ＩＰ用のＴＣＰモジュール１２０３にアクセスし、そこから処理はＵＤＰ／ＩＰ用の伝送安全性チェックプロセス１３０８に進む。コネクション確立プロセス１３０７において、クライアントリクエストにおいて指定されたサーバとＴＣＰインタフェースモジュール（図示せず）との間のコネクションが確立され、データが無線通信ネットワークトランスレータ５００とサーバとの間で転送可能となる。このサーバへのＴＣＰコネクションが設定されたとき、ＡＮＴリクエストプロセッサ１２０４は、処理をサーバコネクション確立プロセス１３０７から伝送安全性チェックプロセス１３０８に進める。
【０２４３】
伝送安全性チェックプロセス１３０８においては、ＡＮＴリクエストプロセッサ１２０４はクライアントからＨＴＴＰリクエストが暗号をサポートするプロトコルを用いるサーバをリクエストしたか否かが判定される。このようなサーバがリクエストされた場合は、処理は取り決めプロセス１３０９に進み、そうでない場合はリクエスト伝送プロセス１３１０に進む。
【０２４４】
取り決めプロセス１３０９において、ＡＮＴリクエストプロセッサ１２０４はサーバと暗号の取り決めを行う。取り決めが終了すると、処理はプロセス１３０９から暗号プロセス１３１１に進む。暗号プロセス１３１１において、ＨＴＴＰリクエストは取り決められ暗号技術を用いて暗号化され、次に処理はリクエスト伝送プロセス１３１０に進む。
【０２４５】
リクエスト伝送プロセス１３１０において、ＨＴＴＰリクエストはメモリ１２１０からＨＴＴＰサーバに送られる。この伝送が終了すると、ＡＮＴリクエストプロセッサ１２０４は、処理を処理結果受け取りチェックプロセス１３１２に進める。
【０２４６】
上述のように、リクエストを受け取ったとき、ＨＴＴＰサーバはリクエストされたサービスを提供する。サービスの提供が終了すると、ＨＴＴＰサーバはＴＩＬデック若しくはＴＩＬデックを無線通信ネットワークトランスレータ５００に戻す。このデックはメモリ１２１０に格納される。サーバがＰＩＬデックをＴＩＬデックに変換しない場合は、無線通信ネットワークトランスレータ５００による翻訳は完了する。
このデックが受け取られ格納されたとき、ＡＮＴリクエストプロセッサ１２０４は処理をチェックプロセス１３１２からＴＣＰ／ＩＰ用の伝送終了プロセス１３１３及びＵＤＰ／ＩＰ用の伝送安全性チェックプロセス１３１４に進める。ＡＮＴリクエストプロセッサ１２０４が、伝送終了プロセス１３１３において、ＴＣＰ回路をサーバと共に閉じる。サーバＴＣＰコネクションが切断されると、処理は伝送安全性チェックプロセス１３１４に進む。
【０２４７】
サーバが暗号を使用している場合、メモリ１２１０に格納されたデックは暗号化される。従って、暗号が用いられている場合は処理は伝送安全性チェックプロセス１３１４から解読プロセス１３１６に進み、そうでない場合はトランザクション記録プロセス１３１５に進む。
【０２４８】
解読プロセス１３１６において、暗号化されたデックは解読され、メモリ１２１０に格納される。また、解読の後、そのデックがＴＩＬデックに転換されなければならない場合は、翻訳が実行される。解読プロセス１３１６から、処理はトランザクション記録プロセス１３１５に進む。
【０２４９】
トランザクション記録プロセス１３１５において、ＡＮＴリクエストプロセッサ１２０４は、メモリ１２１０内のトランザクションログ１２１１にトランザクション記録を書き込む。この実施例においては、各トランザクション記録には、カスタマー識別情報、サーバ識別情報、トランザクションに要した時間、トランザクションのコスト、及び終了コードが含まれる。一実施例においては、安全のため、各携帯電話機にただ１つのカスタマー及びただ１つの口座が割り当てられる。
【０２５０】
トランザクションが記録された後、処理は処理結果伝送プロセス１３１７に進む。処理結果伝送プロセス１３１７においては、ＡＮＴリクエストプロセッサ１２０４はそのデックをクライアント７０２に戻す。このデックの転送が終了した後、ＡＮＴリクエストプロセッサ１２０４は処理を終了する。
【０２５１】
一実施例においては、無線通信ネットワークトランスレータが完全にロードされ、他の伝送が入ってきた場合は、このトランスレータは別の無線通信ネットワークトランスレータのアドレスを戻し、伝送を拒否する。携帯電話機は、他の無線通信ネットワークトランスレータにメッセージを伝送する。更に別の実施例においては、入ってくる全ての伝送がルータに向けられる。ここで、複数の無線通信ネットワークトランスレータがルータに接続されている。このルータは各トランスレータの状態をモニタする。入ってくる伝送のそれぞれが使用状態がもっとも少ないトランスレータに回され、そこでその伝送に応じて必要な処理が実行され、クライアントモジュールとの通信が継続される。
【０２５２】
上述のクライアントモジュール７０２の説明において、モジュール７０２は携帯電話機内の構成要素と対話して、ユーザによって指定された様々な処理を行った。クライアントモジュール７０２を、様々な携帯電話機における緊急事態から可能な限り絶縁するための、クライアントモジュール７０２の一般的なアーキテクチャは以下に詳述する。その一般的なアーキテクチャは、上述の携帯電話内モジュールと対話を行う特定のマネージャモジュールを有し、基準情報をクライアントモジュール７０２内の残りのマネージャモジュールに供給するように設計されている。このクライアントモジュール７０２内のマネージャモジュールはＴＩＬデックを翻訳してユーザインタフェースを発生し、ユーザによる入力データを翻訳し、かつＴＩＬデックを翻訳してユーザによるデータ入力は適当なリソースロケータと結合され、メッセージが適当なサーバに送られるようにするか、若しくは別のローカルＴＩＬデックがクライアントモジュールによって翻訳されるようにするインタプリタを形成する。この実施例は携帯電話機を用いた実施例であるのに対し、マネージャモジュールは汎用性を有し、従って双方向データ通信デバイスにおける任意のクライアントモジュールに適用可能である。
【０２５３】
この方法を採用した場合、様々な双方向データ通信ネットワーク上に様々な双方向データ通信デバイスを、本発明の原理に基づいて実現するために必要なクライアントモジュール７０２の変更が制限される。また、上述の実施例においては、クライアントモジュール７０２は携帯電話ネットワーク上での通信及び対話をサポートしていた。しかし、クライアントモジュール７０２は、携帯電話機７００上のローカルサービスのサポートも可能である。典型的なローカルサービスには、ローカルメッセージ、住所録、予め設定された電子メールの返答文、若しくはこれらのサービスの組み合わせが含まれる。
【０２５４】
この実施例においては、クライアントモジュール７０２は、ナビゲーションマネージャモジュール（navigation manager module）１４０１、ネットワークマネージャモジュール１４０２、ＴＩＬマネージャモジュール１４０３、アーカイブマネージャモジュール１４０４、ローカルマネージャモジュール１４０５、イベントマネージャモジュール１４０６、タイママネージャモジュール１４０７、ユーザインタフェースマネージャモジュール１４０８、メモリマネージャモジュール１４０９及びデバイス従属モジュール１４１０を含む複数のマネージャモジュールを有している。
【０２５５】
ナビゲーションマネージャモジュール１４０１は、キャッシュメモリを管理すると共に、カード及びデックのナビゲーションを取り扱う。ナビゲーションマネージャモジュール１４０１は、ヒストリーリスト及びプッシュカードリストを有しており、これらを管理する。更に、ナビゲーションマネージャモジュール１４０１は、クライアントモジュール７０２の主たるラインとしての役割を果たし、全てのイベントの供給を行い、ローカルサービスのサポートも行っている。
【０２５６】
ローカルサービスに対しては、ローカルメッセージ記憶のように、使用され得る２つの基本的な方法がある。第１に、ローカルサービスはＣＧＩのような方法で実現される。各ローカルサービスが引数リストと共に読み出されたエントリポイントを有する。ＴＩＬデックはイベントマネージャを介して戻される。その点からＴＩＬデックは標準的な方法で処理される。この方法では、遠隔サービスと同様の制限がローカルサービスにもたらされる。制限を少なくする方法は、ローカルサービスが標準的なイベントルートの代わりにフィールドイベントを実行できるようにすることである。ローカルサービスは進行中に、ＴＩＬカードを構成し、それをユーザインタフェースマネージャ１４０６に供給する。ローカルサービスが、そのヒストリ、プッシュカードリスト、及びイベントループによって管理される他の状態に関して、標準的なイベントループと協働する必要があるということに注意されたい。表４は、ナビゲーションマネージャモジュール１４０１用のアーキテクチャに対する処理のリストである。
【０２５７】
【表４】
0004274661.tif 000005
【０２５８】
ルーチンＰｒｏｃｅｓｓＥｖｅｎｔｓは、クライアントモジュール７０２におけるイベント処理のための主たるエントリポイントである。典型的なイベントには、キーパッド上のキープレス、選択カードのための選択、エントリカードのためのテキスト入力、ネットワークイベント、及びヒストリイベントが含まれる。ルーチンＰｒｏｃｅｓｓＥｖｅｎｔｓは、任意の時間に呼び出して、イベントの処理を行うことができる。ルーチンＰｒｏｃｅｓｓＥｖｅｎｔｓは、イベントマネージャモジュール１４０６によって生成されたキュー上の全てのイベントが処理されるまで戻されない。ローカルサービスが実行されている場合、イベントはルーチンＰｒｏｃｅｓｓＥｖｅｎｔｓによって処理される前にローカルサービスに分配される。
【０２５９】
表４における残りのルーチンは内部的にナビゲーションマネージャモジュール１４０１にローカルサービスによって呼び出される。ルーチンＰｕｓｈＬｏｃａｔｉｏｎは、ヒストリリスト上の位置をプッシュし、その位置に対するリクエストを送り出す。ｆｏｒＳｔａｃｋフラグは、ローカルカードのスタックプッシュを示す。
【０２６０】
ルーチン＊ＰｏｐＬｏｃａｔｉｏｎはヒストリスタック上の位置をポップし、ヒストリスタックの最上部の位置に対するリクエストを送出する。ルーチン＊ＰｏｐＬｏｃａｔｉｏｎにおいて、ｆｏｒｓｔａｃｋフラグは、最終スタックプッシュがポップされるはずであることから、全てのカードを示している。
【０２６１】
ルーチン＊ＣｕｒｒｅｎｔＬｏｃａｔｉｏｎは現在位置を戻し、現在ＵＲＬが表示されるようにする。
【０２６２】
表４に示すように、各ローカルサービスは幾つかの関数を与える。ローカルサービスが実行中である場合、ローカルサービスのイベントハンドラーである関数ＨａｎｄｌｅＥｖｅｎｔが、ナビゲーションマネージャモジュール１４０１による処理が行われる前に呼び出される。このイベントがローカルサービスによって取り扱われる場合は、このイベントはこれ以上の処理は行われない。
【０２６３】
関数ＳｔａｒｔＬｏｃａｌＳｅｒｖｉｃｅは、ローカルサービス開始関数である。関数ＳｔａｒｔＬｏｃａｌＳｅｒｖｉｃｅは、ローカル関数にイベントが分配される前に呼び出される。同様に、関数ＳｔｏｐＬｏｃａｌＳｅｒｖｉｃｅは、特定のローカルサービスに対する停止関数である。関数ＳｔｏｐＬｏｃａｌＳｅｒｖｉｃｅは、ローカルサービスにイベントが配分されなくなったときに呼び出される。
【０２６４】
ネットワークマネージャモジュール１４０２はクライアントモジュール７０２の残りの部分を携帯電話ネットワーク上で使用される特定のネットワークプロトコルから絶縁している。ネットワークマネージャモジュール１４０２はＵＲＬにおいて特定されたサーバに、携帯電話ネットワークインタフェースを介してリクエストを送り、待ち時間を短縮するためにサーバからの応答を区分し、ローカルサービスからの応答をイベントモジュール１４０６を介してナビゲーションモジュール１４０１に配分し、携帯電話ネットワーク上でのサーバとのリクエスト／応答サイクル（即ちキャンセル、再試行ストラテジィ）を取り扱い、サーバからの非同期メッセージを受け取ることができ、ＴＩＬデックのメモリ管理を行い、ＴＩＬデックのキャッシングを実行し、プロトコル及びサーバスケーリングに関するサーバとの全ての取り決めを取り扱い、携帯電話機７００とサーバとの間で交換される情報のための暗号を取り扱う。
【０２６５】
携帯電話機の中には、最大メッセージサイズが固定されているものがある。しかし、ＵＤＰ及びＴＣＰメッセージに対しては、このメッセージ伝送に関する制限をバイバスするより直接的なインタフェースが用いられる。メモリの“最大水位（high water mark）”を高めるとともに処理能力を低下させるようなメモリバッファからメモリバッファへのネットワークデータのコピーを避けることは重要である。携帯電話機によって、ネットワークデータを分配するためのインタフェースが異なることから、ネットワークマネージャモジュール１４０２はネットワークデータを管理する。このように、ネットワークデータは長期間の格納のためにのみネットワークバッファからコピーされる。
【０２６６】
メッセージもしくは返答文が到着したとき、ネットワークマネージャモジュール１４０２はイベントマネージャモジュール１４０６を用いて、その事実を伝える。しかし、クライアントモジュール７０２内の他のマネージャモジュールによるデータへのアクセスは、異なる電話機において様々な方法でデータを格納することができるようなプロトコルを用いて行われる。任意の伝送時に、ＴＩＬデータの短時間のキャッシュメモリへの格納は、ネットワークマネージャモジュール１４０２によって取り扱われる。表５は、ネットワークマネージャモジュール１４０２のアーキテクチャの１つである。
【０２６７】
【表５】
0004274661.tif 000006
【０２６８】
ネットワークマネージャモジュール１４０２は、１６ビットのトランザクション識別コードＴＩＢによってネットワークデータの各トランザクションを識別する。ネットワークマネージャモジュール１４０２は新たなトランザクションごとにトランザクション識別コードＴＩＤをインクリメントする。トランザクション識別コードＴＩＤは０ｘｆｆｆｆ以上ではロールオーバされる。
【０２６９】
ルーチンＮＭ Ｉｎｉｔは、ネットワークマネージャモジュール１４０２を初期化し、従ってネットワークマネージャモジュール１４０２の他の呼び出しが行われる前に呼び出される。ルーチンＮＭ Ｔｅｒｍｉｎａｔｅは、ネットワークマネージャモジュール１４０２の処理を停止し、従ってネットワークマネージャモジュール１４０２における他の全ての呼び出しが終了した後に呼び出されるものである。
【０２７０】
ネットワークマネージャモジュール１４０２はリクエストをサーバへ送る標準的なプロセスとしてルーチンＴＩＤ  ＮＭ ＳｅｎｄＲｅｑｕｅｓｔを用いる。ルーチンＴＩＤ  ＮＭ ＳｅｎｄＲｅｑｕｅｓｔを用いる。ルーチンＴＩＤ  ＮＭ ＳｅｎｄＲｅｑｕｅｓｔの呼び出しにおけるポインタ＊ｒｅｑｕｅｓｔＤａｔａは、サーバプロトコルによって規定される。同様に、状態、例えば変数ｉｇｎｏｒｅＣａｃｈｅのブーリアン値が用いられて、キャッシュされた応答が無視されるべきか否かが示される。リクエストが送られた後、このルーチンはサーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄを戻す。ローカルサービスもリクエストサーバに送ることができる。
【０２７１】
ユーザがクライアントモジュール７０２にリクエストをキャンセルする命令を送ったとき、ネットワークマネージャモジュール１４０２は携帯電話トランザクション識別コードＴＩＤ及びサーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄと共にルーチンＮＭ ＣａｎｃｅｌＲｅｑｕｅｓｔを呼び出す。ルーチンＮＭ ＣａｎｃｅｌＲｅｑｕｅｓｔは、サーバに特定のリクエストをキャンセルするコマンドを送る。
【０２７２】
データがネットワークから受け取られたとき、データはルーチンＴＩＤ  ＭＮ ＳｅｎｄＲｅｑｕｅｓｔからのもしくはローカルサービスからのリクエストに対する応答であり得る。従って、サーバから受け取ったデータに応じて、ネットワークマネージャモジュール１４０２はサーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄ及びデータタイプＤＡＴＡＴｙｐｅを含むイベントを発生する。ルーチンＴＩＤ  ＭＮ ＳｅｎｄＲｅｑｕｅｓｔによって送られたリクエストに対する応答のために、サーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄはマッチング呼び出しによりルーチンＴＩＤ  ＭＮ ＳｅｎｄＲｅｑｕｅｓｔに戻されるものと同じであり、データタイプＤＡＴＡＴｙｐｅはデータが応答であることを示す。メッセージから生じたローカルサービスに対しては、サーバ識別ＩＤは新たなものが用いられ、データタイプＤＡＴＡＴｙｐｅはデータが電子メールのデータかプッシュＴＩＬのデータか、もしくは他のタイプのデータかによって決まる。
【０２７３】
ネットワークイベントがイベントマネージャモジュール１４０６により受け取られた後、ナビゲーションマネージャモジュール１４０１はイベントのコントロールをネットワークマネージャモジュール１４０２に送り、ネットワークマネージャモジュール１４０２は、サーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄ及び表５における残りのルーチンを用いて、データの処理を行う。ルーチンＮＭ ＤＡＴＡＴｙｐｅが用いられて、特定のデータタイプＤＡＴＡＴｙｐｅ、例えば返答文（reply）、ＭＩＭＥ、サーバプッシュ（server push）等が戻される。ルーチンＮＭ ＧｅｔＤａｔａは、サーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄによって特定されたデータにポインタをセットし、データの長さを取り出し、全てのデータが受け取られたか否かを判定する。このルーチンにより与えられたインタフェースにより、データストリームの第１部分、例えば、ＴＩＬデックの第１カードが残りのデックが受け取られる前にクライアントモジュール７０２によって処理することができるようになる。
【０２７４】
ルーチンＮＭ ＨｏｌｄＤａｔａは、ルーチンＮＭ ＧｅｔＤａｔａの呼び出しが行われる前に呼び出されて、データを保持し、従ってクライアントモジュール７０２による処理中にデータの有効性を確保するようにする。データが保持されない場合は、データは削除されるか、ネットワークマネージャモジュール１４０２の内部バッファに移動させられる。データが保持されている場合は、ルーチンＮＭ ＲｅｌｅａｓｅＤａｔａがネットワークデータが処理されてデータが放出される前に呼び出される。
【０２７５】
ルーチンＴＩＤ  ＮＭ ＳｔａｒｔＤａｔａ、ＮＭ ＥｎｄＤａｔａ、ＮＭ ＳｅｒＤａｔａＬｅｎｇｔｈ、ＮＭ ＧｒｏｗＤａｔａＬｅｎｇｔｈ、ＮＭ ＧｅｔＤａｔａＬｅｎｇｔｈ、ＮＭ ＧｅｔＤａｔａＰｏｉｎｔｅｒ、及びＮＭ ＤｅｌｉｖｅｒＤａｔａはネットワークマネージャモジュール１４０２、及びローカルサービスにより内部的に使用されてデータを供給する。ローカルサービスがこれらのルーチンを使用することが可能であることにより、同じバッファをネットワークで生成されたデータにもローカルに生成されたデータにも用いて格納することができ、これによりクライアントモジュール７０２をサポートするのに必要なメモリの大きさが小さくてすむ。
【０２７６】
ルーチンＴＩＤ  ＮＭ ＳｔａｒｔＤａｔａは、新たなデータトランザクションを生成し、データ配分イベントを開始する。ルーチンＮＭ ＥｎｄＤａｔａは所与のサーバトランザクション識別コードＴＲＡＮＳＡＣＴＩＯＮＩｄに対する全てのデータが伝送されたときに呼び出される。ルーチンＮＭ ＳｅｒＤａｔａＬｅｎｇｔｈは、データセグメントを所与の長さにセットするが、このときデータの位置を動かしてもよい。ルーチンＮＭ ＧｒｏｗＤａｔａＬｅｎｇｔｈは、所与の長さだけデータセグメントを伸ばし、またこのときもデータの位置を変化させてもよい。ルーチンＮＭ ＧｅｔＤａｔａＬｅｎｇｔｈは、データセグメントの長さを戻す。ルーチンＮＭ ＧｅｔＤａｔａＰｏｉｎｔｅｒは、そのデータに対するポインタを戻す、このルーチンは好ましくはデータバッファへの書き込みが行われる前に呼び出される。また、このルーチンはデータの位置が動き得る場合には常に呼び出されるのが好ましい。ルーチンＮＭ ＤｅｌｉｖｅｒＤａｔａは、少なくとも１枚のカードが格納されたときに呼び出され得るものであって、これにより他のカードが生成されている間の待ち時間を短縮することができる。
【０２７７】
ＴＩＬマネージャモジュール１４０３はクライアントモジュール７０２の残りの部分をＴＩＬ使用への変化から絶縁する。ＴＩＬマネージャモジュール１４０３によって与えられたインタフェースは以下のような特性を有する。即ち、このインタフェースは、クライアントモジュール７０２の残りの部分によりパージングする必要性をなくし、進行中のデータ構造の生成を避けるべくカーソルを使用し、処理のために全てのデックは不要であり、またＴＩＬのバージョン付け（ｖｅｒｓｉｏｎｉｎｇ）を取り扱う。
【０２７８】
各ＴＩＬデックには、主バージョンナンバと副バージョンナンバとが含まれている。副バージョンナンバはＴＩＬがＴＩＬマネージャモジュールの存在を破壊しないような変化を来したときにインクリメントされる。主バージョン番号はＴＩＬのバージョンが互換性を有しないものに変わったときインクリメントされる。
【０２７９】
各ＴＩＬデックは同じ階層構成を有する。この階層構成の一実施例は、表６に示されている。表６においては、様々な階層レベル間の関係を表すためにインデントが用いられている。
【０２８０】
【表６】
0004274661.tif 000007
【０２８１】
表７に示されたＴＩＬマネージャモジュール１４０３に対するインタフェースは、【ＰＩＤＬ及びＴＩＬの記述】の項に記述されているように、ＴＩＬがＰＩＤＬの直接トークン化したものであることを仮定して設計されている。しかし、このインタフェースはそのトークン化したものに従属しておらず、他のＰＩＤＬ符号化技術をサポートすることも可能である。上述の仮定を与えたとき、後に説明する不透過性（opaque）ポインタがＴＩＬデック自体に対する実際のポインタである。スクリプトはデック内における不透過性ポインタが何れを指示しているかに基づく初期段階のオブジェクトタイピングスキームが、以下に述べる汎用関数を実現するのに使用され得る。このオブジェクトタイピングはＴＩＬ符号化の詳細のために実現不可能である場合は、汎用関数が特定の関数に置き換えられ得る。
【０２８２】
【表７】
0004274661.tif 000008
0004274661.tif 000009
【０２８３】
アーカイブマネージャモジュール１４０４は長時間使用された情報を格納し検索する。この情報には、サーバの位置に関連する、及び／若しくはサーバのスケーリングをサポートするのに必要なデータ、暗号に関するデータ、ＴＩＬキャッシング（ユーザに対し透過性を与える）ＴＩＬ格納データ（ユーザによって特定されたもの）、及びメッセージ格納データ及び検索データ（ローカルマネージャモジュール参照）が含まれる。アーカイブマネージャモジュール１４０４は、双方向データ通信デバイスにより与えられる様々な非揮発性メモリスキームをサポートすべきである。
【０２８４】
ローカルマネージャモジュール１４０５は、ローカルメッセージ、アドレスブックエントリ、及び予め設定された電子メール返答文のようなローカルデバイスリソースに対するインタフェースである。ローカルマネージャモジュール１４０５は、アーカイブマネージャモジュール１４０４が使用するために、ナビゲーションマネージャモジュール１４０４に対する抽象インタフェースも規定すべきである。
【０２８５】
表８は、携帯電話機７００上に格納された電話帳にアクセスするためのローカルマネージャモジュール１４０５内のインタフェースのアーキテクチャである。表８におけるルーチンの名称は、そのルーチンによって実行される処理を記述している。
【０２８６】
【表８】
0004274661.tif 000010
【０２８７】
表９は、携帯電話機７００上に格納された予め設定された返答文にアクセスするための、ローカルマネージャモジュール１４０５内のインタフェースのためのアーキテクチャである。表９におけるルーチンの名称は、そのルーチンによって実行される処理を記述している。
【０２８８】
【表９】
0004274661.tif 000011
【０２８９】
表１０は、携帯電話機７００上にローカルに格納されたメッセージにアクセスするための、ローカルマネージャモジュール１４０５内のインタフェースのためのアーキテクチャである。表１０におけるルーチンの名称は、そのルーチンによって実行される処理を記述している。
【０２９０】
【表１０】
0004274661.tif 000012
【０２９１】
イベントマネージャモジュール１４０６は、イベントの配布を取り扱う。この実施例においては、イベントに含まれるのは、キープレスのような低いレベルのイベント及びより高いレベルのナビゲーション及びユーザインタフェースイベントがある。典型的には、一度に生ずるイベントの数はわずかである。双方向データ通信デバイスに従属するモジュールにおける主たるイベントループは、待ち行列内の全てのイベントがなくなるまで、ＥＭ ＧｅｔＮｅｘｔＥｖｅｎｔ（）の呼び出しを継続する。１つのイベントの処理により、別のイベントが待ち行列にプッシュされるということに注意されたい。主たるイベントループは、ユーザのキープレスもしくはネットワークイベントであることから、次のイベントが待ち行列にプッシュされるまで再スタートされない。
【０２９２】
この実施例においては、イベントタイプには、
（１）キーパッドイベント、即ち、キーを押すこと
（２）現在選択カードに関連する選択イベント、例えばユーザが３つの選択肢の中から選択を行うこと
（３）現在エントリカードに関連するテキストエントリイベント、例えばユーザが“ＨＡＬＬＯ”とキーイングすること
（４）ネットワークイベント、例えば、受け取った応答、受け取ったリクエスト、終了したトランザクション、及びネットワークステータス
（５）ヒストリイベント、例えばポップ、マーカへのポップ
が含まれる。
【０２９３】
表１１は、イベントマネージャモジュール１４０６のためのアーキテクチャである。別の表の場合のように、表１１におけるルーチンの名称は、そのルーチンによって実行される処理を記述したものであり、更にコメントフィールドに簡単な説明が与えられている。
【０２９４】
【表１１】
0004274661.tif 000013
【０２９５】
タイマーマネージャモジュール１４０７により、タイマーイベントがタイムアウト、アニメーション、及び他の時間領域機構をサポートすることが可能となる。タイムアウトはイベントマネージャモジュール１４０６を介して配分される。表１２は、タイマーマネージャモジュール１４０７についてのアーキテクチャである。他の表の場合のように、表１２におけるルーチンの名称は、そのルーチンによって実行される処理を記述したものである。
【０２９６】
【表１２】
0004274661.tif 000014
【０２９７】
ユーザインタフェースモジュール１４０８は、キーパッド及びディスプレイとのやりとりを取り扱う。表１において規定されたユーザインタフェースの３つのタイプのそれぞれは、異なるユーザインタフェースマネージャモジュール１４０８を必要とする。殆どの携帯電話機に対しては、一回に一枚のカードのみが用いられる。しかし、携帯電話機の中には一度に複数のカードを表示し、一回に一枚のカードの表示を取り扱うものとは異なるバージョンユーザインタフェースマネージャモジュール１４０８が必要なものがある。
【０２９８】
この実施例においては、ユーザインタフェースマネージャモジュールが、表示、選択、及び入力の３つのタイプのカードに対するユーザインタフェースを提供し、住所録及び電子メールの応答エントリのためのカスタムユーザインタフェースのためのフック（hook）を提供し、カードのユーザインタフェースに関する面だけを取り扱い、ナビゲーション、引数、及びオプション処理は一切提供せず、ワードラッピング（word wrapping）を含むグラフィックレイアウト及びテキストの全てを取り扱い、テキストのスクローリングを取り扱い、ＰＩＤＬデータ構造から処理を行い、幾つかはソフトキーにより生成されたものであり得るキーボードイベントを発生し、ハイレベルのイベント、例えば次カード、選択エントリ３、テキストエントリ“ＩＢＭ”を発生する。
【０２９９】
表１３は、ユーザインタフェースマネージャモジュール１４０８によるカードの処理のためのアーキテクチャである。他の表の場合のように、表１３におけるルーチンの名称は、そのルーチンによって実行される処理を記している。
【０３００】
【表１３】
0004274661.tif 000015
【０３０１】
表１４はユーザインタフェースマネージャモジュール１４０８によるユーザインタフェースの実現のためのアーキテクチャである。他の表の場合のように、表１４におけるルーチンの名称は、そのルーチンによって実行される処理を記述している。
【０３０２】
【表１４】
0004274661.tif 000016
【０３０３】
ｃａｌｌｂａｃｋルーチンはレイアウトされる各ラインの特殊な関数を通知される。従って、ルーチンＵＩ ＬａｙｏｕｔＣａｒｄは、特定の選択肢にスクロールするのに使用され得る。現在行の幅が広すぎて、全てを一度に表示出来ない場合は、水平方向スクロールを行って、全ての行を一回の表示幅で表示する。
【０３０４】
メモリマネージャモジュール１４０９は所望に応じて設けられ、動的なメモリ割り振りをサポートしていない双方向データ通信デバイスにおいて使用される。これらのデバイスにおいては、全てのメモリ割り当て及びリリースはメモリマネージャモジュール１４０９を通して行われなければならない。また、前もってメモリマネージャモジュール１４０９を介してメモリの割り当てを行うことにより、クライアントモジュール７０２は、デバイス上の他の処理の中にメモリを使用するものがあることからメモリを使いきってしまうことが起こらずにすむ。
【０３０５】
一実施例においては、上述の無線通信ネットワークトランスレータはクライアントモジュールとの通信を行うのにインターネットサーバとともに使用された。このインターネットサーバはモザイクＨＴＴＰサーバを走らせるＵＮＩＸコンピュータである。実行可能なコードはコンピュータ上のソースコードをコンパイルすることによって生成されたが、このコンピュータはサンマイクロシステムズ社のコンパイラＳｕｎＰｒｏ  Ｃ及びＣ＃であって、サンマイクロシステムズ社のオペレーティングシステムＳｏｌａｒｉｓ２．４を走らせることができる。また、サンマイクロシステムズ社のＳＤＫを利用することもできる。これらの全ての製品は米国カリフォルニア州マウンテンビューのサンマイクロシステムズ社から入手可能である。
【０３０６】
以上説明してきたのは、新規な対話式双方向データ通信システム、双方向データ通信デバイス、無線通信ネットワークアーキテクチャ、及び予測テキスト入力システムの幾つかの実施例である。これらの実施例についての説明は本発明の原理を説明するためのものであって、本発明の範囲を特定の実施例に限定しようとするものではない。ここに開示した内容を参照することにより、当業者は本発明の原理を様々な応用対象に利用して、本発明の利点を享受することができるであろう。
また、本発明の実施において必要なプログラムは、任意の媒体に格納して使用することができる。
【０３０７】
【ＰＩＤＬ及びＴＩＬの記述】
ＰＩＤＬの主な構造は、抽象構文により記述される。以下、この言語の要素及びその意味について説明する。各要素の構文の記述においては、要素はｅｎｈａｎｃｅｄ  ＢＮＦで定められる。
【０３０８】
図３７を参照されたい。一般に、要素ブランク は、所望に応じて２つの別の要素の間に現れうる。図表を明確にしておくために、図表には必要な場所を除いてブランク記号は省略されて示されている。ブランク記号があってはならない場所、若しくは特別に取り扱われる場合は、そのことが示される。
【０３０９】
以下ＰＩＤＬの要素について説明する。
図３８Ａを参照されたい。１つのデックは１または２以上のカードからなる。デックには少なくとも１つのカードが存在しなければならない。また、デックはそのデック全体に有効を有するように定められたいくつかのソフトキーを有していてもよい。構文上の、完全に記述された以下のソフトキーを参照されたい。
【０３１０】
図３８Ｂを参照されたい。次のデックリクエスト上に渡される追加的な引数は、ｏ−ａｒｇｓで与えられる。構文上で、完全に記述された以下の引数を参照されたい。
【０３１１】
このページを検索するのにかかるコスト（電話料金を除く）は、ｏ−ｃｏｓｔで表される。ｏ−ｃｏｓｔが与えられていない場合は、デックを参照するコストは、ユーザの一般サービス契約の料金の中に含まれる。
【０３１２】
デックは、携帯電話機によりある時間キャッチされうる。ｏ−ｔｔｌエントリは、デックが受け取られてからキャッチされうる時間の秒数を表す。ｏ−ｔｔｌエントリが与えられない場合は、デックはごく短時間、例えば、多くのウェブブラウザと同様にバック関数を実現する時間だけキャッチされうることになる。ｏ−ｔｔｌの値が０である場合は、デックはキャッチされてはならない。
【０３１３】
以下カード要素の設定について説明する。
図３８Ｃを参照されたい。カードは、この実施例においては、３つのタイプのカードのうちの１つである。このことは以下のセクションに記述される。
図３８Ｄを参照されたい。全てのカードはこれらのオプションを有しうる。オプションの１つのｏ−ｎａｍｅオプションは、カードの名称を与える。カードが名称を有する場合は、カードは行き先により参照されうることになる。
【０３１４】
ｏ−ｎｅｘｔ及びｏ−ｐｒｅｖは、ＮＥＸＴ及びＰＲＥＶキーに行き先を与える。これがない場合はデフォルト値は、デック内の次カード及び前カードが連続して現れるものである。ｏ−ｐｒｅｖが、第１カードにない場合は、ＰＲＥＶキーは最後に呼び出されたデックに戻される。最終カードにｏ−ｎｅｘｔがない場合は、ＮＥＸＴキーは現在デックの第１カードに戻される。しかし、このデフォルトビヘイビア（default behavior）は、フェールセーフのみを目的としており、デック内の最終カードは常にｏ−ｎｅｘｔオプションか選択カードを有しおり、このとき選択カードには新たな目的地を示す選択エントリが含まれている。
【０３１５】
以下表示カードの設定について説明する。
図３８Ｅを参照されたい。表示カードはユーザが読むための情報を与える。表示されうる情報のフォーマットを完全に記述するための以下の一定のフォーマットで記述されたテキストを参照されたい。ソフトキーは、このカードだけのために記述されうるものであり、以下のソフトキーの項を参照されたい。
【０３１６】
以下選択カードの設定について説明する。
図３９Ａを参照されたい。ユーザはリストから１つの選択肢を選択する。初めのディスプレイの内容はユーザに示され次いで選択肢が示される。各選択肢は一定のフォーマットに従って記述された１行のテキストであり得る。（このテキストが長すぎる場合は、電話機を操作することによりラッピング若しくはスクローリングを行えるようにしてもよい。）
選択肢がどのように表示され選択されるかは、ｏ−ｍｅｔｈｏｄオプションに基づいてなされる。このオプションがヒントに過ぎず、電話機によって無視されうるものであるということに注意されたい。番号メソッドはデフォルト値であり、その選択肢が１から順に番号をふられていること、及びキーパッド上の適当な数値を押すことによって選択されることを示している。９個を越えるオプションが存在する場合は、電話機は他の選択メソッドを採用してもよい。ｌｉｓｔ  ｍｅｔｈｏｄは、そのリストが番号をふられるべきではなく、ユーザがリストをスクロールして、どれかの数字入力キーを押すことによりエントリを選択すべきであることを示している。ａｌｐｈａ  ｍｅｔｈｏｄはリストに似たものであり、これは、エントリのテキストが、選択可能である場合に、その選択を助けるのに使用されるべきであることを示すものに過ぎない。この場合においては、エントリはアルファベット順にソートされることが仮定されている。ｇｒｏｕｐ  ｍｅｔｈｏｄは後に詳述する。
【０３１７】
ｏ−ｋｅｙオプションは、それが存在している場合は、引数リストに加えられるべき引数のキーを示すものである。以下の引数の項には更に詳しく説明をされているので参照されたい。引数の値は選択エントリからのものであり、以下を参照されたい。ｏ−ｄｅｆａｕｌｔオプションは、ユーザがＥＮＴＥＲキーを押した場合のデフォルト値を示している。以下の入力カードの項においてｏ−ｄｅｆａｕｌｔについて更に詳しく説明されているので、参照されたい。
【０３１８】
図３９Ｂを参照されたい。各選択はユーザに対して表示されたテキストを有する。ａｃｔｉｏｎ−ｏｐｔｉｏｎｓが与えられている場合は、選択がなされた場合、示された動作が行われる。ｏ−ｖａｌｕｅオプションが存在する場合は、選択肢ヘッダにおけるｏ−ｋｅｙオプションで特定された引数に一定の値が供給される。ｏ−ｖａｌｕｅが与えられていない場合は、エントリのテキストは引数の値として用いられる（フォーマッティングは行われない）。
【０３１９】
図３９Ｃを参照されたい。ｇｒｏｕｐ  ｍｅｔｈｏｄが用いられる場合は、選択肢はいくつかのグループに分けられる。各グループはｇｒｏｕｐ−ｅｎｔｒｙにより見出しが付けられており、このｇｒｏｕｐ−ｅｎｔｒｙはｌａｂｅｌオプションを介して、グループにショートネームを与える。次に電話機がユーザに多くの選択肢からの選択をなすための階層的インタフェースを与える。ラベルのテキストは、８文字以内に限定されるべきであり、電話機により端の桁の切り捨てが行われてもよい。
【０３２０】
以下入力カードの設定について説明する。
図３９Ｄを参照されたい。ｅｎｔｒｙはユーザが数値を入力できるようにするものである。ユーザにはディスプレイ内容が示され、次いで入力行が示される。ユーザの入力はフォーマットにより制御される。ｏ−ｋｅｙオプションは、入力によってセットされる引数を示すものである。引数の値はユーザの入力である。
図３９Ｅを参照されたい。このオプションはユーザの入力エントリのフォーマットを特定する。文字列がフォーマットコントロール文字列及び入力領域に表示される静的テキストからなる。フォーマットコントロール文字列のほとんどは、ユーザによってキーイングされることが期待されるデータが何れかを制御する。これはユーザがタイピングを行うまで空白として表示される。
【０３２１】
フォーマットコードには、
Ａ：アルファベット文字の入力
９：任意の数字の入力
Ｘ：アルファベット文字または数字の入力
＊ｆ：任意の数の文字を入力可能にし、次の文字ｆはＡ、ＱまたはＸの１つであり、どんな種類の文字が入力可能かを特定する
＼ｃ：エントリフィールドにおいて、次の文字ｃを表示するものであり、エントリフィールドにおけるフォーマッティング文字の表示を可能にする
がある。
【０３２２】
ｆｏｒｍａｔ−ｈｉｎｔは、どんな種類の数値が入力されるかを示すものである。ｆｏｒｍａｔ−ｈｉｎｔが読みとられない場合は、無視される。ここで定義されているｆｏｒｍａｔ−ｈｉｎｔには、
ｔｅｘｔ：ｔｅｘｔはテキストが特別な入力技術を用いて入力されることを予想するものであり、一般には＊Ａ若しくは＊Ｘの後にテキストが記述される
ｍａｉｌ−ｒｅｐｌｙ：ｔｅｘｔに似たものであるが、電子メールメッセージ若しくはページャー用のテキストが入力されることを予測するものであり、入力アルゴリズムに影響を与えうる場合もある
ａｄｄｒｅｓｓ−ｌｉｓｔ：入力が電子メールアドレスのリストであることを表す
がある。
【０３２３】
図３９Ｆを参照されたい。ｏ−ｄｅｆａｕｌｔオプションは、ユーザが単にＮＥＸＴキーを押した場合に用いられる値を供給するものである。デフォルト値が与えられない場合は、ユーザが１つの値を入力しなければならない。
【０３２４】
以下フォーマットを整えられたテキストの設定について説明する。
図４０Ａを参照されたい。ｆｏｒｍａｔｔｅｄ  ｔｅｘｔは、ほとんどのカードにおいてユーザに示されるものである。フォーマットが整えられた行は、選択エントリ用として用いられる。
【０３２５】
図４０Ｂを参照されたい。フォーマットコードは書体のボールド体、イタリック体及びブリンキング体をコントロールする。スラッシュはフォーマッティングをキャンセルする場合である。ＨＴＭＬとは異なり、これらは必ずしもネストされる必要のあるものではなく、アプリケーション上若しくはキャンセレーション上も可能である。ｆｏｒｍａｔｔｅｄ−ｔｅｘｔ及びｆｏｒｍａｔｔｅｄ−ｌｉｎｅ要素は通常モード上で（ボールド体、イタリック体若しくはブリンキング体でない）開始される。
【０３２６】
図４０Ｃを参照されたい。ａｌｉｇｎｍｅｎｔコードは行の部分がどのようにレイアウトされるかを特定する。ａｌｉｇｎｍｅｎｔコードに続くテキストは、センタリングされるか、同じ行の他のテキストと共に右寄せされる。このコードに続くテキスト若しくはイメージは、次のａｌｉｇｎｍｅｎｔコードまたは行が終了するまでに存在する全てのテキストであると考えられる。全ての行は左寄せされて始まることが潜在的に決められている。これらが、潜在的な行の終わりを含んでおらず、１つの行の上でテキストを左寄せ若しくは右寄せしうるということに注意されたい。テキストが長すぎ、その行にテキストを入れる十分な余地がない場合は、ラップモードにおいては、おさまりきらないテキストが次の行に動かされて、同じように位置揃えされる。ラインモード（ｌｉｎｅ  ｍｏｄｅ）においては、その行は左寄せされたセグメント、センタリングされたセグメント、及び右寄せされたセグメント間の２つのスペースと共にのびて終了する。
【０３２７】
ｔａｂコードは位置揃えされた列を生成するのに使用される。文字の位置を特定するタブではなく、このｔａｂコードはテキストを各列に区分する。列の幅は各ラインごとのテキスト（若しくはイメージ）の最大幅によって決定される。列の長さはｔａｂコードを有する第１行からｔａｂコードを備えた隣接する最後の行に達するまで延びる。行の中には、他の行と較べてｔａｂコードが少ないものあり、この場合は余分の列が必要なテキストが存在しないことが示されている。
図４０Ｄを参照されたい。多数行に亘るテキストは、＜ＢＲ＞コードによって分割される。行が長すぎてスクリーンに収まらない場合は、ラップモード（ｗｒａｐｍｏｄｅ）においては、その行は複数行にワードラップされる。ラインモードにおいては、その行は１つの行のままに取り扱われ、水平方向にスクロールされる。ｆｏｒｍａｔｔｅｄ−ｔｅｘｔ及びｆｏｒｍａｔｔｅｄ−ｌｉｎｅ要素は、ラップモードにおいてスタートし＜ＷＲＡＰ＞若しくは＜ＬＩＮＥ＞コードの何れかで変更され得る。これらのコードは潜在的なラインブレークである。
【０３２８】
以下イメージ（画像）の設計について説明する。
図４０Ｅを参照されたい。イメージは、大きなワードとして取り扱われ、デフォルト値では、単にテキストの一部分として表示される。ｆｌｏｗ−ｉｍａｇｅｓは、ｆｌｏｗオプションを有し、これはイメージに対し別の取り扱いを行うようにするものである。イメージデータはｓｏｕｒｃｅオプションにより特定されるように、分割されたデータストリームとして格納される。
【０３２９】
インラインイメージは全く同様に取り扱われ、データが現在データストリームの一部分であるに過ぎない。ＡＳＣＩＩ８５はプリント可能なＡＳＣＩＩにおけるバイナリデータの標準的な符号化方法であり、これによればデータが各４バイトごとに５つの文字に符号化される。ＴＩＬがインラインイメージの符号化のみを用い、異なる符号化方法を用いることに注意されたい。
【０３３０】
図４０Ｆを参照されたい。このオプションは、イメージデータ源の位置を特定する。
図４０Ｇを参照されたい。このオプションは、フローイメージデータの位置合わせを制御する。このオプションは、スクリーン内で画像が左揃えされるか右揃えされるかを特定する。次にテキストの次の行が残りの右側若しくは左側の空間に流れ込む。
【０３３１】
以下ソフトキーの設定について説明する。
図４１Ａを参照されたい。ソフトキーはＳＯＦＴ−Ｌ及びＳＯＦＴ−Ｒの２つのボタンの定義を与える。これらの２つのキーはユーザに表示されるグラフィクス領域及び普通のテキスト上には現れず、ソフトキーにラベル付けする別の行の上に表示される。（注意：実施形態によっては、スクリーンの面積が狭いため、このラベル付け行は、現在カード上にソフトキーが定義されていない場合は、普通のテキスト及びグラフィクス表示用に用いられ得る）
ソフトキーが押されたとき、ここに示された動作が行われる。
【０３３２】
図４１Ｂを参照されたい。ｂｕｔｔｏｎオプションは、ソフトキーがどの物理的キーに適用されるかを特定するものである。ｌａｂｅｌオプションは、そのキーのためにスクリーン上に表示されるテキストである。電話機ではラベルの端を切り捨ててもよい。ラベルの文字数は８文字未満が望ましい。
【０３３３】
ソフトキーは、デック全体に対して及び各カードに対してそれぞれ特定されうる。（デックヘッダの処理が終了後、第１カードの処理が開始される前に）そのデックに対してソフトキーが特定されたとき、このソフトキーはそのデック全体に亘って有効である。（そのカードの、フォーマットを整えられたテキストは始まるときに）そのカードに対してソフトキーが特定される場合は、これらのソフトキーは、そのカードが目に見える間、一時的にデックソフトキーに優先する。この優先順位処理が２つのキー（カードは１つのソフトキーに優先しうるが、他のキーには優先し得ない）に対して無関係に行われる。ソフトキーを用いずにデックソフトキーを無効にするために（要するに、そのカードが表示されている間ソフトキーを取り除いて示すために）ラベル付けされておらず、動作を行わないソフトキーが用いられる。
【０３３４】
以下シンタックス、それに関連するオプションについて説明する。
ＰＩＤＬのシンタックス要素の多くは、それらに関連するオプションリストを有する。オプションは、それらが属する要素の動作を改善する。そうでない場合は、特に示されていない限り、オプションは同じオプションが２つのネストされた要素に与えられている場合においてもネストされない。１つの要素に対して定められていないオプションは特定の要素に対して有効である場合でも無視される。
【０３３５】
図４１Ｃを参照されたい。オプションリストは、０若しくは１以上のオプションを含む。各オプションはブランク（必須！）によって区分され、所望に応じて続けてブランクが記入される。構文表において、オプションリストはｏｌ（ｖａｌｉｄ−ｏｐｔｉｏｎ）と示されており、ここでｖａｌｉｄ−ｏｐｔｉｏｎはそのコンテキストにおいて可能なオプションを定義する要素に置き換えられる。ｏｌは、オプションリストの一般的な構文に従った記述である。
【０３３６】
各オプションはキー及び数値である。このオプションはオプションのリスト内に任意のオーダで与えられ得る。このキーは常にａｌｐｈａ−ｎｕｍｅｒｉｃネームであって、これは文字の区別をしない。この数値は、それが英数字のみからなる場合は、イコール記号の後に直接現れる。そうでない場合は、この数値は引用文として表示されなければならない。この引用において、ブランクは１つの定数として取り扱われ、数値の一部分と考えられる。
【０３３７】
構文表において、様々なオプションに対する可能な数値は引用を行わずに特定される。しかし、引用文は、オプション数値の周りに常に書き込まれうる。
他の構文要素のほとんど全てとは異なり、ブランクはキーとイコール記号との間に、若しくはイコール記号と数値との間に存在してはならない。
多くのオプションは、上述の構文によって表される数値のより限定されたセットを有する。この詳細については、個別のオプションについての説明を参照されたい。
【０３３８】
以下行き先の設定について説明する。
オプションによっては、示されるべき次の、若しくは前のデックまたはカードを指定するために行き先が用いられる。デックは、全ての位置（ｓｅｒｖｉｃｅ−ｉｄ及びｄｅｃｋ−ｐａｔｈ）、ｄｅｃｋ−ｐａｔｈ（この場合サービスは現在デックのサービスと同じものである）を用いて、若しくは相対ｄｅｃｋ−ｐａｔｈを用いて特定される。後者の場合においては、現在デックパスの最終要素が除去され（相対デックパスにおける各．．／に対する１つの追加的な要素）、及びデックパスが加えられる。
【０３３９】
１つの特定のカードが行き先でありえ、ｃａｒｄ−ｌｏｃ要素によって特定される。
図４２Ａを参照されたい。ユーザが訪ねたことのある、電話機に格納された通常のヒストリリストに加えて、電話機は、位置のショートスタックも備えている。＋記号を用いることにより、新たなカードに進む前に、現在位置（デック及びカード、及びヒストリリストにおける位置、及び使用したアニメーション）がスタック上にプッシュされるようにする。−記号を用いることにより、スタックの最上部の位置が戻され、ヒストリリストがセーブされた点に戻されるようにする。アニメーションが与えられていない場合は、逆アニメーションが用いられる。このスタックはポップされる。
【０３４０】
図４２Ｂを参照されたい。所望に応じて使用されるアニメーション（動画）引数は、その行き先に行くときに、必要ならば、スクリーンアニメーションの形態としてどのようなものが用いられるべきかを指定する。このアニメーションはヒストリ及び行き先スタックにおける行き先と共に取り出される。ユーザが‘ｇｏ’または“ｎｅｘｔ’動作を介して行き先へ移動する場合は、そのアニメーションが実行される。ユーザが、‘ｐｒｅｖ’または‘ｐｏｐ’動作を介して、行き先へ移動する場合は、現在位置に関連する逆アニメーションが実行される。
【０３４１】
以下ユーザが選択を行ったときに行われる動作について説明する。
選択エントリ及びソフトキーはユーザがその選択肢またはソフトキーを選択したとき実行されるべき動作を特定することができる。
図４２Ｃを参照されたい。ｇｏ処理は、移動すべき行き先を指定するものである。
【０３４２】
以下引数処理について説明する。
デックがリクエストされる度に、引数はリクエストと共に渡されてもよい。これらの引数は、サービスエンドが、単に書き込み前のデックを戻すためでなく、ユーザに固有のデックをコンピュータ処理するのに使用されてもよい。
【０３４３】
引数は、ユーザがデックを横断するときに構築される。各引数は対になったキーの数値である。引数は表面的にはオプションに似ているが、これらの２つのエントリは全く異なったものである。即ち、オプションはＰＩＴＬの一部分であって、電話機の動作に影響を与える。引数は、電話機によって収集された情報であって、サービスに戻される。ＰＩＤＬも電話機もその基本的な構文構造を越えて引数を理解することはしない。
【０３４４】
引数は、３つの場所、即ち選択カード、エントリカード、及びａｒｇｓオプションから得られる。それぞれは対になったキー数値を特定し、これが引数のバッファに加えられて喪失される。ａｒｇｓオプションの場合においては、多数の引数が特定されてもよい。対になったキー数値である引数が引数バッファに加えられたとき、キーが既にバッファ内に存在する場合は、その数値は置き換えられる。
【０３４５】
図４２Ｄを参照されたい。ここで注意すべきことを以下に述べる。ｏ−ａｒｇｓ要素全体は、オプションの数値である。１以上のａｒｇ−ｋｅｙ−ｖａｌｕｅを有する場合は、引用文にする必要がある。アンパサンド（＆）及びセミコロン（；）が、キー数値の対を区分するために使用されることから、これらの文字は引数の一部にすることができない。
【０３４６】
図４２Ｅを参照されたい。これらのオプションは、選択カード及び入力カードが、これらのカードがセットする引数のためのキー及び数値を特定するのに用いられる。
【０３４７】
以下基本的な要素の設定について説明する。
図４３を参照されたい。テキストにおいては、一連のブランクは、１つのブランクスペースとして取り扱われ、ワードラッピングのための点として使用されうる。
【０３４８】
以下ＴＩＬ符号化について説明する。
注意書きの他に、ＴＩＬはその構造に関してＰＩＤＬと同一である。ＰＩＤＬをＴＩＬに翻訳するために概念上いくつかの過程が必要である。（これらの過程はトランスレータによって一度に行われてもよい。）即ち、
１．ハイビットセットを備えた文字をエスケープする過程と、
２．全てのブランクを圧縮若しくは除去する過程と、
３．コメント要素を、ハイビットセットを備えた１つのバイトにトークン化する過程と、
４．インラインイメージを処理する過程とからなる。
【０３４９】
基本的には、ＴＩＬは、一定の共通のキャラクターシーケンスを備えたＰＩＤＬを、ハイビットセットを備えた１つのバイトに置き換えたものに過ぎない。初めの２つの過程はこれをサポートしている。更に、イメージは、高密度のフォーマットで１つの行に含まれるようにすることによってコンパクト化される。
【０３５０】
トークン化は、次の表に与えられた符号化の後に行われる。要素を分割するために、オプションキー識別子を表すトークン（イコールサインを有する）は、ブランクの前に全てを含むものと考えられ得る。同様に、オプション値を表すトークンは、ブランクの後に全てが含まれると考えられ得る。
【０３５１】
最後に、図４４を参照すると、ＰＩＤＬ及びＴＩＬの各要素のそれぞれに対応するコードが一覧に示されている。
【０３５２】
【発明の効果】
以上より、携帯電話機、双方向ページャー等の軽量の移動式双方向データ通信デバイスをクライアントとして使用可能な双方向データ通信ネットワークシステムが提供される。
【図面の簡単な説明】
【図１】本発明の双方向データ通信デバイスを含む本発明の無線通信ネットワークの一実施例を示した図である。
【図２】Ａ〜Ｈよりなり、それぞれ、本発明の原理に基づくアプリケーションの１つを示している、本発明の双方向データ通信デバイスにおける一連のスクリーン上の表示を示した図である。
【図３】Ａ〜Ｆよりなり、それぞれ、本発明の原理に基づく第２のアプリケーションを示している、本発明の双方向データ通信デバイスのスクリーン上の表示を示した図である。
【図４】Ａ〜Ｉよりなり、それぞれ、本発明の原理に基づく別のアプリケーションを示している、本発明の双方向データ通信デバイスのスクリーン上の表示を示した図である。
【図５】本発明の双方向データ通信デバイスと無線通信ネットワークトランスレータとを含む本発明の無線通信ネットワークの別の実施例を示した図である。
【図６】本発明のクライアント及びサポートモジュールを含む、移動無線通信デバイスのブロック図である。
【図７】本発明の無線通信ネットワークアーキテクチャ内におけるサーバコンピュータと移動無線通信デバイスのより詳細な図である。
【図８】図７のサーバコンピュータ上のサーバと、移動無線通信デバイスにおけるクライアントとによって実行される処理を示したプロセス流れ図の一部である。
【図９】図７のサーバコンピュータ上のサーバと、移動無線通信デバイスにおけるクライアントとによって実行される処理を示したプロセス流れ図の一部である。
【図１０】図７のサーバコンピュータ上のサーバと、移動無線通信デバイスにおけるクライアントとによって実行される処理を示したプロセス流れ図の一部である。
【図１１】図７のサーバコンピュータ上のサーバと、移動無線通信デバイスにおけるクライアントとによって実行される処理を示したプロセス流れ図の一部である。
【図１２】本発明の一部分をなす新規な予知的テキスト入力システムを含む本発明の移動無線通信デバイスを示した図である。
【図１３】文字符号頻度テーブルの一実施例の一部を示した図であって、図１４に続く。
【図１４】文字符号頻度テーブルの一実施例の一部を示した図であって、図１３からの続きであり、図１５に続く。
【図１５】文字符号頻度テーブルの一実施例の一部を示した図であって、図１４からの続きであり、図１６に続く。
【図１６】文字符号頻度テーブルの一実施例の一部を示した図であって、図１５からの続きであり、図１７に続く。
【図１７】文字符号頻度テーブルの一実施例の一部を示した図であって、図１６からの続きであり、図１８に続く。
【図１８】文字符号頻度テーブルの一実施例の一部を示した図であって、図１７からの続きであり、図１９に続く。
【図１９】文字符号頻度テーブルの一実施例の一部を示した図であって、図１８からの続きであり、図２０に続く。
【図２０】文字符号頻度テーブルの一実施例の一部を示した図であって、図１９からの続きであり、図２１に続く。
【図２１】文字符号頻度テーブルの一実施例の一部を示した図であって、図２０からの続きであり、図２２に続く。
【図２２】文字符号頻度テーブルの一実施例の一部を示した図であって、図２１からの続きであり、図２３に続く。
【図２３】文字符号頻度テーブルの一実施例の一部を示した図であって、図２２からの続きであり、図２４に続く。
【図２４】文字符号頻度テーブルの一実施例の一部を示した図であって、図２３からの続きであり、図２５に続く。
【図２５】文字符号頻度テーブルの一実施例の一部を示した図であって、図２４からの続きであり、図２６に続く。
【図２６】文字符号頻度テーブルの一実施例の一部を示した図であって、図２５からの続きであり、図２７に続く。
【図２７】文字符号頻度テーブルの一実施例の一部を示した図であって、図２６からの続きであり、図２８に続く。
【図２８】文字符号頻度テーブルの一実施例の一部を示した図であって、図２７からの続きであり、図２９に続く。
【図２９】文字符号頻度テーブルの一実施例の一部を示した図であって、図２８からの続きであり、図３０に続く。
【図３０】文字符号頻度テーブルの一実施例の一部を示した図であって、図２９からの続きであり、図３１に続く。
【図３１】文字符号頻度テーブルの一実施例の一部を示した図であって、図３０からの続きであり、図３２に続く。
【図３２】文字符号頻度テーブルの一実施例の一部を示した図であって、図３１からの続きである。
【図３３】本発明の新規な予測式データ入力プロセスを含む、データ入力プロセスの一実施例を示すプロセス流れ図である。
【図３４】本発明の別の実施例の無線通信ネットワークアーキテクチャ内における、無線通信ネットワークトランスレータ及び移動無線通信デバイスのより詳細な図である。
【図３５】図３４の無線通信ネットワークトランスレータによって実行される様々なプロセスを示したプロセス流れ図である。
【図３６】本発明のクライアントモジュールの一実施例に含まれる様々なモジュールマネージャを示した図である。
【図３７】電話間対話記述言語（ＰＩＤＬ）及び端末間対話記述言語（ＴＩＬ）の記述における基本的な記述の方法を示した図である。
【図３８】Ａ〜Ｅよりなり、それぞれ、ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図３９】Ａ〜Ｆよりなり、それぞれ、ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図４０】Ａ〜Ｇよりなり、それぞれ、ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図４１】Ａ〜Ｄよりなり、それぞれ、ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図４２】Ａ〜Ｅよりなり、それぞれ、ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図４３】ＰＩＤＬ及びＴＩＬの各要素の設定の記述方法を示した図である。
【図４４】ＰＩＤＬ及びＴＩＬの各要素に対応するコードの一覧である。
【図４５】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４６に続く。
【図４６】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４５からの続きであり、図４７に続く。
【図４７】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４６からの続きであり、図４８に続く。
【図４８】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４７からの続きであり、図４９に続く。
【図４９】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４８からの続きであり、図５０に続く。
【図５０】予測データ入力プロセスで使用する文字頻度テーブルを発生するためのコンピュータプログラムの一部であって、図４９からの続きである。
【符号の説明】
１００  双方向データ通信デバイス（携帯電話機）
１０１  双方向データ通信デバイス（双方向ページャー）
１０２  双方向データ通信デバイス（電話機）
１０５、１０６、１０７  ディスプレイ
１１０  データ処理対応型携帯電話ネットワーク
１１１  双方向ページャーネットワーク
１１２  公衆電話交換回線
１２０  ワイドエリアネットワーク（ＷＡＮ）
１２１  サーバコンピュータ
１３０  ローカルエリアネットワーク（ＬＡＮ）
１３１  サーバコンピュータ
１４０  インターネット
１４１  サーバコンピュータ
１５０  無線通信ネットワーク
２００  内容紹介スクリーンディスプレイ
２０１、２０２  メニューディスプレイ
２０３  多段ディスプレイスクリーンカードインディケータ（ハンドアイコン）
２０４  Ｈｏｍｅキー
２０５  Ｉｎｆｏキー
２０６  購入注文番号入力スクリーンディスプレイ
２０７  ソフトキー
２０８  Ｆａｘソフトキー
２０９  購入注文番号入力後のスクリーンディスプレイ
３００  内容紹介スクリーンディスプレイ
３０１  Ｈｏｍｅキー
３０２  Ｉｎｆｏキー
３０３  多段ディスプレイスクリーンカードインディケータ（ハンドアイコン）
３０４、３０５、３０６、３０８、３１０  スクリーンディスプレイ
３０７  ＰＲＥＶキー
３０９  スケジュールキー
４００  内容紹介スクリーンディスプレイ
４００、４０２、４０３、４０６、４０９  スクリーンディスプレイ
４０１  Ｈｏｍｅキー
４０４  無線通信ネットワークソフトキー
４０５  Ｉｎｆｏキー
５００  無線通信ネットワークトランスレータ
５４１  株式市況サービスプロバイダ
５４２  会社データベースプロバイダ
５４３  サーバプロバイダ
６００  携帯電話機
６０１  ＲＯＭ
６０２  クライアントモジュール
６０３  サポートモジュール
６０５  ディスプレイスクリーン
６１０  物理層プロセッサ
７００  携帯電話機
７０２  クライアントモジュール
７０５  ディスプレイ
７１０  ＣＤＰＤ（セルラーデジタルパケットデータ）ネットワーク
７１１  キーパッドモジュール
７１２  ディスプレイモジュール
７１４  ＵＤＰ（ユーザデータグラムプロトコル）インタフェース
７１５  キーパッド
７１６  メモリ
７４３  サーバコンピュータ
７４８  ＵＤＰインタフェース
７４９  ＨＴＴＰサーバ
７５０  無線通信ネットワーク
７５５  メモリ
７６０  ＴＩＬデック
７６１  ＣＧＩプログラム
９０１  テキスト入力モジュール
９０２  文字頻度テーブル
９０３  テキストバッファ
１２０１  制御モジュール
１２０２  ＵＤＰインタフェース
１２０３  ＴＣＰインタフェース
１２０４  ＡＮＴリクエストプロセッサ
１２１０  メモリ
１２１１  トランザクションログ
１２１２  サーバデータ
１２１３  カストマーデータ
【図１】
0004274661.tif 000017
【図２】
0004274661.tif 000018
【図３】
0004274661.tif 000019
【図４】
0004274661.tif 000020
【図５】
0004274661.tif 000021
【図６】
0004274661.tif 000022
【図７】
0004274661.tif 000023
【図８】
0004274661.tif 000024
【図９】
0004274661.tif 000025
【図１０】
0004274661.tif 000026
【図１１】
0004274661.tif 000027
【図１２】
0004274661.tif 000028
【図１３】
0004274661.tif 000029
【図１４】
0004274661.tif 000030
【図１５】
0004274661.tif 000031
【図１６】
0004274661.tif 000032
【図１７】
0004274661.tif 000033
【図１８】
0004274661.tif 000034
【図１９】
0004274661.tif 000035
【図２０】
0004274661.tif 000036
【図２１】
0004274661.tif 000037
【図２２】
0004274661.tif 000038
【図２３】
0004274661.tif 000039
【図２４】
0004274661.tif 000040
【図２５】
0004274661.tif 000041
【図２６】
0004274661.tif 000042
【図２７】
0004274661.tif 000043
【図２８】
0004274661.tif 000044
【図２９】
0004274661.tif 000045
【図３０】
0004274661.tif 000046
【図３１】
0004274661.tif 000047
【図３２】
0004274661.tif 000048
【図３３】
0004274661.tif 000049
【図３４】
0004274661.tif 000050
【図３５】
0004274661.tif 000051
【図３６】
0004274661.tif 000052
【図３７】
0004274661.tif 000053
【図３８】
0004274661.tif 000054
【図３９】
0004274661.tif 000055
【図４０】
0004274661.tif 000056
【図４１】
0004274661.tif 000057
【図４２】
0004274661.tif 000058
【図４３】
0004274661.tif 000059
【図４４】
0004274661.tif 000060
【図４５】
0004274661.tif 000061
【図４６】
0004274661.tif 000062
【図４７】
0004274661.tif 000063
【図４８】
0004274661.tif 000064
【図４９】
0004274661.tif 000065
【図５０】
0004274661.tif 000066