JP2008186453A - 属性間の制約条件についてのクライアントとの通信を文書管理システムに実現させるプロトコル - Google Patents

Abstract

【課題】クライアントソフトウェアが装置に依存しない、ネットワークを介した包括的装置間通信を容易化する。
【解決手段】制御構成要素２０２と複数の処理構成要素２０４〜２０８の間の通信を容易に行えるようにするシステムは、処理構成要素２０４〜２０８と制御構成要素２０２間の通信を容易化するユニバーサルドライバ２１０であって、処理構成要素２０４〜２０８に問い合わせて、各構成要素２０４〜２０８に関連付けられた少なくとも１つの属性を受け取る問い合わせ構成要素と、１つ以上の処理構成要素それぞれについて、サポートされる属性の組み合わせと、サポートされない属性の組み合わせと、を判定する制約条件評価装置と、サポートされているか否かに少なくとも部分的に基づいて、各属性の組み合わせを分類する属性フィルタと、を含むユニバーサルドライバ２１０と、を含む。
【選択図】図２

Description

下記は、クライアント／サーバの通信プロトコルに関する。また、文書管理システムがそのクライアントに属性間の制約条件を通信できるプロトコルを用いた特定の用途を明らかにすると共に、その特定の用途を参照した説明を提供する。ただし、例示する実施形態は、他の同様の用途に適合するように修正できることも理解されたい。

一般的なネットワークは、互いに通信する複数の装置を含む。このような通信を容易化するには、１つ以上のソフトウェアコンポーネントを用いて、途切れのない情報の転送と装置の相互運用性とを実現する。このため、ネットワーク上の各装置（例えば、クライアントやサーバ等）は、ドライバ（または同様のもの）を利用して、異種の装置に特定の情報を提供していた。このようなドライバは、装置の個別タイプ（型式、製造業者等）ごとに設計する必要があった。したがって、ネットワークに新しい装置が追加されるたびに、装置固有のドライバをインストールして、新たに追加された装置がネットワークの残りの装置と通信できるようにしていた。

図１に、制御構成要素１０２が、第１処理構成要素１０４と、第２処理構成要素１０６と、第３処理構成要素１０８とのインタフェースとして機能する従来のネットワークアーキテクチャ１００を示す。このネットワーク１００において、制御構成要素１０２は、各処理構成要素とインタフェースするためのドライバを処理構成要素ごとに備える必要がある。周知のように、ドライバは、特定のタイプのコンピュータソフトウエアであり、主に、ハードウェアデバイスとの相互作用を実現するために開発されている。ドライバは、通常、ハードウェアが接続されている特定のコンピュータバスや通信サブシステムを介して装置と通信し、前記装置に対するコマンドの送付と前記装置からのデータの受信の少なくともいずれかを行うためのインタフェースを構成する一方で、通信の相手側においてはオペレーティングシステムとソフトウェアアプリケーションに対する必須のインタフェースとなる。

ドライバは、ハードウェアに依存する特殊化されたコンピュータプログラムであるが、オペレーティングシステム固有のプログラムでもあり、他のプログラム、一般に、オペレーティングシステムやアプリケーションソフトウェアパッケージが、所定の装置と透過的（transparently）に相互作用できるようにする。通常、必要とする任意の非同期時間依存ハードウェア相互作用を要求する際に求められる必須割り込み処理を提供する。各ドライバは、各処理構成要素の属性に特定的なものである。

デバイスドライバの重要な設計目標は抽象化である。ハードウェアのモデルは、（装置の同一クラス内であっても）それぞれ異なっている。より高い信頼性や性能を提供する製造業者によって新しいモデルも発売され、これら新しいモデルはしばしばこれまでとは異なった方法で制御される。すべての装置の制御方法についての認識を、コンピュータおよびそのオペレーティングシステムに期待することは、現在のところ不可能であり、また、今後期待できるようになるものでもない。この問題を解決するため、オペレーティングシステムは、基本的に、各種の装置を制御すべき方法を要求する。このため、デバイスドライバは、その機能として、ＯＳから要求されたファンクションコールを装置固有のコールに変換する役割を担う。理論上、新しい方式で制御される新しい装置は、適切なドライバを利用できれば正常に機能するものである。したがって、ドライバは、オペレーティングシステムの視点において装置が正常に動作しているように見せる働きをすることになる。

従来、属性間の制約条件は、ドライバが各装置と密接に連結されるように、クライアント側でハードコード化される。例えば、本実施形態において、各処理構成要素１０４〜１０８は、ネットワーク上にある１つ以上の異種コンポーネントとの通信を容易化する特定のドライバを持つ。このように、制御構成要素１０２は、第１ドライバ１１０と、第２ドライバ１１２と、第３ドライバ１１４と、を含む。この例において、第１ドライバ１１０は、第１処理構成要素１０４と通信するために採用され、第２ドライバ１１２は、第２処理構成要素１０６と通信するために採用され、第３ドライバ１１４は、第３処理構成要素１０８と通信するために採用される。インタフェースコンポーネント１１６は、ユーザが制御構成要素１０２と通信できるようにする。

ネットワーク上のコンポーネントそれぞれに異なるドライバを必要とすることは、煩わしいことであり、また、通信上の障害にもなる。この問題は、モデルや製造業者等が異なる複数の装置と通信するために必要な無数のプロトコルと無数の通信規格によって更に悪化する。また、オペレーションシステムが異なれば、異なるドライバが必要になる。例えば、１つのドライバについて、Ｍａｃと、Ｌｉｎｕｘと、Ｗｉｎｄｏｗｓの各種個別バージョンとに採用されているオペレーティングシステムそれぞれに対応したドライバを開発しなければならない。そこで、ウェブサービスを導入して、特定の印刷ドライバの通信に関連した問題をある程度緩和している。

