JP6668890B2 - 通信装置 - Google Patents

Description

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

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

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

例えば、スマートフォンなどの携帯端末のＯＳ（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」に従った通信である。

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

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

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

（認証カード５０の構成）
認証カード５０は、ＮＦＣタグであるＮＦＣＩ／Ｆ５２を備える。認証カード５０は、通常、ＯＳソフトウェア及びアプリケーションを有さない。ＮＦＣＩ／Ｆ５２は、タイプＡ、Ｂ、Ｆ、及び、Ｖのいずれか１つのタイプに対応する（換言すると、１つのタイプのみをサポートしている）。タイプＡに対応するＮＦＣＩ／Ｆ５２は、通信規格「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などの認証カード５０であると判断する。

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

Ｓ３３０において、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２を介して、Ｔ３Ｔ層を利用した通信（以下では「Ｔ３Ｔ通信」と呼ぶ）を、対象装置である携帯端末７０と実行する。ＣＰＵ３２は、Ｔ３Ｔ通信において、要求信号を携帯端末７０に送信し、携帯端末７０からのＦｏｒｍａｔ信号１６０を受信する。Ｆｏｒｍａｔ信号１６０は、図４のＦｏｒｍａｔ信号１２０と同様である。以降のＳ３３２〜Ｓ３３８は、図４のＳ２３２〜Ｓ２３８と同様であり、Ｓ３３４で受信されるＮＤＥＦ信号１６２は、図４のＮＤＥＦ信号１２２と同様である。ＣＰＵ３２は、Ｓ３３０〜Ｓ３３８の処理を実行して、生成ＩＤを抽出して正常ＥＮＤとして処理を終了するか、ＩＤの抽出に失敗してエラーＥＮＤとして処理を終了する。

（タイプＶに対応するＩＤ抽出処理）
続いて、図示省略しているが、図３のＳ１３２又はＳ１５２でタイプＶが特定された場合の処理を説明する。対象装置がタイプＶに対応する場合には、対象装置は、携帯端末７０であることはあり得ず、認証カード５０である。従って、ＣＰＵ３２は、タイプＶを特定した場合には、Ｐｏｌｌｉｎｇ信号に対する応答信号に含まれるＵＩＤを抽出する。この場合、Ｓ１４０又はＳ１６０では、必ずＹＥＳと判断される。なお、タイプＶに対応するＵＩＤのデータサイズは、８バイトである。

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

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

（ケースＡ；図６）
ケースＡでは、対象装置は、通信タイプがタイプＡに対応するMifare系の認証カード５０Ａである。認証カード５０Ａには、ＮＦＣＩＤ１「Ａ３」が予め割り当てられている。

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

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

ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＦＦを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていないと判断し（図４のＳ２００でＮＯ）、対象装置がMifare系の認証カード５０Ａであると判断する。また、ＭＦＰ１０は、ＳＥＬ信号内のカードタイプを示す情報に基づいて、認証カード５０Ａのカードタイプを特定する（Ｓ２１０）。Ｔ４０では、ＭＦＰ１０は、ＳＤＤ信号から、特定済みのカードタイプに対応するデータサイズを有するＮＦＣＩＤ１「Ａ３」を抽出する（Ｓ２１２）。Ｔ４２では、ＭＦＰ１０は、ユーザ情報に対応付けてＮＦＣＩＤ１「Ａ３」を認証ＩＤとしてユーザテーブル４０に登録する（図３のＳ１４２）。なお、Ｔ４２が完了すると、ＭＦＰ１０は、Ｔ２０でログインしたユーザをログオフさせる。

Ｔ４２にて認証カード５０Ａの認証ＩＤのユーザテーブル４０への登録が完了した後に、ユーザが認証カード５０ＡをＭＦＰ１０に再び近づけると、Ｔ５０において、ＭＦＰ１０は、Ｔ３０と同様に、タイプＡの各応答信号を受信する（Ｓ１５０でＹＥＳ）。この場合、ＭＦＰ１０は、タイプＡを特定する（Ｓ１５２）。その後のＴ６０は、Ｔ４０と同様である。

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

