JP2005085045A - アプリケーション課金装置 - Google Patents

Abstract

【課題】 アプリケーションの実行に伴って、アプリケーションディベロッパが独自のポリシに基づき、課金できるようにすることを目的とする。
【解決手段】 アプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき前記課金手段が課金を行うようにする。
【選択図】 図１

Description

本発明は、コンピュータシステム一般における、アプリケーションの利用に対して課金を行う装置に関するものである。

従来より、一般的なコンピュータシステムで、アプリケーションを動作させ、その実行の度合い（ある機能の実行回数や成果物の量）により、アプリケーションのユーザに対して課金するシステムがあった。

例えば、特開平１１−２１９２９２号公報においては、ユーザコンピュータ上でアプリケーションを実行する度にカウンタデータをデクリメントし、カウンタデータが０以下になったらホストコンピュータに新たなカウンタデータの送信を要求する。そして、ホストコンピュータが新たなカウンタデータをユーザコンピュータに送信する時に、ユーザに対して課金を行うようになっている。

また、特開２００２−１１７１５７号公報においては、１台のMFP（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）上で複数のアプリケーションを動作させることができ、前記アプリケーションによる成果物に応じて、ＭＦＰのユーザに対して課金を行うようになっている。

特開平１１−２１９２９２号公報 特開２００２−１１７１５７号公報

しかし、前記従来技術には以下のような課題があった。
特開平１１−２１９２９２号公報が実現するシステムでは、アプリケーションのディベロッパが異なれば、各々のディベロッパが管理する、もしくは委託する、異なるホストコンピュータで課金されることになる。

例え、同一のホストコンピュータで課金されたとしても、課金するタイミング等、課金に関する決定はディベロッパの都合で行われる。つまり、各ディベロッパが個別にユーザに対して課金するものであり、ユーザは各ディベロッパに対し、いちいち料金を支払わなければならず、手間がかかる。

また、特開２００２−１１７１５７号公報が実現するシステムでは、ＭＦＰ上で動作させるアプリケーションのディベロッパが異なったとしても、アプリケーションの成果物のカウントはＭＦＰシステムが行うので、複数のアプリケーション間で統一的にユーザに課金できる。例えば、全アプリケーションに対する課金集計の時期を月の何日というように決定できる。

しかし、カウンタが更新されるのは、ＭＦＰが提供した機能を利用して、ＭＦＰが規定する成果物が得られた場合である。しかも、カウンタそのものもＭＦＰが管理するものである。アプリケーションディベロッパがアプリケーションの提供する機能及び独自の課金ポリシに基づき、課金カウンタを更新することはできない。

本発明は、以上のような課題を解決するためになされたものであり、その第一の目的は、コンピュータシステム一般において、アプリケーションの実行に伴って、アプリケーションディベロッパが独自のポリシに基づき、課金できるようにすることである。課金対象をシステム（ここでのシステムとはアプリケーション以外のハードウエア及びソフトウエアを指す）が提供する機能（例えば、複合機においては、プリント、スキャン）の実行以外にも広げることである。さらに言えば、システムが提供する機能に限らず、アプリケーションが提供する機能に従って、課金できるようにすることである。

また、第二の目的は、複数のアプリケーションディベロッパが各々のアプリケーションを動作させる上で、独自の課金を行ったとしても、システムとしては課金の集計を統一的に行うことにより、一貫した方法でユーザに料金を請求できるようにすることである。

上記目的を達成するために本発明は、アプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき前記課金手段が課金を行うことを特徴とするアプリケーション課金装置、を提供する。

本発明によれば、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、コンピュータシステム一般において、アプリケーションの実行に伴って、アプリケーションディベロッパが独自のポリシに基づき課金できる。

課金対象をシステム（ここでのシステムとはアプリケーション以外のハードウエア及びソフトウエアを指す）が提供する機能の実行以外にも広げることができる。
さらに言えば、システムが提供する機能に限らず、アプリケーションが提供する機能に従って課金できるようになる。

また、複数のアプリケーションディベロッパが各々のアプリケーションを動作させる上で、独自の課金を行ったとしても、システムとしては課金の集計を統一的に行うことにより、一貫した方法でユーザに料金を請求できるという効果もある。

以下、本発明の第一の実施の形態を、図を用いて説明する。
図１は本発明の第一の実施の形態の装置であるところの複合機（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ、略してＭＦＰとも呼ばれる）のハードウエア構成を示したブロック図であり、同図において、１０１は、中央演算装置であるところのＣＰＵであり、装置全体の制御を行う。各種アプリケーションやその他のプログラムの実行、並びに各種表示制御もここで行う。

ここで、アプリケーションとは、アプリケーションディベロッパ（以下、単にディベロッパと称す）が作成したプログラムであり、複合機上で実行されるものを指すものとする。本明細書における以下の記載についても同様とする。

１０２はＲＯＭであり、書換えが不要なプログラムやデータが格納されている。１０３はＲＡＭであり、装置制御時のデータあるいは画像データ等の各種データの一時的な格納場所となる。１０４は不揮発性ＲＡＭ（ＮＶＲＡＭ）であり、複合機の電源ＯＦＦ時にも保持する必要があるデータを書き込んでおくために使用される。

１０５はハードディスク（ＨＤ）であり、各種データ、プログラム、及びアプリケーションが格納される。ＨＤ１０５は、ＮＶＲＡＭ１０４と同じく、電源ＯＦＦでもデータを保持する手段として使うことが可能である。１０６はディスプレイであり、各種表示がなされる。

１０７は、リムーバブルメディアドライブであり、コードあるいはデータを外部とやり取りするための記憶媒体（リムーバブルメディア）を着脱自在に装着できる。

１０８は、ネットワークインタフェースであり、ネットワーク１０９とのインタフェースを担うものである。ここで、ネットワーク１０９は有線、無線を問わず、電気、光、赤外線、いずれの方式も問わない。

１１０はスキャナであり、文書等を光学的に走査し、読み取りを行い、画像データを得るものである。１１１はプリンタであり、各種データの印刷を行う。

次に、図２を用いて、ライセンスファイルの説明を行う。
ライセンスファイルはアプリケーションの利用をユーザに許可するためのものであり、例えば、アプリケーションの利用有効期限等の利用許可情報（ライセンス情報）が格納されている。ライセンスファイルは対応するアプリケーションと一対で存在する。

アプリケーションは、その不正使用を防止するため、暗号化される。その復号化に必要な復号化キーはライセンスファイル中に格納される（図示なし）。さらに、ライセンスファイルもまた、所定の暗号化キーによって暗号化される。

ライセンスファイルの復号化キーは複合機のみが知っている。このようにしておけば、ライセンスファイルの復号化、及びアプリケーションの復号化は複合機のみが行える。ライセンスファイルの偽造が不可能になり、偽ったライセンスを用いてアプリケーションを使用することもできなくなる。

ライセンスファイルがアプリケーションと分離された構成となっているのは、ライセンス情報の更新を可能にするためである。例えば、複合機のユーザからディベロッパに対価が支払われた場合、アプリケーションの利用有効期限が延長される。その場合、新たな利用有効期限を設定したライセンスファイルが複合機にインストールされる。

図２に示す如く、ライセンスファイルに書き込まれるライセンス情報には、共通ライセンス情報とアプリケーション独自ライセンス情報の２種類が存在する。
共通ライセンス情報とは、いずれのアプリケーションにも共通に設定されるべきライセンスに関する情報であり、例えば、そのライセンスファイルに関連付けられるアプリケーションを識別するためのアプリケーションＩＤであったり、アプリケーションの利用有効期限等の、多くのアプリケーションがサポートするようなライセンス情報であったり、そのライセンスが許可する、スキャナ１１０やプリンタ１１１の利用回数といった、複合機で予め定められた種類のライセンス情報であったりする。

