Communication device

本明細書によって開示される技術は、ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式で、通信対象の対象データを外部装置と通信する通信装置に関する。

特許文献１には、通信端末と、ＮＦＣデバイスと、を備えるシステムが開示されている。 通信端末がＲ／Ｗモードであり、かつ、ＮＦＣデバイスがパッシブタグモードである状態において、通信端末からＮＦＣデバイスにデータ読み出し要求が送信される。 次いで、通信端末及びＮＦＣデバイスのそれぞれは、Ｐ２Ｐモードに移行する。 通信端末がＰ２Ｐモードであり、かつ、ＮＦＣデバイスがＰ２Ｐモードである状態において、ＮＦＣデバイスから通信端末にデータが転送される。 データ転送が完了すると、通信端末は、パッシブタグモードに移行し、ＮＦＣデバイスは、Ｒ／Ｗモードに移行する。

本明細書では、通信装置が、ＮＦＣ方式で通信対象の対象データを外部装置と適切に通信するための技術を提供する。

本明細書によって開示される技術は、ＮＦＣ（Near Field Communication）規格に従った通信方式であるＮＦＣ方式で、通信対象の対象データを外部装置と通信する通信装置である。
通信装置は、ＮＦＣ方式の通信を実行するためのＮＦＣインターフェースと、プロセッサと、プログラムを格納しているメモリと、を備える。 プロセッサは、メモリに格納されているプログラムに従って、以下の各ステップ、即ち、
通信装置の現在の状態と外部装置の現在の状態とに応じて、通信装置と外部装置との間に、ＮＦＣ規格で定められている特定のプロトコルに従った第１種及び第２種の接続のうちの少なくとも１種の接続を確立する確立ステップであって、
（Ａ）通信装置の現在の状態が、特定のプロトコルに従ったサーバ機能が有効化されている状態であり、かつ、外部装置の現在の状態が、特定のプロトコルに従ったクライアント機能が有効化されている状態である場合に、通信装置がサーバとして動作すると共に外部装置がクライアントとして動作するための第１種の接続を確立し、
（Ｂ）通信装置の現在の状態が、クライアント機能が有効化されている状態であり、かつ、外部装置の現在の状態が、サーバ機能が有効化されている状態である場合に、通信装置がクライアントとして動作すると共に外部装置がサーバとして動作するための第２種の接続を確立する、確立ステップと、
確立済みの少なくとも１種の接続を利用して、ＮＦＣインターフェースを介して、対象データを外部装置と通信する通信ステップと、を実行する。
プロセッサは、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行する。

上記の構成によると、通信装置は、通信装置及び外部装置の状態（即ち、サーバ機能及びクライアント機能のそれぞれの有効化に関する状態）に応じて、第１種及び第２種の接続のうちの少なくとも１種の接続を確立する。 そして、通信装置は、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行する。 このために、通信装置は、どの種の接続が確立されるのかに応じた適切な通信ステップを実行し得る。 従って、通信装置は、対象データを外部装置と適切に通信し得る。

通信ステップは、第１種及び第２種の接続の両方が確立される場合に、第１種の接続を利用して、ＮＦＣインターフェースを介して、外部装置から第１の対象データを受信し、その後、第２種の接続を利用して、ＮＦＣインターフェースを介して、第２の対象データを外部装置に送信する第１の通信ステップを含んでいてもよい。 この構成によると、通信装置は、第１種及び第２種の接続の両方が確立される場合に、第１種及び第２種の接続のそれぞれを順次利用して、第１及び第２の対象データのそれぞれを外部装置と順次通信する。 従って、通信装置は、第１及び第２の対象データを外部装置と適切に通信し得る。

第１の通信ステップは、特定のプロトコルのＰＵＴコマンドに従って、外部装置から第１の対象データを受信し、その後、特定のプロトコルのＰＵＴコマンドに従って、第２の対象データを外部装置に送信することを含んでいてもよい。 この構成によると、通信装置は、同じＰＵＴコマンドに従って、第１及び第２の対象データを外部装置と通信する。 従って、例えば、外部装置が、ＰＵＴコマンドを利用可能であるが、ＰＵＴコマンドとは異なるコマンドを利用不可能である場合に、通信装置は、第１及び第２の対象データを外部装置と適切に通信し得る。

第１の対象データは、特定のリクエストを示すデータを含んでいてもよい。 第２の対象データは、特定のリクエストに対するレスポンスを示すデータを含んでいてもよい。 プロセッサは、メモリに格納されているプログラムに従って、さらに、第１の対象データが受信される場合に、特定のリクエストに対応する処理を実行して、第２の対象データを生成する生成ステップを実行してもよい。 この構成によると、通信装置は、外部装置から第１の対象データを受信する場合に、特定のリクエストに対応する処理を実行して、第２の対象データを生成することができる。

通信ステップは、第１種及び第２種の接続のうちの第２種の接続のみが確立される場合に、第２種の接続を利用して、ＮＦＣインターフェースを介して、第３の対象データを外部装置に送信する第２の通信ステップを含んでいてもよい。 この構成によると、通信装置は、第２種の接続のみが確立される場合に、第３の対象データを外部装置に適切に送信し得る。

第２の通信ステップは、特定のプロトコルのＰＵＴコマンドに従って、第３の対象データを外部装置に送信することを含んでいてもよい。 この構成によると、通信装置は、ＰＵＴコマンドに従って、第３の対象データを外部装置に送信する。 従って、例えば、外部装置が、ＰＵＴコマンドを利用可能であるが、ＰＵＴコマンドとは異なるコマンドを利用不可能である場合に、通信装置は、第３の対象データを外部装置に適切に送信し得る。

第３の対象データは、外部装置の状態を、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化させるための特定のデータを含んでいてもよい。 この構成によると、通信装置は、第３の対象データを外部装置に送信することによって、外部装置のクライアント機能を有効化させ得る。

特定のデータは、外部装置が通信装置に特定の機能を実行させるための特定のアプリケーションを識別する識別情報を含んでいてもよい。 この構成によると、通信装置は、外部装置のクライアント機能を適切に有効化させ得る。

通信ステップは、第１種及び第２種の接続のうちの第１種の接続のみが確立される場合に、第１種の接続を利用して、ＮＦＣインターフェースを介して、外部装置から第４の対象データを受信し、その後、第１種の接続を利用して、ＮＦＣインターフェースを介して、第５の対象データを外部装置に送信する第３の通信ステップを含んでいてもよい。 この構成によると、通信装置は、第１種の接続のみが確立される場合に、第１種の接続を利用して、第４及び第５の対象データのそれぞれを外部装置と順次通信する。 従って、通信装置は、第４及び第５の対象データを外部装置と適切に通信し得る。

第３の通信ステップは、特定のプロトコルのＰＵＴコマンドに従って、外部装置から第４の対象データを受信し、その後、特定のプロトコルのＧＥＴコマンドに従って、第５の対象データを外部装置に送信することを含んでいてもよい。 この構成によると、外部装置が、ＰＵＴコマンド及びＧＥＴコマンドを利用可能である場合に、通信装置は、第４及び第５の対象データを外部装置と適切に通信し得る。

第４の対象データは、特定のリクエストを示すデータを含んでいてもよい。 第５の対象データは、特定のリクエストに対するレスポンスを示すデータを含んでいてもよい。 プロセッサは、メモリに格納されているプログラムに従って、さらに、第４の対象データが受信される場合に、特定のリクエストに対応する処理を実行して、第５の対象データを生成する生成ステップを実行してもよい。 この構成によると、通信装置は、外部装置から第４の対象データを受信する場合に、特定のリクエストに対応する処理を実行して、第５の対象データを生成することができる。

通信装置は、通信装置の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持してもよい。 プロセッサは、通信装置の現在の状態が、サーバ機能及びクライアント機能の両方が有効化されている状態である状況において、確立ステップを実行してもよい。 この構成によると、通信装置は、確立ステップを適切に実行して、対象データを外部装置と適切に通信し得る。

プロセッサは、通信装置の現在の状態が、サーバ機能及びクライアント機能のうちのクライアント機能のみが有効化されている状態である第１の状況において、確立ステップを実行してもよい。 プロセッサは、メモリに格納されているプログラムに従って、さらに、第１の状況において確立ステップが実行された後に、通信装置の状態を、サーバ機能及びクライアント機能のうちのクライアント機能のみが有効化されている状態から、サーバ機能及びクライアント機能の両方が有効化されている状態に変化させる変化ステップを実行させてもよい。 プロセッサは、変化ステップが実行された後に、通信装置の現在の状態が、サーバ機能及びクライアント機能の両方が有効化されている状態である第２の状況において、確立ステップを再び実行してもよい。 この構成によると、通信装置は、確立ステップを適切に実行して、対象データを外部装置と適切に通信し得る。

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

通信システムの構成を示す。

第１実施例のＭＦＰのＮＦＣ処理のフローチャートを示す。

ケースＡ１の通信のシーケンスチャートを示す。

ケースＡ２の通信のシーケンスチャートを示す。

ケースＡ３の通信のシーケンスチャートを示す。

第２実施例のＭＦＰのＮＦＣ処理のフローチャートを示す。

ケースＢ１の通信のシーケンスチャートを示す。

ケースＢ２の通信のシーケンスチャートを示す。

ケースＢ３の通信のシーケンスチャートを示す。

（第１実施例）
（通信システム２の構成）
図１に示すように、通信システム２は、多機能機（以下では「ＭＦＰ（Multi-Function Peripheralの略）」と呼ぶ）１０と、携帯端末５０，５２と、を備える。 ＭＦＰ１０と携帯端末５０，５２とは、それぞれ、ＮＦＣ規格の通信方式（即ちＮＦＣ方式）の通信を実行可能である。 本実施例では、ＮＦＣ規格は、ＩＳＯ／ＩＥＣ２１４８１又はＩＳＯ／ＩＥＣ１８０９２の国際標準規格である。 ＮＦＣ方式の通信は、１３．５６ＭＨｚ帯の電波を利用した無線通信である。 また、ＭＦＰ１０と携帯端末５０，５２とは、それぞれ、ＮＦＣ方式の通信リンクとは異なる通信ネットワークを利用して、有線通信又は無線通信を実行可能である。