（ケースＢ；図６）
ケースＢでは、対象装置は、通信タイプがタイプＡに対応するMifare Desfire系の認証カード５０Ｂである。認証カード５０Ｂには、ＮＦＣＩＤ１「Ａ４」が予め割り当てられている。

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

ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＦＦを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていないと判断する（Ｓ２２０でＮＯ）。そして、ＭＦＰ１０は、ＳＥＮＳ信号内のデータサイズ情報が７バイトを示すので（Ｓ２２２でＹＥＳ）、対象装置がMifare Desfire系の認証カード５０Ｂであると判断する。この結果、ＭＦＰ１０は、Ｔ１４０において、ＳＤＤ信号からＮＦＣＩＤ１「Ａ４」を抽出し（Ｓ２１２）、Ｔ１４２において、ＮＦＣＩＤ１「Ａ４」を利用した認証を実行する（図３のＳ１６２）。

（ケースＣ；図７）
図７のケースＣでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ａであって、Ｐ２Ｐ通信を実行可能な携帯端末７０Ａである。携帯端末７０Ａには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ５」が割り当てられている。

ユーザが携帯端末７０ＡをＭＦＰ１０に近づけて、携帯端末７０ＡがＭＦＰ１０からＰｏｌｌｉｎｇ信号を受信すると、Ｔ２２８において、携帯端末７０ＡのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ１「Ａ６」として決定する。

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

ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＮを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていると判断する（Ｓ２２０でＹＥＳ）。これにより、ＭＦＰ１０は、対象装置がＰ２Ｐ通信を実行可能な携帯端末７０Ａであると判断する。

Ｔ２３２において、ＭＦＰ１０は、携帯端末７０Ａから、Ｆｏｒｍａｔ情報を含むＦｏｒｍａｔ信号と、ＮＤＥＦ領域を含むＮＤＥＦ信号と、を含むＴ４Ｔの各応答信号を受信する。具体的には、ＭＦＰ１０は、まず、Ｆｏｒｍａｔ信号を受信し（Ｓ２３０）、Ｆｏｒｍａｔ情報が、携帯端末７０ＡがＮＤＥＦをサポートしていることを示すので（Ｓ２３２でＹＥＳ）、さらに、ＮＤＥＦ信号を受信する（Ｓ２３４）。ＭＦＰ１０は、ＮＤＥＦ領域にベンダ情報が含まれるので（Ｓ２３６でＹＥＳ）、Ｔ２４０において、ＮＤＥＦ領域から生成ＩＤ「Ａ５」を抽出し（Ｓ２３８）、Ｔ２４２において、生成ＩＤ「Ａ５」を利用した認証を実行する（図３のＳ１６２）。

（ケースＤ；図７）
ケースＤでは、対象装置は、通信タイプがタイプＡに対応する携帯端末７０Ｂであって、実際にはＰ２Ｐ通信を実行可能であるにも関わらず、ＳＥＬ信号内の第７ビットにＯＦＦを記述する携帯端末７０Ｂである。携帯端末７０Ｂには、認証アプリケーション７８の初回起動時に生成された生成ＩＤ「Ａ７」が割り当てられている。

Ｔ２４８において、携帯端末７０ＢのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ１「Ａ８」として決定する。

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

ＭＦＰ１０は、ＳＥＬ信号内の第６ビットがＯＮを示すので、対象装置がＩＳＯ＿ＤＥＰをサポートしていると判断し（図４のＳ２００でＹＥＳ）、ＳＥＬ信号内の第７ビットがＯＦＦを示すので対象装置がＮＦＣ＿ＤＥＰをサポートしていないと判断する（Ｓ２２０でＮＯ）。そして、ＭＦＰ１０は、ＳＥＮＳ信号内のデータサイズ情報が４バイトを示すので（Ｓ２２２でＮＯ）、対象装置がＰ２Ｐ通信を実行不可能な携帯端末７０Ｂであると判断する。その後のＳ２５２〜Ｓ２６２は、ケースＣのＴ２３２〜Ｔ２４２と同様である。

（ケースＥ；図８）
ケースＥでは、対象装置は、通信タイプがタイプＦに対応するFeliCa Standard 、FeliCa Liteなどの認証カード５０Ｃである。認証カード５０Ｃには、ＮＦＣＩＤ２「Ａ９」が予め割り当てられている。

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

