JP2023146162A - 第１の通信装置、第１の通信装置のためのコンピュータプログラム、及び、第２の通信装置のためのアプリケーションプログラム - Google Patents

Abstract

【課題】従来とは異なる手法を利用して、通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立するための技術を提供すること。【解決手段】第１の通信装置は、第２の通信装置から、第１の通信装置に割り当てられているＭＡＣアドレスを送信先アドレスとして含まない第１の認証要求を受信する場合に、第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像を出力部に出力させる。第１の通信装置は、出力画像が出力された後に、第２の通信装置から第１のキーが利用された第２の認証要求を受信する場合に、接続情報を第２の通信装置と通信する。接続情報は、第１の通信装置又は第２の通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立するための情報である。【選択図】図４

Description

本明細書は、通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立するための技術を開示する。

特許文献１には、ＤＰＰ（Device Provisioning Protocolの略）に従って、端末を利用してプリンタとＡＰ（Access Pointの略）との間にＷｉ－Ｆｉ接続を確立させる技術が開示されている。プリンタは、端末から所定のＳＳＩＤ（Service Set Identifierの略）を含むＰｒｏｂｅ要求を受信する場合に、プリンタの公開鍵をコード化することによって得られるＱＲコード（登録商標）を表示する。端末は、当該ＱＲコードを読み取ることによって、公開鍵を取得する。これにより、端末は、公開鍵を利用して、プリンタとＡＰとの間にＷｉ－Ｆｉ接続を確立させる。

特開２０１９－１８００３６号公報

本明細書では、従来とは異なる手法を利用して、通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立するための技術を提供する。

本明細書に開示される第１の通信装置は、Ｗｉ－Ｆｉ規格に従った無線通信を実行するための第１の無線インターフェースと、出力部と、第２の通信装置から、前記第１の無線インターフェースを介して、ＤＰＰ（Device Provisioning Protocolの略）に従った第１の認証要求を受信する第１の認証要求受信部であって、前記第１の認証要求は、前記第１の無線インターフェースに割り当てられているＭＡＣアドレスを送信先アドレスとして含まない、前記第１の認証要求受信部と、前記第２の通信装置から前記第１の認証要求が受信される場合に、前記第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像を前記出力部に出力させる出力制御部と、前記出力画像が出力された後に、前記第２の通信装置から、前記第１の無線インターフェースを介して、前記ＤＰＰに従った第２の認証要求であって、前記第１のキーが利用された前記第２の認証要求を受信する第２の認証要求受信部と、前記第２の通信装置から前記第２の認証要求が受信される場合に、前記第１の無線インターフェースを介して、前記ＤＰＰに従った接続情報を前記第２の通信装置と通信する接続情報通信部であって、前記接続情報は、前記第１の通信装置又は前記第２の通信装置と外部装置との間に前記Ｗｉ－Ｆｉ規格に従った無線接続を確立するための情報である、前記接続情報通信部と、を備えてもよい。

上記の構成によれば、第１の通信装置は、第２の通信装置から、第１の通信装置のＭＡＣアドレスを送信先アドレスとして含まない第１の認証要求を受信する場合に、出力画像を出力する。このために、本技術によると、従来とは異なる手法を利用して、第１の通信装置又は第２の通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立することができる。

本明細書では、第２の通信装置のためのアプリケーションプログラムも開示する。前記第２の通信装置は、Ｗｉ－Ｆｉ規格に従った無線通信を実行するための第２の無線インターフェースと、カメラと、コンピュータと、を備えてもよい。前記アプリケーションプログラムは、前記コンピュータを、以下の各部、即ち、前記第２の無線インターフェースを介して、ＤＰＰ（Device Provisioning Protocolの略）に従った第１の認証要求を送信する第１の認証要求送信部であって、前記第１の認証要求は、第１の通信装置の第１の無線インターフェースであって、Ｗｉ－Ｆｉ規格に従った無線通信を実行するための前記第１の無線インターフェースに割り当てられているＭＡＣアドレスを送信先アドレスとして含まない、前記第１の認証要求送信部と、前記第１の認証要求が前記第１の通信装置に送信されることに応じて、前記第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像が前記第１の通信装置によって出力され、かつ、前記第１の出力画像が前記カメラによって撮影される場合に、前記第１のキーを取得する取得部と、前記第１のキーが取得される場合に、前記第２の無線インターフェースを介して、前記ＤＰＰに従った第２の認証要求であって、前記第１のキーが利用される前記第２の認証要求を前記第１の通信装置に送信する第２の認証要求送信部と、前記第２の認証要求が前記第１の通信装置に送信される場合に、前記第２の無線インターフェースを介して、前記ＤＰＰに従った接続情報を前記第１の通信装置と通信する接続情報通信部であって、前記接続情報は、前記第１の通信装置又は前記第２の通信装置と外部装置との間に前記Ｗｉ－Ｆｉ規格に従った無線接続を確立するための情報である、前記接続情報通信部と、として機能させてもよい。

上記の構成によれば、第２の通信装置は、第１の通信装置のＭＡＣアドレスを送信先アドレスとして含まない第１の認証要求を第１の通信装置に送信する。これにより、出力画像が第１の通信装置によって出力されるので、第２の通信装置は、第１の出力画像を撮影することによって、第１のキーを取得することができる。このために、本技術によると、従来とは異なる手法を利用して、第１の通信装置又は第２の通信装置と外部装置との間にＷｉ－Ｆｉ規格に従った無線接続を確立することができる。

第１の通信装置を実現するためのコンピュータプログラム、及び、当該コンピュータプログラムを記憶するコンピュータ可読記憶媒体も新規で有用である。第１の通信装置によって実行される方法も新規で有用である。上記のアプリケーションプログラムを記憶するコンピュータ可読記憶媒体、当該アプリケーションプログラムによって実現される第２の通信装置そのもの、及び、第２の通信装置によって実行される方法も新規で有用である。また、第１の通信装置と第２の通信装置とを備える通信システムも新規で有用である。

通信システムの構成を示す。 プリンタのＱＲコード表示処理のフローチャートを示す。 プリンタの検証表示処理のフローチャートを示す。 第１実施例のケースＡのシーケンス図を示す。 第１実施例のケースＢのシーケンス図を示す。 第２実施例のシーケンス図を示す。 第３実施例のシーケンス図を示す。 第４実施例のシーケンス図を示す。

（第１実施例）
（通信システム２の構成；図１）
図１に示されるように、通信システム２は、プリンタ１０と携帯端末１００とを備える。本実施例では、携帯端末１００を利用して、プリンタ１０とＡＰ（Access Pointの略）６との間にＷｉ－Ｆｉ規格に従った無線接続（以下では「Ｗｉ－Ｆｉ接続」と記載する）を確立させる。以下では、携帯端末１００のことを「端末１００」と簡単に記載する。

（プリンタ１０の構成）
プリンタ１０は、印刷機能を実行可能な周辺装置（例えば端末１００の周辺装置）である。変形例では、プリンタ１０は、印刷機能に加えて、スキャン機能、ＦＡＸ機能等を実行可能な多機能機であってもよい。プリンタ１０は、操作部１２と、表示部１４と、無線ＬＡＮ（Local Area Networkの略）インターフェース１６と、印刷実行部１８と、制御部３０と、を備える。各部１２～３０は、バス線（符号省略）に接続されている。以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。

操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示をプリンタ１０に入力することができる。表示部１４は、様々な情報を表示させるディスプレイである。表示部１４は、いわゆるタッチパネル（即ちユーザの操作を受け付ける操作部）としても機能する。印刷実行部１８は、インクジェット方式、レーザ方式等の印刷機構を備える。

