JP6922593B2 - 情報処理システムおよび無線端末 - Google Patents

Description

本発明は、情報処理システムおよび無線端末に関する。

無線によるデータ通信が可能な携帯端末の普及に伴い、ビーコンのような無線局の識別情報を活用したサービスの提供が進んでいる。例えばレストランのオーナーは、自身のレストランにビーコンを設置し、ビーコンから一定間隔でビーコンの識別情報を送信させる。携帯端末のユーザは、レストランに接近することにより、ビーコンから送信される識別情報を含む無線信号を受信する。携帯端末はビーコンから受信した識別情報を含む無線信号に基づき、レストランのクーポン情報を取得することが出来る。

携帯端末は、検知した識別情報に対応するビーコン等の検知対象を特定するため、特定すべき識別情報に関連する検知対象の識別情報一覧をあらかじめ携帯端末に登録しておくことができる。検知対象は固有の識別情報を有するので、携帯端末は、検知した識別情報と、あらかじめ自身に登録した識別情報一覧とを照合することにより、検知した識別情報に対応する検知対象を特定することが出来る。例えば特許文献１には、自身の携帯端末と近距離通信可能な携帯端末をグループ化し、グループ中の自身の携帯端末のみサーバと通信可能とする技術が開示されている。

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

ビーコンは一般に建築物や地面等に固定的に設置されており、携帯端末がビーコンからの無線信号を受信できる範囲（カバレッジエリア）は、ビーコンから無線信号が届く範囲に限られる。そのため、複数のビーコンを設置してカバレッジエリアを広げることが考えられる。ここで、所望するカバレッジエリアにビーコンをまばらに設置すると、必要なビーコン数は抑えられるものの、いわゆるカバレッジホールが発生すること等により、無線端末がビーコンからの無線信号を確実に受信できないことが想定される。一方、所望するカバレッジエリアにビーコンを密に設置すると、カバレッジホールの発生は抑えられるものの、必要なビーコン数が増大し、コスト面等で問題が残る。

開示の技術は、必要なビーコンの数を押さえつつ、広い範囲を確実にカバーすることを目的とする。

上述した課題を解決し、目的を達成するため、情報処理システムは、所定情報を含む検知信号を無線送信する検知対象と、前記検知信号の受信に基づいて前記所定情報を含む仮想検知信号を無線送信する複数の特定無線端末と、前記検知信号と前記仮想検知信号のいずれも受信できない場合、前記仮想検知信号の発信を依頼する発信依頼信号を無線送信する無線端末とを有し、前記特定無線端末は、前記発信依頼信号を受信した場合であっても、他の前記特定無線端末から前記仮想検知信号を受信した場合には、前記仮想検知信号の無線送信を行わないことを特徴とする。

本件の開示する技術の一つの態様によれば、必要なビーコンの数を押さえつつ、広い範囲を確実にカバーすることが出来るという効果を奏する。

図１は、情報処理システムの一例である。 図２は、携帯端末のハードウェアブロック図である。 図３は、検知対象のハードウェアブロック図である。 図４は、検知対象に対応する仮想化ビーコン信号を携帯端末に発信させる状態を示す概念図である。 図５は、仮想ビーコン信号を発信する携帯端末が検知対象のエリア外に移動した場合の処理を示す概念図である。 図６は、他の携帯端末からの発信依頼を受信した携帯端末の動作を示す概念図である。 図７は、発信依頼を行う携帯端末が、担当する動作を変更する状態を示す概念図である。 図８は、発信依頼を行う携帯端末を変更する状態を示す概念図である。 図９は、携帯端末からの発信依頼を分散させる様子を示すタイムチャートである。 図１０は、サーバから携帯端末にルール情報を配信するシステムの機能ブロック図である。 図１１は、サーバのハードウェアブロック図である。 図１２は、ルール情報の具体例である。 図１３は、ルール情報に対応する通知情報の具体例である。 図１４は、サーバから各携帯端末にルール情報を配信する場合の処理フローである。 図１５Ａは、携帯端末におけるイベント受信時の処理フローの一部である。 図１５Ｂは、携帯端末におけるイベント受信時の処理フローの一部である。 図１６は、携帯端末における通知発信の処理フローである。 図１７は、携帯端末の通知発信におけるタイマー起動の処理フローである。 図１８Ａは、携帯端末における発信依頼の処理フローの一部である。 図１８Ｂは、携帯端末における発信依頼の処理フローの一部である。 図１９は、携帯端末の発信依頼におけるタイマー起動の処理フローである。 図２０は、携帯端末における担当変更処理の詳細なフローである。

以下、本発明の実施形態について具体的に説明する。

図１は、情報処理システムの一例である。図１において情報処理システム１は、携帯端末３（以下、単に端末３ともいう）、検知対象４、ネットワーク５を有する。情報処理システム１は、識別情報を処理管理する情報処理システムの一つである。

携帯端末３は、携帯電話、スマートフォン等のデータ通信可能な無線端末である。携帯端末３は、基本的には人間に携帯されて移動することが想定される移動無線端末である。情報処理システム１において、一例として、携帯端末３は携帯端末３ａ〜３ｅを含む。検知対象４は、位置情報等を固有の識別情報と共に無線信号で発信する無線局である。検知対象４は例えばあらかじめ情報が設定された無線信号（ビーコン信号と称される）を一定周期で無線送信するビーコンであり、基本的には建築物や地面等に固定的に設置されることが想定される固定無線局である。ビーコン信号は例えば、各検知対象を識別するための識別情報や検知対象が設置された位置を示す設置位置情報、またはビーコン信号の送信時間などを含む。検出対象４は、ビーコンの他、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＱＲ（Ｑｕｉｃｋ Ｒｅｓｐｏｎｓｅ）コード、ＷｉＦｉなどであってもよい。また後述の通り、検知対象４から発信される信号を受信可能な範囲をエリア６と定義しているが、例えばＧＰＳ信号を検知するために割り当てられた領域を検知対象としてもよい。

