JP7432691B2 - クライアント装置及びシステム - Google Patents

Description

本発明は、クライアント装置、システム、管理装置及びプログラムに関する。

Ｗｅｂサーバ装置において予め定められた時間内に接続可能なアクセス数の上限値を設定する技術が知られている（例えば、特許文献１参照）。
［先行技術文献］
［特許文献］
［特許文献１］特開２０１７－２１５９０１号公報

クライアント装置からサーバ装置に到来するサービス要求の数を、サーバ装置の能力等に応じた適切な数に抑制することが望まれている。

本発明の第１の態様においては、管理装置が提供される。上記の管理装置は、例えば、サーバ装置へサービス要求を送信することをクライアント装置に許可した数を管理する管理部を備える。上記の管理装置は、例えば、クライアント装置から、サービス要求の送信許可を要求する要求情報を受信する要求受信部を備える。上記の管理装置は、例えば、要求受信部が要求情報を受信した場合に、管理部により管理されている数が予め定められた上限値未満であることを条件として、クライアント装置にサービス要求の送信を許可すると判断する判断部を備える。上記の管理装置は、例えば、判断部がクライアント装置にサービス要求の送信を許可すると判断した場合に、クライアント装置に許可情報を送信する送信部を備える。

管理部は、複数の許可情報のそれぞれがクライアント装置に送信されたか否かを示す情報を管理してよい。判断部は、管理部が管理している情報に基づいて、複数の許可情報の中にクライアント装置に送信されていない許可情報が存在する場合に、クライアント装置にサービス要求の送信を許可すると判断してよい。

上記の管理装置は、サービス要求に応じてクライアント装置がサーバ装置から応答を受信した後にクライアント装置から送信される終了通知を受信する終了通知受信部を備えてよい。管理部は、許可情報の送信に応じて、サービス要求を送信することをクライアント装置に許可した数を示す第１の許可発行数を増加させ、終了通知の受信に応じて、第１の許可発行数を減少させてよい。

管理部はさらに、要求受信部が要求情報を受信した場合において、管理部により管理されている数が上限値に達している場合に、クライアント装置の識別情報を待ち行列に追加してよい。送信部は、終了通知受信部が終了通知を受信した場合に、待ち行列に含まれる識別情報で識別されるクライアント装置に、許可情報を送信してよい。

送信部は、要求受信部が要求情報を受信した場合において、管理部により管理されている数が上限値に達している場合に、クライアント装置がサービス要求をサーバ装置に送信するまでの待ち時間を含む許可情報を送信してよい。

上記の管理装置は、サーバ装置から、サーバ装置がサービス要求を受け付けることができる許容量を示す情報を受信する許容量受信部を備えてよい。管理部は、許容量に応じて上限値を調整してよい。

上限値は、複数の優先度のそれぞれに対して定められてよい。管理部は、複数の優先度のそれぞれに対応づけて、サービス要求を送信することをクライアント装置に許可した数を示す第１の許可発行数を管理してよい。判断部は、要求受信部が要求情報を受信した場合に、クライアント装置に対するサービス提供の優先度に対応づけて管理部で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置にサービス要求の送信を許可すると判断してよい。

管理部はさらに、複数のクライアント装置に対する優先度を管理してよい。判断部は、要求情報の送信元のクライアント装置に対する優先度に対応づけて管理部で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置にサービス要求の送信を許可すると判断してよい。

クライアント装置から送信される要求情報には、サービス要求に対する優先度を示す優先度情報が含まれてよい。判断部は、要求情報に含まれる優先度情報で示される優先度に対応づけて管理部で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置にサービス要求の送信を許可すると判断してよい。

管理部は、複数の優先度のそれぞれに対応づけて、それぞれの優先度よりサービス提供に対する優先度が高いクライアント装置にサービス要求の送信を許可した数を示す第２の許可発行数を管理してよい。判断部は、要求情報の送信元のクライアント装置に対するサービス提供の優先度が第１の優先度である場合において、第１の優先度に対応づけて管理部で管理されている第１の許可発行数が第１の優先度に対して定められている上限値に達している場合であっても、第１の優先度より低い第２の優先度に対応づけて管理部で管理されている第２の許可発行数が、第２の優先度に対して定められた上限値未満の予め定められた閾値未満であることを条件として、クライアント装置にサービス要求の送信を許可すると判断してよい。

本発明の第２の態様においては、システムが提供される。当該システムは、例えば、上記の管理装置と、上記のクライアント装置とを備える。

本発明の第３の態様においては、プログラムが提供される。上記のプログラムは、コンピュータを、上記の管理装置として機能させるためのプログラムであってよい。上記のプログラムは、コンピュータに、上記の管理装置における情報処理を実行させるためのプログラムであってもよい。上記のプログラムを格納するコンピュータ可読媒体が提供されてもよい。コンピュータ可読媒体は、非一時的なコンピュータ可読媒体であってもよい。コンピュータ可読媒体は、コンピュータ可読記録媒体であってもよい。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

一実施形態におけるシステム１０の構成の一例を概略的に示す。 管理装置４０の機能構成を示すブロック図である。 クライアント装置２０、サーバ装置３０及び管理装置４０における処理のシーケンスを示す。 管理部２４０が管理する情報の一例をテーブル形式で示す。 管理装置４０における処理を示すフローチャートである。 クライアント装置２０における処理を示すフローチャートである。 待ち時間を含むアクセスチケットをクライアント装置２０に送信する場合のタイムチャートを示す。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、図面において、同一または類似の部分には同一の参照番号を付して、重複する説明を省く場合がある。

図１は、一実施形態におけるシステム１０の構成の一例を概略的に示す。本実施形態において、システム１０は、サーバ装置３０と、クライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ及びクライアント装置２０ｄと、管理装置４０とを備える。本実施形態において、クライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ、及びクライアント装置２０ｄを「クライアント装置２０」と総称する場合がある。

サーバ装置３０、クライアント装置２０、及び管理装置４０は、ネットワーク１２を介して接続される。ネットワーク１２は、任意の通信回線を含んでよい。例えば、ネットワーク１２は、専用線、公衆回線、ローカル回線の少なくともいずれかを含んでよい。公衆回線は、インターネット、移動体通信回線、及び電話回線等の少なくともいずれかを含んでよい。移動体通信網は、いわゆる３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）及び５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）等を含んでよい。

サーバ装置３０は、クライアント装置２０からのサービス要求に応じて、クライアント装置２０にサービス提供する。サーバ装置３０は、例えば、クライアント装置２０から要求された処理を行って、処理結果を示すレスポンスをクライアント装置２０に返す。サーバ装置３０は、例えば、ウエブサーバやアプリケーションサーバ等であってよい。

