JP4109258B2 - Ｈｔｔｐに基づく通信システムにおけるエラーメッセージングの方法 - Google Patents

Description

本発明は通信ネットワークにおけるメッセージハンドリングに関し、特に、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）に基づく通信のためのエラーメッセージングに関する。

今日、ほとんどすべてのウェブサーバ、クライアント、及び関連するウェブアプリケーションは、ＨＴＴＰを介して相互に通信する。通信は、クライアント及びサーバ間のＨＴＴＰリクエスト及びレスポンスに基づき、ＨＴＴＰは通信のためのリクエスト−レスポンスプロトコルを規定する。クライアントがＨＴＴＰリクエストを送信するたびに、ウェブサーバはＭＩＭＥ(Multipurpose Internet Mail Extensions)ヘッダを返す。レスポンスの最初の行は、次の通りである。

＜バージョン＞ ＜ステータスコード＞ ＜リーズンフレーズ＞

バージョンパートは、そのメッセージに使用されるＨＴＴＰのバージョンを示す。ステータスコードは、３桁のコードナンバーであり、リクエストの間に何が発生したかを大雑把に示す。ステータスコードは一般クラスにグループ化され、それは最初の桁によって示される。例えば、２ＸＸ形式のコードは「成功」を意味し、４ＸＸ及び５ＸＸコードはそれぞれ「クライアントエラー」及び「サーバエラー」を示す。最後に、リーズンフレーズはそのコードナンバーに関する人間が読める説明であり、その特徴は以下に示される。成功したＧＥＴ要求に対する標準的なＨＴＴＰレスポンスは、次の通りである。

ＨＴＴＰ／１．０ ２００ ＯＫ

上の行には一般的に、例えばコンテンツタイプやレングス(length)のような他のヘッダ情報が続き、次いで、要求されたドキュメントが続く。

一般に使用される、従来技術における通信ネットワークは、プロキシサーバ（一般的に、「プロキシ」と呼ばれる）を介してクライアント端末と通信するウェブサーバを備える。プロキシは、ＨＴＴＰメッセージを、サーバとクライアントの間を往復してやりとりさせる。より詳細には、プロキシはＨＴＴＰ又は無線セッションプロトコル（ＷＳＰ）に基づく各々のリクエストを、無線クライアントからウェブサーバに送信し、それに続く各々のＨＴＴＰレスポンスを、ウェブサーバからクライアントに送信する。レスポンスの最初の行が改変されることなくプロキシを通過すると、エンドユーザは、ウェブサーバから送信されたレスポンスに直接対応するレスポンスメッセージを受信する。

ここで、サーバがエラーに直面し、ＨＴＴＰレスポンスの中でそれを報告することを想定する。そのような場合、（ＨＥＡＤリクエストを除く）ＨＴＴＰプロトコルは、サーバはレスポンスの中で「エラー状況の説明を含むエンティティを備えなければならない」と規定する（非特許文献１参照）。さらに、ユーザエージェントは「備えられるすべてのエンティティをユーザに提示しなければならない」と規定する。これは、説明エンティティ、すなわち、レスポンスメッセージに組み込まれたリーズンフレーズが存在するかもしれない（又は存在しないかもしれない）ということを意味する。さらに、リーズンフレーズが存在するときであっても、それがエンドユーザに提示されるかどうかは定かではない。エラーコードのみが提示される場合もある。要求されたサービスのプロバイダ、例えば移動体通信運用者は、特定のエラー状況において、場合によっては何が発生するかを知ることができない。

さらに、リーズンフレーズが示されたとしても、それが実際のエラー状況をひどく不適切に示していたり、間違って示していたりする可能性もある。ＨＴＴＰの仕様は、リーズンフレーズのための厳密なテキストに関するいかなる方針も規定しておらず、それゆえ、それは任意のものとなる。その結果、エンドユーザはサービスプロバイダに対する誤った印象を抱く可能性があり、それは非常に深刻な問題である。なぜなら、それはユーザの視点におけるサービスの価値を低下させるからである。

それゆえ、ＨＴＴＰエラーメッセージの従来のハンドリングは、到底満足のゆくものではなく、改良されたエラーメッセージングの方法に対する少なからぬ要求がある。
R. Fielding et. al, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999

本発明の全体的な目的は、ＨＴＴＰ通信システムにおける改良されたエラーハンドリングを提供することである。より詳細な目的は、中間装置を介するクライアント−サーバ通信のための、信頼でき有益なエラーメッセージを実現することである。

