JP2023057701A - 情報処理装置及びその制御方法 - Google Patents

Abstract

【課題】 発注後に入稿データを送ることが可能なシステムにおいて、印刷業者が、入稿データが確定されたものなのかを判定可能とすることを目的とする。【解決手段】 印刷成果物の発注データを受信し、発注データの受信とは異なるタイミングで、発注データに対する入稿データを受信する。入稿データの確定情報を受信し、発注データと入稿データと確定情報に基づいて、印刷成果物の生産を行うように制御する。【選択図】 図１２

Description

本発明は、印刷成果物の入稿に関わる技術に関する。

商業印刷分野において、発注者が印刷業者に対して印刷成果物の生産を依頼する際、ウェブ発注等の電子受発注、および電子的な入稿業務を要望する発注者並びに要望されたシステムを印刷業者が提供することの要望が近年高まっている。

これらの要望を受けて印刷会社によってはウェブシステムをベースとした受発注システムを提供したシステムを公開している。また、受注システム、発注システムが各社各様とならぬよう、ＰｒｉｎｔＴａｌｋのように、受発注業務における各種コマンド、交換される情報を共通化させることを目的にした電子取引データの標準仕様も検討されている。

特許文献１は、電子入稿管理サーバと依頼端末を用いて、印刷成果物の発注及び入稿システムが開示されている。

特開２００４－２１３３７８号公報

特許文献１は、発注時に入稿データを入稿するシステムであり、発注後に入稿データを送るような場合については想定されていない。従って、例えば、発注者が、入稿データを後から送ったり、入稿データの差し替えをする場合、印刷業者は、入稿データが確定されたものなのか判断できない。そのため、印刷業者が、入稿データを受け取ってから進める処理（例えば、印刷処理）を進めることができない。

本発明は、上述のような状況を鑑みてなされたものである。すなわち、発注後に入稿データを送ることが可能なシステムにおいて、印刷業者が、入稿データが確定されたものなのかを判定可能な技術を提供することを目的とする。

上記課題を解決すべく、本発明における情報処理装置は、印刷成果物の発注データと、前記発注データに対する入稿データを受信する受信手段と、前記印刷成果物の生産を行うように制御する制御手段を有し、前記印刷成果物の発注データと、前記発注データに対する入稿データとを異なるタイミングで受信し、前記受信手段は、さらに、前記入稿データの確定情報を受信し、前記制御手段は、前記発注データと前記入稿データと前記確定情報に基づいて、前記印刷成果物の生産を行うように制御することを特徴する。

本発明によれば、発注後に入稿データを送ることが可能なシステムにおいて、印刷業者が、入稿データが確定されたものなのかを判定可能となる。

第１実施形態における受発注システムと印刷業者システム全体を示すブロック図 第１実施形態における情報処理装置のハード構成図 第１実施形態における第一の情報処理装置のソフト構成図 第１実施形態における第二の情報処理装置のソフト構成図 第１実施形態における第一の情報処理装置における操作フローの説明図 第１実施形態における第一の情報処理装置における操作フローの説明図 第１実施形態における第一の情報処理装置における操作フローの説明図 第１実施形態における第二の情報処理装置における操作フローの説明図 第１実施形態における第二の情報処理装置における操作フローの説明図 第１実施形態における第二の情報処理装置における追加入稿データ操作の動作を示す一例の図 第１実施形態における第一及び第二の情報処理装置で交換される情報のシーケンス図 第１実施形態における第一及び第二の情報処理装置で交換される情報の一例を説明するための図 第１実施形態における第一及び第二の情報処理装置で交換される情報の一例を説明するための図 第１実施形態における第一及び第二の情報処理装置で交換される情報の一例を説明するための図 第１実施形態における稿データとワークフローを構成する工程の依存関係の一例を説明するための図 第１実施形態における第二の情報処理装置内に格納される入稿データの管理テーブルを説明するための図 第１実施形態における入稿データの処理フローの動作を説明するための図 第１実施形態における入稿データの処理フローのうち、入稿ファイル登録処理の詳細を説明するための図 第２実施形態における第一及び第二の情報処理装置で交換される情報のシーケンス図 第２実施形態における第一及び第二の情報処理装置で交換される情報の一例を説明するための図 第２実施形態における入稿データの処理フローの動作を説明するための図

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

（第１の実施形態）
図１は、第一実施形態に係る受発注システムを示すブロック図である。

システムは発注者システム（１０１、１０２、１０３）、印刷業者システム（１０４、１０５、１０６）、に大別され、それらはインターネット１００によって相互に接続されている。発注者システム（１０１、１０２、１０３）には少なくとも１以上の情報処理装置１０７が含まれる。

以下、印刷業者システム（１０４、１０５、１０６）の内部構成について詳細に説明する。図１に示す通り複数の装置がネットワーク１０９によって相互に接続されている。複数装置の例としては情報処理装置１０８、画像形成装置（１１０、１１１、１１２）、ラミネータ１１４、ＣＴＰ１１３等が接続されている。

画像形成装置１１０はカットシートタイプのデジタル印刷機である。画像形成装置１１１は連帳シート用のデジタル印刷機である。画像形成装置１１２はオフセットタイプの印刷機である。印刷会社はそれぞれ性質の異なる機器を通常複数有し、受注した内容や成果物の数、成果物の単価、品質等様々な条件を考慮した上で最適な画像形成装置を選択し、生産を行う。

各装置は情報処理装置１０８上で動作するワークフローソフトウェア群の配下のもと制御され、発注者システム（１０１、１０２、１０３）より受理した電子取引データ、並びに入稿されたデータを処理し、成果物を生産する。発注者システム（１０１、１０２、１０３）から印刷業者システム（１０４、１０５、１０６）に対して為される印刷成果物の受発注に関する要求の送受信は共通化された電子フォーマットをインターネット１００経由で相互に行われる。

ここで複数の異なる発注者システム（１０１、１０２、１０３）が複数の異なる印刷業者システム（１０４、１０５、１０６）との間で行う受発注処理において、送受信される電子フォーマットが共通化されているものである事のメリットは次に示す通りである。

第一に、発注者システムは複数の印刷業者システムの何れを選択し、印刷成果物を発注する場合であっても、印刷会社システムが独自に設ける固有のシステム毎に異なる態様によって受発注処理をする必要がない。何故ならば共通化された電子フォーマットによって共通の発注システムを利用することによって達成することが出来るからである。つまり、異なる印刷会社であっても共通のシステムを発注者システム（１０１、１０２、１０３）に提供することが出来る。つまり、複数の印刷業者に対して受発注する場合であっても、受発注に伴う各種処理は統一されたものとなる。その効果として、受発注に係る各種業務の効率化・共通化、さらには自動化が促進される。

第二に、印刷業者システム（１０４、１０５、１０６）の側においても、複数の異なる発注者システム（１０１、１０２、１０３）から異なる様式によって印刷成果物の製造業務に関する受発注を実施する必要がない。何故ならば共通化された電子フォーマットによって共通の受注システムを利用することが可能となるからである。つまり、異なる複数の発注者からの業務を受注する場合であっても、受注する側としては統一された手法によって受注処理を実行することが可能となる。その効果として、各種業務を印刷業者システムにおける受注に係る各種業務の効率化・共通化、さらには自動化が促進される。

上述した以外にも、発注者システム（１０１、１０２、１０３）および印刷業者システム（１０４、１０５、１０６）が共通化された電子フォーマットによる制御に基づき印刷成果物の受発注システムを統一的に利用する事のメリットは様々あり得る。例えば、従来業務を委託していた印刷業者から、別の印刷業者に同一内容の印刷成果物の製造を新規に依頼する場合を想定する。受発注に伴い送受信される情報は共通化された電子フォーマットであって、かつ受注者、発注者が保有するシステムが該共通化された電子フォーマットに従って受発注業務を電子的に処理するよう構成されている。故に、前述した従来とは異なる印刷業者に新規に印刷成果物の製造依頼をする際においても、製造を請け負う業者が変わることを意識する必要がない。従って、従来とは異なり柔軟に製造を依頼する印刷業者を変更することを可能とする。

また、次に示す様な更なるメリットもある。受発注時に発注者と印刷業者との間で送受信する電子データやコマンドが共通化されたものであるため、旧来のように業界の慣習や会社ごとに異なる業態等の固有要因を極小化することが容易である。すなわち、受発注業務に要求される各種処理の一部もしくは全部を自動化する際に有利なシステム構成を容易に具現化することが可能となる。

さらには、現在はウェブ入稿をはじめとする電子入稿システムを備えていない印刷業者を想定する。これら業者においても共通化された電子データやコマンドを送受信するための発注者システム、もしくは印刷業者システムをライブラリ化する、あるいは標準的なアプリケーションとして頒布されたものを従来と比較し遥かに容易に導入することが考えられる。このようにして印刷成果物の受発注業務を行っている業界全体にメリットをもたらすことをも可能となる。

さらに、同図に示す通り、印刷業者システム（１０４、１０５、１０６）がそれぞれ性質の異なる種類の画像形成装置（１１０、１１１、１１２）を保有しているような場合においては次に示すようなメリットを享受できる。つまり生産数、品質、納期、その他画像形成装置の特徴を生かして発注者にとって、好都合な条件のもとで生産を行える印刷業者を発注者が選択することも容易に実現することが出来る。

尚、本実施形態で説明する印刷業者システムは、以下の「後から入稿」と「差し替え入稿」を許容するものである。

印刷成果物の受発注業務の業態として、発注者は印刷業者に対し、成果物の注文内容の概要を伝えて、見積もりを取得、見積もりに基づき発注処理を行う。発注処理を行う際に印刷対象データである入稿データの提供を印刷会社が発注者に求めることもあるが、印刷成果物の受発注業務の慣習として入稿データは発注の段階までに制作が完了されるとは限らず発注後に入稿される。つまり、発注処理と入稿処理は別処理として実施される。いわゆる「後から入稿」と呼ばれる処理に相当する。

