JP2006067362A - Ｗａｐゲートウェイ及びｗａｐゲートウェイの制御方法 - Google Patents

Abstract

【課題】インターネットに接続している、電話回路網に属する移動端末等の移動端末からのインターネットへのアクセス要求を中継するＷＡＰゲートウェイにおいて、非稼働サーバーへの無用な要求の転送をなくし、負荷の増大を防ぐ。
【解決手段】ユーザー端末からの要求を、要求を処理する後段サーバーに分配するサーバーに、後段サーバーの稼働／非稼働を示すデータを記憶するテーブルを設け、要求を後段サーバーへ転送する時、当該テーブルを検査し、後段サーバーが稼働中の時のみ要求を転送し、非稼働の時は要求元に処理不能の通知をする。
【選択図】 図３

Description

本発明は、携帯電話やPDA（Personal Digital Assistant）等の移動端末からインターネットへのアクセス要求を処理し、インターネットから移動端末に送信されるサービスを中継するＷＡＰゲートウェイに関するものである。特に、ＷＡＰゲートウェイを構成し、ユーザーからの要求に応答して要求されたサービス等を提供するサーバーの稼働状況を一元的に管理し、メンテナンス等により要求を処理するサーバーが応答不可能となった場合においても、処理の遅延が発生せず、不要な通信の増加を招かないＷＡＰゲートウェイを提供するものである。

移動端末等からインターネットをアクセスし、インターネット上の情報を取得する等インターネットのサービスを受けるため、無線電話回路網とインターネットの間には、両者間の情報あるいは制御を中継するＷＡＰゲートウェイが設けられている。ＷＡＰゲートウェイは無線電話回路網とインターネット間の中継を実行する他、ユーザーにインターネットへのポータルとなるメニューデータを提供する、コンテンツのダウンロード等ユーザーがインターネットから受けたサービスに対して、コンテンツの提供者に代わってユーザーへ課金する、あるいは、ユーザーがダウンロード可能なＪＡＶＡアプリケーション等のデータをシステム内のデータベースとして保管し、ユーザーからのダウンロード要求に応答しダウンロードを許可する等、ユーザーに対して直接サービスを提供する機能を備えたものが存在する。

ＷＡＰゲートウェイに関する文献に以下のものが存在する。
特開２００２−１６５２７６号公報

ＷＡＰゲートウェイは複数の各ノードあるいはサーバーにより構成されており、各ノードあるいはサーバー間で制御あるいはデータを授受することにより携帯端末網とインターネットの間のゲートウェイ機能、あるいは移動端末へのサービスの提供を実行している。システム内には、ユーザーからの要求を対応する後段サーバーに分配するサーバーが存在する。当分配サーバーは、ユーザー端末から送信されて来た要求を解析し、当該要求を処理すべき後段サーバーを決定し、決定されたサーバーにその要求を転送する。従来構成のＷＡＰゲートウェイでは、分配サーバーは後段サーバーの状況を把握する手段を有さず、ユーザーからの要求を処理する後段サーバーが非稼働であっても、当該要求を非稼働の後段サーバーに転送していた。非稼働のサーバーに要求を転送した後の従来の対応が図５に示されている。

図５（ａ）に示される例は、後段サーバーは前段サーバーからのリクエストに応答し得ず、無応答のままとなる。前段サーバーではリクエストを送信した後、所定時間が経過しても後段サーバーからの応答が無いことから、後段サーバーは障害中であると判断し、その処理を打ち切り、ユーザーに処理不能である旨を通知する。この形態では、後段サーバーに無駄なリクエストを出さねばならず、また、処理不能の判別はリクエストを発してから所定時間が経過した後であり、処理の遅延が発生する。

図５（ａ）の形態の改善として、図５（ｂ）の形態が存在する。当形態は、メンテナンス等により処理不能となるサーバーに代わって、要求は処理不能であることをユーザーに通知するＳOＲサーバーが設置されている。メンテナンス時に、サーバーに設置されている転送装置により、当サーバーへのリクエストを上記ＳOＲサーバーに転送する。前段サーバーが非稼働の後段サーバーに発行したリクエストは、後段サーバーに設けられている転送装置によりＳOＲサーバーに転送される。転送を受けたＳOＲサーバーは、処理不能のサーバーに代わって、要求先のサーバーは処理不能である旨の応答を、要求を送信した前段サーバーに返す。この構成により、図５（ａ）の構成のように、所定時間応答が無いことを待つ必要がなく、処理の遅延が少なくなる。しかし、各サーバーに転送装置が必要となり、また、非稼働サーバーへのリクエスト、ＳOＲサーバーへのリクエストの転送、と言う無駄な転送が発生することになる。

