JP2006309595A - ネットワークシステム、情報処理装置、及び通信制御方法 - Google Patents

Abstract

【課題】 Ｗｅｂサービスに係るクライアントとウェブサーバとの間でのデータ転送が中断した場合に、サーバのリソースを効率良く利用できるようにするとともに、データ転送効率を向上させる。
【解決手段】 処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、端末から送信された複数の処理情報に基づいて処理を実行して得られた応答を端末に送信するウェブサーバと、端末とウェブサーバとの間の通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを備え、端末とウェブサーバとの間の通信セッションが中断した場合には、中断した通信セッションの状態を示すセッション状態情報を生成してセッション状態保持手段に登録するとともに、中断したセッションをウェブサーバが強制的に終了しそれに関連する内部リソースを解放する。
【選択図】 図２

Description

本発明は、ネットワークシステム、情報処理装置、及び通信制御方法に関し、特に、クライアントからの要求に応じたウェブ（Ｗｅｂ）サービスを提供するサービス提供システムに用いて好適なものである。

近年、インターネットの普及に加え、ＸＭＬ（eXtensible Markup Language）技術の持つ高い拡張性を利用した電子商取引（ＥＣ）などが活発化しており、インターネット標準の各種Ｗｅｂプロトコルやマークアップ言語を利用して、インターネットをベースとする分散コンポーネント環境を実現するＷｅｂサービスが台頭してきている。

Ｗｅｂサービスは、サービスを利用するクライアントが処理情報を送信し、送信された処理情報に基づいてサービスを提供するサーバが処理を実行して得られた応答をクライアントに返すという処理を行うものである。Ｗｅｂサービスでは、データアクセスプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を使用している。ＳＯＡＰバージョン１．０では、実際のデータの送受信に使う下位プロトコルとして、Ｗｅｂと同じＨＴＴＰ（Hyper Text Transfer Protocol）を利用する。

ここでＨＴＴＰは、インターネットやイントラネットなどのネットワークを介したデータ通信にて最も広く普及しているプロトコルの１つであり、安全性確保のためにファイアウォールが設置されているような場合でも、このＨＴＴＰだけは特別な措置を行わずとも常に利用できる可能性が高い。例えば、ＨＴＴＰのＰＯＳＴメソッドを使って、アクセスしたいオブジェクトを表すＸＭＬデータを送ると、そのＨＴＴＰリクエストに対するレスポンス（応答）として目的のデータを含むＸＭＬデータが送り返されてくる。ここで、データ形式にＸＭＬを利用することにより、特定のフォーマットにとらわれない、柔軟で汎用性が高いデータアクセス機能を提供している。

Ｗｅｂサ−ビスにおいては、外部とのインターフェイスとしてＸＭＬの技術を全面的に採用することにより、人間を介することなくＷｅｂサービスが他のＷｅｂサービスとやり取りすることを可能にしている。Ｗｅｂサービスは、上述のような技術的な背景を基礎として、ビジネス文書管理、メッセージング、データベース、及びＭＦＰ（Multi-Function Peripheral）など多岐にわたり利用されている。

特開２００１−３０６５１２号公報

ところで、Ｗｅｂサービスを利用して画像データなどの大容量のデータを転送中に、通信路上の予期せぬ障害やサービスを提供するサーバ側のパフォーマンス障害などに起因してデータ転送（セッション）が中断してしまうことがある。この場合、データを受信するサーバは、通信セッションの復帰に備えて、内部リソースを解放せずに通信再開を待つ。そのため、この間サーバのリソースが不足し、パフォーマンスが低下したり、他の新規セッションの確立ができなくなったりしてしまうといった不都合が生じる。

また、Ｗｅｂサービスを利用するサービスリクエスタであるクライアントは、中断したセッションを再開するときにＷｅｂサービスに対して既に転送したデータのサイズ（データ量）や信頼性が保証できず、最初からすべてのデータ転送を行わなければならない場合があり、データの転送効率が低下するという問題がある。特に、転送するデータが画像データのような大量データである場合には、このような問題が顕在化する。

ところで、上記特許文献１によれば、Ｗｅｂサービスに係るシステムダウン後の回復処理に関して、クライアントから送信された複数の処理情報をサーバ側で保持しておき、システム復帰時に順次実行することでクライアントからの冗長な情報の送信を防ぐ方法が提案されている。この提案は、システム復帰時に、サーバ側で既に受け取った処理情報に基づく処理を再開する方法に注目しており、クライアント側がどこから情報を転送すれば良いかといった判断に対処する仕組みが不明である。したがって、クライアントは、システムダウン時にサーバ側でどこまで正しく情報を受け取れたかわからず、データの転送を効率的に再開することが困難である。

本発明は、このような事情に鑑みてなされたものであり、Ｗｅｂサービスを利用するクライアントとＷｅｂサービスを提供するサーバとの間におけるデータ転送（通信セッション）が中断した場合に、サーバのリソースを効率良く利用できるようにするとともに、データ転送効率を向上させることを目的とする。