ウェブサービスは、偏在する電算処理を提供するために、ベンダーと顧客の間の相互作用および協働性を提供する分散型電算処理技術である。一般に、ウェブサービスは、インターネット標準技術を介して配信される、結合力の緩いソフトウェアコンポーネントである。従来から、ウェブサービスモデルは、発行、探索、結合のパラダイムに従っている。第１段階では、サービスプロバイダが、ウェブサービスレジストリにウェブサービスを公開する。第２段階では、自分たちの要件を満たすサービスを探しているクライアントが前記レジストリ内を検索する。複数の適合物が見つかったら、その中からサービスが選択される。次に、クライアントは、その設定に基づいて１つのサービスを選択し、続いてそのサービスの記述をダウンロードしてバインドし、サービスを起動して利用する。

ＸＭＬスキーマは、ユーザが作成するＸＭＬ文書の有効性を管理する文書規則を識別するために利用できる一連の規則を生成する手段を提供する。スキーマは、種類の異なるコンピュータと種類の異なる文書の間で共有できるＸＭＬ文書の構造と、内容と、意味規則とを定義する手段を提供する。ＸＭＬスキーマの規格は、一般的なオブジェクト指向プログラミング言語で特定されるオブジェクト指向の設計原理を仕様内に記述するために設計されたものである。また、ＸＭＬは、多くのリレーショナルデータベースシステムで利用できるデータ型定義機能と同様のリッチデータ型定義サポートを提供するように設計されている。

米国特許第５，３３７，２５８号明細書 米国特許第５，４７１，５６３号明細書 米国特許第５，４７１，５６４号明細書 米国特許第７，０９２，９５０号明細書 米国特許出願公開第２００３／００５５８０６号明細書

クライアントソフトウェアが装置に依存しない、ネットワークを介した包括的装置間通信を容易化するシステムおよび方法が求められている。

一側面において、制御構成要素と、複数の処理構成要素の間の通信を容易化するシステムである。１つ以上の処理構成要素は１つ以上のタスクを実行し、各処理構成要素は、処理構成要素自身に関連付けられた少なくとも１つの属性を持つ。１つ以上の処理構成要素には、それぞれ、１つ以上の属性バンクが対応付けられ、各属性バンクは少なくとも１つの属性を格納する。制御構成要素は、各処理構成要素に対する１つ以上のタスクを起動する。ユニバーサルドライバは、前記１つ以上の処理構成要素と前記制御構成要素の間の通信を容易化する。このドライバは、前記１つ以上の処理構成要素に問い合わせを行って、各処理構成要素に対応付けられた少なくとも１つの属性を受け取る問い合わせコンポーネントを含む。制約条件評価装置は、前記１つ以上の処理構成要素ごとに、サポートされる属性の組み合わせと、サポートされない属性の組み合わせと、を決定する。属性フィルタは、サポートされているか否かに少なくとも部分的に基づいて各属性の組み合わせを分類する。

また他の側面において、制御システム内で該当する情報をユーザに提供する方法を採用する。ネットワーク内の１つ以上の装置にポーリングを行って、該装置に関連付けられた制約条件を要求する。各装置の監査を実行して制約条件を決定する。各装置から制約条件を受け取り、受け取った制約条件に少なくとも部分的に基づいて、ユーザが利用可能な属性を決定する。基準となるユーザインタフェースは、前記利用可能な属性に少なくとも部分的に基づいて修正される。

図２に、制御構成要素２０２が、ユニバーサルドライバ２１０を介して複数の処理構成要素２０４，２０６，２０８と通信するシステム２００を示す。インタフェースコンポーネント２１２を利用して、制御構成要素２０２と通信する。ユニバーサルドライバ２１０を用いて、実質的にすべての処理構成要素と通信する。これにより、単一のドライバが、ネットワーク内のシームレスな相互作用を実現できる。

制御構成要素２０２は、ネットワーク上にある１つ以上の異種コンポーネントの制御を容易にするものであれば、実質的にいかなる装置であってもよい。一例において、制御構成要素２０２はコンピュータである。このコンピュータは、処理部（図示せず）と、システムメモリ（図示せず）と、システムバス（図示せず）と、を含むことができる。システムバスは、システムコンポーネントを前記処理部に結合できる。システムコンポーネントはシステムメモリを含むが、これに限定されるものではない。処理部は、各種利用可能な任意のプロセッサであってよい。前記処理部として、デュアルマイクロプロセッサおよび他のマイクロプロセッサのアーキテクチャを採用することもできる。

システムバスは、複数のタイプのバス構造のいずれであってもよく、このバス構造は、メモリバスまたはメモリコントロラ、周辺バスまたは外部バス、および各種利用可能なバスアーキテクチャを用いたローカルバスのすべて、あるいはそのいずれかを含み、前記バスアーキテクチャは、８ビットバスと、業界標準アーキテクチャ（ＩＳＡ）と、マイクロチャネルアーキテクチャ（ＭＳＡ）と、拡張ＩＳＡ（Ｅｘｔｅｎｄｅｄ ＩＳＡ）と、インテリジェントドライブエレクトロニクス（ＩＤＥ）と、ＶＥＳＡローカルバス（ＶＬＢ）と、周辺装置相互接続（ＰＣＩ）と、ユニバーサルシリアルバス（ＵＳＢ）と、アドバンストグラフィックポート（ＡＧＰ）と、ＰＣメモリカード国際協会（ＰＣＭＣＩＡ）バスと、小型コンピュータ用周辺機器インタフェース（ＳＣＳＩ）と、を含むが、これらに限定されるものではない。

システムメモリは、揮発性メモリと不揮発性メモリとを含むことができる。基本入出力システム（ＢＩＯＳ）は、例えば、起動時などに、コンピュータ内の要素間で情報をやり取りするための基本ルーチンを含んでおり、不揮発性メモリ内に格納される。限定的なものではないが、実例を示すと、不揮発性メモリは、読取り専用メモリ（ＲＯＭ）や、プログラマブルＲＯＭ（ＰＲＯＭ）や、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）や、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）や、フラッシュメモリを含んでよい。揮発性メモリは、外部キャッシュメモリとして機能するランダムアクセスメモリ（ＲＡＭ）を含む。限定するものではないが、実例を示すと、ＲＡＭは、例えば、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）等の多くの形式で利用できる。

