(通信システム2の構成)
図1に示すように、通信システム2は、多機能機(以下では「MFP(Multi-Function Peripheralの略)」と呼ぶ)10と、携帯端末50と、を備える。MFP10と携帯端末50とは、NFC規格の通信方式(即ちNFC方式)の通信を実行可能である。本実施例では、NFC規格は、ISO/IEC21481又はISO/IEC18092の国際標準規格である。NFC方式の通信は、13.56MHz帯の電波を利用した無線通信である。また、MFP10と携帯端末50とは、それぞれ、NFC方式の通信リンクとは異なる通信ネットワークを利用して、有線通信又は無線通信を実行可能である。
(MFP10の構成)
MFP10は、操作部12と、表示部14と、ネットワークインターフェイス(以下では、インターフェイスのことを「I/F」と記載する)16と、印刷実行部18と、スキャン実行部20と、NFC I/F22と、制御部30と、を備える。操作部12は、複数のキーを備える。ユーザは、操作部12を操作することによって、様々な指示をMFP10に入力することができる。表示部14は、様々な情報を表示するためのディスプレイである。ネットワークI/F16は、有線ネットワークに接続するためのI/Fであってもよいし、無線ネットワークに接続するためのI/Fであってもよい。なお、この無線ネットワークは、NFC方式の通信とは異なる無線通信を実行するためのネットワークであり、例えば、IEEE(The Institute of Electrical and Electronics Engineers, Inc.の略)の802.11の規格、及び、それに準ずる規格(例えば802.11a,11b,11g,11n等)に従ったネットワークである。印刷実行部18は、インクジェット方式、レーザ方式等の印刷機構である。スキャン実行部20は、CCD、CIS等のスキャン機構である。
NFC I/F22は、NFC方式の通信を実行するためのインターフェイスである。NFC I/F22は、ネットワークI/F16とは異なるチップによって構成されている。なお、ネットワークI/F16が無線ネットワークに接続するためのI/Fである場合には、ネットワークI/F16とNFC I/F22とは、以下の点で異なる。
即ち、ネットワークI/F16を介した無線通信の通信速度は、NFC I/F22を介した無線通信の通信速度よりも速い。さらに、ネットワークI/F16を介した無線通信における搬送波の周波数は、NFC I/F22を介した無線通信における搬送波の周波数とは異なる。また、MFP10と携帯端末50との距離がおよそ10cm以下である場合に、MFP10は、NFC I/F22を介して、携帯端末50とNFC方式の通信を実行可能である。一方において、MFP10と携帯端末50との距離が、10cm以下である場合でも、10cm以上である場合でも、MFP10は、ネットワークI/F16を介して、携帯端末50と無線通信を実行可能である。即ち、MFP10が、ネットワークI/F16を介して、通信先の機器(例えば携帯端末50)と無線通信を実行可能な最大の距離は、MFP10が、NFC I/F22を介して、通信先の機器と無線通信を実行可能な最大の距離よりも大きい。なお、以下では、ネットワークI/F16を介した無線通信のことを、「ネットワーク無線通信」と呼ぶ。
制御部30は、CPU32とメモリ34とを備える。CPU32は、メモリ34に格納されているプログラム36,38に従って、様々な処理を実行する。メモリ34は、ROM、RAM、ハードディスク等によって構成される。メモリ34は、CPU32によって実行される上記のプログラム36,38を格納する。アプリケーションプログラム36は、CPU32が、OSI参照モデルのアプリケーション層の処理を実行するためのプログラムである。
プロトコルスタック38は、CPU32が、OSI参照モデルのアプリケーション層よりも下位層の処理を実行するためのプログラムである。なお、プロトコルスタック38は、P2P(Peer to Peerの略)プログラムと、R/Wプログラムと、CEプログラムと、を含む。P2Pプログラムは、NFC規格のP2Pモードに従った処理を実行するためのプログラムである。R/Wプログラムは、NFC規格のReader/Writerモードに従った処理を実行するためのプログラムである。CEプログラムは、NFC規格のCE(Card Emulationの略)モードに従った処理を実行するためのプログラムである。これらのプログラムは、NFCフォーラムによって定められたNFC規格に準拠した処理を実行するためのプログラムである。
メモリ34は、さらに、送信フラグとして「0」又は「1」を記憶する。送信フラグは、MFP10が、通信対象の対象データを送信すべきか否かを示すフラグである。即ち、MFP10が対象データを送信すべき状況では、送信フラグは「1」に設定される。また、MFP10が対象データを送信すべきでない状況では、送信フラグは「0」に設定される。
メモリ34は、さらに、通信済フラグとして「0」又は「1」を記憶する。後で詳しく述べるが、MFP10と携帯端末50との間では、一方のデバイスから他方のデバイスに、NFC方式の通信によって、第1の対象データが送信された後に、当該他方のデバイスから当該一方のデバイスに、NFC方式の通信によって、第2の対象データが送信される。以下では、このように、第1の対象データの通信を実行し、次いで、第2の対象データの通信を実行することを、「1セットの通信」と呼ぶ。通信済フラグは、1セットの通信において、第1の対象データの通信が実行された状況であるのか、第1の対象データの通信が実行されていない状況であるのか、を示すフラグである。即ち、第1の対象データの通信が実行された状況では、通信済フラグは「1」に設定される。また、第1の対象データの通信が実行されていない状況では、通信済フラグは「0」に設定される。
(携帯端末50の構成)
携帯端末50は、例えば、携帯電話(例えばスマートフォン)、PDA、ノートPC、タブレットPC、携帯型音楽再生装置、携帯型動画再生装置等である。携帯端末50は、無線ネットワークに接続するためのネットワークI/Fと、NFC I/Fと、を備える。従って、携帯端末50は、ネットワークI/Fを介して、MFP10と無線通信を実行可能であると共に、NFC I/Fを利用して、MFP10と無線通信を実行可能である。
携帯端末50は、MFP10に様々な機能(例えば、印刷機能、スキャン機能等)を実行させるためのアプリケーションプログラム(以下では「MFP用アプリケーション」と呼ぶ)を備える。なお、MFP用アプリケーションは、例えば、MFP10のベンダによって提供されるサーバから携帯端末50にインストールされてもよいし、MFP10と共に出荷されるメディアから携帯端末50にインストールされてもよい。
(通信対象の対象データ)
上記の1セットの通信の対象である第1及び第2の対象データとして、様々なデータが考えられる。第1及び第2の対象データの一例を以下に列挙する。
(第1の例)
MFP10が、携帯端末50から印刷データを受信して、当該印刷データに従った印刷機能を実行すべき状況を想定する。携帯端末50のユーザは、携帯端末50のMFP用アプリケーションを起動させて、MFP10に印刷機能を実行させるための指示を携帯端末50に入力する。この場合、携帯端末50は、NFC方式の通信を利用して、印刷実行指示をMFP10に送信する。印刷実行指示は、印刷データを含まない。
MFP10は、携帯端末50から、NFC I/F22を介して、印刷実行指示を受信する。上述したように、NFC方式の通信の通信速度は、ネットワーク無線通信の通信速度よりも遅い。このために、仮に、携帯端末50からMFP10への印刷データの通信としてNFC方式の通信が利用されると、印刷データの通信に長時間を要する可能性がある。従って、本例では、MFP10が、ネットワーク無線通信を利用して、携帯端末50から印刷データを受信する構成を採用する。このような構成を採用するためには、携帯端末50は、MFP10とネットワーク無線通信を実行するための無線設定を知る必要がある。従って、MFP10は、携帯端末50から印刷実行指示を受信する場合に、NFC I/F22を介して、上記の無線設定を含む応答を携帯端末50に送信する。
これにより、MFP10及び携帯端末50は、NFC方式の通信に代えて、ネットワーク無線通信を実行して、印刷データを通信することができる。従って、MFP10は、印刷機能を実行することができる。本例では、印刷実行指示、無線設定を含む応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
(第2の例)
MFP10が、スキャンを実行してスキャンデータを生成して、当該スキャンデータを携帯端末50に送信するスキャン機能を実行すべき状況を想定する。携帯端末50のユーザは、携帯端末50のMFP用アプリケーションを起動させて、MFP10にスキャン機能を実行させるための指示を携帯端末50に入力する。この場合、携帯端末50は、NFC方式の通信を利用して、スキャン実行指示をMFP10に送信する。
MFP10は、携帯端末50から、NFC I/F22を介して、スキャン実行指示を受信する。上記の第1の例と同様に、仮に、MFP10から携帯端末50へのスキャンデータの通信としてNFC方式の通信が利用されると、スキャンデータの通信に長時間を要する可能性がある。このために、本例では、MFP10が、ネットワーク無線通信を利用して、スキャンデータを携帯端末50に送信する構成を採用する。従って、MFP10は、携帯端末50からスキャン実行指示を受信する場合に、NFC I/F22を介して、無線設定を含む応答を携帯端末50に送信する。
これにより、MFP10及び携帯端末50は、NFC方式の通信に代えて、ネットワーク無線通信を実行して、スキャンデータを通信することができる。従って、MFP10は、スキャン機能を実行することができる。本例では、スキャン実行指示、無線設定を含む応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
(第3の例)
携帯端末50が、MFP10が利用すべき設定情報を、MFP10に送信すべき状況を想定する。上記の設定情報として、例えば、MFP10が印刷機能を実行するための印刷設定情報(例えば、印刷解像度、用紙サイズ等)、MFP10がスキャン機能を実行するためのスキャン設定情報(例えば、スキャン解像度等)、MFP10が通信機能を実行するための通信設定情報(例えば、IPアドレス、サブネットマスク、ゲートウェイアドレス等)を挙げることができる。
携帯端末50のユーザは、携帯端末50のMFP用アプリケーションを起動させて、MFP10が利用すべき設定情報を携帯端末50に入力する。この場合、携帯端末50は、NFC方式の通信を利用して、上記の設定情報をMFP10に送信する。
MFP10は、携帯端末50から、NFC I/F22を介して、設定情報を受信する。MFP10は、受信済みの設定情報を、MFP10が利用すべき設定情報として、メモリ34に格納する。これにより、MFP10は、受信済みの設定情報を利用して、様々な機能を実行することができる。MFP10は、携帯端末50から設定情報を受信する場合に、設定情報を受信したことを示す応答を、NFC I/F22を介して、携帯端末50に送信する。本例では、設定情報、応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
(第4の例)
携帯端末50が、携帯端末50で現在利用されているアドレス帳に含まれるアドレス情報を、MFP10に送信すべき状況を想定する。携帯端末50のユーザは、携帯端末50のMFP用アプリケーションを起動させて、アドレス情報をMFP10に送信するための指示を携帯端末50に入力する。この場合、携帯端末50は、NFC方式の通信を利用して、アドレス情報をMFP10に送信する。
MFP10は、携帯端末50から、NFC I/F22を介して、アドレス情報を受信する。MFP10は、受信済みのアドレス情報を、MFP10で現在利用されているアドレス帳(即ちメモリ34内のアドレス帳)に追加する。これにより、MFP10は、受信済みのアドレス情報を利用して、通信機能を実行することができる。MFP10は、携帯端末50からアドレス情報を受信する場合に、アドレス情報を受信したことを示す応答を、NFC I/F22を介して、携帯端末50に送信する。本例では、アドレス情報、応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
(第5の例)
上記の第1の例では、MFP10が、ネットワーク無線通信を利用して、印刷データを携帯端末50に送信する構成を採用している。これに代えて、例えば、MFP10は、携帯端末50から、NFC I/F22を介して、印刷データを受信してもよい。この場合、MFP10は、印刷データを受信したことを示す応答を、NFC I/F22を介して、携帯端末50に送信してもよい。本例では、印刷データ、応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
(第6の例)
上記の第1〜第5の例では、1セットの通信において、携帯端末50からMFP10への第1の対象データの送信が実行され、その後、MFP10から携帯端末50への第2の対象データの送信が実行される。ただし、1セットの通信において、MFP10から携帯端末50への第1の対象データの送信が実行され、その後、携帯端末50からMFP10への第2の対象データの送信が実行されてもよい。例えば、MFP10は、NFC I/F22を介して、スキャンデータを携帯端末50に送信し、携帯端末50から、NFC I/F22を介して、応答を受信してもよい。本例では、スキャンデータ、応答が、それぞれ、「第1の対象データ」、「第2の対象データ」の一例である。
なお、「第1の対象データ」と「第2の対象データ」の組合せは、上記の第1〜第6の例に限られず、他の組合せであってもよい。即ち、「第1の対象データ」は、通信対象のデータであれば、どのような種類のデータであってもよく、「第2の対象データ」は、第1の対象データを処理することによって生成されるデータ(即ち、第1の対象データとは異なるデータ)であれば、どのような種類のデータであってもよい。なお、第2の対象データを生成する主体は、MDP10であってもよいし、携帯端末50であってもよい。
(NFC規格のモード)
続いて、NFC規格で採用されている各モードについて説明する。NFC規格では、P2Pモード、Reader/Writerモード(以下では「R/Wモード」と簡単に記載する)、及び、CEモードが利用される。なお、以下では、NFC方式の通信を実行可能な機器(MFP10、携帯端末50等)のことを「NFC機器」と呼ぶ。
NFC機器の中には、上記の3つのモードの全てを利用可能な機器も存在するし、上記の3つのモードのうちの1つ又は2つのモードのみを利用可能な機器も存在する。本実施例では、MFP10は、上記の3つのモードの全てを利用可能な機器である。ただし、携帯端末50は、上記の3つのモードの全てを利用可能な機器であってもよいし、上記の3つのモードのうち、R/Wモード及びCEモードの2つのモードのみを利用可能であってもよい。
(P2Pモード)
P2Pモードは、一対のNFC機器の間で双方向通信を実行するためのモードである。
例えば、第1のNFC機器と第2のNFC機器との両方が、P2Pモードに従って動作する状況を想定する。この場合、第1のNFC機器と第2のNFC機器との間で、P2Pモードに従った通信を実行するための通信リンクが確立される。例えば、第1のNFC機器は、通信リンクを利用してデータを第2のNFC機器に送信する。その後、第2のNFC機器は、通常、同じ通信リンクを利用して、他のデータを第1のNFC機器に送信する。これにより、双方向通信が実現される。NFCフォーラムによって定められるタグタイプがタイプAであるNFC機器、及び、タグタイプがタイプFであるNFC機器は、P2Pモードに従って動作することができるが、タグタイプがタイプBであるNFC機器は、P2Pモードに従って動作することができない。
(R/Wモード、CEモード)
R/Wモード及びCEモードは、一対のNFC機器の間で単方向通信を実行するためのモードである。CEモードは、NFC機器がNFCフォーラムによって定められた形式である「カード」として動作するためのモードである。タグタイプがタイプAであるNFC機器と、タグタイプがタイプFであるNFC機器と、タグタイプがタイプBであるNFC機器と、のいずれも、CEモードに従って動作することができる。R/Wモードは、さらに、Readerモードと、Writerモードと、に区分される。Readerモードは、CEモードでカードとして動作するNFC機器からデータを読み出すためのモードである。Writerモードは、CEモードでカードとして動作するNFC機器にデータを書き込むためのモードである。なお、Readerモードでは、NFC規格のカードからデータを読み出すこともできる。また、Writerモードでは、NFC規格のカードにデータを書き込むこともできる。
例えば、第1のNFC機器が、Readerモードに従って動作し、第2のNFC機器が、CEモードに従って動作する状況を想定する。この場合、第1のNFC機器と第2のNFC機器との間で、Readerモード及びCEモードに従った通信を実行するための通信リンクが確立される。第1のNFC機器は、第2のNFC機器内の擬似的なカードからデータを読み出すための動作を実行することによって、当該データを第2のNFC機器から受信する。
また、例えば、第1のNFC機器が、Writerモードに従って動作し、第2のNFC機器が、CEモードに従って動作する状況を想定する。この場合、第1のNFC機器と第2のNFC機器との間で、Writerモード及びCEモードに従った通信を実行するための通信リンクが確立される。第1のNFC機器は、第2のNFC機器内の擬似的なカードにデータを書き込むための動作を実行することによって、当該データを第2のNFC機器に送信する。
上述したように、一対のNFC機器がNFC方式の通信を実行するためには、様々なモードの組合せが考えられる。例えば、MFP10及び携帯端末50のモードの組合せとして、以下の5つのパターン、即ち、「P2Pモード、P2Pモード」、「Readerモード、CEモード」、「Writerモード、CEモード」、「CEモード、Readerモード」、「CEモード、Writerモード」が考えられる。
(Poll動作とListen動作)
NFC機器は、Poll動作及びListen動作を実行可能である。より具体的に言うと、例えば、MFP10では、CPU32が、プログラム36,38に従ってPoll動作及びListen動作を実行するのではなく、NFC I/F22が、Poll動作及びListen動作を実行する。Poll動作は、ポーリング信号を送信して、ポーリング信号に対するレスポンス信号を受信する動作である。また、Listen動作は、ポーリング信号を受信して、ポーリング信号に対するレスポンス信号を送信する動作である。
MFP10のNFC I/F22は、Poll動作を実行するためのPollモードと、Listen動作を実行するためのListenモードと、Poll動作及びListen動作のどちらも実行しないモード(以下では「不実行モード」と呼ぶ)と、のうちのいずれかのモードで動作可能である。NFC I/F22は、Pollモード、Listenモード、及び、不実行モードで、順次動作する。例えば、NFC I/F22は、Pollモードで動作し、その後、Listenモードで動作し、その後、不実行モードで動作するという1セットの動作を実行する。NFC I/F22は、上記の1セットの動作を繰り返し実行する。
Pollモードでは、NFC I/F22は、ポーリング信号を送信して、レスポンス信号を受信することを監視する。具体的に言うと、NFC I/F22は、(1)タグタイプがタイプAであるNFC機器が応答可能なポーリング信号(即ちタイプAに対応するポーリング信号)を送信して、レスポンス信号の受信を所定時間監視し、(2)レスポンス信号を受信しなければ、タグタイプがタイプBであるNFC機器が応答可能なポーリング信号(即ちタイプBに対応するポーリング信号)を送信して、レスポンス信号の受信を所定時間監視し、(3)レスポンス信号を受信しなければ、タグタイプがタイプFであるNFC機器が応答可能なポーリング信号(即ちタイプFに対応するポーリング信号)を送信して、レスポンス信号の受信を所定時間監視する、という動作を繰り返す。NFC I/F22が所定時間内にNFC機器からレスポンス信号を受信する場合には、当該NFC機器は、当該レスポンス信号の送信の直前に受信したポーリング信号に対応するタイプのNFC機器であると言える。NFC I/F22は、レスポンス信号を受信する場合に、さらに、当該レスポンス信号の送信元のNFC機器が、どのモードで動作可能であるのかを問い合わせる問い合わせ信号を、当該NFC機器に送信する。この結果、NFC I/F22は、当該NFC機器から動作可能モード信号を受信する。動作可能モード信号は、当該NFC機器がP2Pモード及びCEモードで動作可能であることを示すか、あるいは、当該NFC機器がCEモードのみで動作可能であることを示す。
Listenモードでは、NFC I/F22は、ポーリング信号を受信することを監視して、ポーリング信号を受信すると、レスポンス信号を送信する。NFC I/F22は、NFC I/F22に対応するタイプのポーリング信号を受信する場合にのみ、ポーリング信号の送信元のNFC機器にレスポンス信号を送信する。NFC I/F22は、当該NFC機器にレスポンス信号を送信する場合に、当該NFC機器から問い合わせ信号を受信して、動作可能モード信号を当該NFC機器に送信する。不実行モードでは、NFC I/F22は、ポーリング信号を送信せず、さらに、ポーリング信号を受信しても、レスポンス信号を送信しない。
携帯端末50も、上記の1セットの動作を繰り返し実行する。従って、例えば、MFP10と携帯端末50との間の距離が10cm未満であり、かつ、NFC I/F22がPollモードで動作する期間と、携帯端末50がListenモードで動作する期間と、が一致する場合には、NFC I/F22は、ポーリング信号を携帯端末50に送信して、レスポンス信号を携帯端末50から受信するPoll動作を実行する。また、例えば、MFP10と携帯端末50との間の距離が10cm未満であり、NFC I/F22がListenモードで動作する期間と、携帯端末50がPollモードで動作する期間と、が一致すると、NFC I/F22は、ポーリング信号を携帯端末50から受信して、レスポンス信号を携帯端末50に送信するListen動作を実行する。
NFC I/F22がPoll動作又はListen動作を実行すると、以降の通信のための各処理は、CPU32に引き継がれる。具体的に言うと、MFP10のNFC I/F22がPoll動作を実行し、携帯端末50がListen動作を実行する場合には、携帯端末50がどのモードの動作を実行可能であるのかを示す情報(即ち、受信済みの動作可能モード信号が示す情報)が、NFC I/F22からCPU32に受け渡される。CPU32は、NFC I/F22から受け渡された情報に基づいて、MFP10がどのモードで動作すべきかを決定する。具体的には、MFP10が全てのモードで動作可能であり、かつ、受信済みの動作可能モード信号がP2Pモード及びCEモードで動作可能であることを示す場合には、CPU32は、MFP10がP2Pモードで動作すべきことを決定する。なお、変形例では、この場合に、CPU32は、MFP10がCEモードで動作すべきことを決定してもよい。また、MFP10が全てのモードで動作可能であり、かつ、受信済みの動作可能モード信号がCEモードのみで動作可能であることを示す場合には、CPU32は、MFP10がR/Wモードで動作すべきことを決定する。なお、仮に、MFP10がR/Wモードのみで動作可能であり、かつ、受信済みの動作可能モード信号がCEモードで動作可能であることを示す場合には、CPU32は、MFP10がR/Wモードで動作すべきことを決定する。後で詳しく述べるが、その後、CPU32は、MFP10が動作すべきモード(即ちCPU32によって決定されたモード)に対応するActivationコマンドを携帯端末50に送信する(図4のS112、図5のS160参照)。Activationコマンドは、NFC規格で採用されているコマンドであり、MFP10と携帯端末50との間にNFC方式の通信リンクを確立するためのコマンドである。
なお、NFC規格では、Poll動作を実行したNFC機器(以下では「Poll機器」と呼ぶ)は、P2Pモード及びR/Wモードで動作することができるが、CEモードで動作することができない。従って、上述したように、MFP10がPoll機器である場合には、CPU32は、MFP10がP2Pモード又はR/Wモードで動作すべきことを決定する。
一方において、MFP10のNFC I/F22がListen動作を実行し、携帯端末50がPoll動作を実行する場合には、CPU32は、携帯端末50が動作すべきモードに対応するActivationコマンドを、携帯端末50から受信する(図2のS10参照)。CPU32は、P2Pモードに対応するActivationコマンドを受信する場合に、MFP10がP2Pモードで動作すべきことを決定し、R/Wモードに対応するActivationコマンドを受信する場合に、MFP10がCEモードで動作すべきことを決定する。
なお、NFC規格では、Listen動作を実行したNFC機器(以下では「Listen機器」と呼ぶ)は、P2Pモード及びCEモードで動作することができるが、R/Wモードで動作することができない。従って、上述したように、MFP10がPoll機器である場合には、CPU32は、MFP10がP2Pモード又はCEモードで動作すべきことを決定する。
上述したように、CPU32は、NFC I/F22がPoll動作又はListen動作を実行すれば、MFP10の近傍に携帯端末50が存在することを知ることができ、さらに、MFP10がどのモードで動作すべきかを知ることができ、その後の通信のための各処理(後述の図2〜図5参照)を実行する。
(MFP10が実行する処理;図2〜図5)
続いて、図2〜図5を参照して、MFP10が実行する処理について説明する。なお、CPU32は、メモリ34内のプログラム36,38に従って、図2〜図5の各処理を実行する。以下では、まず、NFC I/F22がListen動作を実行した場合に、CPU32が実行する処理(図2及び図3;以下では「MFPのListen処理」と呼ぶ)の内容を説明し、次いで、NFC I/F22がPoll動作を実行した場合に、CPU32が実行する処理(図4及び図5;以下では「MFPのPoll処理」と呼ぶ)の内容を説明する。
(MFPのListen処理;図2及び図3)
上述したように、NFC I/F22がListen動作を実行する場合(即ち携帯端末50がPoll動作を実行する場合)には、携帯端末50は、携帯端末50が動作すべきモードに対応するActivationコマンドをMFP10に送信する。S10において、CPU32は、携帯端末50から、NFC I/F22を介して、Activationコマンドを受信する。
次いで、S12において、CPU32は、MFP10が、P2Pモードで動作すべきか、CEモードで動作すべきかを判断する。上述したように、MFP10は、P2Pモード、R/Wモード、及び、CEモードの3つのモードのうちの全てを利用可能なNFC機器である。一方において、携帯端末50は、3つのモードのうちの全てのモードを利用可能な機器であるかもしれないし、R/Wモード及びCEモードのみを利用可能な機器であるかもしれない。CPU32は、P2Pモードに対応するActivationコマンドを受信する場合に、MFP10がP2Pモードで動作すべきと判断して(図2のS12でYES)、S14に進む。一方において、CPU32は、R/Wモードに対応するActivationコマンドを受信する場合に、MFP10がCEモードで動作すべきと判断して(図2のS12でNO)、図3のS62に進む。
(MFPのListen処理;P2Pモード)
S14では、CPU32は、Activationコマンドに対するレスポンスコマンド(即ちOKコマンド)を、NFC I/F22を介して、携帯端末50に送信する。これにより、MFP10と携帯端末50との間にNFC方式の通信リンクが確立される。即ち、CPU32は、Activationコマンドを受信して、OKコマンドを送信することによって、通信リンクを適切に確立することができる。
なお、MFPのListen処理では、MFP10から携帯端末50にActivationコマンドを送信することができない。Poll機器はActivationコマンドを送信することができるが、Listen機器はActivationコマンドを送信することができないからである。
次いで、S16では、CPU32は、確認コマンド応答処理を開始する。確認コマンドは、Poll機器からListen機器に送信されるコマンドであり、通信リンクを維持するための否かを確認するためのコマンドである。上述したように、現時点では、MFP10がListen機器であり、携帯端末50がPoll機器である。従って、確認コマンド応答処理では、CPU32は、携帯端末50から、NFC I/F22を介して、確認コマンドを受信して、確認コマンドに対するレスポンスコマンド(即ちOKコマンド)を、NFC I/F22を介して、携帯端末50に送信する。
なお、フローチャートには示されていないが、CPU32は、S16で確認コマンド応答処理を開始すると、後述のS38が実行されるまで、又は、後述のS44で通信リンクが切断されるまで、確認コマンド応答処理を継続して実行する。
次いで、S18では、CPU32は、メモリ34内の送信フラグが「1」であるのか否かを判断する。なお、上記の1セットの通信において、第1の対象データの通信が実行されていない状況では、通常、送信フラグは「0」に設定される。例えば、対象データに関する上記の第1〜第5の例では、第1の対象データは、携帯端末50からMFP10に送信され、第2の対象データは、MFP10から携帯端末50に送信される。このようなケースでは、第1の対象データの通信が実行されていない状況では、通常、送信フラグは「0」に設定される。この結果、後述のように、MFP10が第1の対象データを携帯端末50から受信することが実現される(S22等参照)。さらに、このようなケースでは、第1の対象データの通信が実行された状況では、送信フラグは「1」に設定される(S28等参照)。この結果、後述のように、MFP10が第2の対象データを携帯端末50に送信することが実現される(S32等参照)。
ただし、対象データに関する上記の第6の例では、第1の対象データは、MFP10から携帯端末50に送信され、第2の対象データは、携帯端末50からMFP10に送信される。例えば、CPU32は、上記の第6の例に従って、スキャンデータ(即ち第1の対象データ)を生成すると、図2〜図5のフローチャートに示されていない処理において、送信フラグを「0」から「1」に変更する。このようなケースでは、上記の1セットの通信において、第1の対象データの通信が実行されていない状況でも、送信フラグは「1」に設定される。この結果、後述のように、MFP10が第1の対象データを携帯端末50に送信することが実現される(S32等参照)。さらに、このようなケースでは、第1の対象データの通信が実行された状況では、送信フラグは「0」に設定される(S36等参照)。この結果、後述のように、MFP10が第2の対象データを携帯端末50から受信することが実現される(S22等参照)。
CPU32は、メモリ34内の送信フラグが「1」である場合に、S18でYESと判断して、S30に進む。一方において、CPU32は、メモリ34内の送信フラグが「0」である場合に、S18でNOと判断して、S20に進む。
S20では、CPU32は、NFC I/F22を介して、携帯端末50とネゴシエーションを実行する。具体的に言うと、CPU32は、まず、MFP10がP2Pモードのクライアントとして動作することを決定する。次いで、CPU32は、MFP10がクライアントとして動作し、携帯端末50がP2Pモードのサーバとして動作するように、Simple NDEF Exchangeプロトコルに従った通信を実行する。これにより、携帯端末50は、クライアント(即ちMFP10)からのリクエストに応じて、処理を実行するサーバとして動作する。なお、NDEFは、NFC data Exchange Formatの略である。
S20では、CPU32は、さらに、MFP10がデータ受信を実行すること(即ち携帯端末50がデータ送信を実行すること)を、携帯端末50に通知する。これにより、携帯端末50は、対象データをMFP10に送信すべきことを知ることができ、対象データをMFP10に送信する。なお、以下では、「対象データ」は、対象データに関する上記の第1〜6の例のうちのいずれの第1の対象データであってもよいし、いずれの第2の対象データであってもよい。
次いで、S22では、CPU32は、S14で確立された通信リンクを利用して、携帯端末50から、NFC I/F22を介して、対象データを受信する。
次いで、S24では、CPU32は、S22で受信された対象データを処理する。例えば、上記の第1又は第2の例では、CPU32は、S22で受信された印刷実行指示又はスキャン実行(即ち第1の対象データ)を解釈して、無線設定(即ち第2の対象データ)を含む応答を生成する。また、例えば、上記の第3の例では、CPU32は、S22で受信された設定情報(即ち第1の対象データ)をメモリ34に記憶させ、設定情報を受信したことを示す応答(即ち第2の対象データ)を生成する。また、例えば、上記の第4の例では、CPU32は、S22で受信されたアドレス情報(即ち第1の対象データ)をメモリ34内のアドレス帳に追加し、アドレス情報を受信したことを示す応答(即ち第2の対象データ)を生成する。また、例えば、上記の第5の例では、CPU32は、S22で受信された印刷データ(即ち第1の対象データ)に従った印刷機能を実行し、印刷データを受信したことを示す応答(即ち第2の対象データ)を生成する。
なお、上記の第6の例では、CPU32は、S22で受信された応答(即ち第2の対象データ)を解釈して、携帯端末50がスキャンデータを受信したことを確認する。この場合、上記の第1〜第5の例とは異なり、CPU32は、第2の対象データを生成する処理を実行しない。即ち、第2の対象データは、携帯端末50によって生成されるデータである。
次いで、S26では、CPU32は、メモリ34内の通信済フラグが「1」であるのか否かを判断する。CPU32は、メモリ34内の通信済フラグが「1」である場合に、S26でYESと判断して、S40に進む。一方において、CPU32は、メモリ34内の通信済フラグが「0」である場合に、S26でNOと判断して、S28に進む。
S28では、CPU32は、メモリ34内の送信フラグを「1」に設定し、メモリ34内の通信済フラグを「1」に設定する。S28を終えると、S38に進む。
S38では、CPU32は、S14で確立された通信リンクを切断するための切断処理を実行する。S38の切断処理の手法として、ソフトウェア的切断処理と、ハードウェア的切断処理と、の2つの手法が考えられる。CPU32は、どちらの手法の切断処理を実行してもよい。
CPU32がソフトウェア的切断処理を実行する場合には、CPU32は、S16で開始された確認コマンド応答処理を終了させる。即ち、CPU32は、携帯端末50から確認コマンドを受信しても、確認コマンドに対するレスポンスコマンド(即ちOKコマンド)を携帯端末50に送信しない。これにより、携帯端末50は、MFP10が通信リンクを維持することを望まないことを知ることができ、通信リンクを切断するためのDeactivationコマンドをMFP10に送信する。
従って、CPU32は、携帯端末50から、NFC I/F22を介して、Deactivationコマンドを受信する。この場合、CPU32は、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を、NFC I/F22を介して、携帯端末50に送信する。これにより、S14で確立された通信リンクが切断される。CPU32は、ソフトウェア的切断処理(確認コマンド応答処理の終了、Activationコマンドの受信、OKコマンドの送信)を実行することによって、通信リンクを適切に切断することができる。
なお、MFPのListen処理では、MFP10から携帯端末50にDeactivationコマンドを送信することはできない。Poll機器はDeactivationコマンドを送信することができるが、Listen機器はDeactivationコマンドを送信することができないからである。
一方において、CPU32がハードウェア的切断処理を実行する場合には、CPU32は、NFC I/F22の動作を一時的に停止させる。具体的に言うと、例えば、CPU32は、NFC I/F22が動作を停止するための指示を、NFC I/F22に送信する。これにより、NFC I/F22は、外部からの信号の受信、外部への信号の送信、Poll動作、Listen動作等を含む全ての動作を一時的に停止する。従って、CPU32は、NFC I/F22を介して、S16で開始された確認コマンド応答処理を実行することができなくなる。
ハードウェア的切断処理が実行されると、ソフトウェア的切断処理の場合と同様に、携帯端末50は、確認コマンドに対するレスポンスコマンド(即ちOKコマンド)を受信することができない。この場合、携帯端末50は、DeactivationコマンドをMFP10に送信するが、MFP10のNFC I/F22の動作が停止されているために、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を受信することもできない。従って、携帯端末50は、タイムアウトと判断して、通信リンクを維持するための処理(即ち、確認コマンドを送信する処理等)を終了する。これにより、S14で確立された通信リンクが切断される。CPU32は、ハードウェア的切断処理(即ちNFC I/F22の動作の停止)を実行することによって、通信リンクを適切に切断することができる。
なお、NFC I/F22の動作を停止させる手法は、上記のように、CPU32からNFC I/F22に指示を送信する手法に限られない。例えば、CPU32は、NFC I/F22への電力供給を一時的に停止することによって、NFC I/F22の動作を一時的に停止させてもよい。この手法も、ハードウェア的切断処理の一例である。S38が終了すると、MFPのListen処理が終了する。
一方において、S18でYESの場合(即ち送信フラグが「1」である場合)には、S30において、CPU32は、S20と同様に、MFP10がP2Pモードのクライアントとして動作し、携帯端末50がP2Pモードのサーバとして動作するように、ネゴシエーションを実行する。S30では、CPU32は、さらに、MFP10がデータ送信を実行すること(即ち携帯端末50がデータ受信を実行すること)を、携帯端末50に通知する。これにより、携帯端末50は、MFP10から対象データを受信するまで待機する。
次いで、S32において、CPU32は、S14で確立された通信リンクを利用して、NFC I/F22を介して、携帯端末50に対象データを送信する。例えば、上記の第1〜第5の例では、CPU32は、例えば、前回のMFPのListen処理のS24、又は、前回のMFPのPoll処理(図4)のS124において、第1の対象データを処理して、第2の対象データを生成する。この場合、S32では、CPU32は、生成済みの第2の対象データを携帯端末50に送信する。また、例えば、上記の第6の例では、第1の対象データとして、スキャンデータが生成される。この場合、S32では、CPU32は、生成済みの第1の対象データを携帯端末50に送信する。
次いで、S34では、CPU32は、メモリ34内の通信済フラグが「1」であるのか否かを判断する。CPU32は、メモリ34内の通信済フラグが「1」である場合に、S34でYESと判断して、S40に進む。一方において、CPU32は、メモリ34内の通信済フラグが「0」である場合に、S34でNOと判断して、S36に進む。
S36では、CPU32は、メモリ34内の送信フラグを「0」に設定し、メモリ34内の通信済フラグを「1」に設定する。CPU32は、S36を終えると、S38に進み、上記の切断処理を実行する。
一方において、S40では、CPU32は、メモリ34内の送信フラグを「0」に設定し、メモリ34内の通信済フラグを「0」に設定する。
なお、S40が実行される場合(即ち、通信済フラグが「1」である場合)には、第2の対象データの通信が完了している(即ち、上記の1セットの通信が完了している)。従って、携帯端末50は、通信リンクを維持する必要がないと判断して、DeactivationコマンドをMFP10に送信する。この結果、S42において、CPU32は、携帯端末50から、NFC I/F22を介して、Deactivationコマンドを受信する。
次いで、S44において、CPU32は、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を、NFC I/F22を介して、携帯端末50に送信する。これにより、S14で確立された通信リンクが切断される。S44が終了すると、MFPのListen処理が終了する。
(MFPのListen処理;CEモード(図3))
続いて、図3を参照して、図2のS12でNOと判断される場合(MFP10がCEモードで動作すべきことが判断される場合)の処理の内容を説明する。S62は、図2のS14と同様である。なお、MFP10がCEモードで動作し、携帯端末50がR/Wモードで動作する場合には、P2Pモードの場合と異なり、確認コマンド応答処理(図2のS16参照)が実行されない。単方向通信のためのモードであるために(即ち、1回の対象データの通信のみが実行されるモードであるために)、通信リンクを維持するのか否かを確認する必要がないからである。
S64〜S72は、図2のS18,S22〜S28と同様である。S74〜S78は、図2のS32〜S36と同様である。また、S86〜S90は、図2のS40〜S44と同様である。S90が終了すると、MFPのListen処理が終了する。
S80では、CPU32は、S62で確立された通信リンクを切断するためのソフトウェア的切断処理を実行する。即ち、CPU32は、携帯端末50から、NFC I/F22を介して、Deactivationコマンドを受信して、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を、NFC I/F22を介して、携帯端末50に送信する。これにより、S62で確立された通信リンクが切断される。CPU32は、ソフトウェア的切断処理(Deactivationコマンドの受信、及び、OKコマンドの送信)を実行することによって、通信リンクを適切に切断することができる。
次いで、S82において、CPU32は、NFC I/F22の動作を制御するための動作制御処理を実行する。CPU32は、NFC I/F22が動作を停止するための指示を、NFC I/F22に送信する。これにより、NFC I/F22は、外部からの信号の受信、外部への信号の送信、Poll動作、Listen動作等を含む全ての動作を一時的に停止する。
S80で通信リンクが切断されると、携帯端末50は、Pollモード及びListenモードで再び順次動作する。ただし、S82において、MFP10のNFC I/F22の動作が一時的に停止されるために、携帯端末50は、ポーリング信号を送信しても、レスポンス信号を受信しない。また、携帯端末50は、MFP10からポーリング信号を受信しない。このために、携帯端末50は、MFP10と携帯端末50の間の距離が大きくなったこと、即ち、通信相手が離反したこと、を検知することができる。
携帯端末50に通信相手の離反を検知させるのは(即ちS82の動作制御処理を実行するのは)、以下の理由である。CEモード及びR/Wモードに対応する通信リンクでは、1回の対象データの通信のみが実行されることが前提となっている。従って、一対のNFC機器のそれぞれは、CEモード及びR/Wモードに従って、対象データの通信を実行すると、通常、通信リンクを切断する。その後、仮に、一対のNFC機器が近接している状態が維持され続けると、一対のNFC機器は、Poll動作及びListen動作を再び実行して通信リンクを再び確立し、同じ対象データの通信を実行し得る。即ち、一対のNFC機器が近接している状態が維持される場合には、同じ対象データが何回も通信されるという事象が発生し得る。
従って、NFC機器は、通常、CEモード及びR/Wモードに対応する通信リンクを切断した後に、通信相手の離反を検知しない場合には、Poll動作及びListen動作を再び実行しても、通信リンクを再び確立しないようにプログラムされている。そして、NFC機器は、例えば、ポーリング信号を何回か送信しても、レスポンス信号を通信相手から受信しない場合や、所定期間に亘って通信相手からポーリング信号を受信しない場合に、通信相手の離反を検知する。NFC機器は、このようにして通信相手の離反を検知すると、同じ通信相手と通信リンクを再び確立することができる。
本実施例では、第1の対象データの通信が実行された後に、第2の対象データの通信が実行される(即ち1セットの通信が実行される)。従って、第1の対象データの通信のための通信リンクが切断された後に、MFP10と携帯端末50とが近接している状態が維持されていても、第2の対象データの通信のための新たな通信リンクを再び確立させる仕組みが必要である。この仕組みが、S82の動作制御処理である。即ち、MFP10がS82の動作制御処理を実行すれば、MFP10と携帯端末50とが近接している状態が維持されていても、携帯端末50は、MFP10の離反を検知することができる。その後、MFP10及び携帯端末50がPoll動作及びListen動作を実行すれば、MFP10及び携帯端末50の間に通信リンクを再び確立させることができる。
なお、S82の動作制御処理は、上記のように、CPU32からNFC I/F22に指示を送信する手法に限られない。例えば、CPU32は、NFC I/F22への電力供給を一時的に停止することによって、NFC I/F22の動作を一時的に停止させてもよい。この手法も、動作制御処理の一例である。S82が終了すると、MFPのListen処理が終了する。
(MFPのPoll処理;図4及び図5)
続いて、図4及び図5を参照して、MFPのPoll処理の内容を説明する。上述したように、NFC I/F22がPoll動作を実行する場合には、MFP10は、受信済みの動作可能モード信号に従って、P2Pモード及びR/Wモードのうちのどちらかのモードで動作する。S110では、CPU32は、受信済みの動作可能モード信号に基づいて、MFP10が、P2Pモードで動作すべきか、R/Wモードで動作すべきか、を判断する。CPU32は、MFP10がP2Pモードで動作すべきと判断する場合(S110でYESの場合)に、S112に進み、MFP10がR/Wモードで動作すべきと判断する場合(S110でNOの場合)に、図5のS160に進む。
(MFPのPoll処理;P2Pモード(図4))
S112では、CPU32は、NFC I/F22を介して、P2Pモードに対応するActivationコマンドを携帯端末50に送信する。次いで、S114では、CPU32は、携帯端末50から、NFC I/F22を介して、Activationコマンドに対するレスポンスコマンド(即ちOKコマンド)を受信する。これにより、MFP10と携帯端末50との間にNFC方式の通信リンクが確立される。
次いで、S116では、CPU32は、確認コマンド送信処理を開始する。確認コマンド送信処理では、CPU32は、確認コマンドを、NFC I/F22を介して、携帯端末50に送信して、携帯端末50から、NFC I/F22を介して、確認コマンドに対するレスポンスコマンド(即ちOKコマンド)を受信する。なお、CPU32は、S116で確認コマンド送信処理を開始すると、後述のS138が実行されるまで、又は、後述のS144で通信リンクが切断されるまで、確認コマンド送信処理を継続して実行する。
S118〜S128は、図2のS18〜S28と同様である。S130〜S136は、図2のS30〜S36と同様である。また、S140は、図2のS40と同様である。S142では、CPU32は、NFC I/F22を介して、Deactivationコマンドを携帯端末50に送信する。次いで、S144では、CPU32は、携帯端末50から、NFC I/F22を介して、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を受信する。これにより、S114で確立された通信リンクが切断される。
S138では、CPU32は、S114で確立された通信リンクを切断するための切断処理を実行する。S138の切断処理の手法として、ソフトウェア的切断処理と、ハードウェア的切断処理と、の2つの手法が考えられる。CPU32は、どちらの手法の切断処理を実行してもよい。
CPU32がソフトウェア的切断処理を実行する場合には、CPU32は、NFC I/F22を介して、Deactivationコマンドを携帯端末50に送信して、携帯端末50から、NFC I/F22を介して、Deactivationコマンドに対するレスポンスコマンド(即ちOKコマンド)を受信する。これにより、S114で確立された通信リンクが切断される。CPU32は、ソフトウェア的切断処理(Deactivationコマンドの送信、及び、OKコマンドの受信)を実行することによって、通信リンクを適切に切断することができる。
なお、ソフトウェア的切断処理は、上記のように、CPU32がDeactivationコマンドを送信する手法に限られない。例えば、CPU32は、S116で開始された確認コマンド送信処理を終了させてもよい。即ち、CPU32は、確認コマンドを携帯端末50に送信しない。携帯端末50は、所定期間に亘って、MFP10から確認コマンドを受信しない場合に、タイムアウトと判断する。これにより、携帯端末50は、通信リンクに関する処理(即ち、確認コマンドの受信の監視等)を終了し、この結果、通信リンクが切断される。この手法も、ソフトウェア的切断処理の一例である。
一方において、CPU32がハードウェア的切断処理を実行する場合には、CPU32は、NFC I/F22の動作を一時的に停止させる。具体的に言うと、例えば、CPU32は、NFC I/F22が動作を停止するための指示を、NFC I/F22に送信する。従って、CPU32は、NFC I/F22を介して、S116で開始された確認コマンド送信処理を実行することができなくなる。この場合、携帯端末50は、タイムアウトと判断し、通信リンクに関する処理(即ち、確認コマンドの受信の監視等)を終了し、この結果、通信リンクが切断される。CPU32は、ハードウェア的切断処理(NFC I/F22の動作の停止)を実行することによって、通信リンクを適切に切断することができる。
なお、NFC I/F22の動作を停止させる手法は、上記のように、CPU32からNFC I/F22に指示を送信する手法に限られない。例えば、CPU32は、NFC I/F22への電力供給を一時的に停止することによって、NFC I/F22の動作を一時的に停止させてもよい。この手法も、ハードウェア的切断処理の一例である。S138が終了すると、MFPのPoll処理が終了する。
(MFPのPoll処理;R/Wモード(図5))
続いて、図5を参照して、図4のS110でNOと判断される場合(即ちMFP10がR/Wモードで動作すべきと判断される場合)の処理の内容を説明する。S160〜S164は、図4のS112,S114,S118と同様である。ただし、S160では、CPU32は、R/Wモードに対応するActivationコマンドを送信する。
S164でNOの場合(即ち送信フラグが「0」である場合)には、S165において、CPU32は、MFP10がReaderモードに従って動作すべきことを決定する。これにより、CPU32は、携帯端末50の擬似的なカードから対象データを読み出すこと、即ち、携帯端末50から対象データを受信することができる。この後に実行されるS166〜S172は、図3のS66〜S72と同様である。
一方において、S164でYESの場合(即ち送信フラグが「1」である場合)には、S173において、CPU32は、MFP10がWriterモードに従って動作すべきことを決定する。これにより、CPU32は、携帯端末50の擬似的なカードに対象データを書き込むこと、即ち、携帯端末50に対象データを送信することができる。この後に実行されるS174〜S182は、図3のS74〜S82と同様である。なお、S186〜S190は、図4のS140〜S144と同様である。
(具体的なケース)
続いて、本実施例によって実現される具体的なケースを説明する。以下の各ケースは、MFP10が図2〜図5の各処理を実行することによって、実現される。
(ケースA1;図6)
ケースA1では、MFP10がListen動作を実行し(即ち携帯端末50がPoll動作を実行し)、さらに、携帯端末50がP2Pモードに従って動作可能である。
MFP10は、携帯端末50からActivationコマンドを受信して(図2のS10)、OKコマンドを携帯端末50に送信する(S14)。これにより、MFP10と携帯端末50との間に通信リンクL1が確立される。この場合、MFP10は、確認コマンド応答処理を開始する(S16)。即ち、MFP10は、携帯端末50から確認コマンドを受信して、OKコマンドを携帯端末50に送信する。
ケースA1では、通信リンクL1が確立された時点では、送信フラグが「0」である。この場合、MFP10は、図2のS18でNOと判断し、次いで、ネゴシエーションを実行して、MFP10がデータ受信を実行することを、携帯端末50に通知する(S20)。MFP10は、携帯端末50から第1の対象データを受信し(S22)、第1の対象データを処理することによって第2の対象データを生成する(S24)。この場合、MFP10は、送信フラグを「1」に設定し、通信済フラグを「1」に設定する(S28)。
次いで、MFP10は、ソフトウェア的切断処理を実行する(S38)。即ち、MFP10は、携帯端末50から確認コマンドを受信しても、OKコマンドを送信しない。この場合、MFP10は、携帯端末50からDeactivationコマンドを受信して、OKコマンドを携帯端末50送信する。この結果、通信リンクL1が切断される。
その後、MFP10がListen動作を再び実行する(即ち携帯端末50がPoll動作を再び実行する)。MFP10は、携帯端末50からActivationコマンドを受信して(S10)、OKコマンドを携帯端末50に送信する(S14)。この結果、MFP10と携帯端末50との間に通信リンクL2が確立される。
第1の対象データが通信された際に、送信フラグが「1」に設定されている。この場合、MFP10は、図2のS18でYESと判断し、次いで、ネゴシエーションを実行して、MFP10がデータ送信を実行することを、携帯端末50に通知する(S30)。MFP10は、第2の対象データを携帯端末50に送信する(S32)。この場合、MFP10は、送信フラグを「0」に設定し、通信済フラグを「0」に設定する(S40)。次いで、MFP10は、携帯端末50からDeactivationコマンドを受信して(S42)、OKコマンドを携帯端末50に送信する(S44)。この結果、通信リンクL2が切断される。
上述したように、P2Pモードは、双方向通信のためのモードである。従って、同じ通信リンクL1を利用して、第1及び第2の対象データの両方を通信する構成が考えられる。しかしながら、携帯端末50が、P2Pモードに従って、双方向通信を適切に実行することができない可能性がある。例えば、携帯端末50のOS(Operating System)が、通信リンクL1を利用して、第1の対象データを送信した後に、同じ通信リンクL1を利用して、第2の対象データを受信する動作を許容しない可能性がある。
このような可能性に鑑みて、本実施例では、ケースA1に示されるように、MFP10は、P2Pに対応する通信リンクL1を利用して、携帯端末50から第1の対象データを受信すると、通信リンクL1を切断する。次いで、MFP10は、P2Pに対応する通信リンクL2を再確立し、通信リンクL2を利用して、第2の対象データを携帯端末50に送信する。従って、携帯端末50がP2Pモードの双方向通信を許容しない場合でも、MFP10は、P2Pモードに従って、第1の対象データと、第1の対象データを処理することによって生成される第2の対象データと、の両方を、携帯端末50と適切に通信することができる。
(ケースA2;図7)
ケースA2では、MFP10が、ソフトウェア的切断処理の代わりに、ハードウェア的切断処理(図2のS38)を実行する点が、ケースA1とは異なる。
即ち、MFP10は、ハードウェア的切断処理において、NFC I/F22の動作を一時的に停止させる。このために、MFP10は、携帯端末50から確認コマンドを受信しても、OKコマンドを送信しない。また、MFP10は、携帯端末50からDeactivationコマンドを受信しても、OKコマンドを送信しない。これにより、携帯端末50は、タイムアウトと判断し、この結果、通信リンクL1が切断される。その他の点は、ケースA1と同様である。ケースA2でも、ケースA1と同様の作用及び効果が得られる。
なお、ケースA2のハードウェア的切断処理を実行すると、NFC I/F22が復帰するまでに長時間を要する可能性がある。従って、処理の迅速化という観点では、ケースA1のソフトウェア的切断処理を実行することが好ましい。ただし、ケースA2のハードウェア的切断処理によると、通信リンクL1を確実に切断することができる。従って、通信リンクの切断の確実化という観点では、ケースA2のハードウェア的切断処理を実行することが好ましい。その他のケース(例えば図4のケースA4)でも、MFP10のベンダが重視する観点に応じて、ソフトウェア的切断処理及びハードウェア的切断処理のどちらが採用されてもよい。
(ケースA3;図8)
ケースA3では、MFP10がPoll動作を実行し(即ち携帯端末50がListen動作を実行し)、さらに、携帯端末50がP2Pモードに従って動作可能である。
MFP10は、Activationコマンドを携帯端末50に送信して(図4のS112)、携帯端末50からOKコマンドを受信する(S114)。これにより、MFP10と携帯端末50との間に通信リンクL1が確立される。
ケースA3では、通信リンクL1が確立された時点では、送信フラグが「0」である。この場合、MFP10は、図4のS118でNOと判断し、次いで、ネゴシエーションを実行して、MFP10がデータ受信を実行することを、携帯端末50に通知する(S120)。MFP10は、携帯端末50から第1の対象データを受信し(S122)、第1の対象データを処理することによって第2の対象データを生成する(S124)。この場合、MFP10は、送信フラグを「1」に設定し、通信済フラグを「1」に設定する(S128)。
次いで、MFP10は、ソフトウェア的切断処理を実行する(S138)。即ち、MFP10は、Deactivationコマンドを携帯端末50に送信して、携帯端末50からOKコマンドを受信する。この結果、通信リンクL1が切断される。
その後、MFP10がPoll動作を再び実行する(即ち携帯端末50がListen動作を再び実行する)。MFP10は、Activationコマンドを携帯端末50に送信して(S112)、携帯端末50からOKコマンドを受信する(S114)。この結果、MFP10と携帯端末50との間に通信リンクL2が確立される。
第1の対象データが通信された際に、送信フラグが「1」に設定されている。この場合、MFP10は、図4のS118でYESと判断し、次いで、ネゴシエーションを実行して、MFP10がデータ送信を実行することを、携帯端末50に通知する(S130)。MFP10は、第2の対象データを携帯端末50に送信する(S132)。この場合、MFP10は、送信フラグを「0」に設定し、通信済フラグを「0」に設定する(S140)。次いで、MFP10は、Deactivationコマンドを携帯端末50に送信して(S142)、携帯端末50からOKコマンドを受信する(S144)。この結果、通信リンクL2が切断される。
ケースA3でも、MFP10は、P2Pモードに従って、第1の対象データと、第1の対象データを処理することによって生成される第2の対象データと、の両方を、携帯端末50と適切に通信することができる。
(ケースA4;図9)
ケースA4では、ソフトウェア的切断処理の内容が、ケースA3とは異なる。なお、MFP10は、通信リンクL1が確立されると、確認コマンド送信処理を開始する(S116)。即ち、MFP10は、確認コマンドを携帯端末50に送信して、携帯端末50からOKコマンドを受信する。
ケースA3のソフトウェア的切断処理では、MFP10は、Deactivationコマンドを携帯端末50に送信して、携帯端末50からOKコマンドを受信する(図8参照)。これに代えて、ケースA4では、ソフトウェア的切断処理において、MFP10は、確認コマンド送信処理を終了する(S138)。これにより、携帯端末50は、タイムアウトと判断し、この結果、通信リンクL1が切断される。その他の点は、ケースA3と同様である。ケースA4でも、ケースA3と同様の作用及び効果が得られる。
なお、上述したように、MFP10は、NFC I/F22の動作を一時的に停止させるハードウェア的切断処理を実行してもよい(S138)。この場合も、確認コマンドが携帯端末50に送信されないために、携帯端末50は、タイムアウトと判断し、この結果、通信リンクL1が切断される。このような構成でも、同様の作用及び効果が得られる。
(その他のケース)
図6〜図9のケースA1〜A4では、第1の通信リンクL1を確立する際、及び、第2の通信リンクL2を確立する際、の両方において、MFP10は、同じ機器(即ち、図6及び図7ではListen機器、図8及び図9ではPoll機器)として動作する。しかしながら、例えば、MFP10は、第1の通信リンクL1を確立する際に、Listen機器として動作し、第2の通信リンクL2を確立する際に、Poll機器として動作してもよい。また、例えば、MFP10は、第1の通信リンクL1を確立する際に、Poll機器として動作し、第2の通信リンクL2を確立する際に、Listen機器として動作してもよい。
また、図6〜図9のケースA1〜A4では、MFP10は、携帯端末50から第1の対象データを受信して、第2の対象データを携帯端末50に送信する。即ち、ケースA1〜A4は、対象データに関する上記の第1〜第5の例に対応する。しかしながら、MFP10は、第1の対象データを携帯端末50に送信して、携帯端末50から第2の対象データを受信してもよい。即ち、対象データに関する上記の第6の例が実現されてもよい。いずれのケースでも、ケースA1〜A4と同様の作用及び効果が得られる。
(ケースB1;図10)
ケースB1では、MFP10がListen動作を実行し(即ち携帯端末50がPoll動作を実行し)、さらに、携帯端末50がR/Wモード及びCEモードのみに従って動作可能である。従って、MFP10がCEモードに従って動作し、携帯端末50がR/Wモードに従って動作する。
MFP10は、携帯端末50からActivationコマンドを受信して(図2のS10)、OKコマンドを携帯端末50に送信する(S62)。これにより、MFP10と携帯端末50との間に通信リンクL1が確立される。
ケースB1では、通信リンクL1が確立された時点では、送信フラグが「0」である。この場合、MFP10は、図3のS64でNOと判断し、携帯端末50から第1の対象データを受信し(S66)、第1の対象データを処理することによって第2の対象データを生成する(S68)。この場合、MFP10は、送信フラグを「1」に設定し、通信済フラグを「1」に設定する(S72)。
次いで、MFP10は、ソフトウェア的切断処理を実行する(S80)。即ち、MFP10は、携帯端末50からDeactivationコマンドを受信して、OKコマンドを携帯端末50に送信する。この結果、通信リンクL1が切断される。
次いで、MFP10は、動作制御処理を実行する(S82)。即ち、MFP10は、携帯端末50からポーリング信号を受信しても、レスポンス信号を送信しない(即ち、NFC I/F22がListen動作を一時的に実行しない)。また、MFP10は、ポーリング信号を携帯端末50に送信しない(即ち、NFC I/F22がPoll動作を一時的に実行しない)。これにより、携帯端末50は、MFP10の離反を検知する。この結果、MFP10及び携帯端末50が近接している状態が維持されても、後述の通信リンクL2を適切に確立することができる。
その後、MFP10がListen動作を再び実行する(即ち携帯端末50がPoll動作を再び実行する)。MFP10は、携帯端末50からActivationコマンドを受信して(図2のS10)、OKコマンドを携帯端末50に送信する(S62)。この結果、MFP10と携帯端末50との間に通信リンクL2が確立される。
第1の対象データが通信された際に、送信フラグが「1」に設定されている。この場合、MFP10は、図3のS64でYESと判断し、第2の対象データを携帯端末50に送信する(S74)。この場合、MFP10は、送信フラグを「0」に設定し、通信済フラグを「0」に設定する(S86)。次いで、MFP10は、携帯端末50からDeactivationコマンドを受信して(S88)、OKコマンドを携帯端末50に送信する(S90)。この結果、通信リンクL2が切断される。
上述したように、R/Wモード及びCEモードは、単方向通信のためのモードである。従って、同じ通信リンクL1を利用して、第1及び第2の対象データの両方を通信することができない。本実施例では、ケースB1に示されるように、MFP10は、通信リンクL1を利用して、携帯端末50から第1の対象データを受信すると、通信リンクL1を切断する。次いで、MFP10は、通信リンクL2を再確立し、通信リンクL2を利用して、第2の対象データを携帯端末50に送信する。従って、MFP10及び携帯端末50がR/Wモード及びCEモードに従って動作する場合でも、MFP10は、第1の対象データと、第1の対象データを処理することによって生成される第2の対象データと、の両方を、携帯端末50と適切に通信することができる。即ち、MFP10は、擬似的な双方向通信を実現することができる。
(ケースB2;図11)
ケースB2では、MFP10がPoll動作を実行し(即ち携帯端末50がListen動作を実行し)、さらに、携帯端末50がR/Wモード及びCEモードのみに従って動作可能である。従って、MFP10がR/Wモードに従って動作し、携帯端末50がCEモードに従って動作する。
MFP10は、Activationコマンドを携帯端末50に送信して(図5のS160)、携帯端末50からOKコマンドを受信する(S162)。これにより、MFP10と携帯端末50との間に通信リンクL1が確立される。
ケースB2では、通信リンクL1が確立された時点では、送信フラグが「0」である。この場合、MFP10は、図5のS164でNOと判断し、MFP10がReaderモードに従って動作すべきことを決定する(S165)。MFP10は、携帯端末50から第1の対象データを受信し(S166)、第1の対象データを処理することによって第2の対象データを生成する(S168)。この場合、MFP10は、送信フラグを「1」に設定し、通信済フラグを「1」に設定する(S172)。
次いで、MFP10は、ソフトウェア的切断処理を実行する(S180)。即ち、MFP10は、Deactivationコマンドを携帯端末50に送信して、携帯端末50からOKコマンドを受信する。この結果、通信リンクL1が切断される。
次いで、MFP10は、動作制御処理を実行する(S182)。これにより、携帯端末50は、MFP10の離反を検知する。その後、MFP10がPoll動作を再び実行する(即ち携帯端末50がListen動作を再び実行する)。MFP10は、Activationコマンドを携帯端末50に送信して(S160)、携帯端末50からOKコマンドを受信する(S162)。この結果、MFP10と携帯端末50との間に通信リンクL2が確立される。
第1の対象データが通信された際に、送信フラグが「1」に設定されている。この場合、MFP10は、図5のS164でYESと判断し、MFP10がWriterモードに従って動作すべきことを決定する(S173)。MFP10は、第2の対象データを携帯端末50に送信する(S174)。この場合、MFP10は、送信フラグを「0」に設定し、通信済フラグを「0」に設定する(S186)。次いで、MFP10は、Deactivationコマンドを携帯端末50に送信して(S188)、携帯端末50からOKコマンドを受信する(S190)。この結果、通信リンクL2が切断される。
ケースB2でも、ケースB1と同様の作用及び効果が得られる。即ち、MFP10及び携帯端末50がR/Wモード及びCEモードに従って動作する場合でも、MFP10は、擬似的な双方向通信を実現することができる。
(その他のケース)
図10及び図11のケースB1,B2では、第1の通信リンクL1を確立する際、及び、第2の通信リンクL2を確立する際、の両方において、MFP10は、同じ機器(即ち、図10ではListen機器、図11ではPoll機器)として動作する。しかしながら、例えば、図12のケースB3に示されるように、MFP10は、第1の通信リンクL1を確立する際に、Listen機器(即ちCEモード)として動作し、第2の通信リンクL2を確立する際に、Poll機器(即ちWriterモード)として動作してもよい。また、例えば、図12のケースB4に示されるように、MFP10は、第1の通信リンクL1を確立する際に、Poll機器(即ちReaderモード)として動作し、第2の通信リンクL2を確立する際に、Listen機器(即ちCEモード)として動作してもよい。
また、図10及び図11のケースB1,B2では、MFP10は、携帯端末50から第1の対象データを受信して、第2の対象データを携帯端末50に送信する。即ち、ケースB1,B2は、対象データに関する上記の第1〜第5の例に対応する。しかしながら、図12のケースB5〜B8のように、MFP10は、第1の対象データを携帯端末50に送信して、携帯端末50から第2の対象データを受信してもよい。即ち、対象データに関する上記の第6の例が実現されてもよい。いずれのケースでも、ケースB1,B2と同様の作用及び効果が得られる。
(対応関係)
MFP10、携帯端末50が、それぞれ、「通信装置」、「外部装置」の一例である。Activationコマンドが、「第1の確立コマンド」及び「第2の確立コマンド」の一例である。Deactivationコマンドが、「切断コマンド」の一例である。また、送信フラグ=1が、「送信情報」の一例である。また、図6〜図9のケースA1〜A4では、P2Pモードが、「送信用モード」及び「受信用モード」の一例である。また、図10のケースB1では、CEモードが、「送信用モード」及び「受信用モード」の一例である。また、図11のケースB2では、Writerモード、Readerモードが、それぞれ、「送信用モード」、「受信用モード」の一例である。
図2のS10,S14、図3のS62、図4のS112,S114、図5のS160,S162が、「第1の確立ステップ(さらに第1の確立手段)」及び「第2の確立ステップ(さらに第2の確立手段)」の一例である。図2のS22,S32、図3のS66,S74、図4のS122,S132、図5のS166,S174が、「第1の通信ステップ(さらに第1の通信手段)」及び「第2の通信ステップ(さらに第2の通信手段)」の一例である。また、図2のS38、図3のS80、図4のS138、図5のS180が、「切断ステップ(さらに切断手段)」の一例である。例えば、図2のS38、図4のS138が、それぞれ、「第1の切断手法」、「第2の切断手法」の一例である。また、例えば、図3のS80、図5のS180が、それぞれ、「第1の切断手法」、「第2の切断手法」の一例である。
また、図2のS16で開始される確認コマンド応答処理、図4のS116で開始される確認コマンド送信処理が、それぞれ、「第1の確認ステップ」、「第2の確認ステップ」の一例である。図3のS82、図5のS182が、「動作制御ステップ」の一例である。また、図2のS18、図3のS64、図4のS118、図5のS164が、「判断ステップ」の一例である。図2のS28,S36、図3のS72,S78、図4のS128,S136、図5のS172,S178が、「メモリ制御ステップ」の一例である。図2のS20、図4のS120が、「通知ステップ」の一例である。図5のS165,S173が、「決定ステップ」の一例である。図2のS24、図3のS68、図4のS124、図3のS168が、「処理ステップ」の一例である。また、図2のS22、図3のS66、図4のS122、図5のS166が、「受信ステップ」の一例である。図2のS32、図3のS74、図4のS132、図5のS174が、「送信ステップ」の一例である。
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。上記の実施例の変形例を以下に列挙する。
(変形例1)「通信装置」は、印刷機能及びスキャン機能を実行可能な多機能機(即ちMFP10)に限られず、印刷機能及びスキャン機能のうちの印刷機能のみを実行可能なプリンタであってもよいし、印刷機能及びスキャン機能のうちのスキャン機能のみを実行可能なスキャナであってもよい。また、「通信装置」は、印刷機能及びスキャン機能とは異なる機能(例えば、画像の表示機能、データの演算機能)を実行する装置(例えば、PC、サーバ、携帯端末(携帯電話、スマートフォン、PDA等))であってもよい。即ち、「通信装置」は、NFC方式の通信を実行可能なあらゆるデバイスを含む。
(変形例2)MFP10は、P2Pモードを利用可能でなくてもよく、R/Wモード及びCEモードのみを利用可能であってもよい。この場合、CPU32は、図2及び図4の各処理を実行せずに、図3及び図5の各処理を実行すればよい。また、MFP10は、R/Wモード及びCEモードを利用可能でなくてもよく、P2Pモードのみを利用可能であってもよい。即ち、「通信装置」は、NFC規格の全てのモードを利用可能でなくてもよく、少なくとも1つのモードを利用可能であればよい。
(変形例3)上記の各実施例では、図2〜図5の各処理がソフトウェア(即ちプログラム36,38)によって実現されるが、図2〜図5の各処理のうちの少なくとも1つが論理回路等のハードウェアによって実現されてもよい。
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。