JP6658221B2 - 通信装置 - Google Patents

Description

本明細書では、対象装置の認証を実行可能な通信装置を開示する。

特許文献１には、端末とサービス提供装置と認証装置とを備えるシステムが開示されている。端末は、非接触ＩＣカードリーダを用いて、非接触ＩＣカード又は携帯電話機からチップＩＤを読取り、当該チップＩＤをサービス提供装置に送信する。サービス提供装置は、チップＩＤを含む資格認証要求を認証装置に送信する。認証装置は、チップＩＤの認証を実行して、顧客の資格の有無を示す資格認証情報をサービス提供装置に送信する。サービス提供装置は、資格認証情報に応じて端末を動作させる。

特開２０１０−１９８５０５号公報 特開２０１５−０６９４５８号公報 米国特許出願公開２０１４／０１６８６８７号公報 米国特許出願公開２０１５／００２９５３２号公報

上述したように、特許文献１には、端末が、複数種類のデバイス（即ち非接触ＩＣカード及び携帯電話機）から送信される信号内のＩＤを読取って認証を実行することが開示されている。各デバイスは、通常、異なるベンダによって製造される。このために、各デバイスから送信される信号内にＩＤを記述するためのルールは、通常、各デバイスの間で異なる。例えば、非接触ＩＣカードについては、ある信号内の第１の位置に第１のデータサイズを有するＩＤが記述される第１のルールが決められており、携帯電話機については、ある信号内の第１の位置とは異なる第２の位置に第１のデータサイズとは異なる第２のデータサイズを有するＩＤが記述される第２のルールが決められている。そして、端末は、非接触ＩＣカードが近づけられる場合には、第１のルールに従ってＩＤを読取り、携帯電話機が近づけられる場合には、第２のルールに従ってＩＤを読取る。従って、端末は、複数のルールに対応する複数のプログラムを有していなければならない。

本明細書では、複数種類のデバイスから共通のルールに従った識別情報を取得して認証を実行し得る通信装置を開示する。

本明細書によって開示される通信装置は、所定規格に従った無線通信を実行するための無線インターフェースと、対象装置から、無線インターフェースを介して、所定規格で定められている２種以上の変調方式に対応する２種以上の信号のうちのいずれかの信号を受信する第１の受信部と、対象装置から２種以上の信号のうちのいずれかの信号が受信されても、対象装置から、無線インターフェースを介して、フォーマット情報を受信する第２の受信部であって、フォーマット情報は、対象装置が、所定規格で定められている所定のフォーマットであって、信号内に情報を記述するための所定のフォーマットをサポートしているのか否かを示す情報を含む、第２の受信部と、フォーマット情報が、対象装置が所定のフォーマットをサポートしていることを示す場合に、対象装置から、無線インターフェースを介して、所定のフォーマットで記述されている情報を含む特定の信号を受信する第３の受信部であって、フォーマット情報が、対象装置が所定のフォーマットをサポートしていないことを示す場合に、特定の信号は受信されない、第３の受信部と、所定のアプリケーションソフトウェアに関連する関連情報が特定の信号に含まれるのか否かを判断する第１の判断部と、関連情報が特定の信号に含まれると判断される場合に、特定の信号に含まれる第１の識別情報を利用して、対象装置の認証を実行する第１の認証部であって、関連情報が特定の信号に含まれないと判断される場合に、特定の信号に含まれる情報を利用した認証は実行されない、第１の認証部と、を備える。

上記の構成によると、通信装置は、複数種類のデバイスのいずれかである対象装置から、２種以上の変調方式に対応する２種以上の信号のうち、当該対象装置によってサポートされている変調方式に対応する信号を受信する。そして、通信装置は、２種以上の信号のいずれかの信号が受信されても、即ち、対象装置の種類に関わらず、対象装置が所定のフォーマットをサポートしている場合には、対象装置から、所定のフォーマットで記述されている情報を含む特定の信号を受信する。当該特定の信号は、所定のアプリケーションソフトウェアに関連する関連情報を含む場合に、さらに、第１の識別情報を含む。このために、通信装置は、複数種類のデバイスから共通のルールに従った第１の識別情報を取得することができ、第１の識別情報を利用して対象装置の認証を適切に実行し得る。

上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。また、上記の通信装置と対象装置とを備える通信システムも、新規で有用である。

通信システムの構成を示す。 認証フラグＯＦＦ時処理のフローチャートを示す。 認証フラグＯＮ時処理のフローチャートを示す。 ＩＤ抽出処理のフローチャートを示す。 通信プロトコルのサポートの有無を示すテーブルである。 認証が実行されるケースのシーケンス図を示す。 認証が実行されないケースのシーケンス図を示す。 第２実施例において装置ＩＤを認証に利用可能か否かを判断するためのテーブルである。 各通信タイプに対応する各応答信号を示す。 第２実施例及び第３実施例のシーケンス図を示す。

（通信システム２の構成；図１）
図１に示すように、通信システム２は、多機能機１０（以下では「ＭＦＰ（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」に従った通信である。

次いで、Ｗｉ−ＦｉＩ／Ｆ２０とＮＦＣＩ／Ｆ２２との間の相違点を説明しておく。Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信の通信速度（例えば最大の通信速度が１１〜６００Ｍｂｐｓ）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信の通信速度（例えば最大の通信速度が１００〜４２４Ｋｂｐｓ）よりも速い。また、Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信における搬送波の周波数（例えば２．４ＧＨｚ帯又は５．０ＧＨｚ帯）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信における搬送波の周波数（例えば１３．５６ＭＨｚ帯）とは異なる。また、Ｗｉ−ＦｉＩ／Ｆ２０を介したＷｉ−Ｆｉ通信を実行可能な最大の距離（例えば最大で約１００ｍ）は、ＮＦＣＩ／Ｆ２２を介したＮＦＣ通信を実行可能な最大の距離（例えば最大で約１０ｃｍ）よりも大きい。

制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に格納されているプログラム３６に従って、様々な処理を実行する。メモリ３４は、揮発性メモリ、不揮発性メモリ等によって構成される。また、メモリ３４は、認証フラグ３８及びユーザテーブル４０を格納する。認証フラグ３８は、ユーザ情報を利用した認証を実行することを意味する「ＯＮ」と、当該認証を実行しないことを意味する「ＯＦＦ」と、のどちらかの値を示す。認証フラグ３８は、ＭＦＰ１０の管理者によって「ＯＮ」又は「ＯＦＦ」に設定される。

ユーザテーブル４０では、ユーザ名と、パスワードと、認証ＩＤと、印刷許可情報と、スキャン許可情報と、が対応付けられる。ユーザ名、パスワード、印刷許可情報、及び、スキャン許可情報は、例えば、ＭＦＰ１０の管理者が、操作部１２を操作することによって、又は、端末装置からＭＦＰ１０にアクセスすることによって、ユーザテーブル４０に登録される。印刷許可情報、スキャン許可情報は、それぞれ、印刷機能、スキャン機能をユーザに許可するのか否かを示す。各許可情報の「ＯＫ」は、機能の利用を許可することを示し、「ＮＧ」は、機能の利用を許可しないことを示す。認証ＩＤは、認証カード５０又は携帯端末７０を識別するための識別情報であり、後述する処理によって認証カード５０又は携帯端末７０から抽出されて登録される。ここで、認証ＩＤを一例として含む「識別情報」という用語は、１個の装置に固有（即ちユニーク）な情報であってもよいし、装置内の構成要素（例えばソフトウェア）を識別する情報であってもよいし、装置のモデルを示す情報であってもよい。即ち、識別情報は、１個の装置そのものを識別する情報に限定されず、ある概念を識別する情報も含む。なお、変形例では、ユーザテーブル４０は、ＭＦＰ１０とは異なる外部装置のメモリ内に格納されてもよい。この場合、ＭＦＰ１０は、当該外部装置と通信して、ユーザテーブル４０内の情報を利用することができる。

（認証カード５０の構成）
認証カード５０は、ＮＦＣタグであるＮＦＣＩ／Ｆ５２を備える。認証カード５０は、通常、ＯＳソフトウェア及びアプリケーションを有さない。ＮＦＣＩ／Ｆ５２は、タイプＡ、Ｂ、Ｆ、及び、Ｖのいずれか１つのタイプに対応する（換言すると、１つのタイプのみをサポートしている）。タイプＡに対応するＮＦＣＩ／Ｆ５２は、通信規格「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の略）を起動して、無線ネットワークの親局として動作してもよい。Ｓ１４において、ＣＰＵ３２は、さらに、当該無線ネットワークで利用されるべき無線設定（即ちＳＳＩＤ及びパスワード）を決定する。ＳＳＩＤは、当該無線ネットワークを識別するための識別子である。パスワードは、当該無線ネットワークにおいて認証及び暗号化に利用される文字列である。ＣＰＵ３２は、例えば、予め決められている文字列を取得することによって、又は、ランダムに文字列を抽出することによって、無線設定を決定する。

Ｓ１６において、ＣＰＵ３２は、Ｓ１４で決定された無線設定をＮＦＣＩ／Ｆ２２に供給する。この結果、ＮＦＣＩ／Ｆ２２は、Ｐ２Ｐ通信リンクを介して、無線設定を携帯端末７０に送信する。これにより、携帯端末７０が無線設定を受信し、携帯端末７０が印刷アプリケーション７６を備えている場合には、携帯端末７０において無線設定が利用される。そして、Ｗｉ−Ｆｉ方式に従ったＷｉ−Ｆｉ接続を確立するための様々な信号が、携帯端末７０からＭＦＰ１０に送信される。

Ｓ１８において、ＣＰＵ３２は、Ｗｉ−ＦｉＩ／Ｆ２０を介して、携帯端末７０とのＷｉ−Ｆｉ接続を確立する。具体的には、ＣＰＵ３２は、上記のＳＳＩＤを含む信号、パスワードを含む信号等を受信し、パスワードの認証が成功すると、Ｗｉ−Ｆｉ接続を確立する。

Ｓ２０において、ＣＰＵ３２は、Ｓ１８で確立されたＷｉ−Ｆｉ接続を利用して、Ｗｉ−ＦｉＩ／Ｆ２０を介して、携帯端末７０から印刷対象の画像を表わす印刷データを受信する。上述のように、Ｗｉ−Ｆｉ通信の通信速度は、ＮＦＣ通信の通信速度よりも速い。このために、ＮＦＣ通信を利用して印刷データを通信する構成と比べると、ＭＦＰ１０は、携帯端末７０から印刷データを迅速に受信することができる。

Ｓ２２において、ＣＰＵ３２は、Ｓ２０で受信された印刷データを印刷実行部１６に供給して、印刷実行部１６に印刷を実行させる。なお、変形例では、ＣＰＵ３２は、Ｓ２０及びＳ２２に代えて、スキャン実行部１８に原稿のスキャンを実行させ、Ｗｉ−Ｆｉ接続を利用して、Ｗｉ−ＦｉＩ／Ｆ２０を介して、スキャンデータを携帯端末７０に送信してもよい。このように、認証フラグ３８が「ＯＦＦ」に設定されている状況では、ＭＦＰ１０は、ユーザ情報の認証を実行することなく、いずれのユーザから指示を受けても、印刷機能及びスキャン機能を実行する（Ｓ２０、Ｓ２２）。