第三の、複合機で予め定められたライセンス情報においては、ライセンス情報と現在の状態（例えば、スキャナ１１０やプリンタ１１１の利用回数）の比較、及びそれに基づく制御を、アプリケーションではなく、複合機のシステムが行う。ここでは、システムという語をアプリケーション以外のソフトウエア部分であって、ハードウエアを含めた複合機全体の制御及びアプリケーションまで含めた各種プログラムの実行及び管理を行う部分を指す意味で使用している。

スキャナ１１０やプリンタ１１１の起動等のトリガとなる動作はアプリケーションが行い得るが、アプリケーションは複合機の機能の実行を、複合機のシステムが提供するソフトウエアモジュールを呼び出すことで行っており、実際のスキャナ１１０やプリンタ１１１の制御、及びスキャナ１１０やプリンタ１１１の利用回数のカウントアップ等は、前記ソフトウエアモジュールつまりシステムが行っている。

前記利用回数は、複合機使用に関する課金に直接関係する重要な情報であるので、データのバックアップを取る等、複合機のシステムはこれに対する保護手段を備えている。

しかし、アプリケーション側から見れば、スキャナ１１０やプリンタ１１１の利用回数カウンタにアクセスするには、前記ソフトウエアモジュールを呼び出して、複合機システムが提供する機能を実行する以外にない。また、複合機システムがサポートするライセンス情報の数も種類も限られている。

これに対して、アプリケーション独自ライセンス情報はディベロッパが自由に定めたライセンスに関する情報である。このライセンスは複合機が提供する様々な機能（アプリケーション自身が提供する機能でもよい）に応じて、定められる。

例えば、データベース（ＤＢ）アクセス機能、メール機能、ファイル転送機能、アプリケーション利用時間、送受信データ量および種類、ストリームデータの受信時間、保存、機能の予約実行、エージェント、アプレット、スクリプト等のサブプログラムの実行の種類及び回数等、様々な機能についてのライセンスが考えられる。

ライセンスが規定する量的な値についても、回数、サイズ、時間、機能のポイント換算、あるいはそれらの組み合わせが考えられるし、ライセンス条件としては、量的な値による制限だけでなく、より複雑な条件も有り得る。これらの情報が、アプリケーション独自ライセンス情報として、ライセンスファイル中に格納されている。

図２に示すように、ディベロッパは決定したライセンス情報を格納したライセンスファイルを作成した後、それを暗号化する。暗号化が必要である理由は前述した通りである。そして、暗号化されたライセンスファイルを複合機にインストールする。

インストールされるライセンスファイルはネットワーク１０９を通じて入力されてもよいし、リムーバブルメディアに格納されたものがリムーバブルメディアドライブ１０７を通じて入力されてもよい。また、アプリケーションのインストールはライセンスファイルと同時に行っても、行わなくても、どちらでも良い。

なお、前記の説明では、ライセンス情報がライセンスファイルに格納されている例で説明したが、本発明はファイル形式に限定されるものではない。要は、ライセンス情報データが複合機にインストールされればよい。

次に、アプリケーション独自ライセンス情報についてさらに詳しく説明する。アプリケーション独自ライセンス情報の構成としては、そのアプリケーションについてライセンスする項目が１乃至複数個存在し、そのライセンス項目各々に対して、キー及び値からなる一組のデータが複数個存在している。

アプリケーションに対して、ライセンスする項目が１乃至複数個存在するというのは、例えば、そのアプリケーションがＤＢアクセス機能とメール機能を提供するものである場合、ＤＢアクセス量と、メール送受信量の双方にライセンスを設定したい場合等、複数個、ライセンスしたい項目が存在する場合が考えられるからである。

しかしながら、必ず識別すべきライセンス項目が存在しなければならないということはない。そのアプリケーションではライセンスすべき項目は決まっており、明示しなくても、そのアプリケーションにとっては、どんな機能に対するライセンス情報なのか分かる場合もある。この場合は、ライセンス項目を識別する情報がないことも有り得る。

一方、ライセンス項目各々に対して複数個存在するキー及び値のデータは、そのライセンス項目について設定される詳細なライセンス条件を表現したものである。図３にこのようなキー（あるいは、ライセンスキー。これは文字列で表現される）及び値の意味の例を示した。

”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”はライセンス項目を識別するためのものであり、その値は、数値、あるいは、文字列等、アプリケーションがそのライセンス項目を識別できさえすれば、何でも良い。

”ＮＡＭＥ”の値はライセンス項目の名前を指す文字列である。”ＤＥＳＣＲＩＰＴＩＯＮ”の値はライセンス項目の説明文字列である。これら２つについては、ライセンス項目の情報について、ユーザのためにディスプレイ１０６に表示させたり、プリンタ１１１から印刷させたりする目的のため、文字列を値として取っている。

”ＭＡＸ＿ＣＯＵＮＴ”の値は、そのライセンス項目がライセンスする最大カウントである。”ＭＡＸ＿ＳＩＺＥ”の値は、そのライセンス項目がライセンスする最大サイズである。

”ＭＡＸ＿ＴＩＭＥ”の値は、そのライセンス項目がライセンスする最大時間である。これらのキーの意味は、ライセンス項目によって異なる。また、１つのライセンス項目がこれらのキーを全て備えなければならないということはなく、そのライセンス項目に適したキーが存在していればよい。

”ＥＸＰＩＲＡＴＩＯＮ＿ＴＩＭＥ”の値は、そのライセンス項目の利用有効期限を意味する。前述したように、利用有効期限に関するライセンスは共通ライセンス情報の一項目としてもよいが、ここでは、アプリケーション独自ライセンス情報の中に入っているものとする。

”ＴＥＲＭ”はライセンス条件を設定するために汎用的に使用できるキーであり、その値は、数値、あるいは、文字列等、アプリケーションがそのライセンス条件を識別できれば、何でも良い。

”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＮＵＭ”、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＢＥＧＩＮ”、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＥＮＤ”の３つのキーは、他のものとは異なり、ライセンス項目各々について存在するものではなく、複合機のシステムが、ライセンスファイルを解析できるようにするためのものである。データの形式としては、他のキー及び値のデータと同一、もしくはそれに準じているので、ここで説明している。

図３におけるライセンスキーは予め定められた文字列を持つキーを示しているが、これら以外にもディベロッパは独自にライセンスキーを定めることができる。その場合は、前記予め定められたキー以外の文字列で表現されるキーを用いる。さらに、前述の例で、ライセンス条件は、文字列を持つキーと、それに対応する何らかのデータである値の組み合わせからなるとしたが、ライセンス条件の表現方法としては、これにとどまらず、他のデータ表現方法も用いることができる。

例えば、ライセンス条件の識別情報となるキーは文字列ではなく、例えば、数字、アルファベット、記号その他から構成される任意のIDを取ることもできる。要は、システム及びアプリケーションがライセンス条件を識別できさえすればよい。後述するライセンス情報を取得する共通ＡＰＩは、ライセンス条件の識別情報の形式がどうなっているかによって、変わってくる。

次に、アプリケーション独自ライセンス情報のライセンスファイルへの格納フォーマットの例について、図４を用いて説明する。
図４に示すように、アプリケーション独自ライセンス情報のフォーマットは、最初に、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＮＵＭ”キーとその値である、ライセンスファイル中のライセンス項目数が来て、次に、そのライセンス項目数が示す数の分、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＢＥＧＩＮ”と”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＥＮＤ”ではさまれるライセンス項目内容が来る。

”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”キーにおいては、その値がライセンス項目のＩＤを示す。なお、前述したようにライセンス項目を識別する情報がない場合は、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”キーがない。

