JP2017211940A - 画像処理システム及び画像処理方法 - Google Patents

Abstract

【課題】 複数の注文データを処理する際に、いずれかの画像処理装置において画像処理が実行できなくなった場合であっても、画像処理を適切に完了させること。【解決手段】 データサーバは、受け付けた注文に対応する注文データを保存し、管理手段は、注文のステータスとして決済ステータスを管理し、各ダウンローダは、データサーバから注文データを取得し、処理対象の注文データのステータスが決済済みとなった場合、取得した注文データに画像処理を実行し、画像処理を実行した処理済みデータを出力し、第１画像処理装置の接続状態が非接続となったことが特定された場合、接続されている画像処理装置に第１画像処理装置に割当てられていた注文を割り当て、各画像処理装置は、非接続状態から接続状態になる場合、取得済みの注文データを削除する。【選択図】 図１１

Description

本発明は、データサーバーに保存された画像データを複数の画像処理装置により実行する画像処理システム及び画像処理方法に関するものである。

近年、顧客がフォトアルバムをオンラインで注文するシステムが知られている。顧客は自分の端末装置から、写真アルバム生成アプリケーションを用いて、写真をページに配置し、フォトアルバムのデザインなどを決定して、アルバムの制作を注文する。すると、顧客情報とデータコンテンツがサーバーにアップロードされる。フォトアルバムを受注したアルバム制作者は、アップロードされたデータをダウンロードして電子データを作成し、この電子データをプリンタに送信することによって印刷を行い、製本をして、アルバムを制作する。

ところで、生産性を向上するために、複数の画像形成装置を連結動作させて、並行して処理を実行させる画像形成システムが知られている（特許文献１参照）。

特開２００１−７９６１号公報

しかしながら、特許文献１のような画像形成システムを、オンラインで注文するシステムに適用した場合、問題が生じてしまう。例えば、ジョブを割り振った後に、いずれかの画像処理装置が何らかの理由によりシャットダウンしてしまった場合、割り振られたジョブの印刷が遅れてしまう。また、注文システムの場合、決済が確定してから処理を実行することがある。すなわち、画像形成装置は、注文データを取得した後、注文が「決済済み」に変わった時点で画像処理を実行することがある。しかしながら、決済済みに変わった時点でその画像処理装置がシャットダウン等の理由により外部装置と接続できない場合、決済済みになったことを認識できず、処理が実行されなくなってしまう。

上述のような課題を解決するための本発明の画像処理システムは、データサーバーと、画像処理を実行する複数の画像処理装置と、を有する画像処理システムであって、
注文を受け付ける受付手段と、
前記受付手段が受け付けた注文を各画像処理装置に対して割り当て割当手段と、
前記受付手段により受け付けた注文のステータスを管理する管理手段と、
前記各画像処理装置の接続状態を監視する監視手段と、
を有し、
前記データサーバーは、前記受付手段により受け付けた注文に対応する注文データを保存し、
前記管理手段は、前記注文のステータスとして決済ステータスを管理し、
前記各画像処理装置は、
前記データサーバーから注文データを取得する取得手段と、
処理対象の注文データの前記決済ステータスが決済済みとなった場合、前記取得手段により取得した注文データに画像処理を実行する実行手段と、
前記実行手段により画像処理を実行した処理済みデータを出力する出力手段と、
を有し、
前記監視手段により第１画像処理装置の接続状態が非接続となったことが特定された場合、前記割当手段は、前記複数の画像処理装置のうち接続されている画像処理装置に前記第１画像処理装置に割当てられていた注文を割り当て、
各画像処理装置は、非接続状態から接続状態になる場合、取得済みの注文データを削除する。

本発明によれば、複数の注文データを処理する際に、いずれかの画像処理装置において画像処理が実行できなくなった場合であっても、画像処理を適切に完了させることができる。

実施形態１に係るフォトアルバムを作成するシステムの概念図である。 実施形態１に係る各装置のハードウェア構成を示す図である。 実施形態１に係るダウンローダーアプリが提供する画面の図である。 実施形態１に係る画像処理サーバーのダウンロード処理のフローである。 実施形態１に係る画像処理サーバーのインポーター処理のフローである。 実施形態１に係る自動ダウンロードの３つのモードについて説明する図である。 実施形態１に係るＤＨＳが保持するＤＣＳリストの一例である。 自動ダウンロードの対象となる注文の特定処理のフローチャートである。 注文データのダウンロード指示のフローチャートである。 注文データのダウンロード処理を受けたＤＣＳのフローチャートである。 ＤＣＳのステータスを監視処理のフローチャートである。 非同期処理完了状態になったＤＣＳに対してダウンロード完了のための処理を指示するフローチャートである。 ダウンロード完了ファイル未作成リストの一例である。 注文一覧の取得処理のフローチャートである。 ＤＨＳのシャットダウン処理のフローチャートである。 ＤＣＳの終了処理のフローチャートである。 ＤＨＳの再起動処理のフローチャートである。 ＤＣＳの初期化処理のフローチャートである。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜実施形態１＞
図１は、画像処理システムの一例として、フォトアルバムを作成するシステムの構成の一例を示す図である。フォトアルバムを作成するシステムは、情報処理装置１００と、画像処理システムと、プリントシステム１６０とを有する。図１において、フォトアルバムを作成する画像処理システムは、認証サーバー１１０、注文サーバー１２０、データサーバー１３０、ダウンローダーＰＣ１４０、ダウンローダーＰＣ１５０を含む。認証サーバー１１０、注文サーバー１２０、データサーバー１３０、ダウンローダーＰＣ１４０、ダウンローダーＰＣ１５０は、それぞれ、例えば、一般的なパーソナルコンピュータで構成される。

情報処理装置１００は、注文サーバー１２０と、データサーバー１３０と、ネットワークを介して接続されている。

認証サーバー１１０は、ダウンローダーＰＣ１４０及びダウンローダーＰＣ１５０とそれぞれ、ネットワークを介して接続されている。

注文サーバー１２０は、ダウンローダーＰＣ１４０及びダウンローダーＰＣ１５０とそれぞれ、ネットワークを介して接続されている。

データサーバー１３０は、ダウンローダーＰＣ１４０及びダウンローダーＰＣ１５０とそれぞれ、ネットワークを介して接続されている。

また、ダウンローダーＰＣ１４０と、ダウンローダーＰＣ１５０とは、ネットワークを介して接続されている。

情報処理装置１００は、顧客の端末装置であり、例えば、ＰＣ、スマートフォン等から構成される。また、情報処理装置１００は、フォトアルバムを作成するためのアプリケーションソフトウェア（アルバムアプリともいう）を有している。ユーザは、フォトアルバムを作成するためのアプリケーションソフトウェアを用いて、フォトアルバム用の画像データを生成し、アルバムの制作を注文することができる。なお、フォトアルバム用の画像データは、情報処理装置１００に保存されている画像データ又はクラウド上の画像データを用いて、画像データに基づく画像を１以上配置したレイアウト画像を複数生成することで、生成される。

認証サーバー１１０は、注文サーバー１２０へのアクセスに際して必要となる認証情報を保持するサーバーである。

注文サーバー１２０は、注文を受け付ける受付サーバーであり、顧客により発注された注文をリスト化した注文一覧を保持する。すなわち、注文を受けると、注文サーバー１２０の注文一覧に追加される。 データサーバー１３０は、各注文データの内容を保持するサーバーである。注文データは、顧客により発注された注文情報と、フォトアルバム用の画像データと、画像データをフォトアルバムの各ページに面付けするためのレイアウト情報とを含む。本実施形態では、アルバムの画像に関するデータ（画像データ及びレイアウト情報）をアルバムデータともいう。注文情報は、注文識別情報と、配送情報と、成果物情報を含む。注文識別情報は、当該注文を識別するための情報であって、注文日時や注文番号や発注者情報などにより構成される。配送情報は、プリントシステム１６０において製造された成果物の配送先に関する情報であって、配送番号と、納期と、配送先住所などにより構成される。成果物情報は、当該注文に含まれる成果物に関する情報であって、フォトアルバムの商材種別と、数量などにより構成される。各ＤＣＳはアルバムデータをデータサーバー１３０からダウンロードする。本実施形態では、ネットワークトラフィックを考慮して、顧客が注文したフォトアルバム用の１つの注文データは、分割して保持されている。

ここで、注文サーバー１２０の注文の受付について説明する。

（１）情報処理装置１００のアルバムアプリにおいて、ユーザが注文ボタンを選択すると、アルバムアプリは、注文サーバー１２０に対して、データをアップロードしてよいか問い合せをする。
（２）問合せを受けた注文サーバー１２０が、データをアップロードしてよいという応答をアルバムアプリに送信する。
（３）応答を受けたアルバムアプリは、分割したデータの１つ目の保存先を注文サーバー１２０に問い合わせる。
（４）問合せを受けた注文サーバー１２０は、アップロード先のＵＲＬ（データサーバ１３０の所定のＵＲＬ）をアルバムアプリに応答する。
（５）アルバムアプリは、指定されたＵＲＬにデータをアップロードする。
（３）〜（５）の処理を繰り返すことにより、注文１つ分のデータをアップロードする。

ダウンローダーＰＣ１４０及びダウンローダーＰＣ１５０は、画像処理を実行する画像処理サーバー（画像処理装置）である。 ダウンローダーＰＣ１４０は、ダウンローダークライアントサービス（以下、ＤＣＳ）１４１と、ダウンロードフォルダ１４２と、インポーターサービス１４３と、入稿フォルダ１４４と、を有する。さらに、ダウンローダーＰＣ１４０は、ダウンローダーアプリ１４５と、ダウンローダーホストサービス（以下、ＤＨＳ）１４６と、を有する。

