JP5958254B2 - 特定のサーバ及び通信装置 - Google Patents

Description

本明細書では、ウェブ画面を端末装置に表示させるための特定のサーバを開示する。本明細書では、さらに、端末装置と無線通信を実行するための通信装置を開示する。

例えば、特許文献１には、ＰＣと中継装置とＭＦＰとサービス提供装置とを備えるシステムが開示されている。ＰＣは、仮登録ＩＤ発行要求を中継装置に送信する。中継装置は、仮登録ＩＤ発行要求を受信すると、仮登録ＩＤを生成して、仮登録ＩＤをＰＣに送信する。これにより、ＰＣは、仮登録ＩＤを表示させる。ユーザは、ＭＦＰを操作して、ＰＣに表示された仮登録ＩＤをＭＦＰに入力する。この場合、ＭＦＰは、仮登録ＩＤを中継装置に送信する。中継装置は、仮登録ＩＤを受信すると、仮登録ＩＤを用いて、サービス提供装置からアクセストークンを取得する。

特開２０１２−１１３６９６号公報

特許文献１の技術では、ユーザは、ＭＦＰを操作して、仮登録ＩＤをＭＦＰに入力する必要がある。本明細書では、新規な手法を用いて、対象データを通信装置に供給し得る技術を提供する。

本明細書によって開示される特定のサーバは、第１の受信部と、準備部と、第１の送信部と、を備える。第１の受信部は、ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、第１の送信要求を受信する。準備部は、第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する。第１の特定データは、第１の端末装置が、第１種の無線通信とは異なる第２種の無線通信を利用して、第１の端末装置とは異なる通信装置に対象データを送信するための手法を示す第１のウェブ画面を、第１の端末装置に表示させるためのデータである。第１の送信部は、第１の特定データを第１の端末装置に送信する。

上記の構成によると、特定のサーバは、第１の端末装置から第１の送信要求を受信する場合に、対象データを含む第１の特定データを準備して、第１の特定データを第１の端末装置に送信する。これにより、第１の端末装置は、第１のウェブ画面を表示させ得る。このために、第１の端末装置のユーザは、第１のウェブ画面を見て、第１の端末装置が通信装置に対象データを送信するための手法（即ち、第２種の無線通信を利用するための手法）を知り得る。この結果、ユーザが当該手法に従って動作すれば、第１の端末装置は、第２種の無線通信を利用して、通信装置に対象データを送信し得る。このために、新規な手法を用いて、対象データを通信装置に供給し得る。

本明細書によって開示される通信装置は、受信部と、処理実行部と、を備える。受信部は、ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、特定のサーバから、対象データを含む第１の特定データを受信した結果として、第１の端末装置が、第１種の無線通信とは異なる第２種の無線通信を利用して、対象データを通信装置に送信する場合に、第２種の無線通信を利用して、対象データを受信する。第１の特定データは、第１の端末装置が、第２種の無線通信を利用して、通信装置に対象データを送信するための手法を示す第１のウェブ画面を、第１の端末装置に表示させるためのデータである。処理実行部は、対象データを用いて、特定の処理を実行する。

上記の構成によると、第１の端末装置は、第１種の無線通信を利用して、特定のサーバから第１の特定データを受信し得る。これにより、第１の端末装置は、第１のウェブ画面を表示させ得る。このために、第１の端末装置のユーザは、第１のウェブ画面を見て、第１の端末装置が通信装置に対象データを送信するための手法（即ち、第２種の無線通信を利用するための手法）を知り得る。この結果、ユーザが当該手法に従って動作すれば、第１の端末装置は、第２種の無線通信を利用して、通信装置に対象データを送信し得る。このために、通信装置は、新規な手法を用いて、第１の端末装置から対象データを受信して、特定の処理を適切に実行し得る。

上記の特定のサーバを実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記憶媒体も、新規で有用である。また、上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記憶媒体も、新規で有用である。また、上記の特定のサーバと上記の通信装置とを備える通信システムも、新規で有用である。
以下の特徴は、出願当初の特許請求の範囲に記載の要素である。
（特徴１）
特定のサーバであって、
ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信部と、
前記第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する準備部であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記第１の端末装置とは異なる通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータである、前記準備部と、
前記第１の特定データを前記第１の端末装置に送信する第１の送信部と、
を備える特定のサーバ。
（特徴２）
前記第１の特定データは、前記対象データを含む第１の位置情報であって、前記第１のウェブ画面を表わす第１のウェブデータの位置を示す前記第１の位置情報へのアクセスを指示する第１のアクセスコマンドである、特徴１に記載の特定のサーバ。
（特徴３）
前記特定のサーバは、さらに、
前記対象データを生成する生成部を備え、
前記準備部は、前記対象データを含む前記第１の特定データを生成することによって、前記第１の特定データを準備する、特徴１又は２に記載の特定のサーバ。
（特徴４）
前記特定のサーバは、さらに、
前記特定のサーバとは異なるサービス提供サーバから認証情報を取得する取得部であって、前記認証情報は、前記通信装置が前記サービス提供サーバからサービスを受けるための情報である、前記取得部を備え、
前記生成部は、前記サービス提供サーバから前記認証情報が取得される場合に、前記通信装置が前記認証情報を前記特定のサーバから取得するための前記対象データを生成して、前記認証情報と前記対象データとを対応付けてメモリに記憶させる、特徴３に記載の特定のサーバ。
（特徴５）
前記特定のサーバは、さらに、
前記第１の特定データが前記第１の端末装置に送信された後に、前記通信装置から、前記対象データを含む特定の送信要求を受信する第２の受信部と、
前記特定の送信要求が受信される場合に、前記特定の送信要求に含まれる前記対象データに対応付けられている前記認証情報を前記メモリから読み出して、前記認証情報を前記通信装置に送信する第２の送信部と、
を備える、特徴４に記載の特定のサーバ。
（特徴６）
前記第１の送信要求は、前記第１の端末装置が、前記サービス提供サーバから、前記特定のサーバ内の位置を示す第２の位置情報へのアクセスを指示する第２のアクセスコマンドを受信する場合に、前記第２の位置情報を用いて、前記特定のサーバに送信する要求である、特徴４又は５に記載の特定のサーバ。
（特徴７）
前記第２種の無線通信は、前記第１種の無線通信と比べて無線通信可能な距離が短い近距離無線通信であり、
前記第１のウェブ画面は、前記第１の端末装置を前記通信装置に近づけることを示す第１のメッセージを含む、特徴１から６のいずれか一項に記載の特定のサーバ。
（特徴８）
前記第１の送信要求は、さらに、前記第１の端末装置に搭載されているプログラムに関係する関係情報を含み、
前記特定のサーバは、さらに、
前記関係情報に基づいて、前記プログラムが前記第２種の無線通信をサポートするのか否かを判断する判断部を備え、
前記準備部は、
前記プログラムが前記第２種の無線通信をサポートすると判断される第１の場合に、前記第１のメッセージを含む前記第１のウェブ画面を、前記第１の端末装置に表示させるための前記第１の特定データを準備し、
前記プログラムが前記第２種の無線通信をサポートしないと判断される第２の場合に、前記第１のメッセージを含まない第２のウェブ画面であって、前記通信装置を操作して前記対象データを前記通信装置に入力することを示す第２のメッセージを含む前記第２のウェブ画面を、前記第１の端末装置に表示させるための第２の特定データを準備し、
前記第１の送信部は、
前記第１の場合に、前記第１の特定データを前記第１の端末装置に送信し、
前記第２の場合に、前記第２の特定データを前記第１の端末装置に送信する、特徴７に記載の特定のサーバ。
（特徴９）
前記第１の受信部は、
前記第２種の無線通信をサポートする前記第１の端末装置が、前記特定のサーバ内の位置を示す第３の位置情報を用いて、前記第１の送信要求を前記特定のサーバに送信する場合に、前記第１の送信要求を受信し、
前記第２種の無線通信をサポートしない第２の端末装置が、前記特定のサーバ内の位置を示す第４の位置情報であって、前記第３の位置情報とは異なる前記第４の位置情報を用いて、第２の送信要求を前記特定のサーバに送信する場合に、前記第２の送信要求を受信し、
前記準備部は、さらに、前記第２の送信要求が受信される場合に、前記第１のメッセージを含まない第２のウェブ画面であって、前記通信装置を操作して前記対象データを前記通信装置に入力することを示す第２のメッセージを含む前記第２のウェブ画面を、前記第２の端末装置に表示させるための第２の特定データを準備し、
前記第１の送信部は、さらに、前記第２の送信要求が受信される場合に、前記第２の特定データを前記第２の端末装置に送信する、特徴７に記載の特定のサーバ。
（特徴１０）
通信装置であって、
ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、特定のサーバから、対象データを含む第１の特定データを受信した結果として、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記対象データを前記通信装置に送信する場合に、前記第２種の無線通信を利用して、前記対象データを受信する受信部であって、前記第１の特定データは、前記第１の端末装置が、前記第２種の無線通信を利用して、前記通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータである、前記受信部と、
前記対象データを用いて、特定の処理を実行する処理実行部と、
を備える通信装置。
（特徴１１）
前記第１の特定データは、前記対象データを含む第１の位置情報であって、前記第１のウェブ画面を表わす第１のウェブデータの位置を示す前記第１の位置情報へのアクセスを指示する第１のアクセスコマンドであり、
前記受信部は、前記第１の端末装置が、前記第１のアクセスコマンドに従って前記第１の位置情報にアクセスして、前記第１のウェブ画面を表示させた後に、前記第２種の無線通信を利用して、前記第１の位置情報を前記通信装置に送信する場合に、前記第２種の無線通信を利用して、前記第１の位置情報を受信し、
前記通信装置は、さらに、
前記第１の位置情報から前記対象データを抽出する抽出部を備え、
前記処理実行部は、抽出済みの前記対象データを用いて、前記特定の処理を実行する、特徴１０に記載の通信装置。
（特徴１２）
特定のサーバのためのコンピュータプログラムであって、
前記特定のサーバに搭載されるコンピュータに、以下の各処理、即ち、
ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信処理と、
前記第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する準備処理であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記第１の端末装置とは異なる通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータである、前記準備処理と、
前記第１の特定データを前記第１の端末装置に送信する第１の送信処理と、
を実行させるコンピュータプログラム。

通信システムの構成を示す。 携帯端末を利用してＭＦＰにＤＬ印刷処理を実行させるための各処理のシーケンス図を示す。 図２の続きのシーケンス図を示す。 携帯端末又はＰＣで表示される各画面の一例を示す。 ＰＣを利用してＭＦＰにＤＬ印刷処理を実行させるための各処理のシーケンス図を示す。 図５の続きのシーケンス図を示す。 図２の続きの第２実施例のシーケンス図を示す。 図５の続きの第２実施例のシーケンス図を示す。 （Ａ）携帯端末で表示されるメッセージ画面と、（Ｂ）ＰＣで表示されるメッセージ画面と、の一例を示す。

（第１実施例）
（システムの構成）
図１に示されるように、通信システム２は、ＭＦＰ（Multi-Function Peripheralの略）１０と、仲介サーバ５０と、複数個のサービス提供サーバ１００，１１０と、携帯端末１５０と、ＰＣ１６０と、を備える。各デバイス１０，５０，１００，１１０，１５０，１６０は、インターネットに接続可能である。また、ＭＦＰ１０及び携帯端末１５０のそれぞれは、ＮＦＣ（Near Field Communicationの略）通信を実行可能である。

（ＭＦＰ１０の構成）
ＭＦＰ１０は、印刷機能、スキャン機能、コピー機能、ＦＡＸ機能等の多機能を実行可能な周辺装置である。ＭＦＰ１０は、操作部１２と、表示部１４と、ＮＦＣＩ／Ｆ（NFC Interfaceの略）１６と、印刷実行部１８と、スキャン実行部２０と、ネットワークＩ／Ｆ２２と、制御部３０と、を備える。操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示をＭＦＰ１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。印刷実行部１８は、インクジェット方式、レーザ方式等の印刷機構を備える。スキャン実行部２０は、ＣＣＤ、ＣＩＳ等のスキャン機構を備える。

