JP2014197820A - スキャナ及び通信システム - Google Patents

Abstract

【課題】 スキャナによって生成されるスキャンデータをサーバに保存するための新規な技術を開示すること。【解決手段】 スキャナ１０は、１回のＮＦＣ通信を利用して、仲介サーバ５０にログインするためのアカウント情報ＡＣ１と、保存サーバ１００にログインするためのアカウント情報ＡＣ２と、の双方を携帯端末１５０から受信する。スキャナ１０は、アカウント情報ＡＣ１を利用して仲介サーバ５０にログインした後に、仲介サーバ５０からスキャン指示を受信する場合に、スキャンデータを仲介サーバ５０に送信する。スキャナ１０は、アカウント情報ＡＣ１，ＡＣ２が関連付けられる状態で、アカウント情報ＡＣ２を仲介サーバ５０に送信する。仲介サーバ５０は、アカウント情報ＡＣ２を利用して保存サーバ１００にログインして、スキャンデータを保存サーバ１００に送信する。【選択図】 図２

Description

本明細書では、スキャナによって生成されるスキャンデータをサーバに保存するための技術を開示する。

スキャナによって生成されるスキャンデータをサーバに保存（即ちアップロード）するための技術が知られている。

特開２００８−２３６７０２ 特開２００３−３２４２５ 特開２０１１−１９２１１６

本明細書では、スキャナによって生成されるスキャンデータをサーバに保存するための新規な技術を開示する。

本明細書によって開示されるスキャナは、スキャン実行部と、アカウント情報受信部と、ログイン部と、指示受信部と、スキャン制御部と、スキャンデータ送信部と、アカウント情報送信部と、を備える。アカウント情報受信部は、第１のサーバにログインするための第１のアカウント情報と、第２のサーバにログインするための第２のアカウント情報と、の双方を、ユーザによって実行される１回の操作に応じた１回の無線通信を利用して、携帯端末から受信する。第１のサーバは、スキャナから第２のサーバへのスキャンデータの送信を仲介する。第２のサーバは、スキャンデータを保存する。ログイン部は、第１のアカウント情報を利用して第１のサーバにログインする。指示受信部は、第１のサーバへのログインの後に、第１のサーバからスキャン指示を受信する。スキャン制御部は、第１のサーバからスキャン指示が受信される場合に、原稿のスキャンをスキャン実行部に実行させて、特定のスキャンデータを生成する。スキャンデータ送信部は、特定のスキャンデータを第１のサーバに送信する。アカウント情報送信部は、第１のアカウント情報と第２のアカウント情報とが第１のサーバで関連付けられる状態で、第２のアカウント情報を第１のサーバに送信する。この結果、第１のサーバは、第２のアカウント情報を利用して第２のサーバにログインして、特定のスキャンデータを第２のサーバに送信する。

上記の構成によると、スキャナは、ユーザによって実行される１回の操作に応じた１回の無線通信を利用して、携帯端末から第１及び第２のアカウント情報の双方を受信することができる。このために、スキャナは、以下の動作を実行することができる。即ち、スキャナは、第１のアカウント情報を利用して第１のサーバにログインし、その後、第１のサーバからスキャン指示を受信する。この場合、スキャナは、特定のスキャンデータを生成して、特定のスキャンデータを第１のサーバに送信する。また、スキャナは、第１及び第２のアカウント情報が第１のサーバで関連付けられる状態で、第２のアカウント情報を第１のサーバに送信する。これにより、第１のサーバは、スキャナのログインのために利用された第１のアカウント情報と、第２のサーバにログインするための第２のアカウント情報と、を関連付けることができ、この結果、第２のアカウント情報を利用して第２のサーバにログインして、特定のスキャンデータを第２のサーバに送信することができる。この技術によると、ユーザは、１回の操作に応じた１回の無線通信を携帯端末に実行させるだけで、スキャナに特定のスキャンデータを生成させることができると共に、第１のサーバを介して第２のサーバに当該特定のスキャンデータを保存させることができる。

本明細書では、スキャナと、第１のサーバと、を備える通信システムも開示する。第１のサーバは、スキャナから第１のアカウント情報を含むログイン要求を受信して、スキャナの第１のサーバへのログインを許容するログイン制御部と、スキャナの第１のサーバへのログインの後に、スキャン指示をスキャナに送信する指示送信部と、スキャナから特定のスキャンデータを受信するスキャンデータ受信部と、第１のアカウント情報と第２のアカウント情報とが関連付けられる状態で、スキャナから第２のアカウント情報を受信する第２のアカウント情報受信部と、第２のアカウント情報を利用して第２のサーバにログインして、特定のスキャンデータを第２のサーバに送信する第２のスキャンデータ送信部と、を備える。この技術によると、ユーザは、１回の操作に応じた１回の無線通信を携帯端末に実行させるだけで、スキャナに特定のスキャンデータを生成させることができると共に、第１のサーバを介して第２のサーバに当該特定のスキャンデータを保存させることができる。

上記のいずれかの機器（即ち、スキャナ、又は、第１のサーバ）を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを記憶するコンピュータ読取可能記憶媒体も、新規で有用である。

通信システムの構成を示す。 各デバイスによって実行される各処理のシーケンス図を示す。 スキャンデータ送信処理のフローチャートを示す。 アップロード準備処理のフローチャートを示す。 アップロード処理のフローチャートを示す。 アップロードが成功するケースのシーケンス図を示す。 原稿の詰まりが発生するケースのシーケンス図を示す。 携帯端末で表示される各画面を示す。

（実施例）
（システムの構成）
図１に示されるように、通信システム２は、スキャナ１０と、仲介サーバ５０と、保存サーバ１００と、携帯端末１５０と、を備える。各デバイス１０，５０，１００，１５０は、インターネットを介して、相互に通信可能である。また、スキャナ１０及び携帯端末１５０は、後述のＮＦＣ（Near Field Communicationの略）方式に従った無線通信を利用して、相互に通信可能である。

スキャナ１０は、原稿のスキャンを実行して、スキャナ１０の内部にスキャンデータを記憶したり、スキャナ１０と同じＬＡＮ（Local Area Networkの略）に接続されているＰＣ（Personal Computerの略）にスキャンデータを送信したりすることができる。特に、本実施例では、スキャナ１０は、携帯端末１５０とＮＦＣ方式に従った無線通信を実行することによって、原稿のスキャンを実行して、仲介サーバ５０を介して保存サーバ１００にスキャンデータをアップロードすることができる。このアップロードを実現するために、各デバイス１０等は、以下の構成を備える。

（スキャナ１０の構成）
スキャナ１０は、図示省略のＰＣ等の周辺機器である。スキャナ１０は、操作部１２と、表示部１４と、ＮＦＣインターフェース１６と、スキャン実行部２０と、ネットワークインターフェース２２と、制御部３０と、を備える。以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。

操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示をスキャナ１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。スキャン実行部２０は、ＣＣＤ方式、ＣＩＳ方式等のスキャン機構を備える。

ＮＦＣＩ／Ｆ１６は、ＮＦＣ方式の無線通信（以下では「ＮＦＣ通信」と呼ぶ）を実行するためのＩ／Ｆである。ＮＦＣ方式は、いわゆる近距離無線通信のための無線通信方式であり、例えば、ＩＳＯ／ＩＥＣ２１４８１又は１８０９２の国際標準規格に基づく無線通信方式である。ネットワークＩ／Ｆ２２は、スキャナ１０が設置されている環境に構築される図示省略のＬＡＮに接続するためのＩ／Ｆであり、有線通信のためのＩ／Ｆであってもよいし、無線通信のためのＩ／Ｆであってもよい。スキャナ１０は、ネットワークＩ／Ｆ２２及び図示省略のＬＡＮを介して、インターネットに接続される。

制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に記憶されているプログラムに従って、様々な処理を実行する。

（仲介サーバ５０の構成）
仲介サーバ５０は、スキャナ１０のベンダによってインターネット上に設置されるサーバである。仲介サーバ５０は、スキャナ１０からスキャンデータを受信して、当該スキャンデータを保存サーバ１００に送信する。即ち、仲介サーバ５０は、スキャナ１０から保存サーバ１００へのスキャンデータの送信を仲介する。仲介サーバ５０は、ネットワークＩ／Ｆ６０と、制御部７０と、を備える。

ネットワークＩ／Ｆ６０は、インターネットに接続するためのＩ／Ｆである。制御部７０は、ＣＰＵ７２と、メモリ７４と、を備える。ＣＰＵ７２は、メモリ７４に格納されているプログラムに従って、様々な処理を実行する。

（保存サーバ１００の構成）
保存サーバ１００は、スキャナ１０のベンダとは異なる特定のサービス提供会社によってインターネット上に設置されるサーバである。保存サーバ１００は、画像データ、文書データ等の様々なデータ（即ちファイル）を保存することができる。保存サーバ１００は、例えば、「ＦＴＯＰＩＡ」、「Ｅｖｅｒｎｏｔｅ（登録商標）」、「Ｇｏｏｇｌｅ（登録商標） Ｄｏｃｓ」、「ＰＩＣＡＳＡ（登録商標）」、「ＦＡＣＥＢＯＯＫ（登録商標）」等の公知のサーバであってもよい。

