JP6617782B2 - 通信装置 - Google Patents

Description

本明細書によって開示される技術は、ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式で無線通信を実行可能な通信装置に関する。

特許文献１には、ＮＦＣデバイスが接続されるインターフェースを備える情報処理装置が開示されている。情報処理装置は、情報処理装置自身が省電力状態であるのか通常動作状態であるのかに応じて、ＮＦＣデバイスの動作モードを切り替える。これにより、情報処理装置は、ＮＦＣデバイスを利用して、情報処理装置自身の状態に応じたＮＦＣ通信を通信端末と実行することができる。

特開２０１１−４４０９２号公報

本明細書では、ＮＦＣ方式の無線通信を利用して、通信装置の状態に応じた適切な情報を携帯端末に送信し得る新規な技術を提供する。

本明細書によって開示される通信装置は、ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式の無線通信を実行するための第１のインターフェースと、制御部と、を備える。制御部は、通信装置の状態が、通信装置でエラーが発生しているエラー状態である状況において、第１のインターフェースを介した第１の接続が携帯端末と確立される場合に、第１の接続を利用して、エラー状態に関係する関係情報を携帯端末に送信する第１の通信制御部と、通信装置の状態が、通信装置でエラーが発生していない非エラー状態である状況において、第１のインターフェースを介した第２の接続が携帯端末と確立される場合に、第２の接続を利用して、関係情報とは異なる特定情報を携帯端末に送信する第２の通信制御部と、を備える。

上記の構成によると、通信装置は、ＮＦＣ方式の無線通信を利用して、エラー状態であるのか非エラー状態であるのかに応じた適切な情報を携帯端末に送信し得る。

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

通信システムの構成を示す。 多機能機のエラー監視処理のフローチャートを示す。 多機能機のエラー状態処理のフローチャートを示す。 多機能機の非エラー状態処理のフローチャートを示す。 多機能機がエラー状態である状況でＮＦＣ接続が確立されるケースＡのシーケンスチャートを示す。 多機能機が非エラー状態である状況でＮＦＣ接続が確立されるケースＢのシーケンスチャートを示す。

（通信システム２の構成；図１）
図１に示されるように、通信システム２は、多機能機１０と携帯端末５０とウェブサーバ１００とを備える。多機能機１０と携帯端末５０とのそれぞれは、ＮＦＣ規格の通信方式であるＮＦＣ方式の無線通信（即ちＮＦＣ通信）を実行可能であり、さらに、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅによって策定された通信方式であるＷｉ−Ｆｉ方式の無線通信（即ちＷｉ−Ｆｉ通信）を実行可能である。また、携帯端末５０は、Ｗｉ−Ｆｉ通信、３Ｇ通信等を実行して、インターネットにアクセス可能である。ウェブサーバ１００は、インターネット上に設けられている。

（多機能機１０の構成）
多機能機１０は、印刷機能及びスキャン機能を含む多機能を実行可能な周辺機器（即ちＰＣ（Personal Computerの略）等の周辺機器）である。多機能機１０は、操作部１２と、表示部１４と、印刷実行部１６と、スキャン実行部１８と、無線ＬＡＮ（Local Area Networkの略）インターフェース２０と、ＮＦＣインターフェース２２と、制御部３０と、を備える。以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。

操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示を多機能機１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。印刷実行部１６は、インクジェット方式、レーザ方式等の印刷機構である。スキャン実行部１８は、ＣＣＤ、ＣＩＳ等のスキャン機構である。

無線ＬＡＮＩ／Ｆ２０は、Ｗｉ−Ｆｉ方式の無線通信を実行するためのインターフェースである。Ｗｉ−Ｆｉ方式は、例えば、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.の略）の８０２．１１の規格又はそれに準ずる規格（例えば、８０２．１１ａ，１１ｂ，１１ｇ，１１ｎ等）に従った無線通信方式である。

より具体的に言うと、無線ＬＡＮＩ／Ｆ２０は、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅによって策定されたＷＦＤ（Wi-Fi Directの略）方式をサポートしている。従って、制御部３０は、ＷＦＤ方式の無線ネットワーク（以下では「ＷＦＤＮＷ」と呼ぶ）を利用して、無線ＬＡＮＩ／Ｆ２０を介して、Ｗｉ−Ｆｉ通信を実行することができる。ＷＦＤ方式の詳細は、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅによって作成された「Ｗｉ−Ｆｉ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ（Ｐ２Ｐ） Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ１．１」に記述されている。また、米国特許出願公開第２０１３／０２６０６８３号公報にも、ＷＦＤ方式の詳細が開示されており、当該文献を参照して引用する。

ＮＦＣＩ／Ｆ２２は、ＮＦＣ方式の無線通信を実行するためのインターフェースである。ＮＦＣ方式は、例えば、ＩＳＯ／ＩＥＣ２１４８１又はＩＳＯ／ＩＥＣ１８０９２の国際標準規格に従った無線通信方式である。ＮＦＣＩ／Ｆ２２は、例えば、ＮＦＣフォーラムによって定められるＴｙｐｅＡ又はＴｙｐｅＦを有するＩ／Ｆであり、ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モードをサポートしている。特に、ＮＦＣＩ／Ｆ２２は、ＮＦＣ規格のＳＮＥＰ（Simple NDEF Exchange Protocolの略)で定められているクライアント及びサーバのいずれとしても動作可能である。なお、NDEFは、NFC Data Exchange Formatの略である。

無線ＬＡＮＩ／Ｆ２０とＮＦＣＩ／Ｆ２２とは、物理的に異なるチップによって構成されている。無線ＬＡＮＩ／Ｆ２０を介した無線通信の通信速度（例えば、最大の通信速度が１１〜６００Ｍｂｐｓ）は、ＮＦＣＩ／Ｆ２２を介した無線通信の通信速度（例えば、最大の通信速度が１０６〜４２４ｋｂｐｓ）よりも速い。無線ＬＡＮＩ／Ｆ２０を介した無線通信における搬送波の周波数（例えば、２．４ＧＨｚ帯、５．０ＧＨｚ帯）は、ＮＦＣＩ／Ｆ２２を介した無線通信における搬送波の周波数（例えば、１３．５６ＭＨｚ帯）とは異なる。また、無線ＬＡＮＩ／Ｆ２０を介して無線通信可能な最大の距離（例えば１００ｍ）は、ＮＦＣＩ／Ｆ２２を介して無線通信可能な最大の距離（例えば１０ｃｍ）よりも大きい。

制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に格納されているプログラムに従って、様々な処理を実行するプロセッサである。メモリ３４は、上記のプログラムの他に、さらに、エラーフラグと、ＵＲＬ（Uniform Resource Locatorの略）データと、無線プロファイルと、を格納する。

エラーフラグは、「０」又は「１」を示すフラグである。エラーフラグ「０」は、多機能機１０の状態が、多機能機１０でエラーが発生していない非エラー状態であることを示す。エラーフラグ「１」は、多機能機１０の状態が、多機能機１０でエラーが発生しているエラー状態であることを示す。

多機能機１０では、様々な種類のエラーが発生し得る。様々な種類のエラーを以下に例示する。（１）カバーオープンエラー；筐体に対してカバーが開かれている状態。（２）印刷媒体ジャムエラー；印刷媒体を印刷実行部１６に搬送するための印刷媒体搬送装置に印刷媒体が詰まっている状態。（３）原稿ジャムエラー；スキャン対象の原稿をスキャン実行部１８に搬送するための自動原稿搬送装置（即ちＡＤＦ（Auto Document Feederの略））に原稿が詰まっている状態。（４）媒体無エラー；印刷媒体が給紙トレイに無い状態。（５）カートリッジエラー；例えば、インクカートリッジ、トナーカートリッジ等が多機能機１０に装着されていない状態、又は、装着されているカートリッジ内の色材が無い状態。（６）メモリフルエラー；メモリ３４内の空き容量が所定値未満である状態。

