JP6732508B2 - データを保存するシステム、サーバー、方法、及びプログラム - Google Patents

Description

本発明は、ストレージサービスを利用して画像データを保存する技術に関する。

ストレージサービスはインターネットを活用したサービスの１つであり、インターネット上の仮想ストレージにファイルを保存し、ＰＣ、スマートフォン、タブレット等の様々な端末からの該保存したファイルへの共有アクセスを可能にするサービスである。ストレージサービスは、ファイルをアップロード可能なデータ容量が定められている。一般的なストレージサービスでは、空き容量の不足が原因でデータを保存できなかった場合、データを保存できなかった旨を示すエラーがユーザーに通知される。エラーが通知されたユーザーは、例えば不要なファイルを削除することで、必要な空き容量を確保し、データを保存し直す必要がある。

上述の問題に対処する手法として、特許文献１は、ユーザーが容量制限を超えて画像をアップロードした場合に、一定期間はサーバー上に画像データを保管し続け削除までの猶予を与える技術を開示する。

特開２０１０−０４４４６８号公報

しかしながら、特許文献１に記載の方法では、サーバーに保存されているデータがユーザーの知らぬ間に削除される恐れがあった。

そこで本発明は、データのアップロードに失敗した場合でも該データが消失することを防ぎ、かつ、保存されているデータがユーザーの知らぬ間に削除されることを防ぐことができるシステムを提供することを目的とする。

本発明は、データをストレージサーバーにアップロードするサービスのためのシステムであって、原稿を読み取る読取部を備える読取装置が、当該読取部により原稿を読み取ることで取得された画像データであって、当該読取装置から送信された画像データの、前記ストレージサーバーへのアップロードを試みるアップロード手段と、前記アップロードに失敗した場合、前記画像データを、前記サービスにログイン中のユーザーに対応付けて保存する保存手段と、前記保存手段が前記画像データを保存する場合に、前記ユーザーに、前記アップロードの失敗に関する所定の通知を行う通知手段と、を有し、前記アップロード手段は、前記読取装置による原稿読取をユーザーが指示し、かつ、前記保存手段が当該ユーザーに対応付けて前記画像データを保存していることに基づいて、当該画像データの前記ストレージサーバーへのアップロードを再び試みることを特徴とするシステムである。

本発明により、データのアップロードに失敗した場合でも該データが消失することを防ぎ、かつ、保存されているデータがユーザーの知らぬ間に削除されることを防ぐことができる。

実施例１に係るＭＦＰの概略構成を示すブロック図 実施例１に係るクライアント及びサーバーとして用いられるＰＣの概略構成を示すブロック図 実施例１に係るシステムの構成を示す図 実施例１に係るクライアントが実行する処理のフローチャート 実施例１に係るクライアントが表示するＵＩ 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係るスキャンチケット 実施例１に係るＭＦＰが実行する処理のフローチャート 実施例１に係る情報処理サーバーが一時的に保存するデータを説明するための図 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係る情報処理サーバーが実行する処理のフローチャート 実施例１に係るシステムが実行する処理のシーケンスチャート

以下、添付図面を参照して本発明の実施形態を詳しく説明する。ただし、以下の実施形態は例示に過ぎず、特許請求の範囲に係る本発明を限定するものではない。また、以下で説明されている特徴の組み合わせの全てが、本発明の解決手段として必須のものとは限らない。なお、各図面において同一の要素には同一の符号を付与する。

＜実施例１＞
まず図１〜図３を用いて、本実施例で用いる複合機能画像形成装置（以下ＭＦＰ）、クライアント及びサーバーとして用いられるＰＣ、及びこれらが接続されて構成されるシステムについて説明する。

（ＭＦＰの構成について）
図１は、本実施例に係る画像形成装置の一例であるＭＦＰの概略構成を示すブロック図である。ＭＦＰ１００は、プリンタ部１０１と、スキャナ部１０２と、メモリカード装着部１０３とを備える。ＭＦＰ１００は、プリンタ部１０１によって実現されるプリンタ機能と、スキャナ部１０２によって実現されるスキャン機能と、メモリカード装着部１０３に装着するメモリカード１０４によって実現されるストレージ機能とを有する。これらの機能は、ＭＦＰ１００を実際に触って操作するユーザーに提供されるが、ネットワーク接続部１１１を介してネットワーク経由でユーザーに提供することも可能である。

プリンタ部１０１は、ＭＦＰ１００に接続されている外部装置から受信した印刷ジョブに含まれる印刷データやメモリカード１０４に格納されている画像データ等に基づき、記録媒体に画像を形成する。画像を形成する方式として、インクジェット方式や電子写真方式等、ＭＦＰ１００に応じた任意の方式を用いて良い。スキャナ部１０２は、原稿台にセットされた原稿を光学的に読み取って電子データを取得し、該取得した電子データを指定されたファイル形式に変換する。ＭＦＰ１００は、指定されたファイル形式に変換された電子データを、ネットワーク経由で外部装置に送信する。或いはＭＦＰ１００は、該電子データを、ＭＦＰ１００内のフラッシュメモリ１１２や、ＭＦＰ１００に装着されたメモリカード１０４等の記憶媒体に保存しても良い。ＭＦＰ１００を使ったコピーサービスでは、原稿台に置かれた原稿をスキャナ部１０２が読み取ることで生成された画像データはプリンタ部１０１へ送信され、プリンタ部１０１が該送信された画像データに基づき記録媒体に画像を形成する。本実施例では、メモリカード１０４に格納されているファイルを、ＭＦＰ１００と接続された外部装置がネットワーク経由で読み出すこと、読み出したファイルを編集すること、編集後のファイルをメモリカード１０４に保存すること等が可能である。

またＭＦＰ１００は、中央演算装置（以下ＣＰＵ）１０５と、プログラムメモリ１０６と、ワークメモリ１０７と、表示部１０８と、操作部１０９とを備える。ＣＰＵ１０５は、信号線１１３を介して接続されたＭＦＰ１００の各構成要素を統括的に制御する。プログラムメモリ１０６は、後述する情報処理サーバーと通信するためのクライアントアプリケーション１１４等、ＣＰＵ１０５が実行するプログラムを格納するための不揮発性メモリである（例えばＲＯＭ）。なお、ＣＰＵ１０５が実行するプログラムには、後述する本実施例に係る処理を実行するためのプログラムも含まれる。ワークメモリ１０７は、各処理実行時に生じる画像データ等を一時的に格納するための揮発性メモリであり（例えばＲＡＭ）、バッファリング等に用いられる。表示部１０８は、ユーザーに情報を視認可能に提示するための手段である（例えばＬＣＤ）。操作部１０９は、ユーザーによる入力を受け付けるための手段であり、ボタン、タッチパネル、スイッチ等を含む。