情報処理システム１において、検知対象４は検知対象４ａ、４ｂを含む。また図１において、エリア６ａ、６ｂはそれぞれ、検知対象４ａ、４ｂから送信されるビーコン信号を携帯端末３が受信可能な範囲である。図１の場合、携帯端末３ｂ、３ｃは検知対象４ａから送信されるビーコン信号を受信可能なエリア６ａにあり、携帯端末３ｄ、３ｅは検知対象４ｂから送信されるビーコン信号を受信可能なエリア６ｂにある。携帯端末３はそれぞれネットワーク５に有線または無線で接続されている。

検知対象４が送信する識別情報は、例えばｉＢｅａｃｏｎの場合、ＲＦＣ４１２２規格で規定されたＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）に、ｍａｊｏｒ番号、ｍｉｎｏｒ番号を付与したものである。検知対象４は、それぞれ固有のＵＵＩＤを有する。携帯端末３は、検知対象４が配信する信号を検知するため、検知したい検知対象４の識別情報を自身のＯＳに登録しておく必要がある。

携帯端末３が検知を望むまたは想定する検知対象４の識別情報は、情報処理システム１の設置エリアに入る前に、携帯端末３に割り振られる。検知対象４の識別情報は、後述の通り、例えば携帯端末３にインストールしたアプリケーションの制御により、携帯端末３に割り振られる。

本実施形態における携帯端末３の少なくとも一部は、検知対象４であるビーコンとしても振る舞う（擬似的にビーコンを装う）ことが出来る。すなわち、携帯端末３は所定の条件を満たす場合に、検知対象４であるビーコンとしても振る舞い、検知対象４の識別情報を含むビーコン信号（仮想ビーコン信号と称する）の送信を行う。これにより、検知対象４であるビーコンの数を抑えるとともに、カバレッジホールの発生を抑制しつつ広いエリアをカバーすることが可能となる。

ただし、検知対象４としても振る舞える携帯端末３の全てが検知対象４として振る舞ってしまうと、検知対象４から発信されるビーコン信号に加えて、携帯端末３から発信される仮想ビーコン信号の量も膨大となり、ビーコン信号の受信に支障を来たす恐れがある。この問題を解決するための一案として、どの携帯端末３がどの検知対象４として振る舞っているのか等を一元管理することも考えられる。しかしながら、この場合には一元管理のためのサーバ等を設置する必要があり、コストや運用面で課題が残る。

そこで、サーバ等による一元管理を行うことなく、検知対象４としても振る舞える携帯端末３が節度を保ちつつも柔軟にビーコン信号を発信するための仕組みが必要となる。

本実施形態における携帯端末３の少なくとも一部は、検知対象４を検知できない場合（検知対象４からのビーコン信号を受信できない場合）、他の携帯端末３に対し、仮想ビーコン信号の発信依頼を行う機能を有する。発信依頼を行う機能を有する端末３としては、例えば比較的低級（低機能）な端末３が想定される。これに対し、前述した検知対象４としても振る舞える携帯端末３としては、例えば比較的高級（高機能）な端末３が想定される。

発信依頼を行う機能を有する携帯端末３は、他の携帯端末３に対し、仮想ビーコン信号の発信を依頼する発信依頼信号を送信する。発信依頼信号を受信した携帯端末３は、仮想ビーコン信号を送信開始する。発信依頼信号を受信後、自身が仮想ビーコン信号を発信する前に、他の携帯端末３から発信された仮想ビーコン信号を受信した携帯端末３は、仮想ビーコン信号を発信しない。

以上の通り本実施形態の情報処理システム１は、一元管理のためのサーバに依存することなくそれぞれの携帯端末３の仮想ビーコン信号の発信状況を管理することが出来る。

図２は、携帯端末のハードウェアブロック図である。携帯端末３は、ＣＰＵ２２、メモリ２３、ストレージ２４、ネットワークＩＦ２５、センサ２６、ディスプレイ２７を有する。ＣＰＵ２２、メモリ２３、ストレージ２４、ネットワークＩＦ２５、センサ２６、ディスプレイ２７は、バス２８により互いに接続され、データ通信可能となっている。メモリ２３およびストレージ２４はそれぞれ、情報を記憶する記憶部の一つである。

ＣＰＵ２２は、ストレージ２４またはメモリ２３に記憶されたソフトウェアプログラムを読み出して実行する。メモリ２３は、ストレージ２４から読み出したデータや、ネットワークＩＦ２５により外部から受信したデータなどを一時的に記憶する。ストレージ２４は、ＯＳやソフトウェアプログラム、プログラムの実行時に参照されるデータなどを記憶する。ネットワークＩＦ２５は、ネットワーク５を介して他の装置とデータの送受信を行う通信装置である。またネットワークＩＦ２５は、後述する局所化情報を配信する配信回路として機能する。センサ２６は、例えば携帯端末３の動きを検知する加速度センサや、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）センサである。ディスプレイ２７は、検知対象４からの信号検知情報や識別情報に基づく店舗のクーポン情報等を表示する。

図３は、検知対象のハードウェアブロック図である。検知対象４は、ＣＰＵ３２、メモリ３３、送信モジュール３５を有する。ＣＰＵ３２、メモリ３３、および送信モジュール３５は、バス３６により互いに接続され、データ通信可能となっている。メモリ３３は情報を記憶する記憶部の一つである。

ＣＰＵ３２は、メモリ３３に記憶されたソフトウェアプログラムを読み出して実行する。メモリ３３は、検知対象４の固有識別情報や設置位置情報、ソフトウェアプログラムなどを記憶する。送信モジュール３５は、メモリ３３に記録された情報を外部に無線送信する。

図４は、検知対象に対応する仮想化ビーコン信号を携帯端末に発信させる状態を示す概念図である。図４（ａ）は、検知対象４ａのビーコン信号を受信可能なエリア６ａの中に、携帯端末３ａ、３ｂが存在している状態を示す。図４（ｂ）は、発信依頼を行う携帯端末３１ａの発信依頼信号の受信可能エリア７ａ内に、携帯端末３ａ、３ｂが存在している状態を示す。図４（ｃ）は、携帯端末３１ａの発信依頼信号を受信した携帯端末３ａが、仮想ビーコン信号をエリア７ｂで発信する状態を示す。図４（ｄ）は、携帯端末３ａから発信された仮想ビーコン信号を受信した携帯端末３１ａが発信依頼を停止する状態を示す。