ＮＦＣＩ／Ｆ１６は、ＮＦＣ方式の無線通信を実行するためのインターフェースである。ＮＦＣ方式は、いわゆる近距離無線通信のための無線通信方式であり、例えば、ＩＳＯ／ＩＥＣ２１４８１又は１８０９２の国際標準規格に基づく無線通信方式である。ネットワークＩ／Ｆ２２は、ＬＡＮ（Local Area Networkの略）に接続するためのインターフェースである。ネットワークＩ／Ｆ２２は、有線ＬＡＮに接続されるインターフェースであってもよいし、無線ＬＡＮに接続されるインターフェースであってもよい。ＭＦＰ１０は、ネットワークＩ／Ｆ２２を介して（即ちＬＡＮを介して）、インターネットに接続可能である。

制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に格納されているプログラムに従って、様々な処理を実行する。ＣＰＵ３２が上記のプログラムに従って処理を実行することによって、各部４１〜４３の機能が実現される。

ＭＦＰ１０は、後述の図２及び図３等の各処理を実行することによって、サービス提供サーバ（例えば１００）からサービスを受けることができる。例えば、ＭＦＰ１０は、サービス提供サーバから画像データをダウンロードして、画像データによって表わされる画像を印刷媒体に印刷することができる（以下では「ＤＬ印刷処理」と呼ぶ）。即ち、ＭＦＰ１０は、サービス提供サーバからデータ供給サービスを受けて、ＤＬ印刷処理を実行することができる。また、例えば、ＭＦＰ１０は、スキャンによって生成される画像データをサービス提供サーバにアップロードすることができる（以下では「スキャンＵＬ処理」と呼ぶ）。即ち、ＭＦＰ１０は、サービス提供サーバからデータ保存サービスを受けて、スキャンＵＬ処理を実行することができる。

（仲介サーバ５０の構成）
仲介サーバ５０は、ＭＦＰ１０のベンダによって提供されるサーバであり、サービス提供サーバ１００，１１０からＭＦＰ１０へのサービスの提供を仲介するためのサーバである。また、仲介サーバ５０は、携帯端末１５０及びＰＣ１６０にウェブデータを提供するためのウェブサーバとして機能する。仲介サーバ５０は、ネットワークＩ／Ｆ６０と、制御部７０と、を備える。仲介サーバ５０は、ネットワークＩ／Ｆ６０を介して、インターネットに接続可能である。

制御部７０は、ＣＰＵ７２と、メモリ７４と、を備える。ＣＰＵ７２は、メモリ７４に格納されているプログラムに従って、様々な処理を実行する。ＣＰＵ７２が上記のプログラムに従って処理を実行することによって、各部８１〜８８の機能が実現される。

（サービス提供サーバ１００，１１０の構成）
各サービス提供サーバ１００，１１０は、例えば、「Evernote（登録商標）」、「Google（登録商標） Docs」、「PICASA（登録商標）」、「Facebook（登録商標）」等の公知のサービス提供サーバである。本実施例では、各サービス提供サーバ１００，１１０の名称（即ちサービス名）は、それぞれ、「AAA」、「BBB」である。各サービス提供サーバ１００，１１０は、通信機器（例えばＭＦＰ１０）にデータを供給するためのデータ供給サービスと、通信機器からデータを取得して保存するためのデータ保存サービスと、を提供可能である。

サービス提供サーバ１００は、第１のサービス事業者（即ち第１の会社）によって提供されるサーバであり、サービス提供サーバ１１０は、第１のサービス事業者とは異なる第２のサービス事業者（即ち第２の会社）によって提供されるサーバである。第１のサービス事業者は、サービス提供サーバ１００からサービスを受けるための第１のＡＰＩ（Application Program Interfaceの略）を公開しており、第２のサービス事業者は、サービス提供サーバ１１０からサービスを受けるための第２のＡＰＩを公開している。第１のサービス事業者と第２のサービス事業者とが異なるために、通常、第１のＡＰＩと第２のＡＰＩとは異なる。通信機器は、例えば、サービス提供サーバ１００，１１０の両方からサービスを受けるためには、第１及び第２のＡＰＩの両方に対応している必要がある（即ち、第１のＡＰＩを利用するためのプログラムと、第２のＡＰＩを利用するためのプログラムと、の両方が必要である）。

例えば、ＭＦＰ１０が複数個のサービス提供サーバ１００，１１０のそれぞれからサービスを受けるためには、ＭＦＰ１０は、複数個のＡＰＩに対応している必要があり、多くのプログラムを格納する必要がある。しかしながら、ＰＣ１６０等と比べると、ＭＦＰ１０のメモリ３４の記憶容量は少ない。従って、本実施例では、ＭＦＰ１０に多くのプログラムを格納させることなく、ＭＦＰ１０が複数個のサービス提供サーバ１００，１１０のそれぞれからサービスを受けることができるように、仲介サーバ５０が設けられている。

即ち、仲介サーバ５０は、複数個のサービス提供サーバ１００，１１０のための複数個のＡＰＩに対応している。そして、仲介サーバ５０は、ＭＦＰ１０が各サービス提供サーバ１００，１１０からサービスを受けることができるように、各サービス提供サーバ１００，１１０のための各ＡＰＩを利用して、各サービス提供サーバ１００，１１０と通信（例えば、後述のアクセストークン２３０の取得のための通信）を実行する。これにより、ＭＦＰ１０は、各サービス提供サーバ１００，１１０のための各ＡＰＩに対応していなくても（即ち多くのプログラムを格納していなくても）、各サービス提供サーバ１００，１１０からサービスを受けることができる。また、サービス提供サーバ１００，１１０の仕様変更が行われる場合に、仲介サーバ５０のプログラムを変更すれば、ＭＦＰ１０のプログラムを変更しなくても、当該仕様変更に対応することができる。また、新規のサービス提供サーバのためのＡＰＩに対応するように、仲介サーバ５０のプログラムを変更すれば、ＭＦＰ１０のプログラムを変更しなくても、ＭＦＰ１０は、新規のサービス提供サーバからサービスを受けることができる。

（携帯端末１５０の構成）
携帯端末１５０は、例えば、携帯電話（例えばスマートフォン）、ＰＤＡ、ノートＰＣ、タブレットＰＣ、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末装置である。図示省略しているが、携帯端末１５０は、ＮＦＣ通信を実行するためのインターフェースと、Ｗｉ−Ｆｉアライアンスによって定められる無線通信規格に基づく無線通信を実行するためのインターフェースと、を備える。以下では、後者の無線通信のことを「Ｗｉ−Ｆｉ通信」と呼ぶ。

携帯端末１５０は、ＮＦＣ通信及びＷｉ−Ｆｉ通信をサポートしている公知のＯＳプログラム（例えばAndroid（登録商標）等）を備える。また、携帯端末１５０は、さらに、公知のウェブブラウザプログラムを備える。ただし、携帯端末１５０は、ウェブデータの中から後述のテンポラリＩＤを抽出して、ＮＦＣ通信を利用して当該テンポラリＩＤをＭＦＰ１０に送信するための特別なアプリケーションプログラムを備えていない。携帯端末１５０は、Ｗｉ−Ｆｉ通信を実行して、インターネットに接続可能である。なお、本実施例では、携帯端末１５０及びＭＦＰ１０が同一のＬＡＮに接続されていない状況を想定している。

ここでは、ＮＦＣ通信とＷｉ−Ｆｉ通信との相違点を記載しておく。ＮＦＣ通信は、上述したように、例えば、ＩＳＯ／ＩＥＣ２１４８１又は１８０９２の国際標準規格に基づく無線通信である。これに対し、Ｗｉ−Ｆｉ通信は、例えば、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.の略）の８０２．１１の規格、及び、それに準ずる規格（例えば、８０２．１１ａ，１１ｂ，１１ｇ，１１ｎ等）に基づく無線通信である。ＮＦＣ通信の通信速度（例えば最大の通信速度＝１００〜４２４Ｋｂｐｓ）は、Ｗｉ−Ｆｉ通信の通信速度（例えば最大の通信速度＝１１〜６００Ｍｂｐｓ）よりも遅い。また、ＮＦＣ通信における搬送波の周波数（例えば１３．５６ＭＨｚ帯）は、Ｗｉ−Ｆｉ通信における搬送波の周波数（例えば２．４ＧＨｚ帯又は５．０ＧＨｚ帯）とは異なる。また、ＮＦＣ通信の通信可能距離（例えば１０ｃｍ以下）は、Ｗｉ−Ｆｉ通信の通信可能距離（例えば１００ｍ以下）よりも短い。

（ＰＣ１６０の構成）
ＰＣ１６０は、例えば、デスクトップＰＣ、ノートＰＣ、タブレットＰＣ等の端末装置である。ＰＣ１６０は、携帯端末１５０とは異なり、ＮＦＣ通信を実行不可能である。ＰＣ１６０は、Ｗｉ−Ｆｉ通信をサポートしている公知のＯＳプログラム（例えばWindows（登録商標）等）を備える。また、ＰＣ１６０は、さらに、公知のウェブブラウザプログラムを備える。ＰＣ１６０は、Ｗｉ−Ｆｉ通信を実行して、インターネットに接続可能である。なお、本実施例では、ＰＣ１６０及びＭＦＰ１０が同一のＬＡＮに接続されていない状況を想定している。

（ユーザの事前準備）
ユーザは、ＭＦＰ１０が各サービス提供サーバ１００，１１０からサービスを受けるために、以下の事前準備を実行する必要がある。ユーザは、例えば、携帯端末１５０、ＰＣ１６０等の端末装置を用いて、例えば、サービス提供サーバ１００にアクセスして、公知の手法を利用して、ログインＩＤ及びパスワードをサービス提供サーバ１００に登録する。このような事前準備が完了すると、ユーザは、上記の端末装置を用いて、サービス提供サーバ１００からサービスを受けることができる。例えば、ユーザは、サービス提供サーバ１００からデータ保存サービスを受けて、画像データを含むファイルをサービス提供サーバ１００にアップロードすることができる。その後、ユーザは、アップロード済みのファイルの印刷をＭＦＰ１０に実行させることを望む場合（即ち、ＭＦＰ１０にＤＬ印刷処理を実行させる場合）に、後述の図２及び図３等に示される動作を実行する。

（ＭＦＰ１０にＤＬ印刷処理を実行させるための処理）
ＭＦＰ１０が、サービス提供サーバ１００からデータ供給サービスを受けて、ＤＬ印刷処理を実行するためには、ＭＦＰ１０は、サービス提供サーバ１００によって生成されるアクセストークンを取得する必要がある。アクセストークンをＭＦＰ１０に供給するための手法として、ＮＦＣ通信を実行可能な携帯端末１５０が利用される手法と、ＮＦＣ通信を実行不可能なＰＣ１６０が利用される手法と、が存在する。以下では、図２及び図３を参照して、携帯端末１５０が利用される手法を説明し、次いで、図５及び図６を参照して、ＰＣ１６０が利用される手法を説明する。

（携帯端末１５０が利用されるケースＡ；図２）
携帯端末１５０のユーザは、携帯端末１５０とＭＦＰ１０との間にＮＦＣ接続が確立されるように、携帯端末１５０をＭＦＰ１０に近づける。ＭＦＰ１０が電源ＯＮにされている間に、ＭＦＰ１０のＮＦＣＩ／Ｆ１６は、ＮＦＣ通信を実行可能な機器（例えば携帯端末１５０）を検出するための検出電波を発信している。また、携帯端末１５０のＮＦＣＩ／Ｆ（図示省略）も、ＮＦＣ通信を実行可能な機器（例えばＭＦＰ１０）を検出するための検出電波を発信している。ＭＦＰ１０と携帯端末１５０との間の距離が、上記の検出電波が届く距離（例えば１０ｃｍ）より小さくなると、ＭＦＰ１０及び携帯端末１５０の一方の機器は、他方の機器から検出電波を受信して、応答電波を送信する。この結果、ＭＦＰ１０と携帯端末１５０との間にＮＦＣ接続が確立される。