ＵＲＬデータは、複数種類のエラーのそれぞれについて、当該種類のエラーコードと、ＵＲＬと、が対応付けられたデータである。ＵＲＬは、後述のウェブサーバ１００内の位置を示す情報である。カバーオープンエラーに対応するＵＲＬ、印刷媒体ジャムエラーに対応するＵＲＬは、それぞれ、「Ｕ１」、「Ｕ２」である。

無線プロファイルは、ＷＦＤＮＷで利用される無線設定情報であり、ＳＳＩＤと認証方式と暗号化方式とパスワードとを含む。ＳＳＩＤは、ＷＦＤＮＷを識別するための識別子である。認証方式、暗号化方式、及び、パスワードは、ＷＦＤＮＷで実行される認証及び暗号化で利用される情報である。ＣＰＵ３２は、電源がＯＮされると、多機能機１０をＷＦＤ方式のＧ／Ｏ（Group Ownerの略）状態に移行させて、ＷＦＤＮＷを形成する。その際に、ＣＰＵ３２は、当該ＷＦＤＮＷで利用される無線設定情報を準備して、メモリ３４に格納させる。

（携帯端末５０の構成）
携帯端末５０は、例えば、携帯電話（例えばスマートフォン）、ＰＤＡ、ノートＰＣ、タブレットＰＣ、携帯型音楽再生装置、携帯型動画再生装置等の可搬型の端末装置である。携帯端末５０は、無線ＬＡＮＩ／Ｆ６０と、ＮＦＣＩ／Ｆ６２と、制御部７０と、を備える。

無線ＬＡＮＩ／Ｆ６０、ＮＦＣＩ／Ｆ６２は、それぞれ、多機能機１０の無線ＬＡＮＩ／Ｆ２０、ＮＦＣＩ／Ｆ２２と同様である。制御部７０は、ＣＰＵ７２と、メモリ７４と、を備える。ＣＰＵ７２は、メモリ７４に格納されているプログラム（後述のＯＳ（Operation Systemの略）プログラム等）に従って、様々な処理を実行するプロセッサである。メモリ７４は、ＯＳプログラムと、ブラウザアプリケーションと、多機能機用アプリケーションと、を格納している。以下では、アプリケーションのことを、「アプリ」と省略して記載する。

本実施例では、ＯＳプログラムは、Android（登録商標）である。ブラウザアプリは、インターネット上のウェブサーバ（例えば１００）から提供されるＨＴＭＬ（Hyper Text Markup Languageの略）形式のウェブページデータを解釈して表示するためのプログラムである。多機能機用アプリは、例えば、印刷機能とスキャン機能との少なくとも一方を多機能機１０に実行させるためのプログラムである。多機能機用アプリは、インターネット上のサーバから携帯端末５０にインストールされてもよいし、多機能機１０と共に出荷されるメディアから携帯端末５０にインストールされてもよい。

（ウェブサーバ１００の構成）
ウェブサーバ１００は、多機能機１０のベンダによって提供されるサーバである。ウェブサーバ１００は、多機能機１０で発生し得る複数種類のエラーのそれぞれについて、当該エラーの解消方法を示すウェブページを表わすウェブページデータＤ１、Ｄ２等と、当該ウェブページデータの位置を示すＵＲＬ「Ｕ１」、「Ｕ２」等と、を対応付けて格納している。具体的には、ＵＲＬ「Ｕ１」に対応するウェブページデータＤ１は、多機能機１０のカバーオープンエラーの解消方法を示すウェブページを表わす。また、ＵＲＬ「Ｕ２」に対応するウェブページデータＤ２は、多機能機１０の印刷媒体ジャムエラーの解消方法を示すウェブページを表わす。

（エラー監視処理；図２）
続いて、図２を参照して、多機能機１０のＣＰＵ３２によって実行されるエラー監視処理の内容を説明する。エラー監視処理は、多機能機１０の電源がＯＮされることをトリガとして開始される。

Ｓ１０では、ＣＰＵ３２は、多機能機１０を構成する各部（即ち各ハードウェア）から、当該各部の状況を示す各信号を取得する。例えば、ＣＰＵ３２は、カバー、印刷実行部１６、スキャン実行部１８、印刷媒体搬送装置、原稿搬送装置、メモリ３４等のそれぞれから信号を取得する。

次いで、Ｓ２０では、ＣＰＵ３２は、メモリ３４内のエラーフラグが「０」を示し、かつ、多機能機１０がエラー状態であるのか否かを判断する。ＣＰＵ３２は、Ｓ１０で各部から取得される各信号のうちの少なくとも１つの信号がエラーを示す場合に、多機能機１０がエラー状態であると判断し、当該各信号のいずれもエラーを示さない場合に、多機能機１０が非エラー状態であると判断する。ＣＰＵ３２は、エラーフラグが「０」を示し、かつ、多機能機１０がエラー状態である場合（即ち多機能機１０が非エラー状態からエラー状態に移行する場合）に、Ｓ２０でＹＥＳと判断して、Ｓ２２に進む。一方において、ＣＰＵ３２は、エラーフラグが「１」を示す場合、又は、多機能機１０が非エラー状態である場合に、Ｓ２０でＮＯと判断して、Ｓ３０に進む。

Ｓ２２では、ＣＰＵ３２は、メモリ３４内のエラーフラグを「０」から「１」に変更する。次いで、Ｓ２４では、ＣＰＵ３２は、ＮＦＣ通信のための機能を一時的に停止するためのコマンドをＮＦＣＩ／Ｆ２２に供給する。この場合、ＮＦＣＩ／Ｆ２２は、ＮＦＣ通信のための全ての機能（例えば接続を確立するための信号の受信及び送信）を一時的に停止する。これにより、ＮＦＣＩ／Ｆ２２は、後述のＳ２６で変更される変更後の動作モード（即ちクライアントモード）に従って適切に動作することができる。

次いで、Ｓ２６では、ＣＰＵ３２は、サーバモードからクライアントモードへのモード変更指示をＮＦＣＩ／Ｆ２２に供給する。この場合、ＮＦＣＩ／Ｆ２２は、ＮＦＣＩ／Ｆ２２の動作モードをサーバモードからクライアントモードに変更する。サーバモードは、ＳＮＥＰのサーバ動作をＮＦＣＩ／Ｆ２２に実行させ、その後、ＳＮＥＰのクライアント動作をＮＦＣＩ／Ｆ２２に実行させるためのモードである。また、クライアントモードは、ＳＮＥＰのサーバ動作とＳＮＥＰのクライアント動作とのうちのＳＮＥＰのクライアント動作のみをＮＦＣＩ／Ｆ２２に実行させるためのモードである。ＳＮＥＰのサーバ動作は、ＮＦＣＩ／Ｆ２２が、外部機器（例えば携帯端末５０）から受信する情報を、制御部３０（即ちＣＰＵ３２）に供給する動作である。ＳＮＥＰのクライアント動作は、ＮＦＣＩ／Ｆ２２が、制御部３０（即ちＣＰＵ３２）から取得する情報を、外部機器（例えば携帯端末５０）に送信する動作である。なお、クライアントモードでは、ＮＦＣＩ／Ｆ２２は、仮に、外部機器から情報を受信しても、当該情報を制御部３０（即ちＣＰＵ３２）に供給しない。Ｓ２６が終了すると、Ｓ１０に戻る。

