JP5589819B2 - 通信装置及び通信方法 - Google Patents

Description

本発明は、無線通信装置に関する。

無線ＬＡＮ（Local Area Network）の標準規格の策定を行うＩＥＥＥ（The Institute of Electrical and Electronic Engineers）８０２．１１タスクグループにより規定された、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｇ、ＩＥＥＥ８０２．１１ｎなどの無線ＬＡＮ技術は、世界的に、オフィスまたは家庭で普及している。

ＩＥＥＥ８０２．１１ａは、５[GHz]の周波数帯域を用いて通信をおこなう仕様である。ＩＥＥＥ８０２．１１ｇは、２．４[GHz]の周波数帯域を用いて通信をおこなう仕様である。ＩＥＥＥ８０２．１１ｎは、送信側および受信側にて複数のアンテナを組み合わせることにより、データ送受信の帯域を広げることにより無線通信を行うための仕様である。該無線通信を行う技術は、ＭＩＭＯ（Multiple Input Multiple Output）と呼ばれる。

ＩＥＥＥ８０２．１１ａ／ｇ／ｎの仕様においては、その接続形態は、インフラストラクチャーモードとアドホックモードの２つに分けられる。

インフラストラクチャーモードは、アクセスポイントを中心に、無線ＬＡＮ端末であるステーションが存在し、あるステーションと他のステーションとの間のデータ伝送を、アクセスポイント経由で行うものである。オフィス、家庭などの環境において、多く使用されており、一般的な接続形態である。

アドホックモードは、アクセスポイントが存在せず、ステーション間でのデータ伝送は、ステーション同士で直接行うものである。従って、アクセスポイントの使用を必要としない。ただし、アドホックモードは、ＩＥＥＥ８０２．１１ａ／ｇ／ｎ仕様においては、補助的な機能としての位置付けを越えていない。例えば、ＩＥＥＥ８０２．１１ｇにおける、インフラストラクチャーモードでの最大伝送レートが５４[Mbps]であるのに対し、アドホックモードでは１１[Mbps]に制限されている。また、インフラストラクチャーモードでは、暗号方式としてＷＥＰ（Wired Equivalent Privacy）、ＷＰＡ（Wi-Fi Protected Access）をサポートしているのに対し、アドホックモードではＷＥＰ（Wired Equivalent Privacy）のみしかサポートしていない。また、インフラストラクチャーモードでの接続が一般的であることが想定されているため、アドホックモードで接続する際には、その設定が複雑になっている。このような状況から、アドホックモードでの接続形態は、普及していない。

ところが、近年の技術動向から、パソコン、携帯電話、デジタルカメラ、プリンタなどから、キーボードやヘッドフォンに至るまで、無線ＬＡＮ通信機能を搭載した通信装置、すなわち、Ｗｉ−Ｆｉ対応機器が増えており、アクセスポイントなしで、各通信装置の間でデータ伝送をする必要性が高くなっている。

このような状況において、無線ＬＡＮ製品の普及促進を図ることを目的とした業界団体であるＷｉ−Ｆｉ Ａｌｌｉａｎｃｅは、２００９年１０月に、Ｗｉ−Ｆｉ端末間で直接通信する仕様「Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ」（以下、「Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ」という）を発表した。該Ｗｉ−Ｆｉ Ｄｉｒｅｃｔの仕様については、ドラフトの仕様書が策定されている（例えば、非特許文献１参照）。

Ｗｉ−Ｆｉ Ｄｉｒｅｃｔは、基本概念として、各Ｗｉ−Ｆｉ対応機器がソフトウェアアクセスポイント機能を搭載し、ネットワークに参加する複数台のＷｉ−Ｆｉ対応機器の中で、いずれか一台の通信装置が、実際にソフトウェアアクセスポイントとして動作する。なお、実際にソフトウェアアクセスポイントとして動作する通信装置の決定方法については、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔの仕様に、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎとして定義されている。

ソフトウェアアクセスポイントを使用することにより、ＩＥＥＥ８０２．１１ｇでの最大伝送レートが、従来のインフラストラクチャーモードと同じ５４[Mbps]を実現でき、また、暗号方式も、ＷＰＡをサポートできる。

また、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔの仕様では、ソフトウェアアクセスポイントは、ＷＰＳ（Wi-Fi Protected Setup）機能を用いることが規定されている。ＷＰＳ機能は、従来複雑であった、無線ＬＡＮの接続の事前に必要となる、ＳＳＩＤ(Service Set Identifier)の設定、暗号キーの設定を、簡単に行うためのしくみである。ＷＰＳ機能を有するソフトウェアアクセスポイント機能を搭載することにより、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔにおける各通信装置間でのデータ伝送を行うための設定は、簡単になる。

Ｗｉ−Ｆｉ Ｄｉｒｅｃｔの仕様においては、ある一つのネットワークに参加する各通信装置を、Ｐ２Ｐ Ｄｅｖｉｃｅとして定義し、そのネットワークを、Ｐ２Ｐ Ｇｒｏｕｐとして定義している。Ｐ２Ｐ Ｇｒｏｕｐにおいて、実際にソフトウェアアクセスポイントの機能を用いるＰ２Ｐ Ｄｅｖｉｃｅを、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒとして定義し、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒ以外のＰ２Ｐ Ｄｅｖｉｃｅを、Ｐ２Ｐ Ｃｌｉｅｎｔとして定義している。複数のＰ２Ｐ ＤｅｖｉｃｅからＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒを選出する手順を、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎとして定義している。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎに先立ち、接続したい相手となる通信装置の検出が必要となる。Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様では、この通信装置の検出をおこなうフェーズを、Ｆｉｎｄ Ｐｈａｓｅとして定義している。Ｆｉｎｄ Ｐｈａｓｅでは、Ｌｉｓｔｅｎ Ｓｔａｔｅと、Ｓｅａｒｃｈ Ｓｔａｔｅと呼ばれる２つのステートが繰り返される。

Ｌｉｓｔｅｎ Ｓｔａｔｅは、ある１つのチャンネルにおいて、ある通信装置からのＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームを待ち、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを受信したらＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを送出する。

Ｓｅａｒｃｈ Ｓｔａｔｅは、チャンネルを変更しながら、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを送出する。Ｌｉｓｔｅｎ Ｓｔａｔｅの期間を、１０２４[μsec]×１００×ｎとして、このｎを、１から３の範囲でのランダムな値として選択することにより、一方の通信装置がＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームを送出するＳｅａｒｃｈ Ｓｔａｔｅとなり、もう一方の通信装置がＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームを受信してＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを送出するＬｉｓｔｅｎ Ｓｔａｔｅとなるという状態が実現されるようにする。

このようにして、Ｆｉｎｄ Ｐｈａｓｅにて、接続したい相手となる通信装置を検出した通信装置は、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎを開始する。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎは、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｃｏｎｆｉｒｍａｔｉｏｎフレームという、３つ（３−ｗａｙ）の情報の交換から成り立っている。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗した場合には、パケットキャプチャツールを用いてＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをモニタすることにより、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したか失敗したかを把握することができる。さらに、失敗した場合には、その要因がどのようなものであるかを把握することができる。

又は、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗した場合には、ファームウェアで、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを解析することにより、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム中のＳｔａｔｕｓ ａｔｔｒｉｂｕｔｅのＳｔａｔｕｓ Ｃｏｄｅの値を調べることにより、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したか失敗したかを把握することができる。さらに、失敗した場合には、その要因がどのようなものであるかを把握することができる。

