(57)【要約】      （修正有）【課題】任意の課金アプリケーションに対応した申請画面の自動生成、および生成された画面からの入力情報に基づく課金情報の自動生成を行い、任意の課金アプリケーションに関しての課金契約処理を効率的に行うことを可能とする。【解決手段】価格パターン記憶処理部１０４は、複数の課金形態（計算ロジック１０６）と申請画面を構成するユーザ・コントロール群（ＵＩ部品１０５）とを対応付けて管理し、価格メンテナンス機能１０１は、ＡＰ毎に、当該ＡＰの計算ロジックとＵＩ部品のペアを対応付けて記憶管理し、レンダリング部１１１は、当該ＡＰの課金形態の設定に用いる申請画面１１５を生成して表示し、入力解析部１１２は、ＡＰの課金形態を当該ユーザに対応付けて記憶管理し、計算適用部１１４は、使用情報データベース１０９で管理するユーザ毎のＡＰの利用状態と入力解析部が管理するユーザ毎のＡＰの課金形態とを用いて課金データを算出する。【選択図】図１
2011034478.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの利用状態に応じて、当該アプリケーションを利用するユーザから徴収する利用料金を算出して課金するアプリケーション利用料課金システムであって、
アプリケーションの利用形態に応じた複数の課金形態と当該課金形態をユーザが設定する際に用いる申請画面を構成するユーザ・コントロール群とを対応付けて記憶装置に格納する第１の手段と、
アプリケーション毎に、当該アプリケーションの複数の利用形態に応じた各課金形態とユーザ・コントロール群のペアを上記記憶装置から読み出して当該アプリケーションに対応付けて記憶装置に格納する第２の手段と、
ユーザから要求されたアプリケーションに対応付けられた各課金形態とユーザ・コントロール群のペアを記憶装置から読み出し、当該アプリケーションの課金形態の設定に用いる申請画面を生成して表示装置に表示する第３の手段と、
上記表示した申請画面を用いてユーザが設定したアプリケーションの課金形態を当該ユーザに対応付けて記憶装置に格納する第４の手段と、
ユーザ毎のアプリケーションの利用状態を収集して記憶装置に格納する第５の手段と、
該第５の手段が記憶装置に格納したユーザ毎のアプリケーションの利用状態と、上記第４の手段が記憶装置に格納したユーザ毎のアプリケーションの課金形態とを用いて、各ユーザが利用したアプリケーションの利用料金を算出し、当該ユーザに関しての課金データとして記憶装置に格納する第６の手段と
を有することを特徴とするアプリケーション利用料課金システム。
【請求項２】
プログラムされたコンピュータ処理により、アプリケーションの利用状態に応じて、当該アプリケーションを利用するユーザから徴収する利用料金を算出して課金するシステムのアプリケーション利用料課金方法であって、
プログラムされたコンピュータ処理手順として、
入力装置からの入力操作に応じて、アプリケーションの利用形態に応じた複数の課金形態と当該課金形態をユーザが設定する際に用いる申請画面を構成するユーザ・コントロール群とを対応付けて第１の記憶装置に格納する第１の手順と、
入力装置からの入力操作に応じて、アプリケーション毎に、当該アプリケーションの複数の利用形態に応じた各課金形態とユーザ・コントロール群のペアを上記第１の記憶装置から読み出して、当該アプリケーションに対応付けて第２の記憶装置に格納する第２の手順と、
入力装置を介してユーザから要求されたアプリケーションに対応付けられた各課金形態とユーザ・コントロール群のペアを上記第２の記憶装置から読み出し、当該アプリケーションの課金形態の設定に用いる申請画面を生成して表示装置に表示する第３の手順と
を含むことを特徴とするアプリケーション利用料課金方法。
【請求項３】
請求項２に記載のアプリケーション利用料課金方法であって、
プログラムされたコンピュータ処理手順として、
上記第３の手順で上記表示装置に表示した申請画面を用いてユーザが設定したアプリケーションの課金形態を当該ユーザに対応付けて第３の記憶装置に格納する第４の手順と、
ユーザ毎のアプリケーションの利用状態を収集して第４の記憶装置に格納する第５の手順と、
該第５の手順で上記第４の記憶装置に格納したユーザ毎のアプリケーションの利用状態と、上記第４の手順で上記第３の記憶装置に格納したユーザ毎のアプリケーションの課金形態とを用いて、各ユーザが利用したアプリケーションの利用料金を算出し、当該ユーザに関しての課金データとして第５の記憶装置に格納する第６の手順と
を含むことを特徴とするアプリケーション利用料課金方法。
【請求項４】
コンピュータに、請求項２もしくは請求項３のいずれかに記載のアプリケーション利用料課金方法における各手順を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、SaaS（Software as a Service）等、ASP（Application Service Provider）から提供される従量的に課金（当該アプリケーションの利用料を徴収）されるアプリケーション（以下課金アプリケーションと記載）を利用したユーザに対する課金を行う技術に係り、特に、任意の課金アプリケーションに関しての課金契約処理を効率的に行うのに好適な技術に関するものである。
【背景技術】
【０００２】
近年、多くの企業がネットワーク経由で利用可能なアプリケーションを提供している。例えば、Google社による、ワープロ、表計算アプリケーションや、SalesForce.com社による、顧客管理アプリケーションなどがその代表例である。
【０００３】
これらのアプリケーションはSaaS等とも呼ばれており、「ネットワーク経由」で利用する形態のため、その販売形態はパッケージ製品のような売り切りではなく、利用した分だけ月ごとに課金される従量的な課金方式が用いられることが多い。
【０００４】
このようなSaaSアプリケーション（課金アプリケーション）の利用者（ユーザ）に対する課金は、例えば以下のような情報をもとに行われる。
【０００５】
利用可能なユーザ数やログインした回数、
特定のオプション機能の有無、
利用したハードディスクの容量、
【０００６】
これらの課金の仕方は、各課金アプリケーションごとに異なり、課金アプリケーションの販売（利用申請）を自動化する場合、その利用申請画面は課金アプリケーションごとに開発する必要がある。
【０００７】
また、それらの利用申請画面から入力されたデータを基に課金情報を作成する必要があるが、この課金情報もまた課金アプリケーションごとに異なる計算方式が必要となり、個別に開発する必要がある。
【０００８】
複数の課金アプリケーションごとの利用申請画面を効率的に提供するための従来技術としては、例えば、特許文献１に記載の技術があるが、任意の課金アプリケーションに関して、申請データから課金情報の生成までを一元的に行う技術に関しての記載はない。
【０００９】
このように、従来技術では、課金アプリケーションの申請画面および課金計算を、当該課金アプリケーションごとに作成する必要があり、複数の課金アプリケーションに対する申請画面および課金情報の生成を一元的に処理することが困難であった。
【００１０】
そのため、従来は、課金アプリケーションごとに申請画面を作成し、課金アプリケーションごとに課金情報の生成を行っていることが一般的である。
【００１１】
つまり、従来の技術では、課金アプリケーションの申請画面、および課金情報の生成を課金アプリケーションごとに個別に開発する必要があるということになる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００４−３０４１０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
解決しようとする問題点は、従来の技術では、課金アプリケーションの申請画面、および課金情報の生成を、課金アプリケーションごとに個別に開発する必要があるという点である。
【００１４】
本発明の目的は、これら従来技術の課題を解決し、任意の課金アプリケーションに対応した申請画面の自動生成、および生成された画面からの入力情報に基づく課金情報の自動生成を行い、任意の課金アプリケーションに関しての課金契約処理を効率的に行うことを可能とすることである。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明では、課金アプリケーションに対する利用申請画面の自動生成、および、生成した画面からの入力情報に応じた課金情報の自動生成を行う。具体的には、アプリケーション（課金アプリケーション）の利用状態に応じて、当該アプリケーションを利用するユーザから徴収する利用料金を算出して課金するために、まず、第１の手段（価格パターン記憶処理部１０４）において、入力装置からの入力操作に応じて、アプリケーションの利用形態に応じた複数の課金形態（計算ロジック１０６）と当該課金形態をユーザが設定する際に用いる申請画面を構成するユーザ・コントロール群（ＵＩ部品１０５）とを対応付けて記憶装置に格納し、第２の手段（価格メンテナンス機能１０１）において、入力装置からの入力操作に応じて、アプリケーション毎に、当該アプリケーションの複数の利用形態に応じた各課金形態とユーザ・コントロール群のペアを記憶装置から読み出して、当該アアプリケーションに対応付けて記憶装置（価格情報データベース１０７）に格納し、第３の手段（レンダリング部１１１）において、入力装置を介してユーザから要求されたアプリケーションに対応付けられた各課金形態とユーザ・コントロール群のペアを記憶装置（価格情報データベース１０７）から読み出し、当該アプリケーションの課金形態の設定に用いる申請画面を生成して表示装置に表示し、さらに、第４の手段（入力解析部１１２）において、表示装置に表示した申請画面を用いてユーザが設定したアプリケーションの課金形態を当該ユーザに対応付けて記憶装置に格納すると共に、第５の手段（使用情報データベース１０９）において、ユーザ毎のアプリケーションの利用状態を収集して格納する。そして、第６の手段（計算適用部１１４）において、第５の手段（使用情報データベース１０９）が格納したユーザ毎のアプリケーションの利用状態と、第４の手段（入力解析部１１２）が記憶装置（入力情報データベース１０８）に格納したユーザ毎のアプリケーションの課金形態とを用いて、各ユーザが利用したアプリケーションの利用料金を算出し、当該ユーザに関しての課金データとして記憶装置（課金情報データベース１１６）に格納することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、価格パターンの組み合わせにより、柔軟に、各課金アプリケーションに対する価格設定を行うことができ、かつ、申請画面および課金情報の生成を自動化することが可能になり、課金アプリケーションごとの申請画面の開発や課金計算を行うことをせずに、一元的に申請情報および課金情報を管理することが可能となり、任意の課金アプリケーションに関しての課金契約処理を効率的に行うことが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明に係るアプリケーション利用料課金システムの構成例を示すブロック図である。
【図２】図１における価格パターンの構成例を示す説明図である。
【図３】図１における価格情報データベースのレコード構成例を示す説明図である。
【図４】図１における申請画面生成エンジンによる画面生成処理動作例を示すフローチャートである。
【図５】図１における申請画面の構成例を示す説明図である。
【図６】図１における入力情報データベースのレコード構成例を示す説明図である。
【図７】図１における課金データ生成エンジンによる課金データ生成処理動作例を示すフローチャートである。
【図８】図１における課金情報データベースのレコード構成例を示す説明図である。
【発明を実施するための形態】
【００１８】
以下、図を用いて本発明を実施するための形態例を説明する。図１に示す本発明に係るアプリケーション利用料課金システムは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）や主メモリ等を具備したコンピュータ装置からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、各処理部の機能を実現する。
【００１９】
すなわち、図１における本例のアプリケーション利用料課金システムは、プログラムされたコンピュータ処理を実行する機能として、価格メンテナンス機能１０１、価格パターン記憶処理部（図中「価格パターン」と記載）１０４、価格情報データベース１０７、入力情報データベース１０８、使用情報データベース１０９、申請画面生成エンジン１１０、課金データ生成エンジン１１３、課金情報データベース１１６を有している。
【００２０】
このような構成により、本例のアプリケーション利用料課金システムは、価格パターン記憶処理部１０４、価格メンテナンス機能１０１、申請画面生成エンジン１１０および課金データ生成エンジン１１３を利用することで、アプリケーション（課金アプリケーション）に対する申請画面１１５の自動生成、および、生成した申請画面１１５からの入力情報に応じた課金情報の自動生成を行う。
【００２１】
特に、本例のアプリケーション利用料課金システムでは、多様な課金アプリケーションの課金形態に対応するために、課金アプリケーションの価格情報を、価格パターン記憶処理部１０４で記憶管理する情報を用いて管理する。
【００２２】
価格パターン記憶処理部１０４は、申請画面１１５の生成に用いられるＵＩ（User Interface）部品１０５と、課金情報の生成に用いられる計算ロジック１０６とを対応付けて、ペアとして登録し管理する。
【００２３】
ＵＩ部品１０５とは、テキストボックス、ラベル、セレクトボックス等のユーザ・コントロール群を指し、主に、申請画面生成エンジン１１０が、入力操作用画面を生成する際に用いる部品情報である。また、計算ロジック１０７とは、単価計算やボリュームディスカウント計算などの計算ロジック群を指し、主に、課金データ生成エンジン１１３が、課金計算処理を行う際に用いる情報である。
【００２４】
このように、ＵＩ部品１０５と計算ロジック１０６とを価格パターンとしてペアで管理することにより、申請画面からの入力情報と課金情報の算出ロジック１０６を対応付けることが可能となる。
【００２５】
価格メンテナンス機能１０１は、課金アプリケーションごとの価格設定情報である価格情報データベース１０７を設定するための機能であり、価格情報データベース１０７においては、課金アプリケーションごとの価格情報を保持する。この価格情報は、図３に示すように、複数の価格項目レコードから構成され、各価格項目レコードには価格パターンが設定される。各課金アプリケーションの価格情報は、この価格パターンの組み合わせで表現される。
【００２６】
申請画面生成エンジン１１０は、具備したレンダリング部１１１により、利用者への申請画面１１５を自動生成する。このレンダリング部１１１では、当該課金アプリケーションに属する価格情報を、価格情報データベース１０７から取得し、各価格項目の価格パターンのうちＵＩ部品１０５をもとに画面生成を行う。
【００２７】
生成した申請画面１１５に対する入力情報は、申請画面生成エンジン１１０における入力解析部１１２により読み込まれ、価格パターンと対となるように、申請者情報（ユーザを特定するための情報）と共に、入力情報データベース１０８に記憶される。
【００２８】
課金情報の自動生成に関しては、課金データ生成エンジン１１３における計算適用部１１４において、価格情報データベース１０７から価格項目レコードを取得し、その設定された価格パターンの計算ロジック１０６を、入力情報データベース１０８に保持されている入力値と共に適用することによって、使用情報データベース１０９に格納された当該アプリケーションの当該利用者の利用状況に応じて自動計算する。
【００２９】
このようにして、本例のアプリケーション利用料課金システムによれば、価格パターンの組み合わせにより、柔軟に、各課金アプリケーションに対する価格設定を行うことができ、かつ、申請画面１１５の生成および課金情報の生成を自動化することが可能になり、課金アプリケーションごとの申請画面の開発や課金計算を行うことをせずに、一元的に申請情報および課金情報を管理することが可能となり、任意の課金アプリケーションに関しての課金契約処理を効率的に行うことが可能となる。
【００３０】
以下、各図を用いて詳細を説明する。
【００３１】
図２では、価格パターン記憶処理部１０４においてペアで管理するＵＩ部品１０５と計算ロジック１０７の一例（価格パターン例２０１〜２０４）を示している。
【００３２】
図２においては、価格パターン例２０１として、定額料金での計算ロジックとテキストボックスとのペア情報が、価格パターン例２０２として、定額単価での計算ロジックとチェックボックスとのペア情報が、価格パターン例２０３として、段階変動単価での計算ロジックとテキストボックスとのペア情報が、価格パターン例２０４として、従量単価での計算ロジックとテキストボックスとのペア情報が示されている。
【００３３】
価格メンテナンス機能１０１は、課金アプリケーションごとの価格情報を管理・設定を行うものであり、設定画面としてのメンテナンスＵＩ１０２から入力された価格情報を、定義更新部１０３により読み取り、定義更新部１０３では、読み取った価格情報を価格情報データベース１０７に渡す。
【００３４】
価格情報データベース１０７においては、各課金アプリケーションを一意に特定する「アプリケーションＩＤ」をキーとして、課金アプリケーションごとに価格情報を記憶する。この課金アプリケーションの価格情報は、課金項目単位に価格項目レコードとして表現され、価格項目レコードには、後述するエンジン郡（申請画面生成エンジン１１０、課金データ生成エンジン１１３）がそれぞれの処理で用いるための価格パターンが設定される。
【００３５】
図３において、価格項目レコードの構成を示す。図３の価格項目レコード３０１においては、価格パターン以外にも、申請画面生成エンジン１１０による申請用画面生成処理および課金データ生成エンジン１１３による課金情報生成処理に必要な項目が保持される。
【００３６】
また、課金データ生成エンジン１１３による課金データの生成時に単価もしくは価格として扱われる金額は、価格項目レコード３０１を親とする価格項目明細レコード（図中「明細レコード」と記載）として保持する。これは、ラジオボタンやセレクトボックスなどの複数の選択項目を設定できるＵＩ部品１０５を利用している価格パターンが設定された場合に、その選択項目名や選択時用の複数の価格を保持できるようにするためである。
【００３７】
価格項目レコード３０１においての、その他の項目として、申請画面生成エンジン１１０での処理で重要となる２つの項目について説明する。すなわち、申請画面生成エンジン１１０による申請用の画面生成時に価格項目の必須条件を示すオプションタイプ、および、価格項目をグルーピングするためのカテゴリについて説明する。
【００３８】
オプションタイプは、「必須」、「必須オプション」、「任意オプション」のいずれかの値を保持する。「必須」については、その価格項目の選択および入力が必須であることを示し、「任意オプション」では、その価格項目の選択が任意であることを表す。「必須オプション」については、この価格項目の同一カテゴリ内から１つの価格項目を選択することが必須であることを表す。
【００３９】
申請画面生成エンジン１１０は、価格情報データベース１０７で記憶管理する価格情報に基づいた申請画面の生成を行う「レンダリング部１１１」と、生成された画面からの入力情報の解析を行う「入力解析部１１２」から構成されており、図４に、画面生成までの処理手順が示されている。以下、図４を用いて、申請画面生成エンジン１１０による申請用画面生成の処理動作を説明する。
【００４０】
申請画面の生成が要求されると、申請画面生成エンジン１１０は、価格情報データベース１０７より該当の課金アプリケーションの価格情報を取得し（ステップＳ４００）、レンダリング部１１１により、この価格情報の価格項目レコードに対し画面生成を行う（ステップＳ４０１〜Ｓ４１０）。この画面生成処理は上述したオプションタイプによって分岐する。
【００４１】
例えば、オプションタイプが「必須」の場合（ステップＳ４０２）、レンダリング部１１１は、価格項目レコードに設定されたＵＩ部品１０５をそのままレンダリング（画像化）する（ステップＳ４０３）。
【００４２】
また「任意オプション」の場合は（ステップＳ４０４）、設定されたＵＩ部品１０５に任意選択用の「チェックボックス」を付加して（ステップＳ４０５）レンダリングする（ステップＳ４０６）。
【００４３】
さらに、「必須オプション」の場合は（ステップＳ４０５）、現在の価格項目レコードに対するカテゴリと同一な価格項目レコードに対して（ステップＳ４０７）、ＵＩ部品１０５に単一選択用のラジオボタンを付加してレンダリングを行う（ステップＳ４０８，４０９）。
【００４４】
これらの処理を、価格項目レコード分、繰り返すことによって申請画面１１５を生成する（ステップＳ４０１〜Ｓ４１０）。図５においては、図３における価格情報３０１に基づき生成した申請画面５０１を示している。この申請画面５０１において利用者は、入力情報の入力操作を行う。
【００４５】
このようにして図５に示す申請画面５０１を用いて利用者が入力情報の入力操作を行うと、入力解析部１１２において当該入力情報に対する処理を実行する。
【００４６】
入力解析部１１２では、該当課金アプリケーションの価格項目レコードを基に、入力情報と突き合せ、妥当性検査を行う。ここで行う主な妥当性検査は、上述したオプションタイプによる必須チェックに該当する。
【００４７】
正常なデータであれば、入力解析部１１２は、申請者情報とともに、突き合わせた価格項目レコードと対になるように、入力情報レコードを生成して、入力情報データベース１０８に送出し、入力情報データベース１０８において格納する。
【００４８】
このようにして入力情報データベース１０８において格納された入力情報レコードの構成例を図６に示す。
【００４９】
図６に示すように、入力情報レコード６０２においては、ひもづく価格項目レコード６０１が選択されているかを示す「選択フラグ」情報、実際に入力された値である「入力値」情報、および、申請者を一意に特定する「ユーザＩＤ」情報を保持する。
【００５０】
このようにして入力情報データベース１０８に格納された入力情報レコード６０２と各情報データベース１０７に格納された価格情報３０１および使用情報データベース１０９に格納された当該課金アプリケーションの利用者による利用状況情報を用いて、課金データ生成エンジン１１３において、当該課金アプリケーションの利用者に対する課金情報の生成を行う。
【００５１】
このような課金データ生成エンジン１１３による課金情報の生成処理動作を、図７を用いて説明する。
【００５２】
課金データ生成エンジン１１３は、まず、処理対象の課金アプリケーションの価格情報を価格情報データベース１０７から取得する（ステップＳ７００）。また、処理対象の申請者および課金アプリケーションの入力情報を入力情報データベース１０８から取得する（ステップＳ７０１）。
【００５３】
次に、課金データ生成エンジン１１３は、具備した計算適用部１１４により、価格項目レコードを繰り返し処理することによって課金データを生成する（ステップＳ７０２〜Ｓ７１０）。
【００５４】
すなわち、計算適用部１１４は、まず、価格項目レコードと合致する入力情報レコードを検索し（ステップＳ７０３）、その「選択フラグ」を判定して課金対象の価格項目か否かを判断する（ステップＳ７０４）。
【００５５】
課金対象の価格項目であれば（ｙｅｓ）、価格パターンの計算ロジックが従量系であるか否かを判別し（ステップＳ７０５）、否（ｎｏ：定額）であれば、価格項目レコード３０１，６０１に定義された計算部品を適用し、入力情報レコード６０２における「入力値」から、その価格項目ごとの課金額を算出する（ステップＳ７０６）。
【００５６】
また、ステップＳ７０５での判別で「従量系」であるとの判別結果であれば（ｙｅｓ）、使用情報データベース１０９から必要な使用情報をロードし（ステップＳ７０７）、計算ロジックに対して従量値を入力値として与えることで課金額を計算する（ステップＳ７０８）。
【００５７】
その後、および、ステップＳ７０６での処理の後、全ての価格項目の課金額を合計し（ステップＳ７０９）、その合計値をその課金アプリケーションに対する申請者への課金データとして生成し、課金情報データベース１１６において登録する（ステップＳ７１１）。
【００５８】
図８においては、課金情報データベース１１６が格納した図７の処理結果例を示している。例えば、図８の課金情報レコード８０１の１行目においては、図５に示す申請画面５０１における入力情報に基づき課金データ生成エンジン１１３が生成した課金データ例として、課金アプリケーション「ｘｘｘｘ００１」のユーザ「ｙｙｙｙ００１」に対する課金額（￥１０，５００）が示されている。すなわち、申請された「ユーザ数」が５名で（￥３００×５）、「メール機能」はアドバンス（￥８，０００）、「固定費」は月払い（￥１．０００）での申請であり、（３００×５）＋（８０００）＋（１０００）＝￥１０，５００が課金されている。
【００５９】
以上、図１〜図８を用いて説明したように、本例のアプリケーション利用料課金システムでは、課金アプリケーションに対する利用申請画面の自動生成、および、生成した画面からの入力情報に応じた課金情報の自動生成を行う。
【００６０】
具体的には、アプリケーション（課金アプリケーション）の利用状態に応じて、当該アプリケーションを利用するユーザから徴収する利用料金を算出して課金するために、まず、価格パターン記憶処理部１０４において、入力装置からの入力操作に応じて、アプリケーションの利用形態に応じた複数の課金形態（計算ロジック１０６）と当該課金形態をユーザが設定する際に用いる申請画面を構成するユーザ・コントロール群（ＵＩ部品１０５）とを対応付けて記憶装置に格納し、価格メンテナンス機能１０１において、入力装置からの入力操作に応じて、アプリケーション毎に、当該アプリケーションの複数の利用形態に応じた各課金形態とユーザ・コントロール群のペアを記憶装置から読み出して、当該アアプリケーションに対応付けて価格情報データベース１０７に格納し、レンダリング部１１１において、入力装置を介してユーザから要求されたアプリケーションに対応付けられた各課金形態とユーザ・コントロール群のペアを価格情報データベース１０７から読み出し、当該アプリケーションの課金形態の設定に用いる申請画面を生成して表示装置に表示する。
【００６１】
さらに、入力解析部１１２において、表示装置に表示した申請画面を用いてユーザが設定したアプリケーションの課金形態を当該ユーザに対応付けて記憶装置に格納すると共に、使用情報データベース１０９において、ユーザ毎のアプリケーションの利用状態を収集して格納する。そして、計算適用部１１４において、使用情報データベース１０９が格納したユーザ毎のアプリケーションの利用状態と、入力解析部１１２が入力情報データベース１０８に格納したユーザ毎のアプリケーションの課金形態とを用いて、各ユーザが利用したアプリケーションの利用料金を算出し、当該ユーザに関しての課金データとして課金情報データベース１１６に格納する。
【００６２】
このように、本例のアプリケーション利用料課金システムによれば、価格パターンの組み合わせにより、柔軟に、各課金アプリケーションに対する価格設定を行うことができ、かつ、申請画面１１５の生成および課金情報の生成を自動化することが可能になり、課金アプリケーションごとの申請画面の開発や課金計算を行うことをせずに、一元的に申請情報および課金情報を管理することが可能となり、任意の課金アプリケーションに関しての課金契約処理を効率的に行うことが可能となる。
【００６３】
尚、本発明は、図１〜図８を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、アプリケーション利用料課金システムを１つのコンピュータ装置に設けた構成としているが、各データベース（１０７，１０８，１０９）や生成エンジン（１１０，１１３）のそれぞれを個別のコンピュータ装置に設けた構成としても良く、また、申請画面１１５を、ネットワークを介して接続されたユーザ側のコンピュータ装置に表示する構成としても良い。
【００６４】
また、本例のコンピュータ装置の構成に関しても、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良く、さらに、本例では光ディスクを記録媒体として用いる説明をしているが、ＦＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【符号の説明】
【００６５】
１０１：価格メンテナンス機能、１０２：メンテナンスＵＩ、１０３：定義更新部、１０４：価格パターン記憶処理部、１０５：ＵＩ部品、１０６：計算ロジック、１０７：価格情報データベース、１０８：入力情報データベース、１０９：使用情報データベース、１１０：申請画面生成エンジン、１１１：レンダリング部、１１２：入力解析部、１１３：課金データ生成エンジン、１１４：計算適用部、１１５：申請画面、１１６：課金情報データベース、２０１〜２０４：価格パターン例、３０１：価格項目レコード、５０１：申請画面、６０１：価格項目レコード、６０２：入力情報レコード、８０１：課金情報レコード。
【図１】
2011034478.tif 000003
【図２】
2011034478.tif 000004
【図３】
2011034478.tif 000005
【図４】
2011034478.tif 000006
【図５】
2011034478.tif 000007
【図６】
2011034478.tif 000008
【図７】
2011034478.tif 000009
【図８】
2011034478.tif 000010