(57)【特許請求の範囲】
【請求項１】
複数のアプリケーションサーバに格納されるアプリケーションプログラムのそれぞれの応答時間データを、前記複数のアプリケーションサーバのそれぞれからデータサーバに定期的に送信するステップと、
前記アプリケーションプログラムに対する接続要求データとユーザ識別データとを、ユーザ端末から前記複数のアプリケーションサーバのうち何れか一のアプリケーションサーバに送信するステップと、
前記ユーザ識別データと前記データサーバに予め格納されるユーザ識別データとを前記何れか一のアプリケーションサーバにおいて比較し一致する場合に、予め認証された認証証明書データを前記データサーバに格納し、前記応答時間データのそれぞれを前記データサーバから前記何れか一のアプリケーションサーバに送信して、前記応答時間データのそれぞれのうち最も応答時間が短いアプリケーションプログラムが格納される最速アプリケーションサーバを指定するメニューデータを作成し、且つ前記予め認証された認証証明書データと前記メニューデータとを、前記何れか一のアプリケーションサーバから前記ユーザ端末に送信するステップと、
前記メニューデータに基づいて前記ユーザ端末から前記最速アプリケーションサーバに接続するとともに、前記最速アプリケーションサーバに格納されるアプリケーションプログラムのそれぞれのうち一のアプリケーションプログラムに対する会話要求データと予め認証された認証証明書データとを、前記ユーザ端末から前記一のアプリケーションプログラムが格納される前記最速アプリケーションサーバに送信する第１のステップと、
前記予め認証された認証証明書データとデータサーバに予め格納される認証証明書データとを前記最速アプリケーションサーバにおいて比較し一致する場合に、前記一のアプリケーションプログラムによって前記会話要求データに対する会話返答データと利用実績データとを作成し、且つ前記最速アプリケーションサーバが再度認証した認証証明書データと前記会話返答データとを、前記最速アプリケーションサーバから前記ユーザ端末に送信する第２のステップと、
前記利用実績データを、前記一のアプリケーションプログラムに組み込んだ課金ＡＰＩから前記データサーバに送信する第３のステップと、
を含むことを特徴とするアプリケーション・サービスを提供する方法。
【請求項２】
前記第３のステップ後に前記複数のアプリケーションサーバに格納されるアプリケーションプログラムのそれぞれのうち他のアプリケーションプログラムに対する会話要求データと前記再度認証された認証証明書データとを、前記ユーザ端末から前記他のアプリケーションプログラムが格納される他のアプリケーションサーバに送信する第４のステップと、
前記再度認証された認証証明書データと前記予め格納された認証証明書データとを前記他のアプリケーションサーバにおいて比較し一致する場合に、前記会話要求データに対する会話返答データと利用実績データとを、前記他のアプリケーションプログラムによって作成し、且つ前記会話返答データと前記他のアプリケーションサーバによって再度認証された認証証明書データとを、前記他のアプリケーションサーバから前記ユーザ端末に送信する第５のステップと、
前記利用実績データを、前記他のアプリケーションプログラムに組み込んだ課金ＡＰＩから前記データサーバに送信する第６のステップと、
を含むことを特徴とする請求項１に記載のアプリケーション・サービスを提供する方法。
【請求項３】
前記第３のステップ又は前記第６のステップ後に、前記第４のステップ、前記第５のステップ及び前記第６のステップを１回以上繰り返して実行する第７のステップを含むことを特徴とする請求項１又は請求項２に記載のアプリケーション・サービスを提供する方法。
【請求項４】
前記一のアプリケーションプログラムに組み込んだ課金ＡＰＩ及び／又は前記他のアプリケーションプログラムに組み込んだ課金ＡＰＩから受信した利用実績データに基づく利用代金の額データを、前記データサーバにおいて作成するステップを含むことを特徴とする請求項１から請求項３の何れか一に記載のアプリケーション・サービスを提供する方法。
【請求項５】
前記第２のステップ及び／又は前記第５のステップは、
前記認証証明書データと前記予め格納された認証証明書データとを比較し一致する場合に、前記予め格納される認証証明書データを、新たな認証証明書データに前記最速アプリケーションサーバ及び／又は前記他のアプリケーションサーバにおいて変更し、且つ前記新たな認証証明書データを、前記データサーバに格納するステップを含み、
前記再度認証された認証証明書データを、前記新たな認証証明書データとして送信することを特徴とする請求項１から請求項４の何れか一に記載のアプリケーション・サービスを提供する方法。
【請求項６】
前記第１のステップに係る認証証明書データが、予め暗号化された暗号化済認証証明書データであり、
前記第２のステップ及び／又は前記第５のステップは、前記予め認証された認証証明書データを、前記最速アプリケーションサーバ及び／又は前記他のアプリケーションサーバにおいて暗号化し暗号化済認証証明書データを生成し、且つ前記暗号化済認証証明書データを前記データサーバに格納するステップを含み、
前記再度認証された認証証明書データとして、前記暗号化済認証証明書データを送信することを特徴とする請求項１から請求項５の何れか一に記載のアプリケーション・サービスを提供する方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、アプリケーション・サービスを提供する方法及びシステムに関するものである。
【０００２】
【発明の背景】
アプリケーション・サービスを提供するとは、コンピュータネットワークを介してアプリケーションプログラムを有償でユーザに利用させること、若しくはコンピュータネットワークを介していわゆる商用サービスをユーザに提供することをいう。
【０００３】
ここで、コンピュータネットワークとは、例えば、インターネット（Ｉｎｔｅｒｎｅｔ）、広域通信網（ＷＡＮ：Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等である。インターネットとは、良く知られるように、通信プロトコルＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いて全世界のネットワークを相互に接続した巨大なコンピュータネットワークである。また、ＴＣＰ／ＩＰとはインターネット、イントラネットで標準的に使われるプロトコルであり、ＴＣＰ／ＩＰはＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等の基盤となるプロトコルである。
尚、ＨＴＴＰとはＷｅｂサーバとＷｅｂブラウザとの間でデータ（ＨＴＭＬ文書、画像ファイル、音楽ファイル、映像ファイル等）を送受信するのに使われるプロトコルであり、ＨＴＴＰは１つのＨＴＭＬ文書毎にＴＣＰ／ＩＰの接続・データ転送（ＨＴＭＬ文書のほか、このＨＴＭＬ文書に関連付けられている画像ファイル等）・切断を行うステートレスのプロトコルである。ＨＴＴＰは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）が公開している技術文書ｒｆｃ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２６１６で定義されている（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２６１６．ｔｘｔ）。
【０００４】
また、ＷｅｂサーバとはＷｅｂブラウザからのリクエストに応じてサーバ上のリソース（ＨＴＭＬ文書、画像ファイル、音楽ファイル、映像ファイル等）をＷｅｂブラウザに送信するものである。ここで、Ｗｅｂサーバには、サーバ上のＨＴＭＬ文書等を単に送信するもののほか、サーバ上のアプリケーションプログラムを実行しその出力結果に基づいて生成されたＨＴＭＬ文書等を送信するものも含む。尚、アプリケーションプログラムの出力結果に基づいてＨＴＭＬ文書を生成するアプリケーションプログラムは、例えば、Ｐｅｒｌ（Ｐｒａｃｔｉｃａｌ  Ｅｘｔｒａｃｔｉｏｎ  ａｎｄ  Ｒｅｐｏｒｔ  Ｌａｎｇｕａｇｅ）、Ｊａｖａ等のプログラム言語で作成されている。Ｐｅｒｌで作成されたアプリケーションプログラムは、良く知られるように、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）技術を用いて動的なＨＴＭＬ文書を生成できる。
一方、Ｗｅｂブラウザとはサーバ上のリソースをＷｅｂブラウザから受信してリソースを解析してユーザ端末のディスプレイ又はスピーカに表示又は再生するものである。加えて、Ｗｅｂブラウザはユーザからの入力を受け取ってＷｅｂサーバに送信することもできる。ここで、Ｗｅｂブラウザには、Ｎｅｔｓｃａｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社のＮｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ（Ｃｏｍｍｕｎｉｃａｔｏｒ）、Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ等がある。
【０００５】
ところで、現在、アプリケーション・サービスを提供する事業者、即ちアプリケーション・サービス・プロバイダ（ＡＳＰ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）と言えば、自らアプリケーションプログラムを開発するベンダーである。即ち、ベンダー自らがアプリケーションプログラムを開発するとともに、業務プロセスプログラム（ユーザ認証プログラム、課金処理プログラム等）を開発して、業務プロセスプログラムを組み込んだアプリケーションプログラムをコンピュータネットワークを介して有償でユーザに利用させている。
【発明が解決しようとする課題】
現在のアプリケーション・サービスを提供する方法及びシステムには次のような問題があった。
【０００６】
例えば、複数のユーザが同一のアプリケーションプログラムを同時に利用することも当然に生じ得る。この場合、アプリケーションプログラムは複数のユーザのそれぞれに対するＨＴＭＬ文書等のデータを生成する必要があるので、アプリケーションプログラムの処理速度が低下することになる。
【０００７】
ここで、アプリケーションプログラムの処理速度の低下を防ぐためには、アプリケーションプログラムが格納されるサーバ（以下、「アプリケーションサーバ」とも言う。）の処理能力を高くすれば解決する。
ところが、アプリケーションサーバのコストは処理能力が高くなるに伴って飛躍的に高くなるのが現状である。具体的に言えば、アプリケーションサーバのコストは、演算速度に依存するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）  のクロック周波数、データの送信速度に依存するルータの通信速度等が２倍になると２倍以上になることは言うまでもない。また、現在の技術ではＣＰＵのクロック周波数等には上限があるのが現状である。従って、アプリケーションサーバの処理能力を高くすることには限界があるので、ある程度の数のユーザが同一のアプリケーションプログラムを同時に利用する場合には、アプリケーションプログラムの処理速度の低下を防ぐことができるが、非常に多くの数のユーザが同一のアプリケーションプログラムを同時に利用する場合、アプリケーションプログラムの処理速度が低下することになる。
【０００８】
また、アプリケーションプログラムの処理速度の低下を防ぐためには、アプリケーションサーバを複数台設置することによっても解決する。即ち、アプリケーションプログラムを複数のアプリケーションサーバに分散させて、一台のアプリケーションサーバに格納されるアプリケーションプログラムを利用するユーザの数を分散させる。これにより、アプリケーションプログラムの処理速度の低下を防止することができる。
結果として、例えば、同一のユーザが同一のアプリケーションプログラムを複数のアプリケーションサーバで利用することも当然に生じ得る。即ち、同一のユーザが同一のアプリケーションプログラムをあるアプリケーションサーバで利用し始め、利用を一旦中止する（一時退避）。しかる後に同一のユーザが同一のアプリケーションプログラムを別のアプリケーションサーバで利用を再開することも当然に生じ得る。この場合、業務プロセスプログラムのそれぞれがアプリケーションプログラム（ユーザ認証プログラム、課金処理プログラム等）に組み込まれているので、アプリケーションサーバ単位で同一のユーザのユーザ認証がされ、同一のユーザに課金処理がされることになる。
【０００９】
従って、アプリケーション・サービス・プロバイダ（ＡＳＰ）が同一のユーザに対して利用代金の支払いを求める場合、アプリケーション・サービス・プロバイダを行う事業者は同一のユーザに対する課金処理の結果をアプリケーションサーバのそれぞれで収集して利用代金の額を算出することになる。尚、課金処理の結果である利用代金の額は、アプリケーション・サービス・プロバイダを行う事業者とユーザとの契約でユーザが利用したアプリケーションプログラムの実績データ（利用時間、利用回数等）に基づいて算出されている。
【００１０】
ここで、アプリケーション・サービス・プロバイダ（ＡＳＰ）とユーザとの間の契約で利用代金の額が、ユーザの利用時間（実績データ）に線形である場合、アプリケーションサーバ単位の課金処理の結果である利用代金の額を単に足すだけでよい。一例を挙げれば、契約で利用代金の額が、１０００円／１時間当たり（ユーザの利用時間）であるとする。Ａ（ユーザ）さんがＡ（アプリケーションプログラム）をＡサーバ（アプリケーションサーバ）で１時間利用し、しかる後にＡさんがＡをＢサーバで２時間利用したとする。Ａサーバは課金処理の結果として利用代金の額を１０００円であると算出し、Ｂサーバは課金処理の結果として利用代金の額を２０００円であると算出する。これに対し、課金処理の結果である利用代金の額のそれぞれを単に足すだけでよい（１０００円＋２０００円）。
【００１１】
しかしながら、アプリケーション・サービス・プロバイダ（ＡＳＰ）とユーザとの間の契約で利用代金の額が、ユーザの利用時間（実績データ）に線形でない場合、アプリケーションサーバ単位の課金処理の結果である利用代金の額を単に足すことはできない。一例を挙げれば、契約で利用代金の額が、合計利用時間が１時間までは１０００円／１時間当たりであり、合計利用時間が１時間以降２時間までは２０００円／１時間当たりであるとする。先程と同様に、ＡさんがＡをＡサーバで１時間利用し、しかる後にＡさんがＡをＢサーバで２時間利用したとする。Ａサーバは課金処理の結果として利用代金の額を１０００円であると算出し、Ｂサーバは課金処理の結果として利用代金の額を３０００円（１０００円＋２０００円）であると算出する。これに対し、課金処理の結果である利用代金の額のそれぞれを単に足すと４０００円（１０００円＋３０００円）。一方、契約ではＡさんがＡを３時間利用すると、契約の利用代金の額は５０００円（１０００×１＋２０００×２）である。
【００１２】
即ち、契約の利用代金の額がユーザの利用時間（実績データ）に線形でない場合、アプリケーションサーバ単位の課金処理の結果である利用代金の額を単に足すことはできない。従って、ＡさんはＡをＡサーバで１時間利用し、しかる後にＡさんはＡを再びＡサーバで２時間利用しなければならない。即ち、同一のユーザが同一のアプリケーションプログラムを同一のアプリケーションサーバで利用しなければならない。結果として、アプリケーションプログラムを複数のアプリケーションサーバに分散させても、一台のアプリケーションサーバに格納されるアプリケーションプログラムを利用するユーザの数を分散できない場合がある。これにより、アプリケーションプログラムの処理速度が低下することになる。
【００１３】
本発明は現在のアプリケーション・サービスを提供する方法及びシステムにおける問題に鑑みてなされたものであって、アプリケーションプログラムの処理速度の低下を防止することができるアプリケーション・サービスを提供する方法及びシステムを提供することを課題とする。
【００１４】
【課題を解決するための手段】
前記課題を解決する請求項１の発明は、複数のアプリケーションサーバに格納されるアプリケーションプログラムのそれぞれのうち一のアプリケーションプログラムに対する会話要求データと予め認証された認証証明書データとを、ユーザ端末から前記一のアプリケーションプログラムが格納される一のアプリケーションサーバに送受信する第１のステップと、前記予め認証された認証証明書データとデータサーバに予め格納される認証証明書データとを前記一のアプリケーションサーバにおいて比較し一致する場合に、前記一のアプリケーションプログラムによって前記会話要求データに対する会話返答データと利用実績データとを作成し、且つ前記一のアプリケーションサーバが再度認証した認証証明書データと前記会話返答データとを、前記一のアプリケーションサーバから前記ユーザ端末に送受信する第２のステップと、前記利用実績データを、前記一のアプリケーションプログラムに組み込んだ課金ＡＰＩから前記データサーバに送受信する第３のステップとを含むことを特徴とするアプリケーション・サービスを提供する方法である。
【００１５】
したがって請求項１の発明によれば、複数のアプリケーションサーバのそれぞれが、受信した認証証明書データとデータサーバに予め格納される認証証明書データとを比較して、受信した認証証明書データの正当性の確認を行うことができる。即ち、複数のアプリケーションサーバのそれぞれが、同一のユーザを識別することができる。換言すれば、複数のアプリケーションサーバ間でユーザ管理の統一性を実現することができる。これにより、アプリケーションプログラムを複数のアプリケーションサーバに分散させて、アプリケーションプログラムの処理速度の低下を防止することができるという利点がある。
【００１６】
また、請求項２の発明は、前記第３のステップ後に前記複数のアプリケーションサーバに格納されるアプリケーションプログラムのそれぞれのうち他のアプリケーションプログラムに対する会話要求データと前記再度認証された認証証明書データとを、前記ユーザ端末から前記他のアプリケーションプログラムが格納される他のアプリケーションサーバに送受信する第４のステップと、前記再度認証された認証証明書データと前記予め格納された認証証明書データとを前記他のアプリケーションサーバにおいて比較し一致する場合に、前記会話要求データに対する会話返答データと利用実績データとを、前記他のアプリケーションプログラムによって作成し、且つ前記会話返答データと前記他のアプリケーションサーバによって再度認証された認証証明書データとを、前記他のアプリケーションサーバから前記ユーザ端末に送受信する第５のステップと、前記利用実績データを、前記他のアプリケーションプログラムに組み込んだ課金ＡＰＩから前記データサーバに送受信する第６のステップとを含むことを特徴とする請求項１に記載のアプリケーション・サービスを提供する方法である。
【００１７】
したがって請求項２の発明によれば、請求項１の発明の利点があるとともに、ユーザは一のアプリケーションプログラムによって再度認証された認証証明書データを他のアプリケーションプログラムに送信することにより、他のアプリケーションプログラムを利用することができる。結果として、ユーザは同一のアプリケーションプログラムを他のアプリケーションサーバで利用することもでき、また、異なるアプリケーションプログラムを契約の範囲内で自由に利用することができる。このように、ユーザが同一のアプリケーションサーバだけに制限されることがないので、ユーザが複数のアプリケーションサーバに分散することになる。これにより、アプリケーションプログラムの処理速度の低下を防止することができるという利点がある。
【００１８】
また、請求項３の発明は、前記第３のステップ又は前記第６のステップ後に、前記第４のステップ、前記第５のステップ及び前記第６のステップを１回以上繰り返して実行する第７のステップを含むことを特徴とする請求項１又は請求項２に記載のアプリケーション・サービスを提供する方法である。
【００１９】
したがって請求項３の発明によれば、請求項１又は請求項２の発明の利点があるとともに、ユーザは一のアプリケーションサーバから他のアプリケーションサーバに接続した後、再び一のアプリケーションサーバに格納される同一のアプリケーションプログラムを利用することができる。例えば、ユーザが他のアプリケーションサーバに接続を切り換えたとしても、必ずしも他のアプリケーションサーバに格納される他のアプリケーションプログラムの処理速度が速いとは限らない。従って、他のアプリケーションプログラムの処理速度が遅い場合には、ユーザが一のアプリケーションプログラムの利用を再開することにより、他のアプリケーションプログラムの処理速度の更なる低下を防止することができる。
【００２０】
また、請求項４の発明は、前記一のアプリケーションプログラムに組み込んだ課金ＡＰＩ及び／又は前記他のアプリケーションプログラムに組み込んだ課金ＡＰＩから受信した利用実績データに基づく利用代金の額データを、前記データサーバにおいて作成するステップを含むことを特徴とする請求項１から請求項３の何れか一に記載のアプリケーション・サービスを提供する方法である。
【００２１】
したがって請求項４の発明によれば、請求項１から請求項３の何れか一の発明の利点があるとともに、利用実績データがアプリケーションサーバのそれぞれからデータサーバに送信されるので、契約の利用代金の額がユーザの利用時間（実績データ）に線形でない場合であっても、データサーバで利用実績データを収集して、課金処理を行って利用代金の額を算出することができる。即ち、複数のアプリケーションサーバ間で課金管理の統一性を実現することができるという利点がある。
【００２２】
また、請求項５の発明は、アプリケーションプログラムの応答時間データを、前記複数のアプリケーションサーバのそれぞれから前記データサーバに定期的に送受信する監視ステップと、前記第１のステップ前にアプリケーションプログラムに対する接続要求データとユーザ識別データとを、前記ユーザ端末から前記複数のアプリケーションサーバのうち何れか一のアプリケーションサーバに送受信するログインステップと、前記ユーザ識別データと前記データサーバに予め格納されるユーザ識別データとを前記何れか一のアプリケーションサーバにおいて比較し一致する場合に、前記第１のステップに係る予め認証された認証証明書データを、前記データサーバに格納し、前記応答時間データのそれぞれを前記データサーバから前記何れか一のアプリケーションサーバに送受信して、前記応答時間データのそれぞれのうち最も応答時間が短いアプリケーションプログラムが格納される最速アプリケーションサーバを指定するメニューデータを作成し、且つ前記予め認証された認証証明書データと前記メニューデータとを、前記何れか一のアプリケーションサーバから前記ユーザ端末に送受信する認証ステップとを含み、前記メニューデータに基づいて前記ユーザ端末から前記最速アプリケーションサーバに接続するとともに、前記第１のステップに係る一のアプリケーションサーバが前記最速アプリケーションサーバとして前記第１のステップを実行することを特徴とする請求項１から請求項４の何れか一に記載のアプリケーション・サービスを提供する方法である。
【００２３】
したがって請求項５の発明によれば、請求項１から請求項４の何れか一の発明の利点があるとともに、アプリケーションプログラムの応答時間データが監視されているので、アプリケーションプログラムの処理速度の低下を確実に防止することができるという利点がある。
【００２４】
また、請求項６の発明は、前記第２のステップ及び／又は前記第５のステップは、前記認証証明書データと前記予め格納された認証証明書データとを比較し一致する場合に、前記予め格納される認証証明書データを、新たな認証証明書データに前記一のアプリケーションサーバ及び／又は前記他のアプリケーションサーバにおいて変更し、且つ前記新たな認証証明書データを、前記データサーバに格納するステップを含み、前記再度認証された認証証明書データを、前記新たな認証証明書データとして送受信することを特徴とする請求項１から請求項５の何れか一に記載のアプリケーション・サービスを提供する方法である。
【００２５】
また、請求項７の発明は、前記第１のステップに係る認証証明書データが、予め暗号化された暗号化済認証証明書データであり、前記第２のステップ及び／又は前記第５のステップは、前記予め認証された認証証明書データを、前記一のアプリケーションサーバ及び／又は前記他のアプリケーションサーバにおいて暗号化し暗号化済認証証明書データを生成し、且つ前記暗号化済認証証明書データを前記データサーバに格納するステップを含み、前記再度認証された認証証明書データとして、前記暗号化済認証証明書データを送受信することを特徴とする請求項１から請求項６の何れか一に記載のアプリケーション・サービスを提供する方法である。
【００２６】
したがって請求項６又は請求項７の発明によれば、認証証明書データの偽造を防止することができるという利点がある。
【００３６】
尚、現在のアプリケーション・サービスを提供する方法及びシステムには次のような問題もあった。
【００３７】
ベンダー自ら業務プロセスプログラム（ユーザ認証プログラム、課金処理プログラム等）を開発する必要があるので、業務プロセスプログラムの開発に必要な設備（プログラム開発者、プログラム開発用サーバ等）を導入する必要がある。即ち、ベンダー自らが業務プロセスプログラムの開発に必要な設備を導入し、業務プロセスを運用する必要がある。この設備の導入コスト及び業務プロセスの運用コストは高額であるので、事実上多くの資本を有する大手ベンダーのみがアプリケーション・サービス・プロバイダ（ＡＳＰ）となっている。従って、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できないという問題があった。
【００３８】
また、業務プロセスプログラムの開発に必要な設備の導入コスト及び業務プロセスの運用コストは高額であるので、大手ベンダーでさえアプリケーションプログラムを高価格でユーザに利用させて、初めて導入コスト及び運用コストの採算が取れているのが現状である。従って、ユーザが利用可能なアプリケーションプログラムの数若しくは種類が事実上少ないという問題があった。
【００３９】
更に、大手ベンダーが個々にアプリケーション・サービス・プロバイダ（ＡＳＰ）となるので、ユーザはアプリケーション・サービス・プロバイダ（ＡＳＰ）毎に予め契約を結び、且つアプリケーションプログラムの利用代金を支払う必要がある。従って、ユーザは契約、利用代金の支払い等の事務手続が煩雑であるという問題があった。
【００４０】
また請求項１３は、認証システムによって予め認証された認証証明書データが、アプリケーションプログラムに入力され、
前記予め認証された認証証明書データが、認証ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を介して前記認証システムに入力され、
且つ前記認証システムによって再度認証された認証証明書データが、前記認証ＡＰＩを介して前記アプリケーションプログラムに出力されるステップを含むこと特徴とする認証関数プログラムによるユーザの認証方法である。
【００４１】
また請求項１４は、請求項１３に記載のステップを実行させるための認証関数プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００４２】
したがって請求項１３又は請求項１４の発明によれば、アプリケーションプログラムに認証ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を組み込むだけで、アプリケーションプログラムはユーザの管理ができる。即ち、アプリケーションプログラムを開発するだけで、ユーザ認証プログラムを開発する必要がなくなる。これにより、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００４３】
また請求項１５は、アプリケーションプログラムに対する会話要求データが、前記アプリケーションプログラムに入力される第１のステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する利用実績データが、前記アプリケーションプログラムによって作成される第３のステップと、
前記利用実績データが、課金ＡＰＩを介して課金システムに入力される第４のステップと、を含むこと特徴とする課金関数プログラムによるユーザの課金方法である。
【００４４】
したがって請求項１５の発明によれば、アプリケーションプログラムに課金ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を組み込むだけで、アプリケーションプログラムはユーザの課金ができる。即ち、アプリケーションプログラムを開発するだけで、課金処理プログラムを開発する必要がなくなる。これにより、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００４５】
また請求項１６は、前記第１のステップ後前記第２のステップ前に処理開始時刻が、前記アプリケーションプログラムによって作成されるステップと、
前記第２のステップ後前記第３のステップ前に処理終了時刻が、前記アプリケーションプログラムによって作成されるステップと、を含み、
前記第３のステップは、前記処理開始時刻及び前記処理終了時刻に基づいて前記利用実績データが作成されることを特徴とする請求項１５に記載の課金関数プログラムによるユーザの課金方法である。
【００４６】
また請求項１７は、前記第３のステップは、前記会話要求データ及び前記会話応答データに基づく課金項目に基づき前記利用実績データが作成されることを特徴とする請求項１５又は請求項１６に記載の課金関数プログラムによるユーザの課金方法である。
【００４７】
また請求項１８は、請求項１５から請求項１７の何れか一に記載の全てのステップを実行させるための課金関数プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００４８】
したがって請求項１６から請求項１８の何れか一の発明によれば、アプリケーションプログラムはユーザの利用態様に応じて課金ができる。
【００４９】
また請求項１９は、認証システムによって予め認証された認証証明書データが、ユーザ端末からアプリケーションプログラムに受信され、
前記予め認証された認証証明書データが、前記認証ＡＰＩを介して前記認証システムに入力され、
且つ前記認証システムによって再度認証された認証証明書データが、前記認証ＡＰＩを介して前記アプリケーションプログラムからユーザ端末に送信されるステップとを含むこと特徴とするアプリケーションプログラムによるユーザの認証方法である。
【００５０】
また請求項２０は、アプリケーションプログラムに対する会話要求データが、ユーザ端末から前記アプリケーションプログラムに受信される第１のステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する利用実績データが、前記アプリケーションプログラムによって作成される第３のステップと、
前記利用実績データが、課金ＡＰＩを介して前記アプリケーションプログラムから課金システムに入力される第４のステップと、を含むこと特徴とするアプリケーションプログラムによるユーザの課金方法である。
【００５１】
また請求項２１は、前記第１のステップ後前記第２のステップ前に処理開始時刻が、前記アプリケーションプログラムによって作成されるステップと、
前記第２のステップ後前記第３のステップ前に処理終了時刻が、前記アプリケーションプログラムによって作成されるステップと、を含み、
前記第３のステップは、前記処理開始時刻及び前記処理終了時刻に基づいて前記利用実績データが作成されることを特徴とする請求項２０に記載のアプリケーションプログラムによるユーザの課金方法である。
【００５２】
また請求項２２は、前記第３のステップは、前記会話要求データ及び前記会話応答データに基づく課金項目に基づき前記利用実績データが作成されることを特徴とする請求項２０又は請求項２１に記載のアプリケーションプログラムによるユーザの課金方法である。
【００５３】
また請求項２３は、請求項１９に記載のステップと、
請求項２０から請求項２２の何れか一に記載の全てのステップと、を含むことを特徴とするユーザの課金及び課金方法である。
【００５４】
また請求項２４は、請求項１９から請求項２３の何れか一に記載の全てのステップを実行させるためのアプリケーションプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５５】
したがって請求項１９から請求項２４の何れか一の発明によれば、認証ＡＰＩ及び／又は課金ＡＰＩを組み込んだアプリケーションプログラムを作成するだけで、アプリケーションプログラムはユーザの認証及び／又課金はができる。即ち、認証ＡＰＩ及び／又は課金ＡＰＩを組み込んだアプリケーションプログラムを開発するだけで、ユーザ認証及び／又は課金処理プログラムを開発する必要がなくなる。これにより、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００５６】
また請求項２５は、ユーザ識別データが、ユーザ端末からアプリケーションサーバに格納される認証システムに受信されるログインステップと、
前記ユーザ識別データが、前記認証システムによって認証され、
前記認証システムによって予め認証された認証証明書データが、前記認証システムから前記ユーザ端末に送信される認証ステップと、
アプリケーションプログラムに対する会話要求データと前記予め認証された認証証明書データとが、前記ユーザ端末から前記アプリケーションプログラムに受信される第１のステップと、
前記予め認証された認証証明書データが、前記アプリケーションプログラムに組み込まれた認証ＡＰＩを介して前記認証システムに入力され、
前記予め認証された認証証明書データが、前記認証システムによって再度認証され、
前記認証システムによって再度認証された認証証明書データが、認証ＡＰＩを介して前記アプリケーションプログラムに出力される再認証ステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する利用実績データが、前記アプリケーションプログラムによって作成される第３のステップと、
前記再度認証された認証証明書データと前記会話応答データとが、前記アプリケーションプログラムからユーザ端末に送信されるステップと、
前記利用実績データが、課金ＡＰＩを介して前記アプリケーションプログラムからデータサーバに格納される課金システムに入力される第４のステップと、を含むこと特徴とするアプリケーションサーバによるユーザの認証及び課金方法である。
【００５７】
また請求項２６は、請求項２５に記載の全てのステップを実行させるためのアプリケーションサーバに格納されるアプリケーションプログラム及び認証システムプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５８】
したがって請求項２５又は請求項２６の発明によれば、認証ＡＰＩ及び課金ＡＰＩを組み込んだアプリケーションプログラムと認証システムとをアプリケーションサーバに格納するだけで、ベンターはアプリケーション・サービスを提供することができる。即ち、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００５９】
また請求項２７は、ユーザ識別データが、ユーザ端末からアプリケーションサーバに格納される認証システムに送受信されるログインステップと、
前記ユーザ識別データが、前記認証システムによって認証され、
前記認証システムによって予め認証された認証証明書データが、前記認証システムから前記ユーザ端末に送信される認証ステップと、
アプリケーションプログラムに対する会話要求データと前記予め認証された認証証明書データとが、前記ユーザ端末から前記アプリケーションプログラムに送受信される第１のステップと、
前記予め認証された認証証明書データが、前記アプリケーションプログラムに組み込まれた認証ＡＰＩを介して前記認証システムに入力され、
前記予め認証された認証証明書データが、前記認証システムによって再度認証され、
前記認証システムによって再度認証された認証証明書データが、認証ＡＰＩを介して前記アプリケーションプログラムに出力される再認証ステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する利用実績データが、前記アプリケーションプログラムによって作成される第３のステップと、
前記再度認証された認証証明書データと前記会話応答データとが、前記アプリケーションプログラムからユーザ端末に送受信されるステップと、
前記利用実績データが、課金ＡＰＩを介して前記アプリケーションプログラムからデータサーバに格納される課金システムに入力される第４のステップと、を含むこと特徴とするアプリケーション・サービスを提供する方法である。
【００６０】
したがって請求項２７の発明によれば、認証ＡＰＩ及び課金ＡＰＩを組み込んだアプリケーションプログラムと認証システムとをアプリケーションサーバに格納するだけで、ベンターはアプリケーション・サービスを提供することができる。即ち、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００６１】
また、ベンダーはユーザ認証及び課金処理プログラムを開発する必要がなくなるので、新たなアプリケーションプログラムを開発することができる。この場合、この新たなアプリケーションプログラムをアプリケーションサーバに格納するだけで、ベンターは複数のアプリケーション・サービスを提供することができる。即ち、ユーザが利用可能なアプリケーションプログラムの数若しくは種類が多くなるという利点がある。
ここで、複数のアプリケーションプログラムがそれぞれ認証ＡＰＩを介して一の認証システムによって、ユーザを識別することができる。換言すれば、複数のアプリケーションプログラム間でユーザ管理の統一性を実現することができる。
【００６２】
更に、別のベンダーが別のアプリケーションプログラムを開発した場合、複数のアプリケーションプログラムと一の認証システムとをアプリケーションサーバに別のアプリケーションプログラムを格納するだけで、別のベンダーもアプリケーション・サービスを提供することができる。即ち、アプリケーションサーバは複数のベンダーのアプリケーションプログラムをユーザに有償で利用させることができる。
ここで、複数のベンダーのアプリケーションプログラムがそれぞれ課金ＡＰＩを介して一の課金システムによって、利用実績データを集計して利用金額を算出することができる。換言すれば、複数のベンダーの間で課金管理の統一性を実現することができる。課金システムはユーザ別に利用金額を算出してユーザに支払いを求める一方、課金システムはベンダー別に利用金額を算出してベンダーに支払う。これにより、ユーザは利用代金の支払い等の事務手続が煩雑でないという利点がある。
【００６３】
また請求項２８は、前記再認証ステップは、前記予め認証された認証証明書データと認証データ保持システムに予め格納された認証証明書データとが前記認証システムによって比較されて一致する場合に、
前記予め格納される認証証明書データが、新たな認証証明書データに前記認証システムによって変更され、
且つ前記新たな認証証明書データが、前記データサーバに格納される認証データ保持システムに格納されるステップを含み、
前記再度認証された認証証明書データが、前記新たな認証証明書データとして出力されることを特徴とする請求項２７に記載のアプリケーション・サービスを提供する方法である。
【００６４】
また請求項２９は、前記認証ステップに係る認証証明書データが、前記認証システムによって予め暗号化された暗号化済認証証明書データであり、
前記再認証ステップは、前記予め認証された認証証明書データと認証データ保持システムに予め格納された認証証明書データとが前記認証システムによって比較されて一致する場合に、
前記予め格納される認証証明書データが、新たな暗号化済認証証明書データに前記認証システムによって暗号化され、
且つ前記新たな暗号化済認証証明書データが、前記データサーバに格納される認証データ保持システムに格納されるステップを含み、
前記再度認証された認証証明書データが、前記新たな暗号化済認証証明書データとして出力されることを特徴とする請求項２７又は請求項２８に記載のアプリケーション・サービスを提供する方法である。
【００６５】
したがって請求項２８又は請求項２９の発明によれば、認証証明書データの偽造を防止することができるという利点がある。
【００６６】
また請求項３０は、ユーザ識別データをユーザ端末から受信し、
前記ユーザ識別データを認証して予め認証された認証証明書データをユーザ端末に送信し、
前記予め認証された認証証明書データをアプリケーションプログラムから前記アプリケーションプログラムに組み込まれた認証ＡＰＩを介して入力され、
前記予め認証された認証証明書データを再度認証して再度認証された認証証明書データを前記アプリケーションプログラムに前記認証ＡＰＩを介して出力する認証システムと、
前記会話要求データと前記予め認証された認証証明書データとを前記ユーザ端末から受信し、
前記予め認証された認証証明書データを前記認証システムに入力し、
前記再度認証された認証証明書データを前記認証システムから出力され、
前記会話要求データに対する会話応答データと利用実績データとを作成し、
前記前記再度認証された認証証明書データと前記会話返答データとを前記ユーザ端末に送信し、
前記利用実績データを課金ＡＰＩを介してデータサーバに格納される課金システムに入力するアプリケーションプログラムと、備えることを特徴とするアプリケーションサーバである。
【００６７】
また請求項３１は、アプリケーションサーバに格納される認証システムによって予め認証された認証証明書データを前記認証システムから格納され、
前記認証システムによって再度認証された認証証明書データを前記認証システムから格納される認証データ保持システムと、
利用実績データを前記アプリケーションサーバに格納されるアプリケーションから前記アプリケーションプログラムに組み込まれる認証ＡＰＩを介して入力される課金システムと、を備えるデータサーバである。
【００６８】
また請求項３２は、請求項３０に記載のアプリケーションサーバと、請求項３１に記載のデータサーバと、から構成されてなるアプリケーション・サービスを提供するシステムである。
【００６９】
したがって請求項３０から請求項３２何れか一の発明によれば、認証ＡＰＩ及び課金ＡＰＩを組み込んだアプリケーションプログラムと認証システムとをアプリケーションサーバに格納するだけで、ベンターはアプリケーション・サービスを提供することができる。即ち、ベンダーがアプリケーション・サービス・プロバイダの事業に容易に参入できるという利点がある。
【００７０】
また、ベンダーはユーザ認証及び課金処理プログラムを開発する必要がなくなるので、新たなアプリケーションプログラムを開発することができる。この場合、この新たなアプリケーションプログラムをアプリケーションサーバに格納するだけで、ベンターは複数のアプリケーション・サービスを提供することができる。即ち、ユーザが利用可能なアプリケーションプログラムの数若しくは種類が多くなるという利点がある。
ここで、複数のアプリケーションプログラムがそれぞれ認証ＡＰＩを介して一の認証システムによって、ユーザを識別することができる。換言すれば、複数のアプリケーションプログラム間でユーザ管理の統一性を実現することができる。
【００７１】
更に、別のベンダーが別のアプリケーションプログラムを開発した場合、複数のアプリケーションプログラムと一の認証システムとをアプリケーションサーバに別のアプリケーションプログラムを格納するだけで、別のベンダーもアプリケーション・サービスを提供することができる。即ち、アプリケーションサーバは複数のベンダーのアプリケーションプログラムをユーザに有償で利用させることができる。
ここで、複数のベンダーのアプリケーションプログラムがそれぞれ課金ＡＰＩを介して一の課金システムによって、利用実績データを集計して利用金額を算出することができる。換言すれば、複数のベンダーの間で課金管理の統一性を実現することができる。課金システムはユーザ別に利用金額を算出してユーザに支払いを求める一方、課金システムはベンダー別に利用金額を算出してベンダーに支払う。これにより、ユーザは利用代金の支払い等の事務手続が煩雑でないという利点がある。
【００７２】
尚、現在のアプリケーション・サービスを提供する方法及びシステムには次のような問題もあった。
【００７３】
［アプリケーションプログラムの負荷分散］
あるアプリケーションプログラムＡに複数のユーザからの接続の要求のそれぞれが同時期に集中すると、このアプリケーションプログラムＡを格納するサーバＡの負荷が高くなる。この場合、アプリケーションプログラムＡの処理速度が低下するので、アプリケーションプログラムＡは複数のユーザに対する応答時間のそれぞれが遅くなり、サーバＡのネットワークトラフック量は減少することになる。この時、ロードバランサー（従来のアプリケーションプログラムの負荷を分散する装置）が複数のサーバのネットワークトラフック量を計測し、且つ最も少ないネットワークトラフック量がサーバＡである場合には、ロードバランサーはあるユーザの接続をサーバＡのアプリケーションプログラムＡに振り向けることになる。
即ち、アプリケーションプログラムの負荷が高くても、ユーザがこのアプリケーションプログラムに接続することもあるので、アプリケーションプログラムの負荷の分散が必ずしも正確にできないという問題があった。
【００７４】
［待機するアプリケーションプログラムへの切替］
また、ロードバランサー、クラスタリング（従来の待機するアプリケーションプログラムへの切り替え装置）によっても、正常稼動を確認するための通信はサーバ単位で実行しているので、障害時の待機系への切り替えはサーバ単位に行っていることになる。従って、例えば、あるサーバＡのアプリケーションプログラムＡに障害が発生し、且つサーバＡのアプリケーションプログラムＢが正常稼動している場合、サーバＡに障害が発生したことになるので、待機するサーバＢに切り替わることになる。この時、サーバＡで正常稼動しているアプリケーションプログラムＢを利用するユーザは、サーバＡのアプリケーションプログラムＢを強制的に終了させられる、又はサーバＡから待機するサーバＢに切り替わる間にアプリケーションプログラムＢを利用することができない。
即ち、接続するサーバのアプリケーションプログラムが正常稼動していても、待機するサーバのアプリケーションプログラムに切り替わることもあるので、待機するアプリケーションプログラムへの切替が必ずしも正確にできないという問題があった。
【００７５】
また請求項３３は、アプリケーションプログラムに対する会話要求データが、アプリケーションプログラムに入力される第１のステップと、
前記第１のステップ後に処理開始時刻が、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムから出力される第３のステップと、
前記第３のステップ後に処理終了時刻が、前記アプリケーションプログラムによって作成される第４のステップと、
前記アプリケーションプログラムの応答時間データが、前記処理開始時刻及び前記処理終了時刻に基づいて前記アプリケーションプログラムによって作成される第５のステップと、
前記応答時間データが、前記アプリケーションプログラムから監視ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）に入力される第６のステップと、監視要求データが、監視システム（エージェント）から前記監視ＡＰＩに入力される第７のステップと、
前記応答時間データが、前記監視ＡＰＩから前記監視システム（エージェント）に出力される第８のステップと、を含むことを特徴とする監視関数プログラムによるアプリケーションプログラムの監視方法である。
【００７６】
したがって請求項３３の発明によれば、アプリケーションプログラムの応答時間を監視することができるので、アプリケーションプログラムに対する接続の要求等の負荷が一のアプリケーションプログラムに集中する場合、複数のアプリケーションプログラムのうち応答時間が短い他のアプリケーションプログラムに負荷を処理させることができる。即ち、一のアプリケーションプログラムの処理速度の低下を防ぐことができる。換言すれば、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
【００７７】
また請求項３４は、前記第８のステップ前に前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、及び前記第７のステップの一連のステッップがＮ（Ｎは１以上）回以上繰り返して実行される第９のステップを含み、
前記第８のステップは、前記第９のステップが実行される結果として、
前記監視ＡＰＩに入力される前記Ｎ個の応答時間データに基づく平均応答時間データが、前記第８のステップに係る応答時間データとして出力されることを特徴とする請求項３３に記載の監視関数プログラムによるアプリケーションプログラムの監視方法である。
【００７８】
したがって請求項３４の発明によれば、請求項３３の発明の利点があるとともに、アプリケーションプログラムの応答時間を正確に監視することができる。これにより、アプリケーションプログラムの負荷分散を更に正確に行うことができるという利点がある。
【００７９】
また請求項３５は、請求項３３又は請求項３４に記載の全てのステップを実行させるための監視関数プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００８０】
したがって請求項３５の発明によれば、アプリケーションプログラムに監視ＡＰＩを組み込むだけで、アプリケーションプログラムの応答時間を監視することができる。これにより、アプリケーションプログラムの負荷分散を更に正確に行うことができるという利点がある。
【００８１】
また請求項３６は、アプリケーションプログラムに対する会話要求データが、ユーザ端末からアプリケーションプログラムに受信される第１のステップと、
前記第１のステップ後に処理開始時刻が、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムから前記ユーザ端末に送信される第３のステップと、
前記第３のステップ後に処理終了時刻が、前記アプリケーションプログラムによって作成される第４のステップと、
前記アプリケーションプログラムの応答時間データが、前記処理開始時刻及び前記処理終了時刻に基づいて前記アプリケーションプログラムによって作成される第５のステップと、
前記応答時間データが、前記アプリケーションプログラムから監視ＡＰＩに入力される第６のステップと、
監視要求データが、監視システム（エージェント）から前記監視ＡＰＩに入力される第７のステップと、
前記応答時間データが、前記監視ＡＰＩから前記監視システム（エージェント）に出力される第８のステップと、を含むことを特徴とするアプリケーションプログラムによるアプリケーションプログラムの監視方法である。
【００８２】
また請求項３７は、前記第８のステップ前に前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、及び前記第７のステップの一連のステッップがＮ（Ｎは１以上）回以上繰り返して実行される第９のステップを含み、
前記第８のステップは、前記第９のステップが実行される結果として、
前記監視ＡＰＩに入力される前記Ｎ個の応答時間データに基づく平均応答時間データが、前記第８のステップに係る応答時間データとして出力されることを特徴とする請求項３６に記載のアプリケーションプログラムによるアプリケーションプログラムの監視方法である。
【００８３】
また請求項３８は、請求項３６又は請求項３７に記載の全てのステップを実行させるためのアプリケーションプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００８４】
したがって請求項３６から請求項３８の何れか一の発明によれば、アプリケーションプログラムの応答時間を監視することができるので、アプリケーションプログラムに対する接続の要求等の負荷が一のアプリケーションプログラムに集中する場合、複数のアプリケーションプログラムのうち応答時間が短い他のアプリケーションプログラムに負荷を処理させることができる。即ち、一のアプリケーションプログラムの処理速度の低下を防ぐことができる。換言すれば、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
【００８５】
また請求項３９は、アプリケーションサーバに格納されるアプリケーションプログラムに対する会話要求データが、ユーザ端末からアプリケーションプログラムに受信される第１のステップと、
前記第１のステップ後に処理開始時刻が、前記アプリケーションプログラムによって作成される第２のステップと、
前記会話要求データに対する会話応答データが、前記アプリケーションプログラムから前記ユーザ端末に送信される第３のステップと、
前記第３のステップ後に処理終了時刻が、前記アプリケーションプログラムによって作成される第４のステップと、
前記アプリケーションプログラムの応答時間データが、前記処理開始時刻及び前記処理終了時刻に基づいて前記アプリケーションプログラムによって作成される第５のステップと、
前記応答時間データが、前記アプリケーションプログラムから前記アプリケーションプログラムに組み込まれた監視ＡＰＩに入力される第６のステップと、
監視要求データが、前記アプリケーションサーバに格納される監視システム（エージェント）から前記監視ＡＰＩに入力される第７のステップと、
前記応答時間データが、前記監視ＡＰＩから前記監視システム（エージェント）に出力される第８のステップと、を含むことを特徴とするアプリケーションサーバによるアプリケーションプログラムの監視方法である。
【００８６】
また請求項４０は、前記第８のステップ前に前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、及び前記第７のステップの一連のステッップがＮ（Ｎは１以上）回以上繰り返して実行される第９のステップを含み、
前記第８のステップは、前記第９のステップが実行される結果として、
前記監視ＡＰＩに入力される前記Ｎ個の応答時間データに基づく平均応答時間データが、前記第８のステップに係る応答時間データとして出力されることを特徴とする請求項３９に記載のアプリケーションサーバによるアプリケーションプログラムの監視方法である。
【００８７】
したがって請求項３９又は請求項４０の発明によれば、アプリケーションプログラムの応答時間を監視することができる。これにより、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
【００８８】
また請求項４１は、前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、前記第７のステップ、前記第９のステップ、及び前記第８のステップの一連のステッップがＭ（Ｍは１以上）回以上繰り返して実行される第１０のステップと、
前記第９のステップが実行される結果として、
前記第８のステップに係る平均応答時間データが、前記監視システム（エージェント）に前記Ｍ回出力されない場合、
前記アプリケーションプログラムに障害が発生した旨の障害発生データが、前記監視システム（エージェント）によって作成される第１１のステップと、を含むことを特徴とする請求項４０に記載のアプリケーションサーバによるアプリケーションプログラムの監視方法である。
【００８９】
したがって請求項４１の発明によれば、請求項３９又は請求項４０の発明の利点があるとともに、アプリケーションプログラム単位で障害の発生を監視することができる。これにより、アプリケーションサーバに障害の発生が発生したアプリケーションプログラムと正常稼動する他のアプリケーションとが格納される場合、障害の発生が発生したアプリケーションプログラムを利用するユーザのみを待機するアプリケーションプログラムへ切り替えることができる。一方、正常稼動する他のアプリケーションを利用するユーザは、引き続き他のアプリケーションを利用し続けることができる。これにより、待機するアプリケーションプログラムへの切替を正確に行うことのできるという利点がある。
【００９０】
また、請求項４２は、請求項３９から請求項４１の何れか一に記載の全てのステップを実行させるためのアプリケーションサーバに格納されるアプリケーションプログラム及び監視システム（エージェント）プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００９１】
したがって請求項４２の発明によれば、アプリケーションプログラム及び監視システム（エージェント）をアプリケーションサーバに格納することにより、アプリケーションプログラムの応答時間を監視することができる。これにより、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
また、アプリケーションプログラム単位で障害の発生を監視することができる。これにより、待機するアプリケーションプログラムへの切替を正確に行うことのできるという利点がある。
【００９２】
また請求項４３は、複数のアプリケーションサーバに格納されるアプリケーションプログラムのそれぞれに対する会話要求データが、ユーザ端末からアプリケーションプログラムのそれぞれに送受信される第１のステップと
前記第１のステップ後に処理開始時刻が、前記アプリケーションプログラムのそれぞれによって作成される第２のステップと
前記会話要求データのそれぞれに対する会話応答データが、前記アプリケーションプログラムのそれぞれから前記ユーザ端末に送受信される第３のステップと
前記第３のステップ後に処理終了時刻が、前記アプリケーションプログラムのそれぞれによって作成される第４のステップと
前記アプリケーションプログラムのそれぞれの応答時間データが、前記処理開始時刻及び前記処理終了時刻に基づいて前記アプリケーションプログラムのそれぞれによって作成される第５のステップと
前記応答時間データが、前記アプリケーションプログラムから前記アプリケーションプログラムに組み込まれた監視ＡＰＩのそれぞれに入力される第６のステップと
監視要求データが、前記アプリケーションサーバに格納される監視システム（エージェント）のそれぞれから前記監視ＡＰＩに入力される第７のステップと、
前記応答時間データが、前記監視ＡＰＩのそれぞれから前記監視システム（エージェント）のそれぞれに出力される第８のステップと
前記応答時間データが、前記監視システム（エージェント）のそれぞれからデータサーバに格納されるサーバリストのそれぞれに格納される第９のステップとから成る監視ステップと、
前記アプリケーションプログラムのそれぞれのうち何れか一のアプリケーションプログラムに対する接続要求データが、あるユーザ端末から前記何れか一のアプリケーションプログラムが格納される何れか一のアプリケーションサーバに格納される動的メニュー生成システムに送受信されるステップと、
前記サーバリストのそれぞれに格納される応答時間データが、前記データサーバから前記動的メニュー生成システムに入力され、
前記応答時間データのそれぞれのうち最も応答時間が短いアプリケーションプログラムが格納される最速アプリケーションサーバを特定し得るメニューデータが、前記動的メニュー生成システムによって作成され、
且つ前記メニューデータが、前記動的メニュー生成システムから前記あるユーザ端末に送受信される動的メニューステップと、を含むことを特徴とするアプリケーション・サービスを提供する方法である。
【００９３】
したがって請求項４３の発明によれば、アプリケーションプログラムの応答時間データが監視されているので、あるユーザを最速アプリケーションサーバに振り向けることができる。これにより、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
【００９４】
また請求項４４は、前記監視ステップは、前記第８のステップ前に前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、及び前記第７のステップの一連のステッップがＮ（Ｎは１以上）回以上繰り返して実行される第１０のステップから成り、
前記第８のステップは、前記第１０のステップが実行される結果として、
前記監視ＡＰＩのそれぞれに入力される前記Ｎ個の応答時間データに基づく平均応答時間データが、前記第８のステップに係る応答時間データのそれぞれとして出力され、
前記第９のステップに係るサーバリストは、前記平均応答時間データのそれぞれが応答時間データのそれぞれとして格納され、
前記動的メニューステップは、前記平均応答時間データのそれぞれが、前記動的メニューステップに係る応答時間データのそれぞれとして前記データサーバから出力され、
且つ前記メニューデータは、前記平均応答時間データのそれぞれが前記動的メニューステップに係る応答時間データのそれぞれとして作成されることを特徴とする請求項４３に記載のアプリケーション・サービスを提供する方法である。
【００９５】
したがって請求項４４の発明によれば、請求項４３の発明の利点があるとともに、アプリケーションプログラムの応答時間データを正確に監視することができる。これにより、アプリケーションプログラムの負荷分散を更に正確に行うことができるという利点がある。
【００９６】
また、請求項４５は、前記監視ステップは、前記第１のステップ、前記第２のステップ、前記第３のステップ、前記第４のステップ、前記第５のステップ、及び前記第６のステップ、前記第７のステップ、前記第１０のステップ、及び前記第８のステップの一連のステッップがＭ（Ｍは１以上）回以上繰り返して実行される第１１のステップと、
前記第１０のステップが実行される結果として、
前記第８のステップに係る平均応答時間データが、前記監視ＡＰＩのうちある監視ＡＰＩから前記監視システム（エージェント）に前記Ｍ回出力されない場合、前記ある監視ＡＰＩが組み込まれたあるアプリケーションプログラムに障害が発生した旨の障害発生データが、前記あるアプリケーションプログラムが格納されるあるアプリケーションサーバに格納されるある監視システム（エージェント）によって作成される第１２のステップと、
前記障害発生データが、前記ある監視システム（エージェント）から前記サーバリストのうちあるサーバリストに格納される第１３のステップと、から成り、
前記動的メニューステップは、前記あるサーバリストに格納される障害発生データが、前記データサーバから前記動的メニュー生成システムに入力される場合、前記メニューデータは、前記障害発生データを作成したあるアプリケーションサーバを除外した最速アプリケーションサーバを特定し得るものであることを特徴とする請求項４４に記載のアプリケーション・サービスを提供する方法である。
【００９７】
したがって請求項４５の発明によれば、請求項４３又は請求項４４の発明の利点があるとともに、アプリケーションプログラム単位で障害の発生を監視することができる。これにより、アプリケーションサーバに障害の発生が発生したアプリケーションプログラムと正常稼動する他のアプリケーションとが格納される場合、障害の発生が発生したアプリケーションプログラムを利用するユーザのみを待機するアプリケーションプログラムへ切り替えることができる。一方、正常稼動する他のアプリケーションを利用するユーザは、引き続き他のアプリケーションを利用し続けることができる。これにより、待機するアプリケーションプログラムへの切替を正確に行うことのできるという利点がある。
【００９８】
また請求項４６は、アプリケーションプログラムの応答時間データが、前記複数のアプリケーションサーバのそれぞれから前記データサーバに定期的に送受信される監視ステップと、
前記アプリケーションプログラムのそれぞれのうち何れか一のアプリケーションプログラムに対する接続要求データが、あるユーザ端末から前記何れか一のアプリケーションプログラムが格納される何れか一のアプリケーションサーバに送受信されるステップと、
前記応答時間データのそれぞれが、前記データサーバから前記何れか一のアプリケーションサーバに送受信され、
且つ前記応答時間データのそれぞれのうち最も応答時間が短いアプリケーションプログラムが格納される最速アプリケーションサーバを特定し得るメニューデータが、前記何れか一のアプリケーションサーバから前記あるユーザ端末に送受信されるステップと、を含むアプリケーションプログラムの監視方法である。
【００９９】
したがって請求項４６の発明によれば、アプリケーションプログラムの応答時間データが監視されているので、あるユーザを最速アプリケーションサーバに振り向けることができる。これにより、アプリケーションプログラムの負荷分散を正確に行うことができるという利点がある。
【０１００】
【発明の実施の形態】
以下に本発明の実施の形態のアプリケーション・サービスを提供する方法及びシステムにつき図面を参照して説明する。
【０１０１】
（実施の形態１）
まず、本発明の実施の形態１のアプリケーション・サービスを提供するシステムにつき、図５を参照して、説明する。
図５は本発明の実施の形態１のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
【０１０２】
先ず、図５を参照するに、本実施の形態１のアプリケーション・サービスを提供するシステムは、アプリケーションプログラムを利用するユーザ端末（１００）と、アプリケーションプログラムが動作する複数のアプリケーションサーバ（３００，４００，．．．）と、各種のデータを格納するデータサーバ（５００）と、から構成されてなる。
ここで、ユーザ端末（１００）と、複数のアプリケーションサーバ（３００，４００，．．．）のそれぞれとは、コンピュータネットワーク（２００）を介して相互に接続可能に構成されている。また、データサーバ（５００）と、１以上のアプリケーションサーバ（３００，４００，．．．）とは、主として同一組織内で用いられる総合的な情報通信ネットワーク（ＬＡＮ：Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、公衆回線、又は専用線等を介して相互に接続可能に構成されている。尚、ユーザ端末（１００）と、複数のアプリケーションサーバ（３００，４００，．．．）と、データサーバ（５００）とが、コンピュータネットワーク（２００）を介して相互に接続可能に構成されていてもよい。
また、コンピュータネットワーク（２００）とは、例えば、インターネット（Ｉｎｔｅｒｎｅｔ）、広域通信網（ＷＡＮ：Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等である。更に、コンピュータネットワーク（２００）、ＬＡＮ等は、有線、無線を問わず、ユーザ端末（１００）とアプリケーションサーバ（３００，４００，．．．）との間、ユーザ端末（１００）とデータサーバ（５００）との間、アプリケーションサーバ（３００，４００，．．．）とデータサーバ（５００）との間、及びユーザ端末（１００）とアプリケーションサーバ（３００，４００，．．．）とデータサーバ（５００）との間のぞれぞれでデータを送受信するためのものであればよい。
【０１０３】
ユーザ端末（１００）は、コンピュータネットワーク（２００）を介してホームページへのアクセス等を可能とするＷｅｂブラウザ（１０１）と、ホームページを表示可能とする表示手段（図示せず）と、文字・記号等を入力するキーボード（ボタン）、マウス等の入力手段（図示せず）と、を備える。
ここで、ユーザ端末（１００）は、例えば、パソコン（デスクトップ型パソコン、ノート型パソコン）、携帯電話機等である。
【０１０４】
複数のアプリケーションサーバ（３００，４００，．．．）のそれぞれは、ＨＴＭＬ文書データ等のリソースデータ（図示せず）を格納する記憶手段と、ユーザを認証する認証システム（３０１）と、ユーザ個別のメニューを動的に生成する動的メニュー生成システム（３０２）と、コンピュータネットワーク（２００）を介して有償で提供するアプリケーションプログラムＡ（３１０，．．．）と、Ｗｅｂサーバ（３９０）と、を備える。
また、アプリケーションプログラムＡ（３１０）のそれぞれは、認証ＡＰＩ（３０３）と課金ＡＰＩ（３０４）と、を備える。
更に、Ｗｅｂサーバ（３９０）は、ユーザ端末（１００）のＷｅｂブラウザ（１０１）とＨＴＴＰで通信する。即ち、Ｗｅｂサーバ（３９０）は、認証システム（３０１）、動的メニュー生成システム（３０２）、及びアプリケーションプログラムＡ（３１０）のそれぞれと、Ｗｅｂブラウザ（１０１）と、の通信を中継する。
ここで、アプリケーションサーバ（３００，４００，．．．）は、例えば、いわゆるサーバ（ハード・ディスク等の記憶手段の容量が大きいオフコン）、パソコン等である。
【０１０５】
データサーバ（５００）は、ユーザ認証に必要なデータ（ユーザＩＤ、パスワード、端末識別子等を含む。）を格納する認証データ保持システム（５０１）と、ユーザごとにあらかじめ合意した利用可能アプリケーションプログラムのリストを格納するメニューデータ保持システム（５０２）と、利用実績データを蓄積してユーザ別アプリケーションプログラム別請求書を作成する課金システム（５０３）と、を備える。
ここで、データサーバ（５００）は、例えば、いわゆるサーバ、パソコン等である。
【０１０６】
尚、本実施の形態１のアプリケーション・サービスを提供するシステムの構成要素のうち、認証システム（３０１）と、動的メニュー生成システム（３０２）と、認証ＡＰＩ（３０３）と、課金ＡＰＩ（３０４）と、認証データ保持システム（５０１）と、メニューデータ保持システム（５０２）と、課金システム（５０３）とが本発明の機能を有し、これらの構成要素をＡＳＰ基盤システムという。
【０１０７】
次に、本発明の実施の形態のアプリケーション・サービスを提供する方法及びシステムの前提となるアプリケーション・サービスを提供するための準備をするシステム及び方法につき、図１〜図４を参照して、説明する。尚、アプリケーション・サービスを提供するための準備をするシステム方法は、アプリケーションプログラムを準備する方法（ステップＡ１〜Ａ５）と、アプリケーションプログラムを利用するユーザの登録方法（ステップＢ１〜Ｂ５）と、から成る。
図１はアプリケーション・サービスを提供するための準備をするシステムの構成例を示すブロック図である。図２はアプリケーションプログラムを準備する方法を説明するためのフローチャート図である。
【０１０８】
予め、ＡＳＰ基盤システムのうち認証システム（３０１）と、動的メニュー生成システム（３０２）と、認証ＡＰＩ（３０３）と、課金ＡＰＩ（３０４）とが、アプリケーションサーバ１（３００）に格納されている。また、ＡＳＰ基盤システムの残りの認証データ保持システム（５０１）と、メニューデータ保持システム（５０２）と、課金システム（５０３）とが、アプリケーションサーバ１（３００）に格納されている。尚、ＡＳＰ基盤システムが格納されるサーバはアプリケーションサーバ１（３００）に限られず、ＡＳＰ基盤システムが格納できるサーバであればよい。
加えて、開発されたアプリケーションプログラムが、ベンダー端末（７００）に格納されている。
【０１０９】
［ステップＡ１］
（アプリケーションプログラムを準備する方法）
アプリケーションサーバ１（３００）に係るＡＳＰ基盤システム（認証システム（３０１）、動的メニュー生成システム（３０２）、認証ＡＰＩ（３０３）、課金ＡＰＩ（３０４））が、公衆回線若しくは専用線（２２０）、又は光磁気ディスク（ＭＯ：Ｍａｇｎｅｔｏ  Ｏｐｔｉｃａｌ  ｄｉｓｋ）、光ディスク（ＣＤ：Ｃｏｍｐａｃｔ  Ｄｉｓｋ，ＤＶＤ：Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）  、フロッピーディスク  （ＦＤ：Ｆｌｏｐｐｙ  Ｄｉｓｋ）    等の補助記憶媒体（２３０）を介してアプリケーションサーバ１（３００）からベンダー端末（７００）に提供されて格納される。
【０１１０】
［ステップＡ２］
開発されたアプリケーションプログラムをＡＳＰ基盤システムに適合されるため、提供された認証ＡＰＩ（３０３）及び課金ＡＰＩ（３０４）が、ベンダー端末（７００）によって開発されたアプリケーションプログラムに組み込まれる。
【０１１１】
［ステップＡ３］
アプリケーションサーバ２（４００）でもアプリケーションプログラムのサービスを行うため、提供された認証システム（３０１）及び動的メニュー生成システム（３０２）が、ＬＡＮ（２１０）介してベンダー端末（７００）からアプリケーションサーバ２（４００）にインストールされて格納される。尚、ここで、ＡＳＰ基盤システムの認証システム（３０１）及び動的メニュー生成システム（３０２）が、公衆回線等（２２０，２３０）を介してアプリケーションサーバ２（４００）にインストールされてもよいことは言うまでもない。
【０１１２】
［ステップＡ４］
認証ＡＰＩ（３０３）及び課金ＡＰＩ（３０４）が組み込まれたアプリケーションプログラム（３１０）が、ベンダー端末（７００）からアプリケーションサーバ１（３００）及びアプリケーションサーバ２（４００）にＬＡＮ等（２１０，２２０，２３０）を介してインストールされて格納される。
【０１１３】
［ステップＡ５］
アプリケーションサーバ１（３００）及びアプリケーションサーバ２（４００）に格納されるアプリケーションプログラム（３１０）のアプリケーション情報（機能概要、詳細説明、デモプログラムへのリンク、契約条件（料金表を含む））が、データサーバ（５００）に登録されて格納される。
【０１１４】
尚、複数のアプリケーションサーバ（３００，４００，．．．）のそれぞれに複数のアプリケーションプログラム（３１０，３２０，．．．）が格納される場合には、アプリケーションプログラム（３１０，３２０，．．．）のそれぞれに対するアプリケーション情報がデータサーバ（５００）に登録されて格納される。
【０１１５】
また、図３はアプリケーションプログラムを利用するユーザの登録方法を説明するためのフローチャート図である。
【０１１６】
［ステップＢ１］
（アプリケーションプログラムを利用するユーザの登録方法）
先ず、ユーザ端末（１００）はデータサーバ（５００）に接続する。
【０１１７】
［ステップＢ２］
これに対し、データサーバ（５００）はアプリケーション情報をユーザ端末（１００）に送信する。尚、データサーバ（５００）は、ユーザ端末（１００）から入力される検索条件とアプリケーション情報に含まれる機能概要の一部とが一致するアプリケーション情報を検索し、検索条件に一致するアプリケーション情報をユーザ端末（１００）に送信する手段を備える。
【０１１８】
［ステップＢ３］
ユーザ端末（１００）は検索条件を入力してアプリケーション情報を受信してユーザ端末（１００）の表示手段（図示せず）に表示する。ここで、例えば、図４に示すアプリケーション情報表示画面が、ユーザ端末（１００）の表示手段に表示される。
図４を参照するに、表示されるアプリケーション情報表示画面は、アプリケーション名称（例えば、日英翻訳、百科事典）、機能概要の一覧である。ここで、ユーザは表示手段に表示される「詳細表示ボタン」、「デモ表示ボタン」、及び「料金表示ボタン」のそれぞれのボタンをマウスでクリックすることができる。「詳細表示ボタン」がクリックされると、アプリケーションプログラムの機能詳細説明画面（図示せず）が表示手段に表示される。また、「デモ表示ボタン」がクリックされると、アプリケーションプログラムのアプリケーションプログラムのデモプログラムが実行され、アプリケーションデモ画面（図示せず）が表示手段に表示される。加えて、「詳細表示ボタン」がクリックされると、料金表等の契約条件を表す契約条件画面（図示せず）が表示手段に表示される。
【０１１９】
［ステップＢ４］
ユーザは、利用するアプリケーションプログラム（百科事典）を決めたら、当該アプリケーションプログラムの「ラジオボタン（選択）」をチェックして（図４中の●）、「契約申し込みボタン」をクリックする。
その後、ユーザ登録画面（図示せず）がユーザ端末（１００）の表示手段に表示され、ユーザは登録に必要なユーザ情報（企業名、責任者名、住所、電話番号、決済方法、端末識別子等）を入力してデータサーバ（５００）に送信する。ここで、端末識別子とは、ユーザ端末（１００）のＩＰアドレス（ＩＰ  ａｄｄｒｅｓｓ）若しくはフル・クォリファイド・ドメイン・ネイム（ＦＱＤＮ：Ｆｕｌｌ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）である。例えば、ＩＰアドレスは１９２．１６８．０１．００１であり、ＦＱＤＮはｗｗｗ．○○○．ｃｏ．ｊｐである。
【０１２０】
［ステップＢ５］
これに対し、データサーバ（５００）は必要なユーザ情報をユーザ端末（１００）から受信し、利用に必要なユーザ情報（ユーザＩＤ（ユーザ識別データ）、パスワード）を発行する。データサーバ（５００）は、登録に必要なユーザ情報に前記利用に必要なユーザ情報を加えたユーザ情報（ユーザＩＤ、パスワード、企業名、責任者名、住所、電話番号、決済方法、端末識別子等）を登録して格納する。
【０１２１】
［ステップＢ６］
データサーバ（５００）は、利用に必要な情報（ユーザＩＤ、パスワード）をユーザ端末（１００）に送信して通知する。
【０１２２】
次に、本発明の実施の形態のアプリケーション・サービスを提供する方法につき、図５を参照して、説明する。
【０１２３】
［ステップＣ１：ログインステップ］
アプリケーションプログラムに対する接続要求データが、ユーザ端末（１００）から複数のアプリケーションサーバ（３００，４００，．．．）のうち何れか一のアプリケーションサーバ１（３００）に送受信される。ここで、アプリケーションサーバ１（３００）は、接続要求データをＷｅｂサーバ（３９０）を介して認証システム（３０１）で受信している。これに対し、アプリケーションサーバ１（３００）は、ログイン画面データをＷｅｂサーバ（３９０）を介して認証システム（３０１）からユーザ端末（１００）に送信する。
一方、ユーザ端末（１００）は、Ｗｅｂブラウザ（１０１）を介してログイン画面データを受信すると、ログイン画面がユーザ端末（１００）の表示手段に表示される。次に、ユーザは、ログインＩＤ（ユーザ識別データ）とパスワードとを入力してアプリケーションサーバ１（３００）に送信する。これに対し、アプリケーションサーバ１（３００）は、ログインＩＤ（ユーザ識別データ）とパスワードとをＷｅｂサーバ（３９０）を介して認証システム（３０１）に入力する。
【０１２４】
尚、ログインＩＤ（ユーザ識別データ）とパスワードとのパケットデータがユーザ端末（１００）からアプリケーションサーバ１（３００）にＩＰプロトコルで送受信されるているので、パケットデータは常に送信元（ユーザ端末（１００）のＩＰアドレス）と送信先（アプリケーションサーバ１（３００）のＩＰプロトコル）とが格納されている。
従って、アプリケーションサーバ１（３００）は、ログインＩＤ（ユーザ識別データ）とパスワードとを受信するとともに、ユーザ端末（１００）のＩＰアドレス（端末識別子）をパケットデータから抽出して認証システム（３０１）に入力することもできる。
【０１２５】
［ステップＣ２：認証ステップ］
次に、承認システム（３０１）は、入力されたログインＩＤ（ユーザ識別データ）及びパスワードと、認証データ保持システム（５０１）に予め格納されるユーザＩＤ（ユーザ識別データ）及びパスワードと、を比較する。この比較の結果として、入力されたログインＩＤ及びパスワードと、予め格納されるユーザＩＤ及びパスワードと、が一致する場合に、認証システム（３０１）は、ユーザ端末（１００）のユーザを認証する。この時、認証システム（３０１）は、ユーザＩＤと認証した時刻とを含む認証証明書データを作成して認証データ保持システム（５０１）に格納する。
ここで、認証証明書データが認証した時刻を含むことにより、認証証明書データに有効期限を持たせることができる。また、認証証明書データがユーザＩＤとともに認証した時刻を含むことにより、承認時に毎回異なるユニークな認証証明書データを作成することができる。認証証明書データが有効期限で時間で管理される、又は認証証明書データが承認時に毎回異なるので、認証証明書データの偽造を防止することができるという利点がある。加えて、認証システム（３０１）が暗号化した認証証明書データを作成することにより、認証証明書データの偽造を防止を強化することができる。
【０１２６】
尚、認証システム（３０１）は、ＩＰアドレス（端末識別子）が入力される場合には、入力されたＩＰアドレス（端末識別子）と、予め格納される端末識別子と、を更に比較することができる。この比較の結果として、入力されたログインＩＤ、パスワード、及び端末識別子と、予め格納されるユーザＩＤ、パスワード、及び端末識別子と、が完全に一致する場合に、認証システム（３０１）は、ユーザ端末（１００）のユーザを認証することもできる。これにより、認証システム（３０１）は、仮に入力されたログインＩＤ及びパスワードが偽造されたものであっても、正規なユーザのみを正確に認証することができる。
【０１２７】
［ステップＣ３］
次に、認証システム（３０１）は、動的メニュー生成システム（３０２）を起動し、認証証明書データを動的メニュー生成システム（３０２）に入力する。
【０１２８】
［ステップＣ４］
これに対し、動的メニュー生成システム（３０２）は、入力された認証証明書データのユーザＩＤをキーとして、予め当該ユーザが利用契約したアプリケーションプログラムリストをメニューデータ保持システム（７０２）から取得する。
次に、動的メニュー生成システム（３０２）は、取得したアプリケーションプログラムリストのアプリケーションプログラム名をキーとしてサーバリストをメニューデータ保持システム（７０２）から取得する。
ここで、取得したサーバリストが複数ある場合、動的メニュー生成システム（３０２）は、エラーステータス及び平均応答時間を複数のサーバリストから取得する。
次に、動的メニュー生成システム（３０２）は、抽出したエラーステータスがサービス中であり、且つ抽出した平均応答時間が最小であるサーバリストを選択する。
次に、動的メニュー生成システム（３０２）は、選択したサーバリストに係るプログラムファイル名及びサーバ端末識別名を取得する。
次に、動的メニュー生成システム（３０２）は、取得したプログラムファイル名及びサーバ端末識別名に基づいてＵＲＩ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｒｅ）情報を含むメニューデータを動的に作成する。
尚、ＵＲＩは、ＩＥＴＦが公開している技術文書ｒｆｃ２３９６で定義されている（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３９６．ｔｘｔ）。また、ＵＲＩはＵＲＬ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）と同義である。
【０１２９】
［ステップＣ５］
次に、動的メニュー生成システム（３０２）は、メニューデータと認証証明書データとをＷｅｂサーバ（３９０）を介してユーザ端末（１００）に送信する。尚、認証証明書データが暗号化されている場合には、暗号化された認証証明書データのみがユーザ端末（１００）に送信される。
これに対し、ユーザ端末（１００）は、メニューデータと認証証明書データとをＷｅｂブラウザー（１０１）を介してＷｅｂサーバ（３９０）から受信する。ここで、Ｗｅｂブラウザー（１０１）は、認証証明書データをクッキー（Ｃｏｏｋｉｅ）として一次保持する。
【０１３０】
［ステップＣ６］
ユーザが、ユーザ端末（１００）でアプリケーションプログラムＡ（３１０）を選択すると、メニューデータのＵＲＩに従って、ユーザ端末（１００）は、アプリケーションサーバ１（３００）に格納されるアプリケーションプログラムＡ（３１０）に対する会話要求データ（メッセージ）をＷｅｂブラウザー（１０１）を介してアプリケーションプログラムＡ（３１０）に送信する。この時、ユーザ端末（１００）は、認証証明書データをクッキー（Ｃｏｏｋｉｅ）として送信する。
これに対し、アプリケーションプログラムＡ（３１０）は、会話要求データ（メッセージ）と認証証明書データとをＷｅｂサーバ（３９０）を介してアプリケーションプログラムＡ（３１０）で受信する。
【０１３１】
［ステップＣ７］
アプリケーションプログラムＡ（３１０）は、認証証明書データをアプリケーションプログラムＡ（３１０）に組み込まれた認証ＡＰＩ（３０３）にセットする。ここで、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）とは、認証システム（３０１）、課金システムプログラム（５０３）等の外部プログラムをアプリケーションプログラムＡ（３１０）内部から使用するための仕組みである。尚、具体的に言えば、ＡＰＩはクラス名、メソッド名、引数の並びで規定されている。
即ち、アプリケーションプログラムＡ（３１０）は、認証証明書データを認証ＡＰＩ（３０３）を介して認証システム（３０１）に入力する。ここで、認証ＡＰＩ（３０３）は、認証証明書データを認証システム（３０１）に送り、認証証明書データの正当性を確認している。
【０１３２】
［ステップＣ８：再認証ステップ］
これに対し、認証システム（３０１）は、認証ＡＰＩ（３０３）を介して入力された認証証明書データと、予め認証した認証証明書データと、を比較する。この比較の結果として、入力された認証証明書データと、予め格納した認証証明書データと、が一致する場合に、認証システム（３０１）は、ユーザ端末（１００）のユーザを再度認証する。この時、認証システム（３０１）は、ユーザＩＤと再度認証した時刻とを含む認証証明書データを作成して認証データ保持システム（５０１）に格納する。即ち、認証システム（３０１）は、認証証明書の認証時刻を更新して、認証データ保持システム（５０１）に格納する。
次に、認証システム（３０１）は、再度認証された認証証明書データを認証ＡＰＩ（３０３）を介してアプリケーションプログラムＡ（３１０）に出力する。
【０１３３】
［ステップＣ９］
次に、アプリケーションプログラムＡ（３１０）は、会話要求データ（メッセージ）に対する会話返答データ（メッセージ）を作成する。
次に、アプリケーションプログラムＡ（３１０）は、作成した会話返答データ（メッセージ）と再度認証された認証証明書とをＷｅｂサーバ（３９０）を介してユーザ端末（１００）に送信する。
これに対し、ユーザ端末（１００）は、作成された会話返答データ（メッセージ）と再度認証された認証証明書とをＷｅｂブラウザー（１０１）を介してＷｅｂサーバ（３９０）から受信する。ここで、再度認証された認証証明書は、Ｗｅｂサーバ（３９０）からＷｅｂブラウザー（１０１）にクッキー（Ｃｏｏｋｉｅ）として送受信されている。
この後、ユーザ端末（１００）とアプリケーションＡ（３１０）の間でメッセージの送受信があるたびに、認証証明書データの認証及び更新を行う。これらにより、認証証明書データの偽造を防止を更に強化することができる。
【０１３４】
［ステップＣ１０］
ユーザがアプリケーションプログラムＡ（３１０）の利用を終了すると、利用実績データを課金ＡＰＩ（３０４）を介して課金システム（５０３）に出力する。
【０１３５】
［ステップＣ１１］
前記ステップＣ６のメニューデータに含まれるＵＲＩは、アプリケーションサーバ１（３００）に格納されるアプリケーションプログラムＡ（３１０）を特定し得るものであった。即ち、ステップＣ４において、アプリケーションサーバ１（３００）に格納されるアプリケーションプログラムＡ（３１０）の平均応答時間が最小であったので、ＵＲＩは、アプリケーションサーバ１（３００）に格納されるアプリケーションプログラムＡ（３１０）を特定し得るものであった。
ところが、アプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）の平均応答時間が最小である場合、動的メニュー生成システム（３０２）が作成するメニューデータに係るＵＲＩは、アプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）を特定し得るものになる。
この場合、ユーザが、ユーザ端末（１００）でアプリケーションプログラムＡ（３１０）を選択すると、メニューデータのＵＲＩに従って、ユーザ端末（１００）は、アプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）に対する会話要求データ（メッセージ）をＷｅｂブラウザー（１０１）を介してアプリケーションプログラムＡ（３１０）に送信する。この時、ユーザ端末（１００）は、認証証明書データをクッキー（Ｃｏｏｋｉｅ）として送信する。
これに対し、アプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）は、会話要求データ（メッセージ）と認証証明書データとをＷｅｂサーバ（３９０）を介してアプリケーションプログラムＡ（３１０）で受信する。
【０１３６】
［ステップＣ１２］
アプリケーションプログラムＡ（３１０）は、認証証明書データを認証ＡＰＩ（３０３）を介して認証システム（３０１）に入力する。
【０１３７】
［ステップＣ１３］
これに対し、認証システム（３０１）は、認証ＡＰＩ（３０３）を介して入力された認証証明書データと、予め認証した認証証明書データと、を比較する。この比較の結果として、入力された認証証明書データと、予め格納した認証証明書データと、が一致する場合に、認証システム（３０１）は、ユーザ端末（１００）のユーザを再度認証する。この時、認証システム（３０１）は、ユーザＩＤと再度認証した時刻とを含む認証証明書データを作成して認証データ保持システム（５０１）に格納する。
次に、認証システム（３０１）は、再度認証された認証証明書データを認証ＡＰＩ（３０３）を介してアプリケーションプログラムＡ（３１０）に出力する。
【０１３８】
このように、アプリケーションサーバ１（３００）及びアプリケーションサーバ２（４００）は、認証証明書データをクッキーの仕組みで受信し、認証システム（３０１）を介して認証データ保持システム（５０１）に格納される認証証明書データと比較して受信した認証証明書データの正当性の確認を行うことができる。即ち、最初にユーザがログインしたアプリケーションサーバ１（３００）に格納されるアプリケーションプログラムＡ（３１０）のほか、最初にログインしたアプリケーションサーバ１（３００）と異なるアプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）も同一のユーザを識別することができる。換言すれば、複数のアプリケーションサーバ間でユーザ管理の統一性を実現することができる。
【０１３９】
［ステップＣ１４］
ユーザがアプリケーションプログラムＡ（３１０）の利用を終了すると、利用実績データを課金ＡＰＩ（３０４）を介して課金システム（５０３）に出力する。
尚、アプリケーションプログラムが独自の利用実績データ出力機能を持っているときは、統一性のある利用実績データのフォーマットに変換して課金システム（５０３）にファイル転送で送信する機能を有する。
【０１４０】
次に、本発明の実施の形態のアプリケーション・サービスを提供する方法につき、図６〜図８を参照して、簡単に説明する。
図６はユーザがアプリケーションサーバ１（３００）に格納されるアプリケーションプログラムを利用した場合の流れ図である。
［ステップＤ１］
ユーザ端末（１００）は、アプリケーションサーバ１（３００）に接続する。
［ステップＤ２］
アプリケーションサーバ１（３００）は、ユーザ端末（１００）にログイン画面を送信する。
［ステップＤ３］
ユーザ端末（１００）は、アプリケーションサーバ１（３００）にユーザＩＤとパスワードとを送信する。
［ステップＤ４］
アプリケーションサーバ１（３００）は、ユーザＩＤとパスワードと必要に応じてユーザ端末（１００）の端末識別子をチェックし、正当と判断すれば、ユーザが利用契約したアプリケーションプログラムの一覧をメニューとして送信する。
［ステップＤ５］
ユーザ端末（１００）は、アプリケーションプログラムを選択するとＵＲＩに従ってアプリケーションサーバ１（３００）に接続する。
［ステップＤ６］
アプリケーションサーバ１（３００）は、ＵＲＩに従って選択されたアプリケーションプログラムを起動する。
［ステップＤ７］
ユーザは、ユーザ端末（１００）でアプリケーションプログラムを利用し、終了する。
［ステップＤ８］
ユーザが、アプリケーションサーバ１（３００）でアプリケーションプログラムが終了すると、利用実績データを蓄積する。
【０１４１】
図７はユーザがアプリケーションサーバ２（４００）に格納されるアプリケーションプログラムを利用した場合の流れ図である。
［ステップＥ１〜Ｅ４］
ステップＤ１〜Ｄ４と同じである。
［ステップＥ５］
ユーザ端末（１００）は、アプリケーションプログラムを選択するとＵＲＩに従ってアプリケーションサーバ２（４００）に接続する。
［ステップＥ６］
アプリケーションサーバ２（４００）は、ＵＲＩに従って選択されたアプリケーションプログラムを起動する。
［ステップＥ７］
ユーザは、ユーザ端末（１００）でアプリケーションプログラムを利用し、終了する。
［ステップＥ８］
ユーザが、アプリケーションサーバ２（４００）でアプリケーションプログラムが終了すると、利用実績データを蓄積する。
【０１４２】
図８は課金の流れ図である。
［ステップＦ１］
データサーバ（５００）は、定期的に蓄積した利用実績データをユーザ別アプリケーション別に集計する。
［ステップＦ２］
データサーバ（５００）は、課金処理を実行して請求書を発行し、ユーザに電子メール、郵便等で送付する。
［ステップＦ３］
ユーザは、利用料金をデータサーバ（５００）に電子マネー、クレジットカード、口座振込等で支払う。
［ステップＦ４］
データサーバ（５００）は、ベンダー別アプリケーション利用料金を集計する。
［ステップＦ５］
データサーバ（５００）は、ベンダー端末（７００）にアプリケーション利用料金を電子マネー、口座振込等で支払う。
【０１４３】
次に、［ステップＡ２］に係る認証ＡＰＩ（３０３）及び課金ＡＰＩ（３０４）をアプリケーションプログラムに組み込む方法につき、図９及び図１０を参照して、説明する。
図９は認証ＡＰＩ（３０３）をアプリケーションプログラムに組み込む方法を示すフローチャートである。このフローチャートで認証ＡＰＩ（３０３）をアプリケーションプログラムに組み込むを方法を説明する。
まず組み込む前の一般的なアプリケーションプログラムの入力メッセージを処理するフローを説明する。
【０１４４】
［ステップＧ１］
アプリケーションプログラムは、ユーザ端末（１００）からメッセージ（会話要求データ）を受信する。
［ステップＧ２］
アプリケーションプログラムは、受信したメッセージＩＤが処理ＩＤに等しいか比較する。受信したメッセージＩＤが処理１に等しければ該当する処理１を実行する（ステップＧ５へ）。受信したメッセージＩＤが処理１に等しくなければ次の処理ＩＤに等しいか比較する（ステップＧ３へ）。
［ステップＧ３］
アプリケーションプログラムは、受信したメッセージＩＤが処理２に等しいか比較する。受信したメッセージＩＤが処理２に等しければ該当する処理２を実行する（ステップＧ６へ）。受信したメッセージＩＤが処理２に等しくなければ次の処理ＩＤに等しいか比較する（ステップＧ４へ）。
［ステップＧ４］
アプリケーションプログラムは、受信したメッセージＩＤが処理ｎに等しいか比較する。受信したメッセージＩＤが処理ｎに等しければ該当する処理ｎを実行する（ステップＧ７へ）。受信したメッセージＩＤが処理ｎに等しくなければエラー処理を行う（ステップＧ８へ）。
［ステップＧ５］
アプリケーションプログラムは、受信したメッセージを処理１して結果をＨＴＭＬ文書形式にしてユーザ端末（１００）に送信する。
［ステップＧ６］
アプリケーションプログラムは、受信したメッセージを処理２して結果をＨＴＭＬ文書形式にしてユーザ端末（１００）に送信する。
［ステップＧ７］
アプリケーションプログラムは、受信したメッセージを処理ｎして結果をＨＴＭＬ文書形式にしてユーザ端末（１００）に送信する。
［ステップＧ８］
アプリケーションプログラムは、受信したメッセージＩＤが最後の処理ＩＤと一致しなければエラーメッセージをユーザ端末（１００）に送信する。
【０１４５】
次に認証ＡＰＩ（３０３）をアプリケーションプログラムに組み込む方法を説明する。
ステップＧ１とステップＧ２の間に次に示すステップＨ１〜Ｈ６を挿入する。
尚、ステップＣ５において、動的メニュー生成システム（３０２）が暗号化された認証証明書データをユーザ端末（１００）に送信され、ステップＣ６において、暗号化された認証証明書データがユーザ端末（１００）からアプリケーションプログラムに送信されているとする。
［ステップＨ１］
アプリケーションプログラムは、暗号化された認証証明書データをクッキーとしてユーザ端末（１００）から受信する。
［ステップＨ２］
アプリケーションプログラムは、暗号化された認証証明書データを認証ＡＰＩ（３０３）の引数にセットする。
［ステップＨ３］
アプリケーションプログラムは、認証ＡＰＩ（３０３）を呼び出す。
［ステップＨ４］
アプリケーションプログラムは、認証ＡＰＩ（３０３）から戻された値をチェックする。無効コードならステップＨ５へ行く。
［ステップＨ５］
アプリケーションプログラムは、エラーメッセージとログイン画面を表示する。
［ステップＨ６］
アプリケーションプログラムは、認証ＡＰＩ（３０３）から戻された新しい暗号化された認証証明書データをクッキーとしてユーザ端末（１００）に送信する。
尚、ステップＨ１〜ステップＨ６を実行させるためのプログラムを認証関数プログラムという。
【０１４６】
図１０は課金ＡＰＩ（３０４）をアプリケーションプログラムに組み込む方法を示すフローチャートである。このフローチャートで認証ＡＰＩ（３０３）をアプリケーションプログラムに組み込むを方法を説明する。
ステップＩ２が本来のアプリケーションの処理であり、図９のステップＨ５〜Ｈ７が示す処理である。ステップＩ２（ステップＨ５〜Ｈ７）の直前にステップＨ１を挿入し、ステップＩ２の後ろにステップＩ３〜ステップＩ５を挿入する。
［ステップＩ１］
アプリケーションプログラムは、ステップＩ２の直前に処理開始時刻としてマシン時間を取得する。
［ステップＩ２］
アプリケーションプログラムは、処理をするとともに、課金対象となる使用量を計測する。
［ステップＩ３］
アプリケーションプログラムは、ステップＩ２の直後に処理終了時刻としてマシン時間を取得する。
［ステップＩ４］
アプリケーションプログラムは、利用実績データ（ユーザ識別名、処理開始時刻、処理時間（＝処理終了時刻−処理開始時刻）、ステップＩ２で採取した課金対象となる使用量等を含む。）を作成する。（図１５に示す利用実績データ（５０３−２）を参照。）
［ステップＩ５］
アプリケーションプログラムは、課金ＡＰＩ（３０４）を呼び出す。
尚、ステップＩ１〜ステップＩ５を実行させるためのプログラムを課金関数プログラムという。
【０１４７】
（実施の形態２）
次に、本発明の実施の形態２のアプリケーション・サービスを提供する方法及びシステムにつき、図１２を参照して、説明する。
図１２は本発明の実施の形態２のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
図５に示す本発明の実施の形態１のシステムは複数のアプリケーションサーバ（３００，４００，．．．）から構成されていたが、図１２に示す実施の形態２のシステムは一のアプリケーションサーバ１（３００）から構成されてなる。
【０１４８】
次に、本発明の実施の形態のアプリケーション・サービスを提供する方法につき、図１２、図１３〜図１５を参照して、説明する。
尚、ステップＣ１〜ステップＣ１４に相当するものである。
【０１４９】
［ステップＬ１］
ユーザは、ユーザ端末（１００）のＷｅｂブラウザ（１０１）を使用してコンピュータネットワーク（２００）上に開設しているアプリケーションサーバ１（３００）に接続する。
【０１５０】
［ステップＬ２］
認証システム（３０１）が、Ｗｅｂサーバ（３９０）を介してログイン画面データをユーザ端末（１００）に送出する。
【０１５１】
［ステップＬ３］
ユーザは、ユーザ端末（１００）の表示手段に表示されたログイン画面からログインＩＤ（ユーザ識別データ）とパスワードとを入力する。
【０１５２】
［ステップＬ４］
認証システム（３０１）は、ユーザ端末（１００）から受信したログインＩＤとパスワードとユーザ端末（１００）の端末識別子とをＷｅｂサーバ（３９０）から受け取る。ユーザ識別名、パスワード、端末識別子のすべてまたはあらかじめ決めてあるそれらの内のいくつかの組み合わせと、認証データ保持システム（５０１）からログインＩＤをキーにして受信した認証データ（ユーザＩＤ、パスワード、端末識別子を含む。図１３．認証データ５０１−１参照。）を突き合わせて一致するか比較する。一致すれば正常、一致しなければ以上と判断する。
【０１５３】
［ステップＬ５］
認証システム（３０１）の認証結果が正常なら、認証したときの時刻（年月日時分秒）をマシン時間から取得する。次に、認証システム（３０１）は、ユーザＩＤと認証したときの時刻とを含む認証証明書データを作成する。同時に、認証システム（３０１）は、認証証明書データを暗号化し、暗号化した認証証明書データを作成する。
次に、認証システム（３０１）は、暗号化した認証証明書をキーとしてユーザ認証データ保持システム（５０１）に暗号化前の認証証明書データと暗号化した認証証明書と（図１３．認証証明書データ５０１−２参照。）を保存する。そして認証システム（３０１）は動的メニュー生成システム（３０２）を起動し、ユーザＩＤと暗号化した認証証明書を引き渡す。ここで、認証証明書の暗号化には、第三者に解読不可能な一方向暗号アルゴリズムを使用する。たとえば要約関数ＭＤ５（ＲＦＣ１３２１で定義されている）を使う。尚、ＭＤ５の出力結果はバイナリなのでネットワーク透過にするためＢＡＳＥ６４でエンコードするしたものを暗号化した認証証明書データとする。
【０１５４】
［ステップＬ６］
動的メニュー生成システム（３０２）は、ユーザＩＤをキーとしてメニューデータ保持システム（５０２）から当該ユーザが利用可能なアプリケーションプログラムのリスト（図１４．アプリケーションプログラムリスト５０２−１参照。）と各アプリケーションプログラムが動作可能なサーバのリスト（図１４．サーバリスト５０２−２参照。）を受信する。アプリケーションプログラムリスト（５０２−１）は、ユーザＩＤとアプリケーションプログラム名とを含む。また、サーバリスト（５０２−２）は、アプリケーションプログラム名とサーバ端末識別名とプログラムファイル名とを含む。
【０１５５】
［ステップＬ７］
動的メニュー生成システム（３０２）はクッキー化した、且つ暗号化した認証証明書データと当該ユーザが利用可能なアプリケーションプログラムのリストをＵＲＩ形式に合成し、メニューデータを生成する。動的メニュー生成システム（３０２）は生成したメニューデータをＷｅｂサーバ（３９０）を介してユーザ端末（１００）に送出する。
【０１５６】
［ステップＬ８］
ユーザが、メニュー画面からアプリケーションＡ（３１０）を選択すると、Ｗｅｂブラウザ（１０１）はアプリケーションＡ（３１０）のＵＲＩを使って選択されたアプリケーションに接続する。このとき、ユーザ端末（１００）は、ステップＬ７で受信した暗号化された認証証明書データをクッキーとして送出する。
【０１５７】
［ステップＬ９］
アプリケーションＡ（３１０）は、Ｗｅｂサーバ（３９０）を介してクッキーとして暗号化された認証証明書データを受信する。アプリケーションＡ（３１０）は、この暗号化された認証証明書データを引数に格納して認証ＡＰＩ（３０３）を呼び出す。認証ＡＰＩ（３０３）は、認証システム（３１０）に暗号化された認証証明書データを送出し、正当性確認を要求する。
【０１５８】
［ステップＬ１０］
認証システム（３０１）は、暗号化された認証証明書データをキーとして認証データ保持システム（５０１）から認証証明書データを取り出す。認証証明書データに含まれる認証時刻が、現在のマシン時刻を基点としてあらかじめ決めておいた無通信タイムアウト時間より過去であれば、この暗号化された認証証明書は無効であると判定する。認証システム（３０１）は、データ保持システム（５０１）から取り出した認証証明書データを再度暗号化したものが受信した暗号化された認証証明書データと一致すれば有効、一致しなければ無効と判定する。認証システム（３０１）の認証結果が有効であれば、認証システム（３０１）は、認証証明書の認証時刻を現在のマシン時刻に変更して認証証明書データを更新する。次に、認証システム（３０１）は、新しい認証証明書データを暗号化する。認証システム（３０１）は、この暗号化した認証証明データをキーとして新しい認証証明データを認証データ保持システム（４０１）に登録し、古い認証証明データは削除する。
【０１５９】
［ステップＬ１１］
認証システム（３０１）は、認証ＡＰＩ（３０３）を介してアプリケーションＡ（３１０）に認証結果を応答する。認証システム（３０１）の認証結果が有効なら、ユーザＩＤと新しい暗号化された認証証明書データを返し、無効なら無効を意味するコードを返す。
【０１６０】
［ステップＬ１２］
アプリケーションＡ（３１０）は、認証システム（３０１）の認証結果が正常なら、ユーザ端末（１００）とアプリケーションレベルの会話（メッセージ）を開始する。このとき、アプリケーションＡ（３１０）は、ユーザ端末（１００）からＷｅｂサーバ（３９０）を介してデータを受信すると、必ず暗号化された認証証明書データがクッキーとして送られてくるので、毎回ステップＬ９〜ステップＬ１１の手順で正当性を確認する。アプリケーションＡ（３１０）は、ユーザ端末（１００）にＷｅｂサーバ（３９０）を介してＨＴＭＬ文書データを送信するときはステップＬ１１で返された新しい暗号化された認証証明書データをクッキーとして送信する。
【０１６１】
［ステップＬ１３］
一連のアプリケーションレベルの会話（メッセージ：会話要求データ、会話返送データ）の途中、又はアプリケーションＡ（３１０）の終了時に、アプリケーションＡ（３１０）は利用実績データ（５０３−２）としてユーザ識別名、時刻、利用機能、各アプリケーションプログラムで決めた課金対象となるアプリケーション利用量等を課金ＡＰＩ（３０４）を介して課金システム（５０３）に送出する。課金システム（５０３）は、受信した利用実績データを蓄積し、定期的に集計して、認証データ保持システム（５０１）に格納しているユーザ別アプリケーション別各アプリケーション利用量単価（図１５．単価マスタ５０３−１参照。）にユーザ別アプリケーション別アプリケーション利用量を積算し、利用料金の額を算出して請求書を作成する。
【０１６２】
（実施の形態３）
次に、本発明の実施の形態３のアプリケーション・サービスを提供する方法及びシステムにつき、図１６を参照して、説明する。
図１６は本発明の実施の形態３のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
図１６に示す実施の形態３のシステムは、図５に示す本発明の実施の形態１のシステムに、監視システム（エージェーント（３０６），サーバ（７０４））を追加し、更にアプリケーションプログラム（３１０，４１０）のそれぞれに監視ＡＰＩ（３０５）を組み込む。尚、認証システム（３０１）、認証データ保持システム（７０１）、課金システム（７０３）、認証ＡＰＩ（３０３）及び課金課金ＡＰＩ（３０４）については図示を省略する。
【０１６３】
複数のアプリケーションサーバ（３００，４００，．．．）のそれぞれは、アプリケーションプログラム（３１０，４１０，．．．）のそれぞれに組み込んだ監視ＡＰＩ（３０５）に定期的に稼動状況を問い合わせる監視システム（エージェント）（３０３）を更に備える。
また、監視ＡＰＩ（３０５）は、アプリケーションプログラムの負荷状況と障害状況とのデータを採取する。
データサーバ（５００）は、監視システム（エージェント）（３０３）が採取したアプリケーションプログラムの稼動状況データを蓄積する監視システム（サーバ）（７０４）を更に備える。
【０１６４】
先ず、監視ＡＰＩ（３０５）をアプリケーションプログラムに組み込む方法につき、図１１を参照して、説明する。
図１１は監視ＡＰＩ（３０５）をアプリケーションプログラムに組み込む方法を示すフローチャートである。このフローチャートで監視ＡＰＩ（３０５）をアプリケーションプログラムに組み込むを方法を説明する。
【０１６５】
まず組み込む前の一般的なアプリケーションプログラムの処理フローを説明する。
［ステップＪ１］
アプリケーションプログラムは、端末からのデータ受信等のイベントを入力する。
［ステップＪ２］
アプリケーションプログラムは、入力したイベントがアプリケーションプログラムの終了イベントならステップＪ４へ行く。
［ステップＪ３］
アプリケーションプログラムは、入力したイベントに対応する業務処理を実行する。終われば次のイベント入力を待つ。
［ステップＪ４］
アプリケーションプログラムは、終了イベントを入力したら終了処理を行う。
【０１６６】
次に監視ＡＰＩ（３０５）をアプリケーションプログラムに組み込む方法を説明する。
［ステップＫ１］
アプリケーションプログラムは、ステップＪ１の前に、初期処理として監視ＡＰＩ（３０５）のインスタンスを生成する。
［ステップＫ２］
アプリケーションプログラムは、ステップＪ３の直前でマシン時刻を取得し処理開始時刻として一時退避する。
［ステップＫ３］
アプリケーションプログラムは、ステップＪ３の直後でマシン時刻を取得し、ステップＫ２の処理開始時刻を減算して処理時間を算出し、処理時間を応答時間として監視ＡＰＩ（３０５）に渡す。
また、業務処理（ステップＪ３）でエラーが発生していれば、エラーコードとエラーメッセージとを監視ＡＰＩ（３０５）に渡す。
【０１６７】
先ず、監視ＡＰＩ（３０５）は、渡された応答時間を規定ｎ回数分（例えばｎ＝１０：ｎは１以上の自然数）だけ応答時間データ（３０５−１）に保持する。即ち、監視ＡＰＩ（３０５）は、最近の１０個の応答時間を格納する（図１９応答時間データ（３０５−１）参照）。
監視ＡＰＩ（３０５）は、応答時間を渡される毎に渡された応答時間を最新の応答時間１として応答時間データ（３０５−１）に格納する。これと同時に、監視ＡＰＩ（３０５）は、応答時間１であった応答時間を応答時間２として応答時間データ（３０５−１）に格納し、応答時間２であった応答時間を応答時間３として応答時間データ（３０５−１）に格納し、・・・、応答時間９であった応答時間を応答時間１０（ｎ）として応答時間データ（３０５−１）に格納し、応答時間１０であった応答時間を応答時間データ（３０５−１）から破棄する。
また、監視ＡＰＩ（３０５）は、応答時間を渡される毎に応答時間データ（３０５−１）に格納された応答時間１、応答時間２・・・応答時間１０（ｎ）の平均応答時間を算出し、平均応答時間（現在）としてを応答時間データ（３０５−１）に格納する。
更に、監視ＡＰＩ（３０５）は、エラーコードとエラーメッセージとを渡される毎にこれらを応答時間データ（３０５−１）に格納する。尚、監視ＡＰＩ（３０５）は、監視ＡＰＩ（３０５）を組み込むアプリケーションプログラム名を応答時間データ（３０５−１）に格納する。
加えて、監視ＡＰＩ（３０５）は、監視要求データを監視システム（エージェント）（３０５）から入力された場合、応答時間データ（３０５−１）に格納する平均応答時間（現在）、エラーコード、及びエラーメッセージを監視システム（エージェント）（３０５）に出力する。
【０１６８】
［ステップＫ４］
アプリケーションプログラムは、ステップＪ４の後ろに、終了処理として監視ＡＰＩ（３０５）のインスタンスを消去する。
尚、ステップＫ１〜ステップＫ４を実行させるためのプログラムを監視関数プログラムという。
【０１６９】
次に、本発明の実施の形態のアプリケーション・サービスを提供する方法につき、図１６〜図２０を参照して、説明する。
【０１７０】
［ステップＭ１］
アプリケーションサーバ１（３００）の監視システム（エージェント）（３０５）は、起動するとともに、データベースサーバ（５００）のメニューデータ保持システム（５０２）からアプリケーションサーバ１（３００）に関するサーバリスト（５０２−２）（図１８参照）を読み込み、アプリケーションパフォーマンスリスト（３０６−１）（図１９参照）を内部テーブルとして生成する。即ち、監視システム（エージェント）（３０５）は、アプリケーションサーバ１（３００）のサーバ端末識別名をキーとしてサーバリスト（５０２−２）を抽出し、抽出したサーバリスト（５０２−２）の平均応答時間をアプリケーションパフォーマンスリスト（３０６−１）の平均応答時間（現在）に格納する。
尚、図１８に示すように、サーバリスト（５０２−２）は、例えば、アプリケーションプログラム名と、サーバ端末識別名と、プログラム名と、エラーステータスと、平均応答時間とから成る。また、図１９に示すように、アプリケーションパフォーマンスリスト（３０６−１）は、例えば、アプリケーションプログラム名と、エラーコードと、エラーメッセージと、平均応答時間（現在）と、平均応答時間（前回）と、応答時間１と、・・・応答時間ｎとから成る。
【０１７１】
次に、監視システム（エージェント）（３０５）は、定期的（たとえば１０秒毎）にアプリケーションサーバ１（３００）に格納されるアプリケーションプログラムのそれぞれに組み込まれた監視ＡＰＩ（３０５）に監視状況の問い合わせを行う。即ち、監視システム（エージェント）（３０５）は、監視要求データを監視ＡＰＩ（３０５）に定期的に入力する。これに対し、監視ＡＰＩ（３０５）は、応答時間データ（３０５−１）に格納するアプリケーションプログラムの平均応答時間（現在）を監視システム（エージェント）（３０５）に出力する。
これに対し、監視システム（エージェント）（３０５）は、アプリケーションプログラムの平均応答時間（現在）をアプリケーションパフォーマンスリスト（３０６−１）に格納する。これと同時に、監視システム（エージェント）（３０５）は、平均応答時間（現在）であった平均応答時間を平均応答時間（前回）として格納し、平均応答時間（前回）であった平均応答時間を破棄する。
【０１７２】
［ステップＭ２］
ところで、アプリケーションプログラムにエラーが発生した場合、監視ＡＰＩ（３０５）は、エラーコードとエラーメッセージとをアプリケーションプログラムから渡される。この場合、監視ＡＰＩ（３０５）は平均応答時間（現在）とエラーコードとエラーメッセージとを監視システム（エージェント）（３０５）に出力するので、監視システム（エージェント）（３０５）はアプリケーションパフォーマンスデータ（５０４−１）を作成してデータサーバ（５００）に格納する（図２０参照）。
また、アプリケーションプログラムに重大なエラーが発生した場合、アプリケーションが動作しないので、監視ＡＰＩ（３０５）も動作しなくなる。従って、監視システム（エージェント）（３０５）が監視要求データを監視ＡＰＩ（３０５）に入力しても、監視ＡＰＩ（３０５）は何も出力することができない。そこで、監視システム（エージェント）（３０５）は、予め決めた回数（例えば４回）連続して、監視ＡＰＩから応答がない場合、監視システム（エージェント）（３０５）は、応答がない監視ＡＰＩ（３０５）のアプリケーションプログラムにサービス不可能な障害が発生したと判断する。
この場合、監視システム（エージェント）（３０５）は、データサーバに格納されるアプリケーションパフォーマンスデータ（５０４−１）の時刻と、エラーコードと、エラーメッセージとを更新する。これと同時に、監視システム（エージェント）（３０５）は、メニューデータ保持システム（５０２）のサーバリスト（５０２−２）のエラーステータスをサービス中止として格納する。
【０１７３】
［ステップＭ３］
また、アプリケーションプログラムの処理能力が低下した場合、又はアプリケーションプログラムの処理能力が向上した場合、監視ＡＰＩ（３０５）は、長い平均応答時間（現在）、又は短い平均応答時間（現在）をアプリケーションプログラムから渡される。従って、アプリケーションプログラムの処理能力の状況を反映させるため、監視システム（エージェント）（３０５）は、アプリケーションパフォーマンスリスト（３０６−１）の平均応答時間（現在）と平均応答時間（前回）を毎回比較して、平均応答時間（現在）が平均応答時間（前回）よりもより予め決めた値以上に変動した場合、監視システム（エージェント）（３０５）は、メニューデータ保持システム（５０２）のサーバリスト（５０２−２）の平均応答時間を平均応答時間（現在）として格納する。
【０１７４】
［ステップＭ４］
一方、アプリケーションプログラムに対する接続要求データが、ユーザ端末（１００）から複数のアプリケーションサーバ（３００，４００，．．．）のうち何れか一のアプリケーションサーバ１（３００）に送受信され、（実施の形態１）のステップＣ１〜Ｃ３が実行される。
【０１７５】
［ステップＭ５］
動的メニュー生成システム（３０２）は、サーバリスト（５０２−２）をメニューデータ保持システム（７０２）から取得する。次に、動的メニュー生成システム（３０２）は、エラーステータス及び平均応答時間を複数のサーバリストから取得する。
次に、動的メニュー生成システム（３０２）は、抽出したエラーステータスがサービス中であり、且つ抽出した平均応答時間が最小であるサーバリストを選択する。
次に、動的メニュー生成システム（３０２）は、選択したサーバリストに係るプログラムファイル名及びサーバ端末識別名を取得する。
次に、動的メニュー生成システム（３０２）は、取得したプログラムファイル名及びサーバ端末識別名に基づいてＵＲＩ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｒｅ）情報を含むメニューデータを動的に作成する。
ここで、一例を挙げれば、図１７に示すようなメニューデータである。ＵＲＩ（ｈｔｔｐ：／／アプリケーションサーバ２／アプリケーションＡ．ａｓｐ）は、プログラムファイル名（アプリケーションＡ．ａｓｐ）及びサーバ端末識別名（アプリケーションサーバ２）に基づいて作成される。
【０１７６】
［ステップＭ６］
動的メニュー生成システム（３０１）は、ステップＭ５で作成したＵＲＩのリスト作成から図１７に示すようなメニュー画面用のＨＴＭＬ文書ファイルをユーザ端末にメニュー画面用のＨＴＭＬ文書ファイルを送出する。
【０１７７】
［ステップＭ７］
ユーザはユーザ端末（１００）のＷｅｂブラウザ（１０１）を使用してメニュー画面からアプリケーションプログラムＡを選択すると、選択したＵＲＩが示すアプリケーションサーバ２（４００）のＷｅｂサーバ（３９０）に接続する。
【０１７８】
［ステップＭ８］
これに対し、アプリケーションサーバ２（４００）に格納されるアプリケーションプログラムＡ（３１０）は、ユーザが接続したＵＲＩに従ってアプリケーションサーバ２（４００）のＷｅｂサーバ（３９０）から起動される。これ以降、ユーザ端末（１００）はアプリケーションサーバ２（４００）のアプリケーションプログラムＡ（３１０）と会話する。
【０１７９】
［ステップＭ９］
また、ステップＭ７でユーザがメニュー画面からアプリケーションプログラムＢを選択した場合は、選択したＵＲＬが示すアプリケーションサーバ１（３００）のＷｅｂサーバ（３９０）に接続する。
【０１８０】
［ステップＭ１０］
ステップＭ７ではなく、ステップＭ９が実行された場合、アプリケーションサーバ１（３００）上にあるアプリケーションプログラムＢ（３２０）は、ユーザが接続したＵＲＩに従ってアプリケーションサーバ１（３００）のＷｅｂサーバ（３９０）から起動される。これ以降、ユーザ端末（１００）はアプリケーションサーバ１（３００）のアプリケーションプログラムＢ（３２０）と会話する。
【０１８１】
【発明の効果】
本発明のアプリケーション・サービスを提供する方法及びシステムによれば、複数のアプリケーションサーバのそれぞれが、受信した認証証明書データとデータサーバに予め格納される認証証明書データとを比較して、受信した認証証明書データの正当性の確認を行うことができる。即ち、複数のアプリケーションサーバのそれぞれが、同一のユーザを識別することができる。換言すれば、複数のアプリケーションサーバ間でユーザ管理の統一性を実現することができる。これにより、アプリケーションプログラムを複数のアプリケーションサーバに分散させて、アプリケーションプログラムの処理速度の低下を防止することができるという効果がある。
【０１８２】
また、利用実績データがアプリケーションサーバのそれぞれからデータサーバに送信されるので、契約の利用代金の額がユーザの利用時間（実績データ）に線形でない場合であっても、データサーバで利用実績データを収集して、課金処理を行って利用代金の額を算出することができる。即ち、複数のアプリケーションサーバ間で課金管理の統一性を実現することができるという効果がある。
更に、アプリケーションプログラムの応答時間データが監視されているので、アプリケーションプログラムの処理速度の低下を確実に防止することができるという効果がある。
【図面の簡単な説明】
【図１】実施の形態１のアプリケーション・サービスを提供するための準備をするシステムの構成例を示すブロック図である。
【図２】実施の形態１のアプリケーションプログラムを準備する方法を説明するためのフローチャート図である。
【図３】実施の形態１のアプリケーションプログラムを利用するユーザの登録方法を説明するためのフローチャート図である。
【図４】実施の形態１のアプリケーション情報表示画面である。
【図５】実施の形態１のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
【図６】実施の形態１のアプリケーションサーバ１のアプリケーションプログラムを利用した場合の流れ図である。
【図７】実施の形態１のアプリケーションサーバ２のアプリケーションプログラムを利用した場合の流れ図である。
【図８】実施の形態１の課金の流れ図である。
【図９】実施の形態１の認証ＡＰＩをアプリケーションプログラムに組み込む方法を示すフローチャートである。
【図１０】実施の形態１の課金ＡＰＩをアプリケーションプログラムに組み込む方法を示すフローチャートである。
【図１１】実施の形態３の監視ＡＰＩをアプリケーションプログラムに組み込む方法を示すフローチャートである。
【図１２】実施の形態２のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
【図１３】実施の形態２の認証データ保持システムが保持するデータ例である。
【図１４】実施の形態２のメニューデータ保持システムが保持するデータ例１である。
【図１５】実施の形態２の課金システムが保持するデータ例である。
【図１６】実施の形態３のアプリケーション・サービスを提供するシステムの構成例を示すブロック図である。
【図１７】実施の形態３のメニュー画面のソース例である。
【図１８】実施の形態３のメニューデータ保持システムが保持するデータ例２である。
【図１９】実施の形態３の監視ＡＰＩ及び監視システム（エージェント）が管理するデータ例である。
【図２０】実施の形態３の監視システム（サーバ）が管理するデータ例である。
【符号の説明】
１００    ユーザ端末
１０１    Ｗｅｂブラウザ
２００    コンピュータネットワーク
２１０    ＬＡＮ
２２０    公衆回線または専用線
２３０    補助記憶媒体
３００、４００    アプリケーションサーバ
３０１    認証システム
３０２    動的メニュー生成システム
３０３    認証ＡＰＩ
３０４    課金ＡＰＩ
３０５    監視ＡＰＩ
３０５−１  応答時間データ
３０６    監視システム（エージェント）
３１０、３２０    アプリケーションプログラム
３９０    Ｗｅｂサーバ
５００    データサーバ
５０１    認証データ保持システム
５０１−１  認証データ
５０１−２  認証証明書データ
５０２    メニューデータ保持システム
５０２−１  アプリケーションプログラムリスト
５０２−２  サーバリスト
５０３    課金システム
５０３−１  単価マスタ
５０３−２  利用実績データ
５０４    監視システム（サーバ）
５０４−１  アプリケーションパフォーマンスデータ
７００    ベンダー端末
【図１】
0003626662.tif 000002
【図２】
0003626662.tif 000003
【図３】
0003626662.tif 000004
【図４】
0003626662.tif 000005
【図５】
0003626662.tif 000006
【図６】
0003626662.tif 000007
【図７】
0003626662.tif 000008
【図８】
0003626662.tif 000009
【図９】
0003626662.tif 000010
【図１０】
0003626662.tif 000011
【図１１】
0003626662.tif 000012
【図１２】
0003626662.tif 000013
【図１３】
0003626662.tif 000014
【図１４】
0003626662.tif 000015
【図１５】
0003626662.tif 000016
【図１６】
0003626662.tif 000017
【図１７】
0003626662.tif 000018
【図１８】
0003626662.tif 000019
【図１９】
0003626662.tif 000020
【図２０】
0003626662.tif 000021