なお、Ｓｔａｔｕｓ Ｃｏｄｅは、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎのみならず、接続要求を表すＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームに対する応答を表すＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームにも含まれる。Ｓｔａｔｕｓ Ｃｏｄｅは、接続要求を受け付けるか否かを表す。さらに、Ｓｔａｔｕｓ Ｃｏｄｅは、接続要求を受け付けない場合には、その要因がどのようなものであるかを表す。

情報交換をおこなった際の失敗要因については、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔの他の、いくつかの通信技術仕様にも定義されている。例えば、Ｄｅｆｉｎｉｔｉｏｎｓ ｆｏｒ Ｐｏｒｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ＭＩＢとして定義されることもある（例えば、非特許文献２参照）。また、Ｒｅｓｕｌｔ Ｃｏｄｅｓとして定義されることもある（例えば、非特許文献３参照）。

ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム中のＳｔａｔｕｓ ａｔｔｒｉｂｕｔｅ中のＳｔａｔｕｓ Ｃｏｄｅ Ｆｉｅｌｄを調べることにより、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したかどうかを把握することができる。さらに、失敗した場合にはその要因が何であるかを把握することができる。

しかし、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したかどうかを把握した結果、失敗している場合に、失敗の要因を把握するためには、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様について専門的な知識を持っていることが前提となる。一般的なユーザーがこの情報を把握することは困難である。

前述の、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ以外の通信仕様についても、例えば、Ｄｅｆｉｎｉｔｉｏｎｓ ｆｏｒ Ｐｏｒｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ＭＩＢとして定義される技術においては、システムを運用する部署の管理者などが、特定のツールを用いて解析するためのものである。従って、一般的にはユーザーに公開される類のものではない。

また、Ｒｅｓｕｌｔ Ｃｏｄｅｓとして定義される技術においては、Ｒｅｓｕｌｔ Ｃｏｄｅｓの取り扱いについては、ベンダーに依存するとの旨記載されている。しかし、Ｒｅｓｕｌｔ Ｃｏｄｅｓとして定義される技術の仕様が記載されているワイヤレスＵＳＢ技術が普及していない。具体的に、Ｒｅｓｕｌｔ Ｃｏｄｅｓを利用した例は、発見されていない。

つまり、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔで規定されているＳｔａｔｕｓ Ｃｏｄｅの情報をはじめ、失敗要因を示す情報を有効に活用するための障壁が高い。

そこで、本発明は、上述した問題点の少なくとも１つに鑑みてなされたものであり、失敗要因を表す情報を有効に活用することである。

本通信装置は、
複数の通信装置を含む通信システムにおける１の通信装置であって、
他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する情報交換成功判定部と、
該情報交換成功判定部により情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する自動設定変更判定部と、
該自動設定変更判定部により自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定部により自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う設定変更部と、
該設定変更部により変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う再試行部と
を有する。

本通信方法は、
複数の通信装置を含む通信システムにおける１の通信装置における通信方法であって、
他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する情報交換成功判定ステップと、
該情報交換成功判定ステップにより情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する自動設定変更判定ステップと、
該自動設定変更判定ステップにより自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定ステップにより自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う設定変更ステップと、
該設定変更ステップにより変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う再試行ステップと
を有する。

開示の実施例によれば、失敗要因を表す情報を有効に活用することができる。

本実施例に従った通信装置の一例を示す図である。 本実施例に従った通信装置の動作を示すシーケンスチャートである。 失敗要因番号と、失敗要因内容との対応を示す図である。 本実施例に従った通信装置における対応方法の表示例を示す図である。 本実施例に従った通信装置における対応方法の表示例を示す図である。 本実施例に従った通信装置の動作を示すシーケンスチャートである。 本実施例に従った通信装置の動作を示すフローチャートである。 本実施例に従った通信装置における失敗要因番号と、失敗要因内容と、対策カテゴリとの対応を示す図である。

次に、本発明を実施するための形態を、以下の実施例に基づき図面を参照しつつ説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を用い、繰り返しの説明は省略する。

＜通信システム＞
本通信システムは、複数の通信装置を有する。通信装置同士は、アクセスポイントを介さずに無線通信を行う。ここで、アクセスポイントとは、アクセスポイントとしてのみ機能させる装置であってもよい。例えば、各通信装置は、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔに従って無線通信を行うようにしてもよい。本実施例では、一例として、各通信装置がＷｉ−Ｆｉ Ｄｉｒｅｃｔに従って無線通信を行う場合について説明するが、他の無線通信方式に従った無線通信を行う場合にも適用できる。例えば、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎに相当する処理が行われ、該処理が失敗した場合に、該失敗の要因を表す情報を取得できる無線通信方式に適用できる。

＜通信装置＞
図１は、本実施例に従った通信装置を示すブロック図である。

本通信装置１００は、機器制御部１０２と、該機器制御部１０２とバス１５０により接続された通信コントローラ１２２とを有する。

＜機器制御部＞
機器制御部１０２は、メインＣＰＵ(Central Processing Unit)１０４と、メモリ１０６とを有する。メインＣＰＵ１０４は、メモリ１０６を用いてオペレーティングシステム１０８を実行させる。メインＣＰＵ１０４は、オペレーティングシステム１０８上でドライバ１１０を実行させる。

機器制御部１０２は、ドライバ１１０を有する。該ドライバ１１０は、レジスタに対して値の読み書きを行うことによりＭＡＣハードウェア１３２を制御する。

機器制御部１２０は、バスコントローラ１２０を有する。該バスコントローラ１２０は、バス１５０を制御する。

機器制御部１０２は、アプリケーションソフトウェア１１２を有する。アプリケーションソフトウェア１１２は、通信相手となる他の通信装置からのデータを処理する。該アプリケーションソフトウェア１１２は、通信相手となる他の通信装置へ送出するデータを生成する。

機器制御部１０２は、表示データ作成部１１４を有する。該表示データ作成部１１４は、アプリケーションソフトウェア１１２に含まれてもよい。該表示データ作成部１１４は、通信コントローラ１２２の受信情報解析部１３０により解析された失敗要因にユーザに向けて表示すべきデータが含まれる場合に、該ユーザに向けて表示すべきデータを作成する。

機器制御部１０２は、情報表示部１１８を有する。該情報表示部１１８は、表示データ作成部１１４により作成されたデータを表示する。該情報表示部１１８は、例えば液晶モニタにより構成されてもよい。

機器制御部１０２は、ユーザＩ／Ｆ１１６を有する。該ユーザＩ／Ｆ１１６は、情報表示部１１８に表示されたデータに対する、ユーザーからの入力を受け付ける。例えば、ユーザＩ／Ｆには、上下方向や、左右方向にカーソルを移動させるためのキーが含まれてもよい。

＜通信コントローラ＞
通信コントローラ１２２は、ＭＡＣハードウェア１３２を有する。該ＭＡＣハードウェア１３２は、サブＣＰＵ１４０、メモリ１３６、ＰＨＹ(Physical Layer)部１４２との間で、データフレームの受け渡しや、データフレームのフィルタリング等の処理を行う。例えば、ＭＡＣハードウェア１３２は、通信プロトコルの仕様に従って処理を実行する。ＭＡＣハードウェア１３２とＰＨＹ部１４２との間の通信は、ＭＡＣ−ＰＨＹインタフェース仕様書の規定に従って通信が実行される。

通信コントローラ１２２は、ＰＨＹ部１４２を有する。該ＰＨＹ部１４２は、周波数変換などの処理を行う。該ＰＨＹ部１４２は、ベースバンド部１４４を有する。該ベースバンド部１４４は、電気信号とディジタルデータとの間で変換を行う。該ＰＨＹ部１４２は、ＲＦ部１４６を有する。該ＲＦ部１４６は、電気信号の周波数と無線の電波の周波数との間で周波数変換をおこなう。