ダウンローダーＰＣ１５０は、ＤＣＳ１５１と、ダウンロードフォルダ１５２と、インポーターサービス１５３と、を有する。

ＤＨＳ１４６は、管理対象のダウンローダーＰＣが提供する各種機能の実行を制御するサービスアプリケーションである。より具体的には、ＤＨＳ１４６は、ＤＣＳ１４１及びＤＣＳ１５１の制御を行う。

ＤＣＳ１４１は、ホストであるダウンローダーＰＣ１４０上で動作するＤＨＳ１４６からの指示を受けて、注文サーバー１２０から注文一覧をダウンロードするサービスアプリケーションである。さらに、ＤＣＳ１４１は、ホストであるダウンローダーＰＣ１４０上で動作するＤＨＳ１４６からの指示を受けて、データサーバー１３０から注文データをダウンロードする。注文データのダウンロード処理には時間がかかる。そのためＤＨＳ１４６から指示を受けたＤＣＳは、ＤＨＳと非同期でダウンロード処理を開始する。

インポーターサービス１４３は、ダウンローダー処理においてダウンロードされたデータをプリントシステム１６０向けのデータに変換して（入稿データ変換処理）出力するサービスアプリケーションである。ダウンロードフォルダ１４２に出力されたダウンロード完了ファイルを確認したら、それに紐づく注文データをダウンロードフォルダ１４２から取り込んで、プリントシステム１６０向けのデータを入稿フォルダ１４４に出力する。すなわち、プリントシステム１６０が処理可能なデータに変換して、入稿フォルダ１４４に出力する。具体的には、ダウンロードフォルダ１４２から取り込んだ注文データ（画像データ）を復号化し、画像変換を行い、面付け処理を行い、注文情報を変換して得られた処理済みの画像データを含む処理済みアルバムデータを、入稿フォルダ１４４に出力する。入稿フォルダ１４４のパス情報は、インポーターサービス１４３の設定ファイルに記載して、インポーターサービス１４３が起動時にその設定ファイルを読み込むことで、パスが設定される。

また、ＤＣＳ１５１は、ＤＣＳ１４１と同様の機能を有し、ダウンロードフォルダ１５２は、ダウンロードフォルダ１４２と同様の機能を有し、インポーターサービス１４３は、インポーターサービス１５３と同様の機能を有するので、説明を省略する。入稿フォルダ１４４は、ダウンローダーＰＣ１４０のインポーターサービス１４３からの入稿データを受付けるだけでなく、ダウンローダーＰＣ１５０のインポーターサービス１５３からの入稿データを受付ける。

ダウンローダーアプリ１４５は、ダウンロード指示やダウンロード状況の確認を行うためのアプリケーションであり、ダウンローダーＰＣ１４０の表示部に、ダウンロードの指示やダウンロードの状況を確認するための表示画面を提供する。プリントシステム１６０は、入稿フォルダ１４４から送信された処理済みアルバムデータを受信して、ユーザが注文したフォトアルバムを作成する。まず、印刷は、プリントシステムに含まれる画像形成装置において実行される。処理済みのアルバムデータは、例えば、印刷設定等が記載されているプリントチケットと、処理済み画像データを含む。そして、印刷したものを製本して、アルバムを制作する。

ここで、アルバムの注文処理について説明する。

情報処理装置１００が、アルバムアプリを介して、フォトアルバムの作成依頼を指示すると、注文をした顧客の情報（顧客情報）が注文サーバー１２０へ送信されると共に、注文データがデータ―サーバー１３０へ送信される。

ここで、注文の割り振り及びダウンロード処理について説明する。

ＤＨＳ１４６は、ＤＣＳ１４１に注文一覧の取得指示を送信する。なお、ＤＨＳ１４６は、ダウンローダーアプリ１４５が起動していなくても、定期的に自動で注文一覧の取得指示を送信する。

ＤＣＳ１４１は、注文一覧の取得指示を受信すると、注文サーバー１２０から注文一覧の情報を取得し、ＤＨＳ１４６へ送信する。

ＤＨＳ１４６は、注文一覧を解釈して、ＤＣＳのいずれにも割り当てられていない注文を、ＤＣＳに割り当てる。すなわち、ＤＨＳ１４６は、注文サーバー１２０が受付けた複数の注文を、複数の画像処理サーバーに注文単位で振り分け（割り当て）する。

また、ＤＨＳ１４６は、ＤＣＳの状態及び各注文のステータスを定期的に監視する（監視処理）。なお、監視処理で監視するＤＣＳの状態については、詳細は後述するが、ＤＣＳの接続状態、ＤＣＳステータス、使用中フラグ等である。ＤＨＳ１４６は、ダウンロード処理を行っておらず且つ待機状態になっているＤＣＳに対して、ダウンロード処理の指示をする。ＤＨＳ１４６は、ＤＣＳに指示を送信した場合、ＤＣＳのダウンロード処理完了の応答を待たずに、自身の処理を続行する。

ＤＣＳは、自身に割当てられた注文の注文データをデータサーバー１３０から取得する。具体的には、ＤＣＳ（１４１，１５１）は、ＤＨＳ１４６から注文のダウンロード指示を受けると、認証サーバー１１０から認証情報を取得して、注文サーバー１２０にアクセスして、注文データのＵＲＬを取得する。そして、ＤＣＳ（１４１，１５１）は、取得したＵＲＬに基づき、データサーバー１３０から注文データをダウンロードする。本実施形態では、注文情報は、分割されているため、分割されたファイルそれぞれに対してＵＲＬの取得及びダウンロードを実行する。次に、分割ファイルを結合してデータの妥当性をチェックサムなどを用いて確認する。ＤＣＳ１４１は、結合した結果のデータを、注文データとしてダウンロードフォルダ１４２に出力する。また、ＤＣＳ１５１は、結合した結果のデータを、注文データとしてダウンロードフォルダ１５２に出力する。

ＤＨＳ１４６は、監視処理によりＤＣＳが注文データのダウンロードを完了したことを検知した場合、そのダウンロードが完了したＤＣＳに対して、ダウンロード完了処理を指示する。

ＤＣＳ（１４１，１５１）は、ダウンロード完了処理の指示を受信した場合、ダウンロード完了処理を行う。なお、ダウンロード完了処理とは、ダウンロードフォルダ（１４２，１５２）に、ダウンロード完了ファイル（トリガファイル）を保存する処理である。すなわち、ＤＣＳは、該当する注文データに紐づくダウンロード完了ファイルをダウンロードフォルダ（１４２，１５２）に出力する。なお、ダウンロードフォルダ（１４２，１５２）のパスは、ＰＣ毎に設定する。ダウンロードフォルダ１４２のパスの情報はＤＣＳ１４１の設定ファイルに記載しておき、これをＤＣＳ１４１が起動時に読み込むことで、パスが設定される。ダウンロードフォルダ１５２のパスの情報はＤＣＳ１５１の設定ファイルに記載しておき、これをＤＣＳ１５１が起動時に読み込むことで、パスが設定される。すなわち、ＤＨＳ１４６は、ダウンロードフォルダ（１４２，１５２）のパスを関知しない。

また、ＤＨＳ１４６は、ＤＣＳがダウンロード完了処理を終了した場合、監視処理によりそれを検知することができる。ＤＨＳ１４６がＤＣＳによるダウンロード完了処理が終了したことを検知したら、注文サーバー１２０に対して、ダウンロードが完了したことを通知する。

インポーターサービス（１４３、１５３）の処理は、上述した通りである。インポーター処理が完了した後はインポート完了ファイルを入稿フォルダ１４４に出力する。後段のプリントシステムは、このインポート完了ファイルが出力されたことを受けて適切なタイミングでプリントシステム１６０における処理を開始する。
このように、本実施形態では、注文サーバー１２０が受付けた複数の注文を、複数の画像処理サーバーに注文データ単位で振り分けて、並列して画像処理を実行する。本実施形態では、ダウンローダーＰＣ１４０が、ホストとして機能し、ダウンロードを行うＤＣＳを自動的に選んで当該ＤＣＳが動作するＰＣ（ＰＣ１４０もしくはＰＣ１５０）をクライアントＰＣとして処理を実行する。なお、図１では、画像処理サーバーを２つとしたが、これに限定されず、３以上であってもよい。 図２（ａ）は、認証サーバー１１０のハードウェア構成の一例を表す図である。なお、ここでは、認証サーバー１１０の構成を例に挙げて説明するが、注文サーバー１２０、データサーバー１３０、ダウンローダーＰＣ１４０、ダウンローダーＰＣ１５０もそれぞれ同様の構成を有する。

図２に示す通り、認証サーバー１１０は、ＲＡＭ２１１、ＨＤＤ２１２、操作部２１３、ＣＰＵ２１４と、通信制御部２１５と、表示部２１６とを有する。また、認証サーバー１１０は、少なくとも図２に示す各ブロックを互いに通信可能に接続するバス２１７を含む。

ＲＡＭ２１１は、ＣＰＵ２１４の作業領域として用いられ、また、各データの一時格納領域として用いられる。

ＣＰＵ２１４は、認証サーバー１１０の全体を制御する制御部である。

ＨＤＤ（ハードディスクドライブ）２１２は、不揮発性の記憶部であり、各種データや、ＣＰＵ２１４が実行するためのプログラムを記憶する。なお、ＨＤＤ２１２の代わりに、可搬性ＣＤ−ＲＯＭまたは内部据付のＲＯＭ等が記憶部として用いられてもよい。

操作部２１３は、ユーザインターフェースであり、ハードキーやタッチパネル等の入力部を含む。表示部２１６は、各種情報を表示する表示部である。なお、タッチパネルの場合は、表示部２１６と操作部２１３との少なくとも一部が一体となっている。

通信制御部２１５は、外部装置との通信接続を可能とする。例えば、外部装置から、画像データ等を受信する。

