JP2005510818A - クライアントおよびサーバを有するコミュニケーションシステムがブラウザ性能をも有するコミュニケーションシステム - Google Patents

Abstract

クライアントおよびサーバを有するコミュニケーションシステムがブラウザ性能をも有するコミュニケーションシステム。コミュニケーションシステムが、従来から公知の方法と同様の方法で、パラメータが添付されたアドレスの呼び出しによってクライアントからサーバへリクエストを行うことを可能にする。しかし、本発明によるシステムは、クライアントからサーバへ１つのパラメータのみを送信し、このパラメータが符号化された、バイナリデータパケット（スタートパケット）を含む。

Description

本発明は、ブラウザ性能を有するコミュニケーションシステムが、所定のプロトコルを使用して互いに通信を行うサーバおよびクライアントを有する、本発明の請求項１の特徴によるコミュニケーションシステムに関する。

例えば、ＷＡＰ性能を有する移動電話（携帯電話）に接続するだけでなく、本出願人によってＢｅｃｋｅｒ−Ｒａｄｉｏ Ｏｎｌｉｎｅ Ｐｒｏという名称で販売されているカーラジオデバイスとも接続する、例えばＷＡＰブラウザ性能を有するコミュニケーションシステムはすでに公知である。

この引用されるＯｎｌｉｎｅ Ｐｒｏのタイプのカーラジオは内蔵型のＧＳＭモジュールを有し、それを利用して電話をかけＷＡＰページを呼び出すことが可能である。サーバから呼び出されるＷＡＰページがその後３行の画面に示される。さらに、このカーラジオが内蔵型ナビゲーションシステムを有する。このナビゲーションシステムは、リクエストされると、ＷＥＢ．ｄｅなどのサーバから現在の交通渋滞情報を引き出し得、必要な場合には、運転者が、発生中の交通渋滞を迂回して運転し得るように、この情報を計算されたルートに直接含み得る。

公知の方法では、以下が問題となる。（端末、例えば携帯電話またはカーラジオなどの）クライアントとサーバとの間のコミュニケーションに関し、無線アプリケーションプロトコル（ＷＡＰ）が提供するもので行い得ることは限られている。ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介して、クライアントはＨＴＴＰ−ＧＥＴコマンドを使用してサーバにリクエストを置き得、その結果、パラメータがサーバに送られる。

現在の方法では、ＵＲＬの呼び出しを介し、添付されるパラメータを用いて、クライアント（ＯｎｌｉｎｅＰｒｏ）からサーバ（ＷＡＰサーバ）へリクエストが行われる。添付されるパラメータは、キーボード、セパレータおよび、例えば以下の種類の値からなる。

例１：
．．．／ｔｅｓｔａｐｐｌ．ｃｇｉ？ｎａｖｄｅｓｔ＝［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［２］ＨＩＬＤＥＳＨＥＩＭ，，［３］ＤＡＩＭＬＥＲＲＩＮＧ
例２：
．．．／ｔｅｓｔａｐｐｌ２．ｐｈｐ？ｐａｒａｍ１＝ｓｏｍｅｖａｌｕｅ＆ｐａｒａｍ２＝ａｎｏｔｈｅｒｖａｌｕｅ．．．
リクエストが機能する方法は、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）方法に従って記載される。

サーバは、理解し得る形式でその答えをクライアントに送らねばならない。答えのデータは、接続を確立している間にクライアントが通知を行ったＭｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ （ＭＩＭＥ−ＴＹＰＥ）の方法で符号化される。このリクエストから、ＷＡＰサーバが特定のＭＩＭＥ形式（例えば、，’ｘ−ｂｅｃｋｅｒ／ｖｎｄ．ｗａｐ．ｂｉｍ’）を有するパケットを生成する。このパケットは平文のデータを含む。そのパケットのサイズは限定される。

しかし、公知の方法は、それ自体ではクライアントからサーバへ２５６バイト以上の送信を確実に行う可能性を何も提供せず、サーバからクライアントへの返事のサイズもまた限られている（正確なサイズはその実行に応じる）。