システム１０の利用形態の一例として、システム１０が金融機関において用いられる場合を説明する。サーバ装置３０は、例えば金融機関のセンターサーバである。サーバ装置３０は、金融機関の顧客に関する顧客データを格納する。例えば、サーバ装置３０は、金融機関と顧客との間で過去に行われた取引データや、顧客が所有する金融口座情報、顧客の信用情報等を、顧客データとして格納する。

クライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ及びクライアント装置２０ｄは、金融機関の店舗に設けられる。クライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ、及びクライアント装置２０ｄは、サーバ装置３０に格納されている顧客データを取得する。

クライアント装置２０ａは、ロボティック・プロセス・オートメーション（ＲＰＡ）機能により、サーバ装置３０から顧客データを自動的に収集する。クライアント装置２０ａは、店舗業務で用いられる顧客データをサーバ装置３０から自動的にダウンロードする。例えば、クライアント装置２０ａは、渉外担当者の翌日のスケジュールデータを参照して、渉外担当者が翌日に出向く取引先の顧客データをサーバ装置３０からダウンロードする。クライアント装置２０ａは、サーバ装置３０からダウンロードした顧客データを、渉外担当者の電子メールアドレス宛に送信する。

クライアント装置２０ｂは、渉外担当者が利用する端末である。渉外担当者は、クライアント装置２０ｂを用いて、渉外担当者の電子メールアドレスに届いた顧客データを参照することができる。また、渉外担当者は、クライアント装置２０ｂを操作してサーバ装置３０にアクセスして、サーバ装置３０から直接に顧客データをダウンロードすることもできる。

クライアント装置２０ｃは、金融機関の店舗において窓口業務を行う窓口担当者が操作するテラー端末である。クライアント装置２０ｃは、いわゆる一線端末である。クライアント装置２０ｄは、窓口業務の後方業務を行う後方業務者が操作する後方端末である。クライアント装置２０ｄは、いわゆる二線端末である。クライアント装置２０ｃ及びクライアント装置２０ｄは、例えば口座の新規開設依頼を顧客から受け付けた場合に、顧客が開設済みの口座情報の一覧をサーバ装置３０からダウンロードする。これにより、窓口担当者や後方業務者は、顧客が既に同種の口座を開設していないことを確認することができる。

ここで、仮に、クライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ、及びクライアント装置２０ｄが一斉にサーバ装置３０にアクセスすると、サーバ装置３０が処理可能なアクセス数を超えてしまい、サーバ装置３０がサービス提供することができない可能性がある。例えば、複数の店舗において、クライアント装置２０ａが銀行業務の終了時刻に一斉にサーバ装置３０にアクセスして顧客データをダウンロードしようとすると、サーバ装置３０がクライアント装置２０にサービス提供することができない場合がある。

管理装置４０は、クライアント装置２０からサーバ装置３０に大量のサービス要求が送信されることを抑制する。具体的には、管理装置４０は、クライアント装置２０がサーバ装置３０にアクセスすることを許可するアクセスチケットを管理する。例えば、管理装置４０は、サーバ装置３０においてクライアント装置２０からのサービス要求の応答に使用することができる処理能力に応じた数のアクセスチケットを管理する。

クライアント装置２０は、サーバ装置３０に顧客データの送信要求を送信する前に、管理装置４０にアクセスチケットを要求する。管理装置４０は、クライアント装置２０に既に送信したアクセスチケット数が、管理装置４０が管理しているアクセスチケットの上限値未満である場合に、クライアント装置２０にアクセスチケットを送信する。

クライアント装置２０は、サーバ装置３０からアクセスチケットを受信した後に、サーバ装置３０に顧客データのサービス要求を送信する。クライアント装置２０は、サーバ装置３０から顧客データを含むレスポンスを受信すると、管理装置４０にアクセスチケットを返却するとともに、サーバ装置３０から受信した顧客データを用いた処理を行う。

システム１０によれば、クライアント装置２０からサーバ装置３０に到来するサービス要求の数を、サーバ装置３０の処理能力に応じた適切な数に抑制することができる。これにより、過負荷によりサーバ装置３０がクライアント装置２０にサービス提供できなくなることを抑制することができる。

図２は、管理装置４０の機能構成を示すブロック図である。管理装置４０は、処理部４２と、記憶部４８と、格納部４４とを備える。処理部４２は、プロセッサを含む処理装置により実現される。記憶部４８は、揮発性の記憶装置により実現される。格納部４４は、不揮発性の記憶装置により実現される。

処理部４２は、要求受信部２１０と、判断部２２０と、送信部２３０と、管理部２４０と、終了通知受信部２５０と、許容量受信部２６０とを備える。

管理部２４０は、サーバ装置３０へサービス要求を送信することをクライアント装置２０に許可した数を管理する。例えば、管理部２４０は、クライアント装置２０にアクセスチケットを送信した数を管理する。なお、本実施形態においてクライアント装置２０がサーバ装置３０に送信するリクエストは、サービス要求の一例である。

要求受信部２１０は、クライアント装置２０から、サービス要求の送信許可を要求する要求情報を受信する。本実施形態におけるアクセスチケット要求は、要求情報の一例である。

判断部２２０は、要求受信部２１０が要求情報を受信した場合に、管理部２４０により管理されている数が予め定められた上限値未満であることを条件として、クライアント装置２０にサービス要求の送信を許可すると判断する。送信部２３０は、判断部２２０がクライアント装置２０にサービス要求の送信を許可すると判断した場合に、クライアント装置２０に許可情報を送信する。例えば、管理部２４０は、複数の許可情報のそれぞれがクライアント装置２０に送信されたか否かを示す情報を管理する。判断部２２０は、管理部２４０が管理している情報に基づいて、複数の許可情報の中にクライアント装置２０に送信されていない許可情報が存在する場合に、クライアント装置２０にサービス要求の送信を許可すると判断してよい。これにより、クライアント装置２０からサーバ装置３０に大量のサービス要求が一斉に送信されることを抑制することが出来る。なお、本実施形態において管理装置４０からクライアント装置２０に送信されるアクセスチケットは、許可情報の一例である。

終了通知受信部２５０は、サービス要求に応じてクライアント装置２０がサーバ装置３０から応答を受信した後にクライアント装置２０から送信される終了通知を受信する。本実施形態におけるアクセスチケット返却情報は、終了通知の一例である。管理部２４０は、許可情報の送信に応じて、サービス要求を送信することをクライアント装置２０に許可した数を示す第１の許可発行数を増加させ、終了通知の受信に応じて、第１の許可発行数を減少させる。