これらの目的は、添付の請求の範囲に従って達成される。

簡単に言えば、本発明の方法は、サーバから送信されるエラーメッセージのコントロールを達成するために、無線クライアント端末とウェブサーバを相互接続する中間装置を活用する。サーバから送信されるエラーステータスコードは、拡張エラー記述テキストと併せて新たなステータスコードを含む、有用なエラー記述メッセージに変換される。新たなステータスコードは、望ましくは、それがエラー記述テキストの表示を実行するように選択される。このようにして、失敗したリクエストに応じてエンドユーザがどのメッセージを受信するかをコントロールすることが可能となり、また、そのメッセージがクライアント端末に実際に表示されることを保証する。本発明は、ＨＴＴＰに基づく通信に適用可能であり、望ましくは、エラー記述メッセージの従属する情報資源の場所を提供するエラー情報テーブルを介してプロキシサーバによって実現される。

本発明の他の側面から見ると、エラーメッセージング手段を備えるプロキシサーバが提供される。マルチメディアメッセージングサービス（ＭＭＳ）通信のためのエラーメッセージング手段もまた、提供される。

本発明は、その更なる目的と利点と併せて、添付の図面と併せて後述する説明を参照することにより、最もよく理解できるであろう。

図面全体を通して、同一の参照番号は、類似又は対応する要素に対して使用される。

図１は、無線クライアントとウェブサーバ間の通信のための代表的なネットワークの図式に概観した図である。例えば移動体電話やポケットベル、ラップトップのような多数の無線クライアント端末１０−１、１０−２、１０−３を一方に備え、ウェブサーバ３０を他方に備える通信システムが示されている。そのシステムはさらに、移動体ネットワーク１５とインターネット２５上のサービスとの間でブリッジを形成する中間装置である、プロキシサーバ２０を備える。プロキシ２０はまた、例えば、メッセージフィルタリングの実行、セキュリティソリューションやその他のサービスの提供のうち少なくともいずれかを行ってもよい。実際には、ほとんどの通信システムは、図１の簡単な例と比べてより複雑なネットワークに設けられる複数のプロキシとサーバを備える。

背景技術の項目で概説したように、エンドユーザが中間装置を介してクライアント−サーバ通信において受信するエラー情報は、概して不適切である。その状況が図２に示されており、それは、従来のエラーメッセージングの概略ブロック図である。無線クライアント端末１０は、プロキシサーバ２０を介して、ウェブサーバ３０に接続されている。無線クライアント１０は、ＧＥＴリクエストをプロキシ２０に送信し、それはそのメッセージをウェブサーバ３０に転送する。図に示すように、クライアント１０とプロキシ２０は、ＷＳＰ又はＨＴＴＰプロトコルを介して相互に通信する。ＷＳＰは、この種の通信において現在最も普及している言語である。しかし、プロキシ２０とウェーブサーバ３０の間の通信は、常にＨＴＴＰに基づいている。図２のウェブサーバ３０は、リクエストを処理しているときにエラーに遭遇し、例えば「サーバエラー」を示すステータスコード５００を伴うレスポンスをプロキシ２０に送信する。プロキシ２０は、そのレスポンスの最初の行を改変することなくクライアント端末１０に転送する。そのレスポンスは、背景技術の項目で説明した、より限定的なリーズンフレーズを含むかもしれないし、含まないかもしれない。また、それはクライアント端末１０に表示されるかもしれないし、表示されないかもしれない。

図２から明らかなことは、エンドユーザはエラー情報に関して、ウェブサーバが見て欲しいと望むものを見る。このことは、図３のような状況で特に問題となる。ここでは、外部ウェブサーバが設けられている。ウェブサーバ３０は移動体通信運用者のコントロール範囲４０の外、例えばインターネットに位置する。この例ではエラーステータスコード４００を伴うエラーメッセージは、外部のウェブサーバ３０から送信され、プロキシ２０を通過し、クライアント端末１０に受信される。せいぜいエンドユーザは不十分なリーズンフレーズを見るが、どちらかといえば理解不能なエラーステータスコードが残り、ユーザはおそらく、移動体通信運用者は貧弱なサービスの質を持っているという印象を抱くであろう。移動体通信運用者は、考えられるリーズンフレーズの存在と言葉遣いに影響を与えることはできない。