図４（ａ）において、エリア６ａに入った携帯端末３ａ、３ｂは、本実施例において、自律的には仮想ビーコンを発信しない。携帯端末３１ａは、他の携帯端末に対し仮想ビーコン信号の発信依頼を行う端末である。図４（ｂ）の通り発信依頼を行う携帯端末３１ａがエリア６ａに入ることで、携帯端末３ａ、３ｂが携帯端末３１ａの発信依頼信号を受信可能なエリア７ａに入ったとする。ビーコン信号を受信している状態で発信依頼信号を受信した他の携帯端末は、条件に応じて仮想ビーコン信号を発信する。

図４（ｃ）において、発信依頼信号を受信した携帯端末３ａは、携帯端末３ｂよりも先に仮想ビーコン信号を発信する。携帯端末３ａと同様に携帯端末３１ａから発信依頼信号を受信した携帯端末３ｂは、発信依頼信号を受信後に仮想ビーコン信号を受信したため、何も処理することなく仮想ビーコン信号発信処理を終了する。

図４（ｄ）において、携帯端末３ａの仮想ビーコン信号を受信した携帯端末３１ａは、発信依頼信号を停止する。

以上の通り携帯端末は、他の携帯端末から発信依頼を受けて特定の条件を満たした場合にのみ仮想ビーコン信号を発信することにより、不要に多数の携帯端末が仮想ビーコン信号を発信するのを防止することが出来る。

図５は、仮想ビーコン信号を発信する携帯端末が検知対象のエリア外に移動した場合の処理を示す概念図である。図５（ａ）は、携帯端末３ａが検知対象４ａの仮想ビーコン信号をエリア７ｂで発信している状態を示す。図５（ｂ）は、携帯端末３ａが検知対象４ａのエリア６ａの外部に移動し、仮想ビーコン信号の発信を停止した状態を示す。図５（ｃ）は、携帯端末３１ａが再度仮想ビーコン信号の発信依頼を行う状態を示す。図５（ｄ）は、発信依頼信号を受信した携帯端末３ｂが、仮想ビーコン信号の発信を開始した状態を示す。

図５（ａ）において、携帯端末３１ａは、携帯端末３ａから発信される仮想ビーコン信号を受信している場合、発信依頼信号の発信を停止する。図５（ｂ）において、携帯端末３ａが検知対象４ａから発信されるビーコン信号のエリア６ａの外に移動すると、仮想ビーコン信号の発信を停止する。図５（ｃ）において、携帯端末３１ａは、仮想ビーコン信号が受信できなくなると、再度発信依頼信号の発信を開始する。図５（ｄ）において、検知対象４ａのエリア６ａの内部にある携帯端末３ｂは、携帯端末３１ａの発信依頼信号を受信し、仮想ビーコン信号の発信を行う。

以上の通り情報処理システムは、仮想ビーコン信号を発信する携帯端末がビーコン信号を受信可能なエリアの外に出た場合であっても、ビーコン信号を受信する他の携帯端末に対し、仮想ビーコン信号の発信動作を切り替えることが出来る。

図６は、他の携帯端末からの発信依頼を受信した携帯端末の動作を示す概念図である。図６（ａ）は、携帯端末３ａから発信される仮想ビーコン信号のエリア７ｂの内部に、発信依頼を行う携帯端末３１ａ、３１ｂが存在する状態を示す。図６（ｂ）は、仮想ビーコン信号を発信する携帯端末３ａが、検知対象４ａのビーコン信号のエリア６ａの外部に移動し、仮想ビーコン信号の発信が停止した状態を示す。図６（ｃ）は、携帯端末３１ａが仮想ビーコン信号の発信依頼を行い、携帯端末３１ｂは携帯端末３１ａの発信依頼信号を受信し、発信依頼信号を発信していない状態を示す。図６（ｄ）は、携帯端末３１ａから送信された発信依頼信号を受信した携帯端末３ｂが、仮想ビーコン信号を発信する状態を示す。

以上の通り情報処理システムは、１つのビーコン信号受信可能エリアに発信依頼を行う携帯端末が複数存在する場合であっても、１つの携帯端末に発信依頼動作を特定することが出来る。

図７は、発信依頼を行う携帯端末が、担当する動作を変更する状態を示す概念図である。図７（ａ）は、検知対象４ａのビーコン信号を受信可能なエリア６ａに、発信依頼を行う携帯端末３１ａ、３１ｂのみが存在する状態を示す。図７（ｂ）は、発信依頼を行う携帯端末３１ａが発信依頼を行った後、仮想ビーコン信号の受信がないために自身の担当を発信依頼から仮想ビーコン信号の送信に変更した状態を示す。図７（ｃ）は、携帯端末３１ｂが仮想ビーコン信号の発信依頼を行っている状態を示す。図７（ｄ）は、携帯端末３１ｂから発信された発信依頼信号を受けて、携帯端末３１ａが仮想ビーコン信号を発信している状態を示す。ここで担当とは、携帯端末にあらかじめ設定された、複数の動作モードを示す。

図７（ａ）に示す通り、検知対象４ａのビーコン信号を受信可能なエリアに仮想ビーコン信号を送信可能な携帯端末が存在しない場合、携帯端末３１ａ、３１ｂによる発信依頼は無駄になる。そこで、携帯端末３１ａ、３１ｂから発信依頼を行っても、仮想ビーコン信号を送信する携帯端末が出現しない場合、図７（ｂ）に示す通り、発信依頼を行う携帯端末３１ａを仮想ビーコン信号を発信する携帯端末に担当変更する。これにより、発信依頼を行う他の携帯端末３１ｂに対し、図７（ｃ）に示す通り、携帯端末３１ａが応答可能となる。この結果、図７（ｄ）に示す通り、携帯端末３１ａが発信依頼を受けて仮想ビーコン信号を発信することが出来る。