管理部２４０はさらに、要求受信部２１０が要求情報を受信した場合において、管理部２４０により管理されている数が上限値に達している場合に、クライアント装置２０の識別情報を待ち行列に追加する。送信部２３０は、終了通知受信部２５０が終了通知を受信した場合に、待ち行列に含まれる識別情報で識別されるクライアント装置２０に、許可情報を送信する。これにより、アクセスチケットが返却され次第、他のクライアント装置２０にサービス要求の送信を許可することができる。

送信部２３０は、要求受信部２１０が要求情報を受信した場合において、管理部２４０により管理されている数が上限値に達している場合に、クライアント装置２０がサービス要求をサーバ装置３０に送信するまでの待ち時間を含む許可情報を送信してもよい。待ち時間を含む許可情報については、図７等に関連して説明する。

許容量受信部２６０は、サーバ装置３０から、サーバ装置３０がサービス要求を受け付けることができる許容量を示す情報を受信する。本実施形態の許容アクセス数情報は、許容量を示す情報の一例である。管理部２４０は、サーバ装置３０から受信した許容量に応じて、サービス要求の送信を許可する数の上限値を調整する。これにより、サーバ装置３０の現在の負荷に応じて、クライアント装置２０がサーバ装置３０にアクセスすることを許可する許容アクセス数を動的に調整することができる。例えば、サーバ装置３０の負荷が高まった場合に許容アクセス数を低下させ、サーバ装置３０の負荷が低くなった場合に、許容アクセス数を増加させることができる。これにより、サーバ装置３０のリソース逼迫時に、クライアント装置２０からサーバ装置３０に到来するサービス要求を抑制することができる。

上限値は、複数の優先度のそれぞれに対して定められていてよい。管理部２４０は、複数の優先度のそれぞれに対応づけて、サービス要求を送信することをクライアント装置２０に許可した数を示す第１の許可発行数を管理してよい。判断部２２０は、要求受信部２１０が要求情報を受信した場合に、クライアント装置２０に対するサービス提供の優先度に対応づけて管理部２４０で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置２０にサービス要求の送信を許可すると判断してよい。

管理部２４０は、複数のクライアント装置２０に対する優先度を管理してよい。判断部２２０は、要求情報の送信元のクライアント装置２０に対する優先度に対応づけて管理部２４０で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置２０にサービス要求の送信を許可すると判断してよい。

なお、クライアント装置２０から送信される要求情報には、サービス要求に対する優先度を示す優先度情報が含まれていてよい。判断部２２０は、要求情報に含まれる優先度情報で示される優先度に対応づけて管理部２４０で管理されている第１の許可発行数が、当該優先度に対して定められている上限値未満の場合に、クライアント装置２０にサービス要求の送信を許可すると判断してよい。これにより、同一のクライアント装置２０からのサービス要求についても、サービス要求の種別に応じて、異なる優先度を設定することが出来る。これにより、クライアント装置２０は、優先度の高い種別のサービス要求を、優先度が低い種別のサービス要求より優先してサーバ装置３０に送信することができる。

管理部２４０は、複数の優先度のそれぞれに対応づけて、それぞれの優先度よりサービス提供に対する優先度が高いクライアント装置２０にサービス要求の送信を許可した数を示す第２の許可発行数を管理してよい。判断部２２０は、要求情報の送信元のクライアント装置２０に対するサービス提供の優先度が第１の優先度である場合において、第１の優先度に対応づけて管理部２４０で管理されている第１の許可発行数が第１の優先度に対して定められている上限値に達している場合であっても、第１の優先度より低い第２の優先度に対応づけて管理部２４０で管理されている第２の許可発行数が、第２の優先度に対して定められた上限値未満の予め定められた閾値未満であることを条件として、クライアント装置２０にサービス要求の送信を許可すると判断してよい。これにより、優先度が低いサービス要求について最低限のアクセスチケット枠を確保しつつ、優先度が低いサービス要求が少ない場合には、アクセスチケット枠を優先度が高いサービス要求に振り向けることができる。これにより、サーバ装置３０の処理能力を有効に利用することができる。

図３は、クライアント装置２０、サーバ装置３０及び管理装置４０における処理の全体シーケンスを示す。図３は、クライアント装置２０ａ及びクライアント装置２０ｃがサーバ装置３０にアクセスする場合の全体シーケンスを示す。

サーバ装置３０は、サーバ装置３０の現在の負荷量に応じて、クライアント装置２０からのサービス要求に応答することができるアクセス数を示す許容アクセス数情報を送信する（Ｓ３０２）。管理装置４０において、許容量受信部２６０が許容アクセス数情報を受信すると、管理部２４０は、許容アクセス数情報が示すアクセス数に基づいて、管理装置４０が発行することができるアクセスチケット数（発行可能チケット数）の上限値を調整する（Ｓ３０４）。Ｓ３０６及びＳ３０８において、クライアント装置２０ｃ及びクライアント装置２０ａは、アクセスチケット要求を管理装置４０に送信する。

ここで、管理装置４０の管理部２４０において管理している発行可能チケット数とクライアント装置２０に発行済みのチケット数との差が１であったとする。管理装置４０において、要求受信部２１０がクライアント装置２０ａ及びクライアント装置２０ｃからのアクセスチケット要求を受信すると、送信部２３０は、クライアント装置２０ｃに対してのみ、アクセスチケットを送信する（Ｓ３１０）。管理部２４０は、クライアント装置２０ａからのアクセス要求を、アクセスチケットの待ち行列に追加する（Ｓ３１２）。

クライアント装置２０ｃは、アクセスチケットを受信すると、顧客指定情報を含む顧客データのリクエストを生成して（Ｓ３２０）、サーバ装置３０に送信する（Ｓ３２２）。サーバ装置３０は、クライアント装置２０ｃからリクエストを受信すると、顧客指定情報で指定された顧客の顧客データを含むレスポンスを、クライアント装置２０ｃに送信する（Ｓ３２４）。

クライアント装置２０ｃは、サーバ装置３０からレスポンスを受信すると、受信したアクセスチケットの返却通知を、管理装置４０に送信する（Ｓ３３０）。管理装置４０において、終了通知受信部２５０はクライアント装置２０ｃから返却通知を受信すると、クライアント装置２０ａにアクセスチケットを送信する（Ｓ３３２）。これにより、クライアント装置２０ａは、Ｓ３３２のアクセスチケットの受信に応じて、サーバ装置３０に顧客データのリクエストを送信する（Ｓ３３６）。

クライアント装置２０ｃは、Ｓ３３０でアクセスチケットの返却通知を管理装置４０に送信した後、Ｓ３２４で受信したレスポンスに含まれる顧客データを用いた処理を行う（Ｓ３３４）。