図示省略しているが、インターネット上には、上記の特定のサービス提供会社によって設置される保存サーバ１００のみならず、他の様々なサービス提供会社によって提供される様々な保存サーバが存在する。即ち、複数個のサービス提供会社によって運営される複数個の保存サーバがインターネット上に存在する。

スキャナ１０のベンダは、仲介サーバ５０と通信を実行するためのＡＰＩ（Application Program Interface）を公開している。そして、複数個のサービス提供会社のそれぞれは、上記のＡＰＩを含むプログラムに従って各保存サーバ１００等を動作させる。これにより、保存サーバ１００等は、仲介サーバ５０と様々な通信（例えば後述の図６のスキャンデータ３００の通信等）を実行することができる。

（携帯端末１５０の構成）
携帯端末１５０は、例えば、携帯電話（例えばスマートフォン）、ＰＤＡ（Personal Digital Assistanceの略）、ノートＰＣ、タブレットＰＣ、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末装置である。携帯端末１５０は、ＮＦＣＩ／Ｆ１５６と、ＣＰＵ１６２と、メモリ１６４と、を備える。また、携帯端末１５０は、図示省略の様々なハードウェア（例えば、操作部、表示部等）を備える。

ＮＦＣＩ／Ｆ１５６は、ＮＦＣ通信を実行するためのＩ／Ｆである。ＣＰＵ１６２は、メモリ１６４に格納されているプログラムに従って、様々な処理を実行する。メモリ１６４は、さらに、スキャナ１０から保存サーバ１００等へのスキャンデータのアップロードに関連する様々な処理をスキャナ１０に実行させるためのアプリケーション（以下では「スキャナ用アプリケーション」と呼ぶ）を記憶している。例えば、携帯端末１５０は、スキャナ１０のベンダによってインターネット上に設置されるサーバ（即ち仲介サーバ５０は異なるサーバ）から、スキャナ用アプリケーションをダウンロードする。ＣＰＵ１６２によって実行される以下の各処理は、スキャナ用アプリケーションに従って実行される。

（事前準備；図２）
図２を参照しながら、各デバイス１０，５０，１００，１５０が実行する各処理の内容を説明する。まず、携帯端末１５０のユーザは、以下の事前準備を実行する。携帯端末１５０では、ユーザによってスキャナ用アプリケーションが起動される。次いで、仲介サーバ５０にアクセスするための操作が実行される。スキャナ用アプリケーションには、仲介サーバ５０のＵＲＬ（Uniform Resource Locatorの略）が予め記述されている。携帯端末１５０のＣＰＵ１６２は、仲介サーバ５０のＵＲＬを利用して仲介サーバ５０にアクセスして、仲介サーバ５０からアカウント登録画面を表わす画面情報を受信する。これにより、ＣＰＵ１６２は、アカウント登録画面を表示部（図示省略）に表示させる。ユーザは、アカウント登録画面を見ながら、携帯端末１５０を操作して、ユーザＩＤ、パスワード等の各種情報を携帯端末１５０に入力する。ＣＰＵ１６２は、ユーザによって上記の各種情報が入力されると、上記の各種情報を含むアカウント要求２００を仲介サーバ５０に送信する。

仲介サーバ５０のＣＰＵ７２は、携帯端末１５０からアカウント要求２００を受信すると、アカウント要求２００に含まれる上記の各種情報を含むアカウント情報ＡＣ１を、メモリ７４に登録する（即ちメモリ７４に記憶させる）。そして、ＣＰＵ７２は、登録済みのアカウント情報ＡＣ１を携帯端末１５０に送信する。

携帯端末１５０のＣＰＵ１６２は、仲介サーバ５０からアカウント情報ＡＣ１を受信すると、アカウント情報ＡＣ１を記憶する。これにより、仲介サーバ５０にログインするためのアカウント情報ＡＣ１が、携帯端末１５０に記憶される。

また、スキャナ用アプリケーションには、複数個の保存サーバのそれぞれのサーバ名及びＵＲＬが予め記述されている。本実施例では、ユーザは、複数個の保存サーバの中から保存サーバ１００を選択して、保存サーバ１００にアクセスするための操作を実行する。この場合、携帯端末１５０のＣＰＵ１６２は、仲介サーバ５０の場合と同様に、保存サーバ１００のＵＲＬを利用して、保存サーバ１００からアカウント登録画面を表わす画面情報を受信する。ユーザは、ユーザＩＤ、パスワード等の各種情報を携帯端末１５０に入力する。この場合、携帯端末１５０のＣＰＵ１６２は、ユーザによって入力された上記の各種情報を含むアカウント要求２０４を保存サーバ１００に送信する。

保存サーバ１００は、携帯端末１５０からアカウント要求２０４を受信すると、アカウント要求２０４に含まれる上記の各種情報を含むアカウント情報ＡＣ２を登録する。そして、保存サーバ１００は、登録済みのアカウント情報ＡＣ２を携帯端末１５０に送信する。

携帯端末１５０のＣＰＵ１６２は、保存サーバ１００からアカウント情報ＡＣ２を受信すると、アカウント情報ＡＣ２を記憶する。これにより、保存サーバ１００にログインするためのアカウント情報ＡＣ２が、携帯端末１５０に記憶される。

なお、携帯端末１５０は、ユーザの指示に従って、保存サーバ１００とは異なる保存サーバにログインするためのアカウント情報も記憶することができる。即ち、携帯端末１５０には、１個以上の保存サーバにログインするための１個以上のアカウント情報が記憶される。

（スキャンデータのアップロードのための処理）
ユーザは、上記の事前準備を実行して、２個のアカウント情報ＡＣ１，ＡＣ２を携帯端末１５０に記憶させた後に、保存サーバ１００へのスキャンデータのアップロードを仲介サーバ５０に実行させることができる。ユーザは、スキャンデータのアップロードの実行を望む場合に、携帯端末１５０に記憶されているスキャナ用アプリケーションを起動させる。これにより、待機画面ＳＣ１（図８参照）が携帯端末１５０に表示される。

図８に示されるように、待機画面ＳＣ１は、サーバ名を選択するための領域を含む。本実施例では、ユーザは、携帯端末１５０にアカウント情報が記憶されている１個以上の保存サーバのサーバ名の中から、スキャンデータを保存するための１個の保存サーバのサーバ名（本実施例では保存サーバ１００のサーバ名「ｘｘｘ」）を選択する。

待機画面ＳＣ１は、さらに、スキャン条件（即ち、スキャン対象の原稿のサイズ、スキャンタイプ、ファイルタイプ）を選択するための領域を含む。ユーザは、Ａ３、Ａ４、Ｂ４等の複数個の原稿のサイズの中から、１個のサイズを選択する。また、ユーザは、カラースキャン、モノクロスキャン等の複数個のスキャンタイプの中から、１個のスキャンタイプを選択する。また、ユーザは、ＰＤＦ、ＪＰＥＧ等の複数個のファイル形式の中から、１個のファイル形式（即ち、スキャンデータのファイル形式）を選択する。

次いで、ユーザは、スキャナ１０と携帯端末１５０との間でＮＦＣ接続を確立させるために、携帯端末１５０をスキャナ１０に近づける。この結果、スキャナ１０のＮＦＣＩ／Ｆ１６と携帯端末１５０のＮＦＣＩ／Ｆ１５６との間の距離が、各Ｉ／Ｆ１６，１５６が通信可能な最大の距離（即ちＮＦＣ通信を実行可能な距離；例えば１０ｃｍ）よりも大きい状態から、当該最大の距離以下である状態に移行する。この場合、図２に示されるように、スキャナ１０のＮＦＣＩ／Ｆ１６と携帯端末１５０のＮＦＣＩ／Ｆ１５６との間にＮＦＣ接続が確立される。

携帯端末１５０のＣＰＵ１６２は、上記のＮＦＣ接続を利用して（即ちＮＦＣＩ／Ｆ１５６を介して）、ＮＦＣ情報２０８をスキャナ１０に送信する。ＮＦＣ情報２０８は、仲介サーバ５０にログインするためのアカウント情報ＡＣ１と、ユーザによって選択された保存サーバ１００にログインするためのアカウント情報ＡＣ２と、ユーザによって選択されたスキャン条件を示す条件情報と、ユーザによって選択されたサーバ名と、を含む。

スキャナ１０のＣＰＵ３２は、上記のＮＦＣ接続を利用して（即ちＮＦＣＩ／Ｆ１６を介して）、携帯端末１５０からＮＦＣ情報２０８を受信する。この場合、ＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、ＮＦＣ情報２０８内のアカウント情報ＡＣ１を含むログイン要求２１０を、仲介サーバ５０のＵＲＬを利用して仲介サーバ５０に送信する。なお、仲介サーバ５０のＵＲＬは、スキャナ１０のメモリ３４に予め記憶されていてもよいし、携帯端末１５０から受信されるＮＦＣ情報２０８内に記述されていてもよい。

仲介サーバ５０のＣＰＵ７２は、ネットワークＩ／Ｆ６０を介して、スキャナ１０からログイン要求２１０を受信する。なお、仲介サーバ５０において実行される通信では、ネットワークＩ／Ｆ６０が常に利用されるので、以下の説明では、「ネットワークＩ／Ｆ６０を介して」という用語を省略する。ＣＰＵ７２は、ログイン要求２１０に含まれるアカウント情報ＡＣ１がメモリ７４に登録されているのか否かを判断する。ＣＰＵ７２は、アカウント情報ＡＣ１がメモリ７４に登録されていないと判断する場合には、図示省略しているが、ログイン失敗通知をスキャナ１０に送信する。