ＭＦＰ１０は、ＰＡＤ０が示すＩＣタイプ「０１ｈ」が所定タイプを示さないので（図５のＳ３００でＮＯ）、対象装置がFeliCa Standard 、FeliCa Liteなどの認証カード５０Ｃであると判断する。この結果、ＭＦＰ１０は、Ｔ３４０において、ＳＥＮＳＦ信号からＮＦＣＩＤ２「Ａ９」を抽出し（Ｓ３１２）、Ｔ３４２において、ＮＦＣＩＤ２「Ａ９」を利用した認証を実行する（図３のＳ１６２）。

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

Ｔ３４８において、携帯端末７０ＣのＯＳソフトウェア７４は、ランダムに文字列を生成して、当該文字列をＮＦＣＩＤ２「Ａ１１」として決定する。

Ｔ３５０において、ＭＦＰ１０は、タイプＦのＰｏｌｌｉｎｇ信号の送信に応じて、携帯端末７０Ｃから、ＳＥＮＳＦ信号を含むタイプＦの応答信号を受信する（Ｓ１５０でＹＥＳ）。ＳＥＮＳＦ信号は、ＩＣタイプ「０６ｈ」を示すＰＤＡ０と、ＮＦＣＩＤ２「Ａ１１」と、を含む。この場合、ＭＦＰ１０は、タイプＦを特定する（Ｓ１５２）。

ＭＦＰ１０は、ＰＡＤ０が示すＩＣタイプ「０６ｈ」が所定タイプを示すので（図５のＳ３００でＹＥＳ）、対象装置が携帯端末７０Ｃであると判断する。その後のＴ３５２〜Ｔ３６２は、図７のケースＣのＴ２３２〜Ｔ２４２と同様である。

（本実施例の効果）
上述のように、認証カード５０のＮＦＣＩＤ１、ＮＦＣＩＤ２、ＵＩＤは、固定的なＩＤであり、さらに、ユニークさが保証されているので、認証に適している。一方、携帯端末７０のＯＳソフトウェア７４によって準備されるＮＦＣＩＤ１又はＮＦＣＩＤ２は、ＮＦＣ通信が実行される毎に決定されるので、固定的なＩＤではなく、認証に適していない。また、ＯＳソフトウェア７４の中には、予め決められている固定的なＩＤをＮＦＣＩＤ１又はＮＦＣＩＤ２として利用する特定のＯＳソフトウェアが存在し得る。このような特定のＯＳソフトウェアは、固定的なＩＤを利用するが、当該特定のＯＳソフトウェアを有する複数の携帯端末の間で同じＩＤがＮＦＣＩＤ１又はＮＦＣＩＤ２として利用される。このようなＩＤは、ユニークさが保証されないので、やはり、認証に適していない。そこで、本実施例では、ＭＦＰ１０は、対象装置が認証カード５０であるのか携帯端末７０であるのかに応じて、認証に利用すべきＩＤを変える。即ち、ＭＦＰ１０は、図４のＳＥＮＳ信号及びＳＥＬ信号に含まれる各情報、又は、図５のＳＥＮＳＦ信号に含まれるＰＡＤ０を利用して、対象装置が認証カード５０であるのか携帯端末７０であるのかを判断する（図４のＳ２００、Ｓ２２０、Ｓ２２２、図５のＳ３００）。そして、ＭＦＰ１０は、対象装置が認証カード５０であると判断する場合には、ＮＦＣＩＤ１又はＮＦＣＩＤ２を利用した認証を実行し（図４のＳ２１２、図５のＳ３１２、図３のＳ１６２）、対象装置が携帯端末７０であると判断する場合には、Ｔ４Ｔ通信によって受信されるＮＤＥＦ領域内の生成ＩＤを利用した認証を実行する（図４のＳ２３８、図５のＳ３３８、図３のＳ１６２）。ここで、生成ＩＤは、携帯端末７０の認証アプリケーション７８によって生成される固定的かつユニークなＩＤである。このために、ＭＦＰ１０は、対象装置が携帯端末７０である場合に、認証に適していないＮＦＣＩＤ１又はＮＦＣＩＤ２を利用せずに、生成ＩＤを利用した認証を適切に実行することができる。