本発明は、上記従来技術の課題を解決するため、ユーザーからの要求を解析し、要求を処理すべき後段サーバーへユーザーの要求を分配転送する分配サーバーに、後段サーバーが稼働中か非稼働かを示すデータを記憶する非稼動テーブルを設け、稼働中のサーバーへは要求を転送するが、非稼働とされたサーバーへの要求は転送せず、ユーザーに要求は処理不能である旨の通知を出力する手段を設けるものである。

本発明の構成により、非稼働の後段サーバーへ無用なリクエストを送信する等、不必要な要求の転送が無く、無応答によるタイムオーバー待ちの遅延が発生することのないシステムが実現可能となる。

図１−１は本発明が適用される移動端末によるインターネットへのアクセスを管理するＷＡＰゲートウェイの概要図であり、図１−２には、ユーザーの移動電話機とインターネット上で無料のコンテンツを提供するコンテンツ提供サーバーとの間でセッションを確立し、無料コンテンツを取得した後セッションを開放するWAPの基本シーケンスの一例がしめされている。

図１−１に示される各ノード、サーバーの概要は以下の通りである。
ＧＧＳＮ（２）：ユーザーの移動電話機（ＵＥ）が属するコアネットワーク（パケット網）とＷＡＰゲートウェイを構成するIPネットワークとのゲートウェイである。
ＪＳＲ（３）：加入者認証機構であり、サービス毎にユーザーのアクセス権限をチェックする。
ＰＣＮ（４）：移動電話機が送出するパケットを監視し、そのパケット量を基に課金情報を記述し、所定の期間毎に課金レコード（ＣＤＲ）を出力するサーバーであり、このＣＤＲを基に加入者に対して通信料の課金を行う。
ＪＳＰ（６）：標準機能と拡張機能の調整をするアプリケーションゲートウェイであり、受け付けたリクエストを後段サーバーに適合した形式に変換し、転送するプロキシ機能と、ＳＳＬを用いたセキュアアクセス機能などの各種機能を提供する。
Ｒ２Ｍ（７）：サービス毎のユーザーのアクセス権限をチェックする加入者認証セッションの管理を行う。また、サービス加入者がウェブやメール等のサービスを利用する際に必要となる、ユーザー情報、ユーザー設定情報、端末情報を管理し、ＷＡＰゲートウェイ内の各サーバーからの要求に応じてそれら情報を提供するサーバーである。
ＰＴＬ（８）：各サーバーから各種統計情報を収集し、統計情報に基づいてメニューの項目をソートする等、ＷＡＰゲートウェイの公式メニューの更新管理を行う。移動端末からのリクエストに応答して、メニューデータベースから対応メニューを検索し移動端末に提供するサーバーである。
ＷＧＷ（１０）：移動端末のユーザーがウェブをアクセスする際、ユーザーからのリクエストをコンテンツ提供サーバー（ＣＰ１４）へ仲介するゲートウェイサーバーである。ユーザーのコンテンツ使用料をコンテンツ提供サーバーに代わって徴収する課金システム（回収代行）やスキーム変換などの機能を持つ。
ＤＢＳ（１２）：データベース・シンクロナイザーであり、複数のデータベース間で内容の同期を採るものである。
Ｗｔｒａｎｓ（１３）：ＷＧＷ１０とインターネット上のコンテンツ提供サーバー（ＣＰ）の中間に位置し、コード変換などを行うサーバーである。
ＣＰ（１４）：インターネット上でホームページを開設し、ユーザーにコンテンツ等を提供するサーバーである。電話会社等のＷＡＰゲートウェイ運営者と契約し、ＷＡＰゲートウェイの公式メニューに選択項目として登録される。ユーザーが移動端末の表示画面に表示されたメニューから当該選択項目を選択することにより、ユーザーはＷＡＰゲートウェイを介して当該ホームページにアクセスし、提供コンテンツの購入が可能となる。