（ＭＦＰ１０の構成）
ＭＦＰ１０は、操作部１２と、表示部１４と、ネットワークインターフェース（以下では、インターフェースのことを「Ｉ／Ｆ」と記載する）１６と、印刷実行部１８と、スキャン実行部２０と、ＮＦＣ Ｉ／Ｆ２２と、制御部３０と、を備える。

操作部１２は、複数のキーを備える。 ユーザは、操作部１２を操作することによって、様々な指示をＭＦＰ１０に入力することができる。 表示部１４は、様々な情報を表示するためのディスプレイである。 ネットワークＩ／Ｆ１６は、有線ネットワークに接続するためのＩ／Ｆであってもよいし、無線ネットワークに接続するためのＩ／Ｆであってもよい。 なお、この無線ネットワークは、ＮＦＣ方式の通信とは異なる無線通信を実行するためのネットワークであり、例えば、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.の略）の８０２．１１の規格、及び、それに準ずる規格（例えば８０２．１１ａ，１１ｂ，１１ｇ，１１ｎ等）に従ったネットワークである。 印刷実行部１８は、インクジェット方式、レーザ方式等の印刷機構である。 スキャン実行部２０は、ＣＣＤ、ＣＩＳ等のスキャン機構である。

ＮＦＣ Ｉ／Ｆ２２は、ＮＦＣ方式の通信を実行するためのインターフェースである。 ＮＦＣ Ｉ／Ｆ２２は、ネットワークＩ／Ｆ１６とは異なるチップによって構成されている。 なお、ネットワークＩ／Ｆ１６が無線ネットワークに接続するためのＩ／Ｆである場合には、ネットワークＩ／Ｆ１６とＮＦＣ Ｉ／Ｆ２２とは、以下の点で異なる。

即ち、ネットワークＩ／Ｆ１６を介した無線通信の通信速度は、ＮＦＣ Ｉ／Ｆ２２を介した無線通信の通信速度よりも速い。 さらに、ネットワークＩ／Ｆ１６を介した無線通信における搬送波の周波数は、ＮＦＣ Ｉ／Ｆ２２を介した無線通信における搬送波の周波数とは異なる。 また、例えば、ＭＦＰ１０と携帯端末５０との距離がおよそ１０ｃｍ以下である場合に、ＭＦＰ１０は、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末５０とＮＦＣ方式の通信を実行可能である。 一方において、例えば、ＭＦＰ１０と携帯端末５０との距離が、１０ｃｍ以下である場合でも、１０ｃｍ以上である場合でも、ＭＦＰ１０は、ネットワークＩ／Ｆ１６を介して、携帯端末５０と無線通信を実行可能である。 即ち、ＭＦＰ１０が、ネットワークＩ／Ｆ１６を介して、通信先の機器（例えば携帯端末５０）と無線通信を実行可能な最大の距離は、ＭＦＰ１０が、ＮＦＣ Ｉ／Ｆ２２を介して、通信先の機器と無線通信を実行可能な最大の距離よりも大きい。 なお、以下では、ネットワークＩ／Ｆ１６を介した無線通信のことを、「ネットワーク無線通信」と呼ぶ。

制御部３０は、ＣＰＵ３２とメモリ３４とを備える。 ＣＰＵ３２は、メモリ３４に格納されているプログラム３６に従って、様々な処理を実行する。 メモリ３４は、ＲＯＭ、ＲＡＭ、ハードディスク等によって構成される。 メモリ３４は、ＣＰＵ３２によって実行される上記のプログラム３６を格納する。

プログラム３６は、アプリケーションプログラムと、プロトコルスタックと、を含む。 アプリケーションプログラムは、ＣＰＵ３２が、ＯＳＩ参照モデルのアプリケーション層の処理を実行するためのプログラムである。 プロトコルスタックは、ＣＰＵ３２が、ＯＳＩ参照モデルのアプリケーション層よりも下位層の処理を実行するためのプログラムである。 プロトコルスタックは、ＮＦＣフォーラムによって定められたＮＦＣ規格に準拠した処理を実行するためのプログラムである。 プロトコルスタックは、ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モードに従った処理を実行するためのＰ２Ｐプログラムを含む。 なお、プロトコルスタックは、ＮＦＣ規格のＲ／Ｗ（Reader/Writerの略）モードに従った処理を実行するためのＲ／Ｗプログラムを含んでいてもよいし、含んでいなくてもよい。 また、プロトコルスタックは、ＮＦＣ規格のＣＥ（Card Emulationの略）モードに従った処理を実行するためのＣＥプログラムを含んでいてもよいし、含んでいなくてもよい。

以下では、ＮＦＣ方式の通信を実行可能な機器（ＭＦＰ１０、携帯端末５０，５２等）のことを「ＮＦＣ機器」と呼ぶ。 ＮＦＣ機器の中には、Ｐ２Ｐモード、Ｒ／Ｗモード、及び、ＣＥモードの３つのモードの全てを利用可能な機器も存在するし、上記の３つのモードのうちの１つ又は２つのモードのみを利用可能な機器も存在する。 本実施例では、ＭＦＰ１０のプログラム３６がＰ２Ｐプログラムを含むために、ＭＦＰ１０は、少なくともＰ２Ｐモードを利用可能である。 また、携帯端末５０，５２も、少なくともＰ２Ｐモードを利用可能である。

Ｐ２Ｐモードは、一対のＮＦＣ機器の間で双方向通信を実行するためのモードである。
例えば、第１のＮＦＣ機器と第２のＮＦＣ機器との両方が、Ｐ２Ｐモードに従って動作する状況を想定する。 この場合、第１のＮＦＣ機器と第２のＮＦＣ機器との間で、Ｐ２Ｐモードに従った通信を実行するための通信リンクが確立される。 なお、以下では、Ｐ２Ｐモードに従った通信を実行するための通信リンクのことを、「ＬＬＣＰ（Logical Link Control Protocol）接続」と呼ぶことがある。 例えば、第１のＮＦＣ機器は、ＬＬＣＰ接続を利用して、第１のデータを第２のＮＦＣ機器に送信する。 その後、第２のＮＦＣ機器は、通常、同じＬＬＣＰ接続を利用して、第２のデータを第１のＮＦＣ機器に送信する。 これにより、双方向通信が実現される。

なお、ＮＦＣフォーラムによって定められるＩＳＯ／ＩＥＣ １４４３のＴｙｐｅＡであるＮＦＣ機器、及び、ＩＳＯ／ＩＥＣ １８０９２のＴｙｐｅＦであるＮＦＣ機器は、Ｐ２Ｐモードに従って動作することができる。 ただし、ＩＳＯ／ＩＥＣ １４４３のＴｙｐｅＢであるＮＦＣ機器は、Ｐ２Ｐモードに従って動作することができない。

一対のＮＦＣ機器の間でＬＬＣＰ接続が確立される場合には、一対の通信機器は、通常、さらに、ＳＮＥＰ（Simple NDEF(NFC Data Exchange Format) Exchange Protocolの略）接続を確立する。 ＳＮＥＰ接続では、一対のＮＦＣ機器のうちの一方のＮＥＣ機器がサーバとして動作すると共に、一対のＮＦＣ機器のうちの他方のＮＦＣ機器がクライアントとして動作する。 一対のＮＦＣ機器のそれぞれがサーバ及びクライアントのどちらで動作するのかは、一対のＮＦＣ機器のそれぞれの状態に依存する。

例えば、ＭＦＰ１０の状態が、ＳＮＥＰのサーバ機能が有効化されている状態であり、かつ、携帯端末５０の状態が、ＳＮＥＰのクライアント機能が有効化されている状態である場合には、ＭＦＰ１０がサーバとして動作すると共に携帯端末５０がクライアントとして動作するためのＳＮＥＰ接続（以下では「ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続」と呼ぶ）が確立される。 また、例えば、ＭＦＰ１０の状態が、ＳＮＥＰのクライアント機能が有効化されている状態であり、かつ、携帯端末５０の状態が、ＳＮＥＰのサーバ機能が有効化されている状態である場合には、ＭＦＰ１０がクライアントとして動作すると共に携帯端末５０がサーバとして動作するためのＳＮＥＰ接続（以下では、「ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続」と呼ぶ）が確立される。

なお、例えば、ＭＦＰ１０の状態が、ＳＮＥＰのサーバ機能及びクライアント機能の両方が有効化されている状態であり、かつ、携帯端末５０の状態が、ＳＮＥＰのサーバ機能及びクライアント機能が有効化されている状態である場合には、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、の両方のＳＮＥＰ接続が確立される。 なお、以下では、ＳＮＥＰのサーバ機能、ＳＮＥＰのクライアント機能のことを、それぞれ、「サーバ機能」、「クライアント機能」と簡単に記載する。

本実施例では、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。 従って、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、のうちのどの接続が確立されるのかは、通信相手（即ち、携帯端末５０，５２）の状態に依存する。 即ち、通信相手の状態が、サーバ機能及びクライアント機能の両方が有効化されている場合には、両方のＳＮＥＰ接続が確立される。 また、通信相手の状態が、サーバ機能のみが有効化されている場合には、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される。 また、通信相手の状態が、クライアント機能のみが有効化されている場合には、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立される。