本明細書で説明する本発明はここからスタートする。

本発明の目的は、データ通信においてそのような限定を持たないブラウザ性能を有するコミュニケーションシステムを提供することである。

この目的は、請求項１の特徴を有するコミュニケーションシステムの手段によって解決される。

それをさらに発展させたものが従属請求項の内容である。

本発明によると、ブラウザはインターネット上を次々と移動するプログラムと考えられる。ブラウザが、インターネットから情報を取り出し表示する役割を行う。ブラウザは、テキスト、絵およびプログラムを含み得る、受け取ったＨＴＭＬページを図形的に表示する。さらに、例えば音声およびビデオファイルをある特定のプログラムによって表示し得るように、ユーザが、ＷＷＷブラウザを調節し得る。公知のブラウザのいくつかの例は、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ，Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ，ＮＳＣＡ Ｍｏｓａｉｃ， ＬＹＮＸである。ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）ページの表示に加え、ＷＷＷブラウザは
・電子メールを読むことおよび書くこと
・ファイルの（サーバからローカルコンピュータへの）送信
・ニュースを読むことおよび書くこと
などのサービスを提供する。
本明細書で説明する、本発明の枠組みにおいて、ＵＲＬは「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」の公知の略語である。ＵＲＬの助けを借りて、インターネット上の全ての情報が世界中で明確にアドレス指定される。例えば、ｈｔｔｐ：／／ｗｗｗ．ｂｅｃｋｅｒ．ｄｅというＵＲＬは、使用される伝送プロトコル、ｈｔｔｐ：（は、ＨＴＭＬドキュメントを送ることに責任を負う）、サブレベルドメインのｗｗｗ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ），ドメインのＢｅｃｋｅｒ、トップレベルドメインのｄｅ（ドイツ―Ｄｅｕｔｓｃｈｌａｎｄを表す）および対応するページ（またはファイル）のリンクのパスからなる。この個々のアドレスのコンポーネントの階層的な順番は、正しいアドレスに到達するために必要である。特にＨＴＭＬページのＵＲＬはリンクとしての役割をし、その上で、ユーザがマウスクリック１つでウェブサイトからウェブサイトへ移動し得る。

ブラウザ性能を有するコミュニケーションシステムは、ブラウザの助けを借りてコミュニケーションデータをユーザ間に送るコミュニケーションシステムであると理解される。

コミュニケーションシステムの必須要素は、データ伝送プロトコルであり、それを用いてクライアントとサーバとの間のコミュニケーションが確立される。本発明による方法では、クライアント（ＯｎｌｉｎｅＰｒｏ）からサーバへのリクエストが従来と同じ手法で、パラメータを用いてＵＲＬなどのリソースロケータを呼び出すことによって行われる。しかし、新しい方法は、ただ１つのパラメータを送信し、それが送信のために符号化されたバイナリパケットを含む。

必要なら、そのプロトコルが、起こり得るパケットのフラグメンテーション／フラグメンテーションの解消に備える。そのプロトコルが、異なるサービスが１つのデータ形式で処理されることを可能にし、例えば応答パケットが常に同じＭＩＭＥ形式を有し得る。

このソルーションによって、公知のシステムに比べて以下の利点が達成される。

−より大きいデータパケットがいくつかのステップで自動的に送られる。

−サーバが、クライアントからのデータをリクエストすることが可能である。これは通常では全く不可能である。

−必要とされるＭＩＭＥ形式がただ１つなので（ｈｔｔｐサーバの再コンフィギュレーションがないので）、本方法を用いて実行される新しいサービスが、以前よりもかなり迅速に、動作され得る。

−内部タスク識別コードの評価が、プロトコルを将来的にも保証されるものとする。

本発明によると、サーバが、再び、公知の方法と同じ方法で、クライアントからのリクエストに対して反応する。しかし上で説明したように、またも、パケット内容はもはや平文には含まれないが、本発明のアプリケーションによって書類内に含まれるように、バイナリに含まれる。