更にＭＦＰ１００は、ネットワーク通信部１１０と、ネットワーク接続部１１１と、フラッシュメモリ１１２とを備える。ネットワーク通信部１１０は、ＭＦＰ１００をネットワークに接続して各種通信を行うための手段であり、有線ＬＡＮと無線ＬＡＮとの少なくとも一方に対応する。ネットワーク接続部１１１は、ネットワーク通信部１１０をネットワーク媒体に接続するための手段である。ネットワーク通信部１１０が有線ＬＡＮに対応する場合、ネットワーク接続部１１１は、有線ＬＡＮのＬＡＮケーブルをＭＦＰ１００に接続するためのコネクタである。一方、ネットワーク通信部１１０が無線ＬＡＮに対応する場合、ネットワーク接続部１１１はアンテナである。フラッシュメモリ１１２は、ネットワーク通信部１１０が受信したデータを格納するための、不揮発性メモリである。

（クライアント及びサーバーとして用いられるＰＣの構成について）
図２は、本実施例に係るクライアント及びサーバーとして用いられるＰＣの概略構成を示すブロック図である。ＰＣ２００は、ＣＰＵ２１２と、ディスク装置２０２と、外部ディスク読取装置２０３と、メモリ２０４と、表示部２０５と、操作部２０６と、ネットワーク通信部２０７と、ネットワーク接続部２０８と、ＵＳＢ通信部２１０と、ＵＳＢ接続部２１１とを備える。

ＣＰＵ２１２は、信号線２０９を介して接続されたＰＣ２００の各構成要素を統括的に制御する。ディスク装置２０２は、各種ファイルを格納するための装置であり（例えばＨＤＤ）、ＣＰＵ２１２によって実行されるアプリケーションプログラムやＯｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ（以下ＯＳ）などがインストールされている。外部ディスク読取装置２０３は、マウントされた記憶媒体（ＣＤ−ＲＯＭ等）の内容を読み出すための装置である。メモリ２０４は、ＣＰＵ２１２が必要に応じて生成したデータを一時的に格納するための揮発性メモリであり（例えばＲＡＭ）、バッファリング等に用いられる。表示部２０５は、ユーザーに情報を視認可能に提示するための手段である（例えばＣＲＴやＬＣＤ等）。操作部２０６は、ユーザーによる入力を受け付けるための手段であり、キーボード、マウス等を含む。ネットワーク通信部２０７は、ＰＣ２００をネットワークに接続して各種通信を行うための手段である。ネットワーク接続部２０８は、ネットワーク通信部２０７をネットワーク媒体に接続するための手段である。ＭＦＰ１００と同様に、ＰＣ２００のネットワーク通信部２０７及びネットワーク接続部２０８は、有線ＬＡＮと無線ＬＡＮとの少なくとも一方に対応する。ＵＳＢ通信部２１０は、画像形成装置などの各種外部装置とＵＳＢインターフェースを介して通信するための手段である。ＵＳＢ接続部２１１は、ＰＣ２００にＵＳＢを接続するための手段である（例えばＵＳＢコネクタ）。

（ネットワークの構成について）
図３は、本実施例に係るクライアント・サーバー型のストレージサービスを実現可能なシステムのネットワーク構成を示す図である。図示するようにシステムは、ＭＦＰと、クライアントと、情報処理サーバーと、ストレージサーバーとから構成されている。システムを構成するこれらの装置は、インターネット３５０を介して接続されており、インターネット３５０を介して互いにデータをやり取りすることが可能である。

図３において、ＭＦＰ１５０はＭＦＰ１００と同様の機能を有するＭＦＰである。クライアント２０１及びクライアント２５０は、クライアント用ＯＳがインストールされたＰＣである。情報処理サーバー３００、情報処理サーバー３０１、及び情報処理サーバー３０２は、情報処理サーバー用ＯＳがインストールされたＰＣである。ストレージサーバー４００及びストレージサーバー４０１は、ストレージサービスでファイルをアップロードするために用いられるＰＣである。図３に示すクライアント、情報処理サーバー、及びストレージサーバーとして、図２を用いて説明したＰＣ２００を用いることが可能である。なおここでは、図示するように、２台のＭＦＰと、２台のクライアントと、３台の情報処理サーバーと、２台のストレージサーバーとから構成されたシステムについて説明しているが、これらの装置の台数は本例に限定されず任意に変更して良い。

以下、図３に示したシステムにより実現される本実施例に係るストレージサービスにおける処理について説明する。具体的には、クライアント２０１におけるユーザーの入力がトリガーとなって、情報処理サーバー３００がＭＦＰ１００に原稿読取を実行させ、該読取により得た画像データを情報処理サーバー３０１がストレージサーバー４００にアップロードする処理である。なお以下では、情報処理サーバー３００と情報処理サーバー３０１とが夫々異なる処理を実行する場合について説明するが、１個のサーバーで、情報処理サーバー３００と情報処理サーバー３０１とが実行する処理をまとめて実行しても良い。

（クライアントが実行する処理について）
図４は、本実施例に係るクライアント２０１が実行する処理のフローチャートである。本処理は、クライアント２０１で立ち上げたアプリケーション上で、ユーザーがストレージサービスを利用した原稿読取を指示すると開始する。

ステップＳ１０１（以下Ｓ１０１と略記し、他のステップも同様に略記する。）において、クライアント２０１は、原稿読取に関するユーザー側で設定可能な条件及び保存先候補を問い合わせるためのクエリーを、情報処理サーバー３００に送信する。Ｓ１０２において、クライアント２０１は、Ｓ１０１で送信したクエリーに対する応答として、原稿読取に関するユーザー側で設定可能な条件及び保存先候補を含む情報を、情報処理サーバー３００から受信する。Ｓ１０３において、クライアント２０１は、Ｓ１０２で情報処理サーバー３００から受信した情報に基づくＵＩ（ユーザインターフェース）を作成し、表示部２０５に表示する。図５に、Ｓ１０３でクライアント２０１が表示するＵＩの例を示す。図示するようにＵＩ５０１は、読取詳細設定部５０２と、保存先指定部５０３と、読取開始ボタン５０４とを有する。ユーザーは、読取詳細設定部５０２を介して読取に関する詳細な条件を設定し、保存先指定部５０３を介して画像データの保存先を指定して、読取開始ボタン５０４を押下する。

Ｓ１０４において、クライアント２０１は、読取開始ボタン５０４が押下されたか否かを判定する。Ｓ１０４の判定の結果、読取開始ボタン５０４が押下された場合、Ｓ１０５に進む一方、読取開始ボタン５０４が押下されていない場合、ユーザーが読取開始ボタン５０４を押下するまで待つ。Ｓ１０５において、クライアント２０１は、ＵＩ５０１を介してユーザーが設定した内容に基づく原稿読取要求を、情報処理サーバー３００に送信する。Ｓ１０６において、クライアント２０１は、Ｓ１０５で送信した原稿読取要求に対応する原稿読取応答を、情報処理サーバー３００から受信する。

