JP2007079859A - 画像形成装置およびその制御方法とプログラム - Google Patents

Abstract

【課題】有料の複写サービスにおける有償サービスの拡張時の柔軟性を向上させ、また、サービス毎の事前の課金を確実に行う。
【解決手段】複写機で提供されるサービスに対応するアプリケーションが実行されると、そのアプリケーションはサービスに対応する、複合機に用意された機能を呼び出す。機能が呼び出されると、課金監視層は課金情報テーブルを操作し（Ｓ５０１）、その機能は課金対象か判定する（Ｓ５０２）。課金対象であれば、課金情報を取得して、料金を請求する画面を表示する（Ｓ５０３）。料金が支払われると、該当機能を実行する（Ｓ５０４）。
【選択図】図５

Description

本発明は、たとえば公衆が利用可能な環境に設置され、有償での利用に供される画像形成装置およびその制御方法に関し、特に利用した機能に応じた料金の課金及び課金後の機能の実行を実現する画像形成装置及びその制御方法とプログラムに関する。

従来、公衆環境に接地され、利用者から装置の利用料を徴収して利用に供される複写機がある。このような有償複写機は、複写操作が行われると、まず、貨幣の支払い管理を行ういわゆるコインロボに十分な金額が投入されていることを確認する。そして、十分な金額が投入されていれば複写処理を行って、その処理が完了すると設定された金額をコインロボの投入金額から引き落とす。

また、複写枚数をカウンタにより数えておき、そのカウンタ値に応じて料金を課金する方式もある。このような複写機の中には、機能やアプリケーションプログラムを追加的にインストールでき、機能やアプリケーションプログラムのインストールに応じてカウンタも追加されるものが提案されている（たとえば特許文献１等参照）。この複写機は、実行した機能やアプリケーションプログラムの数等がカウンタにより計数する。そしてカウンタ値に応じて利用者は課金される。

上記従来の課金方式は、いずれも多機能化した複写機を公衆の利用に供するためには適当ではない。たとえば上述のコインロボを用いた複写機では、複写枚数に応じて課金するに過ぎず、複写以外の機能に対して課金することはできなかった。

また、特許文献１記載の複写機は、カウンタを用いた方式であるために、料金の請求が実際の処理の後で事後的に行われる。このため、多機能化に対しては対応可能である一方、公衆の利用に供するためには、たとえば支払いの履行を監視する管理者が不可欠であるなど、不都合な点がある。このように、多機能の複写機を、管理者を置かずに有償で公衆の利用に提供することは従来困難であった。

また、従来は提供する機能（サービス）とその課金体系とが固定化されており、新たなサービスを追加する場合、課金システムもそのサービスに合わせて作り込まなければならない。複写機の多機能化が今後ますます進むことが予想されるため、提供される有償のサービスも増加すると考えられる。ところがサービスとその課金体系とが従来のように固定化されていると、新機能追加のための労力や経費が多大なものとなってしまう。

本発明は上記従来例に鑑みてなされたもので、複写に限らず新規な機能に対する課金をすることができ、課金金額をその都度回収して公衆による利用に適した複写機等の画像形成装置およびその制御方法とプログラムを提供することを目的とする。また、提供される機能に共通の課金のしくみを持つプラットフォームを提供することで、新規機能の課金処理に伴うアプリケーション開発の負担の増加を防止できる複写機等の画像形成装置およびその制御方法とプログラムを提供することを目的とする。

アプリケーションプログラムが利用する機能を特定し、複合機に搭載されたプログラム等を含む各種機能の利用状況に応じた適切な課金を、サービスの実行前にユーザに提示する仕組みを提供することをさらに別の目的とする。

上記目的を達成するために本発明は以下の構成を備える。すなわあち、利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させることが可能な画像形成装置であって、
アプリケーションプログラムで実行される機能のうち、有償機能を判別する有償機能判別手段と、
前記有償機能判別手段により判別された有償機能について、課金が実行できることを判定する課金判定手段とを備え、
前記課金判定手段により課金が実行できると判定された場合、前記有償機能を実行させることを特徴とする。

あるいは、利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置であって、
前記アプリケーションプラットフォームは、
課金対象の有償機能を識別するための課金テーブルと、
前記課金テーブルを参照して有償機能の実行を監視する課金監視手段と、
前記課金監視手段により有償機能の実行が見出された場合、該有償機能に対応する金額を表示し、その課金が実行できるかを判定する課金ライブラリとを備え、
前記課金が実行できる場合は前記有償機能の実行を許すことを特徴とする。

あるいは、利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置であって、
前記アプリケーションプラットフォームは、
課金対象の有償機能を識別するための課金テーブルと、
前記アプリケーションプログラムによる、前記有償機能の呼び出しの宣言に応じて、宣言された機能およびその課金金額を記憶する宣言記憶手段と、
前記アプリケーションプログラムによる合算メッセージに応じて、前記宣言記憶手段により記憶した有償機能に対応する金額を表示し、その課金がされた場合には、その旨記憶する支払記憶手段と、
前記アプリケーションプログラムにより前記有償機能が実行される場合、当該アプリケーションプログラムに対応して課金がされているか否かを判定する判定手段とを備え、
課金がされていると判定された場合には、前記有償機能の実行を許すことを特徴とする。

本発明によれば、複写機等の画像形成装置に有償の新規サービスを追加した場合に、そのサービスに対する課金処理に伴うアプリケーション開発の負担を軽減できる。

また、サービスに対する課金を、画像形成装置の利用の都度、回収して公衆による利用に適した複写機等の画像形成装置を提供することができる。

また、１つのサービスが複数の有償の機能を利用している場合であっても、それに対する課金を一元的に行え、利用者の利便性を向上させることができる。

