JP4727268B2 - 情報管理装置、位置情報管理装置、情報管理方法、情報管理プログラム、コンピュータに読み取り可能な記録媒体及び位置情報管理システム - Google Patents

Description

本発明は、情報管理装置、位置情報管理装置、情報管理方法、情報管理プログラム、コンピュータに読み取り可能な記録媒体及び位置情報管理システムに関するものであり、特に所定の条件に合致した場合にネットワークを介して接続されている機器、アプリケーション又はプロセスに通知を行う技術に関するものである。

近年、情報ネットワーク技術の発達が著しい。会社などの様々な環境下で構築されたネットワーク内では様々な機器が接続されており、これらの機器では様々なアプリケーションが実行することが可能である。このため、ネットワークを介して入力された情報に基づいて処理を行うアプリケーションも多く開発されている。

そこで、定義された条件を従属した場合に、イベントが発生したとして、ネットワークに接続された機器に情報を提供する技術が提案されている（例えば、特許文献１）。

この特許文献１に記載された技術において、イベントを通知するトリガを受信した場合に、このイベントと一致するまたは相関するプロファイルに記載された基準を満たした場合に、このプロファイルに定義された方法で通知されることになる。

特開２００３−３２７２１号公報

しかしながら特許文献１に記載された技術においてはプロファイルに記載された条件について具体的な記載がなされておらず、通知する条件として複雑な条件を設定できない。このため、機器、アプリケーション又はプロセスが要求する情報を通知するために最適な条件を設定できないという問題がある。

本発明は、上記に鑑みてなされたものであって、ネットワークを介して接続された機器、アプリケーション又はプロセスによる要求に対して適切な情報の通知を可能とする情報管理装置、位置情報管理装置、情報管理方法、情報管理プログラム、コンピュータに読み取り可能な記録媒体及び位置情報管理システムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、対象となる事象の情報を管理し、該対象に備え付けられた携帯型情報記憶媒体を検出するための検出装置と接続された情報管理装置であって、前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信手段と、前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、を備えたことを特徴とする。

また、請求項２にかかる発明は、物体に備えられた携帯型情報記憶媒体を検出装置が検出することで特定できる物体の位置情報を管理する位置情報管理装置において、前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、前記物体の位置に関して通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、前記検出装置から、所定の情報を受信し、前記所定の情報に基づく前記携帯型情報記憶媒体の位置を示す位置情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持受信手段と、
前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記位置情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、を備えたことを特徴とする。

また、請求項３にかかる発明は、対象となる事象の情報を管理し、該対象に備え付けられた携帯型情報記憶媒体を検出するための検出装置と接続された情報管理装置で実行される情報管理方法であって、前記情報管理装置が、前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて保存する第２の記憶手段と、アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、を備え、受信手段が、前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信ステップと、生成手段が、前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成ステップと、通知手段が、前記生成ステップで生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知ステップと、を有することを特徴とする。

また、請求項４にかかる発明は、請求項３に記載された情報管理方法をコンピュータで実行させることを特徴とする。

また、請求項５にかかる発明は、請求項４に記載された情報管理プログラムを格納したコンピュータの読み取り可能な記録媒体であることを特徴とする。

また、請求項６にかかる発明は、位置情報を取得する対象となる区域内に存在する物体に備えられた携帯型情報記憶媒体と、前記携帯型情報記憶媒体と非接触により前記携帯型情報記憶媒体を検知する検出装置と、検出された前記携帯型情報記憶媒体を備えた物体の位置情報を管理する位置情報を管理する位置情報管理装置と、を備えた位置情報管理システムにおいて、位置情報管理装置は、前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、前記物体の位置に関して通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信手段と、前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、を備えたことを特徴とする。

請求項１にかかる発明によれば、アプリケーション又はプロセスによる要求に対して適切な情報の通知を可能とするという効果を奏する。

また、請求項２にかかる発明によれば、アプリケーション又はプロセスによる要求に対して適切な情報の通知を可能とするという効果を奏する。

また、請求項３にかかる発明によれば、アプリケーション又はプロセスによる要求に対して適切な情報の通知を可能とするという効果を奏する。

また、請求項４にかかる発明によれば、コンピュータに読み取らせて実行することによって、請求項３に記載された情報管理方法をコンピュータの利用で実現することができ、これら各情報管理方法と同様の効果を奏する。

また、請求項５に係る発明によれば、請求項４に記載された情報管理プログラムを格納した記録媒体であり、この記録媒体をコンピュータに読み込ませることで、情報管理プログラムを実行することが可能という効果を奏する。

また、請求項６に係る発明によれば、アプリケーション又はプロセスによる要求に対して適切な情報の通知を可能とするという効果を奏する。

以下に添付図面を参照して、この発明にかかる情報管理装置、位置情報管理装置、情報管理方法、情報管理プログラム、コンピュータに読み取り可能な記録媒体及び位置情報管理システムの最良な実施の形態を詳細に説明する。

図１は、本発明の実施の形態にかかる位置情報管理システムの構成を示すブロック図である。本実施の形態にかかる位置情報管理システムでは、物体に対して備え付けられたアクティブタグ１６１ａ〜ｎと、アクティブタグ１６１ａ〜ｎから送信された識別信号を受信するリーダ１５１ａ〜ｎと、リーダ１５１ａ〜ｎに接続された位置情報管理サーバ１００から構成される。本図に示すように、アクティブタグ１６１ａ〜ｎから出力された信号をリーダ１５１ａ〜ｎが検知する。そして、リーダ１５１ａ〜ｎは検知した識別信号に含まれていた情報及び計測された信号強度を、ネットワークを通じて接続された位置情報管理サーバ１００に送信する。そして、位置情報管理サーバ１００は、送信された情報及び計測された信号強度から取得できる位置情報等が予め設定されたイベントの生成条件に合致した際にイベントが生成され、このイベントに基づいて生成された通知情報をアプリケーション毎に送信する。

このイベントは、アクティブタグ１６１ａ〜ｎ等から検出された信号の変化又は時刻の経過等の事象の変化に応じて生成されるものであり、換言すれば事象情報に相当する。なお、本実施の形態においては、イベントとして基本イベントと応用イベントを用いるが、これらのイベントを用いること制限するものではなく、さらに複数種類のイベントを用意してもよい。なお、基本イベント及び応用イベントについては後述する。

また、本実施の形態において物体とは、物のみならず人間を含むこととする。これにより、例えばアクティブタグ１６１ｌを利用者が保持し、アクティブタグ１６１ｍを利用者が保持するＰＨＳ等の物に備え付け、アクティブタグ１６１ｎを搬入対象となる荷物に備え付ける等の様々な状況でタグを検出し、後述する処理を行うことが可能になる。

アクティブタグ１６１ａ〜ｎは、換言すれば携帯型情報記憶媒体に相当し、少なくとも１つの物体又は利用者毎に備えられていることとする。本実施の形態においてアクティブタグ１６１ａ〜ｎは、電波により１秒ごとに識別信号を発信する。なお、本実施の形態は携帯型情報記憶媒体をアクティブに電波を発信するタグに制限するものではなく、例えばパッシブなものでもかまわない。より具体的な例としてパッシブ型ＲＦＩＤタグあるいはアクティブに電波を発するBluetooth規格やZigBee規格で通信を行っても良い。

リーダ１５１ａ〜ｎは、換言すれば検出装置に相当し、アクティブタグ１６１ａ〜ｎから識別信号を受信した場合、位置情報管理サーバ１００を示すアドレス及びポートに、受信した識別信号に含まれていたタグＩＤ、計測された信号強度が送信され、位置情報管理サーバ１００でリーダ１５１ａ〜ｎのリーダＩＤと対応付けられる。このリーダＩＤは、リーダＩＤとリーダのアドレスの対応関係から特定できる。そして、送信元のリーダのアドレスは、上記情報を送る際に用いられたパケットのヘッダに含まれている送信元アドレスより特定できる。

また、本実施の形態とは異なる形態としてリーダ１５１ａ〜ｎが上記の情報と共にリーダ１５１ａ〜ｎを示すリーダＩＤを対応付けて送信してもよい。

図２は、位置情報管理サーバ１００の全体構成の概念的に示した説明図である。各リーダ１５１ａ〜ｃは検知された識別信号を、この信号強度と共に位置情報管理サーバ１００にネットワークを通じて送信し、さらに位置情報管理サーバ１００は、受信した情報に基づいて利用者又は物体の位置情報等を取得して、アプリケーションＡ２０１〜アプリケーションＤ２０４にネットワークを通じて通知する。このアプリケーションＡ２０１〜アプリケーションＤ２０４に対する通知は所定の時間毎に送信する、又は各アプリケーションから要求があった場合に送信する。