図４は、管理部２４０が管理する情報の一例をテーブル形式で示す。図４の（Ａ）は、管理部２４０が管理するチケット管理テーブルの一例である。チケット管理テーブルは、格納部４４に格納される。

チケット管理テーブルは、チケットＩＤと、優先度と、発行済みフラグと、発行日時と、発行先優先度と、使用可能フラグとを対応づける。「チケットＩＤ」には、アクセスチケットを識別する情報が格納される。「優先度」には、アクセスチケットの優先度を示す情報が格納される。本実施形態において、優先度１は、優先度２より優先度が高いことを意味する。

「発行済みフラグ」には、クライアント装置２０にアクセスチケットを送信済みであるか否かを示す情報が格納される。図４において、ＴＲＵＥは、クライアント装置２０にアクセスチケットを送信済みであることを示し、ＦＡＬＳＥは、クライアント装置２０にアクセスチケットが送信されていないことを示す。

「発行日時」には、アクセスチケットが発行された日時を示す情報が格納される。アクセスチケットが発行された日時は、アクセスチケットをクライアント装置２０に送信した日時であってよい。管理部２４０は、チケット管理テーブルに格納されているチケットＩＤの中から、「発行日時」からの経過時間がが予め定められた時間を越えたチケットＩＤを選択して、選択したチケットＩＤのアクセスチケットを無効化して、新たなチケットＩＤのアクセスチケットを生成してもよい。この場合、管理部２４０は、無効化したアクセスチケットと同数のアクセスチケットを新たに生成してよい。これにより、クライアント装置２０からアクセスチケットが長時間返却されない場合でも、適切に対処することができる。

「発行先優先度」には、アクセスチケット要求に対するサービス提供の優先度を示す情報が格納される。アクセスチケット要求に対するサービス提供の優先度は、クライアント装置２０毎に定められてよい。なお、サービス提供の優先度が１のアクセスチケット要求を送信したクライアント装置２０には、チケット管理テーブルにおいて優先度１に対応づけられたアクセスチケットの他に、優先度２が対応づけられたアクセスチケットの少なくとも一部のアクセスチケットを発行することができる。したがって、優先度２のアクセスチケットのうちの一部のアクセスチケットの「発行先優先度」には、優先度１が格納され得る。

「使用可能フラグ」には、アクセスチケットが使用可能であるか否かを示す情報が格納される。図４において、ＴＲＵＥはアクセスチケットが使用可能であることを示し、ＦＡＬＳＥはアクセスチケットが使用可能でないことを示す。管理部２４０は、許容量受信部２６０が管理装置４０から許容アクセス数情報を受信した場合に、許容アクセス数情報が示す許容アクセス数に応じた数のアクセスチケットを使用可能とする。例えば、管理部２４０は、許容アクセス数を上限として、使用可能フラグをＴＲＵＥに設定する。

図４の（Ｂ）は、管理部２４０が管理する優先度テーブルの一例である。優先度テーブルは、格納部４４に格納される。

優先度テーブルは、クライアントＩＤと、優先度とを対応づける。「クライアントＩＤ」には、クライアント装置２０を識別する情報が格納される。「優先度」には、クライアント装置２０へのサービス提供の優先度を示す情報が格納される。

判断部２２０は、優先度テーブルを参照して、要求受信部２１０が受信したアクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけられた優先度を特定する。判断部２２０は、特定した優先度と、アクセスチケット要求に含まれる優先度情報が示す優先度とに基づいて、アクセスチケット要求に対するサービス提供の優先度を決定する。

例えば、判断部２２０は、アクセスチケット要求に優先度情報が含まれない場合に、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけられた優先度を、アクセスチケット要求に対するサービス提供の優先度として決定する。アクセスチケット要求に優先度情報が含まれる場合、判断部２２０は、当該優先度情報が示す優先度を、アクセスチケット要求に対するサービス提供の優先度として決定する。アクセスチケット要求に優先度情報が含まれる場合、判断部２２０は、アクセスチケット要求に含まれる優先度情報が示す優先度と、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけられた優先度との積により、サービス提供の優先度を決定してもよい。

判断部２２０は、アクセスチケット管理テーブルを参照して、決定した優先度に対応づけられたチケットＩＤのうち、発行済みフラグがＦＡＬＳであり、かつ、使用可能フラグがＴＲＵＥのチケットＩＤが存在する場合に、クライアント装置２０にサービス要求の送信を許可すると判断する。なお、本実施形態において「発行済みフラグがＦＡＬＳであり、かつ、使用可能フラグがＴＲＵＥのチケットＩＤにより識別されるアクセスチケット」のことを、「未発行のアクセスチケット」等と呼ぶ場合がある。

ここで、図４の（Ａ）の「発行先優先度」について説明する。上述したように、判断部２２０は、サービス要求の優先度に対応する未発行のアクセスチケットが存在する場合に、アクセスチケット要求の送信元のクライアント装置２０にサービス要求の送信を許可すると判断する。ここで、管理装置４０は、サービス提供の優先度が１のアクセスチケット要求に対して、優先度２が対応づけられたアクセスチケットのうち一部のアクセスチケットを送信することができる。例えば、判断部２２０は、チケット管理テーブルを参照して、優先度１が対応づけられた未発行のアクセスチケットが存在しない場合であっても、優先度２が対応づけられた未発行のアクセスチケットが存在し、かつ、発行先優先度１が対応づけられたアクセスチケットの数が予め定められた閾値Ｍ未満である場合には、サービス要求の送信を許可してよい。この場合、管理部２４０は、チケット管理テーブルにおいて、優先度２が対応づけられた未発行のアクセスチケットのうち１つのアクセスチケットを選択して、発行済みフラグとしてＴＲＵＥを格納し、発行日時に現在日時を格納し、発行先優先度に１を格納する。このように、チケット管理テーブルにおいて発行済みフラグ、発行日時及び発行先優先度を設定することを、「アクセスチケットを発行済みにする」等と呼ぶ場合がある。

なお、チケット管理テーブルにおいて優先度２が対応づけられたアクセスチケットの数がＮである場合、Ｍ＜Ｎであるとする。すなわち、優先度２のサービス要求に対して、少なくとも１以上の（Ｎ－Ｍ）個のアクセスチケット枠が確保されているものとする。