ＳＮＥＰ接続では、クライアントとして動作するＮＦＣ機器（以下では単に「クライアント」と呼ぶ）が、サーバとして動作するＮＦＣ機器（以下では単に「サーバ」と呼ぶ）にリクエストコマンドを送信する。 例えば、クライアントは、ＰＵＴコマンドを利用して、クライアント内の対象データをサーバに送信することができる。 具体的に言うと、クライアントは、ＰＵＴリクエストと対象データとをサーバに送信する。 これにより、サーバは、クライアントから対象データを受信して、対象データを利用することができる。 また、例えば、クライアントは、ＧＥＴコマンドを利用して、サーバ内の対象データをサーバから受信することができる。 具体的に言うと、クライアントは、ＧＥＴリクエストをサーバに送信する。 この場合、サーバは、ＧＥＴレスポンスと対象データとをクライアントに送信する。 これにより、クライアントは、サーバから対象データを受信して、対象データを利用することができる。 なお、サーバは、ＰＵＴリクエスト又はＧＥＴリクエストを送信することができず、ＰＵＴリクエスト又はＧＥＴリクエストに応じた処理（例えば、ＧＥＴリクエストに対するＧＥＴレスポンスの送信）を実行する。 このように、ＳＮＥＰ接続では、クライアントは、対象データの通信のハンドリングを実行し、サーバは、クライアントの動作に応じて、対象データの通信を実行する。

（携帯端末５０，５２の構成）
携帯端末５０，５２は、例えば、携帯電話（例えばスマートフォン）、ＰＤＡ、ノートＰＣ、タブレットＰＣ、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末である。 携帯端末５０，５２のそれぞれは、無線ネットワークに接続するためのネットワークＩ／Ｆと、ＮＦＣ Ｉ／Ｆと、を備える。 従って、携帯端末５０，５２のそれぞれは、ネットワークＩ／Ｆを介して、ＭＦＰ１０と無線通信を実行可能であると共に、ＮＦＣ Ｉ／Ｆを利用して、ＭＦＰ１０と無線通信を実行可能である。

携帯端末５０，５２のそれぞれは、ＭＦＰ１０に様々な機能（例えば、印刷機能、スキャン機能等）を実行させるためのアプリケーションプログラム（以下では「ＭＦＰ用アプリケーション」と呼ぶ）をインストールすることができる。 なお、本実施例では、携帯端末５０，５２は、ＭＦＰ１０のベンダによって提供されるインターネットサーバ（図示省略）から、ＭＦＰ用アプリケーションをインストールする。

携帯端末５０は、第１のＯＳ（Operation Systemの略）プログラムを備える。 第１のＯＳプログラムは、例えば、Ａｎｄｒｏｉｄ（登録商標）のバージョン４．０である。 第１のＯＳプログラムは、携帯端末５０を以下のように動作させる。 即ち、携帯端末５０は、携帯端末５０の電源がＯＮされている間に、サーバ機能が有効化されている状態を維持する。 携帯端末５０は、ＭＦＰ用アプリケーションがインストールされていない場合には、クライアント機能が無効化されている状態を維持する。 携帯端末５０は、ＭＦＰ用アプリケーションがインストールされていても、ＭＦＰ用アプリケーションが起動されていない場合には、クライアント機能が無効化されている状態を維持する。 携帯端末５０は、ＭＦＰ用アプリケーションが起動されると、クライアント機能を有効化し、ＭＦＰ用アプリケーションが終了すると（即ち、ＭＦＰ用アプリケーションが起動されていない状態になると）、クライアント機能を無効化する。

携帯端末５２は、第１のＯＳプログラムとは異なる第２のＯＳプログラムを備える。 第２のＯＳプログラムは、携帯端末５２を以下のように動作させる。 即ち、携帯端末５２は、ＭＦＰ用アプリケーションがインストールされていない場合には、携帯端末５２の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が無効化されている状態を維持する。 携帯端末５２は、ＭＦＰ用アプリケーションがインストールされていても、ＭＦＰ用アプリケーションが起動されていない場合には、サーバ機能及びクライアント機能の両方が無効化されている状態を維持する。 携帯端末５２は、ＭＦＰ用アプリケーションが起動されると、クライアント機能を有効化し、ＭＦＰ用アプリケーションが終了すると（即ち、ＭＦＰ用アプリケーションが起動されていない状態になると）、クライアント機能を無効化する。

（Ｐｏｌｌ動作及びＬｉｓｔｅｎ動作）
続いて、ＮＦＣ機器によって実行されるＰｏｌｌ動作及びＬｉｓｔｅｎ動作について説明する。 例えば、ＭＦＰ１０では、ＣＰＵ３２が、プログラムに従ってＰｏｌｌ動作及びＬｉｓｔｅｎ動作を実行するのではなく、ＮＦＣ Ｉ／Ｆ２２が、Ｐｏｌｌ動作及びＬｉｓｔｅｎ動作を実行する。 Ｐｏｌｌ動作は、ポーリング信号を送信して、ポーリング信号に対するレスポンス信号を受信する動作である。 また、Ｌｉｓｔｅｎ動作は、ポーリング信号を受信して、ポーリング信号に対するレスポンス信号を送信する動作である。

ＭＦＰ１０のＮＦＣ Ｉ／Ｆ２２は、Ｐｏｌｌ動作を実行するためのＰｏｌｌモードと、Ｌｉｓｔｅｎ動作を実行するためのＬｉｓｔｅｎモードと、Ｐｏｌｌ動作及びＬｉｓｔｅｎ動作のどちらも実行しないモード（以下では「不実行モード」と呼ぶ）と、のうちのいずれかのモードで動作可能である。 ＮＦＣ Ｉ／Ｆ２２は、Ｐｏｌｌモード、Ｌｉｓｔｅｎモード、及び、不実行モードで、順次動作する。 例えば、ＮＦＣ Ｉ／Ｆ２２は、Ｐｏｌｌモードで動作し、次いで、Ｌｉｓｔｅｎモードで動作し、次いで、不実行モードで動作する、という１セットの動作を実行する。 ＮＦＣ Ｉ／Ｆ２２は、上記の１セットの動作を繰り返し実行する。

Ｐｏｌｌモードでは、ＮＦＣ Ｉ／Ｆ２２は、ポーリング信号を送信して、レスポンス信号を受信することを監視する。 Ｌｉｓｔｅｎモードでは、ＮＦＣ Ｉ／Ｆ２２は、ポーリング信号を受信することを監視して、ポーリング信号を受信すると、レスポンス信号を送信する。 不実行モードでは、ＮＦＣ Ｉ／Ｆ２２は、ポーリング信号を送信せず、さらに、ポーリング信号を受信しても、レスポンス信号を送信しない。

携帯端末５０，５２のそれぞれも、上記の１セットの動作を繰り返し実行する。 従って、例えば、ＭＦＰ１０と携帯端末５０との間の距離が１０ｃｍ未満であり、かつ、ＭＦＰ１０のＮＦＣ Ｉ／Ｆ２２がＰｏｌｌモードで動作する期間と、携帯端末５０がＬｉｓｔｅｎモードで動作する期間と、が一致する場合には、ＮＦＣ Ｉ／Ｆ２２は、ポーリング信号を携帯端末５０に送信して、レスポンス信号を携帯端末５０から受信するＰｏｌｌ動作を実行する。 また、例えば、ＭＦＰ１０と携帯端末５０との間の距離が１０ｃｍ未満であり、ＮＦＣ Ｉ／Ｆ２２がＬｉｓｔｅｎモードで動作する期間と、携帯端末５０がＰｏｌｌモードで動作する期間と、が一致すると、ＮＦＣ Ｉ／Ｆ２２は、ポーリング信号を携帯端末５０から受信して、レスポンス信号を携帯端末５０に送信するＬｉｓｔｅｎ動作を実行する。

本実施例では、ＭＦＰ１０及び携帯端末５０，５２は、Ｐ２Ｐモードに従って動作可能である。 従って、ＭＦＰ１０及び携帯端末（即ち携帯端末５０又は５２）がＰｏｌｌ動作及びＬｉｓｔｅｎ動作を実行すると、Ｐ２Ｐモードに従った通信を実行するための通信リンク、即ち、ＬＬＣＰ接続が確立される。 より具体的に言うと、Ｐｏｌｌ動作を実行したＮＦＣ機器（以下では「Ｐｏｌｌ機器」と呼ぶ）は、Ｐ２Ｐモードに対応するＡｃｔｉｖａｔｉｏｎコマンドを、Ｌｉｓｔｅｎ動作を実行したＮＦＣ機器（以下では「Ｌｉｓｔｅｎ機器」と呼ぶ）に送信する。 次いで、Ｌｉｓｔｅｎ機器は、Ｐｏｌｌ機器からＡｃｔｉｖａｔｉｏｎコマンドを受信すると、ＯＫコマンドをＰｏｌｌ機器に送信する。 これにより、ＭＦＰ１０（即ちＰｏｌｌ機器又はＬｉｓｔｅｎ機器）と携帯端末（即ちＬｉｓｔｅｎ機器又はＰｏｌｌ機器）との間に、ＬＬＣＰ接続が確立される。 その後、ＭＦＰ１０と携帯端末との間に、それらの機器の状態に応じたＳＮＥＰ接続（即ち、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続、及び／又は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続）が確立される。

（ＭＦＰのＮＦＣ処理；図２）
次いで、図２を参照して、ＭＦＰ１０のＣＰＵ３２がプログラム３６に従って実行する処理の内容を説明する。 ＣＰＵ３２は、ＭＦＰ１０の電源がＯＮされると、図２の処理を実行する。 なお、上述したように、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する（即ち、ＭＦＰ（Ｓ）＝ＯＮ、ＭＦＰ（Ｃ）＝ＯＮ）。

Ｓ１０では、ＣＰＵ３２は、ＭＦＰ１０と携帯端末（即ち、携帯端末５０，５２のどちらか）との間にＬＬＣＰ接続が確立されることを監視する。 上述したように、Ｐ２Ｐモードに対応するＡｃｔｉｖａｔｉｏｎコマンド及びＯＫコマンドの通信が実行されると、ＭＦＰ１０と携帯端末との間にＬＬＣＰ接続が確立される。 この場合、ＣＰＵ３２は、Ｓ１０でＹＥＳと判断して、Ｓ１２に進む。