本発明のネットワークシステムは、処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、上記端末から送信された複数の処理情報に基づいて処理を実行し、得られた応答を上記端末に送信するウェブサーバと、上記端末及び上記ウェブサーバに通信可能に接続され、上記端末と上記ウェブサーバとの間の通信セッションが中断した場合に、当該中断した通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを備えることを特徴とする。
本発明の情報処理装置は、所定の処理を実行させるための複数の処理情報を送信する端末と、当該送信された複数の処理情報に基づいて処理を実行して得られた応答を上記端末に送信するウェブサーバとに通信可能に接続された情報処理装置であって、上記ウェブサーバから送信される、上記端末と上記ウェブサーバとの間の通信セッションに係るセッション状態情報を受信する受信手段と、上記受信手段により受信した上記セッション状態情報を記憶する情報記憶手段と、上記情報記憶手段に記憶したセッション状態情報を上記端末に送信する送信手段とを備えることを特徴とする。
また、本発明の情報処理装置は、所定の処理を実行させるための複数の処理情報を送信する端末に通信可能に接続され、当該送信された複数の処理情報に基づいて処理を実行して得られた応答を上記端末に送信する情報処理装置であって、上記端末との通信セッションが中断した場合に、当該中断した通信セッションに係るセッション状態情報を生成する情報生成手段と、上記情報生成手段により生成したセッション状態情報を、通信可能に接続されるセッション状態保持手段に送信し登録する情報登録手段と、上記端末から送信されるセッション状態情報に基づいて、上記端末との通信セッションを再開するか否かを判定する再開判定手段とを備えることを特徴とする。
また、本発明の情報処理装置は、受信する処理情報に基づいて処理を実行し得られる応答を返すウェブサーバに通信可能に接続され、当該ウェブサーバに所定の処理を実行させるための複数の処理情報を送信する情報処理装置であって、上記ウェブサーバとの間の中断された通信セッションを再開する場合に、当該中断された通信セッションに係るセッション状態情報を取得する情報取得手段と、上記情報取得手段により取得したセッション状態情報に基づいて、上記ウェブサーバにて中断前に受信されている処理情報を除く処理情報を上記ウェブサーバに送信する送信手段とを備えることを特徴とする。
本発明の通信制御方法は、処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、上記端末から送信された複数の処理情報に基づいて処理を実行し、得られた応答を上記端末に送信するウェブサーバと、上記端末及び上記ウェブサーバに通信可能に接続され、上記端末と上記ウェブサーバとの間の通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを有するネットワークシステムの通信制御方法であって、上記端末と上記ウェブサーバとの間の通信セッションが中断した場合に、当該通信セッションのセッション状態情報を上記ウェブサーバが上記セッション状態保持手段に登録する情報登録ステップと、上記中断された通信セッションを再開するために、上記セッション状態保持手段に登録された上記セッション状態情報を上記端末が取得する情報取得ステップと、上記取得したセッション状態情報の内容に基づいて、上記端末が上記ウェブサーバにアクセスし通信セッションの再開を要求する再開要求ステップと、上記再開要求に対し、上記セッション状態情報の内容に基づいて上記ウェブサーバが上記端末との通信セッションの再開判定を行う再開許可ステップとを有することを特徴とする。
本発明のプログラムは、上記通信制御方法の各ステップをコンピュータに実行させることを特徴とする。本発明のコンピュータ読み取り可能な記録媒体は、上記プログラムを記録したことを特徴とする。

本発明によれば、端末とウェブサーバとの間の通信セッションが中断した場合には、ウェブサーバが、セッション状態情報として、中断した通信セッションの状態をセッション状態保持手段に保存するので、通信再開を待つことなくウェブサーバ側から自発的に通信セッションを終了してリソースを解放することが可能となる。したがって、通信セッションが中断してもウェブサーバのリソースを効率良く利用することができ、パフォーマンスの低下を防止することができる。また、通信セッションを再開する際には、保存されたセッション状態情報により中断時の通信セッション状態を知ることができ、最初からすべての処理情報を転送し直す必要がなく、未送信の処理情報のみを送信すればよいので、従来と比較して転送効率を向上させることができる。

以下、本発明の実施形態を図面に基づいて説明する。
図１は、本発明の実施形態によるネットワークシステムを適用したＷｅｂサービス提供システムの構成例を示すブロック図である。図１に示すように、本実施形態におけるＷｅｂサービス提供システムは、Ｗｅｂサービスを利用するクライアント端末（以下、単に「クライアント」とも称す。）１００、Ｗｅｂサービスを提供するＷｅｂサーバ（Ｗｅｂサービス提供装置）２００、及びクライアント１００とＷｅｂサーバ２００との間のセッションに係る情報（セッション状態情報）を保持するセッション状態保持手段３００を有する。

クライアント１００は、利用者からの要求を受け付けるためのインターフェイスを有しており、利用者からの要求に応じた処理情報をＷｅｂサービスを提供する側に対して発行するコンピュータ（ＰＣ）である。具体的には、クライアント１００は、利用者からの要求に応じた処理を実行させるための複数の処理情報をＷｅｂサーバ２００に送信し、その処理を実行して得られるＷｅｂサーバ２００からの応答を受信する。

クライアント１００は、通信制御部１０１、セッション状態情報取得部１０２、及びセッション状態情報解析部１０３を有する。通信制御部１０１は、Ｗｅｂサーバ２００との間で行うデータ通信を制御する。例えば、通信制御部１０１は、セッションの確立処理、及び処理情報（データ及びコマンド等）の送信や応答の受信を行い、Ｗｅｂサーバ２００に対するデータ送受信を統括的に制御する。

セッション状態情報取得部１０２は、Ｗｅｂサーバ２００との間の中断されたセッションを再開する場合に、セッション状態保持手段３００からセッション状態情報を取得する。セッション状態情報解析部１０３は、セッション状態情報取得部１０２により取得したセッション状態情報に基づいて、中断されたセッションの状態（中断前に転送済みとなっている処理情報の量等）を解析する。Ｗｅｂサーバ２００との間の中断されたセッションを再開する場合には、クライアント１００は、セッション状態情報解析部１０３での解析結果に従って、中断前に実行済みのセッションに係る動作は行わずに中断時以降に実行すべき動作のみを継続して実行するように、すなわち転送済みでない（未転送の）処理情報のみを送信するように制御される。

Ｗｅｂサーバ２００は、クライアント１００から送信された処理情報を受け、当該処理情報に基づき処理を実行して得られた応答をクライアント１００に返すコンピュータである。Ｗｅｂサーバ２００は、通信制御部２０１、処理実行部２０２、セッション状態判定部２０３、セッション状態情報生成登録部２０４、及びセッション再開判定部２０５を有する。

通信制御部２０１は、セッションの確立処理、及び処理情報（データ及びコマンド等）の受信や応答の送信を行い、クライアント１００との間で行うデータ通信を統括的に制御する。処理実行部２０２は、通信制御部２０１で受信した処理情報に基づいて処理を実行し、その処理により得られた応答を出力する。

セッション状態判定部２０３は、通信制御部２０１とクライアント１００（詳細にはその通信制御部１０１）との間でのデータ転送動作を基に、そのセッションが中断しているか否かを判定する。セッション状態情報生成登録部２０４は、セッション状態判定部２０３によりセッションが中断していると判定された場合に、このセッションに係るセッション状態情報を生成してセッション状態保持手段３００に送信し登録する。