このことが、今度は、古い方法に比べて以下の利点を有する。

−伝送されるデータ量がより小さい（個々の値をビットシーケンスに要約する）
−内容がもはや全ての人に明らかなわけではない。

−端末ソフトウェアにとって、より簡単でより迅速に読み得る。

−ハンドシェークプロセスの実現（１以上のサブパケットの伝送）
−（ＵＲＬなどの）リプライリソースロケータを伝送することによるサーバリクエストの実現およびハンドシェークの実現
以下で、総合ナビゲーションシステム及びＧＰＳモジュールを有するカーラジオ（以下でクライアントと呼ぶ）を使用する具体的な実施形態が説明される。この実施形態では、リソースローケータが、上で説明したように、公知のＵＲＬの呼び出しであり、公知のＷＡＰ（「Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」）が伝送形式として使用されると想定される。しかし、本発明はこのＵＲＬ及びＷＡＰに制限されない。

後者のＷＡＰプロトコルを使用して、ＷＡＰサーバを用いるコミュニケーションが可能である。データインターフェースを含む必要なＷＡＰブラウザが、カーラジオで実行されていると想定される。このカーラジオは、非常に異なるパラメータがサーバに伝送され得、その後、それが各ユーザに対する特定の内容を生成し得る、というように形成される。

古典的なＷＡＰアーキテクチャのように、１つの側にクライアントがあり、他方側にサーバがある。決まりとして、このクライアントが開始者であり、クライアントが接続を確立しデータをリクエストする。このサーバはリクエストされるデータのみを供給し、リクエストを開始することはできない。

このサーバは、端末がＷＡＰブラウザの助けを借りて特定のデータを取り出す手配をするために、ＳＭＳプッシュのみを使用し得る。データ接続は内蔵ＧＳＭモデムおよび選択されるアクセスプロファイルを介して生成される。接続が確立された後、要求されるインターネットポータルが呼び出され、全ての可能なサービスがＷＭＬ（Ｗｉｒｅｌｅｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページとして表示される。このポータルコールは、デバイス番号、パスワード、乗り物識別番号およびＵＲＬパラメータのような地理的座標などのパラメータの非常に広い範囲を進む。

このサーバが、今度は、各ユーザのために動的に生成される情報を有するＷＡＰページを組み立てる。その後、従来の意味においてＷＡＰの入力を通してナビゲーションを行うのと同様に、これらの内容を通してナビゲーションを行うことが可能である。

例えば、ユーザがホテル検索を選択した場合、ログイン時に通過した位置に応じて、考え得る地域がサーバ側で計算され、可能なホテルがデータベースから選択される。これらの結果が、ＷＭＬページの形式で端末に送り返される。

ユーザが所望のホテルを選択し、その後、リンクを含む、ホテルに関する詳細なデータを（再びＷＭＬページとして）受け取る。このリンクが、そのナビゲーションシステムのための目的地記述を含むデータパケットを表に出さない。この接続はナビゲーションデータが送られた後、終了する。

１． データパケットの形式
クライアントとサーバの間で交換されるデータパケットの形式が以下のように提示される。

ＭＩＭＥ形式に加え、サーバからクライアントへ送られるデータパケット（サービスパケット）およびクライアントからサーバへ送られるデータパケット（リクエストパケット）の形式の表記がある。

１．１ Ｃｏｎｔｅｎｔ／ＭＩＭＥタイプ形式
このために選択されるＣｏｎｔｅｎｔ形式またはＭＩＭＥ形式は、例えばｘ−ｂｅｃｋｅｒ／ｖｎｄ．ｗａｐ．ｌｂｓ．と呼ばれる。