”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＢＥＧＩＮ”及び”ＬＩＣＥＮＣＥ＿ＩＴＥＭ＿ＥＮＤ”キーには値が存在しない。不要だからである。各ライセンス項目には複数個のライセンスキー及び値の組データが存在する。

ライセンスキーと値とは、等号”＝”で区切られる。ライセンスキー及び値の各組データは改行文字で区切られる。ライセンスキーあるいは値の文字列中に、等号あるいは改行文字が現れた場合は、バックスラッシュ文字でエスケープされる。

もちろん、ここで示した区切り文字やフォーマットは一つの例である。これら以外の区切り文字を用いてもよいし、ＸＭＬ(ｅＸｔｅｎｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ)仕様に基づいたフォーマットを用いても良い。
要は複合機システムがこれを読み出した時に、例え、システムの知らないライセンスキーが存在したとしても、ライセンスファイルを解析でき、ライセンス情報を把握しておくことができればよい。

なお、図４中の”ＭＡＸ＿ＣＯＵＮＴ＿ＡＰＰＬＥＴ＿ＴＹＰＥ＿Ａ”、”ＭＡＸ＿ＣＯＵＮＴ＿ＡＰＰＬＥＴ＿ＴＹＰＥ＿Ｂ”、”ＭＡＸ＿ＣＯＵＮＴ＿ＡＰＰＬＥＴ＿ＯＴＨＥＲ＿ＴＹＰＥ”の各キーはディベロッパが独自に定めたキーの一例である。

次に、図５以下のフローチャートを用いて、本実施例の動作について説明する。
図５は複合機システムがライセンスファイル中のライセンス情報を解析する際の手順を示したフローチャートである。

同図において、最初に、ライセンスファイルが複合機にインストールされる（ステップＳ５０１）。図２を用いた前述の説明のように、インストールされるライセンスファイルはネットワーク１０９を通じて入力されてもよいし、リムーバブルメディアに格納されたものがリムーバブルメディアドライブ１０７を通じて入力されてもよい。インストールされたライセンスファイルはＨＤ１０５上に置かれる。

このライセンスファイルは前述のように暗号化されているので、ＣＰＵ１０１は、内部に予め備えた復号化キーを用いて、ライセンスファイルを復号化し（ステップＳ５０２）、その結果を読み出す（ステップＳ５０３）。

次に、ＣＰＵ１０１はライセンスファイルの解析を開始する。まず、共通ライセンス情報を取得し、そのデータを解析して、適当なデータ形式に変換して、ＲＡＭ１０３上に解析結果データを記憶する（ステップＳ５０４）。オブジェクト指向にのっとったシステムであれば、オブジェクトとして記憶されるであろう。

ＣＰＵ１０１は次いで、アプリケーション独自ライセンス情報を取得する。アプリケーション独自ライセンス情報の解析では、最初のキー”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＮＵＭ”とその値を読み出す（ステップＳ５０５）。これはアプリケーション独自のライセンス項目の数を表しており、ＣＰＵ１０１はこれを記憶しておく。

ここでキーと値の読み出しは、図４のフォーマットに基づくものとする。つまり、等号でキーと値が区切られている場合は、等号の前の文字までの文字列がキーとなる。キーと値の組データが改行文字で区切られている場合は、等号の直後の文字から改行文字の前の文字までの文字列が値となる文字列である。キーを読み出している場合に、改行文字が現れた場合は、改行文字の前の文字までの文字列がキーであり、値はなしとする。

次に、ＣＰＵ１０１はライセンス項目の処理が終了したかどうかを判断する（ステップＳ５０６）。未処理のライセンス項目の数が０であれば、Ｙｅｓとなり、処理を終了する。未処理のライセンス項目がまだ存在すれば、Ｎｏに進む。

ＣＰＵ１０１は次のキーを読み出し、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＢＥＧＩＮ”であることを確認する（ステップＳ５０７）。そうでなければ、フォーマットエラーであり、エラー処理をして（ステップＳ５１３）、終了する。例えば、「ライセンスファイルのフォーマットが不正です。」と、ディスプレイ１０６上に表示して、ライセンスファイルのフォーマット異常をインストールを行った人に通知する。

ステップＳ５０７が成功すれば、ＣＰＵ１０１は次のキーを読み出す（ステップＳ５０８）。そのキーが”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＥＮＤ”である場合は（ステップＳ５０９）、そのライセンス項目についての処理が終了したことを意味するので、ステップＳ５０６に戻り、次の未処理のライセンス項目の処理に移る。

”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＥＮＤ”でない場合は、ＣＰＵ１０１は次に、値を読み出す（ステップＳ５１０）。値となる文字列が数字のみからなる場合は、数値に変換しておく。

キーと値の読み出し時、ＣＰＵ１０１はそのフォーマットが正しいかどうかを判定する（ステップＳ５１１）。例えば、エスケープされていない等号が複数個存在したり、キーあるいは値の文字列の長さが予め定めた最大長を超えたりした場合は、フォーマットエラーとして、Ｎｏに進み、エラー処理をして（ステップＳ５１３）、終了する。

キーだけが存在し、値が存在しない場合も正しいフォーマットのデータとして扱う。アプリケーションによっては、そのようなライセンスキーをサポートしているかも知れない。

キー及び値を正しく読み出せた後、ＣＰＵ１０１はキー及び値を格納したオブジェクトを作成し、ＲＡＭ１０３上に記憶する（ステップＳ５１２）。その際、オブジェクトを後で区別するために、処理中のアプリケーションのアプリケーションＩＤ及び処理中のライセンス項目の”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”値と関連付けておく。

なお、前述したように、”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”キーが存在しない場合は、デフォルトの”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”値と関連付けておく。それからステップＳ５０８に戻り、次のキーの処理に移る。
このようにして、ライセンス情報は解析され、オブジェクトの形式で、情報が記憶される。

次に、アプリケーションのある機能の実行に伴い、アプリケーションが共通ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用いて、アプリケーション独自ライセンス情報にアクセスする際の手順について、図６のフローチャートを用いて説明する。

図６においては、アプリケーションは何らかの機能の実行回数をカウントしており、アプリケーション独自ライセンス情報として、”ＭＡＸ＿ＣＯＵＮＴ”値を用いていることを前提としている。
アプリケーションがその機能を実行するに当たり、ＣＰＵ１０１は、共通ＡＰＩを用いて、その機能に関した”ＭＡＸ＿ＣＯＵＮＴ”値を取得する（ステップＳ６０１）。

ここで共通ＡＰＩとは、システムが管理しているアプリケーション独自ライセンス情報にアクセスするためのＡＰＩを指す。各アプリケーションはそれを自由に呼び出せる。アプリケーションがそれを呼び出した場合は、そのアプリケーションのアプリケーションＩＤ、ライセンス項目のＩＤ、ライセンスキーを基に、指定されたライセンス項目のキーに対応する値が求められる。

例えば、Ｊａｖａ（Ｒ）言語（Ｊａｖａ（Ｒ）はサン・マイクロシステムズ社の米国並びにその他の国における商標である。）を用いた、この場合のＡＰＩとしては、次のようなものが考えられる。
Object getLicenseValue(int licenseID, String licenseKey);
（上記getLicenseValueはクラスApplicationのメソッドとする）

この場合、各アプリケーションは自アプリケーションを指すApplicationクラス（またはそのサブクラス）オブジェクトに対し、getLicenseValueを呼ぶ。その際のパラメータは、ライセンス項目のＩＤをlicenseIDとして、また、ライセンスキーをlicenseKeyとして渡す。例えば、図４におけるＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＮＯ＝１に対応する機能の実行に際してのステップＳ６０１の場合は、licenseIDとして１を、licenseKeyとして"MAX#COUNT"を渡すことになる。

