(57)【要約】【課題】  複数個の画像ファイルを同一の対象ファイルグループ内に適切にアップロードするための技術を提供すること。【解決手段】  ＵＬサーバ１００は、画像ファイル２００を含むＦＧ（ファイルグループ）３１８ｂがＳＰサーバ１５０内に保存されている状態で、ＵＬ要求コマンド４１０をＭＦＰ１０から受信する。ＵＬサーバ１００は、ＵＬ要求コマンド４１０に含まれるＦＧＩＤ３２０を用いてＦＧ３１８ｂをＦＧ３１８ｃに変更して、画像ファイル２５０をアップロードする。これにより、画像ファイル２００と２５０とを同一のＦＧ３１８ｃにアップロードすることができる。【選択図】  図７
2014130410.tif 000002
【特許請求の範囲】
【請求項１】
通信装置からデータ保存サーバへの画像ファイルのアップロードを仲介するための仲介サーバであって、
現行の文書ファイルと、アップロード対象の複数個の画像ファイルのうちの１個以上の画像ファイルと、を含む現行の対象ファイルグループが、前記データ保存サーバに保存されている状態で、前記複数個の画像ファイルのうちの第１の画像ファイルの前記データ保存サーバへのアップロードを指示するアップロードコマンドを、前記通信装置から受信するアップロードコマンド受信部であって、前記現行の文書ファイルは、前記データ保存サーバに保存されている前記１個以上の画像ファイルを特定するための１個以上のテキストデータを含み、前記アップロードコマンドは、前記対象ファイルグループを識別するためのグループ識別情報と、前記第１の画像ファイルと、を含む、前記アップロードコマンド受信部と、
前記アップロードコマンドが受信される場合に、前記グループ識別情報を用いて、前記データ保存サーバに前記第１の画像ファイルをアップロードして、前記データ保存サーバ内の前記現行の対象ファイルグループを変更するアップロード部であって、変更後の対象ファイルグループは、変更後の文書ファイルと、前記１個以上の画像ファイルと、前記第１の画像ファイルと、を含み、前記変更後の文書ファイルは、前記第１の画像ファイルを特定するための第１のテキストデータを前記現行の文書ファイルに追加することによって得られる、前記アップロード部と、
を備える、仲介サーバ。
【請求項２】
前記アップロード部は、
前記グループ識別情報を前記データ保存サーバに供給して、前記データ保存サーバから前記現行の文書ファイルを取得するファイル取得部と、
前記第１のテキストデータを前記現行の文書ファイルに追加して、前記変更後の文書ファイルを生成する追加部と、
前記変更後の文書ファイルと前記第１の画像ファイルとを前記データ保存サーバに供給するファイル供給部と、
を備える、請求項１に記載の仲介サーバ。
【請求項３】
前記仲介サーバは、さらに、
前記現行の対象ファイルグループの変更が成功したのか否かを示す結果情報が、前記データ保存サーバから取得される場合に、前記結果情報を前記通信装置に供給する結果情報供給部を備える、請求項１又は２に記載の仲介サーバ。
【請求項４】
前記アップロードコマンド受信部は、第１のプログラムに従って、前記通信装置から前記アップロードコマンドを受信し、
前記アップロード部は、前記アップロードコマンドが受信される場合に、前記第１のプログラムとは異なる第２のプログラムに従って、前記データ保存サーバ内の前記現行の対象ファイルグループを変更する、請求項１から３のいずれか一項に記載の仲介サーバ。
【請求項５】
前記仲介サーバは、さらに、
前記複数個の画像ファイルのうちのいずれの画像ファイルも前記データ保存サーバに保存されていない状態で、初期の対象ファイルグループの生成を指示する生成コマンドを、前記通信装置から受信する生成コマンド受信部と、
前記生成コマンドが受信される場合に、初期の文書ファイルを生成する生成部であって、前記初期の文書ファイルは、前記複数個の画像ファイルを特定するための複数個のテキストデータのいずれも含まない、前記生成部と、
前記初期の文書ファイルを前記データ保存サーバに供給して、前記初期の対象ファイルグループを前記データ保存サーバ内に保存させる保存制御部であって、前記初期の対象ファイルグループは、前記初期の文書ファイルを含み、前記複数個の画像ファイルのいずれも含まない、前記保存制御部と、
前記初期の文書ファイルが前記データ保存サーバに供給された後に、前記データ保存サーバから前記グループ識別情報が取得される場合に、前記グループ識別情報を前記通信装置に供給する識別情報供給部と、を備える、請求項１から４のいずれか一項に記載の仲介サーバ。
【請求項６】
前記生成部は、さらに、前記初期の文書ファイルを生成する際に、前記対象ファイルグループの名称として、アップロード中であることを示す第１の名称を生成し、
前記保存制御部は、前記初期の文書ファイルを前記データ保存サーバに供給する際に、前記第１の名称を前記データ保存サーバに供給し、
前記仲介サーバは、さらに、
前記複数個の画像ファイルの全てのアップロードが完了したことを示す完了情報が、前記通信装置から取得される場合に、前記対象ファイルグループの名称を前記第１の名称からアップロード中であることを示さない第２の名称に変更するための指示を、前記データ保存サーバに供給する名称変更部を備える、請求項５に記載の仲介サーバ。
【請求項７】
前記仲介サーバは、
第１のアプリケーションに従って実現される第１のサーバと、
前記第１のアプリケーションとは異なる第２のアプリケーションに従って実現される第２のサーバと、を備え、
前記第１のサーバは、前記アップロードコマンド受信部と、前記アップロード部と、を備え、
前記第２のサーバは、前記生成コマンド受信部と、前記生成部と、前記保存制御部と、前記識別情報供給部と、を備える、請求項５又は６に記載の仲介サーバ。
【請求項８】
前記第２のサーバは、さらに、
前記第１のサーバの位置情報を前記通信装置に供給する位置情報供給部を備える、請求項７に記載の仲介サーバ。
【請求項９】
仲介サーバを介してデータ保存サーバへの画像ファイルのアップロードを実行するための通信装置であって、
初期の対象ファイルグループが前記データ保存サーバに保存されている状態で、前記データ保存サーバから、前記仲介サーバを介して、前記対象ファイルグループを識別するためのグループ識別情報を取得する識別情報取得部であって、前記初期の対象ファイルグループは、初期の文書ファイルを含み、アップロード対象の複数個の画像ファイルのいずれも含まず、前記初期の文書ファイルは、前記複数個の画像ファイルを特定するための複数個のテキストデータのいずれも含まない、前記識別情報取得部と、
現行の文書ファイルと、前記複数個の画像ファイルのうちの１個以上の画像ファイルと、を含む現行の対象ファイルグループが、前記データ保存サーバに保存されている状態で、前記複数個の画像ファイルのうちの第１の画像ファイルの前記データ保存サーバへのアップロードを指示するアップロードコマンドを、前記仲介サーバに送信するアップロードコマンド送信部であって、前記現行の文書ファイルは、前記１個以上の画像ファイルを特定するための１個以上のテキストデータのそれぞれを前記初期の文書ファイルに追加することによって得られ、前記アップロードコマンドは、前記グループ識別情報と、前記第１の画像ファイルと、を含む、前記アップロードコマンド送信部と、
を備える、通信装置。
【請求項１０】
通信装置からデータ保存サーバへの画像ファイルのアップロードを仲介するための仲介サーバのためのコンピュータプログラムであって、
前記コンピュータプログラムは、前記仲介サーバに搭載される１個以上のプロセッサに、以下の各処理、即ち、
現行の文書ファイルと、アップロード対象の複数個の画像ファイルのうちの１個以上の画像ファイルと、を含む現行の対象ファイルグループが、前記データ保存サーバに保存されている状態で、前記複数個の画像ファイルのうちの第１の画像ファイルの前記データ保存サーバへのアップロードを指示するアップロードコマンドを、前記通信装置から受信するアップロードコマンド受信処理であって、前記現行の文書ファイルは、前記データ保存サーバに保存されている前記１個以上の画像ファイルを特定するための１個以上のテキストデータを含み、前記アップロードコマンドは、前記対象ファイルグループを識別するためのグループ識別情報と、前記第１の画像ファイルと、を含む、前記アップロードコマンド受信処理と、
前記アップロードコマンドが受信される場合に、前記グループ識別情報を用いて、前記データ保存サーバに前記第１の画像ファイルをアップロードして、前記データ保存サーバ内の前記現行の対象ファイルグループを変更するアップロード処理であって、変更後の対象ファイルグループは、変更後の文書ファイルと、前記１個以上の画像ファイルと、前記第１の画像ファイルと、を含み、前記変更後の文書ファイルは、前記第１の画像ファイルを特定するための第１のテキストデータを前記現行の文書ファイルに追加することによって得られる、前記アップロード処理と、
を実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書では、通信装置からデータ保存サーバへの画像ファイルのアップロードを実行するための技術を開示する。
【背景技術】
【０００２】
特許文献１には、画像処理装置が、イメージスキャナによって生成される画像データを、サーバにアップロードするための技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２６９２５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本明細書では、通信装置からデータ保存サーバに複数個の画像ファイルを適切にアップロードするための技術を提供する。
【課題を解決するための手段】
【０００５】
本明細書によって開示される一つの技術は、通信装置からデータ保存サーバへの画像ファイルのアップロードを仲介するための仲介サーバである。仲介サーバは、アップロードコマンド受信部と、アップロード部と、を備える。アップロードコマンド受信部は、現行の文書ファイルと、アップロード対象の複数個の画像ファイルのうちの１個以上の画像ファイルと、を含む現行の対象ファイルグループが、データ保存サーバに保存されている状態で、複数個の画像ファイルのうちの第１の画像ファイルのデータ保存サーバへのアップロードを指示するアップロードコマンドを、通信装置から受信する。現行の文書ファイルは、データ保存サーバに保存されている１個以上の画像ファイルを特定するための１個以上のテキストデータを含む。アップロードコマンドは、対象ファイルグループを識別するためのグループ識別情報と、第１の画像ファイルと、を含む。アップロード部は、アップロードコマンドが受信される場合に、グループ識別情報を用いて、データ保存サーバに第１の画像ファイルをアップロードして、データ保存サーバ内の現行の対象ファイルグループを変更する。変更後の対象ファイルグループは、変更後の文書ファイルと、１個以上の画像ファイルと、第１の画像ファイルと、を含む。変更後の文書ファイルは、第１の画像ファイルを特定するための第１のテキストデータを現行の文書ファイルに追加することによって得られる。
【０００６】
上記の構成によると、仲介サーバは、現行の対象ファイルグループがデータ保存サーバに保存されている状態で、通信装置からアップロードコマンドが受信される場合に、グループ識別情報を用いて、データ保存サーバに第１の画像ファイルをアップロードする。即ち、仲介サーバは、グループ識別情報によって識別される対象ファイルグループに第１の画像ファイルが新たに含まれるように、現行の対象ファイルグループを変更することができる。これにより、仲介サーバは、複数個の画像ファイルを同一の対象ファイルグループ内に適切にアップロードすることができる。
【０００７】
本明細書によって開示される一つの技術は、仲介サーバを介してデータ保存サーバへの画像ファイルのアップロードを実行するための通信装置である。通信装置は、識別情報取得部と、アップロードコマンド送信部と、を備える。識別情報取得部は、初期の対象ファイルグループがデータ保存サーバに保存されている状態で、データ保存サーバから、仲介サーバを介して、対象ファイルグループを識別するためのグループ識別情報を取得する。初期の対象ファイルグループは、初期の文書ファイルを含み、アップロード対象の複数個の画像ファイルのいずれも含まない。初期の文書ファイルは、複数個の画像ファイルを特定するための複数個のテキストデータのいずれも含まない。アップロードコマンド送信部は、現行の文書ファイルと、複数個の画像ファイルのうちの１個以上の画像ファイルと、を含む現行の対象ファイルグループが、データ保存サーバに保存されている状態で、複数個の画像ファイルのうちの第１の画像ファイルのデータ保存サーバへのアップロードを指示するアップロードコマンドを、仲介サーバに送信する。現行の文書ファイルは、１個以上の画像ファイルを特定するための１個以上のテキストデータのそれぞれを初期の文書ファイルに追加することによって得られる。アップロードコマンドは、グループ識別情報と、第１の画像ファイルと、を含む。
【０００８】
上記の構成によると、通信装置は、初期の対象ファイルグループがデータ保存サーバに保存されている状態で、データ保存サーバから、仲介サーバを介して、グループ識別情報を取得する。そして、通信装置は、現行の対象ファイルグループがデータ保存サーバに保存されている状態で、グループ識別情報と、第１の画像ファイルと、を含むアップロードコマンドを、仲介サーバに送信する。即ち、通信装置は、グループ識別情報によって識別される対象ファイルグループに第１の画像ファイルが新たに含まれるように、アップロードコマンドを仲介サーバに適切に送信することができる。
【０００９】
上記の各デバイス（即ち、仲介サーバ、通信装置）を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを記憶するコンピュータ読取可能記憶媒体も、新規で有用である。また、上記の仲介サーバと上記の通信装置とを備えるシステムも、新規で有用である。
【図面の簡単な説明】
【００１０】
【図１】通信システムの構成を示す。
【図２】ＳＰサーバ内のフォルダ及びファイルグループの階層構造を示す。
【図３】ＭＦＰ処理のフローチャートを示す。
【図４】ＡＰＩサーバ処理のフローチャートを示す。
【図５】ＵＬサーバ処理のフローチャートを示す。
【図６】実施例の各デバイスによって実行される各処理のシーケンス図を示す。
【図７】図６の続きのシーケンス図を示す。
【図８】アップロードが成功するケースＡのシーケンス図と、アップロードが失敗するケースＢのシーケンス図と、を示す。
【図９】比較例の各デバイスによって実行される各処理のシーケンス図を示す。
【図１０】実施例及び比較例を対比して説明するための図を示す。
【発明を実施するための形態】
【００１１】
（実施例）
（システムの構成）
図１に示されるように、通信システム２は、ＭＦＰ（Multi-Function Peripheralの略）１０と、ＡＰＩ（Application Program Interfaceの略）サーバ５０と、アップロードサーバ１００（以下では「ＵＬ（Uploadの略）サーバ１００」と呼ぶ）と、複数個のサービス提供サーバ１５０，１６０（以下では「ＳＰ（Service Providingの略）サーバ１５０，１６０」と呼ぶ）と、を備える。各デバイス１０，５０，１００，１５０，１６０は、インターネットに接続可能である。
【００１２】
（ＭＦＰ１０の構成）
ＭＦＰ１０は、印刷機能、スキャン機能、コピー機能、ＦＡＸ機能等の多機能を実行可能な周辺装置である。ＭＦＰ１０は、操作部１２と、ディスプレイ１４と、印刷実行部１６と、スキャン実行部２０と、ネットワークＩ／Ｆ２２と、制御部３０と、を備える。操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示をＭＦＰ１０に入力することができる。ディスプレイ１４は、様々な情報を表示することができる。印刷実行部１６は、インクジェット方式、レーザ方式等の印刷機構を備える。スキャン実行部２０は、ＣＣＤ、ＣＩＳ等のスキャン機構を備える。
【００１３】
ネットワークＩ／Ｆ２２は、ＬＡＮ（Local Area Networkの略）に接続するためのインターフェースである。ネットワークＩ／Ｆ２２は、有線ＬＡＮに接続されるインターフェースであってもよいし、無線ＬＡＮに接続されるインターフェースであってもよい。ＭＦＰ１０は、ネットワークＩ／Ｆ２２を介して（即ちＬＡＮを介して）、インターネットに接続可能である。
【００１４】
制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に記憶されているプログラムに従って、様々な処理を実行する。ＣＰＵ３２が上記のプログラムに従って処理を実行することによって、各部４１，４２の機能が実現される。
【００１５】
（ＡＰＩサーバ５０の構成）
ＡＰＩサーバ５０は、ＭＦＰ１０のベンダによって提供されるサーバであり、各ＳＰサーバ１５０，１６０からＭＦＰ１０へのサービスの提供を仲介するためのサーバである。具体的に言うと、ＡＰＩサーバ５０は、各ＳＰサーバ１５０，１６０に対応する各ＡＰＩに従って、各ＳＰサーバ１５０，１６０と通信してデータ処理を実行する。
【００１６】
ＡＰＩサーバ５０は、ネットワークＩ／Ｆ６０と、制御部７０と、を備える。ＡＰＩサーバ５０は、ネットワークＩ／Ｆ６０を介して、インターネットに接続可能である。制御部７０は、ＣＰＵ７２と、メモリ７４と、を備える。ＣＰＵ７２は、メモリ７４に記憶されているプログラムに従って、様々な処理を実行する。
【００１７】
メモリ７４内のプログラムは、ＡＰＩサーバ５０を実現するためのアプリケーションプログラムを含む。当該アプリケーションプログラムは、後述の図４の各処理を実行するためのプログラムを含む。メモリ７４内のプログラムは、さらに、複数個のＳＰサーバ１５０，１６０に対応する複数個のＡＰＩを含む。複数個のＡＰＩのそれぞれは、当該ＡＰＩに対応するＳＰサーバ（例えばＳＰサーバ１５０）と通信してデータ処理を実行するためのプログラムである。特に、ＳＰサーバ１５０に対応するＡＰＩは、後述の図４の各処理を実行するためのプログラムを含む。ＣＰＵ７２が、上記のアプリケーションプログラム及びＳＰサーバ１５０に対応するＡＰＩに従って処理を実行することによって、各部８１〜８６の機能が実現される。
【００１８】
（ＵＬサーバ１００の構成）
ＵＬサーバ１００は、ＭＦＰ１０のベンダによって提供されるサーバであり、各ＳＰサーバ１５０，１６０からＭＦＰ１０へのサービスの提供を仲介するためのサーバである。具体的に言うと、ＵＬサーバ１００は、ＭＦＰ１０からの要求に応じて、画像ファイルを各ＳＰサーバ１５０，１６０にアップロードする。
【００１９】
ＵＬサーバ１００は、ネットワークＩ／Ｆ１１０と、制御部１２０と、を備える。ＵＬサーバ１００は、ネットワークＩ／Ｆ１１０を介して、インターネットに接続可能である。制御部１２０は、ＣＰＵ１２２と、メモリ１２４と、を備える。ＣＰＵ１２２は、メモリ１２４に記憶されているプログラムに従って、様々な処理を実行する。
【００２０】
メモリ１２４内のプログラムは、ＵＬサーバ１００を実現するためのアプリケーションプログラムを含む。当該アプリケーションプログラムは、後述の図５の各処理を実行するためのプログラムを含む。図４の処理及び図５の処理が異なることから明らかなように、ＵＬサーバ１００のためのアプリケーションプログラムは、ＡＰＩサーバ５０のためのアプリケーションプログラムとは異なる。即ち、ＡＰＩサーバ５０及びＵＬサーバ１００は、異なるアプリケーションプログラムによって実現される異なるサーバである。メモリ１２４内のプログラムは、さらに、複数個のＳＰサーバ１５０，１６０に対応する複数個のＡＰＩを含む。特に、ＳＰサーバ１５０に対応するＡＰＩは、後述の図５の各処理を実行するためのプログラムを含む。ＣＰＵ１２２が上記のアプリケーションプログラム及びＳＰサーバ１５０に対応するＡＰＩに従って処理を実行することによって、各部１３１〜１３３の機能が実現される。なお、アップロード部１３２は、各部１４１〜１４３を備える。
【００２１】
（ＳＰサーバ１５０，１６０の構成）
各ＳＰサーバ１５０，１６０は、例えば、「Evernote（登録商標）」、「Google（登録商標） Docs」、「PICASA（登録商標）」、「Facebook（登録商標）」等の公知のサービス提供サーバ（即ちクラウドサーバ）である。各ＳＰサーバ１５０，１６０は、通信機器（例えばＭＦＰ１０）からデータを取得して保存するデータ保存サービスを実行可能である。また、各ＳＰサーバ１５０，１６０は、通信機器にデータを提供するデータ提供サービスを実行可能である。
【００２２】
ＳＰサーバ１５０は、第１のサービス事業者（即ち第１の会社）によって提供されるサーバであり、ＳＰサーバ１６０は、第１のサービス事業者とは異なる第２のサービス事業者（即ち第２の会社）によって提供されるサーバである。第１のサービス事業者は、ＳＰサーバ１５０からサービスを受けるための第１のＡＰＩを公開しており、第２のサービス事業者は、ＳＰサーバ１６０からサービスを受けるための第２のＡＰＩを公開している。第１のサービス事業者と第２のサービス事業者とが異なるために、通常、第１のＡＰＩと第２のＡＰＩとは異なる。通信機器は、例えば、ＳＰサーバ１５０，１６０の両方からサービスを受けるためには、第１のＡＰＩと第２のＡＰＩとの両方を備えていなければならない。また、例えば、ＭＦＰ１０のベンダは、第１のサービス事業者及び第２のサービス事業者と異なる。
【００２３】
例えば、ＭＦＰ１０が複数個のＳＰサーバ１５０，１６０のそれぞれからサービスを受けるためには、ＭＦＰ１０は、複数個のＡＰＩを備えていなければならないので、多くのプログラムを記憶しなければならない。しかしながら、ＰＣ等と比べると、ＭＦＰ１０のメモリ３４の記憶容量は少ない。従って、本実施例では、ＭＦＰ１０に多くのプログラムを記憶させることなく、ＭＦＰ１０が複数個のＳＰサーバ１５０，１６０のそれぞれからサービスを受けることができるように、ＡＰＩサーバ５０及びＵＬサーバ１００が設けられている。
【００２４】
上述したように、ＡＰＩサーバ５０及びＵＬサーバ１００は、複数個のＳＰサーバ１５０，１６０に対応する複数個のＡＰＩを備えている。そして、ＡＰＩサーバ５０は、ＭＦＰ１０が各ＳＰサーバ１５０，１６０からサービスを受けることができるように、各ＳＰサーバ１５０，１６０に対応する各ＡＰＩを利用して、各ＳＰサーバ１５０，１６０と様々な通信（例えば、後述の図６のコマンド３０２，３１２，３１７等の通信）を実行する。同様に、ＵＬサーバ１００は、各ＳＰサーバ１５０，１６０に対応する各ＡＰＩを利用して、各ＳＰサーバ１５０，１６０と様々な通信（例えば、後述の図７のコマンド４０２等の通信）を実行する。これにより、ＭＦＰ１０は、各ＳＰサーバ１５０，１６０に対応する各ＡＰＩを備えていなくても（即ち多くのプログラムを記憶していなくても）、各ＳＰサーバ１５０，１６０からサービスを受けることができる。また、ＳＰサーバ１５０，１６０の仕様変更が行われる場合に、ＡＰＩサーバ５０及びＵＬサーバ１００のプログラムを変更すれば、ＭＦＰ１０のプログラムを変更しなくても、当該仕様変更に対応することができる。また、新規のＳＰサーバに対応するＡＰＩを備えるように、ＡＰＩサーバ５０及びＵＬサーバ１００のプログラムを変更すれば、ＭＦＰ１０のプログラムを変更しなくても、ＭＦＰ１０は、新規のＳＰサーバからサービスを受けることができる。
【００２５】
（ＳＰサーバ１５０内のフォルダ及びファイルグループの階層構造；図２）
ユーザは、ＳＰサーバ１５０にアカウント情報を登録することによって、ＳＰサーバ１５０からサービスを受けることができる。図２は、ユーザによって登録されたアカウント情報に対応する複数個のフォルダ及び複数個のファイルグループ（以下では「ＦＧ（File Groupの略）」と呼ぶ）の一例を示す。なお、フォルダ及びＦＧの階層構造を採用しているＳＰサーバ１５０の一例として、「Evernote（登録商標）」を挙げることができる。即ち、「Evernote（登録商標）」では、ノートブックがフォルダに対応し、ノートがＦＧに対応する。
【００２６】
各フォルダは、フォルダ名（例えば「Upload from MFP」）と、フォルダＩＤ（例えば「xxxxx」）と、を有する。フォルダ名は、ＳＰサーバ１５０内に新規のフォルダが生成される際に、当該フォルダの生成主体（例えば、ユーザ自身、ＡＰＩサーバ５０等）によって任意に決定される名称である。フォルダＩＤは、ＳＰサーバ１５０内に新規のフォルダが生成される際に、ＳＰサーバ１５０によって決定されるユニークなＩＤである。
【００２７】
各フォルダは、１個以上のＦＧを格納することができる。各ＦＧは、ＦＧ名（例えば「201211301310.xml」）と、ＦＧＩＤ（例えば「yyyyy」）と、を有する。ＦＧ名は、ＳＰサーバ１５０内に新規のＦＧが生成される際に、当該ＦＧの生成主体（例えば、ユーザ自身、ＡＰＩサーバ５０等）によって任意に決定される名称である。ＦＧＩＤは、ＳＰサーバ１５０内に新規のＦＧが生成される際に、ＳＰサーバ１５０によって決定されるユニークなＩＤである。
【００２８】
各ＦＧは、少なくとも文書ファイル（以下では「ＤＦ（Document Fileの略）」と呼ぶ）を含む。ＤＦは、ＸＭＬ（eXtensible Markup Languageの略）形式のファイルであり、少なくともヘッダデータを含む。ヘッダデータは、ＸＭＬのバージョンを表わすデータ（例えば「?xml version=”1.0”」）と、符号化方式を表わすデータ（例えば「encoding=”UTF-8”?」）と、文書タイプや文書の詳細な記述ルールなどの文書構造を定義するためのデータ（例えば「<!DOCTYPE xxx yyy “http://aaa.com/xxx1.dtd”>」）と、を含む。
【００２９】
また、各ＦＧは、ユーザによってアップロードされる１個以上の画像ファイルを含むことが可能である。ＦＧが１個以上の画像ファイルを含む場合には、ＤＦは、さらに、当該１個以上の画像ファイルを特定するための１個以上のテキストデータを含む。図２の例では、ＦＧが２個の画像ファイルを含むために、ＤＦは、２個のテキストデータを含む。画像「Ａ」を表わす画像ファイルを特定するためのテキストデータは、当該画像ファイルのタイプを表わすデータ（例えば「<media type=”image/jpeg”」）と、当該画像ファイルをハッシュ化（即ちダイジェスト化）することによって得られるハッシュ値を表わすデータ（例えば「hash=”a0b1c2d3e4”/>」）と、を含む。また、画像「Ｂ」を表わす画像ファイルを特定するためのテキストデータは、当該画像ファイルのタイプを表わすデータ（例えば「<media type=”image/jpeg”」）と、当該画像ファイルをハッシュ化することによって得られるハッシュ値を表わすデータ（例えば「hash=”f5g6h7i8j9”/>」）と、を含む。
【００３０】
ＳＰサーバ１５０は、図２に示される階層構造を保存しているので、以下のデータ提供サービスを実行することができる。ユーザは、例えばＰＣ等を利用して、ＳＰサーバ１５０にアクセスする。この場合、ＳＰサーバ１５０は、当該ユーザのアカウント情報に対応する複数個のフォルダのフォルダ名の一覧をＰＣに供給する。これにより、ユーザは、フォルダ名の一覧を見ることができる。なお、ユーザは、いずれかのフォルダのフォルダ名を異なる名称に変更することができる。ただし、ユーザは、通常、各フォルダのフォルダＩＤを見ることができず、さらに、フォルダＩＤを変更することができない。
【００３１】
ユーザは、さらに、フォルダ名の一覧の中から１個のフォルダ名を選択することによって、複数個のフォルダの中から１個のフォルダを選択することができる。この場合、ＳＰサーバ１５０は、当該フォルダに含まれる複数個のＦＧのＦＧ名の一覧をＰＣに供給する。これにより、ユーザは、ＦＧ名の一覧を見ることができる。なお、ユーザは、いずれかのＦＧのＦＧ名を異なるＦＧ名に変更することができる。ただし、ユーザは、通常、各ＦＧのＦＧＩＤを見ることができず、さらに、ＦＧＩＤに変更することができない。
【００３２】
ユーザは、さらに、ＦＧ名の一覧の中から１個のＦＧ名を選択することによって、複数個のＦＧの中から１個のＦＧを選択することができる。この場合、ＳＰサーバ１５０は、当該ＦＧに含まれるＤＦを参照して、当該ＦＧに含まれる画像ファイルを特定する。例えば、図２の例では、ＳＰサーバ１５０は、ＦＧ名「201211301310.xml」が選択される場合に、ＤＦに含まれる２個のテキストデータに従って、当該ＦＧに含まれる２個の画像ファイルを特定する。そして、ＳＰサーバ１５０は、特定済みの２個の画像ファイルをＰＣに供給する。これにより、ユーザは、２個の画像ファイルによって表される２個の画像（即ち「Ａ」及び「Ｂ」を表わす２個の画像）を見ることができる。
【００３３】
なお、ユーザは、例えば、第１のＦＧに含まれる画像ファイル（例えば「Ａ」を表わす画像ファイル）が、第２のＦＧにも含まれるように、ＳＰサーバ１５０に要求することができる。この場合、ＳＰサーバ１５０は、当該画像ファイルを特定するためのテキストデータを、第２のＦＧに含まれるＤＦに追加する。これにより、第１のＦＧに含まれるＤＦと第２のＦＧに含まれるＤＦとが同じテキストデータを含むことになる。即ち、ＳＰサーバ１５０は、「Ａ」を表わす画像ファイルを１個しか保存していないが、第１のＦＧ及び第２のＦＧのそれぞれに当該画像ファイルが含まれる状態を形成することができる。
【００３４】
（ＭＦＰ１０が実行する処理；図３）
ＭＦＰ１０は、原稿のスキャンを実行して画像ファイルを生成することができ、当該画像ファイルをＭＦＰ１０内のメモリ３４に保存したり（以下では「通常スキャン」と呼ぶ）、当該画像ファイルをＳＰサーバ１５０，１６０にアップロードしたりすることができる（以下では「スキャンＵＬ」と呼ぶ）。以下では、ユーザがスキャンＵＬを実行する際の、ＭＦＰ１０の動作を説明する。ユーザは、ＭＦＰ１０のディスプレイ１４に表示されるメニュー画面において、「コピー」、「ＦＡＸ」、及び、「スキャン」の中から、「スキャン」を選択し、さらに、「通常スキャン」、及び、「スキャンＵＬ」の中から、「スキャンＵＬ」を選択する。
【００３５】
次いで、ユーザは、ＳＰサーバ１５０に対応するサービス名（例えば「Evernote（登録商標）」と、ＳＰサーバ１６０に対応するサービス名（例えば「Facebook（登録商標）」）と、のどちらかを選択する。即ち、ユーザは、ＳＰサーバ１５０，１６０のどちらに画像ファイルをアップロードするのかを選択する。ＭＦＰ１０の制御部３０は、ＳＰサーバ１５０へのアップロードが選択される場合に、図３の各処理を実行する。
【００３６】
Ｓ２では、制御部３０は、ＦＧ生成コマンドをＡＰＩサーバ５０に送信する。ＦＧ生成コマンドは、ＳＰサーバ１５０内に新規のＦＧを生成するためのコマンドである。ＦＧ生成コマンドは、ＭＦＰ１０のメモリ３４に予め格納されているＡＰＩサーバ５０のＵＲＬ（以下では「特定のＵＲＬ」と呼ぶ）を、要求先ＵＲＬとして含む。ＦＧ生成コマンドは、さらに、ＳＰサーバ１５０に対応するサービス名と、ＳＰサーバ１５０からサービスを受けるための認証情報であるアクセストークン（以下では「ＡＴ（Access Tokenの略）」と呼ぶ）と、を含む。
【００３７】
ユーザは、ＳＰサーバ１５０にアカウント情報（例えば、ユーザＩＤ、パスワード等）を登録する際に、ＳＰサーバ１５０からＡＴを取得することができ、当該ＡＴをＭＦＰ１０に予め格納させておく。これにより、Ｓ２において、制御部３０は、ＡＴを含むＦＧ生成コマンドをＡＰＩサーバ５０に送信することができる。なお、ＡＴは、アカウント情報に基づいて生成される認証情報である。従って、ＳＰサーバ１５０は、ＡＴを含むコマンド（例えば後述の図４のＳ１０２のフォルダ確認コマンド等）を受信する場合に、当該ＡＴに対応するアカウント情報を特定することができる。
【００３８】
詳しくは後述するが、ＡＰＩサーバ５０は、ＭＦＰ１０からＦＧ生成コマンドを受信すると、図４のＳ１００でＹＥＳと判断して、Ｓ１０２〜Ｓ１２４を実行した後に、ＦＧＩＤ通知をＭＦＰ１０に供給する（Ｓ１２６参照）。これにより、Ｓ４において、識別情報取得部４１は、ＡＰＩサーバ５０からＦＧＩＤ通知を取得する。ＦＧＩＤ通知は、ＦＧＩＤと、３個のＵＲＬ（Uniform Resource Locator）と、サービス名と、ＡＴと、を含む。ＦＧＩＤ通知に含まれるＦＧＩＤは、ＳＰサーバ１５０に生成された新規のＦＧのＦＧＩＤである。ＦＧＩＤ通知に含まれる３個のＵＲＬは、ＡＰＩサーバ５０内の位置を示すＵＲＬであり、後述のＳ８、Ｓ１６、及び、Ｓ２４において、コマンド及び情報を送信するための要求先ＵＲＬである。ＦＧＩＤ通知に含まれるサービス名及びＡＴは、Ｓ２で送信されたＦＧ生成コマンドに含まれるサービス名及びＡＴと同じものである。
【００３９】
次いで、Ｓ６では、制御部３０は、スキャン実行部２０にスキャン指示を供給する。これにより、スキャン実行部２０は、Ｎ枚（Ｎは１以上の整数）の原稿のスキャンを実行して、Ｎ個のスキャンデータを生成する。制御部３０は、Ｎ個のスキャンデータに所定の処理（例えば圧縮処理等）を実行して、Ｎ個の画像ファイルを生成する。これにより、ＳＰサーバ１５０にアップロードされるべきＮ個の画像ファイルが生成される。
【００４０】
Ｓ８では、制御部３０は、ＵＲＬ要求コマンドをＡＰＩサーバ５０に送信する。ＵＲＬ要求コマンドは、ＵＬサーバ１００のＵＲＬの送信を、ＡＰＩサーバ５０に要求するためのコマンドである。ＵＲＬ要求コマンドは、Ｓ４で取得されたＦＧＩＤ通知に含まれる３個のＵＲＬのうちの第１のＵＲＬを、要求先ＵＲＬとして含む。ＵＲＬ要求コマンドは、さらに、ＦＧＩＤ通知に含まれる各情報（即ち、ＦＧＩＤ、サービス名、及び、ＡＴ）を含む。
【００４１】
詳しくは後述するが、ＡＰＩサーバ５０は、ＭＦＰ１０からＵＲＬ要求コマンドを受信すると、図４のＳ１３０でＹＥＳと判断して、応答データをＭＦＰ１０に供給する（Ｓ１３２参照）。これにより、Ｓ１０において、制御部３０は、ＡＰＩサーバ５０から応答データを取得する。応答データは、ＵＬサーバ１００のＵＲＬと、ＵＲＬ要求コマンドに含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）と、を含む。
【００４２】
なお、本実施例では、制御部３０は、Ｓ８及びＳ１０の各処理を実行することによって、ＡＰＩサーバ５０からＵＬサーバ１００のＵＲＬを取得する。ただし、変形例では、Ｓ４で取得されるＦＧＩＤ通知は、ＵＬサーバ１００のＵＲＬを含んでいてもよい。この場合、制御部３０は、Ｓ８及びＳ１０の各処理を実行しなくても、Ｓ４でＦＧＩＤ通知を取得することによって、ＡＰＩサーバ５０からＵＬサーバ１００のＵＲＬを取得することができる。
【００４３】
次いで、Ｓ１２では、アップロードコマンド送信部４２は、ＵＬ要求コマンドをＵＬサーバ１００に送信する。ＵＬ要求コマンドは、Ｓ１０で取得された応答データに含まれるＵＬサーバ１００のＵＲＬを、要求先ＵＲＬとして含む。ＵＬ要求コマンドは、さらに、Ｓ６で生成されたＮ個の画像ファイルのうち、未だにアップロードされていない１個の画像ファイルと、Ｓ１０で取得された応答データに含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）と、を含む。
【００４４】
詳しくは後述するが、ＵＬサーバ１００は、ＭＦＰ１０からＵＬ要求コマンドを受信すると、図５のＳ２００でＹＥＳと判断して、Ｓ２０２〜Ｓ２１０を実行した後に、アップロードが成功したのか否かを示す保存結果をＭＦＰ１０に供給する（Ｓ２１２参照）。これにより、Ｓ１４において、制御部３０は、ＵＬサーバ１００から保存結果を取得する。後述するように、保存結果がＡＰＩサーバ５０によって解析されると、例えば、画像ファイルのアップロードの成功、及び、画像ファイルのアップロードの失敗の一方の解析結果が得られる。なお、画像ファイルのアップロードが失敗する状況としては、例えば、当該画像ファイルをアップロードすると、ユーザが利用可能なデータサイズ（即ちＳＰサーバ１５０内のデータサイズ）を超えてしまう状況を挙げることができる。
【００４５】
Ｓ１６では、制御部３０は、Ｓ１４で取得された保存結果をＡＰＩサーバ５０に供給する。保存結果は、Ｓ４で取得されたＦＧＩＤ通知に含まれる３個のＵＲＬのうちの第２のＵＲＬを、要求先ＵＲＬとして含む。
【００４６】
詳しくは後述するが、ＡＰＩサーバ５０は、ＭＦＰ１０から保存結果を受信すると、図４のＳ１４０でＹＥＳと判断して、保存結果の解析を実行し（Ｓ１４２参照）、解析結果をＭＦＰ１０に供給する（Ｓ１４４参照）。これにより、Ｓ１８において、制御部３０は、ＡＰＩサーバ５０から解析結果を取得する。本実施例では、ＭＦＰ１０は、保存結果を解析するためのプログラムを備えていないために、ＡＰＩサーバ５０に保存結果の解析を実行させる。ただし、変形例では、ＭＦＰ１０は、保存結果を解析するためのプログラムを備えていてもよい。この場合、Ｓ１６及びＳ１８の各処理を省略することができる。
【００４７】
次いで、Ｓ２０では、制御部３０は、Ｓ１８で取得された解析結果に基づいて、画像ファイルのアップロードを継続可能であるか否かを判断する。制御部３０は、解析結果がアップロードの成功を示す場合には、画像ファイルのアップロードを継続可能であると判断して（Ｓ２０でＹＥＳ）、Ｓ２２に進む。一方において、制御部３０は、解析結果がアップロードの失敗を示す場合には、画像ファイルのアップロードを継続不可能であると判断して（Ｓ２０でＮＯ）、Ｓ２２及びＳ２４をスキップして、図３の処理を終了する。
【００４８】
Ｓ２２では、制御部３０は、Ｓ６で生成されたＮ個の画像ファイルの全てのアップロードが完了したのか否かを判断する。制御部３０は、Ｎ個の画像ファイルの全てのアップロードが完了した場合には、Ｓ２４に進む。一方において、制御部３０は、Ｎ個の画像ファイルの全てのアップロードが完了していない場合には、Ｓ１２〜Ｓ２２の各処理を再び実行する。Ｎ個の画像ファイルの全てのアップロードが成功する場合には、Ｓ１２〜Ｓ２２の各処理がＮ回繰り返され、Ｎ回目のＳ２２の処理でＹＥＳと判断され、Ｓ２４に進む。
【００４９】
Ｓ２４では、制御部３０は、Ｎ個の画像ファイルの全てのアップロードが完了したことを示す完了通知を、ＡＰＩサーバ５０に送信する。完了通知は、Ｓ４で取得されたＦＧＩＤ通知に含まれる３個のＵＲＬのうちの第３のＵＲＬを、要求先ＵＲＬとして含む。完了通知は、さらに、ＦＧＩＤ通知に含まれる各情報（即ち、ＦＧＩＤ、サービス名、及び、ＡＴ）を含む。
【００５０】
詳しくは後述するが、ＡＰＩサーバ５０は、ＭＦＰ１０から完了通知を受信すると、図４のＳ１５０でＹＥＳと判断して、ＦＧの名称を変更するための各処理を実行する（Ｓ１５２〜Ｓ１５８参照）。
【００５１】
（ＡＰＩサーバ５０が実行する処理；図４）
続いて、図４を参照にして、ＡＰＩサーバ５０の制御部７０が実行する処理について説明する。図４の各処理は、ＡＰＩサーバ５０のためのアプリケーションプログラム及びＳＰサーバ１５０に対応するＡＰＩに従って実現される。当該アプリケーションプログラムは、ＨＴＴＰ（Hyper Text Transfer Protocolの略）通信を実行するためのＨＴＴＰプログラムを含む。そして、ＭＦＰ１０と通信するための各処理（即ち、Ｓ１００、Ｓ１２６、Ｓ１３０、Ｓ１３２、Ｓ１４０、Ｓ１４４、Ｓ１５０）は、ＨＴＴＰプログラムに従って実行される。一方において、ＳＰサーバ１５０と通信するための各処理（即ち、Ｓ１０２〜Ｓ１２４、Ｓ１５２〜Ｓ１５８）は、ＳＰサーバ１５０に対応するＡＰＩに従って実行される。
【００５２】
制御部７０は、Ｓ１００、Ｓ１３０、Ｓ１４０、及び、Ｓ１５０において、ＭＦＰ１０から様々な情報を受信（即ち取得）することを監視している。具体的に言うと、制御部７０は、ＭＦＰ１０から受信される情報に含まれる要求先ＵＲＬを参照して、どの種の情報が受信されたのか否かを判断する。即ち、生成コマンド受信部８１は、上記の特定のＵＲＬを含むＦＧ生成コマンド（図３のＳ２参照）を受信する場合には、Ｓ１００でＹＥＳと判断して、Ｓ１０２に進む。また、制御部７０は、上記の第１のＵＲＬを含むＵＲＬ要求コマンド（図３のＳ８参照）を受信する場合には、Ｓ１３０でＹＥＳと判断して、Ｓ１３２に進む。また、制御部７０は、上記の第２のＵＲＬを含む保存結果（図３のＳ１６参照）を受信する場合には、Ｓ１４０でＹＥＳと判断して、Ｓ１４２に進む。また、制御部７０は、上記の第３のＵＲＬを含む完了通知（図３のＳ２４参照）を受信する場合には、Ｓ１５０でＹＥＳと判断して、Ｓ１５２に進む。なお、制御部７０は、ＭＦＰ１０からの様々な情報を受信しない期間は、Ｓ１００、Ｓ１３０、Ｓ１４０、及び、Ｓ１５０でＮＯと判断し続ける（即ち、様々な情報を受信することを監視し続ける）。
【００５３】
上述したように、Ｓ１００で受信されるＦＧ生成コマンドは、ＳＰサーバ１５０に対応するサービス名と、ＡＴと、を含む（図３のＳ２の説明参照）。Ｓ１０２では、制御部７０は、ＦＧ生成コマンドに含まれるサービス名を参照して、複数個のＳＰサーバ１５０，１６０のうちのＳＰサーバ１５０に画像ファイルをアップロードすべきことを決定する。そして、制御部７０は、フォルダ確認コマンドをＳＰサーバ１５０に送信する。フォルダ確認コマンドは、フォルダ名「Upload from MFP」を有するフォルダ（以下では「対象フォルダ」と呼ぶ）がＳＰサーバ１５０内に存在するのか否かを確認するためのコマンドである。フォルダ確認コマンドは、Ｓ１００で受信されたＦＧ生成コマンドに含まれるＡＴを含む。なお、後述のＳ１１２の処理が過去に実行された場合には、対象フォルダがＳＰサーバ１５０内に存在し得る。
【００５４】
ＳＰサーバ１５０は、ＡＰＩサーバ５０からフォルダ確認コマンドを受信すると、フォルダ確認コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダの中に、フォルダ名「Upload from MFP」を有する対象フォルダが存在するのか否かを判断する。ＳＰサーバ１５０は、対象フォルダが存在すると判断する場合に、対象フォルダが存在することを示すフォルダ確認結果をＡＰＩサーバ５０に供給し、対象フォルダが存在しないと判断する場合に、対象フォルダが存在しないことを示すフォルダ確認結果をＡＰＩサーバ５０に供給する。
【００５５】
Ｓ１０４では、制御部７０は、ＳＰサーバ１５０からフォルダ確認結果を取得する。次いで、Ｓ１１０では、制御部７０は、対象フォルダが存在することを示すフォルダ確認結果が取得されたのか、対象フォルダが存在しないことを示すフォルダ確認結果が取得されたのか、を判断する。制御部７０は、対象フォルダが存在することを示すフォルダ確認結果が取得された場合には、Ｓ１１０でＹＥＳと判断して、Ｓ１１２をスキップして、Ｓ１１４に進む。一方において、制御部７０は、対象フォルダが存在しないことを示すフォルダ確認結果が取得された場合には、Ｓ１１０でＮＯと判断して、Ｓ１１２に進む。
【００５６】
Ｓ１１２では、制御部７０は、フォルダ生成コマンドをＳＰサーバ１５０に送信する。フォルダ生成コマンドは、新規のフォルダ（即ち対象フォルダ）の生成を、ＳＰサーバ１５０に要求するためのコマンドである。フォルダ生成コマンドは、予め決められているフォルダ名「Upload from MFP」と、Ｓ１００で受信されたＦＧ生成コマンドに含まれるＡＴと、を含む。
【００５７】
ＳＰサーバ１５０は、ＡＰＩサーバ５０からフォルダ生成コマンドを受信すると、フォルダ生成コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する新規のフォルダを生成する。また、ＳＰサーバ１５０は、フォルダ生成コマンドに含まれるフォルダ名「Upload from MFP」を、新規のフォルダのフォルダ名として決定する。そして、ＳＰサーバ１５０は、ユニークなフォルダＩＤを、新規のフォルダのフォルダＩＤとして決定する。このようにして新規のフォルダ（即ち、フォルダ名「Upload from MFP」を有する対象フォルダ）が生成されると、ＳＰサーバ１５０は、当該新規のフォルダ内に新規のＦＧ（ファイルグループ；図２参照）を生成することができ、さらに、当該新規のＦＧ内に画像ファイルが含まれるように、画像ファイルを保存することができる。なお、以下では、このようなアップロード対象のＦＧのことを、「対象ＦＧ」と呼ぶ。
【００５８】
Ｓ１１０でＹＥＳと判断された後、又は、Ｓ１１２の後、Ｓ１１４では、制御部７０は、フォルダＩＤ要求コマンドをＳＰサーバ１５０に送信する。フォルダＩＤ要求コマンドは、対象フォルダのフォルダＩＤの送信を、ＳＰサーバ１５０に要求するためのコマンドである。フォルダＩＤ要求コマンドは、フォルダ名「Upload from MFP」と、Ｓ１００で受信されたＦＧ生成コマンドに含まれるＡＴと、を含む。
【００５９】
ＳＰサーバ１５０は、ＡＰＩサーバ５０からフォルダＩＤ要求コマンドを受信すると、フォルダＩＤ要求コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダの複数個のフォルダＩＤの中から、フォルダＩＤ要求コマンドに含まれるフォルダ名「Upload from MFP」を有する対象フォルダのフォルダＩＤを特定する。次いで、ＳＰサーバ１５０は、特定済みのフォルダＩＤをＡＰＩサーバ５０に供給する。
【００６０】
Ｓ１１６では、制御部７０は、ＳＰサーバ１５０からフォルダＩＤを取得する。次いで、Ｓ１１８では、生成部８２は、新規のＤＦ（文書ファイル；図２参照）を生成する。以下では、Ｓ１１８で生成されるＤＦのことを、「初期ＤＦ」と呼ぶ。初期ＤＦは、画像ファイルに対応するテキストデータを含まず、ヘッダデータのみを含む。
【００６１】
次いで、Ｓ１２０では、生成部８２は、新規のＦＧ（即ち対象ＦＧ）のＦＧ名を生成する。具体的に言うと、生成部８２は、「Uploading」という文字列を示すＦＧ名を生成する。これにより、仮に、ユーザが、「Uploading」を示すＦＧ名を見た場合に、対象ＦＧに画像ファイルがアップロードされている最中であることを知ることができる。以下では、Ｓ１２０で生成されるＦＧ名のことを、「仮ＦＧ名」と呼ぶ。
【００６２】
次いで、Ｓ１２２では、保存制御部８３は、ＦＧＩＤ要求コマンドをＳＰサーバ１５０に送信する。ＦＧＩＤ要求コマンドは、新規のＦＧ（即ち対象ＦＧ）の生成と、当該新規のＦＧのＦＧＩＤの送信と、をＳＰサーバ１５０に要求するためのコマンドである。ＦＧＩＤ要求コマンドは、Ｓ１１６で取得されたフォルダＩＤと、Ｓ１１８で生成された初期ＤＦと、Ｓ１２０で生成された仮ＦＧ名と、Ｓ１００で受信されたＦＧ生成コマンドに含まれるＡＴと、を含む。
【００６３】
ＳＰサーバ１５０は、ＡＰＩサーバ５０からＦＧＩＤ要求コマンドを受信すると、ＦＧＩＤ要求コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダの中から、ＦＧＩＤ要求コマンドに含まれるフォルダＩＤを有する対象フォルダを特定する。次いで、ＳＰサーバ１５０は、特定済みの対象フォルダ内に新規のＦＧを生成する。以下では、ここで生成されるＦＧのことを、「初期ＦＧ」と呼ぶ。初期ＦＧは、ＦＧＩＤ要求コマンドに含まれる初期ＤＦを含む。ただし、このとき、初期ＦＧは、いずれの画像ファイルも含まない。ＳＰサーバ１５０は、ＦＧＩＤ要求コマンドに含まれる仮ＦＧ名を、初期ＦＧのＦＧ名として決定する。また、ＳＰサーバ１５０は、ユニークなＦＧＩＤを、初期ＦＧのＦＧＩＤとして決定する。そして、ＳＰサーバ１５０は、初期ＦＧのＦＧＩＤをＡＰＩサーバ５０に供給する。
【００６４】
次いで、Ｓ１２４では、制御部７０は、ＳＰサーバ１５０からＦＧＩＤを取得する。そして、Ｓ１２６では、識別情報供給部８４は、ＦＧＩＤ通知をＭＦＰ１０に供給する。ＦＧＩＤ通知は、Ｓ１２４で受信されたＦＧＩＤと、上記の第１〜第３のＵＲＬと、Ｓ１００で受信されたＦＧ生成コマンドに含まれる各情報（即ち、サービス名及びＡＴ）と、を含む。これにより、図３のＳ４において、ＭＦＰ１０は、ＡＰＩサーバ５０からＦＧＩＤ通知を取得する。なお、上記の第１〜第３のＵＲＬは、ＡＰＩサーバ５０のメモリ７４に予め格納されている。
【００６５】
上述したように、Ｓ１３０で受信されるＵＲＬ要求コマンドは、ＦＧＩＤと、サービス名と、ＡＴと、を含む（図３のＳ８の説明参照）。Ｓ１３２では、位置情報供給部８６は、応答データをＭＦＰ１０に供給する。応答データは、ＡＰＩサーバ５０のメモリ７４に予め格納されているＵＬサーバ１００のＵＲＬと、ＵＲＬ要求コマンドに含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）と、を含む。これにより、図３のＳ１０において、ＭＦＰ１０は、ＡＰＩサーバ５０から応答データを取得する。
【００６６】
Ｓ１４０で保存結果が取得される場合には、Ｓ１４２において、制御部７０は、保存結果を解析して、解析結果を生成する。解析結果は、ＭＦＰ１０が解釈可能なデータ形式を有する。そして、Ｓ１４４では、制御部７０は、解析結果をＭＦＰ１０に供給する。これにより、図３のＳ１８において、ＭＦＰ１０は、ＡＰＩサーバ５０から解析結果を取得する。
【００６７】
上述したように、Ｓ１５０で取得される完了通知は、ＦＧＩＤと、サービス名と、ＡＴと、を含む（図３のＳ２４の説明参照）。Ｓ１５２では、制御部７０は、完了通知に含まれるサービス名を参照して、複数個のＳＰサーバ１５０，１６０のうちのＳＰサーバ１５０への各画像ファイルのアップロードが完了したことを知ることができる。そして、制御部７０は、ＤＦ要求コマンドをＳＰサーバ１５０に送信する。ＤＦ要求コマンドは、アップロード済みの各画像ファイルに対応する各テキストデータを含むＤＦ（以下では「最終ＤＦ」と呼ぶ）の送信を、ＳＰサーバ１５０に要求するためのコマンドである。ＤＦ要求コマンドは、Ｓ１５０で取得された完了通知に含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）を含む。
【００６８】
ＳＰサーバ１５０は、ＡＰＩサーバ５０からＤＦ要求コマンドを受信すると、ＤＦ要求コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダに含まれる複数個のＦＧの中から、ＤＦ要求コマンドに含まれるＦＧＩＤを有するＦＧ（即ち対象ＦＧ）を特定する。次いで、ＳＰサーバ１５０は、特定済みの対象ＦＧに含まれる最終ＤＦをＡＰＩサーバ５０に供給する。
【００６９】
次いで、Ｓ１５４では、制御部７０は、ＡＰＩサーバ５０から最終ＤＦと、現在のＦＧ名と、を取得する。なお、対象ＦＧの現在のＦＧ名は、「Uploading」を示す仮ＦＧ名である（Ｓ１２０参照）。そして、Ｓ１５６では、名称変更部８５は、対象ＦＧの新規のＦＧ名を生成する。具体的に言うと、名称変更部８５は、現在の日時を示すＦＧ名を生成する。以下では、Ｓ１５６で生成されるＦＧ名のことを、「正式ＦＧ名」と呼ぶ。
【００７０】
次いで、Ｓ１５８では、名称変更部８５は、名称変更コマンドをＳＰサーバ１５０に送信する。名称変更コマンドは、対象ＦＧのＦＧ名の変更（即ち仮ＦＧ名から正式ＦＧ名への変更）を、ＳＰサーバ１５０に要求するためのコマンドである。名称変更コマンドは、Ｓ１５４で取得された最終ＤＦと、Ｓ１５６で生成された正式ＦＧ名と、Ｓ１５０で取得された完了通知に含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）と、を含む。
【００７１】
ＳＰサーバ１５０は、ＡＰＩサーバ５０から名称変更コマンドを受信すると、名称変更コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダに含まれる複数個のＦＧの中から、名称変更コマンドに含まれるＦＧＩＤを有する対象ＦＧを特定する。そして、ＳＰサーバ１５０は、特定済みの対象ＦＧのＦＧ名を、仮ＦＧ名から、名称変更コマンドに含まれる正式ＦＧ名に変更する。これにより、仮に、ユーザが、日時を示すＦＧ名を見た場合に、対象ＦＧに画像ファイルがアップロードされた日時を知ることができる。
【００７２】
（ＵＬサーバ１００が実行する処理；図５）
続いて、図５を参照にして、ＵＬサーバ１００が実行する処理について説明する。図５の各処理は、ＵＬサーバ１００のメモリ１２４に格納されているアプリケーションプログラムに従って実現される。当該アプリケーションプログラムは、ＨＴＴＰ通信を実行するためのＨＴＴＰプログラムを含む。そして、ＭＦＰ１０と通信するための各処理（即ち、Ｓ２００、Ｓ２１２）は、ＨＴＴＰプログラムに従って実行される。一方において、ＳＰサーバ１５０と通信するための各処理（即ち、Ｓ２０２〜Ｓ２１０）は、ＳＰサーバ１５０に対応するＡＰＩに従って実行される。
【００７３】
Ｓ２００では、アップロードコマンド受信部１３１は、ＭＦＰ１０からＵＬ要求コマンド（図３のＳ１２参照）を受信することを監視している。アップロードコマンド受信部１３１は、ＵＬ要求コマンドを受信する場合に、Ｓ２００でＹＥＳと判断して、Ｓ２０２に進む。なお、制御部７０は、ＭＦＰ１０からＵＬ要求コマンドを受信しない期間は、Ｓ２００にてＮＯと判断し続ける（即ち、ＵＬ要求コマンドを受信することを監視し続ける）。
【００７４】
上述したように、Ｓ２００で受信されるＵＬ要求コマンドは、ＦＧＩＤと、１個の画像ファイルと、ＡＴと、を含む（図３のＳ１２の説明参照）。Ｓ２０２では、ファイル取得部１４１は、ＤＦ要求コマンドをＳＰサーバ１５０に送信する。ＤＦ要求コマンドは、対象ＦＧに含まれる現在のＤＦ（以下では「現行ＤＦ」と呼ぶ）の送信を、ＳＰサーバ１５０に要求するためのコマンドである。ＤＦ要求コマンドは、Ｓ２００で受信されたＵＬ要求コマンドに含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）を含む。
【００７５】
ＳＰサーバ１５０は、ＵＬサーバ１００からＤＦ要求コマンドを受信すると、ＤＦ要求コマンドに含まれるＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダに含まれる複数個のＦＧの中から、ＤＦ要求コマンドに含まれるＦＧＩＤを有する対象ＦＧを特定する。次いで、ＳＰサーバ１５０は、特定済みの対象ＦＧに含まれる現行ＤＦをＵＬサーバ１００に供給する。
【００７６】
次いで、Ｓ２０４では、ファイル取得部１４１は、ＳＰサーバ１５０から現行ＤＦを取得する。例えば、図３のＳ６で生成されたＮ個の画像ファイルのうちのアップロード済みの画像ファイルの個数がゼロである場合には、Ｓ２０４で取得される現行ＤＦは、初期ＤＦ（図４のＳ１１８参照）である。また、例えば、Ｎ個の画像ファイルのうちのアップロード済みの画像ファイルの個数がＭ（Ｍは１以上Ｎ未満の整数）である場合には、Ｓ２０４で取得される現行ＤＦは、Ｍ個の画像ファイルを特定するためのＭ個のテキストデータが初期ＤＦに追加されたものである。
【００７７】
そして、Ｓ２０６では、追加部１４２は、Ｓ２００で受信されたＵＬ要求コマンドに含まれる１個の画像ファイルのタイプを表わすデータ（例えば「<media type=”image/jpeg”」）を生成する。Ｓ２０６では、追加部１４２は、さらに、当該画像ファイルをハッシュ化することによって、ハッシュ値を表わすデータ（例えば「hash=”a0b1c2d3e4”/>」）を生成する。これにより、追加部１４２は、１個のテキストデータ（画像ファイルのタイプを表わすデータ、及び、ハッシュ値を表わすデータの組合せ）を生成することができる。次いで、追加部１４２は、Ｓ２０４で取得された現行ＤＦに、生成済みのテキストデータを追加することによって、変更後ＤＦを生成する。
【００７８】
さらに、Ｓ２０８では、ファイル供給部１４３は、Ｓ２００で受信されたＵＬ要求コマンドに含まれる１個の画像ファイルと、Ｓ２０６で生成された変更後ＤＦと、Ｓ２００で取得されたＵＬ要求コマンドに含まれる各情報（即ち、ＦＧＩＤ及びＡＴ）と、をＳＰサーバ１５０に供給する。
【００７９】
ＳＰサーバ１５０は、ＵＬサーバ１００から、ＦＧＩＤと、画像ファイルと、変更後ＤＦと、ＡＴと、を取得すると、当該ＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダに含まれる複数個のＦＧの中から、ＦＧＩＤを有する対象ＦＧを特定する。次いで、ＳＰサーバ１５０は、特定済みの対象ＦＧに含まれる現行ＤＦを、変更後ＤＦに変更する。さらに、ＳＰサーバ１５０は、画像ファイルを保存する。これにより、１個の画像ファイルがアップロードされることになる。
【００８０】
ＳＰサーバ１５０は、画像ファイルのアップロードが成功する場合には、アップロードの成功を示す保存結果をＵＬサーバ１００に供給する。一方において、例えば、画像ファイルをアップロードすると、ユーザが利用可能なＳＰサーバ１５０内のデータサイズを超えてしまう場合には、ＳＰサーバ１５０は、画像ファイルを保存せずに、アップロードの失敗を示す保存結果をＵＬサーバ１００に供給する。
【００８１】
そして、Ｓ２１０では、制御部１２０は、ＳＰサーバ１５０から保存結果を取得する。次いで、Ｓ２１２では、結果情報供給部１３３は、Ｓ２１０で取得された保存結果をＭＦＰ１０に供給する。これにより、ＭＦＰ１０は、図３のＳ１６において、ＵＬサーバ１００から保存結果を取得する。
【００８２】
Ｓ２１２を終えると、Ｓ２００に戻る。制御部１２０は、ＭＦＰ１０からＵＬ要求コマンドを受信する毎に、Ｓ２０２〜Ｓ２１２の各処理を実行する。即ち、制御部１２０は、Ｎ個の画像ファイルを含むＮ個のＵＬ要求コマンドのそれぞれを順次受信して、Ｎ個の画像ファイルのそれぞれをＳＰサーバ１５０に順次アップロードする。
【００８３】
（具体例；図６〜図８）
続いて、図６〜図８を参照して、各デバイス１０，５０，１００，１５０によって実行される各処理の具体例を説明する。図６〜図８の各処理は、各デバイス１０，５０，１００が図３〜図５のフローチャートを実行することによって実現される。
【００８４】
ＭＦＰ１０は、ＦＧ生成コマンド３００をＡＰＩサーバ５０に送信する（図３のＳ２）。ＦＧ生成コマンド３００は、ＳＰサーバ１５０に対応するサービス名と、ＡＴと、を含む。
【００８５】
ＡＰＩサーバ５０は、ＦＧ生成コマンド３００を受信すると（図４のＳ１００でＹＥＳ）、ＡＴを含むフォルダ確認コマンド３０２をＳＰサーバ１５０に送信する（Ｓ１０２）。
【００８６】
ＳＰサーバ１５０は、フォルダ確認コマンド３０２を受信すると、フォルダ名「Upload from MFP」を有する対象フォルダが存在するのか否かを判断して、フォルダ確認結果３０４をＡＰＩサーバ５０に供給する。図６の例では、対象フォルダが存在しないので、フォルダ確認結果３０４は、対象フォルダが存在しないことを示す。
【００８７】
ＡＰＩサーバ５０は、フォルダ確認結果３０４を取得すると（図４のＳ１０４）、ＳＰサーバ１５０内に対象フォルダが存在しないと判断する（Ｓ１１０でＮＯ）。次いで、ＡＰＩサーバ５０は、「Upload from MFP」というフォルダ名３０８とＡＴとを含むフォルダ生成コマンド３０６を、ＳＰサーバ１５０に送信する（Ｓ１１２）。
【００８８】
ＳＰサーバ１５０は、フォルダ生成コマンド３０６を受信すると、フォルダ名３０８を有する新規のフォルダ３１０（即ち対象フォルダ３１０）を生成する。この際に、ＳＰサーバ１５０は、フォルダ３１０のフォルダＩＤ３１４を決定する。
【００８９】
ＡＰＩサーバ５０は、フォルダ生成コマンド３０６を送信した後に、フォルダ名３０８とＡＴとを含むフォルダＩＤ要求コマンド３１２を、ＳＰサーバ１５０に送信する（図４のＳ１１４）。
【００９０】
ＳＰサーバ１５０は、フォルダＩＤ要求コマンド３１２を受信すると、対象フォルダ３１０のフォルダＩＤ３１４をＡＰＩサーバ５０に供給する。
【００９１】
ＡＰＩサーバ５０は、フォルダＩＤ３１４を取得すると（図４のＳ１１６）、初期ＤＦ３１６ａを生成する（図４のＳ１１８）。なお、図１０は、初期ＤＦ３１６ａの一例を示す。初期ＤＦ３１６ａは、画像ファイルを特定するためのテキストデータを含まない。ＡＰＩサーバ５０は、さらに、仮ＦＧ名「Uploading」を生成する（Ｓ１２０）。次いで、ＡＰＩサーバ５０は、フォルダＩＤ３１４と、初期ＤＦ３１６ａと、仮ＦＧ名と、ＡＴと、を含むＦＧＩＤ要求コマンド３１７を、ＳＰサーバ１５０に送信する（Ｓ１２２）。
【００９２】
ＳＰサーバ１５０は、ＦＧＩＤ要求コマンド３１７を受信すると、ＦＧＩＤ要求コマンド３１７に含まれるフォルダＩＤ３１４を有する対象フォルダ３１０内に、初期ＦＧ３１８ａ（図１０参照）を生成する。初期ＦＧ３１８ａは、ＦＧＩＤ要求コマンド３１７に含まれる初期ＤＦ３１６ａを含むが、いずれの画像ファイルも含まない。次いで、ＳＰサーバ１５０は、ＦＧＩＤ要求コマンド３１７に含まれる仮ＦＧ名を、初期ＦＧ３１８ａのＦＧ名として決定する。ＳＰサーバ１５０は、さらに、初期ＦＧ３１８ａのＦＧＩＤ３２０を決定して、ＦＧＩＤ３２０をＡＰＩサーバ５０に供給する。
【００９３】
ＡＰＩサーバ５０は、ＦＧＩＤ３２０を取得すると（図４のＳ１２４）、ＦＧＩＤ３２０と、ＡＰＩサーバの３個のＵＲＬ（即ち、第１のＵＲＬ３２４、第２のＵＲＬ３２６、第３のＵＲＬ３２８）と、サービス名と、ＡＴと、を含むＦＧＩＤ通知３２２を、ＭＦＰ１０に供給する（Ｓ１２６）。
【００９４】
ＭＦＰ１０は、ＦＧＩＤ通知３２２を取得すると（図３のＳ４）、Ｎ個の画像ファイルを生成する（Ｓ６）。次いで、ＭＦＰ１０は、要求先ＵＲＬとして第１のＵＲＬ３２４（ＦＧＩＤ通知３２２参照）を含むＵＲＬ要求コマンド３３０を、ＡＰＩサーバ５０に送信する（Ｓ８）。ＵＲＬ要求コマンド３３０は、ＦＧＩＤ３２０と、サービス名と、ＡＴと、を含む。
【００９５】
ＡＰＩサーバ５０は、ＵＬ要求コマンド３３０を受信すると（図４のＳ１３０でＹＥＳ）、ＵＬサーバＵＲＬ３３２と、ＦＧＩＤ３２０と、ＡＴと、を含む応答データを、ＭＦＰ１０に供給する（Ｓ１３２）。
【００９６】
図７に示されるように、ＭＦＰ１０は、応答データを取得すると（図３のＳ１０）、要求先ＵＲＬとしてＵＬサーバＵＲＬ３３２を含むＵＬ要求コマンド４００を、ＵＬサーバ１００に送信する（Ｓ１２）。ＵＬ要求コマンド４００は、ＦＧＩＤ３２０と、１個の画像ファイル２００と、ＡＴと、を含む。
【００９７】
ＵＬサーバ１００は、ＵＬ要求コマンド４００を受信すると（図５のＳ２００でＹＥＳ）、ＦＧＩＤ３２０とＡＴとを含むＤＦ要求コマンド４０２を、ＳＰサーバ１５０に送信する（Ｓ２０２）。
【００９８】
ＳＰサーバ１５０は、ＤＦ要求コマンド４０２を受信すると、ＤＦ要求コマンド４０２に含まれるＦＧＩＤ３２０を有する初期ＦＧ３１８ａを特定して、特定済みの初期ＦＧ３１８ａに含まれる初期ＤＦ３１６ａをＵＬサーバ１００に供給する。
【００９９】
ＵＬサーバ１００は、初期ＤＦ３１６ａを取得すると（図５のＳ２０４）、画像ファイル２００を特定するためのテキストデータを初期ＤＦ３１６ａに追加する（Ｓ２０６）。これにより、変更後ＤＦ３１６ｂが生成される。図１０に示されるように、変更後ＤＦ３１６ｂは、画像ファイル２００を特定するための１個のテキストデータを含む。次いで、ＵＬサーバ１００は、ＦＧＩＤ３２０と画像ファイル２００と変更後ＤＦ３１６ｂとＡＴとをＳＰサーバ１５０に供給する（Ｓ２０８）。
【０１００】
ＳＰサーバ１５０は、ＦＧＩＤ３２０と画像ファイル２００と変更後ＤＦ３１６ｂとＡＴとを取得すると、ＡＴとＦＧＩＤ３２０とに基づいて、ＳＰサーバ１５０内の初期ＦＧ３１８ａを特定する。次いで、ＳＰサーバ１５０は、特定済みの初期ＦＧ３１８ａに含まれる初期ＤＦ３１６ａを変更後ＤＦ３１６ｂに変更し、さらに、画像ファイル２００を保存することによって、変更後ＦＧ３１８ｂを生成する。図１０に示されるように、変更後ＦＧ３１８ｂは、変更後ＤＦ３１６ｂと、画像ファイル２００と、を含む。次いで、ＳＰサーバ１５０は、アップロードの成功を示す保存結果４０６をＵＬサーバ１００に供給する。
【０１０１】
ＵＬサーバ１００は、保存結果４０６を取得すると（図５のＳ２１０）、保存結果４０６をＭＦＰ１０に供給する（Ｓ２１２）。
【０１０２】
ＭＦＰ１０は、保存結果４０６を取得すると（図３のＳ１４）、要求先ＵＲＬとして第２のＵＲＬ３２６（図６のＦＧＩＤ通知３２２参照）を含む保存結果４０６を、ＡＰＩサーバ５０に供給する（Ｓ１６）。
【０１０３】
ＡＰＩサーバ５０は、保存結果４０６を取得すると（図４のＳ１４０でＹＥＳ）、保存結果４０６を解析する（Ｓ１４２）。次いで、ＡＰＩサーバ５０は、アップロードの成功を示す解析結果４０８をＭＦＰ１０に供給する（Ｓ１４４）。
【０１０４】
ＭＦＰ１０は、解析結果４０８を取得すると（図３のＳ１８）、解析結果４０８に基づいて、画像ファイルのアップロードの継続が可能か否かを判断する（Ｓ２０）。ここでは、ＭＦＰ１０は、アップロードの継続が可能であると判断する（Ｓ２０でＹＥＳ）。次いで、ＭＦＰ１０は、要求先ＵＲＬとしてＵＬサーバＵＲＬ３３２を含むＵＬ要求コマンド４１０を、ＵＬサーバ１００に送信する（Ｓ１２）。ＵＬ要求コマンド４１０は、ＦＧＩＤ３２０と、１個の画像ファイル２５０と、ＡＴと、を含む。
【０１０５】
ＵＬサーバ１００は、ＵＬ要求コマンド４１０を受信すると（図５のＳ２００でＹＥＳ）、ＦＧＩＤ３２０とＡＴとを含むＤＦ要求コマンド４１２を、ＳＰサーバ１５０に送信する（図５のＳ２０２）。
【０１０６】
ＳＰサーバ１５０は、ＤＦ要求コマンド４１２を受信すると、ＤＦ要求コマンド４１２に含まれるＦＧＩＤ３２０を有する現行ＦＧ３１８ｂを特定して、特定済みの現行ＦＧ３１８ｂに含まれる現行ＤＦ３１６ｂをＵＬサーバ１００に供給する。
【０１０７】
ＵＬサーバ１００は、現行ＤＦ３１６ｂを取得すると（図５のＳ２０４）、画像ファイル２５０を特定するためのテキストデータを現行ＤＦ３１６ｂに追加する（Ｓ２０６）。これにより、変更後ＤＦ３１６ｃが生成される。図１０に示されるように、変更後ＤＦ３１６ｃは、２個の画像ファイル２００，２５０を特定するための２個のテキストデータを含む。次いで、ＵＬサーバ１００は、ＦＧＩＤ３２０と画像ファイル２５０と変更後ＤＦ３１６ｃとＡＴとをＳＰサーバ１５０に供給する（Ｓ２０８）。
【０１０８】
ＳＰサーバ１５０は、ＦＧＩＤ３２０と画像ファイル２５０と変更後ＤＦ３１６ｃとＡＴとを取得すると、ＡＴとＦＧＩＤ３２０とに基づいて、ＳＰサーバ１５０内の現行ＦＧ３１８ｂを特定する。次いで、ＳＰサーバ１５０は、特定済みの現行ＦＧ３１８ｂに含まれる現行ＤＦ３１６ｂを変更後ＤＦ３１６ｃに変更し、さらに、画像ファイル２５０を保存することによって、変更後ＦＧ３１８ｃを生成する。図１０に示されるように、変更後ＦＧ３１８ｃは、変更後ＤＦ３１６ｃと、２個の画像ファイル２００，２５０と、を含む。次いで、ＳＰサーバ１５０は、アップロードの成功を示す保存結果４１６をＵＬサーバ１００に供給する。
【０１０９】
保存結果４０６の場合と同様に、保存結果４１６は、ＭＦＰ１０を経由して、ＵＬサーバ１００からＡＰＩサーバ５０に供給される。この結果、解析結果４１８が、ＡＰＩサーバ５０からＭＦＰ１０に供給される。ＵＬ要求コマンド４１０の通信から解析結果４１８の通信までの各処理が、（Ｎ−１）回繰り返される。即ち、Ｎ個の画像ファイルの全てがアップロードされるまで上記の各処理が繰り返される。
【０１１０】
（ケースＡ）
以下では、Ｎが２である場合を例として、図８のケースＡを説明する。即ち、画像ファイル２００，２５０のアップロードが完了すると、Ｎ個の画像ファイルの全てのアップロードが完了する。従って、図１０に示される変更後ＤＦ３１６ｃは、Ｎ個の画像ファイルを特定するためのＮ個のテキストデータを含む最終ＤＦ（図４のＳ１５４参照）である。
【０１１１】
図８のケースＡに示されるように、ＭＦＰ１０は、要求先ＵＲＬとして第３のＵＲＬ３２８（図６のＦＧＩＤ通知３２２参照）を含む完了通知４２０を、ＡＰＩサーバ５０に供給する（図３のＳ２４）。完了通知４２０は、ＦＧＩＤ３２０と、サービス名と、ＡＴと、を含む。
【０１１２】
ＡＰＩサーバ５０は、完了通知４２０を取得すると（図４のＳ１５０でＹＥＳ）、ＦＧＩＤ３２０とＡＴとを含むＤＦ要求コマンド４２２を、ＳＰサーバ１５０に送信する（１５２）。
【０１１３】
ＳＰサーバ１５０は、ＤＦ要求コマンド４２２を受信すると、最終ＤＦ３１６ｃをＡＰＩサーバ５０に供給する。
【０１１４】
ＡＰＩサーバ５０は、最終ＤＦ３１６ｃを取得すると（図４のＳ１５４）、現在の日時を示す正式ＦＧ名を生成する（Ｓ１５６）。次いで、ＡＰＩサーバ５０は、ＦＧＩＤ３２０と最終ＤＦ３１６ｃと正式ＦＧ名とＡＴとを含む名称変更コマンド４２４を、ＳＰサーバ１５０に送信する（Ｓ１５８）。
【０１１５】
ＳＰサーバ１５０は、名称変更コマンド４２４を受信すると、名称変更コマンド４２４に含まれるＦＧＩＤ３２０とＡＴとに基づいて、ＳＰサーバ１５０内の現行ＦＧ３１８ｃを特定する。次いで、ＳＰサーバ１５０は、特定済みの現行ＦＧ３１８ｃの名称を、仮ＦＧ名から正式ＦＧ名に変更する。
【０１１６】
このように、本実施例では、Ｎ個の画像ファイルのアップロードが完了するまで、対象ＦＧ（即ちＦＧ３１８ａ，３１８ｂ）のＦＧ名として、仮ＦＧ名「Uploading」が利用される。このために、ユーザは、例えばＰＣ等を利用して、ＳＰサーバ１５０にアクセスすれば、仮ＦＧ名を見ることができ、この結果、仮ＦＧ名を有する対象ＦＧが画像ファイルのアップロード中であることを知ることができる。従って、アップロードを妨げる操作（例えば、対象ＦＧに他のファイルをアップロードさせるための操作、対象ＦＧからファイルを取得するための操作等）が、ユーザによって実行されるのを抑制することができる。また、Ｎ個の画像ファイルのアップロードが完了すると、対象ＦＧ（即ちＦＧ３１８ｃ）のＦＧ名として、正式ＦＧ名が利用される。この結果、ユーザは、正式ＦＧ名を見ることによって、画像ファイルのアップロードが完了され、さらにアップロードが実行された日時を知ることができる。
【０１１７】
（ケースＢ）
図７のケースでは、各画像ファイル２００，２５０のアップロードが成功する。これに対し、図８のケースＢでは、画像ファイル２００のアップロードが失敗する。ケースＢにおいて、ＭＦＰ１０からＵＬサーバ１００へのＵＬ要求コマンド４００の送信から、ＵＬサーバ１００からＳＰサーバ１５０へのＦＧＩＤ３２０と変更後ＤＦ３１６ｂと画像ファイル２００とＡＴとの供給までは、図７のケースと同様である。
【０１１８】
画像ファイル２００をアップロードすると、ユーザが利用可能なＳＰサーバ１５０内のデータサイズを超えてしまうので、ＳＰサーバ１５０は、画像ファイル２００をアップロードすることができない。従って、ＳＰサーバ１５０は、アップロードの失敗を示す保存結果５０６を、ＵＬサーバ１００に供給する。
【０１１９】
保存結果５０６は、ＭＦＰ１０を経由して、ＵＬサーバ１００からＡＰＩサーバ５０に供給される。この結果、解析結果５０８が、ＡＰＩサーバ５０からＭＦＰ１０に供給される。ＭＦＰ１０は、解析結果５０８を取得すると（図３のＳ１８）、解析結果５０８に基づいて、画像ファイルのアップロードを継続不可能であると判断する（Ｓ２０でＮＯ）。この場合、ＭＦＰ１０は、ＳＰサーバ１５０への画像ファイルのアップロードを中止する（即ち図３の処理を終了する）。
【０１２０】
（ＳＰサーバ１６０への画像ファイルのアップロード）
続いて、ＳＰサーバ１５０とは異なるＳＰサーバ１６０への画像ファイルのアップロードについて、簡単に説明しておく。なお、本実施例では、ＳＰサーバ１６０は、ＳＰサーバ１５０とは異なり、フォルダ及びＦＧという階層関係を利用するものではなく、フォルダ及びファイルという一般的な階層関係を利用するものである。
【０１２１】
ＭＦＰ１０のユーザは、「スキャンＵＬ」を選択し、さらに、ＳＰサーバ１６０に対応するサービス名（例えば「Facebook（登録商標）」）を選択する。この場合、ＭＦＰ１０の制御部３０は、図３とは異なるフローチャートに従って、各処理を実行する。これら各処理は、例えば、制御部３０は、図３のＳ６と同様に、スキャン実行部２０にスキャン指示を供給して、Ｎ個の画像ファイルを生成する。次いで、制御部３０は、図３のＳ８及びＳ１０と同様に、ＡＰＩサーバ５０からＵＬサーバ１００のＵＲＬを取得する。ＳＰサーバ１６０は、ユーザによってＳＰサーバ１６０に予め登録されたアカウント情報に対応する複数個のフォルダを保存している。制御部３０は、これらの複数個のフォルダのフォルダ名の一覧の送信を要求するための第１のコマンドを、ＡＰＩサーバ５０に送信する。
【０１２２】
ＡＰＩサーバ５０の制御部７０は、ＭＦＰ１０から第１のコマンドを受信すると、ＳＰサーバ１６０に対応するＡＰＩ（即ち、ＳＰサーバ１５０に対応するＡＰＩとは異なるＡＰＩ）に従って、ＳＰサーバ１６０からフォルダ名の一覧を取得する。そして、制御部７０は、フォルダ名の一覧をＭＦＰ１０に供給する。
【０１２３】
ＭＦＰ１０の制御部３０は、ＡＰＩサーバ５０からフォルダ名の一覧を取得すると、フォルダ名の一覧を表示部１４に表示させる。ユーザは、操作部１２を操作して、フォルダ名の一覧の中から、画像ファイルが保存されるべきフォルダのフォルダ名を選択する。この場合、制御部３０は、選択済みのフォルダ名を含む第２のコマンドを、ＡＰＩサーバ５０に送信する。
【０１２４】
ＡＰＩサーバ５０の制御部７０は、ＭＦＰ１０から第２のコマンドを受信すると、ＳＰサーバ１６０に対応するＡＰＩに従って、第２のコマンドに含まれる選択済みのフォルダ名をＳＰサーバ１６０に供給して、選択済みのフォルダ名を有するフォルダに画像ファイルをアップロードするためのＵＲＬ（即ちＳＰサーバ１６０内の位置を示すＵＲＬ（以下では「対象ＵＲＬ」と呼ぶ）をＳＰサーバ１６０から取得する。そして、制御部７０は、対象ＵＲＬをＭＦＰ１０に供給する。
【０１２５】
ＭＦＰ１０の制御部３０は、ＡＰＩサーバ５０から対象ＵＲＬを取得すると、画像ファイルをアップロードするための第３のコマンドをＵＬサーバ１００に送信する。第３のコマンドは、取得済みのＵＬサーバ１００のＵＲＬを、要求先ＵＲＬとして含む。また、第３のコマンドは、生成済みの画像ファイルと、対象ＵＲＬと、を含む。
【０１２６】
ＵＬサーバ１００の制御部１２０は、ＭＦＰ１０から第３のコマンドを受信すると、第３のコマンドに含まれる画像ファイル及び対象ＵＲＬをＳＰサーバ１６０に供給して、当該画像ファイルをアップロードする。
【０１２７】
上述したように、本実施例では、ＡＰＩサーバ５０は、各ＳＰサーバ１５０，１６０に対応する各ＡＰＩを備えているので、ＭＦＰ１０からのコマンドに応じて、各ＡＰＩに従って各ＳＰサーバ１５０，１６０と様々な通信を実行することができる。この結果、ＭＦＰ１０は、各ＳＰサーバ１５０，１６０に画像ファイルを適切にアップロードすることができる。
【０１２８】
（比較例；図９）
図９を参照にして、ＳＰサーバ１５０への画像ファイルのアップロードを実行するための比較例について説明する。ＳＰサーバ１５０からＡＰＩサーバ５０へのフォルダＩＤ３１４の供給までの各処理は、図６と同様である。
【０１２９】
ＭＦＰ１０は、ＡＰＩサーバ５０からフォルダＩＤ３１４を取得すると、Ｎ個の画像ファイルを生成する。次いで、ＭＦＰ１０は、フォルダＩＤ３１４と、画像ファイル２００と、ＡＴと、を含むＵＬ要求コマンド６００を、ＵＬサーバ１００に送信する。
【０１３０】
ＵＬサーバ１００は、ＵＬ要求コマンド６００を受信すると、ＤＦ６０２を生成する。図１０に示されるように、ＤＦ６０２は、画像ファイル２００を特定するためのテキストデータを含む。次いで、ＵＬサーバ１００は、フォルダＩＤ３１４を有する対象フォルダ内に新規のＦＧを生成するために、フォルダＩＤ３１４と画像ファイル２００とＤＦ６０２とＡＴとをＳＰサーバ１５０に供給する。
【０１３１】
ＳＰサーバ１５０は、画像ファイル２００と、ＤＦ６０２と、フォルダＩＤ３１４と、ＡＴとを取得すると、当該ＡＴが、どのアカウント情報に対応するのかを特定する。そして、ＳＰサーバ１５０は、特定済みのアカウント情報に対応する複数個のフォルダの中から、フォルダＩＤ３１４を有する対象フォルダを特定する。次いで、ＳＰサーバ１５０は、特定済みの対象フォルダ内に画像ファイル２００及びＤＦ６０２を含むＦＧ６０４を生成する。保存結果及び解析結果の通信については、図７と同様であるために、説明を省略する。
【０１３２】
ＭＦＰ１０は、さらに、フォルダＩＤ３１４と、画像ファイル２５０と、ＡＴと、を含むＵＬ要求コマンド６１０を、ＵＬサーバ１００に送信する。
【０１３３】
ＵＬサーバ１００は、ＵＬ要求コマンド６１０を受信すると、ＤＦ６１２を生成する。図１０に示されるように、ＤＦ６１２は、ＤＦ６０２とは異なるＤＦであり、画像ファイル２５０を特定するためのテキストデータを含む。次いで、ＵＬサーバ１００は、フォルダＩＤ３１４を有する対象フォルダ内に新規のＦＧを生成するために、フォルダＩＤ３１４と画像ファイル２５０とＤＦ６１２とＡＴとをＳＰサーバ１５０に供給する。
【０１３４】
ＳＰサーバ１５０は、画像ファイル２５０と、ＤＦ６１２と、フォルダＩＤ３１４と、ＡＴとを取得すると、当該ＡＴとフォルダＩＤ３１４とに基づいて、対象フォルダを特定する。次いで、ＳＰサーバ１５０は、特定済みの対象フォルダ内に画像ファイル２５０及びＤＦ６１２を含むＦＧ６１４を生成する。図１０に示されるように、ＦＧ６１４は、ＦＧ６０４とは異なるＦＧである。このように、比較例によると、ＵＬサーバ１００は、ＵＬ要求コマンド６００，６１０を受信する毎に、１個の画像ファイルを含む１個のＦＧをＳＰサーバ１５０の対象フォルダ内に生成する。従って、ＭＦＰ１０によってＮ個の画像ファイルが生成される場合には、Ｎ個のＦＧが対象フォルダ内に生成される。この結果、ユーザは、例えばＰＣ等を利用して、ＳＰサーバ１５０にアクセスし、次いで、対象フォルダ内の複数個のＦＧのＦＧ名の一覧から１個のＦＧ名を選択する場合に、１個の画像ファイルによって表される１個の画像しか見ることができない。即ち、ユーザは、例えば、Ｎ個の画像ファイルによって表されるＮ個の画像を見ることを望む場合に、ＦＧ名の一覧の中からＮ個のＦＧ名のそれぞれを選択しなければならない。比較例によると、このような煩わしい操作をユーザに強いることになる。
【０１３５】
（実施例の効果）
これに対し、本実施例によると、図７に示されるように、ＵＬサーバ１００は、現行ＤＦ３１６ｂ及び画像ファイル２００を含む現行ＦＧ３１８ｂがＳＰサーバ１５０に保存されている状態で、画像ファイル２５０のアップロードを指示するＵＬ要求コマンド４１０を、ＭＦＰ１０から受信する。ＵＬ要求コマンド４１０は、現行ＦＧ３１８ｂのＦＧＩＤ３２０を含む。従って、ＵＬサーバ１００は、ＦＧＩＤ３２０を利用することができ、この結果、現行ＦＧ３１８ｂに画像ファイル２５０が新たに含まれるように、画像ファイル２５０をＳＰサーバ１５０にアップロードすることができる。即ち、ＵＬサーバ１００は、ＳＰサーバ１５０から現行ＤＦ３１６ｂを取得し、画像ファイル２５０を特定するためのテキストデータを現行ＤＦ３１６ｂに追加して、変更後ＤＦ３１６ｃを生成することができる。そして、ＵＬサーバ１００は、変更後ＤＦ３１６ｃ及び画像ファイル２５０をＳＰサーバ１５０に供給することによって、現行ＦＧ３１８ｂに代えて、変更後ＤＦ３１６ｃ及び画像ファイル２００，２５０を含む変更後ＦＧ３１８ｃをＳＰサーバ１５０内に保存することができる。即ち、ＵＬサーバ１００は、複数個の画像ファイル２００，２５０を同一のＦＧ（即ち変更後ＦＧ３１８ｃ）に適切にアップロードすることができる。
【０１３６】
従って、ユーザから与えられる１回の「スキャンＵＬ」の指示に応じて、ＭＦＰ１０によってＮ個の画像ファイルが生成される場合には、Ｎ個の画像ファイルを含む１個の対象ＦＧのみが対象フォルダ内に生成される。この結果、ユーザは、例えば、Ｎ個の画像ファイルによって表されるＮ個の画像を見ることを望む場合に、対象フォルダ内の複数個のＦＧのＦＧ名の一覧の中から、対象ＦＧのＦＧ名を選択すれば、Ｎ個の画像の全てを見ることができる。即ち、ユーザは、Ｎ個の画像を容易に見ることができる。本実施例によると、比較例と比べて、ユーザの利便性が向上する。
【０１３７】
（対応関係）
ＭＦＰ１０、ＳＰサーバ１５０が、それぞれ、「通信装置」、「データ保存サーバ」の一例である。ＡＰＩサーバ５０及びＵＬサーバ１００の組合せが、「仲介サーバ」の一例である。ＵＬサーバ１００、ＡＰＩサーバ５０が、それぞれ、「第１のサーバ」、「第２のサーバ」の一例である。ＵＬサーバ１００のためのアプリケーションプログラム、ＡＰＩサーバ５０のためのアプリケーションプログラムが、それぞれ、「第１のアプリケーション」、「第２のアプリケーション」の一例である。
【０１３８】
ＤＦ３１６ａ、ＤＦ３１６ｂ、ＤＦ３１６ｃが、それぞれ、「初期の文書ファイル」、「現行の文書ファイル」、「変更後の文書ファイル」の一例である。ＦＧ３１８ａ、ＦＧ３１８ｂ、ＦＧ３１８ｃが、それぞれ、「初期の対象ファイルグループ」、「現行の対象ファイルグループ」、「変更後の対象ファイルグループ」の一例である。ＦＧＩＤ３２０が、「グループ識別情報」の一例である。仮ＦＧ名、正式ＦＧ名が、それぞれ、「第１の名称」、「第２の名称」の一例である。
【０１３９】
Ｎ個の画像ファイルが、「複数個の画像ファイル」の一例である。画像ファイル２００、画像ファイル２００を特定するためのテキストデータが、それぞれ、「１個以上の画像ファイル」、「１個以上のテキストデータ」の一例である。画像ファイル２５０、画像ファイル２５０を特定するためのテキストデータが、それぞれ、「第１の画像ファイル」、「第１のテキストデータ」の一例である。
【０１４０】
ＨＴＴＰプログラム、ＳＰサーバ１５０に対応するＡＰＩが、それぞれ、「第１のプログラム」、「第２のプログラム」の一例である。ＦＧ生成コマンド３００、ＵＬ要求コマンド４１０が、それぞれ、「生成コマンド」、「アップロードコマンド」の一例である。保存結果４１６、完了通知４２０が、それぞれ、「結果情報」、「完了情報」の一例である。ＵＬサーバ１００のＵＲＬ３３２が、「第１のサーバの位置情報」の一例である。
【０１４１】
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例が含まれる。
【０１４２】
（変形例１）上記の実施例では、図７に示されるように、ＵＬサーバ１００のアップロード部１３２は、（１）ＦＧＩＤ３２０を含むＤＦ要求コマンド４１２をＳＰサーバ１５０に送信して、ＳＰサーバ１５０から現行ＤＦ３１６ｂを取得し、（２）画像ファイル２５０を特定するためのテキストデータを現行ＤＦ３１６ｂに追加して、変更後ＤＦ３１６ｃを生成し、（３）変更後ＤＦ３１６ｃ及び画像ファイル２５０をＳＰサーバ１５０に供給する。これに代えて、アップロード部１３２は、現行ＤＦ３１６ｂの取得、及び、変更後ＤＦ３１６ｃの生成を実行せずに、ＦＧＩＤ３２０及び画像ファイル２５０をＳＰサーバ１５０に供給してもよい。この場合、ＳＰサーバ１５０は、ＦＧＩＤ３２０に基づいて現行ＤＦ３１６ｂを特定し、画像ファイル２５０を特定するためのテキストデータを現行ＤＦ３１６ｂに追加して、変更後ＤＦ３１６ｃを生成することができる。本変形例でも、複数個の画像ファイル２００，２５０を同一のＦＧにアップロードすることができる。一般的に言うと、「アップロード部」は、ファイル取得部、追加部、及び、ファイル供給部を備えていなくてもよい。
【０１４３】
（変形例２）上記の実施例では、図８のケースＡに示されるように、ＡＰＩサーバ５０の名称変更部８５は、正式ＦＧ名を生成して、正式ＦＧ名をＳＰサーバ１５０に供給することによって、対象ＦＧのＦＧ名を仮ＦＧ名から正式ＦＧ名に変更する。これに代えて、名称変更部８５は、正式ＦＧ名の生成及び供給を実行せずに、対象ＦＧのＦＧ名を変更するための名称変更コマンドをＳＰサーバ１５０に送信してもよい。この場合、ＳＰサーバ１５０は、例えば現在の日時を示す正式ＦＧ名を生成して、対象ＦＧのＦＧ名を仮ＦＧ名から正式ＦＧ名に変更してもよい。即ち、名称変更部８５は、上記の実施例のように、正式ＦＧ名を含む名称変更コマンド４２４をＳＰサーバ１５０に送信してもよいし、本変形例のように、正式ＦＧ名を含まない名称変更コマンドをＳＰサーバ１５０に送信してもよい。一般的に言うと、「名称変更部」は、名称の変更のための指示をデータ保存サーバに供給すればよい。
【０１４４】
（変形例３）上記の実施例では、仮ＦＧ名は、「Uploading」である。これに代えて、仮ＦＧ名は、アップロード中であることをユーザに認識させるための別の名称であってもよい。例えば、仮ＦＧ名は、ユーザがアップロードを妨げる操作を実行しないように、「Don’t open」という名称であってもよい。即ち、「第１の名称」は、アップロード中であることを示す名称であれば、どのような名称であってもよい。
【０１４５】
（変形例４）上記の実施例では、正式ＦＧ名は、画像ファイルのアップロードの実行時の日時を示す。これに代えて、正式ＦＧ名は、例えば、「１」、「２」、「３」・・・のような通し番号を示す名称であってもよいし、ＭＦＰ１０のノード名を含む名称であってもよい。即ち、「第２の名称」は、アップロード中であることを示さない名称であれば、どのような名称であってもよい。
【０１４６】
（変形例５）「データ保存サーバ」は、「Evernote（登録商標）」でなくてもよく、文書ファイル及び画像ファイルを含むファイルグループを保存することが可能なサーバであれば、他の種類のサーバであってもよい。「文書ファイル」は、ＸＭＬ形式のファイルでなくてもよく、画像ファイルを特定するためのテキストデータを記述可能な他の形式のファイルであってもよい。また、「テキストデータ」は、画像ファイルのハッシュ化によって得られるハッシュ値を含んでいなくてもよく、画像ファイルを特定するための他のデータ（例えば画像ファイルのファイル名）であってもよい。
【０１４７】
（変形例６）「第１のプログラム」は、ＨＴＴＰプログラムでなくてもよく、他の通信プロトコル（例えばＨＴＴＰＳ）に従った通信を実行するためのプログラムであってもよい。「第２のプログラム」は、「Evernote（登録商標）」に対応するＡＰＩでなくてもよく、他の種類のサーバに対応するＡＰＩであってもよい。
【０１４８】
（変形例７）上記の実施例では、ＡＰＩサーバ５０及びＵＬサーバ１００は、別体に構成されているが、一体に構成されていてもよい。即ち、「仲介サーバ」は、別体に構成されている第１及び第２のサーバを備えていてもよいし、一体に構成されている第１及び第２のサーバを備えていてもよい。
【０１４９】
（変形例８）上記の実施例では、ＭＦＰ１０のＣＰＵ３２がソフトウェアに従って処理を実行することによって、各部４１，４２の機能が実現される。また、ＡＰＩサーバ５０及びＵＬサーバ１００のＣＰＵ７２，１２２がソフトウェアに従って処理を実行することによって、各部８１〜８６，１３１〜１３３，１４１〜１４３の機能が実現される。これに代えて、上記の各部４１，４２，８１〜８６，１３１〜１３３，１４１〜１４３のうちの少なくとも一部は、論理回路等のハードウェアによって実現されてもよい。
【０１５０】
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【０１５１】
２：通信システム、１０：ＭＦＰ、１２：操作部、１４：ディスプレイ、２０：スキャン実行部、２２：ネットワークＩ／Ｆ、３０：制御部、３２：ＣＰＵ、３４：メモリ、４１：識別情報取得部、４２：アップロードコマンド送信部、５０：ＡＰＩサーバ、６０：ネットワークＩ／Ｆ、７０：制御部、７２：ＣＰＵ、７４：メモリ、８１：生成コマンド受信部、８２：生成部、８３：保存制御部、８４：識別情報供給部、８５：名称変更部、８６：位置情報供給部、１００：ＵＬサーバ、１１０：ネットワークＩ／Ｆ、１２０：制御部、１２２：ＣＰＵ、１２４：メモリ、１３１：アップロードコマンド受信部、１３２：アップロード部、１３３：結果情報供給部、１４１：ファイル取得部、１４２：追加部、１４３：ファイル供給部、１５０，１６０：ＳＰサーバ、２００，２５０：画像ファイル、３１６ａ，３１６ｂ，３１６ｃ：ＤＦ（文書ファイル）、３１８ａ，３１８ｂ，３１８ｃ：ＦＧ（ファイルグループ）、３２０：ＦＧＩＤ、４００，４１０：ＵＬ要求コマンド
【図１】
2014130410.tif 000003
【図２】
2014130410.tif 000004
【図３】
2014130410.tif 000005
【図４】
2014130410.tif 000006
【図５】
2014130410.tif 000007
【図６】
2014130410.tif 000008
【図７】
2014130410.tif 000009
【図８】
2014130410.tif 000010
【図９】
2014130410.tif 000011
【図１０】
2014130410.tif 000012