Ｓ２４において、ＣＰＵ３２は、Ｓ１８で確立されたＷｉ−Ｆｉ接続を切断し、さらに、ＭＦＰ１０の動作状態をＧ／Ｏ状態からデバイス状態に移行させる。Ｓ２４が終了すると、Ｓ１２に戻る。

（認証フラグＯＮ時処理；図３）
続いて、図３を参照して、認証フラグ３８が「ＯＮ」に設定されている場合に、ＣＰＵ３２によって実行される処理について説明する。認証フラグ３８を「ＯＦＦ」から「ＯＮ」に変更するための操作が操作部１２に実行された際に、図３の処理が開始される。なお、以下では、認証カード５０及び携帯端末７０を総称して、「対象装置」と呼ぶ場合がある。

Ｓ１００において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＣＥモードがＯＦＦされていると共にＲ／ＷモードがＯＮされているモード状態に設定する。この場合、ＮＦＣＩ／Ｆ２２は、上記の３つのモードのうちのＲ／Ｗモードのみで動作可能である。認証フラグ３８が「ＯＮ」に設定されている状況では、対象装置のＩＤの登録又は認証が実行される。ここで、対象装置が認証カード５０である場合には、認証カード５０（即ちＮＦＣタグであるＮＦＣＩ／Ｆ５２）からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモード（より詳しくはＲｅａｄｅｒモード）で動作する必要がある。また、携帯端末７０は、認証アプリケーション７８に従って、ＮＦＣ通信を利用して、ＩＤを送信可能である。ここで、認証アプリケーション７８は、ＮＦＣＩ／Ｆ７２がＣＥモードで動作する状態でＩＤを送信するようにプログラムされている。従って、対象装置が携帯端末７０である場合にも、携帯端末７０（即ちＮＦＣフォーラムデバイスであるＮＦＣＩ／Ｆ７２）からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモード（より詳しくはＲｅａｄｅｒモード）で動作する必要がある。このように、対象装置からＩＤを受信するためには、ＮＦＣＩ／Ｆ２２がＲ／Ｗモードで動作する必要があるので、Ｓ１００において、ＮＦＣＩ／Ｆ２２がＲ／Ｗモードのみで動作可能なモード状態に設定される。

Ｓ１００において、ＣＰＵ３２は、さらに、タイプＡ、Ｂ、Ｆ、及び、Ｖに対応する４種類のＰｏｌｌｉｎｇ信号の送信をＮＦＣＩ／Ｆ２２に指示する。この結果、ＮＦＣＩ／Ｆ２２は、各タイプに対応する各Ｐｏｌｌｉｎｇ信号を順次送信することを繰り返す。

Ｓ１１０において、ＣＰＵ３２は、ユーザによってログイン操作が操作部１２に実行されることを監視する。ＣＰＵ３２は、ユーザテーブル４０に登録されているユーザ名及びパスワードの組合せが操作部１２に入力される場合に、Ｓ１１０でＹＥＳと判断して、Ｓ１２０に進む。

Ｓ１２０において、ＣＰＵ３２は、認証ＩＤをユーザテーブル４０に登録するための登録ボタンが操作されたのか否かを判断する。ＣＰＵ３２は、登録ボタンが操作されたと判断する場合（Ｓ１２０でＹＥＳ）に、Ｓ１３０に進む。一方、ＣＰＵ３２は、登録ボタンとは異なるボタンが操作されたと判断する場合（Ｓ１２０でＮＯ）に、Ｓ１２２において、当該ボタンに対応する処理を実行する。例えば、ＣＰＵ３２は、外部サーバから印刷データを受信して印刷を実行するためのボタンが操作される場合には、Ｓ１１０で入力されたユーザ情報（即ちユーザ名及びパスワード）に対応する印刷許可情報が「ＯＫ」であるのか否かを判断する。そして、ＣＰＵ３２は、「ＯＫ」であると判断する場合には、印刷データを受信して、当該印刷データを印刷実行部１６に供給する。また、例えば、ＣＰＵ３２は、スキャンを実行するためのボタンが操作される場合には、Ｓ１１０で入力されたユーザ情報に対応するスキャン許可情報が「ＯＫ」であるのか否かを判断する。そして、ＣＰＵ３２は、「ＯＫ」であると判断する場合には、スキャン実行部１８にスキャンを実行させる。Ｓ１２２が終了すると、Ｓ１１０に戻る。なお、変形例では、ＣＰＵ３２は、Ｓ１２２が終了した後に、ログイン操作が再び実行されなくても、Ｓ１２２の処理を実行するための操作を受け付けてもよい。この状態は、ユーザによってログアウト操作が実行されるまで継続されてもよい。

Ｓ１３０において、ＣＰＵ３２は、対象装置から、ＮＦＣＩ／Ｆ２２を介して、Ｐｏｌｌｉｎｇ信号に対する応答信号を受信することを監視する。上述のように、ＮＦＣＩ／Ｆ２２は、各タイプに対応する各Ｐｏｌｌｉｎｇ信号を順次送信することを繰り返す。ＮＦＣＩ／Ｆ２２は、例えば、タイプＡに対応するＰｏｌｌｉｎｇ信号を送信した際に、当該信号に対する応答信号を受信する場合に、タイプＡを示す情報を制御部３０に供給する。同様に、ＮＦＣＩ／Ｆ２２は、他の通信タイプに対応する応答信号を受信する場合に、当該タイプを示す情報を制御部３０に供給する。ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から上記の情報を取得する場合に、Ｓ１３０でＹＥＳと判断して、Ｓ１３２に進む。上述したように、タイプＡでは変調方式「ＡＳＫ１００％」が利用され、タイプＢ又はＦでは変調方式「ＡＳＫ１０％」が利用される。従って、４種類のＰｏｌｌｉｎｇ信号のうちの少なくとも２種類のＰｏｌｌｉｎｇ信号では、変調方式が異なる。従って、Ｓ１３０（又は後述のＳ１５０）で受信される応答信号は、２種以上の変調方式に対応する２種以上の応答信号のうちのいずれかの応答信号である。

Ｓ１３２において、ＣＰＵ３２は、Ｓ１３０で取得された情報に基づいて、応答信号を受信するための通信タイプを特定する。そして、Ｓ１３４において、ＣＰＵ３２は、ＩＤ抽出処理（図４参照）を実行する。ＮＦＣＩ／Ｆ２２がＲ／Ｗモードのみで動作しているので、ＣＰＵ３２は、Ｒｅａｄｅｒとして機能することができ、この結果、対象装置から信号を受信して、当該信号内のＩＤを読み出す（即ち抽出する）ことができる。

Ｓ１４０において、ＣＰＵ３２は、ＩＤの抽出が成功したのか否かを判断する。ＣＰＵ３２は、ＩＤの抽出が成功した場合（例えば図４の「正常ＥＮＤ」参照）には、Ｓ１４０でＹＥＳと判断し、Ｓ１４２において、Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤとして、Ｓ１３４で抽出されたＩＤをユーザテーブル４０に登録する。Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤが既に登録されている場合には、Ｓ１４２において、ＣＰＵ３２は、ユーザ情報に対応する認証ＩＤとして、対象装置のＩＤを上書きして登録する。なお、変形例では、ＣＰＵ３２は、Ｓ１１０で入力されたユーザ情報に対応する認証ＩＤが既に登録されている場合には、当該ユーザ情報と、対象装置のＩＤと、が対応付けられている新たな情報をユーザテーブル４０に新たに登録してもよい。即ち、この場合、１つのユーザ情報に対して複数の認証ＩＤが登録される。

一方、ＣＰＵ３２は、ＩＤの抽出が失敗した場合（例えば図４の「エラーＥＮＤ」参照）には、Ｓ１４０でＮＯと判断し、Ｓ１４４において、認証ＩＤの登録を実行不可能であることを示すエラー画面を表示部１４に表示させる。これにより、ユーザは、認証ＩＤの登録が失敗したことを知ることができる。Ｓ１４２又はＳ１４４が終了すると、Ｓ１１０に戻る。

また、Ｓ１５０において、ＣＰＵ３２は、対象装置から、ＮＦＣＩ／Ｆ２２を介して、Ｐｏｌｌｉｎｇ信号に対する応答信号を受信することを監視する。Ｓ１５０は、Ｓ１３０と同様である。また、Ｓ１５０でＹＥＳの場合に実行されるＳ１５２、Ｓ１５４、及び、Ｓ１６０は、Ｓ１３２、Ｓ１３４、及び、Ｓ１４０と同様である。

Ｓ１６２において、ＣＰＵ３２は、Ｓ１５４で抽出されたＩＤの認証、即ち、対象装置の認証を実行する。ＣＰＵ３２は、抽出済みのＩＤに一致する認証ＩＤがユーザテーブル４０に登録されている場合に、認証が成功したと判断する。この場合、ＣＰＵ３２は、Ｓ１２２で説明した処理と同様に、ユーザからの指示に応じて、ユーザに許可されている機能を実行する。ここで、ＣＰＵ３２は、例えば、ユーザに許可されている機能のリストを示す画面を表示部１４に表示させて、当該リストから機能を選択するための指示を受け付けてもよい。ユーザは、対象装置の認証をＭＦＰ１０に実行させることにより、ログイン操作を実行しなくても、ＭＦＰ１０に機能を実行させることができる。なお、ＣＰＵ３２は、対象装置のＩＤに一致する認証ＩＤがユーザテーブル４０に登録されていない場合には、認証が失敗したと判断し、例えばエラー画面を表示部１４に表示させて、Ｓ１１０に戻る。Ｓ１３６が終了すると、Ｓ１０２に戻る。なお、変形例では、ＣＰＵ３２は、Ｓ１６２が終了した後に、認証が再び実行されなくても、ユーザからの指示に応じた処理を実行するための操作を受け付けてもよい。この状態は、ユーザによってログアウト操作が実行されるまで継続されてもよい。

一方、ＣＰＵ３２は、ＩＤの抽出が失敗した場合には、Ｓ１６０でＮＯと判断し、Ｓ１６４において、ＩＤの認証（即ち対象装置の認証）を実行不可能であることを示すエラー画面を表示部１４に表示させる。これにより、ユーザは、認証が失敗したことを知ることができる。この場合、ＣＰＵ３２は、印刷機能及びスキャン機能を実行しない。Ｓ１６２又はＳ１６４が終了すると、Ｓ１１０に戻る。なお、変形例では、エラー画面の表示（即ちＳ１４４及びＳ１６４）に代えて、エラーを示す音声が出力されてもよいし、エラーを示す画像が印刷されてもよい。

