スケジュール管理システムサーバが稼働する第1のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第2のサイトと、を含み、前記第1のサイトと前記第2のサイトがインターネットを介して接続されるスケジュール管理システムであって、業務アプリケーションが動作する該スケジュール管理システム外のサイトと接続する論理的なインターフェースを前記第1のサイトは有することを特徴とするスケジュール管理システム。請求項1記載のスケジュール管理システムにおいて、前記スケジュール管理システムサーバは、バッチ処理の開始処理を行う前記スケジュール管理システムクライアントから出力される呼び出しでバッチ処理可否判定処理を開始し、前記バッチ処理可否判定処理の結果を、前記スケジュール管理システムクライアントに戻すことを特徴とするスケジュール管理システム。請求項2記載のスケジュール管理システムにおいて、前記バッチ処理可否判定処理に際し、前記スケジュール管理システムサーバは自身が有する1又は2以上のリポジトリからスケジュールの基礎情報を用いることを特徴とするスケジュール管理システム。請求項3記載のスケジュール管理システムにおいて、前記バッチ処理可否判定処理を受信した前記スケジュール管理システムクライアントは所定の場合にバッチ処理を実行することを特徴とするスケジュール管理システム。スケジュール管理システムサーバが稼働する第1のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第2のサイトと、を含み、前記第1のサイトと前記第2のサイトがインターネットを介して接続されるスケジュール管理システムの制御方法であって、前記スケジュール管理システムクライアントが前記スケジュール管理システムサーバに処理を行うべきバッチの有無の確認を要求するバッチ処理確認ステップと、前記バッチ処理確認ステップでの要求を受けて、前記スケジュール管理システムサーバが処理を行うべきバッチの有無を確認し、前記スケジュール管理システムクライアントに前記確認の結果を送信するバッチ処理確認ステップと、を有することを特徴とするスケジュール管理システムの制御方法。スケジュール管理システムサーバ上で実行の判定を行うプログラムであって、該プログラムは、前記スケジュール管理システムサーバとコンピュータネットワークで接続されるスケジュール管理システムクライアント上で動作するバッチ実行モジュールから、企業IDとバッチIDを取得し、バッチ処理の要否を判定し、前記コンピュータネットワークを介して前記バッチ実行モジュールに前記判定の結果を返送することを特徴とするプログラム。請求項6記載のプログラムにおいて、前記判定の結果が肯定的なものである場合には、前記スケジュール管理システムサーバ内のバッチ実行スケジュールリポジトリの最終実施日を更新することを特徴とするプログラム。しかし、クラウドコンピューティングにおいては、バッチシステムとスケジュール管理システム間での通信にインターネットを利用することとなり、どちらか一方に公開用のポートを開ける必要がある。このため、セキュリティリスクを増大させるといった問題が発生する。このようなシステムをクラウドコンピューティング環境で利用する場合、システム間情報連携を実現するセキュアなシステム構成の検討が必要となる。本発明の目的は、スケジュール管理システムクライアントが管理するバッチが実行可能かスケジュール管理システムサーバに問い合わせることで、インターネット上にポートを公開する必要なくセキュアな環境でバッチ処理システムを稼動させる手段を提供することにある。本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。本発明の代表的な実施の形態に関わるスケジュール管理システムは、スケジュール管理システムサーバが稼働する第1のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第2のサイトと、を含み、これらの第1のサイトと第2のサイトがインターネットを介して接続され、業務アプリケーションが動作する該スケジュール管理システム外のサイトと接続する論理的なインターフェースを第1のサイトは有することを特徴とする。このスケジュール管理システムにおいて、スケジュール管理システムサーバは、バッチ処理の開始処理を行うスケジュール管理システムクライアントから出力される呼び出しでバッチ処理可否判定処理を開始し、バッチ処理可否判定処理の結果を、スケジュール管理システムクライアントに戻すことを特徴としても良い。このスケジュール管理システムにおいて、バッチ処理可否判定処理に際し、スケジュール管理システムサーバは自身が有する1又は2以上のリポジトリからスケジュールの基礎情報を用いることを特徴としても良い。このスケジュール管理システムにおいて、バッチ処理可否判定処理を受信したスケジュール管理システムクライアントは所定の場合にバッチ処理を実行することを特徴としても良い。本発明の代表的な実施の形態に関わるスケジュール管理システムの制御方法は、スケジュール管理システムサーバが稼働する第1のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第2のサイトと、を含み、第1のサイトと第2のサイトがインターネットを介して接続され、スケジュール管理システムクライアントがスケジュール管理システムサーバに処理を行うべきバッチの有無の確認を要求するバッチ処理確認ステップと、バッチ処理確認ステップでの要求を受けて、スケジュール管理システムサーバが処理を行うべきバッチの有無を確認し、スケジュール管理システムクライアントに確認の結果を送信するバッチ処理確認ステップと、を有することを特徴とする。本発明の代表的な実施の形態に関わるプログラムは、スケジュール管理システムサーバ上で動作するものであって、スケジュール管理システムサーバとコンピュータネットワークで接続されるスケジュール管理システムクライアント上で動作するバッチ実行モジュールから、企業IDとバッチIDを取得し、バッチ処理の要否を判定し、コンピュータネットワークを介してバッチ実行モジュールに判定の結果を返送することを特徴とする。このプログラムにおいて、判定の結果が肯定的なものである場合には、スケジュール管理システムサーバ内のバッチ実行スケジュールリポジトリの最終実施日を更新することを特徴としても良い。スケジュール管理システムサーバがスケジュール管理システムクライアントに実行命令を出すのではなく、スケジュール管理システムクライアントが管理しているバッチが実行可能か否かをスケジュール管理システムサーバに問い合わせることで、バッチ処理システム環境でインターネット上にポートを公開する必要はなく、セキュアな環境でバッチ処理システムの稼働が可能となる。また、インターネット上の様々なアプリケーションは、スケジュール管理システムサーバで管理された情報を元に、各企業に適したユーザインターフェース等のサービスを提供可能となる。さらに、企業独自のカレンダ情報が手に入ることから、3月第2営業日等の抽象表現での日付指定が業務アプリケーション上で可能となる。以下の実施の形態においては、便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明する。しかし、特に明示した場合を除き、それは互いに無関係なものではなく、一方は他方の一部又は全部の変形例、詳細、補足説明などの関係にある。また、以下の実施の形態において、要素の数など個数、数値、量、範囲などを含むに言及する場合、特に明示した場合及び原理的に明らかに特定の数に限定される場合などを除き、その特定の数に限定されるものでなく、特定の数以上でも以下でも良い。さらに、以下の実施の形態において、その構成要素は、特に明示した場合及び原理的に明らかに必須であると考えられる場合を除き、必ずしも必須のものでないことは言うまでもない。以下、図を用いて本発明の実施の形態を説明する。実施の形態本発明に関わるスケジュール管理システムの概略動作は以下のようになる。スケジュール管理システムクライアントは、スケジュール管理システムサーバに対して一定間隔でバッチ処理の実行の可否について問い合わせを行う。問い合わせを受けたスケジュール管理システムサーバは、自身が管理するバッチ実行スケジュールと企業のカレンダ情報を参照し、処理を行うべきバッチがあるかを確認する。処理を行うバッチの有無の判定結果は、スケジュール管理システムサーバからスケジュール管理システムクライアントに伝達される。処理を要するバッチがあった場合には、スケジュール管理システムクライアントは指定されたバッチ処理を実行する。次にインターネット上の業務アプリケーションが企業独自のカレンダ情報を取り込む場合について説明する。またインターネット上にある業務アプリケーションは、複数の企業が汎用化された同じ業務アプリケーションを利用し、迅速かつ安価にアプリケーションを導入できる。一方で、インターネット上にある業務アプリケーションでは個別の企業の営業日や休業日を登録することはできず、画面情報にも反映されないため、利用者にとっては不便なユーザインターフェースとなっている。これに対し、本発明では、業務アプリケーションは必要に応じて、特定企業の特定の期間についてスケジュール管理システムサーバに問い合わせる。問い合わせを受けたスケジュール管理システムサーバは自身が管理するカレンダ情報を参照し、指定された期間の営業日、休日といったカレンダ情報をアプリケーションに返す。アプリケーションでは受け取ったカレンダ情報を元に画面の表示などを行う。図1は、本発明を実現するスケジュール管理システムの全体概要図である。本発明に関わるシステムは、インターネット10によって相互に接続される、スケジュール管理システムサーバ101が稼働するサイト11と、スケジュール管理システムクライアント102とバッチ処理システム103が稼働するサイト12、インターネット上で公開される業務アプリケーション104が稼働するサイト13により構成される。インターネット10とは、インターネットプロトコル技術を用いて相互接続されたコンピュータネットワークである。従来、企業が持つ複数のバッチ処理システムは社内LANLocalAreaNetworkなど、外部と隔離された環境に配置される。これらの複数のバッチ処理システムはスケジュール管理システムからの起動命令で各バッチ処理が稼動する。インターネット10を経由する場合、スケジュール管理システムがバッチ処理システムに命令を出すために必要なTCP等のトランスポート層のプロトコルで用いるネットワークポートをインターネット上に公開する必要がある。これはバッチ処理システムが配置された全環境で必要となる為、バッチ処理システムが多いほどセキュリティのリスクを増大させることとなっていた。また特に手段を講じなければ、EndToEndの経路は、保証されるものではなく、経路上のデータの安全性は保証されない。さらには、不足の第三者がインターネット10経由でサイト11、12、13に不正にアクセスを試みることも可能であるため、各サイトは一定の安全措置を採る必要がある。本発明は、これらのリスクを解消するための物である。スケジュール管理システムサーバ101は、企業の営業日と休業日を定義したカレンダ情報と、バッチ処理システムの実行スケジュールを管理するシステムサーバである。スケジュール管理システムクライアント102は、スケジュール管理システムサーバ101が管理するスケジュールに基づいてバッチ処理システムを実行する上位ソフトウェアモジュールである。バッチ処理システム103は、スケジュール管理システムクライアント102により実行され、インターネット上のハードウェアを利用する際に、自社で運用していたスケジュール監視システム図示せずをスケジュール管理システムサーバ101が提供するスケジュール管理システムに置き換える下位ソフトウェアモジュールである。なお、サイト12上のスケジュール管理システムクライアント102及びバッチ処理システム103の対は複数存在すると思われるが、説明の簡略化のために一組に制限している。サイト12上にスケジュール管理システムクライアント102及びバッチ処理システム103の対が複数存在する場合も本発明の射程に含まれるのは言うまでもない。また、スケジュール管理システムクライアント102及びバッチ処理システム103が動作するサイト12が複数存在することも発明者は想定している。これらも本発明の射程に含まれる。サイト13上で動作する業務アプリケーション104は、Salesforce.com登録商標やGoogleApps登録商標などインターネット上で公開される業務アプリケーションである。図2は、図1で説明した各サイトの開放ポート一覧に関する図である。ここで、ポート番号はTCPトランスミッションコントロールプロトコルまたはUDPユーザデータグラムプロトコルで定義される使用ポートアドレスのことを言う。サイト11では、スケジュール管理システムクライアント102からの問い合わせと、業務アプリケーション104からの問い合わせをWebサービスとして受け付ける。このため、インターネット10を経由してのサイト11へのポート番号80HTTP、若しくはポート番号443HTTPSの通信が許可されている。サイト12では、スケジュール管理システムクライアント102がスケジュール管理システムサーバ101のWebサービスに問い合わせるために、サイト12からインターネット10を経由してのポート番号80、若しくはポート番号443が解放されている。サイト13に関してもサイト12と同様である。これにより、不適切なポートを経由しての外部からのアクセスをサイト12とサイト13は遮断することができる。図3は、スケジュール管理システムサーバ101の構成図である。スケジュール管理システムサーバ101は、定休日情報リポジトリ302と、例外休業日情報リポジトリ303と、バッチ実行スケジュールリポジトリ304と、実行判定モジュール305と、カレンダ情報提供モジュール306と、日付提供モジュール307と、を含んで構成される。定休日情報リポジトリ302は、企業毎の定休日を管理するリポジトリデータ格納部である。例外休業日情報リポジトリ303は、企業毎の定休日以外の休業日を管理するリポジトリである。これらの定休日情報リポジトリ302及び例外休業日情報リポジトリ303は、該企業の定休日など、スケジュールの基礎情報を提供する。すなわち該当日が定休日情報リポジトリ302及び例外休業日情報リポジトリ303から上げられる情報に含まれていなければ、営業日であるとの判断をなすことができる。バッチ実行スケジュールリポジトリ304は、バッチ処理システム103の稼働スケジュールを管理するリポジトリである。実行判定モジュール305は、スケジュール管理システムクライアント102からの問い合わせに対して、対象のバッチがその時実行出来るか否かを判定するソフトウェアモジュールである。カレンダ情報提供モジュール306は、業務アプリケーション104からの問い合わせに対して、休業日情報を返すソフトウェアモジュールである。日付提供モジュール307は、業務アプリケーション104からの問い合わせに対して、抽象的な表現を具体的な日付に変換するソフトウェアモジュールである。スケジュール管理システムサーバ101が持つ実行判定モジュール305と、カレンダ情報提供モジュール306と、日付提供モジュール307はSaaS等のWebサービスとしてインターネットに公開されている。図4は、スケジュール管理システムクライアント102の構成図である。スケジュール管理システムクライアント102は、バッチ実行モジュール402とプロパティファイル403を含んで構成される。バッチ実行モジュール402は、スケジュール管理システムサーバ101の実行判定モジュール305にバッチ処理システム103の起動可否を確認し、可能であった場合はバッチ処理システム103を起動するソフトウェアモジュールである。プロパティファイル403は、バッチ実行モジュール402が管理するバッチ処理システム103を表すIDとバッチ処理システム103を所有する企業IDが格納されたデータ格納部である。図5は、スケジュール管理システムサーバ101で公開されるWebサービスの一覧に関する図である。実行判定モジュール305は、スケジュール管理システムクライアント102のバッチ実行モジュール402から渡される企業IDとバッチIDを引数として取得し、バッチIDが表すバッチ処理システム103がその時起動可能であるかを判定し、その可否情報をスケジュール管理システムクライアント102に返す。カレンダ情報提供モジュール306は、業務アプリケーション104から渡される企業IDと、確認期間開始日と確認期間終了日で指定される期間情報を元に、企業IDに該当する企業に関して、指定された期間内の休業日一覧を呼び出し元の業務アプリケーション104に返す。日付提供モジュール307は業務アプリケーション104から渡される企業IDと、日付確認の対象月を指定する確認指定月情報と、確認指定月情報で指定された月の中で何番目の営業日または休業日を検索するかを指定する確認数え日と、日付確認の対象が営業日か休業日かを指定する営業日休業日フラグを元に、定休日情報リポジトリ302と例外休業日情報リポジトリ303を参照し、具体的な日付情報を返す。例えば、業務アプリケーション104から、企業IDとして対象の企業ID、確認指定月として1、確認数え日として3、営業日休業日フラグとしてtrueを受け取った場合、日付提供モジュール307は企業IDの定休日情報リポジトリ302と例外休業日情報リポジトリ303の情報を参照し、企業IDに該当する企業の1月の第3営業日にあたる日付情報を呼び出し元の業務アプリケーション104に返す。図6は、定休日情報リポジトリ302の一例を示す図である。ここでは、企業IDとその企業の定休日定期休業曜日が登録されている。図6の場合、CompanyAは土曜日と日曜日が定休日であり、CompanyBは火曜日が定休日であることが登録されている。図7は、例外休業日情報リポジトリ303の一例を示す図である。ここでは、企業IDとその企業の定休日以外の休業日例外休業日が登録されている。図7の場合、CompanyAは3月10日と5月20日、CompanyBは12月31日が休業日であることが登録されている。図8は、バッチ実行スケジュールリポジトリ304の一例を表す図である。ここでは、バッチ処理システム103を表すバッチIDとその実行開始時刻、及び、実施周期、周期で指定された日にちが営業日の場合、バッチ処理システム103を起動させるか否かを表す営業日実施フラグ、周期で指定された日にちが休業日の場合、バッチ処理システム103を起動させるか否かを表す休業日実施フラグが登録されている。なお、図中の最終実施日は、バッチ処理を最後に行った日をいう。便宜上スケジュール管理システムクライアント102からスケジュール管理システムサーバ101への問い合わせがあった最終の日となると思われるが、最終実施日を如何様にするかは設計事項である。なお、後述する図10ではステップS1109、S1111がこの最終実施日の更新に当たる。図8では、BatchAは毎週水曜日の11時に実行、BatchBは毎月最終日が営業日の場合のみ12時に実行、BatchCは2011年の2月18日から2日おきで、営業日に該当する日のみ実施することを表している。なお、定休日情報リポジトリ302、例外休業日情報リポジトリ303及びバッチ実行スケジュールリポジトリ304は、各企業の担当者により予めこれらの情報が登録されているものとし、登録手段に関して言及しないものとする。図9は、本発明におけるバッチ実行モジュール402の動作を示すフローチャートである。バッチ実行モジュール402はLinux登録商標のcronやWindows登録商標のタスクスケジューラなどにより定期的に実行されるモジュールである。起動したバッチ実行モジュール402はプロパティファイル403からバッチ処理システム103を管理する企業を表す企業IDと、バッチ処理システム103を表すバッチIDを取得しステップS1001、スケジュール管理システムサーバ101の実行判定モジュール305を公開したWebサービスに問い合わせを行うステップS1002。スケジュール管理システムサーバ101からの戻り値がtrueの場合ステップS1003:Yes、バッチ処理システム103を実行可能である。このため、プロパティファイル403から取得したバッチIDに該当するバッチ実行モジュール402を実行するステップS1004。スケジュール管理システムサーバ101からの戻り値がfalseの場合ステップS1003:No、バッチ処理システム103は実行不可であるため、処理を終了することとなる。図10は、本発明における実行判定モジュール305の動作を示すフローチャートである。実行判定モジュール305はWebサービスとして公開され、スケジュール管理システムクライアント102のバッチ実行モジュール402から呼び出されることで処理が開始する。処理開始後、実行判定モジュール305は、まずバッチ実行モジュール402から取得した企業ID情報をキーに、定休日情報リポジトリ302と例外休業日情報リポジトリ303を参照し、休業日一覧を取得するステップS1101。次に、実行判定モジュール305は、処理実行時の日時とバッチ実行モジュール402から取得したバッチIDの情報をもとに、バッチ実行スケジュールリポジトリ304を参照するステップS1102。ステップS1102で参照した結果を元に実行判定モジュール305は処理実施日がバッチ実行スケジュールリポジトリ304の実施周期で指定された日に該当し、且つ、処理実施時刻がバッチ実行スケジュールリポジトリ304の始日時を過ぎている、且つ、バッチ実行スケジュールリポジトリ304の最終実行日時が実施日よりも過去の日付であるか=営業日であるかを判定するステップS1103。営業日である場合ステップS1104:Yes、バッチ実行スケジュールリポジトリ304から取得した情報の営業日実施フラグを参照する。trueである場合ステップS1105:Yesは、呼び出し元のバッチ実行モジュール402にtrueステップS1107を返し、falseステップS1105:Noである場合は、呼び出し元のバッチ実行モジュール402にfalseを返すステップS1110。また、実行判定モジュール305は、処理実施日が休業日であった場合ステップS1104:No、バッチ実行スケジュールリポジトリ304から取得した情報の休業日実施フラグを参照する。休業日実施がtrueである場合はステップS1106:Yes、呼び出し元のバッチ実行モジュール402にtrueを返しステップS1108、falseである場合はステップS1106:No、呼び出し元のバッチ実行モジュール402にfalseを返すステップS1112。なお、呼び出し元のバッチ実行モジュール402にtrueを返した場合、バッチ実行スケジュールリポジトリ304内のバッチIDに該当するデータに関して、最終実施日を処理実施日に書き換えるステップS1109及びステップS1111。図11は、本発明におけるカレンダ情報提供モジュール306の動作を示すフローチャートである。カレンダ情報提供モジュール306はWebサービスとして公開される。業務アプリケーション104がカレンダ情報提供モジュール306を呼び出すことでカレンダ情報提供モジュール306の処理が開始される。カレンダ情報提供モジュール306の処理開始後、カレンダ情報提供モジュール306は、まず業務アプリケーション104から取得した企業ID情報をキーに、定休日情報リポジトリ302と例外休業日情報リポジトリ303を参照し、該当企業の休業日を取得するステップS1201。次に、カレンダ情報提供モジュール306は、ステップS1201で取得した休業日情報から、業務アプリケーション104から取得した確認期間開始日と確認期間終了日で指定された期間に含まれる休業日の一覧を作成するステップS1202。その後カレンダ情報提供モジュール306は、作成した休業日一覧を呼び出し元の業務アプリケーション104に返すステップS1203。業務アプリケーション104はその画面表示に送られた休業日一覧を反映するなどして、利用者へのサービスの情報として利用する。図12は、本発明における日付提供モジュール307の動作を示すフローチャートである。日付提供モジュール307はWebサービスとして公開される。日付提供モジュール307は業務アプリケーション104から呼び出されることで処理が開始する。日付提供モジュール307の処理開始後、日付提供モジュール307は、まず業務アプリケーション104から取得した企業ID情報をキーに、定休日情報リポジトリ302と例外休業日情報リポジトリ303を参照し、休業日一覧を取得するステップS1301。次に業務アプリケーション104から取得した確認指定月、確認数え日、営業日休業日フラグを元に、具体的な日付を算出するステップS1302。例えば、業務アプリケーション104から、企業IDはCompanyA、確認指定月は1、確認数え日は3、営業日休業日フラグとしてtrueを受け取ったとき、定休日情報リポジトリ302の内容が図6、例外休業日情報リポジトリ303の内容が図7の状態とすると、処理実施年度の1月の中で、土曜日と日曜日を除く3つ目の日付を、呼び出し元の業務アプリケーション104に返すステップS1303。このように、日付提供モジュール307を使用することで、業務アプリケーション104は抽象的に表現された日付情報から具体的な日付情報を取得することができる。このように処理することで、インターネット上に不要なポートを公開する必要なくセキュアな環境でバッチ処理システムを稼動させることが可能となる。すなわち、1企業が持つ複数のバッチ処理システムと、それらの管理と実行を行うスケジュール管理システムをインターネット上のハードウェアリソース上で稼動させる、2企業が持つシステムをインターネット上にあるアプリケーションに置き換えるという問題を解決することができる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。例えば、スケジュール管理システムサーバ101中には定休日情報リポジトリ302、例外休業日情報リポジトリ303、バッチ実行スケジュールリポジトリ304、実行判定モジュール305、カレンダ情報提供モジュール306、日付提供モジュール307が存在する。これらの役割を併せ持つソフトウェアモジュールに処理を一元化する場合や、いくつかの処理を行うモジュールを用いるなど、一般的な応用事例については当然に本発明の射程に含まれる。また上記では、処理すべきバッチの有無の判定結果はその如何にかかわらずスケジュール管理システムサーバ101からスケジュール管理システムクライアント102へ伝達された。しかし、処理すべきバッチがあるときのみスケジュール管理システムサーバ101からスケジュール管理システムクライアント102に伝達するようにしても良い。