ＭＦＰ１０のメモリ３４は、仲介サーバ５０のＵＲＬ（Uniform Resource Locatorの略）「http://www.aa.com」を予め記憶している。ＭＦＰ１０の制御部３０は、ＭＦＰ１０と携帯端末１５０との間にＮＦＣ接続が確立される場合に、当該ＮＦＣ接続を利用して（即ちＮＦＣ通信を利用して）、メモリ３４内の仲介サーバ５０のＵＲＬを携帯端末１５０に送信する。

Ｓ１０では、携帯端末１５０のＯＳプログラムは、ＮＦＣ通信の結果として仲介サーバ５０のＵＲＬを受信する場合に、携帯端末１５０のウェブブラウザを起動させる。このような仕組みは、ＯＳプログラムに予め搭載されている仕組みである。従って、携帯端末１５０に特別なアプリケーションプログラムをインストールしなくても、携帯端末１５０のＯＳプログラムは、ウェブブラウザを起動させることができる。

携帯端末１５０のウェブブラウザは、仲介サーバ５０のＵＲＬにアクセスする。なお、以下では、携帯端末１５０のＯＳプログラム、携帯端末１５０のブラウザプログラムを、それぞれ、「携帯端末１５０（ＯＳ）」、「携帯端末１５０（ブラウザ）」と簡単に記載する。携帯端末１５０（ブラウザ）が仲介サーバ５０のＵＲＬにアクセスする手法を、次に説明する。

携帯端末１５０（ブラウザ）は、仲介サーバ５０のＵＲＬ「http://www.aa.com」のうち、仲介サーバ５０のサーバ名「www.aa.com」を用いて、ＤＮＳ（Domain Name Systemの略）サーバから仲介サーバ５０のＩＰアドレスを取得する。そして、携帯端末１５０（ブラウザ）は、取得済みのＩＰアドレスを送信先ＩＰアドレスとして含むＨＴＴＰ（Hyper Text Transfer Protocolの略）のＧＥＴコマンドを生成する。従って、ＧＥＴコマンドは、仲介サーバ５０のＩＰアドレスを含むが、仲介サーバ５０のＵＲＬそのものを含まない。ただし、仲介サーバ５０のＩＰアドレスは、仲介サーバ５０のＵＲＬを名前変換することによって得られるものであるために、仲介サーバ５０のＵＲＬと等価な情報である。このために、ＧＥＴコマンドが仲介サーバ５０のＩＰアドレスを含むということは、ＧＥＴコマンドが仲介サーバ５０のＵＲＬを含むことに等しいと言える。従って、本実施例では、機器（例えば携帯端末１５０）がＵＲＬにアクセスしてＧＥＴコマンドを送信する状況において、実際には、ＧＥＴコマンドがＵＲＬそのものを含むわけではないが、「ＧＥＴコマンドがＵＲＬを含む」と表現する。

また、仮に、携帯端末１５０（ブラウザ）がアクセスすべき対象のＵＲＬが、例えば、「http://www.aa.com/xxx/yyy」である状況を想定する。以下では、このようなＵＲＬにおいて、サーバ名「www.aa.com」より後ろの部分「xxx」及び「yyy」のことを「リソース部」と呼ぶ。携帯端末１５０（ブラウザ）は、サーバ名「www.aa.com」を用いて、ＤＮＳサーバからＩＰアドレスを取得して、取得済みのＩＰアドレスを送信先ＩＰアドレスとして含むＧＥＴコマンドを生成する。ＧＥＴコマンドは、さらに、ＵＲＬ内のリソース部を示す文字列（即ち「xxx」及び「yyy」）を含む。従って、ＧＥＴコマンドは、仲介サーバ５０のＩＰアドレスと、ＵＲＬ内のリソース部以降の文字列と、を含むが、ＵＲＬそのものを含まない。本実施例では、このようなＧＥＴコマンドについても、「ＧＥＴコマンドがＵＲＬを含む」と表現する。なお、実際には、リソース部は、「.cgi」のような拡張子を含むが、本実施例及び図面では、「.cgi」の記載及び図示を省略する。

携帯端末１５０（ブラウザ）は、仲介サーバ５０のＵＲＬを要求先ＵＲＬとして含むＧＥＴコマンド２１０を生成する。ＵＲＬ２１０は、仲介サーバ５０のサーバ名「www.aa.com」を含む（即ち仲介サーバ５０内の位置を示す）。従って、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を実行して、ＧＥＴコマンド２１０を仲介サーバ５０に送信する。これにより、携帯端末１５０（ブラウザ）は、仲介サーバ５０のＵＲＬにアクセスすることができる。

仲介サーバ５０の制御部７０は、ＨＴＴＰ通信を利用して、携帯端末１５０（ブラウザ）からＧＥＴコマンド２１０を受信する。この場合、制御部７０は、サービスリストデータ２１２をメモリ７４から取得する。サービスリストデータ２１２は、図４のサービスリスト画面２１２ａを表わすウェブデータであり、携帯端末１５０（ブラウザ）が解釈可能な形式を有する。次いで、制御部７０は、ＨＴＴＰ通信を利用して、サービスリストデータ２１２を携帯端末１５０（ブラウザ）に送信する。サービスリストデータ２１２は、ウェブページ（即ち図４のサービスリスト画面２１２ａ）のページＵＲＬとして、仲介サーバ５０のＵＲＬ（即ち、ＧＥＴコマンド２１０に含まれる要求先ＵＲＬと同じＵＲＬ）を含む。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、仲介サーバ５０からサービスリストデータ２１２を受信する。この場合、携帯端末１５０（ブラウザ）は、サービスリストデータ２１２によって表わされるサービスリスト画面２１２ａ（図４参照）を表示させる。サービスリスト画面２１２ａの最上欄は、サービスリストデータ２１２内のＵＲＬ「http://www.aa.com」を示す。また、サービスリスト画面２１２ａは、サービス提供サーバ１００，１１０のそれぞれのサービス名（即ち、「AAA」、「BBB」）を含む。

ユーザは、サービスリスト画面２１２ａを見ながら、携帯端末１５０を操作して、１個のサービス名（例えばAAA」）を選択し、その後、図示省略のＯＫボタンを選択する。これにより、携帯端末１５０（ブラウザ）は、選択結果（例えば「AAA」）を含むＰＯＳＴコマンド２１４を生成する。次いで、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、ＰＯＳＴコマンド２１４を仲介サーバ５０に送信する。

なお、携帯端末１５０（ブラウザ）がＰＯＳＴコマンド２１４を生成するためのスクリプトは、サービスリストデータ２１２に含まれる。このために、携帯端末１５０に特別なアプリケーションをインストールしなくても、携帯端末１５０（ブラウザ）は、ＰＯＳＴコマンド２１４を生成して送信することができる。

仲介サーバ５０の制御部７０は、ＨＴＴＰ通信を利用して、携帯端末１５０（ブラウザ）からＰＯＳＴコマンド２１４を受信する。この場合、制御部７０は、ＰＯＳＴコマンド２１４に含まれる選択結果に対応するＵＲＬを生成して、当該ＵＲＬをリダイレクトＵＲＬとして含むＨＴＴＰのリダイレクトコマンド２１６を生成する。なお、ＨＴＴＰのリダイレクトコマンドは、当該リダイレクトコマンドに含まれるＵＲＬ（即ちリダイレクトＵＲＬ）へのアクセスを指示するコマンドである。

ＰＯＳＴコマンド２１４に含まれる選択結果が、サービス提供サーバ１００のサービス名「AAA」を示す場合には、制御部７０は、サービス提供サーバ１００のＵＲＬ「http://www.bb.com」を、メモリ７４から取得する。制御部７０は、さらに、後述の図３のＳ４０の処理を実行するためのＵＲＬ（以下では「戻りＵＲＬ」と呼ぶ）を、メモリ７４から取得する。戻りＵＲＬは、「http://www.aa.com/id」であり、仲介サーバ５０のサーバ名「www.aa.com」を含む（即ち、仲介サーバ５０内の位置を示す）。次いで、制御部７０は、サービス提供サーバ１００のＵＲＬ「http://www.bb.com」と、戻りＵＲＬが記述されたクエリ部「?URL=http://www.aa.com/id」と、を組み合わせることによって、第１の組合せＵＲＬを生成する。なお、以下では、ＵＲＬがクエリ部（「?」以降の部分）を含む場合には、クエリ部よりも前の部分（即ち「?」より前の部分）のことを「ドメイン部」と呼ぶ。例えば、第１の組合せＵＲＬでは、ドメイン部が「http://www.bb.com」であり、クエリ部が「?URL=http://www.aa.com/id」である。

仮に、ＰＯＳＴコマンド２１４に含まれる選択結果が、サービス提供サーバ１１０のサービス名「BBB」を示す場合には、制御部７０は、サービス提供サーバ１１０のＵＲＬ（図示省略）を示すドメイン部と、上記の戻りＵＲＬが記述されたクエリ部と、を組み合わせることによって、第１の組合せＵＲＬを生成する。

制御部７０は、生成済みの第１の組合せＵＲＬをリダイレクトＵＲＬとして含むリダイレクトコマンド２１６を生成し、ＨＴＴＰ通信を利用して、リダイレクトコマンド２１６を携帯端末１５０（ブラウザ）に送信する。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、仲介サーバ５０からリダイレクトコマンド２１６を受信する。この場合、携帯端末１５０（ブラウザ）は、リダイレクトコマンド２１６に従って、リダイレクトＵＲＬ（即ち第１の組合せＵＲＬ）にアクセスする。即ち、携帯端末１５０（ブラウザ）は、第１の組合せＵＲＬを要求先ＵＲＬとして含むＧＥＴコマンド２１８を生成する。図２の例では、要求先ＵＲＬのドメイン部「http://www.bb.com」は、サービス提供サーバ１００のサーバ名「www.bb.com」を含む（即ち、サービス提供サーバ１００内の位置を示す）。従って、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、ＧＥＴコマンド２１８をサービス提供サーバ１００に送信する。

サービス提供サーバ１００は、携帯端末１５０（ブラウザ）からＧＥＴコマンド２１８を受信する場合に、ログインデータ２２０をサービス提供サーバ１００のメモリ（図示省略）から取得する。ログインデータ２２０は、図４のログイン画面２２０ａを表わすウェブデータであり、携帯端末１５０（ブラウザ）が解釈可能な形式を有する。次いで、サービス提供サーバ１００は、ログインデータ２２０を携帯端末１５０（ブラウザ）に送信する。ログインデータ２２０は、ウェブページ（即ち図４のログイン画面２２０ａ）のページＵＲＬとして、第１の組合せＵＲＬ（即ち、ＧＥＴコマンド２１８に含まれる要求先ＵＲＬと同じＵＲＬ）を含む。

なお、サービス提供サーバ１００は、ＧＥＴコマンド２１８に含まれる第１の組合せＵＲＬを取得することができるので、第１の組合せＵＲＬ内のクエリ部（「?」以降の部分）に記述されている戻りＵＲＬ「http://www.aa.com/id」を用いて、後述の図３のリダイレクトコマンド２５０を送信することができる。このような仕組み、即ち、ＧＥＴコマンドの要求先ＵＲＬ内のクエリ部に記述されているＵＲＬを用いて、リダイレクトコマンドを送信する仕組みは、サービス提供サーバ１００に予め搭載されている。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、仲介サーバ５０からログインデータ２２０を受信する。この場合、携帯端末１５０（ブラウザ）は、ログインデータ２２０によって表わされるログイン画面２２０ａ（図４）を表示させる。ログイン画面２２０ａの最上欄は、ログインデータ２２０内のＵＲＬ（即ち第１の組合せＵＲＬ）を示す。また、ログイン画面２２０ａは、ログインＩＤを入力するためのボックスと、パスワードを入力するためのボックスと、を含む。