（ＩＤ抽出処理；図４）
続いて、図４を参照して、図３のＳ１３４又はＳ１５４で実行される処理の内容を説明する。処理の内容を説明する前に、ＮＦＣ通信の通信レイヤについて説明しておく。ＮＦＣ通信の通信レイヤは、最下層であるアナログ層と、アナログ層の上位層であるデジタルプロトコル層と、デジタルプロトコル層の上位層であるアクティビティ層と、アクティビティ層の上位層であるＴ１Ｔ〜Ｔ５Ｔ層と、を含む。図３のＳ１３０、Ｓ１５０の応答信号は、Ｔ１Ｔ〜Ｔ５Ｔ層以上の通信レイヤが利用されずに、アクティビティ層以下の通信レイヤが利用されて通信される。一方、後述の図４のＳ２１０及びＳ２２０の各信号は、Ｔ１Ｔ〜Ｔ５Ｔ層の通信レイヤが利用されて通信される。

Ｓ２００において、ＣＰＵ３２は、図３のＳ１３０又はＳ１５０で受信済みの応答信号を利用して、対象装置が、Ｔ１Ｔ〜Ｔ５Ｔ層の通信を実行可能であるのか否か、即ち、ＮＦＣ規格で定められているＴ１Ｔ〜Ｔ５Ｔの通信プロトコルのいずれかをサポートしているのか否かを判断する。具体的には、ＣＰＵ３２は、Ｓ１３２で特定された通信タイプと図５のテーブルとに基づいて、判断を実行する。

図５に示されるように、特定済みの通信タイプがタイプＡである場合には、ＣＰＵ３２は、応答信号に含まれるＳＥＬ（SEL_RES Responseの略）信号内の第３ビット及び第６ビットの情報に基づいて、判断を実行する。具体的には、ＣＰＵ３２は、ＳＥＬ信号内の第３ビットがＯＮを示す場合には、ＳＥＬ信号内の第６ビットの情報に関わらず、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断する。なお、応答信号に含まれるＳＥＮＳ（SENS_RES Responseの略）信号は、対象装置がＴ１Ｔをサポートしているのか否かを示すＴ１Ｔサポート情報を含み得る。ＣＰＵ３２は、ＳＥＬ信号内の第３ビットがＯＮを示し、かつ、ＳＥＮＳ信号内のＴ１Ｔサポート情報がＯＦＦを示す場合に、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断してもよい。また、ＣＰＵ３２は、ＳＥＬ信号内の第３ビットがＯＦＦを示す場合には、ＳＥＬ信号内の第６ビットがＯＮを示していれば、対象装置がＴ４Ｔをサポートしていると判断し、ＳＥＬ信号内の第６ビットがＯＦＦを示していれば、対象装置がＴ２Ｔをサポートしていると判断する。

特定済みの通信タイプがタイプＢである場合には、ＣＰＵ３２は、応答信号に含まれるＳＥＮＳＢ（SENSB_RES Responseの略）信号が、Ｔ４Ｔをサポートしていることを示すサポート情報を含むのか否かを判断する。ＣＰＵ３２は、ＳＥＮＳＢ信号がサポート情報を含む場合には、対象装置がＴ４Ｔをサポートしていると判断し、ＳＥＮＳＢ信号がサポート情報を含まない場合には、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断する。特定済みの通信タイプがタイプＦである場合には、ＳＥＮＳＢ信号に代えて、応答信号に含まれるＳＥＮＳＦ（SENSF_RES Responseの略）信号が利用される点と、Ｔ４Ｔをサポートしていることを示すサポート情報に代えて、Ｔ３Ｔをサポートしていることを示すサポート情報が利用される点を、を除くと、タイプＢの場合と同様である。

また、特定済みの通信タイプがタイプＶである場合には、ＣＰＵ３２は、応答信号に含まれるＩｎｖｅｎｔｏｒｙ信号を解釈可能であるのか否かを判断する。ＣＰＵ３２は、Ｉｎｖｅｎｔｏｒｙ信号を解釈可能である場合には、対象装置がＴ５Ｔをサポートしていると判断し、Ｉｎｖｅｎｔｏｒｙ信号を解釈不可能である場合には、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断する。

図４のＳ２００では、ＣＰＵ３２は、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれかの通信プロトコルをサポートしていると判断する場合（Ｓ２００でＹＥＳ）には、Ｓ２１０に進む。一方、ＣＰＵ３２は、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断する場合（Ｓ２００でＮＯ）には、Ｓ２１０及びＳ２２０の各信号を受信不可能であるので、エラーＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＮＯと判断される。

Ｓ２１０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｓ２００で特定された通信プロトコルを利用した通信、即ち、Ｔ１Ｔ〜Ｔ５Ｔ層のいずれかの通信レイヤを利用した通信（以下では「上位層通信」と呼ぶ）を、対象装置と実行する。ＣＰＵ３２は、上位層通信において、要求信号を対象装置に送信して、対象装置から応答信号を受信する。当該応答信号は、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号を含む。Ｆｏｒｍａｔ情報は、対象装置がＮＤＥＦ（NFC Data Exchange Formatの略）をサポートしているのか否かを示す。対象装置は、ＮＤＥＦをサポートしている場合には、ＮＤＥＦ領域を含むＮＤＥＦ信号の通信を実行可能であり、ＮＤＥＦをサポートしていない場合には、ＮＤＥＦ信号の通信を実行不可能である。ＮＤＥＦ領域は、自由に情報を記述可能な領域である。例えば、対象装置が携帯端末７０である場合には、ＮＤＥＦ領域には、認証アプリケーション７８によって生成されるＩＤ（以下では「生成ＩＤ」と呼ぶ）が記述される。

生成ＩＤは、認証アプリケーション７８の初回起動時に生成される。認証アプリケーション７８は、携帯端末７０のＭＡＣアドレスから所定バイト（例えば３２バイト）を有する生成ＩＤを生成する。生成ＩＤは、２個以上の携帯端末の間で重複しないユニークなＭＡＣアドレスから生成されるために、ユニークなＩＤである。また、同じ携帯端末７０では、認証アプリケーション７８の初回起動時に生成された生成ＩＤ（即ち固定的なＩＤ）が継続して利用される。そして、認証アプリケーション７８は、認証アプリケーション７８のベンダ（即ちＭＦＰ１０のベンダ）を示すベンダ情報と、生成ＩＤと、をＮＤＥＦ領域に記述する。なお、変形例では、認証アプリケーション７８には、２個以上の認証アプリケーションの間で重複しないユニークなＩＤが予め割り当てられていてもよい。この場合、認証アプリケーション７８は、当該ＩＤをＮＤＥＦ領域に記述してもよい。また、別の変形例では、認証アプリケーション７８が、生成ＩＤ又は予め割り当てられているＩＤをＯＳソフトウェア７４に供給し、ＯＳソフトウェア７４が、当該ＩＤをＮＤＥＦ領域に記述してもよい。即ち、ＩＤを含むＮＤＥＦ信号は、認証アプリケーション７８に従って送信される信号であればよい。

Ｓ２１２において、ＣＰＵ３２は、Ｆｏｒｍａｔ信号に含まれるＦｏｒｍａｔ情報に基づいて、対象装置がＮＤＥＦをサポートしているのか否かを判断する。ＣＰＵ３２は、対象装置がＮＤＥＦをサポートしていると判断する場合（Ｓ２１２でＹＥＳ）に、ＳＳ２２０に進む。一方、ＣＰＵ３２は、対象装置がＮＤＥＦをサポートしていないと判断する場合（Ｓ２１２でＮＯ）に、認証アプリケーション７８がＩＤを記述可能なＮＤＥＦ領域を含むＮＤＥＦ信号の通信を実行することができないので、さらなる通信を実行することなく、エラーＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＮＯと判断される。

Ｓ２２０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、さらなる上位層通信を対象装置と実行する。ＣＰＵ３２は、上位層通信において、要求信号を対象装置に送信し、対象装置から応答信号を受信する。当該応答信号は、ＮＤＥＦ領域を含むＮＤＥＦ信号を含む。

Ｓ２２２において、ＣＰＵ３２は、ＮＤＥＦ信号に含まれるＮＤＥＦ領域内の記述内容に基づいて、対象装置が認証アプリケーション７８を有するのか否かを判断する。具体的には、ＣＰＵ３２は、ＭＦＰ１０のベンダを示すベンダ情報、即ち、認証アプリケーション７８のベンダを示すベンダ情報が、ＮＤＥＦ領域に記述されている場合に、携帯端末７０が認証アプリケーション７８を有すると判断し（Ｓ２２２でＹＥＳ）、Ｓ２２４に進む。一方、ＣＰＵ３２は、ベンダ情報がＮＤＥＦ領域に記述されていない場合に、対象装置が認証アプリケーション７８を有さないと判断し（Ｓ２２２でＮＯ）、エラーＥＮＤとして図４の処理を終了する。なお、Ｓ２１２でＹＥＳと判断され、かつ、Ｓ２２２でＮＯと判断される場合には、対象装置は、ＮＤＥＦを利用する何らかのアプリケーションを有しているが、当該アプリケーションが認証アプリケーション７８ではないことを意味する。

Ｓ２２４において、ＣＰＵ３２は、ＮＤＥＦ領域内の生成ＩＤを抽出する。この場合、ＣＰＵ３２は、正常ＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＹＥＳと判断され、Ｓ１４２又はＳ１６２では抽出済みの生成ＩＤが利用される。

（具体的なケース；図６及び図７）
続いて、図６及び７を参照して、図３及び４の各処理によって実現される具体的なケースＡ〜Ｄについて説明する。各ケースＡ〜Ｄの初期状態では、認証フラグ３８が「ＯＮ」に設定されており、この結果、ＮＦＣＩ／Ｆ２２ではＲ／ＷモードのみがＯＮされている（図３のＳ１００）。

Ｔ１０では、ＭＦＰ１０は、４つのタイプに対応する４種類のＰｏｌｌｉｎｇ信号を順次送信することを繰り返す（図３のＳ１００）。

ケースＡでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ａである。携帯端末７０Ａには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ１」が割り当てられている。

ＭＦＰ１０は、Ｔ２０において、ユーザ名「Ｕ３」及びパスワード「Ｐ３」の組合せを含むユーザ情報の入力（即ちログイン操作）を受け付け（図３のＳ１１０）、Ｔ２２において、登録ボタンの操作を受け付ける（Ｓ１２０でＹＥＳ）。

Ｔ３０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、携帯端末７０Ａから、ＳＥＬ信号を含むタイプＡの応答信号を受信する（Ｓ１３０でＹＥＳ）。ＭＦＰ１０は、ＳＥＬ信号内の第３ビットがＯＦＦを示し、かつ、第６ビットがＯＮを示すので、対象装置がＴ４Ｔをサポートしていると判断し（図４のＳ２００でＹＥＳ）、Ｔ４０において、対象装置とのＴ４Ｔ通信を実行して、携帯端末７０Ａから、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号と、ＮＤＥＦ領域を含むＮＤＥＦ信号と、を受信する。具体的には、ＭＦＰ１０は、まず、Ｆｏｒｍａｔ信号を受信し（Ｓ２１０）、Ｆｏｒｍａｔ情報が、携帯端末７０ＡがＮＤＥＦをサポートしていることを示すので（Ｓ２１２でＹＥＳ）、さらに、ＮＤＥＦ信号を受信する（Ｓ２２０）。ＭＦＰ１０は、ＮＤＥＦ領域にベンダ情報「ＸＸＸ」が含まれるので（Ｓ２２２でＹＥＳ）、Ｔ５０において、ＮＤＥＦ領域から生成ＩＤ「Ａ１」を抽出する（Ｓ２２４）。Ｔ５２では、ＭＦＰ１０は、ユーザ情報に対応付けて生成ＩＤ「Ａ１」を認証ＩＤとしてユーザテーブル４０に登録する（図３のＳ１４２）。

