JP6880719B2 - 通信装置、通信方法、電子時計及びプログラム - Google Patents

Description

本発明は、通信装置、通信方法、電子時計及びこの通信方法を実行するためのプログラムに関する。

従来、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ：登録商標）などの近距離無線通信を用いて種々の情報をやり取りすることが可能な電子装置が存在する。ブルートゥースは、近距離で各種装置を無線で連結してデータをやり取りすることができる近距離無線通信規約である。ブルートゥース通信方法には、ＢＲ／ＥＤＲ（Ｂａｓｉｃ Ｒａｔｅ／Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅ）と、低電力方式であるＬＥ（Ｌｏｗ Ｅｎｅｒｇｙ）とがある。ＢＲ／ＥＤＲはブルートゥースクラシック（Ｂｌｕｅｔｏｏｔｈ Ｃｌａｓｓｉｃ）とも呼ばれる。ブルートゥース４．０から適用されたブルートゥースローエナジー（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ、以下ＢＬＥと称する。）は、少ない電力を消耗して数百キロバイト（ＫＢ）の情報を安定的に提供することができる。このようなＢＬＥ技術はブルートゥースクラシックに比べて動作を簡単にしてエネルギー消費を減らす。最近発売されたスマートバンド、スマートウォッチ、スマートグラス、等のウェアラブル無線通信装置のほとんどはＢＬＥ技術を用いて無線通信を行う。

このような近距離無線通信により、複数の電子装置のそれぞれが個別に取得したり保持したりする情報を、他の電子装置で容易に取得することが可能になっている。例えば、特開２０１４−１７５８３０号公報には、効率的に通信を行うために、二つの通信装置がＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）値をやりとりし、やりとりしたＭＴＵ値に応じて通信期間を割り当てる技術が開示されている。

特開２０１４−１７５８３０号公報

しかし、上記特許文献１に開示された技術は、送受信する情報の種類に関しては考慮していない。従って、複数の種類の情報を通信しようとする場合は、通信装置間の通信回数が、通信する情報の種類の数に応じて増加する。そのため、通信する情報の種類の数が多いと、通信装置の消費電流及び処理負荷が増加する。

この発明は、無線通信装置の間の通信の効率性を高める方法、この方法を実行する通信装置、電子時計及びプログラムを提供することを目的とする。

本発明の１つの態様は、無線通信のできる装置であって、通信パケットを他の通信装置と送受信する通信部と、一つ以上の種類の設定情報を格納するメモリと、プロセッサと、を備え、前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一である。

また、本発明の他の１つの態様は、無線通信のできる装置であって、他の通信装置からサービス情報を受信し、前記他の通信装置と通信パケットを送受信する通信部と、一つ以上の種類の設定情報を格納するメモリと、プロセッサと、を備え、前記プロセッサは、前記他の通信装置から前記一つ以上の種類の設定情報の更新の有無を示す判別情報を受信し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一である。

本発明によると、無線通信装置の間の通信の効率性を高めることができる。しかし、本発明の目的と効果は上記のものに制限されないし、下記の詳細な説明と添付の図面から本発明の他の目的と効果を理解することができる。

以下の詳細な記述が以下の図面と合わせて考慮されると、本願のより深い理解が得られる。これらの図面は例示に過ぎず、本発明の範囲を限定するものではない。
本明細書において提案された方法が適用されることができる無線通信システムの一例を示す図である。 本明細書において提案された方法を具現することができる装置の内部ブロック図の一例を示す。 本明細書において提案された方法が適用されることができるＢＬＥ通信アーキテクチャーの一例を示す図である。 典型的なサービスディスカバリーメカニズムを示す図である。 ＧＡＴＴサーバに格納されるアトリビュート（Ａｔｔｒｉｂｕｔｅ）の通常の構造の一例を示す。 （Ａ）はＢＬＥプロトコルによって定義されるパケット構造を示し、（Ｂ）はアトリビュート値をやり取りするためのアトリビュートプロトコルＰＤＵの構造の一例を示す。 アトリビュートプロトコルＰＤＵのアトリビュートオペコード（Ａｔｔｒｉｂｕｔｅ Ｏｐｃｏｄｅ）及びパラメーターのリストの一例を示すテーブルである。 通常のアトリビュートデータベースの一例を示す図である。 サーバとクライアントとがデータ通信を行う通常の方法を示す概念図である。 本発明の複数の実施形態において設定変更を示す判別情報として用いられるビットマップの一例を示す図である。 ビットマップを用いてサーバとクライアントとの設定を動機させる方法を示す概念図である。 本発明の一実施形態に係るアトリビュートデータベースの一例を示す図である。 本発明の他の実施形態に係るアトリビュートデータベースの一例を示す図である。 本発明の一実施形態に係るサーバとクライアントとが常時接続するパターンにおいてサーバとクライアント間のデータ通信方法を示す図である。 本発明の一実施形態に係る通信プロセスを示すフローチャートである。 本発明の一実施形態に係るサーバとクライアントとの間に再接続が発生するパターンにおいてサーバとクライアント間のデータ通信方法を示す図である。 本発明の一実施形態に係る通信プロセスを示すフローチャートである。 本発明の一実施形態に係るサーバとクライアント間のデータ通信方法を示す図である。 本発明の他の実施形態に係るアトリビュートデータベースの一例を示す図である。 本発明の一実施形態に係るサーバとクライアントとが常時接続するパターンにおいてサーバとクライアント間のデータ通信方法を示す図である。 本発明の一実施形態に係るサーバとクライアントとの間に再接続が発生するパターンにおいてサーバとクライアント間のデータ通信方法を示す図である。

本明細書においては、主に本発明をブルートゥース（登録商標）、特に、ＢＬＥに適用した実施形態について説明するが、本発明の適用分野はブルートゥースに限定されない。本発明は、サービスディスカバリーが必要な全ての通信方式に対して適用可能である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。

図１は、後述する実施形態に共通する図であって、本明細書において提案された方法が適用されることができる無線通信システムの一例を示す図である。以下に記述される実施形態において、第１の装置と第２の装置とは、ブルートゥースローエナジー（以下、『ＢＬＥ』と称する。）技術を利用して近距離無線通信を行う。無線通信システム１０は少なくとも第１の装置１００及びＢＬＥによって第１の装置１００と無線接続されてデータ交換が可能な第２の装置２００から成る。本発明が適用されることができる第１の装置１００は、例えば、腕時計型端末装置の一種である電子時計である。しかし、第１の装置１００はこの例に限定されなく、ＢＬＥ通信が可能な装置であればその種類や形態を問わない。第１の装置１００は、例えば、デジタルカメラ、デジタル体重計等のヘルス機器、又は、スマートバンド等のウェアラブル機器であっても良い。

本発明が適用されることができる第２の装置２００は、例えば、携帯電話の一種であるスマートフォンであり、移動通信網２０に接続されている。しかし、第２の装置２００はこの例に限定されなく、近距離無線通信が可能な装置であればその種類や形態を問わない。

以下に詳細に説明するように、ＢＬＥのＡＴＴ（Ａｔｔｒｉｂｕｔｅ Ｐｒｏｔｏｃｏｌ）はサーバ／クライアントの構造で相手装置のデータに接近するための規則を定義する。サーバはサービスを提供し、クライアントはサーバに要請してサーバが有するサービスに関連した情報を得ることができる。説明の便宜のために、以下では特別な説明がない限り第１の装置１００をサーバと、第２の装置２００のアプリケーションをクライアントとして説明する。しかし、第１の装置１００は他の装置との関係においてクライアントとして動作することができ、第２の装置は他のデバイスとの関係においてサーバとして動作することができる。即ち、ＢＬＥ通信システムにおいて一つの装置はサーバ又はクライアントとして動作することが可能であり、必要な場合、同時にサーバ及びクライアントとして動作することも可能である。

第２の装置２００は、第１の装置１００にデータを要求することができる。第１の装置１００は、第２の装置２００からデータ要求メッセージを受信する場合、応答（Ｒｅｓｐｏｎｓｅ）メッセージによって第２の装置２００へデータを提供する。また、第１の装置１００は第２の装置２００へデータを通知するために第２の装置２００に対して告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージ又は指示（Ｉｎｄｉｃａｔｉｏｎ）メッセージを送信する。第１の装置１００が第２の装置２００へ指示メッセージを送信した場合に、当該指示メッセージが第２の装置２００によって成功的に受信されれば第２の装置２００は当該指示メッセージに対する確認（Ｃｏｎｆｉｒｍ）メッセージを第１の装置１００へ送信する。また、第２の装置２００は、第１の装置１００に対してデータの書込みを要請するために要求（Ｒｅｑｕｅｓｔ）メッセージ又は命令（Ｃｏｍｍａｎｄ）メッセージを送信する。第２の装置２００が第１の装置１００へ要求メッセージを送信した場合に、データの書込みが成功的に行われれば、第１の装置１００は第２の装置２００へ応答（Ｒｅｓｐｏｎｓｅ）メッセージを送信する。

第１の装置１００又は第２の装置２００は、他の装置とメッセージを送受信する過程で出力部、例えば、ディスプレーを通じてユーザにデータ情報を提供したり、入力部、例えば、Ｕｓｅｒ Ｉｎｐｕｔ Ｉｎｔｅｒｆａｃｅを通じてユーザから入力される要請を受信したりすることができる。また、メモリからデータを読み出したり、新しいデータをメモリに記入したりすることもできる。

図２は、本明細書において提案された方法を具現することができる装置の内部ブロック図の一例を示す。図２（Ａ）は第１の装置１００の内部ブロック図であり、図２（Ｂ）は第２の装置２００の内部ブロック図である。

図２（Ａ）に示されたように、第１の装置１００は近距離通信部１０２と、プロセッサ１０４と、電源部１０６と、メモリ１０８と、時計部１１０と、入力部１１２と、表示部１１４とを含む。近距離通信部１０２は近距離無線通信技術、例えば、ブルートゥースを利用して装置の間の要求／応答、命令、告知、指示／確認メッセージ、又は、データの送受信を可能にするインターフェースと、無線信号を処理するベースバンド回路とを含む。本実施形態において、近距離通信部１０２はＢＬＥをサポートする。近距離通信部１０２の少なくとも一部の機能はソフトウェアによって具現されることができ、ソフトウェアによって具現される場合、上記機能を実行するプログラムの形態としてメモリ１０８に格納されることができる。

プロセッサ１０４は第１の装置１００の全体的な動作を制御する。プロセッサ１０４は、制御ユニット（Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、コントローラー等と称されることもある。プロセッサ１０４はＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、他のチップセット、論理回路、及び／又は、データ処理装置を含むことができる。電源部１０６は図示を省略するが、バッテリー及び電源管理部を含む。メモリ１０８はプロセッサ１０４によって実行されるコンピュータプログラム命令、ファームウェア等の各種ソフトウェア、及び／又は、プロセッサ１０４が必要とするデータ又はプロセッサ１０４の処理結果を記憶するために使われる。メモリ１０８は第１の装置１００に組み込まれた、又は、第１の装置１００から着脱可能なＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、又はディスクドライブ等の１つ又はそれ以上の任意の記憶装置を含む。メモリ１０８はプロセッサ１０４に組み込むことも可能である。

