JP2020113930A - 画像形成装置、制御方法、およびプログラム - Google Patents

Abstract

【課題】スキャン送信処理を拡張アプリケーションが実行しなくてもよい画像形成装置を提供すること。【解決手段】 アプリケーションを実行可能な画像形成装置は、原稿を読み取る読取部を制御し、画像データを生成し、アプリケーションから、送信ファイルおよび送信先を一括で指定するための動的なフォーマット情報を含むコマンドを受け付け、動的なフォーマット情報を含むコマンドに基づいて、送信ファイルおよび送信先を指定する情報を生成し、生成した送信先に、送信ファイルとして画像データを送出する。【選択図】 図１０

Description

本発明は、画像形成装置、制御方法、およびプログラムに関する。

特許文献１には、クライアントコンピュータからサーバまたはクラウドサービスへ、クライアントコンピュータがスキャンして生成した画像データを送信する技術が開示されている。このような技術では、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を介してファイルを送信する場合がある。

このような、ＨＴＴＰを介してスキャン画像を送信する技術において、画像形成装置を以下のように構成することが知られている（以下、公知技術と称する）。まず、拡張アプリケーションは、原稿のスキャンをファームウェアに指示する。指示を受けたファームウェアは、その指示に基づいて原稿をスキャンして画像データを生成し、そのデータを共有ストレージに格納する。拡張アプリケーションは、共有ストレージに格納されたデータを読み出し、そのデータに対して送信に必要なＨＴＴＰヘッダ等の情報を付加しながらクラウドサービスにＨＴＴＰプロトコルで送信する。これによって、拡張アプリケーションが送信先のサーバに応じてＨＴＴＰヘッダやＨＴＴＰボディを生成することができる。

米国特許９０３５９５８号明細書

ここで、比較的安価な画像形成装置では、コストの制約から拡張アプリケーションを動作させるために割り当てることができるメモリの容量を少なくしなければならない場合が多い。このような場合、一度に１つのみの拡張アプリケーションが実行されるよう制限されることもある。このような制限がある場合、公知技術のように、スキャン送信処理を拡張アプリケーションが受け持ってしまうと、ＨＴＴＰを介した送信が完了するまで、別のアプリケーションを実行することができない。スキャン送信する原稿の枚数や通信環境によっては、ＨＴＴＰを介した送信は何分にも及ぶことがあり、これを鑑みると、拡張アプリケーションは送信処理の実行を受け持たず、ファームウェアが送信処理を受け持つことが望ましい。

しかしながら、ＨＴＴＰを介して任意のサーバに画像データを送信する場合、拡張アプリケーションが送信先のサーバの情報と認証に必要な情報だけを静的なフォーマットでファームウェアへ指示しても、ＨＴＴＰ送信が確立できない場合がある。これは、サーバが提供しているサービスや、画像形成装置が送信する画像データによって、ＨＴＴＰ送信を確立するために必要な情報が異なりうるためである。

本発明の目的は、上述の課題に鑑みてなされたものであり、スキャン送信処理を拡張アプリケーションが実行しなくてもよい画像形成装置を提供することを目的とする。

上記目的を達成するために、本発明の画像形成装置は、アプリケーションを実行可能な画像形成装置であって、原稿を読み取る読取部を制御し、画像データを生成する読取手段と、前記アプリケーションから、送信ファイルおよび送信先を一括で指定するための動的なフォーマット情報を含むコマンドを受け付ける受付手段と、前記動的なフォーマット情報を含む前記コマンドに基づいて、送信ファイルおよび送信先を指定する情報を生成する生成手段と、生成した前記送信先に、前記送信ファイルとして前記画像データを送出する送出手段と、を備える。

本発明によれば、スキャン送信処理を拡張アプリケーションが実行しなくてもよい画像形成装置を提供することができる。

第１実施形態に係るＭＦＰのハードウェア構成を示すブロック図。 第１実施形態に係るＭＦＰのソフトウェア構成を示すブロック図。 第１実施形態に係る画像形成装置の利用環境の一例を示す図。 第１実施形態に係るホーム画面の一例を示す図。 第１実施形態に係る分割送信処理を要求するコマンドの一例を示す図。 第１実施形態に係る一括送信処理を要求するコマンドの一例を示す図。 第１実施形態に係る分割送信処理において送信されるＨＴＴＰメッセージの一例を示す図。 第１実施形態に係る一括送信処理において送信されるＨＴＴＰメッセージの一例を示す図。 第１実施形態に係るＨＴＴＰ送信処理の流れを示すフローチャート。 第１実施形態に係る分割送信処理の詳細を示すフローチャート。 第１実施形態に係る一括送信処理の詳細を示すフローチャート。 第１実施形態に係るクラウド送信処理の流れを示すフローチャート。 第１実施形態に係るクラウドボタン処理の流れを示すフローチャート。 第２実施形態に係るマルチパート送信処理を要求するコマンドの一例を示す図。 第２実施形態に係るマルチパート送信処理において送信されるＨＴＴＰメッセージの一例を示す図。 第２実施形態に係るＨＴＴＰ送信処理の流れを示すフローチャート。 第２実施形態に係るマルチパート送信処理の詳細を示すフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１実施形態＞
図３は、本実施形態に係る画像形成装置（ＭＦＰ）の利用環境の一例を示す概略図である。ＭＦＰ１０は、有線または無線ネットワークを介して、インターネットに接続し、クラウドＡ２１やクラウドＢ２２といったサイトにアクセスすることができる。そして、後述するように、ＭＦＰ１０のスキャナで原稿を読み取って画像データを生成し、それぞれのサイトで定められたプロトコルに従って、画像データをクラウドＡ２１やクラウドＢ２２に送信することができる。

図１は、本実施形態に係るＭＦＰ１０のハードウェア構成を示すブロック図である。ＭＦＰ１０は、ＣＰＵ１０１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３、表示コントローラ１０４、表示部１０５、操作コントローラ１０６、および操作部１０７を備える。また、ＭＦＰ１０は、ｅＭＭＣ（ｅｍｂｅｄｄｅｄ Ｍｕｌｔｉ Ｍｅｄｉａ Ｃａｒｄ）ホストコントローラ１０８、ｅＭＭＣ１０９、読取コントローラ１１０、読取部１１１、記録コントローラ１１２、記録部１１３を備える。さらに、ＭＦＰ１０は、ＵＳＢホストコントローラ１１４、モデム１１５、網制御ユニット（ＮＣＵ）１１６、ネットワークインタフェースカード（ＮＩＣ）１１７を備えている。