なお、Ｔ５２が完了すると、ＭＦＰ１０は、Ｔ２０でログインしたユーザをログオフさせ、ユーザのログイン操作を監視（Ｓ１１０）、及び、Ｐｏｌｌｉｎｇ信号に対する応答信号を受信することを監視する（Ｓ１５０）。この状態において、ユーザが携帯端末７０ＡをＭＦＰ１０に再び近づけると、Ｔ６０において、ＭＦＰ１０は、Ｔ３０と同様に、タイプＡの応答信号を受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）とともに、対象装置がＴ４Ｔをサポートしていると判断する（図４のＳ２００でＹＥＳ）。その後のＴ７０、Ｔ８０は、それぞれ、Ｔ４０、Ｔ５０と同様である。

Ｔ８２において、ＭＦＰ１０は、携帯端末７０Ａの認証を実行する（Ｓ１６２）。ＭＦＰ１０は、Ｔ８０で抽出された生成ＩＤ「Ａ１」に一致する認証ＩＤ「Ａ１」がユーザテーブル４０に登録されているので、認証が成功したと判断する。この場合、ＭＦＰ１０は、ユーザ名「Ｕ３」に対応するユーザに許可されている機能を実行する。

（ケースＢ：図７）
ケースＢでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ｂである。携帯端末７０Ｂには、認証アプリケーション７８がインストールされていないが、ＮＤＥＦを利用する認証アプリケーション７８とは異なるアプリケーションがインストールされている。

Ｔ１３０、Ｔ１４０は、それぞれ、図６のケースＡのＴ６０、Ｔ７０と同様である。ただし、ＭＦＰ１０は、ＮＤＥＦ信号にベンダ情報が含まれないので、対象装置に認証アプリケーション７８がインストールされていないと判断する（Ｓ２２２でＮＯ）。この場合、ＭＦＰ１０は、ＩＤを抽出することができないので（図３のＳ１６０でＮＯ）、Ｔ１５０において、エラー画面を表示する（Ｓ１６４）。

（ケースＣ：図７）
ケースＣでは、対象装置は、通信タイプがタイプＡに対応する認証カード５０Ａであって、ＮＤＥＦをサポートしていないMifare Mini（即ちMifare系）の認証カード５０Ａである。

Ｔ２３０は、ケースＡのＴ６０と同様である。ＭＦＰ１０は、Ｔ２４０において、対象装置とのＴ４Ｔ通信を実行して、認証カード５０ＡからＴ４Ｔの応答信号を受信する。具体的には、ＭＦＰ１０は、Ｆｏｒｍａｔ信号を受信し（Ｓ２１０）、Ｆｏｒｍａｔ情報が、認証カード５０ＡがＮＤＥＦをサポートしていないと判断する（Ｓ２１２でＮＯ）。この場合、ケースＢのＴ１５０と同様にＴ２５０が実行される。

（ケースＤ：図７）
ケースＤでは、対象装置は、通信タイプがタイプＡに対応する認証カード５０Ｂであって、Ｔ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルをサポートしていないMifare Mini（即ちMifare系）の認証カード５０Ｂである。

Ｔ３３０において、ＭＦＰ１０は、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ｂから、ＳＥＮＳ信号と、ＳＥＬ信号と、を含むタイプＡの応答信号を受信する（Ｓ１３０でＹＥＳ）。ＭＦＰ１０は、ＳＥＮＳ信号内のＴ１Ｔサポート情報がＯＦＦを示し、かつ、ＳＥＬ信号内の第３ビットがＯＮを示すので、対象装置がＴ１Ｔ〜Ｔ５Ｔのいずれの通信プロトコルもサポートしていないと判断する（図４のＳ２００でＮＯ）。この場合、ケースＢのＴ１５０と同様にＴ３３２が実行される。

（第１実施例の効果）
例えば、タイプＡに対応する携帯端末（以下では「携帯端末（Ａ）」と呼び）とタイプＦに対応する携帯端末（以下では「携帯端末（Ｆ）」と呼ぶ）とが存在し、これらの携帯端末のそれぞれにＩＤが割り当てられている状況を想定する。携帯端末（Ａ）と携帯端末（Ｆ）とは、異なる変調方式に対応するものであり、異なる種類の装置である。従って、これらの携帯端末がＩＤを信号内に記述するためのルールは、通常、各携帯端末を製造するベンダによって異なる。例えば、携帯端末（Ａ）については、ある信号内の第１の位置に第１のデータサイズを有するＩＤが記述される第１のルールが決められており、携帯端末（Ｆ）については、ある信号内の第１の位置とは異なる第２の位置に第１のデータサイズとは異なる第２のデータサイズを有するＩＤが記述される第２のルールが決められる。従って、携帯端末（Ａ）及び携帯端末（Ｆ）のそれぞれからＩＤを抽出するためには、複数のルールに対応する複数のプログラムが必要である。

これに対し、本実施例では、ＭＦＰ１０は、対象装置から２種以上の変調方式に対応する２種以上の応答信号のいずれが受信されても（図３のＳ１５０でＹＥＳ）、即ち、携帯端末（Ａ）及び携帯端末（Ｆ）のいずれから応答信号が受信されても、対象装置がＮＤＥＦをサポートしており（図４のＳ２１２でＹＥＳ）、かつ、ＮＤＥＦ信号にベンダ情報が含まれている場合（Ｓ２２２でＹＥＳ）に、認証アプリケーション７８によってＮＤＥＦ信号内に記述される生成ＩＤを利用して、対象装置の認証を実行する。ここで、生成ＩＤは、ＭＦＰ１０のベンダによって提供される認証アプリケーション７８が生成してＮＤＥＦ信号内に記述するＩＤである。このために、ＭＦＰ１０は、複数のルールに対応する複数のプログラムを備えていなくても、携帯端末（Ａ）及び携帯端末（Ｆ）を含む対象装置から共通のルール（即ち認証アプリケーション７８）に従った生成ＩＤを取得することができ、生成ＩＤを利用して対象装置の認証を適切に認証することができる。なお、タイプＢに対応する携帯端末がさらに存在する状況でも、上記の効果は同様に得られる。

（対応関係）
ＭＦＰ１０が、「通信装置」の一例である。認証カード５０及び携帯端末７０が、「対象装置」の一例である。ＮＦＣＩ／Ｆ２２が、「無線インターフェース」の一例である。
認証アプリケーション７８が、「所定のアプリケーションソフトウェア」の一例である。ベンダ情報が、「関連情報」の一例である。生成ＩＤが、「第１の識別情報」の一例である。各タイプに対応するＰｏｌｌｉｎｇ信号に対する各タイプの応答信号が、「所定規格で定められている２種以上の変調方式に対応する２種以上の信号」の一例である。Ｆｏｒｍａｔ信号及びＮＤＥＦ信号が、「特定の信号」の一例である。Ｔ１Ｔ〜Ｔ５Ｔの通信プロトコルが、「所定の通信プロトコル」の一例である。アクティビティ層が「第１の通信レイヤ」の一例であり、Ｔ１Ｔ〜Ｔ５Ｔ層が「第２の通信レイヤ」の一例である。認証フラグ３８が「ＯＦＦ」である状態、「ＯＮ」である状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。

図３のＳ１５０が、「第１の受信部」が実行する処理の一例である。図４のＳ２１０が、Ｓ２２０が、それぞれ、「第２の受信部」、「第３の受信部」が実行する処理の一例である。図４のＳ２２４を経た図３のＳ１６２が、「第１の認証部」が実行する処理の一例である。

(第２実施例)
本実施例では、図４のＩＤ抽出処理が第１実施例とは異なる。具体的には、Ｓ２１２でＮＯの場合及びＳ２２２でＮＯの場合に、Ｓ２３０に進む。Ｓ２３０において、ＣＰＵ３２は、図３のＳ１３０又はＳ１５０で受信済みの応答信号を利用して、受信済みの応答信号に含まれる装置ＩＤが認証に利用可能であるのか否かを判断する。具体的には、ＣＰＵ３２は、図８のテーブルに基づいて、判断を実行する。

図８のテーブルを説明する前に、図９を参照して、各通信タイプに応じた各応答信号（図３のＳ１３０又はＳ１５０参照）と、装置ＩＤと、について説明しておく。タイプＡの応答信号は、ＳＥＮＳ（SENS_RES Responseの略）信号と、ＳＤＤ（SDD_RES Responseの略）信号と、ＳＥＬ信号と、を含む。ＳＤＤ信号は、タイプＡの装置ＩＤであるＮＦＣＩＤ１を含み、ＳＥＮＳ信号は、当該ＮＦＣＩＤのデータサイズを示す情報を含む。ＳＥＬ信号は、図５を参照して説明した第３ビット及び第６ビットの情報と、他の情報（例えば第７ビットの情報）と、を含む。

タイプＢの応答信号は、ＳＥＮＳＢ信号を含み、ＳＥＮＳＢ信号は、タイプＢの装置ＩＤであるＮＦＣＩＤ０を含む。タイプＦの応答信号は、ＳＥＮＳＦ信号を含み、ＳＥＮＳＦ信号は、ＰＡＤ０と、タイプＦの装置ＩＤであるＮＦＣＩＤ２と、を含む。ＰＡＤ０は、対象装置のＮＦＣＩ／ＦのＩＣタイプを示す情報を含み、ＰＭｍ（Manufacture Parameterの略）と言い換えることもできる。タイプＶの応答信号は、Ｉｎｖｅｎｔｏｒｙ信号を含み、Ｉｎｖｅｎｔｏｒｙ信号は、タイプＶの装置ＩＤであるＵＩＤ（Universal IDの略）を含む。

上述したように、装置ＩＤは、通信タイプ毎に異なる名称を有するＩＤである。即ち、通信タイプＡ、Ｂ、Ｆ、Ｖに対応する装置ＩＤは、それぞれ、「ＮＦＣＩＤ１」、「ＮＦＣＩＤ０」、「ＮＦＣＩＤ２」、「ＵＩＤ」である。ＮＦＣＩＤ０〜２は、ＮＦＣフォーラムで規定されており、ＵＩＤは、ＮＦＣフォーラムで規定されていない。

対象装置が認証カード５０である場合には、装置ＩＤは、各カードに予め割り当てられている。対象装置がタイプＡ、Ｆ、又は、Ｖに対応する認証カード５０では、装置ＩＤは認証カード毎にユニークなＩＤであり、２枚以上の認証カードの間で装置ＩＤが重複しない。従って、タイプＡ、Ｆ、又は、Ｖに対応する認証カード５０の装置ＩＤは、認証に適している。一方、タイプＢに対応する認証カード５０では、複数枚の認証カードに同じ装置ＩＤが割り当てられ得る。このために、タイプＢに対応する認証カード５０の装置ＩＤは、認証に適していない。

