JP2006168134A - 印刷方法、印刷デバイス及び印刷システム - Google Patents

Abstract

【課題】 印刷処理を中断することなく、印刷デバイスが印刷可能状態に復帰したあと、自動的に印刷を実行することができ、ユーザにとっての煩雑な印刷処理のための操作を行なう必要がなくなり、効率のよい印刷処理を実行することが可能な印刷手段、印刷デバイス及び印刷システムを提供する。
【解決手段】 印刷データを受信したプリンタは、自身の状態を判断し、印刷不可能である場合にはネットワーク上のストレージサーバを検索し、印刷データを一時的に当該ストレージサーバに格納しておく。印刷可能状態になると、前記ストレージサーバから印刷データを取得し印刷処理を行う。
【選択図】 図１９

Description

本発明は、印刷方法、印刷デバイス及び印刷システム、特に端末装置とネットワークに接続され、自身の機能を用いたサービスを端末装置に対して提供することが可能なサービス提供装置、印刷装置、データ保存装置による印刷方法、印刷デバイス及び印刷システムに関する。

近年、インターネットなど大規模なネットワークの普及に伴い、ネットワーク技術が飛躍的に向上している中で、ＸＭＬ、ＳＯＡＰなどのＷＷＷ関連の技術を用いて、ネットワークで接続された機器間の連携によって、さまざまなネットワーク上のサービスを利用できるようにしたＷｅｂサービスと呼ばれる技術が注目を集めている。

その中でも、ネットワーク上に接続された端末から、ネットワーク上からの印刷要求を受け付け、印刷を実行することが可能な複数の印刷デバイスを検索し、所望の機能を有した印刷デバイスから印刷を行う印刷サービスと呼ばれるサービスや、ネットワーク上の端末装置などからサーバ装置のハードディスクなど大容量の記憶媒体を利用して、各種データの保存や読み出しを行うことが可能な複数のサーバ装置を検索し、所望の機能を有したサーバ装置に対して各種データの保存や読み出しをおこなうストレージサービスと呼ばれるサービス等が利用されつつある（例えば、特許文献１参照）。

このようなサービスを提供する機器は、サービスを開始していることを通知するとともに、機器情報やサービス内容をネットワーク上に公開する。ネットワークに接続されている端末装置はそれらの公開されている情報を取得、あるいは検索することによって、ネットワーク上のサービスにアクセスすることが可能となり、印刷サービスやストレージサービス等を利用することができる。
特開２００４−１６４２３６号公報

しかしながら、上記の印刷サービスを提供する印刷デバイスによって印刷を行おうとした場合に、印刷デバイスが紙詰まりを起こしていたり、印刷デバイスが多数の印刷ジョブを受け付け、印刷処理を実行していることによって、印刷デバイス自身のハードディスク装置の記憶可能領域が少なくなり、印刷データのスプールができないなど、印刷を実行できない場合には、印刷デバイスはクライアントからの印刷要求に対して印刷不可であるエラーを返すことしができない。

したがって、ユーザが端末装置から検索した所望の印刷デバイスによって印刷を実行したい場合には、その印刷デバイスが印刷可能の状態に復帰したことを何らかの方法で確認する必要があり、ユーザ自身によって印刷可能の状態に復帰したことを確認した後、再び印刷要求を送信するという非効率的な方法でしか印刷を行えなかった。

また、所望の印刷処理を実行可能である印刷デバイスがハードディスク装置を持たないような場合には、その印刷デバイスによって印刷を実行するときに、印刷デバイスが印刷データのスプールができないために、他の印刷ジョブが終了するまで、印刷を実行できないという問題があった。

本発明は、このような問題点に鑑みて為されたものであり、その目的とする処は、印刷処理を中断することなく、印刷デバイスが印刷可能状態に復帰したあと、自動的に印刷を実行することができ、ユーザにとっての煩雑な印刷処理のための操作を行なう必要がなくなり、効率のよい印刷処理を実行することが可能な印刷方法、印刷デバイス及び印刷システムを提供することにある。

本発明は上記課題を解決するために、以下のような印刷方法を有する。

端末装置からの印刷要求を受け付け、送信される印刷データの印刷を行う印刷サービスを提供する印刷デバイスの印刷方法において、ネットワークに接続された端末装置からの印刷要求を受信するステップと、印刷要求を受付けた際に、印刷デバイスの状態と印刷要求に含まれる印刷属性情報を元に、印刷デバイス自身が要求された印刷が可能であるかを判断するステップと、印刷が不可能である場合には、端末装置から送信される印刷データを保存可能なネットワーク上のストレージサービスを検索するステップと、検索したストレージサービスに対してデータ保存要求を送信し、ストレージサービスから返信されるデータ保存先の所在情報を含んだ応答を受信した後、印刷要求を送信した端末装置に印刷要求の応答として、そのストレージサービスから送信されるデータ保存先の所在情報を返信することによって、端末装置が印刷データをストレージサービスへ送信し、その印刷データをストレージサービスに保存させるステップと、上記の印刷データの保存が完了した際に、ストレージサービスから送信されるデータ保存完了イベント通知を受信するステップと、ストレージサービスへのデータ保存が完了した後、印刷デバイス自身の状態を監視し、印刷デバイスが印刷可能であると判断した場合には、ストレージサービスから印刷データの読み出しをするためのデータ読み出し要求を送信し、ストレージサービスから返信されるデータ保存先の所在情報を含んだ応答に基づき、ストレージサービスから印刷データを受信するステップと、ストレージサービスから受信した印刷データを、端末装置の印刷要求に含まれる印刷属性に基づき印刷するステップと、印刷が完了した後、ストレージサービスに保存されている印刷データを削除するステップと、全ての印刷処理が終了したことを告げる、印刷終了イベント通知を端末装置に送信することで印刷処理を終了するステップを含んだ印刷方法によってネットワークを介した印刷処理を行なうことを特徴とする。