また同一データの入稿は単一回数によるとは限らず、複数回に及ぶことが実際の受発注業務において必要となるケースが多いことが知られている。原因はさまざまであるが、例えば何らかの入稿データのコンテンツ自体の変更や更新が生じた場合等が一例としてあげられる。これはいわゆる「差し替え入稿」と呼ばれる処理に相当する。

以降、発注者システム１０１、印刷業者システム１０４を例として説明するが、発注者システム１０１は、発注者システム１０２、１０３であっても構わないし、また、複数の発注者システムからなっても構わない。印刷業者システム１０４も、印刷業者システム１０５、１０６であっても構わないし、また、複数の印刷業者システムからなっても構わない。

図２は、情報処理装置（１０７、１０８）の構成を示すブロック図である。同図において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはＨＤＤ２１１からＲＡＭ２０２にロードされたＯＳや一般アプリケーションのプログラムを実行する。ＲＯＭ２０３はまたフォントＲＯＭやデータＲＯＭを有している。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボードやポインティングデバイス（不図示）からの入力を制御する。表示コントローラＣＲＴＣ２０６は、表示部ＣＲＴ２１０への表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、ブートプログラム、種々のアプリケーション、フォントデータ等を記憶するＨＤＤ２１１等とのアクセスを制御する。ネットワークコントローラ（ＮＩＣ）２１２は、ネットワークに接続されて、そのネットワークに接続された他の機器との通信制御処理を実行する。バス２０４は、ＣＰＵ２０１とＲＡＭ２０２、ＲＯＭ２０３及び各種コントローラ等を接続して、データ信号や制御信号を搬送している。

なお、携帯端末の場合にはキーボードコントローラ（ＫＢＣ）２０５の代わりにタッチパネルコントローラ等を構成に含む場合がある。また、ＨＤＤ２１１の代わりとなる大容量記憶装置を備える場合もある。さらに、ネットワークコントローラ（ＮＩＣ）２１２は、備える装置が有線ＬＡＮ、無線ＬＡＮ其々の場合、あるいは双方を備える場合とで、内部構成が異なる。ただし、これらの内部構成による差異は、ネットワークコントローラ（ＮＩＣ）２１２内部に隠蔽され、同図に示す他のモジュールには等価なものとしてシステムを制御可能な様、構成される。

図３は、発注者システム１０１における情報処理装置１０７が有するプログラムの構成を例示した図である。

ブートローダ３０１は、情報処理装置１０７の電源投入直後に実行されるプログラムである。これらプログラムには、システムの起動に必要となる各種起動シーケンスを実行するためのプログラムが含まれる。

オペレーティングシステム３０２は、情報処理装置１０２の機能を実現する各種プログラムの実行環境を提供することを目的としたプログラムである。これは、情報処理装置のメモリ、即ちＲＯＭ２０３やＲＡＭ２０２，ＨＤＤ２１１等の資源管理等の機能を提供する。

ネットワーク制御プログラム３０３は、ネットワークを介して接続される機器に対してデータを送受信する際に実行されるプログラムである。すなわち、ＮＩＣ２１２を制御し、インターネット１００を介して外部とデータやファイルを送受信する際に使われるソフトウェアである。

ウェブシステム３０４は、ネットワーク経由で接続された外部機器に対からのウェブベースのサービスの受付や受理、あるいは外部のウェブサービスへのデータやコマンドの送信を司るプログラムである。

発注情報管理プログラム３０５は、発注者システム１０１において中心的な役割を担うプログラムである。すなわち、発注者が当該発注者システム１０１の主目的である、印刷成果物を外部の印刷業者システム１０４に対し、次に示すような処理を行う。すなわち発注に係る各種コマンドによる要求やその結果であるレスポンスの受信と解釈、各種コマンドを操作者に実行させるための指示手段提供等である。ここにおける各種コマンドとその実行順序については後述する。

入稿データ管理プログラム３０６は発注する印刷成果物の元データ、すなわち原稿画像データを管理するためのものである。原稿画像データを送信するまで保持するのみであれば、オペレーティングシステム３０２が備えるファイルシステムの機能をそのまま利用することも可能である。ただし、当該入稿データ管理プログラム３０６はデータの加工、コンテンツの作成、編集などを実行する際に利用されるプログラム等も本実施形態においては含まれることを想定している。

ＪＤＦ管理プログラム３０７は、印刷業者システム１０４に対して印刷成果物を発注する際に、その成果物の形態を電子的に表現されるＪＤＦフォーマットのファイルの作成、編集等を実行する際に利用されるプログラムである。本プログラムによって編集若しくは作成されたＪＤＦ情報は発注情報管理プログラム３０５によって、印刷業者システム１０４に対して印刷成果物製造の発注時に送信される。

第一の送信プログラム３０８は発注者システム１０１から、印刷業者システム１０４に対して、受発注処理において送信される各種コマンドの送信処理を行うための手段である。第一の送信プログラム３０８が送信するコマンドについては後述する。

第二の送信プログラム３０９は、第一の送信プログラム３０８が送信対象である各種コマンドのうち、発注コマンド（発注データ）が送信かつ受理された後に、印刷対象データである入稿データを送信するための送信手段である。入稿データ並びに第二の送信プログラムの動作については後述する。

第一の受信プログラム３１０は、第一の送信プログラム３０８および第二の送信プログラム３０９によるコマンドやデータが印刷業者システム１０４に送信され、処理結果であるレスポンスデータを受信、受信結果を解析するための手段である。

図４は、印刷業者システム１０４における情報処理装置１０８が有するプログラムの構成を例示した図である。

ブートローダ４０１、オペレーティングシステム４０２は、ネットワーク制御プログラム４０３、ウェブシステム４０４の処理内容と役割は図３において示した同名の手段と同じであるため、説明を割愛する。

受注情報管理プログラム４０５は、印刷業者システム（１０１、１０２、１０３）において中心的な役割を担うプログラムであり、ＭＩＳシステムと呼ばれる事もある。すなわち、発注者が当該印刷業者システム１０４の主目的である、発注者システム１０１による印刷成果物の発注に係る各種コマンドによる要求を受信する。そして実行した結果であるレスポンスの送信、各種コマンドを操作者に実行させるための指示手段等を提供する。ここにおける各種コマンドとその実行順序については後述する。

入稿データ保持プログラム４０６は、発注者システム１０１から入稿された印刷対象データを管理するための物である。

ＪＤＦ解析プログラム４０７は発注者システム１０１から受理した印刷成果物の発注依頼時に成果物の形態を電子的に表現するためのＪＤＦフォーマットファイルを受信およびその内容の解析をするためのプログラムである。ＪＤＦファイルに含まれる情報に基づき成果物の形態、部数、メディア等、生産を実施する上で必要となる事前条件、例えばワークフローの事前設定や生産計画立案等を実施する際に利用される。またこの情報に基づき、ワークフローを構成する各工程の処理内容、すなわち工程毎のジョブチケットが生成される。これらワークフローの事前設定や工程毎のジョブチケットの生成等は生産性向上を目的とした入稿データの先行処理を目的として為される。入稿データ、工程毎の先行処理については後述する。

第二の受信プログラム４０８は、図３において示した第一の送信プログラム３０８によって送信される各種コマンドの受信処理を実行するためのプログラムである。

第三の受信プログラム４０９は、図３において示した第二の送信プログラム３０９によって送信される入稿データを受信するためのプログラムである。

第二の受信プログラム４０８、第三の受信プログラム４０９が受信するコマンドやデータの例については後述する。

第三の送信プログラム４１０は、第二の受信プログラム４０８、第三の受信プログラム４０９が受信した結果をレスポンスとして図３に示した発注者システム１０１における第一の受信プログラム３１０に対して送信するプログラムである。第二の受信プログラム４０８、第三の受信プログラム４０９が受信したコマンドやデータを受注情報管理プログラム４０５、入稿データ保持プログラム４０６が処理し、結果のレスポンスを第三の送信プログラム４１０によって送信する。

ワークフロー制御プログラム４１１は印刷業者システム１０４内部のネットワーク１０９を介して接続された機器間の処理や制御、工程毎のジョブ実行等を集中的に管理するためのプログラムである。これは印刷業者システム１０４の中核をなすものである。複数工程、すなわち複数の装置を用いて成果物を製造する際に、その実行順序やジョブの実行制御等を行う。また、使用する装置の選択、切り替え、リカバリ生産等の制御もワークフロー制御プログラム４１１が実行する。また、印刷業者システム１０４内部で働くオペレータに対し各種の指示を出す処理もワークフロー制御プログラム４１１が実行する。

ワークフロー制御プログラム４１１は次に示す情報に基づき、求められた成果物を生産するために必要な工程を定義する。第一に、第二の受信プログラム４０８が受信する発注コマンド（発注データ）である。発注コマンドは印刷業者システム１０４が発注者システム１０１からの受注を受けた際に送付され、ＪＤＦ解析プログラム４０７によって保持管理する発注内容情報を含む。第二に、第三の受信プログラム４１０が受信する入稿データである。その上で、ワークフローにおけるジョブを生成および維持、管理、制御する。ワークフローにおけるジョブを工程毎に実行する事によって、発注者が要望する成果物が段階的に生産され、結果的に最終成果物に至る。

また本実施形態においては、発注者システム１０１から受理する入稿データを受理する際に、当該入稿データに対応する入稿コマンドの処理の可否に関する制御も同ワークフロー制御プログラム４１１が行う場合の一例を示している。

