知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-04-14
(45)【発行日】2025-04-22
(54)【発明の名称】情報処理装置及びプログラム
(51)【国際特許分類】
G06Q 20/28 20120101AFI20250415BHJP
G16Y 10/50 20200101ALI20250415BHJP
【ＦＩ】
G06Q20/28
G16Y10/50
【請求項の数】
4
(21)【出願番号】P 2020131772
(22)【出願日】2020-08-03
(65)【公開番号】P2022028400
(43)【公開日】2022-02-16
【審査請求日】2023-07-20
(73)【特許権者】
【識別番号】000005496
【氏名又は名称】富士フイルムビジネスイノベーション株式会社
(74)【代理人】
【識別番号】110001210
【氏名又は名称】弁理士法人ＹＫＩ国際特許事務所
(72)【発明者】
【氏名】杉浦 敦史
(72)【発明者】
【氏名】山本 寛
(72)【発明者】
【氏名】海原 浩平
(72)【発明者】
【氏名】堀田 敬一
【審査官】小原 正信
(56)【参考文献】
【文献】特開２０１０－１７０４４２（ＪＰ，Ａ）
【文献】特開２０１８－０４５５６５（ＪＰ，Ａ）
【文献】特開２００３－１２３１４２（ＪＰ，Ａ）
【文献】特開２０１９－１９９０６９（ＪＰ，Ａ）
【文献】特開２０１２－０３７９８７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
Ｇ１６Ｙ １０／５０
(57)【特許請求の範囲】
【請求項1】
プロセッサを備え、前記プロセッサは、
ユーザと決済センタとの間での処理の実行に関する決済の完了の確認後に当該処理を実行し、
情報処理装置で当該処理を開始する前に前記決済にて徴収した決済金額が当該処理の実行により発生した代金を上回る場合、ユーザへの返金を前記決済センタに依頼する返金処理を実施し、
前記返金処理に応じて前記決済センタからユーザへの返金が完了した旨が通知されてくると、当該返金が完了した旨を内部に保持し、
前記情報処理装置が停止した後の再起動時に、前記返金処理に応じて前記決済センタから通知されてくる当該返金が完了した旨が内部に保持されていないことが確認された場合、前記返金処理を再度実施し、
再起動時における前記返金処理に応じて前記決済センタからユーザへの返金の完了の通知を受けることによってユーザへの返金の完了を確認する、
ことを特徴とする情報処理装置。
【請求項2】
前記プロセッサは、ユーザへの返金が必要となった場合、返金がある旨を当該ユーザに通知することを特徴とする請求項１に記載の情報処理装置。
【請求項3】
前記プロセッサは、前記情報処理装置が再起動した後、前記処理の実行ログから算出される前記代金と、前記処理の実行に伴う決済用管理ログから算出される前記代金と、が一致しないことによりユーザへの返金額が決められない場合、再起動時における前記返金処理を実施せずに不確定の旨を管理者に通知することを特徴とする請求項１に記載の情報処理装置。
【請求項4】
コンピュータに、ユーザと決済センタとの間での処理の実行に関する決済の完了の確認後に当該処理を実行する機能、
前記コンピュータで当該処理を開始する前に前記決済にて徴収した決済金額が当該処理の実行により発生した代金を上回る場合、ユーザへの返金を前記決済センタに依頼する返金処理を実施する機能、
前記返金処理に応じて前記決済センタからユーザへの返金が完了した旨が通知されてくると、当該返金が完了した旨を内部に保持する機能、
前記コンピュータが停止した後の再起動時に、前記返金処理に応じて前記決済センタから通知されてくる当該返金が完了した旨が内部に保持されていないことが確認された場合、前記返金処理を再度実施する機能、
再起動時における前記返金処理に応じて前記決済センタからユーザへの返金の完了の通知を受けることによってユーザへの返金の完了を確認する機能、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【0002】
近年では、画像形成装置を利用する際、ユーザはオンライン決済を利用したり、電子マネーで決済を行ったりすることができる。画像形成装置は、決済の完了を確認してから、ユーザにより要求されたジョブの実行を開始する。また、事前に決済された決済額が、ジョブの実行により発生した金額を超える場合、返金額を算出して返金を行う技術が提案されている（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１０－１７０４４２号公報
【文献】特開２０１８－０４６４９２号公報
【文献】特開２０１８－０４６４９４号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、従来においては、返金が完了する前に装置が停止したときのリカバリ処理が用意されていなかったため、返金を完了させるためには、停止からの復旧後にユーザに何らかの操作をしてもらう必要があった。
【0005】
本発明は、ユーザと決済センタとの間での処理の実行に対する決済の完了後に情報処理装置が処理を実行したものの返金が必要になった場合、返金が完了する前に情報処理装置が停止した場合でもユーザに返金のための操作をさせることなく返金できるようにすることを目的とする。
【課題を解決するための手段】
【0006】
本発明に係る情報処理装置は、プロセッサを備え、前記プロセッサは、ユーザと決済センタとの間での処理の実行に関する決済の完了の確認後に当該処理を実行し、情報処理装置で当該処理を開始する前に前記決済にて徴収した決済金額が当該処理の実行により発生した代金を上回る場合、ユーザへの返金を前記決済センタに依頼する返金処理を実施し、前記返金処理に応じて前記決済センタからユーザへの返金が完了した旨が通知されてくると、当該返金が完了した旨を内部に保持し、前記情報処理装置が停止した後の再起動時に、前記返金処理に応じて前記決済センタから通知されてくる当該返金が完了した旨が内部に保持されていないことが確認された場合、前記返金処理を再度実施し、再起動時における前記返金処理に応じて前記決済センタからユーザへの返金の完了の通知を受けることによってユーザへの返金の完了を確認することを特徴とする。
【0007】
また、前記プロセッサは、ユーザへの返金が必要となった場合、返金がある旨を当該ユーザに通知することを特徴とする。
【0008】
また、前記プロセッサは、前記情報処理装置が再起動した後、前記処理の実行ログから算出される前記代金と、前記処理の実行に伴う決済用管理ログから算出される前記代金と、が一致しないことによりユーザへの返金額が決められない場合、再起動時における前記返金処理を実施せずに不確定の旨を管理者に通知することを特徴とする。
【0010】
本発明に係るプログラムは、コンピュータに、ユーザと決済センタとの間での処理の実行に関する決済の完了の確認後に当該処理を実行する機能、前記コンピュータで当該処理を開始する前に前記決済にて徴収した決済金額が当該処理の実行により発生した代金を上回る場合、ユーザへの返金を前記決済センタに依頼する返金処理を実施する機能、前記返金処理に応じて前記決済センタからユーザへの返金が完了した旨が通知されてくると、当該返金が完了した旨を内部に保持する機能、前記コンピュータが停止した後の再起動時に、前記返金処理に応じて前記決済センタから通知されてくる当該返金が完了した旨が内部に保持されていないことが確認された場合、前記返金処理を再度実施する機能、再起動時における前記返金処理に応じて前記決済センタからユーザへの返金の完了の通知を受けることによってユーザへの返金の完了を確認する機能、を実現させる。
【発明の効果】
【0011】
請求項１に記載の発明によれば、ユーザと決済センタとの間での処理の実行に対する決済の完了後に情報処理装置が処理を実行したものの返金が必要になった場合、返金が完了する前に情報処理装置が停止した場合でもユーザに返金のための操作をさせることなく返金することができる。
【0012】
請求項２に記載の発明によれば、返金があることをユーザに知らせることができる。
【0013】
請求項３に記載の発明によれば、自動処理では対応できない返金処理を管理者に対応させることができる。
【0015】
請求項４に記載の発明によれば、ユーザと決済センタとの間での処理の実行に対する決済の完了後にコンピュータが処理を実行したものの返金が必要になった場合、返金が完了する前にコンピュータが停止した場合でもユーザに返金のための操作をさせることなく返金することができる。
【図面の簡単な説明】
【0016】
【図1】本実施の形態における印刷システムの全体構成及び本実施の形態における画像形成装置を示すブロック構成図である。
【図2】本実施の形態における画像形成装置のハードウェア構成図である。
【図3】本実施の形態におけるジョブログ記憶部に記憶されるジョブログのデータ構成の一例を示す図である。
【図4】本実施の形態における決済管理用ジョブログ記憶部に記憶される決済管理用ジョブログのデータ構成の一例を示す図である。
【図5】本実施の形態における決済ログ記憶部に記憶される決済ログのデータ構成の一例を示す図である。
【図6】本実施の形態におけるジョブ実行処理を示すフローチャートである。
【図7】本実施の形態においてジョブが実行されているときに操作パネルに表示される画面例及び画面の遷移を示す図である。
【図8A】本実施の形態におけるジョブ実行処理を示すシーケンス図である。
【図9】本実施の形態における画像形成装置の再起動時処理を示すフローチャートである。
【図10】本実施の形態において返金に失敗したときユーザに提示する返金失敗画面の表示例を示す図である。
【図11】本実施の形態において操作パネルに表示される機械管理者向けの画面例及び画面の遷移を示す図である。
【図12】本実施の形態における画像形成装置の再起動時処理を示すシーケンス図である。
【発明を実施するための形態】
【0017】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【0018】
図１は、本実施の形態における印刷システムの全体構成及び本実施の形態における画像形成装置１０を示すブロック構成図である。図１には、画像形成装置１０と、画像形成装置１０を利用するユーザが携帯するモバイル端末２と、決済センタ３とが、ネットワーク４を介して接続される構成が示されている。
【0019】
図２は、本発明に係る情報処理装置の一例としての画像形成装置１０のハードウェア構成図である。画像形成装置１０は、印刷機能、コピー機能、スキャナ機能等各種機能を搭載した複合機であり、コンピュータ、すなわち情報処理装置を搭載した装置である。図２において、ＲＯＭ２２には、本装置の制御や電子データの送受信等に関する各種プログラムが格納されており、ＣＰＵ（プロセッサ）２１は、ＲＯＭ２２に格納されたプログラムにしたがってスキャナ２６やプリンタ２７等本装置に搭載された各種機構の動作制御を行う。ＲＡＭ２３は、プログラム実行時のワークメモリや電子データ送受信時の通信バッファとして利用される。ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２４は、スキャナ２６を使用して読み取った電子文書などを格納する。操作パネル２５は、ユーザからの指示の受け付け、情報の表示を行う。スキャナ２６は、ユーザがセットした原稿を読み取り、電子データとしてＨＤＤ２４等に蓄積する。プリンタ２７は、ＣＰＵ２１で実行される制御プログラムからの指示に従い出力用紙上に画像を印字する。ネットワークインタフェース（ＩＦ）２８は、ネットワーク４を接続し、外部装置との電子データの送受信、またブラウザ経由による本装置へのアクセスなどに利用される。アドレスデータバス２９は、ＣＰＵ２１の制御対象となる各種機構と接続してデータの通信を行う。
【0020】
図１に戻り、本実施の形態における画像形成装置１０は、ユーザインタフェース（ＵＩ）処理部１１、ジョブ実行制御部１２、決済処理部１３、制御部１４、ジョブログ記憶部１５、決済管理用ジョブログ記憶部１６及び決済ログ記憶部１７を有している。なお、画像形成装置１０は、本来、印刷機能、コピー機能等の各種機能を実行するための構成要素を有しているが、本実施の形態の説明に用いない構成要素については、図から省略している。
【0021】
ユーザインタフェース処理部１１は、操作パネル２５を機能させる。すなわち、ユーザインタフェース処理部１１は、操作パネル２５へのユーザ操作を受け付ける操作受付手段、また、各種画面を操作パネル２５に表示させる表示制御手段として機能する。ジョブ実行制御部１２は、ユーザから要求されたジョブの実行を制御する。本実施の形態では、ジョブの実行に伴い料金が発生するが、決済処理部１３は、決済センタ３と連携してユーザから料金を徴収するなど決済に関する処理を行う。また、返金が必要となった場合には、その返金処理を行う。本実施の形態において画像形成装置１０が実施する「返金処理」というのは、ユーザへの返金を決済センタ３に依頼する処理のことをいう。制御部１４は、他の構成要素１１～１３と連携して、画像形成装置１０においてジョブが実行され、またジョブの実行に伴い発生する決済処理、更に必要により返金処理が行えるよう制御する。
【0022】
図３は、本実施の形態におけるジョブログ記憶部１５に記憶されるジョブログのデータ構成の一例を示す図である。ジョブログ記憶部１５には、ジョブの実行に伴いジョブ実行制御部１２により生成されるジョブログが蓄積される。各ジョブを識別する識別情報としてのジョブＩＤに、ユーザ、実行日時、排出枚数、実行状態を対応付けて含む。ユーザには、ジョブの実行を要求したユーザの識別情報、例えばユーザＩＤやユーザ名が設定される。実行日時には、当該ジョブの実行が開始された日時が設定される。排出枚数には、当該ジョブが実行されることによって出力される用紙の枚数が積算され設定される。実行状態には、ジョブの現時点における状態が設定される。実行状態には、ジョブが開始される前（開始前）、実行中、実行中に強制終了された状態（すなわち、中止）、正常終了、正常に終了しなかった場合（異常終了）等の状態が設定される。
【0023】
図４は、本実施の形態における決済管理用ジョブログ記憶部１６に記憶される決済管理用ジョブログのデータ構成の一例を示す図である。決済管理用ジョブログ記憶部１６には、決済処理部１３がジョブ実行制御部１２から受け取ったジョブログに関する情報が決済管理用ジョブログとして保存される。決済管理用ジョブログには、基本的には、ジョブログと同様の項目が設定されればよい。ジョブＩＤ及び実行状態の項目欄は、ジョブ実行制御部１２からの情報に同期して設定される。但し、決済ログと紐付ける取引番号は、決済センタ３から受け取った情報を設定するようにしてもよい。また、後述するように、決済処理部１３には、用紙が１枚排出される度にその旨の通知がジョブ実行制御部１２から送られてくるので、決済管理用ジョブログには、その通知を受け取った日時が排出日時として記録される。つまり、決済管理用ジョブログは、ジョブ実行制御部１２からの通知を受け取る度に生成され、決済管理用ジョブログ記憶部１６に記録される。
【0024】
図５は、本実施の形態における決済ログ記憶部１７に記憶される決済ログのデータ構成の一例を示す図である。決済ログ記憶部１７には、決済及び返金に伴って決済センタ３から送られてくる情報が決済処理部１３により受け取られて保存される。決済ログは、ジョブの実行に紐付く取引毎に生成され、当該取引を識別する情報としての取引番号に、日時、決済額、決済結果及び返金手続を対応付けて含む。日時には、取引番号を受け取った日時、すなわち取引が開始された日時が設定される。決済額には、当該取引により発生する金額、すなわちユーザと決済センタ３との間でジョブの実行に関する決済金額が設定される。決済結果には、ユーザとの間で決済が完了したかどうかが設定される。返金手続には、返金の要不要が不明な状態であることを示す“－”と、返金の要不要の別と、返金が必要となった場合、ユーザとの間で返金手続が完了しているかどうかが設定される。
【0025】
画像形成装置１０における各構成要素１１～１４は、画像形成装置１０に搭載されるコンピュータと、コンピュータに搭載されたＣＰＵ２１で動作するプログラムとの協調動作により実現される。また、ジョブログ記憶部１５及び決済管理用ジョブログ記憶部１６は、ＲＡＭ２３にて実現される。ＨＤＤ２４をバックアップ用として使用してもよい。また、決済ログ記憶部１７は、ＨＤＤ２４にて実現される。あるいは、ＲＡＭ２３を用いてもよい。あるいは、外部にある記憶手段をネットワーク経由で利用してもよい。
【0026】
また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ－ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵ２１がプログラムを順次実行することで各種処理が実現される。
【0027】
モバイル端末２は、コンピュータが搭載された情報機器であり、例えば、スマートフォンやタブレット端末を想定している。後述するように、本実施の形態では、操作パネル２５に表示されるＱＲコード（登録商標）等で表される決済コードを読み取るので、モバイル端末２は、カメラ等決済コードの読取機能を備える。また、モバイル端末２は、読み取った決済コードの解析機能、決済センタ３の間で決済を行う決済機能等のアプリケーションを少なくとも有している。
【0028】
ユーザが画像形成装置１０を利用してジョブを実行する際に料金が発生するが、決済センタ３は、その際の決済、またユーザへの返金が必要となったときの返金の各手続を行うための施設である。決済センタ３には、決済及び返金を処理するための決済サーバ３１が設置されている。決済サーバ３１は、モバイル端末２及び画像形成装置１０とやり取りすることで、ユーザが画像形成装置１０を利用することに関する決済を行う。また、決済サーバ３１は、画像形成装置１０がユーザからの要求に応じてジョブを実行した結果、返金する必要が生じた場合、ユーザへの返金を行う。
【0029】
次に、本実施の形態における動作について説明する。
【0030】
本実施の形態における画像形成装置１０は、ユーザにより要求されたジョブを実行する。ここでは、成果物として印刷物を出力する印刷ジョブをジョブの例として説明する。そして、画像形成装置１０は、ジョブを実行する際に成果物の数量等に応じてユーザから料金を徴収する。そのため、画像形成装置１０は、決済が完了したことを確認できてはじめて、ユーザから要求されたジョブの実行を開始する。以下、画像形成装置１０がジョブを実行するときに実施する処理の概要について図６に示すフローチャート及び操作パネル２５に表示される画面を示す図７を用いて説明する。
【0031】
ユーザがログインして操作パネル２５に表示されるメニュー画面（図７（ａ））から印刷ボタン３０を選択して印刷設定画面（図７（ｂ））を表示させる。ユーザが印刷設定画面から所望の印刷属性を設定してスタートボタン３２を選択することでジョブの実行を指示すると、画像形成装置１０は、その実行指示を受け付ける（ステップ１１０）。そして、画像形成装置１０は、ジョブの実行に伴う決済処理を実施する（ステップ１２０）。決済処理では、決済サーバ３１が生成した決済コードを表示する決済画面（図７（ｃ））が操作パネル２５に表示される。ユーザは、モバイル端末２を用いて操作パネル２５に表示されている決済コードを読み取り、所定の手順にて決済を完了させると（ステップ１３０でＹ）、画像形成装置１０は、ジョブの実行を開始する（ステップ１４０）。ジョブの実行中、画像形成装置１０は、操作パネル２５にジョブ実行中画面（図７（ｄ））を表示した状態にする。なお、何らかの理由により決済を行わない場合（ステップ１３０でＮ）、画像形成装置１０は、ジョブを実行せずに終了する。
【0032】
画像形成装置１０は、ジョブが終了若しくはユーザが画面上の中止ボタン３３が選択されることでジョブが中止されるまでジョブを実行し（ステップ１５０でＮ）、ジョブが終了又は中止すると（ステップ１５０でＹ）、画像形成装置１０は、ジョブを実際に実行したことで発生した代金（以下、「実行額」という）を算出する（ステップ１６０）。続いて、画像形成装置１０は、決済額と実行額を比較し、決済額が実行額を上回る場合（ステップ１７０でＹ）、返済処理を実施して（ステップ１８０）、決済額と実行額の差額を返済額として返済する。返済が終了すると、画像形成装置１０は、返金額をユーザに知らせるために返金画面（図7（ｅ））を操作パネル２５に表示する。なお、決済額と実行額が一致する場合（ステップ１７０でＮ）、画像形成装置１０は、返済処理を行うことなく処理を終了し、メニュー画面（図７（ａ））を操作パネル２５に表示する。
【0033】
図７（ｅ）に示す返金画面では、返金が必要となった理由を示すステータスと、返金が正常終了したか、あるいは未完了の場合はその理由を示す返金ステータス等の情報が付加されて表示される。
【0034】
【0035】
ユーザが画像形成装置１０にログインし、操作パネル２５を操作して表示させたジョブ実行画面からジョブの実行を指示する（ステップ１１１）。画像形成装置１０におけるユーザインタフェース処理部１１がその指示を受け付けると、ジョブ実行制御部１２は、決済処理部１３にジョブの実行に伴う決済を指示する（ステップ１１２）。なお、ジョブ実行制御部１２は、指示されたジョブに対してジョブの識別情報（以下、「ジョブＩＤ」）を発行し、ジョブの実行を指示したユーザの識別情報（以下、「ユーザＩＤ」）を含むジョブログを生成してジョブログ記憶部１５に登録する。ジョブ実行制御部１２からの指示には、ジョブを指示したユーザを特定する情報（例えば、ユーザＩＤ）及びジョブＩＤと、ジョブの実行により発生する料金を算出するのに必要な情報、例えば用紙サイズ、出力枚数、白黒／カラー印刷等の印刷属性情報が含まれており、決済処理部１３は、その印刷属性情報を参照してジョブの実行に伴い発生する料金を算出する（ステップ１２１）。ここで算出された料金は、決済額に等しい。決済処理部１３は、続いて、決済額、決済するユーザ（以下、「決済者」とも言う）の識別情報を含む決済依頼情報を送信することで決済を依頼する（ステップ１２２）。また、決済処理部１３は、ジョブ実行制御部１２からの決済の指示に伴いジョブＩＤを含む決済管理用ジョブログを生成して決済管理用ジョブログ記憶部１６に登録する。
【0036】
決済センタ３における決済サーバ３１は、決済処理部１３からの依頼に応じて、決済サーバ３１へのアクセス情報、決済者及び決済額を少なくとも含む決済コードを作成する（ステップ１２３）。そして、決済サーバ３１は、決済に関する情報、具体的には、決済者、決済者との取引番号、決済額を含む決済情報を生成して内部に保存する。その後、決済サーバ３１は、決済コードを決済処理部１３へ返信する（ステップ１２４）。決済コードには、取引番号と決済額が付加されている。なお、本実施の形態では、決済センタ３が取引番号を発行するが、画像形成装置１０、例えば決済処理部１３が決済を依頼するときに取引番号を発行してもよい。
【0037】
決済処理部１３は、決済サーバ３１からの返信を受け取ると、取引番号と取引の開始日時と決済額とを含む決済ログを生成して決済ログ記憶部１７に登録する。なお、ユーザとの間の決済はまだ済んでいないので、決済ログの決済結果には、まだ済んでいない旨のフラグ情報（“未”）が初期値として設定される。また、返金手続には要不要が不明な状態なので、その旨を示す情報（“－”）が初期値として設定される。また、決済処理部１３は、ジョブ実行制御部１２から受け取ったジョブＩＤに対応する決済管理用ジョブログに取引番号を設定登録する。なお、この時点では、まだジョブが実行されていないので、決済管理用ジョブログの排出日時にはＮＵＬＬ、実行状態には開始前が設定される。
【0038】
以上のようにして、ジョブログと決済管理用ジョブログは、ジョブＩＤにより紐付けられ、決済管理用ジョブログと決済ログは、取引番号により紐付けられる。続いて、決済処理部１３は、決済コードをジョブ実行制御部１２へ送ると（ステップ１２５）、決済完了通知が決済サーバ３１から送られてくるのを待機する（ステップ１２６）。
【0039】
決済処理部１３からの決済コードを受け取ると、ジョブ実行制御部１２は、ユーザインタフェース処理部１１に指示することで、操作パネル２５に決済コードを表示させる（ステップ１２７）。
【0040】
決済コードは、例えば図７（ｃ）に示すようにＱＲコード等のカメラ等で読み取り可能なコードである。ここで、ユーザがモバイル端末２を操作し、決済コードを読み取り、決済サーバ３１にアクセスし、決済センタ３との間で決済を行う（ステップ１３１）。ユーザと決済センタ３との決済のためのやりとりは、従前からある方法で行えばよい。
【0041】
ユーザとの間で決済が完了すると、決済サーバ３１は、決済が完了した旨を決済情報に付加して内部に保存する。そして、決済サーバ３１は、決済完了通知を決済処理部１３へ送信する（ステップ１３２）。また、決済処理部１３は、決済ログの決済結果を（“未”）から決済が完了した旨を示す情報（“済”）に設定変更する。
【0042】
以上のようにして決済処理が終了すると、決済処理部１３は、ジョブの実行の開始をジョブ実行制御部１２に指示する（ステップ１４１）。決済処理部１３は、この指示するタイミングで、ジョブ実行制御部１２からのジョブの実行開始の通知を受けることなく決済管理用ジョブログの実行状態を、開始前から実行中に変更してもよい。
【0043】
ジョブ実行制御部１２は、決済処理部１３からの指示に応じてジョブの実行を開始する（ステップ１４２）。このとき、対応するジョブログの実行日時に、ジョブの実行を開始した日時を設定する。また、ジョブログの実行状態を、開始前から実行中に変更する。
【0044】
前述したように、本実施の形態では、印刷ジョブを実行することになるが、ジョブ実行制御部１２は、用紙１枚の印刷物を生成すると、ジョブログの排出枚数を１インクリメントすると共に、用紙１枚を排出した旨の通知（以下、「用紙１枚排出通知」）を決済処理部１３に行う（ステップ１４３）。
【0045】
決済処理部１３は、用紙１枚排出通知を受け取る度に、その通知を受け取った日時（以下、「排出日時」）を決済管理用ジョブログに登録する。ジョブログでは、１つのジョブに対して１レコードが登録されるが、決済管理用ジョブログには、用紙が１枚排出される度に１レコードが追加される。すなわち、複数枚の印刷物を生成する１つのジョブに対しては、複数のログが決済管理用ジョブログに記録される。なお、本実施の形態では、ジョブログと決済管理用ジョブログとでは、排出枚数の記録方法を異ならせているが、いずれかに合わせて排出枚数を同様に管理するようにしてもよい。
【0046】
ジョブが終了すると（ステップ１５１）、ジョブ実行制御部１２は、その旨を決済処理部１３に通知する（ステップ１５２）。このとき、ジョブ実行制御部１２は、ジョブログの実行状態を、終了の状況に応じて実行中から正常終了、異常終了又は中止に変更する。
【0047】
決済処理部１３は、ジョブ実行制御部１２からジョブの終了通知を受けると、決済管理用ジョブログの実行状態を、ジョブログに合わせるよう変更する。なお、決済管理用ジョブログには、複数枚の印刷物を生成するジョブに対し、複数のレコードが登録されているので、全てのレコードの実行状態を変更するようにしてもよいし、最後のレコードの実行状態のみを変更してもよい。
【0048】
決済処理部１３は、ジョブ実行制御部１２からジョブの終了通知を受けると、ジョブの実行により実際に発生した代金、すなわち実行額を算出する（ステップ１６１）。続いて、決済処理部１３は、決済ログに保存している決済額と算出した実行額とを比較する。そして、決済額が実行額を上回る場合、決済処理部１３は、所定の返金処理を行う。具体的には、決済センタ３に対して決済額と実行額との差額、すなわち返金額を指定して返金手続を依頼する（ステップ１８１）。このとき、決済処理部１３は、返金手続が必要な場合、決済ログの返金手続の項目欄に、返金手続が必要であってまだ返金手続きが完了していない旨の情報（“未”）を設定する。一方、決済処理部１３は、返金手続が不要な場合、返金手続が不要である旨の情報（“不要”）を設定する。
【0049】
決済センタ３は、返金手続依頼に応じて、返金額をユーザに返金する（ステップ１８２）。なお、返金の方法は、従前からある方法を利用してよい。返金が完了すると、決済サーバ３１は、返金が完了した旨を決済情報に付加して内部に保存する。そして、決済サーバ３１は、返金が完了した旨を決済処理部１３に通知する（ステップ１８３）。
【0050】
決済処理部１３は、決済サーバ３１から返金手続が完了した旨の通知を受けると、返金決済ログの返金手続の項目欄に、手続が完了した旨の情報（“済”）を設定すると共に、返金がある旨をジョブ実行制御部１２に通知する（ステップ１８４）。ジョブ実行制御部１２は、この通知を受けると、ユーザインタフェース処理部１１に指示することで、操作パネル２５に図７（ｅ）に示す返金画面を表示させることで、ユーザに返金がある旨を通知する（ステップ１８５）。
【0051】
本実施の形態によれば、以上のように処理することで、返金が必要な場合でも返金を受け取るために特別な操作をユーザに行わせる必要がない。すなわち、ユーザは、返金を自動的に受けることができる。
【0052】
ところで、返金が必要な場合、上記のように決済センタ３は、決済処理部１３からの依頼を受けて実施される。但し、返金手続の依頼に応じて決済センタ３が返金手続をし、その返金の完了の通知を決済処理部１３に行うまでの間に、すなわち決済センタ３によるユーザへの返金の完了を確認する前に何らかの理由により画像形成装置１０がシステムダウンして停止してしまうと、画像形成装置１０は、ユーザへの返金が正常に実施されたのかどうかわからない。
【0053】
そこで、本実施の形態においては、返金が完了する前に画像形成装置１０が停止した場合でもユーザに返金のための操作をさせることなく返金できるようにしたことを特徴としている。以下、画像形成装置１０が停止し、再起動後に実施する処理の概要について図９に示すフローチャートを用いて説明する。
【0054】
画像形成装置１０は、再起動すると、ジョブログ、決済管理用ジョブログ及び決済ログをそれぞれ各記憶部１５～１７から取得する（ステップ２１０）。続いて、画像形成装置１０は、ジョブログと決済管理用ジョブログの登録内容を比較する（ステップ２２０）。本実施の形態では、ジョブの実行に伴い排出された用紙の枚数を比較するので、決済管理用ジョブログからは当該ジョブのジョブＩＤに紐付くログの数を排出枚数として取得し、ジョブログの排出枚数と比較する。ここで、排出枚数が一致する場合（ステップ２３０でＹ）、画像形成装置１０は、決済ログの返金手続が“要（済）”であれば（ステップ２４０でＹ）、ユーザへの返金は完了しているので、返金に関する処理をする必要はない。そうでない場合（ステップ２４０でＮ）、画像形成装置１０は、排出枚数によって実行額を算出した後（ステップ２５０）、返済処理を実施する（ステップ２６０）。
【0055】
以上説明したように、本実施の形態では、画像形成装置１０の再起動後に返金処理の必要性を判断し、必要であると判断した場合に返金処理を自動的に行うようにした。
【0056】
一方、画像形成装置１０が停止した理由やタイミングによっては、ジョブログと決済管理用ジョブログそれぞれから得られる排出枚数が一致しない場合もあり得る。この場合（ステップ２３０でＮ）、実行額を正確に算出できない。すなわち、ユーザへの返金額が決められないので、ユーザへの返金の必要性が不確定である。そのため、画像形成装置１０は、ユーザへの返金の必要性が不確定であるため自動返金に失敗した旨を機械管理者に通知する（ステップ２７０）。あるいは、図１０に示す返金失敗画面を操作パネル２５に表示させて、ユーザに機械管理者に連絡を取らせるようにしてもよい。
【0057】
連絡を受けた機械管理者が取る処置について図１１に示す操作パネル２５に表示される画面の表示例を用いて説明する。
【0058】
まず、自動返金に失敗した旨の連絡を受けると、機械管理者は、画像形成装置１０にログインする。続いて、操作パネル２５に表示される図７（ａ）と同じメニュー画面（図１１（ａ））から決済一覧ボタン３５を選択して機械管理者ログイン画面（図１１（ｂ））を表示させる。機械管理者が機械管理者ログイン画面から機械管理者ＩＤ及びパスワードの認証情報を入力してログインボタン３６を選択することでログインすると、決済一覧画面（図１１（ｃ））が操作パネル２５に表示される。
【0059】
決済一覧画面には、決済ログに登録されている情報が表示される。図１１（ｃ）には、取引番号と日時と返金手続が抽出されてリスト表示される。なお、表示対象とする決済ログは、直近の所定期間内の取引や直近の所定件数の取引としたり、返金手続きが完了していない取引に絞ってもよい。
【0060】
ここで、機械管理者は、処理したい取引に対応させて表示されているアイコン３７を選択することで、当該取引の返金実行画面（図１１（ｄ））を表示させて当該取引についての返金手続を進める。前述したように、ジョブログと決済管理用ジョブログの排出枚数が合致しないことで実行額が不明な場合、正しい実行額を求めて返金実行画面から返金額を設定して返金ボタン３８を選択することで、ユーザへの返金を実施する。返金が完了すると、返金画面（図１１（ｅ））が表示される。
【0061】
次に、前述した画像形成装置１０の再起動時における処理の詳細を図１２に示すシーケンス図を用いて説明する。
【0062】
画像形成装置１０が再起動すると、決済処理部１３は、ジョブログ、決済管理用ジョブログ及び決済ログをそれぞれ各記憶部１５～１７から取得する（ステップ２１１，２１２，２１３）。なお、各記憶部１５～１７から取得する順番は、上記に限る必要はない。
【0063】
続いて、決済処理部１３は、ジョブログ及び決済管理用ジョブログそれぞれから得られる排出枚数を比較する（ステップ２２１）。
【0064】
排出枚数が一致していない場合、決済処理部１３は、正しい排出枚数が得られないため実行額を正しく算出できず、返金手続を決済センタ３に依頼できない状態にある。この場合、決済処理部１３は、ジョブ実行制御部１２に機械管理者への通知を指示し（ステップ２７１）、ジョブ実行制御部１２は、この通知に応じて管理者に通知する（ステップ２７２）。通知を受けた機械管理者は、前述したように図１１（ｄ）に示す返金画面から実行額を設定する（ステップ２７３）。ジョブ実行制御部１２は、機械管理者により設定された実行額を決済処理部１３に通知する（ステップ２７４）。決済処理部１３は、この通知に応じて決済額と実行額との差額（つまり、返金額）を指定して返金手続を依頼する（ステップ２６１）。
【0065】
一方、排出枚数が一致する場合、ジョブが正常に終了していない場合と正常に終了している場合とに分けて考えることができる。ジョブが終了しているかどうかは、ジョブログの実行状態を参照することで確認できる。
【0066】
ジョブが正常に終了していない場合、実行額が決済額に達していない可能性が高い。従って、決済処理部１３は、実行額を算出し（ステップ２５１）、決済額と実行額との差額（つまり、返金額）を指定して返金手続を依頼する（ステップ２６１）。なお、ジョブが終了していないため、決済ログの返金手続の有無は不明であることから、決済処理部１３は、決済ログの返金手続の項目欄には、初期値（“－”）が設定されたままであるが、返金手続を依頼することで、返金手続きが完了していない旨の情報（“未”）を設定する。
【0067】
なお、ジョブが正常に終了していないのにもかかわらず、決済額と実行額とが等しい場合もあり得るが、決済ログの返金手続が“要（済）”でないはずなので、決済処理部１３は、返金手続を常に依頼することになる。
【0068】
一方、ジョブが正常に終了している場合、決済ログの返金手続が“要（済）”であれば、ユーザへの返金は完了しているので、返金に関する処理をする必要はない。また、決済ログの返金手続が“－”の場合、決済処理部１３は、実行額を算出し（ステップ２５１）、返金手続を依頼する（ステップ２６１）。また、決済ログの返金手続が“要（未）”の場合、決済処理部１３は、返金手続を依頼しているが、返金手続の完了通知を決済センタ３からまだ受け取っていない。従って、決済処理部１３は、再度、実行額を算出し（ステップ２５１）、返金手続を依頼する（ステップ２６１）。
【0069】
以上説明したように、ジョブが正常に終了している場合でも返金の完了が確認できていない場合には、実行額を算出して返金手続の依頼を再度行うことになる。
【0070】
決済センタ３は、返金手続依頼に応じて、返金額をユーザに返金する（ステップ２６２）。続いて、決済サーバ３１は、返金が完了した旨を決済処理部１３に通知する（ステップ２６３）。決済処理部１３は、返金手続を依頼する際、決済ログの返金手続に“要（未）”を設定し、決済サーバ３１から返金手続完了通知を受けることで決済ログの返金手続を“要（未）”から“要（済）”に設定変更する。
【0071】
ところで、決済処理部１３が返金手続依頼をした後、返金手続完了通知を受ける前に画像形成装置１０が停止したとする。決済サーバ３１は、返金手続依頼を最初に受けたときに返金を完了させている。そして、決済サーバ３１は、返金の完了により返金手続完了通知を送っているものの、決済処理部１３は、画像形成装置１０の停止により返金手続完了通知を受け取れていない。このため、決済ログの返金手続は“要（未）”のままである。従って、決済処理部１３は、前述したように決済ログの返金手続が“要（未）”なので、返金手続を依頼することになるが、決済サーバ３１は、返金を完了させていれば、返金手続依頼を再度受けたとしてもユーザへの返金を再度行う必要がない。なお、決済サーバ３１において、ユーザへの返金が完了しているかどうかは、返金が完了した旨を内部に保存しているので判断可能である。
【0072】
以上説明したように、必要により返金手続を行うと、決済サーバ３１は、返金が完了した旨（つまり、返金手続完了通知）を決済処理部１３に通知する（ステップ２６３）。なお、上記の通り、ユーザへの返金が完了済みの場合、この時点でユーザへの返金を行っていない場合でも、決済サーバ３１は、返金が完了した旨を決済処理部１３に通知する。
【0073】
決済処理部１３は、決済サーバ３１から返金手続が完了した旨の通知を受けると、返金決済ログの返金手続の項目欄に、手続が完了した旨の情報（“済”）を設定すると共に、返金がある旨をジョブ実行制御部１２に通知する（ステップ２６４）。ジョブ実行制御部１２は、この通知を受けると、ユーザインタフェース処理部１１に指示することで、操作パネル２５に図７（ｅ）に示す返金画面を表示させることで、ユーザに返金がある旨を通知する（ステップ２６５）。
【0074】
以上説明したように、本実施の形態によれば、ユーザへの返金が必要となった場合においてユーザへの返金が完了する前に画像形成装置１０が停止した場合でも、ユーザに返金のための操作をさせることなく返金を行うことができる。
【0075】
なお、本実施の形態では、決済ログに返金手続の項目を設けて、ユーザへの返金の完了状態を確認できるようにした。ただ、画像形成装置１０において決済ログや決済ログを記憶するＨＤＤ２４等の記憶手段に障害が発生した場合には、返金の完了状態を確認することができない。この場合、決済処理部１３は、画像形成装置１０の再起動後に決済センタ３にユーザの返金の完了状態を問い合わせることによってユーザへの返金の完了状態を確認するように処理してもよい。
【0076】
また、本実施の形態では、画像形成装置１０の印刷機能を利用した印刷処理を、決済が必要な処理の一例として説明したが、これに限る必要はない。
【0077】
上記実施の形態において、プロセッサとは広義的なプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ等）や、専用のプロセッサ（例えばＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、プログラマブル論理デバイス等）を含むものである。
【0078】
また上記実施の形態におけるプロセッサの動作は、１つのプロセッサによって成すのみでなく、物理的に離れた位置に存在する複数のプロセッサが協働して成すものであってもよい。また、プロセッサの各動作の順序は上記各実施の形態において記載した順序のみに限定されるものではなく、適宜変更してもよい。
【符号の説明】
【0079】
２ モバイル端末、３ 決済センタ、４ ネットワーク、１０ 画像形成装置、１１ ユーザインタフェース（ＵＩ）処理部、１２ ジョブ実行制御部、１３ 決済処理部、１４ 制御部、１５ ジョブログ記憶部、１６ 決済管理用ジョブログ記憶部、１７ 決済ログ記憶部、２１ ＣＰＵ、２２ ＲＯＭ、２３ ＲＡＭ、２４ ＨＤＤ、２５ 操作パネル、２６ スキャナ、２７ プリンタ、２９ アドレスデータバス、３１ 決済サーバ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】