本発明によれば、印刷処理を中断することなく、印刷デバイスが印刷可能状態に復帰したあと、自動的に印刷を実行することができ、ユーザにとっての煩雑な印刷処理のための操作を行なう必要がなくなり、効率のよい印刷処理を実行することが可能な印刷方法、印刷デバイス及び印刷システムを提供することができる。

以下本発明の実施例について、図面を参照しながら説明する。

図１は本発明のサービス検索を行う一実施形態の構成を示す図である。

本実施形態は、印刷サービスによる印刷を実行するユーザ端末装置１０１と、印刷サービス提供機器である印刷デバイス１０２と、ストレージサービス提供機器であるサーバ装置１０３とから構成される。これらの端末装置１０１、印刷デバイス１０２、サーバ装置１０３は、ネットワーク１００を介して接続され、相互にデータの通信を行うことができるようになっており、全てネットワーク対応デバイスである。なお、ここではユーザ端末装置１０１、印刷デバイス１０２、サーバ装置１０３をそれぞれ１つのみ示しているが、これらは複数であっても良い。

図２は、一般的なユーザ端末装置及び、サーバ装置のハードウェア構成を示すブロック図である。図２において、２００はコンピュータＰＣあるいはＷＳであり、図１におけるユーザ端末装置１０１、サーバ装置１０３と同等である。ＰＣ２００は、ＣＰＵ２０１を備え、ＲＯＭ２０２またはハードディスク（ＨＤ）２１１に記憶された、あるいはフロッピー（登録商標）ディスクドライブ（ＦＤ）２１２に格納されるプログラムを実行し、システムバス２０４に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイスからの指示入力を制御する。

２０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。２０７はディスクコントローラ（ＤＫＣ）で、ブートプログラム（起動プログラム：パソコンのハードやソフトの実行（動作）を開始するプログラム）、複数のアプリケーション、編集ファイル、ユーザファイルそしてネットワーク管理プログラム等を記憶するハードディスク（ＨＤ）２１１、及びフロッピー（登録商標）ディスク（ＦＤ）２１２とのアクセスを制御する。ストレージサービスを提供するサーバ装置のハードディスク（ＨＤ）２１１には、サービス利用者であるネットワーク上の端末装置が利用可能な記憶領域が設定されており、サービス利用者によって送信されるさまざまな形式のデータを保存することができる。

２０８はネットワークＩ／Ｆ制御部で、ＬＡＮ２１３を介して、印刷デバイスなど、他のネットワーク機器と双方向のデータのやり取りを行う。なお、本実施形態においては、ＬＡＮ２１３は図１におけるネットワーク１００と同じものである。

第３図は、本発明の実施形態における印刷デバイスのハードウェア構成を示すブロック図である。図３において、３００は印刷デバイスであり、図１における印刷デバイス１０２と同等である。印刷デバイス３００は、ＣＰＵ（中央処理装置）３０１を備えている。このＣＰＵ３０１は、ＲＯＭ（リードオンリーメモリ）３０２またはハードディスク３１０に格納されているプログラムを実行して、システムバス３０４に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。３０３はＲＡＭ（ランダムアクセスメモリ）で、ＣＰＵ３０１の主メモリ、ワークエリアとして機能する。

３０５は、プリンタＩ／Ｆ制御部であり、プリンタ３０６を制御する装置である。上記ＭＦＰ３００のＣＰＵ３０１、ＲＯＭ３０２またはハードディスク３１０に記憶されたプログラムにより、本実施形態の各手段が構成される。３０７は不揮発性のメモリＮＶＲＡＭであり印刷デバイスの各種設定値を保存するためのものである。パネル制御部３０８は、オペレーションパネル３０９を制御し、各種情報の表示、使用者からの指示入力を行なう。ネットワークＩ／Ｆ制御部３１１は、ＬＡＮ３１２とのデータの送受信を制御する。なお、本実施形態においては、ＬＡＮ３１０は図１におけるネットワーク１００と同じものである。

第４図は、本発明の実施形態におけるユーザ端末装置２００のソフトウェア構成を示すブロック図である。印刷アプリケーション４０１は、ユーザの指示操作によって印刷を実行するアプリケーションであり、印刷処理制御部へ印刷データを渡す。印刷処理制御部４０２は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。サービス検索処理部４０３は本実施形態におけるサービスの検索を実行するための処理を行なうモジュールであり、検索に関する処理を行なう。ネットワークドライバ４０８は、図２におけるネットワークＩ／Ｆ制御部２０８を制御し、ネットワーク４０９とのデータ送受信の制御を行う。

ＴＣＰ／ＩＰ制御部４０７は、ＴＣＰ／ＩＰプロトコルによるデータの送受信及び制御を行なう。ＨＴＴＰクライアントは、ＨＴＴＰプロトコルのクライアント機能を有しており、上位アプリケーションの指示によりＨＴＴＰリクエストパケットを印刷デバイス、サーバ装置に送信するとともに、印刷デバイス、サーバ装置から送信された、ＨＴＴＰレスポンスパケットを解析して、データをＳＯＡＰ制御部４０４、サービス検索処理部４０３や印刷処理制御部４０２等の上位アプリケーションにわたす処理を行なう。

ＳＯＡＰ制御部４０４はＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルを制御するモジュールであり、印刷デバイス、サーバ装置から受信したＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ ＬＡＮｇｕａｇｅ）形式のデータをＸＭＬパーサ４０５を使用して解析し、印刷処理制御部４０２の適切なモジュールを呼び出したり、サービス検索処理部４０３へ印刷デバイス、サーバ装置から送信されるサービス検索応答などのデータを渡すと同時に、印刷デバイス、サーバ装置に送信すべきデータをＸＭＬデータに変換し、ＨＴＴＰクライアント制御部５０６を介して印刷デバイス、サーバ装置に送信する制御を行なう。ＸＭＬパーサ５０５はＸＭＬ形式データを入力とし解析結果を出力するモジュールである。