すなわち、課題で述べた通り発注者システム１０１は印刷業者システム１０４に対して第三の受信プログラム４０９が受信する入稿データの受理およびその後の処理内容を可変的に制御可能とする構成をとっている。つまり、第三の受信プログラム４０９が受信する入稿データが、発注者システム１０１が当該入稿データについて、確定したものであることを示す確定情報から判別する機能を有する。つまり、本実施形態におけるワークフロー制御プログラム４１１は、発注者システム１０１から受信した入稿データが「確定状態」であるか否かを判別する機能を有する。同手段によって判別された結果が、確定状態である場合、当該入稿データに関する更なる後から入稿や差し替え入稿はない旨、発注者システム１０１が表明していることを判別することが可能である。従ってこのような場合には印刷業者システム１０４は、入稿したデータをワークフロー制御プログラム４１１が管理するワークフローを作動させることによって当該入稿データに係る生産に着手することが可能となる。

一方で、発注者システム１０１から受信した入稿データが「確定状態」であると判別することができない場合は次のようになる。つまり印刷業者システム１０４は当該入稿データをめぐり後のタイミングにおいて更なる後から入稿や差し替え入稿が為される可能性があると判別することが可能となる。この場合には当該入稿データに係るワークフロー制御プログラム４１１による生産に着手せず、後において為される可能性のある後から入稿、差し替え入稿による入稿データの更新により無駄な処理や後戻りなどが生じないように効率よく制御することを可能とする。

プリプレスプログラム４１２は、第三の受信プログラム４０９が受信し、入稿データ保持プログラム４０６が管理する入稿データに対し、面付け、画像加工、データフォーマット変換等のような、印刷の前処理工程を実行するためのプログラムである。プリプレスプログラム４１２はワークフロー制御プログラム４１０の制御下で実行される。

生産管理プログラム４１３はワークフロー制御プログラム４１１と協調し、印刷業者システム１０４全体の機材および人員の稼働計画や稼働状況を管理するためのプログラムである。

図５Ａ、図５Ｂ、図５Ｃは、発注者システム１０１における情報処理装置１０７において実行される、図３にて示した発注情報管理プログラム３０５が表示する操作画面の一例を示したものである。

図５Ａは本実施形態における発注情報管理プログラム３０５の主画面５００のうち注文設定メインタブ５０１が選択された状態を示している。同図に示す例においては、印刷業者選択部５０２が提示され、第一の印刷業者５０３、第二の印刷業者５０４、第三の印刷業者５０５が表示されている。発注者は、所望の印刷業者の何れかから、発注処理を実施する印刷業者を選択することが可能である。また、不図示の印刷業者管理画面によって、発注可能な印刷業者の追加や削除等の管理も可能なよう本実施形態における発注情報プログラム３０５は構成されている。また、同図に示す例においては第二の印刷業者５０４が発注先として選択された状態である場合を示している。

コマンド選択部５０６においては、発注者システム１０１が印刷業者システム１０４に対して、印刷成果物の受発注に係る各種処理を伝達するコマンドの選択手段が複数設けられている。

見積依頼コマンド発行部５０７は、印刷業者選択部５０２において選択された印刷業者に対し、成果物作成に要する費用の見積もり依頼コマンドの送信指示を行うためのものである。見積依頼コマンド発行部５０７を押下すると不図示である見積依頼に必要な各種情報を入力する画面に遷移し、印刷業者は同画面を利用して見積依頼コマンドの発行に必要な情報の入力処理を行う。

発注依頼コマンド発行部５０８は、印刷業者システム１０４に対して成果物の発注に必要なコマンドならびに情報を送信するための指示手段である。同指示手段によって送信されるコマンド並びにデータは次に示す通りである。第一に、見積依頼コマンド発行部５０７を選択して取得した見積情報に基づき生成された発注コマンドである。第二に同じく見積情報に基づき生成され、ＪＤＦ編集部５１５によって編集された成果物の形態情報である。発注依頼コマンド発行部５０８を選択することによってこれらコマンド並びに情報が選択されている第二の印刷業者５０４に送信される。

入稿データ送信部５０９は、発注者システム１０１が印刷業者システム１０４に対して印刷対象となる入稿データの送信を指示する際に利用するためのものである。同手段による入稿処理は、発注依頼コマンド発行部５０８における発注処理以降に、かつ独立した処理として選択実行可能であるよう、本実施形態におけるシステムは構成される。

つまり、印刷成果物製造業の受発注をめぐる慣習において、発注処理と印刷対象となるデータの入稿処理は必ずしも同時に処理されるとは限らない。印刷業者においては発注処理を先行して受理および実行し生産に向けての各種処理を先行させる一方で、発注者は発注処理後に入稿データの制作や更新等を実施し、発注後に入稿データを印刷業者に送付することはしばしば行われている。

また、すべての入稿データが一度に制作され、印刷業者に入稿されるとも限らない。入稿データを構成するコンテンツのうちの、完成した部分から入稿し、すべての入稿データがそろった段階で入稿処理が完了するというケースも存在する。

さらには入稿データの完成度が最初の入稿時点において高いとは限らず、校正処理やプリフライト処理等を複数回経て生産用途に供することの可能な入稿データを完成させるということも、印刷成果物受発注業務においてはしばしば行われているケースである。

さらなる例として、一度入稿したデータを何らかの理由で差し替える、若しくは発注の段階では予定していなかったコンテンツを追加するなどのケースも実在する。

すなわち、発注処理と入稿処理は印刷業の慣習においては別タイミングとしてなされることがしばしばであり、理由は上述したとおりである。第一の実施形態において、図５Ａに示す通り、発注依頼コマンド発行部５０８と入稿データ送信部５０９が別手段として供されているのはこのような状況に柔軟に対処することを目的としたものである。

そのうえで、入稿データ送信部５０９は本手段によって発注者システム１０１が印刷業者システム１０４に送信する入稿データが確定済状態のものであるか否かを示す情報も付与して送信する機能を有する。さらにその際に確定済状態のものであるか否かを示す情報の設定手段を有する。

プルーフ依頼部５１０は、発注依頼コマンド発行部５０８ならびに入稿データ送信部５０９によって送信した印刷成果物の生産に必要となる製造条件や入稿データによって、いわゆる試し刷りを依頼するためのコマンドの送信指示を行うためのものである。

支払実行部５１１は発注依頼コマンド発行部５０８、入稿データ送信部５０９、プルーフ依頼部５１０等の手段を通じ、印刷業者システム１０４が生産した成果物の対価の支払処理を実施するためのコマンドの送信を指示する手段である。その際においては主に見積依頼コマンド発行部５０７の実行結果として取得される金額情報に基づき金額が計算され、主に電子的な手段によって決済処理がなされることを本実施形態におけるシステムにおいては想定しているものである。

状況確認部５１３は、発注者システム１０１と印刷業者システム１０４間で送受信されるコマンドやレスポンスの内容を表示するために設けられた手段である。具体的には主にコマンド選択部５０６において実行した発注者システム１０１が印刷業者システム１０４へのコマンドの送信履歴情報から成る。または、コマンドを受け印刷業者システム１０４が該コマンドを実行した結果であるレスポンス情報である。または、印刷業者システム１０４が発注者システム１０１に対して実行するコマンドや通知情報である。これら情報表示が同手段によって行われるよう本実施形態においては構成されている。

同図における例においては、まだ発注者システム１０１は第二の印刷業者５０４を選択したのみであり、コマンド選択部５０６によって何らコマンドの実行をしていない状態を示している。従って状況１（５１４）においては、２０２１年１月１４日１０時３０分時点では何ら処理が行われていない旨が示されている。

図５Ｂは、図５Ａの状態から発注者システム１０１が第二の印刷業者５０４に対してコマンド選択部５０６に設けられた各種手段による指示コマンドの実行と、そのコマンドに対するレスポンスの送受信履歴の一例を示したものである。以下、状況確認部５１３により示されるコマンド実行履歴から、本実施形態におけるシステムの挙動、すなわち発注者システム１０１と印刷業者システム１０４間でなされた成果物受発注コマンド実行の内容の詳細を述べる。

状況２（５１６）において、２０２１年１月１４日１１時３０分に発注依頼コマンド発行部５０８によって、第二の印刷業者５０４に対して発注コマンドが送信されたことを同図は示している。図５Ａにおいて述べた通り、発注コマンドの指示時にＪＤＦ編集部５１５にて編集および作成されたＪＤＦデータも同時に送信される。

状況３（５１７）において、状況２（５１６）の発注コマンドが印刷会社によって受理された旨示されている。

入稿データ送信部５０９の選択によって、入稿データの発注者システム１０１から第二の印刷業者５０４に対する送信処理が実行される。その際、状況確認部５１３における状況４（５１８）によって２０２１年１月１５日１３時００分に該処理が実行された旨の情報通知が為される。また、その際に送信される入稿データのファイル名（５１９）が示される。さらに、同入稿データは発注者システム１０１においては、確定済ではない状態（５２０）によって印刷業者システム１０４に送信されたものであることをも同図の例では示している。

状況４（５１８）によって同図に示した入稿データ送信部５０９の実行による入稿処理は、印刷業者システム１０４によるレスポンス（状況５（５２１））によって受理されたことが示される。印刷業者システム１０４からのレスポンスに含まれる更なる詳細な情報を確認する場合には詳細確認表示部５２２を押下すれば内容を参照することが可能である。

状況６（５２３）においては、２０２１年１月１５日１３時３０分に、入稿データ送信部５０９の選択によって、さらなる入稿処理が印刷業者システム１０４に対して為された場合の例を示している。また、同図に示す通り、入稿データのファイル名５１９は、状況４（５１８）において実行されたファイル名５１９と同一であることが示されている。つまり、状況６（５２３）における入稿処理は状況４（５１８）において実行された入稿処理に対する差し替え入稿に相当する。さらに、状況６（５２３）における入稿処理は、確定済の状態（５２４）として印刷業者システム１０４に送信されたものであることをも同図の例では示している。