［第１実施形態］
本実施形態では、コンビニエンスストア等に設置された複写機（またはディジタル複合機）によって、ネットワーク上のサーバから楽譜をダウンロードして印刷するサービスを例にとって説明する。

このサービスは、
１．利用できる楽譜の一覧をダウンロードし、
２．一覧からユーザに楽譜を選択させ、
３．選択された楽譜をダウンロードし、
４．その楽譜をＡ３で印刷する、
という処理の流れになっている。そしてこのサービスは、サービス料として楽譜１部につき一定金額、たとえば５００円が課金され、さらに印刷代として１枚につき一定金額、たとえば１０円が課金される。印刷枚数は楽譜の長さに応じて異なる。

図１は、このような楽譜印刷サービスを展開するコンビニエンスストアのネットワーク構成図である。コンビニエンスストア本部の課金情報サーバ１００には、図２で示す課金情報テーブル２００が格納されている。課金情報サーバ１００は、各コンビニエンスストア店舗の複合機１０１で提供するサービスの課金対象と料金に関する情報等を一元管理している。課金情報テーブル２００には、複合機自体が本来備えている印刷機能、スキャン機能、ファクシミリ機能それぞれの課金情報が保存されている。それに加えて課金情報テーブル２００には、サードパーティ等により提供される、独自の処理を行うライブラリプログラムやアプリケーションプログラムを用いたサービスに独自の機能に対する課金情報も保持している。すなわち、本例では、複合機１０１により楽譜の印刷というサービスが提供され、そのサービスに独自の機能である楽譜のダウンロードに対する料金等が保存されている。なお、楽譜印刷サービス以外にもコピーサービスなども本実施例を適用できる。

楽譜サーバ１０２は、各複合機１０１によりダウンロードして印刷可能な形式の楽譜データを保存している。サーバ１００、１０２および複合機１０１は、ネットワーク１０３により接続されている。

図２に示す課金情報テーブル２００について説明する。課金情報テーブル２００には、複合機１０１により提供される機能毎に、機能名２０１、課金フラグ２０２、機能に対する料金２０３、機能種別２０４、表示されるメッセージ２０５が登録されている。機能名２０１は機能の識別名であり、図２には通常の名称を記載したが、機能毎に固有の識別情報であればよい。また、課金情報テーブル２００の先頭からのオフセットにより機能を識別するようにテーブルを構成すれば、機能名２０１はなくとも構わない。

課金フラグ２０２は課金対象か否かを示す。図２においては丸記号が課金されること示す。料金２０３は、その機能に対する単価を示す。たとえば印刷機能で有れば、１枚あたりの単価は１０円に設定されている。もちろんサイズやカラー／モノクロの別等により印刷単価は異なるであろうが、本例では簡単のためにこの様に単純化している。楽譜のダウンロード機能に対する料金は、本例の前提に従って５００円である。種別２０４はその機能が実行されるレイヤを示す。印刷、スキャン、ファクシミリは、複合機１０１に備えられたハードウエアデバイスにより実行されるのでデバイス機能と記述されている。デバイス機能は、ライブラリやアプリケーションにより使用可能である。これに対して電子透かしやＯＣＲ機能は、複合機にソフトウエアライブラリとして提供された機能であり、追加ライブラリと記述される。ライブラリはアプリケーションにより使用可能である。楽譜ダウンロードはアプリケーションにより実現される機能であり、追加アプリケーションと記述されている。アプリケーションは、利用者に提供されるサービスの一単位を構成する。種別も固有の識別情報であればよい。

メッセージ２０４は、該当する機能の実行時に複合機の表示パネルに表示されるメッセージである。たとえば印刷機能に対しては「％ｓを％ｓ枚印刷します。」というメッセージが保存されている。ここで％ｓは変数であり、最初の％ｓには用紙サイズで、２番目の％ｓには枚数で置換されたメッセージが表示される。

＜複合機（画像形成装置）のハードウェア構成＞
図１５は、複合機１０１のハードウェア構成を示すブロック図である。制御ユニット１１１は、画像入力デバイスであるスキャナ１１３や画像出力デバイスであるプリンタ１１４と接続し、一方ではＬＡＮ１００や公衆回線（ＷＡＮ）と接続することで、画像情報やデバイス情報の入出力を行なうコントローラである。

ＣＰＵ３０１は、ＲＡＭ３０２に格納されたプログラムを実行することで、制御ユニット１１１全体を制御し、あるいは複合機の機能を実現するコントローラである。後述のフローチャートに係る処理はＣＰＵ３０１により実行される。ＲＡＭ３０２は、ＣＰＵ３０１が動作するために使用するデータやプログラムを格納するシステムワークメモリである。また、ＲＡＭ３０２は、画像データを一時記憶するための画像メモリでもある。ＲＯＭ３０３は、ブートＲＯＭであり、システムのブートプログラムが格納されている。ＨＤＤ３０４は、ハードディスクドライブであり、システムソフトウェア、画像データを格納する。

操作部Ｉ／Ｆ３０６は、操作部（ＵＩ）１１２との間のインタフェースを司り、操作部１１２に表示すべき画像データを操作部１１２に対して出力する。また、使用者が操作部１１２を介して入力した情報を、ＣＰＵ３０１に伝える役割を果たす。操作部には、サービスに対する料金の投入を促すメッセージ等が表示される。

ネットワークインタフェース（Ｎｅｔｗｏｒｋ）３０８は、ＬＡＮ１００との接続を司り、ＬＡＮ１００に対して情報の入出力を行なう。サーバ１００、１０２とはネットワークインターフェース３０８を介して接続されている。課金情報テーブル２００へのアクセスや楽譜データの取得はネットワークインターフェース３０８を介して行われる。モデム（ＭＯＤＥＭ）３０９は、公衆回線との接続を司り、公衆回線に対して情報の入出力を行なう。ファクシミリはモデム３０９を介して送受信される。以上のデバイスがシステムバス３０７上に配置される。