第５図は、本発明の実施形態におけるサーバ装置２００のソフトウェア構成を示すブロック図である。ストレージデータ処理部５０１は、サーバ装置の提供するストレージサービスを実行するためのモジュールであり、ネットワーク上の他の機器からの各種データの保存やデータ読み出し等の必要な処理を行なう。サービス検索処理部５０２は本実施形態におけるサービスの検索を実行するための処理を行なうモジュールであり、検索に関する処理を行なう。

ネットワークドライバ４０７は、図２におけるネットワークＩ／Ｆ制御部２０８を制御し、ネットワーク５０８とのデータ送受信の制御を行う。ＴＣＰ／ＩＰ制御部５０６は、ＴＣＰ／ＩＰプロトコルによるデータの送受信及び制御を行なう。ＨＴＴＰサーバ５０５は、ＨＴＴＰプロトコルのサーバ機能を有しており、 印刷デバイスあるいは端末装置から受信したＨＴＴＰリクエストパケットを解析して、データをＳＯＡＰ制御部５０３、サービス検索処理部５０２やストレージデータ処理部５０１等の上位アプリケーションにわたすと共に、上位アプリケーションの指示によりＨＴＴＰレスポンスパケットを印刷デバイス、端末装置に返信する制御を行なう。

ＳＯＡＰ制御５０３はＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルを制御するモジュールであり、印刷デバイス、端末装置から受信したＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ ＬＡＮｇｕａｇｅ）形式のデータを、ＸＭＬパーサ５０４を使用して解析し、ストレージデータ処理部５０１の適切なモジュールを呼び出したり、サービス検索処理部５０２へ印刷デバイス、端末装置から送信されるサービス検索要求などのデータを渡すと同時に、印刷デバイスに送信すべきデータをＸＭＬデータに変換し、ＨＴＴＰサーバ制御部５０５を介して印刷デバイス、端末装置に返信する制御を行なう。ＸＭＬパーサ５０４はＸＭＬ形式データを入力とし解析結果を出力するモジュールである。

第６図は、本発明の実施形態における印刷デバイス３００のソフトウェア構成を示すブロック図である。プリンタ制御部６０１は、図３におけるプリンタＩ／Ｆ制御部３０５を制御して、図３におけるプリンタ３０６へのデータ送信、排紙制御などを行う。印刷処理制御部６０２は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。

サービス検索処理部６０３は本実施形態におけるサービスの検索を実行するための処理を行なうモジュールであり、検索に関する処理を行なう。ネットワークドライバ６０８は、図３におけるネットワークＩ／Ｆ制御部３１１を制御し、ネットワーク６０９とのデータ送受信の制御を行う。ＴＣＰ／ＩＰ制御部６０７は、ＴＣＰ／ＩＰプロトコルによるデータの送受信及び制御を行なう。ＨＴＴＰサーバ・クライアントは、ＨＴＴＰプロトコルのサーバ機能及びクライアント機能を有しており、サーバ機能として端末装置から受信したＨＴＴＰリクエストパケットを解析して、データをＳＯＡＰ制御部６０４、サービス検索処理部５０３や印刷処理制御部６０２等の上位アプリケーションにわたすと共に、上位アプリケーションの指示によりＨＴＴＰレスポンスパケットを端末装置に返信する制御を行なう。

さらにクライアント機能として上位アプリケーションの指示によりＨＴＴＰリクエストパケットをネットワーク上のサーバ装置に送信するとともに、サーバ装置から返信された、ＨＴＴＰレスポンスパケットを解析して、データをＳＯＡＰ制御部６０４、サービス検索処理部６０３や印刷処理制御部６０２等の上位アプリケーションにわたす処理を行なう。ＳＯＡＰ制御部６０４はＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルを制御するモジュールであり、端末装置、サーバ装置から受信したＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ ＬＡＮｇｕａｇｅ）形式のデータをＸＭＬパーサ６０５を使用して解析し、印刷処理制御部６０２の適切なモジュールを呼び出したり、サービス検索処理部６０３へ端末装置から送信されるサービス検索要求などのデータを渡すと同時に、端末装置に返すべきデータをＸＭＬデータに変換し、ＨＴＴＰサーバ・クライアント制御部６０６を介して端末装置に返信する制御を行なう。

同様にして、サービス検索要求の処理を行なう際には、サービス検索処理部６０３へサーバ装置から送信されるサービス検索応答などのデータを渡すと同時に、サーバ装置に送信すべきデータをＸＭＬデータに変換し、ＨＴＴＰサーバ・クライアント制御部６０６を介してサーバ装置に送信する制御を行なう。ＸＭＬパーサ６０５はＸＭＬ形式データを入力とし解析結果を出力するモジュールである。

以下に本実施形態における、端末装置から印刷デバイスによって印刷を行う場合の印刷デバイスの動作について述べる。

ここでは最初に、従来の印刷処理について述べた後、本実施形態におけるストレージサービスを利用した印刷デバイスの印刷実行処理方法について述べる。

図７は、本実施形態におけるＨＴＴＰ上のＳＯＡＰを用いて端末装置から印刷デバイスに送信されるＣｒｅａｔｅＪｏｂと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ＣｒｅａｔｅＪｏｂパケットは、印刷デバイスに対し、ジョブ（印刷）の開始を指示するコマンドであり、要求元のユーザ名（＜ｒｅｑｕｅｓｔｉｎｇ−ｕｓｅｒ−ｎａｍｅ＞タグ）やジョブの処理に関する指示（＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグ）等の情報が記述されている。＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグには印刷部数を設定する＜ｃｏｐｉｅｓ＞タグ、両面印刷を設定する＜ｓｉｄｅｓ＞タグ、印刷の仕上げを設定する＜ｆｉｎｉｓｈｉｎｇ＞タグなどが含まれ、印刷デバイスはこれらのタグに設定された値に基づき、ジョブの処理を行う。また、＜ｄａｔａｓｉｚｅ＞タグには、印刷データのデータサイズ（＜ｖａｌｕｅ＞タグ）と、データサイズの単位（＜ｕｎｉｔ＞タグ）が記述されている。