図４の（Ｂ）において、「Ａ」、「Ｂ」、「Ｃ」、及び「Ｄ」は、それぞれクライアント装置２０ａ、クライアント装置２０ｂ、クライアント装置２０ｃ、及びクライアント装置２０ｄを示す。クライアント装置２０ｃ及びクライアント装置２０ｄへのサービス提供の優先度は、クライアント装置２０ａ及びクライアント装置２０ｂへのサービス提供の優先度より高い。このように優先度を設定することで、クライアント装置２０ａやクライアント装置２０ｂから大量のアクセスチケット要求が送信された場合でも、１線端末又は２線端末であるクライアント装置２０ｃやクライアント装置２０ｄにアクセスチケットを送信することが可能になる。そのため、クライアント装置２０ｃ及びクライアント装置２０ｄは、クライアント装置２０ａやクライアント装置２０ｂから大量のアクセスチケット要求が一斉に送信された場合でも、サーバ装置３０から顧客データをダウンロードすることができる。これにより、窓口で顧客を待たせる時間を削減することができる。

図４の（Ｃ）は、管理部２４０が管理する待ち行列の一例である。待ち行列は、管理装置４０の揮発性メモリに格納されてよい。待ち行列は、格納部４４に格納されてもよい。

待ち行列は、クライアントＩＤと、優先度と、発行先優先度と、要求優先度と、発行順位とを対応づける。「クライアントＩＤ」には、クライアント装置２０を識別する情報が格納される。「優先度」は、発行するべきアクセスチケットの優先度を示す情報が格納される。上述したように、「優先度」は、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけられた優先度と、アクセスチケット要求に含まれる優先度情報が示す優先度とに基づいて決定される。「優先度」は、クライアントＩＤで識別されるクライアント装置２０に対するサービス提供の優先度を示す情報の一例である。

「発行先優先度」には、アクセスチケット要求を発行したクライアント装置２０のクライアントＩＤに対応づけられた優先度が格納される。「要求優先度」には、アクセスチケット要求に含まれる優先度情報が示す優先度が格納される。「発行順位」には、待ち行列に「優先度」が同一のクライアント装置２０からのアクセスチケット要求が複数格納されている場合において、アクセスチケットの発行対象として選択されるべき順位が格納される。管理部２４０は、発行先優先度に基づいて「発行順位」を決定する。例えば、管理部２４０は、発行先優先度１のアクセスチケット要求に対して発行順位１を決定し、発行先優先度２のアクセスチケット要求に対して発行順位２を決定してよい。このように、管理部２４０は、発行先優先度が高いほど、高い発行順位を決定してよい。

判断部２２０は、終了通知受信部２５０がクライアント装置２０からアクセスチケット返却情報を受信した場合に、待ち行列の「優先度」のを参照して、受信したアクセスチケット返却情報に含まれるアクセスチケットＩＤに対応づけられた優先度に適合する「優先度」に対応づけられたクライアントＩＤが存在する場合に、当該クライアントＩＤで識別されるクライアント装置２０にアクセスチケットを送信すると判断する。なお、アクセスチケット返却情報に含まれるアクセスチケットＩＤに対応づけられた優先度と同一の「優先度」に対応づけられたクライアントＩＤが複数存在する場合、判断部２２０は、「発行順位」に従って、アクセスチケットの送信対象となるクライアント装置２０を選択する。具体的には、判断部２２０は、より高い「発行順位」に対応づけられたクライアントＩＤで識別されるクライアント装置２０を、アクセスチケットの送信対象となるクライアント装置２０として、より優先して選択する。

このように、サーバ装置３０が待ち行列でアクセスチケットを管理するので、クライアント装置２０は、アクセスチケットの再送を要求する必要がない。また、クライアント装置２０は、管理装置４０にアクセスチケットが返却され次第、速やかにアクセスチケットを取得することができる。

図５は、管理装置４０における処理を示すフローチャートである。本フローチャートは、管理装置４０がクライアント装置２０又はサーバ装置３０からデータを受信した場合に開始される。

Ｓ５０２において、管理装置４０の処理部４２は受信したデータの種別を判断する。受信データの種別がアクセスチケット要求である場合、要求受信部２１０に受信データが提供される。この場合、Ｓ５０４において、判断部２２０は、受信したアクセスチケット要求の送信元のクライアント装置２０に対するサービス提供の優先度を決定する。例えば、判断部２２０は、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけて優先度テーブルに格納されている優先度に基づいて、サービス提供の優先度を決定する。

上述したように、クライアント装置２０は、優先度を示す優先度情報を含むアクセスチケット要求を管理装置４０に送信してもよい。アクセスチケット要求に優先度情報が含まれる場合、判断部２２０は、アクセスチケット要求に含まれる優先度情報が示す優先度を、クライアント装置２０に対するサービス提供の優先度として決定してよい。また、判断部２２０は、アクセスチケット要求に含まれる優先度と、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤに対応づけて優先度テーブルに格納されている優先度との積に基づいて、サービス提供の優先度を決定してもよい。

Ｓ５０６において、判断部２２０は、優先度に適合する未発行のアクセスチケットがあるか否かを判断する。例えば、判断部２２０は、Ｓ５０４で決定した優先度に対応づけられたアクセスチケットのうち、発行済みフラグがＦＡＬＳであり、かつ、使用可能フラグがＴＲＵＥであるアクセスチケットが存在するか否かを判断する。なお、判断部２２０は、上述したように、Ｓ５０４で決定したサービス提供の優先度より低い優先度に対応づけられたアクセスチケットに未発行のアクセスチケットがあり、かつ、より高い優先度のサービス要求に対して発行されたアクセスチケットの数が閾値Ｍ未満の場合に、優先度に適合する未発行のアクセスチケットが存在すると判断してよい。

Ｓ５０６において優先度に適合する未発行のアクセスチケットがあると判断した場合、管理部２４０は、未発行のアクセスチケットを１つ選択し（Ｓ５０８）、Ｓ５１０において、アクセスチケットを発行済みに設定する。

Ｓ５１２において、送信部２３０は、クライアント装置２０にアクセスチケットを送信する。具体的には、送信部２３０は、Ｓ５０８で選択したアクセスチケットＩＤを含むアクセスチケットとして送信する。

Ｓ５０６において、優先度に適合する未発行のアクセスチケットがないと判断した場合、Ｓ５１４において、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤと、サービス提供の優先度とを、待ち行列に追加する。

Ｓ５０２において、受信データの種別がアクセスチケット返却通知である場合、終了通知受信部２５０に受信データが提供される。アクセスチケット返却通知には、アクセスチケットのチケットＩＤが含まれる。管理部２４０は、アクセスチケット返却通知に含まれるチケットＩＤで識別されるアクセスチケットを、未発行に設定する。例えば、管理部２４０は、チケット管理テーブルにおいて、チケットＩＤに対応づけて発行済みフラグにＦＡＬＳを格納し、発行日時にＮＵＬＬ値を格納する。

