JP2020135344A - ソフトウェア提供装置及びプログラム - Google Patents

Abstract

【課題】ソフトウェアの提供側がソフトウェアの利用先にかかるネットワーク負荷を考慮してソフトウェアを提供する。【解決手段】ソフトウェア管理サーバ１０は、ライセンスを購入した企業、購入されたアプリケーション及びライセンス管理番号を含むライセンス情報マスタ２２と、購入ライセンス数に応じた同時更新許可数が設定される上限数マスタ２３と、更新確認処理部１１がユーザからの更新情報の確認要求を受信すると、ライセンス情報マスタ２２及び上限数マスタ２３を参照して確認要求をしたユーザが所属する企業において同時にダウンロードが可能なユーザの上限数を決定する上限数決定部１２と、当該企業において現在ダウンロード中のユーザ数が上限数に満たない場合に確認要求をしたユーザに更新モジュールのダウンロードを許可する判定部１３と、を有する。【選択図】図１

Description

本発明は、ソフトウェア提供装置及びプログラムに関する。

事業所においてソフトウェア提供事業者が提供するソフトウェアを所内の複数のユーザに利用させる場合がある。ソフトウェア提供事業者がソフトウェアをバージョンアップすると、バージョンアップした旨の通知を受けたユーザは、各自でソフトウェア提供事業者から更新モジュールをダウンロードしてソフトウェアをバージョンアップする。

従来では、ソフトウェア提供事業者のサーバと連携するローカルサーバを事業所内に設置し、所内の各ユーザは、更新モジュールがローカルサーバにあればローカルサーバから、ローカルサーバになければソフトウェア提供事業者のサーバから、それぞれダウンロードすることで、多くのユーザが同時並行して更新モジュールのダウンロードを行うことにより発生しうるスループットの低下を回避する技術が提案されている（例えば、特許文献１）。

特開２００２−３１２３１２号公報 特開２００５−２３４７２９号公報

従来においては、ソフトウェアが提供される側、換言するとソフトウェアを利用する側でローカルサーバを用意してネットワーク負荷を軽減させるようにしていた。

本発明は、ソフトウェアの提供側がソフトウェアの利用先にかかるネットワーク負荷を考慮してソフトウェアを提供することを目的とする。

本発明に係るソフトウェア提供装置は、複数のユーザがソフトウェアを利用する利用先のユーザからネットワークを介したダウンロードに関する要求を受けた場合に、当該利用先において同時にダウンロードが可能なユーザの上限数を決定する決定手段と、当該利用先におけるダウンロード中のユーザ数が、前記決定手段が決定した上限数に満たない場合に前記要求をしたユーザに対してソフトウェアのダウンロードを許可する許可手段と、を有することを特徴とする。

また、前記決定手段は、ソフトウェアのライセンス契約をユーザ毎にすることで当該ユーザが当該ソフトウェアを使用できる場合、前記利用先が契約しているソフトウェアのライセンス数に応じて前記上限数を決定することを特徴とする。

また、前記決定手段は、前記利用先に対する前記上限数を、当該利用先が契約しているソフトウェアのライセンス数より小さく設定することを特徴とする。

また、前記許可手段が許可したユーザに対してソフトウェアをダウンロードするダウンロード手段と、前記ダウンロード手段がソフトウェアをダウンロードしたときの転送速度を記録する記録手段と、を有し、前記決定手段は、前記記録手段が記録した転送速度を参照して前記利用先に対する上限数を決定することを特徴とする。

また、前記決定手段は、転送速度が下降傾向にある場合、前記上限数を減少させることを特徴とする。

また、前記決定手段は、転送速度に上昇傾向にある場合、前記ソフトウェアの上限数を増加させることを特徴とする。

また、前記ソフトウェアは、バージョンアップ用の更新モジュールであることを特徴とする。

本発明に係るプログラムは、コンピュータを、複数のユーザがソフトウェアを利用する利用先のユーザからネットワークを介したダウンロードに関する要求を受けた場合に、当該利用先において同時にダウンロードが可能なユーザの上限数を決定する決定手段、当該利用先におけるダウンロード中のユーザ数が、前記決定手段が決定した上限数に満たない場合に前記要求をしたユーザに対してソフトウェアのダウンロードを許可する許可手段、として機能させる。