Ｓ３０では、ＣＰＵ３２は、メモリ３４内のエラーフラグが「１」を示し、かつ、多機能機１０が非エラー状態であるのか否かを判断する。ＣＰＵ３２は、エラーフラグが「１」を示し、かつ、多機能機１０が非エラー状態である場合（即ち多機能機１０がエラー状態から非エラー状態に移行する場合）に、Ｓ３０でＹＥＳと判断して、Ｓ３２に進む。一方において、ＣＰＵ３２は、エラーフラグが「０」を示す場合、又は、多機能機１０がエラー状態である場合に、Ｓ３０でＮＯと判断して、Ｓ１０に戻る。

Ｓ３２では、ＣＰＵ３２は、メモリ３４内のエラーフラグを「１」から「０」に変更する。Ｓ３４は、Ｓ２４と同様である。これにより、ＮＦＣＩ／Ｆ２２は、後述のＳ３６で変更される変更後の動作モード（即ちサーバモード）に従って適切に動作することができる。次いで、Ｓ３６では、ＣＰＵ３２は、クライアントモードからサーバモードへのモード変更指示をＮＦＣＩ／Ｆ２２に供給する。この場合、ＮＦＣＩ／Ｆ２２は、ＮＦＣＩ／Ｆ２２の動作モードをクライアントモードからサーバモードに変更する。Ｓ３６が終了すると、Ｓ１０に戻る。

（エラー状態処理；図３）
続いて、図３を参照して、多機能機１０のＣＰＵ３２によって実行されるエラー状態処理の内容を説明する。エラー状態処理は、多機能機１０がエラー状態である間、即ち、メモリ３４内のエラーフラグが「１」である間に、実行される。換言すると、エラー状態処理は、ＮＦＣＩ／Ｆ２２の動作モードがクライアントモードである間に、実行される。

Ｓ５０では、ＣＰＵ３２は、多機能機１０のＮＦＣＩ／Ｆ２２と携帯端末５０のＮＦＣＩ／Ｆ６２との間にＮＦＣ方式に従った接続（以下では「ＮＦＣ接続」と呼ぶ）が確立されることを監視する。多機能機１０のＮＦＣＩ／Ｆ２２は、ＮＦＣ接続を確立するための要求信号を外部に定期的に送信する。同様に、携帯端末５０のＮＦＣＩ／Ｆ６２も、要求信号を外部に定期的に送信する。一対のＮＦＣＩ／Ｆ２２，６２の間の距離がＮＦＣ通信可能な最大の距離（例えば１０ｃｍ）以下になると、一方のＮＦＣＩ／Ｆは、他方のＩ／Ｆから要求信号を受信して、応答信号を他方のＩ／Ｆに送信する。これにより、一対のＮＦＣＩ／Ｆ２２，６２の間にＮＦＣ接続が確立される。この場合、多機能機１０のＮＦＣＩ／Ｆ２２は、ＮＦＣ接続が確立されたことを示す情報を制御部３０に供給する。この結果、ＣＰＵ３２は、Ｓ５０でＹＥＳと判断して、Ｓ５２に進む。

Ｓ５２では、ＣＰＵ３２は、メモリ３４内のＵＲＬデータ（図１参照）から、多機能機１０で現在発生しているエラーに対応するＵＲＬを取得する。なお、ＣＰＵ３２は、多機能機１０で２種類以上のエラーが現在発生している場合には、例えば、予め決められている優先度に応じて、最も優先度が高い１種類のエラー（即ち最も早期に解消されるべきエラー）に対応するＵＲＬを取得する。

次いで、Ｓ５４では、ＣＰＵ３２は、取得済みのＵＲＬをＮＦＣＩ／Ｆ２２に供給する。ＮＦＣＩ／Ｆ２２の動作モードがクライアントモードであるので、ＮＦＣＩ／Ｆ２２は、ＣＰＵ３２から取得するＵＲＬを、携帯端末５０に送信する（即ちＳＮＥＰのクライアント動作を実行する）。即ち、Ｓ５４では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＳＮＥＰのクライアントとして動作させて、Ｓ５０で確立されたＮＦＣ接続を利用して、ＵＲＬを携帯端末５０に送信する。Ｓ５４が終了すると、Ｓ５０に戻る。

（非エラー状態処理；図４）
続いて、図４を参照して、多機能機１０のＣＰＵ３２によって実行される非エラー状態処理の内容を説明する。非エラー状態処理は、多機能機１０が非エラー状態である間、即ち、メモリ３４内のエラーフラグが「０」である間に、実行される。換言すると、非エラー状態処理は、ＮＦＣＩ／Ｆ２２の動作モードがサーバモードである間に、実行される。

Ｓ６０は、図３のＳ５０と同様である。ＣＰＵ３２は、ＮＦＣ接続が確立される場合に、Ｓ６０でＹＥＳと判断して、Ｓ６２に進む。

Ｓ６２では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から無線プロファイルの要求を取得する。上述したように、図３のエラー状態処理では、ＣＰＵ３２は、ＮＦＣ接続が確立された後に、携帯端末５０から要求を受信しなくても、携帯端末５０に送信されるべきＵＲＬをＮＦＣＩ／Ｆ２２に供給する（図３のＳ５４）。これに対し、図４の非エラー状態処理では、ＣＰＵ３２は、携帯端末５０から要求を受信するまで、携帯端末５０に送信されるべき情報をＮＦＣＩ／Ｆ２２に供給しない。そして、ＮＦＣＩ／Ｆ２２の動作モードがサーバモードであるので、ＮＦＣＩ／Ｆ２２は、携帯端末５０から無線プロファイルの要求を受信する場合に、当該要求を制御部３０に供給する（即ちＳＮＥＰのサーバ動作を実行する）。即ち、Ｓ６２では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＳＮＥＰのサーバとして動作させて、Ｓ６０で確立されたＮＦＣ接続を利用して、携帯端末５０から無線プロファイルの要求を受信する。

次いで、Ｓ６４では、ＣＰＵ３２は、メモリ３４から無線プロファイルを取得し、当該無線プロファイルをＮＦＣＩ／Ｆ２２に供給する。これにより、ＮＦＣＩ／Ｆ２２は、制御部３０から無線プロファイルを取得する場合に、当該無線プロファイルを携帯端末５０に送信する（即ちＳＮＥＰのクライアント動作を実行する）。即ち、Ｓ６４では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＳＮＥＰのクライアントとして動作させて、Ｓ６０で確立されたＮＦＣ接続を利用して、無線プロファイルを携帯端末５０に送信する。Ｓ６４が終了すると、Ｓ６０に戻る。

（ケースＡ；図５）
続いて、図２〜図４の各処理によって実現されるケースＡを説明する。ケースＡの初期状態では、多機能機１０が非エラー状態であり、ＮＦＣＩ／Ｆ２２の動作モードがサーバモードである。

Ｔ１０では、ユーザによって多機能機１０のカバーが開かれることに起因して、多機能機１０において、カバーオープンエラーが発生する。この場合、Ｔ１２では、多機能機１０のＣＰＵ３２は、モード変更指示をＮＦＣＩ／Ｆ２２に供給する（図２のＳ２０でＹＥＳ、Ｓ２２〜Ｓ２６）。これにより、Ｔ１４では、ＮＦＣＩ／Ｆ２２は、サーバモードからクライアントモードに移行する。