ここで、情報処理装置１００は、例えば、ＰＣ、スマートフォン等からなり、上述した認証サーバー１１０と同様のハードウェア構成を有している。そして、ＨＤＤ２１２に、画像をレイアウトするアプリケーションソフトウェアが、コンピュータプログラムの１つとして保存されている。なお、アプリケーションソフトウェアは、例えば、外部装置からダウンロードして、ＨＤＤ２１２に保存される。

図２（ｂ）は、プリントシステム１６０に含まれる画像形成装置２００のハードウェア構成の一例を表す図である。画像形成装置２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、通信制御部２０５、操作部２０６、画像処理部２０７、エンジン制御部２０８を備え、それぞれがシステムバス２０９を介して接続される。

ＣＰＵ２０１は、マイクロプロセッサ形態の中央演算処理部である。ＣＰＵ２０１は、プログラムの実行やハードウェアの起動により画像形成装置２００全体の動作を制御する。ＲＯＭ２０２は、ＣＰＵ２０１が実行するためのプログラムや画像形成装置２００の各種動作に必要な固定データを格納する。ＲＡＭ２０３は、ＣＰＵ２０１がワークエリアとして用いられたり、種々の受信データの一時格納領域として用いられたり、各種設定データを記憶させたりする。ＨＤＤ２０４は、ＣＰＵ２０１が実行するためのプログラム、印刷データ、画像形成装置２００の各種動作に必要な設定情報を、内蔵するハードディスクに記憶させたり、読み出したりすることが可能である。

操作部２０６は、ユーザが種々の操作を行うためのハードキーやタッチパネル、またユーザに種々の情報を提示（通知）するための表示部を含む。また、ユーザへの情報の提示は、音声発生器からの音響情報に基づく音響（ブザー、音声等）を出力することによっても行うこともできる。

画像処理部２０７は、画像形成装置２００で扱う印刷データ（例えば、ページ記述言語で表されたデータ）の画像データ（ビットマップ画像）への展開（変換）や画像処理を行う。入力された印刷データに含まれる画像データの色空間（たとえばＹＣｂＣｒ）を、標準的なＲＧＢ色空間（たとえばｓＲＧＢ）に変換する。また、画像データに対し、画像形成装置２００が印刷処理可能な画素数への解像度変換、画像解析、画像補正等、様々な画像処理が必要に応じて施される。これらの画像処理によって得られた画像データは、ＲＡＭ２０３または、ＨＤＤ２０４に格納される。

エンジン制御部２０８は、ＣＰＵ２０１等から受信した制御コマンドに応じて、印刷データに基づく画像をシート上に印刷する処理の制御を行う。印刷データに応じて印刷ヘッドの駆動制御を行い、印刷ヘッドからインクを吐出させ、シート上に画像を形成させる。

ここで、図３を用いて、ダウンローダーアプリ１４５が提供する画面について説明する。図３は、ダウンローダーＰＣ１４０の表示部に表示されるダウンローダーアプリ１４５が提供する確認画面である。ＤＨＳ１４６が、注文サーバー１２０から注文一覧の情報を取得すると、ダウンローダーアプリ１４５は、取得した注文一覧の情報に基づいて、図３（ａ）に示す管理画面を表示する。なお、取得した注文一覧の情報は、ダウンローダーＰＣ１４０のメモリに保存されており、注文毎に、入稿番号、注文ステータス、決済ステータス、ダウンロード完了日時、部数等の情報を含む。なお、注文一覧はメモリではなく、ＨＤＤに保存してもよい。

管理画面は、注文サーバー１２０が受付けた注文一覧（３０１〜３０５）と、自動ダウンロード設定ボタン３０６と、ダウンロードボタン３０７と、を表示する。注文一覧は、注文毎に後述する各種情報を表示する。図３（ａ）では、各種情報として、入稿番号３０１、注文ステータス３０２、決済ステータス３０３、ダウンロード完了日時３０４、部数３０５を表示する。なお、各種情報はこれらに限定されるものではない。入稿番号３０１は、注文データを識別するための情報である。注文ステータス３０２は、注文済、ダウンロード済、出荷済、キャンセル済のいずれかのステータスとなる。「注文済」は、顧客が注文した状態であって、ダウンロード処理が行われていない注文である。「ダウンロード済」は、注文がされた後、ダウンロード処理が行われた状態であって、出荷が完了していない注文である。「出荷済」は、出荷が完了した注文である。「キャンセル済」は、キャンセルされた注文である。決済ステータス３０３は、未決済、決済、不明のいずれかのステータスとなる。注文サーバー１２０から取得した注文のうち、決済が済んでいない注文を「未決済」とし、決済が済んでいる注文を「決済」とする。そのいずれにも該当しないものを「不明」とする。

ユーザが画面上で、対象とする注文を選択して、ダウンロードボタン３０７をクリックすると、ダウンローダーアプリ１４５は、ＤＨＳ１４６に該当する注文のダウンロードを指示する。このように、ユーザの選択に基づく操作を「手動ダウンロード」と呼ぶ。

また、本実施形態では、ダウンローダーＰＣ（１４０、１５０）には、自動ダウンロード機能がある。自動ダウンロード機能とは、指定した時間帯になったら、未ダウンロードの注文を自動的にダウンロードするものである。

ユーザが自動ダウンロード設定ボタン３０６をクリックすると、図３（ｂ）に示すような自動ダウンロードの設定画面を表示する。

設定画面は、前述した自動ダウンロードの条件を設定するための画面である。自動ダウンロードを行いたい場合には、「定期的に自動ダウンロードを行う」という表示５０１に対応するチェックボックスを有効にする。自動ダウンロードを行わない場合は、「自動ダウンロードしない」という表示５０４に対応するチェックボックスを有効にする。すなわち、チェックボックスは、いずれか一方のみが選択可能である。

「定期的に自動ダウンロードを行う」のチェックボックスが選択された場合には、さらに条件を設定することができる。図４（ｂ）では、１つ目の条件として、自動ダウンロードを行う時間間隔を設定することができる。表示部５０２に、設定したい時間を入力することができる。例えば、６０分ごとにダウンロードを行いたい場合は、「６０」を入力すればよい。

また、図４（ｂ）では、２つ目の条件として、未決済の注文について自動ダウンロードを行うか否かを設定することができる。「未決済の注文をダウンロードする」という５０３に対応するチェックボックスを有効にすると、未決済の注文について自動ダウンロードを行うことができるようになる。一方、チェックボックスにチェックをしない場合は、未決済の注文について自動ダウンロードを行わない。

図４を用いて、各画像処理サーバー（ダウンローダーＰＣ１４０、ダウンローダーＰＣ１５０）のＤＣＳが実行するダウンロード処理について説明する。なお、図４に示すフローは、各画像処理サーバーのＣＰＵ２１４がメモリに格納されたプログラムをＲＡＭ２１１にロードすることにより実行される。ここでは、ダウンローダーＰＣ１４０を例に挙げて説明する。

図４に示すように、ＤＣＳ１４１は、ＤＨＳ１４６から当該注文のダウンロード指示を受けると、認証サーバー１１０から認証情報を取得して、注文サーバー１２０にアクセスして、注文データのＵＲＬを取得する（Ｓ３０１）。

次に、ＤＣＳ１４１は、取得したＵＲＬに基づき、データサーバー１３０から注文データの注文情報をダウンロードする。本実施形態では、注文情報は、分割されているため、分割されたファイルそれぞれに対してＵＲＬの取得及びダウンロードを実行する（Ｓ３０２）。

次に、分割ファイルを結合してデータが妥当であるか確認する。具体的には、データの妥当性をチェックサムなどを用いて確認する（Ｓ３０３）。

データが妥当であった場合は、ＤＣＳ１４１は、結合した結果のデータを、注文データとしてダウンロードフォルダ１４２に出力する。ＤＣＳ１４１は、注文データを出力したあと、該当する注文データに紐づくダウンロード完了ファイルをダウンロードフォルダ１４２に出力する（Ｓ３０４）。なお、ダウンロードフォルダ１４２に出力する条件は、後述するモードに応じて異なる。

これにより、ダウンロード処理は、終了する。

図５を用いて、各画像処理サーバー（ダウンローダーＰＣ１４０、ダウンローダーＰＣ１５０）のインポーターサービスが実行するインポーター処理について説明する。なお、図５に示すフローは、各画像処理サーバーのＣＰＵ２１４がメモリに格納されたプログラムをＲＡＭ２１１にロードすることにより実行される。ここでは、ダウンローダーＰＣ１４０を例に挙げて説明する。

図５に示すように、インポーターサービス１４３は、インポーター設定ファイルを参照する（Ｓ５０１）。インポーター設定ファイルとは、インポーターサービス１４３が参照するフォルダを設定するものである。前述したように、インポーターサービスは、起動時に前述の設定ファイルを参照する。

次に、インポーターサービス１４３は、ダウンロードフォルダ１４２へのダウンロード完了ファイルの出力を定期的に監視する（Ｓ５０２）。すなわち、ダウンロードフォルダ１４２にアクセスし、ダウンロード完了ファイルが保存されているか確認する。

次に、ダウンロード完了ファイルが存在することを確認した場合、プリントシステム１６０向けの注文データに変換処理を行う（Ｓ５０３）。すなわち、ダウンロード完了ファイルを、プリントシステム１６０へ入稿するデータに変換する（入稿データ変換処理）。

変換してできた注文データ（入稿データ）を、入稿フォルダ１４４に出力する（Ｓ５０４）。

これにより、インポーター処理は、終了する。

図６を用いて、図３（ｂ）に示す画面において、未決済の注文を自動ダウンロードする設定にした場合の自動ダウンロードの動作モードについて説明する。