上述した種類の問題は、例えばＭＭＳのような、移動体通信運用者によって運営されるサービスに関しても発生する。そのような状況が図４に示されている。図４は、ＭＭＳ通信に対する従来のエラーメッセージングの概略ブロック図である。図４の要素は、サーバ３０を除いて図３のそれと直接対応しており、サーバ３０はこの例ではＭＭＳセンター（ＭＭＳＣ）である。例えば、エンドユーザがＭＭＳＣ３０に格納されるＭＭＳメッセージを受信したが、その通知が何らかの理由でエンドユーザに届かなかったと想定する。彼の移動体電話１０は例えば電源が切られているかもしれない。所定の時間の後、ＭＭＳメッセージはＭＭＳＣ３０から消去されるが、移動体電話１０が再び使用可能になると、エンドユーザはまた、ＭＭＳＣ３０にＭＭＳメッセージが存在するという通知を受信する。彼がそれを受け取ろうとすると、エラーメッセージが表示される。このエラーメッセージはエラーステータスコードを伴うＨＴＴＰレスポンスであり、上述の場合と同様に改変されることなくプロキシ２０を通過する。メッセージが消去されたことをエンドユーザに通知する方法はない。このことは必然的に、この場合ＭＭＳである、提供されるサービスに対する悪い認識を抱かせ、結果として、顧客に不満を与える。

本発明は、移動体通信運用者は一般的に上述の状況でプロキシをコントロールするという事実を利用して、上述の問題を取り除く。エラーステータスコードを単にウェブサーバからクライアント端末に通過させる代わりに、本発明のプロキシはステータスコードを、共に最も信頼でき利点のあるエラーメッセージハンドリングにつながる２つの部分を含むエラー記述メッセージに変換する。これは、図５及び図６を参照して詳細に説明される。

図５は、本発明におけるエラーメッセージングシステムの代表的な実施例の概略ブロック図である。従来は、無線クライアント端末１０とウェブサーバ３０の間のリクエスト及びレスポンスメッセージは、例えばプロキシサーバやゲートウェイ（ここでは前者を記載）などの中間装置２０を通過する。無線クライアント端末１０は、移動体電話、ラップトップ、ＰＤＡを含むあらゆる適切な種類の無線装置として実装される本発明に従う通信システムにある。現在最も望ましい本発明の実施例はクライアント−プロキシ通信にＷＳＰを使用するが、無線クライアント端末１０と中間装置２０は共にＷＳＰ又はＨＴＴＰで互いに通信可能である。本発明の中間装置２０は、ＷＳＰプロキシ、無線アプリケーションプロトコル（ＷＡＰ）ゲートウェイ、又はＨＴＴＰプロキシのいずれでもよい。それは例えば、エリクソンから入手可能なＭｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｅｎａｂｌｉｎｇ Ｐｒｏｘｙ １．０が適している。中間装置２０とウェブサーバ３０の間の通信は、ＨＴＴＰプロトコルによって管理される。ウェブサーバ３０はそれゆえ、ＨＴＴＰリクエストを処理し、レスポンスのサービスを行う。また、ＨＴＴＰサーバとも呼ばれる。本発明で使用されるサーバは、広範な機能を実装してもよく、例えばＭＭＳＣでもよい。

再び図５を参照して説明すると、クライアント端末１０は、ＵＲＬによって特定される場所の情報資源を求めて、ＧＥＴリクエストをプロキシ２０に送信する。プロキシ２０は、従来の方法で要求されたウェブサーバ３０にＨＴＴＰメッセージを転送する。エラーが発生すると、サーバ３０は第１のＨＴＴＰエラーステータスコード（図５の例では５００）をプロキシ２０に対して出力する。本発明によれば、プロキシ２０はこの第１のエラーステータスコードを、エラー記述テキスト２４を含むエラー記述メッセージに変換し、そのメッセージの前に第２のステータスコード（図５の例では２００）がクライアント端末１０に送信される。

エラー記述テキスト２４は、エンドユーザにエラーの状況を説明する任意の長さのテキストである。それは望ましくは、無線マークアップ言語（ＷＭＬ）又はハイパーテキストマークアップランゲージ（ＨＴＭＬ）のページとして実現される。エラー記述テキストはそれゆえ、背景技術の項目で述べたように、ＨＴＴＰメッセージの最初の行にエラーステータスコードを伴って時々添えられる任意かつ限定的なリーズンフレーズと区別がつかないということはない。

