"複数の利用者の端末と、リソースプロバイダと、複数のパブリッククラウドとがネットワークで通信接続され、前記複数のパブリッククラウドは、各々に、前記リソースプロバイダが管理する共同利用型サーバが設置され、前記リソースプロバイダは、制御部と、記憶部と、を有し、前記制御部は、登録部と、実行制御部とを有し、前記記憶部は、前記利用者のプログラムのデータを管理情報と共に格納し、前記登録部は、前記利用者からの指示に基づき、前記利用者のプログラムのデータを管理情報と共に前記記憶部に格納する処理を行い、前記実行制御部は、前記利用者からの指示に基づき、前記記憶部の前記利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させるように制御する処理を行い、前記実行制御部からの制御に基づき、前記対象のパブリッククラウドの対象の共同利用型サーバは、前記利用者のプログラムの処理を稼働させること、を特徴とするクラウド共用型リソース提供システム。請求項1記載のクラウド共用型リソース提供システムにおいて、前記リソースプロバイダは、モニタシステムを有し、前記モニタシステムは、前記対象のパブリッククラウドの対象の共同利用型サーバでの前記利用者のプログラムの処理の稼働の状態をモニタし、当該モニタ情報に基づいて、前記利用者に対する課金計算処理を行うこと、を特徴とするクラウド共用型リソース提供システム。請求項1記載のクラウド共用型リソース提供システムにおいて、前記利用者により、前記リソースプロバイダに対し、前記利用者のプログラムを稼働させる対象となるパブリッククラウド、及び共同利用型サーバを指定可能とすること、を特徴とするクラウド共用型リソース提供システム。請求項2記載のクラウド共用型リソース提供システムにおいて、前記モニタシステムは、前記利用者に対する課金方式として、前記対象のパブリッククラウドの対象の共同利用型サーバでの前記利用者のプログラムの処理の稼働時間または処理量に応じた従量課金方式の課金計算処理を行うこと、を特徴とするクラウド共用型リソース提供システム。請求項1記載のクラウド共用型リソース提供システムにおいて、前記パブリッククラウド内に、前記共同利用型サーバが複数設けられ、前記実行制御部は、前記記憶部の前記利用者のプログラムを対象のパブリッククラウドの複数の共同利用型サーバのうち選択された1つで実行されるように制御する処理を行うこと、を特徴とするクラウド共用型リソース提供システム。請求項5記載のクラウド共用型リソース提供システムにおいて、前記実行制御部は、前記対象のパブリッククラウドの複数の共同利用型サーバのうち1つを選択する際に、負荷が小さい1つを選択すること、を特徴とするクラウド共用型リソース提供システム。請求項5記載のクラウド共用型リソース提供システムにおいて、前記パブリッククラウド内の複数の共同利用型サーバは、機能が異なり、前記実行制御部は、前記対象のパブリッククラウドの複数の共同利用型サーバのうち1つを選択する際には、前記利用者からの指示または設定に基づいて、所定の機能を持つ1つを選択すること、を特徴とするクラウド共用型リソース提供システム。請求項1記載のクラウド共用型リソース提供システムにおいて、前記パブリッククラウド内に、前記リソースプロバイダ側の記憶部の前記利用者のプログラムのデータのコピーを管理情報と共に格納するローカル記憶部を有し、前記リソースプロバイダ側の記憶部の前記利用者のプログラムの第1のデータを、初回、前記パブリッククラウド側のローカル記憶部に第2のデータとしてコピーし、2回目以降は、前記第1と第2のデータで違いがある場合のみ前記ローカル記憶部へのコピーを行い、前記利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させる際に、対象の共同利用型サーバは、前記ローカル記憶部の前記利用者のプログラムの第2のデータを取り出し、当該利用者のプログラムの処理を実行すること、を特徴とするクラウド共用型リソース提供システム。前述の各種のパブリッククラウドが存在し、利用者によるパブリッククラウドの利用方法は様々であり、利用者は、固有のパブリッククラウドに合わせた利用方法や課金方式を余儀なくされている。即ち、パブリッククラウドの利用における容易性利便性やコストパフォーマンス等に関して課題改善余地がある。例えば、ある固有のパブリッククラウドを利用して利用者が所望のアプリケーション処理やバッチ処理などのプログラム処理を実現する場合、当該パブリッククラウドの仮想サーバ数単位での利用契約課金方式に基づき、課金がされる。しかし例えばバッチ処理で所定の限定された日時にしか処理が実行されなくても、利用契約で借りている仮想サーバ数単位の課金の料金になるため、利用者にとってはコストパフォーマンスがよくないと感じられる。以上を鑑み、本発明の主な目的は、パブリッククラウドの利用に係わる新しいモデルのシステム技術を提供することにより、利用者のパブリッククラウドの利用に係わる容易性利便性やコストパフォーマンス等を実現できることである。上記目的を達成するため、本発明のうち代表的な形態は、パブリッククラウド等のクラウドコンピューティングシステムそのサービス処理等を利用者が効果的に利用するための情報処理システムクラウド共用型リソース提供システム、等であって、以下に示す構成を有することを特徴とする。本形態のシステムは、複数の利用者の端末と、リソースプロバイダと、複数のパブリッククラウドとがネットワークで通信接続されて構成される。複数のパブリッククラウドは、各々に、リソースプロバイダが管理する共同利用型サーバが設置される。リソースプロバイダは、制御部と、記憶部と、モニタシステムとを有する。制御部は、登録部と、実行制御部とを有する。記憶部は、利用者のプログラムのデータを管理情報と共に格納する。登録部は、利用者からの指示に基づき、利用者のプログラムのデータを管理情報と共に記憶部に格納する処理を行う。実行制御部は、利用者からの指示に基づき、記憶部の利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させるように制御する処理を行う。実行制御部からの制御に基づき、対象のパブリッククラウドの対象の共同利用型サーバは、利用者のプログラムの処理を稼働させる。モニタシステムは、対象のパブリッククラウドの対象の共同利用型サーバでの利用者のプログラムの処理の稼働の状態をモニタし、当該モニタ情報に基づいて、利用者に対する課金計算処理を行う。本発明のうち代表的な形態によれば、パブリッククラウドの利用に係わる新しいモデルのシステム技術を提供することにより、利用者のパブリッククラウドの利用に係わる容易性利便性やコストパフォーマンス等を実現できる。特に、企業等の利用者が各種のパブリッククラウドを容易に利用して所望のアプリケーション処理やバッチ処理を実現でき、なおかつコストパフォーマンスに優れるシステムを構築することができる。事業者側は新しいモデルのサービスを提供することができる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。<従来例>本実施の形態と比較するため、図6を用いて、従来例のシステムにおける利用者がパブリッククラウドを利用する例及びその問題点などについて説明する。図6で、複数の各種のパブリッククラウド、例えばA,Bを有し、それらを利用する複数の利用者、例えばA,Bを有する。例えば、利用者A例:企業Aは、端末コンピュータA1に、利用者プログラムUP1,2を有する。UPは、利用者企業システム等ごとの所望の内容の処理アプリケーション処理やバッチ処理などを実現するためのプログラムである。端末A1は、例えば企業Aシステム内に設置されたオンプレミスサーバ自社設置サーバである。利用者B例:企業Bは、端末B1に、利用者プログラムUP3を有する。端末B1は、例えば企業Bシステム内に設置されたオンプレミスサーバである。端末A1のUP1の処理例:バッチ処理Aでは、パブリッククラウドAWebAPサーバ601等にアクセスしそのリソース605を使用して処理が行われる。同様に、端末A1のUP2の処理例:アプリ処理Aでは、パブリッククラウドBリソース605にアクセスし処理が行われる。同様に、端末B1のUP3の処理例:バッチ処理Bでは、パブリッククラウドAリソース605にアクセスし処理が行われる。例えばパブリッククラウドAでは、複数のWebAPウェブアプリケーションサーバ601やDB602を有する。物理サーバであるWebAPサーバ601では、仮想化ソフトウェア等を用いて複数の仮想サーバ603が稼働し、仮想サーバ603を用いたサービス処理を提供する。DB2は、WebAPサーバ601が処理するデータ情報例えば利用者のデータを格納するデータベースやストレージである。605は、601~603を含むリソースサービス処理をまとめて表す。パブリッククラウドAの課金部604は、利用者による当該パブリッククラウドAリソース605の利用に係わる課金処理を行う。この課金方式として、例えば、利用契約で利用者が借りる利用者に貸す固定の仮想サーバ数を単位とした課金である。同様に、パブリッククラウドBでは、異なるサーバ等の構成によるリソース605を有する。パブリッククラウドBの課金部604は、課金方式として、例えば、月固定の料金である。上記例のように各種のパブリッククラウドA,Bの利用方法課金方式があり、利用者はそれぞれの利用方法課金方式に応じて利用する。UP1は例えば所定のバッチ処理Aを実行するプログラムであり、所定の日時に稼働し、ネットワークを介してパブリッククラウドAのリソース605仮想サーバ603等にアクセスしその処理を実現する。UP1の処理内容コードは、固有のパブリッククラウドAに応じた内容として記述されている。利用者A端末A1は、UP1バッチ処理Aのため、パブリッククラウドAの利用契約に応じた仮想サーバ数を使用する。上記バッチ処理Aが例えば1日のうち30分といった限定された時間で実行されるとしても、上記課金方式によると、処理実行時間分ではなく、固定の仮想サーバ数単位で課金されるため、利用者にとっては比較的割高な料金に感じられる可能性がある。また例えば端末A1のUP1からネットワークを介してパブリッククラウドAにアクセスするが、パブリッククラウドの位置物理サーバが設置されている地域などは各種パブリッククラウドに応じて異なるため、端末A1からのアクセスの距離などに応じた遅延やエラーも発生し得る。即ち、固有のパブリッククラウドの特性に応じて利用者のプログラム処理の結果へ影響する場合がある。<概要等>本実施の形態のシステムでは、インターネット上、不特定の利用者のコンピュータシステム端末と複数の各種のパブリッククラウドとの間に、新たにリソースプロバイダ対応する情報処理システムを設ける。リソースプロバイダの提供するリソースとは、パブリッククラウド内に設けられる共同利用型サーバクラウド共用型サーバを指す。この共同利用型サーバとは、複数の利用者により対象のパブリッククラウドそのリソースを共同利用するための特徴的なサーバハードウェア及びソフトウェアを含むである。リソースプロバイダは、不特定の利用者に対して、利用契約課金に基づき、当該共同利用型サーバリソースを提供する。例えば、従量課金方式でのリソース貸しである。利用者は、所望の利用者プログラムをリソースプロバイダに登録し、上記提供リソースを利用して、利用者プログラムの処理アプリケーション処理やバッチ処理などを実現する。利用者システム内では当該利用者プログラム及びその稼働用のオンプレミスサーバ等を保持する必要性が小さくなる。リソースプロバイダは、予め、対象事業対象、設置対象の複数の各種のパブリッククラウド内に、共同利用型サーバ各々1つ以上を設置する。またリソースプロバイダは、利用者からの指示要求に応じて、利用者プログラムそのデータをプールに登録する。リソースプロバイダは、利用者からの指示要求に応じて、プールの利用者プログラムを、対象パブリッククラウドの対象共同利用型サーバ上で実行させるように制御する。共同利用型サーバ上の利用者プログラムの処理では適宜パブリッククラウドのリソースサービス処理仮想サーバ等を利用して自身の処理を行う。また、リソースプロバイダは、モニタシステムにより、各パブリッククラウドの共同利用型サーバにおける利用者プログラムの稼働状況実績をモニタし、そのモニタ情報に応じて利用者に対する課金処理を行う。利用者は、実際に利用者プログラムが稼働した時間や処理量などに応じた課金で済むため、利用者にとってコストパフォーマンスに優れる。[システム構成]図1において、本実施の形態のシステムの全体の構成例を示している。本システム全体は、リソースプロバイダ1と、利用者端末2図示しないが複数と、複数の各種のパブリッククラウド3例:A,B,C等とを含み、これらは通信ネットワークインターネットで接続されている。1リソースプロバイダ1は、サーバ主制御部10と、プール50利用者プログラム格納部と、モニタシステム40と、UIユーザインタフェース部60とを有し、各部は例えばLAN等で接続される。リソースプロバイダ1は、複数の利用者2と複数のパブリッククラウド3との間に介在する事業者のシステムであり、利用者2に対して、パブリッククラウド3を効果的に利用するためのリソースである、共同利用型サーバ31を提供利用契約によるリソース貸しする。複数の利用者2が共同利用型サーバ31を共同利用する仕組みにより、低コストで当該リソースを提供できる。2利用者端末2は、不特定の利用者が使用するコンピュータシステムないし端末等である。利用者端末2は、図示しないプロセッサ、メモリ、通信インタフェース、OS,Webブラウザ等の公知の要素の他に、利用者プログラムUP101を有する。UP101は、利用者2がパブリッククラウド3に対して実行させる所望の処理アプリケーション処理やバッチ処理などのプログラムのデータである。3パブリッククラウド3は、公知技術部分であるリソース30と、本システムの特徴要素である共同利用型サーバSS31と、SS31上で稼働させる利用者プログラムUP103と、リソースプロバイダ1のモニタシステム40と連携するエージェント32とを有する。リソースサービス30は、前述605と同様に、当該パブリッククラウド3が元々備えている物理サーバ、仮想サーバ、DB、等のリソースサービス処理を含む。31共同利用型サーバSS31は、リソースプロバイダ1により予め対象のパブリッククラウド3内に設置用意される。SS31は、リソースプロバイダ1サーバ10の実行制御部12からの指示a2-2に従い、対象のUP103の処理を当該SS31上で稼働させる。UP103の処理は、適宜、パブリッククラウド3のリソースサービス30を参照しながら行われる。SS31上には複数のUP103の処理を稼働させることができる。32エージェント32は、例えば、対応する対象の共同利用型サーバSS31上で一緒に稼働する別のサーバ等で稼働する形としてもよい。エージェント32は、モニタ設定情報に基づいて、モニタ内容として、対象のSS31の動作状態その変動と、SS31上で稼働するUP103の動作状態その変動とをモニタし、その内容を示すモニタ情報a4を発行し、ネットワークを介してモニタシステム40モニタ部41へ送信する。UP103のモニタは、少なくともUP102の処理プロセスないしインスタンスの起動開始と停止終了の把握を含む。10サーバ10は、本システムリソースプロバイダ1の主制御部であり、登録部11と、実行制御部12とを有する。各処理部11,12は例えば当該サーバ10に備えるプロセッサ、メモリ、通信インタフェース等の公知の要素を用いたソフトウェアプログラム処理で実現される。50プール50は、利用者プログラム格納部であり、ストレージやDB及びその入出力制御処理を用いて実現される。プール50には、利用者プログラムUP102データが、対応する管理情報51と共に格納される。サーバ10は管理情報51を作成管理する。60UI部60は、利用者2に対して本システムの機能の設定や指示入力などのためのユーザインタフェースを提供する処理部であり、例えばWebサーバで実装される。利用者は、利用者端末2Webブラウザから当該UI部60の提供するWebページにアクセスし、当該Webページで表示情報設定状態などを確認したり、各種の設定や指示a0,a1-1,a2-1等の操作が可能である。40モニタシステム40は、モニタ部41と、課金部42と、モニタ情報43履歴情報とを有する。モニタシステム40は、例えばサーバで実装され、主に利用者への課金のためのモニタ処理を行う。なおモニタシステム40部分は、リソースプロバイダ1やサーバ10から分離したシステムとして連携する形態としてもよい。モニタシステム40部分として例えば既存の統合監視システムクラウドの仮想サーバ等の動作状態を監視するシステムや課金管理システム等を利用してもよい。41モニタ部41は、パブリッククラウド3内で稼働するエージェント32と連携し、エージェント32からのモニタ情報a4に基づき、共同利用型サーバSS31の動作状態をモニタし、モニタ情報43として記録する。モニタ内容は、SS31の動作状態と、SS31上で稼働するUP103の動作状態とを含む。42課金部42は、モニタ情報43に基づいて、及び利用者の課金設定情報に基づいて、課金計算処理例えばSS31上のUP103の稼働時間や処理量に応じた従量課金を行い、結果情報を保存し、利用者端末2に対する課金請求通知a5をしたり、UI部60のWebページに課金情報を表示したりする処理を行う。利用者2への課金請求は、既存の決済システム等との連携により行ってもよい。11登録部11は、利用者2からのUP事前登録の指示a1-1に基づき、利用者プログラムUP101のデータコピーを、管理情報51を付けてプール50に格納登録する処理を行うUP102。また登録部11は、利用者からの指示に応じて、UP101の内容バージョンの更新の場合、プール50の該当UP102のデータを利用者側からの新データによって更新し、また登録解除の場合、プール50の該当UP102のデータを削除する。12実行制御部12は、利用者2からのUP実行指示a2-1に基づき、プール50の該当UP102のデータ及び管理情報51を参照して、対象のパブリッククラウド3の対象のSS31へ、UP実行指示a2-2及び対象のUP102のデータを送信コピーa2-3する処理を行う。[処理シーケンス]図2は、本システム図1の各要素間の処理シーケンスを示すS101等は処理ステップを表す。S101まず利用者2とリソースプロバイダ1との利用契約があり、対象としてどのパブリッククラウド3、どの共同利用型サーバSS31及びその機能などを利用するのか、及び課金方式例えば従量課金とその詳細の指定、などを含め、基本的な設定a0が行われる。例えば、利用者または事業者側の管理者等により、当該基本設定a0の操作がサーバ10のUI部60に対し行われ、基本設定情報図示しないがリソースプロバイダ1内に保存される。S102利用者端末2から、利用者の操作に基づき、サーバ10のUI部60を介して登録部11に対し、UP101のデータを事前登録する指示a1-1が行われる。S103上記指示a1-1に従い、登録部11は、利用者端末2からのUP101のデータコピーを取得受信し、プール50内に、当該UP102のデータを、当該UP102の管理情報51具体例は図3を付けて格納する。S104登録済みの状態で、利用者端末2から、利用者の操作に基づく任意タイミングで、サーバ10のUI部60を介して実行制御部12に対し、UP実行指示a2-1を送信する。実行制御部12は当該指示a2-2を受信する。S105実行制御部12は、上記指示a2-2に従い、プール50内の該当のUP102データ及び管理情報51を参照取得し、対象パブリッククラウド3の対象SS31へ、まず対象UPの実行指示a2-2を送信する。ここではまだUP102データは送信しない。S106対象パブリッククラウド3の対象SS31は、上記指示a2-2を受けると、例えば、当該SS31で対象UPの実行が可能な状態である場合OKは、そのOKの旨をサーバ10へ応答する。また不可能な状態である場合NGは、そのNGの旨を応答する。上記状態OK/NGは、例えばSS31の負荷やリソースの状況に応じて判断される。S107実行制御部12は、対象SS31から上記OKの応答を受けた場合は、該当のUP102のデータそのコピーをネットワークを介して対象パブリッククラウド3の対象SS31へ送信するa2-3。対象SS31は、当該UPデータを受信取得する。S108続いて、対象SS31は、当該SS31上で、上記指示され受信した対象のUP102の処理を起動開始させるUP103。なおUP103がバッチ処理である場合、所定の日時で起動する。S109エージェント32は、対象SS31の動作状態をモニタしている。例えばS108で対象SS31がUP103の処理を起動した時、そのことを示すモニタデータa4を発行し、ネットワークを介して、モニタ部41へ送信する。モニタ部41は、当該モニタデータa4を受信し、履歴情報モニタ情報43として記録する。S110対象SS31では、該当UP103は、適宜、パブリッククラウド3のリソースサービス30を利用しながら、自身の所定の処理例えばバッチ処理を実行する。SS31のプロセッサ、メモリ、通信インタフェース等の公知の要素を用いて当該プログラム処理が実行される。また必要に応じて利用者端末2からネットワークを介してSS31のUP103へアクセスして処理を行ってもよいa6。S111対象SS31は、当該SS31上の該当のUP103の処理を所定の契機で停止終了させる。例えばUP103がバッチ処理である場合、所定の日時の処理が終わると起動終了する。またこの契機は、利用者2側からのUPの停止の指示によるものとしてもよい。この場合、前述同様に、指示を受けた実行制御部12から対象SS31へ該当UP103の停止の指示を送信し、SS31がUP103の稼働を停止させる。S112前述同様に、エージェント32は、対象SS31上のUP103の処理の終了をモニタしており、当該終了した時、そのことを示すモニタデータa4を発行し、ネットワークを介して、モニタ部41へ送信する。モニタ部41は、当該モニタデータa4を受信し、履歴情報モニタ情報43として記録する。モニタ部41は、モニタデータa4及びモニタ情報43を参照することにより、SS31及びUP103の動作状態を把握できる。特に上記UP103がバッチ処理の場合は、所定の日時のみの起動の状況がモニタされる。S113課金部42は、モニタ部41と連携し、SS31及びUP103の動作状態を示すモニタ情報43等を参照し、該当利用者の課金設定情報課金方式に基づいた課金計算処理例えばUP103の処理の稼働時間に応じた従量課金を行う。課金部42は、課金計算の結果情報を記録し、利用者2への課金請求の通知a5を行ったり、UI部60で表示するWebページに課金請求情報を表示させる。上記モニタ部41または課金部42は、モニタ情報43から課金計算用の情報を別途作成して保存してもよい。課金方式に応じて、例えばUP103の処理でリソース30を使用した量の情報や、UP103の処理の開始から終了までの時間の情報などを作成してもよい。[管理情報]図3は、サーバ主制御部10で管理するUP102の管理情報51の構成例を示す。管理情報51で管理する情報項目の例として、aUP情報、b利用者情報、c対象パブリッククラウド情報、d対象共同利用型サーバSS情報、e課金方式、等を有し、更にオプション情報として、f対象機能、gタイプ、等を有する。aUP情報は、UP101の識別情報IDやアドレス等である。例えばUPA1等で示す。b利用者情報は、UP101の利用者2のIDやアドレス等である。例えば利用者A等で示す。c対象パブリッククラウド情報は、当該UPを稼働させる対象となるパブリッククラウド3のIDやアドレス等である。例えばパブリッククラウドA等で示す。d対象共同利用型サーバSS情報は、当該UPを稼働させる対象となるSS31のIDやアドレス等である。例えばSSA1等で示す。対象パブリッククラウド3内に複数のSS31が存在する場合はそれらの中から指定することができる。e課金方式は、課金設定情報として、例えば当該UP103の稼動に応じた従量課金方式などを選択可能とする。f対象機能は、対象SS31の持つ機能のうち、当該UPで使用したい機能実行クラスを示す情報である。機能の例としてPDF機能の有無などがある。SS31毎に機能が異なる場合は上記d対象SS情報で指定すればよい。gタイプは、例えばSS31の共同利用のタイプ方式を指定する情報である。例えばパブリッククラウド3内の特定のSS31のみでUP103を稼働させることや、パブリッククラウド3内の複数の任意のSS31でUP103を稼働させることや、更には、パブリッククラウド3内の複数のSS31における利用の優先順位の指定、等が挙げられる後述。[利用例]図4では、本システム図1のリソースプロバイダ1を介して複数の利用者2複数のUP101がそれぞれパブリッククラウド3SS31を利用する例を示している。利用者A端末A1,利用者B端末B1,利用者C端末C1,C2,利用者D端末D1を有し、パブリッククラウドASSA1,パブリッククラウドBSSB1,パブリッククラウドCSSC1,SSC2,SSC3を有する。利用者A端末A1は、第1のプログラムであるUPA1を登録し、対象のパブリッククラウドAのSSA1上で稼働させる。また第2のプログラムであるUPA2を登録し、対象のパブリッククラウドBのSSB1上で稼働させる。利用者B端末B1は、UPB1を登録し、対象のパブリッククラウドBのSSB1上で稼働させる。利用者C端末C1は、UPC1を登録し、対象のパブリッククラウドBのSSB1上で稼働させる。SSB1上では、UPA2,UPB1,UPC1を含む複数のUP103が共同で稼働する。利用者C端末C2は、UPC2を登録し、対象のパブリッククラウドCのSSC1上で稼働させる。利用者D端末D1は、UPD1を登録し、対象のパブリッククラウドCのSSC2上で稼働させる。パブリッククラウドC内のSSC1,SSC2,SSC3でそれぞれUP103が稼動する。[詳細構成例]次に、図5を用いて、上述の実施の形態に基づいたより詳しい構成例について説明する。基本構成は図1等と同様であり、異なる構成について以下説明する。図5において、対象のパブリッククラウド3内に、利用者プログラムUPを格納するためのローカルプール70を有する。ローカルプール70は、リソースプロバイダ1側のプール50と対応関係であり、ストレージやDB等で実現され、プール50のUP102のデータのコピーをUP104として格納する。またUP104にはプール50側と同様に必要な管理情報が付与される。また、対象のパブリッククラウド3内に、複数の共同利用型サーバSS31を設ける。例えばSSグループ500における、SSA1,SSA2,SSA3の3つのSS31を示す。SSグループ500の各SS31は、前述同様にリソース30を利用する。また複数のSS31に併せて、各エージェント32が稼働し、各SS31の動作状態を前述同様にモニタする。例えばSS31ごとのエージェント32AA1,AA2,AA3を有する。リソースプロバイダ1の制御部10の実行制御部12は、初回、プール50のUP102データを、ローカルプール70へ送信コピーし格納させるb1。また2回目以降の場合、実行制御部12は、プール50のUP102データと、ローカルプール70のUP104データとの違いバージョン等をチェックし、最新データへの更新が必要な場合はプール50のUP102のデータを送信コピーしてローカル70側のUP104データを更新させ、必要でない場合は送信しないb2。これによりリソースプロバイダ1とパブリッククラウド3との通信を抑制する。パブリッククラウド3側で、ローカルプール70の管理参照は、例えばSS31により行う。各SS31は、ローカルプール70にアクセスし、ローカルプール70内のUP104データ及び管理情報を読み書きするb5。また、前述の利用者2からの指示に基づきSS31上でUP103を稼働させる実行制御の際には、SSグループ500候補の中から当該UP103を稼働させる対象となるSS31を選択可能であるb3。例えばパブリッククラウド3側各SS31で、当該UP104を稼働させる1つのSS31を動的に決定するb4。例えば複数のSS31の負荷リソース状況を比較し、負荷が少ない良好な状態のSS31を選択する。当該選択された1つのSS31例:SSA1は、ローカルプール70の該当UP104データコピーを取り出し、当該SS31SSA1上で稼働させる。また、上記動的な決定に限らず、1つのSS31を利用者2が選択指示する形としてもよいし、複数の候補のSS31の中から順番に1つを選択する形などとしてもよい。また、パブリッククラウド3内に備える複数のSS31500としては、同タイプのSS31のみでなく、各種のタイプ例えばサーバ種別や機能が異なるのSS31を並存させてもよい。例えば、機能が異なるSS31として、PDF機能を持つSS31と持たないSS31とを設ける。この場合、利用者UPの設定や指示などに応じて、所望のSS31の機能例:PDF機能を選択して実行させるように制御する図3の51のfの対象機能でも設定可能。利用者2側からのUP実行指示前記a2-1の際に、利用者の所望の機能例:PDF機能に対応する実行クラスを指定可能とする。この場合は指定に応じた実行クラス機能を持つSS31が選択されることになる。また、複数のSS31から選択可能とする場合、利用者2側からの設定や指示などにより、複数のSS31における選択の優先順位などを付けてもよい。実行制御の際には優先順位に応じてSS31が選択されることになる。[効果等]以上説明したように、本実施の形態によれば、リソースプロバイダ1を含む新しいモデルのシステムを提供することにより、利用者2のパブリッククラウド3の利用に係わる容易性利便性やコストパフォーマンス等を実現できる。特に、企業等の利用者2が各種のパブリッククラウド3を容易に利用して所望のアプリケーション処理やバッチ処理などを実現でき、なおかつコストパフォーマンスに優れるシステム企業システム等を構築することができる。事業者側は新しいモデルのサービスを提供できる。特に、共同利用型サーバSS31でのUP103の稼働分による従量課金方式などにより、UP101が例えばバッチ処理プログラムである場合も、限定された日時のバッチ処理の実行時間分の料金で済むことになるため、また利用者システム内のオンプレミスサーバ等の具備も必要ではないため、利用者2にとっては安価となる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。"