その後、ユーザは、携帯端末５０を多機能機１０に近づける。これにより、Ｔ２０では、多機能機１０のＮＦＣＩ／Ｆ２２と携帯端末５０のＮＦＣＩ／Ｆ６２との間にＮＦＣ接続が確立される（図３のＳ５０でＹＥＳ）。

Ｔ２２では、多機能機１０のＣＰＵ３２は、カバーオープンエラーに対応するＵＲＬ「Ｕ１」（図１参照）をＮＦＣＩ／Ｆ２２に供給する。Ｔ２４では、ＮＦＣＩ／Ｆ２２は、ＳＮＥＰのクライアントとして動作して、Ｔ２０のＮＦＣ接続を利用して、ＵＲＬ「Ｕ１」を携帯端末５０に送信する。

Ｔ２４の時点では、携帯端末５０では、ブラウザアプリ及び多機能用アプリを含むいずれのアプリも起動されていない。この場合、携帯端末５０のＣＰＵ７２は、ＯＳプログラムに従って、ＳＮＥＰのサーバ動作をＮＦＣＩ／Ｆ６２に実行させる。従って、Ｔ３０では、ＮＦＣＩ／Ｆ６２は、多機能機１０から受信するＵＲＬ「Ｕ１」を、ＣＰＵ７２に供給する。この結果、Ｔ３２では、ＣＰＵ７２は、ユーザから指示が与えられなくても、ブラウザアプリを自動的に起動する。

Ｔ４０では、携帯端末５０のＣＰＵ７２（即ちブラウザアプリ）は、無線ＬＡＮＩ／Ｆ６０を介して、ＵＲＬ「Ｕ１」を含むＨＴＴＰ（Hyper Text Transfer Protocolの略）要求をウェブサーバ１００に送信する。これにより、Ｔ４２では、ＣＰＵ７２は、ウェブサーバ１００から、無線ＬＡＮＩ／Ｆ６０を介して、ＵＲＬ「Ｕ１」に対応するウェブページデータＤ１（図１参照）を受信する。そして、Ｔ４４では、ＣＰＵ７２（即ちブラウザアプリ）は、ウェブページデータＤ１によって表わされるウェブページを携帯端末５０の表示部（図示省略）に表示させる。

ユーザは、Ｔ４４で表示されるウェブページを見ることによって、カバーオープンエラーの解消方法（例えば、どのカバーをどのようにして閉じるのか）を知ることができる。従って、ユーザは、多機能機１０において、カバーオープンエラーを解消するための動作を実行する。この結果、Ｔ５０では、ユーザによって多機能機１０のカバーが閉じられることに起因して、多機能機１０において、カバーオープンエラーが解消する。この場合、Ｔ５２では、多機能機１０のＣＰＵ３２は、モード変更指示をＮＦＣＩ／Ｆ２２に供給する（図２のＳ３０でＹＥＳ、Ｓ３２〜Ｓ３６）。これにより、Ｔ５４では、ＮＦＣＩ／Ｆ２２は、クライアントモードからサーバモードに移行する。

なお、仮に、Ｔ１０で印刷媒体ジャムエラーが発生する場合には、Ｔ２２，Ｔ２４，Ｔ３０では、ＵＲＬ「Ｕ２」の通信が実行され、Ｔ４０では、ＵＲＬ「Ｕ２」を含むＨＴＴＰ要求の通信が実行され、Ｔ４２では、ウェブページデータＤ２の通信が実行される。この結果、Ｔ４４では、印刷媒体ジャムエラーの解消方法を示すウェブページが表示され、Ｔ５０では、印刷媒体ジャムエラーが解消される。

（ケースＢ；図６）
続いて、図２〜図４の各処理によって実現されるケースＢを説明する。ケースＢの初期状態は、図５のケースＡの初期状態と同じである。ケースＢでは、ユーザが、携帯端末５０の多機能機用アプリを利用して、携帯端末５０内の画像データによって表わされる画像の印刷を多機能機１０に実行させる。

Ｔ１００では、携帯端末５０のＣＰＵ７２は、ユーザから指示が与えられることに起因して、多機能機用アプリを起動する。そして、ユーザは、携帯端末５０を多機能機１０に近づける。これにより、Ｔ１１０では、多機能機１０のＮＦＣＩ／Ｆ２２と携帯端末５０のＮＦＣＩ／Ｆ６２との間にＮＦＣ接続が確立される（図４のＳ６０でＹＥＳ）。

Ｔ１２０では、携帯端末５０のＣＰＵ７２（即ち多機能機用アプリ）は、無線プロファイルの要求をＮＦＣＩ／Ｆ６２に供給する。これにより、Ｔ１２２では、ＮＦＣＩ／Ｆ６２は、ＳＮＥＰのクライアントとして動作して、Ｔ１１０のＮＦＣ接続を利用して、無線プロファイルの要求を多機能機１０に送信する。

Ｔ１３０では、多機能機１０のＮＦＣＩ／Ｆ２２は、ＳＮＥＰのサーバとして動作して、携帯端末５０から受信する無線プロファイルの要求を、ＣＰＵ３２に供給する。これにより、ＣＰＵ３２は、無線プロファイルの要求を取得する（図４のＳ６２）。

次いで、Ｔ１３２では、多機能機１０のＣＰＵ３２は、メモリ３４内の無線プロファイルをＮＦＣＩ／Ｆ２２に供給する（図４のＳ６４）。この結果、Ｔ１３４では、ＮＦＣＩ／Ｆ２２は、ＳＮＥＰのクライアントとして動作して、Ｔ１１０のＮＦＣ接続を利用して、無線プロファイルを携帯端末５０に送信する。

Ｔ１４０では、携帯端末５０のＮＦＣＩ／Ｆ６２は、ＳＮＥＰのサーバとして動作して、多機能機１０から受信する無線プロファイルを、ＣＰＵ７２に供給する。この場合、Ｔ１４２では、ＣＰＵ７２（即ち多機能機用アプリ）は、無線プロファイルを利用して、無線ＬＡＮＩ／Ｆ６０を介して、多機能機１０との無線接続を確立するための様々な通信を実行する。当該通信は、例えば、無線プロファイル内のＳＳＩＤを含むProbe Request信号の送信、無線プロファイル内のパスワード等を利用した認証のための通信等を含む。これにより、多機能機１０の無線ＬＡＮＩ／Ｆ２０と携帯端末５０の無線ＬＡＮＩ／Ｆ６０との間に、Ｗｉ−Ｆｉ方式に従った無線接続が確立される。即ち、携帯端末５０は、ＷＦＤ方式のＣＬ（Clientの略）状態に移行して、多機能機１０がＧ／Ｏ状態として動作するＷＦＤＮＷに参加することができる。

Ｔ１４４では、携帯端末５０のＣＰＵ７２（即ち多機能機用アプリ）は、ＷＦＤＮＷを利用して（即ちＴ１４０の無線接続を利用して）、無線ＬＡＮＩ／Ｆ６０を介して、画像データを多機能機１０に送信する。当該画像データは、例えば、携帯端末５０のメモリ７４に格納されている複数個の画像データの中から、印刷対象としてユーザによって指定される画像データである。

多機能機１０のＣＰＵ３２は、ＷＦＤＮＷを利用して、無線ＬＡＮＩ／Ｆ２０を介して、携帯端末５０から画像データを受信する。この場合、Ｔ１５０では、ＣＰＵ３２は、携帯端末５０から受信される画像データを利用して、当該画像データによって表わされる画像の印刷を印刷実行部１６に実行させる。