通信コントローラ１２２は、アンテナ１４８を有する。該アンテナ１４８は、電波の送受信を行う。

通信コントローラ１２２は、バスコントローラ１４０を有する。該バスコントローラ１４０は、バス１５０を制御する。

通信コントローラ１２２は、サブＣＰＵ１４０を有する。該サブＣＰＵ１４０は、メモリ１３６を用いて、リアルタイムオペレーションシステム１３４を実行する。該サブＣＰＵ１４０は、リアルタイムオペレーティングシステム１３４上で、ＭＡＣハードウェア部１３２の各部を制御するためのファームウェア１２４を実行させる。

メモリ１３６は、受信情報保存部１３８を有する。該受信情報保存部１３８は、通信相手となる他の通信装置からの情報を保存する。通信相手となる他の通信装置からの情報を保存することにより、後に参照および比較することができる。

通信コントローラ１２２は、ファームウェア１２４を有する。該ファームウェア１２４は、通信プロトコル制御部１２６を有する。該通信プロトコル制御部１２６は、ドライバ１１０からのデータに基づいて、送信すべきデータフレームを生成する。該ファームウェア１２４は、設定情報更新部１２８を有する。該設定情報更新部１２８は、受信情報解析部１３０により入力されるべき設定情報に更新する。該ファームウェア１２４は、受信情報解析部１３０を有する。該受信情報解析部１３０は、受信情報を解析する。例えば、該受信情報解析部１３０は、受信情報を解析することにより、他の通信装置との間での情報交換が成功したかどうかを判定する。さらに、該受信情報解析部１３０は、情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する。さらに、該受信情報解析部１３０は、自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行う。さらに、該受信情報解析部１３０は、自動的に設定変更を行うべきでないと判定された場合に、失敗要因を表す情報を表示し、ユーザに設定変更を促す。該受信情報解析部１３０は、ユーザによる設定変更に従って、設定変更を行う。

＜データの送受信＞
本通信装置１００が、通信相手となる他の通信装置に対してデータを送出する場合について説明する。

アプリケーションソフトウェア１１２によりデータが生成される。該データは、ドライバ１１０を経由し、バス１５０を介して、ファームウェア１２４に渡される。該ファームウェア１２４は、データフレームを生成し、ＭＡＣハードウェア部１３２に渡す。ＭＡＣハードウェア部１３２は、ベースバンド部１４４に、ファームウェア１２４からのデータフレームを渡す。ベースバンド部１４４は、ＭＡＣハードウェア部１３２からのデータフレームを電気信号に変換し、ＲＦ部１４６に渡す。ＲＦ部１４６は、無線の電波信号に、ベースバンド部１４４からの電気信号を変換し、アンテナ１４８を介して送出する。

本通信装置１００が、通信相手となる他の通信装置からデータを受信する場合について説明する。

他の通信装置からの電波信号は、アンテナ１４８を介して、ＲＦ部１４６に入力される。該ＲＦ部１４６は、該電波信号を電気信号に変換し、ベースバンド部１４４に入力する。該ベースバンド部１４４は、該電気信号を０（零）又は１のディジタルデータに変換する。該ベースバンド部１４４は、該ディジタルデータをＭＡＣハードウェア１３２に渡す。

該ＭＡＣハードウェア１３２は、ファームウェア１２４に、ベースバンド部１４４からのディジタルデータを渡す。ファームウェア１２４は、該ＭＡＣハードウェア部１３２からのデータフレームを分解する。該分解されたデータは、ドライバ１１０を経由して、アプリケーションソフトウェア１１２に渡される。

＜Ｆｉｎｄ Ｐｈａｓｅ、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎ＞
図２は、本通信システムに含まれる通信装置の動作を示すシーケンスチャートである。図２には、通信装置（以下、「Ｐ２Ｐ Ｄｅｖｉｃｅ＿１」という）と、該通信装置の通信相手となる通信装置（以下、「Ｐ２Ｐ Ｄｅｖｉｃｅ＿２」という）との間における、ファインドフェーズ（Ｆｉｎｄ Ｐｈａｓｅ）と、該Ｆｉｎｄ Ｐｈａｓｅの後のグループオーナネゴシエーション（Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎ）のシーケンスが示される。

＜Ｆｉｎｄ Ｐｈａｓｅ＞
Ｐ２Ｐ Ｄｅｖｉｃｅ＿１は、サーチ状態（Ｓｅａｒｃｈ Ｓｔａｔｅ）でプローブリクエスト（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ）（接続要求）を送信し（ステップＳ２０２、Ｓ２０４、Ｓ２０８、Ｓ２１４、Ｓ２１８、Ｓ２２２）、リスン状態（Ｌｉｓｔｅｎ Ｓｔａｔｅ）で、Ｐ２Ｐ Ｄｅｖｉｃｅ＿２からのプローブリクエストを受信する。図２には、Ｐ２Ｐ Ｄｅｖｉｃｅ＿１がＳｅａｒｃｈ ＳｔａｔｅでＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信する際に、チャネル１、６、１１の順で送信する例が示される。

同様に、Ｐ２Ｐ Ｄｅｖｉｃｅ＿２は、Ｓｅａｒｃｈ ＳｔａｔｅでＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信し（ステップＳ２０６、Ｓ２１０、Ｓ２１２、Ｓ２１６、Ｓ２２０、Ｓ２２４、Ｓ２２６）、Ｌｉｓｔｅｎ Ｓｔａｔｅで、Ｐ２Ｐ Ｄｅｖｉｃｅ＿１からのプローブリクエストを受信する。図２には、Ｐ２Ｐ Ｄｅｖｉｃｅ＿２がＳｅａｒｃｈ ＳｔａｔｅでＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信する際に、チャネル１、６、１１の順で送信する例が示される。

Ｐ２Ｐ Ｄｅｖｉｃｅ＿２がＳｅａｒｃｈ Ｓｔａｔｅで、チャネル１で送信したＰｒｏｂｅ Ｒｅｑｕｅｓｔが（ステップＳ２２６）、Ｐ２Ｐ Ｄｅｖｉｃｅ＿１に受信される。該Ｐ２Ｐ Ｄｅｖｉｃｅ＿１は、Ｐ２Ｐ Ｄｅｖｉｃｅ＿２により送信されたＰｒｏｂｅ Ｒｅｑｕｅｓｔに対する応答として、プローブレスポンス（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ）（接続応答）を、チャネル１で送信する（ステップＳ２２８）。

＜Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎ＞
Ｐ２Ｐ Ｄｅｖｉｃｅ＿１により送信されたＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを受信したＰ２Ｐ Ｄｅｖｉｃｅ＿２は、ゴーネゴシエーションリクエスト（ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）（交渉要求）フレームを送出する（ステップＳ２３０）。ここで、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを受信したＰ２Ｐ Ｄｅｖｉｃｅ＿１が、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームの送出を省略して、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出してもよいことが、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に記載されている。

ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームには、Ｐ２Ｐ ＩＥ（Peer-to-Peer Information Element）と、ＷＰＳ ＩＥ（Wi-Fi Protected Setup Information Element）が含まれる。Ｐ２Ｐ ＩＥの中には、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｉｎｔｅｎｔ、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤなどの情報が含まれる。Ｇｒｏｕｐ Ｏｗｎｅｒ ＩｎｔｅｎｔはＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになることをどれだけ強く希望するかの度合いを表す。Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤは認証に必要な情報のやりとりを行うＰｒｏｖｉｓｉｏｎｉｎｇで用いる情報の出所を表す。該Ｐｒｏｖｉｓｉｏｎｉｎｇは、サポートするチャンネルを表すＣｈａｎｎｅｌ、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの後に行われる。これらの情報は、ａｔｔｒｉｂｕｔｅとして定義されている。

