"利用者端末と、前記利用者端末から使用する第1の業務システム、前記利用者端末から前記第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び前記第1の認証手段が前記利用者情報を識別するために使用する前記第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、前記第1の業務システムから呼び出される第2の業務システム、前記第1の認証手段から予め前記利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び前記第2の認証手段が前記利用者情報を識別するために使用する前記第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、前記第2の認証手段は、前記第1の認証手段から前記利用者情報の認証要求を最初に受けた時に、前記第2の認証データ管理部に当該認証要求の可否を問い合わせ、認証を可とする場合は、前記第2のサーバに備える認証フラグ管理部に前記利用者情報と認証済フラグの少なくとも一方を記入し、前記第2の業務システムが、前記第1の業務システムから呼び出される時は、前記認証フラグ管理部の前記利用者情報又は前記認証済フラグの少なくとも一方の有無をチェックする、前記第2のサーバに備えた認証チェック手段が、前記第2の業務システムの利用の可否を判定することを特徴とする認証システム。前記認証フラグ管理部は、前記第2の認証手段が生成するHTTPセッション又はデータベースであることを特徴とする請求項1に記載の認証システム。前記第1の認証データ管理部及び前記第2の認証データ管理部はデータベース又は一覧テーブルであることを特徴とする請求項1又は請求項2に記載の認証システム。前記第1のサーバは、前記認証チェック手段が前記認証要求を否と判定した場合に当該判定を受けて、その後の処理を制御する認証エラー制御手段と、前記認証エラー制御手段が前記処理内容を決定するために用いる認証エラー制御設定ファイルを有することを特徴とする請求項1乃至請求項3のいずれか1項に記載の認証システム。前記利用者情報は、利用者端末情報、ユーザ情報、第1のサーバ情報の少なくとも1つを含むことを特徴とする請求項1乃至請求項4のいずれか1項に記載の認証システム。前記認証エラー制御設定ファイルは、前記第2の業務システムの一部又は全部の利用権限を有する、利用者端末情報、ユーザ情報、第2のサーバ情報の少なくとも1つを含むことを特徴とする請求項5に記載の認証システム。従来の認証システムでは、WEBシステム上のソフトウェア資産の利用において、複雑な認証鍵や公開鍵といった認証技術の利用が必要であったり、他のサーバへアクセスする都度認証を行う必要があるという問題点があり、多数のWEBシステムを連携する場合に、時間がかかる、煩わしい等の問題があった。この発明は、上記のような課題を解決するためになされたものであり、認証鍵や公開鍵といった認証技術の利用を必須とせず、繰り返しアクセスするWEBシステム間の認証工程の処理効率の向上を目的とする。この発明に係る認証システムは、利用者端末と、利用者端末から使用する第1の業務システム、利用者端末から第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び第1の認証手段が利用者情報を識別するために使用する第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、第1の業務システムから呼び出される第2の業務システム、第1の認証手段から予め利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び第2の認証手段が利用者情報を識別するために使用する第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、第2の業務システムが、第1の業務システムから呼び出される時は、認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものである。この発明に係る認証システムは、第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、第2の業務システムが、第1の業務システムから呼び出される時は、認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものなので、ログイン時に認証が通れば、後の業務処理の実行時には認証データベースを使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。実施の形態1.以下、この発明の実施の形態1を図1乃至図4に基づいて説明する。図1は、この発明の実施の形態1に係る認証システム100の機能構成ログイン時と各構成要素間の相互関係を示す図である。ログイン画面等、利用者側の操作画面をGUI環境を利用して表示する利用者端末101と、利用者が直接使う業務システムA特許請求の範囲では第1の業務システムに相当が搭載されたサーバA特許請求の範囲では第1のサーバに相当、業務システムAから利用されている業務システムB特許請求の範囲では第2の業務システムに相当のソフトウェア資産105が搭載されたサーバB特許請求の範囲では第2のサーバに相当、及び同様に業務システムC特許請求の範囲では第2の業務システムに相当のソフトウェア資産110が搭載されたサーバC特許請求の範囲では第2のサーバに相当で構成される。サーバ数は、説明の都合上2台にしているだけであり、同様の構成であれば何台でも接続できる。図2は、利用者が利用者端末101からサーバAの業務システムAにログインする時のフローを示す図であり、以下、図1の網掛け部分を主に説明する。他の図においても同じ利用者端末101上に表示されるログイン画面にて、ユーザ情報ユーザID、パスワード等を入力し、業務システムAにログインS201する。認証手段104特許請求の範囲では第1の認証手段に相当は、業務システムA用の認証データベースである認証DB103特許請求の範囲では第1の認証データ管理部に相当を用いてユーザ情報の認証処理を行いS202、認証結果S203がOKであれば、業務システムB用の認証手段107特許請求の範囲では第2の認証手段に相当を呼び出す。この時、サーバBにはHTTPセッション108特許請求の範囲では認証フラグ管理部に相当が生成され、その後、認証手段107は、業務システムB用の認証データベースである認証DB106特許請求の範囲では第2の認証データ管理部に相当を用いてユーザ情報の認証処理を行いS204、認証結果S205がOKであれば、HTTPセッション108に認証済フラグ1081をセットS206する。業務システムC特許請求の範囲では第2の業務システムに相当についても同様の処理S207~S209を行う。各認証処理にて、認証結果がNGとなった場合は、エラー画面を利用者端末101に表示S210する。次に、図3、図4に基づいて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。図3は、認証システム100において業務システムAが他のサーバのソフトウェア資産にアクセスする時の機能構成を示す図である。また、図4はソフトウェア資産連携のフローを示す図である。利用者端末101上に表示された業務システムAの業務画面から利用者が業務システムAに属する業務処理aの使用を依頼すると、業務処理aが実行S401される。業務処理aは、業務システムBに属する業務処理bを担当するソフトウェア資産105を使用するために業務処理bを呼び出すS402のであるが、その時に認証チェック手段109が実行S403される。認証チェック手段はHTTPセッション108内に認証済フラグ1081が存在するか否かをチェックし、チェック結果S404がOKであれば、業務システムBのソフトウェア資産105を実行S405する。業務システムCのソフトウェア資産の使用についても同様の処理S406~409を行う。各認証チェック処理にて、チェック結果がNGとなった場合は、エラー画面を表示S410する。この実施の形態1では、ログイン時に認証が通れば、後の業務処理の実行時には認証DB106を使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。また、認証処理は、各業務システムで個別の方法で行うことができるのでフレキシブルなシステム構成を実現できる。実施の形態2.以下、この発明の実施の形態2を図5、図6に基づいて、実施の形態1と異なる部分を説明する。図5は、認証システム200の機能構成ログイン時を示す図である。実施の形態1では、業務システムB、業務システムCにて各々認証DB106,111を用いた認証処理を実施していたが、実施の形態2では独自の認証DBを不要とした認証手段207、212を用いる構成となっている。次に、利用者がログインする時の動作を実施の形態1と異なる部分を説明する。図6は、実施の形態2に係る認証システム200の動作のフローチャートログイン時を示す図である。実施の形態1と異なるところは、認証処理のためのデータベースをシステム毎に実装する必要が無く、認証処理実行S601、S602はデータベースの代わりに設けた信頼済みサーバ一覧情報206、211を利用するところである。認証手段207、212は、自身の機能の呼び元のサーバ情報ここではサーバAをリクエスト情報から取得し、予め信頼できるサーバとして登録されている信頼済みサーバ一覧情報206、211と比較して、合致した場合に認証結果S205、S208をOKとする。ソフトウェア資産アクセス時のその他の動作は、実施の形態1で図4を用いて説明したものと同じである。この実施の形態2では、各業務システムで個別のデータベースを用いた認証処理までは不要の場合に、簡易に認証処理を実現できる。実施の形態3.以下、この発明の実施の形態3を図7乃至図10に基づいて実施の形態1と異なる部分を説明する。図7は、実施の形態3に係る認証システム300の機能構成ログイン時を示す図である。実施の形態1では、認証済みフラグの保持用としてHTTPセッション108を利用していたが、この実施の形態3では、認証手段用DB308を利用する。次に、図7、図8を用いて、利用者がログインする時の動作を説明する。図8は、認証システム300の動作のフローチャートログイン時を示す図である。実施の形態1と異なるところは、認証処理B用、C用の実行の後で、認証手段用DB308の認証済情報管理テーブル318にユーザIDを登録801、802し、これを認証済フラグとして利用する点である。次に、図9、図10を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。図9は、認証システム300の機能構成ソフトウェア資産アクセス時を示す図である。また、図10は、認証システム300の動作のフローチャートソフトウェア資産アクセス時を示す図である。実施の形態1と異なるところは、認証チェックBS1001において、認証チェック手段309が、認証手段用DB308に備える認証済情報管理テーブル318中に該当のユーザIDが存在するか否かの検索を行い、存在する場合にチェック結果をOKとする点である。認証チェックCS1002についても同様である。この実施の形態3では、認証済情報を識別するためのデータであるユーザIDをデータベースに保持するため、実施の形態1で発生するHTTPセッション108のタイムアウトによる認証済フラグ1081の消滅という不都合を回避できる。実施の形態4.以下、この発明の実施の形態4を図11に基づいて、実施の形態1と異なる部分を説明する。図11は、認証システム400の機能構成ソフトウェア資産アクセス時を示す図である。実施の形態1では、サーバB、Cでの認証チェック手段109,114による認証チェックでエラーが発生した時には、エラー画面を表示していた。この実施の形態4では、サーバB、C上の認証チェック手段409,414による認証チェックでエラーが発生した場合でもエラー画面の表示は行わず、サーバA上の認証エラー制御手段415にその後の判断を委ねる。次に、図12を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。図12は、実施の形態4に係る認証システム400の動作のフローチャートソフトウェア資産アクセス時を示す図である。実施の形態1と異なるところは、認証チェックB,Cの各ステップS1201、S1202において、認証エラーが発生した場合でもエラー画面の表示を行わず、認証エラー制御S1203,S1205を実行する点である。認証エラー制御手段415は、認証エラー制御設定ファイル416を読み込み、各サーバで認証エラーが発生した場合の後続処理継続/中止を判断する。継続と判断した場合は、エラー画面表示は行わず次の処理を実行する。本実施の形態4におけるログイン時の動作は、実施の形態1、図2で説明したものと同じである。実施の形態4では、他の業務システムのソフトウェア資産の特性に合わせ、認証エラー時の動作を認証エラー制御設定ファイルに容易に定義できる。例えば、特定のサーバについてはエラーが発生してもフルアクセスを許可したり、業務システムB,C中の一部の業務処理についてのみ、エラー時でも利用を許可しても良い。また、利用者情報毎にエラー時の動作を定義しても良い。認証エラー制御設定ファイルを利用することにより、一時的に認証対象を一括変更できるという利点もある。なお、この実施の形態4で示した認証エラー制御手段415は、先述の実施の形態2、3とも組み合わせて運用可能であり、組み合わされた各実施の形態が持つ効果を合わせて得ることができる。各実施の形態によって、利用者情報としては利用者端末情報、ユーザ情報ID、パスワード、第1のサーバ情報の少なくとも1つを含むこととなる。"