Ｓ１０７において、クライアント２０１は、Ｓ１０６で受信した原稿読取応答が原稿読取の受託を示すか否かを判定する。Ｓ１０７の判定の結果、原稿読取応答が原稿読取の受託を示す場合、一連の処理は終了する一方、原稿読取応答がエラーを示す場合、Ｓ１０８に進む。Ｓ１０８において、クライアント２０１は、表示部２０５にエラーメッセージを表示し、一連の処理は終了する。Ｓ１０８で表示するエラーメッセージは常に同一でも良いし、エラーの内容に応じて異なるエラーメッセージを表示しても良い。例えば、原稿読取応答が、前回の読取時にアップロードに失敗した画像データが残っていることが原因でスキャンできないことを示すとする。この場合、クライアント２０１は「前回の読取時に画像データのアップロードに失敗しました。この画像データがアップロードされるまではスキャンできません。空き領域を確保してからリトライしてください。」といったメッセージを表示しても良い。図４に示す一連の処理が終わった時点で、クライアント２０１における読取に関するジョブは終了する。これにより、クライアント２０１としてマルチタスク不可の物を用いている場合、ユーザーは、クライアント２０１上で他の操作を実行できるようになる。以上が、本実施例に係るクライアント２０１が実行する処理の内容である。

（情報処理サーバー３００が実行する処理について）
図６は、Ｓ１０１でクライアント２０１により送信されたクエリーを受信する情報処理サーバー３００が、該クエリーに対応する情報をクライアント２０１に送信する際に実行する処理のフローチャートである。Ｓ２０１において、情報処理サーバー３００は、Ｓ１０１でクライアント２０１が送信した、原稿読取に関するユーザー側で設定可能な条件及び保存先候補を問い合わせるためのクエリーを受信する。Ｓ２０２において、情報処理サーバー３００は、データベースに格納されているリストを参照し、ユーザーが利用するストレージサービスに対応する、原稿読取に関するユーザー側で設定可能な条件、及び、保存先候補を含む情報を取得する。なおここで情報処理サーバー３００が参照するリストは、情報処理サーバー３００自身が保有する。また、該リストには、ストレージサービス毎の、原稿読取に関する設定可能な条件及び保存先候補が保持されているため、情報処理サーバー３００は、原稿読取の設定に関する情報をＭＦＰの機種別に管理する必要は無い。Ｓ２０３において、情報処理サーバー３００は、Ｓ２０２で取得した原稿読取に関するユーザー側で設定可能な条件及び保存先候補を含む情報を、クライアント２０１に送信する。

図７は、Ｓ１０５でクライアント２０１により送信された原稿読取要求を受信する情報処理サーバー３００が、原稿読取要求に対応する原稿読取応答を送信する際に実行する処理のフローチャートである。Ｓ３０１において、情報処理サーバー３００は、Ｓ１０５でクライアント２０１が送信した原稿読取要求を受信する。Ｓ３０２において、情報処理サーバー３００は、Ｓ３０１で受信した原稿読取要求に従ってスキャンチケットを作成する。なお、スキャンチケットの詳細は後述する。

Ｓ３０３において、情報処理サーバー３００は、アップロードの準備ができているか否かを問い合わせるためのクエリーを、情報処理サーバー３０１に送信する。本ステップで送信するクエリーは、Ｓ３０２で作成したスキャンチケットを含んで良く、また情報処理サーバー３０１は、ＭＦＰ１００での読み取りにより得た画像データを一時的に保存する機能を有する（詳細は後述する）。Ｓ３０４において、情報処理サーバー３００は、Ｓ３０３で送信したクエリーに対する応答として、アップロードの準備ができているか否かを示す情報を、情報処理サーバー３０１から受信する。Ｓ３０５において、情報処理サーバー３００は、Ｓ３０４で受信した情報に基づき、アップロードの準備ができているか否かを判定する。Ｓ３０５の判定の結果、アップロードの準備ができている場合、Ｓ３０６に進む一方、アップロードの準備ができていない場合、Ｓ３１１に進む。

Ｓ３０６において、情報処理サーバー３００は、Ｓ３０２で作成したスキャンチケットを含む原稿読取ジョブを、ＭＦＰ１００に送信する。Ｓ３０７において、情報処理サーバー３００は、Ｓ３０６で送信した原稿読取ジョブに対する応答を、ＭＦＰ１００から受信する。Ｓ３０８において、情報処理サーバー３００は、Ｓ３０７で受信した応答に基づき、原稿読取ジョブの受付に成功したか否かを判定する。Ｓ３０８の判定の結果、原稿読取ジョブの受付に成功した場合、Ｓ３０９に進む一方、原稿読取ジョブの受付に失敗した場合、Ｓ３１１に進む。

Ｓ３０９において、情報処理サーバー３００は、クライアント２０１に送信する原稿読取応答に、原稿読取ジョブがＭＦＰ１００に登録されたことを示す情報（“成功”を示す値）をセットする。Ｓ３１０において、情報処理サーバー３００は、原稿読取応答をクライアント２０１に送信する。

一方、原稿読取ジョブが受け付けられなかった場合（Ｓ３０５又はＳ３０８でＮＯ）、Ｓ３１１において、情報処理サーバー３００は、原稿読取応答に、原稿読取ジョブがＭＦＰ１００に登録されなかったことを示す情報（“失敗”を示す値）をセットする。その後Ｓ３１０に進み、情報処理サーバー３００は、原稿読取応答をクライアント２０１に送信する。

Ｓ３１０で原稿読取応答をクライアント２０１に送信すると、一連の処理は終了し、ストレージサービスにおける情報処理サーバー３００の役割は終了する。以上が、本実施例に係る情報処理サーバー３００が実行する処理の内容である。

（スキャンチケットについて）
図８に、Ｓ３０２で作成するスキャンチケットの一例を示す。図示するようにスキャンチケット７０１は、読取設定保持部７０２と、機種情報保持部７０３と、画像処理設定保持部７０４と、アップロード情報保持部７０５とから構成されている。読取設定保持部７０２には、ＵＩ５０１を介してユーザーが設定した読取に関する詳細な条件（原稿の種類、サイズ等）が保持されている。機種情報保持部７０３には、情報処理サーバー３００のデータベースを参照することで取得可能なＭＦＰ１００に関する情報（機種名、読取機構の方式等）が保持されている。画像処理設定保持部７０４には、ＵＩ５０１を介してユーザーが設定した画像処理に関する詳細な条件（取得する画像データの形式等）が保持されている。アップロード情報保持部７０５には、ストレージサーバー４００へのアップロードに関する情報、及び、アップロードに失敗したときに実行されるリトライを制御するための情報が保持されている。本実施例では、ストレージサーバー４００へのアクセスは、情報処理サーバー３０１によってサポートされている。従って、ストレージサーバー４００にアクセスするために必要な情報（具体的にはストレージサービスにログインするためのユーザー名やパスワード等）を、アップロード情報保持部７０５で保持し、後続の処理で情報処理サーバー３０１が利用できるようにする。