さらに、＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはオプションとして＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグを含めることも可能である。この＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはジョブに関する通知情報が記述される。図６の例においては通知情報として、通知先を設定する＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｒｅｃｉｐｉｅｎｔ＞タグおよび通知条件を設定する＜ｅｖｅｎｔ＞タグが記述されている。印刷デバイスはこれらのタグに設定された値に基づいてイベント送信処理を行う。

図８は、図７のＣｒｅａｔｅＪｏｂパケットに対する応答パケットデータの一例である。本データも図７と同様にＸＭＬ形式で記述され、本実施形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ＣｒｅａｔｅＪｏｂ応答パケットには、ＣｒｅａｔｅＪｏｂコマンド対する結果コード（＜ｒｅｓｕｌｔ−ｃｏｄｅ＞タグ）や生成されたジョブの識別子（＜ｊｏｂ−ｉｄ＞タグ）、印刷用ポートのＵＲＩ（＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグ）等の情報が含まれている。

図９は、端末装置が印刷を行う場合における従来例の印刷デバイスの動作を示すフローチャートである。

以下、図９を用いて、従来例の印刷デバイスの動作を説明する。

端末装置から例えば図７に示したようなＣｒｅａｔｅＪｏｂパケットが印刷デバイスに送信されると、印刷デバイスはＳ９０１において、ＣｒｅａｔｅＪｏｂに記述されたＸＭＬデータを解析し、Ｓ９０２に進み印刷デバイス自身が印刷を実行できるか否かを判定する。印刷を実行可能であれば、Ｓ９０３において印刷データ受信用の印刷ポートを生成する。Ｓ９０３の処理が終わるとＳ９０４へ進み、ＣｒｅａｔｅＪｏｂパケットに対するレスポンスのＸＭＬデータの生成を行なう。このときに印刷データ受信用に生成したポートのＵＲＩを＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグの値として設定する。

例えば、図８の例のようなＵＲＩがＸＭＬデータに埋め込まれる。ＣｒｅａｔｅＪｏｂレスポンスデータの生成が終了するとＳ９０５へ進み、そのデータをＳＯＡＰを用いて端末装置に送信する。端末装置は、その後、＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグで指定されたＵＲＩに対してＨＴＴＰのＰＯＳＴメソッドを用いて印刷データを送信する。図１０はＨＴＴＰ ＰＯＳＴメソッドによる印刷データ転送パケットの一例である。印刷デバイスはＳ９０６において印刷ポートに到着したデータを受信し、適切な処理をしながらプリンタに印刷する。Ｓ９０６において、印刷データの受信が正常に終了すると印刷デバイスはＳ９０７において図１１に示した例のようなＨＴＴＰレスポンスパケットを端末装置に送信し、印刷用ポートを削除（クローズ）して印刷動作を終了する。一方、Ｓ９０２において印刷デバイス自身が印刷を実行できないと判定された場合はＳ９０８へ進み、エラーレスポンスデータを生成する。図１２はエラーレスポンスの例である。次にＳ９０５においてエラーレスポンスを端末装置に送信すると、端末装置は印刷データを送信することはせず、処理を終了する。

上記の従来例の印刷処理において、図９に示されるＳ９０２で印刷デバイスが印刷を実行できない場合には、端末装置から要求された印刷処理を中断せざるを得なかった。そこで、本実施形態では、印刷デバイスが印刷をできない場合に、印刷データをネットワーク上で提供されるストレージサービスを利用して、印刷データをファイルとして一時的に他のストレージに保存し、印刷印刷デバイスが印刷可能な状態に復旧した後、ストレージサービスから保存されている印刷データを受信して、そのデータを印刷する。

これによって、端末装置から印刷要求があった場合に、印刷デバイスが印刷ができない状態であっても、プリントサービスを提供する印刷デバイスとストレージサービスを提供するサーバ装置の連携によって、印刷処理を中断することなく、印刷デバイスが印刷可能状態に復帰したあと、自動的に印刷を実行することができる。さらに、ユーザが端末装置から印刷要求を再送するような猥雑な処理を行なうことなく、かつ、同時に端末装置の印刷処理を早期に開放することが可能になる。

次に、本実施形態におけるストレージサービスを利用した印刷処理の印刷デバイスの動作について述べる。

図１３は本実施形態におけるＨＴＴＰ上のＳＯＡＰを用いて印刷デバイスからストレージサービスを提供しているサーバ装置に送信されるＣｒｅａｔｅＦｉｌｅと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ＣｒｅａｔｅＦｉｌｅパケットは、サーバ装置に対し、ジョブ（データの保存）の開始を指示するコマンドであり、要求元のユーザ名（＜ｒｅｑｕｅｓｔｉｎｇ−ｕｓｅｒ−ｎａｍｅ＞タグ）やジョブの処理に関する指示（＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグ）等の情報が記述されている。＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグには保存するデータのファイル名を指定する＜ｆｉｌｅ−ｎａｍｅ
＞タグ、保存するファイルのアクセス権を指定する＜ｒｅａｄ−ｏｎｌｙ＞タグなどが含まれ、サーバ装置はこれらのタグに設定された値に基づき、ジョブの処理を行う。

さらに、＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはオプションとして＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグを含めることも可能である。この＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはジョブに関する通知情報が記述される。図１３の例においては通知情報として、通知先を設定する＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｒｅｃｉｐｉｅｎｔ＞タグおよび通知条件を設定する＜ｅｖｅｎｔ＞タグが記述されている。印刷デバイスはこれらのタグに設定された値に基づいてイベント送信処理を行う。本実施形態のＣｒｅａｔｅＦｉｌｅパケットデータでは、ファイルの保存終了したことを通知するイベントを返信する指定が＜ｅｖｅｎｔ＞ｊｏｂ−ｃｏｍｐｌｅｔｅｄ＜／ｅｖｅｎｔ＞として記述されている。