また、制御構成要素２０２は、取り外し可能／固定式、揮発性／不揮発性コンピュータ記憶媒体（図示せず）、例えば、ディスク記憶装置等も含んでよい。ディスク記憶装置は、磁気ディスクドライブ、フロッピーディスクドライブ、テープドライブ、ｊａｓドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのような装置を含むことができるが、これらに限定されるものではない。また、ディスク記憶装置は、単独、または他の記憶媒体と組み合わせて記憶媒体を含むことができ、この記憶媒体は、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）装置等の光ディスクドライブ、書込み可能ＣＤドライブ（ＣＤ−Ｒドライブ）、書き換え可能ＣＤドライブ（ＣＤ−ＲＷドライブ）、またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭドライブ）等を含むが、これらに限定されるものではない。ディスク記憶装置とシステムバスの接続を容易にするため、一般に、インタフェースコンポーネント２１２等の取り外し可能／固定式インタフェースが利用される。

制御構成要素２０２は、ユーザと、適切なオペレーティング環境に記述された基本コンピュータ資源との間の媒介手段として機能するソフトウェアを利用することは理解されるであろう。このようなソフトウェアは、オペレーティングシステム（図示せず）を含むことができる。オペレーティングシステムは、ディスク記憶装置に格納でき、コンピュータシステムの資源の制御と割り付けを行う機能を担う。システムアプリケーションは、システムメモリやディスク記憶装置に格納されたプログラムモジュールおよびプログラムデータを通じて、オペレーティングシステムによる資源管理を上手に活用する。対象とする実施形態は、各種のオペレーティングシステムまたはオペレーティングシステムの組み合わせを用いて実現できることを理解されたい。

ユーザは、１つ以上の入力装置（例えば、インタフェースコンポーネント２１２）から制御構成要素２０２にコマンドまたは情報を入力する。入力装置は、マウス等のポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイク、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナーカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラ等を含んでよいが、これらに限定されるものではない。前述した入力装置または他の入力装置は、１つ以上のインタフェースポート（図示せず）からシステムバスを介して処理部と連結する。インタフェースポートは、例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）を含むことができる。

一例において、インタフェースコンポーネント２１２は、ユーザに対して情報を出力するモニタである。インタフェースコンポーネント２１２はアプリケーションを表示でき、このアプリケーションを介して、ユーザは、制御構成要素２０２に接続された処理構成要素２０４〜２０８に関連するアクティビティを見ることができる。一例において、処理構成要素は印刷エンジンである。ユーザは、各印刷エンジンの状態（例えば、性能、最大出力、利用可能な資源等）を画面に表示できる。この情報を利用して、ユーザは、各種のタスク、要求、ジョブ等を１つ以上の印刷エンジンに割り当てる方法について十分な情報を得た上で当該方法を決定できる。

１つ以上の出力装置（図示せず）は、前記１つ以上の入力装置として、いくつかの同型ポートを利用できる。したがって、例えば、ＵＳＢポートを利用して、制御構成要素２０２に入力を提供したり、制御構成要素２０２から出力装置に情報を出力したりできる。出力装置の中でも、特に、特殊なアダプタを必要とするモニタ、スピーカ、プリンタのような一部の出力装置については、出力アダプタ（図示せず）を採用できる。限定するものではないが、実例を示すと、出力アダプタは、出力装置とシステムバスの接続手段を提供するビデオカードおよびサウンドカードを含むことができる。ここで、他の装置と装置のシステムの少なくとも一方は、処理構成要素２０４，２０６，２０８等のように、入力機能と出力機能の両方を提供することを注記しておく。

制御構成要素２０２は、処理構成要素２０４，２０６，２０８との論理接続を用いてネットワーク環境で動作できる。処理構成要素２０４〜２０８は、パソコン、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイス、または他の共通ネットワークノード等であってよく、通常は、制御構成要素２０２を基準として記述された多くの要素またはすべての要素を含む。

処理構成要素２０４〜２０８は、制御構成要素２０２に対して、ネットワークインタフェース（図示せず）を介して論理接続され、更に、通信接続部（図示せず）を介して物理接続される。ネットワークインタフェースは、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）等の通信ネットワークを包含できる。ＬＡＮ技術は、光ファイバ分散データインタフェース（ＦＤＤＩ）、銅線分散データインタフェース（ＣＤＤＩ）、イーサネット／ＩＥＥＥ ８０２．３、トークンリング／ＩＥＥＥ ８０２．５等を含む。ＷＡＮ技術は、二地点間リンクと、総合デジタル通信網（ＩＳＤＮ）とその変形物等の回線交換網と、パケット交換網と、デジタル加入者回線（ＤＳＬ）とを含むが、これらに限定されるものではない。

通信接続部は、ネットワークインタフェースをバスに接続するために用いられるハードウェア／ソフトウェアを意味する。通信接続部は、制御構成要素２０２の内部または外部のいずれに設けられてもよい。ネットワークインタフェースへの接続に必要なハードウェア／ソフトウェアは、その一例を示すと、通常の電話回線モデムと、ケーブルモデムと、ＤＳＬモデムとを含むモデム、ＩＳＤＮアダプタ、およびイーサネットカード等の内部技術と外部技術を含む。

ユニバーサルドライバ２１０を用いて、ネットワーク上で制御構成要素２０２と組み合わされた、ほとんどすべての装置と通信する。一例において、制御構成要素２０２は、ソフトウェアアプリケーションとしてインストールされたユニバーサルドライバを持つ。このアプリケーションは、ハードウェアが接続されている特定のコンピュータバスや通信サブシステムを介した前記装置と通信して、前記装置へのコマンドの送付と、前記装置からのデータの受信の少なくともいずれかを行うインタフェースを提供する一方で、通信の相手方については、オペレーティングシステムおよびソフトウェアアプリケーションへの必須インタフェースを提供する。