一方において、ＣＰＵ７２は、アカウント情報ＡＣ１がメモリ７４に登録されていると判断する場合には、ユニークな文字列であるトークン（即ち認証情報）２１４を生成する。そして、ＣＰＵ７２は、アカウント情報ＡＣ１に関連付けて、トークン２１４をメモリ７４に記憶させる。次いで、ＣＰＵ７２は、トークン２１４を含むログイン成功通知２１２をスキャナ１０に送信する。

スキャナ１０のＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、仲介サーバ５０からログイン成功通知２１２を受信する。この場合、ＣＰＵ３２は、ログイン成功通知２１２に含まれるトークン２１４をメモリ３４に記憶させる。次いで、ＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、トークン２１４を含む接続要求を仲介サーバ５０に送信する。上記の接続要求は、スキャナ１０と仲介サーバ５０との間にＸＭＰＰ（Extensible Messaging and Presence Protocolの略）接続を確立するための要求である。

仲介サーバ５０のＣＰＵ７２は、スキャナ１０から接続要求を受信すると、接続要求に含まれるトークン２１４がメモリ７４に記憶されているのか否かを判断する。ＣＰＵ７２は、トークン２１４がメモリ７４に記憶されていると判断する場合には、所定の応答をスキャナ１０に送信する。これにより、スキャナ１０と仲介サーバ５０との間にＸＭＰＰ接続が確立される。この結果、仲介サーバ５０は、ＸＭＰＰ接続を利用することができるので、図示省略のルータ等によって通信が妨げられることなく、後述のスキャン指示２２０をスキャナ１０に適切に送信することができる（即ち、インターネット側からＬＡＮ側への通信を実行することができる）。

仲介サーバ５０のＣＰＵ７２は、ＸＭＰＰ接続が確立される場合に、ＸＭＰＰ接続を識別するための接続ＩＤを生成し、アカウント情報ＡＣ１に関連付けて、接続ＩＤをメモリ７４に記憶させる。この結果、メモリ７４では、トークン２１４、接続ＩＤ、及び、アカウント情報ＡＣ１が関連付けられている状態になる。

次いで、スキャナ１０のＣＰＵ３２は、トークン２１４を利用して、スキャンデータのアップロードに関連する処理を識別するための処理ＩＤ２１６を生成する。本実施例では、処理ＩＤ（例えばYYY20130315）は、トークン２１４によって示される文字列（例えばYYY）と、現在の日時を示す情報（例えば20130315）と、を組み合わせることによって生成される。詳しくは後述するが、処理ＩＤ２１６は、携帯端末１５０のユーザがスキャンデータのアップロードに関連する処理のステータスを確認するために、携帯端末１５０及び保存サーバ１００で利用される。

スキャナ１０のＣＰＵ３２は、上記のＮＦＣ接続を利用して（即ちＮＦＣＩ／Ｆ１６を介して）、処理ＩＤ２１６を含むスキャン受付通知２１８を携帯端末１５０に送信する。

携帯端末１５０のＣＰＵ１６２は、上記のＮＦＣ接続を利用して（即ちＮＦＣＩ／Ｆ１５６を介して）、スキャナ１０からスキャン受付通知２１８を受信する。この場合、受付画面ＳＣ２（図８参照）が携帯端末１５０で表示される。受付画面ＳＣ２は、スキャンの要求を受け付けたことを示すメッセージと、スキャン受付通知２１８に含まれる処理ＩＤ２１６と、を含む。

ユーザは、受付画面ＳＣ２を見れば、携帯端末１５０をスキャナ１０から離反させてもよいことを知ることができる。携帯端末１５０がスキャナ１０から離反すると、スキャナ１０のＮＦＣＩ／Ｆ１６と携帯端末１５０のＮＦＣＩ／Ｆ１５６との間の距離が、各Ｉ／Ｆ１６，１５６が通信可能な最大の距離以下である状態から、当該距離よりも大きい状態に戻る。この場合、上記のＮＦＣ接続が切断される。以下では、上記のＮＦＣ接続が確立されてから、上記のＮＦＣ接続が切断されるまでに、スキャナ１０と携帯端末１５０との間で実行されるＮＦＣ通信（即ち、ＮＦＣ情報２０８の通信、及び、スキャン受付通知２１８の通信）のことを、「１回のＮＦＣ通信」と呼ぶ。

上述したように、本実施例では、ユーザが携帯端末１５０をスキャナ１０に近づけるための１回の操作を実行すれば、１回のＮＦＣ通信を利用して、携帯端末１５０からスキャナ１０へのＮＦＣ情報２０８の送信と、スキャナ１０から携帯端末１５０へのスキャン受付通知２１８の送信と、が実行される。即ち、１回のＮＦＣ通信を利用して、アカウント情報ＡＣ１、アカウント情報ＡＣ２、及び、処理ＩＤ２１６の３個の情報の全ての通信が実行される。上記の３個の情報の通信のために、ユーザが携帯端末１５０をスキャナ１０に近づけるための操作を複数回に亘って実行しなければならない構成と比べると、ユーザの利便性が向上する。

上述したように、スキャナ１０は、携帯端末１５０から、保存サーバ１００にログインするためのアカウント情報ＡＣ２、及び、保存サーバ１００のサーバ名を受信済みである（ＮＦＣ情報２０８参照）。スキャナ１０のＣＰＵ３２は、上記のＸＭＰＰ接続を利用して（即ちネットワークＩ／Ｆ２２を介して）、処理ＩＤ２１６、アカウント情報ＡＣ２、及び、サーバ名が関連付けられた状態で、これらの情報を仲介サーバ５０に送信する。即ち、ＣＰＵ３２は、これらの情報を同時的に仲介サーバ５０に送信する。

仲介サーバ５０のＣＰＵ７２は、上記のＸＭＰＰ接続を利用して、スキャナ１０からアカウント情報ＡＣ２、処理ＩＤ２１６、及び、保存サーバ１００のサーバ名を同時的に受信する。

上述したように、処理ＩＤ２１６は、トークン２１４を用いて生成される。また、仲介サーバ５０のメモリ７４では、アカウント情報ＡＣ１及びトークン２１４が関連付けられている。従って、ＣＰＵ７２は、アカウント情報ＡＣ２と、処理ＩＤ２１６に含まれるトークン２１４と、を同時的に受信する場合に、メモリ７４を参照して、トークン２１４に関連付けられているアカウント情報ＡＣ１を特定することができる。即ち、ＣＰＵ７２は、トークン２１４を介して、アカウント情報ＡＣ１及びアカウント情報ＡＣ２を関連付けることができる。そして、ＣＰＵ７２は、アカウント情報ＡＣ２及び処理ＩＤ２１６をメモリ７４に記憶させる。この結果、メモリ７４では、トークン２１４、接続ＩＤ、アカウント情報ＡＣ１、アカウント情報ＡＣ２、及び、処理ＩＤ２１６が関連付けられている状態になる。

なお、変形例では、仲介サーバ５０のＣＰＵ７２は、以下のようにして、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けてもよい。上述したように、ＣＰＵ７２は、ＸＭＰＰ接続を利用して、スキャナ１０からアカウント情報ＡＣ２及び処理ＩＤ２１６を受信する。そして、メモリ７４では、ＸＭＰＰ接続を識別するための接続ＩＤ及びアカウント情報ＡＣ１が関連付けられている。従って、ＣＰＵ７２は、ＸＭＰＰ接続を利用してアカウント情報ＡＣ２及び処理ＩＤ２１６を受信する場合に、メモリ７４を参照して、当該ＸＭＰＰ接続の接続ＩＤに関連付けられているアカウント情報ＡＣ１を特定することができ、この結果、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けることができる。即ち、ＣＰＵ７２は、ＸＭＰＰ接続の接続ＩＤを介して、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けることができる。なお、ＸＭＰＰ接続は、トークン２１４を利用して確立される接続である。従って、本変形例でも、トークン２１４を介して、２個のアカウント情報ＡＣ１，ＡＣ２が関連付けられていると言える。

次いで、仲介サーバ５０のＣＰＵ７２は、処理ＩＤ２１６に関連付けて、ステータス情報をメモリ７４に記憶させる。この結果、メモリ７４では、トークン２１４、接続ＩＤ、アカウント情報ＡＣ１、アカウント情報ＡＣ２、処理ＩＤ２１６、及び、ステータス情報が関連付けられている状態になる。現時点では、ステータス情報は、「スキャン準備」を示す。詳しくは後述するが、仲介サーバ５０は、ステータス情報を携帯端末１５０に供給することができる（後述の図６のステータス要求３０８、ステータス通知３１０等参照）。即ち、ユーザは、携帯端末１５０を利用して、ステータス情報にアクセスすれば、スキャンデータのアップロードに関連する処理の現在のステータスを知ることができる。

次いで、ＣＰＵ７２は、上記のＸＭＰＰ接続を利用して、スキャン指示２２０をスキャナ１０に送信する。ＣＰＵ７２は、ＸＭＰＰ接続を利用するので、ＬＡＮ側に存在するスキャナ１０にスキャン指示２２０を適切に送信することができる。ＣＰＵ７２は、スキャン指示２２０をスキャナ１０に送信すると、アップロード準備処理（図４参照）を開始する。