図１に戻り、位置情報管理サーバ１００の内部は、記憶部１０１と、受信処理部１０２と、タグ情報管理部１０９と、位置情報取得部１０３と、基本イベント生成部１０４と、応用イベント生成部１０５と、通知情報生成部１０６と、通知処理部１０７と、イベント編集受付部１０８とを備え、リーダ１５１ａ〜ｎから送信された識別信号及び計測された信号強度から取得した位置情報を保存した後、この位置情報等に基づいて基本イベントを生成する条件を満たした場合に基本イベントを生成し、生成した基本イベント等に基づいて応用イベントを生成する条件を満たした場合に応用イベントを生成し、生成した応用イベントに基づいて通知情報を生成して他のアプリケーション又はプロセスに通知する。

基本イベントとは、時間が経過した又はアクティブタグを検出したなどの基本的な事象の変化を検知した場合に生成する情報である。なお、基本イベントは、換言すれば第１の事象情報に相当する。

また、応用イベントとは、所定の場所に滞在し続けている等の、基本イベント及び生成された応用イベントに基づいて判断可能な複雑な事象についての条件を満たしたと判断した場合に生成される情報である。

記憶部１０１は、位置情報データベース１１１と、基本イベントデータベース１１２と、応用イベントデータベース１１３と、フィルタリングデータベース１１４と、を記憶する。また、記憶部１０１は、例えばＨＤＤ、光ディスク、メモリカードなどの一般的に用いられるあらゆる記憶手段で構成することができる。

位置情報データベース１１１は、リーダ位置管理テーブルと、タグ信号管理テーブルと、ＩＤ位置情報管理テーブルと、を記憶する。図３はリーダ位置管理テーブルの構造を示した図である。本図に示すように、リーダ位置管理テーブルは、リーダＩＤと、リーダの位置情報、リーダのアドレスを対応付けて保持している。リーダＩＤとリーダのアドレスを対応付けていることで、アクティブタグを検出した旨の情報の送信元のリーダのアドレスからリーダＩＤを特定することができる。これによりリーダＩＤに基づいてリーダの位置情報を特定することができる。なお、リーダのアドレスは、リーダから送信されたパケットのヘッダを参照することで取得できる。

図４はタグ信号管理テーブルの構造を示した図である。本図に示すように、タグ信号管理テーブルは、ＩＤと、リーダＩＤと、信号強度と、検出時間とを対応付けて保持している。つまり、タグ信号管理テーブルは、リーダ１５１ａ〜ｎから送信された情報に検出時間を対応付けた情報をレコードとして管理している。また、ＩＤは、アクティブタグ１６１ａ〜ｎを備えられた物体を特定するために用いられるＩＤとする。

図５は、ＩＤ位置情報管理テーブルの構造を示した図である。本図に示すように、ＩＤ位置情報管理テーブルは、ＩＤと、位置情報と、検出時間とを対応付けて保持している。このＩＤ位置管理テーブルが保持する各レコードは、リーダ位置管理テーブル、タグ信号管理テーブル、が保持するレコードに基づいて生成されてものである。また、検出時間は、リーダ１５１ａ〜ｎがアクティブタグ１６１ａ〜ｎを検出した時間とする。このように位置情報を記憶することで、物体の位置情報の変化の検出や、複数の物体間の距離等を算出することができる。

基本イベントデータベース１１２は、基本イベント管理テーブルを記憶する。図６は、基本イベント管理テーブルの構造を示した図である。本図に示すように、生成される基本イベントと、イベント生成条件とを対応付けて保持している。なお、図６においてイベント生成条件は、理解を容易にするために日本語で記載したが、実際は位置情報管理サーバ１００が認識可能な形式で保持する。後述する図７及び図８についても同様とする。この基本イベント管理テーブルが保持するイベント生成条件は、換言すれば基本生成条件情報に相当する。

本図に示された基本イベントについて説明する。‘ＤＥＴＥＣＴＥＤ’は、検出されたアクティブタグの位置情報を取得した場合に生成される。‘ＵＮＤＥＴＥＣＴＥＤ’は、アクティブタグが検出できなかった場合及びアクティブタグを検出したが位置情報を取得できなかった場合に生成される。‘ＰＯＳ＿ＵＰＤＡＴＥ’は、取得したアクティブタグの位置情報で位置情報管理テーブルを更新した場合に生成される。‘ＰＯＳ＿ＣＨＡＮＧＥ’は、取得した位置情報を特定するＩＤがすでに位置情報管理テーブルのレコードとして保持している場合で、このレコードが保持している位置情報と取得した位置情報が異なる場合に生成される。‘ＴＩＭＥ＿ＣＹＣＬＥ’は、予め定められたサイクル時間毎に周期的に生成されるイベントとする。この予め定められたサイクル時間は、アプリケーションに周期的に情報を通知する時間間隔が設定され、例えば１秒等とする。

また、‘ＤＥＴＥＣＴＥＤ’、‘ＵＮＤＥＴＥＣＴＥＤ’、‘ＰＯＳ＿ＵＰＤＡＴＥ’及び‘ＰＯＳ＿ＣＨＡＮＧＥ’のイベントが生成された場合、これらのイベントにＩＤ、位置情報及び検出時間を含める。また、‘ＴＩＭＥ＿ＣＹＣＬＥ’は本実施の形態においては現在時間、及び位置情報管理テーブルで前回送信してから更新されたレコードが保持しているＩＤ及び位置情報を含めて生成するが、必要に応じて現在時間のみ含めて生成する等も考えられる。なお、本実施の形態は、本発明で生成されるイベントを上記のイベントに制限するものではなく、通知先のアプリケーションが要求する情報等に応じて適切なイベントを設定する。

応用イベントデータベース１１３は、応用イベント管理テーブルと、イベント状態管理テーブルと、エリアテーブルと、を記憶する。

図７は、応用イベント管理テーブルの構造を示した図である。本図に示すように、イベント名、トリガイベント、イベント生成条件、引数、送信データ、有効期限及び有効フラグを対応付けて保持している。本図で示したテーブルを用いて後述する応用イベント生成部１０５で応用イベントが生成される。

この応用イベント管理テーブルは、生成された応用イベントと生成する条件を対応付けて保持する情報であり、換言すれば事象対応情報に相当する。また、応用イベント管理テーブルのイベント生成条件は、換言すれば事象生成条件情報に相当する。また、トリガイベントは、生成する際に比較対象として用いられるイベントであり、換言すれば対象事象情報に相当する。

イベント名は生成条件を満たした場合に生成される応用イベントのイベント名を示している。トリガイベントは、当該応用イベントを生成するか否か判断を行うトリガとなるイベントを示しており、基本イベントのみならず応用イベントもトリガとして用いられる。イベント生成条件は、応用イベントを生成する条件を示したものである。引数はイベント生成条件で使用される値等を保持する。例えばイベント生成条件で「指定位置で検出された場合」であり、引数が「ＩＤ００１、（１０、３０）」の場合には、指定位置を示す座標（１０、３０）でＩＤ００１のアクティブタグを検出した場合にイベント生成条件と一致したと判断する。また、引数が設定されていない場合には任意の値で合致したこととなる。例えば上記のイベント生成条件で引数が「、（１０、３０）」の場合には、指定位置を示す座標（１０、３０）で任意のアクティブタグを検出した場合にイベント生成条件と一致したと判断する。

また、送信データは生成されたイベントに含まれる情報とする。有効期間は、このレコードで示される応用イベントが生成される期限を示したものであり、この期限を経過した場合には、このレコードを用いてイベントが生成されなくなる。この有効期限は、後述するイベント編集受付部１０８によるイベント追加の際に、有効期限を指定できる。有効期限の切れたイベントは削除するか、有効フラグを‘０’として無効化する。

また、有効フラグは、このレコードが有効か否かを示したものであり‘１’の場合には有効であり、このレコードで示された生成条件を満たした場合にイベントが生成され、‘０’の場合には無効であり、このレコードでイベントの生成が行われなくなる。なお、このテーブルを用いた応用イベントの生成方法は後述する。