図１４は、図１３のＣｒｅａｔｅＦｉｌｅパケットに対する応答パケットデータの一例である。本データも図１３と同様にＸＭＬ形式で記述され、本実施形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ＣｒｅａｔｅＦｉｌｅ応答パケットには、ＣｒｅａｔｅＦｉｌｅコマンドに対する結果コード（＜ｒｅｓｕｌｔ−ｃｏｄｅ＞タグ）や生成されたファイルの識別子（＜ｆｉｌｅ−ｉｄ＞タグ）、データの送信先情報を示すデータの受信用ポートであるＵＲＩ（＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグ）等の情報が含まれている。

図１５は本実施形態におけるＨＴＴＰ上のＳＯＡＰを用いて印刷デバイスからストレージサービスを提供しているサーバ装置に送信されるＲｅａｄＤａｔａと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ＲｅａｄＤａｔａパケットは、サーバ装置に対し、ジョブ（ストレージに保存されているファイルデータの読み出し）の開始を指示するコマンドであり、要求元のユーザ名（＜ｒｅｑｕｅｓｔｉｎｇ−ｕｓｅｒ−ｎａｍｅ＞タグ）と読み出す対象となるファイルの識別子（＜ｆｉｌｅ−ｉｄ＞タグ）の情報が記述されている。ファイル識別子は図１４に示したＣｒｅａｔｅＦｉｌｅ応答パケットでサーバ装置から返されるファイルの識別子と同じである。このファイル識別子によってサーバ装置上に保存されている印刷デバイスが読み出したい所望のファイル（印刷データ）を指定する。サーバ装置はこれらのタグに設定された値に基づき、ジョブの処理を行う。本実施形態においては、このパケットを印刷可能状態に復帰した印刷デバイスが送信することによって、ストレージサービスに保存されている印刷データの所在情報を取得し、その所在情報を元に印刷データを取得し、プルプリントを実行することが可能になる。

図１６は、図１５のＲｅａｄＦｉｌｅパケットに対する応答パケットデータの一例である。本データも図１３と同様にＸＭＬ形式で記述され、本実施形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ＲｅａｄＦｉｌｅ応答パケットには、ＲｅａｄＦｉｌｅコマンドに対する結果コード（＜ｒｅｓｕｌｔ−ｃｏｄｅ＞タグ）と取得したいデータの所在情報であるデータのＵＲＩ（＜ｄａｔａ−ｓｏｕｒｃｅ−ｕｒｉ＞タグ）等の情報が含まれている。

図１７は本実施形態におけるＨＴＴＰ上のＳＯＡＰを用いて印刷デバイスからストレージサービスを提供しているサーバ装置に送信されるＤｅｌｅｔｅＦｉｌｅと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ＤｅｌｅｔｅＦｉｌｅパケットは、サーバ装置に対し、ジョブ（ストレージに保存されているファイルデータの削除）の開始を指示するコマンドであり、要求元のユーザ名（＜ｒｅｑｕｅｓｔｉｎｇ−ｕｓｅｒ−ｎａｍｅ＞タグ）と読み出す対象となるファイルの識別子（＜ｆｉｌｅ−ｉｄ＞タグ）の情報が記述されている。ファイル識別子は図１４に示したＤｅｌｅｔｅＦｉｌｅ応答パケットでサーバ装置から返されるファイルの識別子と同じである。このファイル識別子によってサーバ装置上に保存されている印刷デバイスが削除したい所望のファイル（印刷データ）を指定する。サーバ装置はこれらのタグに設定された値に基づき、ジョブの処理を行う。本実施形態において、このパケットを印刷デバイスが送信することによって、ストレージサービスに保存されている印刷データをプルプリントした後、サーバ上に保存されている印刷データの削除が可能になる。

図１８は、図１７のＤｅｌｅｔｅＦｉｌｅパケットに対する応答パケットデータの一例である。本データも図１３と同様にＸＭＬ形式で記述され、本実施形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ＤｅｌｅｔｅＦｉｌｅ応答パケットには、ＤｅｌｅｔｅＦｉｌｅコマンドに対する結果コード（＜ｒｅｓｕｌｔ−ｃｏｄｅ＞タグ）等の情報が含まれている。

図１９は本実施形態における、印刷デバイスが端末装置からの印刷要求の受付け時に印刷が実行できない状態にあるとき、ネットワーク上のストレージサービスを利用して印刷データをスプールし、印刷可能状態に復帰したあとで印刷を行なう場合の印刷デバイスの動作を示すフローチャートである。

以下図１９を用いて本実施形態の印刷デバイスの動作を説明する。

図１９においてＳ１９０１からＳ１９０２のステップは図９のＳ９０１からＳ９０２の動作と同じである。Ｓ１９０２のステップにおいて印刷デバイスが印刷可能である場合には次のステップＳ１９０３へ進む。Ｓ１９０３の処理は図９におけるＳ９０３からＳ９０８の処理と同じである。

Ｓ１９０２において印刷デバイスが、紙ジャム発生時や、ハードディスクのＦＵＬＬ状態、あるいはハードディスクをもたずデータスプールが不可能といった理由によって印刷ができないような場合には、Ｓ１９０４へ進む。

本実施形態において、印刷デバイス自身がハードディスク装置などのスプール可能な記憶装置を持つ場合に、印刷データがスプール可能であるかの判断は、デバイス自身が図７に示したＣｒｅａｔＪｏｂパケットの＜ｄａｔａｓｉｚｅ＞タグに記述されている印刷データのデータサイズと、印刷デバイスの記憶可能なデータ領域を比較することによって、印刷データをスプール可能か否かを判断する。

