JP2018037898A - 送信機、通信システム、送信方法及びプログラム - Google Patents

Abstract

【課題】ビーコンを送信する送信機の所有者の特定を困難にすることが可能な技術を提供すること。【解決手段】ＢＬＥ（Bluetooth（登録商標） Low Energy）のアドバタイジングパケットを送信する送信機であって、暗号化に用いる複数の鍵と、該複数の鍵の各々に対応する鍵番号とを含む鍵情報を記憶する記憶手段と、時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定し、前記暗号化用の鍵番号に対応する鍵を用いて所定の識別子を暗号化する暗号化手段と、前記暗号化用の鍵番号と前記暗号化手段により暗号化された識別子とを含むアドバタイジングパケットを送信する送信手段と、を有する送信機を提供する。【選択図】図８

Description

本発明は、送信機、通信システム、送信方法及びプログラムに関する。

近距離無線通信技術であるＢｌｕｅｔｏｏｔｈ（登録商標）を拡張した技術であり、極めて省電力での通信が可能であるＢＬＥ（Bluetooth（登録商標） Low Energy）と呼ばれる技術が知られている。ＢＬＥでは、送信機から、ビーコンと呼ばれるアドバタイジングパケットを送信することで、不特定多数のユーザに対して情報配信等のサービスを提供することが可能である。なお、ＢＬＥを利用した従来技術として、例えば、特許文献１に開示された技術がある。

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

ビーコンを用いたサービスを行うためには、受信機側で、どの送信機から送信されたビーコンであるのかを識別可能にする必要がある。そのため、送信機は、送信機自身のＩＤやサービスを提供する店舗を識別する識別子などをビーコンに含めて送信することが一般的に行われている。

しかしながら、ビーコンは不特定多数のユーザが受信可能であることから、ビーコンに含まれる識別子から、ビーコンを送信する送信機の所有者が特定される可能性があるという問題がある。

本発明は上記に鑑みてなされたものであって、ビーコンを送信する送信機の所有者の特定を困難にすることが可能な技術を提供することを目的とする。

本発明の実施の形態に係る送信機は、ＢＬＥ（Bluetooth（登録商標） Low Energy）のアドバタイジングパケットを送信する送信機であって、暗号化に用いる複数の鍵と、該複数の鍵の各々に対応する鍵番号とを含む鍵情報を記憶する記憶手段と、時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定し、前記暗号化用の鍵番号に対応する鍵を用いて所定の識別子を暗号化する暗号化手段と、前記暗号化用の鍵番号と前記暗号化手段により暗号化された識別子とを含むアドバタイジングパケットを送信する送信手段と、を有する。

本発明よれば、ビーコンを送信する送信機の所有者の特定を困難にすることが可能な技術が提供される。

実施の形態に係る通信システムの構成例を示す図である。 実施の形態に係る送信機、受信機及びサーバのハードウェア構成例を示す図である。 実施の形態に係る送信機の機能構成例を示す図である。 実施の形態に係る受信機の機能構成例を示す図である。 実施の形態に係るサーバの機能構成例を示す図である。 鍵情報の一例を示す図である。 実施の形態に係る受信機の機能構成例（変形例）を示す図である。 実施の形態に係る通信システムが行う処理手順の一例を示すシーケンス図である。 実施の形態に係る通信システムが行う処理手順（変形例）の一例を示すシーケンス図である。 アドバタイジングパケットのフォーマットを説明するための図である。 独自フォーマットを使用したアドバタイジングパケットの一例を示す図である。 ｉビーコンで規定されるフォーマットを流用したアドバタイジングパケットの一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

＜システム構成、概要＞
図１は、実施の形態に係る通信システムの構成例を示す図である。本通信システムは、ＢＬＥのアドバタイジングパケット（advertising packets）を送信する送信機１０、アドバタイジングパケットを受信する受信機２０、及び、アドバタイジングパケットの収集を行うサーバ３０を有する。受信機２０とサーバ３０は無線又は有線で接続され、相互に通信することが可能である。図１には、送信機１０及び受信機２０が１つずつ図示されているが、送信機１０及び受信機２０はそれぞれ複数であってもよい。

