JP4119002B2 - ネットワーク印刷システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、一般には、ネットワーク印刷コンテキスト（context）において使用するためのプリンタインタフェースに関し、ＨＴＴＰに基づくネットワーク印刷用として特に適するプリントサーバに関する。
【０００２】
【従来の技術】
ＨＴＴＰに基づくプリントサーバを使用することによって、複数のインタネットクライアントが１又は複数のドキュメント処理装置とインタネット通信することが可能になる。プリントサーバのアーキテクチャは、１又は複数のドキュメント処理装置が組込型ＨＴＴＰサーバを有するか否かに関わらす、インタネット通信を実現させる。
【０００３】
米国特許第５，２２０，６７４号には、複数のクライアントおよび複数のプリンタと共同して機能し、クライアントとプリンタとの間の通信を容易にするローカルエリアプリントサーバが開示されている。このサーバは、サーバが通信するすべてのサブシステムに仮想上で関連する広範囲の状態情報を保全する状態収集サブシステムのような種々のサブシステムを備える。状態収集サブシステムは、通知機能を備え、その通知機能によって、印刷システム状態変化または事象の報告が、それらを知ることに関心があるローカルプリントサーバの内外の適切なネットワーク構成要素に送られる。
【０００４】
ますます人気が高まっているワールドワイドウエブ（ＷＷＷ）においては、ハイパーテキストマークアップランゲージ（ｈｔｍｌ）によって「クライアント」コンピュータ上の情報の表示が指定され、ハイパーテキスト転送プロトコル（ｈｔｔｐ）によって、ＴＣＰ／ＩＰネットワークプロトコルによる「サーバ」コンピュータから「クライアント」コンピュータへの情報の転送に対するニュートラル方式が提供される。そのニュートラル方式が特に重要であり、ニュートラル方式においては、情報の転送および表示は、クライアントコンピュータオペレーティングシステムまたはプロセッサ構成に依存せずに、プロトコルに従う「ブラウザ」の機能のみに依存する。このようなソフトウェアは、現在では、ほとんどのコンピュータに対して広く利用できる。クライアントに転送され表示される情報は、前もって定められる静的情報、およびクライアントがサーバに要求する時点において計算される動的情報の両者を含む。公然と利用できるサーバソフトウェアは、多くの場合、共通ゲートウェイインタフェース（ＣＧＩ）を含み、共通ゲートウェイインタフェースを使用することによって、サーバはユーザに特有のパラメータを通過させることができるソフトウェアプログラムを呼び出すことが可能となり、このソフトウェアプログラムの出力はクライアントコンピュータに転送され、そこに表示されることになる。
【０００５】
プリントおよびドキュメント処理機では、制御および状態のためのインタフェースとして、ｈｔｍｌおよびｈｔｔｐを使用することができる。これらのマシンは、幾つかの理由のために、このような使用によって大きな利益を受ける。すなわち、第１に、開発費用が比較的低く、開発期間が比較的短い。その理由は、その機構は、多数のクライアントが使用することが可能であり、そのクライアントが使用する各オペレーティングシステムおよびプロセッサのために、クライアント表示ソフトウェア（多くの場合、「ユーザインタフェース」またはＵＩと呼ばれる）を書き込む必要がないためである。第２に、複数の言語による情報をサーバに記憶することによって多言語インタフェースを形成することが簡単であり、このインタフェースを使用し、サーバは、異なるクライアントによって複数の言語で同時にアクセスされることが可能となる。第３に、プリントまたは文書処理機の機能の改良または変更を、ベンダが新クライアント表示ソフトウェアを開発する不便およびこのような各改良のためにクライアントが新ソフトウェアをあらゆるクライアントコンピュータにインストールする不便なしに、実行できる。
【０００６】
【発明が解決しようとする課題】
米国特許第５，２２０，６７４号に開示されているようなネットワーク印刷システムにおいては、相当な数のオペレーションリクエスト（たとえば、問い合わせ）が、所定のクライアントと１又は複数の印刷サブシステムとの間を通過し、所定の印刷サブシステムのためのマシン設定またはその印刷サブシステムの状態のような所定の印刷サブシステムに関して選択される情報を決定する。これらの問い合わせは、ＨＴＴＰコンテキストによって処理されることが最も好ましい。その理由は、このようなコンテキストは、仕様の変化するドキュメント処理プラットファームの全域においてニュートラルであるためである。しかし、ニュートラル状態のこの利点は、先行技術においては、十分に利用されていないと考えられる。たとえば、ヒューレット・パッカード社（Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ）“ＨＰ”は、サーバによって、複数のクライアントが複数のドキュメント処理機と通信する構成を提供すると考えられている。しかし、この装置を有するサーバを使用するためには、装置が、ＨＰが所有権を有する特定のカードを備えることが必要である。ドキュメント処理機の一部は組込型ＨＴＴＰサーバを含み、その他は組込型ＨＴＴＰサーバを含まないが、これらのドキュメント処理機間においてインタネットオペレーションのホストを行う機能を有するプロキシサーバが提供されることが望ましい。
【０００７】
その上、通常のプロキシサーバにおいては、アプリケーションレイヤは、オペレーション要求をクライアントとドキュメント処理装置との間において転送することができるコネクティビティレイヤと連絡している。一部のクライアント／サーバに基づくソフトウェアは、インタフェースを貫通するミドルウェアと呼ばれるコネクティビティレイヤのために便宜を図る。オペレーション中は、ミドルウェアは複数のモジュールを含み、各モジュールはクライアントと１又は複数の目標装置との間のオペレーション要求の転送を容易にする。たとえば、ひとつのモジュールはマイクロソフト（Ｍｉｓｒｏｓｏｆｔ）に基づくクライアントとドキュメントセンタ（“Ｄｏｃｕｍｅｔ Ｃｅｎｔｒｅ”はゼロックス社（Ｘｅｒｏｘ Ｃｏｅｐ．）の登録商標である）に基づくプリンタとの間の問い合わせの転送を容易にする。ひとつの先行技術スキーマにおいては、オペレーションに関する要求は、クライアントからアプリケーションレイヤを経由して受け取られ、要求に対応する一連のパラメータはアプリケーションレイヤによって生成される。一例においては、要求は目標文書処理装置の選択されるマシン設定に関連する値を探索して確認することができる。したがって、要求される設定は、コネクティビティレイヤに送られ、次に、コネクテイビティレイヤはアプリケーションレイヤによって指定される値を取得する。
【０００８】
アプリケーションレイヤを使用してパラメータを設定するこの方法は、アプリケーションコードの作成者に関する問題を生じ、それは作成者は、対応する目標に関連する現在のパラメータに最も精通している者ではない場合があることである。他方、通常、コネクティビティレイヤに対するこれらの書き込みコードは、目標となる文書処理装置が関連するパラメータと非常に密接な関係がある。それ故、所定の文書処理装置に関連する値を取得する責務がアプリケーションレイヤからコネクティビティレイヤすなわちミドルウェアレイヤに移転されるシステムが提供されることが望ましい。
【０００９】
【課題を解決するための手段】
本発明によれば、１又は複数のクライアントが、複数のレイヤによって特徴づけられるアーキテクチャを有するプリントサーバを経由して、複数のプリンタと通信する印刷システムが提供される。実際上、複数のレイヤの１つは、複数のクライアントの１つから要求（リクエスト）を受け取り、その要求は複数のプリンタの１つに関して実行される必要があるオペレーションを指定する。印刷システムはアプリケーションレイヤを備え、アプリケーションレイヤは、複数のレイヤーの１つと通信し、複数のレイヤの１つによって受け取られる要求に基づいてコマンド（命令式）を生成する。通信インタフェースは、第１コネクティビティモジュールおよび第２コネクティビティモジュールを含み、第１コネクティビティモジュールは複数のプリンタ中の第１プリンタと連絡し、第２コネクティビティモジュールは複数のプリンタ中の第２プリンタと連絡する。また、ルーティングインタフェースは、前記アプリケーションレイヤおよび前記通信インタフェースの両者と連絡し、第１コネクティビティモジュールおよび第２コネクティビティモジュールの選択される１つに関する命令式を指示し、第１および第２コネクティビティモジュールの内で選択された１つは命令式を使用し、複数のプリンタの１つに関して指定されるオペレーションの少なくとも一部を実行する。
【００１０】
【発明の実施の形態】
図１は、好適な実施形態における使用に適する形式のディジタル複写機を示す図である。図に示すように、システムは、文書フィーダ１および操作（または表示）パネル２を備える。所望の条件が操作パネル２に入力されると、文書フィーダ１は文書を画像読み取り装置３上の所定の読み取り位置に搬送し、文書の読み取り完了後、読み取り位置から文書を搬出する。画像読み取り装置３は、その読み取り位置に搬入される文書を照明する。結果として生じる文書からの反射は、たとえば、ＣＣＤ（電荷結合素子）画像センサのような固体撮像素子によって、対応する電気信号、すなわち画像信号に変換される。画像形成装置４は、電子複写、感熱、熱転写、インクジェット、または類似の従来のシステムによって、普通紙または感熱紙上に、画像信号によって表される画像を形成する。
【００１１】
用紙が、用紙カセット７から画像形成部４に供給されると、形成部４は用紙の片面に画像を形成する。両面複写部５は、片面に画像が印刷された用紙を反転させて再び画像形成部４に供給するように組み立てられる。その結果、画像が用紙の反対側面に形成され、両面複写が完了する。両面複写部５は、通常、用紙を直ちに再供給、または逐次堆積された用紙を底部の用紙から頂部の用紙まで連続して再供給するように設計されている。画像形成部４から排出される用紙、または両面複写紙は、出力装置６によって、ページの順序によってまたはページごとに分類される。
【００１２】
通常、アプリケーション８は、文書フィーダ１、操作パネル２、画像読み取り装置３、画像形成部４、両面複写部５、出力装置６および用紙カセット７を共用し、これらは複写機システムに組み込まれる資源である。以下に述べるように、アプリケーションは、複写機アプリケーション、プリンタ（ＩＯＴ）アプリケーション、ファクシミリ（Ｆａｘ）アプリケーション、および他のアプリケーションを含む。さらに、ディジタル複写機システムは、従来のネットワーク接続９によって、ネットワークに接続される。
【００１３】
図２は、符号１０によって示される多機能、ネットワーク適応印刷システムを示す図である。印刷システム１０は、ネットワークサービスモジュール１４に接続されて作動する印刷機１２を備える。印刷機１２は電子サブシステム１６を備え、電子サブシステム１６は、ビデオ制御モジュール（ＶＣＭ）と呼ばれ、スキャナ１８およびプリンタ２０と接続される。一例においては、ＶＣＭ１６は、ディジタル複写構造のスキャナおよびプリンタの動作を調整し、この例は、Ｓａｌｇａｄｏによる米国特許第５，５７９，４４７号に開示されている。ディジタル複写構造においては、スキャナ１８（画像入力端末（ＩＩＴ）とも呼ばれる）は、ＣＣＤ全幅アレイを使用して原文書の画像を読み取り、収集されるアナログビデオ信号をディジタル信号に変換する。次に、スキャナ１８に関連する画像処理システム（図示してない）は、信号補正などを実行し、補正された信号を多レベル信号（たとえば、２進信号）に変換し、多レベル信号を圧縮し、好適には同一物を電子事前照合（図示してない）に記憶する。
【００１４】
図２を参照すると、プリンタ２０（画像出力端末（ＩＯＴ）とも呼ばれる）は、好適には、静電写真プリントエンジンを備える。一例においては、プリントエンジンは多ピッチベルト（図示してない）を有し、多ピッチベルトは、同期ソース（たとえば、レーザラスタ出力走査装置）または非同期ソース（たとえば、ＬＥＤプリントバー）のような撮像ソースによって書き込まれる。印刷コンテキストにおいては、多レベル画像データがＥＰＣメモリから読み出され、同時に、撮像ソースが、画像データに従って起動および停止され、フォトレセプタ上に潜像を形成する。次に、潜像は、たとえば、ハイブリッド飛び越し現像法を使用して現像され、印刷媒体シートに転写される。その結果得られるプリントを定着すると、両面または片面出力物に転化される。当業者には、本発明の実施形態の基礎となる概念を変更することなく、静電写真プリントエンジン以外の形式のプリンタを仮定することができることは理解される。たとえば、印刷システム１０は、熱インクジェットまたはイオノグラフィックプリンタを使用して具体化することができる。
【００１５】
図３を参照して、ネットワークサービスモジュール１４について、さらに詳細に述べる。当業者には認識されるように、ネットワークサービスモジュールのアーキテクチャは、公知の「ＰＣクローン」のアーキテクチャと類似している。特に、一例においては、コントローラ４４はサンマイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．）製のＳＰＡＲＣプロセッサの形式であり、標準Ｓバス７２に接続される。図３に示す実施形態においては、好適にはＤＲＡＭの形式であるホストメモリ７４、およびＳＣＩＳディスク駆動装置７６が、Ｓバス７２に接続され作動される。図３には示してないが、記憶または入出力装置が、適切なインタフェースチップによってＳバスに接続される。さらに、図３に示すように、Ｓバスは、適切なネットワークインタフェース８０によって、ネットワーク７８に接続される。一例においては、ネットワークインタフェースは、コントローラ４４のハードウェア／ソフトウェア構成要素をネットワーク７８のハードウェア／ソフトウェア構成要素と関係付けるために必要とされるすべてのハードウェアおよびソフトウェアを含む。たとえば、ネットワークサービスモジュール１４とネットワーク７８との間において種々のプロトコルをインタフェースするために、ネットワークインタフェースは、ソフトウェアの中でも特にノベル社（Ｎｏｖｅｌｌ Ｃｏｒｐ．）製のネットウェア（Ｎｅｔｗａｒｅ）（登録商標）を備えることができる。
【００１６】
一例においては、ネットワーク７８は、エミッタまたはドライバ８４を有するワークステーション８２のようなクライアントを含む。動作時は、ユーザは、複数の電子ページおよび処理命令のセットを含むジョブを生成することができる。次に、ジョブは、エミッタによって、ＰｏｓｔＳｃｒｉｐｔのようなページ記述言語によって記述される表現に変換される。次に、ジョブは、コントローラ４４に転送され、コントローラ４４において、ジョブは、Ａｄｏｂｅ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるデコンポーザによって解釈される。
【００１７】
図４は、図３に概略示したネットワークコントローラをさらに詳細に示すブロック図である。図４に示す実施形態においては、クライアント１００（図３において、ワークステーション８２およびエミッタ８４として示したような各クライアント）は、ＬＰＤ（ＵＮＩＸに対するプロトコル）、Ｎｏｖｅｌｌネットワークプロトコル、ＡｐｐｌｅＴａｌｋおよびＤＣＳ（“Ｄｏｃｕｍｅｎｔ Ｃｅｎｔｒｅ Ｓｙｓｔｅｍ”として知られるＸｅｒｏｘディジタル複写機のためのプロトコル）のような種々のプロトコルによって構成される。したがって、各クライアントは、好適には、「ブラウジング」機能を備え、ブラウジング機能によって、ＷＷＷにアクセスするために、種々の位置において、たとえば、ＨＴＴＰサーバと通信することができる。一例においては、所定のクライアントは、Ｎｅｔｓｃａｐｅ（２．０１以上）またはＭｉｃｒｏｓｏｆｔ（たとえば、“ｎａｓｈｖｉｌｌｅ”（マイクロソフトの登録商標））のいずれかから得られるブラウザを使用する。クライアントは、コネクティビティサービス（ＣＳ）１０２によって、ネットワークサーバすなわち電子サブシステム（“ＥＳＳ”）１４と通信する。図４に示すように、電子サブシステムは、二つの部分、すなわち、マイクロカーネル１０４（特に、ＤＰＡ ＩＳＯ １０１７５／ＰＯＳＩＸ ＩＥＥＥ １００３．７を基礎とするモデルにマップされるマイクロカーネルの部分抽象モデル）およびアプリケーション特有のサブシステム１０６を備える。
【００１８】
通常、ネットワーク、すなわち、二地点間を結ぶ印刷実行依頼は、（ＣＳ）サブシステムのプロトコルサービスレベルにおいて始まる。各プロトコルサービスは、公知のソケットによって接続標識をウオッチングする。プロトコルサービスが接続標識を受信すると、プロトコルサービスはジョブ要求をコネクティビティコアに実行依頼する。コネクティビティコアは、この要求をＤＰＡ互換性フォーマットに変換し、ＤＭサブシステム１０８に転送する。ジョブサブシステムが認可されると、プロトコルサービスは、１又は複数のドキュメントを実行依頼することができる。文書実行依頼は、文書要求および入出力ディスクリプタをコネクティビティコアに送ることによって達成される。文書実行依頼も変換され、ＤＭサブシステムに転送される。
【００１９】
文書が受け取られた後で、プロトコルサービスは、データを下にあるプロトコルスタックから受け取り、データを入出力ディスクリプタに書き込むことを開始する。このデータは、入出力ディスクリプタの反対側において コンシューマによって読み取られるか、またはシステムのどこかにスプールされる。遠隔クライアントがそれ以上はデータがないことを示すとき、入出力ディスクリプタは閉鎖され、この特定の文書の終了の信号が出される。すべての文書が受け取られた後で、ジョブ終了要求が、プロトコルサービスからコネクティビティコアに送られ、コネクティビティコアはこの要求をＤＭに転送する。最後には、この要求は、システムによって完成され、プロトコルサービスはすべてのジョブに関連する資源を解放する。
【００２０】
通常、問い合わせは、クライアント（図４）から印刷機１２に向けられ、一実施形態においては、ＤＭサブシステム１０８と共に作動するＨＴＴＰサーバ１０７を使用することによって処理される。好適な実施形態においては、ＨＴＴＰサーバの構造および機能はプロキシサーバ１０７Ａ（図５）にあり、このプロキシサーバの詳細について、以下に述べる。図４および図５に示す実施形態はＨＴＴＰサーバを備えるが、他のサーバ形式を使用する実施形態が考えられることを、当業者は理解するはずである。すなわち、サーバ１０７または１０７Ａのいずれかは、クライアントと文書処理装置との間のネットワーク（技術上、用語「ブラウジング」が考えられるような）において、好適な実施形態が意図する目的を変更することなく、ブラウジングを容易にする任意の形式のサーバとすることができる。
【００２１】
マイクロカーネルは、大部分のＤＰＡ／ＰＯＳＩＸサーバ機能を実行する文書管理（ＤＭ）サブシステムを有する。ＤＭサブシステムは、ユーザ要求の妥当性を検査し、要求を待ち行列に入れ、文書データをスプールし、装置に対するジョブをスケジュールし、また状態情報を収集し保全する。ＤＭサブシステムは、一部の態様においてＤＰＡ／ＰＯＳＩＸサーバを拡張し、それは、ＤＭサブシステムは走査ジョブ（フィリングまたはファックス送信のため）および複写ジョブを取り扱うように構成することができるためである。ＤＭは、文書探索（ｓｎｉｆｆｉｎｇ）、スプーリング、およびスケジューリングサービスのために準備する。文書処理１１０のようなサービスプロバイダは、ＤＭに関するそれらのサービスを記録することができる。
【００２２】
文書処理（ＤＰ）は、画像フレーム記憶（ＩＦＳ）および少なくともひとつのプロデューサの例示を含み、マイクロカーネルを備える。ＤＰは、文書を処理して画像とする（マイクロカーネルの構成によって、全フレームバッファまたはラスタ走査帯域）。画像フレーム記憶は、プロデューサをコンシューマに割り当てる。
【００２３】
本質上、マイクロカーネル１０４は、共通電子サブシステムとして考えることができるが、サブシステム１０６は、アプリケーション特有の電子サブシステムとして考えることができる。すなわち、マイクロカーネル１０４は、プリントサーバの基本ビルディングブロックを含むが、一方、サブシステム１０６は、所望のレベルの操作性を有するビデオ制御モジュール１６を提供するために、マイクロカーネル１０４と共に必要とされるすべてのソフトウェア構成要素を含む。特に、マイクロカーネル１０４から出るすべてのコマンド／要求を完全にフィルタリングするエージェントを、符号１１４によって示す。基本的に、エージェントは、共通電子サブシステムに対する「かぎ」としての機能を果たし、すべての遠隔資源の取扱を容易にする。エージェントは、プリントサービス１１６およびダイアグノスチックス１１８のような他のサービスと共に作用し、ビデオ制御モジュールのオペレーションを支援する。
【００２４】
エージェント１１４は、電子サブシステム待ち行列（キュー）ユーティリティ１２０と通信し、特に、複合待ち行列を保全する。エージェントおよび電子サブシステム待ち行列ユーティリティの機能を結合することはできるが、本明細書のモジュール化したモデルにおいては別々に示す。電子サブシステム待ち行列ユーティリティは、走査からファイルまでの処理１２２にも連絡され、この処理によって、先に走査されたネットワークに関する文書のファイリング、および課金／許可／認証サービス（“ＡＡＡ”）１２４が容易になる。課金／許可／認証サービスを使用して、特に、遠隔クライアントによって実行される必要があることが要求されるある一定の行為の実行が許可される。一例においては、課金／許可／認証サービスは、ゼロックス社のＤｏｃｕＳＰ １．０プリントサーバに認められる形式のソフトウェアによって具体化される。明らかに、課金／許可／認証サービスによって、ひとつ以上の待ち行列に入れられたジョブに関して、許可されていないシステムユーザによる望ましくない干渉が阻止される好適な実施形態が容易になる。さらに、明らかに、電子サブシステム待ち行列ユーティリティ１２０を使用することによって、待ち行列情報以外の情報のホストを得ることができる。たとえば、ユーティリティ１２０を使用してマシン構成情報（マシン設定のような）および待ち行列以外のサブシステム／処理に関係する状態情報を得ることができる。
【００２５】
図４に示す印刷機１２の態様について述べると、複写サービス１２８は、電子サブシステム待ち行列ユーティリティ１２０およびビデオ制御モジュール待ち行列ユーティリティ１３０に連絡される。複写サービスは、一例においては、コントローラ４４（図３）にあり、複写機側において、文書管理１０８に匹敵する機能を実行する。特に、複写サービスは、複写の現像およびファックスジョブならびにビデオ制御モジュールの管理を監視する。ビデオ制御モジュール待ち行列ユーティリティ１３０は、マークサービス１３２および適切なユーザインタフェース１３４と通信し、それらから得られる待ち行列に関係するデータを収集する。ユーザインタフェースおよびビデオ制御モジュール待ち行列ユーティリティの機能は組み合わせることができるが、これらの機能は図４においてはモジュール化されたモデルとして別々に示す。
【００２６】
たとえば、ゼロックスのＤｏｃｕｍｅｎｔ Ｃｅｎｔｒｅ ３５ディジタル複写機の場合は、マークサービスは、プリンタ２０（図２および図３）と関連し、ビデオ制御モジュール待ち行列は、ユーザインタフェースと関連する。当業者は理解するように、マークサービスおよびユーザインタフェースの両者は、現像およびビデオ制御モジュール待ち行列の保全において重要な構成要素である。たとえば、ビデオ制御待ち行列の状況は、マークサービスのアクティビティの結果として絶えず変化するが、相当な量の制御がユーザインタフェースとの通信の関数としてビデオ制御モジュール待ち行列上に明示される。
【００２７】
さらに図４について述べると、ＨＴＴＰサーバ１０７は、さらに、符号１４０で示される共通ゲートウェイインタフェース（“ＣＧＩ”）を備える。前述したように、共通ゲートウェイインタフェース１４０は、適切なソフトウェアの使用によって、ユーザが提供するパラメータに対応する出力をクライアント１００に送信することができる。特に、実際に、クライアントユーザは問い合わせ（パラメータのセットを含む）を生成し、その問い合わせは印刷システム１２のような遠隔ネットワークシステムからの出力を要求する。一例においては、要求は、待ち行列中のジョブの順序または印刷システムの現在の設定に関する情報について行われることがある。当業者には理解されるように、問い合わせは、印刷システムに関連する広範囲の情報に対して向けられ、また問い合わせを受ける遠隔ネットワークシステムは印刷システム以外のシステムを含み、たとえば、遠隔ネットワークシステムは独立型走査装置を備えることがある。
【００２８】
図５について述べると、プロキシサーバによって、クライアント１００は文書処理装置２００−１（たとえば、印刷システム１２）、２００−２、．．．２００−Ｎと接続され通信が可能となり、プロキシサーバは、以下の重要な構成要素を備える。
【００２９】
すなわち、
ＨＴＴＰサーバ２０１と、
アプリケーションレイヤ２０２と、
装置（デバイス）データキャッシュおよび装置／ユーザデータベース２０４と、
ルーティングインタフェース２０６と、
通信インタフェース２０８と、
を備える。
【００３０】
例示の実施形態においては、ＨＴＴＰサーバ２０１は、マイクロソフト社のインタネット情報サーバを含むが（“ｉｎｔｅｒｎｅｔ ｉｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ”（“ＩＩＳ”）は、マイクロソフト社によってウェブサービスに関連して使用される登録商標である）、アプリケーションレイヤ２０２は、マイクロソフト社のインタネットサーバアプリケーション（“ｉｎｔｅｒｎｅｔ Ｓｅｒｖｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ”（“ＩＳＡｓ”）は、マイクロソフト社によってウェブサービスに関連して使用される登録商標である）、およびフィルタ（たとえば、印刷ハンドラ、情報ハンドラに対する要求、およびデータ更新ハンドラ）を含む。インタネットサーバアプリケーションは、ダイナミックリンクライブラリ（“ＤＬＬ”）であり、ＤＬＬは、クライアント要求に対応して、インタネット情報サーバのアドレス空間の負荷となってしまう。要求に応じて行われる動作は、インタネットサーバアプリケーションにおいて発生する。
【００３１】
例示の実施形態においては、装置データキャッシュおよび装置／ユーザデータベース２０４（以下、簡単にするために「データベース」と呼ぶ）は、プロキシサーバが装置（デバイス）２００から得た関連するすべての情報を記憶する。記憶情報は、特に、
装置２００のリストと、
各装置に関する現在のジョブ待ち行列と、
各装置の現在のジョブ状態と、
各装置に対して設定可能な現在サイトと、
各装置に対するドライバ（単数または複数）と、
各装置に対するクライアントにおいて表示される必要がある適切なストリングおよびビットマップに関する基準と、
を含む。
【００３２】
ルーティングインタフェース２０６は、好適にはアプリケーションプログラマブルインタフェースを備え、アプリケーションプログラマブルインタフェースは、一例においては、三つのサブシステム、すなわち、データ供給アプリケーション、データ獲得アプリケーション、および装置インストールツールを含む。好適には、データ供給アプリケーションは、（１）特定の装置におけるサイト設定可能値を変更し、（２）ジョブ管理コマンドを特定の装置に対して発行する。さらに、データ獲得デーモンは、通信インタフェース２０８を初期設定し、各登録された装置について、たとえば、装置、ジョブ状態、およびサイト設定可能情報を通信インタフェース２０８から収集する。次に、デーモンは、データベースにこのような情報を転送し記憶させる。最後に、装置インストールツールは、以下に詳細に述べるように、クライアント要求に応じて装置を追加または削除することに対応する。
【００３３】
通信インタフェースは、主にクライアントと装置との間のコネクティビティを提供することを目的とするソフトウェアプログラムのセットである。言い換えれば、通信インタフェースの主要目的は、文書処理装置とプロキシサーバのデータベースとの間の通信を提供することである。実際に、通信インタフェースは、データ獲得デーモンと顧客のネットワークの支援装置との間の連絡係として作用する。通信インタフェースは、種々の装置状態、ジョブ状態、およびサイト設定可能データを、Ｃ＋＋オブジェクトおよびそのメンバ機能によって、収集し報告する方法を記憶している。一例においては、通信インタフェースは、ソフトウェアモジュールを備え、データベースと装置との間の通信を制御する。従って、所定のモジュールを適応させ、単独装置または装置のファミリー全体の機能を果たすことができる。
【００３４】
図より理解されるように、図４に開示されるサーバの基礎にある概念を使用して、図５に示す通信インタフェースを具体化することができるが、これはゼロックス社によって提供される印刷システムＤｏｃｕｍｅｎｔ Ｃｅｎｔｒｅ Ｓｙｓｔｅｍ ３５に存在する別のモードのインタフェースである（Ｄｏｃｕｍｅｎｔ Ｃｅｎｔｒｅ Ｓｙｓｔｅｍはゼロックス社の登録商標である）。以下は、通信インタフェースの概要であり、ミドルウェアレイヤ構成要素、ネットワーク抽象レイヤ構成要素、インフラストラクチャレイヤ構成要素、およびその他のプロトコルを含む。
【００３５】
ミドルウェアレイヤ構成要素
このレイヤは、物理ネットワークの基本アブストラクトを具体化し、ネットワーク近傍、待ち行列、ファイルサーバ、およびプリンタ、多機能装置の少なくとも一方を含むすべての支援ネットワーク実体のオブジェクト表現を提供する。さらに、このレイヤは、アブストラクトを、Ｎｏｖｅｌｌ、ＳＮＭＰ、およびＲＰＣを含む多数の異なるネットワークオペレーティングシステムに翻訳する。
【００３６】
ネットワークアブストラクトレイヤオブジェクト
このサービスは、ネットワーク抽象ライブラリに対するインタフェースを提供し、Ｃ＋＋オブジェクトのセットとして具体化される。
【００３７】
インフラストラクチャレイヤ構成要素
このレイヤは、文書処理プラットフォームのひとつ以上のファミリに対する低レベルネットワークコネクティビティを提供する。
【００３８】
その他のプロトコル支援
前述した構成要素の操作性を容易にするために使用されるプロトコルは、特に、ＴＣＰ／ＩＰ、Ｎｅｔｗａｒｅ（“Ｎｅｔｗａｒｅ”は、ネットワークオペレーティングシステムに関連して、Ｎｏｖｅｌｌ，Ｉｎｃ．によって使用される登録商標である）、およびＬＡＮマネージャを含む。
【００３９】
図５に示すシステムに対して考えられる選択されるデータフローシナリオを、以下に示す（括弧内の数字は図５における位置を示す）。
【００４０】
通常、
・データベースは、すべての関連する装置情報に対するキャッシュとして作用する。
【００４１】
・クライアントは、データベースから、データベースを通じて情報を受け取る。
【００４２】
・データベースは、データ供給および獲得デーモンによって通信インタフェースを経由して、また装置インストールツールによって、転送され記憶される。
【００４３】
サーバからの情報に対するクライアント要求
装置状態、ジョブ状態、および現在サイト設定可能値について、
・各事例において、クライアントは、特定の型の特定の装置に対するＵＲＬ（ウェブページ）を要求する（１）。
【００４４】
・ＨＴＴＰサーバは、アプリケーションレイヤの適切な機能を呼び出す（２）。
【００４５】
・その機能が、ホームページ（装置の型に関する）およびそれに関連するデータ（特定の装置に関する）をデータベースから要求し（３）、その機能はそのデータを戻す（１０）。
【００４６】
・アプリケーションレイヤは、適切なウェブページを検索し、データに差込み、そのページをクライアントに戻す（１１、１２）。
【００４７】
・ＩＳＡは、適切なウェブページを検索し、データに差し込み、そのページをクライアントに戻す（１１、１２）。
【００４８】
プロキシサーバに対する情報のクライアントアップロード
（装置／ジョブ管理指令）
変更されるサイト設定可能値およびジョブ管理コマンドについて、
・各事例において、クライアントは、データおよびその目的をＨＴＴＰサーバに送る（１）。
【００４９】
・ＨＴＴＰサーバは、アプリケーションレイヤの適切な機能を呼び出す（２）。
【００５０】
・そのアプリケーションレイヤの機能は、データベース中の適切な呼び出し（単数または複数）を変更する（３）。
【００５１】
・データベース中の値を変更する試行が、データ供給関数呼び出しをトリガし（４）、データ供給関数呼び出しは適切な装置上において、通信インタフェースを経由して値を変更する（５、６）。
【００５２】
・データが、適切な装置上において更新されるとき、データベースはデータの変更を完了する。
【００５３】
装置からの情報に対するプロキシ要求
装置状態変化、ジョブ状態変化、および現在サイト設定可能値、装置追加および削除について、
・データ獲得デーモンは、通信インタフェースを有する装置を登録する（１３）（新しい装置が、システムアドミニストレータとして現れ、プロキシサーバにプリント待ち行列を加える）。
【００５４】
・ミドルウェアは、次に、その装置に対する現在の装置状態／ジョブを獲得し（７）、それをデータ獲得デーモンに戻すことに着手する（８）。
【００５５】
・データ獲得デーモンは、更新されたデータをデータベースに記憶する（９）。
【００５６】
・データベースのデータが変化しようとするとき、データベースはアプリケーションレイヤの機能を呼び出し、その機能によってデータを更新し適切なクライアントに送る。
【００５７】
装置インストール
ユーザは、任意の名称、装置ＩＰアドレス、および装置タイプを特定することによって新装置を定義する。その装置に関連するＬＰＲポートおよび待ち行列が、ＨＴＴＰサーバ上に自動的に準備される。
【００５８】
・次に、新装置は、クライアントにおける表示のためにデータベースに記載される（１６）。
【００５９】
・また、新装置は、データベースにアクセスするために通信インタフェースによって登録される（１５）。
【００６０】
図６（Ａ）および（Ｂ）を参照して、好適な実施形態の有利な態様について述べる。（Ａ）に示す比較的好適でない実施形態においては、アプリケーションレイヤは、詳細要求、たとえば、情報に関係のある装置を得ることに関する要求を生成しなければならない。すなわち、クライアントが装置２００（図５）のひとつのマシン設定に関する情報を所望するこれらの状態の場合は、アプリケーションは、図６（Ａ）に示す実施形態においては、クライアントがシークするマシン値設定に関する詳細リストを有する通信インタフェース２０８を提供する。次に、詳細リストは、通信インタフェース内の適切なモジュール（“ＣＩＳ”）に送られ、そのモジュールによってリストの待ち行列またはコマンドがクライアント要求値が提供されている対応する装置に送られる。モジュールに関して、開示されるシステムの各装置は、Ｃ＋＋クラスのインスタンスとして表され、各クラスは装置の型を表す。すなわち、ひとつのクラスは、ひとつの型の装置（たとえば、印刷システム）に対応し、別のクラスは、別の型の装置（たとえば、独立型撮像装置）に対応し、以下同様である。前述より理解されるように、この比較的好適でない手法は、アプリケーションレイヤが情報探索の対象である特定の装置に関連する種々のマシン設定に関する比較的重要な知識を有するために、ひとつの書き込みコードを必要とする。
【００６１】
対照的に、図６（Ｂ）に示す好適な手法においては、アプリケーションは、クライアントから要求を受け取り、その要求を引数を有する関数呼び出しに変換する。実際には、以下の論議より明らかなように、情報呼び出しによって、ルーティングインタフェース２０６は通信インタフェースに、簡略な方法によって、クライアントがどんな情報を所望するかを伝達する。特に、大部分の関数およびその引数が、通信インタフェースの適切なモジュールに対して利用可能となり、そのモジュールは、どの値が特定の装置に提供される必要があるか、またはどの動作が特定の装置に関してとられる必要があるかを決定する。理解されるように、これによって、アプリケーションレイヤが提供する必要があるコマンドの量が非常に減少される。
【００６２】
コミュニケーションレイヤの基礎をなす構造／機能を使用することによって、各装置に対するインタフェースは、装置がどの型であるかに関係なく、および装置がアクセスする必要がある基礎をなす構造／関数に関係なく、アプリケーションレイヤとっては同じに見える。
【００６３】
プロキシサーバによって使用される関数呼び出しのリストを以下に例示する。