Ｓ５２２において、判断部２２０は、管理部２４０により管理されている待ち行列において、返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤが格納されているか否かを判断する。「返却されたアクセスチケットの優先度に適合する優先度」とは、Ｓ５０６等で説明したように、返却されたアクセスチケットの優先度と同じ優先度の他に、返却されたアクセスチケットの優先度未満の優先度を含み得る。例えば、判断部２２０は、返却されたアクセスチケットの優先度より低い優先度に対応づけられたアクセスチケットに未発行のアクセスチケットがあり、かつ、より高い優先度のサービス要求に対して発行されたアクセスチケットの数が閾値Ｍ未満の場合に、返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤが待ち行列に格納されていると判断してよい。

返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤが待ち行列に格納されている場合に、Ｓ５２４において、返却されたアクセスチケットを発行済みに設定する。Ｓ５２６において、送信部２３０は、返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤで識別されるクライアント装置２０に、アクセスチケットを送信する。上述したように、返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤが待ち行列に複数存在する場合、アクセスチケットの送信対象となるクライアント装置２０は、待ち行列の「発行順位」に従って選択される。なお、Ｓ５２２において、返却されたアクセスチケットの優先度に適合する優先度に対応するクライアントＩＤが待ち行列に格納されていない場合は、本フローチャートの処理を終了する。

Ｓ５０２において、受信データの種別がサーバ装置３０からの許容アクセス数情報である場合、許容量受信部２６０に受信データが提供される。この場合、Ｓ５３０において、管理部２４０は、許容量受信部２６０が受信した許容アクセス数情報により示されるアクセス数を超えないように、「使用可能フラグ」がＴＲＵＥのアクセスチケットの数を調整する。

図６は、クライアント装置２０における処理を示すフローチャートである。本フローチャートは、クライアント装置２０において、サーバ装置３０にサービス要求を送信する操作が行われた場合に、開始される。例えば、クライアント装置２０において、ウエブブラウザに表示されている顧客データダウンロードボタンがクリックされた後に、開始される。

Ｓ６０２において、クライアント装置２０は、管理装置４０にアクセスチケット要求を送信する。例えば、クライアント装置２０で動作するウエブブラウザに表示される顧客データダウンロードボタンには、ボタンのクリックに応じて管理装置４０にアクセスチケット要求を送信する動作を行うＪａｖａＳｃｒｉｐｔ（登録商標）関数が対応づけられており、ダウンロードボタンがクリックされることによって当該関数が実行されることで、アクセスチケット要求が管理装置４０に送信されてよい。その他、ダウンロードボタンのクリックに応じて、管理装置４０にアクセスチケット要求を送信する操作を受け付けるボタンが表示され、当該ボタンがクリックされることによって、アクセスチケット要求が管理装置４０に送信されてよい。

Ｓ６０４において、クライアント装置２０は、管理装置４０からのアクセスチケットの受信を待つ。Ｓ６０６において、クライアント装置２０は、受信したアクセスチケットを利用するか否かを判断する。例えば、クライアント装置２０は、Ｓ６０４でアクセスチケットの受信を待っている期間内にダウンロードのキャンセルボタンがクリックされなかった場合に、アクセスチケットを利用すると判断し、ダウンロードのキャンセルボタンがクリックされた場合に、アクセスチケットを利用しないと判断してよい。

クライアント装置２０は、管理装置４０から受信したアクセスチケットを利用すると判断した場合に、Ｓ６０８において、サーバ装置３０へのリクエストを生成する。例えば、クライアント装置２０ａがＲＰＡ機能によりサーバ装置３０にアクセスする場合、渉外担当者のスケジュール情報を収集して、渉外担当者が翌日に出掛ける取引先の顧客を示す顧客指定情報を含むリクエストを生成する。Ｓ６１０において、Ｓ６０８で生成したリクエストを、サーバ装置３０に送信する。なお、クライアント装置２０は、アクセスチケットをサーバ装置３０には送信しない。アクセスチケットは、サーバ装置３０にサービス要求を送信することをクライアント装置２０に許可することをクライアント装置２０に通知するために、クライアント装置２０とサーバ装置３０との間でのみやりとりされる情報である。

Ｓ６１２において、クライアント装置２０は、サーバ装置３０からのレスポンスが正常レスポンスか異常レスポンスかを判断する。正常レスポンスである場合、Ｓ６１４において、クライアント装置２０は、正常レスポンスによってサーバ装置３０から提供されるデータを、不揮発性の記録媒体に格納する。続いて、Ｓ６１６において、クライアント装置２０は、Ｓ６０４で受信したアクセスチケットを管理装置４０に返却する。具体的には、クライアント装置２０は、Ｓ６０４で受信したチケットＩＤを含むアクセスチケット返却情報を管理装置４０に送信する。続いて、クライアント装置２０は、Ｓ６１８において、サーバ装置３０からのレスポンスで提供されたデータを用いて処理を行う。例えば、クライアント装置２０ａがサーバ装置３０から受信したレスポンスに含まれる顧客データを、渉外担当者の電子メールアドレス宛に送信する。

Ｓ６１２において、サーバ装置３０からのレスポンスが異常レスポンスである場合、クライアント装置２０は、Ｓ６２０においてアクセスチケット返却情報を管理装置４０に送信する。また、Ｓ６０６において、管理装置４０から受信したアクセスチケットを利用しないと判断した場合も、クライアント装置２０は、Ｓ６２０においてアクセスチケット返却情報を管理装置４０に送信する。

図６等に関連して説明したように、クライアント装置２０は、管理装置４０から送信されるアクセスチケットの受信を待って、サービス要求を生成するための情報を収集して、サービス要求を生成する。サーバ装置３０へのアクセス数は管理装置４０により管理されているので、クライアント装置２０はリクエストの送信後、サーバ装置３０からすぐにレスポンスを受信することができる。そのため、リクエストのために確保したリソースを維持する時間を短縮することができる。また、仮にアクセスチケットを長時間受信できずにリクエストをキャンセルすることになったとしても、クライアント装置２０がアクセスチケットを取得せずにサーバ装置３０にリクエストを送信する方式に比べると、リクエストの生成に消費する時間やリソースが無駄になることがない。また、クライアント装置２０は、管理装置４０からアクセスチケットを受信した後、サーバ装置３０にリクエストを送信する段階において、サーバ装置３０からのレスポンスを処理するためのリソースを確保すればよい。そのため、クライアント装置２０がレスポンスにかかるリソースを維持する時間を短縮することができる。