Ｓ１２では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、のそれぞれを確立することを試行する。 具体的に言うと、Ｓ１２では、ＣＰＵ３２は、まず、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を確立するための第１のネゴシエーション通信を、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末と実行することを試行する。 例えば、携帯端末の状態が、クライアント機能が有効化されている状態であれば、携帯端末が、上記の第１のネゴシエーション通信を実行し、この結果、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続が確立される。 一方において、例えば、携帯端末の状態が、クライアント機能が無効化されている状態であれば、携帯端末が、上記の第１のネゴシエーション通信を実行せず、この結果、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続が確立されない。

Ｓ１２では、ＣＰＵ３２は、さらに、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を確立するための第２のネゴシエーション通信を、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末と実行することを試行する。 例えば、携帯端末の状態が、サーバ機能が有効化されている状態であれば、携帯端末が、上記の第２のネゴシエーション通信を実行し、この結果、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立される。 一方において、例えば、携帯端末の状態が、サーバ機能が無効化されている状態であれば、携帯端末が、上記の第２のネゴシエーション通信を実行せず、この結果、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立されない。

次いで、Ｓ２０において、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、の両方のＳＮＥＰ接続が確立されたのか否かを判断する。 両方のＳＮＥＰ接続が確立された場合には、ＣＰＵ３２は、Ｓ２０でＹＥＳと判断して、Ｓ２２に進む。 一方において、一方のＳＮＥＰ接続のみが確立された場合、又は、どちらのＳＮＥＰ接続も確立されなかった場合には、ＣＰＵ３２は、Ｓ２０でＮＯと判断して、Ｓ３０に進む。

Ｓ２２では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末からＰＵＴリクエストと印刷リクエストデータとを受信する。 本実施例では、印刷リクエストデータは、印刷機能をＭＦＰ１０に実行させるための印刷指示コマンドを含む。 なお、印刷リクエストデータは、印刷対象のデータである印刷データ自体を含まない。

上述したように、ＮＦＣ方式の通信の通信速度は、ネットワーク無線通信の通信速度よりも遅い。 このために、仮に、携帯端末からＭＦＰ１０への印刷データの通信としてＮＦＣ方式の通信が利用されると、印刷データの通信に長時間を要する可能性がある。 従って、本実施例では、ＭＦＰ１０が、ネットワーク無線通信を利用して、携帯端末５０から印刷データを受信する構成を採用する。 このような構成を採用するためには、携帯端末５０は、ＭＦＰ１０とネットワーク無線通信を実行するための無線設定を知る必要がある。 従って、ＭＦＰ１０は、携帯端末から印刷指示コマンドを含む印刷リクエストデータを受信する場合に、印刷指示コマンドに対するレスポンスを示すレスポンスデータとして、上記の無線設定を携帯端末に送信する。

即ち、Ｓ２４では、ＣＰＵ３２は、印刷リクエストデータに含まれる印刷指示コマンドを読み込むと、メモリ３４から、ＭＦＰ１０が現在属している無線ネットワークで利用されている無線設定を特定する。 次いで、ＣＰＵ３２は、ＳＮＥＰの通信方式に適合するレスポンスデータを生成する。 この際に、ＣＰＵ３２は、特定済みの無線設定を含むレスポンスデータを生成する。

次いで、Ｓ２６では、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、ＰＵＴリクエストと生成済みのレスポンスデータとを携帯端末に送信する。 これにより、携帯端末は、レスポンスデータに含まれる無線設定を利用して、無線ネットワークに参加することができる。 この結果、ＭＦＰ１０及び携帯端末は、ＮＦＣ方式の通信に代えて、ネットワーク無線通信を実行して、印刷データを通信することができる。 即ち、ＭＦＰ１０は、携帯端末から印刷データを受信して、印刷機能を実行することができる。

Ｓ２６を終えると、Ｓ５０において、ＣＰＵ３２は、Ｓ１０で確立されたＬＬＣＰ接続を切断する。 例えば、ＭＦＰ１０がＰｏｌｌ機器である状態で、ＬＬＣＰ接続が確立された場合には、Ｓ５０において、ＣＰＵ３２は、ＮＦＣ Ｉ／Ｆ２２を介して、Ｄｅａｃｔｉｖａｔｉｏｎコマンドを携帯端末に送信し、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末からＯＫコマンドを受信する。 この結果、ＬＬＣＰ接続が切断される。 一方において、ＭＦＰ１０がＬｉｓｔｅｎ機器である状態で、ＬＬＣＰ接続が確立された場合には、Ｓ５０において、ＣＰＵ３２は、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末からＤｅａｃｔｉｖａｔｉｏｎコマンドを受信し、ＮＦＣ Ｉ／Ｆ２２を介して、ＯＫコマンドを携帯端末に送信する。 この結果、ＬＬＣＰ接続が切断される。 なお、ＬＬＣＰ接続が切断されると、ＳＮＥＰ接続も切断される。 Ｓ５０が終了すると、Ｓ１０に戻る。

Ｓ３０では、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立されたのか否かを判断する。 ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立された場合には、ＣＰＵ３２は、Ｓ３０でＹＥＳと判断して、Ｓ３２に進む。 一方において、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立された場合、又は、どちらのＳＮＥＰ接続も確立されなかった場合には、ＣＰＵ３２は、Ｓ３０でＮＯと判断して、Ｓ４０に進む。

Ｓ３２では、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、ＰＵＴリクエストとＵＲＬ（Uniform Resource Locatorの略）データとを携帯端末に送信する。 上述したように、ＭＦＰ１０のベンダによって提供されるインターネットサーバは、ＭＦＰ用アプリケーションを格納しており、外部装置からのリクエストに応じて、ＭＦＰ用アプリケーションのダウンロード及びインストールを外部装置に許可する。 Ｓ３２で送信されるＵＲＬデータは、ＭＦＰ用アプリケーションのＵＲＬ（即ち、上記のインターネットサーバ内のＭＦＰ用アプリケーションのファイルアドレス）を示す。 ＵＲＬデータは、ＮＦＣ規格で定められているスマートポスター（Smart Poster）のコマンドを含む。 なお、ＵＲＬデータを受信した際に携帯端末が実行する動作については、後で詳しく説明する。 Ｓ３２が終了すると、Ｓ５０に進む。

Ｓ４０では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立されたのか否かを判断する。 ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立された場合には、ＣＰＵ３２は、Ｓ４０でＹＥＳと判断して、Ｓ４２に進む。 一方において、どちらのＳＮＥＰ接続も確立されなかった場合には、ＣＰＵ３２は、Ｓ４０でＮＯと判断して、Ｓ５０に進む。

Ｓ４２では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末からＰＵＴリクエストと印刷リクエストデータとを受信する。 Ｓ４２で受信される印刷リクエストデータは、Ｓ２２で受信される印刷リクエストデータと同様である。

次いで、Ｓ４４において、ＣＰＵ３２は、Ｓ２４と同様に、無線設定を含むレスポンスデータを生成する。 続いて、Ｓ４６では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、携帯端末からＧＥＴリクエストを受信する。 Ｓ４６では、ＣＰＵ３２は、さらに、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＮＦＣ Ｉ／Ｆ２２を介して、ＧＥＴレスポンスと生成済みのレスポンスデータとを携帯端末に送信する。 Ｓ４６が終了すると、Ｓ５０に進む。

（具体的なケース）
続いて、本実施例によって実現される具体的なケースＡ１〜Ａ３を説明する。 ケースＡ１〜Ａ３は、ＭＦＰ１０が図２の各処理を実行することによって、実現される。 なお、ケースＡ１〜Ａ３では、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続に関する通信を破線で示し、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続に関する通信を一点鎖線で示す。 この点は、後述の第２実施例の図７〜図９でも同様である。

（ケースＡ１；図３）
ケースＡ１は、ＭＦＰ１０と、第１のＯＳプログラムを備える携帯端末５０と、の間で実行される通信を示す。 上述したように、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する（即ち、ＭＦＰ（Ｓ）＝ＯＮ、ＭＦＰ（Ｃ）＝ＯＮ）。 また、携帯端末５０は、携帯端末５０の電源がＯＮされている間に、サーバ機能が有効化されている状態を維持する（即ち、端末（Ｓ）＝ＯＮ）。 また、携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みである。 そして、携帯端末５０のユーザは、ＭＦＰ用アプリケーションを起動させるための操作を、携帯端末５０に加える。 これにより、携帯端末５０は、クライアント機能を有効化させる（即ち、端末（Ｃ）＝ＯＮ）。

携帯端末５０のユーザは、ＭＦＰ用アプリケーションの画面に従って、印刷機能をＭＦＰ１０に実行させるための操作を、携帯端末５０に加える。 そして、ユーザは、携帯端末５０をＭＦＰ１０に近づける。 この結果、ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続が確立される（図２のＳ１０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されている。 このために、ＭＦＰ１０と携帯端末５０との間に、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、の両方のＳＮＥＰ接続が確立される（Ｓ２０でＹＥＳ）。

携帯端末５０は、ＭＦＰ用アプリケーションに従って、印刷リクエストデータを生成する。 そして、携帯端末５０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストと生成済みの印刷リクエストデータとをＭＦＰ１０に送信する。

ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５０からＰＵＴリクエストと印刷リクエストデータとを受信する（Ｓ２２）。 次いで、ＭＦＰ１０は、レスポンスデータを生成する（Ｓ２４）。 続いて、ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとレスポンスデータとを携帯端末５０に送信する（Ｓ２６）。