本実施形態では、図６に示すように、未決済の注文に対する自動ダウンロードの動作モードが３つある。

モード１は、自動ダウンロードの実行時に、未ダウンロードの注文データのうち決済済みの注文だけをダウンロードフォルダにダウンロードするモードである。

モード２は、自動ダウンロードの実行時に、未ダウンロードの注文データであれば、未決済の注文をダウンロードするが、ダウンロード完了ファイルは、ダウンロードフォルダ（１４２，１５２）に出力しないモードである。ダウンロードフォルダ（１４２，１４５）にダウンロード完了ファイルを出力しないため、インポーターサービスの取り込み対象とはならない。このモードでは、インポーターサービスに取り込まれないため、入稿フォルダ１４４には注文データが出力されず、プリントシステム１６０へはデータは送信されない。すなわち、モード２は、ダウンロード処理は行うが、インポーター処理を開始しないモードである。インポーター処理が開始されるためには、当該注文の決済ステータスが、未決済から決済に変わる必要がある。決済ステータスが、決済に変わったと判定されると、ダウンロード完了ファイルをダウンロードフォルダに出力され、インポーターの取り込み対象となる。

モード３は、自動ダウンロードの実行時に、未ダウンロードの注文データであれば、未決済の注文をダウンロードし、ダウンロード完了ファイルもダウンロードフォルダ（１４２，１５２）に出力するモードである。インポーターの取り込み対象となる。したがって、入稿フォルダ１４４に注文データが出力される。

前述のモード２に対する処理について述べる。ＤＨＳ１４６は、図１３に示すような、管理対象のＤＣＳ（１４１，１５１）がダウンロードした各注文のリストを作成し、ダウンローダーＰＣ１４０内のメモリに保持する。このリストに保持されている注文については、注文サーバー１２０を定期的にポーリングすることで、決済ステータスの変化を監視する。以後は、ダウンロード済み、かつ、ダウンロード完了ファイルをダウンロードフォルダに出力していない注文のリストを「ダウンロード完了ファイル未作成リスト」とする。当該リストにおいて、ダウンロード済み、かつ、ダウンロード完了ファイルをダウンロードフォルダに出力していない注文の注文番号を管理する。詳細については、後述する。ユーザが注文を決済すると、注文サーバー１２０において、注文の決済ステータスが「未決済」から「決済」に変わる。決済に変わった注文については、インポーター処理を開始させるために、ダウンロード完了ファイルをダウンロードフォルダ１４２に出力し、ダウンロード完了ファイル未作成リストから当該注文を削除する。

自動ダウンロード対象の注文であるか否かは、注文一覧を参照して判断する。具体的には、注文ステータスが未ダウンロードであり、かつ、決済ステータスが未決済であれば、自動ダウンロード対象の注文であると判断する。自動ダウンロードの対象となる注文を特定するフローを図８に基づき説明する。

図８は、画像処理サーバーであるダウンローダーＰＣ１４０のＤＨＳ１４６が実行する特定処理である。なお、図８に示すフローは、ダウンローダーＰＣ１４０のＣＰＵ２１４がメモリに格納されたプログラムをＲＡＭ２１１にロードすることにより実行される。

まず、ダウンローダーアプリ１４５が、ＤＨＳ１４６にダウンロード指示をすることにより、ＤＨＳ１４６が管理対象のダウンローダーＰＣのうち動作しているダウンローダーＰＣのＤＣＳを介して注文サーバー１２０から注文一覧を取得する（Ｓ８０１）。

取得した注文に含まれる注文の分だけ以下のループ処理を行う。

まず、着目する注文の注文ステータスが未ダウンロードであるかを判断する（Ｓ８０３）。未ダウンロードであると判定した場合（Ｓ８０３で、はい）、着目する注文（処理対象の注文）の決済ステータスが決済済みであるかを判断する（Ｓ８０４）。

決済ステータスが決済済みであると判定した場合（Ｓ８０４で、はい）、Ｓ８０６へ進む。

決済ステータスが決済済みではないと判定した場合（Ｓ８０４でいいえ）、未決済の注文の自動ダウンロード要否が「要」となっているか判定する（Ｓ８０８）。未決済の注文の自動ダウンロード要否が「要」となっていると判定した場合、すなわち、未決済の注文を自動ダウンロード対象とする設定になっている場合（Ｓ８０８で、はい）、Ｓ８０６へ進む。

Ｓ８０６では、ダウンロード処理待ちキューに当該注文が存在していないか判定する（Ｓ８０６）。ダウンロード処理待ちキューは、ＤＨＳ１４６がダウンローダーＰＣ１４０内で管理しているキューであり、管理対象のＤＣＳに割り当てられる注文の全てを管理するキューである。ここで、着目する注文は自動ダウンロード対象となる。自動ダウンロード対象の注文は、処理待ちのキューに入れるが、複数の注文がダウンロード待ちのキューに存在していると、当該注文がすぐにダウンロード処理されるとは限らない。また、何らかの理由でダウンロードが実行されずに当該注文がキューに存在している可能性もあるため、Ｓ８０６の判定を行う。着目する注文が存在していないと判定された場合（Ｓ８０６ではい）、当該着目する注文をダウンロード処理待ちキューに追加し（Ｓ８０７）、Ｓ８０９へ進み、着目する注文の処理を終了し、ループの先頭に戻る。

未決済の注文の自動ダウンロード要否が「否」となっていると判定した場合、すなわち、未決済の注文を自動ダウンロード対象とする設定になっていない場合（Ｓ８０８で、いいえ）、Ｓ８０９へ進み、着目する注文の処理を終了し、ループの先頭に戻る。

ループの先頭に戻った際は、着目対象の注文を変更する。このようにして、注文一覧に含まれる注文の分の処理が終了すると、特定処理を終了する。

ここで、図７を用いて、ＤＨＳ１４６が保持している監視対象のＤＣＳのリストについて説明する。ＤＨＳ１４６は、監視対象のＤＣＳの状態をリスト（以後「ＤＣＳリスト」とする）として保持している。本実施形態では、ダウンローダーＰＣ１４０のＤＣＳ１４１と、ダウンローダーＰＣ１５０のＤＣＳ１５１とが、監視対象のＤＣＳとなる。ＤＨＳ１４６は、ＤＣＳリストを参照して、ダウンロード可能な状態のＤＣＳを特定する。

ＤＣＳリストは、接続相手となる監視対象の各ＰＣを識別する情報と、各ＰＣの状態に関する情報を含む。図７では、監視対象のＤＣＳが４つである場合を例に挙げて説明する。図７に示すように、本実施形態では、ＤＣＳリストは、ＩＰアドレスと、ポート番号と、ホストＰＣ情報と、接続状態と、ＤＣＳステータスと、使用中フラグと、ダウンロード対象の注文番号からなる。ホストＰＣ情報とは、ホストＰＣであるか、クライアントＰＣであるかの区別をするための情報である。接続状態とは、ＤＨＳ１４６が該当ＰＣと接続しているか、接続していないかの区別をするための情報であって、「接続」、「非接続」の状態がある。

ＤＣＳステータスとは、ＤＣＳがどのような状態であるかを区別するための情報である。ＤＣＳは、データをダウンロードする処理に時間がかかる。そのため、ＤＨＳ１４６からダウンロードの指示（ＡＰＩ）を受けると、実際のダウンロードの処理を開始する前にＤＨＳ１４６にＡＰＩを返す。この状態が「非同期処理中」であり、対象のＤＣＳが注文データをダウンロード処理中であることを示す。ＤＣＳは、ＡＰＩを返したあとで、ＤＣＳは非同期処理にて実際のダウンロード処理を行う。「待機中」は、ＤＣＳが注文データをダウンロード可能な状態であるが、注文データをダウンロードしていない状態であることを示す。「非同期処理完了」は、ＤＣＳが注文データをダウンロード完了した直後から、状態がリセットされるまでの間の状態であることを示す。「不明」とは、ＤＨＳがＤＣＳの状態を判定できない状態であることを示す。

使用中フラグとは、ＤＣＳを使用中か否かを区別するために用いられる情報である。前述したようにＤＨＳ１４６は、ＤＣＳにダウンロードの指示などの各種の指示をするが、当該ＤＣＳが処理中であれば、前述の指示をすることができない。ＤＨＳ１４６がダウンロード指示を割り当てるＤＣＳを決定し、ＤＣＳに指示をかけ、ＤＣＳがその指示を受けて処理を開始するまでの「時間」は、非同期処理中のステータスにならない。一方でＤＨＳ１４６は、前述の「時間」の間にも次のダウンロードの割り当てを行う可能性がある。したがって、前記ＤＣＳに再び割り当てを行うことを防止するために、ダウンロードの指示を割り当てるＤＣＳを決定したら、その段階で使用中フラグを「使用中」に変更する。なお、前記段階から、ダウンロード完了処理を終了する段階（図１２のＳ１２１２）までが「使用中」となり、ＤＣＳを使用していない場合、すなわち、上記の使用中以外は、「未使用」となる。ダウンロード対象の注文番号は、どの注文データをＤＣＳがダウンロードしているかを示すものである。

ＤＨＳ１４６が管理対象のＤＣＳのうち特定のＤＣＳに注文データのダウンロードを指示すると、指示をうけたＤＣＳがダウンロード処理を行う。ＤＨＳは、ＤＣＳのステータスを監視する。

ＤＨＳ１４６は、ＤＣＳリストのＤＣＳステータスを見て、当該ＤＣＳのＤＣＳステータスが非同期処理完了状態であることを確認すると、ダウンロードを行ったＤＣＳにダウンロード完了の指示をする。