ＭＩＭＥ形式はＩＡＮＡの要求を満たすために「ｘ−」で始めなければならない（ｗｗｗ．ｗ３ｃ．ｏｒｇ−ＲＦＣ１７００を参照のこと）。サーバからクライアントに送られるデータのためのこの形式は、将来的にも保証（ｆｕｔｕｒｅ−ｐｒｏｏｆ）されている。それは、異なるサービスが、このＭＩＭＥ形式を有する単に別々のＳｅｒｖｉｃｅ ＩＤによって処理され得るからである。

含まれるＳｅｒｖｉｃｅ ＩＤに従って、このＭＩＭＥ形式を有するデータパケットのみが、クライアントによって復号化される。

１．２ サービスパケット（サーバ）
サービスパケットはリクエストが行われたとき、サーバポータルからクライアントに送られる。Ｓｅｒｖｉｃｅ ＩＤコード，デバイス番号およびＣＲＣ３２チェックに加え、サービスパケットは有用なデータを含む。有用なデータの長さは選択されるサービスに応じる。したがって、この形式は比較的フレキシブルである。

１．２．１ データパケットの形式
これらのパケットの記述は、ＭＰＥＧ２のシンタックス規格および比較的理解しやすい疑似プログラム言語に従う。このプロトコルのセットアップは、例えば以下のように選択されている。

ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ（）
｛
ｓｅｒｖｉｃｅ＿ｉｄ ８ ｂｉｔｓ ／／サービス識別コード
ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／シリアルナンバーの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｖｉｃｅ＿ｉｄ［ｎ１］ ８ ｂｉｔｓ ／／シリアルナンバー
｝
ｒｅｓｅｒｖｅｄ ３２ ｂｉｔｓ ／／将来の使用のため
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ ４ ｂｉｔｓ ／／パケットの数
ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ ４ ｂｉｔｓ ／／このパケットの番号
ｆｏｒ（ｎ１＝０；ｎ１＜ｓｅｓｓｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｓｅｓｓｉｏｎ＿ｉｄ［ｎ１］ ８ ｂｉｔｓ ／／セッションＩＤ
｝
ｓｗｉｔｃｈ（ｓｅｒｖｉｃｅ＿ｉｄ）
｛
ｃａｓｅ ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｎａｖｄｅｓｔｉｎａｔｉｏｎｓ（）
ｂｒｅａｋ
ｃａｓｅ ＳＥＲＶＩＣＥ＿ＳＥＲＶＥＲＲＥＱＵＥＳＴ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｓｅｒｖｅｒｒｅｑｕｅｓｔ（）
ｂｒｅａｋ
ｃａｓｅ ＳＥＲＶＩＣＥ＿ＴＴＳ：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｔｔｓ（）
ｂｒｅａｋ
ｃａｓｅ ＳＥＲＣＩＣＥ＿．．．：
ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ．．．（）
ｂｒｅａｋ
｝
ＣＲＣ＿３２ ３２ ｂｉｔｓ ／／自動エラーコレクション
｝
この場合、ｓｅｒｖｉｃｅ＿ｉｄはそれぞれのサービスの識別コードである。この８ビットのＩＤを使用して、パケットの中に含まれる残りのデータが復号化される。可能なＳｅｒｖｉｃｅ ＩＤは以下であり得る。

ｄｅｖｉｃｅ＿ｉｄはデバイス番号を含む。それはソースコードのいくつかの部分ではユーザネームと呼ばれる。

２つの４ビット値のｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒおよびｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、次々といくつのこの形式のパケットが送られているのか、および現在のパケットのパケット番号は何番なのかを記述する。これは、データ量が通常の量を超える将来のバージョンにとって絶対的に有用である。１つの実施形態では、これらの２つの値が常に１に設定され得る。

１つ以上のセクションを送るために、ｓｅｓｓｉｏｎ＿ｉｄが必要とされ、それが各データ交換の伝送に含まれる。それは可変の長さを有し、サーバが呼び出されたときに初めてサーバによって生成／規定される。ＴＤＳのために必要とされるようなハンドシェイクプロセスは、例えば、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ，ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒおよびｓｅｓｓｉｏｎ＿ｉｄの組み合わせを使用して実現され得る。