アップロード情報保持部７０５の項目「Remain Retry Counter」は、アップロードをリトライする回数を示す。「Remain Retry Counter」の値は、アップロードのリトライが１回実行される毎に１減少し、「Remain Retry Counter」の値が０になるとアップロードのリトライが実行されなくなる。アップロード情報保持部７０５の項目「Retry Next Time」は、リトライを開始するタイミングを示す。即ち「Retry Next Time」の時刻以降の任意のタイミングで、アップロードのリトライが実行される。これにより、一定若しくは可変の時間を待ってからアップロードのリトライを実行するように実装することが可能となるので、頻繁なリトライが引き起こすネットワークトラフィックの悪化を防止することが可能となる。「Remain Retry Counter」の値が０になった場合、アップロード用に情報処理サーバー３０１で一時的に保存していた画像データやこれに付随するスキャンチケットは通常、ストレージ容量を解放するために削除される。その場合、情報処理サーバー３０１は、一時的に保存していた画像データを削除する旨を、メールやリアルタイムコミュニケーションツールなどでユーザーに告知し、ユーザーの承認を得てから画像データを削除するように実装しても良い。尚、情報処理サーバー３０１が許容できるのであれば、情報処理サーバー３０１で一時的に保存している画像データやこれに付随するスキャンチケットを、そのまま保存し続けても構わない。これにより、アイドルタイム時にバックグランドジョブとして画像データの再アップロードを実行させたり、または、ユーザーによって次のスキャン指示がなされた場合に、画像データの再アップロードを試みたりすることが可能となる。

（ＭＦＰが実行する処理について）
図９は、Ｓ３０６で情報処理サーバー３００により送信された原稿読取ジョブを受信するＭＦＰ１００が実行する処理のフローチャートである。

Ｓ４０１において、ＭＦＰ１００は、Ｓ３０６で情報処理サーバー３００が送信した原稿読取ジョブを受信する。上述の通り、本ステップで受信する原稿読取ジョブには、スキャンチケットが含まれる。Ｓ４０２において、ＭＦＰ１００は、Ｓ４０１で得たスキャンチケットを解析する。Ｓ４０３において、ＭＦＰ１００は、スキャンチケットの内容が正しいか否かを判定する。Ｓ４０３の判定の結果、スキャンチケットの内容が正しい場合、Ｓ４０４に進む一方、スキャンチケットの内容が正しくない場合、Ｓ４１０に進む。

Ｓ４０４において、ＭＦＰ１００は、Ｓ４０１で受信した原稿読取ジョブに対する応答を、情報処理サーバー３００に送信する。本ステップで送信する応答には、原稿読取ジョブの受付に成功した旨を示す情報が含まれる。Ｓ４０５において、ＭＦＰ１００は、スキャンチケット７０１の読取設定保持部７０２の内容に従って原稿の読取を行い、画像データを生成する。Ｓ４０６において、ＭＦＰ１００は、原稿の読取に成功したか否かを判定する。Ｓ４０６の判定の結果、読取に成功した場合、Ｓ４０７に進む一方、読取に失敗した場合、Ｓ４０９に進む。

Ｓ４０７において、ＭＦＰ１００は、Ｓ４０５での読取により得た画像データ、及び、該画像データに対応付けられているスキャンチケットを、情報処理サーバー３０１に送信する。なお、本ステップで画像データを送信する際、画像データをバンド単位に分けて随時送信しても構わない。Ｓ４０８において、ＭＦＰ１００は、Ｓ４０７におけるデータ送信に成功したか否かを判定する。Ｓ４０８の判定の結果、データ送信に成功した場合、一連の処理は終了する一方、データ送信に失敗した場合、Ｓ４０９に進む。

原稿読取ジョブの受付に成功したが、画像データの取得又は送信に失敗した場合（Ｓ４０６又はＳ４０８でＮＯ）、Ｓ４０９において、ＭＦＰ１００は、エラー画面を表示したり、ランプを点滅させたりすることで、エラーが発生した旨をユーザーに通知する。本ステップによりエラーの発生を知ったユーザーは、ＭＦＰ１００を操作してエラーを解除する必要がある。

原稿読取ジョブの受付に失敗した場合（Ｓ４０３でＮＯ）、Ｓ４１０において、ＭＦＰ１００は、Ｓ４０１で受信した原稿読取ジョブに対する応答を、情報処理サーバー３００に送信する。本ステップで送信する応答には、原稿読取ジョブの受付に失敗した旨を示す情報が含まれる。

図９に示す一連の処理が終了すると、ストレージサービスにおけるＭＦＰ１００の役割は終了し、ＭＦＰ１００は他のジョブを実行可能となる。以上が、本実施例に係るＭＦＰ１００が実行する処理の内容である。

（情報処理サーバー３０１に保存されるデータについて）
図１０は、情報処理サーバー３０１のディスク装置に保存されるデータを説明するための図である。情報処理サーバー３０１は、ＭＦＰ１００から送信される、画像データ及びこれに付随するスキャンチケット等のデータを一時的に保存する機能を有する。「一時的」とは、情報処理サーバー３０１に恒久的にファイルを保存することは想定しておらず、ストレージサーバー４００への画像データのアップロード完了時など所定の条件を満たす場合に、情報処理サーバー３０１からデータを削除することを意味する。

図１０に示すように情報処理サーバー３０１は、外部の画像処理サーバーと、画像データおよびスキャンチケットのやり取り（送受信）を行う。情報処理サーバー３０１から画像データおよびスキャンチケットを受信した画像処理サーバーは、該受信したスキャンチケットの内容に基づく画像処理を、該受信した画像データに施す。そして、画像処理サーバーは、該画像処理後の画像データおよびスキャンチケットを、情報処理サーバー３０１に送信する。

また情報処理サーバー３０１は、外部のファイル変換サーバーと、画像データおよびスキャンチケットのやり取り（送受信）を行う。情報処理サーバー３０１から画像データおよびスキャンチケットを受信したファイル変換サーバーは、該受信したスキャンチケットの内容に従って、画像データのファイル形式を変換する。そして、ファイル変換サーバーは、該変換後の画像データおよびスキャンチケットを、情報処理サーバー３０１に送信する。

なお、上述の外部サーバーによる画像処理およびファイル変換は、エラーが発生しない状況下で継続的に実行される。スキャンチケットの内容に従っての処理が何らかの理由により実行できなくなった場合（エラーが発生した場合）、基本的にはジョブの滞留を防ぐために、該当する画像データ及びスキャンチケットは削除される。通常の画像処理などにおいては、処理がエラーとなるケースは殆ど想定されないが、そのような場合に、情報処理サーバー３０１がエラーとなった画像処理だけをスキップし残りの処理を継続して実行するように実装することも可能である。

一方、ストレージサーバー４００への画像データのアップロードにおいて、スキャン自体は成功していてもユーザーの空き容量が不足していること等が原因で画像データをアップロードできないエラーが発生する場合が想定される。このような場合、最終的に画像データがストレージサーバーにアップロードされることをユーザーが望んでいることから、情報処理サーバー３０１は、アップロード処理をスキップせず、後でアップロードのリトライ処理を実行する。また本実施例では、アップロード失敗時にデータが消失することを防ぐため、情報処理サーバー３０１は、リトライ用に画像データ及びスキャンチケットを一時的に保存しておく。本実施例では、情報処理サーバー３０１により、リトライ用に一時的に保存される画像データ及びスキャンチケット等のデータの状態を「テンポラリ（状態）」と呼び、該データを「テンポラリファイル」と呼ぶ。また、テンポラリファイルが保存されるフォルダを「テンポラリフォルダ」と呼ぶ。