Ｓ１９０４において、印刷デバイスは端末装置が送信する印刷データの保存をストレージサービスに対して行なうために、所望の利用可能なストレージサービスの検索を行なう。次に、Ｓ１９０５において検索が成功したか否かの判断を行ない、検索が成功した場合には次のステップへ進む。Ｓ１９０６において印刷デバイスはＳ１９０４において検索したストレージサービスを利用するために、図１３に示したようなＸＭＬ形式のＣｒｅａｔｅＦｉｌｅパケットを生成し、サービス提供しているサーバ装置へＳＯＡＰを用いて送信する。Ｓ１９０７おいてストレージサービスから図１４に示したようなＣｒｅａｔｅＦｉｌｅ応答パケットを受信し、次のステップへ進む。

Ｓ１９０９では、Ｓ１９０１において端末装置から送信された、ＣｒｅａｔｅＪｏｂパケットに対するレスポンスのＸＭＬデータの生成を行なう。このとき、Ｓ１９０７において受信したＣｒｅａｔｅＦｉｌｅ応答パケットに記述されているストレージサービスの保存データ受信用ポートのＵＲＩをＣｒｅａｔｅＪｏｂ応答パケットの＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグの値として設定する。ＣｒｅａｔｅＪｏｂレスポンスデータの生成が終了するとＳ１９１０へ進み、そのレスポンスデータをＳＯＡＰを用いて端末装置に送信する。

端末装置は、その後、＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグで指定されたＵＲＩに対してＨＴＴＰのＰＯＳＴメソッドを用いて印刷データを送信する。ＨＴＴＰ ＰＯＳＴメソッドによる印刷データ転送パケットは図１０に示したパケットデータと同じパケットフォーマットである。サーバ装置は受信ポートに到着したデータを受信し、適切な処理をしながら自身のストレージ領域にデータを保存する。印刷データの受信が正常に終了するとサーバ装置は図２０に示した例のようなＮｏｔｉｆｙイベントを印刷デバイスに送信し、データを受信したことを通知した後、データ保存用ポートを削除（クローズ）してデータ保存動作を終了する。

一方、Ｓ１９０５において印刷データの保存が可能なストレージサービスの検索に失敗、あるいは、Ｓ１９０８においてＣｒｅａｔｅＦｉｌｅ要求のレスポンスがエラーとなり、ストレージサービスを利用できないと判定された場合はＳ１９０８へ進み、エラーレスポンスデータを生成する。エラーレスポンスは図１２に示したエラーレスポンスの例と同じである。次にＳ１９１０においてエラーレスポンスを端末装置に送信すると、端末装置は印刷データを送信することはせず、処理を終了する。

Ｓ１９１１においてストレージサービスへの印刷データの保存が正常に終了したことを告げるイベントメッセージを印刷デバイスが受信した後、印刷デバイスはＳ１９１２において自身の印刷機能が復旧したか否かの判断を行なう。印刷機能が復旧している場合には次のステップＳ１９１４へ進む。復旧していない場合にはＳ１９１３へ進み、一定時間待機した後、Ｓ１９１２の判断へ戻り、自身の機能が復帰するまで自身の機能を監視し、その判断を繰り返す。

本実施形態では、自身の機能が復帰するまで印刷デバイス自身がそれを定期的に監視して、その判断の処理を繰り返しポーリングしているが、その他の実施形態として、印刷機能が復帰したら印刷デバイス内部で印刷機能が復帰したことを告げるイベントを発行し、印刷機能復帰の判断を行なっても良い。また、一定期間の間、印刷機能が復帰しない場合には、印刷エラーとして端末装置にエラーイベントを発行し、処理を終了することも可能とする。その際には後述するストレージサービスに保存されている印刷データの削除手段によって、サーバ装置の印刷データの削除を行なうことが望ましい。

自身の印刷機能が復帰した印刷デバイスはＳ１９１４において、ストレージサービスに保存されている印刷データを取得・印刷を実行するために、図１５に示したようなＲｅａｄＦｉｌｅパケットのＸＭＬデータの生成を行なう。このとき、Ｓ１９０７において受信したＣｒｅａｔｅＦｉｌｅ応答パケットに記述されているストレージサービスの保存データのファイル識別子を＜ｆｉｌｅ−ｉｄ＞タグの値として設定し、ＳＯＡＰを用いてサーバ装置へ送信する。

ＲｅａｄＦｉｌｅパケットを受信したサーバ装置は、ＲｅａｄＦｉｌｅパケットに含まれる＜ｆｉｌｅ−ｉｄ＞タグに設定された値を元に、ストレージサービスに保存されているデータの送信用ポートであるＵＲＩを含む、図１６に示したようなＸＭＬで記述されたＲｅａｄＦｉｌｅ応答パケットを印刷デバイスへ返信する。Ｓ１９１５においてサーバ装置からのＲｅａｄＦｉｌｅ応答パケットを受信した印刷デバイスは、ＸＭＬデータの解析を行う。

Ｓ１９１６において印刷デバイスは、ＲｅａｄＦｉｌｅ応答パケットの＜ｄａｔａ−ｓｏｕｒｃｅ−ｕｒｉ＞タグで指定されたＵＲＩに対してＨＴＴＰのＧＥＴメソッドを用いて印刷データの取得要求を送信し、Ｓ１９１７において印刷データを受信する。 ＨＴＴＰ ＧＥＴメソッドによる印刷データ転送パケットの一例を図２１に示す。Ｓ１９１８において、Ｓ１９０１で受信した印刷要求パケットに含まれる印刷属性情報に基づき、適切な処理をしながら受信したデータの印刷を行なう。

印刷が正常に終了したら、印刷デバイスはストレージサービスに保存されている印刷データを削除するために、Ｓ１９１９において図１７に示したようなＤｅｌｅｔｅＦｉｌｅパケットのＸＭＬデータの生成を行なう。このとき、Ｓ１９０７において受信したＤｅｌｅｔｅＦｉｌｅ応答パケットに記述されているストレージサービスの保存データのファイル識別子を＜ｆｉｌｅ−ｉｄ＞タグの値として設定し、 ＳＯＡＰを用いてサーバ装置へ送信する。