図９を用いて、ＤＨＳ１４６がＤＣＳリストを参照して、ダウンロード可能な状態のＤＣＳに対してダウンロードの指示をかけるフローについて説明する。なお、図８に示すフローは、ＤＨＳ１４６が実行する処理であり、ダウンローダーＰＣ１４０のＣＰＵ２１４がメモリに格納されたプログラムをＲＡＭ２１１にロードすることにより実行される。

ＤＨＳ１４６は、管理中のＤＣＳリストをダウンローダーＰＣ１４０のメモリから取得する（Ｓ９０１）。

そして、ダウンロード処理待ちキューに入っている注文の数だけ、次のループ処理（Ｓ９０２〜Ｓ９０７）を行う。ＤＣＳリストのＤＣＳステータスが待機中となっているＤＣＳがあるか判定する（Ｓ９０３）。ＤＣＳステータスが待機中のＤＣＳが存在しないと判定した場合（Ｓ９０３で、いいえ）、ＤＣＳ側の処理が進んでステータスが変更されるのを待つために、１００ミリ秒のウェイト処理を行う（Ｓ９０４）。そして、Ｓ９０７へ進み、着目する注文の処理を終了し、ループの先頭に戻る。

ＤＣＳステータスが待機中のＤＣＳが存在すると判定された場合（Ｓ９０３で、はい）、Ｓ９０５に進んで、待機中のＤＣＳのうちで、ＤＣＳリストの最上位にあるＤＣＳを、ダウンロード処理の指示対象と決定する（Ｓ９０５）。そして、当該ＤＣＳに対して、ＤＣＳリストの情報を更新する（Ｓ９０６）。更新の内容は、指示対象となったＤＣＳの使用中フラグの状態を使用中に変更することと、ダウンロード対象の注文番号を設定することである。そして、Ｓ９０７へ進み、着目する注文の処理を終了し、ループ処理の先頭に戻る。

ループの先頭に戻った際は、着目対象の注文を変更する。このようにして、ダウンロード処理待ちキューの注文の分の処理が終了すると、ダウンロードの指示処理を終了する。

図１０を用いて、ＤＨＳからダウンロードの指示を受けたＤＣＳが注文データをダウンロードするフローについて説明する。すなわち、ＤＣＳの実行する処理について説明する。

まず、ＤＣＳは自身のステータスを「非同期処理中」に変更する（Ｓ１００１）。上述したように、ＤＣＳは、ＤＨＳ１４６からの指示（ＡＰＩ）を受けて、ＤＨＳとは非同期でダウンロード処理を行うためである。なお、ＤＨＳ１４６は、このＤＣＳのステータスを定期的に監視して、図７を用いて説明したＤＣＳリストのＤＣＳスタータスにそれにより得られた結果を保持する。

次に、認証サーバー１１０からトークンを取得する（Ｓ１００２）。

取得したトークンを用いて注文サーバー１２０にアクセスをして、分割ファイル数と、のちほど結合する際にデータの妥当性を確認するために用いるチェックサムとを取得する（Ｓ１００３）。分割ファイル数とは、１つの注文がいくつのファイルに分割されているかを示すものである。

次に、分割ファイル数分のループ処理を行う（Ｓ１００４〜Ｓ１００９）。ＤＨＳ１４６からダウンロードキャンセルの指示を受けたか判定する（Ｓ１００５）。これはダウンロード中にダウンロードキャンセルの処理を実行することができるためであり、キャンセルの指示は、ユーザがダウンローダーアプリ１４５が提供する画面を介して行うことができる。もしくは、後述するように、ＤＨＳ１４６がシャットダウンする際にキャンセルの指示をすることもある。キャンセルの指示を受けたと判定した場合（Ｓ１００５で、はい）、ループ処理を抜けて、Ｓ１０１３へ進む。

キャンセル指示を受けていないと判定した場合は（Ｓ１００５で、いいえ）、注文サーバー１２０から分割ファイルの保存先ＵＲＬを取得する（Ｓ１００６）。そして、取得したＵＲＬに基づきデータサーバー１３０にアクセスして、分割ファイルをダウンロードする（Ｓ１００７）。次に、分割ファイルのダウンロードが成功したか否かを判定する（Ｓ１００８）。ダウンロードに失敗したと判定した場合（Ｓ１００８で、いいえ）、ループ処理を抜けて、Ｓ１０１３に進む。ダウンロードに成功したと判定した場合（Ｓ１００８で、はい）、Ｓ１００９へ進み、着目する分割ファイルの処理を終了し、ループの先頭に戻る。すべての分割ファイルをダウンロードしたら、ダウンロードした分割ファイルを結合する（Ｓ１０１０）。そして結合して得られたデータの妥当性を確認するために、チェックサムが一致しているか判定する（Ｓ１０１１）。チェックサムが一致していなかった場合（Ｓ１０１１で、いいえ）、データは妥当ではないと判定し、Ｓ１０１３へ進む。

チェックサムが一致していた場合（Ｓ１０１１で、はい）、データは妥当であると判定し、ダウンロード結果に「成功」を設定する（Ｓ１０１２）。そして、ＤＣＳのステータスを「非同期処理中」から「非同期処理完了」に変更して（Ｓ１０１５）、処理を終了する。

Ｓ１０１３では、ダウンロード済みのファイルを削除する。すなわち、キャンセル指示を受けた場合（Ｓ１００５で、はい）、ダウンロードが失敗した場合（Ｓ１００８で、いいえ、Ｓ１０１１で、いいえ）、ダウンロード済みのファイル（取得済みのファイル）を削除する。そして、ダウンロード途中で中止したため、ダウンロード結果に「失敗」を設定する（Ｓ１０１４）。

図１１を用いて、ＤＨＳ１４６のステータスの監視処理について説明する。ＤＨＳ１４６は、ＤＨＳ１４６がシャットダウンするまでの間に、ＤＣＳのステータスが変わることを監視する。そして、この監視処理のスレッドは、ＤＣＳごとに存在する。

ＤＨＳ１４６は、ＤＣＳリストから監視対象となるＤＣＳのＩＰアドレスとポート番号を取得する（Ｓ１１０１）。

次に、以下のループ処理を行う（Ｓ１１０２〜１１１７）。

まず、ＤＣＳリストから監視対象のＤＣＳの接続状態を取得する（Ｓ１１０３）。取得した接続状態が「接続」であるか判定する（Ｓ１１０４）。「接続」であった場合（Ｓ１１０４で、はい）、そのまま、当該ＤＣＳのステータスを取得する（Ｓ１１１０）。「接続」でなかった場合は（Ｓ１１０４で、いいえ）、ＤＣＳを初期化して「接続」にするための処理を行い（Ｓ１１０５からＳ１１０９）、当該ＤＣＳのステータスを取得する（Ｓ１１１０）。Ｓ１１０５では、初期化処理を行う対象のＤＣＳのインスタンスを取得する。なお、インスタンスとは、メモリ上に存在するＤＣＳの実体である。インスタンスが取得できたか判定する（Ｓ１１０６）。インスタンスが取得できた場合は（Ｓ１１０６で、はい）、当該ＤＣＳに対して初期化指示をかける（Ｓ１１０７）。そして、初期化が成功したか否かを判定する（Ｓ１１０８）。初期化が成功した場合は（Ｓ１１０８で、はい）、ＤＣＳの接続状態を「接続」に更新し（Ｓ１１０９）、Ｓ１１１０へ進む。

なお、インスタンスが取得できなった場合（Ｓ１１０６で、いいえ）、Ｓ１１１４へ進む。また、Ｓ１１０８において、初期化に失敗した場合（Ｓ１１０８で、いいえ）、Ｓ１１１４へ進む。

Ｓ１１１０で取得したＤＣＳのステータスが「非同期処理中」から「非同期処理完了」に変更されたか否か判定する（Ｓ１１１１）。非同期処理完了に変更されたと判定した場合（Ｓ１１１１で、はい）、当該ＤＣＳのダウンロード処理が完了していることを意味するため、その先の処理をＤＣＳに指示する（Ｓ１１１２）。具体的には、ダウンロード完了処理スレッドに対してダウンロード完了処理を指示する。そして、Ｓ１１１３へ進む。なお、ダウンロード完了処理については、詳細は後述する。Ｓ１１１３では、図７を用いて説明したＤＣＳリストのＤＣＳステータスを更新し、次に、Ｓ１１１４へ進む。

Ｓ１１１４では、ＤＣＳリストにおいてＤＣＳの接続状態が「接続」になっているかを判定する。

ＤＣＳの接続状態が「接続」である場合（Ｓ１１１４で、はい）５秒ウェイトし（Ｓ１１１５）、ループの終端へ進む。「接続」状態ではない場合（Ｓ１１１４で、いいえ）、６０秒ウェイトし（Ｓ１１１６）、ループ処理の終端へ進む。

上述した処理は、ＤＨＳ１４６がシャットダウンするまで実行する。なお、ＤＨＳ１４６がシャットダウンすると、ステータス監視処理を終了する。

上述したように、ＤＨＳ１４６は、接続が確認できたＤＣＳに対して、ダウンロード完了処理を指示すると共に、ＤＣＳリストのＤＣＳステータスを更新する。また、管理対象のＤＣＳのうち接続しているＤＣＳに対しては５秒ごとに接続確認を行い、管理対象のＤＣＳのうち接続していない場合は６０秒ごとに接続確認を行う。このように、ＤＨＳ１４６は、ＤＣＳリストにリストアップしているＤＣＳに対して、定期的に接続を確認している。

Ｓ１１１２では、ＤＨＳ１４６は、ダウンロードが完了してＤＣＳステータスが非同期処理完了状態になったＤＣＳに対して、ダウンロード完了のための処理を指示する。なお、ダウンロード完了の処理を行わない限り、ダウンロード完了ファイルが出力されず、インポーター処理が開始しない。

図１２を用いて、ＤＨＳ１４６が実行するダウンロード完了処理について説明する。