図７は、前述した呼び出しまたはコマンドが使用される方法の概要を示す図である。最初に、ステップ２１４において、要求が、クライアント１００（図５）からプロキシサーバ１０７Ａに実行され、要求はアプリケーションレイヤ２０２において読み取られる。関数呼び出しの実行に従って、アプリケーションレイヤはデータベース２０４を検査し（ステップ２１６）、装置に関してどの情報が存在するか、および何時その情報をデータベースに転送し記憶するかを決定する。好適には、データベース内の情報は、「標識付されたデータ」であるので、ある一定の環境においては、情報に対するクライアント要求は、このような要求に関しては通信インタフェース２０８を呼び出すことなく、アドレス指定されることができる。たとえば、ひとつの考えられる状態においては、比較的最近のマシン設定情報は、通信インタフェースを呼び出すことなく、このような要求に対する直接応答によって、データベースからクライアントに提供される。論議を分かり易くするために、以下においては、装置２００に関する情報またはオペレーションは、クライアントの要求に直接に応答するルーティングインタフェース２０６を有する通信インタフェースを呼び出すことによって実行されると仮定する。
【００６４】
ステップ２１８において、要求は、装置インストール、すなわち装置追加をシークするかに関する決定が行われる。追加が要求されると仮定すると、ステップ２２０において、検査が実行され、追加する必要がある装置は既にデータベースに記載されているかが決定される。装置がデータベースに記載されている場合、すなわち、装置が既にインストールされている場合は、次に、ステップ２２２において、エラーメッセージが発行される（すなわち、エラーメッセージがインストールをシークするクライアントに返答される）。インストールされていない場合は、ステップ２２４において、追加関数呼び出しが、追加される必要がある装置の名称によって書き入れられる。次に、ルーティングインタフェース２０６（好適には、ＡＰＩ）は、通信インタフェース２０８によって、以下に述べる手順に従って新装置を追加する（ステップ２２６）。
【００６５】
新装置の追加に対する要求が行われなかったときは、ステップ２３０において、装置を除去する必要があるかに関する決定が行われる。装置を除去または削除する必要があると仮定すると、ステップ２３２において、装置はデータベース２０４に記載されているかに関する決定が行われる。除去する必要がある装置がデータベースにないときは、次に、ステップ２３４において、エラーメッセージが発行される（すなわち、エラーメッセージが設置をシークするクライアントに返答される）。データベースに存在するときは、ステップ２３６において、除去関数呼び出しが除去される必要がある装置の名称によって書き入れられる。次に、ルーティングインタフェースすなわちＡＰＩ２０６は、通信インタフェース２０８によって、以下に述べる手順に従って、指定される装置を除去する（ステップ２３８）。
【００６６】
インストールが必要とされないと仮定すると、ステップ２４２において、獲得オペレーションが必要とされるかを決定する決定が行われる。獲得オペレーションを提供するために、獲得関数が、適切なアプリケーションレイヤによって提供され（ステップ２４４）、その対応する引数が以下に述べる手順に従って書き入れられる。次に、ステップ２４６の方法に従って、ＡＰＩ２０６は、通信インタフェースによって、要求される獲得オペレーションを具体化する。他方、設定オペレーションが要求されるときは（ステップ２４８参照）、次に、設定関数が、アプリケーションレイヤによって提供され（ステップ２５０）、その対応する引数が以下に述べる手法に従って書き入れられる。次に、ＡＰＩ２０６は、ステップ２５２の方法に従って、通信インタフェースによって、要求される設定オペレーションを具体化する。いかなる場合でも、図７に示す具体化によって開始される動作の状態は、「状態」ブロックを経由して動作を要求するクライアントに返答される。
【００６７】
以下のコマンド／呼び出しは、サーバ１０７Ａの選択される構成要素によって具体化され、その構成要素を以下「インタフェース」と呼ぶ。
【００６８】
ジョブ管理コマンドは、ユーザが、ウインドウＮＴ待ち行列において、またはもしあれば宛先装置のハードディスクにおいて、インタフェースが認識するジョブに関するコマンドを発行することを可能とする。呼び出しプログラムについては、ジョブがサーバ待ち行列にあるかまたは装置にあるかによる相異はない。呼び出しは同じである。
【００６９】
状態コマンドは、ユーザが、特定の装置に関する現在情報、または特定の装置に予定されるジョブに関する現在情報を獲得することを可能とする。
【００７０】
構成コマンドは、装置の非揮発メモリ中にあり、現在装置の構成を規定する種々の値を獲得および設定するために使用される。
【００７１】
設置コマンドの開示
開示される実施形態に関する多数の態様が、当業者には理解される。
【００７２】
第一に、コード生成を最適化するプロキシサーバが提供される。特に、アプリケーションプログラミングインタフェース（ＡＰＩ）を、アプリケーションレイヤの下流かつ通信インタフェースの上流に配置することによって、コミュニケーションレイヤにおいてコードを生成する負担を増加させることなしに、アプリケーションレイヤにおいてコードを生成する負担が最小化される。本質上、ＡＰＩを賢明に使用することによって、コード生成はアプリケーションレイヤと通信インタフェースとに、インテリジェントな方法によって配分される。
【００７３】
ＡＰＩの使用の結果として、アプリケーションレイヤからコミュニケーションレイヤに対する要求すなわち「呼び出し」は、非常に簡単になる。好適には、所定の装置から情報を得るためまたは所定の装置に関するオペレーションを実行するために、アプリケーションレイヤは、適切な引数を有する関数呼び出しを含むＡＰＩを提供することしか必要としない。次に、ＡＰＩは、適切に処理するために、関数呼び出しを通信インタフェースのサブシステムに送る。
【００７４】
第二に、プロキシサーバは、インタネットコンテキストにおいては、すべての分類の文書処理装置と共にに使用することができ、どの文書処理装置も特にインタネット使用のために適応させる必要はない。したがって、すべての装置は、特定のアダプタカード、ＨＴＴＰサーバの少なくとも一方の保有にも関わらず、サーバと共にに使用できる。それ故、プロキシサーバは、全く異なる設計である異なる製造業者から装置を容易に調達することができる。
【００７５】
最後に、プロキシサーバは、データベースを、ひとつ以上のクライアントから要求される装置に関係する情報を得るために必要とされる時間を最小とする方法によって使用する。特に、時間で特徴づけられる情報は、ＡＰＩおよび通信インタフェースによって周期的にデータベースに記憶される。情報がクライアントによって要求され、アプリケーションがデータベースにアクセスするとき情報が十分に現行である場合は、情報は、ＡＰＩまたは通信インタフェースを呼び出す必要なしに、要求するクライアントに提供される。
【図面の簡単な説明】
【図１】 対応する情報要求に適合するネットワークに接続されるディジタル複写機を示す透視図である。
【図２】 多機能ネットワーク適応印刷機を示すブロック図である。
【図３】 図２に示す印刷機のためのネットワークコントローラを示すブロック図である。
【図４】 図３に示すネットワークコントローラをさらに詳細に示すブロック図である。
【図５】 複数のクライアントが、ＨＴＴＰプロキシサーバによって、複数の文書処理装置（たとえば、プリンタ）と通信できるように接続される状態を示すブロック図である。
【図６】 （Ａ）は、図５に示すルーティングインタフェースと通信インタフェースとの好適でない関係を示すブロック図であり、（Ｂ）は、図５に示すルーティングインタフェースと通信インタフェースとの好適な関係を示すブロック図である。
【図７】 種々の関数呼び出しを使用し、ひとつ以上の文書処理装置に関するオペレーションを実行する方法を示す流れ図である。
【符号の説明】
１ 文書フィーダ、２ 操作（または表示）パネル、３ 画像読み取り部、４画像形成部、５ 画像複写部、６ 出力装置、７ 用紙カセット、８ アプリケーション、９ ネットワーク接続、１２ 印刷機、１４ ネットワークサービスモジュール（電子サブシステム）、１６ ビデオ制御モジュール（電子サブシステム）、１８ スキャナ、２０ プリンタ、４４ コントローラ、７２ 標準Ｓバス、７４ ホストメモリ、７６ ＳＣＩディスク駆動装置、７８ ネットワーク、８０ ネットワークインタフェース、８２ ワークステーション、８４ エミッタまたはドライバ、１００ クライアント、１０２ コネクティビティサービス、１０４ マイクロカーネル、１０６ アプリケーション特有サブシステム、１０７ ＨＴＴＰサーバ、１０７Ａ プロキシサーバ、１０８ 文書管理サブシステム、１１０ 文書処理、１１４ エージェント、１１６ プリントサービス、１１８ ダイアグノスチックス、１２０ 電子サブシステム問い合わせユーティリティ、１２２ 走査からフィルタまでの処理、１２４ 課金／許可／認証サービス、１２８ 複写サービス、１３０ ビデオ制御モジュール待ち行列ユーティリティ、１３２ マークサービス、１３４ ユーザインタフェース、１４０ 共通ゲートウェイインタフェース、２００−１，−２，−Ｎ 文書処理装置、２０１ ＨＴＴＰサーバ、２０２ アプリケーションレイヤ、２０４ 装置データキャッシュおよび装置／ユーザインタフェース（データベース）、２０６ ルーティングインタフェース、２０８ 通信インタフェース。