イメージバスインターフェース（Ｉｍａｇｅ Ｂｕｓ Ｉ／Ｆ）３０５は、システムバス３０７と画像データを高速で転送する画像バス３１０とを接続し、データ構造を変換するバスブリッジである。画像バス３１０は、ＰＣＩバスまたはＩ１５Ｅ１３９４で構成される。

画像バス３１０には以下のデバイスが配置される。ラスタイメージプロセッサ（ＲＩＰ）３１１は、ネットワークから送信されたＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部３１２は、画像入出力デバイスであるスキャナ１１３やプリンタ１１４と制御ユニット１１１とを接続し、画像データの同期系／非同期系の変換を行なう。

スキャナ画像処理部３１３は、入力画像データに対し補正、加工、編集を行なう。プリンタ画像処理部３１４は、プリント出力画像データに対して、プリンタ１１４の性能に応じた補正、解像度変換等を行なう。画像回転部３１５は画像データの回転を行なう。画像圧縮部３１６は、多値画像データに対してはＪＰＥＧ圧縮伸長処理を行い、２値画像データに対してはＪＢＩＧ、ＭＭＲ、ＭＨの圧縮伸長処理を行なう。

Ｉ／Ｏインターフェース３２１はコインロボ３２２と接続され、制御ユニット１１１によるコインロボ３２２の制御のために利用される。コインロボの制御は従来行われている通りのものである。たとえば、投入金額を読み出すこと、及び、指定した金額の釣り銭を返却させること等の動作が制御される。

図１６は、複合機１０１の外観を示す斜視図である。画像入力デバイスであるスキャナ１１３は、原稿となる紙上の画像を照明し、１３Ｄラインセンサ（図示せず）を走査することによって、ラスターイメージデータを生成する。

画像出力デバイスであるプリンタ１１４は、ラスターイメージデータを用紙に印刷する部分である。その方式は、感光体ドラムや感光体ベルトを用いた電子写真方式、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式であってもよい。なお、プリント動作は、ＣＰＵ３０１からの指示によって起動される。プリンタ１１４は、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセット４０１、４０２、４０３がある。また、排紙トレイ４０４は、印字し終わった用紙を受けるものである。

利用者は操作部１１２に表示されたメニューから所望のサービスを選択する。たとえば複写であれば、それを選択し、表示された料金をコインロボに投入して複写操作を行う。その際には、使用者は原稿用紙を原稿フィーダ４０５のトレイ４０６にセットして、操作部１１２において読み取りの起動を指示する。それに応じて制御ユニット１１１のＣＰＵ３０１がスキャナ１１３に指示を与え、トレイ４０６にセットされた原稿用紙は１枚ずつフィードされ、スキャナ１１３が原稿画像の読み取り動作を行なう。読み取られた画像はプリンタ１１４により印刷される。

楽譜ダウンロードを行う場合には、利用者は操作部１１２に表示されたメニューから楽譜ダウンロードサービス及びダウンロードされる楽譜を選択し、料金を投入する。この場合にはこの２つの操作により楽譜は印刷される。ただし本例では、利用者は楽譜ダウンロードの料金と印刷の料金とをそれぞれ投入するのに対して、後述の第２実施形態ではまとめて投入できる。

＜複合機のソフトウエア構成＞
図３は複合機に搭載されるソフトウェアの構成図である。楽譜印刷アプリケーション３０１のような一般的なアプリケーションプログラム（以下アプリケーションと略す場合がある。）は、対応するサービスを実現するために実行される。アプリケーションは、アプリケーション・プラットフォーム３１０の最上位層である一般ライブラリ３０２に含まれる必要なライブラリを呼び出す。それによってライブラリにより提供される機能が実現される。なおアプリケーション・プラットフォーム３１０はひとつのものとして有るわけではなく、ライブラリにより提供される、アプリケーションプログラムに対するインターフェースの集合である。そのライブラリの呼び出しを、ライブラリの直下にある課金監視層３０４が、課金情報テーブル２００に基づいてフックし、課金ライブラリ３０３に単価や量、メッセージ等のパラメータとともに処理を引き渡している。呼び出されたライブラリは、必要に応じてオペレーティングシステム３０７により提供される機能や、デバイスドライバ３０８を使用する。そしてその際には、インタープリタ３０５やコントローラ３０６が介在するが、本実施形態ではこれら中間層に関する説明は省略する。なお課金監視層３０４はプログラムにより実現される。

次に、実際のアプリケーションにおける課金ライブラリ３０３による処理およびその前後の動作を説明する。図４に楽譜印刷アプリケーション３０１の構成概要図を示す。ここでは課金対象機能であるダウンロードと印刷とに関連する部分をまとめて表している。楽譜印刷アプリケーション３０１において各機能を実行するダウンロードモジュール３０１ａおよび印刷モジュール３０１ｂは、それぞれネットワークライブラリ３０２ａおよび印刷ライブラリ３０２ｂを呼び出す。各ライブラリはその機能を実行するために、中間層４１０を介してオペレーティングシステムの機能（デバイスにより提供される機能を含む）をさらに呼び出す。