図８は、発信依頼を行う携帯端末を変更する状態を示す概念図である。図８（ａ）は、携帯端末３１ａが発信依頼を行い、発信依頼信号を受信した携帯端末３１ｂは何も処理を実行していない状態を示す。図８（ｂ）は、発信依頼信号の送信に対し仮想ビーコン信号が受信されないため、携帯端末３１ａが発信依頼の担当を変更した状態を示す。図８（ｃ）は、発信依頼の担当変更後、携帯端末３１ｂが発信依頼を行っている状態を示す。図８（ｄ）は、発信依頼信号の送信に対し仮想ビーコン信号が受信されないため、携帯端末３１ｂが発信依頼の担当を変更した状態を示す。

以上の通り発信依頼を行う携帯端末は、仮想ビーコン信号を発信する様、担当変更をしながら、発信依頼を定期的に行う。発信依頼を行う携帯端末を担当変更することにより、発信依頼信号を発信するエリアを分散させることが出来る。

図９は、携帯端末からの発信依頼を分散させる様子を示すタイムチャートである。図９において、上から順に、携帯端末３１ａ、３１ｂ、３１ｃのタイムチャートを示す。本実施形態において、携帯端末３１ａにはｍｉｎｏｒ値として１０、携帯端末３１ｂにはｍｉｎｏｒ値として２０、携帯端末３１ｃにはｍｉｎｏｒ値として１５が割り当てられている。本実施例において、それぞれの携帯端末３１にはｍｉｎｏｒ値がランダムに割り当てられている。

ｍｉｎｏｒ値の初期値は、以下のように決定することもできる。携帯端末３によりこのシステムが利用される時刻を元に計算し、近い時刻に利用を開始した端末のｍｉｎｏｒ値を近い値とする。ｍｉｎｏｒ値が近いことで、発信依頼からの仮想ビーコン発信が早くなり、かつ、担当ビーコン喪失による仮想ビーコン発信停止からの発信依頼までの待ち時間が長くなる。これは、同じ移動をする場合に効果を発揮する。つまり、開始時刻が近い携帯端末３は、グループであると考えられるため、ｍｉｎｏｒ値を近づけて、上記の効果を狙っている。また、検知対象のビーコンの数の多さにより、ｍｉｎｏｒ値をばらけさせることも効果的である。ビーコンの数が少ないときは、担当を変える必要が少なく、ｍｉｎｏｒ値をばらけさせずに設定する。これにより、発信依頼からの仮想ビーコン発信が早くなる。ビーコンの数が多いときは、担当を変えながら検知対象のビーコンを検知することになるため、ｍｉｎｏｒ値をばらけさせる。これにより、発信依頼の待ち時間が短くなり、仮想ビーコン発信が行われない場合の担当変更が早く行われるようになる。

携帯端末３１ａは、時刻Ｔ１から時刻Ｔ２まで、時間ｒａの間発信依頼を行う。携帯端末３１ａは、発信依頼終了後、あらかじめ設定された待ち時間の間待機状態となる。携帯端末３１ａの発信依頼を受信した他の携帯端末は、受信した携帯端末３１ａのｍｉｎｏｒ値と自身のｍｉｎｏｒ値との差分に応じて待ち時間を設定する。本実施形態において、各携帯端末はｍｉｎｏｒ値の差分が大きいほど待ち時間を短く設定する。例えば、各携帯端末は、発信依頼信号に含まれるｍｉｎｏｒ値と自身のｍｉｎｏｒ値との差分の逆数に基づき、待ち時間を設定しても良い。本実施形態において、携帯端末３１ｂのｍｉｎｏｒ値は２０であり、携帯端末３１ａのｍｉｎｏｒ値は１０であるので、その差分値は１０となる。同様に、携帯端末３１ａと携帯端末３１ｃとのｍｉｎｏｒ値の差分値は５となる。よって差分値は携帯端末３１ｂの方が大きいため、待ち時間は携帯端末３１ｃよりも短くなる。以上の通りｍｉｎｏｒ値の差分値に基づき待ち時間を決定することにより、それぞれの携帯端末の待ち時間を分散させることが出来る。

携帯端末３１ｂは、時刻Ｔ２から上記差分に対応する待ち時間経過後、時間ｒｂの間発信依頼を行う。携帯端末３１ｂが発信依頼を開始した時刻Ｔ３において、携帯端末３１ａ、３１ｃはまだ待ち状態となっている。それぞれの携帯端末は、携帯端末３１ｂが発信依頼を開始した時刻Ｔ３から、それぞれの携帯端末の待ち時間が終了するまでの時間を、携帯端末３１ｂが発信依頼を終了する時刻Ｔ４からの待ち時間に加算する。例えば携帯端末３１ａは、時刻Ｔ３から待ち時間終了までの時間ｗａの間、時刻Ｔ４から待機状態となる。同様に携帯端末３１ｃは、時刻Ｔ３から待ち時間終了までの時間ｗｃの間、時刻Ｔ４から待機状態となる。また、発信依頼を行う携帯端末３１ｂ以外の携帯端末の待ち時間は、携帯端末３１ａが発信依頼を行っていた場合と同様に、発信依頼を行う携帯端末３１ｂのｍｉｎｏｒ値に対するそれぞれの携帯端末のｍｉｎｏｒ値の差分値に基づいて決定する。本実施例では携帯端末３１ｂのｍｉｎｏｒ値に対する差分値は携帯端末３１ａの方が大きいため、携帯端末３１ａの待ち時間は、携帯端末３１ｃの待ち時間よりも短くなる。一方、時刻Ｔ４からの携帯端末３１ａの待ち時間ｗａは、携帯端末３１ｃの待ち時間ｗｃよりも大きいため、時刻Ｔ４からの待ち時間は、携帯端末３１ａよりも携帯端末３１ｃの方が短くなる。よって次に発信依頼を行うのは携帯端末３１ｃとなる。

以上の通りｍｉｎｏｒ値の差分に基づき各携帯端末の待ち時間を決定することに加え、発信依頼により中断された待ち時間を次回の待ち時間に加算することで、発信依頼を行う携帯端末を分散させることが出来る。

図１０は、サーバから携帯端末にルール情報を配信するシステムの機能ブロック図である。サーバ２から携帯端末３へのルール情報の配信は、例えば事前に携帯端末３に対してサーバ２へアクセスするためのアプリケーションをインストールし、アプリケーションの実行により実現しても良い。なお、本実施形態におけるサーバ２は、上述したような携帯端末３の一元管理を行うものではないことには留意されたい。また、本実施形態において、サーバ２によるルール情報の配信は必須ではない。