ＣＰＵ１０１は、システムバス１１８に接続される各デバイスを総括的に制御する。ＣＰＵ１０１は、電源が供給されると、ＲＯＭ１０２に記憶されたブートプログラムを実行する。通常、ブートプログラムを実行したＣＰＵ１０１は、ｅＭＭＣ１０９の特定領域に保存されているメインプログラムをＲＡＭ１０３にロードし、ロードされたメインプログラムの先頭にジャンプしてメインプログラムを実行する。ＲＡＭ１０３は、メインプログラムのロード場所としてだけでなく、メインプログラムが動作するためのワークエリアなどとしても機能する。ＣＰＵ１０１は、後述する図９から図１３、図１６、および、図１７の各制御プログラムを実行することにより、例えば図７、図８、または図１５などの情報を生成する。

表示コントローラ１０４は、表示部１０５に描画される画面を制御する。表示部１０５は液晶ディスプレイ（ＬＣＤ）や有機エレクトロルミネッセンス（ＯＬＥＤ）ディスプレイなどのディスプレイであり、本実施形態ではＷＶＧＡサイズのフルビットマップＬＣＤであるものとして説明を行う。操作コントローラ１０６は、操作部１０７からの入力を制御する。操作部１０７は、表示部１０５と一体に形成されたタッチパネルやプッシュボタンからなるユーザインタフェース（ＵＩ）である。

読取部１１１は、原稿を読み取る。読取部１１１は、ガラス面と原稿を抑える圧板を備え、原稿を１枚ずつ読み取ることができる。また、読取部１１１にはオートドキュメントフィーダ（ＡＤＦ）が装着されており、複数枚の原稿を自動的に順次読み取ることもできる。なお、以下、ガラス面での原稿の読み取りを圧板スキャン、ＡＤＦでの原稿の読み取りをＡＤＦスキャンと呼ぶ。読取部１１１は読取コントローラ１１０に接続されており、ＣＰＵ１０１は読取コントローラ１１０を介して読取部１１１を制御することができる。

また、記録部１１３は、電子写真方式で記録紙に画像形成を行うプリンタユニットである。記録部１１３は記録コントローラ１１２に接続されており、ＣＰＵ１０１は記録コントローラ１１２を介して記録部１１３とやり取りする。

ＵＳＢホストコントローラ１１４は、ＵＳＢのプロトコル制御を受け持ち、ＵＳＢフラッシュメモリ（不図示）などの、ＵＳＢホストコントローラ１１４に接続されたＵＳＢデバイスに対するアクセスを仲介する。

モデム１１５は、ファクシミリ通信に必要な信号の変復調を行う。モデム１１５はＮＣＵ１１６に接続され、モデム１１５で変調された信号は、ＮＣＵ１１６を介して公衆回線網（ＰＳＴＮ）へ送出される。

ＮＩＣ１１７は、ＬＡＮを介して、メールやファイルのサーバなどと双方向にデータのやり取りを行う。また、Ｗｅｂサーバなどとも双方向にデータをやり取りする。

本実施形態のＭＦＰ１０は、ストレージとしてｅＭＭＣ１０９を備える。ＣＰＵ１０１は、ｅＭＭＣホストコントローラ１０８を介してｅＭＭＣ１０９にアクセスする。

次に、図２を参照して本実施形態に係るＭＦＰ１０のソフトウェア構成を説明する。図２において実線で示した各部は、ＣＰＵ１０１が前述したブートプログラムでＲＡＭ１０３にロードされたメインプログラムを実行することにより実現されるソフトウェアモジュールである。破線で示した各部は、図１を参照して説明したハードウェアまたは当該ハードウェアとデバイスドライバ２０８との通信線である。

メインプログラムは、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２０１によって後述するそれぞれのモジュールの実行を管理・制御する。ＯＳ２０１は、デバイスドライバ２０８を有する。デバイスドライバ２０８は、表示コントローラ１０４、操作コントローラ１０６、および読取コントローラ１１０の少なくとも何れかといったハードウェアデバイスとのやり取りを仲介する。

ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部２０２は、表示部１０５および操作部１０７を介して各種情報をユーザに提供するとともに、ユーザからの各種指示を受け付ける。ＭＦＰ１０の振る舞いを切り替える各種設定も、ＵＩ部２０２によって変更することができる。ＵＩ部２０２によって変更された各種設定は、データベース２１３を介して物理的にｅＭＭＣ１０９へ格納される。ＵＩ部２０２によって変更される表示言語の設定も各種設定のひとつである。

ジョブコントローラ２０３は、コピーやプリント、ファックスなどのジョブを受け付け、受け付けたジョブの実行を制御する。

ストレージ２０６は、例えばスキャン部２０７が受信した画像データや拡張アプリケーション２１０から要求されたアプリケーション設定などのデータを、物理的にｅＭＭＣ１０９へ格納して管理するソフトウェアモジュールである。例えば、本実施形態に係るＭＦＰ１０において、ジョブコントローラ２０３がＳＭＢ送信ジョブを受け付けると、スキャン部２０７はそのジョブ要求を受けて読取部１１１を制御して原稿をスキャンする。そして、スキャンした画像データをストレージ２０６へ格納する。ストレージ２０６に格納された画像データは送信部２０５によって読み出され、ＮＩＣ１１７を介してＳＭＢファイルサーバに送信される。