状況７（５２５）においては、状況６（５２３）において為された入稿データ送信部５０９の実行による入稿処理が、印刷業者システム１０４が受理した旨のレスポンスが示されている。

図５Ｃは、発注者システム１０１が備える入稿データ送信部５０９を選択した後に、該入稿データ送信処理時の詳細な設定を行うための入稿データ設定詳細画面５２６の一例を示したものである。同図に示す画面はタイムスタンプ５２７において示された時間にファイル名５１９によって示されるデータが入稿される場合の一例を示したものである。

入稿対象となるファイルはファイル選択部５２８によって任意に選択可能なよう構成され、選択されたファイルのファイル名５１９が表示される。

入稿データ送信モード設定部５２９は、ファイル名５１９で選択されている入稿データを発注者システム１０１が印刷業者システム１０４に送信する際の送信設定の詳細を設定する手段を提供する。

新規データ入稿選択部５３０はファイル選択部５２８によって選択されファイル名５１９に示されたファイルを新規に発注者システム１０１が印刷業者システム１０４に送信する場合に選択するためのものである。

更新データ入稿選択部５３１はファイル選択部５２８によって選択されファイル名５１９に示されたファイルが既に入稿されている状態で、同名のファイルを再入稿し更新する目的で利用されるものである。

入稿対象データ確定部５３２は上述した入稿データファイルの選択及び送信手段によって発注者システム１０１が印刷業者システム１０４に送信するデータを確定したものとして送信する場合に選択する手段である。

なお、ＯＫボタン５３３が選択された場合、上述した設定に基づき印刷業者システム１０４に対し入稿データおよび入稿データコマンドが送信され、図５Ａもしくは図５Ｂの画面に遷移する。一方でキャンセルボタン５３４が選択された場合には印刷業者システム１０４に対し入稿データおよび入稿データコマンドが送信されずに、図５Ａもしくは図５Ｂの画面に遷移する。

上述の通り発注者システム１０１と印刷業者システム１０４間で、印刷成果物の受発注業務に関し、特に発注・入稿処理に関するコマンドとレスポンスを相互のシステム間で交換されている例を図５Ａ、図５Ｂ、図５Ｃの一連の例によって示した。

図６Ａ、図６Ｂは印刷業者システム１０４における情報処理装置１０８において実行される、図４にて示した受注情報管理プログラム４０５が表示する操作画面の一例を示したものである。

図６Ａは本実施形態における受注情報管理プログラム４０５の主画面６００のうち受注処理メインタブ６０１が選択された状態を示している。同図に示す例においては、発注者選択部６０２が提示され、第一の発注者６０３、第二の発注業者６０４、第三の発注者６０５が表示されている。印刷業者は複数の発注者からの受注をこのような方式によって個別に識別並びに管理可能なよう、本実施形態における受注情報管理プログラム４０５の操作手段は構成されている。複数の発注者の何れかを選択し、その要求であるコマンドの内容に応じて必要な処理を講じることを可能としている。さらには、また、不図示の発注者管理画面によって、受注可能な発注者の追加や削除等の管理も可能なよう本実施形態における受注情報管理プログラム４０５は構成されている。また、同図に示す例においては第一の発注者６０３からの要求を処理すべく選択された状態である場合を示している。

コマンド選択部６０６においては、印刷業者システム１０４が発注者（１０１、１０２、１０３）に対して、印刷成果物の受発注に係る印刷業者としての各種処理を伝達するコマンドの選択手段が複数設けられている。主な用途としては図５Ａ、図５Ｂ、図５Ｃにおいて示した発注者システム１０１におけるコマンド選択部５０６によって指示された印刷業者に対する各種要求コマンドに対する受理と応答、すなわちレスポンスを選択するための手段として供されている。

見積依頼応答コマンド発行手段６０７は図５Ａにおける見積依頼コマンド発行部５０７による発注者システム１０１からの成果物作成に要する費用の見積もり依頼コマンドに対する応答を送信するためのものである。同手段によって指定された見積もり対象に対する見積金額情報を含むレスポンスが発注者システム１０１に送信される。

発注依頼応答コマンド発行手段６０８は図５Ａにおける発注依頼コマンド発行部５０８による発注者システム１０１からの発注コマンドに対する応答である受注の可否を発注者システム１０１に送信するためのものである。

入稿データ受理手段６０９は、図５Ａにおける入稿データ送信部５０９による発注者システム１０１からのデータ入稿依頼コマンドに対する応答をするための手段である。入稿データ受理の可否を含むレスポンスが同手段によって発注者システム１０１に送信される。

ワークフロー実行指示手段６１０は、以上で述べた一連の印刷成果物受発注業務に係るコマンドの送受信によって、その成果物の生産に必要な条件が整った段階で生産を指示するためにワークフロー制御プログラム４１１に指示を与えるためのものである。印刷業者システム１０４は発注を受けた段階でワークフローの処理を発注にかかる生産処理として先行的に実行指示することが可能である。その際に本指示手段は利用される。また、図５Ａ、図５Ｂ、図５Ｃにおいて述べた通り、発注者システム１０１から受理された処理対象データである入稿データが、確定したものであるか否かが先行処理を効果的に実行可能であると判断される場合の主要な条件の一つである。

つまり、入稿データが確定したものであることが判別される場合には同データに対して、後から入稿もしくは差し替え入稿等によって置き換えを要求されることが無い事が判明する。その場合には当該データの先行処理を印刷業者は実行することが可能である。このような生産の前倒し処理や前倒し可能な条件下において為される効率的な生産計画の立案によって、総合的な生産性向上、生産能力の向上効果を得ることが可能となる。それと同時に、入稿データが確定される前であれば前述した先行処理は実施しないように意図的に制御することによって、発注者に対して後から入稿、差し替え入稿等の柔軟性等の利便性や生産性を犠牲にすることなく提供することが可能となる。

図４において示したワークフロー制御プログラム４１１が実行対象とするワークフローの構成ならびにその動作については後述する。

支払依頼実行手段６１１は印刷業者システム１０４が発注者システム１０１から依頼された印刷成果物の生産に係る費用を依頼主である発注者に対し請求する際に選択および実行されるコマンドの指示手段である。図５Ａにおいて示した支払実行部５１１に先んじて実行されるか、若しくは前後して実行指示されるべく設けられている。

状況確認手段６１３はコマンド選択部６０６において実行した発注者システム１０１から受信したコマンド、もしくは印刷業者システム１０４が該コマンドを実行した結果であるレスポンスの内容を表示するためのものである。ただし、印刷業者システム１０４が発注者システム１０１に対して実行するコマンドや通知情報などの表示も同手段によって表示可能なよう本実施形態においては構成されている。

状況１（６１４）において、図５Ｂの状況２（５１６）、すなわち２０２１年１月１４日１１時３０分に発注依頼コマンド発行部５０８により第二の印刷業者５０４に対して送信された発注コマンドが受信されたことを示している。

図６Ｂは、図６Ａにおいて示した状態から、発注者システム１０１および印刷業者システム１０４との間でなされた成果物受発注における各種コマンドの実行が為された状態の一例を示すためのものである。以下、状況確認手段６１３によって提示される情報に基づき、印刷業者システム１０４が発注者システム１０１との間でやり取りした処理内容の詳細の例について説明する。

状況２（６１５）において、印刷業者システム１０４が発注依頼応答コマンド発行手段６０８の選択によって、発注者システム１０１から受理した発注依頼を受理したことが示されている。状況２（６１５）は状況１（６１４）に対する応答（レスポンス）となっている。

状況３（６１６）において、図５Ｂにおける状況４（５１８）、すなわち入稿データ送信部５０９の実行による入稿データおよびその送信コマンドが印刷業者システム１０４によって受理されたことを示している。図５Ｂにおいて示した通り、状況４（５１８）において送信された入稿データは確定済ではない状態（５２０）によるものであった。従ってその旨を示す入稿データ未確定状態表示６１７によってそのことが示されている。

状況４（６１８）において、状況３（６１６）において受信した入稿データ送信コマンドのレスポンスを印刷業者システム１０４が発注者システム１０１に対して送信されていることを同図の例において示している。

状況５（６１９）において、図５Ｂにおける状況６（５２３）において為されたにおける状況４（５１８）の入稿データの差し替え入稿処理に関する情報が同図の例において示されている。また、図５Ｂにおいて示した通り確定済の状態（５２４）として同差し替え入稿処理が為されたことを示す確定済データ識別情報６２０が示されている。この段階において、印刷業者システム１０４はファイル名５１９によって示される、入稿データは確定したものであることが発注者システム１０１から通知されたことを認識することが可能である。つまり、ファイル名５１９によって示される入稿データは印刷業者システム１０４がその生産に係る各種ワークフローの処理を先行実行しても構わない。

状況６（６２１）において、状況５（６１９）で為された入稿データの受理と当該データが確定されたものである旨の通知を受理した事を示すレスポンスを印刷業者システム１０４が発注者システム１０１に送信されている。そして印刷業者システム１０４は入稿されたデータが、確定済データ識別情報６２０により示される通り確定済であるために、当該データの処理をワークフロー実行指示手段６１０が実行指示された状態（６２２）であることを同図の例は示している。

図７は、図５Ｂにおいて説明した操作から、更なる入稿処理を、発注者システム１０１を選択した印刷業者システム１０４に対して実施した場合の一例を説明するためのものである。

図７（Ａ）は図５Ｂに示した通り、確定済の入稿データに対して更なる入稿処理を実施しようとした際の発注者システム１０１の挙動の一例を説明するためのものである。