最後の値のＣＲＣ３２を除き、ｓｅｒｖｉｃｅ＿ｉｄに応じてさらなる復号化が行われる。いわゆる有用データの符号化は以下の適切なセクションで取り扱われる。

１．２．２ Ｓｅｒｖｉｃｅ．ＩＤ ＳＥＲＶＩＣＥ ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ
ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ ＩＤに接続して、近隣で見つけられる目的地の検索のためのサービスが、本明細書に説明される全てのサービスの最初のものであった。このサービスを用いて、（レストラン、ホテル、鉄道の駅、博物館などの）特別の目的地のナビゲーションデータのリクエストが可能である。この入手し得る目的地情報は「通常の」ＣＤナビゲーションデータには含まれない。

この追加のサービスにより、カーラジオが電話帳の職業別企業案内の形をとることができる。この方法でリクエストされるナビゲーションデータの料金は、一方ではリクエスト者に請求され得るが、他方、（例えばレストランのオーナーなど）その目的地の所有者に請求され得る。

データパケットの形式は、例えば以下のようである。

ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｎａｖｄｅｓｔｉｎａｔｉｏｎｓ（）
｛
ｓｔａｒｔ＿ｍｏｄｅ ２ ｂｉｔｓ ／／ナビゲーションのため
ｓａｖｅ＿ｍｏｄｅ １ ｂｉｔｓ ／／イエスまたはノーを保存する
ｒｅｓｅｒｖｅｄ ５ ｂｉｔｓ ／／将来の使用のため
ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ ８ ｂｉｔｓ ／／パケットの中の目的地の数
ｆｏｒ（ｉ＝０；ｉ＜ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ；ｉ＋＋）
｛
ｄｅｓｔ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／文字列の文字の数
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｓｔ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｓｔｉｎａｔｉｏｎ［ｎ１］ ／／目的地の文字
｝
ｕｒｌ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／文字列の文字の数
ｆｏｒ（ｎ１＝０；ｎ１＜ｕｒｌ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｕｒｌ［ｎ１］ ／／目的地情報を有するＵＲＬ
｝
｝１つのナビゲーション目的地に対して１つのＵＲＬ、などの追加のデータが、定義に応じてデータパケットに添付され得る。

ヘッダデータが復号化された際にＳｅｒｖｉｃｅ ＩＤ ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳが見つけられると、ここに記録されたシンタックスにしたがって、有用データが復号化される。

ｓｔａｒｔ＿ｍｏｄｅ（２ビット値）およびｓａｖｅ＿ｍｏｄｅ（１ビット値）の２つの値がナビゲーションそのものに必要とされる。スタートモードはナビゲーションをすぐに開始するのか、または、送られてきた目的地が、後に使用するための可能な目的地として、先ずメモリに置かれるべきかを確立するために使用される。ここで可能な値は以下の表に記載される。

表：ナビゲーションのための、可能なスタートモード
次に、ｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔの値、つまりこのパケットの目的地の数がこのブロックにくる。次に、正確にｎｕｍｂｅｒ＿ｏｆ＿ｄｅｓｔ回、回るループがくる。ここが個々の目的地が読み出される場所である。

１．２．２．１ 目的地文字列
目的地文字列は送られている目的地を示す。この文字列は、いわゆるｓｅｌｅｃｔｉｏｎ ｃｒｉｔｅｒｉａのタグで作られ、その後、各記述が続く。このｓｅｌｅｃｔｉｏｎ ｃｒｉｔｅｒｉａは四角の括弧で括られ、数字（十進法数）を含む。