課金監視層３０４は、それぞれのライブラリによる機能（あるいは処理や関数とも呼ぶ。）呼び出しを監視している。そしてその機能の呼出しをフックして、課金ライブラリ３０３に処理を渡している。なお、課金監視層３０４におけるフックは、呼び出される機能すべてについて実施される。実際に課金されるか否かは、フック後に課金情報テーブル２００を参照して判断される。図４の例では、印刷ライブラリは印刷設定と印刷実行という２つの機能を呼び出すが、課金対象となり得るのは印刷実行機能のみであり、印刷設定機能は課金されない。印刷実行機能も、課金情報テーブル２００の登録内容次第では課金されないこともあり得る。しかし、いずれの機能も課金情報テーブル２００の内容に関わらずフックされ、登録の有無が判定される。課金ライブラリ３０３は、主に操作パネル１１２およびコインロボ３０８ｄとの入出力インターフェースを持ち、それらを介してユーザに課金を促したり、入金を確認したりする。またネットワークライブラリ３０２ａはＮＩＣ（ネットワークインターフェース）３０８ａの機能をオペレーティングシステムを介して呼び出す。その機能呼出しも課金監視層３０４によりフックされる。

＜課金監視層による動作＞
課金ライブラリ３０３内部では、図５に示すように課金処理が実施される。利用者が楽譜ダウンロードサービス及びダウンロードされる楽譜を選択することで、楽譜ダウンロードアプリケーションが実行される。その中で、選択された楽譜を対象とした楽譜ダウンロード機能や、印刷機能が呼び出される。図５の処理は、それら機能が呼び出されたときに、課金監視層３０４および課金ライブラリ３０３で実行される手順である。以下の説明において、特に課金ライブラリ３０３で実行されると記載していない工程は課金監視層３０４で実行される。

具体的には、ライブラリにより所定の機能（あるいは関数とも呼ぶ）の呼出しがあると、それをフックする。アプリケーションやライブラリの追加時の便宜のために、所定の機能以外の機能の呼出しがあるとそれをフックするようにしてもよい。機能の呼出しを、たとえば機能毎の名称（機能名）をパラメータとして所定の関数をコールすることで行えば、フック対象となる機能であるか否かは、パラメータである機能名をフック対象の有無を示す表と照合するだけで特定できる。本例では、フック対象の有無を示す表としても課金情報テーブル２００が用いられる。そのため課金情報テーブル２００に登録された機能は、課金監視層３０４によりフックされる。

機能の呼出しがあると、図５の処理が開始される。まず課金情報テーブル２００の内部、特に機能名を走査する（Ｓ５０１）。本実施形態では、課金情報テーブル２００はあらかじめ複合機にダウンロードしてあるものとしたが、課金情報サーバ１００内の課金情報テーブル２００をネットワークを介して参照しても良い。課金情報テーブル２００を走査した結果、その機能が登録されており、しかも今フックした処理の課金フラグ（課金属性よも呼ぶ。）がオンであるか否か判定する（Ｓ５０２）。機能名が登録されていないか、あるいは登録されていても課金属性がオフであれば、すぐに処理を戻し、指定機能を継続する（Ｓ５０７）。一方機能名が登録されており、その課金属性がオンであれば、課金情報テーブル２００より、該当する機能の課金情報（料金およびメッセージ）を読み取る（Ｓ５０３）。その課金情報をパラメータとして課金ライブラリ３０３に渡し、課金ライブラリ３０３を実行させる。ステップＳ５０４からステップＳ５０６は、課金ライブラリ３０３による処理である。もちろん、課金ライブラリ３０３の機能の一部としての課金テーブルの参照機能や課金計算の機能を課金情報サーバ１００内に実装しても良い。この場合は、複合機内の、実行指示されたアプリケーションが発行する宣言メッセージがネットワークを介して課金サーバ１００に送信される。そして、当該メッセージに対応する課金テーブル１００が課金サーバ１００において参照される。課金サーバ１００は、課金テーブル２００を参照して有償機能を特定して、課金すべき金額を計算し、有償機能情報の一例として、図６、図７、図１０を表示するために必要な情報を、複合機に通知してもよい。複合機は、有償機能情報を取得して、実行指示されたアプリケーションの有償機能を判別してもよい。

課金ライブラリ３０３は、パラメータに基づいて図６および図７に示す支払請求画面を表示する（Ｓ５０４）。すなわち、メッセージを第１行目に表示し、金額を第２行目に表示すると共に文字列「を投入してください」を表示する。図６および図７において点線で囲んだ１行目のメッセージ６０１，７０１および金額６０２，７０２が、課金情報に基づいて表示された部分である。支払請求画面を表示した後、課金ライブラリ３０３はコインロボの状態監視ループに入る。コインロボは現在投入されている金額を課金ライブラリ３０３に渡すインターフェースを備えている。課金ライブラリ３０３は、定期的に投入金額を取得する（Ｓ５０５）。そして、その投入金額が課金情報テーブル２００から取得した料金以上であるか判定する（Ｓ５０６）。料金以上であれば、状態監視ループを抜ける。そうすると課金ライブラリ３０３は、処理を課金監視層３０４のフック直後に戻す。ステップＳ５０７は、呼び出された機能本体の処理である。本体処理は、たとえは楽譜ダウンロードであれば、楽譜サーバ１０２から選択された楽譜データをダウンロードし、ハードディスク等に保存する。またたとえば楽譜の印刷であれば、楽譜データをレンダリングしてＡ３サイズの用紙に印刷する。

本来の処理を実行した後、その処理が成功したかどうかがエラーコードして戻ってくる。課金監視層３０４は、そのエラーコードを監視して判定する（Ｓ５０８）。もし成功であれば、その処理が課金対象である（すなわち当該機能が課金情報テーブル２００に登録されており、かつ、課金フラグがオンである）か判定する（Ｓ５０９）。課金対象で有れば、課金ライブラリ３０３を介して、コインロボに投入されている貨幣のうち、料金分だけ金庫に引き落とさせる。もし、不成功であれば料金の引き落としはせず、課金ライブラリ３０３にエラーメッセージを操作パネルに表示させる。