また、本実施例では、ＭＦＰ１０は、タイプＡ、Ｂ、Ｆ、及び、Ｖのいずれに対応する対象装置についても、ＩＤを適切に抽出することができる。特に、ＭＦＰ１０は、タイプＡについては、ＳＥＮＳ信号及びＳＥＬ信号に含まれる各情報に基づいて対象装置を判断し（図４のＳ２００、Ｓ２２０、Ｓ２２）、タイプＦについては、ＳＥＮＳＦ信号に含まれるＰＡＤ０に基づいて対象装置を判断する（図５のＳ３００）。このように、ＭＦＰ１０は、対象装置の判断に利用すべき属性情報をタイプに応じて変えるので、対象装置の種類を適切に判断することができる。

なお、例えば、コンビニエンスストアの端末、駅の改札機、飲み物の自動販売機等は、認証カードの電子マネーと携帯端末の電子マネーとの両方を認証可能である。このような公知の装置は、ＮＦＣＩＤ１又はＮＦＣＩＤ２を認証ＩＤとして利用しているのではなく、さらに、認証カード及び携帯端末を区別することなく、Ｔ３Ｔ通信、Ｔ４Ｔ通信等で受信される所定の信号に記述されたＩＤを認証ＩＤとして利用する。このようなＩＤは、予め決められている規則に従って上記の所定の信号に記述される。しかしながら、このような構成を採用すると、常に、Ｔ１Ｔ〜Ｔ５Ｔ層の通信が必要である。これに対し、本実施例では、ＭＦＰ１０は、対象装置が認証カード５０である場合には、認証カード５０のＮＦＣＩＤ１又はＮＦＣＩＤ２を利用した認証を実行するので、Ｔ１Ｔ〜Ｔ５Ｔ層の通信を実行せずに済む（図４のＳ２００でＮＯ、Ｓ２２２でＹＥＳ、又は、図５のＳ３００でＮＯ）。従って、ＭＦＰ１０は、対象装置が認証カード５０である場合に、認証カード５０の認証を迅速に実行することができる。

（対応関係）
ＭＦＰ１０、認証カード５０、携帯端末７０が、それぞれ、「通信装置」、「第１種の装置」、「第２種の装置」の一例である。表示部１４、ＮＦＣＩ／Ｆ２２、それぞれ、「出力部」、「無線インターフェース」の一例である。認証アプリケーション７８が、「所定のアプリケーション」の一例である。図４では、ＳＥＮＳ信号１００、ＳＤＤ信号１０２及びＳＥＬ信号１０４が、「第１の信号」の一例であり、Ｆｏｒｍａｔ信号１２０及びＮＤＥＦ信号１２２が、「第２の信号」の一例である。また、図５では、ＳＥＮＳＦ信号１４０が、「第１の信号」の一例であり、Ｆｏｒｍａｔ信号１６０及びＮＤＥＦ信号１６２が、「第２の信号」の一例である。図６〜図８では、タイプＡ又はタイプＦの応答信号が、「第１の信号」の一例である。図７、図８では、Ｔ４Ｔ又はＴ３Ｔの応答信号が、「第２の信号」の一例である。タイプＦ、タイプＡが、それぞれ、「第１の通信タイプ」、「第２の通信タイプ」の一例である。アクティビティ層が「第１の通信レイヤ」の一例であり、Ｔ１Ｔ〜Ｔ５Ｔ層が「第２の通信レイヤ」の一例である。

ＮＦＣＩＤ１、ＮＦＣＩＤ２、及び、ＵＩＤが「第１の識別情報」の一例であり、生成ＩＤが、「第２の識別情報」の一例である。ＳＥＮＳ信号１００、ＳＥＬ信号１０４、及び、ＳＥＮＳＦ信号１４０内の各情報が、「属性情報」の一例である。ＳＥＮＳ信号１００内のデータサイズを示す情報、ＳＥＬ信号１０４内の第６ビット、第７ビットが、それぞれ、「第１の情報」、「第２の情報」、「第３の情報」の一例である。７バイト、４バイトが、それぞれ、「第１のデータサイズ」、「第２のデータサイズ」の一例である。ＰＡＤ０、Ｆｏｒｍａｔ情報、ベンダ情報が、それぞれ、「第４の情報」、「第５の情報」、「第６の情報」の一例である。ISO/IEC14443−4、ＮＤＥＦが、それぞれ、「所定規格に準拠した特定規格」、「所定のフォーマット」の一例である。図３のＳ１６４のエラー表示が、「不可情報」の一例である。認証フラグ３８が「ＯＦＦ」である状態、「ＯＮ」である状態が、それぞれ、「第１の動作状態」、「第２の動作状態」の一例である。