図８は、図７で示した応用イベント管理テーブルにレコードとして登録される応用イベントの一覧を示した図である。本図に示した一覧から、通知情報の送信対象となるアプリケーション及びプロセスの必要に応じて、引数、有効期限、有効フラグ等が設定された上で応用イベント管理テーブルに登録されることになる。また、これらの応用イベントは、生成対象となるイベントして応用イベント管理テーブルに登録されるのみならず、イベント生成条件としても設定される。例えば、図７で示した応用イベント管理テーブルにおいて、第９レコードの‘ＡＷＡＹ＿ＡＲＥＡ’イベントでは、イベント生成条件として、‘ＬＡＳＴＩＮＧ’イベントを設定している。これにより‘ＬＡＳＴＩＮＧ’イベントのイベント生成条件を満たした場合に、‘ＡＷＡＹ＿ＡＲＥＡ’イベントが生成されることとなる。

図９は、イベント状態管理テーブルの構造を示した図である。本図に示すように時間、発生イベントを対応付けて保持する。これにより各時間で発生したイベントを認識することができる。なお、本図において視認性を向上させるために図示していないが、保持するイベントはイベント名のみならず、イベントが保持する情報、例えばＩＤ、位置情報及び検出時間等も保持することとする。これによりどのＩＤ又はどの位置でこれらのイベントが発生したのか等を特定することが可能になる。なお、このテーブルで保持するイベントはどのようなイベントであってもよく、本実施の形態において基本イベント及び応用イベントを登録することとする。なお、使用する態様によっては、どちらか一方のみ登録しても良い。

図１０は、エリアテーブルの構造を示した図である。本図に示すようにエリア名と該当する領域を対応付けて保持している。また、領域は、エリアの形状及びエリアを特定するための座標を保持している。例えば矩形エリアと記載されている場合はエリアが矩形であることを示し、矩形エリアである場合には矩形を特定するための２点の位置座標を保持している。また、領域の形状は矩形以外でも良く、例えば円形エリアなどが考えられる。この円形エリアの場合、中心となる位置座標及び半径を保持する等が考えられる。

フィルタリングデータベース１１４は、ＩＤ情報管理テーブルと、フィルタテーブルを記憶する。図１１は、ＩＤ情報管理テーブルの構造を示した図である。本図に示すように、ＩＤ情報管理テーブルは、ＩＤと、名前と、タイプを対応付けて保持している。名前は、物体の名称を示し、ＩＤ情報管理テーブルで保持することにより各アプリケーションで統一した名称を使用することが可能になる。また、ＩＤ情報管理テーブルで名前を保持することで、人間がタグを備えている物体自体を識別することが可能になる。タイプは、ＩＤで特定される物体が人であるのか物であるのか、また人であればこの所属先、物であれば性質等、ＩＤで示された物体の属性を保持する。このように、タイプをＩＤと対応付けて保持することで、物体の属性に基づいたフィルタリングを行うことができる。

図１２は、フィルタテーブルの構造を示した図である。本図に示すように、イベントと、フィルタタイプと、ＩＤと、位置と、サービスタイプと、暗号と、送信先と、送信情報とを対応付けて保持している。「イベント」フィールドは、生成された応用イベントと合致した場合に送信することを示している。この「イベント」フィールドは、換言すれば通知事象情報に相当する。また、「フィルタタイプ」、「ＩＤ」、「位置」フィールドは、フィルタリングを行う条件を示したフィールドであり、これらのフィールドに記載された条件を満たしていた場合に限り送信される。つまり、これらのフィールドは、換言すれば通知条件情報に相当する。また、これらのフィールドに記載がない場合、特にフィルタリングを行う条件が設定されていないものとする。「サービスタイプ」フィールドは、送信する際の送信プロトコルを保持している。「暗号」フィールドは、アプリケーションに送信する際の暗号化方法を保持している。「送信先」フィールドは、情報の送信先を示したものであり、送信先に情報を処理するアプリケーションが存在している。「送信情報」フィールドは、送信する情報の種類を保持されている。これにより、各アプリケーションに必要な情報のみ送信することができる。つまり、レコードが保持するフィルタリングを行う条件を満たした場合、「送信情報」で保持されていた情報を取得し、取得した情報を当該レコードで対応付けて保持している「送信先」に「サービスタイプ」で設定された送信プロトコルを用いて送信されることになる。そして送信される情報は対応付けられた「送信情報」フィールドを参照することで把握できる。これにより、アプリケーション毎に送信する条件を設定して、この条件を満たした場合に限り情報を送信することができる。

図１に戻り、受信処理部１０２は、リーダ１５１ａ〜ｎから送信された情報を受信する処理を行う。本実施の形態において受信処理部１０２は、リーダ１５１ａ〜ｎからネットワークを介して受信したタグＩＤ、計測された信号強度を受信する。受信した際、受信したパケットのヘッダを参照することでリーダのＩＰアドレスを特定できる。このタグＩＤ、信号強度及びリーダのＩＰアドレスは、リーダ１５１ａ〜ｎから送信するように定められた情報であり、換言すれば所定情報に相当する。この受信処理部１０２は、これら受信した情報に検出時間を対応付けた情報で、タグ信号管理テーブルを更新するようにタグ情報管理部１０９に依頼する。検出時間とは、リーダ１５１ａ〜ｎがアクティブタグ１６１ａ〜ｎを検出したとみなされる時間、換言すればリーダ１５１ａ〜ｎからタグＩＤ等を受信した時の現在時間とする。

タグ情報管理部１０９は、デバイスＤＢが保持する各テーブルに対して処理を行う。本実施の形態では、タグ情報管理部１０９は、リーダ位置管理テーブルを参照して受信処理部１０２から入力されたリーダのＩＰアドレスよりリーダＩＤを特定し、この特定されたリーダＩＤと、入力されたＩＤと、信号強度と、検出時間を対応付けた情報で、タグ信号管理テーブルのリーダＩＤとＩＤをキーとして一致するレコードに対して更新を行う。これにより、タグ信号管理テーブルでは、対応付けられたリーダＩＤ及びＩＤが最新の検出情報による信号強度と検出時間を保持できる。

また、タグ情報管理部１０９は、タグ信号管理テーブルが保持するレコードで更新されなかった場合には一定時間だけ保持する。本実施の形態では、この一定時間を３秒以上とする。これにより、例えば、所定のアクティブタグを１秒前にリーダａ、リーダｂ及びリーダｃで検出されたが、今回リーダａ及びリーダｂでのみ検出された場合に、リーダａとリーダｂを示すリーダＩＤと対応付けられたレコードについてのみ更新され、リーダｃを示すリーダＩＤと対応付けられたレコードは１秒前の情報が保持される。このように、３秒以内に一度でも検出されていればタグＩＤに対応付けられた情報が保持されていることになる。つまり、何らかの障害により一時的にアクティブタグからの信号が検出できなかった場合でも位置情報を算出することができる。

位置情報取得部１０３は、予め定められた期間毎にタグ信号管理テーブルが更新されたか否か確認し、更新されていた場合には更新されていたレコードにより特定できるＩＤを取得し、このＩＤの情報を保持するレコードの情報に基づいてアクティブタグ１６１ａ〜ｎの位置情報を取得する。また、位置情報の取得は、タグ信号管理テーブルが保持するリーダＩＤと、リーダ位置管理テーブルが保持するリーダＩＤとリーダの位置情報から可能となる。本実施の形態においては、予め定められた期間を１秒とし、位置情報取得部１０３は、１秒毎に更新されているか否か確認する。この取得した位置情報は、換言すれば取得位置情報に相当する。

また、位置情報取得部１０３は、アクティブタグを検出したリーダが１つしかない場合、検出したリーダの座標系及び位置情報をアクティブタグ１６１ｂの位置を示す座標系及び位置情報とする。

また、位置情報取得部１０３は、アクティブタグを検出したリーダが複数ある場合に現在提案されている様々な位置算出方法のうちどのような方法を用いても良い。例えば、検出したリーダの位置情報の平均値、又は検出したリーダの位置情報に信号強度で重み付けした上で平均値をとる方法等が考えられる。

そして、位置情報取得部１０３は、取得したＩＤ、位置情報及び検出時間を対応付けて位置情報管理テーブルに更新する。この際、前回更新した位置情報から位置が変化したか否かを確認する。そして、これら取得したＩＤ、位置情報及び検出時間に、位置情報管理テーブルを正常に更新できたか否か、また、前回更新した位置情報から位置が変化したか否かを、後述する基本イベント生成部１０４に出力する。

基本イベント生成部１０４は、図６で示した基本イベント管理テーブルが保持するイベント生成条件に合致した場合に、基本イベントを生成して、応用イベント生成部１０５に出力する。このイベント生成条件に設定される条件について特に制限はなく、例えば物体の位置情報、時間、アクティブタグを検出する領域又はアクティブタグ自体に基づいた条件等が考えられる。この基本イベント管理テーブルが保持するイベント生成条件は、換言すれば第１の事象条件に相当する。