ドライバは、ハードウェアに依存する、特殊化されたコンピュータプログラムであると共に、オペレーティングシステム固有のものでもあり、他のプログラム、通常はオペレーティングシステムやアプリケーションソフトウェアパッケージが、所定の装置と透過的に対話できるようにするものである。また、ドライバは、通常、必要とする任意の非同期時間依存ハードウェア相互作用を要求する際に求められる必須割り込み処理を提供する。各ドライバは、各処理構成要素の属性に特定的なものである。

従来のドライバと異なり、ユニバーサルドライバ２１０は、前記１つ以上の処理構成要素の種類、モデル、性能、通信インタフェース等がいずれであるかに関わらず通信を可能にする複数のコンポーネントを包含できる。このような通信の基盤は、通信したい各処理構成要素に関連付けられた１つ以上の属性を識別することである。一例において、処理構成要素２０４は印刷エンジンである。この印刷エンジンは、カラー印刷および両面印刷を行うことができ、用紙供給装置を備えると共に、３種類の異なるサイズの用紙資源に印刷を行える。また、この印刷エンジンには、処理可能な資源の最大厚さが規定されている。

ユニバーサルドライバ２１０は、処理構成要素２０４に問い合わせを行い、前記処理構成要素２０４に関連付けられた属性を特定できる。このような属性を受け取ると、ユニバーサルドライバ２１０は、同時またはほぼ同時に利用できる属性はいずれであるかを決定する。例えば、両面印刷を実行でき、かつ、最大厚さの資源を印刷できることになっていても、最大厚さの資源に両面印刷を行うことはできない。このような最大厚さは、片面印刷に限定されてよい。このような例を具体的に例示したが、前述したような一緒に実行できない属性の組み合わせとしては、任意の数の組み合わせが存在することは理解されるであろう。ここに記載したような組み合わせのことを制約条件と呼ぶ。

処理構成要素２０４の制約条件が設定されると、ユニバーサルドライバは、１つ以上の属性の組み合わせに対するアクセスを制限できる。これにより、処理構成要素２０４に対する好ましからざる影響を軽減できる。例えば、１つ以上の制約条件を利用してしまうと、処理構成要素２０４は、機能停止したり、オフラインになったり、１つ以上の構造物に損傷を与えたりする。したがって、処理構成要素２０４に関連付けられた属性へのアクセスを規制することで、ユーザは、処理構成要素２０４と安全にインタフェースすることができる。

図３に、ユニバーサルドライバを利用して、制御構成要素と複数の処理構成要素の間の通信を容易化するシステムを示す。このシステムは、処理構成要素３０４、処理構成要素３０６、および処理構成要素３０８と通信する制御構成要素３０２を含む。制御構成要素３０２との通信には、インタフェースコンポーネント３１０が利用される。ここに例示する実施形態において、処理構成要素の属性は、ローカルで定義および保存されるため、制御構成要素３０２（およびその関連ソフトウェア）は、制御構成要素３０２に接続された処理構成要素３０４〜３０８とは独立して機能できる。各処理構成要素は属性バンクを含んでおり、個別には、処理構成要素３０４が属性バンク３１２、処理構成要素３０６が属性バンク３１４、そして処理構成要素３０８が属性バンク３１６を含む。

ユニバーサルドライバ３１８を採用して、制御構成要素２０２と処理構成要素３０４〜３０８の通信を容易に行えるようにする。ユニバーサルドライバ３１８は、問い合わせ装置３２０と、制約条件評価装置３２２と、属性フィルタ３２４とを含む。属性フィルタ３２４は、非サポート組み合わせ属性用バンク３２６およびサポート属性用バンク３２８に対するインタフェース機能を担う。前述したように、ユニバーサルドライバは、制御構成要素３０２と、１つ以上の処理構成要素（例えば、処理構成要素３１２〜３１６）の間の通信を可能にする。一例において、処理構成要素は印刷エンジンで、制御構成要素はコンピュータである。ユニバーサルドライバ３１８を採用することで、特定の製造業者からの装置、特定の装置タイプ、特定のモデル等、すべての装置と通信できる。このように、ユニバーサルドライバ３１８によって提供される通信インタフェース機能には各種のレベルがあってよい。

処理構成要素３０４〜３０８は、それぞれ、処理構成要素自身に関連付けられた１つ以上の属性を持つ。このような属性は、各処理構成要素の設計に付随する固有のものである。一例において、各処理構成要素の属性は、属性バンク３１２〜３１６に格納される。属性は、各処理構成要素で実行できる実質的にすべての特性、特徴、機能に関連付けることができる。一例において、属性は、走査と、印刷と、片面複写と、両面複写と、ホチキス留めと、折り畳み製本と、画像修正と、給紙と、を含む。これらの各属性は、該属性に関連付けられた機能に対する１つ以上の制限事項を持つことができる。一例において、処理構成要素３０４〜３０８は、文書管理装置である。

他の例において、印刷システムを含む文書管理装置に送信された要求（例えば、制御構成要素３０２からの要求）は、しばしばジョブと呼ばれる。これらのジョブは、最終出力がどのようなものになるかを決定する属性によって記述される。例えば、印刷ジョブはホチキス留め属性を持ち、走査ジョブはファイル格納場所属性を持つ可能性がある。場合によってはこれらの属性が競合することがあり、これは、特定の装置ではこれら２つの属性を同時に満たすことはできないことを意味する。一例は、大量の用紙資源をホチキス留めすることができない装置を利用しているときに、大量の印刷用紙資源のホチキス留めを試みることである。クライアントソフトウェアは、前述した特定の用紙資源が媒体タイプとして選択された場合に、ユーザがホチキス留めを選択できないようにするユーザインタフェースを提供することになる。したがって、これら２つの属性には制約が課せられる。