送信機１０は、例えば、ＢＬＥビーコン、ＢＬＥタグ等であり、周期的にアドバタイジングパケットを送信する。送信機１０が送信するアドバタイジングパケットには、送信機１０を特定可能な識別子（以下、「ビーコン識別子」と呼ぶ）が含まれている。ビーコン識別子は、送信機１０及びサーバ３０が共通に保持している鍵を用いて暗号化される。ビーコン識別子は、例えば、送信機１０のＩＤ（Identifier）、サービスを提供する店舗を特定する識別子など、送信機１０の所有者を特定又は推定可能な識別子である。本実施の形態では、ビーコン識別子は、データ長が１６オクテット（１２８ビット）であるＵＵＩＤ（Universally Unique Identifier）、又は、データ長が６オクテット（４８ビット）であるＢＤ（Bluetooth（登録商標） Device）アドレスである前提で説明するが、これに限定されるものではなく、本実施の形態では、あらゆる識別子を利用することが可能である。なお、ＵＵＩＤとは、ＲＦＣ４１２２で規定されているＩＤであり、全てのスペース及び全ての時間においてユニークなＩＤと定義されている。ＢＤアドレスとは、Ｂｌｕｅｔｏｏｔｈ（登録商標）仕様で規定されており、Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイスを特定するために用いられる。ＢＤアドレスは、Ｂｌｕｅｔｏｏｔｈ（登録商標）仕様ではＢＤ＿ＡＤＤＲとも呼ばれる。

受信機２０は、アドバタイジングパケットを受信し、受信したアドバタイジングパケットをサーバに送信（転送）する。ここで、受信機２０が受信するアドバタイジングパケットの中には、本通信システムとは無関係なビーコンから送信されるアドバタイジングパケットも含まれる。そのため、受信機２０は、受信した全てのアドバタイジングパケットをサーバに送信（転送）するのではなく、本通信システムの送信機１０から送信されたアドバタイジングパケットをスクリーニング（選別）してサーバに送信（転送）するようにしてもよい。受信機２０は、例えば、スマートフォン、タブレット、携帯電話等の端末である。

サーバ３０は、受信機２０から受信したアドバタイジングパケットに含まれるビーコン識別子を復号し、復号したビーコン識別子を用いて送信機１０を特定することで所定の処理を行う。所定の処理はどのような処理であってもよいが、例えば、特定した送信機１０に対応する情報（例えば送信機１０が設置されている店舗のクーポン等）を受信機２０に配信するといった処理を想定している。

＜ハードウェア構成＞
続いて、送信機１０、受信機２０及びサーバ３０のハードウェア構成について説明する。

図２は、実施の形態に係る送信機、受信機及びサーバのハードウェア構成例を示す図である。送信機１０、受信機２０及びサーバ３０は、ＣＰＵ１１と、メモリ１２と、通信ＩＦ１３と、入力部１４と、出力部１５とを有する。また、送信機１０、受信機２０及びサーバ３０は、記憶媒体１６を接続可能であってもよい。

ＣＰＵ１１は、送信機１０、受信機２０及びサーバ３０の全体制御を行うプロセッサである。ＣＰＵ１１は、メモリ１２に記憶されたプログラムを実行し、送信機１０、受信機２０又はサーバ３０の各種機能を実現する。メモリ１２には、各種のプログラムやプログラムによって利用されるデータ等が記憶される。また、メモリ１２は、記憶媒体１６からプログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等としても用いられる。通信ＩＦ１３は、無線又は有線によりデータの送受信を行うための通信インターフェースである。入力部１４は、ユーザからの入力を受け付けるためのハードウェア、又は、ユーザからの入力を受け付けるためのハードウェアを接続可能なインターフェースである。出力部１５は、ユーザに向けた表示等を行うハードウェア、又は、ユーザに向けた表示等を行うハードウェアを接続可能なインターフェースである。なお、記憶媒体１６とは、非一時的（non-transitory）な記憶媒体を言う。記憶媒体１６の例としては、磁気記憶媒体、光ディスク、光磁気記憶媒体、不揮発性メモリなどがある。

＜機能構成＞
続いて、送信機１０、受信機２０及びサーバ３０の機能構成について説明する。

（送信機）
図３は、実施の形態に係る送信機の機能構成例を示す図である。図３に示すように、送信機１０は、暗号化部１０１と、生成部１０２と、送信部１０３と、記憶部１０４とを有する。これら各機能部は、送信機１０にインストールされた１以上のプログラムが、ＣＰＵ１１に実行させる処理により実現され得る。記憶部１０４は、メモリ１２を用いて実現可能である。

