(57)【要約】【課題】    制約された物理リソースの下で、仮想サーバ上のアプリケーションソフトウェアに対するトライアル環境をユーザの使用状況等に配慮して調整する。【解決手段】  無償または有償の試用期間の間、アプリケーションソフトウェア（３８）をユーザ（見込み客）に試用させるトライアル環境（８０）のシステムを提供する。有限の物理リソースを有する物理サーバ（３０）上に複数の仮想サーバ（３６）が展開され、各ユーザ端末（１２）からインターネット（２０）を通じてユーザの仮想サーバにあるアプリケーションソフトウェア（３８）が試用される。仮想サーバ毎に、トライアル環境（８０）におけるアプリケーションソフトウェアの使用状況をモニターし（８２）、モニターした使用状況等に基づいて仮想サーバに割り当てるべきリソース量を決定する（８４）。各仮想サーバは決定したリソース量で動作して（８６）、トライアル環境（８０）を動的に調整する。【選択図】  図１
2013109653.tif 000002
【特許請求の範囲】
【請求項１】
インターネットに接続される複数の仮想サーバ、
各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、
各仮想サーバにはそれぞれのユーザＩＤが割り当てられること、
複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、
端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、
モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、
物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、
を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システム。
【請求項２】
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間の使用状況を表わす数値データ（「現使用状況データ」）を取得して購買期待度算出手段に供給する、請求項１に記載のトライアル環境システム。
【請求項３】
使用状況モニターは、現使用状況データを定期的に取得する、請求項２に記載のトライアル環境システム。
【請求項４】
使用状況モニターが取得する現使用状況データの取得間隔は一秒から三日の範囲内である、
請求項３に記載のトライアル環境システム。
【請求項５】
購買期待度算出手段は、現使用状況データにより購買期待度を算出する、請求項２から４のいずれか一項に記載のトライアル環境システム。
【請求項６】
購買期待度算出手段は、過去の複数の区間での使用状況データ（「過去使用状況履歴データ」）を蓄積する記憶手段を含み、過去使用状況履歴データと現使用状況データとから購買期待度を算出する、請求項２から４のいずれか一項に記載のトライアル環境システム。
【請求項７】
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する（Ａ）アクセス回数、（Ｂ）使用時間、（Ｃ）使用段階、および（Ｄ）これらの組み合わせからなる群のなかから選択されたものを取得する、請求項１に記載のトライアル環境システム。
【請求項８】
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する（Ａ）アクセス回数、（Ｂ）使用時間、（Ｃ）使用段階のうち２以上からなるもの（「複数種類の現使用状況データ」）を取得し、
購買期待度算出手段は、複数種類の現使用状況データを演算して１つの数値データに変換する手段を含む、請求項１に記載のトライアル環境システム。
【請求項９】
ユーザＩＤ毎の購買重みデータを蓄積した購買重みデータベースをさらに備え、
購買期待度算出手段は、モニターしたユーザ毎の使用状況とユーザ毎の購買重みデータとに基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する、
請求項１に記載のトライアル環境システム。
【請求項１０】
仮想リソース動的割り当て手段は、ユーザＩＤ毎に割り当てられる仮想リソースの容量がアプリケーションソフトに関連付けた下限を下回らず、かつアプリケーションソフトに関連付けた上限を上回らないように確保する仮想リソースソース確保手段を含む、請求項１に記載のトライアル環境システム。
【請求項１１】
請求項１から１０のいずれか一項に記載のトライアル環境システムと、
使用状況モニターのモニター結果および／または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業ＩＤが入力された端末（「営業端末」）に通知する通知手段と、
を備える営業支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システムおよび営業支援システムに関するものである。
【背景技術】
【０００２】
従来から、物理サーバ上に複数の仮想マシン（仮想サーバ）を構築し、互いに独立に動作させるサーバ仮想化技術が知られている。たとえば、この種の技術を適用した製品として、ヴイエムウェア社による「ＶＭＷａｒｅＥＳＸ  Ｓｅｒｖｅｒ」、マイクロソフト社による「Ｖｉｒｔｕａｌ  Ｓｅｒｖｅｒ」、および米国Ｘｅｎ  Ｓｏｕｒｃｅ社による「Ｘｅｎ」などが知られている。
【０００３】
この種の仮想サーバをトライアル期間中にユーザに無料あるいは有償で貸与し、仮想サーバに搭載したアプリケーションソフトウェアをトライアル環境において試用させる用途（トライアル環境システム）を考えることができる。また、トライアル環境でのユーザの活動状況を営業の支援に応用した営業支援システムの提供についても少なからずニーズがあると考えられる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１７０７８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
この種のトライアル環境システムにおいては、物理サーバから利用できるリソースの容量に制約が大きいことが一般的であり、そのため、全ユーザに均等な仮想リソースを割り当てる戦略は平等である反面、個々のユーザにおけるアプリケーションソフトウェアの購入意欲をそぐ可能性がある。また、アプリケーションソフトウェアのプロバイダには、均等割り当てはビジネス面で不利であると考えられる。
【０００６】
そこで、本発明は、アプリケーションソフトウェアのトライアル環境における限られたリソースの制約の中で、個々のユーザに適切なリソース（コンピュータ資源）が割り当てられるようにしたトライアル環境システムを提供することを目的とする。また、本発明はこの種のトライアル環境システムを利用した営業支援システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一側面によれば、
インターネットに接続される複数の仮想サーバ、
各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、
各仮想サーバにはそれぞれのユーザＩＤが割り当てられること、
複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、
端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、
モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、および
物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、
を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システムが提供される。
【０００８】
この構成によれば、低コストでトライアル環境システムを提供することができる。同時に、購買意欲のあるユーザは快適な動作環境でアプリケーションソフトウェアを使用できる。
【０００９】
本発明の別側面によれば、
インターネットに接続される複数の仮想サーバ、
各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェアが置かれること、
各仮想サーバにはそれぞれのユーザＩＤが割り当てられること、
複数の仮想サーバは有限リソースの物理サーバに基づいて構築されるものであること、
端末およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター、
モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段、
物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段、および
使用状況モニターのモニター結果および／または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業ＩＤが入力された端末（「営業端末」）に通知する通知手段、
を備える営業支援システムが提供される。
【００１０】
この構成によれば、過剰なリソース（コンピュータ資源）を費やすことなく、トライアル中のユーザに対して適切な営業活動が可能になり、低コストの営業支援システムを提供できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の概要を示す概念図である。
【図２】図１の概念図の特徴の一を示す図である。
【図３】仮想サーバを構築するシステムを示す図である。
【図４】仮想サーバを構築するシステムにおける複製機能を示した図である。
【図５】本発明の主要部である仮想リソース割り当て決定システムの説明図である。
【図６】本発明の実施形態に係る営業支援システムの構成を示すブロック図である。
【図７】実施形態に係るトライアル環境調整の動作フローである。
【図８】使用状況モニタリングの具体例を示すフローチャートである。
【図９】使用履歴スタックメモリを示す図である。
【図１０】使用状況モニタリングの別の具体例を示すフローチャートである。
【図１１】使用状況モニタリングのさらに別の具体例を示すフローチャートである。
【図１２】使用状況モニタリングのさらに別の具体例を示すフローチャートである。
【図１３】使用状況モニタリングのさらに別の具体例を示すフローチャートである。
【図１４】イベント駆動型の使用モニタリングの具体例を示すフローチャートである。
【図１５】購買期待度算出処理の具体例を示すフローチャートである。
【図１６】購買期待度算出処理の別の具体例を示すフローチャートである。
【図１７】図１６の処理で参照する履歴重みパターン関数を説明する図である。
【図１８】購買期待度算出処理のさらに別の具体例を示すフローチャートである。
【図１９】購買期待度算出処理のさらに別の具体例を示すフローチャートである。
【図２０】購買期待度算出処理のさらに別の具体例を示すフローチャートである。
【図２１】購買期待度算出処理のさらに別の具体例を示すフローチャートである。
【図２２】仮想リソース割当処理の具体例を示すフローチャートである。
【図２３】仮想リソース割当処理の別の具体例を示すフローチャートである。
【図２４】顧客重みデータ更新処理の具体例を示すフローチャートである。
【図２５】ユーザの使用リスト更新処理の具体例を示すフローチャートである。
【図２６】ユーザの使用リストを説明する図である。
【図２７】営業端末への通知処理の具体例を示すフローチャートである。
【図２８】営業端末への通知処理の別の具体例を示すフローチャートである。
【図２９】営業端末への通知処理のさらに別の具体例を示すフローチャートである。
【図３０】本発明の実施形態におけるユーザの登録手順を説明する図である。
【図３１】本発明の実施形態に基づいた各部の動作の手順を説明する図である。
【図３２】サーバの代表的なハードウェア構成図である。
【図３３】トラフィックモニタリングの動作を示すフローチャートである。
【図３４】使用履歴スタック正規化処理のフローチャートである。
【図３５】トラフィック量の時間帯による変動に応じた使用状況データの正規化（再評価）を説明する図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明をさらに詳細に説明する。図面に示す実施形態のシステムは、仮想サーバに置かれたアプリケーションソフトウェアを無償または有償のトライアル期間においてユーザ（見込み客）に開放して試用できるようにしたトライアル環境システムを備えた営業支援システムである。
【００１３】
図１から図６を参照すると、営業支援システムは顧客情報データベースを初めとして各種営業データベースを備えており、営業担当者は営業端末から営業ＩＤを指定することによりインターネットを通じて、営業データベースにアクセスすることができ、ユーザ（アプリケーションソフトウェアの試用者）に対して営業活動を行なうことが容易になっている。一方、ユーザはユーザ端末からユーザＩＤを指定することにより、インターネットを通じて、仮想サーバのアプリケーションソフトウェアにアクセスして試用することができるようになっている。
【００１４】
図１に本発明の営業支援システム１０の概念図を示す。なお、図１では、インターネット、物理サーバ、仮想サーバなどはユーザ、営業担当者には「透明」であるところから、図示を省略し、本発明の特徴である動的な「トライアル環境システム」を強調した記載になっている。
【００１５】
図１において、ユーザが自己のＩＤに割り当てられた試用対象であるアプリケーションソフトウェアにアクセスして試用するときの環境をトライアル環境８０として描いている。アプリケーションソフトウェア３８は仮想サーバ３６に置かれているため、本発明では、仮想サーバ３６のリソース容量を調整することで、通信速度、アプリケーションソフトウェアの動作速度などが変化し、トライアル環境の快適さをユーザに提供することができる。ここに、仮想サーバは、限られたリソース容量をもつ物理サーバ３０に基づいて構築されるものであるため、複数のユーザによる複数の仮想サーバの使用環境下で、各仮想サーバに割り当てられる平均的割当リソース量には大きな制約がある。本発明では、アプリケーションソフトウェアの試用に積極的なユーザに対して、割り当てリソース量を増やしてトライアル環境８０の快適さを提供している。図１に破線で示すように拡大したトライアル環境は割り当てリソース量が増大したことを示唆している。なお、実際にはトライアル環境８０はユーザごとの試用環境であり、ユーザの数に相当するトライアル環境が存在するが、図１では図示の便宜上、１つのトライアル環境８０のブロックで代表させている。
【００１６】
図１において、トライアル環境利用情報８２はこのようなトライアル環境８０におけるアプリケーションソフトウェア３８の利用情報（使用状況）を表わしており、取得されたトライアル環境利用情報８２はリソース割り当て量決定システム８４に渡される。リソース割り当て量決定システム８４はトライアル環境利用情報８２（アプリケーションソフトの使用状況）に基づいてそのユーザの購買期待度を算出し、算出した購買期待度に応じてそのユーザの使用する仮想サーバ３６に割り当てるリソース量を決定する。リソース割り当て量決定システム８４の決定結果（リソース量）は仮想サーバマネジメントシステム８６に渡される。仮想サーバマネジメントシステム８６は決定したリソース量に基づいて当該仮想サーバ３６に各リソース、具体的には、図５に例示するように仮想サーバ用ＣＰＵ、仮想サーバ用メモリ、仮想サーバ用ネットワーク（帯域）および仮想サーバ用のストレージを割り当て実行する。仮想サーバマネジメントシステム８６による仮想リソースの割り当て結果に応じて、トライアル環境８０で使用可能なリソース量が動的に変わる。
【００１７】
図２は図１と同様の図であるが、ユーザ毎のトライアル環境の使用状況などを営業担当者に通知する機能に焦点を当てて描いたものである。すなわち、トライアル環境の使用状況は営業端末１４を通じて営業担当者に通知することができる。たとえば、営業端末１４にユーザの使用履歴データを表示することができる。トライアル環境の使用状況などを表わす情報として、トライアル環境利用情報８２に代え、あるいはこれと組み合わせてユーザの購入期待度（リソース割り当て量決定システムの中間演算結果）を営業端末１４から見ることができるようにしてもよい。あるいは、購入期待度の高い（若しくは使用量の多い）ユーザをスクリーニングして表示する機能を持たせてもよい。
【００１８】
物理サーバ３０から仮想サーバ３６を構築するシステム（図３）自体は公知である。図３において、マネージメントシステム４２は仮想サーバ３６の作成、削除、起動、リソース割り当てを実行する制御システムである。ハイパーバイザー３２を物理サーバ３０にインストールすることによりマネージメントシステム４２はリソースプール３４を通じて仮想サーバ３６に関するオペレーション（作成、削除、起動、リソース割り当てなど）が可能になる。図４は図３と同様の図であるが、公知のように、マネージメントシステム４２のオペレーションの下に、仮想サーバ３６の複製が行われることを示したものである。なお、マネージメントシステム４２は図１の仮想サーバマネジメントシステム８６の具体例である。
【００１９】
図５はこの種のマネージメントシステム４２のサポート下で、本発明により提供される「動的トライアル環境システム」を、リソース割り当て決定システム８４に焦点を当てて示したものである。なお、マネージメントシステム自体はバックグランドサポートとして、図５には図示していない。リソース割り当て量決定システム８４は各仮想サーバ３６をモニタリングして、アプリケーションソフトウェアに対する各ユーザ（仮想サーバ使用者）の使用状況を取得し、その結果に基づいて各仮想サーバに対するリソース割当量を決定する。マネージメントシステム４２は決定した割当量を受け、リソースプール３４を介して仮想サーバ３６の各リソース割り当て域を調整する。
【００２０】
図５において、リソース割当量決定システム８４に吹き出しをつけ、吹き出し内に、同システム８４の動作フローを記載している。動作フロー自体の記載は明白であるのでこれ以上の説明は省略する。なお、リソース割当量決定システム８４の動作、機能は、動作フローに記載した動作、機能には限定されず、本発明の範囲内で種々の変更が可能である。
【００２１】
図６は実施形態に係る営業支援システム全体のハード構成の概要を示すブロック図である。インターネット２０には複数のユーザ端末１２が接続可能であり、１以上の営業端末１４が接続可能である。さらに、インターネット２０にはネットワーク機器（ファイアウォール、ロードバランサ、ＬＡＮスイッチ等）を介して営業支援システムの主要部を構成するＬＡＮが接続される。ＬＡＮのバスには、ＡＰ物理サーバ３０が接続され、ＡＰ物理サーバ３０に基づいて構築された複数の仮想サーバ３６が接続される。仮想サーバ３６にはユーザ端末１２からユーザＩＤによりアクセスして使用可能なアプリケーションソフトウェア３８が置かれる。さらに、ＶＳ物理サーバ４０および関連するＶＳマネージメントシステム４２がＬＡＮバスに接続される。また、ＬＡＮバスにはＰＥ物理サーバ５０を通じて動的トライアル制御システム５２が接続される。動的トライアル制御システム５２は使用状況モニター５４、購買期待度算出部５６、ＶＳリソース割り当て部５８を有する。また、ＬＡＮバスには営業サーバ６０および関連する営業データベース７０が接続される。
【００２２】
なお、図６において、物理サーバ３０、４６、５０、６０をそれぞれ１つのブロックで示しているが実際の物理サーバの個数を反映したものではない。また、所望であれば、たとえば、ＰＥ物理サーバ５０と営業サーバ６０の機能を併合した１以上の物理サーバで、サーバ５０と６０をインプリメントすることなどが可能である。したがって、各ブロックは「機能」に着目してブロック表示したものであると解釈されたい。さらに、単一のＬＡＮ内部に各要素を示しているが、これには限らず、所望であれば、各要素はインターネット上に分散されて存在してもよい。また、ユーザ端末１２は、ユーザがＩＤを通じてアプリケーションソフトウェアにアクセスするのに使用される端末であることを意味しており、ユーザが所有する端末である必要はない。営業端末１４についても同様であり、営業端末１４は、営業担当者が営業ＩＤを通じて営業支援システム本体（図６のＬＡＮのうち営業ＩＤにアクセス権が与えられている部分、典型的には営業サーバ６０）にアクセスするのに使用される端末であることを意味する。なお、端末１２、１４の種類、仕様は特に問わない。ウェブブラウザを備えたパーソナルコンピュータ、あるいは携帯情報端末であり得る。
【００２３】
以上のように構成した、トライアル環境システム、営業支援システム１０の動作について以下、フローチャートを参照して説明する。
【００２４】
図７はトライアル環境システムの動作を示すフローチャートである。
トライアル環境システムは、動的トライアル制御システム５２の制御の下に、ＰＥ物理サーバ５０を通じて、使用状況モニタリング１００を実行し、購買期待度算出処理２００を実行し、仮想リソース割当処理３００を実行する。
【００２５】
＜使用状況モニタリング１００＞
使用状況モニタリング１００はユーザのアプリケーションソフトウェアに対する現在の使用状況を取得する処理である。この種のモニタリングは定期的（周期的）あるいはイベントに応じて実行することができる。定期的に使用状況モニタリングを行なう場合に、モニタリングのサンプリングレート（現使用状況データの取得周期）は、比較的低速であることが好適であり、具体的には、現使用状況データの取得間隔は一秒から三日の範囲内（さらに好ましくは３０分から一日の範囲内）であってよい。
【００２６】
定期型の使用状況モニタリング１００を実現するための、複数種類の実施形態を図８から図１３に示す。図８は、アプリケーションソフトウェア３８へのアクセス回数を現在（現区間）の使用状況データとする形態１００Ａである。まず、ＰＥ物理サーバ５０はＡＰ物理サーバ３０に問い合わせて、各ユーザＩＤについて現区間の通信記録を取得する（８−１）。ここに「現区間」は、現時点から現使用状況データの取得間隔の長さだけ過去までの区間で定義してよい（たとえば、今から３０分前までの区間）。次に、各ユーザＩＤについて、取得した現区間の通信記録から現区間におけるアクセス回数を取得する（８−２）。次に、各ユーザＩＤについて、取得した現区間におけるアクセス回数を現在の使用状況データとして決定する（８−３）。最後に、各ユーザＩＤについて、決定した使用状況データを使用履歴スタックにセットする（８−４）。ここに使用履歴スタックはユーザＩＤ毎に用意されており、図９に１００ｍで示すように構成される。８−３で決定した使用状況データは、この使用履歴スタック１００ｍの「現区間」のエリアに置かれる。すなわち、８−４では、使用履歴スタックのトップに新しい「現区間」のエリアを定義し（その際、スタック上のいままでの「現区間」は「１つ前」に再定義され、「１つ前」の区間は「２つ前の区間」に再定義され、以下、同様である）、そこに決定した使用状況データをセットする。なお、８−２におけるアクセス回数の取得（算出）は、１）ログインのカウント、２）ログオフのカウント、または、３）ログイン及びログオフのカウントにより、容易にインプリメントできる。所望であれば、ログイン、ログオフ以外にトランザクションの回数もカウントして、アクセス回数を算出するようにしてもよい。その場合において、ログインおよび／またはログオフに係る計数値は第一種のアクセス回数（第一種の使用状況データとして定義できる）として取得し、トランザクションに係る計数値は第二種のアクセス回数（第二種の使用状況データ）として取得し、後述する購買期待度を算出する際にそれぞれ、引数として使用するようにしてもよい。あるいは、使用状況モニタリングのなか（８−２）で、第一種のアクセス回数と第二種のアクセス回数の線形結合により「統合した」アクセス回数を取得するようにしてもよい。
【００２７】
図１０は、アプリケーションソフトウェア３８への現区間における使用時間を現在の使用状況データとする形態１００Ｂである（１０−２、１０−３参照）。他のステップは形態１００Ａと同様である。
【００２８】
図１１は、形態１００Ａと形態１００Ｂを組み合わせた形態１００Ｃである。すなわち、各ユーザＩＤについて現区間におけるアクセス回数と使用時間を取得し（１１−２）、取得したアクセス回数と使用時間とから使用状況データを決定する（１１−３）。たとえば、アクセス回数Ａと使用時間Ｔとの線形結合を使用状況データとして求めることができる。他は形態１００Ａと同様である。
【００２９】
図１２は、現区間におけるアプリケーションソフトウェアの使用段階（たとえば、ゲームソフトウェアにおけるゲームステージ）に基づいて現区間の使用状況データを決定する形態１００Ｄである（１２−２、１２−３参照）。したがって、アプリケーションソフトウェアがその性質上、「使用段階」を持つことが前提になっている。この形態１００Ｄはアプリケーションソフトウェアの属性に依存する点で汎用性は低下するが、かかる属性をもつアプリケーションソフトウェアに対する使用状況を決定するのには有効であると考えられる。これに対して、形態１００Ａから１００Ｃで抽出している「アクセス回数」と「使用時間」は原理的にアプリケーションソフトウェアの種類には依存しないデータであることから任意のアプリケーションソフトウェアに対して適用でき、汎用性が高い。
【００３０】
図１３に示す形態１００Ｅは、各ユーザＩＤについて現区間におけるアクセス回数、使用時間および使用段階のうち２以上の要素を取得し（１３−２）、各ユーザＩＤについて取得した２以上の要素を合成（たとえば、線形結合）して１つの数値データとしての使用状況データを決定する（１３−３）ものである。形態１００Ｅの一変形形態において、使用状況モニターとしては、各ユーザＩＤについて取得した２以上の要素を合成することなく第１種、第２種などの使用状況データとして（一般的に拡張すると、多変数の使用状況データとして）そのまま残し（なお使用履歴スタックはこれに対応する構成とする）、購買期待度算出処理２００側で、購買期待度算出手段は、複数種類の使用状況データを演算して１つの数値データ（統合した使用状況データ）に変換するようにしてもよい。要するに、各種使用状況データの関数として購買期待度が与えられるような場合、使用状況モニターが生成した各種使用状況データを引数として購買期待度を算出する機能を購買期待度算出処理に持たせることは合理的である。
【００３１】
図１４は仮想サーバにあるアプリケーションソフトウェアに関連するイベントが発生した際に（１４−１）、使用状況モニタリングを実施する形態１００Ｆである。したがって、この形態１００Ｆはモニタリングの実施タイミングについて非周期型である。なお、図１４に示す形態１００Ｆの場合、使用履歴スタックとしては図９で説明したものを使用し、使用履歴スタックに新しい「現区間」のエリアが作成されるのは、一定間隔としている（図１４には図示せず）。これにより、発生するイベントの非同期性との調整を行なっている。すなわち、１４−３で発生イベントから関連する使用状況データ要素（たとえばアクセス発生）を求めた後、１４−４でイベントに係るユーザＩＤの使用履歴スタック１００ｍから現区間にある使用状況データを取り込み、それを１４−３で求めた使用状況データ要素を用いて更新する。その後、更新結果を使用履歴スタックの「現区間」のエリアに戻す処理を行なう（１４−５）。なお１４−２では発生したイベントに関与したユーザＩＤを決定している。なお、形態１００Ｆにおいて、「現区間の使用状況データ」は、形態１００Ａで述べたような「アクセス回数」、形態１００Ｂで述べたような「使用時間」、形態１００Ｃで述べたような「アクセス回数と使用時間の合成関数」、形態１００Ｄで述べたような「使用段階（ゲームステージ）」、あるいは形態１００Ｄで述べたような「２以上の要素の合成関数」を用いて定義してよく、あるいは段落００３０で述べたような多変数の使用状況データによって定義してもよい。
【００３２】
＜購買期待度算出２００＞
購買期待度算出処理２００は、使用状況モニタリング１００の結果（たとえば、使用履歴スタック１００ｍの内容）を利用してユーザの購買期待度を算出するものである。本処理２００は使用状況データが更新される都度、あるいは非同期型使用状況モニタリング（図１４参照）の場合は、現区間の使用状況データが確定する都度、実行すればよい。この場合、使用状況モニタリングの実行周期（現区間の使用状況データ更新周期）と購買期待度算出処理の実行周期（購買期待度の更新周期）は同一になる。所望であれば、同一でない形態も容易に実施できる。
【００３３】
たとえば、アプリケーションソフトウェアが一般業務用ソフトウェアである場合には、休日について（あるいは午後８時から午前８時までのような非営業時間帯）は、その使用状況のモニタリング結果が購買期待度と相関性をもたないと予想される。したがって、このような場合、休日等の非営業時間帯は使用状況モニタリング自体を実施しないか、使用状況のモニタリングは実施してもそのモニタリング結果は購買期待度の算出から除外することが多くの場合、好ましい。この種の時間帯における使用状況データの反映を禁止または弱める手法としては、使用状況モニタリングを一時的に中断する方法と、購買期待度算出処理側で、この種の時間帯における使用状況データのモニタリング結果を無視するか低く見積もる方法が考えられる。また、好ましい方法としてモニタリング結果の時系列に対して「移動平均」などの統計処理を行うことが考えられる。
【００３４】
一般にユーザは、購買意欲は変わらないまま、都合によりアプリケーションソフトウェアの使用を一時的に中断することが日常的である。一方で、使用状況モニタリングを一日よりも十分に短い周期（たとえば３０分毎）でモニタリングする場合、時間区間ごとの変動が大きいことや、局部的にある時間区間では使用していない状況がありえる。一方で、購買意欲を急になくしてアプリケーソンソフトウェアの使用を止めることもあり得る。ある短い区間の間、アプリケーションソフトウェアを使用していないという事実だけでは、その不使用の理由（購買意欲を急に失ったからなのか、それとも都合により中断しているだけなのか）を知るすべがない。このような点にも配慮した適切な購買期待度の推定（算出）が望ましい。１つの有効な算出手法は、比較的長い区間（たとえば、７２時間）について使用状況データを集計し、集計結果に基づいて（あるいは同様に長い区間ごとに使用状況をモニタリングし、その結果である現区間の使用状況データに基づいて）、購買期待度を算出する方法である。
【００３５】
購買期待度算出処理２００を実現するための、複数種類の実施形態を図１５から図２１に示す。図１５は、現区間の使用状況データを取得し（１５−１）それに基づいて購買期待度を求める（１５−２）ようにした形態２００Ａである。ステップ１５−１で取得する現区間の使用状況データとしては、使用状況モニタリング１００によって使用履歴スタック１００ｍ（図９）の「現区間」にセットされたデータを使用できる。ただし、使用履歴スタック１００ｍの一区間の長さが短い場合（たとえば一時間毎の場合）には、適当な複数の区間（たとえば７２時間分）に渡って使用状況データを集計し、集計結果を、１５−１でいう「現区間の使用状況データ」とすることができる。これは、モニタリングした使用状況データの時系列に対して「移動平均」をとっていることと均等である。
【００３６】
図１６に示す形態２００Ｂは、使用履歴データを使用履歴スタックから取得し（１５−１）、履歴重みパターンを読み出し（１６−２）、履歴重みパターンと使用履歴データとを積和演算して購買期待度を算出する（１６−３）。１６−２で読み出す履歴重みパターン（時間関数）の具体例を図１７に示す。ここでは、履歴重みパターンは過去に向かって減少する減少関数となっているが、これに限定されるものではない。したがって、ステップ１６−３で行なっている処理は使用状況データの時系列に対して重み付け移動平均をとることと均等である。
【００３７】
履歴重みパターン関数はたとえば、次のようにして作成することができる。時間帯（たとえば、夜間、曜日）によって使用期待度が変動するパターンが認められる場合、このような変動を表わす時間関数を第１の関数として用意しておき、それに現時点からの時間差に応じて減少するグローバル減少関数を第２の関数として用意しておき、第１と第２の関数を合成（たとえば乗算あるいは加算）することによって、履歴重みパターンを作成するようにしてもよい。
【００３８】
上記形態２００Ａと２００Ｂでは、使用履歴スタック１００ｍ（図９）に蓄積した使用履歴データのみから購買期待度を算出した。
【００３９】
実施形態によっては、購買期待度の算出に、使用状況データのみならず他の変数を加味することができる。
【００４０】
図１８に示す形態２００Ｃはその一例であり、顧客情報データベース７２にある顧客に割り当てた重みデータ（顧客重みデータ）を他の変数として購買期待度の算出に使用している。すなわち、各ユーザＩＤについて、顧客情報データベース７２からそのユーザＩＤに係る重みデータＷ（ＩＤ）を取得し（１８−２）、各ユーザＩＤについて、使用状況データと顧客重みデータＷ（ＩＤ）とを用いて、そのユーザの購買期待度（ＩＤ）を演算する（１８−３）。演算式としては、たとえば、重みデータを係数（乗数）として、
購買期待度（ＩＤ）＝使用状況データ（ＩＤ）×顧客重みデータＷ（ＩＤ）
が使用できる（１８−３）。あるいは、重みデータを
購買期待度（ＩＤ）＝使用状況データ（ＩＤ）＋顧客重みデータＷ（ＩＤ）
のように、バイアス変数として使用してもよい。あるいは、右辺に示す２つの式の線形結合式を購買期待度（ＩＤ）として求めてもよい。すなわち、
購買期待度（ＩＤ）＝２つの式の線形結合式
＝ａ×使用状況データ（ＩＤ）×顧客重みデータＷ（ＩＤ）＋
ｂ×顧客重みデータＷ（ＩＤ）
【００４１】
顧客情報データベース７２の顧客重みデータは、試用アプリケーションソフトウェアの使用状況データとは別に、顧客の購入意欲に相関すると期待されるデータであればよく、たとえば、過去のユーザの同種アプリケーションソフトウェアの購入実績、および／またはインターネット上のフェースブックやツイッタなどにおいて試用アプリケーションソフトウェアに関してユーザが投稿した件数などを反映した値をもたせることができる。
【００４２】
図１９に示す形態２００Ｄは、移動平均をとる形態２００Ｂと顧客重みデータを顧客期待度に反映させる形態２００Ｃとを組み合わせたものである。すなわち、１６−１、１６−２、１９−３により、使用状況データの時系列に対して重み付け移動平均をとったものをユーザＩＤの使用状況データ（ＩＤ）とし、後は、図１８の場合と同様に、使用状況データ（ＩＤ）と顧客重みデータＷ（ＩＤ）とを演算して購買期待度を求めている（１８−３）。
【００４３】
図２０に示す形態２００Ｅは、図１８の形態２００Ｃ（顧客重みデータを参照する形態）を変形したもので、顧客重みデータをそのまま使用するのではなく、顧客重みデータＷ（ＩＤ）の増加関数を決定し（２０−３）、それを購買期待度の算出における重みデータ（係数またはバイアスまたはその組み合わせ）として使用する（２０−４）ようにしたものである。増加関数としては適当な任意の増加関数が使用でき、たとえば、
ＦＵＮＣ（Ｗ（ＩＤ））＝Ｗ（ＩＤ）＋１、
ＦＵＮＣ（Ｗ（ＩＤ））＝Ｗ（ＩＤ）＋ｋ（ただし、ｋは変数）、
ＦＵＮＣ（Ｗ（ＩＤ））＝ｋ１＊Ｗ（ＩＤ）＋ｋ２（ただし、ｋ１、ｋ２は変数）、
その他、顧客重みデータＷ（ＩＤ）の対数関数などが考えられる。
【００４４】
図２１に示す形態２００Ｆは、図１９の形態（第１から第３のステップ１６−１、１６−２および１９−３に関して）と図２０の形態２００Ｅ（第４から第６のステップ１８−２、２０−３、２０−４に関して）を組み合わせたものである。すなわち、各ユーザＩＤについて使用状況の時系列の移動平均を取り、それを改めて「使用状況データ（ＩＤ）」として、顧客情報データベース７２の顧客重みデータＷ（ＩＤ）の増加関数ＦＵＮＣを求め、移動平均である使用状況データ（ＩＤ）と顧客重みデータの増加関数とを演算して購買期待度（ＩＤ）を算出する。
【００４５】
＜仮想リソース割当処理３００＞
仮想リソース割当処理３００は購買期待度に基づいて仮想サーバ３６に割り当てる仮想リソース（仮想サーバ用ＣＰＵ、仮想サーバ用メモリ、帯域に関連する仮想サーバ用ネットワーク、仮想サーバ用ストレージ）の範囲を決定する処理である。本処理３００は購買期待度が更新される都度、実行すればよい。この場合、購買期待度算出の実行周期（購買期待度更新周期）と仮想リソース割当処理の実行周期（仮想リソース域更新周期）は同一になる。所望であれば、周期が同一でない形態も可能である。
【００４６】
仮想リソース割当処理３００の２つの実施形態を図２２と図２３に示す。図２２に示す仮想リソース割当処理３００Ａにおいて、ＰＥ物理サーバ５０は、動的トライアル制御システム５２の制御の下に、各ユーザＩＤについて購買期待度（ＩＤ）を取得する（２２−１）。これは購買期待度算出処理２００の処理結果を読むことで行なわれる。次に、各購買期待度（ＩＤ）を正規化して割当比（ＩＤ）を求める（２２−２）。次に、各割当比（ＩＤ）について、各仮想のリソースの容量から、すなわちＡＰ物理サーバ３０において利用可能な各物理リソースの容量から、リソースの種類ごとに、該当する仮想サーバ３６（ユーザＩＤに係る仮想サーバ）に割り当てるべきリソース割当サイズ（ＩＤ）を決定する（２２−３）。最後に（２２−４）、ＰＥ物理サーバ５０は処理結果であるリソース割当サイズ（ＩＤ）を含む情報をＶＳ物理サーバ４０に渡し、ＶＳ物理サーバ４０はＶＳマネージメントシステム４２の制御の下に、リソース割当サイズ（ＩＤ）に基づいた割当オペレーションを、ＡＰ物理サーバ３０を通じて実施する。
【００４７】
図２３に示す仮想リソース割当処理の実施形態３００Ｂでは、動的リソース割当の結果によらず、各仮想サーバ３６にあるアプリケーションソフトウェア３８をユーザがインターネット経由で使用する際に、支障がないように、仮想リソース割当処理３００Ｂで実施される割当リソースサイズの下限と上限をアプリケーションソフトウェア３８に関連付けて規制している（２２−３、２３−４）。すなわち、「下限」未満のリソース割当は回避されるので、アプリケーションソフトウェアの使用環境として許容される最低環境以上での使用が保証される。また、「上限」を超えるリソース割当も回避されるので、限られた物理リソースに対する無駄使いが規制され、アプリケーションソフトウェアの使用環境として許容される最高環境以上での使用が防止される。以上により、アプリケーションソフトウェア３８の使用環境を確保しながら、ＡＰ物理サーバ３６が有する限られた物理リソースを有効利用するツールが実現される。
【００４８】
＜顧客重みデータ更新＞
本発明に係るトライアル環境システムは、有限の物理リソースを有する物理サーバ上に展開される複数の仮想サーバにあるアプリケーションを複数のユーザ（個々の仮想サーバが割り当てられたユーザ）がインターネットを通じて試用するものである。本発明は、各仮想サーバに割り当てられるリソースの容量をユーザの使用状況等（「購買期待度」）に基づいて動的に調整することを本質としている。このために、購買期待度算出処理２００においてはモニタリングによって取得したユーザの使用状況に基づいて購買期待度を算出している。いくつかの実施形態において、ユーザの購買期待度はユーザによるアプリケーションソフトウェアの使用状況のみから算出することができる（図１５、図１６参照）。別のいくつかの実施形態において、ユーザの購買期待度は、ユーザによるアプリケーションソフトウェアの使用状況のみならず、当該ユーザに固有の情報（顧客重みデータ）をも参照して算出することができる（図１８−図２１）。後者の形態は、顧客重みデータＷ（ＩＤ）が「購買期待度」と相関性をもつと期待される限りにおいて有効である。したがって、ユーザにより購買期待度と相関性を持つ行為がなされた場合に、顧客重みデータをその行為に合わせて更新することが望ましい。
【００４９】
顧客重みデータの更新処理の一形態を図２４に４００で示す。この形態４００は、アプリケーションソフトウェアの売買契約が成立したか不成立に終わったかによって、顧客重みデータを更新するものである。まず、営業サーバ６０は、ポインタＰで最初のユーザＩＤを指定し（２４−１）、そのユーザＩＤについて契約が成立したかどうか（契約成立フラグ（Ｐ）が立っているかどうか）をみる（２４−２）。契約が成立していれば、そのユーザＩＤの顧客重みデータ（ＩＤ）をインクリメントする（２４−３）。これに関連し、購買期待度算出処理において顧客重みデータを乗数（たとえば、使用状況データに対する乗数）として使用する形態（たとえば、図１８の形態）の場合には、顧客重みデータ（ＩＤ）に上限をつけることが望ましい。なお、購買期待度算出処理において顧客重みデータをバイアス（たとえば、使用状況データに対する加減数）として使用する形態の場合には、原則、上限のクリップ処理は不要である。次に契約成立フラグ（Ｐ）をリセットし（２４−４）、次のパスの判定ステップ２４−２で再びＹＥＳが返されないようにする。判定ステップ２４−２でＮＯのときは、契約の不成立が確定したかどうか（契約不成立フラグ（Ｐ）が立っているかどうか）をみる（２４−５）。契約不成立であれば、そのユーザＩＤの顧客重みデータ（ＩＤ）をデクリメントする（２４−４）。これに関連し、購買期待度算出処理において顧客重みデータを乗数（たとえば、使用状況データに対する乗数）として使用する形態（たとえば、図１８の形態）の場合には、顧客重みデータ（ＩＤ）に下限をつけることが望ましい。なお、顧客重みデータをバイアス（たとえば、使用状況データに対する加減数）として使用する形態の場合には、原則、下限のクリップ処理は不要である。２４−８でポインタＰの指すユーザＩＤの次のユーザＩＤがなければ処理を終了し、あれば、Ｐで次のユーザＩＤを指定して（２４−９）、契約成立判定ステップ２４−２に戻る。
【００５０】
顧客重みデータ更新処理の別形態では、インターネット上のアプリケーションソフトウェアに関する掲載件数をユーザに関連付けて収集し、掲載件数の多いユーザについてそのユーザ（ユーザＩＤ）に係る顧客重みデータを掲載件数に応じてインクリメントする。なお、この顧客重みデータは第２種の顧客重みデータとして記憶、管理するのが好ましい。この場合、図２４に関して述べた、顧客の購買実績に係る顧客重みデータは第１種の顧客重みデータとして記憶、管理される。購買期待度を算出するに際して、第１種と第２種の顧客重みデータを合成して顧客重みデータＷ（ＩＤ）として使用することができる。その他、複数種類の顧客重みデータを用意してもよい。別の実施形態において、第１種の顧客重みデータを図２０などでの顧客重みデータＷ（ＩＤ）として使用し、第２種、第３種などの顧客重みデータは、重みデータの増加関数ＦＵＮＣ（Ｗ（ＩＤ））を算出する際に（たとえば、２０−３参照）、引数（段落００４３で述べたｋ１、ｋ２あるいはｋなど）として使用することができる。
【００５１】
＜営業支援＞
いくつかの実施形態を通じて説明した本発明に係るトライアル環境システムの処理結果（使用履歴スタックの内容、購買期待度）は、営業活動に有益な情報（営業情報）として営業担当者に知らせることにより営業支援システム１０が構築される。以下、営業支援に関して説明する。
【００５２】
＜ユーザの使用リスト更新＞
営業支援システム１０は、ユーザの使用リストを営業端末に通知することができる。ユーザの使用リストはたとえば、図２６に示すような形式である。図示のように、ユーザの使用リスト５００ｍは、複数の行が複数のユーザ名に対応し、複数の列が購買期待度、現使用状況など複数の属性に対応している表形式である。
【００５３】
ユーザの使用リスト更新処理の形態を図２５に参照符合５００で示す。営業サーバ６０に接続された処理装置（図示せず）は、図示しない制御プログラムの制御の下に、ユーザの使用リスト更新処理５００を実行する。この処理による更新周期は購買期待度算出処理２００による購買期待度の更新周期と同一であってよい。このことは、たとえば、購買期待度算出処理２００は購買期待度を更新した際に更新フラグをセットし、このフラグ情報を使用リスト更新処理が参照することで実現できる。なお、所望であれば、両者の更新周期は同一でなくてもよい。
【００５４】
図２５において、まず、購買期待度が更新されていなければ（２５−１）そのまま終了する。購買期待度が更新されていれば、営業サーバ６０からユーザの使用リスト４００ｍ（たとえば、ウェブページで構成される）をダウンロードする（２５−２）。次に、各ユーザＩＤ（ここに、ユーザＩＤは、使用リスト上はユーザ名で表記されて関連付けられている）の購買期待度データを購買期待度算出処理の処理結果メモリから読み込む（２５−３）。次に、読み取った各購買期待度データによりユーザの使用リスト５００ｍを更新する（２５−４）。次に各ユーザＩＤの使用履歴データを使用履歴スタック１００ｍから読み出す（２５−５）。次に、各ユーザＩＤの使用履歴データからユーザ名ごとに使用履歴棒グラフ（使用の履歴を表わした画像）を作成し、使用リストにおける該当するユーザ名に関連付ける（２５−６）。最後に更新結果（更新した使用リスト及びユーザ名ごとに関連する使用履歴棒グラフ）を営業サーバ６０にアップロードする（２５−７）。
【００５５】
＜営業端末への通知＞
営業端末１４から営業サーバ５６にアクセスされている間、営業サーバ５６は営業端末からの要求に応じて、関連する情報を営業端末１４に通知（表示）する。ユーザの使用リストに関連する営業端末への通知処理についていくつかの形態を図２７から図２９に示す。図２７の営業端末への通知処理６００Ａにおいて、営業端末１４ユーザの使用リストが表示中であれば（２７−１でＹＥＳ）、営業サーバ５６は、特定のユーザ名がクリックされたかどうかを判定し（２７−２）、ユーザ名がクリックされたならば、そのユーザ名の使用履歴棒グラフをユーザ名の位置に関連付けて吹き出しで表示する（２７−３）。図２を参照すると、吹き出しで表示される使用履歴棒グラフの例を営業端末１４の位置に示してある。
【００５６】
図２８は営業端末への通知処理の別形態６００Ｂである。この形態６００Ｂでは、使用リストのうちで、所定の使用条件を満たす使用状況データを有するユーザ名を特定し、それらのユーザ名からなる使用リスト（使用サブリスト）を表示するようにしている（２８−５）。スクリーニング表示ステップ（２８−５）の起動は表示されているユーザの使用リスト５００ｍから、「現使用状況」のボタンがクリックされることで行なってよい（２８−４）。２８−５の処理は一種のスクリーニングであり、スクリーニングの方法は様々な態様が容易に実現できる。たとえば、使用状況データが上位１０％のユーザをスクリーニングする、使用状況データで上位１０人のユーザをスクリーニングする、使用状況データの値が条件値を超えるユーザをスクリーニングするなどが実現できる。また、スクリーニング結果をカラーで識別表示（色分け表示）することも容易である。
【００５７】
図２９は営業端末への通知処理のさらに別の形態６００Ｃである。この形態６００Ｃでは、ユーザの使用リスト５００ｍのうちで、所定の購買期待度条件を満たす購買期待度を有するユーザ名を特定し、それらのユーザ名からなる使用リスト（使用サブリスト）を表示するようにしている（２９−５）。スクリーニング表示ステップ（２９−５）の起動は表示されているユーザの使用リスト５００ｍから、「購買期待度」のボタンがクリックされることで行なってよい（２９−４）。２９−５の処理は一種のスクリーニングであり、スクリーニングの方法は様々な態様が容易に実現できる。たとえば、購買期待度が上位１０％のユーザをスクリーニングする、購買期待度で上位１０人のユーザをスクリーニングする、購買期待度の値が条件値を超えるユーザをスクリーニングするなどが実現できる。また、スクリーニング結果をカラーで識別表示（色分け表示）することも容易である。
【００５８】
また、形態６００Ｂの使用状況によるスクリーニング機能と形態６００Ｃによる購買期待度によるスクリーニング機能を組み合わせた形態も容易に実現できる。
【００５９】
図３０に仮想サーバへの登録の際の手続を示す。黒ドットで示す各主体は、人間（見込み客、営業担当者）を除けば、コンピュータを制御する「プログラム」によって実現される。図３０に記載した主体間のデータないし指令の受け渡しの関係の時系列情報から、本書を読んだ当業者には容易に各主体のプログラムを実装することができる。
【００６０】
図３１に仮想サーバを使用中の際の手続を示す。黒ドットで示す各主体は、人間（見込み客、営業担当者）を除けば、コンピュータを制御する「プログラム」によって実現される。図３１に記載した主体間のデータないし指令の受け渡しの関係の時系列情報から、本書を読んだ当業者には容易に各主体のプログラムを実装することができる。
【００６１】
図３２にサーバ（図６の各種サーバ３０、４０、５０、６０）として使用できるコンピュータ（「サーバコンピュータ」）の代表的なハードウェア構成を示す。サーバコンピュータ１０００は、ＣＰＵ１０１０、プログラム記憶装置１０１２、データベース（ＤＢ）記憶装置１０１４、作業メモリ１０１６、入力装置１０１８、表示装置１０２０、通信インタフェース１０２２を備え、これらはシステムバスを介して相互に接続されている。プログラム記憶装置１０１２はＣＰＵ１０１０を制御するための各種プログラム（各フローチャートで示したプログラムを含む）を記憶するためのものである。ＣＰＵ１０１０はプログラム記憶装置１０１２に記憶されたプログラムの制御の下に動作して、各フローチャートで示したように動作する。データベース記憶装置１０１４は当該サーバコンピュータ１０００に関連するデータベースを記憶する。外部との情報のやり取りは通信インタフェース１０２２を介して行なわれる。なお、図３２に示したサーバコンピュータ１０００と図６のＰＥ物理サーバ５０との対応関係を説明すると、図６におけるＰＥ物理サーバ５０および関連する動的トライアル制御システム５２を含んだ機能が、サーバコンピュータ１００によって実現される。同様に、図６における営業物理サーバ６０および関連する営業データ７０を含んだ機能が、同一又は他のサーバコンピュータ１００によって実現される。
以下、同様であり、たとえば、図６におけるＡＰ物理サーバ３０、その仮想サーバ３６、ＶＳ物理サーバ４０および関連するＶＳマネージメントシステム４２が１または複数のサーバコンピュータ１０００によって実現される。以上、説明の便宜上、対応関係について一応説明したが、当業者には明らかなように、上記の対応関係に限定されず、他の対抗関係で実施可能であることは自明である。
【００６２】
段落００３３において、時間帯によっては、その使用状況のモニタリング結果が購買期待度と相関性をもたない可能性を取り上げた。そして、かような時間帯に対しては、使用状況モニタリング自体を実施しないか、使用状況のモニタリングは実施してもそのモニタリング結果は購買期待度の算出から除外することを提案した。また、この種の時間帯における使用状況データの反映を禁止または弱める手法としては、使用状況モニタリングを一時的に中断する方法と、購買期待度算出処理側で、この種の時間帯における使用状況データのモニタリング結果を無視するか低く見積もる方法が考えられるとした。以下では、具体例として、アプリケーションソフトウェアが置かれている物理サーバに対する総アクセス量である、全ユーザに係るトラフィック量をモニターして、時間帯による変動を把握し、時間帯毎のトラフィック量に応じて、各ユーザの各時間帯における使用状況データを再評価する形態を説明する。
【００６３】
図３３にＰＥ物理サーバ５０が実施するトラフィックモニタリング７００の動作フローを示す。なお、以下では、ＰＥ物理サーバ５０および関連する動的トライアル制御システム５２を含んだ機能が、サーバコンピュータ１００によって実現されるものとして、図３２を参照しつつ動作を説明する。まず、最初のステップ３３−１で、サーバコンピュータ１０００内のＣＰＵ１０１０は、プログラム記憶装置にあるプログラムの制御の下に、全ユーザによるトラフィック量をモニターする。これは、たとえば、使用状況モニタリング１００（１００Ａ−１００Ｆ）のモニタリング結果である使用履歴スタック１００ｍ（図９）から現区間にあるデータを全ユーザのＩＤについて、集計することで実現できる。なお、使用履歴スタック１００ｍは作業メモリ１０１６上に置かれてよい。次のステップ３３−２で、ＣＰＵ１０１０はプログラムの制御の下に、トラフィック履歴スタック（同様に作業メモリ１０１６上に置かれてよい）の現区間にトラフィックのモニター結果をセットする。トラフィック履歴スタックが示すトラフィック量の時間プロファイルの具体例を図３５に示す。次のステップ３３−３で、ＣＰＵ１０１０はプログラムの制御の下に、基準とするトラフィック量を取得する。ここでは、基準とするトラフィック量として、「移動平均」のトラフィック量を求めている。これはトラフィック履歴スタックを参照することで容易に算出できる。なお、基準とするトラフィック量として、必ずしも「移動平均」のトラフィック量である必要は無く、所望であれば、「重み付け移動平均」のトラフィック量であってもよいし、その他、トラフィックに関連する任意の適当な統計量が使用できる。次のステップ３３−４で、ＣＰＵ１０１０はプログラムの制御の下に、正規化係数を算出する。これは、たとえば、現区間のトラフィック量を基準のトラフィック量（たとえば、「移動平均」のトラフィック量）で正規化することで実現できる。最後のステップ３３−５で、ＣＰＵ１０１０はプログラムの制御の下に、算出した正規化係数を正規化履歴スタック（同様に作業メモリ１０１６上に置かれてよい）の現区間にセットする。
【００６４】
図３４にＰＥ物理サーバ５０が実施する使用履歴スタックの正規化処理８００の動作フローを示す。具体的には、図６で述べた機能５０および５２が図３２に例示するようなサーバコンピュータ１０００で実現されたものとして説明する。最初のステップ３４−１で、ＣＰＵ１０１０はプログラムの制御の下に、使用履歴スタック１００ｍ（図９参照）を読み出す。次のステップ３４−２で、ＣＰＵ１０１０はプログラムの制御の下に、使用履歴スタック１００ｍの各要素（各区間の使用状況データ）を正規化履歴スタック（図３３のフローにより算出済み）の各要素（各区間の正規化係数）に対応付け、各区間の使用状況データおよび区間長（たとえば３０分間、６０分間など）を対応付けた正規化係数で正規化する。その結果は、正規化使用履歴スタックとして定義される（３４−３）。
【００６５】
このような正規化使用履歴スタックは、購買期待度算出処理３００のなかで、使用履歴スタック１００ｍ（図９）の代わりに使用することができる。結果として、特殊な時間帯における使用状況データの反映を禁止または弱める手法が実現される。図３５は、図３２−図３４で述べた正規化処理を説明する図である。図３５には、トラフィック量を評価した正規化係数により、使用状況データ（ここでは、区間長、使用時間、アクセス回数）が再評価される様子が示されている。使用状況データの属性である区間長を正規化係数で正規化することにより、時間軸の圧縮、伸長を実現できる。その他、詳細については、図３５自体から自明であるので、これ以上の説明は省略する。トラフィックモニタリングを利用した使用状況データの再評価の手法（図３２−図３５）は、個々のアプリケーションソフトウェアの特殊性を考慮する必要がない点で、汎用性がある。また、個々のユーザの使用状況データを集計することでトラフィック量が求められるので、プログラム的に無駄がなく、実施が容易である。また、トラフィック量は様々な要因で時間的に変動すると考えられるが、計測したトラフィック量の時間プロファイル（トラフィック履歴スタックの内容）を基にして定められるトラフィック量を基準とすることにより、各区間の使用状況データ等に対して適切な正規化が実現できる。また、トラフィック量が多いときにアプリケーションソフトウェアを試用しているユーザ（いわば、魚群の濃い場所にいるユーザ）に対して有利にリソースを割り当てることが可能となる（多数派優先機能）。また、購買期待度の時間プロファイルを円滑化できる。
【００６６】
なお、トラフィック量の時間プロファイルと個々のユーザの使用履歴データとの「相関度」を算出するプログラムを用意してもよい。ユーザによっては、他のユーザとは逆の行動パターン（試用パターン）をとる人もいるが、この種のユーザ（ユーザＩＤ）は低い「相関度」によって特徴付けることができ、相関度算出プログラムによって検出可能である。所望であれば、検出した対象ユーザＩＤには、正規化していない使用履歴スタック（図９）の内容に基づいて、リソースを割り当てるようにしてもよい（少数派補償機能）。
【００６７】
以上で、実施形態の説明を終えるが、実施形態はもっぱら例示を目的とするものであり、本発明を制限することを意図していない。たとえば、１つの仮想サーバに置かれるアプリケーションソフトウェアをグループウェアとして使用する場合には、通常、試用契約の組織に属する複数のメンバーが固有のメンバーＩＤで同一アプリケーションソフトウェアを共用することになり、このようなグループウェアの場合にも本発明を適用できることはいうまでもない。この場合、実施形態で述べたユーザＩＤはグループウェアの試用契約に係るメンバーＩＤのセットで構成されることになる。また、図示実施形態においては、各ユーザＩＤについて、使用状況データ、必要に応じて顧客重みデータを加えた１ないし多変数入力（「使用状況データ等」）からそのユーザの購買期待度を数値として明に算出し、算出した購買期待度の数値に合わせて仮想サーバに対する物理リソース（コンピュータ資源）の割り振りないし占有率を調整しているが、これには限られない。すなわち、「使用状況データ等」からユーザＩＤごとに優先順位を付け、優先順位に従って各仮想サーバの物理リソース割当率ないし占有率（物理リソース割当量）を決定するような構成も本発明の範囲に属するものである。なぜならば、かかる構成にも、使用状況データ等に基づいてユーザの購買期待度を「順位の形式」で決定した結果が優先順位となって現れているからである。なお、優先順位に従って各仮想サーバの物理リソース割当量を決定するコンピュータプログラムは当業者にとって自明である。また、動的トライアル環境システム部（図７）の少なくとも一部において、たとえば購買期待度算出部２００において、メンバーシップ関数を使用するファジー演算を少なくとも部分的に利用した形態が実現可能である。また、購買期待度算出部が算出する購買期待度は単一の数値で表現した購買期待度である必要は無く、確率密度関数形式で表現した購買期待度であってもよい。この場合、採用する確率密度関数として任意の適当な関数が使用でき、たとえばガウス分布関数（正規分布）を使用した場合であれば、中心値と分散により購買期待度を定義できる。たとえば、「中心値」には、図示実施形態で述べたような購買期待度を代入し、分散は適当な分散要因、たとえば、使用状況データの時間的変動などに基づいて決めることができる。確率密度関数形式の購買期待度からリソース割当量を決定する形態では、適当なタイミングで、たとえばリソース割当動作（３００）の都度、適当な乱数を生成して購買期待度を表現した確率密度関数のなかから物理リソースの割当に適用する数値を選択し、後は、図示実施形態（図２２、図２３）のようにして各ユーザＩＤについて、仮想サーバに割り当てるリソース量を決定することができる。以上のように、本発明は説明した実施形態には限定されず、本発明の範囲内で種々変更が可能である。したがって、本発明の範囲は添付する特許請求の範囲の記載に基づいて定められるべきものである。
【００６８】
以上の説明から明らかなように、本発明の特徴の一は、仮想マシンをユーザＩＤに割り当てて仮想マシン上のアプリケーションをユーザに試用させるトライアル環境システムにおいて、アプリケーションソフトウェアに対する使用状況をモニターする点にある。ここにおいて、アプリケーションソフトウェアに対する使用状況というものは、アプリケーションソフトウェアの実行によって実際に仮想マシンで使用されている物理リソース量とは似て非なる概念である。なぜならば、前者はユーザの購買期待度と相関性を有するのに対して、後者（仮想マシンで使用される物理リソース量）は、第一義的に、アプリケーションソフトウェアの種類や実行中のアプリケーションソフトウェア部分（たとえば、多くのメモリやデータ処理量を必要とするソフトウェア部分、あるいは所要メモリ量やデータ処理量が少ないソフトウェア部分）に依存する性質をもつにすぎないからである。また、後者がマシン寄りの低レベル情報であるのに対して前者はユーザに係る高レベル情報であって、レイヤーが異なっている。したがって、後者による実際の物理リソース使用量からはアプリケーションソフトウェアに対するユーザの購買期待度情報は得られない。これに対して、本発明の場合、アプリケーションソフトウェアに対するユーザの使用状況をモニターしているので、モニターした使用状況と購買期待度とは相関関係を有し、それにより、モニターした使用状況に基づいてユーザ（アプリケーションソフトウェア試用者）の購買期待度を算出することが可能になる。また、特定の実施形態では、アプリケーションソフトウェアの使用状況のみならず、ユーザの購買期待度と相関性を有する顧客重み情報をも考慮して購買期待度を算出している。この形態の場合も、ユーザの購買期待度を求めることができる。結果として、本発明の場合、トライアル環境システムの提供者やアプリケーションソフトウェアのプロバイダは、低いランニングコストで、より多くの購買者を獲得するという可能性が高められる。
【００６９】
以下、付記について記載する。なお、付記において参照符号を括弧書きで記入しているとともに付記の横に図番、段落等を記載しているが、開示の裏づけを示したもので、本発明の範囲を限定することを意図していない。
付記Ｃ１：図６、図７
インターネット（２０）に接続される複数の仮想サーバ（３６）、
各仮想サーバには、ユーザにより試用されるアプリケーションソフトウェア（３８）が置かれること、
各仮想サーバにはそれぞれのユーザＩＤが割り当てられること、
複数の仮想サーバは有限リソースの物理サーバ（３０）に基づいて構築されるものであること、
端末（１２）およびインターネットを介した、各ユーザによるアプリケーションソフトウェアの使用状況をモニターする使用状況モニター（５４；１００）、
モニターしたユーザ毎の使用状況に基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する購買期待度算出手段（５６；２００）、
物理サーバの有限リソースの制約下において、各仮想サーバに割り当てる仮想リソース領域を、算出した購買期待度に基づいて動的に調整する仮想リソース動的割り当て手段（５８；３００）、
を備える、インターネット経由で試用されるアプリケーションソフトウェアのトライアル環境システム。
効果：低コストでトライアル環境システムを提供することができる。同時に、購買意欲のあるユーザは快適な動作環境でアプリケーションソフトウェアを使用できる。
付記Ｃ２：図８−１３
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間の使用状況を表わす数値データ（「現使用状況データ」）を取得して購買期待度算出手段に供給する、付記Ｃ１に記載のトライアル環境システム。
効果：区間毎の使用状況を把握できる。
付記Ｃ３：図８−１３
使用状況モニター（１００）は、現使用状況データを定期的に取得する（１００Ａ；１００Ｂ；１００Ｃ；１００Ｄ；１００Ｅ）、付記Ｃ２に記載のトライアル環境システム。
効果：使用状況モニタリングが容易に実現できる。
付記Ｃ４：段落００２５ 
使用状況モニターが取得する現使用状況データの取得間隔は一秒から三日の範囲内である、
付記Ｃ３に記載のトライアル環境システム。
効果：比較的低速の使用状況モニタリングで足りる。
付記Ｃ５：図１５（図１７−２１も同様）
購買期待度算出手段（２００）は、現使用状況データにより購買期待度を算出する（２００Ａ）、付記Ｃ２からＣ４のいずれか一項に記載のトライアル環境システム。
効果：購買期待度に合わせたリソース割当が容易に実施できる。
付記Ｃ６：図９、「集計＝移動平均」、図１６など
購買期待度算出手段（２００）は、過去の複数の区間での使用状況データ（「過去使用状況履歴データ」）を蓄積する記憶手段（１００ｍ）を含み、過去使用状況履歴データと現使用状況データとから購買期待度を算出する（２００Ｂ）、付記Ｃ２から付記Ｃ４のいずれか一項に記載のトライアル環境システム。
効果：購買期待度の平滑化が実現容易になる。
付記Ｃ７：図８、図１０、図１２
使用状況モニター（１００）は、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する（Ａ）アクセス回数、（Ｂ）使用時間、（Ｃ）使用段階、および（Ｄ）これらの組み合わせからなる群のなかから選択されたものを取得する（１００Ａ，１００Ｂ、１００Ｄ）、付記Ｃ１に記載のトライアル環境システム。
各種使用状況を選択しえる。
付記Ｃ８：図１３および関連説明（段落００３０）
使用状況モニター（１００）は、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する（Ａ）アクセス回数、（Ｂ）使用時間、（Ｃ）使用段階のうち２以上からなるもの（「複数種類の現使用状況データ」）を取得し、
購買期待度算出手段は、複数種類の現使用状況データを演算して１つの数値データに変換する手段を含む、付記Ｃ１に記載のトライアル環境システム。
複数種類の使用状況データを取得できる。
付記Ｃ９：図６、図１８−２１
ユーザＩＤ毎の購買重みデータ（Ｗ（ＩＤ））を蓄積した購買重みデータベース（７２）をさらに備え、
購買期待度算出手段（２００）は、モニターしたユーザ毎の使用状況とユーザ毎の購買重みデータとに基づいて、アプリケーションソフトウェアに対する各ユーザの購買期待度を算出する（２００Ｃ；２００Ｄ；２００Ｅ；２００Ｆ）、
付記Ｃ１に記載のトライアル環境システム。
効果：使用状況のみならず、購買期待度と相関性のある情報（購買重みデータ）にも配慮した購買期待度が得られる。
付記Ｃ１０：図２３
仮想リソース動的割り当て手段（３００）は、ユーザＩＤ毎に割り当てられる仮想リソースの容量がアプリケーションソフトに関連付けた下限を下回らず、かつアプリケーションソフトに関連付けた上限を上回らないように確保する仮想リソースソース確保手段（２３−４、２３−５）を含む（３００Ｂ）、付記Ｃ１に記載のトライアル環境システム。
効果：アプリケーションソフトウェアを使用する際のトライアル環境を整備できる。
付記Ｃ１１：図２７−２９
付記Ｃ１からＣ１０のいずれか一項に記載のトライアル環境システムと、
使用状況モニターのモニター結果および／または購買期待度算出手段の購買期待度算出結果に基づいた営業支援情報を営業ＩＤが入力された端末（「営業端末」）に通知する通知手段（６００Ａ；６００Ｂ；６００Ｃ）と、を備える営業支援システム（１０）。
効果：過剰なリソース（コンピュータ資源）を費やすことなく、トライアル中のユーザに対して適切な営業活動が可能になり、低コストの営業支援システムを提供できる。
付記Ｆ１：段落００２５
使用状況モニターが取得する現使用状況データの取得間隔は３０分から一日の範囲内である、付記Ｃ４に記載のトライアル環境システム。
効果：使用状況モニタリング処理経費が低コストになる。
付記Ｆ１：図８
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対するアクセス回数を取得する（１００Ａ）、付記Ｃ１に記載のトライアル環境システム。
効果：アプリケーションソフトウェアの属性に依存しない汎用性がある。
付記Ｆ２：図１０
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する使用時間を取得する（１００Ｂ）、Ｃ１に記載のトライアル環境システム。
効果：汎用性がある
付記Ｆ３：図１１
使用状況モニターは、各ユーザによるアプリケーションソフトウェアの使用状況として、現区間におけるアプリケーションソフトウェアに対する使用時間およびアクセス回数を取得する（１００Ｃ）、付記Ｃ１に記載のトライアル環境システム。
効果：汎用性がある。
付記Ｆ４；図１４
使用状況モニターは、仮想サーバに係る特定のイベントの発生に応答してモニターを行なうことにより、現使用状況データを非定期的に取得する（１００Ｆ）、付記Ｃ２記載のトライアル環境システム。
効果：非同期の使用状況モニタリングを実現できる。
付記Ｆ５：図１６
購買期待度算出手段（２００）は、過去使用状況履歴データと現使用状況データからなる時系列データに対して時間関数である重み付けパターンによる重み付けをした移動平均をとって購買期待度を算出する（２００Ｂ）、付記Ｃ４に記載のトライアル環境システム。
効果：購買期待度を平滑化できる。重み付けパターンを工夫することで、現使用状況データに対する購買期待度の感度を上げることも可能である。
付記Ｆ６：図１８
購買期待度算出手段（２００）は、モニターしたユーザ毎の使用状況を表すデータにユーザ毎の購買重みデータを掛け合わせてアプリケーションソフトウェアに対する各ユーザの購買期待度を算出する（２００Ｃ）付記Ｃ７に記載のトライアル環境システム。
効果：購買期待度を使用状況データのみならず購買重みデータにも依存させることができる。
付記Ｆ７：図２０
購買期待度算出手段は、モニターしたユーザ毎の使用状況を表すデータに、ユーザ毎の購買重みデータが表す購買重みの増加関数を掛け合わせてアプリケーションソフトウェアに対する各ユーザの購買期待度を算出する（２００Ｅ）付記Ｃ７に記載のトライアル環境システム。
効果：  効果：購買期待度を使用状況データのみならず購買重みデータにも依存させることができる。
付記Ｆ８：図２８
通知手段は、使用状況のモニター結果から所定の使用条件を満足する使用状況にあるユーザ名を特定し、特定したユーザ名を営業支援情報として通知する機能（６００Ｂ）を有する付記Ｃ１１に記載の営業支援システム。
効果：営業のために、特定のユーザ名をスクリーニングできる。 
付記Ｆ９：図２９
通知手段は、購買期待度算出結果から所定の購買期待度条件を満足する購買期待度を有するユーザ名を特定し、特定したユーザ名を営業支援情報として通知する機能（６００Ｃ）を有する付記Ｃ１１に記載の営業支援システム。
効果：営業のために、特定のユーザ名をスクリーニングできる。 
付記Ｇ１：図３２−図３５
物理サーバに対する全ユーザＩＤのトラフィック量をモニターするトラフィックモニター（７００）を備え、現使用状況データをトラフィック量のモニター結果に基づいて正規化する正規化手段（８００）を備える、付記Ｃ２のトライアル環境システム。
効果：段落００６５参照。 
【符号の説明】
【００７０】
１０：営業支援システム
２０：インターネット
３０：物理サーバ
３６：仮想サーバ
３８：アプリケーションソフトウェア
５４、１００：使用状況モニター
５６、２００：購買期待度算出部
５８、３００：仮想リソース動的割当部
６００Ａ、６００Ｂ、６００Ｃ：営業端末への通知部
１４：営業端末
１２：ユーザ端末
Ｗ（ＩＤ）：顧客の重みデータ
【図１】
2013109653.tif 000003
【図２】
2013109653.tif 000004
【図３】
2013109653.tif 000005
【図４】
2013109653.tif 000006
【図５】
2013109653.tif 000007
【図６】
2013109653.tif 000008
【図７】
2013109653.tif 000009
【図８】
2013109653.tif 000010
【図９】
2013109653.tif 000011
【図１０】
2013109653.tif 000012
【図１１】
2013109653.tif 000013
【図１２】
2013109653.tif 000014
【図１３】
2013109653.tif 000015
【図１４】
2013109653.tif 000016
【図１５】
2013109653.tif 000017
【図１６】
2013109653.tif 000018
【図１７】
2013109653.tif 000019
【図１８】
2013109653.tif 000020
【図１９】
2013109653.tif 000021
【図２０】
2013109653.tif 000022
【図２１】
2013109653.tif 000023
【図２２】
2013109653.tif 000024
【図２３】
2013109653.tif 000025
【図２４】
2013109653.tif 000026
【図２５】
2013109653.tif 000027
【図２６】
2013109653.tif 000028
【図２７】
2013109653.tif 000029
【図２８】
2013109653.tif 000030
【図２９】
2013109653.tif 000031
【図３０】
2013109653.tif 000032
【図３１】
2013109653.tif 000033
【図３２】
2013109653.tif 000034
【図３３】
2013109653.tif 000035
【図３４】
2013109653.tif 000036
【図３５】
2013109653.tif 000037