携帯端末５０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＭＦＰ１０からＰＵＴリクエストとレスポンスデータとを受信する。 これにより、携帯端末５０は、ＭＦＰ用アプリケーションに従って、レスポンスデータに含まれる無線設定を利用して、無線ネットワークに参加する。 携帯端末５０は、ネットワーク無線通信を実行して、印刷データをＭＦＰ１０に送信する。

ＭＦＰ１０は、ネットワーク無線通信を実行して、携帯端末５０から印刷データを受信する。 印刷データは、印刷実行部１８に供給される。 これにより、ＭＦＰ１０（即ち印刷実行部１８）は、印刷データによって表される画像を、印刷媒体に印刷する。

上述したように、ケースＡ１では、両方のＳＮＥＰ接続が確立される場合に、ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５０から印刷リクエストデータを受信し、その後、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、レスポンスデータを携帯端末５０に送信する。 従って、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

なお、本実施例では、携帯端末５０の第１のＯＳプログラムは、ＰＵＴコマンドを利用可能であるが、ＧＥＴコマンドを利用不可能である。 ケースＡ１では、印刷リクエストデータ及びレスポンスデータのどちらが通信されるべき状況でも、ＰＵＴコマンドが利用される。 従って、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

（ケースＡ２；図４）
ケースＡ２は、ＭＦＰ１０と、第１のＯＳプログラムを備える携帯端末５０と、の間で実行される通信を示す。 ＭＦＰ１０の状態は、図３のケースＡ１の状態と同様である（即ち、ＭＦＰ（Ｓ）＝ＯＮ、ＭＦＰ（Ｃ）＝ＯＮ）。 携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みでない。 もしくは、携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みであるが、ＭＦＰ用アプリケーションを起動していない。 従って、携帯端末５０では、サーバ機能が有効化されているが、クライアント機能が無効化されている（即ち、端末（Ｓ）＝ＯＮ、端末（Ｃ）＝ＯＦＦ）。

ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続が確立される（図２のＳ１０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５０において、サーバ機能のみが有効化されている。 このために、ＭＦＰ１０と携帯端末５０との間に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される（Ｓ２０でＮＯ、Ｓ３０でＹＥＳ）。

ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとＵＲＬデータとを携帯端末５０に送信する（Ｓ３２）。 次いで、ＬＬＣＰ接続が切断される（Ｓ５０）。

携帯端末５０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＭＦＰ１０からＰＵＴリクエストとＵＲＬデータとを受信する。 これにより、携帯端末５０は、第１のＯＳプログラムに従って、ＵＲＬデータに含まれるスマートポスターのコマンドを読み込む。

携帯端末５０がＭＦＰ用アプリケーションをインストール済みでないケースでは、以下の第１の例及び第２の例が実現される。 第１の例では、携帯端末５０は、スマートポスターのコマンドを読み込むと、ＵＲＬデータに含まれるＵＲＬ（即ちＭＦＰ用アプリケーションを格納しているインターネットサーバ）に自動的にアクセスして、インターネットサーバからＭＦＰ用アプリケーションをダウンロードする。 これにより、携帯端末５０は、ＭＦＰ用アプリケーションをインストールすることができる。 第２の例では、携帯端末５０は、スマートポスターのコマンドを読み込むと、所定の画面を表示させて、ＵＲＬデータに含まれるＵＲＬにアクセスするのか否かを、ユーザに問い合わせる。 そして、ユーザがアクセスを許可すると、携帯端末５０は、インターネットサーバからＭＦＰ用アプリケーションをダウンロードする。 これにより、携帯端末５０は、ＭＦＰ用アプリケーションをインストールすることができる。 携帯端末５０は、ＭＦＰ用アプリケーションをインストールすると、ＭＦＰ用アプリケーションを起動させる。 この結果、携帯端末５０は、クライアント機能を有効化させる。 即ち、携帯端末５０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。

携帯端末５０がＭＦＰ用アプリケーションをインストール済みであるケースでは、携帯端末５０は、スマートポスターのコマンドを読み込むと、ＵＲＬデータを破棄して、ＭＦＰ用アプリケーションをダウンロードしない。 ただし、携帯端末５０は、スマートポスターのコマンドを読み込むと、ＭＦＰ用アプリケーションを起動させる。 この結果、携帯端末５０は、クライアント機能を有効化させる。 即ち、携帯端末５０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。

携帯端末５０のユーザは、図３のケースＡ１と同様に、印刷機能をＭＦＰ１０に実行させるための操作を加えた後に、携帯端末５０をＭＦＰ１０に近づける。 この結果、ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続が再び確立される（図２のＳ１０でＹＥＳ）。 携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されているために、両方のＳＮＥＰ接続が確立される（Ｓ２０でＹＥＳ）。 この後の動作は、図３のケースＡ１と同様である。

上述したように、ケースＡ２では、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される場合に、ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＵＲＬデータを携帯端末５０に送信する。 このために、携帯端末５０がＭＦＰ用アプリケーションをインストール済みでないケースでは、携帯端末５０は、ＵＲＬデータを用いて、ＭＦＰ用アプリケーションをインストールして、ＭＦＰ用アプリケーションを起動させる。 また、携帯端末５０がＭＦＰ用アプリケーションをインストール済みであるケースでは、携帯端末５０は、ＭＦＰ用アプリケーションをダウンロードしないが、ＭＦＰ用アプリケーションを起動させる。 携帯端末５０は、ＭＦＰ用アプリケーションを起動すると、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化する。 従って、ＭＦＰ１０は、ＵＲＬデータを携帯端末５０に送信することによって、携帯端末５０のクライアント機能を適切に有効化させることができる。 このために、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

また、ＵＲＬデータの通信には、ＰＵＴコマンドが利用される。 従って、ＭＦＰ１０は、携帯端末５０がＧＥＴコマンドを利用不可能である場合に、ＵＲＬデータを携帯端末５０と適切に通信することができる。 この結果、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

（ケースＡ３；図５）
ケースＡ３は、ＭＦＰ１０と、第２のＯＳプログラムを備える携帯端末５２と、の間で実行される通信を示す。 ＭＦＰ１０の状態は、図３のケースＡ１の状態と同様である（即ち、ＭＦＰ（Ｓ）＝ＯＮ、ＭＦＰ（Ｃ）＝ＯＮ）。 また、携帯端末５２は、携帯端末５２の電源がＯＮされている間に、サーバ機能が無効化されている状態を維持する（即ち、端末（Ｓ）＝ＯＦＦ）。 また、携帯端末５２は、ＭＦＰ用アプリケーションをインストール済みである。 そして、携帯端末５２のユーザは、ＭＦＰ用アプリケーションを起動させるための操作を、携帯端末５２に加える。 これにより、携帯端末５２は、クライアント機能を有効化させる（即ち、端末（Ｃ）＝ＯＮ）。

携帯端末５２のユーザは、ＭＦＰ用アプリケーションの画面に従って、印刷機能をＭＦＰ１０に実行させるための操作を、携帯端末５２に加える。 そして、ユーザは、携帯端末５２をＭＦＰ１０に近づける。 この結果、ＭＦＰ１０と携帯端末５２との間に、ＬＬＣＰ接続が確立される（図２のＳ１０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５２において、クライアント機能のみが有効化されている。 このために、ＭＦＰ１０と携帯端末５２との間に、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立される（Ｓ２０でＮＯ、Ｓ３０でＮＯ、Ｓ４０でＹＥＳ）。

携帯端末５２は、ＭＦＰ用アプリケーションに従って、印刷リクエストデータを生成する。 そして、携帯端末５２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストと生成済みの印刷リクエストデータとをＭＦＰ１０に送信する。

ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５２からＰＵＴリクエストと印刷リクエストデータとを受信する（Ｓ４２）。 次いで、ＭＦＰ１０は、レスポンスデータを生成する（Ｓ４４）。

携帯端末５２は、印刷リクエストデータをＭＦＰ１０に送信した後に、さらに、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＧＥＴリクエストをＭＦＰ１０に送信する。

ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５２からＧＥＴリクエストを受信する（Ｓ４６）。 次いで、ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＧＥＴレスポンスとレスポンスデータとを携帯端末５２に送信する（Ｓ４６）。 この後の動作は、図３のケースＡ１と同様である。

上述したように、ケースＡ３では、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立される場合に、ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５２から印刷リクエストデータを受信し、その後、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、レスポンスデータを携帯端末５２に送信する。 従って、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５２と適切に通信することができる。

なお、本実施例では、携帯端末５２の第２のＯＳプログラムは、ＰＵＴコマンド及びＧＥＴコマンドの両方を利用可能である。 従って、ＭＦＰ１０は、ＰＵＴコマンド及びＧＥＴコマンドを利用して、印刷リクエストデータ及びレスポンスデータを携帯端末５２と適切に通信することができる。

（第１実施例の効果）
本実施例によると、ＭＦＰ１０は、ＭＦＰ１０及び携帯端末５０，５２の現在の状態（即ち、サーバ機能及びクライアント機能のそれぞれの有効化に関する状態）に応じて、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、のうちの少なくとも１つのＳＮＥＰ接続を確立する。 そして、ＭＦＰ１０は、どのＳＮＥＰ接続が確立されるのかに応じて、図３〜図５のケースＡ１〜Ａ３に示されるように、異なる通信ステップを実行する。 このために、ＭＦＰ１０は、どのＳＮＥＰ接続が確立されるのかに応じた適切な通信ステップを実行することができる。 本実施例によると、ＭＦＰ１０は、印刷リクエストデータ、レスポンスデータ、ＵＲＬデータ等を、を携帯端末５０，５２と適切に通信することができる。