請求項１に記載の発明によれば、ソフトウェアの提供側がソフトウェアの利用先にかかるネットワーク負荷を考慮してソフトウェアを提供することができる。

請求項２に記載の発明によれば、ソフトウェアの利用先に対する上限数を、当該利用先のライセンス数に依存させて設定することができる。

請求項３に記載の発明によれば、同時にダウンロード可能なユーザ数を制限することができる。

請求項４に記載の発明によれば、ネットワーク負荷の指標となる転送速度を参照してソフトウェアの利用先に対して同時にダウンロードが可能なユーザの上限数を決定することができる。

請求項５に記載の発明によれば、上昇傾向にあるネットワーク負荷の増加を防止することができる。

請求項６に記載の発明によれば、ソフトウェアの利用先において同時にダウンロードが可能なユーザ数を増やすことができる。

請求項７に記載の発明によれば、バージョンアップの場合に適用することができる。

請求項８に記載の発明によれば、ソフトウェアの提供側がソフトウェアの利用先にかかるネットワーク負荷を考慮してソフトウェアを提供することができる。

実施の形態１においてソフトウェアを提供する側と利用する側を含むネットワークシステムの構成図である。 実施の形態１におけるバージョン管理マスタに登録されているバージョン情報のデータ構成例を示す図である。 実施の形態１におけるライセンス情報マスタに登録されているライセンス情報のデータ構成例を示す図である。 実施の形態１における上限数マスタに登録されている上限数情報のデータ構成例を示す図である。 実施の形態１において、ユーザ端末にインストールされているアプリケーションをバージョンアップするときにユーザ端末で実施される処理を示すフローチャートである。 実施の形態１において、ユーザ端末にインストールされているアプリケーションをバージョンアップするときにソフトウェア管理サーバで実施される処理を示すフローチャートである。 実施の形態１における更新ログ情報記憶部に記憶されて更新ログ情報のデータ構成例を示す図である。 実施の形態２においてソフトウェアを提供する側と利用する側を含むネットワークシステムの構成図である。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

実施の形態１．
図１は、本実施の形態においてソフトウェアを提供する側と利用する側を含むネットワークシステムの構成図である。図１において、ソフトウェア管理サーバ１０は、ソフトウェアを提供する事業者等に設置されるソフトウェア提供装置の一形態である。企業システム３０は、ソフトウェア管理サーバ１０が提供するソフトウェアの利用先となる企業内に構築されるシステムである。ソフトウェア管理サーバ１０と企業システム３０は共にインターネット２に接続され、インターネット２を介してデータ通信を行うことが可能である。なお、ソフトウェア管理サーバ１０は、複数の企業とライセンス契約を締結するが、企業システム３０は、各企業とも同様の構成を有し、バージョンアップに際しては同様に処理すればよいので、図１には、便宜的に一企業の企業システム３０のみ図示した。

企業システム３０は、企業内の従業員等（以下、「ユーザ」）がそれぞれ使用する複数のユーザ端末３１と、各ユーザ端末３１とソフトウェア管理サーバ１０との間でデータ通信を可能にするルータ３２と、をＬＡＮ３３に接続して構築される。なお、本実施の形態の説明に用いない構成要素は図から省略している。ユーザ端末３１は、企業内のユーザが使用する端末装置である。本実施の形態では、説明の便宜上、各ユーザが使用するユーザ端末３１は決められている、つまり１対１の関係にあるものとして説明する。ユーザ端末３１は、汎用的なパーソナルコンピュータ（ＰＣ）を想定して説明するが、ソフトウェアをインストールして使用する情報処理装置であれば、ＰＣに限る必要はない。また、本実施の形態では、ユーザ端末３１を有線のＬＡＮ３３に接続して使用する例を示しているが、無線にて接続されるように構成してもよい。

