(57)【要約】【課題】通信が一時的に途切れた状態になった場合でも、途切れた通信セッションを再開することのできるサーバ装置を提供する。【解決手段】本発明に係るサーバ装置は、通信途中で遮断したセッションの情報を保持するセッション情報テーブルを備えている。セッション情報がセッション情報テーブルに格納されているときに当該サーバ装置にアクセスがあると、当該サーバ装置は中断していた通信セッションを再開する。【選択図】図１
2010273045.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとの間で通信するサーバ装置であって、
前記クライアントとの間で通信パケットを送受信する送受信部と、
前記クライアントを特定するクライアント特定部と、
前記クライアント特定部が特定した前記クライアントの識別情報を、前記クライアントとの間の通信セッションを特定するセッション情報として保持するセッション情報テーブルと、
前記セッション情報テーブルに前記セッション情報を格納するセッション管理部と、
を備え、
前記セッション管理部は、
通信途中で中断した前記通信セッションを特定する前記セッション情報を前記セッション情報テーブルに格納し、
前記セッション情報テーブルが前記セッション情報を保持しているときにそのセッション情報に対応する前記クライアントから当該サーバ装置にアクセスがあると、
そのセッション情報を用いて当該セッションを再開する
ことを特徴とするサーバ装置。
【請求項２】
前記クライアントを認証する認証部を備え、
前記クライアント特定部は、
前記クライアントが動作する端末の識別子と、前記認証部が前記クライアントを認証する際に用いる認証情報とを用いて、前記クライアントを特定する
ことを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記セッション管理部は、
前記セッション情報テーブルに前記セッション情報を格納してから所定時間以上が経過したときは、
そのセッション情報を前記セッション情報テーブルから削除する
ことを特徴とする請求項１または請求項２記載のサーバ装置。
【請求項４】
前記セッション管理部は、
前記クライアントとの間の通信セッションにおいて当該クライアントに応答データを返信している途中で当該通信セッションが中断したときは、
その通信セッションを特定するセッション情報として、
当該クライアントを特定する識別情報と当該応答データを前記セッション情報テーブルに格納しておき、
前記セッション情報テーブルがそのセッション情報を保持しているときに前記クライアントから当該サーバ装置にアクセスがあると、
前記応答データをそのクライアントに送信する
ことを特徴とする請求項１から請求項３までのいずれか１項に記載のサーバ装置。
【請求項５】
前記セッション管理部は、
前記クライアントとの間の通信セッションにおいて当該クライアントから通信パケットを受信している最中に当該通信セッションが中断したときは、
その通信セッションについての前記セッション情報を前記セッション情報テーブルに書き込まずに当該通信セッションを終了する
ことを特徴とする請求項１から請求項４までのいずれか１項に記載のサーバ装置。
【請求項６】
前記クライアントから受信した情報を保持するアプリケーションデータベースを備え、
前記セッション管理部は、
前記クライアントとの間の通信セッションにおいて当該クライアントから通信パケットを受信して前記アプリケーションデータベースに対する書き込みを開始した後であってその書き込みが終了する前の時点で当該通信セッションが中断したときは、
その通信セッションについての前記セッション情報を前記セッション情報テーブルに書き込まずに当該通信セッションを終了する
ことを特徴とする請求項１から請求項５までのいずれか１項に記載のサーバ装置。
【請求項７】
前記送受信部は、
前記セッション情報テーブルが前記セッション情報を保持しているときにそのセッション情報に対応する前記クライアントから当該サーバ装置にアクセスがあると、
当該通信セッションを再開するかまたは当該セッション情報を破棄するかを選択することを促す応答データを当該クライアントに送信し、
前記セッション管理部は、
当該クライアントが当該通信セッションを再開する旨の要求を当該サーバ装置に送信した場合には、
そのセッション情報を用いて当該セッションを再開する
ことを特徴とする請求項１から請求項６までのいずれか１項に記載のサーバ装置。
【請求項８】
前記セッション管理部は、
当該クライアントが当該セッション情報を破棄する旨の要求を当該サーバ装置に送信した場合には、
そのセッション情報を前記セッション情報テーブルから削除する
ことを特徴とする請求項７記載のサーバ装置。
【請求項９】
前記送受信部は、
前記クライアントが当該サーバ装置に通信パケットを送信する際に表示していた画面を識別する画面ＩＤを受信し、
前記セッション管理部は、
当該通信セッションにおける前記画面ＩＤを前記セッション情報テーブルに格納し、
前記セッション情報テーブルが前記セッション情報を保持しているときにそのセッション情報に対応する前記クライアントから当該サーバ装置にアクセスがあると、
当該通信セッションにおける前記画面ＩＤを用いて前記セッション情報テーブルを検索し、
該当する前記セッション情報が見つかったときは、
そのセッション情報を用いて当該セッションを再開する
ことを特徴とする請求項１から請求項８までのいずれか１項に記載のサーバ装置。
【請求項１０】
前記送受信部は、前記画面ＩＤとして、
前記クライアントが当該サーバ装置に通信パケットを送信する際に表示していた一連の複数の画面を一体として識別する画面ＩＤを受信する
ことを特徴とする請求項９記載のサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置に関するものである。
【背景技術】
【０００２】
携帯電話の高性能化に伴い、携帯電話からＷｅｂシステムへアクセスすることが広まってきている。しかし、地下鉄、僻地等ではまだ携帯電話の通信可能圏外となる箇所があるため、どこでもＷｅｂシステムにアクセスすることができるわけではない。
【０００３】
一方、近年では法人で携帯電話向けのＷｅｂシステムが利用されることが増えてきている。このとき、携帯電話からＷｅｂシステムにアクセスして重要な登録作業を行う場合がある。
【０００４】
Ｗｅｂシステムでは、サーバ装置上でＷｅｂアプリケーションが動作する。デスクトップコンピュータ、携帯電話等の移動端末装置は、Ｗｅｂクライアント端末としてサーバ装置にアクセスし、サーバアプリケーションが提供するＷｅｂページを取得して表示する。ユーザは、そのＷｅｂページ上でコンテンツの閲覧や登録作業などの操作を行う。
【０００５】
Ｗｅｂクライアント端末は、サーバ装置からＷｅｂページを取得して画面表示するためにＷｅｂブラウザソフトウェアを用いる。
【０００６】
Ｗｅｂクライアント端末には、ディスプレイなどの表示装置と、キーボードまたはマウスなどの入力装置とが設けられている。表示装置に表示されたＷｅｂページ上で、ユーザが入力装置を用いてＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を入力した時点、またはブックマークなどによりあらかじめ記録されたＵＲＬを選択した時点、またはＷｅｂページに貼り付けられているリンクを選択した時点で、Ｗｅｂブラウザソフトウェアは、選択されたＷｅｂページの内容をネットワーク経由で取得する。Ｗｅｂブラウザソフトウェアは、取得したＷｅｂページを表示装置上に表示する。
【０００７】
Ｗｅｂブラウザソフトウェアは、サーバ装置が応答としてＷｅｂページを送信している途中で通信セッションが遮断された場合、所定のタイムアウト値まで待機した上で、タイムアウトエラー画面を表示する。
【０００８】
通信セッションに関する従来技術として、下記特許文献１や特許文献２のようなものがある。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−３１２０９１号公報
【特許文献２】特開２００９−６４０５６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
移動端末装置は、地下や僻地では通信可能圏外となることがある。そのため、移動端末装置がＷｅｂシステムを利用しているときに、一時的に通信が途切れる場合がある。このとき、移動端末装置のＷｅｂブラウザソフトウェアは、上述のようにタイムアウトエラー画面を表示する。
【００１１】
通信が途切れる前にユーザがＷｅｂページ上で登録作業などを行っていた場合、途中で通信が途切れると、ユーザはそのＷｅｂページ上で行っていた登録処理が完了したか否かが分からなくなる。その結果、ユーザは再度同じＷｅｂページ上で登録作業を行い、２重に登録が行われてしまう可能性がある。
【００１２】
上記のような不都合は、Ｗｅｂアプリケーションが２重登録チェックを行うことで回避することができる。しかし、２重登録チェックは登録画面のセッションＩＤなど特定のパラメータを用いて行われることが多いため、同じ通信セッション内で再度同じＷｅｂページから登録処理が実行されない限り、２重更新チェックが正常に動作しない場合がある。例えば、一時的に通信が途切れたときにＷｅｂブラウザソフトウェアを一旦終了させ、再度Ｗｅｂブラウザソフトウェアを起動して元のＷｅｂページから登録作業を行うと、２重登録チェックが正常に行われない可能性がある。
【００１３】
本発明は、上記のような課題を解決するためになされたものであり、通信が一時的に途切れた状態になった場合でも、途切れた通信セッションを再開することのできるサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明に係るサーバ装置は、通信途中で遮断したセッションの情報を保持するセッション情報テーブルを備えている。セッション情報がセッション情報テーブルに格納されているときに当該サーバ装置にアクセスがあると、当該サーバ装置は中断していた通信セッションを再開する。
【発明の効果】
【００１５】
本発明に係るサーバ装置は、通信途中で遮断したセッションの情報を保持しておくことにより、通信が一時的に途切れた状態になった場合でも、途切れた通信セッションを再開することができる。
【図面の簡単な説明】
【００１６】
【図１】実施の形態１に係るサーバ装置１００の機能ブロック図である。
【図２】セッションＤＢ１３０が格納しているセッション情報テーブルの構成とデータ例を示す図である。
【図３】サーバ装置１００がセッションＤＢ１３０にセッション情報を格納する際の動作シーケンスを示す図である。
【図４】図３の動作シーケンスの後にユーザが再び同じ移動端末３００を用いてサーバ装置１００にアクセスしたときの動作シーケンスを示す図である。
【図５】図３〜図４に対応する移動端末３００の画面遷移図である。
【図６】セッション管理部１４０が古いセッション情報を削除する処理フローである。
【図７】実施の形態２におけるサーバ装置１００の動作シーケンスを示す図である。
【図８】実施の形態３におけるサーバ装置１００の動作シーケンスを示す図である。
【図９】実施の形態４における移動端末３００の画面遷移を示す図である。
【図１０】ユーザが図９（４）の画面で「再取得する」ボタンを押下したときのサーバ装置１００の動作フローである。
【図１１】ユーザが図９（４）の画面で「再取得しない」ボタンを押下したときのサーバ装置１００の動作フローである。
【図１２】ユーザが図９（３）の画面で「送信」ボタンを押下したときのサーバ装置１００の動作フローである。
【図１３】実施の形態５におけるセッション情報テーブルの構成とデータ例を示す図である。
【図１４】入力用Ｗｅｂページが複数画面にまたがっている場合の画面遷移図である。
【発明を実施するための形態】
【００１７】
（実施の形態１）
図１は、本発明の実施の形態１に係るサーバ装置１００の機能ブロック図である。サーバ装置１００は、クライアントにＷｅｂサービスを提供する装置である。
【００１８】
なお、ここでいうクライアントとは、Ｗｅｂブラウザ等のＷｅｂアクセスに用いるクライアントソフトウェアを備えた端末本体、またはそのクライアントソフトウェアのことをいう。また、Ｗｅｂサービスとは、Ｗｅｂページをクライアントに提供する機能、クライアントにそのＷｅｂページ上で情報入力を行わせてその内容をデータベース等に登録する機能など、Ｗｅｂ経由でクライアントに提供することのできる種々の機能をいう。
【００１９】
サーバ装置１００は、インターネット５００を介して、基地局２００、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）４００と接続されている。インターネット５００と、基地局２００およびＰＣ４００との間の接続形態は、有線・無線など任意のものでよい。図１では、サーバ装置１００、基地局２００、ＰＣ４００はそれぞれ１つずつ記載しているが、これらの個数は１つに限定されるものではなく、それぞれ複数存在していてもよい。
【００２０】
基地局２００の配下には、無線ネットワークを介して移動端末３００ａ、３００ｂ、３００ｃが接続されている。移動端末３００ａ〜３００ｃは、Ｗｅｂブラウザを備えた携帯電話などの端末である。移動端末３００ａ〜３００ｃは、無線ネットワークを介して基地局２００に接続し、基地局２００〜インターネット５００を経由してサーバ装置１００にアクセスし、Ｗｅｂブラウザの機能を用いてＷｅｂサービスを利用する。
【００２１】
ＰＣ４００には、Ｗｅｂブラウザがインストールされている。ＰＣ４００は、インターネット５００を介してサーバ装置１００にアクセスし、Ｗｅｂブラウザの機能を用いてＷｅｂサービスを利用する。
【００２２】
サーバ装置１００は、送受信部１１０、クライアント特定部１２０、セッションＤＢ（ＤａｔａＢａｓｅ）１３０、セッション管理部１４０、クライアント認証部１５０を備える。
【００２３】
送受信部１１０は、インターネット５００と接続し、基地局２００やＰＣ４００との間で通信パケットを送受信する。
【００２４】
クライアント特定部１２０は、サーバ装置１００にアクセスしたクライアントを特定する。クライアントを特定する手法については、後述の図２で改めて説明する。
【００２５】
セッションＤＢ１３０は、後述の図２で説明するセッション情報テーブルを格納する。
【００２６】
セッション管理部１４０は、セッション情報テーブルにセッション情報を格納する。また、セッション情報テーブルが保持しているセッション情報を用いて、途中で中断したセッションを再開する。具体的な動作については、後述の図３〜図４で改めて説明する。
【００２７】
クライアント認証部１５０は、サーバ装置１００にアクセスしたクライアントを認証してその認証結果をクライアント特定部１２０に通知する。
【００２８】
クライアント特定部１２０、セッション管理部１４０、クライアント認証部１５０は、これらの機能を実現する回路デバイスのようなハードウェアを用いて構成することもできるし、マイコンやＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）のような演算装置とその動作を規定するソフトウェアを用いて構成することもできる。
【００２９】
送受信部１１０は、適当な通信インターフェースを備える。
【００３０】
セッションＤＢ１３０は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの書き込み可能な記憶装置に、セッション情報テーブルを構成するファイル等を格納するなどにより構成することができる。
【００３１】
図２は、セッションＤＢ１３０が格納しているセッション情報テーブルの構成とデータ例を示す図である。セッション情報テーブルは、中断した通信セッションを特定するセッション情報を保持するテーブルである。セッション情報テーブルは、セッションＩＤ１３１、要求元端末ＩＤ１３２、要求元ＩＰアドレス１３３、要求元ログインＩＤ１３４、発行時刻１３５、応答データ１３６を、各セッション情報について保持する。
【００３２】
セッションＩＤ１３１は、各セッション情報を識別するための一意のＩＤである。
【００３３】
要求元端末ＩＤ１３２は、サーバ装置１００にアクセスしたクライアント端末を一意に識別するＩＤである。例えば、クライアント端末が携帯電話である場合、当該携帯電話のＷｅｂブラウザは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いてサーバ装置１００にアクセスする際に、要求元端末ＩＤ１３２をＨＴＴＰヘッダ内に自動的に格納する。サーバ装置１００は、その値をセッション情報テーブルに格納する。
【００３４】
要求元ＩＰアドレス１３３は、サーバ装置１００にアクセスしたクライアント端末のＩＰアドレスである。
【００３５】
要求元ログインＩＤ１３４は、クライアント端末がサーバ装置１００上のＷｅｂアプリケーションにログインする際に用いる認証情報である。要求元ログインＩＤ１３４の用い方については後述する。
【００３６】
発行時刻１３５は、当該セッション情報を格納した時刻である。
【００３７】
応答データ１３６は、サーバ装置１００からクライアント端末に応答データを送信している際に当該通信セッションが中断した場合、その応答データが格納される。本実施の形態１ではＷｅｂアプリケーションを想定しているため、応答データとしてＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）テキストを格納した例を示した。
【００３８】
以上、サーバ装置１００の構成について説明した。次に、サーバ装置１００の動作について説明する。
【００３９】
図３は、サーバ装置１００がセッションＤＢ１３０にセッション情報を格納する際の動作シーケンスを示す図である。以下、図３の各ステップについて説明する。本動作シーケンスではユーザが指名をＷｅｂアプリケーション上で登録する処理を例とする。以下では移動端末３００がサーバ装置１００にアクセスする場合を説明するが、ＰＣ４００がサーバ装置１００にアクセスする場合も動作シーケンスは同様である。
【００４０】
（図３：ステップＳ３０１）
移動端末３００のユーザは、Ｗｅｂブラウザを操作して、サーバ装置１００のＵＲＬを指定する。このときユーザは、サーバ装置１００が提供するＷｅｂアプリケーションにログインするための認証情報として、ログインＩＤを入力してもよい。移動端末３００のＷｅｂブラウザは、ＨＴＴＰを用いてサーバ装置１００にアクセスする。ユーザがログインＩＤを指定した場合は、ログインＩＤも併せて送信される。なお、ログインＩＤとパスワードのセットを認証情報として用いてもよいが、以下では説明の簡易のため、ログインＩＤのみを用いる。
【００４１】
（図３：ステップＳ３０２）
送受信部１１０は、ＷｅｂブラウザからのＨＴＴＰクエリを受信する。送受信部１１０は、クライアント特定部１２０に当該クライアント（ここでは移動端末３００）を特定するよう依頼する。ここでいうクライアントの特定とは、当該クライアント端末を識別する情報を特定することをいう。ログインＩＤが指定されている場合には、その情報にはログインＩＤも含めることができる。
【００４２】
（図３：ステップＳ３０３）
クライアント特定部１２０は、以下のようにして当該クライアントを識別する情報を特定し、その結果を送受信部１１０に戻す。
【００４３】
（図３：ステップＳ３０３：その１）
携帯電話のように、当該クライアント端末が固有のＩＤを有する場合、クライアント特定部１２０は、その端末ＩＤを取得する。また、当該クライアント端末のＩＰアドレスを併せて取得してもよい。クライアント特定部１２０は、これらの組み合わせにより、当該クライアント端末を識別することができる。
【００４４】
（図３：ステップＳ３０３：その２）
当該クライアント端末が端末固有のＩＤを有さない場合、クライアント特定部１２０は、当該クライアント端末のＩＰアドレスを取得する。このＩＰアドレスにより、当該クライアント端末を識別する。
【００４５】
（図３：ステップＳ３０３：その３）
ステップＳ３０１でログインＩＤが送信された場合、クライアント特定部１２０は、クライアント認証部１５０に当該クライアント端末を認証するよう依頼する。クライアント認証部１５０は、認証結果をクライアント特定部１２０に戻す。クライアント特定部１２０は、当該クライアントが認証された場合は、上記その１またはその２にログインＩＤを組み合わせて、当該クライアント端末を識別する。
【００４６】
（図３：ステップＳ３０４）
送受信部１１０は、ステップＳ３０３でクライアント特定部１２０が特定した当該クライアントの識別情報をキーにして、中断したセッション情報がセッション情報テーブルに存在するか否かをセッション管理部１４０に問い合わせる。
【００４７】
（図３：ステップＳ３０５）
セッション管理部１４０は、当該クライアントの識別情報をキーにして、セッション情報テーブルを検索する。
【００４８】
（図３：ステップＳ３０６）
ここでは、セッション情報テーブルは空であるため、検索結果も空である。
【００４９】
（図３：ステップＳ３０７）
セッション管理部１４０は、該当するセッション情報は存在しない旨を、送受信部１１０に返信する。
【００５０】
（図３：ステップＳ３０８）
送受信部１１０は、クライアント特定部１２０が特定した上記各情報を用いて当該クライアントを特定し、そのクライアントとの間で通信セッションを確立する。
【００５１】
（図３：ステップＳ３０９）
移動端末３００のユーザは、サーバ装置１００が提供する入力用Ｗｅｂページにアクセスし、Ｗｅｂアプリケーションに登録する情報（例えばユーザの氏名など）を入力する。移動端末３００のＷｅｂブラウザは、その情報をサーバ装置１００に送信する。なお、記載の簡易のため省略するが、移動端末３００は、サーバ装置１００にアクセスする毎に、認証情報をサーバ装置１００に送信する。サーバ装置１００は、ステップＳ３０２〜Ｓ３０７と同様の処理を実行する。
【００５２】
（図３：ステップＳ３１０）
サーバ装置１００の送受信部１１０は、ステップＳ３０９で移動端末３００が送信した情報を受信する。サーバ装置１００のＷｅｂアプリケーションは、その情報を規定のアプリケーションデータベース（図示せず）などに登録する。
【００５３】
（図３：ステップＳ３１１）
サーバ装置１００の送受信部１１０は、登録が完了した旨を表示するＨＴＭＬデータを応答データとして移動端末３００に送信する。ここでは、その応答途中で移動端末３００とサーバ装置１００の間の通信セッションが中断し通信が途切れたものと想定する。
【００５４】
（図３：ステップＳ３１２）
送受信部１１０は、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）コネクションが切断されたことなどにより、応答途中で移動端末３００とサーバ装置１００の間の通信セッションが中断したことを検出する。送受信部１１０は、当該通信セッションを特定する情報をセッションＤＢ１３０に格納するように、セッション管理部１４０へ依頼する。
【００５５】
（図３：ステップＳ３１３）
セッション管理部１４０は、当該通信セッションのクライアントを特定するよう、クライアント特定部１２０へ依頼する。
【００５６】
（図３：ステップＳ３１４）
クライアント特定部１２０は、ステップＳ３０３と同様にして、当該クライアントを識別する情報を取得し、セッション管理部１４０に出力する。
【００５７】
（図３：ステップＳ３１５）
セッション管理部１４０は、当該クライアントを識別する情報、および送受信部１１０が移動端末３００に送信中であった応答データを、セッション情報テーブルに格納する。このとき、セッションＩＤ１３１と発行時刻１３５を適宜セットしておく。
【００５８】
（図３：ステップＳ３１６）
移動端末３００のＷｅｂブラウザは、タイムアウトエラーを画面表示する。
【００５９】
以上、セッション情報テーブルにセッション情報を格納するまでの動作シーケンスを説明した。次に、セッション情報を利用して、中断していたセッションを再開する動作シーケンスを説明する。
【００６０】
図４は、図３の動作シーケンスの後にユーザが再び同じ移動端末３００を用いてサーバ装置１００にアクセスしたときの動作シーケンスを示す図である。ここでは、図３のステップＳ３１６でタイムアウトエラー画面が表示された後、ユーザがＷｅｂブラウザの「戻る」キーを押下するなどして、ステップＳ３０９と同じ入力用Ｗｅｂページを再度画面表示したものとする。以下、図４の各ステップについて説明する。
【００６１】
（図４：ステップＳ４０１〜Ｓ４０５）
移動端末３００のユーザは、ステップＳ３０９と同じ入力用Ｗｅｂページで、Ｗｅｂアプリケーションに登録する情報（例えばユーザの氏名など）を入力する。移動端末３００のＷｅｂブラウザは、その情報をサーバ装置１００に送信する。なお、ステップＳ３０９と同様に、移動端末３００は、認証情報をサーバ装置１００に送信する。ステップＳ４０２〜Ｓ４０５は、図３のステップＳ３０２〜Ｓ３０５と同様である。
【００６２】
（図４：ステップＳ４０６）
ここでは、先の図３のステップＳ３１５でセッション情報テーブルに当該クライアントのセッション情報が書き込まれているので、そのセッション情報が照会結果としてセッション管理部１４０に戻される。
【００６３】
（図４：ステップＳ４０７）
セッション管理部１４０は、取得したセッション情報から応答データを取り出し、送受信部１１０に出力する。
【００６４】
（図４：ステップＳ４０８）
送受信部１１０は、応答データを移動端末３００に送信する。応答データの送信に成功した場合、セッション管理部１４０は、当該セッション情報をセッション情報テーブルから削除する。
【００６５】
（図４：ステップＳ４０９）
移動端末３００のＷｅｂブラウザは、応答データ（登録が完了した旨を示すＷｅｂページ）を画面表示する。
【００６６】
図５は、図３〜図４に対応する移動端末３００の画面遷移図である。各画面の上部に、対応するステップ番号を付与した。図３〜図４の動作シーケンスによれば、ユーザは登録が完了したことを把握することができる。また、中断したセッション情報をセッション情報テーブルに保持しておいて応答データのみ再送するので、２重登録は行われていない。
【００６７】
図６は、セッション管理部１４０が古いセッション情報を削除する処理フローである。通信セッションが途中で中断してからある程度以上の時間が経過したときは、もはやその通信セッションは有効でないといえる。この時間はＷｅｂアプリケーションの特性などによって異なるが、例えば中断してから３０分以上経過した通信セッションは、破棄しても支障ない場合が多いと考えられる。そこで、セッション管理部１４０は、古いセッション情報をセッション情報テーブルから検索して削除する。以下、図６の各ステップについて説明する。
【００６８】
（図６：ステップＳ６００）
セッション管理部１４０は、所定の時間間隔、例えば通信セッションの有効期間（３０分など）毎に、本処理フローを開始する。
【００６９】
（図６：ステップＳ６０１）
セッション管理部１４０は、セッション情報テーブルから、発行時刻１３５が現在時刻より所定時間（例えば３０分）以上前のセッション情報を検索する。
【００７０】
（図６：ステップＳ６０２）
セッション管理部１４０は、ステップＳ６０１で検索の結果として得られたセッション情報を、セッション情報テーブルから削除する。
【００７１】
以上、セッション情報を用いて、中断していたセッションを再開する動作シーケンスを説明した。
【００７２】
以上のように、本実施の形態１によれば、サーバ装置１００は、通信途中で中断したセッションを特定するセッション情報をセッション情報テーブルに保持しておく。後にクライアントがサーバ装置１００にアクセスした際は、そのセッション情報を用いて先に中断したセッションを再開する。
【００７３】
これにより、Ｗｅｂアプリケーション上で２重登録チェックを行うための仕組みを設けておかなくても、通信が一時的に途切れた状態になった場合には、途切れた通信セッションを再開することができる。
【００７４】
また、本実施の形態１によれば、クライアント特定部１２０は、クライアント端末のＩＤ（要求元端末ＩＤ１３２）と、Ｗｅｂアプリケーション上のログインＩＤ（要求元ログインＩＤ１３４）とを用いて、クライアントを特定する。
【００７５】
これにより、通信セッション毎にクライアント端末のＩＰアドレスやＦＱＤＮ名が変更になる可能性のある環境下でも、クライアントを確実に特定することができる。また、クライアントがセッションＩＤなどの通信セッションを識別する情報を保持することができない場合（例えばＣｏｏｋｉｅを保持することができない場合）であっても、クライアントを確実に特定することができる。
【００７６】
また、本実施の形態１によれば、セッション管理部１４０は、所定時間以上が経過した古いセッション情報を削除するので、有効性の低くなったセッション情報を不適切に再利用してユーザを混乱させてしまう可能性を低減することができる。
【００７７】
また、本実施の形態１によれば、セッション管理部１４０は、セッション情報として、送信途中であった応答データをセッション情報テーブルに格納しておき、後にセッションを再開するときにその応答データをクライアントに送信する。
【００７８】
これにより、ユーザはセッションが完了した旨を確実に知ることができるので、再度同じ情報を送信するなどして２重登録が発生してしまう可能性を低減することができる。
【００７９】
（実施の形態２）
本発明の実施の形態２では、セッション管理部１４０がセッション情報をセッション情報テーブルに格納しない例を説明する。各装置などの構成は実施の形態１と同様である。
【００８０】
図７は、本実施の形態２におけるサーバ装置１００の動作シーケンスを示す図である。以下、図７の各ステップについて説明する。
【００８１】
（図７：ステップＳ７０１〜Ｓ７０９）
これらのステップは、図３のステップＳ３０１〜Ｓ３０９と同様である。
【００８２】
（図７：ステップＳ７１０）
サーバ装置１００の送受信部１１０が移動端末３００から通信パケットを受信している最中に、移動端末３００とサーバ装置１００の間の通信セッションが中断し通信が途切れたものと想定する。すなわち、送受信部１１０は、移動端末３００が送信した通信パケットを一部のみ受信しているものとする。この場合、セッション管理部１４０は、その通信セッションを特定する情報を、セッション情報テーブルに格納しない。
【００８３】
（図７：ステップＳ７１１）
移動端末３００のＷｅｂブラウザは、タイムアウトエラーを画面表示する。
【００８４】
以上のように、本実施の形態２において、セッション管理部１４０は、クライアントから通信パケットを受信している最中に当該通信セッションが中断したときは、そのセッション情報をセッション情報テーブルに書き込まない。これは、もし受信途中のセッション情報を書き込んでしまうと、次にセッションを再開するときに、先に受信完了しておくべきであった情報が不完全に受信された状態でセッションが再開されてしまうからである。
【００８５】
すなわち、本実施の形態２によれば、不完全な通信セッションを不完全なままで再開してしまうことがないので、Ｗｅｂアプリケーション上の情報の完全性や一貫性を維持することができる。
【００８６】
（実施の形態３）
本発明の実施の形態３では、セッション管理部１４０がセッション情報をセッション情報テーブルに格納しない別の例を説明する。サーバ装置１００の構成は実施の形態１〜２と同様である。
【００８７】
図８は、本実施の形態３におけるサーバ装置１００の動作シーケンスを示す図である。以下、図８の各ステップについて説明する。
【００８８】
（図８：ステップＳ８０１〜Ｓ８０９）
これらのステップは、図３のステップＳ３０１〜Ｓ３０９と同様である。
【００８９】
（図８：ステップＳ８１０）
サーバ装置１００送受信部１１０は、ステップＳ８０９で移動端末３００が送信した情報を受信する。サーバ装置１００のＷｅｂアプリケーションがその情報を規定のアプリケーションデータベース（図示せず）などに登録している最中に、その登録トランザクションが異常終了したと仮定する。この場合、セッション管理部１４０は、その通信セッションを特定する情報を、セッション情報テーブルに格納しない。
【００９０】
（図８：ステップＳ８１１）
移動端末３００のＷｅｂブラウザは、タイムアウトエラーを画面表示する。
【００９１】
以上のように、本実施の形態３において、セッション管理部１４０は、アプリケーションデータベースに対するトランザクションが異常終了したときは、そのセッション情報をセッション情報テーブルに書き込まない。これは、データベーストランザクションが異常終了した通信セッションをそのまま再開してしまうと、データの完全性が崩れてしまう可能性があるからである。
【００９２】
すなわち、本実施の形態３によれば、不完全なトランザクションが発生する可能性のある通信セッションをそのまま再開してしまうことがないので、データベース上の情報の完全性や一貫性を維持することができる。
【００９３】
（実施の形態４）
本発明の実施の形態４では、セッション情報テーブルに中断したセッション情報が存在している場合、サーバ装置１００からの応答を再開するか否かをユーザに選択させる構成と動作例を説明する。本実施の形態４では、まず移動端末３００の画面遷移を説明し、その後にサーバ装置１００の動作シーケンスを説明する。なお、サーバ装置１００の構成は、実施の形態１〜３と概ね同様であるため、以下では差異点を中心に説明する。
【００９４】
図９は、本実施の形態４における移動端末３００の画面遷移を示す図である。以下、各画面の遷移について説明する。
【００９５】
（１）入力用Ｗｅｂページ
ユーザは、移動端末３００のＷｅｂブラウザを操作して、サーバ装置１００より入力用Ｗｅｂページを取得する。ユーザは、所定の入力項目を入力する。移動端末３００はサーバ装置１００にその情報を送信する。
（２）通信セッションが中断する
サーバ装置１００が移動端末３００に応答データを送信している最中に、通信セッションが遮断されたものとする。
（３）入力用Ｗｅｂページを再表示する
ユーザは、Ｗｅｂブラウザの「戻る」キーを押下して、入力用Ｗｅｂページを再度表示したものと仮定する。ユーザは、所定の入力項目を再入力する。移動端末３００はサーバ装置１００にその情報を再送信する。
（４）応答再開／中止の選択画面
サーバ装置１００は、移動端末３００へ応答を送信している途中で中断された通信セッションの情報がセッション情報テーブルに格納されていることを発見すると、応答を再開するか否かをユーザに選択させるＷｅｂページを、移動端末３００に送信する。ユーザは、そのＷｅｂページに表示されている「再取得する」ボタン、または「再取得しない」ボタンを押下する。
（５）登録完了ページ
ユーザが「再取得する」ボタンを押下すると、サーバ装置１００は、中断していたセッションの応答データ（登録が完了した旨を表示するＨＴＭＬ）を移動端末３００に送信する。移動端末３００は、その応答データを画面表示する。
（６）応答中止ページ
ユーザが「再取得しない」ボタンを押下すると、サーバ装置１００は、中断していたセッションを再開しない旨を通知するＷｅｂページを移動端末３００に送信する。移動端末３００は、そのＷｅｂページを画面表示する。
【００９６】
以上、本実施の形態４における画面遷移を説明した。次に、本実施の形態４におけるサーバ装置１００の動作について説明する。
【００９７】
図１０は、ユーザが図９（４）の画面で「再取得する」ボタンを押下したときのサーバ装置１００の動作フローである。以下、図１０の各ステップについて説明する。
【００９８】
（図１０：ステップＳ１０００）
ユーザが図９（４）の画面で「再取得する」ボタンを押下すると、移動端末３００は、中断していたセッションを再開すべき旨の要求を、サーバ装置１００に送信する。サーバ装置１００の送受信部１１０がその要求を受信すると、本動作フローが開始される。
【００９９】
（図１０：ステップＳ１００１）
送受信部１１０、クライアント特定部１２０、セッション管理部１４０は、図４のステップＳ４０２〜Ｓ４０５と同様の手順により、当該移動端末３００に対応するセッション情報をセッション情報テーブルから検索する。
【０１００】
（図１０：ステップＳ１００２）
当該移動端末３００に対応するセッション情報が存在する場合はステップＳ１００３へ進み、存在しない場合はステップＳ１００７へ進む。
【０１０１】
（図１０：ステップＳ１００３）
セッション管理部１４０は、セッション情報テーブルから取得したセッション情報に含まれる応答データを取得する。本ステップは、図４のステップＳ４０７に対応する。
【０１０２】
（図１０：ステップＳ１００４）
送受信部１１０は、セッション管理部１４０から応答データを受け取り、移動端末３００に送信する。本ステップは、図４のステップＳ４０８に対応する。
【０１０３】
（図１０：ステップＳ１００５）
送受信部１１０は、移動端末３００に応答データを送信することが成功したか否かを判定する。判定手法は、例えば図３のステップＳ３１２と同様でよい。応答データの送信に成功した場合は、ステップＳ１００６へ進む。失敗した場合は、そのまま本動作フローを終了する。この場合、移動端末３００のユーザは、図９（２）の画面から再度操作をやり直すことになる。
【０１０４】
（図１０：ステップＳ１００６）
セッション管理部１４０は、当該セッション情報をセッション情報テーブルから削除する。
【０１０５】
（図１０：ステップＳ１００７）
送受信部１１０は、再開するよう要求されたセッションを再開することができない旨のエラー通知Ｗｅｂページを、移動端末３００に送信する。
【０１０６】
図１１は、ユーザが図９（４）の画面で「再取得しない」ボタンを押下したときのサーバ装置１００の動作フローである。以下、図１１の各ステップについて説明する。
【０１０７】
（図１１：ステップＳ１１００）
ユーザが図９（４）の画面で「再取得しない」ボタンを押下すると、移動端末３００は、中断していたセッションの応答データを破棄すべき旨の要求を、サーバ装置１００に送信する。サーバ装置１００の送受信部１１０がその要求を受信すると、本動作フローが開始される。
【０１０８】
（図１１：ステップＳ１１０１）
本ステップは、図１０のステップＳ１００１と同様である。
【０１０９】
（図１１：ステップＳ１１０２）
当該移動端末３００に対応するセッション情報が存在する場合はステップＳ１１０３へ進み、存在しない場合はステップＳ１１０５へ進む。
【０１１０】
（図１１：ステップＳ１１０３）
セッション管理部１４０は、当該セッション情報をセッション情報テーブルから削除する。
【０１１１】
（図１１：ステップＳ１１０４）
送受信部１１０は、セッション情報をセッション情報テーブルから削除した旨を通知するＷｅｂページ（図９（６）のＷｅｂページ）を、移動端末３００に送信する。
【０１１２】
（図１１：ステップＳ１１０５）
送受信部１１０は、削除するよう要求されたセッション情報を削除することができない旨のエラー通知Ｗｅｂページを、移動端末３００に送信する。
【０１１３】
図１２は、ユーザが図９（３）の画面で「送信」ボタンを押下したときのサーバ装置１００の動作フローである。以下、図１２の各ステップについて説明する。
【０１１４】
（図１２：ステップＳ１２００）
ユーザが図９（３）の画面で「送信」ボタンを押下すると、移動端末３００は、ユーザが入力した情報をＨＴＴＰプロトコルでサーバ装置１００に送信する。送受信部１１０がそのＨＴＴＰクエリを受信すると、本動作フローが開始される。本ステップは、図４のステップＳ４０１に相当する。
【０１１５】
（図１２：ステップＳ１２０１）
送受信部１１０、クライアント特定部１２０、セッション管理部１４０は、図４のステップＳ４０２〜Ｓ４０５と同様の手順により、当該移動端末３００に対応するセッション情報をセッション情報テーブルから検索する。
【０１１６】
（図１２：ステップＳ１２０２）
当該移動端末３００に対応するセッション情報が存在しない場合はステップＳ１２０３へ進み、存在する場合はステップＳ１２０６へ進む。
【０１１７】
（図１２：ステップＳ１２０３）
送受信部１１０は、移動端末３００に応答データを送信する。
【０１１８】
（図１２：ステップＳ１２０４）
送受信部１１０は、応答データを移動端末３００に送信することが成功したか否かを判定する。成功した場合は本動作フローを終了し、失敗した場合はステップＳ１２０５へ進む。失敗した場合の動作は、図３のステップＳ３１１に相当する。
【０１１９】
（図１２：ステップＳ１２０５）
送受信部１１０、クライアント特定部１２０、セッション管理部１４０は、図３のステップＳ３１２〜Ｓ３１５と同様の手順により、セッション情報テーブルに当該通信セッションを特定する情報を格納する。
【０１２０】
（図１２：ステップＳ１２０６）
送受信部１１０は、先に中断したセッション応答を再開するか否かをユーザに選択させるＷｅｂページ（図９（４）のＷｅｂページ）を、移動端末３００に送信する。
【０１２１】
以上、本実施の形態４におけるサーバ装置１００の動作について説明した。
【０１２２】
以上のように、本実施の形態４によれば、サーバ装置１００は、応答途中で中断したセッションを再開するか否か、すなわち送信途中であった応答データを再取得するか否かをユーザに選択させるＷｅｂページを、移動端末３００に送信する。
【０１２３】
これにより、ユーザは、再取得した応答データが先に中断したセッションの応答データである旨を明示的に把握することができる。特に、応答データの中に次のＷｅｂページへのナビゲーションが含まれている場合には、画面の連続性をユーザが意識しつつ応答を再開することができるので、ユーザにとって便宜である。
【０１２４】
また、本実施の形態４によれば、図９（４）のＷｅｂページでユーザが「再取得しない」ボタンを押下したときは、セッション管理部１４０は該当するセッション情報をセッション情報テーブルから削除する。
【０１２５】
これにより、不要なセッション情報を早めに削除することになるので、移動端末３００は、サーバ装置１００にアクセスする度に図９（４）のＷｅｂページを表示する必要はなく、ユーザにとって便宜である。
【０１２６】
（実施の形態５）
以上の実施の形態１〜４では、ユーザがＷｅｂブラウザ上で「戻る」キーを押下して再度同じ入力用Ｗｅｂページで情報入力を行ったような場合を想定した動作を説明した。一方で、通信セッションが応答途中で遮断された場合、ユーザは必ずしも再度同じ入力用Ｗｅｂページで情報入力を行うとは限らない。他のＷｅｂページからサーバ装置１００にアクセスしたときに、中断していた応答データを返信すると、ユーザにとっては別のＷｅｂページに対する応答が画面表示されることになり、混乱してしまう可能性もある。
【０１２７】
そこで、本発明の実施の形態５では、クライアント毎に加えて画面毎にセッション情報を保持する構成と動作例を説明する。本実施の形態５に係るサーバ装置１００の構成は、セッション情報テーブルを除いて実施の形態１〜４と概ね同様であるため、以下では差異点を中心に説明する。
【０１２８】
図１３は、本実施の形態５におけるセッション情報テーブルの構成とデータ例を示す図である。本実施の形態５において、セッション情報テーブルは、図２で説明した各データに加えて新たに画面ＩＤ１３７を保持する。
【０１２９】
本実施の形態５において、サーバ装置１００の送受信部１１０は、図９（１）（３）の入力用Ｗｅｂページを移動端末３００に送信する際に、「送信」ボタンの部分へ、当該入力用Ｗｅｂページを識別する固有の画面ＩＤを埋め込んでおく。他の入力用Ｗｅｂページについても同様である。
【０１３０】
これにより、ユーザが「送信」ボタンを押下してサーバ装置１００に入力情報を送信する際に、入力情報とともに当該入力用Ｗｅｂページの画面ＩＤがサーバ装置１００へ送信されることになる。
【０１３１】
サーバ装置１００のセッション管理部１４０は、例えば図３のステップＳ３１５でセッション情報をセッション情報テーブルに格納する際に、上記画面ＩＤを画面ＩＤ１３７として格納しておく。
【０１３２】
セッション管理部１４０は、例えば図４のステップＳ４０５において、クライアントの識別情報に加えて画面ＩＤをキーにして、セッション情報テーブルを検索する。これにより、Ｗｅｂページ毎にセッション情報が検索されることになる。したがって、サーバ装置１００は、別のＷｅｂページについての応答データをクライアントに送信することはないので、誤った応答データを送信してユーザを混乱させてしまう心配はない。
【０１３３】
（実施の形態６）
実施の形態５では、入力用Ｗｅｂページに画面ＩＤを付与しておき、Ｗｅｂページ毎にセッション情報を格納する例を説明した。一方、入力用Ｗｅｂページが複数画面にまたがっている場合に上記の手法を採用すると、ユーザにとって操作が煩雑になる場合がある。
【０１３４】
本発明の実施の形態６では、入力用Ｗｅｂページが複数画面にまたがっている場合にユーザの操作が煩雑になる例と、その回避手法について説明する。なお、サーバ装置１００の構成は、実施の形態５と同様である。
【０１３５】
図１４は、入力用Ｗｅｂページが複数画面にまたがっている場合の画面遷移図である。同図に示す入力用Ｗｅｂページは、図１４（１）（２）が入力用、図１４（３）が登録前確認用、図１４（４）が登録完了通知用のＷｅｂページである。各Ｗｅｂページでユーザが「次へ」ボタンや「登録」ボタンを押下すると、次の画面へ遷移する。
【０１３６】
ここで、ユーザが図１４（２）で「次へ」を押下した後、移動端末３００が図１４（３）のＷｅｂページを取得する前に通信セッションが遮断された場合を想定する。図１４（１）〜（４）それぞれについて異なる画面ＩＤを付与していた場合、ユーザが図１４（１）から改めて情報入力を行うと、図１４（２）から図１４（３）へ画面遷移する時点に達するまで、セッション情報テーブルの検索は行われないことになる。
【０１３７】
そこで、本実施の形態６に係るサーバ装置１００は、図１４のように複数画面にまたがる入力用Ｗｅｂページについては、各Ｗｅｂページを一体とみなし、同一の画面ＩＤを付与する。
【０１３８】
これにより、ユーザが図１４（１）から改めて情報入力を行おうとしたとき、その画面ＩＤを用いてセッション情報テーブルが検索され、図１４（３）のＷｅｂページが応答データとして移動端末３００に送信されることになる。したがって、ユーザは同じ情報入力操作を何度も繰り返す必要がなく、セッションを再開する効果を十分に発揮することができる。
【０１３９】
以上のように、本実施の形態６によれば、サーバ装置１００は、入力用Ｗｅｂページをクライアントに送信する際に、複数の画面にまたがる入力用Ｗｅｂページについては同一の画面ＩＤを付与しておく。
【０１４０】
これにより、入力の途中で通信セッションが遮断され、ユーザが最初の入力用Ｗｅｂページから改めて入力を再開しようとした場合でも、入力途中のＷｅｂページが応答データとしてクライアントに戻されることになる。したがって、ユーザは改めて全ての入力用Ｗｅｂページについて情報入力をやり直さなくて済むので、ユーザの操作負担を軽減することができる。
【０１４１】
（実施の形態７）
以上の実施の形態１〜４において、同一のクライアントについて複数のセッション情報がセッション情報テーブルに格納されている場合、セッション管理部１４０は、古いセッション情報から順にクライアントへ送信する。セッションの到着順に応答データを返信するためである。
【０１４２】
同様に、実施の形態５〜６において、同一のクライアントおよび同一の画面ＩＤについて複数のセッション情報がセッション情報テーブルに格納されている場合、セッション管理部１４０は、古いセッション情報から順にクライアントへ送信する。
【０１４３】
（実施の形態８）
以上の実施の形態１〜７では、クライアントは、サーバ装置１００にアクセスする毎にログインＩＤなどの認証情報をサーバ装置１００へ送信することを説明した。これは、Ｃｏｏｋｉｅを保持することができない携帯電話端末のように、セッション識別子を保持する手段のないクライアントを想定したものである。
【０１４４】
一方、クライアントがセッション識別子を保持することができる場合は、サーバ装置１００にアクセスする毎に認証情報をサーバ装置１００へ送信する必要はなく、これに代えてサーバ装置１００に付与されたセッション識別子を送信すればよい。サーバ装置１００では、クライアントにセッション識別子を付与する際に、セッション識別子とログインＩＤの対応関係を記憶しておく。
【０１４５】
クライアントがサーバ装置１００にアクセスした際、クライアント特定部１２０は、クライアントが送信してきたセッション識別子とログインＩＤの対応関係を用いて、そのクライアントを識別することができる。セッション管理部１４０は、そのログインＩＤをセッション情報テーブルに格納する。
【０１４６】
（実施の形態９）
以上の実施の形態１〜８では、主にクライアントとして移動端末３００のＷｅｂブラウザ用いた動作を説明したが、クライアントを一意に特定することができれば、クライアントの種類は問わない。
【０１４７】
また、以上の実施の形態１〜８では、サーバ装置１００はＷｅｂアプリケーションを提供することを説明したが、クライアントを一意に特定して通信セッションを維持するアプリケーションであれば、Ｗｅｂアプリケーション以外についても本発明の手法を適用することができる。例えば、クライアント／サーバ型のアプリケーションが考えられる。
【０１４８】
この場合、要求元端末ＩＤ１３２は、クライアントアプリケーションが通信パケット内に格納しておくようにするとよい。
【符号の説明】
【０１４９】
１００：サーバ装置、１１０：送受信部、１２０：クライアント特定部、１３０：セッションＤＢ、１３１：セッションＩＤ、１３２：要求元端末ＩＤ、１３３：要求元ＩＰアドレス、１３４：要求元ログインＩＤ、１３５：発行時刻、１３６：応答データ、１３７：画面ＩＤ、１４０：セッション管理部、１５０：クライアント認証部、２００：基地局、３００ａ、３００ｂ、３００ｃ：移動端末、４００：ＰＣ、５００：インターネット。
【図１】
2010273045.tif 000003
【図２】
2010273045.tif 000004
【図３】
2010273045.tif 000005
【図４】
2010273045.tif 000006
【図５】
2010273045.tif 000007
【図６】
2010273045.tif 000008
【図７】
2010273045.tif 000009
【図８】
2010273045.tif 000010
【図９】
2010273045.tif 000011
【図１０】
2010273045.tif 000012
【図１１】
2010273045.tif 000013
【図１２】
2010273045.tif 000014
【図１３】
2010273045.tif 000015
【図１４】
2010273045.tif 000016