(57)【要約】【課題】複数の課金装置を用いた課金処理を効率よく実現すること。【解決手段】課金装置と一対一に対応し、かかる課金装置に課金実行を指示する課金実行手順と、１または複数の課金実行手順を選択し、選択した課金実行手順に課金実行を依頼する対価手順とをコンピュータに実行させる。また、オブジェクト指向設計により、加算式課金装置および減算式課金装置に対応したオブジェクトモデリングをおこない、帳簿クラス、伝票クラス、料金表クラス、対価クラス、取引表クラス、投入金額クラス、請求金額クラスおよび請求先クラスのオブジェクトによる協調関係により課金処理を実現する。【選択図】        図９
2006085477.tif 000002
【特許請求の範囲】
【請求項１】
利用者の要求に応じサービスを提供するサービス提供装置または前記サービス提供装置と通信可能な課金管理装置に搭載され、利用者により前記サービス提供装置に要求されたサービスのサービス料金を算出し、該サービス料金の課金実行を課金装置に指示する課金管理プログラムであって、
課金装置と一対一に対応し、該課金装置に課金実行を指示する課金実行手段と、
１または複数の前記課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段と
してコンピュータを機能させることを特徴とする課金管理プログラム。
【請求項２】
前記課金実行手段は、減算式課金装置と一対一に対応する減算式課金手段と、加算式課金装置と一対一に対応する加算式課金手段とをさらに備えたことを特徴とする請求項１に記載の課金管理プログラム。
【請求項３】
前記課金実行手段は、すべての前記加算式課金手段を管理する管理手段をさらに備え、該管理手段は、１つの加算式課金手段を選択して課金実行を指示し、選択した加算式課金手段が課金実行を継続できない場合には、他の加算式課金手段を選択して課金実行を継続させることを特徴とする請求項１または２に記載の課金管理プログラム。
【請求項４】
前記管理手段は、合計額および限度額を保持し、課金要求を受け付けたならば該課金要求に含まれる課金額を合計額に加算し、所定の条件を満たした場合に前記加算式課金手段に対し課金実行を指示することを特徴とする請求項３に記載の課金管理プログラム。
【請求項５】
前記対価手段は、前記減算式課金手段および前記管理手段を木構造の子として管理し、前記管理手段は、前記加算式課金手段を木構造の子として管理することを特徴とする請求項３または４に記載の課金管理プログラム。
【請求項６】
利用可能な課金装置の一覧を保持する取引表手段をさらに備え、前記対価手段は、該取引表手段の検索結果に基づいて前記減算式課金手段または前記加算式課金手段を選択することを特徴とする請求項５に記載の課金管理プログラム。
【請求項７】
前記減算式課金手段は、対応する減算式課金装置が課金不能状態となったならば、前記対価手段に対し課金先の変更を依頼することを特徴とする請求項５または６に記載の課金管理プログラム。
【請求項８】
前記請求先手段は、対応する加算式課金装置が課金不能状態となったならば、前記請求金額手段に対し課金先の変更を依頼し、該請求金額手段は、前記対価手段に対し課金先の変更を依頼することを特徴とする請求項５、６または７に記載の課金管理プログラム。
【請求項９】
前記減算式課金手段は、前記対価手段から選択されたならば、自己が保持する減算式課金装置の残高に基づいて課金実行の可否を判定し、判定結果を該対価手段に応答することを特徴とする請求項５〜８のいずれか一つに記載の課金管理プログラム。
【請求項１０】
前記サービス提供装置の制御プログラムからサービス要求内容を含むサービス要求通知を受信する帳簿手段と、該サービス要求通知ごとに該帳簿手段により生成される伝票手段とをさらに備え、
前記伝票手段は、前記対価手段を生成して該対価手段に課金処理を依頼することを特徴とする請求項５〜９のいずれか一つに記載の課金管理プログラム。
【請求項１１】
提供するサービスの料金一覧を保持し、前記伝票手段の求めに応じ該当するサービス料金を検索して該料金を応答する料金表手段をさらに備えたことを特徴とする請求項１０に記載の課金管理プログラム。
【請求項１２】
前記伝票手段は、前記サービス料金が無料である場合には、前記対価手段を生成しないことを特徴とする請求項１１に記載の課金管理プログラム。
【請求項１３】
利用者により要求されたサービスのサービス料金を算出し、該サービス料金の課金実行を課金装置に指示する画像形成装置であって、
前記課金装置と一対一に対応し、該課金装置に課金実行を指示する課金実行手段と、
１または複数の前記課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段と
を備えたことを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者の要求に応じサービスを提供するサービス提供装置またはサービス提供装置と通信可能な課金管理装置に搭載され、利用者によりサービス提供装置に要求されたサービスのサービス料金を算出する課金管理プログラムおよび画像形成装置に関するものである。
【背景技術】
【０００２】
従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（Ｒ）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。
【０００３】
ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、それぞれエンジン制御、メモリ制御およびシステム制御などを別個におこなっているので、重複処理という無駄が生じていた。
【０００４】
このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。
【０００５】
また、特許文献２では、ファックス機能を使用した際に発生する通信回線使用料金をテーブルデータとして記憶し、ファックス機能の提供にともなって発生するプリンタ機能の提供料金と、かかる通信回線使用料金とを加算することで、ファックス機能を提供する際の課金をおこなうこととしている。
【０００６】
【特許文献１】特開２００２−０８４３８３号公報
【特許文献２】特開平１０−０２３１８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、この特許文献１で開示されている発明は、ハードウェアを制御する処理部分を共通化するものであり、各アプリケーションの内部処理全般を共通化するものではない。このため、複合機上のアプリケーションには、開発効率の向上を図るうえで改善の余地が残されている。
【０００８】
たとえば、オペレーションパネル制御ソフトウェアやネットワーク制御ソフトウェアを介して、コピーサービスなどの機能提供要求を受け付け、提供する機能に応じた課金をおこなう課金処理は、複写機上の各アプリケーションに共通して存在する処理であるが、ハードウェアを直接制御する処理ではないため各アプリケーションで別個に実現されており、共通化することが可能である。
【０００９】
また、特許文献２で開示されている発明は、複合機上の複数の機能を組み合わせたサービスについての課金処理に関するものであり、複数の課金処理を並行しておこなうことを考慮したものではない。したがって、複合機が複数のサービス要求を受け付け、各サービス要求に対する課金処理をおこなう場合には、各課金処理を正確に管理することが困難となり、課金処理が正しくおこなわれず、二重課金や未課金といった課金ミスが発生する可能性が高くなるおそれがある。特に、コインラック装置やキーカード装置といった複数の課金装置の利用が可能な環境においては、かかる課金ミスが発生する可能性はさらに高くなる。
【００１０】
これらのことから、複合機に搭載されるアプリケーションの課金処理をいかにして効率よく、かつ、高い信頼性をもって実現するかが大きな課題となっている。なお、かかる課題は複合機についてのみ生じるものではなく、たとえば、有料サービスに対する課金をおこなう課金管理装置を形成するような場合にも同様に生ずる課題である。
【００１１】
本発明は、上述した従来技術による問題点を解消するためになされたものであり、課金処理を効率よく実現することができる課金管理プログラムおよび画像形成装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するために、請求項１の発明にかかる課金管理プログラムは、利用者の要求に応じサービスを提供するサービス提供装置または前記サービス提供装置と通信可能な課金管理装置に搭載され、利用者により前記サービス提供装置に要求されたサービスのサービス料金を算出し、該サービス料金の課金実行を課金装置に指示する課金管理プログラムであって、課金装置と一対一に対応し、該課金装置に課金実行を指示する課金実行手段と、１または複数の前記課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段としてコンピュータを機能させることを特徴とする。
【００１３】
また、請求項２の発明にかかる課金管理プログラムは、請求項１の発明において、前記課金実行手段は、減算式課金装置と一対一に対応する減算式課金手段と、加算式課金装置と一対一に対応する加算式課金手段とをさらに備えたことを特徴とする。
【００１４】
また、請求項３の発明にかかる課金管理プログラムは、請求項１または２の発明において、前記課金実行手段は、すべての前記加算式課金手段を管理する管理手段をさらに備え、該管理手段は、１つの加算式課金手段を選択して課金実行を指示し、選択した加算式課金手段が課金実行を継続できない場合には、他の加算式課金手段を選択して課金実行を継続させることを特徴とする。
【００１５】
また、請求項４の発明にかかる課金管理プログラムは、請求項３の発明において、前記管理手段は、合計額および限度額を保持し、課金要求を受け付けたならば該課金要求に含まれる課金額を合計額に加算し、所定の条件を満たした場合に前記加算式課金手段に対し課金実行を指示することを特徴とする。
【００１６】
また、請求項５の発明にかかる課金管理プログラムは、請求項３または４の発明において、前記対価手段は、前記減算式課金手段および前記管理手段を木構造の子として管理し、前記管理手段は、前記加算式課金手段を木構造の子として管理することを特徴とする。
【００１７】
また、請求項６の発明にかかる課金管理プログラムは、請求項５の発明において、利用可能な課金装置の一覧を保持する取引表手段をさらに備え、前記対価手段は、該取引表手段の検索結果に基づいて前記減算式課金手段または前記加算式課金手段を選択することを特徴とする。
【００１８】
また、請求項７の発明にかかる課金管理プログラムは、請求項５または６の発明において、前記減算式課金手段は、対応する減算式課金装置が課金不能状態となったならば、前記対価手段に対し課金先の変更を依頼することを特徴とする。
【００１９】
また、請求項８の発明にかかる課金管理プログラムは、請求項５、６または７の発明において、前記請求先手段は、対応する加算式課金装置が課金不能状態となったならば、前記請求金額手段に対し課金先の変更を依頼し、該請求金額手段は、前記対価手段に対し課金先の変更を依頼することを特徴とする。
【００２０】
また、請求項９の発明にかかる課金管理プログラムは、請求項５〜８の発明において、前記減算式課金手段は、前記対価手段から選択されたならば、自己が保持する減算式課金装置の残高に基づいて課金実行の可否を判定し、判定結果を該対価手段に応答することを特徴とする。
【００２１】
また、請求項１０の発明にかかる課金管理プログラムは、請求項５〜９の発明において、前記サービス提供装置の制御プログラムからサービス要求内容を含むサービス要求通知を受信する帳簿手段と、該サービス要求通知ごとに該帳簿手段により生成される伝票手段とをさらに備え、前記伝票手段は、前記対価手段を生成して該対価手段に課金処理を依頼することを特徴とする。
【００２２】
また、請求項１１の発明にかかる課金管理プログラムは、請求項１０の発明において、提供するサービスの料金一覧を保持し、前記伝票手段の求めに応じ該当するサービス料金を検索して該料金を応答する料金表手段をさらに備えたことを特徴とする。
【００２３】
また、請求項１２の発明にかかる課金管理プログラムは、請求項１１の発明において、前記伝票手段は、前記サービス料金が無料である場合には、前記対価手段を生成しないことを特徴とする。
【００２４】
また、請求項１３の発明にかかる画像形成装置は、利用者により要求されたサービスのサービス料金を算出し、該サービス料金の課金実行を課金装置に指示する画像形成装置であって、前記課金装置と一対一に対応し、該課金装置に課金実行を指示する課金実行手段と、１または複数の前記課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段とを備えたことを特徴とする。
【発明の効果】
【００２５】
請求項１にかかる課金管理プログラムによれば、課金装置と一対一に対応し、課金装置に課金実行を指示する課金実行手段と、１または複数の課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段としてコンピュータを機能させるよう構成したので、ソフトウェア開発者やソフトウェア保守要員が、課金部の構成と役割を容易に把握することがでるとともに、複数の課金装置を用いた場合や、サービス要求を並行処理する場合であっても課金状態を正確に管理できるので、課金処理を効率よく実現することができるという効果を奏する。
【００２６】
また、請求項２にかかる課金管理プログラムによれば、課金実行手段は、減算式課金装置と一対一に対応する減算式課金手段と、加算式課金装置と一対一に対応する加算式課金手段とをさらに備えるよう構成したので、加算式課金装置および減算式課金装置に固有の機能の差異を吸収して効率的な課金処理をおこなうことができるという効果を奏する。
【００２７】
また、請求項３にかかる課金管理プログラムによれば、課金実行手段は、すべての加算式課金手段を管理する管理手段をさらに備え、管理手段は、１つの加算式課金手段を選択して課金実行を指示し、選択した加算式課金手段が課金実行を継続できない場合には、他の加算式課金手段を選択して課金実行を継続させるよう構成したので、課金装置を体系的に管理することができ、効率的な課金処理をおこなうことができるという効果を奏する。
【００２８】
また、請求項４にかかる課金管理プログラムによれば、管理手段は、合計額および限度額を保持し、課金要求を受け付けたならば課金要求に含まれる課金額を合計額に加算し、所定の条件を満たした場合に加算式課金手段に対し課金実行を指示するよう構成したので、課金装置への課金指示の頻度を減少させ効率的な課金処理をおこなうことができるという効果を奏する。
【００２９】
また、請求項５にかかる課金管理プログラムによれば、対価手段は、減算式課金手段および管理手段を木構造の子として管理し、管理手段は、加算式課金手段を木構造の子として管理するよう構成したので、ソフトウェア開発者やソフトウェア保守要員が、課金部の構成と役割を容易に把握することがでるとともに、効率的な課金処理をおこなうことができるという効果を奏する。
【００３０】
また、請求項６にかかる課金管理プログラムによれば、利用可能な課金装置の一覧を保持する取引表手段をさらに備え、対価手段は、取引表手段の検索結果に基づいて減算式課金手段または加算式課金手段を選択するよう構成したので、ソフトウェア開発者やソフトウェア保守要員が、課金部の構成と役割を容易に把握することがでるとともに、課金装置の追加や取外しを容易におこなうことができるという効果を奏する。
【００３１】
また、請求項７にかかる課金管理プログラムによれば、減算式課金手段は、対応する減算式課金装置が課金不能状態となったならば、対価手段に対し課金先の変更を依頼するよう構成したので、課金装置の状態に応じて課金装置を切替えることにより効率的な課金処理をおこなうことができるという効果を奏する。
【００３２】
また、請求項８にかかる課金管理プログラムによれば、請求先手段は、対応する加算式課金装置が課金不能状態となったならば、請求金額手段に対し課金先の変更を依頼し、請求金額手段は、対価手段に対し課金先の変更を依頼するよう構成したので、体系的に管理する課金装置の状態に応じて課金装置を切替えることにより、効率的な課金処理をおこなうことができるという効果を奏する。
【００３３】
また、請求項９にかかる課金管理プログラムによれば、減算式課金手段は、対価手段から選択されたならば、自己が保持する減算式課金装置の残高に基づいて課金実行の可否を判定し、判定結果を対価手段に応答するよう構成したので、課金処理を確実におこなうことができるという効果を奏する。
【００３４】
また、請求項１０にかかる課金管理プログラムによれば、サービス提供装置の制御プログラムからサービス要求内容を含むサービス要求通知を受信する帳簿手段と、サービス要求通知ごとに帳簿手段により生成される伝票手段とをさらに備え、伝票手段は、対価手段を生成して対価手段に課金処理を依頼するよう構成したので、複数の課金処理を並行しておこなうことができるという効果を奏する。
【００３５】
また、請求項１１にかかる課金管理プログラムによれば、提供するサービスの料金一覧を保持し、伝票手段の求めに応じ該当するサービス料金を検索して料金を応答する料金表手段をさらに備えるよう構成したので、提供するサービスの種別にかかわらずサービス料金の算出をおこなうことができるという効果を奏する。
【００３６】
また、請求項１２にかかる課金管理プログラムによれば、伝票手段は、サービス料金が無料である場合には、対価手段を生成しないよう構成したので、サービス料金が無料である場合であっても効率的な処理をおこなうことができるという効果を奏する。
【００３７】
また、請求項１３にかかる画像形成装置によれば、課金装置と一対一に対応し、課金装置に課金実行を指示する課金実行手段と、１または複数の前記課金実行手段を選択し、選択した課金実行手段に課金実行を依頼する対価手段とを備えるよう構成したので、ソフトウェア開発者やソフトウェア保守要員が、課金部の構成と役割を容易に把握することがでるとともに、複数の課金装置を用いた場合や、サービス要求を並行処理する場合であっても課金状態を正確に管理できるので、課金処理を効率よく実現することができるという効果を奏する。
【発明を実施するための最良の形態】
【００３８】
以下に添付図面を参照して、この発明にかかる課金管理プログラム、およびこのプログラムを実行させるためのコンピュータを含んだ画像形成装置の最良な実施の形態を詳細に説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、課金管理をおこなう各種装置に適用することができる。
【００３９】
まず、本実施の形態に係る画像形成装置（以下「複合機」と言う）１の概要について図１、図２、図３、図１９および図２０を用いて説明する。図１は、本実施の形態に係る複合機１を取り巻くネットワーク環境を説明するためのネットワーク図であり、図２は、図１に示した複合機１のハードウェア構成を示すブロック図であり、図３は、図１に示した複合機１のソフトウェアとハードウェアの関係を説明するための説明図であり、図１９は、複合機１に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図２０は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。
【００４０】
図１に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたパーソナルコンピュータ（ＰＣ）などの機器は、ＬＡＮ（Local Area Network）などのネットワークに接続され、相互に通信することが通常となった。たとえば、同図に示したように、かかるネットワークには、クライアントＰＣ、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、課金サーバ２、サーバＰＣなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。
【００４１】
このようなネットワーク化の進展に伴い、複合機１もかかるネットワークに接続され、ＰＣ等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。
【００４２】
たとえば、複合機１は、通常のコピー機能に加えて、クライアントＰＣからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントＰＣからのファックス要求により文書データ等をサーバＰＣに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有するようになった。
【００４３】
また、複合機１は、課金装置１ａなどの複合機１本体に直接接続される装置を用いて課金処理をおこなうことに加えて、ネットワークを介して接続される課金サーバ２を用いて課金処理をおこなうことができるようになった。ここで、課金装置１ａは、料金徴収用のコインラック装置や、事後的な料金徴収のためにコピー等の使用量を記録するプリセットキーカード装置や、クレジットカード装置といった装置であり、課金サーバ２は、事後的な料金徴収をおこなうために、課金データを管理する装置である。
【００４４】
こうして複合化とネットワーク化の進展により必要となった多くの機能を実現するため、複合機１に搭載されるソフトウェアは、規模が大きく、複雑なものとなっている。そして、それにともなって、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。
【００４５】
図２は、かかる複合機１のハードウェア構成を示すブロック図である。同図に示すように、この複合機１は、コントローラ１０とエンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バスで接続した構成となる。コントローラ１０は、複合機１全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部６０は、ＰＣＩバスに接続可能なプリンタエンジンなどであり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部６０には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。
【００４６】
コントローラ１０は、ＣＰＵ１１と、ノースブリッジ（ＮＢ）１３と、システムメモリ（ＭＥＭ−Ｐ）１２と、サウスブリッジ（ＳＢ）１４と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ハードディスクドライブ（ＨＤＤ）１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）バス１５で接続した構成となる。また、ＭＥＭ−Ｐ１２は、ＲＯＭ（Read Only Memory）１２ａと、ＲＡＭ(Random Access Memory)１２ｂとをさらに有する。
【００４７】
ＣＰＵ１１は、複合機１の全体制御をおこなうものであり、ＮＢ１３、ＭＥＭ−Ｐ１２およびＳＢ１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。
【００４８】
ＮＢ１３は、ＣＰＵ１１とＭＥＭ−Ｐ１２、ＳＢ１４、ＡＧＰ１５とを接続するためのブリッジであり、ＭＥＭ−Ｐ１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。
【００４９】
ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ１２ａとＲＡＭ１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
【００５０】
ＳＢ１４は、ＮＢ１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ１４は、ＰＣＩバスを介してＮＢ１３と接続されており、このＰＣＩバスには、ネットワークインターフェース（Ｉ／Ｆ）部なども接続される。
【００５１】
ＡＳＩＣ１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）であり、ＡＧＰ１５、ＰＣＩバス、ＨＤＤ１８およびＭＥＭ−Ｃ１７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ−Ｃ１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Direct Memory Access Controller）と、エンジン部６０との間でＰＣＩバスを介したデータ転送をおこなうＰＣＩユニットとからなる。このＡＳＩＣ１６には、ＰＣＩバスを介してＦＣＵ（Fax Control Unit）３０、ＵＳＢ（Universal Serial Bus）４０、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０が接続される。
【００５２】
ＭＥＭ−Ｃ１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＨＤＤ（Hard Disk Drive）１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。
【００５３】
ＡＧＰ１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ−Ｐ１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。
【００５４】
図３は、かかる複合機１のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施の形態の特徴部分である課金部１１２ａを含む統合アプリケーション１１０と、ソフトウェア１００およびハードウェア２００の階層関係を示している。同図に示すように、ハードウェア２００は、ハードウェアリソース２０１を有し、このハードウェアリソース２０１は、スキャナ２０１ａ、プロッタ２０１ｂ、ＨＤＤ（Hard Disk Drive）２０１ｃ、ネットワーク２０１ｄおよびその他のリソース２０１ｅを有する。なお、その他のリソース２０１ｅは、２０１ａ〜２０１ｄ以外のハードウェアリソース２０１のことであり、たとえば、操作パネルなどの入出力デバイスを示す。
【００５５】
また、かかるハードウェア２００に搭載されるソフトウェア１００は階層化されており、オペレーティングシステム１０３の上層にはサービス層１０２が構築され、このサービス層１０２の上層にはアプリケーション層１０３が構築されている。そして、サービス層１０２は、各ハードウェアリソース（２０１ａ〜２０１ｅ）を制御するドライバーに相当する、スキャナ制御１０２部ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、配信／メール送受信制御部１０２ｄ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇを有する。
【００５６】
ここで、図３に示したソフトウェア１００が、かかる階層構造をとるに至った経緯について、図１９および図２０を用いて説明する。図１９は、複合機１に搭載されるソフトウェア構成の変遷を示す説明図である。図１９のサービス層分離前アプリケーション５０１に示すように、多機能化した複合機１に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図３に示したオペレーティングシステム１０３上で動作していた。
【００５７】
しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層１０２）を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。
【００５８】
そこで、図１９のサービス層分離後アプリケーション５０２に示すように、サービス層分離前アプリケーション５０１のサービス層１０２相当部分を括りだしサービス層１０２とするとともに、各アプリケーションは、このサービス層１０２の上層であるアプリケーション層１０１に構築する構成とした。かかる階層化構成をとることにより、各アプリケーションはスリム化され開発労力も軽減された。
【００５９】
しかしながら、複合機１のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層１０１の各アプリケーション、たとえば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部１０２ａや蓄積制御部１０２ｃといったドライバーと通信をおこなう処理や、各種機能が提供するサービスの課金管理などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。
【００６０】
この問題を解決するため、図１９の共通ルーチン分離アプリケーション５０３に示すように、かかる同様な処理（共通処理部分）を共通ルーチンとして括りだすことも考えられた。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。
【００６１】
しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。
【００６２】
そこで、図１９のオブジェクト指向アプリケーション５０４に示すように、オブジェクト指向による設計手法（オブジェクトモデリング）により、かかる複数のアプリケーションを、統合アプリケーション１１０に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション１１０を構成する。そして、従来のコピー機能やスキャナ機能といった機能は、かかるオブジェクトモデルの協調関係によって実現する。
【００６３】
このような構成をとることにより、たとえばプリンタ機能のような新規機能の追加は、かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。
【００６４】
図２０は、図１９に示したサービス層分離後アプリケーション５０２の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層１０２の各ドライバーの関係を示した説明図である。同図に示すように、アプリケーション層１０１は、コピーアプリケーション１２０、スキャナアプリケーション１３０、ファックスアプリケーション１４０およびプリンタアプリケーション１５０を有する。
【００６５】
たとえば、コピーアプリケーション１２０は、コピー機能を実現するために、スキャナ制御部１０２ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃおよびその他の制御部１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１４０は、ファックス機能を実現するために、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１の各アプリケーションとサービス層１０２の各ドライバー間の通信は、複雑なものとなっていた。
【００６６】
図３の説明に戻ると、上述したオブジェクトモデリングにより、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションが重複しておこなっていた各ドライバーとの通信処理は、統合アプリケーション１１０を構成する所定のオブジェクトモデルにおこなわせるように構成したことにより、アプリケーション層１０１のアプリケーションと、サービス層１０２の各ドライバー間の通信は、図２０と比較して単純になっている。
【００６７】
次に、統合アプリケーション１１０の内部構成について説明する。図４は、統合アプリケーション１１０の内部構成を示すブロック図である。同図に示すように、統合アプリケーション１１０は、操作系サブシステム１１１と、管理系サブシステム１１２と、実行系サブシステム１１３とを有する。
【００６８】
操作系サブシステム１１１は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム１１１は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。
【００６９】
管理系サブシステム１１２は、画像形成装置１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム１１２は、ハードウェアリソース２０１およびこのハードウェアリソース２０１が保持するデータ状態を管理するサービスをおこなう。
【００７０】
実行系サブシステム１１３は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム１１３は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。
【００７１】
操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション１１０全体として複合機１に必要とされるサービスの提供をおこなう。
【００７２】
そして、管理系サブシステム１１２は、本実施の形態の特徴部分である課金部１１２ａを有する。この課金部１１２ａは、課金処理の受付け、課金額の算出、課金処理実行の指示などの課金管理処理をおこなう。
【００７３】
図５は、図４に示した各サブシステムを、ＵＭＬ（Unified Modeling Language）のクラス図（ＵＭＬクラス図）に置き換えた図である。ここで、ＵＭＬとは、ＯＭＧ（Object Management Group）が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このＵＭＬは、オブジェクト指向によるソフトウェアの設計において広く用いられている。
【００７４】
図５に示すように、統合アプリケーション１１０は複数のパッケージを有し、また、この統合アプリケーション１１０自体もひとつのパッケージとなっている。ここで、パッケージとはＵＭＬモデルの各構成要素（シンボル）をグループ化したものであり、左上にタブのついたフォルダの形をしたシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。
【００７５】
図５に示したように、統合アプリケーション１１０は、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３の３つのパッケージを内部に有するパッケージである。さらに、管理系サブシステム１１２は、課金部１１２ａを内部に有するパッケージである。そして、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３を相互に結ぶ直線は、各パッケージ間に処理依頼（たとえば、メッセージ送受信）などの関連があることを示している。なお、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すＵＭＬのシンボルである。
【００７６】
次に、本実施の形態の特徴部分である課金部１１２ａについて詳細に説明する。なお、課金部１１２ａは、オブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができるようにオブジェクトモデルを構成した。かかるオブジェクトモデルの構成について図６〜図８を用いて説明しておく。
【００７７】
図６は、複合機１の操作パネル４００の一例を示した図である。同図に示すように、かかる操作パネル４００は、初期設定キー４０１、コピーキー４０２、コピーサーバーキー４０３、プリンタキー４０４、送信キー４０５、テンキー４０６、クリア／ストップキー４０７、スタートキー４０８、予熱キー４０９、リセットキー４１０および液晶タッチパネル４２０を有する。
【００７８】
初期設定キー４０１をタッチすると、液晶タッチパネル４２０に初期設定用のメニューが表示され、かかるメニューにおいては、収納される用紙サイズなどを設定することができる。また、コピーをしたい場合にはコピーキー４０２を、コピー結果を複合機１に蓄積したい場合にはコピーサーバーキー４０３を、プリンタに係る操作をおこないたい場合には、プリンタキー４０４を、ファックスや蓄積画像などの送信をしたい場合には送信キー４０５を、それぞれタッチすると、液晶タッチパネル４２０に対応したメニューが表示される。
【００７９】
図７は液晶タッチパネル４２０に表示されるメニューの一例である。このメニューは、図６に示したコピーキー４０２をタッチすることにより表示される。図７に示すように、この液晶タッチパネル４２０には、自動濃度ボタン４２１、自動用紙選択ボタン４２２、等倍ボタン４２３などが表示される。利用者は、これらのボタンを選択することによりコピー機能の詳細な内容を指示し、この指示を受け取った複合機１は、指示された内容に従ってコピー処理を実行することになる。
【００８０】
そして、かかるコピー処理に対する課金は、コピーの種別（たとえば、モノクロコピーやカラーコピー）、記録紙の種別（たとえば、Ａ４やＡ３）、コピーの枚数などに基づいておこなわれる。たとえば、Ａ４のモノクロコピーの料金が一枚あたり１０円である場合において、利用者が課金装置１ａに１００円硬貨を一枚投入し、かかるコピーを８枚指示した場合には、課金される料金は８０円となり８０円が徴収され、２０円が返却される。
【００８１】
また、ネットワークを利用した複数の利用者が、複合機１に対して電子データの印刷を指示したり、電子データのファックスを指示したりする場合には、課金サーバ２には、これらの処理に応じた課金履歴が蓄積されることになる。そして、蓄積された課金履歴に基づいて課金がおこなわれる。
【００８２】
このように、ネットワークの進展により、ネットワークを利用した複数の利用者や、複合機１を操作する利用者が同時にサービス提供を要求する場合が多くなるので、サービス料金（対価）の課金処理を確実におこなう必要がある。また、複合機１に直接接続される課金装置１ａのみならず、ネットワーク接続され複合機１と通信可能な課金管理装置（たとえば、課金サーバ２）も課金を実行する装置となりうるので、課金を実行する装置は多数存在する。したがって、課金を実行する装置の選択および切替えを確実におこなって、二重課金や未課金などの課金ミスがないようにする必要がある。
【００８３】
ここで、課金装置の種類について説明しておく。課金装置には、加算式課金装置と減算式課金装置とがあり、加算式課金装置としては、たとえば、加算式キーカード装置、クレジットカード装置および課金サーバ２などがある。また、減算式課金装置としては、たとえば、減算式キーカード装置、コインラック装置およびプリペイドカード装置などがある。このように、課金装置の種類は多様であり、複数の課金装置が接続され課金先を切替えて課金実行をおこなう場合も多い。
【００８４】
図８は、サービス対価の課金処理の概要を説明するための説明図である。同図に示すように、利用者が複合機１を操作して有料コピーサービスなどのサービス要求をおこなった場合、かかる課金処理においては、まず、提供するサービスの対価を算出し、つづいて課金装置（１ａおよび２）の中から課金の実行が可能な課金装置を選択し、サービスを提供した後に、選択した課金装置において対価の徴収をおこなうことになる。
【００８５】
なお、利用可能な課金装置が多数ある場合には、複数の課金装置を順次切替えて課金実行をおこなうこととすることもできる。たとえば、課金実行中の加算式課金装置のカウント値が最大値に達したならば、課金実行先を他の加算式課金装置に切替えて課金を実行することとすれば、サービス提供を中止することなくサービス対価の徴収が可能となる（課金装置の組合せ）。
【００８６】
このように、複数の課金装置を用いる場合には、課金装置の切替え、課金装置の追加および課金装置の取外しに柔軟に対応できる課金管理の仕組みが必要となる。また、加算式課金装置や減算式課金装置といった課金装置固有の特性に基づいてオブジェクトモデリングをおこなう必要がある。
【００８７】
そこで、本実施の形態の特徴部分である課金部１１２ａは、加算式課金装置および減算式課金装置に対応するクラスと、各課金装置の切替えを管理するクラスを中心に各クラスを設計した。図９は、課金部１１２ａのクラス構成を示すＵＭＬクラス図である。同図に示すように、課金部１１２ａは、利用者のサービス要求を受け付ける帳簿クラス３１０、各サービス要求を「伝票」として管理する伝票クラス３２０、サービスの単価一覧を保持する料金表クラス３３０、サービスの対価を算出して対価の徴収を指示する対価クラス３４０、課金実行先の一覧を保持する取引表クラス３５０、減算式課金装置に対応する投入金額クラス３６０、加算式課金装置を取りまとめる請求金額クラス３７０および加算式課金装置に対応する請求先クラス３８０を有する。
【００８８】
ここで、「伝票」の単位について説明しておく。伝票の単位は、一つの「伝票」あたり１つの「ジョブ」とすることを基本とするが、かかる伝票の単位をこれと異なるものとすることもできる。なお、「ジョブ」とは、成果物（たとえば、コピーした記録紙）の作成が完了するまでの処理の実行単位をいい、複合機全体として入力の始まりから出力の終了までを示す。
【００８９】
たとえば、利用者がモノクロコピー１０枚を依頼した場合、「モノクロコピー１０枚」を一つの「ジョブ」とすれば、一つの伝票は「モノクロコピー１０枚」の依頼を含むことになる。しかし、「モノクロコピー１枚」を一つの「ジョブ」とすれば、「モノクロコピー１枚」を一つの伝票とすることもできる。また、「カラーコピー５枚」と「モノクロコピー５枚」とを依頼した場合、これらの依頼のそれぞれを一つの伝票とすることが基本となるが、これらの依頼をまとめて一つの伝票とすることもできる。
【００９０】
次に、クラスとＵＭＬクラス図におけるクラスの記述方法について説明しておく。クラスとは、オブジェクト指向システムを構成するオブジェクトの設計図に相当する概念であり、オブジェクト内部に有する属性と処理や、他のオブジェクトとの関係を定義するものである。
【００９１】
ＵＭＬクラス図におけるクラスは、３段の区画を有する矩形として記述される。それぞれの区画は、上から、クラス名を示す名前区画、クラスが有するデータ（属性）を示す属性区画およびクラスが有する処理（操作）を示す操作区画と呼ばれる。たとえば、帳簿クラス３１０を示す矩形の名前区画は、かかるクラスのクラス名が「帳簿」であることを示し、属性区画は、かかるクラスが有する属性が、「状態」であることを示し、操作区画は、かかるクラスが有する操作が、「記入する（）」および「取消す（）」であることを示している。
【００９２】
このように、各クラスは、データ（属性）を所持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう処理（操作）を所持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。
【００９３】
なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「＋」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については「記入する（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。
【００９４】
次に、本実施の形態の特徴部分である課金部１１２ａのクラスの概要について説明する。上述したように、課金部１１２ａは、帳簿クラス３１０、伝票クラス３２０、料金表クラス３３０、対価クラス３４０、取引表クラス３５０、投入金額クラス３６０、請求金額クラス３７０および請求先クラス３８０を有する。以下では、まず、これらのクラスの概要について説明する。
【００９５】
帳簿クラス３１０は、課金対象となる機能（たとえば、コピー機能やファックス機能）の詳細な内容（たとえば、用紙サイズやカラーモード）を受け付けるクラスであり、伝票クラス３２０は、受け付けた詳細な内容を保持するとともに課金状況を保持しておくクラスである。また、料金表クラス３３０は、課金対象となる機能の単価一覧を保持するととともに該当する料金を検索するクラスであり、対価クラス３４０は、対価の徴収可否を把握し課金先となる課金装置を決定するクラスであり、取引表クラス３５０は、提供する機能ごとの課金装置の利用制限一覧を保持するとともに、利用可能な課金装置を検索するクラスである。
【００９６】
また、投入金額クラス３６０は、コインラック装置などの減算式課金装置の状態を管理するとともに、管理する減算式課金装置に課金実行を指示するクラスである。さらに、請求金額クラス３７０は、加算式課金装置を束ね、加算するタイミングと加算する料金の合計値を管理するクラスであり、請求先クラス３８０は、加算式キーカード装置などの加算式課金装置の状態を管理し、管理する加算式課金装置に課金実行を指示するクラスである。
【００９７】
次に、各クラスの内容についてさらに詳細に説明する。帳簿クラス３１０は、課金対象となる機能（たとえば、コピー機能やファックス機能）の詳細な内容（たとえば、用紙サイズやカラーモード）を受け付けるクラスである。具体的には、この帳簿クラス３１０は、属性として、状態３１０ａを有し、操作として、記入する（）３１０ｂおよび取消す（）３１０ｃを有する。なお、かかる帳簿クラス３１０を実体化したオブジェクトが生成されると、状態３１０ａはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【００９８】
状態３１０ａは、現在の帳簿の処理状態をあらわし、この状態には、閉状態および開状態の２つがある。閉状態とは、処理対象となる伝票が存在しないので帳簿を閉じている状態をあらわし、開状態とは、帳簿を開いて伝票を処理している状態をあらわす。
【００９９】
記入する（）３１０ｂは、操作系サブシステム１１１を経由して利用者の注文を受け付け、新しい注文であれば伝票クラス３２０のオブジェクトを生成し、その注文内容をこのオブジェクトに引き渡す。また、注文の変更を受け付けた場合には、該当する伝票クラス３２０のオブジェクトを探し、かかるオブジェクトが保持する注文内容を書き換える。
【０１００】
ここで、「注文」とは、コピー機能やファックス機能を利用者が利用する際の利用単位のことをあらわす。たとえば、利用者が「Ａ４モノクロコピー」を１０枚指示した場合には、「Ａ４モノクロコピー１０枚」を一つの「注文」とする。この場合、「Ａ４モノクロコピー１枚」を一つの「注文」とし、かかる「注文」が１０個あることとしてもよい。また、利用者が、「Ａ４モノクロコピー１０枚」と「Ａ４カラーコピー１０枚」を同時に指示した場合には、「Ａ４モノクロコピー１０枚」を一つの「注文」とし、「Ａ４カラーコピー１０枚」を一つの「注文」とするが、「Ａ４モノクロコピー１０枚」および「Ａ４カラーコピー１０枚」を一つの「注文」とすることもできる。なお、「注文内容」とは、用紙サイズやカラーモードといった上記「詳細な内容」のことをあらわす。
【０１０１】
また、取消す（）３１０ｃは、受け付けた注文の取り消し処理をおこなう。具体的には、この取消す（）３１０ｃは、注文取り消しの対象となる伝票クラス３２０のオブジェクトを削除する。
【０１０２】
伝票クラス３２０は、受け付けた詳細な内容を保持するとともに課金状況を保持しておくクラスである。具体的には、この伝票クラス３２０は、属性として、状態３２０ａ、番号３２０ｂ、サービス内容３２０ｃおよび料金３２０ｄを有し、操作として、記入する（）３２０ｅ、処理する（）３２０ｆ、および完結する（）３２０ｇを有する。なお、かかる伝票クラス３２０を実体化したオブジェクトが生成されると、状態３２０ａ、番号３２０ｂ、サービス内容３２０ｃおよび料金３２０ｄはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１０３】
状態３２０ａは、現在の伝票クラス３２０の処理状態をあらわし、この状態には、記入中、処理中および処理済の３つがある。記入中状態とは、受け付けた詳細な内容の変更が可能な状態をあらわし、処理中状態とは、課金処理が継続中である状態をあらわし、処理済状態とは、課金処理が終了している状態をあらわす。ここで、図１０を用いてこれらの状態と各状態間の状態遷移について説明しておく。図１０は、伝票クラス３２０の状態遷移（状態３２０ａが保持する状態の状態遷移）を示すＵＭＬステートチャート図である。
【０１０４】
同図に示すように、現在の状態が「記入中」であれば、「処理中」状態への状態遷移が可能である。具体的には、「記入中」状態において記入する（）３２０ｅが呼び出されると（ステップＳ１０１）、状態は「記入中」のままである。また、処理する（）３２０ｆが呼び出されると（ステップＳ１０２）、「処理中」状態に状態遷移する。
【０１０５】
また、同図に示したように、現在の状態が「処理中」であれば、「記入中」および「処理済」状態への状態遷移が可能である。具体的には、「処理中」状態において処理する（）３２０ｆが呼び出されると（ステップＳ１０３）、状態は「処理中」状態のままである。また、記入する（）３２０ｅが呼び出されると（ステップＳ１０４）、「記入中」状態に状態遷移し、完結する（）３２０ｇが呼び出されると（ステップＳ１０５）、「処理済」状態に状態遷移する。
【０１０６】
このように、状態３２０ａの各状態に応じて実行可能な操作が限定されており、実行された操作による遷移先の状態も限定されている。このような「状態」および「状態遷移」の概念を用いることにより、伝票クラス３２０は、「伝票」の処理状態を的確に把握することができる。
【０１０７】
図９に戻って、番号３２０ｂについて説明する。番号３２０ｂは、伝票クラス３２０の各オブジェクトを識別するための値を保持する。この番号３２０ｂは、他のクラスのオブジェクトが、処理対象となる伝票クラス３２０のオブジェクトを特定して処理をおこなう際に参照される。
【０１０８】
サービス内容３２０ｃは、コピーやファックスといった各機能の詳細な内容を保持する。この詳細な内容とは、たとえば、「Ａ４モノクロコピーを１０枚」や「Ａ３カラー両面コピーを１００枚」といった、利用者が要求した機能の詳細な内容のことを指す。また、料金３２０ｄは、サービス内容３２０ｃに対応するサービス料金を保持する。
【０１０９】
記入する（）３２０ｅは、帳簿クラス３１０から通知された詳細な内容を、サービス内容３２０ｃに保持させる処理をおこなうとともに、対価クラス３４０に対し、料金３２０ｄに保持した金額の徴収が可能か否かの確認および課金方法の決定を依頼する処理をおこなう。また、処理する（）３２０ｆは、料金３２０ｄに保持した金額の徴収を対価クラス３４０に依頼する処理をおこなう。さらに、完結する（）３２０ｇは、伝票クラス３２０の終了処理をおこなう。
【０１１０】
料金表クラス３３０は、課金対象となる機能の単価一覧を保持するととともに該当する料金を検索するクラスである。具体的には、この料金表クラス３３０は、属性として、単価一覧３３０ａを有し、操作として、検索する（）３３０ｂを有する。なお、かかる料金表クラス３３０を実体化したオブジェクトが生成されると、単価一覧３３０ａはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１１１】
単価一覧３３０ａは、コピー機能やファックス機能といった機能ごとの単価を保持する。また、検索する（）３３０ｂは、伝票クラス３２０から呼び出され、指定された機能の単価を単価一覧３４０ａの検索により取得し、取得した単価を呼び出し元に通知する。
【０１１２】
対価クラス３４０は、対価の徴収可否を把握し課金先となる課金装置を決定するクラスである。具体的には、この対価クラス３４０は、属性として、状態３４０ａを有し、操作として、交換する（）３４０ｂ、領収可否を確認する（）３４０ｃおよび付替要求（）３４０ｄを有する。なお、かかる対価クラス３４０を実体化したオブジェクトが生成されると、状態３４０ａはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１１３】
状態３４０ａは、現在の対価クラス３４０の処理状態をあらわし、この状態には、交換不可、交換可能および付替中の３つがある。交換不可状態とは、提供機能に対する料金の交換ができない状態、言い換えると、料金の徴収ができないので機能を提供してはいけない状態をあらわす。また、交換可能状態とは、料金の徴収ができるので機能を提供してよい状態をあらわし、付替中状態とは、料金徴収を実行する課金装置の変更処理をおこなっている状態をあらわす。ここで、図１１を用いてこれらの状態と各状態間の状態遷移について説明しておく。図１１は、対価クラス３４０の状態遷移（状態３４０ａが保持する状態の状態遷移）を示すＵＭＬステートチャート図である。
【０１１４】
同図に示すように、現在の状態が「交換不可」であれば、「交換可能」および「付替中」状態への状態遷移が可能である。具体的には、「交換不可」状態において領収可否を確認する（）３４０ｃが呼び出され、その戻り値が「ＮＧ」であれば（ステップＳ２０１）、状態は「交換不可」のままであり、かかる戻り値が「ＯＫ」であれば（ステップＳ２０２）、「交換不可」状態に状態遷移する。また、付替要求（）３４０ｄが呼び出されると（ステップＳ２０３）、「付替中」状態に状態遷移する。
【０１１５】
また、同図に示したように、現在の状態が「交換可能」であれば、「交換不可」および「付替中」状態への状態遷移が可能である。具体的には、「交換可能」状態において交換する（）３４０ｂが呼び出されると（ステップＳ２０４）、状態は「交換可能」のままである。また、領収可否を確認する（）３４０ｃが呼び出され、その戻り値が「ＯＫ」である場合にも（ステップＳ２０４）、状態は「交換可能」のままである。また、領収可否を確認する（）３４０ｃが呼び出され、その戻り値が「ＮＧ」であれば（ステップＳ２０５）、「交換不可」状態に状態遷移し、付替要求（）３４０ｄが呼び出されると（ステップＳ２０６）、「付替中」状態に状態遷移する。
【０１１６】
また、現在の状態が「付替中」であれば、「交換不可」および「交換可能」状態への状態遷移が可能である。具体的には、「付替中」状態において領収可否を確認する（）３４０ｃが呼び出され、その戻り値が「ＮＧ」であれば（ステップＳ２０７）、「交換不可」状態に状態遷移し、かかる戻り値が「ＯＫ」であれば（ステップＳ２０８）、「交換可能」状態に状態遷移する。
【０１１７】
このように、状態３４０ａの各状態に応じて実行可能な操作が限定されており、実行された操作による遷移先の状態も限定されている。このような「状態」および「状態遷移」の概念を用いることにより、対価クラス３４０は、対価の交換可否状態を的確に把握することができる。
【０１１８】
図９に戻り、交換する（）３４０ｂについて説明する。交換する（）３４０ｂは、領収可否を確認する（）３４０ｃの実行により決定した課金方法により課金をおこなう。たとえば、決定した課金方法が減算式課金装置であれば投入金額クラス３６０に、加算式課金装置であれば請求金額クラス３７０に、課金処理をおこなわせる。
【０１１９】
領収可否を確認する（）３４０ｃは、課金方法を決定するとともに、料金の回収が可能であるか否かを確認する処理をおこなう。たとえば、伝票クラス３２０の料金３２０ｄに保持されている金額が１０００円であり、この金額を徴収可能な課金装置が見つかったならば、この領収可否を確認する（）３４０ｃは「ＯＫ」を返す。一方、１０００円を徴収可能な課金装置が見つからない場合には、「ＮＧ」を返す。また、付替要求（）３４０ｄは、かかる課金方法を変更する処理をおこなう。
【０１２０】
取引表クラス３５０は、提供する機能ごとの課金装置の利用制限一覧を保持するとともに利用可能な課金装置を検索するクラスである。具体的には、この取引表クラス３５０は、属性として、制限一覧３５０ａを有し、操作として、検索する（）３５０ｂおよび更新する（）３５０ｃを有する。なお、かかる取引表クラス３５０を実体化したオブジェクトが生成されると、制限一覧３５０ａはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１２１】
制限一覧３５０ａは、コピー機能などの課金対象となる機能ごとに、利用可能な課金方法一覧を保持する。たとえば、ファックス機能では、コインラック装置を課金方法として選択できないのであれば、ファックス機能で利用可能な課金方法一覧には、コインラック装置は含まれないことになる。なお、利用料が無料である機能の場合には、かかる機能の課金方法はない旨の情報を保持する。また、かかる課金方法一覧には、各課金装置の優先順位を含めることとしてもよい。検索する（）３５０ｂは、制限一覧３５０ａから該当する利用可能な課金方法を取出し、呼び出し元に通知する処理をおこなう。また、更新する（）３５０ｃは、制限一覧３５０ａを更新する処理をおこなう。
【０１２２】
投入金額クラス３６０は、コインラック装置などの減算式課金装置の状態を管理するとともに、管理する減算式課金装置に課金実行を指示するクラスである。具体的には、この投入金額クラス３６０は、属性として、状態３６０ａ、名称３６０ｂおよび残高３６０ｃを有し、操作として、事前確認する（）３６０ｄ、減算する（）３６０ｅ、追加する（）３６０ｆおよび返却する（）３６０ｇを有する。なお、かかる投入金額クラス３６０を実体化したオブジェクトが生成されると、状態３６０ａ、名称３６０ｂおよび残高３６０ｃはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１２３】
状態３６０ａは、現在の投入金額クラス３６０の処理状態をあらわし、この状態には、残高不足および残高十分の２つがある。残高不足状態とは、対応する減算式課金装置の残高が、伝票クラス３２０の料金３２０ｄに保持されている金額よりも小さい状態をあらわし、残高十分状態とは、かかる残高が料金３２０ｄに保持されている金額以上である状態をあらわす。ここで、図１２を用いてこれらの状態と各状態間の状態遷移について説明しておく。図１２は、投入金額クラス３６０の状態遷移（状態３６０ａが保持する状態の状態遷移）を示すＵＭＬステートチャート図である。
【０１２４】
同図に示すように、現在の状態が「残高不足」であれば、「残高十分」状態への状態遷移が可能である。具体的には、「残高不足」状態において追加する（）３６０ｆまたは返却する（）３６０ｇが呼び出されても（ステップＳ３０１）、状態は「残高不足」のままである。しかしながら、事前確認をする（）３６０ｄが呼び出され、その戻り値が「ＯＫ」であれば（ステップＳ３０２）、「残高十分」状態に状態遷移する。
【０１２５】
また、同図に示したように、現在の状態が「残高十分」であれば、「残高不足」状態への状態遷移が可能である。具体的には、「残高十分」状態において追加する（）３６０ｆまたは減算する（）３６０ｅが呼び出されても（ステップＳ３０３）、状態は「残高十分」のままである。しかしながら、事前確認をする（）３６０ｄが呼び出され、その戻り値が「ＮＧ」であれば（ステップＳ３０４）、「残高不足」状態に状態遷移する。
【０１２６】
「残高不足」状態および「残高十分」状態間の状態遷移は、事前確認をする（）３６０ｄが呼び出された場合にのみおこなわれ、減算する（）３６０ｅ、追加する（）３６０ｆおよび返却する（）３６０ｄが呼び出された場合には、かかる状態遷移はおこなわれない。このように、状態３６０ａの各状態に応じて実行可能な操作が限定されており、実行された操作による遷移先の状態も限定されている。このような「状態」および「状態遷移」の概念を用いることにより、投入金額クラス３６０は、減算式課金装置の残高状態を的確に把握することができる。
【０１２７】
図９に戻って、名称３６０ｂについて説明する。名称３６０ｂは、コインラック装置や減算式キーカード装置といった減算式課金装置の名称（略号などを含む）を保持し、残高３６０ｃは、投入された貨幣の残金や、カウント値といった残高を保持する。
【０１２８】
事前確認する（）３６０ｄは、伝票クラス３２０の料金３２０ｄに保持されている金額（料金）と残高３６０ｃに保持されている金額（残高）とを比較して、かかる料金の徴収が可能であるか否かを確認する処理をおこなう。なお、この事前確認する（）３６０ｄは、徴収が可能であれば「ＯＫ」を、徴収が不可能であれば「ＮＧ」を呼び出し元に返す。
【０１２９】
減算する（）３６０ｅは、対応する減算式課金装置に対して課金を実行させる処理をおこない、追加する（）３６０ｆは、減算式課金装置に追加された金額を残高３６０ｃに足しこむ処理をおこなう。また、返却する（）３６０ｇは、減算式課金装置の残金が０となった場合や、利用者が減算式課金装置の返却ボタンを押下して残金が返却された場合に、残金３６０ｃの値を０にする処理をおこなう。
【０１３０】
請求金額クラス３７０は、加算式キーカード装置などの加算式課金装置を束ね、加算するタイミングと加算する料金の合計値を管理するクラスである。具体的には、この請求金額クラス３７０は、属性として、状態３７０ａ、合計額３７０ｂ、限度額３７０ｃおよび精算日３７０ｄを有し、操作として、査定する（）３７０ｅ、加算する（）３７０ｆ、精算する（）３７０ｇおよび付替要求（）３７０ｈを有する。なお、かかる請求金額クラス３７０を実体化したオブジェクトが生成されると、状態３７０ａ、合計額３７０ｂ、限度額３７０ｃおよび精算日３７０ｄはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１３１】
状態３７０ａは、現在の請求金額クラス３７０の処理状態をあらわし、この状態には、付替可能、加算可能、加算不可および精算中の４つがある。付替可能状態とは、請求先となる加算式課金装置の切替えが可能な状態をあらわし、加算可能状態とは、いずれかの加算式課金装置への料金徴収が可能な状態をあらわし、加算不可状態とは、いずれの加算式課金装置を用いても料金徴収が不可能な状態をあらわす。また、精算中状態とは、料金徴収（精算）が処理中であることを指す。ここで、図１３を用いてこれらの状態と各状態間の状態遷移について説明しておく。図１３は、請求金額クラス３７０の状態遷移（状態３７０ａが保持する状態の状態遷移）を示すＵＭＬステートチャート図である。
【０１３２】
同図に示すように、現在の状態が「付替可能」であれば、「加算可能」状態への状態遷移が可能である。具体的には、「付替可能」状態において付替要求（）３７０ｈが呼び出されても（ステップＳ４０１）、状態は「付替可能」のままである。また、加算する（）３７０ｆが呼び出されると（ステップＳ４０２）、「加算可能」状態に状態遷移する。
【０１３３】
また、同図に示したように、現在の状態が「加算可能」であれば、「精算中」および「加算不可」状態への状態遷移が可能である。具体的には、「加算可能」状態において加算する（）３７０ｆが呼び出されても（ステップＳ４０３）、状態は「加算可能」のままである。また、精算日３７０ｄを指定して精算する（）３７０ｇが呼び出されると（ステップＳ４０４）、「精算中」状態に状態遷移し、加算する（）３７０ｆが呼び出され加算処理がおこなわれた結果、限度額３７０ｃに達すると（ステップＳ４０５）、「加算不可」状態に状態遷移する。
【０１３４】
また、現在の状態が「加算不可」であれば、「精算中」状態への状態遷移が可能である。具体的には、「加算不可」状態において「直ちに」の条件で精算する（）３７０ｇが呼び出されると（ステップＳ４０６）、「精算中」状態に状態遷移する。さらに、現在の状態が「精算中」であれば、「付替可能」状態への状態遷移が可能である。具体的には、「精算中」状態において精算が完了した場合には、「付替可能」状態に状態遷移する（ステップＳ４０７）。
【０１３５】
このように、状態３７０ａの各状態に応じて実行可能な操作が限定されており、実行された操作による遷移先の状態も限定されている。このような「状態」および「状態遷移」の概念を用いることにより、請求金額クラス３７０は、加算式課金装置を束ねて管理し、必要に応じてかかる加算式課金装置の切替えをおこなうことができる。
【０１３６】
図９に戻って、合計額３７０ｂについて説明する。合計額３７０ｂは、提供した機能の料金を保持する。この合計額３７０ｂは、機能提供中に随時加算されていき、精算する（）３７０ｇが呼び出された際に、まとめて料金の徴収（カウント値の加算など）がおこなわれる。また、限度額３７０ｃは、加算可能な料金の上限値を保持し、精算日３７０ｄは、精算処理を事後的におこなう場合の精算日時などを保持する。
【０１３７】
査定する（）３７０ｅは、管理下にある請求先クラス３８０に対して合計額３７０ｂに保持されている金額（料金）の徴収が可能であるか否かを確認する処理をおこない、加算する（）３７０ｆは、合計額３７０ｂに提供したサービスの料金を加算する処理をおこなう。また、精算する（）３７０ｇは、課金先として選択された請求先クラス３８０に対して課金を指示する処理をおこない、付替要求（）３７０ｈは、課金先となる請求先クラス３８０の切替え（付替）処理をおこなう。
【０１３８】
請求先クラス３８０は、加算式キーカード装置などの加算式課金装置の状態を管理し、管理する加算式課金装置に課金実行を指示するクラスである。具体的には、この請求先クラス３８０は、属性として、状態３８０ａおよび名称３８０ｂを有し、操作として、請求する（）３８０ｃ、有効にする（）３８０ｄおよび無効にする（）３８０ｅを有する。なお、かかる請求先クラス３８０を実体化したオブジェクトが生成されると、状態３８０ａおよび名称３８０ｂはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをおこなうことが可能となる。
【０１３９】
状態３８０ａは、現在の請求先クラス３８０の処理状態をあらわし、この状態には、無効状態および有効状態の２つがある。無効状態とは、対応する加算式課金装置の使用が許可されていない状態をあらわし、有効状態とは、対応する加算式課金装置の使用が許可されている状態をあらわす。また、名称３８０ｂは、加算式キーカード装置やクレジットカード装置といった加算式課金装置の名称（略号などを含む）を保持する。
【０１４０】
請求する（）３８０ｃは、対応する加算式課金装置に対し課金実行を指示する処理をおこない、有効にする（）３８０ｄは、対応する加算式課金装置に対し使用許可を与える処理をおこない、無効にする（）３８０ｅは、対応する加算式課金装置に対し使用許可を取消す処理をおこなう。
【０１４１】
次に、図９に示した各クラス間の関係について説明する。同図に示したように、ＵＭＬクラス図においては、クラス間に何らかの関係がある場合には、それらのクラスを表す矩形の間が直線で結ばれる。この直線の両端付近の文字はクラスのロールを表し、数字はクラスの多重度を表す。ここで、ロールとは、直線で結ばれた他方のクラスに対する当該クラスの役割のことであり、多重度とは、直線で結ばれた他方のクラスのオブジェクトと関連付けられて生成されるオブジェクトの数のことである。
【０１４２】
たとえば、帳簿クラス３１０からみた伝票クラス３２０の役割は「綴じるもの」であり、伝票クラス３２０からみた帳簿クラス３１０の役割は「綴じ先」である。また、帳簿クラス３１０の多重度は「１」であり、伝票クラス３２０の多重度は「０．．ｎ」である。ここで、「０．．ｎ」は、かかる伝票クラス３２０の多重度が、０からｎの範囲であることを示している。また、たとえば、「１．．３」の記載をした場合には、かかるクラスの多重度が、１〜３の範囲であることを示す。
【０１４３】
まず、帳簿クラス３１０と伝票クラス３２０とのクラス関係について説明する。帳簿クラス３１０のオブジェクトは、課金部１１２ａ内に１個のみ存在し、伝票クラス３２０のオブジェクトは、利用者の機能要求ごとに、帳簿クラス３１０のオブジェクトにより生成される。すなわち、複数の機能（コピー機能やプリンタ機能など）が同時に提供されている場合には、同時に提供している機能数分の伝票クラス３２０のオブジェクトが生成される。したがって、帳簿クラス３１０のオブジェクトに対して０個以上ｎ個以下の範囲で存在する。ここで、オブジェクト数が０個とは、提供中の機能がなく伝票クラス３２０のオブジェクトが存在しない場合を示しており、かかるオブジェクト数の上限数はｎ個としているものの、当然に、ハードウェア仕様などによる制限を受けるものとする。
【０１４４】
また、帳簿クラス３１０は、伝票クラス３２０から見ると「綴じ先（管理者）」としての役割を有しており、一方、伝票クラス３２０は、帳簿クラス３１０から見ると「綴じるもの（管理対象）」としての役割を有している。
【０１４５】
次に、伝票クラス３２０と料金表クラス３３０との関係について説明する。伝票クラス３２０のオブジェクトは提供する機能ごとに生成され、かかるオブジェクトごとに料金が発生するので、伝票クラス３２０は料金表クラス３３０に料金の単価の検索を依頼し、これに基づいて料金を算出する必要がある。したがって、伝票クラス３２０と料金表クラス３３０とは、「検索者」と「単価」という関係をなしている。また、料金表クラス３３０のオブジェクトは、課金部１１２ａ内に１個のみ存在する。上述したように、伝票クラス３２０のオブジェクトは、同時に提供している機能数分だけ存在するので、料金表クラス３３０のオブジェクトに対して０個以上ｎ個以下の範囲で存在する。
【０１４６】
次に、伝票クラス３２０と対価クラス３４０との関係について説明する。伝票クラス３２０のオブジェクトは提供する機能ごとに生成され、かかるオブジェクトごとに料金（提供した機能の対価）が発生する。したがって、伝票クラス３２０と対価クラス３４０は、「請求者」と「対価」の関係をなしている。また、一つの伝票クラス３２０のオブジェクトに対して、一つの対価クラス３３０のオブジェクトが存在するので、それぞれのオブジェクトは１対１の関係をなす。なお、料金の徴収が不要な場合は、伝票クラス３２０のオブジェクトに対応する対価クラス３４０のオブジェクトは存在しないので、対価クラス３４０のオブジェクトは、伝票クラス３２０のオブジェクトに対して０個以上１個以下の範囲で存在する。
【０１４７】
次に、対価クラス３４０と取引表クラス３５０との関係について説明する。対価クラス３４０は、対価の交換（料金の徴収）に先立って、利用可能な（利用が制限されていない）課金装置を取得する必要がある。したがって、対価クラス３４０と取引表クラス３５０は、「検索者」と「制限」の関係をなしている。なお、両クラスの多重度の関係は、上述した伝票クラス３２０と料金クラス３３０の関係と同様である。
【０１４８】
次に、対価クラス３４０と投入金額クラス３６０との関係について説明する。対価クラス３４０は、対価の交換先（料金の徴収先）として減算式課金装置を選択した場合、減算式課金装置と対応するクラスである投入金額クラス３６０に課金の実行を指示する。したがって、対価クラス３４０と投入金額クラス３６０は、「対価」と「課金実行者」の関係をなしている。なお、選択可能な減算式課金装置は存在しない場合もあり、複数存在する場合もあるので、投入金額クラス３６０のオブジェクトは、対価クラス３４０のオブジェクトに対して０個以上ｎ個以下の範囲で存在する。
【０１４９】
次に、対価クラス３４０と請求金額クラス３７０との関係について説明する。対価クラス３４０は、対価の交換（料金の徴収）先として加算式課金装置を選択した場合、加算式課金装置を管理するクラスである請求金額クラス３７０に課金の実行を指示する。したがって、対価クラス３４と請求金額クラス３７０は、「対価」と「課金実行者」の関係をなしている。また、加算式課金装置を束ねて管理する請求金額クラス３７０のオブジェクトと、対価クラス３４０のオブジェクトとは１対１の関係をなすが、加算式課金装置が存在しない場合には、かかる装置を管理する請求金額クラス３７０のオブジェクトも存在しないので、請求金額クラス３７０のオブジェクトは、対価クラス３４０のオブジェクトに対して０個以上１個以下の範囲で存在する。
【０１５０】
最後に、請求金額クラス３７０と請求先クラス３８０との関係について説明する。請求金額クラス３７０のオブジェクトは、各加算式課金装置と対応する請求先クラス３８０のオブジェクトの中から、課金実行先となるオブジェクトを１個選択するとともに、他のオブジェクトを課金実行先の代替候補として管理する。したがって、請求金額クラス３７０と請求先クラス３８０は、「選択者」と「課金代行者」の関係をなすとともに、「選択者」と「予備代行者」の関係をなしている。なお、「課金代行者」となるオブジェクトは１個であり、「予備代行者」となるオブジェクトは１個以上ｎ個以下の範囲で存在する。
【０１５１】
このように、帳簿クラス３１０、伝票クラス３２０、料金表クラス３３０、対価クラス３４０、取引表クラス３５０、投入金額クラス３６０、請求金額クラス３７０および請求先クラス３８０の各オブジェクトは、相互に関連し合い、協調して、課金部１１２ａに必要な機能を実現している。
【０１５２】
次に、図９に示した各クラスの操作の実行手順について例をあげて説明する。図１４は、機能提供要求を受け付けた際の操作の実行手順を示すＵＭＬシーケンス図である。
【０１５３】
ここで、ＵＭＬシーケンス図について説明しておく。図１４の上部に並んだ矩形は、それぞれがクラスのオブジェクトを示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線（ライフライン）であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間（活性期間）を示す。
【０１５４】
各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれるの操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。また、矢印が自分自身のオブジェクトを指している場合は、オブジェクトが自分に含まれる操作を自身で呼び出すことを意味する。
【０１５５】
図１４に示すように、利用者が、複合機１の操作パネル４００を操作し、提供してほしい機能の機能内容を設定すると、かかる設定内容（機能内容）は操作系サブシステム１１１に通知される。そして、操作系サブシステム１１１は、帳簿オブジェクト３１０Ａの記入する（）３１０ｂを呼び出し（ステップＳ５０１）、かかる機能内容を帳簿オブジェクト３１０Ａに通知する。つづいて、帳簿オブジェクト３１０Ａは、伝票オブジェクト３２０Ａを生成するとともに、生成した伝票オブジェクト３２０Ａの記入する（）を呼び出し（ステップＳ５０２）、かかる機能内容を伝票オブジェクト３２０Ａに通知する。このようにして、利用者が設定した「機能内容」を反映した伝票オブジェクト３２０Ａが生成される。
【０１５６】
なお、操作系サブシステム１１１が、複数の機能の提供要求を受け付けた場合には、帳簿オブジェクト３１０Ａは、受け付けた機能に応じた数の伝票オブジェクト３２０Ａを生成し、生成した各伝票オブジェクト３２０Ａに機能内容を通知する。また、操作系サブシステムが、変更依頼を受け付けた場合には、帳簿オブジェクト３１０Ａは、伝票オブジェクト３２０Ａを生成せず、該当する伝票オブジェクト３２０Ａに変更内容を通知する。
【０１５７】
つづいて、伝票オブジェクト３２０Ａは、料金表オブジェクト３３０Ａの検索する（）３３０ｂを呼び出し（ステップＳ５０３）、かかる機能内容の料金の検索を依頼する。検索を依頼された料金表オブジェクト３３０Ａは、該当する「料金」を検索結果として伝票オブジェクト３２０Ａに返す（ステップＳ５０４）。検索結果を受け取った伝票オブジェクト３２０Ａは、料金３２０ｄに、かかる検索結果を書き込む。
【０１５８】
そして、伝票オブジェクト３２０Ａは、対価オブジェクト３４０Ａの領収可否を確認する（）３４０ｃを呼び出し（ステップＳ５０５）、対価オブジェクト３４０Ａに、「料金」の領収が可能な課金装置の決定を依頼する。依頼を受けた対価オブジェクト３４０Ａは、取引表オブジェクト３５０Ａの検索する（）３５０ｂを呼び出し（ステップＳ５０６）、「料金」の領収が可能な課金装置の検索を依頼する。検索を依頼された取引表オブジェクト３５０Ａは、該当する課金装置（課金対象）を検索結果として対価オブジェクト３４０Ａに返す（ステップＳ５０７）。
【０１５９】
たとえば、検索結果として通知された課金対象が減算式課金装置である場合には（ステップＳ５０８）、対価オブジェクト３４０Ａは、料金３２０ｄから読み出した「料金」を引数として、投入金額オブジェクト３６０Ａの事前確認する（）３６０ｄを呼び出し（ステップＳ５０９）、該当する減算式課金装置の残金が十分であるか否かの確認を依頼する。なお、検索結果として通知された課金対象が加算式課金装置である場合には、対価オブジェクト３４０Ａは、請求金額オブジェクト３７０Ａの査定する（）３７０ｅを呼び出すことになる。このようにして、サービス料金の領収可否が判明したならば、かかる領収可否を液晶タッチパネル４２０に表示するなどして、機能提供要求をおこなった利用者に通知する。
【０１６０】
次に、利用者が要求したサービスを提供する際に、サービス料金（提供したサービスの対価）を徴収する処理手順について図１５および図１６を用いて説明する。図１５は、減算式課金装置を選択して課金をおこなう場合の操作の実行手順を示すＵＭＬシーケンス図であり、図１６は、加算式課金装置を選択して課金をおこなう場合の操作の実行手順を示すＵＭＬシーケンス図である。
【０１６１】
まず、減算式課金装置が選択された場合の課金処理の手順について説明する。図１５に示すように、利用者への機能提供が完了したならば、実行系サブシステム１１３は、該当する伝票オブジェクト３２０Ａに、機能提供が完了したことを通知する。かかる通知は、伝票オブジェクト３２０Ａの処理する（）３２０ｆを呼び出すことによりおこなわれる(ステップＳ６０１)。機能提供の完了を通知された伝票オブジェクト３２０Ａは、自己の属性区画に保持されている料金３２０ｄの値を読み出し、この値（サービス料金）の徴収を、対応する対価オブジェクト３４０Ａに依頼する。具体的には、かかる伝票オブジェクト３２０Ａは、読み出した料金３２０ｄの値を引数に設定したうえで対応する対価オブジェクト３４０Ａの交換する（）３４０ｂを呼び出す（ステップＳ６０２）。
【０１６２】
そして、料金の徴収を依頼された対価オブジェクト３４０Ａは、コインラック装置などの減算式課金装置と対応する投入金額オブジェクト３６０Ａに対し、かかる料金の引き落としの実行依頼を、投入金額オブジェクト３６０Ａの減算する（）３６０ｅを呼び出すことによりおこなう（ステップＳ６０３）。
【０１６３】
次に、加算式課金装置が選択された場合の課金処理の手順について説明する。図１６に示すステップＳ７０１およびＳ７０２は、図１５に示したＳ６０１およびＳ６０２と同様の手順であるため説明を省略する。料金の徴収を依頼された対価オブジェクト３４０Ａは、加算式キーカード装置などの加算式課金装置を束ねて管理する請求金額オブジェクト３７０Ａに対し、かかる料金の加算の実行を依頼する。具体的には、かかる対価オブジェクト３４０Ａは、請求金額オブジェクト３７０Ａの加算する３７０ｆを呼び出す（ステップＳ７０３）。
【０１６４】
呼び出された請求金額オブジェクト３７０Ａは、通知された料金を自己の属性区画に保持されている合計額３７０ｂに足しこむ。そして、精算を実行する所定の条件を満たしたならば、かかる請求金額オブジェクト３７０Ａは、自己の精算する（）３７０ｇを呼び出す（ステップＳ７０４）。自己の精算する（）３７０ｇを呼び出した請求金額オブジェクト３７０Ａは、かかる合計額３７０ｂの値を引数に設定したうえで、加算式課金装置に対応する請求先オブジェクト３８０Ａの請求する（）３８０ｃを呼び出し（ステップＳ７０５）、課金実行を依頼する。
【０１６５】
次に、利用中の課金装置が無効状態（たとえば、コインラック装置の残金を返却した状態やキーカード装置のカードを抜取った状態）となった場合における課金装置の付替手順について図１７および図１８を用いて説明する。図１７は、選択した減算式課金装置から付替要求をおこなう際の操作の実行手順を示すＵＭＬシーケンス図であり、図１８は、選択した加算式課金装置から付替要求をおこなう際の操作の実行手順を示すＵＭＬシーケンス図である。
【０１６６】
まず、利用中の課金装置が減算式課金装置である場合の付替手順について説明する。図１７に示すように、利用中の減算式課金装置が無効状態となったことを通知された管理系サブシステム１１２は、該当する投入金額オブジェクト３６０Ａの返却する（）３６０ｇを呼び出す（ステップＳ８０１）。呼び出された投入金額オブジェクト３６０Ａは、対価オブジェクト３４０Ａの付替要求（）３４０ｄを呼び出し（ステップＳ８０２）、課金装置の付替を依頼する。そして、かかる付替依頼を受け付けた対価オブジェクト３４０Ａは、課金装置を再選択して課金装置の付替処理をおこなう。
【０１６７】
次に、利用中の課金装置が加算式課金装置である場合の付替手順について説明する。図１８に示すように、利用中の加算式課金装置が無効状態となったことを通知された管理系サブシステム１１２は、該当する請求先オブジェクト３８０Ａの無効にする（）３８０ｅを呼び出し（ステップＳ９０１）、対応する課金装置が無効状態となったことを通知する。呼び出された請求先オブジェクト３８０Ａは、請求金額オブジェクト３７０Ａの付替要求（）３７０ｈを呼び出し（ステップＳ９０２）、課金装置の付替を依頼する。呼び出された請求金額オブジェクト３７０Ａは、さらに、対価オブジェクト３４０Ａの付替要求（）３４０ｄを呼び出し（ステップＳ９０３）、課金装置の付替を依頼する。そして、かかる付替依頼を受け付けた対価オブジェクト３４０Ａは、課金装置を再選択して課金装置の付替処理をおこなう。
【０１６８】
上述してきたように、本実施の形態では、オブジェクト指向設計により課金部の仕組みを構築し、さらに、加算式課金装置および減算式課金装置に対応したオブジェクトモデリングをおこない、帳簿クラス、伝票クラス、料金表クラス、対価クラス、取引表クラス、投入金額クラス、請求金額クラスおよび請求先クラスを用いることにより、かかる課金部を実現したので、ソフトウェア開発者やソフトウェア保守要員が、課金部の構成と役割を容易に把握することができる。また、課金装置を体系的に管理し、かかる課金装置の状態に応じて課金装置を切替えることとしたので課金装置の追加や取外しを容易におこなうことができる。さらに、各課金装置間の機能の差異を課金部が吸収するようオブジェクトモデリングをおこなったので、効率的な課金処理をおこなうことができる。
【０１６９】
なお、本実施の形態では、加算式課金装置に対応する請求先クラスを束ねるクラスとして請求金額クラスを設けるとともに、減算式課金装置に対応する投入金額クラスを束ねるクラスを設けない構成とした。しかしながら、加算式課金装置の場合のように、課金装置に対応するクラスと、かかるクラスを束ねるクラスとの２段階のクラス構成とすることもできる。
【０１７０】
また、本実施の形態の画像形成装置で実行される課金管理プログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、ＣＰＵ１１が上記記憶媒体から、課金管理プログラムを読み出してＭＥＭ−Ｐ１２上にロードすることで、画像形成装置に、上述した各ステップ、各手段または各部を実現させる。
【０１７１】
また、課金管理プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、かかる課金管理プログラムをインターネットなどのネットワーク経由で提供または配布するようにしてもよい。
【産業上の利用可能性】
【０１７２】
以上のように、本発明にかかる課金管理プログラムおよび画像形成装置は、提供するサービスの対価として課金をおこなう各種装置の課金に有用であり、特に、画像形成装置の課金に適している。
【図面の簡単な説明】
【０１７３】
【図１】複合機をとりまくネットワーク環境を示すネットワーク図である。
【図２】複合機のハードウェアを説明するための説明図である。
【図３】複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。
【図４】統合アプリケーションの構成を説明するための説明図である。
【図５】統合アプリケーションの構成を表したＵＭＬクラス図である。
【図６】複合機の操作パネルを説明するための説明図である。
【図７】液晶タッチパネルに表示されるメニュー例を説明するための説明図である。
【図８】課金部のオブジェクトモデリングの概要を説明するための説明図である。
【図９】課金部のクラス構成を示すＵＭＬクラス図である。
【図１０】伝票クラスの状態遷移を示すＵＭＬステートチャート図である。
【図１１】対価クラスの状態遷移を示すＵＭＬステートチャート図である。
【図１２】投入金額クラスの状態遷移を示すＵＭＬステートチャート図である。
【図１３】請求金額クラスの状態遷移を示すＵＭＬステートチャート図である。
【図１４】機能提供要求を受け付けた際の操作の実行手順を示すＵＭＬシーケンス図である。
【図１５】減算式課金装置を選択して課金をおこなう際の操作の実行手順を示すＵＭＬシーケンス図である。
【図１６】加算式課金装置を選択して課金をおこなう際の操作の実行手順を示すＵＭＬシーケンス図である。
【図１７】選択した減算式課金装置から付替要求をおこなう際の操作の実行手順を示すＵＭＬシーケンス図である。
【図１８】選択した加算式課金装置から付替要求をおこなう際の操作の実行手順を示すＵＭＬシーケンス図である。
【図１９】複合機に搭載されるソフトウェア構成の変遷を示す説明図である。
【図２０】従来の複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。
【符号の説明】
【０１７４】
１  画像形成装置（複合機）
１ａ  課金装置
２  課金サーバ
１０  コントローラ
１１  ＣＰＵ
１２  ＭＥＭ−Ｐ
１２ａ  ＲＯＭ
１２ｂ  ＲＡＭ
１３  ＮＢ
１４  ＳＢ
１５  ＡＧＰ
１６  ＡＳＩＣ
１７  ＭＥＭ−Ｃ
１８  ＨＤＤ
２０  キーボード（オペレーションパネル）
３０  ＦＣＵ
４０  ＵＳＢ
５０  ＩＥＥＥ１３９４
６０  エンジン部（Engine）
１００  ソフトウェア
１０１  アプリケーション層
１０２  サービス層
１０２ａ  スキャナ制御部
１０２ｂ  プロッタ制御部
１０２ｃ  蓄積制御部
１０２ｄ  配信／メール送受信制御部
１０２ｅ  ＦＡＸ送受信制御部
１０２ｆ  ネットワーク通信制御部
１０２ｇ  その他の制御部
１０３  オペレーティングシステム
１１０  統合アプリケーション
１１１  操作系サブシステム
１１２  管理系サブシステム
１１２ａ  課金部
１１３  実行系サブシステム
１２０  コピーアプリケーション
１３０  スキャナアプリケーション
１４０  ファックスアプリケーション
１５０  プリンタアプリケーション
２００  ハードウェア
２０１  ハードウェアリソース
２０１ａ  スキャナ
２０１ｂ  プロッタ
２０１ｃ  ＨＤＤ
２０１ｄ  ネットワーク
２０１ｅ  その他のリソース
３１０  帳簿クラス（帳簿手段の一例）
３１０Ａ  帳簿オブジェクト（帳簿手段の一例）
３１０ａ  状態（）
３１０ｂ  記入する（）
３１０ｃ  取消す（）
３２０  伝票クラス（伝票手段の一例）
３２０Ａ  伝票オブジェクト（伝票手段の一例）
３２０ａ  状態
３２０ｂ  番号
３２０ｃ  サービス内容
３２０ｄ  料金
３２０ｅ  記入する（）
３２０ｆ  処理する（）
３２０ｇ  完結する（）
３３０  料金表クラス（料金表手段の一例）
３３０Ａ  料金表オブジェクト（料金表手段の一例）
３３０ａ  単価一覧
３３０ｂ  検索する（）
３４０  対価クラス（対価手段の一例）
３４０Ａ  対価オブジェクト（対価手段の一例）
３４０ａ  状態
３４０ｂ  交換する（）
３４０ｃ  領収可否を確認する（）
３４０ｄ  付替要求（）
３５０  取引表クラス（取引表手段の一例）
３５０Ａ  取引表オブジェクト（取引表手段の一例）
３５０ａ  制限一覧
３５０ｂ  検索する（）
３５０ｃ  更新する（）
３６０  投入金額クラス（減算式課金手段の一例）
３６０Ａ  投入金額オブジェクト（減算式課金手段の一例）
３６０ａ  状態
３６０ｂ  名称
３６０ｃ  残高
３６０ｄ  事前確認する（）
３６０ｅ  減算する（）
３６０ｆ  追加する（）
３６０ｇ  返却する（）
３７０  請求金額クラス（管理手段の一例）
３７０Ａ  請求金額オブジェクト（管理手段の一例）
３７０ａ  状態
３７０ｂ  合計額
３７０ｃ  限度額
３７０ｄ  精算日
３７０ｅ  査定する（）
３７０ｆ  加算する（）
３７０ｇ  精算する（）
３７０ｈ  付替要求（）
３８０  請求先クラス（加算式課金手段の一例）
３８０Ａ  請求先オブジェクト（加算式課金手段の一例）
３８０ａ  状態
３８０ｂ  名称
３８０ｃ  請求する（）
３８０ｄ  有効にする（）
３８０ｅ  無効にする（）
４００  操作パネル
４０１  初期設定キー
４０２  コピーキー
４０３  コピーサーバーキー
４０４  プリンタキー
４０５  送信キー
４０６  テンキー
４０７  クリア／ストップキー
４０８  スタートキー
４０９  予熱キー
４１０  リセットキー
４２０  液晶タッチパネル
４２１  自動濃度ボタン
４２２  自動用紙選択ボタン
４２３  等倍ボタン
５０１  サービス層分離前アプリケーション
５０２  サービス層分離後アプリケーション
５０３  共通ルーチン分離アプリケーション
５０４  オブジェクト指向アプリケーション
【図１】
2006085477.tif 000003
【図２】
2006085477.tif 000004
【図３】
2006085477.tif 000005
【図４】
2006085477.tif 000006
【図５】
2006085477.tif 000007
【図６】
2006085477.tif 000008
【図７】
2006085477.tif 000009
【図８】
2006085477.tif 000010
【図９】
2006085477.tif 000011
【図１０】
2006085477.tif 000012
【図１１】
2006085477.tif 000013
【図１２】
2006085477.tif 000014
【図１３】
2006085477.tif 000015
【図１４】
2006085477.tif 000016
【図１５】
2006085477.tif 000017
【図１６】
2006085477.tif 000018
【図１７】
2006085477.tif 000019
【図１８】
2006085477.tif 000020
【図１９】
2006085477.tif 000021
【図２０】
2006085477.tif 000022