ここで説明するように、本方法を採用して、このような装置依存の制約条件を記述し、ネットワークプロトコルを介して、クライアントで消費可能なフォーマットで前記記述をクライアントに送信する。一例において、このフォーマットは、共通印刷意味規格（Common Print Semantic Specification）（ＣＰＳＳ）の一部である。ほとんどすべてのプロトコルと規格は、その両方または一方を利用して、ネットワーク３００で情報を通信できることは理解されるであろう。他の例では、ウェブサービスを用いて、制御構成要素３０２と処理構成要素３０４〜３０８の間の通信を提供する。この例において、ＸＭＬスキーマを採用し、１つ以上の受信者による消費に対応した特定のデータを挿入および伝達できる。このデータは、１つ以上のコンポーネントによってＸＭＬコードから構文解析される。

前述したように、ユニバーサルドライバ３１８は、制御構成要素３０２と処理構成要素３０４〜３０８の間の通信を容易化するために用いられる複数のコンポーネントを含む。問い合わせ装置３２０は、処理構成要素３０４〜３０８にクエリを送信して、各属性バンク３１２〜３１６からの情報を要求する。このクエリは、イベントに基づいて送信することも、定期的に送信することも、あるいは所定の時間（例えば、システムの起動時）に送ることもできる。受信した属性情報は、各処理構成要素と関連付けされる。

問い合わせ装置３２０は、処理構成要素３０４〜３０８のほとんどすべての特徴に関連する情報を受信できる。例えば、問い合わせ装置３２０は、１つ以上の機能、状態、デフォルトジョブチケット等を受け取ることができる。この情報をユニバーサルドライバ３１８で利用して、制約条件を指定できる。これにより、ユニバーサルドライバは、１つ以上のジョブチケットと１つのＰＤＬストリームの少なくともいずれかを処理構成要素３０４〜３０８に送信できる。

制約条件評価装置３２２は、サポートされる属性の組み合わせとサポートされない属性の組み合わせを判定する。既に説明したように、処理構成要素は自身に関連付けられた複数の属性を持てるが、その属性すべてを実質的に同時に利用できるとは限らない。制約条件評価装置は、予め設定された属性の組み合わせのバンクを格納できるメモリ（図示せず）を含むことができる。このような組み合わせは、特定の処理構成要素に固有であってよい。一例において、ある製造業者から出荷されたモデルは、サポートされていない属性の異なる組み合わせ１７３組と、サポートされている属性の組み合わせ４３２組を持つことができる。

代替または追加の事項として、問い合わせ装置３２０は、各処理構成要素３０４〜３０８に関する特定の情報を提供できる。この情報は、制約条件評価装置３２２に送信でき、この制約条件評価装置３２２は、人工知能コンポーネントを利用して、各処理構成要素３０４〜３０８に関連付けられた制約条件を判定できる。各処理構成要素に関連付けられた制約条件は、機械学習によって生成でき、この機械学習では、検索の望ましい結果と望ましくない結果の少なくともいずれかの例を含むデータの１つ以上のトレーニングセットを利用してシステムをトレーニングできる。対象とする実施形態の他の側面において、望ましい結果を示す１つ以上の特性に基づいて、初期条件を利用できる。識別能力を改善するため、このような初期条件は、時間の経過に応じて調整したり、戻された結果に関連するユーザ動作に応じて調整したりできる。例えば、ユーザによる利用結果を利用してシステムをトレーニングし、関連するクエリに対する望ましい結果を学習させることができる。また、特定の処理構成要素で最も多く決定される制約条件についての知識を利用して、ユーザが利用できる情報のみを公開するように、インタフェースコンポーネントを設定できる。

また、ここで用いられる「推論」という用語は、一般に、イベントとデータの少なくとも一方から捕捉される一連の観測から、システムと、環境と、ユーザのうちの少なくともいずれかの状態を判断または推測する処理を意味する。推論を用いて、特定の文脈や動作を識別することができ、また、推論は、例えば、状態についての確率分布を生成できる。推論は、確率論的、すなわち、対象とする状態に関する確率分布についてのデータとイベントの考察に基づいた計算である。推論は、イベントとデータの少なくとも一方の集合から、より高次のイベントを構成するために用いられる技術を参照できる。このような推論では、観察されたイベントと保存されたイベントデータの少なくとも一方の集合と、イベント同士が時間的に近接した相関関係にあるのかどうかと、イベントとデータは１つまたは複数いずれのイベント資源およびデータ資源に由来するものであるのかとに基づいて、新しいイベントまたは動作を構築できる。各種の分類体系および分類システム（例えば、サポートベクタマシン、神経回路網（例えば、誤差逆伝搬法、フィードフォワード誤差逆伝搬法、放射基底（radial bases）、およびファジイ論理）、エキスパートシステム、ベイジアンネットワーク、およびデータ融合）のうちの少なくとも一方は、対象とする実施形態に係る、自動動作と推論動作の両方または一方の実行に関して採用できる。

例示する実施家形態の更に他の側面では、各処理構成要素に適切な制約条件セットを予測する技法を採用できる。例えば、処理構成要素の型式、モデル、製造業者、属性等の情報と、これらのデータに関連付けられた属性とを利用して、制約条件セットを予測できる。例えば、対象とする実施形態の一側面によれば、統計と、確率と、推論と、分類器（例えば、明示的かつ暗示的にトレーニングされたもの）とに基づいた知的意思決定を採用でき、この知的意思決定は、ベイジアン学習と、ベイジアン分類器と、決定木学習方法や、サポートベクタマシンや、線形回帰や、非線形回帰や、神経回路網等の他の統計分類器と、を含む。このように、制約条件評価装置にＡＩコンポーネント（図示せず）を採用することで、特定のデータ資源（例えば、処理構成要素３０４〜３０８）に関して学習した特定のデータ消費者（例えば、処理構成要素３０２）の動作に基づいた意思決定を提供できる。