なお、変形例では、ＣＰＵ７２は、ＸＭＰＰ接続を利用せずに、スキャン指示２２０をスキャナ１０に送信してもよい。例えば、ＣＰＵ７２は、スキャナ１０から処理ＩＤ２１６及びアカウント情報ＡＣ２を受信すると、それらの情報の戻り値として、スキャン指示２２０をスキャナ１０に送信してもよい。本変形例の構成でも、ＣＰＵ７２は、ルータ等によって通信が妨げられることなく、ＬＡＮ側に存在するスキャナ１０にスキャン指示２２０を適切に送信することができる。

スキャナ１０のＣＰＵ３２は、上記のＸＭＰＰ接続を利用して（即ちネットワークＩ／Ｆ２２を介して）、仲介サーバ５０からスキャン指示２２０を受信する。この場合、Ｓ２において、ＣＰＵ３２は、スキャンデータ送信処理（図３参照）を開始する。

（スキャンデータ送信処理；図３）
図３を参照して、スキャナ１０のＣＰＵ３２によって実行されるスキャンデータ送信処理（図２のＳ２）の内容を説明する。

上述したように、スキャナ１０のＣＰＵ３２は、携帯端末１５０からスキャン条件を示す条件情報を既に受信している（図２のＮＦＣ情報２０８参照）。Ｓ１０では、ＣＰＵ３２は、受信済みの条件情報によって示される原稿のサイズ（例えばＡ４）及びスキャンタイプ（例えばカラー）に従った原稿のスキャンが実行されるように、スキャン実行部２０に命令を送信する。これにより、スキャン実行部２０は、原稿のスキャンを実行して、画像データを生成する。

Ｓ１２では、ＣＰＵ３２は、スキャン対象の原稿の全てのページに対するスキャンが終了したのか否かを判断する。ＣＰＵ３２は、スキャン実行部２０から全てのページのスキャンが終了したことを示す信号を受信する場合には、Ｓ１２でＹＥＳと判断して、スキャン実行部２０から取得される画像データを利用して、受信済みの条件情報によって示されるファイル形式（例えばＰＤＦ）を有するファイルを生成する。以下では、ここで生成されるファイルのことを「スキャンデータ」と呼ぶ。そして、ＣＰＵ３２は、Ｓ１４に進む。一方において、ＣＰＵ３２は、スキャン実行部２０から上記の信号を受信しない場合には、Ｓ１２でＮＯと判断して、Ｓ３０に進む。

Ｓ１４では、ＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、トークン２１４及びスキャンデータを仲介サーバ５０に同時的に送信する。これにより、ＣＰＵ３２は、トークン２１４及びスキャンデータが関連付けられた状態で、トークン２１４及びスキャンデータを仲介サーバ５０に送信することができる。

なお、Ｓ１４では、ＣＰＵ３２は、スキャナ１０及び仲介サーバ５０の間に確立されているＸＭＰＰ接続を利用せずに、トークン２１４及びスキャンデータを仲介サーバ５０に送信する。詳しくは後述するが、仲介サーバ５０は、スキャンデータと共にトークン２１４を受信するので、トークン２１４に関連付けられているアカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０から、スキャンデータを受信したことを知ることができる（後述の図４のＳ５０でＹＥＳ）。

ただし、変形例では、Ｓ１４において、ＣＰＵ３２は、ＸＭＰＰ接続を利用して、スキャンデータを仲介サーバ５０に送信してもよい。この場合、ＣＰＵ３２は、トークン２１４を仲介サーバ５０に送信しなくてもよい。仲介サーバ５０は、ＸＭＰＰ接続の接続ＩＤに関連付けられているアカウント情報ＡＣ１を特定することができ、この結果、アカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０から、スキャンデータを受信したことを知ることができる。

次いで、Ｓ１８では、ＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、ＸＭＰＰ接続を切断するための信号を仲介サーバ５０に送信する。これにより、スキャナ１０と仲介サーバ５０との間のＸＭＰＰ接続が切断される。この結果、スキャナ１０がアカウント情報ＡＣ１に従って仲介サーバ５０にログインしている状態が終了する。

続いて、Ｓ２０では、ＣＰＵ３２は、トークン２１４をメモリ３４から消去する。Ｓ２０が終了すると、スキャンデータ送信処理が終了する。

一方において、Ｓ３０では、ＣＰＵ３２は、図示省略の自動原稿搬送装置（以下では「ＡＤＦ（Automatic Document Feederの略）」と呼ぶ）によってスキャン対象の原稿が搬送される場合に、ＡＤＦ内で原稿の詰まりが発生したのか否かを判断する。ＣＰＵ３２は、ＡＤＦから原稿の詰まりの発生を示す信号を受信する場合には、Ｓ３０でＹＥＳと判断して、Ｓ３２に進む。一方において、ＣＰＵ３２は、ＡＤＦから上記の信号を受信しない場合には、Ｓ３０でＮＯと判断して、Ｓ１２に戻る。

Ｓ３２では、ＣＰＵ３２は、ネットワークＩ／Ｆ２２を介して、トークン２１４及び原稿の詰まりを示すエラー通知を、仲介サーバ５０に送信する。これにより、仲介サーバ５０は、エラー通知と共にトークン２１４を受信するので、トークン２１４に関連付けられているアカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０において、原稿の詰まりが発生したことを知ることができる（後述の図４のＳ７０でＹＥＳ）。

次いで、Ｓ３４では、ＣＰＵ３２は、原稿の詰まりが解消されない状態で、上記のエラー通知を仲介サーバ５０に送信してから一定時間が経過したのか否かを判断する。ＣＰＵ３２は、上記の一定時間が経過した場合には、Ｓ３４でＹＥＳと判断して、Ｓ１８に進む。この場合、スキャナ１０及び仲介サーバ５０の間のＸＭＰＰ接続が切断され（Ｓ１８）、トークン２１４がメモリ３４から消去される（Ｓ２０）。そして、スキャナ１０から仲介サーバ５０へのスキャンデータの送信が実行されず、この結果、保存サーバ１００へのスキャンデータのアップロードが実行されない。一方において、ＣＰＵ３２は、上記の一定時間が経過しない場合には、Ｓ３４でＮＯと判断して、Ｓ３６に進む。

Ｓ３６では、ＣＰＵ３２は、原稿の詰まりが解消されたのか否かを判断する。ユーザによって原稿の詰まりを解消するための処置が実行された場合には、ＣＰＵ３２は、ＡＤＦから原稿の詰まりが解消したことを示す信号を受信する。この場合、ＣＰＵ３２は、Ｓ３６でＹＥＳと判断して、Ｓ１２に戻る。これにより、ＣＰＵ３２は、スキャンデータを仲介サーバ５０に送信することができる（Ｓ１２でＹＥＳ、Ｓ１４）。一方において、ＣＰＵ３２は、ＡＤＦから上記の信号を受信しない場合には、Ｓ３６でＮＯと判断して、Ｓ３４に戻る。

（アップロード準備処理；図４）
図４を参照して、仲介サーバ５０のＣＰＵ７２によって実行されるアップロード準備処理（図２のＳ４）の内容を説明する。アップロード準備処理が開始される段階では、仲介サーバ５０のメモリ７４では、ログイン状態であるアカウント情報ＡＣ１等に関連付けて、「スキャン準備」を示すステータス情報が記憶されている。

Ｓ５０では、仲介サーバ５０のＣＰＵ７２は、トークン２１４に関連付けられているアカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０から、スキャンデータを受信したのか否かを判断する。ＣＰＵ７２は、トークン２１４及びスキャンデータを同時的に受信する場合（図３のＳ１４参照）には、スキャナ１０からスキャンデータを受信したと判断して（Ｓ５０でＹＥＳ）、Ｓ５２に進む。なお、ＣＰＵ７２は、スキャナ１０からスキャンデータを受信する場合には、アカウント情報ＡＣ１、アカウント情報ＡＣ２等に関連付けて、スキャンデータをメモリ７４に記憶させる。一方において、ＣＰＵ７２は、スキャナ１０からスキャンデータを受信しない場合には、Ｓ５０でＮＯと判断して、Ｓ７０に進む。

Ｓ５２では、ＣＰＵ７２は、アカウント情報ＡＣ１に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「スキャン準備」から、「アップロード準備」に変更する。なお、仮に、この状態で、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、現在のステータスがアップロードの準備中であることを知ることができる。

次いで、Ｓ５８では、ＣＰＵ７２は、スキャナ１０から、ＸＭＰＰ接続を切断するための信号（図３のＳ１８参照）を受信する。これにより、スキャナ１０と仲介サーバ５０との間のＸＭＰＰ接続が切断される。

次いで、Ｓ６０では、ＣＰＵ７２は、トークン２１４及び接続ＩＤをメモリ７４から消去する。この結果、メモリ７４では、アカウント情報ＡＣ１、アカウント情報ＡＣ２、サーバ名、処理ＩＤ２１６、ステータス情報（即ち「アップロード準備」）、及び、スキャンデータが関連付けられている状態になる。ＣＰＵ７２は、Ｓ６０を終了すると、後述のアップロード処理（図５参照）を開始して（Ｓ６２）、アップロード準備処理を終了する。