なお、以上に説明した実施形態では、管理部２４０は、アクセスチケット要求をクライアント装置２０から受信した場合において、未発行のアクセスチケットがない場合には、アクセスチケット要求の送信元のクライアント装置２０のクライアントＩＤを待ち行列に追加することによって、クライアント装置２０へのアクセス要求の送信許可を管理する。管理部２４０は、待ち行列によってアクセス要求の送信許可を管理することに加えて、又は、待ち行列によってアクセス要求の送信許可を管理することに代えて、クライアント装置２０がサーバ装置３０にサービス要求を送信するまでの待ち時間を管理することによって、アクセス要求の送信許可を管理してもよい。例えば、図５のＳ５１４に加えて、又は、Ｓ５１４に代えて、管理部２４０は、クライアント装置２０がサーバ装置３０にサービス要求を送信するまでの待ち時間を決定して、管理部２４０が決定した待ち時間を含むアクセスチケットを、送信部２３０がクライアント装置２０に送信してもよい。

図７は、待ち時間を含むアクセスチケットをクライアント装置２０に送信するタイムチャートを示す。図７において、時刻ｔ＝０において、未発行のアクセスチケット数がＸ個であり、時刻ｔ＝０において、クライアント装置２０から短時間でＺ個のアクセスチケット要求が管理装置４０に送信された状況を示す。なお、ここでは、管理部２４０が待ち行列で管理するアクセスチケット要求の数がＹ個であるとする。また、Ｚ＞Ｘ＋Ｙであるとする。

管理部２４０は、Ｘ個のアクセスチケット要求のそれぞれに対して、未発行のアクセスチケットの中から１つずつアクセスチケットを選択する。これにより、送信部２３０は、Ｘ個のアクセスチケット要求のそれぞれに対応するアクセスチケットをクライアント装置２０に送信する。また、管理部２４０は、Ｙ個のアクセスチケット要求を、待ち行列に格納する。

管理部２４０は、残りのＺ－Ｘ－Ｙ個のアクセスチケット要求については、待ち時間Ｔを含むアクセスチケットをクライアント装置２０に送信する。クライアント装置２０は、待ち時間Ｔを含むアクセスチケットを受信した場合、当該アクセスチケットを受信してから待ち時間Ｔが経過したことを条件として、サーバ装置３０にサービス要求を送信する。

ここで、待ち時間Ｔは、Ｔ０以上の時間であってよい。Ｔ０は、例えば、サーバ装置３０がＸ＋Ｙ個のサービス要求への応答に要する最大時間であってよい。例えば、サーバ装置３０において１つのサービス要求を受信してからレスポンスを返すまでの時間Ｔｍａｘが定められている場合、Ｔ０＝（Ｘ＋Ｙ）Ｔｍａｘであってよい。なお、管理部２４０は、待ち時間Ｔとして、クライアント装置２０毎に異なる値を設定してよい。管理部２４０は、ランダムな待ち時間Ｔを含むアクセスチケットをクライアント装置２０に送信してよい。これにより、クライアント装置２０からサーバ装置３０に送信されるサービス要求を分散させることができる。

なお、管理部２４０は、サービス提供の優先度がより高いアクセスチケット要求を送信したクライアント装置２０のクライアントＩＤを、より優先して待ち行列に格納してよい。例えば、クライアント装置２０ｃやクライアント装置２０ｄからアクセスチケット要求の受信した場合に、クライアント装置２０ｃやクライアント装置２０ｄのクライアントＩＤを待ち行列に格納し、優先度がより低いクライアント装置２０ａ及びクライアント装置２０ｂからアクセスチケット要求を受信した場合に、待ち時間Ｔを含むアクセスチケットを送信してもよい。

以上に説明したシステム１０によれば、クライアント装置２０からサーバ装置３０に一斉にサービス要求が送信されることを抑制することができる。また、システム１０によれば、クライアント装置２０のアクセスチケット要求に対して優先度を割り当てることができる。そのため、１線端末であるクライアント装置２０ｃや２線端末等であるクライアント装置２０ｄによるサーバ装置３０へのアクセスと、ＲＰＡ機能により顧客データを収集するクライアント装置２０ａや、翌日の出張先の顧客データを収集するクライアント装置２０ｂからのアクセスとを分離して、サービス提供することができる。そのため、サーバ装置３０におけるアクセス制御プログラムを改修することなく、クライアント装置２０ｃやクライアント装置２０ｄが優先的にサーバ装置３０にサービス要求を行わせることが可能になる。そのため、クライアント装置２０ａやクライアント装置２０ｂのサービス要求によって、クライアント装置２０ｃやクライアント装置２０ｄからのサービス要求に対して応答遅延が生じる可能性を低減することができる。

以上に説明したシステム１０において、管理部２４０は、チケット管理テーブルでアクセスチケットの発行を管理する。管理部２４０は、テーブルによってアクセスチケットの発行を管理する方式の他に、様々な方式でアクセスチケットの発行を管理できる。例えば、管理部２４０は、連結リスト方式により、アクセスチケットの発行を管理してよい。また、管理部２４０は、未発行のアクセスチケット数のみを管理してもよい。例えば、管理部２４０は、アクセスチケットを発行する毎に、未発行のアクセスチケット数をデクリメントし、アクセスチケット返却情報を受信する毎に、未発行のアクセスチケット数をインクリメントしてよい。

また、システム１０において、クライアント装置２０の全てが、サーバ装置３０にサービス要求を送信する前にアクセスチケット要求を管理装置４０に送信するものとした。しかし、クライアント装置２０のうち一部のクライアント装置２０のみが、サーバ装置３０にサービス要求を送信する前にアクセスチケット要求を管理装置４０に送信し、クライアント装置２０のうち他のクライアント装置２０は、管理装置４０にアクセスチケット要求を送信することなくサービス要求をサーバ装置３０に送信してもよい。例えば、クライアント装置２０ａ及びクライアント装置２０ｂがサーバ装置３０にサービス要求を送信する前にアクセスチケット要求を管理装置４０に送信し、クライアント装置２０ｃ及びクライアント装置２０ｄは、アクセスチケット要求を管理装置４０に送信することなくサービス要求をサーバ装置３０に送信してもよい。

上記の説明においては、主として、クライアント装置２０のそれぞれに優先度が割り当てられる場合を具体的に説明したが、クライアント装置２０に優先度が割り当てられていなくてもよい。クライアント装置２０に優先度が割り当てられていない場合、判断部２２０は、サーバ装置３０にアクセスする予め定められた権限を示す情報が要求情報に含まれる場合に、当該要求情報を送信したクライアント装置２０に、サーバ装置３０へのサービス要求の送信を許可してよい。例えば、サーバ装置３０にアクセスする権限を示す情報として、アクセスチケット要求に含まれる優先度情報を適用してよい。この場合、判断部２２０は、要求受信部２１０が受信したアクセスチケット要求に含まれる優先度情報が示す優先度に適合する未発行のアクセスチケットがチケット管理テーブルに存在する場合に、アクセスチケットを送信すると判断してよい。