無線ＬＡＮＩ／Ｆ１６は、Ｗｉ－Ｆｉ規格に従ったＷｉ－Ｆｉ通信を実行するための無線Ｉ／Ｆである。無線ＬＡＮＩ／Ｆ１６には、ＭＡＣアドレスＭｐが割り当てられている。Ｗｉ－Ｆｉ規格は、例えば、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.の略）の８０２．１１の規格、及び、それに準ずる規格（例えば８０２．１１ａ，１１ｂ，１１ｇ，１１ｎ、１１ａｃ等）に従って、無線通信を実行するための無線通信規格である。特に、無線ＬＡＮＩ／Ｆ１６は、Ｗｉ－Ｆｉ Ａｌｌｉａｎｃｅによって策定されたＤＰＰ（Device Provisioning Protocolの略）をサポートしている。ＤＰＰの詳細は、Ｗｉ－Ｆｉ Ａｌｌｉａｎｃｅによって作成された規格書「Wi-Fi Easy Connect Specification Version 2.0」に記述されている。

制御部３０は、ＣＰＵ３２とメモリ３４とを備える。ＣＰＵ３２は、メモリ３４に格納されているプログラム３６に従って、様々な処理を実行する。メモリ３４は、揮発性メモリ、不揮発性メモリ等によって構成される。

メモリ３４は、プログラム３６に加えて、秘密鍵ＳＫｐ１と、公開鍵ＰＫｐ２と、公開鍵ＰＫｐ２に対応する秘密鍵ＳＫｐ２と、ＱＲコード（登録商標）と、を予め記憶している。秘密鍵ＳＫｐ１は、端末１００に記憶されている公開鍵ＰＫｔ１に対応する秘密鍵である。秘密鍵ＳＫｐ１は、プリンタ１０と端末１００との間で実行される１回目のＡｕｔｈｅｎｔｉｃａｔｉｏｎ（以下では「Ａｕｔｈ」と記載する）で利用される。公開鍵ＰＫｐ２及び秘密鍵ＳＫｐ２は、プリンタ１０と端末１００との間で実行される２回目のＡｕｔｈで利用される。ＱＲコードは、公開鍵ＰＫｐ２と無線ＬＡＮＩ／Ｆ１６のＭＡＣアドレスＭｐとがコード化されることによって得られるコード画像である。ＱＲコードは、１回目のＡｕｔｈが実行されることに応じて、表示部１４に表示される。本実施例では、プリンタ１０の出荷時からＱＲコードがメモリ３４に予め記憶されているが、変形例では、ＱＲコードが表示される際に、ＱＲコードが生成されてもよい。

（端末１００の構成）
端末１００は、携帯電話（例えばスマートフォン）、ＰＤＡ、タブレットＰＣ等の可搬型の端末装置である。変形例では、端末１００は、据置型のＰＣ、ノートＰＣ等であってもよい。端末１００は、操作部１１２と、表示部１１４と、無線ＬＡＮＩ／Ｆ１１６と、カメラ１１８と、制御部１３０と、を備える。各部１１２～１３０は、バス線（符号省略）に接続されている。

操作部１１２は、複数のキーを備える。ユーザは、操作部１１２を操作することによって、様々な指示を端末１００に入力することができる。表示部１１４は、様々な情報を表示させるディスプレイである。表示部１１４は、いわゆるタッチパネル（即ちユーザの操作を受け付ける操作部）としても機能する。無線ＬＡＮＩ／Ｆ１１６は、プリンタ１０の無線ＬＡＮＩ／Ｆ１６と同様である。即ち、無線ＬＡＮＩ／Ｆ１１６は、ＤＰＰ方式をサポートしている。カメラ１１８は、物体を撮影するためのデバイスである。本実施例では、カメラ１１８は、プリンタ１０に表示されるＱＲコードを撮影するために利用される。

制御部１３０は、ＣＰＵ１３２とメモリ１３４とを備える。ＣＰＵ１３２は、メモリ１３４に格納されているプログラム１３６，１３８に従って、様々な処理を実行する。メモリ１３４は、揮発性メモリ、不揮発性メモリ等によって構成される。

ＯＳ（Operating Systemの略）プログラム１３６は、端末１００の基本的な動作を実現するためのプログラムである。アプリケーション１３８は、端末１００とＡＰ６との間にＷｉ－Ｆｉ接続を確立させたり、プリンタ１０とＡＰ６との間にＷｉ－Ｆｉ接続を確立させたりするためのプログラムである。以下では、ＯＳプログラム１３６、アプリケーション１３８のことを、それぞれ、「ＯＳ１３６」、「アプリ１３８」と記載する。アプリ１３８は、例えば、プリンタ１０のベンダによって提供されるインターネット上のサーバ（図示省略）又はＯＳ１３６のベンダによって提供されるインターネット上のサーバ（図示省略）から端末１００にインストールされる。アプリ１３８は、ＯＳ１３６に指示を供給することによって、ＯＳ１３６に様々な処理を実行させたり、ＯＳ１３６を介して他のアプリに様々な処理を実行させたりすることができる。従って、アプリ１３８からの指示に応じてＯＳ１３６又は他のアプリによって実行される後述の各処理は、アプリ１３８によって実現される処理である（即ちアプリ１３８が当該処理を実行する実行部としてＣＰＵ１３２を機能させる）と言える。

（プリンタ１０のＱＲコード表示処理：図２）
図２を参照して、プリンタ１０のＣＰＵ３２によって実行されるＱＲコード表示処理を説明する。プリンタ１０の電源がＯＮされることをトリガとして、図２の処理が実行される。

Ｓ１０において、ＣＰＵ３２は、ＡＰ情報がメモリ３４に記憶済みであるのか否かを判断する。ＡＰ情報は、ＡＰ６とのＷｉ－Ｆｉ接続を確立するための情報である。例えば、ＡＰ６のＳＳＩＤ（Service Set Identifierの略）及びパスワードがユーザによってプリンタ１０に入力される場合には、当該ＳＳＩＤ及び当該パスワードを含むＡＰ情報がメモリ３４に記憶される。また、後述のＤＰＰに従ったプリンタ用Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｂｊｅｃｔ（以下では「プリンタ用ＣＯ」と記載する）が端末１００からプリンタ１０に送信される場合には、当該プリンタ用ＣＯを含むＡＰ情報がメモリ３４に記憶される。ＣＰＵ３２は、ＡＰ情報がメモリ３４に記憶済みであると判断する場合（Ｓ１０でＹＥＳ）に、Ｓ５０に進み、この場合、後述のＳ２０～Ｓ４２の処理を実行しない。このように、プリンタ１０は、ＡＰ情報を記憶している場合に、ＱＲコードを表示するための処理（例えば後述のＡｕｔｈ Ｒｅｑの監視、検証等）を実行しない。このために、不要なＡＰ情報の再設定がプリンタ１０に実行されるのを抑制することができる。一方、ＣＰＵ３２は、ＡＰ情報がメモリ３４に記憶済みでないと判断する場合（Ｓ１０でＮＯ）に、Ｓ１２に進む。

Ｓ１２において、ＣＰＵ３２は、プリンタ１０の状態を、ＤＰＰに従った処理を実行不可能な状態（以下では「ＤＰＰＯＦＦ状態」と記載する）から、ＤＰＰに従った処理を実行可能な状態（以下では「ＤＰＰＯＮ状態」と記載する）に移行させる。ＤＰＰＯＦＦ状態は、端末１００からＡｕｔｈ Ｒｅｑｕｅｓｔを受信することに応じて、Ａｕｔｈ Ｒｅｓｐｏｎｓｅを送信不可能な状態である。以下では、Ｒｅｑｕｅｓｔ、Ｒｅｓｐｏｎｓｅのことを、それぞれ、「Ｒｅｑ」、「Ｒｅｓ」と記載する。ＤＰＰＯＮ状態は、端末１００からＡｕｔｈ Ｒｅｑを受信することに応じて、Ａｕｔｈ Ｒｅｓを送信可能な状態である。