サーバ２は、ルール情報４１、ルール配信部４２を有する。ルール情報４１は、後述するサーバ２におけるメモリ１３またはストレージ１４に記憶されている。ルール情報４１は、登録ルール情報、全ルール情報、通知情報を含む。登録ルール情報は、通知ルール情報と発信依頼ルール情報を含む。通知ルール情報は、各携帯端末３のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に登録する、通知のための受発信用ビーコン情報である。通知ルール情報は、ＵＵＩＤのみで構成されている。発信依頼ルール情報は、ＯＳに登録する発信依頼の受発信用ビーコン情報である。発信依頼ルール情報は、ＵＵＩＤおよびｍａｊｏｒで構成されている。全ルール情報は、全ての検出対象４のリストである。全ルール情報は、各検出対象４のＵＵＩＤ、ｍａｊｏｒ、およびｍｉｎｏｒを有する。通知情報は、携帯端末３自身が仮想ビーコン信号の発信源として動作する場合に通知する情報である。通知情報は、ルール情報に対応する検出対象４のリストである。

ルール配信部４２は、メモリ１３またはストレージ１４に記憶されたプログラムを後述するサーバ２におけるＣＰＵ１２が実行することにより実現する機能ブロックである。ルール配信部４２は、ルール情報４１に基づき、各携帯端末３に必要なルール情報を配信する。

携帯端末３は、ルール受信部４３、通知発信部４４、発信依頼部４５、担当変更部４６、イベント受信部４７、ルール情報４８、通知情報４９、関係性情報５０、検知情報５１を有する。ルール受信部４３、通知発信部４４、発信依頼部４５、担当変更部４６、イベント受信部４７は、メモリ２３またはストレージ２４に記憶されたプログラムをＣＰＵ２２が実行することにより実現する機能ブロックである。

ルール受信部４３は、サーバ２から配信されたルール情報に基づき、各携帯端末３のルール情報４８および通知情報４９を保存する。ルール受信部４３の処理の詳細については後述する。イベント受信部４７は、各携帯端末３におけるイベントの種類を判断し、各イベントの種類に応じて処理を実行する。イベント受信部４７の処理の詳細については後述する。通知発信部４４は、イベント受信部４７により判断したイベントの種類に基づいて通知発信処理を実行する。通知発信部４４の処理の詳細については後述する。発信依頼部４５は、他の携帯端末３に対し仮想ビーコン信号の発信を依頼する。発信依頼部４５の処理の詳細については後述する。担当変更部４６は、各携帯端末３に割り当てられた担当ルールを変更する。担当変更部４６の処理の詳細については後述する。

ルール情報４８は、前述のサーバ２におけるルール情報４１と同様に、登録ルール情報および全ルール情報を有する。通知情報４９は、ルール情報４１に含まれる通知情報と同様に、携帯端末３自身が仮想ビーコン信号の発信源として動作する場合に通知する情報である。関係性情報５０は、整数の情報であり、例えばｉＢｅａｃｏｎでは、ｍｉｎｏｒ値が対応する。検知情報５１は、担当ルールの検知状況および通知状況を示す情報である。検知状況は、携帯端末３が担当する検知対象４を検知または非検知であることを示す。通知状況は、携帯端末３が担当する検知対象４の仮想ビーコン信号を通知中、通知待ち、非通知のいずれの状況であるかを示す。検知情報５１は、ルールに対応するビーコン情報のリストに対する検知状況であってもよい。

以上の通り、各携帯端末３は、事前にサーバ２に接続することにより、登録ルール情報、全ルール情報、および通知情報を把握することが出来る。

図１１は、サーバのハードウェアブロック図である。サーバ２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２、メモリ１３、ストレージ１４、ネットワークＩＦ（ＩｎｔｅｒＦａｃｅ）１５を有する。ＣＰＵ１２、メモリ１３、ストレージ１４、およびネットワークＩＦ１５は、バス１６により互いに接続され、データ通信可能となっている。メモリ１３およびストレージ１４はそれぞれ、情報を記憶する記憶部の一つである。

ＣＰＵ１２は、ストレージ１４またはメモリ１３に記憶されたソフトウェアプログラムを読み出して実行する。メモリ１３は、ストレージ１４から読み出したデータや、ネットワークＩＦ１５により外部から受信したデータなどを一時的に記憶する。ストレージ１４は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やソフトウェアプログラム、プログラムの実行時に参照されるデータなどを記憶する。ネットワークＩＦ１５は、ネットワーク５を介して他の装置とデータの送受信を行う。

図１２は、ルール情報の具体例である。図１２（ａ）は、登録ルール情報の具体例を示す。図１２（ｂ）は、全ルール情報の具体例を示す。

図１２（ａ）において、列６１は登録ルール情報の各構成要素である通知ルール情報および発信依頼ルール情報を示す。列６２は各ルール情報のＵＵＩＤを示す。列６３は各ルール情報のｍａｊｏｒを示す。列６２および列６３に示す通り、通知ルール情報はＵＵＩＤのみを有する。発信依頼ルール情報は、通知ルール情報のＵＵＩＤと同じ値のＵＵＩＤを有する。発信依頼ルール情報のＵＵＩＤの値は、通知ルール情報のＵＵＩＤと違う値に設定しても良い。

図１２（ｂ）において、列６４は検知対象を示す。列６５はそれぞれの検知対象４のＵＵＩＤを示す。列６６はそれぞれの検知対象４のｍａｊｏｒ番号を示す。列６７はそれぞれの検知対象４のｍｉｎｏｒ番号を示す。

図１３は、ルール情報に対応する通知情報の具体例である。図１３（ａ）は、全ルール情報の具体例を示す。図１３（ｂ）は、通知情報を示す。図１３（ａ）の内容は図１２（ｂ）と同じであるが、説明のために再掲する。