一方において、Ｓ７０では、ＣＰＵ７２は、トークン２１４に関連付けられているアカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０から、エラー通知を受信したのか否かを判断する。ＣＰＵ７２は、トークン２１４及びエラー通知を同時的に受信する場合（図３のＳ３２参照）には、スキャナ１０からエラー通知を受信したと判断して（Ｓ７０でＹＥＳ）、Ｓ７２に進む。一方において、ＣＰＵ７２は、スキャナ１０からエラー通知を受信しない場合には、Ｓ７０でＮＯと判断して、Ｓ５０に戻る。

Ｓ７２では、ＣＰＵ７２は、アカウント情報ＡＣ１に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「スキャン準備」から、「原稿の詰まり」に変更する。なお、仮に、この状態で、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、スキャナ１０において原稿の詰まりが発生していることを知ることができ、原稿の詰まりを解消するための処置を実行することができる。

次いで、Ｓ７４では、ＣＰＵ７２は、スキャナ１０からスキャンデータを受信したのか否かを判断する。Ｓ７４の処理は、Ｓ５０の処理と同様である。スキャナ１０において原稿の詰まりが解消された場合（図３のＳ３６でＹＥＳ、Ｓ１２でＹＥＳ、Ｓ１４参照）には、ＣＰＵ７２は、スキャナ１０からスキャンデータを受信して、Ｓ７４でＹＥＳと判断して、Ｓ５２に進む。一方において、ＣＰＵ７２は、スキャナ１０からスキャンデータを受信しない場合には、Ｓ７４でＮＯと判断して、Ｓ７６に進む。

Ｓ７６では、ＣＰＵ７２は、スキャナ１０及び仲介サーバ５０の間のＸＭＰＰ接続が切断されたのか否かを判断する。スキャナ１０において原稿の詰まりが解消されない状態で一定時間が経過する場合（図３のＳ３４でＹＥＳ、Ｓ１８参照）には、ＣＰＵ７２は、スキャナ１０からＸＭＰＰ接続を切断するための信号を受信する。この場合、ＣＰＵ７２は、Ｓ７６でＹＥＳと判断して、Ｓ７８に進む。一方において、ＣＰＵ７２は、スキャナ１０から上記の信号を受信しない場合には、Ｓ７６でＮＯと判断して、Ｓ７４に戻る。

Ｓ７８では、ＣＰＵ７２は、トークン２１４、接続ＩＤ、アカウント情報ＡＣ２、処理ＩＤ２１６、及び、ステータス情報をメモリ７４から消去する。この結果、メモリ７４では、いずれの情報もアカウント情報ＡＣ１に関連付けられていない状態になる。ＣＰＵ７２は、Ｓ７８を終了すると、後述のアップロード処理（図５参照）を開始せずに（即ちＳ６２を実行せずに）、アップロード準備処理を終了する。

（アップロード処理；図５）
図５を参照して、図４のＳ６２で開始されるアップロード処理の内容を説明する。アップロード処理が開始される段階では、仲介サーバ５０のメモリ７４では、アカウント情報ＡＣ２等に関連付けて、「アップロード準備」を示すステータス情報が記憶されている（図４のＳ５２参照）。

Ｓ９０では、ＣＰＵ７２は、スキャナ１０から、処理ＩＤ２１６及びアカウント情報ＡＣ２と共に受信したサーバ名（図２参照）に従って、インターネット上に存在する複数個の保存サーバの中から、保存サーバ１００を選択する。そして、ＣＰＵ７２は、アカウント情報ＡＣ２を含むログイン要求を、選択済みの保存サーバ１００に送信する。なお、メモリ７４は、保存サーバ１００のＵＲＬを予め記憶している。ＣＰＵ７２は、保存サーバ１００のＵＲＬを利用して、ログイン要求を保存サーバ１００に送信する。

保存サーバ１００は、仲介サーバ５０からログイン要求を受信すると、ログイン要求に含まれるアカウント情報ＡＣ２が、保存サーバ１００に登録されているのか否かを判断する。保存サーバ１００は、アカウント情報ＡＣ２が登録されていると判断する場合には、ログイン成功通知を仲介サーバ５０に送信し、アカウント情報ＡＣ２が登録されていないと判断する場合には、ログイン失敗通知を仲介サーバ５０に送信する。例えば、アカウント情報ＡＣ２の有効期限が切れている場合には、アカウント情報ＡＣ２が保存サーバ１００から消去され得るので、アカウント情報ＡＣ２が登録されていないと判断され得る。

Ｓ９２では、ＣＰＵ７２は、保存サーバ１００からログイン成功通知を受信したのか否かを判断する。ＣＰＵ７２は、保存サーバ１００からログイン成功通知を受信する場合には、Ｓ９２でＹＥＳと判断して、Ｓ９４に進む。この場合、仲介サーバ５０がアカウント情報ＡＣ２に従って保存サーバ１００にログインしている状態になる。一方において、ＣＰＵ７２は、保存サーバ１００からログイン失敗通知を受信する場合には、Ｓ９２でＮＯと判断して、Ｓ９６に進む。

Ｓ９６では、ＣＰＵ７２は、アカウント情報ＡＣ２に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「アップロード準備」から、「ログイン失敗」に変更する。なお、仮に、この状態で、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、保存サーバ１００へのログインが失敗した結果として、スキャンデータのアップロードが実行されないことを知ることができる。Ｓ９６が終了すると、アップロード処理を終了する。なお、Ｓ９６が実行されてから所定時間経過後に、アカウント情報ＡＣ２、処理ＩＤ２１６、ステータス情報、及び、スキャンデータが、メモリ７４から消去される。

一方において、Ｓ９４では、ＣＰＵ７２は、アカウント情報ＡＣ２に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「アップロード準備」から、「アップロード中」に変更する。なお、仮に、この状態で、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、現在のステータスが保存サーバ１００へのスキャンデータのアップロード中であることを知ることができる。

次いで、Ｓ９８では、ＣＰＵ７２は、アカウント情報ＡＣ２に関連付けられているメモリ７４内のスキャンデータを、保存サーバ１００に送信する。特に、ＣＰＵ７２は、アカウント情報ＡＣ２に従ったログイン状態を利用して、スキャンデータを保存サーバ１００に送信する。なお、上記の「アカウント情報ＡＣ２に従ったログイン状態を利用して」の態様としては、例えば、以下の第１及び第２の手法のどちらかを採用することができる。

第１の手法では、アカウント情報ＡＣ２に従ったログインが成功する場合に、特定のトークンが保存サーバ１００で生成され、当該特定のトークンが仲介サーバ５０に送信される。そして、保存サーバ１００では、特定のトークン及びアカウント情報ＡＣ２が関連付けられる。この場合、仲介サーバ５０のＣＰＵ７２は、特定のトークン及びスキャンデータを保存サーバ１００に同時的に送信する。これにより、保存サーバ１００は、特定のトークンを介して、アカウント情報ＡＣ２及びスキャンデータを関連付けることができる。

第２の手法では、アカウント情報ＡＣ２に従ったログインが成功する場合に、仲介サーバ５０及び保存サーバ１００の間に接続（例えばＸＭＰＰ接続）が確立される。そして、保存サーバ１００では、上記の接続を識別するための接続ＩＤ及びアカウント情報ＡＣ２が関連付けられる。この場合、仲介サーバ５０のＣＰＵ７２は、上記の接続を利用して、スキャンデータを保存サーバ１００に送信する。これにより、保存サーバ１００は、上記の接続ＩＤを介して、アカウント情報ＡＣ２及びスキャンデータを関連付けることができる。

上述したように、保存サーバ１００は、仲介サーバ５０からスキャンデータを受信すると、アカウント情報ＡＣ２及びスキャンデータを関連付けることができる。このために、保存サーバ１００は、アカウント情報ＡＣ２に対応する場所にスキャンデータを保存することができる。即ち、アカウント情報ＡＣ２に対応する場所にスキャンデータがアップロードされる。このように、スキャンデータのアップロードが成功すると、保存サーバ１００は、アップロード成功通知を仲介サーバ５０に送信する。

一方において、例えば、保存サーバ１００において、アカウント情報ＡＣ２に対応する場所に保存可能な最大のデータサイズが予め決められている状況を想定する。この場合、保存サーバ１００は、アカウント情報ＡＣ２に対応する場所に既に保存されているデータのデータサイズと、仲介サーバ５０から受信されたスキャンデータのデータサイズと、の和が、上記の最大のデータサイズを超える場合には、アカウント情報ＡＣ２に対応する場所に、スキャンデータを新たに保存することができない。この場合には、保存サーバ１００は、アップロード失敗通知を仲介サーバ５０に送信する。

Ｓ１００では、ＣＰＵ７２は、保存サーバ１００からアップロード成功通知を受信したのか否かを判断する。ＣＰＵ７２は、保存サーバ１００からアップロード成功通知を受信する場合には、Ｓ１００でＹＥＳと判断して、Ｓ１０２に進む。一方において、ＣＰＵ７２は、保存サーバ１００からアップロード失敗通知を受信する場合には、Ｓ１００でＮＯと判断して、Ｓ１０４に進む。

Ｓ１０２では、ＣＰＵ７２は、アカウント情報ＡＣ２に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「アップロード中」から、「アップロード成功」に変更する。なお、この状態で、仮に、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、保存サーバ１００へのスキャンデータのアップロードが成功したことを知ることができる。Ｓ１０２が終了すると、アップロード処理が終了する。