ＤＨＳ１４６は、ダウンロード結果をＤＣＳから取得する（Ｓ１２０１）。このダウンロード結果とは、図１０のＳ１０１２及びＳ１０１４においてＤＣＳが設定した情報である。

ダウンロードが成功しているか否かを判定する（Ｓ１２０２）。ダウンロードが成功していると判定した場合（Ｓ１２０２で、はい）、ＤＣＳに対して、ダウンロード完了処理を指示する（Ｓ１２０３）。なお、ＤＣＳは、ダウンロード完了処理の指示を受けると、この指示に対する応答を、ＤＨＳ１４６に同期処理で返却する。

Ｓ１２０４では、その返却結果を見て、ダウンロード完了処理が成功しているか判定する（Ｓ１２０４）。

ダウンロード完了処理が成功していると判定すれば（Ｓ１２０４で、はい）、対象となる注文についての決済ステータスが「決済済み」であるかを判定する（Ｓ１２０５）。

なお、ダウンロード完了処理が成功していないと判定した場合（Ｓ１２０２で、いいえ）、Ｓ１２１０へ進み、ＤＣＳにダウンロード済みのファイルの削除を指示する。また、ダウンロード完了通知が成功していない場合（Ｓ１２０４で、いいえ）、Ｓ１２１０へ進み、ＤＣＳにダウンロード済みのファイルの削除を指示する。そして、Ｓ１２１１へ進む。

対象となる注文についての決済ステータスが「決済済み」ではない場合（Ｓ１２０５で、いいえ）、未決済注文のダウンロード完了ファイルの出力要否が「要」であるか判定する（Ｓ１２０６）。未決済の注文について、ダウンロード完了ファイルを出力するモード３である場合は、Ｓ１２０６の判断結果が「はい」に該当する。また、未決済の注文に対してダウンロード完了ファイルを出力しないモード２である場合は、Ｓ１２０６の判断結果が「いいえ」に該当する。

決済済みの注文である場合（Ｓ１２０５で、はい）と、未決済の注文でダウンロード完了ファイルを出力するモード（Ｓ１２０６で、はい）の場合、Ｓ１２０７に進む。

Ｓ１２０７では、ＤＣＳに対して、ＤＨＳ１４６がダウンロード完了ファイルの出力を指示し、Ｓ１２０８において、ダウンロード完了ファイルの出力が成功したか判定をする。

ダウンロード完了ファイルの出力が失敗した場合（Ｓ１２０８で、いいえ）と、未決済の注文のダウンロード完了ファイルの出力要否が「要」ではない場合（Ｓ１２０６で、いいえ）、Ｓ１２０９へ進む。

Ｓ１２０９では、ダウンロード完了ファイル未作成リストに、注文を追加し、Ｓ１２１１へ進む。なお、ダウンロード完了ファイル未作成リストとは、ダウンロード済み、かつ、ダウンロード完了ファイルをダウンロードフォルダに出力していない注文と、当該注文が割り当てられたＤＣＳを管理するためのリストである。

Ｓ１２１１では、ＤＣＳにステータスのリセットを指示する。すなわち、ＤＣＳのステータスを待機中に更新する。そして、Ｓ１２１２では、ＤＣＳリストの情報を更新する。具体的には、使用中フラグを「未使用」に変更し、ダウンロード対象の注文番号を削除する。そして、処理を終了する。

自動ダウンロードモードがモード２の場合、すなわち、未決済の注文に対してはダウンロード処理までを行い、ダウンロードした注文の決済ステータスが「決済」に変わった時点で、すでに当該注文のダウンロードを行ったＰＣが起動していない場合がある。この場合には、ダウンロード完了ファイルをダウンロードフォルダに出力することができない。これに対し、本実施形態では、ダウンロードをどのＤＣＳに対して指示したかをリストとして保持しており、Ｓ１２０９において、ダウンロード完了ファイル未作成リストに、当該注文を追加する。このように、ダウンロード完了ファイル未作成リストに、ダウンロード済み、かつ、ダウンロード完了ファイルをダウンロードフォルダに出力していない注文の注文番号だけでなく、図１３に示すように当該注文のダウンロードを行ったＤＣＳの情報を保持する。

図１３のダウンロード完了ファイル未作成リストでは、注文番号と、ＩＰアドレスとを管理している。すなわち、このリストでは、注文のダウンロードを行ったダウンローダーＰＣのＩＰアドレスを、当該注文と関連付けている。このため、ＩＰアドレスからダウンロードを行ったダウンローダーＰＣを特定でき、当該ＰＣで動作しているＤＣＳを特定することができる。すなわち、各注文をダウンロードしたＤＣＳを特定し、そのＤＣＳに対して、ダウンロード完了ファイルを出力する指示をするので、ＤＨＳ１４６は、当該注文がどのダウンロードフォルダに出力されているかを知らなくともよいことになる。

図１４を用いて、ＤＨＳ１４６が注文一覧を取得する処理について説明する。本実施形態では、ＤＨＳ１４６が、現在管理している注文一覧と、注文サーバー１２０上にある注文一覧との差異を特定し、削除やキャンセルといった差分のある注文について、適切な処理を行う。ダウンロード途中の処理や、ダウンロード済みの注文に対する処理が含まれている。

まず、ＤＨＳ１４６が管理している注文一覧をダウンローダーＰＣ１４０のメモリから取得する（Ｓ１４０１）。この注文一覧を「Ａ」とする。

次に、注文サーバー１２０から注文一覧を取得する（Ｓ１４０２）。ＤＨＳ１４６が管理対象のダウンローダーＰＣのうち動作しているダウンローダーＰＣのＤＣＳに対して、注文サーバー１２０から注文一覧（この注文一覧を「Ｂ」とする）を取得する指示をして、注文一覧「Ｂ」を取得する。注文一覧「Ｂ」は、最新の注文状態を示すものとなる。

Ｓ１４０１及びＳ１４０２において、注文一覧が取得できたかを確認する（Ｓ１４０３）。注文一覧が取得できていなければ（Ｓ１４０３で、いいえ）以後の処理は行わず、処理を終了する。

Ｓ１４０１及びＳ１４０２において、注文一覧が取得できたと判定した場合（Ｓ１４０３で、はい）、Ｓ１４０４に進み、ＡとＢの差分を比較する。

ＡとＢの注文のうち差分が生じている注文の分だけ、Ｓ１４０５〜Ｓ１４１４の処理を行う。

Ｓ１４０６において、着目する注文が削除された注文であるか判定する。ＡにあってＢに無い注文であれば、それは削除された注文であると判定され（Ｓ１４０６で、はい）、Ｓ１４０８に進む。ＡにもＢにもある注文であれば、削除された注文ではないと判定され（Ｓ１４０６で、いいえ）、注文ステータスが「キャンセル」に変更されたか判定する（Ｓ１４０７）。注文ステータスがキャンセルに変更された場合は（Ｓ１４０７で、はい）、Ｓ１４０８に進む。

Ｓ１４０８では、ダウンロード待ちのキューに該当の注文が存在しているか否か判定する。

ダウンロード待ちのキューに該当の注文が存在している場合（Ｓ１４０８で「はい」）の場合、まだ当該注文をダウンロードしていない状態なので、Ｓ１４１０に進んで、ダウンロード処理待ちキューから当該注文を削除する。そして、Ｓ１４１４へ進む。

ダウンロード待ちのキューに該当の注文が存在していない場合（Ｓ１４０８で「いいえ」）、現在ダウンロード処理中であるか否か判定する（Ｓ１４０９）。ダウンロード処理中であると判定した場合（Ｓ１４０９で「はい」）、Ｓ１４１１に進み、ＤＣＳリストを参照して当該注文のダウンロードを指示したＤＣＳに対して、ダウンロードキャンセルを指示する。そして、Ｓ１４１４へ進む。

ダウンロード処理中でない場合（Ｓ１４０９で「いいえ」）、Ｓ１４１２に進み、ダウンロード完了ファイル未作成リストに当該注文が存在しているか判定する。当該注文が存在している場合（Ｓ１４１２で「はい」）、Ｓ１４１３に進んで、当該注文をダウンロード完了ファイル未作成リストから削除する。そして、Ｓ１４１４へ進む。

差分のある注文に対して上記の処理を行ったら、ＤＨＳ１４６が管理しているＡをＢで上書きする（Ｓ１４１５）。

次にダウンロード完了ファイル未作成リストに存在する注文の数だけ、Ｓ１４１６からＳ１４２３までのループ処理を行う。

注文ステータスが「キャンセル」以外か否か判定する（Ｓ１４１７）。

「キャンセル」以外ではないと判定した場合（Ｓ１４１７で「いいえ」）、ループの終端へ進む。

「キャンセル」以外であると判定した場合（Ｓ１４１７で「はい」）、当該注文の決済ステータスが「決済済み」であるか否か判定する（Ｓ１４１８）。「決済済み」でなければ（Ｓ１４０８で「いいえ」）、当該注文に未決済注文のダウンロード完了ファイルを出力するモードであるか否か判定する（Ｓ１４１９）。ここでは、未決済注文のダウンロード完了ファイル出力要否が「要」であるか判定する。自動ダウンロードがモード２の場合（未決済の注文に対しては自動ダウンロードを行うがダウンロード完了ファイルを出力しない）、Ｓ１４１９が「いいえ」に該当する。自動ダウンロードがモード３の場合（未決済の注文に対して自動ダウンロードを行い、ダウンロード完了ファイルを出力する）、Ｓ１４１９が「はい」に該当する。

Ｓ１４１９で「いいえ」の場合は、ループの終端へ進む。