本実施形態のＭＦＰ１０では、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）／ＦＷ（Ｆｒａｍｅｗｏｒｋ）部２０９を備える。拡張アプリケーション２１０は、物理的にはｅＭＭＣ１０９上に配置され、スクリプト言語で記述された任意のプログラム等から複数のアプリケーションを収容する。例えば、バイトコードを解釈して実行するインタープリタであるＪＡＶＡ（登録商標）や、ＬＵＡなどのプログラム言語を用いてもよい。ＶＭ／ＦＷ部２０９は、スクリプト言語や所定の高級言語で記述された任意のプログラムを拡張アプリケーション２１０へインストールする、あるいは、拡張アプリケーション２１０からアンインストールする役割を受け持つ。同時に、インストールされたアプリケーションが有効であるか無効であるかを含むアプリケーションのステータス情報を、ストレージ２０６上に保持する。ＲＯＭ１０２上に複数のプレインストールアプリケーションを圧縮したアーカイブが存在すれば、それを必要に応じて展開しながら拡張アプリケーション２１０にインストールする能力も備える。

また、ＶＭ／ＦＷ部２０９は、拡張アプリケーション２１０にインストールされた任意のプログラムで実現される機能と既存機能との調停等も受け持つ。そして、ＶＭ／ＦＷ部２０９は、表示部１０５に表示されたボタンのユーザ選択を受けて、対応するアプリケーションのスクリプト言語をＲＡＭ１０３上にロードしながら、内容を解釈して実行可能である。これによって、本実施形態のＭＦＰ１０は、スキャンアプリケーション２１４のような任意の付加的な機能を容易に実現することができる。さらに、ＶＭ／ＦＷ部２０９は、拡張アプリケーション２１０にインストールされたアプリケーションからの要求を受けて、データベース２１３の各種設定値を参照したり変更したりすることができる。

ＵＩデバイスコントローラ２１１は、ＵＩ部２０２および拡張アプリケーション２１０が表示部１０５へ各種情報を出力したり、操作部１０７を介して取得したユーザ操作をＵＩ部２０２および拡張アプリケーション２１０へ伝達することができる。

なお、本実施形態において、拡張アプリケーションを除くＯＳ２０１の構成要素を「ファームウェア」と称する。

図４に、スキャンアプリケーション２１４を有するＭＦＰ１０の表示部１０５に表示されるホーム画面の一例を示す。

スキャンアプリケーション２１４は、図３に示すクラウドＡ２１およびクラウドＢ２２にスキャン画像を送信するためのユーザによるスキャン属性や送信先情報などの各種設定を記憶する。各種設定を記憶したスキャンアプリケーション２１４は、図２のＵＩ部２０２の要求に応じて、クラウドＡへの送信ボタン４００１のアイコンデータと、クラウドＢへの送信ボタン４００２のアイコンデータとをＵＩ部２０２に渡す。そして、ＵＩ部２０２は、表示部１０５に図４に示す画面を表示する。

図１３は、ユーザが図４の送信ボタン４００１または４００２を押下した場合にＭＦＰ１０が実行するクラウドボタン処理の流れを示すフローチャートである。

ここで、図１３に示すクラウドボタン処理とは、図２のスキャンアプリケーション２１４を構成する処理の一部である。そして、上述の通りスクリプト言語や所定の高級言語はＶＭ／ＦＷ部２０９で解釈され、実行される。なお、ＶＭ／ＦＷ部２０９におけるスクリプト言語や所定の高級言語の解釈や実行の処理は、最終的にＣＰＵ１０１によって実行される。なお、図１３の説明において、処理を実行する主体は、スキャンアプリケーション２１４を実行するＣＰＵ１０１であるものとして説明を行う。

まず、Ｓ１３０１において、ＣＰＵ１０１は、表示部１０５を制御し、送信を行うか否かを問い合わせる画面を表示する。例えば、ＣＰＵ１０１は、表示部１０５を制御し、送信ボタンとキャンセルボタンを表示し、ユーザの更なる入力を求めてもよい。

続いて、ＣＰＵ１０１は処理をＳ１３０２に進め、ユーザが操作部１０７を操作して、送信を指示したか否かを判定する。送信を指示されたと判定した場合（Ｓ１３０２でＹｅｓ）、ＣＰＵ１０１は処理をＳ１３０３に進め、送信が取り消されたと判定した場合（Ｓ１３０２でＮｏ）、ＣＰＵ１０１は図１３に示す処理を終了する。

Ｓ１３０３では、ＣＰＵ１０１は、押下されたボタンがクラウドＡへの送信ボタン４００１であったか、クラウドＢへの送信ボタン４００２であったかを確認する。宛先がクラウドＡである場合（Ｓ１３０３でクラウドＡ）、ＣＰＵ１０１は処理をＳ１３０４に進め、宛先がクラウドＢである場合（Ｓ１３０３でクラウドＢ）、処理をＳ１３０５に進める。

Ｓ１３０４において、ＣＰＵ１０１は、クラウドＡへの送信を要求するコマンドを生成し、処理をＳ１３０６に進める。Ｓ１３０５において、ＣＰＵ１０１は、クラウドＢへの送信を要求するコマンドを生成し、処理をＳ１３０６に進める。クラウドＡへの送信を要求するコマンドの一例を図５に、クラウドＢへの送信を要求するコマンドの一例を図６に示す。それぞれのコマンドの内容については後述する。

次に、Ｓ１３０６で、ＣＰＵ１０１は、Ｓ１３０４またはＳ１３０５で生成されたコマンドを発行して、ＶＭ／ＦＷ部２０９を介してジョブコントローラ２０３にＨＴＴＰ送信ジョブを発行し、処理をＳ１３０７に進める。

次にＳ１３０７で、ＣＰＵ１０１は、ＶＭ／ＦＷ部２０９を介してジョブコントローラ２０３から情報を受け取って、依頼したＨＴＴＰ送信ジョブに対応する原稿の読み取り方式がＡＤＦスキャンか、圧板スキャンかを判断する。ＡＤＦスキャンである場合（Ｓ１３０７でＹｅｓ）、Ｓ１３０６でジョブコントローラ２０３に発行した送信ジョブによって、原稿の読み取りとスキャンしたデータの送信とが完了するので、ＣＰＵ１０１は図１３のクラウドボタン処理を終了する。一方、原稿の読み取り方式が圧板スキャンである場合（Ｓ１３０７でＮｏ）、ＣＰＵ１０１は処理をＳ１３０８に進める。

Ｓ１３０８では、ＶＭ／ＦＷ部２０９を介して圧板スキャンの状況を取得し、圧板スキャンによる１ページの読み取り終了を待つ。１ページの読み取りが完了したら処理をＳ１３０９に進み、次ページの読み取りを行うか否かをユーザに問い合わせる。

