(57)【要約】【課題】  印刷製本を電子的に発注するサービスにおいて、内容を修正した再注文の見積もりを取り直さずに効率よく発注することを目的とする。【解決手段】  注文指示提供手段、印刷装置選択肢指定手段、印刷料金計算手段提供手段、印刷料金計算手段併合手段、印刷料金計算手段転送手段、印刷製本指示保持手段、印刷料金計算手段、及び印刷装置選択手段を備え、ジョブチケットに複数の印刷業者からの合い見積もり情報を料金体系として保持し、注文のクライアント側で料金の再計算を行うことにより、利用者は過去の注文に使用したジョブチケットを再利用して迅速かつ経済的な注文を行うことが可能となり、また、ショップ側では見積もり処理の効率化を実現することが可能となった。【選択図】      図１
2005092337.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信媒体上に接続された、少なくとも1つ以上の印刷製本注文管理装置および、少なくとも一つ以上の端末装置および少なくとも２つ以上の印刷装置を備えた印刷製本注文システムにおいて、
前記端末装置から前記印刷製本注文管理装置に対する印刷製本注文指示を提供する注文指示提供手段と、
前記端末装置から前記印刷製本注文管理装置に対して少なくとも２つ以上の前記印刷装置を選択する印刷装置選択肢指定手段と、
前記印刷装置から前記印刷製本注文管理装置に対して、前記印刷製本注文指示に対応する印刷料金計算手段を提供する印刷料金計算手段提供手段と、
前記印刷料金計算手段提供手段によって得られた複数の印刷料金計算手段をまとめる印刷料金計算手段併合手段と、
前記印刷料金計算手段併合手段によって得られた複数の印刷料金計算手段を、前記印刷製本注文管理装置から前記端末装置に対して転送する印刷料金計算手段転送手段と、
前記印刷料金計算手段転送手段で得られた複数の印刷料金計算手段を、前記印刷製本注文指示と合わせて保持する印刷製本指示保持手段と、
前記印刷製本指示保持手段に保持されている情報から印刷料金を計算する印刷料金計算手段と、
前記印刷製本指示保持手段に保持されている情報を基に、前記印刷装置を1つ選択する印刷装置選択手段とを備えることを特徴とする印刷製本注文システム。
【請求項２】
前記印刷装置選択手段が、前記印刷装置選択肢指定手段によって指定された複数の印刷装置の中で最も安価な料金であるものを選択することを特徴とする請求項１に記載の印刷製本注文システム。
【請求項３】
前記注文指示提供手段は、前記印刷装置選択手段によって選択された印刷装置を指定する指示を提供することを特徴とする請求項１または２に記載の印刷製本注文システム。
【請求項４】
前記印刷料金計算手段には計算結果の有効期限が存在し、当該印刷料金計算手段によって当該有効期限も取得可能であることを特徴とする請求項１〜３の何れか１項に記載の印刷製本注文システム。
【請求項５】
前記印刷装置は前記印刷料金計算手段によって計算された印刷料金の有効性を判断することを特徴とする請求項１〜４の何れか１項に記載の印刷製本注文システム。
【請求項６】
前記印刷製本注文管理装置は、当該印刷装置に対応する印刷料金計算手段以外の印刷料金計算手段を当該印刷装置へ提供しないように指示情報を加工することを特徴とする請求項３に記載の印刷製本注文システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、原稿の電子データと印刷注文内容を指示した指示書(ジョブチケット)をネットワークに接続されたサーバにアップロードし、それに従って印刷・製本を行うシステムおよびサービスに関するものである。
【背景技術】
【０００２】
電子注文のシステムにおいては一般に注文情報をサーバあるいは注文者(クライアント)が保持していて、注文者がリピート発注をかけられるようになっている。また、クライアントが原稿ページデータと印刷製本指示をサーバへアップロードし、印刷製本業者において製本物を作成することを依頼するシステムが存在する。
【０００３】
この際、両面指示等のレイアウト指示や製本指示のような印刷方法を指示する内容を印刷対象とは別の文書で保持し、印刷対象と対にしてサーバへ送信するということが行われている。この指示内容を含む文書を指示書、あるいはジョブチケット（JobTicket）と呼んでいる。
【０００４】
ジョブチケットの使用により、複雑となる指示内容を保存しておき、同じ印刷方法での印刷を容易に繰り返すことが可能となっている。また、同じ原稿データに対して違うジョブチケットを用いることにより、異なる形態の出力が可能となる。
【０００５】
このようなシステムにおいて注文者は、単純に製本物を注文するというだけでなく、指定した原稿データをどのようにレイアウトまたは加工するか、あるいは製本の形態はどのようにするかを詳細かつ自由に選択・組み合わせて設定することが出来る。
【０００６】
このシステムにおいても前記同様、過去の依頼内容をリピート発注して追加の印刷製本を行うということが可能である。
この場合、一度アップロードした原稿ページデータをサーバに残しておき、別のジョブチケットにおいて以前の原稿データを再利用することにより、通信トラフィックの増加を防ぐ効果もある。電子注文のシステムにおいては通信のトラフィック増加が非常に重要な課題である。
【０００７】
ところで、印刷注文サーバから利用可能な印刷製本業者（以後「ショップ」と呼ぶ）が複数存在し、かつショップ毎に料金が異なる場合には、ユーザが利用するショップを選択するか、自動的に適当なショップが選択されるような仕組みが必要である。
【０００８】
このような場合には、一般の（電子注文ではない）場合でも行われているように、複数のショップ間で見積もりを取り、その見積もり結果から利用するショップを決定するということも行われる。電子注文システムの場合には、印刷注文サーバがこの仲介を行うこととなる。
【０００９】
注文の見積もりが行われて、ジョブチケットを送り出すショップが決まった場合には、ジョブチケットには印刷製本指示情報のほかに、見積もり結果である料金の情報なども記述される場合がある。これにより、その注文指示が所定の見積もり結果に従ったものであることを示すことも可能となる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
見積もり、あるいはショップの選択に関わらない部分に関してはユーザがジョブチケットを保存しておき、再度同じ注文を行う際にジョブチケットに部分的な修正を加えることが可能である。
【００１１】
例えば、頻繁に改定が行われるドキュメントについては、原稿データの全てあるいは所定の部分を更新するだけで、製本方法の指示などはそのまま再注文を行うことが可能である。
【００１２】
しかし、見積もりをとってショップを決定した場合に、その料金などの情報がジョブチケットに含まれていても、印刷製本指示を修正してしまうと、それが無効となってしまうことが多い。それは、印刷注文の場合、料金が印刷製本指示の内容に従って決定するからである。
【００１３】
このような場合には、改めて見積もりをとりショップを決定、注文指示の発行を行うしかない。これでは、ジョブチケットを利用することで容易に再注文が可能となるという利点が半減してしまう。
【００１４】
再注文の際に自動的に同じショップへ見積もりを取るということも考えられるが、この場合には、毎回ショップへの通信が発生しトラフィックの増加となる。これもまた、ジョブチケットを利用する利点が損なわれている。
【００１５】
一方、ショップ側としても、毎回ユーザが見積もりと発注という手順を繰り返すと、その都度の料金計算など受注処理の効率が良くない。また、他のショップを利用されてしまう可能性も高くなり、集客の点からも問題がある。
【００１６】
本発明が解決しようとする課題は、上記のようにユーザ、ショップの双方に利益となるようにジョブチケットに見積もり、依頼ショップ決定情報を保持すると、再注文の際に簡易にショップを決定できないというものである。
【課題を解決するための手段】
【００１７】
上記目的を達成するために本発明は、所定の通信媒体上に接続された、少なくとも1つ以上の印刷製本注文管理装置および、少なくとも一つ以上の端末装置および少なくとも２つ以上の印刷装置を備えた印刷製本注文システムにおいて、前記端末装置から前記印刷製本注文管理装置に対する印刷製本注文指示を提供する注文指示提供手段と、前記端末装置から前記印刷製本注文管理装置に対して少なくとも２つ以上の前記印刷装置を選択する印刷装置選択肢指定手段と、前記印刷装置から前記印刷製本注文管理装置に対して前記印刷製本注文指示に対応する印刷料金計算手段を提供する印刷料金計算手段提供手段と、前記印刷料金計算手段提供手段によって得られた複数の印刷料金計算手段をまとめる印刷料金計算手段併合手段と、前記印刷料金計算手段併合手段によって得られた複数の印刷料金計算手段を前記印刷製本注文管理装置から前記端末装置に対して転送する印刷料金計算手段転送手段と、前記印刷料金計算手段転送手段で得られた複数の印刷料金計算手段を前記印刷製本注文指示を合わせて保持する印刷製本指示保持手段と、前記印刷製本指示保持手段に保持されている情報から印刷料金を計算する印刷料金計算手段と、前記印刷製本指示保持手段に保持されている情報を基に前記印刷装置を1つ選択する印刷装置選択手段とを備えることを特徴とする印刷製本注文システム、を提供する。
【発明の効果】
【００１８】
本発明によれば、前述した手順により、印刷注文サーバおよび印刷製本サービスの利用者は過去の注文に使用したジョブチケットを再利用して迅速かつ経済的な注文を行うことが可能となり、また、ショップ側では見積もり処理の効率化を実現することが可能となった。
【００１９】
本発明を単一のショップに対する見積もり処理に適用することも可能であるが、複数のショップに対する見積もりを取ることで本発明の効果を得ることが可能となる。複数のショップの合い見積もりをとり、かつ料金体系を見積もり情報としてジョブチケットに保持することにより、利用者がより条件の良い印刷業者を効率よく選択できるという効果が得られる。
【００２０】
なお、クライアントから印刷注文サーバへ注文を出す際のジョブチケットとして、ショップの見積もり情報を含む場合には、ショップ側で見積もり情報の内容を正確に確認することが出来るという利点があり、一方、見積もり情報を含まずに見積もりIDだけのジョブチケットを印刷注文サーバへ送信する場合には、システムの処理負荷を軽減することが出来るという利点がある。
【発明を実施するための最良の形態】
【００２１】
以下本発明の実施の形態を、図に沿って詳細に説明する.
(第一の実施の形態)
図１は本発明における実施の形態である印刷製本注文システムの全体構成を示すブロック図である。
【００２２】
図１において、１は注文および印刷を管理する印刷注文サーバ、２は印刷注文サーバ１が持つデータベース、３、４は注文を行う端末機を示すクライアント、５および６は印刷製本を行う印刷拠点、７は印刷注文サーバ１とクライアントとをつなぐネットワーク、８は印刷注文サーバ１と印刷拠点５および印刷拠点６をつなぐネットワークである。
【００２３】
印刷注文サーバ１はクライアント３あるいはクライアント４からの印刷、製本注文を受けてデータベース２へ注文内容を記録し、その注文内容に従った出力が得られるよう印刷拠点に対して指示を出す。
【００２４】
印刷注文サーバ(印刷サービス)の利用者は、ネットワーク７に接続されたクライアント３あるいはクライアント４を端末として利用し、所望のドキュメントファイル(電子データ)とその出力形態(印刷方法、製本方法)を示す指示を印刷注文サーバ１へ送ることにより、出力物を得ることが出来る。
【００２５】
なお、利用者が印刷注文サーバ１への注文を行うにあたって、図１におけるクライアント３を端末としても、クライアント４を端末として使っても構わない。
【００２６】
複数の利用者が異なる時間において同一の端末を利用することも可能である。しかし、以降の説明上の便宜のため、クライアント３とクライアント４にはそれぞれ別の利用者が対応し、同じ利用者は決まった1つの端末を利用するものと考える。そして、クライアント３およびクライアント４によって同時にそれぞれの利用者も表すものとする。
【００２７】
次に本実施の形態における利用者の注文処理の手順例を説明する。
図２は本発明における処理とデータ、物の流れを時系列で示すタイミングチャートである。
【００２８】
図２においては４つの登場人物がある。１００は注文を行うクライアントであり、それぞれ図１におけるクライアント３あるいはクライアント４を表している。１０１はサーバであり、図１における印刷注文サーバ１に対応する。１０２は、１０３は印刷拠点(ショップ)であり、図１における印刷拠点５および印刷拠点６に対応する。
【００２９】
図２における例ではクライアントがショップ１とショップ２に見積もりを取り、製本物を注文した後、注文内容を修正して、見積もりを再利用してショップ１あるいはショップ２に再注文する流れを示している。
【００３０】
まず、１０４においてクライアントがサーバ１０１へログインする。これにより、サーバ１０１はこれからクライアントがログアウトするまでの注文処理を行う利用者がクライアントであることを識別、管理する。
【００３１】
なお、サーバ１０１は公知の技術により実現されるユーザ認証手段を持ち、決済や出力物の配送のための手段が実現されているものとする。また、クライアントはサーバ１０１によって識別されるアクセス権を既に持っているものとする。
【００３２】
次にクライアントはサーバ１０１に対して利用可能なショップの一覧を要求する（１０５）。これに対してサーバ１０１はそのサーバから利用可能なショップの一覧をショップの各種情報とともにクライアントへ返す（１０６）。
【００３３】
クライアントはこの一覧を元に、注文を依頼する候補となるショップをいくつか選択する。選択の基準は、ショップの立地条件や、ブランドの有名、無名などクライアントの好みで決定されるものとする。
【００３４】
選択するショップの数は1つ以上いくつでも構わないが、選択する数が少なければよりよい条件を見つけられない可能性があり、数が多ければその後の処理に多くの時間が必要となる。本実施の形態においては、ショップ１（１０２）とショップ２（１０３）を選んだものとする。１０７では選択した二つのショップをサーバへ指定する。これは後に見積もり依頼を行う対象ショップのリストとして処理される。
【００３５】
続いて、クライアントは印刷対象のページデータをサーバへアップロードする（１０８）。さらに、所望の印刷製本方法を記述したジョブチケットをサーバへ送信する（１０９）。この時点でのジョブチケットには、ショップの指定は記述されておらず、印刷製本方法の指定のみが記述されている。
【００３６】
クライアントからショップリストと印刷製本指示を受け取ると、サーバは指定された各ショップへ指定された印刷製本指示に従った見積もり依頼を行う。１１０ではサーバからショップ１へ見積もり依頼を行っている。次の１１１ではサーバからショップ２へ見積もり依頼を行っている。
【００３７】
見積り依頼を受けた各ショップは夫々のショップの料金体系から見積もり結果を自動的に生成して返信する。１１２ではショップ１からサーバへ見積もり結果を返している。１１３ではショップ２からサーバへ見積もり結果を返している。
【００３８】
リストにある全てのショップから見積もり結果が返ると、サーバは見積もり結果の情報をジョブチケットに付加しクライアントへ返す（１１４）。
クライアントは返されたジョブチケットに記述された見積もり情報を元に依頼ショップを決定し、ジョブチケットに依頼ショップを指定して再びサーバへ送信する（１１５）。
【００３９】
なお、ここで送信したジョブチケットは後に再注文を行う際に必要となるため、クライアント側で保存しておく。なお、１１５においてクライアントはショップ１を選択したものとする。
【００４０】
クライアントは発注後サーバからログアウトし（１１６）注文処理を終了する。クライアントからの注文処理が終了すると、サーバは１１５で受信したジョブチケットに従ってショップ１へ印刷製本指示を送る（１１７）。
【００４１】
ショップ１では注文内容に従った印刷製本を行い、印刷後出力通知をサーバへ返す（１１８）と共に、製品をクライアントのもとへ発送する（１１９）。
ここまでが最初の見積もりおよび注文処理である。
【００４２】
続いて同図２における再注文の際の流れを説明する。
クライアントが最初の注文の後、ページ数を増やし再度同じ印刷製本指示にて注文を行った場合を示す。ジョブチケットの編集を行い、ジョブチケットの変更内容および前回行った見積もりの結果から適切な指定ショップが変更され、今度はショップ２を選択した。
【００４３】
クライアントは編集後の新しいジョブチケットを送信するべく、再びサーバにログインする（１２０）。そして、１２１でファイルをアップロードし、１２２でジョブチケットを送信する。１２３でサーバからログアウトするとクライアントの再注文処理は終了である。
【００４４】
サーバが１２４にてショップ２へ印刷指示を送ると、ショップ２はサーバへ出力通知を（１２５）、製品をクライアントのもとへ発送する（１２６）。
【００４５】
次に本実施の形態における印刷指示情報の指定に関する詳細について説明する。
図３は、図２における１０９でクライアントからサーバへ送られた印刷指示情報の内容を示すものである。
【００４６】
クライアントからサーバへはジョブチケットと呼ばれるファイルを送信することで印刷指示が行われる。図３はそのジョブチケットファイルを示している。
本実施の形態におけるジョブチケットはSGMLやXMLなどに代表されるマークアップ言語を利用したテキストドキュメントの形式をとっている。ただし、本実施の形態の説明に必要な部分のみの表現を用いており、SGMLやXML等の仕様に厳密に従ったものではない。
【００４７】
図３に示すジョブチケットは９行から成り立っている。1行目の<JobTicket>はジョブチケットの記述の開始を意味する。これに対応する表現として、９行目の</JobTicket>はジョブチケットの記述の終了を意味する。２から８行目は具体的な指示を表すものである。
【００４８】
図３における２行目にはこの指示を行っている利用者の情報が記述されている。そして、同時に出力結果の配送先の指定としても解釈される。前述のユーザ認証手段によりログオンした利用者が登録している住所が特定され、印刷製本後の製品はここで指定された利用者のもとへ配送されることとなっている。
【００４９】
この行で、Ｎａｍｅ属性の値で示されているのは利用者の氏名である。
OwnerID属性値で示されている値はユーザ認証手段において登録されている利用者のＩＤである。
【００５０】
３行目には製本方法が記述されている。Type属性値の値で示されているのは製本方法の種類であり、図３においては任意の製本方式を指定しており、依頼したショップの選択に任せることを示している。
【００５１】
４行目には中で使用する用紙の種類指定が記述されている。PaperType属性の値で示されているのは紙の種類である。図３においてはSize属性の値で用紙のサイズ（製本のサイズ）を指定しており、Ａ４サイズが指定されている。
【００５２】
５行目から８行目までは原稿のページデータをどのようにレイアウトするかが記述されている。５行目の<Layout>はレイアウト指示の記述の開始を意味する。
これに対応する表現として、８行目の</Layout>はレイアウト指示の記述の終了を意味する。
【００５３】
この中にはレイアウトに関して大きく二つの指示が記述されている。１つは６行目の表紙の印刷レイアウトについてであり、もう１つは７行目の本身の印刷レイアウトについてである。
【００５４】
６行目には表紙の印刷指定が記述されている。Source属性の値で示されているsource.pdfは表紙として印刷するページデータの原稿ファイルを示す。このファイルは図２における１０８でクライアントからサーバへアップロードされている。
【００５５】
また、page属性の値で示されているのは原稿ファイルの何ページ目を表紙の印刷に用いるかを指定しているページ番号である。つまり、６行目では図２において１０８でアップロードした原稿データの１ページ目を表紙として印刷する指定が記述されている。
【００５６】
７行目には本身の印刷指定が記述されている。Source属性の値で示されているsource.pdfは前述同様である。startpageとendpageで示される属性値は、それぞれ原稿ファイルの何ページ目から何ページ目までを本身として印刷するのかを表し、これで印刷ページ範囲の指定となっている。
【００５７】
つまり、７行目では図２において１０８でアップロードした原稿データの２ページ目から１５０ページ目までを本文として印刷する指定が記述されている。
以上が、図２における１０９でクライアントからサーバへ送られた印刷指示の内容である。
【００５８】
なお、本ジョブチケットはクライアントを操作する利用者が直接記述するものではなく、クライアントを構成するユーザインタフェース、アプリケーションソフトウェアがユーザの指示内容をこの形式に書き出して、サーバへ送信されるものである。
【００５９】
次に本実施の形態でクライアントが選択した二つのショップにおいて、前記ジョブチケット記載の指示に対応した料金体系の差異について概略説明する。
図４は、図２の１０７においてクライアントが見積もりを取ることを選択したショップ１およびショップ２における料金体系をグラフで表したものである。
【００６０】
このグラフは図３に示すジョブチケットの内容に基づき、任意の製本方法、A4サイズという条件で、横軸に製本に使用する用紙の枚数、縦軸にその結果の製品の価格をとったものである。
【００６１】
ショップ１では表紙の部分などページ数に関わらない部分で５００円のコストがかかる。そして、本文の枚数に応じて1枚２０円のコストがかかる。
一方、ショップ２では表紙の部分などページ数に関わらない部分で１０００円のコストがかかる。そして、本文の枚数に応じて1枚１５円のコストがかかる。
【００６２】
以上のことから、図４のグラフに示されるような形となる。図から分かるように、本文が１００枚（つまり200ページ）まではショップ１のほうが安く、１００枚で同じとなり、それより枚数が増えるとショップ２のほうが安くなる。
この事実がわかるのはサーバから見積もり情報の入ったジョブチケットが返されたときである。
【００６３】
次にサーバがショップから見積もり情報を受け取って、クライアントへ見積もり情報の含まれたジョブチケットを返す際のジョブチケットについて説明する。
図５は、図２の１１２および１１３でショップ１およびショップ２から返された見積もり情報を含め、サーバがクライアントへ戻したジョブチケットを示している。
【００６４】
図５に示すジョブチケットは３１行から成り立っている。図５のジョブチケットの内容は、図３に示すジョブチケットにサーバが見積もり情報を付加したものであり、付加された見積もり情報以外は図３に示すものと同じである。
【００６５】
図５において９行目から１９行目までがショップ１の見積もり情報である。そして、２０行目から３０行目までがショップ２の見積もり情報である。見積もり情報は図２の１０９でクライアントが送信したジョブチケットを元にして、各ショップにおける料金体系を記述した内容となっている。
【００６６】
まず、ショップ１の内容から詳しく説明をしていく。
９行目の<Quoteから始まる行はショップ１の見積もり情報記述の開始を意味する。これに対応する表現として、１９行目の</Quote>が1つの見積もり情報、ここではショップ１の見積もり情報の記述の終了を意味する。
【００６７】
１０行目から１８行目は具体的な見積もり内容を表すものである。９行目において、Shop属性の値で示されているものはショップ１の名前である。ShopID属性はサーバが管理するところの印刷拠点の識別子である。
【００６８】
ショップ１の値は"shopid00001"となっている。QuoteID属性はショップ１におけるこの見積もりを識別するための識別子である。この識別子は各ショップ毎に別管理となっている。
【００６９】
見積もり情報は大きく、変更可能項目、計算式定義、料金体系、納期、見積もり有効期限の５つに分けることが出来る。
変更可能項目は、ジョブチケット中で見積もり情報として有効な内容を維持しつつ、編集可能な項目を定義するものである。これは、それぞれの記述がジョブチケット中で変数として扱える属性を表している。
【００７０】
料金体系を表現する際に利用する値については、ローカル変数名への割り当ても定義する。１０行目から１４行目まではそれぞれ変更可能項目の定義を記述している。
【００７１】
１０行目を例にさらに詳しく説明する。
Paramというエレメントの行は変更可能項目の定義を表す。この行はpathという属性、およびオプションとしてvarという属性を持つ。
pathに記述されている値はジョブチケット中で編集可能な属性を記述する。
【００７２】
属性の表現記法は、ジョブチケットのルートノードから対象属性までのエレメント名を'/'(スラッシュ)をデリミタとして連結し、最後に属性名の前に'@'記号をつけたものとなる。１０行目の場合には、ルートノードからJobTicketエレメントの下のLayoutエレメントの下のBodyエレメントのstartpage属性が編集可能であることを表す。
【００７３】
varに記述されている値はその見積もり情報内でローカル変数として利用される名前を定義するとともに、対応するpath属性値をその変数に割り当てる。１０行目の場合には、spageという名前の変数はジョブチケット中のルートノードからJobTicketエレメントの下のLayoutエレメントの下のBodyエレメントのstartpage属性値を表す。この変数の割り当てはショップ１の"qid12345"で特定できる見積もり情報において有効である。
【００７４】
同様にして１１行目における記述は、ジョブチケットのルートノードからJobTicketエレメントの下のLayoutエレメントの下のBodyエレメントのendpage属性が編集可能であることを表し、その値がepageという変数名で参照できることを示している。
【００７５】
編集可能であることのみを表し料金体系の記述の中で使用しない、つまり、何を設定しても金額に影響を与えない属性の場合にはvar属性を省略しても良い。
例えば、１２行目ではジョブチケットのルートノードからJobTicketエレメントの下のLayoutエレメントの下のCoverPageエレメントのSource属性が編集可能であることを表している。
【００７６】
つまり、注文の際、原稿ページデータとして別のファイルを設定しても良いということであり、かつ、その変更については料金に影響を与えないことを示す見積もり結果となっている。
【００７７】
同様に詳細は省略するが、表紙に指定するページ指定、本身の印刷に使用する原稿データも変更可能であることが、１３、１４行目に記述されている。
計算式定義は見積もりを料金体系として記述する便宜上、ある式で表された値をローカル変数に割り当て、別の記述で利用できるようにするものである。１５行目は計算式定義の記述である。
【００７８】
１５行目を例に計算式定義について詳しく説明する。
Defというエレメントの行は計算式定義を表す。この行はexpおよびvarという属性を持つ。expに記述されている内容は計算式を表し、varに記述されている値は、その計算結果の値を対応させるローカル変数名を定義する。
【００７９】
本実施の形態において、exp属性値で表現できる式は、変数、数値、四則演算、括弧および一部の組み込み関数から成る一般的な数式であるものとする。利用できる変数は、見積もり情報内で変更可能項目定義あるいは計算式定義によって定義された変数のみであるとし、帰納的な定義は許されないものとする。
【００８０】
１５行目の記述においては、sheetという変数に本文開始ページから終了ページまでに必要な用紙枚数を設定する式を表している。roundは本実施の形態における組込み関数であり数値の整数への切り上げを表している。
【００８１】
料金体系はそのショップにおける見積もり結果を表したものであり、金額が固定され一度だけ有効な見積もり結果ではなく、ページデータなど諸条件が変わった場合でも有効な料金算出式を表す情報である。
【００８２】
もちろん、注文条件に関わらず固定料金ということもあり得るので、その場合に記述される定数も含め料金算出式であるとする。
【００８３】
１６行目は料金体系の記述である。Costというエレメントの行は料金体系を表す。この行はexpおよびunitという属性を持つ。expの表現方法は計算式定義と同じである。
【００８４】
ただし、計算結果が変数に対応するのではなく、そのまま見積もり結果となる。unit属性値は料金の単位を表す。１６行目の記述において、単位はJPY（円）であり、基本料金５００（円）に加え本文1枚あたり２０（円）の加算となることを表している。
【００８５】
図５における７行目、１０行目、１１行目、１５行目、１６行目の記述より、ショップ１における現ジョブチケットに対応する料金は２０００円であることが決まる。
【００８６】
納期はそのショップに対して当該ジョブチケットで注文を行った場合に、納品までにかかる日数を表している。Dueというエレメントの行は納期を表しており、１７行目は納期を表している。period属性値が日数の値を示しており、１７行目においては４日で納品できることを表している。
【００８７】
見積もり有効期限はジョブチケットに記述された内容（料金の算出式、納期、等）が有効である日時を表しており、この期日までならば同じジョブチケットを用いて再注文を行うことが出来ることを意味する。
【００８８】
Validというエレメントの行は見積もり有効期限を表しており、１８行目は見積もり有効期限を表している。date属性値が期日を示しており、１８行目においては２００３年の１月３１日まで有効であることを表している。以上が見積もり情報の記述書式およびショップ１における見積もり内容である。
【００８９】
次にショップ２の見積もり内容についても説明する。
ショップ２については、基本的にショップ１と同様の見積もり体系と成っているため、ショップ１との差異について説明する。
【００９０】
なお、本実施の形態においてはショップ１とショップ２で似たような料金体系をとっているが、実際には前述した表記方法に従った任意の料金体系を各ショップは設定、返信することが可能である。
【００９１】
料金体系について、ショップ１では５００円ベースの２０円／枚のとなっていたが、図４でも説明している通り、ショップ２では１０００円ベースの１５円／枚となっている。また、納期については7日、見積もりの有効期限は２００２年の１２月３１日である。
【００９２】
図５における７行目、２１行目、２２行目、２６行目、２７行目の記述よりショップ２における現ジョブチケットに対応する料金は２１２５円であることが決まる。
【００９３】
図２の１１４において、上記のようなジョブチケットをサーバから受け取ったクライアントソフトウェアは、図５のジョブチケットにおいてはショップ１のほうが条件の良い(料金が安い)ことを自動的に判断し、正式に注文を依頼するジョブチケットに編集する。
このジョブチケットが図２の１１５においてクライアントからサーバへ送られる。
【００９４】
次に正式注文のジョブチケットについて説明する。
図６は図５のジョブチケットの内容からクライアントソフトウェアが自動的に判断し、編集した結果のジョブチケットを示したものである。
図６と図５の差異について説明する。
図６のジョブチケットでは、図５のジョブチケットに対して9行目の記述が追加されている。それ以外は図５と同じである。
【００９５】
９行目は実際に印刷製本の依頼を行うショップを指定している。この際、所定の見積もりIDを指定することで、その見積もりでの発注を指定している。
Orderエレメントの行は発注とショップの指定を行っている。
【００９６】
ShopID属性値は指定するショップのIDを示す。この値は見積もり情報のQuoteエレメントにおけるShopID属性値と同じものを指定する。また、QuoteIDはそのショップが提示した見積もりの識別子を示し、QuoteエレメントにおけるQuoteID属性値と同じものを指定する。
【００９７】
図６においては、ショップ１を指定し、ShopIDとしては"shopid00001"、見積もり識別子としては"qid12345"を指定している。
このジョブチケットをサーバへ送信することにより、サーバからショップ１へ印刷製本指示が出され、ショップ１とショップ２のうちのより安いほうで所望の製本物を入手することが出来る。
【００９８】
次に、既に見積もり情報をもっているジョブチケットを利用して再注文を行う場合のジョブチケットの編集について説明する。
全く同一の内容で再注文を行う場合には、図６に示すジョブチケットをクライアント側で保存しておき、それをサーバへ再送するだけでよい。原稿データ等を修正して再注文を行う場合には、本実施の形態における手順に従うと、改めて見積もりを取る手続きが不要となる。
【００９９】
図７は、図２の１２１における再注文のジョブチケット送信に対応するジョブチケットを示したものである。
図７において図６との差異のみを説明する。
【０１００】
図２の１１９以降の注文で、クライアントは別の原稿データを印刷製本するために原稿データとジョブチケットをサーバへ送信する。しかし、原稿データと印刷ページ数が異なる以外、前回の印刷製本指示内容と異なる部分が無いため、見積もりを取り直す必要は無い。
見積もりを取り直さずに注文できる指示内容変更の項目はクライアントソフトウェアによってジョブチケットから自動的に判断される。
【０１０１】
図７では、図６と６行目、７行目、９行目のみが異なっている。
６行目、７行目では別の原稿データを利用するために、Source属性値を"another.pdf"へ変更している。この属性値を変更しての再注文について、ショップ１については１３行目、１５行目、ショップ２については２４行目、２６行目から、見積もりが有効であることが分かる。
【０１０２】
もしも、いずれかあるいは両方のショップの見積もり情報の変更可能項目に該当しない場合には、見積もり情報が無効となるため、見積もりを取り直すか、料金不明のまま注文依頼を行うことになってしまう。
同様に、７行目では印刷のページ範囲が１ページ目から２５０ページ目までと変更になっている。この属性値が変更可能であることは１１、１２、２２、２３行目から判断できる。
【０１０３】
以上のような指示変更を行った結果、ショップ１、ショップ２の料金には変化が生じる。つまり、図７のジョブチケットに従えば、ショップ１では３０００円となり、ショップ２では２８７５円となる。
【０１０４】
クライアントソフトウェアはこの変化をジョブチケットに記述されている料金体系より自動的に読み取り、依頼先をより安価にできるショップ２へ変更する。その結果、図７の９行目のような内容となる。
【０１０５】
なお、９行目の修正はクライアントソフトウェアにより自動的に行われる。
なお、クライアントソフトウェアにおけるジョブチケットおよび見積もり情報の判断、編集についての詳細は後述する。
【０１０６】
先にショップ側の処理について詳細に説明する。
図８は、図１における印刷拠点（５あるいは６）の内部構造を示すブロック構成図である。図８において１０は印刷拠点を示し、図１と同じく１は印刷注文サーバ、８はネットワークを示す。さらに、図８において、１１はショップ内サーバ、１２および１３は印刷機器、１４は注文情報や見積もり情報を保持するデータベース、１５はショップサーバと印刷機器をつなぐネットワークである。
【０１０７】
図８におけるショップサーバ１１は印刷注文サーバ１からの見積もり依頼や、印刷注文指示に対する処理を自動で行うものである。ショップサーバ１１はデータベース１４において見積もりや注文の情報管理を行い、印刷機器１２あるいは１３によって印刷製本処理を行う。
【０１０８】
次に、ショップサーバにおける見積もり返信処理と受注処理について、情報の検索管理方法と送受信データの内容について説明する。
【０１０９】
＜ショップ：見積もり返信処理＞
図２に示すサーバからショップへの見積もり依頼と見積もり返信において、ショップの見積もり返信処理は人手によるものではなく見積もり依頼のジョブチケットの内容に応じた自動処理となっている。
【０１１０】
図９は本実施の形態において、ジョブチケットに記述された印刷製本指示から、対応する見積もり情報である料金体系を返すためにショップの内部システムで使用されるデータ構造を概念的に表した図である。実際には図９に示す情報は図８におけるデータベース１４に記録されているものである。
【０１１１】
印刷製本指示内容と対応する料金体系は表の形で予め設定され保存されている。図９において、２００は製本方式を示す列、２０１は用紙サイズを示す列である。
【０１１２】
２００、２０１は、ジョブチケットに記述された印刷製本指示に対応する情報を示す列であり、各列は前述したジョブチケット内の見積もり情報において変更可能項目のpath属性値に使用されているものと同じ表記法を使用し、ジョブチケット内の属性を指す。
【０１１３】
２０２は料金体系を示す列である。２００、２０１、２０２の列の組み合わせ、つまり1つの行は製本方式と用紙サイズの組み合わせから料金体系へと対応付ける。
図９において例えば、製本方式が任意（２０３）で、用紙サイズがA4（２０４）の組み合わせの場合には２０５に示す料金体系が対応することを表している。
【０１１４】
１つの料金体系はジョブチケットと同じマークアップ言語で記述されており、いくつかの情報が付加された後そのまま見積もりの返信として返せる書式となっている。２０２の列の各値は料金体系情報、すなわち２０５に示すような情報へのポインタ値を保持しているものとする。
【０１１５】
本実施の形態、特に図９に示すデータ構造においては、製本方式と用紙サイズを料金体系選択のキーとしているが、このキーの種類つまり列の数と種類はこれに限らず任意に選択できる。また、この情報はショップ毎に夫々の組み合わせが存在するものである。
【０１１６】
各ショップはサーバより見積もり依頼を受けると、ジョブチケットの内容より図９に示す料金体系選択のキーを調べ、ジョブチケットに対応する料金体系を取得する。そして、取得した料金体系に見積もりIDや見積もり有効期限などの情報を付加して、見積もり情報をサーバへ返す。
【０１１７】
なお、ここで付加した見積もりIDと返信した料金体系はショップ内のデータベースに保存しておく。
図１０は、図９における２０５に対応する料金体系情報の内容を、図２におけるショップ１を例に示す具体例である。図１０に示す料金体系情報は、図５に示すジョブチケットの９行目から１９行目に示す部分と同じ内容となっている。
ただし、図５における１８行目および９行目における属性値は後に付加されるものであるため、図１０に示す内容には含まれていない。
【０１１８】
図１０に示す情報は図２における１１２で返される際には見積もりID、ショップID、見積もり有効期限が付加され図１１に示すような内容に編集される。
図１２は、上記見積もりIDの管理についてショップの内部システムで使用されるデータ構造を概念的に表した図である。
【０１１９】
図１２に示すデータ構造は図９に示すデータ構造と連携しているため、図中で図９と同一のデータについて図９と同じ番号を付している。実装上、図１２に示す情報は、図９と同じく図８におけるデータベース１４に記録されているものである。
【０１２０】
見積もり返信の際に見積もりIDが決定されると、図８におけるデータベース１４へ登録される。図１２において、２１１はデータベース内の見積もりIDテーブルである。見積もりIDテーブルは、見積もりIDに対応する料金体系情報へのポインタ（２０６）、見積もりID（２０７）、見積もりIDに対応する有効期限（２０８）の列を持ち、1つの行で見積もり情報を表している。
【０１２１】
図１２においては、"qid12345"という見積もりIDに２０５の料金体系情報が対応していること、また、この見積もり情報の有効期限が2003年1月31日であることを示している。
【０１２２】
＜ショップ：受注処理＞
図２におけるサーバからの印刷指示（１１７あるいは１２４）に対するショップサーバの処理について説明する。
図１３は、図２の１１７においてサーバからショップ１へ印刷指示がなされた時に送られるジョブチケットを示している。
【０１２３】
印刷注文サーバは、クライアントから受け取った注文ジョブチケットを編集して、指定ショップ以外の見積もり情報を削除したジョブチケットを作成し、指定ショップのショップサーバへ送信する。図１３に示すジョブチケットはショップ２の見積もり情報が削除されている。
【０１２４】
図１３のジョブチケットを受け取ったショップサーバは、ジョブチケットの内容を解析する。図１４は本実施の形態においてショップ１のショップサーバが受注処理をする際の処理の手順を示したフローチャートである。
【０１２５】
まず、ステップS３０１にてショップIDを確認する。ステップS３０２にて自分宛の注文であるかを調べ、自分宛てである場合にはステップS３０３へ、そうでない場合にはステップS３１０へ進む。
【０１２６】
次にステップS３０３にて、見積もりIDを確認する。そして、ステップS３０４で図１２のテーブル２１１から該当する見積もりIDで見積もり情報を検索し、ステップS３０５で受け取ったジョブチケットに記載されている見積もり情報と比較する。
【０１２７】
ステップS３０６でジョブチケットと見積もりIDに対応する見積もり情報が一致するかを判断し、一致した場合にはステップS３０７へ、一致しなかった場合にはステップS３１０へ進む。
【０１２８】
さらにステップS３０７では見積もり有効期限を確認し、ステップS３０８で有効期限内であるかを判断する。有効期限内であればステップS３０９へ進み、ジョブチケットの指示内容に従って、図８に示す印刷機器１２あるいは１３等を使用して印刷製本処理を行う。
見積もり有効期限切れであった場合にはステップS３１０へ進み、印刷注文サーバへエラーを返す。
【０１２９】
最後にクライアントソフトウェアによるジョブチケットおよびジョブチケットに含まれる見積もり情報の解析、編集について詳しく説明する。
図１５は、本実施の形態におけるクライアントソフトウェアのユーザインタフェース画面の一例である。
【０１３０】
図１５において、４００は印刷製本指示をユーザが設定する設定画面、４０１は設定画面の中の製本方式を設定するフィールド、４０２は用紙サイズ（製本サイズ）を設定するフィールド、４０３は表紙に使用する原稿データのファイル名を設定するフィールド、４０４は表紙に使用するページを指定するフィールド、４０５は本身に使用する原稿データのファイル名を設定するフィールド、４０６は本身に使用するページ（の範囲）を設定するフィールド、である。
【０１３１】
図１５に示されている各フィールドには図５のジョブチケットの内容と対応する値が表されている。ここで、図５に示すジョブチケットとの対応を例に本実施の形態におけるユーザインタフェース画面について説明する。
【０１３２】
入力フィールド４０１は、図５における３行目のType属性値に対応する。図１５においては「任意」と表現されているが、これはType属性値の"Any"に対応する。クライアントソフトウェアはフィールド４０１に「任意」が入力されるとジョブチケットのBindingエレメントのType属性を"Any"に設定する。
【０１３３】
同様にして、入力フィールド４０２は４行目のSize属性値に対応する。Size属性値はフィールド４０２に入力された値がそのまま設定されるものとする。
【０１３４】
入力フィールド４０３は６行目のSource属性値に対応する。
入力フィールド４０４は６行目のpage属性値に対応する。
入力フィールド４０５は７行目のSource属性値に対応する。
入力フィールド４０６は７行目のstartpage属性値とendpage属性値とに対応する。
【０１３５】
以上のように、クライアントソフトウェアは、図１５に示すユーザインタフェース画面から利用者が設定した内容に従って、ジョブチケットの所定の部分を設定する。
なお、上記では図５に示すジョブチケットに対応しての説明であったが、内部で編集中のジョブチケットが、図３、図６あるいは図７の示すものであったとしても、クライアントソフトウェアのユーザインタフェースと処理内容とは上記と同様である。
【０１３６】
図１６は本実施の形態におけるクライアントソフトウェアのユーザインタフェース画面で、利用者によってあるフィールドが編集される際の処理手順を示すフローチャートである。
【０１３７】
図１６において、ステップS３２０でフィールドの編集が行われるとすると、まず、ステップS３２１において対応する編集中のジョブチケットにショップの見積もり情報が含まれているか否かが判断される。これはジョブチケット中にQuoteエレメントで始まるデータが存在するか否かで判断する。
【０１３８】
見積もり情報が存在しなければ（No）、ステップS３２７へ進み、編集されたフィールドに対応してジョブチケットを編集する。見積もり情報が存在する場合には、次のステップS３２２へ進む。
【０１３９】
ステップS３２２からは、順に全てのショップについて見積もり情報を解析する。まずステップS３２２にて1つのショップの見積もり情報を解析する。この結果から、ステップS３２３では編集されたフィールドに対応するジョブチケットの属性値が変更可能項目であるか否かを判断する。これは、フィールドに対応する属性がParamエレメントの記述によって、変更可能項目として定義されているかで判断する。
【０１４０】
Paramエレメントで変更可能項目と指定定義されていない場合（No）には、ステップS３２８へ進む。ステップS３２８では、フィールドの変更を不可として、ユーザインタフェース上のフィールドに表示されている値を元の状態に戻す。
【０１４１】
更可能項目である場合（Yes）には、ステップS３２４へ進む。
ステップS３２４では、現在解析中の見積もり情報の有効期限が切れていないかを判断する。期限切れの場合（No）にはステップS３２８へ進む。期限内の場合（Yes）にはステップS３２６へ進む。
【０１４２】
ステップS３２６では、未解析の他ショップの見積もり情報があるかを判断する。ある場合（Yes）にはステップS３２２へ戻り、そのショップの見積もり情報について、同様の判断を繰り返す。全てのショップの見積もり情報について解析済みの場合（No）にはステップS３２７へ進み、編集されたフィールドに対応してジョブチケットを編集する。
【０１４３】
以上の処理手順により、ジョブチケットに対して適切な変更を自動的に加えることが可能となる。
次に、クライアントソフトウェアが、ジョブチケットに含まれる見積もり情報と設定されている印刷製本指示とから、ショップ選択と注文指示とを行う手順について説明する。
【０１４４】
図１７はジョブチケットの注文指示を適切に設定、編集する手順を示すフローチャートであり、図２における１１４から１１５の間の処理、あるいは、１２２の処理の前に、クライアントソフトウェア内で自動的に行われる処理に対応する。
【０１４５】
ステップS３４０で処理を開始すると、ステップS３４１では、まずジョブチケット内に見積もり情報があるかを判断する。これは図１６で前述した処理と同様にQuoteエレメントの情報が含まれているか否かを判断する。
【０１４６】
そして、見積もり情報が含まれていない場合（No）にはステップS３４６へ進み終了する。見積もり情報が無い場合には判断するための情報が無いため、ジョブチケットは編集しない。見積もり情報が含まれている場合（Yes）にはステップS３４２へ進む。
【０１４７】
ステップS３４２からは順に全てのショップについて見積もり情報を解析し、各ショップにおける料金を計算する。ステップS３４２では１つのショップの料金を計算する。計算にあたってはCostエレメントのexp属性値で定義されている計算式を用いる。
【０１４８】
この計算に必要な変数については、Paramエレメントの記述、および、Defエレメントの記述から決定する。なお、これらの式を計算する手順については、一般的なプログラム言語の解析処理として公知であるため、本実施の形態において詳細は省略する。
【０１４９】
ステップS３４３では未解析の他ショップの見積もり情報があるかを判断する。ある場合（Yes）にはステップS３４２へ戻り、そのショップの料金計算について同様の処理を繰り返す。全てのショップの料金計算を終えた場合（No）にはステップS３４４へ進み、計算した料金の中で最も安い料金のショップを選択する。
【０１５０】
次にステップS３４５において、ステップS３４４で選択したショップに対して印刷注文を送るために、ジョブチケットのOrderエレメントの行を編集、設定する。
【０１５１】
このとき、既にOrderエレメントが存在する場合には、一度、属性値をリセットした後、再度設定しなおす。Orderエレメントが存在しない場合には、ジョブチケットにその行を追加する。ここで設定する属性値は、指定するショップの見積もり情報のShopIDとQuoteIDである。
【０１５２】
以上説明した手順により、印刷注文サーバおよび印刷製本サービスの利用者は、過去の注文に使用したジョブチケットを再利用して、迅速かつ経済的な注文を行うことが可能となり、また、ショップ側では見積もり処理の効率化を実現することが可能となった。
【０１５３】
さらに、再注文にあたっては、見積もりを取り直さずに編集後の印刷製本注文に対応する料金を知ることが出来るため、クライアントとサーバ間での通信トラフィックを抑え、効率よく応答性の良いサービスが提供できるようになった。
【０１５４】
なお、本実施の形態においては、印刷拠点としてショップ１とショップ２の二つを挙げたが、実際には選択肢となるショップの数も、実際に選択するショップの数も、任意の数で可能である。
【０１５５】
(第二の実施の形態)
第二の実施の形態については、第一の実施の形態との違いを説明する。
図１８は本発明の第二の実施の形態におけるジョブチケットの例である。
図１８に示すジョブチケットは、第一の実施の形態における図２において、１１５あるいは１２２におけるジョブチケット送信で送られるジョブチケットを示しており、図６のジョブチケットに対応するものである。
【０１５６】
第一の実施の形態おいては、クライアントから印刷注文サーバへ送る注文指示ジョブチケットは見積もり情報を含んでいた。このため、サーバ側でショップへ送る際に、他のショップの分の見積もり情報を削除するなどの処理が必要であった。
第二の実施の形態においては、クライアントソフトウェアから印刷注文サーバへ送る際には見積もり情報をジョブチケットに含めず、ショップIDと見積もりIDのみを指定するものとする。
【０１５７】
クライアントソフトウェア側では、見積もり情報を全て含むジョブチケットを保持しておき、印刷注文サーバへ送るときに見積もり情報を削除する。
ショップ側では、必要な料金計算をショップサーバに接続されたデータベースから引き出した見積もり情報を基に行う。
【０１５８】
以上のように、送信時のジョブチケットから見積もり情報を削除し、クライアントソフトウェア側で保持するジョブチケットのみに見積もり情報を残しておくことで、サーバ側の処理の負担を軽減し、かつ通信トラフィックを減らし、システムの効率を上げることが可能となった。
【図面の簡単な説明】
【０１５９】
【図１】印刷注文システムの全体構成を示すブロック図である。
【図２】タイミングチャートである。
【図３】ジョブチケットの一例を示す図である。
【図４】料金体系の違いを示す特性図である。
【図５】ジョブチケットを示す図である。
【図６】ジョブチケットを示す図である。
【図７】ジョブチケットを示す図である。
【図８】印刷拠点のショップサーバ周りの構成を示すブロック図である。
【図９】印刷拠点内部のデータ構造図である。
【図１０】ジョブチケットを示す図である。
【図１１】ジョブチケットを示す図である。
【図１２】印刷拠点内部のデータ構造図である。
【図１３】ジョブチケットを示す図である。
【図１４】ショップのショップサーバが受注処理をする際の処理の手順を示したフローチャートである。
【図１５】クライアントソフトウェアの画面例を示す図である。
【図１６】クライアントソフトウェアのユーザインタフェース画面で、利用者によってあるフィールドが編集される際の処理手順を示すフローチャートである。
【図１７】ジョブチケットの注文指示を適切に設定、編集する手順を示すフローチャートである。
【図１８】第２の実施の形態におけるジョブチケットの一例を示す図である。
【符号の説明】
【０１６０】
１  印刷注文サーバ
２  データベース
３  注文クライアント
４  注文クライアント
５  印刷拠点
６  印刷拠点
７  ネットワーク(接続線)
８  ネットワーク(接続線)
【図１】
2005092337.tif 000003
【図２】
2005092337.tif 000004
【図３】
2005092337.tif 000005
【図４】
2005092337.tif 000006
【図５】
2005092337.tif 000007
【図６】
2005092337.tif 000008
【図７】
2005092337.tif 000009
【図８】
2005092337.tif 000010
【図９】
2005092337.tif 000011
【図１０】
2005092337.tif 000012
【図１１】
2005092337.tif 000013
【図１２】
2005092337.tif 000014
【図１３】
2005092337.tif 000015
【図１４】
2005092337.tif 000016
【図１５】
2005092337.tif 000017
【図１６】
2005092337.tif 000018
【図１７】
2005092337.tif 000019
【図１８】
2005092337.tif 000020