時計部１１０は図示を省略するが、例えば、システムクロック又は発振器によって生成される信号から時刻信号を生成する時計回路であるカウンタを含み、現在の時刻を計時して時刻情報を生成する。時計部１１０は生成した時刻情報をプロセッサ１０４に出力する。時計部１１０をプロセッサ２２内に組み込むこともできる。入力部１１２は各種キー、スイッチ、及び／又は、タッチパネル等から構成され、ユーザの入力部１１２の操作に応じて各種のデータが入力される。表示部１１４はＬＣＤ、ＯＬＥＤ等の表示装置及び駆動回路を含み、現在の時刻等の情報を表示する。

第１の装置１００は、平常時は表示部１１４に時計部１１０で計時されている現在の時刻を表示する。近距離通信部１０２を通じて第２の装置２００から現在の時刻に関するデータを受信した場合は、該当データが示す時刻を時計部１１０に設定することによって、第１の装置１００の時刻を第２の装置２００の時刻に同期させる。

図２（Ｂ）に示されたように、第２の装置２００は、遠距離通信処理部２０２と、近距離通信部２０４と、プロセッサ２０６と、メモリ２０８と、電源部２１０と、入力部２１２と、表示部２１４とを含む。プロセッサ２０６は時計部２１６を含む。遠距離通信処理部２０２は、３Ｇ、ＬＴＥ等の携帯電話システムの基地局と通信することによって、第２の装置２００を携帯電話として機能させる。遠距離通信処理部２０２はアンテナを通じて受信、又は、送信される信号を増幅するアンプ、トランシーバー、デジタルベースバンドプロセッサ、音声入力回路、再生回路等を含むが、これらの周知の構成要素に対しては図示及び説明を省略する。また、遠距離通信処理部２０２を通じて移動通信網２０から正確な時刻データを取得することで時計部２１６が正確な時刻情報を保持することができる。上記のように、第２の装置２００は時計部２１６が保持している時刻情報を第１の装置１００に伝送することができる。

近距離通信部２０４は、近距離無線通信技術、例えば、ブルートゥースを利用して装置の間の要求／応答、命令、告知、指示／確認メッセージ、又は、データの送受信を可能にするインターフェースと、無線信号を処理するベースバンド回路とを含む。本実施形態において、近距離通信部２０４はＢＬＥをサポートする。近距離通信部２０４の少なくとも一部の機能はソフトウェアによって具現されることができ、ソフトウェアによって具現される場合、上記機能を実行するプログラムの形態としてメモリ２０８に格納されることができる。

プロセッサ２０６は第２の装置２００の全体的な動作を制御し、例えば、アプリケーションプロセッサである。本実施形態においては、プロセッサ２０６が時計部２１６を含むように構成されているが、実施形態によっては時計部２１６が別個の構成要素として含まれることもできる。メモリ２０８は、プロセッサ２０６によって実行されるコンピュータプログラム命令、ファームウェア等の各種ソフトウェア、及び／又は、プロセッサ２０６が必要とするデータ又はプロセッサ２０６の処理結果を記憶するために使われる。メモリ２０８は第２の装置２００に組み込まれた、又は、第２の装置２００から着脱可能なＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、又はディスクドライブ、等の１つ又はそれ以上の任意の記憶装置を含む。メモリ２０８はプロセッサ２０６に組み込まれることも可能である。

電源部２１０は図示を省略するが、バッテリー及び電源管理部を含む。入力部２１２は各種キー、スイッチ、及び／又は、タッチパネル等から構成され、ユーザの入力部２１２の操作に応じて各種のデータが入力される。表示部２１４はＬＣＤ、ＯＬＥＤ等の表示装置及び駆動回路を含む。

図１に示されているシステムと、図２（Ａ）及び２（Ｂ）に示されている装置は例示に過ぎず、本明細書に記述された方法を具現することができるシステム又は装置の範囲を制限することではない。

図３は本明細書において提案される方法を適用できるＢＬＥ通信アーキテクチャーの一例を示す図である。例えば、ＢＬＥプロトコルスタックはタイミングが重要な無線装置インターフェースを制御するように動作可能なコントローラースタック（Ｃｏｎｔｒｏｌｌｅｒ ｓｔａｃｋ）３０と、高レベル（ｈｉｇｈ ｌｅｖｅｌ）データを処理するように動作可能なホストスタック（Ｈｏｓｔ ｓｔａｃｋ）４０とを含む。コントローラースタック３０は、通信モジュールと、例えば、マイクロプロセッサー等のプロセッシングデバイスを含むプロセッサモジュールを利用して具現されることができる。ホストスタック４０は、プロセッサモジュール上で作動するＯＳの一部として、又は、ＯＳ上のパッケージ（ｐａｃｋａｇｅ）のインスタンス生成（ｉｎｓｔａｎｔｉａｔｉｏｎ）として具現されることができる。

コントローラースタック３０は、物理レイヤ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ：ＰＨＹ）３２と、リンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）３４と、ホストコントローラーインターフェース（Ｈｏｓｔ Ｃｏｎｔｒｏｌｌｅｒ Ｉｎｔｅｒｆａｃｅ：ＨＣＩ）３６と、を含む。物理レイヤ（無線送受信モジュール）３２は、２．４ＧＨｚの無線信号を送受信する階層であり、ＧＦＳＫ（Ｇａｕｓｓｉａｎ Ｆｒｅｑｕｅｎｃｙ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）変調及び４０個のＲＦチャンネルを利用する周波数ホッピング（ｆｒｅｑｕｅｎｃｙ ｈｏｐｐｉｎｇ）技法を使う。ブルートゥースパケットを伝送したり受信したりする役割を行うリンクレイヤ３４は、３個のアドバタイジング（Ａｄｖｅｒｔｉｓｉｎｇ）チャネルを利用してアドバタイジングやスキャニング機能を行った後に装置間のコネクションを生成し、３７個のデータチャンネルを通じて最大４２バイト（ｂｙｔｅ）のデータパケットをやり取りする機能を提供する。ＨＣＩ３６は、ホストスタックがコマンドとデータをコントローラースタックに提供し、コントローラースタックがイベントとデータをホストスタックに提供することができるように、ホストスタックとコントローラースタックとの間のインターフェースを提供する。

ホストスタック４０は、論理リンク制御及び適応プロトコル（Ｌ２ＣＡＰ）４１と、保安マネージャー（Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｒ：ＳＭ）４２と、アトリビュートプロトコル（Ａｔｔｒｉｂｕｔｅ Ｐｒｏｔｏｃｏｌ：ＡＴＴ）４３と、汎用アトリビュートプロファイル（Ｇｅｎｅｒｉｃ Ａｔｔｒｉｂｕｔｅ Ｐｒｏｆｉｌｅ：ＧＡＴＴ）４４と、汎用アクセスプロファイル（Ｇｅｎｅｒｉｃ Ａｃｃｅｓｓ Ｐｒｏｆｉｌｅ）４５と、ＬＥプロファイル４６と、を含むことができる。但し、ホストスタック４０はこのような例に限定されなく、多様なプロトコル及びプロファイルを含むことができる。ホストスタック４０はＬ２ＣＡＰを使ってブルートゥース仕様（スペック）が提供する多様なプロトコル及びプロファイル等を多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）する。

論理リンク制御及び適応プロトコル（Ｌ２ＣＡＰ）４１は、特定のプロトコル又はプロファイルによってデータを伝送するための一つの双方向チャンネルを提供する。保安マネージャー（ＳＭ）４２は、装置を認証し、キー分配（ｋｅｙ ｄｉｓｔｒｉｂｕｔｉｏｎ）を提供するためのプロトコルである。

アトリビュートプロトコル（ＡＴＴ）４３はサーバ／クライアント構造で相手デバイスのデータに接近するための規則を定義する。ＡＴＴには６種類のメッセージ類型（Ｒｅｑｕｅｓｔ、Ｒｅｓｐｏｎｓｅ、Ｃｏｍｍａｎｄ、Ｎｏｔｉｆｉｃａｔｉｏｎ、Ｉｎｄｉｃａｔｉｏｎ、Ｃｏｎｆｉｒｍａｔｉｏｎ）が定義される。
（１）要求（Ｒｅｑｕｅｓｔ）及び応答（Ｒｅｓｐｏｎｓｅ）メッセージ：要求（Ｒｅｑｕｅｓｔ）メッセージはクライアントがサーバに特定の情報を要請するために送信するメッセージであり、応答（Ｒｅｓｐｏｎｓｅ）メッセージはサーバがクライアントへ送信する要求メッセージに対する返事である。
（２）命令（Ｃｏｍｍａｎｄ）メッセージ：クライアントがサーバに特定の動作を要請するために送信するメッセージであり、サーバは命令（Ｃｏｍｍａｎｄ）メッセージに対する応答をクライアントに送信しない。
（３）告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージ：サーバがクライアントにイベント等の通知のために送信するメッセージであり、クライアントは告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージに対する確認メッセージをサーバに送信しない。
（４）指示（Ｉｎｄｉｃａｔｉｏｎ）及び確認（Ｃｏｎｆｉｒｍａｔｉｏｎ）メッセージ：サーバがクライアントにイベント等の通知のために送信するメッセージであり、告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージとは違い、クライアントは指示（Ｉｎｄｉｃａｔｉｏｎ）メッセージに対する確認（Ｃｏｎｆｉｒｍａｔｉｏｎ）メッセージをサーバに送信する。

汎用アトリビュートプロファイル（ＧＡＴＴ）４４はサービスの構成の時にＡＴＴ４３がどのように使われるかを説明するプロトコルとして用いられる。ＧＡＴＴ４４はサービスとキャラクタリスティック（Ｃｈａｒａｃｔｅｒｉｓｔｉｃ）という概念を使って特定のデータ（即ち、アトリビュート）を他の装置に提供する。ＧＡＴＴはサーバとクライアントとの二種類の役割を定義し、アトリビュートを提供する装置がサーバであり、アトリビュートが提供される装置がクライアントである。

サービスは情報を提供したり、アクションを遂行したり、他のエンティティーに代わってリソースを制御したりすることができるエンティティーである。サービスはソフトウェア、ハードウェア、又は、これらの組合せとして具現されることができる。ＳＤＰサーバによって保有される一つのサービスについての全ての情報は一つのサービスレコード内に含まれる。サービスはデータを論理的エンティティーとして分け、キャラクタリスティックと称されるデータの束を含む。それぞれのサービスは、一つ又はそれ以上のキャラクタリスティックを有することができ、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）と称される固有のＩＤによって区分される。