また、対象装置が携帯端末７０である場合には、装置ＩＤは、ＯＳソフトウェア７４によって準備される。例えば、ＯＳソフトウェア７４は、ＳＤＤ信号を送信すべき際に、ランダムに文字列を決定して、当該文字列を装置ＩＤとして決定する。従って、仮に、携帯端末７０から受信される装置ＩＤがユーザテーブル４０に登録されると（図３のＳ１４２）、その後に携帯端末７０から受信される装置ＩＤは、通常、登録済みの装置ＩＤとは異なる。従って、携帯端末７０から受信される装置ＩＤは、認証に適していない。

図８のテーブルは、図３のＳ１３２又はＳ１５２で特定される通信タイプと、図４のＳ２００で特定される通信プロトコルと、当該通信タイプ及び当該通信プロトコルに基づいて特定される対象装置の種類と、装置ＩＤが認証に利用可能であるのか否かを判断するための方法と、判断結果と、を示す。特定済みの通信タイプがタイプＡであり、かつ、特定済みの通信プロトコルがＴ２Ｔである場合には、ＣＰＵ３２は、対象装置がMifare系の認証カード５０であると特定する。上述したように、タイプＡに対応する認証カード（即ちMifare系の認証カード）の装置ＩＤ（即ちＮＦＣＩＤ１）は、認証に適している。この場合、ＣＰＵ３２は、ＳＥＬ信号に含まれる図示省略のカードタイプ（例えばMifare Mini）を特定し、特定済みのカードタイプについてＮＦＣ規格の仕様書で定義されているＮＦＣＩＤ１のデータサイズを特定する。そして、ＣＰＵ３２は、ＳＥＮＳ信号内に記述されているデータサイズが、特定済みのデータサイズに一致するのか否かを判断する。ＣＰＵ３２は、一致すると判断する場合には、ＮＦＣＩＤ１を認証に利用可能であると判断し、一致しないと判断する場合には、ＮＦＣＩＤ１を認証に利用不可能であると判断する。

特定済みの通信タイプがタイプＡであり、かつ、特定済みの通信プロトコルがＴ４Ｔである場合には、ＣＰＵ３２は、対象装置がMifare Desfire系の認証カード５０又は携帯端末７０であると特定する。この場合、ＣＰＵ３２は、まず、ＳＥＬ信号内の第７ビットがＯＮを示すのかＯＦＦを示すのかを判断する。ＳＥＬ信号内の第７ビットは、対象装置がＮＦＣ＿ＤＥＰ（ISO/IEC18092で定義されたData Exchange Protocolの略）をサポートしているのか否かを示す。ＮＦＣ＿ＤＥＰをサポートしているとは、対象装置がＰ２Ｐ通信リンクを確立可能であること、即ち、対象装置が双方向通信を実行可能な携帯端末７０であること、を意味する。従って、ＣＰＵ３２は、ＳＥＬ信号内の第７ビットがＯＮを示すと判断する場合には、対象装置が携帯端末７０であると特定する。この場合、ＣＰＵ３２は、ＮＦＣＩＤ１を認証に利用不可能であると判断する。ＣＰＵ３２は、ＳＥＬ信号内の第７ビットがＯＦＦを示すと判断する場合には、さらに、ＳＥＮＳ信号内のデータサイズが４バイトを示すのか７バイトを示すのかを判断する。Mifare Desfire系の認証カード５０、携帯端末７０は、それぞれ、ＮＦＣＩＤ１として、通常、７バイト、４バイトのデータサイズを採用する。従って、ＣＰＵ３２は、データサイズが４バイトを示すと判断する場合には、対象装置が携帯端末７０であると特定し、ＮＦＣＩＤ１を認証に利用不可能であると判断する。また、ＣＰＵ３２は、データサイズが７バイトを示すと判断する場合には、対象装置がMifare Desfire系の認証カード５０であると特定し、ＮＦＣＩＤ１を認証に利用可能であると判断する。なお、Mifare Desfire系の認証カード５０であると判断するデータサイズ（本実施例では７バイト）は、Mifareの仕様書に記載されているデータサイズに基づいて設定される。

特定済みの通信タイプがタイプＢであり、かつ、特定済みの通信プロトコルがＴ４Ｔである場合には、ＣＰＵ３２は、ＮＦＣＩＤ０を認証に利用不可能であると判断する。上述したように、通信タイプがタイプＢである場合には、対象装置が携帯端末７０及び認証カード５０のいずれでも、ＮＦＣＩＤ０が認証に適していないためである。

特定済みの通信タイプがタイプＦであり、かつ、特定済みの通信プロトコルがＴ３Ｔである場合には、ＣＰＵ３２は、ＳＥＮＳＦ信号内のＰＡＤ０が所定タイプ（例えば、０６ｈ、０７ｈ、１０ｈ〜１３ｈ、及び、１４ｈ〜１Ｆｈ）を示すのか否かを判断する。携帯端末７０は、通常、ＰＡＤ０として上記の所定タイプを採用し、認証カード５０は、通常、ＰＡＤ０として上記の所定タイプとは異なるタイプを採用する。従って、ＣＰＵ３２は、ＰＡＤ０が所定タイプを示す場合には、対象装置が携帯端末７０であると特定し、ＮＦＣＩＤ２を認証に利用不可能であると判断する。また、ＣＰＵ３２は、ＰＡＤ０が所定タイプを示さない場合には、対象装置が認証カード５０であると特定し、ＮＦＣＩＤ２を認証に利用可能であると判断する。なお、ＰＡＤ０は、２ｂｙｔｅの情報であり、本明細書及び図面に記載されているＩＣタイプを示す情報（０６ｈ等）は、ＰＡＤ０に含まれる情報の一部を示す

また、タイプＶに対応する対象装置は、携帯端末７０ではなく、認証カード５０である。このために、特定済みの通信タイプがタイプＶであり、かつ、特定済みの通信プロトコルがＴ５Ｔである場合には、ＣＰＵ３２は、対象装置が認証カード５０であると特定し、ＵＩＤを認証に利用可能であると判断する。

図４のＳ２３０において、ＣＰＵ３２は、対象装置の装置ＩＤを認証に利用可能であると判断する場合（Ｓ２３０でＹＥＳ）には、Ｓ２３２において、通信タイプに応じた装置ＩＤを抽出する。具体的には、タイプＡの応答信号を受信済みである場合には、ＣＰＵ３２は、ＳＤＤ信号からＮＦＣＩＤ１を抽出する。また、ＣＰＵ３２は、タイプＦのＳＥＮＳＦ信号、又は、タイプＶのＩｎｖｅｎｔｏｒｙ信号から、ＮＦＣＩＤ２又はＵＩＤを抽出する。この場合、ＣＰＵ３２は、正常ＥＮＤとして図４の処理を終了する。一方、ＣＰＵ３２は、対象装置の装置ＩＤを認証に利用不可能であると判断する場合（Ｓ２３０でＮＯ）には、エラーＥＮＤとして図４の処理を終了する。

（具体的なケースＥ；図１０）
続いて、図１０を参照して、第２実施例で実現されるケースＥについて説明する。ケースＥでは、対象装置は、通信タイプがタイプＡに対応するMifare Mini（即ちMifare系）の認証カード５０Ｃである。認証カード５０Ｃには、ＮＦＣＩＤ１「Ａ５」が予め割り当てられている。なお、仕様書で定義されているMifare MiniのＮＦＣＩＤ１のデータサイズは、４バイトである。

ＭＦＰ１０は、Ｔ４３０において、タイプＡのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ｃから、ＳＥＮＳ信号と、ＮＦＣＩＤ１「Ａ５」を含むＳＤＤ信号と、ＳＥＬ信号と、を含むタイプＡの各応答信号を順次受信する（図３のＳ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。

ＭＦＰ１０は、ＳＥＬ信号内の第３ビットがＯＦＦを示し、かつ、第６ビットがＯＦＦを示すので、対象装置がＴ２Ｔをサポートしていると判断し（図５参照、図４のＳ２００でＹＥＳ）、Ｔ４４０において、対象装置とＴ２Ｔ通信を実行して、認証カード５０Ｃから、Ｆｏｒｍａｔ信号を受信する。ＭＦＰ１０は、Ｆｏｒｍａｔ情報が、認証カード５０ＣがＮＤＥＦをサポートしていないことを示すので（Ｓ２１２でＮＯ）、受信済みのＳＤＤ信号に含まれるＮＦＣＩＤ１を認証に利用可能であるのか否を判断する（Ｓ２３０）。具体的には、ＭＦＰ１０は、特定済みの通信タイプがタイプＡであり、かつ、特定済みの通信プロトコルがＴ２Ｔであるので、対象装置がMifare系の認証カードであると特定する。特に、ＭＦＰ１０は、ＳＥＬ信号内のカードタイプを示す情報に基づいて、対象装置がMifare Miniの認証カード５０Ｃであると判断する。そして、ＭＦＰ１０は、ＳＥＮＳ信号内のデータサイズ情報が４バイトを示すので、ＳＥＮＳ信号内のデータサイズが、仕様書で定義されるMifare Miniのデータサイズに一致すると判断し、ＳＤＤ信号に含まれるＮＦＣＩＤ１を認証に利用可能であると判断する（Ｓ２３０でＹＥＳ）。

Ｔ４５０において、ＭＦＰ１０は、ＳＤＤ信号からＮＦＣＩＤ１「Ａ５」を抽出する（Ｓ２３２）。Ｔ４５２において、ＭＦＰ１０は、ＮＦＣＩＤ１「Ａ５」を利用して、認証カード５０Ｃの認証を実行する（図３のＳ１６２）。

（第２実施例の効果）
本実施例によると、ＭＦＰ１０は、対象装置がＮＤＥＦをサポートしていない場合（図４のＳ２１２でＮＯ）、又は、対象装置に認証アプリケーション７８がインストールされていない場合（Ｓ２２２でＮＯ）に、生成ＩＤとは異なる装置ＩＤを利用して、対象装置の認証を実行することができる（Ｓ２３２、図３のＳ１６２）。特に、ＭＦＰ１０は、装置ＩＤを認証に利用可能であるのか否かを判断し（Ｓ２３０）、利用可能であると判断された装置ＩＤを利用して、対象装置の認証を実行する。このために、ＭＦＰ１０は、装置ＩＤを利用して、対象装置の認証を適切に実行することができる。即ち、ＭＦＰ１０は、生成ＩＤ又は装置ＩＤを利用して、対象装置の認証を適切に実行することができる。

（対応関係）
装置ＩＤが、「第１の識別情報とは異なる識別情報」及び「第２の識別情報」の一例である。図４のＳ２３０が、「第２の判断部」によって実行される処理の一例である。図４のＳ２３２を経た図３のＳ１６２が、「第２の認証部」が実行する処理の一例である。