Ｐ２Ｐ Ｄｅｖｉｃｅ＿２からのＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信したＰ２Ｐ Ｄｅｖｉｃｅ＿１は、ゴーネゴシエーションレスポンス（ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）（交渉応答）フレームを送出する（ステップＳ２３２）。該ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームのａｔｔｒｉｂｕｔｅには、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームと同様に、Ｐ２Ｐ ＩＥの内部に、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｉｎｔｅｎｔ、Ｃｈａｎｎｅｌ、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤなどのａｔｔｒｉｂｕｔｅが含まれる。該ａｔｔｒｉｂｕｔｅが含まれるとともに、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム中の情報を解析して照合した結果を示すＳｔａｔｕｓ ａｔｔｒｉｂｕｔｅが含まれる。Ｓｔａｔｕｓ ａｔｔｒｉｂｕｔｅの中には、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したか失敗したか、また、失敗した場合には、失敗要因のうちのいずれであるか、を示すＳｔａｔｕｓ Ｃｏｄｅ Ｆｉｅｌｄが含まれる。例えば、１０個の失敗要因が含まれる。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの成功を表すＳｔａｔｕｓ Ｃｏｄｅの値は０であり、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの失敗要因を表すＳｔａｔｕｓ Ｃｏｄｅの値は２から１１として定義されてもよい。

Ｐ２Ｐ Ｄｅｖｉｃｅ＿１により送信されたＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信したＰ２Ｐ Ｄｅｖｉｃｅ＿２は、ゴーネゴシエーションコンファメーション（ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｃｏｎｆｉｒｍａｔｉｏｎ）（交渉確認）フレームを送出する（ステップＳ２３４）。

以下の説明では、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎを行うにあたって、本通信装置がＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出し、該ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに対して、他の通信装置からＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信した場合を対象として、説明をおこなう。換言すれば、図２を参照して説明したシーケンスチャートにおいて、Ｐ２Ｐ Ｄｅｖｉｃｅ＿２における処理について主に説明される。

Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様には、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム中のＰ２Ｐ ＩＥに含まれるＰ２Ｐ ａｔｔｒｉｂｕｔｅが定義されており、また、Ｐ２Ｐ ａｔｔｒｉｂｕｔｅとして取りうる一つの値として、ステータスコード（Ｓｔａｔｕｓ Ｃｏｄｅ）（失敗要因番号）が定義されている。

図３は、失敗要因番号と、該失敗要因番号により表される失敗内容との対応を示す。例えば、失敗要因番号には１−１０が含まれ、１０種類のＧｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの失敗要因が含まれる。

本通信装置１００は、Ｐ２Ｐ Ｄｅｖｉｃｅ＿１からのＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信情報保存部１３８に保存する。ファームウェア１２４は、受信情報保存部１３８に保存されたＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを解析する。例えば、受信情報解析部１３０は、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅに含まれるＰ２Ｐ ＩＥに含まれるＰ２Ｐ ａｔｔｒｉｂｕｔｅの値（失敗要因番号）を抽出する。該受信情報解析部１３０は、該失敗要因番号により示される失敗要因内容に応じて、その対策として取り得る処理を行う。失敗要因番号により示される失敗要因内容に応じてその対策として取り得る処理を行うことにより、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎを再度実施する際に、成功する可能性をより高くすることができる。

＜失敗要因内容に応じた処理内容＞
本通信装置１００は、失敗要因内容に応じて、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに含まれるパラメータの値を自動的に変更し、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出する。以下、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに含まれるパラメータの値を自動的に変更し、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出する対策が取られるべきことが好ましい失敗要因内容を「自動再試行カテゴリ」という。

本通信装置１００は、失敗要因内容に応じて、情報表示部１１８に、該失敗要因内容への対策を表示させ、ユーザに設定変更を促す。ユーザによる設定に従って、パラメータの値を変更し、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出する。
以下、ユーザによる設定に従って、パラメータの値を変更し、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出する対策が取られることが好ましい失敗要因内容を「ユーザ設定カテゴリ」という。

失敗要因内容が、「自動再試行カテゴリ」に分類されるか「ユーザ設定カテゴリ」に分類されるかは適宜変更可能である。

以下、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に規定されているＳｔａｔｕｓ Ｃｏｄｅ（失敗要因番号）に対応する各失敗要因の内容と、各失敗要因に対する処理内容について説明する。

失敗要因番号が「１」により表される失敗要因内容は、「パラメータの不整合」を表す。「パラメータの不整合」は、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様にグループケーパビリティビットマップ（Ｇｒｏｕｐ Ｃａｐａｂｉｌｉｔｙ Ｂｉｔｍａｐ）（グループ能力ビットマップ）として定義されている値の各ビットが、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームとＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームとのの間で、整合がとれないことを示す。

例えば、Ｐｅｒｓｉｓｔｅｎｔ Ｐ２Ｐ Ｇｒｏｕｐビットは、Ｐ２Ｐ Ｇｒｏｕｐの形成を解いた後も、そのＰ２Ｐ Ｇｒｏｕｐを再利用するかどうかを表す情報である。ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームでは、Ｐ２Ｐ Ｇｒｏｕｐの再利用を希望し、Ｐｅｒｓｉｓｔｅｎｔ Ｐ２Ｐ Ｇｒｏｕｐビットを「１」に設定しているのに対し、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームでは、Ｐ２Ｐ Ｇｒｏｕｐの再利用を望まず、Ｐｅｒｓｉｓｔｅｎｔ Ｐ２Ｐ Ｇｒｏｕｐビットを「０」にする場合がある。

このような場合、通信相手となる通信装置が送出する、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームの内容に従い、通信装置１００が、Ｐ２Ｐ Ｇｒｏｕｐの再利用を希望しないように、自動的にＰｅｒｓｉｓｔｅｎｔ Ｐ２Ｐ Ｇｒｏｕｐビットを０に設定することも可能である。しかし、ユーザに設定変更を促す方が好ましい。例えば、受信情報解析部１３０は、情報表示部１１８に、「再利用を希望しないような設定にしてもよいか？」と表示することにより設定変更を促し、ユーザに、ユーザＩ／Ｆ１１６への入力を促す。

Ｇｒｏｕｐ Ｃａｐａｂｉｌｉｔｙ Ｂｉｔｍａｐの値は、ユーザにより設定された値に依存する部分が大きい。従って、失敗要因内容が、「パラメータの不整合」である場合には、ユーザ設定カテゴリに分類し、不整合であるパラメータを一つ一つ情報表示部１１８に表示する。不整合であるパラメータを表示する際には、ユーザが、応答し易いような表示内容であることが好ましい。例えば、不整合であるパラメータの設定変更の候補を表示し、「ＹＥＳ」（「はい」）又は「ＮＯ」（「いいえ」）を選択させるのが好ましい。不整合であるパラメータの設定変更の候補を表示し、「ＹＥＳ」又は「ＮＯ」を選択させることにより、ユーザは、ユーザＩ／Ｆ１１６を操作することにより設定変更を行うことができる。例えば、ユーザ１１６を操作することによりカーソルを上下又は左右に動かすことにより、所望する設定ができる。受信情報解析部１３０は、設定情報更新部１２８に、ユーザにより設定変更された内容を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された設定変更された内容に従って、設定情報を更新する。