ソフトウェア管理サーバ１０は、コンピュータで動作可能な複数種類のソフトウェアを管理し、企業とのライセンス契約によりソフトウェアの利用が許諾されたユーザが使用するユーザ端末３１にソフトウェアを提供する。以降の説明では、各ユーザ端末３１には、ライセンス契約により利用が許諾されているソフトウェアがすでにインストールされているものとして説明する。但し、インストール済みのソフトウェアが最新バージョンであるとは限らない。最新バージョンでない場合、ユーザは、インストール済みのソフトウェアを更新しバージョンアップするためのソフトウェア（以下、「更新モジュール」という）をソフトウェア管理サーバ１０からユーザ端末３１にダウンロードすることで、ソフトウェアを最新バージョンに更新することが可能である。

なお、本実施の形態におけるソフトウェア管理サーバ１０が管理するソフトウェアには、ライセンス契約によりユーザが使用するアプリケーションと、アプリケーションをバージョンアップするための更新モジュールとが含まれる。本実施の形態では、「ソフトウェア」というのは、狭義には「アプリケーション」を示す。そして、アプリケーションをバージョンアップするためのソフトウェアを前述したように「更新モジュール」と称することにしている。

ソフトウェア管理サーバ１０は、汎用的なハードウェア構成のサーバコンピュータで形成される。すなわち、ソフトウェア管理サーバ１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、また
ハードディスクドライブ（ＨＤＤ）等の記憶手段、通信手段としてのネットワークインタフェースを有する。また、後述するマスタデータの更新等のために、入力手段としてのマウスやキーボード、表示手段としてのディスプレイを持たせてもよい。

図１に示すように、ソフトウェア管理サーバ１０は、更新確認処理部１１、上限数決定部１２、判定部１３、ダウンロード処理部１４、バージョン管理マスタ２１、ライセンス情報マスタ２２、上限数マスタ２３、更新ログ情報記憶部２４及び更新モジュールレポジトリ２５を有する。なお、本実施の形態の説明に用いない構成要素については、図から省略している。

更新確認処理部１１は、ユーザからの更新情報の確認要求を受信すると、バージョンアップの要否、またバージョンアップが必要な場合は更新モジュールのダウンロードの可否を含む更新情報を返信する。上限数決定部１２は、更新確認処理部１１がソフトウェアの利用先である企業のユーザからインターネット２を介してダウンロードに関する要求を受けた場合、ここではダウンロードに関する要求として更新情報の確認要求を受けた場合、当該企業において同時にダウンロードが可能なユーザの上限数（以下、単に「上限数」という）を決定する。本実施の形態における上限数決定部１２は、ライセンス情報マスタ２２から導出できる各企業のライセンス数に応じて上限数を企業毎に決定する。上限数決定部１２は、更新情報の確認要求を発信したユーザがバージョンアップする必要がある場合に動作する。

後述するように、更新ログ情報記憶部２４には、更新モジュールを現在ダウンロード中のユーザ（厳密には、当該ユーザのライセンス管理番号）が判別できるようなデータ構成にて更新ログ情報が登録されるが、判定部１３は、当該企業におけるダウンロード中のユーザ数と上限数決定部１２が決定した上限数とを比較し、ユーザ数が上限数に満たない場合に更新情報の確認要求を発信したユーザに対してソフトウェアのダウンロードを許可する。なお、本実施の形態では、説明の便宜上、一ユーザが同時並行して複数のダウンロードをしないことにする。つまり、ダウンロードを実行するユーザ数と、更新モジュールのダウンロード数とは、同値として説明する。ダウンロード処理部１４は、判定部１３によりダウンロード可と判定されたユーザが使用するユーザ端末３１からのダウンロード要求に応じて、更新モジュールを送信（つまり、ダウンロード）する。

図２は、本実施の形態におけるバージョン管理マスタ２１に登録されているバージョン情報のデータ構成例を示す図である。ＳＷ名は、ソフトウェア管理サーバ１０にて管理しているソフトウェア、つまりアプリケーションの識別情報としてのアプリケーション名であるが、このＳＷ名に、当該アプリケーションの最新バージョンが対応付けして設定される。