セッション再開判定部２０５は、通信制御部２０１を介して供給されるクライアント１００からのセッション状態情報に基づいて、クライアント１００とのセッションを再開するか否かを判定する。セッション再開判定部２０５は、セッション状態情報に施された電子署名等の認証情報を検証する検証部２０６を有する。

本実施形態では、一例としてＷｅｂサーバ２００は、ネットワークに接続しＷｅｂサービス機能を有するＭＦＰ（Multi-Function Peripheral）とする。このＭＦＰは、Ｗｅｂサ−ビスとして印刷サービスやスキャンサービスを利用者に提供可能に構成されている。

例えば、利用者がＭＦＰの印刷サービスを利用する場合には、利用者はクライアント１００において文書を作成したアプリケーション上から当該文書の印刷指定を行う。クライアント１００は、文書のフォーム情報や利用者が指定する印刷仕様に基づいて、最適な印刷サービス（ＭＦＰ）を検索して利用者に対し通知する。利用者が所定のＭＦＰに対して印刷実行を指示すると、クライアント１００は印刷のためのデータを生成し、ＸＭＬ／ＳＯＡＰに基づいて当該データをＭＦＰの印刷サービスに転送する。ＭＦＰの印刷サービスは、受信したデータをそのデータ構造に基づいて解析し、所定のＰＤＬ（Printer Description Language）言語に従って印刷を実行する。

また、利用者がＭＦＰのスキャンサービスを利用する場合には、クライアント１００は、スキャンした画像データを保管しておく文書管理サーバとなる。利用者は、ＭＦＰのフィーダ或いはＢｏｏｋスキャナに原稿（文書等）をセットしてスキャンを実行させる。ＭＦＰは、画像をデータとして取り込み、当該データを文書管理サーバに転送する。文書管理サーバに対するアクセスは、利用者の権限で実行され、データの格納先の指定などもすべてＭＦＰ上から実行可能となっている。文書管理サーバに対する諸属性の指定等は、すべてＸＭＬ／ＳＯＡＰベースで行われる。

ところで、本実施形態におけるＭＦＰ（Ｗｅｂサーバ２００）は、通信機能としてＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＩＰ（Internet Protocol）プロトコルスタックを備え、その上位層にＳＳＬ（Secure Socket Layer）を備えている。ＳＳＬは通信路上のデータの機密性や完全性を保証するために必要である。データ送受信処理は、その上位層にＨＴＴＰ／１．１（Hypertext Transfer Protocol）を備える。

また、ＳＯＡＰ処理は、アプリケーションが利用する処理モジュールの関数名及びその引数に対応するＳＯＡＰエンベロープを生成し、メモリ上にＸＭＬデータを書き出す。また、受信の際にはＳＯＡＰレスポンスを解析して対応する処理の返り値を生成し、内部処理モジュールにマッピングし、該内部処理モジュールを呼び出す機能を備える。これら階層の最上位層にＭＦＰ上で機能する各種ネットワークアプリケーションが実装される。アプリケーションは複数実装することが可能であり、一部のアプリケーションは、プリンタコントローラ処理との通信機能を備える。

セッション状態保持手段３００は、クライアント１００とＷｅｂサーバ２００とのセッションが中断した場合に、中断したセッションに係るセッション状態情報をＷｅｂサーバ２００から受け取って保持する。複数のセッションがあった場合には、中断したセッション毎にそれに関するセッション状態情報が保持される。セッション状態保持手段３００は、状態情報記憶部３０１及び認証情報生成部３０２を有する。状態情報記憶部３０１は、Ｗｅｂサーバ２００から送信されるセッション状態情報を受信して記憶するとともに、記憶したセッション状態情報をクライアント１００に提供する。認証情報生成部３０２は、状態情報記憶部３０１に記憶されるセッション状態情報に電子署名などの認証情報を付加する。

ここで、セッションとは、クライアント１００とＷｅｂサーバ２００との間で確立した通信セッションのことであり、クライアント１００とＷｅｂサーバ２００は所定の処理要求のために互いにセッションを構築し、その処理が完了するとセッション状態を解消する。Ｗｅｂサーバ２００は、セッションを生成するために必要なメモリリソースを確保し、クライアント１００からの要求に応答しなければならない（リクエストに対するレスポンスを返さなければならない）。一般には正常に処理が完了するまでは、クライアント１００とＷｅｂサーバ２００との通信（セッション）が途中で中断しても、Ｗｅｂサーバ２００側からメモリリソースを解放することはない。

通信セッションには、セッションを確立した装置同士が何であるか、どのリクエストに対する通信セッションであるかといったセッションを一意に特定するための情報がそれぞれ割り当てられる。これをセッション情報と呼ぶ。セッション情報は、クライアント１００及びＷｅｂサーバ２００を一意に特定する情報、例えばＭＡＣ（Media Access Control）アドレスやＩＰアドレスなどの識別子、及びその時の通信セッションを特定するための時刻情報やシリアル番号情報などによって構成される。

ここで、本実施形態において中断したセッションを再開する場合には、クライアント１００はセッション状態保持手段３００から再開するセッションに係るセッション状態情報を受け取る。セッション状態保持手段３００に保持されるセッション状態情報には、クライアント１００とＷｅｂサーバ２００との間で確立していたセッションに関するセッション情報（第１の情報）に加えて、送受信される処理情報（データ並びにコマンド）に関する情報（第２の情報）が含まれる。第２の情報は、例えば受信したＰＤＬデータサイズなどの処理情報の転送状態（容量など）の情報である。

したがって、クライアント１００は、セッション情報を指定して関連するセッション状態情報をセッション状態保持手段３００から得ることにより、Ｗｅｂサーバ２００がセッションを中断した時のセッション状態を知ることができる。また、これとは逆に、クライアント１００がセッション状態保持手段３００にアクセスした時に、セッション状態保持手段３００がクライアント１００に関連する中断セッションを検索し、検索結果として得られたセッション状態情報を自動的に通知するようにしても良い。

次に、本実施形態におけるＷｅｂサービス提供システムでの処理動作について図２を参照して説明する。図２は、本実施形態におけるＷｅｂサービス提供システムでの処理の流れを示すフローチャートであり、ネットワークの障害等により通信セッションが中断された場合に、Ｗｅｂサービスを提供するＷｅｂサーバ２００がその通信セッションを明示的に終了するときの処理についても図示している。