（第３実施例）
本実施例では、図４のＩＤ抽出処理が第２実施例とは異なる。具体的には、Ｓ２１２でＮＯの場合又はＳ２２２でＮＯの場合に、Ｓ２４０に進む。Ｓ２４０において、ＣＰＵ３２は、Ｓ２００で特定された通信プロトコルを利用した上位層通信（例えばＴ４Ｔ通信）を実行して、要求信号を対象装置に送信し、対象装置からＮＤＥＦに依存しない非依存信号を受信する。非依存信号は、対象装置のＮＦＣＩ／Ｆ内のメモリに書き込まれているデータを含む。

Ｓ２４２において、ＣＰＵ３２は、非依存信号に識別ＩＤが含まれているのか否かを判断する。本実施例では、プログラム３６は、タイプＢの認証カード５０に識別ＩＤを記述するためのルールに対応するプログラムを含む。当該ルールは、タイプＢの認証カード５０のベンダによって決められているルールであり、非依存信号の所定位置に所定サイズの識別ＩＤを記述することを定義している。また、識別ＩＤは、タイプＢの認証カード５０のベンダが、個々の認証カード５０に割り当てるユニークなＩＤである。このために、識別ＩＤは、認証に適している。Ｓ２４２では、ＣＰＵ３２は、非依存信号の所定位置に所定サイズの識別ＩＤが記述されているのか否かを判断することによって、非依存信号に識別ＩＤが含まれているのか否かを判断する。

ＣＰＵ３２は、非依存信号に識別ＩＤが含まれていると判断する場合（Ｓ２４２でＹＥＳ）には、Ｓ２４４において、非依存信号内の識別ＩＤを抽出する。この場合、ＣＰＵ３２は、正常ＥＮＤとして図４の処理を終了する。この結果、図３のＳ１４０又はＳ１６０でＹＥＳと判断され、Ｓ１４２又はＳ１６２では抽出済みの識別ＩＤが利用される。一方、ＣＰＵ３２は、非依存信号に識別ＩＤが含まれていないと判断する場合（Ｓ２４２でＮＯ）には、Ｓ２３０に進む。なお、変形例では、Ｓ２４２でＮＯの場合に、Ｓ２３０に進まずに、エラーＥＮＤとして処理を終了してもよく、この場合、Ｓ２１２又はＳ２２２でＮＯの場合にも、Ｓ２３０に進まずに、エラーＥＮＤとして処理を終了してもよい。

なお、変形例では、プログラム３６は、タイプＢの認証カード５０のためのルールに代えて又は当該ルールに加えて、他のタイプの認証カード５０又は携帯端末７０のためのルールに対応するプログラムを含んでいてもよい。この場合、ＣＰＵ３２は、プログラム３６に応じたルールを利用して、Ｓ２４２の判断を実行する。

（具体的なケースＦ；図１０）
続いて、図１０を参照して、第３実施例で実現されるケースＦについて説明する。ケースＦでは、対象装置は、通信タイプがタイプＢに対応する認証カード５０Ｄである。認証カード５０Ｄには、ＮＦＣＩＤ０「Ａ６」と、ＮＦＣＩＤ０とは異なる識別ＩＤ「Ａ７」と、が予め割り当てられている。

Ｔ５３０において、ＭＦＰ１０は、タイプＢのＰｏｌｌｉｎｇ信号の送信に応じて、認証カード５０Ｄから、ＳＥＮＳＢ信号を含むタイプＢの応答信号を受信する（Ｓ１３０でＹＥＳ）。次いで、Ｔ５４０において、ＭＦＰ１０は、対象装置とのＴ４Ｔ通信を実行して、認証カード５０Ｄから、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号を受信する。ＭＦＰ１０は、Ｆｏｒｍａｔ情報が、認証カード５０ＤがＮＤＥＦをサポートしていないことを示すので（Ｓ２１２でＮＯ）、さらに、認証カード５０Ｄから非依存信号を受信する（Ｓ２４０）。非依存信号に識別ＩＤ「Ａ７」が含まれるので（Ｓ２４２でＮＯ）、ＭＦＰ１０は、Ｔ５５０において、識別ＩＤ「Ａ７」を抽出し（Ｓ２４４）、Ｔ５５２において、抽出済みの識別ＩＤ「Ａ７」を利用して、認証カード５０Ｄの認証を実行する。ここで、ＭＦＰ１０は、ＳＥＮＳＢ信号に含まれるＮＦＤＩＤ０を利用して、認証を実行しない。上述したように、タイプＢに対応するＮＦＤＩＤ０は、認証に適していないからである。

（第３実施例の効果）
本実施例によると、ＭＦＰ１０は、対象装置がＮＤＥＦをサポートしていない場合（図４のＳ２１２でＮＯ）に、生成ＩＤとは異なる識別ＩＤ、即ち、ＮＤＥＦに依存しない非依存信号に含まれる識別ＩＤを利用して、対象装置の認証を実行することができる（Ｓ２４４、図３のＳ１６２）。即ち、ＭＦＰ１０は、生成ＩＤ、装置ＩＤ、又は、識別ＩＤを利用して、対象装置の認証を適切に実行することができる。

（対応関係）
識別ＩＤが、「第１の識別情報とは異なる識別情報」及び「第３の識別情報」の一例である。図４のＳ２３２又はＳ２４４を経た図３のＳ１６２が、「第２の認証部」が実行する処理の一例である。

（変形例１）ＣＰＵ３２は、図３のＳ１１０でＹＥＳと判断する場合に、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード、Ｒ／Ｗモード、及び、ＣＥモードの全てがＯＮされているモード状態に変更してもよい。この状態では、ＣＰＵ３２は、図２と同様に、印刷機能を実行し得る。また、ＣＰＵ３２は、Ｓ１２０でＹＥＳと判断する場合に、ＮＦＣＩ／Ｆ２２のモード状態を、Ｐ２Ｐモード及びＣＥモードがＯＦＦされており、かつ、Ｒ／ＷモードがＯＮされているモード状態に変更してもよい。この場合、ＣＰＵ３２は、対象装置からＩＤを抽出して登録するための処理（Ｓ１３０〜Ｓ１４２）を適切に実行することができる。本変形例でも、認証フラグ３８が「ＯＦＦ」である状態、「ＯＮ」である状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。別の観点では、ログイン操作後に登録ボタンが操作されていない状態、登録ボタンが操作された後の状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。また、別の変形例では、ＮＦＣＩ／Ｆ２２のモード状態は、少なくともＲ／ＷモードがＯＮされているモード状態に固定されてもよい。即ち、「インターフェース制御部」を省略可能である。

（変形例２）
ＭＦＰ１０は、認証フラグ３８を有していなくてもよい。この場合、ＣＰＵ３２は、図２の処理を実行しない。即ち、「送信部」を省略可能である。

（変形例３）いずれの対象装置もＴ１Ｔ〜Ｔ５Ｔの通信プロトコルのいずれかをサポートしている環境下では、図４のＳ２００を省略して、Ｓ２１０以降の処理が実行されてもよい。即ち、「第３の判断部」を省略可能である。

（変形例４）携帯端末７０は、認証アプリケーション７８を利用して、ベンダ情報と生成ＩＤとを認証カード５０に書き込んでもよい。この場合、ユーザが、認証カード５０をＭＦＰ１０に近づけると、ＣＰＵ３２は、図４のＳ２００〜Ｓ２２４の処理を実行して、認証カード５０に書き込まれている生成ＩＤを抽出する。このように、生成ＩＤが抽出される対象装置は、携帯端末７０に限られず、認証カード５０であってもよい。

（変形例５）ＣＰＵ３２は、図４のＳ２２０において、生成ＩＤに代えて、ユーザ情報（ユーザ名及びパスワード）を受信してもよい。例えば、ユーザが認証アプリケーション７８を起動すると、ユーザ情報を入力可能な画面が携帯端末７０に表示される。ユーザがユーザテーブル４０に登録されているユーザ情報を入力する場合に、携帯端末７０は入力されたユーザ情報を記憶する。ユーザが携帯端末７０をＭＦＰ１０に近づけて、ＭＦＰ１０と携帯端末７０とのＮＦＣ通信が確立されると、Ｓ２２０において、ＣＰＵ３２は、携帯端末７０からユーザ情報を含むＮＤＥＦ信号を受信する。この場合、Ｓ２２４において、ＣＰＵ３２は、ＮＤＥＦ信号からユーザ情報を抽出し、当該ユーザ情報とユーザテーブル４０に登録されているユーザ情報とが一致する場合に、認証が成功したと判断する。本変形例では、ＣＰＵ３２は、認証ＩＤの登録を実行する必要が無い。従って、図３のＳ１２０、Ｓ１３０〜Ｓ１４４の処理を省略することができる。

（変形例６）ユーザテーブル４０への認証ＩＤの登録は、管理者が操作部１２を操作することによって実行されてもよい。この場合、図３のＳ１２０、Ｓ１３０〜Ｓ１４４を省略可能である。

（変形例７）図２のＳ１０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２のモード状態を、ＣＥモードのみがＯＮされているモード状態に設定してもよい。この場合、Ｓ１２において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２がＣＥモードで動作すると共にＮＦＣＩ／Ｆ７２がＲ／Ｗモードで動作するＣＥ−Ｒ／Ｗ通信リンクが確立されることを監視する。Ｓ１４〜Ｓ２４の処理は、上記の実施例と同様である。ただし、Ｓ１６の結果として、ＮＦＣＩ／Ｆ２２は、ＣＥ−Ｒ／Ｗ通信リンクを介して、無線設定を携帯端末７０に送信する。一般的に言うと、「第１のモード状態」は、Ｐ２Ｐモード及びＣＥモードのうちの少なくとも一方のモードが有効化されている状態であればよい。

（変形例８）ユーザテーブル４０は、ショートカット機能を示すショートカット情報を格納していてもよい。ショートカット情報は、例えば、スキャン設定、スキャンデータの宛先等を示す情報であってもよい。この場合、ＣＰＵ３２は、対象装置の認証が成功した場合（Ｓ１６２）に、認証が成功した認証ＩＤに対応するショートカット情報に含まれるスキャン設定に従ったスキャンを実行し、その後、ショートカット情報に含まれる宛先にスキャンデータを送信する。

（変形例９）「無線インターフェース」は、ＮＦＣ通信を実行するためのＩ／Ｆでなくてもよく、例えば、ＢｌｕｅＴｏｏｔｈ（登録商標）、ＴｒａｎｓｆｅｒＪｅｔ（登録商標）等の他の通信方式に従った無線通信を実行するためのＩ／Ｆであってもよい。

（変形例１０）「通信装置」は、複数の機能を実行可能なＭＦＰ１０でなくてもよく、印刷機能のみを実行可能な印刷装置、スキャン機能のみを実行可能なスキャナ装置等であってもよい。