状況１（７０１）において、２０２１年１月１５日１３時５０分に入稿データ送信部５０９によって更なるデータが入稿された場合の例を示している。すなわち、図示の通り“Ｃｏｎｔｅｎｔ３．ｐｄｆ”というファイル名５１９によって示される入稿データファイルがさらに入稿処理された場合を示している。ただし、状況１（７０１）の時点で、ファイル名５１９の入稿データは確定済（５２４、６２０）となっており、当該データは印刷業者システム１０４のワークフロー実行指示手段６１０によって処理が開始されている（６２２）。つまり、既に発注者システム１０１から、入稿されたデータに対して明示的に確定したものであると通知され、印刷業者システム１０４が生産に着手したデータをさらに入稿しようとした場合に相当する。これは発注者システム１０１が入稿対象データ確定部５３２によって確定指示したデータをさらに差し替え入稿すべく送信することを意味する。

状況２（７０２）において、状況１（７０１）の確定後データに対する入稿処理に対するレスポンスを印刷業者システム１０４が発注者システム１０１に対して送信された場合の例を示している。その際に、状況１における入稿処理が拒絶された旨のメッセージ（７０３）が同図における例においては提示されている。詳細表示手段７０４は、状況２（７０２）のレスポンスの内容の詳細を確認するために設けられた手段である。

図７（Ｂ）は図７（Ａ）において、詳細表示手段７０４を選択した後の表示状態の一例を示すためのものである。すなわち確定済の入稿データである“Ｃｏｎｔｅｎｔ３．ｐｄｆ”の差し替え入稿要求が図７（Ａ）における状況１（７０１）において受理されなかった理由等に関する詳細要因の情報を同手段は提示する。

詳細要因情報提示部７０４には、確定後入稿データの差し替え入稿処理依頼を受信した第二の印刷業者５０４から、当該差し替え入稿処理の受理されなかったことに関する理由７０５が記載されている。すなわち第二の印刷業者５０４においては発注者システム１０１から入稿された確定済データの製造に係る印刷業者内ワークフローの工程による生産処理が開始されたため当該データの入稿処理が受理されなかった旨の情報が呈示されている。

図８は、図５Ａ、図５Ｂ、図５Ｃおよび図６Ａ、図６Ｂにおいて示した発注者システム１０１と印刷業者システム１０４との間でやり取りされるコマンドおよびレスポンスのシーケンスを説明するためのものである。

発注者システム１０１から印刷業者システム１０４に対して見積依頼コマンド８０１が送信される。同コマンド送信の指示は図５Ａにて示した通り、見積依頼コマンド発行部５０７によって指示される。

印刷業者システム１０４は見積依頼コマンド８０１に対するレスポンス８０２として、見積情報８０２を発注者システム１０１に対し送信する。レスポンス８０２の送信は、図６Ａにて示した見積頼応答コマンド発行手段６０７によって指示される。

レスポンス８０２に含まれる見積もり情報に基づき、発注者システム１０１は発注依頼コマンド８０３を印刷業者システム１０４に対して送信する。発注依頼コマンド８０３は、図５Ａにて述べた注依依頼コマンド発行部５０８によって指示される。

発注依頼コマンド８０３を受信した印刷業者システム１０４は、発注内容を受理し、生産体制の準備を実施する（８０４）。具体的には後述するワークフローのセットアップに必要となる処理を実施する。これらは確定済入稿データの処理に先立って行われることを本実施形態におけるシステムでは想定したものである。

印刷業者システム１０４が発注依頼コマンド８０３を受理した場合、そのレスポンス８０５を発注者システム１０１に対し送信する。レスポンス８０５の送信は、図６Ａにて示した発注依頼応答コマンド発行手段６０８によって指示される。

以後、発注者システム１０１は、印刷対象である入稿データを制作し、準備ができた段階で入稿コマンド８０６によって印刷業者システム１０４に対し送信し入稿処理を実行する。入稿コマンド８０６は図５Ａにて述べた入稿データ送信部５０９によって指示される。

ただし、入稿コマンド８０６において実行される入稿処理は、図５Ｂにおいて示した確定済の状態（５２４）として入稿されたデータである場合の例を同図は示している。この場合、入稿されたデータは確定されたものであるために、以後の段階で再度入稿データを差し替える等の再入稿処理は許容されない。従って印刷業者システム１０４は当該入稿コマンド８０６によって受理した入稿データに基づく生産の先行処理を開始する。

すなわち、入稿データを受信した印刷業者システム１０４は、受信したデータに対するプリフライト処理８０７を実行し、終了後にレスポンス８０８を発注者システム１０１に対して送信する。レスポンス８０８の送信は入稿データ受理手段６０９によって指示される。そしてそのあと直ちに入稿コマンド８０６において入稿された入稿データを用いた生産処理、すなわちステップ８０４にて準備されたワークフローによる当該処理の生産処理８０９が先行的に開始される。

しかしながら、同図においては、フローがステップ８０９まで進行した後に、入稿コマンド８０６において確定済の状態（５２４）として入稿されたデータに対する新たな入稿データがさらに入稿された場合を示している。すなわち入稿コマンド８０６において入稿されたデータの新たな入稿データを第二の入稿コマンド８１０によって発注者システム１０１が印刷業者システム１０４に対して入稿処理を実行した場合である。

すなわち確定済として受理され、当該データの生産の先行処理が開始された状況下において、新たな入稿データの入稿処理は本システムにおいては受理されない。従って、第二の入稿コマンド８１０が確定済データに対する再入稿であると判別され、当該入稿コマンドの受理は拒否される。その結果、第二のレスポンス８１１によって第二の入稿コマンド８１０は受理されなかった旨、印刷業者システム１０４から発注者システム１０１に対し送信される。その場合の、発注者システム１０１の発注情報管理プログラム３０５の画面の状態は図５Ｂもしくは図５Ｃに示した通りとなる。

要求された印刷成果物の生産８１２が終了した然るべきタイミングで、生産に要した諸費用の請求コマンド８１３が印刷業者システム１０４から発注者システム１０１に対して送信される。同コマンドの送信は図６Ａにおける支払依頼実行手段６１１により指示される。

請求コマンド８１３を受理した発注者システム１０１は相応する支払処理を実行するために支払いを実施するためのレスポンス８１４を印刷業者システム１０４に対して送信する。同レスポンスの送信の過程において電子的な決済処理が本実施形態におけるシステムにおいては為される。

決済処理が完了したのち、若しくは決済処理を前後して製造された印刷成果物を印刷業者システム１０４から発注者システム１０１に対して送付８１５される。同送付処理の実行は不図示の指定手段によって本実施形態におけるシステムにおいては為される。

図９Ａ、図９Ｂ、図９Ｃは、発注者システム１０１と印刷業者システム１０４間で送受信されるコマンドやレスポンスのデータの例を説明するためのものである。

図９Ａは発注依頼コマンド８０３とそのレスポンス８０５のデータの一例を示すためのものである。

発注情報部９０１には、当該データが発注依頼コマンドであることを示すコマンド文字列、一連の取引されている電子データを識別するＢｕｓｉｎｅｓｓＩＤ、本発注に関与している発注者と印刷会社を識別する情報等が含まれる。

発注内容記載部９０２は、成果物の商品名称、成果物の形態や部数等の生産内容、使用するメディア等の情報等である。これらは図３において示したＪＤＦ管理プログラム３０７や図５Ａ、図５Ｂ、図５Ｃに示したＪＤＦ編集部５１５によって作成された情報に相当する。

受注応答記載部９０３には、発注依頼の返信データに関する情報である。例として発注情報部９０１と同様に当該データが発注依頼コマンドの応答であることを示すコマンド文字列、一連の取引されている電子データを識別するＢｕｓｉｎｅｓｓＩＤ、本発注に関与している発注者と印刷会社を識別する情報等が含まれる。また発注が受理されたことを示すＯｒｄｅｒＳｔａｔｕｓ，印刷業者システム１０４から発注者システム１０１に返信する任意形式のコメント情報が含まれている。

図９Ｂは入稿コマンド８０６とそのレスポンス８０８のデータの一例を示すためのものである。

入稿情報部９０４には、当該データが入稿コマンドであることを示すコマンド文字列、一連の取引されている電子データを識別するＢｕｓｉｎｅｓｓＩＤ、本発注に関与している発注者と印刷会社を識別する情報等が含まれる。

また、当該入稿データは入稿処理された際に、確定された物であるか否かを明示的に示す情報である確定識別情報９０８を含む。確定識別情報９０８が値は真、すなわち当該入稿データは確定されものである場合の例を同図は示している。すなわち、図９Ｂにおいて示した入稿コマンドを発注者システム１０１から印刷業者システム１０４が受理した場合、同入稿データは確定したものとして認識される。また、同確定識別情報９０８の設定は図５Ｃにおいて示した、入稿対象データ確定部５３２の選択処理されたことを、発注情報管理プログラム３０５が処理し、第二の送信プログラム３０９が制御することによって設定、生成ならびに伝達される。

入稿データ指定部９０５においては、入稿対象である電子データのファイルを指定している。すなわち“Ｃｏｎｔｅｎｔ３．ｐｄｆ”というファイル（５１９）を追加データとして入稿する場合の例を同図においては示している。ただし、確定識別情報９０８によって、入稿データは追加入稿であると同時に確定されたものであり、再入稿が許容しない旨が示されている。

入稿応答記載部９０６は、入稿依頼の返信データとして入稿情報部９０４と同様の情報である。例として当該データが入稿コマンドの応答であることを示すコマンド文字列、一連の取引されている電子データを識別するＢｕｓｉｎｅｓｓＩＤ、本入稿に関与している発注者と印刷会社を識別する情報等が含まれる。また依頼された入稿データは受理され更なる入稿処理も可能であることを示すＲｅｓｕｌｔの例を同図において示している。

プリフライト結果記載部９０７には、印刷業者システムによるプリフライトの結果が含まれる。例えば、プリフライトを実施した入稿データのファイル名５１９、プリフライト結果９０９である。