また、本実施の形態において、基本イベント生成部１０４は、所定のイベント生成間隔毎にイベントを生成する。この生成間隔は、通知するアプリケーションのニーズ又は位置情報管理サーバ１００の処理能力に基づいて適した時間を設定する。本実施の形態では、イベントの生成間隔を１秒毎とする。

また、基本イベント生成部１０４は、イベントの生成間隔内に位置情報等を受け取った場合、位置情報等に基づくイベントを生成する。本実施の形態において、基本イベント生成部１０４は、位置情報等を受け取った場合に、‘ＤＥＴＥＣＴＥＤ’イベントを生成し、このイベントにＩＤ、位置情報及び検出時間を含める。また、位置情報管理テーブルを正常に更新できていた場合、基本イベント生成部１０４は、‘ＰＯＳ＿ＵＰＤＡＴＥ’イベントを生成し、検出したＩＤ、位置情報及び検出時間を含める。また、前回更新した位置情報から位置が変化していた場合、基本イベント生成部１０４は、‘ＰＯＳ＿ＣＨＡＮＧＥ’イベントを生成し、検出したＩＤ、位置情報及び検出時間を含める。

また、基本イベント生成部１０４は、イベントの生成間隔内に位置情報等を受け取らなかった場合でも、イベント生成条件を満たした場合には、基本イベントを生成する。本実施の形態において、基本イベント生成部１０４は、前回アクティブタグを検出してから検出した情報を保持すると定めた保持期間内であって、今回の生成間隔内に位置情報等が入力されなかった場合には‘ＵＮＤＥＴＥＣＴＥＤ’イベントを生成する。また、基本イベント生成部１０４は、この‘ＵＮＤＥＴＥＣＴＥＤ’イベントに保持期間内に検出されたが今回検出されなかったＩＤ、前回検出したときの位置情報及び検出時間を含める。また、基本イベント生成部１０４は、サイクル時間毎に‘ＴＩＭＥ＿ＣＹＣＬＥ’イベントを生成する。なお、本実施の形態において、保持期間は３秒とし、サイクル時間は１秒とする。

図１３は、位置情報取得部１０３から入力される位置情報等と、基本イベント生成部１０４で生成されるイベントの相関関係の一例を示した説明図である。本図に示すように、基本イベント生成部１０４は、イベントの生成間隔毎にイベントの生成を行う。本図においては、説明を容易にするために検出されるアクティブタグが１つの場合とし、このアクティブタグのＩＤ等の記載を本図では省略する。また、本図で示した環境では、電波状態が悪いため、数秒に１度しかアクティブタグから発信される識別信号を検出することができない。このような環境で検出された識別信号等の所定の情報に基づいて、位置情報取得部１０３は、位置情報を取得して、基本イベント生成部１０４に出力する。なお、アクティブタグからの識別信号を検出できなかった時間では、タグ信号管理テーブルは更新されないため、位置情報取得部１０３は位置情報の出力は行われない。

基本イベント生成部１０４は、位置情報等が入力されたか否かに関わらず、イベントの生成間隔（１秒）毎にイベントを生成する。つまり、１秒経過したことを条件としてイベントを生成しており、前回生成してから経過した時間が経過時間情報に相当する。基本イベント生成部１０４は、位置情報等の入力有無にかかわらず、毎回‘ＴＩＭＥ＿ＣＹＣＬＥ’イベントを生成する。そして、イベント生成時間１３０１において、位置情報等が入力されなかったので、基本イベント生成部１０４は、‘ＵＮ＿ＤＥＴＥＣＴＥＤ’イベントを生成する。

また、イベント生成時間１３０２において、位置情報等が入力されたので、基本イベント生成部１０４は、‘ＤＥＴＥＣＴＥＤ’イベントを生成し、さらに取得した位置情報で位置情報管理テーブルを更新したことを示す‘ＰＯＳ＿ＵＰＤＡＴＥ’イベントを生成する。

さらに、イベント生成時間１３０３に入力された位置情報は、前回のイベント生成時間１３０２に入力された位置情報と異なるので、基本イベント生成部１０４は、上記‘ＤＥＴＥＣＴＥＤ’イベント及び‘ＰＯＳ＿ＵＰＤＡＴＥ’イベントの他に、‘ＰＯＳ＿ＣＨＡＮＧＥ’イベントを生成する。これら生成されたイベントは後述する応用イベント生成部１０５に入力する。

基本イベント生成部１０４を備えたことで、事象の変化に応じた基本イベントを生成することができる。そして、応用イベント生成部１０５では、この基本イベントをトリガ等に用いることで、より複雑な条件に基づいた応用イベントを生成することができる。

応用イベント生成部１０５は、生成されたイベントをトリガとして、図７で示した応用イベント管理テーブルが保持するイベント生成条件に合致した場合に、応用イベントを生成する。トリガとして用いられるイベントは特に制限を設けるものではなく、本実施の形態において、基本イベント及び応用イベントのどちらのイベントをトリガとして用いても良い。

また、応用イベント生成部１０５は、応用イベント管理テーブルが保持するイベント生成条件に合致するか否か判断するために、他のテーブルが保持している情報を利用しても良い。本実施の形態において、応用イベント生成部１０５は、必要に応じて応用イベントデータベース１１３が保持しているエリアテーブル及びイベント状態管理テーブルが保持している情報を利用して、イベント生成条件を満たしているか否か判断する。これにより、より詳細にイベント生成条件を設定することを可能とする。

また、本実施の形態において、応用イベント生成部１０５は、基本イベント生成部１０４と同様に所定のイベント生成間隔毎にイベントを生成する。本実施の形態では、応用イベント生成部１０５のイベントの生成間隔を１秒毎とする。

また、応用イベント生成部１０５は、入力された基本イベント及び生成した応用イベントいずれについても通知情報生成部１０６に出力する。また、応用イベント生成部１０５は、生成した応用イベントをトリガとして応用イベント管理テーブルが保持するイベント生成条件に合致するか否か判断し、合致した場合には応用イベントを生成する。

また、応用イベント生成部１０５は、イベントの生成間隔毎に、入力された基本イベント及び生成した応用イベントを、イベント状態管理テーブルのレコードに現在時間と対応付けて登録する。なお、このイベント状態管理テーブルにイベントを登録する際に、イベント名のみならず、イベントに含まれていた情報、例えばＩＤ、位置情報及び検出時間等も登録する。

図７で示した応用イベント管理テーブルを用いて応用イベントが生成される場合の例について説明する。応用イベント生成部１０５は、基本イベント生成部１０４から‘ＤＥＴＥＣＴＥＤ’イベントが入力された場合、この応用イベント管理テーブルの第１、２及び４レコードのトリガイベントと一致するので、これらのレコードのイベント生成条件を満たした場合に各レコードの応用イベントが生成されることになる。そして、入力された‘ＤＥＴＥＣＴＥＤ’イベントに含まれていたＩＤがＩＤ００１で、位置情報が（１０、１０）とする。この場合、第１レコード及び第２レコードのイベント生成条件及び引数で特定される条件を満たしていないので‘ＰＲＥＳＥＮＴ’イベントは生成されない。

一方、位置情報（１０，１０）は図１０で示したエリアテーブルより第１会議室であることが特定される。つまり引数及びイベント生成条件による「第１会議室でＩＤ００１が検出された場合」という第４レコードのイベント生成条件を満たすこととなる。これにより、応用イベント生成部１０５は、‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントを生成する。また、生成されたイベントには、「送信データ」で指定されていた情報であるＩＤ０００１、第１会議室及びタグを検出した時間が含まれる。なお、応用イベント生成部１０５は、判断するに際し、エリアテーブルより‘第１会議室’を示す座標領域を取得しておく必要がある。

そして、応用イベント生成部１０５は、生成された‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントをトリガとしたレコードがあるか否か判断する。あると判断した場合はこのレコードのイベント生成条件を満たすか否か上述した説明と同様の処理が行われることになる。図７で示した応用イベント管理テーブルではトリガイベントに‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’の応用イベントとして、‘ＳＴＡＹ＿ＡＲＥＡ’が存在する。そこで、イベント生成条件を参照すると、ＬＡＳＴＩＮＧ（ＰＲＥＳＥＮＴ＿ＡＲＥＡ）で引数が、ＩＤ００１及び１０分である。これらのイベント生成条件を満たした場合には、‘ＳＴＡＹ＿ＡＲＥＡ’イベントが生成される。