Ｓ２０において、ＣＰＵ３２は、プリンタ１０の電源がＯＮされてから第１の所定時間Ｔ１が経過することを監視する。ＣＰＵ３２は、Ｔ１が経過する場合（Ｓ２０でＹＥＳ）に、Ｓ６２に進み、Ｔ１が経過していない場合（Ｓ２０でＮＯ）に、Ｓ３０に進む。

Ｓ３０において、ＣＰＵ３２は、ブロードキャストのＡｕｔｈ Ｒｅｑを受信することを監視する。ブロードキャストのＡｕｔｈ Ｒｅｑでは、送信先アドレスとしてプリンタ１０のＭＡＣアドレスＭｐが指定されておらず、例えば、送信先アドレスとしてブロードキャストを示す所定のアドレス（例えばff:ff:ff:ff:ff:ff）が指定されている。ＣＰＵ３２は、端末１００から当該Ａｕｔｈ Ｒｅｑを受信する場合（Ｓ３０でＹＥＳ）に、Ｓ４０に進み、端末１００から当該Ａｕｔｈ Ｒｅｑを受信しない場合（Ｓ３０でＮＯ）に、Ｓ２０の監視に戻る。

Ｓ４０において、ＣＰＵ３２は、当該Ａｕｔｈ Ｒｅｑの検証を実行してＱＲコードを表示するための検証表示処理を実行する。

Ｓ４２において、ＣＰＵ３２は、Ｓ４０でＱＲコードが表示されたのか否かを判断する。ＣＰＵ３２は、Ｓ４０でＱＲコードが表示された場合（Ｓ４２でＹＥＳ）に、図２の処理を終了し、Ｓ４０でＱＲコードが表示されなかった場合（Ｓ４２でＮＯ）に、Ｓ２０の監視に戻る。

Ｓ５０において、ＣＰＵ３２は、ＤＰＰＯＮ操作が操作部１２又は表示部１４に実行されることを監視する。ＤＰＰＯＮ操作は、プリンタ１０の状態をＤＰＰＯＦＦ状態からＤＰＰＯＮ状態に移行させるための操作である。ＣＰＵ３２は、ＤＰＰＯＮ操作が実行される場合（Ｓ５０でＹＥＳ）に、Ｓ５２に進み、ＤＰＰＯＮ操作が実行されない場合（Ｓ５０でＮＯ）に、Ｓ５０の監視を続ける。

Ｓ５２は、Ｓ１２と同様である。Ｓ６０において、ＣＰＵ３２は、Ｓ５０でＤＰＰＯＮ操作が実行されてから第２の所定時間Ｔ２が経過することを監視する。ＣＰＵ３２は、Ｔ２が経過する場合（Ｓ６０でＹＥＳ）に、Ｓ６２に進み、Ｔ２が経過していない場合（Ｓ６０でＮＯ）に、Ｓ７０に進む。

Ｓ６２において、ＣＰＵ３２は、プリンタ１０の状態をＤＰＰＯＮ状態からＤＰＰＯＦＦ状態に移行させる。このように、プリンタ１０は、電源ＯＮ操作が実行されてからＡｕｔｈ Ｒｅｑを受信することなくＴ１が経過する場合（Ｓ２０でＹＥＳ）に、ＤＰＰＯＮ状態からＤＰＰＯＦＦ状態に移行し（Ｓ６２）、ＱＲコードを表示しない。また、プリンタ１０は、ＤＰＰＯＮ操作が実行されてからＡｕｔｈ Ｒｅｑを受信することなくＴ２が経過する場合（Ｓ６０でＹＥＳ）に、ＤＰＰＯＮ状態からＤＰＰＯＦＦ状態に移行し（Ｓ６２）、ＱＲコードを表示しない。従って、不要なＡＰ情報の再設定がプリンタ１０に実行されるのを抑制することができる。ＣＰＵ３２は、Ｓ６２が終了すると、Ｓ５０の監視に戻る。

Ｓ７０、Ｓ８０、Ｓ８２は、それぞれ、Ｓ３０、Ｓ４０、Ｓ４２と同様である。ＣＰＵ３２は、Ｓ８０でＱＲコードが表示された場合（Ｓ８２でＹＥＳ）に、図２の処理を終了し、Ｓ８０でＱＲコードが表示されなかった場合（Ｓ８２でＮＯ）に、Ｓ５０の監視に戻る。

（検証表示処理：図３）
図３を参照して、図２のＳ４０又はＳ８０で実行される検証表示処理を説明する。Ｓ１００において、ＣＰＵ３２は、Ｓ３０又はＳ７０で受信されたＡｕｔｈ Ｒｅｑの検証が成功したのか否かを判断する。当該Ａｕｔｈ Ｒｅｑは、検証用データを含み、当該検証用データは、公開鍵が利用されることによって生成される。当該公開鍵は、当該Ａｕｔｈ Ｒｅｑの送信元のデバイス（例えば端末１００）に予め記憶されていてもよいし、ＤＰＰの規格書に記載されているＰＫＥＸを利用して当該デバイスによって生成されてもよい。ＣＰＵ３２は、メモリ３４内の秘密鍵ＳＫｐ１を利用して上記の検証用データの検証を実行する。

Ｓ３０又はＳ７０で受信されたＡｕｔｈ Ｒｅｑが端末１００から送信されたものである場合には、当該Ａｕｔｈ Ｒｅｑに含まれる検証用データは、端末１００に記憶されている公開鍵ＰＫｔ１であって、秘密鍵ＳＫｐ１に対応する公開鍵ＰＫｔ１が利用されることによって生成される。この場合、ＣＰＵ３２は、検証用データの検証に成功し（Ｓ１００でＹＥＳ）、Ｓ１１０に進む。一方、Ｓ３０又はＳ７０で受信されたＡｕｔｈ Ｒｅｑが端末１００以外のデバイスから送信されたものである場合には、当該Ａｕｔｈ Ｒｅｑに含まれる検証用データは、公開鍵ＰＫｔ１とは異なる公開鍵が利用されることによって生成される。この場合、ＣＰＵ３２は、検証用データの検証に失敗し（Ｓ１００でＮＯ）、Ｓ１１０を実行することなく（即ちＱＲコードを表示することなく）、図３の処理を終了する。

Ｓ１１０において、ＣＰＵ３２は、Ａｕｔｈ Ｒｅｓを端末１００に送信することなく、メモリ３４に予め記憶されているＱＲコードを表示部１４に表示させる。Ｓ１１０が終了すると、図３の処理が終了する。

（具体的なケース：図４及び図５）
図４及び図５を参照して、図２及び図３の処理によって実現される具体的なケースを説明する。以下では、理解の容易化のために、各デバイスのＣＰＵ（例えばＣＰＵ３２等）が実行する動作を、ＣＰＵを主体として記載せずに、各デバイス（例えばプリンタ１０、端末１００）を主体として記載する。また、以下の各通信は、無線ＬＡＮＩ／Ｆ１６又は１１６を介して実行される。従って、以下の各通信を説明する際に、「無線ＬＡＮＩ／Ｆ１６又は１１６を介して」という記載を省略する。

（ケースＡ：図４）
まず、図４を参照して、ケースＡを説明する。図４の初期状態では、端末１００がＡＰ６とのＷｉ－Ｆｉ接続を確立している。従って、端末１００は、ＡＰ６とのＷｉ－Ｆｉ接続を確立するためのＡＰ情報を記憶している。例えば、ＡＰ６のＳＳＩＤ及びパスワードがユーザによって端末１００に入力済みである場合には、当該ＳＳＩＤ及び当該パスワードを含むＡＰ情報が端末１００に記憶される。また、ＤＰＰに従って端末１００とＡＰ６との間にＷｉ－Ｆｉ接続が確立されている場合には、ＤＰＰに従ったＡＰ情報（例えば端末用Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｂｊｅｃｔ）が端末１００に記憶される。なお、プリンタ１０は、例えば、出荷された後に最初に電源がＯＮされる状況のように、ＡＰ情報をまだ記憶していない。