以上が本実施形態における楽譜のダウンロードサービスにおける処理手順、とくに課金手順である。ユーザが本サービスを受けるときには、楽譜ダウンロード時と楽譜印刷時それぞれにおいて支払請求画面が表示され、それぞれの請求に対して貨幣の投入が必要である。そして要求された金額が投入されれば、機能を実行して、機能の完了時に投入された金額を収受する。

そしてこの構成により、新たに追加したライブラリやアプリケーションがあれば、そこで呼び出される機能を課金情報テーブル２００に登録しておくことができる。こうすることで、その機能をフックし、その機能が課金対象であるか否か判定し、課金対象であればユーザに料金を請求することができる。すなわち、ライブラリやアプリケーションの追加に対してその課金処理を柔軟に追加できる。もちろん、既存の機能について、課金したり、課金を取りやめたり、あるいは単価を変更することも容易である。

また、サービスに対する課金を、画像形成装置の利用の都度、回収して公衆による利用に適した複写機等の画像形成装置を提供することができる。

［第２実施形態］
続いて第２実施形態複合機について、図８乃至図１０及び図１２乃至図１４を参照して説明する。なお複合機の構成や、ネットワークの構成については第１実施形態と同様である。図８は、本実施例のソフトウェア構成と処理順序を表すコラボレーション図である。

ユーザが楽譜印刷アプリケーションを開始し、印刷しようとする楽譜を選択すると、まず楽譜印刷枚数取得処理部３０２ｃを呼び出す。この機能は、たとえば楽譜サーバ１００に楽譜データと共に保存されている枚数のデータをネットワークを介して取得する機能である。この機能により印刷枚数を確定し、料金の計算に用いる。次に将来楽譜をダウンロードすることを宣言（あるいは予約）するダウンロード宣言処理部３０２ａを呼び出す。この宣言処理部３０２ａは課金ライブラリ８０２に属している。次に、実行を宣言されたダウンロード機能の機能名と、その宣言処理部３０２ａを呼び出したアプリケーション８０１に固有のプロセスＩＤと、宣言された機能の課金情報（料金とメッセージ）とを関連付けて宣言記憶テーブル９００に記憶する （図９） 。宣言記憶テーブル９００は宣言記憶テーブル管理部８０２ｄにより管理されている。引き続きアプリケーションは同様に印刷宣言をする。このときパラメータとして楽譜印刷枚数取得処理部３０２ｃにより取得した印刷枚数を印刷宣言処理部３０２ｂに渡す。印刷宣言処理部３０２ｂは、印刷枚数に応じた料金を、実行を宣言された印刷機能の機能名と、その宣言処理部３０２ｂを呼び出したアプリケーション８０１に固有のプロセスＩＤとを関連づけて宣言記憶テーブル９００に保存する。

楽譜印刷アプリケーション８０１は、２つの処理（ダウンロードと印刷）が課金対象処理のすべてであり、その２つとも宣言し終えたので、ここで合算課金処理を呼び出す。楽譜印刷アプリケーション８０１は、たとえば一定の機能については固定的に宣言処理を実行する。あるいは、課金情報テーブル２００を参照して課金対象の機能を判別し、課金対象機能について宣言処理を実行する。そのためには、たとえば宣言処理部の手順は共通化し、宣言される機能名をパラメータとして宣言処理部に渡す方法などが採用し得る。

合算課金処理部８０２ｃは、宣言記憶テーブル９００から合算課金処理８０２ｃを呼び出したアプリケーションのプロセスＩＤに該当する宣言に含まれる料金をすべて抽出する。そして、抽出したそれらの料金を合計して総料金を計算する。また該当する宣言のメッセージを連結して新たなメッセージを生成する。そして、総料金と合成した新メッセージを用いて支払請求画面を表示する（図１０）。図１０において、メッセージ１００１は、合成された新メッセージである。金額１００２は総料金である。利用者はＯＫボタン１００３またはキャンセルボタン１００４を押下して、このダイアログに応答する。

そしてその請求金額をユーザが投入し終わると、それを検出した合算処理部８０２ｅは、宣言記憶テーブル９００の支払完了フラグのカラムに支払い済みであることをマークする。以上で合算課金処理が終了し、楽譜印刷アプリケーション８０１本体に制御が戻る。

楽譜印刷アプリケーション８０１は、ネットワークラインブラリ３０２ａを呼び出して楽譜ダウンロードを行う。ダウンロード機能は課金監視層３０４でフックされる。第１実施形態と異なり、ここではフック後、課金ライブラリ８０２の宣言記憶テーブル管理部８０２ｄに処理が引き次がれる。宣言記憶テーブル管理部８０２ｄは、現在処理しようとしている楽譜ダウンロード機能について、支払いが完了しているか確認する。確認のために、宣言記憶テーブルのプロセスＩＤと宣言された機能名とを参照し、そのダウンロード機能を呼び出すアプリケーションのプロセスＩＤおよび呼び出されている機能名と一致する行を検索する。一致するものがあれば、その欄の支払い完了フラグを参照し、「完了」であるか判定する。完了していれば、宣言が登録されている行をテーブルから削除して、楽譜ダウンロード処理を実行する。もし該当する行がないか、あるいはあっても支払いが完了していない場合は、宣言あるいは合算課金はされていない。その場合には、第１実施形態の手順と同様に、楽譜ダウンロード機能の課金処理を課金ライブラリ８０２によって実行する。課金処理が完了してから楽譜ダウンロード機能を実行する。

次に印刷機能も上記ダウンロード機能と同様である。異なるのは、支払いの有無に加えて、宣言時に渡された印刷枚数パラメータと実際の機能呼び出しで処理しようとしている印刷枚数パラメータとが合致していることも判定する点である。

