(57)【要約】      （修正有）【課題】後段フィルターにおける処理待ち時間を短縮する印刷システムを提供する。【解決手段】各フィルターが参照あるいは処理を予定している情報をあらかじめ宣言する。情報はその宣言に基づいてフィルター内で蓄積処理されるかあるいは次段フィルターに送出されるかの処理が成される。各フィルターにはパイプラインを流れてくる細分化されたデータ（フラグメントデータ）を取得する手段と蓄積する手段、蓄積と取り出しを制御する手段を備える。さらに取りだしを制御する手段には処理予定のデータ種別とその変更属性を宣言する手段、取得したい情報を複数種指定できる取得手段を備える。【選択図】図１
2016029758.tif 000002
【特許請求の範囲】
【請求項１】
複数のフィルター（２７００、２８００、２９００）をパイプライン（３０００）によって連結させたデータ変換装置（２１００）であって、以下の特徴を具備するデータ変換装置：
複数の設定情報と変換対象データから成る“変換ジョブ”を該データ変換装置（２１００）への入力として受け付け、設定情報と変換対象データの少なくとも一部を変換して出力する。
該設定情報および変換対象データは各々識別情報を備える。
パイプライン（３０００）は、設定情報、変換対象データおよびそれらがフィルターによって変換された情報が複数の断片に分断されたデータフラグメントを伝送する。
フィルターはパイプライン（３０００）の端点（５）から受信した情報を前記識別情報に基づいて分類して格納するデータフラグメント格納部（４）を備える。
前記パイプラインの端点（５）から受信した情報を前記データフラグメント格納部（４）に格納するか否かを決定するデータフラグメント格納制御部（２）を備える。
データフラグメント格納制御部（２）は、各フィルターが変換ジョブに含まれる設定情報および変換対象データのうち自身が処理可能なものを、識別情報によって宣言する処理可能タイプ設定手段（８）を備える。
データフラグメント格納制御部（２）はデータフラグメント格納部（４）に格納されたデータフラグメントのなかから識別情報によって特定されるデータフラグメントを取得させるデータフラグメント取得手段（９）を備える。
【請求項２】
請求項１のデータ変換装置であってさらに以下の特徴を具備するデータ変換装置：
データフラグメント格納制御部（２）は、処理可能タイプ設定手段（８）によって設定された処理可能タイプに対応していないデータフラグメントを受信した際にはそのデータフラグメントをデータフラグメント格納部（４）に格納することなく次段のフィルターに送信する。
【請求項３】
請求項２のデータ変換装置であってさらに以下の特徴を具備するデータ変換装置：
処理可能タイプ設定手段（８）は前記識別情報とともに、その情報への変更を行うか否かを示す変更属性を受け付ける。
データフラグメント格納制御部（２）は、処理可能タイプ設定手段（８）によって設定された識別情報と変更属性に基づき、以下の処理を行う。
処理可能タイプに対応していないデータフラグメントを受信した際にはそのデータフラグメントをデータフラグメント格納部（４）に格納することなく次段のフィルターに送信する。
処理可能タイプに対応してしたデータフラグメントを受信しかつ、変更属性が“変更を行う“と設定されていた際にはそのデータフラグメントをデータフラグメント格納部（４）に格納する。
処理可能タイプに対応してしたデータフラグメントを受信しかつ、変更属性が“変更を行わない“と設定されていた際にはそのデータフラグメントをデータフラグメント格納部（４）に格納するとともに、次段のフィルターに送信する。
【請求項４】
請求項３のデータ変換装置であってさらに以下の特徴を具備するデータ変換装置：
データフラグメント取得手段（９）は取得したいデータを特定する識別情報を複数指定することを可能とする。
【請求項５】
コンピュータが読出し可能な記憶媒体に記録された制御コードであり、複数のフィルターをパイプラインによって連結させたデータ変換システムであって、以下の特徴を具備するデータ変換システム：
複数の設定情報と変換対象データから成る“変換ジョブ”を概データ変換装置への入力として受け付け、設定情報と変換対象データの少なくとも一部を変換して出力する。
概設定情報および変換対象データは各々識別情報を備える。
パイプラインは、設定情報、変換対象データおよびそれらがフィルターによって変換された情報が複数の断片に分断されたフラグメントを伝送する。
フィルターはパイプラインの端点から受信した情報を前記識別情報に基づいて分類して格納するデータフラグメント格納部（４）を備える。
前記パイプラインの端点から受信した情報を前記データフラグメント格納部（４）に格納するか否かを決定するデータフラグメント格納制御部（２）を備える。
データフラグメント格納制御部（２）は、各フィルターが変換ジョブに含まれる設定情報および変換対象データのうち自身が処理可能なものを、識別情報によって宣言する処理可能タイプ設定手段を備える。
データフラグメント格納制御部（２）はデータフラグメント格納部（４）に格納されたデータフラグメントのなかから識別情報によって特定されるデータフラグメントを取得させるデータフラグメント取得手段（９）を備える。
【請求項６】
請求項５のデータ変換システムであってさらに以下の特徴を具備するデータ変換システム：
データフラグメント格納制御部（２）は、処理可能タイプ設定手段（８）によって設定された処理可能タイプに対応していないデータフラグメントを受信した際にはそのデータフラグメントをデータフラグメント格納部（４）に格納することなく次段のフィルターに送信する。
【請求項７】
請求項６のデータ変換システムであってさらに以下の特徴を具備するデータ変換システム：
処理可能タイプ設定手段は前記識別情報とともに、その情報への変更を行うか否かを示す変更属性を受け付ける。
データフラグメント格納制御部（２）は、処理可能タイプ設定手段（８）によって設定された識別情報と変更属性に基づき、以下の処理を行う。
処理可能タイプに対応していないデータフラグメントを受信した際にはそのデータフラグメントをデータフラグメント格納部（４）に格納することなく次段のフィルターに送信する。
処理可能タイプに対応してしたデータフラグメントを受信しかつ、変更属性が“変更を行う“と設定されていた際にはそのデータフラグメントをデータフラグメント格納部に格納する。
処理可能タイプに対応してしたデータフラグメントを受信しかつ、変更属性が“変更を行わない“と設定されていた際にはそのデータフラグメントをデータフラグメント格納部（４）に格納するとともに、次段のフィルターに送信する。
【請求項８】
請求項７のデータ変換システムであってさらに以下の特徴を具備するデータ変換システム：
データフラグメント取得手段（９）は取得したいデータを特定する識別情報を複数指定することを可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷装置に出力可能な形式にデータを変換するデータ変換サービスに関する。
【背景技術】
【０００２】
ユーザ端末からのリクエストによりWebサービスが印刷データを生成し、その印刷データを印刷装置で受信して処理し、印刷を実行するシステムが存在する。そのようなWebサービスの代表例は特許文献１に開示されている“cloud print service”が知られている（以下略して“CPS“と称する）。CPSは各プリンターベンダーに仕様を公開し、仕様に沿ったプリンターを開発してもらうことでサービスの急速な拡大と利用者への利便性を実現しようとするものである。特許文献１にはCPSにおけるプリンターの登録と選択、印刷データの生成に関する技術が開示されている。
【０００３】
特徴としてCPSはプリンターベンダー毎に特有のページ記述言語（PDL）やプリントデータフォーマットに従った印刷データを生成するのではなく、ベンダー非依存の統一的なフォーマットで印刷データを生成し、各プリンターにその印刷データを直接入力データとして受け取ってもらい印刷を実現する点にある。ベンダー非依存の統一的なフォーマットとしてはPortable Document Format(PDF)が挙げられている。
【０００４】
この仕様に従えば、CPSはプリンターベンダー非依存の画一的な印刷データ生成を行うことができる。サービスの利用者にとってはどのようなベンダーのプリンターであろうがCPSに準拠したプリンターであれば自分の要求する印刷がどこからでも依頼できてかつ印刷物を受け取れる利便性が得られる。
【０００５】
これまでプリンタードライバーはアプリケーションプログラムが出力するドキュメントをプリンターが理解できるPDLで記述した印刷データに変換する処理を行ってきた。加えてプリンターの特性、トナー、インク、記録紙などに応じて色味の調査や、印刷モードの選定などの処理も行っていた。ところが、プリンタードライバーはユーザ端末上で動作していた為、少なからず端末のリソースを消費する。
【０００６】
昨今、ユーザ端末はその形状をデスクトップ型PC、ノート型のPCからスレート（タブレット）型やスマートフォンまで広げている。端末形状は小型化しバッテリーの消費が大きな課題となっている。また多様化するこれらの端末のOSに追従してプリンタードライバーを提供していくことはプリンターベンダーにとっては大きな負担となっている。
【０００７】
このように、プリンタードライバーを不要とするCPSはユーザとプリンターベンダーの両者にとって一見、救世主となるように見える。しかし、実際には、プリンタードライバーが必要とされていた本質的な意義であるプリンターの機能と特性を生かしたデータ変換はやはり必要あることには変わりはない。小型化するユーザ端末とプリンタードライバーを端末上で動作させることなく今までと同じ画質、機能を提供する方策としてプリンタードライバーをクラウド上で動作させる方法が実用となっている。
【０００８】
プリンターベンダーは自社のプリンターのプリンタードライバーをWebサービスとして動作させるサービスを提供することで、文献１に示すCPSと同等の利便性とこれまでのプリンタードライバーが提供していたプリンターの特性を生かした印刷データの生成を両立させようとしている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許出願公開第2011/0299110号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１０】
印刷データの生成に限らずデータ変換サービスに求められる要求として高スループットが挙げられる。変換処理においてはキャッシュの導入、効率の良いアルゴリズムの使用、メモリ使用の促進などによって変換速度を向上させることが可能である。しかし、このような速度向上の方策を採った上でもデータ変換サービスの構成に起因した、高スループットを阻害する要因が存在している。
【００１１】
データ変換サービスは変換処理を“フィルター”と呼ばれる単機能の変換処理をパイプラインと呼ばれる通信路で複数カスケード接続した構成をとっている。この構成における利点はフィルターの数や種類を増減させることで変換処理のバリエーションが生み出せるところにある。カスケード接続という構成上、あるフィルターがデータを処理中にはそのデータの後に控えているデータは処理されずにフィルターに保持されていて順番待ち状態にある。だがもし、この未処理データが当該フィルターでは処理されないことが確定しているとしたら、未処理状態で待機させていることは時間の無駄である。
【００１２】
あるフィルターで処理しないことが確定しているデータはできるだけ早く次段のフィルターに引き渡すことが可能となれば多くのフィルターが何らかのデータを並行処理できる可能性が高くなり、高スループットが見込める。本発明では、この戦略を実現するべく、パイプラインにデータ転送に関する制御部を導入することで、既存のフィルター処理に大きな負荷を強いることなくデータ転送の効率化を達成することを課題としている。
【課題を解決するための手段】
【００１３】
本発明で開示するデータ変換サービスは、フィルター間を流れるデータをフィルターが処理対象とする単位で分割して伝送する手段を備えさせる。さらにフィルターは分割された単位のデータを互いに識別可能な状態で管理する手段を備える。さらにフィルターはデータ伝送に先立って、自身が処理を予定しているデータ種別を前記管理手段に宣言する。管理手段は宣言されなかったデータを受信したらフィルターに通知することなく次段のフィルターに対して概データを転送する手段を備える。
【発明の効果】
【００１４】
前記手段により、あるフィルターでは処理されないデータ種別が予め判明しているのでそのようなデータが到着した場合にはフィルター内に滞留させることなく次段に転送することが可能となり、後段以降のいずれかのフィルターで処理がなされるまで転送が繰り返される。すなわち、複数のフィルターが同時に異なる種類のデータをそれぞれ処理する並行処理が実現可能となる。
【図面の簡単な説明】
【００１５】
【図１】データフラグメントの格納制御部とフラグメント格納部および入出力パイプラインの関係を示す模式図である。
【図２】プリントシステムおよびその利用者（印刷依頼者）の関係を示すユースケース図である。
【図３】サーバーPC上で動作するソフトウエアを説明するブロック図である。
【図４】印刷データ変換サービスとそれが依存するコンポーネント群を示す図である。
【図５】ジョブを構成する各種ファイルの構成を示す図である。
【図６】印刷データ変換サービスが動作するサーバーPCのハードウエア構成図である。
【図７】パイプライン内を移動するパケットを示す模式図である。
【図８】各コンポーネント間のパイプライン内を移動するパケットを示す模式図である。
【図９】フィルターホストのイベントループの処理フローである。
【図１０】フラグメント格納制御部のパイプラインからのデータ受信処理の処理フローである。
【図１１】フラグメント格納制御部のフラグメント受信処理の処理フローである。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態を図面に基づいて説明する。
【００１７】
［実施例１］
図２は本発明の第一の実施例である印刷データ変換サービスとその依頼者から成る構成図である。ドキュメントから印刷データへの変換を依頼する依頼者（５０）は変換要求を送出する機器として、パーソナルコンピュータ（２０）、タブレットPC（３０）や携帯端末（４０）などの機器を利用する。依頼者（５０）はこれらの機器の内部で動作しているアプリケーション（不図示）を操作して、ネットワーク（１０）上に存在する印刷データ変換サービス（２１００）に対してドキュメントから印刷データへの変換を依頼する。印刷データ変換サービス（２１００）はサーバーPC（８０）上でWell-knownのURLを公開している、いわゆるWebサービスとして動作しているプログラムである。
【００１８】
サーバーPC（８０）上では前記URLに対して到着した依頼を印刷データ変換サービス（２１００）に転送するWebサーバー（４１００）も動作している。URLへ到着する依頼は通常多数になるため、単一のサーバーPC（８０）では処理させず、複数のサーバーPC（８０）に処理させる構成とする。従って、複数のサーバーPC（８０）の前段にロードバランサー（７０）を設置し各サーバーPC（８０）に転送される依頼が均一に配分されるように構成する。
【００１９】
印刷データ変換サービス（２１００）が提供するサービスは、依頼者（５０）が指定するデータをプリンタ（６０）で印刷できる形式に変換することである。依頼者が指定するデータにはテキストドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ（６０）が印刷データとして受け付けるデータは前述のフォーマットとは異なり、PDLで記述されたデータや、印刷部数等の印刷を制御するための命令とパラメータを備えたPJL( Print Job Language )で記述されたデータとなっている。
【００２０】
このように、依頼者（５０）とプリンタ（６０）の間には扱うデータ形式の差異が存在する為に、その差異を埋るプログラムが必要とされる。通常この変換処理を行うのがプリンタードライバーと呼ばれるプログラムである。プリンタードライバーは依頼者（５０）が操作する前述のアプリケーションプログラムが動作しているPC上で動作させることが通常である。しかし、プリンタードライバーの処理は比較的CPU、メモリなどのリソースを必要とする重い処理であるため、依頼者（５０）の操作するPCの保持するリソースが少ない場合には印刷処理が実用的でなくなる程時間のかかる処理になってしまう。
【００２１】
依頼者（５０）が操作する端末（パーソナルコンピュータ（２０）、タブレットPC（３０）や携帯端末（４０））などリソースの比較的少ない端末からの印刷の需要が高まるにつれプリンタードライバーの処理をインターネット上のサービスで行わせることの重要性が増している。
【００２２】
依頼者（５０）は前述の各種端末から前述のURLに対して印刷データをプリンタ（６０）で印刷できる形式に変換するように依頼を行う。依頼に応じてサーバーPC（８０）上で動作している印刷データ変換サービス（２１００）が生成した変換後のデータは前述の端末に対して返送される。依頼者（５０）の指示によっては変換後のデータは印刷データ変換サービス（２１００）がアクセス可能なファイルサーバーPC（９０）で保管される場合もある。
【００２３】
図６は印刷データ変換サービス（２１００）をはじめとするソフトウエア群が動作するコンピュータのハードウエア構成図である。印刷データ変換サービス（２１００）はＯＳ（オペレーティングシステム）上で動作するアプリケーションプログラムであり、ＨＤＤ（１００２）あるいはＲＯＭ（１００３）に格納されている。ＣＰＵ（１００５）がＯＳとアプリケーションプログラムをＨＤＤ（１００２）あるいはＲＯＭ（１００３）から読み出してＲＡＭ（１００４）にロードし、実行することで様々な処理が進行しプリントサービスサーバとしての機能を実現する。
【００２４】
処理結果はファイルとしてＨＤＤ（１００２）に格納され、あるいはデータとしてＲＡＭ（１００４）に記憶される。アプリケーションプログラムはコンピュータに接続されている入力装置（１００７）から使用者の入力、各種センサの読み取り値を取得する。さらに出力装置（１００６）に対して情報を出力し、処理結果を表示する。さらに、通信装置（１００８）を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアはコントロールバス（１００１）で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。
【００２５】
図３は印刷データ変換サービス（２１００）を含むソフトウエア群がサーバーPC（８０）上でどのように構成されているかを示すブロック図である。Webサーバー（４１００）は依頼者（５０）が操作したパーソナルコンピュータ（２０）上のアプリケーションからHTTPプロトコルで送信されたリクエストを受け取る。ロードバランサー（７０）はWebサーバー（４１００）の前段に位置し、複数のサーバーPC（８０）上で動作しているWebサーバー（４１００）に振り分ける。この振り分ける方式は種々知られているがその詳細は本発明には関係がないため説明を省略する。
【００２６】
ここで、サーバーPC（８０）は必ずしも物理的な一台のサーバーPCを意味する必要はない。現時点で単一のPC上に複数の仮想的なPCを出現させる仮想化技術が一般的となっており、ソフトウエアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、あるいは判別する必要がない。従って本発明におけるサーバーPC（８０）は「場合によっては仮想化されたPC」を意味する場合もある。これ以降、「PC」という表現は物理的なPCと仮想化されたPCの両方を意味するものとして扱う。
【００２７】
アプリケーションサーバー（４２００）は要求の送付先として指定されたURLを解析し、関連つけられている印刷データ変換サービス（２１００）を決定するソフトウエアである。通常Webサーバー（４１００）とアプリケーションサーバー（４２００）は複数種のサービスを扱うことが可能であり、URLから対応するサービスを特定して要求を振り分けることができる。本実施例ではその複数種のサービスの一つが印刷データ変換サービス（２１００）であることを想定している。このサービスの他にもサービスが稼働しているが発明の説明においては印刷データ変換サービス（２１００）以外のサービスは省略する。
【００２８】
印刷データ変換サービス（２１００）は単一のプロセスではなく、複数プロセスが共同して動作することでサービスを提供する形態をとっている。以下では「印刷データ変換サービス」という場合にはこれら複数のプロセスを総称していることに留意してもらいたい。ロケーター（２５００）とロガー（２６００）は印刷データ変換サービス（２１００）とは独立して存在するプロセスである。アプリケーションサーバー（４２００）は複数の要求を並列実行させるために、印刷データ変換サービス（２１００）を複数起動し、各々に要求を振り分ける。
【００２９】
この場合でも、ロケーター（２５００）とロガー（２６００）は各々一個のプロセスとして存在している。アプリケーションサーバー（４２００）はさらに、印刷データ変換サービス（２１００）が動作する際に依頼者（５０）からの一連の要求を特定する為のセッションを管理する。具体的には、同一の依頼者（５０）からの要求は同一の印刷データ変換サービス（２１００）に転送するセッション・アフィニティーを実現している。
【００３０】
（ロケーター）
印刷データ変換サービス（２１００）を構成するコンポーネント群が利用するロケータ（２５００）は特別な役割を担っている。ロケータ（２５００）はアプリケーションサーバー（４２００）が起動した時点で既に起動している特殊なプロセスである。ロケーター（２５００）の起動の方法はサーバーPC（８０）上で動作しているオペレーティングシステム（OS）によって種々の方法が存在する。例えば、Windows(登録商標）であれば”Windows Service”というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能であり、Linux(登録商標) やUnix(登録商標)ではデーモンプロセスとして動作させることが可能である。
【００３１】
ロケーター（２５００）はコンポーネントの生成の責務を担っている。さらに他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。アクセスポイントとはTCP/IPのリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。
【００３２】
（ロガー）
ロガー（２６００）はプロセスとして同一コントロールバス（５２００）上に一つ存在する。コントロールバス（５２００）上のコンポーネントはジョブの実行中にログ出力を行う。ログの出力対象としてはファイルが一般的であるが、すべてのコンポーネントが独立してログファイルの出力を行うとサーバーPC（８０）上のファイルI/Oの発生回数が増大し印刷データ変換サービス（２１００）全体のパフォーマンスが低下してしまう。そこで、各コンポーネントはログデータをロガー（２６００）に対してネットワークを介して送りつけ、ロガー（２６００）が一定量のログデータの蓄積時点でログファイルに出力することになっている。ログファイルの出力パス等の設定はロガー（２６００）が起動される際に渡されるコンフィギュレーションファイルで指定される。
【００３３】
（印刷データ変換サービス）
図４は印刷データ変換サービス（２１００）の動作に関連するソフトウエアコンポーネント群の関連を説明する図である。印刷データ変換サービス（２１００）は先に説明したように複数のプロセスの共同体として動作している。その構成要素は印刷サービスゲートウェイ（２１１０）、プロキシーモジュール（２２００）、フィルターホスト（２４００）と各種フィルター群（２７００，２８００，２９００）となっている。ここでは説明の為に各種フィルターは3種類示してあるが、実際には多くのフィルターが存在しており、さらにその組み合わせは固定化されておらず、生成される印刷データ変換サービス（２１００）毎に異なるフィルターが使用される可能性がある。
【００３４】
（印刷サービスゲートウェイ）
印刷データ変換サービス（２１００）に対するサービス依頼を受け付けるのはプロセスとして存在する印刷サービスゲートウェイ（２１１０）であり、その起動はアプリケーションサーバー（４２００）が行う。印刷サービスゲートウェイ（２１１０）はプロキシーモジュール（２２００）をロードし、Application Programming Interface(API)で提供している関数群を呼び出すことで変換処理の実行を依頼し、さらに結果を受領する。プロキシーモジュール（２２００）の提供するAPIを呼び出して印刷データ変換サービスにサービスの提供依頼を行う際には図５に示すジョブ定義ファイルを指定する。
【００３５】
（ジョブ）
変換処理はプロキシーモジュール（２２００）のAPIを通じて依頼される際に、「ジョブ定義ファイル」の形で引き渡される。ジョブ定義ファイルは変換されるべき対象データ群と、変換処理用の設定値などをまとまりのある形式に束ねた「プリントチケット」と呼ばれるファイルを関連つけた内容を持つ。このジョブ定義ファイルに記載された各種ファイルには全てその種別を判別するためのタイプ情報が付与されている。例えば、プリントチケットのタイプ情報は”ptk”というリテラルで表現される。ジョブには識別できるようにユニークな識別情報が与えられる（ジョブID）。
【００３６】
生成されたジョブはファイルとして記憶装置に格納される。また記憶装置から取り出す際にはジョブIDを指定してそのファイルを取得して内容を参照することが可能である。プリントチケットは、印刷を行わせるプリンター（６０）が処理できる印刷ファイル形式についての情報を含んでいる。さらに印刷部数や印刷の面付指示などの印刷の処理方法を指定する印刷設定も含んでいる。以降ではジョブを処理する行為を「ジョブを実行する」と呼ぶことがある。
【００３７】
（プロキシーモジュール）
印刷データ変換処理の依頼窓口として機能する。提供しているAPIを通じてサービスの依頼を受けてジョブの内容を後段のジョブコントローラー（２３００）に送信する。さらにジョブの処理結果をョブコントローラー（２３００）から受信し前記APIを通じて印刷サービスゲートウェイ（２１１０）に返却する。
【００３８】
（ジョブコントローラー）
プロキシーモジュール（２２００）を介してジョブ実行を依頼されたジョブコントローラ（２３００）はジョブ定義ファイル、プリントチケット、印刷データを解析して変換に必要なフィルターを選定する。次に、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルター群を選定する。必要なフィルターの組み合わせとその変換順番は固定的な知識としてジョブコントローラ（２３００）に実装されている。
【００３９】
必要な複数のフィルターを選定したあとはこれらフィルターをロードしているフィルターホスト（２４００）を取得する。この例では変換に必要なフィルターとして、フィルターA（２７００）、フィルターB(２８００)、フィルターC（２９００）が必要であり、それらはそれぞれフィルターホスト（２４００）にロードされている。
【００４０】
ジョブコントローラ（２３００）はフィルターA（２７００）、フィルターB(２８００)、フィルターC（２９００）との間で、パイプライン（３０００）と呼ばれるデータ転送チャネルを作成する。パイプライン（３０００）は基本的に片方向にのみデータを転送する。ジョブコントローラー（２３００）→フィルターA（２７００）→フィルターB(２８００) →フィルターC（２９００）→ジョブコントローラ（２３００）と一周するようにパイプライン（３０００）が構成される。また、ジョブコントローラ（２３００）はプロキシーモジュール（２２００）との間にもパイプライン（３０００）を作成する。
【００４１】
このようにパイプライン（３０００）を作成することで、プロキシーモジュール（２２００）から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びプロキシーモジュール（２２００）に戻ってくる。
【００４２】
（パイプライン内のデータフォーマット）
次にパプライン（３０００）を還流するデータの詳細について説明する。図５に示されるジョブ定義ファイルがプロキシーモジュール（２２００）に引き渡されたのち、その内容とジョブを構成するファイルの内容が順にパイプライン（３０００）に流される。図７はジョブを構成するファイル群とそれらの内容がどのような形式で伝送されるかを表した図である。ジョブがジョブ定義ファイルとプリントチケット、および２つのドキュメントデータから構成される例を取り上げてある。この例ではパイプライン（３０００）にはジョブの開始を示す”Job Start”パケットが最初に送信される。
【００４３】
このパケットと対応するJob Endパケットが同一のジョブに関係した最後の転送パケットとして送信される。このJob StartパケットとJob Endパケットの間に、ジョブ定義ファイル、プリントチケット、２つのドキュメントファイルの内容が伝送される。Job StartパケットとJob EndパケットにはジョブIDが含まれている。あるファイルの内容は複数のデータフラグメントという断片に分けられて小口のパケットの連鎖として送られる。各データフラグメントにはそのフラグメントのサイズを含んだタグパケットが先行して伝送される。
【００４４】
タグパケットにはさらにそのデータフラグメントがファイル内容の最後のフラグメントか否かを示す情報とファイルのタイプを示す情報と何番目のパケットかを示す序数も含まれている。各データフラグメントのサイズは固定的ではなく、送出時点で自由に決定される。データフラグメントは最終的にソフトウエア的にはフラグメントリーダーと呼ばれるデータ構造としてまとめられる。フラグメントリーダーには分断されて転送されてきたデータが複数その序数にしたがって連結されて保持されている。
【００４５】
（各コンポーネント間のパイプラインを流れるデータフォーマット）
図８は３つのフィルターが選定されパイプラインを構成した際の例を取り上げる。ジョブは２つのドキュメントを２つのFilterで変換した後Filter Cで結合した上で印刷データに変換する。即ち、各コンポーネントは以下の処理を行う：
プロキシーモジュール：ジョブに含まれる全ファイルの内容を読み出して送信
ジョブコントローラー：ジョブ定義ファイルとプリントチケットからフィルターを選定
フィルターA：ドキュメントAをドキュメントA’に変換
フィルターB：ドキュメントBをドキュメントB’に変換
フィルターC：ドキュメントA’とドキュメントB’を結合した後に印刷データに変換
上記処理と図８の各コンポーネント間を流れるデータフォーマットを照らし合わせて説明する。
【００４６】
プロキシーモジュール（２２００）からジョブコントローラー（２３００）へ伝送されるパケットはJob Startパケットに続き、ジョブ定義ファイルの内容、プリントチケットの内容、ドキュメントAの内容、ドキュメントBの内容そしてJob Endパケットの順となる。ジョブコントローラー（２３００）は受け取ったデータから処理を実行させるフィルターを選定する。選定後にはジョブ定義ファイルは不要となるためジョブコントローラー（２３００）からフィルターA（２７００）に対して送信されるデータにはジョブ定義ファイルが除かれている。
【００４７】
また、ジョブコントローラー（２３００）は受け取ったプリントチケットやドキュメントA,ドキュメントBを処理しない（変換しない）為、受け取ったそのままの順でパイプラインに送出する。フィルターA（２７００）はプリントチケットの内容を参照し、ドキュメントAを変換しドキュメントA’として出力する。その際ドキュメントBは変換しないが、後述するデータ転送機能により自動的にパイプラインに転送される。結果としてドキュメントBが変換後ドキュメントであるドキュメントA’よりも先にフィルターB(２８００)に送られる。
【００４８】
フィルターB(２８００)ではドキュメントBのみを変換してドキュメントB’として出力する為、ドキュメントA’がドキュメントB’を追い越してフィルターC（２９００）へ伝送される。ここで注目すべきは、フィルターA（２７００）でドキュメントAの変換が行われているのと同時にフィルターB(２８００)ではドキュメントBの変換が実行されているということである。従来の技術ではフィルターA（２７００）でドキュメントAの変換を完了させるまでドキュメントBは転送されずにフィルターA（２７００）内に留め置かれていた。
【００４９】
フィルターC（２９００）ではプリントチケットを参照し、２つのドキュメントを結合した上で印刷データに変換する。フィルターC（２９００）からジョブコントローラー（２３００）へ伝送されるパケットはJob Startパケットに続きプリントチケット、印刷データとJob Endパケットの順で送られる。このパケット群はプロキシーモジュール（２２００）まで伝送され、そこで印刷データがファイル化されて返却される。
【００５０】
（フィルター、フィルターホスト）
フィルターはライブラリーモジュールの形式で用意されている。フィルターホスト（２４００）はプロセスとして存在し、実行時に指定されたフィルターをロードする。
【００５１】
フィルターホスト（２４００）はコントロールバス（５００２）への接続とメッセージ送受信、パイプライン（３０００）の生成と接続、ジョブコントローラ（２３００）との通信、フィルターのログ出力のロガー（２６００）への転送などの処理を担当する。フィルターはフィルターホスト（２４００）が用意したパイプライン（３０００）からデータを読み出し、必要な変換処理を施した上で再びパイプライン（３０００）に書き込む処理を行う。フィルター内において前段コンポーネントからのパイプラインを特に入力パイプライン（５）と呼び、次段コンポーネントへのパイプラインを特に出力パイプライン（６）と呼ぶ。
【００５２】
フィルター内部の構成は図１に示すように４つの機能ブロックを含んでいる。この4つの機能ブロックが本発明の主要な部分である。入力パイプライン（５）からの入力データはある一連のデータ（例えばファイルの内容）の一部分であることが多い。つまり読み出したデータはデータフラグメント（断片）としてデータフラグメント格納部（４）に格納される。データフラグメントは種類、データ名、また何番目の断片か、この断片がファイル内容の最後かなどを示す情報と共に送信されてくる。データフラグメント格納部（４）ではデータフラグメントをタイプ別に識別して保管することができる。データフラグメント格納部（４）から種類を指定して取り出したデータフラグメントはその要素として設定ファイルの内容やドキュメントファイルの内容の断片を含んでいる。
【００５３】
データ変換処理部（１）はこの内容を読み出して変換処理を行う。データフラグメント格納部（４）に格納するデータフラグメントの選択と出力パイプライン（６）に自動的にデータフラグメントを送信する機能を提供するのがデータフラグメント格納制御部（２）である。受信したデータフラグメントの自動的な送信機能を提供するためにはデータ変換処理部から予め処理が可能なデータフラグメントの種類とアクセスのモード（読み出しのみか変更するか）を宣言してもらう必要がある。その宣言された情報を記憶しておくのが処理可能フラグメント情報格納部（３）である。
【００５４】
（データフラグメント格納制御部の働き）
データフラグメント格納部（４）はデータ変換処理部の処理速度と入力パイプラインに到着するデータの速度差を吸収し、かつ到着した順番とは独立してデータフラグメントを取り出す機能を提供している。また、データ変換処理部（１）が必要としないデータフラグメントは保管せず直ぐに出力パイプラインに転送する機能も担っている。
【００５５】
入力パイプラインからデータを受信する前に、データ変換処理部（１）は自分が参照するファイルのタイプ（種別）と変更するか読み出すだけかのアクセスモードを組にしてデータフラグメント格納制御部（２）に宣言することになっている。その宣言された情報は処理可能フラグメント情報格納部（３）に格納され、入力パイプラインからデータフラグメントを読み出す都度参照される。データ変換部が必要とするデータタイプが予めわかっているので、受信したデータフラグメントがもし必要とされていないものならばデータフラグメント格納部（４）に格納することなくそのまま出力パイプラインに転送できる。
【００５６】
さらに読み取りだけを行うと宣言しているタイプのデータフラグメントはデータフラグメント格納部に格納を行うが同時に複製して出力パイプラインに転送する。これにより必要なデータフラグメントのみがタイプ別に保管され、到着したデータフラグメントの順番とは独立して自分に都合がよい順番にデータフラグメントを取得できる。さらに、データ変換部は取得できるデータタイプが複数あり、いずれのタイプのデータでも取得して処理できる場合にはデータフラグメント格納制御部（２）に対して複数種類のデータフラグメントを指定して要求することができる。
【００５７】
（データフラグメント作成、取得、転送処理）
本発明の主要な部分であるデータフラグメントの作成、取得、転送処理について説明する。図９はフィルターのホストプロセスであるフィルターホスト（２４００）における処理フローである。ジョブコントローラーがジョブを解析した時点で必要なフィルターモジュールが確定し、そのホスティングプロセスとしてロケーターによってフィルターホスト（２４００）が起動される。フィルターホスト（２４００）には起動時の引数としてロードすべきフィルターのモジュールパスが渡される。起動されたフィルターホスト（２４００）はS００２の初期化処理を開始する。この処理内ではフィルターのロードを行い次の処理を実行する：
パイプラインの接続待ち受け処理
コントロールバス（５００２）への接続とアドバタイズ
パイプラインはTCP/IPプロトコル上の通信チャネルとして実現される。
【００５８】
各フィルターホストは前段のフィルターの出力パイプライン（６）の接続先として入力パイプライン（５）を接続待ち状態にして待機させる。このときの待ちポート番号はアドバタイズ時の情報としてコントロールバス（５００２）に流されロケーター（２５００）に記憶される。
【００５９】
その後、他のフィルターホストもほぼ同時に起動されパイプラインの接続指令がジョブコントローラー（２３００）から発行されるのを待っている。ジョブコントローラー（２３００）は起動したフィルターホスト群のパイプライン接続待ちうけポート番号をロケーター（２５００）に対する問い合わせの応答として入手する。その後、図4に示すように複数のフィルター（２７００，２８００，２９００）の連結順を勘案して、これらにパイプライン接続先アドレス、ポート番号を指定して接続命令を送出する。接続命令はコントロールバスを通じて各フィルターをホストしているフィルターホスト（２４００）に対して送信される。
【００６０】
接続命令を受け取った各フィルターホスト（２４００）は図９のパイプライン接続処理（S００３）を実行する。パイプライン接続処理（S００３）では接続先のフィルターホスト（２４００）が接続待ちを行っているTCP/IPの待ち受けポートに対して接続を行う。接続が成功するとフィルターが連鎖的に接続されたパイプラインが完成することになる。なお、説明を省略したが、パイプライン（３０００）はプロキシーモジュール（２２００）からジョブコントローラー（２３００）を経由して複数のフィルターホスト（２４００）を還流するように構成される。
【００６１】
パイプライン（３０００）が完成したあとの各フィルターホスト（２４００）は図９のパイプランからのデータ受信処理（S０２０）をデータ受信の都度呼び出す。図１０にパイプランからのデータ受信処理（S０２０）の詳細な処理フローを示す。S０２０は入力パイプライン（５）からデータを読み出し、かつその中に含まれているデータフラグメントを適切に処理することが責務となっている。一般に通信チャネルが一度に送信してくるデータのサイズは通信プロトコルスタックが内部の事情で決定したサイズとなっており、図７で説明したどのデータ要素のサイズとも合致する可能性は低い。
【００６２】
そこで、通信チャネルのデータは一旦、S０２０でストリームバッファに追記格納してからS０２２でストリームバッファの追記した端点と反対の端点から読み出すことでシリアライズを行っている。ストリームバッファ上では図８で示したJob Startパケットに続きプリントチケット、印刷データとJob Endパケットの順で送られる。S０２２ではストリームバッファ内にパケットを構成するに足りるデータサイズが含まれているかテストを行っている。もしデータが不足しているならばこれ以上処理は継続できないので処理を抜ける。
【００６３】
データが受信できているならばS０２３にてJob Startパケットが含まれているか否かが解析される。解析結果がYesならばS０２６に進み、Job Startパケットを出力パイプラインに書き込み、その後S０２２に戻り他のパケットの検索と処理を継続する。Job Startパケットは複数のフィルターがジョブの開始として認識し、そこかからジョブIDを取得して内部に保存する。S０２４ではJob Endパケットであるか否かが判定され、YesならばS０２７へ進みフィルターの内部状態を“オフライン”に遷移させる。オフライン状態は以降の入力パイプラインからの入力処理を停止させるために入力側のパイプラインを切断させる。
【００６４】
その後S０２２に戻るがバッファ内にはデータは無いはずだからそのまま処理を終了することになる。S０２５ではJob StartパケットでもJob Endパケットでもない通常のタグパケットであることがテストされる。テストでYesと判定されると図７で説明した新たなフラグメントリーダーがS０２８において作成される。この時点ではフラグメントリーダーに関係付いているデータそのものはまだストリームバッファ内に存在するので次のループでS０３０の到達しフラグメントリーダーにフラグメントデータが連結されていくことになる。
【００６５】
図１１はS０３０の詳細フローである。S０２８で作成されたフラグメントリーダーの内容からフラグメントデータのバイト数と既に受信済みバイト数が得られる。S０３１においてはそのフラグメントデータの未受信バイト数分がストリームバッファに存在しているか否かを確認する。Noの場合は必要なデータがそろっていないため更なるデータ受信が発生するまでは処理を継続できないことを意味する。従って処理を終了する。Yesの場合は現在処理中のデータフラグメントが必要なデータを伴って完成することになる。
【００６６】
S０３２において、完成するデータフラグメントがデータ変換処理部（１）によって処理可能であると宣言されていたのかどうかを処理可能フラグメント情報格納部（３）に保持されていた情報から確認する。確認の結果Noとなると、完成したフラグメントリーダーはこのフィルターにおいては不要であるとみなされるためデータフラグメント格納部（４）から取り出されS０３５において出力パイプラインに送信されて処理を終了する。S０３２においてYesと判定されると引き続きS０３３においてアクセスモードが確認される。
【００６７】
データ変換処理部（１）がこのデータフラグメントを読み取り専用でアクセスしようとしているのならばS０３４に進みフラグメントリーダーは次段のフィルターに対しても複製して送信される。この処理により、書き込みが行われないことが確定しているデータは次段にも転送され、以ってシステムの複数のフィルターが同時に同じデータを参照することが可能となる。S０３３において書き込みが行われると判断されると、当該フィルターでの処理が完了するまではこのフラグメントリーダーは次段のフィルターに対しては送信できないため処理はそのまま終了する。
【００６８】
（データ変換処理部からのデータフラグメント要求）
データフラグメント格納制御部（２）の提供する機能によってデータ変換処理部（１）は自身が処理できるドキュメント種別とそのアクセスモードを予め宣言するだけで、不要なデータフラグメントの読み出しと出力パイプラインへの転送処理が不要となる。このことはデータ変換処理部（１）の処理自体を単純化しメンテナンスの容易さ、処理の高速化の両立をもたらす。単純になったデータ変換処理部（１）では、
処理したいデータフラグメントをデータフラグメント格納制御部（２）から取得
取得したデータフラグメントに含まれている全てのデータを処理
処理したデータが変更（変換）され次段のフィルターに送信する必要があるもののみ出力パイプラインに書き込む
を繰り返せば良い。
【００６９】
しかし、フィルターによっては処理可能なドキュメントの種類が単一ではなく複数扱えるものも存在する。例えば、画像変換を行うようなフィルターでは、JPEG画像やGIF画像などのフォーマットが異なるドキュメントも内部解析して問題なく処理できるものが存在する。そのようなフィルターの場合単一のドキュメントタイプを指定して上記手順１を実行すると、そのタイプのドキュメントはパイプラインに流れてこない場合がある。フィルターはどのようなタイプのドキュメントがジョブとしてパイプラインを流れてくるのかは予め知ることができない。
【００７０】
そこで、データフラグメント格納制御部（２）がデータ変換処理部（１）に提供するデータフラグメント要求処理では複数のデータタイプを指定できるようにしてある。この要求手段により、データ変換処理部（１）は自身が処理可能なドキュメントタイプを複数指定してデータフラグメントを要求することが可能になる。一方、データフラグメント格納制御部（２）は要求に含まれる複数のドキュメントタイプのいずれかひとつがデータフラグメント格納部（４）から検索して見つけることを試みる。その結果条件にマッチするデータフラグメントが検出できた場合にはデータ変換処理部（１）を待たせることなく返却が可能になる。
【符号の説明】
【００７１】
１  データ変換処理部、２  データフラグメント格納制御部、
３  処理可能フラグメント情報格納部、４  データフラグメント格納部、
５  入力パイプライン、６  出力パイプライン、７  フィルター、
８  処理可能タイプ設定手段、９  データフラグメント取得手段、10  ネットワーク、
20  PC、30  タブレットPC、40  携帯電話、50  印刷依頼者、60  プリンター、
70  ロードバランサー、80  サーバーPC、90  ファイルサーバー、
1001  コントロールバス、1002  HDD(ハードディスクドライブ)、
1003  ROM(リードオンリーメモリ)、1004  RAM(ランダムアクセスメモリ)、
1005  CPU(セントラルプロセッシングユニット)、1006  出力装置、1007  入力装置、
1008  通信装置、2100  印刷データ変換サービス、2110  印刷サービスゲートウェイ、
2200  プロキシーモジュール、2300  ジョブコントローラー、2400  フィルターホスト、2500  ロケーター、2600  ロガー、2700  PDLFilter（Filter A）、
2800  LayoutFilter(Filter B)、2900  Filter C、3000  パイプライン、
4100  Webサーバー、4200  アプリケーションサーバー、5002  コントロールバス
【図１】
2016029758.tif 000003
【図２】
2016029758.tif 000004
【図３】
2016029758.tif 000005
【図４】
2016029758.tif 000006
【図５】
2016029758.tif 000007
【図６】
2016029758.tif 000008
【図７】
2016029758.tif 000009
【図８】
2016029758.tif 000010
【図９】
2016029758.tif 000011
【図１０】
2016029758.tif 000012
【図１１】
2016029758.tif 000013