ユーザは、ログイン画面２２０ａを見ながら、携帯端末１５０を操作して、ログインＩＤ及びパスワードを入力する。即ち、ユーザは、上記の事前準備でサービス提供サーバ１００に予め登録しておいたログインＩＤ及びパスワードを入力する。その後、ユーザは、ログイン画面２２０ａ内の図示省略のＯＫボタンを選択する。これにより、携帯端末１５０（ブラウザ）は、ログインＩＤ及びパスワードを含むＰＯＳＴコマンド２２２を生成する。携帯端末１５０（ブラウザ）がＰＯＳＴコマンド２２２を生成するためのスクリプトは、ログインデータ２２０に含まれる。次いで、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、ＰＯＳＴコマンド２２２をサービス提供サーバ１００に送信する。

Ｓ２０では、サービス提供サーバ１００は、携帯端末１５０（ブラウザ）からＰＯＳＴコマンド２２２を受信する場合に、ＰＯＳＴコマンド２２２に含まれるログインＩＤ及びパスワードの認証を実行する。認証が成功すると、Ｓ２２において、サービス提供サーバ１００は、ＭＦＰ１０がサービス提供サーバ１００からサービスを受けるためのアクセストークン２３０を生成する。次いで、サービス提供サーバ１００は、仲介サーバ５０にアクセストークン２３０を送信する。

仲介サーバ５０の取得部８７は、ＨＴＴＰ通信を利用して、サービス提供サーバ１００からアクセストークン２３０を受信することによって、アクセストークン２３０を取得する。この場合、Ｓ３０では、仲介サーバ５０の生成部８６は、例えば、複数個のアルファベットをランダムに選択して組み合わせることによって、テンポラリＩＤ（本実施例では文字列「xyz」）を生成する。そして、生成部８６は、アクセストークン２３０とテンポラリＩＤとを対応付けて、メモリ７４に記憶させる。これにより、後述の図３において、仲介サーバ５０は、テンポラリＩＤを含むアクセストークン要求２８０をＭＦＰ１０から受信する場合に、テンポラリＩＤに対応付けられているアクセストークン２３０をＭＦＰ１０に送信することができる。

（ケースＡ１；図３（図２の続き））
上述したように、サービス提供サーバ１００は、携帯端末１５０（ブラウザ）から図２のＧＥＴコマンド２１８を受信することによって、第１の組合せＵＲＬを取得する。サービス提供サーバ１００は、第１の組合せＵＲＬから、クエリ部（「?」以降の部分）に含まれる戻りＵＲＬ「http://www.aa.com/id」を抽出する。そして、図３に示されるように、サービス提供サーバ１００は、抽出済みの戻りＵＲＬをリダイレクトＵＲＬとして含むリダイレクトコマンド２５０を生成して、リダイレクトコマンド２５０を携帯端末１５０（ブラウザ）に送信する。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、サービス提供サーバ１００からリダイレクトコマンド２５０を受信する。この場合、携帯端末１５０（ブラウザ）は、リダイレクトコマンド２５０に従って、リダイレクトＵＲＬ（即ち上記の戻りＵＲＬ）にアクセスする。即ち、携帯端末１５０（ブラウザ）は、上記の戻りＵＲＬを要求先ＵＲＬとして含むＧＥＴコマンド２５２を生成する。戻りＵＲＬは、仲介サーバ５０のサーバ名「www.aa.com」を含む。従って、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、ＧＥＴコマンド２５２を仲介サーバ５０に送信する。

仲介サーバ５０の第１の受信部８１は、ＨＴＴＰ通信を利用して、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５２を受信する。仲介サーバ５０の制御部７０は、ＧＥＴコマンド２５２内の要求先ＵＲＬ（即ち戻りＵＲＬ）に「/id」が含まれることを認識すると、後述のＳ４０の処理のためのプログラムを起動させて、当該プログラムに従って、Ｓ４０の処理を実行する。

上述したように、本実施例では、仲介サーバ５０は、戻りＵＲＬ（即ち第１の組合せＵＲＬのクエリ部）を含むリダイレクトコマンド２１６を、携帯端末１５０（ブラウザ）に送信する（図２参照）。このために、携帯端末１５０（ブラウザ）は、各データ２１８，２２０，２２２，２５０の通信をサービス提供サーバ１００と実行した後に、戻りＵＲＬにアクセスする。このために、ユーザが仲介サーバ５０にアクセスするための操作を携帯端末１５０（ブラウザ）に加えなくても、携帯端末１５０（ブラウザ）は、仲介サーバ５０にアクセスして（即ちＧＥＴコマンド２５２を送信して）、仲介サーバ５０にＳ４０の処理を適切に実行させることができる。

Ｓ４０では、仲介サーバ５０の準備部８５は、後述のメッセージデータ２５８の位置を示すメッセージＵＲＬ「http://www.aa.com/message」を、メモリ７４から取得する。次いで、準備部８５は、図２のＳ３０で生成されたテンポラリＩＤ「xyz」をメモリ７４から取得する。準備部８５は、メッセージＵＲＬを示すドメイン部と、テンポラリＩＤが記述されているクエリ部「?ID=xyz」と、を組み合わせることによって、第２の組合せＵＲＬ「http://www.aa.com/message?ID=xyz」を生成する。

次いで、準備部８５は、第２の組合せＵＲＬをリダイレクトＵＲＬとして含むリダイレクトコマンド２５４を生成することによって、リダイレクトコマンド２５４を準備する。そして、仲介サーバ５０の第１の送信部８３は、ＨＴＴＰ通信を利用して、リダイレクトコマンド２５４を携帯端末１５０（ブラウザ）に送信する。

なお、Ｓ４０では、準備部８５は、さらに、メッセージデータ２５８を生成する。メッセージデータ２５８は、図４のメッセージ画面２５８ａを表わすウェブデータであり、携帯端末１５０（ブラウザ）が解釈可能な形式を有する。メッセージデータ２５８は、メッセージ３００ａ（図４参照）を表わす文字データと、メッセージ３００ｂを表わす文字データと、を含む。メッセージ３００ａは、携帯端末１５０とＭＦＰ１０との間でＮＦＣ通信が実行されるように、携帯端末１５０をＭＦＰ１０に近づけることをユーザに促すためのメッセージである。

メッセージ３００ｂは、携帯端末１５０をＭＦＰ１０に近づけても反応がない場合（即ちＮＦＣ通信が開始されない場合）、又は、携帯端末１５０がＮＦＣＩ／Ｆを備えない場合に、ＭＦＰ１０の操作部１２を操作して、テンポラリＩＤをＭＦＰ１０に入力することをユーザに促すためのメッセージである。詳しくは後述するが、本実施例の携帯端末１５０（ＯＳ）は、ＮＦＣ接続が確立される際に、フォアグラウンドのプログラムとしてウェブブラウザが動作している場合に、当該ウェブブラウザによって表示されているウェブページのＵＲＬをＮＦＣ通信によって送信する仕組みを有する。しかしながら、このような仕組みを有さないＯＳプログラム（以下では「非対応ＯＳ」と呼ぶ）も存在し得る。仮に、携帯端末１５０が、ＮＦＣＩ／Ｆ１６を備えているものの、非対応ＯＳを搭載している場合には、ウェブページのＵＲＬをＮＦＣ通信によって送信することができない。そこで、メッセージ３００ｂでは、携帯端末１５０をＭＦＰ１０に近づけても反応がない場合に、テンポラリＩＤをＭＦＰ１０に入力することをユーザに促している。

メモリ７４は、メッセージデータ２５８を生成するためのテンプレートを予め記憶している。テンプレートは、上記の各文字データを含む。ただし、テンプレートでは、テンポラリＩＤの具体的な値（即ち「xyz」）が記述されていない。このために、Ｓ４０では、準備部８５は、テンポラリＩＤ（即ち「xyz」）をテンプレートに記述することによって、メッセージデータ２５８を生成する。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、仲介サーバ５０からリダイレクトコマンド２５４を受信する。この場合、携帯端末１５０（ブラウザ）は、リダイレクトコマンド２５４に従って、リダイレクトＵＲＬ（即ち第２の組合せＵＲＬ）にアクセスする。即ち、携帯端末１５０（ブラウザ）は、第２の組合せＵＲＬを要求先ＵＲＬとして含むＧＥＴコマンド２５６を生成する。第２の組合せＵＲＬは、仲介サーバ５０のサーバ名「www.aa.com」を含む。従って、携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、ＧＥＴコマンド２５６を仲介サーバ５０に送信する。

仲介サーバ５０の制御部７０は、ＨＴＴＰ通信を利用して、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５６を受信する。制御部７０は、ＧＥＴコマンド２５６内の要求先ＵＲＬ（即ち第２の組合せＵＲＬ）にリソース部「message」が含まれることを認識すると、メッセージデータ２５８を送信するためのプログラムを起動させる。そして、制御部７０は、当該プログラムに従って、ＨＴＴＰ通信を利用して、メッセージデータ２５８を携帯端末１５０（ブラウザ）に送信する。メッセージデータ２５８は、ウェブページ（即ち図４のメッセージ画面２５８ａ）のページＵＲＬとして、第２の組合せＵＲＬ（即ち、ＧＥＴコマンド２５６に含まれる要求先ＵＲＬと同じＵＲＬ）を含む。

上述したように、仲介サーバ５０は、携帯端末１５０からＧＥＴコマンド２５２を受信する場合に、第２の組合せＵＲＬ及びメッセージデータ２５８を生成し（Ｓ４０）、次いで、リダイレクトコマンド２５４及びＧＥＴコマンド２５６の通信を実行した後に、第２の組合せＵＲＬを含むメッセージデータ２５８を携帯端末１５０に送信する。このような構成を採用せずに、仲介サーバ５０が、ＧＥＴコマンド２５２のレスポンスとして、第２の組合せＵＲＬを含むメッセージデータ２５８を携帯端末１５０に送信する構成（即ち、リダイレクトコマンド２５４及びＧＥＴコマンド２５６の通信を省略する構成）を採用することが考えられる。

しかしながら、ＨＴＴＰの仕組みでは、ウェブサーバ（即ち仲介サーバ５０）は、クライアント（即ち携帯端末１５０）からＧＥＴコマンドを受信して、ＧＥＴコマンドのレスポンスとしてウェブデータを送信する際に、当該ＧＥＴコマンド内の要求先ＵＲＬを、当該ウェブデータのページＵＲＬとして利用しなければならない。従って、仮に、仲介サーバ５０がＧＥＴコマンド２５２のレスポンスとしてメッセージデータ２５８を送信する構成を採用すると、仲介サーバ５０は、ＧＥＴコマンド２５２内の要求先ＵＲＬである戻りＵＲＬ「http://www.aa.com/id」を、メッセージデータ２５８のページＵＲＬとして記述せざるを得ず、テンポラリＩＤが記述された第２の組合せＵＲＬを、メッセージデータ２５８のページＵＲＬとして記述することができない。

本実施例では、上記の実情に鑑みて、仲介サーバ５０は、ＧＥＴコマンド２５２のレスポンスとして、ウェブデータではなく、第２の組合せＵＲＬをリダイレクトＵＲＬとして含むリダイレクトコマンド２５４を送信して、ＧＥＴコマンド２５６を受信する構成を採用している。この結果、仲介サーバ５０は、ＧＥＴコマンド２５６内の要求先ＵＲＬである第２の組合せＵＲＬを、メッセージデータ２５８のページＵＲＬとして記述することができる。これにより、仲介サーバ５０は、テンポラリＩＤが記述された第２の組合せＵＲＬをページＵＲＬとして含むメッセージデータ２５８を、携帯端末１５０に適切に送信することができる。

携帯端末１５０（ブラウザ）は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）を利用して、仲介サーバ５０からメッセージデータ２５８を受信する。この場合、携帯端末１５０（ブラウザ）は、メッセージデータ２５８によって表わされるメッセージ画面２５８ａ（図４）を表示させる。メッセージ画面２５８ａの最上欄は、メッセージデータ２５８内のＵＲＬ（即ち第２の組合せＵＲＬ）を示す。また、メッセージ画面２５８ａは、各メッセージ３００ａ，３００ｂを含む。

