(57)【要約】      （修正有）【課題】通信帯域が様々な態様で使用される場合において、通信帯域の効率的な利用が可能な装置およびプログラムを提供する。【解決手段】通信量制御装置は、端末で使用されるアプリケーションから、接続キーを含むセッション確立のためのリクエストを取得するリクエスト取得部２０１と、接続キーが既にリクエストに応じてセッションが確立されているリクエストに含まれていた接続キーと異なる新たな接続キーである場合に、アプリケーションとの接続数を更新する接続数情報更新部２０６と、更新された接続数があらかじめ設定された最大接続数以下である場合に、アプリケーションとセッションを確立するためのレスポンスを返信するリクエスト返信部２１０を含む。【選択図】図２
2016063528.tif 000002
【特許請求の範囲】
【請求項１】
端末で使用されるアプリケーションから、接続キーを含むセッション確立のためのリクエストを取得するリクエスト取得手段と、
前記接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと異なる新たな接続キーである場合に、前記アプリケーションとの接続数を更新する接続数更新手段と、
前記更新された接続数があらかじめ設定された最大接続数以下である場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信するレスポンス返信手段と、
を含むことを特徴とする通信量制御装置。
【請求項２】
前記レスポンス返信手段は、前記取得されたリクエストに含まれる接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと同じ接続キーである場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信する、
ことを特徴とする請求項１記載の通信量制御装置。
【請求項３】
前記通信量制御装置は、更に、前記アプリケーションから前記セッション確立後に取得したリクエストを実行するリクエスト実行手段を有し、
前記リクエスト実行手段は、前記セッション確立のためのリクエストに含まれる接続キーと同一の接続キーに対応するリクエストが実行中である場合に、該実行中のリクエストが終了した後に、前記セッション確立後に取得したリクエストを実行する、
ことを特徴とする請求項１または２に記載の通信量制御装置。
【請求項４】
前記リクエスト実行手段は、前記セッション確立のためのリクエストに含まれる接続キーと同一の接続キーに対応するリクエストが実行中でない場合に、前記セッション確立後に取得したリクエストを実行することを特徴とする請求項３記載の通信量制御装置。
【請求項５】
前記最大接続数は、アプリケーション毎に設定されることを特徴とする請求項１乃至４のいずれかに記載の通信量制御装置。
【請求項６】
前記通信量制御装置は、更に、前記セッションにおける通信速度を制限する通信速度制限手段を含むことを特徴とする請求項１乃至５のいずれかに記載の通信量制御装置。
【請求項７】
端末で使用されるアプリケーションから、接続キーを含むセッション確立のためのリクエストを取得するリクエスト取得手段、
前記接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと異なる新たな接続キーである場合に、前記アプリケーションとの接続数を更新する接続数更新手段、及び、
前記更新された接続数があらかじめ設定された最大接続数以下である場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信するレスポンス返信手段、
としてコンピュータを機能させることを特徴とする通信量制御プログラム。  
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信量制限装置、通信量制限プログラムに関する。
【背景技術】
【０００２】
例えば、下記特許文献１には、通信帯域に制限のある環境においては、通信量の多い時間帯ではクライアントへのサーバのレスポンスが低下し、システムの操作性が悪化するという点に鑑みて、通信量の多い時間帯では、クライアントからサーバに対してデータを転送する容量を予め予約し、通信量の少ない時間帯において、データの通信を行うことにより、通信量の多い時間帯における通信量を下げるデータ転送方式が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−８３３６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、端末の任意のアプリケーション（以下、「アプリ」という。）から接続されるＡＰＩ(Application Programming Interface)をサーバから提供する場合、例えば、ＧＵＩアプリでは日中の利用頻度が高く、即時性が求められるが、定期的に実行するアプリでは、時間帯による利用頻度の変化は少なく、即時性も不要である場合があるなど、通信帯域が様々な態様で使用され、通信帯域の効率的な利用が困難である場合がある。また、複数のＡＰＩ利用アプリからサーバに接続される場合、ＡＰＩ利用アプリとのセッション数の管理が困難である。
【０００５】
本発明は、例えば、上記のように通信帯域が様々な態様で使用される場合においても、より効率的に通信帯域が使用され得る通信量制限装置、通信量制限方法、通信量制限プログラムを実現することを目的とする。
【課題を解決するための手段】
【０００６】
請求項１に記載の通信量制御装置は、端末で使用されるアプリケーションから、接続キーを含むセッション確立のためのリクエストを取得するリクエスト取得手段と、前記接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと異なる新たな接続キーである場合に、前記アプリケーションとの接続数を更新する接続数更新手段と、前記更新された接続数があらかじめ設定された最大接続数以下である場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信するレスポンス返信手段と、を含むことを特徴とする。
【０００７】
請求項２に記載の通信量制御装置は、請求項１に記載の発明において、前記レスポンス返信手段は、前記取得されたリクエストに含まれる接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと同じ接続キーである場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信する、ことを特徴とする。
【０００８】
請求項３に記載の通信量制御装置は、請求項１または２に記載の発明において、前記通信量制御装置は、更に、前記アプリケーションから前記セッション確立後に取得したリクエストを実行するリクエスト実行手段を有し、前記リクエスト実行手段は、前記セッション確立のためのリクエストに含まれる接続キーと同一の接続キーに対応するリクエストが実行中である場合に、該実行中のリクエストが終了した後に、前記セッション確立後に取得したリクエストを実行する、ことを特徴とする。
【０００９】
請求項４に記載の通信量制御装置は、請求項３に記載の発明において、前記リクエスト実行手段は、前記セッション確立のためのリクエストに含まれる接続キーと同一の接続キーに対応するリクエストが実行中でない場合に、前記セッション確立後に取得したリクエストを実行することを特徴とする。
【００１０】
請求項５に記載の通信量制御装置は、請求項１乃至４のいずれかに記載の発明において、前記最大接続数は、アプリケーション毎に設定されることを特徴とする。
【００１１】
請求項６に記載の通信量制御装置は、請求項１乃至５のいずれかに記載の発明において、前記通信量制御装置は、更に、前記セッションにおける通信速度を制限する通信速度制限手段を含むことを特徴とする。
【００１２】
請求項７に記載の通信量制御プログラムは、端末で使用されるアプリケーションから、接続キーを含むセッション確立のためのリクエストを取得するリクエスト取得手段、前記接続キーが、既にリクエストに応じてセッションが確立されている該リクエストに含まれていた接続キーと異なる新たな接続キーである場合に、前記アプリケーションとの接続数を更新する接続数更新手段、及び、前記更新された接続数があらかじめ設定された最大接続数以下である場合に、前記アプリケーションとセッションを確立するためのレスポンスを返信するレスポンス返信手段、としてコンピュータを機能させることを特徴とする。
【発明の効果】
【００１３】
請求項１、２、６、７に記載の発明によれば、接続キーにより接続数が管理される。
【００１４】
請求項３、４に記載の発明によれば、同一の接続キーに対応するリクエストが順に実行される。
【００１５】
請求項５に記載の発明によれば、アプリケーション毎に最大接続数の管理が可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態に係る通信量制限システムのハードウェア構成の概要について説明するための図である。
【図２】サーバの機能的構成の概要の一例について説明するための図である。
【図３】接続情報の一例を示す図である。
【図４】接続数情報の一例を示す図である。
【図５】実行情報の一例を示す図である。
【図６】セッション確立時におけるサーバの処理のフローの概要の一例を説明するための図である。
【図７】セッション確立後におけるサーバの処理のフローの一例について説明するための図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施形態について、図面を参照しつつ説明する。なお、図面については、同一又は同等の要素には同一の符号を付し、重複する説明は省略する。
【００１８】
図１は、本発明の実施形態に係る通信量制限システムのハードウェア構成の概要について説明するための図である。図１に示すように、通信量制限システム１００は、ネットワーク１３０（例えば、インターネット）を介して接続されたサーバ１１０及び端末１２０を有する。
【００１９】
サーバ１１０は、制御部１１１、記憶部１１２、通信部１１３を含む。制御部１１１は、例えば、ＣＰＵ等であって、記憶部１１２に格納されたプログラムに従って動作する。記憶部１１２は、例えば、ハードディスクやＲＯＭやＲＡＭ等の情報記録媒体で構成され、制御部１１１によって実行されるプログラムを保持する情報記録媒体である。また、記憶部１１２は、制御部１１１のワークメモリとしても動作する。
【００２０】
通信部１１３は、ネットワークインターフェースであって、制御部１１１からの指示に応じて、ネットワーク１３０を介して、情報を送受信する。なお、制御部１１１、記憶部１１２、通信部１１３は、それぞれ、バス１１４を介して接続される。
【００２１】
また、端末１２０は、制御部１２１、通信部１２２、記憶部１２３、表示部１２４、操作部１２５を含む。同様に、各部１２０乃至１２５は、バス１２６を介して接続される。上述したサーバ１１０と同様に、制御部１２１は、例えば、ＣＰＵであって、記憶部１１２に格納されたプログラムに従って動作する。記憶部１２３は、例えば、ハードディスクやＲＯＭやＲＡＭ等の情報記録媒体で構成され、制御部１２１によって実行されるプログラムを保持する情報記録媒体である。また、記憶部１２３は、制御部１２１のワークメモリとしても動作する。
【００２２】
操作部１２５は、例えば、キーボード、マウス、ボタン等のインターフェースで構成され、ユーザの指示操作に応じて、当該指示操作の内容を制御部１２１に出力する。表示部１２４は、例えば、液晶ディスプレイ、ＣＲＴディスプレイ、または有機ＥＬディスプレイ等であって、制御部１２１からの指示に従い、情報を表示する。
【００２３】
なお、上記制御部１１１及び１２１で処理されるプログラムは、例えば、ネットワークを介して、ダウンロードされて提供されてもよいし、または、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータで読み取り可能な各種の情報記録媒体によって提供されてもよい。また、上記サーバ１１０や端末１２０の構成は一例であってこれに限定されるものではない。また、図１においては１の端末１２０のみを示したが、通信量制限システム１００は、複数の端末１２０を有するように構成してもよい。また、サーバ１１０は、複数のサーバ１１０を含むサーバ群により構成してもよい。具体的には、当該サーバは、例えば、単一のＴＣＰ／ＩＰコネクションにおける通信速度制限を行うリバースプロキシと複数のバックエンドサーバで構成される。更に、上記においては、通信量制限システム１００をいわゆるサーバ・クライアントで構成する場合について主に説明したが、クラウド技術を用いて構成してもよい。
【００２４】
次に、本実施の形態におけるサーバ１１０の機能的構成の概要の一例について説明する。サーバ１１０は、図２に示すように、サーバ１１０は、機能的に、主に、リクエスト取得部２０１、ユーザ認証部２０２、アプリ認証部２０３、接続キー判定部２０４、接続情報保持部２０５、接続数情報更新部２０６、接続数情報保持部２０７、接続数判定部２０８、セッションＩＤ生成部２０９、リクエスト応答部２１０、接続情報更新部２１１、リクエスト実行部２１２、実行情報保持部２１３、リクエスト判定部２１４を含む。
【００２５】
まず、主に、セッション確立時におけるサーバ１１０の機能的構成の一例について説明する。リクエスト取得部２０１は、端末のＡＰＩ利用アプリからリクエストを取得する。具体的には、例えば、リクエスト取得部２０１は、セッション確立時には、端末のＡＰＩ利用アプリからログインするためのリクエスト（ログインリクエスト）を取得する。当該ログインリクエストは、例えば、ユーザＩＤ、パスワード、アプリ用ＩＤ、アプリ用秘密キー、接続キーを含む。
【００２６】
ユーザ認証部２０２は、ログインリクエストに基づき、ユーザ認証を行う。具体的には、例えば、当該リクエストに含まれるユーザＩＤ及びパスワードに基づき、ユーザ認証を行う。
【００２７】
アプリ認証部２０３は、上記ログインリクエストに基づき、アプリケーションを認証する。具体的には、例えば、当該リクエストに含まれるアプリ用ＩＤ及びアプリ用秘密キーに基づき、アプリ認証を行う。なお、ユーザ認証及びアプリ認証については周知であるため、詳細な説明は省略する。
【００２８】
接続キー判定部２０４は、ログインリクエストに含まれる接続キーが新たな接続キーか否か判定する。具体的には、例えば、接続キー判定部２０４は、当該接続キーが接続情報保持部２０５に保持されていない場合に、新たな接続キーと判定する。
【００２９】
ここで、接続情報保持部２０５は、図３に示すように、接続キーとセッションＩＤ（セッション識別情報）を関連付けた接続情報を保持する。例えば、ログインリクエストに含まれる接続キーがＡの場合において、接続情報が図３に示す場合、接続キー判定部２０４は、既に接続キー：Ａが保持されているので、上記ログインリクエストに含まれる新たな接続キーでないと判定する。
【００３０】
なお、接続キーは例えばアプリケーション毎に割り当てられる。また、割り当てられる接続キー数の数については、特定の部署やグループ数と一致するように構成してもよいし、特定の接続については特定の部署やグループにのみ割り当てられるように構成してもよい。更に、接続キーについてはサーバ１１０が生成し、当該サーバ１１０で生成された接続キーをＡＰＩ用のアプリ側で共有するように構成してもよい。この場合、ＡＰＩ用アプリ側でサーバ１１０から現在利用されている接続キーの一覧と、その接続数の値を取得するように構成し、既存の接続キーを使用するか、新規の接続キーを作成するか決定するように構成してもよい。
【００３１】
接続キー判定部２０４がログインリクエストに含まれる新たな接続キーであると判定した場合には、接続数情報更新部２０６は、接続数情報保持部２０７に保持されている接続数情報を更新する。ここで、接続数情報保持部２０７は、例えば、図４に示すように、アプリＩＤ、当該アプリＩＤが示すアプリの最大接続数、当該アプリの現在の接続数を関連付けて保持する。接続キー判定部２０４は、例えば、接続情報が図３に示す場合において、ログインリクエストに含まれる接続キーがＣであり、アプリ用ＩＤがＡ２の場合、ログインリクエストに含まれる接続キー新たな接続キーであるので、接続数情報を３から４に更新する。なお、接続数が既に最大接続数である場合には接続数の更新を行わない。
【００３２】
接続数判定部２０８は、ログインリクエストに対する接続を行った場合に、接続数が最大接続数より大きくなるか否かを判定する。具体的には、例えば、接続数情報保持部２０７に保持されている接続数情報と最大接続数とを比較することにより、接続数が最大接続数より大きくなるか否かを判定する。例えば、接続数情報が図４に示す場合において、ログインリクエストに含まれるアプリ用ＩＤがアプリ用ＩＤ：Ａ１については、既に接続数が５となり、更に接続を行うと最大接続数である５より大きくなることから、接続数が最大接続数より大きくなると判定する。
【００３３】
接続数判定部２０８が、接続数が最大接続数より大きくなると判定した場合には、当該接続を行わない。なお、この場合、当該ＡＰＩアプリにエラーを通知するように構成してもよい。
【００３４】
一方、接続キー判定部２０４が、ログインリクエストに含まれる新たな接続キーでないと判定した場合と、接続数判定部２０８が、接続数が最大接続数以内であると判定した場合には、セッションＩＤ生成部２０９は、セッションＩＤを生成する。
【００３５】
リクエスト返信部２１０は、ログインリクエストに対して生成されたセッションＩＤを含むレスポンスを、当該ログリンリクエストを行ったＡＰＩアプリに返信する。
【００３６】
接続情報更新部２１１は、ログインリクエストに含まれる接続キーと当該生成されたセッションＩＤを関連付けて、接続情報保持部２０５に保持するように接続情報を更新する。具体的には、例えば、上記図３に示すような接続情報を追加するよう更新する。
【００３７】
なお、本実施の形態においては、上記サーバ１１０とは別のサーバ１１０において、上記サーバ１１０とＡＰＩ利用アプリとの各コネクションの速度制限を行うように構成してもよい。また、当該速度制限を行う速度制限部（図示なし）を上記サーバ１１０の機能的構成として設けてもよい。
【００３８】
次に、主に、セッション確立後におけるサーバ１１０の機能的構成の一例について説明する。リクエスト取得部２０１は、端末１００のＡＰＩアプリからリクエストを取得する。当該リクエストは、例えば、セッションＩＤ及び当該リクエストの実行に必要な情報（操作情報）を含む。リクエスト実行部２１２は、当該リクエストに応じた処理を実行する。
【００３９】
実行情報保持部２１３は、リクエスト実行部２１２が実行中のリクエストを表す実行情報を保持する。具体的には、例えば、図５に示すように、リクエスト実行部２１２が実行中のリクエストに対応するセッションＩＤを保持する。
【００４０】
リクエスト判定部２１４は、当該リクエストに含まれるセッションＩＤと同じセッションＩＤを有するリクエストが実行中か否かを判定する。具体的には、例えば、当該リクエストに含まれるセッションＩＤがＸＹＺ７８９の場合であって、実行情報が図５に示す場合、リクエスト判定部２１４は、当該セッションＩＤ：ＸＹＺ７８９が実行情報保持部２１３に保持されていることから、実行中であると判定する。
【００４１】
リクエスト返信部２１０は、リクエスト判定部２１４が当該リクエストに含まれるセッションＩＤと同じセッションＩＤを有するリクエストが実行中であると判定した場合には、セッションを確立しているＡＰＩアプリにエラーを返信する。
【００４２】
一方、リクエスト判定部２１４が、当該リクエストに含まれるセッションＩＤと同じセッションＩＤを有するリクエストが実行中でないと判定した場合には、当該セッションＩＤに関連付けられた接続キーと同一の接続キーに関連付けられたセッションＩＤを取得する。具体的には、例えば、図３に示した場合において、当該リクエストに含まれるセッションＩＤがＸＹＺ７８９の場合、当該セッションＩＤに接続キーＡが関連付けられ、当該接続キーＡに関連付けてセッションＩＤ：ＡＢＣ１２３が関連付けられていることから、セッションＩＤ：ＡＢＣ１２３を取得する。
【００４３】
そして、リクエスト判定部２１４は、同一の接続キーに対応するリクエストが実行中か否か判定する。例えば、上記例の場合、当該セッションＩＤ：ＡＢＣ１２３に対応するリクエストが実行中であるか否か、実行情報保持部２１３に保持されている実行情報を参照して、判定する。この場合、実行情報保持部２１３にはセッションＩＤ：ＡＢＣ１２３が保持されていることから、リクエスト判定部２１４は、実行中であると判定する。
【００４４】
リクエスト判定部２１４は、同一の接続キーに対応するリクエストが実行中であると判定した場合には、当該同一の接続キーに対応するリクエストの実行が終了するまで待機し、当該リクエストの実行が終了した後に、リクエスト実行部２１２に当該リクエストを実行させる。具体的には、上記例の場合、セッションＩＤ：ＡＢＣ１２３に対応するリクエストが終了した後、セッションＩＤ：ＸＹＺ７８９に対応するリクエストを実行させる。
【００４５】
一方、同一の接続キーに対応するリクエストが実行中でないと判定した場合には、リクエスト実行部２１２に当該リクエストを実行させる。
【００４６】
リクエスト返信部２１０は、リクエスト実行部２１２による実行結果をセッションが確立されているＡＰＩアプリに返信する。
【００４７】
次に、図６を用いて、セッション確立時におけるサーバ１１０の処理のフローの概要の一例について説明する。
【００４８】
まず、リクエスト取得部２０１は、端末のＡＰＩアプリからログインリクエストを取得する（Ｓ１０１）。ユーザ認証部２０２は、ログインリクエストに基づき、ユーザ認証を行う（Ｓ１０２）。アプリ認証部２０３は、上記ログインリクエストに基づき、アプリを認証する（Ｓ１０３）。
【００４９】
接続キー判定部２０４は、ログインリクエストに含まれる接続キーが新たな接続キーか否か判定する（Ｓ１０４）。接続キー判定部２０４が新たな接続キーでないと判定した場合には、Ｓ１０７に進む。一方、接続キー判定部２０４が、新たな接続キーであると判定した場合には、接続数情報保持部２０７に保持されている接続数情報を更新する（Ｓ１０５）。
【００５０】
接続数判定部２０８は、ログインリクエストに対する接続を行った場合に、接続数が、最大接続数より大きくなるか否かを判定する（Ｓ１０６）。Ｓ１０６において、接続数が最大接続数より大きくなると判定した場合、Ｓ１０１に戻る。そして、新たなログインリクエストについて上記処理が行われる。なお、この場合、ＡＰＩアプリにエラーを通知するように構成してもよい。
【００５１】
Ｓ１０４で接続キー判定部２０４が、新たな接続キーでないと判定した場合と、Ｓ１０６で接続数判定部２０８が接続数が最大接続数以内であると判定した場合には、セッションＩＤ生成部２０９は、セッションＩＤを生成する（Ｓ１０７）。リクエスト返信部２１０は、ログインリクエストに対して生成されたセッションＩＤを含むレスポンスを、当該ログリンリクエストを行ったＡＰＩアプリに返信する（Ｓ１０８）。接続情報更新部２１１は、ログインリクエストに含まれる接続キーと当該生成されたセッションＩＤを関連付けて、接続情報保持部２０５に保持する（Ｓ１０９）。
【００５２】
次に、図７を用いて、セッション確立後におけるサーバ１１０の処理のフローの一例について説明する。
【００５３】
リクエスト取得部２０１は、リクエストを取得する（Ｓ２０１）。リクエスト判定部２１４は、当該リクエストに含まれるセッションＩＤと同じセッションＩＤを有するリクエストが実行中か否かを判定する（Ｓ２０２）。実行中であると判定した場合には、エラーを通知する（Ｓ２０３）。
【００５４】
一方、実行中でないと判定した場合には、当該セッションＩＤに関連付けられた接続キーに関連付けられたセッションＩＤを接続情報保持部２０５から取得する（Ｓ２０４）。リクエスト判定部２１４は、同一の接続キーに対応するリクエストが実行中か否か判定する（Ｓ２０５）。実行中であると判定した場合には、Ｓ２０４に戻る。つまり、当該リクエストの処理が終了するまで待機し、当該リクエストが終了した後に、リクエスト実行部２１２に当該リクエストを実行させる。
【００５５】
一方、実行中でないと判定した場合には、リクエスト実行部２１２に当該リクエストを実行させる（Ｓ２０６）。リクエスト返信部２１０は、リクエスト実行部２１２による実行結果を返信する（Ｓ２０７）。そして、Ｓ２０１に戻る。
【００５６】
本発明は、上記実施の形態に限定されるものではなく、上記実施の形態で示した構成と実質的に同一の構成、同一の作用効果を奏する構成又は同一の目的を達成することができる構成で置き換えてもよい。
【符号の説明】
【００５７】
１００  通信量制限システム、１１０  サーバ、１１１、１２１  制御部、１１２、１２３  記憶部、１１３、１２２  通信部、１２０  端末、１２４  表示部、１２５  操作部、２０１  リクエスト取得部、２０２  ユーザ認証部、２０３  アプリ認証部、２０４  接続キー判定部、２０５  接続情報保持部、２０６  接続数情報更新部、２０７  接続数情報保持部、２０８  接続数判定部、２０９  セッションＩＤ生成部、２１０  リクエスト応答部、２１１  接続情報更新部、２１２  リクエスト実行部、２１３  実行情報保持部、２１４  リクエスト判定部。
【図１】
2016063528.tif 000003
【図２】
2016063528.tif 000004
【図３】
2016063528.tif 000005
【図４】
2016063528.tif 000006
【図５】
2016063528.tif 000007
【図６】
2016063528.tif 000008
【図７】
2016063528.tif 000009