(57)【要約】【課題】  印刷オーダー管理装置において、最初にサーバへ注文指示情報をアップロードした注文者に対して、アップロードした注文指示情報を部分的に非公開に設定することを許容する。【解決手段】  印刷製本注文システムにおいては、既にサーバへアップロードされている注文指示情報に対する、差分指示情報をアップロードすることで修正を含む再注文を可能とする。【選択図】  図１
2005173800.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信媒体上に接続された、少なくとも1つ以上の印刷製本注文管理装置および、少なくとも一つ以上の端末装置を備えた印刷製本注文装置において、
前記端末装置から前記印刷製本注文管理装置に対する印刷製本注文指示を提供する注文指示提供手段、
前記注文指示提供手段によって指示された個々の注文指示を識別するための注文指示識別手段、
前記注文指示識別手段による注文指示の識別を元に前記注文指示提供手段によって指示された注文指示に対する差分注文指示を提供する差分注文指示提供手段、
を備えることを特徴とする印刷製本注文装置。
【請求項２】
請求項１における印刷製本注文装置において、
前記注文指示識別手段は前記差分注文指示提供手段によって指示された注文指示も前記注文指示提供手段によって指示された注文指示も同様に識別できる手段であること、
を特徴とする印刷製本注文装置。
【請求項３】
請求項１あるいは請求項２における印刷製本注文装置において、
前記注文指示提供手段によって注文指示をおこなう前記端末装置の利用者を識別する注文者識別手段、
注文者が該注文指示の別の注文者による差分注文を可能とするか否かを選択する差分注文制御手段、
を備えることを特徴とする印刷製本注文装置。
【請求項４】
請求項１から３における印刷製本注文装置において、
前記印刷製本注文指示は少なくとも1つ以上の原稿データおよび少なくとも1つ以上の印刷製本方法指示書から成り、
該原稿データと該印刷製本方法指示書はそれぞれ独立して前記注文指示提供手段および前記差分注文指示提供手段を用いる、
ことを特徴とする印刷製本注文装置。
【請求項５】
請求項３および請求項４における印刷製本注文装置において、
前記差分注文は異なる注文者からの原稿データを含む、
ことを特徴とする印刷製本注文装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、原稿の電子データと印刷方法を指示した指示書(ジョブチケット)をネットワークに接続されたサーバにアップロードし、それに従って印刷・製本を行うシステムおよびサービスに関するものである。
【背景技術】
【０００２】
電子注文のシステムにおいては一般に注文情報をサーバが保持していて、注文者がリピート発注をかけられるようになっている。
【０００３】
この場合、注文内容はどの商品をいくつ、といった単純な内容であるため、システムの構成としては、過去の注文情報を注文者に戻し注文者はそれを確認しつつ再注文をかけるという手順である。
【０００４】
この際、必要な注文情報が注文者の手元まで来るため、数などの修正も含め、新規の注文と同様の手順で再注文を行い、かつ、必要な情報を1から入力しなくても済むというメリットがある。
【０００５】
これは最初の注文者以外の注文者が同じ発注を行いたい場合も同様の手順が可能である。
【０００６】
仮に最初の注文者が自分以外の者に同じ内容で再注文をかけられたくない場合には、単純に注文情報を他人に公開しなければ良い。
【０００７】
発注の権利や見積額などがその発注者個人に属する場合にはこのようなアクセスコントロールが可能である。
【０００８】
また、クライアントが原稿ページデータと印刷製本指事をサーバへアップロードし、印刷製本業者において製本物を作成することを依頼するシステムが存在する。この際、両面指示等のレイアウト指示や製本指示のような印刷方法を指示する内容を印刷対象とは別の文書で保持し、印刷対象と対にしてサーバへ送信するということが行われている。この指示内容を含む文書を指示書、あるいはジョブチケット（JobTicket)と呼んでいる。ジョブチケットの使用により、複雑となる指示内容を保存しておき同じ印刷方法での印刷を容易に繰り返すことが可能となっている。また、同じ原稿データに対して違うジョブチケットを用いることにより異なる形態の出力が可能となる。
【０００９】
このようなシステムにおいて注文者は、単純に製本物を注文するというだけでなく、指定した原稿データをどのようにレイアウトまたは加工するか、あるいは製本の形態はどのようにするかを詳細かつ自由に選択・組み合わせて設定することが出来る。
【００１０】
このシステムにおいても前記同様、過去の依頼内容をリピート発注して追加の印刷製本を行うということが可能である。
【００１１】
この場合、一度アップロードした原稿ページデータをサーバに残しておき、別のジョブチケットにおいて以前の原稿データを再利用することにより、通信トラフィックの増加を防ぐ効果もある。
【特許文献１】特開２００３−０７６５２４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかし、通常の電子発注と異なり、前記のような印刷注文システムにおいては原稿データは各注文者が所有しているものであり、別の注文者が同じ原稿から成る製本物を要求する場合には、オリジナルの原稿を何らかの手段で入手しなければならない。
【００１３】
例えば、元の注文者から直接電子的なコピーを入手するか、あるいは、元の注文者が前回注文した際にアップロードした原稿データを製本出力後も保持しておき、別の注文者がそれにアクセスする、等の方法である。これでは、リピート発注のメリットである通信トラフィックの増加防止が損なわれることとなる。
【００１４】
また、アクセスコントロールの面でも不十分な点がある。通常の電子発注のように出力物の入手そのものの許可を制御したい場合には、元の発注者は全てのデータ、つまり、原稿データ、ジョブチケットに対してアクセスを禁止したい者に非公開とすればよい。しかし、前記のような印刷注文システムにおいては、原稿データ(電子データ)は非公開だが、印刷・製本された出力を入手することは他の注文者にも許可したい場合というものがある。その一方で、再注文を行いたいほかの注文者の立場として、最初の注文者と異なる製本形態で欲しい場合もある。例えば、より簡易なレイアウト、製本を行って安価な製本物を入手したい場合などである。
【００１５】
このような場合に、原稿データを所有している最初の注文者が原稿データを単純に非公開としてしまうと、再注文者はどのようなジョブチケットを指定すればよいかが分からないという問題点がある。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明に係る印刷製本注文システムにおいては、既にサーバへアップロードされている注文指示情報に対する、差分指示情報をアップロードすることで修正を含む再注文を可能とする。この際、サーバ側にある注文指示情報を全て注文者側へダウンロードしてくる必要は無い。そして、最初にサーバへ注文指示情報をアップロードした注文者はアップロードした注文指示情報を部分的に非公開に設定することが可能であることを特徴とする。
【発明の効果】
【００１７】
以上説明したように、本発明によれば、注文者がファイルをアップロードして印刷製本指示を行う注文システムにおいて、元の注文者による原稿データのアクセスコントロールが有効なまま、他の注文者でも再注文を行うことが出来るようなシステムが実現可能となった。さらに、再注文にあたって原稿データやジョブチケットをサーバへ全て再送信する必要が無いため、応答性の良いサーバを持つシステムとすることが出来るようになった。
【発明を実施するための最良の形態】
【００１８】
以下本発明の実施例を,図に沿って詳細に説明する。
(第一の実施例)
図１は本発明における実施例である印刷製本注文システムの全体構成を示すブロック図である。
【００１９】
図１において、１は注文および印刷を管理する印刷注文サーバ、２は印刷注文サーバ１が持つデータベース、３、４は注文を行う端末機を示すクライアント、５は印刷製本を行う印刷拠点、６は印刷機器、７は印刷注文サーバ１とクライアントをつなぐネットワーク、８は印刷注文サーバ１と印刷拠点５および印刷機器６をつなぐネットワークである。
【００２０】
印刷拠点５と印刷機器６はいずれも印刷注文サーバ１が受けた注文内容に従って印刷製本の出力を行うところであるが、印刷拠点５はプリントショップなどの一部人手あるいは別システムを介するような出力先、印刷機器６は印刷注文サーバ６から直接出力可能な出力先、を示すべく分けて図示した。ただし、本発明におけるシステム構成においては、印刷拠点と印刷機器に明確な区別は無いため、以後これらをまとめて印刷拠点と呼び、実際には印刷拠点と印刷機器の両方があり得るものとする。
【００２１】
印刷注文サーバ１はクライアント３あるいはクライアント４からの印刷、製本注文を受けてデータベース２へ注文内容を記録し、その注文内容に従った出力が得られるよう印刷拠点に対して指示を出す。
【００２２】
印刷注文サーバ(印刷サービス)の利用者は、ネットワーク７に接続されたクライアント３あるいはクライアント４を端末として利用し、所望のドキュメントファイル(電子データ)とその出力形態(印刷方法、製本方法)を示す指示を印刷注文サーバ１へ送ることにより、出力物を得ることが出来る。なお、利用者が印刷注文サーバ１への注文を行うにあたって、図１におけるクライアント３を端末としても、クライアント４を端末として使っても構わない。複数の利用者が異なる時間において同一の端末を利用することも可能である。しかし、以降の説明上の便宜のためクライアント３とクライアント４にはそれぞれ別の利用者が対応し、同じ利用者は決まった1つの端末を利用するものと考える。そして、クライアント３およびクライアント４によって同時にそれぞれの利用者も表すものとする。
【００２３】
次に本実施例における利用者の注文とその利用者が注文物を入手した後に別の利用者によって再注文が行われる処理の手順例を説明する。
【００２４】
図２は本発明における処理とデータ、物の流れを時系列で示すタイミングチャートである。
【００２５】
図２においては４つの登場人物がある。１００、１０１は注文を行うクライアントであり、それぞれ図１におけるクライアント４、クライアント３を表している。１０２はサーバであり、図１における印刷注文サーバ１に対応する。１０３は印刷拠点であり、図１における印刷拠点５あるいは印刷機器６に対応する。
【００２６】
図２における例ではクライアント３が注文した製本物をクライアント４が再注文する流れを示している。
【００２７】
まず、１０４においてクライアント３がサーバ１０２へログインする。これにより、サーバ１０２はこれからクライアント３がログアウトするまでの注文処理を行う利用者がクライアント３であることを識別、管理する。なお、サーバ１０２は公知の技術により実現されるユーザ認証手段を持ち、決済や出力物の配送のための手段が実現されているものとする。また、クライアント３および後述のクライアント４はサーバ１０２によって識別されるアクセス権を既に持っているものとする。
【００２８】
次にクライアント３はこれから印刷および製本を依頼する原稿データ(電子データ)をサーバ１０２へアップロードする（１０５）。アップロードされた原稿データは、クライアント３に関わる識別情報および印刷製本指示情報と関連付けられ、図１におけるデータベース２へ格納される。
【００２９】
サーバ１０２はデータベース２へ格納した原稿データを識別するためのファイルＩＤをクライアント３へ通知する（１０６）。
【００３０】
さらにクライアント３は１０６で通知されたファイルＩＤを元に、原稿データをどのように印刷、製本を行うかを指示する（１０７）。
サーバ１０２は１０５および１０７で指定された原稿データ、印刷指示に従って出力結果を視覚的に表すプレビュー画像を作成し、クライアント３へと示す（１０８）。
【００３１】
クライアント３はサーバ１０２が示すプレビューを確認し、目的の内容と一致することを確認できた場合には注文を確定する。利用者の意図通りでないと判断された場合には、１０５、１０７、１０８の手順が繰り返されるか、注文自体をキャンセルすることとなる。注文を確定する場合にはクライアント３はサーバ１０２へその通知を行う（１０９）。
【００３２】
注文確定を確定するとサーバ１０２は確定した注文毎に一意に割り振られる注文IDをクライアント３へ返す（１１０）。
【００３３】
クライアント３はサーバから１１０において通知されたIDを元に、その注文内容の再注文に関するアクセス権を設定する（１１１）。具体的には、IDに対応する注文内容を自分以外が再注文することを許可するか否か、許可する場合には印刷指示を修正して再注文することを許可するか否か、また特定の利用者だけに許可するか無制限に許可するか、という内容を設定する。図２における１１１ではクライアント４による再注文と別の印刷指示を行うことを許可、ただし、クライアント３がアップロードおよび指定した情報の内容はクライアント４へは非公開、プレビューのみ可能という設定をしたものとして以降の説明を続ける。
【００３４】
なお、サーバ１０２は１１１におけるアクセス権設定の内容に従って、図１におけるデータベース２に格納される原稿データおよび印刷指示情報が印刷拠点１０３における出力後も保管された状態に維持するか否かを決定する。特にアクセス権の設定が無い場合には、印刷拠点における出力後原稿データはデータベースから削除されるものとする。
【００３５】
クライアント３は注文終了後サーバ１０２に対してログアウトを指示（１１２）することでクライアント３の注文処理は終了する。
【００３６】
サーバ１０２はクライアント３からの注文を受け付けると、その内容に従って印刷・製本の出力を行う指示を印刷拠点１０３に対して出す（１１３）。
【００３７】
印刷拠点１０３では指示どおりの出力を行いクライアント３に出力物を配送する（１１４）。なお、本タイミングチャートでは注文料金に関する動きは省略してある。
【００３８】
ここまでがクライアント３の要求に対応する処理である。
【００３９】
ここで、クライアント３が入手した印刷物をクライアント４が見て、同じ内容のものが欲しくなった、あるいは複製を入手する必要が出てきた場合を想定する。
【００４０】
クライアント４は、１１４においてクライアント３が入手した印刷物に対応する注文ID（１１０においてクライアント３がサーバより通知を受けたもの）を教えてもらう（１１５）。このIDを元にクライアント４は次の手順から再注文を行う。
【００４１】
まず、１１６においてクライアント４はサーバへログインする。
【００４２】
そして、クライアント３より教えてもらったIDをサーバへ指定する（１１７）。
【００４３】
サーバは指定されたIDより対応する原稿データと印刷指示情報をデータベースより検索し、クライアント４がこの注文IDに該当する情報にアクセスする（再注文する）権利があることを確認する。図２における場合では１１１においてクライアント３がクライアント４でもアクセスできるように設定しているため、サーバはクライアント４に対して対応するプレビュー画像を作成、プレビュー表示を行う（１１８）。
【００４４】
クライアント４は１１８で表示されたプレビューを確認の後、例えば、より安価な印刷・製本体裁を選択するために、別の印刷指示を行う。ここで、クライアント４は原稿データやクライアント３によって行われた印刷指示を直接編集するのではなく、プレビューより判断した自分が修正印刷指示として出したい情報だけをサーバへ送る（１１９）。ここでは、各種詳細設定および原稿データはクライアント３のものと同じで、製本方法と使用用紙のみをより安価なものを選択したものとして説明を進める。
【００４５】
サーバは１１９でクライアント４から送られた印刷指示を差分情報として、クライアント３のそれにおける印刷指示に適用し、内部で新しい印刷指示を構成する。そして、新しく出来た印刷指示と原稿データから再度プレビュー画像を作成しなおし、クライアント４へ提示する（１２０）。
【００４６】
クライアント４はサーバが示すプレビューを確認し、目的の内容と一致することを確認できた場合には注文を確定する。利用者の意図通りでないと判断された場合には、１１９、１２０の手順が繰り返されるか、注文自体をキャンセルすることとなる。注文を確定する場合にはクライアント４はサーバへその通知を行う（１２１）。
【００４７】
注文確定を確定するとサーバは注文IDをクライアント４へ返す（１２２）。
【００４８】
クライアント４は注文終了後サーバに対してログアウトを指示（１２３）することでクライアント４の注文処理は終了する。
【００４９】
サーバはクライアント４からの注文を受け付けると、クライアント３における場合と同様に指示を印刷拠点１０３に対して出す（１２４）。
【００５０】
印刷拠点１０３では指示どおりの出力を行いクライアント４に出力物を配送する（１２５）。
【００５１】
ここまでがクライアント４の要求に対応する処理である。
【００５２】
これにより、クライアント４はクライアント３の印刷物と同様の内容でより安価な印刷物の注文を容易に行うことが出来た。印刷・製本指示の修正は差分情報のみが送られているため、クライアントとサーバ間の通信も軽く効率が良い。さらに、クライアント３は原稿データを公開せずに再注文を許可しているため、原稿データの不正コピーが出回ることを避けることが出来た。
【００５３】
次に本実施例における印刷指示情報の指定および差分情報の指定に関する詳細について説明する。
【００５４】
図３は、図２におけるクライアント３からサーバへ送られた印刷指示情報の内容を示すものである。クライアントからサーバへはジョブチケットと呼ばれるファイルを送信することで印刷指示が行われる。図３はそのジョブチケットファイルを示している。
【００５５】
本実施例におけるジョブチケットはSGMLやXMLなどに代表されるマークアップ言語を利用したテキストドキュメントの形式をとっている。ただし、本実施例の説明に必要な部分のみの表現を用いており、SGMLやXML等の仕様に厳密に従ったものではない。
【００５６】
図３に示すジョブチケットは９行から成り立っている。1行目の<JobTicket>はジョブチケットの記述の開始を意味する。これに対応する表現として、９行目の</JobTicket>はジョブチケットの記述の終了を意味する。２から８行目は具体的な指示を表すものである。
【００５７】
図３における２行目にはこの指示を行っている利用者の情報が記述されている。そして、同時に出力結果の配送先の指定としても解釈される。前述のユーザ認証手段によりログオンした利用者が登録している住所が特定され、印刷製本後の製品はここで指定された利用者のもとへ配送されることとなっている。この行で、Ｎａｍｅ属性の値で示されているのは利用者の氏名である。OwnerID属性値で示されている値はユーザ認証手段において登録されている利用者のＩＤである。
【００５８】
３行目には製本方法が記述されている。Type属性値の値で示されているのは製本方法の種類であり、図３においてはハードカバータイプの製本を指定している。
【００５９】
４行目には中で使用する用紙の種類指定が記述されている。PaperType属性の値で示されているのは紙の種類である。図３においては上質紙を示す"HighQuality"が指定されている。また、Size属性の値で示されているのは用紙の大きさであり、図３においてはＡ４サイズが指定されている。
【００６０】
５行目から８行目までは原稿のページデータをどのようにレイアウトするかが記述されている。５行目の<Layout>はレイアウト指示の記述の開始を意味する。これに対応する表現として、８行目の</Layout>はレイアウト指示の記述の終了を意味する。この中にはレイアウトに関して大きく二つの指示が記述されている。１つは６行目の表紙の印刷レイアウトについて、であり、もう１つは７行目の本身の印刷レイアウトについてである。
【００６１】
６行目には表紙の印刷指定が記述されている。Source属性の値で示されているID12345は表紙として印刷するページデータの原稿ファイルを示すＩＤである。ここには図２における１０６で通知されたファイルＩＤを用いる。また、page属性の値で示されているのは原稿ファイルの何ページ目を表紙の印刷に用いるかを指定しているページ番号である。つまり、６行目では図２において１０５でアップロードした原稿データの１ページ目を表紙として印刷する指定が記述されている。
【００６２】
７行目には本身の印刷指定が記述されている。Source属性の値で示されているID12345は前述同様ファイルＩＤである。startpageとendpageで示される属性値はそれぞれ原稿ファイルの何ページ目から何ページ目までを本身として印刷するのかを表し、これで印刷ページ範囲の指定となっている。つまり、７行目では図２において１０５でアップロードした原稿データの２ページ目から１５０ページ目までを本文として印刷する指定が記述されている。
【００６３】
以上が、図２における１０７でクライアント３からサーバへ送られた印刷指示の内容である。
【００６４】
なお、本ジョブチケットはクライアント３を操作する利用者が直接記述するものではなく、クライアント３を構成するユーザインタフェース、アプリケーションソフトウェアがユーザの指示内容をこの形式に書き出して、サーバへ送信されるものである。
【００６５】
図４は図３に示すジョブチケットをサーバへ送った結果表示されるプレビュー画面の一例である。本実施例においては特にユーザインタフェース画面等、プレビュー画像以外の部分については省略してある。
【００６６】
図４において、２００は図２における１０８に対応するプレビュー表示画面、２０１はプレビュー画像、２０２は利用者の表示、２０３は２０１に示すプレビュー画像の原稿データのファイル名である。
【００６７】
図４におけるプレビュー画像ではハードカバーの製本が行われる様子が示されている。なお、本実施例の説明においては不図示であるが、表紙および本身の印刷レイアウトの概略についても確認できるものである。
クライアント３はこの表示を確認して、図２における１０９の注文確定を行う。
【００６８】
続いてクライアント４の印刷指示について説明する。
【００６９】
図５はクライアント４がサーバへクライアント３から教えてもらったＩＤを通知した後に表示されるプレビュー画面の一例である。なお、本実施例においては、図２における１１０のＩＤ通知において「ID12345678」というＩＤが通知されたものとして説明を続ける。
【００７０】
図５において、２０５は図２における１１８に対応するプレビュー表示画面、２０６はプレビュー画像、２０７は利用者の表示、２０８は２０１に示すプレビュー画像に対応する注文ＩＤである。なお、２０８に示すＩＤは図２における１１７で指定されたＩＤである。
【００７１】
サーバは注文ＩＤが指定されると、指定されたIDより対応する原稿データと印刷指示情報をデータベースより検索し、クライアント４がこの注文IDに該当する情報にアクセスする（再注文する）権利があることを確認する。そして、図５に示すプレビュー画像を作成、プレビュー表示を行う。ここで表示されるプレビューはクライアント３が図２における１０８で確認したものと同じである。
【００７２】
ここで、クライアント４は２０６のプレビュー画像を確認し、より安価な印刷指示を指定することを決める。
【００７３】
図６はクライアント４による再指示の結果のプレビュー画面の一例である。
【００７４】
図６において、２１０は図２における１２０に対応するプレビュー表示画面、２１１はプレビュー画像、２１２は利用者の表示、２１３は再指示の元となる注文ＩＤである。
【００７５】
図６におけるプレビュー画像ではソフトカバーの製本が行われる様子が示されている。
【００７６】
クライアント４はこの表示を確認して図２における１２１の注文確定を行う。
【００７７】
図７は、図２におけるクライアント４からサーバへ送られた印刷指示情報の内容を示すものである。この場合、クライアントからサーバへはジョブチケットの修正部分のみの記述がなされたファイルが送られる。
【００７８】
図７に示すジョブチケットは５行から成り立っている。1行目の<JobTicket>は図３におけるそれと同様ジョブチケットの記述の開始を意味する。これに対応する表現として、５行目の</JobTicket>がある。また、１行目にはBase属性の値によって、修正元の注文ＩＤが指定されている。これにより、図７に示すジョブチケットが図３に示すジョブチケットに対する修正情報であることが判断できるものとする。
【００７９】
図７における２行目にはこの指示を行っている利用者の情報が記述されている。解釈の方法は図３のジョブチケットと同様である。
【００８０】
３行目には製本方法としてソフトカバータイプが指定されている。
【００８１】
４行目には用紙の種類として、再生紙を示す"NormalQuality"が指定されている。用紙サイズについては元となるクライアント３の注文に従うため、記述していない。
【００８２】
以上が、図２における１１９でクライアント４からサーバへ送られた印刷指示の内容である。この指示によって、図６に示されるようなプレビュー画像が表示される。
【００８３】
図７に示すジョブチケットの処理についてさらに詳しく説明する。
【００８４】
図８はサーバで処理されるクライアント４の注文に対応するジョブチケットを示したものである。クライアント４が指示した内容は図７に示すものであるが、それを受けたサーバ内では図７のジョブチケットが元にしている図３に示すジョブチケットと図７のジョブチケットを合成し、図８に示すようなジョブチケットを作り出す。
【００８５】
図８に示すジョブチケットはクライアント４には見えないため、クライアント３による注文内容へのアクセスコントロールは有効である。
【００８６】
図８において２、３、４行目の下線で示された部分が図７のジョブチケットによって図３のジョブチケットが修正された部分である。
【００８７】
図８のジョブチケットの内容に従って、印刷製本を行うことにより、クライアント４の望む印刷注文を行うことが出来る。
【００８８】
次にサーバがジョブチケットを処理する手順を説明する。
【００８９】
図９は本実施例における印刷注文サーバがクライアントからの印刷製本指示、つまりジョブチケットを解釈し、再注文を行えるようにする手順を示した流れ図である。
【００９０】
なお、本実施例の流れ図ではジョブチケットに従った実際のプレビュー作成や印刷、製本処理については省略してある。プレビュー画像作成や印刷製本処理については公知の技術により、ジョブチケットに記述された各指示が処理されるものとする。
【００９１】
まず、図９におけるステップＳ３００で処理が開始される。これは、サーバがクライアントからの印刷指示を受けた状態（図２における１０７あるいは１１９に相当）である。
【００９２】
ここで、クライアントより受け取ったジョブチケットを本流れ図においてはｄｊｔと表すものとする。ステップＳ３０１ではジョブチケットｄｊｔを読み込み、階層構造をもつジョブチケットの記述のトップレベルからを処理していく。
次のステップＳ３０２において、ｄｊｔがオリジナル印刷指示であるか、差分印刷指示であるかを判断する。具体的にはｄｊｔの記述にＢａｓｅ属性があるか否かを検査する。これは、例えば図７における１行目に記述されているBase="ID12345678"という部分が存在するか否か、のことである。
Ｂａｓｅ属性が存在しない場合（Ｎｏ．）はオリジナルの印刷指示であり、ステップＳ３０３へ進む。Ｂａｓｅ属性が存在する場合（Ｙｅｓ．）はそのＢａｓｅ属性の値が示す注文ＩＤに対応するジョブチケットをベースとする差分印刷指示であり、ステップＳ３０４へ進む。
【００９３】
ｄｊｔがオリジナル印刷指示である場合、ステップＳ３０３でサーバはｄｊｔのコピーを作成し、ｅｊｔとする。ｅｊｔは最後に実際に処理されるジョブチケットである。ｄｊｔのコピーによってｅｊｔを作成したら次にステップＳ３０７へ進む。
【００９４】
ｄｊｔが差分印刷指示である場合、ステップＳ３０４でＢａｓｅ属性値に記述されているＩＤからオリジナルのジョブチケットを取得する。このオリジナルジョブチケットはｄｊｔが示す差分が適用されるベースのジョブチケットとなる。
【００９５】
次にステップＳ３０５においてベースのジョブチケットを複製し、これをｅｊｔとする。
【００９６】
そして、ステップＳ３０６において、ｅｊｔに対してｄｊｔの内容に従った修正を行う。この際、ステップＳ３０６における一階層チェック処理はジョブチケットの階層構造の一階層のみを処理し、下位階層については自分自身を再帰的に呼び出すことによりｅｊｔの全ての階層の修正を行う。なお、<JobTicket>タグの階層についてはこの処理を行わず、次の階層から処理を行う。
【００９７】
この処理が終了するとｅｊｔはプレビュー画像作成や印刷製本処理に必要な状態となっている。
【００９８】
最後にステップＳ３０７においてｅｊｔを処理して、終了する（Ｓ３０８）。
【００９９】
続いて、図９におけるステップＳ３０６についてさらに詳しく説明する。
【０１００】
図１０は図９におけるステップＳ３０６の処理手順を示した流れ図である。
【０１０１】
まず、ステップＳ３１０において、指定された階層の処理が開始される。続いて順にその階層の各タグ（ＸＭＬ等の場合にはエレメント）を処理していく。
ステップＳ３１１では、ｄｊｔから未処理の次のタグを探している。まだ処理していないタグが存在する場合（Ｙｅｓ．）にはステップＳ３１２へ、全て処理が終わった場合（Ｎｏ．）にはステップＳ３２８へ進む。
【０１０２】
ステップＳ３１２では、処理するタグを読み込み、そのタグ名をｔとする(保存しておく)。
【０１０３】
ステップＳ３１３では、ｄｊｔを検査しているのと同じ階層で、ｅｊｔのなかでタグｔが存在するかを調べる。
【０１０４】
ステップＳ３１４ではタグｔの存在によって処理を分けている。ｔがある場合（Ｙｅｓ．）にはそのままステップＳ３１６へ進み、ｔがない場合（Ｎｏ．）にはステップＳ３１５へ進む。
【０１０５】
ステップＳ３１５では、ｄｊｔを検査しているのと同じ階層で、ｅｊｔにタグｔを追加する。そして、ステップＳ３１６へ進む。
【０１０６】
ここからは、タグｔに属する属性とサブのタグについて順に処理していく。
【０１０７】
ステップＳ３１６ではｄｊｔのタグｔに未処理の属性が存在するかを検査している。まだ処理していない属性が存在する場合（Ｙｅｓ．）にはステップＳ３１７へ、全て処理が終わった場合（Ｎｏ．）にはステップＳ３２２へ進む。
【０１０８】
ステップＳ３１７では、処理する属性名と属性値を読み込み、属性名はａｔｔ、属性値はａｔｖとして保存する。
【０１０９】
次のステップＳ３１８でｅｊｔのタグｔに属性ａｔｔがあるかを検査している。
【０１１０】
ステップＳ３１９では属性ａｔｔの存在によって処理を分けている。ａｔｔがある場合（Ｙｅｓ．）にはステップＳ３２０へ進み、ａｔｔがない場合（Ｎｏ．）にはステップＳ３２１へ進む。
【０１１１】
ａｔｔがある場合にはステップＳ３２０にてｅｊｔにおける属性値をａｔｖへ変更する。
【０１１２】
ａｔｔがない場合にはステップＳ３２１にて値をａｔｖとして、ｅｊｔに属性ａｔｔを追加する。
【０１１３】
いずれもｅｊｔへの修正が終わるとステップＳ３１６へ戻る。
【０１１４】
ステップＳ３１６でｄｊｔにおけるタグｔの全ての属性を処理したら、ステップＳ３２２へ進む。ステップＳ３２２ではｄｊｔのタグｔの階層で再帰的にステップＳ３１０からの処理を呼び出す。ｔの階層が終了するとステップＳ３１１へ戻る。
【０１１５】
全てのタグについて処理、つまりｄｊｔの内容に従ったｅｊｔの変更が終了したら、ステップＳ３２８でこの一階層チェックは終了する。
【０１１６】
以上説明した手順により、サーバは差分情報によってもオリジナルと同様にプレビュー作成、印刷製本処理を行うことが出来るジョブチケットを内部で構成することが可能となっている。
【０１１７】
以上の手順により、原稿データを依頼者がアップロードする方式の印刷注文システムにおいて、オリジナルの注文者以外からも再注文を行うことが出来るようになった。かつ、印刷製本指示の内容を再注文者が変更できるようにした場合であっても、オリジナルの原稿データが所有者の意図から外れて複製されないようにアクセスコントロールをすることが出来る。
【０１１８】
さらに、別の注文者が再注文する場合であっても改めて原稿データをアップロードする必要が無いため、クライアントとサーバ間での通信トラフィックを抑え、効率よく応答性の良いサービスが提供できるようになった。
【０１１９】
(第二の実施例)
第二の実施例については、第一の実施例との違いを説明する。
【０１２０】
図１１は本発明における第二の実施例におけるタイミングチャートを示しており、第一の実施例における図２と同じ部分については図示番号を同じにしてある。
【０１２１】
図１１において、１１８のプレビュー表示の後にクライアント４は新たにファイルをアップロードしている（１３０）。このファイルは、クライアント３とは別の表紙を使用することを目的に、新しい表紙用の原稿データをアップロードしているのである。
【０１２２】
サーバはこれに対して、新しいファイルＩＤをクライアント４へ通知する（１３１）。本実施例においては、ID99999というファイルＩＤが通知されたものとして説明を続ける。
【０１２３】
以降の手順は第一の実施例と同様であるが、クライアント４の差分印刷指示として、１３０でアップロードした原稿データを使用することが出来るようになる。
【０１２４】
図１２は第二の実施例におけるクライアント４がサーバへ送信した差分ジョブチケットである。
【０１２５】
これについても第一の実施例との違いのみ説明する。
【０１２６】
図１２においては、５行目から７行目までを除き、図７に示すジョブチケットと同様である。
【０１２７】
５行目から７行目までにおいて、表紙用にID99999というファイルＩＤを持つ原稿データの１ページ目を使用することを指示している。オリジナルの原稿データ（ID12345）はクライアント４にとって非公開であるが、ID99999はクライアント４がアップロードしたファイルであるため、使用に制限は無い。
【０１２８】
以上のように、純粋に指示だけではなく、一部の原稿データについても修正分の印刷指示を行えることで、より柔軟性のある再印刷指示が可能となった。この場合も、オリジナルの原稿データ（クライアント３が最初にアップロードしたもの）についてのアクセスコントロールは有効である。
【図面の簡単な説明】
【０１２９】
【図１】印刷注文システムの全体構成を示すブロック図。
【図２】第一の実施例におけるタイミングチャート。
【図３】第一の実施例におけるジョブチケットの一例。
【図４】第一の実施例におけるプレビュー画面の一例。
【図５】第一の実施例におけるプレビュー画面の一例。
【図６】第一の実施例におけるプレビュー画面の一例。
【図７】第一の実施例におけるジョブチケットの一例。
【図８】第一の実施例におけるジョブチケットの一例。
【図９】第一の実施例における流れ図。
【図１０】第一の実施例における流れ図。
【図１１】第二の実施例におけるタイミングチャート。
【図１２】第二の実施例におけるジョブチケットの一例。
【符号の説明】
【０１３０】
１  印刷注文サーバ
２  データベース
３  注文クライアント
４  注文クライアント
５  印刷拠点
６  印刷機器
７  ネットワーク(接続線)
８  ネットワーク(接続線)
【図１】
2005173800.tif 000003
【図２】
2005173800.tif 000004
【図３】
2005173800.tif 000005
【図４】
2005173800.tif 000006
【図５】
2005173800.tif 000007
【図６】
2005173800.tif 000008
【図７】
2005173800.tif 000009
【図８】
2005173800.tif 000010
【図９】
2005173800.tif 000011
【図１０】
2005173800.tif 000012
【図１１】
2005173800.tif 000013
【図１２】
2005173800.tif 000014