また、‘ＬＡＳＴＩＮＧ’イベントは、指定イベントが指定時間以上継続した場合と有り、指定時間の間に１秒間隔で同一イベントが継続して生成されている場合に生成されるイベントである。換言すれば‘ＬＡＳＴＩＮＧ’イベントは、指定時間を５分とした場合、３００回検知したことを条件と定めたイベントであり、つまり、指定時間内に予め定められた回数検知されたことを条件として生成されるイベントである。

このような、イベント生成条件の設定を可能としたことで、‘ＳＴＡＹ＿ＡＲＥＡ’イベントの登録を可能とすることで、位置情報管理サーバ１００の提供可能なサービスとして特定の人又は任意の人が会議しているという情報をリアルタイムに通知することを可能とする。なお、この特定の人か任意の人かは引数の設定により変更することが可能となる。

次に、応用イベント生成部１０５は、生成したイベント及び入力されたイベントを通知情報生成部１０６に出力し、さらに生成された‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベント及び入力された‘ＤＥＴＥＣＴＥＤ’イベントをイベント状態管理テーブルに登録する。

また、応用イベント生成部１０５は、複数のイベントに基づいて１つの応用イベントを生成してもよい。例えば、図７で示した‘ＣＬＯＳＥ’イベントでは、イベント生成条件が「複数のタグが近傍にいた場合」であり、引数が４，３であることから、４つのアクティブタグが３メートル以内にあった場合にイベント生成条件を満たすことになる。そして、トリガイベント‘ＰＯＳ＿ＵＰＤＡＴＥ’であることから、応用イベント生成部１０５は、イベント生成間隔内に‘ＰＯＳ＿ＵＰＤＡＴＥ’が４個以上入力され、これらのイベントが保持する位置情報が３メートル以内であった場合に、このレコードのイベント生成条件を満たしたものとして‘ＣＬＯＳＥ’イベントを生成する。このように複数のイベントを条件に設定して１つのイベントを生成できることで、より複雑な条件のイベントを生成することが可能になった。

また、応用イベント生成部１０５がイベント生成条件を満たすか否か判断するためにイベント状態テーブルを参照する例を説明する。例えば、上述した‘ＳＴＡＹ＿ＡＲＥＡ’イベントは、イベント生成条件が‘ＬＡＳＴＩＮＧ（ＰＲＥＳＥＮＴ＿ＡＲＥＡ）’であり、引数がＩＤ００１及び１０分となっていた。このイベント生成条件を満たすか否か確認するため、応用イベント生成部１０５は、イベント状態テーブルを参照して、ＩＤ００１が含まれた‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントが１０分間継続して登録されているか否か確認する。１０分間継続して登録されていた場合、応用イベント生成部１０５は、イベント生成条件を満たしていると判断して、‘ＳＴＡＹ＿ＡＲＥＡ’イベントを生成する。なお、図７で示した応用イベント管理テーブルが保持する応用イベントで‘ＳＴＡＹ＿ＡＲＥＡ’をトリガとする応用イベントは存在しないので、応用イベント生成部１０５は、‘ＳＴＡＹ＿ＡＲＥＡ’イベントを用いてイベント生成条件を満たすか否かの判断を行わない。なお、生成された‘ＳＴＡＹ＿ＡＲＥＡ’イベントには、UID001、エリア、タグを検出した時間及びエリアに入ってからの継続時間が含まれる。

図１４は、上述した‘ＳＴＡＹ＿ＡＲＥＡ’イベントが生成された場合にイベント状態管理テーブルに登録されるレコードの一例を示した図である。本図に示すように、‘ＳＴＡＹ＿ＡＲＥＡ’イベント、このトリガとなった‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベント、さらにこのトリガとなった‘ＤＥＴＥＣＴＥＤ’イベントが、更新した旨を示す‘ＰＯＳ＿ＵＰＤＡＴＥ’と共に同時に登録されることになる。

また、応用イベント生成部１０５がイベント生成条件を満たすか否か判断するためにイベント状態テーブルを参照する例をもう一つ説明する。イベント状態参照テーブルを参照さしてイベント生成条件を満たすか否か判断の必要なイベントとして‘ＥＶ＿ＣＨＡＮＧＥ’イベントがある。このイベントは、図８の一覧で示したように、前回生成したイベントと今回生成したイベントとの間で変化が発生していた場合にイベントの生成条件を満たしたと判断される。このように前回生成したイベントと今回生成したイベントを比較してイベントを生成できることで、より複雑な条件のイベントを生成することが可能になった。

この‘ＥＶ＿ＣＨＡＮＧＥ’イベントをイベント生成条件として設定しているイベントとしては、図７で示した応用イベント管理テーブルの第８レコードの‘ＬＥＡＶＥ’イベントがある。この‘ＬＥＡＶＥ’イベントは、トリガイベントして‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベントが、イベント生成条件として‘ＥＶ＿ＣＨＡＮＧＥ（ＰＲＥＳＥＮＴ＿ＡＲＥＡ、ＡＢＳＥＮＴ＿ＡＲＥＡ）が、さらに引数として‘応接室’が設定されている。

つまり、応用イベント生成部１０５は、‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベントを生成した際に、このイベントをトリガとして‘ＬＥＡＶＥ’イベントのイベント生成条件を満たすか否か判断する。今回生成された‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベントが応接室という情報を含んでいた場合は条件に合致したことになる。この場合、応用イベント生成部１０５は、前回応接室という情報が含まれた‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントが生成されているか否か確認するために、イベント状態管理テーブルを参照する。そして、イベント状態管理テーブルに、前回生成された応接室という情報が含まれた‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントを保持していた場合、イベント生成条件を満たしたと判断して、応用イベント生成部１０５は‘ＬＥＡＶＥ’イベントを生成する。なお、当然ながら、今回生成された‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベント及び前回生成された‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’が保持するＩＤは一致する必要がある。

図１５は、生成された‘ＬＥＡＶＥ’イベントが保持されたイベント状態管理テーブルの一例を示した図である。本図に示すように、前回‘ＰＲＥＳＥＮＴ＿ＡＲＥＡ’イベントが生成され、今回‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベントが生成された場合に、‘ＬＥＡＶＥ’イベントが生成されている。それ以後は‘ＡＢＳＥＮＴ＿ＡＲＥＡ’イベントが生成されたとしても、‘ＬＥＡＶＥ’イベントは生成されない。

図１に戻り、通知情報生成部１０６は、応用イベント生成部１０５から入力された基本イベント及び応用イベントに基づいて通知情報を生成する。本実施の形態では、通知情報生成部１０６は、入力されたイベントから、フィルタテーブルが保持する条件を満たした通知情報を生成する。なお、生成された通知情報にはイベント名が含まれていることとし、これにより通知情報がどのような場合に生成されたのか、送信先のアプリケーションが特定することができる。通知情報生成部１０６は、図１２で示したフィルタテーブルを用いてフィルタリングを行い、送信先に送信情報を送信することとなる。

また、通知情報生成部１０６は、基本イベント又は応用イベントなどの入力されたイベントが保持する情報のみならず、イベントが保持する情報に基づいて取得した情報がフィルタテーブルに保持される条件を満たした場合に通知情報を生成してもよい。例えば、イベントに含まれていたＩＤとＩＤ情報管理テーブルが保持するＩＤを比較して、入力されたイベントに対応するレコード情報を取得し、取得したレコードが保持している情報を用いて、フィルタテーブルが保持する条件を満たすか否か判断する。これら保持する条件を満たした場合に、通知情報生成部１０６は、通知情報を生成する。

例えば、通知情報生成部１０６は、‘ＰＯＳ＿ＵＰＤＡＴＥ’イベントに含まれていたＩＤをキーとして用い、ＩＤ情報管理テーブルからレコード情報を取得する。これにより、イベントに対応する名前、タイプを取得できる。これらの条件をフィルタテーブルに設定された条件としてフィルタリングが可能とする。

さらに、通知情報生成部１０６は、送信情報として、イベントが保持する情報のみならず、対応付けられたテーブルから取得した情報も送信する情報として設定できる。上述した例では、ＩＤ情報管理テーブルから取得した名前、タイプも送信する情報として設定できる。

フィルタテーブルの条件について説明する。例えば、フィルタテーブルの各レコードの「ＩＤ」と、基本イベント又は応用イベントに含まれていたＩＤが一致した場合に、「ＩＤ」で定められた条件を満たしたことになる。このように、各レコードが保持している条件を満たした場合に、通知情報生成部１０６は通知情報を生成する。