ユーザは、メッセージ画面２５８ａ内のメッセージ３００ａを見ることによって、ＮＦＣ通信を実行可能な携帯端末１５０をＭＦＰ１０に近づけるべきであることを知ることができる。このために、ユーザは、携帯端末１５０をＭＦＰ１０に近づける。この結果、ＭＦＰ１０と携帯端末１５０（ＯＳ）との間にＮＦＣ接続が再び確立される。

携帯端末１５０（ＯＳ）は、ＮＦＣ接続が確立される場合に、当該ＮＦＣ接続を利用して（即ちＮＦＣ通信を利用して）、メッセージ画面２５８ａに記述されているＵＲＬ（即ち第２の組合せＵＲＬ）をＭＦＰ１０に送信する。このように、ウェブページ（即ちメッセージ画面２５８ａ）が表示されている状態で、ＮＦＣ接続が確立される場合に、当該ＮＦＣ接続を利用して、当該ウェブページのページＵＲＬ（即ち第２の組合せＵＲＬ）を送信する仕組みは、ＯＳプログラムに予め搭載されている仕組みである。即ち、携帯端末１５０（ＯＳ）は、ＮＦＣ接続が確立される際に、フォアグラウンドのプログラムとしてウェブブラウザが動作している場合に、当該ウェブブラウザによって表示されているウェブページのＵＲＬをＮＦＣ通信によって送信する仕組みを有する。従って、携帯端末１５０に特別なアプリケーションプログラムをインストールしなくても、携帯端末１５０（ＯＳ）は、ＮＦＣ通信を利用して、第２の組合せＵＲＬをＭＦＰ１０に送信することができる。換言すると、携帯端末１５０（ＯＳ）は、ＮＦＣ通信を利用して、第２の組合せＵＲＬのクエリ部に記述されているテンポラリＩＤをＭＦＰ１０に送信することができる。

なお、メッセージ画面２５８ａ内のメッセージ３００ｂは、テンポラリＩＤを含む。このために、携帯端末１５０が、メッセージ画面２５８ａ内のメッセージ３００ｂを抽出し、ＮＦＣ通信を利用して、メッセージ３００ｂをＭＦＰ１０に送信することによって、テンポラリＩＤをＭＦＰ１０に供給する構成を採用することが考えられる。しかしながら、携帯端末１５０が、ＨＴＴＰ通信の結果としてウェブデータ（即ちメッセージデータ２５８）を受信する場合に、ＮＦＣ通信を利用して、ウェブデータそのもの（もしくはウェブデータ内の一部の文字列）を送信するためには、携帯端末１５０に特別なアプリケーションプログラムをインストールする必要がある。このような実情に鑑みて、本実施例では、仲介サーバ５０が、テンポラリＩＤが記述された第２の組合せＵＲＬを生成し（Ｓ４０）、第２の組合せＵＲＬをページＵＲＬとして含むメッセージデータ２５８を携帯端末１５０に送信する構成を採用している。これにより、携帯端末１５０に特別なアプリケーションプログラムをインストールしなくても、携帯端末１５０（ＯＳ）は、ＮＦＣ通信を利用して、第２の組合せＵＲＬをＭＦＰ１０に送信することによって、テンポラリＩＤをＭＦＰ１０に適切に供給することができる。

ＭＦＰ１０の受信部４１は、ＮＦＣ通信を利用して、携帯端末１５０（ＯＳ）から第２の組合せＵＲＬを受信する。この場合、Ｓ５０では、ＭＦＰ１０の抽出部４３は、第２の組合せＵＲＬからテンポラリＩＤを抽出する。具体的に言うと、抽出部４３は、第２の組合せＵＲＬに含まれるクエリ部から、テンポラリＩＤの先頭を示す文字列「ID=」を探し出し、その文字列「ID=」より後ろに記述されている文字列「xyz」を抽出する。

次いで、ＭＦＰ１０の処理実行部４２は、抽出済みのテンポラリＩＤを含むアクセストークン要求２８０を生成して、ＨＴＴＰ通信を利用して、アクセストークン要求２８０を仲介サーバ５０に送信する。なお、アクセストークン要求２８０は、ＨＴＴＰのＧＥＴコマンドであってもよいし、ＰＯＳＴコマンドであってもよい。

仲介サーバ５０の第２の受信部８２は、ＨＴＴＰ通信を利用して、ＭＦＰ１０からアクセストークン要求２８０を受信する。この場合、仲介サーバ５０の第２の送信部８４は、アクセストークン要求２８０に含まれるテンポラリＩＤ「xyz」に対応付けられているアクセストークン２３０をメモリ７４から読み出す。そして、第２の送信部８４は、ＨＴＴＰ通信を利用して、アクセストークン２３０をＭＦＰ１０に送信する。

例えば、複数のユーザが図２及び図３の動作を同時的に実行する場合には、仲介サーバ５０が、複数のユーザのための複数個のアクセストークンを、メモリ７４に同時的に記憶させなければならない状況が起こり得る。従って、仮に、メモリ７４において、テンポラリＩＤとアクセストークンとが対応付けられていなければ、仲介サーバ５０は、アクセストークン要求２８０を受信する場合に、複数個のアクセストークンのうちのどのアクセストークンをＭＦＰ１０に送信すればよいのかわからない。本実施例では、図２のＳ３０において、仲介サーバ５０は、アクセストークンとテンポラリＩＤとを対応付けて、メモリ７４に格納させておく。これにより、仲介サーバ５０は、ＭＦＰ１０からアクセストークン要求２８０を受信する場合に、テンポラリＩＤに対応付けられているアクセストークン２３０をＭＦＰ１０に適切に送信することができる。

ＭＦＰ１０の処理実行部４２は、ＨＴＴＰ通信を利用して、仲介サーバ５０からアクセストークン２３０を受信する。この場合、処理実行部４２は、アクセストークン２３０を用いて、サービス提供サーバ１００からデータ供給サービスを受けるための処理を実行する。即ち、処理実行部４２は、ＨＴＴＰ通信を利用して、アクセストークン２３０を含むファイル取得要求２９０（例えばＨＴＴＰのＧＥＴコマンド）をサービス提供サーバ１００に送信する。

サービス提供サーバ１００は、ＭＦＰ１０からファイル取得要求２９０を受信する場合に、ファイル取得要求２９０に含まれるアクセストークン２３０を用いて、認証を実行する。即ち、サービス提供サーバ１００は、アクセストークン２３０がサービス提供サーバ１００自身によって生成されたものであるのか否かを判断する。アクセストークン２３０の認証が成功すると、サービス提供サーバ１００は、ユーザによって過去にサービス提供サーバ１００にアップロードされたファイル２９２をＭＦＰ１０に送信する。即ち、サービス提供サーバ１００は、データ供給サービスを提供する。

ＭＦＰ１０の処理実行部４２は、サービス提供サーバ１００からファイル２９２を受信する場合に、ファイル２９２に含まれる画像データを印刷実行部１８に供給する。印刷実行部１８は、画像データによって表わされる画像を印刷媒体に印刷する。これにより、ＭＦＰ１０は、サービス提供サーバ１００からデータ供給サービスを受けて、ＤＬ印刷処理を実行することができる。換言すると、携帯端末１５０のユーザは、携帯端末１５０を用いて、ＭＦＰ１０にＤＬ印刷処理を実行させることができる。

（ＰＣ１６０が利用されるケースＢ；図５）
続いて、ＰＣ１６０が利用されるケースＢについて説明する。ＰＣ１６０は、ＮＦＣ通信を実行することができない。従って、ＰＣ１６０は、Ｗｉ−Ｆｉ通信を利用して（もしくは有線ＬＡＮを介した有線通信を実行して）、図５及び図６に示される各通信を実行する。

ユーザは、ＰＣ１６０のブラウザを起動させて、キーボード、マウス等の操作装置を用いて、仲介サーバ５０のＵＲＬをＰＣ１６０に入力する。ここで入力される仲介サーバ５０のＵＲＬ「http://www.aa.com」は、図２のケースＡにおいて、携帯端末１５０（ＯＳ）がＮＦＣ通信の結果としてＭＦＰ１０から受信する仲介サーバ５０のＵＲＬと同じものである。なお、仲介サーバ５０のＵＲＬは、例えば、ＭＦＰ１０のための説明書等の中に記述されており、ＰＣ１６０のユーザに予め通知されている。

ＰＣ１６０は、仲介サーバ５０のＵＲＬにアクセスする。即ち、ＰＣ１６０は、仲介サーバ５０のＵＲＬを要求先ＵＲＬとして含むＧＥＴコマンド２１０を仲介サーバ５０に送信する。以降の各処理は、図２のケースＡと同様である。

（ケースＢ１；図６（図５の続き））
ＰＣ１６０が仲介サーバ５０からメッセージデータ２５８を受信するまでの各処理は、図３のケースＡ１と同様である。ＰＣ１６０は、仲介サーバ５０からメッセージデータ２５８を受信する場合に、メッセージ画面２５８ａ（図４参照）を表示させる。ユーザは、ＰＣ１６０がＮＦＣ通信を実行不可能であることを知っている。このために、ユーザは、メッセージ画面２５８ａ内のメッセージ３００ｂを見て、ＭＦＰ１０の操作部１２を操作して、テンポラリＩＤ「xyz」をＭＦＰ１０に入力する。

ＭＦＰ１０の処理実行部４２は、テンポラリＩＤ「xyz」が入力される場合に、図３のケースＡ１と同様に、テンポラリＩＤ「xyz」を含むアクセストークン要求２８０を仲介サーバ５０に送信して、仲介サーバ５０からアクセストークン２３０を受信する。以降の各処理は、図３のケースＡ１と同様である。ＰＣ１６０のユーザは、ＰＣ１６０を用いて、ＭＦＰ１０にＤＬ印刷処理を実行させることができる。

なお、本実施例では、図３のケースＡ１でも、図６のケースＢ１でも、ＭＦＰ１０の制御部３０は、アクセストークン２３０を用いて、ＤＬ印刷処理を実行すると、アクセストークン２３０を破棄する（即ちメモリ３４から消去する）。ただし、変形例では、制御部３０は、アクセストークン２３０と、ユーザ名（例えば、操作部１２に入力されるユーザ名）と、サービス提供サーバ１００のサービス名と、を関連付けて、メモリ３４に継続して記憶させてもよい。この場合、例えば、ユーザが、サービス提供サーバ１００からデータ供給サービスを受けて、ＭＦＰ１０にＤＬ印刷処理を再び実行させることを望む場合に、ＭＦＰ１０は、メモリ３４内のアクセストークン２３０を用いて、ＤＬ印刷処理を実行することができる。

（第１実施例の効果）
仮に、ＭＦＰ１０がウェブサーバ機能を備えており、かつ、携帯端末１５０及びＭＦＰ１０が同一のＬＡＮに接続されている場合には、ユーザは、メッセージ画面２５８ａ内のメッセージ３００ｂ（図４参照）からテンポラリＩＤを知得した後に、例えば、携帯端末１５０を用いて、ＭＦＰ１０のウェブサーバにアクセスし得る。そして、ユーザは、ＭＦＰ１０のウェブサーバから供給されるウェブ画面上でテンポラリＩＤを入力すれば、ＭＦＰ１０にテンポラリＩＤを供給し得る。しかしながら、上述したように、本実施例では、携帯端末１５０及びＭＦＰ１０が同一のＬＡＮに接続されていない状況を想定している。このような状況では、携帯端末１５０は、ＨＴＴＰ通信を利用して、ＭＦＰ１０にアクセスすることができない。そこで、本実施例では、図２及び図３のケースＡ，Ａ１に示されるように、携帯端末１５０及びＭＦＰ１０が同一のＬＡＮに接続されていない状況でも、携帯端末１５０がＭＦＰ１０にテンポラリＩＤを適切に供給するための技術を採用している。