例えば、第１のＯＳプログラムを備える携帯端末５０が、ＭＦＰ用アプリケーションをインストール済みであるのか否かに応じて、ＭＦＰ１０は、ケースＡ１及びＡ２に示されるように、異なる通信ステップを実行することができる。 また、例えば、第１のＯＳプログラムを備える携帯端末５０が、ＭＦＰ用アプリケーションをインストール済みであるが、ＭＦＰアプリケーションを起動しているのか否かに応じて、ＭＦＰ１０は、ケースＡ１及びＡ２に示されるように、異なる通信ステップを実行することができる。 また、上述したように、第１のＯＳプログラムを備える携帯端末５０は、サーバ機能が有効化されている状態を維持するが、第２のＯＳプログラムを備える携帯端末５２は、サーバ機能が無効化されている状態を維持する。 このように、異なるＯＳプログラムを備える様々な携帯端末５０，５２が存在し得る環境において、ＭＦＰ１０は、ケースＡ１（又はＡ２）及びＡ３に示されるように、携帯端末５０，５２が備えるＯＳプログラムの種類に応じて、異なる通信ステップを実行することができる。

また、図３のケースＡ１に示されるように、ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続と、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続と、の両方のＳＮＥＰ接続が確立される場合に、一方のＳＮＥＰ接続及び他方のＳＮＥＰ接続のそれぞれを順次利用して、印刷リクエストデータ及びレスポンスデータを携帯端末５０と順次通信する。 しかも、ＭＦＰ１０は、同じＰＵＴコマンドに従って、印刷リクエストデータ及びレスポンスデータを携帯端末５０と通信する。 従って、携帯端末５０が、ＰＵＴコマンドを利用可能であるが、ＧＥＴコマンドを利用不可能である場合に、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

（対応関係）
ＭＦＰ１０、携帯端末５０，５２が、それぞれ、「通信装置」、「外部装置」の一例である。 ＳＮＥＰが、「特定のプロトコル」の一例である。 ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が、それぞれ、「第１種の接続」、「第２種の接続」の一例である。 図２のＳ１２が、「確立ステップ」の一例である。 Ｓ２２及びＳ２６、Ｓ３２、Ｓ４２及びＳ４６が、それぞれ、「第１の通信ステップ」、「第２の通信ステップ」、「第３の通信ステップ」の一例である。 Ｓ２４，Ｓ４４が、「生成ステップ」の一例である。 Ｓ２２で受信される印刷リクエストデータ、Ｓ２６で送信されるレスポンスデータ、Ｓ３２で送信されるＵＲＬデータ、Ｓ４２で受信される印刷リクエストデータ、Ｓ４６で送信されるレスポンスデータが、それぞれ、「第１の対象データ」、「第２の対象データ」、「第３の対象データ」、「第４の対象データ」、「第５の対象データ」の一例である。 Ｓ３２で送信されるＵＲＬデータに含まれるＭＦＰ用アプリケーションのＵＲＬが、「特定のデータ」及び「識別情報」の一例である。 印刷機能が、「特定の機能」の一例である。

（第２実施例）
第１実施例では、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。 これに対し、本実施例では、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、クライアント機能が有効化されている状態を維持するが、後述の図６のＳ１１６が実行されない限り、サーバ機能が無効化されている状態を維持する。 本実施例では、ＭＦＰ１０のＣＰＵ３２は、図２のＮＦＣ処理に代えて、図６のＮＦＣ処理を実行する。

（ＭＦＰのＮＦＣ処理；図６）
Ｓ１００は、図２のＳ１０と同様である。 Ｓ１０２では、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を確立することを試行する。 なお、Ｓ１０２では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を確立することを試行しない。 ＭＦＰ１０において、サーバ機能が無効化されているからである。 Ｓ１１０では、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立されたのか否かを判断する。 ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立された場合には、ＣＰＵ３２は、Ｓ１１０でＹＥＳと判断して、Ｓ１１２に進む。 一方において、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立されなかった場合には、ＣＰＵ３２は、Ｓ１１０でＮＯと判断し、Ｓ１１２をスキップして、Ｓ１１４に進む。

Ｓ１１２では、ＣＰＵ３２は、図２のＳ３２と同様に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとＵＲＬデータとを携帯端末に送信する。 Ｓ１１２が終了すると、Ｓ１１４に進む。

Ｓ１１４では、ＣＰＵ３２は、図２のＳ５０と同様に、ＬＬＣＰ接続を切断する。 次いで、Ｓ１１６において、ＣＰＵ３２は、サーバ機能が無効化されている状態から、サーバ機能が有効化されている状態に変化させる。 これにより、ＭＦＰ１０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。 Ｓ１１６が終了すると、Ｓ１２０に進む。

Ｓ１２０，１２２は、図２のＳ１０，Ｓ１２と同様である。 Ｓ１３０において、ＣＰＵ３２は、両方のＳＮＥＰ接続が確立されたのか否かを判断する。 両方のＳＮＥＰ接続が確立された場合には、ＣＰＵ３２は、Ｓ１３０でＹＥＳと判断して、Ｓ１３２に進む。 Ｓ１３２〜Ｓ１３６は、図２のＳ２２〜Ｓ２６と同様である。 Ｓ１３６が終了すると、Ｓ１５０に進む。

一方のＳＮＥＰ接続のみが確立された場合、又は、どちらのＳＮＥＰ接続も確立されなかった場合には、ＣＰＵ３２は、Ｓ１３０でＮＯと判断して、Ｓ１４０に進む。 Ｓ１４０では、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立されたのか否かを判断する。 ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立された場合には、ＣＰＵ３２は、Ｓ１４０でＹＥＳと判断して、Ｓ１４２に進む。 Ｓ１４２〜Ｓ１４６は、図２のＳ４２〜Ｓ４６と同様である。 Ｓ１４６が終了すると、Ｓ１５０に進む。

ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立された場合、又は、どちらのＳＮＥＰ接続も確立されなかった場合には、ＣＰＵ３２は、Ｓ１４０でＮＯと判断して、Ｓ１５０に進む。

Ｓ１５０では、ＣＰＵ３２は、図２のＳ５０と同様に、ＬＬＣＰ接続を切断する。 次いで、Ｓ１５２において、ＣＰＵ３２は、サーバ機能が有効化されている状態から、サーバ機能が無効化されている状態に変化させる。 これにより、ＭＦＰ１０は、クライアント機能のみが有効化されている状態になる。 Ｓ１５２が終了すると、Ｓ１００に戻る。

（具体的なケース）
続いて、本実施例によって実現される具体的なケースＢ１〜Ｂ３を説明する。 ケースＢ１〜Ｂ３は、ＭＦＰ１０が図６の各処理を実行することによって、実現される。

（ケースＢ１；図７）
ケースＢ１は、ＭＦＰ１０と、第１のＯＳプログラムを備える携帯端末５０と、の間で実行される通信を示す。 上述したように、ＭＦＰ１０は、ＭＦＰ１０の電源がＯＮされている間に、クライアント機能が有効化されている状態を維持するが、図６のＳ１１６が実行されない限り、サーバ機能が無効化されている状態を維持する（即ち、ＭＦＰ（Ｓ）＝ＯＦＦ、ＭＦＰ（Ｃ）＝ＯＮ）。 また、携帯端末５０では、ＭＦＰ用アプリケーションが起動されている。 従って、携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されている（即ち、端末（Ｓ）＝ＯＮ、端末（Ｃ）＝ＯＮ）。

ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続が確立される（図６のＳ１００でＹＥＳ）。 ＭＦＰ１０において、クライアント機能のみが有効化されており、携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されている。 このために、ＭＦＰ１０と携帯端末５０との間に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される（Ｓ１０２、Ｓ１１０でＹＥＳ）。

ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとＵＲＬデータとを携帯端末５０に送信する（Ｓ１１２）。

携帯端末５０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＭＦＰ１０からＰＵＴリクエストとＵＲＬデータとを受信する。 これにより、携帯端末５０は、第１のＯＳプログラムに従って、ＵＲＬデータに含まれるスマートポスターのコマンドを読み込む。 ただし、携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みである。 従って、携帯端末５０は、ＵＲＬデータを破棄して、ＭＦＰ用アプリケーションをダウンロードしない。

ＭＦＰ１０は、ＭＦＰ１０と携帯端末５０との間のＬＬＣＰ接続を一旦切断する（Ｓ１１４）。 その後、ＭＦＰ１０は、サーバ機能を有効化させる（Ｓ１１６）。 従って、ＭＦＰ１０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。 そして、ＭＦＰ１０は、ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続を再び確立させる（図６のＳ１２０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されている。 このために、ＭＦＰ１０と携帯端末５０との間に、両方のＳＮＥＰ接続が確立される（Ｓ１２２、Ｓ１３０でＹＥＳ）。

携帯端末５０は、ＭＦＰ用アプリケーションに従って、印刷リクエストデータを生成する。 そして、携帯端末５０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストと生成済みの印刷リクエストデータとをＭＦＰ１０に送信する。

ＭＦＰ１０は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５０からＰＵＴリクエストと印刷リクエストデータとを受信する（Ｓ１３２）。 次いで、ＭＦＰ１０は、レスポンスデータを生成する（Ｓ１３４）。 続いて、ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとレスポンスデータとを携帯端末５０に送信する（Ｓ１３６）。 この後の動作は、図３のケースＡ１と同様である。 ケースＢ１によると、図３のケースＡ１と同様の効果が得られる。

（ケースＢ２；図８）
ケースＡ２は、ＭＦＰ１０と、第１のＯＳプログラムを備える携帯端末５０と、の間で実行される通信を示す。 ＭＦＰ１０の状態は、図７のケースＢ１の状態と同様である（即ち、ＭＦＰ（Ｓ）＝ＯＦＦ、ＭＦＰ（Ｃ）＝ＯＮ）。 携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みでない。 もしくは、携帯端末５０は、ＭＦＰ用アプリケーションをインストール済みであるが、ＭＦＰ用アプリケーションを起動していない。 従って、携帯端末５０では、サーバ機能が有効化されているが、クライアント機能が無効化されている（即ち、端末（Ｓ）＝ＯＮ、端末（Ｃ）＝ＯＦＦ）。

ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続が確立される（図６のＳ１００でＹＥＳ）。 また、ＭＦＰ１０において、クライアント機能のみが有効化されており、携帯端末５０において、サーバ機能のみが有効化されている。 このために、ＭＦＰ１０と携帯端末５０との間に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される（Ｓ１０２、Ｓ１１０でＹＥＳ）。