Ｓ１４１９で「はい」の場合は、ＤＣＳにダウンロード完了ファイルの出力を指示する（Ｓ１４２０）。そしてダウンロード完了ファイルを出力する指示が成功したか否か判定し（Ｓ１４２１）、指示が成功しているならば（Ｓ１４２１で「はい」）、ダウンロード完了ファイル未作成リストから当該注文を削除し（Ｓ１４２２）、ループの終端へ進む。

ダウンロード完了ファイル未作成リストに存在する注文の数だけループ処理を実行するまで、ループ処理の先頭に戻る。

上述したように、本実施形態では、ＤＨＳ１４６が各ＤＣＳを定期的に監視している（Ｓ１１０４）。そしてダウンロード完了ファイルの出力を指示する時点でＤＣＳが起動していない場合（Ｓ１１０６）、定期的な監視の中で、起動していないＤＣＳが起動することを確認できた時点で、当該ＤＣＳに対してダウンロード完了ファイルの指示を行う（Ｓ１１１２）。そして指示が成功した時点で、ダウンロード完了ファイル未作成リストの更新をする（Ｓ１４２２）。

次に、ダウンロード処理中に、ＤＨＳ１４６や管理対象のＤＣＳがシャットダウンする場合の対策について説明する。本実施形態では、ＤＨＳ１４６と、複数のＰＣの間で非同期に連携しているＤＣＳとの間で、ＤＨＳやＤＣＳがシャットダウンする場合に、ダウンロード処理を確実に中止する。すなわち、ＤＣＳを監視するＤＨＳ１４６がシャットダウンする場合、シャットダウン前に管理していた情報を不正に参照してしまうことを抑制する。

具体的には、ＤＨＳがシャットダウンする場合、シャットダウンする際の処理として下記の（１）〜（４）を実行し、その後のＤＨＳの再起動の際の処理として、下記の（５）〜（７）を行う。
（１）ＤＨＳ１４６がシャットダウンする際に、ダウンロード指示をかけている各ＤＣＳに対してダウンロードキャンセル指示をかける。ＤＣＳは、キャンセル指示を受けると、ダウンロード処理を中止する。ダウンロード済みの注文データが１ファイルでもあれば削除する。
（２）次に、管理している各ＤＣＳに対して終了指示をかける。
（３）ＤＣＳは、終了指示を受けると、注文データのダウンロード処理中だった場合はダウンロード処理を中止する。ダウンロード済みの注文データが１ファイルでもあれば削除する。ダウンロードを完了し、ダウンロード完了通知の待機中だった場合は、ダウンロード済みの注文データを削除する。
（４）ＤＨＳ１４６の終了処理を行う。
（５）ＤＨＳ１４６が再起動した場合、ＤＨＳ１４６の初期化処理を行う。
（６）管理対象の各ＤＣＳに対して初期化指示をかける。
（７）ＤＣＳは、初期化指示を受けると、注文データのダウンロード中であればダウンロード処理を中止する。ダウンロード済みの注文データが１ファイルでもあれば削除する。ダウンロードを完了し、ダウンロード完了通知の待機中だった場合は、ダウンロード済みの注文データを削除する。

ＤＨＳ１４６のシャットダウン処理について、図１５を用いて説明する。

ＤＨＳが管理しているＤＣＳリストを取得する（Ｓ１５０１）。

そして、ＤＣＳリストに含まれるＤＣＳの分だけループ処理を行う（Ｓ１５０２〜１５０７）。

まず、着目するＤＣＳが非同期処理中であるか判定する（Ｓ１５０３）。非同期処理中であると判定した場合（Ｓ１５０３で「はい」）、ＤＣＳにダウンロード処理のキャンセルを指示する（Ｓ１５０４）。その後、Ｓ１５０５へ進む。なお、ＤＣＳがこのキャンセルの指示を受信すると、図１０のＳ１００５において、「はい」となる。

非同期処理中でないと判定した場合（Ｓ１５０３で「いいえ」）、Ｓ１５０５へ進む。

Ｓ１５０５では、着目するＤＣＳに対して終了処理を指示し、ループ処理の終端へ進む（Ｓ１５０６）。

ＤＣＳリストに含まれるＤＣＳの分だけループが終了したら、ＤＨＳの終了処理を行う（Ｓ１５０７）。ＤＨＳの終了処理では、ＤＣＳリスト及び注文一覧の情報を削除する。これにより、ＤＨＳ１４６のシャットダウン処理を終了する。

図１６を用いて、ＤＨＳから終了処理の指示を受けたＤＣＳの終了処理について説明する。この処理は、ＤＨＳから終了処理の指示を受けたＤＣＳそれぞれにおいて実行される。

ＤＣＳは、自身が現在非同期処理中であるか判定する（Ｓ１６０１）。非同期処理中の場合（Ｓ１６０１で「はい」）、現在ＤＣＳが注文データをダウンロードしていることになるので、ダウンロード処理を中止する（Ｓ１６０２）。そして、ダウンロード済みのファイルを削除し（Ｓ１６０４）、Ｓ１６０５へ進む。

非同期処理中ではない場合（Ｓ１６０１で「いいえ」）、ダウンロード完了通知の待機中であるか判定する（Ｓ１６０３）。ダウンロード完了通知の待機中であった場合（Ｓ１６０３で「はい」）、ダウンロード済みのファイルを削除し（Ｓ１６０４）、Ｓ１６０５へ進む。ダウンロード完了通知の待機中ではない場合（Ｓ１６０３で「いいえ」）、そのままＳ１６０５へ進む。Ｓ１６０５では、ＤＣＳのステータスを「イニシャライズ前」に変える。そして、ＤＣＳの終了処理を終了する。

このように、ＤＣＳがシャットダウンする場合は、ダウンロード済みのファイルがあっても、ダウンロード完了通知を通知していない場合は、ダウンロード済みのファイルを削除する。

図１７を用いて、再起動後のＤＨＳ１４６の処理について説明する。

ＤＨＳ１４６の初期化処理を行う（Ｓ１７０１）。ここで、初期化処理では、ＤＣＳリストの再作成及び注文一覧の情報の再取得を行う。図１５のＳ１５０７において、ＤＣＳリスト及び注文一覧の情報が削除されているためである。なお、初期化処理の段階では、ダウンロード完了ファイル未作成リストは削除されているので存在しない。

ＤＨＳ１４６が管理するＤＣＳリストを取得する（Ｓ１７０２）。

そしてＤＣＳリストに含まれるＤＣＳの分だけループ処理を行う（Ｓ１７０３〜Ｓ１７０５）。ＤＣＳに初期化処理を指示し、次のＤＣＳに対して同様の処理を行う。

ＤＣＳリストに含まれるＤＣＳの分だけＤＣＳの初期化処理を指示すると、ＤＨＳ１４６の初期化処理を終了する。

上述した再起動処理では、注文一覧及びＤＣＳリストが再作成される。その後、上述したように、ＤＨＳ１４６が注文を管理対象のＤＣＳに割当てる。このとき、シャットダウン処理をする際にダウンロードが完了していない注文については、シャットダウン処理により、注文が割当てられていたＤＣＳから削除されているので、再度、同じＤＣＳに割当ててもよいし、他のＤＣＳに割当ててもよい。なお、再割り当ての際には、ＤＨＳ１４６は、接続状態が「接続中」のＤＣＳに注文を割当てる。以上より、異なるＤＣＳに重複して注文が割当てられることがない。

図１８を用いて、ＤＣＳの初期化処理について説明する。なお、ＤＣＳの初期化処理は、ＤＨＳ１４６から初期化処理の指示を受けることにより開始する。例えば、Ｓ１１０７により、指示を受けた場合や、Ｓ１７０４により処理を受けた場合が挙げられる。また、ＤＣＳ毎に実行される。

ＤＣＳは、現在非同期処理中であるか判定する（Ｓ１８０１）。非同期処理中である場合（Ｓ１８０１で「はい」）、現在ＤＣＳが注文データをダウンロードしていることになるため、ダウンロード処理を中止する（Ｓ１８０２）。そして、ダウンロード済みのファイルを削除し（Ｓ１８０４）、Ｓ１８０５へ進む。

非同期処理中ではない場合（Ｓ１８０１で「いいえ」）、ダウンロード完了通知の待機中であるか判定する。ダウンロード完了通知の待機中であった場合（Ｓ１８０３で「はい」）は、ダウンロード済みのファイルを削除し（Ｓ１８０４）、Ｓ１８０５へ進む。Ｓ１８０５では、ＤＣＳのステータスを「イニシャライズ済み」に変え、ＤＣＳの初期化処理を終了する。

このように、ＤＣＳが初期化処理をする場合は、ダウンロード済みのファイルがあっても、ダウンロード完了通知を通知していない場合は、ダウンロード済みのファイルを削除する。

本実施形態では、注文データのダウンロードが完了しただけでは、プリントシステム１６０に、注文データが出力されないようになっている。ＤＣＳは注文データのダウンロードが完了した後に、ＤＨＳ１４６からの指示を受けてダウンロード完了ファイルを出力し、これが後段のインポーター処理に対するトリガファイルとなる。インポーター処理が完了することによって、プリントシステムが処理を開始できるようなる。なお、ダウンローダーＰＣ１５０のＤＣＳについても、ＤＨＳ１４６からの指示を受けることで、同様の処理を行う。

また、ＤＨＳ１４６がシャットダウンしてしまった場合に、ＤＣＳに割り振られた注文に対する処理が失敗したり、再起動後に重複して他のＤＣＳに割り振られたりしないようにしている。具体的には、現在ダウンロードの指示をかけているＤＣＳに対する終了指示を実行し、管理している全てのＤＣＳに対する終了指示をする。

