(57)【要約】  クライアントおよびサーバを有するコミュニケーションシステムがブラウザ性能をも有するコミュニケーションシステム。コミュニケーションシステムが、従来から公知の方法と同様の方法で、パラメータが添付されたアドレスの呼び出しによってクライアントからサーバへリクエストを行うことを可能にする。しかし、本発明によるシステムは、クライアントからサーバへ１つのパラメータのみを送信し、このパラメータが符号化された、バイナリデータパケット（スタートパケット）を含む。【特許請求の範囲】
【請求項１】
互いに通信を行うクライアントおよびサーバを有するコミュニケーションシステムがブラウザ性能を有するコミュニケーションシステムであって、該クライアントが、パラメータが添付されるリクエストによって該サーバを呼び出し、該サーバが、リクエストされたデータパケットを送ることによって該クライアントに返答し、該クライアントが行う該リクエストに添付される該パラメータが、送信のために符号化されるバイナリデータパケット（リクエストパケット）を含むことを特徴とする、ブラウザ機能を有するコミュニケーションシステム。
【請求項２】
Ｗｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＷＡＰ）に従うブラウザ性能を有する、請求項１に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項３】
前記リクエストがＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）を含む、請求項１または２に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項４】
前記リクエストが、前記添付されるパラメータを有し、該リクエストが最大２５６文字の長さであることを特徴とする、請求項１から３のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項５】
前記リクエストに添付される前記パラメータの中で識別コード（ｓｅｓｓｉｏｎ＿ｉｄ）が送信されることによって、前記サーバを用いてハンドシェークプロシージャが可能であることを特徴とする、請求項１から４のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項６】
リクエストされると、前記サーバが、データパケット（Ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）を前記クライアントに送信し、該提供されるサービスの識別のためにサービスＩＤコード（Ｓｅｒｖｉｃｅ＿ＩＤ）を送信することに加え、デバイス番号（Ｄｅｖｉｃｅ＿ｉｄ）およびエラー検出コード（ＣＲＣ＿３２）を送信し、続いてバイナリ志向の有用データを送信することを特徴とする、請求項１から５のいずれかまたは請求項１の前部分に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項７】
前記ユーザデータがバイナリコード化されることを特徴とする、請求項６に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項８】
前記ユーザデータの長さが可変であることを特徴とする、請求項４または５に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項９】
前記サーバから前記クライアント（Ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）に送られる前記データパケットが非常に多くの連続するビットを有し、該ビットが、
前記サービス識別コード（Ｓｅｒｖｉｃｅ  ＩＤ）、
該シリアルナンバーの長さ、
シリアルナンバー、将来の用途のためのさらなる保存エリア、
パケットの数（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
たった今送られたパッケージ番号（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
セクション番号
のように次々と配列されることを特徴とする、請求項６から８のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１０】
前記サービス識別（ｓｅｒｖｉｃｅ＿ｉｄ）がある特定のビット幅を有し、該サービス識別が、前記データパケット（ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）の中に含まれる前記データの残りの復号化を可能にすることを特徴とする、請求項６から９のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１１】
前記セクション番号（ｓｅｃｔｉｏｎ＿ｉｄ）が可変長を有し、該セクション番号が最初の呼び出しで前記サーバによって生成され規定されることを特徴とする、請求項６から１０のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１２】
前記提供されるサービスのうちの１つが、近隣に位置する前記クライアントの目的地の検索のために意図されることを特徴とする、請求項１から１１のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１３】
前記提供されるサービスのうちの１つが、前記クライアントの現時点の位置のクエリを行う役割を果たすことを特徴とする、請求項１から１２のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１４】
前記サーバが、リクエストされると、ＭＩＭＥ形式のデータパケットを前記クライアントに送ることを特徴とする、請求項１から１３のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１５】
前記クライアントが、乗り物のコミュニケーションシステム内で、端末または端末の部分として形成されることを特徴とする、請求項１から１４のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１６】
前記クライアントがカーラジオ／ナビゲーションシステムの中に内蔵されることを特徴とする、請求項１５に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項１７】
請求項１から１６のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、移動コミュニケーションシステムの端末。
【請求項１８】
請求項１から１４のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、請求項１から１７のいずれかに記載のサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブラウザ性能を有するコミュニケーションシステムが、所定のプロトコルを使用して互いに通信を行うサーバおよびクライアントを有する、本発明の請求項１の特徴によるコミュニケーションシステムに関する。
【背景技術】
【０００２】
例えば、ＷＡＰ性能を有する移動電話（携帯電話）に接続するだけでなく、本出願人によってＢｅｃｋｅｒ−Ｒａｄｉｏ  Ｏｎｌｉｎｅ  Ｐｒｏという名称で販売されているカーラジオデバイスとも接続する、例えばＷＡＰブラウザ性能を有するコミュニケーションシステムはすでに公知である。
【０００３】
この引用されるＯｎｌｉｎｅ  Ｐｒｏのタイプのカーラジオは内蔵型のＧＳＭモジュールを有し、それを利用して電話をかけＷＡＰページを呼び出すことが可能である。サーバから呼び出されるＷＡＰページがその後３行の画面に示される。さらに、このカーラジオが内蔵型ナビゲーションシステムを有する。このナビゲーションシステムは、リクエストされると、ＷＥＢ．ｄｅなどのサーバから現在の交通渋滞情報を引き出し得、必要な場合には、運転者が、発生中の交通渋滞を迂回して運転し得るように、この情報を計算されたルートに直接含み得る。
【０００４】
公知の方法では、以下が問題となる。（端末、例えば携帯電話またはカーラジオなどの）クライアントとサーバとの間のコミュニケーションに関し、無線アプリケーションプロトコル（ＷＡＰ）が提供するもので行い得ることは限られている。ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介して、クライアントはＨＴＴＰ−ＧＥＴコマンドを使用してサーバにリクエストを置き得、その結果、パラメータがサーバに送られる。
【０００５】
現在の方法では、ＵＲＬの呼び出しを介し、添付されるパラメータを用いて、クライアント（ＯｎｌｉｎｅＰｒｏ）からサーバ（ＷＡＰサーバ）へリクエストが行われる。添付されるパラメータは、キーボード、セパレータおよび、例えば以下の種類の値からなる。
【０００６】
例１：
．．．／ｔｅｓｔａｐｐｌ．ｃｇｉ？ｎａｖｄｅｓｔ＝［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［２］ＨＩＬＤＥＳＨＥＩＭ，，［３］ＤＡＩＭＬＥＲＲＩＮＧ
例２：
．．．／ｔｅｓｔａｐｐｌ２．ｐｈｐ？ｐａｒａｍ１＝ｓｏｍｅｖａｌｕｅ＆ｐａｒａｍ２＝ａｎｏｔｈｅｒｖａｌｕｅ．．．
リクエストが機能する方法は、Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）方法に従って記載される。
【０００７】
サーバは、理解し得る形式でその答えをクライアントに送らねばならない。答えのデータは、接続を確立している間にクライアントが通知を行ったＭｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎ  （ＭＩＭＥ−ＴＹＰＥ）の方法で符号化される。このリクエストから、ＷＡＰサーバが特定のＭＩＭＥ形式（例えば、，’ｘ−ｂｅｃｋｅｒ／ｖｎｄ．ｗａｐ．ｂｉｍ’）を有するパケットを生成する。このパケットは平文のデータを含む。そのパケットのサイズは限定される。
【０００８】
しかし、公知の方法は、それ自体ではクライアントからサーバへ２５６バイト以上の送信を確実に行う可能性を何も提供せず、サーバからクライアントへの返事のサイズもまた限られている（正確なサイズはその実行に応じる）。
【発明の開示】
【課題を解決するための手段】
【０００９】
本明細書で説明する本発明はここからスタートする。
【００１０】
本発明の目的は、データ通信においてそのような限定を持たないブラウザ性能を有するコミュニケーションシステムを提供することである。
【００１１】
この目的は、請求項１の特徴を有するコミュニケーションシステムの手段によって解決される。
【００１２】
それをさらに発展させたものが従属請求項の内容である。
【００１３】
本発明によると、ブラウザはインターネット上を次々と移動するプログラムと考えられる。ブラウザが、インターネットから情報を取り出し表示する役割を行う。ブラウザは、テキスト、絵およびプログラムを含み得る、受け取ったＨＴＭＬページを図形的に表示する。さらに、例えば音声およびビデオファイルをある特定のプログラムによって表示し得るように、ユーザが、ＷＷＷブラウザを調節し得る。公知のブラウザのいくつかの例は、Ｎｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ，Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ，ＮＳＣＡ  Ｍｏｓａｉｃ，  ＬＹＮＸである。ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）ページの表示に加え、ＷＷＷブラウザは
・電子メールを読むことおよび書くこと
・ファイルの（サーバからローカルコンピュータへの）送信
・ニュースを読むことおよび書くこと
などのサービスを提供する。
本明細書で説明する、本発明の枠組みにおいて、ＵＲＬは「Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ」の公知の略語である。ＵＲＬの助けを借りて、インターネット上の全ての情報が世界中で明確にアドレス指定される。例えば、ｈｔｔｐ：／／ｗｗｗ．ｂｅｃｋｅｒ．ｄｅというＵＲＬは、使用される伝送プロトコル、ｈｔｔｐ：（は、ＨＴＭＬドキュメントを送ることに責任を負う）、サブレベルドメインのｗｗｗ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ），ドメインのＢｅｃｋｅｒ、トップレベルドメインのｄｅ（ドイツ―Ｄｅｕｔｓｃｈｌａｎｄを表す）および対応するページ（またはファイル）のリンクのパスからなる。この個々のアドレスのコンポーネントの階層的な順番は、正しいアドレスに到達するために必要である。特にＨＴＭＬページのＵＲＬはリンクとしての役割をし、その上で、ユーザがマウスクリック１つでウェブサイトからウェブサイトへ移動し得る。
【００１４】
ブラウザ性能を有するコミュニケーションシステムは、ブラウザの助けを借りてコミュニケーションデータをユーザ間に送るコミュニケーションシステムであると理解される。
【００１５】
コミュニケーションシステムの必須要素は、データ伝送プロトコルであり、それを用いてクライアントとサーバとの間のコミュニケーションが確立される。本発明による方法では、クライアント（ＯｎｌｉｎｅＰｒｏ）からサーバへのリクエストが従来と同じ手法で、パラメータを用いてＵＲＬなどのリソースロケータを呼び出すことによって行われる。しかし、新しい方法は、ただ１つのパラメータを送信し、それが送信のために符号化されたバイナリパケットを含む。
【００１６】
必要なら、そのプロトコルが、起こり得るパケットのフラグメンテーション／フラグメンテーションの解消に備える。そのプロトコルが、異なるサービスが１つのデータ形式で処理されることを可能にし、例えば応答パケットが常に同じＭＩＭＥ形式を有し得る。
【００１７】
このソルーションによって、公知のシステムに比べて以下の利点が達成される。
【００１８】
−より大きいデータパケットがいくつかのステップで自動的に送られる。
【００１９】
−サーバが、クライアントからのデータをリクエストすることが可能である。これは通常では全く不可能である。
【００２０】
−必要とされるＭＩＭＥ形式がただ１つなので（ｈｔｔｐサーバの再コンフィギュレーションがないので）、本方法を用いて実行される新しいサービスが、以前よりもかなり迅速に、動作され得る。
【００２１】
−内部タスク識別コードの評価が、プロトコルを将来的にも保証されるものとする。
【００２２】
本発明によると、サーバが、再び、公知の方法と同じ方法で、クライアントからのリクエストに対して反応する。しかし上で説明したように、またも、パケット内容はもはや平文には含まれないが、本発明のアプリケーションによって書類内に含まれるように、バイナリに含まれる。
【００２３】
このことが、今度は、古い方法に比べて以下の利点を有する。
【００２４】
−伝送されるデータ量がより小さい（個々の値をビットシーケンスに要約する）
−内容がもはや全ての人に明らかなわけではない。
【００２５】
−端末ソフトウェアにとって、より簡単でより迅速に読み得る。
【００２６】
−ハンドシェークプロセスの実現（１以上のサブパケットの伝送）
−（ＵＲＬなどの）リプライリソースロケータを伝送することによるサーバリクエストの実現およびハンドシェークの実現
以下で、総合ナビゲーションシステム及びＧＰＳモジュールを有するカーラジオ（以下でクライアントと呼ぶ）を使用する具体的な実施形態が説明される。この実施形態では、リソースローケータが、上で説明したように、公知のＵＲＬの呼び出しであり、公知のＷＡＰ（「Ｗｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ」）が伝送形式として使用されると想定される。しかし、本発明はこのＵＲＬ及びＷＡＰに制限されない。
【００２７】
後者のＷＡＰプロトコルを使用して、ＷＡＰサーバを用いるコミュニケーションが可能である。データインターフェースを含む必要なＷＡＰブラウザが、カーラジオで実行されていると想定される。このカーラジオは、非常に異なるパラメータがサーバに伝送され得、その後、それが各ユーザに対する特定の内容を生成し得る、というように形成される。
【００２８】
古典的なＷＡＰアーキテクチャのように、１つの側にクライアントがあり、他方側にサーバがある。決まりとして、このクライアントが開始者であり、クライアントが接続を確立しデータをリクエストする。このサーバはリクエストされるデータのみを供給し、リクエストを開始することはできない。
【００２９】
このサーバは、端末がＷＡＰブラウザの助けを借りて特定のデータを取り出す手配をするために、ＳＭＳプッシュのみを使用し得る。データ接続は内蔵ＧＳＭモデムおよび選択されるアクセスプロファイルを介して生成される。接続が確立された後、要求されるインターネットポータルが呼び出され、全ての可能なサービスがＷＭＬ（Ｗｉｒｅｌｅｓｓ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ページとして表示される。このポータルコールは、デバイス番号、パスワード、乗り物識別番号およびＵＲＬパラメータのような地理的座標などのパラメータの非常に広い範囲を進む。
【００３０】
このサーバが、今度は、各ユーザのために動的に生成される情報を有するＷＡＰページを組み立てる。その後、従来の意味においてＷＡＰの入力を通してナビゲーションを行うのと同様に、これらの内容を通してナビゲーションを行うことが可能である。
【００３１】
例えば、ユーザがホテル検索を選択した場合、ログイン時に通過した位置に応じて、考え得る地域がサーバ側で計算され、可能なホテルがデータベースから選択される。これらの結果が、ＷＭＬページの形式で端末に送り返される。
【００３２】
ユーザが所望のホテルを選択し、その後、リンクを含む、ホテルに関する詳細なデータを（再びＷＭＬページとして）受け取る。このリンクが、そのナビゲーションシステムのための目的地記述を含むデータパケットを表に出さない。この接続はナビゲーションデータが送られた後、終了する。
【発明を実施するための最良の形態】
【００３３】
１．  データパケットの形式
クライアントとサーバの間で交換されるデータパケットの形式が以下のように提示される。
【００３４】
ＭＩＭＥ形式に加え、サーバからクライアントへ送られるデータパケット（サービスパケット）およびクライアントからサーバへ送られるデータパケット（リクエストパケット）の形式の表記がある。
【００３５】
１．１  Ｃｏｎｔｅｎｔ／ＭＩＭＥタイプ形式
このために選択されるＣｏｎｔｅｎｔ形式またはＭＩＭＥ形式は、例えばｘ−ｂｅｃｋｅｒ／ｖｎｄ．ｗａｐ．ｌｂｓ．と呼ばれる。
【００３６】
ＭＩＭＥ形式はＩＡＮＡの要求を満たすために「ｘ−」で始めなければならない（ｗｗｗ．ｗ３ｃ．ｏｒｇ−ＲＦＣ１７００を参照のこと）。サーバからクライアントに送られるデータのためのこの形式は、将来的にも保証（ｆｕｔｕｒｅ−ｐｒｏｏｆ）されている。それは、異なるサービスが、このＭＩＭＥ形式を有する単に別々のＳｅｒｖｉｃｅ  ＩＤによって処理され得るからである。
【００３７】
含まれるＳｅｒｖｉｃｅ  ＩＤに従って、このＭＩＭＥ形式を有するデータパケットのみが、クライアントによって復号化される。
【００３８】
１．２  サービスパケット（サーバ）
サービスパケットはリクエストが行われたとき、サーバポータルからクライアントに送られる。Ｓｅｒｖｉｃｅ  ＩＤコード，デバイス番号およびＣＲＣ３２チェックに加え、サービスパケットは有用なデータを含む。有用なデータの長さは選択されるサービスに応じる。したがって、この形式は比較的フレキシブルである。
【００３９】
１．２．１  データパケットの形式
これらのパケットの記述は、ＭＰＥＧ２のシンタックス規格および比較的理解しやすい疑似プログラム言語に従う。このプロトコルのセットアップは、例えば以下のように選択されている。
【００４０】
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ（）
｛
ｓｅｒｖｉｃｅ＿ｉｄ      ８  ｂｉｔｓ    ／／サービス識別コード
ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／シリアルナンバーの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｖｉｃｅ＿ｉｄ［ｎ１］    ８  ｂｉｔｓ    ／／シリアルナンバー
｝
ｒｅｓｅｒｖｅｄ    ３２  ｂｉｔｓ    ／／将来の使用のため
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ    ４  ｂｉｔｓ    ／／パケットの数
ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ    ４  ｂｉｔｓ    ／／このパケットの番号
ｆｏｒ（ｎ１＝０；ｎ１＜ｓｅｓｓｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｓｅｓｓｉｏｎ＿ｉｄ［ｎ１］    ８  ｂｉｔｓ    ／／セッションＩＤ
｝
ｓｗｉｔｃｈ（ｓｅｒｖｉｃｅ＿ｉｄ）
｛
ｃａｓｅ  ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｎａｖｄｅｓｔｉｎａｔｉｏｎｓ（）
ｂｒｅａｋ
ｃａｓｅ  ＳＥＲＶＩＣＥ＿ＳＥＲＶＥＲＲＥＱＵＥＳＴ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｓｅｒｖｅｒｒｅｑｕｅｓｔ（）
ｂｒｅａｋ
ｃａｓｅ  ＳＥＲＶＩＣＥ＿ＴＴＳ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｔｔｓ（）
ｂｒｅａｋ
ｃａｓｅ  ＳＥＲＣＩＣＥ＿．．．：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ．．．（）
ｂｒｅａｋ
｝
ＣＲＣ＿３２    ３２  ｂｉｔｓ    ／／自動エラーコレクション
｝
この場合、ｓｅｒｖｉｃｅ＿ｉｄはそれぞれのサービスの識別コードである。この８ビットのＩＤを使用して、パケットの中に含まれる残りのデータが復号化される。可能なＳｅｒｖｉｃｅ  ＩＤは以下であり得る。
【００４１】
【表１】
2005510818.tif 000002
ｄｅｖｉｃｅ＿ｉｄはデバイス番号を含む。それはソースコードのいくつかの部分ではユーザネームと呼ばれる。
【００４２】
２つの４ビット値のｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒおよびｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、次々といくつのこの形式のパケットが送られているのか、および現在のパケットのパケット番号は何番なのかを記述する。これは、データ量が通常の量を超える将来のバージョンにとって絶対的に有用である。１つの実施形態では、これらの２つの値が常に１に設定され得る。
【００４３】
１つ以上のセクションを送るために、ｓｅｓｓｉｏｎ＿ｉｄが必要とされ、それが各データ交換の伝送に含まれる。それは可変の長さを有し、サーバが呼び出されたときに初めてサーバによって生成／規定される。ＴＤＳのために必要とされるようなハンドシェイクプロセスは、例えば、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ，ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒおよびｓｅｓｓｉｏｎ＿ｉｄの組み合わせを使用して実現され得る。
【００４４】
最後の値のＣＲＣ３２を除き、ｓｅｒｖｉｃｅ＿ｉｄに応じてさらなる復号化が行われる。いわゆる有用データの符号化は以下の適切なセクションで取り扱われる。
【００４５】
１．２．２  Ｓｅｒｖｉｃｅ．ＩＤ  ＳＥＲＶＩＣＥ  ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ
ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ  ＩＤに接続して、近隣で見つけられる目的地の検索のためのサービスが、本明細書に説明される全てのサービスの最初のものであった。このサービスを用いて、（レストラン、ホテル、鉄道の駅、博物館などの）特別の目的地のナビゲーションデータのリクエストが可能である。この入手し得る目的地情報は「通常の」ＣＤナビゲーションデータには含まれない。
【００４６】
この追加のサービスにより、カーラジオが電話帳の職業別企業案内の形をとることができる。この方法でリクエストされるナビゲーションデータの料金は、一方ではリクエスト者に請求され得るが、他方、（例えばレストランのオーナーなど）その目的地の所有者に請求され得る。
【００４７】
データパケットの形式は、例えば以下のようである。
【００４８】
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｎａｖｄｅｓｔｉｎａｔｉｏｎｓ（）
｛
ｓｔａｒｔ＿ｍｏｄｅ    ２  ｂｉｔｓ    ／／ナビゲーションのため
ｓａｖｅ＿ｍｏｄｅ    １  ｂｉｔｓ    ／／イエスまたはノーを保存する
ｒｅｓｅｒｖｅｄ    ５  ｂｉｔｓ    ／／将来の使用のため
ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ    ８  ｂｉｔｓ    ／／パケットの中の目的地の数
ｆｏｒ（ｉ＝０；ｉ＜ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ；ｉ＋＋）
｛
ｄｅｓｔ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／文字列の文字の数
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｓｔ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｓｔｉｎａｔｉｏｎ［ｎ１］    ／／目的地の文字
｝
ｕｒｌ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／文字列の文字の数
ｆｏｒ（ｎ１＝０；ｎ１＜ｕｒｌ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｕｒｌ［ｎ１］    ／／目的地情報を有するＵＲＬ
｝
｝１つのナビゲーション目的地に対して１つのＵＲＬ、などの追加のデータが、定義に応じてデータパケットに添付され得る。
【００４９】
ヘッダデータが復号化された際にＳｅｒｖｉｃｅ  ＩＤ  ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳが見つけられると、ここに記録されたシンタックスにしたがって、有用データが復号化される。
【００５０】
ｓｔａｒｔ＿ｍｏｄｅ（２ビット値）およびｓａｖｅ＿ｍｏｄｅ（１ビット値）の２つの値がナビゲーションそのものに必要とされる。スタートモードはナビゲーションをすぐに開始するのか、または、送られてきた目的地が、後に使用するための可能な目的地として、先ずメモリに置かれるべきかを確立するために使用される。ここで可能な値は以下の表に記載される。
【００５１】
【表２】
2005510818.tif 000003
表：ナビゲーションのための、可能なスタートモード
次に、ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔの値、つまりこのパケットの目的地の数がこのブロックにくる。次に、正確にｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ回、回るループがくる。ここが個々の目的地が読み出される場所である。
【００５２】
１．２．２．１  目的地文字列
目的地文字列は送られている目的地を示す。この文字列は、いわゆるｓｅｌｅｃｔｉｏｎ  ｃｒｉｔｅｒｉａのタグで作られ、その後、各記述が続く。このｓｅｌｅｃｔｉｏｎ  ｃｒｉｔｅｒｉａは四角の括弧で括られ、数字（十進法数）を含む。
【００５３】
文字列自体は例えば次のようである。
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［２］ＨＡＭＢＵＲＧ，，［３］ＷＥＮＤＥＮＳＴＲＡＳＳＥ，，［２５６］Ｉｎｎｏｖａｔｉｖｅ  Ｓｙｓｔｅｍｓ
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［１２４］０  ０
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［１２４］０−７３４５０，，［２５６］ＭｃＤｏｎａｌｄｓ  Ｅｃｕａｄｏｒ
同様に、ＷＧＳ８４形式で目的地を特定することも可能である。ＷＧＳ−８４座標は、目的地ガイドについて５０メートルの誤差（各方向において、Ｎａｖ−Ｔｅｃｈデータで１０メートル＋ＧＰＳデータの誤差２０メートル）を有する。
【００５４】
１．２．３  Ｓｅｒｖｉｃ−ＩＤ  ＳＥＲＶＩＣＥ  ＳＥＲＶＥＲＲＥＱＵＥＳＴ
このサービスによって、サーバが、リクエストを行っているデバイスの現在地のクエリを行うことが可能である。この情報はＬｏｃａｔｉｏｎ  Ｂａｓｅｄ  Ｓｅｒｖｉｃｅにとって必須のものである。
【００５５】
現時点の地理的データは、ログインの間にすでにカーラジオに渡され得る。しかし、現時点の地理的データは、好ましくはクライアントのリクエストパケットを介してサーバに提供される。
【００５６】
サーバが、また別の時に位置データを所望すると、それは、このサーバリクエストを介してリクエストされ得る。この機能は、例えば、（輸送車等の）隊の管理、緊急呼び出し指令の発令、引き上げ指令実行などにとって重要である。
【００５７】
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｓｅｒｖｅｒｒｅｑｕｅｓｔ（）
｛
ｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌ    ８  ｂｉｔｓ    ／／ＵＲＬの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌ；ｎ１＋＋）
｛
ｒｅｓｐｏｎｓｅ＿ｕｒｌ［ｎ１］    ／／返答のためのＵＲＬ
｝
｝
クライアントは、サーバによるリクエストへの回答のために、返答を返すべきＵＲＬを必要とする。まず、ＵＲＬの長さｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌが８ビット値として特定され、その後、実際の文字列がくる。
【００５８】
１．３  Ｒｅｑｕｅｓｔ  Ｐａｃｋｅｔ（クライアント）
サーバの返答と同様の方法で、よりバイナリ志向型の形式は、クライアントによるデータのリクエストのために、切り替えられる。データパケットの形式が以下でさらに詳細に説明される。
【００５９】
サービスパケットと対照的に、ブラウザの制約のために、ここではバイナリパケットは簡単に送信され得ない（プッシュトランスミッション）が、代わりにＵＲＬへのリクエストに添付されなければならない。これは、データがＵＲＬに特有の表記法に変換されることを要求する。ここでは、ＵＲＬの長さが２５６文字を超えないことが遵守されなければならない。そうしなければ送信ルートのより古いゲートウェイがデータを削除し得るからである。
【００６０】
パケット内の、あちこちに行き交うＳｅｓｓｉｏｎ  ＩＤを送信することによって、現在行われているセッションがこのＵＲＬコールによって終了される必要がない。例えば、（通信）申込者は、自分のオンラインポータルで、例えば、最初にユーザネームおよびパスワードでログインする。このときから、申込者は符号化された形式でデータが送信されるセッションに入る。申込者が、クライアントが作り出した自己生成されたＵＲＬを有するリンクを呼びだす試みを明確に行うと、サーバが、それがＳｅｓｓｉｏｎ  ＩＤに基く同じセッションであると認識しない限り、申込者は新しいセッションを始める。
【００６１】
１．３．１  データパケットの形式
データパケットの形式は前回存在した形式に従う。Ｓｅｓｓｉｏｎ  ＩＤは、別個のパラメータとしてＵＲＬに添付されるか、またはここのパケットの中に一体化されるかどちらでも可能である。前者の場合、Ｓｅｓｓｉｏｎ  ＩＤの長さは０に設定される。この場合の１例としては以下のようであり得る。
【００６２】
ｒｅｑｕｅｓｔ＿ｐａｃｋｅｔ
｛
ｔａｓｋ＿ｎａｍｅ    ２４  ｂｉｔｓ    ／／タスク識別（旧）
ｓｅｒｖｉｃｅ＿ｉｄ    ８  ｂｉｔｓ    ／／サービスの識別
ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／シリアルナンバーの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｖｉｃｅ＿ｉｄ［ｎ１］    ８  ｂｉｔｓ    ／／シリアルナンバー
｝
ｆｉｎ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／乗り物識別番号の長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｆｉｎ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｆｉｎ［ｎ１］    ８  ｂｉｔｓ    ／／乗り物識別番号
｝
ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／バージョン識別の長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ  ［ｎ１］８  ｂｉｔｓ    ／／バージョン識別
｝
ｌａｎｇｕａｇｅ＿ｉｄ    ８  ｂｉｔｓ    ／／クライアントの言語選択
ｒｅｓｅｒｖｅｄ    ３２  ｂｉｔｓ    ／／将来の使用のため
ｐａｓｓｗｏｒｄ＿ｌｅｎｇｔｈ    ８  ｂｉｔｓ    ／／パスワードの長さ
ｆｏｒ（ｎ２＝０；ｎ２＜ｐａｓｓｗｏｒｄ＿］ｌｅｎｇｔｈ；ｎ２＋＋）
｛
ｐａｓｓｗｏｒｄ［ｎ２］    ８ｂｉｔｓ    ／／パスワード内の文字
｝
ｆｏｒ（ｎ３＝０；ｎ３＜ｓｅｓｓｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈ；３ｎ＋＋）
｛
ｓｅｓｓｉｏｎ＿ｉｄ［ｎ３］    ８  ｂｉｔｓ    ／／セッションＩＤ内の文字
｝
ｌｏｎｇｉｔｕｄｅ    ３２  ｂｉｔｓ    ／／経度
ｌａｔｉｔｕｄｅ    ３２ｂｉｔｓ    ／／緯度
ｉｆ（ｓｅｒｖｉｃｅ＿ｉｄ＝＝ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ）
｛                                    ／／何の追加データも
｝                                    ／／ここにリクエストされない
ｅｌｓｅ  ｉｆ（ｓｅｒｖｉｃｅ＿ｉｄ＝＝ＳＥＲＶＩＣＥ＿．．．）    ／／これは異なって見られ得る
｛                                        ／／他のリクエストのため
．．．．
｝
ＣＲＣ＿３２    ３２  ｂｉｔｓ    ／／エラー訂正
｝
旧から新への送信をより容易にするために、ｔａｓｋ＿ｎａｍｅタグはこの形式にまだ含まれる。
【００６３】
実際のリクエストはｓｅｒｖｉｃｅ＿ｉｄタグの中にある。ここで、受信者が使用を望むＳｅｒｖｉｃｅ  ＩＤが特定されるか、またはその結果、要求されるかが行われる。
【００６４】
個々のリクエストのために、追加のデータが必要とされる場合、このパケットの、より下の部分で実行される。
【００６５】
ｄｅｖｉｃｅ＿ｉｄはクライアントのデバイス番号であり，サーバの返答の中にあるものと同じである。それは１４文字からなる。
【００６６】
それに続く６つの値が乗り物の現時点の位置をＸＹ座標で記述する。
【手続補正書】
【提出日】平成16年6月1日(2004.6.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ブラウザ性能を有するコミュニケーションシステムであって、互いに通信を行うサーバとクライアントとを含み、
該クライアントがリクエストを該サーバに送信し、該リクエストに、符号化されたバイナリのデータパケット（Ｒｅｑｕｅｓｔ  ｐａｃｋｅｔ）の形式でパラメータが添付され、該サーバが、リクエストされたデータパケットを送ることによって該リクエストに返答をする、ブラウザ性能を有するコミュニケーションシステム。
【請求項２】
Ｗｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＷＡＰ）に従うブラウザ性能を有する、請求項１に記載のブラウザ性能を有するコミュニケーションシステム。
【請求項３】
前記リクエストがＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）を含む、請求項１または２に記載のコミュニケーションシステム。
【請求項４】
前記リクエストが、添付されるパラメータを有し、該リクエストが最大２５６文字の長さである、請求項１から３のいずれかに記載のコミュニケーションシステム。
【請求項５】
識別コード（ｓｅｓｓｉｏｎ＿ｉｄ）が、前記リクエストに添付される前記パラメータの中で送信されることによって、ハンドシェークプロシージャが前記サーバを用いて可能である、請求項１から４のいずれかに記載のコミュニケーションシステム。
【請求項６】
リクエストされると、前記サーバがデータパケット（Ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）を前記クライアントに送信し、該データパケットが、該提供されるサービスの識別のためのサービスＩＤコード（Ｓｅｒｖｉｃｅ＿ＩＤ）に加え、デバイス番号（Ｄｅｖｉｃｅ＿ｉｄ）とエラー検出コード（ＣＲＣ＿３２）と、続いてバイナリのペイロードの有用データを含む、請求項１から５のいずれかまたは請求項１の前部分に記載のコミュニケーションシステム。
【請求項７】
前記ユーザデータがバイナリコード化される、請求項６に記載のコミュニケーションシステム。
【請求項８】
前記ユーザデータの長さが可変である、請求項４または５に記載のコミュニケーションシステム。
【請求項９】
前記サーバから前記クライアントに送られる前記データパケット（Ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）が非常に多くの連続するビットを有し、該ビットが、
前記サービス識別コード（Ｓｅｒｖｉｃｅ  ＩＤ）、
該シリアルナンバーの長さ、
シリアルナンバー、将来の用途のためのさらなる保存エリア、
パケットの数（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
たった今送られたパッケージの番号（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
セクション番号
のように次々と配列されることを特徴とする、請求項６から８のいずれかに記載のコミュニケーションシステム。
【請求項１０】
前記サービス識別（ｓｅｒｖｉｃｅ＿ｉｄ）が、ある特定のビット幅を有し、該サービス識別が前記データパケット（ｓｅｒｖｉｃｅ  ｐａｃｋｅｔｓ）の中に含まれる前記データの残りの復号化を可能にする、請求項６から９のいずれかに記載のコミュニケーションシステム。
【請求項１１】
前記セクション番号（ｓｅｃｔｉｏｎ＿ｉｄ）が可変長を有し、該セクション番号が最初の呼び出しで前記サーバによって生成され規定される、請求項６から１０のいずれかに記載のコミュニケーションシステム。
【請求項１２】
前記提供されるサービスのうちの１つが、前記クライアントの近隣に位置する目的地の検索のために意図される、請求項１から１１のいずれかに記載のコミュニケーションシステム。
【請求項１３】
前記提供されるサービスのうちの１つが、前記クライアントの現時点の位置のクエリを行う役割を果たす、請求項１から１２のいずれかに記載のコミュニケーションシステム。
【請求項１４】
前記サーバが、リクエストされると、ＭＩＭＥ形式のデータパケットを前記クライアントに送る、請求項１から１３のいずれかに記載のコミュニケーションシステム。
【請求項１５】
前記クライアントが、乗り物のコミュニケーションシステム内で、端末または端末の部分として形成される、請求項１から１４のいずれかに記載のコミュニケーションシステム。
【請求項１６】
前記クライアントがカーラジオ／ナビゲーションシステムの中に内蔵される、請求項１５に記載のコミュニケーションシステム。
【請求項１７】
請求項１から１６のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、移動コミュニケーションシステムの端末。
【請求項１８】
請求項１から１４のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、コミュニケーションシステムのサーバ。
【国際調査報告】
2005510818.tif 000004
2005510818.tif 000005
2005510818.tif 000006
2005510818.tif 000007
2005510818.tif 000008
2005510818.tif 000009
2005510818.tif 000010
2005510818.tif 000011
2005510818.tif 000012
2005510818.tif 000013