上述したように、ケースＢでは、多機能機１０は、Ｔ１１０のＮＦＣ接続を利用して、無線プロファイルを携帯端末５０に送信する（Ｔ１３４）。この結果、多機能機１０と携帯端末５０との間にＴ１４２の無線接続が確立され、携帯端末５０は、Ｔ１４２の無線接続を利用して、画像データを多機能機１０に送信する（Ｔ１４４）。これに代えて、携帯端末５０が、Ｔ１１０のＮＦＣ接続を利用して、画像データを多機能機１０に送信する構成が考えられる。しかしながら、ＮＦＣＩ／Ｆ２２を介した無線通信の通信速度は、無線ＬＡＮＩ／Ｆ２０を介した無線通信の通信速度よりも遅い。従って、仮に、上記の構成が採用されると、画像データの通信に時間がかかるので、印刷物をユーザに迅速に提供することができない。これに対し、本実施例では、Ｔ１１０のＮＦＣ接続を利用して無線プロファイルが送信されるが、無線プロファイルのデータサイズが画像データと比べて小さいので、無線プロファイルの通信が短時間で済む。その後、Ｔ１４２の無線接続を利用して、画像データが高速で通信される。このために、印刷物をユーザに迅速に提供することができる。

なお、携帯端末５０のユーザは、多機能機用アプリを利用して、原稿のスキャンを多機能機１０に実行させてもよい。この場合、携帯端末５０のＣＰＵ７２は、Ｔ１４４において、画像データではなく、スキャンの実行指示を多機能機１０に送信する。この場合、多機能機１０のＣＰＵ３２は、原稿のスキャンをスキャン実行部１８に実行させて、スキャンデータを生成する。そして、ＣＰＵ３２は、Ｔ１４２の無線接続を利用して、当該スキャンデータを携帯端末５０に送信する。

（実施例の効果）
図５のケースＡに示されるように、多機能機１０は、エラー状態である状況でＮＦＣ接続が携帯端末５０と確立される場合（Ｔ２０）に、当該ＮＦＣ接続を利用して、ＵＲＬ「Ｕ１」を携帯端末５０に送信する（Ｔ２４）。これにより、多機能機１０は、カバーオープンエラーの解消方法を示すウェブページの表示のための動作（Ｔ４０〜Ｔ４４）を携帯端末５０に実行させることができる。また、図６のケースＢに示されるように、多機能機１０は、非エラー状態である状況でＮＦＣ接続が携帯端末５０と確立される場合（Ｔ１１０）に、当該ＮＦＣ接続を利用して、無線プロファイルを携帯端末５０に送信する（Ｔ１３４）。これにより、多機能機１０は、画像データの送信のための動作（Ｔ１４０〜Ｔ１４４）を携帯端末５０に実行させることができる。このように、多機能機１０は、ＮＦＣ通信を利用して、エラー状態であるのか非エラー状態であるのかに応じた適切な情報を携帯端末５０に送信することができ、この結果、エラー状態であるのか非エラー状態であるのかに応じた適切な動作を携帯端末５０に実行させることができる。

（第１の比較例）
本実施例では、多機能機１０がエラー状態である間にＮＦＣＩ／Ｆ２２がクライアントモードで動作し（図３のＳ２６）、多機能機１０が非エラー状態である間にＮＦＣＩ／Ｆ２２がサーバモードで動作する（Ｓ３６）。これに代えて、第１の比較例では、多機能機１０がエラー状態であるのか非エラー状態であるのかに関わらず、ＮＦＣＩ／Ｆ２２の動作モードをサーバモードに維持する。ただし、この場合、多機能機１０は、携帯端末５０から要求を受信しなければ、情報を携帯端末５０に送信することができない。従って、第１の比較例では、多機能機１０は、携帯端末５０からＵＲＬの要求を受信する場合に、ＵＲＬを携帯端末５０に送信し、携帯端末５０から無線プロファイルの要求を受信する場合に、無線プロファイルを携帯端末５０に送信する。このために、第１の比較例では、ＵＲＬの要求を多機能機１０に送信するための特別な仕組み（例えば特別なアプリ）を携帯端末５０に設けなければならない。

これに対し、本実施例では、多機能機１０がエラー状態である間にＮＦＣＩ／Ｆ２２がクライアントモードで動作するので、多機能機１０は、携帯端末５０から要求を受信しなくても、ＵＲＬを携帯端末５０に送信することができる（図５のＴ２２，Ｔ２４）。そして、携帯端末５０のＯＳプログラム（例えばAndroid（登録商標））は、多機能機１０からＵＲＬを受信する場合に、ブラウザアプリを自動的に起動させて、ウェブページにアクセスする（Ｔ３０〜Ｔ４４）。従って、特別な仕組みを携帯端末５０に設けなくても、エラーの解消方法を示すウェブページを携帯端末５０に表示させることができる。

例えば、第１の比較例において、携帯端末５０の多機能機用アプリに上記の特別な仕組みを設けることが考えられる。ただし、この場合、多機能機用アプリが複雑になるので多機能機用アプリを作成するのに手間がかかるし、エラーの解消方法を示すウェブページを携帯端末５０に表示させるために、多機能機用アプリを携帯端末５０に必ずインストールさせなければならない。これに対し、本実施例では、多機能機用アプリに上記の特別な仕組みを設けずに済むので、多機能機用アプリが複雑になるのを抑制することができる。また、本実施例では、仮に、携帯端末５０が多機能機用アプリを備えていなくても、携帯端末５０がＯＳプログラムとブラウザアプリとを備えていれば、エラーの解消方法を示すウェブページを携帯端末５０に表示させることができる。

（第２の比較例）
第２の比較例では、多機能機１０がエラー状態であるのか非エラー状態であるのかに関わらず、ＮＦＣＩ／Ｆ２２の動作モードをクライアントモードに維持する。そして、多機能機１０のＣＰＵ３２は、多機能機１０がエラー状態である状況でＮＦＣ接続が確立される場合に、ＵＲＬをＮＦＣＩ／Ｆ２２に供給し（即ち当該ＵＲＬを携帯端末５０に送信し）、多機能機１０が非エラー状態である状況でＮＦＣ接続が確立される場合に、無線プロファイルをＮＦＣＩ／Ｆ２２に供給する（即ち当該無線プロファイルを携帯端末５０に送信する）。ただし、第２の比較例では、多機能機１０のＣＰＵ３２は、多機能機１０が非エラー状態である状況でＮＦＣ接続が確立される場合に、携帯端末５０から無線プロファイルの要求を受信しなくても、無線プロファイルを携帯端末５０に送信する。即ち、携帯端末５０で多機能機用アプリが起動されていなくても、多機能機１０から携帯端末５０に無線プロファイルが送信される。携帯端末５０で多機能機用アプリが起動されていないので、携帯端末５０は、多機能機１０から無線プロファイルを受信しても、当該無線プロファイルを解釈することができず、当該無線プロファイルに応じた動作を実行しない。即ち、第２の比較例では、携帯端末５０が解釈不可能な不要な情報が、多機能機１０から携帯端末５０に与えられ得る。このような不要な情報が携帯端末５０に与えられると、携帯端末５０の動作が不安定になり得る。

これに対し、本実施例では、多機能機１０が非エラー状態である間にＮＦＣＩ／Ｆ２２がサーバモードで動作するので、多機能機１０は、携帯端末５０から要求を受信することを条件として、無線プロファイルを携帯端末５０に送信することができる（図６のＴ１３０〜Ｔ１３４）。即ち、多機能機１０は、携帯端末５０で多機能機用アプリが起動されている間にのみ、無線プロファイルを携帯端末５０に送信することができる。従って、携帯端末５０が解釈不可能な不要な情報が、多機能機１０から携帯端末５０に与えられるのを抑制することができる。