一例において、処理構成要素３０８は、両面印刷と、透明媒体または封筒媒体について特定の制約条件を持つプリンタである。この例において、プリンタは、“ｍｅｄｉ−ｃｏｌ”コレクション属性の“媒体種別（ｍｅｄｉａ ｔｙｐｅ）”メンバ属性の‘静止（ｓｔａｔｉｏｎｅｒｙ）’、‘透明（ｔｒａｎｓｐａｒｅｎｃｙ）’、および‘封筒（ｅｎｖｅｌｏｐｅ）’の値をサポートする。また、前記プリンタは、“面（ｓｉｄｅｓ）”というジョブ／文書テンプレート属性の３つの値をサポートするが、これは、両面印刷プリンタでサポートされている値である。更に、前記プリンタは、封筒および透明での両面印刷はサポートしない。これらの制約条件を通信するため、プリンタは、属性バンク３１６からユニバーサルドライバ３１８に下記の属性を返す。
sides supported = '片面（one-sided）' 長辺側で両面（two-sided-long-edge）' '短辺側で両面（tow-sided-short-edge）'
media-type-supported = '静止（stationery）' '透明（transparency）' '封筒（envelope）'
combinations-unsupported = '長辺側で両面（two-sided-long-edge）' 短辺側で両面（two-sided-short-edge）'
[ sides supported = '長辺側で両面（two-sided-long-edge）' '（短辺側で両面（two-sided-short-edge）'
media-type-supported = '透明（transparency）' '封筒（envelope）'
]
これは、次のように書き換えられる。
combinations-unsupported
[ sides supported = '長辺側で片面（two-sided-long-edge）' '短辺側で両面（two-sided-short-edge）'
media-type-supported = '透明（transparency）'
]
[ sides supported = '長辺側で両面（two-sided-long-edge）' '短辺側で片面（two-sided-short-edge）'
media-type-supported = '封筒（envelope）'
]

例示する実施形態の他の側面において、制約条件評価装置は、処理構成要素３０４〜３０８に制約条件情報を伝達できる。これにより、各処理構成要素３０４〜３０８は、所有するデフォルト値がサブミットされたジョブの属性による制約を受ける場合に、そのデフォルト値を動的に変更できる。動的デフォルト設定も、制御構成要素３０２によって処理構成要素３０４〜３０８に通信できる。動的デフォルト設定の例を下記に示す。静的デフォルトが‘長辺側で両面（ｔｗｏ-ｓｉｄｅｄ-ｌｏｎｇ-ｅｄｇｅ）’である場合、媒体種別は透明または封筒であり、静的デフォルトが両面である場合に、動的デフォルトは必然的に片面となる。プリンタは、次のような静的デフォルトと動的デフォルトを返すことになる。
media-type-default = '静止（stationery）'
sides-default = '長辺側で両面（two-sided-long-edge）'
combinations-default
[ media-type-supported = envelope, transparency
sides-default = one-sided
]

属性フィルタ３２４は、各処理構成要素３０４〜３０８に関連する制約条件情報を受け取り、１つ以上の条件に基づいて、非サポート組み合わせ属性用バンク３２６とサポート属性用バンク３２８に情報を伝達できる。例えば、１つの条件は、関連するソフトウェアアプリケーションや、制御構成要素３０２に採用されているオペレーティング環境等であってよい。属性フィルタは、２つの受信側装置に配信する構文解析データとして例示したが、条件と受信側装置とを実質的に任意の数で利用できることは理解されるであろう。

非サポート組み合わせ属性用バンク３２６は、各処理構成要素３０４〜３０８の属性のうち、サポートされない属性（例えば、制約条件）の組み合わせをすべて含む。すなわち、ユーザがこれらの組み合わせの１つ以上を利用しようとした場合、有害な影響が生じることになる。非サポート組み合わせ属性用バンク３２６（サポート属性用バンク３２８も同様）は、実質的にどのタイプのメモリであってもよい。例えば、非サポート組み合わせ属性用バンク３２６は、不揮発性メモリで構成でき、読み取り専用メモリ（ＲＯＭ）や、プログラマブルＲＯＭ（ＰＲＯＭ）や、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）や、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）や、フラッシュメモリを含むことができる。揮発性メモリは、外部キャッシュメモリとして機能するランダムアクセスメモリ（ＲＡＭ）を含む。限定するものではないが、実例を示すと、ＲＡＭは、例えば、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）等の多くの形式で利用できる。

サポート属性用バンク３２８は、処理構成要素３０４〜３０８によってサポートされる１つ以上の属性の組み合わせを含む。これらの組み合わせは制約条件ではないため、好ましくない影響を及ぼすことなく利用できる。インタフェースコンポーネント３１０は、サポート属性用バンク３２８から情報を受け取り、その情報をユーザに送信する。他の側面において、サポート属性用バンク３２８と非サポート組み合わせ属性用バンク３２６からのデータはいずれもインタフェースコンポーネント３１０に伝達できる。一例において、サポートされない属性は可視であるが、ユーザがアクセスできないように設定される。他の例において、属性はすべて可視であると共にアクセス可能に設定される。ただし、ユーザがサポートされない組み合わせを１つ以上選択した場合、制御構成要素は、ユーザからの要求を無視して、予め定義された動作を実行する。一例において、この予め定義された動作は置換動作である。他の例では、いずれの動作も実行しないことである。

図４、図５、および図６に、対象とする実施形態に係る方法４００，５００，６００を示す。説明を簡単にするため、この方法は、一連の行為として図示および説明する。対象とする実施形態は、図示された行為やその行為の順序によって制限されるものではなく、例えば、この行為は各種の順序で同時または順次に、ここで図示および言及しない他の行為と一緒に行えることは理解および認識されるであろう。また、対象とする実施形態に係る方法を実施するために、必ずしも図示されたすべての行為が要求されるものでもない。更に、本方法は、代替の選択肢として、状態図または状態イベントを用いた一連の相関状態として表現できることは、当業者であれば理解および認識されるであろう。

