(57)【要約】【課題】データ処理システムのパフォーマンスを安定して維持する。【解決手段】ファイルを取得するファイル取得部と、取得した前記ファイルが電気通信回線を介して接続された外部装置への外部参照を含むか否かを判定し、取得した前記ファイルが前記外部装置への外部参照を含む場合、前記外部装置への前記外部参照に基づいて、前記外部装置に保持されているデータを取得するための要求を生成する要求部と、前記要求を取得する要求取得部と、取得した前記要求に応じて前記外部装置から前記データの種類、長さの少なくともいずれか一方を示す属性情報を取得する属性情報取得部と、前記属性情報が所定の範囲に含まれるかどうかに基づいて前記データを転送対象とするか否かを判定する判定部と、転送対象と判定された前記データを前記外部装置から取得して前記要求部に送信する転送部と、前記要求部が取得した前記データに基づいて処理を実行する実行部と、を備えるデータ処理システム。【選択図】図２
2013145487.tif 000002
【特許請求の範囲】
【請求項１】
外部装置に保持されているデータを取得するための要求を要求元から取得する要求取得部と、
取得した前記要求に応じて前記外部装置から前記データの種類、長さの少なくともいずれか一方を示す属性情報を取得する属性情報取得部と、
前記属性情報が所定の範囲に含まれるかどうかに基づいて前記データを転送対象とするか否かを判定する判定部と、
転送対象と判定された前記データを前記外部装置から取得して前記要求元に送信する転送部と、
を備えるデータ転送装置。
【請求項２】
前記属性情報はＨＴＴＰのヘッダーである、
請求項１に記載のデータ転送装置。
【請求項３】
前記要求はＨＴＴＰのＧＥＴリクエストである、
請求項１または２に記載のデータ転送装置。
【請求項４】
前記判定部は少なくとも前記ヘッダーに含まれたコンテンツタイプに基づいて前記データを転送対象とするか否かを判定する、
請求項２に記載のデータ転送装置。
【請求項５】
前記判定部は前記ヘッダーに含まれたコンテンツレングスに基づいて前記データを転送対象とするか否かを判定する、
請求項３または４に記載のデータ転送装置。
【請求項６】
前記転送部は、転送対象でない前記データを取得しない、
請求項１から５のいずれか一項に記載のデータ転送装置。
【請求項７】
前記転送部は、転送対象でない前記データのかわりに所定のデータを前記要求の要求元に送信する、
請求項１から６のいずれか一項に記載のデータ転送装置。
【請求項８】
ファイルを取得するファイル取得部と、
取得した前記ファイルが電気通信回線を介して接続された外部装置への外部参照を含むか否かを判定し、取得した前記ファイルが前記外部装置への外部参照を含む場合、前記外部装置への前記外部参照に基づいて、前記外部装置に保持されているデータを取得するための要求を生成する要求部と、
前記要求を取得する要求取得部と、
取得した前記要求に応じて前記外部装置から前記データの種類、長さの少なくともいずれか一方を示す属性情報を取得する属性情報取得部と、
前記属性情報が所定の範囲に含まれるかどうかに基づいて前記データを転送対象とするか否かを判定する判定部と、
転送対象と判定された前記データを前記外部装置から取得して前記要求部に送信する転送部と、
前記要求部が取得した前記データに基づいて処理を実行する実行部と、
を備えるデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ転送装置およびデータ処理システムに関する。
【背景技術】
【０００２】
従来、ＨＴＭＬで記述されたページを表示したり印刷するためのデータ処理システムにおいて、インターネットを介して接続されている外部装置への外部参照としてコンテンツデータが埋め込まれている場合には、ＨＴＴＰのＧＥＴリクエストを用いて外部装置からのダウンロードが開始される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２６５６４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、従来のデータ処理システムでは、外部参照として埋め込まれているコンテンツデータの種類や長さに関わらず、ＨＴＴＰのＧＥＴリクエストを用いて外部装置からのダウンロードが開始されるため、データ長によってはネットワークトラフィックが過剰に増大したり、過剰に長い待機時間の後にタイムアウトが発生するという問題がある。また、ダウンロードされたコンテンツデータが悪意を持って作成されている場合には、データ処理システムに障害が発生するという問題がある。
【０００５】
本発明はこれらの問題を解決するために創作されたものであって、データ処理システムのパフォーマンスを安定して維持することを目的の１つとする。
【課題を解決するための手段】
【０００６】
（１）上記目的を達成するためのデータ転送装置は、要求元に電気通信回線を介して接続された外部装置に保持されているデータを取得するための要求を前記要求元から取得する要求取得部と、取得した前記要求に応じて前記外部装置から前記データの種類、長さの少なくともいずれか一方を示す属性情報を取得する属性情報取得部と、前記属性情報が所定の範囲に含まれるかどうかに基づいて前記データを転送対象とするか否かを判定する判定部と、転送対象と判定された前記データを前記外部装置から取得して前記要求元に送信する転送部と、を備える。
【０００７】
本発明によると、要求されたデータを外部装置から取得する前に、そのデータの属性情報を取得して、そのデータ自体を電気通信回線を介して取得するか否かを判定するため、ネットワークトラフィックが過剰に増大したり、取得したデータによって障害が発生することによってデータ処理システムのパフォーマンス（スループットやレイテンシ）が低下することを未然に防止することができる。
【０００８】
（２）上記目的を達成するためのデータ転送装置において、前記属性情報はＨＴＴＰのヘッダーであってもよい。
この構成を採用する場合、ウェブサーバーからデータを取得する前に、そのデータを実際に取得するかどうかを判定することが可能になる。
【０００９】
（３）上記目的を達成するためのデータ転送装置において、前記要求はＨＴＴＰのＧＥＴリクエストであってもよい。
この構成を採用する場合、データ転送装置を汎用的なプロキシサーバーとして実現することが可能になる。
【００１０】
（４）上記目的を達成するためのデータ転送装置において、前記判定部は少なくとも前記ヘッダーに含まれたコンテンツタイプに基づいて前記データを転送対象とするか否かを判定してもよい。
この構成を採用する場合、特定種類のデータを転送対象から除外することで、要求元の処理対象でない種類のデータを転送することによる無駄なデータ通信を未然に防止したり、悪意のあるデータの転送を未然に防止することができる。
【００１１】
（５）上記目的を達成するためのデータ転送装置において、前記ヘッダーに含まれたコンテンツレングスに基づいて前記データを転送対象とするか否かを判定してもよい。
この構成を採用する場合、あらかじめ決めた長さを超えるデータを転送対象から除外することで、過大なデータ転送によってネットワークトラフィックが過剰に増大することを未然に防止したり、過大なデータ転送によってデータ転送装置のパフォーマンスが低下することを未然に防止することができる。
【００１２】
（６）上記目的を達成するためのデータ転送装置において、前記転送部は、転送対象でない前記データを取得しないでもよい。
この構成を採用する場合、要求元の処理対象でない種類のデータを取得することによる無駄なデータ通信や、悪意のあるデータの取得や、過大なデータ取得によるネットワークトラフィックが過剰に増大することや、過大なデータ取得によってデータ転送装置のパフォーマンスが低下することを未然に防止することができる。
【００１３】
（７）上記目的を達成するためのデータ転送装置において、前記転送部は、転送対象でない前記データのかわりに所定のデータを前記要求の要求元に送信してもよい。
この構成を採用する場合、要求元に予め決めた処理を実行させるためのデータを要求元に送信することができる。
【００１４】
（８）上記目的を達成するためのデータ処理システムは、ファイルを取得するファイル取得部と、取得した前記ファイルが電気通信回線を介して接続された外部装置への外部参照を含むか否かを判定し、取得した前記ファイルが前記外部装置への外部参照を含む場合、前記外部装置への前記外部参照に基づいて、前記外部装置に保持されているデータを取得するための要求を生成する要求部と、前記要求を取得する要求取得部と、取得した前記要求に応じて前記外部装置から前記データの種類、長さの少なくともいずれか一方を示す属性情報を取得する属性情報取得部と、前記属性情報に基づいて前記データを転送対象とするか否かを判定する判定部と、転送対象と判定された前記データを前記外部装置から取得して前記要求部に送信する転送部と、前記要求部が取得した前記データに基づいて処理を実行する実行部と、を備える。
【００１５】
本発明によると、ファイルに外部参照として埋め込まれたデータに基づいて処理を実行することができる。また、コンテンツとしてのデータを外部装置から取得する前に、そのデータの属性情報を取得して、そのデータ自体を電気通信回線を介して取得するか否かを判定するため、ネットワークトラフィックが過剰に増大したり、取得したデータによって障害が発生することを未然に防止することができる。
【００１６】
また請求項に記載された各機能は、構成自体で機能が特定されるハードウェア資源、プログラムにより機能が特定されるハードウェア資源、又はそれらの組み合わせにより実現される。また、これらの機能は、各々が物理的に互いに独立したハードウェア資源で実現されるものに限定されない。さらに、本発明は方法の発明としても、コンピュータープログラムの発明としても、コンピュータープログラムの記録媒体の発明としても成立する。むろん、そのコンピュータプログラムの記録媒体は、磁気記録媒体であってもよいし光磁気記録媒体であってもよいし、今後開発されるいかなる記録媒体であってもよい。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態にかかるブロック図。
【図２】本発明の実施形態にかかるアクティビティ図。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を添付図面を参照しながら以下の順に説明する。尚、各図において対応する構成要素には同一の符号が付され、重複する説明は省略される。
【００１９】
１．実施例
図１は、本発明の実施例としての印刷データ処理システムと、印刷データ処理システムのクライアントとしての携帯電話端末３と、印刷データ処理システムによって生成される印刷データに基づいて印刷を実行するプリンター４とを示している。印刷データ処理システムは、印刷データサーバー２と、データ転送装置としてのプロキシサーバー１とを備えている。印刷データサーバー２とプロキシサーバー１と携帯電話端末３とプリンター４とは電気通信回線としてのインターネットによって接続されている。なお、印刷データサーバー２とプロキシサーバー１とを外部に対して閉じられたネットワークを介して接続し、印刷データサーバー２とインターネットとの間にプロキシサーバー１を接続してもよい。
【００２０】
印刷データサーバー２とプロキシサーバー１とによって構成された印刷データ処理システムは、携帯電話端末３等から送信された電子メールを印刷依頼として取得し、その電子メールの添付ファイルまたは本文を印刷データに変換する。添付ファイルがインターネットを介して接続された外部装置への外部参照を含むｈｔｍｌ文書などの場合、プロキシサーバー１が外部参照先からコンテンツデータを取得して印刷データサーバー２に送信する。印刷データサーバー２は、プロキシサーバー１から取得したコンテンツデータを描画しながら印刷データを生成し、あらかじめ登録されているプリンター４に送信する。その結果、プリンター４は、携帯電話端末３によって送信された印刷対象としての電子メールの添付ファイルや本文を印刷する。このため、携帯電話端末３のユーザーは、プリンター４に適合した印刷データを生成する機能を携帯電話端末３が備えていない場合であっても、印刷データサーバー２に登録されているプリンター４に印刷を実行させることができる。
【００２１】
印刷データサーバー２とプロキシサーバー１とは、それぞれ独立したコンピューターによって構成されている。すなわち、印刷データサーバー２とプロキシサーバー１は、それぞれがＣＰＵ，ＲＡＭ，ＲＯＭ，ハードディスク装置といったコンピューターの構成要素を備えている。
【００２２】
印刷データサーバー２は、ハードディスク装置に備えられた各種のコンピュータープログラムを実行することによってファイル取得部としての管理部２１、レンダリング部２２および印刷データ形成部２３として機能する。管理部２１は、登録されているプリンター４に対応付けられた電子メールアドレスが宛先に設定された電子メールを、インターネットを介して印刷依頼として取得する機能を有する。印刷データ形成部２３は、印刷依頼としての電子メールにファイルが添付されている場合、そのファイルを印刷対象として解析しながら印刷データを生成する。また印刷データ形成部２３は、印刷対象のファイルに他のコンピューターへの外部参照が含まれている場合、外部参照先に記憶されているコンテンツデータの描画をレンダリング部２２に対して要求する機能を有する。実行部としてのレンダリング部２２は、コンテンツデータの描画を要求されると、ＨＴＴＰのＧＥＴリクエストを用いてコンテンツデータを取得して描画し、画像を印刷データ形成部２３に引き渡す機能を有する。さらに管理部２１は、印刷データ形成部２３によって形成された印刷データを、印刷依頼としての電子メールの宛先に対応付けられたプリンター４に送信する機能を有する。
【００２３】
プロキシサーバー１は、ハードディスク装置に備えられた各種のコンピュータープログラムを実行することによって要求取得部１１、属性情報取得部１２、判定部１３および転送部１４として機能する。プロキシサーバー１は、プロキシサーバーとして印刷データサーバー２に設定されている。このため、印刷データサーバー２から送信されるＨＴＴＰのＧＥＴリクエストは全て要求取得部１１によって取得される。属性情報取得部１２は、印刷データサーバー２からＨＴＴＰのＧＥＴリクエストが送信されるとこれを取得し、ＨＴＴＰのＧＥＴリクエストで指定されている宛先からコンテンツデータの属性情報を取得する機能を有する。判定部１３は、コンテンツデータの属性情報に応じて当該コンテンツデータを転送対象とするか否かを判定する機能を有する。転送部１４は、転送対象であると判定されたコンテンツデータをインターネットを介して取得し、取得したコンテンツデータを印刷データサーバー２に送信する機能を有する。
【００２４】
図２は、印刷データ処理システムの作動を説明するためのアクティビティ図であって、印刷データ形成部２３がレンダリング部２２にコンテンツデータの描画を要求してから、レンダリング部２２がコンテンツデータを描画するまでの流れを示している。
【００２５】
はじめに、レンダリング部２２が印刷データ形成部２３から描画要求を取得する（Ｓ１０１）。印刷データ形成部２３からレンダリング部２２が取得する描画要求は、コンテンツデータを保持している記憶領域へのパスを含む。
【００２６】
レンダリング部２２は、描画要求を取得すると、描画要求に含まれているパスを解析し、描画要求が対象としているコンテンツデータが外部のコンピューターに保持されているか否かを判定する（Ｓ１０２）。具体的には、描画要求に含まれているパスが"http:// "などで始まるＵＲＬで記述され、印刷データサーバー２自身のコンピューター名でないホスト名をパスに含むか否かが判定される。レンダリング部２２が取得した描画要求が描画対象とするコンテンツデータが印刷データサーバー２自身によって保持されている場合、後述するステップＳ１０６の処理に移行する。
【００２７】
一方、描画要求が描画対象とするコンテンツデータが外部のコンピューターに保持されている場合、コンテンツデータを描画するためには、電気通信回線によって構成されたネットワークを介して、外部のコンピューターにコンテンツデータを要求しなければならない。そこでレンダリング部２２は、描画要求が対象としているコンテンツデータが外部のコンピューターに保持されている場合、コンテンツデータへのパスを含むＨＴＴＰのＧＥＴリクエストを生成して送信する（Ｓ１０３）。
【００２８】
プロキシサーバー１は、印刷データサーバー２のプロキシサーバーとして印刷データサーバー２に設定されているため、レンダリング部２２から送信されたＨＴＴＰのＧＥＴリクエストは、プロキシサーバー１の要求取得部１１によって取得される。すなわち、ＧＥＴリクエストの宛先（ホスト）として設定されている外部のコンピューターによって取得されるべきＧＥＴリクエストが、本実施例では、プロキシサーバー１によって謂わば横取り（インターセプト）される。
【００２９】
次にプロキシサーバー１は、取得したＧＥＴリクエストで指定されている宛先に対して、ＨＴＴＰのＨＥＡＤリクエストを送信する。その後プロキシサーバー１は、宛先のコンテンツデータの属性情報としてＨＴＴＰのヘッダーをＨＥＡＤリクエストの応答として取得する（Ｓ２０１）。ＨＥＡＤリクエストのパスには、プロキシサーバー１が取得したＧＥＴリクエストと同一のパスが設定される。したがって、このＨＥＡＤリクエストは、ＨＥＡＤリクエストの宛先、すなわち、プロキシサーバー１が取得したＧＥＴリクエストの宛先に対して、パスで特定されているコンテンツデータの種類や長さや再利用期限や最終更新日時やエンティティ情報やキャッシュ制御情報や接続状況や移動先といった属性情報を取得するためのＨＴＴＰリクエストである。したがって、ＨＥＡＤリクエストを送信すれば、コンテンツデータの本体を取得しなくても、コンテンツデータの種類や長さといった属性情報を取得することができるのである。
【００３０】
次にプロキシサーバー１は、取得したヘッダーを解析することによって、コンテンツデータのデータ長（content length）が規定範囲内にあるか否かを判定する（Ｓ２０２）。具体的には例えば１００ＭＢを越えるようなデータをプロキシサーバー１が取得して印刷データサーバー２に転送すると、プロキシサーバー１の負荷も、印刷データサーバー２の負荷も、プロキシサーバー１と印刷データサーバー２とを接続しているネットワークの負荷も増大する。そこで、コンテンツデータをホストコンピューターから取得する前に、コンテンツデータのヘッダーを解析することによって、そのコンテンツデータを転送対象とするか否かを判定するのである。
【００３１】
コンテンツデータのデータ長が規定範囲外の場合、プロキシサーバー１は、ＨＴＴＰのＧＥＴリクエストに対するエラーレスポンスを印刷データサーバー２に送信する（Ｓ１０４）。
【００３２】
コンテンツデータのデータ長が規定範囲内の場合、プロキシサーバー１は、取得したコンテンツデータのヘッダーを解析することによって、コンテンツデータの種類が規定のものであるか否かを判定する（Ｓ２０３）。具体的には例えば、悪意のある実行ファイルの転送を未然に防止するためにコンテンツタイプ（content type）が"Application"であるデータを規定外としたり、印刷データを生成不可能なファイルの転送を未然に防止するためにコンテンツタイプが"video"や"audio"であるデータを規定外種類とする。これによりＧＥＴリクエストの送信元である印刷データサーバー２の処理対象でない種類のデータを転送することによる無駄なデータ通信を未然に防止することができる。
【００３３】
ここで、ＲＦＣで規定されているコンテンツタイプは、"text"、"image"、"message"、"audio"といった"タイプ"と、"css"、"plain"、"html"、"jpeg"、"mpeg"といった"サブタイプ"とで構成されている。そこで例えばプロキシサーバー１は、コンテンツデータの"タイプ"と"サブタイプ"の両方について予め決められた種類のものであるかを判定し、少なくとも"タイプ"と"サブタイプ"の一方が予め決められた種類のものであって"タイプ"と"サブタイプ"の組み合わせが適正である場合に規定種類のものであると判定し、少なくともいずれか一方が予め決められた種類のものでない場合や、"タイプ"と"サブタイプ"の組み合わせが適正でない場合には、規定種類のものでないと判定すればよい。"タイプ"と"サブタイプ"の両方に基づいて判定することより、信頼性が低いコンテンツデータを転送することを未然に防止し、障害発生の確率を低減するすることができる。また"タイプ"と"サブタイプ"のいずれか一方が規定種類のものである場合には、コンテンツデータが規定種類であるとみなすことにより、いずれか他方がヘッダーに記述されていない場合であっても規定種類として取り扱うことが可能になる。
【００３４】
コンテンツデータの種類が規定のものでない場合、プロキシサーバー１は、ＨＴＴＰのＧＥＴリクエストに対するエラーレスポンスを印刷データサーバー２に送信する（Ｓ１０５）。
【００３５】
コンテンツデータのデータ長が規定範囲内であってコンテンツデータの種類が規定のものである場合、プロキシサーバー１は、印刷データサーバー２から取得したＧＥＴリクエストと同一のパスを設定したＧＥＴリクエストを生成して送信することによってコンテンツデータをインターネットを介して外部のホストコンピューターから取得する。続いてプロキシサーバー１は、印刷データサーバー２から取得したＨＴＴＰのＧＥＴリクエストに対するレスポンスとして、外部のホストコンピューターから取得したコンテンツデータを印刷データサーバー２に送信する（Ｓ２０４）。この結果、印刷データサーバー２から送信されたＨＴＴＰのＧＥＴリクエストのパスに保持されているコンテンツデータのデータ長が規定範囲内であって、その種類が規定種類のものである場合にのみ、印刷データサーバー２はそのコンテンツデータを取得することになる。
【００３６】
このため、プロキシサーバー１の負荷や、印刷データサーバー２の負荷や、プロキシサーバー１と印刷データサーバー２とを接続しているネットワークの負荷がコンテンツデータの転送によって過剰に増大することが防止される。また、予め決められた種類のコンテンツデータのみが印刷データサーバー２に送信されるため、悪意のあるデータによって印刷データサーバー２に障害が発生することを未然に防止できる。
【００３７】
次にレンダリング部２２は、プロキシサーバー１から取得したコンテンツデータ、印刷データサーバー２自体が保持していたコンテンツデータ、又は印刷依頼の本文や添付ファイル等を描画することによって画像を形成する（Ｓ１０６）。特にプロキシサーバー１からエラーレスポンスを受信した場合には、プロキシサーバー１から取得できなかったコンテンツデータの代わりに印刷データサーバー２自体が保持していたコンテンツデータを描画する。
【００３８】
こうしてレンダリング部２２によって形成された画像を印刷するための印刷データが印刷データ形成部２３によって形成されると、形成された印刷データがプリンター４に送信される。その結果、プリンター４によって印刷が実行される。
【００３９】
以上説明した実施例によると、印刷データサーバー２のパフォーマンス（スループットやレイテンシ）を低下させるデータを印刷データサーバー２が取得する可能性が低い。また、プロキシサーバー１のパフォーマンスを低下させるデータをプロキシサーバー１が取得する可能性も低い。したがって、印刷データ処理システムのパフォーマンスを安定して維持することができる。
【００４０】
２．他の実施形態
尚、本発明の技術的範囲は、上述した実施例に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【００４１】
例えば、転送対象とするか否かを判定する材料を提供する属性情報はＨＴＴＰのヘッダーでなくてもよく、ＨＴＴＰ以外のプロトコルで規定された属性情報であってもよい。
【００４２】
またコンテンツデータとしての画像データのデータ長が規定値を越えるときには、プロキシサーバー１は、その画像データに代えてその画像データのサムネイルをＨＴＴＰのＧＥＴリクエストを用いて取得して印刷データサーバー２に送信しても良い。
【００４３】
またプロキシサーバー１は、コンテンツデータの種類が規定種類外である場合、規定種類のデータを代わりに取得して印刷データサーバー２に送信しても良いし、規定種類外のコンテンツデータを取得して規定種類のデータに変換してから印刷データサーバー２に送信しても良い。例えば、コンテンツデータの種類が動画データである場合、そのサムネイルとしての静止画データをＨＴＴＰのＧＥＴリクエストを用いて取得して印刷データサーバー２に送信しても良い。また例えば、コンテンツデータの種類が、印刷データサーバー２が対応していないフォーマットの静止画データである場合、そのフォーマットの静止画データをそのままＨＴＴＰのＧＥＴリクエストを用いて取得してから、印刷データサーバー２が対応しているフォーマットに変換し、変換した静止画像データを印刷データサーバー２に送信しても良い。
【００４４】
またプロキシサーバー１は、コンテンツデータの種類をコンテンツタイプの"タイプ"のみ、あるいはコンテンツタイプの"サブタイプ"のみで判定しても良いし、"タイプ"と"サブタイプ"が適正に組み合わせられているか否かは判定材料にしないでも良い。
またプロキシサーバー１は、コンテンツデータのデータ長やコンテンツデータの種類の一方のみを判定材料にしてもよいし、属性情報に含まれる別の情報にも基づいて判定を行ってもよい。
【００４５】
またプロキシサーバー１は、ＨＥＡＤリクエストを送信せずに、印刷データサーバー２から取得したＧＥＴリクエストをそのまま送信することによりコンテンツデータとともに取得するヘッダーに基づいてコンテンツデータを転送対象とするか否かを判定しても良い。
【００４６】
また、印刷データサーバー２とプロキシサーバー１とが備える機能を１台のコンピューターによって実現してもよいし、印刷データ処理システム以外のデータ処理システム（例えばリレーショナルデータベースマネジメントシステム）に本発明を適用しても良い。
【符号の説明】
【００４７】
１…プロキシサーバー、２…印刷データサーバー、３…携帯電話端末、４…プリンター、１１…要求取得部、１２…属性情報取得部、１３…判定部、１４…転送部、２１…管理部、２２…レンダリング部、２３…印刷データ形成部
【図１】
2013145487.tif 000003
【図２】
2013145487.tif 000004