（情報処理サーバー３０１が実行する前処理について）
図１１は、アップロードの準備ができているか否かを問い合わせるためのクエリーを受信する情報処理サーバー３０１が、該クエリーに対する応答を送信するために実行する前処理のフローチャートである。「前処理」とは、原稿読取により得る画像データをアップロードするにあたり前もって実行する処理を意味し、アップロードの準備処理（例えば空き容量の解放）などを含む。

Ｓ５０１において、情報処理サーバー３０１は、アップロードの準備ができているか否かを問い合わせるためのクエリーを、情報処理サーバー３００から受信する。Ｓ５０２において、情報処理サーバー３０１は、Ｓ５０１で受信したクエリーに含まれるスキャンチケットに保持された情報（ユーザー名やパスワード等）を用いて、ユーザーが利用を望むストレージサービス（ストレージサーバー４００）にログインする。なお、Ｓ５０１でクエリーを受信した後にログイン処理を行っても良いし、前の時点で行ったログイン処理によるログイン状態が継続されていても良い。ログイン状態が継続されている場合は、本ステップでのログイン処理はスキップされる。Ｓ５０３において、情報処理サーバー３０１は、ストレージサービスへのログインに成功したか否かを判定する。Ｓ５０３の判定の結果、ログインに成功した場合、Ｓ５０４に進む一方、ログインに失敗した場合、Ｓ５１２に進む。

Ｓ５０４において、情報処理サーバー３０１は、ログイン中のユーザーに対応するテンポラリファイル（画像データおよびスキャンチケット）が情報処理サーバー３０１に保存されているか否かを判定する。Ｓ５０４の判定の結果、テンポラリファイルが保存されていない場合、Ｓ５０５に進む一方、テンポラリファイルが保存されている場合、Ｓ５０６に進む。

Ｓ５０５において、情報処理サーバー３０１は、Ｓ５０１で受信したクエリーに対する応答として、アップロードの準備ができている旨を示す情報を、情報処理サーバー３００に送信する。

ログイン中のユーザーに対応するテンポラリファイルが存在する場合（Ｓ５０４でＹＥＳ）、Ｓ５０６において、情報処理サーバー３０１は、ストレージサービスにおける、該ユーザーに対する空き容量を取得する。Ｓ５０７において、情報処理サーバー３０１は、Ｓ５０６で取得した空き容量と、テンポラリファイルとして一時的に保存している画像データのサイズとを比較し、該空き容量が該画像データのサイズ以上であるか否かを判定する。Ｓ５０７の判定の結果、空き容量がテンポラリの画像データのサイズ以上である場合、Ｓ５０８に進む一方、該空き容量が該サイズ未満である場合、Ｓ５１１に進む。なお、ストレージサービスにおけるユーザーの空き容量を調べる手段がない場合、Ｓ５０６およびＳ５０７は省略して構わない。

Ｓ５０８において、情報処理サーバー３０１は、テンポラリファイルとして一時的に保存している画像データの、ストレージサーバー４００へのアップロードを試みる（アップロードのリトライ処理）。Ｓ５０９において、情報処理サーバー３０１は、Ｓ５０８でのアップロードに成功したか否かを判定する。Ｓ５０９の判定の結果、アップロードに成功した場合、Ｓ５１０に進む一方、アップロードに失敗した場合、Ｓ５１１に進む。

テンポラリファイルのアップロードに成功した場合（Ｓ５０９でＹＥＳ）、Ｓ５１０において、情報処理サーバー３０１は、テンポラリファイルとして保存していた画像データ及びスキャンチケットを、テンポラリフォルダから削除する。そしてＳ５０５において、情報処理サーバー３０１は、Ｓ５０１で受信したクエリーに対する応答として、アップロードの準備ができている旨を示す情報を、情報処理サーバー３００に送信する。

テンポラリの画像データが存在するが、該画像データをアップロードするための空き容量が不足している場合（Ｓ５０７でＮＯ）や、該画像データのアップロードに失敗した場合（Ｓ５０９でＮＯ）、Ｓ５１１に進む。Ｓ５１１において、情報処理サーバー３０１は、アップロードのリトライ処理をジョブリストに登録する。そしてＳ５１２において、情報処理サーバー３０１は、Ｓ５０１で受信したクエリーに対する応答として、アップロードの準備ができていない旨を示す情報を、情報処理サーバー３００に送信する。

ストレージサービスへのログインに失敗した場合（Ｓ５０３でＮＯ）、Ｓ５１２において、情報処理サーバー３０１は、Ｓ５０１で受信したクエリーに対する応答として、アップロードの準備ができていない旨を示す情報を、情報処理サーバー３００に送信する。

Ｓ５０５又はＳ５１２で、情報処理サーバー３０１が、Ｓ５０１で受信したクエリーに対する応答を送信すると、一連の処理は終了する。以上が、本実施例に係る情報処理サーバー３０１が実行する前処理の内容である。

（情報処理サーバー３０１が実行する処理（原稿読取により得る画像データを受信しアップロードする処理）について）
図１２は、本実施例に係る情報処理サーバー３０１が実行する、ＭＦＰ１００での原稿読取により得る画像データを受信し、アップロードする処理のフローチャートである。

Ｓ６０１において、情報処理サーバー３０１は、画像データ及びスキャンチケットを、ＭＦＰ１００から受信する。なお上述の通り、本ステップで受信する画像データは、必要に応じて、画像処理が施されたりファイル形式が変換されたりすることで、ストレージサーバー４００にアップロードする画像データが生成される（図１０参照）。Ｓ６０２において、情報処理サーバー３０１は、上述の前処理の段階で既にストレージサービスにログイン中であるユーザーに対する空き容量を取得する。Ｓ６０３において、情報処理サーバー３０１は、Ｓ６０２で取得した空き容量と、ストレージサーバー４００にアップロードする画像データのサイズとを比較し、該空き容量が該画像データのサイズ以上であるか否かを判定する。Ｓ６０３の判定の結果、空き容量がアップロードする画像データのサイズ以上である場合、Ｓ６０４に進む一方、そうでない場合、Ｓ６０８に進む。

Ｓ６０４において、情報処理サーバー３０１は、画像データのストレージサーバー４００へのアップロードを実行する。Ｓ６０５において、情報処理サーバー３０１は、Ｓ６０４でのアップロードに成功したか否かを判定し、該判定の結果、アップロードに成功した場合、Ｓ６０６に進む一方、アップロードに失敗した場合、Ｓ６０８に進む。

Ｓ６０６において、情報処理サーバー３０１は、ストレージサーバー４００へのアップロードに成功した画像データ、及び、該画像データに対応付けられているスキャンチケットを削除する。そしてＳ６０７において、情報処理サーバー３０１は、ストレージサービス（ストレージサーバー４００）からログアウトする。