図３は、本実施の形態におけるライセンス情報マスタ２２に登録されているライセンス情報のデータ構成例を示す図である。ライセンス情報は、ライセンスが付与されるユーザ毎に設定され、ライセンスを識別するライセンスＩＤ（図３では単に「ＩＤ」）に、ＳＷ名、ライセンス及び購入先が対応付けして設定される。ＳＷ名は、ライセンス契約対象のアプリケーションの識別情報としてのアプリケーション名である。ライセンスは、ライセンスの管理番号であり、ライセンスＩＤと同様、ライセンスの識別情報である。購入先は、当該ライセンスを購入した企業である。「購入先」は、前述したソフトウェアの「利用先」と同義である。企業内において、ライセンスの管理番号が各ユーザに割り振られ、ユーザは、管理番号が付与されることで当該アプリケーションが使用できることになる。図示していないが、企業システム３０では、各ユーザが使用するユーザ端末３１とライセンス管理番号とを対応付けして管理している。

図４は、本実施の形態における上限数マスタ２３に登録されている上限数情報のデータ構成例を示す図である。「購入ライセンス数」は、各企業が購入したライセンスの数の範囲を示している。「同時更新許可数」は、対応するライセンス数の範囲にある企業に対して同時並行して更新モジュールをダウンロードしてよいユーザの延べ数である。なお、本実施の形態では、前述したように、一ユーザは同時並行して複数のダウンロードをしないので、ユーザの延べ数を単に「ユーザ数」と表現する。図４に示す数値例によると、例えば契約したライセンスの数が１００以下の企業に対しては、５０ユーザ数を上限として更新モジュールを同時並行してダウンロードしてよいことを示している。本実施の形態では、各購入ライセンス数に対し、同時更新許可数を各購入ライセンス数の最大値（１００，１０００，５０００，１００００）により小さく設定する。

更新ログ情報記憶部２４は、動作の説明と合わせて説明する。更新モジュールレポジトリ２５は、各アプリケーションを最新バージョンとするのに必要な更新モジュールが格納されている。

ソフトウェア管理サーバ１０における各構成要素１１〜１４は、ソフトウェア管理サーバ１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、各記憶手段２１〜２５は、ソフトウェア管理サーバ１０に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。

次に、ユーザ端末３１にインストールされているアプリケーションをバージョンアップするときのユーザ端末３１及びソフトウェア管理サーバ１０で実施される処理について、図５，６に示すフローチャートを用いて説明する。

ユーザ端末３１は、ユーザによる所定の操作を応じて、更新情報の確認要求をソフトウェア管理サーバ１０へ送信する（ステップ１０１）。確認要求には、確認要求対象とするアプリケーションの識別情報（例えば、アプリケーション名）、当該ユーザ端末３１にインストールされている当該アプリケーションのバージョン及び当該アプリケーションのライセンス管理番号が含まれる。

ソフトウェア管理サーバ１０における更新確認処理部１１は、ユーザ端末３１から送信されてきた更新情報の確認要求を受信すると（ステップ１２１）、バージョン管理マスタ２１を参照することで、確認要求に含まれているアプリケーションの最新バージョンを確認する。確認要求に含まれているアプリケーションのバージョンが最新バージョンと一致する場合（ステップ１２２でＹ）、当該ユーザ端末３１にインストールされている当該アプリケーションは、すでに最新バージョンであることからバージョンアップする必要はない。この場合、更新確認処理部１１は、更新情報にバージョンアップは不要という旨の情報を設定して確認要求送信元のユーザ端末３１へ送信する（ステップ１３０）。

一方、確認要求に含まれているアプリケーションのバージョンが最新バージョンでない場合（ステップ１２２でＮ）、更新確認処理部１１は、バージョンアップが必要と判断し、上限数決定部１２に処理を移行する。

なお、以降の説明では、ユーザ端末３１から取得した確認要求には、アプリケーション名として“アプリＡ”が、バージョンとして“Ｖ１．０．１３”が、ライセンス管理番号として“ＡＡＡ−０００”が、それぞれ設定されている場合を例にして説明する。バージョン管理マスタ２１の設定例を参照すると、ユーザのユーザ端末３１には、最新バージョン“Ｖ１．０．１９”のアプリケーション“アプリＡ“がまだインストールされていないことがわかる。