失敗要因番号が「２」により表される失敗要因内容は、「接続可能な台数の最大値を超える」ことを表す。「接続可能な台数の最大値を超える」ことは、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを送出する側が、現在接続されている台数以上の数の通信装置がネットワークに参加することを許容できないことを示す。この場合、通信装置が、最も長い間使用されていない装置を自動的に切断するようにしてもよい。また、この場合、通信装置は、既にネットワークに参加している通信装置のリストを表示し、「どの装置を停止させるのがよいか？」を、情報表示部１１８に表示し、ユーザに、ユーザＩ／Ｆ１１６による入力に委ねる方が望ましい。なお、既にネットワークに参加している通信装置のリストに表示する通信装置の順序としては、最も長い間使用されていない装置の順序で表示するのが好ましい。これは、使用されていない期間が長くなるに従って停止させる装置として選択される可能性が高くなると想定されるためである。停止させる対象となる可能性の高い装置を、できるだけ早くユーザが選択できるようにするためである。

図４は、停止させる通信装置を選択させる際に表示される通信装置のリストの一例を示す。図４に示される例では、他の通信装置に接続される装置は最大で５台である。他の通信装置に５台の装置が接続されている状況で、本通信装置１００が接続要求を行った場合に、通信装置のリストが表示され、停止させるべき通信装置の選択が促される。例えば、他の通信装置には、携帯電話、ファイルサーバ、プリンタ、プロジェクタ、及びディスプレイが接続されている。

従って、失敗要因が「接続可能な台数の最大値を超える」ことである場合には、ユーザ設定カテゴリに分類し、既にネットワークに参加している通信装置のリストと、停止させる装置を選択することを促すことを情報表示部１１８に表示する。既にネットワークに参加している通信装置のリストには、最も長い間使用されていない装置の順序に表示するのが好ましい。ユーザは、上下又は左右に、カーソルを動かすことにより、停止させるべき装置を選択できる。受信情報解析部１３０は、設定情報更新部１２８に、ユーザにより選択された停止させるべき通信装置を表す情報を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された停止させるべき通信装置を表す情報に従って、設定情報を更新する。停止させるべき通信装置を表す情報に従って設定情報が更新された際の処理の詳細については後述する。

失敗要因番号が「３」により表される失敗要因内容は、「パラメータの内容が正しくない」ことを表す。「パラメータの内容が正しくない」ことは、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームの中の、あるパラメータの値が正しくないことを表す。この場合、通信装置が、正しくないパラメータを、訂正値として考えられる値に自動的に設定するようにしてもよい。また、この場合、通信装置は、正しくないパラメータの内容と、該正しくないパラメータの訂正値の候補とを表示し、ユーザに、ユーザＩ／Ｆ１１６に入力を委ねる方が望ましい。

図５は、情報表示部１１８に表示されるべきメッセージの一例を示す。図５には、該メッセージに対応する対策の一例として、ユーザに設定変更を促す際に表示されるべき選択項目の一例が示される。図５に示されるように、複数の選択肢がある場合には、「ＹＥＳ」又は「ＮＯ」ではなく、具体的に、選択項目が表示されてもよい。

なお、表示されるべき選択肢のうち、選択することができないパラメータについては、選択することができないことが分かる表示、例えば、グレーで表示してもよい。選択することができないパラメータをグレーで表示することにより、ユーザが、何の選択肢であるかを、より簡単にイメージすることができるためである。また、選択することができない項目は表示しないようにしてもよいし、選択することができない項目の上にカーソルが移動できないようにすることにより選択できないようにしてもよい。

従って、失敗要因が、「パラメータの内容が正しくない」ことである場合には、ユーザ設定カテゴリに分類し、ユーザが、上下又は左右に、カーソルを動かすことにより、正しくないパラメータの訂正値の候補から、訂正値を選択させることにより設定変更できるようにする。受信情報解析部１３０は、設定情報更新部１２８に、ユーザにより選択された訂正値を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された訂正値に従って、設定情報を更新する。

失敗要因番号が「４」により表される失敗要因内容は、「他のデバイスとＧｒｏｕｐ Ｆｏｒｍａｔｉｏｎ中である」ことを表す。「他のデバイスとＧｒｏｕｐ Ｆｏｒｍａｔｉｏｎ中である」ことは、他の通信装置とＧｒｏｕｐ Ｆｏｒｍａｔｉｏｎ、すなわち、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎ又はＰｒｏｖｉｓｉｏｎｉｎｇを実施している最中に、別の通信装置からＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信したことを示す。

従って、失敗要因が、「他のデバイスとＧｒｏｕｐ Ｆｏｒｍａｔｉｏｎ中である」ことである場合には、自動再試行カテゴリに分類し、ある一定の時間待機した後、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出するようにする。

失敗要因番号が「５」により表される失敗要因内容は、「プロトコルエラー」であることを表す。「プロトコルエラー」は、ｒｅｑｕｅｓｔフレームとｒｅｓｐｏｎｓｅフレームの受け渡しの過程で、何らかの問題が発生したことを表す。この場合は、通信プロトコルが正しくないとみなされた部分の設定を変更して自動的に再試行するようにしてもよい。また、この場合は、通信プロトコルが正しくなかったことと、ｒｅｑｕｅｓｔフレームとｒｅｓｐｏｎｓｅフレームの受け渡しにおいて発生した問題の要因と、修正案の候補とを表示し、ユーザに、了承するかどうかの入力を促す方が望ましい。

従って、失敗要因が、「プロトコルエラー」である場合には、ユーザ設定カテゴリに分類し、ユーザが、上下又は左右に、カーソルを動かすことにより、プロトコルの設定変更をできるようにする。受信情報解析部１３０は、設定情報更新部１２８に、ユーザによる設定変更を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された設定変更に従って、設定情報を更新する。

失敗要因番号が「６」により表される失敗要因内容は、「指定された情報の出所に、情報が見あたらない」ことを表す。「指定された情報の出所に、情報が見あたらない」ことは、ＷＰＳ１．０仕様（Wi-Fi Protected Setup Specification Version 1.0h）の、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤとして定義される、「情報の出所がどこであるか」を指定する領域に設定された値、すなわち、その情報の出所に、情報が存在しないことを示す。例えば、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤがＰＩＮ（Personal Identification Number）に設定されているにもかかわらず、通信相手側で、ＰＩＮを検出できなかった場合に、この失敗要因となる。この場合は、代わりとなる情報の出所の選択肢を表示するようにしてもよい。

従って、失敗要因が、「指定された情報の出所に、情報が見あたらない」ことである場合には、ユーザ設定カテゴリに分類し、ユーザが、上下又は左右に、カーソルを動かすことにより、代わりとなる情報の出所を設定することができるようにする。受信情報解析部１３０は、設定情報更新部１２８に、ユーザにより設定された代わりとなる情報の出所を表す情報を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された代わりとなる情報の出所を表す情報に従って、設定情報を更新する。

失敗要因番号が「７」により表される失敗要因内容は、「チャンネルが一致しない」ことを表す。「チャンネルが一致しない」ことは、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム中で設定されたチャンネルが、通信相手となる通信装置により設定されたチャネルと一致しないことを示す。この場合、再度、通信相手となる通信装置が存在するチャンネルを検出し、該チャンネルを設定してＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを再送出する必要がある。

従って、失敗要因が、「チャンネルが一致しない」ことである場合には、自動再試行カテゴリに分類し、通信相手となる通信装置を検出した後、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出するようにする。

失敗要因番号が「８」により表される失敗要因内容は、「Ｐ２Ｐ Ｇｒｏｕｐ名が一致しない」ことを表す。これは、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム中で設定したＰ２Ｐ Ｇｒｏｕｐ名が、通信相手となる通信装置のＰ２Ｐ Ｇｒｏｕｐと一致しないことを示す。この場合、受信情報保存部２２１に保存したＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム中に設定されているＰ２Ｐ Ｇｒｏｕｐの値を設定し、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを再送出する必要がある。