ステップＳ２０１は、クライアント１００とＷｅｂサーバ２００との通信セッションを確立する工程である。例えば、Ｗｅｂサービスを提供するＷｅｂサーバ２００としてのＭＦＰの印刷サービスを利用者が利用するためにクライアント１００から印刷データを送信する処理を実行したとき、この通信セッションの確立工程（Ｓ２０１）にてクライアント１００とＷｅｂサーバ２００との通信セッションが構築される。

通信セッションが確立するとステップＳ２０２に進み、クライアント１００からＷｅｂサーバ２００に印刷データを送信する工程が実行される。この工程では、印刷サービスを実行するために必要な印刷データや印刷属性などがＸＭＬ／ＳＯＡＰベースでＷｅｂサーバ２００に送信される。

データの送信工程（Ｓ２０２）は、所定のパケット毎に区切られて実施され、このとき、あわせてセッションが中断したか否かの判定がＷｅｂサーバ２００内のセッション状態判定部２０３にて行われる（Ｓ２０３）。このステップＳ２０３でのセッションの中断判定にて偽（ＮＯ）となった場合には、次に、すべてのデータ及びコマンドの転送が完了したか否かの判定（転送終了判定）が行われる（Ｓ２０８）。

ステップＳ２０８での転送終了判定の結果、データ転送が未完了、すなわち転送するデータがまだ残っている場合には、ステップＳ２０２に戻り、データ及びコマンドの転送工程（Ｓ２０２）が再び実行される。一方、すべてのデータ及びコマンドの転送が完了し、ステップＳ２０８での転送終了判定が真（ＹＥＳ）となった場合には、Ｗｅｂサーバ２００へのデータ転送は中断することなく完了したこととなり、Ｗｅｂサービスに係るデータ及びコマンドの転送を終了する。

一方、ステップＳ２０３でのセッションの中断判定で中断を検出して真（ＹＥＳ）となった場合には、Ｗｅｂサービスでの処理はステップＳ２０４へ移行する。ステップＳ２０４は、Ｗｅｂサーバ２００内のセッション状態情報生成登録部２０４が、データの転送が停止し通信セッションが中断したときのセッション状態情報を生成する工程である。セッション状態情報には、上述したようにクライアント１００とＷｅｂサーバ２００とに係るセッション情報に加え、例えば、Ｗｅｂサーバ２００がクライアント１００から既に受信したＰＤＬデータのサイズやデータを特定するアドレス情報などが含まれる。このセッション状態情報は、セッション状態情報生成工程（Ｓ２０４）においてＷｅｂサーバ２００内の所定の記憶領域に生成され一次的に保持される。

次に、Ｗｅｂサーバ２００は、ステップＳ２０４において生成したセッション状態情報をセッション状態保持手段３００に通知するために、ネットワークを介してセッション状態保持手段３００に接続する（Ｓ２０５）。この接続もＸＭＬ／ＳＯＡＰベースで行われる。続いて、Ｗｅｂサーバ２００は、先に生成し記憶領域に一時的に保持しておいたセッション状態情報を、ネットワークを介してセッション状態保持手段３００に送信し登録する（Ｓ２０６）。

Ｗｅｂサーバ２００は、セッション状態保持手段３００へのセッション状態情報の登録（Ｓ２０６）が完了した後、直ちにデータ転送が停止し中断しているセッションを強制的に終了し、関連するメモリリソースを解放する（Ｓ２０７）。これにより、Ｗｅｂサーバ２００は、次に要求される他の通信セッションの確立に備えてメモリリソースを有効に使うことが可能となる。

以上のようにして、中断したセッションに係るセッション状態情報は、例えば他のサーバにより構成されるセッション状態保持手段３００により安全かつ確実に保存されることになる。したがって、クライアント１００は、Ｗｅｂサーバ２００との通信が良好に行えなくとも、Ｗｅｂサーバ２００との間で確立した後に中断したセッションの状態を、それに係るセッション状態情報が保存されているセッション状態保持手段３００を介して知ることが可能となる。

セッション状態保持手段３００に保持されたセッション状態情報は、原則として、中断したセッションが再開し、Ｗｅｂサービスに係るリクエスト・レスポンスに必要なすべてのデータの送受信が完了するまで保持される。しかし、セッション状態保持手段３００の記憶領域にも制限があるので、所定の期間経過しても中断したセッションが正常に再開しない場合にはそのセッション状態情報を自動的に破棄するようにしても良い。

なお、上述したステップＳ２０３にて実行される、クライアント１００とＷｅｂサーバ２００との間の通信セッションが中断しているか否かを判定する工程は、Ｗｅｂサーバ２００に具備しているタイマを利用して実現する。つまり、Ｗｅｂサーバ２００内のセッション状態判定部２０３は、クライアント１００とのデータ転送が中断したときからタイマをカウントし始め、予め設定したカウント値に達してもデータ転送が再開されていない場合には、セッションが中断したと判定する。このタイマのカウント値は、ステップＳ２０３の判定工程を経るたびに初期値にクリアされる。

次に、本実施形態におけるＷｅｂサービス提供システムでのセッションの再開処理について図３を参照して説明する。図３は、中断したクライアント１００とＷｅｂサーバ２００との通信セッションの再開処理の流れを示すフローチャートである。

通信セッションが途中で中断した場合、クライアント１００は、Ｗｅｂサーバ２００に対する要求が完了していないと認識し、所定時間経過後にあらためてＷｅｂサーバ２００とのセッションの確立を試みる。このセッションの確立を試みるときに、図３に示す処理工程が実行される。

ステップＳ３０１にて、クライアント１００は、Ｗｅｂサーバ２００に対する接続を試みる前に、先ずセッション状態保持手段３００に接続する。そして、クライアント１００は、セッション状態保持手段３００から上記図２に示したようにしてＷｅｂサーバ２００により予め登録されたセッション状態情報を取得する（Ｓ３０２）。セッション状態保持手段３００とクライアント１００との通信は、やはりＸＭＬ／ＳＯＡＰに基づいて実施される。

セッション状態保持手段３００は、クライアント１００との通信セッションを構築することで、以前に中断したセッションがあることやクライアント１００の固有情報（例えばＭＡＣアドレスやＩＰアドレスなど）を知ることが可能である。そこで、これらの固有情報等を基に、セッション状態保持手段３００は、状態情報記憶部３０１に保持されているセッション状態情報を検索し、検索結果をクライアント１００に伝える。

