JP2018164225A - 通信装置、通信方法、及びプログラム - Google Patents

Abstract

【課題】無線通信装置の間の通信の効率性を高める方法、この方法を実行する通信装置及びプログラムを提供することにある。
【解決手段】無線通信のできる装置は、通信パケットを他の通信装置と送受信する通信部と、プロセッサと、を備える。上記プロセッサは、上記通信部を介して上記他の通信装置から、データのパッケージ方法を示す第１の情報を含むパケットを受信し、上記第１の情報に対応するデータを上記通信部を介して上記他の通信装置と通信する。
【選択図】図９

Description

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

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

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

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

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

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

本発明の１つの態様は、通信装置であって、通信パケットを他の通信装置と送受信する通信部と、プロセッサと、を備え、上記プロセッサは、上記通信部を介して上記他の通信装置から、データのパッケージ方法を示す第１の情報を含むパケットを受信し、上記第１の情報に対応するデータを前記通信部を介して上記他の通信装置と通信する。

また、本発明の他の１つの態様は、無線通信のできる装置であって、他の通信装置と通信パケットを送受信する通信部と、プロセッサと、を備え、上記プロセッサは、他の通信装置の単位通信当たり通信可能のデータサイズに基づいて、上記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決める。

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

以下の詳細な記述が以下の図面と合わせて考慮されると、本願のより深い理解が得られる。これらの図面は例示に過ぎず、本発明の範囲を限定するものではない。
本明細書において提案された方法が適用されることができる無線通信システムの一例を示す図である。 本明細書において提案された方法を具現することができる装置の内部ブロック図の一例を示す。 アドバタイジングパケットの種類を説明する図である。 （Ａ）はアトリビュート値をやり取りするためのアトリビュートプロトコルＰＤＵの通常の構造を示す図であり、（Ｂ）はＧＡＴＴサーバに格納されるアトリビュートの通常の構造を示す図である。 通常のアトリビュートデータベースの一例を示す図である。 サーバとクライアントとがＢＬＥ通信によりデータのやり取りを行う通常の方法を示す。 本発明の一実施形態に係るアトリビュートデータベースの一例を示す図である。 本発明の一実施形態に係る区別情報の一例を示す図である。 本発明の一実施形態に係るスマートフォンが電子時計にデータの送信を指示する方法を示すシーケンス図である。 本発明の一実施形態に係る指示コマンドのＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅのフォーマットを示す図である。 本発明の一実施形態に係るコマンド種別の一例を示す図である。 （Ａ）は本発明の一実施形態に係る送信指示用の指示コマンドのＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅの一例を示す図であり、（Ｂ）は本発明の一実施形態に係る設定情報のノーティフィケーションメッセージのＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅの一例を示す図である。 本発明の一実施形態に係るスマートフォンが電子時計にデータの書込みを指示する方法を示すシーケンス図である。 （Ａ）は本発明の一実施形態に係る書込待機指示用の指示コマンドのＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅの一例を示す図であり、（Ｂ）は本発明の一実施形態に係る書込みコマンドメッセージのＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅの一例を示す図である。 本発明の一実施形態に係る電子時計の機能ブロック図である。 本発明の一実施形態に係るスマートフォンの機能ブロック図である。 本発明の一実施形態に係る電子時計においての通信プロセスを実現するためのアルゴリズムを示すフローチャートである。 本発明の一実施形態に係るスマートフォンにおいて電子時計にデータの送信を指示する通信プロセスを実現するためのアルゴリズムを示すフローチャートである。 本発明の一実施形態に係るスマートフォンにおいて電子時計にデータの書込みを指示する通信プロセスを実現するためのアルゴリズムを示すフローチャートである。 本発明の他の実施形態に係るスマートフォンにおいて電子時計にデータの送信を指示する通信プロセスを実現するためのアルゴリズムを示すフローチャートである。 本発明の他の実施形態に係るアトリビュートデータベースの一例を示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＡＴＴはサーバ／クライアント構造で相手デバイスのデータに接近するための規則を定義する。ＡＴＴには６種類のメッセージ類型（要求、応答、コマンド、ノーティフィケーション、インディケーション、確認（Ｃｏｎｆｉｒｍａｔｉｏｎ））が定義される。
（１）要求及び応答メッセージ：要求メッセージはクライアントがサーバに特定の情報を要請するために送信するメッセージであり、応答メッセージはサーバがクライアントへ送信する要求メッセージに対する返事である。
（２）コマンドメッセージ：クライアントがサーバに特定の動作を要請するために送信するメッセージであり、サーバはコマンドメッセージに対する応答をクライアントに送信しない。
（３）ノーティフィケーションメッセージ：サーバがクライアントにイベント等の通知のために送信するメッセージであり、クライアントはノーティフィケーションメッセージに対する確認メッセージをサーバに送信しない。
（４）インディケーション及び確認メッセージ：インディケーションメッセージはサーバがクライアントにイベント等の通知のために送信するメッセージであり、ノーティフィケーションメッセージとは違い、クライアントはインディケーションメッセージに対する確認メッセージをサーバに送信する。

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

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

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

図３はアドバタイジングパケットの種類を説明する図である。ブルートゥース通信に用いられるアドバタイジングパケットは図３に示されたように４つのタイプが存在し、パケットのＰＤＵヘッダのＰＤＵ Ｔｙｐｅフィールドに設定された値がパケットのタイプを示す。ＡＤＶ＿ＩＮＤは相手を指定しない接続可能アドバタイジングイベントに用いられ、簡易情報問合せが可能である（即ち、ｓｃａｎｎａｂｌｅ)。簡易情報問合せは、コネクションの前に、スキャンを行う装置（スキャナー）がアドバタイズを行う装置（アドバタイザー）にスキャン要求（ＳＣＡＮ＿ＲＥＱ ＰＤＵ）を送信してアドバタイザーに追加情報（機器情報、提供するサービス、等）を要求する手続きをいう。ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤは指定された装置のみ接続可能なアドバタイジングイベントに用いられる。ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤはアドバタイジングデータを格納するためのデータ部を有しない。従って、アドバタイズによってアドバタイザーのデータを伝送しようとする場合はＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤを使うことができない。ＡＤＶ＿ＮＯＮＣＯＮＮ＿ＩＮＤはいかなる装置も接続不可なアドバタイジングイベントに用いられる。ＡＤＶ＿ＳＣＡＮ＿ＩＮＤはいかなる装置もスキャン可能なアドバタイジングイベントに用いられ、簡易情報問合せが可能である（即ち、どんな装置も簡易情報問合せのみ可能）。

図４（Ａ）はアトリビュート値をやり取りするためのアトリビュートプロトコルＰＤＵの通常の構造を示す。ＧＡＴＴプロファイルは、装置の間にコマンド、要求、応答、インディケーション、ノーティフィケーション、及び確認の形態でデータを伝送するために、アトリビュートプロファイルを用いる。このデータは、図４（Ａ）に示された構造のアトリビュートプロトコルＰＤＵに格納される。アトリビュートプロトコルＰＤＵはアトリビュートオペコード（Ａｔｔｒｉｂｕｔｅ Ｏｐｃｏｄｅ）フィールド、アトリビュートパラメータ（Ａｔｔｒｉｂｕｔｅ Ｐａｒａｍｅｔｅｒｓ）フィールド、及び認証署名（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｉｇｎａｔｕｒｅ）フィールド（選択的）によって構成される。認証署名は、オプションフィールドであり、選択的に存在したり存在しなかったりする。

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

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

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

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

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

クライアントとサーバとのコネクションが確立されると、両方の装置がデータ通信を行うことができ、クライアントは、サーバが提供する特定のサービスにアクセスすることができる。例えば、図６は、サーバとクライアントとがＢＬＥ通信によりデータのやり取りを行う通常の方法を示す。図示された例では、第１の装置１００がサーバとして動作し、第２の装置２００がクライアントとして動作する。第１の装置１００には、図５のアトリビュートデータベースが実装されている。サーバに特定のキャラクタリスティック値を要求しようとする場合、クライアントは読み出し要求（Ｒｅａｄ Ｒｅｑｕｅｓｔ）をサーバに送信する。読み出し要求は、ＢＬＥ仕様に定義されたように、サーバにアトリビュートの値を読み出してその値を送るように要求するために使われるメッセージであり、アトリビュートハンドルをパラメータとして使う。この場合、読み出し要求メッセージのアトリビュートハンドルパラメータは、キャラクタリスティック値ハンドルに設定される。