そしてＳ１３１０に処理を進め、Ｓ１３０９の問い合わせに対するユーザの操作が次ページの読み取りを行うよう指示する操作であるか否かを判定する。次ページの読み取りを行うよう指示するユーザ操作を受信したと判定すると（Ｓ１３１０でＹｅｓ）、Ｓ１３１１に処理を進める。Ｓ１３１１において、ＣＰＵ１０１はＶＭ／ＦＷ部２０９を介して次ページの読み取りをジョブコントローラ２０３に指示して、Ｓ１３０８に処理を戻す。

一方、次ページの読み取りを指示するユーザ操作を受信しなかったと判定すると（Ｓ１３１０でＮｏ）、Ｓ１３１２でＣＰＵ１０１はＶＭ／ＦＷ部２０９を介してＨＴＴＰ送信の開始をジョブコントローラ２０３に要求して、クラウドボタンの処理を終了する。

以上のように、ＡＤＦスキャンの場合は送信要求を、圧板スキャンの場合は送信開始要求した後は、ファームウェアがＨＴＴＰを介した送信処理を受け持つため、スキャンアプリケーション２１４は当該送信処理を継続的に監視する必要はない。ユーザは、図４の状況確認ボタン４００３を押下することで、送信状況の確認や、送信処理の中止を行うことができるように構成されている。

図１２は、本実施形態におけるクラウド送信処理の流れを示すフローチャートである。図１２に示すクラウド送信処理は、ジョブコントローラ２０３を構成する処理の一部であって、ＣＰＵ１０１によって実行される。図２に示すスキャンアプリケーション２１４による図１３のＳ１３０６のＨＴＴＰ送信ジョブがジョブコントローラ２０３に指示されることで図１２の処理が開始される。

まず、Ｓ１２０１において、読取部１１１上のＡＤＦに原稿があるか否かを確認する。ＡＤＦに原稿がある場合（Ｓ１２０１でＹｅｓ）、ＣＰＵ１０１は処理をＳ１２０２に進め、そうでなければジョブコントローラ２０３はＳ１２０４に処理を進める。

Ｓ１２０２では、ＣＰＵ１０１は図２のスキャン部２０７の起動を要求し、ＡＤＦスキャンを実行させる。ＡＤＦスキャンを要求されたスキャン部２０７は、ＡＤＦに原稿が無くなるまで、すべての原稿を順次読み取る。原稿を読み取ったデータは、１ページ単位で管理され、ストレージ２０６に保存される。読み取り処理の詳細についての説明は省略する。Ｓ１２０２でスキャン部２０７の起動を要求すると、処理をＳ１２０３に進める。なお、ＣＰＵ１０１は、Ｓ１２０２で要求したスキャン処理が完了する前に処理をＳ１２０３に進めてもよい。

Ｓ１２０３では、ＣＰＵ１０１は後述する図９の処理を実行し、図１２のクラウド送信処理を終了する。

一方、Ｓ１２０１において、ＡＤＦに原稿がない場合（Ｓ１２０１でＮｏ）、ＣＰＵ１０１は処理をＳ１２０４に進め、図２のスキャン部２０７の起動をＯＳ部に要求し、１ページ毎の圧板スキャンを実行させる。ＡＤＦスキャンと同様に、原稿を読み取ったデータは、１ページ単位で管理されてストレージ２０６に保存される。

続いて、ＣＰＵ１０１は処理をＳ１２０５に進め、図１３のＳ１３０６でユーザからの次ページの読み取り要求を待つ。読み取り要求を受信したと判定した場合（Ｓ１２０５でＹｅｓ）、ジョブコントローラ２０３は処理をＳ１２０４に戻し、次ページのスキャンの圧板スキャンを実行させる。次ページの読み取り要求を受信せず、図１３記載のＳ１３１２によるＨＴＴＰ送信の開始要求を受信したと判定した場合（Ｓ１２０５でＮｏ）、処理をＳ１２０６に進める。

そして、Ｓ１２０６において、ジョブコントローラ２０３は、図２の送信部２０５の起動を要求し、後述する図９に示す処理を実行させ、クラウド送信処理を終了する。

次に、図９を参照し、ＨＴＴＰ送信処理の流れを説明する。

ＨＴＴＰ送信の処理は、図２の送信部２０５を構成する処理の一部であって、ＣＰＵ１０１によって実行される。本実施形態では、図１２のＳ１２０２またはＳ１２０６でジョブコントローラ２０３から要求された場合に実行されるものとして説明を行う。

まず、Ｓ９０１において、図１３のＳ１３０６で発行されたコマンドに含まれるｓｅｐａｒａｔｅＰａｇｅパラメータが真（ｔｒｕｅ）であるか偽（ｆａｌｓｅ）であるかを判断する。ｓｅｐａｒａｔｅＰａｇｅパラメータがｔｒｕｅである場合（Ｓ９０１でＹｅｓ）、送信部２０５は処理をＳ９０２に進める、ｆａｌｓｅである場合（Ｓ９０１でＮｏ）は処理をＳ９０３に進める。

例えば図５の例であれば、ｓｅｐａｒａｔｅＰａｇｅパラメータ５００の値はｔｒｕｅであるため、ＣＰＵ１０１は処理をＳ９０２に進め、図１０を参照して後述する１ページごとに分割してＨＴＴＰ送信を行う処理（分割ＨＴＴＰ送信処理）を実行する。一方、図６の例であれば、ｓｅｐａｒａｔｅＰａｇｅパラメータ６０００はｆａｌｓｅであるため、ＣＰＵ１０１は処理をＳ９０３に進め、例えば全ページなどのまとまったページを一括でＨＴＴＰ送信する処理（一括ＨＴＴＰ送信処理）を実行する。分割ＨＴＴＰ送信処理および一括ＨＴＴＰ送信処理のそれぞれの処理の詳細は後述する。Ｓ９０２またはＳ９０３において、それぞれのＨＴＴＰ送信が完了すると、ＣＰＵ１０１は処理をＳ９０４に進め、送信履歴を記録して図９に示すＨＴＴＰ送信処理を終了する。これによって、アプリケーションが、ファームウェアによるＨＴＴＰ送信処理を監視する必要がなくなり、アプリケーションの複雑化を防ぐことができる。