Claims (2)

1. 複数のレイヤによって特徴付けられるアーキテクチャーをもったプリントサーバーを経由して、１又は複数のクライアントが複数のプリンタと通信し、
   前記複数のレイヤの１つが前記１又は複数のクライアントの１つからリクエストを受信し、
   前記リクエストが前記複数のプリンタの１つについて実行されるべき動作を指定するものである印刷システムにおいて、
   前記プリントサーバーは、
   前記複数のレイヤの１つと通信し、前記１又は複数のレイヤによって受信されるリクエストに基づいて、コマンド式を生成するアプリケーションレイヤと、
   前記複数のプリンタ中の１つである第１プリンタと通信する第１コネクティビティモジュールと、前記複数のプリンタ中の１つである第２プリンタと通信する第２コネクテビィテイモジュールと、を有する通信インタフェースと、
   前記アプリケーションレイヤ及び前記通信インタフェースの両者と通信し、前記コマンド式を前記第１及び第２コネクティビティモジュールの内で選択されたモジュールに向ける、アプリケーションプログラミングインタフェースとして機能するルーティングインタフェースと、
   を含み、
   前記第１及び第２コネクティビティモジュールの内で選択されたモジュールが、前記コマンド式を使用して、前記複数のプリンタの内の１つのプリンタに関して指定される動作の少なくとも一部を実行し、
   前記アプリケーションレイヤが生成するコマンド式は、前記アプリケーションプログラミングインタフェースに対するものであり、これによって前記アプリケーションレイヤから見て前記各プリンタへのインタフェースが同じになる、ことを特徴とする特徴とする印刷システムのプリントサーバー。