当該セッション状態情報には、上述したように中断する前のクライアント１００とＷｅｂサーバ２００のセッションに関する情報、例えばセッションＩＤやクライアントの識別情報、セッションを確立した時刻情報などが含まれる。さらに加えて、セッションが中断するまでにクライアント１００からＷｅｂサーバ２００に送信されたデータサイズに関する情報も含まれる。

なお、上述した説明では、クライアント１００とＷｅｂサーバ２００の間の中断したセッションを再開するために、クライアント１００が最初にセッション状態保持手段３００にアクセスする場合を一例として説明しているが、以下のように逆にすることも可能である。すなわち、セッション状態保持手段３００が、Ｗｅｂサーバ２００から受け取ったセッション状態情報を保持した後、自らがクライアント１００に対してセッションの確立を試みる方式である。この場合には、クライアント１００がＷｅｂサービス機能を併せ持っていることが構成条件として必要であることは言うまでもない。

セッション状態保持手段３００からクライアント１００にアクセスして（セッションの確立を試みて）セッション状態情報を通知する場合には、その通信経路が当初の経路であるクライアント１００−Ｗｅｂサーバ２００間の通信経路とは異なるため、通信経路に依存した通信障害の影響を受けないという利点がある。さらに、中断したセッションを再開するために、クライアント１００が定期的にセッション状態保持手段３００にポーリングを行うといった処理も不要となる。

ステップＳ３０３にて、クライアント１００は、ステップＳ３０２において取得したセッション状態情報を基に送信済みの処理情報（データ及びコマンドの内容）を分析する。具体的には、クライアント１００は、取得したセッション状態情報を基にＷｅｂサーバ２００にすでに転送済みのデータ及びコマンドの種類を識別し、セッションが再開したときに転送するデータ及びコマンドを生成する。

上述したステップＳ３０１〜Ｓ３０３の処理の完了後、クライアント１００は、Ｗｅｂサーバ２００への接続を試みる（Ｓ３０４）。このステップＳ３０４でのＷｅｂサーバ２００への接続は、先にセッションを中断させた原因が未だに解消されていないこともあるため、所定のタイムアウト値を設けて接続を試みる。

そして、ステップＳ３０５にて、クライアント１００は、Ｗｅｂサーバ２００に接続できたか否かを判定する。この判定の結果、Ｗｅｂサーバ２００への接続がまだ不可の場合にはステップＳ３０６に移行し、一方、セッションを中断させた原因が既に解消されＷｅｂサーバ２００への接続ができた場合にはステップＳ３０７に移行する。

ステップＳ３０６は、接続処理を一定時間ウエイトする工程である。ウエイト値はクライアント１００側で利用者が任意に設定することが可能である。この工程は、先にセッション中断の原因が直ちに解消されない場合に、クライアント１００が連続的にＷｅｂサービス１０１に再接続を試みることによってクライアント１００の処理パフォーマンスが低下することを防ぐ効果がある。

ステップＳ３０７は、クライアント１００が、Ｗｅｂサーバ２００に再接続できた後、Ｗｅｂサーバ２００に対して認証トークンを送信する工程である。ここで、認証トークンとは、ステップＳ３０２においてクライアント１００がセッション状態保持手段３００から取得したセッション状態情報に含まれる情報であって、セッションの中断が起こる前にクライアント１００がＷｅｂサーバ２００との間にセッションを保持していたことを証明するものである。中断されたセッションの再開にあたっては、Ｗｅｂサーバ２００が先にセッションを維持していたクライアント１００であることを認識するために、Ｗｅｂサーバ２００により利用される。

認証トークンは、セッション状態保持手段３００内の認証情報生成部３０２によって予め生成され、クライアント１００が独自に改変できないようセッション状態保持手段３００により電子署名が施されている。クライアント１００は、取得したセッション状態情報の中から当該認証トークンを取り出し、それをステップＳ３０７の処理でＷｅｂサーバ２００に転送する。Ｗｅｂサーバ２００は、クライアント１００から認証トークンを受け取ると当該認証トークンの電子署名を検証する（Ｓ３０８）。なお、認証トークンの電子署名は、既知のデジタル証明書を利用した署名と検証方法が利用される。

また、認証トークンの完全性を確認するために、Ｗｅｂサーバ２００がセッション状態保持手段３００に当該認証トークンを渡して検証する方法もある。この場合には、セッション状態保持手段３００の公開鍵暗号方式に基づく秘密鍵で認証トークンを署名し、セッション状態保持手段３００の公開鍵で検証することができる。

ステップＳ３０８での検証の結果、Ｗｅｂサーバ２００において認証トークンが改ざんされていないことが証明されると、Ｗｅｂサーバ２００はクライアント１００を信頼することが可能となり、ここにおいて先に中断したセッションを再開することが可能となる（Ｓ３０９）。そして、ステップＳ３１０にて、クライアント１００はＷｅｂサーバ２００との間のセッションを再開し、未転送の処理情報（データ及びコマンド）をＷｅｂサーバ２００に転送する。

一方、ステップＳ３０８での検証の結果、認証トークンの署名検証が失敗してＷｅｂサーバ２００がクライアント１００を信頼することができない場合には、Ｗｅｂサーバ２００はクライアント１００からのセッション再開要求を受け付けずに終了する。

なお、セッション状態保持手段３００が認証トークンを生成する場合に、認証トークンにトークンの発行時刻情報を合わせて入れることで、クライアント１００とＷｅｂサーバ２００との間で送受信される認証トークンのいわゆるリプレイ攻撃に対処することが可能である。認証トークンの検証を行う時に当該時刻情報を参照して時刻のずれが著しい場合にはリプレイ攻撃を受けているおそれがあるので、Ｗｅｂサーバ２００はクライアント１００からのセッション再開要求を拒否するようにすればよい。時刻のずれは予めＷｅｂサーバ２００側で設定するようにしてもよい。

また、デジタル証明書を利用しないで、セッション状態保持手段３００の独自の公開鍵及び秘密鍵を利用した署名を行う場合には、セッション状態保持手段３００が時刻のずれを判定し、Ｗｅｂサーバ２００に結果を返答する流れになる。このため、時刻のずれに対する許容値の設定はセッション状態保持手段３００に対して行うことになる。

