JP2007140663A

JP2007140663A - 画像処理装置

Info

Publication number: JP2007140663A
Application number: JP2005330329A
Authority: JP
Inventors: Tadahiro Nakamura; 忠弘中村
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-11-15
Filing date: 2005-11-15
Publication date: 2007-06-07

Abstract

【課題】プリントサービスやストレージサービスなどクライアントからデータを受信して処理を行うサービスにおいて、データ受信処理を行う受信処理部を各サービスから分離し、複数のサービスがその受信処理部を利用する構成とすることにより、冗長な部分を排除し各サービスの実装を単純化することを可能とする。
【解決手段】ネットワークを介して外部クライアント装置からジョブを受信し処理を行う画像処理装置であって、外部クライアント装置からのジョブ送信要求を受信するジョブ送信要求受信手段と、上記ジョブを受信するための受信識別子を生成する受信識別子生成手段と、ジョブ送信要求に対する応答として受信識別子の情報を含む応答データを送信する応答手段と、外部クライアントから受信識別子に対して送信されるジョブを受信するジョブ受信手段と、ジョブ受信手段により受信したジョブを処理するジョブ処理手段とを有する。
【選択図】図１

Description

本発明は、ネットワークを介してジョブを受信し、プリント出力を行ったり、内部のストレージに格納したりすることが可能な画像処理装置に関するものである。

近年インターネットにおいてWebサービス技術が大きな注目を集めている。Webサービスは、ネットワーク上に分散する各種サービスを緩やかに結合する技術である。この技術を利用することで、プログラムが人間の手を介さず動的に適切なサービスを選択することが可能であり、目的とする処理を自動的に行う技術として各産業分野から期待されている。このWebサービスにおいてやりとりされるデータはXML（eXtensible Markup Language）で記述されており、このXMLデータはSOAP（Simple Object Access Protocol）を使用してネットワーク上で通信が行われる。このSOAPは下位層にHTTP（Hyper Text Transfer Protocol）やSMTP（Simple Mail Transfer Protocol）を利用することが規定されており、Webブラウジングや電子メールと同様にインターネット上で容易に利用することが可能となっている。

このWebサービス技術を画像処理装置に適用することで、これまでになかったさまざまなメリットが生まれる。一例としてプリンタの場合は、Webサービスを実装することで、プリントサービスとしてSOAPを使用したプリントジョブ投入やデバイス管理が可能となる。また、利用者にとってはこのプリントサービスへのアクセスを柔軟にカスタマイズできるようになる。例えば、プリントサービスへの接続方法はWSDL（Web Service Description Language）で記述されるため、このWSDLを解釈し、一定の規則により変換するプログラムを用意することで、利用者が必要な項目だけを抽出したUI（ユーザインターフェース）を提供することも可能である。また、WSDLにはプリントジョブ投入の際に指定できるジョブ情報も記述することが可能であり、例えば両面プリントが可能かどうかといったことは、WSDLを参照することであらかじめ知ることも可能である。さらに、画像処理装置がハードディスクのような記憶装置を持ち、ジョブを格納したり参照したりするためのストレージサービスを提供する場合も、このWebサービス技術を適用し、ユーザに対してプリントサービスと一貫した操作性を提供することが可能である。

このように、さまざまなメリットを持つWebサービス技術を適用した画像処理装置が今後ますます開発されていくことが想定される。

Webサービス技術を適用したプリントサービスにおける印刷の手順としては次のような例があげられる。まず印刷クライアントは印刷要求コマンドをXMLで記述し、プリントサービスに送信する。プリントサービスは印刷データを受信するためのURLをクライアントに応答する。その後、クライアントは指定されたURLに印刷データを送信し、プリントサービスは印刷を行う。

なお、データ受信用URLとしてはたとえば「http://192.168.0.1/print/job1」といった形式であり、この場合、ポート番号としてはhttpスキームのデフォルトである８０を使用することを意味する。そのため、クライアントはまずプリントサービスのポート８０に対して接続し、HTTPのPOSTメソッドを使用して印刷データを送信する。またプリントサービスは、次の印刷要求に対しては「http://192.168.0.1/print/job2」のように前ジョブの時とURLを変更して応答する。そのため、複数ジョブが同時に投入された場合でもこのURLを確認することでジョブを一意に識別することができる。