図９に宣言記憶テーブル９００の一例を示す。宣言記憶テーブル９００には、プロセスＩＤ９０１，宣言した処理（第１実施形態の機能に相当する）９０２、料金９０３、メッセージ９０４、支払い完了フラグ９０５を有する。プロセスＩＤは、宣言を行ったアプリケーションのプロセスＩＤであり、固有の値である。複数の同一アプリケーションが平行して実行される場合を考えれば、同一アプリケーションであっても、実行されている場合には相異なるプロセスＩＤが動的に与えられるのが望ましい。宣言した処理９０２には、課金情報テーブル２００の機能名と共通する識別名が格納される。料金９０３およびメッセージ９０４は、課金情報テーブル２００から読み出された、該当する機能に対応する料金及びメッセージが保存される。支払い完了フラグ９０５は上述の通りである。

図１１は本実施形態の課金監視層３０４による、ライブラリから機能呼出しのフック処理の手順を示すフローチャートである。図１１の手順は、実際に機能が呼び出されたときの処理で、宣言処理により宣言記憶テーブル９００は、上述の宣言処理により作成されている。すなわち、宣言処理部８０２ｂ等は、実行しようとする機能名と、単価の係数となる数量（例えば枚数等）とアプリケーションのプロセスＩＤとをアプリケーションプログラムからパラメータとして受け取る。そして、宣言処理部は、宣言記憶テーブルにプログラムＩＤと、機能名と、料金と、メッセージとを対応付けて保存する。その際、料金とメッセージとについては、アプリケーションが課金情報テーブル２００を参照してパラメータとして渡せば良い。しかし本例では宣言処理部が課金情報テーブル２００を参照して、アプリケーションから渡された機能名に対応するメッセージと単価とを読み出す。そして料金は、パラメータとして渡された数量に単価を乗じて算出する。これらが宣言記憶テーブルに登録される。

さて、図１１においては、まず宣言記憶テーブル９００を走査して、実行対象の機能を呼び出したアプリケーションのプロセスＩＤを検索する（Ｓ１１０１）。あればそのプロセスＩＤと機能名とを課金ライブラリに渡し、ステップＳ１１０２〜Ｓ１１０４を実行させる。課金ライブラリ８０２は渡されたプロセスＩＤおよび機能名を含む行宣言記憶テーブル９００に含まれているか判定する（Ｓ１１０２）。あればその行の支払い完了フラグをテストする（Ｓ１１０３）。支払い完了フラグがオンであれば、その行を宣言記憶テーブル９００から削除する（Ｓ１１０４）。そして処理を機能のフック直後に戻し、呼び出された機能を実行させる（Ｓ１１０５）。処理が成功したか判定し（Ｓ１１０６）、成功したなら課金ライブラリ８０２によりコインロボから料金を引き落とさせて、残額を返却させる（Ｓ１１０７）。

一方ステップＳ１１０３において支払い完了フラグがオフであると判定された場合、支払いが行われていないと判定される。したがって該当する行を宣言記憶テーブルから削除する。その後、課金ライブラリ８０２による処理を終了して、図５のステップＳ５０１に分岐する。なお、一部の金額がコインロボに投入された可能性もあるので、この場合にはコインロボに投入された金額を全額返却させる制御を行っても良い。これにより第１実施形態の課金処理を同じ手順で課金処理が実行される。ステップＳ１１０２において該当する行がないと判定された場合、すなわち宣言が行われていないと判定された場合も同様に図５のステップＳ５０１に分岐する。

図１２は合算処理部８０２ｃによる処理手順を示す。合算処理部８０２ｃが呼び出されると、まず宣言記憶テーブル９００より、合算処理部８０２ｃを呼び出したアプリケーションのプロセスＩＤに対応する料金欄の合計値を算出する（Ｓ１２０１）。次に宣言記憶テーブル９００より、合算処理部８０２ｃを呼び出したアプリケーションのプロセスＩＤに対応するメッセージを読み出して合成する（Ｓ１２０２）。そしてステップＳ１２０１で算出した総料金と、ステップＳ１２０２で合成したメッセージとを用いて、図１０に示すような支払い請求画面を表示する（Ｓ１２０３）。その後コインロボの投入金額を読み出し（Ｓ１２０４）、必要金額以上の金額が投入されたか判定する（Ｓ１２０５）。必要以上の金額が投入されたと判定したなら、合算処理部８０２ｃを呼び出したアプリケーションのプロセスＩＤに対応するすべての機能の支払い完了フラグを「支払い完了」にセットする（Ｓ１２０６）。

以上の手順により、複数の有償の機能を用いるサービス（アプリケーション）に対して、それら機能それぞれに課金される金額の合計額を、一括して利用者に請求できる。このため、複写に限らず新規な機能に対する課金をサービスごとに一括して行える。さらに課金金額をひとつのサービスを提供する都度回収でき、公衆による利用に適した複写機等の画像形成装置を提供できる。また、提供される機能に共通する課金のしくみを持つプラットフォームを提供することで、新規機能の追加に対しても課金処理に伴うアプリケーション開発の負担の増加を防止できる。

［第３の実施形態］
第１実施形態および第２実施形態では、課金情報テーブル２００がネットワークサーバ上にある場合を考えた。第１および第２実施形態では、課金情報テーブル２００は課金サーバ１００から読み出されて参照されたとはいえ、管理は課金サーバにより一元的に行われていた。しかし店舗毎に導入するアプリケーションを変えて差別化するような場合には、複合機に内蔵されたＨＤＤ上に課金情報テーブル２００を置き、これを店舗毎に管理することが望ましい。この場合、管理者のみが操作できる課金情報テーブル管理サービスという常駐のシステムサービスを準備し、このサービスのＵＩ画面（図１３）によって、課金体系を変更するなどの操作をする。