一方において、Ｓ１０４では、ＣＰＵ７２は、アカウント情報ＡＣ２に関連付けられているメモリ７４内のステータス情報（即ち、処理ＩＤ２１６に関連付けられているステータス情報）を、「アップロード中」から、「アップロード失敗」に変更する。なお、この状態で、仮に、ユーザが携帯端末１５０を利用して仲介サーバ５０にアクセスすれば、ユーザは、保存サーバ１００へのスキャンデータのアップロードが失敗したことを知ることができる。Ｓ１０４が終了すると、アップロード処理が終了する。

なお、Ｓ１０２又はＳ１０４が実行される場合には、所定時間経過後に、アカウント情報ＡＣ２、処理ＩＤ２１６、ステータス情報、及び、スキャンデータが、メモリ７４から消去される。

（アップロードが成功するケース；図６）
図６を参照して、保存サーバ１００へのスキャンデータのアップロードが成功するケースを説明する。本ケースは、図２の続きのシーケンスであり、図３〜図５の各処理によって実現される。

スキャナ１０は、仲介サーバ５０からスキャン指示２２０（図２参照）を受信する場合に、原稿のスキャンを実行して、スキャンデータ３００を生成する（図３のＳ１０、Ｓ１２でＹＥＳ）。そして、スキャナ１０は、トークン２１４及びスキャンデータ３００を仲介サーバ５０に送信する（Ｓ１４）。

仲介サーバ５０は、スキャナ１０からスキャンデータ３００を受信すると（図４のＳ５０でＹＥＳ）、ステータス情報を「スキャン準備」から「アップロード準備」に変更する（Ｓ５２）。

次いで、スキャナ１０及び仲介サーバ５０の間のＸＭＰＰ接続が切断され、スキャナ１０がアカウント情報ＡＣ１に従って仲介サーバ５０にログインしている状態が終了する（図３のＳ１８、図４のＳ５８）。そして、スキャナ１０においてトークン２１４が消去され（図３のＳ２０）、仲介サーバ５０においてトークン２１４が消去される（図４のＳ６０）。

ユーザは、携帯端末１５０を操作して、ステータスの確認のための指示を携帯端末１５０に入力する。この場合、携帯端末１５０のＣＰＵ１６２は、アカウント情報ＡＣ１を含むログイン要求３０４を仲介サーバ５０に送信して、仲介サーバ５０からログイン成功通知３０６を受信する。即ち、携帯端末１５０がアカウント情報ＡＣ１に従って仲介サーバ５０にログインしている状態になる。

上述したように、携帯端末１５０のＣＰＵ１６２は、スキャナ１０から処理ＩＤ２１６を受信済みである（図２のスキャン受付通知２１８参照）。ＣＰＵ１６２は、仲介サーバ５０にログインすると、処理ＩＤ２１６を含むステータス要求３０８を仲介サーバ５０に送信する。

仲介サーバ５０（即ちＣＰＵ７２）は、携帯端末１５０からステータス要求３０８を受信すると、メモリ７４から、ステータス要求３０８に含まれる処理ＩＤ２１６に関連付けられているステータス情報を取得する。そして、仲介サーバ５０は、取得済みのステータス情報を含むステータス通知３１０を携帯端末１５０に送信する。

携帯端末１５０のＣＰＵ１６２は、仲介サーバ５０からステータス通知３１０を受信する。この結果、携帯端末１５０でステータス画面ＳＣ３が表示される（図８参照）。ステータス画面ＳＣ３は、ステータス通知３１０に含まれるステータス情報によって示される「アップロード準備」というメッセージを含む。これにより、ユーザは、現在のステータスがスキャンデータのアップロードの準備中であることを知ることができる。

次いで、図６に示されるように、仲介サーバ５０は、アカウント情報ＡＣ２を含むログイン要求３１４を保存サーバ１００に送信して（図５のＳ９０）、保存サーバ１００からログイン成功通知３１６を受信する（Ｓ９２でＹＥＳ）。即ち、仲介サーバ５０がアカウント情報ＡＣ２に従って保存サーバ１００にログインしている状態になる。そして、仲介サーバ５０は、ステータス情報を「アップロード準備」から「アップロード中」に変更する（Ｓ９４）。次いで、仲介サーバ５０は、スキャンデータ３００を保存サーバ１００に送信する（Ｓ９８）。

保存サーバ１００は、仲介サーバ５０からスキャンデータを受信すると、アカウント情報ＡＣ２に対応する場所にスキャンデータ３００を保存する。これにより、スキャンデータ３００が保存サーバ１００にアップロードされる。保存サーバ１００は、スキャンデータ３００を保存すると、アップロード成功通知３１８を仲介サーバ５０に送信する。

仲介サーバ５０は、保存サーバ１００からアップロード成功通知３１８を受信すると（Ｓ１００でＹＥＳ）、ステータス情報を「アップロード中」から「アップロード成功」に変更する（Ｓ１０２）。

携帯端末１５０のＣＰＵ１６２は、ステータス要求３０８の場合と同様に、ユーザの指示に従って、処理ＩＤ２１６を含むステータス要求３２０を仲介サーバ５０に送信して、仲介サーバ５０からステータス通知３２２を受信する。この結果、携帯端末１５０でステータス画面ＳＣ４が表示される（図８参照）。ステータス画面ＳＣ４は、ステータス通知３２２に含まれるステータス情報によって示される「アップロード成功」というメッセージを含む。これにより、ユーザは、保存サーバ１００へのスキャンデータのアップロードが成功したことを知ることができる。

（原稿の詰まりが発生するケース；図７）
図７を参照して、原稿の詰まりが発生するケースを説明する。本ケースも、図２の続きのシーケンスであり、図３〜図５の各処理によって実現される。

スキャナ１０では、原稿のスキャンが実行される過程で、原稿の詰まりが発生する。この場合、スキャナ１０は、トークン２１４及びエラー通知４０２を仲介サーバ５０に送信する（図３のＳ３２）。

仲介サーバ５０は、スキャナ１０からエラー通知４０２を受信すると、ステータス情報を「スキャン準備」から「原稿の詰まり」に変更する（Ｓ７２）。

携帯端末１５０及び仲介サーバ５０の間で実行される各情報４０４，４０６，４０８，４１０の通信は、図６の各情報３０４，３０６，３０８，３１０の通信と同様である。ただし、本ケースでは、ステータス通知４１０は、「原稿の詰まり」を示すステータス情報を含む。

携帯端末１５０は、仲介サーバ５０からステータス通知４１０を受信する。この結果、携帯端末１５０でステータス画面ＳＣ５が表示される（図８参照）。ステータス画面ＳＣ５は、ステータス通知４１０に含まれるステータス情報によって示される「原稿の詰まり」を示すメッセージを含む。これにより、ユーザは、スキャナ１０で原稿の詰まりが発生していることを知ることができ、原稿の詰まりを解消するための処置を実行することができる。

スキャナ１０は、原稿の詰まりが解消すると（図３のＳ３６でＹＥＳ）、原稿のスキャンを実行して、トークン２１４及びスキャンデータ３００を仲介サーバ５０に送信する（Ｓ１４）。この後の各処理は、図６のケースと同様である。

（実施例の効果）
本実施例によると、図２に示されるように、スキャナ１０は、ユーザが携帯端末１５０をスキャナ１０に近づけるための１回の操作を実行すれば（即ちいわゆるワンタッチの操作を実行すれば）、１回のＮＦＣ通信を利用して、携帯端末１５０から２個のアカウント情報ＡＣ１，ＡＣ２の双方を受信することができる。従って、２個のアカウント情報ＡＣ１，ＡＣ２の通信のために、ユーザが携帯端末１５０をスキャナ１０に近づけるための操作を２回に亘って実行しなければならない構成と比べて、ユーザの利便性が向上する。

スキャナ１０は、携帯端末１５０からアカウント情報ＡＣ１を受信するので、アカウント情報ＡＣ１を利用して仲介サーバ５０にログインすることができる。その後、スキャナ１０は、仲介サーバ５０からスキャン指示２２０を受信する。この場合、図６に示されるように、スキャナ１０は、スキャンデータ３００を生成し、トークン２１４及びスキャンデータ３００を仲介サーバ５０に送信する。

また、図２に示されるように、スキャナ１０は、携帯端末１５０からアカウント情報ＡＣ２を受信するので、アカウント情報ＡＣ２を仲介サーバ５０に送信することができる。ここで、スキャナ１０は、アカウント情報ＡＣ２及び処理ＩＤ２１６が関連付けられた状態で、アカウント情報ＡＣ２及び処理ＩＤ２１６を仲介サーバ５０に送信する。この結果、仲介サーバ５０は、処理ＩＤ２１６に含まれるトークン２１４を介して、アカウント情報ＡＣ１及びアカウント情報ＡＣ２を関連付けることができる。

図６に示されるように、仲介サーバ５０は、アカウント情報ＡＣ２を利用して、保存サーバ１００にログインすることができる。また、仲介サーバ５０は、アカウント情報ＡＣ１及びアカウント情報ＡＣ２を関連付けることができるので、アカウント情報ＡＣ１に従ったログイン状態を有するスキャナ１０から受信されたスキャンデータ３００を、アカウント情報ＡＣ２に従ったログイン状態を利用して、保存サーバ１００に送信することができる。この結果、保存サーバ１００は、アカウント情報ＡＣ２に対応する場所にスキャンデータ３００を保存（即ちアップロード）することができる。