ＳＧＳＮ（３０）：無線ネットワークコントローラとコアネットワーク（パケット網）とのゲートウェイである。
ＳＭＳＣ（３１）：ショート・メッセージ・サービス・センターであり、簡易メールを管理するサーバーである。
ＤＲＳ（３２）：全加入者の情報を一元管理するサーバー（ＤＩＲ）から加入者情報を一定間隔毎にローカルにコピーし維持するサーバーである。照会要求に対して加入者情報を提供し、ＤＩＲが障害の時においても、サービスを継続して提供することを可能にしている。
ＰＰＧ（３３）：プッシュ・プロキシー・ゲートウェイであり、プッシュ（Push）サービスを実行したいノードからの要求により、端末にデータのプッシュを実行するサーバーである。
ＤＲＭ（３４）：著作権管理機構であり、オープン・モバイル・アライアンス（Open Mobile Alliance OMA DRM) 1.0 に定められている３つの著作権管理方法（Forward-lock、Combined delivery、Separate delivery）に対応している。
ＭＭＳ−Ｒ（３５）：マルチメディアメッセージの受信、送信を行うメールサーバーであり、送受信者の認証やメールボックスへのメッセージの格納、取り出し、配信などを行う。
ＭＡＣＳ（３６）：ミッドレット（MIDlet）アクセス・コントロール・サーバーであり、ミッドレット（移動端末用の簡易Javaアプレット）へのアクセス、転送を管理するサーバーである。
Ｒｅｐｏ−ＤＢ（３７）：インターネット上でデータを保存、管理することを目的としたサーバーの総称である。
ＣＯＰ（３８）：ネットワークの設定など、移動端末のセットアップに必要な情報を、ＯＴＡ（Over The Air）を介して提供するノード（ＣＯＰ：Client OTA Provisioning）である。

図１−２には、ユーザーの移動端末とインターネット上で無料のコンテンツを提供するコンテンツ提供サーバー間のシーケンスが示されており、その詳細は以下のとおりである。
（１）シーケンス１〜２
移動端末（ＵＥ）上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）がＷＥＢコンテンツを取得するとき、ＴＣＰ（Transmission Control Protocol）セッションを確立するための接続要求「1) Activate PDP Context Request」をＳＧＳＮ３０に送出する。ＳＧＳＮ３０は、「1) Activate PDP Context Request」を受信すると、移動端末（ＵＥ）の加入者に割り当てられた国際識別番号（ＩＭＳＩ：International Mobile Subscriber Identity）及び移動端末（ＵＥ）の電話番号（ＭＳＩＳＤＮ：Mobile Station ISDN number）が添付された「2) Create PDP Context Request」を生成して、ＧＧＳＮ２に送出する。

（２）シーケンス３〜４
ＧＧＳＮ２は、「2) Create PDP Context Request」を受信すると、ＪＳＲ３に対して認証要求「3) RADIUS Access Request」を送出し、ＪＳＲ３から認証成功を示す「4) RADIUS Access Accept」が返送されると、移動端末（ＵＥ）にＩＰアドレスを払い出して、Ｒ２Ｍ７に対してRADIUSアカウンティングリクエスト「5) RADIUS Accounting-start Request」を送出する。このRADIUSアカウンティングリクエスト「5) RADIUS Accounting-start Request」には、払い出された移動端末（ＵＥ）のＩＰアドレス、ＭＳＩＳＤＮあるいはＩＭＳＩなどが添付されている。

（３）シーケンス５〜７
Ｒ２Ｍ７は、「5) RADIUS Accounting-start Request」を受信すると、ユーザーごとのセッション情報やプロファイル情報を作成して、ＩＰアドレスをキーにひとまとめにして内部メモリにキャッシュする。このキャッシュされた情報は該当するセッションが開放されるまでの間保持される。また、Ｒ２Ｍ７は、ＪＳＰ６にこのセッション情報をリプリケーションさせるために、「6) Replication RADIUS Accounting Profile」を送出する。ＪＳＰ６は、「6) Replication RADIUS Accounting Profile」を受信すると、内部にこのセッション情報の複製（レプリカ）を保持する。ここで、保持するセッション情報には、移動端末（ＵＥ）のＩＰアドレス、ＭＳＩＳＤＮ、ＩＭＳＩが含まれている。ＪＳＰ６は、このセッション情報の複製（レプリカ）を保持すると、セッション情報がリプリケーションされたことを通知する「7) Replication RADIUS Accounting Profile Response」をＲ２Ｍ７に送出する。