クライアントからの読み出し要求が有効である場合、即ち、クライアントがデータを要求する権限を持つ同時に当該データを読み出すことが可能な場合に、サーバはクライアントが要求するデータを読み出し応答（Ｒｅａｄ Ｒｅｓｐｏｎｓｅ）によってクライアントに送信する。読み出し応答は、ＢＬＥ仕様に定義されたように、読み出し要求に応答するためにサーバによって送信されるメッセージであり、読み出されたアトリビュートの値を含む。読み出し応答メッセージは、アトリビュート値をパラメータとして使い、この場合、読み出し応答によって伝送される値は、上記キャラクタリスティック値ハンドルに対応するキャラクタリスティック値（である。

例えば、クライアントがＳｅｒｖｉｃｅＮ１の値を要求する場合は、クライアントはアトリビュートハンドルパラメータが０ｘ００１２に設定されている読み出し要求をサーバに送信する。これに対する応答として、サーバはアトリビュート値パラメータが「ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ」に設定されている読み出し応答をクライアントに送信する。

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

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

クライアントは必要な時に、例えば、所定の時刻になった時、又は、ユーザの操作があった時に、サーバにデータを要求したり、データの記入を指示したり、サーバからデータを受信したりする。現在、ＢＬＥ装置、例えば、ウェアラブル電子時計（スマートウォッチとも称する。）では、複数種類の情報を他の装置とやり取りする際に、各々の種類のデータを別個のメッセージで送受信する。従って、やり取りするデータの種類が多くなると、その種類数分だけ送受信回数が増加する。このようなトランザクション回数の増加は、電力消費及び処理負荷を増加させる。以下複数の実施形態を利用して記述される本発明は、データのトランザクションを制御することで、通信の効率性を高める。しかし、本発明はこれらの実施形態に限定されなく、本発明が属する技術の分野における通常の知識を有する者は、本明細書の記載から多様な変形や代案を容易に導出することができる。

図７は本発明の一実施形態に係るアトリビュートデータベースの一例を示す。図５に示された従来のアトリビュートデータベースはＷａｔｃｈ Ｆｅａｔｕｒｅ Ｓｅｒｖｉｃｅのｘ個のフィーチャーに対応するｘ個のキャラクタリスティックを含んでおり、アトリビュート値としてそれぞれのキャラクタリスティックの値を格納する。本実施形態に係るアトリビュートデータベースは、フィーチャーの数に関わらず、３つのキャラクタリスティック、即ち、Ｕｐｄａｔｅｄ ＡＴＴ＿ＭＴＵと、Ｒｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓと、Ｗａｔｃｈ Ｆｅａｔｕｒｅｓとを含む。

Ｕｐｄａｔｅｄ ＡＴＴ＿ＭＴＵは、第１の装置である電子時計と、第２の装置であるスマートフォン２００との間のＭＴＵサイズ交換手続きにより更新されたＡＴＴ＿ＭＴＵをスマートフォン２００へ通知するためのキャラクタリスティックである。ＭＴＵは、単位通信当りの通信可能なデータ容量（サイズ）を示す。ＢＬＥ仕様に定義されたように、ＡＴＴ＿ＭＴＵはクライアントとサーバとの間で送信されるパケットの最大サイズであり、ＭＴＵサイズ交換はＡＴＴ＿ＭＴＵを両方の装置によってサポートされる最大可能値に設定するためにクライアントによって使用されるサーバコンフィギュレーションのサブプロシージャである。また、ＭＴＵサイズ交換要求は、クライアントの最大受信ＭＴＵサイズをサーバに知らせるとともに、サーバに最大受信ＭＴＵサイズを送信するように要求するためにクライアントによって用いられるメッセージである。サーバは、クライアントからＭＴＵサイズ交換要求を受信すると、ＭＴＵサイズ交換応答で応答する。ＭＴＵサイズ交換応答は、サーバの最大受信ＭＴＵサイズをクライアントに知らせるために用いられるメッセージである。クライアントとサーバは、交換されたＭＴＵサイズの最小値を使用して、以後の通信を行なう。

通常、ＢＬＥ通信装置において、搭載されたＢＬＥチップからＡＴＴ＿ＭＴＵサイズを取得するためのＨＣＩ（Ｈｏｓｔ Ｃｏｎｔｒｏｌｌｅｒ Ｉｎｔｅｒｆａｃｅ）コマンドが用意されるが、スマートフォンの場合、それを利用するためのＡＰＩが用意されてない。そこで、本実施形態では、クライアントであるスマートフォンのプロセッサ（例えば、図２（Ｂ）の２０６）がＡＴＴ＿ＭＴＵサイズを利用することができるように、接続相手である電子時計がＭＴＵサイズ交換（Ｅｘｃｈａｎｇｅ ＭＴＵ）により更新されたＡＴＴ＿ＭＴＵサイズをスマートフォンに通知する仕組みを設ける。Ｕｐｄａｔｅｄ ＡＴＴ＿ＭＴＵは、更新されたＡＴＴ＿ＭＴＵサイズをスマートフォンに通知するためのキャラクタリスティックである。

Ｒｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓは、電子時計１００がデータを送受信するフォーマットを指定する指示コマンドを書込むためのキャラクタリスティックである。Ｗａｔｃｈ Ｆｅａｔｕｒｅｓは、電子時計１００の設定情報であるフィーチャーの設定値を読み書きするためのキャラクタリスティックである。本実施形態では、通常のキャラクタリスティック（即ち、図５のＳｅｒｖｉｃｅＮ１乃至ＳｅｒｖｉｃｅＮｘ）に対応するｘ個のフィーチャーの設定値を、Ｗａｔｃｈ Ｆｅａｔｕｒｅｓのアトリビュート値として格納する。そこで、ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ乃至ＳｅｒｖｉｃｅＮｘ ｖａｌｕｅに１つのハンドル（０ｘ００１７）のみが割り当てられるので、上記複数の種類のデータを区別するための情報である区別情報を更に使用する。換言すれば、従来にＵＵＩＤ又はハンドル値によって区別されていた複数の種類の設定情報を、区別情報によって区別する。

区別情報の一例は、図８に示される。この例において、区別情報の値は、１バイトのサイズを有する。具体的に、ＳｅｒｖｉｃｅＮに対応するＦｅａｔｕｒｅＮの設定データには、区別情報として（Ｎ−１）＜ＳＵB＞１＜/ＳＵB＞＜ＳＵB＞６＜/ＳＵB＞が割り当てられる（ＳｅｒｖｉｃｅＮ１に対応するＦｅａｔｕｒｅ１の設定データに割り当てられる区別情報の値は０ｘ００）。本実施形態において、１バイトのサイズの最大値である０ｘＦＦは、区切りの指定を示す情報として用いられる。区切りの指定については後述する。従って、区別情報によって総２５５種類のデータを区別することができる。通信装置のそれぞれが同一の区別情報を保有するように、区別情報は仕様（スペックとも称する。）として管理されることが好ましい。

図７に示すように、ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ乃至ＳｅｒｖｉｃｅＮｘ ｖａｌｕｅのそれぞれに対応するフィーチャーの設定データを記憶するように割り当てられた領域の先頭の１バイトに、各設定データの区別情報を記憶し、残りの領域に実際のデータを記憶する。一方、区別情報が記憶される位置は、データ記憶領域の先頭に限定されない。

図９は、本発明の一実施形態に係るスマートフォン２００が電子時計１００にデータの送信を指示する方法を示すシーケンス図である。本実施形態において、電子時計１００に実装されるアトリビュートデータベースは図７の構造を有する。電子時計１００がサーバとして動作し、スマートフォン２００がクライアントとして動作する。電子時計１００は、所定の条件が満たされたときに（例えば、あらかじめ設定された時刻に、又は、ボタン操作があったときに）、アドバタイズを開始する。本実施形態で、電子時計１００の送信するアドバタイジングパケットのタイプは、ＡＤＶ＿ＩＮＤである。電子時計１００がＷａｔｃｈ Ｆｅａｔｕｒｅ Ｓｅｒｖｉｃｅを保有していることを示すために、当該アドバタイジングパケットのＡｄｖＤａｔａは、Ｃｏｍｐｌｅｔｅ Ｌｉｓｔ ｏｆ １２８ｂｉｔ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ ＵＵＩＤｓを示す値に設定されたＡＤ Ｔｙｐｅと、Ｗａｔｃｈ Ｆｅａｔｕｒｅ Ｓｅｒｖｉｃｅを示す１２８ビットＵＵＩＤに設定されたＡＤ Ｄａｔａとで構成されるＡＤ Ｓｔｒｕｃｔｕｒｅを含む。一方、スマートフォン２００は、周期的に、又は、所定の条件が満たされたときに（例えば、所定の時刻になったときに、又は、ボタン操作があったときに）スキャンを開始する。