図４に、少なくとも１つ以上の属性に基づいてユーザインタフェースを変更する方法４００を示す。ステップ４０２において、ネットワーク内の１つ以上の装置をポーリングして、当該装置に関連付けられた１つ以上の制約条件を要求する。一例において、ポーリングは、クライアント（例えば、制御構成要素）によって開始されてよい。ステップ４０４において、ポーリング要求を受け取った各装置は、監査処理を実行して、各装置固有の制約条件を決定する。一側面において、各装置には、１組の組み合わせ属性が（例えば、ファームウェアを介して）事前設定およびプログラムされている。サポートされていない組み合わせの属性は制約条件として指定できるが、この組み合わせは各装置に固有のものである。ステップ４０６において、各装置から制約条件を受信する。

ステップ４０８において、ユーザが利用可能な属性は、前記制約条件に少なくとも部分的に基づいて決定される。一側面において、サポートされる属性の組み合わせは利用可能であると決定される。一方、サポートされない属性は利用不可能であると決定される。既に説明したように、サポートされる属性またはサポートされない属性は、実行時と、アクセス時と、開始時のうちの少なくともいずれかの時点で、装置に対する悪影響の原因となり得る組み合わせの属性に基づいて決定できる。したがって、ステップ４１０において、ユーザインタフェースは、１つ以上の利用可能な属性に少なくとも部分的に基づいて変更できる。一側面において、ユーザインタフェースの変更処理は、ユーザが利用可能な属性のみの表示を含んでよい。他の側面において、ユーザインタフェースは、属性はすべて表示されるが、サポートされる属性の組み合わせのみがアクセス可能になるように変更できる。

図５に、装置障害の条件に基づいて属性の組み合わせへのアクセスを有効化または無効化する方法を示す。ステップ５０２において、１つ以上の装置に問い合わせを行い、当該装置に関連付けられた属性を特定する。一側面において、このような問い合わせは、ＸＭＬスキーマを介したウェブサービスを用いてネットワーク上で実行できる。問い合わせは、制御構成要素、例えば、コンピュータ等によって開始されてよい。

ステップ５４０において、第１のセットとして、装置障害を引き起こすような組み合わせ属性のセットを決定する。一例において、障害は、装置の利用可能なアクティビティ／機能を制限するような任意の動作（例えば、機能停止、ジャミング、コンポーネントの損傷等）であってよい。前述の組み合わせは、装置についてのこれまでの知識と当該装置に関連付けられた１つ以上の属性とに基づいて事前に定義できる。他の側面において、装置障害を引き起こす属性の組み合わせは、人工知能コンポーネントによって決定されてよい。ステップ５０６において、前記第１のセットの組み合わせは、各装置の「非サポート」バンクに配置される。このバンクは、実質的に任意の方法で組み合わせを格納できる。例えば、組み合わせ属性は、装置の種類（例えば、プリンタ、スキャナ、ファックス等）や、モデル（Ｘ２，ＣＦＧ４，ＭＤＬ７０００等）や、製造業者等に基づいて格納されてよい。これにより、後で利用する際に前述の組み合わせを簡単に検索できるようになる。

ステップ５０８において、第２のセットとして、装置障害を引き起こさない属性のセットを決定する。既に説明したように、このような組み合わせは、事前定義されていても、あるいは各装置で属性を受信したときに決定されてもよい。ステップ５１０において、前記第２のセットの組み合わせは、各装置の「サポート」バンクに配置される。ステップ５１２において、前記第１のセットの組み合わせへのアクセスが無効化され、ステップ５１４において、前記第２のセットの組み合わせへのアクセスが有効化される。これにより、各装置に関連付けられた属性を分類でき、このような属性の組み合わせへのアクセス可能性を規制することで、１つ以上の装置のいずれについても障害を防止できる。

図６に、ウェブサービスから受け取ったデータを１つ以上の基準に基づいて分類する方法を示す。ステップ６０２において、１つ以上の装置に関連のある、１つ以上の属性が選択される。一例において、属性は、サポートされる面（ｓｉｄｅｓ−ｓｕｐｐｏｒｔｅｄ）、サポートされる媒体種別（ｍｅｄｉａ−ｔｙｐｅ−ｓｕｐｐｏｒｔｅｄ）等、１つ以上のカテゴリに関連付けることができる。カテゴリは、そのカテゴリ内にそれぞれ１つ以上のメンバ属性を持つことができる。例えば、サポートされる面（ｓｉｄｅｓ−ｓｕｐｐｏｒｔｅｄ）は、片面（ｏｎｅ−ｓｉｄｅｄ）と、長辺側で両面（ｔｗｏ−ｓｉｄｅｄ−ｌｏｎｇ−ｅｄｇｅ）と、短辺側で両面（ｔｗｏ−ｓｉｄｅｄ−ｓｈｏｒｔ−ｅｄｇｅ）等を含んでよい。これに代わる設定、あるいは追加の設定として、サポートされる媒体種別（ｍｅｄｉａ−ｔｙｐｅ−ｓｕｐｐｏｒｔｅｄ）は、静止（ｓｔａｔｉｏｎｅｒｙ）と、透明（ｔｒａｎｓｐａｒｅｎｃｙ）と、封筒（ｅｎｖｅｌｏｐｅ）と、を含むことができる。

ステップ６０４において、前記属性をネットワーク上で伝達するスキーマ設計が提供される。このようなスキーマは、ウェブサービス等のような１つ以上のプロトコルでサポートでき、拡張可能なマーク付け言語（ＸＭＬ）で記述できる。これら分散サービスは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）で送信され、かつ、ウェブサービス記述言語（ＷＳＤＬ）を用いて記述される、ＸＭＬコード化されたシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）メッセージを処理できる。また、ＩＰＰプロトコル、ＵＳＢプロトコル等を介して通信を容易化できる。