図１３（ｂ）において、列７５は各携帯端末３に割り当てられる検知対象４を示す。列７６は、検知対象４のいずれかが割り当てられた場合に、携帯端末３から発信するビーコン信号のＵＵＩＤである。このＵＵＩＤは、図１２（ａ）の通知ルール情報のＵＵＩＤである。列７７は、検知対象４のいずれかが割り当てられた場合に、携帯端末３から発信するビーコン信号のｍａｊｏｒ番号である。図１３（ｂ）に示す通知情報は、全ての携帯端末３に記憶される。携帯端末３に登録可能なＵＵＩＤには、ＯＳ上の制約が存在する場合がある。図１３（ｂ）の列７６に示す通り、各検知対象４に対応して携帯端末から発信するビーコン信号のＵＵＩＤを同じにし、列７７に示す通りｍａｊｏｒ番号が同じ値にならないようにすることにより、ＯＳの制約を解消しつつ、各携帯端末３から発信されるビーコン信号を区別することが出来る。

図１４は、サーバから各携帯端末にルール情報を配信する場合の処理フローである。携帯端末３は、サーバ２から全ルール情報を受信し、ルール情報と通知情報に保存する（ステップＳ１１）。携帯端末３は、受信した全ルール情報に基づき、担当ルールを決定し、ルール情報の担当ルールとして保存する（ステップＳ１２）。携帯端末３は、関係性情報の初期値を算出し、関係性情報として保存する（ステップＳ１３）。初期値の算出は、例えば乱数計算により行う。算出された初期値は、例えばｍｉｎｏｒ番号として保存する。携帯端末３は、検知情報を全て非検知と非通知に初期化する（ステップＳ１４）。携帯端末３は、ルール情報の登録ルール（担当ルール、通知ルール、発信依頼ルール）を自身のＯＳに登録する（ステップＳ１５）。携帯端末３は、検知対象４を検知した時と喪失した時、および仮想ビーコン検知と喪失時、発信依頼ビーコン検知と喪失時にＯＳのイベントを実行し、イベント受信の処理を行う。

以上の通り携帯端末３は、サーバ２から事前に受信した全ルール情報に基づき、各種情報の設定を行うことが出来る。

図１５Ａおよび図１５Ｂは、携帯端末におけるイベント受信時の処理フローである。図１５Ａと図１５Ｂとの処理は、丸で囲まれた符号Ａ、Ｂ、Ｃにより接続される。

携帯端末３は、イベント情報を受信すると、受信したイベント情報が担当ルール、通知ルール、発信依頼ルールのいずれであるかを判別する（ステップＳ２１）。

携帯端末３は、イベント情報が担当ルールである場合（ステップＳ２１：担当ルール）、検知情報を更新する（ステップＳ２２）。携帯端末３は、担当ルールが検知か非検知かを判定する（ステップＳ２３）。携帯端末３は、担当ルールが非検知である場合（ステップＳ２３：非検知）、通知発信に処理を移す（ステップＳ２４）。携帯端末３は、検知情報に検知があるか否かを判別する（ステップＳ２６）。携帯端末３は、検知情報に検知がない場合（ステップＳ２６：ＮＯ）、発信依頼に処理を移す（ステップＳ２７）。ここで発信依頼処理は、外部の携帯端末への発信依頼信号の送信を周期的に行う処理である。携帯端末３は、検知情報に検知がある場合（ステップＳ２６：ＹＥＳ）、処理を終了する。携帯端末３は、担当ルールが検知である場合（ステップＳ２３：検知）、発信依頼に処理を移す（ステップＳ２５）。

携帯端末３は、イベント情報が通知ルールである場合（ステップＳ２１：通知ルール）、検知情報を更新する（ステップＳ２８）。携帯端末３は、通知ルールが検知か非検知かを判定する（ステップＳ２９）。携帯端末３は、通知ルールが非検知である場合（ステップＳ２９：非検知）、ステップＳ２６の処理に進む。携帯端末３は、通知ルールが検知である場合（ステップＳ２９：検知）、発信依頼に処理を移す（ステップＳ３０）。携帯端末３は、発信依頼を周期的に行うモードとなっている場合には、発信依頼をキャンセルする。発信依頼中であれば、関係性情報を補正する。携帯端末３は、通知発信に処理を移す（ステップＳ３１）。携帯端末３は、担当ルールに対応する通知であれば、通知待ちをキャンセルする。

携帯端末３は、イベント情報が発信依頼ルールである場合（ステップＳ２１：発信依頼ルール）、発信依頼ルールが検知か非検知かを判定する（ステップＳ３２）。携帯端末３は、発信依頼ルールが検知である場合（ステップＳ３２：検知）、通知発信に処理を移し（ステップＳ３３）、その後発信依頼に処理を移す（ステップＳ３４）。携帯端末３は、担当ルール検知中であれば、通知待ちに入る。携帯端末３は、発信依頼ルールが非検知である場合（ステップＳ３２：非検知）、発信依頼に処理を移す（ステップＳ３４）。携帯端末３は、周期モード中であれば、非検知で待ち状態となり、検知で待機となる。

図１６は、携帯端末における通知発信の処理フローである。携帯端末３は、外部からの依頼信号により呼ばれた理由を判定する（ステップＳ４１）。

携帯端末３は、呼ばれた理由が担当ルール非検知である場合（ステップＳ４１：担当ルール非検知）、通知状況が通知中であるか否かを判定する（ステップＳ４２）。携帯端末３は、通知状況が通知中である場合（ステップＳ４２：ＹＥＳ）、通知発信を停止し（ステップＳ４３）、通知状況を非通知に変更する（ステップＳ４４）。携帯端末３は、通知状況が通知中でない場合（ステップＳ４２：ＮＯ）、通知発信処理を終了する。

携帯端末３は、呼ばれた理由が通知ルール検知である場合（ステップＳ４１：通知ルール検知）、担当ルールに対応する通知ルールか否かを判定する（ステップＳ４５）。携帯端末３は、検知した通知ルールが担当ルールに対応するものである場合（ステップＳ４５：ＹＥＳ）、担当ルールの通知状況が通知待ちか否かを判定する（ステップＳ４６）。携帯端末３は、担当ルールの通知状況が通知待ちである場合（ステップＳ４６：ＹＥＳ）、タイマーをキャンセルし（ステップＳ４７）、通知状況を非通知に変更する（ステップＳ４８）。携帯端末３は、検知した通知ルールが担当ルールに対応しない場合（ステップＳ４５：ＮＯ）、または担当ルールの通知状況が通知待ちでない場合（ステップＳ４６：ＮＯ）、通知発信処理を終了する。