なお、licenseIDの型を整数型としたのは、複合機システムで、ライセンス項目のＩＤは整数に限られている場合であり、ライセンス項目ＩＤがこれに限定されていないシステムでは、licenseIDの型としてObjectクラス（正確に言えば、Ｊａｖａ（Ｒ）.lang.Objectクラス）を用いても良い。

複合機システムは、前記メソッドが呼ばれると、呼び出したアプリケーションのオブジェクトインスタンスからアプリケーションＩＤを割り出す。これは前もって共通ライセンス情報を解析した時に、ライセンスファイルとアプリケーションＩＤを関連付けておくことで可能である。

何故なら、アプリケーションとライセンスファイルは対で構成されており、アプリケーション起動時にアプリケーションオブジェクトインスタンスとライセンスファイルが関連付けられているからである。

複合機システムはアプリケーションＩＤを割り出した後、パラメータとして渡されたlicenseID, licenseKeyからそのキーに関連付けられた値を求め、メソッドの戻り値として返す。値の型はいずれの型でもよいので、ここではObjectクラスとして返すようになっている。

これは、予め図５のステップＳ５１２で、処理中のアプリケーションのアプリケーションＩＤ及び処理中のライセンス項目の”ＬＩＣＥＮＳＥ＿ＩＴＥＭ＿ＩＤ”値と関連付けて、キー及び値を格納したオブジェクトの中から、該当するものを検索することで、実現可能である。

このように共通ＡＰＩの形式を定めておけば、アプリケーションが、そのアプリケーション独自ライセンス情報にアクセスするＡＰＩは容易に知ることができ、その呼び出しも簡単である。複数のアプリケーションを実行する、いわばプラットフォームを提供する側によっては重要なことである。

なお、ここでは共通ＡＰＩとしてＪａｖａ（Ｒ）言語を用いた例を説明したが他のプログラミング言語を用いても、同様のことが実現可能であることはいうまでもない。また、オブジェクト指向言語である必要はなく、例えば、前記アプリケーションＩＤはパラメータの一部としてＡＰＩに渡すようにすれば、アプリケーションＩＤをアプリケーションオブジェクトインスタンスから求める必要もなくなる。

さて、共通ＡＰＩを用いて、ある機能に関した”ＭＡＸ＿ＣＯＵＮＴ”値を取得した後、ＣＰＵ１０１は、今度は別の共通ＡＰＩを用いて、その機能に関する現在のカウント値を取得する（ステップＳ６０２）。

現在のカウント値はアプリケーション独自ライセンス情報ではない。では、何故、現在のカウント値が共通ＡＰＩを用いて取得されるのかと言えば、これが複合機システムの管理対象となっているからである。つまり、現在のカウント値はシステムがＲＡＭ１０３内にその格納領域を確保し、取得、更新、バックアップ及び永続的な保持にシステムが責任を持つ。

永続的な保持とは、複合機の電源がＯＦＦされた場合にもそのデータが失われないように、ＲＡＭ１０３上だけでなく、ＮＶＲＡＭ１０４あるいはＨＤ１０５上にも記憶しておくことを意味している。永続的な保持を行うために、アプリケーションは特別なＡＰＩを呼ぶ必要は無い。この処理はアプリケーションから見えない所でなされる。

永続的な保持は、ハードウエアの制御を必要とする場合がある。その場合、アプリケーションが永続的な保持を行うためには、直接ハードウエアを制御する必要が生じる。これは不適当である。

また、永続的な保持をシステムに任せれば、アプリケーションとしてはそれに対する処理を記述する手間が省ける。現在のカウント値等を共通ＡＰＩのアクセス対象とすれば、これらの効果がある。

このように、共通ＡＰＩのアクセス対象は、アプリケーション独自ライセンス情報に限らず、アプリケーションとシステムが共にアクセスが必要なデータまで拡張される。例えば、現在のカウント値の他には、課金額そのものの値も、その拡張対象とすることができる。現在のカウント値を取得する共通ＡＰＩの具体的な例は、前記getLicenseValueと同様であるので、省略する。

次いで、ＣＰＵ１０１は、取得した現在カウント値が前記”ＭＡＸ＿ＣＯＵＮＴ”値を超えたかどうか、比較する（ステップＳ６０３）。
超えた場合は、アプリケーションのディベロッパにその旨をメール等の手段で通知する（ステップＳ６０４）。

通知されたメッセージには、アプリケーションがどのユーザで使われているものかを示すためのユーザ情報、例えばメールアドレスや電話番号といった情報も付随される。この通知はディベロッパに何らかのアクションを起こさせるためである。これについては後述する。

それから、ＣＰＵ１０１は、現在カウント値がライセンスが許可する最大数を超えたので、機能が実行できない旨をディスプレイ１０６上に表示して（ステップＳ６０５）、機能を実行せずに終了する。

一方、現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値を超えない場合、ＣＰＵ１０１は、現在カウント値が前記”ＭＡＸ＿ＣＯＵＮＴ”値を超えそうかどうか、比較する（ステップＳ６０６）。

この際の閾値は適当に決定される。例えば、ライセンスファイル中に、ライセンスキーの一つとして、指定されるかもしれない。その場合は、”ＭＡＸ＿ＣＯＵＮＴ”値と同様に、共通ＡＰＩを用いて閾値が取得される。または、閾値は複合機システムが適当に内部で決定するかもしれない。

現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値を超えそうな場合は、ＣＰＵ１０１は、そのアプリケーションのディベロッパにその旨を通知する（ステップＳ６０７）。このメッセージもまた、ステップＳ６０４と同様に、ユーザ情報が付随される。

それからＣＰＵ１０１は、現在カウント値が上限に近づいた旨をディスプレイ１０６に表示する（ステップＳ６０８）。ユーザはこれを見て、ライセンス切れが近づいたことを知り、ライセンス更新手続きの準備をすることができる。

前記表示の終了後、あるいは、現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値を超えるにはまだ余裕がある場合は、ＣＰＵ１０１は、所定の機能を実行する（ステップＳ６０９）。
その後、共通ＡＰＩを用いて、現在のカウント値を更新して、終了する（ステップＳ６１０）。取得と更新の共通ＡＰＩは当然異なるが、名前を変えておくことで、容易に区別できる。

ステップＳ６１０では、現在のカウント値が前記機能の実行回数をカウントしているものであれば、現在のカウント値は１だけインクリメントされることになろう。あるいは、前記機能の実行時、例えば印刷が行われ、現在のカウント値が印刷枚数をカウントしているものであれば、印刷の枚数分、現在のカウント値がインクリメントされることになろう。

さて、図６のシーケンスでは、現在カウント値と”ＭＡＸ＿ＣＯＵＮＴ”値を比較し、現在カウント値の更新を行った。ここでは、”ＭＡＸ＿ＣＯＵＮＴ”値の更新を行っていない。しかし、現在カウント値を設けずとも同様なことが実現可能であることは明らかである。

その場合、”ＭＡＸ＿ＣＯＵＮＴ”値のみを読み出し、０あるいは所定の閾値との比較を行って、機能が実行できるかどうかを判断し、”ＭＡＸ＿ＣＯＵＮＴ”値をしかるべく更新（例えばデクリメント）することになろう。このようにすれば現在カウント値に関する記憶領域もＡＰＩも不要となる。

次に、ディベロッパ側での現在カウント値についての情報受信時（送信はステップＳ６０８による）の手順について、図７のフローチャートを用いて説明する。ディベロッパにおいて、図７の動作を行うには、ネットワーク機能を備えた一般のコンピュータで十分であるので、そのハードウエア構成についての説明は省略する。

ディベロッパでは現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値に近づいた旨をメール等の手段で受信する（ステップＳ７０１）。すると、ユーザに、その旨及びライセンス更新方法等の情報について、通知メールを送る（ステップＳ７０２）。場合によっては、アプリケーションのアップデート等、付加的な情報も含まれるかもしれない。これでユーザの注意を喚起できる。