スマートフォン２００のコントローラからのアドバタイジングレポートを受け取ったスマートフォン２００のホストは、電子時計１００とのコネクションが必要である場合、コネクション要求（Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）を発信する。上記コネクション要求を電子時計１００が受信することによって、２つの装置が物理的に接続される。ＢＬＥ仕様に定義されたように、コネクション要求は、２つの装置の間にＬ２ＣＡＰチャンネルを生成するためにマスター装置がスレーブ装置に送信するパケットである。そして、２つの装置の間に、サービスディスカバリーが行われる。サービスディスカバリーセッションで、スマートフォン２００は、電子時計１００のサービスであるＷａｔｃｈ Ｆｅａｔｕｒｅ Ｓｅｒｖｉｃｅに含まれるキャラクタリスティックのアトリビュートハンドルを取得する。

次に、電子時計１００とスマートフォン２００とは、各々の装置がサポートするＭＴＵサイズを交換する。具体的に、クライアントであるスマートフォン２００が、最大受信ＭＴＵサイズをサーバである電子時計１００に知らせるとともに、電子時計１００に最大受信ＭＴＵサイズを送信するように要求するためにＭＴＵサイズ交換要求（Ｅｘｃｈａｎｇｅ ＭＴＵ Ｒｅｑｕｅｓｔ）を送信する。電子時計１００は、上記ＭＴＵサイズ交換要求を受信すると、最大受信ＭＴＵサイズをクライアントに知らせるためにＭＴＵサイズ交換応答（Ｅｘｃｈａｎｇｅ ＭＴＵ Ｒｅｓｐｏｎｓｅ）を送信する。電子時計１００は、両方のＭＴＵサイズの最小値を更新されたＡＴＴ＿ＭＴＵとして取得し、図７のＵｐｄａｔｅｄ ＡＴＴ＿ＭＴＵのアトリビュート値として記憶する。そして、電子時計１００は、更新されたＡＴＴ＿ＭＴＵを、ノーティフィケーションメッセージによりスマートフォン２００に通知する。上記ノーティフィケーションメッセージを受信することで、スマートフォン２００が更新されたＡＴＴ＿ＭＴＵを取得することができる。

スマートフォン２００では、電子時計１００から取得したい複数の種類の設定情報の長さから、取得されたＡＴＴ＿ＭＴＵ（上記更新されたＡＴＴ＿ＭＴＵ）に収まるように、データの順序、組み合わせ、区切り、等を含むデータのパッケージ方法を決定する。区切りは、１つのパケットで通信するデータと、他のパケットで通信するデータを区分する。本実施形態では、一つのパケットに格納されるデータの総長さが、例えば、更新されたＡＴＴ＿ＭＴＵ−３以下になるように、区切りを指定する。上記パッケージ方法に応じて、要求するデータのフォーマットが決まる。スマートフォン２００は、電子時計１００に設定情報の送信を要求するとともに、要求する設定情報のデータフォーマットを知らせるためのメッセージを生成する。上述したように、複数のフィーチャーの設定値に対して１つのハンドルが割り当てられて、読み出し要求はアトリビュートハンドルのみをパラメータとして持つので、本実施形態では、サーバである電子時計１００のアトリビュート値を要求するために読み出し要求を用いることができない。従って、本実施形態で、スマートフォン２００は、設定情報を要求するために、書き込みコマンドを使う。即ち、上記メッセージとして、アトリビュートハンドルパラメータと、アトリビュート値パラメータとのそれぞれが、Ｒｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドル（０ｘ００１７）と、上記データフォーマットを含むコマンドデータとに設定された書き込みコマンドを生成する。この書き込みコマンドを受信すれば、電子時計１００は、キャラクタリスティックであるＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値に、上記データフォーマットを書き込む。このメッセージを、フィーチャーの設定値を書込むように要求するコマンドと区分するために、以下で『指示コマンド』と呼ぶ。

上記書き込みコマンド（指示コマンド）のアトリビュート値パラメータは、図１０に示すように、１バイトのコマンド種別と、それに続くコマンドデータとで構成される。コマンド種別は、当該指示コマンドの受信者との通信を制御するための情報であり、データのやり取りの方向を示す。コマンド種別の一例は、図１１に示されている。本例で、スマートフォン２００が電子時計１００にフィーチャーの設定値を送信するように指示（送信指示）する場合は、コマンド種別が０ｘ００に設定され、スマートフォン２００が電子時計１００にフィーチャーの設定値の書込みを待機するように指示（書込待機指示）する場合は、コマンド種別が０ｘ０１に設定される。従って、スマートフォン２００が電子時計１００に設定情報を要求する場合（図９）は、上記書き込みコマンドのコマンド種別が０ｘ００に設定される。コマンドデータは、取得されたＡＴＴ＿ＭＴＵサイズに基づいて決定された上記データフォーマットを示すデータとして、区別情報を羅列したものであり、電子時計１００はコマンドデータの並び順及び区切り指定に基づき設定情報を送受信する。

送信指示用の指示コマンドである書き込みコマンドのアトリビュート値の一例は、図１２（Ａ）に示されている。上述のように、コマンド種別は送信指示を示す０ｘ００に設定される。コマンドデータは、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１からＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４までの４つのデータを送信するように指示し、１つ目のメッセージとしてフィーチャー１の設定値とフィーチャー２の設定値とを結合して送信し、２つ目のメッセージとしてフィーチャー３の設定値とフィーチャー４の設定値とを結合して送信するよう指示している。即ち、スマートフォン２００は、電子時計１００にデータフォーマットを通知することで、更新されたＡＴＴ＿ＭＴＵに収まるように、上記４種類のデータを２つずつ集めて送信することを指示する。本実施形態では、一つのパケットに格納されるデータの総長さが、例えば、更新されたＡＴＴ＿ＭＴＵ−３以下になるように、データフォーマットが決まる。また、データフォーマットは、ＡＴＴ＿ＭＴＵサイズを最大に活用するように決めることが好ましい。具体的に、１つのメッセージにＡＴＴ＿ＭＴＵサイズの範囲内で最大の個数のデータが含まれるようにデータフォーマットを決めることが好ましい。

指示コマンドを受信した電子時計１００は、コマンド種別により、データを送信するか、スマートフォン２００からの書込みの指示を待機するかを判断する。図１２（Ａ）の例では、コマンド種別が０ｘ００に設定されているので、電子時計１００は指示コマンドのコマンドデータであるデータフォーマットに従って、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１からＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４を送信するための２つのメッセージであるハンドル値ノーティフィケーション１とハンドル値ノーティフィケーション２とを生成する。当該ハンドル値ノーティフィケーションは、アトリビュートハンドルパラメータと、アトリビュート値パラメータとのそれぞれが、Ｗａｔｃｈ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドル（０ｘ００１７）と、スマートフォン２００に送信する設定情報とに設定される。ハンドル値ノーティフィケーション１とハンドル値ノーティフィケーション２とのアトリビュート値の一例は図１２（Ｂ）に示されている。スマートフォン２００から受信したデータフォーマットに従って、ハンドル値ノーティフィケーション１のアトリビュート値パラメータには、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１とＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ２とのデータが順に格納され、ハンドル値ノーティフィケーション２のアトリビュート値パラメータには、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ３とＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４とのデータが順に格納される。

上記２つのノーティフィケーションを受信したスマートフォン２００は、各々のノーティフィケーションに格納されているデータを、指示コマンドによって指定した順序に結合されたデータとして解釈し、４つのフィーチャーの設定値を取得する。ここで、フィーチャー１からフィーチャー４までのデータは、それぞれ異なるデータ長を持っても構わないが、この場合は、データの解析を容易にするために、電子時計１００とスマートフォン２００との各々で各データ長を記憶していることが好ましい。この場合、スマートフォン２００は、データフォーマットとともにデータ長に基づいて、電子時計１００から受信されるメッセージを解析することができる。また、図９は更新されたＡＴＴ＿ＭＴＵと設定情報を送信するためにハンドル値ノーティフィケーションを用いる例を示したが、その代わりにハンドル値インディケーションを用いても良い。この場合、ハンドル値インディケーションを受信したスマートフォン２００は、ハンドル値確認を返信する。特に、設定情報を送信するためにハンドル値インディケーションを用いる場合は、電子時計１００が一番目のハンドル値インディケーションに対する返信であるハンドル値確認を受信した後に、二番目のハンドル値インディケーションをスマートフォン２００に送信しても良い。同様に、指示コマンドである書き込みコマンドは、書き込み要求に切り替えることもできる。この場合、書き込み要求を受信した電子時計１００は、書き込み応答を返信する。

図１３は、本発明の一実施形態に係るスマートフォン２００が電子時計１００にデータの書込みを指示する方法を示すシーケンス図である。本実施形態において、電子時計１００に実装されるアトリビュートデータベースは図７の構造を有する。電子時計１００がサーバとして動作し、スマートフォン２００がクライアントとして動作する。図１３において図９と同一のプロシージャについては詳細な説明を省略する。電子時計１００は、所定の条件が満たされたとき、アドバタイズを開始する。電子時計１００はＡＤＶ＿ＩＮＤタイプのアドバタイジングパケットを送信する。一方、スマートフォン２００はスキャンを開始する。