携帯端末３は、呼ばれた理由が発信依頼ルール検知である場合（ステップＳ４１：発信依頼ルール検知）、担当ルールで検知中があるか否かを判定する（ステップＳ４９）。携帯端末３は、担当ルールで検知中がある場合（ステップＳ４９：ＹＥＳ）、検知中のルールの通知状況を通知待ちに変更し（ステップＳ５０）、待ち時間を計算してタイマーを設定する（ステップＳ５１）。携帯端末３は、担当ルールで検知中が無い場合（ステップＳ４９：ＮＯ）、通知発信処理を終了する。

図１７は、携帯端末の通知発信におけるタイマー起動の処理フローである。図１７の処理フローは、図１６のタイマーに関する処理をより詳細に説明したものである。携帯端末３は、次の通知発信までの待ち時間が設定されているか確認する（ステップＳ６１）。携帯端末３は、待ち時間が設定されている場合（ステップＳ６１：ＹＥＳ）、タイマーを設定する（ステップＳ６２）。携帯端末３は、待ち時間が設定されていない場合（ステップＳ６１：ＮＯ）、処理を終了する。

携帯端末３は、設定した待ち時間が経過したか否かを確認する（ステップＳ６３）。携帯端末３は、設定した待ち時間が経過した場合（ステップＳ６３：ＹＥＳ）、検出中の担当ルールの通知発信を行う（ステップＳ６４）。携帯端末３は、通知状況を”通知中”に変更し（ステップＳ６５）、処理を終了する。携帯端末３は、設定した待ち時間が経過しておらず（ステップＳ６３：ＮＯ）、外部からの通知ルール検知等によりタイマーをキャンセルした場合（ステップＳ６６：ＹＥＳ）、処理を終了する。携帯端末３は、設定した待ち時間が経過しておらず（ステップＳ６３：ＮＯ）、タイマーもキャンセルされていない場合（ステップＳ６６：ＮＯ）、待ち時間が経過するまで再度待機する。

図１８Ａおよび図１８Ｂは、携帯端末における発信依頼の処理フローである。図１８Ａと図１８Ｂとの処理は、丸で囲まれた符号Ｄ、Ｅにより接続される。携帯端末３は、初期状態として、発信依頼を周期的に行うモードとなっている。周期的に行うモードにおいて携帯端末３は、待ち時間を決定し、タイマーを設定している状態となる。

携帯端末３は、外部からの呼び出しを受けると、呼ばれた理由が検知か否かを判定する（ステップＳ７１）。携帯端末３は、呼ばれた理由が検知である場合（ステップＳ７１：ＹＥＳ）、検知したルールを判定する（ステップＳ７３）。携帯端末３は、検知したルールが担当ルールである場合（ステップＳ７３：担当ルール）、発信依頼の周期モードを解除する（ステップＳ７２）。周期モードの解除において携帯端末３は、発信依頼中であれば発信を停止し、待ちの状態であればタイマーをキャンセルし、処理を終了する。

携帯端末３は、検知したルールが通知ルールである場合（ステップＳ７３：通知ルール）、発信依頼中であるか否かを判定する（ステップＳ７４）。携帯端末３は、発信依頼中である場合（ステップＳ７４：ＹＥＳ）、発信を停止し（ステップＳ７５）、通知ルールのｍｉｎｏｒ値に基づき関係性情報を補正する（ステップＳ７６）。携帯端末３は、周期モードであれば、周期モードを解除し（ステップＳ７７）、タイマーをキャンセルする。携帯端末３は、発信依頼中でない場合（ステップＳ７４：ＮＯ）、周期モードを解除する（ステップＳ７７）。

携帯端末３は、検知したルールが発信依頼ルールであり（ステップＳ７３：発信依頼ルール）、周期モードであれば（ステップＳ７８：ＹＥＳ）、タイマーをキャンセルする（ステップＳ７９）。携帯端末３は、検知したルールが発信依頼ルールであり（ステップＳ７３：発信依頼ルール）、周期モードでなければ（ステップＳ７８：ＮＯ）、処理を終了する。

携帯端末３は、外部からの呼び出し理由が非検知である場合（ステップＳ７１：ＮＯ）、非検知となったルールが発信依頼ルールか否かを判定する（ステップＳ８０）。非検知となったルールが発信依頼ルールである場合（ステップＳ８０：ＹＥＳ）、携帯端末３は、周期モードか否かを判定する（ステップＳ８１）。周期モードである場合（ステップＳ８１：ＹＥＳ）、携帯端末３は、ｍｉｎｏｒ値を与えて発信依頼ルールの非検知待ちを解除し（ステップＳ８２）、処理を終了する。

携帯端末３は、非検知となったルールが発信依頼ルールでない場合（ステップＳ８０：ＮＯ）、または周期モードでない場合（ステップＳ８１：ＮＯ）、周期モードに移行し（ステップＳ８３）、処理を終了する。

以上の通り携帯端末３は、発信依頼処理を行うことが出来る。

図１９は、携帯端末の発信依頼におけるタイマー起動の処理フローである。携帯端末３は、図１９の処理フローに基づき、タイマー起動の発信依頼を行う。ステップＳ８３の周期モード移行指示により、図１９の処理が開始される。

携帯端末３は、周期モード開始時刻を保持し（ステップＳ９１）、タイマーを設定する（ステップＳ９２）。携帯端末３は、保持した周期モード開始時刻に基づき、タイマー設定した時間が経過したか否かを判定する（ステップＳ９３）。携帯端末３は、設定した時間が経過している場合（ステップＳ９３：ＹＥＳ）、発信依頼を行う（ステップＳ９４）。携帯端末３は、設定した時間が経過していない場合（ステップＳ９３：ＮＯ）、ステップＳ７９によりタイマーがキャンセルされているか否かを判定する（ステップＳ１０１）。携帯端末３は、タイマーをキャンセルする場合（ステップＳ１０１：ＹＥＳ）、タイマーの残り時間を保持し（ステップＳ１０２）、発信依頼非検知待ちとなる（ステップＳ１０３）。ステップＳ８２で非検知待ちを解除されない限り次の処理には進まない。携帯端末３は、タイマーをキャンセルしない場合（ステップＳ１０１：ＮＯ）、設定時間を経過したか否かの判定を繰り返す（ステップＳ９３）。

