(57)【特許請求の範囲】
【請求項１】
通信装置であって、
所定規格に従った無線通信を実行するための無線インターフェースと、
対象装置から、前記無線インターフェースを介して、１個以上の信号を受信する受信部と、
前記１個以上の信号に含まれる属性情報を利用して、前記対象装置が、第１種の装置であるのか、第２種の装置であるのか、を判断する第１の判断部と、
前記対象装置が前記第１種の装置であると判断される場合に、前記１個以上の信号に含まれる第１の識別情報を利用して、所定処理を実行する第１の処理実行部と、
前記対象装置が前記第２種の装置であると判断される場合に、前記対象装置が所定のアプリケーションソフトウェアに従って前記第１の識別情報とは異なる第２の識別情報を前記通信装置に送信可能であるのか否かを、前記１個以上の信号を利用して判断する第２の判断部と、
前記対象装置が前記第２の識別情報を送信可能であると判断される場合に、前記１個以上の信号に含まれる前記第２の識別情報を利用して、前記所定処理を実行する第２の処理実行部と、
前記対象装置が前記第２の識別情報を送信可能でないと判断される場合に、前記所定のアプリケーションソフトウェアをインストールするための位置情報を、前記無線インターフェースを介して、前記対象装置に送信する送信部と、
を備える通信装置。
【請求項２】
前記所定処理は、識別情報をメモリに登録するための処理と、前記対象装置を認証するための処理と、の少なくとも一方を含み、
前記所定のアプリケーションソフトウェアは、前記対象装置の認証を前記通信装置に実行させるためのアプリケーションソフトウェアである、請求項１に記載の通信装置。
【請求項３】
前記受信部は、前記１個以上の信号のうちの第１の信号であって、前記第１の識別情報と前記属性情報とを含む前記第１の信号を受信し、
前記第１の判断部は、前記対象装置から前記第１の信号が受信される場合に、前記第１の信号に含まれる前記属性情報を利用して、前記対象装置が、前記第１種の装置であるのか、前記第２種の装置であるのか、を判断し、
前記受信部は、前記対象装置が前記第２種の装置であると判断される場合に、前記１個以上の信号のうちの第２の信号であって、前記第１の信号とは異なる前記第２の信号を受信し、
前記第２の判断部は、前記対象装置から前記第２の信号が受信される場合に、前記第２の信号を利用して、前記対象装置が前記第２の識別情報を送信可能であるのか否かを判断し、
前記第２の処理実行部は、前記対象装置が前記第２の識別情報を送信可能であると判断される場合に、前記対象装置が所定のアプリケーションソフトウェアに従って送信する前記第２の識別情報であって、前記第２の信号に含まれる前記第２の識別情報を利用して、前記所定処理を実行する、請求項１又は２に記載の通信装置。
【請求項４】
前記受信部は、
第１の通信レイヤを利用して、前記第１の通信レイヤよりも上位である第２の通信レイヤを利用せずに、前記第１の信号を受信し、
前記第２の通信レイヤを利用して、前記第２の信号を受信する、請求項３に記載の通信装置。
【請求項５】
前記第２の信号は、前記対象装置が所定のフォーマットをサポートしているのか否かを示す第１の情報を含み、
前記第２の判断部は、
前記第１の情報が、前記対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記対象装置が前記第２の識別情報を送信可能であると判断し、
前記第１の情報が、前記対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記対象装置が前記第２の識別情報を送信可能でないと判断する、請求項３又は４に記載の通信装置。
【請求項６】
前記第２の信号は、前記対象装置が前記所定のアプリケーションソフトウェアを有するのか否かを示す第２の情報を含み、
前記第２の判断部は、
前記第２の情報が、前記対象装置が前記所定のアプリケーションソフトウェアを有することを示す場合に、前記対象装置が前記第２の識別情報を送信可能であると判断し、
前記第２の情報が、前記対象装置が前記所定のアプリケーションソフトウェアを有さないことを示す場合に、前記対象装置が前記第２の識別情報を送信可能でないと判断する、請求項３から５のいずれか一項に記載の通信装置。
【請求項７】
前記属性情報は、前記対象装置が前記所定規格に準拠した特定規格に従った装置であるのか否かを示す第３の情報を含み、
前記第１の判断部は、
前記第３の情報が、前記対象装置が前記特定規格に従った装置でないことを示す場合に、前記対象装置が前記第１種の装置であると判断し、
前記第３の情報が、前記対象装置が前記特定規格に従った装置であることを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項１から６のいずれか一項に記載の通信装置。
【請求項８】
前記受信部は、前記所定規格で定められている第１の通信モードを利用して、前記対象装置から前記１個以上の信号を受信し、
前記通信装置は、さらに、
前記対象装置が前記第２の識別情報を送信可能でないと判断される場合に、前記無線インターフェースのモード状態を、前記第１の通信モードとは異なる第２の通信モードであって、前記所定規格で定められている前記第２の通信モードが無効化されている第１のモード状態から、前記第２の通信モードが有効化されている第２のモード状態に変更するモード制御部を備え、
前記送信部は、前記無線インターフェースの前記モード状態が前記第１のモード状態から前記第２のモード状態に変更された後に、前記第２の通信モードを利用して、前記位置情報を前記対象装置に送信する、請求項１から７のいずれか一項に記載の通信装置。
【請求項９】
前記通信装置は、さらに、
前記対象装置が前記第２の識別情報を送信可能でないと判断される場合に、前記無線インターフェースの電波状態を、電波を利用可能な可能状態から、電波を利用不可能な不可能状態に変更する電波制御部を備え、
前記モード制御部は、前記無線インターフェースの前記電波状態が前記可能状態から前記不可能状態に変更された後に、前記無線インターフェースの前記モード状態を前記第１のモード状態から前記第２のモード状態に変更し、
前記電波制御部は、さらに、前記無線インターフェースの前記モード状態が前記第１のモード状態から前記第２のモード状態に変更された後に、前記無線インターフェースの前記電波状態を前記不可能状態から前記可能状態に変更する、請求項８に記載の通信装置。
【請求項１０】
前記送信部は、前記無線インターフェースの前記モード状態が前記第１のモード状態から前記第２のモード状態に変更された後に所定時間が経過するまでに、前記第２の通信モードに対応する無線リンクが前記無線インターフェースと前記対象装置との間に確立される場合に、前記無線インターフェースを介して、前記位置情報を前記対象装置に送信し、
前記モード制御部は、さらに、前記無線インターフェースの前記モード状態が前記第１のモード状態から前記第２のモード状態に変更されてから、前記無線リンクが確立されることなく、前記所定時間が経過する場合に、前記無線インターフェースの前記モード状態を前記第２のモード状態から前記第１のモード状態に変更する、請求項８又は９に記載の通信装置。
【請求項１１】
前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格であり、
前記第１の通信モードは、前記ＮＦＣ規格で定められているＲ／Ｗ（Reader/Writerの略）モードであり、
前記第２の通信モードは、前記ＮＦＣ規格で定められているＰ２Ｐ（Peer to Peerの略）モード及びＣＥ（Card Emulationの略）モードのいずれか一方のモードである、請求項８から１０のいずれか一項に記載の通信装置。
【請求項１２】
前記モード制御部は、さらに、
前記通信装置の動作状態が第１の動作状態である場合に、前記無線インターフェースの前記モード状態を、少なくとも前記Ｐ２Ｐモードが有効化されている第３のモード状態に設定し、
前記通信装置の前記動作状態が前記第１の動作状態から第２の動作状態に変更される場合に、前記無線インターフェースの前記モード状態を、前記第３のモード状態から、前記Ｐ２Ｐモード及び前記ＣＥモードが無効化されていると共に、前記Ｒ／Ｗ（Reader/Writerの略）モードが有効化されている前記第１のモード状態に変更する、請求項１１に記載の通信装置。
【請求項１３】
前記モード制御部は、前記１個以上の信号を受信するための通信タイプが第１の通信タイプであり、かつ、前記対象装置が前記第２の識別情報を送信可能でないと判断される特定の場合に、前記無線インターフェースが、前記第１の通信タイプに対応するポーリングを実行せずに、前記第１の通信タイプとは異なる第２の通信タイプに対応するポーリングを実行するように、前記無線インターフェースの前記モード状態を前記第１のモード状態から前記第２のモード状態に変更する、請求項８から１２のいずれか一項に記載の通信装置。
【請求項１４】
前記１個以上の信号は、前記対象装置が前記無線インターフェースを介した双方向通信を実行可能であるのか否かを示す第４の情報を含み、
前記モード制御部は、
前記特定の場合において、前記第４の情報が、前記対象装置が前記双方向通信を実行不可能であることを示す場合に、前記無線インターフェースが、前記第１の通信タイプに対応する前記ポーリングを実行せずに、前記第２の通信タイプに対応する前記ポーリングを実行するように、前記無線インターフェースの前記モード状態を前記第１のモード状態から前記第２のモード状態に変更し、
前記特定の場合において、前記第４の情報が、前記対象装置が前記双方向通信を実行可能であることを示す場合に、前記無線インターフェースが、前記第１の通信タイプ及び前記第２の通信タイプを含む複数個の通信タイプのそれぞれに対応するポーリングを実行するように、前記無線インターフェースの前記モード状態を前記第１のモード状態から前記第２のモード状態に変更する、請求項１３に記載の通信装置。
【請求項１５】
前記モード制御部は、前記１個以上の信号を受信するための通信タイプが前記第２の通信タイプであり、かつ、前記対象装置が前記第２の識別情報を送信可能でないと判断される場合に、前記無線インターフェースが、前記第２の通信タイプに対応する前記ポーリングを実行せずに、前記第１の通信タイプに対応する前記ポーリングを実行するように、前記無線インターフェースの前記モード状態を前記第１のモード状態から前記第２のモード状態に変更する、請求項１３又は１４に記載の通信装置。
【請求項１６】
通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、以下の各処理、即ち、
対象装置から、所定規格に従った無線通信を実行するための無線インターフェースを介して、１個以上の信号を受信する受信処理と、
前記１個以上の信号に含まれる属性情報を利用して、前記対象装置が、第１種の装置であるのか、第２種の装置であるのか、を判断する第１の判断処理と、
前記対象装置が前記第１種の装置であると判断される場合に、前記１個以上の信号に含まれる第１の識別情報を利用した所定処理と、
前記対象装置が前記第２種の装置であると判断される場合に、前記対象装置が所定のアプリケーションソフトウェアに従って前記第１の識別情報とは異なる第２の識別情報を前記通信装置に送信可能であるのか否かを、前記１個以上の信号を利用して判断する第２の判断処理と、
前記対象装置が前記第２の識別情報を送信可能であると判断される場合に、前記１個以上の信号に含まれる前記第２の識別情報を利用した前記所定処理と、
前記対象装置が前記第２の識別情報を送信可能でないと判断される場合に、前記所定のアプリケーションソフトウェアをインストールするための位置情報を、前記無線インターフェースを介して、前記対象装置に送信する送信処理と、
を実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書では、対象装置から受信される識別情報を利用した処理を実行可能な通信装置を開示する。
【背景技術】
【０００２】
特許文献１には、端末とサービス提供装置と認証装置とを備えるシステムが開示されている。端末は、非接触ＩＣカードリーダを用いて、非接触ＩＣカード又は携帯電話機からチップＩＤを読取り、当該チップＩＤをサービス提供装置に送信する。サービス提供装置は、チップＩＤを含む資格認証要求を認証装置に送信する。認証装置は、チップＩＤの認証を実行して、顧客の資格の有無を示す資格認証情報をサービス提供装置に送信する。サービス提供装置は、資格認証情報に応じて端末を動作させる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１９８５０５号公報
【特許文献２】特開２０１５−０６９４５８号公報
【特許文献３】米国特許出願公開２０１４／１６８６８７号公報
【特許文献４】米国特許出願公開２０１５／０２９５３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、スマートフォンなどの携帯端末のＯＳ（Operation Systemの略）は、非接触の無線通信を実行する毎にランダムな文字列を生成して、当該文字列をチップＩＤとして利用し得る。この場合、当該チップＩＤは、無線通信毎に変更されてしまうので、認証には適していない。また、例えば、携帯端末のＯＳは、予め決められている文字列をチップＩＤとして利用し得る。この場合、同じＯＳを有する複数個の携帯端末の間でチップＩＤが共通になってしまい、当該チップＩＤは、携帯端末毎のユニークさを保証しないので、認証に適していない。
【０００５】
本明細書では、通信装置が、対象装置の種類に応じた識別情報を利用した処理を適切に実行し得る技術を開示する。
【課題を解決するための手段】
【０００６】
本明細書によって開示される通信装置は、所定規格に従った無線通信を実行するための無線インターフェースと、対象装置から、無線インターフェースを介して、１個以上の信号を受信する受信部と、１個以上の信号に含まれる属性情報を利用して、対象装置が、第１種の装置であるのか、第２種の装置であるのか、を判断する第１の判断部と、対象装置が第１種の装置であると判断される場合に、１個以上の信号に含まれる第１の識別情報を利用して、所定処理を実行する第１の処理実行部と、対象装置が第２種の装置であると判断される場合に、対象装置が所定のアプリケーションソフトウェアに従って第１の識別情報とは異なる第２の識別情報を通信装置に送信可能であるのか否かを、１個以上の信号を利用して判断する第２の判断部と、対象装置が第２の識別情報を送信可能であると判断される場合に、１個以上の信号に含まれる第２の識別情報を利用して、所定処理を実行する第２の処理実行部と、対象装置が第２の識別情報を送信可能でないと判断される場合に、所定のアプリケーションソフトウェアをインストールするための位置情報を、無線インターフェースを介して、対象装置に送信する送信部と、を備える。
【０００７】
上記の構成によると、通信装置は、対象装置が第１種の装置であると判断する場合に、第１の識別情報を利用して所定処理を実行する。また、通信装置は、対象装置が２種の装置であると判断する場合に、対象装置が第２の識別情報を送信可能であるか否かを判断し、対象装置が第２の識別情報を送信可能と判断する場合に、第２の識別情報を利用して所定処理を実行する。従って、通信装置は、例えば、ランダムに生成される第１の識別情報、又は、複数の通信装置の間で共通に利用される可能性がある第１の識別情報を利用した所定処理を実行しないので、第２の識別情報を利用して、所定処理を適切に実行し得る。このように、通信装置は、対象装置の種類に応じた識別情報を利用した所定処理を適切に実行し得る。特に、通信装置は、対象装置が第２の識別情報を送信可能でないと判断する場合に、所定のアプリケーションソフトウェアをインストールするための位置情報を対象装置に送信する。この結果、例えば、ユーザが位置情報を対象装置に入力しなくても、対象装置は、通信装置から受信される位置情報を利用して、所定のアプリケーションソフトウェアをインストールし得る。このために、ユーザの利便性を向上させ得る。
【０００８】
上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。また、上記の通信装置と対象装置とを備える通信システムも、新規で有用である。
【図面の簡単な説明】
【０００９】
【図１】通信システムの構成を示す。
【図２】認証フラグＯＦＦ時処理のフローチャートを示す。
【図３】認証フラグＯＮ時処理のフローチャートを示す。
【図４】タイプＡに対応するＩＤ抽出処理のフローチャートを示す。
【図５】タイプＦに対応するＩＤ抽出処理のフローチャートを示す。
【図６】ＵＲＬ供給処理のフローチャートを示す。
【図７】タイプＡに対応する認証カードを認証するケースのシーケンス図を示す。
【図８】タイプＡに対応する携帯端末を認証するケースのシーケンス図を示す。
【図９】タイプＦに対応する認証カード及び携帯端末を認証するケースのシーケンス図を示す。
【図１０】ＵＲＬを携帯端末に供給するケースのシーケンス図を示す。
【図１１】第２実施例のＵＲＬ供給処理のフローチャートを示す。
【図１２】第２実施例のシーケンス図を示す。
【発明を実施するための形態】
【００１０】
（第１実施例）
（通信システム２の構成；図１）
図１に示すように、通信システム２は、多機能機１０（以下では「ＭＦＰ（Multi-Function Peripheralの略）」と呼ぶ）と、認証カード５０と、携帯端末７０と、を備える。各装置１０、５０、７０は、ＮＦＣ（Near Field Communicationの略）方式に従った無線通信（以下では「ＮＦＣ通信」と呼ぶ）を実行可能である。
【００１１】
（ＭＦＰ１０の構成）
ＭＦＰ１０は、操作部１２と、表示部１４と、印刷実行部１６と、スキャン実行部１８と、Ｗｉ−Ｆｉインターフェース（以下ではインターフェースを「Ｉ／Ｆ」と記載する）２０と、ＮＦＣＩ／Ｆ２２と、制御部３０と、を備える。
【００１２】
操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示をＭＦＰ１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。表示部１４は、いわゆるタッチパネルとしても機能する。即ち、表示部１４は、操作部としても機能する。印刷実行部１６は、インクジェット方式、レーザ方式等の印刷機構である。スキャン実行部１８は、ＣＣＤ、ＣＩＳ等のスキャン機構である。
【００１３】
Ｗｉ−ＦｉＩ／Ｆ２０は、Ｗｉ−Ｆｉ方式に従った無線通信（以下では「Ｗｉ−Ｆｉ通信」と呼ぶ）を実行するためのＩ／Ｆである。Ｗｉ−Ｆｉ方式は、例えば、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers、 Inc.の略）の８０２．１１の規格、及び、それに準ずる規格（例えば、８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ等）に基づく無線通信方式である。より具体的に言うと、Ｗｉ−ＦｉＩ／Ｆ２０は、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅによって策定されたＷＦＤ（Wi-Fi Direct（登録商標）の略）方式をサポートしている。ＷＦＤ方式は、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅによって作成された規格書「Wi-Fi Peer-to-Peer (P2P) Technical Specification Version1.1」に記述されている無線通信方式である。
【００１４】
ＮＦＣＩ／Ｆ２２は、ＮＦＣ通信を実行するためのＩ／Ｆである。ＮＦＣ方式は、例えば、ISO/IEC14443、15693、18092などの国際標準規格に基づく無線通信方式である。なお、ＮＦＣ通信を実行するためのＩ／Ｆの種類として、ＮＦＣフォーラムデバイス（NFC Forum Device）と呼ばれるＩ／Ｆと、ＮＦＣタグ（NFC Tag）と呼ばれるＩ／Ｆと、が知られている。ＮＦＣフォーラムデバイスは、Ｐ２Ｐ（Peer To Peerの略）モード、Ｒ／Ｗ（Reader/Writerの略）モード、及び、ＣＥ（Card Emulationの略）モードのいずれかで選択的に動作可能なＩ／Ｆである。ＮＦＣタグは、これらのモードのいずれかで選択的に動作可能なＩ／Ｆではなく、ＮＦＣ方式のＩＣ（Integrated Circuitの略）タグとして機能する。
【００１５】
Ｐ２Ｐモードは、Ｐ２Ｐモードで動作する一方のＮＦＣ機器とＰ２Ｐモードで動作する他方のＮＦＣ機器との間で双方向通信を実行するためのモードである。Ｒ／Ｗモード及びＣＥモードは、Ｒ／Ｗモードで動作する一方のＮＦＣ機器とＣＥモードで動作する他方のＮＦＣ機器との間で単方向通信を実行するためのモードである。なお、ＣＥモードは、セキュア・エレメントを必要とする通常のＣＥモードと、セキュア・エレメントを必要としないＨＣＥ（Host Card Emulationの略）モードと、を含む。Ｒ／ＷモードのうちのＲｅａｄｅｒモードは、ＣＥモードで動作するＮＦＣ機器からデータを読み出すためのモードである。Ｒ／ＷモードのうちのＷｒｉｔｅｒモードは、ＣＥモードで動作するＮＦＣ機器にデータを書き込むためのモードである。なお、Ｒ／Ｗモードで動作するＮＦＣ機器は、ＮＦＣタグからデータを読み出したり、ＮＦＣタグにデータを書き込んだりすることもできる。
【００１６】
ＮＦＣＩ／Ｆ２２は、ＮＦＣフォーラムデバイスである。ＮＦＣＩ／Ｆ２２は、例えば、Ｐｏｌｌｉｎｇ信号を送信して、相手機器から当該信号に対する応答信号を受信する場合に、相手機器とのＮＦＣ通信リンクを確立する。また、ＮＦＣＩ／Ｆ２２は、例えば、相手機器からＰｏｌｌｉｎｇ信号を受信して、当該信号に対する応答信号を相手機器に送信する場合に、相手機器とのＮＦＣ通信リンクを確立する。
【００１７】
ここで、ＮＦＣ通信について詳しく説明する。ＮＦＣ通信は、４種類の通信タイプ（即ち、タイプＡ、タイプＢ、タイプＦ、及び、タイプＶ）に分類される。各通信タイプでは、同じ周波数（即ち１３．５６ＭＨｚ）が利用される。ただし、各通信タイプでは、通信規格、変調方式、及び、符号化方式の組合せが異なる。タイプＡは、通信規格「ISO/IEC14443及び18092」、変調方式「ＡＳＫ（Amplitude Shift Keyingの略）１００％」、及び、符号化方式「Manchester」に従った通信である。タイプＢは、通信規格「ISO/IEC14443」、変調方式「ＡＳＫ１０％」、符号化方式「ＮＲＺ（Non Return to Zeroの略）」に従った通信である。タイプＦは、通信規格「ISO/IEC18092」、変調方式「ＡＳＫ１０％」、及び、符号化方式「Manchester」に従った通信である。タイプＶは、通信規格「ISO/IEC15693」、変調方式「ＡＳＫ１０％又は１００％」、符号化方式「Manchester」に従った通信である。
【００１８】
次いで、Ｗｉ−ＦｉＩ／Ｆ２０とＮＦＣＩ／Ｆ２２との間の相違点を説明しておく。Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信の通信速度（例えば最大の通信速度が１１〜６００Ｍｂｐｓ）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信の通信速度（例えば最大の通信速度が１００〜４２４Ｋｂｐｓ）よりも速い。また、Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信における搬送波の周波数（例えば２．４ＧＨｚ帯又は５．０ＧＨｚ帯）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信における搬送波の周波数（例えば１３．５６ＭＨｚ帯）とは異なる。また、Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信を実行可能な最大の距離（例えば最大で約１００ｍ）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信を実行可能な最大の距離（例えば最大で約１０ｃｍ）よりも大きい。
【００１９】
制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に格納されているプログラム３６に従って、様々な処理を実行する。メモリ３４は、揮発性メモリ、不揮発性メモリ等によって構成される。また、メモリ３４は、認証フラグ３８、ＵＲＬ（Uniform Resource Locatorの略）３９、及び、ユーザテーブル４０を格納する。認証フラグ３８は、ユーザ情報を利用した認証を実行することを意味する「ＯＮ」と、当該認証を実行しないことを意味する「ＯＦＦ」と、のどちらかの値を示す。認証フラグ３８は、ＭＦＰ１０の管理者によって「ＯＮ」又は「ＯＦＦ」に設定される。ＵＲＬ３９は、携帯端末７０にインストールされるべき認証アプリケーション７８のインターネット上の位置情報を示す。
【００２０】
ユーザテーブル４０では、ユーザ名と、パスワードと、認証ＩＤと、印刷許可情報と、スキャン許可情報と、が対応付けられる。ユーザ名、パスワード、印刷許可情報、及び、スキャン許可情報は、例えば、ＭＦＰ１０の管理者が、操作部１２を操作することによって、又は、端末装置からＭＦＰ１０にアクセスすることによって、ユーザテーブル４０に登録される。印刷許可情報、スキャン許可情報は、それぞれ、印刷機能、スキャン機能をユーザに許可するのか否かを示す。各許可情報の「ＯＫ」は、機能の利用を許可することを示し、「ＮＧ」は、機能の利用を許可しないことを示す。認証ＩＤは、認証カード５０又は携帯端末７０を識別するための識別情報であり、後述する処理によって認証カード５０又は携帯端末７０から抽出されて登録される。ここで、認証ＩＤを一例として含む「識別情報」という用語は、１個の装置に固有（即ちユニーク）な情報であってもよいし、装置内の構成要素（例えばソフトウェア）を識別する情報であってもよいし、装置のモデルを示す情報であってもよい。即ち、識別情報は、１個の装置そのものを識別する情報に限定されず、ある概念を識別する情報も含む。なお、変形例では、ユーザテーブル４０は、ＭＦＰ１０とは異なる外部装置のメモリ内に格納されてもよい。この場合、ＭＦＰ１０は、当該外部装置と通信して、ユーザテーブル４０内の情報を利用することができる。
【００２１】
（認証カード５０の構成）
認証カード５０は、ＮＦＣタグであるＮＦＣＩ／Ｆ５２を備える。認証カード５０は、通常、ＯＳソフトウェア及びアプリケーションを有さない。ＮＦＣＩ／Ｆ５２は、タイプＡ、Ｂ、Ｆ、及び、Ｖのいずれか１つのタイプに対応する（換言すると、１つのタイプのみをサポートしている）。タイプＡに対応するＮＦＣＩ／Ｆ５２は、通信規格「ISO/IEC14443」に従ったＩ／Ｆ（即ちカード）であり、さらに、通信規格「ISO/IEC14443」に準拠した特定規格「ISO/IEC14443-4」に従ったＩ／Ｆと、特定規格「ISO/IEC14443-4」に従っていないＩ／Ｆと、に分類される。前者のＩ／Ｆは、非接触カード用の特定の通信プロトコル「Ｔ−ＣＬ」に準拠しているMifare Desfire系のカードであり、例えば、Mifare ProX、Mifare SmartMX、Mifare Desfire等を含む。また、後者のＩ／Ｆは、通信プロトコル「Ｔ−ＣＬ」に準拠していないMifare（登録商標）系のカードであり、例えば、Mifare Ultralight、Mifare Mini等を含む。タイプＦに対応するＮＦＣＩ／Ｆ５２は、通信規格「ISO/IEC18092」に従ったカードであり、例えば、FeliCa Standard、FeliCa Liteなどのカードである。また、タイプＶに対応するＮＦＣＩ／Ｆ５２は、通信規格「ISO/IEC15693」に従ったカードである。
【００２２】
（携帯端末７０の構成）
携帯端末７０は、例えば、携帯電話、スマートフォン、ＰＤＡ、ノートＰＣ、タブレットＰＣ、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末装置である。携帯端末７０は、ＮＦＣＩ／Ｆ７２と、ＯＳソフトウェア７４と、を備える。ＮＦＣＩ／Ｆ７２は、ＮＦＣフォーラムデバイスである。ＯＳソフトウェア７４は、携帯端末７０の種々の基本的な動作を制御するためのソフトウェアである。また、図示省略しているが、携帯端末７０は、さらに、Ｗｉ−Ｆｉ通信を実行するためのＷｉ−ＦｉＩ／Ｆも備える。
【００２３】
携帯端末７０は、さらに、印刷アプリケーション７６と、認証アプリケーション７８と、を有し得る。印刷アプリケーション７６は、ＭＦＰ１０に印刷機能を実行させるためのアプリケーションである。認証アプリケーション７８は、携帯端末７０を利用して、ＭＦＰ１０に認証を実行させるためのアプリケーションである。各アプリケーション７６、７８は、ＭＦＰ１０のベンダによって提供されるアプリケーションであり、例えば、インターネット上のサーバから携帯端末７０にインストールされる。
【００２４】
（認証フラグＯＦＦ時処理；図２）
続いて、図２を参照して、認証フラグ３８が「ＯＦＦ」に設定されている場合に、ＣＰＵ３２によって実行される処理について説明する。ＭＦＰ１０の電源がＯＮされた際、又は、認証フラグ３８を「ＯＮ」から「ＯＦＦ」に変更するための操作が操作部１２に実行された際に、図２の処理が開始される。
【００２５】
Ｓ１０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード、Ｒ／Ｗモード、及び、ＣＥモードの全てがＯＮされているモード状態に設定する。この場合、ＮＦＣＩ／Ｆ２２は、上記の３つのモードのいずれでも動作可能である。なお、変形例では、Ｓ１０において、ＣＰＵ３２は、Ｐ２ＰモードのみがＯＮされているモード状態に設定してもよいし、Ｐ２ＰモードとＲ／Ｗモード又はＣＥモードとがＯＮされているモード状態に設定してもよい。即ち、ＣＰＵ３２は、少なくともＰ２ＰモードがＯＮされているモード状態に設定すればよい。
【００２６】
Ｓ１０において、ＣＰＵ３２は、さらに、タイプＡ、Ｂ、Ｆ、及び、Ｖに対応する４種類のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。この結果、ＮＦＣＩ／Ｆ２２は、各タイプに対応する各Ｐｏｌｌｉｎｇ信号を順次送信することを繰り返す。
【００２７】
Ｓ１２において、ＣＰＵ３２は、携帯端末７０とのＰ２Ｐ通信リンクが確立されることを監視する。ユーザが、Ｐ２ＰモードがＯＮされているＮＦＣＩ／Ｆ７２を備える携帯端末７０をＭＦＰ１０に近づける。この場合、携帯端末７０とＭＦＰ１０との間の距離が、ＮＦＣ通信を実行可能な最大の距離（例えば１０ｃｍ）よりも小さくなり、この結果、Ｐ２Ｐ通信リンクが確立される。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２からＰ２Ｐ通信リンクが確立されたことを示す情報を取得する場合に、Ｓ１２でＹＥＳと判断して、Ｓ１４に進む。
【００２８】
Ｓ１４において、ＣＰＵ３２は、ＭＦＰ１０の動作状態を、ＷＦＤ方式のデバイス状態から、ＷＦＤ方式のＧｒｏｕｐ  Ｏｗｎｅｒ状態（以下では「Ｇ／Ｏ状態」と呼ぶ）に移行させる。デバイス状態は、ＷＦＤ方式に従った無線ネットワークの親局及び子局のどちらでも動作しない状態である。Ｇ／Ｏ状態は、当該無線ネットワークの親局として動作する状態である。なお、変形例では、ＣＰＵ３２は、ＷＦＤ方式のＧ／Ｏ状態に移行する代わりに、いわゆるＳｏｆｔＡＰ（Access Pointの略）を起動して、無線ネットワークの親局として動作してもよい。Ｓ１４において、ＣＰＵ３２は、さらに、当該無線ネットワークで利用されるべき無線設定（即ちＳＳＩＤ及びパスワード）を決定する。ＳＳＩＤは、当該無線ネットワークを識別するための識別子である。パスワードは、当該無線ネットワークにおいて認証及び暗号化に利用される文字列である。ＣＰＵ３２は、例えば、予め決められている文字列を取得することによって、又は、ランダムに文字列を抽出することによって、無線設定を決定する。
【００２９】
Ｓ１６において、ＣＰＵ３２は、Ｓ１４で決定された無線設定をＮＦＣＩ／Ｆ２２に供給する。この結果、ＮＦＣＩ／Ｆ２２は、Ｐ２Ｐ通信リンクを介して、無線設定を携帯端末７０に送信する。これにより、携帯端末７０が無線設定を受信し、携帯端末７０が印刷アプリケーション７６を備えている場合には、携帯端末７０において無線設定が利用される。そして、Ｗｉ−Ｆｉ方式に従ったＷｉ−Ｆｉ接続を確立するための様々な信号が、携帯端末７０からＭＦＰ１０に送信される。
【００３０】
Ｓ１８において、ＣＰＵ３２は、Ｗｉ−ＦｉＩ／Ｆ２０を介して、携帯端末７０とのＷｉ−Ｆｉ接続を確立する。具体的には、ＣＰＵ３２は、上記のＳＳＩＤを含む信号、パスワードを含む信号等を受信し、パスワードの認証が成功すると、Ｗｉ−Ｆｉ接続を確立する。
【００３１】
Ｓ２０において、ＣＰＵ３２は、Ｓ１８で確立されたＷｉ−Ｆｉ接続を利用して、Ｗｉ−ＦｉＩ／Ｆ２０を介して、携帯端末７０から印刷対象の画像を表わす印刷データを受信する。上述のように、Ｗｉ−Ｆｉ通信の通信速度は、ＮＦＣ通信の通信速度よりも速い。このために、ＮＦＣ通信を利用して印刷データを通信する構成と比べると、ＭＦＰ１０は、携帯端末７０から印刷データを迅速に受信することができる。
【００３２】
Ｓ２２において、ＣＰＵ３２は、Ｓ２０で受信された印刷データを印刷実行部１６に供給して、印刷実行部１６に印刷を実行させる。なお、変形例では、ＣＰＵ３２は、Ｓ２０及びＳ２２に代えて、スキャン実行部１８に原稿のスキャンを実行させ、Ｗｉ−Ｆｉ接続を利用して、Ｗｉ−ＦｉＩ／Ｆ２０を介して、スキャンデータを携帯端末７０に送信してもよい。このように、認証フラグ３８が「ＯＦＦ」に設定されている状況では、ＭＦＰ１０は、ユーザ情報の認証を実行することなく、いずれのユーザから指示を受けても、印刷機能及びスキャン機能を実行する（Ｓ２０、Ｓ２２）。
【００３３】
Ｓ２４において、ＣＰＵ３２は、Ｓ１８で確立されたＷｉ−Ｆｉ接続を切断し、さらに、ＭＦＰ１０の動作状態をＧ／Ｏ状態からデバイス状態に移行させる。Ｓ２４が終了すると、Ｓ１２に戻る。
【００３４】
（認証フラグＯＮ時処理；図３）
続いて、図３を参照して、認証フラグ３８が「ＯＮ」に設定されている場合に、ＣＰＵ３２によって実行される処理について説明する。認証フラグ３８を「ＯＦＦ」から「ＯＮ」に変更するための操作が操作部１２に実行された際に、図３の処理が開始される。なお、以下では、認証カード５０及び携帯端末７０を総称して、「対象装置」と呼ぶ場合がある。
【００３５】
Ｓ１００において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＣＥモードがＯＦＦされていると共にＲ／ＷモードがＯＮされているモード状態に設定する。この場合、ＮＦＣＩ／Ｆ２２は、上記の３つのモードのうちのＲ／Ｗモードのみで動作可能である。認証フラグ３８が「ＯＮ」に設定されている状況では、対象装置のＩＤの登録又は認証が実行される。ここで、対象装置が認証カード５０である場合には、認証カード５０（即ちＮＦＣタグであるＮＦＣＩ／Ｆ５２）からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモード（より詳しくはＲｅａｄｅｒモード）で動作する必要がある。また、携帯端末７０は、認証アプリケーション７８に従って、ＮＦＣ通信を利用して、ＩＤを送信可能である。ここで、認証アプリケーション７８は、ＮＦＣＩ／Ｆ７２がＣＥモードで動作する状態でＩＤを送信するようにプログラムされている。従って、対象装置が携帯端末７０である場合にも、携帯端末７０（即ちＮＦＣフォーラムデバイスであるＮＦＣＩ／Ｆ７２）からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモード（より詳しくはＲｅａｄｅｒモード）で動作する必要がある。このように、対象装置からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモードで動作する必要があるので、Ｓ１００において、ＮＦＣＩ／Ｆ２２がＲ／Ｗモードのみで動作可能なモード状態に設定される。
【００３６】
Ｓ１００において、ＣＰＵ３２は、さらに、タイプＡ、Ｂ、Ｆ、及び、Ｖに対応する４種類のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。この結果、ＮＦＣＩ／Ｆ２２は、各タイプに対応する各Ｐｏｌｌｉｎｇ信号を順次送信することを繰り返す。
【００３７】
Ｓ１１０において、ＣＰＵ３２は、ユーザによってログイン操作が操作部１２に実行されることを監視する。ＣＰＵ３２は、ユーザテーブル４０に登録されているユーザ名及びパスワードの組合せが操作部１２に入力される場合に、Ｓ１１０でＹＥＳと判断して、Ｓ１２０に進む。
【００３８】
Ｓ１２０において、ＣＰＵ３２は、認証ＩＤをユーザテーブル４０に登録するための登録ボタンが操作されたのか否かを判断する。ＣＰＵ３２は、登録ボタンが操作されたと判断する場合（Ｓ１２０でＹＥＳ）に、Ｓ１３０に進む。一方、ＣＰＵ３２は、登録ボタンとは異なるボタンが操作されたと判断する場合（Ｓ１２０でＮＯ）に、Ｓ１２２において、当該ボタンに対応する処理を実行する。例えば、ＣＰＵ３２は、外部サーバから印刷データを受信して印刷を実行するためのボタンが操作される場合には、Ｓ１１０で入力されたユーザ情報（即ちユーザ名及びパスワード）に対応する印刷許可情報が「ＯＫ」であるのか否かを判断する。そして、ＣＰＵ３２は、「ＯＫ」であると判断する場合には、印刷データを受信して、当該印刷データを印刷実行部１６に供給する。また、例えば、ＣＰＵ３２は、スキャンを実行するためのボタンが操作される場合には、Ｓ１１０で入力されたユーザ情報に対応するスキャン許可情報が「ＯＫ」であるのか否かを判断する。そして、ＣＰＵ３２は、「ＯＫ」であると判断する場合には、スキャン実行部１８にスキャンを実行させる。Ｓ１２２が終了すると、Ｓ１１０に戻る。なお、変形例では、ＣＰＵ３２は、Ｓ１２２が終了した後に、ログイン操作が再び実行されなくても、Ｓ１２２の処理を実行するための操作を受け付けてもよい。この状態は、ユーザによってログアウト操作が実行されるまで継続されてもよい。
【００３９】
Ｓ１３０において、ＣＰＵ３２は、対象装置から、ＮＦＣＩ／Ｆ２２を介して、Ｐｏｌｌｉｎｇ信号に対する応答信号を受信することを監視する。上述のように、ＮＦＣＩ／Ｆ２２は、各タイプに対応する各Ｐｏｌｌｉｎｇ信号を順次送信することを繰り返す。ＮＦＣＩ／Ｆ２２は、例えば、タイプＡに対応するＰｏｌｌｉｎｇ信号を送信した際に、当該信号に対する応答信号を受信する場合に、タイプＡを示す情報を制御部３０に供給する。同様に、ＮＦＣＩ／Ｆ２２は、他の通信タイプに対応する応答信号を受信する場合に、当該タイプを示す情報を制御部３０に供給する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から上記の情報を取得する場合に、Ｓ１３０でＹＥＳと判断して、Ｓ１３２に進む。
【００４０】
Ｓ１３２において、ＣＰＵ３２は、Ｓ１３０で取得された情報に基づいて、応答信号を受信するための通信タイプを特定する。そして、Ｓ１３４において、ＣＰＵ３２は、特定済みの通信タイプに応じたＩＤ抽出処理（図４及び図５参照）を実行する。ＮＦＣＩ／Ｆ２２がＲ／Ｗモードのみで動作しているので、ＣＰＵ３２は、Ｒｅａｄｅｒとして機能することができ、この結果、対象装置から信号を受信して、当該信号内のＩＤを読み出す（即ち抽出する）ことができる。
【００４１】
後で詳しく説明するが、Ｐｏｌｌｉｎｇ信号に応じて、対象装置から様々な信号が受信される。ＮＦＣ規格の通信レイヤのうちの比較的に下位層のみが利用される信号（例えば後述のＳＤＤ信号、ＳＥＮＳＦ信号等）は、通信タイプに応じたＩＤを含む。通信タイプＡ、Ｂ、Ｆ、Ｖに対応するＩＤは、それぞれ、「ＮＦＣＩＤ１」、「ＮＦＣＩＤ０」、「ＮＦＣＩＤ２」、「ＵＩＤ（Universal IDの略）」である。ＮＦＣＩＤ０〜２は、ＮＦＣフォーラムで規定されており、ＵＩＤは、ＮＦＣフォーラムで規定されていない。また、対象装置が携帯端末７０である場合には、通信タイプに応じた上記の各ＩＤを含む信号が受信された後に、ＮＦＣ規格の通信レイヤのうちの比較的に上位層が利用される信号（例えば後述のＮＤＥＦ信号）が受信され、当該信号がＩＤを含み得る。ＣＰＵ３２は、認証に適しているＩＤが受信される場合に、Ｓ１３４において、対象装置からＩＤを抽出する。
【００４２】
Ｓ１４０において、ＣＰＵ３２は、ＩＤの抽出が成功したのか否かを判断する。ＣＰＵ３２は、ＩＤの抽出が成功した場合（例えば図４及び図５の「正常ＥＮＤ」参照）には、Ｓ１４０でＹＥＳと判断し、Ｓ１４２において、Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤとして、Ｓ１３４で抽出されたＩＤをユーザテーブル４０に登録する。Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤが既に登録されている場合には、Ｓ１４２において、ＣＰＵ３２は、ユーザ情報に対応する認証ＩＤとして、対象装置のＩＤを上書きして登録する。なお、変形例では、ＣＰＵ３２は、Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤが既に登録されている場合には、当該ユーザ情報と、対象装置のＩＤと、が対応付けられている新たな情報をユーザテーブル４０に新たに登録してもよい。即ち、この場合、１つのユーザ情報に対して複数の認証ＩＤが登録される。
【００４３】
一方、ＣＰＵ３２は、ＩＤの抽出が失敗した場合（例えば図４及び図５の「エラーＥＮＤ」参照）には、Ｓ１４０でＮＯと判断し、Ｓ１４４において、認証ＩＤの登録を実行不可能であることを示すエラー画面を表示部１４に表示させる。これにより、ユーザは、認証ＩＤの登録が失敗したことを知ることができる。Ｓ１４２又はＳ１４４が終了すると、ＣＰＵ３２は、Ｓ１１０に戻る。
【００４４】
また、Ｓ１５０において、ＣＰＵ３２は、対象装置から、ＮＦＣＩ／Ｆ２２を介して、Ｐｏｌｌｉｎｇ信号に対する応答信号を受信することを監視する。Ｓ１５０は、Ｓ１３０と同様である。また、Ｓ１５０でＹＥＳの場合に実行されるＳ１５２、Ｓ１５４、及び、Ｓ１６０は、Ｓ１３２、Ｓ１３４、及び、Ｓ１４０と同様である。
【００４５】
Ｓ１６２において、ＣＰＵ３２は、Ｓ１５４で抽出されたＩＤの認証、即ち、対象装置の認証を実行する。ＣＰＵ３２は、抽出済みのＩＤに一致する認証ＩＤがユーザテーブル４０に登録されている場合に、認証が成功したと判断する。この場合、ＣＰＵ３２は、Ｓ１２２で説明した処理と同様に、ユーザからの指示に応じて、ユーザに許可されている機能を実行する。ここで、ＣＰＵ３２は、例えば、ユーザに許可されている機能のリストを示す画面を表示部１４に表示させて、当該リストから機能を選択するための指示を受け付けてもよい。ユーザは、対象装置の認証をＭＦＰ１０に実行させることにより、ログイン操作を実行しなくても、ＭＦＰ１０に機能を実行させることができる。なお、ＣＰＵ３２は、対象装置のＩＤに一致する認証ＩＤがユーザテーブル４０に登録されていない場合には、認証が失敗したと判断し、例えばエラー画面を表示部１４に表示させて、Ｓ１１０に戻る。なお、変形例では、ＣＰＵ３２は、Ｓ１６２が終了した後に、認証が再び実行されなくても、ユーザからの指示に応じた処理を実行するための操作を受け付けてもよい。この状態は、ユーザによってログアウト操作が実行されるまで継続されてもよい。
【００４６】
一方、ＣＰＵ３２は、ＩＤの抽出が失敗した場合には、Ｓ１６０でＮＯと判断し、Ｓ１６４において、ＩＤの認証（即ち対象装置の認証）を実行不可能であることを示すエラー画面を表示部１４に表示させる。これにより、ユーザは、認証が失敗したことを知ることができる。この場合、ＣＰＵ３２は、印刷機能及びスキャン機能を実行しない。Ｓ１６２又はＳ１６４が終了すると、Ｓ１１０に戻る。なお、変形例では、エラー画面の表示（即ちＳ１４４及びＳ１６４）に代えて、エラーを示す音声が出力されてもよいし、エラーを示す画像が印刷されてもよい。
【００４７】
（タイプＡに対応するＩＤ抽出処理；図４）
続いて、図４及び図５を参照して、図３のＳ１３４又はＳ１５４で実行される処理の内容を説明する。まず、図４を参照して、Ｓ１３２又はＳ１５２でタイプＡが特定された場合の処理を説明する。
【００４８】
対象装置がタイプＡに対応する場合、即ち、対象装置がタイプＡのＰｏｌｌｉｎｇ信号に対する応答信号を送信した場合には、当該応答信号は、ＮＦＣＩＤ１のデータサイズを示す情報を含むＳＥＮＳ信号（SENS_RES Responseの略）１００を含む。その後、ＣＰＵ３２は、要求信号を対象装置に送信することに応じて、対象装置から、ＮＦＣＩＤ１を含むＳＤＤ信号（SDD_RES Responseの略）１０２とＳＥＬ信号（SEL_RES Responseの略）１０４とを順次受信する。各信号１００、１０４は、対象装置（即ちＮＦＣＩ／Ｆ５２又は７２）の属性を示す属性情報（例えば、データサイズ、後述のＩＳＯ＿ＤＥＰ、ＮＦＣ＿ＤＥＰ等）を含む信号である。なお、上記の各信号１００〜１０４の名称は、ＮＦＣフォーラムで規定されている。
【００４９】
ＮＦＣ通信の通信レイヤは、最下層であるアナログ層と、アナログ層の上位層であるデジタルプロトコル層と、デジタルプロトコル層の上位層であるアクティビティ層と、アクティビティ層の上位層であるＴ１Ｔ〜Ｔ５Ｔ層と、を含む。ＳＥＮＳ信号１００、ＳＤＤ信号１０２、及び、ＳＥＬ信号１０４は、Ｔ１Ｔ〜Ｔ５Ｔ層層以上の通信レイヤが利用されずに、アクティビティ層以下の通信レイヤが利用されて通信される。
【００５０】
ＳＥＮＳ信号１００に含まれるＮＦＣＩＤ１のデータサイズを示す情報は、４バイト又は７バイトを示す。具体的には、ＯＳソフトウェア７４によって準備されるＮＦＣＩＤ１は、通常、４バイトである。また、Mifare Desfire系の認証カードに割り当てられているＮＦＣＩＤ１は、通常、７バイトである。
【００５１】
例えば、対象装置が認証カード５０である場合には、ＮＦＣＩＤ１は、認証カード５０に予め割り当てられている。この場合、ＮＦＣＩＤ１は認証カード毎にユニークなＩＤであり、２枚以上の認証カードの間でＮＦＣＩＤ１が重複しない。また、例えば、対象装置が携帯端末７０である場合には、ＮＦＣＩＤ１は、ＯＳソフトウェア７４によって準備される。例えば、ＯＳソフトウェア７４は、ＳＤＤ信号１０２を送信すべき際に、ランダムに文字列を決定して、当該文字列をＮＦＣＩＤ１として決定する。従って、仮に、携帯端末７０から受信されるＮＦＣＩＤ１がユーザテーブル４０に登録されると（図３のＳ１４２）、その後に携帯端末７０から受信されるＮＦＣＩＤ１は、通常、登録済みのＮＦＣＩＤ１とは異なる。従って、携帯端末７０から受信されるＮＦＣＩＤ１は、認証に適しておらず、ユーザテーブル４０に登録されるべきではない。
【００５２】
ＳＥＬ信号１０４内の第６ビットは、対象装置がＩＳＯ＿ＤＥＰ（ISO/IEC14443-4で定義されたData Exchange Protocolの略）をサポートしているのか否かを示す。「ＩＳＯ＿ＤＥＰをサポートしている」は、対象装置がISO/IEC14443-4に対応していることを意味する。第６ビットが「ＯＮ」を示す場合には、対象装置がＩＳＯ＿ＤＥＰをサポートしており、第６ビットが「ＯＦＦ」を示す場合には、対象装置がＩＳＯ＿ＤＥＰをサポートしていない。対象装置がＩＳＯ＿ＤＥＰをサポートしているということは、対象装置が携帯端末７０又はMifare Desfire系の認証カードであることを意味する。また、対象装置がＩＳＯ＿ＤＥＰをサポートしていないということは、対象装置がMifare系の認証カードであることを意味する。
【００５３】
また、ＳＥＬ信号１０４内の第７ビットは、対象装置がＮＦＣ＿ＤＥＰ（ISO/IEC18092で定義されたData Exchange Protocolの略）をサポートしているのか否かを示す。ＮＦＣ＿ＤＥＰをサポートしているとは、対象装置がＰ２Ｐ通信リンクを確立可能であること、即ち、対象装置が双方向通信を実行可能であること、を意味する。第７ビットが「ＯＮ」を示す場合には、対象装置がＮＦＣ＿ＤＥＰをサポートしており、第７ビットが「ＯＦＦ」を示す場合には、対象装置がＮＦＣ＿ＤＥＰをサポートしていない。対象装置がＮＦＣ＿ＤＥＰをサポートしているということは、対象装置が携帯端末７０であることを意味する。また、対象装置がＮＦＣ＿ＤＥＰをサポートしていないということは、対象装置がMifare系又はMifare Desfire系の認証カードであることを意味する。なお、ＳＥＬ信号（即ちSEL_RES Response）は、ＳＡＫ（Select Acknowledgeの略）と言い換えることもできる。
【００５４】
Ｓ２００において、ＣＰＵ３２は、ＳＥＬ信号１０４内の第６ビットの値に基づいて、対象装置がＩＳＯ＿ＤＥＰをサポートしているのか否かを判断する。ＣＰＵ３２は、第６ビットが「ＯＮ」を示す場合には、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（Ｓ２００でＹＥＳ）、Ｓ２２０に進む。一方、ＣＰＵ３２は、第６ビットが「ＯＦＦ」を示す場合には、対象装置がＩＳＯ＿ＤＥＰをサポートしていないと判断し（Ｓ２００でＮＯ）、Ｓ２１０に進む。この場合、ＣＰＵ３２は、対象装置がMifare系の認証カード５０であると判断する。
【００５５】
Ｓ２１０において、ＣＰＵ３２は、Mifare系の認証カード５０のカードタイプを特定する。カードタイプが異なると、ＮＦＣＩＤ１のデータサイズが異なり得る。このために、ＣＰＵ３２は、ＳＥＬ信号１０４内のカードタイプを示す情報（図示省略）に基づいて、認証カード５０のカードタイプを特定する。例えば、ＣＰＵ３２は、Mifare Ultralight、Mifare Mini等の複数のカードタイプの中から１個のカードタイプを特定する。
【００５６】
次いで、Ｓ２１２において、ＣＰＵ３２は、Ｓ２１０で特定されたカードタイプに基づいて、ＮＦＣＩＤ１のデータサイズを特定し、ＳＤＤ信号１０２内の文字列から、特定済みのデータサイズを有するＮＦＣＩＤ１を抽出する。Ｓ２１２が終了すると、ＣＰＵ３２は、正常ＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＹＥＳと判断され、Ｓ１４２又はＳ１６２では抽出済みのＮＦＣＩＤ１が利用される。なお、変形例では、ＣＰＵ３２は、Ｓ２１０に代えて、ＳＥＮＳ信号１００内のデータサイズ情報に基づいて、ＮＦＣＩＤ１のデータサイズを特定してもよい。
【００５７】
Ｓ２２０において、ＣＰＵ３２は、ＳＥＬ信号１０４内の第７ビットの値に基づいて、対象装置がＮＦＣ＿ＤＥＰをサポートしているのか否かを判断する。ＣＰＵ３２は、第７ビットが「ＯＮ」を示す場合に、対象装置がＮＦＣ＿ＤＥＰをサポートしていると判断し（Ｓ２２０でＹＥＳ）、Ｓ２３０に進む。この場合、ＣＰＵ３２は、対象装置がＰ２Ｐ通信リンクを確立可能な携帯端末７０であると判断する。一方、ＣＰＵ３２は、第７ビットが「ＯＦＦ」を示す場合に、対象装置がＮＦＣ＿ＤＥＰをサポートしていないと判断し（Ｓ２２０でＮＯ）、Ｓ２２２に進む。この場合、ＣＰＵ３２は、対象装置がＰ２Ｐ通信リンクを確立不可能な携帯端末７０、又は、Mifare Desfire系の認証カード５０であると判断する。なお、携帯端末７０は、通常、Ｐ２Ｐ通信リンクを確立するための能力を有しており、実際には、Ｐ２Ｐ通信リンクを確立可能である。ただし、ある種の携帯端末７０は、Ｐ２Ｐ通信リンクを確立可能であるにも関わらず、ＮＦＣ＿ＤＥＰをサポートしていないことを示す情報を含むＳＥＬ信号１０４をＭＦＰ１０に送信し得る。このような携帯端末７０からＳＥＬ信号１０４が受信される場合には、ＣＰＵ３２は、Ｓ２２０でＮＯと判断する。
【００５８】
Ｓ２２２において、ＣＰＵ３２は、ＳＥＮＳ信号１００内のデータサイズ情報が７バイトを示すのか否かを判断する。ＣＰＵ３２は、データサイズ情報が７バイトを示す場合には、Ｓ２２２でＹＥＳと判断し、Ｓ２１２に進む。この場合、ＣＰＵ３２は、対象装置がMifare Desfire系の認証カード５０であると判断し、Ｓ２１２において、ＳＤＤ信号１０２内の文字列から、７バイトを有するＮＦＣＩＤ１を抽出する。一方、ＣＰＵ３２は、データサイズ情報が４バイトを示す場合には、Ｓ２２２でＮＯと判断し、Ｓ２３０に進む。この場合、ＣＰＵ３２は、対象装置が携帯端末７０であると判断する。なお、Mifare Desfire系の認証カード５０であると判断するデータサイズ（本実施例では７バイト）は、Mifareの仕様書に記載されているデータサイズに基づいて設定される。
【００５９】
Ｓ２３０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｔ４Ｔ層を利用した通信（以下では「Ｔ４Ｔ通信」と呼ぶ）を、対象装置である携帯端末７０と実行する。ＣＰＵ３２は、Ｔ４Ｔ通信において、要求信号を携帯端末７０に送信して、携帯端末７０から応答信号を受信する。当該応答信号は、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号１２０を含む。Ｆｏｒｍａｔ情報は、携帯端末７０がＮＤＥＦ（NFC Data Exchange Formatの略）をサポートしているのか否かを示す。携帯端末７０は、ＮＤＥＦをサポートしている場合には、ＮＤＥＦ領域を含むＮＤＥＦ信号１２２の通信を実行可能であり、ＮＤＥＦをサポートしていない場合には、ＮＤＥＦ信号１２２の通信を実行不可能である。ＮＤＥＦ領域は、携帯端末７０が自由に情報を記述可能な領域である。後述するように、ＮＤＥＦ領域には、例えば、認証アプリケーション７８によって生成されるＩＤ（以下では「生成ＩＤ」と呼ぶ）が記述される。
【００６０】
生成ＩＤは、認証アプリケーション７８の初回起動時に生成される。認証アプリケーション７８は、携帯端末７０のＭＡＣアドレスから所定バイト（例えば３２バイト）を有する生成ＩＤを生成する。生成ＩＤは、２個以上の携帯端末の間で重複しないユニークなＭＡＣアドレスから生成されるために、ユニークなＩＤである。また、同じ携帯端末７０では、認証アプリケーション７８の初回起動時に生成された生成ＩＤ（即ち固定的なＩＤ）が継続して利用される。そして、認証アプリケーション７８は、認証アプリケーション７８のベンダ（即ちＭＦＰ１０のベンダ）を示すベンダ情報と、生成ＩＤと、をＮＤＥＦ領域に記述する。なお、変形例では、認証アプリケーション７８には、２個以上の認証アプリケーションの間で重複しないユニークなＩＤが予め割り当てられていてもよい。この場合、認証アプリケーション７８は、当該ＩＤをＮＤＥＦ領域に記述してもよい。また、別の変形例では、認証アプリケーション７８が、生成ＩＤ又は予め割り当てられているＩＤをＯＳソフトウェア７４に供給し、ＯＳソフトウェア７４が、当該ＩＤをＮＤＥＦ領域に記述してもよい。即ち、ＩＤを含むＮＤＥＦ信号１２２は、認証アプリケーション７８に従って送信される信号であればよい。
【００６１】
Ｓ２３２において、ＣＰＵ３２は、Ｆｏｒｍａｔ信号１２０に含まれるＦｏｒｍａｔ情報に基づいて、携帯端末７０がＮＤＥＦをサポートしているのか否かを判断する。ＣＰＵ３２は、携帯端末７０がＮＤＥＦをサポートしていると判断する場合（Ｓ２３２でＹＥＳ）に、Ｓ２３４に進む。一方、ＣＰＵ３２は、携帯端末７０がＮＤＥＦをサポートしていないと判断する場合（Ｓ２３２でＮＯ）に、Ｓ２４０に進む。携帯端末７０は、ＮＤＥＦを利用する何らかのアプリケーション（例えば認証アプリケーション７８）を有する場合には、ＮＤＥＦをサポートしていることを示すＦｏｒｍａｔ情報をＭＦＰ１０に送信するが、そのようなアプリケーションを有していない場合には、ＮＤＥＦをサポートしていないことを示すＦｏｒｍａｔ情報をＭＦＰ１０に送信する。従って、Ｓ２３２でＮＯと判断されることは、携帯端末７０が認証アプリケーション７８を有していないことを意味する。
【００６２】
Ｓ２３４において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、さらなるＴ４Ｔ通信を携帯端末７０と実行する。ＣＰＵ３２は、Ｔ４Ｔ通信において、要求信号を携帯端末７０に送信し、携帯端末７０から応答信号を受信する。当該応答信号は、ＮＤＥＦ領域を含むＮＤＥＦ信号１２２を含む。
【００６３】
Ｓ２３６において、ＣＰＵ３２は、ＮＤＥＦ信号１２２に含まれるＮＤＥＦ領域内の記述内容に基づいて、携帯端末７０が認証アプリケーション７８を有するのか否かを判断する。具体的には、ＣＰＵ３２は、ＮＤＥＦ領域にベンダを示すベンダ情報が記述されている場合に、携帯端末７０が認証アプリケーション７８を有すると判断し（Ｓ２３６でＹＥＳ）、Ｓ２３８に進む。一方、ＣＰＵ３２は、ＮＤＥＦ領域にベンダを示すベンダ情報が記述されていない場合に、携帯端末７０が認証アプリケーション７８を有さないと判断し（Ｓ２３６でＮＯ）、Ｓ２４０に進む。なお、Ｓ２３２でＹＥＳと判断され、かつ、Ｓ２３６でＮＯと判断される場合には、携帯端末７０は、ＮＤＥＦを利用する何らかのアプリケーションを有しているが、当該アプリケーションが認証アプリケーション７８ではないことを意味する。
【００６４】
Ｓ２３８において、ＣＰＵ３２は、ＮＤＥＦ領域内の生成ＩＤを抽出する。この場合、ＣＰＵ３２は、正常ＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＹＥＳと判断され、Ｓ１４２又はＳ１６２では抽出済みの生成ＩＤが利用される。
【００６５】
Ｓ２４０では、ＣＰＵ３２は、ＵＲＬ供給処理（図６参照）を実行する。ＵＲＬ供給処理が終了すると、ＣＰＵ３２は、エラーＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＮＯと判断される。
【００６６】
（タイプＢに対応するＩＤ抽出処理；図４）
続いて、図３のＳ１３２又はＳ１５２でタイプＢが特定された場合の処理を説明する。タイプＡとタイプＢとの間で共通する処理が多いので、図４を参照して、タイプＢに対応するＩＤ抽出処理を説明する。タイプＢに対応する複数枚の認証カードには、同じＮＦＣＩＤ０が割り当てられ得る。このために、認証カード５０のＮＦＣＩＤ０は、認証に適していない。従って、本実施例では、対象装置がタイプＢに対応する認証カード５０である場合には、ＩＤの登録及び認証が実行されない。
【００６７】
ＣＰＵ３２は、図４のＳ２００〜Ｓ２２２をスキップして、Ｓ２３０〜Ｓ２４０の処理を実行する。対象装置が認証カード５０である場合には、ベンダ情報がＮＤＥＦ領域に記述されないので、ＣＰＵ３２は、Ｓ２３６でＮＯと判断する場合に、対象装置が認証カード５０であると判断することができる。この場合、ＣＰＵ３２は、Ｓ２４０のＵＲＬ供給処理を実行することなく、エラーＥＮＤとして図４の処理を終了する。
【００６８】
一方、対象装置が携帯端末７０である場合には、ＣＰＵ３２は、Ｓ２３０〜Ｓ２４０の処理を実行して、生成ＩＤを抽出して正常ＥＮＤとして処理を終了するか、ＵＲＬ供給処理を実行してエラーＥＮＤとして処理を終了する。
【００６９】
（タイプＦに対応するＩＤ抽出処理；図５）
続いて、図５を参照して、図３のＳ１３２又はＳ１５２でタイプＦが特定された場合の処理を説明する。対象装置がタイプＦに対応する場合、即ち、対象装置がタイプＦのＰｏｌｌｉｎｇ信号に対する応答信号を送信した場合には、当該応答信号は、ＮＦＣフォーラムで規定されているＳＥＮＳＦ信号（SENSF_RES Responseの略）１４０を含む。ＳＥＮＳＦ信号１４０は、Ｔ３Ｔ（Type 3 Tagの略）層以上の通信レイヤが利用されずに、アクティビティ層以下の通信レイヤが利用されて通信される。ＳＥＮＳＦ信号１４０は、ＰＡＤ０とＮＦＣＩＤ２とを含む。
【００７０】
ＰＡＤ０は、対象装置（即ちＮＦＣＩ／Ｆ）の属性を示す属性情報であり、ＮＦＣＩ／ＦのＩＣタイプを示す情報を含む。なお、ＰＡＤ０は、ＰＭｍ（Manufacture Parameterの略）と言い換えることもできる。対象装置が携帯端末７０である場合には、ＰＡＤ０は、０６ｈ、０７ｈ、１０ｈ〜１３ｈ、及び、１４ｈ〜１Ｆｈ（以下ではこれらをまとめて「所定タイプ」と呼ぶ）のいずれかのＩＣタイプを示す。また、対象装置が認証カード５０である場合には、ＰＡＤ０は、０１ｈ、０８ｈ、０９ｈ、０Ｄｈ、２０ｈ、及び、３２ｈのいずれかのＩＣタイプを示す。なお、ＰＡＤ０は、２ｂｙｔｅの情報であり、本明細書及び図面に記載されているＩＣタイプを示す情報（０６ｈ等）は、ＰＡＤ０に含まれる情報の一部を示す。
【００７１】
ＮＦＣＩＤ２は、データサイズが８バイトである点を除くと、ＮＦＣＩＤ１と同様であり、対象装置を識別するためのＩＤｍ（Manufacture ID）と言い換えることもできる。即ち、対象装置が認証カード５０である場合には、ユニークなＮＦＣＩＤ２が認証カード５０に予め割り当てられている。また、対象装置が携帯端末７０である場合には、ＯＳソフトウェア７４によってＮＦＣＩＤ２が準備される。即ち、携帯端末７０から受信されるＮＦＣＩＤ２は、認証に適していない。
【００７２】
Ｓ３００において、ＣＰＵ３２は、ＳＥＮＳＦ信号１４０に含まれるＰＡＤ０に基づいて、対象装置のＮＦＣＩ／ＦのＩＣタイプが上記の所定タイプであるのか否かを判断する。ＣＰＵ３２は、ＰＡＤ０が所定タイプを示す場合に、Ｓ３００でＹＥＳと判断して、Ｓ３３０に進む。この場合、ＣＰＵ３２は、対象装置が携帯端末７０であると判断する。一方、ＣＰＵ３２は、ＰＡＤ０が所定タイプを示さない場合に、Ｓ３００でＮＯと判断し、Ｓ３１２に進む。この場合、ＣＰＵ３２は、対象装置がFeliCa Standard、FeliCa Liteなどの認証カード５０であると判断する。
【００７３】
Ｓ３１２において、ＣＰＵ３２は、ＳＥＮＳＦ信号１４０に含まれるＮＦＣＩＤ２を抽出する。Ｓ３１２が終了すると、ＣＰＵ３２は、正常ＥＮＤとして図５の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＹＥＳと判断され、Ｓ１４２又はＳ１６２では抽出済みのＮＦＣＩＤ２が利用される。
【００７４】
Ｓ３３０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｔ３Ｔ層を利用した通信（以下では「Ｔ３Ｔ通信」と呼ぶ）を、対象装置である携帯端末７０と実行する。ＣＰＵ３２は、Ｔ３Ｔ通信において、要求信号を携帯端末７０に送信し、携帯端末７０からのＦｏｒｍａｔ信号１６０を受信する。Ｆｏｒｍａｔ信号１６０は、図４のＦｏｒｍａｔ信号１２０と同様である。以降のＳ３３２〜Ｓ３４０は、図４のＳ２３２〜Ｓ２４０と同様であり、Ｓ３３４で受信されるＮＤＥＦ信号１６２は、図４のＮＤＥＦ信号１２２と同様である。ＣＰＵ３２は、Ｓ３３０〜Ｓ３４０の処理を実行して、生成ＩＤを抽出して正常ＥＮＤとして処理を終了するか、ＵＲＬ供給処理を実行してエラーＥＮＤとして処理を終了する。
【００７５】
（タイプＶに対応するＩＤ抽出処理）
続いて、図示省略しているが、図３のＳ１３２又はＳ１５２でタイプＶが特定された場合の処理を説明する。対象装置がタイプＶに対応する場合には、対象装置は、携帯端末７０であることはあり得ず、認証カード５０である。従って、ＣＰＵ３２は、タイプＶを特定した場合には、Ｐｏｌｌｉｎｇ信号に対する応答信号に含まれるＵＩＤを抽出する。この場合、Ｓ１４０又はＳ１６０では、必ずＹＥＳと判断される。なお、タイプＶに対応するＵＩＤのデータサイズは、８バイトである。
【００７６】
（ＵＲＬ供給処理：図６）
続いて、図６を参照して、図４のＳ２４０又は図５のＳ３４０で実行される処理の内容について説明する。
【００７７】
Ｓ４００において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｄｅａｃｔｉｖａｔｅ信号を対象装置に送信する。これにより、ＮＦＣＩ／Ｆ２２とＮＦＣＩ／Ｆ７２との間の通信リンクが切断される。
【００７８】
Ｓ４０２において、ＣＰＵ３２は、ＲＦ（Radio Frequencyの略）をＯＦＦするための指示をＮＦＣＩ／Ｆ２２に供給する。これにより、ＮＦＣＩ／Ｆ２２は、電波を利用可能な状態（以下では「可能状態」と呼ぶ）から、電波を利用不可能な状態（以下では「不可能状態」と呼ぶ）に移行する。ＮＦＣＩ／Ｆ２２が不可能状態である場合には、ＮＦＣＩ／Ｆ２２は、通信リンクを確立することができない。従って、通信リンクが確立されることに起因して、次のＳ４０４においてＮＦＣＩ／Ｆ２２のモード状態を変更することができない事象が発生するのを抑制することができる。
【００７９】
Ｓ４０４において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＲ／ＷモードがＯＮされており、ＣＥモードがＯＦＦされているモード状態に設定する。詳しくは後述するが、本実施例では、ＣＰＵ３２は、Ｐ２Ｐモードに従ったＰ２Ｐ通信リンクを利用して、ＵＲＬを携帯端末７０に送信する（Ｓ４３０でＹＥＳ、Ｓ４３２）。このために、Ｓ４０４では、Ｐ２ＰモードがＯＮされる。Ｒ／ＷモードもＯＮされるが、変形例では、Ｒ／ＷモードがＯＦＦされてもよい。Ｐ２Ｐ通信リンクは、双方向通信を実行するためのリンクである。このために、ＣＰＵ３２は、ＵＲＬ３９を携帯端末７０に送信することに応じて、携帯端末７０から確認信号を受信することができる。従って、Ｐ２Ｐ通信リンクを利用する構成を採用すると、ＵＲＬ３９の送信の確実性を高めることができる。
【００８０】
Ｓ４０６において、ＣＰＵ３２は、ＲＦをＯＮするための指示をＮＦＣＩ／Ｆ２２に供給する。これにより、ＮＦＣＩ／Ｆ２２は、不可能状態から可能状態に移行する。なお、変形例では、Ｓ４０２及びＳ４０６を省略してもよい。
【００８１】
次いで、Ｓ４０８において、ＣＰＵ３２は、Ｐｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。ＣＰＵ３２は、携帯端末７０の種類に応じて、Ｐｏｌｌｉｎｇ信号のタイプを変える。Ｐ２Ｐ通信リンクを確立するためには、タイプＡ又はＦのＰｏｌｌｉｎｇ信号に対する応答信号が通信されなければならない。従って、Ｓ４０８では、ＣＰＵ３２は、タイプＡ及びＦのうちの少なくとも一方のタイプのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。
【００８２】
具体的には、ＣＰＵ３２は、図３のＳ１３２で特定されたタイプがＡ又はＦであり、かつ、携帯端末７０がＮＦＣ＿ＤＥＰをサポートしている場合には、タイプＡ、Ｂ、Ｆ、及び、Ｖに対応する４種類のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。上述したように、ＣＰＵ３２は、タイプＡの応答信号を受信する場合には、ＳＥＬ信号（図４参照）内の第７ビットの情報に基づいて、携帯端末７０がＮＦＣ＿ＤＥＰをサポートしているのか否かを判断することができる。また、ＣＰＵ３２は、タイプＦの応答信号を受信する場合には、ＳＥＮＳＦ１４０（図５参照）内の先頭の第１バイトと第２バイトとの情報（図示省略）に基づいて、携帯端末７０がＮＦＣ＿ＤＥＰをサポートしているのか否かを判断することができる。携帯端末７０がＮＦＣ＿ＤＥＰをサポートしている場合（即ち双方向通信であるＰ２Ｐ通信を実行可能である場合）には、タイプＡ及びＦのどちらのＰｏｌｌｉｎｇ信号に対する応答信号が通信されても、携帯端末７０とのＰ２Ｐ通信リンクを確立可能である。従って、ＣＰＵ３２は、タイプＡ及びＦを含む４種類のタイプのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。ただし、変形例では、ＣＰＵ３２は、タイプＡ及びＦのみのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示してもよい。
【００８３】
ＣＰＵ３２は、図３のＳ１３２で特定されたタイプがＢである場合にも、タイプＡ及びＦを含む４種類のタイプ（変形例ではタイプＡ及びＦのみ）のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。これにより、前回、タイプＢの応答信号を送信した携帯端末７０が、今回、タイプＡ及びＦの応答信号を送信することに起因して、Ｐ２Ｐ通信リンクが確立され得る。
【００８４】
ＣＰＵ３２は、図３のＳ１３２で特定されたタイプがＡであり、かつ、携帯端末７０がＮＦＣ＿ＤＥＰをサポートしていない場合には、タイプＦのみのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。タイプＡの応答信号がＮＦＣ＿ＤＥＰをサポートしていないことを示す場合には、タイプＡの応答信号が通信されても、携帯端末７０とのＰ２Ｐ通信リンクを確立不可能である。そして、このような携帯端末７０は、通常、ＮＦＣ＿ＤＥＰをサポートしていることを示すタイプＦの応答信号を送信することができ、この場合、Ｐ２Ｐ通信リンクを確立可能である。従って、ＣＰＵ３２は、タイプＦのみのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。
【００８５】
ＣＰＵ３２は、図３のＳ１３２で特定されたタイプがＦであり、かつ、携帯端末７０がＮＦＣ＿ＤＥＰをサポートしていない場合には、タイプＡのみのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。タイプＦの応答信号がＮＦＣ＿ＤＥＰをサポートしていないことを示す場合には、タイプＦのＰｏｌｌｉｎｇ信号に対する応答信号が通信されても、携帯端末７０とのＰ２Ｐ通信リンクを確立不可能である。そして、このような携帯端末７０は、通常、ＮＦＣ＿ＤＥＰをサポートしていることを示すタイプＡの応答信号を送信することができ、この場合、Ｐ２Ｐ通信リンクを確立可能である。従って、ＣＰＵ３２は、タイプＡのみのＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。
【００８６】
なお、変形例では、Ｓ４０８において、ＣＰＵ３２は、携帯端末７０の種類に関わらず、上記の４種類（変形例ではタイプＡ及びＦのみ）のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示してもよい。また、別の変形例では、ＣＰＵ３２は、Ｐｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示しなくてもよい。この場合、ＮＦＣＩ／Ｆ２２は、携帯端末７０から受信されるＰｏｌｌｉｎｇ信号に対する応答信号を送信することに応じて、Ｐ２Ｐ通信リンクを確立することができる。ただし、本実施例のように、ＮＦＣＩ／Ｆ２２がＰｏｌｌｉｎｇ信号を送信する構成を採用すると、Ｐ２Ｐ通信リンクを迅速かつ適切に確立し得る。また、別の変形例では、ＮＦＣＩ／Ｆ２２及び携帯端末７０のＮＦＣＩ／Ｆ７２のそれぞれが、Ｐｏｌｌｉｎｇ信号を送信してもよい。この場合、ＮＦＣＩ／Ｆ２２は、ＮＦＣＩ／Ｆ２２自身から送信されるＰｏｌｌｉｎｇ信号に応じて携帯端末７０から応答信号を受信する場合、又は、携帯端末７０から受信されるＰｏｌｌｉｎｇ信号に応じて応答信号を送信する場合に、Ｐ２Ｐ通信リンクを確立することができる。
【００８７】
Ｓ４１０において、ＣＰＵ３２は、タイマーのカウントを開始する。Ｓ４１２において、ＣＰＵ３２は、タイマーのカウント値が所定値を超えることを監視する。所定値は、携帯端末７０へのＵＲＬ３９の送信が失敗したことを判断するための閾値である。ＣＰＵ３２は、タイマーのカウント値が所定値を超えた場合（Ｓ４１２でＮＯ）には、Ｓ４２０において、ＵＲＬ３９の送信失敗を示す通知画面を表示部１４に表示させる。これにより、ユーザは、ＵＲＬ３９の送信が失敗したことを知ることができる。Ｓ４２０が終了すると、Ｓ４４０に進む。
【００８８】
また、Ｓ４３０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２とＮＦＣＩ／Ｆ７２との間にＰ２Ｐ通信リンクが確立されることを監視する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２からＰ２Ｐ通信リンクが確立されたことを示す情報を取得する場合（Ｓ４３０でＹＥＳ）に、Ｓ４３２に進む。
【００８９】
Ｓ４３２において、ＣＰＵ３２は、メモリ３４内のＵＲＬ３９をＮＦＣＩ／Ｆ２２に供給する。この結果、ＮＦＣＩ／Ｆ２２は、Ｐ２Ｐ通信リンクを介して、ＵＲＬ３９が記述されたＮＤＥＦ領域を含むＮＤＥＦ信号を携帯端末７０に送信する。
【００９０】
Ｓ４３４において、ＣＰＵ３２は、携帯端末７０から、ＵＲＬ３９を受信したことを示す確認信号を受信したのか否かを判断する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から確認信号を受信したことを示す情報を取得する場合（Ｓ４３４でＹＥＳ）に、Ｓ４４０に進み、ＮＦＣＩ／Ｆ２２から当該情報を取得しない場合（Ｓ４３４でＮＯ）に、Ｓ４２０に進む。
【００９１】
Ｓ４４０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｄｅａｃｔｉｖａｔｅ信号を携帯端末７０に送信する。これにより、ＮＦＣＩ／Ｆ２２とＮＦＣＩ／Ｆ７２との間のＰ２Ｐ通信リンクが切断される。
【００９２】
Ｓ４４２は、Ｓ４０２と同様である。Ｓ４４４において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｒ／ＷがＯＮされており、Ｐ２Ｐモード及びＣＥモードがＯＦＦされているモード状態に設定する。これにより、図３のＳ１００のモード状態に戻る。Ｓ４４６は、Ｓ４０６と同様である。Ｓ４４６が終了すると、図６の処理が終了する。
【００９３】
（具体的なケース）
続いて、図７〜図１０を参照して、図３〜図６の各処理によって実現される具体的なケースＡ〜Ｇについて説明する。各ケースＡ〜Ｇの初期状態では、認証フラグ３８が「ＯＮ」に設定されており、この結果、ＮＦＣＩ／Ｆ２２ではＲ／ＷモードのみがＯＮされている（図３のＳ１００）。
【００９４】
Ｔ１０では、ＭＦＰ１０は、４つのタイプに対応する４種類のＰｏｌｌｉｎｇ信号を順次送信することを繰り返す（図３のＳ１００）。
【００９５】
（ケースＡ；図７）
ケースＡでは、対象装置は、通信タイプがタイプＡに対応するMifare系の認証カード５０Ａである。認証カード５０Ａには、ＮＦＣＩＤ１「Ａ３」が予め割り当てられている。
【００９６】
ＭＦＰ１０は、Ｔ２０において、ユーザ名「Ｕ３」及びパスワード「Ｐ３」の組合せを含むユーザ情報の入力（即ちログイン操作）を受け付け（図３のＳ１１０）、Ｔ２２において、登録ボタンの操作を受け付ける（Ｓ１２０でＹＥＳ）。
【００９７】
その後、ユーザが認証カード５０ＡをＭＦＰ１０に近づけると、Ｔ３０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ａから、ＳＥＮＳ信号と、ＮＦＣＩＤ１「Ａ３」を含むＳＤＤ信号と、ＳＥＬ信号と、を含むタイプＡの各応答信号を順次受信する（Ｓ１３０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１３２）。
【００９８】
ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＦＦを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていないと判断し（図４のＳ２００でＮＯ）、対象装置がMifare系の認証カード５０Ａであると判断する。また、ＭＦＰ１０は、ＳＥＬ信号内のカードタイプを示す情報に基づいて、認証カード５０Ａのカードタイプを特定する（Ｓ２１０）。Ｔ４０では、ＭＦＰ１０は、ＳＤＤ信号から、特定済みのカードタイプに対応するデータサイズを有するＮＦＣＩＤ１「Ａ３」を抽出する（Ｓ２１２）。Ｔ４２では、ＭＦＰ１０は、ユーザ情報に対応付けてＮＦＣＩＤ１「Ａ３」を認証ＩＤとしてユーザテーブル４０に登録する（図３のＳ１４２）。なお、Ｔ４２が完了すると、ＭＦＰ１０は、Ｔ２０でログインしたユーザをログオフさせる。
【００９９】
Ｔ４２にて認証カード５０Ａの認証ＩＤのユーザテーブル４０への登録が完了した後に、ユーザが認証カード５０ＡをＭＦＰ１０に再び近づけると、Ｔ５０において、ＭＦＰ１０は、Ｔ３０と同様に、タイプＡの各応答信号を受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。その後のＴ６０は、Ｔ４０と同様である。
【０１００】
Ｔ６２において、ＭＦＰ１０は、認証カード５０Ａの認証を実行する（Ｓ１６２）。ＭＦＰ１０は、Ｔ６０で抽出されたＮＦＣＩＤ１「Ａ３」に一致する認証ＩＤ「Ａ３」がユーザテーブル４０に登録されているので、認証が成功したと判断する。この場合、ＭＦＰ１０は、ユーザ名「Ｕ３」に対応するユーザに許可されている機能を実行する。
【０１０１】
（ケースＢ；図７）
ケースＢでは、対象装置は、通信タイプがタイプＡに対応するMifare Desfire系の認証カード５０Ｂである。認証カード５０Ｂには、ＮＦＣＩＤ１「Ａ４」が予め割り当てられている。
【０１０２】
Ｔ１３０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ｂから、ＳＥＮＳ信号と、ＮＦＣＩＤ１「Ａ４」を含むＳＤＤ信号と、ＳＥＬ信号と、を含むタイプＡの各応答信号を順次受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。
【０１０３】
ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＦＦを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていないと判断する（Ｓ２２０でＮＯ）。そして、ＭＦＰ１０は、ＳＥＮＳ信号内のデータサイズ情報が７バイトを示すので（Ｓ２２２でＹＥＳ）、対象装置がMifare Desfire系の認証カード５０Ｂであると判断する。この結果、ＭＦＰ１０は、Ｔ１４０において、ＳＤＤ信号からＮＦＣＩＤ１「Ａ４」を抽出し（Ｓ２１２）、Ｔ１４２において、ＮＦＣＩＤ１「Ａ４」を利用した認証を実行する（図３のＳ１６２）。
【０１０４】
（ケースＣ；図８）
図７のケースＣでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ａであって、Ｐ２Ｐ通信を実行可能な携帯端末７０Ａである。携帯端末７０Ａには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ５」が割り当てられている。
【０１０５】
ユーザが携帯端末７０ＡをＭＦＰ１０に近づけて、携帯端末７０ＡがＭＦＰ１０からＰｏｌｌｉｎｇ信号を受信すると、Ｔ２２８において、携帯端末７０ＡのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ１「Ａ６」として決定する。
【０１０６】
Ｔ２３０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、携帯端末７０Ａから、ＳＥＮＳ信号と、ＮＦＣＩＤ１「Ａ６」を含むＳＤＤ信号と、ＳＥＬ信号と、を含むタイプＡの各応答信号を受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。
【０１０７】
ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＮを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていると判断する（Ｓ２２０でＹＥＳ）。これにより、ＭＦＰ１０は、対象装置がＰ２Ｐ通信を実行可能な携帯端末７０Ａであると判断する。
【０１０８】
Ｔ２３２において、ＭＦＰ１０は、携帯端末７０Ａから、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号と、ＮＤＥＦ領域を含むＮＤＥＦ信号と、を含むＴ４Ｔの各応答信号を受信する。具体的には、ＭＦＰ１０は、まず、Ｆｏｒｍａｔ信号を受信し（Ｓ２３０）、Ｆｏｒｍａｔ情報が、携帯端末７０ＡがＮＤＥＦをサポートしていることを示すので（Ｓ２３２でＹＥＳ）、さらに、ＮＤＥＦ信号を受信する（Ｓ２３４）。ＭＦＰ１０は、ＮＤＥＦ領域にベンダ情報が含まれるので（Ｓ２３６でＹＥＳ）、Ｔ２４０において、ＮＤＥＦ領域から生成ＩＤ「Ａ５」を抽出し（Ｓ２３８）、Ｔ２４２において、生成ＩＤ「Ａ５」を利用した認証を実行する（図３のＳ１６２）。
【０１０９】
（ケースＤ；図８）
ケースＤでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ｂであって、実際にはＰ２Ｐ通信を実行可能であるにも関わらず、ＳＥＬ信号内の第７ビットにＯＦＦを記述する携帯端末７０Ｂである。携帯端末７０Ｂには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ７」が割り当てられている。
【０１１０】
Ｔ２４８において、携帯端末７０ＢのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ１「Ａ８」として決定する。
【０１１１】
Ｔ２５０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、携帯端末７０Ｂから、ＳＥＮＳ信号と、ＮＦＣＩＤ１「Ａ８」を含むＳＤＤ信号と、ＳＥＬ信号と、を含むタイプＡの各応答信号を順次受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。
【０１１２】
ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＦＦを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていないと判断する（Ｓ２２０でＮＯ）。そして、ＭＦＰ１０は、ＳＥＮＳ信号内のデータサイズ情報が４バイトを示すので（Ｓ２２２でＮＯ）、対象装置がＰ２Ｐ通信を実行不可能な携帯端末７０Ｂであると判断する。その後のＳ２５２〜Ｓ２６２は、ケースＣのＴ２３２〜Ｔ２４２と同様である。
【０１１３】
（ケースＥ；図９）
ケースＥでは、対象装置は、通信タイプがタイプＦに対応するFeliCa Standard 、FeliCa Liteなどの認証カード５０Ｃである。認証カード５０Ｃには、ＮＦＣＩＤ２「Ａ９」が予め割り当てられている。
【０１１４】
Ｔ３３０において、ＭＦＰ１０は、タイプＦのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ｃから、ＳＥＮＳＦ信号を含むタイプＦの応答信号を受信する（Ｓ１５０でＹＥＳ）。ＳＥＳＦ信号は、ＩＣタイプ「０１ｈ」を示すＰＡＤ０と、ＮＦＣＩＤ２「Ａ９」と、を含む。この場合、ＭＦＰ１０は、タイプＦを特定する（Ｓ１５２）。
【０１１５】
ＭＦＰ１０は、ＰＡＤ０が示すＩＣタイプ「０１ｈ」が所定タイプを示さないので（図５のＳ３００でＮＯ）、対象装置がFeliCa Standard 、FeliCa Liteなどの認証カード５０Ｃであると判断する。この結果、ＭＦＰ１０は、Ｔ３４０において、ＳＥＮＳＦ信号からＮＦＣＩＤ２「Ａ９」を抽出し（Ｓ３１２）、Ｔ３４２において、ＮＦＣＩＤ２「Ａ９」を利用した認証を実行する（図３のＳ１６２）。
【０１１６】
（ケースＦ；図９）
ケースＦでは、対象装置は、通信タイプがタイプＦに対応する携帯端末７０Ｃである。携帯端末７０Ｃには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ１０」が割り当てられている。
【０１１７】
Ｔ３４８において、携帯端末７０ＣのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ２「Ａ１１」として決定する。
【０１１８】
Ｔ３５０において、ＭＦＰ１０は、タイプＦのＰｏｌｌｉｎｇ信号の送信に応じて、携帯端末７０Ｃから、ＳＥＮＳＦ信号を含むタイプＦの応答信号を受信する（Ｓ１５０でＹＥＳ）。ＳＥＮＳＦ信号は、ＩＣタイプ「０６ｈ」を示すＰＡＤ０と、ＮＦＣＩＤ２「Ａ１１」と、を含む。この場合、ＭＦＰ１０は、タイプＦを特定する（Ｓ１５２）。
【０１１９】
ＭＦＰ１０は、ＰＡＤ０が示すＩＣタイプ「０６ｈ」が所定タイプを示すので（図５のＳ３００でＹＥＳ）、対象装置が携帯端末７０Ｃであると判断する。その後のＴ３５２〜Ｔ３６２は、図７のケースＣのＴ２３２〜Ｔ２４２と同様である。
【０１２０】
（ケースＧ：図１０）
ケースＧでは、対象装置は、通信タイプがタイプＡに対応している携帯端末７０Ｄであって、認証アプリケーション７８をまだインストールしていない携帯端末７０Ｄである。認証アプリケーション７８がインストールされていない状態では、携帯端末７０Ｄは、ＮＤＥＦを利用することができない。
【０１２１】
Ｔ４２８〜Ｔ４３０は、ＮＦＣＩＤ１「Ａ１２」が利用される点を除くと、図８のＴ２２８〜Ｔ２３０と同様である。Ｔ４３２において、ＭＦＰ１０は、携帯端末７０Ｄから、Ｆｏｒｍａｔ信号を含むＴ４Ｔの各応答信号を受信する。Ｆｏｒｍａｔ情報が、携帯端末７０ＤがＮＤＥＦをサポートしていないことを示すので（Ｓ２３２でＮＯ）、ＭＦＰ１０は、ＵＲＬ供給処理（Ｓ２４０）を実行する。
【０１２２】
Ｔ４４０において、ＭＦＰ１０は、Ｄｅａｃｔｉｖａｔｅ信号を携帯端末７０Ｄに送信する（図６のＳ４００）。これにより、ＭＦＰ１０と携帯端末７０との間の通信リンクが切断される。
【０１２３】
ＭＦＰ１０は、Ｔ４４２において、ＮＦＣＩ／Ｆ２２のＲＦをＯＦＦし（Ｓ４０２）、Ｔ４４４において、ＮＦＣＩ／Ｆ２２のモード状態をＰ２Ｐモード及びＲ／ＷモードのみがＯＮされている状態に設定し（Ｓ４０４）、Ｔ４４６において、ＮＦＣＩ／Ｆ２２のＲＦをＯＮする（Ｓ４０６）。
【０１２４】
ＭＦＰ１０は、Ｔ４３０で受信した信号に基づいて、Ｔ４３０の応答信号がタイプＡに対応しており、かつ、Ｐ２Ｐ通信可能であると判断し、この結果、Ｔ４５０において、４種類のＰｏｌｌｉｎｇ信号の送信を実行する（Ｓ４０８）。この場合、ＭＦＰ１０は、携帯端末７０ＤからタイプＡ又はＦに対応する応答信号を受信して、Ｔ４６０において、Ｐ２Ｐ通信リンクを確立する（Ｓ４３０でＹＥＳ）。
【０１２５】
ＭＦＰ１０は、Ｔ４７０において、Ｐ２Ｐ通信リンクを利用して、ＵＲＬ３９を含むＮＤＥＦ信号を携帯端末７０Ｄに送信し（Ｓ４３２）、Ｔ４７２において、携帯端末７０Ｄから確認信号を受信する（Ｓ４３４でＹＥＳ）。そして、ＭＦＰ１０は、Ｔ４８０において、Ｄｅａｃｔｉｖａｔｅ信号を送信し（Ｓ４４０）、Ｔ４８２において、ＮＦＣＩ／Ｆ２２のＲＦをＯＦＦし（Ｓ４４２）、Ｔ４８４において、ＮＦＣＩ／Ｆ２２のモード状態をＲ／ＷモードのみがＯＮされているモード状態に設定し（Ｓ４４４）Ｔ４８６において、ＮＦＣＩ／Ｆ２２のＲＦをＯＮする（Ｓ４４６）。
【０１２６】
なお、携帯端末７０ＤのＯＳプログラムは、通常、ＮＤＦＥ信号内にＵＲＬが記述されていることを認識すると、ブラウザプログラムを起動させて、当該ＵＲＬにアクセスする。従って、携帯端末７０Ｄは、Ｔ４７０において、ＵＲＬ３９を含むＮＤＥＦ信号を受信すると、認証アプリケーション７８をインストールするためのＵＲＬ３９にアクセスする。このために、ユーザは、ＵＲＬ３９によって示されるウェブ画面において、認証アプリケーション７８をインストールするための操作を容易に実行することができる。
【０１２７】
（第１実施例の効果）
上述のように、認証カード５０のＮＦＣＩＤ１、ＮＦＣＩＤ２、ＵＩＤは、固定的なＩＤであり、さらに、ユニークさが保証されているので、認証に適している。一方、携帯端末７０のＯＳソフトウェア７４によって準備されるＮＦＣＩＤ１又はＮＦＣＩＤ２は、ＮＦＣ通信が実行される毎に決定されるので、固定的なＩＤではなく、認証に適していない。また、ＯＳソフトウェア７４の中には、予め決められている固定的なＩＤをＮＦＣＩＤ１又はＮＦＣＩＤ２として利用する特定のＯＳソフトウェアが存在し得る。このような特定のＯＳソフトウェアは、固定的なＩＤを利用するが、当該特定のＯＳソフトウェアを有する複数の携帯端末の間で同じＩＤがＮＦＣＩＤ１又はＮＦＣＩＤ２として利用される。このようなＩＤは、ユニークさが保証されないので、やはり、認証に適していない。そこで、本実施例では、ＭＦＰ１０は、対象装置が認証カード５０であるのか携帯端末７０であるのかに応じて、認証に利用すべきＩＤを変える。即ち、ＭＦＰ１０は、図４のＳＥＮＳ信号及びＳＥＬ信号に含まれる各情報、又は、図５のＳＥＮＳＦ信号に含まれるＰＡＤ０を利用して、対象装置が認証カード５０であるのか携帯端末７０であるのかを判断する（図４のＳ２００、Ｓ２２０、Ｓ２２２、図５のＳ３００）。そして、ＭＦＰ１０は、対象装置が認証カード５０であると判断する場合には、ＮＦＣＩＤ１又はＮＦＣＩＤ２を利用した認証を実行し（図４のＳ２１２、図５のＳ３１２、図３のＳ１６２）、対象装置が携帯端末７０であると判断する場合には、Ｔ４Ｔ通信によって受信されるＮＤＥＦ領域内の生成ＩＤを利用した認証を実行する（図４のＳ２３８、図５のＳ３３８、図３のＳ１６２）。ここで、生成ＩＤは、携帯端末７０の認証アプリケーション７８によって生成される固定的かつユニークなＩＤである。このために、ＭＦＰ１０は、対象装置が携帯端末７０である場合に、認証に適していないＮＦＣＩＤ１又はＮＦＣＩＤ２を利用せずに、生成ＩＤを利用した認証を適切に実行することができる。
【０１２８】
また、ＭＦＰ１０は、携帯端末７０が認証アプリケーション７８をまだインストールしていない場合（図４のＳ２３２でＮＯ、Ｓ２３６でＮＯ、図５のＳ３３２でＮＯ、３３６でＮＯ）には、ＵＲＬ供給処理（図４のＳ２４０、図５のＳ３４０、図６）を実行して、ＵＲＬ３９を携帯端末７０に送信する。ユーザは、例えばタッチパネル等を操作してＵＲＬ３９を携帯端末７０に入力しなくても、認証アプリケーション７８を容易にインストールすることができる。これにより、ユーザの利便性を向上させることができる。
【０１２９】
（対応関係）
ＭＦＰ１０、認証カード５０、携帯端末７０が、それぞれ、「通信装置」、「第１種の装置」、「第２種の装置」の一例である。ＮＦＣＩ／Ｆ２２が、「無線インターフェース」の一例である認証アプリケーション７８、ＵＲＬ３９が、それぞれ、「所定のアプリケーションソフトウェア」、「位置情報」の一例である。図４の各信号１００〜１２２及び図５の各信号１４０〜１６２が、「１個以上の信号」の一例である。図４では、ＳＥＮＳ信号１００、ＳＤＤ信号１０２、ＳＥＬ信号１０４が、「第１の信号」の一例である。図５では、ＳＥＮＳＦ信号１４０が、「第１の信号」の一例である。Ｆｏｒｍａｔ信号１２０、１６０及びＮＤＥＦ信号１２２、１６２が、「第２の信号」の一例である。タイプＡ又はＦが「第１の通信タイプ」の一例である。タイプＦ又はＡが、「第２の通信タイプ」の一例である。アクティビティ層、Ｔ１Ｔ〜Ｔ５Ｔ層が、それぞれ、「第１の通信レイヤ」、「第２の通信レイヤ」の一例である。
【０１３０】
ＮＦＣＩＤ１、ＮＦＣＩＤ２、及び、ＵＩＤが、「第１の識別情報」の一例であり、生成ＩＤが、「第２の識別情報」の一例である。ＳＥＮＳ信号１００、ＳＥＬ信号１０４、及び、ＳＥＮＳＦ信号１４０内の各情報が、「属性情報」の一例である。Ｆｏｒｍａｔ信号１２０、１６０内の情報が、「第１の情報」の一例である。ＮＤＥＦ信号１２２、１６２内の情報が、「第２の情報」の一例である。ISO/IEC14443−4が、「所定規格に準拠した特定規格」の一例である。ＳＥＬ信号１０４内の第６ビットが、「第３の情報」の一例である。ＳＥＬ信号１０４内の第６ビット及びＳＥＮＳＦ信号１４０の第１バイトが、「第４の情報」の一例である。Ｒ／Ｗモード、Ｐ２Ｐモードが、それぞれ、「第１の通信モード」、「第２の通信モード」の一例である。認証フラグ３８が「ＯＦＦ」である状態、「ＯＮ」である状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。
【０１３１】
図４のＳ２００、２２０、２２２、及び、図５のＳ３００が、「第１の判断部」が実行する処理の一例である。図４のＳ２３２、２３６、及び、図５のＳ３３２、３３６が、「第２の判断部」が実行する処理の一例である。図４のＳ２１２又は図５のＳ３１２を経た図３のＳ１４２又はＳ１６２が、「第１の処理実行部」が実行する処理の一例である。図４のＳ２３８又は図５のＳ３３８を経た図３のＳ１４２又はＳ１６２が、「第２の処理実行部」が実行する処理の一例である。
【０１３２】
（第２実施例）
第１実施例と異なる点を中心に説明する。第２実施例では、ＣＰＵ３２は、図６に代えて、図１１のＵＲＬ供給処理を実行する。
【０１３３】
（ＵＲＬ供給処理：図１１）
Ｓ５００、Ｓ５０２は、図６のＳ４００、Ｓ４０２と同様である。Ｓ５０４において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＲ／ＷモードがＯＦＦされており、ＣＥモードがＯＮされているモード状態に設定する。Ｓ５０６において、ＣＰＵ３２は、ＵＲＬ３９をＮＦＣＩ／Ｆ２２に供給する。この結果、ＮＦＣＩ／Ｆ２２は、ＮＦＣＩ／Ｆ２２内のメモリ（図示省略）にＵＲＬ３９を記憶させる。Ｓ５０８は、図６のＳ４０６と同様である。
【０１３４】
ＮＦＣＩ／Ｆ２２においてＣＥモードのみがＯＮされている場合には、ＮＦＣＩ／Ｆ２２は、Ｐｏｌｌｉｎｇ信号を送信不可能である。この場合、ＮＦＣＩ／Ｆ２２は、携帯端末７０から受信されるＰｏｌｌｉｎｇ信号に対する応答信号を送信することによって、ＮＦＣＩ／Ｆ２２がＣＥモードで動作すると共にＮＦＣＩ／Ｆ７２がＲ／Ｗモードで動作するＣＥ−Ｒ／Ｗ通信リンクを確立することができる。
【０１３５】
Ｓ５１０、Ｓ５１２、Ｓ５２０は、図６のＳ４１０、Ｓ４１２、Ｓ４２０と同様である。Ｓ５３０において、ＣＰＵ３２は、ＣＥ−Ｒ／Ｗ通信リンクを介して、携帯端末７０からＲｅａｄ信号を受信することを監視する。ＮＦＣＩ／Ｆ２２は、Ｒｅａｄ信号を受信する場合に、Ｓ５０６で記憶されたＵＲＬ３９を携帯端末７０に送信し、次いで、Ｒｅａｄ信号を受信したことを示す情報をＣＰＵ３２に供給する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から当該情報を取得する場合に、Ｓ５３０でＹＥＳと判断し、Ｓ５４０に進む。
【０１３６】
Ｓ５４０において、ＣＰＵ３２は、携帯端末７０からＤｅａｃｔｉｖａｔｅ信号を受信することを監視する。ＮＦＣＩ／Ｆ２２は、Ｄｅａｃｔｉｖａｔｅ信号を受信する場合に、当該信号を受信したことを示す情報をＣＰＵ３２に供給する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から当該情報を取得する場合に、Ｓ５４０でＹＥＳと判断し、Ｓ５４２に進む。Ｓ５４２〜Ｓ５４６は、図６のＳ４４２〜４４６と同様である。
【０１３７】
（ケースＨ：図１２）
続いて、図１２を参照して、本実施例で実現されるケースＨについて説明する。Ｔ５２８〜Ｔ５４２は、図１０のＴ４２８〜Ｔ４４２と同様である。
【０１３８】
ＭＦＰ１０は、Ｔ５４４において、ＮＦＣＩ／Ｆ２２のモード状態をＣＥモードのみがＯＮされているモード状態に設定し（図１１のＳ５０４）、Ｔ５４６において、ＵＲＬ３９をＮＦＣＩ／Ｆ２２に供給し（Ｓ５０６）、Ｔ５４８において、ＲＦをＯＮする（Ｓ５０８）。
【０１３９】
ユーザが携帯端末７０ＤをＭＦＰ１０に近づけると、Ｔ５６０において、ＮＦＣＩ／Ｆ２２とＮＦＣＩ／Ｆ７２との間にＣＥ−Ｒ／Ｗ通信リンクが確立される。そして、ＭＦＰ１０は、Ｔ５６２において、携帯端末７０ＤからＲｅａｄ信号を受信し（Ｓ５３０でＹＥＳ）、Ｔ５７０において、ＵＲＬ３９を含むＮＤＥＦ信号を携帯端末７０Ｄに送信し、Ｔ５８０において、携帯端末７０ＤからＤｅａｃｔｉｖａｔｅ信号を受信する（Ｓ５４０でＹＥＳ）。その後のＴ５８２〜Ｔ５８６の処理は、図１０のＴ４８２〜４８６と同様である。
【０１４０】
（第２実施例の効果）
本実施例でも、ＭＦＰ１０がＵＲＬ３９を携帯端末７０に送信することができるので、ユーザの利便性が向上する。また、図１１のＳ５０４において、仮に、Ｒ／ＷモードのみがＯＮされる比較例の構成を採用することを想定する。この場合、ＭＦＰ１０がＲ／Ｗモードで動作すると共に携帯端末７０がＣＥモードで動作するＲ／Ｗ−ＣＥ通信リンクが確立され、ＭＦＰ１０は、Ｗｒｉｔｅ信号を携帯端末７０に送信することによって、ＵＲＬ３９を携帯端末７０に送信することができる。ただし、比較例の構成では、ＭＦＰ１０は、Ｗｒｉｔｅ信号を携帯端末７０に送信する前に、Ｗｒｉｔｅ信号に応じた動作を実行可能であるのか否かを携帯端末７０に問い合わせる必要がある。これに対し、本実施例では、ＭＦＰ１０は、ＣＥモードのみをＯＮしてＲｅａｄ信号を受信する構成を採用しているので、Ｗｒｉｔｅ信号に関する上記の問合せを実行せずに済む。また、ＣＥモードで動作する機器は、通常、Ｒｅａｄ信号に従った動作を実行可能であるので、携帯端末７０は、Ｒｅａｄ信号に応じた動作を実行可能であるのか否かをＭＦＰ１０に問い合わせる必要もない。本実施例によると、事前の問合せが必要ないので、ＵＲＬ３９を送信するための処理を簡単化することができる。
【０１４１】
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。上記の実施例の変形例を以下に列挙する。
【０１４２】
（変形例１）ＣＰＵ３２は、図３のＳ１１０でＹＥＳと判断する場合に、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード、Ｒ／Ｗモード、及び、ＣＥモードの全てがＯＮされているモード状態に変更してもよい。この状態では、ＣＰＵ３２は、図２と同様に、印刷機能を実行し得る。また、ＣＰＵ３２は、Ｓ１２０でＹＥＳと判断する場合に、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＣＥモードがＯＦＦされており、かつ、Ｒ／ＷモードがＯＮされているモード状態に変更してもよい。この場合、ＣＰＵ３２は、対象装置からＩＤを抽出して登録するための処理（Ｓ１３０〜Ｓ１４２）を適切に実行することができる。本変形例でも、認証フラグ３８が「ＯＦＦ」である状態、「ＯＮ」である状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。別の観点では、ログイン操作後に登録ボタンが操作されていない状態、登録ボタンが操作された後の状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。また、別の変形例では、ＮＦＣＩ／Ｆ２２のモード状態は、少なくともＲ／ＷモードがＯＮされているモード状態に固定されてもよい。即ち、「モード制御部」を省略可能である。
【０１４３】
（変形例２）図４のＳ２２０、Ｓ２２２、及び、Ｓ２３０の処理の順番が異なっていてもよい。例えば、ＣＰＵ３２は、Ｓ２２２の処理を最初に実行し、Ｓ２２２でＮＯの場合に、Ｓ２２０及びＳ２３０の処理を実行してもよい。
【０１４４】
（変形例３）例えば、Mifare Desfire系の認証カードが利用されない環境下では、図４のＳ２２０及びＳ２２２を省略して、Ｓ２００でＹＥＳの場合に、対象装置が携帯端末であると判断されてもよい。また、例えば、Ｐ２Ｐ通信を実行不可能な携帯端末が利用されない環境下では、Ｓ２２２を省略して、Ｓ２２０でＹＥＳの場合に、対象装置が携帯端末であると判断され、Ｓ２２０でＮＯの場合に、対象装置が認証カードであると判断されてもよい。また、例えば、Mifare系の認証カードが利用されない環境下では、Ｓ２００を省略して、Ｓ２２０以降の処理が実行されてもよい。即ち、「第１の判断部」は、第３の情報を利用せずに判断してもよい。
【０１４５】
（変形例４）例えば、タイプＡに対応する対象装置が利用されない環境下では、図４の処理の全部が省略されてもよい。この場合、タイプＦに対応する図５の処理が実行される。また、例えば、タイプＦに対応する対象装置が利用されない環境下では、図５の処理の全部が省略されてもよい。この場合、タイプＡに対応する図４の処理が実行される。
【０１４６】
（変形例５）図４のＳ２３０のＴ４Ｔ通信で受信される信号内の所定領域に生成ＩＤが記述されていてもよい。この場合、ＣＰＵ３２は、Ｓ２３０を実行した後に、上記の所定領域に生成ＩＤが記述されているのか否かを判断することによって、携帯端末が所定のアプリケーションソフトウェアに従って生成ＩＤを送信可能であるのか否かを判断してもよい。従って、Ｓ２３２〜Ｓ２３６を省略可能である。即ち、「第２の判断部」は、第１の情報及び第２の情報を利用せずに判断してもよい。
【０１４７】
（変形例６）ＣＰＵ３２は、図４のＳ２３４及び図５のＳ３３４において、生成ＩＤに代えて、ユーザ情報（ユーザ名及びパスワード）を受信してもよい。例えば、ユーザが認証アプリケーション７８を起動すると、ユーザ情報を入力可能な画面が携帯端末７０に表示される。ユーザがユーザテーブル４０に登録されているユーザ情報を入力する場合に、携帯端末７０は入力されたユーザ情報を記憶する。ユーザが携帯端末７０をＭＦＰ１０に近づけて、ＭＦＰ１０と携帯端末７０とのＮＦＣ通信が確立されると、Ｓ２３４及びＳ３３４において、ＣＰＵ３２は、携帯端末７０からユーザ情報を含むＮＤＥＦ信号を受信する。この場合、Ｓ２３８及びＳ３３８において、ＣＰＵ３２は、ＮＤＥＦ信号からユーザ情報を抽出し、当該ユーザ情報とユーザテーブル４０に登録されているユーザ情報とが一致する場合に、認証が成功したと判断する。本変形例では、ＣＰＵ３２は、認証ＩＤの登録を実行する必要が無い。従って、図３のＳ１２０、Ｓ１３０〜Ｓ１４４の処理を省略することができる。
【０１４８】
（変形例７）ユーザテーブル４０への認証ＩＤの登録は、管理者が操作部１２を操作することによって実行されてもよい。この場合、図３のＳ１２０、Ｓ１３０〜Ｓ１４４を省略可能である。
【０１４９】
（変形例８）例えば、対象装置がタイプＡに対応する携帯端末７０である場合に、図３のＳ１３０又はＳ１５０において受信される１個の応答信号が、ＮＦＣＩＤ１のデータサイズを示す情報と、ＮＦＣＩＤ１と、ＩＳＯ＿ＤＥＰ及びＮＦＣ＿ＤＥＰをサポートしているか否かの情報と、Ｆｏｒｍａｔ情報と、ＮＤＥＦ領域と、の全てを含んでいてもよい。この場合、上記の１個の応答信号のみが、「１個以上の信号」の一例である。また、例えば、図８において、ＭＦＰ１０は、タイプＡの各応答信号よりも先にＴ４Ｔの応答信号を受信してもよい。即ち、「第２の信号」は、「第１の信号」よりも先に受信されてもよい。一般的に言うと、「第１の信号」及び「第２の信号」を受信する順番は限定されない。
【０１５０】
（変形例９）図２のＳ１０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、ＣＥモードのみがＯＮされているモード状態に設定してもよい。この場合、Ｓ１２において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２がＣＥモードで動作すると共にＮＦＣＩ／Ｆ７２がＲ／Ｗモードで動作するＣＥ−Ｒ／Ｗ通信リンクが確立されることを監視する。Ｓ１４〜Ｓ２４の処理は、上記の実施例と同様である。ただし、Ｓ１６の結果として、ＮＦＣＩ／Ｆ２２は、ＣＥ−Ｒ／Ｗ通信リンクを介して、無線設定を携帯端末７０に送信する。一般的に言うと、「第３のモード状態」は、Ｐ２Ｐモード及びＣＥモードのうちの少なくとも一方のモードが有効化されている状態であればよい。
【０１５１】
（変形例１０）ユーザテーブル４０は、ショートカット機能を示すショートカット情報を格納していてもよい。ショートカット情報は、例えば、スキャン設定、スキャンデータの宛先等を示す情報であってもよい。この場合、ＣＰＵ３２は、対象装置の認証が成功した場合（Ｓ１６２）に、認証が成功した認証ＩＤに対応するショートカット情報に含まれるスキャン設定に従ったスキャンを実行し、その後、ショートカット情報に含まれる宛先にスキャンデータを送信する。
【０１５２】
（変形例１１）「無線インターフェース」は、ＮＦＣ通信を実行するためのＩ／Ｆでなくてもよく、例えば、ＢｌｕｅＴｏｏｔｈ（登録商標）、ＴｒａｎｓｆｅｒＪｅｔ（登録商標）等の他の通信方式に従った無線通信を実行するためのＩ／Ｆであってもよい。
【０１５３】
（変形例１２）「通信装置」は、複数の機能を実行可能なＭＦＰ１０でなくてもよく、印刷機能のみを実行可能な印刷装置、スキャン機能のみを実行可能なスキャナ装置等であってもよい。
【０１５４】
（変形例１３）上記の実施例では、ＭＦＰ１０のＣＰＵ３２がプログラム３６（即ちソフトウェア）を実行することによって、図２〜図６の各処理が実現される。これに代えて、図２〜図６の各処理のうちの少なくとも１つの処理は、論理回路等のハードウェアによって実現されてもよい。
【０１５５】
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【０１５６】
２：通信システム、１０：多機能機（ＭＦＰ）１２：操作部、１４：表示部、１６：印刷実行部、１８：スキャン実行部、２０：Ｗｉ−ＦｉＩ／Ｆ、２２：ＮＦＣＩ／Ｆ、３０：制御部、３２：ＣＰＵ、３４：メモリ、３６：プログラム、３８：認証フラグ、３９：ＵＲＬ、４０：ユーザテーブル、５０、５０Ａ〜５０Ｃ：認証カード、５２：ＮＦＣＩ／Ｆ、７０、７０Ａ〜７０Ｄ：携帯端末、７２：ＮＦＣＩ／Ｆ、７４：ＯＳソフトウェア、７６：印刷アプリケーション、７８：認証アプリケーション
【図１】
0006645323.tif 000002
【図２】
0006645323.tif 000003
【図３】
0006645323.tif 000004
【図４】
0006645323.tif 000005
【図５】
0006645323.tif 000006
【図６】
0006645323.tif 000007
【図７】
0006645323.tif 000008
【図８】
0006645323.tif 000009
【図９】
0006645323.tif 000010
【図１０】
0006645323.tif 000011
【図１１】
0006645323.tif 000012
【図１２】
0006645323.tif 000013