第２のステータスコードは、エラー記述テキスト２４がクライアント端末１０に表示されることを保証する働きをする。望ましくは、例えば２００コードのような、２ＸＸ形式のＨＴＴＰステータスコードが、本発明の第２のステータスコードを構成する。なぜなら、これらのコードは「成功」を意味し、それゆえ、添付のドキュメントは常に表示されるということを示唆するからである。それゆえ、２００ステータスコードと共に送信されるエラー記述ページは、エンドユーザに提示されることが保証される。

本発明はそれゆえ、エラーを示唆しなければならないのではなく、代わりに、クライアント端末に望まれるエラー記述テキストの表示を実行するための、積極的なレスポンスを構成するステータスコードを使用する。このようにして、移動体通信運用者はエラーメッセージの実際の記述テキストと共に、その表示をコントロールし、あらゆる望まれる説明テキストをエンドユーザに強制的に表示することを達成できる。

エラーメッセージ変換は望ましくはエラー情報テーブル２２による方法で実現される。図６に示されるように、第１のエラーステータスコードと、望ましくはさらにＨＴＴＰリクエストのＵＲＬとが、テーブル２２に入力される。このインプットパラメータ情報に基づいて、第２のステータスコードと、エラー記述テキスト２４を伴うエラーページとが提供される。ＵＲＬがエラー情報テーブル２２に入力されることが望ましいのは、ＵＲＬは、エラー記述メッセージに従属する情報資源の場所が出力されることを可能にするからである。

エラー情報テーブル２２は、望ましくは、プロキシソフトウェアの中に実装される。しかし、プロキシが外部のエラー情報テーブルを呼び出す実施例も、本発明の範囲内にある。

表１は、本発明の望ましい実施例におけるエラー情報テーブルの構造を概説する。これは多数の例示を含み、第１のエラーステータスコード及びサーバのＵＲＬの形式の入力パラメータは、エラー記述メッセージに変換される。エラー記述メッセージは、第２のステータスコード及びエラー記述テキストを伴うエラーページを含む出力パラメータに基づく。各々のエラーページの言語は、望ましくは、テーブル中で規定される。

例えば、移動体通信運用者の管轄外にある特定のウェブサーバＳ１を示すＵＲＬのリクエストを考える。そのようなリクエストは、ステータスコード５００を伴うＨＴＴＰエラーに出くわすと、表１に従って、新たなステータスコード２００を伴う適切なエラー記述テキストＴ１によるＷＭＬページを、プロキシがクライアント端末に送信するという結果になる。「成功」を意味するステータスコード２００は、エラー記述テキストがエンドユーザに提示されることを保証する。

表１は、エラーメッセージに従属する情報資源の場所を提供するために、プロキシがＵＲＬサービスの場所情報を、前述のように望ましく使用することを実現する。ここで、１つ重要な区別が、外部のウェブサーバと、移動体通信運用者の管轄外にあるサーバとの間にある。通信運用者のウェブサーバに関するエラーコードは、拡張されたエラー記述テキストを生成する動機付けを与えるものとは見なされないことがあり、改変されることなく単にプロキシを通過するにすぎない（ステータスコード５０１を伴う例を参照）。さらに、異なる外部のウェブサーバは一般的に異なった扱いを受ける。例えば、サーバＵＲＬ Ｓ１、Ｓ２、Ｓ３の場合、すべてが同じ入力ステータスコード（５００）を持つ。それにもかかわらず、異なるエラー記述テキストＴ１、Ｔ２、Ｔ３が、それぞれのサービスの場所に依存して出力される。これらの、事例特有のエラー記述テキストは明らかに、そうでない場合に可能である以上に個々のエラー状況の詳細な説明を含む。

表１における１つの例は、ウェブサーバが、移動体通信運用者に管理されているＭＭＳＣである場合に関する。これは図７にも示されており、図７は、本発明におけるＭＭＳ通信のための代表的なエラーメッセージングシステムの概略ブロック図である。ここで、エラー記述メッセージは望ましくは、望まれるエラー記述テキストを伴う新たなＭＭＳメッセージ２４を含む。（図４を参照して説明したように）ＭＭＳメッセージが消去された場合は、エラー記述テキストは一般的に、メッセージが消去されたこと及び、望ましくは、そのことの説明を、エンドユーザに通知する。ＭＭＳパッケージ２４はクライアント端末１０のＭＭＳブラウザに送信され、そこで、それはエラー記述テキストを表示可能にするＷＭＬ又はＨＴＭＬページに変換される。