携帯端末３は、発信依頼を実行（ステップＳ９４）後、もしくは、発信依頼非検知待ちを解除された（ステップＳ１０３）後、周期モードを解除するかどうかを判定する（ステップＳ９５）。周期モードを解除する場合（ステップＳ９５：ＹＥＳ）、携帯端末３は発信依頼処理のタイマー起動の処理を終了する。周期モード解除は、ステップＳ７２やステップＳ７７にて指示される。携帯端末３は、周期モードを解除しない場合（ステップＳ９５：ＮＯ）、周期モード経過時間を計測する（ステップＳ９６）。携帯端末３は、周期モードの経過時間が閾値を超えた場合（ステップＳ９７：ＹＥＳ）、担当変更に処理を移し（ステップＳ１０４）、周期モード開始時刻保持に戻る（ステップＳ９１）。携帯端末３は、周期モードの経過時間が閾値を超えていない場合（ステップＳ９７：ＮＯ）、待ち時間を計算し（ステップＳ９８）、残り時間を待ち時間に加算し（ステップＳ９９）、タイマー設定処理に戻る（ステップＳ９２）。

以上の通り携帯端末３は、外部に対し発信依頼処理を行うことが出来る。

図２０は、携帯端末における担当変更処理の詳細なフローである。図２０は、図１９におけるステップＳ１０４をより詳細に説明するものである。

担当変更処理において、携帯端末３は、メモリ２３またはストレージ２４に記憶されたルール情報を参照し、担当ルールおよび全ルールを取得する（ステップＳ１１１）。携帯端末３は、ＯＳに登録している担当ルールを解除する（ステップＳ１１２）。携帯端末３は、新たな担当ルールを決定し、ルール情報としてメモリ２３またはストレージ２４に保存する（ステップＳ１１３）。携帯端末３は、新たな担当ルールをＯＳに登録する（ステップＳ１１４）。

以上の通り携帯端末３は、ルール情報に基づき、担当ルールを変更することが出来る。

発信依頼や通知発信のタイマー起動の待ち時間制御において、待ち時間の計算に以下の要素を加味することも可能である。携帯端末の加速度センサーなどから移動速度を計算し、移動速度が速い携帯端末の待ち時間は長くする。移動速度が速い携帯端末は、検知対象のビーコンから離れる可能性が高いため、待ち時間を長くすることで、発信依頼や通知発信を行いづらくする。これにより、無駄な発信依頼の回数を減らすことが可能である。また、検知対象のビーコンを検知している場合の電波強度に応じて待ち時間を設定することも効果がある。電波強度が弱い場合は、ビーコン喪失の可能性が高いため、待ち時間を長く設定する。

携帯端末により仮想ビーコン発信を行うことを述べてきたが、検知対象のビーコンにて仮想ビーコン発信を行う構成も可能である。この場合、ビーコンは、常時検知対象としてのビーコン発信は行わない。携帯端末からの発信依頼により、仮想ビーコン発信を一定期間行う。このような構成とすることにより、発信よりも受信の方が消費電力が少ないため、常時発信し続ける場合と比べて、ビーコンの電池が長持ちする。また、携帯端末側にて仮想ビーコン発信を行う必要がなくなり、携帯端末にも省電力の効果がある。

１：情報処理システム
２：サーバ
３：携帯端末
４：検知対象
４１：ルール情報
４２：ルール配信部
４３：ルール受信部
４４：通知発信部
４５：発信依頼部
４６：担当変更部
４７：イベント受信部
４８：ルール情報
４９：通知情報
５０：関係性情報
５１：検知情報

Claims (8)

1. 所定情報を含む検知信号を無線送信する検知対象と、
   前記検知信号の受信に基づいて前記所定情報を含む仮想検知信号を無線送信する複数の特定無線端末と、
   前記検知信号と前記仮想検知信号のいずれも受信できない場合、前記仮想検知信号の発信を依頼する発信依頼信号を無線送信する無線端末と
   を有し、
   前記特定無線端末は、前記発信依頼信号を受信した場合であっても、他の前記特定無線端末から前記仮想検知信号を受信した場合には、前記仮想検知信号の無線送信を行わないことを特徴とする情報処理システム。
2. 前記特定無線端末は、前記検知信号を受信しなくなると前記仮想検知信号の無線送信を停止する
   請求項１に記載の無線通信システム。
3. 前記無線端末は、前記仮想検知信号を受信しなくなると、前記発信依頼信号を再送信する
   請求項１に記載の情報処理システム。
4. 前記無線端末は、所定時間を経過するまで前記発信依頼信号の無線送信を待つ
   請求項１に記載の情報処理システム。
5. 前記所定時間は、前記無線端末毎に異なる時間を設定可能である
   請求項４に記載の情報処理システム。
6. 前記特定無線端末及び前記無線端末は移動無線端末である
   請求項１に記載の情報処理システム。
7. 前記検知対象は前記検知信号を所定周期で送信する
   請求項１に記載の情報処理システム。
8. 検知対象の識別情報を含むビーコン信号を周期的に無線送信するように構成されたビーコンを含む情報処理システムにおける特定無線端末であって、
   前記情報処理システムにおける無線端末から発信依頼信号を受信した場合、前記ビーコンから受信した前記ビーコン信号に基づいて前記検知対象の識別情報を含む仮想ビーコン信号を周期的に無線送信することで、前記無線端末に対して疑似的にビーコンを装う制御部
   を有し、
   前記制御部は、前記発信依頼信号を受信した場合であっても、他の特定無線端末から前記仮想ビーコン信号を受信した場合には、周期的な前記仮想ビーコン信号の無線送信を行わない
   ことを特徴とする特定無線端末。

Images