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

Abstract

【課題】無線通信装置の間のコネクションプロセスを改善する方法、この方法を実行する通信装置及びプログラムを提供することにある。【解決手段】無線通信のできる装置は、通信パケットを他の通信装置と送受信する通信部と、サービスを構成するデータ要求のための機能及びデータ通信のための機能の参照情報と、上記参照情報の上記機能に関連するデータと、上記データを区別するための区別情報と、を記憶するメモリと、プロセッサと、を備える。上記プロセッサは、データ通信のための機能に関連付けられた参照情報と、上記データと、上記区別情報と、を含むパケットを生成する。【選択図】図１５

Description

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

従来、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ：登録商標）などの近距離無線通信を用いて種々の情報をやり取りすることが可能な電子装置が存在する。ブルートゥースは、近距離で各種装置を無線で連結してデータをやり取りすることができる近距離無線通信規約である。ブルートゥース通信方法には、ＢＲ／ＥＤＲ（Ｂａｓｉｃ Ｒａｔｅ／Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅ）と、低電力方式であるＬＥ（Ｌｏｗ Ｅｎｅｒｇｙ）とがある。ブルートゥース４．０から適用されたブルートゥースローエネルギー（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ、以下ＢＬＥと称する。）は、少ない電力を消耗して数百キロバイト（ＫＢ）の情報を安定的に提供することができる。

ブルートゥース装置は周辺のブルートゥース装置に対する検索／選択／認証（ペアリング）等の過程を経て無線通信を行うことができる。ブルートゥース規格は、汎用アトリビュートプロファイル（ｇｅｎｅｒｉｃ ａｔｔｒｉｂｕｔｅ ｐｒｏｆｉｌｅ：ＧＡＴＴ）を含み、ＧＡＴＴはブルートゥース装置で実行されるアプリケーションが利用可能なサービスを発見し、上記サービスのキャラクタリスティック（ｃｈａｒａｃｔｅｒｉｓｔｉｃ）がわかるようにするサービスディスカバリープロトコル（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｐｒｏｔｏｃｏｌ：ＳＤＰ）を含む。従来、キャラクタリスティックとは、サービスを構成する単一データ配列であり、キャラクタリスティック値は特定の機能の設定値を示す。１つの機能に対して１つのキャラクタリスティックを有するようにサービスが構成される。従って、１つのサービスに含まれるキャラクタリスティックの個数は、当該サービスによって提供される設定値の種類の個数と同一である。ＳＤＰに関する情報は、ブルートゥースサービスディスカバリープロファイルに含まれる。ＳＤＰは連結されたブルートゥース装置においてどんなサービスが可能であるかに関する情報と、その可能なサービスの特徴に関する情報とを交換するためのプロトコルである。例えば、ＳＤＰを通じて様々なデジタル機器に装着されたブルートゥースデバイスが、ＬＡＮアクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ）、携帯電話、ファクシミリ、プリンター等のサービスを提供することができるかどうかに関する情報を交換する。また、ＳＤＰはサーバークライアントの構造を有している。サーバー装置は可能なサービスの目録と各サービスについての細部事項をデータベースとして持っている。クライアントはサーバーに要請してサービスに関する情報を得ることができる。

例えば、特開２００９−１４３００５号公報には、サービスディスカバリープロファイルに規定されている検索方式によって通信装置を検索する技術が開示されている。

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

上記特許文献１に開示された技術によると、装置及びサービスの検索のために装置間のコネクション手続きに長い時間がかかり、ネットワークの電力消耗が大きいという問題がある。

この発明の目的は、無線通信装置の間のコネクションプロセスを改善する方法、この方法を実行する通信装置、電子時計、及びプログラムを提供することにある。

本発明の１つの態様は、無線通信のできる装置であって、通信パケットを他の通信装置と送受信する通信部と、サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報と、上記参照情報の上記機能に関連するデータと、上記データを区別するための区別情報と、を記憶するメモリと、プロセッサと、を備え、上記プロセッサは、前記データ通信のための機能に関連付けられた参照情報と、上記データと、上記区別情報と、を含むパケットを生成する。

また、本発明の他の１つの態様は、無線通信のできる装置であって、他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を受信し、通信パケットを他の通信装置と送受信する通信部と、一つ又はそれ以上のデータの区別情報を記憶するメモリと、プロセッサと、を備え、上記プロセッサは、第１の機能の参照情報と、一つのデータの区別情報と、を含むパケットを生成する。

本発明によると、無線通信装置の間のコネクションプロセスを改善することができる。
しかし、本発明の目的と効果は上記のものに制限されないし、下記の詳細な説明と添付の図面から本発明の他の目的と効果を理解することができる。

以下の詳細な記述が以下の図面と合わせて考慮されると、本願のより深い理解が得られる。これらの図面は例示に過ぎず、本発明の範囲を限定するものではない。
本明細書において提案された方法を適用することができる無線通信システムの一例を示す図である。 本明細書において提案された方法を具現することができる装置の内部ブロック図である。 本明細書において提案された方法を適用することができるＢＬＥ通信アーキテクチャーの一例を示す図である。 典型的なサービスディスカバリーメカニズムを示す図である。 ＧＡＴＴサーバーに格納されるアトリビュート（Ａｔｔｒｉｂｕｔｅ）の通常の構造の一例を示す。 （Ａ）はＢＬＥプロトコルによって定義されるパケット構造を示し、（Ｂ）はアトリビュート値をやり取りするためのアトリビュートプロトコルＰＤＵの構造の一例を示す。 アトリビュートプロトコルＰＤＵのアトリビュートオペコード（Ａｔｔｒｉｂｕｔｅ Ｏｐｃｏｄｅ）及びパラメーターのリストの一例を示すテーブルである。 通常のＢＬＥ装置のサービス構造の一例を示す図である。 本発明の一実施形態に係るサービス構造の一例を示す図である。 本発明の一実施形態に係るクライアントからサーバーに対してデータを要求する方法を、従来の方法と共に示す図である。 本発明の一実施形態に係るＷｒｉｔｅ Ｒｅｑｕｅｓｔ（書込み要求）メッセージによってデータを書き込む方法を、従来の方法と共に示す図である。 本発明の一実施形態に係るＷｒｉｔｅ Ｃｏｍｍａｎｄ（書込み命令）メッセージによってデータを書き込む方法を、従来の方法と共に示す図である。 本発明の一実施形態に係るサーバーからクライアントへ告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージを送信する方法を、従来の方法と共に示す図である。 本発明の一実施形態に係るサーバーからクライアントへ指示（Ｉｎｄｉｃａｔｉｏｎ）メッセージを送信する方法を、従来の方法と共に示す図である。 本発明の一実施形態に係るデータ要求プロセスを示す例示的なフローチャートである。 本発明の一実施形態に係るデータ書込みプロセスを示す例示的なフローチャートである。 本発明の一実施形態に係るデータ通知プロセスを示す例示的なフローチャートである。 本発明の他の実施形態に係るデータ通信方法を示す図である。 本発明の他の実施形態に係るデータ通信方法を示す図である。 本発明の他の実施形態に係るデータ通信方法を示す図である。 本発明の他の実施形態に係るデータ通信方法を示す図である。 本発明の他の実施形態に係るデータ通信方法を示す図である。 本発明の一部実施形態の構成及び特徴を要約したテーブルである。

本明細書においては、主に本発明をブルートゥース（登録商標）、特に、ＢＬＥに適用した実施形態について説明するが、本発明の適用分野はブルートゥースに限定されない。本発明は、サービスとキャラクタリスティックの概念を用いる他の無線通信技術にも適用可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常のブルートゥースサービスディスカバリーメカニズムにおいて、サービス検索命令はＢＬＥプロトコルとして規格化されているが、検索方法や検索順序はＯＳによって違う。サービスディスカバリープロセスは時間をかなり消費するプロセスであり、多数の装置が互いに近接している場合望ましくない遅延をもたらすことができる。

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

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

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

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

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