ステップＳ６０８においても、ユーザに対して表示は行っているのだが、ステップＳ７０２においてはメール送信先ユーザを実際に操作したユーザと異なるユーザにすることで、例えば、複合機の管理者等、ライセンス更新権限を持ったユーザに宛ててメールを送ることができ、より効果的な通知ができる。

次に、ディベロッパ側での現在カウント値についての情報受信時（送信はステップＳ６０４による）の手順について、図８のフローチャートを用いて説明する。同図において、ディベロッパにおいて、現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値を超えた旨を受信する（ステップＳ８０１）。

ディベロッパのコンピュータは、アプリケーションを利用しているユーザのライセンス契約情報にアクセスし（図示なし）、そのユーザとライセンスの自動更新契約を締結しているかどうかを判断する（ステップＳ８０２）。

契約を締結していなければ、ユーザにライセンス更新を促すメールを送り（ステップＳ８０６）、終了する。
契約を締結していれば、ユーザに「ライセンスが切れたため、ライセンスの自動更新を行います」旨の通知メールを送る（ステップＳ８０３）。このメールにはライセンス自動更新にかかる費用も明記されることになろう。

そして、ディベロッパのコンピュータは更新ライセンス分について、銀行振替等の手段によりユーザから料金を徴収する（ステップＳ８０４）。
料金を徴収した後は、ライセンス更新情報を複合機に対して送信して（ステップＳ８０５）、終了する。

ライセンス更新情報は、新たな”ＭＡＸ＿ＣＯＵＮＴ”値や、”ＥＸＰＲＩＲＡＴＩＯＮ＿ＴＩＭＥ”値等を含んだ、ライセンスファイルと同じ形式、あるいはその一部を抜き出した形式で提供することが可能である（ライセンス自動更新の際に、それらの値が自動的に決定される場合、あるいは、図示しないが、ディベロッパとユーザの間で書面等の手段によってライセンス更新が行われ、ライセンス情報更新が全く独立した手順として行われるときも、このような方法でライセンス更新を行うことが可能である。）
また、ライセンスキーや値に変更がなければ、ライセンス更新があったということを示すデータのみを含んだものでもよい。

複合機のＣＰＵ１０１は、前記ライセンス更新情報を受信すると（ステップＳ８０７）、それに基づき、ＲＡＭ１０３上に持った、あるいはＮＶＲＡＭ１０４上やＨＤ１０５上に永続的に保持したライセンス情報を更新する（ステップＳ８０８）。

例えば、新たな”ＭＡＸ＿ＣＯＵＮＴ”値や、”ＥＸＰＲＩＲＡＴＩＯＮ＿ＴＩＭＥ”値を受信した場合は、内部のライセンス情報をその値に更新することになろう。あるいは、ライセンス更新があったということを示すデータのみを含んでいる場合は、単に現在カウント値を共通ＡＰＩを用いて、０に戻すという操作を施すかもしれない。

前述のステップＳ７０２において、現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値に近づいた時点で、ユーザに通知メールを送信していたが、この時にライセンス更新をすることも有り得る。この場合のライセンス更新では、０ではなく、（現在カウント値 − ”ＭＡＸ＿ＣＯＵＮＴ”値）の値が新たな現在カウント値として設定されることになろう。そうでないと、未実行カウントの分、ユーザが損をすることになるからである。

以上、図６から図８を用いた説明では、”ＭＡＸ＿ＣＯＵＮＴ”キーに関連するライセンス情報の取得及び更新について説明したが、これ以外のライセンスキーについても同様のことが可能であることは言うまでもない。

また、図６から図８の方法では、現在カウント値をインクリメントしていって、”ＭＡＸ＿ＣＯＵＮＴ”値を比較する方法について述べたが、本発明はこの方式に拘らず、残りカウント値の初期値を”ＭＡＸ＿ＣＯＵＮＴ”値にして、残りカウント値をデクリメントしていき、０と比較する方式でもよい。

または、”ＭＡＸ＿ＣＯＵＮＴ”値ではなく、”ＣＯＵＮＴ”値がライセンスキーとして存在し、初期値が最大許可数を意味し、機能の実行後とに、”ＣＯＵＮＴ”値がデクリメントされ、０と比較されるという方式でも良い。

さて、ライセンスキーに関連する値の取得及び更新を共通ＡＰＩを用いて行うことにより、アプリケーション側だけではなく、システム側でもそれらの値の取得が可能になる。そのことを示した手順について、図９のフローチャートを用いて説明する。

図９は複合機システムにおいて、スケジュール機能実行時、ライセンスに関する警告メールを送信する際の手順について示したものである。
同図において、最初にＣＰＵ１０１は、予め定められたスケジュール情報に基づき、スケジュール機能を起動する（ステップＳ９０１）。

ここでいうスケジュール機能とは、定期的な、あるいは予約された、特定機能の実行を指す。例えば、毎正時、予め登録した機能を実行することができる。ここでは、以下に説明する、全アプリケーションに対するライセンス情報のチェック手順が実行されるようになっているものとする。

次に、ＣＰＵ１０１は、ライセンス情報のチェックが複合機内にインストールされた全アプリケーションについて終了したかを判断する（ステップＳ９０２）。全アプリケーションについて、終了した場合は、処理を終了する。
全アプリケーションについて終了していない場合は、処理すべき次のアプリケーションを選択する（ステップＳ９０３）。

選択したアプリケーションについて、ライセンス項目がある場合は、全てのライセンス項目について処理が終了したかを判断する（ステップＳ９０４）。一つもライセンス項目がない、あるいは、全てのライセンス項目について処理が終了した場合は、ステップＳ９０３に戻り、次の処理すべきアプリケーションを選択する。

全てのライセンス項目について処理が終了していない場合は、処理すべき次のライセンス項目を選択する（ステップＳ９０５）。
選択したライセンス項目について、ライセンスキーがある場合は、全てのライセンスキーについて処理が終了したかを判断する（ステップＳ９０６）。一つもライセンスキーが存在しない、あるいは、全てのライセンスキーについて処理が終了した場合は、ステップＳ９０５に戻り、次の処理すべきライセンス項目を選択する。

全てのライセンスキーについて処理が終了していない場合は、処理すべき次のライセンスキーを選択する（ステップＳ９０７）。
そして、ＣＰＵ１０１は、選択したライセンスキーが”ＭＡＸ＿ＣＯＵＮＴ”であるかどうかを判断する（ステップＳ９０８）。”ＭＡＸ＿ＣＯＵＮＴ”である場合は、共通ＡＰＩを用いて”ＭＡＸ＿ＣＯＵＮＴ”値と現在カウント値を取得し、比較する（ステップＳ９１３）。

選択したライセンスキーが”ＭＡＸ＿ＣＯＵＮＴ”でない場合は、”ＭＡＸ＿ＳＩＺＥ”であるかどうかを判断し（ステップＳ９０９）、その場合は、共通ＡＰＩを用いて”ＭＡＸ＿ＳＩＺＥ”値と、ライセンスキー”ＭＡＸ＿ＳＩＺＥ”が対象とする、何らかのサイズに関わるデータの現在の値、すなわち現在サイズ値を取得し、比較する（ステップＳ９１４）。

さらに、選択したキーが”ＭＡＸ＿ＳＩＺＥ”でない場合は、”ＭＡＸ＿ＴＩＭＥ”であるかどうかを判断し（ステップＳ９１０）、その場合は、共通ＡＰＩを用いて”ＭＡＸ＿ＴＩＭＥ”値と、ライセンスキー”ＭＡＸ＿ＴＩＭＥ”が対象とする、何らかの機能の累積利用時間（そのアプリケーション自身の累積利用時間であることも有り得る。）を取得し、比較する（ステップＳ９１５）。

