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