（対応関係）
多機能機１０が、「通信装置」の一例である。ＮＦＣＩ／Ｆ２２、無線ＬＡＮＩ／Ｆ２０が、それぞれ、「第１のインターフェース」、「第２のインターフェース」の一例である。図５のＴ２０のＮＦＣ接続、図６のＴ１１０のＮＦＣ接続が、それぞれ、「第１の接続」、「第２の接続」の一例である。図５のＴ２４のＵＲＬ、図６のＴ１２２の要求、Ｔ１３４の無線プロファイルが、それぞれ、「関係情報」、「特定要求」、「特定情報」の一例である。カバーオープンエラー、印刷媒体ジャムエラーが、それぞれ、「第１のエラー」、「第２のエラー」の一例である。ＵＲＬ「Ｕ１」、ＵＲＬ「Ｕ２」が、それぞれ、「第１種の関係情報」、「第２種の関係情報」の一例である。サーバモード、クライアントモードが、それぞれ、「第１のモード」、「第２のモード」の一例である。

図３のＳ５０〜５４の処理、図４のＳ６０〜６４の処理が、それぞれ、「第１の通信制御部」、「第２の通信制御部」によって実行される処理の一例である。図２のＳ２６及びＳ３６の処理が、「モード制御部」によって実行される処理の一例である。

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

（変形例１）多機能機１０は、上記の第１の比較例の動作を実行してもよい。即ち、多機能機１０は、ＮＦＣＩ／Ｆ２２の動作モードをサーバモードに維持し、携帯端末５０からＵＲＬの要求を受信する場合に、ＵＲＬを携帯端末５０に送信し、携帯端末５０から無線プロファイルの要求を受信する場合に、無線プロファイルを携帯端末５０に送信してもよい。本変形例では、ＵＲＬの要求に応じてＵＲＬを携帯端末５０に送信する処理、無線プロファイルの要求に応じて無線プロファイルを携帯端末５０に送信する処理が、それぞれ、「第１の通信制御部」、「第２の通信制御部」によって実行される処理の一例である。

（変形例２）多機能機１０は、上記の第２の比較例の動作を実行してもよい。即ち、多機能機１０は、ＮＦＣＩ／Ｆ２２の動作モードをクライアントモードに維持し、多機能機１０がエラー状態である状況でＮＦＣ接続が確立される場合に、携帯端末５０から要求を受信しなくても、ＵＲＬを携帯端末５０に送信し、多機能機１０が非エラー状態である状況でＮＦＣ接続が確立される場合に、携帯端末５０から要求を受信しなくても、無線プロファイルを携帯端末５０に送信してもよい。本変形例では、要求を受信せずにＵＲＬを携帯端末５０に送信する処理、要求を受信せずに無線プロファイルを携帯端末５０に送信する処理が、それぞれ、「第１の通信制御部」、「第２の通信制御部」によって実行される処理の一例である。

（変形例３）上記の実施例では、多機能機１０のＮＦＣＩ／Ｆ２２と携帯端末５０のＮＦＣＩ／Ｆ６２とが、ＳＮＥＰのサーバ動作とＳＮＥＰのクライアント動作とを実行して、ＮＦＣ規格のＰ２Ｐモードに従って通信を実行する。これに代えて、各ＮＦＣＩ／Ｆ２２，６２は、ＮＦＣ規格の他のモード（即ち、ＣＥ（Card Emulationの略）モード又はＲ／Ｗ（Reader/Writerの略）モード）に従って、以下の（変形例３−１）〜（変形例３−４）の通信を実行してもよい。一般的に言うと、「第１の通信制御部」と「第２の通信制御部」とは、上記の実施例のように、ＮＦＣ規格のＰ２Ｐモードに従って携帯端末と通信を実行してもよいし、本変形例のように、ＮＦＣ規格の他のモードに従って携帯端末と通信を実行してもよい。

（変形例３−１）図２のＳ２６では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＣＥモードで動作させてもよい。この場合、携帯端末５０がＲｅａｄｅｒモードで動作すれば、図３のＳ５４では、ＣＰＵ３２は、ＵＲＬを携帯端末５０に送信することができる。また、図３のＳ６４では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＣＥモードで動作させてもよい。この場合、携帯端末５０がＲｅａｄｅｒモードで動作すれば、ＣＰＵ３２は、無線プロファイルを携帯端末５０に送信することができる。

（変形例３−２）図２のＳ２６では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＷｒｉｔｅｒモードで動作させてもよい。この場合、携帯端末５０がＣＥモードで動作すれば、図３のＳ５４では、ＣＰＵ３２は、ＵＲＬを携帯端末５０に送信することができる。また、図３のＳ６４では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＷｒｉｔｅｒモードで動作させてもよい。この場合、携帯端末５０がＣＥモードで動作すれば、ＣＰＵ３２は、無線プロファイルを携帯端末５０に送信することができる。

（変形例３−３）図２のＳ３６では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＣＥモードで動作させてもよい。この場合、携帯端末５０がＷｒｉｔｅｒモードで動作すれば、図３のＳ６２では、ＣＰＵ３２は、携帯端末５０から無線プロファイルの要求を受信することができる。

（変形例３−４）図２のＳ３６では、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２をＲｅａｄｅｒモードで動作させてもよい。この場合、携帯端末５０がＣＥモードで動作すれば、図３のＳ６２では、ＣＰＵ３２は、携帯端末５０から無線プロファイルの要求を受信することができる。

（変形例４）上記の実施例と上記の変形例３では、ＮＦＣＩ／Ｆ２２は、ＮＦＣフォーラムデバイスと呼ばれるＩ／Ｆであり、ＮＦＣ規格の３つのモード（Ｐ２Ｐ、Ｒ／Ｗ、及び、ＣＥ）のいずれかで動作可能である。これに代えて、ＮＦＣＩ／Ｆ２２は、ＩＣタグのみとして機能するＮＦＣフォーラムタグと呼ばれるＩ／Ｆであってもよい。特に、ＮＦＣＩ／Ｆ２２は、ホスト側（即ち多機能機１０側）のＣＰＵ３２からの情報の書き込みと情報の読み出しとを許容するＩ／Ｆであってもよい。この場合、例えば、ＣＰＵ３２は、多機能機１０が非エラー状態からエラー状態に移行する場合に、ＵＲＬをＮＦＣＩ／Ｆ２２に書き込む。これにより、携帯端末５０がＲｅａｄｅｒモードで動作すれば、ＮＦＣＩ／Ｆ２２は、ＵＲＬを携帯端末５０に送信することができる。また、例えば、ＣＰＵ３２は、多機能機１０がエラー状態から非エラー状態に移行する場合に、ＮＦＣＩ／Ｆ６２に書き込んだＵＲＬを消去する。この場合、携帯端末５０がＷｒｉｔｅｒモードで動作すれば、ＮＦＣＩ／Ｆ２２は、携帯端末５０から無線プロファイルの要求を受信することができる。そして、ＣＰＵ３２は、ＮＦＣＩ／Ｆ２２から無線プロファイルの要求を読み出し、その後、無線プロファイルをＮＦＣＩ／Ｆ２２に書き込む。これにより、携帯端末５０がＲｅａｄｅｒモードで動作すれば、ＮＦＣＩ／Ｆ２２は、無線プロファイルを携帯端末５０に送信することができる。一般的に言うと、「第１のインターフェース」は、ＮＦＣ方式で無線通信を実行するためのインターフェースであればよい。