また、Webサービス技術を適用したストレージサービスにおける文書格納の手順としては次のような例があげられる。まずストレージクライアントは、文書格納要求コマンドをXMLで記述し、ストレージサービスに送信する。ストレージサービスは文書データを受信するためのURLをクライアントに応答する。その後、クライアントは指定されたURLに文書データを送信し、ストレージサービスは受信文書を格納する。データ受信用URLは、上記プリントサービスにおける印刷手順の場合と同様である。

従来例としては、例えば特許文献１をあげることが出来る。
特開２００３−０６７１４８号公報

上記従来例においては、プリントサービスとストレージサービスの両方を持つ画像処理装置の場合に、データを受信するための処理は両サービスで重複しているにもかかわらずそれぞれ独自のデータ受信処理を行っており、開発効率が悪かった。また、一方のデータ受信処理においてタイムアウト時間などの動作仕様を変更した場合、他方も変更することを忘れ、機器としての仕様の一貫性に欠けてしまう状況を作り出してしまう危険性があった。

本発明は上記の問題を解決するためのものであり、その目的は、プリントサービスやストレージサービスなどクライアントからデータを受信して処理を行うサービスにおいて、データ受信処理を行う受信処理部を各サービスから分離し、複数のサービスがその受信処理部を利用する構成とすることにより、冗長な部分を排除し各サービスの実装を単純化することを可能とする画像処理装置を提供することである。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

ネットワークに接続され、ネットワークを介して外部クライアント装置からジョブを受信し処理を行う画像処理装置であって、上記外部クライアント装置からのジョブ送信要求を受信するジョブ送信要求受信手段と、上記ジョブを受信するための受信識別子を生成する受信識別子生成手段と、上記ジョブ送信要求に対する応答として、上記受信識別子生成手段により生成された受信識別子の情報を含む応答データを送信する応答手段と、上記外部クライアントから上記受信識別子に対して送信されるジョブを受信するジョブ受信手段と、上記ジョブ受信手段により受信したジョブを処理するジョブ処理手段とを有することを特徴とする画像処理装置。

以上説明したように、プリントサービスやストレージサービスなどクライアントからデータを受信して処理を行うサービスにおいて、データ受信処理を行う受信処理部を各サービスから分離し、複数のサービスがその受信処理部を利用する構成とすることにより、冗長な部分を排除し各サービスの実装を単純化することを可能とする画像処理装置を提供することが可能となる。

（実施例１）
以下、本発明における画像処理装置の第一の実施例を図面を参照して説明する。

図１は本実施例において本発明を適用可能な印刷システムの構築例を示すブロック図である。画像処理装置１０１はネットワークに接続され、ホストコンピュータ１０２、１０３と通信可能である。画像処理装置１０１は、プリントサービスおよびストレージサービスを提供しており、ホストコンピュータ１０２、１０３からプリントジョブを受信し印刷を行ったり、データを受信して内部の記憶装置に格納したりすることが可能である。

図２は、本発明の実施形態を示す画像処理装置のハードウェア構成を説明するブロック図である。なお、ここでは、レーザビームプリンタを例にして説明する。図２のプリンタ２００において、１２はプリンタＣＰＵ（ＣＰＵ）で、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラムに基づいてシステムバス１５に接続される各種のデバイスとのアクセスを総括的に制御し、印刷部インタフェース１６を介して接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラム用ＲＯＭには、ＣＰＵ１２が実行可能な制御プログラム等を記憶する。さらに、ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ（アウトラインフォントデータを含む）等を記憶し、ＲＯＭ１３のデータ用ＲＯＭには、ホストコンピュータ上で利用される情報等を記憶している。ＣＰＵ１２はネットワークインターフェース部１８を介してネットワーク上のホストコンピュータとの通信処理が可能となっている。１９はＲＡＭで、主としてＣＰＵ１２の主メモリ，ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域，環境データ格納領域等に用いられる。ハードディスク（ＨＤ），ＩＣカード等の外部記憶装置１４は、ディスクコントローラ（ＤＫＣ）２０によりアクセスが制御される。ハードディスクは、プリントジョブを一時的にスプールするための受信バッファとして使用されるほか、受信したデータを永続的に保持し、外部から参照するためのデータ格納領域として使用される。また、２０１は操作パネルで、ユーザがソフトウェアキーから各種情報を入力することが可能である。前述した外部記憶装置は、１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード，言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。２４は不揮発性メモリであり、操作パネル２０１からのプリンタモード設定情報をユーザ別，グループ別に記憶している。