即ち、仲介サーバ５０は、サービス提供サーバ１００からアクセストークン２３０を取得する場合に、テンポラリＩＤ「xyz」を生成して、テンポラリＩＤとアクセストークン２３０とを対応付けて、メモリ７４に記憶させる（図２のＳ３０）。そして、仲介サーバ５０は、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５２を受信する場合に、テンポラリＩＤが記述された第２の組合せＵＲＬを含むリダイレクトコマンド２５４を携帯端末１５０（ブラウザ）に送信する。携帯端末１５０（ブラウザ）は、ＧＥＴコマンド２５６を仲介サーバ５０に送信して、仲介サーバ５０からメッセージデータ２５８を受信し、この結果、メッセージ画面２５８ａ（図４参照）を表示させる。

ユーザは、メッセージ画面２５８ａ内のメッセージ３００ａを見て、携帯端末１５０をＭＦＣ１０に近づける。この結果、携帯端末１５０（ＯＳ）は、ＮＦＣ通信を利用して、第２の組合せＵＲＬをＭＦＰ１０に送信することによって、テンポラリＩＤをＭＦＰ１０に供給する。従って、ＰＣ１６０が利用される場合（図５、図６参照）とは異なり、ユーザは、ＭＦＰ１０の操作部１２を操作して、テンポラリＩＤをＭＦＰ１０に入力しなくて済むために、テンポラリＩＤをＭＦＰ１０に容易に供給することができる。特に、テンポラリＩＤを構成する文字数（例えばアルファベットの数）が多い場合には、本実施例の技術が効果的である。本実施例によると、ユーザの利便性を向上させることができる。

また、本実施例では、第２の組合せＵＲＬ内のクエリ部にテンポラリＩＤが記述される。このために、携帯端末１５０は、ＯＳプログラムに予め搭載されている仕組み、即ち、フォアグラウンドで動作しているメッセージ画面２５８ａのページＵＲＬをＮＦＣ通信で送信する仕組みに従って、第２の組合せＵＲＬをＭＦＰ１０に送信することができる。携帯端末１５０に特別なアプリケーションプログラムをインストールしなくても、携帯端末１５０（ＯＳ）は、ＮＦＣ通信を利用して、テンポラリＩＤをＭＦＰ１０に適切に送信することができる。

図５及び図６のケースＢ，Ｂ１に示されるように、ユーザが、ＮＦＣ通信を実行不可能なＰＣ１６０を用いて、ＭＦＰ１０にＤＬ印刷処理を実行させることを望む可能性がある。このために、仲介サーバ５０は、メッセージ３００ａのみならず、メッセージ３００ｂを含むメッセージ画面２５８ａを表わすメッセージデータ２５８を準備する。このために、ＮＦＣ通信を実行可能な携帯端末１５０が利用される場合でも、ＮＦＣ通信を実行不可能なＰＣ１６０が利用される場合でも、ユーザは、テンポラリＩＤをＭＦＰ１０に適切に供給することができる。

また、ＭＦＰ１０は、ＮＦＣ通信を利用して、携帯端末１５０から第２の組合せＵＲＬを受信する場合に、第２の組合せＵＲＬからテンポラリＩＤを適切に抽出することができる。このために、ＭＦＰ１０は、テンポラリＩＤを用いて、仲介サーバ５０からアクセストークン２３０を適切に取得することができる。また、ＭＦＰ１０は、アクセストークン２３０を用いて、サービス提供サーバ１００からデータ供給サービスを受けて、ＤＬ印刷処理を適切に実行することができる。

（対応関係）
ＭＦＰ１０、仲介サーバ５０、携帯端末１５０が、それぞれ、「通信装置」、「特定のサーバ」、「第１の端末装置」の一例である。Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）、ＮＦＣ通信が、それぞれ、「第１種の無線通信」、「第２種の無線通信」の一例である。リダイレクトコマンド２５４が、「第１の特定データ」及び「第１のアクセスコマンド」の一例である。ＧＥＴコマンド２５２、アクセストークン要求２８０、リダイレクトコマンド２５０が、それぞれ、「第１の送信要求」、「特定の送信要求」、「第２のアクセスコマンド」の一例である。第２の組合せＵＲＬ、戻りＵＲＬが、それぞれ、「第１の位置情報」、「第２の位置情報」の一例である。メッセージデータ２５８、メッセージ画面２５８ａ、メッセージ３００ａが、それぞれ、「第１のウェブデータ」、「第１のウェブ画面」、「第１のメッセージ」の一例である。テンポラリＩＤ、アクセストークン２３０が、それぞれ、「対象データ」、「認証情報」の一例である。アクセストークン要求２８０の送信処理及びＤＬ印刷処理が、「特定の処理」の一例である。

（第２実施例）
第１実施例と異なる点を説明する。第１実施例では、仲介サーバ５０は、ＮＦＣ通信を実行可能な携帯端末１５０が利用される場合でも、ＮＦＣ通信を実行不可能なＰＣ１６０が利用される場合でも、同じメッセージ画面２５８ａを携帯端末１５０及びＰＣ１６０に表示させる。本実施例では、仲介サーバ５０は、携帯端末１５０及びＰＣ１６０に異なるメッセージ画面２５８ａ−１，２５８ａ−２（図９（Ａ）、（Ｂ）参照）を表示させる。

（携帯端末１５０が利用されるケースＡ２；図７（図２の続き））
ＮＦＣ通信を実行可能な携帯端末１５０が利用される場合には、図２のケースＡと同様に、各通信及び各処理が実行される。その後、図７に示されるように、携帯端末１５０（ブラウザ）は、サービス提供サーバ１００からリダイレクトコマンド２５０を受信する場合に、ＯＳ情報を含むＧＥＴコマンド２５２を仲介サーバ５０に送信する。ＯＳ情報は、携帯端末１５０のＯＳプログラムの名称及びバージョン（例えばAndroid 4.0（登録商標）等）を示す。ウェブブラウザには、通常、ＯＳ情報を含むＨＴＴＰのＧＥＴコマンドを送信する仕組みが搭載されている。従って、携帯端末１５０に特別なアプリケーションをインストールしなくても、携帯端末１５０（ブラウザ）は、ＯＳ情報を含むＧＥＴコマンド２５２を仲介サーバ５０に送信することができる。

仲介サーバ５０のメモリ７４は、公知の様々なＯＳプログラムについて、ＯＳ情報と、ＮＦＣ通信をサポートしているのか否かを示すＮＦＣ情報と、が関連付けられている判断用情報を予め記憶している。ＭＦＰ１０のベンダは、公知の様々なＯＳプログラムを調査して、判断用情報をメモリ７４に予め記憶させておく。

仲介サーバ５０の判断部８８は、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５２を受信する場合に、ＧＥＴコマンド２５２に含まれるＯＳ情報と、メモリ７４内の判断用情報と、を用いて、携帯端末１５０のＯＳプログラムがＮＦＣ通信をサポートしているのか否かを判断する。

メモリ７４内の判断用情報では、携帯端末１５０のＯＳプログラムに関するＯＳ情報と、ＮＦＣ通信をサポートしていることを示すＮＦＣ情報と、が関連付けられている。従って、Ｓ３２では、判断部８８は、携帯端末１５０のＯＳプログラムがＮＦＣ通信をサポートしていると判断する。この場合、Ｓ４２では、仲介サーバ５０の準備部８５は、後述のメッセージデータ２５８−１の位置を示すメッセージＵＲＬを、メモリ７４から取得する。ここで取得されるメッセージＵＲＬ「・・・message1」は、第１実施例の図３のＳ４０で取得されるメッセージＵＲＬ「・・・message」とは異なる。なお、「・・・」は、「http://www.aa.com/」を省略したものである。準備部８５は、メッセージＵＲＬを示すドメイン部と、テンポラリＩＤが記述されたクエリ部と、を組み合わせることによって、第２の組合せＵＲＬ「・・・message1?ID=xyz」を生成する。

メモリ７４は、メッセージ画面２５８ａ−１（図９参照）を表わすメッセージデータ２５８−１を生成するための第１のテンプレートと、メッセージ画面２５８ａ−２（図９参照）を表わすメッセージデータ２５８−２を生成するための第２のテンプレートと、を予め記憶している。Ｓ４２では、準備部８５は、さらに、第１のテンプレートを用いて、メッセージデータ２５８−１を生成する。メッセージデータ２５８−１は、メッセージ３００ａを表わす文字データと、メッセージ３００ｂを表わす文字データと、を含む（図９（Ａ）参照）。

リダイレクトコマンド２５４−１及びＧＥＴコマンド２５６−１は、第２の組合せＵＲＬが異なる点を除くと、図３のリダイレクトコマンド２５４及びＧＥＴコマンド２５６と同様である。仲介サーバ５０の制御部７０は、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５６−１を受信する場合に、メッセージデータ２５８−１を携帯端末１５０（ブラウザ）に送信する。

これにより、携帯端末１５０は、メッセージ画面２５８ａ−１（図９（Ａ）参照）を表示させる。この結果、ユーザは、携帯端末１５０をＭＦＰ１０に近づける。なお、ＯＳプログラムがＮＦＣ通信をサポートしていても、ＮＦＣＩ／Ｆが設けられていない機器が存在し得ること、また、ＮＦＣＩ／Ｆが設けられていても、搭載されているＯＳプログラムが上記の非対応ＯＳである機器（即ち、ウェブページのＵＲＬをＮＦＣ通信によって送信不可能である機器）が存在し得ることを考慮して、本実施例でも、メッセージ画面２５８ａ−１がメッセージ３００ｂを含むように、上記の第１のテンプレートが構成されている。以降の各処理は、図３のケースＡ１と同様である。

（ＰＣ１６０が利用されるケースＢ２；図８（図５の続き））
ＮＦＣ通信を実行不可能なＰＣ１６０が利用される場合には、図５のケースＢと同様に、各通信及び各処理が実行される。その後、図８に示されるように、携帯端末１５０（ブラウザ）は、ＯＳ情報を含むＧＥＴコマンド２５２を仲介サーバ５０に送信する。

メモリ７４内の判断用情報では、ＰＣ１６０のＯＳプログラム（例えばWindows（登録商標））に関するＯＳ情報と、ＮＦＣ通信をサポートしていないことを示すＮＦＣ情報と、が関連付けられている。従って、Ｓ３４では、判断部８８は、ＰＣ１６０のＯＳプログラムがＮＦＣ通信をサポートしていないと判断する。この場合、Ｓ４４では、仲介サーバ５０の準備部８５は、後述のメッセージデータ２５８−２の位置を示すメッセージＵＲＬを、メモリ７４から取得する。ここで取得されるメッセージＵＲＬ「・・・message2」は、図７のＳ４２で取得されるメッセージＵＲＬ「・・・message1」とは異なる（即ち、リソース部が異なる）。準備部８５は、図７のＳ４２とは異なり、メッセージＵＲＬとクエリ部とを含む第２の組合せＵＲＬを生成しない。図９のケースＢ２では、ＮＦＣ通信を利用してテンポラリＩＤをＭＦＰ１０に供給することを想定していないために、テンポラリＩＤを含むクエリ部が必要ないからである。

Ｓ４４では、準備部８５は、さらに、上記の第２のテンプレートを用いて、メッセージデータ２５８−２を生成する。メッセージデータ２５８−２は、メッセージ３００ｃ（図９（Ｂ）参照）を表わす文字データを含む。ただし、メッセージデータ２５８−２は、ＮＦＣ通信に関するメッセージ３００ａ（図９（Ａ）参照）を含まない。

リダイレクトコマンド２５４−２及びＧＥＴコマンド２５６−２は、第２の組合せＵＲＬの代わりに、メッセージＵＲＬ「・・・message2」が利用される点を除くと、図６のリダイレクトコマンド２５４及びＧＥＴコマンド２５６と同様である。仲介サーバ５０の制御部７０は、携帯端末１５０（ブラウザ）からＧＥＴコマンド２５６−２を受信する場合に、メッセージデータ２５８−２を携帯端末１５０（ブラウザ）に送信する。