この場合、上限数決定部１２は、ライセンス情報マスタ２２を参照して、確認要求を発信したユーザが所属する企業のライセンス数を次のようにして取得する（ステップ１２３）。すなわち、確認要求に含まれているライセンス管理番号をライセンス情報マスタ２２と照合することで、確認要求元のユーザが所属する企業を特定する。図３に示すライセンス情報の設定例によると、ライセンス管理番号“ＡＡＡ−０００”が付与されたユーザは、“Ｘ会社”に所属していることがわかる。これにより、上限数決定部１２は、ライセンス情報マスタ２２に登録されている、Ｘ会社のライセンス数を積算して、Ｘ会社が契約しているライセンス数を取得する。

続いて、上限数決定部１２は、上限数マスタ２３を参照して、上限数を決定する（ステップ１２４）。図３に示す上限数マスタ２３の設定例によると、“Ｘ会社”のライセンス数が例えば４０だとすると、Ｘ会社の同時更新許可数は５０なので、上限数決定部１２は、同時更新許可数５０をそのままＸ会社の上限数と決定する。従って、本実施の形態の場合、上限数マスタ２３に設定されている「同時更新許可数」と「上限数」は同義である。

続いて、判定部１３は、更新ログ情報記憶部２４を参照することで、現時点のダウンロードの実施状況を取得する（ステップ１２５）。

図７は、本実施の形態における更新ログ情報記憶部２４に記憶されて更新ログ情報のデータ構成例を示す図である。更新ログ情報は、ダウンロード処理部１４によって逐次登録及び更新される。更新ログ情報は、バージョンアップされている若しくはバージョンアップされたアプリケーションに対応するライセンスＩＤに、ダウンロード対象の当該アプリケーションの更新モジュールのバージョン及び更新状況が対応付けして登録される。なお、ライセンス情報を参照することで、ライセンスＩＤからどの企業と契約し、どのアプリケーションがバージョンアップ対象であるのかを特定できる。更新状況には、当該更新モジュールが現時点でダウンロード中である場合には“取得中”が設定される。そして、ダウンロードが終了すると“取得中”が“取得済”に更新される。なお、更新ログ情報記憶部２４をログとして機能させるために、ダウンロードの実行日時等の情報を付加してもよいが、本実施の形態では、説明に用いない項目は省略している。

なお、本実施の形態では、更新ログ情報に更新状況という項目を設けて、ダウンロードが終了したときでもレコードを削除しないようにして、更新ログ情報記憶部２４にログとしての機能を持たせた。ただ、更新状況という項目を設けずに、更新ログ情報記憶部２４には、現在ダウンロード中の更新モジュールのみが記録され管理されるように構成してもよい。

判定部１３は、更新ログ情報のライセンスＩＤとライセンス情報を参照し、現在ダウンロード中のＸ会社のユーザの数を求める。図３に示すライセンス情報と図７に示す更新ログ情報の設定例によると、ライセンスＩＤ“Ａ１１１”が付与されたＸ会社のユーザが現在ダウンロード中であることがわかる。判定部１３は、このようにしてＸ会社のダウンロード中のユーザ数を現時点のダウンロードの実施状況として求める。この求めたダウンロード中のユーザ数が、ステップ１２４で決定した上限数に達している場合、これ以上ダウンロードの実行開始を許可すると、Ｘ会社における企業システム３０のネットワーク負荷が増大し、スループットが低下すると判断する。つまり、判定部１３は、ネットワーク負荷を考慮すると、これ以上、ダウンロードを同時並行してさせるべきでないと判断する。この場合（ステップ１２６でＮ）、更新確認処理部１１は、更新情報にバージョンアップは必要であるものの現時点でのダウンロードは不可という旨の情報を設定して確認要求送信元のユーザ端末３１へ送信する（ステップ１３１）。この場合に送信する更新情報は、アプリケーションの更新禁止指示に相当する。

一方、現在ダウンロード中のユーザ数が、ステップ１２４で決定した上限数に満たないる場合、判定部１３は、ネットワーク負荷の観点からしてダウンロードが可能と判断する。この場合（ステップ１２６でＹ）、更新確認処理部１１は、更新情報にバージョンアップは必要であり、かつダウンロードを許可するために現在ダウンロードは可能という旨の情報を設定して確認要求送信元のユーザ端末３１へ送信する（ステップ１２７）。この場合に送信する更新情報は、アプリケーションの更新指示に相当する。