図８は通常のＢＬＥ装置のサービス構造（即ち、アトリビュートデータベース）の一例を示す。図８のサービス構造を有するＢＬＥ装置は電子時計である。それぞれのサービスはデータを論理的に分ける役割を行い、一つ又はそれ以上のキャラクタリスティックを含む。示されたように、プライマリーサービスであるＷａｔｃｈ Ｓｅｒｖｉｃｅは、複数のキャラクタリスティック（ＳｅｒｖｉｃｅＮ１、ＳｅｒｖｉｃｅＮ２、．．．、ＳｅｒｖｉｃｅＮｘ）を含む。本例において、Ｗａｔｃｈ Ｓｅｒｖｉｃｅは、ｘ個のキャラクタリスティックを含む。上記複数のキャラクタリスティックは、例えば、ＢＬＥ仕様設定、ＢＬＥ時計設定、等を含む。それぞれのサービスはＵＵＩＤ、即ち、１６ビット又は１２８ビットの識別子を有する。また、上述のように、それぞれのキャラクタリスティックは、キャラクタリスティック宣言とキャラクタリスティック値宣言との二つのアトリビュートを有する。例えば、ＳｅｒｖｉｃｅＮ１のキャラクタリスティック宣言は、アトリビュートタイプ（キャラクタリスティックのＵＵＩＤ）と、アトリビュート値としてキャラクタリスティックプロパティーと、キャラクタリスティック値ハンドルと、キャラクタリスティックＵＵＩＤ（ＳｅｒｖｉｃｅＮ１のＵＵＩＤ）とによって構成される。ＳｅｒｖｉｃｅＮ１のキャラクタリスティック値宣言は、キャラクタリスティック値に対するＵＵＩＤ（ＳｅｒｖｉｃｅＮ１のＵＵＩＤ）と、キャラクタリスティック値（ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ）によって構成される。

図８に示されたように、通常のＢＬＥ装置では一つの機能に対して一つのキャラクタリスティックを有する形態としてサービスが構成されている。このような従来のサービス構造は、キャラクタリスティック値ごとにハンドルを割り当て、ハンドルごとにデータ構造を固定できるので、サービスの設計とデータの解読が容易であるという長所がある。これに対して、他の装置がこの装置のサービスを検索するためには時間がかなりかかり、その結果接続完了までの時間が長くなるという短所がある。このような問題はキャラクタリスティックが多くなるほどさらに浮び上がる。また、サーバー装置に機能が追加されれば、サービスやキャラクタリスティックを新しく追加するためにサーバー装置のプログラムを変更する必要がある。

図９は、図８のＢＬＥ装置のプライマリーサービスであるＷａｔｃｈ Ｓｅｒｖｉｃｅを本発明の一実施形態により構成した例を示す。図９に示されたように、Ｗａｔｃｈ Ｓｅｒｖｉｃｅは２つのキャラクタリスティックであるデータ要求用キャラクタリスティック及びデータ通信用キャラクタリスティックのみを含む。データ要求用キャラクタリスティックは、クライアントがサーバーにデータを要求するために用いるキャラクタリスティックであり、データ通信用キャラクタリスティックはサーバーとクライアントとの間のデータ通信のために用いられるキャラクタリスティックである。従来、キャラクタリスティック値であるデータがそれぞれのキャラクタリスティックのアトリビュート値フィールドに記憶され、各々のキャラクタリスティックはＵＵＩＤによって識別される。一つの機能に一つのキャラクタリスティックを対応させる通常のサービス構造とは違い、本実施形態では機能の個数に関わらず２つの統合型キャラクタリスティックによってサービスを構成する。図８のキャラクタリスティック値、即ち、複数の機能の設定値（即ち、 ＳｅｒｖｉｃｅＮ１ ｖａｌｕｅ乃至ＳｅｒｖｉｃｅＮｘ ｖａｌｕｅ）は、データ通信用キャラクタリスティックのアトリビュート値として格納する。

図９の実施形態では、次の理由で２種類のキャラクタリスティックによってサービスを構成する。一つのサービスによって複数の機能の設定値が提供される場合、これらの複数の機能の設定値である複数の種別のデータを一つのデータ通信用キャラクタリスティックによって取り扱うので、複数の種別のデータに対して一つのハンドルのみが付与される。そのため、アトリビュートハンドルのみをパラメーターとして使う従来のＲｅａｄ Ｒｅｑｕｅｓｔ（読出し要求）メッセージ（図７を参照）を本実施形態では使用できなくなる。従って、データ要求用のキャラクタリスティックが別に必要になり、データ要求用のキャラクタリスティックとデータ通信用のキャラクタリスティックとの２つのキャラクタリスティックによってサービスを構成する。しかし、上記サービス構造は一例であり、本発明はこのような例に限定されない。例えば、実施形態によっては、複数のサービスを一つのサービスとして統合しても良く、従来の通り複数のサービスが存在しても良い。また、以下に詳細に説明するように、サービスは一つのキャラクタリスティックのみで構成されることも可能である。

このように２つの統合型キャラクタリスティックでサービスを構成すると、ハンドルによって多様な種類のデータを区別することができないので、本発明の複数の実施形態では、データの種類を区別するための別個の区別情報を使う。通信装置のそれぞれが同一の区別情報を保有することができるように区別情報はスペック（仕様）として管理されることが好ましい。区別情報は対応するデータに連関されて記憶される。具体的には、サーバーにおいて、データを記憶するために割り当てられているスペースに、（区別情報＋当該区別情報に対応するデータ）が記憶される。これによって、区別情報を記憶するためのスペース（例えば、１バイト（ｂｙｔｅ））が必要になり、データを記憶するスペースはそれだけ減る。区別情報はデータの前に記録されても良いし、データの後ろに記録されても良い。

データを要求したりデータを送信したりする場合にも、パケットのデータフィールドに要求するデータの区別情報、又は、データ及び当該データの区別情報を格納する。具体的には、例えば、図６（Ｂ）に示されたように、アトリビュートプロトコルＰＤＵのペイロードのアトリビュートパラメーターフィールドにアトリビュート値（Ａｔｔｒｉｂｕｔｅ
Ｖａｌｕｅ）として「区別情報」又は「区別情報＋データ」が記憶される。従って、区別情報を記憶するためのスペースが必要になり、データを記憶するスペースはそれだけ減る。例えば、区別情報を記憶するために１バイトを使えば、データを記憶するスペースは「Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅに割り当てられているスペース−１バイト」になる。区別情報はデータの前に記録されても良いし、データの後ろに記憶されても良い。クライアント装置でデータを格納する時にも、データとその区別情報を関連付けて格納することが好ましい。

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

以下、具体的な実施形態を使って本発明を一層具体的に説明する。図１０乃至図１４に示された実施形態において、第１の装置１００がサーバーであり、第２の装置２００であるスマートフォンのアプリケーションがクライアントとして動作する。

図１０は本実施形態に係るクライアントからサーバーに対してデータを要求する方法を従来の方法と共に示す。データはアトリビュートの値である。従来は、データを要求するためにクライアントがＲｅａｄ Ｒｅｑｕｅｓｔメッセージをサーバーに送信する。Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージは図７に示されたように、アトリビュートハンドルをパラメーター（アトリビュートハンドルパラメーター）として使う。アトリビュートハンドルはクライアントがサーバーのアトリビュートを問い合わせることができるようにするためにサーバーによって割り当てられる１６ビットの値である。サーバーからキャラクタリスティック値を読み出そうとする場合、アトリビュートハンドルパラメーターはキャラクタリスティック値ハンドルに設定される。このハンドルによって特定のＵＵＩＤを持つキャラクタリスティックの値にアクセスすることができる。クライアントからのＲｅａｄ Ｒｅｑｕｅｓｔが有効な場合、サーバーはクライアントが要求するデータをＲｅａｄ Ｒｅｓｐｏｎｓｅ（読出し応答）メッセージによってクライアントに送信する。図７に示されたように、Ｒｅａｄ Ｒｅｓｐｏｎｓｅメッセージはアトリビュート値をパラメーター（アトリビュート値パラメーター）として使い、この場合、Ｒｅａｄ Ｒｅｓｐｏｎｓｅによって伝送される値はキャラクタリスティック値である。

