印刷装置、印刷指示装置および印刷システム
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置であって、 サブデータを取得する印刷データ取得手段（インタプリタ１２０３）と、取得されたサブデータが、印刷データの印刷を完了するために再びインタプリタ１２０３によって取得される必要性があるか否かを判定する判定手段（ラスタライザ１２０２）と、必要性がないと判定された場合に、その旨を、印刷指示を発した印刷指示装置に通知する通知手段（通信Ｉ／Ｆ１２０４）とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は印刷装置、印刷指示装置および印刷システムに関し、特に印刷データを一時的に格納する印刷バッファのメモリ解放制御技術に関する。
【背景技術】
【０００２】
従来より、ネットワークで接続された印刷システムにおいて、印刷装置（以下、「画像形成装置」、「プリンタ」とも記す。）から印刷指示装置（以下、「文書画像供給装置」、「ホスト装置」とも記す。）に対して印刷データの転送を要求するＰｕｌｌ方式の印刷システムでは、文書画像供給装置が備える印刷バッファに印刷データを蓄積し、画像形成装置が印刷を実行している際に、必要になった印刷データをその都度、前記文書画像供給装置に対し、転送要求を行い、必要な印刷データを受信し、印刷している。
【０００３】
この印刷の処理中に、文書画像供給装置は印刷処理に不要になったデータを随時消去していき、印刷バッファを有効に利用することが必要となる。
【０００４】
従来から行われている印刷バッファのメモリ解放制御方法としては、画像形成装置が文書画像供給装置に印刷データの転送の要求を行い、受信が完了した際に行う転送応答を文書画像供給装置が受信した際に当該印刷データを印刷バッファから消去するか、または、ＰＵＳＨ方式の印刷システムのように、文書画像供給装置が印刷データの転送が完了したと判断した場合に、印刷バッファから当該印刷データを消去する方法がある。
【０００５】
例えば、図１に示されるように印刷データをバンド処理する場合、第１バンド、第２バンド、…の印刷データを図２に示されるラスタメモリＡ，Ｂに交互に格納し、第１バンドの印刷データの転送が完了すると、第１バンドの印刷データを削除し、第３バンドの印刷データをラスタメモリＡに格納し、第２バンドの印刷データの転送が完了すると、第２バンドの印刷データを削除し、第４バンドの印刷データをラスタメモリＢに格納する処理を繰り返し行うようにしてしている。図３は、バンドデータをラスタメモリに格納し、転送を行い、消去するタイミングを表す図である。
【０００６】
このようなＰＵＳＨ方式の印刷システムにおいては、文書画像供給装置が画像形成装置に対して印刷させたい印刷データを送信するため、文書画像供給装置が印刷データ転送完了後に当該印刷データを印刷バッファ上から消去することに問題はなかった。
【０００７】
ところで、オフィスでのネットワーク化の普及に伴いネットワーク対応のプリンタが広く普及している。今後は、家庭においてもネットワーク化が進む方向にあり、家庭でのネットワーク対応プリンタも普及してゆくと予想される。なお、ネットワークプリントにおけるネットワークとしては、従来からのＬＡＮ（Ｌｏｃａｌ ＡｒｅａＮｅｔｗｏｒｋ）だけでなく、インターネットも対象になりつつある。
【０００８】
ここで、ネットワークプリント方式の１つに、Ｐｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式（本明細書中、以下、ＰＢＲ方式と呼ぶ）がある。ＰＢＲ方式では、ホスト装置が印刷データのサーバともなり、ホストがプリンタにＵＲＬを指定した印刷指示を出し、印刷指示を受け取ったプリンタはＵＲＬで指定されるＷｅｂサーバからデータを取得して印刷する。
【０００９】
ここで、ＵＲＬでインターネット上のデータを指定すれば、インターネット上のデータをも印刷することが可能である。
【００１０】
ＰＢＲ方式では、インターネット接続機能を持たないホストからであっても、インターネット上のデータを印刷可能であることが大きな優位点である。安価なホストでは、大きなコストアップ要因となるインターネット接続機能を搭載するのは困難であるが、そのようなホストからでも、インターネット上データの印刷機能を実現できるので、今後広く普及することが予想される。
【００１１】
ここで、インターネット・プリンティングプロトコルの代表的なものとしてＲＦＣで規定されており標準プロトコルとなっているＩｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ（本明細書中、以下、ＩＰＰと呼ぶ）があるが、ＩＰＰにおいてもＰＢＲ方式に準じたものとしてＰｒｉｎｔ−ＵＲＩリクエストが規定されている。この動作であるが、ホストがプリンタにＵＲＬを指定した“Ｐｒｉｎｔ−ＵＲＩリクエスト”を送ると、それを受け取ったプリンタが、ＵＲＬ指定先のＷｅｂサーバ上のデータを取得して印刷を行なう。このＰｒｉｎｔ−ＵＲＩ機能により、世界中のＷｅｂサーバ上のデータを印刷することを実現できる。
【００１２】
さて、ＰＢＲ方式対応プリンタでの印刷データとしては、ＰｏｓｔＳｃｒｉｐｔに代表されるページ記述言語で書かれたデータ、ＰＣＬに代表されるプリンタ制御言語で書かれたデータ、ＪＰＥＧ圧縮された画像データ等の他にＨＴＭＬに代表されるマークアップ言語で書かれたデータ（以下、マークアップデータと呼ぶ）等がある。
【００１３】
ここで、マークアップデータでは、データ内部から別のデータを参照する記述が可能であるが、ＰＢＲ方式で印刷データとしてマークアップデータを指定して印刷指示をする場合、指定したマークアップデータが印刷対象となりうるデータを参照しているならば、マークアップデータだけでなく参照データも印刷対象となる。
【００１４】
さて、ＰＢＲ方式を対応するプリントシステムにおいては、クライアント、プリンタ、Ｗｅｂサーバの３者が登場するが、各々を別々の装置に存在させなくてもよい。クライアントとＷｅｂサーバを１つのホスト装置に実装し、プリンタ装置と接続させるシステム構成も可能である。システム構成上、装置が２つしか存在しないので、このシステム構成を、本明細書中で以後、２者システムと呼ぶことにする。２者システムでは、ホスト装置とプリンタ装置よりなる通常のＬＡＮ対応プリントシステムと同じ構成になるが、ＰＢＲ方式でインターネットプリンティングも可能なプリンタ装置をそのままＬＡＮ対応プリンタとして使用できることになる。
【００１５】
さて、従来技術として、ＰＢＲ方式での２者システムの例がある（例えば、特許文献１を参照）。特許文献１において、ＰＢＲのプロトコルとして、ＩＰＰでのＰｒｉｎｔ−ＵＲＩリクエストで実現している。
【００１６】
この従来例の２者システムにおいては、ホスト装置はＰｒｉｎｔＵＲＩリクエストで自装置内の印刷データを指定するＵＲＬをプリンタに送る。プリンタはＵＲＬより印刷データがネットワーク上のホスト装置にあることを特定し、ホスト装置のＷｅｂサーバにアクセスして指定の印刷データをダウンロードして印刷する。
【００１７】
図４は、この従来例におけるホスト装置におけるデータ処理手順動作を示すフローチャートである（特許文献１の図７参照）。なお、以下では、印刷データのデータ転送と削除タイミングに関わる部分について重点的に説明し、それ以外については簡略説明にとどめる。
【００１８】
まず、ステップＳ９００１において、印刷データ転送のためのＷｅｂサーバが起動していない場合には、Ｗｅｂサーバを起動する（Ｓ９００２）。
【００１９】
次に、印刷データの登録が行なわれ（Ｓ９００３）、印刷データの管理を行なう（Ｓ９００４）。
【００２０】
次に、データに対するＰｕｌｌ要求（ダウンロード要求）をプリンタから受けると、それが印刷データに対する一番目のＰｕｌｌ要求の場合かを判断する（Ｓ９００５）。
【００２１】
一番目のＰｕｌｌ要求の場合は、Ｐｕｌｌ要求を受け付けて（Ｓ９００６）、印刷データをプリンタに返信する（Ｓ９００７）。
【００２２】
そして、印刷データの転送が完了したかを判断して（Ｓ９００８）、印刷データの転送が完了したと判断した場合には、ステップＳ９００９に移行して当該印刷データを自装置内から削除し、Ｗｅｂサーバを停止し（Ｓ９０１０）、処理を終了する（Ｓ９０１１）。
【００２３】
さて、ＰＢＲ方式では、Ｗｅｂサーバ上の印刷データの削除タイミングについては一般的に規定がない。実装に依存するがＩＰＰにおいても同様である。
【００２４】
一般的にＰＢＲの２者システムでは、ホスト装置はプリンタが印刷出力が完了したことを確認後に自装置内の印刷データを削除する。印刷出力が完了したので印刷データが不要なのは自明だからである。
【００２５】
ここで、印刷エンジンでの印刷処理には印刷データ転送等の他の処理に比べて多くの時間が必要である。印刷出力完了まで印刷データの保管をしておくとなると、ホスト装置は、長時間、印刷データ格納のための印刷データバッファ（ＲＡＭ等のワークメモリ）を解放できず、システムリソースの効率的かつ有効な活用が困難である。
【００２６】
これに対して、この従来例では、プリンタが１度ダウンロードした印刷データの再ダウンロードをしないことを前提とし、ホスト装置は印刷データの送信が完了した時点で印刷データは不要と判断して削除を行なっている。
【００２７】
この従来例においては、印刷データの送信が印刷出力の完了よりもかなり早く終了するので、印刷データを格納する印刷データバッファの解放をより早くでき、ホスト装置のシステムリソースを早いタイミングで印刷以外の処理に提供でき効率的かつ有効な活用が図れることを目的としている。
【特許文献１】特開２００２−２０２８７４号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかしながら、従来からあるＰｕｌｌ方式の印刷システムのメモリ解放制御方法では、例えば、インターネット上のＨＴＭＬコンテンツのようなドキュメントを印刷ドキュメントとする場合、１つの印刷ドキュメントの中で同一の画像オブジェクトが複数回用いられることが多々ある。
【００２９】
この場合、文書画像供給装置から画像形成装置に一度目の画像データの転送が完了しても、画像形成装置から文書画像供給装置に再度同一の画像の転送の要求がされることになる。従来のＰｕｌｌ方式のメモリ解放制御方法では、一度目の転送完了時に当該画像データは削除されており、二度目以降の転送要求には対応できないことになる。
【００３０】
このような場合に、従来のＰｕｌｌ方式の印刷システムでは、２度以上転送要求のある印刷オブジェクトは、印刷バッファ上から消去されているため、文書画像供給装置は画像形成装置からの印刷オブジェクトの転送要求に対して、再度印刷オブジェクトの生成を行う負荷をおうか、または画像形成装置からの印刷オブジェクトの転送要求に対応することができない。
【００３１】
印刷データが再度要求される可能性のあるＰｕｌｌ方式の印刷システムでも、印刷ジョブが終了すると印刷バッファは解放できるため、最小でも１つの印刷ジョブで必要な印刷データを全て格納できるだけの印刷バッファが確保できれば問題ないが、印刷バッファの容量が十分でない場合、印刷データの転送後も新たな印刷データをバッファに格納できない状況になり、印刷データの転送を継続することが不可能となる。
【００３２】
つまり、従来の技術では、印刷データを早く削除しすぎた結果、印刷データの再要求があった場合には印刷データを再度生成して印刷バッファに格納しなければならず、印刷データの再要求があった場合におけるオーバーヘッドが大きいという問題がある。
【００３３】
さて、ＰＢＲ方式では、プリンタが印刷データをダウンロードしたからといって、再ダウンロード要求をしないという保証はない。これは２者システムでのＰＢＲにおいても同様である。再ダウンロードするか否かはプリンタの実装に依存する。
【００３４】
ＰＢＲ方式において、再ダウンロードをうまく活用すれば、少ないシステムリソース（ＲＡＭ等）しか持たない安価なプリンタであっても高機能を実現することができる。
【００３５】
以下に、一例を示す。画像データをプリンタで回転させて印刷する場合である。インクジェットプリンタに代表されるラインプリンタでは、印刷データバッファにはプリンタヘッド走査に必要な分だけの印刷データを格納して処理する構成をとれるので、印刷データバッファを実現するメモリサイズを小さくでき、これにより低価格を実現している。
【００３６】
ここで、ＰＢＲ方式でプリントするラインプリンタで画像の回転印刷機能を実現することを考える。最も簡単な方法は画像データ全体をダウンロードし、画像データ全体をプリンタのプリンタバッファに格納し、それを回転したうえで印刷する方法である。この方法ならばダウンロードは１回で十分であり、再ダウンロードは必要ない。しかしながら、通常画像データはサイズがかなり大きく、その全体を格納するためには大きなサイズのプリンタバッファメモリが必要となるため、コストアップにつながり安価なプリンタとできない。
【００３７】
これに対して、ダウンロードした画像データのうち、プリンタヘッド走査において必要とされまた小さなプリンタバッファに格納できるだけを回転させてプリンタバッファに格納することで回転印刷をする方法がある。この方法においては、回転イメージは１回で作成できず、画像データの「ダウンロード・回転」を繰り返すことで回転させて印刷を行なうことで画像回転印刷を実現する。この方法の場合、同じ印刷データに対して複数回のダウンロードが必要であるが、小さな印刷データバッファしかない安価なラインプリンタであっても画像回転のような高機能を実現することができる。
【００３８】
このように、ＰＢＲ方式のネットワークプリンタに印刷データの再ダウンロードをするならば、安価な構成で高機能を実現できる。
【００３９】
しかしながら、前記従来のホスト装置のデータ処理では、プリンタからの再ダウンロードに対応しておらず、印刷データの再ダウンロードが必要なプリンタ処理を継続できないという課題を有していた。
【００４０】
また、一般的なＰＢＲの２者システムで行なわれている印刷出力完了時に印刷データを削除する方式だと再ダウンロードに対応できるが、印刷データ格納のためのシステムリソースの効率的かつ有効な活用が困難である課題は残る。
【００４１】
すなわち、従来の技術では、印刷データを早く削除しすぎた結果、印刷データの再要求があった場合には印刷データを再度生成して印刷バッファに格納しなければならず、印刷データの再要求があった場合におけるオーバーヘッドが大きかったり、印刷バッファに印刷データを長時間持ちすぎたりするという問題がある。
【００４２】
そこで、本発明は、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを防止しつつ、効率よく印刷バッファを利用することができる印刷装置、印刷指示装置および印刷システムを提供することを目的とする。
【課題を解決するための手段】
【００４３】
上記目的を達成するために、本発明に係る印刷装置においては、印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置であって、サブデータを取得する印刷データ取得手段と、取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知手段とを備えることを特徴とする。
【００４４】
これにより、その旨を通知された印刷指示装置は、印刷データが再び取得されることがないことを知り、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００４５】
また、本発明に係る印刷装置においては、前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、前記印刷データ取得手段は、子サブデータに先立って親サブデータを取得し、前記判定手段は、取得された親サブデータが参照している子サブデータに基づいて前記必要性を判定することを特徴とすることができる。
【００４６】
これにより、印刷指示装置は、子サブデータごとに再び取得されることがあるか否かを判断することができる。
【００４７】
また、本発明に係る印刷装置においては、前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータの１箇所だけから参照されている場合に、前記必要性がないと判定することを特徴とすることもできる。
【００４８】
これにより、他の箇所から参照されている場合に、その子サブデータを削除してしまう事態を避けることができる。
【００４９】
また、本発明に係る印刷装置においては、前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータで以降参照されない場合に、前記必要性がないと判定することを特徴とすることもできる。
【００５０】
これにより、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、迅速に印刷バッファを解放することができる。
【００５１】
また、本発明に係る印刷装置においては、前記親サブデータから参照される子サブデータには、前記子サブデータから参照される孫サブデータが含まれることを特徴とすることもできる。
【００５２】
これにより、多様な箇所から孫サブデータ（画像データ）を集め、印刷データを構成することができる。
【００５３】
また、本発明に係る印刷装置においては、前記判定手段は、前記親サブデータだけについて、前記必要性を判定することを特徴とすることもできる。
【００５４】
これにより、印刷バッファに親サブデータだけが格納されている場合に、この親サブデータを迅速に削除することができる。
【００５５】
また、本発明に係る印刷装置においては、前記通知手段は、前記印刷指示装置から前記通知の要求を受けた場合にだけ、前記通知をすることを特徴とすることができる。
【００５６】
これにより、通知の要求を受けない場合には、通知の必要がないので、印刷装置における処理が簡易化され、かつ通信量の少ない方法で印刷バッファを解放することができる。
【００５７】
また、本発明に係る印刷装置においては、前記通知手段は、前記印刷指示に前記通知の要求が含まれているか否かを判断し、含まれている場合にだけ、前記通知をすることを特徴とすることもできる。
【００５８】
これにより、通知の要求が含まれている場合にだけ通知すればよいので、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止することができる。
【００５９】
また、本発明に係る印刷装置においては、前記親サブデータは、マークアップ言語で記述され、前記子サブデータは、マークアップ言語で記述されたデータを除くデータであることを特徴とすることができる。
【００６０】
また、本発明に係る印刷装置においては、前記親サブデータは、ＨＴＭＬで記述され、前記子サブデータは、画像データまたはスタイル情報データであることを特徴とすることもできる。
【００６１】
また、上記目的を達成するために、本発明に係る印刷指示装置においては、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置であって、少なくとも１つのサブデータを保持する印刷バッファと、前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信手段と、前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段とを備えることを特徴とする。
【００６２】
これにより、その旨を通知された場合にだけ、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００６３】
また、本発明に係る印刷指示装置においては、前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、前記印刷バッファは、前記印刷データを構成するサブデータのうち、親サブデータだけを保持し、前記削除手段は、前記親サブデータを前記印刷バッファから削除することを特徴とすることができる。
【００６４】
なお、本発明は、このような印刷装置や、印刷指示装置として実現することができるだけでなく、このような印刷装置と、印刷指示装置とから構成される印刷システムとして構成したり、このような印刷装置や、印刷指示装置が備える特徴的な手段をステップとする印刷方法や、印刷指示方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【発明の効果】
【００６５】
以上の説明から明らかなように、本発明に係る印刷装置、印刷指示装置および印刷システムによれば、印刷データが再び取得されることがない場合にだけ、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００６６】
よって、本発明により、ハードウェア資源の少ない装置間で、システムリソースの効率的かつ有効活用を図ることができるＰｕｌｌ方式の印刷システムが実現され、インターネットが普及してきた今日における本願発明の実用的価値は極めて高い。
【００６７】
本発明は、以下の実施の形態および添付の図面を用いて説明されるが、これは例示を目的とするものであって、本発明はこれらに限定されることを意図しない。
【図面の簡単な説明】
【００６８】
【図１】印刷システムにおける印刷データのバンド処理を表す図である。
【図２】印刷データを格納する印刷バッファの使用例を表す図である。
【図３】図１のバンドデータを図２のラスタメモリに格納し、転送を行い、消去するタイミングを表す図である。
【図４】従来の実施例におけるホスト装置のデータ処理手順の一例を示すフローチャートである。
【図５】本発明の実施の形態に係る印刷システムの全体構成を示すブロック図である。
【図６】実施の形態１における印刷ドキュメントの例を示す図である。
【図７】図６の印刷ドキュメントを表す印刷記述データを示す図である。
【図８】印刷記述データのラスタライズ手順を示す図である。
【図９】印刷オブジェクトの要不要判定手順を含む画像形成装置の処理フローを示す図である。
【図１０】印刷オブジェクトの不要通知による印刷バッファ解放のフローを示す図である。
【図１１】本発明の実施の形態１における文書画像供給装置と画像形成装置間の通信シーケンスを示す図である。
【図１２】実施の形態２における印刷ドキュメントの例を示す図である。
【図１３】実施の形態２の印刷ドキュメントの詳細な構成を示す図である。
【図１４】図１３の印刷ドキュメントを表す印刷記述データを示す図である。
【図１５】内部処理モードの変更手順を含む画像形成装置の処理フローを示す図である。
【図１６】印刷オブジェクト転送要求による転送済み印刷オブジェクトの解放フローを示す図である。
【図１７】本発明の実施の形態１における文書画像供給装置と画像形成装置間の通信シーケンスを示す図である。
【図１８】本発明の実施の形態３におけるネットワーク構成を示すシステム構成図である。
【図１９】本発明の実施の形態３におけるホスト装置の構成を示すブロック図である。
【図２０】本発明の実施の形態３における印刷装置の構成を示すブロック図である。
【図２１】本発明の実施の形態３におけるホスト装置の機能構成を示す図である。
【図２２】本発明の実施の形態３における印刷装置の機能構成を示す図である。
【図２３】本発明の実施の形態３におけるプリンタステータスを定義する定義テーブルを示す図である。
【図２４】本発明の実施の形態３におけるプリンタステータスレコードのフィールド構成を示す図である。
【図２５】本発明の実施の形態３におけるジョブステータスを定義する定義テーブルを示す図である。
【図２６】本発明の実施の形態３におけるジョブステータスレコードのフィールド構成を示す図である。
【図２７】本発明の実施の形態３におけるプリンタステータスパケットのフィールド構成を示す図である。
【図２８】本発明の実施の形態３におけるジョブステータスパケットのフィールド構成を示す図である。
【図２９】本発明の実施の形態３における印刷データの構成を示す図である。
【図３０】本発明の実施の形態３における印刷データの格納場所を説明する図である。
【図３１】本発明の実施の形態３におけるホスト装置と印刷装置間の通信シーケンスを示す図である。
【図３２】本発明の実施の形態３におけるホスト装置のデータ処理を示すフローチャートである。
【図３３】本発明の実施の形態３における印刷装置のデータ処理を示すフローチャートである。
【図３４】本発明の実施の形態４における印刷データの構成を示す図である。
【図３５】本発明の実施の形態４における印刷データの格納場所を説明する図である。
【図３６】本発明の実施の形態４におけるホスト装置と印刷装置間の通信シーケンスを示す図である。
【図３７】本発明の実施の形態４におけるホスト装置のデータ処理を示すフローチャートである。
【図３８】本発明の実施の形態４における印刷装置のデータ処理を示すフローチャートである。
【図３９】本発明の実施の形態５におけるネットワーク構成を示すシステム構成図である。
【図４０】本発明の実施の形態５における印刷データの構成を示す図である。
【図４１】本発明の実施の形態５における印刷データの格納場所を説明する図である。
【図４２】本発明の実施の形態５におけるホスト装置、サーバ装置と印刷装置間の通信シーケンスを示す図である。
【図４３】印刷指示装置の印刷データバッファに、６個のプリントジョブ（Ｊｏｂ５〜Ｊｏｂ１０）のデータを格納している状態を示す図である。
【図４４】印刷指示装置におけるジョブ管理と、プリンタにおけるジョブのデータ取り込みの様子を示す図である。
【符号の説明】
【００６９】
１，２，３ 印刷システム
１１００ 文書画像供給装置
１１０１ アプリケーション
１１０２ 変換部
１１０３ プリンタ制御部
１１０４ 通信Ｉ／Ｆ
１２００ 画像形成装置
１３００ 伝送媒体
１４００ 印刷ドキュメント
１４０１〜１４０３ 画像オブジェクト
１４０４ 印刷記述データ
２００１ ホスト装置
２００２ 印刷装置
２００３ ネットワーク
２００４ ＰＢＲクライアント機能
２００５ ＰＢＲデバイス機能
２００６ Ｗｅｂクライアント機能
２００７ Ｗｅｂサーバ機能
２００８ サーバ装置
２０４２ プリントサービス
２０４３ ＰＢＲクライアントポート
２０４５ 印刷データバッファ
２０４７ Ｗｅｂサーバ
２０５１ ＰＢＲデバイスポート
２０５６ ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ
２０５７ レイアウト計算部
２０５９ Ｗｅｂクライアント
【発明を実施するための最良の形態】
【００７０】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００７１】
（実施の形態１）
図５は、本発明の実施の形態に係る印刷システムの全体構成を示すブロック図である。
【００７２】
印刷システム１は、図５に示されるように、文書画像供給装置１１００と、画像形成装置１２００と、文書画像供給装置１１００と画像形成装置１２００とを相互に通信可能に接続する伝送媒体１３００とから構成される。
【００７３】
文書画像供給装置１１００としては、デジタルＴＶや、セットトップボックス（ＳＴＢ）等を使用することができるが、その他データのソース源となる機器であれば何でも適用可能である。また、画像形成装置１２００としては、プリンタあるいはファクシミリ等を使用することができる。さらに、伝送媒体１３００としては、コンピュータとプリンタ間に使用されるバスあるいは公衆網、専用回線、インターネット網等の有線または無線でデータ転送可能な媒体を用いることができる。なお、図５においては、文書画像供給装置１１００としてデジタルテレビ（ＤＴＶ）を使用した場合の内部構成が示されており、画像形成装置１２００としてプリンタを使用した場合の内部構成が示されている。
【００７４】
文書画像供給装置１１００は、アプリケーション１１０１と、変換部１１０２と、プリンタ制御部１１０３と、印刷バッファ１１０５と、通信Ｉ／Ｆ１１０４とから構成される。
【００７５】
アプリケーション１１０１は、印刷記述データを生成する。変換部１１０２は、アプリケーション１１０１から出力された印刷記述データの形式を、画像形成装置１２００が解読可能な階層構造をもつリンクファイル（ここではＸＨＴＭＬ（Ｅｘｔｅｎｓｉｂｌｅ ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を使用する）形式に変換する。プリンタ制御部１１０３は、印刷記述データを解読してプリントジョブを発行したり、印刷記述データのバッファ管理を行なう。印刷バッファ１１０５は、印刷記述データを一時的に保存する。通信Ｉ／Ｆ１１０４は、伝送媒体１３００との接続インターフェースを提供する。
【００７６】
なお、印刷バッファ１１０５は、文書画像供給装置１１００に内蔵されている場合が示されているが、ネットワーク上の別の機器に存在する場合等であってもよく、存在位置は問わず適用可能である。
【００７７】
上記構成において、まず、ユーザがアプリケーション１１０１を用いて印刷データの編集等を行い印刷要求を出すと、アプリケーション１１０１から印刷に必要なデータが出力される。なお、このアプリケーション１１０１については、メーラや、ＷｅｂブラウザおよびＢＭＬブラウザ、デジタルスチルカメラのデータを編集可能なＤＳＣアルバムなどがある。変換部１１０２は、アプリケーション１１０１からのデータを、プリンタ側で解読可能な言語、例えばＸＨＴＭＬ形式に変換する。なお、印刷データが、既にＸＨＴＭＬ形式等であれば、特に変換は行なわなくてもよい。このように、変換された印刷記述データは、プリンタ制御部１１０３に渡され、印刷バッファ１１０５に格納される。その際、印刷記述データの中でリンクされている画像オブジェクトなどについては、変換部１１０２において画像形成装置１２００で印刷処理が可能な形式（例えば、ＪＰＥＧやＰＮＧ形式）のデータに変換されて、本来当該データが存在していたソース源から印刷バッファ１１０５にコピーされる。ここで、上記ソース源は、文書画像供給装置１１００の中に存在するか、外に存在するかを問わない。ここでも、既に画像形成装置１２００で印刷処理が可能な形式のデータである場合には、変換の必要はないことはもちろんである。
【００７８】
なお、この印刷バッファ１１０５として、文書画像供給装置１１００のメモリおよびＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を利用できる。例えば当該文書画像供給装置１１００がデジタルテレビである場合、当該デジタルテレビの機能上本来備えているメモリ等の記憶手段の一部を使用することができる。
【００７９】
画像形成装置１２００は、プリンタエンジン１２０１と、ラスタライザ１２０２と、インタプリタ１２０３と、通信Ｉ／Ｆ１２０４とから構成される。
【００８０】
プリンタエンジン１２０１は、印刷ドキュメントを記録紙等に印刷する。ラスタライザ１２０２は、印刷ドキュメントを小さな点の集まりとして表現されるラスタデータに展開する。インタプリタ１２０３は、印刷ドキュメントを構成する親サブデータである印刷記述データ（トップページ）の解析を行い、ラスタライザ１２０２が必要とする印刷ドキュメントを構成する子サブデータである画像オブジェクトの転送要求を文書画像供給装置１１００に出力する。通信Ｉ／Ｆ１２０４は、伝送媒体１３００を介して、上記印刷記述データや、画像オブジェクト、転送要求等を送受信する。
【００８１】
ここで、図６に示される印刷ドキュメント１４００を印刷しようとする場合、アプリケーション１１０１が扱うデータが、図７に示すプリンタ２００Ｐで処理可能な言語（ここではＸＨＴＭＬ形式いわゆるＭＬ形式）で記述された印刷記述データに変換され、アプリケーション１１０１が扱うデータにリンクされているオブジェクトが、表示可能な画像オブジェクト（ＪＰＥＧ、ＰＮＧ等）等の印刷オブジェクトに変換されて、それぞれ印刷バッファ１１０５に蓄積される。印刷データは、印刷記述データを表す場合もあり、印刷オブジェクトを表す場合もある。
【００８２】
図６の印刷ドキュメント１４００を例に挙げると、印刷ドキュメント１４００は、印刷記述データ１４０４と、３つの画像オブジェクト１４０１，４０２，４０３とから構成されており、画像オブジェクト１４０１と４０３とは同一の画像オブジェクトがリンクされている。印刷記述データ１４０４は、印刷ドキュメント１４００のトップページを表すサブデータ（親サブデータ）であり、画像形成装置１２００からの要求によって、文書画像供給装置１１００の通信Ｉ／Ｆ１１０４から画像形成装置１２００の通信Ｉ／Ｆ１２０４に転送される。印刷記述データ１４０４が送られてくると、インタプリタ１２０３は、印刷記述データ１４０４の解析を行い、ラスタライザ１２０２が必要とする画像オブジェクト１４０１，１４０２，１４０３の転送要求を文書画像供給装置１１００に出す。また、インタプリタ１２０３は、印刷記述データ１４０４の解析の際に、画像オブジェクト１４０１，１４０２，１４０３の印刷を完了するために再び取得される必要性があるか否かを判定する。
【００８３】
プリンタエンジン１２０１が、印刷ドキュメント１４００を表す印刷記述データ１４０４にしたがって印刷する場合、ラスタライザ１２０２は図８に示される矢印１４５１〜１４６１に沿って上から順にラスタライズを行う。矢印１４５１〜１４５４の領域をラスタライズする場合には、画像オブジェクト１４０１が必要になり、矢印１４５１をラスタライズする直前に、ラスタライザ１２０２が文書画像供給装置１１００へ画像オブジェクト１４０１の転送要求を出し、画像オブジェクト１４０１を受信する。次に、矢印１４５５〜１４５７の領域をラスタライズする場合には、画像オブジェクト１４０２が必要になり、矢印１４５５をラスタライズする直前に、ラスタライザ１２０２が文書画像供給装置１１００へ画像オブジェクト１４０２の転送要求を出し、画像オブジェクト１４０２を受信する。次に、矢印１４５８〜１４６１の領域をラスタライズする場合には、画像オブジェクト１４０３が必要になるが、画像オブジェクト１４０３が画像オブジェクト１４０１と同一のものであるので再度画像オブジェクト１４０１が必要になり、再度文書画像供給装置１１００に対して画像オブジェクト１４０１の転送要求を出し、画像オブジェクト１４０１を受信し、矢印１４５８〜１４６１の領域のラスタライズを開始することになる。
【００８４】
なお、画像オブジェクト１４０３のラスタライズ時には、画像形成装置１２００がキャッシュメモリを搭載し、前記キャッシュメモリに画像オブジェクト１４０１を保持している場合には、文書画像供給装置１１００に対して、画像オブジェクト１４０１の転送要求は不必要となることはもちろんである。
【００８５】
図６の印刷ドキュメント１４００では、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）について、画像形成装置１２００から文書画像供給装置１１００に対し２度転送を要求されることになるため、１度目の転送が終わった時点で画像オブジェクト１４０１を印刷バッファ１１０５から消去した場合、文書画像供給装置１１００は２度目の転送要求に対応できなくなるため、印刷バッファ１１０５から印刷データを消去するタイミングを画像形成装置１２００から文書画像供給装置１１００に対して転送完了の応答があった時点とすることはできない。
【００８６】
そのため、印刷ドキュメント１４００に関するオブジェクトに対して、画像形成装置１２００は図９に示すような処理手順によって、文書画像供給装置１１００に対してラスタライザ１２０２、またはインタプリタ１２０３が印刷オブジェクトの不要通知を行う。
【００８７】
まず、インタプリタ１２０３は、文書画像供給装置１１００から転送された印刷記述データ１４０４を解析する（Ｓ１１０１）。次いで、ラスタライザ１２０２は、ラスタライズの準備をし（Ｓ１１０２）、印刷記述データ１４０４にリンクされている印刷オブジェクトのデータが必要か否か判断する（Ｓ１１０３）。
【００８８】
印刷オブジェクトのデータが必要な場合は、ラスタライザ１２０２は、文書画像供給装置１１００に対して転送要求を行い（Ｓ１１０４）、印刷オブジェクトのデータを受信する（Ｓ１１０５）。続いて、この受信した印刷オブジェクトのデータをラスタライズする（Ｓ１１０６）。また、上記ステップＳ１１０３において、印刷オブジェクトの転送要求が必要でない場合は、次いで、ラスタライザ１２０２は、受信した印刷オブジェクトのデータをラスタライズする（Ｓ１１０６）。ラスタライズ（Ｓ１１０６）の後、印刷文書末（印刷ドキュメントのラスタライズ完了）かどうかの判断を行う（Ｓ１１０７）。印刷文書末でなく、引き続きラスタライズを行う場合、現時点までに受信完了した印刷オブジェクトの転送要求を再度行うことが必要になるか否か判断する（Ｓ１１０８）。受信完了した印刷オブジェクトの転送要求を再度行わない場合は、当該印刷オブジェクトが以降不要であることの通知を文書画像供給装置１１００に行う（Ｓ１１０９）。
【００８９】
なお、印刷オブジェクトの不要通知を行う際、不要な印刷オブジェクトを特定する情報としては、当該印刷オブジェクトのフルパス、当該オブジェクトの含まれる印刷ジョブＩＤ等の印刷ジョブを特定する情報と相対パスの組み合わせ、等が挙げられるが、印刷オブジェクトを特定できる情報であれば適用可能である。また、印刷オブジェクトの不要通知を行う時点は、再度転送要求しない印刷オブジェクトを不図示の印刷バッファに格納できた時点とすることもできる。
【００９０】
そして、ステップＳ１１０８における判断は、印刷データがトップページで以降参照されるか否かで行われ、印刷データがトップページで以降参照されない場合に、必要性がないと判断される。これにより、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、迅速に印刷バッファを解放することができる。
【００９１】
一方、文書画像供給装置１１００は、図１０に示すように印刷データ生成するステップＳ１２０１、印刷データを印刷バッファに格納するステップＳ１２０２、印刷ジョブを発行するステップＳ１２０３、画像形成装置からの受信情報が印刷データの転送要求か判断するステップＳ１２０４、受信情報が印刷データ転送要求でなかった場合、画像形成装置からの受信情報が印刷データ不要通知か判断するステップＳ１２０５、受信情報が印刷データの不要通知でなかった場合、画像形成装置からの受信情報が印刷ジョブ終了通知か判断するステップＳ１２０６、受信情報が印刷データの転送要求であった場合、印刷バッファ１１０５に格納された当該印刷データを当該画像形成装置１２００に転送するステップＳ１２０７、受信情報が印刷データの不要通知であった場合、印刷バッファ１１０５の当該印刷データ格納領域を開放するステップＳ１２０８を備えた手順で、不要通知を受信した文書画像供給装置１１００は、画像形成装置からの受信情報が印刷データ不要通知か判断するステップＳ１２０５と、受信情報が印刷データの不要通知であった場合、印刷バッファ１１０５の当該印刷データ格納領域を開放するステップＳ１２０８によって、印刷バッファ１１０５から当該印刷データを格納している領域を開放することができる。
【００９２】
図１１は、印刷ドキュメント１４００を印刷する場合において、文書画像供給装置１１００および画像形成装置１２００間で行われるシーケンス図である。
【００９３】
文書画像供給装置１１００のアプリケーション１１０１および変換部１１０２は、印刷ドキュメント１４００を構成する印刷記述データ１４０４、画像オブジェクト１４０１〜１４０３を作成し、印刷バッファ１１０５に格納する。アプリケーション１１０１は、プリンタ制御部１１０３に対して印刷を行なうよう依頼する。
【００９４】
プリンタ制御部１１０３は、印刷記述データ１４０４、画像オブジェクト１４０１〜１４０３を内部の管理データベースに登録と管理をする。そして、プリンタ制御部１１０３は、不図示のＰＢＲクライアントポートにＵＲＩプリントリクエストを画像形成装置１２００に発行するよう要求する。要求を受けたＰＢＲクライアントポートは、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に対してＵＲＩプリントリクエストを送る（Ｓ１５０１）。
【００９５】
ここで、ＵＲＩプリントリクエストにより画像形成装置１２００に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・文書画像供給装置１１００の印刷データが不要になった場合にプリンタステータス情報を提示する要求を送る。本実施の形態１ではＵＲＬで印刷記述データ１４０４を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信はＰＢＲクライアントポートが行なう。
【００９６】
ＵＲＩプリントリクエストを受けた画像形成装置１２００の不図示のジョブマネージャはジョブの発行を行い、発行したジョブに対応するジョブステータスレコードを作成しジョブ管理テーブルに登録する。登録後にＰＢＲデバイスポートによりＵＲＩプリントリクエストの応答を返す（Ｓ１５０２）。
【００９７】
そして、不図示のプリンタマネージャは、プリンタステータスが“ｄａｔａ ｎｏ ｎｅｅｄ”状態になったら文書画像供給装置１１００にプリンタ状態通知イベントを行なうように内部状態をセットする。
【００９８】
次にジョブマネージャは、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には印刷記述データ１４０４）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ１５０３）。
【００９９】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から印刷記述データ１４０４（ｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、画像形成装置１２００に返送する（Ｓ１５０４）。
【０１００】
印刷記述データ１４０４を受け取った画像形成装置１２００のＷｅｂクライアントは、ジョブマネージャ経由で、インタプリタ１２０３に受け渡し、インタプリタ１２０３は印刷記述データ１４０４にインタプリト処理を行い文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換し、不図示のレイアウト計算部に渡す。レイアウト計算部はＤＯＭツリーよりレイアウト計算を行なうとともに、印刷記述データ１４０４で参照されている画像オブジェクト１４０１〜１４０３を特定する。
【０１０１】
次に、レイアウト計算部は、まず画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｆｒｏｎｔ．ｊｐｇ）」を送信する（Ｓ１５０５）。
【０１０２】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５０６）。
【０１０３】
画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）を受信すると、受け取ったＷｅｂクライアントはレイアウト計算部に受け渡し、レイアウト計算部はラスタライザ１２０２でラスタライズ処理をさせてプリンタエンジン１２０１への出力データを作成させる。出力データの作成が終わるとラスタライザ１２０２はプリンタエンジン１２０１へそれを送信し、プリンタエンジン１２０１は画像オブジェクト１４０１を印刷する。
【０１０４】
画像オブジェクト１４０１の印刷が終わると、次に、レイアウト計算部は、画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｓｉｄｅ．ｊｐｇ）」を送信する（Ｓ１５０７）。なお、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）については、再度印刷に利用するので、オブジェクト（ｆｒｏｎｔ．ｊｐｇ）不要通知を送信することはない。
【０１０５】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５０７）。
【０１０６】
画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）を受信すると、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）の場合と同様の処理が行われ、プリンタエンジン１２０１は画像オブジェクト１４０２を印刷する。そして、画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）については、印刷に再度利用することがないので、ラスタライザ１２０２またはインタプリタ１２０３は、通信Ｉ／Ｆ１２０４を介してオブジェクト（ｓｉｄｅ．ｊｐｇ）不要通知を送信する（Ｓ１５０９）。
【０１０７】
なお、この不要通知は、プリンタステータスレコードのプリンタステータスフィールドにステータス値“ｄａｔａ ｎｏ ｎｅｅｄ”を記入したプリンタ状態通知イベントとして送信される。
【０１０８】
プリンタ状態通知イベントを受け取ると、プリンタ制御部１１０３は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷バッファ１１０５に格納されている画像オブジェクト１４０２を削除してよいと判断し、印刷バッファ１１０５の画像オブジェクト１４０２が格納されていたメモリ領域を解放（Ｓ１５０９）。
【０１０９】
オブジェクト不要要求の送信が終わると、次に、レイアウト計算部は、画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｆｒｏｎｔ．ｊｐｇ）」を送信する（Ｓ１５１１）。
【０１１０】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５１２）。
【０１１１】
画像オブジェクト１４０２（ｆｒｏｎｔ．ｊｐｇ）を受信すると、プリンタエンジン１２０１は画像オブジェクト１４０２を印刷する。そして、画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）については、印刷に再度利用することがないので、ラスタライザ１２０２またはインタプリタ１２０３は、通信Ｉ／Ｆ１２０４を介してオブジェクト（ｆｒｏｎｔ．ｊｐｇ）不要通知を送信する（Ｓ１５１３）。
【０１１２】
プリンタ状態通知イベントを受け取ると、プリンタ制御部１１０３は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷バッファ１１０５に格納されている画像オブジェクト１４０３、つまりｆｏｒｎ．ｊｐｇを削除してよいと判断し、印刷バッファ１１０５のｆｒｏｎｔ．ｊｐｇが格納されていたメモリ領域を解放（Ｓ１５１４）。そして、印刷記述データ１４０４についても、削除してよいと判断し、印刷記述データ１４０４が格納されていた領域を開放し、印刷データ転送サービスが不要になったので、Ｗｅｂサーバを停止する。
【０１１３】
その後、画像形成装置１２００のレイアウト計算部は、ラスタライザ１２０２を介してプリンタエンジン１２０１が残りを印刷し、印刷ドキュメント１４００の印刷を完了する。そして、インタプリタ１２０３またはラスタライザ１２０２は、ＰＢＲデバイスポートにジョブステータスフィールドに“ｃｏｍｐｌｅｔｅｄ”と書き込んだジョブステータスパケットを、文書画像供給装置１１００に送信するよう依頼し、ＰＢＲデバイスポートがジョブステータスパケットを文書画像供給装置１１００に送信する。このジョブステータスパケットを受け取った文書画像供給装置１１００は、画像形成装置１２００での印刷ドキュメント１４００の印刷の完了を知る。
【０１１４】
かかる構成によれば、印刷ドキュメントの印刷完了前に、画像形成装置１２００から文書画像供給装置１１００へ印刷データの不要通知を行うことにより、文書画像供給装置１１００は、オーバーヘッドを生じることなく、印刷バッファ１１０５の解放を迅速確実に行うことができ、バッファ容量が少ない場合でも効率よく印刷バッファ１１０５を利用し、印刷ジョブを完了することができる。
【０１１５】
また、文書画像供給装置１１００が携帯電話機のようなモバイル機器である場合、画像形成装置１２００から印刷完了通知を受け取る前に画像形成装置１２００との接続を切断することができるので、接続時間を短縮できるという効果も発揮でき、モバイル機器にとってきわめて有効である。
【０１１６】
（実施の形態２）
次いで、本発明の実施の形態２に係る印刷システムについて説明する。なお、この印刷システムの構成が実施の形態１における図５で示される印刷システム１と同等であるので、システム構成の図示が省略されている。
【０１１７】
ところで、上記実施の形態１においては、図６に示される印刷ドキュメント１４００、つまり同じオブジェクトを２回用いる場合を例に挙げて説明したが、Ｐｕｌｌ方式の印刷システムでは図１２に示される印刷ドキュメント１５００も考えられる。
【０１１８】
図１２の印刷ドキュメント１５００が、印刷記述データと、１つの画像オブジェクト１５０１で構成されているが、印刷バッファ１１０５のメモリ容量によっては図１３のように画像オブジェクト１５０１を画像オブジェクト１５１１〜画像オブジェクト１５１３のように分割し、画像オブジェクト１５１１〜画像オブジェクト１５１３を印刷を行う優先度の高いものから順に印刷バッファ１１０５に格納していく必要がある。
【０１１９】
図１４は、図１３の印刷ドキュメント１５００を表す印刷記述データ５１４の構成例を示す図である。
【０１２０】
図１３のような印刷ドキュメント１５００を印刷する場合は、実施の形態１で述べた文書画像供給装置１１００が不要通知を受信した際に印刷バッファ１１０５を解放することも可能であるが、図１０で示す手順において、文書画像供給装置１１００が印刷ジョブを発行するステップＳ１２０４の段階では、画像オブジェクト１５１１〜画像オブジェクト１５１３は、印刷ドキュメント１５００に１回ずつしか現れ無いことがわかっているので、毎回の不要通知の受信は不必要になる。このため、この実施の形態２に係る印刷システムでは、文書画像供給装置１１００および画像形成装置１２００は、１回しか利用しないことが予めわかっている場合には、受信済みの画像オブジェクトについては再度転送要求をしないで、不要通知を省略するという処理モードを備えている。
【０１２１】
つまり、このような場合は、画像形成装置１２００では、図１５に示すように、内部処理モードの変更ステップＳ１３０１で、文書画像供給装置１１００から受信した印刷ジョブの情報を用い、受信済みの画像オブジェクトは再度転送要求をしないという処理モードに変更し、不要通知を省略する。
【０１２２】
また、文書画像供給装置１１００では、図１６に示すように、印刷データ生成時に各印刷オブジェクトが一回ずつしか現れないことがアプリケーション１１０１、変換部１１０２およびプリンタ制御部１１０３のいずれかでわかった場合、このいずれかは、バッファ処理モードの変更ステップＳ１４０１で、印刷バッファの解放のタイミングを不要通知受信後から、印刷オブジェクトの転送要求を受信した時に変更し、画像形成装置１２００から印刷オブジェクト転送要求を受信した時に、印刷バッファ内に転送済みの印刷データが存在する場合に当該バッファ領域を解放する転送済み印刷データ解放ステップＳ１４０２を備える。
【０１２３】
図１７は、印刷ドキュメント１５００を印刷する場合において、文書画像供給装置１１００および画像形成装置１２００間で行われるシーケンス図である。なお、ここにおいても、図１１に示される印刷ドキュメント１４００を印刷する場合と対応する処理については同じステップ番号を付し、その説明を省略する。
【０１２４】
このような構成により、図１３のような構造の印刷ドキュメント１５００を印刷する場合に、実施の形態１よりも簡易、かつ、通信量の少ない方法で、オーバーヘッドを生じることなく、迅速かつ確実に印刷バッファ１１０５のメモリ解放制御を行うことができる。
【０１２５】
なお、本実施の形態２における文書画像供給装置１１００から画像形成装置１２００へのバッファ処理モード（画像形成装置１２００における内部処理モードの変更）の通知方法としては、印刷ジョブにバッファ処理モードを含める方法、文書画像供給装置１１００と画像形成装置１２００との間で印刷ジョブ実行のためのコネクションが確立された後にコマンドとして通知する方法、印刷記述データ、または印刷オブジェクト内に記述する方法等が挙げられる。
【０１２６】
また、上記実施の形態２では印刷データを解放してから（Ｓ１４０２，Ｓ１５２２，Ｓ１５２３，Ｓ１５２４）、次の印刷データを転送したが（Ｓ１２０７，Ｓ１５０６，Ｓ１５０８，Ｓ１５１２）、この逆の順序であってもよい。
【０１２７】
かかる構成によれば、文書画像供給装置１１００から画像形成装置１２００へ印刷バッファ１１０５の処理モード通知を行うことにより、文書画像供給装置１１００は印刷バッファ１１０５の解放を行うタイミングを知ることができ、バッファ容量が少ない場合でも効率よく印刷バッファ１１０５を利用し、印刷ジョブを完了することができる。
【０１２８】
（実施の形態３）
次いで、本発明の実施の形態３に係る印刷システムについて説明する。
【０１２９】
図１８は、本発明の実施の形態３に係る印刷システムの全体構成を示す図である。
この印刷システム２は、図１８に示されるように、ホスト装置２００１と、印刷装置２００２と、ホスト装置２００１と印刷装置２００２とを接続するネットワーク２００３とから構成される。ここで、本発明は通信および印刷データの管理に関するものであるので、図１８において通信機能の存在位置も示されている。
【０１３０】
ホスト装置２００１は、ＰＢＲクライアント機能２００４と、Ｗｅｂサーバ機能２００７とを備える。
【０１３１】
印刷装置２００２は、ＰＢＲデバイス機能２００５と、Ｗｅｂクライアント機能２００６とを備える。
【０１３２】
ＰＢＲクライアント機能２００４は、ＰｒｉｎｔＢｙＲｅｆｅｒｎｃｅ（ＰＢＲ）方式のクライアント通信機能を提供する。ＰＢＲデバイス機能２００５は、ＰＢＲクライアント機能２００４からの印刷指示や各種問い合わせ等への回答等のＰＢＲプリントのデバイス側通信機能を提供する。Ｗｅｂクライアント機能２００６は、ＰＢＲデバイス機能２００５からの印刷データのダウンロード要求を受けてネットワーク上のＷｅｂサーバにダウンロードを要求する。Ｗｅｂサーバ機能２００７は、印刷装置２００２のＷｅｂクライアント機能２００６からのダウンロード要求に答える。
【０１３３】
本実施の形態３におけるネットワークプリントシステムである印刷システム２は、２者システムであるので、ＰＢＲクライアント機能２００４とＷｅｂサーバ機能２００７とが１つのホスト装置２００１上に実装されている。
【０１３４】
図１９は、図１８に示したホスト装置２００１のハードウェア構成を示す内部ブロック図である。なお図１８と同一のものには同一の符号を示してある。
【０１３５】
図１９に示されるように、ホスト装置２００１は、ＣＰＵ２０１１と、ＲＯＭ２０１２と、ＲＡＭ２０１３と、ネットワークインターフェースカード（ＮＩＣ）２０１４と、ＣＲＴコントローラ（ＣＲＴＣ）２０１５と、ＣＲＴディスプレイ（ＣＲＴ）２０１６と、リモコン受光ユニット（ＲＭＲ）２０１７と、リムーバブルメディアコントローラ（ＲＭＣ）２０１８と、リムーバブルメディアアクセスデバイス（ＲＭＡ）２０１９と、これらを接続するシステムバス２０２０とから構成される。
【０１３６】
ＣＰＵ２０１１は、ＯＳや印刷アプリケーションプログラムをはじめとする各種アプリケーションプログラムや、ネットワークドライバ等の各種デバイスドライバプログラム等のソフトウエアを実行する。ＲＯＭ２０１２は、ＣＰＵ２０１１が実行するソフトウエアを格納する。ＲＡＭ２０１３は、システム起動時にＲＯＭに格納されたソフトウエアがコピーされ、またアプリケーションソフトやＯＳのワークエリアを提供する。ＮＩＣ２０１４は、ネットワーク２００３へのインターフェースを提供するネットワークインターフェースカードである。ＣＲＴＣ２０１５は、ＣＲＴ２０１６の表示を制御する。ＲＭＲ２０１７は、リモコンからの送信光を受光する。ＲＭＣ２０１８は、ＲＭＡ２０１９を制御する。ＲＭＡ２０１９は、ＳＤカード等のリムーバブルメディアにアクセスする。システムバス２０２０は、ＣＰＵ２０１１、ＲＯＭ２０１２、ＲＡＭ２０１３、ＮＩＣ２０１４、ＣＲＴＣ２０１５、ＲＭＲ２０１７、ＲＭＣ２０１８を互いに接続する。
【０１３７】
図２０は、図１８に示される印刷装置２００２のハードウェア構成を示す内部ブロック図である。なお図１８と同一のものには同一の符号を示してある。
【０１３８】
印刷装置２００２は、図２０に示されるように、コントローラ部２０３０と、印刷部２０３５と、操作パネル２０３８とを備える。コントローラ部２０３０は、ＣＰＵ２０３１と、ＲＯＭ２０３２と、システムバス２０３３と、印刷部インターフェース２０３４と、入力部２０３６とから構成される。
【０１３９】
コントローラ部２０３０のＣＰＵ２０３１は、ＲＯＭ２０３２のプログラム用ＲＯＭに記憶された制御プログラムに基づいてシステムバス２０３３に接続される各種のデバイスとのアクセスを統括的に制御し、印刷部インターフェース２０３４を介して接続される印刷部（プリントエンジン）２０３５に出力情報としての画像信号を出力する。
【０１４０】
また、ＲＯＭ２０３２のプログラム用ＲＯＭには、ＣＰＵ２０３１が実行可能な制御プログラム等が記憶される。さらに、ＲＯＭ２０３２のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ２０３２のデータ用ＲＯＭにはホスト装置２００１で使用される情報等が記憶される。
【０１４１】
ＣＰＵ２０３１は、入力部２０３６を介してホスト装置２００１との通信処理を実行し、印刷装置２００２内の情報等をホスト装置２００１に通知する。
【０１４２】
ＲＡＭ２０３７は、主としてＣＰＵ２０３１の主メモリ、ワークエリア等として機能する。なお、ＲＡＭ２０３７は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等として用いられる。
【０１４３】
また、操作パネル２０３８は、操作のためのスイッチおよびＬＥＤ表示器等が配されて構成される。ここで、ＮＶＲＡＭ（図示しない）に、操作パネル２０３８から入力されたプリンタモード設定情報をユーザ別、グループ別に記憶するようにしてもよい。
【０１４４】
図２１は、図１８に示されるホスト装置２００１の機能構成を示す図である。
ホスト装置２００１は、印刷アプリケーション２０４１と、プリントサービス２０４２と、ＰＢＲクライアントポート２０４３と、プリンタ情報管理部２０４４と、印刷データバッファ２０４５と、ＳＤデータ管理部２０４６と、Ｗｅｂサーバ２０４７とから構成される。
【０１４５】
印刷アプリケーション２０４１は、プリントサービス２０４２の印刷データ生成機能により印刷データを構成する親サブデータおよび子サブデータを作成し、印刷データバッファ２０４５に格納したり、プリントサービス２０４２に対して印刷を行なうよう依頼したりする。
【０１４６】
プリントサービス２０４２は、印刷アプリケーション２０４１に対して印刷データ生成サービス、ジョブ管理サービス、プリンタ管理サービス、印刷管理サービスを提供する。なお、本実施の形態３では、ＸＨＴＭＬ−Ｐｒｉｎｔで記述した印刷データの印刷について説明することにする。
【０１４７】
ここで、ＸＨＴＭＬ−Ｐｒｉｎｔというのは、ＸＭＬに基づいて書き直されたＨＴＭＬ言語に対してプリント処理の負荷低減等考慮したサブセット化および機能追加を施した言語であり、Ｐｒｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ（ＰＷＧ）において標準化されている。
【０１４８】
ＰＢＲクライアントポート２０４３は、ＰＢＲクライアント機能２００４を提供する。ＰＢＲクライアントポート２０４３は、ＵＲＩプリントリクエストの印刷装置２００２への送信およびその応答受信と、印刷装置２００２からのジョブ状態通知イベントおよびプリンタ状態通知イベントの受信とを行なう。プリンタ情報管理部２０４４は、プリンタの状態情報や、プリンタのネットワークアドレス情報を管理する。
【０１４９】
印刷データバッファ２０４５は、ＲＡＭ２０１３に作成され、親サブデータおよび子サブデータを一時的に格納する。ＳＤデータ管理部２０４６は、ＲＭＡ２０１９からアクセスされるＳＤメモリカード内のデータを管理する。Ｗｅｂサーバ２０４７は、Ｗｅｂサーバ機能２００７を提供する。そして、Ｗｅｂサーバ２０４７は、印刷装置２００２からのからのＰｕｌｌ要求を受け付け、Ｐｕｌｌ要求内のＵＲＬで指定されたデータを返送する。
【０１５０】
なお、印刷アプリケーション２０４１、プリントサービス２０４２、ＰＢＲクライアントポート２０４３、プリンタ情報管理部２０４４、ＳＤデータ管理部２０４６、Ｗｅｂサーバ２０４７は、ソフトウエアであり、このソフトウエアをＣＰＵ２０１１が実行するにより実現される。
【０１５１】
図２２は、図１８に示される印刷装置２００２におけるコントローラ部２０３０の機能構成を示す図である。
【０１５２】
コントローラ部２０３０は、ＰＢＲデバイスポート２０５１と、ジョブマネージャ２０５２と、ジョブ管理テーブル２０５３と、プリンタマネージャ２０５４と、プリンタステータスレコード２０５５と、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６と、レイアウト計算部２０５７と、ラスタライザ２０５８と、Ｗｅｂクライアント２０５９とを備える。
【０１５３】
ＰＢＲデバイスポート２０５１は、ＰＢＲデバイス機能２００５を提供する。そして、ＰＢＲデバイスポート２０５１は、ホスト装置２００１からのＵＲＩプリントリクエストの受信および応答の送信、ホスト装置２００１へのジョブ状態通知イベントおよびプリンタ状態通知イベントの送信を行なう。
【０１５４】
ジョブマネージャ２０５２は、ＰＢＲデバイスポート２０５１を介して受信したＵＲＩプリントリクエストの受付処理およびジョブ管理を行なう。ジョブ管理テーブル２０５３は、ジョブマネージャ２０５２がジョブ管理をする上で使用する。プリンタマネージャ２０５４は、印刷装置２００２の機器状態を管理する。プリンタステータスレコード２０５５は、印刷装置２００２の機器情報を格納する。
【０１５５】
ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は、ＸＨＴＭＬ−Ｐｒｉｎｔで記述された印刷データのパーシング処理および解釈処理を行う。レイアウト計算部２０５７は、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６の処理結果を受け、印刷出力のレイアウト情報を計算する。ラスタライザ２０５８は、レイアウト計算部２０５７の計算結果を受け、印刷部２０３５への出力データである画像信号を計算し、印刷部２０３５へ出力するとともにその管理を行なう。
【０１５６】
Ｗｅｂクライアント２０５９は、Ｗｅｂクライアント機能２００６を提供し、ホスト装置２００１へＰｕｌｌ要求を出し、データを受信する。
【０１５７】
なお、ＰＢＲデバイスポート２０５１、ジョブマネージャ２０５２、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６、レイアウト計算部２０５７、ラスタライザ２０５８、Ｗｅｂクライアント２０５９はソフトウエアであり、このソフトウエアをコントローラ部２０３０のＣＰＵ２０３１が実行することにより実現される。
【０１５８】
また、ジョブ管理テーブル２０５３およびプリンタステータスレコード２０５５は、コントローラ部２０３０のＲＡＭ２０３７に用意される。
【０１５９】
図２３は、図１８に示される印刷装置２００２のプリンタステータスを示す図である。
図２３に示される“Ｐａｐｅｒ ｅｍｐｔｙ”、”Ｐａｐｅｒ ｊａｍ”、”Ｉｎｋ ｅｍｐｔｙ”、”Ｏｕｔｐｕｔ ｔｒａｙ ｏｐｅｎ”、”Ｆａｔａｌ ｅｒｒｏｒ”については、プリンタで一般的に使用されているステータスである。
【０１６０】
“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”、”ｄａｔａ ｎｏ ｎｅｅｄ”は、本明細書中にて追加定義されたステータスである。“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、印刷装置２００２が親サブデータ（本実施の形態３ではＸＨＴＭＬ−Ｐｒｉｎｔデータが相当する）の処理を終え、ホスト装置２００１上の親サブデータが必要でなくなった状態になったことを示す。“Ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、印刷装置２００２が印刷データの処理を終え、ホスト装置２００１上の印刷データが必要でなくなった状態になったことを示す。印刷データが複数のサブデータより構成される場合には、全てのサブデータが必要でなくなった状態になるとこのステータスになる。
【０１６１】
図２４は、図２２に示されるプリンタステータスレコード２０５５のフィールド構成を示す図である。
【０１６２】
プリンタステータスレコード２０５５は、プリンタＩＤフィールド２０７１と、プリンタステータスフィールド２０７２とから構成される。プリンタＩＤフィールド２０７１には、印刷装置２００２を識別するためのプリンタＩＤ情報が格納される。プリンタステータスフィールド２０７２には、図２３で定義されるプリンタステータスが格納される。
【０１６３】
図２５は、印刷装置２００２のジョブのステータスの構成例を示す図である。
図２５に示される“Ｐｅｎｄｉｎｇ”、“Ｐｅｎｄｉｎｇ−ｈｅｌｄ”、“Ｐｒｏｃｅｓｓｉｎｇ”、“Ｐｒｏｃｅｓｓｉｎｇ−ｈｅｌｄ”、“Ｃａｎｃｅｌｅｄ”、“Ａｂｏｒｔｅｄ”“Ｃｏｍｐｌｅｔｅｄ”は、プリンタで一般的に使用されているステータスである。
【０１６４】
“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”および“Ｐｒｏｃｅｓｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”は、本明細書中にて追加定義されたステータスである。“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、ジョブが親サブデータ（本実施の形態３ではＸＨＴＭＬ−Ｐｒｉｎｔデータが相当する）の処理を終え、ホスト装置２００１上の親サブデータが必要でなくなった状態になったことを示す。“Ｐｒｏｃｅｓｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、ジョブが印刷データの処理を終え、ホスト装置２００１上の印刷データが必要でなくなった状態になったことを示す。印刷データが複数のサブデータより構成される場合、全てのサブデータが処理を終えた時点でこのステータスになる。
【０１６５】
図２６は、ジョブ管理テーブル２０５３に設けられるジョブステータスレコードの構成を示す図である。
【０１６６】
ジョブステータスレコード２０９１は、ジョブ管理テーブル２０５３にジョブの数に応じた数だけ設けられ、各ジョブごとにジョブステータス情報を格納するためのものであり、ジョブＩＤフィールド２０９２と、ジョブステータスフィールドに２０９３とから構成される。ジョブＩＤフィールド２０９２には、ジョブを識別するためのジョブＩＤ情報が格納される。ジョブステータスフィールド２０９３には、図２５で定義されるジョブステータスが格納される。
【０１６７】
図２７は、プリンタステータスパケットの構成を示す図である。
プリンタステータスパケット２１０１は、印刷装置２００２のプリントステータスを通信相手に知らせるためのものであり、ヘッダ部２１０２と、ヘッダ部２１０２とから構成される。ヘッダ部２１０２には、パケットヘッダ情報が格納される。プリンタステータスフィールド２１０３には、図２３で定義されるプリンタステータスが格納される。
【０１６８】
図２８は、ジョブステータスパケットの構成を示す図である。
ジョブステータスパケット２１１１は、印刷装置２００２におけるジョブステータスを通信相手に知らせるためのものであり、パケットヘッダ情報を格納するヘッダ部１１１２と、ジョブを識別するためのジョブＩＤ情報を格納するジョブＩＤフィールド１１１３と、ジョブステータス情報を格納するジョブステータスフィールド２１１４とから構成される。ジョブステータスフィールド２１１４には、図２５で定義されるジョブステータスが記載される。
【０１６９】
以下に、本実施の形態３における１つのアプリケーションについて説明する。
このアプリケーションでは、印刷データが複数のサブデータから構成され、それらのサブデータがホスト装置２００１の印刷データバッファ２０４５に格納されている。この場合、印刷データバッファ２０４５からの印刷データの削除は、印刷装置２００２が全サブデータの処理を終えて全サブデータが必要でなくなった時点で行なうのが妥当である。ホスト上の全サブデータが必要でなくなったことは、プリンタステータスとして印刷装置２００２が通知することとする。
【０１７０】
図２９は、本アプリケーションでの印刷データの構成を示す図である。
印刷データ２１２１は、複数のサブデータ、すなわち、親サブデータ２１２２と、子サブデータ（画像データ）２１２３ａ〜２１２３ｃとから構成される。親サブデータ２１２２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述されたデータである。子サブデータ２１２３ａ，２１２３ｂ，２１２３ｃは、親サブデータ２１２２から参照される子データに相当する画像データ（ｉｍｇ０１．ｊｐｇ，ｉｍｇ０２．ｊｐｇ，ｉｍｇ０３．ｊｐｇ）である。親サブデータ２１２２は印刷データ２１２１につき、１つ必ず存在する。子サブデータ２１２３ａ，１１２３ｂ，２１２３ｃは親サブデータ２１２２と同じ場所におかれており、親サブデータ２１２２で対応付けがなされている。
【０１７１】
図３０は、印刷データ２１２１の格納場所を示す図である。なお、図３０では、ＲＡＭ２０１３およびＲＭＡ２０１９が図示されている。
【０１７２】
ＲＡＭ２０１３には、印刷データバッファ２０４５と、印刷アプリケーションワークエリア２１３２とが用意される。アプリケーションワークエリア２１３２は、印刷アプリケーション２０４１が作業用エリアとして使用するエリアである。本実施の形態３では、印刷データバッファ２０４５には、親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃが全て格納される。ＳＤカードメモリ２１３３は、リムーバブルメディアアクセスデバイス（ＲＭＡ）２０１９に挿入されるカードメモリである。印刷データをＳＤカードメモリ２１３３に格納し、印刷データとすることができる。本実施の形態３では、ＳＤカードメモリ２１３３は使用しない。
【０１７３】
図３１は本実施の形態３におけるホスト装置２００１と印刷装置２００２との間の通信シーケンスを示す図であり、図３２は本実施の形態３におけるホスト装置２００１のデータ処理を示すフローチャートであり、図３３は本実施の形態３における印刷装置２００２のデータ処理を示すフローチャートである。
【０１７４】
図３１〜図３３により、ホスト装置２００１と印刷装置２００２間の通信シーケンスと、各々の内部動作を説明する。
【０１７５】
印刷アプリケーション２０４１は、プリントサービス２０４２の印刷データ生成機能により親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃを作成し、作成した親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃを印刷データバッファ２０４５に格納する。印刷アプリケーション２０４１は、プリントサービス２０４２に対して印刷を行なうよう依頼する。プリントサービス２０４２は、Ｗｅｂサーバが起動していないならばＷｅｂサーバ２０４７を起動する（Ｓ２５０２）。
【０１７６】
プリントサービス２０４２は、親サブデータ２１２２、子サブデータ２１２３ａ〜２１２３ｃを内部の管理データベースに登録し、管理する（Ｓ２５０３，Ｓ２５０４）。そして、プリントサービス２０４２は、ＰＢＲクライアントポート２０４３にＵＲＩプリントリクエストを印刷装置２００２に発行するよう要求する。
【０１７７】
ＰＢＲクライアントポート２０４３（ホスト装置２００１）は、印刷装置２００２に対してＵＲＩプリントリクエストを送る（Ｓ２４０１）。
【０１７８】
ここで、ＵＲＩプリントリクエストにより印刷装置２００２に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・ホスト装置の印刷データが不要になった場合にプリンタステータス情報を提示する要求（図３１において「ＵＲＩプリントリクエスト（ａｌｌ−ｄａｔａ：ＯＮ）」が相当）を送る。本実施の形態３ではＵＲＬで親サブデータ２１２２を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信はＰＢＲクライアントポート２０４３が行なう。
【０１７９】
ＵＲＩプリントリクエストを受けた印刷装置２００２のジョブマネージャ２０５２はジョブの発行を行い、発行したジョブに対応するジョブステータスレコード２０９１を作成し、ジョブ管理テーブル２０５３に登録する（Ｓ２６０２）。そして、登録後に、ＰＢＲデバイスポート２０５１は、ＵＲＩプリントリクエストに対する応答を返す（Ｓ２４０２）。プリンタマネージャ２０５４は、プリンタステータスが“ｄａｔａ ｎｏ ｎｅｅｄ”状態（図２３参照）になったら、ホスト装置２００１にプリンタ状態通知イベントを行なうように内部状態をセットする。
【０１８０】
次にジョブマネージャ２０５２は、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には、親サブデータ２１２２）をダウンロードするようＷｅｂクライアント２０５９に依頼し、Ｗｅｂクライアント２０５９は、ホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ２６０３，Ｓ２４０３）。ホスト装置２００１のＷｅｂサーバ２０４７は、Ｐｕｌｌ要求を受け付け（Ｓ２５０５）、印刷データバッファ２０４５から親サブデータ２１２２（ｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、印刷装置２００２に送信する（Ｓ２５０６，Ｓ２４０４）。
【０１８１】
Ｗｅｂクライアント２０５９は、ホスト装置２００１から親サブデータ２１２２を受け取ると（Ｓ２６０４）、ジョブマネージャ２０５２経由で、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６に受け渡し、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は親サブデータ２１２２にインタプリト処理を行い（Ｓ２６０５）、文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換し、レイアウト計算部２０５７に渡す。レイアウト計算部２０５７はＤＯＭツリーよりレイアウト計算を行なうとともに（Ｓ２６０６）、親サブデータ（ＸＭＬデータ）２１２２で参照されている子サブデータ（画像データ）２１２３ａ〜２１２３ｃを特定する（Ｓ２６０７）。なお、これ以降の処理においてはＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は登場しない。
【０１８２】
次に、レイアウト計算部２０５７は、まず子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）をダウンロードするようＷｅｂクライアント２０５９に依頼し（Ｓ２６０８）、Ｗｅｂクライアント２０５９はホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ｉｍｇ０１．ｊｐｇ）」を送信する（Ｓ２４０５）。
【０１８３】
Ｐｕｌｌ要求を受けたホスト装置２００１のＷｅｂサーバ２０４７は（Ｓ２５０５）、印刷データバッファ２０４５から子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）を取り出し、印刷装置２００２に送信する（Ｓ２５０６，Ｓ２４０６）。
【０１８４】
子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）を受信すると（Ｓ２６０９）、Ｗｅｂクライアント２０５９は受け取った子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）をレイアウト計算部２０５７に受け渡し、レイアウト計算部２０５７はラスタライザ２０５８にラスタライズ処理（Ｓ２６１０）をさせて、印刷部２０３５への出力データを作成させる。出力データの作成が終わると、ラスタライザ２０５８は印刷部２０３５へそれを送信し、印刷部２０３５は印刷する（Ｓ２６１１）。
【０１８５】
子サブデータ２１２３ｂ（ｉｍｇ０２．ｊｐｇ）および子サブデータ２１２３ｃ（ｉｍｇ０３．ｊｐｇ）についても、子サブデータ（画像データ）２１２３ａ（ｉｍｇ０１．ｊｐｇ）と同様の処理を行なう（Ｓ２４０７〜Ｓ２４１０，Ｓ２５０５〜Ｓ２５０６，Ｓ２６０８〜Ｓ２６１１）。
【０１８６】
レイアウト計算部２０５７は、子サブデータ（画像データ）２１２３ａ〜２１２３ｃのデータ処理が完了してホスト装置２００１上の子サブデータ２１２３ａ〜２１２３ｃが必要であるか判断し（Ｓ２６１２）、必要がない状態になったら、プリンタマネージャ２０５４にその旨を通知する。プリンタマネージャ２０５４は、プリンタステータスレコード２０５５のプリンタステータスフィールド２０７２にステータス値“ｄａｔａ ｎｏ ｎｅｅｄ”を記入し、プリンタ状態通知イベントをホスト装置２００１に送信するようジョブマネージャ２０５２経由でＰＢＲデバイスポート２０５１に依頼する（Ｓ２６１３）。つまり、印刷データ不要通知を依頼する。ＰＢＲデバイスポート２０５１は、プリンタステータスフィールド２１０３に“ｄａｔａ ｎｏ ｎｅｅｄ”をセットしたプリンタステータスパケット２１０１を作成し、ホスト装置２００１に送信する（Ｓ２４１１）。
【０１８７】
ＰＢＲクライアントポート２０４３は、プリンタ状態通知イベントを受け取ると、プリントサービス２０４２に通知し、プリントサービス２０４２は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷データバッファ２０４５に格納されている親サブデータ２１２２、子サブデータ２１２３ａ〜１１２３ｃを削除してよいと判断し（Ｓ２５０７）、データ自体を削除するか、印刷データバッファ２０４５をＲＡＭ２０１３から削除する（Ｓ２５０８，Ｓ２４１２）。ここで、印刷データ転送サービスが不要になったので、Ｗｅｂサーバ２０４７を停止する（Ｓ２５０９）。
【０１８８】
その後、レイアウト計算部２０５７は、ラスタライザ２０５８を介して印刷部２０３５が残りの印刷出力を行い（Ｓ２６１４）、印刷出力を完了し（Ｓ２６１５）、それを検知すると、ジョブマネージャ２０５２に通知し、ジョブマネージャ２０５２は、ＰＢＲデバイスポート２０５１にジョブステータスフィールドに“ｃｏｍｐｌｅｔｅｄ”と書き込んだジョブステータスパケット２１１１を、ホスト装置２００１に送信するよう依頼し、ＰＢＲデバイスポート２０５１がジョブステータスパケット２１１１をホスト装置２００１に送信する（Ｓ２４１３）。
【０１８９】
ジョブステータスパケット２１１１を受け取ったホスト装置２００１は、ここで印刷装置２００２での印刷出力の完了を知る（Ｓ２４１４）。
【０１９０】
以上のように、本実施の形態３では、印刷データが複数のサブデータよりなり、それらがホスト装置の印刷データバッファに格納され、印刷データバッファからの印刷データの削除は、印刷装置が全サブデータの処理を終えて全サブデータが必要でなくなった時点で、プリンタステータスとして印刷装置が通知している。これにより、ホスト装置は、自装置内の印刷データバッファから印刷データを削除し、メモリ等のシステムリソースを解放を、印刷完了時点でよりも早く行なえる。このため、プリンタエンジン処理機能が低かったり、大きな画像データを扱う場合にその効果はより大きい。
【０１９１】
（実施の形態４）
次いで、実施の形態４に係るアプリケーションについて説明する。
【０１９２】
本アプリケーションでは、印刷データが複数のサブデータよりなるが、親サブデータだけが印刷データバッファ２０４５に格納され、子サブデータは、リムバブルメモリカードメディア等の外部メモリに格納する場合に適用される。
【０１９３】
この場合、印刷データバッファ２０４５からの印刷データの削除は、印刷装置２００２が親サブデータの処理を終えて親サブデータが必要でなくなった時点で行なうのが妥当である。ホスト上の親サブデータが必要でなくなったことは、プリンタステータスとして印刷装置２００２が通知することとする。
【０１９４】
図３４は、本実施の形態４における印刷データの構成を示す図である。なお、図３４では、ＲＡＭ２０１３およびＲＭＡ２０１９が図示されている。
【０１９５】
印刷データ２１７１は、親サブデータ２１７２と、子サブデータ２１７３ａ〜２１７３ｃとから構成される。親サブデータ２１７２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述された親サブデータであり、印刷データ２１７１のサブデータである。子サブデータ２１７３ａ〜２１７３ｃは、親サブデータ２１７２から参照される子サブデータであり、印刷データ２１７１のサブデータである。子サブデータ２１７３ａ〜２１７３ｃは画像データである。子サブデータ２１７３ａ〜２１７３ｃは親サブデータ２１７２と異なる場所におかれており、親サブデータで対応付けがなされている。
【０１９６】
図３５は、印刷データの格納場所を示す図である。なお、図３０と同一のものは同じ番号を付し、説明を省略する。
【０１９７】
本実施の形態４では、親サブデータ２１７２のみが印刷データバッファ２０４５に格納され、子サブデータ２１７３ａ〜２１７３ｃはＳＤカードメモリ２１３３に格納される。この点で実施の形態３と異なる。
【０１９８】
図３６は、本実施の形態４におけるホスト装置２００１と印刷装置２００２との間の通信シーケンスを示す図である。なお、一部を除いては図３１と同じであり、同一の処理を示すステップについては同じ番号を付している。そして、ステップＳ２９０１と、ステップＳ２９０２が追加された処理である。
【０１９９】
また、図３７は、本実施の形態４におけるホスト装置２００１のデータ処理を示すフローチャートである。一部を除いては図３２と同じであり、同一の処理を示すステップについては同じ番号を付している。そして、ステップＳ３００１と、ステップＳ３００２が追加された処理である。
【０２００】
さらに、図３８は、本実施の形態４における印刷装置２００２のデータ処理を示すフローチャートである。一部を除いては図３３と同じであり、同一の処理を示すステップは同じ番号を付している。そして、ステップＳ３１０２が追加された処理である。
【０２０１】
次いで、図３６〜図３８により、ホスト装置２００１と印刷装置２００２間の通信シーケンスと、各々の内部動作を説明する。なお、図３１〜図３３と同じステップ番号で同じ処理を示すものについては、本実施の形態４に必要なものについて説明するにとどめる。
【０２０２】
ＰＢＲクライアントポート２０４３（ホスト装置２００１）は、印刷装置２００２に対してＵＲＩプリントリクエストを送る（Ｓ２４０１）。
【０２０３】
ここで、ＵＲＩプリントリクエストにより印刷装置２００２に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・ホスト装置の親サブデータが不要になった場合にプリンタステータス情報を提示する要求（図３６において「ＵＲＩプリントリクエスト（ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ：ＯＮ）」が相当）を送る（Ｓ２４０１）。本実施の形態４ではＵＲＬで親サブデータ２１２２を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信は、ＰＢＲクライアントポート２０４３が行なう。
【０２０４】
ＵＲＩプリントリクエストを受けた印刷装置２００２のジョブマネージャ２０５２は、ジョブの発行を行い、発行したジョブに対応するジョブステータスレコード２０９１を作成し、ジョブ管理テーブル２０５３に登録する（Ｓ２６０２）。登録後に、ＰＢＲデバイスポート２０５１は、ＵＲＩプリントリクエストの応答を返す（Ｓ２４０２）。
【０２０５】
プリンタマネージャ２０５４は、プリンタステータスが“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”状態（図２３参照）になったら、ホスト装置２００１にプリンタ状態通知イベントを行なうように内部状態をセットする。
【０２０６】
次にジョブマネージャ２０５２は、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には親サブデータ２１７２）をダウンロードするようＷｅｂクライアント２０５９に依頼し、Ｗｅｂクライアント２０５９は、ホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ＳＤｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ２６０３，Ｓ２４０３）。
【０２０７】
ホスト装置２００１のＷｅｂサーバ２０４７は、Ｐｕｌｌ要求を受け付け（Ｓ２５０５）、印刷データバッファ２０４５から親サブデータ２１２２（ＳＤｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、印刷装置２００２に返送する（Ｓ２５０６，Ｓ２４０４）。
【０２０８】
Ｗｅｂクライアント２０５９は、ホスト装置２００１から親サブデータ２１７２を受け取ると（Ｓ２６０４）、ジョブマネージャ２０５２経由で、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６に受け渡し、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は、親サブデータ２１２２にインタプリト処理を行い（Ｓ２６０５）、文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換する。
【０２０９】
ここで、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリンタは、親サブデータ２１７２の処理が完了し、それ以降ホスト装置２００１上の親サブデータ２１７２を必要としないか判定し、必要がないと判定すると、プリンタマネージャ２０５４にその旨通知する。
【０２１０】
プリンタマネージャ２０５４は、プリンタステータスレコード２０５５のプリンタステータスフィールド２０７２にステータス値“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”を記入し、プリンタ状態通知イベントをホスト装置２００１に送信するようジョブマネージャ２０５２経由でＰＢＲデバイスポート２０５１に依頼する。
【０２１１】
ＰＢＲデバイスポート２０５１は、プリンタステータスフィールド２１０３に“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”をセットしたプリンタステータスパケット２１０１を作成し、ホスト装置２００１に送信する（Ｓ２９０１）。
【０２１２】
ＰＢＲクライアントポート２０４３は、プリンタ状態通知イベントを受け取るとプリントサービス２０４２に通知し、プリントサービス２０４２は、“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷データバッファ２０４５に格納されている親サブデータ２１７２を削除してよいと判断し（Ｓ３００１）、親サブデータ２１７２自体を削除するか、印刷データバッファ２０４５自体をＲＡＭ２０１３から削除する（Ｓ３００２，Ｓ２９０２）。
【０２１３】
以後の処理は、“ａｌｌ ｄａｔａ ｎｏ ｎｅｅｄ”というプリントステータスの通知に関する処理がないという点を除けば実施の形態３と同じである。
【０２１４】
以上のように、上記本実施の形態４では、印刷データが複数のサブデータよりなり、そのうち親サブデータが印刷データバッファに格納され、それ以外の子サブデータはリムバブルメモリカードメディア等の外部メモリに格納され、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で、プリンタステータスでその旨ホスト装置に通知し、通知を受けたホスト装置は親サブデータを削除する。
【０２１５】
これにより、ホスト装置は、印刷装置で早期に処理される親サブデータの処理完了のタイミングで、親サブデータの不要を知ることができるので実施の形態３と比べて、より早いタイミングで親サブデータを削除し印刷データバッファの解放ができる。親サブデータを早期に削除することのメリットであるが、印刷アプリケーションによっては、親サブデータがかなり大きくなる場合がある。この場合、親サブデータの格納のためにＲＡＭの空き領域が少なくなり、そのようなメモリが逼迫した状態では、印刷アプリケーションを終了して、別のアプリケーションを起動させようとしても、よりメモリを必要とするアプリケーションは起動できなかったり、起動できても動作が遅くなったりすることがある。この場合、本実施の形態４では、親サブデータの削除とメモリの解放を早期に行なえるので、メモリ逼迫状態からの復帰を早めることができ、その有用性は高い。
【０２１６】
（実施の形態５）
次いで、実施の形態５に係る他のアプリケーションについて説明する。
【０２１７】
本アプリケーションでは、印刷データが複数のサブデータよりなるが、親サブデータだけがホスト装置の印刷データバッファに格納され、子サブデータは、他のサーバ装置上に格納される場合である。この場合、ホスト装置の印刷データバッファからの印刷データの削除は、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で行なうのが妥当であり、実施の形態４と同じである。ホスト上の親サブデータが必要でなくなったことは、プリンタステータスとして印刷装置が通知することとする。
【０２１８】
図３９は、本実施形態５におけるサーバ装置、ホスト装置および印刷装置により構成されるネットワークプリントシステムのシステム構成図である。なお、図３９において、図１８と同一のものは同一の番号を付し、説明は省略する。
【０２１９】
図３９に示されるように、印刷システム３は、ホスト装置２００１と、印刷装置２００２にサーバ装置２００８を加えた３者間におけるネットワークプリントシステムである。ただし、印刷データはホスト装置２００１と、サーバ装置２００８上に分散しておかれるので、Ｗｅｂサーバ機能２００７はサーバ装置２００８だけでなく、ホスト装置２００１にも存在する。
【０２２０】
図４０は、本実施の形態５における印刷データの構成を示す図である。
印刷データ２２３１は、親サブデータ２２３２と、子サブデータ２２３３ａ〜２２３３ｃとから構成される。親サブデータ２２３２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述された親サブデータであり、印刷データ２２３１のサブデータである。子サブデータ２２３３ａ〜２２３３ｃは、親サブデータ２２３２から参照される子サブデータであり、印刷データ２２３１のサブデータである。子サブデータ２２３３ａ〜２２３３ｃは画像データである。子サブデータ２２３３ａ〜２２３３ｃは、サーバ装置２００８上におかれ、親サブデータで対応付けがなされている。
【０２２１】
図４１は、印刷データの格納場所を示す図である。なお、図３０と同一のものについては、同じ番号を付し、説明を省略する。
【０２２２】
図４１に示されるように、サーバ装置２００８は、ハードディスク装置３４０１を備える。ハードディスク装置３４０１は、印刷データ等を格納するハードディスク装置である。本実施の形態５では親サブデータ２２３２のみがホスト装置上の印刷データバッファ２０４５に格納され、子サブデータ２２３３ａ〜２２３３ｃは、サーバ装置２００８上のハードディスク装置３４０１に格納される。この点で実施の形態４と異なる。
【０２２３】
図４２は、本実施の形態５におけるホスト装置２００１、印刷装置２００２、サーバ装置２００８との間の通信シーケンスを示す。なお、図３１、図３６と略同じであり、同一の処理を示すステップについては同じ番号を付している。また、実施の形態４と本実施の形態５との違いを、図３６と図４２を比較しながら説明する。
【０２２４】
図３６では、ステップＳ２４０３およびＳ２４０４において印刷装置２００２はＳＤｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐをＰｕｌｌ要求しているのに対して、図４２ではＳＶｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐに対してＰｕｌｌ要求をしているが、印刷装置２００２での内部処理は、Ｐｕｌｌ要求対象親サブデータが異なるだけで、実施の形態４と同じである。
【０２２５】
図３６では、ステップＳ２４０５およびＳ２４０６においてＳＤｉｍｇ０１．ｊｐｇをホスト装置２００１にＰｕｌｌ要求しているのに対して、図４２ではサーバ装置２００８に対して、ＳＶｉｍｇ０１．ｊｐｇのＰｕｌｌ要求をしている。なお、ステップＳ２４０５での印刷装置２００２での内部処理は、Ｐｕｌｌするデータとアクセス先装置が異なる点を除けば、実施の形態４と同じである。また、ステップＳ２４０６でのサーバ装置２００８での内部処理は、取り扱う子サブデータが違う点を除けば、実施の形態４におけるホスト装置２００１での内部処理と同様である。
【０２２６】
ステップＳ２４０７〜Ｓ２４１０についても同様である。印刷データバッファ２０４５から親サブデータ２２３２を削除し、印刷データバッファを開放するタイミングも実施の形態４と同じである。
【０２２７】
以上のように、本実施の形態５では、印刷データが複数のサブデータよりなり、そのうち親サブデータがホスト装置の印刷データバッファに格納され、それ以外の子サブデータはサーバ装置に格納され、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で、プリンタステータスでその旨ホスト装置に通知し、通知を受けたホスト装置は親サブデータを削除する。
【０２２８】
これにより、ホスト装置は、印刷装置で早期に処理される親サブデータの処理完了のタイミングで、親サブデータの不要を知ることができるので実施の形態３と比べて、より早いタイミングで親サブデータを削除し印刷データバッファの解放ができる。
【０２２９】
また、実施の形態４とは異なり、親サブデータ不要の通知を受けた後は、データ通信は印刷装置とサーバ装置との間でのみ行なわれるのでホスト装置の負荷はなく、またホスト装置を停止しても印刷処理を継続することができる。本実施の形態５も、実施の形態４と同様に親サブデータがかなり大きくなる場合に、親サブデータの削除とメモリの解放を早期に行なえるので、メモリ逼迫状態からの復帰を早めることができ、その有用性は高い。
【０２３０】
なお、本実施の形態３〜５においてはプリンタステータスにより、印刷装置がホスト装置上の印刷データ全体または親サブデータが不要になったことを通知しているが、ジョブステータスの通知により行なってもよい。印刷データ全体に関するジョブステータスは図２５で示される“Ｐｒｏｃｅｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”であり、親データのみに関するステータスは、“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”である。各々のジョブステータス値がジョブステータスフィールド２１１４にセットされて送られる。
【０２３１】
また、本実施の形態３〜５においては、印刷装置がホスト装置上の印刷データ全体または親サブデータが不要になったことを通知しているが、ホスト装置からの問い合わせに対して、プリンタステータスまたはジョブステータスを回答することにしてもよい。
【０２３２】
また、本実施の形態３，４においては、印刷装置とホスト装置はＬＡＮを介してネットワーク接続されているが、ＵＳＢ等により１対１に接続しても構わない。
【０２３３】
また、上記実施の形態１〜５では、１つのジョブにおいて画像オブジェクトが３つである場合（実施の形態１）などを例に挙げて説明したが、本発明では画像オブジェクトが３つのみに限定されるのではなく、複数である場合に適用されることはいうまでもない。
【０２３４】
また、上記実施の形態１〜５では、１つのジョブにおける印刷データの処理について説明したが、複数のジョブにおける印刷データの処理について、本願発明を適用することができるのはいうまでもない。
【０２３５】
すなわち、印刷指示装置（ホスト装置、文書画像供給装置）がジョブごとの印刷データを印刷バッファに保持する場合、再び印刷装置（画像形成装置、プリンタ）によって取得される必要性がないジョブの印刷データを、一連のジョブの印刷が完了する前に、印刷バッファから削除するようにしてもよい。この場合、例えば、印刷指示装置側では印刷装置に指示する複数のジョブを管理し、印刷装置側ではこれから印刷するジョブの内、既に読み込み済みのジョブを読み込み済みリストとして管理しておけばよい。なお、この読み込み済みリストは、対応するデータが以降、再読込不要であるものを管理するためのリストであることを意味する。
【０２３６】
より詳しくは、図４３に示されるように印刷指示装置（ホスト装置、文書画像供給装置）は、６個のプリントジョブ（Ｊｏｂ５〜Ｊｏｂ１０）のデータを印刷データバッファに格納し、ジョブリストで各ジョブのＩＤ、５，６，７，８，９，１０を管理しているものとする。そして、プリンタは、図４４に示されるように、Ｊｏｂ５，６，７のデータを既に取り込み、Ｊｏｂ８のデータの取り込み中で、Ｊｏｂ５のデータの印刷中であるものとする。この場合、プリンタは、Ｊｏｂ５，６，７のＩＤ５，６，７を読み込み済みリストとして管理しておけば、読み込み済みリストとしてＩＤ５，６，７をプリントステータスとして印刷指示装置に送ることにより、印刷指示装置はプリントステータスからＪｏｂ５，６，７のデータは不要であると判断することができ、Ｊｏｂ５，６，７のデータを印刷データバッファから素早く削除し、印刷データバッファを解放することができる。つまり、複数のジョブについても、本願発明を適用することができる。
【０２３７】
また、上記実施の形態では、子サブデータが画像データである場合、つまりＨＴＭＬが１つの場合について説明したが、子サブデータがＨＴＭＬであってもよく、画像データが子サブデータであるＨＴＭＬにリンクされる孫サブデータであってもよい。つまり親サブデータと子サブデータと、画像データをリンクするようにした場合についても、本願発明を適用することができる。
【産業上の利用可能性】
【０２３８】
本発明に係る印刷装置は、Ｐｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式で、かつホスト装置が印刷データのサーバ機能を持つ場合のプリンタ等に適用でき、本発明に係る印刷指示装置（ホスト装置、文書画像供給装置）は、自装置が印刷データのサーバ機能を持つ場合のＰｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式でのプリントホストとなるデジタルテレビや、セットトップボックス（ＳＴＢ）等に適用できる。
【技術分野】
【０００１】
本発明は印刷装置、印刷指示装置および印刷システムに関し、特に印刷データを一時的に格納する印刷バッファのメモリ解放制御技術に関する。
【背景技術】
【０００２】
従来より、ネットワークで接続された印刷システムにおいて、印刷装置（以下、「画像形成装置」、「プリンタ」とも記す。）から印刷指示装置（以下、「文書画像供給装置」、「ホスト装置」とも記す。）に対して印刷データの転送を要求するＰｕｌｌ方式の印刷システムでは、文書画像供給装置が備える印刷バッファに印刷データを蓄積し、画像形成装置が印刷を実行している際に、必要になった印刷データをその都度、前記文書画像供給装置に対し、転送要求を行い、必要な印刷データを受信し、印刷している。
【０００３】
この印刷の処理中に、文書画像供給装置は印刷処理に不要になったデータを随時消去していき、印刷バッファを有効に利用することが必要となる。
【０００４】
従来から行われている印刷バッファのメモリ解放制御方法としては、画像形成装置が文書画像供給装置に印刷データの転送の要求を行い、受信が完了した際に行う転送応答を文書画像供給装置が受信した際に当該印刷データを印刷バッファから消去するか、または、ＰＵＳＨ方式の印刷システムのように、文書画像供給装置が印刷データの転送が完了したと判断した場合に、印刷バッファから当該印刷データを消去する方法がある。
【０００５】
例えば、図１に示されるように印刷データをバンド処理する場合、第１バンド、第２バンド、…の印刷データを図２に示されるラスタメモリＡ，Ｂに交互に格納し、第１バンドの印刷データの転送が完了すると、第１バンドの印刷データを削除し、第３バンドの印刷データをラスタメモリＡに格納し、第２バンドの印刷データの転送が完了すると、第２バンドの印刷データを削除し、第４バンドの印刷データをラスタメモリＢに格納する処理を繰り返し行うようにしてしている。図３は、バンドデータをラスタメモリに格納し、転送を行い、消去するタイミングを表す図である。
【０００６】
このようなＰＵＳＨ方式の印刷システムにおいては、文書画像供給装置が画像形成装置に対して印刷させたい印刷データを送信するため、文書画像供給装置が印刷データ転送完了後に当該印刷データを印刷バッファ上から消去することに問題はなかった。
【０００７】
ところで、オフィスでのネットワーク化の普及に伴いネットワーク対応のプリンタが広く普及している。今後は、家庭においてもネットワーク化が進む方向にあり、家庭でのネットワーク対応プリンタも普及してゆくと予想される。なお、ネットワークプリントにおけるネットワークとしては、従来からのＬＡＮ（Ｌｏｃａｌ ＡｒｅａＮｅｔｗｏｒｋ）だけでなく、インターネットも対象になりつつある。
【０００８】
ここで、ネットワークプリント方式の１つに、Ｐｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式（本明細書中、以下、ＰＢＲ方式と呼ぶ）がある。ＰＢＲ方式では、ホスト装置が印刷データのサーバともなり、ホストがプリンタにＵＲＬを指定した印刷指示を出し、印刷指示を受け取ったプリンタはＵＲＬで指定されるＷｅｂサーバからデータを取得して印刷する。
【０００９】
ここで、ＵＲＬでインターネット上のデータを指定すれば、インターネット上のデータをも印刷することが可能である。
【００１０】
ＰＢＲ方式では、インターネット接続機能を持たないホストからであっても、インターネット上のデータを印刷可能であることが大きな優位点である。安価なホストでは、大きなコストアップ要因となるインターネット接続機能を搭載するのは困難であるが、そのようなホストからでも、インターネット上データの印刷機能を実現できるので、今後広く普及することが予想される。
【００１１】
ここで、インターネット・プリンティングプロトコルの代表的なものとしてＲＦＣで規定されており標準プロトコルとなっているＩｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ（本明細書中、以下、ＩＰＰと呼ぶ）があるが、ＩＰＰにおいてもＰＢＲ方式に準じたものとしてＰｒｉｎｔ−ＵＲＩリクエストが規定されている。この動作であるが、ホストがプリンタにＵＲＬを指定した“Ｐｒｉｎｔ−ＵＲＩリクエスト”を送ると、それを受け取ったプリンタが、ＵＲＬ指定先のＷｅｂサーバ上のデータを取得して印刷を行なう。このＰｒｉｎｔ−ＵＲＩ機能により、世界中のＷｅｂサーバ上のデータを印刷することを実現できる。
【００１２】
さて、ＰＢＲ方式対応プリンタでの印刷データとしては、ＰｏｓｔＳｃｒｉｐｔに代表されるページ記述言語で書かれたデータ、ＰＣＬに代表されるプリンタ制御言語で書かれたデータ、ＪＰＥＧ圧縮された画像データ等の他にＨＴＭＬに代表されるマークアップ言語で書かれたデータ（以下、マークアップデータと呼ぶ）等がある。
【００１３】
ここで、マークアップデータでは、データ内部から別のデータを参照する記述が可能であるが、ＰＢＲ方式で印刷データとしてマークアップデータを指定して印刷指示をする場合、指定したマークアップデータが印刷対象となりうるデータを参照しているならば、マークアップデータだけでなく参照データも印刷対象となる。
【００１４】
さて、ＰＢＲ方式を対応するプリントシステムにおいては、クライアント、プリンタ、Ｗｅｂサーバの３者が登場するが、各々を別々の装置に存在させなくてもよい。クライアントとＷｅｂサーバを１つのホスト装置に実装し、プリンタ装置と接続させるシステム構成も可能である。システム構成上、装置が２つしか存在しないので、このシステム構成を、本明細書中で以後、２者システムと呼ぶことにする。２者システムでは、ホスト装置とプリンタ装置よりなる通常のＬＡＮ対応プリントシステムと同じ構成になるが、ＰＢＲ方式でインターネットプリンティングも可能なプリンタ装置をそのままＬＡＮ対応プリンタとして使用できることになる。
【００１５】
さて、従来技術として、ＰＢＲ方式での２者システムの例がある（例えば、特許文献１を参照）。特許文献１において、ＰＢＲのプロトコルとして、ＩＰＰでのＰｒｉｎｔ−ＵＲＩリクエストで実現している。
【００１６】
この従来例の２者システムにおいては、ホスト装置はＰｒｉｎｔＵＲＩリクエストで自装置内の印刷データを指定するＵＲＬをプリンタに送る。プリンタはＵＲＬより印刷データがネットワーク上のホスト装置にあることを特定し、ホスト装置のＷｅｂサーバにアクセスして指定の印刷データをダウンロードして印刷する。
【００１７】
図４は、この従来例におけるホスト装置におけるデータ処理手順動作を示すフローチャートである（特許文献１の図７参照）。なお、以下では、印刷データのデータ転送と削除タイミングに関わる部分について重点的に説明し、それ以外については簡略説明にとどめる。
【００１８】
まず、ステップＳ９００１において、印刷データ転送のためのＷｅｂサーバが起動していない場合には、Ｗｅｂサーバを起動する（Ｓ９００２）。
【００１９】
次に、印刷データの登録が行なわれ（Ｓ９００３）、印刷データの管理を行なう（Ｓ９００４）。
【００２０】
次に、データに対するＰｕｌｌ要求（ダウンロード要求）をプリンタから受けると、それが印刷データに対する一番目のＰｕｌｌ要求の場合かを判断する（Ｓ９００５）。
【００２１】
一番目のＰｕｌｌ要求の場合は、Ｐｕｌｌ要求を受け付けて（Ｓ９００６）、印刷データをプリンタに返信する（Ｓ９００７）。
【００２２】
そして、印刷データの転送が完了したかを判断して（Ｓ９００８）、印刷データの転送が完了したと判断した場合には、ステップＳ９００９に移行して当該印刷データを自装置内から削除し、Ｗｅｂサーバを停止し（Ｓ９０１０）、処理を終了する（Ｓ９０１１）。
【００２３】
さて、ＰＢＲ方式では、Ｗｅｂサーバ上の印刷データの削除タイミングについては一般的に規定がない。実装に依存するがＩＰＰにおいても同様である。
【００２４】
一般的にＰＢＲの２者システムでは、ホスト装置はプリンタが印刷出力が完了したことを確認後に自装置内の印刷データを削除する。印刷出力が完了したので印刷データが不要なのは自明だからである。
【００２５】
ここで、印刷エンジンでの印刷処理には印刷データ転送等の他の処理に比べて多くの時間が必要である。印刷出力完了まで印刷データの保管をしておくとなると、ホスト装置は、長時間、印刷データ格納のための印刷データバッファ（ＲＡＭ等のワークメモリ）を解放できず、システムリソースの効率的かつ有効な活用が困難である。
【００２６】
これに対して、この従来例では、プリンタが１度ダウンロードした印刷データの再ダウンロードをしないことを前提とし、ホスト装置は印刷データの送信が完了した時点で印刷データは不要と判断して削除を行なっている。
【００２７】
この従来例においては、印刷データの送信が印刷出力の完了よりもかなり早く終了するので、印刷データを格納する印刷データバッファの解放をより早くでき、ホスト装置のシステムリソースを早いタイミングで印刷以外の処理に提供でき効率的かつ有効な活用が図れることを目的としている。
【特許文献１】特開２００２−２０２８７４号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかしながら、従来からあるＰｕｌｌ方式の印刷システムのメモリ解放制御方法では、例えば、インターネット上のＨＴＭＬコンテンツのようなドキュメントを印刷ドキュメントとする場合、１つの印刷ドキュメントの中で同一の画像オブジェクトが複数回用いられることが多々ある。
【００２９】
この場合、文書画像供給装置から画像形成装置に一度目の画像データの転送が完了しても、画像形成装置から文書画像供給装置に再度同一の画像の転送の要求がされることになる。従来のＰｕｌｌ方式のメモリ解放制御方法では、一度目の転送完了時に当該画像データは削除されており、二度目以降の転送要求には対応できないことになる。
【００３０】
このような場合に、従来のＰｕｌｌ方式の印刷システムでは、２度以上転送要求のある印刷オブジェクトは、印刷バッファ上から消去されているため、文書画像供給装置は画像形成装置からの印刷オブジェクトの転送要求に対して、再度印刷オブジェクトの生成を行う負荷をおうか、または画像形成装置からの印刷オブジェクトの転送要求に対応することができない。
【００３１】
印刷データが再度要求される可能性のあるＰｕｌｌ方式の印刷システムでも、印刷ジョブが終了すると印刷バッファは解放できるため、最小でも１つの印刷ジョブで必要な印刷データを全て格納できるだけの印刷バッファが確保できれば問題ないが、印刷バッファの容量が十分でない場合、印刷データの転送後も新たな印刷データをバッファに格納できない状況になり、印刷データの転送を継続することが不可能となる。
【００３２】
つまり、従来の技術では、印刷データを早く削除しすぎた結果、印刷データの再要求があった場合には印刷データを再度生成して印刷バッファに格納しなければならず、印刷データの再要求があった場合におけるオーバーヘッドが大きいという問題がある。
【００３３】
さて、ＰＢＲ方式では、プリンタが印刷データをダウンロードしたからといって、再ダウンロード要求をしないという保証はない。これは２者システムでのＰＢＲにおいても同様である。再ダウンロードするか否かはプリンタの実装に依存する。
【００３４】
ＰＢＲ方式において、再ダウンロードをうまく活用すれば、少ないシステムリソース（ＲＡＭ等）しか持たない安価なプリンタであっても高機能を実現することができる。
【００３５】
以下に、一例を示す。画像データをプリンタで回転させて印刷する場合である。インクジェットプリンタに代表されるラインプリンタでは、印刷データバッファにはプリンタヘッド走査に必要な分だけの印刷データを格納して処理する構成をとれるので、印刷データバッファを実現するメモリサイズを小さくでき、これにより低価格を実現している。
【００３６】
ここで、ＰＢＲ方式でプリントするラインプリンタで画像の回転印刷機能を実現することを考える。最も簡単な方法は画像データ全体をダウンロードし、画像データ全体をプリンタのプリンタバッファに格納し、それを回転したうえで印刷する方法である。この方法ならばダウンロードは１回で十分であり、再ダウンロードは必要ない。しかしながら、通常画像データはサイズがかなり大きく、その全体を格納するためには大きなサイズのプリンタバッファメモリが必要となるため、コストアップにつながり安価なプリンタとできない。
【００３７】
これに対して、ダウンロードした画像データのうち、プリンタヘッド走査において必要とされまた小さなプリンタバッファに格納できるだけを回転させてプリンタバッファに格納することで回転印刷をする方法がある。この方法においては、回転イメージは１回で作成できず、画像データの「ダウンロード・回転」を繰り返すことで回転させて印刷を行なうことで画像回転印刷を実現する。この方法の場合、同じ印刷データに対して複数回のダウンロードが必要であるが、小さな印刷データバッファしかない安価なラインプリンタであっても画像回転のような高機能を実現することができる。
【００３８】
このように、ＰＢＲ方式のネットワークプリンタに印刷データの再ダウンロードをするならば、安価な構成で高機能を実現できる。
【００３９】
しかしながら、前記従来のホスト装置のデータ処理では、プリンタからの再ダウンロードに対応しておらず、印刷データの再ダウンロードが必要なプリンタ処理を継続できないという課題を有していた。
【００４０】
また、一般的なＰＢＲの２者システムで行なわれている印刷出力完了時に印刷データを削除する方式だと再ダウンロードに対応できるが、印刷データ格納のためのシステムリソースの効率的かつ有効な活用が困難である課題は残る。
【００４１】
すなわち、従来の技術では、印刷データを早く削除しすぎた結果、印刷データの再要求があった場合には印刷データを再度生成して印刷バッファに格納しなければならず、印刷データの再要求があった場合におけるオーバーヘッドが大きかったり、印刷バッファに印刷データを長時間持ちすぎたりするという問題がある。
【００４２】
そこで、本発明は、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを防止しつつ、効率よく印刷バッファを利用することができる印刷装置、印刷指示装置および印刷システムを提供することを目的とする。
【課題を解決するための手段】
【００４３】
上記目的を達成するために、本発明に係る印刷装置においては、印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置であって、サブデータを取得する印刷データ取得手段と、取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知手段とを備えることを特徴とする。
【００４４】
これにより、その旨を通知された印刷指示装置は、印刷データが再び取得されることがないことを知り、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００４５】
また、本発明に係る印刷装置においては、前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、前記印刷データ取得手段は、子サブデータに先立って親サブデータを取得し、前記判定手段は、取得された親サブデータが参照している子サブデータに基づいて前記必要性を判定することを特徴とすることができる。
【００４６】
これにより、印刷指示装置は、子サブデータごとに再び取得されることがあるか否かを判断することができる。
【００４７】
また、本発明に係る印刷装置においては、前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータの１箇所だけから参照されている場合に、前記必要性がないと判定することを特徴とすることもできる。
【００４８】
これにより、他の箇所から参照されている場合に、その子サブデータを削除してしまう事態を避けることができる。
【００４９】
また、本発明に係る印刷装置においては、前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータで以降参照されない場合に、前記必要性がないと判定することを特徴とすることもできる。
【００５０】
これにより、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、迅速に印刷バッファを解放することができる。
【００５１】
また、本発明に係る印刷装置においては、前記親サブデータから参照される子サブデータには、前記子サブデータから参照される孫サブデータが含まれることを特徴とすることもできる。
【００５２】
これにより、多様な箇所から孫サブデータ（画像データ）を集め、印刷データを構成することができる。
【００５３】
また、本発明に係る印刷装置においては、前記判定手段は、前記親サブデータだけについて、前記必要性を判定することを特徴とすることもできる。
【００５４】
これにより、印刷バッファに親サブデータだけが格納されている場合に、この親サブデータを迅速に削除することができる。
【００５５】
また、本発明に係る印刷装置においては、前記通知手段は、前記印刷指示装置から前記通知の要求を受けた場合にだけ、前記通知をすることを特徴とすることができる。
【００５６】
これにより、通知の要求を受けない場合には、通知の必要がないので、印刷装置における処理が簡易化され、かつ通信量の少ない方法で印刷バッファを解放することができる。
【００５７】
また、本発明に係る印刷装置においては、前記通知手段は、前記印刷指示に前記通知の要求が含まれているか否かを判断し、含まれている場合にだけ、前記通知をすることを特徴とすることもできる。
【００５８】
これにより、通知の要求が含まれている場合にだけ通知すればよいので、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止することができる。
【００５９】
また、本発明に係る印刷装置においては、前記親サブデータは、マークアップ言語で記述され、前記子サブデータは、マークアップ言語で記述されたデータを除くデータであることを特徴とすることができる。
【００６０】
また、本発明に係る印刷装置においては、前記親サブデータは、ＨＴＭＬで記述され、前記子サブデータは、画像データまたはスタイル情報データであることを特徴とすることもできる。
【００６１】
また、上記目的を達成するために、本発明に係る印刷指示装置においては、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置であって、少なくとも１つのサブデータを保持する印刷バッファと、前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信手段と、前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段とを備えることを特徴とする。
【００６２】
これにより、その旨を通知された場合にだけ、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００６３】
また、本発明に係る印刷指示装置においては、前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、前記印刷バッファは、前記印刷データを構成するサブデータのうち、親サブデータだけを保持し、前記削除手段は、前記親サブデータを前記印刷バッファから削除することを特徴とすることができる。
【００６４】
なお、本発明は、このような印刷装置や、印刷指示装置として実現することができるだけでなく、このような印刷装置と、印刷指示装置とから構成される印刷システムとして構成したり、このような印刷装置や、印刷指示装置が備える特徴的な手段をステップとする印刷方法や、印刷指示方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【発明の効果】
【００６５】
以上の説明から明らかなように、本発明に係る印刷装置、印刷指示装置および印刷システムによれば、印刷データが再び取得されることがない場合にだけ、印刷データを印刷バッファから迅速に削除することができる。したがって、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、効率よく印刷バッファを利用することができる。
【００６６】
よって、本発明により、ハードウェア資源の少ない装置間で、システムリソースの効率的かつ有効活用を図ることができるＰｕｌｌ方式の印刷システムが実現され、インターネットが普及してきた今日における本願発明の実用的価値は極めて高い。
【００６７】
本発明は、以下の実施の形態および添付の図面を用いて説明されるが、これは例示を目的とするものであって、本発明はこれらに限定されることを意図しない。
【図面の簡単な説明】
【００６８】
【図１】印刷システムにおける印刷データのバンド処理を表す図である。
【図２】印刷データを格納する印刷バッファの使用例を表す図である。
【図３】図１のバンドデータを図２のラスタメモリに格納し、転送を行い、消去するタイミングを表す図である。
【図４】従来の実施例におけるホスト装置のデータ処理手順の一例を示すフローチャートである。
【図５】本発明の実施の形態に係る印刷システムの全体構成を示すブロック図である。
【図６】実施の形態１における印刷ドキュメントの例を示す図である。
【図７】図６の印刷ドキュメントを表す印刷記述データを示す図である。
【図８】印刷記述データのラスタライズ手順を示す図である。
【図９】印刷オブジェクトの要不要判定手順を含む画像形成装置の処理フローを示す図である。
【図１０】印刷オブジェクトの不要通知による印刷バッファ解放のフローを示す図である。
【図１１】本発明の実施の形態１における文書画像供給装置と画像形成装置間の通信シーケンスを示す図である。
【図１２】実施の形態２における印刷ドキュメントの例を示す図である。
【図１３】実施の形態２の印刷ドキュメントの詳細な構成を示す図である。
【図１４】図１３の印刷ドキュメントを表す印刷記述データを示す図である。
【図１５】内部処理モードの変更手順を含む画像形成装置の処理フローを示す図である。
【図１６】印刷オブジェクト転送要求による転送済み印刷オブジェクトの解放フローを示す図である。
【図１７】本発明の実施の形態１における文書画像供給装置と画像形成装置間の通信シーケンスを示す図である。
【図１８】本発明の実施の形態３におけるネットワーク構成を示すシステム構成図である。
【図１９】本発明の実施の形態３におけるホスト装置の構成を示すブロック図である。
【図２０】本発明の実施の形態３における印刷装置の構成を示すブロック図である。
【図２１】本発明の実施の形態３におけるホスト装置の機能構成を示す図である。
【図２２】本発明の実施の形態３における印刷装置の機能構成を示す図である。
【図２３】本発明の実施の形態３におけるプリンタステータスを定義する定義テーブルを示す図である。
【図２４】本発明の実施の形態３におけるプリンタステータスレコードのフィールド構成を示す図である。
【図２５】本発明の実施の形態３におけるジョブステータスを定義する定義テーブルを示す図である。
【図２６】本発明の実施の形態３におけるジョブステータスレコードのフィールド構成を示す図である。
【図２７】本発明の実施の形態３におけるプリンタステータスパケットのフィールド構成を示す図である。
【図２８】本発明の実施の形態３におけるジョブステータスパケットのフィールド構成を示す図である。
【図２９】本発明の実施の形態３における印刷データの構成を示す図である。
【図３０】本発明の実施の形態３における印刷データの格納場所を説明する図である。
【図３１】本発明の実施の形態３におけるホスト装置と印刷装置間の通信シーケンスを示す図である。
【図３２】本発明の実施の形態３におけるホスト装置のデータ処理を示すフローチャートである。
【図３３】本発明の実施の形態３における印刷装置のデータ処理を示すフローチャートである。
【図３４】本発明の実施の形態４における印刷データの構成を示す図である。
【図３５】本発明の実施の形態４における印刷データの格納場所を説明する図である。
【図３６】本発明の実施の形態４におけるホスト装置と印刷装置間の通信シーケンスを示す図である。
【図３７】本発明の実施の形態４におけるホスト装置のデータ処理を示すフローチャートである。
【図３８】本発明の実施の形態４における印刷装置のデータ処理を示すフローチャートである。
【図３９】本発明の実施の形態５におけるネットワーク構成を示すシステム構成図である。
【図４０】本発明の実施の形態５における印刷データの構成を示す図である。
【図４１】本発明の実施の形態５における印刷データの格納場所を説明する図である。
【図４２】本発明の実施の形態５におけるホスト装置、サーバ装置と印刷装置間の通信シーケンスを示す図である。
【図４３】印刷指示装置の印刷データバッファに、６個のプリントジョブ（Ｊｏｂ５〜Ｊｏｂ１０）のデータを格納している状態を示す図である。
【図４４】印刷指示装置におけるジョブ管理と、プリンタにおけるジョブのデータ取り込みの様子を示す図である。
【符号の説明】
【００６９】
１，２，３ 印刷システム
１１００ 文書画像供給装置
１１０１ アプリケーション
１１０２ 変換部
１１０３ プリンタ制御部
１１０４ 通信Ｉ／Ｆ
１２００ 画像形成装置
１３００ 伝送媒体
１４００ 印刷ドキュメント
１４０１〜１４０３ 画像オブジェクト
１４０４ 印刷記述データ
２００１ ホスト装置
２００２ 印刷装置
２００３ ネットワーク
２００４ ＰＢＲクライアント機能
２００５ ＰＢＲデバイス機能
２００６ Ｗｅｂクライアント機能
２００７ Ｗｅｂサーバ機能
２００８ サーバ装置
２０４２ プリントサービス
２０４３ ＰＢＲクライアントポート
２０４５ 印刷データバッファ
２０４７ Ｗｅｂサーバ
２０５１ ＰＢＲデバイスポート
２０５６ ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ
２０５７ レイアウト計算部
２０５９ Ｗｅｂクライアント
【発明を実施するための最良の形態】
【００７０】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００７１】
（実施の形態１）
図５は、本発明の実施の形態に係る印刷システムの全体構成を示すブロック図である。
【００７２】
印刷システム１は、図５に示されるように、文書画像供給装置１１００と、画像形成装置１２００と、文書画像供給装置１１００と画像形成装置１２００とを相互に通信可能に接続する伝送媒体１３００とから構成される。
【００７３】
文書画像供給装置１１００としては、デジタルＴＶや、セットトップボックス（ＳＴＢ）等を使用することができるが、その他データのソース源となる機器であれば何でも適用可能である。また、画像形成装置１２００としては、プリンタあるいはファクシミリ等を使用することができる。さらに、伝送媒体１３００としては、コンピュータとプリンタ間に使用されるバスあるいは公衆網、専用回線、インターネット網等の有線または無線でデータ転送可能な媒体を用いることができる。なお、図５においては、文書画像供給装置１１００としてデジタルテレビ（ＤＴＶ）を使用した場合の内部構成が示されており、画像形成装置１２００としてプリンタを使用した場合の内部構成が示されている。
【００７４】
文書画像供給装置１１００は、アプリケーション１１０１と、変換部１１０２と、プリンタ制御部１１０３と、印刷バッファ１１０５と、通信Ｉ／Ｆ１１０４とから構成される。
【００７５】
アプリケーション１１０１は、印刷記述データを生成する。変換部１１０２は、アプリケーション１１０１から出力された印刷記述データの形式を、画像形成装置１２００が解読可能な階層構造をもつリンクファイル（ここではＸＨＴＭＬ（Ｅｘｔｅｎｓｉｂｌｅ ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を使用する）形式に変換する。プリンタ制御部１１０３は、印刷記述データを解読してプリントジョブを発行したり、印刷記述データのバッファ管理を行なう。印刷バッファ１１０５は、印刷記述データを一時的に保存する。通信Ｉ／Ｆ１１０４は、伝送媒体１３００との接続インターフェースを提供する。
【００７６】
なお、印刷バッファ１１０５は、文書画像供給装置１１００に内蔵されている場合が示されているが、ネットワーク上の別の機器に存在する場合等であってもよく、存在位置は問わず適用可能である。
【００７７】
上記構成において、まず、ユーザがアプリケーション１１０１を用いて印刷データの編集等を行い印刷要求を出すと、アプリケーション１１０１から印刷に必要なデータが出力される。なお、このアプリケーション１１０１については、メーラや、ＷｅｂブラウザおよびＢＭＬブラウザ、デジタルスチルカメラのデータを編集可能なＤＳＣアルバムなどがある。変換部１１０２は、アプリケーション１１０１からのデータを、プリンタ側で解読可能な言語、例えばＸＨＴＭＬ形式に変換する。なお、印刷データが、既にＸＨＴＭＬ形式等であれば、特に変換は行なわなくてもよい。このように、変換された印刷記述データは、プリンタ制御部１１０３に渡され、印刷バッファ１１０５に格納される。その際、印刷記述データの中でリンクされている画像オブジェクトなどについては、変換部１１０２において画像形成装置１２００で印刷処理が可能な形式（例えば、ＪＰＥＧやＰＮＧ形式）のデータに変換されて、本来当該データが存在していたソース源から印刷バッファ１１０５にコピーされる。ここで、上記ソース源は、文書画像供給装置１１００の中に存在するか、外に存在するかを問わない。ここでも、既に画像形成装置１２００で印刷処理が可能な形式のデータである場合には、変換の必要はないことはもちろんである。
【００７８】
なお、この印刷バッファ１１０５として、文書画像供給装置１１００のメモリおよびＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を利用できる。例えば当該文書画像供給装置１１００がデジタルテレビである場合、当該デジタルテレビの機能上本来備えているメモリ等の記憶手段の一部を使用することができる。
【００７９】
画像形成装置１２００は、プリンタエンジン１２０１と、ラスタライザ１２０２と、インタプリタ１２０３と、通信Ｉ／Ｆ１２０４とから構成される。
【００８０】
プリンタエンジン１２０１は、印刷ドキュメントを記録紙等に印刷する。ラスタライザ１２０２は、印刷ドキュメントを小さな点の集まりとして表現されるラスタデータに展開する。インタプリタ１２０３は、印刷ドキュメントを構成する親サブデータである印刷記述データ（トップページ）の解析を行い、ラスタライザ１２０２が必要とする印刷ドキュメントを構成する子サブデータである画像オブジェクトの転送要求を文書画像供給装置１１００に出力する。通信Ｉ／Ｆ１２０４は、伝送媒体１３００を介して、上記印刷記述データや、画像オブジェクト、転送要求等を送受信する。
【００８１】
ここで、図６に示される印刷ドキュメント１４００を印刷しようとする場合、アプリケーション１１０１が扱うデータが、図７に示すプリンタ２００Ｐで処理可能な言語（ここではＸＨＴＭＬ形式いわゆるＭＬ形式）で記述された印刷記述データに変換され、アプリケーション１１０１が扱うデータにリンクされているオブジェクトが、表示可能な画像オブジェクト（ＪＰＥＧ、ＰＮＧ等）等の印刷オブジェクトに変換されて、それぞれ印刷バッファ１１０５に蓄積される。印刷データは、印刷記述データを表す場合もあり、印刷オブジェクトを表す場合もある。
【００８２】
図６の印刷ドキュメント１４００を例に挙げると、印刷ドキュメント１４００は、印刷記述データ１４０４と、３つの画像オブジェクト１４０１，４０２，４０３とから構成されており、画像オブジェクト１４０１と４０３とは同一の画像オブジェクトがリンクされている。印刷記述データ１４０４は、印刷ドキュメント１４００のトップページを表すサブデータ（親サブデータ）であり、画像形成装置１２００からの要求によって、文書画像供給装置１１００の通信Ｉ／Ｆ１１０４から画像形成装置１２００の通信Ｉ／Ｆ１２０４に転送される。印刷記述データ１４０４が送られてくると、インタプリタ１２０３は、印刷記述データ１４０４の解析を行い、ラスタライザ１２０２が必要とする画像オブジェクト１４０１，１４０２，１４０３の転送要求を文書画像供給装置１１００に出す。また、インタプリタ１２０３は、印刷記述データ１４０４の解析の際に、画像オブジェクト１４０１，１４０２，１４０３の印刷を完了するために再び取得される必要性があるか否かを判定する。
【００８３】
プリンタエンジン１２０１が、印刷ドキュメント１４００を表す印刷記述データ１４０４にしたがって印刷する場合、ラスタライザ１２０２は図８に示される矢印１４５１〜１４６１に沿って上から順にラスタライズを行う。矢印１４５１〜１４５４の領域をラスタライズする場合には、画像オブジェクト１４０１が必要になり、矢印１４５１をラスタライズする直前に、ラスタライザ１２０２が文書画像供給装置１１００へ画像オブジェクト１４０１の転送要求を出し、画像オブジェクト１４０１を受信する。次に、矢印１４５５〜１４５７の領域をラスタライズする場合には、画像オブジェクト１４０２が必要になり、矢印１４５５をラスタライズする直前に、ラスタライザ１２０２が文書画像供給装置１１００へ画像オブジェクト１４０２の転送要求を出し、画像オブジェクト１４０２を受信する。次に、矢印１４５８〜１４６１の領域をラスタライズする場合には、画像オブジェクト１４０３が必要になるが、画像オブジェクト１４０３が画像オブジェクト１４０１と同一のものであるので再度画像オブジェクト１４０１が必要になり、再度文書画像供給装置１１００に対して画像オブジェクト１４０１の転送要求を出し、画像オブジェクト１４０１を受信し、矢印１４５８〜１４６１の領域のラスタライズを開始することになる。
【００８４】
なお、画像オブジェクト１４０３のラスタライズ時には、画像形成装置１２００がキャッシュメモリを搭載し、前記キャッシュメモリに画像オブジェクト１４０１を保持している場合には、文書画像供給装置１１００に対して、画像オブジェクト１４０１の転送要求は不必要となることはもちろんである。
【００８５】
図６の印刷ドキュメント１４００では、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）について、画像形成装置１２００から文書画像供給装置１１００に対し２度転送を要求されることになるため、１度目の転送が終わった時点で画像オブジェクト１４０１を印刷バッファ１１０５から消去した場合、文書画像供給装置１１００は２度目の転送要求に対応できなくなるため、印刷バッファ１１０５から印刷データを消去するタイミングを画像形成装置１２００から文書画像供給装置１１００に対して転送完了の応答があった時点とすることはできない。
【００８６】
そのため、印刷ドキュメント１４００に関するオブジェクトに対して、画像形成装置１２００は図９に示すような処理手順によって、文書画像供給装置１１００に対してラスタライザ１２０２、またはインタプリタ１２０３が印刷オブジェクトの不要通知を行う。
【００８７】
まず、インタプリタ１２０３は、文書画像供給装置１１００から転送された印刷記述データ１４０４を解析する（Ｓ１１０１）。次いで、ラスタライザ１２０２は、ラスタライズの準備をし（Ｓ１１０２）、印刷記述データ１４０４にリンクされている印刷オブジェクトのデータが必要か否か判断する（Ｓ１１０３）。
【００８８】
印刷オブジェクトのデータが必要な場合は、ラスタライザ１２０２は、文書画像供給装置１１００に対して転送要求を行い（Ｓ１１０４）、印刷オブジェクトのデータを受信する（Ｓ１１０５）。続いて、この受信した印刷オブジェクトのデータをラスタライズする（Ｓ１１０６）。また、上記ステップＳ１１０３において、印刷オブジェクトの転送要求が必要でない場合は、次いで、ラスタライザ１２０２は、受信した印刷オブジェクトのデータをラスタライズする（Ｓ１１０６）。ラスタライズ（Ｓ１１０６）の後、印刷文書末（印刷ドキュメントのラスタライズ完了）かどうかの判断を行う（Ｓ１１０７）。印刷文書末でなく、引き続きラスタライズを行う場合、現時点までに受信完了した印刷オブジェクトの転送要求を再度行うことが必要になるか否か判断する（Ｓ１１０８）。受信完了した印刷オブジェクトの転送要求を再度行わない場合は、当該印刷オブジェクトが以降不要であることの通知を文書画像供給装置１１００に行う（Ｓ１１０９）。
【００８９】
なお、印刷オブジェクトの不要通知を行う際、不要な印刷オブジェクトを特定する情報としては、当該印刷オブジェクトのフルパス、当該オブジェクトの含まれる印刷ジョブＩＤ等の印刷ジョブを特定する情報と相対パスの組み合わせ、等が挙げられるが、印刷オブジェクトを特定できる情報であれば適用可能である。また、印刷オブジェクトの不要通知を行う時点は、再度転送要求しない印刷オブジェクトを不図示の印刷バッファに格納できた時点とすることもできる。
【００９０】
そして、ステップＳ１１０８における判断は、印刷データがトップページで以降参照されるか否かで行われ、印刷データがトップページで以降参照されない場合に、必要性がないと判断される。これにより、オーバーヘッドが生じたり、印刷データを長時間持ちすぎたりすることを確実に防止しつつ、迅速に印刷バッファを解放することができる。
【００９１】
一方、文書画像供給装置１１００は、図１０に示すように印刷データ生成するステップＳ１２０１、印刷データを印刷バッファに格納するステップＳ１２０２、印刷ジョブを発行するステップＳ１２０３、画像形成装置からの受信情報が印刷データの転送要求か判断するステップＳ１２０４、受信情報が印刷データ転送要求でなかった場合、画像形成装置からの受信情報が印刷データ不要通知か判断するステップＳ１２０５、受信情報が印刷データの不要通知でなかった場合、画像形成装置からの受信情報が印刷ジョブ終了通知か判断するステップＳ１２０６、受信情報が印刷データの転送要求であった場合、印刷バッファ１１０５に格納された当該印刷データを当該画像形成装置１２００に転送するステップＳ１２０７、受信情報が印刷データの不要通知であった場合、印刷バッファ１１０５の当該印刷データ格納領域を開放するステップＳ１２０８を備えた手順で、不要通知を受信した文書画像供給装置１１００は、画像形成装置からの受信情報が印刷データ不要通知か判断するステップＳ１２０５と、受信情報が印刷データの不要通知であった場合、印刷バッファ１１０５の当該印刷データ格納領域を開放するステップＳ１２０８によって、印刷バッファ１１０５から当該印刷データを格納している領域を開放することができる。
【００９２】
図１１は、印刷ドキュメント１４００を印刷する場合において、文書画像供給装置１１００および画像形成装置１２００間で行われるシーケンス図である。
【００９３】
文書画像供給装置１１００のアプリケーション１１０１および変換部１１０２は、印刷ドキュメント１４００を構成する印刷記述データ１４０４、画像オブジェクト１４０１〜１４０３を作成し、印刷バッファ１１０５に格納する。アプリケーション１１０１は、プリンタ制御部１１０３に対して印刷を行なうよう依頼する。
【００９４】
プリンタ制御部１１０３は、印刷記述データ１４０４、画像オブジェクト１４０１〜１４０３を内部の管理データベースに登録と管理をする。そして、プリンタ制御部１１０３は、不図示のＰＢＲクライアントポートにＵＲＩプリントリクエストを画像形成装置１２００に発行するよう要求する。要求を受けたＰＢＲクライアントポートは、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に対してＵＲＩプリントリクエストを送る（Ｓ１５０１）。
【００９５】
ここで、ＵＲＩプリントリクエストにより画像形成装置１２００に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・文書画像供給装置１１００の印刷データが不要になった場合にプリンタステータス情報を提示する要求を送る。本実施の形態１ではＵＲＬで印刷記述データ１４０４を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信はＰＢＲクライアントポートが行なう。
【００９６】
ＵＲＩプリントリクエストを受けた画像形成装置１２００の不図示のジョブマネージャはジョブの発行を行い、発行したジョブに対応するジョブステータスレコードを作成しジョブ管理テーブルに登録する。登録後にＰＢＲデバイスポートによりＵＲＩプリントリクエストの応答を返す（Ｓ１５０２）。
【００９７】
そして、不図示のプリンタマネージャは、プリンタステータスが“ｄａｔａ ｎｏ ｎｅｅｄ”状態になったら文書画像供給装置１１００にプリンタ状態通知イベントを行なうように内部状態をセットする。
【００９８】
次にジョブマネージャは、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には印刷記述データ１４０４）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ１５０３）。
【００９９】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から印刷記述データ１４０４（ｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、画像形成装置１２００に返送する（Ｓ１５０４）。
【０１００】
印刷記述データ１４０４を受け取った画像形成装置１２００のＷｅｂクライアントは、ジョブマネージャ経由で、インタプリタ１２０３に受け渡し、インタプリタ１２０３は印刷記述データ１４０４にインタプリト処理を行い文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換し、不図示のレイアウト計算部に渡す。レイアウト計算部はＤＯＭツリーよりレイアウト計算を行なうとともに、印刷記述データ１４０４で参照されている画像オブジェクト１４０１〜１４０３を特定する。
【０１０１】
次に、レイアウト計算部は、まず画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｆｒｏｎｔ．ｊｐｇ）」を送信する（Ｓ１５０５）。
【０１０２】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５０６）。
【０１０３】
画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）を受信すると、受け取ったＷｅｂクライアントはレイアウト計算部に受け渡し、レイアウト計算部はラスタライザ１２０２でラスタライズ処理をさせてプリンタエンジン１２０１への出力データを作成させる。出力データの作成が終わるとラスタライザ１２０２はプリンタエンジン１２０１へそれを送信し、プリンタエンジン１２０１は画像オブジェクト１４０１を印刷する。
【０１０４】
画像オブジェクト１４０１の印刷が終わると、次に、レイアウト計算部は、画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｓｉｄｅ．ｊｐｇ）」を送信する（Ｓ１５０７）。なお、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）については、再度印刷に利用するので、オブジェクト（ｆｒｏｎｔ．ｊｐｇ）不要通知を送信することはない。
【０１０５】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５０７）。
【０１０６】
画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）を受信すると、画像オブジェクト１４０１（ｆｒｏｎｔ．ｊｐｇ）の場合と同様の処理が行われ、プリンタエンジン１２０１は画像オブジェクト１４０２を印刷する。そして、画像オブジェクト１４０２（ｓｉｄｅ．ｊｐｇ）については、印刷に再度利用することがないので、ラスタライザ１２０２またはインタプリタ１２０３は、通信Ｉ／Ｆ１２０４を介してオブジェクト（ｓｉｄｅ．ｊｐｇ）不要通知を送信する（Ｓ１５０９）。
【０１０７】
なお、この不要通知は、プリンタステータスレコードのプリンタステータスフィールドにステータス値“ｄａｔａ ｎｏ ｎｅｅｄ”を記入したプリンタ状態通知イベントとして送信される。
【０１０８】
プリンタ状態通知イベントを受け取ると、プリンタ制御部１１０３は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷バッファ１１０５に格納されている画像オブジェクト１４０２を削除してよいと判断し、印刷バッファ１１０５の画像オブジェクト１４０２が格納されていたメモリ領域を解放（Ｓ１５０９）。
【０１０９】
オブジェクト不要要求の送信が終わると、次に、レイアウト計算部は、画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）をダウンロードするようＷｅｂクライアントに依頼し、Ｗｅｂクライアントは通信Ｉ／Ｆ１２０４を介して文書画像供給装置１１００へＰｕｌｌ要求「Ｐｕｌｌ要求（ｆｒｏｎｔ．ｊｐｇ）」を送信する（Ｓ１５１１）。
【０１１０】
Ｐｕｌｌ要求を受けた文書画像供給装置１１００のプリンタ制御部１１０３は、印刷バッファ１１０５から画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）を取り出し、通信Ｉ／Ｆ１１０４を介して画像形成装置１２００に送信する（Ｓ１５１２）。
【０１１１】
画像オブジェクト１４０２（ｆｒｏｎｔ．ｊｐｇ）を受信すると、プリンタエンジン１２０１は画像オブジェクト１４０２を印刷する。そして、画像オブジェクト１４０３（ｆｒｏｎｔ．ｊｐｇ）については、印刷に再度利用することがないので、ラスタライザ１２０２またはインタプリタ１２０３は、通信Ｉ／Ｆ１２０４を介してオブジェクト（ｆｒｏｎｔ．ｊｐｇ）不要通知を送信する（Ｓ１５１３）。
【０１１２】
プリンタ状態通知イベントを受け取ると、プリンタ制御部１１０３は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷バッファ１１０５に格納されている画像オブジェクト１４０３、つまりｆｏｒｎ．ｊｐｇを削除してよいと判断し、印刷バッファ１１０５のｆｒｏｎｔ．ｊｐｇが格納されていたメモリ領域を解放（Ｓ１５１４）。そして、印刷記述データ１４０４についても、削除してよいと判断し、印刷記述データ１４０４が格納されていた領域を開放し、印刷データ転送サービスが不要になったので、Ｗｅｂサーバを停止する。
【０１１３】
その後、画像形成装置１２００のレイアウト計算部は、ラスタライザ１２０２を介してプリンタエンジン１２０１が残りを印刷し、印刷ドキュメント１４００の印刷を完了する。そして、インタプリタ１２０３またはラスタライザ１２０２は、ＰＢＲデバイスポートにジョブステータスフィールドに“ｃｏｍｐｌｅｔｅｄ”と書き込んだジョブステータスパケットを、文書画像供給装置１１００に送信するよう依頼し、ＰＢＲデバイスポートがジョブステータスパケットを文書画像供給装置１１００に送信する。このジョブステータスパケットを受け取った文書画像供給装置１１００は、画像形成装置１２００での印刷ドキュメント１４００の印刷の完了を知る。
【０１１４】
かかる構成によれば、印刷ドキュメントの印刷完了前に、画像形成装置１２００から文書画像供給装置１１００へ印刷データの不要通知を行うことにより、文書画像供給装置１１００は、オーバーヘッドを生じることなく、印刷バッファ１１０５の解放を迅速確実に行うことができ、バッファ容量が少ない場合でも効率よく印刷バッファ１１０５を利用し、印刷ジョブを完了することができる。
【０１１５】
また、文書画像供給装置１１００が携帯電話機のようなモバイル機器である場合、画像形成装置１２００から印刷完了通知を受け取る前に画像形成装置１２００との接続を切断することができるので、接続時間を短縮できるという効果も発揮でき、モバイル機器にとってきわめて有効である。
【０１１６】
（実施の形態２）
次いで、本発明の実施の形態２に係る印刷システムについて説明する。なお、この印刷システムの構成が実施の形態１における図５で示される印刷システム１と同等であるので、システム構成の図示が省略されている。
【０１１７】
ところで、上記実施の形態１においては、図６に示される印刷ドキュメント１４００、つまり同じオブジェクトを２回用いる場合を例に挙げて説明したが、Ｐｕｌｌ方式の印刷システムでは図１２に示される印刷ドキュメント１５００も考えられる。
【０１１８】
図１２の印刷ドキュメント１５００が、印刷記述データと、１つの画像オブジェクト１５０１で構成されているが、印刷バッファ１１０５のメモリ容量によっては図１３のように画像オブジェクト１５０１を画像オブジェクト１５１１〜画像オブジェクト１５１３のように分割し、画像オブジェクト１５１１〜画像オブジェクト１５１３を印刷を行う優先度の高いものから順に印刷バッファ１１０５に格納していく必要がある。
【０１１９】
図１４は、図１３の印刷ドキュメント１５００を表す印刷記述データ５１４の構成例を示す図である。
【０１２０】
図１３のような印刷ドキュメント１５００を印刷する場合は、実施の形態１で述べた文書画像供給装置１１００が不要通知を受信した際に印刷バッファ１１０５を解放することも可能であるが、図１０で示す手順において、文書画像供給装置１１００が印刷ジョブを発行するステップＳ１２０４の段階では、画像オブジェクト１５１１〜画像オブジェクト１５１３は、印刷ドキュメント１５００に１回ずつしか現れ無いことがわかっているので、毎回の不要通知の受信は不必要になる。このため、この実施の形態２に係る印刷システムでは、文書画像供給装置１１００および画像形成装置１２００は、１回しか利用しないことが予めわかっている場合には、受信済みの画像オブジェクトについては再度転送要求をしないで、不要通知を省略するという処理モードを備えている。
【０１２１】
つまり、このような場合は、画像形成装置１２００では、図１５に示すように、内部処理モードの変更ステップＳ１３０１で、文書画像供給装置１１００から受信した印刷ジョブの情報を用い、受信済みの画像オブジェクトは再度転送要求をしないという処理モードに変更し、不要通知を省略する。
【０１２２】
また、文書画像供給装置１１００では、図１６に示すように、印刷データ生成時に各印刷オブジェクトが一回ずつしか現れないことがアプリケーション１１０１、変換部１１０２およびプリンタ制御部１１０３のいずれかでわかった場合、このいずれかは、バッファ処理モードの変更ステップＳ１４０１で、印刷バッファの解放のタイミングを不要通知受信後から、印刷オブジェクトの転送要求を受信した時に変更し、画像形成装置１２００から印刷オブジェクト転送要求を受信した時に、印刷バッファ内に転送済みの印刷データが存在する場合に当該バッファ領域を解放する転送済み印刷データ解放ステップＳ１４０２を備える。
【０１２３】
図１７は、印刷ドキュメント１５００を印刷する場合において、文書画像供給装置１１００および画像形成装置１２００間で行われるシーケンス図である。なお、ここにおいても、図１１に示される印刷ドキュメント１４００を印刷する場合と対応する処理については同じステップ番号を付し、その説明を省略する。
【０１２４】
このような構成により、図１３のような構造の印刷ドキュメント１５００を印刷する場合に、実施の形態１よりも簡易、かつ、通信量の少ない方法で、オーバーヘッドを生じることなく、迅速かつ確実に印刷バッファ１１０５のメモリ解放制御を行うことができる。
【０１２５】
なお、本実施の形態２における文書画像供給装置１１００から画像形成装置１２００へのバッファ処理モード（画像形成装置１２００における内部処理モードの変更）の通知方法としては、印刷ジョブにバッファ処理モードを含める方法、文書画像供給装置１１００と画像形成装置１２００との間で印刷ジョブ実行のためのコネクションが確立された後にコマンドとして通知する方法、印刷記述データ、または印刷オブジェクト内に記述する方法等が挙げられる。
【０１２６】
また、上記実施の形態２では印刷データを解放してから（Ｓ１４０２，Ｓ１５２２，Ｓ１５２３，Ｓ１５２４）、次の印刷データを転送したが（Ｓ１２０７，Ｓ１５０６，Ｓ１５０８，Ｓ１５１２）、この逆の順序であってもよい。
【０１２７】
かかる構成によれば、文書画像供給装置１１００から画像形成装置１２００へ印刷バッファ１１０５の処理モード通知を行うことにより、文書画像供給装置１１００は印刷バッファ１１０５の解放を行うタイミングを知ることができ、バッファ容量が少ない場合でも効率よく印刷バッファ１１０５を利用し、印刷ジョブを完了することができる。
【０１２８】
（実施の形態３）
次いで、本発明の実施の形態３に係る印刷システムについて説明する。
【０１２９】
図１８は、本発明の実施の形態３に係る印刷システムの全体構成を示す図である。
この印刷システム２は、図１８に示されるように、ホスト装置２００１と、印刷装置２００２と、ホスト装置２００１と印刷装置２００２とを接続するネットワーク２００３とから構成される。ここで、本発明は通信および印刷データの管理に関するものであるので、図１８において通信機能の存在位置も示されている。
【０１３０】
ホスト装置２００１は、ＰＢＲクライアント機能２００４と、Ｗｅｂサーバ機能２００７とを備える。
【０１３１】
印刷装置２００２は、ＰＢＲデバイス機能２００５と、Ｗｅｂクライアント機能２００６とを備える。
【０１３２】
ＰＢＲクライアント機能２００４は、ＰｒｉｎｔＢｙＲｅｆｅｒｎｃｅ（ＰＢＲ）方式のクライアント通信機能を提供する。ＰＢＲデバイス機能２００５は、ＰＢＲクライアント機能２００４からの印刷指示や各種問い合わせ等への回答等のＰＢＲプリントのデバイス側通信機能を提供する。Ｗｅｂクライアント機能２００６は、ＰＢＲデバイス機能２００５からの印刷データのダウンロード要求を受けてネットワーク上のＷｅｂサーバにダウンロードを要求する。Ｗｅｂサーバ機能２００７は、印刷装置２００２のＷｅｂクライアント機能２００６からのダウンロード要求に答える。
【０１３３】
本実施の形態３におけるネットワークプリントシステムである印刷システム２は、２者システムであるので、ＰＢＲクライアント機能２００４とＷｅｂサーバ機能２００７とが１つのホスト装置２００１上に実装されている。
【０１３４】
図１９は、図１８に示したホスト装置２００１のハードウェア構成を示す内部ブロック図である。なお図１８と同一のものには同一の符号を示してある。
【０１３５】
図１９に示されるように、ホスト装置２００１は、ＣＰＵ２０１１と、ＲＯＭ２０１２と、ＲＡＭ２０１３と、ネットワークインターフェースカード（ＮＩＣ）２０１４と、ＣＲＴコントローラ（ＣＲＴＣ）２０１５と、ＣＲＴディスプレイ（ＣＲＴ）２０１６と、リモコン受光ユニット（ＲＭＲ）２０１７と、リムーバブルメディアコントローラ（ＲＭＣ）２０１８と、リムーバブルメディアアクセスデバイス（ＲＭＡ）２０１９と、これらを接続するシステムバス２０２０とから構成される。
【０１３６】
ＣＰＵ２０１１は、ＯＳや印刷アプリケーションプログラムをはじめとする各種アプリケーションプログラムや、ネットワークドライバ等の各種デバイスドライバプログラム等のソフトウエアを実行する。ＲＯＭ２０１２は、ＣＰＵ２０１１が実行するソフトウエアを格納する。ＲＡＭ２０１３は、システム起動時にＲＯＭに格納されたソフトウエアがコピーされ、またアプリケーションソフトやＯＳのワークエリアを提供する。ＮＩＣ２０１４は、ネットワーク２００３へのインターフェースを提供するネットワークインターフェースカードである。ＣＲＴＣ２０１５は、ＣＲＴ２０１６の表示を制御する。ＲＭＲ２０１７は、リモコンからの送信光を受光する。ＲＭＣ２０１８は、ＲＭＡ２０１９を制御する。ＲＭＡ２０１９は、ＳＤカード等のリムーバブルメディアにアクセスする。システムバス２０２０は、ＣＰＵ２０１１、ＲＯＭ２０１２、ＲＡＭ２０１３、ＮＩＣ２０１４、ＣＲＴＣ２０１５、ＲＭＲ２０１７、ＲＭＣ２０１８を互いに接続する。
【０１３７】
図２０は、図１８に示される印刷装置２００２のハードウェア構成を示す内部ブロック図である。なお図１８と同一のものには同一の符号を示してある。
【０１３８】
印刷装置２００２は、図２０に示されるように、コントローラ部２０３０と、印刷部２０３５と、操作パネル２０３８とを備える。コントローラ部２０３０は、ＣＰＵ２０３１と、ＲＯＭ２０３２と、システムバス２０３３と、印刷部インターフェース２０３４と、入力部２０３６とから構成される。
【０１３９】
コントローラ部２０３０のＣＰＵ２０３１は、ＲＯＭ２０３２のプログラム用ＲＯＭに記憶された制御プログラムに基づいてシステムバス２０３３に接続される各種のデバイスとのアクセスを統括的に制御し、印刷部インターフェース２０３４を介して接続される印刷部（プリントエンジン）２０３５に出力情報としての画像信号を出力する。
【０１４０】
また、ＲＯＭ２０３２のプログラム用ＲＯＭには、ＣＰＵ２０３１が実行可能な制御プログラム等が記憶される。さらに、ＲＯＭ２０３２のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ２０３２のデータ用ＲＯＭにはホスト装置２００１で使用される情報等が記憶される。
【０１４１】
ＣＰＵ２０３１は、入力部２０３６を介してホスト装置２００１との通信処理を実行し、印刷装置２００２内の情報等をホスト装置２００１に通知する。
【０１４２】
ＲＡＭ２０３７は、主としてＣＰＵ２０３１の主メモリ、ワークエリア等として機能する。なお、ＲＡＭ２０３７は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等として用いられる。
【０１４３】
また、操作パネル２０３８は、操作のためのスイッチおよびＬＥＤ表示器等が配されて構成される。ここで、ＮＶＲＡＭ（図示しない）に、操作パネル２０３８から入力されたプリンタモード設定情報をユーザ別、グループ別に記憶するようにしてもよい。
【０１４４】
図２１は、図１８に示されるホスト装置２００１の機能構成を示す図である。
ホスト装置２００１は、印刷アプリケーション２０４１と、プリントサービス２０４２と、ＰＢＲクライアントポート２０４３と、プリンタ情報管理部２０４４と、印刷データバッファ２０４５と、ＳＤデータ管理部２０４６と、Ｗｅｂサーバ２０４７とから構成される。
【０１４５】
印刷アプリケーション２０４１は、プリントサービス２０４２の印刷データ生成機能により印刷データを構成する親サブデータおよび子サブデータを作成し、印刷データバッファ２０４５に格納したり、プリントサービス２０４２に対して印刷を行なうよう依頼したりする。
【０１４６】
プリントサービス２０４２は、印刷アプリケーション２０４１に対して印刷データ生成サービス、ジョブ管理サービス、プリンタ管理サービス、印刷管理サービスを提供する。なお、本実施の形態３では、ＸＨＴＭＬ−Ｐｒｉｎｔで記述した印刷データの印刷について説明することにする。
【０１４７】
ここで、ＸＨＴＭＬ−Ｐｒｉｎｔというのは、ＸＭＬに基づいて書き直されたＨＴＭＬ言語に対してプリント処理の負荷低減等考慮したサブセット化および機能追加を施した言語であり、Ｐｒｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ（ＰＷＧ）において標準化されている。
【０１４８】
ＰＢＲクライアントポート２０４３は、ＰＢＲクライアント機能２００４を提供する。ＰＢＲクライアントポート２０４３は、ＵＲＩプリントリクエストの印刷装置２００２への送信およびその応答受信と、印刷装置２００２からのジョブ状態通知イベントおよびプリンタ状態通知イベントの受信とを行なう。プリンタ情報管理部２０４４は、プリンタの状態情報や、プリンタのネットワークアドレス情報を管理する。
【０１４９】
印刷データバッファ２０４５は、ＲＡＭ２０１３に作成され、親サブデータおよび子サブデータを一時的に格納する。ＳＤデータ管理部２０４６は、ＲＭＡ２０１９からアクセスされるＳＤメモリカード内のデータを管理する。Ｗｅｂサーバ２０４７は、Ｗｅｂサーバ機能２００７を提供する。そして、Ｗｅｂサーバ２０４７は、印刷装置２００２からのからのＰｕｌｌ要求を受け付け、Ｐｕｌｌ要求内のＵＲＬで指定されたデータを返送する。
【０１５０】
なお、印刷アプリケーション２０４１、プリントサービス２０４２、ＰＢＲクライアントポート２０４３、プリンタ情報管理部２０４４、ＳＤデータ管理部２０４６、Ｗｅｂサーバ２０４７は、ソフトウエアであり、このソフトウエアをＣＰＵ２０１１が実行するにより実現される。
【０１５１】
図２２は、図１８に示される印刷装置２００２におけるコントローラ部２０３０の機能構成を示す図である。
【０１５２】
コントローラ部２０３０は、ＰＢＲデバイスポート２０５１と、ジョブマネージャ２０５２と、ジョブ管理テーブル２０５３と、プリンタマネージャ２０５４と、プリンタステータスレコード２０５５と、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６と、レイアウト計算部２０５７と、ラスタライザ２０５８と、Ｗｅｂクライアント２０５９とを備える。
【０１５３】
ＰＢＲデバイスポート２０５１は、ＰＢＲデバイス機能２００５を提供する。そして、ＰＢＲデバイスポート２０５１は、ホスト装置２００１からのＵＲＩプリントリクエストの受信および応答の送信、ホスト装置２００１へのジョブ状態通知イベントおよびプリンタ状態通知イベントの送信を行なう。
【０１５４】
ジョブマネージャ２０５２は、ＰＢＲデバイスポート２０５１を介して受信したＵＲＩプリントリクエストの受付処理およびジョブ管理を行なう。ジョブ管理テーブル２０５３は、ジョブマネージャ２０５２がジョブ管理をする上で使用する。プリンタマネージャ２０５４は、印刷装置２００２の機器状態を管理する。プリンタステータスレコード２０５５は、印刷装置２００２の機器情報を格納する。
【０１５５】
ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は、ＸＨＴＭＬ−Ｐｒｉｎｔで記述された印刷データのパーシング処理および解釈処理を行う。レイアウト計算部２０５７は、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６の処理結果を受け、印刷出力のレイアウト情報を計算する。ラスタライザ２０５８は、レイアウト計算部２０５７の計算結果を受け、印刷部２０３５への出力データである画像信号を計算し、印刷部２０３５へ出力するとともにその管理を行なう。
【０１５６】
Ｗｅｂクライアント２０５９は、Ｗｅｂクライアント機能２００６を提供し、ホスト装置２００１へＰｕｌｌ要求を出し、データを受信する。
【０１５７】
なお、ＰＢＲデバイスポート２０５１、ジョブマネージャ２０５２、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６、レイアウト計算部２０５７、ラスタライザ２０５８、Ｗｅｂクライアント２０５９はソフトウエアであり、このソフトウエアをコントローラ部２０３０のＣＰＵ２０３１が実行することにより実現される。
【０１５８】
また、ジョブ管理テーブル２０５３およびプリンタステータスレコード２０５５は、コントローラ部２０３０のＲＡＭ２０３７に用意される。
【０１５９】
図２３は、図１８に示される印刷装置２００２のプリンタステータスを示す図である。
図２３に示される“Ｐａｐｅｒ ｅｍｐｔｙ”、”Ｐａｐｅｒ ｊａｍ”、”Ｉｎｋ ｅｍｐｔｙ”、”Ｏｕｔｐｕｔ ｔｒａｙ ｏｐｅｎ”、”Ｆａｔａｌ ｅｒｒｏｒ”については、プリンタで一般的に使用されているステータスである。
【０１６０】
“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”、”ｄａｔａ ｎｏ ｎｅｅｄ”は、本明細書中にて追加定義されたステータスである。“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、印刷装置２００２が親サブデータ（本実施の形態３ではＸＨＴＭＬ−Ｐｒｉｎｔデータが相当する）の処理を終え、ホスト装置２００１上の親サブデータが必要でなくなった状態になったことを示す。“Ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、印刷装置２００２が印刷データの処理を終え、ホスト装置２００１上の印刷データが必要でなくなった状態になったことを示す。印刷データが複数のサブデータより構成される場合には、全てのサブデータが必要でなくなった状態になるとこのステータスになる。
【０１６１】
図２４は、図２２に示されるプリンタステータスレコード２０５５のフィールド構成を示す図である。
【０１６２】
プリンタステータスレコード２０５５は、プリンタＩＤフィールド２０７１と、プリンタステータスフィールド２０７２とから構成される。プリンタＩＤフィールド２０７１には、印刷装置２００２を識別するためのプリンタＩＤ情報が格納される。プリンタステータスフィールド２０７２には、図２３で定義されるプリンタステータスが格納される。
【０１６３】
図２５は、印刷装置２００２のジョブのステータスの構成例を示す図である。
図２５に示される“Ｐｅｎｄｉｎｇ”、“Ｐｅｎｄｉｎｇ−ｈｅｌｄ”、“Ｐｒｏｃｅｓｓｉｎｇ”、“Ｐｒｏｃｅｓｓｉｎｇ−ｈｅｌｄ”、“Ｃａｎｃｅｌｅｄ”、“Ａｂｏｒｔｅｄ”“Ｃｏｍｐｌｅｔｅｄ”は、プリンタで一般的に使用されているステータスである。
【０１６４】
“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”および“Ｐｒｏｃｅｓｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”は、本明細書中にて追加定義されたステータスである。“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、ジョブが親サブデータ（本実施の形態３ではＸＨＴＭＬ−Ｐｒｉｎｔデータが相当する）の処理を終え、ホスト装置２００１上の親サブデータが必要でなくなった状態になったことを示す。“Ｐｒｏｃｅｓｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”ステータスは、ジョブが印刷データの処理を終え、ホスト装置２００１上の印刷データが必要でなくなった状態になったことを示す。印刷データが複数のサブデータより構成される場合、全てのサブデータが処理を終えた時点でこのステータスになる。
【０１６５】
図２６は、ジョブ管理テーブル２０５３に設けられるジョブステータスレコードの構成を示す図である。
【０１６６】
ジョブステータスレコード２０９１は、ジョブ管理テーブル２０５３にジョブの数に応じた数だけ設けられ、各ジョブごとにジョブステータス情報を格納するためのものであり、ジョブＩＤフィールド２０９２と、ジョブステータスフィールドに２０９３とから構成される。ジョブＩＤフィールド２０９２には、ジョブを識別するためのジョブＩＤ情報が格納される。ジョブステータスフィールド２０９３には、図２５で定義されるジョブステータスが格納される。
【０１６７】
図２７は、プリンタステータスパケットの構成を示す図である。
プリンタステータスパケット２１０１は、印刷装置２００２のプリントステータスを通信相手に知らせるためのものであり、ヘッダ部２１０２と、ヘッダ部２１０２とから構成される。ヘッダ部２１０２には、パケットヘッダ情報が格納される。プリンタステータスフィールド２１０３には、図２３で定義されるプリンタステータスが格納される。
【０１６８】
図２８は、ジョブステータスパケットの構成を示す図である。
ジョブステータスパケット２１１１は、印刷装置２００２におけるジョブステータスを通信相手に知らせるためのものであり、パケットヘッダ情報を格納するヘッダ部１１１２と、ジョブを識別するためのジョブＩＤ情報を格納するジョブＩＤフィールド１１１３と、ジョブステータス情報を格納するジョブステータスフィールド２１１４とから構成される。ジョブステータスフィールド２１１４には、図２５で定義されるジョブステータスが記載される。
【０１６９】
以下に、本実施の形態３における１つのアプリケーションについて説明する。
このアプリケーションでは、印刷データが複数のサブデータから構成され、それらのサブデータがホスト装置２００１の印刷データバッファ２０４５に格納されている。この場合、印刷データバッファ２０４５からの印刷データの削除は、印刷装置２００２が全サブデータの処理を終えて全サブデータが必要でなくなった時点で行なうのが妥当である。ホスト上の全サブデータが必要でなくなったことは、プリンタステータスとして印刷装置２００２が通知することとする。
【０１７０】
図２９は、本アプリケーションでの印刷データの構成を示す図である。
印刷データ２１２１は、複数のサブデータ、すなわち、親サブデータ２１２２と、子サブデータ（画像データ）２１２３ａ〜２１２３ｃとから構成される。親サブデータ２１２２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述されたデータである。子サブデータ２１２３ａ，２１２３ｂ，２１２３ｃは、親サブデータ２１２２から参照される子データに相当する画像データ（ｉｍｇ０１．ｊｐｇ，ｉｍｇ０２．ｊｐｇ，ｉｍｇ０３．ｊｐｇ）である。親サブデータ２１２２は印刷データ２１２１につき、１つ必ず存在する。子サブデータ２１２３ａ，１１２３ｂ，２１２３ｃは親サブデータ２１２２と同じ場所におかれており、親サブデータ２１２２で対応付けがなされている。
【０１７１】
図３０は、印刷データ２１２１の格納場所を示す図である。なお、図３０では、ＲＡＭ２０１３およびＲＭＡ２０１９が図示されている。
【０１７２】
ＲＡＭ２０１３には、印刷データバッファ２０４５と、印刷アプリケーションワークエリア２１３２とが用意される。アプリケーションワークエリア２１３２は、印刷アプリケーション２０４１が作業用エリアとして使用するエリアである。本実施の形態３では、印刷データバッファ２０４５には、親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃが全て格納される。ＳＤカードメモリ２１３３は、リムーバブルメディアアクセスデバイス（ＲＭＡ）２０１９に挿入されるカードメモリである。印刷データをＳＤカードメモリ２１３３に格納し、印刷データとすることができる。本実施の形態３では、ＳＤカードメモリ２１３３は使用しない。
【０１７３】
図３１は本実施の形態３におけるホスト装置２００１と印刷装置２００２との間の通信シーケンスを示す図であり、図３２は本実施の形態３におけるホスト装置２００１のデータ処理を示すフローチャートであり、図３３は本実施の形態３における印刷装置２００２のデータ処理を示すフローチャートである。
【０１７４】
図３１〜図３３により、ホスト装置２００１と印刷装置２００２間の通信シーケンスと、各々の内部動作を説明する。
【０１７５】
印刷アプリケーション２０４１は、プリントサービス２０４２の印刷データ生成機能により親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃを作成し、作成した親サブデータ２１２２および子サブデータ２１２３ａ〜１１２３ｃを印刷データバッファ２０４５に格納する。印刷アプリケーション２０４１は、プリントサービス２０４２に対して印刷を行なうよう依頼する。プリントサービス２０４２は、Ｗｅｂサーバが起動していないならばＷｅｂサーバ２０４７を起動する（Ｓ２５０２）。
【０１７６】
プリントサービス２０４２は、親サブデータ２１２２、子サブデータ２１２３ａ〜２１２３ｃを内部の管理データベースに登録し、管理する（Ｓ２５０３，Ｓ２５０４）。そして、プリントサービス２０４２は、ＰＢＲクライアントポート２０４３にＵＲＩプリントリクエストを印刷装置２００２に発行するよう要求する。
【０１７７】
ＰＢＲクライアントポート２０４３（ホスト装置２００１）は、印刷装置２００２に対してＵＲＩプリントリクエストを送る（Ｓ２４０１）。
【０１７８】
ここで、ＵＲＩプリントリクエストにより印刷装置２００２に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・ホスト装置の印刷データが不要になった場合にプリンタステータス情報を提示する要求（図３１において「ＵＲＩプリントリクエスト（ａｌｌ−ｄａｔａ：ＯＮ）」が相当）を送る。本実施の形態３ではＵＲＬで親サブデータ２１２２を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信はＰＢＲクライアントポート２０４３が行なう。
【０１７９】
ＵＲＩプリントリクエストを受けた印刷装置２００２のジョブマネージャ２０５２はジョブの発行を行い、発行したジョブに対応するジョブステータスレコード２０９１を作成し、ジョブ管理テーブル２０５３に登録する（Ｓ２６０２）。そして、登録後に、ＰＢＲデバイスポート２０５１は、ＵＲＩプリントリクエストに対する応答を返す（Ｓ２４０２）。プリンタマネージャ２０５４は、プリンタステータスが“ｄａｔａ ｎｏ ｎｅｅｄ”状態（図２３参照）になったら、ホスト装置２００１にプリンタ状態通知イベントを行なうように内部状態をセットする。
【０１８０】
次にジョブマネージャ２０５２は、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には、親サブデータ２１２２）をダウンロードするようＷｅｂクライアント２０５９に依頼し、Ｗｅｂクライアント２０５９は、ホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ２６０３，Ｓ２４０３）。ホスト装置２００１のＷｅｂサーバ２０４７は、Ｐｕｌｌ要求を受け付け（Ｓ２５０５）、印刷データバッファ２０４５から親サブデータ２１２２（ｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、印刷装置２００２に送信する（Ｓ２５０６，Ｓ２４０４）。
【０１８１】
Ｗｅｂクライアント２０５９は、ホスト装置２００１から親サブデータ２１２２を受け取ると（Ｓ２６０４）、ジョブマネージャ２０５２経由で、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６に受け渡し、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は親サブデータ２１２２にインタプリト処理を行い（Ｓ２６０５）、文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換し、レイアウト計算部２０５７に渡す。レイアウト計算部２０５７はＤＯＭツリーよりレイアウト計算を行なうとともに（Ｓ２６０６）、親サブデータ（ＸＭＬデータ）２１２２で参照されている子サブデータ（画像データ）２１２３ａ〜２１２３ｃを特定する（Ｓ２６０７）。なお、これ以降の処理においてはＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は登場しない。
【０１８２】
次に、レイアウト計算部２０５７は、まず子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）をダウンロードするようＷｅｂクライアント２０５９に依頼し（Ｓ２６０８）、Ｗｅｂクライアント２０５９はホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ｉｍｇ０１．ｊｐｇ）」を送信する（Ｓ２４０５）。
【０１８３】
Ｐｕｌｌ要求を受けたホスト装置２００１のＷｅｂサーバ２０４７は（Ｓ２５０５）、印刷データバッファ２０４５から子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）を取り出し、印刷装置２００２に送信する（Ｓ２５０６，Ｓ２４０６）。
【０１８４】
子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）を受信すると（Ｓ２６０９）、Ｗｅｂクライアント２０５９は受け取った子サブデータ２１２３ａ（ｉｍｇ０１．ｊｐｇ）をレイアウト計算部２０５７に受け渡し、レイアウト計算部２０５７はラスタライザ２０５８にラスタライズ処理（Ｓ２６１０）をさせて、印刷部２０３５への出力データを作成させる。出力データの作成が終わると、ラスタライザ２０５８は印刷部２０３５へそれを送信し、印刷部２０３５は印刷する（Ｓ２６１１）。
【０１８５】
子サブデータ２１２３ｂ（ｉｍｇ０２．ｊｐｇ）および子サブデータ２１２３ｃ（ｉｍｇ０３．ｊｐｇ）についても、子サブデータ（画像データ）２１２３ａ（ｉｍｇ０１．ｊｐｇ）と同様の処理を行なう（Ｓ２４０７〜Ｓ２４１０，Ｓ２５０５〜Ｓ２５０６，Ｓ２６０８〜Ｓ２６１１）。
【０１８６】
レイアウト計算部２０５７は、子サブデータ（画像データ）２１２３ａ〜２１２３ｃのデータ処理が完了してホスト装置２００１上の子サブデータ２１２３ａ〜２１２３ｃが必要であるか判断し（Ｓ２６１２）、必要がない状態になったら、プリンタマネージャ２０５４にその旨を通知する。プリンタマネージャ２０５４は、プリンタステータスレコード２０５５のプリンタステータスフィールド２０７２にステータス値“ｄａｔａ ｎｏ ｎｅｅｄ”を記入し、プリンタ状態通知イベントをホスト装置２００１に送信するようジョブマネージャ２０５２経由でＰＢＲデバイスポート２０５１に依頼する（Ｓ２６１３）。つまり、印刷データ不要通知を依頼する。ＰＢＲデバイスポート２０５１は、プリンタステータスフィールド２１０３に“ｄａｔａ ｎｏ ｎｅｅｄ”をセットしたプリンタステータスパケット２１０１を作成し、ホスト装置２００１に送信する（Ｓ２４１１）。
【０１８７】
ＰＢＲクライアントポート２０４３は、プリンタ状態通知イベントを受け取ると、プリントサービス２０４２に通知し、プリントサービス２０４２は、“ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷データバッファ２０４５に格納されている親サブデータ２１２２、子サブデータ２１２３ａ〜１１２３ｃを削除してよいと判断し（Ｓ２５０７）、データ自体を削除するか、印刷データバッファ２０４５をＲＡＭ２０１３から削除する（Ｓ２５０８，Ｓ２４１２）。ここで、印刷データ転送サービスが不要になったので、Ｗｅｂサーバ２０４７を停止する（Ｓ２５０９）。
【０１８８】
その後、レイアウト計算部２０５７は、ラスタライザ２０５８を介して印刷部２０３５が残りの印刷出力を行い（Ｓ２６１４）、印刷出力を完了し（Ｓ２６１５）、それを検知すると、ジョブマネージャ２０５２に通知し、ジョブマネージャ２０５２は、ＰＢＲデバイスポート２０５１にジョブステータスフィールドに“ｃｏｍｐｌｅｔｅｄ”と書き込んだジョブステータスパケット２１１１を、ホスト装置２００１に送信するよう依頼し、ＰＢＲデバイスポート２０５１がジョブステータスパケット２１１１をホスト装置２００１に送信する（Ｓ２４１３）。
【０１８９】
ジョブステータスパケット２１１１を受け取ったホスト装置２００１は、ここで印刷装置２００２での印刷出力の完了を知る（Ｓ２４１４）。
【０１９０】
以上のように、本実施の形態３では、印刷データが複数のサブデータよりなり、それらがホスト装置の印刷データバッファに格納され、印刷データバッファからの印刷データの削除は、印刷装置が全サブデータの処理を終えて全サブデータが必要でなくなった時点で、プリンタステータスとして印刷装置が通知している。これにより、ホスト装置は、自装置内の印刷データバッファから印刷データを削除し、メモリ等のシステムリソースを解放を、印刷完了時点でよりも早く行なえる。このため、プリンタエンジン処理機能が低かったり、大きな画像データを扱う場合にその効果はより大きい。
【０１９１】
（実施の形態４）
次いで、実施の形態４に係るアプリケーションについて説明する。
【０１９２】
本アプリケーションでは、印刷データが複数のサブデータよりなるが、親サブデータだけが印刷データバッファ２０４５に格納され、子サブデータは、リムバブルメモリカードメディア等の外部メモリに格納する場合に適用される。
【０１９３】
この場合、印刷データバッファ２０４５からの印刷データの削除は、印刷装置２００２が親サブデータの処理を終えて親サブデータが必要でなくなった時点で行なうのが妥当である。ホスト上の親サブデータが必要でなくなったことは、プリンタステータスとして印刷装置２００２が通知することとする。
【０１９４】
図３４は、本実施の形態４における印刷データの構成を示す図である。なお、図３４では、ＲＡＭ２０１３およびＲＭＡ２０１９が図示されている。
【０１９５】
印刷データ２１７１は、親サブデータ２１７２と、子サブデータ２１７３ａ〜２１７３ｃとから構成される。親サブデータ２１７２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述された親サブデータであり、印刷データ２１７１のサブデータである。子サブデータ２１７３ａ〜２１７３ｃは、親サブデータ２１７２から参照される子サブデータであり、印刷データ２１７１のサブデータである。子サブデータ２１７３ａ〜２１７３ｃは画像データである。子サブデータ２１７３ａ〜２１７３ｃは親サブデータ２１７２と異なる場所におかれており、親サブデータで対応付けがなされている。
【０１９６】
図３５は、印刷データの格納場所を示す図である。なお、図３０と同一のものは同じ番号を付し、説明を省略する。
【０１９７】
本実施の形態４では、親サブデータ２１７２のみが印刷データバッファ２０４５に格納され、子サブデータ２１７３ａ〜２１７３ｃはＳＤカードメモリ２１３３に格納される。この点で実施の形態３と異なる。
【０１９８】
図３６は、本実施の形態４におけるホスト装置２００１と印刷装置２００２との間の通信シーケンスを示す図である。なお、一部を除いては図３１と同じであり、同一の処理を示すステップについては同じ番号を付している。そして、ステップＳ２９０１と、ステップＳ２９０２が追加された処理である。
【０１９９】
また、図３７は、本実施の形態４におけるホスト装置２００１のデータ処理を示すフローチャートである。一部を除いては図３２と同じであり、同一の処理を示すステップについては同じ番号を付している。そして、ステップＳ３００１と、ステップＳ３００２が追加された処理である。
【０２００】
さらに、図３８は、本実施の形態４における印刷装置２００２のデータ処理を示すフローチャートである。一部を除いては図３３と同じであり、同一の処理を示すステップは同じ番号を付している。そして、ステップＳ３１０２が追加された処理である。
【０２０１】
次いで、図３６〜図３８により、ホスト装置２００１と印刷装置２００２間の通信シーケンスと、各々の内部動作を説明する。なお、図３１〜図３３と同じステップ番号で同じ処理を示すものについては、本実施の形態４に必要なものについて説明するにとどめる。
【０２０２】
ＰＢＲクライアントポート２０４３（ホスト装置２００１）は、印刷装置２００２に対してＵＲＩプリントリクエストを送る（Ｓ２４０１）。
【０２０３】
ここで、ＵＲＩプリントリクエストにより印刷装置２００２に、
・印刷データを指定するＵＲＬ
・印刷条件
とともに
・ホスト装置の親サブデータが不要になった場合にプリンタステータス情報を提示する要求（図３６において「ＵＲＩプリントリクエスト（ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ：ＯＮ）」が相当）を送る（Ｓ２４０１）。本実施の形態４ではＵＲＬで親サブデータ２１２２を指定する。このＵＲＩプリントリクエストの送信とそれに対する応答受信は、ＰＢＲクライアントポート２０４３が行なう。
【０２０４】
ＵＲＩプリントリクエストを受けた印刷装置２００２のジョブマネージャ２０５２は、ジョブの発行を行い、発行したジョブに対応するジョブステータスレコード２０９１を作成し、ジョブ管理テーブル２０５３に登録する（Ｓ２６０２）。登録後に、ＰＢＲデバイスポート２０５１は、ＵＲＩプリントリクエストの応答を返す（Ｓ２４０２）。
【０２０５】
プリンタマネージャ２０５４は、プリンタステータスが“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”状態（図２３参照）になったら、ホスト装置２００１にプリンタ状態通知イベントを行なうように内部状態をセットする。
【０２０６】
次にジョブマネージャ２０５２は、ＵＲＩプリントリクエストからＵＲＬで指定された印刷データ（実際には親サブデータ２１７２）をダウンロードするようＷｅｂクライアント２０５９に依頼し、Ｗｅｂクライアント２０５９は、ホスト装置２００１へＰｕｌｌ要求「Ｐｕｌｌ要求（ＳＤｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐ）」を送信する（Ｓ２６０３，Ｓ２４０３）。
【０２０７】
ホスト装置２００１のＷｅｂサーバ２０４７は、Ｐｕｌｌ要求を受け付け（Ｓ２５０５）、印刷データバッファ２０４５から親サブデータ２１２２（ＳＤｔｏｐｐａｇｅ．ｘｈｔｍｌｐ）を取り出し、印刷装置２００２に返送する（Ｓ２５０６，Ｓ２４０４）。
【０２０８】
Ｗｅｂクライアント２０５９は、ホスト装置２００１から親サブデータ２１７２を受け取ると（Ｓ２６０４）、ジョブマネージャ２０５２経由で、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６に受け渡し、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリタ２０５６は、親サブデータ２１２２にインタプリト処理を行い（Ｓ２６０５）、文書構造を示すＤＯＭツリー（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に変換する。
【０２０９】
ここで、ＸＨＴＭＬ−Ｐｒｉｎｔインタプリンタは、親サブデータ２１７２の処理が完了し、それ以降ホスト装置２００１上の親サブデータ２１７２を必要としないか判定し、必要がないと判定すると、プリンタマネージャ２０５４にその旨通知する。
【０２１０】
プリンタマネージャ２０５４は、プリンタステータスレコード２０５５のプリンタステータスフィールド２０７２にステータス値“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”を記入し、プリンタ状態通知イベントをホスト装置２００１に送信するようジョブマネージャ２０５２経由でＰＢＲデバイスポート２０５１に依頼する。
【０２１１】
ＰＢＲデバイスポート２０５１は、プリンタステータスフィールド２１０３に“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”をセットしたプリンタステータスパケット２１０１を作成し、ホスト装置２００１に送信する（Ｓ２９０１）。
【０２１２】
ＰＢＲクライアントポート２０４３は、プリンタ状態通知イベントを受け取るとプリントサービス２０４２に通知し、プリントサービス２０４２は、“ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”というイベント理由より、印刷データバッファ２０４５に格納されている親サブデータ２１７２を削除してよいと判断し（Ｓ３００１）、親サブデータ２１７２自体を削除するか、印刷データバッファ２０４５自体をＲＡＭ２０１３から削除する（Ｓ３００２，Ｓ２９０２）。
【０２１３】
以後の処理は、“ａｌｌ ｄａｔａ ｎｏ ｎｅｅｄ”というプリントステータスの通知に関する処理がないという点を除けば実施の形態３と同じである。
【０２１４】
以上のように、上記本実施の形態４では、印刷データが複数のサブデータよりなり、そのうち親サブデータが印刷データバッファに格納され、それ以外の子サブデータはリムバブルメモリカードメディア等の外部メモリに格納され、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で、プリンタステータスでその旨ホスト装置に通知し、通知を受けたホスト装置は親サブデータを削除する。
【０２１５】
これにより、ホスト装置は、印刷装置で早期に処理される親サブデータの処理完了のタイミングで、親サブデータの不要を知ることができるので実施の形態３と比べて、より早いタイミングで親サブデータを削除し印刷データバッファの解放ができる。親サブデータを早期に削除することのメリットであるが、印刷アプリケーションによっては、親サブデータがかなり大きくなる場合がある。この場合、親サブデータの格納のためにＲＡＭの空き領域が少なくなり、そのようなメモリが逼迫した状態では、印刷アプリケーションを終了して、別のアプリケーションを起動させようとしても、よりメモリを必要とするアプリケーションは起動できなかったり、起動できても動作が遅くなったりすることがある。この場合、本実施の形態４では、親サブデータの削除とメモリの解放を早期に行なえるので、メモリ逼迫状態からの復帰を早めることができ、その有用性は高い。
【０２１６】
（実施の形態５）
次いで、実施の形態５に係る他のアプリケーションについて説明する。
【０２１７】
本アプリケーションでは、印刷データが複数のサブデータよりなるが、親サブデータだけがホスト装置の印刷データバッファに格納され、子サブデータは、他のサーバ装置上に格納される場合である。この場合、ホスト装置の印刷データバッファからの印刷データの削除は、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で行なうのが妥当であり、実施の形態４と同じである。ホスト上の親サブデータが必要でなくなったことは、プリンタステータスとして印刷装置が通知することとする。
【０２１８】
図３９は、本実施形態５におけるサーバ装置、ホスト装置および印刷装置により構成されるネットワークプリントシステムのシステム構成図である。なお、図３９において、図１８と同一のものは同一の番号を付し、説明は省略する。
【０２１９】
図３９に示されるように、印刷システム３は、ホスト装置２００１と、印刷装置２００２にサーバ装置２００８を加えた３者間におけるネットワークプリントシステムである。ただし、印刷データはホスト装置２００１と、サーバ装置２００８上に分散しておかれるので、Ｗｅｂサーバ機能２００７はサーバ装置２００８だけでなく、ホスト装置２００１にも存在する。
【０２２０】
図４０は、本実施の形態５における印刷データの構成を示す図である。
印刷データ２２３１は、親サブデータ２２３２と、子サブデータ２２３３ａ〜２２３３ｃとから構成される。親サブデータ２２３２は、ＸＨＴＭＬ−Ｐｒｉｎｔ言語で記述された親サブデータであり、印刷データ２２３１のサブデータである。子サブデータ２２３３ａ〜２２３３ｃは、親サブデータ２２３２から参照される子サブデータであり、印刷データ２２３１のサブデータである。子サブデータ２２３３ａ〜２２３３ｃは画像データである。子サブデータ２２３３ａ〜２２３３ｃは、サーバ装置２００８上におかれ、親サブデータで対応付けがなされている。
【０２２１】
図４１は、印刷データの格納場所を示す図である。なお、図３０と同一のものについては、同じ番号を付し、説明を省略する。
【０２２２】
図４１に示されるように、サーバ装置２００８は、ハードディスク装置３４０１を備える。ハードディスク装置３４０１は、印刷データ等を格納するハードディスク装置である。本実施の形態５では親サブデータ２２３２のみがホスト装置上の印刷データバッファ２０４５に格納され、子サブデータ２２３３ａ〜２２３３ｃは、サーバ装置２００８上のハードディスク装置３４０１に格納される。この点で実施の形態４と異なる。
【０２２３】
図４２は、本実施の形態５におけるホスト装置２００１、印刷装置２００２、サーバ装置２００８との間の通信シーケンスを示す。なお、図３１、図３６と略同じであり、同一の処理を示すステップについては同じ番号を付している。また、実施の形態４と本実施の形態５との違いを、図３６と図４２を比較しながら説明する。
【０２２４】
図３６では、ステップＳ２４０３およびＳ２４０４において印刷装置２００２はＳＤｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐをＰｕｌｌ要求しているのに対して、図４２ではＳＶｔｏｐｐｐａｇｅ．ｘｈｔｍｌｐに対してＰｕｌｌ要求をしているが、印刷装置２００２での内部処理は、Ｐｕｌｌ要求対象親サブデータが異なるだけで、実施の形態４と同じである。
【０２２５】
図３６では、ステップＳ２４０５およびＳ２４０６においてＳＤｉｍｇ０１．ｊｐｇをホスト装置２００１にＰｕｌｌ要求しているのに対して、図４２ではサーバ装置２００８に対して、ＳＶｉｍｇ０１．ｊｐｇのＰｕｌｌ要求をしている。なお、ステップＳ２４０５での印刷装置２００２での内部処理は、Ｐｕｌｌするデータとアクセス先装置が異なる点を除けば、実施の形態４と同じである。また、ステップＳ２４０６でのサーバ装置２００８での内部処理は、取り扱う子サブデータが違う点を除けば、実施の形態４におけるホスト装置２００１での内部処理と同様である。
【０２２６】
ステップＳ２４０７〜Ｓ２４１０についても同様である。印刷データバッファ２０４５から親サブデータ２２３２を削除し、印刷データバッファを開放するタイミングも実施の形態４と同じである。
【０２２７】
以上のように、本実施の形態５では、印刷データが複数のサブデータよりなり、そのうち親サブデータがホスト装置の印刷データバッファに格納され、それ以外の子サブデータはサーバ装置に格納され、印刷装置が親サブデータの処理を終えて親サブデータが必要でなくなった時点で、プリンタステータスでその旨ホスト装置に通知し、通知を受けたホスト装置は親サブデータを削除する。
【０２２８】
これにより、ホスト装置は、印刷装置で早期に処理される親サブデータの処理完了のタイミングで、親サブデータの不要を知ることができるので実施の形態３と比べて、より早いタイミングで親サブデータを削除し印刷データバッファの解放ができる。
【０２２９】
また、実施の形態４とは異なり、親サブデータ不要の通知を受けた後は、データ通信は印刷装置とサーバ装置との間でのみ行なわれるのでホスト装置の負荷はなく、またホスト装置を停止しても印刷処理を継続することができる。本実施の形態５も、実施の形態４と同様に親サブデータがかなり大きくなる場合に、親サブデータの削除とメモリの解放を早期に行なえるので、メモリ逼迫状態からの復帰を早めることができ、その有用性は高い。
【０２３０】
なお、本実施の形態３〜５においてはプリンタステータスにより、印刷装置がホスト装置上の印刷データ全体または親サブデータが不要になったことを通知しているが、ジョブステータスの通知により行なってもよい。印刷データ全体に関するジョブステータスは図２５で示される“Ｐｒｏｃｅｓｉｎｇ−ｄａｔａ ｎｏ ｎｅｅｄ”であり、親データのみに関するステータスは、“Ｐｒｏｃｅｓｓｉｎｇ−ｐａｒｅｎｔ ｓｕｂ−ｄａｔａ ｎｏ ｎｅｅｄ”である。各々のジョブステータス値がジョブステータスフィールド２１１４にセットされて送られる。
【０２３１】
また、本実施の形態３〜５においては、印刷装置がホスト装置上の印刷データ全体または親サブデータが不要になったことを通知しているが、ホスト装置からの問い合わせに対して、プリンタステータスまたはジョブステータスを回答することにしてもよい。
【０２３２】
また、本実施の形態３，４においては、印刷装置とホスト装置はＬＡＮを介してネットワーク接続されているが、ＵＳＢ等により１対１に接続しても構わない。
【０２３３】
また、上記実施の形態１〜５では、１つのジョブにおいて画像オブジェクトが３つである場合（実施の形態１）などを例に挙げて説明したが、本発明では画像オブジェクトが３つのみに限定されるのではなく、複数である場合に適用されることはいうまでもない。
【０２３４】
また、上記実施の形態１〜５では、１つのジョブにおける印刷データの処理について説明したが、複数のジョブにおける印刷データの処理について、本願発明を適用することができるのはいうまでもない。
【０２３５】
すなわち、印刷指示装置（ホスト装置、文書画像供給装置）がジョブごとの印刷データを印刷バッファに保持する場合、再び印刷装置（画像形成装置、プリンタ）によって取得される必要性がないジョブの印刷データを、一連のジョブの印刷が完了する前に、印刷バッファから削除するようにしてもよい。この場合、例えば、印刷指示装置側では印刷装置に指示する複数のジョブを管理し、印刷装置側ではこれから印刷するジョブの内、既に読み込み済みのジョブを読み込み済みリストとして管理しておけばよい。なお、この読み込み済みリストは、対応するデータが以降、再読込不要であるものを管理するためのリストであることを意味する。
【０２３６】
より詳しくは、図４３に示されるように印刷指示装置（ホスト装置、文書画像供給装置）は、６個のプリントジョブ（Ｊｏｂ５〜Ｊｏｂ１０）のデータを印刷データバッファに格納し、ジョブリストで各ジョブのＩＤ、５，６，７，８，９，１０を管理しているものとする。そして、プリンタは、図４４に示されるように、Ｊｏｂ５，６，７のデータを既に取り込み、Ｊｏｂ８のデータの取り込み中で、Ｊｏｂ５のデータの印刷中であるものとする。この場合、プリンタは、Ｊｏｂ５，６，７のＩＤ５，６，７を読み込み済みリストとして管理しておけば、読み込み済みリストとしてＩＤ５，６，７をプリントステータスとして印刷指示装置に送ることにより、印刷指示装置はプリントステータスからＪｏｂ５，６，７のデータは不要であると判断することができ、Ｊｏｂ５，６，７のデータを印刷データバッファから素早く削除し、印刷データバッファを解放することができる。つまり、複数のジョブについても、本願発明を適用することができる。
【０２３７】
また、上記実施の形態では、子サブデータが画像データである場合、つまりＨＴＭＬが１つの場合について説明したが、子サブデータがＨＴＭＬであってもよく、画像データが子サブデータであるＨＴＭＬにリンクされる孫サブデータであってもよい。つまり親サブデータと子サブデータと、画像データをリンクするようにした場合についても、本願発明を適用することができる。
【産業上の利用可能性】
【０２３８】
本発明に係る印刷装置は、Ｐｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式で、かつホスト装置が印刷データのサーバ機能を持つ場合のプリンタ等に適用でき、本発明に係る印刷指示装置（ホスト装置、文書画像供給装置）は、自装置が印刷データのサーバ機能を持つ場合のＰｒｉｎｔ Ｂｙ Ｒｅｆｅｒｒｅｎｃｅ方式でのプリントホストとなるデジタルテレビや、セットトップボックス（ＳＴＢ）等に適用できる。
【特許請求の範囲】
【請求項１】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置であって、
サブデータを取得する印刷データ取得手段と、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、
前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知手段と
を備えることを特徴とする印刷装置。
【請求項２】
前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、
前記印刷データ取得手段は、子サブデータに先立って親サブデータを取得し、
前記判定手段は、取得された親サブデータが参照している子サブデータに基づいて前記必要性を判定する
ことを特徴とする請求項１記載の印刷装置。
【請求項３】
前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータの１箇所だけから参照されている場合に、前記必要性がないと判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項４】
前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータで以降参照されない場合に、前記必要性がないと判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項５】
前記親サブデータから参照される子サブデータには、前記子サブデータから参照される孫サブデータが含まれる
ことを特徴とする請求項２記載の印刷装置。
【請求項６】
前記判定手段は、前記親サブデータだけについて、前記必要性を判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項７】
前記通知手段は、前記印刷指示装置から前記通知の要求を受けた場合にだけ、前記通知をする
ことを特徴とする請求項１記載の印刷装置。
【請求項８】
前記通知手段は、前記印刷指示に前記通知の要求が含まれているか否かを判断し、含まれている場合にだけ、前記通知をする
ことを特徴とする請求項７記載の印刷装置。
【請求項９】
前記親サブデータは、マークアップ言語で記述され、
前記子サブデータは、マークアップ言語で記述されたデータを除くデータである
ことを特徴とする請求項２記載の印刷装置。
【請求項１０】
前記親サブデータは、ＨＴＭＬで記述され、
前記子サブデータは、画像データまたはスタイル情報データである
ことを特徴とする請求項９記載の印刷装置。
【請求項１１】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷方法であって、
サブデータを取得する印刷データ取得ステップと、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得ステップによって取得される必要性があるか否かを判定する判定ステップと、
前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知ステップと
を含むことを特徴とする印刷方法。
【請求項１２】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置のためのプログラムであって、
請求項１１記載の印刷方法に含まれるステップをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１３】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置であって、
少なくとも１つのサブデータを保持する印刷バッファと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、
出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信手段と、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段と
を備えることを特徴とする印刷指示装置。
【請求項１４】
前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、
前記印刷バッファは、前記印刷データを構成するサブデータのうち、親サブデータだけを保持し、
前記削除手段は、前記親サブデータを前記印刷バッファから削除する
ことを特徴とする請求項１３記載の印刷指示装置。
【請求項１５】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置における印刷バッファのメモリ解放制御方法であって、
少なくとも１つのサブデータを前記印刷バッファに格納するステップと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力ステップと、
出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信ステップと、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除ステップと
を含むことを特徴とするメモリ解放制御方法。
【請求項１６】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置のためのプログラムであって、
請求項１５記載のメモリ解放制御方法に含まれるステップをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１７】
印刷装置と、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置とから構成される印刷システムであって、
前記印刷装置は、
サブデータを取得する印刷データ取得手段と、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、
前記必要性がないと判定された場合に、その旨を、前記印刷指示装置に通知する通知手段とを備え、
前記印刷指示装置は、
少なくとも１つのサブデータを保持する印刷バッファと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、
前記通知手段から前記通知を受信する必要性受信手段と、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段と
を備えることを特徴とする印刷システム。
【請求項１８】
印刷装置と、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置とから構成されるシステムにおける印刷方法であって、
前記印刷指示装置の印刷バッファに保持されたサブデータを前記印刷装置に転送する転送ステップと、
転送されたサブデータが、前記印刷装置において前記印刷データの印刷を完了するために再び前記印刷指示装置から前記印刷装置に転送される必要性があるか否かを判定する判定ステップと、
前記必要性がないと判定された場合に、その旨を、前記印刷装置から前記印刷指示装置に通知する通知ステップと、
前記通知が行われた場合に、前記印刷指示装置の印刷バッファに保持されたサブデータを削除する削除ステップと
を含むことを特徴とする印刷方法。
【請求項１】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置であって、
サブデータを取得する印刷データ取得手段と、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、
前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知手段と
を備えることを特徴とする印刷装置。
【請求項２】
前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、
前記印刷データ取得手段は、子サブデータに先立って親サブデータを取得し、
前記判定手段は、取得された親サブデータが参照している子サブデータに基づいて前記必要性を判定する
ことを特徴とする請求項１記載の印刷装置。
【請求項３】
前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータの１箇所だけから参照されている場合に、前記必要性がないと判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項４】
前記判定手段は、前記印刷データ取得手段によって取得された子サブデータが前記親サブデータで以降参照されない場合に、前記必要性がないと判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項５】
前記親サブデータから参照される子サブデータには、前記子サブデータから参照される孫サブデータが含まれる
ことを特徴とする請求項２記載の印刷装置。
【請求項６】
前記判定手段は、前記親サブデータだけについて、前記必要性を判定する
ことを特徴とする請求項２記載の印刷装置。
【請求項７】
前記通知手段は、前記印刷指示装置から前記通知の要求を受けた場合にだけ、前記通知をする
ことを特徴とする請求項１記載の印刷装置。
【請求項８】
前記通知手段は、前記印刷指示に前記通知の要求が含まれているか否かを判断し、含まれている場合にだけ、前記通知をする
ことを特徴とする請求項７記載の印刷装置。
【請求項９】
前記親サブデータは、マークアップ言語で記述され、
前記子サブデータは、マークアップ言語で記述されたデータを除くデータである
ことを特徴とする請求項２記載の印刷装置。
【請求項１０】
前記親サブデータは、ＨＴＭＬで記述され、
前記子サブデータは、画像データまたはスタイル情報データである
ことを特徴とする請求項９記載の印刷装置。
【請求項１１】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷方法であって、
サブデータを取得する印刷データ取得ステップと、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得ステップによって取得される必要性があるか否かを判定する判定ステップと、
前記必要性がないと判定された場合に、その旨を、前記印刷指示を発した印刷指示装置に通知する通知ステップと
を含むことを特徴とする印刷方法。
【請求項１２】
印刷指示を受けると、複数のサブデータから構成される印刷データを取得して印刷する印刷装置のためのプログラムであって、
請求項１１記載の印刷方法に含まれるステップをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１３】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置であって、
少なくとも１つのサブデータを保持する印刷バッファと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、
出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信手段と、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段と
を備えることを特徴とする印刷指示装置。
【請求項１４】
前記印刷データには、１つの親サブデータと前記親サブデータから参照される１つ以上の子サブデータが含まれ、
前記印刷バッファは、前記印刷データを構成するサブデータのうち、親サブデータだけを保持し、
前記削除手段は、前記親サブデータを前記印刷バッファから削除する
ことを特徴とする請求項１３記載の印刷指示装置。
【請求項１５】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置における印刷バッファのメモリ解放制御方法であって、
少なくとも１つのサブデータを前記印刷バッファに格納するステップと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力ステップと、
出力されたサブデータが、前記印刷データの印刷を完了するために再び前記印刷装置によって取得される必要性がない旨の通知を前記印刷装置から受信する必要性受信ステップと、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除ステップと
を含むことを特徴とするメモリ解放制御方法。
【請求項１６】
複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置のためのプログラムであって、
請求項１５記載のメモリ解放制御方法に含まれるステップをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１７】
印刷装置と、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置とから構成される印刷システムであって、
前記印刷装置は、
サブデータを取得する印刷データ取得手段と、
取得されたサブデータが、前記印刷データの印刷を完了するために再び前記データ取得手段によって取得される必要性があるか否かを判定する判定手段と、
前記必要性がないと判定された場合に、その旨を、前記印刷指示装置に通知する通知手段とを備え、
前記印刷指示装置は、
少なくとも１つのサブデータを保持する印刷バッファと、
前記印刷バッファに保持されたサブデータを前記印刷装置に出力する印刷データ出力手段と、
前記通知手段から前記通知を受信する必要性受信手段と、
前記通知が受信された場合に、前記通知に対応するサブデータを前記印刷バッファから削除する削除手段と
を備えることを特徴とする印刷システム。
【請求項１８】
印刷装置と、複数のサブデータから構成される印刷データの印刷を印刷装置に指示する印刷指示装置とから構成されるシステムにおける印刷方法であって、
前記印刷指示装置の印刷バッファに保持されたサブデータを前記印刷装置に転送する転送ステップと、
転送されたサブデータが、前記印刷装置において前記印刷データの印刷を完了するために再び前記印刷指示装置から前記印刷装置に転送される必要性があるか否かを判定する判定ステップと、
前記必要性がないと判定された場合に、その旨を、前記印刷装置から前記印刷指示装置に通知する通知ステップと、
前記通知が行われた場合に、前記印刷指示装置の印刷バッファに保持されたサブデータを削除する削除ステップと
を含むことを特徴とする印刷方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【国際公開番号】ＷＯ２００５／０６９１１９
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【発行日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【出願番号】特願２００５−５１７１０３（Ｐ２００５−５１７１０３）
【国際出願番号】ＰＣＴ／ＪＰ２００５／０００５３９
【国際出願日】平成１７年１月１８日（２００５．１．１８）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【発行日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【国際出願番号】ＰＣＴ／ＪＰ２００５／０００５３９
【国際出願日】平成１７年１月１８日（２００５．１．１８）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]