従って、失敗要因が、「Ｐ２Ｐ Ｇｒｏｕｐ名が一致しない」である場合には、自動再試行カテゴリに分類し、通信相手となる通信装置と同じＰ２Ｐ Ｇｒｏｕｐの値を設定した後、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出するようにする。

失敗要因番号が「９」により表される失敗要因内容は、「両方のＰ２Ｐ ＤｅｖｉｃｅがＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになることを希望している」ことを表す。「両方のＰ２Ｐ ＤｅｖｉｃｅがＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになることを希望している」ことは、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送出した側も、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送出した側も、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになりたい度合いを表す値を、最も高い設定値として定義されている値１５に設定しているために、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗したことを表す。この場合、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになりたい度合いを表す値を、自動的に１５よりも小さな値に設定して再接続するようにしてもよい。また、元々最大値である１５に設定しているのは、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒにならなければならない何らかの理由があるためであると考えられる。そのため、１５以外の値に変更することが可能であるかは、ユーザの判断に委ねた方が望ましい。そこで、情報表示部１１８に、「１５以外の値に設定してよいかどうか」と表示し、ユーザが、１５以外の値に設定してよいかどうかを選択できるようにする。

従って、失敗要因が、「両方のＰ２Ｐ ＤｅｖｉｃｅがＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒになることを希望している」ことである場合には、ユーザ設定カテゴリに分類し、ユーザが、カーソルを上下又は左右に動かすことにより、設定することができるようにする。受信情報解析部１３０は、設定情報更新部１２８に、ユーザによる設定変更を表す情報を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された設定変更を表す情報に従って、設定情報を更新する。

失敗要因番号が「１０」により表される失敗要因内容は、「指定された情報の出所が、使用できる状態にない」ことを表す。「指定された情報の出所が、使用できる状態にない」ことは、Ｐｒｏｖｉｓｉｏｎｉｎｇ ｉｎｆｏｒｍａｔｉｏｎが見あたらないことを示す。具体的には、ＷＰＳ１．０仕様（Wi-Fi Protected Setup Specification Version 1.0h）の、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤとして定義される、「情報の出所がどこであるか」を指定する領域に設定された値、すなわち、その情報の出所として指定された対象が、使用できる状態にないことを示す。例えば、Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ ＩＤがＰＩＮ（Personal Identification Number）に設定されているにもかかわらず、通信相手側で、ＰＩＮが有効ではないと判断された場合に、この失敗要因となる。この場合は、代わりとなる情報の出所の選択肢を表示し、ユーザが、所望の情報の出所となる対象に情報を書き込み、選択肢の中から、対象となる出所を選択するのが望ましい。

従って、失敗要因が、「指定された情報の出所が、使用できる状態にない」である場合には、ユーザ設定カテゴリに分類し、ユーザが、上下又は左右に、カーソルを動かすことにより、代わりとなる情報の出所を設定することができるようにする。受信情報解析部１３０は、設定情報更新部１２８に、ユーザにより選択された代わりとなる情報の出所を表す情報を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された代わりとなる情報の出所を表す情報に従って、設定情報を更新する。

上述した失敗要因内容のうち、失敗要因番号が「２」により表される失敗要因内容については、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信した通信装置に、停止させるべき通信装置を表す情報を通知する必要がある。例えば、グループオーナ（Ｇｒｏｕｐ Ｏｗｎｅｒ）に、停止させるべき通信装置を表す情報を通知する。この場合、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信した通信装置がＧｒｏｕｐ Ｏｗｎｅｒである場合に該当する。

ここで、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒに、ユーザにより選択された停止させるべき通信装置を表す情報を通知する方法について説明する。

一例として、ユーザが独自で利用することが可能な領域であるベンダースペシフィックアトリビュート（Ｖｅｎｄｏｒ ｓｐｅｃｉｆｉｃ ａｔｔｒｉｂｕｔｅ）を、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒ側とＰ２Ｐ Ｃｌｉｅｎｔ側で、共通に用いることを前提にする。

Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒから送出されるＢｅａｃｏｎフレーム又はＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームには、該Ｐ２Ｐ Ｇｒｏｕｐ ＯｗｎｅｒのＰ２Ｐ Ｇｒｏｕｐに参加している全通信装置に対する、カテゴリＩＤ（Ｃａｔｅｇｏｒｙ ＩＤ）及びサブカテゴリＩＤ（Ｓｕｂ Ｃａｔｅｇｏｒｙ ＩＤ）と、Ｐ２Ｐ Ｄｅｖｉｃｅが含まれている。Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒから送出されるＢｅａｃｏｎフレーム又はＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームに、該Ｐ２Ｐ Ｇｒｏｕｐ ＯｗｎｅｒのＰ２Ｐ Ｇｒｏｕｐに参加している全通信装置に対する、カテゴリＩＤ及びサブカテゴリＩＤと、Ｐ２Ｐ Ｄｅｖｉｃｅが含まれているため、通信装置の種類とＭＡＣアドレスとの対応を把握することが可能となる。

接続を要求した通信装置においては、ユーザが選択した通信装置に対応するＭＡＣアドレスを、Ｖｅｎｄｏｒ ｓｐｅｃｉｆｉｃ ａｔｔｒｉｂｕｔｅに設定し、再度Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを送出する。該Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを受信したＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒは、Ｖｅｎｄｏｒ ｓｐｅｃｉｆｉｃ ａｔｔｒｉｂｕｔｅ中のＭＡＣアドレスを解析することにより、ユーザにより指定された通信装置を特定できる。Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒは、該ユーザにより指定された通信装置に対して、切断要求となるディスアドシエーション（Ｄｉｓａｓｓｏｃｉａｔｉｏｎ）フレームを送出する。該Ｄｉｓａｓｓｏｃｉａｔｉｏｎフレームを受信した通信装置は、Ｐ２Ｐ Ｇｒｏｕｐ ＯｗｎｅｒのＰ２Ｐ Ｇｒｏｕｐから離れる。

図６は、ユーザにより停止させるべき通信装置が選択された際の処理を示すシーケンスチャートである。

Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒは、接続を要求したＰ２Ｐ クライアントに、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを送出する（ステップＳ６０２）。該Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅには、Ｐ２Ｐ Ｇｒｏｕｐ ＯｗｎｅｒのＰ２Ｐ Ｇｒｏｕｐに参加している全通信装置を表す情報と、該全通信装置の種類と、ＭＡＣアドレスとが含まれる。

接続を要求したＰ２Ｐ クライアントは、通信装置のリストを表示する（ステップＳ６０４）。ユーザは、該通信装置のリストを参照し、停止させるべき通信装置を選択できる。

接続を要求したＰ２Ｐクライアントは、ユーザにより選択された停止させるべき通信装置を設定する（ステップＳ６０６）。

接続を要求したＰ２Ｐクライアントは、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒに、ＰｒｏｂｅＲｅｑｕｅｓｔを送出する（ステップＳ６０８）。該Ｐｒｏｂｅ Ｒｅｑｕｅｓｔには、ユーザにより選択された停止させるべき通信装置を表す情報が含まれる。例えば、Ｖｅｎｄｅｒ Ｓｐｅｃｉｆｉｃ ＩＥに、停止させるべき通信装置のＭＡＣアドレスが設定される。

Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒは、Ｐ２ＰクライアントからのＰｒｏｂｅ Ｒｅｑｕｅｓｔに含まれる停止させるべき通信装置を表す情報に従って、該停止させるべき通信装置に、切断要求を送信する（ステップＳ６１０）。