ＭＦＰ１０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴリクエストとＵＲＬデータとを携帯端末５０に送信する（Ｓ１１２）。

携帯端末５０は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＭＦＰ１０からＰＵＴリクエストとＵＲＬデータとを受信する。 図４のケースＡ２と同様に、携帯端末５０がＭＦＰ用アプリケーションをインストール済みでないケースでは、携帯端末５０は、ＭＦＰ用アプリケーションをインストールして、ＭＦＰ用アプリケーションを起動させる。 また、携帯端末５０がＭＦＰ用アプリケーションをインストール済みであるケースでは、携帯端末５０は、ＭＦＰ用アプリケーションをダウンロードしないが、ＭＦＰ用アプリケーションを起動させる。 この結果、携帯端末５０は、クライアント機能を有効化させる。 即ち、携帯端末５０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。

ＭＦＰ１０は、ＭＦＰ１０と携帯端末５０との間のＬＬＣＰ接続を一旦切断する（Ｓ１１４）。 その後、ＭＦＰ１０は、クライアント機能を有効化させる（Ｓ１１６）。 従って、ＭＦＰ１０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。 そして、ＭＦＰ１０は、ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続を再び確立させる（図６のＳ１２０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５０において、サーバ機能及びクライアント機能の両方が有効化されている。 このために、両方のＳＮＥＰ接続が確立される（Ｓ１２２、Ｓ１３０でＹＥＳ）。 この後の動作は、図７のケースＢ１と同様である。 ケースＢ２によると、図４のケースＡ２と同様の効果が得られる。

（ケースＢ３；図９）
ケースＡ３は、ＭＦＰ１０と、第２のＯＳプログラムを備える携帯端末５２と、の間で実行される通信を示す。 ＭＦＰ１０の状態は、図７のケースＢ１の状態と同様である（即ち、ＭＦＰ（Ｓ）＝ＯＦＦ、ＭＦＰ（Ｃ）＝ＯＮ）。 また、携帯端末５２は、携帯端末５２の電源がＯＮされている間に、サーバ機能が無効化されている状態を維持する。 また、携帯端末５２では、ＭＦＰ用アプリケーションが起動されている。 従って、携帯端末５２において、クライアント機能のみが有効化されている（即ち、端末（Ｓ）＝ＯＦＦ、端末（Ｃ）＝ＯＮ）。

ＭＦＰ１０と携帯端末５２との間に、ＬＬＣＰ接続が確立される（図６のＳ１００でＹＥＳ）。 ＭＦＰ１０において、クライアント機能のみが有効化されており、携帯端末５２において、クライアント機能のみが有効化されている。 このために、ＭＦＰ１０と携帯端末５２との間に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続が確立されない（Ｓ１０２、Ｓ１１０でＮＯ）。 従って、ＭＦＰ１０は、ＵＲＬデータを携帯端末５２に送信しない（Ｓ１１２をスキップ）。

ＭＦＰ１０は、ＭＦＰ１０と携帯端末５２との間のＬＬＣＰ接続を一旦切断する（Ｓ１１４）。 その後、ＭＦＰ１０は、クライアント機能を有効化させる（Ｓ１１６）。 従って、ＭＦＰ１０は、サーバ機能及びクライアント機能の両方が有効化されている状態になる。 そして、ＭＦＰ１０は、ＭＦＰ１０と携帯端末５０との間に、ＬＬＣＰ接続を再び確立させる（図６のＳ１２０でＹＥＳ）。 ＭＦＰ１０において、サーバ機能及びクライアント機能の両方が有効化されており、携帯端末５２において、クライアント機能のみが有効化されている。 このために、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続のみが確立される（Ｓ１２２、Ｓ１４０でＹＥＳ）。 この後の動作は、図５のケースＡ３と同様である。 ケースＢ３によると、図５のケースＡ３と同様の効果が得られる。

（第２実施例の効果）
本実施例によっても、第１実施例と同様の効果が得られる。 即ち、ＭＦＰ１０は、どのＳＮＥＰ接続が確立されるのかに応じて、図７〜図９のケースＢ１〜Ｂ３に示されるように、異なる通信ステップを実行する。 このために、ＭＦＰ１０は、どのＳＮＥＰ接続が確立されるのかに応じた適切な通信ステップを実行することができる。 本実施例によると、ＭＦＰ１０は、印刷リクエストデータ、レスポンスデータ、ＵＲＬデータ等を、を携帯端末５０，５２と適切に通信することができる。

また、図７のケースＢ１に示されるように、ＭＦＰ１０は、両方のＳＮＥＰ接続が確立される場合に、一方のＳＮＥＰ接続及び他方のＳＮＥＰ接続のそれぞれを順次利用して、同じＰＵＴコマンドに従って、印刷リクエストデータ及びレスポンスデータを携帯端末５０と通信する。 従って、携帯端末５０が、ＰＵＴコマンドを利用可能であるが、ＧＥＴコマンドを利用不可能である場合に、ＭＦＰ１０は、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

（第１及び第２実施例の相違について）
上述したように、第１実施例では、ＭＦＰ１０は、サーバ機能及びクライアント機能の両方が有効化されている状態を維持する。 これに対し、第２実施例では、ＭＦＰ１０は、クライアント機能が有効化されている状態を維持するが、図６のＳ１１６が実行されない限り、サーバ機能が無効化されている状態を維持する。

第２実施例では、図７のケースＢ１に示されるように、携帯端末５０が、ＭＦＰ用アプリケーションをインストール済みであり、かつ、ＭＦＰ用アプリケーションを起動している状況において、１回目のＬＬＣＰ接続が確立された際に、ＵＲＬデータが送信される。 その後、２回目のＬＬＣＰ接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。 これに対し、第１実施例では、図３のケースＡ１に示されるように、携帯端末５０が、ＭＦＰ用アプリケーションをインストール済みであり、かつ、ＭＦＰ用アプリケーションを起動している状況において、１回目のＬＬＣＰ接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。 従って、第１実施例によると、ＭＦＰ１０は、ＬＬＣＰ接続を２回に亘って確立せずに済み、１回目のＬＬＣＰ接続が確立される際に、印刷リクエストデータ及びレスポンスデータを携帯端末５０と迅速に通信することができる。

同様に、第２実施例では、図９のケースＢ３に示されるように、２回目のＬＬＣＰ接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。 これに対し、第１実施例では、図５のケースＡ３に示されるように、１回目のＬＬＣＰ接続が確立された際に、印刷リクエストデータ及びレスポンスデータが通信される。 従って、第１実施例によると、ＭＦＰ１０は、ＬＬＣＰ接続を２回に亘って確立せずに済み、１回目のＬＬＣＰ接続が確立される際に、印刷リクエストデータ及びレスポンスデータを携帯端末５２と迅速に通信することができる。

なお、第１実施例では、携帯端末５０は、ＭＦＰ用アプリケーションを起動していない状況では、クライアント機能が無効化されている状態を維持することが前提となっている。 しかしながら、例えば、ＭＦＰ用アプリケーションが起動されていなくても、別のアプリケーションが起動されると、携帯端末５０がクライアント機能を有効化する可能性がある。 従って、例えば、携帯端末５０が、ＭＦＰ用アプリケーションを起動していないが、サーバ機能及びクライアント機能の両方を有効化している状況（以下では「特定の状況」と呼ぶ）において、第１実施例の手法を利用すると、両方のＳＮＥＰ接続が確立される（図２のＳ２０でＹＥＳ）。 ただし、携帯端末５０は、ＭＦＰ用アプリケーションに従って動作しないために、印刷リクエストデータをＭＦＰ１０に送信しない。 即ち、上記の特定の状況では、ＭＦＰ１０と携帯端末５０との間で、印刷リクエストデータ及びレスポンスデータが通信されないおそれがある。

これに対し、第２実施例では、上記の特定の状況において、１回目のＬＬＣＰ接続が確立される際に、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続のみが確立される（図６のＳ１１０でＹＥＳ）。 従って、ＭＦＰ１０から携帯端末５０にＵＲＬデータが送信される（Ｓ１１２）。 この結果、携帯端末５０は、ＭＦＰ用アプリケーションを起動する。 その後、ＭＦＰ１０と携帯端末５０との間に、２回目のＬＬＣＰ接続が確立された際に、両方のＳＮＥＰ接続が確立され（Ｓ１３０でＹＥＳ）、印刷リクエストデータ及びレスポンスデータが通信される（Ｓ１３２，Ｓ１３６）。 従って、第２実施例によると、ＭＦＰ１０は、上記の特定の状況において、印刷リクエストデータ及びレスポンスデータを携帯端末５０と適切に通信することができる。

（対応関係）
図６のＳ１０２，Ｓ１２２が、「確立ステップ」の一例である。 特に、Ｓ１０２が、「第１の状況」で実行される「確立ステップ」の一例であり、Ｓ１２２が、「第２の状況」で実行される「確立ステップ」の一例である。 Ｓ１１６が、「変化ステップ」の一例である。 Ｓ１３２及びＳ１３６、Ｓ１１２、Ｓ１４２及びＳ１４６が、それぞれ、「第１の通信ステップ」、「第２の通信ステップ」、「第３の通信ステップ」の一例である。 Ｓ１３４，Ｓ１４４が、「生成ステップ」の一例である。 Ｓ１３２で受信される印刷リクエストデータ、Ｓ１３６で送信されるレスポンスデータ、Ｓ１１２で送信されるＵＲＬデータ、Ｓ１４２で受信される印刷リクエストデータ、Ｓ１４６で送信されるレスポンスデータが、それぞれ、「第１の対象データ」、「第２の対象データ」、「第３の対象データ」、「第４の対象データ」、「第５の対象データ」の一例である。

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