また、図示していないが、プリンタ２００にはさらにオプションで、ステープルやソート機能を行うフィニッシャや、両面印刷機能を実現するための両面装置など各種拡張装置を装着することが可能となっており、それらの動作はＣＰＵ１２から制御される。

図３は、本発明の実施形態を示す画像処理装置のソフトウェアプログラム構成を説明するブロック図である。

プリントサービス部３０１は、SOAP制御部３０４からプリント要求とともに受信する印刷制御情報に従い、その後データ受信部３０３から受信する印刷データを印刷可能なデータ形式に変換し、印刷部インターフェース１６を制御してプリンタエンジン１７に変換したデータの送信を行うなど、印刷に関する様々な制御を行う。ストレージサービス部３０２は、SOAP制御部３０４から格納要求とともに受信する格納制御情報に従いデータ受信部３０３から受信したデータを、ディスクコントローラ２０を制御してハードディスク１４に格納したり、格納したデータの削除や取り出しといったデータ管理に関する様々な制御を行う。ネットワーク通信ドライバ３０８は、ネットワークインターフェース部１８を制御し、ネットワークとのデータ送受信の制御を行う。TCP/IPプロトコル制御部３０７は、TCP/IPプロトコルを制御するモジュールを備え、ネットワークドライバ３０８を使用してTCP/IPプロトコルに則ったデータ送受信制御を行う。HTTPサーバ制御部３０６は、HTTPプロトコルの全般を制御するモジュールであり、クライアントから受信したHTTPリクエストパケットを解析し適切な処理を行い、データをSOAP制御部３０４やデータ受信部３０３等の上位アプリケーションにわたすと共に、上位アプリケーションの指示によりHTTPレスポンスパケットをクライアントに返送する制御を行う。また、クライアントからのリクエストを受信するURLは上位アプリケーションから動的に登録／削除が可能である。SOAP制御部３０４はSOAPプロトコルを制御するモジュールであり、クライアントから受信したXML形式のデータをXMLパーサ３０５を使用して解析し、プリントサービス部３０１やストレージサービス部３０２の適切なモジュールを呼び出したり、クライアントに返すべきデータをXMLデータに変換し、HTTPサーバ制御部３０６を介してクライアントに返信する制御を行う。XMLパーサ３０５はXML形式データを入力とし解析結果を出力するモジュールである。

図４は、本実施例におけるホストコンピュータと画像処理装置との間の通信の流れを示す図である。

まずホストコンピュータからは、ステップ４０１において印刷の場合はCreateJob（図５）、格納の場合はCreateFile（図６）と称するパケットを画像処理装置１０１に送信する。CreateJobパケットは、画像処理装置に対し、データの印刷を指示するコマンドであり、要求元のユーザ名(<requesting-user-name>タグ)や印刷データの処理に関する指示(<job-instruction>タグ)等の情報が記述されている。<job-instruction>タグには印刷部数を設定する<copies>タグ、両面印刷を設定する<sides>タグ、印刷の仕上げを設定する<finishing>タグなどが含まれ、画像処理装置はこれらのタグに設定された値に基づき、印刷処理を行う。CreateFileパケットは、画像処理装置に対し、データの格納を指示するコマンドであり、要求元のユーザ名（<requesting-user-name>タグ）や格納するデータの処理に関する指示（<file-instruction>タグ）等の情報が記述されている。<file-instruction>タグには格納するデータに付与するファイル名を設定する<file-name>タグ、Read/Write属性を設定する<read-only>タグなどが含まれ、画像処理装置はこれらのタグに設定された値に基づき、格納処理を行う。