続いて、図１０を参照して図９のＳ９０２の分割ＨＴＴＰ送信処理の流れを説明する。

まず、Ｓ１００１において、ＣＰＵ１０１は、ページ番号を示す変数ｉを初期化し、処理をＳ１００２に進める。次にＳ１００２において、ＣＰＵ１０１はｉページ目のデータがすべて揃うのを待つ。先に説明した通り、原稿を読み取ったデータは、１ページ単位で管理されてストレージ２０６に保存されるので、ｉページ目のデータがストレージ２０６に揃った場合（Ｓ１００２でＹｅｓ）に、処理をＳ１００３に進める。

Ｓ１００３では、ＣＰＵ１０１は図１３のＳ１３０６で発行されたコマンドに動的なフォーマット情報が含まれるか否かを判定する。本実施形態においては、発行されたコマンドに含まれるリクエストラインやヘッダの中の「｛｝」で囲まれた部分を動的なフォーマット情報（動的フォーマット）として扱うものとして説明を行う。

例えば、図５の例であれば、ｕｒｌパラメータ５０１の「｛０４｝」、およびｈｔｔｐＨｅａｄｅｒパラメータ配列５０２の「｛０４｝」が動的フォーマットである。よって、図５に示すコマンドが発行された場合、ＣＰＵ１０１は動的フォーマットが含まれていると判定し（Ｓ１００３でＹｅｓ）、処理をＳ１００４に進める。

Ｓ１００４では、インデックス値ｉに基づいて、動的フォーマットを変換してリクエストラインおよびヘッダを生成する。本実施形態においては、「｛｝」で囲まれた動的フォーマットを次のように変換する。

例えば、動的フォーマットが「｛ｎ｝」（ｎは自然数）である場合、インデックス値ｉをｎ桁の１０進数で表現した文字列に変換する。より具体的には、例えばｎ＝５、ｉ＝１１である場合、「｛５｝」は「１１」に変換される。

また、動的フォーマットが「｛０ｎ｝」である場合、１０進数で表現した文字列がｎ桁に満たない場合は先頭に０を付加するものとする。より具体的には、ｎ＝４、ｉ＝１２である場合、「｛０４｝」は「００１２」に変換される。仮にｉの桁数がｎを超える場合、ｉが必要とする桁まで拡張されてもよい。

続いてステップＳ１００５において、ＣＰＵ１０１は、変換されたフォーマットを含むＳ１００４で変換したＨＴＴＰヘッダを送出する。図１３のステップＳ１３０６で発行されたコマンドが図５に示すコマンドである場合に送出されるＨＴＴＰヘッダの例を図７（Ａ）および図７（Ｂ）に示す。１ページ目をスキャンした場合、すなわちＳ１００４でｉ＝１の場合は、ＵＲＬパラメータ５０１に含まれる「｛０４｝」がｉに基づいて変換された１０進数文字列７０１１である「０００１」を含むリクエストライン７０１０が送出される。

また、ｈｔｔｐＨｅａｄｅｒパラメータ配列５０２のｆｉｌｅｎａｍｅパラメータ５０３は、同様に「｛０４｝」がｉに基づいて変換された１０進数文字列７０２１である「０００１」を含むヘッダ７０２０が送出される。この際、例えば「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のような他に必要とされる固定のヘッダ情報が適宜送出される。

続いて、ＣＰＵ１０１は処理をＳ１００６に進め、ｉページ目の画像データをストレージ２０６から読み出しながら、図７に示すメッセージのボディ部分に付加して送出する。

続いて、ＣＰＵ１０１は処理をＳ１００７に進め、送出が終わったｉページ目のデータをストレージ２０６から削除して、処理をＳ１００８に進める。

これによって、比較的安価な画像形成装置で、コストの制約から、画像データを保存するストレージの容量を抑える必要がある場合であっても、複数ページの原稿をスキャンしてストレージに保存しながら、送信が完了したデータを順次削除することができる。すなわち、ストレージの枯渇によってスキャン送信処理が失敗することを防ぐことができる。また、ファームウェアが画像データの削除を実行することで、アプリケーションがストレージの空き容量を常に監視し、データの送信と送信完了したデータの削除とを実行するといった複雑な制御を減らすことができる。

Ｓ１００８では、ＣＰＵ１０１は、次ページがあるか否かを判定する。例えば、読取部１１１のＡＤＦに原稿がある場合には、次ページがあると判断してもよいし、ストレージ２０６に、次ページの少なくとも一部のデータがある場合には、次ページがあると判断してもよい。次ページがある場合（Ｓ１００８でＹｅｓ）、ＣＰＵ１０１は処理をＳ１００９に進め、ページ番号を示すインデックス値ｉをひとつ加算して処理をＳ１００２に戻す。例えば、Ｓ１００６で１ページ目のデータの送出が完了し、Ｓ１００８で次ページがあると判断した場合、処理をＳ１００９に進め、ｉ＝２として、Ｓ１００２以降の処理を繰り返す。言い換えると、Ｓ１００４において、ｕｒｌパラメータ５０１の「｛０４｝」がｉに基づいて変換された１０進数文字列７０３１である「０００２」を含むリクエストライン７０３０が送出される。また、ｈｔｔｐＨｅａｄｅｒパラメータ配列５０２のｆｉｌｅｎａｍｅパラメータ５０３の「｛０４｝」も、ｉに基づいて変換された文字列「０００２」を含むヘッダ７０４０として送出される。Ｓ１００８において次ページがないと判断した場合（Ｓ１００８でＮｏ）、ＣＰＵ１０１は図１０に示す分割ＨＴＴＰ送信処理を終了する。

Ｓ１００３において、ＣＰＵ１０１は、コマンドに動的フォーマットが含まれないと判断した場合（Ｓ１００３でＮｏ）、処理をＳ１０１０に進める。Ｓ１０１０では、ＣＰＵ１０１は発行されたコマンドのＵＲＬパラメータに対して必要な情報を付加した文字列を送出する。また、ｈｔｔｐＨｅａｄｅｒパラメータ配列で指定された文字列を変換することなく送出する。なお、Ｓ１０１０では、動的フォーマットを変換しないものの、ＨＴＴＰヘッダに例えば「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のような必要な付加的な固定のヘッダ情報を付加してもよい。続いて、ＣＰＵ１０１は処理をＳ１００６に進める。