プリンタ１０は、Ｔ１０において、ユーザから電源ＯＮ操作を受け付ける（図２の処理のトリガ）。この場合、プリンタ１０は、Ｔ１２において、ＤＰＰＯＦＦ状態からＤＰＰＯＮ状態に移行する（Ｓ１０でＹＥＳ、Ｓ１２）。

端末１００は、Ｔ２０において、ユーザからアプリ１３８を起動させるための操作を受け付ける。この場合、端末１００は、アプリ１３８を起動させる。これにより、端末１００によって実行される以降の各処理は、アプリ１３８が起点となって実行される。即ち、端末１００によって実行される以降の各処理は、アプリ１３８によって実現される処理である（即ちアプリ１３８が当該処理を実行する実行部としてＣＰＵ１３２を機能させる）。

端末１００は、Ｔ２２において、ユーザからＤＰＰ操作を受け付ける。ＤＰＰ操作は、アプリ１３８によって表示されるホーム画面（図示省略）に含まれるＤＰＰボタンを選択する操作である。これにより、端末１００は、ＤＰＰに従ってプリンタ１０とＡＰ６との間にＷｉ－Ｆｉ接続を確立するための処理を開始する。

端末１００は、Ｔ２２において、ＤＰＰ操作を受け付けると、Ａｕｔｈ Ｒｅｑを生成する。Ａｕｔｈ Ｒｅｑは、検証用データの検証を要求する信号である。具体的には、アプリ１３８は、公開鍵ＰＫｔ１を予め含んでいる。端末１００は、公開鍵ＰＫｔ１を利用して検証用データを生成し、さらに、ブロードキャストを示すアドレスを生成する。そして、端末１００は、当該検証用データを含むと共に、当該アドレスを送信先アドレスとして含むＡｕｔｈ Ｒｅｑを生成する。そして、端末１００は、Ｔ３０において、生成済みのブロードキャストのＡｕｔｈ Ｒｅｑ（即ち特定のデバイスのＭＡＣアドレスが指定されていないＡｕｔｈ Ｒｅｑ）を送信する。

上記のＴ３０の処理は、端末１００のアプリ１３８がＡｕｔｈ Ｒｅｑを生成して当該Ａｕｔｈ Ｒｅｑの送信をＯＳ１３６に指示することによって実現される。これにより、ＯＳ１３６は、当該Ａｕｔｈ Ｒｅｑの送信を含むＤＰＰに従った処理を実行する。ここで、アプリ１３８は、Ａｕｔｈ Ｒｅｑの送信をＯＳ１３６に指示してから所定時間が経過すると、ＤＰＰに従った処理のキャンセルをＯＳ１３６に指示する。なお、Ａｕｔｈ Ｒｅｑの送信が終了した後（即ちプリンタ１０がＱＲコードを表示した後）に、ＤＰＰに従った処理がキャンセルされるように、当該所定時間が予め設定されている。これにより、ＯＳ１３６は、ＤＰＰに従った処理をキャンセルするので、アプリ１３８からの指示に従って、後述の２回目のＡｕｔｈを適切に実行することができる。

プリンタ１０は、Ｔ１２において、ＤＰＰＯＮ状態に移行しているので、Ｔ３０において、端末１００からＡｕｔｈ Ｒｅｑを受信することができる（Ｓ２０でＹＥＳ）。この場合、プリンタ１０は、秘密鍵ＳＫｐ１を利用して、当該Ａｕｔｈ Ｒｅｑに含まれる検証用データの検証を実行する（図３のＳ１００）。秘密鍵ＳＫｐ１は、検証用データの生成に利用された公開鍵ＰＫｔ１に対応する。このため、Ｔ３２において、検証が成功する（Ｓ１００でＹＥＳ）。上記のＴ３０及びＴ３２の各処理は、ＤＰＰのＡｕｔｈに対応し、特に本実施例では、１回目のＡｕｔｈに対応する。なお、変形例では、プリンタ１０は、秘密鍵ＳＫｐ１に代えて、他の情報を利用して検証を実行してもよい。例えば、プリンタ１０は、端末１００の公開鍵ＰＫｔ１と同じ情報を記憶しておき、公開鍵ＰＫｔ１を利用して検証を実行してもよい。

プリンタ１０は、Ａｕｔｈ Ｒｅｓを端末１００に送信することなく、Ｔ３４において、メモリ３４に記憶されているＱＲコードを表示する（Ｓ１１０）。このように、プリンタ１０がＡｕｔｈ Ｒｅｓを送信しないので、プリンタ１０の処理負荷を低減させることができる。

プリンタ１０がＡｕｔｈ Ｒｅｓを送信しないので、以下の効果が得られる。例えば、端末１００の周囲において、プリンタ１０を含む複数個のプリンタが存在する状況を想定する。そして、端末１００のユーザは、複数個のプリンタのうちのプリンタ１０のみとＡＰ６との間にＷｉ－Ｆｉ接続を確立させることを望んでいる。仮に、各プリンタがＡｕｔｈ Ｒｅｓを端末１００に送信する構成を採用すると、端末１００が、Ｔ３０においてＡｕｔｈ Ｒｅｑを送信することに応じて、プリンタ１０とは異なるプリンタからＡｕｔｈ Ｒｅｓを受信し得る。この場合、端末１００と当該異なるプリンタとの間でＤＰＰに従った処理が進んでしまうので、例えば、端末１００が、ＡＰ６とのＷｉ－Ｆｉ接続を確立するためのＡＰ情報を当該異なるプリンタに送信し得る。この結果、ユーザが意図していないプリンタとＡＰ６との間にＷｉ－Ｆｉ接続が確立されてしまう。これに対し、本実施例では、各プリンタがＡｕｔｈ Ｒｅｓを送信しない構成を採用しているので、端末１００と上記の異なるプリンタとの間でＤＰＰに従った処理が進んでしまうことを抑制することができる。この結果、ユーザが意図していないプリンタとＡＰ６との間にＷｉ－Ｆｉ接続が確立されることを抑制することができる。

特に、端末１００は、Ｔ３０において、複数個のチャネル（即ち複数個の周波数帯）のうちの或るチャネルを利用して、Ａｕｔｈ Ｒｅｑを送信する。端末１００は、当該Ａｕｔｈ Ｒｅｑに対する応答としてＡｕｔｈ Ｒｅｓを受信しない場合には、複数個のチャネルのうちの他の各チャネルを順次利用して、Ａｕｔｈ Ｒｅｑを順次送信する。このため、複数個のプリンタのそれぞれが異なるチャネルでＡｕｔｈ Ｒｅｑの受信を待ち受けている場合でも、複数個のプリンタのそれぞれにＱＲコードを表示させることができる。従って、ＱＲコードをプリンタ１０に適切に表示させることができる。

また、本実施例では、ユーザがプリンタに表示されるＱＲコードを端末１００に撮影させる構成を採用しているので、仮に、上記の複数個のプリンタのそれぞれにＱＲコードが表示されても、ユーザは、上記の複数個のプリンタのうちのプリンタ１０に表示されるＱＲコードのみを端末１００に撮影させれば、プリンタ１０とＡＰ６との間にＷｉ－Ｆｉ接続を適切に確立させることができる。