暗号化部１０１は、記憶部１０４に記憶されている鍵情報から、ビーコン識別子の暗号化に用いる鍵を取得し、取得した鍵を用いてビーコン識別子を暗号化する機能を有する。ここで、鍵情報には、暗号化に用いる複数の鍵と、該複数の鍵の各々に対応する鍵番号とが対応づけて記憶されている。暗号化部１０１は、時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定し、鍵情報から、決定した暗号化用の鍵番号に対応する鍵を取り出してビーコン識別子を暗号化する。

生成部１０２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格で定められているアドバタイジングパケットのフォーマットに従い、暗号化されたビーコン識別子を含むアドバタイジングパケットを生成する機能を有する。また、生成部１０２は、アドバタイジングパケットを受信機２０からサーバ３０に送信（転送）すべきか否かの判定に用いられる情報（以下、「スクリーニング情報」と言う）を、アドバタイジングパケットに含めるようにしてもよい。

送信部１０３は、生成部１０２で生成されたアドバタイジングパケットを送信する機能を有する。記憶部１０４は、鍵情報を記憶する。図６は、鍵情報の一例を示す図である。図６の例では、「鍵番号」は２オクテット（０番〜２５５番）であり、「鍵」の長さは１２８ビット（１６オクテット）であるが、あくまで一例であり、これに限定されるものではない。「鍵番号」は３オクテット以上であってもよいし、「鍵」の長さも、１２８ビット以外（８０ビット、１９２ビット等）であってもよい。

（受信機）
図４は、実施の形態に係る受信機の機能構成例を示す図である。図４に示すように、受信機２０は、受信部２０１と、スクリーニング部２０２と、送信部２０３とを有する。これら各機能部は、受信機２０にインストールされた１以上のプログラムが、ＣＰＵ１１に実行させる処理により実現され得る。

受信部２０１は、送信機１０から送信されるアドバタイジングパケットを受信する機能を有する。

スクリーニング部２０２は、アドバタイジングパケットに含まれるスクリーニング情報が所定の条件を満たす情報であるか否かを判定することでスクリーニング処理を行う機能を有する。

送信部２０３は、スクリーニング部２０２において、スクリーニング情報が所定の条件を満たす情報であると判定されたアドバタイジングパケットをサーバ３０に送信する機能を有する。

（サーバ）
図５は、実施の形態に係るサーバの機能構成例を示す図である。図５に示すように、サーバ３０は、受信部３０１と、復号部３０２と、記憶部３０３とを有する。これら各機能部は、サーバ３０にインストールされた１以上のプログラムが、ＣＰＵ１１に実行させる処理により実現され得る。記憶部３０３は、メモリ１２又はサーバ３０にネットワークを介して接続される記憶装置等を用いて実現可能である。

受信部３０１は、受信機２０から送信（転送）されるアドバタイジングパケットを受信する機能を有する。

復号部３０２は、受信部３０１で受信したアドバタイジングパケットに含まれるビーコン識別子を、記憶部３０３に記憶されている鍵情報を用いて復号する機能を有する。より具体的には、復号部３０２は、受信したアドバタイジングパケットに含まれる鍵番号に対応する鍵を鍵情報から取得し、取得した鍵を用いて、受信したアドバタイジングパケットに含まれるビーコン識別子を復号する。

記憶部３０３は、鍵情報を記憶する。記憶部３０３に記憶される鍵情報は、送信機１０に記憶されている鍵情報と同一である。

受信部３０１と、復号部３０２と、記憶部３０３とは、１つのコンピューターを用いて実現されてもよいし、異なるコンピューターを用いて実現されていてもよいし、細かい単位でコンピューターが分散されていてもよい。すなわち、サーバ３０は、１又は複数のコンピューターを用いて実現されていてもよい。また、当該１又は複数のコンピューターは、仮想化技術を利用した仮想サーバであってもよいし、クラウド上に実装された仮想サーバであってもよい。

