"インターネットに接続される複数の仮想サーバ、各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、各仮想サーバにはそれぞれのユーザIDが割り当てられること、複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システム。使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間の使用状況を表わす数値データ現使用状況データを取得して購買期待度算出手段に供給する、請求項1に記載のトライアル環境システム。使用状況モニターは、現使用状況データを定期的に取得する、請求項2に記載のトライアル環境システム。使用状況モニターが取得する現使用状況データの取得間隔は一秒から三日の範囲内である、請求項3に記載のトライアル環境システム。購買期待度算出手段は、現使用状況データにより購買期待度を算出する、請求項2から4のいずれか一項に記載のトライアル環境システム。購買期待度算出手段は、過去の複数の区間での使用状況データ過去使用状況履歴データを蓄積する記憶手段を含み、過去使用状況履歴データと現使用状況データとから購買期待度を算出する、請求項2から4のいずれか一項に記載のトライアル環境システム。使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するAアクセス回数、B使用時間、C使用段階、およびDこれらの組み合わせからなる群のなかから選択されたものを取得する、請求項1に記載のトライアル環境システム。使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するAアクセス回数、B使用時間、C使用段階のうち2以上からなるもの複数種類の現使用状況データを取得し、購買期待度算出手段は、複数種類の現使用状況データを演算して1つの数値データに変換する手段を含む、請求項1に記載のトライアル環境システム。ユーザID毎の購買重みデータを蓄積した購買重みデータベースをさらに備え、購買期待度算出手段は、モニターしたユーザ毎の使用状況とユーザ毎の購買重みデータとに基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する、請求項1に記載のトライアル環境システム。仮想リソース動的割り当て手段は、ユーザID毎に割り当てられる仮想リソースの容量がアプリケーションソフトに関連付けた下限を下回らず、かつアプリケーションソフトに関連付けた上限を上回らないように確保する仮想リソースソース確保手段を含む、請求項1に記載のトライアル環境システム。請求項1から10のいずれか一項に記載のトライアル環境システムと、使用状況モニターのモニター結果および/または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業IDが入力された端末営業端末に通知する通知手段と、を備える営業支援システム。この種のトライアル環境システムにおいては、物理サーバから利用できるリソースの容量に制約が大きいことが一般的であり、そのため、全ユーザに均等な仮想リソースを割り当てる戦略は平等である反面、個々のユーザにおけるアプリケーションソフトウェアの購入意欲をそぐ可能性がある。また、アプリケーションソフトウェアのプロバイダには、均等割り当てはビジネス面で不利であると考えられる。そこで、本発明は、アプリケーションソフトウェアのトライアル環境における限られたリソースの制約の中で、個々のユーザに適切なリソースコンピュータ資源が割り当てられるようにしたトライアル環境システムを提供することを目的とする。また、本発明はこの種のトライアル環境システムを利用した営業支援システムを提供することを目的とする。本発明の一側面によれば、インターネットに接続される複数の仮想サーバ、各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、各仮想サーバにはそれぞれのユーザIDが割り当てられること、複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、および物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システムが提供される。この構成によれば、低コストでトライアル環境システムを提供することができる。同時に、購買意欲のあるユーザは快適な動作環境でアプリケーションソフトウェアを使用できる。本発明の別側面によれば、インターネットに接続される複数の仮想サーバ、各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、各仮想サーバにはそれぞれのユーザIDが割り当てられること、複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、および使用状況モニターのモニター結果および/または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業IDが入力された端末営業端末に通知する通知手段、を備える営業支援システムが提供される。この構成によれば、過剰なリソースコンピュータ資源を費やすことなく、トライアル中のユーザに対して適切な営業活動が可能になり、低コストの営業支援システムを提供できる。以下、図面を参照して本発明をさらに詳細に説明する。図面に示す実施形態のシステムは、仮想サーバに置かれたアプリケーションソフトウェアを無償または有償のトライアル期間においてユーザ見込み客に開放して試用できるようにしたトライアル環境システムを備えた営業支援システムである。図1から図6を参照すると、営業支援システムは顧客情報データベースを初めとして各種営業データベースを備えており、営業担当者は営業端末から営業IDを指定することによりインターネットを通じて、営業データベースにアクセスすることができ、ユーザアプリケーションソフトウェアの試用者に対して営業活動を行なうことが容易になっている。一方、ユーザはユーザ端末からユーザIDを指定することにより、インターネットを通じて、仮想サーバのアプリケーションソフトウェアにアクセスして試用することができるようになっている。図1に本発明の営業支援システム10の概念図を示す。なお、図1では、インターネット、物理サーバ、仮想サーバなどはユーザ、営業担当者には透明であるところから、図示を省略し、本発明の特徴である動的なトライアル環境システムを強調した記載になっている。図1において、ユーザが自己のIDに割り当てられた試用対象であるアプリケーションソフトウェアにアクセスして試用するときの環境をトライアル環境80として描いている。アプリケーションソフトウェア38は仮想サーバ36に置かれているため、本発明では、仮想サーバ36のリソース容量を調整することで、通信速度、アプリケーションソフトウェアの動作速度などが変化し、トライアル環境の快適さをユーザに提供することができる。ここに、仮想サーバは、限られたリソース容量をもつ物理サーバ30に基づいて構築されるものであるため、複数のユーザによる複数の仮想サーバの使用環境下で、各仮想サーバに割り当てられる平均的割当リソース量には大きな制約がある。本発明では、アプリケーションソフトウェアの試用に積極的なユーザに対して、割り当てリソース量を増やしてトライアル環境80の快適さを提供している。図1に破線で示すように拡大したトライアル環境は割り当てリソース量が増大したことを示唆している。なお、実際にはトライアル環境80はユーザごとの試用環境であり、ユーザの数に相当するトライアル環境が存在するが、図1では図示の便宜上、1つのトライアル環境80のブロックで代表させている。図1において、トライアル環境利用情報82はこのようなトライアル環境80におけるアプリケーションソフトウェア38の利用情報使用状況を表わしており、取得されたトライアル環境利用情報82はリソース割り当て量決定システム84に渡される。リソース割り当て量決定システム84はトライアル環境利用情報82アプリケーションソフトの使用状況に基づいてそのユーザの購買期待度を算出し、算出した購買期待度に応じてそのユーザの使用する仮想サーバ36に割り当てるリソース量を決定する。リソース割り当て量決定システム84の決定結果リソース量は仮想サーバマネジメントシステム86に渡される。仮想サーバマネジメントシステム86は決定したリソース量に基づいて当該仮想サーバ36に各リソース、具体的には、図5に例示するように仮想サーバ用CPU、仮想サーバ用メモリ、仮想サーバ用ネットワーク帯域および仮想サーバ用のストレージを割り当て実行する。仮想サーバマネジメントシステム86による仮想リソースの割り当て結果に応じて、トライアル環境80で使用可能なリソース量が動的に変わる。図2は図1と同様の図であるが、ユーザ毎のトライアル環境の使用状況などを営業担当者に通知する機能に焦点を当てて描いたものである。すなわち、トライアル環境の使用状況は営業端末14を通じて営業担当者に通知することができる。たとえば、営業端末14にユーザの使用履歴データを表示することができる。トライアル環境の使用状況などを表わす情報として、トライアル環境利用情報82に代え、あるいはこれと組み合わせてユーザの購入期待度リソース割り当て量決定システムの中間演算結果を営業端末14から見ることができるようにしてもよい。あるいは、購入期待度の高い若しくは使用量の多いユーザをスクリーニングして表示する機能を持たせてもよい。物理サーバ30から仮想サーバ36を構築するシステム図3自体は公知である。図3において、マネージメントシステム42は仮想サーバ36の作成、削除、起動、リソース割り当てを実行する制御システムである。ハイパーバイザー32を物理サーバ30にインストールすることによりマネージメントシステム42はリソースプール34を通じて仮想サーバ36に関するオペレーション作成、削除、起動、リソース割り当てなどが可能になる。図4は図3と同様の図であるが、公知のように、マネージメントシステム42のオペレーションの下に、仮想サーバ36の複製が行われることを示したものである。なお、マネージメントシステム42は図1の仮想サーバマネジメントシステム86の具体例である。図5はこの種のマネージメントシステム42のサポート下で、本発明により提供される動的トライアル環境システムを、リソース割り当て決定システム84に焦点を当てて示したものである。なお、マネージメントシステム自体はバックグランドサポートとして、図5には図示していない。リソース割り当て量決定システム84は各仮想サーバ36をモニタリングして、アプリケーションソフトウェアに対する各ユーザ仮想サーバ使用者の使用状況を取得し、その結果に基づいて各仮想サーバに対するリソース割当量を決定する。マネージメントシステム42は決定した割当量を受け、リソースプール34を介して仮想サーバ36の各リソース割り当て域を調整する。図5において、リソース割当量決定システム84に吹き出しをつけ、吹き出し内に、同システム84の動作フローを記載している。動作フロー自体の記載は明白であるのでこれ以上の説明は省略する。なお、リソース割当量決定システム84の動作、機能は、動作フローに記載した動作、機能には限定されず、本発明の範囲内で種々の変更が可能である。図6は実施形態に係る営業支援システム全体のハード構成の概要を示すブロック図である。インターネット20には複数のユーザ端末12が接続可能であり、1以上の営業端末14が接続可能である。さらに、インターネット20にはネットワーク機器ファイアウォール、ロードバランサ、LANスイッチ等を介して営業支援システムの主要部を構成するLANが接続される。LANのバスには、AP物理サーバ30が接続され、AP物理サーバ30に基づいて構築された複数の仮想サーバ36が接続される。仮想サーバ36にはユーザ端末12からユーザIDによりアクセスして使用可能なアプリケーションソフトウェア38が置かれる。さらに、VS物理サーバ40および関連するVSマネージメントシステム42がLANバスに接続される。また、LANバスにはPE物理サーバ50を通じて動的トライアル制御システム52が接続される。動的トライアル制御システム52は使用状況モニター54、購買期待度算出部56、VSリソース割り当て部58を有する。また、LANバスには営業サーバ60および関連する営業データベース70が接続される。なお、図6において、物理サーバ30、46、50、60をそれぞれ1つのブロックで示しているが実際の物理サーバの個数を反映したものではない。また、所望であれば、たとえば、PE物理サーバ50と営業サーバ60の機能を併合した1以上の物理サーバで、サーバ50と60をインプリメントすることなどが可能である。したがって、各ブロックは機能に着目してブロック表示したものであると解釈されたい。さらに、単一のLAN内部に各要素を示しているが、これには限らず、所望であれば、各要素はインターネット上に分散されて存在してもよい。また、ユーザ端末12は、ユーザがIDを通じてアプリケーションソフトウェアにアクセスするのに使用される端末であることを意味しており、ユーザが所有する端末である必要はない。営業端末14についても同様であり、営業端末14は、営業担当者が営業IDを通じて営業支援システム本体図6のLANのうち営業IDにアクセス権が与えられている部分、典型的には営業サーバ60にアクセスするのに使用される端末であることを意味する。なお、端末12、14の種類、仕様は特に問わない。ウェブブラウザを備えたパーソナルコンピュータ、あるいは携帯情報端末であり得る。以上のように構成した、トライアル環境システム、営業支援システム10の動作について以下、フローチャートを参照して説明する。図7はトライアル環境システムの動作を示すフローチャートである。トライアル環境システムは、動的トライアル制御システム52の制御の下に、PE物理サーバ50を通じて、使用状況モニタリング100を実行し、購買期待度算出処理200を実行し、仮想リソース割当処理300を実行する。<使用状況モニタリング100>使用状況モニタリング100はユーザのアプリケーションソフトウェアに対する現在の使用状況を取得する処理である。この種のモニタリングは定期的周期的あるいはイベントに応じて実行することができる。定期的に使用状況モニタリングを行なう場合に、モニタリングのサンプリングレート現使用状況データの取得周期は、比較的低速であることが好適であり、具体的には、現使用状況データの取得間隔は一秒から三日の範囲内さらに好ましくは30分から一日の範囲内であってよい。定期型の使用状況モニタリング100を実現するための、複数種類の実施形態を図8から図13に示す。図8は、アプリケーションソフトウェア38へのアクセス回数を現在現区間の使用状況データとする形態100Aである。まず、PE物理サーバ50はAP物理サーバ30に問い合わせて、各ユーザIDについて現区間の通信記録を取得する8-1。ここに現区間は、現時点から現使用状況データの取得間隔の長さだけ過去までの区間で定義してよいたとえば、今から30分前までの区間。次に、各ユーザIDについて、取得した現区間の通信記録から現区間におけるアクセス回数を取得する8-2。次に、各ユーザIDについて、取得した現区間におけるアクセス回数を現在の使用状況データとして決定する8-3。最後に、各ユーザIDについて、決定した使用状況データを使用履歴スタックにセットする8-4。ここに使用履歴スタックはユーザID毎に用意されており、図9に100mで示すように構成される。8-3で決定した使用状況データは、この使用履歴スタック100mの現区間のエリアに置かれる。すなわち、8-4では、使用履歴スタックのトップに新しい現区間のエリアを定義しその際、スタック上のいままでの現区間は1つ前に再定義され、1つ前の区間は2つ前の区間に再定義され、以下、同様である、そこに決定した使用状況データをセットする。なお、8-2におけるアクセス回数の取得算出は、1ログインのカウント、2ログオフのカウント、または、3ログイン及びログオフのカウントにより、容易にインプリメントできる。所望であれば、ログイン、ログオフ以外にトランザクションの回数もカウントして、アクセス回数を算出するようにしてもよい。その場合において、ログインおよび/またはログオフに係る計数値は第一種のアクセス回数第一種の使用状況データとして定義できるとして取得し、トランザクションに係る計数値は第二種のアクセス回数第二種の使用状況データとして取得し、後述する購買期待度を算出する際にそれぞれ、引数として使用するようにしてもよい。あるいは、使用状況モニタリングのなか8-2で、第一種のアクセス回数と第二種のアクセス回数の線形結合により統合したアクセス回数を取得するようにしてもよい。図10は、アプリケーションソフトウェア38への現区間における使用時間を現在の使用状況データとする形態100Bである10-2、10-3参照。他のステップは形態100Aと同様である。図11は、形態100Aと形態100Bを組み合わせた形態100Cである。すなわち、各ユーザIDについて現区間におけるアクセス回数と使用時間を取得し11-2、取得したアクセス回数と使用時間とから使用状況データを決定する11-3。たとえば、アクセス回数Aと使用時間Tとの線形結合を使用状況データとして求めることができる。他は形態100Aと同様である。図12は、現区間におけるアプリケーションソフトウェアの使用段階たとえば、ゲームソフトウェアにおけるゲームステージに基づいて現区間の使用状況データを決定する形態100Dである12-2、12-3参照。したがって、アプリケーションソフトウェアがその性質上、使用段階を持つことが前提になっている。この形態100Dはアプリケーションソフトウェアの属性に依存する点で汎用性は低下するが、かかる属性をもつアプリケーションソフトウェアに対する使用状況を決定するのには有効であると考えられる。これに対して、形態100Aから100Cで抽出しているアクセス回数と使用時間は原理的にアプリケーションソフトウェアの種類には依存しないデータであることから任意のアプリケーションソフトウェアに対して適用でき、汎用性が高い。図13に示す形態100Eは、各ユーザIDについて現区間におけるアクセス回数、使用時間および使用段階のうち2以上の要素を取得し13-2、各ユーザIDについて取得した2以上の要素を合成たとえば、線形結合して1つの数値データとしての使用状況データを決定する13-3ものである。形態100Eの一変形形態において、使用状況モニターとしては、各ユーザIDについて取得した2以上の要素を合成することなく第1種、第2種などの使用状況データとして一般的に拡張すると、多変数の使用状況データとしてそのまま残しなお使用履歴スタックはこれに対応する構成とする、購買期待度算出処理200側で、購買期待度算出手段は、複数種類の使用状況データを演算して1つの数値データ統合した使用状況データに変換するようにしてもよい。要するに、各種使用状況データの関数として購買期待度が与えられるような場合、使用状況モニターが生成した各種使用状況データを引数として購買期待度を算出する機能を購買期待度算出処理に持たせることは合理的である。図14は仮想サーバにあるアプリケーションソフトウェアに関連するイベントが発生した際に14-1、使用状況モニタリングを実施する形態100Fである。したがって、この形態100Fはモニタリングの実施タイミングについて非周期型である。なお、図14に示す形態100Fの場合、使用履歴スタックとしては図9で説明したものを使用し、使用履歴スタックに新しい現区間のエリアが作成されるのは、一定間隔としている図14には図示せず。これにより、発生するイベントの非同期性との調整を行なっている。すなわち、14-3で発生イベントから関連する使用状況データ要素たとえばアクセス発生を求めた後、14-4でイベントに係るユーザIDの使用履歴スタック100mから現区間にある使用状況データを取り込み、それを14-3で求めた使用状況データ要素を用いて更新する。その後、更新結果を使用履歴スタックの現区間のエリアに戻す処理を行なう14-5。なお14-2では発生したイベントに関与したユーザIDを決定している。なお、形態100Fにおいて、現区間の使用状況データは、形態100Aで述べたようなアクセス回数、形態100Bで述べたような使用時間、形態100Cで述べたようなアクセス回数と使用時間の合成関数、形態100Dで述べたような使用段階ゲームステージ、あるいは形態100Dで述べたような2以上の要素の合成関数を用いて定義してよく、あるいは段落0030で述べたような多変数の使用状況データによって定義してもよい。<購買期待度算出200>購買期待度算出処理200は、使用状況モニタリング100の結果たとえば、使用履歴スタック100mの内容を利用してユーザの購買期待度を算出するものである。本処理200は使用状況データが更新される都度、あるいは非同期型使用状況モニタリング図14参照の場合は、現区間の使用状況データが確定する都度、実行すればよい。この場合、使用状況モニタリングの実行周期現区間の使用状況データ更新周期と購買期待度算出処理の実行周期購買期待度の更新周期は同一になる。所望であれば、同一でない形態も容易に実施できる。たとえば、アプリケーションソフトウェアが一般業務用ソフトウェアである場合には、休日についてあるいは午後8時から午前8時までのような非営業時間帯は、その使用状況のモニタリング結果が購買期待度と相関性をもたないと予想される。したがって、このような場合、休日等の非営業時間帯は使用状況モニタリング自体を実施しないか、使用状況のモニタリングは実施してもそのモニタリング結果は購買期待度の算出から除外することが多くの場合、好ましい。この種の時間帯における使用状況データの反映を禁止または弱める手法としては、使用状況モニタリングを一時的に中断する方法と、購買期待度算出処理側で、この種の時間帯における使用状況データのモニタリング結果を無視するか低く見積もる方法が考えられる。また、好ましい方法としてモニタリング結果の時系列に対して移動平均などの統計処理を行うことが考えられる。一般にユーザは、購買意欲は変わらないまま、都合によりアプリケーションソフトウェアの使用を一時的に中断することが日常的である。一方で、使用状況モニタリングを一日よりも十分に短い周期たとえば30分毎でモニタリングする場合、時間区間ごとの変動が大きいことや、局部的にある時間区間では使用していない状況がありえる。一方で、購買意欲を急になくしてアプリケーソンソフトウェアの使用を止めることもあり得る。ある短い区間の間、アプリケーションソフトウェアを使用していないという事実だけでは、その不使用の理由購買意欲を急に失ったからなのか、それとも都合により中断しているだけなのかを知るすべがない。このような点にも配慮した適切な購買期待度の推定算出が望ましい。1つの有効な算出手法は、比較的長い区間たとえば、72時間について使用状況データを集計し、集計結果に基づいてあるいは同様に長い区間ごとに使用状況をモニタリングし、その結果である現区間の使用状況データに基づいて、購買期待度を算出する方法である。購買期待度算出処理200を実現するための、複数種類の実施形態を図15から図21に示す。図15は、現区間の使用状況データを取得し15-1それに基づいて購買期待度を求める15-2ようにした形態200Aである。ステップ15-1で取得する現区間の使用状況データとしては、使用状況モニタリング100によって使用履歴スタック100m図9の現区間にセットされたデータを使用できる。ただし、使用履歴スタック100mの一区間の長さが短い場合たとえば一時間毎の場合には、適当な複数の区間たとえば72時間分に渡って使用状況データを集計し、集計結果を、15-1でいう現区間の使用状況データとすることができる。これは、モニタリングした使用状況データの時系列に対して移動平均をとっていることと均等である。図16に示す形態200Bは、使用履歴データを使用履歴スタックから取得し15-1、履歴重みパターンを読み出し16-2、履歴重みパターンと使用履歴データとを積和演算して購買期待度を算出する16-3。16-2で読み出す履歴重みパターン時間関数の具体例を図17に示す。ここでは、履歴重みパターンは過去に向かって減少する減少関数となっているが、これに限定されるものではない。したがって、ステップ16-3で行なっている処理は使用状況データの時系列に対して重み付け移動平均をとることと均等である。履歴重みパターン関数はたとえば、次のようにして作成することができる。時間帯たとえば、夜間、曜日によって使用期待度が変動するパターンが認められる場合、このような変動を表わす時間関数を第1の関数として用意しておき、それに現時点からの時間差に応じて減少するグローバル減少関数を第2の関数として用意しておき、第1と第2の関数を合成たとえば乗算あるいは加算することによって、履歴重みパターンを作成するようにしてもよい。上記形態200Aと200Bでは、使用履歴スタック100m図9に蓄積した使用履歴データのみから購買期待度を算出した。実施形態によっては、購買期待度の算出に、使用状況データのみならず他の変数を加味することができる。図18に示す形態200Cはその一例であり、顧客情報データベース72にある顧客に割り当てた重みデータ顧客重みデータを他の変数として購買期待度の算出に使用している。すなわち、各ユーザIDについて、顧客情報データベース72からそのユーザIDに係る重みデータWIDを取得し18-2、各ユーザIDについて、使用状況データと顧客重みデータWIDとを用いて、そのユーザの購買期待度IDを演算する18-3。演算式としては、たとえば、重みデータを係数乗数として、購買期待度ID=使用状況データID×顧客重みデータWIDが使用できる18-3。あるいは、重みデータを購買期待度ID=使用状況データID顧客重みデータWIDのように、バイアス変数として使用してもよい。あるいは、右辺に示す2つの式の線形結合式を購買期待度IDとして求めてもよい。すなわち、購買期待度ID=2つの式の線形結合式=a×使用状況データID×顧客重みデータWIDb×顧客重みデータWID顧客情報データベース72の顧客重みデータは、試用アプリケーションソフトウェアの使用状況データとは別に、顧客の購入意欲に相関すると期待されるデータであればよく、たとえば、過去のユーザの同種アプリケーションソフトウェアの購入実績、および/またはインターネット上のフェースブックやツイッタなどにおいて試用アプリケーションソフトウェアに関してユーザが投稿した件数などを反映した値をもたせることができる。図19に示す形態200Dは、移動平均をとる形態200Bと顧客重みデータを顧客期待度に反映させる形態200Cとを組み合わせたものである。すなわち、16-1、16-2、19-3により、使用状況データの時系列に対して重み付け移動平均をとったものをユーザIDの使用状況データIDとし、後は、図18の場合と同様に、使用状況データIDと顧客重みデータWIDとを演算して購買期待度を求めている18-3。図20に示す形態200Eは、図18の形態200C顧客重みデータを参照する形態を変形したもので、顧客重みデータをそのまま使用するのではなく、顧客重みデータWIDの増加関数を決定し20-3、それを購買期待度の算出における重みデータ係数またはバイアスまたはその組み合わせとして使用する20-4ようにしたものである。増加関数としては適当な任意の増加関数が使用でき、たとえば、FUNCWID=WID1、FUNCWID=WIDkただし、kは変数、FUNCWID=k1WIDk2ただし、k1、k2は変数、その他、顧客重みデータWIDの対数関数などが考えられる。図21に示す形態200Fは、図19の形態第1から第3のステップ16-1、16-2および19-3に関してと図20の形態200E第4から第6のステップ18-2、20-3、20-4に関してを組み合わせたものである。すなわち、各ユーザIDについて使用状況の時系列の移動平均を取り、それを改めて使用状況データIDとして、顧客情報データベース72の顧客重みデータWIDの増加関数FUNCを求め、移動平均である使用状況データIDと顧客重みデータの増加関数とを演算して購買期待度IDを算出する。<仮想リソース割当処理300>仮想リソース割当処理300は購買期待度に基づいて仮想サーバ36に割り当てる仮想リソース仮想サーバ用CPU、仮想サーバ用メモリ、帯域に関連する仮想サーバ用ネットワーク、仮想サーバ用ストレージの範囲を決定する処理である。本処理300は購買期待度が更新される都度、実行すればよい。この場合、購買期待度算出の実行周期購買期待度更新周期と仮想リソース割当処理の実行周期仮想リソース域更新周期は同一になる。所望であれば、周期が同一でない形態も可能である。仮想リソース割当処理300の2つの実施形態を図22と図23に示す。図22に示す仮想リソース割当処理300Aにおいて、PE物理サーバ50は、動的トライアル制御システム52の制御の下に、各ユーザIDについて購買期待度IDを取得する22-1。これは購買期待度算出処理200の処理結果を読むことで行なわれる。次に、各購買期待度IDを正規化して割当比IDを求める22-2。次に、各割当比IDについて、各仮想のリソースの容量から、すなわちAP物理サーバ30において利用可能な各物理リソースの容量から、リソースの種類ごとに、該当する仮想サーバ36ユーザIDに係る仮想サーバに割り当てるべきリソース割当サイズIDを決定する22-3。最後に22-4、PE物理サーバ50は処理結果であるリソース割当サイズIDを含む情報をVS物理サーバ40に渡し、VS物理サーバ40はVSマネージメントシステム42の制御の下に、リソース割当サイズIDに基づいた割当オペレーションを、AP物理サーバ30を通じて実施する。図23に示す仮想リソース割当処理の実施形態300Bでは、動的リソース割当の結果によらず、各仮想サーバ36にあるアプリケーションソフトウェア38をユーザがインターネット経由で使用する際に、支障がないように、仮想リソース割当処理300Bで実施される割当リソースサイズの下限と上限をアプリケーションソフトウェア38に関連付けて規制している22-3、23-4。すなわち、下限未満のリソース割当は回避されるので、アプリケーションソフトウェアの使用環境として許容される最低環境以上での使用が保証される。また、上限を超えるリソース割当も回避されるので、限られた物理リソースに対する無駄使いが規制され、アプリケーションソフトウェアの使用環境として許容される最高環境以上での使用が防止される。以上により、アプリケーションソフトウェア38の使用環境を確保しながら、AP物理サーバ36が有する限られた物理リソースを有効利用するツールが実現される。<顧客重みデータ更新>本発明に係るトライアル環境システムは、有限の物理リソースを有する物理サーバ上に展開される複数の仮想サーバにあるアプリケーションを複数のユーザ個々の仮想サーバが割り当てられたユーザがインターネットを通じて試用するものである。本発明は、各仮想サーバに割り当てられるリソースの容量をユーザの使用状況等購買期待度に基づいて動的に調整することを本質としている。このために、購買期待度算出処理200においてはモニタリングによって取得したユーザの使用状況に基づいて購買期待度を算出している。いくつかの実施形態において、ユーザの購買期待度はユーザによるアプリケーションソフトウェアの使用状況のみから算出することができる図15、図16参照。別のいくつかの実施形態において、ユーザの購買期待度は、ユーザによるアプリケーションソフトウェアの使用状況のみならず、当該ユーザに固有の情報顧客重みデータをも参照して算出することができる図18-図21。後者の形態は、顧客重みデータWIDが購買期待度と相関性をもつと期待される限りにおいて有効である。したがって、ユーザにより購買期待度と相関性を持つ行為がなされた場合に、顧客重みデータをその行為に合わせて更新することが望ましい。顧客重みデータの更新処理の一形態を図24に400で示す。この形態400は、アプリケーションソフトウェアの売買契約が成立したか不成立に終わったかによって、顧客重みデータを更新するものである。まず、営業サーバ60は、ポインタPで最初のユーザIDを指定し24-1、そのユーザIDについて契約が成立したかどうか契約成立フラグPが立っているかどうかをみる24-2。契約が成立していれば、そのユーザIDの顧客重みデータIDをインクリメントする24-3。これに関連し、購買期待度算出処理において顧客重みデータを乗数たとえば、使用状況データに対する乗数として使用する形態たとえば、図18の形態の場合には、顧客重みデータIDに上限をつけることが望ましい。なお、購買期待度算出処理において顧客重みデータをバイアスたとえば、使用状況データに対する加減数として使用する形態の場合には、原則、上限のクリップ処理は不要である。次に契約成立フラグPをリセットし24-4、次のパスの判定ステップ24-2で再びYESが返されないようにする。判定ステップ24-2でNOのときは、契約の不成立が確定したかどうか契約不成立フラグPが立っているかどうかをみる24-5。契約不成立であれば、そのユーザIDの顧客重みデータIDをデクリメントする24-4。これに関連し、購買期待度算出処理において顧客重みデータを乗数たとえば、使用状況データに対する乗数として使用する形態たとえば、図18の形態の場合には、顧客重みデータIDに下限をつけることが望ましい。なお、顧客重みデータをバイアスたとえば、使用状況データに対する加減数として使用する形態の場合には、原則、下限のクリップ処理は不要である。24-8でポインタPの指すユーザIDの次のユーザIDがなければ処理を終了し、あれば、Pで次のユーザIDを指定して24-9、契約成立判定ステップ24-2に戻る。顧客重みデータ更新処理の別形態では、インターネット上のアプリケーションソフトウェアに関する掲載件数をユーザに関連付けて収集し、掲載件数の多いユーザについてそのユーザユーザIDに係る顧客重みデータを掲載件数に応じてインクリメントする。なお、この顧客重みデータは第2種の顧客重みデータとして記憶、管理するのが好ましい。この場合、図24に関して述べた、顧客の購買実績に係る顧客重みデータは第1種の顧客重みデータとして記憶、管理される。購買期待度を算出するに際して、第1種と第2種の顧客重みデータを合成して顧客重みデータWIDとして使用することができる。その他、複数種類の顧客重みデータを用意してもよい。別の実施形態において、第1種の顧客重みデータを図20などでの顧客重みデータWIDとして使用し、第2種、第3種などの顧客重みデータは、重みデータの増加関数FUNCWIDを算出する際にたとえば、20-3参照、引数段落0043で述べたk1、k2あるいはkなどとして使用することができる。<営業支援>いくつかの実施形態を通じて説明した本発明に係るトライアル環境システムの処理結果使用履歴スタックの内容、購買期待度は、営業活動に有益な情報営業情報として営業担当者に知らせることにより営業支援システム10が構築される。以下、営業支援に関して説明する。<ユーザの使用リスト更新>営業支援システム10は、ユーザの使用リストを営業端末に通知することができる。ユーザの使用リストはたとえば、図26に示すような形式である。図示のように、ユーザの使用リスト500mは、複数の行が複数のユーザ名に対応し、複数の列が購買期待度、現使用状況など複数の属性に対応している表形式である。ユーザの使用リスト更新処理の形態を図25に参照符合500で示す。営業サーバ60に接続された処理装置図示せずは、図示しない制御プログラムの制御の下に、ユーザの使用リスト更新処理500を実行する。この処理による更新周期は購買期待度算出処理200による購買期待度の更新周期と同一であってよい。このことは、たとえば、購買期待度算出処理200は購買期待度を更新した際に更新フラグをセットし、このフラグ情報を使用リスト更新処理が参照することで実現できる。なお、所望であれば、両者の更新周期は同一でなくてもよい。図25において、まず、購買期待度が更新されていなければ25-1そのまま終了する。購買期待度が更新されていれば、営業サーバ60からユーザの使用リスト400mたとえば、ウェブページで構成されるをダウンロードする25-2。次に、各ユーザIDここに、ユーザIDは、使用リスト上はユーザ名で表記されて関連付けられているの購買期待度データを購買期待度算出処理の処理結果メモリから読み込む25-3。次に、読み取った各購買期待度データによりユーザの使用リスト500mを更新する25-4。次に各ユーザIDの使用履歴データを使用履歴スタック100mから読み出す25-5。次に、各ユーザIDの使用履歴データからユーザ名ごとに使用履歴棒グラフ使用の履歴を表わした画像を作成し、使用リストにおける該当するユーザ名に関連付ける25-6。最後に更新結果更新した使用リスト及びユーザ名ごとに関連する使用履歴棒グラフを営業サーバ60にアップロードする25-7。<営業端末への通知>営業端末14から営業サーバ56にアクセスされている間、営業サーバ56は営業端末からの要求に応じて、関連する情報を営業端末14に通知表示する。ユーザの使用リストに関連する営業端末への通知処理についていくつかの形態を図27から図29に示す。図27の営業端末への通知処理600Aにおいて、営業端末14ユーザの使用リストが表示中であれば27-1でYES、営業サーバ56は、特定のユーザ名がクリックされたかどうかを判定し27-2、ユーザ名がクリックされたならば、そのユーザ名の使用履歴棒グラフをユーザ名の位置に関連付けて吹き出しで表示する27-3。図2を参照すると、吹き出しで表示される使用履歴棒グラフの例を営業端末14の位置に示してある。図28は営業端末への通知処理の別形態600Bである。この形態600Bでは、使用リストのうちで、所定の使用条件を満たす使用状況データを有するユーザ名を特定し、それらのユーザ名からなる使用リスト使用サブリストを表示するようにしている28-5。スクリーニング表示ステップ28-5の起動は表示されているユーザの使用リスト500mから、現使用状況のボタンがクリックされることで行なってよい28-4。28-5の処理は一種のスクリーニングであり、スクリーニングの方法は様々な態様が容易に実現できる。たとえば、使用状況データが上位10のユーザをスクリーニングする、使用状況データで上位10人のユーザをスクリーニングする、使用状況データの値が条件値を超えるユーザをスクリーニングするなどが実現できる。また、スクリーニング結果をカラーで識別表示色分け表示することも容易である。図29は営業端末への通知処理のさらに別の形態600Cである。この形態600Cでは、ユーザの使用リスト500mのうちで、所定の購買期待度条件を満たす購買期待度を有するユーザ名を特定し、それらのユーザ名からなる使用リスト使用サブリストを表示するようにしている29-5。スクリーニング表示ステップ29-5の起動は表示されているユーザの使用リスト500mから、購買期待度のボタンがクリックされることで行なってよい29-4。29-5の処理は一種のスクリーニングであり、スクリーニングの方法は様々な態様が容易に実現できる。たとえば、購買期待度が上位10のユーザをスクリーニングする、購買期待度で上位10人のユーザをスクリーニングする、購買期待度の値が条件値を超えるユーザをスクリーニングするなどが実現できる。また、スクリーニング結果をカラーで識別表示色分け表示することも容易である。また、形態600Bの使用状況によるスクリーニング機能と形態600Cによる購買期待度によるスクリーニング機能を組み合わせた形態も容易に実現できる。図30に仮想サーバへの登録の際の手続を示す。黒ドットで示す各主体は、人間見込み客、営業担当者を除けば、コンピュータを制御するプログラムによって実現される。図30に記載した主体間のデータないし指令の受け渡しの関係の時系列情報から、本書を読んだ当業者には容易に各主体のプログラムを実装することができる。図31に仮想サーバを使用中の際の手続を示す。黒ドットで示す各主体は、人間見込み客、営業担当者を除けば、コンピュータを制御するプログラムによって実現される。図31に記載した主体間のデータないし指令の受け渡しの関係の時系列情報から、本書を読んだ当業者には容易に各主体のプログラムを実装することができる。図32にサーバ図6の各種サーバ30、40、50、60として使用できるコンピュータサーバコンピュータの代表的なハードウェア構成を示す。サーバコンピュータ1000は、CPU1010、プログラム記憶装置1012、データベースDB記憶装置1014、作業メモリ1016、入力装置1018、表示装置1020、通信インタフェース1022を備え、これらはシステムバスを介して相互に接続されている。プログラム記憶装置1012はCPU1010を制御するための各種プログラム各フローチャートで示したプログラムを含むを記憶するためのものである。CPU1010はプログラム記憶装置1012に記憶されたプログラムの制御の下に動作して、各フローチャートで示したように動作する。データベース記憶装置1014は当該サーバコンピュータ1000に関連するデータベースを記憶する。外部との情報のやり取りは通信インタフェース1022を介して行なわれる。なお、図32に示したサーバコンピュータ1000と図6のPE物理サーバ50との対応関係を説明すると、図6におけるPE物理サーバ50および関連する動的トライアル制御システム52を含んだ機能が、サーバコンピュータ100によって実現される。同様に、図6における営業物理サーバ60および関連する営業データ70を含んだ機能が、同一又は他のサーバコンピュータ100によって実現される。以下、同様であり、たとえば、図6におけるAP物理サーバ30、その仮想サーバ36、VS物理サーバ40および関連するVSマネージメントシステム42が1または複数のサーバコンピュータ1000によって実現される。以上、説明の便宜上、対応関係について一応説明したが、当業者には明らかなように、上記の対応関係に限定されず、他の対抗関係で実施可能であることは自明である。段落0033において、時間帯によっては、その使用状況のモニタリング結果が購買期待度と相関性をもたない可能性を取り上げた。そして、かような時間帯に対しては、使用状況モニタリング自体を実施しないか、使用状況のモニタリングは実施してもそのモニタリング結果は購買期待度の算出から除外することを提案した。また、この種の時間帯における使用状況データの反映を禁止または弱める手法としては、使用状況モニタリングを一時的に中断する方法と、購買期待度算出処理側で、この種の時間帯における使用状況データのモニタリング結果を無視するか低く見積もる方法が考えられるとした。以下では、具体例として、アプリケーションソフトウェアが置かれている物理サーバに対する総アクセス量である、全ユーザに係るトラフィック量をモニターして、時間帯による変動を把握し、時間帯毎のトラフィック量に応じて、各ユーザの各時間帯における使用状況データを再評価する形態を説明する。図33にPE物理サーバ50が実施するトラフィックモニタリング700の動作フローを示す。なお、以下では、PE物理サーバ50および関連する動的トライアル制御システム52を含んだ機能が、サーバコンピュータ100によって実現されるものとして、図32を参照しつつ動作を説明する。まず、最初のステップ33-1で、サーバコンピュータ1000内のCPU1010は、プログラム記憶装置にあるプログラムの制御の下に、全ユーザによるトラフィック量をモニターする。これは、たとえば、使用状況モニタリング100100A-100Fのモニタリング結果である使用履歴スタック100m図9から現区間にあるデータを全ユーザのIDについて、集計することで実現できる。なお、使用履歴スタック100mは作業メモリ1016上に置かれてよい。次のステップ33-2で、CPU1010はプログラムの制御の下に、トラフィック履歴スタック同様に作業メモリ1016上に置かれてよいの現区間にトラフィックのモニター結果をセットする。トラフィック履歴スタックが示すトラフィック量の時間プロファイルの具体例を図35に示す。次のステップ33-3で、CPU1010はプログラムの制御の下に、基準とするトラフィック量を取得する。ここでは、基準とするトラフィック量として、移動平均のトラフィック量を求めている。これはトラフィック履歴スタックを参照することで容易に算出できる。なお、基準とするトラフィック量として、必ずしも移動平均のトラフィック量である必要は無く、所望であれば、重み付け移動平均のトラフィック量であってもよいし、その他、トラフィックに関連する任意の適当な統計量が使用できる。次のステップ33-4で、CPU1010はプログラムの制御の下に、正規化係数を算出する。これは、たとえば、現区間のトラフィック量を基準のトラフィック量たとえば、移動平均のトラフィック量で正規化することで実現できる。最後のステップ33-5で、CPU1010はプログラムの制御の下に、算出した正規化係数を正規化履歴スタック同様に作業メモリ1016上に置かれてよいの現区間にセットする。図34にPE物理サーバ50が実施する使用履歴スタックの正規化処理800の動作フローを示す。具体的には、図6で述べた機能50および52が図32に例示するようなサーバコンピュータ1000で実現されたものとして説明する。最初のステップ34-1で、CPU1010はプログラムの制御の下に、使用履歴スタック100m図9参照を読み出す。次のステップ34-2で、CPU1010はプログラムの制御の下に、使用履歴スタック100mの各要素各区間の使用状況データを正規化履歴スタック図33のフローにより算出済みの各要素各区間の正規化係数に対応付け、各区間の使用状況データおよび区間長たとえば30分間、60分間などを対応付けた正規化係数で正規化する。その結果は、正規化使用履歴スタックとして定義される34-3。このような正規化使用履歴スタックは、購買期待度算出処理300のなかで、使用履歴スタック100m図9の代わりに使用することができる。結果として、特殊な時間帯における使用状況データの反映を禁止または弱める手法が実現される。図35は、図32-図34で述べた正規化処理を説明する図である。図35には、トラフィック量を評価した正規化係数により、使用状況データここでは、区間長、使用時間、アクセス回数が再評価される様子が示されている。使用状況データの属性である区間長を正規化係数で正規化することにより、時間軸の圧縮、伸長を実現できる。その他、詳細については、図35自体から自明であるので、これ以上の説明は省略する。トラフィックモニタリングを利用した使用状況データの再評価の手法図32-図35は、個々のアプリケーションソフトウェアの特殊性を考慮する必要がない点で、汎用性がある。また、個々のユーザの使用状況データを集計することでトラフィック量が求められるので、プログラム的に無駄がなく、実施が容易である。また、トラフィック量は様々な要因で時間的に変動すると考えられるが、計測したトラフィック量の時間プロファイルトラフィック履歴スタックの内容を基にして定められるトラフィック量を基準とすることにより、各区間の使用状況データ等に対して適切な正規化が実現できる。また、トラフィック量が多いときにアプリケーションソフトウェアを試用しているユーザいわば、魚群の濃い場所にいるユーザに対して有利にリソースを割り当てることが可能となる多数派優先機能。また、購買期待度の時間プロファイルを円滑化できる。なお、トラフィック量の時間プロファイルと個々のユーザの使用履歴データとの相関度を算出するプログラムを用意してもよい。ユーザによっては、他のユーザとは逆の行動パターン試用パターンをとる人もいるが、この種のユーザユーザIDは低い相関度によって特徴付けることができ、相関度算出プログラムによって検出可能である。所望であれば、検出した対象ユーザIDには、正規化していない使用履歴スタック図9の内容に基づいて、リソースを割り当てるようにしてもよい少数派補償機能。以上で、実施形態の説明を終えるが、実施形態はもっぱら例示を目的とするものであり、本発明を制限することを意図していない。たとえば、1つの仮想サーバに置かれるアプリケーションソフトウェアをグループウェアとして使用する場合には、通常、試用契約の組織に属する複数のメンバーが固有のメンバーIDで同一アプリケーションソフトウェアを共用することになり、このようなグループウェアの場合にも本発明を適用できることはいうまでもない。この場合、実施形態で述べたユーザIDはグループウェアの試用契約に係るメンバーIDのセットで構成されることになる。また、図示実施形態においては、各ユーザIDについて、使用状況データ、必要に応じて顧客重みデータを加えた1ないし多変数入力使用状況データ等からそのユーザの購買期待度を数値として明に算出し、算出した購買期待度の数値に合わせて仮想サーバに対する物理リソースコンピュータ資源の割り振りないし占有率を調整しているが、これには限られない。すなわち、使用状況データ等からユーザIDごとに優先順位を付け、優先順位に従って各仮想サーバの物理リソース割当率ないし占有率物理リソース割当量を決定するような構成も本発明の範囲に属するものである。なぜならば、かかる構成にも、使用状況データ等に基づいてユーザの購買期待度を順位の形式で決定した結果が優先順位となって現れているからである。なお、優先順位に従って各仮想サーバの物理リソース割当量を決定するコンピュータプログラムは当業者にとって自明である。また、動的トライアル環境システム部図7の少なくとも一部において、たとえば購買期待度算出部200において、メンバーシップ関数を使用するファジー演算を少なくとも部分的に利用した形態が実現可能である。また、購買期待度算出部が算出する購買期待度は単一の数値で表現した購買期待度である必要は無く、確率密度関数形式で表現した購買期待度であってもよい。この場合、採用する確率密度関数として任意の適当な関数が使用でき、たとえばガウス分布関数正規分布を使用した場合であれば、中心値と分散により購買期待度を定義できる。たとえば、中心値には、図示実施形態で述べたような購買期待度を代入し、分散は適当な分散要因、たとえば、使用状況データの時間的変動などに基づいて決めることができる。確率密度関数形式の購買期待度からリソース割当量を決定する形態では、適当なタイミングで、たとえばリソース割当動作300の都度、適当な乱数を生成して購買期待度を表現した確率密度関数のなかから物理リソースの割当に適用する数値を選択し、後は、図示実施形態図22、図23のようにして各ユーザIDについて、仮想サーバに割り当てるリソース量を決定することができる。以上のように、本発明は説明した実施形態には限定されず、本発明の範囲内で種々変更が可能である。したがって、本発明の範囲は添付する特許請求の範囲の記載に基づいて定められるべきものである。以上の説明から明らかなように、本発明の特徴の一は、仮想マシンをユーザIDに割り当てて仮想マシン上のアプリケーションをユーザに試用させるトライアル環境システムにおいて、アプリケーションソフトウェアに対する使用状況をモニターする点にある。ここにおいて、アプリケーションソフトウェアに対する使用状況というものは、アプリケーションソフトウェアの実行によって実際に仮想マシンで使用されている物理リソース量とは似て非なる概念である。なぜならば、前者はユーザの購買期待度と相関性を有するのに対して、後者仮想マシンで使用される物理リソース量は、第一義的に、アプリケーションソフトウェアの種類や実行中のアプリケーションソフトウェア部分たとえば、多くのメモリやデータ処理量を必要とするソフトウェア部分、あるいは所要メモリ量やデータ処理量が少ないソフトウェア部分に依存する性質をもつにすぎないからである。また、後者がマシン寄りの低レベル情報であるのに対して前者はユーザに係る高レベル情報であって、レイヤーが異なっている。したがって、後者による実際の物理リソース使用量からはアプリケーションソフトウェアに対するユーザの購買期待度情報は得られない。これに対して、本発明の場合、アプリケーションソフトウェアに対するユーザの使用状況をモニターしているので、モニターした使用状況と購買期待度とは相関関係を有し、それにより、モニターした使用状況に基づいてユーザアプリケーションソフトウェア試用者の購買期待度を算出することが可能になる。また、特定の実施形態では、アプリケーションソフトウェアの使用状況のみならず、ユーザの購買期待度と相関性を有する顧客重み情報をも考慮して購買期待度を算出している。この形態の場合も、ユーザの購買期待度を求めることができる。結果として、本発明の場合、トライアル環境システムの提供者やアプリケーションソフトウェアのプロバイダは、低いランニングコストで、より多くの購買者を獲得するという可能性が高められる。以下、付記について記載する。なお、付記において参照符号を括弧書きで記入しているとともに付記の横に図番、段落等を記載しているが、開示の裏づけを示したもので、本発明の範囲を限定することを意図していない。付記C1:図6、図7インターネット20に接続される複数の仮想サーバ36、各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェア38が置かれること、各仮想サーバにはそれぞれのユーザIDが割り当てられること、複数の仮想サーバは有限リソースの物理サーバ30に基づいて構築されるものであること、端末12およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター54;100、モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段56;200、物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段58;300、を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システム。効果:低コストでトライアル環境システムを提供することができる。同時に、購買意欲のあるユーザは快適な動作環境でアプリケーションソフトウェアを使用できる。付記C2:図8-13使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間の使用状況を表わす数値データ現使用状況データを取得して購買期待度算出手段に供給する、付記C1に記載のトライアル環境システム。効果:区間毎の使用状況を把握できる。付記C3:図8-13使用状況モニター100は、現使用状況データを定期的に取得する100A;100B;100C;100D;100E、付記C2に記載のトライアル環境システム。効果:使用状況モニタリングが容易に実現できる。付記C4:段落0025使用状況モニターが取得する現使用状況データの取得間隔は一秒から三日の範囲内である、付記C3に記載のトライアル環境システム。効果:比較的低速の使用状況モニタリングで足りる。付記C5:図15図17-21も同様購買期待度算出手段200は、現使用状況データにより購買期待度を算出する200A、付記C2からC4のいずれか一項に記載のトライアル環境システム。効果:購買期待度に合わせたリソース割当が容易に実施できる。付記C6:図9、集計=移動平均、図16など購買期待度算出手段200は、過去の複数の区間での使用状況データ過去使用状況履歴データを蓄積する記憶手段100mを含み、過去使用状況履歴データと現使用状況データとから購買期待度を算出する200B、付記C2から付記C4のいずれか一項に記載のトライアル環境システム。効果:購買期待度の平滑化が実現容易になる。付記C7:図8、図10、図12使用状況モニター100は、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するAアクセス回数、B使用時間、C使用段階、およびDこれらの組み合わせからなる群のなかから選択されたものを取得する100A,100B、100D、付記C1に記載のトライアル環境システム。各種使用状況を選択しえる。付記C8:図13および関連説明段落0030使用状況モニター100は、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するAアクセス回数、B使用時間、C使用段階のうち2以上からなるもの複数種類の現使用状況データを取得し、購買期待度算出手段は、複数種類の現使用状況データを演算して1つの数値データに変換する手段を含む、付記C1に記載のトライアル環境システム。複数種類の使用状況データを取得できる。付記C9:図6、図18-21ユーザID毎の購買重みデータWIDを蓄積した購買重みデータベース72をさらに備え、購買期待度算出手段200は、モニターしたユーザ毎の使用状況とユーザ毎の購買重みデータとに基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する200C;200D;200E;200F、付記C1に記載のトライアル環境システム。効果:使用状況のみならず、購買期待度と相関性のある情報購買重みデータにも配慮した購買期待度が得られる。付記C10:図23仮想リソース動的割り当て手段300は、ユーザID毎に割り当てられる仮想リソースの容量がアプリケーションソフトに関連付けた下限を下回らず、かつアプリケーションソフトに関連付けた上限を上回らないように確保する仮想リソースソース確保手段23-4、23-5を含む300B、付記C1に記載のトライアル環境システム。効果:アプリケーションソフトウェアを使用する際のトライアル環境を整備できる。付記C11:図27-29付記C1からC10のいずれか一項に記載のトライアル環境システムと、使用状況モニターのモニター結果および/または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業IDが入力された端末営業端末に通知する通知手段600A;600B;600Cと、を備える営業支援システム10。効果:過剰なリソースコンピュータ資源を費やすことなく、トライアル中のユーザに対して適切な営業活動が可能になり、低コストの営業支援システムを提供できる。付記F1:段落0025使用状況モニターが取得する現使用状況データの取得間隔は30分から一日の範囲内である、付記C4に記載のトライアル環境システム。効果:使用状況モニタリング処理経費が低コストになる。付記F1:図8使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するアクセス回数を取得する100A、付記C1に記載のトライアル環境システム。効果:アプリケーションソフトウェアの属性に依存しない汎用性がある。付記F2:図10使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する使用時間を取得する100B、C1に記載のトライアル環境システム。効果:汎用性がある付記F3:図11使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する使用時間およびアクセス回数を取得する100C、付記C1に記載のトライアル環境システム。効果:汎用性がある。付記F4;図14使用状況モニターは、仮想サーバに係る特定のイベントの発生に応答してモニターを行なうことにより、現使用状況データを非定期的に取得する100F、付記C2記載のトライアル環境システム。効果:非同期の使用状況モニタリングを実現できる。付記F5:図16購買期待度算出手段200は、過去使用状況履歴データと現使用状況データからなる時系列データに対して時間関数である重み付けパターンによる重み付けをした移動平均をとって購買期待度を算出する200B、付記C4に記載のトライアル環境システム。効果:購買期待度を平滑化できる。重み付けパターンを工夫することで、現使用状況データに対する購買期待度の感度を上げることも可能である。付記F6:図18購買期待度算出手段200は、モニターしたユーザ毎の使用状況を表すデータにユーザ毎の購買重みデータを掛け合わせてアプリケーションソフトウェアに対する各ユーザの購買期待度を算出する200C付記C7に記載のトライアル環境システム。効果:購買期待度を使用状況データのみならず購買重みデータにも依存させることができる。付記F7:図20購買期待度算出手段は、モニターしたユーザ毎の使用状況を表すデータに、ユーザ毎の購買重みデータが表す購買重みの増加関数を掛け合わせてアプリケーションソフトウェアに対する各ユーザの購買期待度を算出する200E付記C7に記載のトライアル環境システム。効果:効果:購買期待度を使用状況データのみならず購買重みデータにも依存させることができる。付記F8:図28通知手段は、使用状況のモニター結果から所定の使用条件を満足する使用状況にあるユーザ名を特定し、特定したユーザ名を営業支援情報として通知する機能600Bを有する付記C11に記載の営業支援システム。効果:営業のために、特定のユーザ名をスクリーニングできる。付記F9:図29通知手段は、購買期待度算出結果から所定の購買期待度条件を満足する購買期待度を有するユーザ名を特定し、特定したユーザ名を営業支援情報として通知する機能600Cを有する付記C11に記載の営業支援システム。効果:営業のために、特定のユーザ名をスクリーニングできる。付記G1:図32-図35物理サーバに対する全ユーザIDのトラフィック量をモニターするトラフィックモニター700を備え、現使用状況データをトラフィック量のモニター結果に基づいて正規化する正規化手段800を備える、付記C2のトライアル環境システム。効果:段落0065参照。"