(57)【要約】【課題】検出装置で入力された情報に基づいて生成された通知情報を、送信先毎に適したタイミングで送信する。【解決手段】送信先と、送信するタイミングを保持する送信タイプと、を対応付けて保持するサービスフィルタテーブルを記憶する記憶部と、アクティブタグを検出したリーダから入力された情報に基づいて、通知情報を生成する通知情報生成部と、サービスフィルタテーブルの送信タイプにより定められる送信するタイミングに従って、生成された通知情報を、送信タイプと対応付けられている送信先に送信する送信処理部と、を備える。【選択図】        図１
2007079865.tif 000002
【特許請求の範囲】
【請求項１】
送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報を記憶する記憶手段と、
携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成手段と、
前記記憶手段に記憶された前記送信対応情報の前記送信タイミング情報に従って、前記通知情報生成手段により生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信手段と、
を備えたことを特徴とする情報送信装置。
【請求項２】
前記記憶手段は、前記送信対応情報の前記送信タイミング情報として前記時間間隔を記憶し、
前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記時間間隔毎に、前記通知情報を前記時間間隔と対応付けられた前記送信先に送信すること、
を特徴とする請求項１に記載の情報送信装置。
【請求項３】
前記記憶手段は、前記送信対応情報の前記送信タイミング情報として所定の送信判断数を記憶し、
前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記送信判断数と、前記通知情報生成手段により前記通知情報が生成された回数の比較結果に基づいて前記通知情報を、前記送信判断数と対応付けられている前記送信先に送信すること、
を特徴とする請求項１に記載の情報送信装置。
【請求項４】
前記記憶手段は、前記送信対応情報の前記送信タイミング情報として所定の継続時間とを記憶し、
前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記所定の継続時間の間、前記通知情報生成手段で生成された通知情報に基づいて所定の条件を満足する状態が継続していると判断した場合に、前記通知情報を前記所定の継続時間と対応付けられた前記送信先に送信すること、
を特徴とする請求項１に記載の情報送信装置。
【請求項５】
前記送信手段は、送信する条件を満たした場合に前記送信先毎に前記通知情報を圧縮する圧縮手段を備え、前記圧縮手段により圧縮された前記通知情報を前記送信先に送信すること、
を特徴とする請求項１乃至４のいずれか１つに記載の情報送信装置。
【請求項６】
前記送信手段は、送信する条件を満たした場合に前記送信先に送信する前記通知情報から所定の条件を満たした通知情報を抽出する抽出手段を備え、前記抽出手段により抽出された該通知情報を前記送信先に送信すること、
を特徴とする請求項１乃至５のいずれか１つに記載の情報送信装置。
【請求項７】
情報を受信する受信手段を、さらに備え、
前記記憶手段は、前記送信対応情報として、情報の送信先と、送信タイミング情報に、さらに送信条件を対応付けて保持し、
前記通知情報生成手段は、携帯型情報記憶媒体を検出した検出装置から入力された情報が一方の前記送信条件を満足した場合に、通知情報を生成し、
前記送信手段は、前記送信条件を満たした場合に前記通知情報を、一方の前記送信条件と対応付けられた前記送信先である自装置に送信し、
前記受信手段は、前記送信手段から送信された前記通知情報を受信し、
前記通知情報生成手段は、さらに前記受信手段から受信した前記通知情報が、他方の前記送信条件を満足した場合に、通知情報を生成すること、
を特徴とする請求項１乃至６のいずれか１つに記載の情報送信装置。
【請求項８】
携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成ステップと、
送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報の前記送信タイミング情報に従って、前記通知情報生成ステップにより生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信ステップと、
を備えたことを特徴とする情報送信方法。
【請求項９】
前記送信ステップは、前記送信先と、時間間隔と、を対応付けて保持する送信対応情報の該時間間隔毎に、前記通知情報を該時間間隔と対応付けられた前記送信先に送信すること、
を特徴とする請求項８に記載の情報送信方法。
【請求項１０】
前記送信ステップは、前記送信先と、所定の送信判断数と、を対応付けて保持する前記送信対応情報の該送信判断数と、前記通知情報生成ステップにより前記通知情報が生成された回数の比較結果に基づいて前記通知情報を、前記送信判断数と対応付けられている前記送信先に送信すること、
を特徴とする請求項８に記載の情報送信方法。
【請求項１１】
前記送信ステップは、前記送信先と、所定の継続時間と、を対応付けて保持する前記送信対応情報の前記所定の継続時間の間、前記通知情報生成ステップで生成された通知情報に基づいて所定の条件を満足する状態が継続していると判断した場合に、前記通知情報を前記所定の継続時間と対応付けられた前記送信先に送信すること、
を特徴とする請求項８に記載の情報送信方法。
【請求項１２】
前記送信ステップは、送信する条件を満たした場合に前記送信先毎に前記通知情報を圧縮する圧縮ステップを備え、前記圧縮ステップにより圧縮された前記通知情報を前記送信先に送信すること、
を特徴とする請求項８乃至１１のいずれか１つに記載の情報送信方法。
【請求項１３】
前記送信ステップは、送信する条件を満たした場合に前記送信先に送信する前記通知情報から所定の条件を満たした通知情報を抽出する抽出ステップを備え、前記抽出ステップにより抽出された該通知情報を前記送信先に送信すること、
を特徴とする請求項８乃至１２のいずれか１つに記載の情報送信方法。
【請求項１４】
情報を受信する受信ステップを、さらに備え、
前記通知情報生成ステップは、携帯型情報記憶媒体を検出した検出装置から入力された情報が、前記情報の送信先と前記送信タイミング情報と、さらに送信条件とを対応付けて保持する前記送信対応情報の一方の送信条件を満足した場合に、通知情報を生成し、
前記送信ステップは、前記通知情報生成ステップにより生成された前記通知情報を、一方の前記送信条件と対応付けられた前記送信先である自装置に、前記送信条件と対応付けられた前記送信タイミングに従って送信し、
前記受信ステップは、前記送信ステップから送信された前記通知情報を受信し、
前記通知情報生成ステップは、さらに前記受信ステップから受信した前記通知情報が、前記送信対応情報の他方の送信条件を満足した場合に、通知情報を生成すること、
を特徴とする請求項８乃至１３のいずれか１つに記載の情報送信方法。
【請求項１５】
請求項８乃至１４のいずれか１つに記載された情報送信方法をコンピュータで実行させることを特徴とする情報送信プログラム。
【請求項１６】
請求項１５に記載された情報送信プログラムを格納したコンピュータの読み取り可能な記録媒体。
【請求項１７】
物体毎に備えられた携帯型情報記憶媒体と、接触せずに該携帯型情報記憶媒体を検知する検出装置と、該検出装置から入力された情報に基づいて生成した通知情報を送信する情報送信装置と、を備えた情報送信システムにおいて、
前記情報送信装置は、
送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報を記憶する記憶手段と、
携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成手段と、
前記記憶手段に記憶された前記送信対応情報の前記送信タイミング情報に従って、前記通知情報生成手段により生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信手段と、を備えたこと、
を特徴とする情報送信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報送信装置、情報送信方法、情報送信プログラム、コンピュータに読み取り可能な記録媒体及び情報送信システムに関するものであり、特に検出装置から入力された情報に基づいた通知情報を送信するタイミングに関するものである。
【背景技術】
【０００２】
従来、ＲＦＩＤタグ等の無線タグから受信した信号から特定できる屋内での人やモノの位置情報は、物品管理や入退室管理等、さまざまなアプリケーションで利用することが可能である。
【０００３】
そこで、無線タグやＰＨＳ等の複数の端末機器からの情報を取得して一括処理する技術が提案されている。そして、位置を一括して管理することで、各種アプリケーションが容易に位置情報を利用することが可能となる（例えば特許文献１）。
【０００４】
この特許文献１に記載された発明では、アプリケーションサーバが位置情報処理サーバに位置情報の送信を要求することで、位置情報処理サーバから端末機器の位置情報が送信される。これによりアプリケーションサーバは位置情報を得ることができる。
【０００５】
【特許文献１】特開２００２−３１５０３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載された発明では、アプリケーションサーバに対して情報を送信するタイミングについて具体的に明示されていない。これは、位置情報処理サーバは１つのアプリケーションサーバに接続していることした想定していないため、アプリケーションサーバの要求に適した送信処理方法を予め設定しているからと考えられる。
【０００７】
これに対して、位置情報の送信を行うサーバが複数のアプリケーションに対して送信を行う場合、アプリケーション毎に適した送信のタイミングが存在する。例えば、アプリケーションが、３分毎の利用者の位置情報に基づいた処理を行い場合に、位置情報処理サーバが１０秒毎に位置情報を送信しても、送信された位置情報のうち処理に用いられる位置情報は限られていることとなる。逆に、アプリケーションが５秒毎の位置情報を要求しているのに、１０秒毎にしか位置情報処理サーバが位置情報を送信しないという状況も考えられる。
【０００８】
このように引用文献１に記載された発明では、送信先に対して適切なタイミングで情報の送信を行わないので、送信先で適切な処理が行えないという問題がある。
【０００９】
本発明は、上記に鑑みてなされたものであって、送信先に適したタイミングで情報を送信する情報送信装置、情報送信方法、情報送信プログラム、コンピュータに読み取り可能な記録媒体及び情報送信システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報を記憶する記憶手段と、携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成手段と、前記記憶手段に記憶された前記送信対応情報の前記送信タイミング情報に従って、前記通知情報生成手段により生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信手段と、を備えたことを特徴とする。
【００１１】
また、請求項２にかかる発明は、請求項１にかかる発明において、前記記憶手段は、前記送信対応情報の前記送信タイミング情報として前記時間間隔を記憶し、前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記時間間隔毎に、前記通知情報を前記時間間隔と対応付けられた前記送信先に送信すること、を特徴とする。
【００１２】
また、請求項３にかかる発明は、請求項１にかかる発明において、前記記憶手段は、前記送信対応情報の前記送信タイミング情報として所定の送信判断数を記憶し、前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記送信判断数と、前記通知情報生成手段により前記通知情報が生成された回数の比較結果に基づいて前記通知情報を、前記送信判断数と対応付けられている前記送信先に送信すること、を特徴とする。
【００１３】
また、請求項４にかかる発明は、請求項１にかかる発明において、前記記憶手段は、前記送信対応情報の前記送信タイミング情報として所定の継続時間とを記憶し、前記送信手段は、前記記憶手段に記憶された前記送信対応情報の前記所定の継続時間の間、前記通知情報生成手段で生成された通知情報に基づいて所定の条件を満足する状態が継続していると判断した場合に、前記通知情報を前記所定の継続時間と対応付けられた前記送信先に送信すること、を特徴とする。
【００１４】
また、請求項５にかかる発明は、請求項１〜４のいずれか一つにかかる発明において、前記送信手段は、送信する条件を満たした場合に前記送信先毎に前記通知情報を圧縮する圧縮手段を備え、前記圧縮手段により圧縮された前記通知情報を前記送信先に送信すること、を特徴とする。
【００１５】
また、請求項６にかかる発明は、請求項１〜５のいずれか一つにかかる発明において、前記送信手段は、送信する条件を満たした場合に前記送信先に送信する前記通知情報から所定の条件を満たした通知情報を抽出する抽出手段を備え、前記抽出手段により抽出された該通知情報を前記送信先に送信すること、を特徴とする。
【００１６】
また、請求項７にかかる発明は、請求項１〜６のいずれか一つにかかる発明において、情報を受信する受信手段を、さらに備え、前記記憶手段は、前記送信対応情報として、情報の送信先と、送信タイミング情報に、さらに送信条件を対応付けて保持し、前記通知情報生成手段は、携帯型情報記憶媒体を検出した検出装置から入力された情報が一方の前記送信条件を満足した場合に、通知情報を生成し、前記送信手段は、前記送信条件を満たした場合に前記通知情報を、一方の前記送信条件と対応付けられた前記送信先である自装置に送信し、前記受信手段は、前記送信手段から送信された前記通知情報を受信し、前記通知情報生成手段は、さらに前記受信手段から受信した前記通知情報が、他方の前記送信条件を満足した場合に、通知情報を生成すること、を特徴とする。
【００１７】
また、請求項８にかかる発明は、携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成ステップと、送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報の前記送信タイミング情報に従って、前記通知情報生成ステップにより生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信ステップと、を備えたことを特徴とする。
【００１８】
また、請求項９にかかる発明は、請求項８にかかる発明において、前記送信ステップは、前記送信先と、時間間隔と、を対応付けて保持する送信対応情報の該時間間隔毎に、前記通知情報を該時間間隔と対応付けられた前記送信先に送信すること、を特徴とする。
【００１９】
また、請求項１０にかかる発明は、請求項８にかかる発明において、前記送信ステップは、前記送信先と、所定の送信判断数と、を対応付けて保持する前記送信対応情報の該送信判断数と、前記通知情報生成ステップにより前記通知情報が生成された回数の比較結果に基づいて前記通知情報を、前記送信判断数と対応付けられている前記送信先に送信すること、を特徴とする。
【００２０】
また、請求項１１にかかる発明は、請求項８にかかる発明において、前記送信ステップは、前記送信先と、所定の継続時間と、を対応付けて保持する前記送信対応情報の前記所定の継続時間の間、前記通知情報生成ステップで生成された通知情報に基づいて所定の条件を満足する状態が継続していると判断した場合に、前記通知情報を前記所定の継続時間と対応付けられた前記送信先に送信すること、を特徴とする。
【００２１】
また、請求項１２にかかる発明は、請求項８〜１１のいずれか一つにかかる発明において、前記送信ステップは、送信する条件を満たした場合に前記送信先毎に前記通知情報を圧縮する圧縮ステップを備え、前記圧縮ステップにより圧縮された前記通知情報を前記送信先に送信すること、を特徴とする。
【００２２】
また、請求項１３にかかる発明は、請求項８〜１２のいずれか一つにかかる発明において、前記送信ステップは、送信する条件を満たした場合に前記送信先に送信する前記通知情報から所定の条件を満たした通知情報を抽出する抽出ステップを備え、前記抽出ステップにより抽出された該通知情報を前記送信先に送信すること、を特徴とする。
【００２３】
また、請求項１４にかかる発明は、請求項８〜１３のいずれか一つにかかる発明において、情報を受信する受信ステップを、さらに備え、前記通知情報生成ステップは、携帯型情報記憶媒体を検出した検出装置から入力された情報が、前記情報の送信先と前記送信タイミング情報と、さらに送信条件とを対応付けて保持する前記送信対応情報の一方の送信条件を満足した場合に、通知情報を生成し、前記送信ステップは、前記通知情報生成ステップにより生成された前記通知情報を、一方の前記送信条件と対応付けられた前記送信先である自装置に、前記送信条件と対応付けられた前記送信タイミングに従って送信し、前記受信ステップは、前記送信ステップから送信された前記通知情報を受信し、前記通知情報生成ステップは、さらに前記受信ステップから受信した前記通知情報が、前記送信対応情報の他方の送信条件を満足した場合に、通知情報を生成すること、を特徴とする。
【００２４】
また、請求項１５にかかる発明は、請求項８〜１４のいずれか１つにかかる発明をコンピュータで実行させることを特徴とする。
【００２５】
また、請求項１６にかかる発明は、請求項１５に記載されたプログラムを格納したコンピュータの読み取り可能な記録媒体であることを特徴とする。
【００２６】
また、請求項１７にかかる発明は、物体毎に備えられた携帯型情報記憶媒体と、接触せずに該携帯型情報記憶媒体を検知する検出装置と、該検出装置から入力された情報に基づいて生成した通知情報を送信する情報送信装置と、を備えた情報送信システムにおいて、前記情報送信装置は、送信先と、送信タイミング情報と、を対応付けて保持する送信対応情報を記憶する記憶手段と、携帯型情報記憶媒体を検出した検出装置から入力された情報に基づいて、通知情報を生成する通知情報生成手段と、前記記憶手段に記憶された前記送信対応情報の前記送信タイミング情報に従って、前記通知情報生成手段により生成された前記通知情報を、前記送信タイミング情報と対応付けられている前記送信先に送信する送信手段と、を備えたこと、を特徴とする。
【発明の効果】
【００２７】
請求項１にかかる発明によれば、記憶手段で記憶した送信タイミング情報に従って、前記送信タイミング情報に対応付けられた送信先に対して通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００２８】
また、請求項２にかかる発明によれば、時間間隔毎に通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００２９】
また、請求項３にかかる発明によれば、通知情報が通信判断数だけ生成された場合に通知情報を送信するので、送信先で通知情報の一括処理が可能となり処理負担が軽減するという効果を奏する。
【００３０】
また、請求項４にかかる発明によれば、通知情報に含まれている情報が所定の条件を時間間隔毎に通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００３１】
また、請求項５にかかる発明によれば、通知情報を圧縮してから送信することで、送信先が通知情報を受信する際に時間が短縮すると共に、ネットワークトラフィックが軽減するという効果を奏する。
【００３２】
また、請求項６にかかる発明によれば、通知情報を抽出してから送信することで、送信先に不要な情報が送信されないことになり、送信先の処理負担が軽減するという効果を奏する。
【００３３】
また、請求項７にかかる発明によれば、複数の送信条件を満足した場合に限り通知情報を、送信先に送信できるので、送信先の要求に適した送信情報を送信できるという効果を奏する。
【００３４】
また、請求項８にかかる発明によれば、送信タイミング情報に従って、前記送信タイミング情報に対応付けられた送信先に対して通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００３５】
また、請求項９にかかる発明によれば、時間間隔毎に通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００３６】
また、請求項１０にかかる発明によれば、通知情報が通信判断数だけ生成された場合に通知情報を送信するので、送信先で通知情報の一括処理が可能となり処理負担が軽減するという効果を奏する。
【００３７】
また、請求項１１にかかる発明によれば、通知情報に含まれている情報が所定の条件を時間間隔毎に通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【００３８】
また、請求項１２にかかる発明によれば、通知情報を圧縮してから送信することで、送信先が通知情報を受信する際に時間が短縮すると共に、ネットワークトラフィックが軽減するという効果を奏する。
【００３９】
また、請求項１３にかかる発明によれば、通知情報を抽出してから送信することで、送信先に不要な情報が送信されないことになり、送信先の処理負担が軽減するという効果を奏する。
【００４０】
また、請求項１４にかかる発明によれば、複数の送信条件を満足した場合に限り通知情報を、送信先に送信できるので、送信先の要求に適した送信情報を送信できるという効果を奏する。
【００４１】
また、請求項１５にかかる発明によれば、コンピュータに読み取らせて実行することによって、請求項８〜１４のいずれか一つに記載された情報送信方法をコンピュータの利用で実現することができ、これら各情報送信方法と同様の効果を奏する。
【００４２】
また、請求項１６に係る発明によれば、請求項１５に記載された情報送信プログラムを格納した記録媒体であり、この記録媒体をコンピュータに読み込ませることで、情報送信プログラムを実行することが可能という効果を奏する。
【００４３】
また、請求項１７にかかる発明によれば、記憶手段で記憶した送信タイミング情報に従って、前記送信タイミング情報に対応付けられた送信先に対して通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができるという効果を奏する。
【発明を実施するための最良の形態】
【００４４】
以下に添付図面を参照して、この発明にかかる情報送信装置、情報送信方法、情報送信プログラム、コンピュータに読み取り可能な記録媒体及び情報送信システムの最良な実施の形態を詳細に説明する。
【００４５】
（第１の実施の形態）
図１は、第１の実施の形態にかかる情報送信システムの構成を示すブロック図である。本実施の形態にかかる情報送信システムでは、物体に対して備え付けられたアクティブタグ１６１ａ〜ｎと、アクティブタグ１６１ａ〜ｎから送信された識別信号を受信するリーダ１５１ａ〜ｎと、リーダ１５１ａ〜ｎに接続された位置情報送信サーバ１００から構成される。また、位置情報送信サーバ１００は、本発明の情報送信装置の機能を備えている。本図に示すように、アクティブタグ１６１ａ〜ｎから出力された信号をリーダ１５１ａ〜ｎが検知する。そして、リーダ１５１ａ〜ｎは検知した識別信号に含まれていた情報及び計測された信号強度を、ネットワークを通じて接続された位置情報送信サーバ１００に送信する。そして、位置情報送信サーバ１００は、送信された情報及び計測された信号強度に基づいて取得した情報を、ネットワーク１０を介してアプリケーション毎に送信する。
【００４６】
また、リーダ１５１ａ〜ｎは、位置情報管理サーバ１００ａに接続されていれば、直接接続されていても良く、またネットワークを介して接続されても良く、どのような経路を辿っても良い。本実施の形態において、リーダ１５１ａ〜ｎは、ネットワーク１０を介して位置情報管理サーバ１００ａに接続されているものとする。なお、図１では、直接、後述するタグ受信処理部１０２に接続されているが、これは理解を容易にするためのものとする。
【００４７】
また、本実施の形態において、アクティブタグ１６１ａ〜ｎが備え付けられる対象を人間や所定の物に制限するものではなく、物や人間を含むあらゆる物体に対して備え付けることができる。これにより、例えばアクティブタグ１６１ｌを利用者が保持し、アクティブタグ１６１ｍを利用者が保持するＰＨＳ等の物に備え付け、アクティブタグ１６１ｎを搬入対象となる荷物に備え付ける等の様々な状況でタグを検出し、後述する処理を行うことが可能になる。
【００４８】
アクティブタグ１６１ａ〜ｎは、換言すれば携帯型情報記憶媒体に相当し、上記の物体毎に備えられている。アクティブタグ１６１ａ〜ｎは、物体の位置情報を把握できればどのようなものでもよい。本実施の形態に係るアクティブタグ１６１ａ〜ｎは、アクティブに電波を発信するものとし、例えば１秒毎に識別信号を発信するものとする。また、本実施の形態以外のタグの例としては、パッシブ型ＲＦＩＤタグなどの信号に対してパッシブなものでもよく、他にはアクティブに電波を発するBluetooth規格やZigBee規格のタグを用いても良い。
【００４９】
リーダ１５１ａ〜ｎは、換言すれば検出装置に相当し、アクティブタグ１６１ａ〜ｎから識別信号を受信した場合、位置情報送信サーバ１００を示すアドレス及びポートに、受信した識別信号に含まれていたタグＩＤ、計測された信号強度を送信する。また、位置情報送信サーバ１００は、受信したタグＩＤと、信号強度を、リーダ１５１ａ〜ｎのリーダＩＤと対応付けて記憶する。なお、位置情報送信サーバ１００は、リーダＩＤを、予め記憶してあるリーダＩＤとリーダのアドレスの対応関係から特定できる。そして、送信元のリーダのアドレスは、上記情報を送る際に用いられたパケットのヘッダに含まれている送信元アドレスより特定できる。
【００５０】
また、本実施の形態とは異なる形態としてリーダ１５１ａ〜ｎが上記の情報と共にリーダ１５１ａ〜ｎを示すリーダＩＤを対応付けて送信することにしてもよい。
【００５１】
図２は、本実施の形態に係る位置情報送信サーバ１００の全体構成を概念的に示した説明図である。各リーダ１５１ａ〜ｃは検知された識別信号を、この信号強度と共に位置情報送信サーバ１００にネットワークを通じて送信し、さらに位置情報送信サーバ１００は、受信した情報に基づいて物体の位置情報等を取得して、アプリケーションＡ２０１〜アプリケーションＤ２０４にネットワークを通じて通知する。このアプリケーションＡ２０１〜アプリケーションＤ２０４に対する通知は所定の時間毎に送信する、又は各アプリケーションから要求があった場合に送信する。
【００５２】
図１に戻り、位置情報送信サーバ１００の内部は、記憶部１０１と、タグ受信処理部１０２と、タグ情報管理部１０３と、位置情報取得部１０４と、イベント生成部１０５と、位置情報ＤＢ管理部１０６と、通知情報生成部１０７と、フィルタＤＢ管理部１０８と、通信処理部１０９とを備え、リーダ１５１ａ〜ｎから送信された識別信号及び計測された信号強度を保存した後、物体の位置情報を算出し、位置情報を含んだ通知情報を生成し、所定の条件を満足した場合に他のアプリケーションに送信する。
【００５３】
記憶部１０１は、デバイスデータベース１１１と、位置情報データベース１１２と、フィルタリングデータベース１１３と、を記憶する。
【００５４】
デバイスデータベース１１１は、リーダ位置管理テーブルと、タグ信号管理テーブルとを保持する。図３はリーダ位置管理テーブルの構造を示した図である。本図に示すように、リーダ位置管理テーブルは、リーダＩＤと、リーダの位置情報、リーダのアドレス及びリーダの座標系を対応付けて保持している。リーダＩＤとリーダのアドレスを対応付けていることで、情報の送信元のリーダのアドレスからリーダＩＤを特定することができる。これによりリーダＩＤに基づいて座標系及びリーダの位置情報を特定することができる。座標系とは、リーダの位置を位置座標で示すために用いられている座標系をいい、領域毎に異なる座標系が定められている。本実施の形態では階毎に異なる座標系が割り当てられていることとする。このため、「座標系」フィールドは、階数を保持する。
【００５５】
図４はタグ信号管理テーブルの構造を示した図である。本図に示すように、タグ信号管理テーブルは、タグＩＤと、リーダＩＤと、信号強度と、検出時間とを対応付けて保持している。つまり、タグ信号管理テーブルは、リーダ１５１ａ〜ｎから送信された情報に検出時間を対応付けた情報をレコードとして管理している。また、タグＩＤは、アクティブタグ１６１ａ〜ｎを備えられた物体を特定するために用いられるＩＤとする。
【００５６】
そして、位置情報データベース１１２は、ＩＤ対応管理テーブルと、ＵＩＤ位置管理テーブルとを保持する。図５は、ＩＤ対応管理テーブルの構造を示した図である。本図に示すように、ＩＤ対応管理テーブルは、ＵＩＤと、デバイス種類と、タグＩＤとを対応付けて保持している。ＵＩＤ(Universal ID)はデバイス種類等に係わらずアクティブタグ１６１ａ〜ｎ毎にユニークなＩＤを割り当てたものとする。これによりデバイスの種類等によらず一括して管理することができる。デバイス種類は、具体的には複数種類のタグが用いられている環境においてタグを生産又は販売したメーカや、上述したアクティブ、パッシブ、又は通信規格の違い等を認識するために用いられる。
【００５７】
図６は、ＵＩＤ位置管理テーブルの構造を示した図である。本図に示すように、ＵＩＤ位置管理テーブルは、ＵＩＤと、座標系と、位置情報と、検出時間とを対応付けて保持している。このＵＩＤ位置管理テーブルが保持する各レコードは、リーダ位置管理テーブル、タグ信号管理テーブル、ＩＤ対応管理テーブルが保持するレコードに基づいて生成されてものである。
【００５８】
そして、フィルタリングデータベース１１３は、エリアテーブルと、ＵＩＤ情報管理テーブルと、サービスフィルタテーブルと、を保持する。
【００５９】
図７は、エリアテーブルの構造を示した図である。本図に示すように、エリアテーブルは、座標系と、位置１と、位置２と、ラベルを対応付けて保持している。そして各レコードの矢印先が、レコードに対応した領域を示している。そしてエリアテーブルの各フィールドについて説明する。この「位置１」フィールドと「位置２」フィールドは、領域を定めるために用いられる。具体的には「位置１」フィールドの位置座標と「位置２」フィールドの位置座標を対向する頂点としてすることで、矩形領域を特定することができる。そして「ラベル」フィールドは、この特定された矩形領域を示す名称を保持している。
【００６０】
図８は、ＵＩＤ情報管理テーブルの構造を示した図である。本図に示すように、ＵＩＤ情報管理テーブルは、ＵＩＤと、名前と、タイプを対応付けて保持している。名前は、物体の名称を示し、ＵＩＤ情報管理テーブルで保持することにより各アプリケーションで統一した名称を使用することが可能になる。また、ＵＩＤ情報管理テーブルで名前を保持することで、人間がタグを備えている物体自体を識別することが可能になる。タイプは、ＵＩＤで特定される物体が人であるのか物であるのか、また人であればこの所属先、物であれば性質等、ＵＩＤで示された物体の属性を保持する。このように、タイプをＵＩＤと対応付けて保持することで、物体の属性に基づいたフィルタリングを行うことができる。
【００６１】
図９は、サービスフィルタテーブルの構造を示した図である。本図に示すように、フィルタＩＤと、イベントと、フィルタと、送信とを対応付けて保持している。また、フィルタは、ＵＩＤと、位置と、タイプと、フィルタＩＤとを保持し、これらのフィールドはフィルタリングする際に用いられる条件として用いられる。また、送信は、圧縮と、抽出と、送信タイプと、送信先と、プロトコルと、送信情報とを保持し、これらのフィールドは通知情報を生成する際に用いられる。
【００６２】
「イベント」フィールドは、他のアプリケーションに送信するイベント情報を示している。例えば“ＬＯＳＴ”は、位置情報を失った場合に生成されるイベント情報が送信されることを示している。また、“ＥＶ＿ＰＯＳ＿ＣＨＡＮＧＥ”であれば、ＵＩＤの位置座標が、前回の位置座標から変化した場合に生成されるイベント情報が送信されることを示している。また、“ＰＯＳ＿ＵＰＤＡＴＥ”であれば、ＵＩＤの位置座標が更新された場合に生成されるイベント情報が送信されることを示している。また、“ＥＶ＿ＣＲＥＡＴＥＤ＿ＥＶＥＮＴ”であれば、後述する受信処理部１２２が通知情報を受信した場合に、生成されるイベント情報が送信されることを示している。
【００６３】
フィルタの各フィールドは、生成されたイベント情報をフィルタリングする条件を示している。なお、フィールドに何も記載されていない場合、条件として用いないことを示している。
【００６４】
「ＵＩＤ」フィールドは、送信されるＵＩＤの条件が記載されている。「位置」フィールドは、送信される位置情報の条件が記載されている。「位置」フィールドは、（Ｘ座標、Ｙ座標、半径）で示されている。例えば（１０，２０，５）の場合、座標（１０，２０）で半径５ｍ以内に含まれている場合にフィルタの条件を満足することを示している。なお、最初に“not”が記載されている場合は、検出した位置情報が、（Ｘ座標、Ｙ座標、半径）に含まれていない場合にフィルタの条件を満足することを意味する。
【００６５】
「タイプ」フィールドは、ＵＩＤと対応付けられているタイプについての送信する条件を示している。「フィルタＩＤ」フィールドは、受信した通知情報が保持するフィルタＩＤについての送信する条件を示している。
【００６６】
つまり、フィルタリングとは、例えば生成されたイベント名“ＬＯＳＴ”のイベント情報が、フィルタＩＤがfil.0001のレコードにより、当該イベント情報が保持する位置情報が座標（１０，２０）から５ｍの範囲内であり、ＵＩＤがＵＩＤ０００１の場合に、フィルタの条件を満足し、送信されることを示している。
【００６７】
送信の各フィールドは、送信するイベント情報を生成する際に用いる。「圧縮」フィールドは、圧縮方法が記載されている。なお、「圧縮」フィールドに何も記載されていない場合、圧縮せずに送信する。圧縮方法としてどのような方法を用いても良い。また、圧縮方法の例としては、Run-Lengthエンコーディング等が考えられる。また、本実施の形態において、Run-Lengthエンコーディングを用いる場合、「圧縮」フィールドに“Ｒ−Ｌ”と記載する。これにより後述する圧縮部１３１が、記載された方法で圧縮する。
【００６８】
「抽出」フィールドは、送信先に送信するイベント情報が複数存在する場合に、これらのイベント情報のうちの１つだけ抽出することを示している。そして、送信処理部１２１は、抽出されたイベント情報のみを送信することになる。この抽出方法については後述する。
【００６９】
「送信タイプ」フィールドは、送信するタイミングの条件が示してある。本実施の形態で用いられるタイプの種類は“normal”と、“bulk”と、“continue”と、“lost”とするがこれら以外の種類を設定しても良い。
【００７０】
“normal”は、フィルタの条件を満たして生成された通知情報を、送信処理部１２１が、逐次送信するタイプとする。“bulk”は、“bulk:秒数:通知情報の数”と記載され、タイマにより設定された秒数だけ通知情報をバッファリングした場合、又はフィルタの条件を満たして生成された通知情報を、設定された通知情報の数だけバッファリングした場合、送信処理部１２１が、当該バッファリングされていた通知情報を、送信するタイプとする。なお、“bulk”は、秒数と通知情報の数のどちらかを省略することもできる。
【００７１】
“continue”は、“continue:秒数”として記載され、最初に通知情報が入力されてから設定された秒数だけ同じ状態が継続している場合に、送信するタイプとする。“lost”は、“lost:秒数”として記載され、通知情報が入力されてから設定された秒数経過しても同じフィルタを通った通知情報が入力されなかった場合に、送信するタイプとする。
【００７２】
「送信先」フィールドは、情報の送信先を示したものであり、送信先に情報を処理するアプリケーションが存在することを示している。「プロトコル」フィールドは、送信する際の送信プロトコルを保持している。
【００７３】
「送信情報」フィールドは、通知情報に含める情報を保持している。「送信情報」フィールドが通知情報に含める情報を保持することで、各アプリケーションに必要な情報のみ送信することができる。
【００７４】
つまり、当該レコードは、「イベント」で示されたイベント情報が生成された際、「フィルタ」に設定された条件を満たしたイベント情報がある場合、「送信情報」で保持されていた情報を通知情報に含め、「送信タイプ」で設定されたタイミングで、「送信先」に「プロトコル」を用いて送信されることとなる。なお、送信情報は必要に応じて「圧縮」による圧縮方法で圧縮され、「抽出」が設定された場合に抽出されたイベント情報のみ送信されることとなる。
【００７５】
また、サービスフィルタテーブルのレコードは、ネットワーク１０を介して接続されているアプリケーションが追加、削除、変更を行うことも可能である。
【００７６】
タグ受信処理部１０２は、リーダ１５１ａ〜ｎから送信された情報を受信する処理を行う。本実施の形態においてタグ受信処理部１０２は、リーダ１５１ａ〜ｎからネットワークを介して受信したタグＩＤ、計測された信号強度を受信する。受信した際、受信したパケットのヘッダを参照することでリーダのＩＰアドレスを特定できる。このタグ受信処理部１０２は、これら受信した情報と、検出時間を対応付けてタグ信号管理テーブルを更新するように、タグ情報管理部１０３に指示する。検出時間とは、リーダ１５１ａ〜ｎがアクティブタグ１６１ａ〜ｎを検出したとみなされる時間、つまりリーダ１５１ａ〜ｎからタグＩＤ等を受信した時の現在時間とする。
【００７７】
タグ情報管理部１０３は、デバイスＤＢが保持する各テーブルに対して処理を行う。本実施の形態では、タグ情報管理部１０３は、リーダ位置管理テーブルを参照して、タグ受信処理部１０２から入力されたリーダのＩＰアドレスよりリーダＩＤを特定する。そして、タグ情報管理部１０３は、特定されたリーダＩＤと、入力されたタグＩＤと、信号強度と、検出時間を対応付けて、タグ信号管理テーブルのリーダＩＤとタグＩＤをキーとして一致するレコードを更新する。これにより、タグ信号管理テーブルでは、リーダＩＤとタグＩＤと対応付けられた信号強度と検出時間の最新情報が保持される。
【００７８】
また、タグ情報管理部１０３は、後述する位置情報取得部１０４からの要求により、タグ信号管理テーブルが保持しているユニークなタグＩＤの数を抽出して出力する。また、タグ情報管理部１０３は、位置情報取得部１０４からの要求により、所定の時間毎に、タグ信号管理テーブルからタグＩＤをリーダＩＤ、信号強度と、検出時間と対応付けて出力する。この際、出力したリーダＩＤと対応付けられた位置情報をリーダ位置管理テーブルから取得して出力する。本実施の形態では所定の時間を３秒とする。
【００７９】
また、タグ情報管理部１０３は、上述したようにレコードを更新する際にリーダＩＤとタグＩＤをキーとして該当するレコードを更新した。レコードの管理方法はどのように管理しても良い。そこで、本実施の形態においては、レコードは更新されなかった場合、タグ情報管理部１０３が一定時間後に消去することとした。なお、本実施の形態ではこの一定時間を３秒とする。つまり、３秒以内であれば、更新されなくとも維持されることになる。
【００８０】
これにより、例えば、所定のアクティブタグを１秒前にリーダ１５１ａ、リーダ１５１ｂ及びリーダ１５１ｃが検出したとする。そして、今回リーダ１５１ａ及びリーダ１５１ｂのみ検出した場合、リーダ１５１ａとリーダ１５１ｂを示すリーダＩＤと対応付けられたレコードが更新され、リーダ１５１ｃを示すリーダＩＤと対応付けられたレコードは１秒前の情報が保持されている。そして、位置情報を算出する際には、リーダ１５１ａ〜ｃに対応付けられたレコードを用いて行われる。
【００８１】
つまり、３秒以内に一度以上検出されていれば、当該リーダで検出された情報は、位置情報の算出に用いられる。つまり、何らかの障害により一時的にアクティブタグからの信号が検出できなかった場合でも位置情報を算出することができる。
【００８２】
位置情報取得部１０４は、所定の時間間隔毎に位置情報を取得する。また、所定の時間間隔は、どのような時間間隔でも良い。本実施の形態においては、位置情報取得部１０４は、３秒毎に位置情報を取得する。
【００８３】
そして、位置情報取得部１０４は、３秒毎にタグ情報管理部１０３からタグ信号管理テーブルが保持しているタグＩＤと対応付けられたリーダＩＤ、信号強度及び検出時間、並びにリーダ位置管理テーブルが保持しているリーダＩＤと対応付けられた座標系及び位置情報を取得する。これにより、位置情報取得部１０４は、検出した全てのタグＩＤを取得することができる。
【００８４】
また、位置情報取得部１０４は、３秒を検出したタグＩＤの数で除した時間間隔毎に、検出されたアクティブタグ１個毎の位置情報を算出する。これにより、３秒間で検出された全てのアクティブタグの位置情報を取得できる。また、位置情報取得部１０４は、タグＩＤの数を、タグ情報管理部１０３から入力されたタグ信号管理テーブルの全レコード情報のユニークなＩＤを抽出することで取得した。これにより、位置情報取得部１０４は、検出されたアクティブタグの位置情報の算出処理を分散して行うことができる。
【００８５】
また、位置情報取得部１０４は、位置情報を算出した後、タグＩＤと、位置情報と、検出時間と、座標系を対応付けてイベント生成部１０５に出力する。また、本実施の形態では、位置情報取得部１０４は、検出されたアクティブタグ１個の位置情報を算出する度に出力することとする。
【００８６】
また、位置情報取得部１０４は、アクティブタグ１６１ａ〜ｎの位置情報の算出方法としてはどのような方法を用いても良い。例えば、位置情報取得部１０４は、アクティブタグ１６１ｂを検出したリーダが１個しかない場合、検出したリーダの座標系及び位置情報をアクティブタグ１６１ｂの位置を示す座標系及び位置情報とする。
【００８７】
また、アクティブタグ１６１ｃを検出したリーダが複数ある場合、位置情報取得部１０４は、アクティブタグ１６１ｃの位置情報の算出方法としてどのような方法を用いてもよい。例えば、位置情報取得部１０４は、検出したリーダの位置情報の平均値をアクティブタグ１６１ｃの位置情報とする、又は検出したリーダの位置情報に信号強度で重み付けした上で算出した平均値をアクティブタグ１６１ｃの位置情報とする等が考えられる。
【００８８】
また、位置情報取得部１０４が３秒毎に位置情報を算出することとする。そして、タグ信号管理テーブルのレコードは更新されなくとも３秒間保持されている。これにより、位置情報取得部１０４は、仮にリーダがアクティブタグから発信された信号を３回に１回程度しか受信できない電波状況でも、更新された情報に基づいて位置情報を算出することができる。
【００８９】
イベント生成部１０５は、所定の条件を満たした場合にイベント情報を生成する。イベント情報を生成する際の条件については後述する。
【００９０】
なお、イベント生成部１０５は、位置情報取得部１０４からタグＩＤと対応付けられた位置情報が入力された際、タグＩＤと対応付けられたＵＩＤを、位置情報ＤＢ管理部１０６に対してタグＩＤを受け渡すことで取得することができる。これは、位置情報ＤＢ管理部１０６がＩＤ対応管理テーブルから当該タグＩＤと対応付けられたＵＩＤを取得するために実現できる。
【００９１】
また、イベント生成部１０５は、位置情報取得部１０４からタグＩＤと、位置情報と、検出時間と、座標系とを対応付けて入力された場合、イベント名が“ＰＯＳ＿ＵＰＤＡＴＥ”のイベント情報を生成して、通知情報生成部１０７に出力する。なお、生成されたイベント情報は、イベント名と、位置情報取得部１０４から入力された位置情報と、検出時間と、座標系と、さらにＵＩＤと、を保持していることとする。
【００９２】
また、イベント生成部１０５は、位置情報取得部１０４からタグＩＤと対応付けられた位置情報が入力された場合、対応付けられたＵＩＤを取得する。次に、イベント生成部１０５は、位置情報管理ＤＢ１０６から、以前検出された時の位置情報と、ＵＩＤと対応付けて入力される。そして、イベント生成部１０５は、ＵＩＤが一致する、位置情報取得部１０４から入力された位置情報と、以前検出された時の位置情報を比較する。
【００９３】
そして、イベント生成部１０５は、位置情報が変化したと判断した場合、イベント名が“ＥＶ＿ＰＯＳ＿ＣＨＡＮＧＥ”のイベント情報を生成して、通知情報生成部１０７に出力する。なお、生成されたイベントは、イベント名と、位置情報取得部１０４から入力された位置情報と、検出時間と、座標系と、さらにＵＩＤと、を保持していることとする。
【００９４】
また、イベント生成部１０５は、後述する位置情報ＤＢ管理部１０６から以前検出された時のタグＩＤと対応付けられた位置情報が入力され、対応するタグＩＤの情報が位置情報取得部１０４から入力されなかった場合、イベント名“ＬＯＳＴ”のイベント情報を生成して、通知情報生成部１０７に出力する。なお、生成されたイベントは、イベント名と、以前検出された際のＵＩＤと、位置情報と、検出時間と、座標系を保持していることとする。
【００９５】
また、イベント生成部１０５は、位置情報取得部１０４から位置情報が入力された場合、上述したイベント情報の生成が終了した後、位置情報ＤＢ管理部１０６に対して入力された位置情報でＵＩＤ位置管理テーブルを更新する旨を指示する。この際、イベント生成部１０５は、位置情報と、ＵＩＤと、検出時間とを対応付けて出力する。
【００９６】
また、イベント生成部１０５は、後述する受信処理部１２２から通知情報が入力された場合、イベント名“ＥＶ＿ＣＲＥＡＴＥＤ＿ＥＶＥＮＴ”のイベント情報を生成して、通知情報生成部１０７に出力する。なお、生成されたイベントは、イベント名と、通知情報に含まれていた情報を保持していることとする。
【００９７】
位置情報ＤＢ管理部１０６は、位置情報ＤＢが保持する各テーブルに対して処理を行う。本実施の形態では、位置情報ＤＢ管理部１０６は、イベント生成部１０５からタグＩＤが入力されると、ＩＤ対応管理テーブルによりタグＩＤと対応付けられたＵＩＤをイベント生成部１０５に出力する。また、位置情報ＤＢ管理部１０６は、出力したＵＩＤに対応付けられた位置情報等をＵＩＤ位置管理テーブルから取得して、イベント生成部１０５に出力する。
【００９８】
また、位置情報ＤＢ管理部１０６は、更新する旨の依頼と共にＵＩＤ、位置情報及び検出時間がイベント生成部１０５から入力された場合、ＵＩＤ情報管理テーブルを更新する。これにより、ＵＩＤ情報管理テーブルは、アクティブタグを備えた全ての物体の現在の位置情報を保持していることになる。
【００９９】
通知情報生成部１０７は、入力されたイベント情報に基づいて通知情報を生成して、サービルフィルタテーブルが保持している圧縮情報、抽出情報、送信タイプ情報、送信先情報、プロトコル情報と共に後述する送信処理部１２１に出力する。本実施の形態に係る通知情報生成部１０７は、通知情報を生成する際に、入力されたイベント情報に対してフィルタリング処理を行う。通知情報生成部１０７は、フィルタリング処理に用いるフィルタとして、入力されたイベント情報のイベント名と合致するレコード情報をフィルタＤＢ管理部１０８から取得する。
【０１００】
そして、通知情報生成部１０７は、フィルタＤＢ管理部１０８から取得したレコード情報のフィルタの各フィールドで示された条件を満たすか否か判断する。条件を満たすと判断した場合、通知情報生成部１０７は、イベント情報から通知情報を生成する。また、通知情報生成部１０７が、生成された通知情報に、当該レコードの送信情報で示した情報を保持させる。
【０１０１】
また、フィルタの各フィールドと一致するか否かとは、例えば、サービスフィルタテーブルのフィルタの「位置」フィールドで指定された範囲内に、イベント情報に含まれていた位置情報が存在していた場合に、通知情報生成部１０７は、条件を満たすと判断する。
【０１０２】
他の例としては、サービスフィルタテーブルのフィルタの「ＵＩＤ」フィールドで指定されていたＵＩＤと、イベント情報に含まれていたＵＩＤが一致した場合に、通知情報生成部１０７は、条件を満たすと判断する。
【０１０３】
また、通知情報生成部１０７は、必要に応じて、フィルタＤＢ管理部１０８に対して指示することで、エリアテーブル及びＵＩＤ情報管理テーブルから必要な情報を取得する。
【０１０４】
そして、通知情報生成部１０７は、生成された通知情報を、当該レコード情報の圧縮情報、抽出情報、送信タイプ情報、送信先情報、プロトコル情報と共に、送信処理部１２１に出力する。
【０１０５】
フィルタＤＢ管理部１０８は、フィルタリングデータベース１１３が保持する各テーブルに対して処理を行う。本実施の形態では、フィルタＤＢ管理部１０８は、通知情報生成部１０７から入力されたイベント名より一致するフィルタのレコード情報をサービスフィルタテーブルから取得して通知情報生成部１０７に出力する。また、フィルタＤＢ管理部１０８は、通知情報生成部１０７からの指示に応じて、ＵＩＤ情報管理テーブル又はエリアテーブルが保持している情報から取得して、通知情報生成部１０７に出力する。
【０１０６】
また、フィルタＤＢ管理部１０８は、要求受付部１２３からフィルタを追加する旨と共に追加する条件を示す情報が入力された場合、サービスフィルタテーブルに条件を示すレコードを追加する。また、要求受付部１２３からフィルタの変更又は削除する旨が入力された場合も同様にサービスフィルタテーブルに対して変更又は削除を行う。
【０１０７】
通信処理部１０９は、送信処理部１２１と、受信処理部１２２と、要求受付部１２３とを備え、ネットワーク１０を介して接続されているアプリケーション又は他のプロセス等と送受信を行う。
【０１０８】
送信処理部１２１は、圧縮部１３１と、抽出部１３２とを備え、アプリケーション等に対して通知情報を送信する処理を行う。また、送信処理部１２１は、通知情報と共に入力された送信タイプ、圧縮、抽出、送信先、プロトコルに基づいて送信する処理を行う。
【０１０９】
送信処理部１２１は、入力された送信タイプ情報により、通知情報を送信するタイミングが異ならせて処理を行う。
【０１１０】
送信処理部１２１は、送信タイプが“normal”の場合、タイミングの制御を行わず、入力された際に送信するための処理を開始する。
【０１１１】
送信処理部１２１は、送信タイプが“bulk”の場合、入力された通知情報をバッファリングし、所定時間経過後又は入力された通知情報が所定数を超えた場合に、入力された通知情報を一括して送信する。
【０１１２】
図９のfil.0003の場合について説明する。このfil.0003は、“bulk:180:100”と設定されている。まず、１８０秒周期のタイマがfil.0003を登録した時点でスタートする。次に、fil.0003の条件を満たして入力された通知情報がある場合に、通知情報のバッファリングを行う。そして、送信処理部１２１は、タイマがスタートしてから１８０秒経過した場合、又はfil.0003の条件を満たして入力された通知情報の数が１００を超えた場合に、バッファリングしていた通知情報を一括して送信する処理を開始する。なお、１８０秒周期タイマはfil.0007が削除されるまで永続的に繰り返される。また、bulkの秒数又は回数が‘０’の場合、送信処理部１２１は、設定されている項目を無制限として処理する。
【０１１３】
送信処理部１２１は、送信タイプが“continue”の場合、一致する通知情報が入力された場合にタイマが開始し、入力された通知情報をバッファリングし、タイマが所定時間経過した時点で入力された通知情報が同じ状態であれば、入力された通知情報を送信する。
【０１１４】
図９のfil.0004の場合について説明する。このfil.0004は、“continue:180”と設定されている。図１０は、送信処理部１２１が送信タイプ“continue”の場合に“continue”でアプリケーションに通知情報を送信する条件を示す説明図である。本図に示すように、ＵＩＤ０００１のユーザが座標（２０，３０）にいる場合、フィルタの（２０，３０，５）に含まれているので通知情報は生成されない。そして、ＵＩＤ０００１のユーザが座標（１０，１０）に移動した場合、fil.0004のフィルタの条件を満たしたので、送信処理部１２１にfil.0004の条件を満たした通知情報が入力される。これによりfil.0004のタイマが開始される。このタイマは、１８０秒間経過するまでカウントを行う。そして、送信処理部１２１は、１８０秒経過後に、ＵＩＤ０００１のユーザが（２０，３０，５）に含まれているか否か判断する。具体的には、送信処理部１２１は、１８０秒経過の３秒以内に、fil.0004の条件を満たした通知情報が入力されたか否かにより判断する。つまり、入力されていた場合、送信処理部１２１は、（２０，３０，５）に含まれていないと判断することができる。入力されなかった場合、送信処理部１２１は、ＵＩＤ０００１のユーザの位置はfil.0004の条件を満たさなかった、つまり、ＵＩＤ０００１のユーザは（２０，３０，５）に含まれていると判断することができる。そして、送信処理部１２１は、（２０，３０，５）に含まれていないと判断した場合に、通知情報を送信する処理を開始する。
【０１１５】
送信処理部１２１は、送信タイプが“lost”の場合、当該フィルタに一致する通知情報が入力された時点でタイマが開始し、タイマの開始から所定時間経過しても当該フィルタに一致する入力情報が入力されなかった場合に、最初に入力された通知情報を送信する。
【０１１６】
圧縮部１３１は、送信処理部１２１から入力された圧縮で指定された圧縮方法を用いて、通知情報を圧縮する。
【０１１７】
図１１は、本実施の形態に係る圧縮部１３１が、送信タイプ“bulk”で６秒毎に送信する場合に、通知情報を圧縮する概念を示した概念図である。本図に示すように、通知情報を圧縮することでデータ容量が小さくなるため、ネットワーク１０のトラフィックを軽減することができる。また、送信先で、通知情報を受信する際の受信時間を短縮できる。
【０１１８】
抽出部１３２は、送信処理部１２１から入力された抽出情報が‘１’である場合に、複数の通知情報から１つの通知情報のみ抽出する。本実施の形態において抽出部１３２は、複数の通知情報のうち、最新の通知情報を抽出することとする。
【０１１９】
図１２は、抽出部１３２が、送信タイプ“bulk”で６秒毎に送信する場合に、通知情報に対して抽出を行う概念を示した概念図である。本図に示すように、６秒間に生成された複数の通知情報から１つの通知情報を抽出して送信を行うことで、データ容量が小さくなり、さらにネットワーク１０のトラフィックを軽減することができる。また、アプリケーションに対して不要な通知情報を送信せずにすむことになる。これにより、送信先のアプリケーションにおいて、処理負担を軽減できる。
【０１２０】
また、送信処理部１２１は、送信する処理が開始された場合、必要に応じて圧縮、抽出が行われた後、送信先として通知情報生成部１０７から入力された送信先を設定する。このように、位置情報送信サーバ１００は、サービスフィルタテーブルに設定された送信先毎に適したタイミングで通知情報を送信することができる。
【０１２１】
また、送信処理部１２１は、送信先を設定した後、通信に用いるプロトコルとして通知情報生成部１０７から入力されたプロトコルを用いて送信する処理を行う。
【０１２２】
受信処理部１２２は、位置情報送信サーバ１００から自装置を送信先として送信された通知情報を受信する。そして、通知情報を受信した場合、受信した通知情報を、イベント生成部１０５に出力する。これにより、イベント生成部１０５は、イベント名“ＥＶ＿ＣＲＥＡＴＥＤ＿ＥＶＥＮＴ”のイベント情報を生成することとなる。
【０１２３】
図９のfil.0006の場合について説明する。このfil.0006は、“continue:180”で送信先に“localhost.2345”と設定されている。この“localhost.2345”は、位置情報送信サーバ１００のアドレスを示している。これにより、当該レコード情報の条件を満たして送信された通知情報は、受信処理部１２２が受信する。そして、イベント生成部１０５は、受信処理部１２２で入力された通知情報からイベント情報を生成する。そして、通知情報生成部１０７に入力されたイベント情報に含まれるフィルタＩＤがfil.0006のため、fil.0007の条件を満たすので、通知情報が生成され、送信処理部１２１による送信処理が行われることになる。
【０１２４】
このように、位置情報送信サーバ１００では、一度しかフィルタリングを行わないが、上述した処理により２段以上のフィルタリングを行うことができる。つまり、複数の送信条件を満足した場合に限り通知情報を、送信先のアプリケーションに送信できる。これにより、複雑な条件が設定可能となり、アプリケーションの詳細な要求に適した送信情報を送信できる。
【０１２５】
要求受付部１２３は、位置情報送信サーバ１００に接続されたアプリケーション又はプロセスから要求を受け付けて、要求に適した情報をフィルタＤＢ管理部１０８に送信する。そして、フィルタＤＢ管理部１０８は、要求に適したレコードをサービスフィルタテーブルに登録する。
【０１２６】
また、要求受付部１２３は、サービスフィルタテーブルに対するレコードの登録の他に、レコードの変更又は削除等の要求も受け付ける。そして、受け付けた要求は、要求と共に受け取ったフィルタを指定する情報、さらに変更の場合は変更する条件を示す情報と共にフィルタＤＢ管理部１０８に出力する。また、フィルタを指定する条件としては、サービスフィルタテーブルの「フィルタＩＤ」フィールドなどレコードを特定可能であればどのような条件でも良い。
【０１２７】
図１３は、アプリケーションから位置情報に基づく情報の送信の要求を受け付けた場合に、位置情報送信サーバ１００が要求に応じたフィルタを生成するまでの一例を示した説明図である。本図に示すように、アプリケーションが、位置情報に基づいた通知情報の送信する要求を、通知情報を送信する際の条件と共に、位置情報送信サーバ１００に行う。この場合、要求受付部１２３が、通知情報を送信する要求を、通知情報を送信する際の条件とともに受け付ける。なお、送信する際の条件としては、送信する際のイベントの選択、上述したフィルタリングの条件、送信タイプによる送信するタイミング、又は送信に用いるプロトコルなどサービスフィルタテーブルに設定可能な条件であればどのような条件でも良い。そして、要求受付部１２３は、フィルタＤＢ管理部１０８に、上述した要求に基づいて生成したレコード情報を、サービスフィルタテーブルに登録する指示を行う。なお、当該レコード情報の「送信先」フィールドは、要求を行ったアプリケーションのアドレスとする。そして、フィルタＤＢ管理部１０８が、サービスフィルタテーブルに当該レコードを追加する。
【０１２８】
これにより、サービスフィルタテーブルに追加されたレコードの条件を満たした場合に、位置情報送信サーバ１００は、要求を行ったアプリケーションに対して通知情報を送信することになる。
【０１２９】
次に、以上のように構成された本実施の形態にかかる位置情報送信サーバ１００におけるタグＩＤ等の情報の受信から位置情報に変更があった場合にアプリケーションに通知情報を通知するまでの処理について説明する。図１４は、本実施の形態にかかる位置情報送信サーバ１００における上述した処理の手順を示すフローチャートである。
【０１３０】
まず、タグ受信処理部１０２は、リーダ１５１ａ〜ｎが検出したアクティブタグ１６１ａ〜ｎのタグＩＤ等の情報をリーダ１５１ａ〜ｎから受信する（ステップＳ１４０１）。
【０１３１】
そして、タグ情報管理部１０３は、タグ受信処理部１０２が受信したタグＩＤ、受信したリードのリーダＩＤ、信号強度及び検出時間を対応付けてタグ信号管理テーブルを更新する（ステップＳ１４０２）。
【０１３２】
次に、位置情報取得部１０４は、３秒毎に、タグ情報管理部１０３から３秒以内に検出されたアクティブタグ１６１ａ〜ｎのタグＩＤ、検出したリーダのリーダＩＤ及び信号強度、並びにリーダ毎の位置情報をタグ信号管理テーブルから取得し、取得した情報に基づいてタグＩＤに対応付けられた位置情報を算出して、アクティブタグ１６１ａ〜ｎの位置情報を取得する（ステップＳ１４０３）。
【０１３３】
そして、イベント生成部１０５は、位置情報取得部１０４が取得した位置情報と、位置情報ＤＢ管理部１０６から入力された以前の位置情報に基づいて、イベント情報を生成する（ステップＳ１４０４）。
【０１３４】
次に、位置情報ＤＢ管理部１０６は、取得した位置情報に基づいて、ＵＩＤ位置管理テーブルを更新する（ステップＳ１４０５）。
【０１３５】
そして、通知情報生成部１０７は、イベント生成部１０５から入力されたイベント情報に対して、フィルリングを行い、フィルタの条件を満足したイベント情報に基づいて通知情報を生成する（ステップＳ１４０６）。このフィルタリングは、入力されたイベント情報のフィルタ名と一致するレコードを、フィルタＤＢ管理部１０８がサービスフィルタテーブルから取得し、通知情報生成部１０７に出力することで行われる。そして入力されたレコード情報のフィルタの各フィールドの条件を満たした場合に、通知情報生成部１０７は、通知情報を生成する。また、通知情報生成部１０７は、通知情報を生成する際、当該レコードに含まれていた送信情報を含めることとする。
【０１３６】
次に、送信処理部１２１が、通知情報生成部１０７から通知情報が入力されると、当該通知情報と共に入力された送信タイプの条件を満たした場合、通知情報の送信処理を行う（ステップＳ１４０７）。なお、送信処理部１２１が行う詳細な手順については後述する。
【０１３７】
上述した処理手順により、アクティブタグ１６１ａ〜ｎを検出してからアプリケーション毎に適した情報を、アプリケーション毎に適したタイミングで送信することが可能となる。なお、上述した処理手順は、本実施の形態によるタグＩＤ等の情報を受信してから位置情報が変更された場合の通知情報を生成して通知処理を行うまでの処理手順の例を示したものであり、本発明をこの処理手順に制限するものではない。
【０１３８】
次に、以上のように構成された本実施の形態にかかる送信処理部１２１における通知情報が入力されてから送信処理を行うまでの処理について説明する。図１５は、本実施の形態にかかる送信処理部１２１における上述した処理の手順を示すフローチャートである。
【０１３９】
まず、送信処理部１２１は、通知情報と共に入力された送信タイプが、“bulk”であるか否か判断する（ステップＳ１５０１）。
【０１４０】
そして、送信処理部１２１は、送信タイプが“bulk”であると判断した場合（ステップＳ１５０１：Ｙｅｓ）、通知情報をタイマにより設定された秒数だけ通知情報のバッファリング、又は所定の数だけ通知情報のバッファリングを行う（ステップＳ１５０２）。
【０１４１】
また、送信処理部１２１は、送信タイプが“bulk”ではないと判断した場合（ステップＳ１５０１：Ｎｏ）、送信タイプが“continue”であるか否か判断する（ステップＳ１５０３）。
【０１４２】
そして、送信処理部１２１は、送信タイプが“continue”であると判断した場合（ステップＳ１５０３：Ｙｅｓ）、通知情報に含まれている状態が、設定された秒数だけ持続するまで待機する（ステップＳ１５０４）。なお、設定された秒数だけ同じ状態が持続しなかった場合、送信処理部１２１は、送信タイプが“continue”に基づく送信処理を行わない。
【０１４３】
また、送信処理部１２１は、送信タイプが“continue”でないと判断した場合（ステップＳ１５０３：Ｎｏ）、送信タイプが“lost”であるか否か判断する（ステップＳ１５０５）。
【０１４４】
そして、送信処理部１２１は、送信タイプが“lost”であると判断した場合（ステップＳ１５０５：Ｙｅｓ）、当該通知情報が入力したときから待機を開始し、同じフィルタを通った通知情報が入力されずに、待機開始から設定された秒数経過するまで待機する（ステップＳ１５０６）。なお、同じフィルタを通った通知情報が、設定された秒数以内に入力された場合、送信処理部１２１は、再度入力された時から待機を開始することとなる。
【０１４５】
また、送信処理部１２１は、送信タイプが“lost”ではないと判断した場合（ステップＳ１５０５：Ｎｏ）、送信タイプが“normal”として、そのまま送信する処理を行う。
【０１４６】
次に、送信処理部１２１は、通知情報と共に入力された抽出情報により、抽出するか否か判断する（ステップＳ１５０７）。また、抽出しないと判断した場合（ステップＳ１５０７：Ｎｏ）、特に処理は行わない。
【０１４７】
そして、送信処理部１２１は、抽出すると判断した場合（ステップＳ１５０７：Ｙｅｓ）、抽出部１３２が、同一フィルタを通過して入力された複数の通知情報から、最新の通知情報を１つ抽出する（ステップＳ１５０８）。
【０１４８】
次に、送信処理部１２１は、通知情報と共に入力された圧縮情報により、圧縮するか否か判断する（ステップＳ１５０９）。また、圧縮しないと判断した場合（ステップＳ１５０９：Ｎｏ）、特に処理は行わない。
【０１４９】
そして、送信処理部１２１が、圧縮すると判断した場合（ステップＳ１５０９：Ｙｅｓ）、圧縮部１３１が、送信する対象となる通知情報を、圧縮情報で保持していた圧縮方法を用いて圧縮する（ステップＳ１５１０）。
【０１５０】
次に、送信処理部１２１は、通知情報の送信処理を行う（ステップＳ１５１１）。
【０１５１】
上述した処理手順により、送信処理部１２１が、通知情報をアプリケーション毎に適したタイミングで、適した処理を施した後に送信処理を行うことが可能となる。なお、上述した処理手順は、本実施の形態による送信処理部１２１における通知情報が入力されてから送信処理を行うまでの処理手順の例を示したものであり、本発明をこの処理手順に制限するものではない。
【０１５２】
図１６は、位置情報送信サーバ１００の機能を実現するためのプログラムを実行したＰＣのハードウェア構成を示した図である。本実施の形態の位置情報送信サーバ１００は、ＣＰＵ（Central Processing Unit）１６０１等の制御装置と、ＲＯＭ（Read Only Memory）１６０２やＲＡＭ（Random Access Memory）１６０３等の記憶装置と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disk）ドライブ装置等の外部記憶装置１６０４と、ディスプレイ装置等の表示装置１６０５と、キーボードやマウス等の入力装置１６０６と、通信Ｉ／Ｆ(InterFace)１６０７と、これらを接続するバス１６０８を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【０１５３】
本実施形態の位置情報送信サーバ１００で実行される情報送信プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１５４】
また、本実施形態の位置情報送信サーバ１００で実行される情報送信プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の位置情報送信サーバ１００で実行される情報送信プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。
【０１５５】
また、本実施形態の情報送信プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１５６】
本実施の形態の位置情報送信サーバ１００で実行される情報送信プログラムは、上述した各部（記憶部、タグ受信処理部、タグ情報管理部、位置情報取得部、イベント生成部、位置情報ＤＢ管理部、通知情報生成部、フィルタＤＢ管理部、通信処理部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ１６０１が上記記録媒体から情報送信プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、記憶部、タグ受信処理部、タグ情報管理部、位置情報取得部、イベント生成部、位置情報ＤＢ管理部、通知情報生成部、フィルタＤＢ管理部、通信処理部が主記憶装置上に生成されるようになっている。
【０１５７】
上述した実施の形態にかかる位置情報送信サーバ１００により、発生したイベント毎に任意の間隔で通知情報を送信可能とする。つまり、位置情報送信サーバ１００は、送信タイプで定められたタイミングに従って、送信タイプに対応付けられた送信先に対して通知情報を送信するので、送信先毎に適したタイミングで通知情報を送信することができる。
【０１５８】
また、位置情報送信サーバ１００は、サービスフィルタテーブルで送信する際の通知情報の発生回数、時間間隔をアプリケーション単位で管理することができる。そして、アプリケーションからの要求に応じて、要求受付部１２３が要求に適したレコードを追加する指示を行うことを可能とした。これにより、アプリケーションが、送信するタイミング及び情報量を設定することが可能となった。
【産業上の利用可能性】
【０１５９】
以上のように、本発明にかかる情報送信装置、情報送信方法、情報送信プログラム、コンピュータに読み取り可能な記録媒体及び情報送信システムは、検出装置で検出された場合に情報を送信する技術に有用であり、特に、情報を送信する際に送信先毎に適したタイミングで送信する制御を行う技術に適している。
【図面の簡単な説明】
【０１６０】
【図１】第１の実施の形態にかかる情報送信システムの構成を示すブロック図である。
【図２】第１の実施の形態に係る位置情報送信サーバの全体構成を概念的に示した説明図である。
【図３】第１の実施の形態に係る位置情報送信サーバのデバイスデータベースで保持するリーダ位置管理テーブルの構造を示した図である。
【図４】第１の実施の形態に係る位置情報送信サーバのデバイスデータベースで保持するタグ信号管理テーブルの構造を示した図である。
【図５】第１の実施の形態に係る位置情報送信サーバの位置情報データベースで保持するＩＤ対応管理テーブルの構造を示した図である。
【図６】第１の実施の形態に係る位置情報送信サーバの位置情報データベースで保持するＵＩＤ位置管理テーブルの構造を示した図である。
【図７】第１の実施の形態に係る位置情報送信サーバのフィルタリングデータベースで保持するエリアテーブルの構造を示した図である。
【図８】第１の実施の形態に係る位置情報送信サーバのフィルタリングデータベースで保持するＵＩＤ情報管理テーブルの構造を示した図である。
【図９】第１の実施の形態に係る位置情報送信サーバのフィルタリングデータベースで保持するサービスフィルタテーブルの構造を示した図である。
【図１０】第１の実施の形態に係る送信処理部が送信タイプ“continue”の場合にアプリケーションに通知情報を送信する条件を示す説明図である。
【図１１】第１の実施の形態に係る圧縮部が、送信タイプ“bulk”で６秒毎に送信する場合に、通知情報を圧縮する概念を示した概念図である。
【図１２】第１の実施の形態に係る抽出部が、送信タイプ“bulk”で６秒毎に送信する場合に、通知情報に対して抽出を行う概念を示した概念図である。
【図１３】第１の実施の形態において、アプリケーションから位置情報に基づく情報の送信の要求を受け付けた場合に、位置情報送信サーバが要求に応じたフィルタを生成するまでの一例を示した説明図である。
【図１４】第１の実施の形態にかかる位置情報送信サーバにおけるタグＩＤ等の情報の受信から位置情報に変更があった場合にアプリケーションに通知情報を通知するまでの処理の手順を示すフローチャートである。
【図１５】第１の実施の形態にかかる送信処理部における通知情報が入力されてから送信処理を行うまでの処理の手順を示すフローチャートである。
【図１６】第１の実施の形態にかかる位置情報送信サーバの機能を実現するためのプログラムを実行したＰＣのハードウェア構成を示した図である。
【符号の説明】
【０１６１】
１００  位置情報送信サーバ
１０１  記憶部
１０２  タグ受信処理部
１０３  タグ情報管理部
１０４  位置情報取得部
１０５  イベント生成部
１０６  位置情報ＤＢ管理部
１０７  通知情報生成部
１０８  フィルタＤＢ管理部
１０９  通信処理部
１１１  デバイスデータベース
１１２  位置情報データベース
１１３  フィルタリングデータベース
１２１  送信処理部
１２２  受信処理部
１２３  要求受付部
１３１  圧縮部
１３２  抽出部
１５１ａ〜ｎ  リーダ
１６１ａ〜ｎ  アクティブタグ
１６０１  ＣＰＵ
１６０２  ＲＯＭ
１６０３  ＲＡＭ
１６０４  外部記憶装置
１６０５  表示装置
１６０６  入力装置
１６０７  通信Ｉ／Ｆ
１６０８  バス
【図１】
2007079865.tif 000003
【図２】
2007079865.tif 000004
【図３】
2007079865.tif 000005
【図４】
2007079865.tif 000006
【図５】
2007079865.tif 000007
【図６】
2007079865.tif 000008
【図７】
2007079865.tif 000009
【図８】
2007079865.tif 000010
【図９】
2007079865.tif 000011
【図１０】
2007079865.tif 000012
【図１１】
2007079865.tif 000013
【図１２】
2007079865.tif 000014
【図１３】
2007079865.tif 000015
【図１４】
2007079865.tif 000016
【図１５】
2007079865.tif 000017
【図１６】
2007079865.tif 000018