画像処理装置がCreateJob/CreateFileパケットを受信すると、ステップ４０２においてSOAP制御部３０４によりパケットが解析され、CreateJobパケットであればプリントサービス、CreateFileパケットであればストレージサービスが呼び出される。その後プリントサービス部３０１またはストレージサービス部３０２は後述のような処理を行い、ステップ４０３においてホストコンピュータに対して図７または図８のような応答を送信する。

図７は、CreateJobパケットに対する応答パケットの一例である。CreateJob応答パケットには、CreateJobコマンド対する結果コード(<result-code>タグ)や生成されたジョブの識別子(<job-id>タグ)、データ受信用ポートのURL(<data-sink-uri>タグ)等の情報が含まれている。図７の例ではデータ受信用ポートとして「http://192.168.0.1/bmlinks/job?1」というURLが示されている。

図８は、CreateFileパケットに対する応答パケットの一例である。CreateFile応答パケットには、CreateFileコマンド対する結果コード(<result-code>タグ)や生成されたジョブの識別子(<job-id>タグ)、データ受信用ポートのURL(<data-sink-uri>タグ)等の情報が含まれている。図８の例ではデータ受信用ポートとして「http://192.168.0.1/bmlinks/job?2」というURLが示されている。

ホストコンピュータは、ステップ４０４においてCreateJob/CreateFile応答パケットを受信すると、ステップ４０５において<data-sink-uri>タグで指定されたURLに対してHTTPのPOSTメソッドを用いてデータを送信する。図９はHTTP POSTメソッドによるデータ転送パケットの一例である。図７や図８の例にあるように、応答パケットの<data-sink-uri>タグの値のパス部分がそのままPOSTメソッドの宛先として指定されるため、画像処理装置は、ジョブを一意に識別することが可能である。画像処理装置はステップ４０６においてデータの受信を行い、受信が正常に終了するとステップ４０７において図１０に示した例のようなHTTPレスポンスパケットをホストコンピュータに送信し、通信を終了する。

図１１は、ホストコンピュータが印刷を行う場合におけるプリントサービス部３０１の動作を示すフローチャートである。

ホストコンピュータから図５に示したようなCreateJobパケットが画像処理装置１０１に送信されると、SOAP制御部３０４によりパケットが解析され、プリントサービス部３０１はステップ１１０１においてプリント要求を受信する。プリントサービス部３０１はプリント要求を受信すると、ステップ１１０２においてデータ受信部３０３に対してデータ受信要求を送信し、その応答としてステップ１１０３においてデータ受信用URL（data-sink-uri）を得る。次に、ステップ１１０４において、データ受信部３０３から受信したデータ受信用URLを使用してCreateJob応答パケットを生成し、ホストコンピュータに送信する。その後は、ステップ１１０５においてデータ受信部３０３からのデータ受信終了通知を待ち、通知を受信するとステップ１１０６において、受信データ格納領域からデータを読み出して印刷を行う。印刷が終了するとステップ１１０７において受信データを削除して処理を終了する。

図１２は、ホストコンピュータがデータ格納を行う場合におけるストレージサービス部３０２の動作を示すフローチャートである。

ホストコンピュータから図６に示したようなCreateFileパケットが画像処理装置１０１に送信されると、SOAP制御部３０４によりパケットが解析され、ストレージサービス部３０２はステップ１２０１において格納要求を受信する。ストレージサービス部３０２は格納要求を受信すると、ステップ１２０２においてデータ受信部３０３に対してデータ受信要求を送信し、その応答としてステップ１２０３においてデータ受信用URL（data-sink-uri）を得る。次に、ステップ１２０４において、データ受信部３０３から受信したデータ受信用URLを使用してCreateFile応答パケットを生成し、ホストコンピュータに送信する。その後は、ステップ１２０５においてデータ受信部３０３からのデータ受信終了通知を待ち、通知を受信するとステップ１２０６において、受信データ格納領域に格納されたデータをストレージサービスが管理する領域に移動し、処理を終了する。

図１３は、データ受信部３０３の動作を示すフローチャートである。