本発明の実施形態では、上記のように、サーバーのサービスがデータ要求用キャラクタリスティックとデータ通信用キャラクタリスティックとで構成されるので、サーバーにデータを要求するためにＲｅａｄ Ｒｅｑｕｅｓｔメッセージを利用すればパラメーターとしてデータ要求用キャラクタリスティックのハンドル値のみを入れることができる。即ち、Ｒｅａｄ Ｒｅｑｕｅｓｔメッセージによっては様々な種類のデータを読み出すことができない。従って、本実施形態では、サーバーにデータを要求する時にＲｅａｄ Ｒｅｑｕｅｓｔメッセージを使用できず、その代わりにＷｒｉｔｅ Ｃｏｍｍａｎｄ（書込み命令）メッセージとデータの区別情報とを使う。Ｗｒｉｔｅ Ｃｏｍｍａｎｄのパラメーターであるアトリビュートハンドルとアトリビュート値とのそれぞれは、データ要求用キャラクタリスティックのキャラクタリスティック値ハンドルと、区別情報とに設定される（書込み命令のパラメーターについては図７を参照）。サーバーは命令メッセージに対する応答を送らないために、本実施形態では上記区別情報に対応するデータをクライアントに送るために告知メッセージを利用する。図１０に示されたように、サーバーはクライアントにアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのキャラクタリスティック値ハンドルと、「区別情報＋データ」と、に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎ（ハンドル値告知）メッセージを送信することでクライアントが要求したデータを送信する。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを受信すると、クライアントはアトリビュート値の最初の１バイトをデータの区別情報として解読する。これによって、クライアントがサーバーから受信したデータの種類を判別することができる。区別情報が記録される位置（データの前又は後）及び／又は区別情報を記憶するスペースの大きさは、この実施形態に限定されない。

上記実施形態では、応答を伴わないＣｏｍｍａｎｄメッセージと告知メッセージを用いてデータの要求とデータの伝送とを行ったが、本発明はこの実施形態に限定されない。一実施形態においては、クライアントはサーバーにＷｒｉｔｅ Ｒｅｑｕｅｓｔ（書込み要求）メッセージを伝送してデータを要求する。この場合、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージのアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれは、データ要求用キャラクタリスティックのキャラクタリスティック値ハンドルと、区別情報とに設定される（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔのパラメーターについては図７を参照)。アトリビュート値の書き込みが正常に行なわれると、サーバーはＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージをクライアントに送信する。この実施形態はＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージがサーバーによって成功的に受信されたことを確認することができるという長所があるが、サーバーが応答メッセージを送るために追加的な電力を消耗しなければならないという短所がある。特に、サーバーがバッテリー容量の少ないデバイス（例えば、電子時計やウォッチ型のウェアラブルデバイス）である場合は、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを利用する方が電力消費の減少の側面でより有利である。

他の実施形態では、サーバーがデータを送信する時に、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージの代わりにＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎ（ハンドル値指示）メッセージを使用する。告知と指示の両方は、サーバーからクライアントに送信される通知用のメッセージであるが、告知は送信の成功時にもクライアントからの応答メッセージを伴わない一方、指示は応答メッセージである確認を伴うという違いがある。この実施形態の場合、サーバーは、クライアントにアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのキャラクタリスティック値ハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージによって、クライアントが要求したデータを送信する。

また、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージを受信すると、クライアントはＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎ（ハンドル値確認）メッセージで応答する。サーバーは、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージを受信することで、クライアント側でデータを正常に受信したことを確認することができる。本実施形態は、データがクライアントに成功的に送信されたことを確認することができるので、重要度が高いデータを伝送する時に有利である。一方、クライアントが応答メッセージを送信するために、追加の電力を消費しなければならないという短所がある。特に、クライアントがバッテリー容量の少ないデバイス（例えば、ウォッチ型のウェアラブルデバイス）である場合は、告知メッセージを利用する方が、消費電力の低減の観点ではより有利である。従って、データの重要度及び／又は電力消費を考慮して、告知メッセージを利用するか指示メッセージを利用するかを決定することができる。

図１１は、本実施形態に係るＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージによってデータを記入する方法を、従来の方法とともに示す。示されたように、従来は、クライアントが、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データを書き込むアトリビュートのハンドルと、記入されるデータとに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージをサーバーに送信する。上記ハンドルによって対応する特定のＵＵＩＤのキャラクタリスティックの値にアクセスしてデータを書き込むことができる。上記データが正常に書き込まれると、サーバーはＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージをクライアントに送信する。

本発明の実施形態では、上記のように、サーバーのサービスがデータ要求用キャラクタリスティックとデータ通信用キャラクタリスティックとで構成されるため、サーバーにデータを書き込もうとする場合、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージのアトリビュートハンドルパラメーターとしてデータ通信用キャラクタリスティックのハンドル値のみを入れることができる。従って、アトリビュートハンドルパラメーターによっては、様々な種類のデータにアクセスすることができない。本発明では、サーバーにデータを書き込もうとすると、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージのアトリビュート値パラメーターを「区別情報＋データ」に設定する。即ち、図６（Ｂ）に示されたペイロードのアトリビュートパラメーターフィールドのアトリビュート値を記憶するスペースの中で１バイトに、当該データの区別情報を記憶する。つまり、複数の種類のデータに同一のハンドル値が与えられているが、区別情報によってこれらを区別することができる。一方、区別情報を記憶するスペースの大きさは１バイトに限定されないし、実施形態によってさらに大きかったり少なかったりすることもできる。上記データが正常に書き込まれると、サーバーはＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージをクライアントに送る。

図１２は、本発明の一実施形態に係るＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージによってデータを記入する方法を、従来の方法とともに示す。示されたように、従来は、クライアントがアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データを書き込むアトリビュートのハンドルと記入されるデータとに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージをサーバーに送信する。上記ハンドルによって対応する特定のＵＵＩＤのキャラクタリスティック値にアクセスしてデータを書き込むことができる。命令メッセージは、応答メッセージを伴わない。

本発明の実施形態では、上記のように、サーバーのサービスがデータ要求用キャラクタリスティックと、データ通信用キャラクタリスティックとで構成されるため、サーバーにデータを書き込もうとする場合、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージのアトリビュートハンドルパラメーターとしてデータ通信用キャラクタリスティックのハンドル値のみを入れることができる。従って、アトリビュートハンドルパラメーターによっては、様々な種類のデータにアクセスすることができない。本発明では、サーバーにデータを書き込もうとすると、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージのアトリビュート値パラメーターを「区別情報＋データ」に設定する。即ち、図６（Ｂ）に示されるペイロードのアトリビュートパラメーターフィールドのアトリビュート値を記憶するスペースの中で１バイトに、当該データの区別情報を記憶する。つまり、複数の種類のデータに同一のハンドル値が与えられているが、区別情報によってこれらを区別することができる。一方、区別情報を記憶するスペースの大きさは１バイトに限定されないし、実施形態によってさらに大きかったり少なかったりすることもできる。

図１３は、本発明の一実施形態に係るサーバーからクライアントへ告知メッセージを送信する方法を、従来の方法とともに示す。示されたように、従来はサーバーがアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、通知するデータであるキャラクタリスティック値のキャラクタリスティック値ハンドルと、当該データとに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージをクライアントに送信することにより、データを送信する。クライアントは、告知メッセージを受信しても、これに対する応答メッセージをサーバーに送信しない。従って、データの重要度が低く、サーバーの消費電力の削減が重要な場合に告知メッセージを用いることが好ましい。

