(57)【要約】【課題】ＩＰＰを利用したインターネット印刷処理において、既存のゲートウェイ設定を変更すること無く、ファイアウォール越えのネットワーク印刷を実現し、また、ＳＭＴＰサーバの処理能力の制限等に起因するＩＰＰリクエスト処理の遅延に対し、オペレーション成否に対する明確な判断を可能せしめる。【解決手段】  所定のネットワーク印刷プロトコルに従って処理を行う情報処理装置において、外部情報処理装置に対して印刷処理に関する操作命令を電子メールで送信する電子メール送信部と、前記外部情報処理装置における前記操作命令実行の完了通知を含む電子メールを受信する電子メール受信部と、有することを特徴とする情報処理装置。【選択図】        図１
2007094534.tif 000002
【特許請求の範囲】
【請求項１】
所定のネットワーク印刷プロトコルに従って処理を行う情報処理装置において、
外部情報処理装置に対して印刷処理に関する操作命令を電子メールで送信する電子メール送信部と、
前記外部情報処理装置における前記操作命令実行の完了通知を含む電子メールを受信する電子メール受信部と、
を有することを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
電子メールの転送を許可しているファイアウォールを介して、前記外部情報処理装置に対して前記操作命令を含む電子メールを送信することを特徴とする情報処理装置。
【請求項３】
請求項１又は２に記載の情報処理装置において、
前記情報処理装置は、
前記電子メール送信部は、前記操作命令の操作対象であるジョブと共に前記操作命令に識別子を付加して送信し、
前記外部処理装置が前記ジョブと前記操作命令の識別子の受信に応じて発行した印刷ジョブの識別子と前記操作命令の識別子の組を含む電子メールを、前記外部情報処理装置より受信することを特徴とする情報処理装置。
【請求項４】
請求項１乃至３いずれかに記載の情報処理装置において、
前記電子メール送信部は、前記印刷処理に関する操作命令および該操作命令の有効期限に関する情報を含む電子メールを送信し、
さらに、前記操作命令の有効期限に関する情報が示す時刻を経過したにもかかわらず、前記完了通知を含む電子メールを受信しない場合は、前記操作命令が適切に実行されなかったことをユーザに報知する印刷処理管理部を有することを特徴とする情報処理装置。
【請求項５】
所定のネットワーク印刷プロトコルに従って処理を行う情報処理方法において、
外部情報処理装置に対して印刷処理に関する操作命令を電子メールで送信する電子メール送信する電子メール送信ステップと、
前記外部情報処理装置における前記操作命令実行の完了通知を含む電子メールを受信する電子メール受信ステップと、
を有することを特徴とする情報処理方法。
【請求項６】
所定のネットワーク印刷プロトコルに従って処理を行う情報処理方法を実現するためのプログラムであって、
外部情報処理装置に対して印刷処理に関する操作命令を電子メールで送信する電子メール送信する電子メール送信ステップと、
前記外部情報処理装置における前記操作命令実行の完了通知を含む電子メールを受信する電子メール受信ステップと、
をコンピュータに実行させることを特徴とするプログラム。
【請求項７】
所定のネットワーク印刷プロトコルに従い、第一の情報処理装置と第二の情報処理装置の間で印刷処理に関する情報を双方向通信する印刷システムであり、
前記第一の処理装置は、
印刷データを生成する印刷データ生成部と、
有効期限に関する情報が付加された前記操作命令を発行する操作命令発行部と、
前記操作命令の有効期限に関する情報を含む電子メールを生成する電子メール生成部を含み、
生成された前記印刷データに前記操作命令を付加し、電子メールで送信する電子メール送信部と、
前記第二の情報処理装置は、
前記印刷データ、前記操作命令および前記操作命令の有効期限に関する情報を含む電子メールを受信する電子メール受信部と、
前記情報処理装置が有する時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する印刷処理管理部を含むことを特徴とする印刷システム。
【請求項８】
所定のネットワークプリンティングプロトコルに従って処理を行う情報処理方法において、
外部情報処理装置に対してジョブの生成命令を電子メールで送信するジョブの印刷指示命令送信ステップと、
前記外部情報処理装置で管理されている前記ジョブの識別子と共に、前記ジョブを対象とする印刷完了通知の情報を含む電子メールを外部処理装置より受信する完了通知受信ステップとを有することを特徴とする情報処理方法。
【請求項９】
請求項８に記載の情報処理方法において、
前記操作命令送信ステップの前に、印刷指示命令に有効期限に関する情報を付加する有効期限情報付加ステップを実行することを特徴とする情報処理方法。
【請求項１０】
請求項８又は９に記載の情報処理方法において、前記識別子並びに前記印刷指示命令の完了通知は、ファイアウォールを介して外部情報処理装置より受信されることを特徴とする情報処理方法。
【請求項１１】
請求項９又は１０に記載の情報処理方法において、
前記情報処理装置から前記印刷指示命令を受信した前記外部情報装置は、印刷指示命令の有効期限に関する情報を含む電子メールを受信し、
時刻機能が示す時刻が、前記印刷指示命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記印刷指示命令を破棄することを特徴とする情報処理方法。
【請求項１２】
外部装置からの印刷処理に関する操作命令に応じて印刷処理を制御する情報処理装置であって、
前記外部装置から操作命令および該操作命令の有効期限に関する情報を含む電子メールを受信する電子メール受信部と、
前記操作命令によって指示された印刷処理が完了した場合は、該印刷処理の完了を示す電子メールを前記外部装置に送信する電子メール送信部と、
時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する印刷処理管理部を有することを特徴とする情報処理装置。
【請求項１３】
外部装置からの印刷処理に関する操作命令に応じて印刷処理を制御する情報処理方法であって、
前記外部装置から操作命令および該操作命令の有効期限に関する情報を含む電子メールを受信する受信ステップと、
前記操作命令によって指示された印刷処理が完了した場合は、該印刷処理の完了を示す電子メールを前記外部装置に送信する送信ステップと、
時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する操作命令破棄ステップを有することを特徴とする情報処理方法。
【請求項１４】
請求項１３に記載の情報処理方法において、
前記操作命令破棄ステップの実行に応じて、前記操作命令が完了しなかった旨を、前記操作命令を含む電子メールの送信元に対して電子メールで送信する送信ステップを実行することを特徴とする情報処理方法。
【請求項１５】
請求項１３に記載の情報処理方法において、
前記操作命令破棄ステップの実行に応じて、前記操作命令を破棄した旨を表示部に表示させる表示ステップを実行することを特徴とする情報処理方法。
【請求項１６】
請求項８乃至１５にいずれかに記載の情報処理方法において、電子メールの送受信又は電子メールのデータ構造が、ＳＭＴＰプロトコルに従うことを特徴とする情報処理方法。
【請求項１７】
請求項の８乃至１６いずれかに記載の記載の情報処理方法において、前記操作命令は、ジョブの識別子の生成命令又は印刷処理のキャンセル命令又はジョブの印刷指示命令又は印刷処理の保留命令又は保留されたジョブの印刷再開指示命令のいずれかを含むことを特徴とする情報処理方法。
【請求項１８】
所定のネットワークプリンティングプロトコルで印刷する旨が入力される印刷指示入力ステップと、
印刷データを生成する生成ステップと、
生成された印刷データを所定のネットワークプリンティングプロトコルで処理して電子メールで転送する転送ステップと、
前記ネットワークプリンティングプロトコルで設定可能な属性を設定する設定画面を情報処理装置の表示部に表示した状態で保持する設定画面表示ステップと、
を有する情報処理方法において、
前記情報処理方法は、
前記印刷指示入力ステップの実行に基づいて印刷データ生成されるのに応じて、設定画面表示ステップを実行することを特徴とする情報処理方法。
【請求項１９】
請求項１８に記載の情報処理方法において、前記所定のネットワークプリンティングプロトコルで設定する属性は、操作命令の有効期限に関する情報を含むことを特徴とする情報処理方法。
【請求項２０】
請求項８乃至１９のいずれかに記載の情報処理方法において、前記操作命令が、インターネットプリンティングプロトコルにより規定されたオペレーションであることを特徴とする情報処理方法。
【請求項２１】
所定のネットワーク印刷プロトコルに従って処理を行う情報処理方法において、
操作命令の有効期限に関する情報を含む電子メールを受信する電子メール受信ステップと、
前記情報処理装置が有する時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する操作命令破棄ステップとをコンピュータに実行させることを特徴とする制御プログラム。
【請求項２２】
所定のネットワークプリンティングプロトコルで印刷指示を行う印刷指示ステップと、
印刷データを生成する生成ステップと、
生成された印刷データを所定のネットワークプリンティングプロトコルで処理して電子メールで転送する転送ステップと、
前記ネットワークプリンティングプロトコルで設定可能な属性を設定する設定画面を情報処理装置の表示部に表示した状態で保持する設定画面表示ステップと、
を有する情報処理方法において、
前記情報処理方法は、
前記印刷指示を契機として、
印刷データ生成ステップと設定画面表示ステップを並列に実行する印刷方法をコンピュータに実行させることを特徴とする処理プログラム。
【請求項２３】
請求項５又は１２記載の情報処理装置において、
電子メールで受信したデータが、印刷データか、アプリケーションにより作成されたアプリケーションデータかを判別するデータ判別部と、
前記電子メールで受信したデータが、アプリケーションデータである場合、前記アプリケーションデータを印刷データに変換するデータ変換部をさらに有する情報処理装置。
【請求項２４】
請求項１乃至４又は１２いずれかに記載の情報処理装置において、前記操作命令は、ジョブの識別子の生成又は印刷処理のキャンセル又はジョブの印刷指示又は印刷処理の保留又は保留されたジョブの印刷再開指示のいずれかを含むことを特徴とする情報処理装置
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク印刷に係る情報処理装置、情報処理方法、印刷システムおよびプログラムに関するものである。
【背景技術】
【０００２】
近年、情報通信技術の進展に伴いインターネットが広く一般に普及し、インターネット経由で各種情報の取得や電子メールの送受信が行われるようになっている。また、携帯電話やＰＤＡに代表される、小型化・省消費電力化が一段と進んだ各種モバイル端末も、急激にその需要が伸び、モバイル端末からのインターネットの利用が日常的に行われるようになっている。こうした状況下、印刷という従来オフィスや家庭内の閉じた空間でのみ行われていた処理を、社外の出張先や電車や駅、あるいは屋外といった様々な条件下においても行いたいという要求が高まっている。
【０００３】
このような要求を背景に、出先での印刷やドキュメント作成、小ロット印刷を目的としたＰＯＤ（Ｐｒｉｎｔ  Ｏｎ  Ｄｅｍａｎｄ）印刷などを行うプリントショップ、いわゆる情報コンビニサービスが生まれ、店舗数が増加している。出張等で移動中に、あるいは宿泊先から、所定のドキュメントを印刷したい場合、最寄りの情報コンビニにあるプリンタへインターネット経由で印刷を実行する事が可能である。また、印刷したい情報は文書データに限らず、例えば携帯端末のディスプレイに表示されるスクリーンイメージ（天気図、株価チャートなど）など、或いは、スケジュールが記載されたカレンダー、ｔｏ−ｄｏリスト、電子メールのメッセージ、アドレス帳など様々な種類があげられる。情報コンビニでは、これらの印刷出力の対価を受け取る事で利益を得るのである。
【０００４】
一方、これらインターネット経由の印刷を実現する標準技術としてＩＰＰがある。これは、リモートでネットワーク印刷機器に印刷を行うための通信手順（プロトコル）を規定したものであり、ＩＥＴＦ（Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）のプリンティング関連専門ワーキンググループであるＰｒｉｎｔｅｒ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ（ＰＷＧ）によって標準化仕様が取りまとめられ、バージョン１．０がＲＦＣ２５６７、ＲＦＣ２５６６、ＲＦＣ２５６５、ＲＦＣ２５６９、ＲＦＣ２６３９として、さらにバージョン１．１がＲＦＣ２９１０、ＲＦＣ２９１１としてそれぞれ公開されている。ＩＰＰは、そのデータパケットのためのトランスポートレイヤプロトコルとして、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を使用する。ＩＰＰとして印刷のための各種オペレーション並びにジョブを細かく制御するための各種属性を規定し、これら各種属性をＨＴＴＰのＭｅｓｓａｇｅ  Ｂｏｄｙ（Ｅｎｔｉｔｙ  Ｂｏｄｙ）としてエンコードする。ＨＴＴＰはＴＣＰ／ＩＰ上にマッピングされるため、ＩＰＰを利用すればコネクション型の通信が保証される仕組みとなっている。従来のＨＴＴＰサービスはＴＣＰポートとして８０番が使用されるが、ＩＰＰサービスの場合は６３１番を使用するよう勧告されている。しかし、一般のファイアウォールにおいて、６３１番ポートをＩＰＰサービスを通すように設定されている場合は少ない。
【０００５】
ＩＰＰオペレーションにはＰｒｉｎｔ−Ｊｏｂ（印刷実行）、Ｇｅｔ−Ｐｒｉｎｔｅｒ−Ａｔｔｒｉｂｕｔｅｓ（プリンタ属性取得）、Ｇｅｔ−Ｊｏｂｓ（ジョブリスト取得）、Ｃａｎｃｅｌ−Ｊｏｂ（キャンセル）、Ｇｅｔ−Ｊｏｂ−Ａｔｔｒｉｂｕｔｅｓ（ジョブ状態取得）など、印刷の開始から終了までを制御するための手順や様々な属性が規定されている。また、ＩＰＰバージョン１．１では、デバイス及びジョブを管理するための各種オペレーションや、イベント通知機構を実現するための拡張オペレーションが追加されている。ＩＰＰにおいては、プリンタやジョブをオブジェクトとみなし、プリンタオブジェクトやジョブオブジェクトの性質を属性によって表現する。属性は、オペレーション呼ばれるオブジェクトを操作するインタフェースに基づいて操作可能である。
【０００６】
ＩＰＰ機能をサポートする機器同士は、インターネット経由でデバイス（プリンタオブジェクト）の状態を確認し、印刷を実行する事が可能である。また、複数のジョブ（ジョブオブジェクト）がプリンタオブジェクト上にある場合、これらジョブのリストを取得する事も可能である。管理系のオペレーションは、主にプリンタオブジェクトやジョブオブジェクトの管理を行う。印刷が完了した場合は、その結果がイベント通知オペレーションによって、所定のユーザ（例えば、印刷を実行したユーザ）へ通知される。イベント通知部には、ＩＰＰ独自プロトコルによるものや、電子メール配信機構（′ｍａｉｌｔｏ：′）を利用したものなどがある。
【０００７】
インターネット上を流れるＩＰＰデータパケットのセキュリティ確保のため、ＩＰＰ標準仕様は暗号化通信方式の一つであるＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ  ［ＲＦＣ２２４６］）を選択している。また、ユーザ認証機構としては、ダイジェスト認証方式（Ｄｉｇｅｓｔ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ［ＲＦＣ２６１７］）を選択している。
【０００８】
一方、今日のインターネットは、従来のＥｔｈｅｒｎｅｔ(登録商標)等による有線のみならず、携帯端末等の無線環境においても広く利用可能となってきている。そして、インターネットを利用して、何処からでも、何処へでも印刷を実行したいという要求が益々高まってきており、ＩＰＰはその実現可能手段として大きく注目されている。
【０００９】
また、従来技術として、ＩＰＰとは無関係であるが、電子メールにより、ジョブデータや印刷命令を送信する技術がある。
【特許文献１】特開平０５−１９１４５０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従来の技術では、印刷命令や印刷完了通知の送受信を制限するホスト（例えば、ファイアウォール等）を介して送受信できないという課題があった。
【００１１】
また、電子メールを各種情報の転送手段として使用する場合の一般的な課題として次がある。すなわち、電子メールの中継を行うサーバの処理能力やサーバにかかる過大な負荷が原因で、電子メールが配送経路上の中継サーバ上に長期間滞留したり、電子メールの配送経路上で紛失したりすることがある。このため、印刷サーバに電子メールを用いてサービスを要求したクライアント側において、印刷サーバにおけるサービスの完了を電子メールを用いて知ろうとした場合、所望の期日までには知ることが出来ないという課題がある。
【００１２】
本発明は、ネットワークプリンティングプロトコルの転送手段として印刷命令や印刷完了通知の送受信の制限を受けにくい電子メールを用い、印刷命令や印刷完了通知の送受信を制限するホスト（例えば、ファイアウォール等）を介したネットワーク印刷を可能にすることを目的とする。
【００１３】
さらに、本発明は、印刷データの展開に応じて、所定のネットワーク印刷プロトコルにおけるジョブの属性を画面で確認しながら設定可能とすることを目的とする。
【課題を解決するための手段】
【００１４】
本願請求項１に記載の発明は、
所定のネットワーク印刷プロトコルに従って処理を行う情報処理装置において、
外部情報処理装置に対して印刷処理に関する操作命令を電子メールで送信する電子メール送信部と、
前記外部情報処理装置における前記操作命令実行の完了通知を含む電子メールを受信する電子メール受信部と、
を有することを特徴とする情報処理装置である。
【００１５】
本願請求項７に記載の発明は、所定のネットワーク印刷プロトコルに従い、操作命令を発行する第一の処理装置と、前記操作命令を処理する第二の情報処理装置を含む印刷システムにおいて、
前記第一の処理装置は、
印刷データを生成する印刷データ生成部と、
有効期限に関する情報が付加された前記操作命令を発行することを特徴とする操作命令発行部と、
前記操作命令の有効期限に関する情報を含む電子メールを生成する事を特徴とする電子メール生成部を含み、
生成された前記印刷データに前記操作命令を付加し、電子メールで送信する電子メール送信部と、
前記第二の情報処理装置は、
前記印刷データ、前記操作命令および前記操作命令の有効期限に関する情報を含む電子メールを受信する電子メール受信部と、
前記情報処理装置が有する時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する印刷処理管理部を含むことを特徴とする印刷システムである。
【００１６】
本願請求項１２に記載の発明は、外部装置からの印刷処理に関する操作命令に応じて印刷処理を制御する情報処理装置であって、
前記外部装置から操作命令および該操作命令の有効期限に関する情報を含む電子メールを受信する電子メール受信部と、
前記操作命令によって指示された印刷処理が完了した場合は、該印刷処理の完了を示す電子メールを前記外部装置に送信する電子メール送信部と、
時刻機能が示す時刻が、前記操作命令の有効期限に関する情報が示す時刻を経過するのに応じて、前記操作命令を破棄する印刷処理管理部を有することを特徴とする情報処理装置である。
【００１７】
本願請求項１８に記載の発明は、所定のネットワークプリンティングプロトコルで印刷する旨が入力される印刷指示入力ステップと、
印刷データを生成する生成ステップと、
生成された印刷データを所定のネットワークプリンティングプロトコルで処理して電子メールで転送する転送ステップと、
前記ネットワークプリンティングプロトコルで設定可能な属性を設定する設定画面を情報処理装置の表示部に表示した状態で保持する設定画面表示ステップと、
を有する情報処理方法において、
前記情報処理方法は、
前記印刷指示入力ステップの実行に基づいて印刷データ生成されるのに応じて、設定画面表示ステップを実行することを特徴とする情報処理方法である。
【発明の効果】
【００１８】
本発明によれば、請求項１又は２又は７に記載の発明によれば、ネットワークプリンティングプロトコルの転送手段として印刷命令や印刷完了通知の送受信の制限を受けにくい電子メールを用い、印刷命令や印刷完了通知の送受信を制限するホスト（例えば、ファイアウォール等）を介したネットワーク印刷を可能になった。
【００１９】
請求項１２に記載の発明によれば、電子メールで操作命令又はジョブデータの送受信を行う際、処理の完了の成否が、所望の期日までに操作命令の送信側においても明らかとなるとなった。
【００２０】
さらに、請求項１８に記載の発明によれば、印刷データの展開に応じて、所定のネットワーク印刷プロトコルにおけるジョブの属性を画面で確認しながら設定可能となった。
【発明を実施するための最良の形態】
【００２１】
次に、本発明にかかるインターネット印刷装置及び方法について、図面を参照して説明する。
【実施例】
【００２２】
（実施形態１）
図１は、本実施形態にかかるインターネット印刷装置のひとつの実施形態を示した図である。以下、図１を参照して、生成された印刷データをネットワークプリンティングプロトコルの一例であるＩＰＰに基づいて処理し、電子メールで転送する情報処理装置の実施例を述べる。
【００２３】
クライアント端末１−１は、クライアント端末であり、ＩＰＰ  Ｃｌｉｅｎｔ及びＳＭＴＰモジュールが搭載されている。クライアント端末１−１はファイアウォール１−５を介して、インターネット１−２に接続している。クライアント１−１において、印刷データのＩＰＰに基づいて処理し、電子メールで転送する。
【００２４】
１−３は、ＩＰＰサーバ端末である。ＩＰＰサーバ端末１−３にはＳＭＴＰモジュールが搭載されている。ＩＰＰサーバ１−３は、少なくとも一台以上の印刷機能を有するデバイス群１−４と接続している。ここでは、一般的な実施形態の例として、デバイス１−４がＩＰＰサーバ１−３と同じイントラネット環境にあり、デバイス１−４とＩＰＰサーバ１−３の通信路上には、ファイアウォールは存在しない例を挙げている。一方、ＩＰＰサーバ１−３とインターネット１−２もネットワークにより接続されているが、一般的に、イントラネットとインターネットの接続点であるゲートウェイにおいて、ファイアウォール１−６が存在する。
【００２５】
クライアント端末においては、１−１上でＩＰＰの各種オペレーションを実行することが可能である。クライアント端末１−１にはＳＭＴＰ  Ｓｅｎｄｅｒ１１−２モジュールがあり、クライアントにおいて実行されたＩＰＰオペレーションは、ＩＰＰリクエストメールとして送信される。ＩＰＰリクエストメールは、ファイアウォール１−５のＳＭＴＰサービスポート（通常は２５番）を通じてインターネットに送信される。デバイス１−４にはそれぞれ少なくとも一個以上のプリンタＵＲＩ（ここでは、電子メールアドレス）が対応付けられており、クライアント上で印刷を実行したい電子メールアドレスを指定してＩＰＰオペレーションを実行する。
【００２６】
本実施形態にかかるインターネット印刷方法及び装置は、ＩＰＰプリンタオブジェクトのプリンタＵＲＩとして、各々のプリンタオブジェクトに割り当てられた固有の電子メールアドレスが使用される。この電子メールアドレスは、ＩＰＰサーバ側のＩＰＰリクエストメールを受け取ることのできるＳＭＴＰサーバのドメイン名、並びにこのＳＭＴＰサーバによって管理されるプリンタオブジェクト名から構成される。例えば、プリンタＵＲＩが‘ｍｉｋｅ＠ａｂｃ．ｃｏ．ｊｐ’とある場合、ｍｉｋｅがＩＰＰサーバ側で管理されているプリンタオブジェクト名に、‘ａｂｃ．ｃｏ．ｊｐ’が処理を行うＩＰＰサーバのアドレスになる。
【００２７】
ＩＰＰリクエストメールは目的のＩＰＰサーバに直接、あるいは複数のＳＭＴＰサーバを経由して、目的のＩＰＰサーバ１−３に搭載されているＳＭＴＰ  Ｒｅｃｅｉｖｅｒ１１−３に転送される。この転送ルーチンは、今日、一般的に使用されているメール転送ルーチン及びドメインシステムが適用される。
【００２８】
ＩＰＰサーバ１−３に到達したＩＰＰリクエストメールは、展開され、本文データよりＩＰＰリクエストヘッダが抽出される。ＩＰＰサーバ１−３はこのリクエストのオペレーションＩＤを参照し、処理を実行する。例えば、ジョブの生成にかかる命令である場合、ジョブオブジェクトが生成されＩＤが付与され管理される。
【００２９】
図１に例示するシステム構成において、ＩＰＰサーバ１−３は、複数のデバイス１−４を統合して管理することができる。すなわちＩＰＰサーバ１−３は複数の物理デバイスを、対応する論理プリンタオブジェクトとして隠蔽することもできる。そして、物理デバイスがネットワークプリンタの場合は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）などを利用してデバイス属性の取得、及び設定を行うことが可能である。また、ＩＰＰ印刷オペレーションの場合は、ＩＰＰサーバ１−３はＬＰＲ印刷などによりデバイス１−４に印刷データをネットワーク経由で転送し印刷を実行する。印刷実行後、ジョブＩＤを含んだ印刷完了通知を電子メールで通知してもよい。
【００３０】
従来は、電子メールで印刷命令を送信し、電子メールで完了通知を受信する技術がなかったため、所定のネットワークプリンティングプロトコルを実現する際、印刷命令の実行や印刷完了通知の受信について、セキュリティ上問題があった。すなわち、例えばＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を  転送手段として不用意にサーバ側で実行許可すると、悪意ある第三者にサーバ上のパスワードを盗まれたり、サーバの機器の操作権限を完全に奪われたりすることもあった。
【００３１】
ここで、本実施形態によれば、ネットワークプリンティングプロトコルにおける操作命令又はジョブデータの転送手段として安全性の高い電子メール転送手段をネットワークプリンティングプロトコルの操作命令並びに完了通知の転送手段として用いることで、サーバ側で機器の操作権限が第三者に奪い取られるような事態は想定しにくくなり、セキュリティを高めることが出来る。
【００３２】
さらに、ファイアウォールを介して印刷する場合であっても、例えばＳＭＴＰプロトコルを用いれば、ファイアウォールの転送の制限を受けることが少なく、ホストコンピュータとファイアウォールを介して接続する画像形成装置が適切に印刷命令並びに印刷完了の通知を正常に送受信できる。
【００３３】
図２は、本実施形態にかかるＩＰＰサーバと印刷デバイスが一体型であるネットワーク印刷装置を示す図である。２−１は、図１における１−１で示すクライアント端末と同等の装置である。２−２は、インターネットを示しており、図１に示したのと同様に、クライアント端末がファイアウォール２−５を経てインターネット２−２へ接続している。
【００３４】
２−３並びに２−４はＩＰＰサーバ内蔵型のネットワーク印刷デバイスである。図１における印刷デバイス１−４とは異なり、ＩＰＰサーバ及びＳＮＭＰ  Ｓｅｎｄｅｒ並びにＲｅｃｅｉｖｅｒ機能をそれぞれデバイスに内蔵した印刷機器である。このネットワーク印刷デバイスは、ネットワークに接続しており、ファイアウォール２−６あるいは２−７を経てインターネット２−２に接続している。図１では、ＩＰＰサーバ１−３が複数のプリンタオブジェクトを保持し、各々の物理デバイスを隠蔽するように機能するが、図２のシステムでは、ネットワーク印刷デバイス２−３並びに２−４が、それぞれＩＰＰサーバ機能を所有している。そしてクライアント側はこの物理デバイスに直接接続し、ＩＰＰオペレーションを実行する。
【００３５】
図１及び図２の各システム構成例において、ＩＰＰリクエスト並びにレスポンスシーケンスとこれに伴うＳＭＴＰのエンコード並びにデコードの態様は、全く同一である。現実的には、図１のシステム構成例並びに図２のシステム構成例が混在していると考えることができる。また、図２においては、ＩＰＰサーバが、着脱可能なボードに実装されていても良い。例えば、ＩＰＰサーバをボード上に実装し、ＩＰＰサーバのみを着脱可能とすることにより、ＩＰＰサーバのみのプログラム修正などが可能となり、画像形成装置の可用性を高めることができる。
【００３６】
さらに、機種ごとに依存した情報を分離して前記ボードに搭載することができ、柔軟性が高まる。また、ＩＰＰサーバが画像形成装置と分離している場合は次のような実施例をとることも可能である。例えば、ＩＰＰサーバに電子メールを蓄積し、画像形成装置側にＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  ［ＲＦＣ１９３９，ＰＯＰバージョン３］）を実現する手段を実装する。これにより、ＩＰＰサーバに蓄積された電子メールを、定期的あるいはオンデマンドで画像形成装置にダウンロードするシステム構成を取ることも出来る。本実施形態による効果は、ＩＰＰリクエスト−レスポンスデータがファイアウォールを電子メールデータとして通過することが可能となったことである。これにより、セキュリティの高い転送手段を用いて、ファイアウォールを介したネットワークプリンティングプロトコルの実現が可能となった。ジョブのみを印刷サーバに先に送信し、その後印刷属性の設定も可能となった。
【００３７】
図３は、クライアント１−１側におけるＩＰＰリクエスト発行処理、並びに、トランスポートプロトコルとしてＳＭＴＰ用いてＩＰＰリクエストを送信する処理のフローチャートを示した図である。以下、図３を参照しながら、図４に掲げたフローチャートを、図１の印刷システムに適用した実施例を図面を参照して説明する。
【００３８】
デバイス又はジョブの操作命令の実行の成否が確定するまでの期日が不確実な課題を解決する発明の実施例を述べる。クライアント１−１の画面に表示される印刷指示ボタンが押下されるＳ１００と、クライアント１−１において、印刷データが展開開始Ｓ１０１される。この印刷データ展開処理は、その後のステップＳ１０２，Ｓ１０３，Ｓ１０４のバックグランドで処理されるのが望ましい。例えば、ＩＰＰに従って転送する旨を指示した後、印刷データの生成を検知するのに応じて、ＩＰＰ属性を入力するためのダイアログを表示できるようにすることが望ましい。なお、有効期限以外のオペレーション属性（Ｏｐｅｒａｔｉｏｎ  Ａｔｔｒｉｂｕｔｅ）、ジョブ記述属性（Ｊｏｂ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ａｔｔｒｉｂｕｔｅ）、プリンタ記述属性（Ｐｒｉｎｔｅｒ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ａｔｔｒｉｂｕｔｅ）については、ＩＰＰの標準仕様に規定されたものを指定できるようにすることが考えられる。
【００３９】
このようにデータ展開処理をバックグラウンドで実行すれば、クライアント１−１のユーザの待ち時間を短縮することができる。Ｓ１０２においては、クライアント１−１の画面に、クライアント１−１を操作するユーザにＩＰＰ属性やＩＰＰレスポンスメールの返信先などの設定を促すダイアログを表示する。例えば、属性を入力するために用意するインタフェースとして、グラフィカルユーザインタフェース等を用いて入力できるようにしても良い。
【００４０】
次に、Ｓ１０２において、ＩＰＰ属性指定ダイアログを表示し、続いて、Ｓ１０３において、送信先アドレス及びＩＰＰ属性を指定する。或いはクライアントのユーザがＩＰＰ属性を入力する代わりに、所定の記憶装置から予め設定したＩＰＰ属性を読み込んでも良い。次に、Ｓ１０４において、Ｓ１０３で指定したＩＰＰ並びにＳＭＴＰ属性ヘッダを構成する。
【００４１】
次に、Ｓ１０５において、ＳＭＴＰサーバにジョブを転送する。このＩＰＰ属性ダイアログＳ１０２によれば、ユーザに対し、ＩＰＰ属性を適切なタイミングで入力させる契機を与えることが出来る。ＩＰＰ属性として、例えばここでは期日属性を指定することが出来る。期日属性とは、デバイス操作命令のＩＤの有効期限に関する情報である。前記操作命令のＩＤに有効期限を持たせることにより、途中で電子メールの紛失などにより、操作命令の伝達が失敗した場合でも、次のメリットがある。すなわち、少なくとも操作命令完了の期日までには、ＩＰＰレスポンスメールをしなかった場合、操作命令実行が完了しなかったことが、命令を発行したクライアント側で認識できる。ここでは、例えば、クライアントに備えられた時刻機能が示す時刻を基準として、対象とする操作命令の有効期限に関する情報に該当する時刻を経過しているか否かを判断することが考えられる。もちろん、期日属性にかかる有効期限の形式は、他の形式であってもよい。
【００４２】
例えば、絶対時刻として日付、時刻、あるいは日付並びに時刻の組み合わせを指定しても良いし、送信日からの日数や送信時からの経過時間、または電子メールのネットワーク滞在時間を用いても良い。本実施形態により、ＩＰＰ属性入力部をクライアント表示部に設けたことで、所望のＩＰＰ属性を印刷時にユーザが目で確認しながら、ＩＰＰ属性を設定でき、ユーザの操作負担を軽減し、間違ったＩＰＰ属性の指定を防ぐことができるようになったという効果がある。
【００４３】
図８は、クライアント１−１側において、トランスポートプロトコルとしてＳＭＴＰを用いてＩＰＰレスポンスを受信する処理のフローチャートを示した図である。前記図３のＳ１０３において、所望の期日属性Ａを指定したものとする。図８のＳ２００において、クライアントが有する時刻機能が示す時刻が期日属性Ａを既に経過しているか否かの判断を行う。期日属性Ａが指定する時刻を経過していた場合、当該操作命令のリクエストＩＤを破棄し（Ｓ１０４）、ＩＰＰリクエストを無効化する。この時、破棄されたリクエストＩＤに対応付けられたジョブデータが存在する場合は、データそのものが消去される。また、特定のマーク、例えば、上書き可能であるデータであることを示す旨のマークなどを当該ジョブデータの格納されていた領域に付け、そのまま記憶領域に保持されている場合なども含む。これにより、クライアント１−１においては、当該ＩＰＰリクエストは無効化される。また、ＩＰＰリクエストの操作対象となっていたジョブはその時点以後、ＩＰＰプロトコルのレベルにおいては、リクエストが無かったものとみなされる。
【００４４】
次に、クライアント１−１の画面にダイアログを表示するなどして、当該ＩＰＰリクエストが適切に処理されなかったことをユーザに報知する。例えば、ユーザに対し、期日属性Ａが示す時刻を経過してリクエストＩＤを破棄したことを表示する。期日属性Ａが、クライアントが有する時刻機能より経過していない場合には、ＩＰＰサーバからリクエストの受付を知らせるレスポンスメールの受信待ちＳ２０１となる。ＩＰＰレスポンスメールを受信した場合、ＩＰＰレスポンスを解析し、所定の処理を行い一連の処理を終了する。
【００４５】
これにより、期日属性Ａで指定した時点においては、クライアント側において、独自にＩＰＰリクエストを再度送信するか、印刷処理を中止するかの判断材料とすることができるようになる。ネットワークプリンティングプロトコルの命令又はジョブデータの転送手段電子メールを用いた場合に、印刷完了の通知の不確実性が高いという課題を克服できる。
【００４６】
図４は、ＩＰＰサーバ１−３側における、トランスポートプロトコルとしてＳＭＴＰを用い、ＩＰＰリクエスト及びジョブデータの受信処理、並びに、ＩＰＰレスポンスを送信する処理のフローチャートを示した図である。以下、図４のフローチャートを図１のプリンタシステムに適用した場合の一例として説明する。
【００４７】
Ｓ３０１において、ＩＰＰサーバはリクエストメールを受信する。次にＳ３０２においてＳＭＴＰ並びにＩＰＰヘッダの構文を解析する。
【００４８】
次に、ジョブオブジェクトを生成し、生成したジョブオブジェクトにジョブＩＤが付与される。以降、前記ジョブオブジェクトは、当該ジョブＩＤによって他のジョブオブジェクトから区別される。続いてＳ３０４においてレスポンス用ステータスが生成され、レスポンス用ＳＭＴＰ並びにＩＰＰヘッダが構成される。続いて、例えばジョブデータの送信元にジョブＩＤ、並びにどのリクエストに対応する応答であるかを特定するリクエストＩＤ等の情報を含むレスポンスメールが送信される。その後、印刷処理を行う。
【００４９】
図９は、図４で示したＩＰＰサーバ側における印刷処理Ｓ３０７の内容を詳細に示した図である。印刷処理においては、まず、ジョブの蓄積Ｓ４０１が行われ、印刷処理が開始Ｓ４０２される。続いて、印刷処理完了待ち状態Ｓ４０３となり、Ｓ１０３においてＩＰＰ属性に設定した期日を経過しているかどうかの判断処理Ｓ４０４を行う。ここで、当該期日がまだ経過していないと判断された場合には、印刷処理の完了しているか否かを判断Ｓ４０５し、印刷処理が完了している場合にはイベント通知Ｓ４０６を行い、印刷処理を終了する。一方、印刷処理が完了していない場合には、再び印刷処理完了待ち状態Ｓ４０３となる。もし、ステップＳ１０３においてＩＰＰ属性に予め設定した期日を経過しているかどうかの判断処理Ｓ４０４において、当該期日を経過していると判断された場合には、印刷処理を中止Ｓ４０７し、該当するジョブＩＤを破棄Ｓ４０８して印刷処理を終了する。この時、ジョブＩＤを破棄すると同時にジョブデータを削除しても良いし、ジョブＩＤのみを破棄しても良い。ここで、削除とは、例えば、ジョブデータが占めるデータ領域に対し、上書き可能である旨のマークをつけることも含む。
【００５０】
また、期日属性に指定された期日の経過後、例えば、指定記述期日を経過した旨、或いは、破棄したジョブＩＤを表示してもよい。これにより、ＩＰＰサーバ側で、長期間ジョブが滞留することはなくなる。一方、ここでジョブＩＤが破棄された場合においても、その旨をクライアントに通知するイベントを発生せしめ、クライアントに期日経過によるジョブＩＤ破棄の旨が通知される（Ｓ４０６）。この通知は、ジョブ並びに機器管理命令の再発行をするか否かの重要な判断材料となる。
【００５１】
プリンタドライバはクライアント側にあっても、サーバ側にあってもよい。ここではＩＰＰクライアント側にプリンタドライバがある実施例を説明する。図５は、プリンタドライバがＩＰＰクライアント側にある場合のＩＰＰクライアント端末の構成を示した図である。また、本実施例では、期日属性はクライアント端末から入力されるが、期日属性を適切なタイミングで入力できるようにするためのＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を提供する。この期日属性はＩＰＰ属性として入力されるので、ＩＰＰ属性の入力のためのＵＩとして詳細に説明する。
【００５２】
この実施形態は、例えば以下のように構成される。アプリケーション５―１は、例えば文書作成ソフトであり、例えば、文書又は絵又はグラフなどを含んだ文書データや様々なフォーマットの画像データなど、プリンタドライバによって、各出力デバイスによって出力可能な形式に変換される前のデータがアプリケーションデータである。アプリケーション５―１のダイアログで印刷ボタンが押下されると、アプリケーションはＧｒａｐｈｉｃａｌ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ（ＧＤＩ）５―２を呼び出し、アプリケーションデータがＧＤＩ５―２に渡される。ＧＤＩ５−２は、グラフィックス描画に関連する機能等を受け持つモジュールである。
【００５３】
続いて、ＧＤＩ５―２はプリンタドライバ５―３を呼び出し、プリンタドライバ５―３においてアプリケーションデータが印刷データに変換される。次にＧＤＩ５―２はスプーラ５―４を呼び出し、スプーラ５―４に印刷データがスプーリングされる。ここで、スプーラには印刷データを保持するための所定の記憶装置（不図示）を内包している。データがスプーリングされると、スプーラ５−４は、ＩＰＰオペレーションヘッダ生成部５−５をコールする。そして、ＩＰＰオペレーションヘッダの生成、並びにＩＰＰオペレーションの実行がなされるのである。印刷データの生成を検知したＩＰＰオペレーションヘッダ生成部５―５は、ＩＰＰ属性指定ダイアログ５―６をクライアントの表示部に表示させる。ＩＰＰ属性指定ダイアログ５―６において、ＩＰＰ属性が入力されると、ＩＰＰオペレーションヘッダ生成部５―５はＩＰＰ属性ヘッダを生成し、印刷データと共にメール生成部５―７に渡す。
【００５４】
メール生成部５―７は、ＩＰＰ属性ヘッダ生成部５―５から受け取ったデータをメッセージボディとし、ＳＭＴＰに準拠したメールヘッダ等を付加した電子メールを生成し、ＩＰＰサーバ側に電子メールを送信するＳＭＴＰ  Ｓｅｎｄｅｒ５―８に渡す。従来は、プリンタオブジェクトを、インターネットを介して遠隔で操作することは、セキュリティの観点から好ましくないとされる場合が多かった。しかし、当該ＩＰＰリクエストメールを暗号化する事が可能で、これによりインターネット上でのセキュリティを確保する事が可能である。この発明の構成によれば、既存のＩＰＰのトランスポートプロトコルにＨＴＴＰを用いた技術を用いては通信できなかったイントラネット内のＩＰＰサーバとも通信することができる効果がある。
【００５５】
一方、ＩＰＰの操作及び属性指定ダイアログを設けることで、先にＩＰＰサーバに配置したジョブについて、当該ジョブのジョブＩＤを指定して、当該ジョブの属性を変更する事が可能である。これにより、データの大きなことが多いジョブデータの再送信をする必要が無くなり、ネットワークのトラフィックが軽減される。さらに、広く普及した電子メールの既存のソフトウェア資源の活用を図ることが出来る。例えば、既存のＳＭＴＰは変更せず、ＩＰＰ属性ダイアログをクライアント側に新たに設けるだけで、使い勝手の良いユーザインタフェース並びにＩＰＰプロトコルのトランスポート部を構築出来るという効果がある。また、ＩＰＰ属性ダイアログを設けたことの効果は、所望のＩＰＰ属性を印刷時にユーザが目で確認しながら、例えば指定期日を設定でき、ユーザの操作負担を軽減し、間違ったＩＰＰ属性の指定を防ぐことにある。ユーザは所望の期日属性をこのＵＩを用いて、適切なタイミングで設定でき、容易な操作で設定可能となる。
【００５６】
ここで、ＩＰＰ属性を簡易に指定出来るようにしたので、図１の発明の構成を用いることにより、指定期日を指定する以外の他のＩＰＰ属性を指定することにも使用できる。例えば次のような実施例をとることも可能である。オフィスから遠く離れた出張先で会議が開催される場合であって、会議の直前まで配布すべき資料の部数が不明な場合を考える。出張先にＩＰＰサーバを配置することで次のような使用法が可能である。オフィスから先にジョブデータを出張先のＩＰＰサーバに転送しておく。
【００５７】
続いて配布すべき資料の部数が確定した時点で、次の処理を行う。即ち、ＩＰＰオペレーションに、判明した印刷部数をＩＰＰ属性として付加して送信し、配布部数を指定することが出来る。ここで、本実施形態において、電子メールを用いているので、出張先のＩＰＰサーバがイントラネット内にある場合でも、イントラネットのゲートウェイにおいて、ファイアウォールに接続を拒否されることは少なく、上記の実施例において、遠隔で印刷の保留命令を発行する場合でも、設定した期日属性以内に命令の失敗並びに成功を確実に知ることが出来る効果がある。
【００５８】
（実施形態２）
図６は、プリンタドライバがＩＰＰクライアント側にある場合のＩＰＰクライアントの構成を示す図である。以下には、実施形態１との差分を示す。図７は、プリンタドライバがＩＰＰサーバ側にある場合のＩＰＰサーバの構成を示す図である。下記のＩＰＰ属性は、用紙サイズや印刷部数など色々考えられるが、例えば、期日属性であるとする。機器構成は実施形態１と同様、例えば図１と同様のものとする。ここでは、図６並びに図７を一例として、ＩＰＰサーバ側にプリンタドライバを搭載する実施形態を説明する。
【００５９】
ＩＰＰ印刷クライアント６―１に対して、印刷ファイルの指定とＩＰＰ属性の指定を行う。ＩＰＰオペレーションヘッダ生成部６―２にアプリケーションデータを渡し、ＩＰＰ属性ヘッダとアプリケーションデータを含むデータをメール生成部６―３に送る。メール生成部６―３においては、当該データをメッセージボディとし、ＳＭＴＰに準拠したメールヘッダ等を付加した電子メールを生成し、ＩＰＰサーバ側に電子メールを送信するＳＭＴＰ  Ｓｅｎｄｅｒ６―４に渡す。
【００６０】
次にＩＰＰサーバ側の実施形態について説明する。ＳＭＴＰ  Ｒｅｃｅｉｖｅｒ７―１は、ＩＰＰクライアント側から電子メールを受け取り、ＩＰＰサーバ７―２に渡す。ＩＰＰサーバ７―２は電子メールからアプリケーションデータを取り出し、アプリケーション７―３をサイレントモード（アプリケーションのＧＵＩが表示されず、内部的に起動している状態）で起動する。その後、アプリケーション７―３はＧＤＩ７―４を呼び出し、続いてアプリケーション７−３は、アプリケーションデータをＧＤＩ７―４へ渡す。
【００６１】
続いてＧＤＩ７―４はプリンタドライバ７―５を呼び出す。プリンタドライバ７―５によりアプリケーションデータをプリンタに適合した印刷データに変換する。続いてプリンタドライバはスプーラ７―６を呼び出し、印刷データをスプーリングする。その後、スプーラ７―６はローカルモニタ７―７を呼び出し、印刷データをプリンタ７―８に送信する。この実施形態によれば、プリンタドライバをＩＰＰクライアント側で保持する必要が無くなり、ユーザはプリンタドライバのインストールの負担を軽減できる効果がある。
【００６２】
さらに、ＩＰＰクライアントのプリンタドライバが不要となるので、ＩＰＰクライアントのメモリを有効に活用できる効果がある。なお、ＩＰＰサーバ側において、受信した電子メールが、アプリケーションが作成したアプリケーションデータである場合は、プリンタドライバを用いて印刷データに変換し、印刷データである場合はそのまま印刷データを抽出してプリンタに出力する切り替えを自動的に行う実施例が合わせて考えられる。
【００６３】
さらに、図７に示すローカルモニタ７−７は、代わりにＬＰＲによるＴＣＰ／ＩＰ印刷を行うためのＬＰＲポートモニタであっても良い。この場合、図７に示すサーバ構成は、ＩＰＰプロクシとして機能する事になる。
【００６４】
図１０はＩＰＰサーバが受信した電子メールデータが、印刷データかアプリケーションデータかを判断する印刷処理のフローチャートを示した図である。以下、図１０参照して説明する。電子メール受信待ち状態Ｓ５０１において、電子メールを受信すると、印刷目的のデータを含むか否かの判断処理Ｓ５０２を行う。もし、電子メールデータに印刷目的のデータが含まれる場合、印刷目的のデータの抽出処理Ｓ５０３を行う。次に印刷目的のデータの解析処理Ｓ５０４を行い、印刷目的のデータがドライバ処理をされているか否かの判断処理（すなわち、印刷データであるか、あるいはアプリケーションデータであるかの判別処理）Ｓ５０５を行う。もし印刷目的のデータがアプリケーションデータである場合、当該印刷目的のデータをドライバで処理Ｓ５０６し、印刷データを生成した後に印刷処理Ｓ５０７を行う。もし、印刷データであった場合、そのままプリンタ出力Ｓ５０７を行う。
【００６５】
一方、Ｓ５０２において、印刷目的のデータを含まないと判断された場合は、通常の印刷を目的としていない電子メールとして処理Ｓ５０８する。なおＳ５０４においては、電子メールデータを所定の規則に則ってデコードし、プリンティングプロトコルにより付加されているヘッダ情報を解析する。
【００６６】
（実施形態３）
次に図１１を用いて、本実施形態にかかるインターネット印刷装置のクライアント及びサーバの論理コンポーネントの構成と、ＩＰＰオペレーション要求のもっとも基本的なシーケンスを説明する。以下においても、実施形態１又は実施形態２のは援用される。
【００６７】
図１１は、ＩＰＰクライアント端末１−１、２−１、及びＩＰＰ  サーバ端末１−３、２−３、２−４における、それぞれの論理コンポーネントのブロック構成を示した図である。ＩＰＰクライアント端末には、ＩＰＰ  Ｃｌｉｅｎｔ並びにＳＭＴＰ  Ｓｅｎｄｅｒ、ＳＭＴＰ  Ｒｅｃｅｉｖｅｒが、また、ＩＰＰサーバ端末には、ＩＰＰ  Ｓｅｒｖｅｒ並びにＳＭＴＰ  Ｓｅｎｄｅｒ、ＳＭＴＰ  Ｒｅｃｅｉｖｅｒコンポーネントがそれぞれ実装されている。１１−１は、ＩＰＰ  Ｃｌｉｅｎｔコンポーネントである。これはＩＰＰクライアント端末１−１、２−１に搭載されており、各種ＩＰＰオペレーションの指定、値の設定を行うＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）と、ＩＰＰリクエストヘッダを構成するエンコーダ、ＩＰＰレスポンスヘッダを解読するデコーダ、並びに各種ＩＰＰオペレーションを制御するＩＰＰクライアントコア機能からなる。
【００６８】
１１−２は、エンコードされたＩＰＰヘッダを含むＳＭＴＰデータをＳＭＴＰの手順に従って送出するＳＭＴＰ  Ｓｅｎｄｅｒコンポーネントである。ＩＰＰリクエストメールは、ＳＭＴＰ  Ｓｅｎｄｅｒコンポーネント１１−２により、ＳＭＴＰに準拠したシーケンスでサーバ側のＳＭＴＰ  Ｒｅｃｅｉｖｅｒ１１―３側へ転送される。この時、ＩＰＰリクエストヘッダ及びドキュメントデータは、ＳＭＴＰ  ＤＡＴＡとしてエンコードされる。１１−３は、ＳＭＴＰにしたがってデータを受信する機能を提供するＳＭＴＰ  Ｒｅｃｅｉｖｅｒコンポーネントである。
【００６９】
ＳＭＴＰ  Ｒｅｃｅｉｖｅｒ１１−３は、送信元アドレス、送信先アドレス、並びにメール本文のデータをそれぞれ受信し、これらに対応する応答をＳＭＴＰ  Ｓｅｎｄｅｒ１１−２へ返す。そして、ＳＭＴＰ  Ｒｅｃｅｉｖｅｒ１１−３で受信したメールデータは、メール本文データとしてＩＰＰリクエストヘッダを抽出し、ＩＰＰサーバコンポーネント１１−４へこれを転送する。
【００７０】
ＩＰＰサーバコンポーネント１１−４では、ＩＰＰリクエストヘッダのデコードを行い、必要な処理を実行する。必要な処理とは、いわゆるＩＰＰオペレーションに伴う処理であり、例えば、Ｇｅｔ−Ｐｒｉｎｔｅｒ−Ａｔｔｒｉｂｕｔｅｓ  ｏｐｅｒａｔｉｏｎやＰｒｉｎｔ−Ｊｏｂ  ｏｐｅｒａｔｉｏｎ等である。Ｇｅｔ−Ｐｒｉｎｔｅｒ−Ａｔｔｒｉｂｕｔｅはデバイスの各種属性をＩＰＰ属性としてクライアント側に返信する。また、Ｐｒｉｎｔ−ＪｏｂはＩＰＰ属性に伴って送られてきた印刷データを抽出し、デバイスに転送する。
【００７１】
デバイスが図１の１−４のごとくネットワークに接続されている場合は、ＬＰＲやＯＳ独自の印刷プロトコルを用いて印刷を実行する。ＩＰＰサーバが図２の２−３、２−４に示すごとくデバイスに内蔵されている場合は、そのまま送られてきた印刷データを処理する。
【００７２】
ＩＰＰはリクエスト−レスポンス型のプロトコルであるため、ＩＰＰリクエストメールによるＩＰＰオペレーションの結果をＩＰＰレスポンスとしてクライアントに返信する必要がある。そこで、ＩＰＰオペレーションの処理結果として、ＩＰＰサーバコンポーネント１１―４はＩＰＰレスポンスを構成する。ＩＰＰレスポンスはあらかじめＩＰＰにより規定されているＩＰＰ属性がエンコードされる。そして、生成されたＩＰＰレスポンスヘッダはＩＰＰサーバ側のＳＭＴＰ  Ｓｅｎｄｅｒ１１―５により電子メールの本文データとして、ＩＰＰオペレーションを要求してきたクライアント端末１−１、２−１へと送信される。ＩＰＰオペレーションを要求してきたクライアント端末１−１、２−１のメールアドレスは、ＩＰＰリクエストを送信してきたＳＭＴＰの処理手順の過程で知ることが可能である。したがって、ＩＰＰレスポンスの返信に際しては、この時に知り得たメールアドレスを利用してＩＰＰレスポンスメールの返信を実行する。
【００７３】
ＩＰＰリクエストメールとこれに対するレスポンスメール、並びにオペレーション要求側のメールアドレスといった、一つのＩＰＰオペレーションに付随する全ての情報は、ＩＰＰサーバ側で一元的に管理する必要がある。ＩＰＰサーバに対しては、複数のＩＰＰ  Ｃｌｉｅｎｔから同じタイミングでＩＰＰオペレーション要求がなされる場合があるからである。ＩＰＰのオペレーション属性には、全てのＩＰＰリクエストに対し固有の番号が付与される、ｒｅｑｕｅｓｔ−ｉｄなるものがあるので、ＩＰＰサーバはこの属性とＩＰＰオペレーション要求もとのメールアドレスを関連付けて管理することで、先の処理を実現することになる。
【００７４】
なお、ＩＰＰレスポンスメールは、ＩＰＰ  Ｃｌｉｅｎｔ側のＳＭＴＰ  Ｒｅｃｅｉｖｅｒ１１−６により受信される。ＳＭＴＰ  ＤＡＴＡ部よりＩＰＰリクエストが抽出され、ＩＰＰ  Ｃｌｉｅｎｔコンポーネント１１―１により処理が行われる。
【００７５】
ところで、ＨＴＴＰはサーバに対してリクエスト−レスポンス型のコネクション接続とデータ転送が行われるのに対し、ＳＭＴＰはあらかじめ設定されているＳＭＴＰサーバ（通常クライアント側の最寄りのＳＭＴＰサーバ）に対しデータ転送を行った後は、直ちにコネクションを切断してしまう。クライアント側はＳＭＴＰによるデータが目的のＳＭＴＰ  Ｒｅｃｅｉｖｅｒに何時転送されたか、あるいはちゃんと届いたかといった情報を、リクエストを発行した時に直ちに知ることができない。実際、インターネット上をデータがメール転送される場合、データ転送に介在するＳＭＴＰサーバの過負荷により、データ転送に多くの時間がかかってしまう場合がある。
【００７６】
また、サーバの障害によりデータそのものが消失してしまうといった事故も皆無ではない。このような場合も、ＩＰＰリクエストメールを発行したクライアント側は、その事実を知りうる手立てが無いのである。クライアント側はＩＰＰリクエストを発行したまま、自身のオペレーション要求が消失してしまったにもかかわらず、その事実を知ることができずに、レスポンスメールを待ち続けてしまうなどといった不具合も考えられる。
【００７７】
そこで、本実施形態にかかるインターネット印刷方法及び装置では、ＩＰＰリクエストメールの有効期限に関する情報として、新たなＩＰＰ属性を規定した。以下は、新たに規定したＩＰＰ拡張属性の名称及びデータ型である。
【００７８】
ＩＰＰ−ｒｅｑｕｅｓｔ−ｅｘｐｉｒａｔｉｏｎ−ｔｉｍｅ    ［ｄａｔｅＴｉｍｅ］
この属性はＩＰＰオペレーション属性に分類され、ＩＰＰリクエストメールの有効期限を指定する。ＩＰＰ  Ｃｌｉｅｎｔコンポーネント１１−１は、ＩＰＰリクエストパケットを構成する際、あらかじめユーザが指定する当該属性を含めることができる。本属性の値は、クライアント側がＩＰＰオペレーション要求を発行する前に、あらかじめ任意の値を指定することができる。ＩＰＰ  Ｃｌｉｅｎｔ１１−１コンポーネントは、クライアント側によって指定された値を当該属性として指定して、ＩＰＰリクエストメール中にエンコードする。
【００７９】
本実施例における有効期限に関する情報としてＩＰＰリクエストメールの期日属性の形式の例を述べたが、有効期限に関する情報の指定は他の形式であってもよい。例えば、絶対時刻として日付または、時刻あるいはその組み合わせを指定しても良いし、送信日からの日数や送信時からの経過時間、または電子メールのネットワーク滞在時間を用いても良い。
【００８０】
ＩＰＰサーバコンポーネント１１−４は、当該属性を含むＩＰＰリクエストメールを受信し、ＩＰＰリクエストヘッダをデコードした時に当該属性値が指定した期日を経過していた場合、当該ＩＰＰリクエストメールに指定されているＩＰＰオペレーション要求を処理せずに、直ちに破棄・終了することができる。一方、ＩＰＰ  Ｃｌｉｅｎｔコンポーネントはクライアント側が発行したＩＰＰリクエストメールに対するＩＰＰレスポンスメールの受信が、本属性値に指定された期日までになされない場合、当該ＩＰＰリクエストが何らかの原因で処理されなかったと判断することができる。この時、ＩＰＰクライアントが、ＩＰＰリクエストの完了が失敗したことを所定のアドレスにメールで通知してもよい。
【００８１】
なお、期日属性に基づいて、クライアント及びサーバは、それぞれ独立して期日の到来を判断する。クライアントとサーバのそれぞれが同時に期日属性を判定するためには、各々の時刻が正確に一致していなければならない。これを目的とする時刻の同期処理のためには、既知のネットワークによる時刻同期アルゴリズム等が利用される。
【００８２】
ＩＰＰ拡張属性を導入することによって、クライアント側は自身の発行したＩＰＰオペレーション要求の信頼性を、そのＩＰＰオペレーションの緩急度にあわせて任意に設定することが可能である。そして、自身のオペレーション要求が既に無効になってしまったにもかかわらず、そのレスポンスを待ち続けるといった不具合を未然に防ぐことができるのである。
【００８３】
また、ＩＰＰサーバ側にプリンタドライバを設ける発明によって、プリンタドライバをＩＰＰクライアント側で保持する必要が無くなり、ユーザはプリンタドライバのインストールの負担を軽減できる効果がある。さらに、ＩＰＰクライアントのプリンタドライバが不要となるので、ＩＰＰクライアントのメモリを有効に活用できる効果がある。
【００８４】
また、前述した実施形態の機能を実現するためのソフトウェアのプログラムをネットワークを介して供給し供給することも本実施形態の範疇に含まれる。
【００８５】
またこの場合、前記ソフトウェアのプログラム自体が前述した実施形態の機能を実現することになり、そのプログラム自体、及びそのプログラムをコンピュータに供給するための手段は本実施形態を構成する。
【００８６】
またコンピュータが供給されたプログラムを実行することにより、前述の実施形態の機能が実現されるだけではなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）、あるいは他のアプリケーションソフト等と共同して前述の実施形態の機能が実現される場合にもかかるプログラムは本実施形態に含まれることは言うまでもない。
【図面の簡単な説明】
【００８７】
【図１】本実施形態にかかるインターネット印刷装置の一形態を示した図である。
【図２】本実施形態にかかるＩＰＰサーバと印刷デバイスが一体型であるネットワーク印刷装置を示す図である。
【図３】クライアント１−１側における、ＩＰＰリクエスト発行処理、並びに、トランスポートプロトコルとしてＳＭＴＰ用いてＩＰＰリクエストを送信する処理のフローチャートを示した図である。
【図４】ＩＰＰサーバ１−３側における、トランスポートプロトコルとしてＳＭＴＰを用い、ＩＰＰリクエスト及びジョブデータの受信処理、並びに、ＩＰＰレスポンスを送信する処理のフローチャートを示した図である。
【図５】プリンタドライバがＩＰＰクライアント側にある場合のＩＰＰクライアント端末の構成を示した図である。
【図６】プリンタドライバがＩＰＰサーバ側にある場合のＩＰＰクライアントの構成を示す図である。
【図７】プリンタドライバがＩＰＰサーバ側にある場合のＩＰＰサーバの構成を示す図である。
【図８】クライアント１−１側において、トランスポートプロトコルとしてＳＭＴＰを用いてＩＰＰレスポンスを受信する処理のフローチャートを示した図である。
【図９】図４における印刷処理Ｓ３０７の内容を詳細に示した図である。
【図１０】ＩＰＰサーバが受信した電子メールデータが、印刷データかアプリケーションデータかを判断する印刷処理のフローチャートを示した図である。
【図１１】ＩＰＰクライアント端末１−１、２−１、及びＩＰＰサーバ端末１−３、２−３、２−４における、それぞれの論理コンポーネントのブロック構成を示した図である。
【符号の説明】
【００８８】
１−１、２−１  クライアント端末
１−２、２−２  インターネット
１−３、２−３、２−４  ＩＰＰサーバ
１−４  デバイス
１−５、１−６、２−５、２−６、２−７  ファイアウォール
【図１】
2007094534.tif 000003
【図２】
2007094534.tif 000004
【図３】
2007094534.tif 000005
【図４】
2007094534.tif 000006
【図５】
2007094534.tif 000007
【図６】
2007094534.tif 000008
【図７】
2007094534.tif 000009
【図８】
2007094534.tif 000010
【図９】
2007094534.tif 000011
【図１０】
2007094534.tif 000012
【図１１】
2007094534.tif 000013