次に、図１１を参照して、図９のＳ９０３で実行される一括ＨＴＴＰ送信処理の流れを説明する。なお、一括ＨＴＴＰ送信処理においては、ＨＴＴＰヘッダを動的に指定する必要がなくてもよい。そのため、まず、Ｓ１１０１において、図１３のＳ１３０６で発行されたコマンドで指定されたＨＴＴＰヘッダをそのまま送出する。図６にｓｅｐａｒａｔｅＰａｇｅパラメータがＦａｌｓｅであるコマンドの一例を示す。また、送出されるＨＴＴＰヘッダの一例を図８に示す。図６および図８からもわかるように、コマンドで指定されたリクエストラインはそのまま送出される。また、ｈｔｔｐＨｅａｄｅｒパラメータ配列で指定されたヘッダ８０２０もそのまま送出する。

また、Ｓ１１０１では、発行されたコマンドのｕｒｌパラメータに対して必要な情報を付加した文字列８０１０を送出する。例えば、「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のような必要な付加的な固定ヘッダ情報を適宜送出する。そして、Ｓ１１０２処理を進める。Ｓ１１０２において、ＣＰＵ１０１はページ番号を示すインデックス値ｉを初期化する。すなわち、ｉ＝１とする。

続いて、ＣＰＵ１０１は処理をＳ１１０３に進め、ｉページ目のデータがすべて揃うのを待つ。ＣＰＵ１０１は、ｉページのデータがストレージ２０６に揃っていると判定すると（Ｓ１１０３でＹｅｓ）、処理をＳ１１０４に進める。

Ｓ１１０４では、ＣＰＵ１０１はｉページ目のデータをストレージ２０６から読み出し、図８に示すＨＴＴＰヘッダにＭｅｓｓａｇｅボディとして付加し、送出する。そして、ＣＰＵ１０１は処理をＳ１１０５に進め、送出が終わったｉページ目のデータをストレージ２０６から削除して、Ｓ１１０６に処理を進める。

Ｓ１１０６では、次ページがあるか否かを判定する。次ページがあると判定した場合（Ｓ１１０６でＹｅｓ）、ＣＰＵ１０１は処理をＳ１１０７に進め、ページ番号を示すインデックス値ｉを加算してＳ１１０３に処理を戻す。次ページがないと判定した場合（Ｓ１１０６でＮｏ）、図１１に示す一括ＨＴＴＰ送信処理を終了する。

以上説明したように、第１実施形態では、拡張アプリケーションからファームウェアへ、ＵＲＬやＨＴＴＰヘッダ等の任意の情報を動的なフォーマットでジョブ要求時に指定して実行させることができる。また、動的なフォーマットによって、ページごとに異なる送信ファイルまたは送信先を指し示す情報を含むＨＴＴＰヘッダ等も生成できるようになる。これによって、拡張アプリケーションが画像データの削除やＨＴＴＰプロトコルによる送信処理や、送信履歴の記録などの管理処理を受け持つ必要がなくなる。

＜第２実施形態＞
第１実施形態では、任意のＨＴＴＰのリクエストラインおよびヘッダを、動的なフォーマットでジョブ要求時に一括して指定できるように構成した。しかしながら、クラウドサービスによっては、マルチパート形式（ｍｕｌｔｉｐａｒｔ形式）でＨＴＴＰメッセージを受け付ける。この場合、リクエストラインおよびヘッダだけでなく、ボディに含まれるｍｕｌｔｉｐａｒｔヘッダにも任意な文字列、あるいは、ページごとに異なる文字列を指定しなければならないことがある。第２の実施形態では、ＨＴＴＰのｍｕｌｔｉｐａｒｔヘッダに任意の文字列が指定できるＨＴＴＰ送信処理について説明を行う。

図１６に、第２実施形態に係るＨＴＴＰ送信処理の流れを示すフローチャートを記す。図９に示す送信処理と比較して、Ｓ９０１とＳ９０２との間に、Ｓ１６０１の処理を行う。

Ｓ１６０１では、図１３に示すＳ１３０６で発行されたコマンドにｍｕｌｔｉｐａｒｔパラメータが含まれるか否かを判定する。ｍｕｌｔｉｐａｒｔパラメータとは、ＨＴＴＰメッセージに含まれるコンテンツが復号データ型（ｍｕｌｔｉｐａｒｔ）であることを指し示すパラメータである。そして、本実施形態において、送信ファイルを示す情報がｍｕｌｔｉｐａｒｔパラメータで指定されるものとそる。

ＣＰＵ１０１が、Ｓ１３０６で発行されたコマンドにｍｕｌｔｉｐａｒｔパラメータが含まれていると判定した場合（Ｓ１６０１でＹｅｓ）、処理をＳ１６０２に進める。図１４にｓｅｐａｒａｔｅＰａｇｅパラメータがｔｒｕｅ（真）であって、ｍｕｌｔｉｐａｒｔパラメータが含まれるコマンドの一例を示す。図１４のコマンドはｍｕｌｔｉｐａｒｔパラメータ１４１０を含むので、処理をＳ１６０２に進める。

Ｓ１６０２では、ｍｕｌｔｉｐａｒｔによる分割ＨＴＴＰ送信処理を行い、処理をＳ９０４に戻す。

図１７に、ｍｕｌｔｉｐａｒｔによる分割ＨＴＴＰ送信の詳細な処理の流れを示すフローチャートを記す。ｍｕｌｔｉｐａｒｔによる分割ＨＴＴＰ送信処理は、図１６のＳ１６０２で実行される。

まず、Ｓ１７０１において、図１３のＳ１３０６で発行されたコマンドで指定されたＨＴＴＰヘッダをそのまま送出する。図１４に示す通り、ｓｅｐａｒａｔｅＰａｇｅパラメータ１４００はｔｒｕｅ（真）であるが、ｍｕｌｔｉｐａｒｔパラメータ１４１０を備えるので、ページごとにヘッダを動的にする必要はない。したがって、図１４のｕｒｌパラメータ１４０１およびｈｔｔｐＨｅａｄｅｒパラメータ配列１４０２には動的フォーマットを含まない。