本発明の実施形態では、サーバーはクライアントにアトリビュート値パラメーターが「区別情報＋データ」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージによってデータを送信する。データの種類は、区別情報によって区別されるため、アトリビュートハンドルパラメーターは重要ではない。従って、アトリビュートハンドルパラメーターは、例えば、データ通信用キャラクタリスティックのキャラクタリスティック値ハンドルに設定されればよい。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを受信すると、クライアントはアトリビュート値の最初の１バイトをデータの区別情報として解読する。区別情報が記録される位置（データの前又は後）及び／又は区別情報を記憶するスペースの大きさは、この実施形態に限定されない。

図１４は、本発明の一実施形態に係るサーバーからクライアントへ指示（Ｉｎｄｉｃａｔｉｏｎ）メッセージを送信する方法を、従来の方法とともに示す。示されたように、従来はサーバーがアトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、通知するデータであるキャラクタリスティック値のキャラクタリスティック値ハンドルと、当該データとに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージをクライアントに送信することにより、データを送信する。クライアントは、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージを正常に受信すると、これに対する応答メッセージであるＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージをサーバーに送信する。従って、データの重要度が高い場合には、指示メッセージを用いることが好ましい。

本発明の実施形態では、サーバーはクライアントにアトリビュート値パラメーターが「区別情報＋データ」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージによってデータを送信する。データの種類は、区別情報によって区別されるため、アトリビュートハンドルパラメーターは意味のあるデータではない。従って、アトリビュートハンドルパラメーターは、例えば、データ通信用キャラクタリスティックのキャラクタリスティック値ハンドルに設定されればよい。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージを受信すると、クライアントはアトリビュート値の最初の１バイトをデータの区別情報として解読する。区別情報が記録される位置（データの前又は後）及び／又は区別情報を記憶するスペースの大きさは、この実施形態に限定されない。また、クライアントは、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージの受信をサーバーに確認させるために、応答メッセージであるＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージをサーバーに送信する。

上記のサービス構造、データ要求、データ書き込み、及びデータ通知に基づいて、サーバーとクライアントの間のデータのやり取り方法を定義することができる。以下では、さまざまなシナリオによるデータやり取り方法のいくつかの実施形態を説明する。

＜第１の実施形態＞
本実施形態では、第１の装置１００がサーバーとして、第２の装置２００のアプリケーションがクライアントとして動作する。つまり、第１の装置１００が図９に示された構造のサービスを持つ。換言すれば、第１の装置１００のサービスは、データ要求用キャラクタリスティックと、データ通信用キャラクタリスティックとの２つのキャラクタリスティックで構成されている。また、本実施形態では、データの通信のために、上記のデータ要求、データ書き込み、及びデータの通知を組み合わせる。第１の装置１００と第２の装置２００のアプリケーションは、データ要求やデータ書き込み等の通信の順番を予め固定しておらず、第２装置２００のアプリケーションに通信の順番を委ねるように構成される。

クライアントである第２の装置２００のアプリケーションは、必要に応じて、サーバーである第１の装置１００に対してデータ要求（図１０を参照）又はデータ書き込み（図１１及び図１２を参照）を行う。クライアントである第２の装置２００のアプリケーションは、必要な場合、適切なタイミングに（例えば、画面が遷移する時に）第１の装置１００にデータを要求することができるので、第１の装置１００から受信したデータをキャッシュしなくても良い。

図１５は、第１の実施形態に係るデータ要求プロセスを示す例示的なフローチャートである。以下では、図２を一緒に参照して、図１５について詳細に説明する。本例においては、サーバーは第１の装置１００であり、クライアントは第２の装置２００のアプリケーションである。

第１の装置１００と第２の装置２００の間の物理的コネクションと論理チャンネルが確立されると、第２の装置２００は、利用可能なサービスを発見し、発見されたサービスに関する情報を取得するために近距離通信部２０４を介して、第１の装置１００に対してサービス情報を要請する（ステップＳ１５０２）。第１の装置１００は、上記のサービス情報の要請を受信すると（ステップＳ１５２０）、メモリ１０８に格納されたサービスの情報を読み出してサービス及びキャラクタリスティックの参照情報（例えば、ハンドルのようなインデックス）を含むサービス情報を、近距離通信部１０２を介して第２の装置２００に送信する（ステップＳ１５２２）。上記サービス情報は、データ要求用キャラクタリスティックの参照情報（例えば、ハンドルのようなインデックス）と、データ通信用キャラクタリスティックの参照情報（例えば、ハンドルのようなインデックス）とを含む。第２の装置２００は、近距離通信部２０４を介して上記サービス情報を受信し（ステップＳ１５０４）、上記サービス情報を記憶装置（例えば、メモリ１０８）に格納する。次に、第２の装置２００のプロセッサ２０６は、データ要求用キャラクタリスティックの参照情報と、要求するデータの区別情報とを含むパケットを生成する（ステップＳ１５０６）。要求するデータの区別情報は、メモリ１０８から取得される。上述のように、当該パケットは、例えば、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージである。次に、上記のパケットは、近距離通信部２０４を介して第１の装置１００に送信される（ステップＳ１５０８）。

近距離通信部１０２を介して上記パケットを受信すると（ステップＳ１５２４）、第１の装置１００のプロセッサ１０４は、上記パケットを解読する。具体的には、上記パケットに含まれているキャラクタリスティックの参照情報とデータの区別情報とに基づいて、第２の装置２００が、上記区別情報に対応するデータを要求していると判断する。上記要求が有効な場合（ステップＳ１５２６：ＹＥＳ）、即ち、第２の装置２００がデータを要求する権限を持つ同時に当該データを読み取ることが可能な場合には、メモリ１０８から上記データの区別情報に対応するデータを取得する（ステップＳ１５２８）。プロセッサ１０４は、サービス情報に含まれているデータ通信用キャラクタリスティックの参照情報と、データの区別情報と、データとを含むパケットを生成する（ステップＳ１５３０）。上記パケットは、近距離通信部１０２により、第２の装置２００へ送信される（ステップＳ１５３２）。上述のように、当該パケットは、例えば、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージである。

第２の装置２００のプロセッサ２０６は、近距離通信部２０４を介して所定の時間（例えば、データ要求に対する応答の受信のために予め設定された待機時間）の内にデータを含むパケットを受信すると（ステップＳ１５１０：ＹＥＳ）、上記パケットからデータを抽出して、メモリ２０８に格納する（ステップＳ１５１２）。これによって図１５のデータ要求プロセスは終了する。

一方、第２の装置２００からのデータ要求が有効でない場合（ステップＳ１５２６：ＮＯ）、第１の装置１００は、プロセスを終了する。また、第２の装置２００が上記所定の時間の内に第１の装置１００からデータを含むパケットを受信できなかったり、エラーメッセージを受信したりする場合は（ステップＳ１５１０：ＮＯ）、第２の装置２００は、例えば、表示部２１４にエラーメッセージを表示することによって、データの要求に失敗したことをユーザに知らせる（ステップＳ１５１４）。次に、データ要求プロセスを終了する。この場合は、ステップＳ１５０８に戻って、第２装置２００のアプリケーションが第１の装置１００に再度データの要求を行うこともできる。

図１６は、第１の実施形態に係るデータ書込みプロセスを示す例示的なフローチャートである。以下では、図２を一緒に参照して、図１６について詳細に説明する。本例では、サーバーは第１の装置１００であり、クライアントは第２の装置２００のアプリケーションである。以下の説明は、図１５に関連して説明したサービスディスカバリー手続き（ステップＳ１５０２、Ｓ１５０４、Ｓ１５２０、及びＳ１５２２）が既に行われたことを前提とする。