文字列自体は例えば次のようである。
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［２］ＨＡＭＢＵＲＧ，，［３］ＷＥＮＤＥＮＳＴＲＡＳＳＥ，，［２５６］Ｉｎｎｏｖａｔｉｖｅ Ｓｙｓｔｅｍｓ
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［１２４］０ ０
［１］ＤＥＵＴＳＣＨＬＡＮＤ，，［１２４］０−７３４５０，，［２５６］ＭｃＤｏｎａｌｄｓ Ｅｃｕａｄｏｒ
同様に、ＷＧＳ８４形式で目的地を特定することも可能である。ＷＧＳ−８４座標は、目的地ガイドについて５０メートルの誤差（各方向において、Ｎａｖ−Ｔｅｃｈデータで１０メートル＋ＧＰＳデータの誤差２０メートル）を有する。

１．２．３ Ｓｅｒｖｉｃ−ＩＤ ＳＥＲＶＩＣＥ ＳＥＲＶＥＲＲＥＱＵＥＳＴ
このサービスによって、サーバが、リクエストを行っているデバイスの現在地のクエリを行うことが可能である。この情報はＬｏｃａｔｉｏｎ Ｂａｓｅｄ Ｓｅｒｖｉｃｅにとって必須のものである。

現時点の地理的データは、ログインの間にすでにカーラジオに渡され得る。しかし、現時点の地理的データは、好ましくはクライアントのリクエストパケットを介してサーバに提供される。

サーバが、また別の時に位置データを所望すると、それは、このサーバリクエストを介してリクエストされ得る。この機能は、例えば、（輸送車等の）隊の管理、緊急呼び出し指令の発令、引き上げ指令実行などにとって重要である。

ｓｅｒｖｉｃｅ＿ｐａｃｋｅｔ＿ｓｅｒｖｅｒｒｅｑｕｅｓｔ（）
｛
ｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌ ８ ｂｉｔｓ ／／ＵＲＬの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌ；ｎ１＋＋）
｛
ｒｅｓｐｏｎｓｅ＿ｕｒｌ［ｎ１］ ／／返答のためのＵＲＬ
｝
｝
クライアントは、サーバによるリクエストへの回答のために、返答を返すべきＵＲＬを必要とする。まず、ＵＲＬの長さｌｅｎｇｔｈ＿ｏｆ＿ｕｒｌが８ビット値として特定され、その後、実際の文字列がくる。

１．３ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（クライアント）
サーバの返答と同様の方法で、よりバイナリ志向型の形式は、クライアントによるデータのリクエストのために、切り替えられる。データパケットの形式が以下でさらに詳細に説明される。

サービスパケットと対照的に、ブラウザの制約のために、ここではバイナリパケットは簡単に送信され得ない（プッシュトランスミッション）が、代わりにＵＲＬへのリクエストに添付されなければならない。これは、データがＵＲＬに特有の表記法に変換されることを要求する。ここでは、ＵＲＬの長さが２５６文字を超えないことが遵守されなければならない。そうしなければ送信ルートのより古いゲートウェイがデータを削除し得るからである。

パケット内の、あちこちに行き交うＳｅｓｓｉｏｎ ＩＤを送信することによって、現在行われているセッションがこのＵＲＬコールによって終了される必要がない。例えば、（通信）申込者は、自分のオンラインポータルで、例えば、最初にユーザネームおよびパスワードでログインする。このときから、申込者は符号化された形式でデータが送信されるセッションに入る。申込者が、クライアントが作り出した自己生成されたＵＲＬを有するリンクを呼びだす試みを明確に行うと、サーバが、それがＳｅｓｓｉｏｎ ＩＤに基く同じセッションであると認識しない限り、申込者は新しいセッションを始める。

１．３．１ データパケットの形式
データパケットの形式は前回存在した形式に従う。Ｓｅｓｓｉｏｎ ＩＤは、別個のパラメータとしてＵＲＬに添付されるか、またはここのパケットの中に一体化されるかどちらでも可能である。前者の場合、Ｓｅｓｓｉｏｎ ＩＤの長さは０に設定される。この場合の１例としては以下のようであり得る。

