"夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムであって、前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していく保存手段と、タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定する設定手段と、を有し、前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存することを特徴とするシステム。タスクを管理する管理手段を更に有し、前記特定のタスクが前記保存手段にアクセスする際であって、前記特定のタスクの1個前のタスクが出力した出力データーにアクセスできなかった場合、前記管理手段は前記1個前のタスクに入力された入力データーにアクセスを行い、アクセスできた場合は前記1個前のタスクの処理から再開するように制御することを特徴とする請求項1に記載のシステム。前記特定のタスクが出力データーを前記保存手段に保存した際に、前記特定のタスクの1個前のタスクに設定されている重要度が前記特定のタスクに設定されている重要度よりも低い場合、前記1個前のタスクが出力した出力データーを削除するように制御することを特徴とする請求項1または2に記載のシステム。前記重要度は3つのレベルを規定しており、最も重要度が高いレベルを有するタスクは出力データーを多重化させて保存し、該出力データーは前記特定のジョブの処理が終了するまで削除されないように設定され、次いで重要度が高いレベルを有するタスクは出力データーを多重化させて保存し、該出力データーは前記特定のジョブの処理が終了するまでの間に削除可能になるよう設定され、両方のレベルよりも低いレベルを有するタスクは出力データーを多重化せずに保存することを特徴とする請求項1乃至3の何れか1項に記載のシステム。夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムを制御する制御方法であって、保存手段は、前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していき、設定手段は、タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定し、前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存するよう制御することを特徴とする制御方法。しかしながら、従来技術ではそのデーターの内容が重要か否かという観点で保存先を切り分けているだけであり、一連のジョブ処理の中での各タスクの特性によるデーターの重要度が加味されていない。また一連のジョブ処理の中でタスクが順次実行されていくことで、各タスクにおける処理結果データーの保存が必要となるため、通常のデーター保存と比較してデーターの保存容量や転送容量といったコストの増大は非常に大きな課題となる。そこで、各タスクに重要度を持たすことで、データー保存の多重度やデーター保持期間に基づくデーター保存を実現することで、一連のジョブ処理における低コストのデーター保存実現を目的とする。また、サーバーシステムの異常によりデーターが失われた場合の適切なリカバリーを行い、ジョブ処理の継続を実現することを目的とする。さらには、一連のタスクの連続性を元に、さらなるデーター容量の削減を実現することを目的とする。本願発明は、上述した目的の内、少なくとも一つの目的を達成するためのサーバーシステムを提供することを目的とする。本発明の一実施形に係るシステムは、夫々が規定された処理を実行する複数のタスクの中からデバイスを起点として生成される特定ジョブを処理するためのタスクを決定し、決定されたタスクを連結させ各タスクを順次実行していくことで前記特定ジョブを処理するシステムであって、前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していく保存手段と、タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定する設定手段と、を有し、前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存することを特徴とする。本発明によれば、タスクを連結させてジョブを処理するシステムにおいて、コストを削減しつつデーターの適正な保存が可能となる。以下、本発明を実施するための最良の形態について図面を用いて説明する。図1は、本発明の実施の形態に係るクラウドシステムの全体構成を示す図である。図1において、スキャンサービスサーバー101、フローサービスサーバー102、タスクサービスサーバー103、104、クライアント端末106、画像形成装置107、インターネットサービスサーバー108は、ネットワーク110~112を介して接続されている。図において、タスクサービスサーバー103、104、クライアント端末106、画像形成装置107、クラウドサービスサーバー108は、複数台接続されていることを仮定している。ネットワーク110~112は、例えば、インターネット等のLAN、WAN、電話回線、専用デジタル回線、ATMやフレームリレー回線、ケーブルテレビ回線、データー放送用無線回線等のいずれであり。またこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク110~112は、データーの送受信が可能であればよい。一般的なクラウドサービスでは、ネットワーク110、112はインターネット、ネットワーク111は企業内ネットワークやサービスプロバイダーのネットワークとなる。スキャンサービスサーバー101、フローサービスサーバー102、タスクサービスサーバー103、104は、一般的にサーバーコンピューター上にて実行されており、これらサービス群がユーザーに対してクラウドサービスを提供する。また、様々な企業などにより、同様にクラウドサービスサーバー108がインターネット上に公開されており、これらも一般的にサーバーコンピューター上にて実行されている。本願発明では各サーバーをサービスと記載する。クライアント端末106は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、PDAパーソナルデーターアシスタント等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末106では、Webブラウザインターネットブラウザ、WWWブラウザ、WorldWideWebの利用に供するブラウザ等のプログラムを実行する環境が内蔵されている。このクライアント端末106のようなデバイスからのジョブ処理の開始指示を起点としてジョブ処理が開始される。なお、本実施例では複数のサーバー群から構成されるシステムがクラウドサービスを提供することを想定しているが、これらのサーバー群を1台に集約しても良い。なお、デバイスに相当するクライアント端末からクラウドに実行依頼が送信されたことに応じて、クラウド側は規定された処理を実行する複数のタスクを連結させてジョブを処理することになる。各タスクは、ジョブを処理するためにデーター処理を順次実行順次保存していく。即ち、デバイスを起点としてジョブが生成され、タスクを順次実行することでジョブが処理されるのである。本願発明ではジョブが生成されるタイミングをデバイスからの実行依頼としたが、後述する作成済みのスキャンチケットを選択した時点からをジョブが生成されるタイミングとしても良い。どの時点においてジョブが生成されるかは任意のタイミングではあるが、少なくともデバイスからの実行依頼をクラウド側へ送信することでジョブが処理される点はどのタイミングであっても共通である。図2は、本発明の実施形態に係るクライアント端末106、サービス群101~104を実行するサーバーコンピューターのハードウェア構成図である。図2において、CentralProcessingUnitCPU202は装置全体の制御を行う。CPU202はハードディスクHDD205に格納されているアプリケーションプログラム、OS等を実行し、RandamAccessMemoryRAM203にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ReadOnlyMemoryROM204は記憶手段であり、内部には、基本I/Oプログラム等の各種データーを記憶する。RAM203は一時記憶手段であり、CPU202の主メモリ、ワークエリア等として機能する。HDD205は外部記憶手段の一つであり、大容量メモリとして機能し、Webブラウザ等のアプリケーションプログラム、サービス群のプログラム、OS、関連プログラム等を格納している。ディスプレイ206は表示手段であり、キーボード207から入力したコマンド等を表示したりするものである。インターフェース208は外部装置I/Fであり、プリンター、USB機器、周辺機器を接続する。キーボード207は指示入力手段である。システムバス201は、装置内におけるデーターの流れを司るものである。ネットワークインターフェースカードNIC209は、該インターフェース209、ネットワーク110~112を介して外部装置とのデーターのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図2の構成例に限定されるものではない。例えば、データーやプログラムの格納先は、その特徴に応じてROM204、RAM203、HDD205などで変更することも可能である。図3は、本発明の実施形態に係るクライアント端末106のシステム構成図である。図3において、Webブラウザ301を利用し、スキャンサービス101が提供するWebアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザーは本クライアント端末106のWebブラウザ301を利用して、クラウドサービスを利用する。図4は、本発明の実施形態に係る画像形成装置107の内部構成を例示するブロック図である。本実施例ではスキャンプリントの両機能を併せ持つ装置を例にするが、スキャンサービスを実現するに当たっては、プリント機能のない、スキャン専用装置でも良い。図4において、画像形成装置107は、画像処理ユニット401、印刷ユニット402、および読み込みユニット403から構成される。画像処理ユニット401は、CPU404、直接記憶部405、間接記憶部406、ユーザーインターフェース407、外部インターフェース408から構成されている。CPU404は、所定のプログラムを実行し、画像処理装置107の各種制御を指示するユニットである。CPU404は、CPUCentralProcessingUnitにより実現される。直接記憶部405は、CPU404がプログラムを実行する際に使用するワークメモリであり、CPU404が実行するプログラムは直接記憶部405にロードされる。直接記憶部406は、RAMRandomAccessMemoryにより実現される。間接記憶部406は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部406に記憶されている各種プログラムは、CPU404がプログラムを実行する際に直接記憶部405へ移動する。間接記憶部406は、SSDSolidStateDrive、または、HDDHardDiscDriveにより実現される。なお、CPU04はマルチプロセッサでも良い。ここで、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置107上で実行できる他、画像形成装置107の操作画面をカスタマイズすることが可能になる。プラットフォームの実現方法について説明する。CPU404は、間接記憶部406に記憶されたプラットフォームプログラムを直接記憶部405に移動する。移動が完了するとCPU404は、プラットフォームプログラム例えば、Java登録商標を実行することができる状態になる。本発明の実施例では、CPU404がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置107のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例において、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービス101より、例えば、HTTPHyperTextTransferProtocolと言った通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。ユーザーはスキャンソフトウェア部にて表示されたスキャンチケット一覧より、スキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部はユーザーが選択したスキャンチケットの情報とスキャンした画像データーを合わせてスキャンサービスサーバー101に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置107の制御を実現することができる。アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部406に記憶されたアプリケーションプログラムを直接記憶部405に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例で開示するフローチャートの各処理の一部を行うことが可能である。ユーザーインターフェース407は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース408は、外部装置からのデーター受信や外部装置へのデーター送信が可能となっている。例えば、外部装置としては、外付けHDDや外付けUSBメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置107は、ネットワーク110、111を介して、クライアント端末106、スキャンサービスサーバー101と通信可能である。続いて、クラウドサービスを提供するスキャンサービスサーバー101、タスクサービスサーバー103、104の各サービスに関して説明する。さらには、各サービスの説明とともに、図11のスキャン処理のシーケンス図を用いて、スキャン処理の流れを合わせて説明する。図5を用いて、スキャンサービスサーバー101に関して説明する。スキャンサービスサーバー101はクラウドサービスにおけるスキャン機能の提供を行うサービスである。図5は、本発明の実施形態に係るスキャンサービス101のシステム構成図である。スキャンサービス101は、Webアプリケーション部501、チケット管理DB部502、テンプレート管理DB部503からなる。これら構成要素により各種処理が実行されることでスキャンサービス101がユーザーに提供される。Webアプリケーション部501はスキャン機能を提供するアプリケーションプログラムを提供する。チケット作成部511はユーザーがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置107で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメーター等が記録されている。図11にて、チケット作成部511は、クライアント端末106のWebブラウザ301からのスキャンチケット作成画面リクエストS1101を受け取り、スキャンチケット作成画面を生成しレスポンスS1102を行う。この際、チケット作成部511はテンプレート管理部516より、テンプレート管理DB部503に登録されているスキャンチケットのテンプレートを取得し、テンプレートに含まれるテンプレート名を、クライアント端末106のWebブラウザ301に表示する。テンプレート管理DB部503の詳細な内容は、図8に記載されており、前述したテンプレートについても、図8の説明に際に合わせて説明する。また、テンプレート名を表示する画面例は、図6に記載されている。表示画面についても後述する。ユーザーがクライアント端末106のWebブラウザ301にて操作を行い、スキャンチケット作成リクエストS1103を行うと、スキャンチケット作成と、チケット管理部515への保存を依頼する。チケット管理部515は、チケット保存のリクエストを受け、チケット管理DB部502にチケット情報を保存する。チケット管理DB部502の詳細な内容は図7に記載されている。チケット管理DB部502の詳細は後述する。チケット管理部515は、チケット情報を保存した後、レスポンスS1104を行う。外部I/F514は画像形成装置107上で動作するスキャンソフトウェア部との通信を行う。スキャンソフトウェア部より、外部I/F514を通じて、チケット一覧部512の機能や、スキャン受信部513の機能へのアクセスを行う。図11にて、画像形成装置107のスキャンソフトウェア部は外部I/F514を通じてチケット一覧部512に対して、チケット一覧取得S1105を行う。チケット一覧512では、スキャンチケットの一覧をチケット管理部515より生成し、スキャンソフトウェア部にレスポンスS1106を返す。レスポンスを受け取った画像形成装置107は、取得したチケット一覧を図4におけるユーザーインターフェース407上に表示する。表示画面例は、図9に記載されている。表示画面例の説明は後述する。図11のスキャン処理S1107にて、ユーザーは、ユーザーインターフェース407上に表示されたチケットのいずれかを選択し、画像形成装置に備え付けられたスキャン装置に紙を設置し、スキャン実行する。これにより、スキャンソフトウェア部は、スキャン送信S1108にて、外部I/F514を通じてスキャン受信513に対して、スキャンした画像データーとスキャンチケットの送信を行う。スキャン受信部513は、送信されたスキャンチケット、および画像データーを受信する。スキャン受信部513はステップS1109にて、受信した画像データーを、フローサービスサーバー102に投入する。フローサービスサーバー102は、画像データーを正しく受信できた場合には、スキャンサービスサーバー101に、画像データーを一意に表すIDファイルグループIDを応答する。その後、スキャン受信部513は、ジョブ投入S1111にて、ファイルグループID、およびスキャンチケットをフローサービスサーバー102に送信する。以上がスキャンサービスサーバー101のシステム構成と、スキャンジョブの投入までの流れである。図6にて、チケット作成画面601の説明を行う。チケット作成画面601は、図5のテンプレート管理DB503から取得したテンプレート図中602、603、604を表示する。ユーザーは、表示されたテンプレートの中から、実行するテンプレートを選択する。テンプレートを選択すると、詳細なチケット設定を行う画面605が表示される。図6において、同一画面に詳細設定画面605が表示されているが、別ウィンドウで詳細設定画面605を開くようにしても構わない。詳細設定画面605中では、選択したテンプレートに応じたスキャンの設定を行うことが出来る。例えば、スキャン設定の例としては、図中に示す様にサイズや、カラー、白黒といった色調、またスキャンデーターのフォーマット等の設定がある。ユーザーは、詳細な設定を行った後、チケット発行ボタン606を押下すると、図5のチケット管理DB部502に、チケットの情報が新規作成される。チケット管理DB部502に保存されるチケット情報は、後述する。チケット情報が、チケット管理DB部502に正しく作成された場合には、チケット番号607に、チケットに固有に割り当てられたIDが表示される。このIDは、図7におけるチケットID702と同じ値となる。ユーザーは、チケット番号607に表示されたIDを記憶し、画像形成装置107に移動する。図7にて、チケット管理DB部502で管理されている情報の一例を示す。ユーザーID701は、該チケットを作成したユーザーを一意に表すIDである。チケットID702は、チケットを一意に定義するIDである。このチケットIDは、図6のチケット発行606を押下した際にチケット作成部511にて生成され、チケット管理DB502に保存される。ルートID703は、チケット作成画面601にて、ユーザーが選択したテンプレートに対応するルートIDである。ユーザーがーチケットを選択し、スキャンを実行した場合には、そのスキャンデーターは、ルートID703に定義されたタスクの順番で処理される。パラメーター704は、詳細設定画面605にて設定したスキャンの設定が記録されている。図8にて、テンプレート管理DB503で管理されているテンプレートの一例を示す。テンプレート管理DB503は、図13のルート情報管理DB1301にて管理されるルート情報と、チケット作成画面上に表示されるテンプレートを紐づけるためのデーターベースである。ここで、テンプレートは、テンプレートID801、テンプレート名802、およびルートID803から構成される。テンプレートID801は、各テンプレートを一意に表すIDである。テンプレート名802は、図6のチケット作成画面601に表示される名前である。ルートID803は、図14における、ルート情報管理DB1301にて管理されるルートID1401への外部キーを表す。図9にて、図11のチケット一覧取得S1105にて、取得したチケット情報が表示される画面例を説明する。本画面は、画像形成装置107のユーザーインターフェース407上に表示される。画面上には、チケット管理502から取得したチケットID702が表示されている901~906。ユーザーは、実行するチケットを選択し、画像形成装置107にスキャン対象の原稿を設置し、スキャンボタン907を押下する。これにより、図11におけるスキャン送信S1108が実行される。スキャン送信S1108が実行されると、スキャンサービスサーバー101のスキャン受信513に対して、スキャンしたデーターと、チケットが送信される。引き続き、図10にて、本発明の実施形態に係るタスクサービスサーバー103、104のシステム構成図を説明する。各タスクサービスサーバーは、スキャンサービスを実現するための要素機能を実現するサービスである。例えば画像データー対して画像処理を行うタスクサービスや、ファイル共有機能を提供するような他のクラウドサービス108に対して、画像データーを送信する処理を行うタスクサービスが存在する。本実施例においては、タスクサービスサーバー103は、画像データーに対してOCR処理を行いOCR結果のテキストデーターを画像データーに埋め込む処理を行う。また、タスクサービスサーバー104は、クラウドサービス108の中のストレージ機能を提供する特定のサービスに対して、画像データーをアップロードし保管する処理を行う。以下、図11のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行うタスクサービスサーバー103、104のタスク取得部1011は、ステップS1112、S1113、S1119、S1120にて、定期的にフローサービスサーバー102に問い合わせを行い、各タスクサービスサーバー103、104にて処理可能なタスクを取得する。タスクサービスサーバー103、104のデーター取得部1012は、タスク取得部1011で取得した情報を元に、ステップS1114、S1115、S1121、S1122にてフローサービスサーバー102より処理すべき画像データーの取得を行う。タスクサービスサーバー103、104のタスク処理部1015は、ステップS1116、S1123にて取得した画像データーに対して各種処理を行う。タスクサービスサーバー103のタスク処理部1015は、ステップS1116での処理結果をステップS1117にてデーター保存部1013を通して、フローサービスサーバー103に保存する。タスクサービスサーバー104のタスク処理部1015は、ステップS1123での処理結果をステップS1124にてクラウドサービス108にデーター送信する。タスクサービスサーバー103、104のタスクステータス通知部1014は一連のタスク処理の終了結果をステップS1118、S1125にて、フローサービスサーバー103に通知する。以上で、スキャンジョブの一連の処理が完了する。タスク処理の結果は、各タスクに設定されている重要度に応じて、異なる保存方法で出力結果をメモリに保存していく。続いて、フローサービスサーバー102の詳細な説明を行う。フローサービスサーバー102は本願発明における中心的なサービスであり、ルート管理、ジョブ管理、一時ファイル管理を行うサービスである。図12は、フローサービスサーバー102のシステム構成の概要である。フローサービスサーバー102は、ルート管理サービスサーバー1201、ジョブ管理サービスサーバー1202、一時ファイル管理サービスサーバー1203の各サーバーからなる。これらサーバー上により各種処理が実行されることで各サービスが提供され、それらが連携することで、フローサービスサーバー102がユーザーに提供される。ルート管理サービスサーバー1201はタスクとタスクを連結させたルートの情報を管理する。ジョブ管理サービスサーバー1202はルートの情報に基づきジョブの処理を管理する。一時ファイル管理サービスサーバー1203はジョブ投入時のデーターや各タスクの処理結果データーの保存を管理する。引き続きフローサービスサーバー102を構成するルート管理サービスサーバー1201、ジョブ管理サービスサーバー1202、一時ファイル管理サービスサーバー1203の詳細な説明を行う。図13は、ルート管理サービスサーバーのシステム構成である。ルート管理サービスサーバー1201は、ルート情報管理DB部1301、タスク情報管理DB部1302、外部I/F1303からなる。ルート情報管理DB部1301はタスクの連結をルートという単位で定義するための情報を保持している。タスク情報管理DB部1302は各処理をタスクという単位で定義し、タスクに関する情報を保持している。外部I/F1303はルート管理サービス1201への問い合わせのためのI/Fであり、ジョブ管理サービス1202等からルート情報管理DB部1301やタスク情報管理DB部1302を参照するためのI/Fである。図14にて、ルート情報管理DB部1301で管理されている情報の一例を示す。ルートID1401がルートを一意に識別するIDである。シーケンス番号1402はそのルートの何番目に実行するタスクであるかを保持する。タスクID1403はどのタスクを実行するかを保持する。例えば、データー1413、1414、1415で、ルートID1401が002のルートを定義している。1413が1番目に実行するタスクであり、タスクID1403がTask1のタスクを実行する。同様に、1414が2番目に実行するタスクであり、Task3のタスクを、1415は3番目に実行するタスクでTask5のタスクを実行するという定義となる。このように、1ルートに対して複数のタスクが割り当てられており、更に規定された順番通りにタスクが実行されるように、幾つかのタスクが連結する。図15にて、タスク情報管理DB部1302で管理されている情報の一例を示す。タスクID1501がタスクを一意に識別するIDである。タスク名1502はそのタスクの名前である。続いて、多重度1503と削除1504にてそのタスクの重要度の設定を保持する。多重度1503はそのタスクの処理結果を保存する際、どの程度の多重度でデーターを保存しておくのかを示す設定である。多重度1503が0の場合は処理結果を保存しないタスクであり、その他の場合は多重度の数である。多重度が大きいほど重要なタスクとなる。重要度が高まれば多重化させて出力データーを保存することになる。タスクサービス103、104のデーター保存1013はデーター保存S1115を実行する際に、本設定を元にフローサービス102にデーター保存依頼を行う。削除1504はそのデーターをジョブ終了時まで保持するべきか否かを示すフラグである。削除1504が1の場合にはジョブ処理の途中で削除可能であり、0の場合はジョブが終了するまで削除してはいけない。また、値がないものはそもそもデーターを保存していないタスクである。削除1503は0のものが重要なタスクとなる。例えば、タスク定義1518のように、スキャンデーターを保存するタスクでは、多重度が2、削除は0と設定される。これは、ユーザーが画像形成装置107にて原稿をスキャンした際、処理の結果を待たず原稿を破棄してしまった場合でも、必ず生成したスキャンデーターを保持するための設定である。タスク定義1515のように、クラウド1よりデーターを取得するタスクでは、多重度が2、削除は0と設定される。これは、クラウド1にアクセスする際、認証トークンといった認証情報を利用するためである。一般的に認証トークンは有効期間が決まっているため、認証トークン有効期限が切れた場合クラウド1にアクセスできなくなる。いったんアクセスできて取得した情報は再取得できるかわからないので確実に保持するための設定である。本設定は、例えばワンタイムパスワードでの認証が必要なサービスへのアクセスや、ワンタイムURLへのアクセスが必要な処理の場合でも同様である。タスク定義1513のように、データー変換サービス連携を行う場合では、多重度が2、削除は1と設定される。他サービスに画像データーを送信し、その変換結果を取得するような処理の場合、一般的に処理に時間がかかるうえ、1処理毎に課金される場合がある。このため、データー自体は再生成できるができれば再生成を行いたくないので、データーが失われにくい設定は行う。ただし、あくまでも処理の途中結果であるため、ジョブを処理している最中であっても削除を許可する。タスク定義1516のように、PDFフォーマットのデーターをJPEGフォーマットのデーターに変換する処理では、多重度が1、削除は1と設定される。このような処理は処理コストが低く、本スキャンサービス内でのみ処理する機能の為、データー自体の再生成も容易であり多重度無しで設定する。さらには、処理の途中結果であるため処理途中での削除を許可する。本実施例では少なくとも3つのレベルの重要度を設定しており、多重度2、削除0のものが最も重要度が高く、次いで多重度1、削除1のものが2番目に重要度が高く、最後に多重度1、削除0を両方のレベルより低い重要度と定めている。各タスクは、この重要度のレベルの内何れか1つのレベルが設定され、設定されたレベルに応じた方法で出力データーを保存し、また、保存された出力データーはレベルに応じた設定に従い削除制御が行われる。以上、説明してきたように、夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムにおいて、タスク毎に異なる重要度を設定する。結果、各タスクが出力する出力結果の取り扱いに差異を持たすことができ、各タスクは、上述したように重要度に従った保存方法でメモリにタスクの出力結果を保存する。図16を用いて、ジョブ管理サービスサーバー1202に関して説明する。ジョブ管理サービスサーバー1202は、タスクサービスサーバー103、104からのリクエストに対してタスク情報の授受や、各タスクの状態を管理するためのサービスである。外部I/F1601は、タスクサービスサーバー103、104、および画像形成装置107との通信を行う。外部I/F1601を通じて、ジョブ管理サービスサーバー1202の各機能へのアクセスを行う。ジョブ情報管理DB部1602は、作成された各ジョブのステータスや、各ジョブが扱うデーターのIDを管理する。ジョブ情報管理DB部1602の詳細な内容は、図17に記載されており、ジョブ情報管理DB部1602の内容に関する説明は後述する。ジョブ追加部1603は、スキャンサービスサーバー101が、図11において、外部I/F1601を通じて発行されるジョブ投入リクエストS1109を受け、ジョブ情報管理DB部1602に、ジョブ情報を格納する。ここで、ジョブ情報とは、図17に示されるジョブ情報管理DB部1602に存在する各カラム1701~1707から構成される。ジョブ情報取得部1604は、タスクサービスサーバー103、104から外部I/F1601を通じて発行されるタスク取得リクエストS1110を受け、ジョブ情報管理DB部1602から、ジョブ情報を取得する。ここで取得したジョブ情報は、タスク取得S1111にてタスクサービスサーバー103、104に渡される。ジョブ情報更新部1605は、結果通知S1116にて、タスクサービスサーバー103、104から、外部I/F1601を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理DB部1602の該ジョブの情報を更新する。ここで、更新される情報として、カレントタスクID1704、およびステータス1705、最終更新時刻1706がある。カレントタスクID1704を更新する前には、ルート管理サービス部1201の外部I/F1303を通じて、ルート情報管理DB部1301から、該ルートIDにおける次のタスクIDを取得する。取得したタスクIDを以て、カレントタスクID1704を更新する。また、ステータス1705は0、最終更新時刻1706は現在時刻で更新する。続いて、図17を用いて、ジョブ情報管理DB部1602に保持されるデーターについて説明する。ジョブID1701は、各ジョブ情報に一意に割り当てられるIDである。ルートID1702には、図6のチケット作成画面601にて選択したテンプレートに対応するルートIDが格納される。ファイルグループID1703は、一時ファイル管理サービス1203から発行されるIDである。カレントタスクID1704は、そのジョブにおいて処理を行うべきタスクを示すタスクIDである。タスクサービスサーバー103、104は、このカレントタスクID1704を確認し、自タスクサービスに割り当てられたタスクIDと等しい行を選択し処理を行う。本IDは、該タスクの処理が完了した際には、ジョブ情報更新1605が、該ルートIDの次のタスクのタスクIDに更新する。ステータス1705には、処理待ち0、実行中1、エラー発生2を表す値が設定される。タスクサービスサーバー103、104がジョブを選択する際には、ステータスが1となっている行を選択する。これにより、複数のタスクサービスが同一のタスクを処理するといった事態を防ぐことができる。タスクサービスサーバー103、104が、ジョブを選択した後に、タスクサービスサーバー103、104は、外部I/F1601を通じて、ジョブステータス変更部1605より、ステータス1705を1に変更する。最終更新時刻1706は、タスクサービスサーバー103,104が該ジョブに対して、何らかの処理を実行した際に、更新される。ここで、何らかの処理とは、ステータスの更新処理や、ジョブの取得処理である。タスクサービスサーバー103、104がジョブを取得する際に、自タスクIDと等しいジョブ情報が複数存在していた場合には、最終更新時刻1706が最も古いジョブを選択する。これにより、全てのジョブを平均的に処理することが可能となる。パラメーター1707には、詳細設定画面606にて設定した設定情報や、タスクサービスサーバー103、104が、他のタスクサービスサーバー103、104に渡す設定情報などを記載する。一時ファイル管理サービスサーバー1203は、スキャンサービスサーバー101やタスクサービスサーバー103、104からの要求に応じて、ファイルを格納し、その格納先のパスを管理するサービスである。タスクサービスサーバー103、104からファイル取得要求があった際には保存したファイルのバイナリデーターをタスクサービスサーバー103、104に返却する。また、タスクサービスサーバー103、104やジョブ管理サービス1202からファイル削除の要求があった際には、保存したファイルを削除する。スキャンサービスサーバー101やタスクサービスサーバー103、104は一時ファイル管理サービス1203によって、ファイルの格納先のパスやファイルサーバーの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。続いて、図18、図19、図20、図21を用いて、一時ファイル管理サービス1203について説明する。図18は一時ファイル管理サービス1203の全体構成を示す図である。図18において、中央管理サーバー1801、ファイルサーバーA1802、ファイルサーバーB1803、ファイルサーバーC1804はネットワーク1810を介して接続されている。また、ネットワーク1810はネットワーク110と接続されている。ネットワーク1810はネットワーク110と同様のデーターの送受信が可能な通信ネットワークである。中央管理サーバー1801は一般的にサーバーコンピューター上にて実行される。ファイルサーバー1802~1804は一般にサーバーコンピューター上にて実行されており、必要に応じて電子データーを保存、削除、取得する機能を有している。続いて、一時ファイル管理機能を提供する中央管理サーバー1801について図19、図20、図21を用いて説明する。図19は、本発明の実施形態に係る、中央管理サーバー1801のシステム構成図である。中央管理サーバー1801は、Webアプリケーション部1901、バックエンド部1902、ファイルサーバー管理DB部1931、パス管理DB部1932からからなる。これら構成要素により各種処理が実行されることでサービスを行う。Webアプリケーション部1901が、一時ファイル管理機能を提供するWebアプリケーションプログラムである。各機能については後述する。バックエンド部1902は、ファイルサーバー1802~1804へのファイル保存、取得、削除などの機能を実現する。ファイルサーバー管理DB部1931、パス管理DB部1932は、一時ファイル管理機能を実現するためのデーターを管理する。ファイルサーバー管理DB部1931は、ファイルの格納先であるファイルサーバー1802~1804に関する情報を管理する。図20にファイルサーバー管理DB部1931で管理するデーターの例を示す。ID2001は、ファイルサーバーを一時ファイル管理サービス1203内で一意に識別するための情報である。ホスト名2002は、ネットワーク1810上におけるファイルサーバーの一意のアドレスを示し、Webアプリケーション部1901がバックエンド部1902を通じてファイルサーバー1802~1804にアクセスする際に使用する。アクティブフラグ2003は、Webアプリケーション部1901がバックエンド部1902を通じてホスト名2002に存在するファイルサーバーとの通信の可否を示す真偽値であり、通信可能な場合はTrue、通信不可能な場合はFalseを取る。共有フォルダ名2004はファイルサーバー1802~1804上に作成した共有フォルダ名である。ホスト名2002と共有フォルダ名2004から、ファイルサーバー1802~1804上に作成した共有フォルダのフルパスが得られる。パス管理DB部1932は一時ファイル管理サービス1203で管理している、ファイルサーバー1802~1804に保存された一時ファイルとフォルダに関する情報を管理する。本発明では、一時ファイル管理サービス1203で管理するファイルとフォルダをあわせてエンティティと呼ぶ。図20にパス管理DB部1932で管理するデーターの例を示す。ファイルID2010は、ファイルサーバー1802~1804でエンティティを一意に識別するための情報である。ファイルグループID2011は各エンティティを関連するジョブでグループ化するための情報である。従って、同一ジョブによって生成されたエンティティは同一のファイルグループID2011を持つ。タスクID2012は各エンティティに関連するタスクのタスクID、またはフォルダを表すFolder、またはスキャンサービスサーバー101からの要求により格納されたファイルを表すinitのいずれかの値が入る。本発明では、スキャンサービスサーバー101からの要求により格納されたファイルを初期データーと呼ぶ。No2013は各タスクによって生成されたファイルのファイル番号を示す。パス2014はエンティティの格納先のフルパスを示し、Webアプリケーション部1901がバックエンド部1902を通じてエンティティにアクセスする際に使用する。ホスト名2015は各エンティティの格納先のファイルサーバーのホスト名を示す。作成日2016及び有効期限2017は各エンティティの作成日及び有効期限を示す。ファイルサーバー1802~1804は、一時ファイル管理サービス1203で管理するファイルを格納する。図21にファイルサーバー1802~1804のフォルダの階層構造を示す。フォルダ2101は共有フォルダであり、Webアプリケーション部1901がバックエンド部1902を通じてアクセス可能とする。共有フォルダ2101は各サーバーに少なくとも1つ存在し、ファイルサーバー管理DB部1931の共有フォルダ名2004と一致する。本発明では共有フォルダ2101の深さを0とする。共有フォルダ2101の直下にある、深さ1のフォルダ群2131の各フォルダ2111、2121のフォルダ名はファイルグループID2011に対応する。また、2111および2121の直下にある深さ2のフォルダ群2132の各フォルダ2112、2113、2122、2124、2127のフォルダ名はタスクID2012に対応する。一時ファイル管理で管理される一時ファイルは、深さ2のフォルダ群2132の直下に保存される。このときのファイル名はNo2013に対応する。続いて、Webアプリケーション部1901が持つ各機能について説明する。ファイル保存部1911は、スキャンサービスサーバー101やタスクサービスサーバー103、104からのリクエストに応じて、ファイルサーバー1802~1804にファイルを多重化して保存する機能を実現する。多重度は呼び出し元であるスキャンサービス101やタスクサービスサーバー103、104から1以上の整数を指定でき、多重度1の場合は多重化せずに保存する場合と同義である。また多重度の最大値は、ファイルサーバー1802~1804に存在する共有フォルダ数であり、それ以上は無視される。ファイル保存部1911は、スキャンサービスサーバー101からの初期データー保存のリクエストを受信すると、まず現在稼働中のファイルサーバーの中から保存先のファイルサーバーを選択する。この際、ファイル保存部1911は、深さ1のフォルダ群2131のフォルダ数が少ないファイルサーバーから順に指定された多重度分だけ選択する。これは、各ファイルサーバー1802~1804の容量を均一化するためである。スキャンサービスサーバー101からの初期データー保存のリクエストには、多重度、タスクID、Noが含まれる。ファイル保存1911はファイルグループIDを生成し、ファイルグループID、タスクID、Noに基づいて保存先のファイルパスを生成し、後述のファイル保存処理を実行する。ファイル保存部1911がタスクサービス103、104からファイル保存のリクエストを受信した場合は、そのリクエストには、多重度、ファイルグループID、タスクID、Noが含まれる。ファイル保存1911は、受信したリクエストに含まれるファイルグループIDと同一のファイルグループIDを持つ初期データーが保存されているファイルサーバーをパス管理DB部1932から取得する。ファイル保存1911は、ファイル保存先のファイルサーバーを、取得したファイルサーバーの中から多重度分だけランダムに選択する。ファイル保存部1911は、選択した各ファイルサーバーに対して、ファイルグループID、タスクID、Noに基づいて保存先のファイルパスを決定し、ファイル保存処理を実行する。ファイル保存処理では、ファイル保存部1911がバックエンド部1902に対して保存先ファイルパスとファイルのバイナリデーターを送信する。バックエンド部1902は保存先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はファイルを保存先ファイルパスに保存する。多重保存する場合は上記の処理を多重度分繰り返す。バックエンド部1902は、全てのファイルの保存が完了したらファイル保存部1911に結果を返す。ファイル保存部1911はパス管理DB部1932に保存先ファイルパスに関するエントリを多重度分追加する。ファイル保存処理の完了後、初期データーを保存した場合のみ、呼び出し元のスキャンサービス101に対してファイルグループIDを返却する。ファイル取得部1912はタスクサービスサーバー103、104からの要求に応じてファイルサーバー1802~1804に保存されたファイルをタスクサービス103、104に返す。ファイル取得部1912はタスクサービスサーバー103、104からのリクエストを受信すると、リクエストに含まれるファイルグループIDやタスクID、Noに基づいてパス管理DB部1932に問い合わせ、格納先のファイルパスを取得する。ファイル取得部1912はバックエンド部1902に対して格納先のファイパスを送信する。バックエンド部1912は格納先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はファイルのバイナリデーターをファイル取得部1912に返す。ファイル取得部1912はバックエンド部1912から返却されたバイナリデーターをタスクサービス103、104に返す。ファイル削除1913はタスクサービスサーバー103、104やジョブ管理サービスサーバー1202からの要求に応じてファイルサーバー1802~1804に格納されたエンティティを削除する。ファイル削除部1913はタスクサービスサーバー103、104やジョブ管理サービス部1202からのリクエストを受信すると、リクエストに含まれるファイルグループIDやタスクID、Noに基づいてパス管理部1932に問い合わせる。ファイル削除部1913は取得した格納先のエンティティパスをバックエンド部1902に対して格納先のエンティティパスを送信する。バックエンド部1912は格納先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はエンティティを削除する。バックエンド部1902は削除が完了したら、ファイル削除部1913に結果を返す。エンティティの削除に成功したら、ファイル削除部1913はパス管理DB部1932から削除したエンティティに関するエントリを削除する。以上により、タスクの重要度に応じてデーターの保存多重度を変化させることが実現でき、低コストでのデーター保存が可能となる。引き続き、一時ファイル管理サービス1203にて管理しているデーターに異常が発生した場合のリカバリー処理と、ジョブにおけるデーター保存をさらに削減する処理に関して説明する。図22はジョブ実行中にタスクが保存データーにアクセスできなかった場合にジョブ管理サービス1202が行うジョブのリカバリー処理を示すフローチャートである。即ち、特定のタスクが1個前のタスクが出力した出力データーにアクセスできなかった場合の処理の説明である。本処理は、ジョブ管理サービスサーバー1202がタスクサービスサーバー103、104よりデーターアクセスエラーの通知を受けた場合に実行される。エラー通知を受けたジョブ管理サービスサーバー1202はステップS2202にて、エラーが発生したタスクを実行しているジョブの情報とジョブのルート情報をジョブ管理情報DB部1602より取得する。ステップS2203では取得したジョブ情報を元に、現在実行中のタスクがジョブの最初のタスクであるか否かを判別する。本判断は、ジョブ管理情報DB部1602のルートID1702、カレントタスクID1704および、ルート情報管理DB部1301のシーケンス番号1402の情報を利用して行う。現在実行中のタスクが最初のタスクであった場合、そのジョブは継続して処理が続けられないのでステップS2204にてジョブをエラーとしてそのジョブを終了する。ステップS2203にて最初のタスクではないと判断した場合、ステップSJ05にてエラーが発生したタスクの1個前のタスクの入力データーにアクセスを試み、アクセスできるか否かをチェックする。アクセスできる場合、ステップS2206にて、次にジョブが実行すべきタスクを1個前のタスクに設定しジョブを継続する。ステップS2205にて、データーにアクセスできない場合、ステップS2207にて1個前のタスクを実行タスクに設定し、再度ステップS2203からの処理を行う。即ち、複数のタスク内の特定のタスクが1個前のタスクが出力した出力データーにアクセスできなかった場合、ジョブ管理サービスサーバー1202は1個前のタスクに入力された入力データーにアクセスを行う。そして、アクセスできた場合は1個前のタスクの処理から再開するように制御するのである。以上の処理により、タスクにてデーターアクセスエラーが発生したジョブのリカバリー処理が完了し、データーが正常に保存されている状態からジョブが再開される。図23はジョブ実行中に各タスクが終了したタイミングでジョブ管理サービス1202が行うデーターのシュリンク処理を示すフローチャートである。本処理は、ジョブ管理サービス1202がタスクサービスサーバー103、104よりタスク実行完了の通知を受けた場合に実行される。タスク完了通知を受けたジョブ管理サービス1202はステップS2302にて、完了したタスクを実行しているジョブの情報とジョブのルート情報をジョブ管理情報DB部1602より取得する。ステップS2303では、ステップS2302にて取得した情報より、実行完了したタスクのジョブで、実行完了したタスクよりも前に実行したタスクの分ループ処理を行う。ステップS2304では実行完了タスクと前のタスクの多重度1503の設定を比較し、多重度が実行完了タスクより低いか否かを判断する。多重度が実行完了タスク以下、即ち低いと判断された場合、さらに前のタスクの削除1504の設定を確認し、削除1504が1の場合はステップS1505に進み、前のタスクが保存したデーターを削除する。以上の処理により、最終実行タスクのデーターよりも多重度が低いデーターを削除することで、システムが保持するデーター量を減らすことが可能となる。さらには、データーの多重度が高く重要なデーターが保存されているため、システムの可用性を維持することが可能となる。"