以上、送信機１０、受信機２０及びサーバ３０の機能構成について説明したが、アドバタイジングパケットに含まれる暗号化されたビーコン識別子の復号を、サーバ３０ではなく受信機２０で行うようにしてもよい。すなわち、サーバ３０の復号部３０２及び記憶部３０３を受信機２０内に備える構成とし、サーバ３０は、単にアドバタイジングパケットの収集等を行うサーバとして機能するようにしてもよい。復号機能を有する受信機２０及び復号機能を有するサーバ３０は、復号装置と呼ばれてもよい。その場合の受信機２０の機能構成例を図７に示す。図７に示すように、受信機２０は、受信部２０１と、スクリーニング部２０２と、送信部２０３と、復号部２０４と、記憶部２０５を有する。受信部２０１と、スクリーニング部２０２と、送信部２０３とは、図４と同一であるため説明は省略する。

復号部２０４は、受信部２０１で受信したアドバタイジングパケットに含まれるビーコン識別子を、記憶部２０５に記憶されている鍵情報を用いて復号する機能を有する。より具体的には、復号部２０４は、受信したアドバタイジングパケットに含まれる鍵番号に対応する鍵を鍵情報から取得し、取得した鍵を用いて、受信したアドバタイジングパケットに含まれるビーコン識別子を復号する。また、復号部２０４は、復号されたビーコン識別子が格納されたアドバタイジングパケットをスクリーニング部２０２に渡す。

記憶部２０５は、鍵情報を記憶する。記憶部２０５に記憶される鍵情報は、送信機１０に記憶されている鍵情報と同一である。

＜処理手順＞
図８は、実施の形態に係る通信システムが行う処理手順の一例を示すシーケンス図である。図８の例は、ビーコン識別子の復号をサーバ３０側で行う場合の処理手順を示している。

ステップＳ１１において、送信機１０の暗号化部１０１は、アドバタイジングパケットに含めるべきビーコン識別子を暗号化する。まず、暗号化部１０１は、「時間の経過と共に変化する値」に基づいて暗号化用の鍵番号を決定する。「時間の経過と共に変化する値」は、例えば、送信機１０が備えるクロック（例えば水晶発振器のベースクロック）に基づいてカウントアップする正の整数のカウンター値であってもよいし、初期値として現在時刻が設定された乱数生成器から出力される正の整数の乱数であってもよい。時間の経過と共に変化する値は、少なくともアドバタイジングパケットの送信周期よりも短い周期で変化する値であることが好適である。

続いて、暗号化部１０１は、「時間の経過と共に変化する値」に基づいて暗号化に用いる鍵の鍵番号を決定する。暗号化部１０１は、例えば、「時間の経過と共に変化する値」を２５６で割った"余り"を鍵番号としてもよい。

続いて、暗号化部１０１は、鍵情報から、決定した鍵番号に対応する鍵を取り出してビーコン識別子を暗号化する。暗号化部１０１は、暗号化方式として、例えば、ストリーム暗号方式を利用するようにしてもよいし、ブロック暗号方式を利用するようにしてもよい。

ストリーム暗号方式を利用する場合、暗号化されたビーコン識別子は、暗号化前のビーコン識別子と同一のサイズになる。つまり、ビーコン識別子がＵＵＩＤ（１６オクテット）である場合、暗号化されたビーコン識別子のサイズも１６オクテットになり、ビーコン識別子がＢＤアドレス（６オクテット）である場合、暗号化されたビーコン識別子のサイズも６オクテットになる。

ブロック暗号方式を利用する場合、暗号化されたビーコン識別子は、ブロック長の整数倍になる。そこで、ブロック暗号方式を利用する場合、本実施の形態では、アドバタイジングパケットに格納可能なデータサイズを考慮し、ブロック長が１２８ビットであるブロック暗号方式（例えばＡＥＳ（Advanced Encryption Standard）など）を利用する。ここで、ブロック長が１２８ビットであるブロック暗号アルゴリズムに入力する平文は１２８ビット（１６オクテット）にする必要があるが、ビーコン識別子がＢＤアドレス（６オクテット）である場合、１０オクテット分が不足する。そこで、ビーコン識別子がＢＤアドレスである場合、暗号化部１０１は、不足する１０オクテットを、例えばＲＦＣ１４２３で規定されているPKCS#5 Paddingを利用してパディングするようにしてもよい。また、暗号化部１０１は、送信機１０が備える各種のセンサ等の出力データ（電池残量、温度、湿度など）をＢＤアドレスの後に１０オクテット分加えるようにしてもよい。これにより、アドバタイジングパケットを利用して、送信機１０から出力されるデータをサーバ３０に通知することができる。なお、上述したストリーム暗号方式を利用する場合であっても、暗号化部１０１は、ＢＤアドレス（６オクテット）の後に送信機１０が備える各種センサ等の出力データ（電池残量、温度、湿度など）を加えてから暗号化を行うようにしてもよい。