これにより、携帯端末１５０は、メッセージ画面２５８ａ−２（図９（Ｂ）参照）を表示させる。これにより、ユーザは、ＭＦＰ１０の操作部１２を操作して、テンポラリＩＤをＭＦＰ１０に入力する。以降の各処理は、図６のケースＢ１と同様である。

上述したように、本実施例では、仲介サーバ５０は、ＮＦＣ通信を実行可能な携帯端末１５０が利用される場合には、ＮＦＣ通信に関するメッセージ３００ａを含むメッセージ画面２５８ａ−１を携帯端末１５０に適切に表示させることができる。一方において、仲介サーバ５０は、ＮＦＣ通信を実行不可能なＰＣ１６０が利用される場合には、ＮＦＣ通信に関するメッセージ３００ａを含まず、ＭＦＰ１０の操作に関するメッセージ３００ｃを含むメッセージ画面２５８ａ−２をＰＣ１６０に適切に表示させることができる。

本実施例では、携帯端末１５０及びＰＣ１６０が、「第１の端末装置」の一例である。ＯＳ情報が、「関係情報」の一例である。図７のケースＡ２、図８のケースＢ２が、それぞれ、「第１の場合」、「第２の場合」の一例である。リダイレクトコマンド２５４−１、リダイレクトコマンド２５４−２が、それぞれ、「第１の特定データ」、「第２の特定データ」の一例である。メッセージ画面２５８ａ−１、メッセージ画面２５８ａ−２が、それぞれ、「第１のウェブ画面」、「第２のウェブ画面」の一例である。メッセージ３００ａ、メッセージ３００ｃが、それぞれ、「第１のメッセージ」、「第２のメッセージ」の一例である。

（第３実施例）
本実施例では、仲介サーバ５０は、携帯端末１５０及びＰＣ１６０に異なるメッセージ画面２５８ｂ−１，２５８ａ−２（図９（Ｃ）、（Ｂ）参照）を表示させる。図９（Ｃ）に示されるように、メッセージ画面２５８ｂ−１は、メッセージ３００ａと、メッセージ３００ｄと、を含む。メッセージ３００ｄは、携帯端末１５０をＭＦＰ１０に近づけても反応がない場合に、ＭＦＰ１０の操作部１２を操作して、テンポラリＩＤを入力することをユーザに促すためのメッセージである。即ち、メッセージ３００ｄは、メッセージ３００ｂ（図９（Ａ）参照）とは異なり、ＮＦＣＩ／Ｆが設けられていない機器のユーザに向けてのメッセージ（即ち「ＮＦＣＩ／Ｆを備えていない場合には」）を含まない。後で説明するように、本実施例では、仲介サーバ５０は、携帯端末１５０がＮＦＣＩ／Ｆ１６を備えていることを確実に把握することができるからである。以下では、第２実施例と異なる点を説明する。

（携帯端末１５０が利用されるケース）
ＭＦＰ１０のメモリ３４は、ＮＦＣ通信を利用して携帯端末１５０に送信されるべき仲介サーバ５０のＵＲＬとして、第１実施例のＵＲＬ「http://www.aa.com」に代えて、ＮＦＣ用ＵＲＬ「http://www.aa.com/nfc」を予め記憶している。従って、図２のＮＦＣ接続が確立される際に、ＭＦＰ１０の制御部３０は、ＮＦＣ通信を利用して、ＮＦＣ用ＵＲＬ「・・・nfc」を携帯端末１５０（ＯＳ）に送信する。

従って、図２において、ＧＥＴコマンド２１０内の要求先ＵＲＬは、ＮＦＣ用ＵＲＬ「・・・nfc」である。仲介サーバ５０の制御部７０は、ＮＦＣ用ＵＲＬを含むＧＥＴコマンド２１０を受信する場合には、リソース部「nfc」に対応するプログラムに従って動作し、その後、リダイレクトコマンド２１６を送信する際に、戻りＵＲＬとして、第１実施例の「・・・id」に代えて、「・・・nfc/id」を利用する。この結果、図３において、リダイレクトコマンド２５０及びＧＥＴコマンド２５２は、ＵＲＬ「・・・nfc/id」を含む。仲介サーバ５０の準備部８５は、ＵＲＬ「・・・nfc/id」を含むＧＥＴコマンド２５２を受信する場合には、当該ＵＲＬのリソース部「nfc/id」に対応するプログラムに従って動作する。即ち、図７のＳ４２において、準備部８５は、メモリ７４に予め記憶されている第３のテンプレートを用いて、メッセージ画面２５８ｂ−１（図９（Ｃ）参照）を表わすメッセージデータ２５８−１を生成する。これにより、携帯端末１５０は、メッセージ画面２５８ｂ−１を表示させることができる。他の処理は、図７のケースＡ２と同様である。

（ＰＣ１６０が利用されるケース）
ＭＦＰ１０のための説明書等では、第１実施例のＵＲＬ「http://www.aa.com」に代えて、非ＮＦＣ用ＵＲＬ「http://www.aa.com/nonfc」が記述されている。非ＮＦＣ用ＵＲＬ「・・・nonfc」は、上記のＮＦＣ用ＵＲＬ「・・・nfc」とは異なる（即ち、リソース部が異なる）。図５において、ユーザは、ＰＣ１６０に非ＮＦＣ用ＵＲＬを入力する。

従って、図５において、ＧＥＴコマンド２１０内の要求先ＵＲＬは、非ＮＦＣ用ＵＲＬ「・・・nonfc」である。仲介サーバ５０の制御部７０は、非ＮＦＣ用ＵＲＬを含むＧＥＴコマンド２１０を受信する場合には、リソース部「nonfc」に対応するプログラムに従って動作し、その後、リダイレクトコマンド２１６を送信する際に、戻りＵＲＬとして、第１実施例の「・・・id」に代えて、「・・・nonfc/id」を利用する。この結果、図６において、リダイレクトコマンド２５０及びＧＥＴコマンド２５２は、ＵＲＬ「・・・nonfc/id」を含む。仲介サーバ５０の準備部８５は、ＵＲＬ「・・・nonfc/id」を含むＧＥＴコマンド２５２を受信する場合に、第２実施例の図８のケースＢ２と同様に、Ｓ４４を実行して、リダイレクトコマンド２５４−２及びメッセージデータ２５８−２を準備する。これにより、ＰＣ１６０は、メッセージ画面２５８ａ−２（図９（Ｂ）参照）を表示させることができる。他の処理は、図８のケースＢ２と同様である。

このように、本実施例では、ＮＦＣ用ＵＲＬ「・・・nfc」と非ＮＦＣ用ＵＲＬ「・・・nonfc」とが異なる。このように２つのＵＲＬが利用されるために、仲介サーバ５０は、ＧＥＴコマンド２５２内のＵＲＬがリソース部「nfc/id」を含む場合に、携帯端末１５０がＮＦＣＩ／Ｆ１６を備えることを確実に把握することができる。このために、仲介サーバ５０は、ＧＥＴコマンド２５２（図３、図６参照）を受信する場合に、ＧＥＴコマンド２５２内のＵＲＬ（即ち、リソース部「nfc/id」又は「nonfc/id」）に応じて、携帯端末１５０及びＰＣ１６０に適切なメッセージ画面２５８ｂ−１，２５８ａ−２（図９（Ｃ）、（Ｂ）参照）を表示させることができる。即ち、ＮＦＣＩ／Ｆを備える携帯端末１５０に適切なメッセージ画面２５８ｂ−１を表示させることができ、ＮＦＣＩ／Ｆを備えるか定かでない機器に適切なメッセージ画面２５８ａ−２を表示させることができる。特に、メッセージ画面２５８ｂ−１に表示されるメッセージ３００ｄは、ＮＦＣＩ／Ｆが設けられていない機器のユーザに向けてのメッセージを含まない。従って、ＮＦＣＩ／Ｆを備える携帯端末１５０に、不要なメッセージが表示されることを抑制することができる。

第２実施例では、ＭＦＰ１０のベンダは、仲介サーバ５０のメモリ７４に判断用情報を予め記憶させる必要があるが、本実施例では、このような作業が必要ない。また、第２実施例では、仮に、判断用情報の内容が正確でない場合には、例えば、ＮＦＣ通信を実行可能な携帯端末１５０が利用される状況であるにも関わらず、メッセージ画面２５８ａ−２（図９（Ｂ）参照）が表示される事象が発生する可能性がある。本実施例では、判断用情報に従った判断が実行されないので、上記の事象が発生するのを抑制することができ、携帯端末１５０、ＰＣ１６０に、それぞれ、メッセージ画面２５８ｂ−１、メッセージ画面２５８ａ−２を確実に表示させることができる。

本実施例では、携帯端末１５０、ＰＣ１６０が、それぞれ、「第１の端末装置」、「第２の端末装置」の一例である。ＵＲＬ「・・・nfc/id」、ＵＲＬ「・・・nonfc/id」が、それぞれ、「第３の位置情報」、「第４の位置情報」の一例である。また、ＵＲＬ「・・・nfc/id」を含むＧＥＴコマンド２５２、ＵＲＬ「・・・nonfc/id」を含むＧＥＴコマンド２５２が、それぞれ、「第１の送信要求」、「第２の送信要求」の一例である。

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

（変形例１）上記の第１実施例では、図３のＳ４０において、仲介サーバ５０の準備部８５は、テンポラリＩＤ「xyz」が記述された第２の組合せＵＲＬを含むリダイレクトコマンド２５４を生成する。この結果、リダイレクトコマンド２５４及びＧＥＴコマンド２５６の通信の後に、メッセージデータ２５８が携帯端末１５０（ブラウザ）に送信される。これに代えて、Ｓ４０において、準備部８５は、第２の組合せＵＲＬを生成せず、ＧＥＴコマンド２５２のレスポンスとして送信されるべきメッセージデータ２５８を準備してもよい。即ち、準備部８５は、テンポラリＩＤが記述されていない戻りＵＲＬ「・・・id」をページＵＲＬとして含むメッセージデータ２５８を準備し、さらに、メッセージデータ２５８内の所定部分（即ちページＵＲＬとは異なる部分）にテンポラリＩＤ「xyz」を記述してもよい。そして、仲介サーバ５０の第１の送信部８３は、ＧＥＴコマンド２５２のレスポンスとして、メッセージデータ２５８を携帯端末１５０に送信してもよい（即ち、リダイレクトコマンド２５４及びＧＥＴコマンド２５６の通信を省略してもよい）。

第１実施例では、携帯端末１５０（ＯＳ）は、メッセージデータ２５８内の上記の所定部分からテンポラリＩＤを抽出し、ＮＦＣ通信を利用して、テンポラリＩＤをＭＦＰ１０に送信するという一連の処理を実行することができない。即ち、このような一連の処理を携帯端末１５０に実行させるためには、携帯端末１５０に特別なアプリケーションをインストールしなければならない。ただし、本変形例では、携帯端末１５０（ＯＳ）は、上記の一連の処理を実行することができる。従って、携帯端末１５０に特別なアプリケーションをインストールしなくても、携帯端末１５０（ＯＳ）は、メッセージデータ２５８内の上記の所定部分からテンポラリＩＤを抽出し、ＮＦＣ通信を利用して、テンポラリＩＤをＭＦＰ１０に送信することができる。本変形例によると、リダイレクトコマンド２５４及びＧＥＴコマンド２５６の通信を省略することができる。なお、本変形例では、上記の所定部分にテンポラリＩＤ「xyz」が記述されているメッセージデータ２５８が、「第１の特定データ」の一例である。一般的に言うと、「第１の特定データ」は、対象データを含むデータであって、第１のウェブ画面を第１の端末装置に表示させるためのデータであればよい。