第２の装置２００のプロセッサ２０６は、データ通信用キャラクタリスティックの参照情報（例えば、ハンドルのようなインデックス）と、書き込むデータと、当該データの区別情報とを含むパケットを生成する（ステップＳ１６０２）。上述のように、当該パケットは、例えば、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージである。次に、上記のパケットは、近距離通信部２０４を介して、第１の装置１００に送信される（ステップＳ１６０４）。

近距離通信部１０２を介して上記パケットを受信すると（ステップＳ１６２０）、第１の装置１００のプロセッサ１０４は、上記パケットを解読する。具体的には、上記パケットに含まれているキャラクタリスティックの参照情報と、データの区別情報とに基づいて、第２の装置２００が上記区別情報に対応するデータの書き込みを要請していると判断する。上記の要請が有効な場合（ステップＳ１６２２：ＹＥＳ）、即ち、第２の装置２００がデータの書き込みを要請する権限を持ち、同時に、当該データの書き込みが可能な場合には、メモリ１０８に上記データを記入する（ステップＳ１６２４）。上記データが正常に書き込まれると、プロセッサ１０４は、応答メッセージであるＷｒｉｔｅ Ｒｅｓｐｏｎｓｅを生成し（ステップＳ１６２６）、近距離通信部１０２を介して第２の装置２００に上記応答メッセージを送信する（ステップＳ１６２８）。第２の装置２００のプロセッサ２０６は、近距離通信部２０４を介して所定の時間（例えば、データ書き込み要請に対する応答の受信のために予め設定された待機時間）の内に応答メッセージが受信されると（ステップＳ１６０８：ＹＥＳ）、図１６のデータ書込みプロセスを終了する。

一方、第２の装置２００からのデータ書き込みの要請が有効でない場合（ステップＳ１６２２：ＮＯ）、第１の装置１００はプロセスを終了する。また、第２の装置２００が上記所定の時間の内に第１の装置１００からの応答メッセージを受信できなかったり、エラーメッセージを受信したりする場合（ステップＳ１６０８：ＮＯ）、第２の装置２００は、例えば、表示部２１４にエラーメッセージを表示することにより、データの書き込みに失敗したことをユーザに知らせる（ステップＳ１６１０）。これによって、データ書き込みプロセスを終了する。この場合は、ステップＳ１６０４に戻って、第２の装置２００のアプリケーションが第１の装置１００に再度データ書き込みを要請することもできる。

図１７は、第１の実施形態に係るデータ通知プロセスを示す例示的なフローチャートである。以下では、図２を一緒に参照して、図１７について詳細に説明する。本例では、サーバーは第１の装置１００であり、クライアントは第２の装置２００のアプリケーションである。以下の説明は、図１５に関連して説明したサービスディスカバリー手続き（ステップＳ１５０２、Ｓ１５０４、Ｓ１５２０、及びＳ１５２２）が既に行われたことを前提とする。

第１の装置１００のプロセッサ１０４は、メモリ１０８から、第２の装置２００のアプリケーションに通知するデータを取得する（ステップＳ１７０２）。そして、データ通信用キャラクタリスティックの参照情報（例えば、ハンドルのようなインデックス）と、ステップＳ１７０２において取得されたデータと、当該データの区別情報と、を含むパケットを生成する（ステップＳ１７０４）。上述のように、当該パケットは、例えば、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージである。次に、上記のパケットは、近距離通信部１０２を介して第２の装置２００に送信される（ステップＳ１７０６）。近距離通信部２０４を介して上記パケットを受信すると（ステップＳ１７２０）、第２の装置２００のプロセッサ２０６は、上記パケットを解読する。具体的には、上記パケットに含まれているデータの区別情報に基づいて、第１の装置１００が、当該区別情報に対応するデータを通知すると判断する。上記データが正常に受信されると、プロセッサ２０６は、応答メッセージであるＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎを生成し（ステップＳ１７２２）、近距離通信部２０４を介して、第１の装置１００に上記応答メッセージを送信する（ステップＳ１７２４）。第１の装置１００のプロセッサ１０４は、近距離通信部１０２を介して所定の時間（例えば、データの通知に対する応答の受信のために予め設定された待機時間）の内に応答メッセージが受信されると（ステップＳ１７０８：ＹＥＳ）、図１７のデータ通知プロセスを終了する。

一方、第１の装置１００が上記所定の時間の内に第２の装置２００からの応答メッセージを受信できなかったり、エラーメッセージを受信したりする場合は（ステップＳ１７０８：ＮＯ）、第１の装置１００は、例えば、表示部１１４にエラーメッセージを表示することにより、データの通知に失敗したことをユーザに知らせる（ステップＳ１７１０）。これによって、データの通知プロセスを終了する。この場合は、ステップＳ１７０６に戻って、第１の装置１００が第２の装置２００に再度通知メッセージを送信することもできる。

＜第２の実施形態＞
本実施形態では、第１の装置１００がサーバーとして、第２の装置２００のアプリケーションがクライアントとして動作する。第1の実施形態とは違い、サーバーである第１の装置１００のサービスは、データ通信用キャラクタリスティックのみを有する。また、データの通信のために、上記のデータ書き込み及びデータの通知を組み合わせて使用する。データ要求を用いない代わりに、即ち、データ要求用のキャラクタリスティックをサーバーに実装していない代わりに、サーバーである第１の装置１００とクライアントである第２の装置２００のアプリケーションとの間の通信の順序を固定する。本実施形態では、クライアントである第２の装置２００のアプリケーションが第１の装置１００にデータ要求をすることができないので、第１の装置１００から告知又は指示メッセージによって受信したデータをキャッシュする必要がある。

＜第３の実施形態＞
図１８は、本発明の第３の実施形態に係るデータ通信方法を示す。本実施形態は、第１の実施形態とは違い、第１の装置１００と第２の装置２００のアプリケーションとがサーバー及びクライアントとして動作する。第１の装置１００にはデータ通信用キャラクタリスティックが実装され、第２の装置２００のアプリケーションにはデータ要求用キャラクタリスティックが実装される。

第２の装置２００のアプリケーションが第１の装置１００にデータを要求する場合は、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ要求用キャラクタリスティックのハンドルと、要求データの区別情報とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するデータを要求すると判断する。この要求が有効である場合、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、第２の装置２００のアプリケーションに送信する。これによって、第２の装置２００のアプリケーションからの第１の装置１００へのデータ要求が行われることができる。一方、上記告知メッセージの少なくとも一つをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに取り替えることも可能である。指示メッセージが正常に受信される場合は、受信側は送信側に確認メッセージを送信する。

第２の装置２００のアプリケーションが第１の装置１００にデータの書き込みを要請する場合は、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを第１の装置１００に送信する。上記Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを受信すると、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するアトリビュート値に上記データを記入することを要請すると判断する。データが正常に書き込まれると、第１の装置１００は、Ｗｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを第２の装置２００のアプリケーションに送信する。一方、上記Ｗｒｉｔｅ ＲｅｑｕｅｓｔメッセージをＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージに切り替えることも可能である。この場合は、データが正常に書き込まれた場合も、第１の装置１００は、応答メッセージを送らない。従って、第１の装置１００の電力消費を減らすことができる。しかし、データの重要度が高い場合は、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを用いることが好ましい。

第１の装置１００が第２の装置２００のアプリケーションにデータを通知しようとする場合は、示されたように、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。一方、上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、Ｈａｎｄｌｅ
Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージが正常に受信された場合は、受信側は送信側にＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージを送信する。

＜第４の実施形態＞
図１９は、本発明の第４の実施形態に係るデータ通信方法を示す。本実施形態は、第１の実施形態とは違い、第１の装置１００と第２の装置２００のアプリケーションとが、サーバー及びクライアントとして動作する。第１の装置１００と第２の装置２００のアプリケーションとのそれぞれには、データ通信用キャラクタリスティックが実装される。