図７においてＭＭＳＣ３０から送信された第１のステータスコード４０４を一例とする。それは、例えば他の４ＸＸコードのような、いかなるＨＴＴＰエラーステータスコードであってもよい。同様に、あらゆる２ＸＸコード又は強制的なドキュメント表示と関連付けられている他のステータスコードが、望ましいＭＭＳ通信システムにおいて、第２のステータスコードに置き換わってよい。

図７において、プロキシ２０からＭＭＳエラーメッセージ２４が生成され、送信される。これは望ましい実施例であるが、図８に示すように、新たなＭＭＳメッセージが代わりにＭＭＳＣによって生成されてもよい。エラー記述テキストは、場合によっては１つ又はいくつかの画像を伴い、ＭＭＳ標準に従って新たなＭＭＳメッセージ２４を構成するようにＭＭＳＣ３０でひとまとめにされる。エラー記述テキストは、ＭＭＳメッセージ２４において、テキスト文書又は画像文書のいずれによっても実現可能である。エラー記述テキストを伴う新たなＭＭＳメッセージ２４は、例えば２００コードのような成功を示すＨＴＴＰステータスコードと共に、ＭＭＳＣ３０から送信される。この場合プロキシ２０はＧＥＴリクエストが成功したと信じるため、それはただ、エラーメッセージをクライアント端末１０に転送するだけである。前述のように、ＭＭＳパッケージ２４はクライアント端末１０のＭＭＳブラウザに送信され、そこで、エラー記述テキストを表示可能にするＷＭＬ又はＨＴＭＬページに変換される。

なお、図示されている例はリクエストメソッドＧＥＴに関するが、本発明は、ＰＯＳＴメソッドを含む他のＨＴＴＰリクエストメソッドにも適用可能である。当業者はまた、ここでのエラーコード番号は例示であり、本発明は他のＨＴＴＰエラーコードにも使用可能であることが分かるであろう。

図９は、本発明におけるエラーメッセージをハンドリングする望ましい方法の代表的な実施例を示すフローチャートである。この処理は、無線クライアント端末からのＨＴＴＰリクエストによって開始する。ステップＳ１で、サーバからのＨＴＴＰエラーステータスコードである第１のステータスコードが、例えばプロキシのような中間装置に受信される。ステップＳ２で、第１のステータスコードは、中間装置によって、第２のステータスコードと併せてエラー記述テキストを含むエラー記述メッセージに変換される。ステップＳ２は望ましくは、第１のステータスコード及びＵＲＬサーバを含む入力パラメータ情報に応じたエラー情報テーブルから、エラー記述メッセージを抽出することを含む。それにより、エラー記述メッセージに従属する情報資源の場所が取得される。ステップＳ３で、中間装置は、エラー記述テキストを伝えるＷＭＬページ、ＨＴＭＬページ、又はＭＭＳメッセージを含むエラー記述メッセージを、クライアント端末に送信する。最後のステップＳ４で、エンドユーザに対するエラー記述テキストの表示が、第２のステータスコードの性質によって実行される。この処理はそれゆえ、あらゆる必要とされるエラー記述テキストの提示を保証することを達成する。

なお、本発明は、具体的な図示された実施例を参照して説明したが、開示されている特徴と同等物及び当業者にとって明らかな修正と変形もその範囲に含む。それゆえ、本発明の範囲は添付の請求の範囲によってのみ限定される。

無線クライアントとウェブサーバ間の通信のための代表的なネットワークの図式に概観した図を示す図である。 中間装置を介するクライアント−サーバ通信における従来のエラーメッセージングを示す概略ブロック図である。 外部ウェブサーバを伴うシステムにおける従来のエラーメッセージングを示す概略ブロック図である。 ＭＭＳ通信における従来のエラーメッセージングを示す概略ブロック図である。 本発明におけるエラーメッセージングシステムの代表的な実施例を示す概略ブロック図である。 本発明の代表的な実施例に従うエラーメッセージの検索を示す図である。 本発明に従うＭＭＳ通信のためのエラーメッセージングシステムの代表的な実施例を示す概略ブロック図である。 本発明に従うＭＭＳ通信のためのエラーメッセージングシステムの他の代表的な実施例を示す概略ブロック図である。 本発明に従うエラーメッセージング方法の代表的な実施例のフローチャートである。

