(57)【要約】【課題】  複数のリクエストに対する処理を効率よく実行し、一時的な高負荷時であっても通常運用時のサーバの処理能力で全リクエストを処理可能とする。【解決手段】  リクエスト格納処理において、分類変更部は、分類変更条件が成立していれば分類変更処理を実行する。リクエストを受信すると、振り分け器は、リクエストの分類を判定して振り分け先を決定し、振り分け先のリクエストキューにリクエストを送信する。リクエストキューは、送信されてきたリクエストを保存する。よって、各リクエストキューに、それぞれ、あらかじめ割り当てられている分類のリクエストが保存される。すなわち、各リクエストキューに保存されるリクエスト群は、それぞれ、各サーバが一括処理できる可能性のあるものとなっている。従って、リクエスト対応処理にて、各リクエストキューに記憶されている複数のリクエストに応じた共通処理を実行することが可能となる。【選択図】  図２
2008159081.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを処理するキューイングシステムであって、
受信した共通処理によって一括して処理できる可能性を有するリクエストの内容に含まれる分類を決定するためのキーに応じて複数の分類から当該リクエストの分類を特定し、特定した分類に従ってリクエストを振り分けるリクエスト振分手段と、
前記複数の分類のいずれかが割り当てられており、前記リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキューと、
単位時間あたりの受信リクエスト数が所定数以下となったときに成立する所定の分類変更条件が成立したことに応じて、分類の数を増加させることにより複数の分類の設定内容を変更する分類設定変更手段と、
前記リクエストキューに記憶されている複数のリクエストに返答するための返答情報を、当該リクエストキュー毎に生成する返答処理を実行する返答処理実行手段と、
を備え、
前記複数の分類は、それぞれ、前記返答処理の一部が共通処理によって実行される複数のリクエストが同一分類に属するように、前記リクエストの内容毎に区分けされてあらかじめ設定されており、
前記分類設定変更手段は、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで前記設定内容を変更し、
前記返答処理実行手段は、前記リクエストキューに記憶されている複数のリクエストを読み出し、当該複数のリクエストに対する返答を行うための前記返答処理の一部を前記共通処理により一括して行う、
キューイングシステム。
【請求項２】
返答処理実行手段は、返答処理にて、リクエスト毎の個別処理を実行する必要があるか否か判定し、必要があれば前記個別処理を実行してリクエスト毎に返答するために当該リクエスト毎の返答情報を生成する
請求項１記載のキューイングシステム。
【請求項３】
分類変更条件は、所定の変更指示があったときに成立し、
分類設定変更手段は、前記変更指示に従って設定内容を変更する
請求項１記載のキューイングシステム。
【請求項４】
複数の返答処理実行手段を備え、
前記複数の返答処理実行手段は、それぞれ、リクエストキューのいずれかに割り当てられ、割り当てられたリクエストキューに記憶されている複数のリクエストに返答するために返答処理を実行し、
分類設定変更手段は、所定の分類変更条件が成立したときに、前記複数の返答処理実行手段それぞれにおける前記リクエストキューの割り当てを変更する
請求項２または請求項３記載のキューイングシステム。
【請求項５】
通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを所定の分類毎に振り分けて記憶するキューイング装置であって、
受信した共通処理によって一括して処理できる可能性を有するリクエストの内容に含まれる分類を決定するためのキーに応じて複数の分類から当該リクエストの分類を特定し、特定した分類に従ってリクエストを振り分けるリクエスト振分手段と、
前記複数の分類のいずれかが割り当てられており、前記リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキューと、
単位時間あたりの受信リクエスト数が所定数以下となったときに成立する所定の分類変更条件が成立したことに応じて、分類の数を増加させることにより複数の分類の設定内容を変更する分類設定変更手段と、
を備え、
前記複数のリクエストキューは、それぞれ、当該リクエストキューに記憶されているリクエストを通信ネットワークを介して読み出して当該リクエストキューに記憶されている複数のリクエストに返答するための返答情報を生成する返答処理を実行する返答処理実行装置に対し、当該リクエストキュー毎に前記返答情報を生成させて前記返答処理の一部を共通処理により一括して実行させるために、割り当てられている分類のリクエストを記憶し、
前記リクエスト振分手段が振り分けの際に用いる前記複数の分類は、それぞれ、前記返答処理の一部が前記共通処理によって実行される複数のリクエストが同一分類に属するように、前記リクエストの内容毎に区分けされてあらかじめ設定されており、
前記分類設定変更手段は、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで前記設定内容を変更する、
キューイング装置。
【請求項６】
分類変更条件は、所定の変更指示があったときに成立し、
分類設定変更手段は、前記変更指示に従って設定内容を変更する、
請求項５記載のキューイング装置。
【請求項７】
返答処理実行装置によってリクエストキュー毎に生成された返答情報を通信ネットワークを介して受信する返答情報受信手段と、
受信した返答情報と、当該返答情報によりリクエストに対する返答内容が一意に定まることとなったと認識したときにはその旨を示す情報とを、リクエストキューに対応付けして保存する返答情報保存手段と、
所定のリクエストキューに記憶されているリクエストに対する返答内容が一意に定まることとなっている場合には、前記返答処理実行装置に返答処理を実行させることなく、当該所定のリクエストキューに記憶されている各リクエストそれぞれのリクエスト元に向けて、前記返答情報保存手段に保存されている返答情報を通信ネットワークを介して送信する返答情報送信手段とを備えた
請求項５または請求項６に記載のキューイング装置。
【請求項８】
通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを所定の分類毎に振り分けて記憶するキューイング装置であって、
受信した共通処理によって一括して処理できる可能性を有するリクエストの内容に含まれる分類を決定するためのキーに応じて複数の分類から当該リクエストの分類を特定し、
特定した分類に従ってリクエストを振り分けるリクエスト振分手段と、
前記複数の分類のいずれかが割り当てられており、前記リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキューと、
単位時間あたりの受信リクエスト数が所定数以下となったときに成立する所定の分類変更条件が成立したことに応じて、分類の数を増加させることにより複数の分類の設定内容を変更する分類設定変更手段と、
前記リクエストキューに記憶されているリクエストのうち所定個のリクエストを通信ネットワークを介して読み出して当該所定個の読み出したリクエストに返答するための返答情報を生成する返答処理を実行する返答処理実行装置から、当該所定個のリクエスト毎に生成された前記返答情報を通信ネットワークを介して受信する返答情報受信手段と、
受信した返答情報を、該当するリクエストのリクエスト元に向けて通信ネットワークを介して送信する返答情報送信手段とを備え、
前記リクエスト振分手段が振り分けの際に用いる前記複数の分類は、それぞれ、前記返答処理実行装置によって生成される返答情報が共通して使用され得る複数のリクエストが同一分類に属するように、前記リクエストの内容毎に区分けされてあらかじめ設定されており、
前記分類設定変更手段は、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで前記設定内容を変更し、
前記返答情報送信手段は、受信した返答情報が示す返答内容が所定内容であったときには、対応するリクエストキューに記憶されている各リクエストそれぞれのリクエスト元に向けて、当該受信した返答情報と同一の返答情報を送信するとともに、当該リクエストキューに記憶されていたリクエストを削除する処理を実行する、
キューイング装置。
【請求項９】
通信ネットワークを介して受けたリクエストをキューイングし、リクエストに対する返答を行うためにキュー内のリクエストを処理するキュー処理方法であって、
受信した共通処理によって一括して処理できる可能性を有するリクエストの内容に含まれる分類を決定するためのキーに応じて複数の分類から当該リクエストの分類を特定するステップと、
特定した分類に従ってリクエストを振り分けるステップと、
前記複数の分類のいずれかが割り当てられており、前記リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストを複数のリクエストキューにそれぞれ記憶するステップと、
単位時間あたりの受信リクエスト数が所定数以下となったときに成立する所定の分類変更条件が成立したことに応じて、分類の数を増加させることにより複数の分類の設定内容を変更するステップと、
前記リクエストキューに記憶されている複数のリクエストを読み出すステップと、
読み出した複数のリクエストに返答するための返答情報を当該リクエストキュー毎に生成する返答処理の一部を共通処理により一括して行うステップと、を含み、
前記複数の分類は、それぞれ、前記返答処理の一部が共通処理によって実行される複数のリクエストが同一分類に属するように、前記リクエストの内容毎に区分けされてあらかじめ設定されており、
前記変更するステップは、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで前記設定内容を変更する、
キュー処理方法。
【請求項１０】
通信ネットワークを介して受けたリクエストをキューイングし、リクエストに対する返答を行うためにキュー内のリクエストを処理させるためのキュー処理プログラムであって、
コンピュータに、
受信した共通処理によって一括して処理できる可能性を有するリクエストの内容に含まれる分類を決定するためのキーに応じて複数の分類から当該リクエストの分類を特定するステップと、
特定した分類に従ってリクエストを振り分けるステップと、
前記複数の分類のいずれかが割り当てられており、前記リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストを複数のリクエストキューにそれぞれ記憶するステップと、
単位時間あたりの受信リクエスト数が所定数以下となったときに成立する所定の分類変更条件が成立したことに応じて、分類の数を増加させることにより複数の分類の設定内容を変更するステップと、
前記リクエストキューに記憶されている複数のリクエストを読み出すステップと、
読み出した複数のリクエストに返答するための返答情報を当該リクエストキュー毎に生成する返答処理の一部を共通処理により一括して行うステップと、を実行させ、
前記複数の分類は、それぞれ、前記返答処理の一部が共通処理によって実行される複数のリクエストが同一分類に属するように、前記リクエストの内容毎に区分けされてあらかじめ設定されており、
前記変更するステップは、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで前記設定内容を変更する、
キュー処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リクエストに対する処理の一部または全部を共通処理により一括して実行し得る分類毎に複数のリクエストに対する処理を実行し、複数のリクエストに対する処理を効率的に実行することができるキューイング装置、キュー処理方法およびキュー処理プログラムに関する。
【背景技術】
【０００２】
従来、サーバ／クライアント方式のシステムにおいては、サーバに対するクライアントからのリクエストの待ち行列であるリクエストキューを格納し、複数のサーバプロセスもしくはサーバコンピュータによってリクエストキューから順次リクエストを取り出し、各リクエストに対する処理をしたあと、そのリクエスト元に対する返答を行っている。
【０００３】
上記のようなクライアントからの要求に対する返答を行うための要求返答処理においては、サービスの質を保証するために、帯域やアプリケーション属性、あるいは要求元のＩＰアドレスによってリクエストキューをグループ化する方法が提案されている（例えば、特許文献１参照）。
【０００４】
また、要求返答処理において、複数の要求を一括して処理するために、検索要求の中のキーが同一であるものを同じ領域に格納し、同じ領域に格納されている検索要求に対する処理をまとめて実行するものもある（例えば、特許文献２参照）。
【０００５】
【特許文献１】特開２００２−１１１７２１号公報
【特許文献２】特開平４−１２３２３８号公報（第３頁右上欄第１６行−右下欄第９行、図２）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、要求返答処理を実行するシステムでは、リクエストの増加に比例してサーバでの処理能力を必要とするため、全てのリクエストに対して一定時間内の処理を保証するためには、例えば一時的な過負荷状態であっても、そのすべてを処理可能な能力でサーバを構成・運用する必要がある。しかし、一般には、過負荷状態が発生せず問題とならない可能性もあるし、たとえ過負荷状態となっても時間的にわずかなことが多いため、過負荷に対する備えを万全なものとしておくことは、システムの性能面やコスト面において困難である。
【０００７】
従って、全部のリクエストに対する要求返答処理を実行することが困難な状況となった場合には、例えば、特許文献１のように、優先度の低いキューに格納されたリクエストの処理を断念することで対応している。
【０００８】
なお、特許文献２では、複数の要求を一括して処理するようにしているが、同一の検索結果をそのまま返答することができる同一の要求が複数ある場合にしか対応することができない。すなわち、返答内容が一部でも異なる場合や、要求タイミングによって返答内容を異らせる必要がある場合などには、一括処理により対応することができない。よって、過負荷に対する備えが万全なものとなっているとは言えない。
【０００９】
本発明は、上述した問題を解消し、複数のリクエストに対する返答を行うための処理を効率よく実行することができ、一時的な高負荷時であっても、通常の運用時と同じサーバの処理能力で全てのリクエストを処理することができるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明によるキューイングシステムは、通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを処理するキューイングシステム（例えばキューイングシステム１００）であって、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定し、特定した分類に従ってリクエストを振り分けるリクエスト振分手段（例えば振り分け器２１）と、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキュー（例えばリクエストキュー２２ａ，２２ｂ，２２ｃ）と、リクエストキューに記憶されている複数のリクエストに返答するための返答情報を、当該リクエストキュー毎に生成する返答処理（例えばステップＳ３０２〜Ｓ３０５）を実行する返答処理実行手段（例えば、図１に示すサーバ３１，３２，３３、あるいは図４に示すサーバ３１）とを備え、複数の分類は、それぞれ、返答処理の一部または全部が共通処理（例えばステップＳ３０２）によって実行される複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されており、返答処理実行手段は、リクエストキューに記憶されている複数のリクエストを読み出し（例えばステップＳ３０１）、当該複数のリクエストに対する返答を行うための返答処理の一部または全部（例えば、データベース４０，４１，４２の記憶内容を検索する処理、検索結果に応じて各種の判定を行う処理、判定結果に応じて返答情報を生成する処理などの各種の処理のうちの少なくとも一部）を共通処理により一括して行うことを特徴とする。
【００１１】
返答処理実行手段が、返答処理にて、各リクエスト毎の個別処理を実行する必要があるか否か判定し（例えばステップＳ３０３）、必要があれば個別処理（例えばステップＳ３０４）を実行して各リクエスト毎に返答するために当該リクエスト毎の返答情報を生成するようにしてもよい。
【００１２】
所定の分類変更条件が成立したことに応じて（例えばステップＳ２０１）、複数の分類の設定内容を変更する分類設定変更手段（例えば分類変更部２３）を備え、分類設定変更手段が、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行する（ステップＳ２０２）ことで設定内容を変更するようにしてもよい。
【００１３】
分類変更条件は、単位時間あたりに受信したリクエスト数が所定数（例えば１万件）以上となったときに成立し、分類設定変更手段が、分類変更条件が成立したときに、分類の数を減少（例えば３分類から２分類に減少させる）させて各分類に属するリクエストの範囲を拡大させる処理を実行するようにしてもよい。
【００１４】
分類変更条件は、所定の変更指示（例えばキューイング装置２０が備える入力装置を用いたシステム管理者による分類の変更指示）があったときに成立し、分類設定変更手段は、変更指示に従って設定内容を変更する構成とされていてもよい。
【００１５】
複数の返答処理実行手段（例えばサーバ３１，３２，３３）を備え、複数の返答処理実行手段は、それぞれ、リクエストキューのいずれかに割り当てられ（例えば、各サーバ３１，３２，３３がそれぞれリクエストキュー２２ａ，２２ｂ，２２ｃに割り当てられる）、割り当てられたリクエストキューに記憶されている複数のリクエストに返答するために返答処理を実行し、分類変更手段が、所定の分類変更条件が成立したときに、複数の返答処理実行手段それぞれにおけるリクエストキューの割り当てを変更するようにしてもよい。
【００１６】
リクエストは、周辺地図を要求するための位置情報を含み、複数の分類は、それぞれ、位置情報が示す位置の範囲毎に区分けされてあらかじめ設定されており、返答処理実行手段が、地図情報が記憶されている地図データベースを検索し、リクエストキューに記憶されている複数のリクエストに応じたそれぞれの周辺地図を含む共通地図を生成する共通処理を実行するようにしてもよい。すなわち、キューイングシステムが、リクエストに応じて周辺地図を提供するための地図情報システム１００ａであってもよい。
【００１７】
リクエストは、チケット予約を要求するための予約依頼情報を含み、複数の分類は、それぞれ、少なくともチケット予約の受付けを行うイベント毎に区分けされてあらかじめ設定されており、返答処理実行手段が、チケットの予約状況情報が記憶されているチケットデータベースを検索し、リクエストキューに記憶されている複数のリクエストに応じて当該リクエストの一部または全部について予約を受け付けるか否かを判定し、その判定結果に応じて当該リクエストの一部または全部について共通の予約結果メッセージを生成する共通処理を実行する構成とされていてもよい。すなわち、キューイングシステムが、リクエストに応じてチケットの予約受付を行うためのチケット予約システム１００ｂであってもよい。
【００１８】
リクエストは、答案の添削を要求するための添削依頼情報を含み、複数の分類は、それぞれ、試験問題毎に区分けされてあらかじめ設定されており、返答処理実行手段が、試験問題の解答情報が記憶されているチケットデータベースを検索し、リクエストキューに記憶されている複数のリクエストに応じて当該リクエストの一部または全部について正解とするか否かを判定し、その判定結果に応じて当該リクエストの一部または全部について共通の添削結果メッセージを生成する共通処理を実行する構成とされていてもよい。すなわち、キューイングシステムが、リクエストに応じて試験問題の答案の正否を判定するための試験添削システム（試験採点システム１００ｃ）であってもよい。
【００１９】
また、本発明のキューイング装置は、通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを所定の分類毎に振り分けて記憶するキューイング装置（例えばキューイング装置２０）であって、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定し、特定した分類に従ってリクエストを振り分けるリクエスト振分手段と、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキューとを備え、複数のリクエストキューは、それぞれ、当該リクエストキューに記憶されているリクエストを通信ネットワークを介して読み出して当該リクエストキューに記憶されている複数のリクエストに返答するための返答情報を生成する返答処理を実行する返答処理実行装置に対し、当該リクエストキュー毎に返答情報を生成させて返答処理の一部または全部を共通処理により一括して実行させるために、割り当てられている分類のリクエストを記憶し、リクエスト振分手段が振り分けの際に用いる複数の分類は、それぞれ、返答処理の一部または全部が共通処理によって実行される複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されていることを特徴とする。
【００２０】
所定の分類変更条件が成立したことに応じて、複数の分類の設定内容を変更する分類設定変更手段を備え、分類設定変更手段が、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで設定内容を変更するように構成されていてもよい。
【００２１】
分類変更条件は、単位時間あたりに受信したリクエスト数が所定数以上となったときに成立し、分類設定変更手段が、分類変更条件が成立したときに、分類の数を減少させて各分類に属するリクエストの範囲を拡大させる処理を実行するように構成されていてもよい。
【００２２】
分類変更条件は、所定の変更指示があったときに成立し、分類設定変更手段が、変更指示に従って設定内容を変更するように構成されていてもよい。
【００２３】
返答処理実行装置によってリクエストキュー毎に生成された返答情報を通信ネットワークを介して受信する返答情報受信手段と、受信した返答情報と、当該返答情報によりリクエストに対する返答内容が一意に定まることとなったと認識したとき（例えば、予約受付が終了している場合）にはその旨を示す情報（例えば予約受付が終了したことを示す情報）とを、リクエストキューに対応付けして保存する返答情報保存手段と、所定のリクエストキューに記憶されているリクエストに対する返答内容が一意に定まることとなっている場合（例えば予約受付が終了したことを示す情報が記憶されている場合）には、返答処理実行装置に返答処理を実行させることなく、当該所定のリクエストキューに記憶されている各リクエストそれぞれのリクエスト元に向けて、返答情報保存手段に保存されている返答情報（例えば、予約できない旨の共通メッセージ）を通信ネットワークを介して送信する返答情報送信手段とを備えていてもよい。
【００２４】
また、本発明のキューイング装置は、通信ネットワークを介して受けたリクエストをキューイングして、リクエストに対する返答を行うためにキュー内のリクエストを所定の分類毎に振り分けて記憶するキューイング装置であって、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定し、特定した分類に従ってリクエストを振り分けるリクエスト振分手段と、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストをそれぞれ記憶する複数のリクエストキューと、リクエストキューに記憶されているリクエストのうち所定個（例えば１個、２個）のリクエストを通信ネットワークを介して読み出して当該所定個の読み出したリクエストに返答するための返答情報を生成する返答処理を実行する返答処理実行装置から、当該所定個のリクエスト毎に生成された返答情報を通信ネットワークを介して受信する返答情報受信手段と、受信した返答情報を、該当するリクエストのリクエスト元に向けて通信ネットワークを介して送信する返答情報送信手段とを備え、リクエスト振分手段が振り分けの際に用いる複数の分類は、それぞれ、返答処理実行装置によって生成される返答情報が共通して使用され得る複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されており、返答情報送信手段は、受信した返答情報が示す返答内容が所定内容（例えば予約できない旨のメッセージ）であったときには、対応するリクエストキューに記憶されている各リクエストそれぞれのリクエスト元に向けて、当該受信した返答情報と同一の返答情報（例えば予約できない旨のメッセージ）を送信するとともに、当該リクエストキューに記憶されていたリクエストを削除する処理を実行することを特徴とする。
【００２５】
また、本発明のキュー処理方法は、通信ネットワークを介して受けたリクエストをキューイングし、リクエストに対する返答を行うためにキュー内のリクエストを処理するキュー処理方法であって、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定するステップと、特定した分類に従ってリクエストを振り分けるステップと、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストを複数のリクエストキューにそれぞれ記憶するステップと、リクエストキューに記憶されている複数のリクエストを読み出すステップと、読み出した複数のリクエストに返答するための返答情報を当該リクエストキュー毎に生成する返答処理の一部または全部を共通処理により一括して行うステップとを含み、複数の分類は、それぞれ、返答処理の一部または全部が共通処理によって実行される複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されていることを特徴とする。
【００２６】
所定の分類変更条件が成立したことに応じて、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで、複数の分類の設定内容を変更するステップを含む構成とされていてもよい。
【００２７】
さらに、本発明のキュー処理プログラムは、通信ネットワークを介して受けたリクエストをキューイングし、リクエストに対する返答を行うためにキュー内のリクエストを処理させるためのキュー処理プログラムであって、コンピュータ（例えばキューイング装置２０、サーバ３１，３２，３３）に、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定するステップと、特定した分類に従ってリクエストを振り分けるステップと、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストを複数のリクエストキューにそれぞれ記憶するステップと、リクエストキューに記憶されている複数のリクエストを読み出すステップと、読み出した複数のリクエストに返答するための返答情報を当該リクエストキュー毎に生成する返答処理の一部または全部を共通処理により一括して行うステップとを実行させ、複数の分類は、それぞれ、返答処理の一部または全部が共通処理によって実行される複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されていることを特徴とする。
【００２８】
コンピュータに、さらに、所定の分類変更条件が成立したことに応じて、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで、複数の分類の設定内容を変更するステップを実行させるように構成されていてもよい。
【発明の効果】
【００２９】
本発明によれば、共通処理によって一括して処理できる可能性を持つ分類をあらかじめ設定し、その分類に属する複数のリクエストを、その分類に対応して設けられたリクエストキューにまとめて格納する構成としたので、１つのリクエストキューに格納されている複数のリクエストに返答するための処理の一部または全部を、一回の共通処理で同時に処理することができるようになり、複数のリクエストに対する返答を行うための処理を効率よく実行することができ、サーバの処理負荷を軽減させることができ、通常の運用時と同様のサーバ能力のままで一時的な高負荷時における対応能力を向上させることができる。よって、一時的な高負荷時であっても全てのリクエストに対する返答を完了させる期待度を向上させることができる。
【００３０】
また、サーバの負荷が増大したときに、分類数を減少させる分類変更を行い、共通処理で対応することとする範囲を拡大させる構成としたことで、各サーバの負荷を軽減させることができる。よって、一時的に負荷が増大した場合であっても、サーバの処理能力を向上させることなく、リクエストに対応した処理を実行することができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の一実施の形態について図面を参照して説明する。  図１は、本発明の一実施の形態におけるキューイング装置２０を含むキューイングシステム１００の構成の例を示すブロック図である。キューイングシステム１００は、クライアントコンピュータ（以下、「クライアント」という）１０と、キューイング装置２０と、複数のサーバコンピュータ（以下、単に「サーバ」という）３１，３２，３３とを含む。
【００３２】
クライアント１０とキューイング装置２０は、インターネットなどの通信ネットワークに接続されている。また、キューイング装置２０と、各サーバ３１，３２，３３は、専用回線などの通信ネットワークによって接続されている。なお、クライアント１０は、いくつ設けられていてもよい。
【００３３】
クライアント１０は、例えばパーソナルコンピュータなどの情報処理装置によって構成され、本システム１００の利用者によって管理される。ユーザ端末４０は、通信ネットワークに接続するための接続機能や、例えばＨＴＭＬ（HyperText Markup Language）などのマークアップ言語を表示するためのブラウザ機能などの各種の機能を備えている。
【００３４】
キューイング装置２０は、例えばＷＷＷ（World Wide Web）サーバなどの情報処理装置によって構成される。キューイング装置２０は、クライアント１０から通信ネットワークを介して送信されてきたリクエストを、そのリクエストの内容に応じた分類に振り分けて保持する機能などの各種の機能を有する。
【００３５】
リクエストは、クライアントを特定するためのユーザ情報と、リクエストの内容を示す情報とを含む。リクエストの内容を示す情報には、分類を決定するためのキーとなる情報（例えば、周辺地図をリクエストする場合には、周辺地図の中心位置を示す位置情報（実施例１参照））が含まれる。
【００３６】
キューイング装置２０は、振り分け器２１と、複数のリクエストキュー２２ａ，２２ｂ，２２ｃと、分類変更部２３とを含む。各リクエストキュー２２ａ，２２ｂ，２２ｃは、あらかじめ「分類」が割り当てられている。なお、キューイング装置２０には装置２０全体を制御する図示しない制御手段が備えられ、この制御手段は、装置２０が備える記憶媒体（例えばＲＯＭ）に格納されている制御プログラムに従って処理を実行する。この例では、制御手段が、振り分け器２１と分類変更部２３とにそれぞれ搭載されているものとする。
【００３７】
振り分け器２１は、クライアント１０から送信されてきたリクエストを、そのリクエストの内容と、各リクエストキュー２２ａ，２２ｂ，２２ｃに割り当てられている分類とに従って、各リクエストキュー２２ａ，２２ｂ，２２ｃに振り分ける処理を実行する機能を有する。
【００３８】
各リクエストキュー２２ａ，２２ｂ，２２ｃは、それぞれ、例えばＲＡＭなどの書き換え可能な記憶媒体によって構成される。各リクエストキュー２２ａ，２２ｂ，２２ｃには、それぞれ、あらかじめ割り当てられた分類に適合するリクエストがキューイング（リクエストの待ち行列として格納されることを意味する）される。
【００３９】
各リクエストキュー２２ａ，２２ｂ，２２ｃに割り当てられる「分類」は、例えば、リクエストの内容の範囲別に区分けされた分類とされる。具体的には、取り扱う可能性のある各リクエストを、その内容に応じてリクエストＡ，Ｂ，Ｃの３つの分類のいずれかに割り当てることにあらかじめ定めておくようにする。この場合、各リクエストＡ，Ｂ，Ｃは、各サーバ３１，３２，３３が共通処理によって一括して処理できる可能性を有するリクエストの内容の範囲毎に区分けされる。そして、あらかじめ定められているリクエストの各分類（リクエストＡ，Ｂ，Ｃ）が、それぞれ各リクエストキュー２２ａ，２２ｂ，２２ｃのいずれかに割り当てられる。
【００４０】
分類変更部２３は、各リクエストキュー２２ａ，２２ｂ，２２ｃに割り当てられているリクエストの分類を任意に変更する機能を有する。例えば、分類変更部２３は、リクエストの分類の数を変更するとともに、各分類の範囲を変更し、変更後の分類と各リクエストキュー２２ａ，２２ｂ，２２ｃとの対応関係を決定する処理を実行する。さらに、分類変更部２３は、分類を変更したときに、各リクエストキュー２２ａ，２２ｂ，２２ｃと、各リクエストキュー２２ａ，２２ｂ，２２ｃに記憶されているリクエストに応じた処理を実行するサーバ３１，３２，３３との新たな対応関係を決定し、その決定結果を必要な各サーバ３１，３２，３３に通知する機能を有する。
【００４１】
なお、分類変更部２３は、分類の変更などを自動的に処理する機能を有するが、例えばシステム管理者がキューイング装置２０の外部より任意に分類の変更指示を行うためのインタフェースとして用いられるようにしてもよい。このように構成すれば、システム管理者による分類変更指示に従って、分類の変更を行うことができ、システム管理を円滑に遂行することができるようになる。
【００４２】
各サーバ３１，３２，３３は、それぞれ、例えばＷＷＷサーバなどの情報処理装置によって構成される。各サーバ３１，３２，３３は、それぞれ、キューイング装置２０を介して入力したクライアント１０からのリクエストに応じて各種の処理を行う機能などの各種の処理を実行するサーバ装置である。
【００４３】
各サーバ３１，３２，３３は、各リクエストキュー２２ａ，２２ｂ，２２ｃに格納されているリクエストすなわちキュー内のリクエストを読み出し、そのリクエストに応じた処理を実行する機能を有する。
【００４４】
なお、キューイング装置２０および各サーバ３１，３２，３３は、各サーバ３１，３２，３３を用いて提供される所定のサービス（例えば、地図や飲食店などの検索サービス）の提供者によって管理される。
【００４５】
次に、本発明の一実施の形態におけるキューイングシステム１００の動作について図面を参照して説明する。
【００４６】
先ず、キューイング装置２０によってリクエストが振り分けされて各リクエストキュー２２ａ，２２ｂ，２２ｃに保存されるまでの処理について説明する。図２は、キューイング装置２０におけるリクエストを振り分けて保存するリクエスト格納処理の例を示すフローチャートである。
【００４７】
なお、キューイング装置２０には、分類の初期設定として、リクエストの分類と、各分類と各リクエストキュー２２ａ，２２ｂ，２２ｃとの対応関係とがあらかじめ設定されている。ここでは、初期設定として、リクエストの内容に応じた３つの分類Ａ，Ｂ，Ｃが定められ、各分類Ａ，Ｂ，Ｃにそれぞれ各リクエストキュー２２ａ，２２ｂ，２２ｃが対応付けされているものとする。なお、初期設定は、例えばキューイング装置２０の起動時に自動的に設定されるようにしてもよく、システム管理者が事前に装置２０が備える入力装置（例えばキーボードやマウス）を操作して設定するようにしてもよい。
【００４８】
リクエスト格納処理において、キューイング装置２０の分類変更部２３は、分類変更条件が成立したか否か確認し（ステップＳ２０１）、成立していれば成立した条件の内容に応じて分類変更処理を実行する（ステップＳ２０２）。
【００４９】
分類変更条件は、サーバアプリケーションの種類により定められていてもよいし、サーバの台数、想定されるリクエストの処理数、現在のリクエストキューに格納されているリクエスト数などにより定められていてもよい。また、分類変更処理は、サーバ管理者の指示によって実行する構成としてとしてもよいし、現在のサーバの運用状況によって自動的に実行するようにしてもよい。
【００５０】
この例では、分類変更条件には、例えば、単位時間あたりの受信リクエスト数が所定数（例えば１万件）を超えたときに成立する条件（分類変更条件Ｘ）や、単位時間あたりの受信リクエスト数が所定数（例えば５千件）以下となったときに成立する条件（分類変更条件Ｙ）など複数の条件があるものとする。また、分類変更処理は、分類変更条件が成立したときに自動的に実行されるものとする。
【００５１】
ステップＳ２０２の分類変更処理では、成立した分類変更条件の内容に応じて、分類の数や、新たな各分類と各リクエストキュー２２ａ，２２ｂ，２２ｃとの対応関係を変更するための処理が実行される。なお、分類変更部２３は、分類変更処理にて、各リクエストキュー２２ａ，２２ｂ，２２ｃと、各リクエストキュー２２ａ，２２ｂ，２２ｃに記憶されているリクエストに対応する処理を実行する各サーバ３１，３２，３３との新たな対応関係をも決定する。この決定結果は、分類変更部２３により必要なサーバ３１，３２，３３にそれぞれ通知される。
【００５２】
具体的には、分類変更条件Ｘが成立したときには、各サーバ３１，３２，３３の負荷が大きくなっているので、分類の数を例えば３分類（分類Ａ，Ｂ，Ｃ）から２分類（分類ａ，ｂ）に減らし、分類ａ，ｂに各リクエストキュー２２ａ，２２ｂを対応させるように変更する。この場合、リクエストキュー２２ｃは使用されない。なお、サーバ３３は、例えばリクエストキュー２２ｂに格納されているリクエストに対応した処理をサーバ３２と分担して行うようにすればよい。また、サーバ３３が、例えば、リクエストキュー２２ａに格納されているリクエストに対応した処理をサーバ３１と分担して行うとともに、リクエストキュー２２ｂに格納されているリクエストに対応した処理をサーバ３２と分担して行うようにしてもよい。
【００５３】
上記のように分類変更を行えば、負荷が増大してきたときに、共通処理で対応することとする範囲を広げることができ、各サーバ３１，３２，３３の負荷を軽減させることができる。よって、各サーバ３１，３２，３３の処理能力を向上させることなく、リクエストに対応した処理を実行することができる。
【００５４】
また、具体的には、分類変更条件Ｙが成立したときには、各サーバ３１，３２，３３の負荷が小さくなっているので、分類の数を例えば３分類（分類Ａ，Ｂ，Ｃ）から４分類（分類ｘ、ｙ、ｚ、ｖ）に増やし、分類ｘ、ｙ、ｚ、ｖに各リクエストキュー２２ａ，２２ｂ，２２ｃ，２２ｄ（リクエストキュー２２ｄは図示されていない）を対応させるように変更する。なお、サーバ３３は、例えばリクエストキュー２２ｃおよびリクエストキュー２２ｄに格納されているリクエストに対応した処理を順次行うようにすればよい。また、例えば、リクエストキュー２２ｄに格納されているリクエストに対応した処理を、サーバ３１，３２，３３のうちの少なくとも２つで分担して行うようにしてもよい。
【００５５】
上記のように分類変更を行えば、負荷が縮小してきたときに、共通処理で対応することとする範囲を狭めることができ、各サーバ３１，３２，３３の処理能力を十分に発揮させてクライアントコンピュータ１０への返答を早期に行うことができる。
【００５６】
次いで、クライアント１０からのリクエストを受信すると（ステップＳ２０３）、キューイング装置２０の振り分け器２１は、受信したリクエストの内容に応じてそのリクエストがどの分類に属するか判定し、その判定結果に応じて振り分け先を決定し、振り分け先のリクエストキュー２２ａ，２２ｂ，２２ｃにリクエストを送信する（ステップＳ２０４）。
【００５７】
そして、リクエストキュー２２ａ，２２ｂ，２２ｃは、送信されてきたリクエストをそれぞれ保存する（ステップＳ２０５）。よって、各リクエストキュー２２ａ，２２ｂ，２２ｃに、それぞれ、割り当てられている分類のリクエストが保存される。すなわち、各リクエストキュー２２ａ，２２ｂ，２２ｃに保存されるリクエスト群は、それぞれ、各サーバ３１，３２，３３が一括処理できる可能性のあるものとなっている。
【００５８】
上記のようにして、クライアント１０などの各クライアントからのリクエストが、一括処理できる可能性のあるいずれかの分類に振り分けされて各リクエストキュー２２ａ，２２ｂ，２２ｃに保存される。すなわち、各リクエストキュー２２ａ，２２ｂ，２２ｃに、それぞれ、一括処理できる可能性のあるリクエスト群が保存される。
【００５９】
次に、各クライアントからのリクエストが各リクエストキュー２２ａ，２２ｂ，２２ｃに振り分けされて保存されたあと、各サーバ３１，３２，３３が各リクエストに応じた処理を実行し、各リクエストに対する返答を行う処理について説明する。
【００６０】
図３は、キューイングシステム１００における各サーバ３１，３２，３３が実行するリクエスト対応処理の例を示すフローチャートである。なお、ここでは、クライアント１０からのリクエストが各リクエストキュー２２ａ，２２ｂ，２２ｃに既に記憶されているものとする。また、ここでは、サーバ３１が、対応するリクエストキュー２２ａに記憶されている各リクエストに応じた処理を実行する場合を例に説明する。
【００６１】
リクエスト対応処理は、例えば、各サーバ３１，３２，３３それぞれにおいて、一定時間毎に実行される。一定時間は、例えば返答を早期に行う必要があるかなどの取り扱うリクエストの内容に応じてあらかじめ定められる。具体的には、一定時間は、例えば、１秒ごと、１分ごと、１時間ごとなどのように定められる。なお、一定時間毎に限らず、各リクエストキュー２２ａ，２２ｂ，２２ｃにリクエストキューが保存されたことをキューイング装置２０から通知されたときに、リクエスト対応処理を実行するようにしてもよい。
【００６２】
リクエスト対応処理において、サーバ３１は、リクエストキュー２２ａに記憶されている全てのリクエストを読み出し（ステップＳ３０１）、全リクエストについての共通処理を実行する（ステップＳ３０２）。
【００６３】
共通処理とは、複数のリクエストそれぞれに返答できるようにするために一括して実行される処理であって、複数のリクエストに対するそれぞれの処理を網羅した共通の処理を意味する。
【００６４】
なお、共通処理では、全てのリクエストについて一括して処理される場合と、全リクエストのうちの一部で構成される複数のリクエストについて一括して処理される場合とがある。後者の場合には、ステップＳ３０２にて、全てのリクエストを網羅するまで共通処理が複数回実行されることになる。
【００６５】
共通処理を終えると、サーバ３１は、個別処理が必要か否か確認する（ステップＳ３０３）。すなわち、共通処理のみによって全てのリクエストに対する返答を行うことができるか否か確認する。例えば、共通処理の結果により全てのリクエストの返答を行うことができる場合は個別処理を行う必要がないことになり、共通処理の結果では全てのリクエストの返答を行うことができない場合（例えば、返答する情報の内容が不足している場合）は個別処理を行う必要があることになる。
【００６６】
個別処理が必要であると判定した場合には、サーバ３１は、個別処理が必要な各リクエストについて、個別処理を実行する（ステップＳ３０４）。
【００６７】
各リクエストに対する返答を示す返答情報の作成を終えると、サーバ３１は、通信ネットワークを介して、リクエスト元であるクライアント１０などの各クライアントに向けて返答情報を送信する（ステップＳ３０５）。この処理結果は、全てのリクエストに対して共通の結果である場合と、全リクエストの一部または全部について個別の結果である場合とがある。
【００６８】
以上説明したように、上述した一実施の形態では、クライアントからのリクエストをあらかじめ定められた分類に振り分けて、分類毎に設けられたリクエストキューに格納し、各リクエストキューに保存されたリクエストの全部または一部を一括して処理する構成としたので、リクエストに対応する各サーバの処理の負荷を軽減させることができる。
【００６９】
また、上述したように、共通処理によって一括して処理できる可能性を持つ分類をあらかじめ設定し、その分類に属する複数のリクエストを、その分類に対応して設けられたリクエストキューにまとめて格納する構成としたので１つのリクエストキューに格納されている複数のリクエストに返答するための処理の一部または全部を、一回の共通処理で同時に処理することができるようになり、各サーバの処理負荷を軽減させることができ、通常の運用時と同様のサーバ能力のままで一時的な高負荷時における対応能力を向上させることができる。よって、一時的な高負荷時であっても全てのリクエストに対する返答を完了させる期待度を向上させることができる。
【００７０】
また、上述したように、サーバ３１，３２，３３の負荷が増大したときに、分類数を減少させる分類変更を行い、共通処理で対応することとする範囲を拡大させる構成としたことで、各サーバ３１，３２，３３の負荷を軽減させることができる。よって、一時的に負荷が増大した場合であっても、各サーバ３１，３２，３３の処理能力を向上させることなく、リクエストに対応した処理を実行することができる。
【００７１】
なお、上述した実施の形態では、分類変更条件が成立したか否かを監視し、条件が成立したときに分類変更処理を行う構成としていたが、分類を変更することなく初期設定時のまま固定する構成（例えば、ステップＳ２０１，Ｓ２０２を実行しない構成）としてもよい。この場合、分類変更部２３は、システム管理者により初期設定の変更指示があったことにもとづいて、分類の内容の初期設定を変更する処理を実行する。
【００７２】
また、上述した実施の形態では、３つのサーバ３１，３２，３３を設ける構成としていたが、全部のリクエストキューに格納されている各リクエストに対応する処理を１つのサーバにより行う構成としてもよい。この場合、例えば図４に示すように、リクエストキュー２２ａ，２２ｂ，３３ｃに格納されているそれぞれのリクエスト群に対応する処理を、１つのサーバ３１が順次実行する構成とすればよい。このような構成としても、上述した効果と同様の効果を得ることができる。
【００７３】
また、上述した実施の形態では、キューイング装置２０とサーバ３１，３２，３３とをそれぞれ別の情報処理装置で構成していたが、キューイング装置２０とサーバ３１，３２，３３とが同一の情報処理装置により構成されていてもよい。
【００７４】
また、上述した実施の形態におけるキューイング装置２０や各サーバ３１，３２，３３には、キューイング装置２０や各サーバ３１，３２，３３に、通信ネットワークを介して受けたリクエストをキューイングさせ、リクエストに対する返答を行うためにキュー内のリクエストを処理させるためのキュー処理プログラムが搭載されている。例えば、キュー処理プログラムは、キューイング装置２０や各サーバ３１，３２，３３に、受信したリクエストの内容に応じて複数の分類から当該リクエストの分類を特定するステップ（ステップＳ２０４）と、特定した分類に従ってリクエストを振り分けるステップ（ステップＳ２０５）と、複数の分類のいずれかが割り当てられており、リクエスト振分手段によって振り分けされたリクエストのうち、割り当てられている分類のリクエストを複数のリクエストキュー２２ａ，２２ｂ，２２ｃにそれぞれ記憶するステップ（ステップＳ２０５）と、リクエストキュー２２ａ，２２ｂ，２２ｃに記憶されている複数のリクエストを読み出すステップ（ステップＳ３０１）と、読み出した複数のリクエストに返答するための返答情報を当該リクエストキュー毎に生成する返答処理の一部または全部を共通処理により一括して行うステップ（ステップＳ３０２）とを実行させる制御プログラムである。なお、複数の分類は、それぞれ、返答処理の一部または全部が共通処理によって実行される複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けされてあらかじめ設定されている。
【００７５】
また、キュー処理プログラムは、キューイング装置２０に、さらに、所定の分類変更条件が成立したことに応じて、分類の内容を変更する処理を実行するとともに、変更後の複数の分類それぞれにリクエストキューのいずれかを割り当てる処理を実行することで、複数の分類の設定内容を変更するステップ（例えばステップＳ２０１，Ｓ２０２）を実行させる制御プログラムである。
【実施例１】
【００７６】
以下、第１の実施例として、上述した本発明の一実施の形態におけるキューイングシステム１００を、地図情報の閲覧リクエストをキューイングするための地図情報システム１００ａに適用した例について説明する。
【００７７】
図５は、地図情報システム１００ａの構成の例を示すブロック図である。地図情報システム１００ａは、クライアント１０（図５では図示せず）と、キューイング装置２０と、サーバ３１，３２，３３と、地図情報データベース４０とを含む。
【００７８】
地図情報データベース４０は、例えばハードディスクなどの大容量記憶媒体によって構成され、地図を表示するためのベクトルデータや、地図に表示される記号や図形などの各種のデータが保存されている。
【００７９】
この例では、各リクエストキュー２２ａ，２２ｂ，２２ｃは、それぞれ、一定の各地域ブロックに対応して分類されているものとする。
【００８０】
また、この例では、各サーバ３１，３２，３３は、それぞれ、対応するリクエストキュー２２ａ，２２ｂ，２２ｃに格納されているリクエストに従って、地図情報データベース４０からベクトルデータを読み出し、２次元の平面地図の作成して返答を行う機能を有している。２次元の平面地図は、例えばＧＩＦ（Graphics Interchange Format）などの画像フォーマットで作成される。
【００８１】
次に、この例におけるリクエスト格納処理について説明する。リクエスト格納処理において、キューイング装置２０の分類変更部２３は、クライアント１０からのリクエストを受信すると（ステップＳ２０３参照）、リクエストの内容に応じて分類を決定する（ステップＳ２０４参照）。
【００８２】
この例では、リクエストには、例えばクライアント１０のアドレスを特定するためのユーザ情報と、周辺地図を希望する場所を特定するための場所情報とが含まれる。場所情報には、例えば、緯度および経度を示す情報や、地名、あるいは所在地を示す情報が用いられる。
【００８３】
また、リクエストの分類は、例えば、そのリクエストにおける場所情報が示す地点（例えば緯度と経度によって特定される地点）が含まれている地域ブロックが、どの分類とされているかによって決定される。すなわち、受信したリクエストにおける場所情報が示す地点を含む地域ブロックに割り当てられている分類が、リクエストの分類とされる。
【００８４】
具体的には、例えば図６に示すように、地域ブロックがブロックＡ〜ブロックＣの範囲の３ブロックに分類され、それぞれのブロックＡ〜Ｃに対応して分類Ａ〜Ｃが割り当てられている場合、受信したリクエストが示す場所がブロックＡの範囲に含まれていたとすると、ブロックＡに割り当てられている分類Ａがリクエストの分類とされる。
【００８５】
なお、地域ブロックＡ〜Ｃは、周辺地図の提供要求のためのリクエストに含まれる場所情報が示す地点が指定され得る範囲とされている。この例では、リクエストに含まれる場所情報が示す地点を中心とした所定範囲の周辺地図が提供されるため、地域ブロックＡ〜Ｃの範囲は、図６に示すように、リクエストに応じて作成される地図の範囲よりも狭い範囲となっている。なお、リクエストに応じて作成される地図は、リクエストに含まれる場所情報が示す地点を含むものであればよく、リクエストに含まれる場所情報が示す地点を中心とした地図でなくてもよい。
【００８６】
次いで、振り分け器２１は、決定した分類Ａに対応して割当されているリクエストキュー（例えばリクエストキュー２２ａ）を振り分け先のリクエストキューに決定し、リクエストキュー２２ａに向けてリクエストを送信する（ステップＳ２０４参照）。
【００８７】
そして、リクエストキュー２２ａは、送信されてきたリクエストを受信し、受信したリクエストを保存する（ステップＳ２０５参照）。
【００８８】
上記のようにして、各リクエストキュー２２ａ，２２ｂ，２２ｃに、それぞれ、あらかじめ割り当てられている分類の各リクエストが保存される。例えば、ブロックＡとリクエストキュー２２ａとを分類Ａとし、ブロックＢとリクエストキュー２２ｂとを分類Ｂとし、ブロックＣとリクエストキュー２２ｃとを分類Ｃとすることに各分類設定がなされていた場合には、各クライアントからの複数のリクエストが送られてくると、リクエストキュー２２ａにブロックＡ内の所定地点の周辺地図を要求する複数のリクエストが保存され、リクエストキュー２２ｂにブロックＢ内の所定地点の周辺地図を要求する複数のリクエストが保存され、リクエストキュー２２ｃにブロックＣ内の所定地点の周辺地図を要求する複数のリクエストが保存されることになる。
【００８９】
次に、この例におけるリクエスト対応処理について説明する。ここでは、サーバ３１が、対応するリクエストキュー２２ａに記憶されているリクエストに応じた処理を実行する場合を例に説明する。
【００９０】
リクエスト対応処理において、サーバ３１は、リクエストキュー２２ａに記憶されている全てのリクエストを読み出し（ステップＳ３０１参照）、全リクエストについての共通処理を実行する（ステップＳ３０２参照）。この例では、共通処理において、リクエストキュー２２ａに記憶されている各リクエストそれぞれの地図情報が示す各地点を含むブロックＡの周辺地図を一括して生成する処理を行う。具体的には、図７（Ａ）に示すような、５つのリクエストそれぞれの場所情報が示す各地点の周辺地図（地図Ａａ，地図Ａｂ，地図Ａｃ，地図Ａｄ，地図Ａｅ）を含む共通地図を生成する。
【００９１】
次いで、サーバ３１は、個別処理が必要か否か確認する（ステップＳ３０３参照）。この例では、共通処理により作成された周辺地図が、各リクエストそれぞれに返答するための周辺地図と一致していないため、サーバ３１は、個別処理が必要であると判断する。なお、各リクエストそれぞれに返答するための返答情報として、図７（Ａ）に示すような共通地図を共通に用いる場合には、サーバ３１は、個別処理は必要ないと判断する。なお、共通地図により返答するか個別処理により作成した個別の地図により返答するかは、あらかじめ決められているものとする。
【００９２】
個別処理が必要であると判定されると、サーバ３１は、各リクエストそれぞれに対応した個別地図を作成するための個別処理を実行する（ステップＳ３０４参照）。
【００９３】
個別処理では、サーバ３１は、共通地図から各リクエストに対応した周辺地図の地図領域をそれぞれ切り出して、各リクエストそれぞれに返答するための返答情報として用いる個別地図を作成する。個別地図は、例えば図７（Ｂ）に示すように、共通地図の一部を切り出して作成された地図であって、各リクエストそれぞれの場所情報が示す地点それぞれの周辺地図である。
【００９４】
返答情報である個別地図を作成すると、サーバ３１は、リクエスト元であるそれぞれのクライアントに向けて、通信ネットワークを介して返答情報を送信する処理を行う（ステップＳ３０５参照）。
【００９５】
上述したように、本例では、クライアントからの地図要求のリクエストを、あらかじめ地域ブロック毎に定められた分類別に別個のリクエストキューに格納し、各リクエストキューに保存された各リクエストに対応して共通地図を作成する一括処理を行う構成としたので、地図要求のリクエストに対応する各サーバの処理の負荷を軽減させることができる。
【００９６】
すなわち、共通処理によって共通地図を作成したあとその共通地図を用いて個別地図を作成する構成としたので、共通地図を作成することなく各リクエストに応じて個別地図を個別に作成する場合と比較すると、地図情報データベース４０から地図データを読み出す処理によるサーバの負荷や、個別地図を作成する処理によるサーバの負荷を軽減させることができる。
【００９７】
また、上述したように、共通処理によって一括して処理できる可能性を持つ分類をあらかじめ設定し、その分類に属する複数のリクエストを、その分類に対応して設けられたリクエストキューにまとめて格納する構成としたので１つのリクエストキューに格納されている複数のリクエストに返答するための処理の一部または全部を、一回の共通処理で同時に処理することができるようになり、サーバの処理負荷を軽減させることができ、通常の運用時と同様のサーバ能力のままで一時的な高負荷時における対応能力を向上させることができる。よって、一時的な高負荷時であっても全てのリクエストに対する返答を完了させる期待度を向上させることができる。
【実施例２】
【００９８】
以下、第２の実施例として、上述した本発明の一実施の形態におけるキューイングシステム１００を、チケットの予約の受付や管理を行うためのチケット予約システム１００ｂに適用した例について説明する。
【００９９】
図１０は、チケット予約システム１００ｂの構成の例を示すブロック図である。チケット予約システム１００ｂは、クライアント１０（図１０では図示せず）と、キューイング装置２０と、サーバ３１，３２，３３と、チケットデータベース４１とを含む。
【０１００】
チケットデータベース４１は、例えばハードディスクなどの大容量記憶媒体によって構成され、チケットの予約状況を示す情報などの各種のデータが保存されている。
【０１０１】
この例では、各リクエストキュー２２ａ，２２ｂ，２２ｃは、それぞれ、コンサートや公演などのチケットの予約を受け付けるイベント毎に分類されているものとする。なお、説明を簡単にするために、各イベントには座席の等級（例えばＳ席、Ａ席など）はないものとし、予約のリクエストは１席単位でなされるものとする。
【０１０２】
また、この例では、各サーバ３１，３２，３３は、それぞれ、対応するリクエストキュー２２ａ，２２ｂ，２２ｃに格納されているリクエストに従って、チケットデータベース４１からチケット情報を読み出し、空いている座席があるか否かを確認し、空いている座席の中から予約を受け付ける座席を決定し、予約を受け付けた座席を示す予約受付情報を作成して返答を行う機能を有している。
【０１０３】
次に、この例におけるリクエスト格納処理について説明する。リクエスト格納処理において、キューイング装置２０の分類変更部２３は、クライアント１０からのリクエストを受信すると（ステップＳ２０３参照）、リクエストの内容に応じて分類を決定する（ステップＳ２０４参照）。
【０１０４】
この例では、リクエストには、例えばクライアント１０のアドレスを特定するためのユーザ情報と、予約を希望するイベントを特定するためのイベント種別情報とが含まれる。イベント種別情報には、例えば、あらかじめ割り当てられている識別番号や、イベント名を示す情報が用いられる。
【０１０５】
また、リクエストの分類は、例えば、そのリクエストにおけるイベント種別情報が示すイベントがどの分類とされているかによって決定される。すなわち、受信したリクエストにおけるイベント種別情報が示すイベントに割り当てられている分類が、リクエストの分類とされる。
【０１０６】
具体的には、チケット予約の受け付けサービスの対象となるそれぞれのイベントＡ〜Ｃに対応して分類Ａ〜Ｃが割り当てられている場合、受信したリクエストが示すイベントがイベントＡであったとすると、イベントＡに割り当てられている分類Ａがリクエストの分類とされる。
【０１０７】
次いで、振り分け器２１は、決定した分類Ａに対応して割当されているリクエストキュー（例えばリクエストキュー２２ａ）を振り分け先のリクエストキューに決定し、リクエストキュー２２ａに向けてイベントＡのチケット予約要求を含むリクエストを送信する（ステップＳ２０４参照）。
【０１０８】
そして、リクエストキュー２２ａは、送信されてきたリクエストを受信し、受信したリクエストを保存する（ステップＳ２０５参照）。
【０１０９】
上記のようにして、各リクエストキュー２２ａ，２２ｂ，２２ｃに、それぞれ、あらかじめ割り当てられている分類の各リクエストが保存される。例えば、イベントＡとリクエストキュー２２ａとを分類Ａとし、イベントＢとリクエストキュー２２ｂとを分類Ｂとし、イベントＣとリクエストキュー２２ｃとを分類Ｃとすることに各分類設定がなされていた場合には、各クライアントからの複数のリクエストが送られてくると、リクエストキュー２２ａにイベントＡについてのチケット予約を要求する複数のリクエストが保存され、リクエストキュー２２ｂにイベントＢについてのチケット予約を要求する複数のリクエストが保存され、リクエストキュー２２ｃにイベントＣについてのチケット予約を要求する複数のリクエストが保存されることになる。
【０１１０】
次に、この例におけるリクエスト対応処理について説明する。ここでは、主として、サーバ３１が、対応するリクエストキュー２２ａに記憶されているリクエストに応じた処理を実行する場合を例に説明する。
【０１１１】
また、ここでは、イベントＡとリクエストキュー２２ａとを分類Ａとし、イベントＢとリクエストキュー２２ｂとを分類Ｂとし、イベントＣとリクエストキュー２２ｃとを分類Ｃとすることに各分類設定がなされているものとする。
【０１１２】
図９は、チケットデータベース４１の格納情報の一部を示す説明図である。チケットデータベース４１には、図９に示すように、各イベントについての現在の予約状況を示す予約状況情報が格納されている。ここでは、図９に示すように、イベントＡは、全座席数が２０００人分で現在１９００人分の座席が予約されており、イベントＢは、全座席数が５０００人分で現在全ての座席が予約されており、イベントＣは、全座席数が１００００人分で現在８５００人分の座席が予約されているものとする。
【０１１３】
リクエスト対応処理において、サーバ３１は、リクエストキュー２２ａに記憶されている全てのリクエストを読み出し（ステップＳ３０１参照）、全リクエストについての共通処理を実行する（ステップＳ３０２参照）。この例では、共通処理において、リクエストキュー２２ａに記憶されている各リクエストが示すイベントについての座席予約を一括して処理するとともに、予約の可否を示す応答メッセージを一括して作成する処理を実行する。
【０１１４】
具体的には、サーバ３１は、リクエストキュー２２ａに記憶されているリクエストの数を確認し、何席予約すべきなのかを判定する。次いで、チケットデータベース４１にイベントＡの残り座席数を問い合わせる。
【０１１５】
問い合わせの結果、必要数以上の残り座席数があれば、チケットデータベース４１におけるイベントＡの残り座席数を新たに予約する座席数減算し、全ての予約者に関する情報をチケットデータベース４１に格納する。
【０１１６】
具体的には、図９に示すように、イベントＡの残り座席数が１００席であるため、サーバ３１は、リクエストキュー２２ａに記憶されているリクエストの数（すなわち予約希望の数）が１００以下であれば、チケットデータベース４１に格納されている予約状況情報のうち、予約済数にリクエストの数を加算するとともに、残り座席数からリクエストの数を減算する処理を行う。そして、新たに予約を受け付けた予約者を特定するための情報をチケットデータベース４１に格納する。
【０１１７】
問い合わせの結果、必要数以上の残り座席数はないが、残り座席数はある場合には、リクエストメッセージの到着順に予約可能者を決定し、チケットデータベース４１におけるイベントＡの残り座席数を新たに予約する座席数減算し、予約可能者に関する情報をチケットデータベース４１に格納する。
【０１１８】
具体的には、図９に示すように、イベントＡの残り座席数が１００席であるため、サーバ３１は、リクエストキュー２２ａに記憶されているリクエストの数（すなわち予約希望の数）が１０１以上であれば、チケットデータベース４１に格納されている予約状況情報のうち、予約済数に予約可能数の１００を加算するとともに、残り座席数から予約可能数である１００を減算する処理を行う。そして、新たに予約を受け付けた予約者を特定するための情報をチケットデータベース４１に格納する。
【０１１９】
問い合わせの結果、残り座席数が１つもない場合には、チケットデータベース４１の更新処理は行わない。
【０１２０】
次いで、サーバ３１は、共通処理（ステップＳ３０２参照）において、予約できたそれぞれのユーザに対しては予約を受け付けた旨の共通メッセージ（例えば、「イベントＡのチケットの予約を受け付けました。」）を作成し、予約できなかったそれぞれのユーザに対しては予約できない旨の共通メッセージ（例えば、「イベントＡの残りチケットはありませんでした。」）を作成する。
【０１２１】
そして、サーバ３１は、個別処理が必要であれば、個別処理を実行する（ステップＳ３０３，Ｓ３０４参照）。例えば、チケットの予約ができない旨のメッセージとして、「○○さん、残りチケットはありませんでした。」というメッセージを各クライアントに送信するシステムであるとすると、「残りチケットはありませんでした。」の部分が共通処理で作成される。そして、個別の氏名である「○○さん、」の部分が個別処理で実行される。従って、上記のような個別のメッセージを含む返答情報を作成することとされている場合には、個別処理が必要であると判定される。なお、ここでは、個別処理にて、例えばＣｏｏｋｉｅと称されるユーザ識別情報を利用して個別の氏名を抽出し、各クライアントへの返答情報を完成させる処理が実行される。
【０１２２】
返答情報としてのメッセージを作成すると、サーバ３１は、リクエスト元であるクライアント１０等の各クライアントに向けて、対応するメッセージを送信する処理を行う（ステップＳ３０５参照）。
【０１２３】
上述したように、クライアントからのチケット予約要求のリクエストをあらかじめイベント毎に個別に定められた分類別に別個のリクエストキューに格納し、各リクエストキューに保存された各リクエストに対応した予約状況の確認や予約の受け付けなどの処理と、各リクエストに対応した共通メッセージを作成する処理とを一括処理で行う構成としたので、チケット予約要求のリクエストに応じた処理を実行するサーバの処理の負荷を軽減させることができる。
【０１２４】
また、上述したように、共通処理によって一括して処理できる可能性を持つ分類をあらかじめ設定し、その分類に属する複数のリクエストを、その分類に対応して設けられたリクエストキューにまとめて格納する構成としたので１つのリクエストキューに格納されている複数のリクエストに返答するための処理の一部または全部を、一回の共通処理で同時に処理することができるようになり、サーバの処理負荷を軽減させることができ、通常の運用時と同様のサーバ能力のままで一時的な高負荷時における対応能力を向上させることができる。よって、一時的な高負荷時であっても全てのリクエストに対する返答を完了させる期待度を向上させることができる。
【０１２５】
なお、上述した第２の実施例では、各リクエストに応じた全ての処理を終えたあとは、サーバ３１，３２，３３が、リクエスト元であるクライアント１０などの各クライアントに処理結果（予約結果を示すメッセージ）を返答する処理を行う構成としていたが、例えば特定のリクエストキューに記憶されているリクエストに対する返答内容が一意に定まることとなっている場合などであれば、キューイング装置２０を経由してクライアントに返答する構成としてもよい。
【０１２６】
この場合、キューイング装置２０は、サーバ３１，３２，３３から予約できない旨の共通メッセージを受けたときには、リクエストに対する返答内容が一意に定まることとなったと認識し、該当するイベントは予約受付が終了している旨の情報と、予約できない旨の共通メッセージとを対象となるリクエストキュー（リクエストキュー２２ａ，２２ｂ，２２ｃ）あるいは分類に対応付けて装置内の記憶装置（返答情報保存手段の一例）に保持しておく。そして、キューイング装置２０は、その後、例えば定期的にリクエストキュー（リクエストキュー２２ａ，２２ｂ，２２ｃ）の記憶状態を確認し、予約受付が終了しているイベントの予約要求を示すリクエストが格納されるリクエストキュー（リクエストキュー２２ａ，２２ｂ，２２ｃ）にリクエストが格納されていれば、リクエストの送信元のクライアントに対して予約できない旨の共通メッセージを送信するとともに、該当するリクエストキューに格納されているリクエストを削除する処理を実行する。
【０１２７】
上記のように構成すれば、予約により満席となり予約受付が終了しているイベントに対して座席予約の要求があったときに、キューイング装置２０内で対応することができる。よって、サーバは、予約受付が終了したイベントに対して予約希望のリクエストが送られてきても、予約状況の確認のための処理、共通メッセージを作成するための処理、および共通メッセージを送信するための処理を新たに行う必要をなくすことができ、サーバの処理負荷を大幅に軽減させることができる。
【０１２８】
また、上述した第２の実施例では、サーバ３１，３２，３３が対応するリクエストキュー２２ａ，２２ｂ，２２ｃに記憶されている複数のリクエストの全てを一括処理し、各リクエストに応じた全ての処理を終えたあとは、サーバ３１，３２，３３が、リクエスト元であるクライアント１０などの各クライアントに処理結果（予約結果を示すメッセージ）を返答する処理を行う構成としていたが、サーバ３１，３２，３３が対応するリクエストキュー２２ａ，２２ｂ，２２ｃに記憶されているリクエストを所定個毎（例えば１個毎、２個毎）に処理する構成とし、例えば特定のリクエストキューに記憶されているリクエストに対する返答内容が所定内容となったときに、その特定のリクエストキューに格納されている他のリクエストに対する返答をキューイング装置２０が独自に行う構成としてもよい。
【０１２９】
この場合、サーバ３１，３２，３３は、対応するリクエストキュー２２ａ，２２ｂ，２２ｃに記憶されている複数のリクエストのうちあらかじめ設定された所定個毎にリクエストを読み出し、その所定個のリクエストの一部または全部に対する共通メッセージを生成し、生成した共通メッセージを含む返答情報をキューイング装置２０に送信する。具体的には、例えば、サーバ３１が、リクエストキュー２２ａに記憶されている複数のリクエストのうち最先に記憶された１個のリクエストを読み出し、そのリクエストに応じて予約を受けるか否か判定し、その判定結果にもとづく返答情報をキューイング装置２０に送信する。１個のリクエストに対する返答情報を送信すると、次のリクエストを読み出して同様に処理する。このような処理を、リクエストキュー２２ａ内にリクエストがなくなるまで実行する。
【０１３０】
また、キューイング装置２０は、サーバ３１，３２，３３から返答情報を受信する毎に、リクエスト元であるクライアントに予約結果を示すメッセージを含む返答情報を送信する。ただし、キューイング装置２０は、受信した返答情報が示すメッセージが予約できない旨のメッセージであったときには、リクエスト元であるクライアントの他、対応するリクエストキューに保存されている他のリクエストのリクエスト元の各クライアントに対しても、同時刻に受けたリクエストであるとみなして、予約できない旨のメッセージを含む返答情報を送信するとともに、該当するリクエストキューに格納されているリクエストを削除する処理を実行する。なお、キューイング装置２０は、対応するリクエストキューに保存されている各リクエストのリクエスト元に共通メッセージとしての予約できない旨のメッセージを送信したあとは、新たに受信したリクエストをリクエストキューに蓄積する処理を実行し、対応するサーバに返答情報の生成のための処理を実行させる通常の状態に戻る。
【０１３１】
なお、上記の例においては、分類は、同時刻に受けたリクエストであるとみなすことができる複数のリクエストであって、サーバ３１，３２，３３によって生成される返答情報を共通して使用することができる可能性のある複数のリクエストが同一分類に属するように、リクエストの内容毎に区分けしてあらかじめ設定しておくようにすればよい。具体的には、例えば上記のようなチケット予約のシステムであれば、同一イベント毎などに区分けして設定しておくようにすればよい。
【０１３２】
上記のように構成すれば、予約により満席となり予約受付が終了したときに、予約受付が終了したイベントに対する座席予約の要求が他にもあったときには、キューイング装置２０内によって予約できない旨の共通メッセージを送信することができることになる。よって、サーバは、予約受付が終了したときは、予約受付が終了したイベントに対する予約希望の他のリクエストが存在していても、予約状況の確認のための処理、共通メッセージを作成するための処理、および共通メッセージを送信するための処理を新たに行う必要をなくすことができる。従って、サーバの処理負荷を大幅に軽減させることができる。
【０１３３】
また、上記のように、キューイング装置２０が共通メッセージを送信したあと通常の状態に戻る構成とされているので、既に満席となっていてキャンセルも発生していないときには、リクエストキューに記憶されている複数のリクエストのうち例えば１個のリクエストについてだけサーバでの処理を実行すればよく、他のリクエストについてはキューイング装置２０が予約できない旨の共通メッセージを送信することができるので、サーバの処理負荷を大幅に軽減させることができる。また、満席となっていたがキャンセルが発生した場合には、その後にサーバに読み込まれたリクエストについて、さらに満席となるまで予約を受けることができる。すなわち、キャンセルが発生した場合に、新たな予約を受け付けることができる状態とすることができる。
【０１３４】
また、上述した第２の実施例では、各リクエストキュー２２ａ，２２ｂ，２２ｃが、それぞれ、チケットの予約を受け付けるイベント毎に分類されているものとしていたが、各イベントの座席の等級毎にリクエストキューを分類する構成としてもよい。このように構成すれば、イベントの座席の各等級毎に共通処理を実行することができるため、等級別に座席予約を行うイベントの座席予約の受け付け処理を行う場合についても、サーバの処理負荷を軽減させることができる。
【実施例３】
【０１３５】
以下、第３の実施例として、上述した本発明の一実施の形態におけるキューイングシステム１００を、試験の採点を行うための試験採点システム１００ｃに適用した例について説明する。なお、試験採点システム１００ｃは、採点までは行わず解答の正否の判定を行う試験添削システムであってもよい。
【０１３６】
図１０は、試験採点システム１００ｃの構成の例を示すブロック図である。試験採点システム１００ｃは、クライアント１０（図１０では図示せず）と、キューイング装置２０と、サーバ３１，３２，３３と、試験データベース４２とを含む。
【０１３７】
試験データベース４２は、例えばハードディスクなどの大容量記憶媒体によって構成され、試験問題を示す情報、試験問題の解答を示す情報、試験結果を示す情報、受験者に関する情報などの各種のデータが保存されている。
【０１３８】
この例では、各リクエストキュー２２ａ，２２ｂ，２２ｃは、それぞれ、試験問題の設問毎に分類されているものとする。なお、説明を簡単にするために、試験問題は、同時期には１つしかないものとする。
【０１３９】
また、この例では、各サーバ３１，３２，３３は、それぞれ、対応するリクエストキュー２２ａ，２２ｂ，２２ｃに格納されているリクエストに従って、試験データベース４２から試験情報を読み出し、該当する設問の解答を確認し、正解／不正解の別を判定し、その結果を示す採点情報を作成して受験者である各クライアントに返答を行う機能を有している。
【０１４０】
次に、この例におけるリクエスト格納処理について説明する。リクエスト格納処理において、キューイング装置２０の分類変更部２３は、クライアント１０からのリクエストを受信すると（ステップＳ２０３参照）、リクエストの内容に応じて分類を決定する（ステップＳ２０４参照）。
【０１４１】
リクエストは、採点を希望する１または複数の設問を指定して行われる。この例では、リクエストには、例えばクライアント１０のアドレスを特定するためのユーザ情報と、答案を作成した各設問を示す設問情報と、各設問それぞれに対する答案を示す答案情報とが含まれる。設問情報は、例えば、あらかじめ割り当てられている識別番号などを用いるようにすればよい。なお、この例では、説明を簡単にするために、各設問は、選択肢式の問題であるものとする。
【０１４２】
また、リクエストの分類は、例えば、そのリクエストにおける設問情報が示す設問がどの分類とされているかによって決定される。すなわち、受信したリクエストに含まれている設問情報が示す設問に割り当てられている分類が、リクエストの分類とされる。
【０１４３】
リクエストにおける設問情報が示す設問が複数ある場合には、振り分け器２１は、リクエストを設問別に分割し、分割したリクエストに含まれている設問情報が示す設問に割り当てられている分類を、分割したリクエストの分類とする。
【０１４４】
具体的には、図１１（Ａ）に示すように、リクエストに設問１〜３の３つの設問が含まれていた場合には、そのリクエストは、図１１（Ｂ）に示すように、設問１および設問１の答案を含むリクエストＡと、設問２および設問２の答案を含むリクエストＢと、設問３および設問３の答案を含むリクエストＣとに分割される。なお、分割された各リクエストＡ，Ｂ，Ｃには、それぞれユーザ情報が含まれている。
【０１４５】
そして、採点サービスの対象となるそれぞれの設問１〜３に対応して分類Ａ〜Ｃが割り当てられている場合、分割された各リクエストのうち、リクエストＡは設問１に割り当てられている分類Ａとされ、リクエストＢは設問２に割り当てられている分類Ｂとされ、リクエストＣは設問３に割り当てられている分類Ｃとされる。
【０１４６】
次いで、振り分け器２１は、決定した分類Ａに対応して割当されているリクエストキュー（例えばリクエストキュー２２ａ）をリクエストＡの振り分け先のリクエストキューに決定し、リクエストキュー２２ａに向けて設問１の採点要求を含むリクエストＡを送信する（ステップＳ２０４参照）。同様にして、設問２の採点要求を含むリクエストＢをリクエストキュー２２ｂに向けて送信し、設問３の採点要求を含むリクエストＣをリクエストキュー２２ｃに向けて送信する。
【０１４７】
そして、リクエストキュー２２ａ，２２ｂ，２２ｃは、送信されてきたリクエストを受信し、受信したリクエストを保存する（ステップＳ２０５参照）。
【０１４８】
上記のようにして、各リクエストキュー２２ａ，２２ｂ，２２ｃに、それぞれ、あらかじめ割り当てられている分類の各リクエスト（分割されたリクエストを含む）が保存される。
【０１４９】
次に、この例におけるリクエスト対応処理について説明する。ここでは、サーバ３１が、対応するリクエストキュー２２ａに記憶されているリクエストに応じた処理を実行する場合を例に説明する。
【０１５０】
リクエスト対応処理において、サーバ３１は、リクエストキュー２２ａに記憶されている全てのリクエストを読み出し（ステップＳ３０１参照）、全リクエストについての共通処理を実行する（ステップＳ３０２参照）。この例では、共通処理において、リクエストキュー２２ａに記憶されている各リクエストが示す設問１についての採点を一括して処理する。
【０１５１】
具体的には、サーバ３１は、試験データベース４１に設問１の正解を問い合わせる。次いで、サーバ３１は、リクエストキュー２２ａに記憶されている各リクエストにおける答案内容毎にグループ分けする。この例では、例えば正解の選択肢を選択しているグループと、不正解の選択肢を選択しているグループとに分ける。また、サーバ３１は、正解した旨の共通メッセージと、不正解の旨の共通メッセージとを作成する。
【０１５２】
次いで、サーバ３１は、リクエスト者の情報を示すユーザ情報（例えばユーザ名、ユーザＩＤ、設問Ｑに対する解答・正解／不正解の別など）と、設問１の識別情報とを組にして試験データベース４１に格納する。
【０１５３】
また、サーバ３１は、個別処理が必要であるか否かを確認し、必要であれば個別処理を実行する（ステップＳ３０３，Ｓ３０４参照）。なお、個別処理は、例えば、上述したように、返答するメッセージをクライアント別に作成する場合（ユーザ名を入れるなど）などに実行するようにすればよい。
【０１５４】
そして、各リクエストに応じた全ての処理を終えると、サーバ３１は、リクエスト元である各クライアントに対して、処理結果として、正解した者に対しては正解した旨の共通メッセージ（例えば、「設問１は正解です」）を送信し、不正解した者に対しては不正解である旨の共通メッセージ（例えば、「設問１は不正解です」）を送信する処理を行う（ステップＳ３０５参照）。
【０１５５】
上述したように、クライアントからの採点要求のリクエストをあらかじめ設問毎に個別に定められた分類別に別個のリクエストキューに格納し、各リクエストキューに保存された各リクエストに対応した採点処理と、各リクエストに対応した共通メッセージを作成する処理とを一括処理で行う構成としたので、採点要求のリクエストに対応するサーバの処理の負荷を軽減させることができる。
【０１５６】
また、上述したように、クライアントからの採点要求のリクエストに複数の設問の答案が含まれている場合には、設問毎にリクエストを分割し、分割した各リクエストをあらかじめ設問毎に個別に定められた分類別に別個のリクエストキューに格納する構成としたので、リクエストに複数の設問の答案が含まれている場合であっても、設問毎にまとめて処理することができ、採点要求のリクエストに対応するサーバの処理の負荷を軽減させることができる。
【０１５７】
また、上述したように、共通処理によって一括して処理できる可能性を持つ分類をあらかじめ設定し、その分類に属する複数のリクエストを、その分類に対応して設けられたリクエストキューにまとめて格納する構成としたので、１つのリクエストキューに格納されている複数のリクエストに返答するための処理の一部または全部を、一回の共通処理で同時に処理することができるようになり、サーバの処理負荷を軽減させることができ、通常の運用時と同様のサーバ能力のままで一時的な高負荷時における対応能力を向上させることができる。よって、一時的な高負荷時であっても全てのリクエストに対する返答を完了させる期待度を向上させることができる。
【０１５８】
なお、１つのリクエストで複数の設問についての採点要求がなされた場合には、各サーバ３１，３２，３３が採点結果をキューイング装置２０に送信し、キューイング装置２０が各サーバ３１，３２，３３から受信した処理結果をクライアント毎にまとめる処理を実行し、複数の設問についての採点結果をまとめてクライアントに返答する構成としてもよい。この場合、返答に用いられるメッセージは、例えば「全問正解です」、「設問１は正解、設問２は不正解、設問３は正解です」などのような内容とすればよい。
【図面の簡単な説明】
【０１５９】
【図１】本発明の一実施の形態におけるキューイングシステムの構成の例を示すブロック図である。
【図２】本発明の一実施の形態におけるリクエスト格納処理の例を示すフローチャートである。
【図３】本発明の一実施の形態におけるリクエスト対応処理の例を示すフローチャートである。
【図４】本発明の一実施の形態におけるキューイングシステムの構成の他の例を示すブロック図である。
【図５】本発明の一実施の形態における第１の実施例の地図情報システムの構成の例を示すブロック図である。
【図６】地域ブロックを示す説明図である。
【図７】共通地図と個別地図とを説明示す説明図である。
【図８】本発明の一実施の形態における第２の実施例のチケット予約システムの構成の例を示すブロック図である。
【図９】チケットの予約状況情報の例を示す説明図である。
【図１０】本発明の一実施の形態における第３の実施例の試験採点システムの構成の例を示すブロック図である。
【図１１】リクエストの分割状態の例を示す説明図である。
【符号の説明】
【０１６０】
１０                    クライアントコンピュータ
２０                    キューイング装置
２１                    振り分け器
２２ａ，２２ｂ，２２ｃ  リクエストキュー
２３                    分類変更部
３１，３２，３３        サーバ
４０                    地図情報データベース
４１                    チケットデータベース
４２                    試験データベース
１００                  キューイングシステム
１００ａ                地図情報システム
１００ｂ                チケット予約システム
１００ｃ                試験採点システム
【図１】
2008159081.tif 000003
【図２】
2008159081.tif 000004
【図３】
2008159081.tif 000005
【図４】
2008159081.tif 000006
【図５】
2008159081.tif 000007
【図６】
2008159081.tif 000008
【図７】
2008159081.tif 000009
【図８】
2008159081.tif 000010
【図９】
2008159081.tif 000011
【図１０】
2008159081.tif 000012
【図１１】
2008159081.tif 000013