上述したように、本実施例によると、ユーザは、携帯端末１５０を利用して、スキャナ１０によって生成されるスキャンデータ３００を、仲介サーバ５０を介して、保存サーバ１００に容易に保存（即ちアップロード）させることができる。

また、本実施例では、携帯端末１５０とは異なる携帯端末が利用される場合でも、携帯端末１５０の場合と同様に、スキャンデータを保存サーバ１００にアップロードさせることができる。即ち、仲介サーバ５０は、各ユーザが各携帯端末をスキャナ１０に近づける場合に、各ユーザに対応する各アカウント情報に対応する各場所（即ち異なる場所）に、スキャンデータをアップロードすることができる。本実施例によると、各携帯端末の各ユーザは、同じスキャナ１０を利用して、各ユーザの各アカウント情報に対応する各場所に、スキャンデータをアップロードさせることができる。

特に、本実施例によると、図６に示されるように、スキャナ１０から仲介サーバ５０へのスキャンデータ３００の送信が終了すると、スキャナ１０と仲介サーバ５０との間のＸＭＰＰ接続、即ち、アカウント情報ＡＣ１に従ったＸＭＰＰ接続が、自動的に切断される（図３のＳ１８、図４のＳ５８参照）。仮に、スキャンデータ３００の送信が終了しても、当該ＸＭＰＰ接続が維持される構成を採用すると、他の携帯端末のユーザは、スキャンデータのアップロードを実行することを望む場合に、当該ＸＭＰＰ接続を切断させなければならない。例えば、他の携帯端末のユーザは、スキャナ１０の電源をＯＦＦしたり、スキャナ１０に操作部１２に所定の操作を実行したりして、ＸＭＰＰ接続を切断させなければならない。これに対し、本実施例によると、スキャンデータ３００の送信が終了すると、ＸＭＰＰ接続が自動的に切断されるので、他の携帯端末のユーザは、当該ＸＭＰＰ接続を切断させるための操作を実行せずに済む。このために、ユーザの利便性が向上する。

（対応関係）
仲介サーバ５０、保存サーバ１００が、それぞれ、「第１のサーバ」、「第２のサーバ」の一例である。トークン２１４が、「第１のデータ」の一例である。処理ＩＤ２１６が、「第２のデータ」及び「処理識別情報」の一例である。ＮＦＣＩ／Ｆ１６、ネットワークＩ／Ｆ２２が、それぞれ、「第１のインターフェース」、「第２のインターフェース」の一例である。

スキャナ１０によって実行される各処理は、以下の対応関係を有する。図２において、携帯端末１５０からＮＦＣ情報２０８を受信する処理、ログイン要求２１０を仲介サーバ５０に送信する処理、仲介サーバ５０からログイン成功通知２１２を受信する処理、処理ＩＤ２１６を生成する処理、仲介サーバ５０からスキャン指示２２０を受信する処理、アカウント情報ＡＣ２及び処理ＩＤ２１６を仲介サーバ５０に送信する処理が、それぞれ、「アカウント情報受信部（第１のアカウント情報受信部）」、「ログイン部」、「データ受信部」、「生成部」、「指示受信部」、「アカウント情報送信部」によって実行される処理の一例である。また、スキャン受付通知２１８を携帯端末１５０に送信する処理、及び、処理ＩＤ２１６を仲介サーバ５０に送信する処理が、「識別情報送信部」によって実行される処理の一例である。図３のＳ１０の処理、Ｓ１４の処理が、それぞれ、「スキャン制御部」、「スキャンデータ送信部（第１のスキャンデータ送信部）」によって実行される処理の一例である。

仲介サーバ５０によって実行される各処理は、以下の対応関係を有する。図２において、スキャナ１０からログイン要求２１０を受信してログイン成功通知２１２をスキャナ１０に送信する処理、スキャン指示２２０をスキャナ１０に送信する処理、スキャナ１０からアカウント情報ＡＣ２を受信する処理が、それぞれ、「ログイン制御部」、「指示送信部」、「第２のアカウント情報受信部」によって実行される処理の一例である。図４において、Ｓ５０でスキャナ１０からスキャンデータを受信する処理が、「スキャンデータ受信部」によって実行される処理の一例である。図５において、Ｓ９０及びＳ９８の処理が、「第２のスキャンデータ送信部」によって実行される処理の一例である。また、図６において、ステータス通知３１０を携帯端末１５０に送信する処理が、「状況情報送信部」によって実行される処理の一例である。

以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。上記の実施例の変形例を以下に列挙する。

（変形例１）上記の実施例では、図２に示されるように、スキャナ１０は、ＮＦＣ通信を利用しているが、これに代えて、赤外線通信、Ｔｒａｎｓｆｅｒ Ｊｅｔ等のＮＦＣとは異なる規格に従った近距離無線通信を利用してもよい。本変形例でも、スキャナ１０は、携帯端末１５０をスキャナ１０に近づけるための１回の操作に応じた１回の無線通信を利用して、携帯端末１５０から２個のアカウント情報ＡＣ１，ＡＣ２の双方を受信することができる。本変形例では、赤外線、Ｔｒａｎｓｆｅｒ Ｊｅｔ等の無線通信が、「１回の無線通信」の一例である。

（変形例２）上記の実施例では、図２に示されるように、スキャナ１０は、仲介サーバ５０からスキャン指示２２０を受信する前に、アカウント情報ＡＣ２を仲介サーバ５０に送信する。これに代えて、スキャナ１０は、仲介サーバ５０からスキャン指示２２０を受信した後に、アカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。例えば、スキャナ１０は、原稿のスキャンが終了した後（即ち図３のＳ１２でＹＥＳの後）であって、スキャンデータ３００を仲介サーバ５０に送信する前（即ち図３のＳ１４の前）に、アカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。また、例えば、スキャナ１０は、スキャンデータ３００を仲介サーバ５０に送信した後（即ち図３のＳ１４の後）であって、ＸＭＰＰ接続を切断する前（即ち図３のＳ１８の前）に、アカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。一般的に言うと、アカウント情報送信部は、第１のサーバからスキャン指示が受信される前に、第２のアカウント情報を第１のサーバに送信してもよいし、第１のサーバからスキャン指示が受信された後に、第２のアカウント情報を第１のサーバに送信してもよい。

（変形例３）上記の実施例では、図２に示されるように、スキャナ１０は、処理ＩＤ２１６及びアカウント情報ＡＣ２が関連付けられた状態で、処理ＩＤ２１６及びアカウント情報ＡＣ２を仲介サーバ５０に送信する（即ち、処理ＩＤ２１６及びアカウント情報ＡＣ２を同時的に送信する）。この結果、仲介サーバ５０は、処理ＩＤ２１６に含まれるトークン２１４を介して、アカウント情報ＡＣ１及びアカウント情報ＡＣ２を関連付けることができる。これに代えて、以下の（１）〜（３）のいずれの手法が採用されてもよい。

（１）スキャナ１０は、処理ＩＤ２１６を生成せずに、トークン２１４及びアカウント情報ＡＣ２が関連付けられた状態で、トークン２１４及びアカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。本変形例でも、仲介サーバ５０は、トークン２１４を介して、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けることができる。本変形例では、トークン２１４が「第１のデータ」及び「第２のデータ」の一例であり、「第１のデータ」及び「第２のデータ」が一致する。

（２）仲介サーバ５０は、トークン２１４を生成した後に、さらに、トークン２１４を利用せずにユニークなＩＤを生成し、当該ＩＤ及びアカウント情報ＡＣ１を関連付けて記憶してもよい。そして、仲介サーバ５０は、トークン２１４と上記のＩＤとを含むログイン成功通知２１２をスキャナ１０に送信してもよい。スキャナ１０は、上記のＩＤ及びアカウント情報ＡＣ２が関連付けられた状態で、上記のＩＤ及びアカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。本変形例では、仲介サーバ５０は、上記のＩＤを介して、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けることができる。本変形例では、上記のＩＤが「第１のデータ」及び「第２のデータ」の一例であり、「第１のデータ」及び「第２のデータ」が一致する。

（３）上記の実施例及び上記の変形例（１）、（２）では、スキャナ１０は、アカウント情報ＡＣ２と共に、２個のアカウント情報ＡＣ１，ＡＣ２の関連付けのための何らかのデータ（例えば、処理ＩＤ２１６、トークン２１４、ＩＤ）を、仲介サーバ５０に送信する。これに代えて、スキャナ１０は、アカウント情報ＡＣ２と共にデータを送信しなくてもよく、ＸＭＰＰ接続を利用して、アカウント情報ＡＣ２を仲介サーバ５０に送信してもよい。上記の実施例でも説明したように、仲介サーバ５０では、ＸＭＰＰ接続を識別するための接続ＩＤ及びアカウント情報ＡＣ１が関連付けられている。従って、仲介サーバ５０は、アカウント情報ＡＣ２の受信に利用されたＸＭＰＰ接続の接続ＩＤを介して、２個のアカウント情報ＡＣ１，ＡＣ２を関連付けることができる。本変形例も、「第１のアカウント情報と第２のアカウント情報とが第１のサーバで関連付けられる状態で、第２のアカウント情報を第１のサーバに送信する」という構成の一例である。