以上説明したようにして中断されたセッションが再開し、残りのデータ（未転送の処理情報）が正しく転送されると、セッション状態保持手段３００に保持されているセッション状態情報はもはや不要となる。セッション状態保持手段３００は、Ｗｅｂサーバ２００からセッションが正常に再開しデータ転送が完了したことを、ＸＭＬ／ＳＯＡＰベースの通信によって通知される。この通知を受けた時点で、セッション状態保持手段３００は当該セッションに係るセッション状態情報を廃棄する。どのセッション状態情報を破棄するかは、Ｗｅｂサーバ２００からの通知により、ＭＡＣアドレスやＩＰアドレス情報等に基づいて知ることができるので、これらの情報を基にセッション状態情報を検索して破棄する。

図４は、本実施形態におけるＷｅｂサービス提供システムでのセッション（通常）の処理シーケンスの一例を示す図である。
まず、Ｗｅｂサーバ２００により提供されるＷｅｂサービスを利用するためにクライアント１００からＷｅｂサーバ２００に対して通信セッションの確立要求がなされる（Ｐ４０１）と、クライアント１００及びＷｅｂサーバ２００にて所定の処理が行われ、クライアント１００とＷｅｂサーバ２００との通信セッションが確立（構築）される（Ｐ４０２）。

クライアント１００とＷｅｂサーバ２００との間のセッションが確立すると、クライアント１００は、利用者の要求に応じた所定の処理を実行させるための処理情報ＲＥＱｉをＷｅｂサーバ２００に順次送信する（Ｐ４０３−ｉ）。なお、ｉは添え字であり、ｉ＝１〜ｎの自然数である（後述する図５においても同様）。

そして、処理情報ＲＥＱｎが送信される処理Ｐ４０３−ｎが完了する、すなわち、すべての処理情報がクライアント１００からＷｅｂサーバ２００に転送されると、Ｗｅｂサーバ２００は、それら処理情報に基づいて処理を実行する。続いて、Ｗｅｂサーバ２００は、この処理により得られた応答ＲＥＳをクライアント１００に送信する（Ｐ４０４）。
Ｗｅｂサーバ２００からクライアント１００にＷｅｂサービスで得られた応答ＲＥＳが転送されると、クライアント１００とＷｅｂサーバ２００とのセッションを終了し、Ｗｅｂサービスに係る処理が終了する（Ｐ４０５）。

図５は、本実施形態におけるＷｅｂサービス提供システムでのセッション（中断・再開）の処理シーケンスの一例を示す図である。
まず、Ｗｅｂサービスを利用するためにクライアント１００からＷｅｂサーバ２００に通信セッションの確立要求がなされる（Ｐ５０１）と、所定の処理が行われてクライアント１００とＷｅｂサーバ２００との通信セッションが確立される（Ｐ５０２）。

クライアント１００とＷｅｂサーバ２００との間のセッションが確立すると、クライアント１００は、利用者の要求に応じた所定の処理を実行させるための処理情報ＲＥＱｉをＷｅｂサーバ２００に順次送信する（Ｐ５０３−ｉ）。
ここで、処理Ｐ４０３−ｋ（１≦ｋ＜ｎ）において処理情報ＲＥＱｋが送信された後、言い換えればクライアント１００からＷｅｂサーバ２００への処理情報の転送が終了する前に、クライアント１００とＷｅｂサーバ２００との間のセッションが中断すると、それを検出したＷｅｂサーバ２００は、中断されたセッションに係るセッション状態情報を生成する（Ｐ５０４）。

Ｗｅｂサーバ２００により生成されたセッション状態情報は、Ｗｅｂサーバ２００とセッション状態保持手段３００とのセッションが確立された後にセッション状態保持手段３００に送信され（Ｐ５０５）、保持される（Ｐ５０６）。また、Ｗｅｂサーバ２００は、セッション状態情報をセッション状態保持手段３００に送信し登録すると、クライアント１００とのセッションを強制終了し、当該セッションに関連する内部リソース（例えばメモリリソース）を解放する（Ｐ５０７）。

そして、クライアント１００は、所定時間経過後にＷｅｂサーバ２００とのセッションを再開させるために、セッション状態保持手段３００に対して中断されたセッションに係るセッション状態情報を要求する（Ｐ５０８）。当該要求に応じて、セッション状態保持手段３００からクライアント１００にセッション状態情報が送信される（Ｐ５０９）と、クライアント１００はその取得したセッション状態情報を解析し、中断時のセッション状態を識別する（Ｐ５１０）。

続いて、クライアント１００からＷｅｂサーバ２００に通信セッションの再開要求がなされる（Ｐ５１１）と、セッションを中断させた原因が解消されていれば、クライアント１００とＷｅｂサーバ２００とのセッションが再び確立される（Ｐ５１２）。

クライアント１００とＷｅｂサーバ２００との間のセッションが再開すると、クライアント１００は、中断前に既に送信した処理情報を除く処理情報ＲＥＱｉ、すなわち本実施形態では処理情報ＲＥＱ（ｋ＋１）〜処理情報ＲＥＱｎをＷｅｂサーバ２００に順次送信する（Ｐ５０３−（ｋ＋１）〜Ｐ５０３−ｎ）。
以上のようにして、すべての処理情報ＲＥＱ１〜ＲＥＱｎがクライアント１００からＷｅｂサーバ２００に転送されると、Ｗｅｂサーバ２００は、それら処理情報に基づいて処理を実行し、得られた応答ＲＥＳをクライアント１００に送信する（Ｐ５１３）。

Ｗｅｂサーバ２００からクライアント１００にＷｅｂサービスで得られた応答ＲＥＳが転送されると、クライアント１００とＷｅｂサーバ２００とのセッションを終了する（Ｐ５１４）。さらに、セッション状態保持手段３００が、クライアント１００とＷｅｂサーバ２００とのセッションの終了を受けて、保持していた当該セッションのセッション状態情報を消去し、Ｗｅｂサービスに係る処理が終了する（Ｐ５１５）。