また、プリンタ１０は、端末１００から公開鍵ＰＫｔ１が利用されたＡｕｔｈ Ｒｅｑを受信し、Ａｕｔｈ Ｒｅｑの検証が成功することを条件としてＱＲコードを表示する。仮に、プリンタ１０がＡｕｔｈ Ｒｅｑの検証に失敗してもＱＲコードを表示する構成を採用すると、プリンタ１０は、公開鍵ＰＫｔ１を有さないデバイス（即ちアプリ１３８を有さないデバイス）からＡｕｔｈ Ｒｅｑを受信しても、プリンタ１０の公開鍵ＰＫｐ２及びＭＡＣアドレスＭｐを表わすＱＲコードを表示することになる。このため、プリンタ１０の公開鍵ＰＫｐ２等が第三者によって取得される可能性が高く、セキュリティ面で問題が生じる。これに対して、本実施例では、プリンタ１０がＡｕｔｈ Ｒｅｑの検証に成功することを条件としてＱＲコードを表示する構成を採用しているので、プリンタ１０の公開鍵ＰＫｐ２等が第三者によって取得される可能性が低く、セキュリティが高い。

また、例えば、プリンタ１０を含む複数個のプリンタが存在する環境において、各プリンタがＡｕｔｈ Ｒｅｑの検証に失敗してもＱＲコードを表示する構成を採用することを想定する。この場合、各プリンタは、いずれの端末からＡｕｔｈ Ｒｅｑを受信しても、検証が成功するのか失敗するのかに関わらずＱＲコードを表示する。従って、端末１００のユーザが意図していないプリンタにもＱＲコードが表示され得る。この場合、当該プリンタのユーザがＱＲコードの表示に混乱し得るし、端末１００のユーザがどのプリンタとＡＰとの間にＷｉ－Ｆｉ接続を確立させるべきか混乱し得る。即ち、ユーザの利便性が損なわれ得る。これに対して、本実施例では、プリンタ１０がＡｕｔｈ Ｒｅｑの検証に成功することを条件としてＱＲコードを表示する構成を採用しているので、端末１００のユーザが意図するプリンタ１０（即ちアプリ３８に対応するプリンタ１０）にＱＲコードを表示させることができる。このため、ユーザの利便性が損なわれるのを抑制することができる。

端末１００は、Ｔ３０において、Ａｕｔｈ Ｒｅｑを送信すると、プリンタ１０に表示されたＱＲコードの撮影を促す画面（図示省略）を表示する。このため、端末１００は、Ｔ４０において、ユーザからＱＲコードを撮影するための操作を受け付ける。この場合、端末１００は、ＱＲコードをデコードして、公開鍵ＰＫｐ２及びＭＡＣアドレスＭｐを取得する。上記のＴ３４～Ｔ４２の各処理は、ＤＰＰのＢｏｏｔｓｔｒａｐｐｉｎｇに対応する。

端末１００は、Ｔ５０において、Ａｕｔｈ Ｒｅｑを生成する。具体的には、端末１００は、Ｔ４０で取得された公開鍵ＰＫｐ２を利用して検証用データを生成する。そして、端末１００は、当該検証用データを含むと共に、Ｔ４０で取得されたＭＡＣアドレスＭｐを送信先アドレスとして含むＡｕｔｈ Ｒｅｑを生成する。次いで、端末１００は、生成済みのＡｕｔｈ Ｒｅｑ（即ち特定のデバイスのＭＡＣアドレスが指定されているＡｕｔｈ Ｒｅｑ）をプリンタ１０に送信する。なお、変形例では、Ｔ５０のＡｕｔｈ Ｒｅｑは、ＭＡＣアドレスＭｐを送信先アドレスとして含む代わりに、ブロードキャストを示すアドレスを送信先アドレスとして含んでいてもよい。即ち、Ｔ５０のＡｕｔｈ Ｒｅｑは、ブロードキャストのＡｕｔｈ Ｒｅｑであってもよい。

プリンタ１０は、Ｔ５０において、端末１００からＡｕｔｈ Ｒｅｑを受信すると、秘密鍵ＳＫｐ２を利用して、当該Ａｕｔｈ Ｒｅｑに含まれる検証用データの検証を実行する。秘密鍵ＳＫｐ２は、検証用データの生成に利用された公開鍵ＰＫｐ２に対応する。このため、Ｔ５２において、検証が成功する。この場合、プリンタ１０は、Ｔ５４において、検証成功を示すＡｕｔｈ Ｒｅｓを端末１００に送信する。

端末１００は、Ｔ５４において、プリンタ１０からＡｕｔｈ Ｒｅｓを受信すると、Ｔ５６において、Ａｕｔｈ Ｒｅｓを受信したことを示すＡｕｔｈ Ｃｏｎｆｉｒｍをプリンタ１０に送信する。上記のＴ５０～Ｔ５６の各処理は、ＤＰＰのＡｕｔｈに対応し、特に本実施例では、２回目のＡｕｔｈに対応する。

プリンタ１０は、Ｔ５６において、端末１００からＡｕｔｈ Ｃｏｎｆｉｒｍを受信すると、Ｔ６０において、Ｃｏｎｆｉｇｕｒａｔｉｏｎ（以下では「Ｃｏｎｆｉｇ」と記載する） Ｒｅｑを端末１００に送信する。Ｃｏｎｆｇ Ｒｅｑは、プリンタ用ＣＯの送信を端末１００に要求する信号である。

端末１００は、Ｔ６０において、プリンタ１０からＣｏｎｆｉｇ Ｒｅｑを受信すると、プリンタ用ＣＯを生成する。具体的には、端末１００は、例えば、ＡＰ６のＳＳＩＤ及びパスワードを含むＡＰ情報を記憶している場合には、当該ＳＳＩＤ及び当該パスワードを含むプリンタ用ＣＯを生成する。また、端末１００は、例えば、ＤＰＰに従ったＡＰ情報を記憶している場合には、当該ＡＰ情報に対応するプリンタ用ＣＯを生成する。そして、端末１００は、Ｔ６２において、生成済みのプリンタ用ＣＯを含むＣｏｎｆｉｇ Ｒｅｓをプリンタ１０に送信する。

プリンタ１０は、Ｔ６２において、端末１００からＣｏｎｆｉｇ Ｒｅｓを受信すると、Ｔ６４において、Ｃｏｎｆｉｇ Ｒｅｓに含まれるプリンタ用ＣＯを記憶する。上記のＴ５６～Ｔ６４の各処理は、ＤＰＰのＣｏｎｆｉｇに対応する。

次いで、プリンタ１０は、Ｔ７０において、ＤＰＰのＮｅｔｗｏｒｋ ＡｃｃｅｓｓをＡＰ６と実行する。Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓは、プリンタ用ＣＯに含まれる情報を利用してＡＰ６と通信して、ＡＰ６とのＷｉ－Ｆｉ接続を確立するための処理である。これにより、プリンタ１０とＡＰ６との間にＷｉ－Ｆｉ接続が確立される。この結果、プリンタ１０及び端末１００の双方がＡＰ６によって形成されている無線ネットワークに所属することになる。

上述したように、プリンタ１０は、ＡＰ６とのＷｉ－Ｆｉ接続を確立することができる。このために、プリンタ１０は、端末１００からＡＰ６を介して印刷対象の画像を表わす印刷データを受信して、当該印刷データによって表わされる画像の印刷を実行することができる。

（ケースＢ：図５）
続いて、図５を参照して、ケースＢを説明する。Ｔ１１０及びＴ１１２は、図４のＴ１０及びＴ１２と同様である。

プリンタ１０は、Ｔ１１０の電源ＯＮ操作が実行されてからブロードキャストのＡｕｔｈ Ｒｅｑを受信することなく、第１の所定時間Ｔ１が経過すると、Ｔ１１４において、ＤＰＰＯＮ状態からＤＰＰＯＦＦ状態に移行する（Ｓ２０でＹＥＳ、Ｓ６２）。