ウェブサービスを利用することは、異なる企業間での通信が可能で、異なる構造基盤上への常駐が可能なソフトウェアコンポーネント同士の相互運用を提供できる。ＷＳＤＬは、複数の開発ツールの相互運用をサポートするサービスの記述を提供できる。また、ＷＳＤＬは、インタフェース定義を交換する能力を用いて通信の相互運用性を補完できる。これらはサービス指向アーキテクチャであるので、ウェブサービスは、契約（例えば、メッセージ処理動作のためのＷＳＤＬ／ＢＰＥＬ４ＷＳ）とスキーマ（メッセージ構造についてのＷＳＤＬ／ＸＳＤ）とに基づいて情報をやりとりする。これにより、サービスは、送受信可能なメッセージの構造と、前記メッセージの順序付け制約条件と、を記述できるようになる。

ステップ６０６において、ネットワーク上の１つ以上の装置に問い合わせを行い、ウェブサービスを介して、前記スキーマに基づいたＸＭＬ文書を返す。一側面において、サービスはネットワーク装置に対してクエリを発行し、各装置に関連付けられた属性を収集する。これに代えて、あるいはこれに加えて、サービスは、製品変更と１つ以上の装置のネットワークへの導入の少なくとも一方に基づく更新情報をクライアントに提供できる。ステップ６０８において、ＸＭＬ文書から受け取ったデータが前記スキーマに基づいて構文解析される。このデータは、各装置に関する１つ以上の属性を含むことができる。追加のデータは、デフォルト設定、制約条件、可能な属性の組み合わせ等を含んでよい。データが構文解析された後、ステップ６１０において、前記データは１つ以上の基準に基づいて分類される。一例において、前記データは、サポートされている属性の組み合わせとサポートされていない属性の組み合わせに基づいて分類される。分類が完了した後、スキーマ内のデータは、障害を発生せずに複数の装置と接続するために、ユーザによって（例えば、ソフトウェアアプリケーションを用いて）利用されてよい。

複数のドライバを利用して、制御構成要素と複数の処理構成要素の間の通信を容易化する、例示する実施形態に係るシステムを示す図である。 ユニバーサルドライバを利用して、制御構成要素と複数の処理構成要素の間の通信を容易化する、例示する実施形態に係るシステムを示す図である。 ユニバーサルドライバを利用して、制御構成要素と複数の処理構成要素の間の通信を容易化する、例示する実施形態に係るシステムを示す図である。 ネットワーク上の１つ以上の装置に関連付けられた利用可能な属性に少なくとも部分的に基づいてユーザインタフェースを変更する、例示する実施形態に係る方法論を示す図である。 関連する制約条件に少なくとも部分的に基づいて、１つ以上の装置属性に対するユーザアクセスをフィルタリングする、例示する実施形態に係る方法論を示す図である。 １つ以上の基準に基づいて装置の属性データを分類する、例示する実施形態に係る方法論を示す図である。

符号の説明

１００ ネットワークアーキテクチャ、１０２ 制御構成要素、１０４ 第１処理構成要素、１０６ 第２処理構成要素、１０８ 第３処理構成要素、１１０ 第１ドライバ、１１２ 第２ドライバ、１１４ 第３ドライバ、１１６ インタフェースコンポーネント、２００ システム、２０２ 制御構成要素、２０４ 第１処理構成要素、２０６ 第２処理構成要素、２０８ 第３処理構成要素、２１０ ユニバーサルドライバ、２１２ インタフェースコンポーネント、３００ ネットワーク、３０２ 制御構成要素、３０４ 第１処理構成要素、３０６ 第２処理構成要素、３０８ 第３処理構成要素、３１０ インタフェースコンポーネント、３１２，３１４，３１６ 属性バンク、３１８ ユニバーサルドライバ、３２０ 問い合わせ装置、３２２ 制約条件評価装置、３２４ 属性フィルタ、３２６ 非サポート組み合わせ属性用バンク、３２８ サポート属性用バンク。

Claims (4)

1. 制御構成要素と複数の処理構成要素の間の通信を容易に行えるようにするシステムであって、
   １つ以上のタスクを実行すると共に、自身に関連付けられた少なくとも１つ以上の属性を持つ、１つ以上の処理構成要素と、
   前記１つ以上の処理構成要素それぞれに関連付けられた１つ以上の属性バンクであって、それぞれ少なくとも１つの属性を格納する属性バンクと、
   各処理構成要素に対する前記１つ以上のタスクを開始する制御構成要素と、
   前記１つ以上の処理構成要素と前記制御構成要素間の通信を容易化するユニバーサルドライバであって、
   前記１つ以上の処理構成要素に問い合わせて、各構成要素に関連付けられた前記少なくとも１つの属性を受け取る、問い合わせ構成要素と、
   前記１つ以上の処理構成要素それぞれについて、サポートされる属性の組み合わせと、サポートされない属性の組み合わせと、を判定する制約条件評価装置と、
   サポートされているか否かに少なくとも部分的に基づいて、各属性の組み合わせを分類する属性フィルタと、を含むユニバーサルドライバと、
   を含むシステム。
2. 少なくとも１つの処理構成要素に装置障害を発生させる、１つ以上の属性の組み合わせを格納する、サポートされない属性のバンクを更に含む、請求項１に記載のシステム。
3. 少なくとも１つの処理構成要素に装置障害を発生させない、１つ以上の属性の組み合わせを格納する、サポートされる属性のバンクを更に含む、請求項２に記載のシステム。
4. 前記制御構成要素と前記１つ以上の処理構成要素の間の通信は、ＸＭＬスキーマによって容易化される、請求項１に記載のシステム。

Images