(57)【要約】      （修正有）【課題】複数のマシン上に点在する複数のフィルターをカスケード接続したパイプラインにより印刷データを生成する際に、互いのマシンのローカル時刻の時差情報を動的に作成して時差の補正を自動的に行うクラウド印刷のデータ変換サービスを提供する。【解決手段】各フィルターは時差調査パケットで自身の時刻情報をロガーに送信する。ロガーは各フィルターから送信されるログレコードパケットと時差調査パケットとを受信するデータ受信部２と、時差調査パケットの時刻情報と時差調査パケットを受信した時刻との差分（時差）を算出する時差算出部４と、算出した時差をフィルター毎に記憶する時差情報格納部５と、記憶した時差に基づいて各フィルターから受信したログレコードパケットの時刻を補正する時刻補正部６とを備える。時刻補正部６は、全てのフィルターからのログレコードを受信した時点で、時刻の補正を行う。【選択図】図１
2016157353.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号明細書
【特許文献２】特開平9-160666号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
この時差情報定義を静的に作成するとなれば、各マシンとの通信を行い、時差を計測する処理を通信相手となるホストマシンの数だけ繰り返さなければならない。また各マシンがサマータイムなどの時期によって異なるローカル時刻が使われているならばその変更の都度（つまりサマータイムの運用切り替え時期）のたびごとに時差の計測と時差情報定義の更新を実行し続けなければならない。これはシステム管理者にとって非常に煩雑な処理となる。また、使用するマシンが動的に決定される場合には時差情報定義の手動での作成更新は実用的ではなくなる。
【００１２】
本発明では、上記課題を解決するための手段を提供する。具体的には、次の課題を解決する。
・複数のホストマシン上のプログラムから各マシンのローカル時刻を含んだデータを受信するプログラムは各マシンのローカル時刻と自マシンとの時差を補正しなければならない。
・上記複数のホストマシンは、動的に決定される。さらに各ホストマシンはそれぞれ時差を持つ。時差は地理的、政治的な要因で不定期に変動する。
【００１３】
本発明では、この課題を解決すべく、静的な時差情報を作成するのではなく動的な時差情報の作成を行い時差の補正を自動的に行うことを課題としている。
【課題を解決するための手段】
【００１４】
本発明で開示するデータ変換サービスは、フィルターが動作するホストマシンのローカル時刻を含む時差計測パケットをデータロガープロセスに送信する手段を備える。データロガープロセスは受信した時差計測パケットからフィルターの動作するホストマシンを識別する情報と時差計測パケットの送信時刻を取得し、同パケットを受信した自マシン上のローカル時刻とから2つのマシン間の時刻を算出して記憶する手段を備える。さらにデータロガープロセスは時差を算出済みのフィルターからのログデータを受信した際にはログデータに含まれている送信元ホストマシンのローカル時刻を補正して記録する手段を備える。
【発明の効果】
【００１５】
前記手段により、複数のフィルターがそれぞれ異なるホストマシン上で動作し、かつそれらの間に時差があった場合にも、時差計測を行うことで各フィルターから送信されるデータのロギングデータに含まれているローカル時刻が補正されて記録される。
【図面の簡単な説明】
【００１６】
【図１】ロガーのブロック図である。
【図２】プリントシステムおよびその利用者（印刷依頼者）の関係を示すユースケース図である。
【図３】サーバーPC上で動作するソフトウエアを説明するブロック図である。
【図４】印刷データ変換サービスとそれが依存するコンポーネント群を示す図である。
【図５】ジョブを構成する各種ファイルの構成を示す図である。
【図６】印刷データ変換サービスが動作するサーバーPCのハードウエア構成図である。
【図７】パイプライン内を移動するパケットを示す模式図である。
【図８】各コンポーネント間のパイプライン内を移動するパケットを示す模式図である。
【図９】Job Startパケットの構造を示す図である。
【図１０】時差調査パケットの構造を示す図である。
【図１１】ログレコードの構造を示す図である。
【図１２】フィルターがロガーに対してログレコードを送信する様子を示す模式図である。
【図１３】フィルターホストのイベントループの処理フローである。
【図１４】フィルターホストにおけるパイプラインからのデータ受信処理の処理フローである。
【発明を実施するための形態】
【００１７】
以下、本発明を実施するための形態を図面に基づいて説明する。
【００１８】
［実施例１］
図２は本発明の第一の実施例である印刷データ変換サービスとその依頼者から成る構成図である。ドキュメントから印刷データへの変換を依頼する依頼者（５０）は変換要求を送出する機器として、パーソナルコンピュータ（２０）、タブレット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のリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。
【００３３】
（ロガー）
ロガー（２６００）はプロセスとして同一コントロールバス（５２００）上に一つ存在する。コントロールバス（５２００）上でデータ変換処理を実行するコンポーネントがその処理状況を報告する先としてロガー（２６００）を指定する。ロガー（２６００）は受信した処理状況データ（トラフィック情報レコード）をジョブ単位のログファイルとして出力する。ログファイルの出力パス等の設定はロガー（２６００）が起動される際に渡されるコンフィギュレーションファイルで指定される。本発明はこのロガーに関するものである。ロガー（２６００）の処理および、ロガーに対して送信される処理状況データに関する詳細は後述する。
【００３４】
（印刷データ変換サービス）
図４は印刷データ変換サービス（２１００）の動作に関連するソフトウエアコンポーネント群の関連を説明する図である。印刷データ変換サービス（２１００）は先に説明したように複数のプロセスの共同体として動作している。その構成要素は印刷サービスゲートウェイ（２１１０）、プロキシーモジュール（２２００）、フィルターホスト（２４００）と各種フィルター群（２７００，２８００，２９００）となっている。ここでは説明の為に各種フィルターは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が含まれている。あるファイルの内容は複数のデータフラグメントという断片に分けられて小口のパケットの連鎖として送られる。各データフラグメントにはそのフラグメントのサイズを含んだタグパケットが先行して伝送される。
【００４５】
タグパケットにはさらにそのデータフラグメントがファイル内容の最後のフラグメントか否かを示す情報とファイルのタイプを示す情報と何番目のパケットかを示す序数も含まれている。各データフラグメントのサイズは固定的ではなく、送出時点で自由に決定される。データフラグメントは最終的にソフトウエア的にはフラグメントリーダーと呼ばれるデータ構造としてまとめられる。フラグメントリーダーには分断されて転送されてきたデータが複数その序数にしたがって連結されて保持されている。
【００４６】
（フィルター、フィルターホスト）
フィルターはライブラリーモジュールの形式で用意されている。フィルターホスト（２４００）はプロセスとして存在し、実行時に指定されたフィルターをロードする。
【００４７】
フィルターホスト（２４００）はコントロールバス（５００２）への接続とメッセージ送受信、パイプライン（３０００）の生成と接続、ジョブコントローラ（２３００）との通信、時差調査パケットのロガー（２６００）へ送信、フィルターのトラフィック情報レコードをロガー（２６００）へ送信、などの処理を担当する。
【００４８】
フィルターはフィルターホスト（２４００）が用意したパイプライン（３０００）からデータを読み出し、必要な変換処理を施した上で再びパイプライン（３０００）に書き込む処理を行う。フィルター内において前段コンポーネントからのパイプラインを特に入力パイプラインと呼び、次段コンポーネントへのパイプラインを特に出力パイプラインと呼ぶ。
【００４９】
（データフラグメント作成、取得、転送処理）
データフラグメントの作成、取得、転送処理について説明する。図１３はフィルターのホストプロセスであるフィルターホスト（２４００）における処理フローである。ジョブコントローラーがジョブを解析した時点で必要なフィルターモジュールが確定し、そのホスティングプロセスとしてロケーターによってフィルターホスト（２４００）が起動される。フィルターホスト（２４００）には起動時の引数としてロードすべきフィルターのモジュールパスが渡される。起動されたフィルターホスト（２４００）は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０３０に到達しフラグメントリーダーにフラグメントデータが連結されていくことになる。
【００５６】
これまでの説明で、各コンポーネントがどのようにしてパイプラインを形成し、さらにそのパイプライン中をどのようにデータが還流していくかを明らかにした。ここからは本発明の特徴である、フィルターの処理状況のロガーへの報告処理に関して説明する。
フィルターは入力パイプラインからのデータを処理、加工し出力パイプラインに送り出す。この処理の状況を逐次記録しておきフィルターの性能改善に役立てる試みがとられている。図１２に示すように各フィルターが出力パイプラインにデータを送り出す部分でその時刻と送出データ数の累積値をトラフィック情報レコード（以下ログレコード）としてロガー（２６００）に随時送信する。
【００５７】
ロガー（２６００）はジョブの単位で集結したログレコードをファイルに出力する。各フィルターは異なるマシン上で動作可能性があり、かつ各マシンの設定時刻は互いに時差を持つことが普通である。ところがロガー（２６００）が出力するファイルにそのような時差を含んだままのデータを記録してしまうと各フィルターでの処理遅延の状況が算出できなくなってしまう。よって以下の処理が必要となる；
各フィルターはロガーに対してパイプライン上の位置を識別できる情報を通知する。
ロガーは各フィルターのローカル時刻との差異すなわち時差を計算し、フィルターの識別情報と関連つけて記憶する。
【００５８】
各フィルターはジョブの途中で随時、処理の状況を示す情報（例えばその時点までの累積処理データ量）をローカル時刻と共にロガーに送信する。ロガーでは受信した各フィルターから送信された処理の状況を示す情報に含まれているローカル時刻を上記２で記憶してある情報に基づいて自身のローカル時刻に補正したうえでファイルに出力する。
【００５９】
本発明の実施例において上記処理１はJob Startパケットを出力パイプラインに書き込む時点で実行される。図９にJob Startパケットの構造を示す。Job StartパケットはＸＭＬ形式のテキストデータである。”JobStart”タグの下にジョブＩＤを格納した”JobID”タグとロガーのアドレスを格納した”LoggerAddr”タグと観測点を特定するための観測点ＩＤを格納した”ObservationPoint”タグから成っている。観測点が0に初期設定されプロキシーモジュールのパイプラインへの送出部に渡される。ここでは観測点ＩＤを取得し、そのＩＤに１を加えてJob Startパケットを更新する。
【００６０】
またロガー（２６００）のアドレスもこのパケットから取得する。Job Startパケットは、各フィルターがジョブＩＤで示されるジョブの開始を知る本来の目的に加え、自分の位置を観測点ＩＤとして取得することおよびロガーのアドレスを取得する目的にも利用されている。各フィルターは更新したJob Startパケットをパイプラインに送出した後、取得したロガーのアドレスに対して、図１０に示す時差調査パケットを作成して送信する。時差調査パケットにはこのパケットの送出元を示す情報とこのパケットの送出時刻とトラフィック報告点ＩＤ、パケットを作成した時刻が含まれている。ロガー（２６００）はあるジョブに関係している複数のフィルターからこの時刻調査パケットを受信する。
【００６１】
図１におけるデータ受信部（２）がこの時差調査パケットを受信すると同図の時差算出部（４）に渡される、ロガーは時刻調査パケット以外にもログレコードパケットを受信するが両パケットの判別はＸＭＬ形式のルートタグによって行う。時差調査パケットはそのパケット送出元であるホストマシンでのローカル時刻を送出時刻として含んでいるため、ロガー（２６００）ではパケットの受信時刻との差分を計算することでフィルターとの時差が算出される。算出された時差はフィルター毎に異なるため、ロガー（２６００）では図１の時差情報格納部（５）に観測点ＩＤと関連つけて記憶する。Job Startパケットがパイプラインを循環すると関係しているフィルター全てが時差調査パケットをロガーに対して送信してくるため、ロガーには当該ジョブに関係している全フィルターの時差情報が集結する。
【００６２】
Job Startパケットがパイプラインを一巡した後は、プロキシーモジュール（２２００）はジョブ定義ファイルとプリントチケット、ドキュメントを順にパイプラインに送出してくる。それらのデータがパイプライン上のフィルターに達した時点から、各フィルターは自身の処理の進行の都度ログレコード（６０００）を作製し、ロガー（２６００）に送信する。図１２はフィルターがロガーに対してログレコード（６０００）を送信する様子を示す図である。図１１はログレコード（６０００）の内容を示す図である。
【００６３】
ログレコード（６０００）はＸＭＬ形式のデータであり、その内容にはレコードの作製元であるフィルターを識別するための観測点ＩＤとログレコードの作製時刻と処理済データ量が格納されている。ロガー（２６００）では図１の時刻補正部（６）によって受信した図１１のログレコードパケットの‘Time’タグの値を取得した後、図１の時差情報格納部（５）に記憶してある、観測点ＩＤに対応した時差を適用してロガー（２６００）のローカルタイムに変換する。補正された時刻を含むログレコードは図１のログフィル出力部に送られファイルに出力される。
【符号の説明】
【００６４】
２  データ受信部、３  データ種別判定処理、４  時差算出部、５  時差情報格納部、
６  時刻補正部、７  ログフィル出力部、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  コントロールバス、
6000  ログレコード
【図１】
2016157353.tif 000003
【図２】
2016157353.tif 000004
【図３】
2016157353.tif 000005
【図４】
2016157353.tif 000006
【図５】
2016157353.tif 000007
【図６】
2016157353.tif 000008
【図７】
2016157353.tif 000009
【図８】
2016157353.tif 000010
【図９】
2016157353.tif 000011
【図１０】
2016157353.tif 000012
【図１１】
2016157353.tif 000013
【図１２】
2016157353.tif 000014
【図１３】
2016157353.tif 000015
【図１４】
2016157353.tif 000016