（変形例２）「対象データ」は、テンポラリＩＤに限られず、特定のサーバ（例えば仲介サーバ５０）から第１の端末装置（例えば携帯端末１５０）を介して通信装置（例えばＭＦＰ１０）に供給されるべきデータであれば、どのようなデータであってもよい。例えば、特定のサーバは、ユーザによって登録されるアドレス帳を格納するためのサーバであってもよい。この場合、「対象データ」は、例えば、上記のアドレス帳を示すデータであってもよい。また、例えば、特定のサーバは、通信装置が新たに利用すべき設定情報を格納するためのサーバであってもよい。この場合、「対象データ」は、例えば、上記の設定情報を示すデータであってもよい。設定情報の一例として、例えば、印刷解像度、印刷用紙のサイズ等を示す印刷設定情報、スキャン解像度、スキャンデータのファイル形式等を示すスキャン設定情報等を挙げることができる。

（変形例３）ＭＦＰ１０がサービス提供サーバ１００から受けるサービスは、データ供給サービスに限られない。例えば、図３のケースＡ１において、ＭＦＰ１０の処理実行部４２は、ファイル取得要求２９０を送信するのに代えて、原稿のスキャンをスキャン実行部２０に実行させて、スキャンデータを生成してもよい。そして、処理実行部４２は、スキャンデータとアクセストークン２３０とを含むファイル保存要求（例えばＨＴＴＰのＰＯＳＴコマンド）をサービス提供サーバ１００に送信してもよい。この場合、サービス提供サーバ１００は、アクセストークン２３０の認証が成功すると、スキャンデータを含むファイルをサービス提供サーバ１００のメモリ（図示省略）に格納する。即ち、サービス提供サーバ１００は、データ保存サービスを提供する。これにより、ＭＦＰ１０は、サービス提供サーバ１００からデータ保存サービスを受けて、スキャンＵＬ処理を実行することができる。換言すると、ユーザは、携帯端末１５０を用いて、ＭＦＰ１０にスキャンＵＬ処理を実行させることができる。本変形例では、アクセストークン要求２８０の送信処理及びスキャンＵＬ処理が、「特定の処理」の一例である。また、「特定の処理」は、他の処理（例えば、対象データを印刷する処理等）であってもよい。

（変形例４）「認証情報」は、アクセストークンに限られず、サービス提供サーバ１００，１１０が認証に利用する他の情報（例えば、ユーザＩＤ、パスワード等）であってもよい。

（変形例５）「第１種の無線通信」は、Ｗｉ−Ｆｉ通信（即ちＨＴＴＰ通信）に限られず、例えば、IMT2000（International Mobile Telecommunication 2000の略）の規格に準拠した３Ｇ等の無線通信であってもよい。また、ＨＴＴＰ通信に代えて、ウェブデータを通信するための他のプロトコル（例えばＨＴＴＰに準ずるＨＴＴＰＳ等）に従った通信が利用されてもよい。また、「第２種の無線通信」は、ＮＦＣ通信に限られず、例えば、赤外線通信、ＢｌｕｅＴｏｏｔｈ（登録商標）通信等であってもよい。

（変形例６）上記の各実施例では、「携帯端末をＭＦＰに近づけてください」というメッセージ３００ａを含むメッセージ画面２５８ａが、「第１のウェブ画面」の一例である。これに代えて、「第１のウェブ画面」は、「携帯端末にＮＦＣ通信を実行させてください」というメッセージを含んでいてもよい。即ち、「第１のウェブ画面」は、端末装置に第２種の無線通信を実行させることを示すメッセージを含んでいてもよい。より一般的に言うと、「第１のウェブ画面」は、第２種の無線通信を利用して通信装置に対象データを送信するための手法を示していればよい。

（変形例７）仲介サーバ５０は、別体に構成されている２個以上の機器によって構成されていてもよい。例えば、仲介サーバ５０は、図２のＧＥＴコマンド２１０を受信する場合に、サービスリストデータ２１２を送信する処理を実行するための第１の機器と、図３のＧＥＴコマンド２５２を受信して、Ｓ４０以降の処理を実行するための第２の機器と、によって構成されてもよい。一般的に言うと、「特定のサーバ」は、物理的に一個の機器によって構成されてもよいし、別体に構成されている２個以上の機器によって構成されてもよい。

（変形例８）上記の各実施例では、ＭＦＰ１０及び仲介サーバ５０のＣＰＵ３２，７２がソフトウェアに従って処理を実行することによって、各部４１〜４３，８１〜８８の機能が実現される。これに代えて、各部４１〜４３，８１〜８８の機能のうちの少なくとも一部は、論理回路等のハードウェアによって実現されてもよい。

２：通信システム、１０：ＭＦＰ、５０：仲介サーバ、１００，１００：サービス提供サーバ、１５０：携帯端末、１６０：ＰＣ、２１０，２１８，２５２，２５６：ＧＥＴコマンド、２１２：サービスリストデータ、２１２ａ：サービスリスト画面、２１４，２２２：ＰＯＳＴコマンド、２１６，２５０，２５４：リダイレクトコマンド、２２０：ログインデータ、２２０ａ：ログイン画面、２３０：アクセストークン、２５８：メッセージデータ、２５８ａ：メッセージ画面、２８０：アクセストークン要求、２９０：ファイル取得要求

Claims (9)

1. 特定のサーバであって、
   ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信部と、
   前記第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する準備部であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記第１の端末装置とは異なる通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータであるとともに、前記対象データを含む第１の位置情報であって、前記第１のウェブ画面を表わす第１のウェブデータの位置を示す前記第１の位置情報へのアクセスを指示する第１のアクセスコマンドである、前記準備部と、
   前記第１の特定データを前記第１の端末装置に送信する第１の送信部と、
   を備える特定のサーバ。
2. 特定のサーバであって、
   前記特定のサーバとは異なるサービス提供サーバから認証情報を取得する取得部であって、前記認証情報は、通信装置が前記サービス提供サーバからサービスを受けるための情報である、前記取得部と、
   前記サービス提供サーバから前記認証情報が取得される場合に、前記通信装置が前記認証情報を前記特定のサーバから取得するための対象データを生成して、前記認証情報と前記対象データとを対応付けてメモリに記憶させる生成部と、
   ウェブブラウザを備える第１の端末装置であって、前記通信装置とは異なる前記第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信部と、
   前記第１の送信要求が受信される場合に、前記対象データを含む第１の特定データを生成することによって、前記第１の特定データを準備する準備部であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータである、前記準備部と、
   前記第１の特定データを前記第１の端末装置に送信する第１の送信部と、
   を備える特定のサーバ。
3. 前記特定のサーバは、さらに、
   前記第１の特定データが前記第１の端末装置に送信された後に、前記通信装置から、前記対象データを含む特定の送信要求を受信する第２の受信部と、
   前記特定の送信要求が受信される場合に、前記特定の送信要求に含まれる前記対象データに対応付けられている前記認証情報を前記メモリから読み出して、前記認証情報を前記通信装置に送信する第２の送信部と、
   を備える、請求項２に記載の特定のサーバ。
4. 前記第１の送信要求は、前記第１の端末装置が、前記サービス提供サーバから、前記特定のサーバ内の位置を示す第２の位置情報へのアクセスを指示する第２のアクセスコマンドを受信する場合に、前記第２の位置情報を用いて、前記特定のサーバに送信する要求である、請求項２又は３に記載の特定のサーバ。
5. 特定のサーバであって、
   ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信部と、
   前記第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する準備部であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信と比べて無線通信可能な距離が短い近距離無線通信である第２種の無線通信を利用して、前記第１の端末装置とは異なる通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータであり、前記第１のウェブ画面は、前記第１の端末装置を前記通信装置に近づけることを示す第１のメッセージを含む、前記準備部と、
   前記第１の特定データを前記第１の端末装置に送信する第１の送信部と、
   を備える特定のサーバ。
6. 前記第１の送信要求は、さらに、前記第１の端末装置に搭載されているプログラムに関係する関係情報を含み、
   前記特定のサーバは、さらに、
   前記関係情報に基づいて、前記プログラムが前記第２種の無線通信をサポートするのか否かを判断する判断部を備え、
   前記準備部は、
   前記プログラムが前記第２種の無線通信をサポートすると判断される第１の場合に、前記第１のメッセージを含む前記第１のウェブ画面を、前記第１の端末装置に表示させるための前記第１の特定データを準備し、
   前記プログラムが前記第２種の無線通信をサポートしないと判断される第２の場合に、前記第１のメッセージを含まない第２のウェブ画面であって、前記通信装置を操作して前記対象データを前記通信装置に入力することを示す第２のメッセージを含む前記第２のウェブ画面を、前記第１の端末装置に表示させるための第２の特定データを準備し、
   前記第１の送信部は、
   前記第１の場合に、前記第１の特定データを前記第１の端末装置に送信し、
   前記第２の場合に、前記第２の特定データを前記第１の端末装置に送信する、請求項５に記載の特定のサーバ。
7. 前記第１の受信部は、
   前記第２種の無線通信をサポートする前記第１の端末装置が、前記特定のサーバ内の位置を示す第３の位置情報を用いて、前記第１の送信要求を前記特定のサーバに送信する場合に、前記第１の送信要求を受信し、
   前記第２種の無線通信をサポートしない第２の端末装置が、前記特定のサーバ内の位置を示す第４の位置情報であって、前記第３の位置情報とは異なる前記第４の位置情報を用いて、第２の送信要求を前記特定のサーバに送信する場合に、前記第２の送信要求を受信し、
   前記準備部は、さらに、前記第２の送信要求が受信される場合に、前記第１のメッセージを含まない第２のウェブ画面であって、前記通信装置を操作して前記対象データを前記通信装置に入力することを示す第２のメッセージを含む前記第２のウェブ画面を、前記第２の端末装置に表示させるための第２の特定データを準備し、
   前記第１の送信部は、さらに、前記第２の送信要求が受信される場合に、前記第２の特定データを前記第２の端末装置に送信する、請求項５に記載の特定のサーバ。
8. 通信装置であって、
   ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、特定のサーバから、対象データを含む第１の特定データを受信した結果として、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記対象データを含む第１の位置情報を前記通信装置に送信する場合に、前記第２種の無線通信を利用して、前記第１の位置情報を受信する受信部であって、前記第１の特定データは、前記第１の端末装置が、前記第２種の無線通信を利用して、前記通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータであるとともに、前記第１のウェブ画面を表わす第１のウェブデータの位置を示す前記第１の位置情報へのアクセスを指示する第１のアクセスコマンドである、前記受信部と、
   前記第１の位置情報から前記対象データを抽出する抽出部と、
   抽出済みの前記対象データを用いて、特定の処理を実行する処理実行部と、
   を備え、
   前記受信部は、前記第１の端末装置が、前記第１のアクセスコマンドに従って前記第１の位置情報にアクセスして、前記第１のウェブ画面を表示させた後に、前記第２種の無線通信を利用して、前記第１の位置情報を前記通信装置に送信する場合に、前記第２種の無線通信を利用して、前記第１の位置情報を受信する通信装置。
9. 特定のサーバのためのコンピュータプログラムであって、
   前記特定のサーバに搭載されるコンピュータに、以下の各処理、即ち、
   ウェブブラウザを備える第１の端末装置が、第１種の無線通信を利用して、第１の送信要求を送信する場合に、前記第１の送信要求を受信する第１の受信処理と、
   前記第１の送信要求が受信される場合に、対象データを含む第１の特定データを準備する準備処理であって、前記第１の特定データは、前記第１の端末装置が、前記第１種の無線通信とは異なる第２種の無線通信を利用して、前記第１の端末装置とは異なる通信装置に前記対象データを送信するための手法を示す第１のウェブ画面を、前記第１の端末装置に表示させるためのデータであるとともに、前記対象データを含む第１の位置情報であって、前記第１のウェブ画面を表わす第１のウェブデータの位置を示す前記第１の位置情報へのアクセスを指示する第１のアクセスコマンドである、前記準備処理と、
   前記第１の特定データを前記第１の端末装置に送信する第１の送信処理と、
   を実行させるコンピュータプログラム。

Images