キャラクタリスティックはサービスで使われる単一のデータ配列であり、それぞれのキャラクタリスティックはＵＵＩＤを有する。また、それぞれのキャラクタリスティックは、キャラクタリスティック宣言とキャラクタリスティック値宣言との二つのアトリビュートを有する。キャラクタリスティック宣言は、アトリビュートタイプとアトリビュート値とを有し、アトリビュート値は、キャラクタリスティックプロパティー（Ｃｈａｒａｃｔｅｒｉｓｔｉｃ Ｐｒｏｐｅｒｔｙ）と、キャラクタリスティック値ハンドル（Ｃｈａｒａｃｔｅｒｉｓｔｉｃ Ｖａｌｕｅ Ｈａｎｄｌｅ）と、キャラクタリスティックＵＵＩＤとを有する。キャラクタリスティック値宣言は、キャラクタリスティックＵＵＩＤと、キャラクタリスティック値とによって構成される。

汎用アクセスプロファイル（ＧＡＰ）４５はＢＬＥデバイスの間の通信のための役割（ｒｏｌｅ）の選択と、マルチプロファイル動作の手続きとを制御するために使われる。ＧＡＰは主にデバイス発見、コネクション生成、及びセキュリティーに使われる。

ＬＥプロファイル４６はＧＡＴＴに依存性を持つプロファイルとして、主にＢＬＥデバイスに適用される。ＬＥプロファイルは、例えば、Ｂａｔｔｅｒｙ、Ｔｉｍｅ、ＦｉｎｄＭｅ、Ｐｒｏｘｉｍｉｔｙ等である。

図４は典型的なブルートゥースサービスディスカバリーメカニズムを示す。サービスディスカバリーメカニズムは、クライアントアプリケーションがサーバアプリケーションによって提供されるサービスの存在とこのサービスのアトリビュートとを発見する手段を提供する。サービスのアトリビュートはサービスのタイプ又は種別と、そのサービスを利用するために必要なメカニズム又はプロトコル情報とを含む。サービスディスカバリープロトコル（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ：ＳＤＰ）はＳＤＰサーバとＳＤＰクライアントの間の通信と関連する。サーバは当該サーバと関連したサービスのキャラクタリスティックを記述するサービスレコードの目録を保有する。それぞれのサービスレコードは一つのサービスについての情報を含む。クライアントはＳＤＰ要請を発行することでＳＤＰサーバによって保有されたサービスレコードから情報を検索することができる。

クライアント、又は、当該クライアントと関連したアプリケーションが、あるサービスを利用しようとする場合、当該サービスを利用するためにサービス提供者への別の接続を開始する。ＳＤＰはサービスとその関連したサービスアクセスプロトコルを含むアトリビュートとを発見するメカニズムを提供する。ＳＤＰにおいてサービスの種類を区分するためにＵＵＩＤが用いられる。ＳＤＰクライアントは探そうとするサービスのＵＵＩＤを知っている場合は、このＵＵＩＤを利用して、サーバにこのサービスを提供するかどうかを問い合わせる。探そうとするサービスのＵＵＩＤを知ってない場合は、サーバに当該サーバが提供するサービスに関する情報を要求する。もしデバイス上の多数のアプリケーションがサービスを提供すれば、ＳＤＰサーバはこれらが提供するサービスに関する情報に対する要請を取り扱うためにこれらのサービス提供者に代わって動作する。同様に、多数のクライアントアプリケーションがこれらに代わってサーバにクエリーを送るためにＳＤＰクライアントを利用することができる。

通常のブルートゥースサービスディスカバリーメカニズムにおいて、サービス検索命令はＢＬＥプロトコルとして規格化されているが、検索方法や検索順序はＯＳによって違う。例えば、ｉＯＳ（登録商標）はプライマリーサービス（Ｐｒｉｍａｒｙ Ｓｅｒｖｉｃｅ）を全部検索してからキャラクタリスティックを検索する反面、アンドロイド（登録商標）はプライマリーサービスが発見されるたびにキャラクタリスティックを検索する。サービスディスカバリープロセスは時間をかなり消費するプロセスであり、多数の装置が互いに近接している場合望ましくない遅延をもたらすことができる。

図５は、ＧＡＴＴサーバに格納されるアトリビュートの通常の構造の一例を示す。サーバはこのような形態のアトリビュートを使ってサービスを提供する。一つのアトリビュートは４個の構成要素から成り、次のような意味を有する。
−アトリビュートハンドル（Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅ）：特定のアトリビュートに対応する識別子（インデックス）
−アトリビュートタイプ（Ａｔｔｒｉｂｕｔｅ Ｔｙｐｅ）：アトリビュートの類型（アトリビュート値を記述するＵＵＩＤ）
−アトリビュート値（Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ）：アトリビュートの値（ハンドルによってインデクシングされるデータ）
−アトリビュートパーミッション（Ａｔｔｒｉｂｕｔｅ Ｐｅｒｍｉｓｓｉｏｎ）：アトリビュートに対する読み書き許可

図６（Ａ）はＢＬＥプロトコルによって定義される通常のパケット構造を示す。リンクレイヤはアドバタイジングチャンネルパケットとデータチャンネルパケットとの両方のために使われる一つのパケットフォーマットのみを持つ。各々のパケットはプリアンブル（Ｐｒｅａｍｂｌｅ）、アクセスアドレス（Ａｃｃｅｓｓ Ａｄｄｒｅｓｓ）、ＰＤＵヘッダー、ＰＤＵペイロード及びＣＲＣフィールドを含む。全てのパケットはＰＤＵヘッダーを有し、ＰＤＵヘッダーはアドバタイジング放送又は論理リンクのタイプを決める。一つのパケットがアドバタイジング物理チャンネルで伝送される時、ＰＤＵはアドバタイジングチャンネルＰＤＵであり、データ物理チャンネルで伝送される時、ＰＤＵはデータチャンネルＰＤＵである。アドバタイジングチャンネルＰＤＵは、アドバタイジングＰＤＵと、スキャニングＰＤＵと、開始ＰＤＵ（ｉｎｉｔｉａｔｉｎｇ ＰＤＵ）とに分類される。データチャンネルＰＤＵは１６ビットのヘッダーと、多様な大きさのペイロードとを有し、無線通信セキュリティー（Ｍｅｓｓａｇｅ Ｉｎｔｅｇｒｉｔｙ Ｃｈｅｃｋ：ＭＩＣ）フィールドを含むことができる。

図６（Ｂ）はアトリビュート値をやり取りするためのアトリビュートプロトコルＰＤＵの構造の一例を示す。図６（Ｂ）に示されたように、アトリビュートプロトコルＰＤＵはアトリビュートオペコード（Ｏｐｃｏｄｅ）フィールド、アトリビュートパラメーター（Ａｔｔｒｉｂｕｔｅ Ｐａｒａｍｅｔｅｒｓ）フィールド、及び認証署名（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｉｇｎａｔｕｒｅ）フィールド（選択的）によって構成されることができる。認証署名はオプションフィールドであり、選択的に存在したり存在しなかったりする。

上記アトリビュートオペコードはオクテット（ｏｃｔｅｔ）のデータであり、当該アトリビュートプロトコルＰＤＵがどんなＰＤＵであるかを示す情報を含む。図７はアトリビュートプロトコルＰＤＵのアトリビュートオペコード（Ａｔｔｒｉｂｕｔｅ Ｏｐｃｏｄｅ）及びアトリビュートパラメーターのリストの一例を示すテーブルである。アトリビュートパラメーターは実際のメッセージで伝達しようとする情報を含み、次のような値を持つことができる。
−ハンドル（Ｈａｎｄｌｅ）：データに対応する参照情報（インデックス）。ハンドルを使ってＧＡＴＴクライアントが値を参照、アクセス、又は変更することができる。
−値（Ｖａｌｕｅ）：データの値
−データリスト（Ｄａｔａ Ｌｉｓｔ）：色々なデータ値の目録
−長さ（Ｌｅｎｇｔｈ）：データの長さ

上記のようなアトリビュートプロトコルＰＤＵを通じてクライアントはサーバに格納されているアトリビュートハンドル値、アトリビュート値、データリスト、又は長さ値を読み出したり、サーバにこのような値を記憶させることができる。

図８は通常のアトリビュートデータベースの一例を示す。図８に示されたアトリビュートデータベースが実装されたＢＬＥ装置は、例えば、電子時計である。それぞれのサービスはデータを論理的に分ける役割を行い、一つ又はそれ以上のキャラクタリスティックを含む。示されたように、プライマリーサービスであるＷａｔｃｈ Ｓｅｒｖｉｃｅは複数のキャラクタリスティック（ＳｅｒｖｉｃｅＮ１、ＳｅｒｖｉｃｅＮ２、．．．、ＳｅｒｖｉｃｅＮｘ）を含む。本例において、サービスであるＷａｔｃｈ Ｓｅｒｖｉｃｅは、ｘ個のキャラクタリスティックを含む。示されたように、通常のＢＬＥ装置では一つの機能（フィーチャー）に対して一つのキャラクタリスティックを有する形態としてアトリビュートデータベースが構成される。それぞれのサービスとそれぞれのキャラクタリスティックは、ＵＵＩＤ、即ち、１６ビット又は１２８ビットの識別子を有する。ブルートゥース標準グループは公式的なサービスとキャラクタリスティックのＵＵＩＤのリストをブルートゥーススペックとして提供している。ユーザが新しいカスタムサービス／キャラクタリスティックを定義する場合には、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）の公式ウェブサイトに接続して新しいＵＵＩＤを生成することができる。

それぞれのキャラクタリスティックは、キャラクタリスティック宣言とキャラクタリスティック値宣言との二つのアトリビュートを有する。例えば、ＳｅｒｖｉｃｅＮ１のキャラクタリスティック宣言は、アトリビュートタイプ（キャラクタリスティックのＵＵＩＤ、具体的には、０ｘ２８０３）と、アトリビュート値としてキャラクタリスティックプロパティー（０ｘ０ａ）と、キャラクタリスティック値ハンドル（０ｘ００３ｂ）と、キャラクタリスティックＵＵＩＤ（ＳｅｒｖｉｃｅＮ１のＵＵＩＤ）とによって構成される。ＳｅｒｖｉｃｅＮ１のキャラクタリスティック値宣言は、キャラクタリスティックＵＵＩＤ（ＳｅｒｖｉｃｅＮ１のＵＵＩＤ）と、キャラクタリスティック値（ＳｅｒｖｉｃｅＮ１の値）によって構成される。