空き容量の不足やアップロード失敗などが原因でエラーとなった場合（Ｓ６０３又はＳ６０５でＮＯ）、Ｓ６０８に進む。Ｓ６０８において、情報処理サーバー３０１は、アップロードできなかった画像データ及び該画像データに対応付けられているスキャンチケットを、テンポラリファイルとして保存する。なお、本ステップでテンポラリファイルを保存する際、後で実行するテンポラリファイルの検索を容易にするため、ユーザーと紐付けして（ユーザー毎に）テンポラリファイルを保存しても良い。続くＳ６０９において、情報処理サーバー３０１は、テンポラリファイルがある旨をユーザーに通知する。ここでユーザーに通知する方法としては、ジョブを実行したユーザーの登録メールアドレスにメールを送信したり、ＳＮＳを利用したりすることが考えられる。例えば、空き容量の不足が原因でエラーとなった場合に、情報処理サーバー３０１が「空き容量の不足によりスキャンデータを保存できません。空き容量を確保して下さい。」という内容のメールを送信しても良いし、ＳＮＳで同内容のツイートを実行しても良い。或いは、情報処理サーバー３０１が対応アプリケーションをクライアント２０１上で起動しエラーメッセージを表示させることや、クライアント２０１上で対応アプリケーションが起動したタイミングで情報処理サーバー３０１がエラーを通知することも考えられる。なお、本ステップによるユーザーへの通知は省略しても構わない。Ｓ６１０において、情報処理サーバー３０１は、アップロードのリトライ処理を後で実行するようジョブリストに登録する。

Ｓ６０７でログアウト又はＳ６１０でアップロードのリトライ処理を登録すると、一連の処理は終了する。

（アップロードのリトライ処理について）
以下、アップロードのリトライ処理について説明する。アップロードのリトライ処理は上述したように、ユーザーが原稿読取を指示したときに該ユーザーに対応するテンポラリファイルが存在している場合に実行されるリアルタイム処理である（図１１のＳ５０８）。このようにアップロードのリトライ処理は、ユーザーのアクションがトリガーとなって実行される処理であるが、情報処理サーバー３０１は、ユーザーのアクションとは関係なくバックグラウンドで該リトライ処理を繰り返し実行することが望ましい。その理由は、こうすることで、ユーザーがストレージサーバー内の不要ファイルを削除し空き領域を確保した場合に、テンポラリの画像データが自動的にアップロードされ、原稿読取による新しい画像データの取得およびアップロードが可能となるからである。ただし、ユーザーによる不要ファイルの削除処理には時間がかかるため、頻繁にリトライ処理を実行することはあまり有用とは言えず、また、頻繁なリトライ処理の実行は情報処理サーバー３０１にとって負荷となる。従って、アップロードのリトライ処理は、所定時間ごとに実行することが望ましい。

図１３は、アップロードのリトライ処理を制御する処理のフローチャートである。情報処理サーバー３０１が起動され、読取ジョブの受付が可能になると同時に、アップロードのリトライ処理を行うプロセスが開始する。

Ｓ７０１において、情報処理サーバー３０１は、アップロードのリトライ処理を制御するためのタスクを、バックグラウンドで開始する。Ｓ７０２において、情報処理サーバー３０１は、実行すべきジョブとしてアップロードのリトライ処理が登録されるジョブリスト（以下、リトライ処理登録ジョブリスト）を初期化する。本ステップでの初期化により、リトライ処理登録ジョブリストにジョブが登録されていない状態になり、上述のＳ５１１又はＳ６１０により、リトライ処理登録ジョブリストにアップロードのリトライ処理が追加される。Ｓ７０３において、情報処理サーバー３０１は、リトライ処理登録ジョブリストに登録されているジョブ（即ちアップロードのリトライ処理）があるか否かを判定する。Ｓ７０３の判定の結果、リトライ処理登録ジョブリストに登録されているジョブがある場合、Ｓ７０４に進み、そうでない場合、Ｓ７０８に進む。

Ｓ７０４において、情報処理サーバー３０１は、リトライ処理登録ジョブリストに登録されているジョブを登録順に処理するために、着目ジョブを取得する。Ｓ７０５において、情報処理サーバー３０１は、着目ジョブ（アップロードのリトライ処理）を実行する。詳細は後述するが（図１４参照）、本ステップでアップロードに成功した場合、着目ジョブに対応するテンポラリの画像ファイルは削除されるため、該着目ジョブは後続の処理対象及び判定対象から除外される。Ｓ７０６において、情報処理サーバー３０１は、リトライ処理登録ジョブリストに登録されているジョブ（即ちアップロードのリトライ処理）があるか否かを判定する。Ｓ７０６の判定の結果、リトライ処理登録ジョブリストに登録されているジョブがある場合、Ｓ７０７に進み、そうでない場合、Ｓ７０３に戻る。

Ｓ７０７において、情報処理サーバー３０１は、着目ジョブを更新する。具体的には、これまで着目していたジョブの次に登録されたジョブを、着目ジョブとして設定する。なお、これまで着目していたジョブの次に登録されたジョブが存在しない場合、最初に登録されたジョブを、着目ジョブとして設定する。Ｓ７０８において、情報処理サーバー３０１は、アップロードのリトライ処理を行うプロセスの終了要求がシステムから来たか否かを判定する。Ｓ７０８の判定の結果、プロセスの終了要求が来た場合、一連の処理は終了する一方、そうでない場合、Ｓ７０３に戻る。

図１４は、図１３のＳ７０５で実行するリトライ処理のフローチャートである。Ｓ８０１において、情報処理サーバー３０１は、Ｓ７０４で取得した着目ジョブ（即ちアップロードのリトライ処理）に対応するスキャンチケットを取得する。上述したように、スキャンチケットは、「Retry Next Time」の項目で、リトライ処理を開始するタイミングに関する情報を保持しており（図８参照）、本ステップにより「Retry Next Time」の値（時刻）が取得される。Ｓ８０２において、情報処理サーバー３０１は、現在時刻が「Retry Next Time」の時刻以降であるか否かを判定する。Ｓ８０２の判定の結果、現在時刻が「Retry Next Time」の時刻以降である場合、Ｓ８０３に進み、そうでない場合、一連の処理は終了する。

Ｓ８０３において、情報処理サーバー３０１は、ストレージサービスにおけるユーザーに対する空き容量を取得する。Ｓ８０４において、情報処理サーバー３０１は、Ｓ８０３で取得した空き容量と、テンポラリの画像データのサイズとを比較し、該空き容量が該テンポラリの画像データのサイズ以上であるか否かを判定する。Ｓ８０４の判定の結果、空き容量がテンポラリの画像データのサイズ以上である場合、Ｓ８０５に進む一方、そうでない場合、Ｓ８０９に進む。