図４のＳ２００、２２０、２２２、及び、図５のＳ３００が、「第１の判断部」が実行する処理の一例である。図４のＳ２３２、及び、図５のＳ３３２が、「第２の判断部」が実行する処理の一例である。図４のＳ２３６、及び、図５のＳ３３６が、「第３の判断部」が実行する処理の一例である。

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

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

（変形例２）図４のＳ２２０、Ｓ２２２、及び、Ｓ２３０の処理の順番が異なっていてもよい。例えば、ＣＰＵ３２は、Ｓ２２２の処理を最初に実行し、Ｓ２２２でＮＯの場合に、Ｓ２２０及びＳ２３０の処理を実行してもよい。

（変形例３）例えば、Mifare Desfire系の認証カードが利用されない環境下では、図４のＳ２２０及びＳ２２２を省略して、Ｓ２００でＹＥＳの場合に、対象装置が携帯端末であると判断されてもよい。また、例えば、Ｐ２Ｐ通信を実行不可能な携帯端末が利用されない環境下では、Ｓ２２２を省略して、Ｓ２２０でＹＥＳの場合に、対象装置が携帯端末であると判断され、Ｓ２２０でＮＯの場合に、対象装置が認証カードであると判断されてもよい。また、例えば、Mifare系の認証カードが利用されない環境下では、Ｓ２００を省略して、Ｓ２２０以降の処理が実行されてもよい。即ち、「第１の判断部」は、第１〜第３の情報の全てを利用して判断を実行しなくてもよい。

（変形例４）例えば、タイプＡに対応する対象装置が利用されない環境下では、図４の処理の全部が省略されてもよい。この場合、タイプＦに対応する図５の処理が実行される。即ち、「第１の判断部」は、第１〜第３の情報のいずれも利用せずに、第４の情報を利用して判断を実行してもよい。また、例えば、タイプＦに対応する対象装置が利用されない環境下では、図５の処理の全部が省略されてもよい。この場合、タイプＡに対応する図４の処理が実行される。即ち、「第１の判断部」は、第４の情報を利用せずに、第１〜第３の情報を利用して判断を実行してもよい。

（変形例５）図４のＳ２３０のＴ４Ｔ通信で受信される信号内の所定領域に生成ＩＤが記述されていてもよい。この場合、ＣＰＵ３２は、Ｓ２３０を実行した後に、上記の所定領域から生成ＩＤを抽出する。従って、Ｓ２３２〜Ｓ２３６を省略可能である。即ち、「第２の判断部」及び「第３の判断部」を省略可能である。

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

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

（変形例８）例えば、対象装置がタイプＡに対応する携帯端末７０である場合に、図３のＳ１３０又はＳ１５０において受信される１個の応答信号が、ＮＦＣＩＤ１のデータサイズを示す情報と、ＮＦＣＩＤ１と、ＩＳＯ＿ＤＥＰ及びＮＦＣ＿ＤＥＰをサポートしているか否かの情報と、Ｆｏｒｍａｔ情報と、ＮＤＥＦ領域と、の全てを含んでいてもよい。即ち、「第１の信号」及び「第２の信号」は同じ信号であってもよい。また、例えば、図７において、ＭＦＰ１０は、タイプＡの各応答信号よりも先にＴ４Ｔの応答信号を受信してもよい。即ち、「第２の信号」は、「第１の信号」よりも先に受信されてもよい。一般的に言うと、「第１の信号」及び「第２の信号」を受信する順番は限定されない。

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

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

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

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

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

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

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

Claims (15)

1. 通信装置であって、
   所定規格に従った無線通信を実行するための無線インターフェースと、
   対象装置から、前記無線インターフェースを介して、第１の識別情報と属性情報とを含む第１の信号を受信する第１の受信部と、
   前記属性情報を利用して、前記対象装置が、第１種の装置であるのか、第２種の装置であるのか、を判断する第１の判断部と、
   前記対象装置が前記第１種の装置であると判断される場合に、前記第１の識別情報を利用して、前記対象装置の認証を実行する第１の認証部と、
   前記対象装置が前記第２種の装置であると判断され、かつ、前記対象装置から、前記無線インターフェースを介して、前記第１の識別情報とは異なる第２の識別情報を含む第２の信号が受信される場合に、前記第２の識別情報を利用して、前記対象装置の認証を実行する第２の認証部であって、前記第２の識別情報を含む前記第２の信号は、前記第２種の装置が有する所定のアプリケーションソフトウェアに従って前記通信装置に送信される、前記第２の認証部と、
   を備える通信装置。