本実施形態では、一種類のキャラクタリスティックのみを用いるため、データ要求とデータ通信を判別するためのフラグ（Ｆｌａｇ）が更に用いられる。後述するように、上記フラグは、パケットの用途を判別するために使用される。図示された実施形態では、パケットのペイロードに含まれているフラグ値が０ｘ００である場合はデータ書き込みと、０ｘ０１である場合はデータの要求と、０ｘ０２である場合はデータの通知と解読される。

第２の装置２００のアプリケーションが第１の装置１００にデータを要求する場合は、示されたように、第２の装置２００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと、「要求データの区別情報＋フラグ０ｘ０１」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを生成し、これを第１の装置１００に送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第１の装置１００は、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。フラグの値が０ｘ０１に設定されているので、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するデータを要求したと判断する。この要求が有効であれば、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと「区別情報＋フラグ０ｘ０１＋データ」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００に送信する。これによって、第２の装置２００のアプリケーションからの第１の装置１００へのデータ要求が行われることができる。一方、上記告知メッセージの少なくとも一つをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。指示メッセージが正常に受信された場合は、受信側は送信側に確認メッセージを送信する。また、図示された実施形態では、パケットのデータフィールド内に区別情報、フラグ、データの順に記録するが、記録の順序を変更することも可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを要求する場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと、「要求データの区別情報＋フラグ０ｘ０１」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第２の装置２００のアプリケーションは、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。フラグの値が０ｘ０１に設定されているので、第２の装置２００は、第１の装置１００が、上記区別情報に対応するデータを要求すると判断する。この要求が有効であれば、第２の装置２００のアプリケーションは、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ０１＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。これによって、第１の装置１００からの第２の装置２００のアプリケーションへのデータ要求が行われることができる。一方、上記告知メッセージの少なくとも一つをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。指示メッセージが正常に受信された場合は、受信側は送信側に確認メッセージを送信する。また、図示された実施形態では、パケットのデータフィールド内に区別情報、フラグ、データの順に記録するが、記録の順序を変更することも可能である。

第２の装置２００のアプリケーションが第１の装置１００にデータの書き込みを要請しようとする場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ００＋データ」と、に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを受信すると、第１の装置１００は、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。フラグの値が０ｘ００に設定されているので、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するアトリビュート値に上記データを記入することを要請したと判断する。また、図示された実施形態では、パケットのデータフィールド内に区別情報、フラグ、データの順に記録するが、記録の順序を変更することも可能である。一方、上記告知メッセージをＨａｎｄｌｅ Ｖａｌｕｅ
Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータの書き込みを要請しようとする場合には、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、当該装置に実装されたデータ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ００＋データ」と、に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを受信すると、第２の装置２００のアプリケーションは、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。フラグの値が０ｘ００に設定されているので、第２の装置２００のアプリケーションは、第１の装置１００が、上記区別情報に対応するアトリビュート値に上記データを記入することを要請したと判断する。また、図示された実施形態では、パケットのデータフィールド内に区別情報、フラグ、データの順に記録するが、記録の順序を変更することも可能である。一方、上記告知メッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを通知しようとする場合には、示されたように、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ０２＋データ」と、に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。一方、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージが正常に受信された場合は、受信側は送信側にＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージを送信する。

第２の装置２００のアプリケーションが第１の装置１００にデータを通知しようとする場合には、第２の装置２００のアプリケーションは、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ０２＋データ」と、に設定されたＨａｎｄｌｅ
Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。一方、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。

＜第５の実施形態＞
図２０は、本発明の第５の実施形態に係るデータ通信方法を示す。本実施形態では、第４の実施形態と同様に、第１の装置１００と第２の装置２００のアプリケーションとが、サーバー及びクライアントとして動作し、第１の装置１００と第２の装置２００のアプリケーションとのそれぞれには、データ通信用キャラクタリスティックが実装される。しかし、第４の実施形態とは違い、データ要求とデータ通信を判別するフラグを用いず、有効なデータの有無に応じて、データ要求とデータ通信を判別する。

第２の装置２００のアプリケーションが第１の装置１００にデータを要求する場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、要求データの区別情報とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第１の装置１００は、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出されない場合は、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するデータを要求すると判断する。この要求が有効であれば、第１の装置１００は、アトリビュートハンドルパラメーターと、アトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。これによって、第２の装置２００のアプリケーションからの第１の装置１００へのデータ要求が行われることができる。この場合にも、上記告知メッセージの少なくとも一つをＨａｎｄｌｅ Ｖａｌｕｅ
Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを要求する場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、要求するデータの区別情報とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。上記Ｈａｎｄｌｅ Ｖａｌｕｅ
Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第２の装置２００は、受信されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを解読する。上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出されない場合は、第２の装置２００は、第１の装置１００が上記区別情報に対応するデータを要求すると判断する。この要求が有効であれば、第２の装置２００のアプリケーションは、アトリビュートハンドルパラメーターと、アトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。これによって、第１の装置１００からの第２の装置２００のアプリケーションへのデータ要求が行われることができる。この場合にも、上記告知メッセージの少なくとも一つをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

第２の装置２００のアプリケーションが第１の装置１００にデータの書き込みを要請しようとする場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを第１の装置１００に送信する。上記Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを受信すると、第１の装置１００は、受信したＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを解読する。上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出される場合は、第１の装置１００は、第２の装置２００のアプリケーションが上記区別情報に対応するアトリビュート値に上記データを記入することを要求すると判断する。この場合、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージは、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージに切り替えることが可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータの書き込みを要請しようとする場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを第２の装置２００のアプリケーションに送信する。上記Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを受信すると、第２の装置２００のアプリケーションは、受信したＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを解読する。上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出される場合は、第２の装置２００は、第１の装置１００が上記区別情報に対応するアトリビュート値に上記データを記入することを要求すると判断する。この場合、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージは、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージに切り替えることが可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを通知しようとする場合には、示されたように、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００のアプリケーションに送信する。この場合も、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

第２の装置２００のアプリケーションが第１の装置１００にデータを通知しようとする場合には、示されたように、第２の装置２００のアプリケーションは、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」に設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。この場合も、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

＜第６の実施形態＞
図２１は、本発明の第６の実施形態に係るデータ通信方法を示す。本実施形態は、第１の装置１００がサーバーとして動作し、第２の装置２００のアプリケーションがクライアントとして動作する。第２の実施形態と同様に、サーバーにデータ通信用キャラクタリスティックのみが実装される。そして、データ要求とデータ通信を判別するフラグを使用するという点において、第４の実施形態と類似している。

第２の装置２００のアプリケーションが第１の装置１００にデータを要求する場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、第１の装置１００のキャラクタリスティックであるデータ通信用キャラクタリスティックのハンドルと、「要求データの区別情報＋フラグ０ｘ０１」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第１の装置１００に送信する。一方、本実施形態では区別情報とフラグの順に記録するが、実施形態によっては、記録の順序を変更して、区別情報がフラグの後ろに記録される。上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを正常に受信すると、第１の装置１００は、上記メッセージに含まれているフラグの値が０ｘ０１である場合、第２の装置２００のアプリケーションが上記区別情報に対応するデータを要求すると判断する。この要求が有効であれば、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ０１＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、第２の装置２００のアプリケーションに送信する。一方、本実施形態では区別情報、フラグ、データの順に記録するが、実施形態によっては、記録の順序を変更することも可能である。これによって、第２の装置２００のアプリケーションからの第１の装置１００へのデータ要求が行われることができる。一方、上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。

