JP6414283B2 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
JP6414283B2
JP6414283B2 JP2017125980A JP2017125980A JP6414283B2 JP 6414283 B2 JP6414283 B2 JP 6414283B2 JP 2017125980 A JP2017125980 A JP 2017125980A JP 2017125980 A JP2017125980 A JP 2017125980A JP 6414283 B2 JP6414283 B2 JP 6414283B2
Authority
JP
Japan
Prior art keywords
snep
connection
type
mfp
external device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017125980A
Other languages
English (en)
Other versions
JP2017212738A (ja
Inventor
弘崇 朝倉
弘崇 朝倉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Brother Industries Ltd
Original Assignee
Brother Industries Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brother Industries Ltd filed Critical Brother Industries Ltd
Priority to JP2017125980A priority Critical patent/JP6414283B2/ja
Publication of JP2017212738A publication Critical patent/JP2017212738A/ja
Application granted granted Critical
Publication of JP6414283B2 publication Critical patent/JP6414283B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Telephone Function (AREA)
  • Computer And Data Communications (AREA)
  • Facsimiles In General (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本明細書によって開示される技術は、NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式で、通信対象の対象データを外部装置と通信する通信装置に関する。
特許文献1には、通信端末と、NFCデバイスと、を備えるシステムが開示されている。通信端末がR/Wモードであり、かつ、NFCデバイスがパッシブタグモードである状態において、通信端末からNFCデバイスにデータ読み出し要求が送信される。次いで、通信端末及びNFCデバイスのそれぞれは、P2Pモードに移行する。通信端末がP2Pモードであり、かつ、NFCデバイスがP2Pモードである状態において、NFCデバイスから通信端末にデータが転送される。データ転送が完了すると、通信端末は、パッシブタグモードに移行し、NFCデバイスは、R/Wモードに移行する。
特開2011−44092号公報
本明細書では、通信装置が、NFC方式で通信対象の対象データを外部装置と適切に通信するための技術を提供する。
本明細書によって開示される技術は、NFC(Near Field Communication)規格に従った通信方式であるNFC方式で、通信対象の対象データを外部装置と通信する通信装置である。
通信装置は、NFC方式の通信を実行するためのNFCインターフェースと、プロセッサと、プログラムを格納しているメモリと、を備える。プロセッサは、メモリに格納されているプログラムに従って、以下の各ステップ、即ち、
通信装置の現在の状態と外部装置の現在の状態とに応じて、通信装置と外部装置との間に、NFC規格で定められている特定のプロトコルに従った第1種及び第2種の接続のうちの少なくとも1種の接続を確立する確立ステップであって、
(A)通信装置の現在の状態が、特定のプロトコルに従ったサーバ機能が有効化されている状態であり、かつ、外部装置の現在の状態が、特定のプロトコルに従ったクライアント機能が有効化されている状態である場合に、通信装置がサーバとして動作すると共に外部装置がクライアントとして動作するための第1種の接続を確立し、
(B)通信装置の現在の状態が、クライアント機能が有効化されている状態であり、かつ、外部装置の現在の状態が、サーバ機能が有効化されている状態である場合に、通信装置がクライアントとして動作すると共に外部装置がサーバとして動作するための第2種の接続を確立する、確立ステップと、
確立済みの少なくとも1種の接続を利用して、NFCインターフェースを介して、対象データを外部装置と通信する通信ステップと、を実行する。
プロセッサは、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行する。
上記の構成によると、通信装置は、通信装置及び外部装置の状態(即ち、サーバ機能及びクライアント機能のそれぞれの有効化に関する状態)に応じて、第1種及び第2種の接続のうちの少なくとも1種の接続を確立する。そして、通信装置は、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行する。このために、通信装置は、どの種の接続が確立されるのかに応じた適切な通信ステップを実行し得る。従って、通信装置は、対象データを外部装置と適切に通信し得る。
通信ステップは、第1種及び第2種の接続の両方が確立される場合に、第1種の接続を利用して、NFCインターフェースを介して、外部装置から第1の対象データを受信し、その後、第2種の接続を利用して、NFCインターフェースを介して、第2の対象データを外部装置に送信する第1の通信ステップを含んでいてもよい。この構成によると、通信装置は、第1種及び第2種の接続の両方が確立される場合に、第1種及び第2種の接続のそれぞれを順次利用して、第1及び第2の対象データのそれぞれを外部装置と順次通信する。従って、通信装置は、第1及び第2の対象データを外部装置と適切に通信し得る。
第1の通信ステップは、特定のプロトコルのPUTコマンドに従って、外部装置から第1の対象データを受信し、その後、特定のプロトコルのPUTコマンドに従って、第2の対象データを外部装置に送信することを含んでいてもよい。この構成によると、通信装置は、同じPUTコマンドに従って、第1及び第2の対象データを外部装置と通信する。従って、例えば、外部装置が、PUTコマンドを利用可能であるが、PUTコマンドとは異なるコマンドを利用不可能である場合に、通信装置は、第1及び第2の対象データを外部装置と適切に通信し得る。
第1の対象データは、特定のリクエストを示すデータを含んでいてもよい。第2の対象データは、特定のリクエストに対するレスポンスを示すデータを含んでいてもよい。プロセッサは、メモリに格納されているプログラムに従って、さらに、第1の対象データが受信される場合に、特定のリクエストに対応する処理を実行して、第2の対象データを生成する生成ステップを実行してもよい。この構成によると、通信装置は、外部装置から第1の対象データを受信する場合に、特定のリクエストに対応する処理を実行して、第2の対象データを生成することができる。
通信ステップは、第1種及び第2種の接続のうちの第2種の接続のみが確立される場合に、第2種の接続を利用して、NFCインターフェースを介して、第3の対象データを外部装置に送信する第2の通信ステップを含んでいてもよい。この構成によると、通信装置は、第2種の接続のみが確立される場合に、第3の対象データを外部装置に適切に送信し得る。
第2の通信ステップは、特定のプロトコルのPUTコマンドに従って、第3の対象データを外部装置に送信することを含んでいてもよい。この構成によると、通信装置は、PUTコマンドに従って、第3の対象データを外部装置に送信する。従って、例えば、外部装置が、PUTコマンドを利用可能であるが、PUTコマンドとは異なるコマンドを利用不可能である場合に、通信装置は、第3の対象データを外部装置に適切に送信し得る。
第3の対象データは、外部装置の状態を、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化させるための特定のデータを含んでいてもよい。この構成によると、通信装置は、第3の対象データを外部装置に送信することによって、外部装置のクライアント機能を有効化させ得る。
特定のデータは、外部装置が通信装置に特定の機能を実行させるための特定のアプリケーションを識別する識別情報を含んでいてもよい。この構成によると、通信装置は、外部装置のクライアント機能を適切に有効化させ得る。
通信ステップは、第1種及び第2種の接続のうちの第1種の接続のみが確立される場合に、第1種の接続を利用して、NFCインターフェースを介して、外部装置から第4の対象データを受信し、その後、第1種の接続を利用して、NFCインターフェースを介して、第5の対象データを外部装置に送信する第3の通信ステップを含んでいてもよい。この構成によると、通信装置は、第1種の接続のみが確立される場合に、第1種の接続を利用して、第4及び第5の対象データのそれぞれを外部装置と順次通信する。従って、通信装置は、第4及び第5の対象データを外部装置と適切に通信し得る。
第3の通信ステップは、特定のプロトコルのPUTコマンドに従って、外部装置から第4の対象データを受信し、その後、特定のプロトコルのGETコマンドに従って、第5の対象データを外部装置に送信することを含んでいてもよい。この構成によると、外部装置が、PUTコマンド及びGETコマンドを利用可能である場合に、通信装置は、第4及び第5の対象データを外部装置と適切に通信し得る。
第4の対象データは、特定のリクエストを示すデータを含んでいてもよい。第5の対象データは、特定のリクエストに対するレスポンスを示すデータを含んでいてもよい。プロセッサは、メモリに格納されているプログラムに従って、さらに、第4の対象データが受信される場合に、特定のリクエストに対応する処理を実行して、第5の対象データを生成する生成ステップを実行してもよい。この構成によると、通信装置は、外部装置から第4の対象データを受信する場合に、特定のリクエストに対応する処理を実行して、第5の対象データを生成することができる。
通信装置は、通信装置の電源がONされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持してもよい。プロセッサは、通信装置の現在の状態が、サーバ機能及びクライアント機能の両方が有効化されている状態である状況において、確立ステップを実行してもよい。この構成によると、通信装置は、確立ステップを適切に実行して、対象データを外部装置と適切に通信し得る。
プロセッサは、通信装置の現在の状態が、サーバ機能及びクライアント機能のうちのクライアント機能のみが有効化されている状態である第1の状況において、確立ステップを実行してもよい。プロセッサは、メモリに格納されているプログラムに従って、さらに、第1の状況において確立ステップが実行された後に、通信装置の状態を、サーバ機能及びクライアント機能のうちのクライアント機能のみが有効化されている状態から、サーバ機能及びクライアント機能の両方が有効化されている状態に変化させる変化ステップを実行させてもよい。プロセッサは、変化ステップが実行された後に、通信装置の現在の状態が、サーバ機能及びクライアント機能の両方が有効化されている状態である第2の状況において、確立ステップを再び実行してもよい。この構成によると、通信装置は、確立ステップを適切に実行して、対象データを外部装置と適切に通信し得る。
上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。また、上記の通信装置と外部装置とを含む通信システムも、新規で有用である。
通信システムの構成を示す。 第1実施例のMFPのNFC処理のフローチャートを示す。 ケースA1の通信のシーケンスチャートを示す。 ケースA2の通信のシーケンスチャートを示す。 ケースA3の通信のシーケンスチャートを示す。 第2実施例のMFPのNFC処理のフローチャートを示す。 ケースB1の通信のシーケンスチャートを示す。 ケースB2の通信のシーケンスチャートを示す。 ケースB3の通信のシーケンスチャートを示す。
(第1実施例)
(通信システム2の構成)
図1に示すように、通信システム2は、多機能機(以下では「MFP(Multi-Function Peripheralの略)」と呼ぶ)10と、携帯端末50,52と、を備える。MFP10と携帯端末50,52とは、それぞれ、NFC規格の通信方式(即ちNFC方式)の通信を実行可能である。本実施例では、NFC規格は、ISO/IEC21481又はISO/IEC18092の国際標準規格である。NFC方式の通信は、13.56MHz帯の電波を利用した無線通信である。また、MFP10と携帯端末50,52とは、それぞれ、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に従って、様々な処理を実行する。メモリ34は、ROM、RAM、ハードディスク等によって構成される。メモリ34は、CPU32によって実行される上記のプログラム36を格納する。
プログラム36は、アプリケーションプログラムと、プロトコルスタックと、を含む。アプリケーションプログラムは、CPU32が、OSI参照モデルのアプリケーション層の処理を実行するためのプログラムである。プロトコルスタックは、CPU32が、OSI参照モデルのアプリケーション層よりも下位層の処理を実行するためのプログラムである。プロトコルスタックは、NFCフォーラムによって定められたNFC規格に準拠した処理を実行するためのプログラムである。プロトコルスタックは、NFC規格のP2P(Peer to Peerの略)モードに従った処理を実行するためのP2Pプログラムを含む。なお、プロトコルスタックは、NFC規格のR/W(Reader/Writerの略)モードに従った処理を実行するためのR/Wプログラムを含んでいてもよいし、含んでいなくてもよい。また、プロトコルスタックは、NFC規格のCE(Card Emulationの略)モードに従った処理を実行するためのCEプログラムを含んでいてもよいし、含んでいなくてもよい。
以下では、NFC方式の通信を実行可能な機器(MFP10、携帯端末50,52等)のことを「NFC機器」と呼ぶ。NFC機器の中には、P2Pモード、R/Wモード、及び、CEモードの3つのモードの全てを利用可能な機器も存在するし、上記の3つのモードのうちの1つ又は2つのモードのみを利用可能な機器も存在する。本実施例では、MFP10のプログラム36がP2Pプログラムを含むために、MFP10は、少なくともP2Pモードを利用可能である。また、携帯端末50,52も、少なくともP2Pモードを利用可能である。
P2Pモードは、一対のNFC機器の間で双方向通信を実行するためのモードである。
例えば、第1のNFC機器と第2のNFC機器との両方が、P2Pモードに従って動作する状況を想定する。この場合、第1のNFC機器と第2のNFC機器との間で、P2Pモードに従った通信を実行するための通信リンクが確立される。なお、以下では、P2Pモードに従った通信を実行するための通信リンクのことを、「LLCP(Logical Link Control Protocol)接続」と呼ぶことがある。例えば、第1のNFC機器は、LLCP接続を利用して、第1のデータを第2のNFC機器に送信する。その後、第2のNFC機器は、通常、同じLLCP接続を利用して、第2のデータを第1のNFC機器に送信する。これにより、双方向通信が実現される。
なお、NFCフォーラムによって定められるISO/IEC 1443のTypeAであるNFC機器、及び、ISO/IEC 18092のTypeFであるNFC機器は、P2Pモードに従って動作することができる。ただし、ISO/IEC 1443のTypeBであるNFC機器は、P2Pモードに従って動作することができない。
一対のNFC機器の間でLLCP接続が確立される場合には、一対の通信機器は、通常、さらに、SNEP(Simple NDEF(NFC Data Exchange Format) Exchange Protocolの略)接続を確立する。SNEP接続では、一対のNFC機器のうちの一方のNEC機器がサーバとして動作すると共に、一対のNFC機器のうちの他方のNFC機器がクライアントとして動作する。一対のNFC機器のそれぞれがサーバ及びクライアントのどちらで動作するのかは、一対のNFC機器のそれぞれの状態に依存する。
例えば、MFP10の状態が、SNEPのサーバ機能が有効化されている状態であり、かつ、携帯端末50の状態が、SNEPのクライアント機能が有効化されている状態である場合には、MFP10がサーバとして動作すると共に携帯端末50がクライアントとして動作するためのSNEP接続(以下では「MFP(S)−端末(C)のSNEP接続」と呼ぶ)が確立される。また、例えば、MFP10の状態が、SNEPのクライアント機能が有効化されている状態であり、かつ、携帯端末50の状態が、SNEPのサーバ機能が有効化されている状態である場合には、MFP10がクライアントとして動作すると共に携帯端末50がサーバとして動作するためのSNEP接続(以下では、「MFP(C)−端末(S)のSNEP接続」と呼ぶ)が確立される。
なお、例えば、MFP10の状態が、SNEPのサーバ機能及びクライアント機能の両方が有効化されている状態であり、かつ、携帯端末50の状態が、SNEPのサーバ機能及びクライアント機能が有効化されている状態である場合には、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、の両方のSNEP接続が確立される。なお、以下では、SNEPのサーバ機能、SNEPのクライアント機能のことを、それぞれ、「サーバ機能」、「クライアント機能」と簡単に記載する。
本実施例では、MFP10は、MFP10の電源がONされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。従って、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、のうちのどの接続が確立されるのかは、通信相手(即ち、携帯端末50,52)の状態に依存する。即ち、通信相手の状態が、サーバ機能及びクライアント機能の両方が有効化されている場合には、両方のSNEP接続が確立される。また、通信相手の状態が、サーバ機能のみが有効化されている場合には、MFP(C)−端末(S)のSNEP接続のみが確立される。また、通信相手の状態が、クライアント機能のみが有効化されている場合には、MFP(S)−端末(C)のSNEP接続のみが確立される。
SNEP接続では、クライアントとして動作するNFC機器(以下では単に「クライアント」と呼ぶ)が、サーバとして動作するNFC機器(以下では単に「サーバ」と呼ぶ)にリクエストコマンドを送信する。例えば、クライアントは、PUTコマンドを利用して、クライアント内の対象データをサーバに送信することができる。具体的に言うと、クライアントは、PUTリクエストと対象データとをサーバに送信する。これにより、サーバは、クライアントから対象データを受信して、対象データを利用することができる。また、例えば、クライアントは、GETコマンドを利用して、サーバ内の対象データをサーバから受信することができる。具体的に言うと、クライアントは、GETリクエストをサーバに送信する。この場合、サーバは、GETレスポンスと対象データとをクライアントに送信する。これにより、クライアントは、サーバから対象データを受信して、対象データを利用することができる。なお、サーバは、PUTリクエスト又はGETリクエストを送信することができず、PUTリクエスト又はGETリクエストに応じた処理(例えば、GETリクエストに対するGETレスポンスの送信)を実行する。このように、SNEP接続では、クライアントは、対象データの通信のハンドリングを実行し、サーバは、クライアントの動作に応じて、対象データの通信を実行する。
(携帯端末50,52の構成)
携帯端末50,52は、例えば、携帯電話(例えばスマートフォン)、PDA、ノートPC、タブレットPC、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末である。携帯端末50,52のそれぞれは、無線ネットワークに接続するためのネットワークI/Fと、NFC I/Fと、を備える。従って、携帯端末50,52のそれぞれは、ネットワークI/Fを介して、MFP10と無線通信を実行可能であると共に、NFC I/Fを利用して、MFP10と無線通信を実行可能である。
携帯端末50,52のそれぞれは、MFP10に様々な機能(例えば、印刷機能、スキャン機能等)を実行させるためのアプリケーションプログラム(以下では「MFP用アプリケーション」と呼ぶ)をインストールすることができる。なお、本実施例では、携帯端末50,52は、MFP10のベンダによって提供されるインターネットサーバ(図示省略)から、MFP用アプリケーションをインストールする。
携帯端末50は、第1のOS(Operation Systemの略)プログラムを備える。第1のOSプログラムは、例えば、Android(登録商標)のバージョン4.0である。第1のOSプログラムは、携帯端末50を以下のように動作させる。即ち、携帯端末50は、携帯端末50の電源がONされている間に、サーバ機能が有効化されている状態を維持する。携帯端末50は、MFP用アプリケーションがインストールされていない場合には、クライアント機能が無効化されている状態を維持する。携帯端末50は、MFP用アプリケーションがインストールされていても、MFP用アプリケーションが起動されていない場合には、クライアント機能が無効化されている状態を維持する。携帯端末50は、MFP用アプリケーションが起動されると、クライアント機能を有効化し、MFP用アプリケーションが終了すると(即ち、MFP用アプリケーションが起動されていない状態になると)、クライアント機能を無効化する。
携帯端末52は、第1のOSプログラムとは異なる第2のOSプログラムを備える。第2のOSプログラムは、携帯端末52を以下のように動作させる。即ち、携帯端末52は、MFP用アプリケーションがインストールされていない場合には、携帯端末52の電源がONされている間に、サーバ機能及びクライアント機能の両方が無効化されている状態を維持する。携帯端末52は、MFP用アプリケーションがインストールされていても、MFP用アプリケーションが起動されていない場合には、サーバ機能及びクライアント機能の両方が無効化されている状態を維持する。携帯端末52は、MFP用アプリケーションが起動されると、クライアント機能を有効化し、MFP用アプリケーションが終了すると(即ち、MFP用アプリケーションが起動されていない状態になると)、クライアント機能を無効化する。
(Poll動作及びListen動作)
続いて、NFC機器によって実行されるPoll動作及びListen動作について説明する。例えば、MFP10では、CPU32が、プログラムに従って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は、ポーリング信号を送信して、レスポンス信号を受信することを監視する。Listenモードでは、NFC I/F22は、ポーリング信号を受信することを監視して、ポーリング信号を受信すると、レスポンス信号を送信する。不実行モードでは、NFC I/F22は、ポーリング信号を送信せず、さらに、ポーリング信号を受信しても、レスポンス信号を送信しない。
携帯端末50,52のそれぞれも、上記の1セットの動作を繰り返し実行する。従って、例えば、MFP10と携帯端末50との間の距離が10cm未満であり、かつ、MFP10の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動作を実行する。
本実施例では、MFP10及び携帯端末50,52は、P2Pモードに従って動作可能である。従って、MFP10及び携帯端末(即ち携帯端末50又は52)がPoll動作及びListen動作を実行すると、P2Pモードに従った通信を実行するための通信リンク、即ち、LLCP接続が確立される。より具体的に言うと、Poll動作を実行したNFC機器(以下では「Poll機器」と呼ぶ)は、P2Pモードに対応するActivationコマンドを、Listen動作を実行したNFC機器(以下では「Listen機器」と呼ぶ)に送信する。次いで、Listen機器は、Poll機器からActivationコマンドを受信すると、OKコマンドをPoll機器に送信する。これにより、MFP10(即ちPoll機器又はListen機器)と携帯端末(即ちListen機器又はPoll機器)との間に、LLCP接続が確立される。その後、MFP10と携帯端末との間に、それらの機器の状態に応じたSNEP接続(即ち、MFP(S)−端末(C)のSNEP接続、及び/又は、MFP(C)−端末(S)のSNEP接続)が確立される。
(MFPのNFC処理;図2)
次いで、図2を参照して、MFP10のCPU32がプログラム36に従って実行する処理の内容を説明する。CPU32は、MFP10の電源がONされると、図2の処理を実行する。なお、上述したように、MFP10は、MFP10の電源がONされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する(即ち、MFP(S)=ON、MFP(C)=ON)。
S10では、CPU32は、MFP10と携帯端末(即ち、携帯端末50,52のどちらか)との間にLLCP接続が確立されることを監視する。上述したように、P2Pモードに対応するActivationコマンド及びOKコマンドの通信が実行されると、MFP10と携帯端末との間にLLCP接続が確立される。この場合、CPU32は、S10でYESと判断して、S12に進む。
S12では、CPU32は、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、のそれぞれを確立することを試行する。具体的に言うと、S12では、CPU32は、まず、MFP(S)−端末(C)のSNEP接続を確立するための第1のネゴシエーション通信を、NFC I/F22を介して、携帯端末と実行することを試行する。例えば、携帯端末の状態が、クライアント機能が有効化されている状態であれば、携帯端末が、上記の第1のネゴシエーション通信を実行し、この結果、MFP(S)−端末(C)のSNEP接続が確立される。一方において、例えば、携帯端末の状態が、クライアント機能が無効化されている状態であれば、携帯端末が、上記の第1のネゴシエーション通信を実行せず、この結果、MFP(S)−端末(C)のSNEP接続が確立されない。
S12では、CPU32は、さらに、MFP(C)−端末(S)のSNEP接続を確立するための第2のネゴシエーション通信を、NFC I/F22を介して、携帯端末と実行することを試行する。例えば、携帯端末の状態が、サーバ機能が有効化されている状態であれば、携帯端末が、上記の第2のネゴシエーション通信を実行し、この結果、MFP(C)−端末(S)のSNEP接続が確立される。一方において、例えば、携帯端末の状態が、サーバ機能が無効化されている状態であれば、携帯端末が、上記の第2のネゴシエーション通信を実行せず、この結果、MFP(C)−端末(S)のSNEP接続が確立されない。
次いで、S20において、CPU32は、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、の両方のSNEP接続が確立されたのか否かを判断する。両方のSNEP接続が確立された場合には、CPU32は、S20でYESと判断して、S22に進む。一方において、一方のSNEP接続のみが確立された場合、又は、どちらのSNEP接続も確立されなかった場合には、CPU32は、S20でNOと判断して、S30に進む。
S22では、CPU32は、MFP(S)−端末(C)のSNEP接続を利用して、NFC I/F22を介して、携帯端末からPUTリクエストと印刷リクエストデータとを受信する。本実施例では、印刷リクエストデータは、印刷機能をMFP10に実行させるための印刷指示コマンドを含む。なお、印刷リクエストデータは、印刷対象のデータである印刷データ自体を含まない。
上述したように、NFC方式の通信の通信速度は、ネットワーク無線通信の通信速度よりも遅い。このために、仮に、携帯端末からMFP10への印刷データの通信としてNFC方式の通信が利用されると、印刷データの通信に長時間を要する可能性がある。従って、本実施例では、MFP10が、ネットワーク無線通信を利用して、携帯端末50から印刷データを受信する構成を採用する。このような構成を採用するためには、携帯端末50は、MFP10とネットワーク無線通信を実行するための無線設定を知る必要がある。従って、MFP10は、携帯端末から印刷指示コマンドを含む印刷リクエストデータを受信する場合に、印刷指示コマンドに対するレスポンスを示すレスポンスデータとして、上記の無線設定を携帯端末に送信する。
即ち、S24では、CPU32は、印刷リクエストデータに含まれる印刷指示コマンドを読み込むと、メモリ34から、MFP10が現在属している無線ネットワークで利用されている無線設定を特定する。次いで、CPU32は、SNEPの通信方式に適合するレスポンスデータを生成する。この際に、CPU32は、特定済みの無線設定を含むレスポンスデータを生成する。
次いで、S26では、CPU32は、MFP(C)−端末(S)のSNEP接続を利用して、NFC I/F22を介して、PUTリクエストと生成済みのレスポンスデータとを携帯端末に送信する。これにより、携帯端末は、レスポンスデータに含まれる無線設定を利用して、無線ネットワークに参加することができる。この結果、MFP10及び携帯端末は、NFC方式の通信に代えて、ネットワーク無線通信を実行して、印刷データを通信することができる。即ち、MFP10は、携帯端末から印刷データを受信して、印刷機能を実行することができる。
S26を終えると、S50において、CPU32は、S10で確立されたLLCP接続を切断する。例えば、MFP10がPoll機器である状態で、LLCP接続が確立された場合には、S50において、CPU32は、NFC I/F22を介して、Deactivationコマンドを携帯端末に送信し、NFC I/F22を介して、携帯端末からOKコマンドを受信する。この結果、LLCP接続が切断される。一方において、MFP10がListen機器である状態で、LLCP接続が確立された場合には、S50において、CPU32は、NFC I/F22を介して、携帯端末からDeactivationコマンドを受信し、NFC I/F22を介して、OKコマンドを携帯端末に送信する。この結果、LLCP接続が切断される。なお、LLCP接続が切断されると、SNEP接続も切断される。S50が終了すると、S10に戻る。
S30では、CPU32は、MFP(C)−端末(S)のSNEP接続のみが確立されたのか否かを判断する。MFP(C)−端末(S)のSNEP接続のみが確立された場合には、CPU32は、S30でYESと判断して、S32に進む。一方において、MFP(S)−端末(C)のSNEP接続のみが確立された場合、又は、どちらのSNEP接続も確立されなかった場合には、CPU32は、S30でNOと判断して、S40に進む。
S32では、CPU32は、MFP(C)−端末(S)のSNEP接続を利用して、NFC I/F22を介して、PUTリクエストとURL(Uniform Resource Locatorの略)データとを携帯端末に送信する。上述したように、MFP10のベンダによって提供されるインターネットサーバは、MFP用アプリケーションを格納しており、外部装置からのリクエストに応じて、MFP用アプリケーションのダウンロード及びインストールを外部装置に許可する。S32で送信されるURLデータは、MFP用アプリケーションのURL(即ち、上記のインターネットサーバ内のMFP用アプリケーションのファイルアドレス)を示す。URLデータは、NFC規格で定められているスマートポスター(Smart Poster)のコマンドを含む。なお、URLデータを受信した際に携帯端末が実行する動作については、後で詳しく説明する。S32が終了すると、S50に進む。
S40では、CPU32は、MFP(S)−端末(C)のSNEP接続のみが確立されたのか否かを判断する。MFP(S)−端末(C)のSNEP接続のみが確立された場合には、CPU32は、S40でYESと判断して、S42に進む。一方において、どちらのSNEP接続も確立されなかった場合には、CPU32は、S40でNOと判断して、S50に進む。
S42では、CPU32は、MFP(S)−端末(C)のSNEP接続を利用して、NFC I/F22を介して、携帯端末からPUTリクエストと印刷リクエストデータとを受信する。S42で受信される印刷リクエストデータは、S22で受信される印刷リクエストデータと同様である。
次いで、S44において、CPU32は、S24と同様に、無線設定を含むレスポンスデータを生成する。続いて、S46では、CPU32は、MFP(S)−端末(C)のSNEP接続を利用して、NFC I/F22を介して、携帯端末からGETリクエストを受信する。S46では、CPU32は、さらに、MFP(S)−端末(C)のSNEP接続を利用して、NFC I/F22を介して、GETレスポンスと生成済みのレスポンスデータとを携帯端末に送信する。S46が終了すると、S50に進む。
(具体的なケース)
続いて、本実施例によって実現される具体的なケースA1〜A3を説明する。ケースA1〜A3は、MFP10が図2の各処理を実行することによって、実現される。なお、ケースA1〜A3では、MFP(S)−端末(C)のSNEP接続に関する通信を破線で示し、MFP(C)−端末(S)のSNEP接続に関する通信を一点鎖線で示す。この点は、後述の第2実施例の図7〜図9でも同様である。
(ケースA1;図3)
ケースA1は、MFP10と、第1のOSプログラムを備える携帯端末50と、の間で実行される通信を示す。上述したように、MFP10は、MFP10の電源がONされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する(即ち、MFP(S)=ON、MFP(C)=ON)。また、携帯端末50は、携帯端末50の電源がONされている間に、サーバ機能が有効化されている状態を維持する(即ち、端末(S)=ON)。また、携帯端末50は、MFP用アプリケーションをインストール済みである。そして、携帯端末50のユーザは、MFP用アプリケーションを起動させるための操作を、携帯端末50に加える。これにより、携帯端末50は、クライアント機能を有効化させる(即ち、端末(C)=ON)。
携帯端末50のユーザは、MFP用アプリケーションの画面に従って、印刷機能をMFP10に実行させるための操作を、携帯端末50に加える。そして、ユーザは、携帯端末50をMFP10に近づける。この結果、MFP10と携帯端末50との間に、LLCP接続が確立される(図2のS10でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されている。このために、MFP10と携帯端末50との間に、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、の両方のSNEP接続が確立される(S20でYES)。
携帯端末50は、MFP用アプリケーションに従って、印刷リクエストデータを生成する。そして、携帯端末50は、MFP(S)−端末(C)のSNEP接続を利用して、PUTリクエストと生成済みの印刷リクエストデータとをMFP10に送信する。
MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末50からPUTリクエストと印刷リクエストデータとを受信する(S22)。次いで、MFP10は、レスポンスデータを生成する(S24)。続いて、MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとレスポンスデータとを携帯端末50に送信する(S26)。
携帯端末50は、MFP(C)−端末(S)のSNEP接続を利用して、MFP10からPUTリクエストとレスポンスデータとを受信する。これにより、携帯端末50は、MFP用アプリケーションに従って、レスポンスデータに含まれる無線設定を利用して、無線ネットワークに参加する。携帯端末50は、ネットワーク無線通信を実行して、印刷データをMFP10に送信する。
MFP10は、ネットワーク無線通信を実行して、携帯端末50から印刷データを受信する。印刷データは、印刷実行部18に供給される。これにより、MFP10(即ち印刷実行部18)は、印刷データによって表される画像を、印刷媒体に印刷する。
上述したように、ケースA1では、両方のSNEP接続が確立される場合に、MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末50から印刷リクエストデータを受信し、その後、MFP(C)−端末(S)のSNEP接続を利用して、レスポンスデータを携帯端末50に送信する。従って、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
なお、本実施例では、携帯端末50の第1のOSプログラムは、PUTコマンドを利用可能であるが、GETコマンドを利用不可能である。ケースA1では、印刷リクエストデータ及びレスポンスデータのどちらが通信されるべき状況でも、PUTコマンドが利用される。従って、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
(ケースA2;図4)
ケースA2は、MFP10と、第1のOSプログラムを備える携帯端末50と、の間で実行される通信を示す。MFP10の状態は、図3のケースA1の状態と同様である(即ち、MFP(S)=ON、MFP(C)=ON)。携帯端末50は、MFP用アプリケーションをインストール済みでない。もしくは、携帯端末50は、MFP用アプリケーションをインストール済みであるが、MFP用アプリケーションを起動していない。従って、携帯端末50では、サーバ機能が有効化されているが、クライアント機能が無効化されている(即ち、端末(S)=ON、端末(C)=OFF)。
MFP10と携帯端末50との間に、LLCP接続が確立される(図2のS10でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末50において、サーバ機能のみが有効化されている。このために、MFP10と携帯端末50との間に、MFP(C)−端末(S)のSNEP接続のみが確立される(S20でNO、S30でYES)。
MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとURLデータとを携帯端末50に送信する(S32)。次いで、LLCP接続が切断される(S50)。
携帯端末50は、MFP(C)−端末(S)のSNEP接続を利用して、MFP10からPUTリクエストとURLデータとを受信する。これにより、携帯端末50は、第1のOSプログラムに従って、URLデータに含まれるスマートポスターのコマンドを読み込む。
携帯端末50がMFP用アプリケーションをインストール済みでないケースでは、以下の第1の例及び第2の例が実現される。第1の例では、携帯端末50は、スマートポスターのコマンドを読み込むと、URLデータに含まれるURL(即ちMFP用アプリケーションを格納しているインターネットサーバ)に自動的にアクセスして、インターネットサーバからMFP用アプリケーションをダウンロードする。これにより、携帯端末50は、MFP用アプリケーションをインストールすることができる。第2の例では、携帯端末50は、スマートポスターのコマンドを読み込むと、所定の画面を表示させて、URLデータに含まれるURLにアクセスするのか否かを、ユーザに問い合わせる。そして、ユーザがアクセスを許可すると、携帯端末50は、インターネットサーバからMFP用アプリケーションをダウンロードする。これにより、携帯端末50は、MFP用アプリケーションをインストールすることができる。携帯端末50は、MFP用アプリケーションをインストールすると、MFP用アプリケーションを起動させる。この結果、携帯端末50は、クライアント機能を有効化させる。即ち、携帯端末50は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。
携帯端末50がMFP用アプリケーションをインストール済みであるケースでは、携帯端末50は、スマートポスターのコマンドを読み込むと、URLデータを破棄して、MFP用アプリケーションをダウンロードしない。ただし、携帯端末50は、スマートポスターのコマンドを読み込むと、MFP用アプリケーションを起動させる。この結果、携帯端末50は、クライアント機能を有効化させる。即ち、携帯端末50は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。
携帯端末50のユーザは、図3のケースA1と同様に、印刷機能をMFP10に実行させるための操作を加えた後に、携帯端末50をMFP10に近づける。この結果、MFP10と携帯端末50との間に、LLCP接続が再び確立される(図2のS10でYES)。携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されているために、両方のSNEP接続が確立される(S20でYES)。この後の動作は、図3のケースA1と同様である。
上述したように、ケースA2では、MFP(C)−端末(S)のSNEP接続のみが確立される場合に、MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、URLデータを携帯端末50に送信する。このために、携帯端末50がMFP用アプリケーションをインストール済みでないケースでは、携帯端末50は、URLデータを用いて、MFP用アプリケーションをインストールして、MFP用アプリケーションを起動させる。また、携帯端末50がMFP用アプリケーションをインストール済みであるケースでは、携帯端末50は、MFP用アプリケーションをダウンロードしないが、MFP用アプリケーションを起動させる。携帯端末50は、MFP用アプリケーションを起動すると、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化する。従って、MFP10は、URLデータを携帯端末50に送信することによって、携帯端末50のクライアント機能を適切に有効化させることができる。このために、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
また、URLデータの通信には、PUTコマンドが利用される。従って、MFP10は、携帯端末50がGETコマンドを利用不可能である場合に、URLデータを携帯端末50と適切に通信することができる。この結果、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
(ケースA3;図5)
ケースA3は、MFP10と、第2のOSプログラムを備える携帯端末52と、の間で実行される通信を示す。MFP10の状態は、図3のケースA1の状態と同様である(即ち、MFP(S)=ON、MFP(C)=ON)。また、携帯端末52は、携帯端末52の電源がONされている間に、サーバ機能が無効化されている状態を維持する(即ち、端末(S)=OFF)。また、携帯端末52は、MFP用アプリケーションをインストール済みである。そして、携帯端末52のユーザは、MFP用アプリケーションを起動させるための操作を、携帯端末52に加える。これにより、携帯端末52は、クライアント機能を有効化させる(即ち、端末(C)=ON)。
携帯端末52のユーザは、MFP用アプリケーションの画面に従って、印刷機能をMFP10に実行させるための操作を、携帯端末52に加える。そして、ユーザは、携帯端末52をMFP10に近づける。この結果、MFP10と携帯端末52との間に、LLCP接続が確立される(図2のS10でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末52において、クライアント機能のみが有効化されている。このために、MFP10と携帯端末52との間に、MFP(S)−端末(C)のSNEP接続のみが確立される(S20でNO、S30でNO、S40でYES)。
携帯端末52は、MFP用アプリケーションに従って、印刷リクエストデータを生成する。そして、携帯端末52は、MFP(S)−端末(C)のSNEP接続を利用して、PUTリクエストと生成済みの印刷リクエストデータとをMFP10に送信する。
MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末52からPUTリクエストと印刷リクエストデータとを受信する(S42)。次いで、MFP10は、レスポンスデータを生成する(S44)。
携帯端末52は、印刷リクエストデータをMFP10に送信した後に、さらに、MFP(S)−端末(C)のSNEP接続を利用して、GETリクエストをMFP10に送信する。
MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末52からGETリクエストを受信する(S46)。次いで、MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、GETレスポンスとレスポンスデータとを携帯端末52に送信する(S46)。この後の動作は、図3のケースA1と同様である。
上述したように、ケースA3では、MFP(S)−端末(C)のSNEP接続のみが確立される場合に、MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末52から印刷リクエストデータを受信し、その後、MFP(S)−端末(C)のSNEP接続を利用して、レスポンスデータを携帯端末52に送信する。従って、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末52と適切に通信することができる。
なお、本実施例では、携帯端末52の第2のOSプログラムは、PUTコマンド及びGETコマンドの両方を利用可能である。従って、MFP10は、PUTコマンド及びGETコマンドを利用して、印刷リクエストデータ及びレスポンスデータを携帯端末52と適切に通信することができる。
(第1実施例の効果)
本実施例によると、MFP10は、MFP10及び携帯端末50,52の現在の状態(即ち、サーバ機能及びクライアント機能のそれぞれの有効化に関する状態)に応じて、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、のうちの少なくとも1つのSNEP接続を確立する。そして、MFP10は、どのSNEP接続が確立されるのかに応じて、図3〜図5のケースA1〜A3に示されるように、異なる通信ステップを実行する。このために、MFP10は、どのSNEP接続が確立されるのかに応じた適切な通信ステップを実行することができる。本実施例によると、MFP10は、印刷リクエストデータ、レスポンスデータ、URLデータ等を、を携帯端末50,52と適切に通信することができる。
例えば、第1のOSプログラムを備える携帯端末50が、MFP用アプリケーションをインストール済みであるのか否かに応じて、MFP10は、ケースA1及びA2に示されるように、異なる通信ステップを実行することができる。また、例えば、第1のOSプログラムを備える携帯端末50が、MFP用アプリケーションをインストール済みであるが、MFPアプリケーションを起動しているのか否かに応じて、MFP10は、ケースA1及びA2に示されるように、異なる通信ステップを実行することができる。また、上述したように、第1のOSプログラムを備える携帯端末50は、サーバ機能が有効化されている状態を維持するが、第2のOSプログラムを備える携帯端末52は、サーバ機能が無効化されている状態を維持する。このように、異なるOSプログラムを備える様々な携帯端末50,52が存在し得る環境において、MFP10は、ケースA1(又はA2)及びA3に示されるように、携帯端末50,52が備えるOSプログラムの種類に応じて、異なる通信ステップを実行することができる。
また、図3のケースA1に示されるように、MFP10は、MFP(S)−端末(C)のSNEP接続と、MFP(C)−端末(S)のSNEP接続と、の両方のSNEP接続が確立される場合に、一方のSNEP接続及び他方のSNEP接続のそれぞれを順次利用して、印刷リクエストデータ及びレスポンスデータを携帯端末50と順次通信する。しかも、MFP10は、同じPUTコマンドに従って、印刷リクエストデータ及びレスポンスデータを携帯端末50と通信する。従って、携帯端末50が、PUTコマンドを利用可能であるが、GETコマンドを利用不可能である場合に、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
(対応関係)
MFP10、携帯端末50,52が、それぞれ、「通信装置」、「外部装置」の一例である。SNEPが、「特定のプロトコル」の一例である。MFP(S)−端末(C)のSNEP接続、MFP(C)−端末(S)のSNEP接続が、それぞれ、「第1種の接続」、「第2種の接続」の一例である。図2のS12が、「確立ステップ」の一例である。S22及びS26、S32、S42及びS46が、それぞれ、「第1の通信ステップ」、「第2の通信ステップ」、「第3の通信ステップ」の一例である。S24,S44が、「生成ステップ」の一例である。S22で受信される印刷リクエストデータ、S26で送信されるレスポンスデータ、S32で送信されるURLデータ、S42で受信される印刷リクエストデータ、S46で送信されるレスポンスデータが、それぞれ、「第1の対象データ」、「第2の対象データ」、「第3の対象データ」、「第4の対象データ」、「第5の対象データ」の一例である。S32で送信されるURLデータに含まれるMFP用アプリケーションのURLが、「特定のデータ」及び「識別情報」の一例である。印刷機能が、「特定の機能」の一例である。
(第2実施例)
第1実施例では、MFP10は、MFP10の電源がONされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。これに対し、本実施例では、MFP10は、MFP10の電源がONされている間に、クライアント機能が有効化されている状態を維持するが、後述の図6のS116が実行されない限り、サーバ機能が無効化されている状態を維持する。本実施例では、MFP10のCPU32は、図2のNFC処理に代えて、図6のNFC処理を実行する。
(MFPのNFC処理;図6)
S100は、図2のS10と同様である。S102では、CPU32は、MFP(C)−端末(S)のSNEP接続を確立することを試行する。なお、S102では、CPU32は、MFP(S)−端末(C)のSNEP接続を確立することを試行しない。MFP10において、サーバ機能が無効化されているからである。S110では、CPU32は、MFP(C)−端末(S)のSNEP接続が確立されたのか否かを判断する。MFP(C)−端末(S)のSNEP接続が確立された場合には、CPU32は、S110でYESと判断して、S112に進む。一方において、MFP(C)−端末(S)のSNEP接続が確立されなかった場合には、CPU32は、S110でNOと判断し、S112をスキップして、S114に進む。
S112では、CPU32は、図2のS32と同様に、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとURLデータとを携帯端末に送信する。S112が終了すると、S114に進む。
S114では、CPU32は、図2のS50と同様に、LLCP接続を切断する。次いで、S116において、CPU32は、サーバ機能が無効化されている状態から、サーバ機能が有効化されている状態に変化させる。これにより、MFP10は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。S116が終了すると、S120に進む。
S120,122は、図2のS10,S12と同様である。S130において、CPU32は、両方のSNEP接続が確立されたのか否かを判断する。両方のSNEP接続が確立された場合には、CPU32は、S130でYESと判断して、S132に進む。S132〜S136は、図2のS22〜S26と同様である。S136が終了すると、S150に進む。
一方のSNEP接続のみが確立された場合、又は、どちらのSNEP接続も確立されなかった場合には、CPU32は、S130でNOと判断して、S140に進む。S140では、CPU32は、MFP(S)−端末(C)のSNEP接続のみが確立されたのか否かを判断する。MFP(S)−端末(C)のSNEP接続のみが確立された場合には、CPU32は、S140でYESと判断して、S142に進む。S142〜S146は、図2のS42〜S46と同様である。S146が終了すると、S150に進む。
MFP(C)−端末(S)のSNEP接続のみが確立された場合、又は、どちらのSNEP接続も確立されなかった場合には、CPU32は、S140でNOと判断して、S150に進む。
S150では、CPU32は、図2のS50と同様に、LLCP接続を切断する。次いで、S152において、CPU32は、サーバ機能が有効化されている状態から、サーバ機能が無効化されている状態に変化させる。これにより、MFP10は、クライアント機能のみが有効化されている状態になる。S152が終了すると、S100に戻る。
(具体的なケース)
続いて、本実施例によって実現される具体的なケースB1〜B3を説明する。ケースB1〜B3は、MFP10が図6の各処理を実行することによって、実現される。
(ケースB1;図7)
ケースB1は、MFP10と、第1のOSプログラムを備える携帯端末50と、の間で実行される通信を示す。上述したように、MFP10は、MFP10の電源がONされている間に、クライアント機能が有効化されている状態を維持するが、図6のS116が実行されない限り、サーバ機能が無効化されている状態を維持する(即ち、MFP(S)=OFF、MFP(C)=ON)。また、携帯端末50では、MFP用アプリケーションが起動されている。従って、携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されている(即ち、端末(S)=ON、端末(C)=ON)。
MFP10と携帯端末50との間に、LLCP接続が確立される(図6のS100でYES)。MFP10において、クライアント機能のみが有効化されており、携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されている。このために、MFP10と携帯端末50との間に、MFP(C)−端末(S)のSNEP接続のみが確立される(S102、S110でYES)。
MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとURLデータとを携帯端末50に送信する(S112)。
携帯端末50は、MFP(C)−端末(S)のSNEP接続を利用して、MFP10からPUTリクエストとURLデータとを受信する。これにより、携帯端末50は、第1のOSプログラムに従って、URLデータに含まれるスマートポスターのコマンドを読み込む。ただし、携帯端末50は、MFP用アプリケーションをインストール済みである。従って、携帯端末50は、URLデータを破棄して、MFP用アプリケーションをダウンロードしない。
MFP10は、MFP10と携帯端末50との間のLLCP接続を一旦切断する(S114)。その後、MFP10は、サーバ機能を有効化させる(S116)。従って、MFP10は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。そして、MFP10は、MFP10と携帯端末50との間に、LLCP接続を再び確立させる(図6のS120でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されている。このために、MFP10と携帯端末50との間に、両方のSNEP接続が確立される(S122、S130でYES)。
携帯端末50は、MFP用アプリケーションに従って、印刷リクエストデータを生成する。そして、携帯端末50は、MFP(S)−端末(C)のSNEP接続を利用して、PUTリクエストと生成済みの印刷リクエストデータとをMFP10に送信する。
MFP10は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末50からPUTリクエストと印刷リクエストデータとを受信する(S132)。次いで、MFP10は、レスポンスデータを生成する(S134)。続いて、MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとレスポンスデータとを携帯端末50に送信する(S136)。この後の動作は、図3のケースA1と同様である。ケースB1によると、図3のケースA1と同様の効果が得られる。
(ケースB2;図8)
ケースA2は、MFP10と、第1のOSプログラムを備える携帯端末50と、の間で実行される通信を示す。MFP10の状態は、図7のケースB1の状態と同様である(即ち、MFP(S)=OFF、MFP(C)=ON)。携帯端末50は、MFP用アプリケーションをインストール済みでない。もしくは、携帯端末50は、MFP用アプリケーションをインストール済みであるが、MFP用アプリケーションを起動していない。従って、携帯端末50では、サーバ機能が有効化されているが、クライアント機能が無効化されている(即ち、端末(S)=ON、端末(C)=OFF)。
MFP10と携帯端末50との間に、LLCP接続が確立される(図6のS100でYES)。また、MFP10において、クライアント機能のみが有効化されており、携帯端末50において、サーバ機能のみが有効化されている。このために、MFP10と携帯端末50との間に、MFP(C)−端末(S)のSNEP接続のみが確立される(S102、S110でYES)。
MFP10は、MFP(C)−端末(S)のSNEP接続を利用して、PUTリクエストとURLデータとを携帯端末50に送信する(S112)。
携帯端末50は、MFP(C)−端末(S)のSNEP接続を利用して、MFP10からPUTリクエストとURLデータとを受信する。図4のケースA2と同様に、携帯端末50がMFP用アプリケーションをインストール済みでないケースでは、携帯端末50は、MFP用アプリケーションをインストールして、MFP用アプリケーションを起動させる。また、携帯端末50がMFP用アプリケーションをインストール済みであるケースでは、携帯端末50は、MFP用アプリケーションをダウンロードしないが、MFP用アプリケーションを起動させる。この結果、携帯端末50は、クライアント機能を有効化させる。即ち、携帯端末50は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。
MFP10は、MFP10と携帯端末50との間のLLCP接続を一旦切断する(S114)。その後、MFP10は、クライアント機能を有効化させる(S116)。従って、MFP10は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。そして、MFP10は、MFP10と携帯端末50との間に、LLCP接続を再び確立させる(図6のS120でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末50において、サーバ機能及びクライアント機能の両方が有効化されている。このために、両方のSNEP接続が確立される(S122、S130でYES)。この後の動作は、図7のケースB1と同様である。ケースB2によると、図4のケースA2と同様の効果が得られる。
(ケースB3;図9)
ケースA3は、MFP10と、第2のOSプログラムを備える携帯端末52と、の間で実行される通信を示す。MFP10の状態は、図7のケースB1の状態と同様である(即ち、MFP(S)=OFF、MFP(C)=ON)。また、携帯端末52は、携帯端末52の電源がONされている間に、サーバ機能が無効化されている状態を維持する。また、携帯端末52では、MFP用アプリケーションが起動されている。従って、携帯端末52において、クライアント機能のみが有効化されている(即ち、端末(S)=OFF、端末(C)=ON)。
MFP10と携帯端末52との間に、LLCP接続が確立される(図6のS100でYES)。MFP10において、クライアント機能のみが有効化されており、携帯端末52において、クライアント機能のみが有効化されている。このために、MFP10と携帯端末52との間に、MFP(C)−端末(S)のSNEP接続が確立されない(S102、S110でNO)。従って、MFP10は、URLデータを携帯端末52に送信しない(S112をスキップ)。
MFP10は、MFP10と携帯端末52との間のLLCP接続を一旦切断する(S114)。その後、MFP10は、クライアント機能を有効化させる(S116)。従って、MFP10は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。そして、MFP10は、MFP10と携帯端末50との間に、LLCP接続を再び確立させる(図6のS120でYES)。MFP10において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末52において、クライアント機能のみが有効化されている。このために、MFP(S)−端末(C)のSNEP接続のみが確立される(S122、S140でYES)。この後の動作は、図5のケースA3と同様である。ケースB3によると、図5のケースA3と同様の効果が得られる。
(第2実施例の効果)
本実施例によっても、第1実施例と同様の効果が得られる。即ち、MFP10は、どのSNEP接続が確立されるのかに応じて、図7〜図9のケースB1〜B3に示されるように、異なる通信ステップを実行する。このために、MFP10は、どのSNEP接続が確立されるのかに応じた適切な通信ステップを実行することができる。本実施例によると、MFP10は、印刷リクエストデータ、レスポンスデータ、URLデータ等を、を携帯端末50,52と適切に通信することができる。
また、図7のケースB1に示されるように、MFP10は、両方のSNEP接続が確立される場合に、一方のSNEP接続及び他方のSNEP接続のそれぞれを順次利用して、同じPUTコマンドに従って、印刷リクエストデータ及びレスポンスデータを携帯端末50と通信する。従って、携帯端末50が、PUTコマンドを利用可能であるが、GETコマンドを利用不可能である場合に、MFP10は、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
(第1及び第2実施例の相違について)
上述したように、第1実施例では、MFP10は、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。これに対し、第2実施例では、MFP10は、クライアント機能が有効化されている状態を維持するが、図6のS116が実行されない限り、サーバ機能が無効化されている状態を維持する。
第2実施例では、図7のケースB1に示されるように、携帯端末50が、MFP用アプリケーションをインストール済みであり、かつ、MFP用アプリケーションを起動している状況において、1回目のLLCP接続が確立された際に、URLデータが送信される。その後、2回目のLLCP接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。これに対し、第1実施例では、図3のケースA1に示されるように、携帯端末50が、MFP用アプリケーションをインストール済みであり、かつ、MFP用アプリケーションを起動している状況において、1回目のLLCP接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。従って、第1実施例によると、MFP10は、LLCP接続を2回に亘って確立せずに済み、1回目のLLCP接続が確立される際に、印刷リクエストデータ及びレスポンスデータを携帯端末50と迅速に通信することができる。
同様に、第2実施例では、図9のケースB3に示されるように、2回目のLLCP接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。これに対し、第1実施例では、図5のケースA3に示されるように、1回目のLLCP接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。従って、第1実施例によると、MFP10は、LLCP接続を2回に亘って確立せずに済み、1回目のLLCP接続が確立される際に、印刷リクエストデータ及びレスポンスデータを携帯端末52と迅速に通信することができる。
なお、第1実施例では、携帯端末50は、MFP用アプリケーションを起動していない状況では、クライアント機能が無効化されている状態を維持することが前提となっている。しかしながら、例えば、MFP用アプリケーションが起動されていなくても、別のアプリケーションが起動されると、携帯端末50がクライアント機能を有効化する可能性がある。従って、例えば、携帯端末50が、MFP用アプリケーションを起動していないが、サーバ機能及びクライアント機能の両方を有効化している状況(以下では「特定の状況」と呼ぶ)において、第1実施例の手法を利用すると、両方のSNEP接続が確立される(図2のS20でYES)。ただし、携帯端末50は、MFP用アプリケーションに従って動作しないために、印刷リクエストデータをMFP10に送信しない。即ち、上記の特定の状況では、MFP10と携帯端末50との間で、印刷リクエストデータ及びレスポンスデータが通信されないおそれがある。
これに対し、第2実施例では、上記の特定の状況において、1回目のLLCP接続が確立される際に、MFP(C)−端末(S)のSNEP接続のみが確立される(図6のS110でYES)。従って、MFP10から携帯端末50にURLデータが送信される(S112)。この結果、携帯端末50は、MFP用アプリケーションを起動する。その後、MFP10と携帯端末50との間に、2回目のLLCP接続が確立された際に、両方のSNEP接続が確立され(S130でYES)、印刷リクエストデータ及びレスポンスデータが通信される(S132,S136)。従って、第2実施例によると、MFP10は、上記の特定の状況において、印刷リクエストデータ及びレスポンスデータを携帯端末50と適切に通信することができる。
(対応関係)
図6のS102,S122が、「確立ステップ」の一例である。特に、S102が、「第1の状況」で実行される「確立ステップ」の一例であり、S122が、「第2の状況」で実行される「確立ステップ」の一例である。S116が、「変化ステップ」の一例である。S132及びS136、S112、S142及びS146が、それぞれ、「第1の通信ステップ」、「第2の通信ステップ」、「第3の通信ステップ」の一例である。S134,S144が、「生成ステップ」の一例である。S132で受信される印刷リクエストデータ、S136で送信されるレスポンスデータ、S112で送信されるURLデータ、S142で受信される印刷リクエストデータ、S146で送信されるレスポンスデータが、それぞれ、「第1の対象データ」、「第2の対象データ」、「第3の対象データ」、「第4の対象データ」、「第5の対象データ」の一例である。
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。上記の実施例の変形例を以下に列挙する。
(変形例1)図2のS22及びS26において、CPU32は、PUTコマンドを利用する代わりに、GETコマンドを利用して、印刷リクエストデータ及びレスポンスデータを通信してもよい。即ち、図3のケースA1の変形例に示されるように、図2のS22において、CPU32は、MFP(C)−端末(S)のSNEP接続を利用して、GETリクエストを携帯端末50に送信し、GETレスポンスと印刷リクエストデータを携帯端末50から受信してもよい。また、図2のS26において、CPU32は、MFP(S)−端末(C)のSNEP接続を利用して、携帯端末50からGETリクエストを受信し、GETレスポンスとレスポンスデータとを携帯端末50に送信してもよい。同様に、図6のS132及びS136において、CPU32は、GETコマンドを利用して、印刷リクエストデータ及びレスポンスデータを通信してもよい。即ち、「第1の通信ステップ」では、PUTコマンドの代わりに、GETコマンドが利用されてもよい。
(変形例2)例えば、両方のSNEP接続が確立されることを考慮しない場合(即ち、図3のケースA1を考慮しない場合)には、CPU32は、図2のS20〜S26を実行しなくてもよい。即ち、「第1の通信ステップ」が実行されず、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、「第2の通信ステップ」又は「第3の通信ステップ」が実行されてもよい。また、MFP10が通信すべき対象の携帯端末として、MFPアプリケーションを起動していない携帯端末を考慮しない場合(即ち、図4のケースA2を考慮しない場合)には、CPU32は、図2のS30〜S32を実行しなくてもよい。即ち、「第2の通信ステップ」が実行されず、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、「第1の通信ステップ」又は「第3の通信ステップ」が実行されてもよい。また、例えば、MFP10が通信すべき対象の携帯端末として、第2のOSプログラムを備える携帯端末52を考慮しない場合には、CPU32は、図2のS40〜S46を実行しなくてもよい。即ち、「第3の通信ステップ」が実行されず、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、「第1の通信ステップ」又は「第2の通信ステップ」が実行されてもよい。第2実施例においても、同様の変形例を採用してもよい。一般的に言うと、プロセッサは、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行すればよい。
(変形例3)上記の各実施例では、印刷リクエストデータが、「第1の対象データ」及び「第4の対象データ」の一例であり、レスポンスデータが、「第2の対象データ」及び「第5の対象データ」の一例である。これに代えて、例えば、以下の各変形例が採用されてもよい。
(変形例3−1)「第1の対象データ」及び/又は「第4の対象データ」として、スキャン機能をMFP10に実行させるためのスキャン指示コマンドを含むスキャンリクエストデータが採用されてもよい。この場合、「第2の対象データ」及び/又は「第5の対象データ」として、上記の実施例と同様に、無線設定を含むレスポンスデータが採用されてもよい。
(変形例3−2)携帯端末が、MFP10が利用すべき設定情報を、MFP10に送信すべき状況を想定する。上記の設定情報として、例えば、MFP10が印刷機能を実行するための印刷設定情報(例えば、印刷解像度、用紙サイズ等)、MFP10がスキャン機能を実行するためのスキャン設定情報(例えば、スキャン解像度等)、MFP10が通信機能を実行するための通信設定情報(例えば、IPアドレス、サブネットマスク、ゲートウェイアドレス等)を挙げることができる。これにより、MFP10は、携帯端末から受信される設定情報を利用して、様々な機能を実行することができる。MFP10は、携帯端末から設定情報を受信する場合に、設定情報を受信したことを示す応答コマンドを携帯端末に送信する。「第1の対象データ」及び/又は「第4の対象データ」として、上記の設定情報が採用されてもよい。また、「第2の対象データ」及び/又は「第5の対象データ」として、上記の応答コマンドが採用されてもよい。
(変形例3−3)携帯端末が、携帯端末内のアドレス帳に含まれるアドレス情報を、MFP10に送信すべき状況を想定する。MFP10は、携帯端末から受信されるアドレス情報を利用して、通信機能を実行することができる。MFP10は、携帯端末からアドレス情報を受信する場合に、アドレス情報を受信したことを示す応答コマンドを携帯端末に送信する。「第1の対象データ」及び/又は「第4の対象データ」として、上記のアドレス情報が採用されてもよい。また、「第2の対象データ」及び/又は「第5の対象データ」として、上記の応答コマンドが採用されてもよい。
(変形例3−4)上記の実施例では、MFP10が、ネットワーク無線通信を利用して、携帯端末から印刷データを受信する構成を採用している。これに代えて、例えば、MFP10は、NFC通信を利用して、携帯端末から印刷データを受信してもよい。この場合、MFP10は、印刷データを受信したことを示す応答コマンドを携帯端末に送信してもよい。「第1の対象データ」及び/又は「第4の対象データ」として、上記の印刷データが採用されてもよい。また、「第2の対象データ」及び/又は「第5の対象データ」として、上記の応答コマンドが採用されてもよい。
(変形例4)上記の各実施例では、スマートポスターのコマンドを含むURLデータが、「第3の対象データ」の一例である。これに代えて、例えば、携帯端末50の第1のOSプログラムがAndroid(登録商標)である場合(例えば、4.0又はそれ以降のバージョンを有するプログラムである場合)には、「第3の対象データ」は、Android(登録商標)のアプリケーションレコードを含むデータであってもよい。即ち、図2のS32又は図6のS112において、CPU32は、URLデータの代わりに、アプリケーションレコードを送信してもよい。当該アプリケーションレコードは、MFP用アプリケーションのURLを含まず、MFP用アプリケーションのパッケージ名(即ちテキスト情報)を含む。携帯端末50は、アプリケーションレコードに含まれるパッケージ名を用いて、MFP用アプリケーションをインストールしたり起動したりすることができる。本変形例では、アプリケーションレコード、パッケージ名が、それぞれ、「特定のデータ」、「識別情報」の一例である。
(変形例5)携帯端末50,52において、MFP用アプリケーションがインストール済みであることを前提とするのであれば、「第3の対象データ」として、URLデータの代わりに、MFP用アプリケーションの起動コマンド(ただしURLを含まない)が採用されてもよい。即ち、一般的に言うと、「第3の対象データ」は、外部装置の状態を、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化させるための特定のデータを含んでいればよい。
(変形例6)CPU32は、図2のS20でYESの場合に、まず、MFP(C)−端末(S)のSNEP接続を利用して、PUTコマンドに従って、MFP10内のデータ(例えばスキャンデータ)を携帯端末50に送信し、その後、MFP(S)−端末(C)のSNEP接続を利用して、PUTコマンドに従って、上記のデータを受信したことを示す応答コマンドを携帯端末50から受信してもよい。本変形例も、「通信ステップ」の一例である。また、CPU32は、図2のS40でYESの場合に、まず、MFP(S)−端末(C)のSNEP接続を利用して、GETコマンドに従って、MFP10内のデータ(例えばスキャンデータ)を携帯端末50に送信し、その後、MFP(S)−端末(C)のSNEP接続を利用して、PUTコマンドに従って、上記のデータを受信したことを示す応答コマンドを携帯端末50から受信してもよい。本変形例も、「通信ステップ」の一例である。即ち、一般的に言うと、プロセッサは、第1種及び第2種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行すればよい。
(変形例7)「通信装置」は、印刷機能及びスキャン機能を実行可能な多機能機(即ちMFP10)に限られず、印刷機能及びスキャン機能のうちの印刷機能のみを実行可能なプリンタであってもよいし、印刷機能及びスキャン機能のうちのスキャン機能のみを実行可能なスキャナであってもよい。また、「通信装置」は、印刷機能及びスキャン機能とは異なる機能(例えば、画像の表示機能、データの演算機能)を実行する装置(例えば、PC、サーバ、携帯端末(携帯電話、スマートフォン、PDA等))であってもよい。即ち、「通信装置」は、NFC方式の通信を実行可能なあらゆるデバイスを含む。同様に、「外部装置」は、NFC方式の通信を実行可能なあらゆるデバイスを含む。
(変形例8)上記の各実施例では、図2及び図6の各処理がソフトウェア(即ちプログラム36)によって実現されるが、図2及び図6の各処理のうちの少なくとも1つが論理回路等のハードウェアによって実現されてもよい。
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
2:通信システム、10:多機能機(MFP)、30:制御部、32:CPU、34:メモリ、50,52:携帯端末

Claims (16)

  1. NFC(Near Field Communication)規格に従った通信方式であるNFC方式で外部装置と通信する通信装置であって、
    前記NFC方式の通信を実行するためのNFCインターフェースと、
    特定機能を実行するための特定機能実行部と、
    プロセッサと、
    プログラムを格納しているメモリと、を備え、
    前記プロセッサは、前記メモリに格納されている前記プログラムに従って、以下の各ステップ、即ち、
    前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、第1種のSNEP(Simple NFC Data Exchange Format Exchange Protocol)接続と第2種のSNEP接続とのうちの前記第2種のSNEP接続のみが確立される場合に、前記第2種のSNEP接続を利用して、第1情報を前記外部装置に送信する第1の送信ステップであって、前記第1種のSNEP接続は、前記通信装置がSNEPサーバとして動作すると共に前記外部装置がSNEPクライアントとして動作するための接続であり、前記第2種のSNEP接続は、前記通信装置が前記SNEPクライアントとして動作すると共に前記外部装置が前記SNEPサーバとして動作するための接続であり、前記第1情報は、前記外部装置の状態を、前記SNEPクライアントが無効化されている状態から前記SNEPクライントが有効化されている状態に変化させるための情報である、前記第1の送信ステップと、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記SNEPクライントが有効化されている前記外部装置との間に確立された前記第2種のSNEP接続を利用して、第2情報を前記外部装置に送信する第2の送信ステップであって、前記第2情報は、前記外部装置が第3情報を送信するために必要な情報であり、前記第3情報は、前記特定機能を前記通信装置に実行させるための情報である、前記第2の送信ステップと、
    前記第2情報が前記外部装置に送信された後に、前記SNEPクライントが有効化されている前記外部装置から前記第3情報を受信する第1の受信ステップと、
    前記第3情報が受信される場合に、前記特定機能実行部に前記特定機能を実行させる機能制御ステップと、
    を実行する、通信装置。
  2. 前記特定機能は、画像処理機能である、請求項1に記載の通信装置。
  3. 前記特定機能は、印刷機能であり、
    前記第3情報は、印刷対象の画像を表わす印刷データである、請求項2に記載の通信装置。
  4. 前記プロセッサは、
    前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを試行し、当該試行の結果として、前記第2種のSNEP接続のみが確立される場合に、前記第1の送信ステップを実行し、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを再び試行し、当該試行の結果として、前記第1種のSNEP接続と前記第2種のSNEP接続との双方が確立される場合に、前記第2種のSNEP接続を利用して、前記第2の送信ステップを実行する、請求項1から3のいずれか一項に記載の通信装置。
  5. 前記プロセッサは、
    前記NFCインターフェースにおいて第1のLLCP(Logical Link Control Protocol)接続が確立される場合に、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを試行し、当該試行の結果として、前記第2種のSNEP接続のみが確立される場合に、前記第1の送信ステップを実行し、
    前記第1情報が前記外部装置に送信された後に、前記NFCインターフェースにおいて第2のLLCP接続が確立される場合に、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを再び試行し、当該試行の結果として、前記第1種のSNEP接続と前記第2種のSNEP接続との双方が確立される場合に、前記第2種のSNEP接続を利用して、前記第2の送信ステップを実行する、請求項4に記載の通信装置。
  6. 前記プロセッサは、前記メモリに格納されている前記プログラムに従って、さらに、
    前記第1情報が前記外部装置に送信された後に、前記第1のLLCP接続を切断する切断ステップを実行し、
    前記プロセッサは、前記第1のLLCP接続が切断された後に、前記NFCインターフェースにおいて前記第2のLLCP接続が確立される場合に、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを再び試行する、請求項5に記載の通信装置。
  7. 前記プロセッサは、
    前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続と前記第2種のSNEP接続とのうちの前記第2種のSNEP接続のみを確立することを試行し、当該試行の結果として、前記第2種のSNEP接続のみが確立される場合に、前記第1の送信ステップを実行し、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを試行し、当該試行の結果として、前記第1種のSNEP接続と前記第2種のSNEP接続との双方が確立される場合に、前記第2種のSNEP接続を利用して、前記第2の送信ステップを実行する、請求項1から3のいずれか一項に記載の通信装置。
  8. 前記プロセッサは、前記通信装置の状態が、前記SNEPサーバと前記SNEPクライアントとのうちの前記SNEPクライアントのみが有効化されている状態において、前記NFCインターフェースにおいて第1のLLCP(Logical Link Control Protocolの略)接続が確立される場合に、前記第2種のSNEP接続のみを確立することを試行する、請求項7に記載の通信装置。
  9. 前記プロセッサは、前記メモリに格納されている前記プログラムに従って、さらに、
    前記第2種のSNEP接続のみが確立された後に、前記通信装置の状態を、前記SNEPクライアントのみが有効化されている状態から、前記SNEPサーバと前記SNEPクライアントとの双方が有効化されている状態に変化させる変化ステップを実行し、
    前記プロセッサは、前記通信装置の状態が、前記SNEPサーバと前記SNEPクライアントとの双方が有効化されている状態に変化した後に、前記NFCインターフェースにおいて第2のLLCP接続が確立される場合に、前記第1種のSNEP接続と前記第2種のSNEP接続との双方を確立することを試行する、請求項8に記載の通信装置。
  10. 前記第1情報は、SNEPの特定コマンドに従って、前記第2種のSNEP接続を利用して前記外部装置に送信され、
    前記第2情報は、SNEPの前記特定コマンドに従って、前記第2種のSNEP接続を利用して前記外部装置に送信される、請求項1から9のいずれか一項に記載の通信装置。
  11. 前記特定コマンドは、PUTコマンドである、請求項10に記載の通信装置。
  12. 前記プロセッサは、前記メモリに格納されている前記プログラムに従って、さらに、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記SNEPクライントが有効化されている前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続と前記第2種のSNEP接続とのうちの前記第1種のSNEP接続のみが確立される場合に、前記第1種のSNEP接続を利用して、前記第2情報を前記外部装置に送信する第3の送信ステップを実行する、請求項1から11のいずれか一項に記載の通信装置。
  13. 前記プロセッサは、前記メモリに格納されている前記プログラムに従って、さらに、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記SNEPクライントが有効化されている前記外部装置との間に、前記NFCインターフェースを介して、前記第1種のSNEP接続のみが確立される場合に、前記第1種のSNEP接続を利用して、前記外部装置から要求データを受信する第2の受信ステップを実行し、
    前記第情報は、前記要求データを受信することに応じて、前記第1種のSNEP接続を利用して、前記外部装置に送信される、請求項12に記載の通信装置。
  14. 前記要求データは、PUTコマンドに従って、前記第1種のSNEP接続を利用して前記外部装置から受信され、
    前記第情報は、GETコマンドに従って、前記第1種のSNEP接続を利用して前記外部装置に送信される、請求項13に記載の通信装置。
  15. 前記通信装置は、前記通信装置の電源がONされている間に、前記SNEPサーバと前記SNEPクライアントとの双方が有効化されている状態を維持する、請求項1から6のいずれか一項に記載の通信装置。
  16. NFC(Near Field Communication)規格に従った通信方式であるNFC方式で外部装置と通信する通信装置のためのコンピュータプログラムであって、
    前記通信装置は、
    前記NFC方式の通信を実行するためのNFCインターフェースと、
    特定機能を実行するための特定機能実行部と、
    プロセッサと、を備え、
    前記コンピュータプログラムは、前記プロセッサに、以下の各ステップ、即ち、
    前記通信装置と前記外部装置との間に、前記NFCインターフェースを介して、第1種のSNEP(Simple NFC Data Exchange Format Exchange Protocol)接続と第2種のSNEP接続とのうちの前記第2種のSNEP接続のみが確立される場合に、前記第2種のSNEP接続を利用して、第1情報を前記外部装置に送信する第1の送信ステップであって、前記第1種のSNEP接続は、前記通信装置がSNEPサーバとして動作すると共に前記外部装置がSNEPクライアントとして動作するための接続であり、前記第2種のSNEP接続は、前記通信装置が前記SNEPクライアントとして動作すると共に前記外部装置が前記SNEPサーバとして動作するための接続であり、前記第1情報は、前記外部装置の状態を、前記SNEPクライアントが無効化されている状態から前記SNEPクライントが有効化されている状態に変化させるための情報である、前記第1の送信ステップと、
    前記第1情報が前記外部装置に送信された後に、前記通信装置と前記SNEPクライントが有効化されている前記外部装置との間に確立された前記第2種のSNEP接続を利用して、第2情報を前記外部装置に送信する第2の送信ステップであって、前記第2情報は、前記外部装置が第3情報を送信するために必要な情報であり、前記第3情報は、前記特定機能を前記通信装置に実行させるための情報である、前記第2の送信ステップと、
    前記第2情報が前記外部装置に送信された後に、前記SNEPクライントが有効化されている前記外部装置から前記第3情報を受信する第1の受信ステップと、
    前記第3情報が受信される場合に、前記特定機能実行部に前記特定機能を実行させる機能制御ステップと、
    を実行させる、コンピュータプログラム。
JP2017125980A 2017-06-28 2017-06-28 通信装置 Active JP6414283B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017125980A JP6414283B2 (ja) 2017-06-28 2017-06-28 通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017125980A JP6414283B2 (ja) 2017-06-28 2017-06-28 通信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2016124138A Division JP6168201B2 (ja) 2016-06-23 2016-06-23 通信装置

Publications (2)

Publication Number Publication Date
JP2017212738A JP2017212738A (ja) 2017-11-30
JP6414283B2 true JP6414283B2 (ja) 2018-10-31

Family

ID=60476327

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017125980A Active JP6414283B2 (ja) 2017-06-28 2017-06-28 通信装置

Country Status (1)

Country Link
JP (1) JP6414283B2 (ja)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6600902B1 (en) * 1999-10-22 2003-07-29 Koninklijke Philips Electronics N.V. Multiple link data object conveying method for conveying data objects to wireless stations
JP2004172988A (ja) * 2002-11-20 2004-06-17 Sony Corp 通信装置、通信方法およびデジタルカメラシステム
JP2009515250A (ja) * 2005-11-07 2009-04-09 エルジー エレクトロニクス インコーポレイティド 近距離通信ホストコントローラインターフェイス
US8400913B2 (en) * 2007-05-23 2013-03-19 Microsoft Corporation Method for optimizing near field links
JP2009147896A (ja) * 2007-09-12 2009-07-02 Ricoh Co Ltd 情報処理システム、情報処理装置、情報通信方法、および情報処理装置で実行されるプログラム。
US9558485B2 (en) * 2008-01-30 2017-01-31 Paypal, Inc. Two step near field communication transactions
EP2239924A1 (fr) * 2009-04-08 2010-10-13 Gemalto SA Procédé de présélection d'au moins une application dans un dispositif mobile de communication comportant un système NFC
JP4676014B2 (ja) * 2009-06-30 2011-04-27 株式会社東芝 情報処理装置およびキャプチャ画像の転送処理方法
JP5743675B2 (ja) * 2010-05-13 2015-07-01 キヤノン株式会社 通信装置、通信装置の制御方法およびプログラム。

Also Published As

Publication number Publication date
JP2017212738A (ja) 2017-11-30

Similar Documents

Publication Publication Date Title
JP5958161B2 (ja) 通信装置
US11381280B2 (en) Communication device
JP5900228B2 (ja) 通信装置
JP5900226B2 (ja) 通信装置
JP6123416B2 (ja) 通信装置
JP2014192821A (ja) 通信装置
JP6168201B2 (ja) 通信装置
JP6414283B2 (ja) 通信装置
JP6406364B2 (ja) 通信装置
JP6070880B2 (ja) 通信装置
JP6337984B2 (ja) 通信装置
JP2019068438A (ja) 通信装置
JP2018064279A (ja) 通信装置
JP2016028536A (ja) 通信装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180629

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180710

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180719

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180904

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180917

R150 Certificate of patent or registration of utility model

Ref document number: 6414283

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150