なお、管理装置４０の各部は、ハードウエアにより実現されてもよく、ソフトウエアにより実現されてもよく、ハードウエア及びソフトウエアにより実現されてもよい。管理装置４０の各部は、その少なくとも一部が、単一のサーバによって実現されてもよく、複数のサーバによって実現されてもよい。管理装置４０の各部は、その少なくとも一部が、仮想マシン上又はクラウドシステム上で実現されてもよい。管理装置４０の各部は、その少なくとも一部が、パーソナルコンピュータ又は携帯端末によって実現されてもよい。携帯端末としては、携帯電話、スマートフォン、ＰＤＡ、タブレット、ノートブック・コンピュータ又はラップトップ・コンピュータ、ウエアラブル・コンピュータなどを例示することができる。管理装置４０は、ブロックチェーンなどの分散型台帳技術又は分散型ネットワークを利用して、情報を格納してもよい。

管理装置４０を構成する構成要素の少なくとも一部がソフトウエアにより実現される場合、当該ソフトウエアにより実現される構成要素は、一般的な構成の情報処理装置において、当該構成要素に関する動作を規定したソフトウエア又はプログラムを起動することにより実現されてよい。上記の一般的な構成の情報処理装置は、（ｉ）ＣＰＵ、ＧＰＵなどのプロセッサ、ＲＯＭ、ＲＡＭ、通信インタフェースなどを有するデータ処理装置と、（ｉｉ）キーボード、ポインティングデバイス、タッチパネル、カメラ、音声入力装置、ジェスチャ入力装置、各種センサ、ＧＰＳ受信機などの入力装置と、（ｉｉｉ）表示装置、音声出力装置、振動装置などの出力装置と、（ｉｖ）メモリ、ＨＤＤ、ＳＳＤなどの記憶装置（外部記憶装置を含む。）とを備えてよい。

上記の一般的な構成の情報処理装置において、上記のデータ処理装置又は記憶装置は、上記のソフトウエア又はプログラムを記憶してよい。上記のソフトウエア又はプログラムは、プロセッサによって実行されることにより、上記の情報処理装置に、当該ソフトウエア又はプログラムによって規定された動作を実行させる。上記のソフトウエア又はプログラムは、非一時的なコンピュータ可読記録媒体に格納されていてもよい。上記のソフトウエア又はプログラムは、コンピュータを、管理装置４０又はその一部として機能させるためのプログラムであってよい。上記のソフトウエア又はプログラムは、コンピュータに、管理装置４０又はその一部における情報処理を実行させるためのプログラムであってよい。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。また、技術的に矛盾しない範囲において、特定の実施形態について説明した事項を、他の実施形態に適用することができる。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。

１０ システム
１２ ネットワーク
２０ クライアント装置
３０ サーバ装置
４０ 管理装置
４２ 処理部
４４ 格納部
４８ 記憶部
２１０ 要求受信部
２２０ 判断部
２３０ 送信部
２４０ 管理部
２５０ 終了通知受信部
２６０ 許容量受信部

Claims (6)

1. クライアント装置であって、
   前記クライアント装置は、
   複数のクライアント装置からサーバ装置へのサービス要求の送信を許可する管理装置から、前記サーバ装置に前記サービス要求を送信することを許可する許可情報を受信し、
   前記管理装置から前記許可情報を受信した後に、前記サーバ装置に前記サービス要求を送信し、
   前記サービス要求に応じて前記サーバ装置から応答を受信すると、前記許可情報を返却することを示す返却情報を前記管理装置に送信し、
   前記クライアント装置は、前記サーバ装置に前記サービス要求を送信する場合に、受信した前記許可情報を利用するか否かを判断し、受信した前記許可情報を利用すると判断した場合に、前記サーバ装置に前記サービス要求を送信する
   クライアント装置。
2. クライアント装置であって、
   前記クライアント装置は、
   複数のクライアント装置からサーバ装置へのサービス要求の送信を許可する管理装置から、前記サーバ装置に前記サービス要求を送信することを許可する許可情報を受信し、
   前記管理装置から前記許可情報を受信した後に、前記サーバ装置に前記サービス要求を送信し、
   前記サービス要求に応じて前記サーバ装置から応答を受信すると、前記許可情報を返却することを示す返却情報を前記管理装置に送信し、
   前記クライアント装置は、（ｉ）前記サーバ装置に前記サービス要求を送信する場合に、受信した前記許可情報を利用するか否かを判断し、受信した前記許可情報を利用しないと判断した場合に、前記返却情報を前記管理装置に送信する、又は、（ｉｉ）前記サービス要求に応じて前記サーバ装置から正常応答及び異常応答のいずれを受信した場合でも、前記返却情報を前記管理装置に送信する
   クライアント装置。
3. クライアント装置であって、
   前記クライアント装置は、
   複数のクライアント装置からサーバ装置へのサービス要求の送信を許可する管理装置から、前記サーバ装置に前記サービス要求を送信することを許可する許可情報を受信し、
   前記管理装置から前記許可情報を受信した後に、前記サーバ装置に前記サービス要求を送信し、
   前記サービス要求に応じて前記サーバ装置から応答を受信すると、前記許可情報を返却することを示す返却情報を前記管理装置に送信し、
   前記クライアント装置は、前記管理装置から待ち時間を含む前記許可情報を受信した場合に、前記待ち時間が経過したことを条件として、前記サーバ装置に前記サービス要求を送信する
   クライアント装置。
4. 前記クライアント装置は、前記サーバ装置にアクセスする場合に前記サービス要求の送信許可を要求する要求情報を前記管理装置に送信し、前記要求情報に対する前記許可情報を受信した後に、前記サーバ装置に前記サービス要求を送信する
   請求項１から３のいずれか一項に記載のクライアント装置。
5. 前記許可情報は、前記管理装置から前記複数のクライアント装置に送信される許可情報のそれぞれを識別する識別情報を含み、
   前記クライアント装置は、前記サービス要求に応じて前記サーバ装置から応答を受信すると、前記管理装置から受信した前記許可情報に含まれる識別情報を前記返却情報に含めて、前記返却情報を前記管理装置に送信する
   請求項１から４のいずれか一項に記載のクライアント装置。
6. 請求項１から５のいずれか一項に記載のクライアント装置と、
   前記管理装置と
   を備えるシステム。

Images