(57)【要約】【課題】課金処理を効率よく実現すること。【解決手段】サービス提供装置の制御プログラムからサービス要求内容を含むサービス要求通知を受信したならば、サービス要求内容および伝票状態を含む注文伝票データを生成して保持し、サービス提供装置の制御プログラムからサービス完了通知を受信したならば、伝票状態をサービス提供完了状態に更新するとともに課金装置に課金を指示し、課金装置から課金完了通知を受信したならば、伝票状態を課金完了状態に更新する。また、これらの処理をオブジェクトの協調関係により実現する。【選択図】        図９
2006085476.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）
１００  ソフトウェア
１０１  アプリケーション層
１０２  サービス層
１０２ａ  スキャナ制御部
１０２ｂ  プロッタ制御部
１０２ｃ  蓄積制御部
１０２ｄ  配信／メール送受信制御部
１０２ｅ  ＦＡＸ送受信制御部
１０２ｆ  ネットワーク通信制御部
１０２ｇ  その他の制御部
１０３  オペレーティングシステム
１１０  統合アプリケーション
１１１  操作系サブシステム
１１２  管理系サブシステム
１１２ａ  課金部
１１３  実行系サブシステム
１２０  コピーアプリケーション
１３０  スキャナアプリケーション
１４０  ファックスアプリケーション
１５０  プリンタアプリケーション
２００  ハードウェア
２０１  ハードウェアリソース
２０１ａ  スキャナ
２０１ｂ  プロッタ
２０１ｃ  ＨＤＤ
２０１ｄ  ネットワーク
２０１ｅ  その他のリソース
３１０  注文係クラス（注文係手段の一例）
３１０ａ  注文を受ける（）
３１０ｂ  注文を取り消す（）
３１１  注文係オブジェクト（注文係手段の一例）
３２０  伝票クラス（伝票手段の一例）
３２０ａ  状態
３２０ｂ  商品名
３２０ｃ  数量
３２０ｄ  記入する（）
３２０ｅ  提供チェック（）
３２０ｆ  提供終了チェック（）
３２０ｇ  提供可否を確認する（）
３２１  伝票オブジェクト（伝票手段の一例）
３３０  会計クラス（会計手段の一例）
３３０ａ  回収可否を判定する（）
３３０ｂ  請求する（）
３３１  会計オブジェクト（会計手段の一例）
３４０  料金表クラス（料金表手段の一例）
３４０ａ  単価一覧
３４０ｂ  検索する（）
３４１  料金表オブジェクト（料金表手段の一例）
３５０  請求方法クラス（課金対象決定手段の一例）
３５０ａ  決定する（）
３５１  請求方法オブジェクト（課金対象決定手段の一例）
３６０  課金対象クラス（課金対象手段の一例）
３６０ａ  名称
３６０ｂ  残高
３６０ｃ  課金する（）
３６０ｄ  残高照会（）
３６１  課金対象オブジェクト（課金対象手段の一例）
３７０  集計クラス（集計手段の一例）
３７０ａ  記録する（）
３７０ｂ  集計する（）
４００  操作パネル
４０１  初期設定キー
４０２  コピーキー
４０３  コピーサーバーキー
４０４  プリンタキー
４０５  送信キー
４０６  テンキー
４０７  クリア／ストップキー
４０８  スタートキー
４０９  予熱キー
４１０  リセットキー
４２０  液晶タッチパネル
４２１  自動濃度ボタン
４２２  自動用紙選択ボタン
４２３  等倍ボタン
５０１  サービス層分離前アプリケーション
５０２  サービス層分離後アプリケーション
５０３  共通ルーチン分離アプリケーション
５０４  オブジェクト指向アプリケーション
【図１】
2006085476.tif 000003
【図２】
2006085476.tif 000004
【図３】
2006085476.tif 000005
【図４】
2006085476.tif 000006
【図５】
2006085476.tif 000007
【図６】
2006085476.tif 000008
【図７】
2006085476.tif 000009
【図８】
2006085476.tif 000010
【図９】
2006085476.tif 000011
【図１０】
2006085476.tif 000012
【図１１】
2006085476.tif 000013
【図１２】
2006085476.tif 000014
【図１３】
2006085476.tif 000015
【図１４】
2006085476.tif 000016
【図１５】
2006085476.tif 000017