また、他の例として、通知情報生成部１０６が、入力されたイベントに含まれていた情報より他のテーブルから情報を取得して、条件を満たすか否か判断する場合について説明する。まず、通知情報生成部１０６は、入力されたイベントに含まれていた「ＩＤ」とＩＤ情報管理テーブルのフィールド「ＩＤ」を比較し、一致したレコード情報を取得する。そして取得したレコード情報に含まれていた「タイプ」と、フィルタテーブルの各レコードの「フィルタタイプ」が一致した場合に、「フィルタタイプ」で定められた条件を満たしたことになる。このように、各レコードが保持している条件を満たした場合に、通知情報生成部１０６は通知情報を生成する。

また、通知情報生成部１０６は、フィルタテーブルのレコードの条件を満たした場合、当該フィルタを示すレコードの「送信情報」フィールドを参照し、「送信情報」に記載された情報を取得し、取得した情報を通知情報に含める。これにより、アプリケーション毎に適した情報を含めた通知情報を生成することが可能になる。

また、本実施の形態では、この「送信情報」フィールドに記載された情報は、入力されたイベントに含まれていた情報、又は入力されたイベントとの対応関係から取得可能な情報であればよい。入力されたイベントとの対応関係から取得可能な情報としては、フィルタリングデータベース１１４が保持しているテーブル群から取得できる情報がある。例えば、例えばＩＤ情報管理テーブルが保持している「名前」「タイプ」等を送信する条件として設定しても良い。

これにより、通知情報生成部１０６は、「送信情報」に記載された情報を、通知情報の生成に必要な情報として取得することができる。

また、通知情報生成部１０６は、生成した通知情報を通知処理部１０７に出力する。また、通知情報生成部１０６は、通知情報を出力する際に、フィルタテーブルのレコードが保持していた「送信先」及び「サービスタイプ」を出力する。さらに、当該フィルタが暗号を保持していた場合、通知情報生成部１０６は暗号も、通知情報等と共に出力する。

通知処理部１０７は、通知情報生成部１０６から通知情報、「送信先」及び「サービスタイプ」が入力された場合、サービスタイプが保持する送信プロトコルで送信処理を行うプログラムを呼び出して、通知情報を送信先に送信する処理を行う。また、通知処理部１０７は、通知情報等とともに暗号が入力された場合、入力された暗号方法を用いて暗号化した後に通知情報を送信する。

この入力された暗号化方法で、位置情報管理サーバ１００とアプリケーションの間が暗号化される。この暗号化手段はどのような手段を用いても良く、例えばＩｐｓｅｃ、ｈｔｔｐｓ、ＳＳＬ或いはＤＥＳ等が考えられる。このように通知処理部１０７が、暗号化処理を行うことで、情報の漏洩を防止することができる。さらに、プライバシーを保持し、セキュリティを向上させることができる。

イベント編集受付部１０８は、位置情報管理サーバ１００に接続されたアプリケーション又はプロセスからの要求を受け付け、要求に適した通知情報を送信するために各テーブルのレコードの追加、変更又は削除を行う。本実施の形態において、イベント編集受付部１０８は、通知情報を生成する条件を設定するために応用イベントデータベース１１３の応用イベント管理テーブルのレコードの追加、又は該当するレコードの削除又は変更を行う。

また、イベント編集受付部１０８は、他のアプリケーションから追加するレコードとして、図８で示した応用イベント一覧から選択されたイベント名、及びイベント生成条件を設定する引数の情報が入力された場合に、応用イベントを登録することができる。これにより他のアプリケーションの要求に適した応用イベントを生成することができる。

また、イベント編集受付部１０８は、他のアプリケーションからの要求で登録されていたイベントの生成する条件を削除又は変更する旨の要求を受け付けた場合、要求と共に受け付けた情報から特定できる応用イベント管理テーブルのレコードの削除又は変更を行う。この要求と共に受け付けた情報はレコードを特定できる情報であればどの様な情報でもよく、例えばイベント名及び引数等が考えられる。また、変更の場合、変更する条件上記の情報と共に受け付け、この変更する条件によりレコードを変更する。

また、イベント編集受付部１０８は、応用イベント管理テーブルのレコードを削除する際に、依存関係を調べて、削除するレコードをトリガイベント等のイベント生成条件として用いているレコードが存在する場合、当該レコードの有効フラグをオフにして、使用を中止することができる。また、イベント編集受付部１０８は、当該レコードが新たに追加する処理を行う場合に、依存関係を調べて、これから生成するレコードにイベント生成条件として用いているレコードが存在する場合に、有効フラグをオンにする等の処理を行っても良い。これらの処理により、イベント生成処理の負荷を軽減することが出来るとともに、イベント生成時の労力を軽減することができる。

また、イベント編集受付部１０８は、他のアプリケーションから、フィルタリングの条件及び送信先等を入力された場合、フィルタリングデータベース１１４のフィルタテーブルに入力された情報に基づいたレコードを登録する。

また、イベント編集受付部１０８は、フィルタ登録の依頼の他に、フィルタの変更又はフィルタの削除等の要求も受け付ける。そして、受け付けた要求は、要求と共に受け取ったフィルタを指定する情報、さらに変更の場合は変更する条件を示す情報を用いてフィルタテーブルの該当するレコードの削除又は変更を行う。また、フィルタを指定する条件としては、サービスフィルタテーブルの「送信先」フィールド、「イベント」フィールドなどレコードを特定可能であればどのような条件でも良い。

このように、イベント編集受付部１０８が、生成するイベント及びフィルタの登録、変更及び削除を可能としたことで、他のアプリケーションが情報を定期的に送信して欲しい場合の他に、必要な場合のみ情報を送信して場合であっても、対応することが可能となる。

次に、以上のように構成された本実施の形態にかかる位置情報管理サーバ１００におけるリーダからＩＤ等の情報を受信してから通知情報をアプリケーションに通知するまでの処理について説明する。図１６は、本実施の形態にかかる位置情報管理サーバ１００における上述した処理の手順を示すフローチャートである。

まず、受信処理部１０２は、リーダ１５１ａ〜ｎが検出したアクティブタグ１６１ａ〜ｎのタグＩＤ等の情報をリーダ１５１ａ〜ｎから受信する（ステップＳ１６０１）。

そして、タグ情報管理部１０９が、受信処理部１０２が受信したタグＩＤ、受信したリーダのリーダＩＤ、信号強度及び検出時間を対応付けてタグ信号管理テーブルを更新する（ステップＳ１６０２）。

次に、位置情報取得部１０３は、１秒毎にタグ情報管理部１０９によりタグ信号管理テーブルが更新されているか否か確認する。そして、更新されていた場合、位置情報取得部１０３は、更新されたレコードから検出されたアクティブタグを示すＩＤを取得し、取得したＩＤの情報を保持するレコードを取得して、取得したレコードの情報に基づいて位置情報を算出することで、アクティブタグ１６１ａ〜ｎの位置情報を取得する（ステップＳ１６０３）。

そして、基本イベント生成部１０４は、入力された位置情報等又は所定時間の経過により予め設定された条件を満たした場合に、満たした条件と対応付けられた基本イベントを生成する（ステップＳ１６０４）。

次に、応用イベント生成部１０５は、入力された基本イベント又は生成された応用イベントをトリガとして、応用イベント管理テーブルが保持するイベント生成条件に合致した場合に、応用イベントを生成する（ステップＳ１６０５）。そして、応用イベント生成部１０５は、入力された基本イベント及び生成された応用イベント全てを通知情報生成部１０６に出力する。

次に、通知情報生成部１０６は、入力されたイベントに含まれていた情報と、この情報と対応付けられた情報がフィルタの条件を満たした場合、当該フィルタが保持している「送信情報」フィールドで特定される情報を取得し、取得した情報を対応付けて通知情報を生成する（ステップＳ１６０６）。つまり、入力されたイベントに関連する情報がフィルタの条件を満たしていない場合には、通知情報が生成されない。

次に、通知処理部１０７が、生成された通知情報を、当該フィルタが保持していた「送信先」フィールドで特定された送信先に通知する処理を行う（ステップＳ１６０７）。通知する際に、当該フィルタのサービスタイプが保持している送信プロトコルを用いて送信し、当該フィルタの暗号が定義されている場合、定義されている暗号を用いて暗号化を行う。

上述した処理手順により、アクティブタグ１６１ａ〜ｎを検出してからアプリケーション毎に適した情報を送信することが可能となる。なお、上述した処理手順は、本実施の形態によるＩＤ等の情報を受信してから通知情報を生成して通知処理を行うまでの処理手順の例を示したものであり、本発明をこの処理手順に制限するものではない。