クライアントとサーバとの接続が確立されると、両方の装置がデータ通信を行うことができ、クライアントは、サーバが提供する特定のサービスにアクセスすることができる。例えば、図９は、サーバとクライアントとがデータ通信を行う通常の方法を示す。この例では、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。第１の装置１００には、図８のアトリビュートデータベースが実装されている。サーバに特定のキャラクタリスティック値を要求しようとする場合、クライアントはＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージは、ＢＬＥ仕様に定義されたように、サーバにアトリビュートの値を読み出してその値を送るように要求するために使われるメッセージであり、図７に示されたように、アトリビュートハンドル（Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅ）をパラメーターとして使う。この場合、Ｒｅａｄ ＲｅｑｕｅｓｔメッセージのＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターは、キャラクタリスティック値ハンドル（ Ｃｈａｒａｃｔｅｒｉｓｔｉｃ Ｖａｌｕｅ Ｈａｎｄｌｅ）に設定される。クライアントからのＲｅａｄ Ｒｅｑｕｅｓｔが有効な場合、即ち、クライアントがデータを要求する権限を持つ同時に当該データを読み出すことが可能な場合に、サーバはクライアントが要求するデータをＲｅａｄ Ｒｅｓｐｏｎｓｅメッセージによってクライアントに送信する。Ｒｅａｄ Ｒｅｓｐｏｎｓｅメッセージは、ＢＬＥ仕様に定義されたように、Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージに応答するためにサーバによって送信されるメッセージであり、読み出されたアトリビュートの値を含む。図７に示されたように、Ｒｅａｄ Ｒｅｓｐｏｎｓｅメッセージは、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅをパラメーターとして使い、この場合、Ｒｅａｄ Ｒｅｓｐｏｎｓｅによって伝送される値は、上記キャラクタリスティック値ハンドルに対応するキャラクタリスティック値（Ｃｈａｒａｃｔｅｒｉｓｔｉｃ Ｖａｌｕｅ）である。例えば、クライアントがＳｅｒｖｉｃｅＮ１の値を要求する場合は、クライアントはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターが０ｘ００３ｂに設定されているＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信し、これに対する応答として、サーバはＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターが（ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ）に設定されているＲｅａｄ Ｒｅｓｐｏｎｓｅメッセージをクライアントに送信する。

サーバにデータを書き込もうとする場合、クライアントは、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターとＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、データを書き込むキャラクタリスティック値のハンドルと、書き込むデータとに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージは、ＢＬＥ仕様に定義されたように、サーバにアトリビュートの値を書き込むように要求するために使われるメッセージであり、書き込みの要求が有効である場合、サーバは、上記ハンドルに対応する特定のキャラクタリスティックの値にアクセスして上記データを書き込むことができる。上記データが成功的に書き込まれると、サーバはＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージをクライアントに送信する。データの書き込みに失敗すると、サーバはエラーメッセージをクライアントに送信する。一方、応答メッセージを伴わないＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを用いて、データの書込みを要求することもできる。この場合、クライアント側で書込みが成功的に行なわれたかどうかを直ちに確認することができないが、サーバが応答メッセージを送信するために電力を消費しないので、サーバがバッテリー容量が少ないデバイス、例えば、ウォッチ型のウェアラブルデバイスである場合は、Ｗｒｉｔｅ Ｃｏｍｍａｎｄを用いる方が電力消費の減少の側面でより有利である。

サーバがクライアントにデータを通知しようとする場合、サーバは、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターとＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、通知するデータであるキャラクタリスティック値のハンドルと、当該データとに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージを、クライアントに送信する。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージは、ＢＬＥ仕様に定義されたように、サーバがアトリビュートの値を通知するために送信するメッセージである。クライアントは、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージを成功的に受信すると、これに対する応答メッセージであるＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージをサーバに送信する。従って、データの重要度が高い場合には、指示メッセージを用いることが好ましい。データの重要度が低く、クライアントの消費電力の削減が重要な場合は、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを用いることもできる。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージと同様に、サーバがアトリビュートの値を通知するために送信するメッセージであるが、応答メッセージであるＣｏｎｆｉｒｍａｔｉｏｎを伴わない。

クライアントは必要な時に、例えば、所定の時刻になった時、又は、ユーザの操作があった時に、サーバにデータを要求したり、データの記入を要請したり、サーバからデータを受信したりする。従来には、前回の通信後にサーバの設定、即ち、ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘの値に変更がない場合にも、一定のタイミングに通信が発生するので、同一のデータを繰り返しやり取りするために電力を無駄に消耗する。本発明は、前回の通信後に、サーバの設定に変更があったかどうかを示す判別情報をクライアントに送信することによって、変更があった部分のみを同期化するように構成される。このような構成によって、サーバとクライアント間の通信回数や通信データの量を節減できる。本発明の複数の実施形態においては、上記判別情報として、前回の通信後に変更があった部分を示すビットマップを用いる。以下では、本発明の具体的な実施形態について説明する。

図１０は本発明の複数の実施形態において設定変更を示す判別情報として用いられるビットマップの一例を示す。上記ビットマップのビットは、フィーチャー、即ち、図８に示された通常のアトリビュートデータベースにおいてはキャラクタリスティックＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘに対応し、各ビットの値は当該ビットに対応するフィーチャーの値に変更があるかどうかを示す。ビットの値が０であれば、当該ビットに対応するフィーチャーの値に変更が無いことを、ビットの値が１であれば、当該ビットに対応するフィーチャーの値に変更があることを示す。本例では、サービスがｘ個のフィーチャーであるＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘを含み、これらフィーチャーのうちＳｅｒｖｉｃｅＮ３とＳｅｒｖｉｃｅＮ５との値に変更がある。サーバとクライアントとにおいてビットマップの順番を共通にして、サーバがビットマップをクライアントに送信することで、クライアント側がサーバの設定変更の有無を把握することができる。

図１１は、図１０に示された形態のビットマップを用いてサーバとクライアントとの設定を動機させる方法を示す概念図である。本例で、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。サーバのサービスは８個のフィーチャーを含む。従って、８ビットのビットマップが使われる。第１の装置１００のビットマップが０００１００００であるので、サーバ側で変更があったフィーチャーはＳｅｒｖｉｅＮ５である。以下、サーバ側のビットマップを設定変更ビットマップとも称する。一方、クライアントである第２の装置２００はＳｅｒｖｉｅＮ３を変更したいので、ビットマップ０００００１００を保持しておく。クライアントは、サーバ側にビットマップの読出しを要請して、サーバから設定変更ビットマップを取得する。クライアントは、取得された設定変更ビットマップ０００１００００と、クライアント内部のビットマップ０００００１００とを論理的ＯＲすることで、０００１０１００を得ることができる。これによって、クライアントはＳｅｒｖｉｅＮ３とＳｅｒｖｉｅＮ５のみを動機させれば良いことが分かることになる。

図１２は本発明の一実施形態に係るアトリビュートデータベースの一例を示す。図１２のアトリビュートデータベースは、図８に示された通常のアトリビュートデータベースに、アクセスコントロール用のキャラクタリスティックＭｙ Ａｃｃ Ｃｔｒｌを追加し、そのキャラクタリスティックの値であるアクセスコントロールビットマップ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｂｉｔｍａｐ）として設定変更ビットマップを格納する。従って、クライアントは、必要な時に、アトリビュートハンドル（０ｘ００５５）を使ってアトリビュート値である設定変更ビットマップを読み出すことができる。

図１３は、本発明の他の実施形態に係るアトリビュートデータベースの一例を示す。図８に示された通常のアトリビュートデータベースはＷａｔｃｈ Ｓｅｒｖｉｃｅのｘ個のフィーチャーに対応するｘ個のキャラクタリスティックを含んでおり、アトリビュート値としてそれぞれのキャラクタリスティックの値を格納する。本実施形態に係るアトリビュートデータベースは、機能の数に関わらず、２つのキャラクタリスティック、即ち、アクセスコントロール用のキャラクタリスティックであるＭｙ Ａｃｃ Ｃｔｒｌと、データ通信用のキャラクタリスティックであるＡｌｌ Ｆｅａｔｕｒｅｓとを含む。Ｍｙ Ａｃｃ Ｃｔｒｌのアトリビュート値であるアクセスコントロールビットマップとしてサーバの設定変更ビットマップが格納される。通常のキャラクタリスティック、即ち、ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘの値は、Ａｌｌ Ｆｅａｔｕｒｅｓのアトリビュート値として格納されることができる。本実施形態では、ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘのそれぞれの値に１つのハンドル（０ｘ００１１）のみが割り当てられるので、複数の種類のデータを区別するための情報であるクラスをデータに付加する。換言すれば、従来にＵＵＩＤ又はハンドル値によって区別されていた複数の種類のデータを、新しい区別情報であるクラスによって区別する。例えば、図１３に示すように、各々のデータを記憶するように割り当てられた２０バイトの領域の先頭の１バイトに、各データのクラスを記憶し、残りの１９バイトにデータを記憶する。本例では、クラスに１バイトを割り当てるので、クラスによって２５６種類のデータを区別することができる。通信装置のそれぞれが同一のクラス情報を保有することができるように、クラス情報は仕様（スペック）として管理されることが好ましい。一方、データとクラスとを記憶する領域の大きさは、上記の実施形態に限定されない。また、クラスが記憶される位置はデータ記憶領域の先頭に限定されない。

図１４は、本発明の一実施形態に係るサーバとクライアントとが常時接続するパターンにおいてサーバとクライアント間のデータ通信方法を示す。本実施形態において、サーバに実装されるアトリビュートデータベースは図１３の構造を有する。第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。所定のタイミングに、クライアントは、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターがアクセス制御用アトリビュートのハンドル、即ち、Ｍｙ Ａｃｃ Ｃｔｒｌのキャラクタリスティック値ハンドルである０ｘ０００ｆに設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。上記所定のタイミングは、例えば、所定の時刻になった時、又は、ユーザの所定の操作があった時である。サーバは、上記メッセージに対する応答として、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターがアクセスコントロールビットマップに設定されたＲｅａｄ Ｒｅｓｐｏｎｓｅメッセージを送信する。これによって、クライアントがサーバのアクセスコントロールビットマップを取得することができる。図１１に説明したように、クライアントも、変更したいデータを示すビットマップを保持しておく。

クライアントは、アクセスコントロールビットマップからサーバ側で変更があったフィーチャー（本例では、ＳｅｒｖｉｃｅＮｉ）を判別し、当該フィーチャーの値を読み出すために、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターがＡｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１に設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。このＲｅａｄ Ｒｅｑｕｅｓｔメッセージを受信すると、サーバはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１と、「ＳｅｒｖｉｃｅＮｉのクラス＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、クライアントに送信する。これによって、クライアントがサーバ側の変更されたデータを取得して、クライアント側の設定を更新することができる。アクセスコントロールビットマップからサーバ側において変更されたフィーチャーがないと判断される場合は、Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージを送信しない。