また、ブロック暗号方式を利用する場合、暗号モードによっては、初期化ベクトル（ＩＶ：Initialization Vector）が必要になる。例えば、ＣＢＣモード（Cipher Block Chaining）、ＣＦＢモード（Cipher Feedback Mode）、ＯＦＢモード（Output Feedback Mode）では、暗号化に用いる鍵の他に初期化ベクトルが必要になる。そこで、本実施の形態では、暗号化部１０１は、初期化ベクトルが必要な暗号モードを利用する場合、予め定められた値を初期化ベクトルに使用するようにしてもよいし、鍵番号を初期化ベクトルに利用するようにしてもよい。

ステップＳ１２において、送信機１０の生成部１０２は、アドバタイジングパケットを生成する。ここで、図１０を用いて、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格で定められているアドバタイジングパケットのフォーマットについて説明する。アドバタイジングパケットは、「Preamble」、「Access Address」、「PDU」及び「CRC」の各フィールドから構成されており、「Access Address」には固定値（0x8e89bed6）が設定される。「PDU」は更に「Header」及び「Payload」に分けられる。「Header」の先頭には「PDU Type」が含まれており、本実施の形態では、「PDU Type」にADV_NONCONN_INDを示すビット（0010）を設定してもよい。なお、ADV_NONCONN_INDとは、不特定多数のデバイスから接続不可能（つまり、コネクションの接続を受け付けない）なアドバタイジングイベントを意味する。

「Payload」は更に、「AdvA」及び「AdvData」に分けられる。「AdvA」には、アドバタイザー（Advertiser）のパブリック又はランダムなデバイスアドレスが設定される。より具体的には、「Header」内において「TxADD=0」である場合、「AdvA」にはパブリックなデバイスアドレスが設定され、「TxADD=1」である場合、「AdvA」にはランダムなデバイスアドレスが設定される。本実施の形態では、「TxADD＝1」とすることで「AdvA」にランダムなデバイスアドレスが設定されるようにしてもよい。

「AdvData」には、１以上の「AD Structure」を設定可能である。各「AD Structure」は更に、「Length」、「AD Type」及び「AD Data」の各フィールドに分けられる。「Length」は「AD Structure」の長さ（オクテット）を示す。「AD Type」は、AD Dataに設定されるデータのタイプを示す。「AD Data」には、アドバタイジングする実際のデータが格納される。

ここで、生成部１０２は、独自フォーマットを使用したアドバタイジングパケットを生成するようにしてもよいし、ｉビーコンで規定されるフォーマットを流用したアドバタイジングパケットを生成するようにしてもよい。

図１１は、独自フォーマットを使用したアドバタイジングパケットの一例を示す図である。図１１の例では、「AD Type」に、「AD Data」が独自フォーマット（製品専用のフォーマット）であることを示す0xFF（Manufacture Specific）を設定する。なお、「AD Type=0xFF」の場合、「AD Data」の先頭の２オクテットには、Bluetooth（登録商標） SIG（Bluetooth（登録商標） Special Interest Group）に登録された「Company ID」を設定する必要がある。本実施の形態では、「Company ID」に所定の企業ＩＤを設定する。

「AD Data」には更に、２オクテットの「鍵番号」と、２オクテットの「スクリーニング情報」と、「暗号化ビーコン識別子」とが格納される。ビーコン識別子がＢＤアドレスであり、かつ、ストリーム暗号方式を利用して暗号化された場合は、「暗号化ビーコン識別子」は６オクテットになる。ビーコン識別子がＵＵＩＤである場合は、及び、ビーコン識別子がＢＤアドレスであっても１２８ビットのブロック暗号方式を利用して暗号化された場合は、「暗号化ビーコン識別子」は１６オクテットになる。なお、「鍵番号」、「スクリーニング情報」及び「暗号化ビーコン識別子」の並び順は一例であり、これに限定されない。また、「AD Data」のフィールドに空きがある場合、送信機１０が備える各種センサ等の出力データが含まれるようにしてもよい。