2. インタネットまたはインタネットに基づくシステムにおいて使用される印刷システムであって、
   複数のレイヤによって特徴付けられるアーキテクチャを有するサーバを経由して、１又は複数のクライアントが複数のドキュメント処理装置と通信する印刷システムにおいて、
   前記サーバーは、
   前記複数のドキュメント処理装置の１つに関する情報セットを探索する要求をもった前記１又は複数のクライアントからのリクエストを受信するＨＴＴＰサーバレイヤと、
   前記ＨＴＴＰサーバレイヤと通信し、前記ＨＴＴＰサーバにおいて受信された前記リクエストに基づいて、コマンドセットを生成するアプリケーションレイヤと、
   前記複数のドキュメント処理装置と通信する第１インタフェースのセットであって、それぞれの第１インタフェースが前記複数のドキュメント処理装置の少なくとも１つに対応している第１インタフェースセットと、
   前記アプリケーションレイヤ及び前記第１インタフェースセットの各第１インタフェースの両者と通信し、前記第１インタフェースセットの内で選択された１つに前記コマンドセットを与える、アプリケーションプログラミングインタフェースとして機能する第２インタフェースと、
   を備え、
   前記第１インタフェースセットから選択された１つの第１インタフェースが、前記コマンドセットを利用して、前記１又は複数のクライアントの内の１つによって探索される前記情報セットを取得し、
   前記アプリケーションレイヤが生成するコマンドセットは、前記アプリケーションプログラミングインタフェースに対するものであり、これによって前記アプリケーションレイヤから見て前記各ドキュメント処理装置へのインタフェースが同じになる、ことを特徴とする印刷システムのサーバー。

Images