図１４は、課金情報テーブル管理サービスによる処理手順の一例である。ステップＳ１４０１において、既存の課金情報テーブルが複合機の記憶部、たとえばＨＤＤに保存されているか判定する。既存のものがあれば、その課金情報テーブルを読み、その内容に従って設定画面（図１３）を表示する（Ｓ１４０２）。表示されるのは、課金フラグ２０２，機能名２０１，料金２０３であり、それぞれ課金フラグ欄１３０１、機能名欄１３０２、料金ライ１３０３に表示される。この画面上で管理者は設定内容を変更するための操作を行える（Ｓ１４０３）。なおメッセージも設定可能とすることもできるが、本例ではメッセージは固定している。図１３では、管理者が変更できる項目は課金フラグと料金に限られるが、たとえば機能名を追加あるいは削除させることもできる。

ＯＫボタン１３０４が押されると、それに応じて入力された値を課金情報テーブル９００に書き戻す（Ｓ１４０４）。

一方ステップＳ１４０１で既存のテーブルが無いと判定された場合ステップＳ１４０５へ分岐する。ステップＳ１４０５においては、課金情報テーブルのデフォルト値が登録されたテンプレートを図１３のように表示し（Ｓ１４０５）、ステップＳ１４０３へ分岐する。

以上の手順により、管理者は課金情報テーブルを変更することができる。そして料金や課金の有無に加えて、メッセージや新たな機能の追加や削除も行うことができる。これにより、課金処理の料金や課金対象の変更をより柔軟に行うことができる。

図１７は、プラットフォームプログラム及び楽譜印刷アプリケーションによる処理のフローチャートである。サービスの実行処理の流れである。複合機の操作パネル１１２に、サービスするアプリケーションのリストが表示されている状態を考える。まず、サービスするアプリケーションを、ユーザの操作パネル１１２の選択指示に基づき、指示手段の一例である図３のアプリケーションプラットフォームプログラムが、選択する。本実施形態では、図３のプラットフォームプログラムの上に載っているサービス提供アプリケーションを複合機の操作パネル１１２を用いてユーザが選択すると処理が開始する。ここでは楽譜印刷アプリケーションが選択されたことをプラットフォームプログラムが認識したとする（Ｓ１７０１）。すると、Ｓ１７０２へ進み、処理が楽譜アプリケーションに移る。楽譜アプリケーション３０１は、Ｓ１７０２で、楽譜印刷アプリケーション３０１の楽譜印刷機能の操作パネル１１２の実行ボタンがユーザによって押されたことを、楽譜印刷アプリケーション３０１が認識すると、Ｓ１７０３へ進む。Ｓ１７０３では、楽譜印刷アプリケーションは、課金ライブラリを起動するよう課金ライブラリ２００を制御する。例えば、楽譜印刷アプリケーション３０１が所定のライブラリをコールするのに、課金ライブラリ２００が、課金処理を図５の処理を開始するようにしてもよい。

なお本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。また本発明の目的は、前述の実施形態の機能を実現するプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータが記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体およびプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、本発明には、プログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた場合についても、本発明は適用される。その場合、書き込まれたプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

楽譜印刷サービスのネットワーク構成図 課金情報サーバ上の課金情報テーブルの一例を示す図 複合機上のソフトウェア構成図 楽譜印刷サービスのための複合機のソフトウエア構成概要図 第１実施形態の課金対象機能呼び出し時の課金処理フローチャート 楽譜ダウンロード料金の支払請求画面の一例を示す図 楽譜印刷料金の支払請求画面の一例を示す図 第２実施形態のソフトウエア構成を示す図 宣言記憶テーブルの一例を示す図 合算支払請求画面の一例を示す図 第２実施形態の課金対象機能呼び出し時の課金処理フローチャート 第２実施形態の合算処理フローチャート 課金情報テーブル管理画面 課金情報テーブル変更処理フローチャート 複合機上のハードウエア構成図 複合機上の外観図 プラットフォームプログラム及び楽譜印刷アプリケーションによる処理のフローチャート

符号の説明

１００コンビニエンスストア本部の課金情報サーバ
１０１各コンビニエンスストア店舗の複合機
１０２楽譜サーバ
１０３ネットワーク

Claims (18)

1. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させることが可能な画像形成装置であって、
   アプリケーションプログラムで実行される機能のうち、有償機能を判別する有償機能判別手段と、
   前記有償機能判別手段により判別された有償機能について、課金が実行できることを判定する課金判定手段とを備え、
   前記課金判定手段により課金が実行できると判定された場合、前記有償機能を実行させることを特徴とする画像形成装置。
2. 利用したいアプリケーションを指示する指示手段をさらに備え、
   前記指示手段が指示したアプリケーションで実行される機能のうち、前記有償機能を前記有償機能判別手段は判別することを特徴とする請求項１に記載の画像形成装置。
3. 課金対象の有償機能を識別するための課金テーブルをさらに備え、有償機能判別手段は、前記課金テーブルを参照して、前記アプリケーションプログラムで実行される機能のうち、前記有償機能を判別することを特徴とする請求項１に記載の画像形成装置。
4. 前記アプリケーションプログラムで実行される有償機能に課金される合計金額を計算する合算手段と、
   前記アプリケーションプログラムにより有償機能が実行される場合、前記合算手段により計算された合計金額が課金が実行できることを判定する課金判定手段とを備え、
   前記課金判定手段により課金できると判定された場合、前記有償機能を実行させることを特徴とする請求項１に記載の画像形成装置。
5. 課金対象の有償機能を識別するための課金テーブルをさらに備え、
   前記合算手段は、前記アプリケーションプログラムから発行される、利用する機能の宣言メッセージに応じて、前記課金テーブルを参照して、前記アプリケーションプログラムで実行される有償機能に課金される合計金額を計算することを特徴とする請求項４に記載の画像形成装置。