（変形例１）図２のＳ２２及びＳ２６において、ＣＰＵ３２は、ＰＵＴコマンドを利用する代わりに、ＧＥＴコマンドを利用して、印刷リクエストデータ及びレスポンスデータを通信してもよい。 即ち、図３のケースＡ１の変形例に示されるように、図２のＳ２２において、ＣＰＵ３２は、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＧＥＴリクエストを携帯端末５０に送信し、ＧＥＴレスポンスと印刷リクエストデータを携帯端末５０から受信してもよい。 また、図２のＳ２６において、ＣＰＵ３２は、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、携帯端末５０からＧＥＴリクエストを受信し、ＧＥＴレスポンスとレスポンスデータとを携帯端末５０に送信してもよい。 同様に、図６のＳ１３２及びＳ１３６において、ＣＰＵ３２は、ＧＥＴコマンドを利用して、印刷リクエストデータ及びレスポンスデータを通信してもよい。 即ち、「第１の通信ステップ」では、ＰＵＴコマンドの代わりに、ＧＥＴコマンドが利用されてもよい。

（変形例２）例えば、両方のＳＮＥＰ接続が確立されることを考慮しない場合（即ち、図３のケースＡ１を考慮しない場合）には、ＣＰＵ３２は、図２のＳ２０〜Ｓ２６を実行しなくてもよい。 即ち、「第１の通信ステップ」が実行されず、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、「第２の通信ステップ」又は「第３の通信ステップ」が実行されてもよい。 また、ＭＦＰ１０が通信すべき対象の携帯端末として、ＭＦＰアプリケーションを起動していない携帯端末を考慮しない場合（即ち、図４のケースＡ２を考慮しない場合）には、ＣＰＵ３２は、図２のＳ３０〜Ｓ３２を実行しなくてもよい。 即ち、「第２の通信ステップ」が実行されず、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、「第１の通信ステップ」又は「第３の通信ステップ」が実行されてもよい。 また、例えば、ＭＦＰ１０が通信すべき対象の携帯端末として、第２のＯＳプログラムを備える携帯端末５２を考慮しない場合には、ＣＰＵ３２は、図２のＳ４０〜Ｓ４６を実行しなくてもよい。 即ち、「第３の通信ステップ」が実行されず、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、「第１の通信ステップ」又は「第２の通信ステップ」が実行されてもよい。 第２実施例においても、同様の変形例を採用してもよい。 一般的に言うと、プロセッサは、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行すればよい。

（変形例３）上記の各実施例では、印刷リクエストデータが、「第１の対象データ」及び「第４の対象データ」の一例であり、レスポンスデータが、「第２の対象データ」及び「第５の対象データ」の一例である。 これに代えて、例えば、以下の各変形例が採用されてもよい。

（変形例３−１）「第１の対象データ」及び／又は「第４の対象データ」として、スキャン機能をＭＦＰ１０に実行させるためのスキャン指示コマンドを含むスキャンリクエストデータが採用されてもよい。 この場合、「第２の対象データ」及び／又は「第５の対象データ」として、上記の実施例と同様に、無線設定を含むレスポンスデータが採用されてもよい。

（変形例３−２）携帯端末が、ＭＦＰ１０が利用すべき設定情報を、ＭＦＰ１０に送信すべき状況を想定する。 上記の設定情報として、例えば、ＭＦＰ１０が印刷機能を実行するための印刷設定情報（例えば、印刷解像度、用紙サイズ等）、ＭＦＰ１０がスキャン機能を実行するためのスキャン設定情報（例えば、スキャン解像度等）、ＭＦＰ１０が通信機能を実行するための通信設定情報（例えば、ＩＰアドレス、サブネットマスク、ゲートウェイアドレス等）を挙げることができる。 これにより、ＭＦＰ１０は、携帯端末から受信される設定情報を利用して、様々な機能を実行することができる。 ＭＦＰ１０は、携帯端末から設定情報を受信する場合に、設定情報を受信したことを示す応答コマンドを携帯端末に送信する。 「第１の対象データ」及び／又は「第４の対象データ」として、上記の設定情報が採用されてもよい。 また、「第２の対象データ」及び／又は「第５の対象データ」として、上記の応答コマンドが採用されてもよい。

（変形例３−３）携帯端末が、携帯端末内のアドレス帳に含まれるアドレス情報を、ＭＦＰ１０に送信すべき状況を想定する。 ＭＦＰ１０は、携帯端末から受信されるアドレス情報を利用して、通信機能を実行することができる。 ＭＦＰ１０は、携帯端末からアドレス情報を受信する場合に、アドレス情報を受信したことを示す応答コマンドを携帯端末に送信する。 「第１の対象データ」及び／又は「第４の対象データ」として、上記のアドレス情報が採用されてもよい。 また、「第２の対象データ」及び／又は「第５の対象データ」として、上記の応答コマンドが採用されてもよい。

（変形例３−４）上記の実施例では、ＭＦＰ１０が、ネットワーク無線通信を利用して、携帯端末から印刷データを受信する構成を採用している。 これに代えて、例えば、ＭＦＰ１０は、ＮＦＣ通信を利用して、携帯端末から印刷データを受信してもよい。 この場合、ＭＦＰ１０は、印刷データを受信したことを示す応答コマンドを携帯端末に送信してもよい。 「第１の対象データ」及び／又は「第４の対象データ」として、上記の印刷データが採用されてもよい。 また、「第２の対象データ」及び／又は「第５の対象データ」として、上記の応答コマンドが採用されてもよい。

（変形例４）上記の各実施例では、スマートポスターのコマンドを含むＵＲＬデータが、「第３の対象データ」の一例である。 これに代えて、例えば、携帯端末５０の第１のＯＳプログラムがＡｎｄｒｏｉｄ（登録商標）である場合（例えば、４．０又はそれ以降のバージョンを有するプログラムである場合）には、「第３の対象データ」は、Ａｎｄｒｏｉｄ（登録商標）のアプリケーションレコードを含むデータであってもよい。 即ち、図２のＳ３２又は図６のＳ１１２において、ＣＰＵ３２は、ＵＲＬデータの代わりに、アプリケーションレコードを送信してもよい。 当該アプリケーションレコードは、ＭＦＰ用アプリケーションのＵＲＬを含まず、ＭＦＰ用アプリケーションのパッケージ名（即ちテキスト情報）を含む。 携帯端末５０は、アプリケーションレコードに含まれるパッケージ名を用いて、ＭＦＰ用アプリケーションをインストールしたり起動したりすることができる。 本変形例では、アプリケーションレコード、パッケージ名が、それぞれ、「特定のデータ」、「識別情報」の一例である。

（変形例５）携帯端末５０，５２において、ＭＦＰ用アプリケーションがインストール済みであることを前提とするのであれば、「第３の対象データ」として、ＵＲＬデータの代わりに、ＭＦＰ用アプリケーションの起動コマンド（ただしＵＲＬを含まない）が採用されてもよい。 即ち、一般的に言うと、「第３の対象データ」は、外部装置の状態を、クライアント機能が無効化されている状態から、クライアント機能が有効化されている状態に変化させるための特定のデータを含んでいればよい。

（変形例６）ＣＰＵ３２は、図２のＳ２０でＹＥＳの場合に、まず、ＭＦＰ（Ｃ）−端末（Ｓ）のＳＮＥＰ接続を利用して、ＰＵＴコマンドに従って、ＭＦＰ１０内のデータ（例えばスキャンデータ）を携帯端末５０に送信し、その後、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＰＵＴコマンドに従って、上記のデータを受信したことを示す応答コマンドを携帯端末５０から受信してもよい。 本変形例も、「通信ステップ」の一例である。 また、ＣＰＵ３２は、図２のＳ４０でＹＥＳの場合に、まず、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＧＥＴコマンドに従って、ＭＦＰ１０内のデータ（例えばスキャンデータ）を携帯端末５０に送信し、その後、ＭＦＰ（Ｓ）−端末（Ｃ）のＳＮＥＰ接続を利用して、ＰＵＴコマンドに従って、上記のデータを受信したことを示す応答コマンドを携帯端末５０から受信してもよい。 本変形例も、「通信ステップ」の一例である。 即ち、一般的に言うと、プロセッサは、第１種及び第２種の接続のうちのどの種の接続が確立されるのかに応じて、異なる通信ステップを実行すればよい。

（変形例７）「通信装置」は、印刷機能及びスキャン機能を実行可能な多機能機（即ちＭＦＰ１０）に限られず、印刷機能及びスキャン機能のうちの印刷機能のみを実行可能なプリンタであってもよいし、印刷機能及びスキャン機能のうちのスキャン機能のみを実行可能なスキャナであってもよい。 また、「通信装置」は、印刷機能及びスキャン機能とは異なる機能（例えば、画像の表示機能、データの演算機能）を実行する装置（例えば、ＰＣ、サーバ、携帯端末（携帯電話、スマートフォン、ＰＤＡ等））であってもよい。 即ち、「通信装置」は、ＮＦＣ方式の通信を実行可能なあらゆるデバイスを含む。 同様に、「外部装置」は、ＮＦＣ方式の通信を実行可能なあらゆるデバイスを含む。

（変形例８）上記の各実施例では、図２及び図６の各処理がソフトウェア（即ちプログラム３６）によって実現されるが、図２及び図６の各処理のうちの少なくとも１つが論理回路等のハードウェアによって実現されてもよい。

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

２：通信システム、１０：多機能機（ＭＦＰ）、３０：制御部、３２：ＣＰＵ、３４：メモリ、５０，５２：携帯端末