Ｓ１７０１では、発行されたコマンドのｕｒｌパラメータに対して必要な情報を付加したリクエストライン１５０１０を送出する。送出されるＨＴＴＰメッセージの一例を図１５に示す。本実施形態では、ｈｔｔｐＨｅａｄｅｒパラメータ配列で指定された文字列１５０２０をそのまま送出する。加えて、ｍｕｌｔｉｐａｒｔパラメータ１４１０のｔｙｐｅパラメータ１４１１の値（ここでは「ｆｏｒｍ−ｄａｔａ」）を付加したＣｏｎｔｅｎｔ−Ｔｙｐｅ情報１５０３１、および「ｂｏｕｎｄａｒｙ」情報１５０３２を含むヘッダ１５０３０を送出する。さらに、例えば「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のような他に必要とされる固定のヘッダ情報を適宜送出する。そして、Ｓ１７０２に処理を進める。

Ｓ１７０２では、ページ番号を示すインデックス値ｉを初期化する。

続いて、ＣＰＵ１０１はＳ１７０３に処理を進め、ｉページ目のデータがすべて揃うのを待つ。ｉページのデータがストレージ２０６にすべて揃ったらＳ１７０４に処理を進める。

Ｓ１７０４においては、ＣＰＵ１０１は、発行されたコマンドのｍｕｌｔｉｐａｒｔパラメータに動的フォーマットの部分が含まれるか確認する。例えば、図１４に示す例であれば、ｍｕｌｔｉｐａｒｔパラメータ１４１０の中にあるｈｅａｄｅｒパラメータ配列１４１２のｎａｍｅパラメータ１４１３の値に「｛０３｝」が含まれる。よって、図１４の一例であれば、Ｓ１７０４でＣＰＵ１０１はコマンドに動的フォーマットが含まれていると判断し（Ｓ１７０４でＹｅｓ）、Ｓ１７０５に処理を進める。

Ｓ１７０５では、ＣＰＵ１０１はインデックス値ｉに基づいて、第１実施形態と同様に動的フォーマット部分を変換する。

続いてＳ１７０６において、変換されたフォーマットを含むｍｕｌｔｉｐａｒｔに係るｈｔｔｐヘッダを送出する。まずはｍｕｌｔｉｐａｒｔの境目を示すｂｏｕｎｄａｒｙ文字列１５０４０が送出される。次に、ｉ＝１であれば、ｈｅａｄｅｒパラメータ配列１４１２のｎａｍｅパラメータの値に含まれる「｛０３｝」がｉに基づいて変換された１０進数文字列「００１」を含むマルチパートヘッダ５０５が送出される。この際、例えば「Ｃｏｎｔｅｎｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のような他に必要とされる固定のヘッダ情報が適宜送出される。

そのあと、ＣＰＵ１０１は処理をＳ１７０７に進め、ｉページ目のデータをストレージ２０６から読み出しながら、図１５のｉページ目のｍｕｌｔｉｐａｒｔボディとして送出する。

そして、ＣＰＵ１０１はＳ１７０８において、送出が終わったｉページ目のデータをストレージ２０６から削除して、Ｓ１７０９に処理を進める。

Ｓ１７０９では、ＣＰＵ１０１は次ページがあるか否かを判定する。ＣＰＵ１０１が、次ページがあると判断した場合（Ｓ１７０９でＹｅｓ）、Ｓ１７１０に処理を進め、ページ番号を示すインデックス値をひとつ加算してＳ１７０３に処理を戻す。すなわちｉ＝２となり、Ｓ１７０３からＳ１７０５を経て、Ｓ１７０６においてｂｏｕｎｄａｒｙ文字列１５０６０が送出され、続いてｍｕｌｔｉｐａｒｔヘッダが送出される。例えば、図１４のｎａｍｅパラメータ１４１３の値に含まれる動的フォーマット「｛０３｝」がｉに基づいて変換され、１０進数文字列「００２」を含むｍｕｌｔｉｐａｒｔヘッダ１５０７が生成されて送出される。Ｓ１７０９において、もし次ページがないと判断されたならば、ｍｕｌｔｉｐａｒｔによるページ分割のｈｔｔｐ送信処理を終了する。

一方、Ｓ１７０４において、コマンドに動的フォーマットが含まれないと判断されたならば、Ｓ１７１１に進む。Ｓ１７１１では、発行されたコマンドのｍｕｌｔｉｐａｒｔパラメータのｈｅａｄｅｒパラメータ配列で指定された文字列をすべてそのまま送出する。加えて、例えば「Ｃｏｎｔｅｎｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」のように必要な付加的な固定のヘッダ情報を適宜送出する。そして、Ｓ１１０７に進む。Ｓ１１０７以降の処理は上述したものと同様のため、説明を省略する。

以上のように、第２実施形態にかかる画像形成装置は、Ｍｅｓｓａｇｅボディに含まれるマルチパートヘッダにも任意な文字列、あるいは、ページごとに可変な文字列を指定するよう、動的フォーマットのコマンドを受け付ける。

＜その他の実施形態＞
上記の第１または第２実施形態では、一括送信処理の場合には、動的なフォーマットを用いないとして説明を行ったが、一例では一括送信処理の場合にも動的なフォーマットを用いてもよい。例えば、文字列「｛ＹＹＹＹＭＭＤＤ｝」が、スキャン送信処理を行う年月日を示す場合、図８のＨＴＴＰヘッダ８０２の一括送信処理のファイル名を指定するコマンドに「ｉｍａｇｅ｛ＹＹＹＭＭＤＤ｝．ｐｄｆ」を用いることができる。すなわち、ファームウェアが受付けて変換可能なフォーマットであれば、任意の変換がなされてもよく、これによってアプリケーションをより簡単に構成することができる。

上記の第１または第２実施形態では、スキャンアプリケーション２１４だけがインストールされている例を示した。しかしながら、これはあくまでも一例であって、本発明のアプリケーションは上記に限定されるわけではない。