さらに、選択したキーが”ＭＡＸ＿ＴＩＭＥ”でない場合は、”ＥＸＰＩＲＡＴＩＯＮ＿ＴＩＭＥ”であるかどうかを判断し（ステップＳ９１１）、その場合は、共通ＡＰＩを用いて”ＥＸＰＩＲＡＴＩＯＮ＿ＴＩＭＥ”値を取得し、現在日時と比較する（ステップＳ９１６）。

さらに選択したキーが”ＥＸＰＩＲＡＴＩＯＮ＿ＴＩＭＥ”でない場合は、キーがシステムで処理可能な、その他のキーかどうかを判断し（ステップＳ９１２）、そうでない場合は、そのキーに対する処理は行わず、処理は終了したものとして、ステップＳ９０６に戻る。

キーがシステムで処理可能なその他のキーである場合は、そのキーに関し、前述した”ＭＡＸ＿ＣＯＵＮＴ”等の値と同様の方法で、ライセンス条件の判断を行う（ステップＳ９１７）。そして、ＣＰＵ１０１はステップＳ９１３からステップＳ９１７の比較、判断の結果、警告のための閾値を超えたかどうかを判断する（ステップＳ９１８）。超えていない場合は、そのキーに対する処理は終了し、ステップＳ９０６に戻る。

超えた場合は、予め設定された複合機管理者にその旨をメール等の手段で通知する（ステップＳ９１９）。スケジュール機能実行時は、複合機を実際に利用しているユーザがいるとは限らないので、このように複合機管理者に通知することが有効となる。

以上のように、図９に示すフローチャートでは、アプリケーション独自のライセンス情報であっても、そのライセンスの管理をシステムが行うことができる。
さらに、この方法によれば、例えば現在カウント値が”ＭＡＸ＿ＣＯＵＮＴ”値に近づいたことを、アプリケーションが検出しなくても、システムが検出してくれるので、アプリケーションに検出を仕様として義務付ける必要もなくなり、検出に関する実装誤りや忘れもなくなり、複合機全体としての信頼性も向上する。

次に、アプリケーション独自ライセンスの管理をシステムが行うことができる、もう一つの例として、ユーザログイン時の処理を図１０のフローチャートを用いて説明する。図１０は図９と同一の処理が多いので、変更点のみを説明する。

まず、ユーザが複合機に対してログインを行う（ステップＳ１００１）。ログインの目的は、複合機の操作はどのユーザが行っているのかをシステムが特定することにある。システムはこの情報を課金等に使用する。

ともあれログイン時に、ＣＰＵ１０１は、そのユーザに関連する全アプリケーションについてライセンス情報のチェックが終了したかどうかを判断する（ステップＳ１００２）。ユーザに関連するアプリケーションというのは、ユーザログインに伴い、所定のアプリケーションが起動するようになっており、ライセンス情報のチェックはそれらのアプリケーションに対してのみ行えばよい場合は、それらのチェック対象アプリケーションを指す。

もちろん、そのようなアプリケーションに限らず、システム起動時に同時に起動するアプリケーションもチェック対象に含めてよい。また、ここでは、ユーザに関連する全アプリケーションと限定したが、ステップＳ９０２と同様に登録済み全アプリケーションをチェック対象としても良い。

ステップＳ１００３からステップＳ１０１８はステップＳ９０３からステップＳ９１８と同様の処理であるので、説明を省略する。
ステップＳ１０１８において、ライセンス情報のチェックの結果、警告閾値を超えた倍は、ディスプレイ１０６上に警告ダイアログを表示し、ログインしたユーザの注意を喚起する。このようにすれば、ユーザログインのタイミングで、システムがアプリケーション独自ライセンス情報のチェックをすることができる。

次に、課金集計手順について、図１１のフローチャートを用いて説明する。課金集計は所定のタイミング、例えば毎月定められた日の午前０時に、システムが行う。あるいは、図示しない課金センタからの課金集計要求を受けて、システムが行う。集計の起動はどのように為されても良い。

最初に、ＣＰＵ１０１は、課金集計がシステムに登録された全アプリケーションについて終了したかどうかを判断する（ステップＳ１１０１）。全アプリケーションについて終了した場合は、システムが管理するカウンタ等について、課金を集計し（ステップＳ１１１５）、処理を終了する。

システムが管理するカウンタ等とは、アプリケーションに全く関わらない機能のカウンタ（アプリケーションがなくても実行可能な、複合機に初めから備えられた機能に関するカウンタ）、あるいは共通ライセンス情報に関連するカウンタ等のことであり、これらの更新及び集計はシステムが責任をもって行う。

ステップＳ１１０１で全アプリケーションについて終了していない場合は、処理すべき次のアプリケーションを選択する（ステップＳ１１０２）。
次いで、ＣＰＵ１０１は、そのアプリケーションに対する課金額をアプリケーション自身が計算したかどうか判断する（ステップＳ１１０３）。

アプリケーション自身が課金額を計算する場合は、例えば、図６に示した、機能の実行時に、現在カウント値を更新すると共に、アプリケーションのコード内部に実装した課金ポリシ、あるいはディベロッパのコンピュータからネットワークを通じて得た最新の課金ポリシに従って、現在カウント値から課金額を計算し、共通ＡＰＩを用いて、そのアプリケーションの課金額を更新しておく。

ここで、課金ポリシは、単純に１カウント当たり、いくらと決められることもあるだろうし、より複雑な計算式が与えられることもあるだろうが、適当なデータ形式で、課金ポリシが表現されているものとする。
あるいは、課金ポリシは、サブルーチン、メソッド、スクリプト、あるいは関数等のソフトウエアモジュールで提供されるかも知れない。その場合は、現在カウント値等をパラメータとして渡すことにより、課金額が計算される。いずれにしても課金ポリシはディベロッパが自由に設定できる。

アプリケーション自身が課金額の計算に責任を持つ場合は、システムが課金額の計算を行えなくてもよいが（つまり、課金ポリシをシステムが理解する必要はない）、システムが課金額の計算を行う場合は、ディベロッパが設定した課金ポリシを理解する必要がある。

つまり、課金ポリシデータをどう取り扱えばよいか、あるいは前記課金額を計算するソフトウエアモジュールをどう使用すればよいかについて、アプリケーション側と合意がとれているものとする。

課金額の更新に共通ＡＰＩを用いることで、システムが管理する記憶領域内に課金額の格納領域を確保し、ひいてはシステムのバックアップあるいは永続的な保持機能を利用することができる。

課金額をアプリケーションが計算した場合は、ＣＰＵ１０１は、共通ＡＰＩを用いて、前記計算したアプリケーションの課金額を取得する（ステップＳ１１０４）。そして、このアプリケーションについての処理を終了し、ステップＳ１１０１に戻る。

課金額をアプリケーションが計算しない場合は、ＣＰＵ１０１は、次に、そのアプリケーションに対する課金額の計算は終了したかどうかを判断する（ステップＳ１１０５）。終了した場合は、ステップＳ１１０１に戻る。

終了していない場合は、そのアプリケーションに、まだ課金を計算すべき項目が残っているということであり、課金額の計算を続ける。

課金計算の項目として、ＣＰＵ１０１はまず現在カウント値をチェックする。すなわち、現在カウント値データが存在し、かつ、それに対して課金計算すべきかどうかを判断する（ステップＳ１１０６）。

課金計算すべき場合は、ＣＰＵ１０１はカウント値に対する課金ポリシを取得し（ステップＳ１１０９）、共通ＡＰＩを用いて取得した現在カウント値と前記課金ポリシから課金額を計算する（ステップＳ１１１０）。そして、図示しないが、現在カウント値についての課金計算を終了したものとする。これによって、ステップＳ１１０６で連続してＹｅｓに進むことを防ぐ。