なお、ここでは、表示される通信装置のリストに対し、ユーザが停止させるべき通信装置を選択してＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒに伝える手法について述べた。勿論、表示される通信装置のリストを参照して、ユーザ自身が、いずれかの通信装置を手動で停止させた後、再度、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを送出するように操作してもよい。

＜通信装置の動作＞
図７は、本通信装置１００の動作を示すフローチャートである。

図７には、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎにおいて、失敗要因に応じて処理を振り分けるフローが示される。

本通信装置１００は、他の通信装置からのＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに基づいて、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したか失敗したかを判定する（ステップＳ７０２）。例えば、他の通信装置からのＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームは、受信情報保存部１３８に保存される。受信情報解析部１３０は、受信情報保存部１３８に保存された他の通信装置からのＧＯ Ｎｅｇｏｔｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームのＳｔａｔｕｓ Ｃｏｄｅ Ｆｉｅｌｄを参照し、Ｓｔａｔｕｓ Ｃｏｄｅが、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗したことを表す「１」−「１０」に該当するかどうかを判定する。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功したと判定した場合（ステップＳ７０２：ＮＯ）、本通信装置１００は失敗要因内容に応じて、その対策として取り得る処理を行わない。この場合、本通信装置１００は、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが成功しているので、他の通信装置に、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｃｏｎｆｏｒｍａｔｉｏｎを送信する。

Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗したと判定した場合（ステップＳ７０２：ＹＥＳ）、本通信装置１００はＳｔａｔｕｓ Ｃｏｄｅ（失敗要因番号）に基づいて、失敗要因内容をチェックする（ステップＳ７０４）。例えば、受信情報解析部１３０は、失敗要因番号に対応する失敗要因内容をチェックする。

本通信装置１００は、ステップＳ６０４によりチェックされた失敗要因内容が、「ユーザ設定カテゴリ」に分類されるかどうかを判定する（ステップＳ７０６）。例えば、受信情報解析部１３０は、失敗要因内容が「ユーザ設定カテゴリ」に分類されるかどうかを判定する。

図８は、失敗要因番号と、該失敗要因番号に対応する失敗要因内容と、該失敗要因内容に対する対策のカテゴリとを対応付けたテーブル示す。失敗要因番号と、該失敗要因番号に対応する対策のカテゴリとを対応付けたテーブルであってもよい。該テーブルは、例えば、メモリ１３６に格納される。受信情報解析部１３０は、該テーブルを参照し、ステップＳ７０４によりチェックされた失敗要因内容が、「ユーザ設定カテゴリ」に分類されるかどうかを判定する。

「ユーザ設定カテゴリ」に分類されると判定された場合（ステップＳ７０６：ＹＥＳ）、本通信装置１００は、ユーザに、失敗要因内容と、該失敗要因内容を回避するための設定案とを通知するために表示する。例えば、情報表示部１１８は、失敗要因内容と、該失敗要因内容を回避するための設定案とを通知するために表示する。なお、情報表示部１１８は、表示に使用する言語を設定したり、変更できたりできるのが好ましい。例えば、表示に使用する言語は、ユーザＩ／Ｆ１１６を操作することにより選択できるようにしてもよい。

「ユーザ設定カテゴリ」に分類されると判定されない場合（ステップＳ７０６：ＮＯ）、本通信装置１００は、失敗要因内容が「自動再試行カテゴリ」に分類されると判定する（ステップＳ７１０）。例えば、受信情報解析部１３０は、失敗要因内容を「自動再試行カテゴリ」に分類する。

本通信装置１００は、失敗要因内容に応じて適切な処理を行い、再度ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを発行する（ステップＳ７１２）。受信情報解析部１３０は、自動的に設定変更を行う。受信情報解析部１３０は、設定情報更新部１２８に、設定変更された内容を入力する。設定情報更新部１２８は、受信情報解析部１３０により入力された設定変更された内容に従って、設定情報を更新する。

図７に示されるフローチャートのステップＳ７０６において、自動再試行カテゴリへの分類に該当するかどうかが判定されてもよい。この場合、自動再試行カテゴリに分類されると判定された場合に、失敗要因内容に応じて適切な処理を行うようにしてもよい。自動再試行カテゴリに分類されないと判定された場合に、失敗要因の通知および、再試行のための設定案をユーザに通知するようにしてもよい。

本実施例によれば、失敗要因内容に応じて、適切な対策を取ることができるため、Ｗｉ−Ｆｉ ＤｉｒｅｃｔにおけるＧｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの再実施時の成功率を向上させることができる。

本通信装置は、
複数の通信装置を含む通信システムにおける１の通信装置であって、
他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する受信情報解析部としての、情報交換成功判定部と、
該情報交換成功判定部により情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する受信情報解析部としての、自動設定変更判定部と、
該自動設定変更判定部により自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定部により自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う受信情報解析部及び設定情報更新部としての、設定変更部と、
該設定変更部により変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う通信プロトコル制御部としての、再試行部と
を有する、通信装置。

ユーザが失敗要因を意識することなく、自動的にネットワークへの参加の再試行を行うことができる。さらに、再試行の際に成功する確率を向上させることができる。

これまでの無線ＬＡＮでは、初めから、ステーション、アクセスポイントの役割が決まっていた。ところが、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒを決定する必要があるため、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎを実施する必要がある。本実施例では、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが失敗した場合に、その失敗要因に応じた最適な対策をおこなった後、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎを再実施する際の成功率を向上させる効果がある。すなわち、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔにおいて、特に大きな効果を奏する。

さらに、
情報交換が失敗した要因と、自動的に設定変更を行うべきであることを表す情報又はユーザによる設定変更に従うことを表す情報とを対応付けたテーブル
を有し、
前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定された場合に、前記テーブルを参照し、自動的に設定変更を行うべきかどうかを判定する。

さらに、
該自動設定変更判定部により自動的に設定変更を行うべきでないと判定された場合に、前記情報交換が失敗した要因と、該情報交換が失敗した要因に対応する設定の変更を促すための表示データを作成する表示データ作成部と、
該表示データ作成部により作成された表示データに従って、表示を行う表示部と
を有する。

ユーザが意図しない内容に自動的に設定されてしまうことを回避することができる。また、ユーザが再試行のため設定を行うため、より再試行時のネットワークへの参加の成功率を向上させることができる。

さらに、
前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定され、且つ前記情報交換が失敗した要因が前記他の通信装置との間で設定されているプロトコルが異なることである場合に、自動的に設定変更を行うべきでないと判定し、
前記設定変更部は、ユーザにより了承されたプロトコルに従って、設定変更を行い、
前記再試行部は、前記設定変更部により変更されたプロトコルに従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う。

さらに、
前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定され、且つ前記情報交換が失敗した要因が前記他の通信装置の接続可能な通信装置の数を超えることである場合に、自動的に設定変更を行うべきでないと判定し、
前記表示データ作成部は、前記情報交換が失敗した要因に対応する設定の変更を促すための表示データとして、前記他の通信装置に接続されている装置から、停止させる装置を選択させるための装置のリストを作成する。

さらに、
前記装置のリストに含まれる通信装置は、最も長い間利用されていない順である。

停止させる対象となる可能性の高い装置を、できるだけ早くユーザが選択できることが可能となる。

さらに、
前記ネゴシエーションは、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に従ったものである。

失敗要因がＳｔａｔｕｓ Ｃｏｄｅとして規定されているため、失敗要因について互換性を有し、異なるベンダーの通信装置との接続および再試行を可能にできる。失敗要因情報が規定されている他の通信プロトコルを用いる通信装置に適用することもできる。