図１２は、ｉビーコンで規定されるフォーマットを流用したアドバタイジングパケットの一例を示す図である。図１２に示すように、ｉビーコンで規定されるフォーマットには、「AdvData」には２つの「AD Structure」が設定され、２つ目の「AD Structure」には、１６オクテットの「UUID」と、２オクテットの「Major」と、２オクテットの「Minor」とを格納するフィールドが存在する。生成部１０２は、暗号化されたビーコン識別子を「UUID」に格納し、鍵番号を「Major」に格納し、スクリーニング情報を「Minor」に格納する。ここで、「UUID」フィールドは１６オクテットであると定められている。そのため、暗号化部１０１は、ビーコン識別子がＢＤアドレスである場合、前述したように、ＢＤアドレスにパディングを行うか、又は、ＢＤアドレスに各種センサ等の出力データを加えることで、暗号化後のビーコン識別子が１６オクテットになるように調整する必要がある。

なお、生成部１０２は、「Minor」に鍵番号を格納し、「Major」にスクリーニング情報を格納するようにしてもよい。また、生成部１０２は、「Major」及び「Minor」を結合した４オクテットのフィールドのうち任意のフィールドに鍵番号及びスクリーニング情報を格納するようにしてもよい。例えば、「Major」及び「Minor」を結合した４オクテットのフィールドのうち最初の１オクテットと最後の１オクテットに鍵番号を格納し、中心の２オクテットにスクリーニング情報を格納するようにしてもよい。図６に戻り説明を続ける。

ステップＳ１３において、送信機１０の送信部１０３は、ステップＳ１２の処理手順で生成されたアドバタイジングパケットを、ＢＬＥの信号として送信する。受信機２０の受信部２０１は、送信機１０から送信されたアドバタイジングパケットを受信する。

ステップＳ１４において、受信機２０のスクリーニング部２０２は、受信したアドバタイジングパケットに含まれる「スクリーニング情報」が所定の条件を満たす情報であるか否かを判定する。

ここで、スクリーニング情報は、例えは、アドバタイジングパケットに含まれる情報を所定の関数に入力することで出力された情報であってもよい。例えば、送信機１０の生成部１０２は、「鍵番号」を所定の関数に入力することで出力された情報を「スクリーニング情報」に予め格納しておく。受信機２０のスクリーニング部２０２は、アドバタイジングパケットに含まれる「鍵番号」を当該所定の関数に入力することで出力された情報が、アドバタイジングパケットに含まれる「スクリーニング情報」と一致した場合に、「スクリーニング情報」が所定の条件を満たす情報であると判定する。

所定の関数とは、例えば、入力値をビット反転させる関数であってもよい。この場合、受信機２０のスクリーニング部２０２は、アドバタイジングパケットに含まれる「スクリーニング情報」をビット反転させた情報が、アドバタイジングパケットに含まれる「鍵番号」と一致した場合（又は、「鍵番号」及び「スクリーニング情報」の合計が0xFFFFになる場合）に、「スクリーニング情報」が所定の条件を満たす情報であると判定する。

また、アドバタイジングパケットが図１１に示す独自フォーマットである場合、受信機２０のスクリーニング部２０２は「Company ID」をスクリーニング情報とみなすようにしてもよい。この場合、スクリーニング部２０２は、「Company ID」に所定の企業ＩＤが設定されている場合に、スクリーニング情報が所定の条件を満たす情報であると判定する。なお、この場合、図１１に示すアドバタイジングパケットには「スクリーニング情報」が含まれていなくてもよい。

ステップＳ１５において、受信機２０の送信部２０３は、スクリーニング情報が所定の条件を満たす情報であると判定されたアドバタイジングパケットをサーバ３０に送信する。サーバ３０の受信部３０１は、アドバタイジングパケットを受信する。なお、送信部２０３は、アドバタイジングパケットと一緒に、受信機２０がＧＰＳ等を用いて測定した位置情報、及び／又は、アドバタイジングパケットを送信する時刻（又はアドバタイジングパケットを受信した時刻）などをサーバ３０に送信するようにしてもよい。アドバタイジングパケットが図１１に示す独自フォーマットである場合で、かつ「AD Data」のフィールドに空きがある場合、受信機２０の送信部２０３は、位置情報及び／又は時刻などを「AD Data」に格納してサーバ３０に送信するようにしてもよい。