現在カウント値についての課金計算を終了すると、ステップＳ１１０５に戻り、他の項目の課金計算を行う。
ステップＳ１１０６でＮｏに進んだ場合、ＣＰＵ１０１は、次に、アプリケーションの累積利用時間データが存在し、かつ、それに対して課金計算すべきかどうかを判断する（ステップＳ１１０７）。

課金計算すべき場合は、ＣＰＵ１０１は累積利用時間に対する課金ポリシを取得し（ステップＳ１１１１）、共通ＡＰＩを用いて取得した累積利用時間データと前記課金ポリシから課金額を計算する（ステップＳ１１１２）。そして、図示しないが累積利用時間データに対する課金額の計算を終了したものとする。累積利用時間データについての課金計算を終了すると、ステップＳ１１０５に戻り、他の項目の課金計算を行う。

ステップＳ１１０７でＮｏに進んだ場合、ＣＰＵ１０１は、次に、その他の課金額を計算すべきデータがあるかを判断する（ステップＳ１１０８）。前述した例でいえば、現在サイズ値がこれに当たる。また、他のデータでもよい。

課金額を計算すべきデータがある場合は、そのデータに対する課金ポリシを取得し（ステップＳ１１１３）、共通ＡＰＩを用いて取得した前記データと前記課金ポリシから課金額を計算する（ステップＳ１１１４）。そして、そのデータに対する課金額の計算を終了したものとする。そのデータに対する課金計算を終了すると、ステップＳ１１０５に戻り、他の項目の課金計算を行う。

このようにすれば、１アプリケーションに対し、課金を計算すべき項目が複数個存在する場合も、課金を計算できる。また、言うまでもないことだが、ステップＳ１１１０、ステップＳ１１１２、及びステップＳ１１１４において、各々の項目の課金を計算するとき、それまで求めた、アプリケーションの課金額に加算していき、そのアプリケーションの課金額の計算が終了した時に課金額の合計が求まるようにしている。

以上のようにして、共通ＡＰＩを用いて、ディベロッパが独自に設定したライセンス情報に基づき、システムが課金集計を行うことが出来る。従って、複合機全体として、一貫した課金集計、料金徴収が行える。個々のアプリケーションが勝手に課金集計を行い、ユーザに料金請求を行うと、ユーザにとっては煩わしい事態となるが、一貫した料金徴収によって、そのような事態を防ぐことができる。

また、システムによる、各アプリケーションライセンス料の代行徴収も可能になり、ディベロッパは料金徴収の手間が省けるという効果もある。
以上、本発明について、複合機を用いて説明してきたが、本発明は複合機にとどまるものではなく、複数のアプリケーションを動作させ、そのライセンス管理を行う機器全てに応用可能なものである。

また、本発明は、ハードウエアを必要とするものの、それぞれの装置上で動作するプログラムにより実現可能である。従って、前述した実施形態の機能を実現するソフトウエアのプログラム、及びプログラムコードを記憶した記憶媒体においても、それを読み出して実行することにより、上記機能を実現することが可能である。

以下に本発明の特徴を付記する。
（附記１）アプリケーションを実行させるアプリケーション課金装置において、
前記アプリケーションの実行を制御する制御手段と、
前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、
前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、
前記カウント情報に基づいて課金を行う課金手段とを備え、
前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とするアプリケーション課金装置。

（附記２）アプリケーションを実行させるアプリケーション課金装置において、
前記アプリケーションの実行を制御する制御手段と、
前記アプリケーションが各々、規定する所定のカウント情報を記述したデータソースを入力する入力手段と、
前記カウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、
前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、
前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段が前記記憶手段中に前記カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき前記課金手段が課金を行うことを特徴とするアプリケーション課金装置。

（附記３）アプリケーションを実行させるアプリケーション課金装置において、
前記アプリケーションの実行を制御する制御手段と、
前記アプリケーションが各々、規定する所定の最大許可カウント情報を記述したデータソースを入力する入力手段と、
前記最大許可カウント情報と比較するための現在カウント情報を記憶する記憶手段と、
前記現在カウント情報を更新する更新手段と、
前記現在カウント情報を参照する参照手段と、
前記現在カウント情報に基づいて課金を行う課金手段とを備え、
前記入力手段が入力したデータソースに記述された最大許可カウント情報に基づき、前記制御手段が前記記憶手段中に前記現在カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記現在カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照した現在カウント情報に基づき前記課金手段が課金を行うことを特徴とするアプリケーション課金装置。

（附記４）附記２において、前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段は、前記カウント情報を更新するためのＡＰＩ（アプリケーションプログラミングインタフェース）を提供し、前記ＡＰＩは前記カウント情報の識別情報から呼び出し方法が容易に分かるように構成され、前記更新手段は、前記ＡＰＩを用いて前記カウント情報を更新することを特徴とするアプリケーション課金装置。

（附記５）附記４において、前記カウント情報の識別情報は、前記カウント情報の名前あるいは識別番号であることを特徴とするアプリケーション課金装置。

（附記６）１乃至複数のアプリケーションを実行させるシステム上で前記アプリケーションの課金を行うアプリケーション課金方法において、
前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶工程と、
前記カウント情報を更新する更新工程と、
前記カウント情報を参照する参照工程と、
前記カウント情報に基づいて課金を行う課金工程とを備え、
前記アプリケーションが前記更新工程を用いて前記カウント情報を更新すると共に、前記システムが前記参照工程を用いて参照したカウント情報に基づき、前記課金工程が課金を行うことを特徴とするアプリケーション課金方法。

（附記７）アプリケーションを実行させるシステム上で前記アプリケーションの課金を行うアプリケーション課金方法において、
前記アプリケーションが各々、規定する所定のカウント情報を記述したデータソースを入力する入力工程と、
前記入力工程にて入力したデータソースに記述されたカウント情報を記憶する記憶工程と、
前記カウント情報を更新する更新工程と、
前記カウント情報を参照する参照工程と、
前記カウント情報に基づいて課金を行う課金工程とを備え、
前記アプリケーションが前記更新工程を用いて前記カウント情報を更新すると共に、前記システムが前記参照工程を用いて参照したカウント情報に基づき、前記課金工程が課金を行うことを特徴とするアプリケーション課金方法。

（附記８）アプリケーションを実行させるシステム上で前記アプリケーションの課金を行うアプリケーション課金方法において、
前記アプリケーションが各々、規定する所定の最大許可カウント情報を記述したデータソースを入力する入力工程と、
前記入力工程にて入力したデータソースに記述された最大許可カウント情報と比較するための現在カウント情報を記憶する記憶工程と、
前記現在カウント情報を更新する更新工程と、
前記現在カウント情報を参照する参照工程と、
前記現在カウント情報に基づいて課金を行う課金工程とを備え、
前記アプリケーションが前記更新工程を用いて前記現在カウント情報を更新すると共に、前記システムが前記参照工程を用いて参照した現在カウント情報に基づき前記課金工程が課金を行うことを特徴とするアプリケーション課金方法。

（附記９）附記７において、前記入力工程が入力したデータソースに記述されたカウント情報に基づき、前記システムは、前記カウント情報を更新するためのＡＰＩ（アプリケーションプログラミングインタフェース）を提供し、前記ＡＰＩは前記カウント情報の識別情報から呼び出し方法が容易に分かるように構成され、前記更新工程は、前記ＡＰＩを用いて前記カウント情報を更新することを特徴とするアプリケーション課金方法。

（附記１０）附記９において、前記カウント情報の識別情報は、前記カウント情報の名前あるいは識別番号であることを特徴とするアプリケーション課金方法。