（変形例１１）上記の実施例では、ＭＦＰ１０のＣＰＵ３２がプログラム３６（即ちソフトウェア）を実行することによって、図２〜図４の各処理が実現される。これに代えて、図２〜図４の各処理のうちの少なくとも１つの処理は、論理回路等のハードウェアによって実現されてもよい。

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
以下は、出願時の特許請求の範囲に対応する記載である。
（項目１）
通信装置であって、
所定規格に従った無線通信を実行するための無線インターフェースと、
対象装置から、前記無線インターフェースを介して、前記所定規格で定められている２種以上の変調方式に対応する２種以上の信号のうちのいずれかの信号を受信する第１の受信部と、
前記対象装置から前記２種以上の信号のうちのいずれかの信号が受信されても、前記対象装置から、前記無線インターフェースを介して、フォーマット情報を受信する第２の受信部であって、前記フォーマット情報は、前記対象装置が、前記所定規格で定められている所定のフォーマットであって、信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示す情報を含む、前記第２の受信部と、
前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記対象装置から、前記無線インターフェースを介して、前記所定のフォーマットで記述されている情報を含む特定の信号を受信する第３の受信部であって、前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記特定の信号は受信されない、前記第３の受信部と、
所定のアプリケーションソフトウェアに関連する関連情報が前記特定の信号に含まれるのか否かを判断する第１の判断部と、
前記関連情報が前記特定の信号に含まれると判断される場合に、前記特定の信号に含まれる第１の識別情報を利用して、前記対象装置の認証を実行する第１の認証部であって、前記関連情報が前記特定の信号に含まれないと判断される場合に、前記特定の信号に含まれる情報を利用した前記認証は実行されない、前記第１の認証部と、
を備える通信装置。
（項目２）
前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第１の識別情報とは異なる識別情報を利用して、前記対象装置の認証を実行する第２の認証部を備える、項目１に記載の通信装置。
（項目３）
前記第２の認証部は、前記２種以上の信号のうちの受信済みの信号に含まれる第２の識別情報であって、前記第１の識別情報とは異なる前記第２の識別情報を利用して、前記対象装置の認証を実行する、項目２に記載の通信装置。
（項目４）
前記通信装置は、さらに、
前記２種以上の信号のうちの前記受信済みの信号を利用して、前記第２の識別情報を認証に利用可能であるのか否かを判断する第２の判断部を備え、
前記第２の認証部は、前記第２の識別情報を認証に利用可能であると判断される場合に、前記第２の識別情報を利用して、前記対象装置の認証を実行し、
前記第２の識別情報を認証に利用可能でないと判断される場合に、前記第２の識別情報を利用した前記対象装置の認証は実行されない、項目３に記載の通信装置。
（項目５）
前記通信装置は、さらに、
前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記対象装置から、前記無線インターフェースを介して、前記所定のフォーマットに依存しない非依存信号を受信する第４の受信部を備え、
前記第２の認証部は、前記非依存信号が、前記第１の識別情報とは異なる第３の識別情報を含む場合に、前記第３の識別情報を利用して、前記対象装置の認証を実行する、項目２から４のいずれか一項に記載の通信装置。
（項目６）
前記通信装置は、さらに、
前記２種以上の信号のうちの前記受信済みの信号を利用して、前記対象装置が前記所定規格で定められている所定の通信プロトコルをサポートしているのか否かを判断する第３の判断部を備え、
前記第２の受信部は、前記対象装置が前記所定の通信プロトコルをサポートしていると判断される場合に、前記対象装置から前記フォーマット情報を受信し、
前記対象装置が前記所定の通信プロトコルをサポートしていないと判断される場合に、前記フォーマット情報は受信されない、項目１から５のいずれか一項に記載の通信装置。
（項目７）
前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格である、項目１から６のいずれか一項に記載の通信装置。
（項目８）
前記所定のフォーマットは、ＮＤＥＦ（NFC Data Exchange Formatの略）である、項目７に記載の通信装置。
（項目９）
前記第１の受信部は、前記所定規格で定められている第１の通信レイヤを利用して、前記所定規格で定められている第２の通信レイヤであって、前記第１の通信レイヤよりも上位である前記第２の通信レイヤを利用せずに、前記２種以上の信号のうちのいずれかの信号を受信し、
前記第２の受信部は、前記第２の通信レイヤを利用して、前記フォーマット情報を受信し、
前記第３の受信部は、前記第２の通信レイヤを利用して、前記特定の信号を受信する、項目１から８のいずれか一項に記載の通信装置。
（項目１０）
前記通信装置が第１の動作状態に設定されている間に、前記対象装置から前記２種以上の信号のうちのいずれかの信号が受信される場合に、
前記第２の受信部は、前記フォーマット情報を受信し、
前記第３の受信部は、前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記対象装置から前記特定の信号を受信し、
前記第１の判断部は、前記関連情報が前記特定の信号に含まれるか否かを判断し、
前記第１の認証部は、前記関連情報が前記特定の信号に含まれると判断される場合に、前記第１の識別情報を利用して、前記対象装置の認証を実行し、
前記通信装置は、さらに、
前記通信装置が前記第１の動作状態とは異なる第２の動作状態に設定されている間に、前記対象装置から前記２種以上の信号のうちのいずれかの信号が受信される場合に、前記無線インターフェースを介して、無線設定情報を前記対象装置に送信する送信部を備え、
前記無線設定情報は、前記通信装置と前記対象装置との間に、前記無線インターフェースとは異なるインターフェースを介した無線接続を確立するための情報である、項目１から９のいずれか一項に記載の通信装置。
（項目１１）
前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格であり、
前記通信装置は、さらに、
前記無線インターフェースのモード状態を制御するインターフェース制御部を備え、
前記インターフェース制御部は、
前記通信装置の動作状態が前記第１の動作状態から前記第２の動作状態に変更される場合に、前記無線インターフェースのモード状態を、前記ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モード及びＣＥ（Card Emulationの略）モードのうちの少なくとも一方のモードが有効化されている第１のモード状態に設定し、
前記通信装置の動作状態が前記第２の動作状態から前記第１の動作状態に変更される場合に、前記無線インターフェースのモード状態を、前記ＮＦＣ規格の前記Ｐ２Ｐモード及びＣＥモードが無効化されていると共に、前記ＮＦＣ規格のＲ／Ｗ（Reader/Writerの略）モードが有効化されている第２のモード状態に設定する、項目１０に記載の通信装置。
（項目１２）
通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、以下の処理、即ち、
対象装置から、無線インターフェースを介して、所定規格で定められている２種以上の変調方式に対応する２種以上の信号のうちのいずれかの信号を受信する第１の受信処理であって、前記無線インターフェースは、前記所定規格に従った無線通信を実行するためのインターフェースである、前記第１の受信処理と、
前記対象装置から前記２種以上の信号のうちのいずれかの信号が受信されても、前記対象装置から、前記無線インターフェースを介して、フォーマット情報を受信する第２の受信処理であって、前記フォーマット情報は、前記対象装置が、前記所定規格で定められている所定のフォーマットであって、信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示す情報を含む、前記第２の受信処理と、
前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記対象装置から、前記無線インターフェースを介して、前記所定のフォーマットで記述されている情報を含む特定の信号を受信する第３の受信処理であって、前記フォーマット情報が、前記対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記特定の信号は受信されない、前記第３の受信処理と、
所定のアプリケーションソフトウェアに関連する関連情報が前記特定の信号に含まれるのか否かを判断する第１の判断処理と、
前記関連情報が前記特定の信号に含まれると判断される場合に、前記特定の信号に含まれる第１の識別情報を利用して、前記対象装置の認証を実行する第１の認証処理であって、前記関連情報が前記特定の信号に含まれないと判断される場合に、前記特定の信号に含まれる情報を利用した前記認証は実行されない、前記第１の認証処理と、
を実行させるコンピュータプログラム。

２：通信システム、１０：多機能機（ＭＦＰ）１２：操作部、１４：表示部、１６：印刷実行部、１８：スキャン実行部、２０：Ｗｉ−ＦｉＩ／Ｆ、２２：ＮＦＣＩ／Ｆ、３０：制御部、３２：ＣＰＵ、３４：メモリ、３６：プログラム、３８：認証フラグ、４０：ユーザテーブル、５０，５０Ａ〜５０Ｄ：認証カード、５２：ＮＦＣＩ／Ｆ、７０，７０Ａ，７０Ｂ：携帯端末、７２：ＮＦＣＩ／Ｆ、７４：ＯＳソフトウェア、７６：印刷アプリケーション、７８：認証アプリケーション

Claims (12)

1. 通信装置であって、
   所定規格に従った無線通信を実行するための無線インターフェースと、
   前記無線インターフェースを介して、前記所定規格で定められている２種以上の変調方式であって、第１の変調方式と、前記第１の変調方式とは異なる第２の変調方式と、を含む前記２種以上の変調方式に対応するポーリング信号を順次送信する第１の送信部と、
   前記第１の変調方式に対応する第１のポーリング信号の送信に応じて、第１の対象装置から、前記無線インターフェースを介して、前記第１のポーリング信号に対する第１の応答信号を受信する第１の受信部と、
   前記第１の対象装置から前記第１の応答信号が受信される場合に、前記第１の対象装置から、前記無線インターフェースを介して、第１のフォーマット情報を受信する第２の受信部であって、前記第１のフォーマット情報は、前記第１の対象装置が、前記所定規格で定められている所定のフォーマットであって、前記第１の対象装置から前記通信装置に送信される第１の特定の信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示し、所定のアプリケーションソフトウェアが前記第１の対象装置にインストールされている場合に、当該情報は、前記所定のアプリケーションソフトウェアによって生成される第１の識別情報であって、前記第１の対象装置の認証に利用される前記第１の識別情報を含む、前記第２の受信部と、
   前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記第１の対象装置から、前記無線インターフェースを介して、前記第１の特定の信号を受信する第３の受信部であって、前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第１の特定の信号は受信されない、前記第３の受信部と、
   前記所定のアプリケーションソフトウェアに関連する関連情報が前記第１の特定の信号に含まれるのか否かを判断する第１の判断部と、
   前記関連情報が前記第１の特定の信号に含まれると判断される場合に、前記第１の特定の信号に含まれる前記第１の識別情報を抽出する抽出部と、前記関連情報が前記第１の特定の信号に含まれないと判断される場合に、前記第１の特定の信号に含まれる情報は抽出されない、前記抽出部と、
   前記第１の特定の信号から前記第１の識別情報が抽出される場合に、抽出済みの前記第１の識別情報を利用して、前記第１の対象装置の認証を実行する第１の認証部であって、前記関連情報が前記第１の特定の信号に含まれないと判断される場合に、前記第１の特定の信号に含まれる情報を利用した認証は実行されない、前記第１の認証部と、
   を備え、
   前記第１の受信部は、さらに、前記第２の変調方式に対応する第２のポーリング信号の送信に応じて、第２の対象装置から、前記無線インターフェースを介して、前記第２のポーリング信号に対する第２の応答信号を受信し、
   前記第２の受信部は、さらに、前記第２の対象装置から前記第２の応答信号が受信される場合に、前記第２の対象装置から、前記無線インターフェースを介して、第２のフォーマット情報を受信し、
   前記第２のフォーマット情報は、前記第２の対象装置が、前記第２の対象装置から前記通信装置に送信される第２の特定の信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示し、
   前記所定のアプリケーションソフトウェアが前記第２の対象装置にインストールされている場合に、当該情報は、前記所定のアプリケーションソフトウェアによって生成される特定の識別情報であって、前記第２の対象装置の認証に利用される前記特定の識別情報を含み、
   前記第３の受信部は、さらに、前記第２のフォーマット情報が、前記第２の対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記第２の対象装置から、前記無線インターフェースを介して、前記第２の特定の信号を受信し、
   前記第２のフォーマット情報が、前記第２の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第２の特定の信号は受信されず、
   前記第１の判断部は、さらに、前記関連情報が前記第２の特定の信号に含まれるのか否かを判断し、
   前記抽出部は、さらに、前記関連情報が前記第２の特定の信号に含まれると判断される場合に、前記第２の特定の信号に含まれる前記特定の識別情報を抽出し、
   前記関連情報が前記第２の特定の信号に含まれないと判断される場合に、前記第２の特定の信号に含まれる情報は抽出されず、
   前記第１の認証部は、さらに、前記第２の特定の信号から前記特定の識別情報が抽出される場合に、抽出済みの前記特定の識別情報を利用して、前記第２の対象装置の認証を実行し、
   前記関連情報が前記第２の特定の信号に含まれないと判断される場合に、前記第２の特定の信号に含まれる情報を利用した認証は実行されない、通信装置。