次に、以上のように構成された本実施の形態にかかる位置情報管理サーバ１００の基本イベント生成部１０４における位置情報等が入力されてから生成した基本イベントを出力するまでの処理について説明する。図１７は、本実施の形態にかかる基本イベント生成部１０４における上述した処理の手順を示すフローチャートである。

まず、基本イベント生成部１０４は、位置情報取得部１０３で更新されたＩＤの位置情報等の入力を受け付ける（ステップＳ１７０１）。

次に、基本イベント生成部１０４は、前回イベントを生成してから１秒経過した場合に、ステップＳ１７０１で受け付けたＩＤの位置情報等の入力された情報が、基本イベント管理テーブルのレコードに設定されているイベント生成条件を満たしているか否か判断する（ステップＳ１７０２）。

イベント生成条件を満たしていると判断した場合（ステップＳ１７０２：Ｙｅｓ）、基本イベント生成部１０４は、イベント生成条件に対応付けられたイベント名等からイベントを生成する（ステップＳ１７０３）。また、基本イベント生成部１０４は、イベントを生成する際に、位置情報及びＩＤ等の情報をイベントに含める。

そして、基本イベント管理テーブルが保持している全てのイベント生成条件について確認が終了したか否か判断する（ステップＳ１７０４）。

全てのイベント生成条件について確認が終了していたと判断した場合（ステップＳ１７０４：Ｙｅｓ）、基本イベント生成部１０４は、生成した基本イベントを出力する処理を行う（ステップＳ１７０５）。

また、イベント生成条件を満たしていないと判断した場合（ステップＳ１７０２：Ｎｏ）及び全てのイベント生成条件について確認が終了していないと判断した場合（ステップＳ１７０４：Ｎｏ）、ステップＳ１７０２で判断対象となったイベント生成条件を保持しているレコードの次のレコードを判断対象としてセットする（ステップＳ１７０６）。これにより次のイベント生成条件が設定されたこととなり、ステップＳ１７０２でこのイベント生成条件を満足しているか否か判断する処理から行われる。

上述した処理手順により、入力された位置情報等から基本イベントを生成することが可能となる。なお、上述した処理手順は、本実施の形態による位置情報等が入力されてから生成した基本イベントを出力するまでの処理手順の例を示したものであり、本発明をこの処理手順に制限するものではない。

次に、以上のように構成された本実施の形態にかかる応用イベント生成部１０５における基本イベントの入力の受け付けから入力された基本イベント及び生成された応用イベントを出力するまでの処理について説明する。図１８は、本実施の形態にかかる応用イベント生成部１０５における上述した処理の手順を示すフローチャートである。

まず、応用イベント生成部１０５は、基本イベント生成部１０４から基本イベントの入力を受け付ける（ステップＳ１８０１）。

次に、応用イベント生成部１０５は、入力された最初の基本イベントを比較する対象イベントとして設定する（ステップＳ１８０２）。

そして、応用イベント生成部１０５は、対象イベントとして設定された基本イベントのイベント名と、応用イベント管理テーブルが保持するトリガイベントのイベント名が一致するか否か判断する（ステップＳ１８０３）。なお、初めて判断を行う場合、応用イベント管理テーブルが保持している最初のレコードを判断対象と設定し、この最初のレコードのトリガイベントを用いて判断を行う。

そして、イベント名が一致すると判断した場合（ステップＳ１８０３：Ｙｅｓ）、応用イベント生成部１０５は、対象イベントとして設定された基本イベントが保持する情報及び基本イベントとの対応関係から取得した情報により、トリガイベントと対応付けられた応用イベントの生成条件を満たすか否か判断する（ステップＳ１８０４）。

応用イベントの生成条件を満たすと判断した場合（ステップＳ１８０４：Ｙｅｓ）、応用イベント生成部１０５は、応用イベントを生成する（ステップＳ１８０５）。

また、応用イベントの生成条件を満たしていないと判断した場合（ステップＳ１８０４：Ｎｏ）及びイベント名が一致しないと判断した場合（ステップＳ１８０３：Ｎｏ）、応用イベント生成部１０５は、特に処理を行わない。

そして、応用イベント生成部１０５は、生成した応用イベントを対象イベントして設定して、ステップＳ１８０３からステップＳ１８０８までの処理について再帰処理を行う（ステップＳ１８０６）。これにより、応用イベントに基づいた応用イベントが生成される。

次に、応用イベント生成部１０５は、応用イベント管理テーブルが保持している全てのレコードの応用イベントの生成条件について比較したか否か判断する（ステップＳ１８０７）。

そして、応用イベントの生成条件について比較したと判断した場合（ステップＳ１８０７：Ｎｏ）、応用イベント生成部１０５は、応用イベント管理テーブルが保持している次のレコードを判断対象として設定し（ステップＳ１８０８）、ステップＳ１８０３で判断対象と設定したレコードのトリガイベントを用いて判断が行われることになる。

そして、応用イベント生成部１０５は、入力された全ての基本イベントに対して判断処理を行ったか否か判断する（ステップＳ１８０９）。

入力された全ての基本イベントに対して判断処理が終了していないと判断した場合（ステップＳ１８０９：Ｎｏ）、応用イベント生成部１０５は、入力された基本イベントで判断処理の対象となっていない基本イベントを選択し、この選択された基本イベントを次の判断処理の対象イベントとして設定する（ステップＳ１８１０）。この設定された基本イベントを用いてトリガイベントのイベント名と一致するか否かの判断から行われる（ステップＳ１８１０）。

そして、入力された全ての基本イベントに対して判断処理が終了した判断した場合（ステップＳ１８０９：Ｙｅｓ）、応用イベント生成部１０５は、入力された基本イベント及び生成された応用イベントを、通知情報生成部１０６に出力処理を行う（ステップＳ１８１１）。

上述した処理手順により、基本イベント及び応用イベントが通知情報生成部１０６に入力されるので、応用イベント管理テーブルに設定された条件に基づいた通知情報を生成することが可能となる。なお、上述した処理手順は、本実施の形態による基本イベントの入力の受け付けから入力された基本イベント及び生成された応用イベントを出力するまでの処理手順の例を示したものであり、本発明をこの処理手順に制限するものではない。

また、本実施の形態において、‘ＴＩＭＥ＿ＣＹＣＬＥ’を生成する間隔を示すサイクル時間を１秒とし、基本イベント生成部１０４による基本イベントを生成する生成間隔を１秒としたが、これらの時間に制限するものではなく、アプリケーションからのニーズ及び位置情報管理サーバ１００の処理能力に応じて適切な時間を設定する。さらに、保持期間についても３秒に制限するものではない。

また、本実施の形態において、イベントの生成を２段階で行うこととしたが、２段階に制限するものではなく、３段階以上であってもよい。

本発明では、位置情報取得部の仕組みに依存した１段階のイベント生成の定義とは異なる、イベント生成の定義の仕組みを提供することで、各種アプリケーションで実際に必要とされる条件の複雑なイベントの生成を、少ないコストで定義することができる。

また、本実施の形態は、通知先をアプリケーションに制限するものではなく、プロセスやネットワークを介して接続された装置やプロセス等の情報を送受信可能で場所であれば、どこを通知先として設定しても良い。

本実施の形態ではこのように基本イベント及び応用イベントの２段階のイベント生成を行うこととした、これにより、複雑な条件に基づいた通知情報の出力が可能となった。これにより、通知情報を受け取るアプリケーションは、入力された通知情報を管理して分析、加工して最適な情報を抽出するという処理の必要が無くなり、処理負担が軽減されることとなる。

さらに、２段階の条件を満たした場合の最適な情報のみ通知することになったので、本来的にはアプリケーションが不要とする情報の通知が行われないこととなり、アプリケーションの処理負担が軽減すると共にネットワークのトラフィックも軽減される。さらにアプリケーション開発者は、通知情報に基づくアプリケーションを開発する際に、複雑な処理を実行するプログラムを作成する必要が無くなり、負担が軽減される。

また、１段階で複雑な条件を設定しようとした場合、マクロ等を用意するなど複雑な処理を行う必要があるが、本実施の形態では２段階で複雑な条件を設定した。これにより容易に複雑な条件の設定を可能とした。

また、本発明は、上述した位置情報サーバに制限されないイベント生成方法であるため、既存の情報の通知処理を利用した高度イベント加工システムの構築が可能である。本実施の形態のアクティブタグを用いた位置情報管理サーバだけでなく、位置情報管理システムにおいては、例えば、携帯端末を利用した位置取得サービスやＧＰＳなどの位置情報管理システムに適用することが可能である。