ＤｅｌｅｔｅＦｉｌｅパケットを受信したサーバ装置は、ＤｅｌｅｔｅＦｉｌｅパケットに含まれる＜ｆｉｌｅ−ｉｄ＞タグに設定された値を元に、ストレージサービスに保存されているデータを削除し、正常にファイルを削除した後、図１８に示したようなＸＭＬで記述されたＤｅｌｅｔｅＦｉｌｅ応答パケットを印刷デバイスへ返信する。

Ｓ１９２０において印刷デバイスはＤｅｌｅｔｅＦｉｌｅ応答パケットを受信してストレージサービスの保存データが削除された事を確認した後、Ｓ１９２１において端末装置に印刷が終了したことを告げる図２０に示したようなＸＭＬ形式のイベントパケットを通知し、印刷処理を終了する。

次に、本実施形態における、印刷デバイスのストレージサービス検索手段について述べる。

本実施形態において、印刷デバイスがネットワーク上のサービスを検索する場合、サービス検索要求をネットワーク上へ送信する。そのサービス検索要求はＵＤＰ Ｍｕｌｔｉｃａｓｔによって送信され、ネットワーク上の全てのサービス提供機器であるサーバ装置に対して、サービス検索要求が送信される。サービス検索要求にはサービスを利用する印刷デバイスの所望するサービスの内容の検索式が含まれている。サービス検索要求を受信したサーバ装置は、サービス検索要求に含まれるサービス検索式に基づき、自身のサービスが検索条件に一致するか判断する。

サーバ装置は、端末装置が所望するサービスの内容を提供可能である場合には、サービス検索要求に応答する。サービス検索応答には、サーバ装置の位置情報を示すＲＵＩやサーバ装置の機器情報が含まれている。自身のサービスが検索条件に一致しない場合にはサービス検索要求に対する応答はしない。

このようにして印刷デバイスは、サービス検索応答があった場合には、所望のサービスを提供可能なサーバ装置の存在を検索することが可能であり、所望のサービスを提供可能なサーバ装置が複数存在する場合には、その中から一つのサーバ装置を選択して、所望のサービスを利用することができる。

図２２は本実施形態における、サービス検索要求パケットデータの一例である。本実施形態のサービス検索要求パケットはＨＴＴＰマルチキャスト（以下ＨＴＴＰＭＵ）によって検索を行なう印刷デバイスから、ネットワーク上でサービスを提供する全ての機器に対して送信される。使用するＨＴＴＰメソッドは、Ｍ−ＳＥＡＲＣＨである。このパケットのＨＴＴＰヘッダ部にはＨｏｓｔＵＤＰ Ｍｕｌｔｉｃａｓｔの送信先アドレスとしての、”２３９．２５５．２５５．２５０”を用い、送信先ポートとして１９００番のポートを指定する。

検索式はＨＴＴＰのｂｏｄｙ部にＸＭＬ形式で記述される。本実施形態のサービス検索要求パケットデータでは、５００Ｋｂｙｔｅのデータサイズのデータを保存可能なストレージサービスの検索要求を示す。

検索条件に保存可能なデータサイズを指定する場合は、＜ｃｎｄ＞タグで囲まれたフィールドに保存可能なデータサイズの属性を示す“ｃａｐａｃｉｔｙ”以下に、その要素値を示す＜ｐｒｅ＞タグで囲まれたフィールドに５００Ｋｂｙｔｅのデータサイズを表す“５００”、データサイズの単位を表す“ｋｂ”がそれぞれ格納されている。

印刷デバイスは、このような検索式を含むサービス検索要求パケットを送信し、これを受信したサーバ装置は、この検索式に基づいた、検索応答を行なう。

図２３は本実施形態におけるサービス検索要求に対する、サービス検索応答パケットデータの一例である。本実施形態のサービス検索応答パケットはＨＴＴＰユニキャスト（以下ＨＴＴＰＵ）によって、検索要求を送信した印刷デバイスに対して、送信される。本実施形態におけるサービス検索応答パケットには、サービスを提供可能なサーバ装置のロケーション情報が含まれ、本データも図２２と同様に、ＨＴＴＰのｂｏｄｙ部にＸＭＬ形式で記述される。

サービス内容を表す＜ｓｒｖ＞タグ内には、サービスの種類（＜ｓｔ＞タグ）や、サーバ装置の所在情報を示すＵＲＩ（＜ｌｏｃ＞タグ）が記述されている。

本実施形態において、サービスを提供するサーバ装置は、印刷デバイスから送信された図２２のサービス検索要求に含まれる検索式と、自身の提供可能なサービスの内容を比較し、サーバ装置の所望のサービスを提供できるか否かを判断し、サーバ装置が所望するサービスを自身が提供可能である場合には、このサービス検索応答を送信する。

また、サーバ装置が所望するサービスを自身が提供可能でない場合には、応答を返さない。

したがって、印刷デバイスはサーバ装置から、このサービス検索応答を受信することで、所望のサービスを提供可能なサーバ装置の所在を知ることができる。
複数のサーバ装置が、サービスを提供可能である場合には、複数のサーバ装置からサービス検索応答が返信される。

図２４は印刷デバイスがサービス検索を行う場合における本実施形態の印刷デバイスの動作を示すフローチャートである。

以下、図２４を用いて、本実施形態の印刷デバイスの動作を説明する。この検索処理は図１９のＳ１９０４の処理に相当する。

本実施形態における印刷デバイスは図１に示す印刷デバイス１０２であり、サーバ装置は図１に示すサーバ装置１０３である。

印刷デバイスは、端末装置から送信される印刷データを保存可能なストレージサービスを検索するため、サービス内容の検索式を作成する。本実施形態では、図１９のＳ１９０１において端末装置から送信された図７に示したＣｒｅａｔＪｏｂパケット内の印刷データのデータサイズに関する情報（＜ｄａｔａｓｉｚｅ＞タグ）から、必要なデータサイズを保存可能なストレージサービスを検索するための検索式を作成し、印刷デバイスはＳ２４０１において図２２に示したようなＸＭＬ形式のサービス検索要求パケットを生成する。