スマートフォン２００は、電子時計１００とのコネクションが必要である場合、コネクション要求を発信する。上記ネクション要求を電子時計１００が受信することによって、２つの装置が物理的に接続される。そして、サービスディスカバリーが行われる。次に、電子時計１００とスマートフォン２００とはＭＴＵサイズ交換を行い、電子時計１００は、両方のＭＴＵサイズの最小値を更新されたＡＴＴ＿ＭＴＵとして取得する。電子時計１００は、更新されたＡＴＴ＿ＭＴＵをＵｐｄａｔｅｄ ＡＴＴ＿ＭＴＵのアトリビュート値として、ノーティフィケーションメッセージによりスマートフォン２００に通知する。

スマートフォン２００は、電子時計１００に書込みたい複数の種類の設定情報の長さから、取得されたＡＴＴ＿ＭＴＵに収まるように、データの順序、組み合わせ、区切り、等を含むデータのパッケージ方法を決定する。上記パッケージ方法に応じて、書込むデータのフォーマットが決まる。スマートフォン２００は、電子時計１００に書込待機を指示するとともに、書き込む設定情報のデータフォーマットを知らせるための指示コマンドを生成する。この指示コマンドは、アトリビュートハンドルパラメータと、アトリビュート値パラメータとのそれぞれが、Ｒｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドル（０ｘ００１５）と、上記データフォーマットとに設定された書き込みコマンドである。この書き込みコマンドを受信すれば、電子時計１００はキャラクタリスティックであるＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値に上記データフォーマットを書き込む。

書込待機指示用の指示コマンドである書き込みコマンドのアトリビュート値の一例は、図１４（Ａ）に示されている。上述のように、１バイトのコマンド種別は書込待機指示を示す０ｘ０１に設定される。ＡＴＴ＿ＭＴＵサイズに基づいて決定されたデータフォーマットを示すコマンドデータは、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１からＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４までの４つのデータを２つのメッセージとして送信する旨を電子時計１００に知らせる。具体的に、１つ目のメッセージにはフィーチャー１の設定値とフィーチャー２の設定値とが格納され、２つ目のメッセージにはフィーチャー３の設定値とフィーチャー４の設定値とが格納されることを電子時計１００に知らせる。データフォーマットはＡＴＴ＿ＭＴＵサイズを最大に活用するように決まることが好ましい。

指示コマンドを受信した電子時計１００は、コマンド種別により（即ち、コマンド種別が０ｘ０１に設定されているので）、スマートフォン２００からの書込みの指示を待機する。また、指示コマンドのコマンドデータであるデータフォーマットに従って、スマートフォン２００から受信されるメッセージを解析する。

スマートフォン２００は、上記データフォーマットに従って、電子時計１００にＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１からＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４の書込みを指示するための２つのメッセージである書き込みコマンド１（Ｗｒｉｔｅ Ｃｏｍｍａｎｄ１）と書き込みコマンド２（Ｗｒｉｔｅ Ｃｏｍｍａｎｄ２）とを生成する。当該書き込みコマンドは、アトリビュートハンドルパラメータと、アトリビュート値パラメータとのそれぞれが、Ｗａｔｃｈ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドル（０ｘ００１７）と、書き込みたい設定情報とに設定される。書き込みコマンド１と書き込みコマンド２とのアトリビュート値の一例は図１４（Ｂ）に示されている。書き込みコマンド１のアトリビュート値パラメータには、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ１とＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ２とのデータが順に格納され、書き込みコマンド２のアトリビュート値パラメータには、Ｓｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ３とＳｅｔｔｉｎｇ ｆｏｒ Ｆｅａｔｕｒｅ４とのデータが順に格納される。

電子時計１００は、スマートフォン２００から書き込みコマンド１と書き込みコマンド２とを受信すると、指示コマンドから取得したデータフォーマットにより、上記メッセージを解析する。具体的に、書き込みコマンド１を解析して、当該メッセージのアトリビュート値に格納されている２つのデータを、フィーチャー１とフィーチャー２との設定値として書き込む（図７を参照）。即ち、フィーチャー１とフィーチャー２との設定値を、書き込みコマンド１のアトリビュート値に格納されている２つのデータに更新する。また、書き込みコマンド２を解析して、当該メッセージのアトリビュート値に格納されている２つのデータを、フィーチャー３とフィーチャー４との設定値として書き込む。即ち、フィーチャー３とフィーチャー４との設定値を、書き込みコマンド２のアトリビュート値に格納されている２つのデータに更新する。

ここで、フィーチャー１からフィーチャー４までのデータは、それぞれ異なるデータ長を持っても構わないが、この場合は、データの解析を容易にするために、電子時計１００とスマートフォン２００との各々で各データ長を記憶していることが好ましい。この場合、電子時計１００は、データフォーマットとともにデータ長に基づいて、スマートフォン２００から受信されるメッセージを解析することができる。図１３は更新されたＡＴＴ＿ＭＴＵを送信するためにハンドル値ノーティフィケーションを用いる例を示したが、その代わりにハンドル値インディケーションを用いても良い。また、書き込みコマンドの代わりに、書き込み要求を用いても良い。

図１５は本発明の一実施形態に係る電子時計１００の機能ブロック図である。電子時計１００は、ＢＬＥ通信モジュール１００１と、記憶モジュール１００２と、アドバタイズモジュール１００３と、コネクション制御モジュール１００４と、ＭＴＵ情報管理モジュール１００５と、データパケット生成モジュール１００６と、データパケット解析モジュール１００７と、アトリビュート読出モジュール１００８と、アトリビュート書込モジュール１００９とを含む。モジュール１００１乃至１００９は、バスによって相互接続される。また、モジュール１００１乃至１００９は、ソフトウェア、ハードウェア、又は、これらの組合せによって構成される。例えば、上記モジュールの少なくとも一部をＦＰＧＡとして具現することができる。

ＢＬＥ通信モジュール１００１は、他の装置（本実施形態では、スマートフォン２００）とのＢＬＥ通信を行い、他の装置に信号を送信したり、それから信号を受信したりすることができる。記憶モジュール１００２は、ＢＬＥ通信モジュール１００１が利用するネットワーク情報、ＭＴＵ情報、アトリビュートデータベース、データフォーマット等を記憶する。例えば、記憶モジュール１００２は、１つ以上のメモリで構成される。また、アトリビュートデータベースに格納されているフィーチャーの設定値の長さがそれぞれ異なる場合は、記憶モジュール１００２に、各フィーチャーの設定値の長さを記憶しておくことが好ましい。

アドバタイズモジュール１００３は、アドバタイジングパケットを生成し、生成されたアドバタイジングパケットを発信することでアドバタイズを行なう。アドバタイズモジュール１００３は、所定の条件を満たしたときにアドバタイズを開始する。コネクション制御モジュール１００４は、他の装置からコネクション要求が受信されれば当該装置とのコネクションを構築したり、他の装置との間で確立されたコネクションを切断するためのコネクション切断要求（Ｄｉｓｃｏｎｎｅｃｔ Ｒｅｑｕｅｓｔ）を生成して上記他の装置に送信したりする。

ＭＴＵ情報管理モジュール１００５は、他の装置とのＭＴＵサイズ交換手続きにより更新されたＡＴＴ＿ＭＴＵを取得し、これを記憶モジュール１００２に記憶されたアトリビュートデータベースのキャラクタリスティックＵｐｄａｔｅｄ ＡＴＴ＿ＭＴＵのキャラクタリスティック値として格納する。更新されたＡＴＴ＿ＭＴＵは、データタパケット生成モジュール１００６に伝達され、通知メッセージによって他の装置に通知される。

データパケット生成モジュール１００６は、電子時計１００と他の装置との間のコネクションが確立された後に、上記他の装置に送信するデータパケットを生成する。特に、他の装置から受信した送信指示用の指示コマンドから取得したデータフォーマットに基づいて、上記他の装置に送信するメッセージ（図９の例において、ハンドル値ノーティフィケーション１とハンドル値ノーティフィケーション２）を生成する。データパケット解析モジュール１００７は、他の装置から受信されたデータパケットを解析する。具体的に、データパケットのＰＤＵのタイプを判別し、ＰＤＵに格納されているデータを抽出する。特に、他の装置から受信した書込待機指示用の指示コマンドから取得したデータフォーマットに基づいて、上記他の装置からのメッセージ（図１３の例において、書き込みコマンド１と書き込みコマンド２）に含まれているデータを解析する。