さらに、位置情報の管理装置のみならず、事象の発生又は変化に応じて通知を行う装置であれば適用することができる。例えば、事象の発生を計測するために設置されたセンサ等から検出した情報に基づいて２段階以上のイベント生成条件を設定して、これらの条件を満足した場合に通知情報を出力する装置などに適用することも可能である。

図１９は、位置情報管理サーバ１００の機能を実現するためのプログラムを実行したＰＣのハードウェア構成を示した図である。本実施の形態の位置情報管理サーバ１００は、ＣＰＵ（Central Processing Unit）１９０１等の制御装置と、ＲＯＭ（Read Only Memory）１９０２やＲＡＭ（Random Access Memory）１９０３等の記憶装置と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disk）ドライブ装置等の外部記憶装置１９０４と、ディスプレイ装置等の表示装置１９０７と、ネットワークに接続する通信インターフェース１９０６と、キーボードやマウス等の入力装置１９０５と、これらを接続するバス１９０８を備えており、通常のコンピュータを利用したハードウェア構成となっている。

本実施形態の位置情報管理サーバ１００で実行される通知処理プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、本実施形態の位置情報管理サーバ１００で実行される通知処理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の位置情報管理サーバ１００で実行される通知処理プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

また、本実施形態の通知処理プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

本実施の形態の位置情報管理サーバ１００で実行される通知処理プログラムは、上述した各部（受信処理部、タグ情報管理部、位置情報取得部、基本イベント生成部、応用イベント生成部、通知情報生成部、通知処理部、イベント編集受付部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記録媒体から通知処理プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、受信処理部、タグ情報管理部、位置情報取得部、基本イベント生成部、応用イベント生成部、通知情報生成部、通知処理部、イベント編集受付部が主記憶装置上に生成されるようになっている。

以上のように、本発明にかかる情報管理装置、位置情報管理装置、情報管理方法、情報管理プログラム、コンピュータに読み取り可能な記録媒体及び位置情報管理システムは、他のアプリケーション、プロセス又は装置に情報を通知する技術として有用であり、特に、タグ等により物体の位置情報を管理し、この管理している情報に基づいて通知する技術に適している。

実施の形態にかかる位置情報管理システムの構成を示すブロック図である。 位置情報管理サーバの全体構成の概念的に示した説明図である。 実施の形態にかかるリーダ位置管理テーブルの構造を示した図である。 実施の形態にかかるタグ信号管理テーブルの構造を示した図である。 実施の形態にかかるＩＤ位置情報管理テーブルの構造を示した図である。 実施の形態にかかる基本イベント管理テーブルの構造を示した図である。 実施の形態にかかる応用イベント管理テーブルの構造を示した図である。 実施の形態にかかる応用イベント管理テーブルにレコードとして登録される応用イベントの一覧を示した図である。 実施の形態にかかるイベント状態管理テーブルの構造を示した図である。 実施の形態にかかるエリアテーブルの構造を示した図である。 実施の形態にかかるＩＤ情報管理テーブルの構造を示した図である。 実施の形態にかかるフィルタテーブルの構造を示した図である。 実施の形態にかかる位置情報取得部から入力される位置情報等と、基本イベント生成部で生成されるイベントの相関関係の一例を示した説明図である。 実施の形態にかかる位置情報管理サーバの応用イベント生成部で‘ＳＴＡＹ＿ＡＲＥＡ’イベントが生成された場合にイベント状態管理テーブルに登録されるレコードの一例を示した図である。 実施の形態にかかる位置情報管理サーバの応用イベント生成部で生成された‘ＬＥＡＶＥ’イベントが保持されたイベント状態管理テーブルの一例を示した図である。 本実施の形態にかかる位置情報管理サーバにおけるリーダからＩＤ等の情報を受信してから通知情報をアプリケーションに通知するまで処理の手順を示すフローチャートである。 本実施の形態にかかる基本イベント生成部１０４における位置情報等が入力されてから生成した基本イベントを出力するまでの処理の手順を示すフローチャートである。 本実施の形態にかかる応用イベント生成部１０５における基本イベントの入力の受け付けから入力された基本イベント及び生成された応用イベントを出力するまでの処理の手順を示すフローチャートである。 位置情報管理サーバの機能を実現するためのプログラムを実行したＰＣのハードウェア構成を示した図である。

符号の説明

１００ 位置情報管理サーバ
１０１ 記憶部
１０２ 受信処理部
１０３ 位置情報取得部
１０４ 基本イベント生成部
１０５ 応用イベント生成部
１０６ 通知情報生成部
１０７ 通知処理部
１０８ イベント編集受付部
１０９ タグ情報管理部
１１１ 位置情報データベース
１１２ 基本イベントデータベース
１１３ 応用イベントデータベース
１１４ フィルタリングデータベース
１５１ａ〜ｎ リーダ
１６１ａ〜ｎ アクティブタグ
２０１ アプリケーションＡ
２０２ アプリケーションＢ
２０３ アプリケーションＣ
２０４ アプリケーションＤ
１３０１、１３０２、１３０３ イベント生成時間
１９０１ ＣＰＵ
１９０２ ＲＯＭ
１９０３ ＲＡＭ
１９０４ 外部記憶装置
１９０５ 入力装置
１９０６ 通信インターフェース
１９０７ 表示装置
１９０８ バス

Claims (6)

1. 対象となる事象の情報を管理し、該対象に備え付けられた携帯型情報記憶媒体を検出するための検出装置と接続された情報管理装置であって、
   前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、
   前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信手段と、
   前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、
   アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、
   前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、
   を備えたことを特徴とする情報管理装置。
2. 物体に備えられた携帯型情報記憶媒体を検出装置が検出することで特定できる物体の位置情報を管理する位置情報管理装置において、
   前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、前記物体の位置に関して通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、
   前記検出装置から、所定の情報を受信し、前記所定の情報に基づく前記携帯型情報記憶媒体の位置を示す位置情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持受信手段と、
   前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記位置情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、
   アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、
   前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、
   を備えたことを特徴とする位置情報管理装置。
3. 対象となる事象の情報を管理し、該対象に備え付けられた携帯型情報記憶媒体を検出するための検出装置と接続された情報管理装置で実行される情報管理方法であって、
   前記情報管理装置が、前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、
   前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて保存する第２の記憶手段と、
   アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、を備え、
   受信手段が、前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信ステップと、
   生成手段が、前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成ステップと、
   通知手段が、前記生成ステップで生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知ステップと、
   を有することを特徴とする情報管理方法。
4. 請求項３に記載された情報管理方法をコンピュータで実行させることを特徴とする情報管理プログラム。
5. 請求項４に記載された情報管理プログラムを格納したコンピュータの読み取り可能な記録媒体。
6. 位置情報を取得する対象となる区域内に存在する物体に備えられた携帯型情報記憶媒体と、前記携帯型情報記憶媒体と非接触により前記携帯型情報記憶媒体を検知する検出装置と、検出された前記携帯型情報記憶媒体を備えた物体の位置情報を管理する位置情報を管理する位置情報管理装置と、を備えた位置情報管理システムにおいて、
   位置情報管理装置は、
   前記検出装置を特定する識別情報と、携帯型情報記憶媒体からの信号の信号強度と、を含む所定の情報に基づいて、前記物体の位置に関して通知する情報の種類を示す通知種類を特定する、通知規則情報を記憶する第１の記憶手段と、
   前記検出装置から、所定の情報を受信し、前記所定の情報と前記所定の情報を受信した時間を示す検出時間情報とを対応付けて第２の記憶手段に保持する受信手段と、
   前記第２の記憶手段に保持された、前記検出時間情報の経過に伴う前記所定の情報の変化に基づいて、前記通知規則情報に従って特定される通知種類の、第１の通知情報を、前記検出時間情報を含めて生成及び保持すると共に、保持された前記第１の通知情報と第１の通知情報について予め定められた通知規則とに基づいて特定される通知種類の、前記第２の通知情報を、前記検出時間を含めて生成する生成手段と、
   アプリケーション又はプロセスを送信先として送信するための送信先情報と、アプリケーション又はプロセスに通知されるべき情報の種類である通知種類と、を記憶する第３の記憶手段と、
   前記生成手段で生成された前記第２の通知情報を、当該第２の通知情報の前記通知種類に前記第３の記憶手段で対応付けられた前記送信先情報で示された送信先に通知する通知手段と、
   を備えたこと
   を特徴とする位置情報管理システム。

Images