2. 前記属性情報は、前記第１の識別情報のデータサイズを示す第１の情報を含み、
   前記第１の判断部は、
   前記第１の情報が、前記第１の識別情報の前記データサイズが第１のデータサイズであることを示す場合に、前記対象装置が前記第１種の装置であると判断し、
   前記第１の情報が、前記第１の識別情報の前記データサイズが前記第１のデータサイズとは異なる第２のデータサイズを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項１に記載の通信装置。
3. 前記属性情報は、前記対象装置が前記所定規格に準拠した特定規格に従った装置であるのか否かを示す第２の情報を含み、
   前記第１の判断部は、
   前記第２の情報が、前記対象装置が前記特定規格に従った装置でないことを示す場合に、前記対象装置が前記第１種の装置であると判断し、
   前記第２の情報が、前記対象装置が前記特定規格に従った装置であることを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項１又は２に記載の通信装置。
4. 前記属性情報は、前記対象装置が前記無線インターフェースを介した双方向通信を実行可能であるのか否かを示す第３の情報を含み、
   前記第１の判断部は、
   前記第３の情報が、前記対象装置が前記双方向通信を実行可能でないことを示す場合に、前記対象装置が前記第１種の装置であると判断し、
   前記第３の情報が、前記対象装置が前記双方向通信を実行可能であることを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項１から３のいずれか一項に記載の通信装置。
5. 前記属性情報は、前記対象装置のインターフェースのＩＣ（Integrated Circuitの略）タイプを示す第４の情報を含み、
   前記第１の判断部は、
   前記第４の情報が、前記ＩＣタイプが所定タイプでないことを示す場合に、前記対象装置が前記第１種の装置であると判断し、
   前記第４の情報が、前記ＩＣタイプが前記所定タイプであることを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項１に記載の通信装置。
6. 前記属性情報は、
   前記第１の信号を受信するための通信タイプが第１の通信タイプである第１の場合に、前記第４の情報を含み、
   前記第１の信号を受信するための前記通信タイプが前記第１の通信タイプとは異なる第２の通信タイプである第２の場合に、前記第４の情報を含まないと共に、前記第１の識別情報のデータサイズを示す第１の情報を含み、
   前記第１の判断部は、前記第１の場合に、前記第４の情報を利用して、前記対象装置が、前記第１種の装置であるのか、前記第２種の装置であるのか、を判断し、
   前記第１の判断部は、前記第２の場合において、
   前記第１の情報が、前記第１の識別情報の前記データサイズが第１のデータサイズであることを示す場合に、前記対象装置が前記第１種の装置であると判断し、
   前記第１の情報が、前記第１の識別情報の前記データサイズが前記第１のデータサイズとは異なる第２のデータサイズであることを示す場合に、前記対象装置が前記第２種の装置であると判断する、請求項５に記載の通信装置。
7. 前記第２の信号は、前記対象装置が所定のフォーマットをサポートしているのか否かを示す第５の情報を含み、
   前記通信装置は、さらに、
   前記対象装置が前記第２種の装置であると判断される場合に、前記第５の情報を利用して、前記対象装置が前記所定のフォーマットをサポートしているのか否かを判断する第２の判断部と、
   前記対象装置が前記所定のフォーマットをサポートしていないと判断される場合に、前記対象装置の認証を実行不可能であることを示す不可情報を出力する出力部と、を備え、
   前記第２の認証部は、前記対象装置が前記所定のフォーマットをサポートしていると判断される場合に、前記第２の信号に含まれる所定の領域であって、前記所定のフォーマットに応じた前記所定の領域から、前記第２の識別情報を抽出する、請求項１から６のいずれか一項に記載の通信装置。
