(57)【要約】【課題】  低いコストで高い精度のプルーフを行うことを可能にする技術を提供する。【解決手段】  本発明によれば、サーバ及び画像形成装置と通信可能な情報処理装置であって、印刷対象データと、前記画像形成装置の特性を示すデバイス情報を記憶する記憶手段と、プリント条件を含む指示を入力する指示入力手段と、前記プリント条件と前記デバイス情報に基づいて決定される、前記画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成手段と、前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出し、該画像形成装置にプリントを実行させる制御手段と、前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出手段と、を備えることを特徴とする情報処理装置が提供される。【選択図】  図８
2007122092.tif 000002
【特許請求の範囲】
【請求項１】
サーバ及び画像形成装置と通信可能な情報処理装置であって、
印刷対象データと、前記画像形成装置の特性を示すデバイス情報を記憶する記憶手段と、
プリント条件を含む指示を入力する指示入力手段と、
前記プリント条件と前記デバイス情報に基づいて決定される、前記画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成手段と、
前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出し、該画像形成装置にプリントを実行させる制御手段と、
前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出手段と、を備えることを特徴とする情報処理装置。
【請求項２】
前記画像形成装置によるプリントの結果を承認するか否かの選択を受け付ける受付手段を更に備え、
前記送出手段は、プリントの結果の承認が選択された場合に、前記送出を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記プリント条件情報には印刷／加工体裁情報が含まれることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記画像形成条件情報には、前記デバイス情報と、前記プリントにおいて使用されたプリンタドライバの情報と、の少なくともいずれかが含まれることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記デバイス情報には、前記画像形成装置に保持されているフォント情報と、前記プリントにおいて行われたフォント置換情報と、前記プリントにおいて使用された用紙情報と、前記プリントにおける画像欠け幅情報と、前記プリントにおけるキャリブレーション状況情報と、前記プリントにおいて使用されたカラープロファイル情報と、デバイス種別情報と、前記画像形成装置に装着されたフィニッシング装置の種別情報と、の少なくともいずれかが含まれることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記送出手段は、更に、該印刷データを前記サーバへ送出することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記印刷データはＰＤＬデータであることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
前記制御手段は、更に、所定の画像読取装置に前記プリントの結果を読みとらせ、該読み取りの結果を取得する取得手段を更に備え、
前記送出手段は、更に、取得された前記読み取りの結果を前記サーバへ送出することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
【請求項９】
情報処理装置及びサーバと通信可能な画像形成装置であって、
前記情報処理装置から印刷データを受信する受信手段と、
前記印刷データに基づいて記録媒体に画像形成を行う画像形成手段と、
前記画像形成手段により画像が形成された前記記録媒体から、画像形成の結果を読みとる画像読み取り手段と、
前記画像形成に係る画像形成条件と、前記画像形成読み取り手段において読みとられた前記画像形成の結果を前記サーバへ送出する送出手段と、を備えることを特徴とする画像形成装置。
【請求項１０】
更に、
前記画像形成の条件に係る指示を入力する指示入力手段と、
入力された前記指示に基づいて前記画像形成手段における前記画像形成を調整する調整手段と、を備えることを特徴とする請求項９に記載の画像形成装置。
【請求項１１】
外部装置及び画像形成装置と通信可能な情報処理装置であって、
プレプルーフプリント条件情報に対応する、前記画像形成装置における画像形成の条件を示す画像形成情報を記憶する記憶手段と、
外部装置から、印刷対象データ、プリント条件を示す条件情報、プレプルーフプリント条件情報を受信する受信手段と、
前記受信手段において受信された前記プレプルーフプリント条件情報に対応する前記画像形成情報を前記記憶手段から取得する取得手段と、
前記印刷対象データと、前記条件情報と、取得された前記画像形成情報と、に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出して、該画像形成装置に画像形成処理を実行させる制御手段と、を備えることを特徴とする情報処理装置。
【請求項１２】
第１の画像形成装置と通信可能な情報処理装置と、第２の画像形成装置と通信可能なサーバと、を有する情報処理システムであって、
前記情報処理装置は、
印刷対象データと、前記第１の画像形成装置の特性を示すデバイス情報を記憶する記憶手段と、
プリント条件を含む指示を入力する指示入力手段と、
前記プリント条件と前記デバイス情報に基づいて決定される、前記第１の画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成手段と、
前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記第１の画像形成装置へ送出し、該第１の画像形成装置にプリントを実行させる制御手段と、
前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出手段と、を備え、
前記サーバは、
前記情報処理装置から、前記印刷対象データと、前記プリント条件情報と、前記画像形成条件情報とを受信する受信手段と、
前記印刷対象データと、前記プリント条件情報と、前記画像形成情報と、に基づいて印刷データを生成し、当該印刷データを前記第２の画像形成装置へ送出して、該第２の画像形成装置に画像形成処理を実行させる制御手段と、を備えることを特徴とする情報処理システム。
【請求項１３】
印刷対象データと前記画像形成装置の特性を示すデバイス情報とを記憶する記憶手段を備え、サーバ及び画像形成装置と通信可能な情報処理装置の制御方法であって、
プリント条件を含む指示を入力する指示入力工程と、
前記プリント条件と前記デバイス情報に基づいて決定される、前記画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成工程と、
前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出し、該画像形成装置にプリントを実行させる制御工程と、
前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項１４】
情報処理装置及びサーバと通信可能な画像形成装置の制御方法であって、
前記情報処理装置から印刷データを受信する受信工程と、
前記印刷データに基づいて記録媒体に画像形成を行う画像形成工程と、
前記画像形成工程において画像が形成された前記記録媒体から、画像形成の結果を読みとる画像読み取り工程と、
前記画像形成に係る画像形成条件と、前記画像形成読み取り工程において読みとられた前記画像形成の結果を前記サーバへ送出する送出工程と、を備えることを特徴とする画像形成装置の制御方法。
【請求項１５】
プレプルーフプリント条件情報に対応する前記画像形成装置における画像形成の条件を示す画像形成情報を記憶する記憶手段を備え、外部装置及び画像形成装置と通信可能な情報処理装置の制御方法であって、
外部装置から、印刷対象データ、プリント条件を示す条件情報、プレプルーフプリント条件情報を受信する受信工程と、
前記受信手段において受信された前記プレプルーフプリント条件情報に対応する前記画像形成情報を前記記憶手段から取得する取得工程と、
前記印刷対象データと、前記条件情報と、取得された前記画像形成情報と、に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出して、該画像形成装置に画像形成処理を実行させる制御工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項１６】
コンピュータを請求項１乃至８のいずれか、又は、請求項１１に記載の情報処理装置として機能させるためのプログラム。
【請求項１７】
請求項１６に記載のプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク経由でプリントサービスを提供する技術に関し、特にプリント結果のプレプルーフを行う技術に関する。
【背景技術】
【０００２】
従来より、インターネットやイントラネット等のネットワークを経由して各種のプリントサービスを提供する技術が知られている。このプリントサービスを使う場合、発注者（ユーザ）は例えば、オフィスの自分のＰＣからＷｅｂブラウザなどを用いて、印刷原稿をネットワーク上のプリントサービスサーバにアップロードし、様々な印刷／加工体裁や配送体裁を指定して発注する。一方、プリントサービスの出力拠点のオペレータは、受注した印刷原稿をプリントサービスサーバからダウンロードし、指示された印刷／加工体裁に従って印刷及び製本加工を行い、指示された配送体裁で配送を行い、課金請求処理を行う。このプリントサービスの出力拠点は、イントラネット上のサービスの場合には、発注者のオフィスと近い場合もあるが、一般的には、発注者のオフィスとは離れた場所にあることが多い。
【０００３】
従来、このようなネットワーク上で提供されるプリントサービスに電子的に発注を行う場合、発注者が意図した印刷結果とプリントサービスの出力拠点における実際の印刷結果とが食い違う場合がある。この差異としては、例えば、印刷された色が発注者の意図とは異なっていたり、使われたフォントが化けていたり、印刷されたページのレイアウトが発注者の意図とは異なっていたり、周辺部の画像が欠けていたりすること等が含まれる。
【０００４】
このような食い違いを防止するために、従来のプリントサービスでは、プリントサービスの出力拠点における印刷結果を発注者が確認するプルーフ工程を実施している場合が多い。従来のプリントサービスにおいてとられていたプルーフの方式は以下の３つに大別することができる。
（方式１）現物によるプルーフ方式：
受注側は、受注後に、出力拠点において、印刷原稿を指示された印刷体裁に従って１部数だけ実際に印刷し、指示された加工体裁にしたがって製本加工も行い、その製本結果（現物）を物理的搬送手段で発注者に送付する。発注者は、送付されたプリント結果の現物を確認する。発注者のＯＫが取れた場合、受注側は残りの部数の処理を行う。
（方式２）発注者側で作成されたＰＤＦによるプルーフ方式：
発注前に、発注者側のＰＣ内で印刷原稿からＰＤＦ等を作成し、発注者が自分のＰＣのディスプレィ上でそれを目視確認する。そして、発注者はそのＰＤＦ等を受注側に入稿する。
（方式３）受注側で作成されたＰＤＦによるプルーフ方式：
受注側は、受注後に、出力拠点等において印刷原稿を実際に印刷した場合の印刷結果に対応するＰＤＦ等を作成し、そのＰＤＦ等を発注者側に電子的に送付する。発注者は自分のＰＣのディスプレィ上でＰＤＦ等を確認する。発注者のＯＫが取れた場合、受注側は、指示された印刷体裁、加工体裁に従って、所定数の印刷、製本処理を行う。
【０００５】
例えば特許文献１には、受注者側で作成された校正画像データを発注者の端末機に送信し、該校正画像データの確認を行う記載がある。
【特許文献１】特開２０００−１５５６６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来のプルーフ方式においては、プルーフに要するコストとプルーフの精度にトレードオフがあり、低いコストで高い精度のプルーフを行うことができなかった。
【０００７】
上記従来例において、方式１の現物によるプルーフ方式は、実際の印刷結果で確認するので、発注者が意図と実際の印刷結果との食い違いを最小限に抑えることができる。しかし、物理的搬送手段で印刷結果を送付する必要があるので、プルーフを行うために時間がかかるという問題がある。この問題は実際の印刷結果が発注者の意図と異なり、印刷条件などを修正して再度発注を行う場合に特に顕著である。再度発注を行う場合は、更に、発注者の意図と異なる印刷物を実際に作成するのに要したコストが無駄となってしまう。
【０００８】
また、方式２、３のＰＤＦによるプルーフ方式は、発注前に確認を行えるという利点があるものの、発注側のディスプレィが出力する表示の特性と、出力拠点のデバイスが実際に印刷を行って得られる印刷結果とは一般に一致しない。このため、発注者が確認した画像と実際に印刷された結果とは多くの場合に異なってしまう。また、ＰＣのディスプレィにＰＤＦ等を表示する方式においては製本の結果を十分再現することができない。
【０００９】
なお、方式３の受注側で作成されたＰＤＦによるプルーフ方式は、出力拠点側において、実際に印刷を行うデバイスに依存したＰＤＦを作成可能であるので、方式２よりも印刷結果とＰＤＦファイルの内容を近づけることができる。しかし、依然として発注側のディスプレィの表示と実際の印刷結果とには相違点がある。また、出力拠点側で受注後にプルーフ用ＰＤＦを作成した後に、発注者に確認させる工程が入るので、プルーフを行うために時間がかかってしまう。
【００１０】
本発明は上記問題に鑑みなされたものであり、低いコストで高い精度のプルーフを行うことを可能にする技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、
サーバ及び画像形成装置と通信可能な情報処理装置であって、
印刷対象データと、前記画像形成装置の特性を示すデバイス情報を記憶する記憶手段と、
プリント条件を含む指示を入力する指示入力手段と、
前記プリント条件と前記デバイス情報に基づいて決定される、前記画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成手段と、
前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記画像形成装置へ送出し、該画像形成装置にプリントを実行させる制御手段と、
前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出手段と、を備える。
【００１２】
また、本発明による画像形成装置は以下の構成を備える。即ち、
情報処理装置及びサーバと通信可能な画像形成装置であって、
前記情報処理装置から印刷データを受信する受信手段と、
前記印刷データに基づいて記録媒体に画像形成を行う画像形成手段と、
前記画像形成手段により画像が形成された前記記録媒体から、画像形成の結果を読みとる画像読み取り手段と、
前記画像形成に係る画像形成条件と、前記画像形成読み取り手段において読みとられた前記画像形成の結果を前記サーバへ送出する送出手段と、を備える。
【００１３】
また、本発明による情報処理システムは以下の構成を備える。即ち、
第１の画像形成装置と通信可能な情報処理装置と、第２の画像形成装置と通信可能なサーバと、を有する情報処理システムであって、
前記情報処理装置は、
印刷対象データと、前記第１の画像形成装置の特性を示すデバイス情報を記憶する記憶手段と、
プリント条件を含む指示を入力する指示入力手段と、
前記プリント条件と前記デバイス情報に基づいて決定される、前記第１の画像形成装置による画像形成に係る条件を示す画像形成条件情報を生成する生成手段と、
前記印刷対象データ、前記画像形成に係る条件に基づいて印刷データを生成し、当該印刷データを前記第１の画像形成装置へ送出し、該第１の画像形成装置にプリントを実行させる制御手段と、
前記印刷対象データ、前記プリント条件を示すプリント条件情報、前記画像形成条件情報を、前記サーバへ送出する送出手段と、を備え、
前記サーバは、
前記情報処理装置から、前記印刷対象データと、前記プリント条件情報と、前記画像形成条件情報とを受信する受信手段と、
前記印刷対象データと、前記プリント条件情報と、前記画像形成情報と、に基づいて印刷データを生成し、当該印刷データを前記第２の画像形成装置へ送出して、該第２の画像形成装置に画像形成処理を実行させる制御手段と、を備える。
【発明の効果】
【００１４】
本発明によれば、低いコストで高い精度のプルーフを行うことを可能にする技術を提供することができる。
【発明を実施するための最良の形態】
【００１５】
本実施形態に係る構成においては、発注前に発注者側のローカルプリンタを使用してオーダする原稿を印刷し、この印刷結果に基づいてプルーフを行う。そして、このプルーフ条件（ローカルプリンタの型番等を含む）、プルーフ結果等の情報を、原稿データと合わせてプリントサービスに入稿する。これにより、発注者は発注前に簡易かつ十分なプルーフ確認をできる一方で、受注者はプルーフ条件やプルーフ結果等の情報に基づいて発注者の意図する印刷、製本結果に非常に近い印刷、製本を行うことができる。従って、発注者が意図した印刷結果とプリントサービスの出力拠点における実際の印刷結果との食い違いを非常に小さくすることができる。即ち、高い精度のプルーフを行うことができる。また、プルーフ工程は基本的に発注者側のみで行うため、プルーフに要するコストは小さい。
【００１６】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００１７】
＜＜第１実施形態＞＞
（システム構成）
図１は、プリントサービス発注システムの全体構成図である。図１のように、プリントサービス発注システムにおいては、発注者のオフィス等に存在する発注（者）ＰＣ（Personal Computer）１と受注Ｗｅｂサーバ３とが、ネットワーク２を介して接続されている。ネットワーク２には、イントラネット、インターネット等が含まれる。発注者は、発注ＰＣ１から受注Ｗｅｂサーバ３に対し、ネットワーク２を経由して、プリントサービスを含む後述する様々なサービスの発注を行う。この時、発注者情報、スキャン体裁、印刷体裁、製本加工体裁、配送体裁の指定、印刷用の電子データ等を含むオーダ（発注、注文）情報が、ネットワーク２を経由して、受注Ｗｅｂサーバ３に送られる。また、スキャンサービスやコピーサービスを利用する場合の紙原稿や、印刷サービス用の電子データが格納されたＣＤ−ＲＯＭなどのメディアが、郵送（社内メール便を含む）などを含む物理的搬送手段１０により、出力拠点（出力拠点サーバ４）に送られる。
【００１８】
受注Ｗｅｂサーバ３は発注ＰＣ１から受け取ったオーダ情報に基づいてオーダを管理する。受注Ｗｅｂサーバ３は所定の通信手段を介して出力拠点サーバ４に接続されており、受け取ったオーダ情報に基づいて出力拠点サーバ４にオーダ情報を送出する。
【００１９】
出力拠点サーバ４には、例えば、オペレータのＰＣ９ａ、９ｂ（以下、まとめて９と称する）、ＭＦＰ５、スキャナ６、プリンタ７、オフラインフィニッシャ８などの各種のデバイスが接続されている。ただし、ＭＦＰはMulti Function Peripherals（複合機）である。出力拠点においては、オペレータがＰＣ９を使用して出力拠点サーバ４にアクセスし、各種デバイス５〜８等を使用して、スキャン処理、コピー処理、編集加工処理、プリント処理、フィニッシング処理などを行う。処理結果のアウトプットであるコピー物や、印刷物、製本物などは、例えば、社内メール便などの物理的搬送手段１０を使用して、発注者に送付される。
【００２０】
また、ＭＦＰ−Ｌ１２は、プリントサービスへの発注を行う前に、発注者がプレプルーフプリントを行って印刷体裁や印刷結果等の確認を行うための複合機（ローカルプリンタ）であり、発注ＰＣ１と同一エリア内（例えば、同一オフィス内）に存在する。ただし、ＭＦＰ−Ｌ１２は、多機能である必要はなく、プリンタ機能など最低限、画像を形成する機能を有していればよく、例えば、ローカルプリンタを用いて構成することができる。ＭＦＰ−Ｌ１２と発注者のＰＣ１とはイントラネット１１等のネットワークで接続されている。
【００２１】
なお、上記のシステム構成は説明の便宜のために例示したものであり、これに限られるわけではない。例えば、受注Ｗｅｂサーバ３、出力拠点サーバ４、ＰＣ９を２台以下又は４代以上の情報処理装置によって実現してもよい。また、ＭＦＰ５、スキャナ６、プリンタ７、オフラインフィニッシャ８は、印刷、製本等を行うための装置を例示したものであり、これに限られるわけではない。
【００２２】
（情報処理装置のハードウェア構成）
次に、本実施形態において使用する情報処理装置のハードウェア構成について、図１９を参照して説明する。図１９は、本実施形態における情報処理装置のハードウェア構成を模式的に示したブロック図である。本実施形態では、発注者ＰＣ１、受注Ｗｅｂサーバ３、出力拠点サーバ４、ＰＣ９がこのような情報処理装置に相当する。尚、本実施形態における情報処理装置は、例えば、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）、携帯情報端末（ＰＤＡ）等で実現される。
【００２３】
図１９において、９９０はＣＰＵである。ＣＰＵ９９０は、後述するハードディスク装置９９５に格納されているアプリケーションプログラム、オペレーティングシステム（ＯＳ）や制御プログラム等を実行し、ＲＡＭ９９２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００２４】
９９１はＲＯＭであり、内部には基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。９９２は各種データを一時記憶するためのＲＡＭであり、ＣＰＵ９９０の主メモリ、ワークエリア等として機能する。
【００２５】
９９３は記録媒体へのアクセスを実現するための外部記憶ドライブであり、メディア（記録媒体）９９４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。尚、メディア９９４は、例えば、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意である。
【００２６】
９９５は外部記憶装置であり、本実施形態では大容量メモリとして機能するハードディスク装置（以下、ＨＤと呼ぶ）を用いている。ＨＤ９９５には、アプリケーションプログラム、ＯＳ、制御プログラム、関連プログラム等が格納される。
【００２７】
９９６は指示入力装置であり、キーボードやポインティングデバイス（マウス等）、タッチパネル等がこれに相当する。指示入力装置９９６を用いて、ユーザは、本実施形態に係る情報処理装置に対して、装置を制御するコマンド等を入力指示する。
【００２８】
９９７はディスプレイであり、指示入力装置９９６から入力したコマンドや、それに対する情報処理装置の応答出力等を表示したりするものである。
【００２９】
９９９はシステムバスであり、情報処理装置内のデータの流れを司るものである。９９８はインターフェイス（以下、Ｉ／Ｆという）であり、このＩ／Ｆ９９８を介して外部装置とのデータのやり取りを行う。
【００３０】
尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。
【００３１】
本実施形態では、メディア９９４から本実施形態に係るプログラム及び関連データを直接ＲＡＭ９９２にロードして実行させる例を示すが、これに限られない。例えば、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされているＨＤ９９５からＲＡＭ９９２にロードするようにしてもよい。また、本実施形態に係るプログラムをＲＯＭ９９１に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ９９０で実行することも可能である。
【００３２】
また、本実施形態では、説明の便宜のため、本実施形態に係る情報処理装置を１つの装置で実現した構成について述べるが、複数の装置にリソースを分散した構成によって実現してもよい。例えば、記憶や演算のリソースを複数の装置に分散した形に構成してもよい。或いは、情報処理装置上で仮想的に実現される構成要素毎にリソースを分散し、並列処理を行うようにしてもよい。
【００３３】
（サービス発注画面）
次に、発注者ＰＣ１がユーザに提供するユーザインタフェースについて、図２を参照して説明する。図２は、発注者ＰＣ１がディスプレイ９９７上に表示する、受注Ｗｅｂサーバ３に対するサービス発注画面を例示した図である。説明の簡略化のため、本実施形態では、サービス発注画面は、受注Ｗｅｂサーバ３が作成するＷｅｂ画面であり、発注者は発注者ＰＣ上のＷｅｂブラウザを用いて、この画面にアクセスするものとして説明する。もちろんサービス発注を行う専用のクライアントアプリケーションによって実現してもよいことは明らかである。
【００３４】
図１３に例示したサービス発注画面には、６つのサービスの注文ボタン１４〜１９が表示されている。
【００３５】
まず、１４は、出力／製本サービスを発注するための入り口ボタンである。出力／製本サービスは、電子データを入稿し、それを指定された体裁でプリントし、指定された製本加工を行い、指定された配送先に送付するサービスである。一般に、ステープル綴じなどの後処理は、オフィスにあるＭＦＰ−Ｌ１２に備えられたステープル装置を使用して実施することも可能である。しかし、くるみ製本などの製本作業には、糊付けなどを行う専用のバインダ機や、くるんだ後に端を断裁するための断裁機などが必要であり、オフィスで実施することは困難である。このため、そのような高度な製本作業を要する場合等に、このサービスが使用される。
【００３６】
ついで、１５は、ポスターパネルサービスを発注するための入り口ボタンである。ポスターパネルサービスは、電子データを入稿し、それを指定された体裁でＡ１サイズなどの大判のサイズでプリントし、指定されたパネル加工を行い、指定された配送先に送付するサービスである。このような、オフィスに設置されたＭＦＰ−Ｌ１２では印刷できないような大判サイズのプリントを必要とする場合等に、このサービスが使用される。
【００３７】
ついで、１６は、コピーサービスを発注するための入り口ボタンである。コピーサービスは、紙原稿を入稿し、それを指定された体裁でスキャンし、指定された体裁でプリントし、指定された製本加工を行い、指定された配送先に送付するサービスである。これは、例えば、ページ数が多いコピージョブや、部数が多いコピージョブや、配送先の多いコピージョブについて、このサービスが使用される。
【００３８】
ついで、１７は、再注文サービスを発注するための入り口ボタンである。再注文サービスは、以前に発注されたサービスと同一内容の処理を再度行うサービスであり、以前に発注された内容と同一内容を実行するため、出力拠点側は各種の設定の手間が不要である。
【００３９】
ついで、１８は、保管ドキュメント注文サービスを発注するための入り口ボタンである。保管ドキュメント注文サービスは、出力拠点に保管している保管ドキュメントについて発注者から指定を受け、指定されたドキュメントを印刷し、指定された配送先に送付するサービスである。本実施形態では、保管ドキュメント注文サービスが選択された場合、印刷体裁は固定であるものとするが、用途や目的に応じて自由に設計できることは言うまでもない。
【００４０】
ついで、１９は、スキャンサービスを発注するための入り口ボタンである。スキャンサービスは、紙原稿を入稿し、それを指定された体裁でスキャンし、スキャンした画像データに関して指定され加工を行い、指定した送付先に送付するサービスである。
【００４１】
（発注処理の概要）
次に、発注ＰＣ１に対して発注内容の入力を開始してから、完了するまでの処理の概要について、図３を参照して説明する。ここでは出力／製本サービスを発注する場合について例示的に説明する。図３は、第１実施形態における、発注者ＰＣ１上の、出力／製本サービスの発注処理フローの概要を説明する図である。
【００４２】
まず、ステップＳ１１で、発注者ＰＣ１は、発注者からの指示入力に基づいて受注Ｗｅｂサーバ３にアクセスし、図２に例示したサービス発注（メニュー）画面をディスプレイ９９７に表示する。そして、発注者による出力／製本サービスボタン１４の選択に基づいて、出力／製本サービスを要求する旨の情報とともに受注Ｗｅｂサーバ３にアクセスする。
【００４３】
ついで、ステップＳ１２で、図４（ａ）を参照して後述するように、発注者から電子データの入稿方法の指定を受け付ける。
【００４４】
ついで、ステップＳ１３で、図４（ｂ）を参照して後述するように、印刷／製本体裁の指定を受け付ける。
【００４５】
ついで、ステップＳ１４で、図５（ａ）を参照して後述するように、出力／製本サービスでの印刷結果を事前に確認するためのプレプルーフプリントを実行する。
【００４６】
ついで、ステップＳ１５で、図５（ｂ）を参照して後述するように、プレプルーフプリント結果の承認処理を実行する。
【００４７】
ついで、ステップＳ１６で、図６（ａ）を参照して後述するように、配送体裁の指定を受け付ける。
【００４８】
ついで、ステップＳ１７で、図６（ｂ）を参照して後述するように、発注情報や発注者情報の発注者による確認を受け付け、発注処理を行う。
【００４９】
以下、各ステップにおいて表示する画面例を参照して、各ステップにおいて行う処理を説明する。以下に示す画面例のインタフェースは例示的なものであり、これに限られるわけではない。また、以下に例示する画面は、主に、受注Ｗｅｂサーバ３が画面内容についての情報（ＨＴＭＬなどを含む）を発注ＰＣ１に送出し、発注ＰＣ１が受信した情報に基づいて表示するものとするが、これに限られるわけではない。
【００５０】
[入稿方法の指定]
図４（ａ）は、図２の出力／製本サービスの発注フローの、ステップＳ１２において表示する、原稿の電子データの入稿を受け付ける画面を例示した図である。
【００５１】
１０１は、電子データを電子的に入稿するか、ＣＤ−ＲＯＭなどのメディアを用いて、物理的に送付して入稿するかの指示を受け付けるチェックボックスである。発注者は、電子的に入稿する場合には、１０２の箇所に、発注者のＰＣ１内に存在する入稿ファイル名を書き込むか、参照ボタン２２を押下して、発注者のＰＣ１内の入稿ファイル名を指定する。
【００５２】
１０３は、入稿ファイルのページ数の指定を受け付ける入力領域である。
【００５３】
１０４は、入稿ファイルを作成した情報処理装置におけるＯＳ（Operating System）を入力、又は、選択する領域である。
【００５４】
１０５は、入稿ファイルを作成した時の作成アプリケーションを入力、又は、選択する領域である。
【００５５】
発注者ＰＣ１は、ＯＫボタン２３の押下（選択）に基づいて、１０１乃至１０５に入力された情報を受注Ｗｅｂサーバ３に送出する。入稿ファイルを電子的に入稿する場合には、１０２で指定された。入稿ファイルも、受注Ｗｅｂサーバに電子的に送出する。一方、入稿ファイルをメディアで入稿する場合には、メディアは社内メール便や宅配便などを用いて、物理的搬送手段１０を経由して出力拠点に送付されるように手配する。この手配は、例えば、予め設定された担当者や発注者に物理的搬送を開始する手続きを行う旨の指示が含まれる表示をすることによって行う。
【００５６】
発注者は、このようにして、発注したオーダーに関する原稿の電子データの入稿を行う。
【００５７】
[印刷／製本体裁の指定]
受注Ｗｅｂサーバ３は、ステップＳ１２の処理において１０１乃至１０５に入力された情報を受け取ると、印刷／製本体裁の指定を受け付ける画面を発注ＰＣ１に送出する。ステップＳ１３において、発注ＰＣ１は受け取った画面をディスプレイ９９７に表示する。図４（ｂ）は、出力／製本サービスの発注フローの、ステップＳ１２において表示する、印刷／製本体裁の指定を受け付ける画面の例を示した図である。
【００５８】
２０１は、印刷仕上げサイズを指定するチェックボックスである。図４（ｂ）の２０１ではＡ４が選択されている。
【００５９】
２０２は、カラーで印刷するか、白黒で印刷するかを指定するチェックボックスである。図４（ｂ）の２０２ではカラー／白黒自動が選択されている。
【００６０】
２０３は片面印刷か両面印刷かを指定するチェックボックスである。図４（ｂ）の２０３では両面が選択されている。
【００６１】
２０４は、印刷に使用する紙種を指定するチェックボックスである。図４（ｂ）の２０４ではカラー普通紙が選択されている。
【００６２】
２０５は表紙印刷に関する設定を指定するチェックボックスである。図４（ｂ）の２０５では表紙をつけて、その表紙にも印刷する『表紙あり（印刷あり）』が選択されている。
【００６３】
２０６は印刷した紙をどのように製本するかの製本体裁の設定を指定するチェックボックスである。図４（ｂ）の２０６ではくるみ製本が選択されている。
【００６４】
２０７は印刷した紙に対するパンチ処理に関する設定を指定するチェックボックスである。図４（ｂ）の２０７ではパンチなしが選択されている。
【００６５】
２０８は、印刷した紙に対する辺の断裁処理に関する設定を指定するチェックボックスである。図４（ｂ）の２０８では３方向断裁が選択されている。
【００６６】
２０９は部数設定の入力領域である。図４（ｂ）の２０９では２０部が指定されている。
【００６７】
発注ＰＣ１は、以上の入力領域における入力後、ＯＫボタンが選択されたことに応じて、印刷／製本体裁の情報を受注Ｗｅｂサーバ３に送出する。発注者は、このようにして、発注したオーダーに関する印刷／製本体裁を指定する。
【００６８】
[プレプルーフプリント]
受注Ｗｅｂサーバ３は、ステップＳ１３の処理において入力された情報を受け取ると、プルーフプリント指示画面を発注ＰＣ１に送出する。ステップＳ１４において、発注ＰＣ１は受け取った画面をディスプレイ９９７に表示する。図５（ａ）は、第１実施形態の発注フローにおける、発注者ＰＣ１上の、プレプルーフプリント指示画面を例示した図である。
【００６９】
３０１は、プレプルーフプリントを行う、発注者が直接使用することができるローカルプリンタを２７の候補一覧をプルダウンリストで表示する表示領域である。発注者はこのプルダウンリストからプレプルーフプリントを行うローカルプリンタを選択する。３０１では、ＭＦＰ−Ｌ１２というＭＦＰが選択されている。
【００７０】
３０２〜３０５は、図４(ｂ)で指定された印刷／製本体裁のうち、３０１で選択されたＭＦＰ−Ｌ１２が実行可能なパラメータを一覧表示する領域である。発注ＰＣ１は、ＭＦＰ−Ｌ１２がこれらのパラメータを反映してプレプルーフプリントを実行するように制御する。
【００７１】
一方、３０６乃至３０８は、図４(ｂ)で指定された印刷／製本体裁のうち、３０１で選択されたＭＦＰ−Ｌ１２が実行することのできないパラメータを一覧表示する領域である。例えば、くるみ製本３０７と３方向断裁３０８は、選択したＭＦＰ−Ｌ１２では実行できないパラメータである。こられについては発注ＰＣ１が自動的にそれぞれ、製本なし、断裁なしに変更して表示する。
【００７２】
３０９はプルーフプリントによってプリントを行う部数を表示する領域である。図５の例では、部数を自動的に１に変更する場合を例示している。これは、プルーフプリントを行うのは１部数で充分であるためである。
【００７３】
本実施形態では、このように、ローカルプリンタで実行可能な機能にあわせて、図４(ｂ)で指定された印刷／製本体裁のうち、選択されたローカルプリンタで実行可能なパラメータを自動的に反映してプルーフプリントを行うように制御する。このため、発注者は、図４(ｂ)で指定した印刷／製本体裁に可能な限り近い印刷／製本体裁でプルーフプリントを行うことができる。
【００７４】
また、発注ＰＣ１は、図４(ｂ)で指定された印刷／製本体裁のうち、選択されたローカルプリンタで実行できないパラメータは自動的に非適用とし、非適用としたことを図５(ａ)の３０６〜３０８のように発注者に明示的に表示する。これにより、プレプルーフプリント結果と、後でプリントサービスの出力拠点で印刷される本プリント結果との違いを、発注者は明確に把握することができる。
【００７５】
なお、発注者ＰＣ１は、プレプルーフプリントに使用する使用プリンタが３０１において変更された場合、図５(ａ)の３０２〜３０８を、その使用プリンタで実行可能な機能にあわせて変化させて表示制御する。例えば、選択された使用プリンタが、図４(ｂ)で指定された印刷／製本体裁を全て実行可能な場合には、部数以外の全てのパラメータをプレプルーフプリントに反映するように制御する。
【００７６】
発注者は、使用プリンタを選択し、プレプルーフプリントに反映されるパラメータと反映されないパラメータとを確認後、それで良ければ、『プリントする』ボタン２９を押下（選択）する。発注ＰＣ１は『プリントする』ボタン２９の選択に応じて、プレプルーフプリントを３０１で選択されたプリンタで実行するように制御する。一方、プレプルーフプリントを行いたくない場合、発注者は『プリントしない』ボタン３０を押下する。この場合、発注ＰＣ１は、プレプルーフプリントの工程とプレプルーフ承認の工程をスキップし、図６(ａ)を参照して後述する配送先指定画面を表示する。
【００７７】
さらに、図５(ａ)において、図４(ｂ)で指定した印刷／製本体裁を変更したい場合、発注者は『体裁再設定』ボタン２８を押下する。この場合、発注ＰＣ１は、図４(ｂ)の画面を表示して再び印刷／製本体裁の指定を受け付ける。
【００７８】
[プレプルーフ承認]
図５(ａ)で、『プリントする』ボタン２９が押下されると、発注ＰＣ１は、電子入稿する原稿データに対応するアプリケーションをバックグラウンドで自動的に起動する。そして、図５(ａ)で選択された使用プリンタに対応するプリンタドライバによって、自動的にＰＤＬデータを作成する。その時、そのＰＤＬデータには、図５(ａ)で説明した『プレプルーフプリントに反映される印刷／製本体裁』が、自動的に反映されるように制御する。  発注ＰＣ１は、ＰＤＬデータを、図５(ａ)で選択された使用プリンタに送出し、図５(ａ)で説明した『プレプルーフプリントに反映される印刷／製本体裁』を反映したプレプルーフプリントを実行する。プレプルーフプリント処理が終了すると、発注者ＰＣ１は、図５(ａ)の画面を図５(ｂ)のプレプルーフプリント確認画面に切り替えて表示する。図５（ｂ）は、第１実施形態の発注フローにおける、発注者ＰＣ１上の、プレプルーフプリント確認画面を例示した図である。
【００７９】
４０１は、プレプルーフプリントに使用したプリンタ名とその種別を表示する領域である。
【００８０】
４０２は、プレプルーフプリントに使用したプリンタドライバの種別を表示する領域である。
【００８１】
４０３は、プレプルーフプリント時にプリンタの中で行われたフォント置換の情報を表示する領域である。図５（ｂ）に示した例の４０３では、原稿データ中にKyotoフォントが使われていたが、プリンタがKyotoフォントをサポートしておらず、MSゴシックフォントに置き換えてプリントを行ったことを示している。
【００８２】
４０４は、プレプルーフプリント時にプリンタの中で使われたカラープロファイルの種別の情報を表示する領域である。
【００８３】
４０５は、プレプルーフプリント時のカラー／白黒自動印刷において、カラーページと判定されたページ数と白黒ページと判断されたページ数を表示する領域である。図５（ｂ）の例では、カラーページと判定されたページ数が５ページであり、白黒ページと判断されたページ数が１５ページであった場合を示している。
【００８４】
４０６〜４０８は、プレプルーフプリントに反映されなかった印刷／製本体裁のパラメータを確認的に表示する領域である。
【００８５】
４０９〜４１０は、発注者から、プリントサービスの出力拠点のオペレータに対する注文コメントを入力する領域である。図５（ｂ）に示した例の４１０では、プレプルーフプリントでは両面プリントにおけるオモテ面と裏面の位置があっていなかった場合に、出力拠点における本プリントの時には、その位置を合わせることをオペレータに指示する内容となっている。
【００８６】
発注者は、使用プリンタを用いて紙としてプリントしたプレプルーフプリント結果を目視で確認し、それが発注者の意図と合致したものであれば、図５(ｂ)の『承認する』ボタン３３を押下して、プレプルーフ承認を行う。発注ＰＣ１は『承認する』ボタン３３が押下されるとステップＳ１６へ進む。、
一方、プレプルーフプリント結果のままの状態では承認できない場合には、『承認しない』ボタン３４を押下して承認しない。この場合には、従来例の方式１の現物によるプルーフが、後に行われることになる。さらに、図５(ｂ)において、図４(ｂ)で指定した印刷／製本体裁を変更したい場合には、『体裁再設定』ボタン３２を押下する。『体裁再設定』ボタン３２が押下された場合、発注ＰＣ１は、ステップＳ１３に戻り、図４(ｂ)に例示した画面を再び表示して設定内容の変更を受け付ける。
【００８７】
[配送体裁指定]
ステップＳ１６において、発注ＰＣ１は、配送体裁指定を受け付ける画面を表示する。図６（ａ）は、発注者ＰＣ１上の、出力／製本サービスの発注フローにおける、配送体裁指定を受け付ける画面を例示した図である。
【００８８】
図６（ａ）において、５０１、５０５、５０９は、出力／製本サービスの出力物である印刷物をどのような方法で発注者に届けるかに関する指定を受け付けるチェックボックスである。５０１は社内メール便での送付、５０５は宅配便での送付、５０９は、出力拠点まで発注者が引き取りに行く場合をそれぞれ意味する。５０２〜５０４は、社内メール便での送付の場合の送付先に関する設定を入力する領域である。５０６〜５０８は、宅配便での送付の場合の送付先に関する設定を入力する領域である。５１０は、引き取りに行く場合の引き取り予定日に関する設定を入力する領域である。
【００８９】
発注者は、このようにして、発注したオーダーに関する配送体裁を指定する。配送体裁指定の入力後、ＯＫボタン３８が押下されると、発注ＰＣ１は入力された情報を受注Ｗｅｂサーバ３に送出する。受注Ｗｅｂサーバ３は発注ＰＣ１からの情報の受信に応じて、発注確認の画面の情報を発注ＰＣ１に送出する。発注ＰＣ１は受注Ｗｅｂサーバ３からの情報の受信に応じてステップＳ１７へ進む。一方、キャンセルボタン３９が押下されると処理を終了する。
【００９０】
[発注確認]
図６（ｂ）は、ステップＳ１７の各種サービスの発注フローにおいて、発注者が発注者ＰＣ１上で発注確認を行う画面を例示した図である。
【００９１】
６０１は注文するサービスの種類、６０２は注文しようとするサービスの概算見積もりをそれぞれ表示する領域である。６０３は発注者が納期希望日を記入する入力領域である。そして、６０４から６０９は発注者に関する情報の確認表示である。発注者は、内容を確認し、ＯＫボタン３８を押下する。発注ＰＣ１は、ＯＫボタン３８の押下を契機として、受注Ｗｅｂサーバ３に対してサービスの発注を行う。
【００９２】
（入稿データ）
図７は、第１実施形態における、受注Ｗｅｂサーバに対する発注時に、受注Ｗｅｂサーバに入稿されるデータを例示した図である。
【００９３】
まず、７０１はオーダーＩＤ、７０２は発注日、７０３は納期日、７０４はオーダー種別である。ついで、７０５〜７０９は図４(ａ)で発注者が指定した、入稿方法に関するパラメータである。ついで、７１０〜７１８は、図４(ｂ)で発注者が指定した、印刷／製本体裁に関するパラメータである。ついで、７１９〜７２２は、図６(ａ)で発注者が指定した、配送体裁に関するパラメータである。ついで、７２３〜７３２は、図５(ａ)で発注者が指定した、プレプループプリントの実施パラメータと、その実施結果である。具体的には、まず、７２３は、図５(ｂ)で、発注者がプレプルーフを承認したことを意味する。ついで、７２４は、プレプルーフに反映しなかったパラメータであり、図５(ｂ)の４０７に対応する。ついで、７２５は、プレプルーフに使用したプリンタ名とその種別であり、図５(ｂ)の４０１に対応する。ついで、７２６は、プルーフに使用したプリンタドライバ種別であり、図５(ｂ)の４０２に対応する。以下、同様に、７２７〜７２９は、図５(ｂ)の４０３〜４０５に対応する。さらに、７３０〜７３１は、図５(ｂ)の４１０に対応する。さらに、７３２は、ローカルプリンタに送られたプレプループプリント時のＰＤＬデータであるtest_preproof.pdlである。ついで、７３３〜７３６は、図６(ｂ)で説明した、料金見積もり、発注者の住所や所属や氏名である。
【００９４】
このように、図７で説明した各種の入稿データが、発注者ＰＣから、受注Ｗｅｂサーバに送られる。なお、図７で説明した各データは、本実施形態では、図４、図５、図６の各Ｗｅｂ画面の処理の中で、逐次、発注ＰＣ１から受注Ｗｅｂサーバに送出するものとするが、これに限られない。例えば、これらを、図６(ｂ)でサービスの発注を指示した時に一括して受注Ｗｅｂサーバに送るように構成してもよい。
【００９５】
また、前述のように、本実施形態では、図４、図５、図６の各画面は、受注Ｗｅｂサーバ３が作成するＷｅｂ画面である。即ち、発注者は発注者ＰＣ１上のＷｅｂブラウザ及びそのヘルパーアプリケーションを用いて、この画面にアクセスし、ユーザ指示の処理を行う。ただし、このような構成に限られない。例えば、発注者ＰＣ１上の発注用の専用アプリケーションを用いて各種の設定を行い、その結果設定された図７に例示した各種の入稿データを受注Ｗｅｂサーバ３に送出するように構成してもよい。
【００９６】
（発注ＰＣ１の処理）
次に、上記のような処理を行う発注ＰＣ１のより詳細な処理について、図８を参照して説明する。図８は、第１実施形態における、受注Ｗｅｂサーバに対する発注時の、発注者ＰＣ１上が実行する処理の流れを示したフローチャートである。発注者ＰＣ１は、Ｗｅｂブラウザやそのヘルパーアプリケーション、Ｗｅｂ画面を介した入力等に基づく制御によって図８に示した処理を実行する。
【００９７】
発注ＰＣ１は、受注Ｗｅｂサーバ３のＷｅｂ画面である図２のサービス発注メニュー上の１４の出力製本サービスが選択されたことに応じて、図８の制御フローに基づく処理を開始する。
【００９８】
まず、ステップＳ１０１では、図４(ａ)を参照して説明した、電子データの入稿方法を指定する画面の処理を行う。即ち、電子データの入稿方法の指定を受け付け、入力された情報を受注Ｗｅｂサーバ３へ送出する。
【００９９】
ついで、ステップＳ１０２では、図４(ｂ)を参照して説明した、印刷／製本体裁を指定する画面の処理を行う。即ち、印刷／製本体裁の指定を受け付け、入力された情報を受注Ｗｅｂサーバ３へ送出する。
【０１００】
ついで、ステップＳ１０３では、まず、デフォルト値として設定されている使用プリンタ等の有する機能などの能力の情報を取得する。使用プリンタ等の能力の情報は、例えば、発注ＰＣ１のＯＳに登録されている情報から取得してもいいし、或いは、使用プリンタ等から直接取得してもよい。そして、取得した能力と、ステップＳ１０２で指定された印刷／製本体裁とを比較して、ステップＳ１０２で指定された印刷／製本体裁のうち、その使用プリンタで実行可能なパラメータを自動的にプレプルーフプリント時のパラメータに反映する。一方、実行不能なパラメータは反映しないように振り分ける。
【０１０１】
ついで、ステップＳ１０４では、図５(ａ)を参照して説明したプレプルーフプリントの指示画面を表示する。この画面では、ステップＳ１０３で振り分けた、プレプルーフプリントに反映するパラメータと、反映しないパラメータを表示する。
【０１０２】
ついで、ステップＳ１０５では、図５(ａ)の画面を介して発注者からの指示を受け付ける。体裁再設定ボタン２８が押された場合（ステップＳ１０５で「体裁再設定」）には、ステップＳ１０２に戻る。
【０１０３】
ステップＳ１０５で、プルダウン２７を介して使用プリンタが変更された場合（ステップＳ１０５で「使用プリンタの変更」）には、ステップＳ１０３に戻る。ステップＳ１０３では、新たに変更された使用プリンタの能力を取得し、その能力に基づいて、プレプルーフプリントに反映するパラメータと、反映しないパラメータの再振り分けを行い、ステップＳ１０４でそれを表示する。
【０１０４】
ステップＳ１０５で、「プリントしない」ボタン３０が押下された場合（ステップＳ１０５で「プリントしない」）には、ステップＳ１１１へ進む。ステップＳ１１１では、図６(ａ)を参照して説明した配送先を指定する画面の処理を行う。さらに、図６(ｂ)を参照して説明した発注確認画面の処理を行い、最後に、プレプルーフ承認の処理を行わないで、原稿データ、発注用の印刷／製本体裁データなどの情報を受注Ｗｅｂサーバに送付し、発注を行う。この場合、図７の入稿データにおいて、７２３は『承認なし』となる。そして、処理を終了する。
【０１０５】
ステップＳ１０５で、「プリントする」ボタン３０が押下された場合（ステップＳ１０５で「プリントする」）には、ステップＳ１０７へ進む。
【０１０６】
ステップＳ１０７では、使用プリンタとして選択されたローカルプリンタを用いてプレプルーフプリントを実行する。そして、プレプルーフプリント時の使用カラープロファイル、フォント置換結果、カラー／白黒ページ判定結果、等の実施状況データを使用プリンタから取得する。
【０１０７】
次に、ステップＳ１０８において、図５(ｂ)を参照して説明したプレプルーフプリントの確認画面を表示する。
【０１０８】
ついで、ステップＳ１０９では、図５(ｂ)の画面において発注者の指示を受け付ける。体裁再設定ボタン３２が押された場合（ステップＳ１０９で「体裁再設定」）には、ステップＳ１０２に戻る。一方、ステップＳ１０９で、プレプルーフの「承認しない」ボタン３４が押された場合（ステップＳ１０９で「承認しない」）は、ステップＳ１１１に遷移する。
【０１０９】
さらに、ステップＳ１０９で、プレプルーフの「承認する」ボタン３３が押された場合は（ステップＳ１０９で「承認する」）、ステップＳ１１０に遷移する。
【０１１０】
ステップＳ１１０では、図６(ａ)を参照して説明した配送先を指定する画面の処理を行い、図６(ｂ)を参照して説明した発注確認画面の処理を行う。そして、プレプルーフ承認ありで、原稿データ、発注用の印刷／製本体裁データなどに加えて、図７を参照して説明した７２３〜７３２等のプレプルーフプリントの実施状況データを受注Ｗｅｂサーバに送付し、発注を行う。
【０１１１】
（出力拠点における処理）
上記のような処理によって、発注ＰＣ１から発注に係る情報を受け取ると、受注Ｗｅｂサーバ３は、発注に係る情報を出力拠点サーバ４へ送出する。出力拠点サーバ４は発注に係る情報を受け取ると、オペレータの指示入力等に基づいて出力製本サービス処理を実行する。図９は、出力製本サービス処理の流れを示したフローチャートである。
【０１１２】
まず、ステップＳ２１で、受注をする。即ち、受注Ｗｅｂサーバ３から発注に係る情報を受け取る。
【０１１３】
次に、ステップＳ２２で、原稿を受け取る。即ち、電子データを受注Ｗｅｂサーバ３経由で受け取るか、メディアを物理的搬送手段１０経由で受け取る。以下、電子データで原稿を受け取った場合の処理について説明する。
【０１１４】
次に、ステップＳ２３では受け取った電子データの中身をチェックし、編集／加工が必要かどうかを判断する。この判断は、オペレータが電子データの中身をチェックして行う場合と、出力拠点サーバ４が自動的に行う場合がある。オペレータが編集／加工の必要性の有無を判断する場合は、必要性の有無を入力することが可能なインタフェースを提供し、当該インタフェースを介して入力された情報に基づいて必要性の有無を判定する。出力拠点サーバ４が必要性の有無を自動的に判断する場合は、例えば、対応可能な電子データの形式（例えば、ファイルの種類等）を予め登録しておき、登録された形式と原稿とを比較し、原稿がフォーマットに従っているか否かに基づいて判定する。
【０１１５】
編集／加工が必要な場合（ステップＳ２３でＹＥＳ）には、ステップＳ２４へ進む。ステップＳ２４では、受け取った電子データに対し、ページ番号付加や、面つけや色修正などの編集／加工処理を行う。これらの編集／加工処理も、例えば、所定の編集アプリケーションを介したオペレータの指示入力に基づいて行ってもよいし、或いは、出力拠点サーバ４が自動的に行ってもよい。出力拠点サーバ４が自動的に行う場合には、例えば、受け取った電子データを所定の形式のデータに自動変換する場合が含まれる。そしてステップＳ２５へ進む。
【０１１６】
また、ステップＳ２３で編集／加工が必要でない場合（ステップＳ２３でＹＥＳ）も、ステップＳ２５へ進む。
【０１１７】
ステップＳ２５では、発注ＰＣ１から送られてきた図７の入稿データの７２３を参照し、発注時に発注者側でプレプルーフプリントを行い、それを承認している（承認済み）か否かを判定する。承認済みでない場合（ステップＳ２５でＮＯ）はステップＳ２８へ進み、承認済みの場合（ステップＳ２５でＹＥＳ）はステップＳ２６へ進む。
【０１１８】
ステップＳ２８〜ステップＳ３０では、印刷（出力）拠点側において、従来例の方式１の現物によるプルーフを行う。まず、ステップＳ２８では、印刷拠点側のプリンタを用いて、発注者から指定された印刷／製本体裁に従って部数１のプルーフプリントを行うプリントを実行する。次に、ステップＳ２９において、そのプルーフプリント結果を発注者に社内メール便などの物理的搬送手段で送付して、プルーフ承認を得る。プルーフ承認が得られると、ついで、ステップＳ３０において、残りの部数のプリントを行う。これらの処理は出力拠点サーバ４の制御に基づいて実行されるが、一部の処理を人間が実行するようにも設計することができる。そしてステップＳ３２へ進む。
【０１１９】
一方、ステップＳ２６では、図７の入稿データの一部として送られてきたプルーフ実施状況を確認する。即ち、図７の７２３〜７３２等のプレプルーフプリントの実施状況データを参照する。
【０１２０】
次に、ステップＳ２７では、そのプルーフ実施状況などから、再プルーフが必要かどうかを判定する。この判定は、システムの用途や目的に応じて多様に設計することができ、例えば、カラー印刷に係るプルーフをモノクロプリンタで実行した場合に再プルーフが必要と判定するなどと設計することができる。
【０１２１】
例えば、プレプルーフプリントに使用されたローカルプリンタが、出力拠点に存在するプリンタと特性の近いものである場合は問題ないが、出力拠点側でその特性が知られていない未知のプリンタである場合には、再プルーフが必要と判定する。或いは、出力拠点サーバ４が、各メーカーの各プリンタの特性データを、例えば、データベースに管理しておき、プレプルーフプリントに使用されたローカルプリンタの特性データがデータベースに記録されているか否かによって判定を行ってもよい。また、部数が予め設定された値よりも多い場合などは、プリントに失敗するとやり直しのコストが多大となるので再プルーフが必要と判定するように設計してもよい。また、出力拠点でオペレータが追加の編集加工等を行っ場合は再プルーフが必要と判定するように設計してもよい。また、原稿文書の内容（画像、レイアウト、色）などに基づいて、再プルーフの必要性の有無を判定するように設計してもよい。また、出力拠点のプリンタにプリントする場合のＰＤＬデータを作成し、それと発注者側でプレプルーフに使用されたＰＤＬデータとを比較し、差異がなければ再プルーフは不要と判断するようにしてもよい。
【０１２２】
以上の判定は、出力拠点サーバ４が自動的に行ってもよいし、印刷拠点のオペレータが判断し、その判断結果を入力可能に設計してもよい。
【０１２３】
ステップＳ２７で、再プルーフが必要と判断された場合（ステップＳ２７でＹＥＳ）はステップＳ２８進み、再プルーフが必要と判断されなかった場合（ステップＳ２７でＮＯ）はステップＳ３１へ進む。
【０１２４】
ステップＳ３１では注文原稿の指定された全部数をプリントする。プリントは、発注ＰＣ１から受け取った、ローカルプリンタの種類、そのプリンタの印刷特性、印刷条件等に基づいて、プレプルーフプリントの結果を再現しつつ、その品質を向上させるように行う。例えば、ローカルプリンタの色特性と、出力拠点のプリンタ７の色特性とを比較して、プレプルーフプリントにおいて形成された色を再現するように出力拠点のプリンタ７の色出力を制御する。また、更に、例えば、プレプルーフプリントにおいては普通紙が用いられ、出力拠点においては上質紙が用いられることが要求されている場合は、用紙の違いを吸収して同等の色を再現できるように制御する。このような制御は、プリンタの出力特性データを出力拠点サーバ４において保持しておき、発注ＰＣ１から受け取った情報に対応する出力特性データを参照し、その特性データと出力拠点側のプリンタ７の特性データとの比較に基づいて行うことができる。尚、プレプルーフプリントの結果を反映させるパラメータは色特性に限られず、画像、レイアウト等、発注ＰＣ１から送出させる各種パラメータを適用することができる。また、プレプルーフプリントの結果を踏まえた印刷は、プレプルーフプリントの結果と全く同一にすることに限られない。例えば、ローカルプリンタでは実現できないがプリンタ７で実現可能な画像効果を、発注ＰＣ１からの要求に応じて行う。全部数のプリントが終わったら、ステップＳ３２へ進む。
【０１２５】
ステップＳ３２では、入稿データに基づいて、くるみ製本や中綴じ製本などの製本加工を行う。
【０１２６】
ついで、ステップＳ３３では、指定された配送先に送付し、料金の請求を行う。そして、処理を終了する。
【０１２７】
以上のように、本実施形態に係る構成においては、プルーフ工程は、基本的に、発注者側のみで行い、出力拠点側では行わない。このため、発注者は簡易にプルーフを行うことができる。例えば、プルーフプリント結果を発注者に社内メール便などの物理的搬送手段で送付したり、プルーフ承認結果を待ったりする等の待ち時間を削減することができる。更に、出力拠点側は、プルーフプリントを行った際の印刷条件や、プリンタの特性などの情報に基づいて、発注側の想定に近い仕上がりの印刷、製本などを行うことができる。
【０１２８】
＜＜第２実施形態＞＞
第２実施形態に係る構成においては、第１実施形態に係る構成と、プレプルーフプリントの指示における処理、受注Ｗｅｂサーバに送付するプレプルーフ実施状況データの内容が異なる。また、本実施形態に係る構成においては、プレプルーフプリント結果をスキャンした画像データも受注Ｗｅｂサーバに送出する。
【０１２９】
本実施形態に係る構成は第１実施形態に係る構成と大部分が同様である。このため、以下、第１実施形態に係る構成と相違する箇所を中心に説明する。
【０１３０】
（プレプルーフプリント指示画面）
図１０(ａ)は、本実施形態に係る発注フローにおける、発注者ＰＣ１上の、プレプルーフプリント指示画面を例示した図であり、第１実施形態の図５(ａ)と対応する。
【０１３１】
第１実施形態では、プレプルーフプリントに反映する印刷／製本体裁や反映しない印刷／製本体裁は、情報処理システムを構成する情報処理装置（発注ＰＣ１、受注Ｗｅｂサーバ３、出力拠点サーバ４等）が自動的に決定していた。これに対し、本実施形態では、一部の印刷／製本体裁については、発注者がプレプルーフプリントに反映するかどうかを選択できるようにしている。本実施形態に係る構成によれば、発注者はプレプルーフに係るオプションを自由に選択することができる。例えば、プルーフの必要なページのみをプルーフプリントするといったことが可能である。
【０１３２】
図１０(ａ)において、８０２〜８０４は、プレプルーフプリントに反映する印刷／製本体裁のパラメータである。これらはＭＦＰ−Ｌ１２が実行可能なパラメータであり、システムが自動的に決定する。
【０１３３】
一方、８０５〜８０８は、指定された印刷／製本体裁のうち、３０１で選択されたＭＦＰ−Ｌ１２が実行することのできないパラメータである。本実施形態に係る構成においては、８０５〜８０８の印刷／製本体裁に係るパラメータを、発注者がプレプルーフプリントに反映するかどうかを選択できるように制御する。図１０（ａ）の例では、プルダウンリストのインタフェースを提供し、それぞれの▼ボタンが押下されることに応じて、別の候補がプルダウンリストを表示し、ユーザがパラメータを変更可能に制御する。
【０１３４】
例えば、８０６では、くるみ製本の代わりにステープル製本が指定されているが、これは、ローカルプリンタにくるみ製本機能がない場合に、代替機能として、ステープル製本が選択されていることを示している。
【０１３５】
また、８０７では、３方向断裁の代わりに１方向断裁が指定（選択）されている。また、８０８では、プレプルーフプリントする範囲として、１ページ目から４ページ目が指定（選択）されている。これは、例えば、表紙である１ページ目と２ページ目から４ページ目がカラーページであって他が白黒ページであるような文書について、カラーページの部分の色の調子やレイアウトのみをプルーフで確認したい場合などに指定する。このように、発注者の目的や意図に応じて、プルーフの必要なページのみをプルーフプリントすることにより、プルーフに要する時間や費用や手間を減らすことができる。
【０１３６】
（プレプルーフプリント確認画面）
図１０(ｂ)は、本実施形態の発注フローにおける、発注者ＰＣ１上の、プレプルーフプリント確認画面を例示した図であり、第１実施形態の図５(ｂ)と対応する。図５(ｂ)との主な相違点は、プレプルーフプリント結果をスキャンした画像データを受注Ｗｅｂサーバ３に送付できるようにした点である。
【０１３７】
図１０(ａ)でプレプルーフプリントを指示すると、プレプルーフプリントが実行されるので、発注者は、そのプリント結果を、スキャナで読み取り、読み取ったスキャン画像データを何らかの手法で、自分のＰＣまで送付する。例えば、ＭＦＰ−Ｌ１２に設けられたスキャナ機能を用いてプリント結果をスキャンし、当該スキャンデータを発注ＰＣ１が取得するようにする。
【０１３８】
発注ＰＣ１は、ファイル指定ボタン５３が選択されると、発注ＰＣ１のファイルシステムにアクセスするためのインタフェースを提供し、発注者によるスキャンデータの選択を受け付ける。そして、発注ＰＣ１は、ファイル指定ボタン５３を用いて、スキャン画像データファイル（図１０(ｂ)では、Scan.tif）を指定されると、そのスキャン画像データファイルを受注Ｗｅｂサーバ３に送出する。
【０１３９】
このように、本実施形態に係る構成においては、実際に発注者が目視確認したプレプルーフプリント結果（紙）のスキャン画像を、出力拠点に送出する。これにより、出力拠点側は、出力拠点における印刷結果とプレプルーフプリント結果のスキャン画像と比較して、正確な事前プルーフ確認を行うことができる。
【０１４０】
（発注用JobTicket）
図１１は、発注用JobTicketを例示した図である。ただし、発注用JobTicketとは、発注者により指定された、印刷／製本体裁、配送先等の情報を記述したデータである。即ち、本実施形態では、第１実施形態の図４(ａ)(ｂ)、図６(ａ)(ｂ)と同様のインタフェースを介して指定された発注用の印刷／製本体裁等を記述したデータである。本実施形態では、発注用JobTicketは、図１１に例示したようなＸＭＬファイル（test_preproof_JT1.xml）６１として保持される。
【０１４１】
図１１において、６２は、オーダー全体に関するパラメータを記述した部分であり、発注日、納期日、オーダー種別、発注者ＩＤ、発注者パスワード等が含まれる。ついで、６３の部分は、電子データの入稿方法に関するパラメータを記述した部分であり、入稿方法、入稿ファイル名、ページ数、作成ＯＳ名、作成アプリ名などが含まれる。
【０１４２】
ついで、６４の部分は、印刷体裁に関するパラメータを記述した部分であり、紙サイズ、カラー／白黒、片面／両面、用紙種類、表紙指定、部数などが含まれる。ついで、６５の部分は、製本体裁に関するパラメータを記述した部分であり、くるみ製本などの製本種別、パンチ指定、断裁指定などが含まれる。
【０１４３】
ついで、６６の部分は、配送体裁に関するパラメータを記述した部分であり、配送方法、配送先アドレス、配送先氏名、配送先連絡先などが含まれる。ついで、６７の部分は、課金体裁に関するパラメータを記述した部分であり、課金先部門コード、見積もり金額などが含まれる。
【０１４４】
このように、発注用の印刷／製本体裁等を、タグとその値で構成されたＸＭＬ形式で記述することにより、本実施形態に係る情報処理装置は発注データを処理することが容易となる。例えば、製本に関するパラメータを得る場合、＜binding＞というキーワードの中の、＜book＞というパラメータを調べるだけでよい。
【０１４５】
（プルーフ用JobTicket）
図１２は、プルーフ用JobTicketを例示した図である。プルーフ用JobTicketとは、プルーフに係る印刷／製本体裁指示等を記述したファイルである。本実施形態では、プレプルーフプリント用の印刷／製本体裁指示等も、図１２に示すようなＸＭＬファイル（test_preproof_JT2.xml）７１として記述され、ローカルプリンタ（ＭＦＰ−Ｌ１２）に送出する。図１２のプルーフ用JobTicket（test_preproof_JT2.xml）７１は、図１１の発注用JobTicket（test_preproof_JT1.xml）６１に基づいて、発注ＰＣ１が自動的に生成する。
【０１４６】
図１２において、７２の部分は、印刷／製本体裁に関するパラメータを記述した部分であり、紙サイズ、用紙種類、カラー／白黒、片面／両面、部数、表紙指定、ステープルなどの製本種別、パンチ指定、断裁指定、印刷ページ範囲指定などが含まれる。図１１と図１２のように、発注用JobTicketと、プルーフ用JobTicketは必ずしも同じ形式とはならず、項目のグルーピングが変わったり、項目の順番が変わったり、項目の名称が変わる場合がある。これは、発注用JobTicketを受け取って、それを理解するのは、受注Ｗｅｂサーバ３上のソフトウェアであり、一方、プルーフ用JobTicketを受け取って、それを理解するのは、ローカルプリンタ１２上の別のソフトウェアであるためである。しかし、双方のJobTicketがＸＭＬ形式で記述されていれば、ソフトウェアにより自動的に変換することは容易である。例えば、図１１の＜binding＞というキーワードの中の＜book＞というパラメータを、図１２の＜Printing＞というキーワードの中の＜Binding＞というパラメータに自動変換するように構成することができる。
【０１４７】
なお、ローカルプリンタ（ＭＦＰ−Ｌ）１２がプルーフ用JobTicketに対応していない場合は次のように構成することができる。即ち、発注ＰＣ１がプルーフ用JobTicketを解析し、当該解析結果に基づいてプリンタ制御用信号を生成し、当該信号でもってローカルプリンタ１２を制御するように構成することができる。
【０１４８】
（入稿データ）
図１３は、本実施形態における、受注Ｗｅｂサーバに対する発注時に、受注Ｗｅｂサーバに入稿されるデータを例示した図であり、第１実施形態における図７と対応する。
【０１４９】
図１３において、１００２は、発注用の印刷／製本体裁指示などが、図１１で説明した発注用JobTicketファイル（test_preproof_JT1.xml）として記述される。発注用JobTicketファイルは、入稿データ８１と同一ファイルとして構成してもよいし、或いは、別ファイルとしてもよい。
【０１５０】
ついで、１００３〜１０１２までは、プレプルーフ承認結果とプレプルーフ実施状況データであり、図７とほぼ同様である。ついで、１０１３〜１０２６までは、本実施形態で追加されたプレプルーフ実施状況データである。プレプルーフ実施状況データには、プルーフプリントを行った時のプリントドライバの各種設定情報、プルーフプリントしたページの範囲、ローカルプリンタのフォント情報、画像欠け幅、前回のキャリブレーション日時、各トナーの濃度ＭＡＸ値等が含まれる。以下、１０１３〜１０２６の情報について説明する。
【０１５１】
１０１３では、プルーフプリントを行った時のプリントドライバの各種設定情報が、iniファイル（プリント.ini）の形で記述される。一般に、プリントドライバでは、各種の印刷／製本体裁設定の他に、様々な各種設定が行われるので、その設定値がこのiniファイルに記述される。この各種設定には、例えば、ＰＤＬデータにフォントを埋め込むかどうかや、余白設定や、イメージデータをどういう解像度で扱うかや、使用するカラープロファイルの種別など、ユーザが選択可能な様々なパラメータが含まれる。これらの設定によって、生成されるＰＤＬデータは異なり、ローカルプリンタでプリントされる印刷結果も異なってしまう。このため、本実施形態に係る構成においては、このドライバの各種設定の情報１０１３のように出力拠点に送出し、出力拠点側で当該情報を参照することで、出力拠点側は、プルーフを行った条件を正確に知り、プルーフの条件に忠実に再現することができる。
【０１５２】
ついで、１０１４は、発注者がプルーフプリントしたページの範囲であり、１０１４では、１ページ目から４ページ目までをプルーフしたことを示している。ついで、１０１５は、プルーフに使用した印刷／製本体裁指示などが、図１２を参照して説明したプルーフ用JobTicketファイル（test_preproof_JT2.xml）として記述される。ついで、１０１６は、プルーフに使用したローカルプリンタに装着されているフィニッシャの種別情報を示すものである。出力拠点側は、この情報を基に、プレプルーフにおいて、どういう種別のフィニッシャによりステープルやパンチが使われたかを知ることができる。
【０１５３】
ついで、１０１７は、プルーフに使用されたローカルプリンタ１２に搭載されているフォント情報である。この情報を利用することにより、出力拠点側は、特殊なフォントが搭載されていないかどうかをチェックすることができる。ついで、１０１８は、プルーフに使用されたローカルプリンタ１２の画像欠け幅である。この情報を参照することにより、出力拠点側は、出力拠点で使用するプリンタを選ぶ時の指標の一つにできる。例えば、もしローカルプリンタの画像欠け幅より、大きな欠け幅のプリンタを使用してしまうと、プルーフ時の画像よりも欠けてしまう可能性がある。
【０１５４】
ついで、１０１９は、プルーフに使用されたローカルプリンタ１２の前回のキャリブレーション日時である。この情報を参照することにより、出力拠点側は、プルーフに使用されたローカルプリンタ１２が、きちんとキャリブレーションされたものかどうかを知ることができる。ついで、１０２０は、プルーフに使用したローカルプリンタの各トナーの濃度ＭＡＸ値である。この情報を参照することにより、出力拠点側は、プルーフに使用されたローカルプリンタ１２が、キャリブレーション処理などにより、きちんと色調整されたものかどうかを知ることができる。
【０１５５】
ついで、１０２１は、プルーフに実際に使用された用紙情報である。この情報を参照することにより、出力拠点側は、プルーフに実際に使用された用紙情報を知ることができる。ついで、１０２２は、両面プリント時の表面の位置調整値である。１０２３は、裏面の位置調整値であり、ＭＦＰのサービスマンがこれらをＸ軸、Ｙ軸について、プラスマイナスで調整することにより、両面プリントを透かした時に、表面と裏面の印字位置を合わせることができるものである。例えば、１０２２の場合は、表面を基準位置に対して、Ｘ軸はプラス方向に０.５mm、Ｙ軸はマイナス方向に１.０mmシフトして印字することを意味する。この１０２２、１０２３の情報を利用することで、出力拠点側は、プルーフに使用したローカルプリンタの両面の位置設定値を知ることができる。
【０１５６】
ついで、１０２４は、プルーフプリントを行った日時である。ついで、１０２５は、図１０(ｂ)の画面で指定した、プルーフプリント結果を読み取ったスキャン画像データファイルであるScan.tifである。
【０１５７】
ついで、１０２６は、プレプルーフの確認署名情報ファイルであるVerified20040115.xxxである。この確認署名情報ファイルは、発注者が確かにプルーフ承認をしたことを証明するためのファイルである。具体的には、発注者名や、プルーフプリントの日時や、その他様々なプルーフプリントの実施状況データを、発注者の秘密鍵で暗号化したものとなっている。この暗号化されたファイルは、発注者の公開鍵により復号化できるので、出力拠点のオペレータはその内容を確認することができる。一方、発注者の秘密鍵による暗号化は、発注者しか行えないので、確認署名情報ファイルは発注者しか作れない。よって、この確認署名情報ファイルにより、発注者本人がプルーフ承認をしたことを証明できる。なお、本実施形態では、プルーフ承認者は発注者と同じであるが、異なっているような構成にしてもよい。
【０１５８】
（発注ＰＣ１の処理）
次に、発注ＰＣ１が実行する出力製本サービス発注処理について、図１４を参照して説明する。
【０１５９】
図１４は、本実施形態における、発注者ＰＣ１上が実行する、受注Ｗｅｂサーバ３に対する発注時の制御フローを示したフローチャートであり、第１実施形態における図８と対応する。図１４のフローチャートは、図８のフローチャートとは、ステップＳ２０２，２０３，２０４，２０７，２１０，２１１のみが異なっているので、その相違部分を説明する。それ以外の各ステップＳ２０１，２０５，２０６，２０８，２０９は、それぞれステップＳ１０１，１０５，１０６，１０８，１０９と同様の動作をする。
【０１６０】
まず、ステップＳ２０２について説明する。ステップＳ２０２では、指定された印刷／製本体裁等を、図１１で説明した発注用JobTicketファイル（test_preproof_JT1.xml）として保存する。
【０１６１】
次に、ステップＳ２０３，Ｓ２０４について説明する。図８のステップＳ１０３では、プレプルーフプリントに反映する体裁と反映しない体裁を、プリンタの能力に応じて全て自動決定していた。これに対し、本実施形態では、ステップＳ２０３ではプリンタの能力に応じてプレプルーフプリントに自動反映する体裁（具体的には、図１０(ａ)の８０２〜８０４の体裁）を決定する。次に、ステップＳ２０４において、図１０(ａ)の画面を表示し、残りの体裁（具体的には、図１０(ａ)の８０６〜８０８の体裁）を発注者により変更可能に制御する。そして、ステップＳ２０５へ進む。
【０１６２】
次に、ステップＳ２０７について説明する。ステップＳ２０７の処理は、ステップＳ２０５でプレプルーフプリントを指示された場合（ステップＳ２０５で「プリントする」）に実行する。
【０１６３】
まず図１１で説明した発注用JobTicketファイル（test_preproof_JT1.xml）から、図１２で説明したプルーフ用JobTicketファイル（test_preproof_JT2.xml）を自動生成する。即ち、発注用JobTicketファイルをプルーフ用JobTicketファイルの形式に適合するように変換する。そして、そのプルーフ用JobTicketファイルと、プルーフ用ＰＤＬデータを使用プリンタ１２に送付してプレプルーフプリントを実行するように制御する。ついで、実施状況データ（プリンタのフィニッシャ情報／フォント情報／画像欠け幅／キャリブレーション状況／濃度状況／使用用紙情報、等）を使用プリンタから取得し、さらに、プレプルーフプリント時のドライバ設定情報もドライバから取得する。そして、ステップＳ２０８へ進む。
【０１６４】
次に、ステップＳ２１０について説明する。ステップＳ２１０の処理は、ステップＳ２０９でプルーフ承認が指示された場合（ステップＳ２１０で「承認する」）に実行する。
【０１６５】
まず、図６(ａ)を参照して配送先の指定の処理を行い、図６(ｂ)を参照して説明した発注確認の処理を行う。ついで、図１３を参照して説明した確認署名情報ファイルを作成し、図１３で説明したように、承認ありで、入稿データを受注Ｗｅｂサーバ３に送付する。ただし、入稿データには、発注用JobTicketファイル、プルーフ用JobTicketファイル、プルーフプリント結果を読み取ったスキャン画像データファイル、ステップＳ２０７で取得した実施状況データが含まれる。また、実施状況データには、プリンタのフィニッシャ情報／フォント情報／画像欠け幅／キャリブレーション状況／濃度状況／使用用紙情報、ドライバ設定情報等の各情報が含まれる。そして、処理を終了する。
【０１６６】
次に、ステップＳ２１１について説明する。ステップＳ２１１の処理は、ステップＳ２０９でプルーフ非承認が指示された場合（ステップＳ２０９で「承認しない」）に実行する。ステップＳ２１１では、図６(ａ)で説明した配送先を指定する画面の処理を行い、図６(ｂ)で説明した発注確認画面の処理を行い、ついで、承認なしで、発注用JobTicketファイルを原稿データ等と共に受注Ｗｅｂサーバに送付する。そして、処理を終了する。
【０１６７】
＜＜第３実施形態＞＞
第３実施形態に係る構成は、第１、第２実施形態に係る構成と、プレプルーフプリントの指示、プレプルーフプリント結果をスキャンした画像データの送付における処理が異なる。
【０１６８】
本実施形態に係る構成は第１実施形態に係る構成と大部分が同様である。このため、以下、第１実施形態に係る構成と相違する箇所についてのみ説明を行う。
【０１６９】
（発注処理）
図１５は、本実施形態における、発注処理フローを示したフローチャートであり、第１実施形態の図３と対応する。ステップＳ４１〜ステップＳ４３の処理は、図３のステップＳ１１〜ステップＳ１３の処理と同様である。そして、ステップＳ４４〜ステップＳ４５は、図３のステップＳ１６〜ステップＳ１７と同様である。このため、これらの処理については説明を省略する。
【０１７０】
第１実施形態に係る構成では、図３では、受注Ｗｅｂサーバの画面を用いて、ステップＳ１４のプレプルーフプリントの指示と、ステップＳ１５のプレプルーフプリントの承認を行っていた。これに対し、本実施形態では、ステップＳ４５で発注指示が行わた後に、ＭＦＰ（ＭＦＰ−Ｌ）１２の操作部の画面（ユーザインタフェース）を介して、ステップＳ４７のプレプルーフプリントの指示と、ステップＳ４８のプレプルーフプリントの承認を行う。
【０１７１】
このため、ステップＳ４６では、図５(ａ)と同様な画面を表示して、プレプルーフプリントを行うＭＦＰの選択を受け付け、選択されたＭＦＰに、プレプルーフプリントジョブを送付する。
【０１７２】
ついで、ステップＳ４７では、ＭＦＰ１２が、ログインや、プレプルーフプリント条件の確認、プレプルーフプリントの実行指示などを受け付ける。ＭＦＰ１２は、まず、発注者がログインを行うためのインタフェースを、所定の表示部（不図示）に表示する。発注者はそのＭＦＰ１２のところに移動し、ＭＦＰ１２の操作部（不図示）を利用して、そのＭＦＰ１２に自分のユーザＩＤとパスワードを入力するなどして、ログインを行う。
【０１７３】
発注者のログインに応じて、ＭＦＰ１２は、図１６(ａ)を参照して後述するような、プレプルーフプリントの指示画面を、ＭＦＰ１２の操作部の画面に表示する。発注者は、プレプルーフプリント条件を確認した後に、プレプルーフプリントの実行をＭＦＰ１２に対して指示する。発注者の指示に応じて、ＭＦＰ１２は、プレプルーフプリントを行い、図１６(ｂ)を参照して後述するような、プレプルーフプリントの承認画面を表示する。発注者は、プリントされたプレプルーフプリント結果を、その場で目視で確認する。ＯＫ、即ち、結果に満足した場合、発注者は、プレプルーフプリント結果をＭＦＰ１２の原稿フィーダーにおいてスキャンするべく、ＭＦＰ１２に対してスキャン指示を行う。ＭＦＰ１２は、スキャンの指示に応じてプレプルーフプリント結果のスキャン処理を行う。そして、発注者はプレプルーフプリントの承認を行う。承認に応じて、ＭＦＰ１２は、承認結果と、プレプルーフプリント結果をスキャンした画像データと、プレプルーフプリント実施状況データとを受注Ｗｅｂサーバ３に送付する。
【０１７４】
第２実施形態の構成では、プレプルーフプリント結果をスキャンした画像データは何らかの方法で発注者のＰＣ１に送られ、発注者のＰＣ１から、Ｗｅｂブラウザ経由で、受注Ｗｅｂサーバに送られていた。これに対して、本実施形態の構成では、プレプルーフプリント結果をスキャンした画像データはＭＦＰ１２から直接、Ｗｅｂサーバ３に送られるため、発注者の手間が少ないという利点がある。また、プレプルーフプリント結果をプリントしたＭＦＰ１２のところに、出力結果を取りに行った時にスキャン処理を行えるので、さらに発注者の手間が少ないという利点がある。
【０１７５】
（プレプルーフプリント指示画面）
図１６(ａ)は、ＭＦＰ１２のデバイス操作部における、プレプルーフプリント指示画面を例示した図であり、第２実施形態における受注Ｗｅｂサーバの画面である図１０(ａ)と対応する。発注者によりログインされると、ＭＦＰ１２は、プレプルーフプリントジョブが送付されている場合には図１６(ａ)に例示したプレプルーフプリントの指示画面を、ＭＦＰ１２の操作部の画面に表示する。
【０１７６】
１１０１は、発注先のサービス名や受注ＷｅｂサーバのＵＲＬである。ついで、１１０２は発注者名と、印刷対象となったファイル名とページ数である。ついで、１１０３は、使用プリンタであり、このＭＦＰ１２の名称と種別である。ついで、１１０４〜１１０６は、プレプルーフプリントに反映される印刷／製本体裁であり、これは発注ＰＣ１、ＭＦＰ１２等が自動的に決定する。ついで、１１０８〜１１１０は、図１０と同様、発注者がプレプルーフプリントに反映するかどうかを選択できる印刷／製本体裁である。
【０１７７】
このように、本実施形態では、発注者は、プリントデバイスであるＭＦＰ１２の近辺に移動した後に、ＭＦＰ１２の操作部の画面を用いてプレプルーフプリント条件を確認し、プレプルーフプリントを実行することができる。このため、発注者は、デバイスの状況に応じて、プレプルーフプリント条件を変更することも可能となる。例えば、プレプルーフプリント条件で指定したサイズの紙が用紙切れの場合には、その場で他のサイズに変更してプレプルーフ処理を行うことができる。
【０１７８】
（プレプルーフプリント確認画面）
図１６(ｂ)は、デバイス操作部における、プレプルーフプリント確認画面を例示した図であり、第２実施形態における受注Ｗｅｂサーバの画面である図１０(ｂ)と対応する。ＭＦＰ１２は、図１６(ａ)に例示した画面においてプレプルーフプリントが指示されると、プレプルーフプリントを実行し、図１６(ｂ)に例示した画面を表示する。
【０１７９】
発注者は、プリントされたプレプルーフプリント結果を、その場で目視で確認する。ＯＫ、即ち、プリント結果に満足した場合は、プレプルーフプリント結果をＭＦＰの原稿フィーダーにおいてスキャンするべく、９５のスキャンボタンを押してスキャンを指示する。ＭＦＰ１２は、スキャンの指示に応じてプレプルーフプリント結果のスキャン処理を行う。
【０１８０】
ついで、発注者は、１２０９の入力領域に不図示のキーボードなどを用いて、出力拠点のオペレータに対する作業指示コメントを入力し、承認ボタン９６を押して承認を行う。一方、プレプルーフプリント結果の承認を行わない場合には、承認しないボタン９７を押す。承認された場合には、ＭＦＰ１２は、承認ＯＫ結果と、プレプルーフプリント結果をスキャンした画像データと、プレプルーフプリント実施状況データを受注Ｗｅｂサーバ３に送付する。一方、承認しない場合には、承認ＮＧ結果を受注Ｗｅｂサーバ３に送付する。
【０１８１】
＜＜第４実施形態＞＞
第４実施形態に係る構成は、第１実施形態に係る構成と、発注者のサービス発注フローと、プレプルーフプリント指示における処理が異なる。
【０１８２】
本実施形態に係る構成は第１実施形態に係る構成と大部分が同様である。このため、以下、第１実施形態に係る構成と相違する箇所についてのみ説明を行う。
【０１８３】
（発注処理）
図１７は、本実施形態における、発注処理フローを示したフローチャートである。第１実施形態では、発注者のＰＣ１上のＷｅｂブラウザから受注Ｗｅｂサーバ３にアクセスし、そのＷｅｂ画面で発注処理を行っていた。これに対し、本実施形態では、図１７のステップＳ５１のように、まず、発注者のＰＣ１上で印刷発注したい文書に対応するアプリを起動する。例えば、.doc文書であればワードアプリを起動し、.ppt文書であればプレゼンテーションアプリを起動する。
【０１８４】
ついで、ステップＳ５２では、そのアプリの中から印刷メニューの選択を受け付ける。そして、プリンタドライバとして、発注用専用ドライバの選択を受け付ける。
【０１８５】
ついで、ステップＳ５３では、第１実施形態の図４(ｂ)に例示した画面と同様の、発注用印刷／製本体裁指定画面で、発注用印刷／製本体裁の指定を受け付ける。
【０１８６】
ついで、ステップＳ５４では、図１８を参照して後述するような画面を介して、ローカルプリンタに対するプレプルーフプリント指示を受け付ける。ステップＳ５４で、プレプルーフプリント指示が行われると、発注ＰＣ１は、印刷発注したい文書をＰＤＬデータに変換し、ローカルプリンタにＰＤＬデータとプレプルーフ用ジョブチケットとを送出してプレプルーフプリントを実行する。一方、受注Ｗｅｂサーバ３に対してはＰＤＬデータと、発注用ジョブチケットを送出して入稿を行う。
【０１８７】
ついで、ステップＳ５５では、発注用専用ドライバは受注Ｗｅｂサーバ３にアクセスするためのＷｅｂブラウザを起動して自身は終了する。そして、発注ＰＣ１は、Ｗｅｂブラウザを介して、第１実施形態の図５(ｂ)と同様なプレプルーフプリント確認画面を表示し、発注者によるプレプルーフの承認を受け付ける。
【０１８８】
ステップＳ５６以降の処理は、第１実施形態における図３のステップＳ１６以降の処理と同様である。
【０１８９】
以上のように、本実施形態では、各文書のアプリを起動し、その印刷メニューで発注用専用ドライバの選択を受け付け、その中でプレプルーフプリント指示を行うように構成している。これにより、アプリ（アプリケーション）からの通常のプリントと同じような手順で、プレプルーフプリントを行うことができ、同時に、受注Ｗｅｂサーバへの入稿が行うことができる。また、第１実施形態では、アプリファイルを直接、Ｗｅｂサーバへ入稿していたが、本実施形態では、発注用専用ドライバでアプリファイルをＰＤＬデータに変換してから入稿するようにしている。このため、例えば、出力拠点側でサポートしていないアプリのファイルも、ＰＤＬデータに変換して入稿することができる。また、本実施形態では、発注用専用ドライバはアプリファイルをＰＤＬデータに変換して入稿しているが、例えば、ＰＤＦデータに変換して入稿するようにしても良い。
【０１９０】
（プレプルーフプリント指示画面）
図１８は、第４実施形態の発注フローにおける、発注者ＰＣ１上の発注用専用プリンタドライバのプレプルーフプリント指示画面を例示した図である。これは、図１７のステップＳ５４において表示するものである。
【０１９１】
第１実施形態の図５(ａ)に例示した画面と図１８に例示した画面とでは、主に相違点が２つある。第１の違いは、図５(ａ)に例示した画面は受注Ｗｅｂサーバ３が作成したＷｅｂ画面であったが、図１８は発注用専用プリンタドライバの画面である。第２の違いは、図５(ａ)に例示した画面では、プレプルーフプリントに反映する印刷／製本体裁や反映しない印刷／製本体裁は情報処理装置が自動的に決定していた。これに対し、図１８に例示した画面では、発注者が自由に選べるようにしている。このため、本実施形態に係る構成においては、第１実施形態に係る構成と比べて、発注者の選択の自由度が増しており、例えば、プレプルーフプリントにかかる費用を節約するような選択が可能である。
【０１９２】
図１８では、ポスター印刷サービスを発注する例を示していて、発注用印刷／製本体裁として、Ａ１サイズのカラー片面ポスターを厚紙で印刷し、ラミネート加工し、パネル加工することが指示されている。これをローカルプリンタ１２でプレプルーフプリントを行う場合、通常はローカルプリンタではＡ１サイズを印刷できないので、１３０２では、サイズがＡ３に変更されている。ついで、１３０３では、例えばレイアウトの確認のみを行う場合は白黒で良いので、コストの安い白黒に変更されている。
【０１９３】
ついで、１３０４では、ポスターは片面ではあるが両面で印刷する旨設定されている。これは、プルーフは両面印刷で十分であり、用紙を節約するためである。ついで、１３０５では、厚紙でのプルーフが不要な場合に、入手しやすい普通紙に変更されている。ついで、１３０７、１３０８では、通常はローカルプリンタではラミネート加工もパネル加工もできないので、これらを行わない旨が設定されている。
【０１９４】
以上のように構成することにより、プレプルーフプリントに反映する印刷／製本体裁を、プルーフの目的に応じて、発注者が自由に選ぶことが可能となる。
【０１９５】
以上のように第１乃至第４実施形態に例示した構成によれば、発注前にローカルプリンタを使って印刷した紙でプルーフを行った後に、そのプルーフ条件とプルーフ結果とを原稿データと合わせてプリントサービスに入稿する。これにより、発注者は発注前に充分な確認をすることができる。さらに、発注後に印刷拠点で行っていたプルーフ工程を省略した場合でも、発注者が意図した印刷結果とプリントサービスの出力拠点における実際の印刷結果との食い違いを低減することができる。さらに、従来の現物プルーフ方式に比べて、プルーフにかかる時間や手間を低減することができる。さらに、ローカルプリンタでのプリント用のパラメータと、発注用のパラメータとを、個別に入力する必要がなく、このため、両者間の転記ミスをなくすことができる。
【図面の簡単な説明】
【０１９６】
【図１】プリントサービス発注システムの全体構成図である。
【図２】受注Ｗｅｂサーバに対するサービス発注画面を例示した図である。
【図３】発注者ＰＣ１上の、出力／製本サービスの発注処理フローの概要を説明する図である。
【図４】原稿の電子データの入稿を受け付ける画面、及び、印刷／製本体裁の指定を受け付ける画面を例示した図である。
【図５】プレプルーフプリント指示画面、及び、プレプルーフプリント確認画面を例示した図である。
【図６】配送体裁指定を受け付ける画面、及び、発注確認を行う画面を例示した図である。
【図７】受注Ｗｅｂサーバに対する発注時に、受注Ｗｅｂサーバに入稿されるデータを例示した図である。
【図８】受注Ｗｅｂサーバに対する発注時の、発注者ＰＣ１上が実行する処理の流れを示したフローチャートである。
【図９】出力製本サービス処理の流れを示したフローチャートである。
【図１０】プレプルーフプリント指示画面、及び、プレプルーフプリント確認画面を例示した図である。
【図１１】発注用JobTicketを例示した図である。
【図１２】プルーフ用JobTicketを例示した図である。
【図１３】受注Ｗｅｂサーバに対する発注時に、受注Ｗｅｂサーバに入稿されるデータを例示した図である。
【図１４】発注者ＰＣ上が実行する、受注Ｗｅｂサーバに対する発注時の制御フローを示したフローチャートである。
【図１５】発注処理フローを示したフローチャートである。
【図１６】ＭＦＰ１２のデバイス操作部における、プレプルーフプリント指示画面、及び、プレプルーフプリント確認画面を例示した図である。
【図１７】発注処理フローを示したフローチャートである。
【図１８】発注用専用プリンタドライバのプレプルーフプリント指示画面を例示した図である。
【図１９】情報処理装置のハードウェア構成を模式的に示したブロック図である。
【図１】
2007122092.tif 000003
【図２】
2007122092.tif 000004
【図３】
2007122092.tif 000005
【図４】
2007122092.tif 000006
【図５】
2007122092.tif 000007
【図６】
2007122092.tif 000008
【図７】
2007122092.tif 000009
【図８】
2007122092.tif 000010
【図９】
2007122092.tif 000011
【図１０】
2007122092.tif 000012
【図１１】
2007122092.tif 000013
【図１２】
2007122092.tif 000014
【図１３】
2007122092.tif 000015
【図１４】
2007122092.tif 000016
【図１５】
2007122092.tif 000017
【図１６】
2007122092.tif 000018
【図１７】
2007122092.tif 000019
【図１８】
2007122092.tif 000020
【図１９】
2007122092.tif 000021