ｒｅｑｕｅｓｔ＿ｐａｃｋｅｔ
｛
ｔａｓｋ＿ｎａｍｅ ２４ ｂｉｔｓ ／／タスク識別（旧）
ｓｅｒｖｉｃｅ＿ｉｄ ８ ｂｉｔｓ ／／サービスの識別
ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／シリアルナンバーの長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｄｅｖｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｄｅｖｉｃｅ＿ｉｄ［ｎ１］ ８ ｂｉｔｓ ／／シリアルナンバー
｝
ｆｉｎ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／乗り物識別番号の長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｆｉｎ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｆｉｎ［ｎ１］ ８ ｂｉｔｓ ／／乗り物識別番号
｝
ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／バージョン識別の長さ
ｆｏｒ（ｎ１＝０；ｎ１＜ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ＿ｌｅｎｇｔｈ；ｎ１＋＋）
｛
ｓｏｆｔｗａｒｅ＿ｖｅｒｓｉｏｎ ［ｎ１］８ ｂｉｔｓ ／／バージョン識別
｝
ｌａｎｇｕａｇｅ＿ｉｄ ８ ｂｉｔｓ ／／クライアントの言語選択
ｒｅｓｅｒｖｅｄ ３２ ｂｉｔｓ ／／将来の使用のため
ｐａｓｓｗｏｒｄ＿ｌｅｎｇｔｈ ８ ｂｉｔｓ ／／パスワードの長さ
ｆｏｒ（ｎ２＝０；ｎ２＜ｐａｓｓｗｏｒｄ＿］ｌｅｎｇｔｈ；ｎ２＋＋）
｛
ｐａｓｓｗｏｒｄ［ｎ２］ ８ｂｉｔｓ ／／パスワード内の文字
｝
ｆｏｒ（ｎ３＝０；ｎ３＜ｓｅｓｓｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈ；３ｎ＋＋）
｛
ｓｅｓｓｉｏｎ＿ｉｄ［ｎ３］ ８ ｂｉｔｓ ／／セッションＩＤ内の文字
｝
ｌｏｎｇｉｔｕｄｅ ３２ ｂｉｔｓ ／／経度
ｌａｔｉｔｕｄｅ ３２ｂｉｔｓ ／／緯度
ｉｆ（ｓｅｒｖｉｃｅ＿ｉｄ＝＝ＳＥＲＶＩＣＥ＿ＮＡＶＤＥＳＴＩＮＡＴＩＯＮＳ）
｛ ／／何の追加データも
｝ ／／ここにリクエストされない
ｅｌｓｅ ｉｆ（ｓｅｒｖｉｃｅ＿ｉｄ＝＝ＳＥＲＶＩＣＥ＿．．．） ／／これは異なって見られ得る
｛ ／／他のリクエストのため
．．．．
｝
ＣＲＣ＿３２ ３２ ｂｉｔｓ ／／エラー訂正
｝
旧から新への送信をより容易にするために、ｔａｓｋ＿ｎａｍｅタグはこの形式にまだ含まれる。

実際のリクエストはｓｅｒｖｉｃｅ＿ｉｄタグの中にある。ここで、受信者が使用を望むＳｅｒｖｉｃｅ ＩＤが特定されるか、またはその結果、要求されるかが行われる。

個々のリクエストのために、追加のデータが必要とされる場合、このパケットの、より下の部分で実行される。

ｄｅｖｉｃｅ＿ｉｄはクライアントのデバイス番号であり，サーバの返答の中にあるものと同じである。それは１４文字からなる。

それに続く６つの値が乗り物の現時点の位置をＸＹ座標で記述する。

Claims (18)