データ受信部３０３は、ステップ１３０１においてプリントサービス部３０１またはストレージサービス部３０２からデータ受信要求を受信すると、ステップ１３０２においてデータ受信用のURLを生成する。その際、生成するURLとしては、「http://<画像処理装置のIPアドレス>/bmlinks/job?<受信ジョブ識別ID>」とする。ここで<受信ジョブ識別ID>は、プリントジョブ/ストレージジョブに関わらず１ずつ増加していく整数値である。次にステップ１３０３においてHTTPサーバ制御部３０６に対してデータ受信用URLを登録する。その後、ステップ１３０４において、データ受信要求を送信してきたプリントサービス部３０１またはストレージサービス部３０２に、生成したデータ受信用URLを送信する。その後、ホストコンピュータからデータ受信用URLに対してデータが送信されてくるので、ステップ１３０５においては、ホストコンピュータから送信されるデータを受信し、ハードディスク１４のジョブ一時受信領域に格納する。ステップ１３０６において、データが終了したかどうかを判定し、終了するまでステップ１３０５を繰り返す。データ受信が終了した場合はステップ１３０７へ進み、HTTPサーバ制御部３０６に登録したデータ受信用URLを削除する。その後ステップ１３０８において、データ受信終了通知を、データ受信要求を送信してきたプリントサービス部３０１またはストレージサービス部３０２に送信し、処理を終了する。

なお、上記実施例においては、ストレージサービスは図１２のフローチャートで示したようにデータ受信部３０３が一時受信領域に格納した受信データを、ストレージサービスが管理している領域に移動させていたが、この移動処理を省略させるように構成することも可能である。そのためには、ストレージサービスはデータ受信部３０３に対してデータ受信要求を送信する際に、最終的に格納したい領域へのパスも同時に指定する。データ受信部においては、このパスを指定された場合は、ホストコンピュータから受信したデータを、指定されたパスの領域に格納する。

（実施例２）
次に第二の実施例について説明する。

本実施例は基本的な構成は第一の実施例と同一であり、その差異のみ説明する。本実施例においては、データ受信部３０３はすべてのデータを受信後にプリントサービスまたはストレージサービスに通知するのではなく、ホストコンピュータからデータの一部を受信するたびに通知することにより、各サービスにおける逐次処理を可能とする。

図１４は、本実施例におけるプリントサービス部３０１の動作を示すフローチャートである。

ホストコンピュータから図５に示したようなCreateJobパケットが画像処理装置１０１に送信されると、SOAP制御部３０４によりパケットが解析され、プリントサービス部３０１はステップ１４０１においてプリント要求を受信する。プリントサービス部３０１はプリント要求を受信すると、ステップ１４０２においてデータ受信部３０３に対してデータ受信要求を送信する。その際、データ受信部３０３がデータの一部を受信するたびに呼出されるCallback関数も同時に送信する。なお、このCallback関数にはデータの印刷を行うための処理が記述されている。そしてデータ受信要求に対する応答としてステップ１３０３においてデータ受信用URL（data-sink-uri）を得る。次に、ステップ１３０４において、データ受信部３０３から受信したデータ受信用URLを使用してCreateJob応答パケットを生成し、ホストコンピュータに送信する。その後は、ステップ１４０５においてデータ受信のたびにCallback関数が呼出され、印刷処理を行い、データの終了とともに処理を終了する。

図１５は、本実施例におけるストレージサービス部３０２の動作を示すフローチャートである。

ホストコンピュータから図６に示したようなCreateFileパケットが画像処理装置１０１に送信されると、SOAP制御部３０４によりパケットが解析され、ストレージサービス部３０２はステップ１５０１において格納要求を受信する。ストレージサービス部３０２は格納要求を受信すると、ステップ１５０２においてデータ受信部３０３に対してデータ受信要求を送信する。その際、データ受信部３０３がデータの一部を受信するたびに呼出されるCallback関数も同時に送信する。なお、このCallback関数にはストレージサービスが管理する領域にデータを格納するための処理が記述されている。そしてデータ受信要求に対する応答としてステップ１５０３においてデータ受信用URL（data-sink-uri）を得る。次に、ステップ１５０４において、データ受信部３０３から受信したデータ受信用URLを使用してCreateFile応答パケットを生成し、ホストコンピュータに送信する。その後は、ステップ１５０５においてデータ受信のたびにCallback関数が呼出され、格納処理を行い、データの終了とともに処理を終了する。