アトリビュート読出モジュール１００８は、記憶モジュール１００２に記憶されているアトリビュートデータベースのアトリビュート値を読み出す。特に、他の装置から送信指示用の指示コマンドを受信した場合、アトリビュートデータベースのＷａｔｃｈ Ｆｅａｔｕｒｅｓ（図７）のアトリビュート値から上記他の装置が要求するフィーチャーの設定値を読み出す。アトリビュート書込モジュール１００９は、記憶モジュール１００２に記憶されているアトリビュートデータベースにアトリビュート値を書き込む。特に、他の装置から書込待機指示用の指示コマンドを受信した場合、それに続いて上記他の装置から受信されるデータを、アトリビュートデータベースのＷａｔｃｈ Ｆｅａｔｕｒｅｓのアトリビュート値に書き込む。これによって、アトリビュートデータベースに記憶されている対応するフィーチャーの設定値を、上記受信されたデータに更新する。

図１６は本発明の一実施形態に係るスマートフォン２００の機能ブロック図である。スマートフォン２００は、ＢＬＥ通信モジュール２００１と、記憶モジュール２００２と、スキャンモジュール２００３と、コネクション制御モジュール２００４と、データフォーマット決定モジュール２００５と、データパケット生成モジュール２００６と、データパケット解析モジュール２００７とを含む。データパケット生成モジュール２００６は、指示コマンド生成モジュール２００８を含む。モジュール２００１乃至２００８はバスによって相互接続される。また、モジュール２００１乃至２００８は、ソフトウェア、ハードウェア、又は、これらの組合せによって構成される。例えば、上記モジュールの少なくとも一部をＦＰＧＡとして具現することができる。

ＢＬＥ通信モジュール２００１は、他の装置（本実施形態では、電子時計１００）とのＢＬＥ通信を行い、他の装置に信号を送信したり、それから信号を受信したりすることができる。記憶モジュール２００２は、ＢＬＥ通信モジュール２００１が利用するネットワーク情報、ＭＴＵ情報、設定情報、データフォーマット等を記憶する。ＭＴＵ情報は、更新されたＡＴＴ＿ＭＴＵを含む。上記の実施形態において、更新されたＡＴＴ＿ＭＴＵは、他の装置から通知される。例えば、記憶モジュール２００２は、１つ以上のメモリで構成される。また、設定情報であるフィーチャーの設定値の長さがそれぞれ異なる場合は、記憶モジュール２００２に、各フィーチャーの設定値の長さを記憶しておくことが好ましい。

スキャンモジュール２００３は、所定の時間幅の間、アドバタイジングパケットをスキャンする。スキャンモジュール２００３は、所定の条件を満たしたときに、スキャンを開始する。また、スキャン期間中に受信されたアドバタイジングパケットを復号（デコーディング）して上記アドバタイジングパケットに格納されているデータを抽出する。コネクション制御モジュール２００４は、アドバタイジングパケットを発信する他の装置の中で適当な装置にコネクションを要求するためのコネクション要求を生成し、これを上記装置に送信する。また、コネクションが確立されている他の装置からコネクション切断要求が受信されれば、当該装置とのコネクションを切断する。

データフォーマット決定モジュール２００５は、記憶モジュール２００２に記憶されている更新されたＡＴＴ＿ＭＴＵに基づいてデータフォーマットを決定する。データフォーマット決定モジュール２００５は、図１２（Ａ）及び図１４（Ａ）に示されたように、他の装置と送受信する複数の種類の設定情報の長さから、更新されたＡＴＴ＿ＭＴＵに収まるように、データの順序、組み合わせ、区切り等を含むデータフォーマットを決定する。決定されたデータフォーマットは、指示コマンド生成モジュール２００８に伝達され、指示コマンドによって他の装置に通知される。上記他の装置は、通知されたデータフォーマットに基づいて、スマートフォン２００に送信するメッセージを生成したり、スマートフォン２００から受信したメッセージを解析したりする。

データパケット生成モジュール２００６は、スマートフォン２００と他の装置との間のコネクションが確立された後に上記他の装置に送信するデータパケットを生成する。データパケット生成モジュール２００６は、指示コマンド生成モジュール２００８を含む。指示コマンド生成モジュール２００８は、他の装置に送信する送信指示用の指示コマンド（例えば、図１２（Ａ））又は書込待機指示用の指示コマンド（例えば、図１４（Ａ））を生成する。指示コマンドのアトリビュート値には、コマンド種別（送信指示であるか書込待機指示であるか）と、コマンドデータ（データフォーマット決定モジュール２００５によって決定されたデータフォーマット）とが格納される。

データパケット解析モジュール２００７は、他の装置から受信されたデータパケットを解析する。具体的に、データパケットのＰＤＵのタイプを判別し、ＰＤＵに格納されているデータを抽出する。特に、送信指示用の指示コマンドに応答して他の装置が送信したメッセージに含まれているデータを、記憶モジュール２００２に記憶されているデータフォーマットに基づいて解析する。

図１７は、本発明の一実施形態に係る電子時計１００においての通信プロセスを実現するためのアルゴリズムを示すフローチャートである。本実施形態において、電子時計１００に実装されるアトリビュートデータベースは図７の構造を有する。また、電子時計１００がサーバとして動作し、スマートフォン２００がクライアントとして動作する。以下、図９乃至図１４を一緒に参照して、図１７を詳細に説明する。

電子時計１００は、アドバタイズを開始するための所定の条件が満たされたかどうかを判断する（ステップＳ２２０２）。上記所定の条件は、例えば、あらかじめ設定された時刻になったか、又は、ボタン操作があったか、等である。上記所定の条件が満たされていない場合（ステップＳ２２０２：Ｎｏ）、電子時計１００はアドバタイズを開始しない。上記所定の条件が満たされた場合（ステップＳ２２０２：Ｙｅｓ）、アドバタイズ時間を計測するためのタイマを開始し（ステップＳ２２０４）、アドバタイズを開始する（ステップＳ２２０６）。

続いて、タイマの時間が所定の時間Ｔａ（アドバタイズ時間幅）に達したかどうかを判断する（ステップＳ２２０８）。タイマの時間がＴａに達していない場合、即ち、タイムアウトが起きていない場合は（ステップＳ２２０８：Ｎｏ）、プロセスはステップ２２１２へ移る。タイマの時間がＴａに達した場合、即ち、タイムアウトが起きた場合は（ステップＳ２２０８：Ｙｅｓ）、アドバタイズを停止し（ステップＳ２２１０）、プロセスはステップＳ２２０２に戻る。ステップ２２１２において、電子時計１００は、スマートフォン２００からコネクション要求が受信されたかどうかを判断する。コネクション要求が受信されていない場合（ステップＳ２２１２：Ｎｏ）、プロセスはステップＳ２２０８に戻る。コネクション要求が受信された場合（ステップＳ２２１２：Ｙｅｓ）、アドバタイズを停止し、タイマの時間計測を停止する（ステップＳ２２１４）。図１７でサービスディスカバリーの工程は省略する。

次に、電子時計１００は、スマートフォン２００から最大受信ＭＴＵサイズを知らせるＭＴＵサイズ交換要求を受信する（ステップＳ２２１６）。それに対する返信として、電子時計１００は、最大受信ＭＴＵサイズを知らせるためのＭＴＵサイズ交換応答をスマートフォン２００に送信する（ステップＳ２２１８）。電子時計１００は、両方のＭＴＵサイズの最小値を更新されたＡＴＴ＿ＭＴＵとして取得し、更新されたＡＴＴ＿ＭＴＵをスマートフォン２００に通知する（ステップＳ２２２０）。具体的に、更新されたＡＴＴ＿ＭＴＵをアトリビュートデータベースのＵｐｄａｔｅｄ ＡＴＴ＿ＭＴＵのアトリビュート値として格納し、このアトリビュート値をノーティフィケーションメッセージによりスマートフォン２００に通知する。

電子時計１００は、アトリビュートハンドルパラメータが、Ｒｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルに設定された書き込みコマンドが受信されたかどうかを判断する（ステップＳ２２２２）。上記書き込みコマンドを受信した場合（ステップＳ２２２２：Ｙｅｓ）、このメッセージを指示コマンドと判断する。また、当該メッセージのアトリビュート値として格納されているコマンド種別と、コマンドデータであるデータフォーマットとをアトリビュートデータベースのＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値に書き込む。コマンド種別を確認して（ステップＳ２２２４）、コマンド種別が０ｘ００（送信指示）である場合は、プロセスがステップＳ２２２６へ移り、コマンド種別が０ｘ０１（書込待機指示）である場合は、プロセスがステップＳ２２３２へ移る。