以上、説明したように本実施形態によれば、クライアント１００とＷｅｂサーバ２００とのセッションに係るセッション状態情報を保持するセッション状態保持手段３００を設け、クライアント１００とＷｅｂサーバ２００とのセッションが中断した場合には、Ｗｅｂサーバ２００は中断したセッションのセッション状態情報を生成してセッション状態保持手段３００に登録する。さらに、Ｗｅｂサーバ２００は、セッション状態保持手段３００へのセッション状態情報の登録が完了すると、中断されたセッションを強制的に終了し、それに関連する内部リソースを解放する。そして、中断したセッションを再開する場合には、クライアント１００が、セッション状態保持手段３００からセッション状態情報を取得してセッション中断時の状態を識別し、中断時の状態に応じてセッションの再開を行う。

これにより、Ｗｅｂサービスに係る処理情報の転送途中で、言い換えれば転送が完了する前に、クライアント１００とＷｅｂサーバ２００とのセッションが中断したとしても、それまでの状態をセッション状態情報としてセッション状態保持手段３００に登録することで、それまでにＷｅｂサーバ２００で受信された処理情報などは消失することなく保持される。そのため、Ｗｅｂサーバ２００は、自発的にセッションを終了することが可能となり、内部リソースを効率良く利用し、リソース不足に起因するパフォーマンスの低下を防止することができる。

また、中断したセッションを再開するときに、クライアント１００は、セッション状態保持手段３００から取得したセッション状態情報を基に中断前にどれだけの処理情報（データやコマンドなど）がＷｅｂサーバ２００に転送されているかを知ることができるので、セッションの再開後においては、未転送の処理情報（データ及びコマンド）のみを送信すればよい。したがって、クライアント１００は、中断したセッションを再開する場合に、Ｗｅｂサーバ２００にすべての処理情報を転送し直す必要が無くなり、処理情報の再転送を効率的に実行し、従来と比較して転送効率を向上させることができる。

また、中断したＷｅｂサービスのセッションに係るセッション状態情報をセッション状態保持手段３００に保持するので、Ｗｅｂサービスの復帰予定時刻など付随する情報をあわせて登録することが可能であり、これにより、クライアント１００はより確実なセッションの復帰が実現する。セッション状態保持手段３００に保持されるセッション状態情報は、セッション状態保持手段３００により電子署名されるので、状態の不正な改ざんやなりすましを防止することが可能である。加えて、セッション状態情報に時刻情報を加えることでセッション復帰の際のリプレイ攻撃に対処することも可能である。

なお、上述した本実施形態では、クライアント１００又はＷｅｂサーバ２００と、セッション状態保持手段３００との間での通信は、ＸＭＬ／ＳＯＡＰベースのプロトコルにより行うようにしているが、これは一例（実装仕様例）であり、その他のプロトコルを用いて通信することも可能である。
また、本発明は、上述した本実施形態に限定されず、Ｗｅｂサービスを利用することのできる機能を搭載したＭＦＰ、ネットワークシステム、並びにアプリケーションソフトウエアなどに適宜適用することができる。

（本発明の他の実施形態）
上述した実施形態の機能を実現するべく各種のデバイスを動作させるように、該各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、上記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って上記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。
また、この場合、上記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体は本発明を構成する。また、そのプログラムコードをコンピュータに供給するための手段、例えばかかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。
さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

例えば、上述した実施形態に示したＷｅｂサービス提供システムを構成する各装置（クライアント１００、Ｗｅｂサーバ２００、セッション状態保持手段３００）は、図６に示すようなコンピュータ機能６００を有し、そのＣＰＵ６０１により上述した動作が実施される。
コンピュータ機能６００は、上記図６に示すように、ＣＰＵ６０１と、ＲＯＭ６０２と、ＲＡＭ６０３と、キーボード（ＫＢ）６０９のキーボードコントローラ（ＫＢＣ）６０５と、表示部としてのＣＲＴディスプレイ（ＣＲＴ）６１０のＣＲＴコントローラ（ＣＲＴＣ）６０６と、ハードディスク（ＨＤ）６１１及びフレキシブルディスク（ＦＤ）６１２のディスクコントローラ（ＤＫＣ）６０７と、ネットワークインタフェースカード（ＮＩＣ）６０８とが、システムバス６０４を介して互いに通信可能に接続された構成としている。
ＣＰＵ６０１は、ＲＯＭ６０２又はＨＤ６１１に記憶されたソフトウェア、又はＦＤ６１２より供給されるソフトウェアを実行することで、システムバス６０４に接続された各構成部を総括的に制御する。すなわち、ＣＰＵ６０１は、上述したような動作を行うための処理プログラムを、ＲＯＭ６０２、ＨＤ６１１、又はＦＤ６１２から読み出して実行することで、上述した実施形態での動作を実現するための制御を行う。
ＲＡＭ６０３は、ＣＰＵ６０１の主メモリあるいはワークエリア等として機能する。ＫＢＣ６０５は、ＫＢ６０９や図示していないポインティングデバイス等からの指示入力を制御する。ＣＲＴＣ６０６は、ＣＲＴ６１０の表示を制御する。ＤＫＣ６０７は、ブートプログラム、種々のアプリケーション、ユーザファイル、ネットワーク管理プログラム、及び上述した実施形態における上記処理プログラム等を記憶するＨＤ６１１及びＦＤ６１２とのアクセスを制御する。ＮＩＣ６０８はネットワーク６１３上の他の装置と双方向にデータをやりとりする。

なお、上記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の実施形態によるネットワークシステムの構成例を示す図である。 本実施形態におけるＷｅｂサービス提供システムでの処理の流れを示すフローチャートである。 本実施形態におけるセッション再開処理の流れを示すフローチャートである。 本実施形態におけるセッション（通常）の処理シーケンスの一例を示す図である。 本実施形態におけるセッション（中断・再開）の処理シーケンスの一例を示す図である。 本実施形態における各装置を実現可能なコンピュータ機能を示すブロック図である。

符号の説明

１００ クライアント端末
１０２ セッション状態情報取得部
１０３ セッション状態情報解析部
２００ Ｗｅｂサーバ
２０４ セッション状態情報生成登録部
２０５ セッション再開判定部
２０６ 検証部
３００ セッション状態保持手段
３０１ 状態情報記憶部
３０２ 認証情報生成部

Claims (14)