（４）シーケンス８〜１０
Ｒ２Ｍ７は、「7) Replication RADIUS Accounting Profile Response」を受信すると、ＧＧＳＮ２にＴＣＰセッションの接続準備が整ったことを通知する「8) RADIUS Accounting-start Response」を送出する。ＧＧＳＮ２は、移動端末（ＵＥ）に対して払い出されたＩＰアドレスが添付された「9) Create PDP Context Response」をＳＧＳＮ３０に送出する。次いでＳＧＳＮ３０は、移動端末（ＵＥ）に対して「10) Activate PDP Context Response を送出する。これによって、移動端末（ＵＥ）とＪＳＰ６との間でＴＣＰハンドシェイクが行われてＴＣＰセッションが確立される。

（５）シーケンス１１
移動端末（ＵＥ）とＪＳＰ６との間でＴＣＰセッションが確立すると、移動端末（ＵＥ）は、オリジン・サーバ（ＣＰ）からコンテンツを取得するためにＨＴＴＰリクエスト「11) HTTP Request」をＪＳＰ６に送出する。ＪＳＰ６は、ＨＴＴＰリクエスト「11) HTTP Request」を受信すると、内部に保持しているセッション情報の複製（レプリカ）を参照して、対応するセッション情報が存在するとともに、加入者情報が一致する場合にのみ、そのＨＴＴＰリクエスト「11) HTTP Request」を受け付ける。このＨＴＴＰリクエスト「11) HTTP Request」のヘッダには、ＧＧＳＮ２から払い出された移動端末（ＵＥ）のＩＰアドレス、コンテンツを取得する相手先であるコンテンツ提供サーバ（ＣＰ）のＵＲＩ（Request-URI）、ユーザエージェント情報（UA）、ユーザエージェントのプロファイル情報（UA-Profile）が含まれている。

（６）シーケンス１２〜１３
ＪＳＰ６は、ＨＴＴＰリクエスト「11) HTTP Request」を受信すると、この移動端末（ＵＥ）がコンテンツの取得に必要なプロファイル情報をＲ２Ｍ７から取得するために「12) Profile get Request」を送出する。Ｒ２Ｍ７は、「12) Profile get Request」に添付されているＩＰアドレス、ユーザエージェント情報（UA）、ユーザエージェントのプロファイル情報（UA-Profile）に基づいて、内部にキャッシュされている移動端末（ＵＥ）のプロファイル情報を取得して、「13) Profile get Response」によってＪＳＰ６に通知する。

（７）シーケンス１４〜１５
ＪＳＰ６は、Ｒ２Ｍ７から通知された移動端末（ＵＥ）のプロファイル情報に含まれている端末情報（UE-Profile）に基づいて不足しているパラメータを、移動端末（ＵＥ）から受信したＨＴＴＰリクエスト「11) HTTP Request」の拡張ヘッダに補完して、Request-URIで特定されるコンテンツ提供サーバ（ＣＰ）に「14) HTTP Request」を送出する。ここで、ＷＡＰ対応の移動端末（ＵＥ）では、端末情報（UE-Profile）のパラメータを添付するための拡張ヘッダを持つＨＴＴＰリクエスト「11) HTTP Request」の送出が困難である。しかし、ＪＳＰ６がＨＴＴＰリクエスト「11) HTTP Request」の拡張ヘッダに端末情報（UE-Profile）のパラメータを補完することによって、コンテンツ提供サーバ（ＣＰ）では、移動端末（ＵＥ）がＷＡＰ対応の移動端末かどうかによらず、ＨＴＴＰリクエスト「14) HTTP Request」の拡張ヘッダに添付されている端末情報（UE-Profile）のパラメータを参照することにより、移動端末（ＵＥ）の性能や能力を知ることができる。そして、コンテンツ提供サーバ（ＣＰ）は、移動端末（ＵＥ）の性能や能力に適合するコンテンツを選択あるいは生成して、そのコンテンツを「15) HTTP Response」によってＪＳＰ６に返送する。

（８）シーケンス１６
ＪＳＰ６は、「15) HTTP Response」によってコンテンツ提供サーバ（ＣＰ）から取得したコンテンツをＨＴＴＰレスポンス「16) HTTP Response」として移動端末（ＵＥ）に返送する。ここで、コンテンツ提供サーバ（ＣＰ）によっては、ＨＴＴＰリクエスト「14) HTTP Request」の拡張ヘッダを参照することなくコンテンツを返送するサーバーがある。この場合、ＪＳＰ６が取得したコンテンツは、必ずしも移動端末（ＵＥ）の性能や能力に適合したものではない。そのような場合には、ＪＳＰ６は、移動端末（ＵＥ）の端末情報（UE-Profile）に基づいて、その移動端末（ＵＥ）の性能や能力に適合するように、コンテンツの文字変換やファイル形式変換などを行って、移動端末（ＵＥ）に返送する。