第２の装置２００のアプリケーションが第１の装置１００にデータの書込みを要請しようとする場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ００＋データ」とに設定されたＷｒｉｔｅ ｒｅｑｕｅｓｔメッセージを第１の装置１００に送信する。一方、本実施形態では区別情報、フラグ、データの順に記録するが、実施形態によっては、記録の順序を変更することも可能である。上記Ｗｒｉｔｅ ｒｅｑｕｅｓｔメッセージを受信すると、第１の装置１００は、上記メッセージに含まれているフラグの値が０ｘ００である場合、第２の装置２００のアプリケーションが上記区別情報に対応するアトリビュート値に上記データを書き込むことを要請すると判断する。上記データが正常に記録されれば、第１の装置１００は第２の装置２００のアプリケーションにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。データの重要度が高くない場合、又は、第１の装置１００の消費電力を低減させるべき場合は、第２の装置２００のアプリケーションが応答メッセージを伴わないＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを送信することも可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを通知しようとする場合には、示されたように、第１の装置１００は、Ａｔｔｒｉｂｕｔｅ Ｈａｎｄｌｅパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋フラグ０ｘ０２＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００に送信する。一方、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることも可能である。Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージが正常に受信される場合に、第２の装置２００のアプリケーションは、第１の装置１００にＨａｎｄｌｅ Ｖａｌｕｅ Ｃｏｎｆｉｒｍａｔｉｏｎメッセージを送信する。

＜第７の実施形態＞
図２２は、本発明の第７の実施形態に係るデータ通信方法を示す。本実施形態は、第１の装置１００がサーバーとして動作し、第２の装置２００のアプリケーションがクライアントとして動作する。第２の実施形態と同様に、サーバーにデータ通信用キャラクタリスティックのみが実装される。そして、有効なデータの有無に応じて、データ要求とデータ通信を判別するという点においては、第５の実施形態と類似している。

第２の装置２００のアプリケーションが第１の装置１００にデータを要求する場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、要求するデータの区別情報とに設定されたＷｒｉｔｅ Ｃｏｍｍａｎｄメッセージを第１の装置１００に送信する。第１の装置１００は、上記Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージを受信すると、このメッセージを解析する。第１の装置１００は、上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出されない場合は、第２の装置２００のアプリケーションが上記区別情報に対応するデータを要求すると判断する。この要求が有効であれば、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、第２の装置２００のアプリケーションに送信する。これによって、第２の装置２００のアプリケーションからの第１の装置１００へのデータ要求が行われることができる。この場合にも、上記Ｈａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、Ｈａｎｄｌｅ Ｖａｌｕｅ Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

第２の装置２００のアプリケーションが第１の装置１００にデータの書き込みを要請しようとする場合には、示されたように、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＷｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを第１の装置１００に送信する。第１の装置１００は、上記Ｗｒｉｔｅ Ｒｅｑｕｅｓｔメッセージを受信すると、このメッセージを解析する。第１の装置１００は、上記メッセージのペイロードのデータフィールドにおいて、区別情報の後ろで、当該区別情報に対応する設定値として有効なデータが抽出される場合は、第２の装置２００のアプリケーションが上記区別情報に対応するアトリビュート値に上記データを記入することを要請すると判断する。データが正常に書き込まれると、第１の装置１００は、第２の装置２００のアプリケーションにＷｒｉｔｅ Ｒｅｓｐｏｎｓｅメッセージを送信する。この場合、Ｗｒｉｔｅ
Ｒｅｑｕｅｓｔメッセージを、Ｗｒｉｔｅ Ｃｏｍｍａｎｄメッセージに切り替えることも可能である。

第１の装置１００が第２の装置２００のアプリケーションにデータを通知しようとする場合には、示されたように、第１の装置１００は、アトリビュートハンドルパラメーターとアトリビュート値パラメーターとのそれぞれが、データ通信用キャラクタリスティックのハンドルと、「区別情報＋データ」とに設定されたＨａｎｄｌｅ Ｖａｌｕｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを第２の装置２００に送信する。この場合も、上記Ｈａｎｄｌｅ Ｖａｌｕｅ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨａｎｄｌｅ Ｖａｌｕｅ
Ｉｎｄｉｃａｔｉｏｎメッセージに切り替えることが可能である。

図２３は上記の実施形態の構成及び特徴を要約したテーブルである。示されたように、実施形態によって、第１の装置／第２の装置に実装されるキャラクタリスティックの数と種類、及び／又は、メッセージの判別方法が異なる。第１の実施形態、第３乃至第７の実施形態は、必要に応じてデータの要求が可能であるので、通信順序に自由度が高い。第２の実施形態は、一つのキャラクタリスティックでサービスを構成する。第３乃至第５の実施形態は、第１の装置と第２の装置との相互間にサービスディスカバリーを行う。

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

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

（付記１）
無線通信のできる装置であって、
通信パケットを他の通信装置と送受信する通信部と、
サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリと、
プロセッサと、
を備え、
前記プロセッサは、前記データ通信のための機能に関連付けられた参照情報と、前記データと、前記区別情報と、を含むパケットを生成することを特徴とする通信装置。
（付記２）
無線通信のできる装置であって、
通信パケットを他の通信装置と送受信する通信部と、
プロセッサと、
を備え、
前記プロセッサは、サービスを構成する少なくとも一つの機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成することを特徴とする通信装置。
（付記３）
前記参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリ
を備えることを特徴とする付記２に記載の通信装置。
（付記４）
前記区別情報は、前記パケットのペイロードに記憶されることを特徴とする付記１乃至３の何れか１項に記載の通信装置。
（付記５）
前記区別情報は、他の通信装置によって要求されるデータの区別情報であることを特徴とする付記１乃至４の何れか１項に記載の通信装置。
（付記６）
前記通信部を介して他の通信装置からパケットが受信される場合に、
前記プロセッサは、前記パケットに含まれた機能の参照情報に基づいて、前記他の通信装置との通信を制御することを特徴とする付記１乃至５の何れか１項に記載の通信装置。
（付記７）
前記通信部を介して他の通信装置からパケットが受信される場合に、
前記プロセッサは、前記パケットに含まれたフラグの値に基づいて、前記他の通信装置との通信を制御することを特徴とする付記２乃至５の何れか１項に記載の通信装置。
（付記８）
無線通信のできる装置であって、
通信パケットを他の通信装置と送受信する通信部と、（図２（Ａ）；１０２）
サービスを構成するデータ通信のための機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリと、
プロセッサと、
を備え、
前記通信部を介して他の通信装置からパケットが受信される場合に、
前記プロセッサは、前記パケットのペイロードに前記区別情報及び当該区別情報に対応付けられたデータが含まれているかどうかに基づいて、前記他の通信装置との通信を制御することを特徴とする通信装置。
（付記９）
前記通信部を介して他の通信装置から特定の区別情報に対応するデータを要求するパケットが受信される場合に、
前記プロセッサは、前記メモリから前記特定の区別情報に対応するデータを取得し、一つの機能の参照情報と、取得されたデータと、前記データの区別情報と、を含むパケットを生成することを特徴とする付記１乃至８の何れか１項に記載の通信装置。
（付記１０）
付記１乃至９の何れか１項に記載の通信装置と、
現在の日時を計数する計時部と、
前記計時部が計数した前記日時を表示する表示部と、
を備えることを特徴とする電子時計。
（付記１１）
無線通信のできる装置であって、
他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を受信し、通信パケットを他の通信装置と送受信する通信部と、
一つ又はそれ以上のデータの区別情報を記憶するメモリと、
プロセッサと、
を備え、
前記プロセッサは、第１の機能の参照情報と、一つのデータの区別情報と、を含むパケットを生成することを特徴とする通信装置。
（付記１２）
前記区別情報は、前記パケットのペイロードに記憶されることを特徴とする付記１１に記載の通信装置。
（付記１３）
前記プロセッサは、前記第１の機能とは異なる第２の機能の参照情報と、データと、前記データの区別情報と、を含むパケットを生成することを特徴とする付記１１又は１２に記載の通信装置。
（付記１４）
前記パケットは、当該パケットの用途を判別するためのフラッグを更に含むことを特徴とする付記１１又は１２に記載の通信装置。
（付記１５）
サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報を記憶するメモリを備えた無線通信装置の通信方法であって、
他の通信装置に送信するデータを取得するステップと、
前記データ通信のための機能に関連付けられた参照情報と、取得されたデータと、前記データを区別するための区別情報と、を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を備えることを特徴とする通信方法。
（付記１６）
無線通信装置の通信方法であって、
他の通信装置に送信するデータを取得するステップと、
データ通信に関連する機能の参照情報と、取得されたデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を備えることを特徴とする通信方法。
（付記１７）
無線通信のできる装置の通信方法であって、
他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を含むサービス情報を受信するステップと、
メモリから、前記他の装置と関連するデータの区別情報を取得するステップと、
一つの機能の参照情報と、取得された区別情報と、を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を備えることを特徴とする通信方法。
（付記１８）
サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報を記憶するメモリを備えた無線通信のできる装置に、
他の通信装置に送信するデータを取得するステップと、
前記データ通信のための機能に関連付けられた参照情報と、取得されたデータと、前記データを区別するための区別情報と、を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を実行させるプログラム。
（付記１９）
無線通信のできる装置に、
他の通信装置に送信するデータを取得するステップと、
データ通信に関連する機能の参照情報と、取得されたデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を実行させるプログラム。
（付記２０）
無線通信のできる装置に、
他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を含むサービス情報を受信するステップと、
メモリから、前記他の装置と関連するデータの区別情報を取得するステップと、
一つの機能の参照情報と、取得された区別情報と、を含むパケットを生成するステップと、
前記パケットを前記他の通信装置に送信するステップと、
を実行させるプログラム。

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

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