（附記１１）前記カウント情報、前記最大許可カウント情報、または前記現在カウント情報は前記アプリケーションが提供する機能の実行回数または実行累積時間または前記アプリケーションの実行に関する課金額のいずれかであることを特徴とする附記１乃至１０のいずれかに記載のアプリケーション課金装置またはアプリケーション課金方法。

（附記１２）附記６乃至１１のいずれかに記載のアプリケーション課金方法を実現するためのプログラム。

（附記１３）附記６乃至１１のいずれかに記載のアプリケーション課金方法を実現するためのプログラムを読み取り可能に記憶させた記憶媒体。

附記１の発明によれば、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、コンピュータシステム一般において、アプリケーションの実行に伴って、アプリケーションディベロッパが独自のポリシに基づき、課金できる。

課金対象をシステム（ここでのシステムとはアプリケーション以外のハードウエア及びソフトウエアを指す）が提供する機能の実行以外にも広げることができる。さらに言えば、システムが提供する機能に限らず、アプリケーションが提供する機能に従って、課金できるようになる。

また、複数のアプリケーションディベロッパが各々のアプリケーションを動作させる上で、独自の課金を行ったとしても、システムとしては課金の集計を統一的に行うことにより、一貫した方法でユーザに料金を請求できるという効果もある。

附記２のアプリケーション課金装置は、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記述したデータソースを入力する入力手段と、前記カウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段が前記記憶手段中に前記カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、前記カウント情報の記憶領域の確保を前記制御手段が行うので、前記カウント情報の管理を前記制御手段が行いやすくなり、例えば課金につながる重要な情報である前記カウント情報のバックアップも容易に行え、かつ、前記記憶領域にあるカウント情報もアプリケーションが容易に更新できるという効果がある。

本発明によれば、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、コンピュータシステム一般において、アプリケーションの実行に伴って、アプリケーションディベロッパが独自のポリシに基づき、課金できる。課金対象をシステム（ここでのシステムとはアプリケーション以外のハードウエア及びソフトウエアを指す）が提供する機能の実行以外にも広げることができる。さらに言えば、システムが提供する機能に限らず、アプリケーションが提供する機能に従って、課金できるようになる。

また、複数のアプリケーションディベロッパが各々のアプリケーションを動作させる上で、独自の課金を行ったとしても、システムとしては課金の集計を統一的に行うことにより、一貫した方法でユーザに料金を請求できるという効果もある。

附記２のアプリケーション課金装置は、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定のカウント情報を記述したデータソースを入力する入力手段と、前記カウント情報を記憶する記憶手段と、前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、前記カウント情報に基づいて課金を行う課金手段とを備え、前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段が前記記憶手段中に前記カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、前記カウント情報の記憶領域の確保を前記制御手段が行うので、前記カウント情報の管理を前記制御手段が行いやすくなり、例えば課金につながる重要な情報である前記カウント情報のバックアップも容易に行え、かつ、前記記憶領域にあるカウント情報もアプリケーションが容易に更新できるという効果がある。

附記３のアプリケーション課金装置は、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定の最大許可カウント情報を記述したデータソースを入力する入力手段と、前記最大許可カウント情報と比較するための現在カウント情報を記憶する記憶手段と、前記現在カウント情報を更新する更新手段と、前記現在カウント情報を参照する参照手段と、前記現在カウント情報に基づいて課金を行う課金手段とを備え、前記入力手段が入力したデータソースに記述された最大許可カウント情報に基づき、前記制御手段が前記記憶手段中に前記現在カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記現在カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照した現在カウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、データソース上にある最大許可カウント情報はこのまま残しておいて、現在カウント情報を更新するようにして、課金を計算できる。アプリケーションライセンスには何らかの機能実行に関する最大許可数が記述されている場合があり、その場合に都合がよい。

附記４のアプリケーション課金装置は、附記２において、前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段は、前記カウント情報を更新するためのＡＰＩ（アプリケーションプログラミングインタフェース）を提供し、前記ＡＰＩは前記カウント情報の識別情報から呼び出し方法が容易に分かるように構成され、前記更新手段は、前記ＡＰＩを用いて前記カウント情報を更新することを特徴とすることにより、アプリケーションが前記カウント情報を更新するためのＡＰＩを容易に知ることができ、全てのアプリケーションにとって望ましいプラットフォームを提供することができる。

附記３のアプリケーション課金装置は、１乃至複数のアプリケーションを実行させるアプリケーション課金装置において、前記アプリケーションの実行を制御する制御手段と、前記アプリケーションが各々、規定する所定の最大許可カウント情報を記述したデータソースを入力する入力手段と、前記最大許可カウント情報と比較するための現在カウント情報を記憶する記憶手段と、前記現在カウント情報を更新する更新手段と、前記現在カウント情報を参照する参照手段と、前記現在カウント情報に基づいて課金を行う課金手段とを備え、前記入力手段が入力したデータソースに記述された最大許可カウント情報に基づき、前記制御手段が前記記憶手段中に前記現在カウント情報を記憶させる領域を確保すると共に、前記アプリケーションが前記更新手段を用いて前記現在カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照した現在カウント情報に基づき、前記課金手段が課金を行うことを特徴とすることにより、データソース上にある最大許可カウント情報はこのまま残しておいて、現在カウント情報を更新するようにして、課金を計算できる。アプリケーションライセンスには何らかの機能実行に関する最大許可数が記述されている場合があり、その場合に都合がよい。

附記４のアプリケーション課金装置は、附記２において、前記入力手段が入力したデータソースに記述されたカウント情報に基づき、前記制御手段は、前記カウント情報を更新するためのＡＰＩ（アプリケーションプログラミングインタフェース）を提供し、前記ＡＰＩは前記カウント情報の識別情報から呼び出し方法が容易に分かるように構成され、前記更新手段は、前記ＡＰＩを用いて前記カウント情報を更新することを特徴とすることにより、アプリケーションが前記カウント情報を更新するためのＡＰＩを容易に知ることができ、全てのアプリケーションにとって望ましいプラットフォームを提供することができる。

複合機のハードウエア構成を示したブロック図である。 ライセンスファイルの説明図である。 ライセンスキーと値の意味を示した一覧の図である。 アプリケーション独自ライセンス情報のライセンスファイルへの格納フォーマットの例を示した図である。 複合機システムがライセンスファイル中のライセンス情報を解析する際の手順を示したフローチャートである。 アプリケーションが共通ＡＰＩを用いて、アプリケーション独自ライセンス情報にアクセスする際の手順を示したフローチャートである。 ディベロッパ側での現在カウント値についての情報受信時（送信はステップＳ６０８による）の手順を示したフローチャートである。 ディベロッパ側での現在カウント値についての情報受信時（送信はステップＳ６０４による）の手順を示したフローチャートである。 複合機システムにおいて、スケジュール機能実行時、ライセンスに関する警告メールを送信する際の手順を示したフローチャートである。 複合機システムにおいて、ユーザログイン時、ライセンスに関する警告ダイアログを表示する際の手順を示したフローチャートである。 課金集計の手順を示したフローチャートである

符号の説明

１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＮＶＲＡＭ
１０５ ＨＤ
１０６ ディスプレイ
１０９ ネットワーク
１１０ スキャナ
１１１ プリンタ

Claims (1)

1. アプリケーションを実行させるアプリケーション課金装置において、
   前記アプリケーションの実行を制御する制御手段と、
   前記アプリケーションが各々、規定する所定のカウント情報を記憶する記憶手段と、
   前記カウント情報を更新する更新手段と、前記カウント情報を参照する参照手段と、
   前記カウント情報に基づいて課金を行う課金手段とを備え、
   前記アプリケーションが前記更新手段を用いて前記カウント情報を更新すると共に、前記制御手段が前記参照手段を用いて参照したカウント情報に基づき、前記課金手段が課金を行うことを特徴とするアプリケーション課金装置。

Images