（９）シーケンス１７〜２２
移動端末（ＵＥ）は、ＨＴＴＰレスポンス「16) HTTP Response」によってコンテンツを取得すると、ＪＳＰ６との通信を終了させるために、セッションの開放要求「17) Deactivate PDP Context Request」をＳＧＳＮに送出する。ＳＧＳＮ３０は、ＧＧＳＮ２に「18) Delete PDP Context Request」を送出し、次いでＧＧＳＮ２は、「19) RADIUS Accounting-stop Request」をＲ２Ｍ７に送出する。これを受信したＲ２Ｍ７は、内部に保持していた該当セッション情報を破棄して、「20) RADIUS Accounting-stop Response」をＧＧＳＮ２に送出する。ＧＧＳＮ２は、「21) Delete PDP Context Response」をＳＧＳＮ３０に送出し、次いでＳＧＳＮ３０は、「22) Delete PDP Context Response」を移動端末（ＵＥ）に送出する。こうして移動端末（ＵＥ）とＪＳＰ６との間のＴＣＰセッションが開放され通信が終了する。

図２に、移動端末のユーザーがＷＡＰゲートウェイのメニューサーバー（ＰＴＬ８）からコンテンツ、例えば音楽に関するメニューを取得し、このメニューを参考にインターネット上に存在するコンテンツ提供サーバーのコンテンツを選択し、購入する手順及び制御の概要が示されている。

（１）ユーザーが移動端末（UE）から特定の分野、例えば音楽の販売サイトに関するメニューの表示要求をＷＡＰゲートウェイに送信する（ステップａ）。
（２）ＷＡＰゲートウェイのＧＧＳＮ２は、ＪＳＲ３にて携帯電話パケット網からの上記要求の正当性の認証後、要求をIPネットワークのプロトコルに変換しＪＳＰ６に送信する。ＰＣＮ４はパケットの授受を監視し、課金情報としてアクセスログ統計５に記録する。
（３）ＪＳＰ６はユーザー端末からの要求を解析し、当該要求を転送すべき後段サーバーを決定する。この例では、要求はメニューの取得要求であるため、要求をメニューサーバーＰＴＬ８に適合した形式に変換し、ＰＴＬ８に送信する。その際ＪＳＰ６はＲ２Ｍ７に記録されているユーザー情報を基に、そのユーザーに要求メニューのアクセスが許容されているか否かを判断する。ＰＴＬ８はＪＳＰ６によりアクセスが許可されている時は要求されたメニューデータを自己のデータベース９から読み出し、要求時のルートと逆のルートを介してユーザー端末（UE）に送信する（ステップｂ）。

（４）ユーザー端末ではＪＳＰ６から送信されたメニューを表示し、ユーザーは表示されたメニュー項目から購入を希望する選択肢を選択する。ユーザーの選択動作により、選択された選択肢に付加されている販売サイトのＵＲＬに対するアクセス要求がＷＡＰゲートウェイに送信される（ステップｃ）。
（５）上記要求は、ＧＧＳＮ２、ＪＳＰ６、及びＷＧＷ１）を介してＷｔｒａｎｓ１３に送られる。Ｗｔｒａｎｓ１３はＷＡＰ内のローカルＩＰアドレスをグローバルＩＰアドレスへ変換する等の処理を行い、インターネットに要求を送出する。
（６）アクセス先のコンテンツ提供サーバー（ＣＰ）は要求されたホームページのデータを返送する（ステップｄ）。当データは上記（５）の経路とは逆の経路を経てユーザー端末（UE）に送信され、表示器に表示される。
（７）ユーザーはユーザー端末（UE）に表示されたデータに基づき、購入を希望するコンテンツを選択する。ユーザー端末（UE）は選択されたコンテンツに付加されている被選択コンテンツのＵＲＬを送出する（ステップｅ）。
（８）上記ＵＲＬ要求は、ＧＧＳＮ２、及びＪＳＰ６を介してＷＧＷ１０に送られる。ＷＧＷ１０ではユーザー情報を基に、そのユーザーに要求されたコンテンツの購入が許可されているか否かを判断し、購入可／不可の応答をユーザー端末（UE）に送信する（ステップｆ）。