コマンド種別が０ｘ００である場合、電子時計１００は、指示コマンド（送信指示）に従って、スマートフォン２００が要求するフィーチャーの設定値を通知するメッセージを準備する（ステップＳ２２２６）。具体的に、上記指示コマンドから取得したデータフォーマットのデータの順序、組み合わせ、区切り等に基づいて、必要な個数のノーティフィケーションメッセージを生成する。図１２（Ａ）及び（Ｂ）の例では、フィーチャー１とフィーチャー２の設定値を含むハンドル値ノーティフィケーション１を生成してスマートフォン２００に送信し（ステップＳ２２２８）、フィーチャー３とフィーチャー４の設定値を含むハンドル値ノーティフィケーション２を生成して送信する（ステップＳ２２３０）。これによって、プロセスが終了する。

コマンド種別が０ｘ０１である場合、電子時計１００は、指示コマンド（書込待機指示）に従って、データ書込みを指示する書き込みコマンドの受信を待機する（ステップＳ２２３２）。図１４（Ａ）及び（Ｂ）の例では、スマートフォン２００が書き込みたいフィーチャー１とフィーチャー２の設定値を含む書き込みコマンド１を受信し（ステップＳ２２３４）、フィーチャー３とフィーチャー４の設定値を含む書き込みコマンド２を受信する（ステップＳ２２３６）。電子時計１００は、指示コマンドから取得したデータフォーマットのデータの順序、組み合わせ、区切り等に基づいて、スマートフォン２００から受信した書き込みコマンド１と書き込みコマンド２とのデータを解析し、フィーチャー１からフィーチャー４の設定値を書き込む（ステップＳ２２３８）。これによって、プロセスが終了する。

図１８及び図１９は、本発明の一実施形態に係るスマートフォン２００においての通信プロセスを実現するためのアルゴリズムを示すフローチャートである。図１８は、スマートフォン２００が電子時計１００にデータの送信を指示するプロセスを示めす。以下、図９乃至図１２を参照して、図１８を詳細に説明する。スマートフォン２００は、スキャン時間を計測するためのタイマを開始し（ステップＳ２３０２）、スキャンを開始する（ステップＳ２３０４）。上述のように、スマートフォン２００は、周期的に、又は、所定の条件が満たされたときに（例えば、所定の時刻になったときに、又は、ボタン操作があったときに）、スキャンを行なう。

スマートフォン２００は、タイマの時間が所定の時間Ｔｓ（スキャン時間幅）に達したかどうかを判断する（ステップＳ２３０６）。タイマの時間がＴｓに達していない場合、即ち、タイムアウトが起きていない場合は（ステップＳ２３０６：Ｎｏ）、プロセスはステップ２３１０へ移る。タイマの時間がＴｓに達した場合、即ち、タイムアウトが起きた場合は（ステップＳ２３０６：Ｙｅｓ）、スキャンを停止する（ステップＳ２３０８）。ステップ２３１０において、スマートフォン２００のホストはコントローラからアドバタイジングレポートを受け取る。続いて、スマートフォン２００は、電子時計１００からＡＤＶ＿ＩＮＤタイプのアドバタイジングパケットが受信されたかどうかを判断する（ステップＳ２３１２）。ＡＤＶ＿ＩＮＤタイプのアドバタイジングパケットが受信されていない場合（ステップＳ２３１２：Ｎｏ）、プロセスはステップＳ２３０６に戻る。ＡＤＶ＿ＩＮＤタイプのアドバタイジングパケットが受信された場合（ステップＳ２３１２：Ｙｅｓ）、スマートフォン２００は、スキャンを停止し、タイマの時間計測を停止する（ステップＳ２３１４）。次に、電子時計１００にコネクション要求を送信する（ステップＳ２３１６）。図１８でもサービスディスカバリーの工程は省略する。

上記の過程によって、２つの装置間のコネクションが確立されると、スマートフォン２００は、最大受信ＭＴＵサイズを知らせるためのＭＴＵサイズ交換要求を電子時計１００に送信し（ステップＳ２３１８）、電子時計１００から、最大受信ＭＴＵサイズを知らせるＭＴＵサイズ交換応答を受信する（ステップＳ２３２０）。次に、電子時計１００から、アトリビュート値パラメータが、更新されたＡＴＴ＿ＭＴＵ（即ち、Ｕｐｄａｔｅｄ ＡＴＴ＿ＭＴＵのキャラクタリスティック値）に設定されたノーティフィケーションメッセージを受信する（ステップＳ２３２２）。

スマートフォン２００は、受信したノーティフィケーションメッセージから取得されたＡＴＴ＿ＭＴＵに基づいて、送信指示用の指示コマンドである書き込みコマンドを作成する（ステップＳ２３２４）。具体的に、スマートフォン２００は、取得したい複数の種類の設定情報の長さから、上記更新されたＡＴＴ＿ＭＴＵに収まるように、データの順序、組み合わせ、区切り等を含むデータのフォーマットを決定する。上記書き込みコマンド（指示コマンド）のアトリビュートハンドルパラメータはＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルに設定され、アトリビュート値パラメータは、コマンド種別である０ｘ００（送信指示）と、それに続くデータのフォーマットとで構成される（図１２（Ａ）を参照）。そして、上記書き込みコマンドを、電子時計１００に送信する（ステップＳ２３２６）。

次に、電子時計１００から、上記指示コマンドによって要求した設定情報を通知するメッセージを受信する。図１２（Ａ）及び（Ｂ）の例では、フィーチャー１とフィーチャー２の設定値を含むハンドル値ノーティフィケーション１を受信し（ステップＳ２３２８）、フィーチャー３とフィーチャー４の設定値を含むハンドル値ノーティフィケーション２を受信する（ステップＳ２３３０）。スマートフォン２００は、受信したメッセージを、上記データフォーマットに基づいて、解析し処理する（ステップＳ２３３２）。具体的に、受信した各々のハンドル値ノーティフィケーションのアトリビュート値に格納されているデータを、上記データフォーマットの順序に結合されたデータとして解釈し、４つのフィーチャーの設定情報を取得してメモリ（例えば、図２（Ｂ）の２０８）に格納する。これによって、プロセスが終了する。

図１９は、本発明の一実施形態に係るスマートフォン２００において電子時計１００にデータの書込みを指示する通信プロセスを実現するためのアルゴリズムを示すフローチャートである。以下、図１０乃至図１４を一緒に参照して、図１９を詳細に説明する。図１９において、図１８と同一の処理内容には同一の符号を付して詳細な説明を省略する。

スマートフォン２００は、ステップＳ２３２２において受信したノーティフィケーションメッセージから取得されたＡＴＴ＿ＭＴＵに基づいて、書込待機指示用の指示コマンドである書き込みコマンドを作成する（ステップＳ２４２４）。具体的に、スマートフォン２００は、書き込みたい複数の種類の設定情報の長さから、上記更新されたＡＴＴ＿ＭＴＵに収まるように、データの順序、組み合わせ、区切り等を含むデータのフォーマットを決定する。上記書き込みコマンド（指示コマンド）のＡｔｔｒｉｂｕｔｅ ＨａｎｄｌｅパラメータはＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルに設定され、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅパラメータは、コマンド種別である０ｘ０１（書込待機指示）と、それに続くデータのフォーマットとで構成される（図１４（Ａ）を参照）。そして、上記書き込みコマンドを、電子時計１００に送信する（ステップＳ２４２６）。

次に、設定情報の書込みを指示するメッセージである書き込みコマンドを生成して、電子時計１００に送信する。当該書き込みコマンドは、アトリビュートハンドルパラメータと、アトリビュート値パラメータとのそれぞれが、Ｗａｔｃｈ Ｆｅａｔｕｒｅｓのキャラクタリスティック値ハンドルと、書き込みたい設定情報とに設定される。図１４（Ａ）及び（Ｂ）の例では、フィーチャー１とフィーチャー２の設定値を順に格納した書き込みコマンド１を送信し（ステップＳ２４２８）、フィーチャー３とフィーチャー４の設定値を順に格納した書き込みコマンド２を送信する（ステップＳ２４３０）。これによって、プロセスが終了する。

図１７乃至図１９において、書き込みコマンドとハンドル値ノーティフィケーションとのそれぞれは、書き込み要求とハンドル値インディケーションとに切り替えることができる。図１７乃至図１９に示された実施形態によると、ＭＴＵサイズを最大限に生かすようにデータをまとめて送受信するために、クライアントであるスマートフォン２００がサーバである電子時計１００に指示コマンドを送信してデータのトランザクションを抑制する。データをまとめて送受信することで、通信量（回数）を削減し、消費電力を抑制できる。

＜第２の実施形態＞
上記の実施形態では、スマートフォン２００の制約により、接続時にＭＴＵサイズ交換が必ず実行されることと、ホストがＭＴＵサイズ交換の結果として更新されたＡＴＴ＿ＭＴＵをコントローラから受け取る手段がないことを想定した。その制約がない場合には、図２０に示すように、必要なときのみにＭＴＵサイズ交換を実行する。