1. 処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、
   上記端末から送信された複数の処理情報に基づいて処理を実行し、得られた応答を上記端末に送信するウェブサーバと、
   上記端末及び上記ウェブサーバに通信可能に接続され、上記端末と上記ウェブサーバとの間の通信セッションが中断した場合に、当該中断した通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを備えることを特徴とするネットワークシステム。
2. 上記端末と上記ウェブサーバとの間の通信セッションが中断した場合、上記ウェブサーバは、上記セッション状態情報を上記セッション状態保持手段に登録した後、当該通信セッションに関する内部リソースを解放することを特徴とする請求項１記載のネットワークシステム。
3. 上記セッション状態情報は、上記通信セッションの中断前に、上記端末と上記ウェブサーバとの間で確立していた通信セッションに関する第１の情報及び上記ウェブサーバが受信した上記端末からの処理情報に関する第２の情報を含むことを特徴とする請求項１又は２記載のネットワークシステム。
4. 上記第２の情報は、上記通信セッションの中断前に上記ウェブサーバが受信した処理情報の容量を示す情報であることを特徴とする請求項３記載のネットワークシステム。
5. 上記端末と上記ウェブサーバとの間の中断された通信セッションが再開した場合、上記端末は、上記セッション状態保持手段に保持されている上記セッション状態情報を参照して中断前に未送信の処理情報だけを上記ウェブサーバに送信することを特徴とする請求項４記載のネットワークシステム。
6. 上記セッション状態保持手段は、上記ウェブサーバにより登録される上記セッション状態情報に電子署名を施すことを特徴とする請求項１〜５の何れか１項に記載のネットワークシステム。
7. 上記セッション状態情報に含まれる、上記通信セッションの中断前に、上記端末と上記ウェブサーバとの間で確立していた通信セッションに関する第１の情報に上記電子署名を施すことを特徴とする請求項６記載のネットワークシステム。
8. 上記端末と上記ウェブサーバとの間の中断された通信セッションを再開する際、上記ウェブサーバは、上記端末より供給される上記セッション状態情報の電子署名を検証して完全性が保証される場合に当該通信セッションを再開することを特徴とする請求項６又は７記載のネットワークシステム。
9. 所定の処理を実行させるための複数の処理情報を送信する端末と、当該送信された複数の処理情報に基づいて処理を実行して得られた応答を上記端末に送信するウェブサーバとに通信可能に接続された情報処理装置であって、
   上記ウェブサーバから送信される、上記端末と上記ウェブサーバとの間の通信セッションに係るセッション状態情報を受信する受信手段と、
   上記受信手段により受信した上記セッション状態情報を記憶する情報記憶手段と、
   上記情報記憶手段に記憶したセッション状態情報を上記端末に送信する送信手段とを備えることを特徴とする情報処理装置。
10. 所定の処理を実行させるための複数の処理情報を送信する端末に通信可能に接続され、当該送信された複数の処理情報に基づいて処理を実行して得られた応答を上記端末に送信する情報処理装置であって、
    上記端末との通信セッションが中断した場合に、当該中断した通信セッションに係るセッション状態情報を生成する情報生成手段と、
    上記情報生成手段により生成したセッション状態情報を、通信可能に接続されるセッション状態保持手段に送信し登録する情報登録手段と、
    上記端末から送信されるセッション状態情報に基づいて、上記端末との通信セッションを再開するか否かを判定する再開判定手段とを備えることを特徴とする情報処理装置。
11. 受信する処理情報に基づいて処理を実行し得られる応答を返すウェブサーバに通信可能に接続され、当該ウェブサーバに所定の処理を実行させるための複数の処理情報を送信する情報処理装置であって、
    上記ウェブサーバとの間の中断された通信セッションを再開する場合に、当該中断された通信セッションに係るセッション状態情報を取得する情報取得手段と、
    上記情報取得手段により取得したセッション状態情報に基づいて、上記ウェブサーバにて中断前に受信されている処理情報を除く処理情報を上記ウェブサーバに送信する送信手段とを備えることを特徴とする情報処理装置。
12. 処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、上記端末から送信された複数の処理情報に基づいて処理を実行し、得られた応答を上記端末に送信するウェブサーバと、上記端末及び上記ウェブサーバに通信可能に接続され、上記端末と上記ウェブサーバとの間の通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを有するネットワークシステムの通信制御方法であって、
    上記端末と上記ウェブサーバとの間の通信セッションが中断した場合に、当該通信セッションのセッション状態情報を上記ウェブサーバが上記セッション状態保持手段に登録する情報登録ステップと、
    上記中断された通信セッションを再開するために、上記セッション状態保持手段に登録された上記セッション状態情報を上記端末が取得する情報取得ステップと、
    上記取得したセッション状態情報の内容に基づいて、上記端末が上記ウェブサーバにアクセスし通信セッションの再開を要求する再開要求ステップと、
    上記再開要求に対し、上記セッション状態情報の内容に基づいて上記ウェブサーバが上記端末との通信セッションの再開判定を行う再開許可ステップとを有することを特徴とする通信制御方法。
13. 処理を実行させるための複数の処理情報を送信し、当該処理を実行して得られる応答を受信する端末と、上記端末から送信された複数の処理情報に基づいて処理を実行し、得られた応答を上記端末に送信するウェブサーバと、上記端末及び上記ウェブサーバに通信可能に接続され、上記端末と上記ウェブサーバとの間の通信セッションに係るセッション状態情報を保持するセッション状態保持手段とを有するネットワークシステムにおける通信制御をコンピュータに実行させるためのプログラムであって、
    上記端末と上記ウェブサーバとの間の通信セッションが中断した場合に、当該通信セッションのセッション状態情報を上記ウェブサーバが上記セッション状態保持手段に登録する情報登録ステップと、
    上記中断された通信セッションを再開するために、上記セッション状態保持手段に登録された上記セッション状態情報を上記端末が取得する情報取得ステップと、
    上記取得したセッション状態情報の内容に基づいて、上記端末が上記ウェブサーバにアクセスし通信セッションの再開を要求する再開要求ステップと、
    上記再開要求に対し、上記セッション状態情報の内容に基づいて上記ウェブサーバが上記端末との通信セッションの再開判定を行う再開許可ステップとをコンピュータに実行させるためのプログラム。
14. 請求項１３記載のプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。

Images