6. 前記有償機能判別手段は、ネットワークを介して外部情報処理装置から取得した有償機能情報に基づき、前記有償機能を判別する請求項１乃至５のいずれかに記載の情報処理装置。
7. 前記有償機能の課金の設定をする設定手段をさらに備え、
   前記設定手段が設定する設定内容に従って、前記課金テーブルを変更する変更手段をさらに備える請求項３に記載の情報処理装置。
8. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置であって、
   前記アプリケーションプラットフォームは、
   課金対象の有償機能を識別するための課金テーブルと、
   前記課金テーブルを参照して有償機能の実行を監視する課金監視手段と、
   前記課金監視手段により有償機能の実行が見出された場合、該有償機能に対応する金額を表示し、その課金が実行できるかを判定する課金ライブラリとを備え、
   前記課金が実行できる場合は前記有償機能の実行を許すことを特徴とする画像形成装置。
9. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置であって、
   前記アプリケーションプラットフォームは、
   課金対象の有償機能を識別するための課金テーブルと、
   前記アプリケーションプログラムによる、前記有償機能の呼び出しの宣言に応じて、宣言された機能およびその課金金額を記憶する宣言記憶手段と、
   前記アプリケーションプログラムによる合算メッセージに応じて、前記宣言記憶手段により記憶した有償機能に対応する金額を表示し、その課金がされた場合には、その旨記憶する支払記憶手段と、
   前記アプリケーションプログラムにより前記有償機能が実行される場合、当該アプリケーションプログラムに対応して課金がされているか否かを判定する判定手段とを備え、
   課金がされていると判定された場合には、前記有償機能の実行を許すことを特徴とする画像形成装置。
10. 前記課金テーブルの内容を変更するための手段をさらに備えることを特徴とする請求項３又は８又は９のに記載の画像形成装置。
11. ネットワークに接続するための接続手段をさらに備え、前記課金テーブルは、前記ネットワークに接続された他の機器から取得することを特徴とする請求項３又は８又は９のいずれか１項に記載の画像形成装置。
12. コンピュータを、請求項１乃至１１のいずれか１項に記載の画像形成装置として機能させるためのプログラム。
13. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させることが可能な画像形成装置の制御方法であって、
    アプリケーションプログラムで実行される機能のうち、有償機能を判別する有償機能判別工程と、
    前記有償機能判別工程により判別された有償機能について、課金が実行できることを判定する課金判定工程とを備え、
    前記課金判定工程により課金が実行できると判定された場合、前記有償機能を実行させることを特徴とする画像形成装置の制御方法。
14. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置の制御方法であって、
    前記アプリケーションプラットフォームは、課金対象の有償機能を識別するための課金テーブルを有し、
    前記方法は、前記課金テーブルを参照して有償機能の実行を監視する課金監視工程と、
    前記課金監視工程により有償機能の実行が見出された場合、該有償機能に対応する金額を表示し、その課金が実行できるかを判定する課金工程とを備え、
    前記課金が実行できる場合は前記有償機能の実行を許すことを特徴とする画像形成装置の制御方法。
15. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームを有する画像形成装置の制御方法であって、
    前記アプリケーションプラットフォームは、課金対象の有償機能を識別するための課金テーブルを備え、
    前記方法は、前記アプリケーションプログラムによる、前記有償機能の呼び出しの宣言に応じて、宣言された機能およびその課金金額を記憶する宣言記憶工程と、
    前記アプリケーションプログラムによる合算メッセージに応じて、前記宣言記憶工程により記憶した有償機能に対応する金額を表示し、その課金がされた場合には、その旨記憶する支払記憶工程と、
    前記アプリケーションプログラムにより前記有償機能が実行される場合、当該アプリケーションプログラムに対応して課金がされているか否かを判定する判定工程とを備え、
    課金がされていると判定された場合には、前記有償機能の実行を許すことを特徴とする画像形成装置の制御方法。
16. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させることが可能なコンピュータにより実行できるプログラムであって、
    アプリケーションプログラムで実行される機能のうち、有償機能を判別する有償機能判別手段と、
    前記有償機能判別手段により判別された有償機能について、課金が実行できることを判定する課金判定手段としてコンピュータを機能させ、
    前記課金判定手段により課金が実行できると判定された場合、前記有償機能を実行させることを特徴とするプログラム。
17. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームプログラムであって、
    課金対象の有償機能を識別するための課金テーブルと、
    前記課金テーブルを参照して有償機能の実行を監視する課金監視手段と、
    前記課金監視手段により有償機能の実行が見出された場合、該有償機能に対応する金額を表示し、その課金が実行できるかを判定する課金ライブラリとしてコンピュータを機能させ、
    前記課金が実行できる場合は前記有償機能の実行を許すことを特徴とするプログラム。
18. 利用する機能に応じて利用者に対して課金するアプリケーションプログラムを動作させるためのアプリケーションプラットフォームプログラムであって、
    課金対象の有償機能を識別するための課金テーブルと、
    前記アプリケーションプログラムによる、前記有償機能の呼び出しの宣言に応じて、宣言された機能およびその課金金額を記憶する宣言記憶手段と、
    前記アプリケーションプログラムによる合算メッセージに応じて、前記宣言記憶手段により記憶した有償機能に対応する金額を表示し、その課金がされた場合には、その旨記憶する支払記憶手段と、
    前記アプリケーションプログラムにより前記有償機能が実行される場合、当該アプリケーションプログラムに対応して課金がされているか否かを判定する判定手段としてコンピュータを機能させ、
    課金がされていると判定された場合には、前記有償機能の実行を許すことを特徴とするプログラム。

Images