（変形例５）上記の実施例では、図３のＳ５２，Ｓ５４では、多機能機１０のＣＰＵ３２は、多機能機１０で発生しているエラーの解消方法を示すウェブページのＵＲＬを携帯端末５０に送信する。これに代えて、以下の（変形例５−１）〜（変形例５−３）のいずれかが採用されてもよい。一般的に言うと、「関係情報」は、エラー状態に関係する情報であればよい。

（変形例５−１）ＣＰＵ３２は、エラーの解消方法を示すテキストを携帯端末５０に送信してもよい。この場合、携帯端末５０は、当該テキストを表示すればよく、ウェブサーバ１００にアクセスせずに済む。本変形例では、上記のテキストが、「関係情報」の一例である。

（変形例５−２）ＣＰＵ３２は、エラーの解消方法を示していないと共に当該エラーの種類を示すテキストを携帯端末５０に送信してもよい。本変形例では、上記のテキストが、「関係情報」の一例である。

（変形例５−３）ＣＰＵ３２は、ウェブサーバ１００内の位置を示すＵＲＬ（以下では「第１のＵＲＬ」と呼ぶ）ではなく、他のサーバ内の位置を示すＵＲＬ（以下では「第２のＵＲＬ」と呼ぶ）を携帯端末５０に送信してもよい。この場合、携帯端末５０は、第２のＵＲＬを利用して上記の他のサーバにアクセスして、上記の他のサーバから第１のＵＲＬを取得してもよい。そして、携帯端末５０は、第１のＵＲＬを利用してウェブサーバ１００にアクセスして、ウェブページデータを取得してもよい。本変形例では、上記の第２のＵＲＬが、「関係情報」の一例である。

（変形例６）上記の実施例では、図４のＳ６２，Ｓ６４では、多機能機１０のＣＰＵ３２は、携帯端末５０から無線プロファイルの要求を受信して、無線プロファイルを携帯端末５０に送信する。これに代えて、以下の（変形例６−１）〜（変形例６−３）のいずれかが採用されてもよい。一般的に言うと、「特定情報」は、「関係情報」とは異なる情報であればよい。

（変形例６−１）多機能機１０がアクセスポイントによって形成される特定の無線ネットワークに所属している状況を想定する。多機能機１０のメモリ３４は、上記の特定の無線ネットワークで利用される無線プロファイルを格納する。図４のＳ６４では、ＣＰＵ３２は、当該無線プロファイルを携帯端末５０に送信してもよい。これにより、携帯端末５０は、当該無線プロファイルを利用して、アクセスポイントとの無線接続を確立する。そして、多機能機１０は、上記の特定の無線ネットワークを利用して（即ちアクセスポイントを介して）、無線ＬＡＮＩ／Ｆ２０を介して、携帯端末５０から画像データを受信する。本変形例では、上記の特定の無線ネットワークで利用される無線プロファイルが、「特定情報」の一例である。

（変形例６−２）図４のＳ６２では、ＣＰＵ３２は、携帯端末５０から認証情報を受信してもよい。当該認証情報は、多機能機１０がインターネット上のサーバにログインするための情報である。そして、Ｓ６４では、ＣＰＵ３２は、当該認証情報を受信したことを示すＯＫ情報を携帯端末５０に送信してもよい。本変形例では、上記のＯＫ情報が「特定情報」の一例である。

（変形例６−３）多機能機１０は、ＢｌｕｅＴｏｏｔｈ（登録商標）の無線通信（以下では「ＢＴ通信」と呼ぶ）を実行するためのＩ／Ｆを備えていてもよい。図４のＳ６４では、ＣＰＵ３２は、ＢＴ通信を実行するためのペアリングキーを含む無線プロファイルを携帯端末５０に送信してもよい。本変形例では、ＢＴ通信のための無線プロファイル、ＢＴ通信のためのＩ／Ｆが、それぞれ、「特定情報」、「第２のインターフェース」の一例である。

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

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

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時項目記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
以下の特徴は、出願当初の特許請求の範囲に記載の要素である。
（項目１）
通信装置であって、
ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式の無線通信を実行するための第１のインターフェースと、
制御部と、を備え、
前記制御部は、
前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第１のインターフェースを介した第１の接続が携帯端末と確立される場合に、前記第１の接続を利用して、前記エラー状態に関係する関係情報を前記携帯端末に送信する第１の通信制御部と、
前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第１のインターフェースを介した第２の接続が前記携帯端末と確立される場合に、前記第２の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第２の通信制御部と、
を備える通信装置。
（項目２）
前記第１の通信制御部は、前記第１の接続が確立される場合に、前記第１の接続を利用して、前記携帯端末から要求を受信しなくても、前記関係情報を前記携帯端末に送信し、
前記第２の通信制御部は、前記第２の接続が確立される場合に、前記第２の接続を利用して、前記携帯端末から特定要求を受信し、前記特定要求に応じて、前記特定情報を前記携帯端末に送信する、項目１に記載の通信装置。
（項目３）
前記制御部は、さらに、
前記通信装置の状態が前記非エラー状態から前記エラー状態に移行する場合に、前記第１のインターフェースの動作モードを第１のモードから第２のモードに移行させ、前記通信装置の状態が前記エラー状態から前記非エラー状態に移行する場合に、前記第１のインターフェースの前記動作モードを前記第２のモードから前記第１のモードに移行させるモード制御部を備え、
前記第１のモードは、第１の動作を前記第１のインターフェースに実行させ、その後、前記第１のインターフェースに第２の動作を実行させるためのモードであり、
前記第２のモードは、前記第１の動作と前記第２の動作とのうちの前記第２の動作のみを前記第１のインターフェースに実行させるためのモードであり、
前記第１の動作は、前記第１のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作であり、
前記第２の動作は、前記第１のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作である、項目１又は２に記載の通信装置。
（項目４）
前記第１の動作は、前記ＮＦＣ規格のＳＮＥＰ（Simple NDEF (NFC Data Exchange Formatの略) Exchange Protocolの略)で定められているサーバの動作であり、
前記第２の動作は、前記ＮＦＣ規格の前記ＳＮＥＰで定められているクライアントの動作である、項目３に記載の通信装置。
（項目５）
前記関係情報は、前記携帯端末が前記エラー状態に関係するウェブページを表示するためのＵＲＬ（Uniform Resource Locatorの略）を含む、項目１から４のいずれか一項に記載の通信装置。
（項目６）
前記通信装置は、さらに、
前記ＮＦＣ方式とは異なる通信方式で無線通信を実行するための第２のインターフェースを備え、
前記特定情報は、前記通信装置と前記携帯端末との間で前記第２のインターフェースを介した無線通信を実行するための無線プロファイルを含む、項目１から５のいずれか一項に記載の通信装置。
（項目７）
前記第１の通信制御部は、
前記通信装置で第１種のエラーが発生していることに起因して、前記通信装置の状態が前記エラー状態である状況において、前記第１の接続が確立される場合に、前記第１の接続を利用して、前記第１種のエラーに起因する前記エラー状態に関係する第１種の前記関係情報を前記携帯端末に送信し、
前記通信装置で前記第１種のエラーとは異なる第２種のエラーが発生していることに起因して、前記通信装置の状態が前記エラー状態である状況において、前記第１の接続が確立される場合に、前記第１の接続を利用して、前記第２種のエラーに起因する前記エラー状態に関係する第２種の前記関係情報であって、前記第１種の関係情報とは異なる前記第２種の関係情報を前記携帯端末に送信する、項目１から６のいずれか一項に記載の通信装置。
（項目８）
通信装置のためのコンピュータプログラムであって、
前記コンピュータプログラムは、前記通信装置のプロセッサに、以下の各処理、即ち、
前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記通信装置の第１のインターフェースであって、ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式の無線通信を実行するための前記第１のインターフェースを介した第１の接続が携帯端末と確立される場合に、前記第１の接続を利用して、前記エラー状態に関係する関係情報を前記携帯端末に送信する第１の通信制御処理と、
前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第１のインターフェースを介した第２の接続が前記携帯端末と確立される場合に、前記第２の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第２の通信制御処理と、
を実行させるコンピュータプログラム。