（変形例４）上記の実施例では、図６に示されるように、仲介サーバ５０は、スキャナ１０からスキャンデータ３００を受信した後に、アカウント情報ＡＣ２を利用して保存サーバ１００にログインする。これに代えて、仲介サーバ５０は、スキャン指示２２０（図２）をスキャナ１０に送信する前に、アカウント情報ＡＣ２を利用して保存サーバ１００へのログインを試行してもよい。そして、仲介サーバ５０は、ログインが成功する場合に、スキャン指示２２０をスキャナ１０に送信し、ログインが成功しない場合に、スキャン指示２２０をスキャナ１０に送信しなくてもよい。本変形例によると、スキャナ１０は、保存サーバ１００にログインすることができないことに起因して、アップロードすることができない場合に、スキャンデータを生成せずに済む。

（変形例５）「スキャナ」は、スキャン実行部を備えるあらゆるデバイス（例えば、スキャン機能及び印刷機能を含む多機能を実行可能な多機能機、ＦＡＸ装置等）を含む。例えば、送信側のＦＡＸ装置（即ち「スキャナ」の一例）は、仲介サーバ５０を介してＦＡＸデータ（即ち「スキャンデータ」の一例）を保存サーバ１００にアップロードさせることによって、ＦＡＸ送信を実行してもよい。これにより、受信側のＦＡＸ装置は、仲介サーバ５０からＦＡＸデータを受信することによって、ＦＡＸ受信を実行することができる。

（変形例６）上記の各実施例では、スキャナ１０及び仲介サーバ５０のＣＰＵ３２，７２がメモリ３４，７４内のプログラム（即ちソフトウェア）を実行することによって、図２〜図７の各処理が実現される。これに代えて、各処理のうちの少なくとも１つは、論理回路等のハードウェアによって実現されてもよい。

２：通信システム、１０：スキャナ、１２：操作部、１４：表示部、１６：ＮＦＣＩ／Ｆ、２０：スキャン実行部、２２：ネットワークＩ／Ｆ、３０：制御部、３２：ＣＰＵ、３４：メモリ、５０：仲介サーバ、６０：ネットワークＩ／Ｆ、７０：制御部、７２：ＣＰＵ、７４：メモリ、１００：保存サーバ、１５０：携帯端末、１５６：ＮＦＣＩ／Ｆ

Claims (10)

1. スキャナであって、
   スキャン実行部と、
   第１のサーバにログインするための第１のアカウント情報と、第２のサーバにログインするための第２のアカウント情報と、の双方を、ユーザによって実行される１回の操作に応じた１回の無線通信を利用して、前記携帯端末から受信するアカウント情報受信部であって、前記第１のサーバは、前記スキャナから前記第２のサーバへのスキャンデータの送信を仲介し、前記第２のサーバは、前記スキャンデータを保存する、前記アカウント情報受信部と、
   前記第１のアカウント情報を利用して前記第１のサーバにログインするログイン部と、
   前記第１のサーバへの前記ログインの後に、前記第１のサーバからスキャン指示を受信する指示受信部と、
   前記第１のサーバから前記スキャン指示が受信される場合に、原稿のスキャンを前記スキャン実行部に実行させて、特定のスキャンデータを生成するスキャン制御部と、
   前記特定のスキャンデータを前記第１のサーバに送信するスキャンデータ送信部と、
   前記第１のアカウント情報と前記第２のアカウント情報とが前記第１のサーバで関連付けられる状態で、前記第２のアカウント情報を前記第１のサーバに送信するアカウント情報送信部であって、この結果、前記第１のサーバは、前記第２のアカウント情報を利用して前記第２のサーバにログインして、前記特定のスキャンデータを前記第２のサーバに送信する、前記アカウント情報送信部と、
   を備える、スキャナ。
2. 前記アカウント情報送信部は、前記第１のサーバから前記スキャン指示が受信される前に、前記第２のアカウント情報を前記第１のサーバに送信する、請求項１に記載のスキャナ。
3. 前記スキャナは、さらに、
   前記第１のサーバから、前記第１のサーバで前記第１のアカウント情報に関連付けられた第１のデータを受信するデータ受信部を備え、
   前記アカウント情報送信部は、前記第１のデータに基づく第２のデータと、前記第２のアカウント情報と、を関連付けて、前記第１のサーバに送信する、請求項１又は２に記載のスキャナ。
4. 前記スキャナは、さらに、
   前記スキャン指示に基づいて実行されるべき処理を識別するための処理識別情報を生成する生成部と、
   前記処理識別情報を、前記携帯端末と、前記第１のサーバと、に送信する識別情報送信部と、
   を備える、請求項１又は２に記載のスキャナ。
5. 前記識別情報送信部は、前記１回の無線通信を利用して、前記処理識別情報を前記携帯端末に送信する、請求項４に記載のスキャナ。
6. 前記１回の無線通信は、ＮＦＣ（Near Field Communicationの略）規格に従った無線通信である、請求項１から５のいずれか一項に記載のスキャナ。
7. 前記スキャナは、さらに、
   無線通信を実行するための第１のインターフェースを備え、
   前記ユーザによって実行される前記１回の操作は、前記第１のインターフェースと前記携帯端末との間の距離であるデバイス間距離が、特定の距離以下になるように、前記携帯端末を前記スキャナに近づける操作であり、
   前記１回の無線通信は、前記ユーザによって実行される前記１回の操作に起因して、前記デバイス間距離が前記特定の距離より大きい第１の状態から前記特定の距離以下である第２の状態に移行する第１のタイミングと、前記第２の状態から前記第１の状態に戻る第２のタイミングと、の間の期間に実行される無線通信であり、
   前記アカウント情報受信部は、前記第１のインターフェースを介した前記１回の無線通信を利用して、前記携帯端末から前記第１のアカウント情報と第２のアカウント情報との双方を受信する、請求項１から６のいずれか一項に記載のスキャナ。
8. 前記スキャナは、さらに、
   前記第１のインターフェースとは異なる第２のインターフェースを備え、
   前記ログイン部は、前記第２のインターフェースを介して、前記第１のアカウント情報を利用して前記第１のサーバにログインし、
   前記指示受信部は、前記第２のインターフェースを介して、前記第１のサーバから前記スキャン指示を受信し、
   前記スキャンデータ送信部は、前記第２のインターフェースを介して、前記特定のスキャンデータを前記第１のサーバに送信し、
   前記アカウント情報送信部は、前記第２のインターフェースを介して、前記第２のアカウント情報を前記第１のサーバに送信する、請求項７に記載のスキャナ。
9. 通信システムであって、
   スキャナと、
   前記スキャナから第２のサーバへのスキャンデータの送信を仲介する第１のサーバであって、前記第２のサーバは前記スキャンデータを保存する、前記第１のサーバと、を備え、
   前記スキャナは、
   スキャン実行部と、
   前記第１のサーバにログインするための第１のアカウント情報と、前記第２のサーバにログインするための第２のアカウント情報と、の双方を、ユーザによって実行される１回の操作に応じた１回の無線通信を利用して、前記携帯端末から受信する第１のアカウント情報受信部と、
   前記第１のアカウント情報を含むログイン要求を前記第１のサーバに送信して、前記第１のサーバにログインするログイン部と、
   前記第１のサーバへの前記ログインの後に、前記第１のサーバからスキャン指示を受信する指示受信部と、
   前記第１のサーバから前記スキャン指示が受信される場合に、原稿のスキャンを前記スキャン実行部に実行させて、特定のスキャンデータを生成するスキャン制御部と、
   前記特定のスキャンデータを前記第１のサーバに送信する第１のスキャンデータ送信部と、
   前記第１のアカウント情報と前記第２のアカウント情報とが前記第１のサーバで関連付けられる状態で、前記第２のアカウント情報を前記第１のサーバに送信するアカウント情報送信部と、を備え、
   前記第１のサーバは、
   前記スキャナから前記第１のアカウント情報を含む前記ログイン要求を受信して、前記スキャナの前記第１のサーバへの前記ログインを許容するログイン制御部と、
   前記スキャナの前記第１のサーバへの前記ログインの後に、前記スキャン指示を前記スキャナに送信する指示送信部と、
   前記スキャナから前記特定のスキャンデータを受信するスキャンデータ受信部と、
   前記第１のアカウント情報と前記第２のアカウント情報とが関連付けられる状態で、前記スキャナから前記第２のアカウント情報を受信する第２のアカウント情報受信部と、
   前記第２のアカウント情報を利用して前記第２のサーバにログインして、前記特定のスキャンデータを前記第２のサーバに送信する第２のスキャンデータ送信部と、を備える、通信システム。
10. 前記スキャナは、さらに、
    前記スキャン指示に基づいて実行されるべき処理を識別するための処理識別情報を生成する生成部と、
    前記処理識別情報を、前記携帯端末と、前記第１のサーバと、に送信する識別情報送信部と、を備え、
    前記第１のサーバは、さらに、
    前記携帯端末から前記処理識別情報が受信される場合に、前記処理識別情報によって識別される前記処理の状況を示す状況情報を前記携帯端末に送信する状況情報送信部を備える、請求項９に記載の通信システム。

Images