8. 前記第２の信号は、前記対象装置が前記所定のアプリケーションソフトウェアを有するのか否かを示す第６の情報を含み、
   前記通信装置は、さらに、
   前記対象装置が前記第２種の装置であると判断される場合に、前記第６の情報を利用して、前記対象装置が前記所定のアプリケーションソフトウェアを有するのか否かを判断する第３の判断部と、
   前記対象装置が前記所定のアプリケーションソフトウェアを有さないと判断される場合に、前記対象装置の認証を実行不可能であることを示す不可情報を出力する出力部と、を備え、
   前記第２の認証部は、前記対象装置が前記所定のアプリケーションソフトウェアを有すると判断される場合に、前記第２の信号に含まれる前記第２の識別情報を抽出する、請求項１から７のいずれか一項に記載の通信装置。
9. 前記通信装置は、さらに、
   識別情報をメモリに登録するための登録指示が与えられ、かつ、前記対象装置が前記第１種の装置であると判断される場合に、前記第１の識別情報を前記メモリに登録する第１の登録部と、
   前記登録指示が与えられ、かつ、前記対象装置が前記第２種の装置であると判断される場合に、前記第２の識別情報を前記メモリに登録する第２の登録部と、を備え、
   前記第１の認証部は、前記登録指示が与えられることなく、前記対象装置が前記第１種の装置であると判断される場合に、前記第１の識別情報を利用して、前記対象装置の認証を実行し、
   前記第２の認証部は、前記登録指示が与えられることなく、前記対象装置が前記第２種の装置であると判断される場合に、前記第２の識別情報を利用して、前記対象装置の認証を実行する、請求項１から８のいずれか一項に記載の通信装置。
10. 前記通信装置は、さらに、
    前記対象装置が前記第２種の装置であると判断される場合に、前記対象装置から前記第２の信号を受信する第２の受信部を備え、
    前記対象装置が前記第１種の装置であると判断される場合に、前記第２の信号は受信されない、請求項１から９のいずれか一項に記載の通信装置。
11. 前記所定規格は、ＮＦＣ（Near Field Communicationの略）規格であり、
    前記無線インターフェースは、ＮＦＣフォーラムデバイスである、請求項１から１０のいずれか一項に記載の通信装置。
12. 前記通信装置は、さらに、
    前記無線インターフェースのモード状態を制御するインターフェース制御部を備え、
    前記インターフェース制御部は、
    前記通信装置の動作状態が第１の動作状態である場合に、前記無線インターフェースのモード状態を、ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モード及びＣＥ（Card Emulationの略）モードのうちの少なくとも一方のモードが有効化されている第１のモード状態に設定し、
    前記通信装置の動作状態が前記第１の動作状態から第２の動作状態に変更される場合に、前記無線インターフェースのモード状態を、前記第１のモード状態から、前記ＮＦＣ規格の前記少なくとも一方のモードが無効化されていると共に、前記ＮＦＣ規格のＲ／Ｗ（Reader/Writerの略）モードが有効化されている第２のモード状態に変更する、請求項１１に記載の通信装置。
13. 前記第１の信号は、第１の通信レイヤを利用して、前記第１の通信レイヤよりも上位である第２の通信レイヤを利用せずに、受信され、
    前記第２の信号は、前記第２の通信レイヤを利用して、受信される、請求項１から１２のいずれか一項に記載の通信装置。
14. 前記第１種の装置は、カードであり、
    前記第２種の装置は、端末装置である、請求項１から１３のいずれか一項に記載の通信装置。
15. 通信装置のためのコンピュータプログラムであって、
    前記通信装置に搭載されるコンピュータに、以下の各処理、即ち、
    対象装置から、前記通信装置の無線インターフェースを介して、第１の識別情報と属性情報とを含む第１の信号を受信する第１の受信処理と、
    前記属性情報を利用して、前記対象装置が、第１種の装置であるのか、第２種の装置であるのか、を判断する第１の判断処理と、
    前記対象装置が前記第１種の装置であると判断される場合に、前記第１の識別情報を利用して、前記対象装置の認証を実行する第１の認証処理と、
    前記対象装置が前記第２種の装置であると判断され、かつ、前記対象装置から、前記無線インターフェースを介して、前記第１の識別情報とは異なる第２の識別情報を含む第２の信号が受信される場合に、前記第２の識別情報を利用して、前記対象装置の認証を実行する第２の認証処理であって、前記第２の識別情報を含む前記第２の信号は、前記第２種の装置が有する所定のアプリケーションソフトウェアに従って前記通信装置に送信される、前記第２の認証処理と、
    を実行させるコンピュータプログラム。

Images