(57)【要約】【課題】  コンテンツの表示・再生に必要な要素を一まとめにして送信する際、複数コンテンツの共通部分をＭＩＭＥメッセージの一つのパートに割り当て、重複する情報の削除とストリーミング処理とを共に実現する。【解決手段】  他のファイルへのリンクを記述可能な構造化文書を処理する構造化文書において、複数の前記構造化文書と前記構造化文書からリンクされた一つ以上のファイルを結合し一つのパッケージデータにするファイル結合手段と、前記リンクされたファイルに対応した識別情報を生成する識別情報生成手段と、前記構造化文書内のリンク記述を前記リンク記述が示すファイルの前記識別情報に変換するリンク先識別情報記述変換手段とを有し、前記リンク先識別情報記述変換手段は、前記構造化文書から同一のファイルをリンクしていた場合には該当するリンク記述を同一の識別情報に変換する。【選択図】  図１０
2007048058.tif 000002
【特許請求の範囲】
【請求項１】
他のファイルへのリンクを記述可能な構造化文書を処理する構造化文書処置装置において、
複数の前記構造化文書と前記構造化文書からリンクされた一つ以上のファイルを結合し一つのパッケージデータにするファイル結合手段と、
前記リンクされたファイルに対応した識別情報を生成する識別情報生成手段と、
前記構造化文書内のリンク記述を前記リンク記述が示すファイルの前記識別情報に変換するリンク先識別情報記述変換手段とを有し、
前記リンク先識別情報記述変換手段は、前記構造化文書から同一のファイルをリンクしていた場合には該当するリンク記述を同一の識別情報に変換することを特徴とする構造化文書処理装置。
【請求項２】
請求項１記載の構造化文書処理装置において、
前記構造化文書からリンクされている複数のファイルが同一か否かを判断する同一性判断手段を有し、
前記識別情報生成手段は、前記同一性判断手段により同一と判断された複数のファイルには前記複数のファイルに対応した識別情報を一つしか生成しないことを特徴とする構造化文書処理装置。
【請求項３】
請求項２記載の構造化文書処理装置において、
前記ファイル結合手段は、前記ファイルと、前記識別情報生成手段により生成された前記識別情報とを、関連付けてパッケージデータへ結合することを特徴とする構造化文書処理装置。
【請求項４】
請求項３記載の構造化文書処理装置において、
前記ファイル結合手段は、前記識別情報生成手段により複数のファイルに同一の識別情報が生成された場合に同一の識別情報を持つ複数のファイルから一つだけを選択しパッケージデータへ結合することを特徴とする構造化文書処理装置。
【請求項５】
請求項１に記載の構造化文書処理装置において、
前記識別情報生成手段は、ファイルの種類を示す情報を加えた識別情報を生成することを特徴とする構造化文書処理装置。
【請求項６】
請求項１記載の構造化文書処理装置によって生成されたパッケージデータを処理する構造化文書処理装置において、
前記パッケージデータより識別情報を取得する識別情報取得手段と、
取得した識別情報よりファイル名を生成するファイル名生成手段と、
前記識別情報に対応する前記パッケージデータ内の範囲を抽出し、前記ファイル名生成手段により生成したファイル名でファイルに保存するファイル保存手段とを有し、
前記ファイル保存手段は全てのファイルを識別情報により一意に識別されるファイル名で保存することを特徴とする構造化文書処理装置。
【請求項７】
請求項６記載の構造化文書処理装置において、
前記パッケージデータに収められているファイルの内容を解析しファイルのフォーマットを判別するフォーマット解析手段と、
前記フォーマット解析手段が判別したフォーマットに応じて、ファイルの保存を行うか、アプリケーションへの受け渡しを行うかを判断する処理内容判断手段とを備えることを特徴とする構造化文書処理装置。
【請求項８】
請求項７記載の構造化文書処理装置において、
前記フォーマット解析手段は、請求項５記載の識別情報が含むファイルの種類に示す情報を基にファイルのフォーマットを判別することを特徴とする構造化文書処理装置。
【請求項９】
請求項４記載の構造化文書処理装置において、
前記ファイル結合手段は、前記構造化文書からリンクされたファイルを結合したパッケージデータの末尾に、前記リンク先識別情報記述変換手段を用いて変換した前記構造化文書を追記することを特徴とする構造化文書処理装置。
【請求項１０】
請求項２記載の構造化文書処理装置において、
前記結合手段により結合されたパッケージデータはMIME(Multipurpose Internet Mail Extensions / RFC2045により定義される)形式である事を特徴とする構造化文書処理装置。
【請求項１１】
請求項１０記載の構造化文書処理装置において、
前記識別情報はMIMEで定義されたCID(Content-ID)を含む事を特徴とする構造化文書処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、再利用される側のデータ群と利用する側のデータ群の組を、ネットワーク、ストレージ等の資源の消費を抑えて受け取り側へ渡すプロセスに関するものであり、例えば、渡す相手により内容が異なるバリアブル印刷用画像データの生成・送信・印刷に関するものである。
【背景技術】
【０００２】
従来、図２〜４に示すような画像をリンクするコンテンツを相手に渡す場合、HTTPとHTMLに代表されるリンク元コンテンツとリンク先画像をそれぞれ分けて渡す方法か、電子メールやPDFに代表されるコンテンツと画像をまとめて一つのパッケージデータとしたものをコンテンツ毎に生成し送る方法がよく用いられている。後者の例を図１８に示す。
【０００３】
このような環境では、コンテンツ毎に画像を組み合わせてコンテンツの作者が意図した画像や印刷物を生成し、画面やプリンタへ出力することになっている。
【０００４】
このような環境で顧客毎に多少の修正を加えた印刷を行う所謂バリアブル印刷を実現するためには、密なネットワーク環境であれば前者、ストレージを用いる場合は後者を用いることで実現することができた。
【０００５】
しかしながら、各コンテンツが同一の画像を参照していた場合、前者であればキャッシュを保存する事で同じ画像を複数回取得する事を避けられるが、同一である事を判断するための情報がURIなどのリンク情報しかなく、異なるURIで内容が同一の画像などには対応することができなかった。一般的なキャッシュのアルゴリズムは非参照回数・時間等の履歴を利用したものであり、実際にいつ利用されるかという情報は含んでいないため、キャッシュに十分な記憶領域を確保しておかないとキャッシュミスを生じる事もありえた。
【０００６】
また、後者であればコンテンツ毎に画像を格納するため重複する画像に対し重複を避けるような対応をする事ができなかった。図１８は後者の例である。３種類の記録対象データを含んでいる。各記録対象データは共通の画像データIMG_0001.jpg, IMG_0003.png を含んでいるが、従来は記録対象データ毎に参照する画像データを含めていた。
【０００７】
特開2003-110831では、前者を解決する方法として、重複する部分を事前に送信しておく方法を提案しているが、コンテンツの作者が予め重複部分を明示してコンテンツを設計する必要があり、また、データ転送後も各画像データの組合せ方法等を指示しなければならいため、密なメッセージ交換が可能な環境でなければ実現が難しいという問題がある。
【特許文献１】特開２００３−１１０８３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上記の問題点を解決するべく成されたもので、双方向通信が可能なネットワーク上でもストリーミング転送などの片方向の通信を行うネットワークでもストレージ上でも利用可能なデータ交換を効率化するデータ交換システムを提供する事を目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために、本願の請求項１に記載の構造化文書処理装置は、
他のファイルへのリンクを記述可能な構造化文書を処理する構造化文書において、
複数の前記構造化文書と前記構造化文書からリンクされた一つ以上のファイルを結合し一つのパッケージデータにするファイル結合手段と、
前記リンクされたファイルに対応した識別情報を生成する識別情報生成手段と、
前記構造化文書内のリンク記述を前記リンク記述が示すファイルの前記識別情報に変換するリンク先識別情報記述変換手段とを有し、
前記リンク先識別情報記述変換手段は、前記構造化文書から同一のファイルをリンクしていた場合には該当するリンク記述を同一の識別情報に変換することを特徴とする。
【００１０】
また、本願の請求項２に記載の構造化文書処理装置は、
前記構造化文書からリンクされている複数のファイルが同一か否かを判断する同一性判断手段を有し、
前記識別情報生成手段は、前記同一性判断手段により同一と判断された複数のファイルには前記複数のファイルに対応した識別情報を一つしか生成しないことを特徴とする。
【００１１】
また、本願の請求項３に記載の構造化文書処理装置は、
前記ファイル結合手段が、前記ファイルと、前記識別情報生成手段により生成された前記識別情報とを、関連付けてパッケージデータへ結合することを特徴とする。
【００１２】
また、本願の請求項４に記載の構造化文書処理装置は、
前記識別情報生成手段により複数のファイルに同一の識別情報が生成された場合に同一の識別情報を持つ複数のファイルから一つだけを選択しパッケージデータへ結合することを特徴とする
また、本願の請求項５に記載の構造化文書処理装置は、
前記識別情報生成手段が、ファイルの種類を示す情報を加えた識別情報を生成することを特徴とする。
【００１３】
また、本願の請求項６に記載の構造化文書処理装置は、
請求項１記載の構造化文書処理装置によって生成されたパッケージデータを処理する構造化文書処理装置において、
前記パッケージデータより識別情報を取得する識別情報取得手段と、
取得した識別情報よりファイル名を生成するファイル名生成手段と、
前記識別情報に対応する前記パッケージデータ内の範囲を抽出し、前記ファイル名生成手段により生成したファイル名でファイルに保存するファイル保存手段とを有し、
前記ファイル保存手段は全てのファイルを識別情報により一意に識別されるファイル名で保存することを特徴とする。
【００１４】
また、本願の請求項７に記載の構造化文書処理装置は
前記パッケージデータに収められているファイルの内容を解析しファイルのフォーマットを判別するフォーマット解析手段と、
前記フォーマット解析手段が判別したフォーマットに応じてファイルの保存を行うかアプリへの受け渡しを行うかを判断する処理内容判断手段とを備えることを特徴とする
また、本願の請求項８に記載の構造化文書処理装置は
前記フォーマット解析手段は、請求項５記載の識別情報が含むファイルの種類にを示す情報を基にファイルのフォーマットを判別することを特徴とする。
【００１５】
また、本願の請求項９に記載の構造化文書処理装置は、
前記ファイル結合手段が、前記構造化文書によりリンクされたファイルを結合したパッケージデータの末尾に、前記リンク先識別情報記述変換手段を用いて変換した前記構造化文書を追記することを特徴とする構造化文書処理装置。
【００１６】
また、本願の請求項１０に記載の構造化文書処理装置は、
前記結合手段により結合されたパッケージデータがMIME(Multipurpose Internet Mail Extensions / RFC2045により定義される)形式である事を特徴とする。
【００１７】
また、本願の請求項１１に記載の構造化文書処理装置は、
前記識別情報がMIMEで定義されたCID(Content-ID)を含む事を特徴とする。
【発明の効果】
【００１８】
以上説明したように、本発明によれば、重複する情報に対し一意の識別子を付加し、更に重複する情報を参照する側の参照先識別情報も変換する事で、結果として、受信側が正しく参照関係を再現できる構造で、かつ重複を省いてデータ量を少なくし、疎なネットワーク環境や何かしらのメディアを介した情報の伝達を可能とし、情報を送信するネットワーク帯域への負荷、もしくは情報を保存するメディアを占有する領域を削減する優れた効果を有する。
【００１９】
また、各情報の送信順序を変更する事で、結果として、ストリーミング処理を可能にし、更に遅延時間及びクライアント側・サーバ側の情報を管理するための記憶領域を節約する優れた効果を有する。
【発明を実施するための最良の形態】
【００２０】
以下、添付の図面に沿って本発明における実施の形態を説明する。
【００２１】
図１は本発明を利用するシステムの全体構成を示す。印刷所１８０１はサーバ１８０２とプリンタ１８０３を備え、外部からの印刷要求を受け付ける。なお、サーバ１８０２とプリンタ１８０３が同一の機器でも良い。
【００２２】
印刷所１８０１のサーバ１８０２は、印刷要求を発行する各クライアント１８０５〜１８０７とネットワーク１８０４を介して接続されており、各クライアント１８０５〜１８０７はバリアブル印刷用データを生成し印刷所へ送信する。バリアブル印刷用データを受け取った印刷所１８０１では、内容を解析しプリンタ１８０３から出力する。なお、各クライアントとサーバを繋ぐためにネットワークを用いているが、実際には常時接続されている必要は無く、また、ＦＤやＣＤ、ＨＤＤ等のストレージを利用してバリアブル印刷用データを交換しても良い。
【００２３】
本発明の第一の実施例について説明する。第一の実施例ではクライアントがJPEG画像、PNG画像を参照する複数個のSVG画像をＭＩＭＥメッセージとして一つにまとめ、サーバである印刷所へ送るバリアブル印刷を行う。
【００２４】
システムの動作説明に先立って、送信する画像ファイルについて説明する。
【００２５】
図２、図３、図４は第一の実施例で利用するＳＶＧ画像であり、顧客毎に異なる内容の画像が印刷されるようカスタマイズされている。これらのＳＶＧ画像は共通するＪＰＥＧ，ＰＮＧ画像を参照しており、第一の実施例ではこれらのＳＶＧ画像を参照先画像と共にＭＩＭＥメッセージ内に格納し、印刷所へ送る。
【００２６】
各画像データは全てクライアント側が保持しており、各画像は相対パスを利用して参照先画像を指定している。図４に示す画像３は、他の画像とは異なる場所に配置されており、図３に示す画像２と同一のＰＮＧ画像を異なる識別子を用いて指定している。
【００２７】
クライアントは予め参照情報の記述されている場所を特定するため、図５に示す変換対象情報を生成する。事前に設定ファイルとして生成し、又はオペレータからの入力により動的に生成する。本実施例では、各画像フォーマットと、その要素名、属性名より参照情報が記述される場所を特定している。図５では、SVG画像であればimage要素のxlink:href属性の属性値に参照情報が記述されることを示している。
【００２８】
オペレータより送信対象のＳＶＧ画像を指定されると、２つのプロセスを順に行い送信メッセージの生成を行う。各プロセスを図６、図７に示す。
【００２９】
クライアントは送信対象となるＳＶＧ画像が指定されるたびに図６に示す送信元・送信先情報生成処理プロセスに従い、図８に示す参照元情報、図９に示す参照先情報を生成する。ここで生成する参照元情報とはオペレータが指定した送信画像のファイル名と、それらの画像のフォーマット・格納場所を格納する。参照先情報とはオペレータが指定した画像が参照する画像のファイル名・格納場所と、識別子として動的に生成したContent-IDを格納する。この二つの情報は図７に示す送信メッセージ生成処理で利用される。
【００３０】
参照元・参照先情報生成処理の詳細を、図６を利用して説明する。
【００３１】
クライアントはオペレータに送信対象ファイルを指定（ステップS601）されるたびに指定されたファイルのファイル名・絶対パス・フォーマットを識別（ステップS602）し、それらの情報を参照元情報に追加する（ステップS603）。
【００３２】
図２に示す画像１が指定されると、クライアントは画像のファイル名（顧客１.svg）、画像の絶対パス（/home/eda/print）、画像のフォーマット（ＳＶＧ）を取得し、参照元情報に追加する。その結果、図８の二列目の項目が生成される。
次に、クライアントは図５に示す変換対象情報よりＳＶＧに関する情報を取得（ステップS604）する。図５に示す変換対象情報からはimage要素のxlink:href属性に参照情報が記述されている事が分かる。
【００３３】
次に、クライアントは画像１の解析を開始（ステップS605）し、ステップS604で取得した情報に適合する属性を検索する。最初に参照情報として"IMG_0001.JPG"が指定されている参照画像１を見つける（ステップS606、S607）と、参照元画像の絶対パスと上記識別情報より参照先画像のファイル名・絶対パスを特定（ステップS608）する。次に、参照先情報を確認し、参照先画像が既に登録済みでないかどうかを確認する。参照画像１は今回最初に参照されたものなので、一意に識別可能なContent-IDを生成し、ファイル名・絶対パスと共に参照先情報へ追加（ステップS610、S611）する。その後、解析を継続（ステップS612）し、次の参照情報を検索する。
【００３４】
図２に示す画像１は画像を二つ参照しているので、画像１に対し参照元・参照先情報生成処理を行うと参照画像１に加え参照画像２の情報も参照先情報に加えられ、参照先情報は図９の第２、３列目の情報が記述された状態になる。
【００３５】
次に、図３に示す画像２に対し参照元・参照先情報生成処理を行うと、参照元情報には図８の２列目に示す"顧客２.svg"の項が追加され、参照先情報には図９の４列目に示す"IMG_0003.PNG"の項が追加される。画像２は"IMG_0002.JPG"も参照しているが、画像１を処理する際に既に追加されているので、ステップＳ６０９により追加処理が不要と判断される。
【００３６】
更に、図４に示す画像３に対し参照元・参照先情報生成処理を行うと、参照元情報には図８の３列目に示す"顧客Ａ.svg"の項が追加される。一方、画像３は"../IMG_0003.PNG"を参照しているが、これは画像３の絶対パスの情報を利用する事で画像２で参照していた画像と同一であると判断（ステップS609）されるため、参照先情報には変更が加えられない。
【００３７】
最後に、オペレータが送信画像の指定を終了すると、クライアントは図７に示す送信メッセージ生成手段に従い各参照元画像、参照先画像の結合を行う。以下、図７を利用し、詳細な処理を説明する。
【００３８】
クライアントがオペレータより送信画像の指定の終了を通知されると、クライアントは参照先情報に登録されているファイルを順にMIMEメッセージとして結合し、各パートにContent-IDを付加する。図９に示す参照先情報には"IMG_0001.JPG"、"IMG_0002.JPG"、"IMG_0003.JPG"の三つのファイルが登録されているので、ステップS610で生成したContent-IDを"CID001.JPG@...."、"CID002.JPG@...."、"CID003.PNG@...."の順で付加（ステップS701、S702）する。
【００３９】
更に図５に示す変換対象情報と図８に示す参照元情報より変換対象ファイルと変換対象特定条件を取得（ステップS703、ステップS704）し、対象ファイルを順に解析（S705）する。
【００４０】
図８に示す参照元情報は全てＳＶＧ画像であり、図５に示す変換情報よりimage要素のxlink:href属性を検索する事が分かる。各ファイルを解析し、変換対象となる要素・属性を検索（ステップS707、S708）する。画像１を解析すると、参照画像１、２に対する参照情報が見つかるので、図９に示す参照先情報より各ファイル名と変換結果との対応を取得し、それぞれ"IMG_0001.JPG"、"IMG_0002.JPG"と記述されている部分を"CID001.JPG@..."、"CID002.JPG@...."に変換する（ステップS709）。全ての変換が終わったら参照先画像を格納したMIMEメッセージの末尾に変換済み参照元ファイルを追加する。
【００４１】
同様に画像２、画像３に対し同様の処理を行い、参照情報をContent-IDである変換結果に変換し、MIMEメッセージに追加した結果を図１０に示す。ＭＩＭＥメッセージの先頭にContent-IDを付加した各参照先画像が格納され、後半に参照先情報を利用する参照元画像が配置され、参照元画像の参照先識別情報は全てContent-IDと対応した情報に変更されている。このようにする事で、各参照元画像が共通で利用する参照先画像を重複させる事なくサーバへ渡す事が可能となる。
【００４２】
クライアントは上記のプロセスに従い図１０に示すＭＩＭＥメッセージを生成し、ネットワーク、もしくは何かしらの保存用メディアを利用してサーバ側である印刷所へ上記ＭＩＭＥメッセージを送る。
【００４３】
一方、上記ＭＩＭＥメッセージを受け取ったサーバは図１１に示すプロセスに従い、Content-IDをファイル名に変換し、ＭＩＭＥメッセージをパート毎に保存（ステップS1103、S1104、S1107）する。アプリケーションが各パートの情報を取得する際はContent-IDより変換したファイル名を利用する事で識別する事が出来る。
【００４４】
また、パートを保存せずアプリケーションへ通知する事もできる（ステップS1105、S1106）。印刷所のサーバで印刷する際は、アプリケーションへ通知する情報は図１０に示すＭＩＭＥメッセージに含まれる各ＳＶＧ画像データとなる。サーバが各ＳＶＧ画像を解析する時点では既に参照先画像はファイルとして保存されており、各ＳＶＧ画像に記述されている参照先識別情報はファイル名と一致しているので参照・非参照の関係を正しく再生する事が可能となる。また、画像毎の組合せのルールは全て各ＳＶＧ画像内に記述されているのでＭＩＭＥメッセージ以外の情報交換の必要がない。
【００４５】
サーバは３つのＳＶＧ画像を順に解析する事で、情報の重複していないＭＩＭＥメッセージからクライアントが要求した３種類の印刷データを生成する事ができる。
【００４６】
本発明の第二の実施例について説明する。第二の実施例は第一の実施例とは異なり送信画像の解析と送信を並行して行う。送信する画像ファイルは第一の実施例と同じものである。送信時の処理は図１２に示すプロセスに従う。以下、メッセージ送信処理の詳細を図１２を利用して説明する。
【００４７】
クライアントはオペレータに送信画像ファイルを指定される毎に図１２に示すメッセージ送信処理を行う。送信画像を一つ指定（ステップS1201）されると、送信画像ファイルの絶対パス・フォーマットを識別（ステップS1204）する。図２に示す画像１が指定されると、クライアントは画像の絶対パス（/home/eda/print）、画像フォーマット（ＳＶＧ）を取得する。次に、クライン後は図５に示す変換対象情報よりＳＶＧに関する情報を取得（ステップS1204）する。
【００４８】
次に、クライアントは画像１の解析を開始（ステップS1205）し、ステップS1204で取得した情報に適合する属性を検索する。第一の実施例と同様に"IMG_0001.JPG:が取得できる（ステップS121206）ので、第一の実施例と同様に参照先ファイルの識別を行い、既に処理済みのファイルであるかどうかを判断し、初めて処理するファイルであれば一意に識別可能なContent-IDを生成し、それらの情報を参照先情報へ登録する（ステップS1207〜S1211）。更に、参照先ファイルをMIMEメッセージの一つのパートとして上記Content-IDを付加しサーバへ送る。参照元ファイルの参照先識別情報は画像ファイルの送信の有無に関わらず、参照先画像に割り振られたContent-IDより生成される参照情報へ変換（ステップS1213）する。
【００４９】
画像１は参照先情報を２つ持つので、ステップS1206〜1214を2回行い、2つの参照先画像情報をサーバへ送り、参照元画像の２つの参照先識別情報を変換する。その後、変換済みの参照元画像をMIMEメッセージの一つのパートとして更にサーバへ送る。その結果、図１３に示すMIMEメッセージがサーバ側に送られ、サーバ側は更にMIMEメッセージの次のパートを待受ける状態になる。
【００５０】
クライアント側でオペレータが更に図3に示す画像２の送信を指示（ステップS1201）すると、同様の手順で未送信の参照画像３をサーバへ送り、画像２の２箇所の参照先識別情報を変換（ステップS1204〜S1214）し、更に変換した参照元画像をサーバへ送る。
【００５１】
オペレータが更に図4に示す画像3の送信を指示すると、クライアントは参照先画像を既に全て送っているので参照先画像の送信は行わず、参照先識別情報を変換した参照元画像のみをサーバへ送る。
【００５２】
結果、サーバ側へは図１４に示すMIMEメッセージが届く事になる。
【００５３】
一方、サーバ側では図１３に示すMIMEメッセージを受け取った時点で、第一の実施例で用いた図１１に示すプロセスに従い、画像１を再生する。MIMEメッセージとしては途中までしか受け取っていない状態ではあるが、画像１を再生するために必要な２つの参照先画像を受信しているので画像１を再生する事が可能となる。
【００５４】
画像2、画像３を受け取った際も同様にMIMEメッセージの受信が終了していなくても図１１に示すプロセスに従い各画像を再生する事が可能である。このようにメッセージの生成と送信を同時に行う事で、ＭＩＭＥメッセージ全体をクライアント側で保持する必要も無くなり、また、ＭＩＭＥメッセージ全体の生成を待つ必要もなくサーバ側へ印刷内容を伝える事ができる。なお、各参照元画像は画像を再生した後は不要となるので、再生後破棄する事も可能である。
【００５５】
本発明の第３の実施例について説明する。
【００５６】
上記第一、又は第二の実施例に加え、更にオペレータが更にSVGでない画像としてＸＨＴＭＬで記述された図１５に示す画像４の送信を指示した場合について説明する。
【００５７】
図１５に示す画像４は画像２，３と同様に参照画像３を参照している。よって、画像２、３を送信した後は参照先画像を送る必要がない。
【００５８】
第一の実施例と同様の処理を行うと、図６に示す参照元・参照先情報生成プロセスに従い生成した図８に示す参照元情報より、画像４に関する情報を加えた図１６に示す新たな参照元情報を生成する。参照先情報は第一の実施例と同様のものが生成される。次に、図７に示す送信メッセージ生成プロセスでは、画像４に記述されている参照先識別情報を変換し、図１０に示すＭＩＭＥメッセージの末尾に変換済みの画像4の内容を追加する。
【００５９】
一方、第二の実施例と同様の処理を行うと、図１４に示すＭＩＭＥメッセージの送信が終了した後、更に画像４に対し図１２に示すメッセージ送信プロセスを行い、参照先識別情報を変換した画像データをＭＩＭＥのパートとして更に追加して送る。結果として、図１７に示すＭＩＭＥメッセージをサーバ側へ届ける事が可能となる。
【００６０】
なお、上記３つの実施例では触れなかったが、参照先ファイルが同一であるかどうかの判断は各ファイルの絶対パスによる比較だけではなく、ファイル内容の全比較、もしくは画像ファイルからヘッダ情報等を除いた画像本体のデータのみの比較により同一か否かを判断しても良く、また、類似する画像を同一のものと判断するなど、他の同一性決定アルゴリズムを利用しても良い。
【００６１】
また、本実施例では参照先情報として図示可能な静止画を例として挙げたが、音声情報や動画情報、また、天気情報や交通情報などの加工後に利用するような情報を参照先情報として扱っても良い。
【００６２】
また、参照先情報と非参照情報との参照関係を予めサーバ側へ送る事で、参照先画像を破棄可能なタイミングをサーバ側へ伝え、不要な参照先画像から適宜破棄していきより効率的にサーバ側の記憶領域を利用しても良い。
【図面の簡単な説明】
【００６３】
【図１】本実施例における構成図。
【図２】本実施例でバリアブル印刷を行う際の１つ目の画像データ。
【図３】本実施例でバリアブル印刷を行う際の２つ目の画像データ。
【図４】本実施例でバリアブル印刷を行う際の３つ目の画像データ。
【図５】参照先識別情報が記述された場所を特定する変換対象情報。
【図６】クライアントで行う参照元・参照先情報生成の処理内容を示すフローチャート。
【図７】クライアントで行う送信メッセージ生成の処理内容を示すフローチャート。
【図８】第一の実施例で生成される参照元情報。
【図９】第一の実施例で生成される参照先情報。
【図１０】第一の実施例で生成されるＭＩＭＥメッセージ。
【図１１】サーバで行うＭＩＭＥメッセージ解析の処理内容を示すフローチャート。
【図１２】第二の実施例でクライアントが行うメッセージ送信の処理内容を示すフローチャート。
【図１３】第二の実施例で一つ目の画像データを解析・送信した直後のＭＩＭＥメッセージ。
【図１４】第二の実施例で全ての画像データを解析・送信した後のＭＩＭＥメッセージ。
【図１５】第三の実施例で追加して印刷する画像データ。
【図１６】第三の実施例で生成される印刷元情報。
【図１７】第三の実施例で生成されるＭＩＭＥメッセージ。
【図１８】ＭＩＭＥを用いた場合の従来のメッセージ例。
【符号の説明】
【００６４】
１８０１  印刷所
１８０２  サーバ
１８０３  プリンタ
１８０４  ＷＡＮ
１８０５〜１８０７  クライアント
【図１】
2007048058.tif 000003
【図２】
2007048058.tif 000004
【図３】
2007048058.tif 000005
【図４】
2007048058.tif 000006
【図５】
2007048058.tif 000007
【図６】
2007048058.tif 000008
【図７】
2007048058.tif 000009
【図８】
2007048058.tif 000010
【図９】
2007048058.tif 000011
【図１０】
2007048058.tif 000012
【図１１】
2007048058.tif 000013
【図１２】
2007048058.tif 000014
【図１３】
2007048058.tif 000015
【図１４】
2007048058.tif 000016
【図１５】
2007048058.tif 000017
【図１６】
2007048058.tif 000018
【図１７】
2007048058.tif 000019
【図１８】
2007048058.tif 000020