(57)【要約】【課題】  例えばファイルの送信元と接続ができなくなって、再度ファイルを受信したとしても、ファイルが保存されていることを示す情報を通知することを目的とする。【解決手段】  ファイルとファイルに関連するファイル情報と識別子を受信して、ファイル情報に基づいてファイルは保存されていないと判断した場合にファイルとファイル情報と識別子を紐付けて保存して、ファイル情報に基づいてファイルは保存されていると判断した場合に保存した識別子と新たに受信した識別子が同一であると判断した場合に受信したファイルは保存されていることを示す情報を通知する。【選択図】  図１７
2014241009.tif 000002
【特許請求の範囲】
【請求項１】
ファイルと、前記ファイルに関連するファイル情報と、識別子を受信する受信手段と、
前記ファイル情報に基づいて前記ファイルが保存されているか否かを判断する第１の判断手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていないと判断した場合に、前記ファイルと前記ファイル情報と前記識別子を紐付けて保存する保存手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていると判断した場合に、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であるか否かを判断する第２の判断手段と、
前記第２の判断手段が、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であると判断した場合に、前記受信手段が受信した前記ファイルは保存されていることを示す情報を通知する通知手段と、を有することを特徴とする情報処理装置。
【請求項２】
前記通知手段は、前記第２の判断手段が、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一ではないと判断した場合にエラーを通知することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、前記識別子としてセッションを識別する識別子を受信して、
前記保存手段は、前記ファイルと前記ファイル情報と前記セッションを識別する識別子を紐付けて保存して、
前記第２の判断手段は、前記保存手段が保存した前記セッションを識別する識別子と前記受信手段が新たに受信した前記セッションを識別する識別子が同一であるか否かを判断することを特徴とする請求項１又は請求項２に記載の情報処理装置。
【請求項４】
前記受信手段は前記ファイル情報としてジョブを識別する識別子と前記ジョブを構成するタスクを識別する識別子を前記タスクから受信して、
前記第１の判断手段は、前記ファイルが保存されているか否かを、少なくとも前記保存手段が保存する前記ファイル情報に含まれる前記ジョブを識別する識別子と前記タスクを識別する識別子に、前記受信手段が新たに受信する前記ファイル情報に含まれる前記ジョブを識別する識別子と前記タスクを識別する識別子が含まれているか否かによって判断することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記保存手段は既存のファイル名と重複しないファイル名で前記ファイルを保存することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記保存手段が保存する前記ファイルのうちデータベースで参照されていない前記ファイルを削除する削除手段と、を有し、
前記保存手段は前記ファイルのパスと前記ファイル情報と前記識別子を紐付けて前記データベースに保存することを特徴とする請求項５に記載の情報処理装置。
【請求項７】
ジョブのセッションを識別する識別子が発行されているか否かを判断する第３の判断手段と、
前記第３の判断手段が前記ジョブのセッションを識別する前記識別子は発行されていないと判断した場合に、前記ジョブのセッションを識別する前記識別子を発行する発行手段と、を有し、
前記保存手段は、前記ファイルと前記ファイル情報と前記発行手段が発行する前記ジョブのセッションを識別する前記識別子を紐付けて保存することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
コンピュータに、
ファイルと、前記ファイルに関連するファイル情報と、識別子を受信する受信工程と、
前記ファイル情報に基づいて前記ファイルが保存されているか否かを判断する第１の判断工程と、
前記判断工程で前記ファイル情報に基づいて前記ファイルは保存されていないと判断した場合に、前記ファイルと前記ファイル情報と前記識別子を紐付けて保存する保存工程と、
前記判断工程で前記ファイル情報に基づいて前記ファイルは保存されていると判断した場合に、前記保存工程で保存した前記識別子と前記受信工程で新たに受信した前記識別子が同一であるか否かを判断する第２の判断工程と、
前記第２の判断工程で、前記保存工程で保存した前記識別子と前記受信工程で新たに受信した前記識別子が同一であると判断した場合に、前記受信工程で受信した前記ファイルは保存されていることを示す情報を通知する通知工程と、を実行させることを特徴とするプログラム。
【請求項９】
前記通知工程は、前記第２の判断工程で、前記保存工程で保存した前記識別子と前記受信工程で新たに受信した前記識別子が同一ではないと判断した場合にエラーを通知することを特徴とする請求項８に記載のプログラム。
【請求項１０】
前記受信工程は、前記識別子としてセッションを識別する識別子を受信して、
前記保存工程は、前記ファイルと前記ファイル情報と前記セッションを識別する識別子を紐付けて保存して、
前記第２の判断工程は、前記保存工程で保存した前記セッションを識別する識別子と前記受信工程で新たに受信した前記セッションを識別する識別子が同一であるか否かを判断することを特徴とする請求項８又は請求項９に記載のプログラム。
【請求項１１】
前記受信工程は前記ファイル情報としてジョブを識別する識別子と前記ジョブを構成するタスクを識別する識別子を前記タスクから受信して、
前記第１の判断工程は、前記ファイルが保存されているか否かを、少なくとも前記保存工程で保存する前記ファイル情報に含まれる前記ジョブを識別する識別子と前記タスクを識別する識別子に、前記受信工程で新たに受信する前記ファイル情報に含まれる前記ジョブを識別する識別子と前記タスクを識別する識別子が含まれているか否かによって判断することを特徴とする請求項８乃至１０のいずれか１項に記載のプログラム。
【請求項１２】
前記保存工程は既存のファイル名と重複しないファイル名で前記ファイルを保存することを特徴とする請求項８乃至１１のいずれか１項に記載のプログラム。
【請求項１３】
前記コンピュータに、
前記保存工程で保存する前記ファイルのうちデータベースで参照されていない前記ファイルを削除する削除工程と、を実行させ、
前記保存工程は前記ファイルのパスと前記ファイル情報と前記識別子を紐付けて前記データベースに保存することを特徴とする請求項１２に記載のプログラム。
【請求項１４】
前記コンピュータに、
ジョブのセッションを識別する識別子が発行されているか否かを判断する第３の判断工程と、
前記第３の判断工程で前記ジョブのセッションを識別する前記識別子は発行されていないと判断した場合に、前記ジョブのセッションを識別する前記識別子を発行する発行工程と、を実行させ、
前記保存工程は、前記ファイルと前記ファイル情報と前記発行工程で発行する前記ジョブのセッションを識別する前記識別子を紐付けて保存することを特徴とする請求項８乃至１３のいずれか１項に記載のプログラム。
【請求項１５】
ファイルと、前記ファイルに関連するファイル情報と、識別子を受信する受信工程と、
前記ファイル情報に基づいて前記ファイルが保存されているか否かを判断する第１の判断工程と、
前記判断工程で前記ファイル情報に基づいて前記ファイルは保存されていないと判断した場合に、前記ファイルと前記ファイル情報と前記識別子を紐付けて保存する保存工程と、
前記判断工程で前記ファイル情報に基づいて前記ファイルは保存されていると判断した場合に、前記保存工程で保存した前記識別子と前記受信工程で新たに受信した前記識別子が同一であるか否かを判断する第２の判断工程と、
前記第２の判断工程で、前記保存工程で保存した前記識別子と前記受信工程で新たに受信した前記識別子が同一であると判断した場合に、前記受信工程で受信した前記ファイルは保存されていることを示す情報を通知する通知工程と、を有することを特徴とする制御方法。
【請求項１６】
ファイルと、前記ファイルに関連するファイル情報と、識別子を受信する受信手段と、
前記ファイル情報に基づいて前記ファイルが保存されているか否かを判断する第１の判断手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていないと判断した場合に、前記ファイルと前記ファイル情報と前記識別子を紐付けて保存する保存手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていると判断した場合に、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であるか否かを判断する第２の判断手段と、
前記第２の判断手段が、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であると判断した場合に、前記受信手段が受信した前記ファイルは保存されていることを示す情報を通知する通知手段と、を有することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はファイルを保存する情報処理装置、システム、プログラム及び制御方法に関するものである。
【背景技術】
【０００２】
従来、データを受信後に受信したデータを記憶するか又は記憶せずにエラー終了する技術が存在する。
【０００３】
特許文献１はデータを受信後に、ディレクトリが存在しない場合はディレクトリを作成して受信したデータを記憶して、ディレクトリが存在する場合はデータを記憶せずにエラー終了する技術を開示している。
【０００４】
また、サーバーコンピューター側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）という技術が存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１１２７９９
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前述のクラウドコンピューティングシステムにおいてもファイルの扱いについて課題が生じる可能性がある。
【０００７】
例えば単一のサーバーやクラウドコンピューティングシステムで用いられる、ファイルとファイルに関連するファイル情報を受信するシステムを想定する。想定したシステムは例えば、クライアントからファイルを受信して、クライアントへファイルの正常保存通知を行うといったユースケースで利用することが考えられる。このシステムではファイル情報に基づいてファイルは保存されていないと判断した場合に、ファイルを保存して、ファイルが保存されていることを示す情報を通知する。一方で例えばファイルの上書き等を防ぐ目的で、想定したシステムではファイル情報に基づいてファイルは保存されていると判断した場合にエラー通知を行う。
【０００８】
ここで例えば次のような場合に、想定したシステムにおいて意図せずエラー通知が行われてしまう。すなわち、ファイルとファイル情報を受信後にファイルの送信元と接続ができなくなると、ファイルを保存後にファイルは保存されていることを示す情報を通知できない。その後、送信元がファイルは保存されていることを示す情報を得られないことで、リトライとして再度同じファイルとファイル情報を送信する。これにより、想定したシステムは再度同じファイルとファイル情報を受信する。この場合、想定したシステムは再度受信したファイルとファイル情報は既に保存しているため、エラー通知を行う。その結果例えば、送信元はファイルが保存できていることが把握できず、その先の処理に進むことができない。
【０００９】
一方で特許文献１はファイルとファイルに関連するファイル情報を受信することについても、またファイルが保存されていることを示す情報を通知することも開示していない。さらに、特許文献１はディレクトリが存在する場合にエラー終了してしまうため、前述の想定したシステムと同様の課題が生じる虞があった。
【００１０】
本発明の目的は、前述のように例えばファイルの送信元と接続ができなくなって、再度ファイルを受信したとしても、ファイルが保存されていることを示す情報を通知することを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するための本発明に係る情報処理装置は、
ファイルと、前記ファイルに関連するファイル情報と、識別子を受信する受信手段と、
前記ファイル情報に基づいて前記ファイルが保存されているか否かを判断する第１の判断手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていないと判断した場合に、前記ファイルと前記ファイル情報と前記識別子を紐付けて保存する保存手段と、
前記判断手段が前記ファイル情報に基づいて前記ファイルは保存されていると判断した場合に、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であるか否かを判断する第２の判断手段と、
前記第２の判断手段が、前記保存手段が保存した前記識別子と前記受信手段が新たに受信した前記識別子が同一であると判断した場合に、前記受信手段が受信した前記ファイルは保存されていることを示す情報を通知する通知手段と、を有することを特徴とする。
【発明の効果】
【００１２】
本発明により、前述の課題で説明したように例えばファイルの送信元と接続ができなくなって、再度ファイルを受信したとしても、ファイルが保存されていることを示す情報を通知することができる。
【図面の簡単な説明】
【００１３】
【図１】実施例１におけるクラウドシステムの全体構成を示す図である。
【図２】実施例１におけるクライアント端末、サーバーコンピューターのハードウェア構成図である。
【図３】実施例４における初期データを保存する際の処理のシーケンスを表す図である。
【図４】実施例１における画像形成装置のハードウェア構成の詳細を示す図である。
【図５】実施例１におけるスキャンサービスサーバーのソフトウェア構成図である。
【図６】実施例１におけるタスクサービスサーバーのソフトウェア構成図である。
【図７】実施例１における実施例におけるスキャン処理の一連のシーケンス図である。
【図８】実施例１におけるフローサービスサーバー群のシステム構成図の概要である。
【図９】例外が発生するファイル保存のシーケンスを表した図である。
【図１０】例外が発生するファイル保存のシーケンスを表した図である。
【図１１】実施例４におけるジョブ管理サービスサーバーにて保持するジョブ情報の一例である。
【図１２】実施例１におけるジョブ管理サービスサーバーのソフトウェア構成図である。
【図１３】実施例４における初期データを保存する際の処理のフローチャートである。
【図１４】実施例１におけるファイル管理サービスサーバー群の全体構成を示す図である。
【図１５】実施例１におけるファイル管理サービスサーバー群のソフトウェア構成である。
【図１６】実施例１におけるファイルサーバー情報、ファイルパス情報の一例である。
【図１７】実施例１における一時ファイルを保存する際の処理のフローチャートである。
【図１８】実施例１における一時ファイルを保存する際の処理のシーケンスを表す図である。
【図１９】実施例２におけるファイルパス情報へのエントリの登録処理のフローチャートである。
【発明を実施するための形態】
【００１４】
クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。さらに本明細書ではクラウドコンピューティングの特徴を生かすため、サーバーでの一連の処理を細かく規定されたタスクの連結で実現し、それらを同時並行で処理することで、多数のジョブをスケーラブルに処理する方法について検討する。
【００１５】
ここでタスクとは、本明細書において、ジョブを構成する処理内容又は処理内容を実現するためのソフトウェア上のプロセスを意味する。
【００１６】
この際、ジョブ処理機構において、先頭のタスクが処理するべき一時ファイルや、各タスクにて処理された結果生成される一時ファイルは、可用性確保のために複数のファイルサーバーにレプリケーションを作成することが考えられる。
【００１７】
１つ以上のタスクから構成されるジョブと、前記ジョブに関する情報や実行順序などを制御するジョブ管理サービスサーバーを想定する。各タスクはそれぞれ複数のインスタンスを立ち上げることが可能であり、各インスタンスは非同期でジョブ管理サービスサーバーからジョブを取得し、例えば黒点除去などの画像処理や共有フォルダへのデータ格納処理などを行う。各タスクで扱うバイナリデータはファイル管理サービスサーバー群にて管理し、各タスクは必要に応じて処理すべきデータをファイル管理サービスサーバー群から取得し、処理結果を保存する。本明細書では、ジョブ管理サービスサーバーにジョブを投入するアプリケーションをサービスアプリケーションと呼ぶ。
【００１８】
サービスアプリケーションは、ジョブ管理サービスサーバーに対してジョブを投入すると同時に処理すべきデータをファイル管理サービスサーバー群に投入する。この、ジョブ投入と同時にファイル管理サービスサーバー群に投入されるデータを、本明細書では初期データと呼ぶ。また、データはファイルに含まれる情報である。
【００１９】
初期データは保存後にデータを取り出すことができるように、また誤ってデータが上書きされて削除されることを防ぐために上書きを禁止する。これによって、上書きされて初期データが誤って失われることを防止する。初期データが誤って失われないことで、サーバーに障害等が発生した場合でも、初期データを取り出すことができれば、初期データに基づいて処理を再開することにより、システムの可用性向上に寄与する。また、複数のファイルサーバーに初期データを保存することで可用性はさらに向上する。
【００２０】
そして、ファイルサーバーに保存されている初期データを含むファイルの情報は別途データベースにて管理する。このような上書き禁止のファイル保存ＡＰＩに対してファイル保存の処理を行った際に、サーバー側からファイルが既に存在するために例外（エラー）が発生する。アプリケーションはサーバーの例外の発生によってアプリケーションが行った指示が適切に行われたのか判断を行う。すなわち、例外はその後のアプリケーションの処理に影響するため適切に発生することが望ましい。次の２つのケースを通して例外の発生すべき場合について検討する。最初のケースではシステムが想定していない処理が行われた場合に発生する。
【００２１】
１つ目としてクライアントが既に保存したファイルと全く同一のファイルを第３者が保存しようとした場合に例外が発生するケースについて説明する。
【００２２】
本ケースを図１０のシーケンスを用いて詳細に説明する。図１０において、アプリケーションサーバー９０１は、ファイル管理サービスサーバー群８０３の機能の１つであるＷｅｂアプリケーション部１５０１に対してファイル保存リクエストを行う。そして、既にアプリケーションサーバー９０１が保存したファイルと同一のファイルを、第３者アプリサーバー１００１が、Ｗｅｂアプリケーション部１５０１に対してファイル保存リクエストを行う場合を考える。
【００２３】
なお、以降の説明でファイル管理サービスサーバー群８０３と記載した場合、その機能は単体のサーバー又は単体の仮想サーバーによって実現しても構わないし、あるいは複数のサーバーや複数の仮想サーバーによって実現しても構わない。
【００２４】
また、Ｗｅｂアプリケーション部１５０１に対して保存されたファイル情報（詳細は後述する）はＤＢ部１５３０にて管理し、ファイルはデータ格納領域部１５４１に格納されているものとする。
【００２５】
Ｓ１０１１のデータ保存リクエストにて、アプリケーションサーバー９０１は保存したいファイルのバイナリデータとファイル情報をＷｅｂアプリケーション部１５０１に送信する。データ保存リクエストを受けてＷｅｂアプリケーション部１５０１は、Ｓ９１２にて、ＤＢ部１５３０に既に同一エントリが存在するかどうかの問い合わせを行う。
【００２６】
なお本明細書では、ファイルを管理するデータベース（ここではＤＢ部１５３０）にて管理するファイル情報をエントリと呼ぶ。
【００２７】
続いてＳ９１３でＤＢ部１５３０はエントリ無しの応答を返却する（エントリ有りの場合の処理はここでは省略する）。次に、Ｗｅｂアプリケーション部１５０１は、Ｓ９１４にてデータ格納領域部１５４１にファイル書込を行う。そして、Ｗｅｂアプリケーション部１５０１はＳ９１６でＤＢ部１５３０にエントリを追加して、Ｓ９１７で応答を取得する。Ｓ１０１８で、Ｗｅｂアプリケーション部１５０１は正常保存応答をアプリケーションサーバー９０１に返却する。
【００２８】
その後、第３者アプリサーバー１００１は、Ｗｅｂアプリケーション部１５０１に対してＳ１０１１と同じファイルとファイル情報でデータ保存リクエストＳ１０２０を行う。データ保存リクエストを受けて、Ｗｅｂアプリケーション部１５０１は、Ｓ１０２２にてＤＢ部１５３０に対して、既に同一エントリがあるかどうかの問い合わせを行う。このとき、Ｓ９１６にてＤＢにエントリが書き込まれているので、ＤＢ部１５３０はエントリ有りの応答Ｓ１０２３を返却する。従って、Ｗｅｂアプリケーション部１５０１は、データ保存リクエストＳ１０２０を、既にエントリが存在するファイルに対する上書きリクエストと判定し、Ｓ１０３１にて例外を発生する。
【００２９】
本ケースのようにアプリケーションサーバー９０１によって送信され既に保存されたファイルの上書きを禁止したい場合は、上記のようにファイルの上書きを防ぐために第３者アプリサーバー１００１のデータ保存リクエストに対して例外が発生する。これによって、意図せずファイルが上書きされてしまうことを防ぐことができる。
【００３０】
２つ目は、サーバー側でファイルを保存中にクライアント−サーバー間の通信がタイムアウトし、サーバー側で処理が継続して正常保存できたにも関わらずクライアント側に応答が返らなかったため、クライアントがリトライ処理を行ったケースである。本ケースでは例外が発生すべきではない場合にも関わらず、ケース１と同様に処理が行われてしまうことで、例外が発生してしまうケースである。
【００３１】
本ケースを図９のシーケンスを用いて詳細に説明する。
【００３２】
なお、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、説明を省略する。
【００３３】
Ｓ９１１の初回データ保存リクエストにて、アプリケーションサーバー９０１は保存したいファイルのバイナリデータとファイル情報をＷｅｂアプリケーション部１５０１に送信する。Ｓ９１２〜Ｓ９１７の処理の後、図９の例ではアプリケーションサーバー９０１とＷｅｂアプリケーション部１５０１間の接続がタイムアウトしてしまう。タイムアウトする原因としてはバイナリデータのファイルサイズが大きい場合やファイル管理サービスサーバー群８０３内のネットワークの転送速度が低速の場合に、タイムアウト時間よりも主にＳ９１４及びＳ９１６の処理の時間が長くなることにある。タイムアウトした結果、Ｗｅｂアプリケーション部１５０１は応答Ｓ９１８をアプリケーションサーバーに返却することができない。よって、アプリケーションサーバー９０１はＳ９１１で送信したファイルはファイル管理サービスサーバー群で保存されなかったものと判断して、アプリケーションサーバー９０１はＳ９２０にてデータ保存のリトライ処理を行う。
【００３４】
データ保存リクエストのリトライを受けて、Ｗｅｂアプリケーション部１５０１は、Ｓ９２１にてＤＢ部１５３０に対して、既に同一エントリがあるかどうかの問い合わせを行う。このとき、Ｓ９１６にてＤＢにエントリが書き込まれているので、ＤＢ部１５３０はエントリ有りの応答Ｓ９２２を返却する。従って、Ｗｅｂアプリケーション部１５０１は、データ保存リクエストＳ９２０を、既にエントリが存在するファイルに対する上書きリクエストと判定し、Ｓ９２３にて例外を発生して、処理が中断される。
【００３５】
しかし、このようなケースで例外が発生してしまうことで、アプリケーションサーバー９０１はデータ保存のリトライを行うたびに例外を受け取ってしまう。これによりアプリケーションサーバー９０１はファイルが正常に保存されたことをいつまで経っても把握することができない。
【００３６】
以降説明する実施例では、１つ目のケースでは例外を発生させつつ、２つ目のケースでは正常終了の応答を返すことで、発生すべき適切なタイミングで例外を発生させる。これによって、保存リクエストに対して望ましい応答をクライアント側に返却する。
【実施例１】
【００３７】
図１は、本発明の実施の形態に係るクラウドシステムの全体構成を示す図である。
【００３８】
図１において、スキャンサービスサーバー１０１、フローサービスサーバー群１０２、タスクサービスサーバー１０３〜１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー１０８は、ネットワーク１１０〜１１２を介して接続されている。図において、タスクサービスサーバー１０３〜１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー１０８は、複数台接続されていることを仮定している。ネットワーク１１０〜１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであり。またはこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１１０〜１１２は、データの送受信が可能であればよい。本明細書ではネットワーク１１０及び１１２はインターネット、ネットワーク１１１は企業内ネットワークやサービスプロバイダーのネットワークである。スキャンサービスサーバー１０１、フローサービスサーバー群１０２、タスクサービスサーバー１０３〜１０４は、サーバーコンピューター上にて仮想サーバーによって実行されており、これらサービスサーバー群がユーザーに対してクラウドサービスを提供する。また、クラウドサービスサーバー１０８はインターネット上に公開されており、クラウドサービスサーバー１０８もサーバーコンピューター上にて実行されている。
【００３９】
以降、本明細書で説明するサーバーのそれぞれの機能は単体のサーバー又は単体の仮想サーバーによって実現しても構わないし、あるいは複数のサーバーや複数の仮想サーバーによって実現しても構わない。あるいは複数のサーバーが仮想サーバーとして単体のサーバー上で実行されても構わない。
【００４０】
クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。
【００４１】
図２（Ａ）は、本発明の実施形態に係るクライアント端末１０６、各サービスサーバー１０１〜１０４、クラウドサービスサーバー１０８の各サーバー（情報処理装置）のハードウェア構成図である。
【００４２】
図２（Ａ）において、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はＨａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、Ｒａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービスサーバー群のプログラム、ＯＳ、関連プログラム等を格納している。ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ（ＮＩＣ）２０９は、該インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２（Ａ）の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００４３】
加えて、ＣＰＵ２０２がＨＤＤ２０５に記憶されているプログラムに基づき処理を実行することによって、図５等に示されるようなソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。
【００４４】
図２（Ｂ）は、本発明の実施形態に係るクライアント端末１０６のソフトウェア構成図である。図２（Ｂ）において、Ｗｅｂブラウザ３０１を利用し、スキャンサービスサーバー１０１が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザーはクライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。
【００４５】
図４は、本発明の実施形態に係る画像形成装置１０７のハードウェア構成を例示するブロック図である。本実施例ではスキャン・プリントの両機能を併せ持つ装置を例にするが、スキャンサービスを実現するに当たっては、プリント機能のない、スキャン専用装置でも良い。
【００４６】
図４において、画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、およびスキャンユニット４０３から構成される。画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザーインターフェース４０７、外部インターフェース４０８から構成されている。
【００４７】
ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示するユニットである。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ４０４が実行するプログラムは直接記憶部４０５にロードされる。直接記憶部４０５は、ＲＡＭにより実現される。間接記憶部４０６は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部４０６に記憶されている各種プログラムは、ＣＰＵ４０４がプログラムを実行する際に直接記憶部４０５へ移動する。間接記憶部４０６は、Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ（ＳＳＤ）、または、ＨＤＤにより実現される。なお、ＣＰＵ４０４はマルチプロセッサでも良い。
【００４８】
ここで、プラットフォームプログラムによって実現されるプラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できる他、画像形成装置１０７の操作画面をカスタマイズすることが可能になる。
【００４９】
プラットフォームの実現方法について説明する。ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了するとＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。本発明の実施例では、ＣＰＵ４０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００５０】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例において、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバー１０１より、例えば、Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）と言った通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。ユーザーはスキャンソフトウェア部にて表示されたスキャンチケット一覧より、スキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部はユーザーが選択したスキャンチケットの情報とスキャンした画像データを合わせてスキャンサービスサーバー１０１に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。
【００５１】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例で開示するフローチャートの各処理の一部を行うことが可能である。
【００５２】
図４の説明に戻る。ユーザーインターフェース４０７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、タッチパネル、キーボード又はマウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別筐体のホストコンピュータや画像形成装置等の別筐体の装置が含まれる。画像形成装置１０７は、ネットワーク１１０及び１１１を介して、クライアント端末１０６、スキャンサービスサーバー１０１と通信可能である。
【００５３】
続いて、クラウドサービスを提供するスキャンサービスサーバー１０１、タスクサービスサーバー１０３〜１０４の各サービスサーバー群に関して説明する。
【００５４】
図５を用いて、スキャンサービスサーバー１０１に関して説明する。スキャンサービスサーバー１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスである。図５は、本発明の実施形態に係るスキャンサービスサーバー１０１のソフトウェア構成図である。スキャンサービスサーバー１０１は、Ｗｅｂアプリケーション部５０１、ファイル保存ライブラリ部５０２からなる。これら構成要素により各種処理が実行されることでスキャンサービスサーバー１０１がユーザーに提供される。
【００５５】
Ｗｅｂアプリケーション部５０１はスキャン機能を提供するアプリケーションプログラムを提供する。チケット作成部５１１はユーザーがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメーター等が記録されている。
【００５６】
外部Ｉ／Ｆ５１４は画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。スキャンソフトウェア部より、外部Ｉ／Ｆ５１４を通じて、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを行う。
【００５７】
ファイル保存ライブラリ部５０２は、フローサービスサーバー群にデータを保存する際に使用するライブラリである。詳細は後述する。
【００５８】
スキャン受信部５１３は、送信されたスキャンチケット、および画像データを受信した後、ファイル保存部５２１に対して画像データを送信する。
【００５９】
図７を用いてスキャンジョブの投入までの流れを説明する。まずはスキャン処理についてスキャンチケットの作成とスキャンジョブの投入までの流れを説明する。
【００６０】
図７にて、チケット作成部５１１は、クライアント端末１０６のＷｅｂブラウザ３０１からのスキャンチケット作成画面リクエストＳ７０１を受け取り、スキャンチケット作成画面を生成しレスポンスＳ７０２を行う。ユーザーがクライアント端末１０６のＷｅｂブラウザ３０１にて操作を行い、スキャンチケット作成リクエストＳ７０３を行うことで、スキャンチケット作成と作成したスキャンチケットのチケット管理部５１５への保存を依頼する。チケット管理部５１５は、チケット情報を保存した後、レスポンスＳ７０４を行う。
【００６１】
図７にて、画像形成装置１０７のスキャンソフトウェア部は外部Ｉ／Ｆ５１４を通じてチケット一覧部５１２に対して、チケット一覧取得Ｓ７０５を行う。チケット一覧部５１２では、スキャンチケットの一覧をチケット管理部５１５より生成し、スキャンソフトウェア部にレスポンスＳ７０６を返す。レスポンスを受け取った画像形成装置１０７は、取得したチケット一覧を図４におけるユーザーインターフェース４０７上に表示する。
【００６２】
図７のスキャン処理Ｓ７０７にて、ユーザーは、ユーザーインターフェース４０７上に表示されたチケットのいずれかを選択し、画像形成装置に備え付けられたスキャン装置に紙を設置し、スキャン実行する。これにより、スキャンソフトウェア部は、スキャン送信Ｓ７０８にて、外部Ｉ／Ｆ５１４を通じてスキャン受信部５１３に対して、スキャンした画像データとスキャンチケットの送信を行う。
【００６３】
データ保存Ｓ７１４にて画像データをフローサービスサーバー群１０２に投入する。データ保存Ｓ７１４において、ファイル保存部５２１は、画像データと共に、セッションＩＤ発行部５２２にて発行されるＳｅｓｓｉｏｎＩＤを含むファイル情報をフローサービスサーバー群１０２に投入する。
【００６４】
ＳｅｓｓｉｏｎＩＤとはセッションごとに発行される識別子であり、Ｓ７１４でデータ保存が行われる度に接続には毎回異なる識別子が使われる。
【００６５】
ファイル情報については後述する。これによってフローサービスサーバー群１０２のファイル管理サービスサーバー群８０３はファイル（本実施例では画像データ）とファイルに関連するファイル情報を受信する。データ保存Ｓ７１４において、ファイル保存部５２１とフローサービスサーバー群１０２との通信がタイムアウト等の原因で失敗した場合は、ファイル情報のＳｅｓｓｉｏｎＩＤとしては前回と同一のＳｅｓｓｉｏｎＩＤを用いてリトライ処理を行う。しかし、リトライ処理の接続のＳｅｓｓｉｏｎＩＤとしては初回接続時のＳｅｓｓｉｏｎＩＤとは異なるものを用いても構わない。
【００６６】
本実施例においてリトライ処理は３回行う。また、図７においては省略するが、データ保存Ｓ７１４が３回失敗した場合は、画像形成装置に対して失敗通知を行い、処理を終了する。フローサービスサーバー群１０２は、画像データを正しく受信できた場合には、Ｓ７１５にてスキャンサービスサーバー１０１に、画像データを一意に表すＩＤ（ファイルグループＩＤ）を応答する。その後、スキャン受信部５１３は、ジョブ投入リクエストＳ７１６にて、ファイルグループＩＤ、スキャンチケット、テナントＩＤをフローサービスサーバー群１０２に送信する。ここでテナントＩＤとはジョブを投入したユーザーが属するテナントを表す、テナントに対して一意のＩＤである。
【００６７】
以上がスキャンサービスサーバー１０１のシステム構成と、スキャンジョブの投入までの流れである。
【００６８】
引き続き、図６にて、本発明の実施形態に係るタスクサービスサーバー１０３〜１０４のソフトウェア構成図を説明する。各タスクサービスサーバー群は、スキャンサービスを実現するための要素機能を実現するサービスサーバー群である。例えば画像データ対して画像処理を行うタスクサービスサーバーや、ファイル共有機能を提供するような他のクラウドサービスサーバー１０８に対して、画像データを送信する処理を行うタスクサービスサーバーが存在する。本実施例においては、タスクサービスサーバー１０３は、画像データに対してＯＣＲ処理を行いＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。タスクサービスサーバー１０４は、クラウドサービスサーバー１０８の中のストレージ機能を提供する特定のサービスに対して、画像データをアップロードし保管する処理を行う。
【００６９】
以下、図７のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行う。
【００７０】
タスクサービスサーバー１０３〜１０４のタスク取得部６１１は、Ｓ７１７、Ｓ７２９にて、定期的にフローサービスサーバー群１０２に問い合わせを行い、タスクサービスサーバー１０３〜１０４にて処理可能なタスクを取得する。タスクサービスサーバー１０３〜１０４のデータ取得部６１２は、タスク取得部６１１で取得したジョブ情報を元に、Ｓ７１９、Ｓ７３１にてフローサービスサーバー群１０２より処理すべき画像・文書データの取得を行う。タスクサービスサーバー１０３〜１０４のタスク処理部６１５は、取得した画像データに対してＳ７２５、Ｓ７３７にて各種処理を行う。データ保存部６１３はＳ７２５にて処理したデータをＳ７２７にてフローサービスサーバー群１０２に保存する。
【００７１】
タスクサービスサーバー１０４のタスク処理部６１５は、Ｓ７３７での処理結果をＳ７３８にてクラウドサービスサーバー１０８にデータ送信する。
【００７２】
タスクサービスサーバー１０３〜１０４のタスクステータス通知部６１４は一連のタスク処理の終了結果をＳ７２８、Ｓ７３９にて、フローサービスサーバー群１０２に通知する。
【００７３】
以上で、スキャンジョブの一連の処理が完了する。
【００７４】
続いて、フローサービスサーバー群１０２の詳細な説明を行う。フローサービスサーバー群１０２は本発明における中心的なサービスサーバー群であり、ルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバー群である。
【００７５】
図８は、フローサービスサーバー群１０２のシステム構成の概要である。
【００７６】
フローサービスサーバー群１０２は、ルート管理サービスサーバー８０１、ジョブ管理サービスサーバー８０２、ファイル管理サービスサーバー群８０３の各サーバーからなる。これらサービスサーバー上により各種処理が実行されることで各サービスが提供され、それらが連携することで、フローサービスがユーザーに提供される。
【００７７】
ルート管理サービスサーバー８０１はタスクとタスクを連結させたルートの情報を管理する。ジョブ管理サービスサーバー８０２はルートの情報に基づきジョブの処理を管理する。ファイル管理サービスサーバー群８０３はジョブ投入時のデータや各タスクの処理結果のデータを保存・管理する。
【００７８】
続いてフローサービスサーバー群１０２を構成するジョブ管理サービスサーバー８０２、ファイル管理サービスサーバー群８０３について詳細な説明を行う。
【００７９】
図１２を用いて、ジョブ管理サービスサーバー８０２のソフトウェア構成に関して説明する。ジョブ管理サービスサーバー８０２は、タスクサービスサーバー１０３〜１０４からのリクエストに対してタスク情報の授受や、各タスクの状態を管理するためのサービスサーバーである。
【００８０】
外部Ｉ／Ｆ部１２０１は、タスクサービスサーバー１０３〜１０４、およびスキャンサービスサーバー１０１との通信を行う。外部Ｉ／Ｆ部１２０１を通じて、ジョブ管理サービスサーバー８０２の各機能へのアクセスを行う。ジョブ情報管理ＤＢ部１２０２は、作成された各ジョブのステータスや、各ジョブが扱うデータのＩＤを管理する。ジョブ追加部１２０３は、スキャンサービスサーバー１０１が、図７において、外部Ｉ／Ｆ部１２０１を通じて発行されるジョブ投入リクエストＳ７１６を受け、ジョブ情報管理ＤＢ部１２０２に、ジョブ情報を格納する。ここで、ジョブ情報とは、ジョブ情報管理ＤＢ部１２０２に存在する各ジョブに紐づく情報のことである。ジョブ情報取得部１２０４は、タスクサービスサーバー１０３〜１０４から外部Ｉ／Ｆ部１２０１を通じて発行されるタスク取得リクエストＳ７１７、Ｓ７２９を受け、ジョブ情報管理ＤＢ部１２０２から、ジョブ情報を取得する。ここで取得したジョブ情報は、レスポンス７１８及びＳ７３０にてタスクサービスサーバー１０３〜１０４に渡される。ジョブ情報更新部１２０５は、結果通知Ｓ７２８及びＳ７３９にて、タスクサービスサーバー１０３〜１０４から、外部Ｉ／Ｆ部１２０１を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理ＤＢ部１２０２の該ジョブの情報を更新する。
【００８１】
続いて、図１４、図１５、図１６、図１７を用いて、ファイル管理サービスサーバー群８０３について説明する。
【００８２】
図１４はファイル管理サービスサーバー群８０３の全体構成を示す図である。図１４においてファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３はネットワーク１４１０を介して接続されている。ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３のサーバー数は自然数であればいくつでもよい。また、ネットワーク１４１０はネットワーク１１０と接続されている。ネットワーク１４１０はネットワーク１１０と同様のデータの送受信が可能な通信ネットワークである。
【００８３】
なお、ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３は１台又は複数台のサーバーコンピューター上にて仮想サーバーとして実行されていてもよい。１台のサーバーコンピューター上で仮想サーバーとして実行される場合、ネットワーク１４１０はサーバーコンピューター上のシステムバスによって実現される。
【００８４】
続いて、一時ファイル管理機能を提供するファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３について図１５、図１６、図１７を用いて説明する。
【００８５】
図１５は、本発明の実施形態に係る、ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３のソフトウェア構成図である。ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３はＷｅｂアプリケーション部１５０１、バックエンド部１５０２、ＤＢ部１５３０、データ格納領域部１５４１からなる。ＤＢ部１５３０はファイル管理サービスサーバー管理ＤＢ部１５３１、パス管理ＤＢ部１５３２を含む。これらの構成要素により各種処理が実行されることでサービスを行う。
【００８６】
ファイル管理サービスサーバー管理ＤＢ部１５３１は、ファイルの格納先であるファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３に関する情報を管理する。
【００８７】
図１６（Ａ）にファイル管理サービスサーバー管理ＤＢ部１５３１で管理するデータの例を示す。ＩＤ１６０１は、ファイル管理サービスサーバーをファイル管理サービスサーバー群８０３内で一意に識別するための情報である。ホスト名１６０２は、ネットワーク１４１０上におけるファイル管理サービスサーバーの一意のアドレスを示す。アクティブフラグ１６０３は、ホスト名１６０２に存在するファイル管理サービスサーバーとの通信の可否を示す真偽値であり、通信可能な場合はＴｒｕｅ、通信不可能な場合はＦａｌｓｅを取る。共有フォルダ名１６０４はファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３上に存在するフォルダである。データ格納領域部１５４１は共有フォルダ名１６０４が指すフォルダのことを示す。
【００８８】
パス管理ＤＢ部１５３２はファイル管理サービスサーバー群８０３で管理している、ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３のデータ格納領域部１５４１に保存された一時ファイルに関する情報をエントリとして管理する。
【００８９】
一時ファイルとは、スキャンサービスサーバー１０１から保存される初期データと、タスクサービスサーバー１０３〜１０４の処理の結果生成されるファイルを指す。
【００９０】
図１６（Ｂ）にパス管理ＤＢ部１５３２で管理するエントリの例を示す。
【００９１】
ファイルＩＤ１６１０は、ファイル管理サービスサーバーＡ１４０１…Ｘ１４０３でエントリを一意に識別するための情報である。
【００９２】
ファイルグループＩＤ１６１１は各エントリを関連するジョブでグループ化するための情報である。従って、同一ジョブによって生成されたエントリは同一のファイルグループＩＤ１６１１を持つ。タスクＩＤ１６１２は各エントリに対応する一時ファイルに関連するタスクを識別するタスクＩＤ、または初期データを表す「ｉｎｉｔ」のいずれかの値が入る。Ｎｏ１６１３は各タスクによって生成された一時ファイルのファイル番号を示す。本実施例ではＮｏ１６１３はスキャンサービスサーバー１０１によって任意の番号が付与される。
【００９３】
パス１６１４は各エントリに対応する一時ファイルの格納先のフルパスを示し、Ｗｅｂアプリケーション部１５０１がバックエンド部１５０２を通じてエンティティにアクセスする際に使用する。ホスト名１６１５は各エントリに対応する一時ファイルの格納先のファイル管理サービスサーバーのホスト名を示す。作成日１６１６は一時ファイルをデータ格納領域部１５４１に格納し終わった時間を示す。有効期限１６１７は一時ファイルの有効期限を示し、有効期限１６１７を過ぎたエントリに対応する一時ファイルは削除される。テナントＩＤ１６１８は一時ファイルを保存したユーザーが所属するテナントのテナントＩＤを示す。ＳｅｓｓｉｏｎＩＤ１６１９はファイル保存時に用いられたＳｅｓｓｉｏｎＩＤを示す。例えば、データ保存Ｓ７１４にてスキャンサービスサーバー１０１が発行したＳｅｓｓｉｏｎＩＤが格納される。
【００９４】
続いて、Ｗｅｂアプリケーション部１５０１が持つ各機能について説明する。
【００９５】
上書き禁止ファイル保存部１５１１はスキャンサービスサーバー１０１からのリクエストに応じてファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３内のデータ格納領域部１５４１にファイルを上書き禁止で多重化して保存する機能を実現する。スキャンサービスサーバーからのリクエストにはパス管理ＤＢ部１５３２のエントリとして管理されるタスクＩＤ１６１２、Ｎｏ１６１３、有効期限１６１７、テナントＩＤ１６１８、ＳｅｓｓｉｏｎＩＤ１６１９など保存するファイルに関連する情報を含む。また、スキャンサービスサーバー１０１は、上書き禁止ファイル保存部１５１１に対してリクエストを行う際に、通信エラー等の例外が発生した場合は、リトライ処理を行うことができる。
図７のＳ７１４の処理で前述したように、スキャンサービスサーバー１０１はセッションＩＤ発行部５２２にて発行したＳｅｓｓｉｏｎＩＤを含むファイル情報と一時ファイルからなるリクエストを上書き禁止ファイル保存部１５１１に対して送信する。上書き禁止ファイル保存部１５１１は、ファイル保存リクエストを受け取るとバックエンド部１５０２内の上書き判断処理部１５２２に対してファイル情報を送信する。
【００９６】
図１７のフローチャートを用いて、以降の処理を説明する。上書き判断処理部１５２２はＳ１７０１で、パス管理ＤＢ部１５３２にファイル情報が同一であるエントリが存在するかどうかを確認する。ファイル情報が同一とは具体的にはファイルグループＩＤ１６１１とタスクＩＤ１６１２とＮｏ１６１３の３つの項目の値が完全一致する場合である。なお、これ以外の項目の値によってファイル情報が同一であるか否かを判断しても構わない。例えばファイルグループＩＤ１６１１とタスクＩＤ１６１２によってファイル情報が同一であると判断しても構わない。Ｓ１７０２でファイル情報が同一のエントリが存在しないと判断された場合、上書き禁止ファイル保存部１５１１は、ファイル保存処理部１５２１を呼び出し、Ｓ１７０３でデータ格納領域部１５４１に対してファイル書込を行う。次にファイル保存処理部１５２１は、Ｓ１７０４でパス管理ＤＢ部１５３２に対してエントリを追加する。エントリには受信したファイル（パス１６１４）とＳｅｓｓｉｏｎＩＤ１６１９が紐付けられて保存される。次に上書き禁止ファイル保存部１５１１は、Ｓ１７０６で正常保存通知をスキャンサービスサーバー１０１に対して応答する。正常保存通知はファイルが正常に保存されていることを示す通知である。
【００９７】
Ｓ１７０２でファイル情報が同一のエントリが存在した場合、上書き判断処理部１５２２はＳ１７０５にて同一エントリをパス管理ＤＢ部１５３２から取得する。上書き判断処理部１５２２はＳ１７０７でリクエスト中のファイル情報に含まれるＳｅｓｓｉｏｎＩＤと、Ｓ１７０５にて取得したエントリに含まれるＳｅｓｓｉｏｎＩＤ１６１９が一致するかどうかを確認する。Ｓ１７０７にてＳｅｓｓｉｏｎＩＤが一致した場合、既にリクエストに含まれるファイルが保存済と判断し、上書き禁止ファイル保存部１５１１はＳ１７０６にて正常保存通知をスキャンサービスサーバー１０１に対して応答する。Ｓ１７０７にてＳｅｓｓｉｏｎＩＤが一致しない場合、上書き禁止ファイル保存部１５１１はリクエストを上書きリクエストと判断して、Ｓ１７０８にて例外を発生させる。そして、スキャンサービスサーバー１０１は例外が発生したことを示す情報を取得する。
【００９８】
図１８を用いて、図１７の処理を用いた結果、スキャンサービスサーバー１０１が上書き禁止ファイル保存部１５１１に対してデータ保存を行うシーケンスを、初回リクエスト時と初回リクエスト以降に分けて説明する。簡潔に説明するために、ファイル保存処理部１５２１は省略する。
【００９９】
最初にスキャンサービスサーバー１０１は上書き禁止ファイル保存部１５１１に対してデータ保存リクエストＳ１８０１を行い、このデータ保存リクエストＳ１８０１を受けて、上書き禁止ファイル保存部は、上書き判断処理部１５２２に対して上書き判断処理Ｓ１８０２を行う。上書き判断処理部１５２２はＳ１８０３にて、データ保存リクエストＳ１８０１に含まれるファイル情報と同一のエントリが既にパス管理ＤＢ部に存在するかどうかを確認し、Ｓ１８０５の判断結果を応答する。
【０１００】
ケース１８４１・１８４２はデータ保存リクエストＳ１８０１が初回のデータ保存リクエストであった場合に、Ｓ１８０５の結果によって起こりうる処理の流れを示したものである。
【０１０１】
ケース１８４１はＳ１８０５の判断結果がエントリ無しであった場合の処理の流れを示したものである。ケース１８４１は、データ保存リクエストＳ１８０１が上書きリクエストでない場合に該当する。従って、上書き禁止ファイル保存部１５１１は、ファイル書込Ｓ１８０６にてデータ格納領域部１５４１に対してファイルを書き込み、ＤＢ書込処理Ｓ１８０８にてパス管理ＤＢ部１５３２に対してエントリを書き込んだ後、スキャンサービスサーバー１０１に対して正常保存通知の応答Ｓ１８１０を返却する。
【０１０２】
ケース１８４２はＳ１８０５の判断結果がエントリ有り、ＳｅｓｓｉｏｎＩＤ不一致であった場合の処理の流れを示したものである。ケース１８４２は、データ保存リクエストＳ１８０１が上書きリクエストである場合に該当する。従って、上書き禁止ファイル保存部１５１１は、Ｓ１８１１にてファイルが既に存在する例外を発生させる。ケース１８４２は図１０においてデータ保存リクエストＳ１０２０が行われたケースと同じである。すなわち、ケース１８４２の初回リクエストとは保存する当事者（図１０であれば第３者アプリサーバー１００１）にとってそのリクエストが初回であることを意味している。
【０１０３】
なお、初回リクエストの場合にエントリ有りでＳｅｓｓｉｏｎＩＤ一致のケースは存在しない。これは例えば、既に存在しているエントリのＳｅｓｓｉｏｎＩＤを第３者アプリサーバー１００１などが取得することはできない。よって、第３者アプリサーバー１００１などが既に存在しているエントリのＳｅｓｓｉｏｎＩＤをファイル情報のＳｅｓｓｉｏｎＩＤに指定できず、ＳｅｓｓｉｏｎＩＤが一致しないことためである。
【０１０４】
ケース１８４３〜１８４５はデータ保存リクエストＳ１８０１が初回リクエスト以降のデータ保存リクエストであった場合にＳ１８０５の結果によって起こりうる処理の流れを示したものである。
【０１０５】
ケース１８４３はＳ１８０５の判断結果がエントリ無しであった場合の処理の流れを示したものである。本ケースは例えば初回リクエスト時に正常にエントリが作成されず、リトライを行う場合が該当する。本ケースでは、上書き禁止ファイル保存部１５１１は、ファイル書込Ｓ１８２１にてデータ格納領域部１５４１に対してファイルを書き込む。次に上書き禁止ファイル保存部１５１１は、ＤＢ書込処理Ｓ１８２３にてパス管理ＤＢ部１５３２に対してエントリを書き込んだ後、スキャンサービスサーバー１０１に対して正常保存通知の応答Ｓ１８２５を返却する。
【０１０６】
ケース１８４４はＳ１８０５の判断結果がエントリ有り、ＳｅｓｓｉｏｎＩＤ一致であった場合の処理の流れを示したものである。ケース１８４４は、前回までの保存リクエストで既に保存したいファイルが保存完了している場合に該当する。従ってケース１８４３とは異なり、上書き禁止ファイル保存部１５１１は、ファイル保存処理を行わずに正常保存通知の応答Ｓ１８２６をスキャンサービスサーバー１０１に対して返却する。本明細書の冒頭で図９を用いてデータ保存リクエストＳ９２０にて例外が発生してしまう問題について説明した。図９のデータ保存リクエストＳ９２０は、初回データ保存リクエストＳ９１１のリトライ処理であり、ファイルの保存とエントリの作成はＳ９１４〜Ｓ９１７にて正常に終了しているので、Ｓ９２３にて例外が発生するのは望ましくない。図１７の処理に従うことでＳ１８２６にて正常保存の応答をスキャンサービスサーバー１０１に返却することができる。
【０１０７】
ケース１８４５はＳ１８０５の判断結果がエントリ有り、ＳｅｓｓｉｏｎＩＤ不一致であった場合の処理の流れを示したものである。ケース１８４５は、データ保存リクエストＳ１８０１が上書きリクエストである場合に該当する。従って、上書き禁止ファイル保存部１５１１は、Ｓ１８３１にてファイルが既に存在する例外を発生させる。そして、スキャンサービスサーバー１０１は例外が発生したことを示す情報を取得する。本ケース１８４５は、例えば第３者アプリサーバー１００１がケース１８４２後も再度データ保存リクエストを行う場合が該当する。
【０１０８】
上記のケース１８４１〜１８４５のように、図１７に従って処理を行うことで望ましい正常保存通知と例外発生を行うことができる。
【０１０９】
図１５の説明に戻る。次に上書き許容ファイル保存部１５１４について説明する。上書き許容ファイル保存部１５１４はタスクサービスサーバー１０３〜１０４からのリクエストに応じてファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３内のデータ格納領域部１５４１にファイルを多重化して保存する機能を実現する。上書き許容ファイル保存部１５１４と上書き禁止ファイル保存部１５１１は、パス管理ＤＢ部１５３２にエントリが存在する場合に、ファイル及びエントリの上書きを許可するか禁止するかのみ異なる。タスクサービスサーバー１０３〜１０４から上書き許容ファイル保存部１５１４に対するリクエストには、スキャンサービスサーバー１０１から上書き禁止ファイル保存部１５１１に対するリクエスト同様、ファイル情報と一時ファイルのバイナリデータを含む。また、上書き許容ファイル保存部１５１４の場合、ＳｅｓｓｉｏｎＩＤ１６１９はファイル情報に含んでも含まなくてもよい。
【０１１０】
上書き許容ファイル保存部１５１４は、タスクサービスサーバー１０３〜１０４からリクエストを受け取ると、ファイル保存処理部１５２１にリクエストを転送する。ファイル保存処理部１５２１はデータ格納領域部１５４１に対してファイル書込又はファイル更新を行った後、パス管理ＤＢに対してエントリを追加又はエントリを更新し、最後に正常保存通知を呼出元のタスクサービスサーバー１０３〜１０４に対して応答する。
【０１１１】
ファイル取得処理部１５２３は、ファイル取得部１５１２を介して、タスクサービスサーバー１０３〜１０４からファイル取得リクエストを受け付ける。ファイル取得処理部１５２３は、ファイル取得リクエストを受け付けると、パス管理ＤＢ部１５３２からリクエストに含まれるファイル情報に対応するエントリを検索する。ファイル取得処理部１５２３は、リクエストに対応するエントリがパス管理ＤＢ部１５３２上に存在した場合、対応する一時ファイルをデータ格納領域から取得し、ファイル取得部１５１２を介して呼出元のタスクサービスサーバー１０３〜１０４に一時ファイルを返却する。
【０１１２】
本実施例１による効果は、上書き禁止ファイル保存部１５１１に対する要求が、初回保存リクエストなのかリトライ保存リクエストなのかに関わらず、望ましい応答をクライアント側に返却できる点にある。
【実施例２】
【０１１３】
実施例１において、スキャンサービスサーバー１０１のファイル保存部５２１から上書き禁止ファイル保存部１５１１に対する初回リクエストがタイムアウトしたにも関わらず、ファイル保存処理部１５２１からデータ格納領域部１５４１に対するファイル保存処理は継続している場合を考える。
【０１１４】
ファイル保存部５２１は、初回リクエストがタイムアウトしたため、初回リクエストと同様のＳｅｓｓｉｏｎＩＤをファイル情報に含めて、再び上書き禁止ファイル保存部１５１１に対してリトライリクエストを行う。このとき初回リクエストに対応するファイルの、ファイル保存処理部１５２１からデータ格納領域部１５４１への書込が継続しているため、書込先のファイルは書込ロックされているものとする。従ってリトライリクエストに対応するファイルの、ファイル保存処理部１５２１からデータ格納領域部１５４１への書込はファイルが既に書込ロックされているため失敗する。その結果、リトライリクエストが失敗するという課題が存在する。
【０１１５】
本実施例における、ファイル保存処理部１５２１からデータ格納領域部１５４１に対する一時ファイル保存処理の流れ、すなわち図１７のＳ１７０３で示される処理の流れを説明する。まず、ファイル保存処理部１５２１は、ファイル保存リクエストに対して一意の文字列（以降Ｐｏｓｔｆｉｘと呼ぶ）を発行する。次にファイル保存処理部１５２１は、前記Ｐｏｓｔｆｉｘを末尾に付与したファイル名で、データ格納領域に１５４１に一時ファイルを保存する。これによって既存のファイル名と新たに保存するファイル名が重複しないように一時ファイルを保存することができる。続いて、ファイル保存処理部１５２１は、パス管理ＤＢ部１５３２に対してファイル情報をエントリとして追加する。既にリクエストに含まれるファイル情報と同一のファイル情報がパス管理ＤＢ部１５３２上に存在する場合は、エントリを上書きする。ここでのファイル情報のファイル名にはＰｏｓｔｆｉｘが含まれる。
【０１１６】
本実施例による効果は、ファイル名の末尾にＰｏｓｔｆｉｘを付与することで、ファイルが書込ロックされていることが原因でリトライリクエストが失敗するということがなくなる。
【０１１７】
なお、本実施例ではファイル名の末尾にＰｏｓｔｆｉｘを付与したが、ファイル名がリクエストに対して一意になれば文字列をどこに付与しても構わない。
【実施例３】
【０１１８】
実施例２において、パス管理ＤＢ部１５３２への追加時にリクエストに含まれるファイル情報と同一のエントリが既に存在する場合は、エントリを上書きする。このようにエントリが上書きされることで、上書き前のエントリに対応する一時ファイルがエントリから参照されない形でデータ格納領域部１５４１内に不要なファイルとして残ってしまい、データ格納領域部１５４１の容量を圧迫する。
【０１１９】
そこで本実施例では、パス管理ＤＢ部１５３２のエントリを上書きする前に、上書き前のエントリに対応する一時ファイルをデータ格納領域部１５４１から削除する。図１９を用いて、本実施例における、ファイル保存処理部１５２１がパス管理ＤＢ部１５３２に対してエントリを追加する処理の流れを説明する。
【０１２０】
ファイル保存処理部１５２１はＳ１９０１にて、リクエストに含まれるファイル情報と同一のエントリが既にパス管理ＤＢ部１５３２上に存在するかを確認する。Ｓ１９０１にて、該当するエントリが存在しない場合、ファイル保存処理部１５２１は、パス管理ＤＢ部１５３２にエントリを新規追加する。Ｓ１９０１にて該当するエントリが存在する場合、ファイル保存処理部１５２１は、Ｓ１９１０にて該当する既存のエントリを取得し、Ｓ１９１１にてＯｌｄＥｎｔｒｙに代入する。次に、ファイル保存処理部１５２１は、パス管理ＤＢ部１５３２の既存エントリに新しいエントリを上書きし、ＯｌｄＥｎｔｒｙに紐づくファイルをデータ格納領域部１５４１から削除する。
【０１２１】
実施例３によってエントリから参照されないファイルを削除することができ、データ格納領域部１５４１の容量を節約することができる。
【実施例４】
【０１２２】
第１〜第３の実施例は、スキャンサービスサーバー１０１からファイル管理サービスサーバー群８０３に対して初期データを保存する場合を考えた。本実施例では、タスクからファイル管理サービスサーバー群８０３に対して初期データを保存する場合を考える。タスクから初期データを保存する例として、スキャンサービスサーバー１０１が外部サービスに対してスキャンデータを保存しておき、後で第１〜第３の実施例にて説明した画像処理が必要になった時にジョブ管理サービスサーバー８０２に対してジョブのみを投入するケースが考えられる。ここで投入されるジョブには、スキャンデータを外部サービスから取得してファイル管理サービスサーバー群８０３に保存するタスク、及びタスクサービスサーバー１０３、１０４にて実行されるタスクを順に実行するようなルートが指定される。本実施例ではスキャンデータを外部サービスから取得してファイル管理サービスサーバー群に保存するタスクをファイル保存タスクサービスサーバー２１４０と呼ぶ。
【０１２３】
第１〜第３の実施例においては、データ保存Ｓ７１４はスキャンサービスサーバー１０１が行った。その際に例えば、初回リクエストとリトライ処理をスキャンサービスサーバー１０１が両方同一プロセスで行うことが考えられる。同一プロセスで行う場合、初回リクエスト時のファイル情報のＳｅｓｓｉｏｎＩＤをプロセス内の処理で記憶しておき、リトライ処理のファイル情報のＳｅｓｓｉｏｎＩＤとして用いる。これによって、初回保存リクエストとリトライリクエストで同一のＳｅｓｓｉｏｎＩＤ１６１９を用いることができた。その結果、Ｓ１７０７にて上書き禁止ファイル保存部１５１１に対するリトライリクエストと、上書きリクエストを区別し、応答を切り替えることができた。
【０１２４】
一方、各タスクはファイルの保存に失敗した場合、各タスク個別に設定されるリトライ回数上限値に基づいてタスクのリトライを実行する。各タスクは、処理失敗時にジョブ管理サービスサーバー８０２に対して失敗通知をし、ジョブ管理サービスサーバー８０２に制御を一旦戻す。そのため、１回目のタスク実行（初回リクエスト時）と２回目のタスク実行（リトライ時）で異なるプロセスで処理が行われる可能性がある。その結果、リトライ時のファイルリクエストと初回リクエストでファイル情報のＳｅｓｓｉｏｎＩＤには異なるＳｅｓｓｉｏｎＩＤが用いられるか、あるいはＳｅｓｓｉｏｎＩＤが用いられない可能性がある。その結果、上書き禁止ファイル保存部１５１１に対するリトライリクエストと、上書きリクエストを区別出来ないため、正しい応答をクライアントに返却することができない。
【０１２５】
そこで実施例４では、ジョブ管理サービスサーバー８０２にて、ジョブとＳｅｓｓｉｏｎＩＤを紐付けて管理する。
【０１２６】
図１３のフローチャートを用いて、ファイル保存タスクサービスサーバー２１４０からファイル管理サービスサーバー群８０３に対して初期データを保存する流れを説明する。まずファイル保存タスクサービスサーバー２１４０が、Ｓ２１０１でジョブ管理サービスサーバー８０２に対してジョブ取得要求を出すと、ジョブ管理サービスサーバー８０２がＳ２１０２で対象のジョブを応答する。図１１に、本実施例におけるジョブ情報管理ＤＢ部１２０２で管理するデータの例を示す。
【０１２７】
ファイル保存タスクサービスサーバー２１４０は、前記取得したジョブのＳｅｓｓｉｏｎＩＤ２００１がＮｕｌｌなのかどうかを判定する。ＳｅｓｓｉｏｎＩＤ２００１がＮｕｌｌの場合はまだ当該ＳｅｓｓｉｏｎＩＤ２００１が発行されていないことを意味する。Ｓ２１１０にてジョブのＳｅｓｓｉｏｎＩＤ２００１がＮｕｌｌであった場合に、ファイル保存タスクサービスサーバー２１４０は、Ｓ２１１１にてＳｅｓｓｉｏｎＩＤを発行し、Ｓ２１１２にてジョブ管理サービスサーバー８０２に対してＳｅｓｓｉｏｎＩＤ２００１の更新要求を行う。ＳｅｓｓｉｏｎＩＤの更新要求を受けたジョブ管理サービスサーバー８０２は、Ｓ２１１３にてジョブ情報管理ＤＢ部１２０２のＳｅｓｓｉｏｎＩＤ２００１を更新する。
【０１２８】
次にＳ２１２０にてファイル保存タスクサービスサーバー２１４０はファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３の上書き禁止ファイル保存部１５１１に対して上書き禁止ファイル保存リクエストを出す。Ｓ２１２０のリクエストに含めるＳｅｓｓｉｏｎＩＤ１６１９は、Ｓ２１１０にてＳｅｓｓｉｏｎＩＤ２００１がＮｕｌｌだった場合はＳ２１１１にて発行した文字列、Ｎｕｌｌでなかった場合にはＳｅｓｓｉｏｎＩＤ２００１の文字列を用いる。このようにジョブ情報管理ＤＢ部１２０２にてＳｅｓｓｉｏｎＩＤ２００１の情報を管理することで、ファイル保存タスクサービスサーバー２１４０の各プロセスにて共通のＳｅｓｓｉｏｎＩＤを用いることができる。
【０１２９】
上書き禁止ファイル保存処理Ｓ２１２１では図１７と同一の処理が行われる。その際、図１７のＳ１７０１のファイル情報の同一の判断には実施例１と同じくファイルグループＩＤ１６１１とタスクＩＤ１６１２とＮｏ１６１３の３つの項目の値が用いられる。この中でタスクＩＤ１６１２については初回保存リクエストとリトライリクエストでタスクが異なっていたとしても同一のタスクＩＤが用いられる。これにより図１７のＳ１７０１でリトライリクエストのファイル情報は初回保存リクエストのファイル情報と同一であると判断され、Ｓ１７０２ではエントリが有ると判断される。
【０１３０】
Ｓ２１２１の完了後、ファイル保存タスクサービスサーバー２１４０は、Ｓ２１３０にて保存処理が正常に完了したかどうかを判定する。Ｓ２１３０にて保存処理が正常に完了していた場合、ファイル保存タスクサービスサーバー２１４０はＳ２１２２にて、ジョブ管理サービスサーバー８０２に対してタスク完了通知を行う。ジョブ管理サービスサーバー８０２は、タスク完了処理Ｓ２１２３にてジョブ情報管理ＤＢ部１２０２の現在のタスクＩＤを示すカレントタスクＩＤ１３０４を次のタスクに更新する。
【０１３１】
Ｓ２１３０にて保存処理が失敗していた場合、ファイル保存タスクサービスサーバー２１４０はＳ２１３１にて、ジョブ管理サービスサーバー８０２に対してタスクの失敗通知を行う。ジョブ管理サービスサーバー８０２は、タスク失敗処理Ｓ２１３２にてタスクのリトライ回数を示すカレントタスクリトライ回数１３１１をインクリメントする。
【０１３２】
図３のシーケンスを用いて、ファイル保存タスクサービスＡサーバー２２０１及びＢサーバー２２０２からファイル管理サービスサーバー群８０３に対して初期データを保存する流れを具体的に説明する。ファイル保存タスクサービスＡサーバー２２０１及びＢサーバー２２０２は図１３のファイル保存タスクサービスサーバー２１４０と同じ機能を持ち、処理結果ファイルを初期データとしてファイル管理サービスサーバー群８０３に対して保存するタスクサービスサーバーである。図３のシーケンスは、ある１つのタスクに対して、ファイル保存タスクサービスＡサーバー２２０１が初回タスク処理を行い、初期データの保存に失敗した場合に、ファイル保存タスクサービスＢサーバー２２０２がリトライタスク処理を行う場合の処理の流れを示したものである。
【０１３３】
まず、ファイル保存タスクサービスＡサーバー２２０１はジョブ管理サービスサーバー８０２に対してタスク取得リクエストＳ２２１１を行い、ジョブ管理サービスサーバー８０２はファイル保存タスクサービスＡサーバー２２０１の処理対象のタスクをＳ２２１２にて応答する。ファイル保存タスクサービスＡサーバー２２０１は、タスク処理Ｓ２２１３を行い、タスク処理Ｓ２２１３の結果生成されるファイルを初期データとしてファイル管理サービスサーバー群８０３に対して保存する。
【０１３４】
タスク処理Ｓ２２１３は初回タスク処理であるため、ジョブ管理サービスサーバー８０２からの応答Ｓ２２１２に含まれるジョブ情報の一要素であるＳｅｓｓｉｏｎＩＤ２００１はＮｕｌｌである。従って、ファイル保存タスクサービスＡサーバー２２０１は、Ｓ２２１４にてＳｅｓｓｉｏｎＩＤ発行し、ジョブ管理サービスサーバー８０２に対してＳｅｓｓｉｏｎＩＤ登録リクエストＳ２２１５を行う。ジョブ管理サービスサーバー８０２は、ジョブ情報管理ＤＢ部１２０２のＳｅｓｓｉｏｎＩＤ２００１に、Ｓ２２１４にて発行されたＳｅｓｓｉｏｎＩＤを登録してＳ２２１６を応答する。
【０１３５】
ＳｅｓｓｉｏｎＩＤのジョブ情報管理ＤＢ部１２０２への登録が完了した後、ファイル保存タスクサービスＡサーバー２２０１及びＢサーバー２２０２は、上書き禁止ファイル保存部１５１１に対して、初期データ保存リクエストＳ２２２１を行う。初期データ保存リクエストＳ２２２１を受けた、上書き禁止ファイル保存部１５１１は、Ｓ２２２２〜Ｓ２２２９にて図１８のＳ１８０２〜Ｓ１８０９と同様のファイル保存処理を行い、正常保存通知の応答Ｓ２２３０を、ファイル保存タスクサービスＡサーバー２２０１に返却しようとする。しかし、ファイル保存処理に時間がかかったため、ファイル保存タスクサービスＡサーバー２２０１とファイル管理サービスサーバー群８０３との間の接続がタイムアウトした場合、正常保存通知の応答Ｓ２２３０を返却することができない。
【０１３６】
従って今度は、ファイル保存タスクサービスＢサーバー２２０２がジョブ管理サービスサーバー８０２に対してタスク取得リクエストＳ２２３１を行い、ジョブ管理サービスサーバー８０２はファイル保存タスクサービスＢサーバー２２０２の処理対象のタスクをＳ２２３２にて応答する。ファイル保存タスクサービスＢサーバー２２０２は、タスク処理Ｓ２２３３を行い、タスク処理Ｓ２２３３の結果生成されるファイルを初期データとしてファイル管理サービスサーバー群８０３に対して保存する。
【０１３７】
タスク処理Ｓ２２３３はリトライタスク処理であるため、ジョブ管理サービスサーバー８０２からの応答Ｓ２２１２に含まれるＳｅｓｓｉｏｎＩＤ２００１はＳ２２１４にてファイル保存タスクサービスＡサーバー２２０１が発行したＳｅｓｓｉｏｎＩＤがセットされている。従って、ファイル保存タスクサービスＢサーバー２２０２は、このＳｅｓｓｉｏｎＩＤを用いて初期データ保存リクエストＳ２２３４を上書き禁止ファイル保存部１５１１に対して行う。
【０１３８】
初期データ保存リクエストＳ２２３４を受けた、上書き禁止ファイル保存部１５１１は、Ｓ２２３５〜Ｓ２２３８にて図１８のＳ１８０２〜Ｓ１８０５の判断結果がエントリ無しとなる場合と同様の上書き判断処理を行う。判断結果Ｓ２２３８はエントリ有り、ＳｅｓｓｉｏｎＩＤ一致の場合、すなわち図１８におけるケース１８４４に相当するので、上書き禁止ファイル保存部１５１１は正常保存通知の応答Ｓ２２３９をファイル保存タスクサービスＢサーバー２２０２に対して返却する。
【０１３９】
なお、本実施例では、初回のタスク処理Ｓ２２１３とリトライ時のタスク処理Ｓ２２３３はそれぞれ別のファイル保存タスクサービスサーバーが行ったが、同じファイル保存タスクサービスサーバーが行なっても良い。複数のファイル保存タスクサービスサーバーが存在することで、一方のファイル保存タスクサービスサーバーが停止しても、他方のファイル保存タスクサービスサーバーが処理を継続することができ、可用性が向上する。
【０１４０】
実施例４によって、タスクから上書き禁止ファイル保存部１５１１に対して初期データ保存リクエストを行った場合も、ファイル管理サービスサーバーＡ１４０１〜Ｘ１４０３から常に正しい応答が得られる。
【０１４１】
なお、本実施例で説明したファイル保存タスクサービスサーバー２１４０とジョブ管理サービスサーバー８０２とファイル管理サービスサーバー群８０３は単体のサーバー上で仮想サーバーとして実行されてもよい。
【０１４２】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。
【０１４３】
即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2014241009.tif 000003
【図２】
2014241009.tif 000004
【図３】
2014241009.tif 000005
【図４】
2014241009.tif 000006
【図５】
2014241009.tif 000007
【図６】
2014241009.tif 000008
【図７】
2014241009.tif 000009
【図８】
2014241009.tif 000010
【図９】
2014241009.tif 000011
【図１０】
2014241009.tif 000012
【図１１】
2014241009.tif 000013
【図１２】
2014241009.tif 000014
【図１３】
2014241009.tif 000015
【図１４】
2014241009.tif 000016
【図１５】
2014241009.tif 000017
【図１６】
2014241009.tif 000018
【図１７】
2014241009.tif 000019
【図１８】
2014241009.tif 000020
【図１９】
2014241009.tif 000021