図１６は、本実施例におけるデータ受信部３０３の動作を示すフローチャートである。

データ受信部３０３は、ステップ１６０１においてプリントサービス部３０１またはストレージサービス部３０２からデータ受信要求を受信すると、ステップ１６０２においてデータ受信用のURLを生成する。その際、生成するURLとしては、「http://<画像処理装置のIPアドレス>/bmlinks/job?<受信ジョブ識別ID>」とする。ここで<受信ジョブ識別ID>は、プリントジョブ/ストレージジョブに関わらず１ずつ増加していく整数値である。次にステップ１６０３においてHTTPサーバ制御部３０６に対してデータ受信用URLを登録する。その後、ステップ１６０４において、データ受信要求を送信してきたプリントサービス部３０１またはストレージサービス部３０２に、生成したデータ受信用URLを送信する。その後、ホストコンピュータからデータ受信用URLに対してデータが送信されてくるので、ステップ１６０５においては、ホストコンピュータから送信されるデータを受信し、ステップ１６０１で受信したデータ受信要求に含まれるCallback関数を呼出す。ステップ１６０６において、データが終了したかどうかを判定し、終了するまでステップ１６０５を繰り返す。データ受信が終了した場合はステップ１６０７へ進み、HTTPサーバ制御部３０６に登録したデータ受信用URLを削除し、処理を終了する。

本発明を適用可能な画像処理システムの構築例を示すブロック図画像処理装置のハードウェア構成を説明するブロック図画像処理装置のソフトウェアプログラム構成を説明するブロック図ホストコンピュータと画像処理装置間の通信の流れを示す図ホストコンピュータから画像処理装置に送信されるCreateJobパケットの例ホストコンピュータから画像処理装置に送信されるCreateFileパケットの例 CreateJobパケットに対する応答パケットの例 CreateFileパケットに対する応答パケットの例 HTTP POSTメソッドによるデータ転送パケットの例 HTTP POSTメソッドに対する応答パケットの例第一の実施例におけるプリントサービス部の動作を示すフローチャート第一の実施例におけるストレージサービス部の動作を示すフローチャート第一の実施例にデータ受信部の動作を示すフローチャート第二の実施例におけるプリントサービス部の動作を示すフローチャート第二の実施例におけるストレージサービス部の動作を示すフローチャート第二の実施例におけるデータ受信部の動作を示すフローチャート

Claims

ネットワークに接続され、ネットワークを介して外部クライアント装置からジョブを受信し処理を行う画像処理装置であって、
上記外部クライアント装置からのジョブ送信要求を受信するジョブ送信要求受信手段と、
上記ジョブを受信するための受信識別子を生成する受信識別子生成手段と、
上記ジョブ送信要求に対する応答として、上記受信識別子生成手段により生成された受信識別子の情報を含む応答データを送信する応答手段と、
上記外部クライアントから上記受信識別子に対して送信されるジョブを受信するジョブ受信手段と、
上記ジョブ受信手段により受信したジョブを処理するジョブ処理手段とを有することを特徴とする画像処理装置。
上記受信識別子はURL形式であることを特徴とする請求項１に記載の画像処理装置。
受信したジョブを印刷する印刷手段を有することを特徴とする請求項１、２に記載の画像処理装置。
受信したジョブを格納する格納手段を有することを特徴とする請求項１、２に記載の画像処理装置。
上記ジョブ受信手段は、すべてのデータを受信後に上記ジョブ処理手段に通知し、上記ジョブ処理手段は通知受信後にジョブ処理を開始することを特徴とする請求項１に記載の画像処理装置。
上記ジョブ受信手段は、データの一部を受信後に上記ジョブ処理手段に通知し、上記ジョブ処理手段は通知受信後にジョブ処理を開始することを特徴とする請求項１に記載の画像処理装置。