図２０は、本発明の一実施形態に係るスマートフォン２００においての通信プロセスを実現するためのアルゴリズムを示すフローチャートである。図２０は、スマートフォン２００が、電子時計１００にデータの送信を指示するプロセスを示めす。図２０において、図１８と同一の処理内容には同一の符号を付して、説明を省略する。

２つの装置間のコネクションが確立されると、スマートフォン２００は、要求するデータの合計サイズＭを算出する（ステップＳ２５１８）。そして、ＭがデフォルトＡＴＴ＿ＭＴＵ−３、即ち２０オクテットに収まるかどうかを判断する（ステップＳ２５２０）。Ｍが２０オクテットを超える場合は（ステップＳ２５２０：Ｎｏ）、ステップＳ２５３２へ移る。Ｍが２０オクテットを超えない場合は（ステップＳ２５２０：Ｙｅｓ）、送信指示用の指示コマンドである書き込みコマンドを作成して（ステップＳ２３２４）、電子時計１００に送信する（ステップＳ２３２６）。

その後、２つのノーティフィケーションメッセージを受信するが（Ｓ２３２８，Ｓ２３３０）、メッセージの個数、即ち、データの区切りは、ＡＴＴ＿ＭＴＵ、サイズＭ、データの種類の数、等に応じて決まることができる。スマートフォン２００は、受信したメッセージを、上記データフォーマットに基づいて、解析し処理する（ステップＳ２５３０）。具体的に、受信した各々のハンドル値ノーティフィケーションのアトリビュート値に格納されているデータを、上記データフォーマットの順序に結合されたデータとして解釈し、設定情報を取得してメモリ（例えば、図２（Ｂ）の２０８）に格納する。これによって、プロセスが終了する。

一方、Ｍが２０オクテットを超える場合は（ステップＳ２５２０：Ｎｏ）、ステップＳ２５３２へ移ってＭＴＵサイズ交換を実施する。スマートフォン２００は、最大受信ＭＴＵサイズを知らせるためのＭＴＵサイズ交換要求を電子時計１００に送信し（ステップＳ２５３２）、電子時計１００から、最大受信ＭＴＵサイズを知らせるＭＴＵサイズ交換応答を受信する（ステップＳ２５３４）。次に、自分の最大受信ＭＴＵサイズと、電子時計１００の最大受信ＭＴＵとを比較して、その最小値を更新されたＡＴＴ＿ＭＴＵとして取得する（ステップＳ２５３６）。

本実施形態によると、ＭＴＵサイズ交換に関連するデータのトランザクションを更に削減することが可能になる。

＜第３の実施形態＞
図２１は本発明の他の実施形態に係るアトリビュートデータベースの一例を示す。図７のアトリビュートデータベースは、電子時計１００がデータを送受信するフォーマットを指定する指示コマンドを書込むための１つキャラクタリスティックであるＲｅｑｕｅｓｔ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓを含む。これに対し、図２１の実施形態では、データ送信用のフォーマットを書き込むためのキャラクタリスティックであるＲｅａｄ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓと、データ書込用のフォーマットを書き込むためのキャラクタリスティックであるＷｒｉｔｅ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓとを含む。また、本実施形態では、図１０で説明したコマンド種別を用いない。その代わり、スマートフォン２００が電子時計１００にフィーチャーの設定値を送信するように指示する場合は、送信指示用の指示コマンドとして、アトリビュートハンドルパラメータとアトリビュート値パラメータとのそれぞれが、Ｒｅａｄ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値のハンドル（０ｘ００１２）と、送信するデータのフォーマットとに設定された書き込みコマンドを送信する。スマートフォン２００が電子時計１００にフィーチャーの設定値の書込みを待機するように指示する場合は、書込待機指示用の指示コマンドとして、アトリビュートハンドルパラメータとアトリビュート値パラメータとのそれぞれが、Ｗｒｉｔｅ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値のハンドル（０ｘ００１７）と、書き込むデータのフォーマットとに設定された書き込みコマンドを送信する。

電子時計１００は、アトリビュートハンドルパラメータが、Ｒｅａｄ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値のハンドルに設定された書き込みコマンドを受信すれば、この書き込みコマンドを送信指示用の指示コマンドと判断し、アトリビュート値パラメータであるデータフォーマットをＲｅａｄ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値として格納する。そして、このデータフォーマットに基づいて、スマートフォン２００に送信するメッセージを生成する。

電子時計１００は、アトリビュートハンドルパラメータが、Ｗｒｉｔｅ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値のハンドルに設定された書き込みコマンドを受信すれば、この書き込みコマンドを書込待機指示用の指示コマンドと判断し、アトリビュート値パラメータであるデータフォーマットをＷｒｉｔｅ Ｃｏｍｍａｎｄ ｆｏｒ Ｆｅａｔｕｒｅｓのキャラクタリスティック値として格納する。そして、このデータフォーマットに基づいて、スマートフォン２００から受信されるメッセージを解析する。

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

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

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

（付記１）
通信パケットを他の通信装置と送受信する通信部と、
プロセッサと、
を備え、
前記プロセッサは、前記通信部を介して前記他の通信装置から、データのパッケージ方法を示す第１の情報を含むパケットを受信し、前記第１の情報に対応するデータを前記通信部を介して前記他の通信装置と通信することを特徴とする通信装置。
（付記２）
前記プロセッサは、前記通信部を介して前記他の通信装置から通信制御に関する第２の情報を受信し、受信した前記第２の情報に基づいて前記通信部を制御することを特徴とする付記１に記載の通信装置。
（付記３）
前記第２の情報が第１の値を有する場合は、前記プロセッサが、前記第１の情報に基づいて、前記他の通信装置に送信する一つ以上のパケットを生成し、
前記第２の情報が前記第１の値と異なる第２の値を有する場合は、前記通信部が、前記他の通信装置からのパケットの受信を待機することを特徴とする付記２に記載の通信装置。
（付記４）
メモリを備え、
前記プロセッサは、
前記第２の情報が前記第２の値を有する場合に、前記第１の情報に基づいて、前記他の通信装置から受信された所定の個数のパケットに含まれているデータを、前記メモリに記憶させることを特徴とする付記２又は３に記載の通信装置。
（付記５）
前記メモリは、複数のフィーチャーを区別する区別情報と、それぞれのフィーチャーの設定値を記憶し、
前記プロセッサは、
前記第２の情報が前記第１の値を有する場合に、各々が一つ以上のフィーチャーの設定値を含む所定の個数のパケットを生成し、
前記第２の情報が前記第２の値を有する場合に、前記第１の情報に基づいて、前記他の通信装置から受信された所定の個数のパケットを解析することを特徴とする付記３又は４に記載の通信装置。
（付記６）
前記第１の情報は、一つ以上の区別情報を含むことを特徴とする付記５に記載の通信装置。
（付記７）
前記第１の情報は、複数の区別情報と、区切り情報とを含み、
前記区切り情報は、一つのパケットで通信するデータと、他のパケットで通信するデータとを区分することを示すことを特徴とする付記５に記載の通信装置。
（付記８）
前記他の通信装置と通信するパケットの数は、前記第１の情報における前記区切り情報と前記区別情報との配置に基づいて決まることを特徴とする付記７に記載の通信装置。
（付記９）
前記プロセッサは、前記第２の情報が前記第１の値を有する場合に、前記第１の情報に含まれている複数の区別情報の順に、前記複数の区別情報に対応する複数のフィーチャーの設定値を含む所定の個数のパケットを生成することを特徴とする付記６乃至８の何れか１つに記載の通信装置。
（付記１０）
前記プロセッサは、前記第２の情報が前記第２の値を有する場合に、前記第１の情報に含まれている複数の区別情報の順に、前記他の通信装置から受信された所定の個数のパケットに含まれているデータを、前記複数の区別情報に対応する複数のフィーチャーの設定値として、前記メモリに記憶させることを特徴とする付記６乃至９の何れか１つに記載の通信装置。
（付記１１）
前記メモリは、前記複数のフィーチャーの設定値のそれぞれの長さを示す長さ情報を記憶することを特徴とする付記５乃至１０の何れか１つに記載の通信装置。
（付記１２）
前記プロセッサは、前記第２の情報が前記第１の値を有する場合、前記第１の情報と、前記長さ情報とに基づいて、所定の個数のパケットを生成し、
前記所定の個数のパケットのそれぞれは、一つ以上のフィーチャーの設定値を含むことを特徴とする付記１１に記載の通信装置。
（付記１３）
前記プロセッサは、前記第２の情報が前記第２の値を有する場合、前記第１の情報と、前記長さ情報に基づいて、前記他の通信装置から受信された所定の個数のパケットを解析することを特徴とする付記１１又は１２に記載の通信装置。
（付記１４）
前記メモリは、前記通信装置の最大受信ＭＴＵサイズを記憶し、
前記プロセッサは、前記通信部を介して前記他の通信装置の最大受信ＭＴＵサイズを取得した場合、前記他の装置の最大受信ＭＴＵサイズと、前記通信装置の最大受信ＭＴＵサイズとを比較して、その最小値を含むパケットを生成することを特徴とする付記４乃至１３の何れか１つに記載の通信装置。
（付記１５）
前記第２の情報によって前記他の通信装置に送信するパケットを生成するように指示された場合に、前記プロセッサによって生成されるそれぞれのパケットに含まれるデータの総サイズは、前記最小値から３を引いた値を越えないことを特徴とする付記１４に記載の通信装置。
（付記１６）
付記１乃至１５の何れか１つに記載の通信装置と、
現在の日時を計数する計時部と、
前記計時部が計数した前記日時を表示する表示部と、
を備えることを特徴とする電子時計。
（付記１７）
無線通信のできる装置であって、
他の通信装置と通信パケットを送受信する通信部と、
プロセッサと、
を備え、
前記プロセッサは、他の通信装置の単位通信当たり通信可能のデータサイズに基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めることを特徴とする通信装置。
（付記１８）
無線通信のできる装置の通信方法であって、
他の通信装置から、データのパッケージ方法を示すパッケージ方法情報を含むパケットを受信するステップと、
前記パケットから、前記第パッケージ方法情報を抽出するステップと、
前記パッケージ方法情報に対応するデータを通信するステップと、
を備えることを特徴とする通信方法。
（付記１９）
無線通信のできる装置の通信方法であって、
他の通信装置から単位通信当たり通信可能のデータサイズを示すサイズ情報を受信するステップと、
前記サイズ情報に基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めるステップと、
前記パッケージ方法を示すフォーマット情報を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を備えることを特徴とする通信方法。
（付記２０）
無線通信のできる装置に、
他の通信装置から、データのパッケージ方法を示すパッケージ方法情報を含むパケットを受信するステップと、
前記パケットから、前記パッケージ方法情報を抽出するステップと、
前記パッケージ方法情報に対応するデータを通信するステップと、
を実行させるプログラム。
（付記２１）
無線通信のできる装置に、
他の通信装置から単位通信当たり通信可能のデータサイズを示すサイズ情報を受信するステップと、
前記サイズ情報に基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めるステップと、
前記パッケージ方法を示すフォーマット情報を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を実行させるプログラム。

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