Claims (15)

1. 無線クライアント端末（１０）が中間装置（２０）を介してサーバ（３０）と通信する通信システムのためのエラーメッセージング方法であって、
   前記中間装置（２０）において、エラーステータスコードである第１のハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）ステータスコードを受信する工程と、
   前記中間装置において、前記第１のステータスコードを、エラー記述テキスト（２４）及び、成功を示し、前記エラー記述テキスト（２４）を前記クライアント端末（１０）に強制的に表示することに関連付けられている第２のＨＴＴＰステータスコードを含むエラー記述メッセージに変換する工程と、
   前記エラー記述メッセージを前記クライアント端末（１０）に送信する工程と、
   を備え、
   前記エラー記述テキスト（２４）を前記クライアント端末（１０）に表示することが前記第２のステータスコードに応えて実行されることを特徴とする方法。
2. 前記変換する工程は次に、前記第１のステータスコードを含む入力パラメータ情報に応じたエラー情報テーブル（２２）から、前記エラー記述メッセージを抽出する工程を備えることを特徴とする請求項１に記載の方法。
3. さらに、前記入力パラメータ情報は、前記サーバ（３０）を指示するＵＲＬ部を含み、前記抽出されたエラー記述メッセージは前記ＵＲＬに依存することを特徴とする請求項２に記載の方法。
4. 前記送信する工程は中間装置（２０）によって実行されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記中間装置（２０）は、ＨＴＴＰプロキシ及び無線アプリケーションプロトコル（ＷＡＰ）ゲートウェイの集合から選択されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記サーバ（３０）はマルチメディアメッセージングサービス（ＭＭＳ）センターであることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記エラー記述工程は、第１のＭＭＳメッセージに対するクライアントリクエストによって開始され、前記エラー記述メッセージは第２のＭＭＳメッセージを含むことを特徴とする請求項６に記載の方法。
8. 前記クライアント端末（１０）に表示される前記エラー記述テキストは、無線マークアップ言語（ＷＭＬ）及びハイパーテキストマークアップランゲージ（ＨＴＭＬ）の集合から選択された言語によって記述されていることを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 通信システムにおいて無線クライアント端末（１０）及びサーバ（３０）の間に設置されるプロキシサーバ（２０）であって、エラーメッセージング手段を備え、
   前記エラーメッセージング手段は、
   エラーステータスコードである第１のＨＴＴＰステータスコードを受信する手段と、
   前記第１のステータスコードを、エラー記述テキスト（２４）及び、成功を示し、前記エラー記述テキスト（２４）を前記クライアント端末（１０）に強制的に表示することに関連付けられている第２のＨＴＴＰステータスコードを含むエラー記述メッセージに変換する手段と、
   前記エラー記述メッセージを前記クライアント端末（１０）に送信する手段と、
   を備え、
   前記エラー記述テキスト（２４）を前記クライアント端末（１０）に表示することが前記第２のステータスコードに応えて実行されることを特徴とするプロキシサーバ。
10. 前記変換する手段は次に、前記第１のステータスコードを含む入力パラメータ情報に応じたエラー情報テーブル（２２）から、前記エラー記述メッセージを抽出する手段を備えることを特徴とする請求項９に記載のプロキシサーバ。
11. さらに、前記入力パラメータ情報は、前記サーバ（３０）を指示するＵＲＬ部を含み、前記抽出されたエラー記述メッセージは前記ＵＲＬに依存することを特徴とする請求項１０に記載のプロキシサーバ。
12. ＨＴＴＰプロキシ及びＷＡＰゲートウェイの集合から選択されることを特徴とする請求項９乃至１１のいずれか１項に記載のプロキシサーバ。
13. ＭＭＳセンターと通信することを特徴とする請求項９乃至１２のいずれか１項に記載のプロキシサーバ。
14. 前記エラー記述メッセージはＭＭＳメッセージを含むことを特徴とする請求項１３に記載のプロキシサーバ。
15. 前記クライアント端末（１０）に表示される前記エラー記述テキストは、ＷＭＬ及びＨＴＭＬの集合から選択された言語によって記述されていることを特徴とする請求項９乃至１４のいずれか１項に記載のプロキシサーバ。

Images