また、第１または第２実施形態では、クラウドＡおよびクラウドＢの２つのクラウドサービスへの送信が選択できるスキャンアプリケーション２１４を例に示した。しかしながら、一例では、スキャンアプリケーション２１４を修正することで、ファームウェアを修正することなく、ＵＲＬ、ｈｔｔｐヘッダ、およびＭｅｓｓａｇｅボディのヘッダで対応できる場合には、任意のクラウドサービスに対応することができる。

また、第１または第２実施形態では、１ページごとに同期してｈｔｔｐ送信とデータ削除が実行されるように構成したが、ｈｔｔｐ送信とデータ削除の同期は１ページごとである必要はない。例えば、８ＫＢといったバンド幅でｈｔｔｐ送信とデータ削除の同期を行うように構成してもよい。これによれば、より少ない容量のストレージでＡＤＦスキャンによるｈｔｔｐ送信が実現できるようになる。

また、第１または第２実施形態では、Ｔｒａｎｓｆｅｒ−ＥｎｃｏｄｉｎｇやＣｏｎｔｅｎｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇのヘッダは予め定められた文字列を送出するように構成した。一例では、これらの付加的なパラメータにも任意の文字列が指定できるように構成してもよい。これによって、より自由度が高いシステムを提供することができる。

また、第１または第２実施形態では、動的フォーマットを指定する方法として、「｛｝」で囲むものとしたが、これに限定されない。例えば、Ｃ言語のｐｒｉｎｔｆなどで使用される「％０４ｄ」のような文法を用いることで動的フォーマットを指定できてもよい。

また、第１または第２実施形態では、ファームウェアが送信履歴も記録するように構成した。しかしながら、送信履歴情報を残す必要がないのであれば、送信履歴の記録は行わず、ＵＲＬやｈｔｔｐヘッダ等の任意の情報を動的なフォーマットでジョブ要求時に一括して指定させてもよい。

また、第１または第２実施形態では、送信を要求するコマンドとしてＪＳＯＮフォーマットを使用した。しかしながら、コマンドはＪＳＯＮフォーマットに限定されるわけではない。例えばＸＭＬフォーマットであっても、任意の文字列を指定できるように構成してもよい。

上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０：ＭＦＰ、２１：クラウドＡ、２２：クラウドＢ、１０１：ＣＰＵ、１０２：ＲＯＭ、１０３：ＲＡＭ、１０４：表示コントローラ、１０５：表示部、１０６：操作コントローラ、１０７：操作部、１０８：ｅＭＭＣホストコントローラ、１０９：ｅＭＭＣ、１１０：読取コントローラ、１１１：読取部、１１２：記録コントローラ、１１３：記録部、１１４：ＵＳＢホストコントローラ、１１５：モデム、１１６：ＮＣＵ、１１７：ＮＩＣ、１１８：システムバス、２０１：ＯＳ、２０２：ＵＩ、２０３：ジョブコントローラ、２０４：Ｆａｘ部、２０５：送信部、２０６：ストレージ、２０７：スキャン部、２０８：デバイスドライバ、２０９：ＶＭ／ＦＷ、２１０：拡張アプリケーション、２１１：ＵＩデバイスコントローラ、２１２：プリント部、２１３：データベース、２１４：スキャンアプリケーション、４００１：クラウドＡへの送信ボタン、４００２：クラウドＢへの送信ボタン、４００３：状況確認ボタン

Claims (9)

1. アプリケーションを実行可能な画像形成装置であって、
   原稿を読み取る読取部を制御し、画像データを生成する読取手段と、
   前記アプリケーションから、送信ファイルおよび送信先を一括で指定するための動的なフォーマット情報を含むコマンドを受け付ける受付手段と、
   前記動的なフォーマット情報を含む前記コマンドに基づいて、送信ファイルおよび送信先を指定する情報を生成する生成手段と、
   生成した前記送信先に、前記送信ファイルとして前記画像データを送出する送出手段と、
   を備えることを特徴とする画像形成装置。
2. 前記送出手段で送出が完了した前記画像データをストレージから順次削除する削除手段をさらに備えることを特徴とする請求項１に記載の画像形成装置。
3. 前記画像データの送信が完了したとき、送信履歴に関する情報を記録する管理手段をさらに備えることを特徴とする請求項１または２記載の画像形成装置。
4. 前記画像形成装置は、ファームウェアを実行することで、前記読取手段と、前記受付手段と、前記生成手段と、および前記送出手段との少なくとも何れかの機能を実現することを特徴とする請求項１乃至３の何れか１項に記載の画像形成装置。
5. 前記ファームウェアに動的なフォーマットで送信ファイルおよび送信先を一括で指定するための動的なフォーマット情報を含むコマンドを発行する手段を有するアプリケーションをさらに有することを特徴とする請求項４に記載の画像形成装置。
6. 前記送出手段は、前記受付手段で受け付けた前記コマンドに基づいて、ページごとに異なる前記送信ファイルおよび前記送信先を指し示す情報を生成して送出する、ことを特徴とする請求項１乃至５の何れか１項に記載の画像形成装置。
7. 前記動的なフォーマット情報を含むコマンドが、マルチパート形式で送信するよう指示する場合、前記生成手段は前記動的なフォーマット情報を含む前記コマンドに基づいて、複数の送信ファイルおよび１つの送信先を指定する情報を生成することを特徴とする請求項１乃至６の何れか１項に記載の画像形成装置。
8. アプリケーションを実行可能な画像形成装置が実行する制御方法であって、
   原稿を読み取る読取部を制御し、画像データを生成する読取工程と、
   前記アプリケーションから、動的なフォーマットでＨＴＴＰのリクエストラインおよびヘッダに含まれる情報を指定するコマンドを受け付ける受付工程と、
   前記コマンドに基づいて、ＨＴＴＰのリクエストラインおよびヘッダを生成する生成工程と、
   生成した前記リクエストラインおよび前記ヘッダ、並びにＨＴＴＰのボディとして前記画像データを送出する送出工程と、
   を備えることを特徴とする制御方法。
9. 請求項１乃至７の何れか一項に記載の画像形成装置としてコンピュータを動作させるためのプログラム。

Images