その後、プリンタ１０は、Ｔ１２０において、ＤＰＰＯＮ操作を受け付けると、Ｔ１２２において、ＤＰＰＯＦＦ状態からＤＰＰＯＮ状態に移行する（Ｓ５０でＹＥＳ、Ｓ５２）。従って、プリンタ１０は、ＱＲコードを表示するための処理（例えばＡｕｔｈ Ｒｅｑの監視、検証等）を実行することが可能な状態に再び移行することができる。この後の処理は、図４のＴ２０～Ｔ７０と同様である。

（本実施例の効果）
上記の実施例によれば、プリンタ１０は、端末１００から、プリンタ１０のＭＡＣアドレスＭｐを送信先アドレスとして含まないブロードキャストのＡｕｔｈ Ｒｅｑを受信する際（図４のＴ３０）に、ＱＲコードを表示する（Ｔ３４）。このために、プリンタ１０は、従来とは異なる手法を利用して、ＡＰ６とのＷｉ－Ｆｉ接続を確立することができる。

ここで、端末１００が、ブロードキャストのＡｕｔｈ Ｒｅｑを送信することに代えて、所定のＳＳＩＤを送信先ＳＳＩＤとして含むＰｒｏｂｅ Ｒｅｑを送信する比較例を想定する。当該所定のＳＳＩＤは、ＱＲコードをプリンタ１０に表示させるための所定の文字列を含む。従って、プリンタ１０は、端末１００から当該所定のＳＳＩＤを含むＰｒｏｂｅ Ｒｅｑを受信すると、ＱＲコードを表示する。しかしながら、この構成によると、端末１００のＯＳプログラム１３６は、当該所定のＳＳＩＤが実存するＡＰのＳＳＩＤであると認識するので、Ｐｒｏｂｅ Ｒｅｑを送信する前に、当該ＡＰとのＷｉ－Ｆｉ接続を確立してもよいのか否かをユーザに確認するための確認画面を表示し得る。しかしながら、実際にはＡＰが存在しないので、ユーザの混乱を招く可能性がある。これに対し、本実施例によると、端末１００は、所定のＳＳＩＤを含むＰｒｏｂｅ Ｒｅｑではなく、ブロードキャストのＡｕｔｈ Ｒｅｑを送信することによって、ＱＲコードをプリンタ１０に表示させる。このために、ＯＳプログラム１３６が上記の確認画面を表示しない。ユーザの混乱を招き得る確認画面が表示されないので、ユーザの利便性が向上する。

（対応関係）
プリンタ１０、端末１００、ＡＰ６が、それぞれ、「第１の通信装置」、「第２の通信装置」、「外部装置」の一例である。「第１の通信装置」に関する対応関係は以下の通りである。表示部１４、無線ＬＡＮＩ／Ｆ１６が、それぞれ、「出力部」、「第１の無線インターフェース」の一例である。公開鍵ＰＫｐ２、公開鍵ＰＫｔ１が、それぞれ、「第１のキー」、「第２のキー」の一例である。図２のＳ３０又はＳ７０の処理が、「第１の認証要求受信部」によって実行される処理の一例である。Ｓ１１０又はＳ１３０の処理が、「出力制御部」によって実行される処理の一例である。図４のＴ５０の処理、Ｔ６２の処理が、それぞれ、「第２の認証要求受信部」、「接続情報通信部」によって実行される処理の一例である。

「第２の通信装置」に関する対応関係は以下の通りである。無線ＬＡＮＩ／Ｆ１１６が、「第２の無線インターフェース」の一例である。図４のＴ３０の処理、Ｔ４２の処理、Ｔ５０の処理、Ｔ６２の処理が、それぞれ、「第１の認証要求送信部」、「取得部」、「第２の認証要求送信部」、「接続情報通信部」によって実行される処理の一例である。

（第２実施例：図３）
続いて、第２実施例を説明する。本実施例では、図３のＳ１１０の処理が第１実施例とは異なる。ＣＰＵ３２は、Ｓ１００で検証が成功したにも関わらず、Ｓ１１０において、検証が失敗したこと（即ちエラー）を示すＡｕｔｈ Ｒｅｓを端末１００に送信する。そして、ＣＰＵ３２は、ＱＲコードを表示部１４に表示させる。

（具体的なケース：図６）
図６を参照して、本実施例によって実現される具体的なケースを説明する。Ｔ２１０～Ｔ２３２は、図４のＴ１０～Ｔ３２と同様である。プリンタ１０は、Ｔ２３３において、エラーを示すＡｕｔｈ Ｒｅｓを端末１００に送信する（図３のＳ１１０）。従って、端末１００は、Ａｕｔｈ Ｒｅｑの検証が失敗したことを知ることができる。このため、端末１００がＤＰＰに従った処理を終了するので、ユーザは、ＱＲコードの撮影を端末１００に即座に実行させることができる。その後のＴ２３４～Ｔ２７０は、図４のＴ３４～Ｔ７０と同様である。

（第３実施例：図３）
続いて、第２実施例を説明する。本実施例では、図３のＳ１１０の処理が第１及び第２実施例とは異なる。Ｓ１１０において、ＣＰＵ３２は、検証が成功したことを示すＡｕｔｈ Ｒｅｓを端末１００に送信し、端末１００からＡｕｔｈ Ｃｏｎｆｉｒｍを受信する。Ａｕｔｈ Ｃｏｎｆｉｒｍは、Ａｕｔｈ Ｒｅｓを受信したことを示す確認信号である。そして、ＣＰＵ３２は、ＱＲコードを表示部１４に表示させる。

（具体的なケース：図７）
図７を参照して、本実施例によって実現される具体的なケースを説明する。Ｔ３１０～Ｔ３３２は、図４のＴ１０～Ｔ３２と同様である。プリンタ１０は、Ｔ３３３において、成功を示すＡｕｔｈ Ｒｅｓを端末１００に送信する（図３のＳ１１０）。従って、端末１００は、Ａｕｔｈ Ｒｅｑの検証が成功したことを知ることができる。

その後、プリンタ１０は、Ｔ３３４において、端末１００からＡｕｔｈ Ｃｏｎｆｉｒｍを受信する（Ｓ１１０）。この場合、プリンタ１０は、Ｔ３３６において、ＱＲコードを表示する（Ｓ１１０）。このように、本実施例では、ＤＰＰで規定されているＡｕｔｈの全処理が完了した後に、プリンタ１０においてＱＲコードが表示される。

本実施例では、プリンタ１０と端末１００との間で１回目のＡｕｔｈが成功するので、端末１００がＤＰＰに従った処理を継続し得る。これを避けるために、アプリ１３８は、Ａｕｔｈ Ｒｅｑの送信をＯＳ１３６に指示してから所定時間が経過すると、ＤＰＰに従った処理のキャンセルをＯＳ１３６に指示する。なお、Ａｕｔｈ Ｃｏｎｆｉｒｍの送信が終了した後（即ちプリンタ１０がＱＲコードを表示した後）であり、かつ、端末１００が１回目のＡｕｔｈが成功することに応じてＤＰＰに従った処理を完了する前に、ＤＰＰに従った処理がキャンセルされるように、当該所定時間が予め設定されている。これにより、ＯＳ１３６は、ＤＰＰに従った処理をキャンセルするので、１回目のＡｕｔｈが成功することに応じてＤＰＰに従った処理が継続することを抑制することができる。この結果、ＯＳ１３６は、アプリ１３８からの指示に従って、２回目のＡｕｔｈ Ｒｅｑの送信を適切に実行することができる。

本実施例では、Ｔ３３３の処理、Ｔ３３４の処理が、それぞれ、「認証応答送信部」、「認証確認受信部」によって実行される処理の一例である。

（第４実施例：図３）
続いて、第４実施例を説明する。本実施例では、プリンタ１０のメモリ３４は、秘密鍵ＳＫｐ１を予め記憶していない。そして、図３の検証表示処理において、図３のＳ１００及びＳ１１０の処理に代えて、Ｓ１２０及びＳ１３０の処理が実行される。

