(57)【要約】【課題】ユーザの希望する受取時刻を保証することを目的とする。【解決手段】出力原稿の受取時刻と、出力原稿の種類と、印刷部数とを入力する入力手段と、入力手段で入力された出力原稿の受取時刻と、出力原稿の種類と、印刷部数とに基づいて、印刷時間と、印刷処理以外の処理に要する所要時間と予測する予測手段と、予測手段で予測された印刷時間と、所要時間とに基づいて、予約された印刷のスケジューリングを行うスケジューリング手段と、スケジューリング手段での予約された印刷のスケジューリングに基づいて、出力原稿にかかる入稿の締め切り時刻を通知する通知手段と、を有することによって課題を解決する。【選択図】図１
2012011698.tif 000002
【特許請求の範囲】
【請求項１】
出力原稿の受取時刻と、出力原稿の種類と、印刷部数とを入力する入力手段と、
前記入力手段で入力された出力原稿の受取時刻と、出力原稿の種類と、印刷部数とに基づいて、印刷時間と、印刷処理以外の処理に要する所要時間と予測する予測手段と、
前記予測手段で予測された前記印刷時間と、前記所要時間とに基づいて、予約された印刷のスケジューリングを行うスケジューリング手段と、
前記スケジューリング手段での予約された印刷のスケジューリングに基づいて、出力原稿にかかる入稿の締め切り時刻を通知する通知手段と、
を有する印刷装置。
【請求項２】
印刷装置が実行する予約された印刷のスケジューリング方法であって、
出力原稿の受取時刻と、出力原稿の種類と、印刷部数とを入力する入力ステップと、
前記入力ステップで入力された出力原稿の受取時刻と、出力原稿の種類と、印刷部数とに基づいて、印刷時間と、印刷処理以外の処理に要する所要時間と予測する予測ステップと、
前記予測ステップで予測された前記印刷時間と、前記所要時間とに基づいて、予約された印刷のスケジューリングを行うスケジューリングステップと、
前記スケジューリングステップでの予約された印刷のスケジューリングに基づいて、出力原稿にかかる入稿の締め切り時刻を通知する通知ステップと、
を含む予約された印刷のスケジューリング方法。
【請求項３】
コンピュータに、
出力原稿の受取時刻と、出力原稿の種類と、印刷部数とを入力する入力ステップと、
前記入力ステップで入力された出力原稿の受取時刻と、出力原稿の種類と、印刷部数とに基づいて、印刷時間と、印刷処理以外の処理に要する所要時間と予測する予測ステップと、
前記予測ステップで予測された前記印刷時間と、前記所要時間とに基づいて、予約された印刷のスケジューリングを行うスケジューリングステップと、
前記スケジューリングステップでの予約された印刷のスケジューリングに基づいて、出力原稿にかかる入稿の締め切り時刻を通知する通知ステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷装置、予約された印刷のスケジューリング方法及びプログラムに関する。
【背景技術】
【０００２】
印刷データを入稿せずに印刷予約したい場合、ユーザが適当に時間帯を選び、エンジンを予約するシステムがある。また、ユーザが予約した時間内までに入稿できなかった場合、所定の時間を待ってキャンセルするシステムがある。また、エンジンの待ち時間を作らず、かつ、ユーザが遅れて入稿した際に邪魔にならないように、待たされているジョブを小さく分割して実行するシステムがある。また、印刷予定物の種類と枚数とを指定することで、印刷資源を保証するシステムがある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第４１９４６１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記の制御方法には以下の問題点がある。ユーザは出力開始予定時刻を指定するが、受取時刻を保証することができなかった。その理由は、ユーザが入稿前に予約を行うため、入稿データが確定せず、時間の見積もりができないことにある。
【０００５】
本発明はこのような問題点に鑑みなされたもので、ユーザの希望する受取時刻を保証することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明の印刷装置は、出力原稿の受取時刻と、出力原稿の種類と、印刷部数とを入力する入力手段と、前記入力手段で入力された出力原稿の受取時刻と、出力原稿の種類と、印刷部数とに基づいて、印刷時間と、印刷処理以外の処理に要する所要時間と予測する予測手段と、前記予測手段で予測された前記印刷時間と、前記所要時間とに基づいて、予約された印刷のスケジューリングを行うスケジューリング手段と、前記スケジューリング手段での予約された印刷のスケジューリングに基づいて、出力原稿にかかる入稿の締め切り時刻を通知する通知手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、通知された入稿の締め切り時刻をユーザが守ることによって、ユーザの希望する出力原稿の受取時刻を保証することができる。
【図面の簡単な説明】
【０００８】
【図１】印刷システムのシステム構成の一例を示す図である。
【図２】ジョブ生成部の機能構成の一例を示す図である。
【図３】分割部の機能構成の一例を示す図である。
【図４】スケジュール部の機能構成の一例を示す図である。
【図５】処理時間予測部がもつ処理平均時間のテーブルの一例を示す図である。
【図６】タイムテーブルがもつタイムテーブルと、スケジュールリスト、空き時間リストと予約ジョブの情報と、の一例を示す図である。
【図７】予約を行う際の処理の一例を示すフローチャートである。
【図８】プリント予約画面の一例を示す図である。
【図９】予約受領画面の一例を示す図である。
【図１０】ユーザ情報の入力画面の一例を示す図である。
【図１１】予約失敗画面の一例を示す図である。
【図１２】入稿終了時刻を提示する画面の一例を示す図である。
【図１３】入稿締め切り時刻所定時間前であることを通知するメールの一例を示す図である。
【図１４】予定入稿枚数を上回る入稿をした場合、ユーザに入稿締め切り時刻の変更を問うメッセージの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、印刷システムのシステム構成の一例を示す図である。
印刷システムは、ＵＩ端末１と、印刷装置２と、スケジュール部３と、から構成される。なお、スケジュール部３は、印刷装置２と通信可能であれば印刷装置２と別体のコンピュータで実現してもよいが、以下では説明の簡略化のため、印刷装置２に含まれるものとして説明を行う。なお、スケジュール部３や、コントロール部２１、レンダリング部２２、プリンタエンジン部２３を構成する各機能は、印刷装置２のＣＰＵが、印刷装置２のメモリ等に記憶されているプログラムを実行することによって実現される。
【００１１】
（通常印刷）
ＵＩ端末１は、ユーザから入稿データを受領することができ、パソコンや携帯、ＫＩＯＳＫ端末で実現する。ＵＩ端末１で受領した入稿データは、印刷装置２に送信される。
入稿データは、出力原稿のブックレットやフォトアルバム等の種類、及び印刷部数等を含む。
印刷装置２は、コントロール部２１、レンダリング部２２、プリンタエンジン部２３で構成される。ＵＩ端末１から受信したデータは、コントロール部２１内の、受信部２１１で受信される。受信部２１１は、ジョブ生成部２１２に受領したデータ、コマンドを通知する。ジョブ生成部２１２は、受信部２１１から受け取った情報に従って、ジョブを生成する。ジョブは、ジョブの処置に関するジョブ情報を所有している。ジョブ生成部２１２は、生成したジョブを分割部２１３に送る。分割部２１３は、受け取ったジョブデータをページ単位のレベルに分割する。ページ単位に分割されたジョブは、レンダリング管理部２１４に送られる。レンダリング管理部２１４は、受け取ったジョブにレンダリングが必要な場合は、通信部２１５を通してレンダリング部２２に送信する。レンダリングが必要ない場合は、スプール部２１６にページデータをスプールする。レンダリング部２２は、コントロール部２１からのデータを通信部２２１で受信する。受信したデータは、変換処理部２２２にて画像処理がかけられ、企業マーク等、次以降のページからも、何度も参照されるオブジェクトに関しては、オブジェクト保存部２２３に保存される。画像処理が終了したデータは、通信部２２１を通して再びコントロール部２１に送信される。通信部２１５は、受領したデータをレンダリング管理部２１４に通知し、レンダリング管理部２１４は、画像処理が終了したデータをスプール部２１６に保存する。スプール部２１６には貯められた画像は、プリンタエンジン部２３に送信され、印刷が行われる。
【００１２】
（印刷待ち）
ＵＩ端末１は、ユーザから入稿データを受領する。入稿データは、受信部２１１で受信され、ジョブ生成部２１２に送られる。図２は、ジョブ生成部の機能構成の一例を示す図である。ジョブ生成部２１２は、ジョブ管理部３１、ジョブキュー３２、受信データスプール部３３から構成される。ジョブ管理部３１は、現在のジョブの実行状況を管理している。現在他のジョブが多数動いており、ジョブの投入を待ったほうがいいと判断した場合、ジョブ管理部３１は、受信したデータに対応するジョブを生成した後、ジョブをジョブキュー３２に積む。ジョブがジョブキュー３２に積まれている間に受信したジョブデータは、受信データスプール部３３にスプールされ、ジョブキュー３２に積まれたジョブとの関連付けがされる。先行していたジョブが終了した後、ジョブ管理部３１は、ジョブキュー３２に積まれていたジョブを取り出し、分割部２１３に送信して印刷処理を開始する。
【００１３】
（通常予約受付）
ＵＩ端末１は、ユーザから入稿データと受取予定日時を受け付ける。入稿データ、受取予定日時は受信部２１１で受信され、ジョブ生成部２１２に送られる。ジョブ生成部２１２は、受信したデータを分割部２１３に送信する。図３は、分割部の機能構成の一例を示す図である。分割部２１３は、ページ分割部４１とページ分割見積もり部４２とからなる。通常印刷時はページ分割部４１でデータが分割されレンダリング管理部２１４に送られる。予約設定時はページ分割見積もり部４２にて、ページ構成の情報を受信データから検出し、ジョブ生成部２１２に通知する。ジョブ生成部２１２は、ページ構成と受取予定日時とをスケジュール部３に通知する。図４は、スケジュール部の機能構成の一例を示す図である。スケジュール部３は、タイムテーブル５３と処理時間予測部５１とタイマ５２とから構成される。ジョブ生成部２１２からページ構成を受け取ったタイムテーブル５３は、処理時間予測部５１へ、受領したページ構成通知する。処理時間予測部５１は、出力原稿の種類、印刷部数でジョブ処理にどれだけ印刷時間がかかるか、過去の実例からその最大値、最小値、平均値を保持しており（図５）、そのうちの１つを用いて与えられたページ構成でかかる印刷時間を算出する。処理時間予測部５１は、ページ構成に従って、図５で与えられた、パース時間、レンダリング時間、印刷時間、仕上げ時間を加算し、印刷時間を算出する。部数指定があった場合は、処理時間予測部５１は、印刷時間に仕上げ等の印刷処理以外の所要時間を部数分加算する。処理時間予測部５１から予測結果を受け取ったタイムテーブル５３は、予定を組み込めるか判断する。判断の手法は、現在から受取予定日時までの空き時刻を検索し、その総計が予測時間より多い場合は予約受理、少ない場合は予約不受理と判断する（図６、図７）。予約の受理・不受理は、ユーザ通知部２１７を通してユーザに通知される。ユーザ通知部２１７が通知する先は、ＵＩ端末１やメールである。受付された予約ジョブは、タイムテーブル５３にジョブＩＤと処理開始時間とが登録され、タイマ５２へ開始時刻に通知するよう設定される。
印刷処理以外の処理としては、製本、袋詰め、配送等を含む。
【００１４】
（予約スケジュール決定方法）
図６、７の予約方法について詳しく実施例を述べる。
図６は、タイムテーブルがもつタイムテーブルと、スケジュールリスト、空き時間リスト（空きリスト）と予約ジョブの情報と、の一例を示す図である。タイムテーブル５３は、図６に示すスケジュールリストを内部で保有している。予約が行われる際、ジョブ生成部２１２は、タイムテーブル５３に予約したいジョブの情報を通知する。図６では予約ジョブ１、予約ジョブ２、予約ジョブ３が予約したいジョブにあたる。なお、空きリストにおいて、要旨変更時の時間は−０．５ｈである。また、選択の優先順位は、要旨の変更回数＞空きの利用戸数である。
図７は、予約を行う際の処理の一例を示すフローチャートである。上述したように、処理時間予測部５１は、予約ジョブの処理時間を算出する（Ｓ１０１）。また、処理時間予測部５１は、タイムテーブル５３から空き時間を算出する（Ｓ１０２）。タイムテーブル５３は、受け取った予約ジョブの予測処理時間が、スケジュールの空き時間より短いか長いかを確認する（Ｓ１０３）。予約ジョブの予測処理時間が空き時間の総和より長い場合、ユーザ通知部２１７は、ユーザに指定された受取時刻での予約は受け付けられない旨を通知する（Ｓ１０６）。処理時間予測部５１は、空き時間を、図６でリストになっているように、既に予約されているジョブによって分断する（Ｓ１０５）。タイムテーブル５３は、リストアップされた空き時間の中で、予測処理時間より長いものを更に抽出する（Ｓ１０４）。
次に、タイムテーブル５３は、前後の予約ジョブと用紙交換がないか判断し（Ｓ１０７）、用紙交換が発生する場合は、前ジョブとの用紙交換（Ｓ１０８）、後続ジョブとの用紙交換（Ｓ１０９）を判断する。処理時間予測部５１は、該当する一番短い空き時間で予約を行う（Ｓ１１０）。エンジンが止まる時間が増えてしまうため、用紙交換はなるべく起こらないようにスケジューリングするといい。全ての空き時間が予測処理時間よりも短い場合は、処理時間予測部５１は、ジョブを分裂させ、Ｓ１０４から繰り返す。ジョブの分割手法は、単純にページ数で２分割してもいいし、空き時間に合わせてページ分割の粒度を細かくしてもいい。
【００１５】
（予約印刷開始）
タイマ５２は、登録された時刻になると、予約印刷を開始する時刻になったことをタイムテーブル５３に通知する。タイムテーブル５３は、ジョブ生成部２１２にジョブを開始するように通知する。ジョブ生成部２１２は、通知されたジョブＩＤに従い、ジョブ処理を進める。
【００１６】
（入稿データがない状態での予約）
図８は、プリント予約画面の一例を示す図である。ＵＩ端末１は、図８の予約画面にて、入稿データがない状態で予約を受け付ける。図８で入力が必須な項目は、デジカメ写真サイズ、アルバム種別といった出力予定物の種類、その受取希望日時、入稿予定時刻である。部数、枚数は予定のものであり、実際の入稿データと異なっていてもいい。但し、予約段階で入力したもの以上の入稿をする場合、受取時間は保証されない。ユーザが部数と枚数とを入力しなかった場合、システムが所定の値を決めて、ユーザに提示してもいい。ユーザが図８のＯＫを選択した場合、ＵＩ端末１の情報は受信部２１１を通してジョブ生成部２１２へ送信される。ジョブ生成部２１２は、スケジュール部３へ、ページ数、部数、出力予定物の種類、受取希望時刻を通知する。スケジュール部３は、前記計算方法で、予測処理時間を処理時間予測部５１で算出し、タイムテーブル５３に通知する。タイムテーブル５３が予約を許可した場合は、タイマ５２に開始時刻を登録し、その開始時刻を最終入稿時刻としてユーザ通知部２１７へ送信する。ユーザ通知部２１７は、ＵＩ端末１に図９のような予約受領画面を表示する。図９は、予約受領画面の一例を示す図である。図９の「あと何枚印刷できます」という表示は、入稿締め切り時刻まで余裕があれば、表示しなくてもいい。ユーザに求める入稿時刻の締め切りは、タイムテーブル５３から通知された印刷時刻でなく、ユーザが入力した入稿予定時刻でもいい。タイムテーブル５３の予約スケジュール決定方法は、図６、７のシーケンスと基本的に同じであるが、空き時間の検索範囲が、ユーザの入力した予定入稿時刻から受取時刻までとなる。予約が成立した場合、ユーザ通知部２１７は、続けてユーザが入稿する際に必要な、ＩＤやＰＡＳＳを提示する（図１０）。図１０は、ユーザ情報の入力画面の一例を示す図である。タイムテーブル５３が予約を許可しなかった場合は、不受理の旨をユーザ通知部２１７へ通知する。その際、ユーザ通知部２１７は、図１１のように、受取枚数の限界をユーザに提示してもいい。図１１は、予約失敗画面の一例を示す図である。
【００１７】
（入稿方法）
ユーザは、パソコンやＫＩＯＳＫ端末といったＵＩ端末１で入稿データを送信する。その際、ＩＤとＰＡＳＳとを用いて認証を行う。入稿データは、受信部２１１で受信され、ジョブ生成部２１２に通知される。ジョブ管理部３１は、ユーザＩＤにより、入稿データが予約のものだと判断した場合、受信データスプール部３３に入稿データを蓄積し、ジョブキュー３２に積まれているジョブと予約番号、受信データスプール部３３のスプール領域とを関連付ける。入稿データ受信の終了を確認して、ジョブ生成部２１２は、分割部２１３を通して、入稿データのページ構成を把握する。ジョブ生成部２１２は、入稿データのページ構成をスケジュール部３に通知する。スケジュール部３は、実際に入稿されたデータに関して、処理時間予測部５１で予測処理時間を算出し、確保しているスケジュール時間との差分を取る。タイムテーブル５３は、差分の時間と出力予定物の種類とを用いて印刷可能枚数を算出し、ユーザ通知部２１７に通知する。ユーザ通知部２１７は、図１２のように、ユーザに入稿終了時刻を提示する。また、ユーザ通知部２１７は、同時に入稿データの終了を選択する表示をしてもいい。ＵＩ端末１から受信部２１１を経由して、ジョブ生成部２１２に入稿終了が通知された際、ジョブ生成部２１２のジョブ管理部３１は、同ＩＤによる新規入稿の受け付けを締め切る。入稿が終了した後、スケジュール部３で予約ジョブを先倒しして実行するように判断してもいいし、タイマ５２からの印刷開始を待ってもよい。
【００１８】
（部数変更方法）
ＵＩ端末１は、部数変更を受け付けることができる。ＵＩ端末１は、全ての入稿データに一律に部数を設定することも、それぞれの入稿データに部数を設定することも可能である。ＵＩ端末１から設定された部数変更情報は、受信部２１１、ジョブ生成部２１２を経由し、スケジュール部３へ通知される。スケジュール部３は、更新された部数情報を基に、図６、７の手順で予測処理時間を再計算し、入稿方法の際と同様に、印刷可能枚数を算出、ＵＩ端末１に表示する。指定された部数による予測処理時間が確保しているスケジュール時間より大きかった場合、その情報はスケジュール部３からユーザ通知部２１７を通しＵＩ端末１に通知される。ＵＩ端末１は、部数変更を行うと受取時刻が保証されない旨を表示して部数変更を受け付けない。部数変更を受け付けるシステムの場合は、ユーザに受取時刻の保証を破棄させる。その結果、予約の破棄・タイムテーブルの解放が行われ、予約ジョブは、ユーザから入稿終了の通知がきた後、通常印刷ジョブのようにふるまう。
【００１９】
（入稿締め切り時刻前のユーザへの通知）
タイマ５２は、入稿時刻の締め切りの所定時間前になったら、ユーザ通知部２１７に入稿締め切り時刻所定時間前であることを通知する。ユーザ通知部２１７は、ユーザにメールを送信する（図１３）。図１３は、入稿締め切り時刻所定時間前であることを通知するメールの一例を示す図である。ユーザが入稿時刻を伸ばしたい場合は、部数変更方法の際と同様に、受取時刻の保証を破棄させる。
【００２０】
（入稿締め切り時刻のユーザへの通知と印刷開始）
タイマ５２は、入稿締め切り時刻になったら、ユーザ通知部２１７に入稿の締め切りを通知し、タイムテーブル５３へ印刷の開始時間がきたことを通知する。タイムテーブル５３以降の処理は、前述の予約印刷開始と同様に行う。
【００２１】
（入稿データ多数による入稿締め切り時刻の変更）
ユーザが予定入稿データ枚数を、入稿締め切り時刻前に入稿した場合、ユーザは、既に入稿したデータを削除して新規の写真を追加するか、入稿締め切り時刻を前倒しして、更に入稿を続けるか選択することができる（図１４）。図１４は、予定入稿枚数を上回る入稿をした場合、ユーザに入稿締め切り時刻の変更を問うメッセージの一例を示す図である。その時点から、処理時間予測部５１は、現在の入稿締め切り時刻までの間にある空き時間を求め、所定の割合時間を前倒ししたものを新しい入稿締め切り時刻としてもいい。ユーザには、新しい入稿締め切り時刻と、その間に受付可能な枚数と、を提示する。
【００２２】
以上、上述した実施形態によれば、ユーザの希望する受取時刻を保証することができる。また、写真店店頭サービスされている、お急ぎ印刷を保証することができる。当日、お急ぎ印刷で持ち込んだ際に、必ず印刷できる保証を得ることができ、同窓会、結婚式等、閉会時に写真を渡す個人向けサービスを実現する。また、グループで共有する大判印刷機の利用予約方法としても適用することができる。
【００２３】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２４】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００２５】
３    スケジュール部
５１  処理時間予測部
【図１】
2012011698.tif 000003
【図２】
2012011698.tif 000004
【図３】
2012011698.tif 000005
【図４】
2012011698.tif 000006
【図５】
2012011698.tif 000007
【図６】
2012011698.tif 000008
【図７】
2012011698.tif 000009
【図８】
2012011698.tif 000010
【図９】
2012011698.tif 000011
【図１０】
2012011698.tif 000012
【図１１】
2012011698.tif 000013
【図１２】
2012011698.tif 000014
【図１３】
2012011698.tif 000015
【図１４】
2012011698.tif 000016