さらに、
前記応答信号を保存する受信情報保存部
を有し、
前記情報交換成功判定部は、前記受信情報保存部に保存された応答信号に基づいて、前記他の通信装置との間での情報交換が成功したかどうかを判定する。

情報交換相手となる他の通信装置からの情報と、当該通信装置が送出した情報とを比較することが可能となる。

さらに、
表示データ作成部は、アプリケーション層で、前記情報交換が失敗した要因と、該要因に対応する設定の変更を促すための表示データを作成する。

ユーザへの通知の対象となる失敗要因については、通信プロトコルにおける再試行のための処理の追加が不要であるという効果を奏する。

さらに、
前記設定変更を入力するためのユーザＩ／Ｆ
を有し、
前記表示データ作成部は、前記情報交換が失敗した要因に対応する設定の変更を促すための表示データとして、１又は複数の選択肢を表す情報を表示し、
前記設定変更部は、ユーザＩ／Ｆにより入力されるべき設定変更に従って設定変更を行う。

ユーザ側での操作がし易く、設定内容を入力しやすい、という効果を奏する。

さらに、
前記表示データ作成部は、ユーザにより設定された言語に従って、前記情報交換が失敗した要因と、該要因に対応する設定の変更を促すための表示データを作成する。

より多くのユーザにとって、再試行のための設定が可能となる。

本通信方法は、
複数の通信装置を含む通信システムにおける１の通信装置における方法であって、
他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する情報交換成功判定ステップと、
該情報交換成功判定ステップにより情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する自動設定変更判定ステップと、
該自動設定変更判定ステップにより自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定ステップにより自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う設定変更ステップと、
該設定変更ステップにより変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う再試行ステップと
を有する。

以上、本発明は特定の実施例を参照しながら説明されてきたが、各実施例は単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。説明の便宜上、本発明の実施例に従った装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウエアで又はそれらの組み合わせで実現されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が包含される。

１００ 通信装置
１０２ 機器制御部(CPU: Central Processing Unit)
１０４ メインＣＰＵ(Central Processing Unit)
１０６ メモリ
１０８ オペレーティングシステム
１１０ ドライバ
１１２ アプリケーションソフトウェア
１１４ 表示データ作成部
１１６ ユーザＩ／Ｆ
１１８ 情報表示部
１２０ バスコントローラ
１２２ 通信コントローラ
１２４ ファームウェア
１２６ 通信プロトコル制御部
１２８ 設定情報更新部
１３０ 受信情報解析部
１３２ ＭＡＣハードウェア
１３４ リアルタイムオペレーティングシステム
１３６ メモリ
１３８ 受信情報保存部
１４０ サブＣＰＵ
１４２ ＰＨＹ(Physical Layer)部
１４４ ベースバンド部
１４６ ＲＦ(Radio Frequency)部
１４８ アンテナ
１５０ バス

Ｗｉ−Ｆｉ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ（Ｐ２Ｐ）Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．１ ＩＥＥＥ Ｓｔａｎｄａｒｄ ｆｏｒ Ｌｏｃａｌ ａｎｄ ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋｓ Ｐｏｒｔ−Ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｗｉｒｅｌｅｓｓ Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．０

Claims (12)

1. 複数の通信装置を含む通信システムにおける１の通信装置であって、
   他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する情報交換成功判定部と、
   該情報交換成功判定部により情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する自動設定変更判定部と、
   該自動設定変更判定部により自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定部により自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う設定変更部と、
   該設定変更部により変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う再試行部と
   を有する、通信装置。
2. 請求項１に記載の通信装置において、
   情報交換が失敗した要因と、自動的に設定変更を行うべきであることを表す情報又はユーザによる設定変更に従うことを表す情報とを対応付けたテーブル
   を有し、
   前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定された場合に、前記テーブルを参照し、自動的に設定変更を行うべきかどうかを判定する、通信装置。
3. 請求項１又は２に記載の通信装置において、
   該自動設定変更判定部により自動的に設定変更を行うべきでないと判定された場合に、前記情報交換が失敗した要因と、該情報交換が失敗した要因に対応する設定の変更を促すための表示データを作成する表示データ作成部と、
   該表示データ作成部により作成された表示データに従って、表示を行う表示部と
   を有する、通信装置。
4. 請求項１ないし３のいずれか１項に記載の通信装置において、
   前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定され、且つ前記情報交換が失敗した要因が前記他の通信装置との間で設定されているプロトコルが異なることである場合に、自動的に設定変更を行うべきでないと判定し、
   前記設定変更部は、ユーザにより了承されたプロトコルに従って、設定変更を行い、
   前記再試行部は、前記設定変更部により変更されたプロトコルに従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う、通信装置。
5. 請求項３に記載の通信装置において、
   前記自動設定変更判定部は、前記情報交換成功判定部により情報交換が失敗したと判定され、且つ前記情報交換が失敗した要因が前記他の通信装置の接続可能な通信装置の数を超えることである場合に、自動的に設定変更を行うべきでないと判定し、
   前記表示データ作成部は、前記情報交換が失敗した要因に対応する設定の変更を促すための表示データとして、前記他の通信装置に接続されている装置から、停止させる装置を選択させるための装置のリストを作成する、通信装置。
6. 請求項５に記載の通信装置において、
   前記装置のリストに含まれる通信装置は、最も長い間利用されていない順である、通信装置。
7. 請求項１ないし６のいずれか１項に記載の通信装置において、
   前記ネゴシエーションは、Ｗｉ−Ｆｉ
   Ｄｉｒｅｃｔ仕様に従ったものである、通信装置。
8. 請求項１に記載の通信装置において、
   前記応答信号を保存する受信情報保存部
   を有し、
   前記情報交換成功判定部は、前記受信情報保存部に保存された応答信号に基づいて、前記他の通信装置との間での情報交換が成功したかどうかを判定する、通信装置。
9. 請求項３に記載の通信装置において、
   表示データ作成部は、アプリケーション層で、前記情報交換が失敗した要因と、該要因に対応する設定の変更を促すための表示データを作成する、通信装置。
10. 請求項３に記載の通信装置において、
    前記設定変更を入力するためのユーザＩ／Ｆ
    を有し、
    前記表示データ作成部は、前記情報交換が失敗した要因に対応する設定の変更を促すための表示データとして、１又は複数の選択肢を表す情報を表示し、
    前記設定変更部は、ユーザＩ／Ｆにより入力されるべき設定変更に従って設定変更を行う、通信装置。
11. 請求項３に記載の通信装置において、
    前記表示データ作成部は、ユーザにより設定された言語に従って、前記情報交換が失敗した要因と、該要因に対応する設定の変更を促すための表示データを作成する、通信装置。
12. 複数の通信装置を含む通信システムにおける１の通信装置における通信方法であって、
    他の通信装置との間で、アクセスポイントとして機能するためのネゴシエーションの際に、該他の通信装置から送信されるべき応答信号に基づいて、該他の通信装置との間での情報交換が成功したかどうかを判定する情報交換成功判定ステップと、
    該情報交換成功判定ステップにより情報交換が失敗したと判定された場合に、該情報交換が失敗した要因に応じて、自動的に設定変更を行うべきかどうかを判定する自動設定変更判定ステップと、
    該自動設定変更判定ステップにより自動的に設定変更を行うべきと判定された場合に、自動的に設定変更を行い、該自動設定変更判定ステップにより自動的に設定変更を行うべきでないと判定された場合に、ユーザによる設定変更に従って、設定変更を行う設定変更ステップと、
    該設定変更ステップにより変更された設定に従って、前記他の通信装置との間で、前記ネゴシエーションを再度行う再試行ステップと
    を有する、通信方法。

Images