なお、図６に示すフローチャートでは、更新情報の送信後、ユーザ端末３１からのダウンロード要求が送信されてくるのを待機し、そして受信することになるが（ステップ１２８）、処理をいったん終了させて、ダウンロード要求を受信したときの処理を別途開始するようにしてもよい。

更新情報の確認要求を送信したユーザ端末３１が、ソフトウェア管理サーバ１０から送信されてきた更新情報を受信すると（ステップ１０２）、更新情報の設定内容を確認する。

更新情報にバージョンアップは不要という旨の情報が設定されている場合（ステップ１０３でＹ）、既に最新バージョンのアプリケーションがインストールされているので、バージョンアップを行う必要はなく、処理を終了させる。
更新情報にバージョンアップは必要であるものの現時点でのダウンロードは不可という旨の情報が設定されている場合（ステップ１０３でＮ、ステップ１０４でＮ）、現時点での更新モジュールのダウンロードは禁止されているので、バージョンアップをすることなく、処理を終了させる。この場合、バージョンアップをするためには、しばらく時間が経過してから処理を再度実行することになる。

更新情報にバージョンアップは必要であり、現在ダウンロードは可能という旨の情報が設定されている場合（ステップ１０４でＹ）、ユーザ端末３１は、ユーザによる所定の操作に応じてダウンロード要求をソフトウェア管理サーバ１０へ送信する（ステップ１０５）。ダウンロード要求には、バージョンアップ対象とするアプリケーションの識別情報（例えば、アプリケーション名）及び当該アプリケーションのライセンス管理番号が含まれる。

ソフトウェア管理サーバ１０におけるダウンロード処理部１４は、ユーザ端末３１から送信されてきたダウンロード要求を受信すると（ステップ１２８）、ダウンロード要求に含まれているアプリケーション名に対応する更新モジュールを更新モジュールレポジトリ２５から読み出し、ダウンロード要求元のユーザ端末３１へ送信する（ステップ１２９）。

なお、バージョンアップは必要であるものの現時点でのダウンロードは不可という旨の情報が設定されている更新情報を受け取ったユーザは、アプリケーションのバージョンアップを単に禁止が指示されているだけである。従って、ダウンロードが可能の場合と同様にダウンロード要求を送信することは可能であるかもしれない。そこで、ソフトウェア管理サーバ１０では、ダウンロード不可と判定したユーザのライセンス管理番号又はライセンスＩＤのリストを一時保持しておき、ダウンロード要求を受信したときにダウンロード要求に含まれているライセンス管理番号を一時保持して置いたリストと照合し、リストに合致するライセンス管理番号が存在する場合には、そのダウンロード要求には応じないようにしてもよい。この場合、応じない旨を返信するようにしてもよい。

ユーザ端末３１は、ダウンロード要求に応じてソフトウェア管理サーバ１０からダウンロードされてきた更新モジュールを取得すると（ステップ１０６）、ユーザによる所定の操作手続きに従ってバージョンアップを実行する（ステップ１０７）。そして、バージョンアップに成功すると、ユーザ端末３１は、その更新モジュールのバージョン、通常であれば最新バージョンであるが、そのバージョンによって内部で保持管理しているアプリケーションのバージョン情報を更新する（ステップ１０８）。

以上説明したように、本実施の形態によれば、上限数情報を設け、この上限数情報に設定されている同時更新許可数（つまり、上限数）に従って同時並行して実行可能なダウンロードの数を企業毎に制限できるようにした。特に、契約したライセンス数が膨大であることから膨大な数のユーザによってダウンロードが同時並行して実施されると、他に支障を来すほどネットワーク負荷が増大してしまう可能性があるので、本実施の形態では、契約したライセンス数より小さい数を同時更新許可数に設定しておけば、同時並行して実施なダウンロード数を制限することができ、ネットワーク負荷の増大を回避することが可能となる。