図９Ｃは第二の入稿コマンド８１０とその第二のレスポンス８１１のデータの例を示すためのものである。図９Ｂにおいて示した入稿コマンド８０６との差異部分について主に以下説明する。ただし、コマンドおよびレスポンスに含まれる内容は図５Ａ、図５Ｂ、図５Ｃならびに図６Ａ、図６Ｂにおいて示したものであるため、コマンドが発せられた条件と発生した状況に関する重複する説明は割愛する。

図９Ｃの第二の入稿情報部９１０においては、当コマンドが既に入稿済のデータを更新するための再入稿処理であることを示す再入稿指定情報９１０を含む。また再入稿対象とするファイルは図９Ｂにおいて述べた通り確定識別情報９０８によって確定された情報のファイル（５１９）と同一である例を同図は示している。

入稿応答記載部９１１には、再入稿が受け付けられなかった旨を示す実行結果９１１が示され、実行結果詳細情報９１２にはその理由に関する情報が含まれる。実行結果詳細情報９１２の情報は図７（Ｂ）にて示した様な詳細要因情報提示部７０４における理由７０５の情報の表示制御を行う際に用いられることを本実施形態におけるシステムにおいては想定している。

図１０は、印刷業者システム１０４が発注者システム１０１から確定済データの入稿を受理した後に、内部で動作するワークフローによる工程の先行処理の具体的な一例およびその効果を説明するための図である。

図１０（Ａ）に入稿データとそれを処理されるワークフローの各工程の依存と順序関係を示している。図１０（Ｂ）には図１０（Ａ）において示した入稿データの一例を示している。ここでは、最終成果物（印刷成果物）が、４つの部品から生成され、部品毎の入稿データがある例である。また図１０（Ｃ）には図１０（Ａ）にて示した工程の処理内容の具体例を示している。これらの図に示す例を用いて、入稿したデータから成果物を生成する際に、入稿データが確定済であることを印刷業者システム１０４が判別可能である場合に、ワークフローの各工程を先行処理することによって得られる効果について以下示す。

同図における例では４つの入稿データから単一の成果物が構成される場合の例を示している。また同図において示す例においては、これら４つの入稿データから最終成果物１０１２として製本成果物を構成する場合の例を示している。

入稿データ１（１００１）は最終成果物１０１２の表紙に相当する部分の画像情報として用いられるデータの例であることを同図は示している。同様に、入稿データ２（１００２）は、最終成果物１０１２である製本成果物の本文における文書部のページを構成するために利用されるデータの例を同図は示している。さらに同様に、入稿データ３（１００３）はる製本成果物本文のカラー写真ページを、入稿データ４（１００４）はる製本成果物の本文のカラー図表ページを構成するために利用されるデータの例を示している。

同図は、単一の成果物が複数の異なる目的、および性質による入稿データによって生成される例であることを示している。また以下、これら複数の異なる入稿データからどのような作業工程、つまり、ワークフローの工程を経て最終成果物１０１２が生成されるかを示す。

工程１（１００５）は表紙用のＣＭＳ処理を行うためのプリプレス工程である。表紙はＣＭＹＫ４色によるプロセスカラーに加え特色を用いる場合の例であり、特色を考慮したＣＭＳ処理を工程１（１００５）において実施する必要がある。一方で、工程４（１００８）のＣＭＳ処理は、特色を含まないＣＭＹＫ４色によるプロセスカラーのみのＣＭＳ処理を実施するためのプリプレス工程である。従って同じＣＭＳ処理であっても適用するデータとその処理対象とする色空間が異なるために別工程として処理される。工程４（１００８）においては、表紙用データである入稿データ１（１００１）を除く入稿データのうち、カラーの入稿データである入稿データ３（１００３）、入稿データ４（１００４）の２ファイルが処理対象である。従って入稿データ３（１００３）、入稿データ４（１００４）が工程４（１００８）を先行処理するためには必要であるということを同図は示している。

工程１（１００５）、工程４（１００８）の説明で述べた通り、ワークフローの各工程には工程が処理する入稿データもしくは中間データや中間成果物を処理対象、すなわち入力とし、工程に規定された処理を実行した後に、工程の処理結果を出力として生成する。生成された出力とは新たな中間データや中間成果物であり、さらに次工程への入力として処理が連鎖的に実施されるようワークフローは構成される。

同図おいては上述の通り複数の工程が順序や依存関係を有し、データや中間データや成果物を後段の工程への入力とし処理を連鎖させ、最終工程である工程７（１０１１）の処理を完了させることにより最終成果物１０１２を得ることが可能である。

その際に、本実施形態によるシステムが実現する効果について以下説明する。図１０に示す通り、複数の入稿データから、複数の工程に順序や依存関係のあるワークフローの工程間の処理を経て結果的に最終成果物の生成が行われる。このことが印刷業者システム１０４において、製本成果物などの印刷成果物を生成する際の汎用的な手法となっている。これらの用途にはＪＤＦと呼ばれるワークフローを構成するために必要な情報のフォーマットを定めた業界標準仕様およびそれを適用したシステムによって為されることが知られている。つまり、ＪＤＦはそのような処理を効果的に達成するために考案されたものである。本実施形態におけるシステムにおいてもワークフローの工程間処理およびその順序や依存の連鎖によって最終成果物を生成する仕組みについてはＪＤＦに代表されるワークフロー制御の仕組みに基づくものとして為されることを前提としている。ただし、ＪＤＦによるワークフローシステムの仕組み並びにその構成に関する詳細に関しては割愛する。

入力データである入稿データが確定したものであることを印刷業者システム１０４が認識することが出来る場合、当該入稿データを入力として処理されるよう構成された各工程はその処理を開始することが可能である。同図に示す通り、入稿データから最終成果物を得るまでの間には様々な工程が存在し、かつ互いに図示するような依存関係が存在する。

印刷業者システム１０４は最終成果物を構成する上で必要となる全ての入稿データ（１００１、１００２、１００３、１００４）が揃うまで処理を開始できないとすれば、生産効率が落ちる。さらには、入稿データが揃ったとしてもそれらが確定した物でなければ、入稿データを各工程が処理を開始することはできない。つまり、入稿データが確定したものであると判別できなければ入稿データおよびそのデータを処理する各工程によって先行処理を実施し、生産性を向上させることができない。確定していない入稿データを、データを処理する工程によって各種処理をした後に、入稿データの差し替えなどの再入稿が行われた場合には、実行済の処理が無駄になる。さらには途中まで生成した処理結果である中間データや中間成果物を破棄し、再度入稿されたデータを処理しなおさねばならない。従って、本実施形態は、印刷業者システム１０４にとっては先行処理による生産性向上のメリットを、発注者システム１０１にとっては入稿の柔軟性を確保することを目指している。

工程２（１００６）においては、入稿データ２、３、４（１００２、１００３、１００４）を入力として本実施形態における例では示している。つまり、入稿データ２、３、４（１００２、１００３、１００４）が確定済の状態として入稿された場合に工程２（１００６）はその処理を先行的に開始するように本実施形態におけるシステムでは構成される。工程２（１００６）は背幅を決定するための工程である。これは工程１（１００５）の結果と同時に工程６（１００９）すなわち表紙の生産に必要な情報である。従って工程６（１００９）を実行するためには工程１（１００５）および工程２（１００６）の双方の処理が完結した状態となって初めて開始することが可能である。

すなわち、工程６（１００９）を先行的に処理するためには工程１（１００５）および工程２（１００６）の先行処理も必然的に完了していなければならない。そのためには、は工程１（１００５）および工程２（１００６）が必要とする入稿データである入稿データ１、２、３、４（１００５、１００６、１００７、１００８）が入稿され、かつ確定された物であると当該システムにおいて判定される必要がある。つまり、入稿データ１、２、３、４（１００５、１００６、１００７、１００８）が入稿され、かつ確定された物である場合には、当該システムにおいては工程６（１００９）までの先行処理を実施することが可能である。

工程３（１００７）においては、入稿データ２（１００２）を入力として本実施形態における例では示している。つまり、入稿データ２（１００２）が確定済の状態として入稿された場合に工程３（１００７）はその処理を先行的に開始するように本実施形態におけるシステムでは構成される。

工程５（１０１０）は最終成果物１０１２を構成する、表紙を除く製本成果物本文の部分を作成するための工程である。つまり、表紙に関する入稿データおよび付随する工程処理の結果を除外した残りの情報並びに中間成果物が揃ったことを以て処理を開始することのできる工程であると本実施形態におけるワークフローの例を示している。

同図に示す通り、工程５（１０１０）の開始条件は、その前段である工程２、３、４（１００６、１００７、１００８）の処理結果である中間データもしくは中間成果物が揃うことである。そのためには工程２、３、４（１００６、１００７、１００８）の先行処理が完了しておらねばならず、同図に示すこれら工程の入力である入稿データ２、３、４（１００２、１００３、１００４）が入稿され、かつ確定状態となっている必要がある。

つまり、入稿データ２、３、４（１００６、１００７、１００８）が入稿され、かつ確定された物である場合には、当該システムにおいては工程５（１０１０）までの先行処理を実施することが可能である。

工程７（１０１１）は工程５、６（１０１０、１００９）の結果である中間成果物を合成し最終成果物１０１２を生成するための工程である。

工程７（１０１１）の前段に位置する工程の処理と、その工程が必要とする結果を生ずる工程、入力となる入稿データ確定等の条件が連鎖的になされ、それらを判別することにより先行処理が自動的に実行される。

図１１は、ワークフロー制御プログラム４１１が管理する、第二の受信プログラム４０８が入稿コマンド（８０６、８１０）によって受理した入稿データを管理する入稿データ管理テーブル１１００の一例を示したものである。同入稿データ管理テーブル１１００はワークフロー制御プログラム４１１をＣＰＵ２０１が実行することによりＨＤＤ２１１内に生成、更新並びに管理される。