図１１に説明したように、クライアントは、取得された設定変更ビットマップと、クライアント内部のビットマップとを論理的ＯＲすることで、同期させるデータを判別することができる。例えば、サーバの設定のうちＳｅｒｖｉｃｅＮｊを変更したい場合、クライアントはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１と、「ＳｅｒｖｉｃｅＮｊのクラス＋更新データ」とに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを、サーバに送信する。上記データが書き込まれると、サーバはクライアントにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。Ｗｒｉｔｅ Ｒｅｑｕｅｓｔの代わりに、Ｒｅｓｐｏｎｓｅメッセージを伴わないＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを用いることも可能である。

ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘの中で更新するフィーチャーが重なる場合、例えば、サーバ側の設定変更ビットマップにおいて値が１であるビットと、クライアント側のビットマップにおいて値が１であるビットとが同一である場合は、仕様に規定された規則に従って処理する。例えば、サーバ側を優先して、サーバ側の変更されたフィーチャーの値をクライアントに送信し、クライアントは当該フィーチャーを受信した値に更新する。他の例では、更新するフィーチャーが重なる旨をユーザに通知し、どちらを優先するかを選択させる。

一方、サーバのアトリビュートデータベースが図１２に示された構造を有する場合は、クライアントとサーバとがやり取りするメッセージのパラメーターが下記のように変わる。クライアントは、前回の通信後に変更があったフィーチャーの値を要求するために、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターがＳｅｒｖｉｃｅＮｉのキャラクタリスティック値ハンドルに設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信し、それに対してサーバは、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとが、ＳｅｒｖｉｃｅＮｉのキャラクタリスティック値ハンドルと、ＳｅｒｖｉｃｅＮｉの値とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを送信する。クライアントがサーバの設定のうちＳｅｒｖｉｃｅＮｊを変更したい場合は、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、ＳｅｒｖｉｃｅＮｊのキャラクタリスティック値ハンドルと、更新データとに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。

図１５は、図１３及び図１４の実施形態に係る通信プロセスを示すフローチャートである。一例として、図１５は常時接続パターンにおいての、サーバの動作を実行するためのアルゴリズムを示すフローチャートである。本実施形態で、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。以下では、図２（Ａ）を一緒に参照して図１５を詳細に説明する。

通信プロセスが開始すると、第１の装置１００と第２の装置２００とのペアリングが行われる（ステップＳ１５００）。ペアリングが行われれば、第１の装置１００のプロセッサ１０４はメモリ１０８に格納されている設定変更ビットマップ、即ち、アトリビュートデータベースのアクセスコントロールビットマップ（図１０及び図１３参照）を初期化する（ステップＳ１５０２）。これによって、アクセスコントロールビットマップの全てのビットの値が０に設定される。次に、第１の装置１００の設定が変更されたかどうかを判断する（ステップＳ１５０４）。ユーザの操作等の所定の条件が満足されて前回の通信後に第１の装置１００の設定が変更された場合、換言すれば、ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘのうち変更されたフィーチャーがある場合（ステップＳ１５０４：Ｙｅｓ）、アクセスコントロールビットマップにあっての変更されたフィーチャーに対応するビットを書き換える（ステップＳ１５０６）。即ち、０に設定されている当該ビットの値を１に更新する。次に、第１の装置１００の設定情報を第２の装置２００と通信するタイミングになったかどうかを判断する（ステップＳ１５０８）。一方、前回の通信後に第１の装置１００の設定が変更されなかった場合（ステップＳ１５０４：Ｎｏ）、すぐにステップＳ１５０８へ進む。

第１の装置１００の設定情報を第２の装置２００と通信するタイミングである場合（ステップＳ１５０８：Ｙｅｓ）、第１の装置１００は第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかを確認する（ステップＳ１５１０）。設定情報を通信するタイミングでない場合は（ステップＳ１５０８：Ｎｏ）、ステップＳ１５０４に戻る。

第１の装置１００は、所定の時間の間、第２の装置２００から第１の装置１００のアトリビュートデータベースに格納されているＭｙ Ａｃｃ Ｃｔｒｌのアトリビュート値を要求するＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１５１０：Ｎｏ）。図１３及び図１４に関連して説明したように、このＲｅａｄ Ｒｅｑｕｅｓｔメッセージはサーバである第１の装置１００側の設定変更ビットマップを要求するメッセージである。上記所定の時間内にＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されない場合は、例えば、ユーザにエラーメッセージを表示して設定情報を通信することができない旨を知らせる。上記所定の時間内に第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信される場合（ステップＳ１５１０：Ｙｅｓ）、第１の装置１００のプロセッサ１０４はメモリ１０８に格納されている設定変更ビットマップを読み出して第２の装置２００に送信する（ステップＳ１５１２）。

次に、第１の装置１００のプロセッサ１０４は、メモリ１０８に格納されている設定変更ビットマップから、変更があったフィーチャーがあるかどうかを判断する（ステップＳ１５１４）。変更されたフィーチャーがある場合は（ステップＳ１５１４：Ｙｅｓ）、第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１５１６）。図１３及び図１４に関連して説明したように、このＲｅａｄ Ｒｅｑｕｅｓｔメッセージは第１の装置１００のキャラクタリスティックであるＡｌｌ Ｆｅａｔｕｒｅｓのハンドル値をパラメーターとして用いる。第１の装置１００は、所定の時間の間、第２の装置からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１５１６：Ｎｏ）。上記所定の時間内に第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信される場合（ステップＳ１５１６：Ｙｅｓ）、第１の装置１００は設定変更ビットマップによって指定されたフィーチャーの値、即ち、設定変更ビットマップにおいて値が１であるビットに対応するフィーチャーの値のみを読み出して第２の装置２００に送信する（ステップＳ１５１８）。例えば、図１４に示されたように、第１の装置１００側でＳｅｒｖｉｃｅＮｉの値が変更された場合、第１の装置１００はＳｅｒｖｉｃｅＮｉの値を格納したＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００に送信する。これによって、前回の通信の後に変更があった設定情報のみを第２の装置２００に送信することができる。上記所定の時間内にＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されない場合は、例えば、ユーザにエラーメッセージを表示して設定情報を通信することができない旨を知らせる。一方、第１の装置１００側で変更されたフィーチャーがない場合は（ステップＳ１５１４：Ｎｏ）、すぐにステップＳ１５２０へ進む。

次に、第２の装置２００からデータの書込みを要請するＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１５２０）。例えば、図１４に示されたように、第２の装置２００側においてＳｅｒｖｉｃｅＮｊを変更した場合、第２の装置２００はＡｌｌ Ｆｅａｔｕｒｅｓのハンドル値と、「ＳｅｒｖｉｃｅＮｊのクラス＋更新データ」とをパラメーターとするＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを第１の装置１００に送信する。所定の時間内に第２の装置２００からＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信される場合（ステップＳ１５２０：Ｙｅｓ）、第１の装置１００のプロセッサ１０４は上記Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージによって指定されたフィーチャーの値を更新する（ステップＳ１５２２）。例えば、図１４に示されたように、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージに含まれたクラスに対応するＳｅｒｖｉｃｅＮｊの値を、当該メッセージのデータに更新する。そして、設定情報ビットマップを初期化し、ステップＳ１５０４に戻る（ステップＳ１５２４）。

第１の装置１００は、第２の装置２００からＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信されない場合（ステップＳ１５２０：Ｎｏ）、上記所定の時間が経過したかどうかを判断する（ステップＳ１５２６）。上記所定の時間が経過していない場合は（ステップＳ１５２６：Ｎｏ）、ステップＳ１５２０に戻る。上記所定の時間が経過した場合、即ち、タイムアウトが発生した場合は（ステップＳ１５２６：Ｙｅｓ）、第２の装置２００が変更を要請する設定情報がないと判断して、設定情報ビットマップを初期化し、ステップＳ１５０４に戻る（ステップＳ１５２８）。

図１６は本発明の他の実施形態に係るサーバとクライアントとの間に再接続が発生するパターンにおいてサーバとクライアント間のデータ通信方法を示す。本実施形態で、サーバに実装されるアトリビュートデータベースは図１３の構造を有する。また、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。所定のタイミングに、サーバである第１の装置がアドバタイジングパケットを送信する。上記所定のタイミングは、例えば、所定の時刻になった時、又は、ユーザの所定の操作があった時である。このアドバタイジングパケットには、サーバ側において前回の通信の後に変更があったフィーチャーを示す設定変更ビットマップが格納される。即ち、本実施形態では、サーバとクライアント間のコネクションが構築される前に、アドバタイズ段階においてサーバの設定変更ビットマップをクライアントに送信する。第２の装置２００が上記アドバタイジングパケットを受信することによって、サーバ側の設定変更ビットマップを取得することができる。上述した実施形態と同様に、第１の装置１００と第２の装置２００でビットマップ順番を共通にすることで、第２の装置２００が、取得したビットマップから第１の装置１００のどのフィーチャーに変更があったかを判断することができる。

上記アドバタイジングパケットを受信した第２の装置２００が第１の装置１００にコネクション要求（Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）を発信し、上記Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔを第１の装置が受信することによって、二つの装置間のコネクションが構築される。Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔは、２つの装置の間にＬ２ＣＡＰチャンネルを生成するためにマスター装置がスレーブ装置に送信するパケットである。次に、サービスディスカバリーが行われる。このサービスディスカバリーセッションで、クライアントである第２の装置２００は、第１の装置１００に実装されたサービスとキャラクタリスティックとに関する情報（図１３を参照）を取得する。

サービスディスカバリーが終了すれば、クライアントである第２の装置２００は設定変更ビットマップからサーバ側で変更があったフィーチャー（本例では、ＳｅｒｖｉｃｅＮｉ）を判別し、当該フィーチャーの値を読み出すために、Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。図１６の実施形態において、データのやり取りの手続きは、図１４の実施形態のものと同様であるので、それについては、詳細な説明は省略する。上記Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージを受信すると、サーバはＳｅｒｖｉｃｅＮｉのデータを含むＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、クライアントに送信する。

サーバ側のＳｅｒｖｉｃｅＮｊの値を変更したい場合は、クライアントは、ＳｅｒｖｉｃｅＮｊの更新データを含むＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを、サーバに送信する。上記データが書き込まれると、サーバはクライアントにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。

必要なデータのやり取りが完了すれば、例えば、第２の装置２００がコネクションを切断する手続きを開始するためのメッセージ（ＬＬ＿ＴＥＲＭＩＮＡＴＥ＿ＩＮＤ）を第１の装置１００に送信し、第１の装置１００から確認（Ａｃｋ）メッセージを受信することによって、コネクションを切断する。第１の装置１００と第２の装置２００との両側において設定に変更がなかった場合、即ち、両側のビットマップの全てのビットの値が０である場合は、やりとりするデータがないので、コネクションが構築された後にすぐにコネクションを切断する。