なお、本実施の形態では、更新情報の確認要求に応じて要求元の企業が契約しているライセンス数を積算し、その積算したライセンス数に基づき同時更新許可数を求めるようにした。本実施の形態では、ライセンス情報を全企業に共通して設けているが、例えば、企業毎に同時更新許可数を設定してもよい。この場合、更新情報の確認要求に応じて要求元の企業を特定することで同時更新許可数を決定する。例えば、企業システム３０のネットワーク性能を考慮した数を同時更新許可数に設定しておけば、企業毎にネットワーク負荷の増大をより効果的に解消することが可能となる。

また、本実施の形態においては、ソフトウェア管理サーバ１０は、ダウンロードに関する要求の一例である更新情報の確認要求に応じて更新モジュールのダウンロードの可否をユーザ端末３１へ返し、ダウンロードが可能の場合にユーザ端末３１から別途送信されてくるダウンロードの要求に対応して更新モジュールをダウンロードするようにした。ただ、ダウンロードするまでの手順はこれに限る必要はなく、例えば、ダウンロードに関する要求として更新情報の確認要求ではなく、ユーザ端末３１から送信されてくるダウンロードの要求に応じて更新モジュールのダウンロードの可否を判断し、ダウンロードが可の場合に更新モジュールをダウンロードするようにしてもよい。つまり、この場合は、更新モジュールをダウンロードする手順として更新情報の確認要求の送信が不要となる。

また、本実施の形態においては、アプリケーションはユーザ端末３１にすでにインストールされており、このアプリケーションのバージョンアップのために更新モジュールをダウンロードする場合について説明した。ただ、アプリケーションがまだインストールされていないユーザ端末３１に対してアプリケーションを新規にダウンロードする場合にも適用することは可能である。この場合、例えば、更新情報の確認要求に含めるべきアプリケーションのバージョンを空白にするなどして、新規インストール目的の確認要求であることをソフトウェア管理サーバ１０に知らせるようにしてもよい。

実施の形態２．
図８は、本実施の形態においてソフトウェアを提供する側と利用する側を含むネットワークシステムの構成図であり、実施の形態１において用いた図１に対応する図である。本実施の形態におけるネットワークシステムは、実施の形態１の構成に、転送速度測定部１５及び転送速度情報記憶部２６を追加した構成を有している。転送速度測定部１５は、ダウンロード処理部１４がソフトウェアをダウンロードしたときの転送速度を測定し、測定した転送速度を含む転送速度情報を転送速度情報記憶部２６に記録する。転送速度情報記憶部２６に記録される転送速度情報には、転送速度の測定日時に転送速度が対応付けして設定される。転送速度測定部１５は、ソフトウェア管理サーバ１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、転送速度情報記憶部２６は、ソフトウェア管理サーバ１０に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

以下、本実施の形態における動作について説明するが、基本的には図５及び図６に示すフローチャートを用いて説明した実施の形態１と同じでよい。本実施の形態は、転送速度を用いることに伴い処理が若干追加される。

まず、転送速度測定部１５は、転送速度を測定し、転送速度情報を生成して転送速度情報記憶部２６に記録する。この処理は、例えば、定周期的に実施すればよい。

実施の形態１において説明したように、ソフトウェア管理サーバ１０において、ユーザ端末３１から更新情報の確認要求が送られてくると、上限数決定部１２は、ステップ１２４においてライセンス情報及び上限数情報を参照して当該企業に対する同時更新許可数（つまり、上限数）を決定する。本実施の形態では、この上限数を決定する際に転送速度を参照することになる。

転送速度は、ネットワークのスループットを推測可能な指標の一つであるが、この転送速度が低下するということは、ネットワーク負荷が増大し、スループットが低下していることを示している。従って、上限数決定部１２は、転送速度情報記憶部２６に記録されている転送速度情報を解析し、転送速度の遷移を得る。この転送速度の遷移に所定の下降傾向が現れると、上限数決定部１２は、前述したように上限数情報から抽出して得た同時更新許可数を下方修正する。下方修正の程度は、所定の規則に従って決めればよい。例えば、転送速度の下降の程度に応じて上限数の数を減少させる、換言すると上限数の減少幅を調整すればよい。実施の形態１では、上限数情報から抽出して得た同時更新許可数をそのまま上限数として用いたが、本実施の形態では、以上説明したように上限数情報から抽出して得た同時更新許可数を下方修正して上限数を決定する。