同図に示す通り、入稿データファイル管理情報フィールド１１０１と対応する確定情報フィールド１１０２から成る。同図に示す例においては３つの入稿データが入稿された状態を示している。第一の入稿データ（１１０３、１００１）、第二の入稿データ（１１０４、１００２）、第三の入稿データ（１１０５、１００３）の３つである。これらを図１０における例において示した各入稿データと対応したものとして同図の例は示している。

同図に示す通り、第一の入稿データ（１１０３、１００１）、第二の入稿データ（１１０４、１００２）における確定情報フィールド１１０２の値はＦＡＬＳＥである。すなわちこれらの入稿データは確定された状態ではない。一方、第三の入稿データ（１１０５、１００３）の確定情報フィールド１１０２の値はＴＲＵＥである。すなわちこのデータは確定された状態である。

尚、本実施形態では、確定しないファイルの情報、すなわち、確定情報フィールド１１０２の値がＦＡＬＳＥの情報も送る例を示したが、確定するファイルの情報、すなわち、確定情報フィールド１１０２の値がＴＲＵＥの情報のみを送るようにしてもよい。

図５Ａ、図５Ｂ、図５Ｃ、図８における例で示した通り、入稿データが確定済の物であるか否かによって同一データに対し以降為される再入稿、いわゆる後から入稿、差し替え入稿等の挙動は可変的に制御される事は既述のとおりである。

図１２はワークフロー制御プログラム４１１の動作であって、発注者からの入稿処理の受理・非受理の処理判断の動作の仕組みを主に説明するためのフロー図である。同フロー図はワークフロー制御プログラム４１１をＣＰＵ２０１がＨＤＤ２１１から読みだして実行することによって動作する。

ステップＳ１２０１において、ワークフロー制御プログラム４１１は発注者システム１０１から送付されてくる、図９Ａ、図９Ｂ、図９Ｃにおいて例を示したような実行依頼を既述したコマンドおよびデータを受理する。

発注者システム１０１から何らかのコマンドおよびデータを受信した場合ステップＳ１２０２に進み、受信したコマンドの種別を判別する。

ステップＳ１２０３においては、ステップＳ１２０２にて判別した、ステップＳ１２０１にて受信したコマンドの種別が入稿コマンド（８０６、８１０）であるか否かを判断する。同ステップの判別の結果が偽である場合、ステップＳ１２０５に進み、ステップＳ１１０１にて受信した、図８において示したような入稿コマンド（８０６、８１０）以外の各種コマンドを実行する。同ステップにおいて実行されるコマンドの内容と詳細な動作は省略する。

ステップＳ１２０３の判別の結果が真である場合にはＳ１２０１で受信したコマンドが入稿コマンド（８０６、８１０）であることを意味する。従ってステップＳ１２０４に進み、入稿コマンド受信時の入稿ファイルを検査する。

検査した内容は次のステップＳ１２０６において判別する。具体的にはステップＳ１２０１にて受信した入稿データが既に入稿済のデータであるか否かの判別を実施する。つまり、ステップＳ１２０１にて受信した入稿データが既に入稿されたデータに対する再入稿処理に相応するか否かの判定を同ステップにて実施する。

ステップＳ１２０６の判別の結果が偽である場合、すなわちステップＳ１２０１にて受信した入稿コマンド（８０６、８１０）により入稿された入稿データが新規の入稿データである場合にはステップＳ１２１０に進む。

一方で、ステップＳ１２０６の判別の結果が真である場合、すなわちステップＳ１２０１にて受信した入稿コマンド（８０６、８１０）により入稿された入稿データが既に入稿実績のあるデータである場合にはステップＳ１２０７に進む。

ステップＳ１２１０においては、ステップＳ１２０１における入稿コマンド（８０６）により入稿された入稿データの新規登録処理を実施する。同ステップの処理は後述する。ステップＳ１２１０の処理が完了したらステップＳ１２１１に進み、ステップＳ１２０１における入稿コマンド（８０６）による入稿処理は受理された旨の情報を示す、レスポンス（８０８）を発注者システム１０１に対して送信する。

ステップＳ１２０７においては、ステップＳ１２０６における判別処理において、ステップＳ１２０１にて受理した入稿コマンド（８０６、８１０）による入稿データが既に入稿済である場合に相当する。その場合には図１１にて示した入稿データ管理テーブル１１００における、入稿されたデータに対応する入稿データファイル管理情報フィールド１１０１のエントリに対する確定情報フィールド１１０２の値を検査する。

ステップＳ１２０７において検査された確定情報フィールド１１０２の値は次ステップであるステップＳ１２０８において判別される。

ステップＳ１２０８の判別の結果が偽である場合には、入稿されたデータに対応する入稿データファイル管理情報フィールド１１０１のエントリに対する確定情報フィールド１１０２の値がＦＡＬＳＥ、すなわち確定されたデータではない場合に相当する。この場合、確定済ではないデータと同一データの入稿、すなわち再入稿処理は可能であると当該システムにおいては制御される。故にステップＳ１２１０に進み入稿データの登録処理に進む。

一方でステップＳ１２０８の判別の結果が真である場合には、入稿されたデータに対応する入稿データファイル管理情報フィールド１１０１のエントリに対する確定情報フィールド１１０２の値がＴＲＵＥ、すなわち確定されたデータである場合に相当する。この場合、確定済のデータと同一データの入稿、すなわち再入稿処理は可能としないよう、当該システムにおいては制御される。故に入稿は受理されなかった旨の情報を示す、ステップＳ１２０９に進み入稿コマンド（８１０）に対するレスポンス（８１１）を発注者システム１０１に対して送信する。

図１３は図１２におけるステップ１２１０、すなわち入稿データの登録処理の内容を示すためのフロー図である。

ステップＳ１３０１において、入稿コマンド（８０６、８１０）により入稿されたデータが新規のデータであるか否かを判定する。すなわち、新規の入稿データを受理した物であるのか、既に入稿されたデータの差し替えに相当する再入稿処理に相当するのかを判定する。

同伴別の結果が偽、すなわち以前に相応する入稿データ受理の履歴は無く、新規の入稿処理に相当する場合にはステップＳ１３０２に進み、図１１において示した入稿データ管理テーブル１１００にエントリを追加する。

ステップＳ１３０１の判別結果が真である場合、すなわち入稿コマンド（８０６）により入稿されたデータが既に入稿されたものであるケースに相当する。この場合にはステップ１３０２のような新規エントリを入稿データ管理テーブル１１００に追加する必要がないため、ステップＳ１３０２を省略するよう動作する。

ステップＳ１３０３においては、ステップＳ１２０１にて受信した入稿コマンド（８０６）により入稿されたデータをＨＤＤ２１１に格納する。次にステップＳ１３０４に進み、入稿データ管理テーブル１１００における入稿データファイル管理情報フィールド１１０１の入稿データのデータ格納用エントリにファイル名等の入稿ファイル情報を格納する。続いてステップＳ１３０４に進み、対応する確定情報フィールド１１０２の値を受信した入稿コマンド（８０６）に含まれる情報に基づき登録する。

ステップＳ１３０５においては、ステップＳ１３０４で格納した確定情報フィールド１１０２の値を検査し、その値を次のステップであるステップＳ１３０６において判別する。

ステップＳ１３０６の判別の結果が偽、すなわちステップＳ１３０５において判別した確定情報フィールド１１０２の値がＦＡＬＳＥの場合、入稿データは確定済ではないと判別される場合、同図におけるフローは終了する。

ステップＳ１３０６の判別の結果が真、すなわちステップＳ１３０５において判別した確定情報フィールド１１０２の値がＴＲＵＥ、すなわち入稿データは確定済であると判別される場合、ステップＳ１３０７に進む。ステップＳ１３０７においては図１０において示した通り、確定された状態の入稿データを入力として先行処理を実行することが可能なワークフローの工程に対してその開始をワークフロー制御制御プログラムが指示する。これにより、確定済となった入稿データは処理可能と判別されたものから先行して印刷業者システム１０４は処理を開始することが可能である。入稿データの確定情報に基づく制御を行うことによって先行処理の実施が可能となり、これにより生産計画に柔軟性を持たせる等、効率性を向上させることが可能となる。また、発注者は、印刷業者に入稿データを送付する際、確定ではないデータであっても入稿を可能にし、かつ、再入稿されることも許容される。印刷業者は、入稿データが確定済であることが判定でき、確定済入稿データを処理するワークフローの工程の先行実行を可能となる。

（第２の実施形態）
第２の実施形態においては、第一実施形態とは異なる方法によって入稿されたデータについて、入稿データが確定済であるか否かを発注者システム１０１が印刷業者システム１０４に対し制御することを可能とする。

図１４は、第２の実施形態における、発注者システム１０１と印刷業者システム１０４との間でやり取りされる入稿コマンドおよび確レレスポンスの第二のシーケンスを説明するためのものである。以下、図８において示したシーケンスとの差分箇所に着目して説明する。

入稿済データ確定コマンド１４０１は、入稿コマンド８０６として既に発注者システム１０１から印刷業者システム１０４に対して入稿されたデータを、別コマンドにより確定済の状態とする制御コマンドである。第一実施形態においては、入稿コマンド８０６に含まれる、図９Ａ、図９Ｂ、図９Ｃにおける確定識別情報９０８によって入稿データに対して確定したものとするような制御を行うデータ並びに当該データに基づく制御に関するシステムの例を示した。

第二実施形態においては、入稿コマンド８０６とは分離したコマンドとして入稿済データ確定コマンド１４０１を設け、入稿済データ確定コマンド１４０１によって入稿データを確定するための制御を行うシステムの例である。

入稿済データ確定コマンド１４０１を受理した際のレスポンス１４０２が返却されると同時に、ワークフローがステップ８０９によってその実行が開始される。

これは入稿済データ確定コマンド１４０１により入稿されたデータが確定済であると印刷業者システム１０４が検知し図１０に示したワークフローの先行処理が開始されるようワークフロー制御プログラム４１１が制御を実行することによる。