（９）ユーザーは購入可の返信を受信すると、購入意志の確認を送出する（ステップｇ）。ユーザーから購入意志を受信したコンテンツ提供サーバー（ＣＰ）は、コンテンツのダウンロードに関する情報を返信する（ステップｈ）。
（１０）ＪＳＰ６はＣＰ１４からのダウンロード情報を受信すると、ユーザーと購入を許可されたコンテンツの対応データを作成し、現在時刻等必要な情報と共に記憶する。次にＪＳＰ６はコンテンツのダウンロードに関する情報をユーザー端末（UE）に中継する（ステップｉ）。
（１１）ユーザーは端末に表示されたＣＰ１４からの指示に従ってダウンロードを開始する（ステップｊ）。ＪＳＰ６はユーザー端末（UE）からのダウンロード要求とステップｉで記憶された対応データを照合し、正当なダウンロード要求か否かを判断する。正当なダウンロード要求と判断された時、当該ダウンロード要求をＷＧＷ１０に転送する（ステップｋ）。
（１２）ＷＧＷ１０はダウンロード要求に対応するコンテンツの課金情報を更新し記録する。次に、ＷＧＷ１０はＷｔｒａｎｓ１３を介してコンテンツ提供サーバー（ＣＰ）にダウンロード要求を中継する（ステップｌ）。
（１３）コンテンツ提供サーバー（ＣＰ）は要求されたコンテンツをユーザー端末（UE）に向けて送出する（ステップｍ）。ＷＧＷ１０はステップｌで更新されたコンテンツの課金情報を確定し、コンテンツをユーザーに転送する（ステップｎ）。
（１４）ユーザー端末は、コンテンツが正常に受信されたか否かを判断し、正常に受信された時はＧＧＳＮ２との間で終了処理を実行する（ステップｏ）。
正常に終了しなかった場合はリトライ等のエラー処理を実行する。

上述したように、各サーバー間ではリクエストとレスポンスによりデータの授受を行っている。例えば、メニューサーバーＰＴＬ８はユーザーからの要求に応答してメニューデータをユーザー端末に送信するものであり、ユーザー端末からユーザーが希望するコンテンツグループのメニュー要求が送信されると、ＪＳＰ６はＰＴＬ８に該当するメニューデータの出力を要求する。当該要求に応答して、ＰＴＬ８は自己のデータベースから要求されたメニューファイルを抽出しＪＳＰ６に返信する。しかし、ＰＴＬ８が、メンテナンス等により機能を停止する場合がある。ＰＴＬ８が機能を停止しているにもかかわらず、ユーザーからの要求によりＪＳＰ６がＰＴＬ８にメニュー要求を転送すると、応答待ちのための処理遅延、応答不能を通知するための無用な通信の増加等、前述した不都合が発生する。

本発明は、ＷＡＰゲートウェイにおいて、移動端末からの要求を後段のサーバーに分配するサーバー、例えばＪＳＰ６に後段の各サーバーの稼働状況を示すデータを記憶する非稼働テーブルを設け、前段より送られてきた要求を後段のサーバーに分配する時、前記非稼働テーブルから要求先の後段サーバーの稼働状況を検査し、要求先サーバーが稼働中である時にのみ、前記要求を後段サーバーに送信する。要求先サーバーが非稼働であることが前記稼働状況記憶装置に記憶されている時は、当該要求を送信した前段装置、例えば移動端末にその端末が出力した要求の受付が不可能である旨を通知する構成となっている。

図３及び図４に本発明の構成と動作の一例が示されている。図３（ａ）に示されるＪＳＰ６には非稼働テーブル１００が設けられている。ＰＴＬ８を保守修理するに当たり、ＪＳＰ６の入力装置から前記非稼働テーブル（１００）にＰＴＬ８を非稼働サーバーとして登録する。なお、非稼働の登録をＪＳＰ６の入力装置により行うのではなく、保守修理するＰＴＬ８の入力装置からＪＳＰ６に登録を要求する方法でも良い。登録が完了した後、ＰＴＬ８の保守修理を開始しＰＴＬ８の機能は停止する。図３には非稼働テーブル（１００）にＰＴＬ８が非稼働サーバーとして登録されている状態を示している。また、図３（ａ）及び（ｂ）には、稼働中のサーバーＷＧＷ１０への要求と、非稼働中のサーバーＰＴＬ８への要求が到来した際の対応が模式的に記載されている。

