(57)【要約】オーディオ・データなどプロテクションを施す必要があるデータをＢｌｕｅｔｏｏｔｈ接続により伝送する場合、通信相手となる機器の処理能力に応じて認証の難易度を切り替える。したがって、低い処理能力の機器であっても、ＳＤＭＩに準拠したＢｌｕｅｔｏｏｔｈ通信を行うことができる。また、通信相手がパーソナル・コンピュータのように高い処理能力を持つ機器に対しては、充分なハッキング対策を施すことができる。
2003013068.tif 000002
【特許請求の範囲】
【請求項１】
所定の無線セル内でデータ・ストリームを送信するＳｏｕｒｃｅ装置とデータ・ストリームを受信するＳｉｎｋ装置とからなる無線通信システムであって、
前記Ｓｉｎｋ装置の処理能力を判別する判別手段と、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御手段と、
を具備することを特徴とする無線通信システム。
【請求項２】
前記判別手段は、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプの装置か、又は、処理能力の高い第２のタイプの装置かを判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項３】
前記認証制御手段は、前記Ｓｉｎｋ装置が第１のタイプの場合は比較的簡単な認証方式を採用し、前記Ｓｉｎｋ装置が第２のタイプの場合は比較的複雑な認証方式を採用する、
ことを特徴とする請求項２に記載の無線通信システム。
【請求項４】
前記判別手段は、前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項５】
前記判別手段は、前記Ｓｉｎｋ装置の種別を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項６】
前記判別手段は、前記Ｓｉｎｋ装置がサポートするサービスを基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項７】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙコマンドを用いて前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項８】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌコマンドを用いて前記Ｓｉｎｋ装置に処理能力を問い合わせる、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項９】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、問い合わせ（Ｉｎｑｕｉｒｙ）処理手続の際に入手したＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基に、前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項１０】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、サービス・ディスカバリ（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）によって取得された前記Ｓｉｎｋ装置が対応するサービス（プロトコル又はプロファイル）によってその処理能力を判別する、
ことを特徴とする請求項１に記載の無線通信システム。
【請求項１１】
前記判別手段は、前記Ｓｉｎｋ装置がＡ２ＤＰ（Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ）にのみ対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプであると判断する、
ことを特徴とする請求項１０に記載の無線通信システム。
【請求項１２】
前記判別手段は、前記Ｓｉｎｋ装置がＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ（ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのうち少なくとも１つのプロファイルに対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプではないと判断する、
ことを特徴とする請求項１０に記載の無線通信システム。
【請求項１３】
所定の無線セル内でＳｉｎｋ装置に対してデータ・ストリームを送信する無線通信制御装置であって、
前記Ｓｉｎｋ装置の処理能力を判別する判別手段と、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御手段と、
を具備することを特徴とする無線通信制御装置。
【請求項１４】
前記判別手段は、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプの装置か、又は、処理能力の高い第２のタイプの装置かを判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項１５】
前記認証制御手段は、前記Ｓｉｎｋ装置が第１のタイプの場合は比較的簡単な認証方式を採用し、前記Ｓｉｎｋ装置が第２のタイプの場合は比較的複雑な認証方式を採用する、
ことを特徴とする請求項１４に記載の無線通信制御装置。
【請求項１６】
前記判別手段は、前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項１７】
前記判別手段は、前記Ｓｉｎｋ装置の種別を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項１８】
前記判別手段は、前記Ｓｉｎｋ装置がサポートするサービスを基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項１９】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙコマンドを用いて前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項２０】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌコマンドを用いて前記Ｓｉｎｋ装置に処理能力を問い合わせる、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項２１】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、問い合わせ（Ｉｎｑｕｉｒｙ）処理手続の際に入手したＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基に、前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項２２】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別手段は、サービス・ディスカバリ（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）によって取得された前記Ｓｉｎｋ装置が対応するサービス（プロトコル又はプロファイル）によってその処理能力を判別する、
ことを特徴とする請求項１３に記載の無線通信制御装置。
【請求項２３】
前記判別手段は、前記Ｓｉｎｋ装置がＡ２ＤＰ（Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ）にのみ対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプであると判断する、
ことを特徴とする請求項２２に記載の無線通信制御装置。
【請求項２４】
前記判別手段は、前記Ｓｉｎｋ装置がＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ（ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのうち少なくとも１つのプロファイルに対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプではないと判断する、
ことを特徴とする請求項２２に記載の無線通信制御装置。
【請求項２５】
所定の無線セル内でＳｉｎｋ装置に対するデータ・ストリームの送信を制御する無線通信制御方法であって、
前記Ｓｉｎｋ装置の処理能力を判別する判別ステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御ステップと、
を具備することを特徴とする無線通信制御方法。
【請求項２６】
前記判別ステップでは、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプの装置か、又は、処理能力の高い第２のタイプの装置かを判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項２７】
前記認証制御ステップでは、前記Ｓｉｎｋ装置が第１のタイプの場合は比較的簡単な認証方式を採用し、前記Ｓｉｎｋ装置が第２のタイプの場合は比較的複雑な認証方式を採用する、
ことを特徴とする請求項２６に記載の無線通信制御方法。
【請求項２８】
前記判別ステップでは、前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項２９】
前記判別ステップでは、前記Ｓｉｎｋ装置の種別を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３０】
前記判別ステップでは、前記Ｓｉｎｋ装置がサポートするサービスを基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３１】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別ステップでは、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙコマンドを用いて前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３２】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別ステップでは、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌコマンドを用いて前記Ｓｉｎｋ装置に処理能力を問い合わせる、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３３】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別ステップでは、問い合わせ（Ｉｎｑｕｉｒｙ）処理手続の際に入手したＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基に、前記Ｓｉｎｋ装置の処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３４】
前記無線セルは、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築され、
前記判別ステップでは、サービス・ディスカバリ（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）によって取得された前記Ｓｉｎｋ装置が対応するサービス（プロトコル又はプロファイル）によってその処理能力を判別する、
ことを特徴とする請求項２５に記載の無線通信制御方法。
【請求項３５】
前記判別ステップでは、前記Ｓｉｎｋ装置がＡ２ＤＰ（Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ）にのみ対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプであると判断する、
ことを特徴とする請求項３４に記載の無線通信制御方法。
【請求項３６】
前記判別ステップでは、前記Ｓｉｎｋ装置がＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ（ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのうち少なくとも１つのプロファイルに対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプではないと判断する、
ことを特徴とする請求項３４に記載の無線通信制御方法。
【請求項３７】
所定の無線セル内でＳｉｎｋ装置に対するデータ・ストリームの送信制御をコンピュータ・システム上で実行するように記述されたコンピュータ・ソフトウェアをコンピュータ可読形式で物理的に格納した記憶媒体であって、前記コンピュータ・ソフトウェアは、
前記Ｓｉｎｋ装置の処理能力を判別する判別ステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御ステップと、
を具備することを特徴とする記憶媒体。
【請求項３８】
所定の無線セル内でＳｉｎｋ装置に対するデータ・ストリームの送信制御をコンピュータ・システム上で実行するように記述されたコンピュータ・プログラムであって、
前記Ｓｉｎｋ装置の処理能力を判別する判別ステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御ステップと、
を具備することを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
［技術分野］
本発明は、複数の機器間をワイヤレスで接続するための無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムに係り、特に、所定の通信セル内でワイヤレス接続された機器間でオーディオ・データを伝送するための無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムに関する。
さらに詳しくは、本発明は、Ｂｌｕｅｔｏｏｔｈのように１台のマスタ（ｍａｓｔｅｒ）機器と複数台のスレーブ（ｓｌａｖｅ）機器によって構成されるピコネット（ｐｉｃｏｎｅｔ）内において機器間でオーディオ・データを伝送するための無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムに係り、特に、オーディオ・データなどのデジタル・データに所定のプロテクションを施しながらＢｌｕｅｔｏｏｔｈ機器間で伝送する無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムに関する。
［背景技術］
最近、デジタルＶＴＲやＭＤ（ミニディスク（商標））記録再生装置などのデジタル記録装置が普及し始めている。さらに、記録機能を備えたＤＶＤ（デジタルビデオディスク（商標）あるいはデジタル・バーサタイル・ディスク）装置も登場し、パーソナル・コンピュータ（ＰＣ）などの機器に搭載されるようになってきている。
このようなデジタル情報記録装置によれば、デジタル形式のデータやコンテンツの複製や改竄は極めて容易であり、著作権侵害の危険に無防備にさらされているとさえ言える。したがって、著作権法やその他の複製に関する法規制を強化するだけでは不充分であり、情報技術の観点からもデータやコンテンツの正当な利用を支援し若しくは不正利用を排除して、著作権の保護を拡充する必要があると思料される。
例えば、デジタル音楽の著作権保護を目的として、１９９８年に米国大手レコード会社などが中心となってＳＤＭＩ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  Ｍｕｓｉｃ  Ｉｎｔｅｒａｃｔｉｖｅ）なるフォーラムが設立された。ＳＤＭＩでは、基本的には、何らプロテクションが掛けられていない状態でデジタル形式のコンテンツを機器外に出力することを禁止している。したがって、オーディオ再生機器からスピーカやヘッドフォンなどのレンダリング（Ｒｅｎｄｅｒｉｎｇ）装置にコンテンツをデジタル出力する場合、あるいは、ＤＶＤ−Ｒドライブやパーソナル・コンピュータ（ＰＣ）などのレコーディング（Ｒｅｃｏｒｄｉｎｇ）装置にコンテンツをデジタル出力する場合などにおいて、伝送されるデータ・コンテンツをプロテクトすることが必須（すなわち、”ｕｎｐｒｏｔｅｃｔｅｄ  ｄｉｇｉｔａｌ  ｏｕｔ”の禁止）とされている。
例えば、ＳＤＭＩでは、ポータブル音楽プレーヤで著作権を保護する仕組みとして”Ｓｃｒｅｅｎｉｎｇ”という機能が規定されている。Ｓｃｒｅｅｎｉｎｇとは、ポータブル・デバイス（ＰＤ）のメモリ・レコーダ上にコピーしてよいコンテンツか否かを検査する仕組みであり、電子透かしを利用することが既に合意されている。例えば、不正に配信されたコンテンツや、既に１回（若しくは許容回数だけ）コピーされたコンテンツからはもはやコピーできないように、電子透かしによってＳｃｒｅｅｎｉｎｇをかけることができる。
このようなＳＤＭＩの要請は、ポータブル機器間をケーブル接続する場合は勿論のこと、ワイヤレスで機器間接続する場合においても必須とされている。
ところで、最近では、近距離無線通信の代表例である”Ｂｌｕｅｔｏｏｔｈ”が、普及し始めて、各種の情報機器に搭載されている。Ｂｌｕｅｔｏｏｔｈは、さまざまな業界に対して適用可能なワイヤレス接続インターフェースを提供する標準規格であり、”Ｂｌｕｅｔｏｏｔｈ  ＳＩＧ（Ｓｐｅｃｉａｌ  Ｉｎｔｅｒｅｓｔ  Ｇｒｏｕｐ）”にその運営や管理などが委ねられている。
Ｂｌｕｅｔｏｏｔｈは、２．４ＧＨｚのＩＳＭ  （Ｉｎｄｕｓｔｒｙ  Ｓｃｉｅｎｃｅ  Ｍｅｄｉｃａｌ）バンドと呼ばれるグローバルな無線周波数を使用し、全体のデータ伝送速度は１Ｍｂｐｓであり、その中には電話の音声伝送に利用可能な６４ｋｂｐｓの同期伝送チャンネルと、データ伝送のための非同期伝送チャンネルが設けられている。前者の同期伝送チャンネルは、ＳＣＯ（Ｓｙｎｃｈｒｏｎｏｕｓ  Ｃｏｎｎｅｃｔｉｏｎ  Ｏｒｉｅｎｔｅｄ  Ｌｉｎｋ）伝送方式が採用され、回線接続に適用される。また、後者の非同期伝送チャンネルは、ＡＣＬ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｃｏｎｎｅｃｔｉｏｎ  Ｌｅｓｓ  Ｌｉｎｋ）伝送方式が採用され、パケット交換によるデータ伝送に適用される。Ｂｌｕｅｔｏｏｔｈによる機器間の接続範囲は１０ｍ程度であるが、追加増幅器を使用することによって、さらに１００ｍまで延長することができる。
Ｂｌｕｅｔｏｏｔｈの技術仕様は、「コア（Ｃｏｒｅ）」と「プロファイル（Ｐｒｏｆｉｌｅ）」に大別される。コアは、Ｂｌｕｅｔｏｏｔｈが提供するワイヤレス接続の基礎を定義する。これに対し、プロファイルは、Ｂｌｕｅｔｏｏｔｈのコアに基づいて各種の機能やアプリケーションを開発して機器に組み込む際に、機器間の相互接続性を保証するための各機能毎に規定された技術要件の集まりである。
Ｂｌｕｅｔｏｏｔｈのプロファイルは複数存在し、その組み合わせにより１つのアプリケーション（「利用モデル（Ｕｓａｇｅ）」とも呼ぶ）を提供する。実際には、アプリケーションを提供するプロファイルの組み合わせがコアとともにＢｌｕｅｔｏｏｔｈ製品に実装されることになる。
例えば、携帯電話やパーソナル・コンピュータ関連のプロファイルを始めとして、自動車、ネットワーク、プリンタ、オーディオ、ビデオなど、さまざまなＢｌｕｅｔｏｏｔｈプロファイルが想定される。
例えば、オーディオ・データの伝送用のプロファイルとして、”Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ”（Ａ２ＤＰ）を挙げることができる。このプロファイルによれば、ＡＶ再生機器とスピーカやヘッドフォンなどのレンダリング装置とのワイヤレス接続や、ＡＶ再生機器とのＤＶＤ−Ｒドライブやパーソナル・コンピュータ（ＰＣ）などのレコーディング装置とのワイヤレス接続を実現することができる。
この種のＢｌｕｅｔｏｏｔｈ搭載のＡＶ機器においても、先述したＳＤＭＩに準拠するためには、”ｕｎｐｒｏｔｅｃｔｅｄ  ｄｉｇｉｔａｌ  ｏｕｔ”を禁止するための仕組み、すなわち、デジタル伝送されるオーディオ・データをプロテクトするための仕組みを装備する必要がある。
Ｂｌｕｅｔｏｏｔｈセキュリティは、ある特定の２端末間で「リンク・キー（Ｌｉｎｋ  Ｋｅｙ）」と呼ばれる共通のパラメータを設定することを基本として、マスタと各スレーブ間で１対１のセキュリティが管理される（リンク・キーは第３者には開示されない）。
ここで、デジタル・データをプロテクトする要素としては、「盗み取り（盗み聴き）」対策のための暗号化（ｅｎｃｒｙｐｔｉｏｎ）と、「なりすまし」対策のための認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）という２つに大別される。
Ｂｌｕｅｔｏｏｔｈ  ＳＩＧでは、コンテンツのプロテクション方式に関しては関与していないため、各ベンダの責任でコンテンツのプロテクションを行わなければならない。しかしながら、Ｂｌｕｅｔｏｏｔｈ搭載のオーディオ機器間での認証方式は、Ｂｌｕｅｔｏｏｔｈ層ではなく、その上位のアプリケーション層で実装しなければならない。
本発明者等は、Ｂｌｕｅｔｏｏｔｈ通信をヘッドフォンやスピーカなどのレンダリング（すなわち聴くだけ）の用途に使用する場合と、レコーディングの用途に使用する場合とでは、プロテクションの仕組みが異なるものと思料する。
レコーディングに関しては、Ｍｕｓｉｃ  Ｄｏｗｎｌｏａｄの場合のように、アプリケーション毎に充分納得のいく高い強度レベルのプロテクションが採用される場合が多い。
これに対し、レンダリングに関しては、どの程度の強度とするかまで規定しているケースは少ない。例えば、ヘッドフォンのように処理能力の低いＣＰＵが搭載されている機器に対して高いレベルのプロテクションを要求又は必須とすることは困難である。
例えば、ｉ−ＬＩＮＫ（ＩＥＥＥ  １３９４）用のコピー・プロテクション規格であるＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）のＦｕｌｌａｕｔｈｅｎｔｉｃａｔｉｏｎを適用するためには、ＭＩＰＳ  Ｒ４０００  １００ＭＨｚのＣＰＵで計算しておおよそ６００ｍｓの演算時間を要する負荷となる。このようなＣＰＵのコストや処理時間をヘッドフォンのような末端のポータブル機器に課すことは現実的ではない。また、バッテリ駆動を基本とするポータブル機器においては、システム・デザイン上で消費電力が大きな問題となり、このような過大なレベルの認証方式を一律に採用することは困難である。
一方において、レコーディング機能を装備したパーソナル・コンピュータ（ＰＣ）がレンダリング用途であると偽って不正に記録することを防止しなければならない。
ヘッドフォンのような演算能力が低い機器に対して採用し易いように、レンダリング用途として、例えば８ビットのキーを用いた認証方式を採用した場合、演算能力が高いパーソナル・コンピュータから簡単に破られてしまい、プロテクションを行う意味が薄れてしまう。
［発明の開示］
本発明の目的は、所定の通信セル内でワイヤレス接続された機器間でオーディオ・データを好適に伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、Ｂｌｕｅｔｏｏｔｈのように１台のマスタ（ｍａｓｔｅｒ）機器と複数台のスレーブ（ｓｌａｖｅ）機器によって構成されるピコネット（ｐｉｃｏｎｅｔ）内において機器間でオーディオ・データを好適に伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、オーディオ・データなどのデジタル・データに所定のプロテクションを施しながらＢｌｕｅｔｏｏｔｈ機器間で伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することにある。
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、所定の無線セル内でデータ・ストリームを送信するＳｏｕｒｃｅ装置とデータ・ストリームを受信するＳｉｎｋ装置とからなる無線通信システムであって、
前記Ｓｉｎｋ装置の処理能力を判別する判別手段と、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御手段と、
を具備することを特徴とする無線通信システムである。
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
また、前記無線セルは、例えばＢｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築される「ピコネット」である。ピコネット内では、通信秩序を維持する１台のマスタ装置が複数台のスレーブ装置と１対１のＢｌｕｅｔｏｏｔｈ通信を行なうことができる。
前記判別手段は、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプの装置か、又は、処理能力の高い第２のタイプの装置かを判別する。また、前記認証制御手段は、前記Ｓｉｎｋ装置が第１のタイプの場合は比較的簡単な認証方式を採用し、前記Ｓｉｎｋ装置が第２のタイプの場合は比較的複雑な認証方式を採用する。
本発明の第１の側面に係る無線通信システムによれば、オーディオ・データなどプロテクションを施す必要があるデータをＢｌｕｅｔｏｏｔｈ接続により伝送する場合、通信相手となる機器の処理能力に応じて認証方式の難易度を切り替えることで、適切なコンテンツ・プロテクションを行なうことができる。したがって、ヘッドフォンのようなレンダリング機能しか持たない低い処理能力の機器であっても、ＳＤＭＩに準拠したＢｌｕｅｔｏｏｔｈ通信を行なうことができる。また、通信相手がパーソナル・コンピュータのように高い処理能力を持つ機器に対しては、充分なハッキング対策を施すことができる。
前記判別手段は、前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、オーディオ伝送用のＡＶＤＴＰ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）プロトコルで定義されるＳｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙコマンドを用いて前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別することができる。
また、前記判別手段は、例えば、ＡＶＤＴＰプロトコルで定義されるＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌコマンドを用いて前記Ｓｉｎｋ装置に処理能力を問い合わせることができる。
また、前記判別手段は、前記Ｓｉｎｋ装置の種別を基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、問い合わせ（Ｉｎｑｕｉｒｙ）処理手続の際に入手したＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基に、前記Ｓｉｎｋ装置の処理能力を判別することができる。
また、前記判別手段は、前記Ｓｉｎｋ装置がサポートするサービスを基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、サービス・ディスカバリ（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）によって取得された前記Ｓｉｎｋ装置が対応するサービス（プロトコル又はプロファイル）によってその処理能力を判別することができる。
例えば、前記判別手段は、前記Ｓｉｎｋ装置がＡ２ＤＰ（Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ）にのみ対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプであると判断することができる。
あるいは、前記判別手段は、前記Ｓｉｎｋ装置がＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ（ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのうち少なくとも１つのプロファイルに対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプではないと判断することができる。
また、本発明の第２の側面は、所定の無線セル内でＳｉｎｋ装置に対してデータ・ストリームを送信する無線通信制御装置又は無線通信制御方法であって、
前記Ｓｉｎｋ装置の処理能力を判別する判別手段又はステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御手段又はステップと、
を具備することを特徴とする無線通信制御装置又は無線通信制御方法である。
前記無線セルは、例えばＢｌｕｅｔｏｏｔｈワイヤレス・ネットワークにより構築される「ピコネット」である。ピコネット内では、通信秩序を維持する１台のマスタ装置が複数台のスレーブ装置と１対１のＢｌｕｅｔｏｏｔｈ通信を行うことができる。また、本発明の第２の側面に係る無線通信制御装置又は無線通信制御方法を、Ｂｌｕｅｔｏｏｔｈピコネット内のマスタ装置に実装することができる。
前記判別手段又はステップは、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプの装置か、又は、処理能力の高い第２のタイプの装置かを判別する。また、前記認証制御手段は、前記Ｓｉｎｋ装置が第１のタイプの場合は比較的簡単な認証方式を採用し、前記Ｓｉｎｋ装置が第２のタイプの場合は比較的複雑な認証方式を採用する。
本発明の第２の側面に係る無線通信制御装置又は無線通信制御方法によれば、オーディオ・データなどプロテクションを施す必要があるデータをＢｌｕｅｔｏｏｔｈ接続により伝送する場合、通信相手となる機器の処理能力に応じて認証方式の難易度を切り替えることで、適切なコンテンツ・プロテクションを行なうことができる。したがって、ヘッドフォンのようなレンダリング機能しか持たない低い処理能力の機器であっても、ＳＤＭＩに準拠したＢｌｕｅｔｏｏｔｈ通信を行なうことができる。また、通信相手がパーソナル・コンピュータのように高い処理能力を持つ機器に対しては、充分なハッキング対策を施すことができる。
前記判別手段又はステップは、前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、オーディオ伝送用のＡＶＤＴＰプロトコルで定義されるＳｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙコマンドを用いて前記Ｓｉｎｋ装置からの自己申告を基に前記Ｓｉｎｋ装置の処理能力を判別することができる。
また、前記判別手段又はステップは、例えば、ＡＶＤＴＰプロトコルで定義されるＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌコマンドを用いて前記Ｓｉｎｋ装置に処理能力を問い合わせることができる。
また、前記判別手段又はステップは、前記Ｓｉｎｋ装置の種別を基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、問い合わせ（Ｉｎｑｕｉｒｙ）処理手続の際に入手したＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基に、前記Ｓｉｎｋ装置の処理能力を判別することができる。
また、前記判別手段又はステップは、前記Ｓｉｎｋ装置がサポートするサービスを基に前記Ｓｉｎｋ装置の処理能力を判別するようにしてもよい。例えば、サービス・ディスカバリによって取得された前記Ｓｉｎｋ装置が対応するサービスによってその処理能力を判別することができる。
例えば、前記判別手段又はステップは、前記Ｓｉｎｋ装置がＡ２ＤＰにのみ対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプであると判断することができる。
あるいは、前記判別手段又はステップは、前記Ｓｉｎｋ装置がＰＡＮ、ＬＡＮ、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのうち少なくとも１つのプロファイルに対応している場合には、前記Ｓｉｎｋ装置が処理能力の低い第１のタイプではないと判断することができる。
また、本発明の第３の側面は、所定の無線セル内でＳｉｎｋ装置に対するデータ・ストリームの送信制御をコンピュータ・システム上で実行するように記述されたコンピュータ・ソフトウェアをコンピュータ可読形式で物理的に格納した記憶媒体であって、前記コンピュータ・ソフトウェアは、
前記Ｓｉｎｋ装置の処理能力を判別する判別ステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御ステップと、
を具備することを特徴とする記憶媒体である。
本発明の第３の側面に係る記憶媒体は、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ・ソフトウェアをコンピュータ可読な形式で提供する媒体である。このような媒体は、例えば、ＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）やＦＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ）、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ  ｄｉｓｃ）などの着脱自在で可搬性の記憶媒体である。あるいは、ネットワーク（ネットワークは無線、有線の区別を問わない）などの伝送媒体などを経由してコンピュータ・ソフトウェアを特定のコンピュータ・システムに提供することも技術的に可能である。
このような記憶媒体は、コンピュータ・システム上で所定のコンピュータ・ソフトウェアの機能を実現するための、コンピュータ・ソフトウェアと記憶媒体との構造上又は機能上の協働的関係を定義したものである。換言すれば、本発明の第３の側面に係る記憶媒体を介して所定のコンピュータ・ソフトウェアをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る無線通信システム、あるいは第２の側面に係る無線通信制御装置及び無線通信制御方法と同様の作用効果を得ることができる。
また、本発明の第４の側面は、所定の無線セル内でＳｉｎｋ装置に対するデータ・ストリームの送信制御をコンピュータ・システム上で実行するように記述されたコンピュータ・プログラムであって、
前記Ｓｉｎｋ装置の処理能力を判別する判別ステップと、
該判別された前記Ｓｉｎｋ装置の処理能力に応じて、前記Ｓｏｕｒｃｅ装置との前記Ｓｉｎｋ装置間の認証方式を決定する認証制御ステップと、
を具備することを特徴とするコンピュータ・プログラムである。
本発明の第４の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第４の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る無線通信システム、あるいは第２の側面に係る無線通信制御装置及び無線通信制御方法と同様の作用効果を得ることができる。
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
［発明を実施するための最良の形態］
以下、図面を参照しながら本発明の実施形態について詳解する。
本発明に係る認証方式によれば、認証に成功した場合に限り通信相手はレンダリング用途でストリームを受ける機器であるとみなすことができる。この結果、伝送データのレコーディングが行われることを想定せず、比較的低い強度のプロテクションを以って伝送データを保護することができる。
以下、Ｂｌｕｅｔｏｏｔｈでオーディオ伝送を行う場合を例にとって、図面を参照しながら本発明の実施形態について詳解する。
Ｂｌｕｅｔｏｏｔｈは、２．４ＧＨｚのＩＳＭ（Ｉｎｄｕｓｔｒｙ  Ｓｃｉｅｎｃｅ  Ｍｅｄｉｃａｌ）バンドと呼ばれるグローバルな無線周波数を使用し、全体のデータ伝送速度は１Ｍｂｐｓであり、その中には電話の音声伝送に利用可能な６４ｋｂｐｓの同期伝送チャンネルと、データ伝送のための非同期伝送チャンネルが設けられている。前者の同期伝送チャンネルは、ＳＣＯ（Ｓｙｎｃｈｒｏｎｏｕｓ  Ｃｏｎｎｅｃｔｉｏｎ  Ｏｒｉｅｎｔｅｄ  Ｌｉｎｋ）伝送方式が採用され、回線接続に適用される。また、後者の非同期伝送チャンネルは、ＡＣＬ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｃｏｎｎｅｃｔｉｏｎ  Ｌｅｓｓ  Ｌｉｎｋ）伝送方式が採用され、パケット交換によるデータ伝送に適用される。
Ｂｌｕｅｔｏｏｔｈの技術仕様は、「コア（Ｃｏｒｅ）」と「プロファイル（Ｐｒｏｆｉｌｅ）」に大別される。コアは、Ｂｌｕｅｔｏｏｔｈが提供するワイヤレス接続の基礎を定義する。これに対し、プロファイルは、Ｂｌｕｅｔｏｏｔｈのコアに基づいて各種の機能やアプリケーションを開発して機器に組み込む際に、機器間の相互接続性を保証するための各機能毎に規定された技術要件の集まりである。Ｂｌｕｅｔｏｏｔｈのプロファイルは複数存在し、その組み合わせにより１つのアプリケーション（「利用モデル（Ｕｓａｇｅ）」とも呼ぶ）を提供する。実際には、アプリケーションを提供するプロファイルの組み合わせがコアとともにＢｌｕｅｔｏｏｔｈ製品に実装されることになる。
Ｂｌｕｅｔｏｏｔｈは、１対１のケーブル代替接続だけではなく、１対多の簡易ワイヤレス・ネットワークの構築も提供する。このため、Ｂｌｕｅｔｏｏｔｈ通信に関わる機器群の中の１つに制御機能を与えることで通信の秩序を保つようにしている。制御機能を与えられた機器のことを「マスタ（Ｍａｓｔｅｒ）」機器と呼び、それ以外を「スレーブ（Ｓｌａｖｅ）」機器と呼ぶ。また、マスタ及びスレーブとなった機器群が通信状態にあるネットワークのことを「ピコネット（ｐｉｃｏｎｅｔ）」と呼ぶ。
ピコネット内では、「ピコネット内同期」がとられており、通信状態にあるすべてのＢｌｕｅｔｏｏｔｈ機器は、マスタ機器を基準とした同一の周波数ホッピング・パターンと時間スロットを有している状態にある。時間スロットはマスタ機器が提供するＢｌｕｅｔｏｏｔｈクロックを基準として各スレーブ機器が形成する。
ピコネット内には、必ず１つだけマスタ機器が存在し、このマスタ機器が１台以上のスレーブを制御しながら通信を行なう。また、ピコネット内では、すべてのパケットはマスタ機器とスレーブ機器の間でのみ受信され、スレーブ機器どうしが直接通信を行なうことはできない。
そして、１つのピコネット内で同じ通信できるスレーブは最大７台までと決められている。これらにマスタ機器を含めて、最大で８台のＢｌｕｅｔｏｏｔｈ機器がピコネット内で同時通信を行なうことができる。
ここで、オーディオ・ビジュアル（ＡＶ）機器の分野において、Ｂｌｕｅｔｏｏｔｈ通信を導入した場合、ステレオ・コンポやメディア・プレイヤなどのオーディオ・データ・ストリームの出力源となるＳｏｕｒｃｅ装置１１をマスタとして定義する一方で、ヘッドフォンやパーソナル・コンピュータ（ＰＣ）などのオーディオ出力ターゲットとなるＳｉｎｋ装置をスレーブ機器として定義することができる。図１には、このように構成されたＢｌｕｅｔｏｏｔｈピコネット１０内の構成を模式的に示している。
［従来の技術］の欄でも既に述べたように、このようにオーディオ伝送に適用されたＢｌｕｅｔｏｏｔｈワイヤレス・ネットワークがＳＤＭＩ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  Ｍｕｓｉｃ  Ｉｎｔｅｒａｃｔｉｖｅ）に準拠するためには、Ｓｏｕｒｃｅ装置１１からＳｉｎｋ装置１２へ向かう伝送路に対して、”ｕｎｐｒｏｔｅｃｔｅｄ  ｄｉｇｉｔａｌ  ｏｕｔ”を禁止するための仕組み、すなわち、デジタル伝送されるオーディオ・データをプロテクトするための仕組みを装備する必要がある。
デジタル・データをプロテクトする要素としては、「盗み取り（盗み聴き）」対策のための暗号化（ｅｎｃｒｙｐｔｉｏｎ）と、「なりすまし」対策のための認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）の２つに大別される。
本実施形態に係るＢｌｕｅｔｏｏｔｈワイヤレス・ネットワークでは、前者の暗号化に関しては、Ｂｌｅｔｏｏｔｈ層で定義された暗号化方式をそのまま適用するので、本明細書では詳細な説明を省略する。
また、後者の認証方式に関しては、Ｂｌｕｅｔｏｏｔｈ層ではなく、その上位のアプリケーション層で実装する。本実施形態に係る認証方式は、認証に成功した場合に限り通信相手はレンダリング用途でストリームを受ける機器であるとみなして、伝送データのレコーディングが行われることを想定せず、比較的低い強度のプロテクションを以って伝送データをプロテクトするが、その詳細な説明は後述に譲る。
図２には、図１に示したＢｌｕｅｔｏｏｔｈピコネット１０を構成するＳｏｕｒｃｅ装置としてのオーディオ・プレーヤ（マスタ）１１と、Ｓｉｎｋ装置としてのヘッドフォン（スレーブ）１２の構成を模式的に示している。
Ｓｏｕｒｃｅ装置としてのオーディオ・プレーヤ１１は、Ｂｌｕｅｔｏｏｔｈインターフェース・ブロック１１Ａと、信号生成ブロック１１Ｂと、プレーヤ制御ブロック１１Ｃと、システム制御ブロック１１Ｄとで構成され、Ｂｌｕｅｔｏｏｔｈピコネット１０内ではマスターとして機能する。
Ｂｌｕｅｔｏｏｔｈインターフェース・ブロック１１Ａは、ピコネット１０内におけるＢｌｕｅｔｏｏｔｈワイヤレス接続を実現するための機能ブロックであり、ピコネット１０内におけるスレーブ機器１２，１３との制御信号の交換やオーディオ・データの伝送などを行う。
信号生成ブロック１１Ｂは、オーディオ信号を生成するための機能ブロックである。
プレーヤ制御ブロック１１Ｃは、オーディオ・プレーヤ１１上におけるメディアの再生、停止、一時停止、早送り、巻き戻しなどのメディア再生制御機能を実現するための機能ブロックである。
システム制御ブロック１１Ｄは、Ｂｌｕｅｔｏｏｔｈピコネット１０内における各スレーブ機器１２，１３の統合的な制御を実現するための機能ブロックである。本実施形態では、システム制御ブロック１１Ｄは、ＡＶ機器間のオーディオ・データの伝送用のプロファイルである”Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（Ａ２ＤＰ）におけるＳｏｕｒｃｅの機能を管理するようになっている。
Ａ２ＤＰプロファイルは、Ｂｌｕｅｔｏｏｔｈピコネット１０内でのオーディオ伝送のプロテクトも規定している。Ｂｌｕｅｔｏｏｔｈセキュリティは、ある特定の２端末間で「リンク・キー（Ｌｉｎｋ  Ｋｅｙ）」と呼ばれる共通のパラメータを設定することを基本として、マスタと各スレーブ間で１対１のセキュリティが管理される（リンク・キーは第３者には開示されない）。
オーディオ・データをプロテクトする要素としては、「盗み取り（盗み聴き）」対策のための暗号化（ｅｎｃｒｙｐｔｉｏｎ）と、「なりすまし」対策のための認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）という２つに大別される。本実施形態では、暗号化に関しては、Ｂｌｕｅｔｏｏｔｈ層で定義されている暗号化方式を使用する。また、認証方式に関しては、Ａ２ＤＰプロファイルでは規定されていないので、上位のアプリケーション層（後述）において、本発明に固有の認証方式を実装する。本発明に係る認証方式によれば、Ｓｏｕｒｃｅ装置１１は、認証に成功した場合に限り通信相手はレンダリング用途でストリームを受けるＳｉｎｋ機器であるとみなすことができる。この結果、Ｓｏｕｒｃｅ装置側では、Ｓｉｎｋ装置において伝送データのレコーディングが行われることを想定せず、比較的低い強度のプロテクションを以って伝送データを保護することができる。
ヘッドフォン１２は、Ｂｌｕｅｔｏｏｔｈインターフェース・ブロック１２Ａと、ヘッドフォン制御ブロック１２Ｂと、信号処理ブロック１２Ｃとで構成される、レンダリング専用のＳｉｎｋ装置である。
Ｂｌｕｅｔｏｏｔｈインターフェース・ブロック１２Ａは、Ｂｌｕｅｔｏｏｔｈピコネット１０内におけるＢｌｕｅｔｏｏｔｈワイヤレス接続を実現するための機能ブロックであり、マスタ装置としてのオーディオ・プレーヤ１１との制御信号の交換、並びにオーディオ・データの受信などを行う。
ヘッドフォン制御ブロック１２Ｂは、ボリューム・アップ、ボリューム・ダウン、ミュートなどヘッドフォン１２による音声出力機能を実現するための機能ブロックである。
信号処理ブロック１２Ｃは、Ｂｌｕｅｔｏｏｔｈワイヤレス通信によりマスター装置１１から受信されたオーディオ信号を処理する機能ブロックである。
本実施形態では、ヘッドフォン１２は、従来のオーディオ伝送用のプロファイル”Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（Ａ２ＤＰ）に対応した従来と同様のスレーブ装置として構成することができる。
図３には、オーディオ伝送用のプロファイル”Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（Ａ２ＤＰ）のプロファイル・スタック構造を模式的に図解している。
同図において、ベースバンド層、ＬＭＰ層、Ｌ２ＣＡＰ層、ＳＤＰ層、及び、ＡＶＤＴＰ層の各層は、Ｂｌｕｅｔｏｏｔｈコアで定義されたＢｌｕｅｔｏｏｔｈプロトコルである。このうちベースバンド層、ＬＭＰ層、Ｌ２ＣＡＰ層は、ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔ：開放型システム間相互接続）基本参照モデルの第１層及び第２層に相当する。
ＳＤＰ層は、Ｂｌｕｅｔｏｏｔｈサービス・ディスカバリ・プロトコル（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）を規定するプロトコル層である。システム・コントローラとしてのマスタ装置１１は、このＳＤＰプロトコルを用いて、同じＢｌｕｅｔｏｏｔｈピコネット１０内のスレーブ機器１２，１３が備える機能又はサービスを検出することができる。
ＡＶＤＴＰ（Ａｕｄｉｏ／Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）層は、Ｂｌｕｅｔｏｏｔｈピコネット１０内におけるオーディオ伝送の処理手順やメッセージ交換を規定するプロトコル層であり、データ・ストリームのパラメータのネゴシエーションを行うシグナリング・エンティティと、データ・ストリーム自体を取り扱うトランスポート・エンティティとからなる。
Ａ２ＤＰでは、Ｂｌｕｅｔｏｏｔｈベースバンド層での暗号化をオプショナルとして実装することが可能である。Ａ２ＤＰでは、プロテクションに関して規定はしない。暗号化方式及び認証方式に関しては、Ａ２ＤＰの各プロテクション方式毎に定める。
アプリケーション層は、Ｓｏｕｒｃｅ装置１１又はＳｉｎｋ装置１２においてアプリケーション・サービスやトランスポート・サービスの各パラメータを設定するエンティティで構成される。アプリケーション層は、オーディオ・ストリーム・データを規定のパケット・フォーマットに適合させる処理も行なう。
本実施形態では、アプリケーション層は、Ｂｌｕｅｔｏｏｔｈピコネット１０内におけるオーディオ伝送のための認証方式も実装する。この認証方式によれば、Ｓｏｕｒｃｅ装置１１は、認証に成功した場合に限り通信相手はレンダリング用途でストリームを受けるＳｉｎｋ機器であるとみなすことができる。この結果、Ｓｏｕｒｃｅ装置１１は、Ｓｉｎｋ装置側で伝送データのレコーディングが行われることを想定せず、比較的低い強度のプロテクションを以って伝送データを保護することができる。
図３に示したプロファイル・スタック上では、Ｂｌｕｅｔｏｏｔｈピコネット１０内のＳｏｕｒｃｅ装置１１とＳｉｎｋ装置１２，１３間でのオーディオ伝送における設定、制御、操作を行なうことができる。但し、このプロファイル・スタックでは、１対多のデータ配信を行なうことはできない。
また、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２，１３間でのオーディオ伝送には、無線信号処理や、データ・ストリームのバッファリングや符号化／復号化のためにある程度の遅延が存在する。
また、このプロファイル・スタックを実装するためには、オーディオ・データの伝送レートは、Ｂｌｕｅｔｏｏｔｈリンク上で使用可能なビット・レートよりも充分小さくなければならない。これは、聴覚可能なノイズや音飛びの原因となるパケット消失の影響をなくすためのパケット再伝送を行なうためである。
Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにおけるオーディオ伝送を行うためのプロトコルであるＡＶＤＴＰは、「シグナリング」と「ストリーミング」という２つの機能に大別される。
ストリーミングは、オーディオ信号をリアルタイム伝送することを規定する。また、シグナリングは、Ｓｏｕｒｃｅ装置から送信されたオーディオ・ストリームをＳｉｎｋ装置側で受信処理できるように、フォーマットなどのネゴシエーションを行う。このネゴシエーション・パラメータの１つとして、コンテンツ・プロテクション（Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ：ＣＰ）のタイプがある。
Ｂｌｕｅｔｏｏｔｈ  ＡＶ伝送に適用するプロテクション方式はあらかじめＢｌｕｅｔｏｏｔｈ  ＳＩＧに登録しておき、Ｂｌｕｅｔｏｏｔｈ  ＳＩＧ側では各プロテクション方式に対して識別情報（ＩＤ）を割り振る。このＩＤについては、”Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ”で参照することができる。勿論、登録されたプロテクション方式の内容については、Ｂｌｕｅｔｏｏｔｈの仕様書には何ら記述されない。例えば、本発明に係るコンテンツ・プロテクション方式も、Ｂｌｕｅｔｏｏｔｈ  ＳＩＧの管轄外でライセンスすることにより、規制を設けることもできる。
ＡＶＤＴＰプロトコルでは、接続確立手続（Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）において、”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”コマンドを用いて、Ｓｏｕｒｃｅ装置はオーディオ伝送先となるＳｉｎｋ装置が対応しているプロテクション方式を調べる。また、Ｓｏｕｒｃｅ装置は、”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”コマンドによりＩＤを指定することにより、適用するプロテクション方式をＳｉｎｋ装置に設定する（ＡＶＤＴＰプロトコルでは、コンテンツのプロテクション方式のＩＤは、Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓに登録されるので、一義に決まる）。
図４には、ＡＶＤＴＰプロトコルにおける接続確立手続（Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）のシーケンスを示している。ＡＶＤＴＰプロトコルではＢｌｕｅｔｏｏｔｈデバイスのＳｔｒｅａｍ入出力口としてＳｔｒｅａｍ  Ｅｎｄ  Ｐｏｉｎｔを規定している。Ｓｏｕｒｃｅ装置は、”Ｓｔｒｅａｍ  Ｅｎｄ  Ｐｏｉｎｔ  Ｄｉｓｃｏｖｅｒｙ”コマンドを用いて、Ｓｉｎｋ装置が何系統のストリームに対応しているか、及び、それぞれに対応しているストリーム・タイプ（オーディオかビデオか）について調べる。次いで、Ｓｏｕｒｃｅ装置は、”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”を用いて、オーディオ伝送先となるＳｉｎｋ装置が対応しているプロテクション方式を調べる。その後、ＳＯｕｒｃｅ装置がＯｐｅｎコマンドをＳｉｎｋ装置に送ることにより、Ｓｏｕｒｃｅ装置とＳｉｎｋ装置はともに「オープン」状態になる。
Ｂｌｕｅｔｏｏｔｈオーディオ伝送において適用するプロテクション方式に応じてその後の処理方法は異なるが、本実施形態では、アプリケーション層において、ＡＶＤＴＰプロトコルで定義されている”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを用いてＳｉｎｋ装置の認証を行なうことによってプロテクションを行なう（”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドのパラメータは、各プロテクション方式毎に定義することができる）。
図５には、ＡＶＤＴＰプロトコルで定義されているＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ手続のシーケンスを示している。図示の通り、オープン状態又はストリーミング状態で”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドの処理が行なわれる。この処理によってＢｌｕｅｔｏｏｔｈ伝送のステートの変化は生じない。
本実施形態では、Ｓｏｕｒｃｅ装置１１は、認証に成功した場合に限り通信相手はレンダリング用途でストリームを受けるＳｉｎｋ機器であるとみなすことによって、Ｓｉｎｋ装置において伝送データのレンダリングのみが行なわれる（言い換えれば、レコーディングは行なわれない）ことを想定したオーディオ伝送を行なうが、その詳細については後述に譲る。
ストリーミングに関しては、オーディオ伝送のためのプロファイルである”Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（Ａ２ＤＰ）に記されている。図６には、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにおけるオーディオ・ストリーミングの流れとパケット・フォーマットを模式的に示している。
オーディオ・コンテンツのストリーミングを開始したいときには、まず、ストリーミング・コネクションのセットアップを行う。このセットアップ処理手続の間、各装置間でオーディオ・ストリーミングのための適切なパラメータを選択する。アプリケーション・サービス・ケイパビリティと、トランスポート・サービス・ケイパビリティという２種類のサービスが構成される。Ａ２ＤＰプロファイルでは、シグナリング処理手続に必要なオーディオ仕様パラメータを規定している。
Ａ２ＤＰのアプリケーション・サービス・ケイパビリティは、オーディオＣＯＤＥＣケイパビリティとコンテンツ・プロテクション・ケイパビリティとで構成される。
また、トランスポート・サービス・ケイパビリティは、ストリーミング・パケットを好適に取り扱うことができるように、ＡＶＤＴＰプロトコルで提供されているサービスを選択する。
ストリーミング接続が確立すると、ストリーミング開始処理手続が実行される。ＡＶＤＴＰプロトコルを用いてストリーミング伝送を行なう際の処理手続については、”Ｇｅｎｅｒｉｃ  Ａｕｄｉｏ／Ｖｉｄｅｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（ＧＡＶＤＰ）で規定されている。
Ｓｏｕｒｃｅ装置とＳｉｎｋ装置はともに「ストリーミング状態」になり、オーディオ・ストリームの送受信を即座に行なうことができる。Ｓｏｕｒｃｅ装置は”Ｓｅｎｄ  Ａｕｄｉｏ  Ｓｔｒｅａｍ”処理手続を用いてオーディオ・データの送信を行ない、これに対し、Ｓｉｎｋ装置は”Ｒｅｃｅｉｖｅ  Ａｕｄｉｏ  Ｓｔｒｅａｍ”処理手続を用いてオーディオ・データの受信を行なう。
「オープン状態」にあるときに、Ｓｏｕｒｃｅ装置又はＳｉｎｋ装置がオーディオ・ストリームの送受信を開始したいときには、ＧＡＶＤＰで定義されているストリーミング開始（Ｓｔａｒｔ  Ｓｔｒｅａｍｉｎｇ）処理手続を開始しなければならない。
”Ｓｅｎｄ  Ａｕｄｉｏ  Ｓｔｒｅａｍ”処理手続では、Ｓｏｕｒｃｅ装置は、シグナリング・セッションで、伝送データを選択されたフォーマットに符号化する。Ｓｏｕｒｃｅ装置のアプリケーション層では、符号化データを定義されたメディア・ペイロード（ＭＰ）フォーマットに適合させる。コンテンツ・プロテクション（ＣＰ）を利用する場合には、コンテンツ・プロテクション方式に依存したＣＰヘッダを、暗号化されたオーディオ・コンテンツの先頭に付加する。
その後、ストリーム・データは、インターフェース経由でＡＶＤＴＰ層で処理され、ＡＶＤＴＰプロトコルで定義されるトランスポート・サービスを用いて、トランスポート・チャンネルから送出される。
一方、Ｓｉｎｋ装置側のＡＶＤＴＰ層は、ＡＶＤＴＰプロトコルで定義されるトランスポート・サービスを用いて、トランスポート・チャンネルから受信して、インターフェース経由でアプリケーション層に受信ストリームを渡す。
コンテンツ・プロテクション方式が作動している場合、Ｓｉｎｋ装置側のアプリケーション層は、ＣＰヘッダの解析や暗号化コンテンツの解読を行なう。そして、オーディオ・データ・フレームは、所定のコーディング方式により復号化されて、オーディオ出力（レンダリング）などに利用される。
図７には、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間でのＧＡＶＤＰに従ってストリーミングのセットアップと解放を行うためのＳｏｕｒｃｅ装置とＳｉｎｋ装置間での処理の流れを詳細に示している。但し、同図中で”＊”が付されたものは”Ｇｅｎｅｒｉｃ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ”（ＧＡＰ）で規定されている処理手続であり、また、”＊＊”が付されたものは”Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ”（ＳＤＰ）で定義されている処理手続であると理解されたい。ＧＡＰ及びＳＤＰは、Ｂｌｕｅｔｏｏｔｈの共通基本機能である。
まず、Ｂｌｕｅｔｏｏｔｈピコネット１０内のマスタでもあるＳｏｕｒｃｅ装置１１は、該ピコネット１０内にどのようなスレーブが存在するかを調べるために、Ｉｎｑｕｉｒｙ（問合せ）を行なうためのＩＱパケットをピコネット１０内でブロードキャストする。
Ｉｎｑｕｉｒｙを受信したスレーブとしてのＳｉｎｋ装置１２は、自身のＢｌｕｅｔｏｏｔｈアドレス（ＢＤ＿ＡＤＤＲ）やクロックの情報、機種の属性（Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ）を通知するためのＦＨＳパケットを返信する。
Ｓｏｕｒｃｅ装置１１は、ピコネット内の各スレーブから受信したＦＨＳパケットのデータを基に、どのスレーブと接続するかを選択する。ここでは、説明の便宜上、Ｓｉｎｋ装置１２を選択したものとする。
Ｎａｍｅ  Ｄｉｓｃｏｖｅｒｙ処理手続では、マスタとしてのＳｏｕｒｃｅ装置１１は、Ｐａｇｅ（呼び出し送信）により、スレーブとしてのＳｉｎｋ装置１２に宛てて、マスタの属性を通知して、マスタ及びスレーブ間で１対１の処理を経て通信フェーズに遷移する。そして、Ｎａｍｅ  Ｒｅｑｕｅｓｔにより、接続相手のＢｌｕｅｔｏｏｔｈ  Ｄｅｖｉｃｅ  Ｎａｍｅを取得する。
次いで、リンク確立（Ｌｉｎｋ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）処理手続では、ＢｌｕｅｔｏｏｔｈデバイスとしてのＳｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間の物理リンクを構築する。このリンク確立処理手続の中には、Ｂｌｕｅｔｏｏｔｈベースバンド層（図３を参照のこと）における認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）や暗号化のネゴシエーションも含まれる。但し、Ｂｌｕｅｔｏｏｔｈセキュリティは誤接続防止、盗聴防止を目的としているので、本発明に係る認証方式とは相違する、という点を充分理解されたい。
次いで、サービス・ディスカバリ（Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）、すなわち、スレーブが備える機能又はサービスを検出するために、ＳＤＰ用のＬ２ＣＡＰチャンネル（論理リンク・チャンネル）を張り、ＳＤＰプロトコルによりＳｉｎｋ装置１２がどのようなサービスに対応しているか（すなわち、Ｓｉｎｋ装置１２が対応しているプロトコル、プロファイルなどの情報）を知る。
そして、ＳＤＰ用のＬ２ＣＡＰチャンネルを解放してから、ＡＶＤＴＰシグナリングのためのＬ２ＣＡＰチャンネルを張る。既に述べたように、接続確立（Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）処理手続の中で、オーディオＣＯＤＥＣ、サンプリング周波数などの情報を基に、コンテンツ・プロテクション方式に関する情報の開示及び設定が行なわれる。
本実施形態では、Ｓｏｕｒｃｅ装置１１は、ＡＶＤＴＰプロトコルにおける接続確立手続（Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）において（図４を参照のこと）、”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”コマンドによりＩＤを指定することにより、適用するプロテクション方式をＳｉｎｋ装置１２に設定する。また、ＡＶＤＴＰプロトコルで定義されている”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを用いて（図５を参照のこと）、Ｓｉｎｋ装置１２のタイプ（すなわち、レンダリング用途でストリームを受ける機器であるか、又は、レコーディング用途でストリームを受ける機器か）を認証する。ヘッドフォンであるＳｉｎｋ装置１２は自分自身がレンダリング用途の機器であることを提示することによって、Ｓｏｕｒｃｅ装置１１側では、Ｓｉｎｋ装置１２においてレンダリング用途で伝送データ・ストリームを受けることを想定した認証方式が採用される。
認証に成功して、Ｓｉｎｋ装置１２がレンダリング用途の機器であることが明らかになった場合には、ＧＡＶＤＰで定義されているストリーミング開始（Ｓｔａｒｔ  Ｓｔｒｅａｍｉｎｇ）処理手続を経て、オーディオ・ストリームの伝送が行なわれる。図８には、認証に成功したときのシーケンスを示している。同図に示すように、オープン状態において、Ｓｏｕｒｃｅ装置は、内部イベントの発生に応答して”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを発行して認証を行ない、これに成功すると、内部的なストリーミングの開始に応じて”Ｓｔａｒｔ  Ｓｔｒｅａｍｉｎｇ”コマンドを発行して、Ｓｉｎｋ装置へのストリーミング伝送を行なう。
一方、認証に失敗した場合には、Ｓｏｕｒｃｅ装置１１側ではアプリケーション層に通知され、オーディオ・ストリームの伝送は行なわれない。図９には、認証に失敗したときのシーケンスを示している。同図に示すように、オープン状態において、Ｓｏｕｒｃｅ装置は、内部イベントの発生に応答して”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを発行して認証を行ない、これに失敗すると内部的な接続解放に応答して、”Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｌｅａｓｅ”コマンドを発行してＳｉｎｋ装置との接続を切断して、アイドル状態に遷移する。
図１０には、本実施形態に係るＢｌｕｅｔｏｏｔｈピコネット１０において、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間で行われる認証の処理手順の概念を図解している。
Ｓｏｕｒｃｅ装置１１で発生した乱数ｘは、制御信号の一種としてＳｉｎｋ装置１２に伝送される。同図に示す例では、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２はともに、ｆ（ｘ）で示される認証アルゴリズムを共有しており、Ｓｉｎｋ装置１２は受け取った入力ｘに対して演算を実行して、その演算結果ｆ’（ｘ）をＳｏｕｒｃｅ装置１１に制御信号の一種として送信する。そして、Ｓｏｕｒｃｅ装置１１は、乱数ｘから自分自身で算出した結果ｆ（ｘ）とＳｉｎｋ装置１２から受信した演算結果ｆ’（ｘ）とを比較して、これらが一致するか否かで認証の判断を行なう。
本実施形態に係る認証方式の特徴は、Ｓｏｕｒｃｅ装置１１は、認証の対象とするＳｉｎｋ装置１２のタイプによって演算方式ｆ（ｘ）を切り替えるという点にある。ここで言うＳｉｎｋ装置のタイプは、該装置がヘッドフォンなどの処理能力の低い機器か（Ｔｙｐｅ１）、又は、パーソナル・コンピュータ（ＰＣ）などの処理能力の高い機器か（Ｔｙｐｅ２）で区分される。
例えば、通信相手となるＳｉｎｋ装置がヘッドフォン１２のように処理能力の低い機器の場合には、Ｓｏｕｒｃｅ装置１１は、発生する乱数ｘを８ビットにするとともに、演算ｆ（ｘ）をビットシフトなどの簡単な演算方式にする。ヘッドフォンのように処理能力の低い機器すなわちＴｙｐｅ１の場合、一般に、比較的低い処理能力のＣＰＵが搭載されているので、あまり強度の高くＣＰＵの処理負荷の高い認証処理を行なうのには向いていない。
これに対し、通信相手となるＳｉｎｋ装置がパーソナル・コンピュータ（ＰＣ）１３のように、比較的高い処理能力のＣＰＵが搭載されている装置の場合には、上述したような簡単な演算方式では、容易に「なりすまし」が行なわれて、コンテンツを充分にプロテクトすることができない。したがって、Ｓｉｎｋ装置がＴｙｐｅ２の場合には、Ｓｏｕｒｃｅ装置１１は、発生する乱数ｘを６４ビット又は１２８ビットなどの長いものにするとともに、演算ｆ（ｘ）を楕円関数などの比較的複雑なものを採用する。
なお、認証の演算として、ここでは乱数を入力して演算を行なう例を挙げたが、乱数だけではなく、例えばＳｉｎｋ装置のＢｌｕｅｔｏｏｔｈアドレス（ＢＤ＿ＡＤＤＲ）など装置固有のデータを用いることにより、認証の強度をさらに向上させることができる。
上述したように通信相手となるＳｉｎｋ装置の用途に応じて認証方式を切り換える場合において、最も重要となるのは、Ｓｉｎｋ装置のタイプの判別方法である。例えば、本発明に係る認証方式には非対応（すなわち、ライセンスでの規制範囲外）のパーソナル・コンピュータが「ヘッドフォンである」となりすまして、不正にストリーム・データを記録してしまうような事態を防止しなければならない。
なお、認証演算による負荷が重たい機器（例えば、ＰＣのように高い演算機能を持つ機器）は基本的にＴｙｐｅ２を採用する。本発明に係る認証方式では、逆にＴｙｐｅ１の対象機器を絞り込む。
Ｓｉｎｋ装置のタイプ（Ｔｙｐｅ１，Ｔｙｐｅ２）の判別方法について、以下に詳解する。
（１）自己申告
Ｓｏｕｒｃｅ機器から”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”コマンドを受け取ったＳｉｎｋ装置は、本実施形態に係るコンテンツ・プロテクション方式に対応していることをＣＰ−ＴＹＰＥで示す。”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”のコマンド及びレスポンスに使用されるデータ・フレームの構造を図１１及び図１２にそれぞれ示しておく。
本実施形態に係るコンテンツ・プロテクション方式に対応しているＳｏｕｒｃｅ装置は、Ｓｉｎｋ装置に対して、”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”コマンドを送り、本プロテクション方式を適用するようにセットする。”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”のコマンド及びレスポンスに使用されるデータ・フレームの構造を図１３に示しておく。
次いで、Ｓｏｕｒｃｅ装置は、”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを用いて、Ｓｉｎｋ装置に対してタイプを問い合わせる。”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”のコマンド及びレスポンスに使用されるデータ・フレームの構造を図１４及び図１５にそれぞれ示しておく。また、タイプ問い合わせ時のこれらコマンド及びレスポンスにおける”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を図１６及び図１７にそれぞれ示しておく。
”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドのフィールド長は、コマンド・レスポンス種別により可変長とするが、タイプ問い合わせコマンドの場合は１バイトとし、４ビットでコマンド・レスポンスの種別を示すとともに、４ビットでパラメータを示す。また、タイプ問い合わせコマンドでは、レスポンスの際に４ビットでタイプを示す。Ｔｙｐｅ１の場合は”０００１”となり、Ｔｙｐｅ２の場合は”００１０”となる。
（２）Ｔｙｐｅ１の確認
Ｓｉｎｋ装置がＴｙｐｅ２を自己申告した場合には、Ｔｙｐｅ２に適合した方式で認証が行なわれる。また、Ｓｉｎｋ装置がＴｙｐｅ１及びＴｙｐｅ２以外の値を返してきた場合には、そこで認証は失敗とする。また、Ｓｉｎｋ装置がＴｙｐｅ１を自己申告した場合は、さらにその確認のために以下の処理手順を実行する。
（２−１）Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ
Ｓｏｕｒｃｅ装置は、Ｉｎｑｕｉｒｙ処理手続の際に、Ｓｉｎｋ装置のＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅを入手するので（図７を参照のこと）、ここではＳｉｎｋ装置のＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報を基にＳｉｎｋ装置のタイプの確認を行なうことができる。”Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ”に規定されているように、各Ｂｌｕｅｔｏｏｔｈ機器は自分が何者であるかを、”Ｍａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓ”及び”Ｍｉｎｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓ”で示すようになっている。Ｓｉｎｋ装置のＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”の場合は、このＳｉｎｋ装置はＴｙｐｅ２による認証の対象であり、Ｔｙｐｅ１であることを自己申告したということは「なりすまし」であると解釈する。すなわち、Ｓｉｎｋ装置のＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”の場合は、認証はここで失敗とする。
図１８には、Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報フィールドのデータ構造を模式的に示している。同図に示すように、当該フィールドの先頭から１２ビット目からの５ビットがＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓに割り当てられている。また、Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓが規定するＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓの割り当てを図１９に示しておく。
（２−２）プロファイル
Ｍａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”でなくても、高機能な装置であれば、簡単な認証方式であるＴｙｐｅ１の対象とはならない。そこで、Ｓｏｕｒｃｅ装置は、Ｓｉｎｋ装置がオーディオ伝送以外にサポートしているＢｌｕｅｔｏｏｔｈアプリケーション・プロファイルがあるかどうかを調べる。ＳＤＰによりＢｌｕｅｔｏｏｔｈ機器のサポート・プロファイルを知ることができる。
Ｓｉｎｋ装置がＡ２ＤＰ以外のプロファイルをサポートしていない場合には、このＳｉｎｋ装置をＴｙｐｅ１すなわちレンダリング用途としての認証の対象であると認定する。
また、Ｓｉｎｋ装置がこれら以外のプロファイルに対応している場合には、対応しているプロファイルを基に判断する。Ｓｉｎｋ装置が、”Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ”（ＰＡＮ）、”ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ”（ＬＡＮ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒのいずれかのプロファイルをサポートしている場合には、このＳｉｎｋ装置をＴｙｐｅ２としての認証の対象であると認定して、認証はここで失敗とする。
（３）認証
Ｓｏｕｒｃｅ装置は、Ｓｉｎｋ装置がＴｙｐｅ１又はＴｙｐｅ２のいずれであるかの認証を、”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを用いて行う。認証時における該コマンドのコマンド及びレスポンスにおける”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を図２０及び図２１にそれぞれ示しておく。
図２２及び図２３には、Ｓｏｕｒｃｅ装置１１がＳｉｎｋ装置１２のタイプ判別を行うことにより認証を行なうための処理手順をフローチャートの形式で示している。以下、これらのフローチャートに従って、本実施形態に係る認証処理について説明する。
Ｓｏｕｒｃｅ装置１１は、Ｓｉｎｋ装置１２とはＢｌｕｅｔｏｏｔｈベースバンド層において接続が確立され、呼び出し（Ｐａｇｅ）によりＳｉｎｋ装置の装置種別（Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ）を取得しているとともに、ＳＤＰプロトコルによりＳｉｎｋ装置がサポートしているサービス（対応しているプロトコルやプロファイル）を取得しているものとする。
Ｓｏｕｒｃｅ装置１１は、ＡＶＤＴＰプロトコルに従い、Ｓｉｎｋ装置１２に”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”コマンドを送信して、そのレスポンスのＣＰ＿ＴＹＰＥが示す値を基に、Ｓｉｎｋ装置１２が本発明に係るコンテンツ・プロテクション方式に対応するか否かを判別する（ステップＳ１）。
ＣＰ＿ＴＹＰＥを基に、Ｓｉｎｋ装置１２が本プロテクション方式に対応していない場合には、本処理ルーチン全体を終了する。
一方、Ｓｉｎｋ装置１２が本プロテクション方式に対応していると判断された場合には、Ｓｏｕｒｃｅ装置１１は、Ｓｉｎｋ装置１２に対して、”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”コマンドを送り、本プロテクション方式を適用するようにセットする（ステップＳ２）。ここまでの手続は、ＡＶＤＴＰプロトコルに従って行なうことができる。
次いで、Ｓｏｕｒｃｅ装置１１のアプリケーション層は、”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドを用いて、Ｓｉｎｋ装置１２に対してタイプを問い合わせる（ステップＳ３）。ここで行なわれるタイプ問い合わせすなわち認証処理は、Ｓｉｎｋ装置１２からの自己申告に基づく。ここで言うＳｉｎｋ装置１２のタイプは、該装置がヘッドフォンなどの処理能力の低いか（Ｔｙｐｅ１）、又は、パーソナル・コンピュータ（ＰＣ）などの処理能力の高い機器か（Ｔｙｐｅ２）で区分される。
Ｓｉｎｋ装置１２がＴｙｐｅ１以外の値を返してきた場合には（ステップＳ４）、さらに、Ｓｉｎｋ装置１２がＴｙｐｅ２を自己申告したか否かを判別する（ステップＳ５）。
Ｓｉｎｋ装置１２がＴｙｐｅ２を自己申告した場合には（ステップＳ５）、本処理ルーチン全体を終了して、以後、Ｔｙｐｅ２に適合した方式で認証が行われる（ステップＳ６）。Ｔｙｐｅ２に適合した認証方式とは、例えば、図１０に示す認証メカニズムにおいて、Ｓｏｕｒｃｅ装置１１が、発生する乱数ｘを６４ビット又は１２８ビットなどの長いものにするとともに、演算ｆ（ｘ）を楕円関数などの比較的複雑なものを採用することによって実現される。
Ｔｙｐｅ２に適合した認証に成功した場合には（ステップＳ７）、本処理ルーチンは成功裏に終了する。これに対し、Ｔｙｐｅ２認証に失敗した場合には、認証は失敗として、本処理ルーチン全体を終了する。また、Ｓｉｎｋ装置１２がＴｙｐｅ２以外の値を返してきた場合には（ステップＳ５）、そこで認証は失敗として、本処理ルーチン全体を終了する。
また、Ｓｉｎｋ装置１２がＴｙｐｅ１を自己申告した場合には（ステップＳ４）、さらに、Ｓｉｎｋ装置１２の装置種別（Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ）を確認する（ステップＳ８）。Ｓｉｎｋ装置１２のＣｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅは、Ｎａｍｅ  Ｄｉｓｃｏｖｅｒｙ処理手続時に行われる呼び出し（Ｐａｇｅ）によって既に取得されている。
Ｓｉｎｋ装置１２のＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”の場合は、このＳｉｎｋ装置１２はＴｙｐｅ２による認証の対象であり、Ｔｙｐｅ１であることを自己申告したということは「なりすまし」であると解釈する（ステップＳ８）。すなわち、Ｓｉｎｋ装置のＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”の場合は、認証はここで失敗とする。
他方、Ｍａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓが”Ｃｏｍｐｕｔｅｒ”でなくても、高機能な装置であれば、簡単な認証方式であるＴｙｐｅ１の対象とはならない。そこで、Ｓｏｕｒｃｅ装置１１は、Ｓｉｎｋ装置１２がオーディオ伝送以外にサポートしているＢｌｕｅｔｏｏｔｈアプリケーション・プロファイルがあるかどうかを調べる（ステップＳ１２）。
Ｓｉｎｋ装置１２がＡ２ＤＰ以外のプロファイルをサポートしていない場合には、このＳｉｎｋ装置１２をＴｙｐｅ１の認証の対象であると認定して、Ｔｙｐｅ１に適合した方式で認証を行う（ステップＳ１０）。Ｔｙｐｅ１に適合した認証方式とは、例えば、図１０に示す認証メカニズムにおいて、Ｓｏｕｒｃｅ装置が、発生する乱数ｘを８ビットにするとともに、演算ｆ（ｘ）にビットシフトなどの比較的簡単なものを採用することによって実現される。Ｔｙｐｅ１に適合した認証に成功した場合には（ステップＳ１１）、本処理ルーチンは成功裏に終了する。これに対し、Ｔｙｐｅ１認証に失敗した場合には、認証は失敗として、本処理ルーチン全体を終了する。
また、Ｓｉｎｋ装置１２がＡ２ＤＰ以外のプロファイルをサポートしている場合には、さらに、Ｓｉｎｋ装置１２が、”Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ”（ＰＡＮ）、”ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ”（ＬＡＮ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ  Ｐｒｏｆｉｌｅ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｆｉｌｅのいずれかをサポートしているか否かを判別する（ステップＳ８）。
Ｓｉｎｋ装置１２が、”Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ”（ＰＡＮ）、”ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ”（ＬＡＮ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ  Ｐｒｏｆｉｌｅ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｆｉｌｅのいずれかをサポートしている場合には（ステップＳ９）、このＳｉｎｋ装置１２をＴｙｐｅ２の認証の対象であると認定して、認証はここで失敗とする。
他方、Ｓｉｎｋ装置１２が、”Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ”（ＰＡＮ）、”ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ”（ＬＡＮ）、Ｏｂｊｅｃｔ  Ｐｕｓｈ  Ｐｒｏｆｉｌｅ、又は、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｆｉｌｅのいずれもサポートしていない場合には（ステップＳ９）、このＳｉｎｋ装置１２をＴｙｐｅ１の認証の対象であると認定して、Ｔｙｐｅ１に適合した方式で認証を行い、本処理ルーチン全体を終了する（同上）。
なお、ＳＤＰのＢｌｕｅｔｏｏｔｈ  Ｐｒｏｆｉｌｅ  Ｄｅｓｃｒｉｐｔｏｒ  Ｌｉｓｔにはその機器が対応しているプロファイルが列挙されている。そして、Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓで各プロファイルにＵＵＩＤが割り振られている。図２４には、ＵＵＩＤの例（抜粋）を示している。上述したステップＳ９及びＳ１２では、このＢｌｕｅｔｏｏｔｈ  Ｐｒｏｆｉｌｅ  Ｄｅｓｃｒｉｐｔｏｒ  ＬｉｓｔのＵＵＩＤを参照することによって、機器がサポートしているプロファイルを判断することができる。
追補
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本明細書では、本発明をＢｌｕｅｔｏｏｔｈワイヤレス・ネットワークに適用した場合を例にとって説明してきたが、本発明の要旨は必ずしもこれに限定されるものではなく、同様の機器情報、サービス情報を取り扱う他の有線及び無線伝送システムにおいても本発明を適用することができる。
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
［産業上の利用可能性］
本発明によれば、所定の通信セル内でワイヤレス接続された機器間でオーディオ・データを好適に伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することができる。
また、本発明によれば、Ｂｌｕｅｔｏｏｔｈのように１台のマスタ（ｍａｓｔｅｒ）機器と複数台のスレーブ（ｓｌａｖｅ）機器によって構成されるピコネット（ｐｉｃｏｎｅｔ）内において機器間でオーディオ・データを好適に伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することができる。
また、本発明によれば、オーディオ・データなどのデジタル・データに所定のプロテクションを施しながらＢｌｕｅｔｏｏｔｈ機器間で伝送することができる、優れた無線通信システム、無線通信制御装置及び無線通信制御方法、記憶媒体、並びにコンピュータ・プログラムを提供することができる。
本発明によれば、オーディオ・データなどプロテクションを施す必要があるデータをＢｌｕｅｔｏｏｔｈ接続により伝送する場合、通信相手となる機器の処理能力に応じて認証の難易度を切り替えることができ、Ｂｌｕｅｔｏｏｔｈによるセキュアなオーディオ伝送を実現することができる。したがって、ヘッドフォンのような低い処理能力の機器であっても、ＳＤＭＩに準拠したＢｌｕｅｔｏｏｔｈ通信を行なうことができる。また、通信相手がパーソナル・コンピュータのように高い処理能力を持つ機器に対しては、充分なハッキング対策を施すことができる。
【図面の簡単な説明】
図１は、本発明の一実施形態に係るＢｌｕｅｔｏｏｔｈピコネット１０内の構成を模式的に示した図である。
図２は、図１に示したＢｌｕｅｔｏｏｔｈピコネット１０を構成するＳｏｕｒｃｅ装置としてのオーディオ・プレーヤ（マスタ）１１と、Ｓｉｎｋ装置としてのヘッドフォン（スレーブ）１２の構成を模式的に示した図である。
図３は、オーディオ伝送用のプロファイル”Ｂｌｕｅｔｏｏｔｈ  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｐｒｏｆｉｌｅ”（Ａ２ＤＰ）のプロファイル・スタック構造を模式的に示した図である。
図４は、ＡＶＤＴＰプロトコルにおける接続確立手続（Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ）のシーケンスを示した図である。
図５は、ＡＶＤＴＰプロトコルで定義されているＳｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ手続のシーケンスを示した図である。
図６は、Ｂｌｕｅｔｏｏｔｈワイヤレス・ネットワークにおけるオーディオ・ストリーミングの流れとパケット・フォーマットを模式的に示した図である。
図７は、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間でのＧＡＶＤＰに従ってストリーミングのセットアップと解放を行うためのＳｏｕｒｃｅ装置とＳｉｎｋ装置間での処理の流れを示した図である。
図８は、ＡＶＤＴＰプロトコルで定義されている認証手続きに成功した場合にシーケンスを示した図である。
図９は、ＡＶＤＴＰプロトコルで定義されている認証手続きに失敗した場合にシーケンスを示した図である。
図１０は、本実施形態に係るＢｌｕｅｔｏｏｔｈピコネット１０において、Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間で行われる認証の処理手順の概念を示したブロック図である。
図１１は、”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”のコマンドに使用されるデータ・フレームの構造を示した図である。
図１２は、”Ｓｔｒｅａｍ  Ｇｅｔ  Ｃａｐａｂｉｌｉｔｙ”コマンドに対するレスポンスに使用されるデータ・フレームの構造を示した図である。
図１３は、”Ｓｔｒｅａｍ  Ｓｅｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”のコマンド及びレスポンスに使用されるデータ・フレームの構造を示した図である。
図１４は、”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドに使用されるデータ・フレームの構造を示した図である。
図１５は、”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドに対するレスポンスに使用されるデータ・フレームの構造を示した図である。
図１６は、タイプ問い合わせ時の”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドの”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を示した図である。
図１７は、タイプ問い合わせ時の”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドに対するレスポンスの”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を示した図である。
図１８は、Ｃｌａｓｓ  ｏｆ  Ｄｅｖｉｃｅ情報フィールドのデータ構造を模式的に示した図である。
図１９は、Ｂｌｕｅｔｏｏｔｈ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓが規定するＭａｊｏｒ  Ｄｅｖｉｃｅ  Ｃｌａｓｓの割り当てを示した図である。
図２０は、認証時の”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドの”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を示した図である。
図２１は、認証時の”Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｒｏｌ”コマンドに対するレスポンスの”Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  Ｄｅｐｅｎｄｅｎｔ”フィールドの構成を示した図である。
図２２は、Ｓｏｕｒｃｅ装置がＳｉｎｋ装置のタイプ判別を行うことにより認証を行うための処理手順（前半）を示したフローチャートである。
図２３は、Ｓｏｕｒｃｅ装置がＳｉｎｋ装置のタイプ判別を行うことにより認証を行うための処理手順（後半）を示したフローチャートである。
図２４は、ＵＵＩＤの例（抜粋）を示した図である。
【図１】
2003013068.tif 000003
【図２】
2003013068.tif 000004
【図３】
2003013068.tif 000005
【図４】
2003013068.tif 000006
【図５】
2003013068.tif 000007
【図６】
2003013068.tif 000008
【図７】
2003013068.tif 000009
【図８】
2003013068.tif 000010
【図９】
2003013068.tif 000011
【図１０】
2003013068.tif 000012
【図１１】
2003013068.tif 000013
【図１２】
2003013068.tif 000014
【図１３】
2003013068.tif 000015
【図１４】
2003013068.tif 000016
【図１５】
2003013068.tif 000017
【図１６】
2003013068.tif 000018
【図１７】
2003013068.tif 000019
【図１８】
2003013068.tif 000020
【図１９】
2003013068.tif 000021
【図２０】
2003013068.tif 000022
【図２１】
2003013068.tif 000023
【図２２】
2003013068.tif 000024
【図２３】
2003013068.tif 000025
【図２４】
2003013068.tif 000026
【国際調査報告】
2003013068.tif 000027
2003013068.tif 000028
2003013068.tif 000029
2003013068.tif 000030