情報処理装置が行う画面情報生成方法であって、前記情報処理装置は、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに含まれる第1の情報を用いて、第2の情報を含む当該メインリクエストの応答データを取得する応答データ取得ステップと、前記第2の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得ステップと、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成ステップと、を行い、前記サブリクエスト生成ステップは、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも1つに基づいて、サブリクエストを生成し、前記取得ステップで前記コンテンツの取得に失敗した場合、前記画面情報生成ステップは、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、前記取得ステップで取得したコンテンツに所定の情報が含まれている場合、前記画面情報生成ステップは、取得したコンテンツを所定のコンテンツに差し替えて画面情報を生成することを特徴とする画面情報生成方法。画面情報生成システムであって、端末から送信されたメインリクエストを受け付ける要求受付手段と、前記メインリクエストに含まれる第1の情報を用いて、第2の情報を含む当該メインリクエストの応答データを取得し、前記第2の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成手段と、前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得手段と、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成手段と、を有し、前記サブリクエスト生成手段は、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも1つに基づいて、サブリクエストを生成し、前記取得手段が前記コンテンツの取得に失敗した場合、前記画面情報生成手段は、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、前記取得手段が取得したコンテンツに所定の情報が含まれている場合、前記画面情報生成手段は、取得したコンテンツを所定のコンテンツに差し替えて画面情報を生成することを特徴とする画面情報生成システム。情報処理装置が実行する画面情報生成プログラムであって、前記情報処理装置に、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに含まれる第1の情報を用いて、第2の情報を含む当該メインリクエストの応答データを取得する応答データ取得ステップと、前記第2の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得ステップと、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成ステップと、を実行させ、前記サブリクエスト生成ステップは、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも1つに基づいて、サブリクエストを生成し、前記取得ステップで前記コンテンツの取得に失敗した場合、前記画面情報生成ステップは、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、前記取得ステップで取得したコンテンツに所定の情報が含まれている場合、前記画面情報生成ステップは、取得したコンテンツを所定のコンテンツに差し替えて画面情報を生成することを特徴とする画面情報生成プログラム。MVCモデルでは、前述の通り、1つのViewに複数のコンテンツを表示する場合は、複数のビジネスロジックを1つに統合したビジネスロジックをView毎に作成する必要がある。したがって、使用する画面の数が増えると、画面の数だけ新たなビジネスロジックが必要となり、システムの生産性および保守性の観点において、非効率的である。また、サーブレットAPIを利用した技術の場合、JSPはサーブレットなどを介して複数のビジネスロジックを呼び出すことができる。しかしながら、JSPがビジネスロジックを呼び出す際のリクエストは、クライアントから受け付けたリクエストと同じリクエストである。そのため、画面のレイアウトによっては、クライアントから受け付けたリクエストとは異なるパラメータでビジネスロジックを呼び出す必要がある場合については、考慮されていない。本発明は上記事情に鑑みてなされたものであり、本発明の目的は、画面の生成と、画面を構成するビジネスロジックとを分離して作成して、ビジネスロジックの再利用を容易にすることにより、システムの生産性および保守性をより向上させることにある。上記課題を解決するために、本発明は、例えば、情報処理装置が行う画面情報生成方法であって、前記情報処理装置は、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに基づいて、少なくとも1つのサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得ステップと、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成ステップと、を行う。また、本発明は、画面情報生成システムであって、端末から送信されたメインリクエストを受け付ける要求受付手段と、前記メインリクエストに基づいて、少なくとも1つのサブリクエストを生成するサブリクエスト生成手段と、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得手段と、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成手段と、を有する。また、本発明は、情報処理装置が実行する画面情報生成プログラムであって、前記情報処理装置に、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに基づいて、少なくとも1つのサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得ステップと、前記取得した各コンテンツを統合し、1つの画面情報を生成する画面情報生成ステップと、を実行させる。本発明では、画面の生成と、画面を構成するビジネスロジックとを分離して作成して、ビジネスロジックの再利用を容易にすることにより、システムの生産性および保守性をより向上させることができる。以下、本発明の実施の形態について説明する。図1は、本発明の一実施形態が適用されたWebシステムの全体構成図である。本実施形態のWebシステムは、少なくとも1つのクライアント1と、Webサーバ2と、アプリケーションサーバ3と、を有する。そして、各クライアント1とWebサーバ2とは、インターネットなどのネットワーク4により接続されている。クライアント1のWebブラウザ11は、ユーザの指示を受け付けてWebサーバ2から所望の情報を取得し、出力装置不図示に表示する。Webサーバ2は、各クライアント1からの要求を受け付けて、クライアント1に提供する情報を動的に生成し、生成した情報をクライアント1に送信する。なお、本実施形態では、クライアント1に提供する情報は、Webページを表示するための情報以下、画面情報とする。画面情報は、HTMLHyperTextMarkupLanguage、XMLeXtensibleMarkupLanguageなどのマークアップ言語により記述されているが、本実施形態ではHTMLにより記述された画面情報を例として以下説明する。図示するWebサーバ2は、要求受付部21と、画面生成部22と、少なくとも1つの情報生成ファイル23と、キャッシュメモリ24と、を有する。要求受付部21は、クライアント1が送信した要求以下、メインリクエストを受け付け、受け付けたメインリクエストを情報生成ファイル23または、画面生成部22に引き渡す。なお、要求受付部21は、例えばサーブレットservletであるものとする。画面生成部22は、クライアント1に提供する画面情報を動的に生成し、生成した画面情報をクライアント1に送信する。なお、本実施形態の画面生成部22は、情報生成ファイル23のプログラムを実行することにより、上記処理を実行するものとする。情報生成ファイル23は、例えば、JSPJavaServerPagesの技術を用いたJSPファイルである。すなわち、情報生成ファイル23は、HTMLで記述された画面情報の中に、Java登録商標プログラムが記述されたファイルである。画面生成部22は、情報生成ファイル23に記述されたJava登録商標プログラムを実行することにより、画面情報HTMLファイルを動的に生成し、クライアント1に送信する。また、本実施形態の情報生成ファイル23では、ビジネスロジック31にアクセスするためのサーブレット不図示を呼び出すことができるものとする。なお、情報生成ファイル23は、メモリまたは外部記憶装置に記憶されている。キャッシュメモリ24は、高速な記憶装置であって、アプリケーションサーバ3から取得したコンテンツが記憶される。アプリケーションサーバ3は、複数のビジネスロジック31を有する。各ビジネスロジック31は、Webサーバ2ら送信された要求を受け付けて所定の業務処理を行い、処理結果をWebサーバ6に送信する。上記説明した、クライアント1、Webサーバ2およびアプリケーションサーバ3は、いずれも、例えば図2に示すようなCPU901と、メモリ902と、HDD等の外部記憶装置903と、キーボードやマウスなどの入力装置904と、ディスプレイやプリンタなどの出力装置905と、ネットワークと接続するための通信制御装置906と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、クライアント1、Webサーバ2およびアプリケーションサーバ3の各機能は、クライアント1用のプログラムの場合はクライアント1のCPU901が、Webサーバ2用のプログラムの場合はWebサーバ2のCPU901が、そして、アプリケーションサーバ3用のプログラムの場合はアプリケーションサーバ3のCPU901が、それぞれ実行することにより実現される。なお、入力装置904および出力装置905については、各装置が必要に応じて備えるものとする。また、Webサーバ2およびアプリケーションサーバ3は、1つのコンピュータ装置内に設けることとしてもよい。次に、クライアント1の出力装置に表示される表示画面Webページについて説明する。なお、本実施形態の表示画面は、フレーム機能を用いて画面を複数のフレームで仕切ることなく、1つの画面内に複数のコンテンツが表示されるものとする。また、表示画面における各コンテンツの配置場所などのレイアウト情報は、情報生成ファイル23に定義されているものとする。図3は、表示画面の一例を示す図である。クライアント1のWebブラウザ11は、Webサーバ2から受信した画面情報HTMLファイルを解析し、図示するような表示画面を出力装置に出力する。なお、図示する表示画面は、デイトレーダーなどの個人投資家がネットワークを介して株式など売買するオンライントレードの画面例である。図示する表示画面は、メニュー51、パーソナルメッセージ52、マーケット情報53、および新規公開株情報54の4つのコンテンツから構成されるものとする。パーソナルメッセージ52、マーケット情報53、および新規公開株情報54は、クライアント1からの要求に応じて、後述する処理により動的に生成されるコンテンツである。メニュー51は、あらかじめ定められた固定情報静的コンテンツであって、情報生成ファイル23に記述されているものとする。次に、本実施形態のWebシステムの処理について説明する。図4は、Webシステムの処理を模式的に示した図である。なお、図示する処理は、図3に示す表示画面を生成する場合を例として示したものである。まず、クライアント1のWebブラウザ11は、ユーザの指示を受け付けて、メインリクエストをWebサーバ2に送信するS11。なお、メインリクエストには、ユーザIDが含まれているものとする。Webサーバ2の要求受付部サーブレット21は、メインリクエストを受信し、当該メインリクエストに含まれる情報を引数として、アプリケーションサーバ3のメインリクエスト用ビジネスロジック31aにアクセスする。そして、メインリクエスト用ビジネスロジック31aは、メインリクエストの情報に基づいて応答データを生成し、生成した応答データを要求受付部21に送信するS12。なお、図示するメインリクエスト用ビジネスロジック31aは、応答データとして、メインリクエストに含まれるユーザIDが所有する口座情報をデータベース不図示から取得するものとする。また、口座情報は、ユーザの保有商品に関する情報例えば、株式の銘柄、株数、ファンド名などである。そして、要求受付部21は、メインリクエスト用ビジネスロジック31aから受信した応答データおよびメインリクエストに基づいて、所定の情報生成ファイルJSPファイル23を特定する。そして、要求受付部21は、特定した情報生成ファイル23に、メインリクエストおよび応答データを引き渡すS13。これにより、画面生成部22は、指定された情報生成ファイル23の中に記述されたプログラムを実行して、以下の処理を行う。すなわち、画面生成部22は、情報生成ファイル23を実行し、画面情報HTMLファイル239を生成する。まず、画面生成部22は、メインリクエストおよび応答データを、メインリクエスト用のコンテキスト以下、コンテキストメイン231に記憶する。コンテキストは、実行中のプログラムで用いる引数パラメータ、処理結果、ステータスなどを記憶するための領域である。そして、画面生成部22は、コンテキストメイン231に記憶されたメインリクエストおよび応答データに基づいてサブリクエストを生成し、サブリクエスト用のコンテキスト以下、コンテキストサブ232に記憶するS14。サブリクエストは、クライアントからのメインリクエストと区別するための用語であって、サーバ内で発生するものである。なお、図示する例では図3に示す画面情報を生成するため、パーソナルメッセージを取得するためのサブリクエスト1と、マーケット情報を取得するためのサブリクエスト2と、新規公開株情報を取得するためのサブリクエスト3とを生成する。そして、各サブリクエストは、コンテキストメイン231とは別のコンテキストサブ232で、それぞれ実行される。例えば、サブリクエスト1の場合、コンテキストメイン231の情報口座情報等を参照し、ユーザが保有する商品の種類株式、投資信託、債券など毎に、当該商品に関する情報を要求することが考えられる。具体的には、○○様へのお知らせとして、保有商品が株式の場合は日経平均を要求するためのサブリクエストを生成し、保有商品が投資信託の場合は投信平均を要求するためのサブリクエストを生成することが考えられる。また、サブリクエスト2の場合、コンテキストメイン231の情報口座情報等を参照し、ユーザが保有する商品の時価総額を要求することが考えられる。また、サブリクエスト3の場合、新規公開株の情報を要求することが考えられる。そして、画面生成部22は、生成したサブリクエスト各々を、当該サブリクエストに対応するサーブレット28にそれぞれ送出するS15。なお、サーブレット側では、サブリクエストがあたかもクライアント1から送出されたリクエストのように見える。そして、各サーブレット28は、アプリケーションサーバ3の対応するサブリクエスト用ビジネスロジック31bにそれぞれアクセスする。各サブリクエスト用ビジネスロジック31bは、受け付けたサブリクエストに基づいて、応答データとしてコンテンツを生成し、サーブレット28に送出する。そして、画面生成部22は、各サーブレット28からコンテンツを受け付け、対応するコンテキストサブ232に記憶するS17。サブリクエスト1に対する応答データとしては、例えば、日経平均または投信平均が記述されたパーソナルメッセージのコンテンツ1HTMLファイルが生成される。また、サブリクエスト2に対する応答データとしては、例えば、保有商品の時価情報が記述されたマーケット情報のコンテンツ2が生成される。また、サブリクエスト3に対する応答データとしては、例えば、新規公開株の情報が記述されたコンテンツ3が生成される。そして、画面生成部22は、情報生成ファイル23に定義されたレイアウト情報を参照し、各コンテキストサブ232のコンテンツ応答データを所定の位置に配置して、画面情報239を生成するS18。すなわち、画面生成部22は、情報生成ファイル23のJSPタグ部分に、取得したコンテンツを埋め込むことにより、JSPタグ部分をHTML形式のタグへと変換し、HTMLのみで記述された画面情報HTMLファイル239を動的に生成する。そして、画面生成部22は、生成した画面情報239をクライアント1に送信するS19。そして、クライアント1のWebブラウザ11は、画面情報239のタグを解析し、図3に示すような表示画面を出力装置に表示する。以上説明したように、本実施形態では、コンテキストメイン231に基づいてサブリクエストを生成し、サーブレット28にサブリクエストを発行する。そして、サブリクエストは、コンテキストメイン231とは別のコンテキストサブ232でそれぞれ実行される。これにより、本実施形態では、情報生成ファイル23が各サーブレット28を呼び出す際に、メインリクエストに対応する応答データステータスを含むの影響を受けることがない。したがって、メインリクエストや他のサブリクエストの処理により、意図しないステータスattributeの変更を回避することができる。次に、画面生成部22がサブリクエストを発行し、コンテンツを取得する処理図4:S15~S17について、さらに詳しく説明する。図5は、画面生成部22が行うコンテンツ取得処理のフローチャートである。なお、図示する処理は、サブリクエスト毎にそれぞれ行われる。まず、画面生成部22は、コンテキストサブ232からサブリクエストを読み出すS21。そして、画面生成部22は、読み出したサブリクエストに対応するコンテンツがキャッシュメモリ24に記憶されているか否かを判別するS22。要求するコンテンツがキャッシュメモリ24に記憶されていない場合S22:NO、画面生成部22は、図4で説明したように、対応するサーブレット28にサブリクエストを送出し、コンテンツを要求するS23。そして、画面生成部22は、ビジネスロジックが生成したコンテンツを、サーブレット28から取得するS24。そして、画面生成部22は、取得したコンテンツをコンテキストサブ232に記憶する。また、画面生成部22は、取得したコンテンツにユーザ固有情報が記述されている場合、当該ユーザ固有情報を所定の文字列以下、置換文字列に置換し、置換後のコンテンツをキャッシュメモリ24に記憶するS25。なお、ユーザ固有情報としては、セッション情報やユーザ属性情報などが考えられる。一方、要求するコンテンツが、キャッシュメモリ24に既に記憶されている場合S22:YES、画面生成部22は、キャッシュメモリ24から当該コンテンツを取得するS26。なお、キャッシュメモリ24に記憶されているコンテンツは、前述の通りユーザ固有情報が置換文字列に置換されている。そのため、画面生成部22は、キャッシュメモリ24から取得したコンテンツに置換文字列が存在するか否かを判別し、置換文字列が存在する場合は当該置換文字列をユーザ固有情報に復元置換する。そして、画面生成部22は、ユーザ固有情報を復元したコンテンツを、コンテキストサブ232に記憶するS27。なお、ユーザ固有情報は、メインリクエストとともにクライアント1から送信され、Webサーバ2のメモリなど記憶されるものとする。以上説明したように、コンテンツのユーザ固有情報を所定の置換文字列に置換してキャッシュメモリ24に記憶し、キャッシュメモリ24に記憶されたコンテンツの置換文字列をユーザ固有情報に復元してコンテンツを再利用する。これにより、ビジネスロジックが同じコンテンツをその都度新たに生成する場合に比べて、処理負荷を低減させ、クライアント1への応答時間を短縮することができる。例えば、図3に示す表示画面の場合、新規公開株情報のコンテンツ54については、各ユーザに同じ内容の情報を提供する。このようなコンテンツについては、キャッシュメモリ24にコンテンツを記憶しておくことで、より効果的に処理負荷を低減させ、クライアントへの応答時間を短縮することができる。次に、画面生成部22が画面情報239を生成する処理図4:S18について、さらに詳しく説明する。図6は、画面生成部22が行う画面情報生成処理のフローチャートである。なお、画面生成部22は、以下に説明するS31からS34の処理を、コンテキストサブ毎にそれぞれ行うものとする。画面生成部22は、サブリクエストの処理結果を示すステータスが、正常か否かを判別するS31。なお、ステータスは、コンテンツの取得に成功したか、または、コンテンツの取得に失敗したかなどのコンテンツの取得状況を示すものである。サーブレット28から受け付けたステータスは、応答データの1つとしてコンテンツとともにコンテキストサブ232に記憶される。ステータスが正常の場合S31:YES、画面生成部22は、コンテキストサブ232に記憶されたコンテンツに、所定の文字列が記述されているか否かを判別するS32。所定の文字列としては、例えば、該当するデータが存在しないことを示す保有株式がありません、または、エラーメッセージの申し訳ございませんなどが考えられる。ステータスがエラーの場合S31:NO、または、所定の文字列を含む場合S32:YES、画面生成部22は、当該サブリクエストに対するコンテンツを、所定のコンテンツに差し替えるS33。図7は、コンテンツの差し替えを模式的に示した図である。図7aは、正常な応答データ72がコンテキストサブ271に記憶されている場合S31:YESかつS32:NOを示したものである。この場合、応答データであるマーケット情報のコンテンツ72が、表示画面の所定の位置73に埋め込まれる。図7bは、不正常な応答データ75がコンテキストサブ274に記憶されている場合S31:NOまたはS32:YESを示したものである。この場合、図示するような不正常な応答データ75を、あらかじめ定められた所定のコンテンツに差し替え、表示画面の所定の位置76に埋め込む。なお、差し替え用のコンテンツは、表示画面全体のデザイン上、違和感がないコンテンツをあらかじめ用意しておくものとする。図示する例では、マーケット情報の替わりに、新サービスの案内を示すコンテンツ76に差し替える。不正常な応答データを別のコンテンツに差し替えることにより、不正常な応答データをそのまま埋め込むことにより発生する表示画面のデザイン上の問題違和感、画面の破壊などを回避することができる。また、画面生成部22がこのようなコンテンツの差し替えを行うため、ビジネスロジック側では不正常な応答データの場合の処理を考慮する必要がなく、応答データとして共通のエラーメッセージやエラー画面を返すことができる。そして、正常な応答データの場合S32:NO、画面生成部22は、あらかじめ定められた編集ルールポリシーに基づいてコンテキストサブ232に記憶されたコンテンツを編集するS34。例えば、コンテンツ自身もHTMLファイルである。そのため、各コンテンツをマージして1つの画面情報HTMLファイルを生成すると、<body>タグまたは<html>タグなどが重複する場合がある。そのため、画面生成部22は、コンテンツの埋め込み先に応じて、コンテンツから<body>タグ及び<html>タグなどの不要なタグを削除する。また、あらかじめ定められた編集ルールの条件に合致する場合は、コンテンツに記述された所定の文字列から所定の文字列までの範囲のみを抽出し、他の部分については削除することが考えられる。全てのコンテキストサブ232の応答データについてS31からS34の処理を行った後、画面生成部22は、情報生成ファイル23に定義されたレイアウト情報を参照して、編集後の各コンテンツを情報生成ファイル23の所定の箇所に埋め込み、各コンテンツを統合した画面情報HTMLファイル239を生成するS35。以上、本発明の一実施形態を説明した。本実施形態では、コンテキストメインに記憶されたインリクエストおよびメインリクエストの応答データに基づいてサブリクエストを生成し、サーブレット28にサブリクエストを発行する。そして、サブリクエストは、コンテキストサブでそれぞれ実行される。これにより、情報生成ファイル23が各サーブレット28を呼び出す際に、メインリクエストの応答データステータスを含むの影響を受けることがない。したがって、メインリクエストの処理により、意図しないステータスattributeの変更を回避することができる。また、各サーブレット28を呼び出す際に、メインリクエストとは異なるサブリクエストを発行することができる。また、本実施形態では、画面生成部22が行う画面情報の生成と、ビジネスロジックとを分離して作成することができる。これにより、ビジネスロジックの再利用を容易にし、システムの生産性および保守性をより向上させることができる。すなわち、ビジネスロジックは、画面情報を構成するコンテンツ単位最小単位に作成すればよく、MVCモデルのように各ビジネスロジックを統合したビジネスロジックを作成する必要がない。また、本実施形態では、コンテンツのユーザ固有情報を所定の置換文字列に置換してキャッシュメモリ24に記憶し、キャッシュメモリ24に記憶されたコンテンツの置換文字列をユーザ固有情報に復元してコンテンツを再利用する。これにより、ビジネスロジックが同じコンテンツをその都度新たに生成する場合に比べて、処理負荷を低減させ、クライアント1への応答時間を短縮することができる。また、本実施形態では、不正常な応答データを別のコンテンツに差し替えることにより、不正常な応答データをそのまま埋め込むことにより発生する表示画面のデザイン上の問題違和感、画面の破壊などを回避することができる。また、画面生成部22がこのようなコンテンツの差し替えを行うため、ビジネスロジック側では不正常な応答データの場合の処理を考慮する必要がなく、応答データとして共通のエラーメッセージやエラー画面を返すことができる。また、本実施形態では、正常な応答データであっても、あらかじめ定められた編集ルールに従ってコンテンツの編集を行う。これにより、サブリクエストに対するコンテンツの再利用を促進し、より汎用的なビジネスロジックを作成することができる。また、本実施形態では、フレーム機能を用いることなく、1つの画面Webページで複数のコンテンツを表示する。これにより、フレームを用いた場合に、クライアント1側でフレーム数分のコンテンツHTMLファイルを要求し、ネットワーク上の負荷が増大することを回避することができる。また、クライアント1がフレーム数分のコンテンツをWebサーバ2に要求するたびに発生するユーザ認証処理の回数を低減することができる。また、フレームやスクロールバーが画面上に表示されないため、デザイン的に見栄えの良いより統一感のある画面を生成することができる。なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、Webサーバ2の画面生成部22は、コンテキストメイン231に記憶されたメインリクエストおよび応答データに基づいてサブリクエストを生成することとした。しかしながら、本発明はこれに限定されず、画面生成部22は、コンテキストメイン231に記憶された情報だけでなく、コンテキストサブ232に記憶されたサブリクエストおよび応答データに基づいて、サブリクエストを生成することとしてもよい。図4に示す場合、画面生成部22は、サブリクエスト2を、コンテキストメイン231の情報およびコンテキストサブ1の情報に基づいて生成することが考えられる。また、画面生成部22は、サブリクエスト2を、コンテキストサブ1の情報にのみ基づいて生成することとしてもよい。