ＣＰＵ３２は、図２のＳ３０又はＳ７０で受信されたＡｕｔｈ Ｒｅｑの検証を実行する際に、秘密鍵ＳＫｐ１を利用することができない。このため、Ｓ１２０において、ＣＰＵ３２は、Ａｕｔｈ Ｒｅｑの検証に失敗する。この場合、ＣＰＵ３２は、Ｓ１３０において、Ａｕｔｈ Ｒｅｓを端末１００に送信することなく、ＱＲコードを表示する。なお、変形例では、ＣＰＵ３２は、Ｓ１３０において、検証が失敗したこと（即ちエラー）を示すＡｕｔｈ Ｒｅｓを端末１００に送信してもよい。

（具体的なケース：図８）
図８を参照して、本実施例によって実現される具体的なケースを説明する。Ｔ４１０～Ｔ４３０は、図４のＴ１０～Ｔ３０と同様である。プリンタ１０は、Ｔ４３２において、Ａｕｔｈ Ｒｅｑの検証に失敗する（Ｓ１２０）。プリンタ１０は、Ａｕｔｈ Ｒｅｓを端末１００に送信することなく、Ｔ４３６において、ＱＲコードを表示する（Ｓ１３０）。その後のＴ４４０～Ｔ４７０は、図４のＴ４０～Ｔ７０と同様である。本実施例によると、プリンタ１０が秘密鍵ＳＫｐ１を予め記憶しておく必要がないので、プリンタ１０が記憶すべき情報量を低減させることができる。

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

（変形例１）プリンタ１０は、図３のＳ１１０又はＳ１３０において、ＱＲコードを表示部１４に表示させることに代えて、例えば、ＱＲコードの印刷を印刷実行部１８に実行させてもよい。本変形例では、印刷実行部１８が、「出力部」の一例である。

（変形例２）プリンタ１０は、図４のＴ６２において、端末１００から、端末１００とのＷｉ－Ｆｉ接続を確立するためのプリンタ用ＣＯを受信してもよい。この場合、プリンタ１０は、Ｔ７０において、ＡＰ６とのＷｉ－Ｆｉ接続を確立することに代えて、プリンタ用ＣＯを利用して、端末１００とのＷｉ－Ｆｉ接続を確立する。本変形例では、当該プリンタ用ＣＯが「接続情報」の一例であり、端末１００が「外部装置」の一例である。

（変形例３）「第１の通信装置」は、プリンタ１０に代えて、端末装置、スキャナ、複合機、サーバ等の他のデバイスであってもよい。「第２の通信装置」は、端末１００に代えて、プリンタ、スキャナ、複合機、サーバ等の他のデバイスであってもよい。ここで、例えば、「第１の通信装置」、「第２の通信装置」が、それぞれ、第１の端末装置、第２の端末装置である変形例を考える。第１の端末装置は、ＡＰ６とのＷｉ－Ｆｉ接続を確立済みであり、ＡＰ情報を記憶している。第１の端末装置は、第２の端末装置からブロードキャストのＡｕｔｈ Ｒｅｑを受信する場合に、第１の端末装置の公開鍵を用いて得られるＱＲコードを表示し、その後、第２の端末装置からＡｕｔｈ Ｒｅｑを受信し、Ａｕｔｈ Ｒｅｓを第２の端末装置に送信し、第２の端末装置からＡｕｔｈ Ｃｏｎｆｉｒｍを受信する。そして、第１の端末装置は、第２の端末装置からＣｏｎｆｉｇ Ｒｅｑを受信し、ＡＰ情報を利用して第２の端末装置のためのＣＯを生成し、当該ＣＯを含むＣｏｎｆｉｇ Ｒｅｓを第２の端末装置に送信する。この場合、第２の端末装置は、当該ＣＯを利用してＡＰ６とのＷｉ－Ｆｉ接続を確立する。本変形例では、第１の端末装置、第２の端末装置が、それぞれ、「第１の通信装置」、「第２の通信装置」の一例であり、「接続情報通信部」は、接続情報を第２の通信装置に送信する。この場合、「接続情報」は、「第２の通信装置」と「外部装置」との間に無線接続を確立するための情報である。

（変形例４）プリンタ１０は秘密鍵ＳＫｐ１を予め記憶しなくてもよく、端末１００は公開鍵ＰＫｔ１を予め記憶しなくてもよく、プリンタ１０と端末１００との両方又は一方がＤＰＰに規定されているＰＫＥＸに用いられる情報（例えば特定のキー、文字列等）を予め記憶していてもよい。この場合、プリンタ１０と端末１００とは、ブロードキャストのＡｕｔｈ Ｒｅｑの通信を実行する前に、ＰＫＥＸを利用した通信を実行し、Ａｕｔｈで利用されるべき公開鍵を生成してもよい。そして、プリンタ１０と端末１００とは、生成済みの公開鍵が利用されたブロードキャストのＡｕｔｈ Ｒｅｑの通信を実行する。一般的に言うと、「第２の通信装置」は、第２のキーを予め記憶してなくてもよい。

（変形例５）図２のＳ２０の処理が省略され、Ｓ１２の後にＳ３０に進み、Ｓ３０でＮＯの場合にＳ３０の監視が継続されてもよい。一般的に言うと、「出力制御部」は、「第１の所定時間」が経過するのか否かに応じて処理を変えなくてもよい。

（変形例６）図２のＳ６０及びＳ６２の処理が省略され、Ｓ５２の後にＳ７０に進み、Ｓ７０でＮＯの場合にＳ７０の監視が継続されてもよい。一般的に言うと、「出力制御部」は、「第２の所定時間」が経過するのか否か応じて処理を変えなくてもよい。

（変形例７）図２のＳ１０の処理が省略され、プリンタ１０の電源がＯＮされる際に、Ｓ１２に必ず進んでもよい。一般的に言うと、「出力制御部」は、「接続情報」がメモリに記憶されているのか否か応じて処理を変えなくてもよい。

（変形例８）上記の各実施例では、ＣＰＵ３２，１３２がプログラム３６，１３６を実行することによって、図２～図８の各処理が実現される。これに代えて、図２～図８のいずれかの処理は、論理回路等のハードウェアによって実現されてもよい。

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

２：通信システム、６：ＡＰ、１０：プリンタ、１２：操作部、１４：表示部、１６：無線ＬＡＮＩ／Ｆ、１８：印刷実行部、３０：制御部、３２：ＣＰＵ、３４：メモリ、３６：プログラム、１００：携帯端末、１１２：操作部、１１４：表示部、１１６：無線ＬＡＮＩ／Ｆ、１１８：印刷実行部、１３０：制御部、１３２：ＣＰＵ、１３４：メモリ、１３６：ＯＳプログラム、１３８：アプリケーション、ＳＫｐ１，ＳＫｐ２：秘密鍵、ＰＫｔ１，ＰＫｐ２：公開鍵

Claims (14)

1. 第１の通信装置であって、
   Ｗｉ－Ｆｉ規格に従った無線通信を実行するための第１の無線インターフェースと、
   出力部と、
   第２の通信装置から、前記第１の無線インターフェースを介して、ＤＰＰ（Device Provisioning Protocolの略）に従った第１の認証要求を受信する第１の認証要求受信部であって、前記第１の認証要求は、前記第１の無線インターフェースに割り当てられているＭＡＣアドレスを送信先アドレスとして含まない、前記第１の認証要求受信部と、
   前記第２の通信装置から前記第１の認証要求が受信される場合に、前記第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像を前記出力部に出力させる出力制御部と、
   前記出力画像が出力された後に、前記第２の通信装置から、前記第１の無線インターフェースを介して、前記ＤＰＰに従った第２の認証要求であって、前記第１のキーが利用された前記第２の認証要求を受信する第２の認証要求受信部と、
   前記第２の通信装置から前記第２の認証要求が受信される場合に、前記第１の無線インターフェースを介して、前記ＤＰＰに従った接続情報を前記第２の通信装置と通信する接続情報通信部であって、前記接続情報は、前記第１の通信装置又は前記第２の通信装置と外部装置との間に前記Ｗｉ－Ｆｉ規格に従った無線接続を確立するための情報である、前記接続情報通信部と、
   を備える、第１の通信装置。