図１７は、図１３及び図１６の実施形態に係る通信プロセスを示すフローチャートである。一例として、図１７は再接続が発生するパターンにおいての、サーバの動作を実行するためのアルゴリズムを示すフローチャートである。本実施形態で、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。以下では、図２（Ａ）を一緒に参照して図１７を詳細に説明する。一方、本実施形態においては、再接続が発生する時に、アドバタイジングパケットによって設定変更ビットマップをクライアント側に送信するので、図１３のアトリビュートデータベースにおいてアクセスコントロール用のキャラクタリスティックであるＭｙ Ａｃｃ Ｃｔｒｌと、そのアトリビュートは使われない。従って、サーバが再接続が発生するパターンのみで動作する場合には、サーバにキャラクタリスティックＭｙ Ａｃｃ Ｃｔｒｌを実装しなくても良い。即ち、サーバのアトリビュートデータベースに一つのキャラクタリスティックＡｌｌ Ｆｅａｔｕｒｅｓのみが含まれても良い。

通信プロセスが開始すると、第１の装置１００と第２の装置２００とのペアリングが行われる（ステップＳ１７００）。ペアリングが成功的に行われれば、第１の装置１００のプロセッサ１０４はメモリ１０８に格納されている設定変更ビットマップを初期化する（ステップＳ１７０２）。これによって、設定変更ビットマップの全てのビットの値が０に設定される。次に、第１の装置１００の設定が変更されたかどうかを判断する（ステップＳ１７０４）。ユーザの操作等の所定の条件が満足されて前回の通信後に第１の装置１００の設定が変更された場合、換言すれば、ＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘのうち変更されたフィーチャーがある場合（ステップＳ１７０４：Ｙｅｓ）、設定変更ビットマップにあっての変更されたフィーチャーに対応するビットを書き換える（ステップＳ１７０６）。即ち、０に設定されている当該ビットの値を１に更新する。次に、第１の装置１００の設定情報を第２の装置２００と通信するタイミングになったかどうかを判断する（ステップＳ１７０８）。一方、前回の通信後に第１の装置１００の設定が変更されなかった場合（ステップＳ１７０４：Ｎｏ）、すぐにステップＳ１７０８へ進む。

第１の装置１００の設定情報を第２の装置２００と通信するタイミングである場合（ステップＳ１７０８：Ｙｅｓ）、第１の装置１００はアドバタイズを開始する（ステップＳ１７１０）。図１６に関連して説明したように、第１の装置１００は設定変更ビットマップが格納されたアドバタイジングパケットを第２の装置２００に送信する。第１の装置１００が第２の装置２００からＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを受信することによって、第１の装置１００と第２の装置２００とのコネクションが構築される（ステップＳ１７１２）。一方、設定情報を通信するタイミングでない場合には（ステップＳ１７０８：Ｎｏ）、ステップＳ１７０４に戻る。

次に、第１の装置１００のプロセッサ１０４は、メモリ１０８に格納されている設定変更ビットマップから、変更があったフィーチャーがあるかどうかを判断する（ステップＳ１７１４）。変更されたフィーチャーがある場合は（ステップＳ１７１４：Ｙｅｓ）、第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１７１６）。図１３及び図１６に関連して説明したように、このＲｅａｄ Ｒｅｑｕｅｓｔメッセージは第１の装置１００のキャラクタリスティックであるＡｌｌ Ｆｅａｔｕｒｅｓのハンドル値をパラメーターとして用いる。第１の装置１００は、所定の時間の間、第２の装置からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１７１６：Ｎｏ）。上記所定の時間内に第２の装置２００からＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信される場合（ステップＳ１７１６：Ｙｅｓ）、第１の装置１００は設定変更ビットマップによって指定されたフィーチャーの値、即ち、設定変更ビットマップにおいて値が１であるビットに対応するフィーチャーの値のみを読み出して第２の装置２００に送信する（ステップＳ１７１８）。例えば、図１６に示されたように、第１の装置１００側でＳｅｒｖｉｃｅＮｉの値が変更された場合、第１の装置１００はＳｅｒｖｉｃｅＮｉの値を格納したＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００に送信する。これによって、前回の通信の後に変更があった設定情報のみを第２の装置２００に送信することができる。上記所定の時間内にＲｅａｄ Ｒｅｑｕｅｓｔメッセージが受信されない場合は、例えば、ユーザにエラーメッセージを表示して設定情報を通信することができない旨を知らせる。一方、第１の装置１００側で変更されたフィーチャーがない場合は（ステップＳ１７１４：Ｎｏ）、すぐにステップＳ１７２０へ進む。

次に、第２の装置２００からデータの書込みを要請するＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信されるかどうかを確認する（ステップＳ１７２０）。例えば、図１６に示されたように、第２の装置２００側においてＳｅｒｖｉｃｅＮｊを変更した場合、第２の装置２００はＡｌｌ Ｆｅａｔｕｒｅｓのハンドル値と、「ＳｅｒｖｉｃｅＮｊのクラス＋更新データ」とをパラメーターとするＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを第１の装置１００に送信する。所定の時間内に第２の装置２００からＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信される場合（ステップＳ１７２０：Ｙｅｓ）、第１の装置１００のプロセッサ１０４は上記Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージによって指定されたフィーチャーの値を更新する（ステップＳ１７２２）。例えば、図１６に示されたように、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージに含まれたクラスに対応するＳｅｒｖｉｃｅＮｊの値を、当該メッセージのデータに更新する。そして、設定情報ビットマップを初期化し（ステップＳ１７２４）、コネクション切断処理を行なう（ステップＳ１７３０）。上述のように、コネクション切断処理は、例えば、第２の装置２００からＬＬ＿ＴＥＲＭＩＮＡＴＥ＿ＩＮＤを受信することで開始される。コネクションが切断された後、プロセスはステップＳ１７０４に戻る。

第１の装置１００は、第２の装置２００からＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージが受信されない場合（ステップＳ１７２０：Ｎｏ）、上記所定の時間が経過したかどうかを判断する（ステップＳ１７２６）。上記所定の時間が経過していない場合は（ステップＳ１７２６：Ｎｏ）、ステップＳ１７２０に戻る。上記所定の時間が経過した場合、即ち、タイムアウトが発生した場合は（ステップＳ１７２６：Ｙｅｓ）、第２の装置２００が変更を要請する設定情報がないと判断して、設定情報ビットマップを初期化し（ステップＳ１７２８）、コネクション切断処理を行なう（ステップＳ１７３０）。コネクションが切断された後、プロセスはステップＳ１７０４に戻る。

図１８は本発明の他の実施形態に係るサーバとクライアント間のデータ通信方法を示す。図１８はサーバとクライアントとが常時接続するパターンを想定しているが、本実施形態は再接続が発生するパターンに対しても適用可能である。本実施形態で、サーバに実装されるアトリビュートデータベースは図１３の構造を有する。一方、第１の装置１００がサーバとして、第２の装置２００がクライアントとして動作する。上述した実施形態では、一つのＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージや一つのＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージによって一つのフィーチャーの値のみを送信する。従って、サーバ側で複数のフィーチャーに変更があった場合、変更があったフィーチャーの数だけ、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを送信する。クライアント側で複数のフィーチャーを変更したい場合にも、変更したいフィーチャーの数ほど、Ｗｒｉｔｅ ＲｅｑｕｅｓｔメッセージとＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージとをやり取りする。これとは違い、本実施形態では、通信回数を一層減らすために、複数のフィーチャーに対して一つのメッセージを用いて通信する。

所定のタイミングに、クライアントは、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターがアクセス制御用アトリビュートのハンドル、即ち、Ｍｙ Ａｃｃ Ｃｔｒｌのキャラクタリスティック値ハンドルである０ｘ０００ｆに設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。上記所定のタイミングは、例えば、所定の時刻になった時、又は、ユーザの所定の操作があった時である。サーバは、上記メッセージに対する応答として、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターがアクセスコントロールビットマップに設定されたＲｅａｄ Ｒｅｓｐｏｎｓｅメッセージを送信する。これによって、クライアントがサーバの設定変更ビットマップを取得することができる。上述したように、クライアントも、変更したいデータを示すビットマップを保持しておく。一方、再接続が発生するパターンでは、サーバが設定変更ビットマップをアドバタイジングパケットに格納して、クライアントに送信することで、クライアントがサーバの設定変更ビットマップを取得することができる。

クライアントは、サーバから受信した設定変更ビットマップから変更されたフィーチャーが存在すると判断すれば、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターがＡｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルに設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。クライアントから上記Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージを受信すれば、サーバは変更されたフィーチャーの値をクライアントに送信する。例えば、変更があったフィーチャーがＳｅｒｖｉｃｅＮａ、ＳｅｒｖｉｃｅＮｂ、ＳｅｒｖｉｃｅＮｃ、ＳｅｒｖｉｃｅＮｄである場合、サーバは図１８に示されたように、Ａｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメーターがＡｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１に設定され、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとして、送信するデータの種類の個数（本例では、４）と、ＳｅｒｖｉｃｅＮａ、ＳｅｒｖｉｃｅＮｂ、ＳｅｒｖｉｃｅＮｃ、ＳｅｒｖｉｃｅＮｄの各々のデータの長さ（Ｌｅｎｇｔｈフィールド１バイト）及びデータ（（Ｌｅｎｇｔｈフィールドの値）バイト）を格納した一つのＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージをクライアントに送信する。上記メッセージに格納するデータ、即ち、ＳｅｒｖｉｃｅＮａ、ＳｅｒｖｉｃｅＮｂ、ＳｅｒｖｉｃｅＮｃ、ＳｅｒｖｉｃｅＮｄのデータの順番を設定変更ビットマップの順番と同一にすると同時に、各データの前に当該データの長さを付加することによって、クライアント側で複数の種類のデータを区分することができる。データの種類の個数は選択的な情報であり、上記メッセージに含まれなくても良い。

クライアント側で変更したいフィーチャーがある場合は、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１と、「クライアント側のビットマップ＋更新データ」とに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを、サーバに送信する。変更するデータの種類が複数である場合は、上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージと同様に、データフィールドに「データの長さ＋データ」をビットマップと同一の順番に格納する。クライアント側のビットマップによって、サーバはクライアントが変更を要求するフィーチャーがどれであるかを判別することができる。データの書込みが行われれば、サーバはクライアントにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１９は本発明の他の実施形態に係るアトリビュートデータベースの一例を示す。本実施形態でのアトリビュートデータベースは、図１３のアトリビュートデータベースに比べて、データ要求用のキャラクタリスティックであるＲｅａｄ Ｒｅｑｕｅｓｔ ｆｏｒ Ａｌｌ Ｆｅａｔｕｒｅｓを更に含む。残りの部分は図１３アトリビュートデータベースと同一であるので、それについては説明を省略する。以下、サーバのアトリビュートデータベースが図１９の形態を有する場合のデータ通信について図２０及び図２１を参照して説明する。図２０と図２１との両方において、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。