ステップＳ１６において、サーバ３０の復号部３０２は、送信機１０の暗号化部１０１が行った処理と逆の処理を行うことで、アドバタイジングパケットに含まれるビーコン識別子を復号する。なお、ビーコン識別子がＢＤアドレスであり、ステップＳ１２で説明した方法によりパディングが行われている場合、サーバ３０の復号部３０２は、復号したビーコン識別子のうちパディング部分を破棄する。

なお、ステップＳ１１乃至ステップＳ１６の処理手順は、アドバタイジングパケットの送信周期ごとに繰り返し行われる。

以上、ビーコン識別子の復号をサーバ３０側で行う場合の処理手順について説明した。

続いて、ビーコン識別子の復号を受信機２０側で行う場合の処理手順について説明する。図９は、実施の形態に係る通信システムが行う処理手順（変形例）の一例を示すシーケンス図である。図９において、図８と同一の処理手順については同一の符号を付して説明は省略する。

ステップＳ２１で、受信機２０の復号部２０４は、ステップＳ１３の処理手順で受信したアドバタイジングパケットに含まれる「鍵番号」及び「ビーコン識別子」を抽出し、送信機１０の暗号化部１０１が行った処理と逆の処理を行うことでビーコン識別子を復号する。また、復号部２０４は、復号後のビーコン識別子をアドバタイジングパケットの「ビーコン識別子」のフィールドに格納してスクリーニング部２０２に渡す。以上、ビーコン識別子の復号を受信機２０側で行う場合の処理手順について説明した。

以上説明した実施の形態によれば、アドバタイジングパケットに含まれるビーコン識別子が暗号化されるため、アドバタイジングパケットを受信した第三者は、ビーコン識別子を把握することができなくなる。これにより、第三者は、ビーコン識別子に基づいて、送信機１０の所有者の特定することが困難になる。

また、実施の形態によれば、アドバタイジングパケットに含まれるビーコン識別子は、アドバタイジングパケットの送信周期ごとに異なる鍵を用いて暗号化されることになる。つまり、第三者からは、アドバタイジングパケットの送信周期ごとにビーコン識別子が変化するように見えるため、送信機１０の所有者の特定することが更に困難になる。

また、実施の形態によれば、１２８ビットのブロック暗号方式を利用し、かつ、鍵番号を初期化ベクトルに利用することで、ｉビーコンで規定されるフォーマットにおける各フィールドのサイズを変更することなくアドバタイジングパケットを送信することが可能である。これにより、送信機１０及び受信機２０は、ｉビーコンで規定されるフォーマットを流用した実装を行うことができ、送信機１０及び受信機２０のソフトウェア開発コストを抑制することが可能になる。また、ｉビーコンで規定されるフォーマットは広く一般的に利用されていることから、ｉビーコンで規定されるフォーマットを流用することで、独自フォーマットを利用する場合と比較して送信機１０の所有者の特定が更に困難になる。

また、実施の形態によれば、受信機２０は、受信した全てのアドバタイジングパケットをサーバに送信（転送）するのではなく、受信したアドバタイジングパケットをスクリーニング（選別）してサーバに送信（転送）するようにした。これにより、大量のアドバタイジングパケットがサーバ３０に送信されることを抑止することができ、サーバ３０の処理負荷を軽減させることができる。

＜実施形態の補足＞
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。機能構成図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べたシーケンスは、矛盾の無い限り順序を入れ替えてもよい。処理説明の便宜上、送信機１０、受信機２０及びサーバ３０は機能構成図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。

実施の形態におけるスクリーニング情報は、判定情報の一例である。ビーコン識別子は、所定の識別子の一例である。

１０ 送信機
２０ 受信機
３０ サーバ
１０１ 暗号化部
１０２ 生成部
１０３ 送信部
１０４ 記憶部
２０１ 受信部
２０２ スクリーニング部
２０３ 送信部
２０４ 復号部
２０５ 記憶部
３０１ 受信部
３０２ 復号部
３０３ 記憶部

Claims (10)

1. ＢＬＥ（Bluetooth（登録商標） Low Energy）のアドバタイジングパケットを送信する送信機であって、
   暗号化に用いる複数の鍵と、該複数の鍵の各々に対応する鍵番号とを含む鍵情報を記憶する記憶手段と、
   時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定し、前記暗号化用の鍵番号に対応する鍵を用いて所定の識別子を暗号化する暗号化手段と、
   前記暗号化用の鍵番号と前記暗号化手段により暗号化された識別子とを含むアドバタイジングパケットを送信する送信手段と、
   を有する送信機。