図１５は、第２の実施形態における、発注者システム１０１と印刷業者システム１０４間で送受信されるコマンドやレスポンスの実際のデータの例を説明するためのものである。

第二実施形態における入稿コマンド１５０１には第一実施形態における入稿コマンド８０６における、確定識別情報９０８は含まれない。その代わりに、入稿確定コマンド１５０１（１４０１）によって、同等の効果を得るよう第二実施形態におけるシステムは構成される。入稿確定コマンド１５０１（１４０１）には、入稿済データのうちの何れのデータを確定するのかを示すためにファイル名５１９の情報が含まれる。

第二実施形態におけるシステムにおいては、入稿コマンドとは別のコマンドによって入稿データの確定処理を実行することが可能である。このことによって次に示すような、第一実施形態からは得られない追加のメリットを得ることが可能である。

第一に、入稿時点で発注者は対象入稿データが確定されているか否かの決定を保留にすることが可能である。確定したものであることが判明した時点で確定コマンドを後の適宜のタイミングで送信し、先の入稿データを確定することが出来る。これによって、第一実施形態よりもさらに柔軟な対応が可能となる。

第二に、確定コマンドは入稿コマンドとは分離されたコマンドとなっていることによって、入稿コマンドを投入したシステムもしくはその操作者とは別システムもしくは別操作者が確定コマンドを入稿処理と識別された処理として発行することが可能である。これによって例えば入稿コマンド発行者が入稿データの制作者であって、確定コマンド発行者が発注者システムの責任者等のような運用を可能にする。

第三に、第一実施形態のように確定識別情報９０８が入稿コマンドに含まれるコマンドデータ形式によると、入稿処理と同一処理としてしか確定処理をコマンドとして発行および実行することが出来ない。しかしながら、第二実施形態の様に入稿コマンドと確定コマンドが分離されている場合にはその限りではない。従って、複数の既に入稿済のデータに対して単一の確定コマンドによって同一的に入稿データを確定させるというような利用方法も第二実施形態によるシステムでは可能となる。

図１６は、第２の実施形態におけるワークフロー制御プログラム４１１の動作であって、発注者からの入稿処理の受理・非受理の処理判断の動作の仕組みを主に説明するためのフロー図である。同フロー図はワークフロー制御プログラム４１１をＣＰＵ２０１がＨＤＤ２１１から読みだして実行することによって動作する。第一実施形態における図１２に相当する。

ステップＳ１６０１においてワークフロー制御プログラム４１１は発注者システム１０１から送付されてくる、図１５において例を示したようなコマンド実行依頼を受理する。ステップＳ１６０２におけるコマンドの判別処理はステップＳ１２０２と同等であるため詳細は割愛する。

ステップＳ１６０３においては、ステップＳ１６０２において判別したコマンドの種類が入稿済データ確定コマンド１４０１であるか否かを判別する。入稿済データ確定コマンド１４０１の動作およびフロー並びにデータの詳細は、図１４、１５において述べた通りである。

同ステップにおける判別処理の結果が偽、すなわち入稿済データ確定コマンド１４０１ではないと判別された場合にはステップＳ１６０４に進み、入稿済データ確定コマンド１４０１以外のコマンドの実行処理を行う。入稿済データ確定コマンド１４０１以外のコマンドの実行処理の内容と詳細は省略する。

一方でステップＳ１６０３の判別の結果が真、すなわち受信したコマンドが入稿済データ確定コマンド１４０１であると判別された場合、ステップＳ１６０５以降の処理を実行する。

ステップＳ１６０５において、受信した入稿済データ確定コマンド１４０１に含まれる確定対象のファイルを特定する。具体的には図１４において示したファイル名５１９に基づき、図１１にて示した入稿データ管理テーブル１１００内のエントリを特定する。

ステップＳ１６０６において、ステップＳ１６０５において特定されたた入稿データ管理テーブル１１００内のエントリの、確定情報フィールド１１０２の内容に基づく判別処理を実施する。すなわち、ファイル名５１９に基づき確定情報フィールド１１０２のエントリ内の確定情報フィールド１１０２の値がＴＲＵＥであると判別される場合、確定済の入稿データに対する更なる確定処理の要求を意味する。この場合の確定処理は意味をなさないため、何も実行せずに同フロー図における処理は終了する。

一方でステップＳ１６０６の判別の結果が偽である場合、この場合には確定済ではない入稿データに対する入稿済データ確定コマンド１４０１による確定処理の要求を受理したことを意味する。従ってステップＳ１６０７に進み、入稿データ管理テーブル１１００内のファイル名５１９に対応するフィールドの確定情報フィールド１１０２をＴＲＵＥすなわち確定済状態に変更した上で、ワークフローの工程処理の実行を開始する（ステップＳ１６０８）。

以上が第二実施形態における、入稿データに対し入稿コマンドとは別に設けられた入稿データ確定コマンドによって入稿済のデータを確定させ、ワークフローの工程の処理を開始することにより先行処理を可能とする構成並びに技術の実現形態に関する説明である。

（変形例１）先行処理可能か否かのフラグを入稿データに付ける
第一、および第２の実施形態におけるシステムでは次に示すようなシステムであった。すなわち入稿データが入稿コマンドに含まれる確定情報、もしくは入稿済データに対する確定指示コマンドにより入稿データが確定した旨発注者システム１０１が印刷業者システム１０４に対し伝達するシステムであった。

これによって、印刷業者システム１０４は入稿されたデータが確定されたものであると判別可能なため、生産用に供するワークフローの各工程に予めセットされた設定に従い処理を先行実行することを可能とする技術であった。しかしながらワークフローとそれを為す工程は印刷業者システム１０４内に閉じている。従って外部システムに相当する発注者システム１０１からは、如何様な工程が存在し、かつそれらの間の順序や依存関係が如何様になっているかは自明ではない。

そのような条件下で確定した入稿データに対し先行処理が為されることは、生産性を向上させることを目的とした印刷業者システム１０４にとっては有益であったとしても、発注者システム１０１にとって同様とは限らない。ワークフローの処理工程が合意され、もしくは可視化された場合に限り確定済入稿データの先行処理を印刷業者システム１０４に対し許容することを要望する発注者も存在しうる。

変形例１はこのようなケースに対処するためのシステムである。すなわち、発注者システム１０１が印刷業者システム１０４に対して入稿データを送信する際に、当該入稿データに対して先行処理の実行を許容するか否かに関する情報を設定する手段、および設定された情報を判別する手段を有する。

これら手段によって、特定のデータに関しては確定済入稿データの先行処理を許容、もしくは許容しないよう可変的に制御可能なシステムの提供を可能とする。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形及び変更が可能である。

以上説明した実施形態によれば、ユーザ、すなわち発注者と受注者双方にとって利便性の高い受発注業務の仕組みを提供することができる。すなわち、発注処理と異なるタイミングでしかも複数回に及ぶ入稿処理を実施する発注者の都合と、請け負った印刷成果物の生産を効率的に進める印刷業者のワークフロー処理の効率的な実行を両立することが可能となる。これによって、発注者の要望および印刷業者の要望の双方を可能な限り満足しつつも現実的かつ効率的な印刷成果物の電子的な受発注システムの実現を可能とする。

Claims (11)

1. 印刷成果物の発注データと、前記発注データに対する入稿データを受信する受信手段と、
   前記印刷成果物の生産を行うように制御する制御手段を有し、
   前記印刷成果物の発注データと、前記発注データに対する入稿データとを異なるタイミングで受信し、
   前記受信手段は、さらに、前記入稿データの確定情報を受信し、
   前記制御手段は、前記発注データと前記入稿データと前記確定情報に基づいて、前記印刷成果物の生産を行うように制御することを特徴とする情報処理装置。
2. 前記受信手段は、前記発注データに対する新たな入稿データを受信し、
   前記制御手段は、前記確定情報に基づいて、前記新たな入稿データを、前記印刷成果物の生産に用いるかどうかを制御することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御手段は、前記確定情報に基づいて、前記印刷成果物の生産を行うワークフローの工程を制御することを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記制御手段は、前記確定情報を受信した後、前記印刷成果物の生産を行うように制御することを特徴とする請求項１又は請求項２に記載の情報処理装置。
5. 前記印刷成果物は、複数の部品からなり、
   前記受信手段は、前記部品毎の入稿データを受信することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. 情報処理装置の制御方法であって、
   印刷成果物の発注データを受信する工程と、
   前記発注データの受信とは異なるタイミングで、前記発注データに対する入稿データを受信する工程と、
   前記入稿データの確定情報を受信する工程と、
   前記発注データと前記入稿データと前記確定情報に基づいて、前記印刷成果物の生産を行うように制御する工程を有することを特徴とする情報処理装置の制御方法。
7. 前記発注データに対する新たな入稿データを受信する工程と、
   前記確定情報に基づいて、前記新たな入稿データを、前記印刷成果物の生産に用いるかどうかを判定する工程を有することを特徴とする請求項６に記載の情報処理装置の制御方法。
8. 前記制御する工程は、前記確定情報に基づいて、前記印刷成果物の生産を行うワークフローの工程を制御することを特徴とする請求項６又は請求項７に記載の情報処理装置の制御方法。
9. 前記制御する工程は、前記確定情報を受信した後、前記印刷成果物の生産を行うように制御することを特徴とする請求項６又は請求項７に記載の情報処理装置の制御方法。
10. 前記印刷成果物は、複数の部品からなり、
    前記入稿データを受信する工程は、前記部品毎の入稿データを受信することを特徴とする請求項６乃至９の何れか１項に記載の情報処理装置の制御方法。
11. 請求項１乃至５の何れか１項に記載の情報処理装置としてコンピュータを機能させるための該コンピュータで読み取り可能なプログラム。

Images