1. 互いに通信を行うクライアントおよびサーバを有するコミュニケーションシステムがブラウザ性能を有するコミュニケーションシステムであって、該クライアントが、パラメータが添付されるリクエストによって該サーバを呼び出し、該サーバが、リクエストされたデータパケットを送ることによって該クライアントに返答し、該クライアントが行う該リクエストに添付される該パラメータが、送信のために符号化されるバイナリデータパケット（リクエストパケット）を含むことを特徴とする、ブラウザ機能を有するコミュニケーションシステム。
2. Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＷＡＰ）に従うブラウザ性能を有する、請求項１に記載のブラウザ性能を有するコミュニケーションシステム。
3. 前記リクエストがＵｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）を含む、請求項１または２に記載のブラウザ性能を有するコミュニケーションシステム。
4. 前記リクエストが、前記添付されるパラメータを有し、該リクエストが最大２５６文字の長さであることを特徴とする、請求項１から３のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
5. 前記リクエストに添付される前記パラメータの中で識別コード（ｓｅｓｓｉｏｎ＿ｉｄ）が送信されることによって、前記サーバを用いてハンドシェークプロシージャが可能であることを特徴とする、請求項１から４のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
6. リクエストされると、前記サーバが、データパケット（Ｓｅｒｖｉｃｅ ｐａｃｋｅｔｓ）を前記クライアントに送信し、該提供されるサービスの識別のためにサービスＩＤコード（Ｓｅｒｖｉｃｅ＿ＩＤ）を送信することに加え、デバイス番号（Ｄｅｖｉｃｅ＿ｉｄ）およびエラー検出コード（ＣＲＣ＿３２）を送信し、続いてバイナリ志向の有用データを送信することを特徴とする、請求項１から５のいずれかまたは請求項１の前部分に記載のブラウザ性能を有するコミュニケーションシステム。
7. 前記ユーザデータがバイナリコード化されることを特徴とする、請求項６に記載のブラウザ性能を有するコミュニケーションシステム。
8. 前記ユーザデータの長さが可変であることを特徴とする、請求項４または５に記載のブラウザ性能を有するコミュニケーションシステム。
9. 前記サーバから前記クライアント（Ｓｅｒｖｉｃｅ ｐａｃｋｅｔｓ）に送られる前記データパケットが非常に多くの連続するビットを有し、該ビットが、
   前記サービス識別コード（Ｓｅｒｖｉｃｅ ＩＤ）、
   該シリアルナンバーの長さ、
   シリアルナンバー、将来の用途のためのさらなる保存エリア、
   パケットの数（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
   たった今送られたパッケージ番号（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）、
   セクション番号
   のように次々と配列されることを特徴とする、請求項６から８のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
10. 前記サービス識別（ｓｅｒｖｉｃｅ＿ｉｄ）がある特定のビット幅を有し、該サービス識別が、前記データパケット（ｓｅｒｖｉｃｅ ｐａｃｋｅｔｓ）の中に含まれる前記データの残りの復号化を可能にすることを特徴とする、請求項６から９のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
11. 前記セクション番号（ｓｅｃｔｉｏｎ＿ｉｄ）が可変長を有し、該セクション番号が最初の呼び出しで前記サーバによって生成され規定されることを特徴とする、請求項６から１０のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
12. 前記提供されるサービスのうちの１つが、近隣に位置する前記クライアントの目的地の検索のために意図されることを特徴とする、請求項１から１１のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
13. 前記提供されるサービスのうちの１つが、前記クライアントの現時点の位置のクエリを行う役割を果たすことを特徴とする、請求項１から１２のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
14. 前記サーバが、リクエストされると、ＭＩＭＥ形式のデータパケットを前記クライアントに送ることを特徴とする、請求項１から１３のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
15. 前記クライアントが、乗り物のコミュニケーションシステム内で、端末または端末の部分として形成されることを特徴とする、請求項１から１４のいずれかに記載のブラウザ性能を有するコミュニケーションシステム。
16. 前記クライアントがカーラジオ／ナビゲーションシステムの中に内蔵されることを特徴とする、請求項１５に記載のブラウザ性能を有するコミュニケーションシステム。
17. 請求項１から１６のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、移動コミュニケーションシステムの端末。
18. 請求項１から１４のいずれかに記載の前記ブラウザ性能を有するコミュニケーションシステムに一体化される、請求項１から１７のいずれかに記載のサーバ。