図２０は、本発明の一実施形態に係るサーバとクライアントとが常時接続するパターンにおいてサーバとクライアント間のデータ通信方法を示す。所定のタイミングに、クライアントは、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターがアクセス制御用アトリビュートのハンドル、即ち、Ｍｙ Ａｃｃ Ｃｔｒｌのキャラクタリスティック値ハンドルである０ｘ０００ｆに設定されたＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバに送信する。上記所定のタイミングは、例えば、所定の時刻になった時、又は、ユーザの所定の操作があった時である。サーバは、上記メッセージに対する応答として、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターがアクセスコントロールビットマップに設定されたＲｅａｄ Ｒｅｓｐｏｎｓｅメッセージを送信する。これによって、クライアントがサーバのアクセスコントロールビットマップを取得することができる。図１１に関連して説明したように、クライアントも、変更したいデータを示すビットマップを保持しておく。

クライアントは、アクセスコントロールビットマップからサーバ側で変更があったフィーチャー（本例では、ＳｅｒｖｉｃｅＮｉ）を判別し、当該フィーチャーの値を読み出すために、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ｒｅａｄ Ｒｅｑｕｅｓｔ ｆｏｒ Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１と、ＳｅｒｖｉｃｅＮｉのクラスとに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージをサーバに送信する。このＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを受信すると、サーバはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１３と、「ＳｅｒｖｉｃｅＮｉのクラス＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、クライアントに送信する。これによって、クライアントがサーバ側の変更されたデータを取得することができる。アクセスコントロールビットマップからサーバ側において変更されたフィーチャーがないと判断される場合は、 Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを送信しない。

図１１に関連して説明したように、クライアントは、取得された設定変更ビットマップと、クライアント内部のビットマップとを論理的ＯＲすることで、同期させるデータを判別することができる。例えば、サーバの設定のうちＳｅｒｖｉｃｅＮｊを変更したい場合、クライアントは、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１３と、「ＳｅｒｖｉｃｅＮｊのクラス＋更新データ」とに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを、サーバに送信する。Ｗｒｉｔｅ Ｃｏｍｍａｎｄ の代わりに、Ｒｅｓｐｏｎｓｅメッセージを伴うＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを用いることも可能である。この場合、上記データが書き込まれると、サーバはクライアントにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図２１は本発明の一実施形態に係るサーバとクライアントとの間に再接続が発生するパターンにおいてサーバとクライアント間のデータ通信方法を示す。所定のタイミングに、サーバである第１の装置１００がアドバタイジングパケットを送信する。上記所定のタイミングは、例えば、所定の時刻になった時、又は、ユーザの所定の操作があった時である。このアドバタイジングパケットには、サーバ側において前回の通信の後に変更があったフィーチャーを示す設定変更ビットマップが格納される。即ち、本実施形態では、サーバとクライアント間のコネクションが構築される前に、アドバタイズ段階においてサーバの設定変更ビットマップをクライアントに送信する。第２の装置２００が上記アドバタイジングパケットを受信することによって、サーバ側の設定変更ビットマップを取得することができる。図示された例において、サーバ側の設定変更ビットマップは０００１００００である。即ち、前回の通信の後に５番目のフィーチャーの設定が変更された。上述のように、第１の装置１００と第２の装置２００でビットマップの順番を共通にすることで、第２の装置２００が取得された上記ビットマップから第１の装置１００のどのフィーチャーに変更があったかを判別することができる。また、図１１に関連して説明したように、クライアントも、変更したいデータを示すビットマップを保持しておく。図示された例において、クライアント側のビットマップは０００００１００である。即ち、クライアント側では３番目のフィーチャーの設定が変更された。

上記アドバタイジングパケットを受信した第２の装置２００が、第１の装置１００にＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔを発信し、上記Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔを第１の装置１００が受信することによって、２つの装置のコネクションが構築される。次に、サービスディスカバリーが行われる。このサービスディスカバリーセッションで、クライアントである第２の装置２００は、第１の装置１００に実装されているサービスとキャラクタリスティックとに関する情報（図１９を参照）を取得する。

サービスディスカバリーが終了すれば、クライアントである第２の装置２００は設定変更ビットマップからサーバ側で変更があったフィーチャー（本例では、ＳｅｒｖｉｃｅＮ５）を判別し、当該フィーチャーの値を読み出すために、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ｒｅａｄ Ｒｅｑｕｅｓｔ ｆｏｒ Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１１と、ＳｅｒｖｉｃｅＮ５のクラスとに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージをサーバに送信する。このＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを受信すると、サーバはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１３と、「ＳｅｒｖｉｃｅＮ５のクラス＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、クライアントに送信する。これによって、クライアントがサーバ側の変更されたデータを取得することができる。設定変更ビットマップからサーバ側において変更されたフィーチャーがないと判断される場合は、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを送信しない。

図１１に関連して説明したように、クライアントは、取得された設定変更ビットマップとクライアント内部のビットマップとを論理的ＯＲすることで、同期させるデータを判別することができる。図示された例においては、Ｓｅｒｖｉｃｅ Ｎ３の設定の変更が要求されるので、クライアントはＡｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメーターとのそれぞれが、Ａｌｌ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルである０ｘ００１３と、「ＳｅｒｖｉｃｅＮ３のクラス＋更新データ」とに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを、サーバに送信する。Ｗｒｉｔｅ Ｃｏｍｍａｎｄの代わりに、Ｒｅｓｐｏｎｓｅメッセージを伴うＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを用いることも可能である。この場合、ＳｅｒｖｉｃｅＮ３が上記データに更新されると、サーバはクライアントにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。

必要なデータのやり取りが完了すれば、例えば、第２の装置２００がコネクションを切断する手続きを開始するためのメッセージ（ＬＬ＿ＴＥＲＭＩＮＡＴＥ＿ＩＮＤ）を第１の装置１００に送信し、第１の装置１００から確認（Ａｃｋ）メッセージを受信することによって、コネクションを切断する。第１の装置１００と第２の装置２００との両側において設定に変更がなかった場合、即ち、両側のビットマップの全てのビットの値が０である場合は、やりとりするデータがないので、コネクションが構築された後にすぐにコネクションを切断する。

上記実施形態では、サーバに対して設定情報を要求するＷｒｉｔｅ ＣｏｍｍａｎｄメッセージのＨａｎｄｌｅ Ｖａｌｕｅパラメーターとして、変更があったフィーチャーのクラスを用いる。他の実施形態では、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージの Ｈａｎｄｌｅ Ｖａｌｕｅパラメーターとして設定変更ビットマップを用いる。パラメーターとしてビットマップを用いれば、クラスを用いる場合に比べて通信データの量を減らすこともできる。例えば、サーバ側のフィーチャーが１個である場合、ビットマップは１ビットの大きさを持つので、１バイトの大きさであるクラスを用いる場合に比べてデータの量が１／８に減少する。即ち、ビットマップをパラメーターとして用いれば、フィーチャーの数によっては、クラスを用いる場合に比べて最大１／８程度まで通信するデータの量を減少させることが可能である。

上述した複数の実施形態において、Ｗｒｉｔｅ ＣｏｍｍａｎｄメッセージはＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージに切り替えることができ、Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージはＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることができる。メッセージの種類は、送信データの重要度、メッセージを受信する端末のバッテリーの容量、等によって決まる。

また、上述した複数の実施形態において、サーバは、クライアントから要求メッセージ、例えば、図１４のＡｌｌ ＦｅａｔｕｒｅｓへのＲｅａｄ Ｒｅｑｕｅｓｔ、図２０のＲｅａｄ Ｒｅｑｕｅｓｔ ｆｏｒ Ａｌｌ ＦｅａｔｕｒｅｓへのＷｒｉｔｅ Ｃｏｍｍａｎｄが受信されると、前回の通信の後に変更があった設定情報をクライアントに送信する。しかし、本発明は、この実施形態に限定されない。他の実施形態では、クライアントが設定情報を要求するメッセージを送信せずに、所定のタイミングになると、サーバが前回の通信の後に変更があった設定情報を格納した告知又は指示メッセージをクライアントに送信する。

尚、図１３又は図１９に示された実施形態によると、全てのフィーチャーの値を統合型キャラクタリスティックであるＡｌｌ Ｆｅａｔｕｒｅｓを利用して管理することで、サービスディスカバリーに所要する時間が短縮されることができ、これは接続時間を減らす。また、新しいフィーチャーが付加されてもサービスやキャラクタリスティックを追加する必要がない。サーバ装置に現在のバージョンの仕様に含まれているフィーチャーを追加しようとする場合は、当該フィーチャーに対応するクラスとアトリビュートを追加すれば良い。この場合は、フィーチャーの追加のためのユーザのプログラミングの時に上記フィーチャーによってクラスが自動的に付与されるように通信装置のファームウェアが設計されているとユーザの便宜性を高めることができる。また、現在のバージョンの仕様に含まれていない新しいフィーチャーをユーザに追加、即ち、新しいクラスを生成させることができるようにファームウェアが設計されても良い。新しく生成されるクラスは他のフィーチャーのクラスと異なる固有の値を持つことが好ましい。尚、ユーザが標準グループが管理するウェブサイトを通じてフィーチャーを追加することができるようにすることも可能である。新しいフィーチャーが追加された仕様は、ファームウェアのアップデート等によって通信装置に適用されることができる。

以上、本発明をブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））、特に、ＢＬＥに適用した実施形態について説明したが、本発明の適用分野はこれに限定されないし、例えば、他の無線通信技術にも適用可能である。特に、サービスディスカバリーの概念を用いる無線通信技術に適用可能である。

本発明が属する技術分野における通常の知識を有する者は、上記説明及び関連図面から本発明の多くの変形及び他の実施形態を導出することができる。従って、本発明は開示された特定の実施形態に限定されない。本明細書では、複数の特定用語が使われているが、これらは一般的な意味として単に説明の目的のために使われただけであり、発明を制限する目的で使われたものではない。添付の特許請求の範囲及びその均等物により定義される一般的な発明の概念及び思想を抜け出さない範囲で多様な変形が可能である。

（付記１）
無線通信のできる装置であって、
通信パケットを他の通信装置と送受信する通信部と、
一つ以上の種類の設定情報を格納するメモリと、
プロセッサと、
を備え、
前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御することを特徴とする通信装置。

（付記２）
前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする付記１に記載の通信装置。

（付記３）
前記ビットマップの各ビットは、対応する前記設定情報が前記他の通信装置との前回の通信後に変更されたかどうかを示すことを特徴とする付記２に記載の通信装置。

（付記４）
前記ビットマップの各ビットは、対応する前記設定情報が前記他の通信装置との前回の通信後に変更された場合は１に設定され、変更されていない場合は０に設定されることを特徴とする付記２又は３に記載の通信装置。