2. 前記通信装置は、さらに、
   前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第１の識別情報とは異なる識別情報を利用して、前記第１の対象装置の認証を実行する第２の認証部を備える、請求項１に記載の通信装置。
3. 前記第２の認証部は、前記第１の応答信号に含まれる第２の識別情報であって、前記第１の識別情報とは異なる前記第２の識別情報を利用して、前記第１の対象装置の認証を実行する、請求項２に記載の通信装置。
4. 前記通信装置は、さらに、
   前記第１の応答信号が受信される場合に、前記第１の応答信号を利用して、前記第２の識別情報を認証に利用可能であるのか否かを判断する第２の判断部を備え、
   前記第２の認証部は、前記第２の識別情報を認証に利用可能であると判断される場合に、前記第２の識別情報を利用して、前記第１の対象装置の認証を実行し、
   前記第２の識別情報を認証に利用可能でないと判断される場合に、前記第２の識別情報を利用した前記第１の対象装置の認証は実行されない、請求項３に記載の通信装置。
5. 前記通信装置は、さらに、
   前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第１の対象装置から、前記無線インターフェースを介して、前記所定のフォーマットに依存しない非依存信号を受信する第４の受信部を備え、
   前記第２の認証部は、前記非依存信号が、前記第１の識別情報とは異なる第３の識別情報を含む場合に、前記第３の識別情報を利用して、前記第１の対象装置の認証を実行する、請求項２から４のいずれか一項に記載の通信装置。
6. 前記通信装置は、さらに、
   前記第１の対象装置から前記第１の応答信号が受信される場合に、前記第１の応答信号を利用して、前記第１の対象装置が前記所定規格で定められている所定の通信プロトコルをサポートしているのか否かを判断する第３の判断部を備え、
   前記第２の受信部は、前記第１の対象装置が前記所定の通信プロトコルをサポートしていると判断される場合に、前記第１の対象装置から前記第１のフォーマット情報を受信し、
   前記第１の対象装置が前記所定の通信プロトコルをサポートしていないと判断される場合に、前記第１のフォーマット情報は受信されない、請求項１から５のいずれか一項に記載の通信装置。
7. 前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格である、請求項１から６のいずれか一項に記載の通信装置。
8. 前記所定のフォーマットは、ＮＤＥＦ（NFC Data Exchange Formatの略）である、請求項７に記載の通信装置。
9. 前記第１の受信部は、前記所定規格で定められている第１の通信レイヤを利用して、前記所定規格で定められている第２の通信レイヤであって、前記第１の通信レイヤよりも上位である前記第２の通信レイヤを利用せずに、前記第１の応答信号を受信し、
   前記第２の受信部は、前記第２の通信レイヤを利用して、前記第１のフォーマット情報を受信し、
   前記第３の受信部は、前記第２の通信レイヤを利用して、前記第１の特定の信号を受信する、請求項１から８のいずれか一項に記載の通信装置。
10. 前記通信装置が第１の動作状態に設定されている間に、前記第１の対象装置から前記第１の応答信号が受信される場合に、
    前記第２の受信部は、前記第１のフォーマット情報を受信し、
    前記第３の受信部は、前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記第１の対象装置から前記第１の特定の信号を受信し、
    前記第１の判断部は、前記関連情報が前記第１の特定の信号に含まれるか否かを判断し、
    前記抽出部は、前記関連情報が前記第１の特定の信号に含まれると判断される場合に、前記第１の識別情報を抽出し、
    前記第１の認証部は、前記第１の特定の信号から前記第１の識別情報が抽出される場合に、前記第１の識別情報を利用して、前記第１の対象装置の認証を実行し、
    前記通信装置は、さらに、
    前記通信装置が前記第１の動作状態とは異なる第２の動作状態に設定されている間に、前記第１の対象装置から前記第１の応答信号が受信される場合に、前記無線インターフェースを介して、無線設定情報を前記第１の対象装置に送信する第２の送信部を備え、
    前記無線設定情報は、前記通信装置と前記第１の対象装置との間に、前記無線インターフェースとは異なるインターフェースを介した無線接続を確立するための情報である、請求項１から９のいずれか一項に記載の通信装置。
11. 前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格であり、
    前記通信装置は、さらに、
    前記無線インターフェースのモード状態を制御するインターフェース制御部を備え、
    前記インターフェース制御部は、
    前記通信装置の動作状態が前記第１の動作状態から前記第２の動作状態に変更される場合に、前記無線インターフェースのモード状態を、前記ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モード及びＣＥ（Card Emulationの略）モードのうちの少なくとも一方のモードが有効化されている第１のモード状態に設定し、
    前記通信装置の動作状態が前記第２の動作状態から前記第１の動作状態に変更される場合に、前記無線インターフェースのモード状態を、前記ＮＦＣ規格の前記Ｐ２Ｐモード及びＣＥモードが無効化されていると共に、前記ＮＦＣ規格のＲ／Ｗ（Reader/Writerの略）モードが有効化されている第２のモード状態に設定する、請求項１０に記載の通信装置。
12. 通信装置のためのコンピュータプログラムであって、
    前記通信装置に搭載されるコンピュータに、以下の処理、即ち、
    無線インターフェースを介して、所定規格で定められている２種以上の変調方式であって、第１の変調方式と、前記第１の変調方式とは異なる第２の変調方式と、を含む前記２種以上の変調方式に対応するポーリング信号を順次送信する第１の送信処理であって、前記無線インターフェースは、前記所定規格に従った無線通信を実行するためのインターフェースである、前記第１の送信処理と、
    前記第１の変調方式に対応する第１のポーリング信号の送信に応じて、第１の対象装置から、前記無線インターフェースを介して、前記第１のポーリング信号に対する第１の応答信号を受信する第１の受信処理と、
    前記第１の対象装置から前記第１の応答信号が受信される場合に、前記第１の対象装置から、前記無線インターフェースを介して、第１のフォーマット情報を受信する第２の受信処理であって、前記第１のフォーマット情報は、前記第１の対象装置が、前記所定規格で定められている所定のフォーマットであって、前記第１の対象装置から前記通信装置に送信される第１の特定の信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示し、所定のアプリケーションソフトウェアが前記第１の対象装置にインストールされている場合に、当該情報は、前記所定のアプリケーションソフトウェアによって生成される第１の識別情報であって、前記第１の対象装置の認証に利用される前記第１の識別情報を含む、前記第２の受信処理と、
    前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記第１の対象装置から、前記無線インターフェースを介して、前記第１の特定の信号を受信する第３の受信処理であって、前記第１のフォーマット情報が、前記第１の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第１の特定の信号は受信されない、前記第３の受信処理と、
    前記所定のアプリケーションソフトウェアに関連する関連情報が前記第１の特定の信号に含まれるのか否かを判断する第１の判断処理と、
    前記関連情報が前記第１の特定の信号に含まれると判断される場合に、前記第１の特定の信号に含まれる前記第１の識別情報を抽出する抽出処理と、前記関連情報が前記第１の特定の信号に含まれないと判断される場合に、前記第１の特定の信号に含まれる情報は抽出されない、前記抽出処理と、
    前記第１の特定の信号から前記第１の識別情報が抽出される場合に、抽出済みの前記第１の識別情報を利用して、前記第１の対象装置の認証を実行する第１の認証処理であって、前記関連情報が前記第１の特定の信号に含まれないと判断される場合に、前記第１の特定の信号に含まれる情報を利用した認証は実行されない、前記第１の認証処理と、
    を実行させ、
    前記第１の受信処理は、さらに、前記第２の変調方式に対応する第２のポーリング信号の送信に応じて、第２の対象装置から、前記無線インターフェースを介して、前記第２のポーリング信号に対する第２の応答信号を受信し、
    前記第２の受信処理は、さらに、前記第２の対象装置から前記第２の応答信号が受信される場合に、前記第２の対象装置から、前記無線インターフェースを介して、第２のフォーマット情報を受信し、
    前記第２のフォーマット情報は、前記第２の対象装置が、前記第２の対象装置から前記通信装置に送信される第２の特定の信号内に情報を記述するための前記所定のフォーマットをサポートしているのか否かを示し、
    前記所定のアプリケーションソフトウェアが前記第２の対象装置にインストールされている場合に、当該情報は、前記所定のアプリケーションソフトウェアによって生成される特定の識別情報であって、前記第２の対象装置の認証に利用される前記特定の識別情報を含み、
    前記第３の受信処理は、さらに、前記第２のフォーマット情報が、前記第２の対象装置が前記所定のフォーマットをサポートしていることを示す場合に、前記第２の対象装置から、前記無線インターフェースを介して、前記第２の特定の信号を受信し、
    前記第２のフォーマット情報が、前記第２の対象装置が前記所定のフォーマットをサポートしていないことを示す場合に、前記第２の特定の信号は受信されず、
    前記第１の判断処理は、さらに、前記関連情報が前記第２の特定の信号に含まれるのか否かを判断し、
    前記抽出処理は、さらに、前記関連情報が前記第２の特定の信号に含まれると判断される場合に、前記第２の特定の信号に含まれる前記特定の識別情報を抽出し、
    前記関連情報が前記第２の特定の信号に含まれないと判断される場合に、前記第２の特定の信号に含まれる情報は抽出されず、
    前記第１の認証処理は、さらに、前記第２の特定の信号から前記特定の識別情報が抽出される場合に、抽出済みの前記特定の識別情報を利用して、前記第２の対象装置の認証を実行し、
    前記関連情報が前記第２の特定の信号に含まれないと判断される場合に、前記第２の特定の信号に含まれる情報を利用した認証は実行されない、コンピュータプログラム。

Images