次にＳ１９０１で生成したサービス検索要求パケットを、Ｓ１９０２においてネットワーク上のサービス提供可能なサーバ装置に向けてＨＴＴＰＭＵで送信する。印刷デバイスが所望するサービスを提供可能なサーバ装置が存在する場合には図２３に示したサービス検索応答が返信されるため、Ｓ１９０３においてそのサービス検索応答を受信する。Ｓ１９０３におけるサービス検索応答の受信は、一定時間の間、サービス検索応答の受信を待ち、その間に返信された応答をサービス検索応答として処理し、一定時間経過したら処理を終了する。

ここでは、印刷デバイスがストレージサービスを提供するサーバ装置の検索を行なう例について記述してあるが、この検索処理は端末装置がプリントサービスを提供する印刷デバイスを検索する場合においても、同様な手段によって検索を行い、本実施形態における端末装置が所望の印刷サービスを提供可能な印刷デバイスを検索した後、検索された印刷デバイスによって図１９に示した印刷処理を行なうことも可能である。

また、本実施形態の検索処理では、ＨＴＴＰＭＵによってネットワーク上の全てのサーバ装置に対してサービスの検索を行なっているが、ネットワーク上にサービス検索サービスが存在し、その検索サービスを利用可能である場合には、検索サービスによって所望のストレージサービスの検索を行なってもよいし、さらに、事前にネットワーク上のサービス提供装置であるサーバ装置のサービス内容を、あらかじめ機器間の連携によって、印刷デバイスに登録しておき、その中から所望のサービスを提供可能なサーバ装置を検索することも可能である。

本実施形態における印刷システムの構成図 端末装置、サーバ装置のハードウェア構成ブロック図 印刷デバイスのハードウェア構成ブロック図 端末装置のソフトウェア構成ブロック図 サーバ装置のソフトウェア構成ブロック図 印刷デバイスのソフトウェア構成ブロック図 印刷デバイスに送信されるＣｒｅａｔｅＪｏｂパケットデータの一例を示す図 ＣｒｅａｔｅＪｏｂパケットに対する応答パケットデータの一例を示す図 従来の印刷実行時の印刷デバイスの動作を示すフローチャート ＨＴＴＰ ＰＯＳＴメソッドによる印刷データ転送パケットの一例を示す図 印刷終了時に印刷デバイスが送信するＨＴＴＰのレスポンスパケットの例を示す図 ＣｒｅａｔｅＪｏｂパケットエラーのレスポンスの例を示す図 サーバ装置に送信されるＣｒｅａｔｅＦｉｌｅパケットデータの一例を示す図 ＣｒｅａｔｅＦｉｌｅパケットに対する応答パケットデータの一例を示す図 サーバ装置に送信されるＲｅａｄＤａｔａパケットデータの一例を示す図 ＲｅａｄＤａｔａパケットに対する応答パケットデータの一例を示す図 サーバ装置に送信されるＤｅｌｅｔｅＦｉｌｅパケットデータの一例を示す図 ＤｅｌｅｔｅＦｉｌｅパケットに対する応答パケットデータの一例を示す図 本実施形態の印刷実行時の印刷デバイスの動作を示すフローチャート 印刷デバイスまたは端末装置に送信される通知イベントのＮｏｔｉｆｙパケットデータの一例を示す図 ＨＴＴＰ ＧＥＴメソッドによる印刷データ転送パケットの一例を示す図 ＨＴＴＰＭＵによるサービス検索要求パケットデータの一例を示す図 サービス検索応答パケットデータの一例を示す図 サービス検索実行時の印刷デバイスの動作を示すフローチャート

符号の説明

１０１ ユーザ端末装置
１０２ 印刷デバイス
１０３ サーバ装置

Claims (3)

1. ネットワークに接続される端末装置からの印刷要求を受け付け、送信される印刷データの印刷を行う印刷サービスを提供する印刷デバイスの印刷方法において、
   ネットワークに接続された端末装置からの印刷要求を受信するステップと、
   印刷要求を受付けた際に、印刷デバイスの状態と印刷要求に含まれる印刷属性情報に基づき、印刷デバイス自身が要求された印刷が可能であるかを判断するステップと、
   印刷が不可能である場合には、端末装置から送信される印刷データを保存可能なネットワーク上のストレージサービスを検索するステップと、
   検索したストレージサービスに対してデータ保存要求を送信し、ストレージサービスから返信されるデータ保存先の所在情報を含んだ応答を受信した後、印刷要求を送信した端末装置に印刷要求の応答として、そのストレージサービスから送信されるデータ保存先の所在情報を返信することによって、端末装置が印刷データをストレージサービスへ送信し、その印刷データをストレージサービスに保存させるステップと、
   上記の印刷データの保存が完了した際に、ストレージサービスから送信されるデータ保存完了イベント通知を受信するステップと、
   ストレージサービスへのデータ保存が完了した通知を受信した後、印刷デバイス自身の状態を監視し、印刷デバイスが印刷可能であると判断した場合には、ストレージサービスから印刷データの読み出しをするためのデータ読み出し要求を送信し、ストレージサービスから返信されるデータ保存先の所在情報を含んだ応答に基づき、ストレージサービスから印刷データを受信するステップと、
   ストレージサービスから受信した印刷データを、端末装置の印刷要求に含まれる印刷属性に基づき印刷するステップと、
   印刷が完了した後、ストレージサービスに保存されている印刷データを削除するステップと、
   全ての印刷処理が終了したことを告げる印刷終了イベント通知を端末装置に送信することで印刷処理を終了するステップを含んだ印刷方法。
2. 請求項１に記載の印刷方法を実現する印刷デバイス。
3. 請求項１に記載の印刷方法を実現する印刷システム。