（付記５）
前記プロセッサは、所定のタイミングに、前記通信部に、前記判別情報を前記他の通信装置に送信させることを特徴とする付記１乃至４の何れか１つに記載の通信装置。

（付記６）
前記プロセッサは、前記他の通信装置から前記判別情報を要求するメッセージが受信された場合に、前記通信部に、前記判別情報を前記他の通信装置に送信させることを特徴とする付記１乃至５の何れか１つに記載の通信装置。

（付記７）
前記判別情報は、前記他の通信装置に送信されるアドバタイジングパケットに格納されることを特徴とする付記１乃至６の何れか１つに記載の通信装置。

（付記８）
前記プロセッサは、前記通信部に、前記変更された設定情報を前記他の通信装置に送信させることを特徴とする付記１乃至７の何れか１つに記載の通信装置。

（付記９）
前記プロセッサは、前記通信部を介して前記他の通信装置から設定情報を要求するメッセージが受信された場合に、前記通信部に、前記変更された設定情報を前記他の通信装置に送信させることを特徴とする付記１乃至７の何れか１つに記載の通信装置。

（付記１０）
前記他の通信装置との前回の通信後に変更がなかった設定情報は、前記他の通信装置に送信されないことを特徴とする付記８又は９に記載の通信装置。

（付記１１）
前記プロセッサは、前記判別情報に基づいて、前記少なくとも一つの変更された設定情報を含む更新情報を生成し、
所定のタイミングに、前記通信部に、前記更新情報を前記他の通信装置に送信させることを特徴とする付記１乃至７の何れか１つに記載の通信装置。

（付記１２）
前記他の通信装置との前回の通信の後に複数の設定情報が変更された場合に、
前記プロセッサは、前記判別情報に基づいて、前記複数の変更された設定情報を含む更新情報を生成し、
前記更新情報に含まれる前記複数の設定情報の配列の順番は、前記ビットマップのビットの配列の順番にマッチングされることを特徴とする付記２に記載の通信装置。

（付記１３）
前記プロセッサは、前記通信部を介して前記他の通信装置から前記一つ以上の種類の設定情報のうち少なくとも一つの更新値を受信した場合、前記メモリに格納されている前記設定情報の値を前記更新値に更新することを特徴とする付記１乃至１２の何れか１つに記載の通信装置。

（付記１４）
付記１乃至１３の何れか１つに記載の通信装置と、
現在の日時を計数する計時部と、
を備えることを特徴とする電子時計。

（付記１５）
無線通信のできる装置であって、
他の通信装置からサービス情報を受信し、前記他の通信装置と通信パケットを送受信する通信部と、
一つ以上の種類の設定情報を格納するメモリと、
プロセッサと、
を備え、
前記プロセッサは、前記他の通信装置から前記一つ以上の種類の設定情報の更新の有無を示す判別情報を受信し、前記判別情報に基づいて、前記他の通信装置との通信を制御することを特徴とする通信装置。

（付記１６）
前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする付記１５に記載の通信装置。

（付記１７）
前記判別情報は、前記設定情報の種類の個数のビットを有する第１のビットマップであり、
前記プロセッサは、前記他の通信装置との前回の通信後に前記一つ以上の種類の設定情報に変更があるかどうかを示す第２のビットマップを生成し、
前記第１のビットマップと第２のビットマップとに基づいて、前記一つ以上の種類の設定情報を前記他の通信装置の設定情報と同期させることを特徴とする付記１５又は１６に記載の通信装置。

（付記１８）
無線通信のできる装置の通信方法であって、
他の通信装置とペアリングするステップと、
前記他の通信装置との前回の通信後に、一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断するステップと、
前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成するステップと、
前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
を備えることを特徴とする通信方法。

（付記１９）
無線通信のできる装置の通信方法であって、
他の通信装置とペアリングするステップと、
前記他の通信装置から、一つ以上の種類の設定情報を更新するかどうかを示す判別情報を受信するステップと、
前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
を備えることを特徴とする通信方法。

（付記２０）
無線通信のできる装置に、
他の通信装置とペアリングするステップと、
前記他の通信装置との前回の通信後に、一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断するステップと、
前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成するステップと、
前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
を実行させるプログラム。

（付記２１）
無線通信のできる装置に、
他の通信装置とペアリングするステップと、
前記他の通信装置から、一つ以上の種類の設定情報を更新するかどうかを示す判別情報を受信するステップと、
前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
を実行させるプログラム。
（符号の説明）

１００ 電子時計
２００ スマートフォン
１０２ 近距離通信部
１０４ プロセッサ
１０６ 電源部
１０８ メモリ
１１０ 時計部
１１２ 入力部
１１４ 表示部
２０２ 遠距離通信処理部
２０４ 近距離通信部
２０６ プロセッサ
２０８ メモリ
２１０ 電源部
２１２ 入力部
２１４ 表示部
２１６ 時計部

Claims (19)

1. 無線通信のできる装置であって、
   通信パケットを他の通信装置と送受信する通信部と、
   一つ以上の種類の設定情報を格納するメモリと、
   プロセッサと、
   を備え、
   前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
   前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする通信装置。
2. 前記ビットマップの各ビットは、対応する前記設定情報が前記他の通信装置との前回の通信後に変更されたかどうかを示すことを特徴とする請求項１に記載の通信装置。
3. 前記ビットマップの各ビットは、対応する前記設定情報が前記他の通信装置との前回の通信後に変更された場合は１に設定され、変更されていない場合は０に設定されることを特徴とする請求項１又は２に記載の通信装置。
4. 前記他の通信装置との前回の通信の後に複数の設定情報が変更された場合に、
   前記プロセッサは、前記判別情報に基づいて、前記複数の変更された設定情報を含む更新情報を生成し、
   前記更新情報に含まれる前記複数の設定情報の配列の順番は、前記ビットマップのビットの配列の順番にマッチングされることを特徴とする請求項１に記載の通信装置。
5. 前記プロセッサは、所定のタイミングに、前記通信部に、前記判別情報を前記他の通信装置に送信させることを特徴とする請求項１乃至４の何れか１項に記載の通信装置。
6. 前記プロセッサは、前記他の通信装置から前記判別情報を要求するメッセージが受信された場合に、前記通信部に、前記判別情報を前記他の通信装置に送信させることを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
7. 前記判別情報は、前記他の通信装置に送信されるアドバタイジングパケットに格納されることを特徴とする請求項１乃至６の何れか１項に記載の通信装置。
8. 無線通信のできる装置であって、
   通信パケットを他の通信装置と送受信する通信部と、
   一つ以上の種類の設定情報を格納するメモリと、
   プロセッサと、
   を備え、
   前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
   また、前記プロセッサは、前記通信部に、前記変更された設定情報を前記他の通信装置に送信させることを特徴とする通信装置。
9. 無線通信のできる装置であって、
   通信パケットを他の通信装置と送受信する通信部と、
   一つ以上の種類の設定情報を格納するメモリと、
   プロセッサと、
   を備え、
   前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
   また、前記プロセッサは、前記通信部を介して前記他の通信装置から設定情報を要求するメッセージが受信された場合に、前記通信部に、前記変更された設定情報を前記他の通信装置に送信させることを特徴とする通信装置。
10. 前記他の通信装置との前回の通信後に変更がなかった設定情報は、前記他の通信装置に送信されないことを特徴とする請求項８又は９に記載の通信装置。
11. 無線通信のできる装置であって、
    通信パケットを他の通信装置と送受信する通信部と、
    一つ以上の種類の設定情報を格納するメモリと、
    プロセッサと、
    を備え、
    前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
    また、前記プロセッサは、前記判別情報に基づいて、前記少なくとも一つの変更された設定情報を含む更新情報を生成し、所定のタイミングに、前記通信部に、前記更新情報を前記他の通信装置に送信させることを特徴とする通信装置。
12. 無線通信のできる装置であって、
    通信パケットを他の通信装置と送受信する通信部と、
    一つ以上の種類の設定情報を格納するメモリと、
    プロセッサと、
    を備え、
    前記プロセッサは、前記他の通信装置との前回の通信後に、前記一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断し、前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
    また、前記プロセッサは、前記通信部を介して前記他の通信装置から前記一つ以上の種類の設定情報のうち少なくとも一つの更新値を受信した場合、前記メモリに格納されている前記設定情報の値を前記更新値に更新することを特徴とする通信装置。
13. 請求項１乃至１２の何れか１項に記載の通信装置と、
    現在の日時を計数する計時部と、
    を備えることを特徴とする電子時計。
14. 無線通信のできる装置であって、
    他の通信装置からサービス情報を受信し、前記他の通信装置と通信パケットを送受信する通信部と、
    一つ以上の種類の設定情報を格納するメモリと、
    プロセッサと、
    を備え、
    前記プロセッサは、前記他の通信装置から前記一つ以上の種類の設定情報の更新の有無を示す判別情報を受信し、前記判別情報に基づいて、前記他の通信装置との通信を制御し、
    前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする通信装置。
15. 前記判別情報は、前記設定情報の種類の個数のビットを有する第１のビットマップであり、
    前記プロセッサは、前記他の通信装置との前回の通信後に前記一つ以上の種類の設定情報に変更があるかどうかを示す第２のビットマップを生成し、
    前記第１のビットマップと第２のビットマップとに基づいて、前記一つ以上の種類の設定情報を前記他の通信装置の設定情報と同期させることを特徴とする請求項１４に記載の通信装置。
16. 無線通信のできる装置の通信方法であって、
    他の通信装置とペアリングするステップと、
    前記他の通信装置との前回の通信後に、一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断するステップと、
    前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成するステップと、
    前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
    を備え、
    前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする通信方法。
17. 無線通信のできる装置の通信方法であって、
    他の通信装置とペアリングするステップと、
    前記他の通信装置から、一つ以上の種類の設定情報を更新するかどうかを示す判別情報を受信するステップと、
    前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
    を備え、
    前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であることを特徴とする通信方法。
18. 無線通信のできる装置に、
    他の通信装置とペアリングするステップと、
    前記他の通信装置との前回の通信後に、一つ以上の種類の設定情報のうち少なくとも一つに変更があるかどうかを判断するステップと、
    前記一つ以上の種類の設定情報の変更の有無を示す判別情報を生成するステップと、
    前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
    を実行させ、
    前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であるプログラム。
19. 無線通信のできる装置に、
    他の通信装置とペアリングするステップと、
    前記他の通信装置から、一つ以上の種類の設定情報を更新するかどうかを示す判別情報を受信するステップと、
    前記判別情報に基づいて、前記他の通信装置との通信を制御するステップと、
    を実行させ、
    前記判別情報はビットマップであり、前記ビットマップのビットの数は、前記設定情報の種類の個数と同一であるプログラム。

Images