Ｓ８０５において、情報処理サーバー３０１は、テンポラリの画像データの、ストレージサーバー４００へのアップロードを試みる。Ｓ８０６において、情報処理サーバー３０１は、Ｓ８０５でのアップロードに成功したか否かを判定する。Ｓ８０６の判定の結果、アップロードに成功した場合、Ｓ８０７に進む一方、アップロードに失敗した場合、Ｓ８０９に進む。

Ｓ８０７において、情報処理サーバー３０１は、テンポラリファイルとして保存していた画像データ及びスキャンチケットをテンポラリフォルダから削除し、一連の処理は終了する。

テンポラリの画像データをアップロードするための空き容量が不足している場合（Ｓ８０４でＮＯ）や、該アップロードに失敗した場合（Ｓ８０６でＮＯ）、Ｓ８０９に進む。Ｓ８０９において、情報処理サーバー３０１は、「Remain Retry Counter」の値（即ち、残りのリトライ回数）を１減らしてスキャンチケットを更新する。Ｓ８１０において、情報処理サーバー３０１は、「Remain Retry Counter」の値が０であるか否かを判定する。Ｓ８１０の判定の結果、「Remain Retry Counter」の値が０である場合、一連の処理は終了する一方、そうでない場合、Ｓ８１１に進む。

Ｓ８１１において、情報処理サーバー３０１は、次のリトライのために「Retry Next Time」の値を現在時刻より後の任意の時刻に書き換えることで、スキャンチケットを更新し、一連の処理は終了する。なお、Ｓ８１１で「Retry Next Time」の値を書き換える際、リトライ処理の間隔を最初は短く設定し、実行したリトライ処理の回数が増加するに従って、リトライ処理の間隔を徐々に長くなるように設定しても良い。

（システムが実行する処理について）
図１５は、ユーザーがクライアント２０１を用いて原稿読取を指示してから、ストレージサーバー４００に画像データがアップロードされるまでの、本実施例に係るシステムによって実行される処理を説明するためのシーケンスチャートである。以下、各処理を時系列順に説明する。

クライアント２０１は、原稿読取に関するユーザー側で設定可能な条件及び保存先候補を、情報処理サーバー３００に問い合わせる（Ｓ１０１）。情報処理サーバー３００は、自身が保有するデータベースに格納されているリストを参照し、原稿読取に関するユーザー側で設定可能な条件と保存先候補とを含む情報を取得（Ｓ２０２）し、該情報をクライアント２０１に送信する。クライアント２０１は、該情報を受信し（Ｓ１０２）、該受信した情報に基づくＵＩを表示し（Ｓ１０３）、ユーザーがＵＩを介して設定した原稿読取要求を情報処理サーバー３００に送信する（Ｓ１０５）。情報処理サーバー３００は、受信した原稿読取要求に従いスキャンチケットを作成し（Ｓ３０２）、アップロードの準備ができているかを、アップロードを管理する情報処理サーバー３０１に問い合わせる（Ｓ３０３）。問い合わせを受けた情報処理サーバー３０１は、ストレージサーバー４００にログインする（Ｓ５０２）。また、情報処理サーバー３０１は、テンポラリの画像データが存在するか否かを判定し、テンポラリの画像データが存在する場合、該画像データのストレージサーバー４００へのアップロードを試みる（Ｓ５０８）。さらに、情報処理サーバー３０１は、アップロードの準備ができているか否かを示す情報を、情報処理サーバー３００に送信する。情報処理サーバー３００は、該送信された情報を受信する（Ｓ３０４）。

以下、情報処理サーバー３０１にテンポラリの画像データが保存されていなかった場合、及び、情報処理サーバー３０１がテンポラリの画像データのアップロードに成功した場合について説明する。これらの場合、情報処理サーバー３０１において新しい画像データのアップロードの準備ができているため、情報処理サーバー３００は、原稿読取ジョブをＭＦＰ１００に送信する（Ｓ３０６）。ＭＦＰ１００は、該原稿読取ジョブを受信し、該原稿読取ジョブに含まれるスキャンチケットを解析し（Ｓ４０２）、該原稿読取ジョブを受け付けたか否かを示す情報を、受信した原稿読取ジョブに対する応答として情報処理サーバー３００に送信する。なお本例では、原稿読取ジョブの受付に成功しているものとする。情報処理サーバー３００は、該原稿読取ジョブに対する応答（ＯＫ）を受信し（Ｓ３０７）、当該受信した応答（ＯＫ）に基づく原稿読取応答をクライアント２０１に送信する。その後、クライアント２０１は、該原稿読取応答を受信する（Ｓ１０６）。

ＭＦＰ１００は、スキャンチケットの内容に基づく原稿読取を実行し（Ｓ４０５）、取得した画像データ及びスキャンチケットを、情報処理サーバー３０１に送信する（Ｓ４０７）。なお、ＭＦＰ１００がスキャンチケットを送信する際、ＭＦＰ１００における処理内容を書き込む等、必要に応じてスキャンチケットを更新して良い。

画像データ及びスキャンチケットを受信した情報処理サーバー３０１は、必要に応じて画像処理、ファイル形式変換処理を画像データに施し、ストレージサーバー４００にアップロードする（Ｓ６０４）。該アップロードに成功した場合、情報処理サーバー３０１は、ストレージサーバー４００からログアウトする（Ｓ６０７）。一方、該アップロードに失敗した場合、情報処理サーバー３０１は、ストレージサーバー４００に転送しようとしていた画像データをそのままテンポラリファイルとして保存する（Ｓ６０８）。情報処理サーバー３０１に保存されているテンポラリの画像データに対し、該テンポラリの画像データをアップロードするためのリトライ処理は自動的に（即ち、所定時間ごとに１回、所定回数繰り返して）実行される（Ｓ８０５）。テンポラリの画像データは、ストレージサーバー４００へのアップロードに成功すると、情報処理サーバー３０１から削除される。

上述のように本実施例では、ストレージサービスを利用したデータのアップロードにおいてテンポラリの画像データを活用する。これにより、ストレージサービスにおけるユーザーの空き容量の不足が原因で、ＭＦＰでの原稿読取により取得した画像データをストレージサーバーに転送できない場合であっても、該画像データが消失することは無くなる。従ってユーザーは、安心してＭＦＰの機能を最大限に使用することができる。また本実施例では、テンポラリの画像データのストレージサーバーへの自動的なアップロードを試みる。これにより、ユーザーの利便性が向上する。さらに本実施例では、様々な機能差のあるＭＦＰやストレージサービスが存在してもサーバーはそれらを個別に管理する必要がないため、様々なシステムに柔軟に実装することができる。

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

１００・・・ＭＦＰ
３０１・・・情報処理サーバー
４００・・・ストレージサーバー

Claims (16)

1. データをストレージサーバーにアップロードするサービスのためのシステムであって、
   原稿を読み取る読取部を備える読取装置が、当該読取部により原稿を読み取ることで取得された画像データであって、当該読取装置から送信された画像データの、前記ストレージサーバーへのアップロードを試みるアップロード手段と、
   前記アップロードに失敗した場合、前記画像データを、前記サービスにログイン中のユーザーに対応付けて保存する保存手段と、
   前記保存手段が前記画像データを保存する場合に、前記ユーザーに、前記アップロードの失敗に関する所定の通知を行う通知手段と、を有し、
   前記アップロード手段は、前記読取装置による原稿読取をユーザーが指示し、かつ、前記保存手段が当該ユーザーに対応付けて前記画像データを保存していることに基づいて、当該画像データの前記ストレージサーバーへのアップロードを再び試みることを特徴とするシステム。