ＤＨＳ１４６が、例えば、Ｗｉｎｄｏｗｓのサービス等を利用している場合、ＯＳのシャットダウンによってＤＨＳ１４６がシャットダウンする。しかしながら、ＤＨＳ１４６がＯＳからシャットダウンのイベントを受けて処理を行うが、所定の時間までしかＤＨＳの処理をＯＳが待ってくれず、ＯＳが先にシャットダウンしてしまう可能性がある。これに対し、本実施形態では、さらに、Ｓ１５０４やＳ１５０５の処理が正常に完了できなかったとしても、図１７に示すＤＨＳ１４６が再起動時に行う処理や図１８に示すＤＣＳが再起動時に初期化処理をする。これにより、注文データのダウンロード処理を確実に中止することができる。

上記では、ＤＨＳ１４６がシャットダウンをする場合について説明した。しかしながら、これに限定されず、何らかの原因により、ＤＣＳ１５１のみがシャットダウンする場合は、図１６の処理を実行し、ＤＣＳ１５１が再起動をする際には、ＤＨＳ１４６から初期化処理の指示（Ｓ１１０７）により、図１８の処理を実行すればよい。

また、本実施形態では、ＤＣＳがシャットダウンする場合の対策を行っている。図１１を用いて説明した通り、ＤＨＳはＤＣＳリストで管理している各ＤＣＳの接続状態を定期的に監視している。Ｓ１１０３ではＤＣＳリストから対象となるＤＣＳの接続状態を取得しているが、ここにおいてＤＣＳと接続できない場合（Ｓ１１０６で「いいえ」）、Ｓ１１１２のダウンロード完了ファイルの出力指示を行わない。すなわち、ＤＣＳが注文データのダウンロードを完了しても、ＤＨＳからダウンロード完了通知の指示（Ｓ１２０３）や、ダウンロード完了ファイルの出力指示（Ｓ１２０７）を行わない。したがって、インポーター処理によって後段のプリントシステムに注文データが出力されることがない。

また、本実施形態では、ＤＨＳ１４６と管理対象のＤＣＳの通信接続が切れた場合も、再割り振りできるようにしている。ＤＣＳに注文が割り振られた後に通信接続が切れて、ＤＣＳリストの接続状態が「非接続」となった場合、「非接続」となったＤＣＳに割当てられたダウンロード対象の注文番号（図７参照）に対応する注文を、ＤＣＳに再割り当てする。このとき、他の接続状態が「接続」となっているＤＣＳに再割り当てする。すなわち、図１１のＳ１１０６で「いいえ」の後に、当該ＤＣＳに注文が割当てられている場合は、当該注文を他のＤＣＳに再割り振りする。なお、通信接続が切れる場合とは、通信障害があった場合や、ＤＣＳが何らかの原因によりシャットダウンしてしまった場合等が挙げられる。なお、接続が切れていたＤＣＳと再接続した場合（Ｓ１１０６で「はい」）、当該ＤＣＳに対して初期化指示をする（Ｓ１１０７）。そして、初期化指示を受けたＤＣＳは図１８を用いて説明した初期化処理を行う。したがって、ＤＣＳに既にダウンロード済みのファイルは削除される。以上より、異なるＤＣＳに重複して注文が割当てられることがない。

上述したように、本実施形態では、ＤＨＳは、非接続状態から接続状態になる場合に、ダウンロード処理を中止するとともにダウンロード済みのファイルを削除する。非接続状態から接続状態になる場合とは、例えば、通信ができなくなってから再度通信ができるようになった場合（Ｓ１１０４でいいえ、Ｓ１１０６ではいとなる場合）や、シャットダウンしてから再起動する場合が挙げられる。シャットダウンしてから再起動をする場合は、シャットダウン処理のとき（図１６参照）と、初期化処理のとき（図１８参照）のいずれの場合も、ダウンロード処理を中止するとともにダウンロード済みのファイルを削除するものとしたが、これに限定されない。例えば、いずれか一方で実行するようにしてもよい。

本実施形態では、上述したように、いずれかのＤＣＳがシャットダウンしても、他のＤＣＳに割り振りを行うことができる。したがって、シャットダウンしたＤＣＳに割り振られていた注文の処理が実行されずに止まってしまうのを抑制することができる。また、このとき、注文が重複してＤＣＳに割り振られることがないため、無駄な処理を実行するのを抑制することができる。

また、本実施形態では、各ＤＣＳは注文が割当てられると注文データのダウンロードを実行し、トリガファイルとなるダウンロード完了ファイルが出力されてから、インポーター処理を行う。具体的には、決済前であっても時間のかかる注文データのダウンロードを先に終了させつつ、決済が終了した時点でダウンロード完了ファイルを出力して、インポーター処理を行う。これにより、決済後にすぐにプリントシステムに処理を実行させることができる。

＜他の実施形態＞
本発明は、上述した実施形態に限定されるものではない。例えば、上述した実施形態では、ダウンローダーＰＣ１４０が、ダウンローダーアプリ１４５及びＤＨＳ１４６を有するものとしたが、ダウンローダーＰＣ以外の装置が、ダウンローダーアプリ１４５及びＤＨＳ１４６を有するものとしてもよい。すなわち、注文一覧を監視し、各ダウンローダーＰＣに注文を割り振る装置は、ダウンローダーＰＣ以外の装置であってもよい。

また、入稿フォルダ１４４は、ダウンローダーＰＣが保持するものとしたが、これに限定されず、ダウンローダーＰＣ以外の装置が保持するようにしてもよい。

上述した実施形態は、以下の処理を実行することによっても実現される。すなわち、上述した実施形態の機能を実現するソフトウエア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、プログラムは、１つのコンピュータで実行させても、複数のコンピュータを連動させて実行させるようにしてもよい。また、上記した処理の全てをソフトウエアで実現する必要はなく、処理の一部または全部をＡＳＩＣ等のハードウェアで実現するようにしてもよい。また、ＣＰＵも１つのＣＰＵで全ての処理を行うものに限らず、複数のＣＰＵが適宜連携をしながら処理を行うものとしてもよい。

１００ 情報処理装置
１１０ 認証サーバー
１２０ 注文サーバー
１３０ データ―サーバー
１４０、１５０ ダウンローダーＰＣ

Claims (9)

1. データサーバーと、画像処理を実行する複数の画像処理装置と、を有する画像処理システムであって、
   注文を受け付ける受付手段と、
   前記受付手段が受け付けた注文を各画像処理装置に対して割り当てる割当手段と、
   前記受付手段により受け付けた注文のステータスを管理する管理手段と、
   前記各画像処理装置の接続状態を監視する監視手段と、
   を有し、
   前記データサーバーは、前記受付手段により受け付けた注文に対応する注文データを保存し、
   前記管理手段は、前記注文のステータスとして決済ステータスを管理し、
   前記各画像処理装置は、
   前記データサーバーから注文データを取得する取得手段と、
   処理対象の注文データの前記決済ステータスが決済済みとなった場合、前記取得手段により取得した注文データに画像処理を実行する実行手段と、
   前記実行手段により画像処理を実行した処理済みデータを出力する出力手段と、
   を有し、
   前記監視手段により第１画像処理装置の接続状態が非接続となったことが特定された場合、前記割当手段は、前記複数の画像処理装置のうち接続されている画像処理装置に前記第１画像処理装置に割当てられていた注文を割り当て、
   各画像処理装置は、非接続状態から接続状態になる場合、取得済みの注文データを削除することを特徴とする画像処理システム。
2. 前記各画像処理装置は、非接続状態から接続状態になる場合、初期化処理を実行することにより前記取得済みの注文データを削除することを特徴とする請求項１に記載の画像処理システム。
3. 前記各画像処理装置は、シャットダウンする場合、シャットダウンする前に前記取得済みの注文データを削除することを特徴とする請求項１又は２に記載の画像処理システム。
4. 前記各画像処理装置は、シャットダウンする場合、再起動した際に前記取得済みの注文データを削除することを特徴とする請求項１〜３のいずれか１項に記載の画像処理システム。
5. 前記各画像処理装置は、前記決済ステータスが決済済みとなった場合、トリガファイルを取得済みの注文データを保存するフォルダに出力し、
   前記実行手段は、前記トリガファイルがフォルダに出力された場合、画像処理を実行することを特徴とする請求項１〜４のいずれか１項に記載の画像処理システム。
6. 前記各画像処理装置に初期化処理を指示する指示手段をさらに有することを特徴とする請求項１〜５のいずれか１項に記載の画像処理システム。
7. 前記指示手段は、接続状態が非接続から接続となった画像処理装置に対して初期化処理を指示することを特徴とする請求項６に記載の画像処理システム。
8. 前記複数の画像処理装置のうちいずれか１つの画像処理装置は、
   前記割当手段と、前記管理手段と、前記監視手段をさらに有することを特徴とする請求項１〜７のいずれか１項に記載の画像処理システム。
9. データサーバーと、画像処理を実行する複数の画像処理装置と、を有する画像処理システムの制御方法であって、
   注文を受け付ける受付工程と、
   前記受付工程が受け付けた注文を各画像処理装置に対して割り当てる割当工程と、
   前記受付工程により受け付けた注文のステータスを管理する管理工程と、
   前記各画像処理装置の接続状態を監視する監視工程と、
   を有し、
   前記データサーバーは、前記受付工程により受け付けた注文に対応する注文データを保存し、
   前記管理工程では、前記注文のステータスとして決済ステータスを管理し、
   前記各画像処理装置は、
   前記データサーバーから注文データを取得し、
   処理対象の注文データの前記決済ステータスが決済済みとなった場合、取得した注文データに画像処理を実行し、
   画像処理を実行した処理済みデータを出力し、
   前記監視工程において第１画像処理装置の接続状態が非接続となったことが特定された場合、前記複数の画像処理装置のうち接続されている画像処理装置に前記第１画像処理装置に割当てられていた注文を割り当て、
   各画像処理装置は、非接続状態から接続状態になる場合、取得済みの注文データを削除することを特徴とする画像処理システム。

Images