２：通信システム、１０：多機能機、１２：操作部、１４：表示部、１６：印刷実行部、１８：スキャン実行部、２０：無線ＬＡＮインターフェース、２２：ＮＦＣインターフェース、３０：制御部、３２：ＣＰＵ、３４：メモリ、５０：携帯端末、６０：無線ＬＡＮインターフェース、６２：ＮＦＣインターフェース、７０：制御部、７２：ＣＰＵ、７４：メモリ、１００：ウェブサーバ、Ｄ１，Ｄ２：ウェブページデータ

Claims (9)

1. 通信装置であって、
   ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式の無線通信を実行するための第１のインターフェースと、
   制御部と、を備え、
   前記制御部は、
   前記通信装置で発生しているエラーに関係する関係情報を記憶するメモリと、
   前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第１のインターフェースを介した第１の接続が携帯端末と確立される場合に、前記メモリ内の前記関係情報を前記第１のインターフェースに供給し、前記第１のインターフェースに第２の動作を実行させることによって、前記第１の接続を利用して、前記携帯端末から要求を受信しなくても、前記関係情報を前記携帯端末に送信する第１の送信制御部であって、前記第２の動作は、前記第１のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信するクライアントの動作である、第１の送信制御部と、
   前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第１のインターフェースを介した第２の接続が前記携帯端末と確立される場合に、前記第１のインターフェースに第１の動作を実行させることによって、前記第２の接続を利用して、前記携帯端末から特定要求を受信する受信制御部であって、前記第１の動作は、前記第１のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給するサーバの動作である、受信制御部と、
   前記特定要求が受信されることに応じて、前記第１のインターフェースに前記第２の動作を実行させることによって、前記第２の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第２の送信制御部と、
   を備える通信装置。
2. 前記クライアントの動作及び前記サーバの動作は、前記ＮＦＣ規格のＰ２Ｐ（Peer to Peerの略）モードに従った動作である、請求項１に記載の通信装置。
3. 前記第１の動作は、前記ＮＦＣ規格のＳＮＥＰ（Simple NDEF （NFC Data Exchange Formatの略） Exchange Protocolの略）で定められているサーバの動作であり、
   前記第２の動作は、前記ＮＦＣ規格の前記ＳＮＥＰで定められているクライアントの動作である、請求項１に記載の通信装置。
4. 前記制御部は、さらに、
   前記通信装置の状態が前記非エラー状態から前記エラー状態に移行する場合に、前記第１のインターフェースの動作モードを第１のモードから第２のモードに移行させ、前記通信装置の状態が前記エラー状態から前記非エラー状態に移行する場合に、前記第１のインターフェースの前記動作モードを前記第２のモードから前記第１のモードに移行させるモード制御部を備え、
   前記第１のモードは、前記第１の動作を前記第１のインターフェースに実行させ、その後、前記第１のインターフェースに前記第２の動作を実行させるためのモードであり、
   前記第２のモードは、前記第１の動作と前記第２の動作とのうちの前記第２の動作のみを前記第１のインターフェースに実行させるためのモードである、請求項１から３のいずれか一項に記載の通信装置。
5. 前記制御部は、さらに、
   前記通信装置の状態が前記非エラー状態から前記エラー状態に移行する場合に、前記第１のインターフェースの前記動作モードを前記第１のモードから前記第２のモードに移行させる前に、前記第１のインターフェースの機能であって、外部機器との接続を確立するための前記機能を停止させるためのコマンドを前記第１のインターフェースに供給する第１の供給部と、
   前記通信装置の状態が前記エラー状態から前記非エラー状態に移行する場合に、前記第１のインターフェースの前記動作モードを前記第２のモードから前記第１のモードに移行させる前に、前記コマンドを前記第１のインターフェースに供給する第２の供給部と、を備える、請求項４に記載の通信装置。
6. 前記関係情報は、前記携帯端末が前記エラー状態に関係するウェブページを表示するためのＵＲＬ（Uniform Resource Locatorの略）を含む、請求項１から５のいずれか一項に記載の通信装置。
7. 前記通信装置は、さらに、
   前記ＮＦＣ方式とは異なる通信方式で無線通信を実行するための第２のインターフェースを備え、
   前記特定情報は、前記通信装置と前記携帯端末との間で前記第２のインターフェースを介した無線通信を実行するための無線プロファイルを含む、請求項１から６のいずれか一項に記載の通信装置。
8. 前記第１の送信制御部は、
   前記通信装置で第１種のエラーが発生していることに起因して、前記通信装置の状態が前記エラー状態である状況において、前記第１の接続が確立される場合に、前記第１の接続を利用して、前記第１種のエラーに起因する前記エラー状態に関係する第１種の前記関係情報を前記携帯端末に送信し、
   前記通信装置で前記第１種のエラーとは異なる第２種のエラーが発生していることに起因して、前記通信装置の状態が前記エラー状態である状況において、前記第１の接続が確立される場合に、前記第１の接続を利用して、前記第２種のエラーに起因する前記エラー状態に関係する第２種の前記関係情報であって、前記第１種の関係情報とは異なる前記第２種の関係情報を前記携帯端末に送信する、請求項１から７のいずれか一項に記載の通信装置。
9. 通信装置のためのコンピュータプログラムであって、
   前記通信装置は、
   プロセッサと、
   前記通信装置で発生しているエラーに関係する関係情報を記憶するメモリと、
   ＮＦＣ（Near Field Communicationの略）規格に従った通信方式であるＮＦＣ方式の無線通信を実行するための第１のインターフェースと、を備え、
   前記コンピュータプログラムは、前記プロセッサに、以下の各処理、即ち、
   前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第１のインターフェースを介した第１の接続が携帯端末と確立される場合に、前記メモリ内の前記関係情報を前記第１のインターフェースに供給し、前記第１のインターフェースに第２の動作を実行させることによって、前記第１の接続を利用して、前記携帯端末から要求を受信しなくても、前記関係情報を前記携帯端末に送信する第１の送信制御処理であって、前記第２の動作は、前記第１のインターフェースが、前記プロセッサから取得する情報を、前記携帯端末に送信するクライアントの動作である、第１の送信制御処理と、
   前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第１のインターフェースを介した第２の接続が前記携帯端末と確立される場合に、前記第１のインターフェースに第１の動作を実行させることによって、前記第２の接続を利用して、前記携帯端末から特定要求を受信する受信制御処理であって、前記第１の動作は、前記第１のインターフェースが、前記携帯端末から受信する情報を、前記プロセッサに供給するサーバの動作である、受信制御処理と、
   前記特定要求が受信されることに応じて、前記第１のインターフェースに前記第２の動作を実行させることによって、前記第２の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第２の送信制御処理と、
   を実行させるコンピュータプログラム。

Images