2. データをストレージサーバーにアップロードするサービスのためのシステムであって、
   原稿を読み取る読取部を備える読取装置が原稿を読み取ることで取得され、当該読取装置から送信された画像データの前記ストレージサーバーへのアップロードを試みるアップロード手段と、
   前記アップロードに失敗した場合、前記画像データを保存する保存手段と、
   前記保存手段が前記画像データを保存する場合に、前記サービスにログイン中のユーザーの登録メールアドレスにメールを送信することで、当該ユーザーに前記アップロードの失敗に関する所定の通知を行う通知手段と、を有し、
   前記アップロード手段は、前記保存手段に保存した前記画像データの前記ストレージサーバーへのアップロードを再び試みることを特徴とするシステム。
3. 前記ストレージサーバーにデータを転送するサーバーを備え、
   前記サーバーは、前記アップロード手段と、前記保存手段と、を有することを特徴とする請求項１または２に記載のシステム。
4. 前記読取装置は、画像を印刷する印刷部をさらに有することを特徴とする請求項１乃至３の何れか１項に記載のシステム。
5. 前記読取装置による原稿読取をユーザーが指示し、かつ、前記保存手段が前記画像データを保存している場合に、前記アップロード手段は、当該画像データのアップロードを再び試みることを特徴とする請求項２に記載のシステム。
6. 前記アップロード手段は、所定時間ごとに１回、所定回数繰り返して、前記画像データのアップロードを再び試みることを特徴とする請求項１乃至５の何れか１項に記載のシステム。
7. 原稿読取の要求の受信に応じて、前記読取装置に原稿読取ジョブを送信することで、前記読取部により原稿を読み取らせて当該読取により得られた画像データを送信させる送信制御手段をさらに有し、
   前記送信制御手段により前記読取装置が送信した画像データが前記保存手段により保存されているときに、当該画像データに対応付けられているユーザーからの原稿読取の要求が受信された場合、前記アップロード手段は、当該画像データのアップロードを再び試みることを特徴とする請求項１に記載のシステム。
8. 前記アップロード手段が、前記保存手段により保存されている画像データのアップロードを、当該画像データに対応付けられているユーザーからの原稿読取の要求に応じて再び試み、当該アップロードが成功した場合、前記送信制御手段は、当該要求に応じて、前記読取装置に新たに画像データを送信させることを特徴とする請求項７に記載のシステム。
9. 画像データが前記保存手段により保存されているときに、当該画像データに対応付けられているユーザーからの要求が受信された場合、前記アップロード手段は、前記ストレージサーバーにログインした後に当該画像データのアップロードを再び試みることを特徴とする請求項７または８に記載のシステム。
10. 前記アップロード手段が再び試みた画像データのアップロードが完了したときに前記ストレージサーバーからログアウトされずに、前記読取装置により新たに送信された画像データのアップロードが行われたときに前記ストレージサーバーからログアウトされることを特徴とする請求項８に従属する請求項９に記載のシステム。
11. 前記アップロード手段が再び試みた画像データのアップロードに成功した場合、前記保存手段から当該画像データを削除する削除手段をさらに有することを特徴とする請求項１乃至１０のいずれか１項に記載のシステム。
12. 前記通知手段は、前記ユーザーの登録メールアドレスにメールを送信することで、前記保存手段に保存するデータが存在することを前記ユーザーに通知することを特徴とする請求項１に記載のシステム。
13. データをストレージサーバーにアップロードするサービスのための方法であって、
    原稿を読み取る読取部を備える読取装置が、当該読取部により原稿を読み取ることで取得された画像データであって、当該読取装置から送信された画像データの、前記ストレージサーバーへのアップロードを試みる第１の工程と、
    前記アップロードに失敗した場合、前記画像データを、前記サービスにログイン中のユーザーに対応付けて保存する第２の工程と、
    前記第２の工程で前記画像データを保存する場合に、前記ユーザーに、前記アップロードの失敗に関する所定の通知を行う第３の工程と、
    前記読取装置による原稿読取をユーザーが指示し、かつ、前記第２の工程で当該ユーザーに対応付けて前記画像データを保存していることに基づいて、当該画像データの前記ストレージサーバーへのアップロードを再び試みる第４の工程と、
    を有することを特徴とする方法。
14. データをストレージサーバーにアップロードするサービスのための方法であって、
    原稿を読み取る読取部を備える読取装置が原稿を読み取ることで取得され、当該読取装置から送信された画像データの前記ストレージサーバーへのアップロードを試みる第１の工程と、
    前記アップロードに失敗した場合、前記画像データを保存する第２の工程と、
    前記第２の工程で前記画像データを保存する場合に、前記サービスにログイン中のユーザーの登録メールアドレスにメールを送信することで、当該ユーザーに前記アップロードの失敗に関する所定の通知を行う第３の工程と、
    前記第２の工程で保存した前記画像データの前記ストレージサーバーへのアップロードを再び試みる第４の工程と、
    を有することを特徴とする方法。
15. コンピュータに、
    データをストレージサーバーにアップロードするサービスのための方法であって、
    原稿を読み取る読取部を備える読取装置が、当該読取部により原稿を読み取ることで取得された画像データであって、当該読取装置から送信された画像データの、前記ストレージサーバーへのアップロードを試みる第１の工程と、
    前記アップロードに失敗した場合、前記画像データを、前記サービスにログイン中のユーザーに対応付けて保存する第２の工程と、
    前記第２の工程で前記画像データを保存する場合に、前記ユーザーに、前記アップロードの失敗に関する所定の通知を行う第３の工程と、
    前記読取装置による原稿読取をユーザーが指示し、かつ、前記第２の工程で当該ユーザーに対応付けて前記画像データを保存していることに基づいて、当該画像データの前記ストレージサーバーへのアップロードを再び試みる第４の工程と、
    を有する方法
    を実行させるためのプログラム。
16. コンピュータに、
    データをストレージサーバーにアップロードするサービスのための方法であって、
    原稿を読み取る読取部を備える読取装置が原稿を読み取ることで取得され、当該読取装置から送信された画像データの前記ストレージサーバーへのアップロードを試みる第１の工程と、
    前記アップロードに失敗した場合、前記画像データを保存する第２の工程と、
    前記第２の工程で前記画像データを保存する場合に、前記サービスにログイン中のユーザーの登録メールアドレスにメールを送信することで、当該ユーザーに前記アップロードの失敗に関する所定の通知を行う第３の工程と、
    前記第２の工程で保存した前記画像データの前記ストレージサーバーへのアップロードを再び試みる第４の工程と、
    を有することを特徴とする方法
    を実行させるためのプログラム。

Images