図４はＪＳＰ６の動作のフローチャートである。ＪＳＰ６の前段装置、例えばユーザー端末（ＵＥ）からインターネットへのアクセス要求、または公式メニューの送信要求がＷＡＰゲートウェイに送信されると、当該要求はＪＳＰ６に送られる（Ｓ２００）。ＪＳＰ６は当該要求から、当該要求を転送すべき後段サーバーを決定する（Ｓ２０１）。即ち、公式メニューの送信要求であれば転送先はメニューサーバーＰＴＬ８であり、インターネットへのアクセス要求であればＷＧＷ１０と決定される。次にＪＳＰ６は非稼働テーブル（１００）を検索し、決定された転送先の後段サーバーが非稼働テーブル（１００）に登録されているか否かを検査する（Ｓ２０２）。例えば、Ｓ２０１で転送すべき後段サーバーがＷＧＷ１０と判断された場合、非稼働テーブル（１００）にはＷＧＷ１０は登録されていない。従って、ＪＳＰ６は当該要求をＷＧＷ１０に転送する（Ｓ２０３）。ＷＧＷ１０は転送された要求を解析し所期の動作を実行する。

非稼働テーブル（１００）にはＰＴＬ８が非稼働サーバーとして登録されているため、Ｓ２０１で転送すべき後段サーバーがＰＴＬ８と判断された場合、ＪＳＰ６は当該要求を後段サーバーには転送せず、当該要求を発行した前段装置であるユーザー端末ＵＥ（１）に、要求した処理は実行不可能である旨通知する（Ｓ２０４）。非稼働テーブル（１００）に登録されているサーバーＰＴＬ８の保守が終了し、稼働状態に復帰した時、ＪＳＰ６の入力装置から、あるいは保守が終了したＰＴＬ８の入力装置から、非稼働テーブル（１００）からＰＴＬ８の登録を削除する要求をＪＳＰ６の制御部に与える。この要求により、非稼働テーブル（１００）からＰＴＬ８の登録は削除され、以後のユーザーによるメニュー要求はＰＴＬ８に転送され、ユーザーが要求したメニューデータをユーザーに返信する処理を実行する。

本発明によれば、非稼働テーブル（１００）の登録内容から、要求を転送すべき後段サーバーの稼働状況が即座に判断可能となる。その結果、非稼働サーバーに要求を転送することが無くなり、非稼働サーバーからの応答を待つという無駄時間が不必要となる。また、ＳOＲサーバーに処理不能を通知する等付加的な通信が不要であり、ＷＡＰゲートウェイの効率が向上する。

本発明が適用されるＷＡＰゲートウェイの概要図 本発明が適用されるＷＡＰのシーケンス例 ＷＡＰゲートウェイによるインターネットのアクセスの概要図 本発明の処理分配を示す図 本発明の処理分配のフローチャート図 従来の処理分配を示す図

Claims (2)

1. 移動端末からインターネットへのアクセス要求を処理するＷＡＰゲートウェイであって、
   移動端末からの要求を転送する後段サーバーを決定する分配手段と、
   後段サーバーの稼働／非稼働を示す指標を記憶するテーブル手段と、
   前記テーブル手段に非稼働の後段サーバーを登録する手段と、
   前記テーブル手段に前記決定された後段サーバーが登録されていない時、前記移動端末からの要求を後段サーバーに転送する手段と、
   前記テーブル手段に前記決定された後段サーバーが登録されている時、前記要求移動端末に処理不能の応答をする手段と、
   からなることを特徴とするＷＡＰゲートウェイ。
2. 移動端末からインターネットへのアクセス要求を処理するＷＡＰゲートウェイの制御方法であって、
   後段サーバーの稼働／非稼働を示すデータを記憶するステップと、
   移動端末の要求から該要求を転送する後段サーバーを決定するステップと、
   前記テーブルのデータから前記決定された後段サーバーの稼働／非稼働を判別するステップと、
   前記テーブルに後段サーバーの非稼働が登録されていない時、前記移動端末からの要求を後段サーバーに転送するステップと、
   前記テーブルに後段サーバーの非稼働が登録されている時、前記移動端末に処理不能を通知するステップと
   からなることを特徴とするＷＡＰゲートウェイの制御方法。

Images