2. 前記アドバタイジングパケットには、前記アドバタイジングパケットを受信した受信機が、受信した前記アドバタイジングパケットをサーバに送信するべきか否かを判定するために用いられる判定情報が含まれる、請求項１に記載の送信機。
3. 前記判定情報は、ＢＬＥで規定される企業ＩＤ、又は、前記鍵番号を所定の計算式に代入することで出力される値である、請求項２に記載の送信機。
4. 前記判定情報は、前記鍵番号をビット反転させることで出力される値である、請求項３に記載の送信機。
5. 前記暗号化手段は、ブロック暗号方式を用いて前記所定の識別子を暗号化し、該ブロック暗号方式に使用する初期化ベクトルとして前記暗号化用の鍵番号を使用する、請求項１乃至４のいずれか一項に記載の送信機。
6. 前記アドバタイジングパケットは、
   ＡＤタイプフィールドに、ＡＤデータフィールドが製品専用のフォーマットであることを示す値が格納され、
   ＡＤデータフィールドに、企業ＩＤと、前記暗号化用の鍵番号と、前記暗号化された識別子とが格納される、
   請求項１乃至５のいずれか一項に記載の送信機。
7. 前記アドバタイジングパケットのＡＤデータフィールドは、企業ＩＤと、ＵＵＩＤフィールドと、Ｍａｊｏｒフィールドと、Ｍｉｎｏｒフィールドとを含み、
   前記ＵＵＩＤフィールドに、前記暗号化された識別子が格納され、
   前記Ｍａｊｏｒフィールド又は前記Ｍｉｎｏｒフィールドに、前記暗号化用の鍵番号が格納される、
   請求項１乃至５のいずれか一項に記載の送信機。
8. ＢＬＥ（Bluetooth（登録商標） Low Energy）のアドバタイジングパケットを送信する送信機と、該アドバタイジングパケットを受信する受信機と、該受信機と通信するサーバとを含む通信システムであって、
   前記送信機は、
   暗号化に用いる複数の鍵と、該複数の鍵の各々に対応する鍵番号とを含む鍵情報を記憶する記憶手段と、
   時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定し、前記暗号化用の鍵番号に対応する鍵を用いて所定の識別子を暗号化する暗号化手段と、
   前記暗号化用の鍵番号と、前記暗号化手段により暗号化された識別子と、前記受信機がアドバタイジングパケットを前記サーバに送信するべきか否かを判定するために用いられる判定情報と、を含むアドバタイジングパケットを送信する送信手段と、
   を有し、
   前記受信機は、
   前記送信機から送信されたアドバタイジングパケットを受信する受信手段と、
   前記受信手段で受信されたアドバタイジングパケットに含まれる判定情報が所定の条件を満たす場合に、前記受信手段で受信されたアドバタイジングパケットを前記サーバに送信する送信手段と、
   を有し、
   前記サーバは、
   前記鍵情報を記憶する記憶手段と、
   前記受信機から受信したアドバタイジングパケットに含まれる前記暗号化用の鍵番号に対応する鍵を前記鍵情報から取得し、取得した鍵を用いて、前記受信機から受信したアドバタイジングパケットに含まれる前記暗号化された識別子を復号する復号手段と、
   を有する、通信システム。
9. ＢＬＥ（Bluetooth（登録商標） Low Energy）のアドバタイジングパケットを送信する送信機が実行する送信方法であって、
   時間の経過と共に変化する値に基づいて暗号化用の鍵番号を決定するステップと、
   暗号化に用いる複数の鍵と該複数の鍵の各々に対応する鍵番号とを含む鍵情報を参照することで、前記暗号化用の鍵番号に対応する鍵を取得するステップと、
   取得された前記暗号化用の鍵番号に対応する鍵を用いて当該送信機を特定する識別子を暗号化するステップと、
   前記暗号化用の鍵番号と暗号化された識別子とを含むアドバタイジングパケットを送信するステップと、
   を有する送信方法。
10. コンピューターを、請求項１乃至７のいずれか一項に記載の送信機の各手段として機能させるプログラム。

Images