Claims (21)

1. 通信パケットを他の通信装置と送受信する通信部と、
   プロセッサと、
   を備え、
   前記プロセッサは、前記通信部を介して前記他の通信装置から、データのパッケージ方法を示す第１の情報を含むパケットを受信し、前記第１の情報に対応するデータを前記通信部を介して前記他の通信装置と通信することを特徴とする通信装置。
2. 前記プロセッサは、前記通信部を介して前記他の通信装置から通信制御に関する第２の情報を受信し、受信した前記第２の情報に基づいて前記通信部を制御することを特徴とする請求項１に記載の通信装置。
3. 前記第２の情報が第１の値を有する場合は、前記プロセッサが、前記第１の情報に基づいて、前記他の通信装置に送信する一つ以上のパケットを生成し、
   前記第２の情報が前記第１の値と異なる第２の値を有する場合は、前記通信部が、前記他の通信装置からのパケットの受信を待機することを特徴とする請求項２に記載の通信装置。
4. メモリを備え、
   前記プロセッサは、
   前記第２の情報が前記第２の値を有する場合に、前記第１の情報に基づいて、前記他の通信装置から受信された所定の個数のパケットに含まれているデータを、前記メモリに記憶させることを特徴とする請求項２又は３に記載の通信装置。
5. 前記メモリは、複数のフィーチャーを区別する区別情報と、それぞれのフィーチャーの設定値を記憶し、
   前記プロセッサは、
   前記第２の情報が前記第１の値を有する場合に、各々が一つ以上のフィーチャーの設定値を含む所定の個数のパケットを生成し、
   前記第２の情報が前記第２の値を有する場合に、前記第１の情報に基づいて、前記他の通信装置から受信された所定の個数のパケットを解析することを特徴とする請求項３又は４に記載の通信装置。
6. 前記第１の情報は、一つ以上の区別情報を含むことを特徴とする請求項５に記載の通信装置。
7. 前記第１の情報は、複数の区別情報と、区切り情報とを含み、
   前記区切り情報は、一つのパケットで通信するデータと、他のパケットで通信するデータとを区分することを示すことを特徴とする請求項５に記載の通信装置。
8. 前記他の通信装置と通信するパケットの数は、前記第１の情報における前記区切り情報と前記区別情報との配置に基づいて決まることを特徴とする請求項７に記載の通信装置。
9. 前記プロセッサは、前記第２の情報が前記第１の値を有する場合に、前記第１の情報に含まれている複数の区別情報の順に、前記複数の区別情報に対応する複数のフィーチャーの設定値を含む所定の個数のパケットを生成することを特徴とする請求項６乃至８の何れか１項に記載の通信装置。
10. 前記プロセッサは、前記第２の情報が前記第２の値を有する場合に、前記第１の情報に含まれている複数の区別情報の順に、前記他の通信装置から受信された所定の個数のパケットに含まれているデータを、前記複数の区別情報に対応する複数のフィーチャーの設定値として、前記メモリに記憶させることを特徴とする請求項６乃至９の何れか１項に記載の通信装置。
11. 前記メモリは、前記複数のフィーチャーの設定値のそれぞれの長さを示す長さ情報を記憶することを特徴とする請求項５乃至１０の何れか１項に記載の通信装置。
12. 前記プロセッサは、前記第２の情報が前記第１の値を有する場合、前記第１の情報と、前記長さ情報とに基づいて、所定の個数のパケットを生成し、
    前記所定の個数のパケットのそれぞれは、一つ以上のフィーチャーの設定値を含むことを特徴とする請求項１１に記載の通信装置。
13. 前記プロセッサは、前記第２の情報が前記第２の値を有する場合、前記第１の情報と、前記長さ情報に基づいて、前記他の通信装置から受信された所定の個数のパケットを解析することを特徴とする請求項１１又は１２に記載の通信装置。
14. 前記メモリは、前記通信装置の最大受信ＭＴＵサイズを記憶し、
    前記プロセッサは、前記通信部を介して前記他の通信装置の最大受信ＭＴＵサイズを取得した場合、前記他の装置の最大受信ＭＴＵサイズと、前記通信装置の最大受信ＭＴＵサイズとを比較して、その最小値を含むパケットを生成することを特徴とする請求項４乃至１３の何れか１項に記載の通信装置。
15. 前記第２の情報によって前記他の通信装置に送信するパケットを生成するように指示された場合に、前記プロセッサによって生成されるそれぞれのパケットに含まれるデータの総サイズは、前記最小値から３を引いた値を越えないことを特徴とする請求項１４に記載の通信装置。
16. 請求項１乃至１５の何れか１項に記載の通信装置と、
    現在の日時を計数する計時部と、
    前記計時部が計数した前記日時を表示する表示部と、
    を備えることを特徴とする電子時計。
17. 無線通信のできる装置であって、
    他の通信装置と通信パケットを送受信する通信部と、
    プロセッサと、
    を備え、
    前記プロセッサは、他の通信装置の単位通信当たり通信可能のデータサイズに基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めることを特徴とする通信装置。
18. 無線通信のできる装置の通信方法であって、
    他の通信装置から、データのパッケージ方法を示すパッケージ方法情報を含むパケットを受信するステップと、
    前記パケットから、前記パッケージ方法情報を抽出するステップと、
    前記パッケージ方法情報に対応するデータを通信するステップと、
    を備えることを特徴とする通信方法。
19. 無線通信のできる装置の通信方法であって、
    他の通信装置から単位通信当たり通信可能のデータサイズを示すサイズ情報を受信するステップと、
    前記サイズ情報に基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めるステップと、
    前記パッケージ方法を示すフォーマット情報を含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を備えることを特徴とする通信方法。
20. 無線通信のできる装置に、
    他の通信装置から、データのパッケージ方法を示すパッケージ方法情報を含むパケットを受信するステップと、
    前記パケットから、前記パッケージ方法情報を抽出するステップと、
    前記パッケージ方法情報に対応するデータを通信するステップと、
    を実行させるプログラム。
21. 無線通信のできる装置に、
    他の通信装置から単位通信当たり通信可能のデータサイズを示すサイズ情報を受信するステップと、
    前記サイズ情報に基づいて、前記他の通信装置と通信する一つ以上の種類のデータのパッケージ方法を決めるステップと、
    前記パッケージ方法を示すフォーマット情報を含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を実行させるプログラム。

Images