▶ 株式会社東芝の特許一覧 ▶ 東芝ソリューション株式会社の特許一覧
特開2023-73718コンテキストマッチング関連情報処理システム、情報処理方法、情報処理装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023073718
(43)【公開日】2023-05-26
(54)【発明の名称】コンテキストマッチング関連情報処理システム、情報処理方法、情報処理装置
(51)【国際特許分類】
H04L 67/562 20220101AFI20230519BHJP
G06Q 30/0251 20230101ALI20230519BHJP
G06Q 30/0207 20230101ALI20230519BHJP
【ＦＩ】
H04L67/562
G06Q30/02 398
G06Q30/02 320
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2021186348
(22)【出願日】2021-11-16
(71)【出願人】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(71)【出願人】
【識別番号】301063496
【氏名又は名称】東芝デジタルソリューションズ株式会社
(74)【代理人】
【識別番号】110001737
【氏名又は名称】弁理士法人スズエ国際特許事務所
(72)【発明者】
【氏名】吉本 武弘
(72)【発明者】
【氏名】石塚 晃
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049BB07
5L049BB08
(57)【要約】
【課題】受信側又は送信側のユーザは、通信エリアにおいて、予め設定している状況が成立した場合、ユーザが特別な操作をしないときであっても、受信側又は送信のユーザは、サービス情報を受け取る、又は提供することができる。
【解決手段】通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられる。前記ビーコン信号を受信し、受信した前記ユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記コンテキストデータに応じたサービス情報の出力を行う。そして、前記サービス情報の出力部を備える。
【選択図】図２Ａ
【解決手段】通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられる。前記ビーコン信号を受信し、受信した前記ユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記コンテキストデータに応じたサービス情報の出力を行う。そして、前記サービス情報の出力部を備える。
【選択図】図２Ａ
【特許請求の範囲】
【請求項1】
コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、
前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器と、
前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理する第1の処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用出力データとして処理する第２の処理器を備える、
ことを特徴とする情報処理システム。
前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器と、
前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理する第1の処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用出力データとして処理する第２の処理器を備える、
ことを特徴とする情報処理システム。
【請求項2】
前記ノード通知データは、前記第２の情報処理器に、クーポンを与えるデータである、請求項１記載の情報処理システム。
【請求項3】
前記コンテキスト判定部は、インターネットを介して前記第１の情報処理器に接続されている、
請求項１記載の情報処理システム。
請求項１記載の情報処理システム。
【請求項4】
前記コンテキスト判定部は、前記第１の情報処理器に内蔵されている、
請求項１記載の情報処理システム。
請求項１記載の情報処理システム。
【請求項5】
前記コンテキスト判定部は、前記第１の情報処理器、前記第２の情報処理器から送られてきた前記第１のコンテキストと前記第２のコンテキスト、さらに他の第３の情報処理器、第４の情報処理器から送られてきた第３のコンテキストと前記第４のコンテキストのマッチング処理を行い、コンテキスト毎に各情報処理器のデバイスＩＤを分類したテーブルを備える、請求項２又は３又は４に記載の情報処理システム。
【請求項6】
コンテキスト判定部が第１の情報処理器の第１のコンテキストを登録可能とし、
前記コンテキスト判定部が第２の情報処理器の第２のコンテキストを登録可能とし、
前記第１の情報処理器と前記第２の情報処理理器が互いにビーコン通信を行ったときに、
判定部がビーコン・パケットに含まれるコンテキスト関連情報を判定し、
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器が前記結果データをノード通知データとして処理し、
前記第２の情報処理器が前記結果データをユーザ通知用出力データとして処理する、
ことを特徴とする情報処理方法。
前記コンテキスト判定部が第２の情報処理器の第２のコンテキストを登録可能とし、
前記第１の情報処理器と前記第２の情報処理理器が互いにビーコン通信を行ったときに、
判定部がビーコン・パケットに含まれるコンテキスト関連情報を判定し、
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器が前記結果データをノード通知データとして処理し、
前記第２の情報処理器が前記結果データをユーザ通知用出力データとして処理する、
ことを特徴とする情報処理方法。
【請求項7】
コンテキスト判定部に第１のコンテキストを登録し、エージェントとして動作する情報処理装置であって、
前記コンテキスト判定部に第２のコンテキストを登録している他の情報処理装置が通信エリア内にあるとき、互いにビーコン・パケットを用いたビーコン通信を行い、
前記コンテキスト判定部から得られるコンテキスト関連情報が前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す結果データを得た場合、
前記結果データをノード通知データとして処理することを特徴とする情報処理装置。
前記コンテキスト判定部に第２のコンテキストを登録している他の情報処理装置が通信エリア内にあるとき、互いにビーコン・パケットを用いたビーコン通信を行い、
前記コンテキスト判定部から得られるコンテキスト関連情報が前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す結果データを得た場合、
前記結果データをノード通知データとして処理することを特徴とする情報処理装置。
【請求項8】
前記ノード通知データは、前記他の情報処理器に、クーポンを与えるデータである、
請求項７記載の情報処理装置。
請求項７記載の情報処理装置。
【請求項9】
前記所定のコンテキスト判定部は、外部のサーバに設けられている、請求項７記載の情報処理装置。
【請求項10】
前記所定のコンテキスト判定部は、自器の内部に設けられている、請求項７記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテキストマッチング関連情報処理システム、情報処理方法、情報処理装置に関し、さらに受信方法、送信方法、サーバなどにも関連するものである。
【背景技術】
【0002】
一般に、ユーザが通信システムを利用して何等かのサービス情報を取得するには、例えば次のような方法がある。ユーザは、パーソナルコンピュータ（以下ＰＣと称する）や携帯端末（例えば、スマートフォン（以下スマホと称する））を利用し、ニーズに応じて検索情報やＵＲＬ（Uniform Resource Locator）を入力する、あるいは、画面上に表示されているコマーシャル画面をクリックし、該当するサーバと通信環境を構築する。すると、サーバからサービス情報が当該ＰＣやスマホに提供される。
【0003】
このように、ユーザが何等かのサービス情報を取得する方法は、ユーザが“ニーズ”に応じてＰＣやスマホを操作し、サーバを積極的にアクセスし、サーバが提供するサービス情報を取得する方法である。この方法は、ユーザが起点となる方法であるから、以下“ユーザ起点”方式と称することにする。
【0004】
上記の“ユーザ起点”方法でなくてもサービス情報を取得できる特別なケースがある。この特別なケースは、例えば地震などが発生したときに特定の機関（例えば気象庁などの公的な専門機関）が「緊急通知」を一斉に発信するケースである。この方法は、受信者（ユーザ）が特定されることはなく、ユーザがスマホで一斉に受信する。このような情報の提供は、ユーザにとって有意義である。一方では、各種のサービス情報（ユーザの意図しないコマーシャル等）をユーザのスマホやＰＣに送る通信システムもあり、この通信システムによると、ユーザは興味のないサービス情報まで提供されることが多々ある。
【0005】
上記のように従来の多くのサービス情報提供システムは、“ユーザ起点”方式が基本であり、ユーザの具体的な“ニーズ”或は“リクエスト”に応じて、サービス情報を提供するシステムである。また、“ユーザ起点”方式を採用するシステムは、ユーザが明示的に意識した“ニーズ”或は“リクエスト”を提示した時のみ、サービス情報の提供を行う。このため、従来のサービス情報提供システムは、サービス情報を提供するチャンスの規模が小さいと言える。また、“ユーザ起点”方式ではなく「地震速報」などのサービス情報提供システムは、特別なケースに限られており融通性が狭いと言える。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特許第６７１５５０１号公報
【特許文献2】特開２０２１－６４３９４号公報
【特許文献3】特開２０２１－１１１１６４号公報
【特許文献4】特開２０２１－１１９４８８号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
ここで本発明の発明者等は、ユーザの“ニーズ”或は“リクエスト”に呼応するサービス情報をユーザに提供するチャンス、或はユーザがサービス情報を受取るチャンスは、ユーザが“ニーズ”或は“リクエスト”を明示的に意識していないタイミングであっても、多々発生する点に着目した。
【0008】
このタイミングは、周辺で複数のユーザや物の複数の状態の組み合わせが発生した場合であり、ここでは、この複数の状態の組み合わせを“状況”と称することにする。なお状況は、“環境”“雰囲気”“コンテキストスキームルール設定”または単純に“ルール設定”と称してもよい。
【0009】
さらに、“複数の状態”は、サービスの目的に応じて種々の状態がある。状態の代表的な例を示すと、例えば以下のようなものがある。
・複数のユーザの目的の共通性が存在する状態
・特定の物とユーザとが近接した状態
・サービスを受けるユーザと、当該サービスを提供するユーザが近接した状態
・物やユーザが所定の数揃った状態
・その他。
・複数のユーザの目的の共通性が存在する状態
・特定の物とユーザとが近接した状態
・サービスを受けるユーザと、当該サービスを提供するユーザが近接した状態
・物やユーザが所定の数揃った状態
・その他。
【0010】
そこで、本発明は、“ユーザ起点”方式では無く、状況或は状況ルールを起点とする方法（以下、仮に“状況起点”或は“状況ルール起点”方式と言う）によりサービス情報を提供する、或はサービス情報を受取ることができる、今までにない新しい方法、装置やシステムを工夫することにした。
【0011】
実施形態の第１の局面では、ユーザは、状況ルールを起点として、少なくともサービス情報を受けることができる或はサービス情報を提供することができるコンテキストマッチング関連情報処理システム、情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【0012】
一実施形態によれば、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器と、を備える。そして前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。
【0013】
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、前記第１の情報処理器は前記結果データをノード通知データとして処理する第1の処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用出力データとして処理する第２の処理器を備える、情報処理システムが提供される。
【0014】
他の実施形態によれば、前記コンテキストは予めコード化されたものでもよい。
【図面の簡単な説明】
【0015】
【発明を実施するための形態】
【0016】
以下、実施の形態について図面を参照して説明する。本発明のいくつかの実施形態を説明するが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。さらにまた、請求項の各構成要素において、構成要素を分割して表現した場合、或いは複数を合わせて表現した場合、或いはこれらを組み合わせて表現した場合であっても本発明の範疇である。また、複数の実施形態を組み合わせてもよく、この組み合わせで構成される実施例も発明の範疇である。
【0017】
また、図面は、説明をより明確にするため、実際の態様に比べて、各部の幅、厚さ、形状等について模式的に表される場合がある。また請求項を制御ロジックとして表現した場合、コンピュータを実行させるインストラクションを含むプログラムとして表現した場合、及び前記インストラクションを記載したコンピュータ読み取り可能な記録媒体として表現した場合でも本発明の装置を適用したものである。また、使用している名称や用語についても限定されるものではなく、他の表現であっても実質的に同一内容、同趣旨であれば、本発明に含まれるものである。
【0018】
本実施形態では、「情報処理器」と言う用語を用いるが、以下のようなデバイス、ソフトウエア、或は機器をもまた含む。
・半導体チップで構成され、センサ信号の入力部を持ち、センサから入力処理した信号を送信する送信器を含む。
・またセンサ信号の入力部がセンサと直結し、センサから入力処理した信号を送信する送信器を含む。
・センサ信号の入力部がセンサからの無線信号を受信し、センサから入力処理した信号を送信する送受信器を含む。
・外観がハードウエアブロックの構成でありゲートウエイとして構成されており、近距離無線通信を行う機能、ネットワークに接続可能な機能を有する前記ゲートウエイを含む。
・また前記ゲートウエイがエージェントとして動作する場合も当該ゲートウエイを含む。
・外観がスマートフォンであり、シンプルな通知機能、シンプルな受信機能、エージェントとして動作する場合も当該スマートフォンを含む。
・また外観を問わず、上記半導体チップが埋設されたテープ、カード、基板なども含み、さらには、プログラムで動作する装置に、データ処理プログラムとしてインストールされている場合も本願の言う情報処理器である。
＜ビーコン信号＞
図１を参照して、まず、本実施形態において利用されるビーコン信号について説明する。通信機能を備えた情報処理器は、ビーコン信号として、ＢＬＥ（ブルートゥース（登録商標）・ロウ・エネルギ（Bluetooth（登録商標） Low Energy）機能で使われるアドバタイジング・パケットを使用する。
・半導体チップで構成され、センサ信号の入力部を持ち、センサから入力処理した信号を送信する送信器を含む。
・またセンサ信号の入力部がセンサと直結し、センサから入力処理した信号を送信する送信器を含む。
・センサ信号の入力部がセンサからの無線信号を受信し、センサから入力処理した信号を送信する送受信器を含む。
・外観がハードウエアブロックの構成でありゲートウエイとして構成されており、近距離無線通信を行う機能、ネットワークに接続可能な機能を有する前記ゲートウエイを含む。
・また前記ゲートウエイがエージェントとして動作する場合も当該ゲートウエイを含む。
・外観がスマートフォンであり、シンプルな通知機能、シンプルな受信機能、エージェントとして動作する場合も当該スマートフォンを含む。
・また外観を問わず、上記半導体チップが埋設されたテープ、カード、基板なども含み、さらには、プログラムで動作する装置に、データ処理プログラムとしてインストールされている場合も本願の言う情報処理器である。
＜ビーコン信号＞
図１を参照して、まず、本実施形態において利用されるビーコン信号について説明する。通信機能を備えた情報処理器は、ビーコン信号として、ＢＬＥ（ブルートゥース（登録商標）・ロウ・エネルギ（Bluetooth（登録商標） Low Energy）機能で使われるアドバタイジング・パケットを使用する。
【0019】
Bluetooth Low Energyの規格では、通信用のチャンネルとして４０チャンネルが確保されており、そのうち３チャンネルが、アドバタイジング・チャンネルとして用いられる。このアドバタイジング・チャンネルは、アドバタイズメント・パケットを送信するためのチャンネルであり、デバイス自器の存在を周囲に伝えるためのデータを送信する。アドバタイジングのインターバル時間は、２０ｍ秒から１０．２４ｍ秒である。アドバタイジングは、設定されている３つのチャンネルのそれぞれで、アドバタイズメント・パケットを搬送するビーコン信号をブロードキャストする。
【0020】
通信機能を備えた情報処理器は、種々のタイプが存在し、サーバとインターネットを介して接続し互いに交信可能なものも含まれる。
【0021】
本実施形態は、「上記のアドバタイズメント・パケットはその一部の領域に、ユーザが任意に使用できる領域を有する」と言う点に着目している。
【0022】
また、情報処理器は、簡素化された構成のビーコンデバイスとして構成されるのみならず、情報処理器は、センサと複合化された複合化チップや複合化装置又はその一部として構成される場合がある。さらに情報処理器は、ビーコンモジュールとしてスマホと複合化された複合化装置や複合化システム又はその一部として構成される場合もある。さらにまた、情報処理器は、ビーコンモジュールとしてエッジコンピュータと複合化された複合化装置や複合号化システム又はその一部として構成される場合もある。
【0023】
本実施形態は、アドバタイズメント・パケットが上記の複合化チップ、複合化装置、あるいは複合化システムに有効に適用できるように、当該アドバタイズメント・パケット（以下ビーコン・パケットと称する）の構成を以下のように設定している。
＜ビーコン・パケット＞
図１に示すように、上記の情報処理器が使用する共通フォーマットのビーコン・パケット２１を示している。ビーコン・パケット２１は、３２バイトで構成され、ヘッダー領域２２が７バイト、ユーザ領域２３が２５バイトである。ユーザ領域２３は、アプリＩＤ/サービスＩＤ領域２４と、通信データ部領域２５を含む。ユーザ領域２３に記述されるデータが、コンテキストマッチング用の関連データである。サービスＩＤ領域２４に記述される情報は、その全体若しくは一部がアプリＩＤ或はサービスＩＤと称されてもよい。
＜ビーコン・パケット＞
図１に示すように、上記の情報処理器が使用する共通フォーマットのビーコン・パケット２１を示している。ビーコン・パケット２１は、３２バイトで構成され、ヘッダー領域２２が７バイト、ユーザ領域２３が２５バイトである。ユーザ領域２３は、アプリＩＤ/サービスＩＤ領域２４と、通信データ部領域２５を含む。ユーザ領域２３に記述されるデータが、コンテキストマッチング用の関連データである。サービスＩＤ領域２４に記述される情報は、その全体若しくは一部がアプリＩＤ或はサービスＩＤと称されてもよい。
【0024】
ヘッダー領域２２は、Bluetooth Low Energyの規格そのものであり、ここでは詳細な説明は省略する。本実施形態では、ユーザが独自に使用できる範囲である、バイト７～バイト３１に着目している。
【0025】
バイト７～バイト８（符号２４aの領域）には、アプリＩＤが記述される。このアプリＩＤの中には、メンバＩＤ（Member ID：電子装置のユーザの識別情報）が記述される。メンバＩＤ（Member ID：電子装置のユーザの識別情報）は、企業や組織を識別する情報である。このバイト７～バイト８が予約値（reserved）例えば０ｘ００００の場合は、特殊用途での使用を想定しており、通常での利用は禁止される。
【0026】
バイト９～バイト１０（符号２４ｂの領域）には、サービスＩＤが記述される。このサービスＩＤには、モジュールＩＤ（Module ID：非特定アプリケーションの識別情報）が記述される。モジュールＩＤ（Module ID）は、企業や組織毎のプログラムモジュールの内部識別情報であり、例えば利用者のスマートフォンに、ある企業や組織の複数の個別アプリがインストールされている場合、これらのデータ構造を識別出来るように個別アプリ毎にモジュールＩＤを割り当てることができる。
【0027】
バイト１１（符号２４ｃの領域）には、フレームタイプ（Frame Type）が記述される。フレームタイプ（Frame Type）は送信種別を示す。フレームタイプ（Frame Type）は、デバイス間で、通信が行われたときに、通信の正確性を上げるためにもので、相手に対して「応答を要求する」或は「応答を要求しない」を示すフラッグとコマンドを含む。コマンドは、例えばセンサ値を通知する、ＪＯＢを通知する、ＪＯＢ結果を通知する、などがある。これにより、相互の通信が確実に実施される。
【0028】
バイト１２～バイト３１（符号２５の領域）は、通信データ部と言われるパラメータ部（Parameters：送信情報）である。パラメータ部は、複数のパラメータを格納する。各パラメータは、ＴＬ部とＶＡＬ部からなる。ＴＬ部は１バイトからなり、ＴＹＰＥフィールドとＬＥＮＧＴＨフィールドからなる。ＴＹＰＥフィールドは、ＶＡＬ部内のデータのタイプ（int型、float型、string型がある）が、int型、float型、string型のいずれであるかを区別している（予め設定された１６進数で区別している）。ＬＥＮＧＴＨフィールドは、ＶＡＬ部のデータのデータ長を示している（予め設定された１6進数で示す）。ＶＡＬ部には、ＴＹＰＥフィールドで特定されたタイプであり、且つＬＥＮＧＴＨフィールドで特定された長さのデータが記述される。
【0029】
上記の記述方式を利用して、例えば以下のような情報が記述される。バイト１２～バイト１３（符号２５aの領域）には、ノードＩＤ、バイト１４（符号２５ｂの領域）には情報ＩＤ，バイト１５－１６（符号２５ｃの領域）には制御コード、バイト１７－３１（符号２５ｄの領域）にはデータ部（状態コード、判別用コード、アクション指示）などが記述される。
【0030】
ノードＩＤとは、このビーコン・パケット２１を送信するデバイスの識別データであり、例えば、エージェント、ノード、スマホ、ゲートウエイなどのデバイスを識別する識別データである。
【0031】
情報ＩＤとは、どのような種類の情報が送られているかを示す。種類としては、例えばＧＰＳ情報、センサ情報、などがある。
【0032】
制御コードは、例えば新しい状況ルールが登録される場合、或は状況ルールに変更があるとき、などを伝える場合、或はルールそのものを伝える場合に利用される。
【0033】
データ部のデータ（状態コード、判別用コード、アクション指示コードなど）は、コンテキストに対応したスキーマ情報が利用される。つまり、送信側と受信側で予め取り決めた意味をもつコードが用いられる。また、利用するコンテキストマッチングサービスの種類によっては、生のコンテキストデータが用いられる場合も含む。
【0034】
上記のエリアの情報は、一般には属性情報と称される。上記の属性情報は、固定のものではなく限定されるものではない。属性情報は、基本的には、いわゆるコンテキストデータの取り扱いを指示するものである。したがってシステム運用者において、属性情報のフォーマットや内容は種々であり、重要なものは、属性情報がこのエリアに存在することである。
【0035】
なお、上記のパラメータ部のデータには暗号化処理が行われている場合もある。また特別なケースとして、パスワードを用いた圧縮処理が施されている場合もある。パスワードが、第１のユーザの第１のデバイスと、第２のユーザの第２のデバイス間で利用される場合、ユーザはそれぞれのデバイスに予めパスワードを登録することができる。これにより、第１のデバイスと第２のデバイス間のビーコン通信は自動的に解凍されようになっている。
＜実施形態の動作概要＞
ここで、一実施形態の動作の概要の一例を説明する。
サービス提供者（情報を提供する側）が第1の情報処理器（エージェント）を有するものとする。これに対して、サービス要求者（情報を欲しい人、或は、情報の提供のアシストを受けたい側）が第２の情報処理器（ノード）を有するものとする。
＜実施形態の動作概要＞
ここで、一実施形態の動作の概要の一例を説明する。
サービス提供者（情報を提供する側）が第1の情報処理器（エージェント）を有するものとする。これに対して、サービス要求者（情報を欲しい人、或は、情報の提供のアシストを受けたい側）が第２の情報処理器（ノード）を有するものとする。
【0036】
今、サービス要求者（店）が第２の情報処理器（以下第1のノード）のデバイスＩＤ１と第１のコンテキストデータ（例えばメロンパン売れ残り）をコンテキスト判定部（後述する登録器）に登録したとする。
【0037】
サービス要求者（客）が、第２の情報処理器（以下第２のノード）のデバイスＩＤ２と第２のコンテキストデータ（例えばメロンパン好き）をコンテキスト判定部（後述する登録器）に登録したとする。
【0038】
さらに第１の情報処理器（以下エージェント）が、コンテキストデータ「メロンパン値引きクーポン」をコンテキスト判定部（後述する登録器）に登録したとする。なおエージェントと店のノードとは、一体の場合がある。
【0039】
上記の設定により、エージェントは、コンテキスト判定部からの指令に基づいてコンテキストデータ「メロンパン値引きクーポン」の送信準備を行うことができる。
【0040】
コンテキスト判定部は、上記した登録時に、（メロンパン値引き）のキーワード（メロンパン）と（メロンパン好き）のキーワード（メロンパン）とが、マッチング関係にあると判断する。そしてコンテキスト判定部は、コンテキストデータのキーワード（メロンパン）を共通ワードとして、第１のノードのデバイスＩＤ１と第２のノードデバイスＩＤ２とを同一グループとして管理する。別の言い方をすると、第１のノードと第２のノードとが紐づけされる。また、このとき、エージェントも「メロンパン」を共通ワードとして、第１ノード、第２のノードと紐付けされグループ化される。
【0041】
エージェントは、同一グループのノードのデバイスＩＤ１とＩＤ２をコンテキスト判定部から受け取ることができる。今、エージェントの通信エリア内に、第１のノード（客が所有している）が浸入し、ブロードキャストを行ったとする。このとき第１のノードは、エージェントではないので、単純に自器のデバイスＩＤ２のみをパラメータ部のノードＩＤ領域に記述してブロードキャストを行う。
【0042】
このとき、エージェントは、同一グループのデバイスＩＤ１とＩＤ２をコンテキスト判定部から受け取っているので、通信エリア内に、コンテキストマッチングによりグループ化されたデバイス（第１のノード）が浸入していることを認識することができる。そしてエージェントは、ジョブ或はアクションの１つとして、「メロンパン値引きクーポン」を第１のノードへ自動送信する。「メロンパン値引きクーポン」のデータは、データ部に記述されて送られる。このデータ（つまりコンテキスト）は、コード化（例えばコンテキスト番号化）されたものでもよく、変換処理機能をシステムが所有することで可能である。
【0043】
これにより、第１のノード（客）は、操作やサーチをなんら行うことなく、自動的に「メロンパン値引きクーポン」を取得することができる。
【0044】
上記のように第１のノード（客）は、エージェントが送信してきたパラメータ部２５の中に自器のデバイスＩＤと「メロンパン値引きクーポン」（或は所定のマッチング通知情報）があるために、所定の状況ルール（複数の情報機器間でコンテキストマッチングという状態）が成立していることを検出することができる。
【0045】
一方、第２のノード（店）は、自器が提供しているコンテキスト「メロンパン値引きクーポン」に対応して、エージェントが、「メロンパン値引きクーポン」の送信を行ったことを認識することができる。つまり、第２のノード（店）に対するアシスト（或はＣＭ）が成功したことを認識することができる。これにより、本システムは、マッチング効果をより高める（販売促進の強化を得る）ことができる。
【0046】
一方、エージェントは、受信信号から第１のノードのデバイスＩＤ１を検出した時点で、自器の通信エリア内で、所定の状況ルールが発生したことを検知する。つまり、エージェント（第１の情報処理器は、第１のノード（第２の情報処理器）が所定の位置（通信エリア内）と言う状態にあること、第１のノード（第２情報処理器）との関係がコンテキストマッチングの状態であること、自器以外に第１のノード（第２の情報処理器）が存在する状態（複数の情報処理器が存在する状態であること）を判断することができる。
【0047】
このような状況ルールが生じる可能性のあるエリアを本実施形態ではコンテキストエリアと称する。
【0048】
上記の説明で、第１の情報処理器（エージェント）は、自器のデバイスＩＤ１と第２の情報処理器（第１のノード、第２のノード）のデバイスＩＤ１、ＩＤ２をブードキャストすることを説明した。そして、第１の情報処理器（エージェント）は、さらに「所定のマッチング通知情報」（ジョブ或は通知の１つ）として、コンテキストデータ（メロンパン値引きクーポン）を送信した。その他、コメントとして単純に「マッチングしています」や、音声データを送信してもよい。
【0049】
この場合、第２の情報処理器（ノード）は、保存している自器のコンテキストデータ（或はマッチング確認用データ）と、外部から送られてきた「所定のマッチング通知情報」を比較する能力があれば、当該コンテキストデータ（メロンパン値引きクーポン）を表示部で表示することができる。スマホであれば、この比較能力及び表示能力を、ソフトエアを追加することで、十分に備えることができる。
【0050】
上記の説明は、実施形態における簡単な動作例を説明している。しかし本発明の基本システムは、これから説明するように多様な動作を行うことができる。
＜情報処理システムの基本構成と機能１＞
図２Ａは、情報処理システムの実施形態の基本となる構成例を示している。
現実のシステムではコンテキストエリアは多数存在するが、この実施形態では、２つのコンテキストエリア１０と２０が存在する例を示している。
＜情報処理システムの基本構成と機能１＞
図２Ａは、情報処理システムの実施形態の基本となる構成例を示している。
現実のシステムではコンテキストエリアは多数存在するが、この実施形態では、２つのコンテキストエリア１０と２０が存在する例を示している。
【0051】
コンテキストエリア１０は、エージェント２０００と、客が所有するノード４１００、店が所有するノード４２００がブロードキャストにより相互に通信可能なエリアである。なおエージェント２０００は、店が所有するノード４２００と一体化されている場合もある。
【0052】
コンテキストエリア２０は、エージェント３０００と、ノード４３００がブロードキャストにより相互に通信可能なエリアである。なおノード４４００は、エージェント３０００により制御可能なサイネージであり、エージェント３０００のデバイスＩＤと常に一体とに取り扱われる。あるいは、サイネージ４４００は、ブロードキャストを行うノードとして設定されてもよい。
【0053】
エージェント２０００、３０００は、例えばゲートウエイ、スマホ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣなどで実現される。エージェント２０００、３０００の設置場所は、例えばスーパーマーケット、コンビニエンスストア、デパート、オフィス、レストラン、工場内、車内、病院内、飛翔体内、道路沿い、など各種の場所が可能である。また、当該設置場所は、照明器具、テレビ、サイネージ、横断歩道の信号機、電柱、街灯などの「物」も対象となる。
【0054】
ノード４１００、４２００、ノード４３００などは、例えば、スマホ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、アクセサリー、腕時計、バンド、などの携帯可能なものが利用される。したがって、これらのノードは、異なるコンテキストエリアに移動することが可能である。ノード４４００は、エージェント３０００により制御されるサイネージであるが、ビーコン通信を行うデバイスであってもよいことは勿論である。
【0055】
上記のエージェントが移動する車載型であれば、ノードは固定場所へ配置するタイプのものとして利用される。このタイプのノードは、例えば、センサ付きのデバイスであり、橋、道路、ビル、工事現場、ロボットなどに配置される。
【0056】
また、エージェントも、複数のノードも移動するものに搭載、或は装着され、ノードがエージェントのコンテキストエリアに侵入したとき、相互の認識を行うシステムにも利用可能である。
【0057】
エージェント２０００と３０００は、それぞれコンテキスト判定部１０００と相互通信し、データの送受信を行うことができる。コンテキスト判定部１０００は、例えばサーバに設置される。なお、コンテキスト判定部１０００は、エージェント２０００又は３０００と一体化されている実施形態もある。
【0058】
コンテキスト判定部１０００は、送受信部１１００、各種のファイル部（メモリ、制御器を含む）１２００、状況マッチング処理部１３００を含む。送受信部１１００は、エージェント２０００、３０００と相互通信を行う。コンテキスト判定部１０００がサーバとしてクラウドに配置されているときは、コンテキスト判定部１０００とエージェント２０００及び３０００との間は、インターネットを介して接続される。コンテキスト判定部１０００が例えばエージェント２０００と一体である場合は、コンテキスト判定部１０００は、内部配線（半導体基板やフレキシブル基板を含む）或はケーブルにより、エージェントの入出力部と接続される。
【0059】
コンテキスト判定部１０００は、ファイル部１２００を含む。ファイル部１２００は、各種のファイル（データ、ソフトウエア、属性データなど）を格納することができ、また制御器（図示せず）も含む。ソフトウエアの中には、コンテキストマッチング処理、コンテキストグループ分け処理、読出し処理、データ取り込み処理、書き込み処理、出力処理などを行うためのプログラムが含まれ、制御器（図示せず）によりファイル及びそのデータが制御される。
【0060】
コンテキストデータは、エージェント２０００、３０００、ノード４１００－４４００などを利用するユーザにより、後で説明する登録システムからコンテキスト判定部１０００に登録される。
【0061】
このときの登録行為は、ファイル部１２００に対して、例えばノード４１００のユーザがコンテキストデータの「メロンパン好き」を登録し、ノード４２００のユーザがコンテキストデータの「メロンパン売れ残り」を登録するようなケースである。また、この登録行為により、ファイル部１２００は、エージェント２０００、３０００、ノード４１００－４４００などのデバイスＩＤも格納する。
【0062】
今、ファイル部１２００に対して、以下のような登録が行われるものとして説明する。ノード４１００のユーザ（客）とノード４２００のユーザ（店）がそれぞれ「メロンパン好き」と「メロンパン売れ残り」を登録したとする。また、エージェント２０００がアクションとして「メロンパン値引きクーポン」を発行するために「メロンパン値引きクーポン」というコンテキストを登録したとする。
【0063】
またノード４３００のユーザ（客）が「赤ワイン好き」を登録し、エージェント３０００のユーザ（この例では店とする）がアクションとして「赤ワイン広告」をコンテキストとして登録したとする。この場合ノード４４００は、例えばサイネージ（店の近くの電子看板）であるとする。
【0064】
すると、ファイル部１２００は、コンテキストマッチング処理により、コンテキスト毎にエージェントＩＤ、ノードＩＤ（以下これらをデバイスＩＤと総称する）を分類し、コンテキスト（つまりキーワード）毎にデバイスＩＤグループを形成する。このグループデータは、テーブル１２０１に格納される。
【0065】
図の例であると、メロンパングループＧ１は、エージェント２０００のデバイスＩＤ、ノード４１００のデバイスＩＤ、ノード４２００のデバイスＩＤ、デバイスＩＤグループとして形成される。
【0066】
また赤ワイングループＧ２は、エージェント３０００のデバイスＩＤ、ノード４３００のデバイスＩＤ、そしてノード４４００のデバイスＩＤによるバイスＩＤグループとして形成されている。ノード４４００のデバイスＩＤは、店としてのエージェント３０００が関連デバイス（サイネージ）として、コンテキスト判定部１０００に登録することが望ましい。
【0067】
これらのグループデータは、テーブル１２０１としてファイル部１２００に格納される。このテーブル１２０１は、例えば、更新プログラムにより、数分毎に更新処理される。または、登録されているコンテキスト内容に応じて、１日に１回乃至数回の割合で更新処理される（この更新処理回数は別途システム管理者により変更可能である）。新しい登録データは、更新が行われるまでの間は、図示しないバッファメモリに仮保存されている。
【0068】
上記のように、各ユーザによって登録された各コンテキストデータは、それぞれ所定のエージェントに紐づけされた（属する）コンテキストであり、また所定のノードに紐づけされた（属する）コンテキストであると言える。
【0069】
さらに、コンテキスト判定部１０００がサーバに設けられている場合、エージェント２０００に関連するグループデータは、予めエージェント２０００に送信され、そこのメモリに格納されていてもよい（この点は図２Ｂにて説明する）。同様に、エージェント３０００に関連するグループデータも、予めエージェント３０００に送信され、そこのメモリに格納されていてもよい（この点も図２Ｂにて説明する）。
【0070】
また、コンテキストエリア１０内の特に店のノード４２００とエージェント２０００とは、密接な関係にあり、店のノード４２００で得られる商品の販売数、販売価格などの情報は、常に対応するエージェント２０００にジョブとして通知される。同様に、コンテキストエリア２０内の特に店のノード（サイネージ）４４００とエージェント（店）３０００も、密接な関係にあり、エージェント（店）３０００は、店のノード（サイネージ）４４００の表示を直接制御可能としてもよい。勿論、エージェント３０００とノード４４００がブロードキャストによる通信を行うことで、エージェント３０００から「広告実施」の指令が、ノード４４００に与えられてもよい。
【0071】
このシステム動作により、コンテキストエリア３０内に、ノード４３００が浸入すると、ノード（サイネージ）４４００には、「赤ワインあり」などの広告宣伝が表示される。
【0072】
上記のようにエージェント２０００は、サーバ或はコンテキスト判定部１０００へジョブデータを送信するが、その他、エリア内のノード４１００に対して、値引きクーポンを送信する。またエージェント３０００は、ノード（サイネージ）４４００に適切なタイミングで、特定の客へ広告宣伝を行うことができる。
【0073】
これらのアクションは、エージェント２０００による値引きクーポン送信の事実、エージェント３０００によるサイネージの広告宣伝の事実は、サーバやコンテキスト判定部１０００に対するジョブデータ送信の対象となる。
＜「メロンパン値引きクーポン」の登録に対するシステム対応＞
「メロンパン値引きクーポン」がコンテキスト判定部１０００に登録された場合、ファイル部１２００の値引きクーポン処理用のプログラムが起動する。他の商品の「値引きクーポン」がコンテキスト判定部１０００に登録された場合も同様にクーポン処理用のプログラムが起動する。
＜「メロンパン値引きクーポン」の登録に対するシステム対応＞
「メロンパン値引きクーポン」がコンテキスト判定部１０００に登録された場合、ファイル部１２００の値引きクーポン処理用のプログラムが起動する。他の商品の「値引きクーポン」がコンテキスト判定部１０００に登録された場合も同様にクーポン処理用のプログラムが起動する。
【0074】
クーポン処理用のプログラムは、例えば「値引きクーポン」をキーワードとして起動する。そして、何処のエージェントから送信されてきた「値引きクーポン」なのかを判定し、発信元のエージェントを特定する。次に、該プログラムは、発信元のエージェントに対して、当該「値引きクーポン」に設定されている属性情報（値引き値或は値引き率、発行期限（開始年月日時間から終了年月日時間）を付加して、発信元のエージェントに送信する。
【0075】
前記「値引きクーポン」に設定されている属性情報（値引き値或は値引き率、発行期限（開始年月日時間から終了年月日時間）は、発信元のエージェント（販売店）（具体的にはエージェントを操作するユーザ）が設定する場合と、値引き対象となる商品の「卸売り店」（具体的にはコンテキスト判定部１０００を操作可能な特別なユーザ、或はシステム管理者）が設定する場合がある。システム管理者は、卸売り店からの指示に基づいて、上記の属性情報を設定する。また「値引きクーポン」の発行条件（属性情報）が、コンテキストエリア内のコンテキストマッチング関係にあるノードの数に応じて決められてもよい。つまり、ノード数が、Ｎ（設定数）以上のときは、「値引きクーポン」が発行されるのである。
【0076】
＜コンテキストエリア１０に関連するシステム動作例＞
次にコンテキストエリア１０に関連するシステム動作例を説明する。ここでは、コンテキスト判定部１０００がサーバに配置され、ファイル部１２００のテーブル１２０１が利用される例を説明する。
次にコンテキストエリア１０に関連するシステム動作例を説明する。ここでは、コンテキスト判定部１０００がサーバに配置され、ファイル部１２００のテーブル１２０１が利用される例を説明する。
【0077】
今、コンテキストエリア１０のエージェント２０００のコンテキストは、「メロンパン値引きクーポン」であり、このコンテキストがファイル部１２００に登録されている場合を説明する。
【0078】
＜コンテキストエリア１０におけるエージェント２０００の状況検知モード＞
今、コンテキストエリア１０において、エージェント２０００、ノード４１００、４２００の間のブロードキャストが行われたとする（このときの動作モードは、エージェントによる状況検知モードである）。エージェント２０００は、自器のデバイスＩＤと共にノード４１００と４２００の少なくともデバイスＩＤをコンテキスト判定部１０００のファイル部１２００宛てに送信する（このことは、状況通知２０１と称される）。
今、コンテキストエリア１０において、エージェント２０００、ノード４１００、４２００の間のブロードキャストが行われたとする（このときの動作モードは、エージェントによる状況検知モードである）。エージェント２０００は、自器のデバイスＩＤと共にノード４１００と４２００の少なくともデバイスＩＤをコンテキスト判定部１０００のファイル部１２００宛てに送信する（このことは、状況通知２０１と称される）。
【0079】
すると、コンテキスト判定部１０００の状況マッチング処理部１３００は、ファイル部１２００のデータファイル（テーブル１２０１）を参照する、そして、送られてきた複数のデバイスＩＤをデバイスＩＤグループの中から探し出す。今のコンテキストエリア１０の状況（シチュエーション）であると、エージェント２０００と、ノード４１００、ノード４２００がメロンパングループＧ１に属することが判定される。またエージェント３０００、ノード４３００が、赤ワイングループＧ２に属することが判定される。図の例では、さらに、ノード４４００のデバイスＩＤが、エージェント３０００の配下にあるサイネージとして、エージェント３０００のデバイスＩＤと一体化されている。
【0080】
上記した判定に基づいて、ファイル部１２００は、エージェント２０００に対して、メロンパングループに属するデバイスＩＤ（つまりエージェント２０００のデバイスＩＤと、ノード４１００、４２００のデバイスＩＤ）を通知する（このことは状況ルールの成立、つまりマッチング通知２０２と称される）。
【0081】
＜コンテキストエリア１０におけるエージェント２０００のノードに対するマッチング報告モード＞
次に上記のマッチング通知２０２（状況ルール成立通知と称してもよい）が行われた後、コンテキストエリア１０において、エージェント２０００、ノード４１００、４２００の間でブロードキャストが行われたとする（この動作は、エージェント２０００によるマッチング報告モードである）。
次に上記のマッチング通知２０２（状況ルール成立通知と称してもよい）が行われた後、コンテキストエリア１０において、エージェント２０００、ノード４１００、４２００の間でブロードキャストが行われたとする（この動作は、エージェント２０００によるマッチング報告モードである）。
【0082】
エージェント２０００は、データ処理部の機能に基づき、マッチング通知情報（自器のデバイスＩＤとノード４１００のデバイスＩＤ）を保持しているので、この情報を図１で説明したパラメータ部に記述してブロードキャストを実行する。すると、ノード４１００は、受信したアドバタイズメント・パケットのパラメータ部から、自器のデバイスＩＤと、エージェント２０００のデバイスＩＤと「コンテキストマッチング関連情報」を検出することができる。
【0083】
これによりノード４１００は、そのデータ処理部の機能に基づき、何等かの反応をし、ユーザの注意を引き付けることができる。例えば、エージェント２０００から、「メロンパン値引きクーポン」を自動的に受取ることができる。よって広告効果を一層高めることが可能となる。また販売促進を行うことができる。
【0084】
ノード４１００のその他の反応としては、光の点滅、音声による通知音出力、振動、或は文字表示による通知でもよい。この通知方法は、ノード４１００の種類や性能に応じて様々な形態をとることができる。アクセサリータイプの簡易型であれば、点滅或は音声通知、振動通知が可能である。
【0085】
またスマホタイプであれば、データ処理部の機能に基づき、さらに加えて文字表示、画像表示などが可能である。例えば、エージェント２０００が、パラメータ部に「メロンパン値引き」と言うコンテキストを記述し送信していた場合、ノード４１００のユーザは、「メロンパン値引き」の文字表示を見る、或は音声出力を聞く、さらにはメロン画像を見ることが可能となる。勿論、先に説明したように、「メロンパン値引きクーポン」を受取ることができる。
【0086】
またノードがコンテキストの比較機能を有する場合、エージェント２０００は、所定のマッチング通知情報を送信してもよい。所定のマッチング通知情報は、例えば「メロンパン値引き」等である。これによりノード４１００を所有するユーザは、少なくとも「メロンパン」に関して、サービスを提供するユーザが近くに存在することを容易に認識することが可能である。
【0087】
一方、エージェント２０００は、通信エリア内に「メロンパン好き」のユーザ（ノード４１００等）が何名いるかを「状況通知」と「マッチング通知」が実行されるごとに把握することができる。エージェント２０００は、この把握により「メロンパン好き」なユーザの人数と、メロンパンの販売量とのデータを収集し、人数と販売量との相関を計算することが可能となる。さらにこのことは、ダイレクト広告が実現したことであり、所定のサーバへそのジョブ情報を通知する。ジョブ情報とは、エージェントが収集したデータ及び又は先の人数と販売量との相関（比率等）の計算結果である。
【0088】
エージェント２０００は、通信エリア内のノードをカウントする場合、店としてのノード４２００のデバイスＩＤもカウントするカウントプログラムを備える。しかし、エージェント２０００は、管理管轄であるノード４２００（店）のデバイスＩＤを予め保持している。このために、エージェント２０００のカウントプログラムは、ノード４２００（店）のデバイスＩＤを差し引いてカウントし、実質的な「客」のノード数をカウントするように構成されている。
【0089】
＜コンテキストエリア２０に関連するシステム動作例＞
次にコンテキストエリア２に関連するシステム動作例を説明する。
次にコンテキストエリア２に関連するシステム動作例を説明する。
【0090】
今、コンテキストエリア２０のエージェント３０００のコンテキストは、「赤ワイン販売」であり、このコンテキストがファイル部１２００に登録されている場合を説明する。
【0091】
コンテキストエリア２０の場合、客が所有するノード４３００が「赤ワイン好き」をファイル部１２００に登録しているものとする。また、店が所有するエージェント３０００が、「赤ワイン販売」をファイル部１２００に登録しているものとする。またエージェント３０００は、関連デバイスとしてノード（サイネージ）４４００をファイル部１２００に登録しているものとする。
【0092】
この場合、赤ワイングループＧ２に、エージェント３０００、ノード４３００のデバイスＩＤ，ノード４４００のデバイスＩＤが分類されている。
【0093】
＜コンテキストエリア２０のエージェント３０００の状況検知モード＞
今、コンテキストエリア２０において、エージェント３０００、ノード４３００の間でブロードキャストが行われたとする（このときの動作はエージェントによる状況検知モードである）。エージェント３０００は、自器のデバイスＩＤと共にノード４３００の少なくともデバイスＩＤをコンテキスト判定部１０００のファイル部１２００宛てに送信する（このことは、状況通知３０１と称される）。
今、コンテキストエリア２０において、エージェント３０００、ノード４３００の間でブロードキャストが行われたとする（このときの動作はエージェントによる状況検知モードである）。エージェント３０００は、自器のデバイスＩＤと共にノード４３００の少なくともデバイスＩＤをコンテキスト判定部１０００のファイル部１２００宛てに送信する（このことは、状況通知３０１と称される）。
【0094】
すると、コンテキスト判定部１０００の状況マッチング処理部１３００は、ファイル部１２００のテーブル１２０１を参照し、送られてきた複数のデバイスＩＤをデバイスＩＤグループの中から探し出す。今の状況（シチュエーション）であると、エージェント３０００と、ノード４３００が、赤ワイングループＧ２に属することが判定される（状況ルールの判定）。
【0095】
この判定に基づいて、ファイル部１２００は、エージェント３０００に対して、赤ワイングループＧ２に属する複数のデバイスＩＤ（エージェント３０００のデバイスＩＤと、ノード４３００のデバイスＩＤ）を赤ワイングループとして通知する（このことはマッチング通知３０２と称される）。
【0096】
＜エージェント３０００によるノードに対するマッチング報告モード＞
上記のマッチング通知３０２が行われた後、コンテキストエリア２０において、エージェント３０００、ノード４３００の間でブロードキャストが行われる（この動作は、エージェント３０００によるマッチング報告モードである）。
上記のマッチング通知３０２が行われた後、コンテキストエリア２０において、エージェント３０００、ノード４３００の間でブロードキャストが行われる（この動作は、エージェント３０００によるマッチング報告モードである）。
【0097】
エージェント３０００は、マッチング通知情報（自器のデバイスＩＤとノード４３００のデバイスＩＤ）を保持しており、この情報を図１で説明したパラメータ部に記述してブロードキャストを実行する。すると、ノード４３００は、受信したアドバタイズメント・パケットのパラメータ部から、自器のデバイスＩＤと、エージェント３０００のデバイスＩＤを検出することができる。これにより、ノード４３００は、何等かの反応をし、ユーザの注意を引き付けることができる。この注意の引き付け方法も、さきのノード４４００を説明したときの方法と同様な方法である。
【0098】
さらにこの場合、エージェント３０００は、オートマチックアクションとして、ノード（サイネージ）４４００に対して、「赤ワイン販売」を表示するように通知する。これにより、ノード４３００を所有する客は、近くのサイネージをみて、「赤ワインを販売する店」が近くにあることを高い確率で認識することができる。これにより広告効果を一層高めることが可能となる。また販売促進を行うことができる。
【0099】
なお、エージェント３０００が、「メロンパンの販売」もしており、さらに他のノード（図示せず）が「メロンパン好き」というコンテキストを登録している場合は、さらに第２のマッチング通知情報を処理する。このような場合、これら複数のマッチング通知情報を、同時あるいは時間差を以てブロードキャストすることができる。
【0100】
その他、エージェント３０００は、ジョブ情報として、コンテキスト判定部１０００のファイル部１２００、或は、別途指定されている指定サーバへ「赤ワインの宣伝広告」を行ったことをジョブとして通知する。ここで、コンテキスト判定部１０００或は指定サーバに登録されている「赤ワイン販売業者」の課金テーブルの課金データを、更新して課金処理を行ってもよい。このときの課金は、ダイレクトコマーシャル成功報酬である。
【0101】
＜マッチング通知情報の先行配備＞
上記の説明では、コンテキスト判定部１０００がサーバに設けられており、コンテキスト判定部１０００がテーブル１２０１（コンテキスト別に、エージェントＩＤ及びノードＩＤをグループ分けしたテーブル）を有することを説明した。そしてエージェントは、状況通知２０１、３０１を行い、コンテキスト判定部１０００からマッチング通知２０２、３０２を受取るものとして説明した。
上記の説明では、コンテキスト判定部１０００がサーバに設けられており、コンテキスト判定部１０００がテーブル１２０１（コンテキスト別に、エージェントＩＤ及びノードＩＤをグループ分けしたテーブル）を有することを説明した。そしてエージェントは、状況通知２０１、３０１を行い、コンテキスト判定部１０００からマッチング通知２０２、３０２を受取るものとして説明した。
【0102】
しかし、エージェント２０００、３０００に対するマッチング通知２０２、３０２の情報は、各エージェント２０００、３０００にそれぞれ先行して配備されてもよい。この方式であると、サーバ（コンテキスト判定部）の負担を軽減できるとともに、エージェントによるノードに対するマッチング報告及び値引きクーポンの送信が素早くなる。
【0103】
図２Ｂは、エージェントに、関連するマッチング通知情報を先行配備する実施形態を示している。図２Ａと同一部分には、同一符号を付して、重複した説明は省略する。この実施形態は、エージェント２０００、３０００、ノード４１００、４２００、４３００が、それぞれ自器のデバイスＩＤと、コンテキストをコンテキスト判定部１０００のファイル部１２００に登録した後の処理に特徴を備える。
【0104】
コンテキスト判定部１０００のファイル部１２００は、先に説明したように、テーブル１２０１を作成する。コンテキストマッチング処理を行い、コンテキスト（キーワード）毎にエージェント及びノードのデバイスＩＤを分類する。
【0105】
状況マッチング処理部１３００は、エージェントから状況通知２０１、３０１がコンテキスト判定部１０００に送られてきたときに、その返信動作として、エージェント２０００やエージェント３０００に、マッチング通知２０２、２０３を行う、ことを先に説明した。
【0106】
しかし、状況マッチング処理部１３００は、テーブル１２０１の更新処理が実行された後、エージェント２０００、３０００に対して、マッチング通知を先行して行ってもよい。即ち、
エージェント２０００に対しては、エージェント２０００が登録したコンテキストのグループに属するノードのデバイスＩＤと、エージェント２０００のデバイスＩＤを含むサブテーブル２００１を先行配備する。図の例であると、メロンパングループＧ１に属するデバイスＩＤ（４１００のＩＤ、４２００のＩＤ、２０００のＩＤ）である。
エージェント２０００に対しては、エージェント２０００が登録したコンテキストのグループに属するノードのデバイスＩＤと、エージェント２０００のデバイスＩＤを含むサブテーブル２００１を先行配備する。図の例であると、メロンパングループＧ１に属するデバイスＩＤ（４１００のＩＤ、４２００のＩＤ、２０００のＩＤ）である。
【0107】
またエージェント３０００に対しては、エージェント３０００が登録しているコンテキストのグループに属するノードのデバイスＩＤと、エージェント３０００のデバイスＩＤを含むサブテーブル３００１を先行配備する。図の例であると、赤ワイングループＧ２に属するデバイスＩＤであって、ノード４３００のＩＤ，４４００のＩＤとエージェント３０００のＩＤである。
【0108】
上記のようにテーブル２００１が、エージェント２０００に先行配備（或は先行手配）され、テーブル３００１がエージェント３０００に先行配備(或は先行手配)される。この状態において、ブロードキャストが行われた場合、各エージェント２０００、３０００は、即座にマッチング報告を行うことができるとともに「値引きクーポン」をすぐに送信することが可能である。またエージェント３０００は、サイネージであるノード４４００にすぐに広告宣伝を行わせることができる。
【0109】
つまり、エージェント２０００の動作を説明すると、次のようになる。エージェント２０００は、ブロードキャストを行うときに、自動的にメロンパングループＧ１のノードのデバイスＩＤと自器のデバイスＩＤとを、図１で説明したパラメータ部に記述してブロードキャストを実行する。すると、この場合は、ノード４１００がコンテキストエリア２０に存在するので、このノード４１００が何等かの反応を得ることができる。またノード４１００は、自器のデバイスＩＤをブロードキャストする。
【0110】
するとエージェント２０００は、ノード４１００がコンテキストエリアに存在することを認識するので、即座に、「メロンパン値引きクーポン」をノード４１００向けに送信することができる。
【0111】
ここで、もしノード４１００の利用者（つまり客）が、モード４２００（つまり店）でクーポンを使って、メロンパンを購入したとする。この販売情報（ジョブ情報或は報告情報）は、ノード４２００からエージェント２０００に送信される。またエージェント２００は、販売情報をコンテキスト判定部１０００、或はメロンパンの卸売業者、或は製造会社のサーバへ送信する。メロンパンの卸売業者、或は、製造会社は、販売状況に応じて、値引きクーポンの発行部数、発行期限、発行時間帯などの調整をコンテキスト判定部１０００やサーバの運営者或はシステム管理者に依頼することができる。よって、本システムでは、クーポンの発行が、商品販売数、時間帯、日時に応じて、即座に実施可能或は変更である。
【0112】
エージェント３０００は、ブロードキャストを行うときに、自動的に赤ワイングループＧ２のノードのデバイスＩＤと自器のデバイスＩＤとを、図１で説明したパラメータ部に記述してブロードキャストを実行する。すると、この場合は、ノード４３００がコンテキストエリア２０に存在するので、このノード４３００が何等かの反応をする。またノード４３００は、自器のデバイスＩＤをブロードキャストする。
【0113】
するとエージェント３０００は、ノード４３００がコンテキストエリアに存在することを認識するので、即座に、「赤ワインあり」のメッセージをノード（サイネージ）４４００向けに送信することができる。これにより、ノード（サイネージ）４４００においては、すぐに「赤ワイン販売」の音声出力あるいは表示が得られる。
【0114】
なお、コンテキストエリア１０から、「赤ワイン好き」を登録しているノード（図示せず）がコンテキストエリア２０に移動してきたときは、当該ノードは、エージェント３０００からのサービスを即座に受けることができる。
【0115】
上記のように、エージェント２０００や３０００は、コンテキストエリア内で検知したノードに対して、オートマチックアクションとしてコンテキストマッチングする各ノードに「値引きクーポン」を送信するために、ＣＭ効果が高く、直接的でＣＭ効率がよい。
【0116】
図２Ｃは、エージェント２０００、ノード４１００、ノード４５０１、ノード４５０３が、同時に通信エリア（コンテキストエリア）に存在し、ブロードキャストを行った場合の、動作の一例を示すフローチャートである。
【0117】
ここで、エージェント２０００は、「メロンパン値引きクーポン」を所有し、発行可能であるとする。またエージェント２０００は、例えば「桃の販売」をコンテキスト判定部１０００に登録しているものとする。
【0118】
そして、ノード４１００は、「メロンパン好き」をコンテキスト判定部１０００に登録しているものとする。ノード４５０１は、クーポン対象とは異なる「桃が好物」をコンテキスト判定部１０００に登録しているものとする。さらにノード４５０２は、「ハンバーガー大好き」をコンテキスト判定部１０００に登録しているものとする。
【0119】
いま、エージェント２０００、ノード４１００、ノード４５０１、ノード４５０３が、同時に通信エリア（コンテキストエリア）で、ブロードキャストを行ったとする（Ｓ０１）。エージェント２０００は、受信したデバイスＩＤ（ノード４１００、４５０１、４５０３の各デバイスＩＤ）をチェックし、コンテキストマッチング関係にあるデバイスＩＤを特定する（Ｓ０２）。
【0120】
そしてエージェント２０００は、ノード４１００のデバイスＩＤが、「メロンパングループＧ１」であることを判定し、さらに、当該デバイスＩＤ（ノード４１００）は、クーポン配布対象であることを判定する。そこで、エージェント２０００は、ノード４１００のデバイスＩＤとクーポンデータ「メロンパン値引きクーポン」をペアとしたデータを、図１で示したパラメータ部に記述して送信する。具体的には、ノード４１００のデバイスＩＤと「メロンパン値引きクーポン」をデータ部に記述して送信する（Ｓ０３）。これにより、ノード４１００は、「メロンパン値引きクーポン」を取得することができる（Ｓ０５）。
【0121】
また、エージェント２０００は、ノード４５０１のデバイスＩＤが、「桃のループＧＸ」であることを判定する。この場合は、エージェント２０００は、ノード４５０１に対して、ノード４５０１のデバイスＩＤと「桃の販売」をペアとしたデータを、図１で示したデータ部に記述して送信する。これにより、ノード４５０１は、「桃の販売」という「コンテキストマッチング関連情報」を取得することができる（Ｓ０６）。
【0122】
さらにまた、エージェント２０００は、ノード４５０２のデバイスＩＤが、サービス対象ではないことを判定する。この場合、ノード４５０２に関するデータは、図１で示したパラメータ部に記述することはない。このため、ノード４５０２は、エージェント２０００から、何ら「コンテキストマッチング関連情報」を取得することはない（Ｓ０７）。そして、ブロードキャスト（Ｓ０１）に基づく処理が終了する（Ｓ１１）。
【0123】
上記したように本実施形態は、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器（エージェント）と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器（ノード４１００）と、を備える。
【0124】
そして前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備えることを特徴とする。この実施形態は情報処理システム又は本システムに係る方法、又は本システムに係る装置、又は本システムに係る処理プログラムにも及ぶ。
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備えることを特徴とする。この実施形態は情報処理システム又は本システムに係る方法、又は本システムに係る装置、又は本システムに係る処理プログラムにも及ぶ。
【0125】
図２Ａ、図２Ｂのシステムでは、エージェント２０００は、コンテキストマッチング状態にあるノードを検出した後、当該ノードに対してさらに次のブロードキャストにおいて、クーポンなどを自動配信した。したがって本システムは、商流の可能性の高い人に、正確に適切な営業を実行すると言える。上記の例であると、「メロンパン好き」と言う消費者に対して確実に「メロンパン値引きクーポン」と言うサービスを提供できることになる。さらに加えて、営業効果が強化される。
【0126】
しかし、上記の「値引きクーポン」は、エージェントに限らず、サーバからノードに送信されてもよい。つまり、サーバは、複数のエージェントの状態（例えばコンテキストマッチングが実現した数）を把握することができる。したがって「値引きクーポン」の発行をサーバが管理することで、サーバは、「値引きクーポン」の全体の発行数、或は各エージェントに対する割り当てを管理できる。
【0127】
上記したように値引きクーポンのノード向けの送信方法は、エージェントがブロードキャストで送信する方法であるが、さらにサーバがインターネットなどのネットワークを介して、エージェント若しくはノードに送信する方法も可能である。
【0128】
図２Ｄは、サーバ７Ａがインターネットなどのネットワークを介して、エージェント若しくはノードに送信する方法の一例を示している。
【0129】
サーバ７Ａは、コンテキスト判定部１０００、アプリケーションインターフェース（ＡＰＩ）７Ａ１、販売実績管理器７Ａ２、クーポン管理器７Ａ３を有する。ＡＰＩ７Ａ１は、コンテキスト判定部１０００と販売実績管理部７Ａ２とのインタフェースとして機能している。
【0130】
販売実績管理器７Ａ２は、コンテキスト判定部１０００から、ＡＰＩ７Ａ１を介して、複数のエージェント２０００、３０００からのＪＯＢ情報（商品の販売数、販売量、売上データなど）を受取り、販売実績を把握し、クーポンの発行数、クーポンを配布すべきエージェント、配布時間帯などの属性データ（図１で示した制御コード、データ部の記述内容に対応する）を決定する。この決定に応じて、クーポン管理器７Ａ３は、ＡＰＩ７Ａ１、コンテキスト判定部１０００を介して、例えばノード４１００にクーポンを送信することができる。勿論、この場合、サーバ７Ａは、各エージェント或はノードのデバイスＩＤ、メールアドレスなどを把握している。各エージェント、或は、ノードは、自器のコンテキスト（メロンパン好き）をコンテキスト判定部１０００に登録するときに、デバイスＩＤやメールアドレス等を登録している。この登録データがＡＰＩを介して間接的にクーポン管理器７Ａ２により利用される。
【0131】
サーバ７Ａは、クーポン管理器７Ａ３によりクーポンの発行を許可するエージェントが決まった場合、このエージェントに対して「値引きクーポン」を予め直接ネットワークを介して送信してもよい。またコンテキスト判定部１０００がコンテキストマッチングを判断した際に、対応するノードに対して、直接「値引きクーポン」をネットワークを介して送信してもよい。
【0132】
＜基本システムを円滑に稼働させるための設定システム＞
上記したように、本システムは、「サービス情報を提供する側のユーザ」から、「サービス情報を欲しい側のユーザ」に対して、状況のルール成立を起点として、適切にサービス情報を提供する。この仕組みを多様に実現するために、さらに次のような設定システムが本システムに導入されることで一層の価値を発揮する。
上記したように、本システムは、「サービス情報を提供する側のユーザ」から、「サービス情報を欲しい側のユーザ」に対して、状況のルール成立を起点として、適切にサービス情報を提供する。この仕組みを多様に実現するために、さらに次のような設定システムが本システムに導入されることで一層の価値を発揮する。
【0133】
図３は、基本システムを円滑に稼働させるための各種の設定システムを示している。
なお以後の図においても先に説明した図のブロックと同一部分は、先に説明した図の符号と同じ符号を付して重複した説明は省略する。
＜コンテキストスキーム及びルール設定システム＞
上記した「状況のルール」を設定するためには、コンテキストスキーム及びルール設定部５０００が利用される。コンテキストスキーム及びルール設定部５０００は、例えば本システムを利用して、情報サービスの形態（種類など）を考案するルール設定者５５００と、ユーザ（事業主、サービス運営者、或はサービス仕掛人等）により主として活用される。
なお以後の図においても先に説明した図のブロックと同一部分は、先に説明した図の符号と同じ符号を付して重複した説明は省略する。
＜コンテキストスキーム及びルール設定システム＞
上記した「状況のルール」を設定するためには、コンテキストスキーム及びルール設定部５０００が利用される。コンテキストスキーム及びルール設定部５０００は、例えば本システムを利用して、情報サービスの形態（種類など）を考案するルール設定者５５００と、ユーザ（事業主、サービス運営者、或はサービス仕掛人等）により主として活用される。
【0134】
ルール設定者５５００は、ユーザ（事業主、サービス運営者、自治体或はサービス仕掛人等）と相談しながら、「情報を提供する側」及び「情報を欲しい側」のユーザが「情報を提供する」、「情報を受取る」ための仕組みを設計する。仕組みは、情報処理手順と称してもよい。
【0135】
上記の事業主、サービス運営者、自治体、或サービス仕掛人等としては、各種商品の販売店、或は子供を持つ親（Parent-Teacher Association （ＰＴＡ））、或は地方自治体などの公的機関、或は学校の同窓会の委員、或は企業などである、またルール設定者５５００自身であってもよい。
【0136】
・販売店は、商品の販売を促進したいと考える、商品としては、食品、雑貨、衣料品、工業製品、部品、住宅などの各種の販売商品、証券、不動産なども含む、
・また子供を持つ親は、子供の通学の安全をチェックしたいと考える、
・また公的機関は、老人の行動範囲などをチェックしたいと考える、
・また学校の同窓会の委員は、同窓会のメンバを探したいと考える、
・またビルの管理者は、ビルの省電力化を図りたいと考える、
・さらに、大規模のスーパーマーケットの管理者、イベント会場の運営者などは、顧客を効率的に誘導するために、顧客の動線設定を行いたいと考える。
・また子供を持つ親は、子供の通学の安全をチェックしたいと考える、
・また公的機関は、老人の行動範囲などをチェックしたいと考える、
・また学校の同窓会の委員は、同窓会のメンバを探したいと考える、
・またビルの管理者は、ビルの省電力化を図りたいと考える、
・さらに、大規模のスーパーマーケットの管理者、イベント会場の運営者などは、顧客を効率的に誘導するために、顧客の動線設定を行いたいと考える。
【0137】
これらのサービスは、例えば、「売れ残り商品の販売サービス」或は「商品販売促進サービス」、「子供の見守りサービス」、「老人の見守りサービス」、「出会い検知サービス」、「ビルの省電力管理サービス」、「顧客の動線設定サービス」、「待ち合わせサービス」、「趣味・クラブ・同窓会などのマッチング情報提供サービス」と称される。
【0138】
ルール設定者５５００は、上記したような各サービスに好適であってユーザが利用しやすい「ルール実行プログラム」とプログラムが処理するための情報を入力する「情報入力テンプレート」を設計する。
【0139】
ルールの設定内容は、本システムを利用するユーザによって異なるし、ルールの設定内容に応じてルール設定者も異なる場合がある。例えば「商品販売促進サービス」は、店舗によって販売促進方法（ルール設定状況を構築する要素）が異なるかもしれないし、また、取り扱う商品（日常品、貴金属、乗用車など）によって販売促進方法（ルール設定状況を構築する要素）が異なるかもしれない。
【0140】
理解を容易にするために、「売れ残り商品の販売サービス」の利用例について説明する。
「売れ残り商品の販売サービス」の仕組みは、ルール設定者５５００によりコンテキストスキーム及びルール設定部５０００で設計される。「売れ残り商品の販売サービス」を運営するためには、「ルール実行プログラム」と「情報入力用のテンプレート」とが必要である。
「売れ残り商品の販売サービス」の仕組みは、ルール設定者５５００によりコンテキストスキーム及びルール設定部５０００で設計される。「売れ残り商品の販売サービス」を運営するためには、「ルール実行プログラム」と「情報入力用のテンプレート」とが必要である。
【0141】
状況の設定を依頼するユーザつまりルール設定者５５００は、例えばコンビニエンスストア、スーパーマーケット、デパートの経営者、さらにまた、ＰＴＡ（Parent-Teacher Association）、或は地方自治体などの公的機関、或は学校の同窓会の委員、或は企業などである。
【0142】
ルール設定者５５００は、自身のエージェントを用意する。複数のノードは、来店する顧客、見守りが必要な子供、老人など、不特定多数である。
【0143】
ルール設定者５５００は、複数のノードとエージェント間にどのような状態（配置関係或は位置関係、ノードとエージェントの相互の検知方法、検出内容）を予定しているのかを設計する。例えば先のエージェント２０００は、その通信エリア（コンテキストエリア）１０を設定できること、この通信エリアでノードを検知可能とすること、などを設計する。ノードを検知可能とするために、どのようなコンテキストのマッチングを予定しているのかも取り決めを行う。先の例では、コンテキストが「メロンパン売れ残り」であり、「キーワードを「メロンパン」とするなどである。
【0144】
しかし、スーパーマーケット、デパートでは商品数が多数になる。また、高額な貴金属の販売店、車の販売店などでは、来店者の入場制限が必要な場合がる。このような状況において、ユーザにマッチング通知をどのように行うかなどの方法を工夫する必要がある。
【0145】
そのために、商品名をテンプレートに入力するための工夫（例えば商品名をデータベースから自動取り込みする、マニュアルで入力するなど）の、話し合いや取り決めが行われる。またコンテキスト判定部１０００からエージェントに対してマッチング通知を行う場合、通知条件を設定可能とするなどの取り決めが行われる。通知条件とは、例えば、通知頻度、所定の通知先は排除するなどである。勿論、先に説明したように「値引きクーポン」の発行指示どのような場合に行うか、発行指示をどのような日時で行うか、その変更修正を可能とするか、などの取り決めを行う。
【0146】
上記したように、コンテキストスキーム及びルール設定部５０００では、ユーザ（エージェント所有者）の業種に精通しているルール設定者が、ルール実行プログラムと情報入力用のテンプレートを作成する。そして、ユーザは、希望するテンプレートを選択し、必要な設定データを入力できるように、システムが設計される。
【0147】
そのために、ルール設定者は、テンプレート内にサービス情報（コンテキスト）に付帯する属性情報（図１で説明した制御コード、データ部などである）を入力する欄を設計してもよい。
【0148】
属性情報としては、さらにコンテキスト「メロンパン売れ残り」の広告時間帯、コンテキストの有効期間、などの情報がある。またデータ部の長さ（コンテキストの長さ）、言語の種類などの指定情報がある。さらにコンテキスト判定部は、コンテキストの分類処理以外に、各種の目的で活用されてもよい。この場合、その目的を指定する情報が属性情報に追加される。例えばコンテキストが、パスワードにより暗号化されているか否かを示す情報がある。さらにまた、後述するシステム管理者９５００に委託する事項を入力する欄を属性情報に設けてもよい。委託する事項としては、例えば広告（マッチング関連情報）の送信頻度などである。
【0149】
コンテキストスキーム及びルール設定部５０００で作成された、「ルール実行プログラム」と「情報入力テンプレート」は、ルール設定データ５０１として、データファイル部１２００に格納される。また、ルール設定データ５０１は、ルール設定データ５０２として、予めエージェント２０００に送信されていてもよい。
【0150】
上記したように本実施形態では、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器とを備える。前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。
【0151】
そして前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。さらに前記コンテキスト判定部に接続可能であって、前記マッチング関係となるルールを設定することでユーザサービス形態を設計するためのルール設定システムであって、前記ルールを設定する要素として、少なくともコンテキスト、デバイスＩＤの入力部を用意している、ルール設定部を備える。
【0152】
＜情報登録システム６０００＞
上記したように各種のテンプレートがコンテキストスキーム及びルール設定部５０００において作成される。情報登録システム６０００は、ルール設定者が設計したテンプレートやソフトウエアを利用して種々のデータを登録するためのシステムである。この情報登録システム６０００は、「情報を欲しい側」のユーザ６５００が、具体的なコンテキストデータや自身の情報処理器のデバイスＩＤを先の入力情報テンプレートを用いて入力するのに利用される。
上記したように各種のテンプレートがコンテキストスキーム及びルール設定部５０００において作成される。情報登録システム６０００は、ルール設定者が設計したテンプレートやソフトウエアを利用して種々のデータを登録するためのシステムである。この情報登録システム６０００は、「情報を欲しい側」のユーザ６５００が、具体的なコンテキストデータや自身の情報処理器のデバイスＩＤを先の入力情報テンプレートを用いて入力するのに利用される。
【0153】
「情報を欲しい側のユーザ」は、情報（プロファイル情報或はプロフ情報と称してもよい）を登録する。先の例であると、ノード４１００のユーザが「メロンパン好き」を登録することである。また、ノード４３００のユーザが「赤ワイン好き」を登録することである。またノード４２００のユーザが「メロンパン売れ残り」を登録することである。これらの情報は、プロフ情報６０１としてデータファイル部１２００に登録される。
【0154】
また情報登録システム６０００は、自動マーケティング運営者のために以下のように利用されてもよい。
【0155】
先のコンテキストエリア１０において、「メロンパン」に関するコンテキストマッチングが成立した場合、エージェント２０００は、ジョブ情報をコンテキスト判定部１０００に通知する。また、ジョブ情報には、「所定の状況」が成立した後、一定時間内に販売されたメロンパンの販売数も含まれる。
【0156】
そこで、自動マーケティング運営者もまた、エージェント２０００と同様に「メロンパン好き」というノード数をカウントできる「調査エージェント」をコンテキスト判定部１０００に用意する。そして、この「調査エージェント」は、多数のコンビニのエージェントから、メロンパン卸売り業者に通知されるメロンパン販売数のデータを受信する。そして、当日或は数日間の平均販売数や、時間帯に応じて、自動マーケティング運営者（「調査エージェント」）は、各コンビニに対して、メロンパンの値引き率の通知、或は「メロンパン値引きクーポン」の発行指示、発行数を通知することも可能である。
【0157】
なお自動マーケティング運営者とメロンパン卸売り業者は同じであってもよい。このように「調査エージェント」は、メロンパンの販売状況に応じて、各コンビニのエージェントに対して、クーポンの発行指示を行うことが可能である。
【0158】
或は、「調査エージェント」は、コンビニの特別な商品（例えば弁当、生鮮食品など）に対する値引き率を時間帯に応じて可変するように指示を出すことも可能である。このような指示は、さらにエージェントを介してコンビニの店頭や店内に配置されているサイネージ制御システムに入力されてもよい。
【0159】
プロフ情報６０１には、「サービス情報を欲しい側のユーザ」が使用する情報処理器のデバイスＩＤが含まれる。そしてテンプレートに記述されるプロフ情報には、欲しい情報に関わるコンテキストが含まれる。コンテキストとしては、例えば、先の「メロンパン好き」、「赤ワイン好き」などである。
【0160】
さらにプロフ情報６０１の属性情報として、「サービス情報を欲しているユーザ（情報処理器）」からの登録情報であることを示す属性情報が付属する。尚、属性情報としては種々の属性情報があるので、それぞれ属性情報の種類に応じて、ヘッダーとして予め取り決められたコードや記号が存在する（スキーマ情報とも称される）。
【0161】
また属性情報として、条件のデータ、マッチング制限データ等があってもよい。条件のデータとしては、コンテキストの有効期間などがある。
【0162】
マッチング制限データとしては、本情報処理器と他の情報処理器間で、コンテキストマッチングが成立したとしても、特別な状態が存在した場合は、マッチングを不成立として取り扱うデータである。例えば、マッチング制限データは、所定のデバイスＩＤ（特にエージェント）、或は所定のライバル店などの名称がコンテキストに付随していた場合、データファイル部１２００のグループ分けプログラムが、マッチング不成立として判断することができるデータである。
【0163】
例えば先の図２Ａ、図２Ｂの例であれば、エージェント２０００、３０００がライバル店であったとする。このような場合、エージェント２０００と３０００の店が、コンテキストデータをファイル部１２００に登録する場合、ライバル店の情報を登録してもよい。
【0164】
エージェント２０００と３０００の店が、同じ商品（例えばメロンパン）を取り扱っていた場合、メロンパングループＧ１にエージェント２０００と３０００のデバイスＩＤが存在することになる。この場合、ライバル店の情報がコンテキストデータに含まれると、コンテキスト判定部１０００は、メロンパングループＧ１を、エージェント２０００用のメロンパングループＧ１－１と、エージェント３０００用のメロンパングループＧ１－２に分けて管理する。
【0165】
そして、コンテキスト判定部１０００が、エージェント２０００にマッチング通知を行うときは、メロンパングループＧ１－１に含まれるデバイスＩＤを送信し、エージェント３０００にマッチング通知を行うときは、メロンパングループＧ１－２に含まれるデバイスＩＤを送信する。
【0166】
これにより、１つのグループ内のデバイスＩＤを１つのエージェントに送信する場合、他のエージェントのデバイスＩＤが同居しないようにグループ内のデバイスＩＤを送信する。これにより、各エージェントは不要な処理工程を無くすることができる。
【0167】
なお、本システムが図２Ｂで説明したように、予めエージェント２０００に対してテーブル２００１を先行配備する場合も同様である。
【0168】
上記したように本実施形態は、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器とを備える。前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。
【0169】
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、また、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、また、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。
【0170】
さらに、前記マッチング関係の具体的判断要素となる、前記第１の情報処理器、前記第２の情報処理器のそれぞれのデバイスＩＤ、それぞれのコンテキストデータ、を含むプロフィール情報を事前設定するためのプロフィール情報入力システムを、前記コンテキスト判定部に対して接続可能である。
【0171】
＜提供情報入力システム７０００＞
提供情報入力システム７０００は、「サービス情報を提供する側のユーザ」が、テンプレートを利用して、「提供情報」をコンテキスト判定部１０００に入力するためのシステムである。この提供情報入力システム７０００における入力用プログラムやテンプレートも、状況を設定したルール設定者が作成している。
提供情報入力システム７０００は、「サービス情報を提供する側のユーザ」が、テンプレートを利用して、「提供情報」をコンテキスト判定部１０００に入力するためのシステムである。この提供情報入力システム７０００における入力用プログラムやテンプレートも、状況を設定したルール設定者が作成している。
【0172】
情報を提供する側のユーザ７５００が本システムのコンテキスト判定部１０００に入力する入力情報としては、「情報を提供する側のユーザ」が使用している情報提供用情報処理器（エージェント或はノード）のデバイスＩＤと、少なくともコンテキストがある。コンテキストとしては、例えば先のエージェント２０００が「メロンパン値引きクーポン」を登録することである。またノード４２００のユーザが「メロンパン売れ残り」を登録することである。またエージェント３０００が、サイネージ用の広告データ（例えば赤ワインあり）を登録することである。
【0173】
また、この入力情報には、情報を提供する側のユーザ７５００からの情報であることがコンテキスト判定部１０００で判断できるように、属性情報（予め取り決められたコード）が付属してもよい。
【0174】
情報提供用情報処理器の属性情報には、マッチング制限データが付帯してもよい。情報提供用情報処理器との間でコンテキストマッチングが成立する第３の情報処理器が存在したとする。しかしながら、第３の情報処理器の属性情報の内容によっては、マッチング不成立として最終判定する（サービス情報を提供しない）ほうが好ましい場合がある。例えば、提供する情報が「アルコール類の値引き販売」であった場合、第３の情報処理器のユーザの属性情報に１４歳以下、或は２０歳以下の年齢データが記述され、コンテキストとして「消毒用アルコール」が記述されているような場合がある。このような場合は、コンテキスト判定部１０００の状況マッチング処理部１３００は、第３の情報処理器と情報提供用情報処理器とのマッチングは不成立として判定する。
【0175】
また属性情報としては、「提供情報」の送信先のエージェントを特定する場合、或は逆に「提供情報」を送信しないエージェントを特定する場合などに利用される。例えば、図２Ａ、図２Ｂの例では、エージェント２０００が「メロンパン値引きクーポン」を登録するとき、属性情報の中に「提供情報」を送信しないエージェントとして「エージェント３０００」を特定することがある。属性情報の記述方法は例えばエージェント３０００の名称、電話番号、住所などが利用されてもよい。
【0176】
なお状況を提供する側のユーザとしては、先に説明したルール設定者５５００自身もなり得る場合がある。
【0177】
上記したように本実施形態によると、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器とを備える。そして前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。
【0178】
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。
【0179】
さらに、前記コンテキスト判定部に接続可能であって、前記マッチング関係となる情報処理器に対して与える前記結果データは、相手に提供すべきコンテキスト内容のデータであることを事前入力するための提供情報入力システムを有する。
【0180】
＜一般ユーザ入力システム４５００＞
一般ユーザ入力システム４５００は、エージェントやゲートウエイが設定している状況により、検知、或は非検知されるノードを所有するユーザが利用するシステムである。このユーザ入力システム４５００において使用される入力用プログラムやテンプレートも、状況を設定したルール設定者が作成する。
一般ユーザ入力システム４５００は、エージェントやゲートウエイが設定している状況により、検知、或は非検知されるノードを所有するユーザが利用するシステムである。このユーザ入力システム４５００において使用される入力用プログラムやテンプレートも、状況を設定したルール設定者が作成する。
【0181】
ユーザ入力システム４５００は、先に説明したノード４１００、４２００、４３００が、それぞれデバイスＩＤとともに、例えば、先の「メロンパン好き」、「メロンパン売れ残り」、「赤ワイン好き」「赤ワイン販売、メロンパン販売」などのコンテキストをファイル部１２００に登録するためのシステムである。ユーザ入力システム４５００は、一般利用者が、いつでもコンテキストデータの登録を行えるように設計されている。また、必要に応じて、コンテキストデータの削除を行うことも可能である。
【0182】
このユーザ入力システム４５００を利用するユーザは、テンプレートを利用して、ルール設定者が構築している、情報登録システム６０００を介してコンテキストを入力する、または、先の提供情報入力システム７０００を介してコンテキストを入力するユーザである。入力情報としては、ユーザが利用する情報処理器のデバイスＩＤとコンテキストがある。さらに各種の属性情報が入力されてもよい。
【0183】
＜マッチング通知を行う場合の送信管理＞
さらに本システムには、システム管理者９５００により、マッチング通知２０２、２０３や状況通知が行われる場合の送信管理システム９０００が設けられている。送信管理システム９０００は、送受信部１１００を制御する。送受信部１１００は、マッチング通知２０２、２０３を行う場合、送信管理システム９０００の制御に基づき、アクション送信が実行される。アクション送信とは、例えば送信動作の排他的制御、送信動作の重複排除、優先度による送信、送信頻度の管理に基づく送信のことである。
さらに本システムには、システム管理者９５００により、マッチング通知２０２、２０３や状況通知が行われる場合の送信管理システム９０００が設けられている。送信管理システム９０００は、送受信部１１００を制御する。送受信部１１００は、マッチング通知２０２、２０３を行う場合、送信管理システム９０００の制御に基づき、アクション送信が実行される。アクション送信とは、例えば送信動作の排他的制御、送信動作の重複排除、優先度による送信、送信頻度の管理に基づく送信のことである。
【0184】
排他的制御について：
送受信部１１００が、多数のエージェントやゲートウエイにマッチング通知を行う場合、基本的には、順番を設定して均等な頻度でマッチング通知を行う仕組みである。しかし、エージェントやゲートウエイによって、「時間帯」や「日」によって、マッチング通知を頻繁に欲しいものと、さほど頻繁でなくてもよいものが存在する。このような場合、マッチング通知が頻繁でなくてもよいエージェントやゲートウエイに対するマッチング通知を排他的に制御するというものである。例えば、店が定休日の場合は、マッチング通知は不要である場合がある。また午後のみ営業する店は、午前中のマッチング通知は、不要若しくは最小数の設定でよい。そこで、各エージェント若しくはルール設定者は、システム管理者９５００と話し合いにより、上記の排他的制御に関する内容を取り決めする。
送受信部１１００が、多数のエージェントやゲートウエイにマッチング通知を行う場合、基本的には、順番を設定して均等な頻度でマッチング通知を行う仕組みである。しかし、エージェントやゲートウエイによって、「時間帯」や「日」によって、マッチング通知を頻繁に欲しいものと、さほど頻繁でなくてもよいものが存在する。このような場合、マッチング通知が頻繁でなくてもよいエージェントやゲートウエイに対するマッチング通知を排他的に制御するというものである。例えば、店が定休日の場合は、マッチング通知は不要である場合がある。また午後のみ営業する店は、午前中のマッチング通知は、不要若しくは最小数の設定でよい。そこで、各エージェント若しくはルール設定者は、システム管理者９５００と話し合いにより、上記の排他的制御に関する内容を取り決めする。
【0185】
重複排除による制御について：
例えば同じコンテキストエリアに、同様なエージェントが複数（例えば２つ）存在することがある。すると、２つのエージェントからコンテキスト判定部１０００には、同じノードのデバイスＩＤが２か所から通知される。そして、コンテキスト判定部１０００は、同じノードのデバイスＩＤを、２つのエージェントに送信することになる。このような場合は、同じノードのデバイスＩＤを、２つのエージェントに時間をおいて交互に送信して、重複送信を避ける制御が重複排除による制御である。
例えば同じコンテキストエリアに、同様なエージェントが複数（例えば２つ）存在することがある。すると、２つのエージェントからコンテキスト判定部１０００には、同じノードのデバイスＩＤが２か所から通知される。そして、コンテキスト判定部１０００は、同じノードのデバイスＩＤを、２つのエージェントに送信することになる。このような場合は、同じノードのデバイスＩＤを、２つのエージェントに時間をおいて交互に送信して、重複送信を避ける制御が重複排除による制御である。
【0186】
優先度による制御について：
例えば、複数のエージェントがコンテキスト判定部１０００に接続されている場合、エージェントにより、規模が異なる場合がある。またエージェントにより、サービス内容の違いや規模の違いある、例えば救急病院のエージェント（或はゲートウエイ）、公的機関のエージェント（或はゲートウエイ）、スーパーマーケットのエージェント、コンビニのエージェントなどがある。またシーズンによって、活動が忙しく（ビジーに）なるエージェントや、活動が暇（フリー）となるエージェントがある。このような場合、マッチング通知が即時性を要するエージェントや忙しいエージェントに対して優先的に送信されるようになっている。
例えば、複数のエージェントがコンテキスト判定部１０００に接続されている場合、エージェントにより、規模が異なる場合がある。またエージェントにより、サービス内容の違いや規模の違いある、例えば救急病院のエージェント（或はゲートウエイ）、公的機関のエージェント（或はゲートウエイ）、スーパーマーケットのエージェント、コンビニのエージェントなどがある。またシーズンによって、活動が忙しく（ビジーに）なるエージェントや、活動が暇（フリー）となるエージェントがある。このような場合、マッチング通知が即時性を要するエージェントや忙しいエージェントに対して優先的に送信されるようになっている。
【0187】
送信頻度管理による制御について：
コンテキスト判定部１０００は、基本的には、順番を設定して均等な頻度で、各エージェント（又はゲートウエイ）にマッチング通知を行う仕組みである。このために一定の期間内での、各エージェント（又はゲートウエイ）へのマッチング通知回数が均等となるように、調整する。
コンテキスト判定部１０００は、基本的には、順番を設定して均等な頻度で、各エージェント（又はゲートウエイ）にマッチング通知を行う仕組みである。このために一定の期間内での、各エージェント（又はゲートウエイ）へのマッチング通知回数が均等となるように、調整する。
【0188】
上記したように実施形態によると、コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器とを備える。前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備える。
【0189】
前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える。
【0190】
さらに、前記コンテキスト判定部に接続可能であって、前記コンテキスト関連情報の送り方として、送信頻度、排他的制御、重複排除のいずれかを行う送信管理情報を前記コンテキスト判定部に入力する送信管理システムを有する。
＜エージェントとして利用される機器の例＞
図４Ａ、図４Ｂ、図４Ｃは、エージェントとして利用される情報処理器の外観を示し、図４Ｄは、当該情報処理器の内部機能ブロックを示している。しかし必ずしもここで例示されるものに限定されるものではない。
＜エージェントとして利用される機器の例＞
図４Ａ、図４Ｂ、図４Ｃは、エージェントとして利用される情報処理器の外観を示し、図４Ｄは、当該情報処理器の内部機能ブロックを示している。しかし必ずしもここで例示されるものに限定されるものではない。
【0191】
図４Ａは、スマホがエージェント２０００或は３０００として利用される例である。このスマホは、ビーコン通信部２３１と、電話回線やインターネットに接続するための基地局接続部２３２を有する。図４Ｂは、パーソナルコンピュータ（ＰＣ）がエージェント２０００或は３０００として利用される例である。このＰＣは、ビーコン通信部２３３と、インターネットに接続するためのネットワーク接続部２３４を備える。図４Ｃは、エージェント２０００或は３０００として専用に作成された情報処理器である。この情報処理器は、ビーコン通信部２３５と、ネットワーク接続部２３６を備える。
【0192】
図４Ｄは、上記のエージェント２０００或は３０００に必要な機能ブロックを示している。これらは、ノード４１００－４３００として利用されてもよいことは勿論である。またサイネージに組み込まれてもよいことは勿論である。
【0193】
機能ブロックは、送受信部２３００と、ビーコン通信処理器２３０１と、無線又はネットワーク通信処理器２３０２を備える。ビーコン通信が行われるときはビーコン通信処理器２３０１とデータ処理器２３０４がスイッチ２３０３により接続され、無線通信或はネットワーク通信が行われるときは、無線又はネットワーク通信処理器２３０２とデータ処理器２３０４がスイッチ２３０３により接続される。
【0194】
状況データのメモリ２３０５は、図２Ｂで説明したテーブル２００１やテーブル３００１のデータや、各種の属性データを格納する。したがって、ビーコン通信が行われるときは、データ処理器２３０４は、メモリ２３０５のデータを読み出して、アドバタイズメント・パケットのパラメータ部に送信データとして記述する。制御部２３０６は、上記の送受信部２３００、ビーコン通信処理器２３０１、無線又はネットワーク通信処理器２３０２、スイッチ２３０３、データ処理器２３０４及びメモリ２３０５を総合的に制御する。したがって制御部２３０６は、動作モードに応じて、各種アプリケーションを選択的に利用する。また表示器２３０７、電源２３０８もまた装備されている。
【0195】
上記した、状況データのメモリ２３０５は、書き換え可能な領域を有するメモリ（ＲＡＭ）と、予めコンテキストマッチング用の読出し専用メモリ（ＲＯＭ）を含んでもよい。ＲＯＭとしては、ノード２０００、３０００の利用価値を高めるために、各種のコンテキストデータを記述した専用メモリであり、着脱可能であってもよい。例えば、コンビニやデパートで使用される販売商品は多数であり、予め商品名やコンテキストが記述されたメモリが利用されてもよい。後述するノードの状況データのメモリにあっても上記と同様なことが言える。
【0196】
＜ノードとして利用される機器の他の例＞
図５Ａ、図５Ｂ、図５Ｃ、図５Ｄ、図５Ｅは、ノードとして利用される機器（情報処理器）の例を外観形状で示している。しかし必ずしもここで例示するもの限定されるわけではない。
図５Ａ、図５Ｂ、図５Ｃ、図５Ｄ、図５Ｅは、ノードとして利用される機器（情報処理器）の例を外観形状で示している。しかし必ずしもここで例示するもの限定されるわけではない。
【0197】
図５Ａは、スマホ４５１０の例であり、ビーコン通信部４５１１と、電話回線やインターネットに接続するための基地局接続部４５１２を有する。図５Ｂは、腕時計４５２０が利用された例であり、この腕時計４５２０にビーコン通信部４５２１が内蔵されている。図５Ｃは、ペンダント４５３０が利用された例であり、このペンダント４５３０にビーコン通信部４５３１が内蔵されている。図５Ｄは、腕輪４５４０が利用された例であり、この腕輪４５４０にビーコン通信部４５４１が装着されている。図５Ｅは、めがね４５５０が利用された例であり、このメガネ４５５０にビーコン通信部４５５１が装着されている。
【0198】
＜ノードの機能の例＞
図６Ａ、図６Ｂ、図６Ｃ、図６Ｄは、ノード（又はエージェントとしても利用可能）の各種の機能ブロックの例を示している。これらの情報処理器は、コンテキスト判定部１０００に登録する際、エージェントとして登録することも可能である。
図６Ａ、図６Ｂ、図６Ｃ、図６Ｄは、ノード（又はエージェントとしても利用可能）の各種の機能ブロックの例を示している。これらの情報処理器は、コンテキスト判定部１０００に登録する際、エージェントとして登録することも可能である。
【0199】
以下、簡単にノードとして説明する。ノードの機能ブロックは、シンプルなものから複雑なものまで各種のタイプが利用される。図６Ａのノード４Ａ００の機能ブロックは、スマホと同様な機能ブロックであり、また図４Ｄで説明したエージェントと同様な構成である。即ち、
送受信部４Ａ１０と、ビーコン通信処理器４Ａ１１と、無線又はネットワーク通信処理器４Ａ１２を備える。スイッチ４Ａ１３は、データ処理器４Ａ１４を、ビーコン通信処理器４Ａ１１と無線又はネットワーク通信処理器４Ａ１２に対して動作モード（ビーコン通信モード又は無線通信或はネットワーク通信モード）に応じて選択的に接続する。
送受信部４Ａ１０と、ビーコン通信処理器４Ａ１１と、無線又はネットワーク通信処理器４Ａ１２を備える。スイッチ４Ａ１３は、データ処理器４Ａ１４を、ビーコン通信処理器４Ａ１１と無線又はネットワーク通信処理器４Ａ１２に対して動作モード（ビーコン通信モード又は無線通信或はネットワーク通信モード）に応じて選択的に接続する。
【0200】
状況データのメモリ４Ａ１５は、自器のデバイスＩＤ、自器で設定しているコンテキスト、属性データなどを格納する。データ処理器４Ａ１４は、メモリ４Ａ１５のデータを読み出して、アドバタイズメント・パケットのパラメータ部に該データを記述することができる。制御部４Ａ１６は、送受信部４Ａ１０、ビーコン通信処理器４Ａ１１、無線又はネットワーク通信処理器４Ａ１２、スイッチ４Ａ１３、データ処理器４Ａ１４及びメモリ４Ａ１５を総合的に制御する。したがって制御部４Ａ１６は、動作モードに応じて、各種アプリケーションを選択的に利用する。また表示器４Ａ０７、電源４Ａ０８もまた装備されている。
【0201】
このノード４Ａ００は、アプリケーションを追加することで、自律的にコンテキストマッチング処理及び状況マッチング処理を実行することが可能となる。このため図２Ａ，図２Ｂで説明したコンテキスト判定部１０００の機能と同様な機能を小規模で持つことができる。
【0202】
図６Ｂのノード４Ｂ００の機能ブロックは、図６Ａのノード４Ａ００から状況データのメモリ４Ａ１５、表示器４Ａ０７が除かれたものであり、他の機能ブロックは、ノード４Ａ００と同じである。このノード４Ｂ００は、専用の中継器として利用することが可能である。例えばビーコン通信で取得したデータ（例えばデバイスＩＤ）をインターネット経由でサーバ或はエージェントに送信する機器として利用可能である。また逆にインターネット経由で取得したデータを、ビーコン通信により、近辺の通信エリアに存在する他のノード或はエージェントに通知することが可能である。
【0203】
図６Ｃのノード４Ｃ００の機能ブロックは、図６Ａのノード４Ａ００から状況データのメモリ４Ａ１５、表示器４Ａ０７、無線又はネットワーク通信処理器４Ａ１２が除かれ、センサ４Ａ０９が付加されたものであり、他の機能ブロックは、ノード４Ａ００と同じである。このノード４Ｃ００は、ビーコン通信だけを行うものであり、例えばセンサ４Ａ０９の検知信号レベルを通知する場合に利用可能である。センサの種類としては、照度センサ、温度センサ、湿度センサ、ガスセンサ、臭気センサ、ジャイロ、高度センサ、ＧＰＳ、気圧センサ、圧力センサ、水漏れセンサ、粉塵検出センサ、ＣＯ２センサ、人感センサ、イメージセンサなどがある。センサは、これらに限定されるものではない。
【0204】
図６Ｄのノード４Ｄ００の機能ブロックは、図６Ａのノード４Ａ００から表示器４Ａ０７、無線又はネットワーク通信処理器４Ａ１２が除かれ、他の機能ブロックは、ノード４Ａ００と同じである。このノード４Ｄ００は、ビーコン通信を行ったとき、簡単なコンテキストマッチング処理を行うことが可能である。その結果は、表示器４Ａ１５によりユーザに通知することが可能である。コンテキストマッチング処理を大規模で行う事は困難であるが、簡単なキーワードに関して処理することは可能である。このノード４Ｄ００表示器もＬＥＤの点滅など簡単な表示を行う場合に有効である。
【0205】
上記した各種ノードにおいても音声出力機能が設けられてもよことは勿論である。
【0206】
＜コンビニ、スーパーマーケット、デパート、各種店舗でのシステム利用例＞
図７Ａは、コンビニエンスストア３Ａが、商品の販売促進システムに本発明の実施形態を適用した例を示している。コンビニエンスストア３Ａのオーナは、エージェント３０００を導入している。エージェント３０００は、コンテキストエリア２０を有する。エージェント３０００は、コンビニ３Ａのノードとしても利用される。そして、コンテキスト判定部１０００に「赤ワイン販売」「メロンパン販売」を登録している。
図７Ａは、コンビニエンスストア３Ａが、商品の販売促進システムに本発明の実施形態を適用した例を示している。コンビニエンスストア３Ａのオーナは、エージェント３０００を導入している。エージェント３０００は、コンテキストエリア２０を有する。エージェント３０００は、コンビニ３Ａのノードとしても利用される。そして、コンテキスト判定部１０００に「赤ワイン販売」「メロンパン販売」を登録している。
【0207】
顧客３Ｂは、ノード４Ａ００を有し、コンテキストとして「赤ワイン好き」を登録している。また顧客３Ｃは、ノード４Ｄ００を有し、コンテキストとして「メロンパン好き」を登録している。
【0208】
図７Ｂは、販売促進システムの動作例を時間Ｔの経過に沿って示している。顧客３Ｂ、３Ｃがコンテキストエリア２０内に侵入し、ブロードキャストが行われたとする（ＳＡ１）。すると、エージェント３０００、ノード４Ａ００、ノード４Ｄ００は、コンテキストマッチング状態となり、それぞれコンテキストマッチング状態を検知する。これにより、顧客３Ｂと顧客３Ｃは、それぞれ自身が興味を持つ商品が、近くで販売されていることを認識できる（ＳＡ２、ＳＡ３）。つまり顧客３Ｂは、近くに「赤ワインの販売」を行っている店があることを認識し、顧客３Ｃは、近くに「メロンパンの販売」を行っている店があることを認識する。
【0209】
一方、エージェント３０００は、ブロードキャストを実行したきに、ノード４Ａ００、ノード４Ｄ００のデバイスＩＤを取得する。これによりエージェント３０００は、販売促進を行っている商品に興味をもつ顧客３Ｂ、３Ｃに対して、直接的に広告を行ったことを認識できる（ＳＡ４）。そして、エージェント３０００は、取得したデバイスＩＤをカウントし、デバイス数を認識する（ＳＡ５）。このカウントを行う場合は、所定時間以内で既に受信しているデバイスＩＤの数は除外する。これは重複してデバイスＩＤがカウントされるのを避けるためである。さらにエージェント３０００は、カウントしたデバイスＩＤの数をサービス運営者のサーバ５Ａへ送信する。
【0210】
サービス運営者のサーバ５Ａは、「広告成立」の報酬として、エージェント３０００に対する課金用のデータファイルを更新する（ＳＡ６）。
【0211】
また、エージェント３０００は、ノード４Ｄ００のユーザが「メロンパンが好き」であることを認識するとともに、エージェント３０００が「赤ワイン値引きクーポン」を発行できることを認識している場合がある。この場合、「メロンパン値引きクーポン」を、ノード４Ｄ００向けに送信する（ＳＡ７）。これにより、ノード４Ｄは、値引きクーポンを取得することができる（ＳＡ８）。
【0212】
また、エージェント３０００は、ノード４Ａ００が「赤ワイン好き」であることを認識する。ここで、近くにサイネージがある場合は、サイネージに向けて「赤ワイン販売」などの広告を行うことができる（ＳＡ９，ＳＡ１０）。
【0213】
＜見守りサービス１＞
図８Ａは、サービス運営者（例えば地域自治体、或はParent-Teacher Association (PTA
)或は警備会社）が、見守りサービスシステムに本発明の実施形態を適用した例を示している。子供６Ａの通学見守りサービスシステムを例に説明する。
図８Ａは、サービス運営者（例えば地域自治体、或はParent-Teacher Association (PTA
)或は警備会社）が、見守りサービスシステムに本発明の実施形態を適用した例を示している。子供６Ａの通学見守りサービスシステムを例に説明する。
【0214】
子供６Ａ１は、スマホ４５１０を有する。子供６Ａ１の通学路の途中の例えば横断歩道の信号機６Ｂ１に、この場合、エージェント４Ｂ００が配置されている。このエージェント４Ｂ００は、子供６Ａ１のスマホ４５１０が通信エリア内にある時、ブロードキャストにより、スマホ４５１０のデバイスＩＤを取得する。エージェント４Ｂ００は，取得したデバイスＩＤを、サービス運営者のサーバ７Ａにネットワークを介して送信する。
【0215】
サーバ７Ａは、見守り利用者のためにデータ保存用のテーブル７Ａ１０を有し、このテーブル７Ａ１０に各利用者６Ａ１，６Ａ２，６Ａ３・・・の通過位置データ６Ｔ１，６Ｔ２，６Ｔ３・・・をそれぞれ記録する。通過位置データは、例えば信号機６Ｂ１の所在地（番地、町名など）と利用者（図の場合は利用者６Ａ１）が通過した日時データを含む。信号機６Ｂ１の所在地は、信号機６Ｂ１に設置されているエージェント４Ｂ００がファイル部に登録されるときに、エージェント４Ｂ００のデバイスＩＤとともに同時に登録されている。
【0216】
サーバ７Ａの利用者６Ａ１のデータをチェックできるユーザは、予めサービス運営者と契約を行っている例えば両親６Ｃ１、６Ｄ１である。両親６Ｃ１、６Ｄ１は、子供６Ａ１の通過位置がいつもと違うような場合、スマホ４５１１を利用して直接子供６Ａ１のスマホ４５１０に電話をかけて、状況を確認することができる。
【0217】
またサーバ７Ａには、利用者の通過位置がいつもと違うような場合、或は、利用者の通過時間がいつもと大きくずれているような場合、両親６Ｃ１、６Ｄ１のスマホ４５１１へ通知するサービスアプリが設けられていてもよい。
【0218】
図８Ｂは、上記した見守りシステムの一部の動作例を時間Ｔの経過に沿って示している。子供６Ａ１が信号機６Ｂ１の近くを通るとき、スマホ４５１０とエージェント４Ｂ００との間でブロードキャストが行われる（ＳＢ１）。エージェント６Ｂ１は、予め登録されているスマホ４５１０のデバイスＩＤを検知する。そしてエージェント６Ｂ１は、サーバ７Ａに対して、スマホ４５１０のデバイスＩＤと、信号機６Ｂ１の番号或は住所などの通過位置のデータを送信する（ＳＢ３）。サーバ７Ａは、テーブル７Ａ１０の利用者６Ａ１（子供）のデータ記録部６Ｔ１に、通過位置データを記録する（ＳＢ４）。
【0219】
両親６Ｃ１，６Ｄ１は、任意の時間にスマホ４５１１を使用し、サーバ７Ａをアクセスし、通過位置データ６Ｔ１を確認することができる（ＳＢ５）。また、サーバ７Ａは、通過位置データ６Ｔ１のチェックプログラムを有し、受け取った通過位置がいつもと違う位置のときは、両親６Ｃ１，６Ｄ１のスマホ４５１１に警告通知を行う（ＳＢ６，ＳＢ７）。
【0220】
これにより両親６Ｃ１，６Ｄ１は、スマホ４５１１を使用して子供６Ａ１のスマホ４５１０を呼び出し、状況報告を求めることが可能である（ＳＢ９）。
【0221】
＜見守りサービス２＞
図９Ａは、サービス運営者（地域自治体）が、老人見守り及び案内システムを本発明の実施形態として実現した場合の例を示している。図９Ｂは、老人見守り及び案内システムの動作例を時間Ｔの経過に沿って示している。図９Ａと図９Ｂを参照して説明する。
図９Ａは、サービス運営者（地域自治体）が、老人見守り及び案内システムを本発明の実施形態として実現した場合の例を示している。図９Ｂは、老人見守り及び案内システムの動作例を時間Ｔの経過に沿って示している。図９Ａと図９Ｂを参照して説明する。
【0222】
老人６Ｅのための散歩道６Ｈの途中には、上りの階段６Ｆ、下りの階段６Ｇがある。そこで、地域自治体は、老人６Ｅが、上りの階段６Ｆと、下りの階段６Ｇに近づいたとき、老人６Ｅのスマホを制御し音声により注意を呼び掛けることを実現している。
【0223】
老人６Ｅの散歩道６Ｈには、さらに電柱２Ａ０１、２Ａ０２、２Ａ０３がある。電柱２Ａ０１、２Ａ０２、２Ａ０３には、それぞれエージェント２Ａ１１、２Ａ１２、２Ａ１３が配備されている。図では１つのエージェントの構成例を代表で示している。エージェント２Ａ１１、２Ａ１２、２Ａ１３は地域自治体が配備する。なおこのエージェント２Ａ１１、２Ａ１２、２Ａ１３は、街中では外観が看板やサイネージ、或は道路標識であってもよい。
【0224】
サーバ７Ａは、ファイル部に案内システムのためのデータベース（テーブル）７Ａ１３を備える。テーブル７Ａ１３は、地域自治体が登録したエージェント２Ａ１１、２Ａ１２、２Ａ１３のデバイスＩＤを同一グループで管理している。そして、老人６Ｅのスマホ４５１５のデバイスＩＤは、地域自治体が登録したエージェント２Ａ１１、２Ａ１２、２Ａ１３のデバイスＩＤと同じグループに登録されている。この登録も地域自治体が行う。
【0225】
今、老人６Ｅが、上り階段６Ｆに差し掛かったとする。するとエージェント２Ａ１１と老人６Ｅのスマホ４５１５が同じコンテキストエリアに入る。エージェント２Ａ１１とスマホ４５１５のブロードキャストにより、エージェント２Ａ１１は、スマホ４５１５（老人６Ｅ）を認識する（図９ＢのＳＣ１）。また、エージェント２Ａ１１は、次のブロードキャストにより、スマホ４５１５に向けてメッセージ音声の出力制御を行う（図９ＢのＳＣ２）。メッセージ音声は、例えば、「上り階段があります、十分気をつけてください、お手伝いが欲しい場合は、スマホの♯のボタンを押してください」である。
【0226】
またエージェント２Ａ１１は、サーバ７Ａに、スマホ４５１５がエージェント２Ａ１１の位置を通過したという通過位置データを送信し、サーバ７Ａは通過位置データを記録部に記録する（図９ＢのＳＣ３、ＳＣ５）。この時の処理方法は、図８Ａで説明した方法と同じである。
【0227】
次に、老人６Ｅが移動し、エージェント２Ａ１２に近くに到着したとする。エージェント２Ａ１２とスマホ４５１５のブロードキャストにより、エージェント２Ａ１２は、スマホ４５１５（老人６Ｅ）を認識する（図９ＢのＳＣ６）。エージェント２Ａ１１は、サーバ７Ａに、スマホ４５１５がエージェント２Ａ１２の位置を通過したという通過位置データを送信し、サーバ７Ａは通過位置データを記録部に記録する（図９ＢのＳＣ７、ＳＣ８）。
【0228】
さらに老人６Ｅが移動し、下り階段６Ｇに差し掛かったとする。するとエージェント２Ａ１３と老人６Ｅのスマホ４５１５が同じコンテキストエリアに入る。エージェント２Ａ１３とスマホ４５１５のブロードキャストにより、エージェント２Ａ１３は、スマホ４５１５（老人６Ｅ）を認識する（図９ＢのＳＣ９）。また、エージェント２Ａ１３は、次のブロードキャストにより、スマホ４５１５に向けてメッセージ音声の出力制御を行う（図９ＢのＳＣ１０）。メッセージ音声は、例えば、「下り階段があります、十分気をつけてください、お手伝いが欲しい場合は、スマホの♯のボタンを押してください」である。エージェント２Ａ１１，２Ａ１２，２Ａ１３の構成は、図４Ｄで示したエージェント２０００と同じであり、さらにスピーカ２３０１を有し、このエージェント２Ａ１１、２Ａ１２、２Ａ１３が案内音声を出力してもよい。
【0229】
またエージェント２Ａ１３は、サーバ７Ａに、スマホ４５１５がエージェント２Ａ１３の位置を通過したという通過位置データを送信し、サーバ７Ａは通過位置データを記録部に記録する（図９ＢのＳＣ１１、ＳＣ１３）。
【0230】
上記のシステムは老人の見守り及び散歩の誘導を行うことができる。サーバ７Ａに記録された通過位置データは、自治体或は家族がスマホからアクセスしてチェックすることが可能である。この見守り及び案内システムは、老人或はその家族が自治体にシステム利用届を行うことで利用可能である。
【0231】
上記のシステムは、道案内システムとしても転用することが容易である。スマホ４５１５（老人６Ｅ）が、エージェント２Ａ１１、２Ａ１２、２Ａ１３に差し掛かるごとに、老人６Ｅに対して次の目印や方角を音声で教える方法が可能である。
＜出会い系サービス＞
図１０Ａは、出会い検知システムに本発明の実施形態が適用された場合のイメージ例を示す説明図である。図１０Ｂは、出会い系検知システムにデバイスＩＤを登録する場合の手順を示す説明図である。また図１０Ｃは、腕時計４５２０とペンダント４５３０とが同一のコンテキストエリアに位置し、ブロードキャストを行った場合の動作説明図である。
＜出会い系サービス＞
図１０Ａは、出会い検知システムに本発明の実施形態が適用された場合のイメージ例を示す説明図である。図１０Ｂは、出会い系検知システムにデバイスＩＤを登録する場合の手順を示す説明図である。また図１０Ｃは、腕時計４５２０とペンダント４５３０とが同一のコンテキストエリアに位置し、ブロードキャストを行った場合の動作説明図である。
【0232】
【0233】
このノード４Ａ００とノード４Ｄ００は、ブロードキャストにより、受信したコンテキストと自身のコンテキストとを比較する機能を備えている。状況データメモリ４Ａ１５内には、自身のコンテキストを記憶している。このコンテキストをキャッチ用コンテキストと称する。このキャッチ用コンテキストは、１種類のみならず複数であってもよい。例えば、ＡＡＡ学校卒業、趣味スキー、趣味テニスなど比較的短いキャッチ用コンテキストが望ましい。またこれらの要件には、論理ＡＮＤ（同時成立）と論理ＯＲ（いずれかが成立）を設定することが可能である。
【0234】
ノード４Ａ００とノード４Ｄ００は、ブロードキャストにより、互いのコンテキストを受信すると、受信コンテキストと自身のキャッチ用コンテキストを比較することができる。この比較は、データ処理器４Ａ１４が制御部４Ａ１６の制御のもとで実行する。そして、受信コンテキストとキャッチ用コンテキストとが一致した場合、何等かの表示或は音声出力が、腕時計４５２０、ペンダント４５３０から得られる。
【0235】
上記のノード４Ａ００とノード４Ｄ００に対して、ユーザがキャッチ用コンテキストを登録する場合は、以下のように手続きをおこなう。まず、ユーザは、スマホ或はパーソナルコンピュータを用いて所定のサーバをアクセスする。またユーザは、スマホ或はパーソナルコンピュータを自身のノード４Ａ００或はノード４Ｄ００を近距離無線通信により相互通信可能状態に設定する。
【0236】
そして、図１０Ｂに示すように、所定のサーバからスマホ或はパーソナルコンピュータに登録用のソフトウエアをダウンロードする。つまりスマホ或はパーソナルコンピュータが、出会い系サービステンプレートを読み出し、登録用ソフトウエアを展開することができる。このとき、ノードは、スマホ或はパーソナルコンピュータと近距離無線により、リンクし、相互通信可能となっている。スマホ或はパーソナルコンピュータによりアクセスされたサーバには、これから出会い系サービスのユーザが情報を入力することが設定され、サーバは、出会い系サービステンプレートの管理を開始する（ＳＥ０，ＳＥ１）。
【0237】
ユーザは、テンプレートの空欄に対して、使用するノード４Ａ００或はノード４Ｄ００のデバイスＩＤと、出会いマッチング用（或はキャッチ用）のコンテキストデータを入力し登録する（ＳＥ２、ＳＥ３）。このとき、複数（例えば2つ）のコンテキストデータが入力された場合、「いずれか一方が成立すればよい」、「または両方の成立が必要」、という論理条件の属性入力欄があってもよい。また、コンテキストに対して属性情報として、排他的条件データが付加されてもよい（ＳＥ４）。さらには、コンテキストデータの期限制限データが同じく属性情報として付加されてもよい。期限制限データとしては、例えばマッチングを受け付ける期間や時間が指定されてもよいし、終了日時が指定されてもよい（ＳＥ５）。ユーザは、入力データを確認し（ＳＥ６）操作を終了する。するとテンプレートに入力したデータ（コンテキストデータ及び属性データ）が、サーバに登録されるとともに、直接的にユーザが操作したスマホ或はパーソナルコンピュータから無線により腕時計４５２０或はペンダント４５３０に送信され、ノード４Ａ００或は４Ｄ００のメモリ４Ａ１５に記録される。
【0238】
従って、ノード４Ａ００或は４Ｄ００の制御部４Ａ１６は、スマホ或はパーソナルコンピュータとリンクして相互に通信するアプリケーションを備えている。このアプリケーションが対応する通信は、近距離無線通信、ビーコン通信などいずれでもよい。
【0239】
次に、腕時計４５２０のノード４Ａ００と、ペンダント４５３０のノード４Ｄ００とが、同一のコンテキストエリアの同時に遭遇したとする。すると
図１０Ｃに示すように、ノード４Ａ００と、ノード４Ｄ００とがブロードキャストし（ＳＦ０）、お互いを検知することになる（ＳＦ１、ＳＦ１１）。そしてお互いは、保持しているコンテキストデータと、受信したコンテキストデータとを比較し、マッチングが成立しているかどうかを判定する。
図１０Ｃに示すように、ノード４Ａ００と、ノード４Ｄ００とがブロードキャストし（ＳＦ０）、お互いを検知することになる（ＳＦ１、ＳＦ１１）。そしてお互いは、保持しているコンテキストデータと、受信したコンテキストデータとを比較し、マッチングが成立しているかどうかを判定する。
【0240】
しかし、ノード４Ａ００とノード４Ｄ００は、それぞれ受信したコンテキストデータに、マッチング排他データが含まれているかどうかを判定する（ＳＦ２、ＳＦ１２）。受信したコンテキストデータに、マッチング排他データが含まれている場合は、以後の処理・受信を一定期間中止する。しかし、受信したコンテキストデータに、マッチング排他データが含まれていない場合は、ユーザに表示又は音声による通知を行う（ＳＦ３、ＳＦ１３）。
【0241】
上記の出会い系サービスは、例えば「同窓会の委員が同窓会のメンバと遭遇したい」、あるいは「ある趣味を持つ人が、同じ趣味を持つ人と遭遇したい」、など各種の利用方法が可能である。
【0242】
また特別なケースとして、パスワードを用いた圧縮処理が施されている場合もある。パスワードが、第１のユーザの第１のデバイスと、第２のユーザの第２のデバイス間で利用される場合、ユーザはそれぞれのデバイスに予めパスワードを登録することができる。これにより、第１のデバイスと第２のデバイス間の通信による受信データは、それぞれのデバイスにおいて自動的に解凍される。
【0243】
図１１は、ビル管理システムに本発明に係る実施形態が導入された例を示す。８Ａは例えば１階（１Ｆ）から４階（４Ｆ）までの会社のビルを示している。社員は、２階から４階までは、エレベータ８Ａ１を利用していくことができる。受付カウンタ８Ａ２には、エージェント３０００が配置されており、このエージェント３０００は、会社員に割り当てられたスマホ４５８１（社員カードでもよい）のＩＤをコンテキスト判定部に記憶しているものとする。
【0244】
今、社員６Ｈが出勤し、受付カウンタ８Ａ２において、自分のスマホ４５８１を受取り、電源をオンしたとする。社員６Ｈは、３Ｆの部門に在籍するものとする。
【0245】
すると、スマホ４５８１とエージェント３０００がビーコン信号をブロードキャストする。エージェント３０００は、社員６Ｈが出勤したものと判定し、社員６Ｈが在籍する部門の照明３ＬＤ１～３ＬＤ６をオン制御する。また、空調装置３ＡＣ１，３ＡＣ２に制御信号を送り、空調動作をスタートさせる。一方、スマホ４５８１は、その表示器の画面に、社員名、行き先の階３Ｆを表示する。
【0246】
社員がエレベータ８Ａ１に乗ると、エレベータ８Ａ１は、エージェント３０００から通知を受けたエレベータ制御装置８Ａ３により制御され、３Ｆまで移動して停止する。
【0247】
上記の説明は、受付カウンタ８Ａ２にエージェント３０００が配置されているとしたが、エレベータ３０００内に配置されていてもよい。
【0248】
なお、社員が帰宅するときは、スマホ４５８１の電源をオフし、受付カウンタ８Ａ２の所定の位置に返却する。これにより、社員の出退勤が、エージェント３０００によりチェック可能となっている。つまりエージェント３０００は、スマホ４５１８の電源のオン、オフの時間管理を行うことができるからである。
【0249】
上記のビル管理システムであると、必要個所の照明や空調装置の電源オンオフを行うので無駄な消費電力の消費を抑制できる。また、社員の出退勤の管理が可能である。
【0250】
図１２Ａは、空間環境検知システムに本発明の実施形態が適用された例を示す説明図である。
【0251】
例えばＣｏ２を検知するセンサ４Ａ０９を有するノード４Ｃ００が使用された例である。このノード４Ｃ００は、例えば、バス１１Ａ内、電車１２Ａ内、オフィス１３Ａ、飛行機１４Ａ内、バー１５Ａ内、病室１６Ａ内、レストラン１７Ａ内などがある。
【0252】
スマホ４５１９を有するユーザが、バス１１Ａ内、電車１２Ａ内、オフィス１３Ａ、飛行機１４Ａ内、バー１５Ａ内、病室１６Ａ内、レストラン１７Ａ内などに侵入した場合、ノード４Ｃ００とスマホ４５１９間でブロードキャストを行う。この通信により、ユーザは、ノード４Ｃ００から各環境のＣｏ２の状態報告（サービス情報）を受けることができる。つまり、スマホ４５１９は、ノード４Ｃ００からＣｏ２検知信号を受け取ることができる。Ｃｏ２検知信号が、基準値以下であれば、スマホ４５１９は表示部に例えば「充分な換気が保たれています」などの表示を行う。しかし、Ｃｏ２検知信号が、基準値に満たない場合は、スマホ４５１９は表示部に「換気を行ってください」などの表示を行う。
【0253】
上記はＣｏ２センサを有するノードの使用例を示したが、使用する環境と目的に応じて、各種のセンサが利用される。センサの種類としては、照度センサ、温度センサ、湿度センサ、ガスセンサ、臭気センサ、ジャイロ、高度センサ、ＧＰＳ、気圧センサ、圧力センサ、水漏れセンサ、粉塵検出センサがあるが、これらに限定されるものではない。
【0254】
図１２Ｂは、ノード４Ｃ００の他の構成例を示している。このノード４Ｃ００は、複数のセンサ４ＡＳ１、４ＡＳ２、４ＡＳ３の検出値を受取ることができる。センサ４ＡＳ１、４ＡＳ２、４ＡＳ３の検出値の受け取り方法は、無線、或は有線のいずれでもよい。無線方式のセンサの場合、車内や機内に予め装備されているセンサが利用される。
【0255】
センサ４ＡＳ１、４ＡＳ２、４ＡＳ３の種類は、ノード４Ｃ００の使用環境に応じて、各種のセンサが選択的に使用される。
【0256】
このようなセンサをもつノード４Ｃ００は、車内や機内の位置（ＧＰＳ）と、温度、気圧などを同時に取得し、スマホ１５１９に通知することが可能である。
【0257】
図１３は、イベント会場、ショッピングモールの入り口などでの待ち合わせ用システム、グループ点検システム、顧客動線システム等に本発明の実施形態が用いられた例を示す説明図である。観客は、会場の入り口付近で待ち合わせを行う事が多い。また、団体旅行客は、グループの点検を行うこともある。また個人では会場が広いために独自に予約席まで行くのに大変苦労する。
【0258】
２０Ａは、各種のイベントが行われるイベント会場である。待ち合わせ用システムは、例えば同じ趣味を持つ人、同じファンクラブの会員の人、などが利用可能である。
【0259】
【0260】
またイベント会場２０Ａの正面入り口付近には、案内ロボット２１Ａが配置される。この案内ロボット２１Ａは、エージェント３０００を内蔵しており、ビーコン通信部２３５と、ネットワーク通信部２３６を備える。
【0261】
また案内ロボット２１Ａのネットワーク通信部２３６は、基地局２２Ａを介して所定のサーバ２３Ａと通信が可能である。
【0262】
サーバ２３Ａは、送受信部２３Ａ１、制御部２３Ａ２、イベント会場の少なくとも予約データファイル２３Ａ３を有する。予約データファイル２３Ａ３は、スマホ４５１０、４５１１、４５１５を所有する各ユーザの予約データを記録しているものとする。予約データは、例えばユーザのスマホのデバイスＩＤ、スマホの電話番号、予約席データ、予約日、ユーザの年齢などが含まれていてもよい。
【0263】
今、各ユーザがロボット２１Ａに近づくと、各ユーザが所有するスマホ４５１０、４５１１、４５１５と、ロボット２１Ａに内蔵されているエージェント３０００との間でブロードキャストが実行される。
【0264】
すると、エージェント３０００は、各スマホ４５１０、４５１１、４５１５のデバイスＩＤを、サーバ２３Ａにネットワークを介して送信する。
【0265】
ここで、サーバ２３Ａは、各スマホ４５１０、４５１１、４５１５のイベント会場２０Ａの予約データを有するものとする。このために、サーバ２３Ａは、予約データからスマホ４５１０、４５１１、４５１５の電話番号と、予約日、予約席データを検出する。
【0266】
またサーバ２３Ａは、予約席データを検出した場合、イベント会場入り口（ロボット２１Ａの位置）から、当該予約席までの案内プログラムを起動する。この案内プログラムには、必ず、トイレ位置の案内が含まれるが、さらにお土産販売店の案内も含まれてよい。
【0267】
上記案内プログラムによる案内音声と動線情報（例えば画面による道案内情報）は、それぞれ個別回線で、それぞれのスマホ４５１０、４５１１、４５１５に、サーバ２３Ａから基地局２２Ａを介して送信される。このシステムにより、顧客は不安なく予約席まで行くことができる。
【0268】
上記の例は、イベント会場２０Ａの顧客動線システムを説明したが、イベント会場２０Ａだけでなく、大型ショッピングモール、デパート、空港、などにも本実施形態が適用可能であることは勿論である。この実施形態の場合、予約席の代わりに、買いたい商品のコンテキスト、出口番号、入り口番号などがサーバに設定される。
【0269】
さらにまた、本システムが、待ち合わせシステムとして利用された場合、次のような配慮がなされている。今、コンテキストデータとして、「絵画鑑賞」、属性情報として「日付」「待ち合わせ」「グループ人数」などが登録されているものとする。
【0270】
このような場合、１つのグループの複数のユーザが、ロボット周辺（コンテキストエリア）に集合する時間は、ぞれぞれ、ずれている。そこで、エージェント３０００は、到着したノードと通信を行った場合、コンテキストデータ「絵画鑑賞」の他に属性情報に少なくとも「待ち合わせ」と言う目的記述があるかどうかを判定する。当該ノードが「待ち合わせ」という属性情報を有する場合、エージェント３００は、同じコンテキストマッチング関連にあるユーザがすでに到着しているかどうかを判定する。また新たに到着したユーザのデバイスＩＤをグループ用メモリに記述する。そして、新たに到着したユーザのノードに対しては、現在の集合人数（実際にはノード数）をブロードキャストで返信する。
【0271】
図１４は、ビーコン・パケットのユーザ領域を利用する場合の他の例である。
【0272】
ユーザ領域２３には、図１で説明したように、バイト７～バイト８には、メンバＩＤ（Member ID：電子装置のユーザの識別情報）が記述される。バイト９～バイト１０には、モジュールＩＤ（非特定アプリケーションの識別情報）が記述される。バイト１１には、フレームタイプ（Frame Type）が記述される。フレームタイプ（Frame Type）は送信種別を示す、ことを説明した。
【0273】
さらにバイト１２～バイト３１は、パラメータ部（Parameters：送信情報）である。パラメータ部は、複数のパラメータを格納する。各パラメータは、ＴＬ部とＶＡＬ部からなる。ＴＬ部は１バイトからなり、ＴＹＰＥフィールドとＬＥＮＧＴＨフィールドからなる。ＴＹＰＥフィールドは、ＶＡＬ部内のデータのタイプ（int型、float型、string型がある）が、int型、float型、string型のいずれであるかを区別していることを説明した。
【0274】
図１４は、上記のパラメータ部に記述されるパラメータ（データと称してもよい）の他の例を示すが、このようなフォーマットに限定されるものではない。パラメータ部のデータ領域は、ヘッダー領域ｂ、情報ＩＤ記述領域ｃ、制御コード記述領域ｄ、デバイスＩＤ記述領域ｅ、データ記述領域ｆ、を含む。
【0275】
ヘッダー領域ｂには、ヘッダー領域ｂには、パラメータ部の特定のコードが割り当てられている。次に続く情報ＩＤ記述領域ｃには、どのような種類（特にデータ部のデータの種類）の情報が送られているかを示す識別データが記述される。種類としては、例えばＧＰＳ情報、センサ情報、などがある。さらに、ファイルシステムのように、各種データの記述領域の割り当てバイト数の情報が存在してもよい。
【0276】
ノードＩＤの記述領域ｅには、このビーコン・パケット２１を送信するデバイスの識別データであり、例えば、エージェント、ノード、スマホ、ゲートウエイなどのデバイスを識別する識別データである。
【0277】
制御コードの領域ｄには、例えば新しい状況ルールが登録される場合、或は状況ルールに変更があるとき、などを伝える場合、或はルールそのものを伝える場合に利用される。また、制御コードには、
データ記述領域ｅには、コンテキストに対応したスキーマ情報が利用される。つまり、送信側と受信側で予め取り決めた意味をもつコードが用いられる。また、利用するコンテキストマッチングサービスの種類によっては、生のコンテキストデータが用いられる場合も含む。
データ記述領域ｅには、コンテキストに対応したスキーマ情報が利用される。つまり、送信側と受信側で予め取り決めた意味をもつコードが用いられる。また、利用するコンテキストマッチングサービスの種類によっては、生のコンテキストデータが用いられる場合も含む。
【0278】
上記のエリアの情報は、一般には属性情報と称される。上記の属性情報は、固定のものではなく限定されるものではない。属性情報は、基本的には、いわゆるコンテキストデータの取り扱いを指示するものである。したがってシステム運用者において、属性情報のフォーマットや内容は種々であり、重要なものは、属性情報がこのエリアに存在することである。
【0279】
制御コードの領域ｄは、利用期間記述領域を含んでもよい。利用期間記述領域は、本サービスを利用可能な利用期間（年月日、曜日、時間帯）が記述される。この利用期間情報は、システムや利用者により必要に応じて書き換えが可能である。例えば、販売促進システム（図７Ａ、図７Ｂで説明）の利用者と本システム運営者との契約が満了となった場合は、システムにより利用期間が自動的に削除される場合がある。また販売促進システムの活用されたために、販売商品が完売となると、利用者は、登録システムから、テンプレートを利用して利用期間を削除することができる。また出会い検知システム（図１０Ａで説明）においても利用者は、出会い検知が実現した場合、登録システムから、テンプレートを利用して利用期間を削除することができる。
【0280】
さらにまた、エージェントが利用される環境によっては、「時間帯」や「日」によって、マッチング通知を頻繁に欲しいものと、さほど頻繁でなくてもよいものが存在する。この場合、マッチング通知が頻繁でなくてもよいエージェントに対するマッチング通知を時間帯に応じて、自動的に制御するための情報領域として、利用期間記述領域ｄ２を利用できる。
【0281】
従って、利用期間を示すデータにも、利用形態を示す識別データが含まれていてもよい。コンテキスト判定部１０００は、この識別データを認識したうえで、利用期間（年月日、曜日、時間帯）の活用形態を決めて、エージェントの制御を実行するように設定されている。
【0282】
制御コードの領域ｄは、データの送信を排除又は否定すべきデバイスＩＤを記述する領域ｄ３を含む。この領域ｄ３は、エージェント２０００と３０００が、それぞれブロードキャストする毎に、送信するデバイスＩＤの間引きを行う場合に利用される。
【0283】
例えば、２つのエージェントのコンテキストエリアが重なるような場合、１つのノードが２つのエージェントからマッチング報告を受けることがある。
【0284】
例えばもし、図２Ａのコンテキストエリア１０と２０が重なった場合、ノード４１００、４４００「メロンパン好きのグループ」は、２つのエージェント２０００と３０００から、「メロンパン値引き」というマッチング報告を受けることになる。そこで、このような場合、コンテキスト判定部１０００は、エージェント２０００と３０００が、ブロードキャストする毎に、送信されるデバイスＩＤ（４１００、４４００）が間引きされるように制御することができる。例えばこの例では、ブロードキャストの２回に１回の割合で、４１００、４４００のデバイスＩＤの送信が否定される。例えば、領域ｄ３には、否定すべきデバイスＩＤとブロードキャスト毎の頻度（この例では例えば１／２）が記述される。３つのコンテキストエリアが重なっている場合は、頻度１／３が記述される。
【0285】
この頻度の指定は、コンテキスト判定部１０００からの通知に基づいて、エージェント２０００と３０００が自らの制御のもとで行うように、エージェント内の送信データ処理プログラムが設定されている（重複排除の実行が可能）。
【0286】
また上記の処理が実現するためには、コンテキスト判定部１０００は、コンテキストエリア１０と２０が重なっていることを検出する必要がある。この検出は、以下のように行われる。即ち、エージェント２０００が状況通知したときは、その通知するデータの中にエージェント３０００のデバイスＩＤが含まれており、さらにエージェント３０００が状況通知したときは、その通知するデータの中にエージェント２０００のデバイスＩＤが含まれている。このような場合は、コンテキスト判定部１０００は、コンテキストエリア１０と２０が重なっていると判断する。そしてコンテキスト判定部１０００は、上記した領域ｄ３に頻度が設定されるように、各エージェント２０００、３０００を制御する。
【0287】
さらに、制御コードの領域ｄは、マッチング処理で不採用とするコンテキストデータの記述領域を含む。記述領域には、例えば明らかに公序良俗に反するような用語が記述される。
【0288】
さらに、制御コードの領域ｄは、続きの送信データが有るか否かを示すフラッグの記述領域を備える。例えば、この記述領域には、「終わり」又は「続く」が記述される。上記したように、本システムにおける１回のビーコン通信では、パラメータ部で送信できるデータ量には、限りがある。そこで、１回（今回）のビーコン通信で送信されるデータ容量に対して、送信すべきすべてデータの容量がオーバーするような場合、記述領域ｄ５に「続く」が記述される。そして次回のビーコン通信でも続きのデータが送られる。
【0289】
上記のようにパラメータ部にファイルシステム領域ｃ、属性データ記述領域ｄを設けることにより、多様で充実したビーコン通信を実現できる。
【0290】
さらにまた、制御コードの領域ｄの中に、パスワード「使用」、「不使用」の記述領域を設けてもよい。パスワードは、ビーコン通信を行う特定の利用者（例えば６Ｃ１と６Ｄ１）が予め取り決めるパスワードである。利用者６Ｃ１と６Ｄ１は、共通のパスワードを、例えばスマホタイプのノードのデータ処理器のメモリに予め登録する。そして、利用者６Ｃ１と６Ｄ１がパスワード「使用或はＯＮ」をメニュー画面で設定すると、自動的にパスワード有無の記述領域ｄ６に、パスワード「使用」の記号が記述される。このようにすると、利用者６Ｃ１と６Ｄ１のみがビーコン通信で相互の情報を交換することができるようになる。つまり、ビーコン通信で取得したパラメータが、パスワードにより圧縮されているときは、互いのノードは、パスワードを使用して、デバイスＩＤやコンテキストで他を解凍する。しかし、利用者６Ｃ１と６Ｄ１がパスワード「不使用或はＯＦＦ」をメニュー画面で設定すると、通常のビーコン通信で、コンテキストマッチング処理が可能となる。この場合は、先に説明した実施形態と同様な動作を得ることができる。
【0291】
図１５は、本システムの情報処理器が、さらにｉｆＬｉｎｋ（登録商標）システムと複合化された実施形態を示している。情報処理器はエージェント又はノードでもよく、ここではエージェント３０００として説明する。
【0292】
一方、発明者等は、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）システムに対してｉｆＬｉｎｋ（登録商標）システムを結合する場合、スマホを活用する方法をすでに開発している。そこで、今回は、発明者等は、スマホタイプのエージェント３０００が、さらにｉｆＬｉｎｋシステムと復号化した新しいシステムを開発した。
【0293】
図１５に示すエージェント３０００は、ｉｆＬｉｎｋアプリ３２０１と、ＩＢＩ（ｉｆＬｉｎｋ Ｂｅａｃｏｎ Ｉｎｔｅｒｆａｃｅ）マイクロサービス３２０２を搭載している。ＩＢＩマイクロサービス３２０２は、マイクロサービスに基づいて、ｉｆＬｉｎｋアプリ３２０１と、先の各実施例で説明した各種の情報処理器との橋渡しを行うことができる。したがって、ＩＢＩマクロサービス３２０２は、ビーコン信号のフォーマットで送られてくるデータを読み取ることができ、ｉｆＬｉｎｋアプリ３２０１で使用されるデータに変換するスキーマ情報を備える。また逆に、ＩＢＩマクロサービス３２０２は、スキーマ情報により、ｉｆＬｉｎｋアプリ３２０１で使用されるデータを、ビーコン信号のフォーマットのデータに変換することもできる。
【0294】
図に示す例は、センサ一体型のノード４Ｃ１１が、ＩＢＩを介してエージェント３０００に接続され、また、スマホタイプのノード４Ｃ１２が、ＩＢＩを介してエッジコンピュータ３０００に接続される例を示している。
【0295】
ノード４Ｃ１１は、例えばＣＯ２が規定値以下の場合と、規定値より多く検出した場合とで、それぞれ異なる電文をサービス情報として、エージェント３０００に送信する。ＣＯ２が規定値以下の場合は、例えば「換気が充分に保たれています」と言う電文（サービス情報）であり、規定値より多く検出した場合は、例えば「ＣＯ２が多くなっています、今すぐ、換気を行ってください」のような電文（サービス情報）である。これらの電文は、ノード４Ｃ１１のメモリにパケット用データとして記述されている。
【0296】
しかし電文としては、上記の電文に限らず、予め取り決めた記号或は符号であってもよい。そして、この記号や符号が、ｉｆＬｉｎｋアプリ３２０１で解釈できるようにしてもよい。このような方式であると、ビーコン信号のデータ量が少なくてよく、また、エージェント３０００を使用しているユーザの使用言語に合わせてｉｆＬｉｎｋアプリ３２０１の応答言語（文字出力、或は音声出力）を設定できる。
【0297】
スマホタイプのノード４Ｃ１２は、例えばＩＢＩライブラリを有し、スマホの独自の言語を、ＩＢＩマイクロサービス３２０２が理解できるタイプの言語に変換して送るように構成される。この場合、この変換に利用されるデータは、スキーマ情報と称される。このように、スマホタイプのノード４Ｃ１２は、は、一般のスマホに対して、ＩＢＩライブラリとして機能するアプリケーションを、所定のサーバからダウンロードして取得し、容易に設定することができる。
【0298】
＜ｉｆＬｉｎｋシステムの概要＞
図１６は、ｉｆＬｉｎｋシステムの概要を説明するための図である。このｉｆＬｉｎｋシステムと、上記したブロードキャストシステムと、さらにユニキャストシステムを組み合わせ利用することで、多種の機能を実現することができる。
図１６は、ｉｆＬｉｎｋシステムの概要を説明するための図である。このｉｆＬｉｎｋシステムと、上記したブロードキャストシステムと、さらにユニキャストシステムを組み合わせ利用することで、多種の機能を実現することができる。
【0299】
ｉｆＬｉｎｋシステムにおいては、ＩＦ－ＴＨＥＮルールが利用される。ＩＦ－ＴＨＥＮルールとは、若しＩＦ＝Ａと言う条件が満たされるとＴＨＥＮ＝Ｂというアクションが発動されるというように、「条件アイテム」に対応する「約束アイテム」或は「取り決めアイテム」を設定したルールである。
【0300】
＜サーバ１７内の概要＞
各種のＩＦ－ＴＨＥＮルールは、例えばサーバ１７のデータ部１７０３に格納されている。各種のＩＦ－ＴＨＥＮルールは、ルールマネージャ１７０２により管理されている。ルールマネージャ１７０２は、ＩＦ－ＴＨＥＮルールの製作者、ルールの販売、貸出、その値段など管理し、また新しいルールの受付、古いルールの処分等も管理している。
各種のＩＦ－ＴＨＥＮルールは、例えばサーバ１７のデータ部１７０３に格納されている。各種のＩＦ－ＴＨＥＮルールは、ルールマネージャ１７０２により管理されている。ルールマネージャ１７０２は、ＩＦ－ＴＨＥＮルールの製作者、ルールの販売、貸出、その値段など管理し、また新しいルールの受付、古いルールの処分等も管理している。
【0301】
ルール課金管理部１７０４は、ＩＦ－ＴＨＥＮルールを使用したユーザを管理し、当該ユーザに対するルール使用料などを発行することもできる。またユーザがＩＦ－ＴＨＥＮルールを使用する期間などを管理することもできる。
【0302】
＜エージェント（又はノード）３０００内の概要＞
エージェント３０００が、スマホタイプの場合、スマホアプリ３１０６を有する。また、表示制御部３１０７、操作制御部３１０８を有する。操作制御部３１０８は、表示部と一体型のタッチパネルが利用されることが多い。
エージェント３０００が、スマホタイプの場合、スマホアプリ３１０６を有する。また、表示制御部３１０７、操作制御部３１０８を有する。操作制御部３１０８は、表示部と一体型のタッチパネルが利用されることが多い。
【0303】
さらに、ここでは、ｉｆＬｉｎｋアプリ３２０１がエージェント３０００に搭載され、全体を統括制御する。ｉｆＬｉｎｋアプリ３２０１は、さらにＩＦ－ＴＨＥＮエンジン３１００を含む。
【0304】
システム制御部３１０５は、スマホアプリ３２０１、表示制御部３１０７、操作制御部３１０８、ｉｆＬｉｎｋアプリ３２０１、ＩＦ－ＴＨＥＮルール格納部３１００等を統括しており、各部の制御タイミング、動作タイミングの調整・制御などを行う。
【0305】
エージェント３０００は、ネットワークＮＥＴＷに接続された送信部３００１及び受信部３００２を備える。ｉｆＬｉｎｋアプリ３０１は、送信部３１０１を介してサーバ１７をアクセスして、所望のＩＦ－ＴＨＥＮルールを要求することができる。ＩＦ－ＴＨＥＮルールには、例えば名称（利用可能な設備名、システム名などの識別名）が付加されており、カタログなどで紹介されている。ユーザは、所望の識別名を、入力画面に入力することで、受信部３１０２を介して、所望のＩＦ－ＴＥＮルールをダウンロードすることができる。
【0306】
ＩＦ－ＴＨＥＮルールは、ルール管理部及び制御部３２０７を介して、ＩＦ－ＴＨＥＮルール格納部３１０９に格納される。ＩＦ－ＴＨＥＮルールは、単一のものもあるが、複数のルールが集合したＩＦ－ＴＨＥＮルールセットが多い。
【0307】
複数のＩＦ－ＴＨＥＮルールセットは、ルールセットＩＤにより識別されている。同一のルールセットがサーバ１７から取り寄せられた場合、後から追加されたルールが有効となるように、ルール管理及び制御部３２０７により調整されている。ルールが更新されたことは、表示制御部３１０７を介してユーザに通知される。
【0308】
ルール管理及び制御部３２０７は、ＩＦモニタ３２０６がＩＢＩマイクロサービス３２０２から最初の「条件」を受け取ると、当該「条件」をルール管理部及び制御部３２０７に与える。すると、ルール管理部及び制御部３２０７は、当該「条件」を最初に含むルールセットをＩＦ－ＴＨＥＮルール格納部３１０９から、読出し、ＴＨＥＮ実行管理部３２０８にセットする。
【0309】
ＴＨＥＮ実行管理部３２０８は、セットされたルールセットの最初の「条件＝ＩＦ」を既に受け取っている。したがって、ＴＨＥＮ実行管理部３２０８は、この「条件＝ＩＦ」に対応した「発動＝ＴＨＥＮ」のためのコマンドをＪＯＢ制御部３２０９に与える。ＪＯＢ制御部３２０９は、当該コマンドを、ＩＢＩマイクロサービス３２０２に与える。ＩＢＩマイクロサービス３２０２は、コマンドに対応した「検出データ」を、ＩＢＩ対応している外部機器に対して、ビーコン信号で送信する。
【0310】
これにより、１つのＪＯＢが実行されるわけであり、その情報は、ログ出力部３２１０、送信部３１０１を通じて、ルールマネージャ１７０２及び又はルール課金管理部１７０４へ送信される。
【0311】
上記の「検出データ」は、ビーコン送受信部３１０３を介して、例えばノード４Ｃ１２などに送信される。ビーコン送受信部３１０３は、先の送受信部３１０１、３１０２と一体となっていてもかまわない。
【0312】
上記のエージェント３０００は、ＩＢＩマイクロサービス３２０２のみならず、種々の個別機器とも相互通信が可能なように、個別機器用マイクロサービス（ＭＳ）３２０４、Ｗｅｂ用マイクロサービス（ＭＳ）３２０５も備える。
【0313】
このため、先のＪＯＢ制御部３２０８は、コマンドを送信する際、そのコマンドにマイクロサービス指定用のコードを付加する。つまり、ＩＢＩマイクロサービス３２０２、或は個別機器用マイクロサービス（ＭＳ）３２０４、或はＷｅｂ用マイクロサービス（ＭＳ）３２０５が、選択的に指定されることで、送受信先の切り替えが可能である。
【0314】
このように構成した場合、ビーコン信号によりブロードキャストで入手したＩＦの応答であるＴＥＨＮの実行コマンドを、個別機器用ＭＳ３１１、或はＷｅｂ用ＭＳに接続された機器に反映させることが可能となる。個別機器用ＭＳ３２０４への外部からの指令は、ユニキャストにより与えられることになる。
【0315】
上記とは逆に、個別機器用ＭＳ３２０４、或はＷｅｂ用ＭＳ３２０５を介して取得したＩＦの応答であるＴＥＨＮの実行コマンドを、ＩＢＩマイクロサービス３２０２に接続された機器に反映させることも可能である。
【0316】
＜ＩＦ－ＴＥＮルールの構成例＞
図１７は、ＩＦ－ＴＨＥＮルールの構成例を示す図である。ルールセットの基本的な考え方を説明するためにその一例としての構成例である。例えばルールセット６０１０は、４つのルール１からルール４を有するものとする。
図においては、ＩＦデバイスは、ＩＦ１,ＩＦ２,ＩＦ３・・・・のようにデバイスを区別して示し、ＴＨＥＮデバイスは、ＴＨＥＮ１、ＴＨＥＮ２、ＴＨＥＮ３、・・・のようにデバイスを区別して示す。
図１７は、ＩＦ－ＴＨＥＮルールの構成例を示す図である。ルールセットの基本的な考え方を説明するためにその一例としての構成例である。例えばルールセット６０１０は、４つのルール１からルール４を有するものとする。
図においては、ＩＦデバイスは、ＩＦ１,ＩＦ２,ＩＦ３・・・・のようにデバイスを区別して示し、ＴＨＥＮデバイスは、ＴＨＥＮ１、ＴＨＥＮ２、ＴＨＥＮ３、・・・のようにデバイスを区別して示す。
【0317】
ルール１は、ＩＦデバイスのＩＦ１とＴＨＥＮデバイスのＴＨＥＮ１とを連携させており、ＩＦデバイスＩＦ１の条件（以下「条件」は、動作条件、検出条件等を意味する）が満たされるとＴＨＥＮデバイスＴＨＥＮ１が発動（以下「発動」は、応答、或は起動、或は停止、等を意味する）するルールである、
ルール２は、ＩＦデバイスのＩＦ２とＩＦデバイスのＩＦ３の条件が同時に満たされると、ＴＨＥＮデバイスＴＨＥＮ２が発動するルールである、
ルール３は、ＩＦデバイスＩＦ４の条件が満たされると、ＴＨＥＮデバイスＴＨＥＮ３とＴＨＥＮデバイスＴＨＥＮ４が発動するルールである、
ルール４は、ＩＦデバイスのＩＦ５とＩＦデバイスのＩＦ６の条件が同時に満たされると、ＴＨＥＮデバイスのＴＨＥＮ５とＴＨＥＮデバイスのＴＨＥＮ６が発動するルールである。
ルール２は、ＩＦデバイスのＩＦ２とＩＦデバイスのＩＦ３の条件が同時に満たされると、ＴＨＥＮデバイスＴＨＥＮ２が発動するルールである、
ルール３は、ＩＦデバイスＩＦ４の条件が満たされると、ＴＨＥＮデバイスＴＨＥＮ３とＴＨＥＮデバイスＴＨＥＮ４が発動するルールである、
ルール４は、ＩＦデバイスのＩＦ５とＩＦデバイスのＩＦ６の条件が同時に満たされると、ＴＨＥＮデバイスのＴＨＥＮ５とＴＨＥＮデバイスのＴＨＥＮ６が発動するルールである。
【0318】
ここでルールセットの全体属性情報６０１１としては、ルールセットの概要（文字による記述可）、ルールセット識別データ、ルールセット名称（文字による記述可）が存在する。この場合さらに、このルールセットに対応するマイクロサービスの情報（識別データ）が存在してもよい。つまり、全体属性情報によりルールセットのルールを外部のデバイスに反映するために用意されているマイクロサービスが特定されていてもよい。
またルールセット優先順位情報、ルールセット有効無効設定情報、ルールセット利用環境情報が存在してもよい。
またルールセット優先順位情報、ルールセット有効無効設定情報、ルールセット利用環境情報が存在してもよい。
【0319】
ルールセット優先順位情報は、他のルールセットが競合するような場合、その優先順位を決める情報であり、競合相手となる他のルールセット識別データとともに記述されていてもよい。ルールセット有効無効設定情報は、本ルールセットが機能すべきか否かを設定する情報である。したがって期間情報と合わせることで、ルールセットの有効期間や無効期間を設定することもできる。さらにルールセット利用環境情報があってもよい、この情報は例えばこのルールセットが採用されるための所定の条件（環境条件）を記述した情報である。例えば、天気が晴れの場合、あるいは特別の施設の中で使用されている場合などである。環境条件は、ルールセットを記憶する例えばエッジコンピュータによって自動的に記述されてもよい。さらに、施設、利用者、課題、ＧＰＳ状報などの特定の利用環境の属性情報が記述されてもよい。この利用環境の属性情報も、当該ルールセットを記憶するエッジコンピュータにより自動的に記述されてもよいし、エッジコンピュータを有するユーザがエッジコンピュータの外部から記述してもよい。
【0320】
個別のルール６０１２（ルール１、２、３、・・・）の属性情報としては、ルール名称（文字による記述可）、ルール識別データが存在する。この属性情報にも、ルール優先順位情報、ルール有効無効設定情報が存在してもよい。またルールセット利用環境情報と同様に、ルール毎の独自のルール使用環境情報が存在してもよい。この場合は、ルール使用環境情報は、ルールセット利用環境情報の下位概念を規定することになる。
【0321】
さらに個別のＩＦデバイス６０１３（ＩＦ１－ＩＦ６）の属性情報としては、ＩＦデバイス名（センサ名或はサービス名でもよい）（文字記述可）、ＩＦデバイスのシリアル番号、IFデバイスの概要（文字による記述可）、条件などが存在する。条件としては、ＩＦデバイスの動作状態（検知）の範囲、閾値、抑止時間、個別パラメータなどが設定可能である。
【0322】
動作状態（検知の）範囲とは、例えば温度センサであれば２０度から２５度の範囲を検知した場合に検知出力を送信する、閾値とは、例えば、３０度以上を検出した場合に検知出力を送信する、抑止時間とは、検知した時点から何秒後に検知出力を送信するか、などを決める情報である。このような属性情報により、同じＩＦデバイスからの検知出力であっても、この検知出力が異なる値（値の範囲や値の閾値において異なる値）の場合、それぞれの値の範囲や値の閾値に応じて異なるＴＨＥＮデバイスを指定することも実現可能である。また、同自ＴＨＥＮデバイスであってもＩＦデバイスから入力するそれぞれの異なる値に応じて、この同じＴＨＥＮデバイスに異なる制御命令を発動させることも実現可能である。
【0323】
上記のＩＦデバイスは、基本的には先にアクションを生じる先行要素であり、少なくともセンサ名、シリアル番号などの先行要素識別情報を含む属性情報を有する。
【0324】
また個別のＴＨＥＮデバイスの属性情報６０１４としては、ＴＨＥＮデバイス名（センサ名或はサービス名でもよい）（文字による記述可）、ＴＨＥＮデバイスのシリアル番号、ＴＨＥＮデバイスの概要（文字による記述可）、条件などが存在する。
【0325】
条件としては、ＴＨＥＮデバイスの抑止時間、センサ名、制御対象、個別パラメータなどが設定可能である。
抑止時間とは、ＩＦデバイスからの検出通知があった時点から何秒後に応答を開始するか、或は他のＴＨＥＮデバイス（或は他のＩＦデバイス）の動作環境が整っているかどうかを判定するための待ち時間などを決める情報である。
センサ名（或はifparamとも称される）は、対応する先行要素としてのIFデバイスの名称や番号などであり、対応IFデバイスと確実にリンクさせることができる情報である。
制御対象は、ＴＨＥＮデバイスの中でもさらに、指定したい部位やスイッチなど指す。制御対象が記述されていると、ＴＨＥＮデバイスの例えば単純な電源のオンオフ制御ではなく、電源オン状態において、さらに電流や電圧を制御対象としたい場合に有効である。
抑止時間とは、ＩＦデバイスからの検出通知があった時点から何秒後に応答を開始するか、或は他のＴＨＥＮデバイス（或は他のＩＦデバイス）の動作環境が整っているかどうかを判定するための待ち時間などを決める情報である。
センサ名（或はifparamとも称される）は、対応する先行要素としてのIFデバイスの名称や番号などであり、対応IFデバイスと確実にリンクさせることができる情報である。
制御対象は、ＴＨＥＮデバイスの中でもさらに、指定したい部位やスイッチなど指す。制御対象が記述されていると、ＴＨＥＮデバイスの例えば単純な電源のオンオフ制御ではなく、電源オン状態において、さらに電流や電圧を制御対象としたい場合に有効である。
【0326】
個別パラメータは、具体的な制御情報を発生するための情報である。例えば、動作範囲を設定する具体的な情報（例えばドローン制御であればその高さを制限する情報）がある。
上記の属性情報にも、外部のデバイスに向けてコマンドを出力するマイクロサービスを特定するデータが記述されることが好ましい。これにより、このエッジコンピュータ（例えば３００）が、不用意に他のエリアなどのデバイスを制御するようなことが防止される。つまり、マイクロサービスは、自器で管轄すべきＩＦデバイスとＴＨＥＮデバイスを特定できるので、他のマイクロサービスの管轄のＩＦデバイスやＴＨＥＮデバイスに応答したり制御したりすることがない。
上記の属性情報にも、外部のデバイスに向けてコマンドを出力するマイクロサービスを特定するデータが記述されることが好ましい。これにより、このエッジコンピュータ（例えば３００）が、不用意に他のエリアなどのデバイスを制御するようなことが防止される。つまり、マイクロサービスは、自器で管轄すべきＩＦデバイスとＴＨＥＮデバイスを特定できるので、他のマイクロサービスの管轄のＩＦデバイスやＴＨＥＮデバイスに応答したり制御したりすることがない。
【0327】
上記のＴＨＥＮデバイスは、基本的には先の先行アクションに連携して後行アクションを実行する後行要素であり、少なくともデバイス名、シリアル番号などの後行要素識別情報を含む属性情報を有する。
【0328】
さらに、属性情報としては「イベント関連情報」が記述されていてもよい。イベント関連情報とは、例えばこのＴＨＥＮデバイスが動作したときに、この動作が他のＩＦデバイスに影響を与えるような場合、そのＩＦデバイスのデバイス名とかシリアル番号、或は概要などを記述する欄である。またどのような影響を与えるかを概要として文字列により記述できるようにしてもよい。たとえば、ＴＨＥＮデバイスが特定の音を発するようなデバイスであると、本来関係ない音センサとしてのＩＦデバイスに影響を与えることがある。またＴＨＥＮデバイスが、光を出力するようなデバイスであると、光センサとしてのＩＦデバイスに影響を与える場合がある。このようなケースが事前にわかると、利用者は、ＴＨＥＮデバイス或はＩＦデバイスを他のセンサに交換することを考慮することができる。イベント関連情報は、ルールセットを例えば販売提供するメーカが予め記述するが、ユーザ自器がエッジコンピュータにおいて、意識的に記述できるようにしてもよい。これによりルールセットの多様な使い方が可能となる。
【0329】
なお、各属性情報には識別用の属性識別情報（ヘッダと称してもよい）が設けられている。ルール実行プログラムは、属性識別情報を読み取り、属性の種類、属性情報の有り無し、を判定できる。ルール実行プログラムは、属性情報が記述されていると判断した場合は、その属性内容を確認しチェックすることが可能であり、属性情報が記述されていないと判断した場合は、属性情報のチェックをスルーする。
【0330】
属性識別情報が無い場合は、ルール実行プログラムは、属性記述記号（例えば、deviceserial=, id=,など）の順に応じて順次、属性情報の内容判断を行う。内容を決めていない属性情報の場合は、属性情報の例えばヘッダーや属性記述記号の次の所定のデータ領域に例えば００００が記述される。この場合は、当該属性情報の判定や処理は無視される。
【0331】
上記の属性情報には、さらに、先のルールセット使用環境情報として、ルールセットが使用される空間を示す（或は推奨する）情報（ルールセットが採用されるシーン情報）、ルールセットを使用するユーザ情報、ルールセットに関係するテーマなどの情報が記述されてもよい。また、これらのシーン情報、ユーザ情報、テーマなどの情報は、IFデバイスの属性情報内、ＴＨＥＮデバイスの属性情報内に選択的に記述されていてもよい。
【0332】
＜ビーコン信号の利用方法のさらなる説明＞
図１８は、図１に示したフレームタイプ（Ｆｌａｍｅ Ｔｙｐｅ）の構成の一例を示す。フレームタイプを利用すると、ビーコン信号を利用した相互通信をより高度な内容とすることが可能となる。したがって、フレームタイプ（Ｆｌａｍｅ Ｔｙｐｅ）を利用すると、重要な内容のコンテキストデータの送受信を行う場合に有効である。
図１８は、図１に示したフレームタイプ（Ｆｌａｍｅ Ｔｙｐｅ）の構成の一例を示す。フレームタイプを利用すると、ビーコン信号を利用した相互通信をより高度な内容とすることが可能となる。したがって、フレームタイプ（Ｆｌａｍｅ Ｔｙｐｅ）を利用すると、重要な内容のコンテキストデータの送受信を行う場合に有効である。
【0333】
フレームタイプは、１バイトからなり、要求／応答を示すＲＥＱ／ＲＥＳフラグ、コマンドに対する応答が必要か否かを示すＲＥＰＬＹフラグ及び実際のコマンド（COMMAND）からなる。
【0334】
例えばセンサ値送信の場合、「要求」は、スマホタイプの情報処理器５００のスマホアプリ（個別アプリと称してもよい）からＩＢＩマイクロサービス３０２へセンサ値を送信することであり、「応答」は、ＩＢＩマイクロサービス３０２からスマホアプリへ「センサ値を受信しました」と送信することである。
ビット７はＲＥＱ／ＲＥＳフラグのフィールドであり、送信種別が要求の場合、フラグは０とされ、送信種別が応答の場合、フラグは１とされる。
ビット６はＲＥＰＬＹフラグのフィールドであり、応答が不要な場合、フラグは０とさ れ、応答が必要な場合、フラグは１とされる。
ビット５～ビット０のコマンドは、１：デバイス登録（未使用）、２：デバイス登録結 果（未使用）、３：センサ値通知、４：ジョブ通知、５：ジョブ結果通知である。
ビット７はＲＥＱ／ＲＥＳフラグのフィールドであり、送信種別が要求の場合、フラグは０とされ、送信種別が応答の場合、フラグは１とされる。
ビット６はＲＥＰＬＹフラグのフィールドであり、応答が不要な場合、フラグは０とさ れ、応答が必要な場合、フラグは１とされる。
ビット５～ビット０のコマンドは、１：デバイス登録（未使用）、２：デバイス登録結 果（未使用）、３：センサ値通知、４：ジョブ通知、５：ジョブ結果通知である。
【0335】
図１９は、図１８のフレームタイプの設定値の一例を示す。例えば、センサ値応答（応答不要）のフレームタイプは、０ｘ０３である。センサ値応答（応答要）のフレームタイプは、０ｘ４３である。センサ値通知の例は、センサとしてのスマホアプリ（個別アプリ）からＩＢＩマイクロサービス３０２へのセンサ値の送信である。
【0336】
センサ値応答のフレームタイプの設定値は、０ｘＣ３である。センサ値応答の例は、センサ値通知（応答要）の場合、ＩＢＩマイクロサービス３０２からセンサとしてのスマホアプリへ「センサ値を受信しました」という応答の送信である。
【0337】
ジョブ通知（応答不要）のフレームタイプの設定値は、０ｘ０４である。ジョブ通知（応答要）のフレームタイプは、０ｘ４４である。ジョブ通知の例は、ＩＢＩマイクロサービス３０２からＴＨＥＮモジュールとしてのスマホアプリへ「〇〇動作をして下さい」という指示の送信である。
【0338】
ジョブ結果通知のフレームタイプは、０ｘＣ４である。ジョブ結果通知の例は、ＴＨＥＮモジュールとしてのスマホアプリからＩＢＩマイクロサービス３０２へ「〇〇動作をし ました」という応答の送信である。
＜スキーマ情報例＞
図２０は、実施形態によるスキーマ情報の一例を示す。まず、この情報には、ＩＢＩが対応できるデバイス名が記述される。この例では、例えばデバイス名SampleDevie１とデバイス名SampleDevie２が記述されている。
＜スキーマ情報例＞
図２０は、実施形態によるスキーマ情報の一例を示す。まず、この情報には、ＩＢＩが対応できるデバイス名が記述される。この例では、例えばデバイス名SampleDevie１とデバイス名SampleDevie２が記述されている。
【0339】
デバイス名SampleDevie１は、例えば第１のスマートフォンに対応し、デバイス名SampleDevie２は、例えば第２のスマートフォンに対応することを意味する。各デバイス名に続いてスキーマ情報が記述される。
【0340】
プロパティ(property)として、デバイス名（devicename）、デバイスシリアル番号（deviceserial）、タイムスタンプ、メンバＩＤ（me mberid）、モジュールＩＤ（moduleid）、パラメータ１（param１）～パラメータ４（param4）が記述されている。デバイス名SampleDevie１は、
図２１は、センサ値通知のためのビーコン・パケット内のパラメータ（Parameters）の一例を示す。ただしここでは、コンテキストデータの基本的な送信パターンを説明する。
図２１は、センサ値通知のためのビーコン・パケット内のパラメータ（Parameters）の一例を示す。ただしここでは、コンテキストデータの基本的な送信パターンを説明する。
【0341】
例えば、センサ値通知時のパラメータ（コンテキストデータと称してよい）は、パラメータ１～パラメータ４がこの順にビーコン・パケットに格納される。この例では、バイト１２の０ｘ２０は、最初のパラメータ（param１）がｉｎｔ型、１バイトであることを示し、バイト１３がその値（０）を示す。バイト１４の０ｘ４３が、次のパラメータ（param２）がｆｌｏａｔ型、４バイトであることを示し、バイト１５～バイト１８がその値（１．２）を示す。この例では、個別アプリ３４は２つのセンサ、例えば温度センサと湿度センサ、を備え、センサ値はparam１とparam２に格納され、param１は温度、param２は湿度を示す。パラメータの数は４に限定されず、送信したいデータ次第で、数は可変である。
【0342】
上記の各種の情報処理器において、電源供給システムが用意されていてもよい。スマホタイプの場合は、既に充電器が存在する。しかし、簡易型の情報処理器であると、電源電圧が低下した場合、電源確保を行う必要がある。そのために、ソーラ型発電器、圧電型発電器、振動型発電器などの付属品が電源部に追加されていてもよい。またユーザ領域のデータについては、暗号処理或はパスワードを伴うデータ圧縮処理が施されてもよい。
【0343】
上記したように各実施形態及びその組み合わせによる実施形態においては、種々の発明が含まれる。
【0344】
図２２から図３２は、それぞれが実施形態における基本構成を示すものであり、特有の工夫がなされた部分を取り出して示している。今まで説明した構成要素と同一部分には同一符号を付して重複した説明は省略する。ここでエージェント２０００、３０００を第１の情報処理器、ノード４１００－４４００を第２の情報処理器とする。すると、
図２２では、コンテキスト判定部１０００に第１のコンテキストを登録している第１の情報処理器２０００、３０００と、前記コンテキスト判定部１０００に第２のコンテキストを登録している第２の情報処理器４１００－４４００と、を備える。前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行う、そして、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える、ことを特徴とする 情報処理システムが提供される。
図２２では、コンテキスト判定部１０００に第１のコンテキストを登録している第１の情報処理器２０００、３０００と、前記コンテキスト判定部１０００に第２のコンテキストを登録している第２の情報処理器４１００－４４００と、を備える。前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行う、そして、ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える、ことを特徴とする 情報処理システムが提供される。
【0345】
図２３は、さらに別の実施形態としての基本構成を示す。この実施形態は、コンテキスト判定部１０００Ａ、１０００Ｂが、それぞれエージェント２０００、３０００内に配置されている例である。コンテキスト判定部１０００Ａ、１０００Ｂは、サーバ７ＡとネットワークＮＴＷを介して接続されており、それぞれが必要なソフトウエア、などをダウンロードして使用することができる。ユーザはプロフ情報を登録するときは、登録するコンテキスト判定部（又はエージェント）を指定することも可能である。
【0346】
図２４は、さらに別の実施形態としての基本構成を示す。この実施形態は、コンテキスト判定部１０００Ａ、１０００Ｂが、それぞれエージェント２０００、３０００内に配置され、コンテキスト判定部１０００Ｃがエージェントの外部（例えばサーバ）に配置されている例である。
【0347】
この場合は、図２Ｂで説明した利用方法が可能である。また、エージェントが取り扱うデータ量の規模に応じて、外部のコンテキスト判定部１０００Ｃと、エージェント内のコンテキスト判定部１０００Ａ又は１０００Ｂとを使い分けることも可能である。例えば、販売品目が少ない商店は、エージェント内のコンテキスト判定部１０００Ａ、１０００Ｂを利用し、販売商品が大量となるショッピングモールは、外部のコンテキスト判定部１０００Ｃを利用するのである。
【0348】
図２５は、さらに別の実施形態としての基本構成を示すものであり、特有の工夫がなされた部分を取り出して示している。図２２の実施形態に加えて、ルール設定者（状況のルール設定を行う側（人、事業者等））５５００が、システムをアクセス可能としたものである。ルール設定者５５００は、コンテキストスキーム及びルール設定システム５０００を操作する。コンテキストスキーム及びルール設定システム５０００は、コンテキスト判定部１０００に接続可能であり、マッチング関係となる状況のルールを設定することでユーザサービス形態を設計及び設定する。サービス形態としては、先に説明した見守りサービス、販売促進サービスなどである。コンテキストスキーム及びルール設定部５０００は、状況ルールを設定する要素として、少なくともコンテキスト、デバイスＩＤの入力部を用意する。この例は、状況のルール設定が、エージェント外部のコンテキスト判定部１０００を介して、各エージェント２０００、３０００に対して実施される。
【0349】
図２６は、図２５のタイプに比べて、状況のルール設定が、エージェント内の状況ルール設定部において直接実施される例である。しかし、状況のルール設定のための情報は、サーバ７Ａ経由により、各エージェント２０００、３０００に送られてもよい。
【0350】
図２７は、図２２の実施形態に加えて、実際に利用者がプロフィール情報を入力する情報登録システム６０００が追加され、前記コンテキスト判定部１０００に接続可能とした例を示している。即ち、ここでは、前記マッチング関係の具体的判断要素となる、前記第１の情報処理器、前記第２の情報処理器のそれぞれのデバイスＩＤ，それぞれのコンテキストデータ、を含むプロフィール情報を事前設定することが可能となる。
【0351】
図２８は、図２２の実施形態に加えて、プロフィール情報を入力する情報登録システム６０００が、直接エージェント内のコンテキスト判定部１０００Ａ或は１０００Ｂに接続された例である。この場合も、プロフィール情報は、サーバ７Ａ経由により、各エージェント２０００、３０００に送られてもよい。
【0352】
図２９は、図２２の実施形態に加えて、提供情報入力システム７０００が前記コンテキスト判定部１０００に接続可能された例である。この提供情報入力システム７０００は、前記マッチング関係となる情報処理器に対して与える結果データ（相手に提供すべきコンテキスト内容のデータ）を、事前入力する入力システムである。例えば、「メロンパン値引き」などの情報がある。
【0353】
図３０は、図２２の実施形態に加えて、提供情報を入力する提供情報入力システム７０００が、直接エージェント内のコンテキスト判定部１０００Ａ或は１０００Ｂに接続された例である。この場合も、提供情報は、サーバ７Ａ経由により、各エージェント２０００、３０００に送られてもよい。
【0354】
図３１は、図２２の実施形態に加えて、送信管理システム９０００Ａ，９０００Ｂが前記コンテキスト判定部１０００に接続された例を示している。送信管理システム９０００Ａ，９０００Ｂは、前記コンテキスト関連情報の送り方として、送信頻度、排他的制御、重複排除のいずれかを行うもので、各エージェント２０００，３０００の送信形態を制御することができる。特に、エージェント２０００，３０００のコンテキストエリアが一部重なっているような場合は有効である。図の例では、例えばノード４２００とノード４３００には、両方のエージェント２０００，３０００から「赤ワイン値引き」と言う情報が報告される。このような場合、エージェント２０００，３０００のＪＯＢ情報には、互いに広告実績数の中に余分な広告が１つ加算されていることになる。このことは、例えば、ルール設定者（或はシステム運営者）が、広告成立のための課金をエージェント２０００，３０００に対して実施する場合、過分の課金を行うことになる。
【0355】
そこで、送信管理システム９０００Ａ，９０００Ｂは、ノード４２００とノード４３００が両方のエージェント２０００，３０００のＪＯＢ情報に含まれるときは、例えば次のような対策を行う。例えば、課金を１/２にする、或は、エージェント２０００，３０００のビーコン送信頻度を低減して均等に振り分ける。
【0356】
【0357】
送信管理システム９０００Ａ，９０００Ｂは、エージェント２０００，３０００の送信出力パワーの制御を可能としてもよい。例えば、特定のエージェントに対して、月日や、時間帯に応じて送信電力の出力パワーをいつもより強化する制御が行われてもよい。この制御は、例えば自動マーケティング運営者が、予めシステム管理者に依頼しておくことで、可能となる。送信電力の出力パワーを制御した場合、コンテキストエリアの範囲を拡大或は縮小可能である。このため特に販売促進を行う場合は、有効となる。また送信管理システム９０００Ａ，９０００Ｂの運営者は、エージェント管理者に対する課金を行うことも可能となる。
【0358】
＜上記した実施形態は、種々の発明を含む、以下各発明の基本的な構成をまとめる＞
Ａ１]登録システム（少なくとも情報登録システム６０００を含む）は、複数の情報処理器（エージェント２０００、３０００、ノード４１００－４４００）のそれぞれが少なくともニーズ又はリクエストしている内容を示すコンテキストを登録部（コンテキスト判定部１０００）に登録し、
送受信システム（送受信部１１００、エージェント２０００、３０００の送受信部）は、前記登録システムと情報交換を行うものであって、前記複数の情報処理器が互いに同一の通信環境に同時に存在するときに前記複数の情報処理器を認識し、前記登録システムが前記複数の情報処理器の間で前記コンテキストがマッチング関係にあると判定している場合、前記マッチング関係であることを示す情報を前記複数の情報処理器に送信する、コンテキストマッチング関連情報処理システム又は情報処理装置。
Ａ１]登録システム（少なくとも情報登録システム６０００を含む）は、複数の情報処理器（エージェント２０００、３０００、ノード４１００－４４００）のそれぞれが少なくともニーズ又はリクエストしている内容を示すコンテキストを登録部（コンテキスト判定部１０００）に登録し、
送受信システム（送受信部１１００、エージェント２０００、３０００の送受信部）は、前記登録システムと情報交換を行うものであって、前記複数の情報処理器が互いに同一の通信環境に同時に存在するときに前記複数の情報処理器を認識し、前記登録システムが前記複数の情報処理器の間で前記コンテキストがマッチング関係にあると判定している場合、前記マッチング関係であることを示す情報を前記複数の情報処理器に送信する、コンテキストマッチング関連情報処理システム又は情報処理装置。
【0359】
Ａ２]さらにまた上記のコンテキストマッチング関連情報処理システム又は上記情報処理装置は、コンテキストマッチングを実行するサーバ、又はエージェント、などを含むことができる。また、情報処理装置は、前記登録システムの一部または全体を含む場合もある。また、上記の複数の情報処理器のタイプとしては、センサを有するタイプ、センサが接続されるタイプ、表示器、音声出力器を有するものもある。
＜受信側（エージェント又はノード）のシリーズ＞
Ｂ１]通信規格データを含むヘッダー領域（２２）と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域（２３）とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
前記ビーコン信号を受信し、受信した前記ユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記コンテキストデータに応じたサービス情報の出力を行う装置（２０００、３０００）であり、
前記ビーコン信号の受信部（２３００、２３０１）と、前記検出データを得る検出部（２３０４）と、前記検出データが得られた場合、前記コンテキストデータに応じた前記サービス情報の出力を行う出力部（２３０７）を備える、サービス情報の受信装置が提供される。
＜受信側（エージェント又はノード）のシリーズ＞
Ｂ１]通信規格データを含むヘッダー領域（２２）と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域（２３）とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
前記ビーコン信号を受信し、受信した前記ユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記コンテキストデータに応じたサービス情報の出力を行う装置（２０００、３０００）であり、
前記ビーコン信号の受信部（２３００、２３０１）と、前記検出データを得る検出部（２３０４）と、前記検出データが得られた場合、前記コンテキストデータに応じた前記サービス情報の出力を行う出力部（２３０７）を備える、サービス情報の受信装置が提供される。
【0360】
Ｂ２] 前記受信した前記ユーザ領域のデータが、前記自器の設定したコンテキストデータと前記対応関係にある、と言うことを示す前記検出データは、外部のコンテキストマッチングノード（マッチング判定が高度である）１０００から取得した検出データである、Ｂ１に記載のサービス情報の受信装置が提供される。
【0361】
Ｂ３] 前記受信した前記ユーザ領域のデータが、前記自器の設定したコンテキストデータと前記対応関係にある、と言うことを示す前記検出データは、前記自器の制御部（自器がマッチングファームウェアを持つエージェントやＰＣ、２３０４，２３０５，２３０６）の処理により得られた検出データである、Ｂ１に記載のサービス情報の受信装置が提供される。
【0362】
Ｂ４] 前記受信した前記ユーザ領域のデータが、前記自器の設定したコンテキストデータと前記対応関係にある、と言うことを示す前記検出データは、前記自器の制御部が取り換え可能なメモリのデータを前記自器の設定したコンテキストデータとして用いることで得られた検出データである（自器のコンテキストデータを交換可能メモリ（２３０５）に入れておき、受信したコンテキストデータと比較することができる：各種のジャンルのデータのメモリチップを取り換え可能）、Ｂ１に記載のサービス情報の受信装置が提供される。
【0363】
＜送信部、受信部を有する・・メロンパン、赤ワインの例で、コンビニ側のエージェントの構成＞
Ｃ１]通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
自器のビーコン信号を送信する送信部と、他器のビーコン信号を受信する受信部と、前記他器のビーコン信号を受信し、受信した前記他器のユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データである場合、前記自器の設定したコンテキストデータに応じたサービス情報を前記他器において出力させるためのデータを、前記送信部を介して送信（通知）する制御部と、を備える、サービス情報の送信及び受信装置が提供される。
Ｃ１]通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
自器のビーコン信号を送信する送信部と、他器のビーコン信号を受信する受信部と、前記他器のビーコン信号を受信し、受信した前記他器のユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データである場合、前記自器の設定したコンテキストデータに応じたサービス情報を前記他器において出力させるためのデータを、前記送信部を介して送信（通知）する制御部と、を備える、サービス情報の送信及び受信装置が提供される。
【0364】
Ｃ２] 前記受信した前記他器のユーザ領域のデータが、前記自器の設定したコンテキストデータと前記対応関係にある、と言うことを示す前記検出データは、外部のコンテキストマッチングノード（マッチング判定が高度なノード：サーバ）から取得した検出データである、請求項Ｃ１に記載のサービス情報の送信装置が提供される。
【0365】
Ｃ３] 前記サービス情報を前記他器において出力させるための前記データは、前記自器のビーコン信号のユーザ領域に前記サービス情報の内容を記述したデータ（例えば：メロンパン値引き、或はクーポン）である、請求項Ｃ１に記載のサービス情報の送信装置が提供される。
【0366】
Ｃ４] 前記受信した前記他器のユーザ領域のデータが、前記自器の設定したコンテキストデータと前記対応関係にある、と言うことを示す前記検出データは、前記自器の制御部（自器がマッチングファームウェアを持つエージェントやＰＣの場合）の処理により得られた検出データである、請求項Ｃ１に記載のサービス情報の送信装置が提供される。
＜送受信システムとしての内容＞
Ｄ１] 通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
送信装置が、自器のビーコン信号を送信する送信部と、他器のビーコン信号を受信する受信部と、前記他器のビーコン信号を受信し、受信した前記他器のユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記自器の設定したコンテキストデータが示すサービスに応じた動作を前記他器に行わせるためのデータを、前記送信部を介して送信する制御部と、
を備え、
前記他器としての受信装置が、前記送信装置からのビーコン信号を受信し、前記サービスを得るための前記データを検出する装置であり、前記ビーコン信号の受信部と、
前記データを得る検出部と、前記データが得られた場合、自器のコンテキストデータが示す前記サービスに応じた出力を行う出力部を備える、サービス情報の送信及び受信システムが提供される。
＜送受信システムとしての内容＞
Ｄ１] 通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストするシステムに用いられるものであり、
送信装置が、自器のビーコン信号を送信する送信部と、他器のビーコン信号を受信する受信部と、前記他器のビーコン信号を受信し、受信した前記他器のユーザ領域のデータが、自器の設定したコンテキストデータと対応関係にある、と言うことを示す検出データを取得した場合、前記自器の設定したコンテキストデータが示すサービスに応じた動作を前記他器に行わせるためのデータを、前記送信部を介して送信する制御部と、
を備え、
前記他器としての受信装置が、前記送信装置からのビーコン信号を受信し、前記サービスを得るための前記データを検出する装置であり、前記ビーコン信号の受信部と、
前記データを得る検出部と、前記データが得られた場合、自器のコンテキストデータが示す前記サービスに応じた出力を行う出力部を備える、サービス情報の送信及び受信システムが提供される。
【0367】
＜ｉｆＬｉｎｋシステムとの連携＞
Ｅ１] 条件としてのＩＦデータと前記条件に呼応するためのＴＨＥＮデータを含み、前記ＩＦデータが与えられたとき、前記ＴＨＥＮデータを得るためのルールセットが定義されており、前記ルールセットが設定されるＩＦ－ＴＨＥＮエンジンと、
特定された「ＪＯＢ」を指示するコマンドが与えられるＩＢＩマイクロサービス及び個別機器用マイクロサービスを含む複数のマイクロサービスと、を備え、
前記ＩＢＩマイクロサービスは、ビーコン送受信部に接続されており、
前記ビーコン送受信部は、通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストする送受信部であり、ビーコン信号のブロードキャストと、前記個別機器用マイクロサービスを利用するユニットキャストを利用可能にした送信および受信装置が提供される。
Ｅ１] 条件としてのＩＦデータと前記条件に呼応するためのＴＨＥＮデータを含み、前記ＩＦデータが与えられたとき、前記ＴＨＥＮデータを得るためのルールセットが定義されており、前記ルールセットが設定されるＩＦ－ＴＨＥＮエンジンと、
特定された「ＪＯＢ」を指示するコマンドが与えられるＩＢＩマイクロサービス及び個別機器用マイクロサービスを含む複数のマイクロサービスと、を備え、
前記ＩＢＩマイクロサービスは、ビーコン送受信部に接続されており、
前記ビーコン送受信部は、通信規格データを含むヘッダー領域と、利用しているデバイスＩＤとコンテキストデータとを書き込み可能なユーザ領域とからなるパケットをビーコン信号としてブロードキャストする送受信部であり、ビーコン信号のブロードキャストと、前記個別機器用マイクロサービスを利用するユニットキャストを利用可能にした送信および受信装置が提供される。
【0368】
＜基本システム＞
Ｆ１） コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器と、前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える、ことを特徴とする情報処理システムが提供される。
Ｆ１） コンテキスト判定部に第１のコンテキストを登録している第１の情報処理器と、前記コンテキスト判定部に第２のコンテキストを登録している第２の情報処理器と、前記第１の情報処理器と前記第２の情報処理理器とは、互いにビーコン通信を行い、
ビーコン・パケットに含まれるコンテキスト関連情報を判定する判定部を備え、前記判定の結果データが前記第１のコンテキストと前記第２のコンテキストとがマッチング関係であることを示す場合、
前記第１の情報処理器は前記結果データをノード通知データとして処理するデータ処理器を備え、
前記第２の情報処理器は前記結果データをユーザ通知用（表示又は音声又は振動）出力データとして処理するデータ処理器を備える、ことを特徴とする情報処理システムが提供される。
【0369】
Ｆ２）上記Ｆ１）に加えて、さらに、前記コンテキスト判定部に接続可能であり、
前記マッチング関係となる状況を設定することでユーザサービス形態を設計するための状況設定システムであって、
前記状況を設定する要素として、少なくともコンテキスト、デバイスＩＤの入力部を用意している、状況設定システムを備える、ことを特徴とする情報処理システムが提供される。
前記マッチング関係となる状況を設定することでユーザサービス形態を設計するための状況設定システムであって、
前記状況を設定する要素として、少なくともコンテキスト、デバイスＩＤの入力部を用意している、状況設定システムを備える、ことを特徴とする情報処理システムが提供される。
【0370】
Ｆ３）上記Ｆ１）に加えて、さらに、前記コンテキスト判定部に対して、
前記マッチング関係の具体的判断要素となる、前記第１の情報処理器、前記第２の情報処理器のそれぞれのデバイスＩＤ，それぞれのコンテキストデータ、を含むプロフィール情報を事前設定するためのプロフィール情報入力システムを接続可能である、ことを特徴とする 情報処理システムが提供される。
前記マッチング関係の具体的判断要素となる、前記第１の情報処理器、前記第２の情報処理器のそれぞれのデバイスＩＤ，それぞれのコンテキストデータ、を含むプロフィール情報を事前設定するためのプロフィール情報入力システムを接続可能である、ことを特徴とする 情報処理システムが提供される。
【0371】
Ｆ４）上記Ｆ１）に加えて、さらに、前記コンテキスト判定部に接続可能であり、
前記マッチング関係となる情報処理器に対して与える前記結果データは、相手に提供すべきコンテキスト内容のデータであることを事前入力するための提供情報入力システムを有する、
ことを特徴とする 情報処理システムが提供される。
前記マッチング関係となる情報処理器に対して与える前記結果データは、相手に提供すべきコンテキスト内容のデータであることを事前入力するための提供情報入力システムを有する、
ことを特徴とする 情報処理システムが提供される。
【0372】
Ｆ５）上記Ｆ１）に加えて、さらに、前記コンテキスト判定部に接続可能であり、前記コンテキスト関連情報の送り方として、送信頻度、排他的制御、重複排除のいずれかを行う送信管理情報を前記コンテキスト判定部に入力する送信管理システムを有する、ことを特徴とする 情報処理システムが提供される。
【0373】
また上記の装置は、カテゴリーとして、送信方法、受信方法、送受信方法としても特徴を備えるものである。
【符号の説明】
【0374】
１０、２０・・・コンテキストエリア、２１・・・ビーコン・パケット、２３・・・ユーザ領域、１０００・・・コンテキスト判定部、１１００・・・送受信部、１２００・・・ファイル部、
１２０１・・・テーブル、１３００・・・状況マッチング処理部、２０００、３０００・・・エージェント、２００１、３００１・・・サブテーブル、４２００、４３００、４４００・・・ノード、
５０００・・・状況設定システム、５５００・・・ルール設定者、
６０００・・・情報登録システム、６５００・・・情報を欲しい側のユーザ、７０００・・・提供情報入力システム、７５００・・・情報を提供する側のユーザ、９０００・・・送信管理システム、９５００・・・システム管理者。
１２０１・・・テーブル、１３００・・・状況マッチング処理部、２０００、３０００・・・エージェント、２００１、３００１・・・サブテーブル、４２００、４３００、４４００・・・ノード、
５０００・・・状況設定システム、５５００・・・ルール設定者、
６０００・・・情報登録システム、６５００・・・情報を欲しい側のユーザ、７０００・・・提供情報入力システム、７５００・・・情報を提供する側のユーザ、９０００・・・送信管理システム、９５００・・・システム管理者。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5A】
【図5B】
【図5C】
【図5D】
【図5E】
【図6A】
【図6B】
【図6C】
【図6D】
【図7A】
【図7B】
【図8A】
【図8B】
【図9A】
【図9B】
【図10A】
【図10B】
【図10C】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】