2. 前記第１の認証要求受信部は、前記第２の通信装置から、ブートストラッピングキーである第２のキーが利用された前記第１の認証要求を受信する、請求項１に記載の第１の通信装置。
3. 前記出力制御部は、前記第２の通信装置から前記第１の認証要求が受信される際に、前記出力画像を前記出力部に出力させる、請求項１又は２に記載の第１の通信装置。
4. 前記第１の通信装置は、さらに、
   前記第２の通信装置から前記第１の認証要求が受信される場合に、前記第１の無線インターフェースを介して、前記ＤＰＰに従った認証応答を前記第２の通信装置に送信する認証応答送信部と、
   前記認証応答が前記第２の通信装置に送信される場合に、前記第２の通信装置から、前記第１の無線インターフェースを介して、前記ＤＰＰに従った認証確認を受信する認証確認受信部と、を備え、
   前記出力制御部は、前記第２の通信装置から前記認証確認が受信される際に、前記出力画像を前記出力部に出力させる、請求項１又は２に記載の第１の通信装置。
5. 前記出力制御部は、前記第２の通信装置から前記第１の認証要求が受信され、かつ、前記第１の認証要求の検証に成功する場合に、前記出力画像を前記出力部に出力させる、請求項１から４のいずれか一項に記載の第１の通信装置。
6. 前記第２の通信装置から前記第１の認証要求が受信され、かつ、前記第１の認証要求の検証に成功する場合に、前記ＤＰＰに従った認証応答が前記第２の通信装置に送信されない、請求項５に記載の第１の通信装置。
7. 前記第１の通信装置は、さらに、
   前記第２の通信装置から前記第１の認証要求が受信され、かつ、前記第１の認証要求の検証に成功する場合に、前記第１の無線インターフェースを介して、前記ＤＰＰに従った認証応答であって、前記検証が失敗したことを示す前記認証応答を前記第２の通信装置に送信する認証応答送信部を備える、請求項５に記載の第１の通信装置。
8. 前記出力制御部は、前記第２の通信装置から前記第１の認証要求が受信され、かつ、前記第１の認証要求の検証に失敗する場合に、前記出力画像を前記出力部に出力させる、請求項１から３のいずれか一項に記載の第１の通信装置。
9. 前記出力制御部は、
   前記第１の通信装置の電源がＯＮされてから第１の所定時間が経過する前に、前記第２の通信装置から前記第１の認証要求が受信される場合に、前記出力画像を前記出力部に出力させ、
   前記第１の通信装置の電源がＯＮされてから前記第１の所定時間が経過する場合に、前記出力画像を前記出力部に出力させない、請求項１から８のいずれか一項に記載の第１の通信装置。
10. 前記出力制御部は、
    前記第１の通信装置の電源がＯＮされている状態において、前記第１の通信装置に対して所定操作が実行されてから第２の所定時間が経過する前に、前記第２の通信装置から前記第１の認証要求が受信される場合に、前記出力画像を前記出力部に出力させ、
    前記第１の通信装置の電源がＯＮされている状態において、前記第１の通信装置に対して前記所定操作が実行されてから前記第２の所定時間が経過する場合に、前記出力画像を前記出力部に出力させない、請求項１から９のいずれか一項に記載の第１の通信装置。
11. 前記出力制御部は、
    前記第１の通信装置と前記外部装置との間に前記無線接続を確立するための前記接続情報が前記第１の通信装置のメモリに記憶されていない状態において、前記第２の通信装置から前記第１の認証要求が受信される場合に、前記出力画像を前記出力部に出力させ、
    前記接続情報が前記メモリに記憶されている場合に、前記出力画像を前記出力部に出力させない、請求項１から１０のいずれか一項に記載の第１の通信装置。
12. 第１の通信装置のためのコンピュータプログラムであって、
    前記第１の通信装置は、
    Ｗｉ－Ｆｉ規格に従った無線通信を実行するための第１の無線インターフェースと、
    出力部と、
    コンピュータと、を備え、
    前記コンピュータプログラムは、前記コンピュータに、以下の各部、即ち、
    第２の通信装置から、前記第１の無線インターフェースを介して、ＤＰＰ（Device Provisioning Protocolの略）に従った第１の認証要求を受信する第１の認証要求受信部であって、前記第１の認証要求は、前記第１の無線インターフェースに割り当てられているＭＡＣアドレスを送信先アドレスとして含まない、前記第１の認証要求受信部と、
    前記第２の通信装置から前記第１の認証要求が受信される場合に、前記第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像を前記出力部に出力させる出力制御部と、
    前記出力画像が出力された後に、前記第２の通信装置から、前記第１の無線インターフェースを介して、前記ＤＰＰに従った第２の認証要求であって、前記第１のキーが利用された前記第２の認証要求を受信する第２の認証要求受信部と、
    前記第２の通信装置から前記第２の認証要求が受信される場合に、前記第１の無線インターフェースを介して、前記ＤＰＰに従った接続情報を前記第２の通信装置と通信する接続情報通信部であって、前記接続情報は、前記第１の通信装置又は前記第２の通信装置と外部装置との間に前記Ｗｉ－Ｆｉ規格に従った無線接続を確立するための情報である、前記接続情報通信部と、
    として機能させる、コンピュータプログラム。
13. 第２の通信装置のためのアプリケーションプログラムであって、
    前記第２の通信装置は、
    Ｗｉ－Ｆｉ規格に従った無線通信を実行するための第２の無線インターフェースと、
    カメラと、
    コンピュータと、を備え、
    前記アプリケーションプログラムは、前記コンピュータを、以下の各部、即ち、
    前記第２の無線インターフェースを介して、ＤＰＰ（Device Provisioning Protocolの略）に従った第１の認証要求を送信する第１の認証要求送信部であって、前記第１の認証要求は、第１の通信装置の第１の無線インターフェースであって、Ｗｉ－Ｆｉ規格に従った無線通信を実行するための前記第１の無線インターフェースに割り当てられているＭＡＣアドレスを送信先アドレスとして含まない、前記第１の認証要求送信部と、
    前記第１の認証要求が前記第１の通信装置に送信されることに応じて、前記第１の通信装置のブートストラッピングキーである第１のキーを用いて得られる出力画像が前記第１の通信装置によって出力され、かつ、前記第１の出力画像が前記カメラによって撮影される場合に、前記第１のキーを取得する取得部と、
    前記第１のキーが取得される場合に、前記第２の無線インターフェースを介して、前記ＤＰＰに従った第２の認証要求であって、前記第１のキーが利用される前記第２の認証要求を前記第１の通信装置に送信する第２の認証要求送信部と、
    前記第２の認証要求が前記第１の通信装置に送信される場合に、前記第２の無線インターフェースを介して、前記ＤＰＰに従った接続情報を前記第１の通信装置と通信する接続情報通信部であって、前記接続情報は、前記第１の通信装置又は前記第２の通信装置と外部装置との間に前記Ｗｉ－Ｆｉ規格に従った無線接続を確立するための情報である、前記接続情報通信部と、
    として機能させる、アプリケーションプログラム。
14. 前記第１の認証要求送信部は、ブートストラッピングキーである第２のキーが利用された第１の認証要求を前記第１の通信装置に送信する、請求項１３に記載のアプリケーションプログラム。

Images