この発明の目的は、無線通信装置の間のコネクションプロセスを改善する方法、この方法を実行する通信装置、及びプログラムを提供することにある。

本発明の１つの態様は、データ要求のための機能とデータ通信のための機能とのうち少なくとも一つに対応した参照情報と、前記機能の内容を区別する区別情報と、を記憶するメモリと、プロセッサと、通信部と、を備え、前記プロセッサは、データ要求またはデータ通信を行うために、前記メモリから前記参照情報または前記区別情報を取得し、取得した前記参照情報または前記区別情報を含むパケットを生成し、前記通信部は、前記パケットを第２の通信装置に送信する。

Claims (21)

1. 無線通信のできる装置であって、
   通信パケットを他の通信装置と送受信する通信部と、
   サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリと、
   プロセッサと、
   を備え、
   前記プロセッサは、前記データ通信のための機能に関連付けられた参照情報と、前記データと、前記区別情報と、を含むパケットを生成することを特徴とする通信装置。
2. 前記通信部を介して他の通信装置から特定の区別情報に対応するデータを要求するパケットが受信される場合に、
   前記プロセッサは、前記メモリから前記特定の区別情報に対応するデータを取得し、一つの機能の参照情報と、取得されたデータと、前記データの区別情報と、を含むパケットを生成することを特徴とする請求項１に記載の通信装置。
3. 無線通信のできる装置であって、
   通信パケットを他の通信装置と送受信する通信部と、
   プロセッサと、
   を備え、
   前記プロセッサは、サービスを構成する少なくとも一つの機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成することを特徴とする通信装置。
4. 前記参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリ
   を備えることを特徴とする請求項３に記載の通信装置。
5. 前記通信部を介して他の通信装置から特定の区別情報に対応するデータを要求するパケットが受信される場合に、
   前記プロセッサは、前記メモリから前記特定の区別情報に対応するデータを取得し、一つの機能の参照情報と、取得されたデータと、前記データの区別情報と、を含むパケットを生成することを特徴とする請求項４に記載の通信装置。
6. 前記区別情報は、前記パケットのペイロードに記憶されることを特徴とする請求項１乃至５の何れか１項に記載の通信装置。
7. 前記区別情報は、他の通信装置によって要求されるデータの区別情報であることを特徴とする請求項１乃至６の何れか１項に記載の通信装置。
8. 前記通信部を介して他の通信装置からパケットが受信される場合に、
   前記プロセッサは、前記パケットに含まれた機能の参照情報に基づいて、前記他の通信装置との通信を制御することを特徴とする請求項１乃至７の何れか１項に記載の通信装置。
9. 前記通信部を介して他の通信装置からパケットが受信される場合に、
   前記プロセッサは、前記パケットに含まれたフラグの値に基づいて、前記他の通信装置との通信を制御することを特徴とする請求項１乃至７の何れか１項に記載の通信装置。
10. 無線通信のできる装置であって、
    通信パケットを他の通信装置と送受信する通信部と、
    サービスを構成するデータ通信のための機能に関連付けられた参照情報と、前記参照情報の前記機能に関連するデータと、前記データを区別するための区別情報と、を記憶するメモリと、
    プロセッサと、
    を備え、
    前記通信部を介して他の通信装置からパケットが受信される場合に、
    前記プロセッサは、前記パケットのペイロードに前記区別情報及び当該区別情報に対応付けられたデータが含まれているかどうかに基づいて、前記他の通信装置との通信を制御することを特徴とする通信装置。
11. 請求項１乃至１０の何れか１項に記載の通信装置と、
    現在の日時を計数する計時部と、
    前記計時部が計数した前記日時を表示する表示部と、
    を備えることを特徴とする電子時計。
12. 無線通信のできる装置であって、
    他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を受信し、通信パケットを他の通信装置と送受信する通信部と、
    一つ又はそれ以上のデータの区別情報を記憶するメモリと、
    プロセッサと、
    を備え、
    前記プロセッサは、第１の機能の参照情報と、一つのデータの区別情報と、を含むパケットを生成することを特徴とする通信装置。
13. 前記区別情報は、前記パケットのペイロードに記憶されることを特徴とする請求項１２に記載の通信装置。
14. 前記プロセッサは、前記第１の機能とは異なる第２の機能の参照情報と、データと、前記データの区別情報と、を含むパケットを生成することを特徴とする請求項１２又は１３に記載の通信装置。
15. 前記パケットは、当該パケットの用途を判別するためのフラッグを更に含むことを特徴とする請求項１２又は１３に記載の通信装置。
16. サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報を記憶するメモリを備えた無線通信装置の通信方法であって、
    他の通信装置に送信するデータを取得するステップと、
    前記データ通信のための機能に関連付けられた参照情報と、取得されたデータと、前記データを区別するための区別情報と、を含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を備えることを特徴とする通信方法。
17. 無線通信装置の通信方法であって、
    他の通信装置に送信するデータを取得するステップと、
    データ通信に関連する機能の参照情報と、取得されたデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を備えることを特徴とする通信方法。
18. 無線通信のできる装置の通信方法であって、
    他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を含むサービス情報を受信するステップと、
    メモリから、前記他の通信装置と関連するデータの区別情報を取得するステップと、
    一つの機能の参照情報と、取得された区別情報と、を含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を備えることを特徴とする通信方法。
19. サービスを構成するデータ要求のための機能及びデータ通信のための機能に関連付けられた参照情報を記憶するメモリを備えた無線通信のできる装置に、
    他の通信装置に送信するデータを取得するステップと、
    前記データ通信のための機能に関連付けられた参照情報と、取得されたデータと、前記データを区別するための区別情報と、を含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を実行させるプログラム。
20. 無線通信のできる装置に、
    他の通信装置に送信するデータを取得するステップと、
    データ通信に関連する機能の参照情報と、取得されたデータと、前記データを区別するための区別情報と、パケットの用途を判別するためのフラグとを含むパケットを生成するステップと、
    前記パケットを前記他の通信装置に送信するステップと、
    を実行させるプログラム。
21. 無線通信のできる装置に、
    他の通信装置から、サービスを構成する少なくとも一つの機能の参照情報を含むサービス情報を受信するステップと、
    メモリから、前記他の通信装置と関連するデータの区別情報を取得するステップと、
    一つの機能の参照情報と、取得された区別情報と、を含むパケットを生成するステップと、前記パケットを前記他の通信装置に送信するステップと、
    を実行させるプログラム。

Images