なお、下方修正した上限数を保持しておき、これ以降に更新情報の確認要求を発したユーザに対しては、上限数情報に設定されている同時更新許可数ではなく、保持した上限数を用いて上限数を決定するようにしてもよい。

同時更新許可数を下方修正して上限数を決定することで、ステップ１２６においてダウンロードは可能と判定されにくくなり、ダウンロードを新規に始められるユーザ数を減らすことが可能となる。

実施の形態１では、上限数情報から抽出して得た同時更新許可数をそのまま上限数として用いたが、本実施の形態では、ネットワーク負荷が増大傾向にある場合、上限数を下方修正することでこれ以上のネットワーク負荷の増大を抑止することができる。その他の処理は、実施の形態１と同じでよいので説明を省略する。

なお、上記説明では、ネットワーク負荷の増大を抑止する場合について説明したが、例えば、転送速度の遷移に所定の上昇傾向が現れるとネットワーク負荷が減少傾向にあると考えられることから、上限数決定部１２は、上限数を増加させるようにしてもよい。これにより、下方修正した上限数を元に戻すことも可能となる。

以上説明したように、本実施の形態によれば、転送速度という指標を用いて実際のネットワーク負荷の状況を監視することによって上限数を現実に適合した値に補正することができる。

２ インターネット、１０ ソフトウェア管理サーバ、１１ 更新確認処理部、１２ 上限数決定部、１３ 判定部、１４ ダウンロード処理部、１５ 転送速度測定部、２１ バージョン管理マスタ、２２ ライセンス情報マスタ、２３ 上限数マスタ、２４ 更新ログ情報記憶部、２５ 更新モジュールレポジトリ、２６ 転送速度情報記憶部、３０ 企業システム、３１ ユーザ端末、３２ ルータ。

Claims (8)

1. 複数のユーザがソフトウェアを利用する利用先のユーザからネットワークを介したダウンロードに関する要求を受けた場合に、当該利用先において同時にダウンロードが可能なユーザの上限数を決定する決定手段と、
   当該利用先におけるダウンロード中のユーザ数が、前記決定手段が決定した上限数に満たない場合に前記要求をしたユーザに対してソフトウェアのダウンロードを許可する許可手段と、
   を有することを特徴とするソフトウェア提供装置。
2. 前記決定手段は、ソフトウェアのライセンス契約をユーザ毎にすることで当該ユーザが当該ソフトウェアを使用できる場合、前記利用先が契約しているソフトウェアのライセンス数に応じて前記上限数を決定することを特徴とする請求項１に記載のソフトウェア提供装置。
3. 前記決定手段は、前記利用先に対する前記上限数を、当該利用先が契約しているソフトウェアのライセンス数より小さく設定することを特徴とする請求項２に記載のソフトウェア提供装置。
4. 前記許可手段が許可したユーザに対してソフトウェアをダウンロードするダウンロード手段と、
   前記ダウンロード手段がソフトウェアをダウンロードしたときの転送速度を記録する記録手段と、
   を有し、
   前記決定手段は、前記記録手段が記録した転送速度を参照して前記利用先に対する上限数を決定することを特徴とする請求項１に記載のソフトウェア提供装置。
5. 前記決定手段は、転送速度が下降傾向にある場合、前記上限数を減少させることを特徴とする請求項４に記載のソフトウェア提供装置。
6. 前記決定手段は、転送速度に上昇傾向にある場合、前記ソフトウェアの上限数を増加させることを特徴とする請求項４に記載のソフトウェア提供装置。
7. 前記ソフトウェアは、バージョンアップ用の更新モジュールであることを特徴とする請求項１乃至６のいずれか１項に記載のソフトウェア提供装置。
8. コンピュータを、
   複数のユーザがソフトウェアを利用する利用先のユーザからネットワークを介したダウンロードに関する要求を受けた場合に、当該利用先において同時にダウンロードが可能なユーザの上限数を決定する決定手段、
   当該利用先におけるダウンロード中のユーザ数が、前記決定手段が決定した上限数に満たない場合に前記要求をしたユーザに対してソフトウェアのダウンロードを許可する許可手段、
   として機能させるためのプログラム。
   

Images