(57)【要約】【課題】複数の権原端末装置が、ローカル（現場）又は通信回線を利用した同時期に所定範囲に配設された同じ鍵管理制御装置の現場台帳をリモートメンテナンスしても、互いに同期しないこと。【解決手段】所定範囲に存在する建物の複数の鍵データを現場台帳に管理する鍵管理制御装置と、現場台帳の鍵データを変更する権原を有する権原端末装置と、少なくとも権原端末装置又は鍵管理制御装置のいずれから変更した鍵データを、通信回線を介して受付け、かつ受付けた変化点情報を記憶部に保存するサーバを備え、少なくとも権原端末装置又は鍵管理制御装置のいずれかは、サーバが記憶部に保存されている変化点情報を、通信回線を介して参照することができる通信回線における鍵データ制御システム。【選択図】図１
2016056635.tif 000002
【特許請求の範囲】
【請求項１】
所定範囲に存在する建物の複数の鍵データを現場台帳に管理する鍵管理制御装置と、前記現場台帳の前記鍵データを変更する権原を有する権原端末装置と、少なくとも前記権原端末装置又は鍵管理制御装置のいずれから前記変更した鍵データを、通信回線を介して受付け、かつ受付けた変化点情報を記憶部に保存するサーバを備え、
少なくとも前記権原端末装置又は鍵管理制御装置のいずれかは、前記サーバが前記記憶部に保存されている変化点情報を、前記通信回線を介して参照することができる、通信回線における鍵データ制御システム。
【請求項２】
請求項１に於いて、サーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、所定の保存領域に複数の変化点情報が発生した場合、最も新しい鍵データを、後入れ先出しリスト構造を持つスタック領域に最新の変化点情報として保有することができることを特徴とする通信回線における鍵データ制御システム。
【請求項３】
請求項１に於いて、サーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、複数の変化点情報が発生した場合、先入れ先出しリスト構造を持つキュー部領域に最新の変化点情報として保有することができることを特徴とする通信回線における鍵データ制御システム。
【請求項４】
請求項１、請求項２、請求項３のいずれかに於いて、サーバは、順次又は所定時間経過後のいずれかに、スタック領域或いはキュー部領域から最新の変化点情報を次々と更新する変更台帳を有し、少なくとも権原端末装置又は鍵管理制御装置のいずれかは、前記変更台帳を参照することができることを特徴とする通信回線における鍵データ制御システム。
【請求項５】
請求項４に於いて、鍵管理制御装置は所定時間経過後又は定期的かのいずれかに、変更台帳に保存されている更新情報を問い合わせることができることを特徴とする通信回線における鍵データ制御システム。
【請求項６】
請求項１に於いて、鍵管理制御装置は、建物のゲートを管理する入退出管理制御装置であることを特徴とする通信回線における鍵データ制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、建物の複数の鍵データを管理する鍵管理制御装置と、前記鍵データを変更する権原を有する権原端末装置と、前記鍵管理制御装置又は権原端末装置のいずれかから、変更した鍵情報を受信し、該変化点情報を記録するサーバとを備える、通信回線における鍵データ制御システムに関する。
【背景技術】
【０００２】
一般にオンラインシステムでは、各端末から送られてくるメッセージを一旦待ち行列（キュー）に登録する。これが入力メッセージのキューイングで、コンピュータの基本的なデータ構造の一つである。メッセージのキューイングの機能は、ＯＳや人間の頭脳に相当するアプリケーションではなく、人間の手足に相当する「ミドルウェア」によって提供されることが多く、ＡＰＩを呼び出すことにより、アプリケーションソフトから簡単に利用できるようになっている。そして、待ち行列（キュー）にデータを入れることを「エンキー」といい、前記データを取り出すことを「デキュー」という。前記デキューは、普通一般に先行するデータから順番に取り出され、これを「先入れ先出しリスト構造」と称し、該先入れ先出しリスト構造を持つデータバッファは「キュー部領域」と称されている。
【０００３】
一方、上記普通一般のキューとは逆に、「後入れ先出しのリスト構造」を持つデータバッファは、「スタック領域」と称されている。このように、「先入れ先出しか」、それとも「後入れ先出しか」によってメモリー領域の呼び方が異なるものの、入力メッセージのキューイング手段は、周知事項である。
【０００４】
まず特許文献１は、入力メッセージのキューイングに関する技術であり、処理待ち入力メッセージの中で有効期限の過ぎたものを消去して、処理の無駄をなくし、且つ、キュースタックの有効利用を図るために、端末１からオンラインシステムセンタ２へは、有効時間を指定してメッセージが送られてくると、該オンラインシステムセンタ２のメッセージ登録部２３は、入力メッセージをスタック３１に登録すると共に、そのメッセージ有効期限管理情報を管理エリア３２に登録する。そして、前記メッセージ登録部２４は、スタック３１から入力メッセージを取り出して処理し、処理結果を端末１へ通知する一方、メッセージ有効期限制御部２５は一定時間毎に管理エリア３２のメッセージ有効期限管理情報をサーチし、有効期限満了のものがあれば、スタック３１内の該当入力メッセージを消去する方式である（符号は特許文献１のもの）。なお、特許文献１の「スタック」の概念は、発明の目的を考慮すると、普通一般のキュー部領域の方式を前提としているものと考えられる。
【０００５】
次に特許文献２は、錠管理システムに関する技術であり、保守管理が容易で、設置コスト及び維持コストが低廉で、かつ、利用者にとっても利便性の高い錠管理システムを得るために、ユーザが所持する携帯端末装置６の応答器（タグ）の開錠コード（鍵データ）を用い、施開錠装置２の質問器（タグリーダ）と、前記携帯端末装置６の応答器（タグ）との呼応により、建物のドアに設けられた電子錠１を解錠することを前提として、「建物のドア側に設けられた施開錠装置２と、この施開錠装置の記憶部に格納されている鍵データを管理する錠管理サーバ４と、この錠管理サーバ４が管理する前記鍵データと同一の鍵データを有する携帯端末装置６とを備えた錠管理システムにおいて、第１及び第２の開錠コード（鍵データ）を新たに生成する手段１５と、前記錠管理サーバ４から前記施開錠装置２に対して第１の開錠コードを送信するとともに、前記携帯端末装置６に対して第２の開錠コードを送信する開錠コード配信手段１６と、施開錠装置２と携帯端末装置６との間で相互に近距離無線通信を行う近距離無線通信手段１０と、近距離無線通信手段１０によって通信を行い、第１の開錠コードと第２の開錠コードとを照合し、両者が適合した場合には施開錠装置２により錠の開錠を行う開錠制御手段１３を具備する錠管理システム」である。
【０００６】
さらに特許文献３にも、ユーザが所持する記憶媒体としての応答器（タグ）の鍵データ（識別子）を用い、ドア付近或いはドアに設けられた通信ユニット（施・解錠装置）の質問器（タグリーダ）と、前記応答器（タグ）との呼応により、建物のドアに設けられた電気錠（電子錠）を解錠することができる旨が記載されている。そして、該特許文献２の図２には、通信ユニット（施・解錠装置）が存在する建物の現場で、該通信ユニット（施・解錠装置）に出入力部に設定入力器（外部端末）を接続し、通信ユニット（施・解錠装置）の複数の鍵データの設定・更新・削除ができる旨が示唆されている。このように、ドア側の質問器（タグリーダ）と、ユーザが所持する携帯端末装置の応答器（タグ）との呼応により、建物のドアに設けられた電気錠（電子錠）を解錠することは周知事項であり、これらの解錠システムは、例えば入退出管理システムとか、入出退管理装置とも称されている（例えば特開平１０−４９７６７号公報、特許第３３７６６８６号公報など）。
【０００７】
ところで、所定範囲（区画された土地）に存在する集合住宅、事業を営んでいるビルディング等の建物の複数の鍵データを管理する鍵管理制御装置（入退出管理システム）は、例えば前記所定範囲に単数又は複数配設され、該鍵管理制御装置が保有する現場の鍵台帳は、原権を有する権原端末装置により、変更（更新等）可能であるものの、次のような問題点があった。
【０００８】
従来、電気錠制御装置の鍵データを変更する場合、業者又は権原を有する管理者が、外部端末を所持し、前記電気錠制御装置の鍵データを変更していた。ところで、業者等が電気錠制御装置の鍵データを変更する場合、鍵データを一括管理する「鍵管理制御装置」の場所で行うことができれば便利である。また通信回線が普及した現在、前記鍵データの変更は、例えばインターネットを利用すれば非常に便利である。
【０００９】
しかして、複数の権原端末装置が、ローカル（現場）又は通信回線を利用して同時期に所定範囲に配設された同じ鍵管理制御装置の現場台帳をメンテナンスする場合、鍵データを変更する側と鍵データを変更される側は、互いに同期しないことが望まれる。そこで、現在、理想的な鍵データ制御システムの出現が望まれる。なお、特許文献１、特許文献２、特許文献３等には、サーバのキューイング手段と鍵管理制御装置とを組み合せることは開示されていない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開５−３１４０６９号公報
【特許文献２】特開２００４−１２０２５７号公報
【特許文献３】特開２０１２−３６７０４号公報の図２
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本願発明の主たる目的は、複数の権原端末装置が、ローカル（現場）又は通信回線を利用した同時期に所定範囲に配設された同じ鍵管理制御装置の現場台帳をリモートメンテナンスしても、互いに同期しないことである。また、通信回線を利用して鍵データを簡単に変更することができることである。本願発明の第２の目的は、少なくとも権原端末装置又は鍵管理制御装置のいずれかは、通信回線を介してリアルタイムにサーバが管理する変更台帳を参照し、最新の変化点情報が正しく反映されているか否かを確認、或いは問い合わせすることができることである。
【課題を解決するための手段】
【００１２】
本発明の通信回線における鍵データ制御システムは、所定範囲に存在する建物の複数の鍵データを現場台帳に管理する鍵管理制御装置と、前記現場台帳の前記鍵データを変更する権原を有する権原端末装置と、少なくとも前記権原端末装置又は鍵管理制御装置のいずれから前記変更した鍵データを、通信回線を介して受付け、かつ受付けた変化点情報を記憶部に保存するサーバを備え、少なくとも前記権原端末装置又は鍵管理制御装置のいずれかは、前記サーバが前記記憶部に保存されている変化点情報を、前記通信回線を介して参照することができることを特徴とする。
【００１３】
上記構成に於いて、サーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、所定の保存領域に複数の変化点情報（経時的に先・後する変更鍵データ）が発生した場合、最も新しい鍵データを、例えば後入れ先出しリスト構造を持つスタック領域に「最新の変化点情報」として保有することができることを特徴とする。またサーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、複数の変化点情報が発生した場合、例えば先入れ先出しリスト構造を持つキュー部領域に最新の変化点情報として保有することができることを特徴とする。またサーバは、順次又は所定時間経過後のいずれかに、所定の領域から最新の変化点情報を次々と更新する変更台帳を有し、  少なくとも権原端末装置は又は鍵管理制御装置のいずれかは、前記変更台帳を参照することができることを特徴とする。また鍵管理制御装置は所定時間経過後又は定期的かのいずれかに、変更台帳に保存されている更新情報を問い合わせることができることを特徴とする。さらに、鍵管理制御装置は、建物のゲートを管理する入退出管理制御装置であることを特徴とする。
【００１４】
なお、実施形態のサーバ１７は、図１で示すように、いわば鍵データ処理装置３１に含めても良いキューイング手段の保存領域（スタック領域又はキュー部領域）３７と変更台帳３６ａを格納する記憶部３６の両方を有する。
【００１５】
付言すると、キューイング手段の保存領域３６は、先入れ先出しリスト構造を持つデータバッファとしての「キュー部領域３７」、又は後入れ先出しのリスト構造を持つデータバッファとしての「スタック領域３７」のいずれであっても良く、望ましくは、先入れ先出しされた、或いは後入れ先出しされた変化点情報は、変更台帳３６ａとしてサーバ１７に保存される。
【発明の効果】
【００１６】
（ａ）請求項１に記載の発明は、所定範囲に存在する建物の複数の鍵データを現場台帳に管理する鍵管理制御装置と、前記現場台帳の前記鍵データを変更する権原を有する権原端末装置と、少なくとも前記権原端末装置又は鍵管理制御装置のいずれから前記変更した鍵データを、通信回線を介して受付け、かつ受付けた変化点情報を記憶部に保存するサーバを備え、少なくとも前記権原端末装置又は鍵管理制御装置のいずれかは、前記サーバが前記記憶部に保存されている変化点情報を、前記通信回線を介して参照することができるので、多数の権原端末装置が、ローカル（現場）又は通信回線を利用した同時期に所定範囲に配設された同じ鍵管理制御装置の現場台帳をリモートメンテナンスしても、互いに同期しない。また、通信回線を利用して鍵データを簡単に変更することができる。さらに、少なくとも権原端末装置又は鍵管理制御装置のいずれかは、通信回線を介してリアルタイムにサーバが管理する変更台帳を参照し、最新の変化点情報が正しく反映されているか否かを確認、或いは問い合わせすることができる。
（ｂ）請求項２に記載の発明は、サーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、所定の保存領域に複数の変化点情報（経時的に先・後する変更鍵データ）が発生した場合、最も新しい鍵データを、後入れ先出しリスト構造を持つスタック領域に「最新の変化点情報」として保有することができることができるので、（ａ）の効果を確実に得ることができる。
（ｃ）請求項３に記載の発明は、サーバは、変化点情報を列状態に格納するキューイング手段を有し、該キューイング手段は、所定の保存領域に複数の変化点情報が発生した場合、先入れ先出しリスト構造を持つキュー部領域に最新の変化点情報として保有することができるので、請求項２に記載の発明と同様に（ａ）の効果を確実に得ることができる。
（ｄ）請求項４並びに請求項５に記載の発明は、サーバは、順次又は所定時間経過後のいずれかに、スタック領域から最新の変化点情報を次々と更新する変更台帳を有し、少なくとも権原端末装置は又は鍵管理制御装置のいずれかは、前記変更台帳を参照することができるので、メンテナンスの信頼性を得ることができる。
（ｅ）請求項６に記載の発明は、複数の電気錠制御装置の鍵データを一括管理する入退出管理制御装置に適用することができるので、現場で鍵データを変更する際、各階にそれぞれ設置されている電気錠制御装置に脚を運ぶ必要がなく、前記入退出管理制御装置が設置されている場で即時に実施をすることができるので、変更作業の利便性が向上する。
【図面の簡単な説明】
【００１７】
図１乃至図１０は本発明の一実施形態を示す各説明図。
【図１】全体の概念を示す鍵データ制御システム図。
【図２】全体の概念を示す鍵データ制御システム図。
【図３】鍵管理制御装置１５を中心とする説明図。
【図４】送信される変化点情報のデータ構造を示す説明図。
【図５】変化点情報の送信（端末）と受信（サーバ）の概略説明図。
【図６】サーバ１７を中心とする説明図。
【図７】キューイング手段を構成するスタック領域の説明図。
【図８】変化点情報の移行の概略説明図。
【図９】権原端末装置１８等の動作の具体例を示す説明図。
【図１０】キューイング手段を構成するキュー部領域の説明図。
【発明を実施するための最良の形態】
【００１８】
図１乃至図１０は、本発明の一実施形態の通信回線における鍵データ制御システムである。図１は本発明の全体の概念を示す鍵データ制御システムＸの概略説明図である。図２はドア３に設けられた電気錠４、ドア又はドア付近に設けられた電気錠制御装置５、通路、ドア付近、ドア等に設けられた質問器１１、質問器と呼応する所持者の応答器１２、建物２の複数の鍵データを管理する鍵管理制御装置１５、通信回線１６及びサーバ１７を示す説明図である。
【００１９】
まず、図１及び図２に於いて、仮想線の符号１は所定範囲（区画された土地）で、この所定範囲１には、少なくとも一つ以上のマンション、営利法人や公益法人が事業を行うビルディング等の建物２（以下、ここでは「建物」という）が存在する。この「建物」の概念には、例えば一丁目、町内会、自治会、一団地等の如く、区画された土地を、名称等により、所定の範囲を特定可能であれば、一丁目、町内会、一地域等に存在する多数の個人住宅も含まれる。
【００２０】
３は建物２のゲートに相当するドアで、例えば建物２の共用部分と専有部分を区別するゲートの場合には玄関ドアであり、該玄関ドア３には電気錠４が設けられている。なお、ドア３の概念には、例えば建物２が集合住宅であれば、エントランスの自動開閉扉や管理組合が管理する集会所、備品倉庫等のドアも含まれる。
【００２１】
したがって、一つの建物には、複数個のドア３（３ａ、３ｂ、３ｃ…３ｎ）が存在し、各ドア３にはそれぞれ電気錠４（４ａ、４ｂ、４ｃ…４ｎ）が配設されている。そして、各電気錠をそれぞれ制御する電気錠制御装置５（５ａ、５ｂ、５ｃ…５ｎ）が複数個存在し、各電気錠制御装置５の各記憶部６（６ａ、６ｂ、６ｃ…６ｎ）には、それぞれ当該ドアの鍵データ（認証リストＩＤ１〜ＩＤｎ：鍵データ１、鍵データ２、鍵データ３…鍵データｎ）が必要な数だけ格納されている。
【００２２】
ところで、図２に於いて、７は電気錠制御装置５の制御部、８は認証部、９は送受信部、１０は入出力部、１１は質問器（タグリーダ）、１２は居住者、従業員等が所持する応答器（タグ）である。
【００２３】
１５は所定範囲１に配設された単数又は複数の鍵管理制御装置である。この鍵管理制御装置１５は、例えば建物２が一つのマンション（集合住宅）であれば、共用部分に一台配設され、適当な接続態様、例えばＬＡＮ形式で電気錠制御装置５（５ａ、５ｂ、５ｃ…５ｎ）に接続されている。
【００２４】
したがって、所定範囲１に設置された単数又は複数の鍵管理制御装置１５は、建物２の各ドア３の各電気錠４を制御する各電気錠制御装置５にそれぞれ接続し、後述するように、実施形態では一つの建物２の多数の鍵データ（認証リスト：ＩＤ１、ＩＤ２〜ＩＤｎ）を管理する現場台帳、送信用アプリケーション（以下、これを「送信用アプリ」という）等を有している。
【００２５】
なお、質問器１１と応答器との呼応態様、質問器１１の具体的構成、電気錠制御装置５のデータ処理、電気錠制御装置５の電気錠４に対する制御態様等は周知事項なので、ここでは詳細な説明を割愛する。
【００２６】
次に、図３を参照にして鍵管理制御装置１５の構成について簡単に説明する。図３に於いて、２１は制御部で、この制御部は、送受信制御部２１ａと、変化点情報制御部２１ｂとを有する。２４はプログラムで、このプログラムには、送信アプリケーション２４ａと、受信アプリケーション２４ｂが含まれる。ここでは送信アプリケーション２４ａ及び受信アプリケーション２４ｂを、説明の便宜上「送信側アプリ」という。
【００２７】
実施形態のプログラム２４は、両方のアプリケーション２４ａ、２４ｂを有しているが、変化点情報を送信する送信アプリケーション２４ａのみでも良い。しかし、望ましくは、サーバ１７から変化点情報に関するログ情報（最新情報を含む履歴情報）を受信する受信アプリケーション２４ｂも有する。
【００２８】
２５はインターフェイスに相当する送受信部、２６は所定時間を知るための、或いは変化点情報の送信時間を設定するためのタイマ、２７は前述した送信側アプリの作動状況及び変化点情報制御部の制御状態（プロセスの生成、異常、終了等）を監視するプロセス監視部、そして、２８は記憶部である。
【００２９】
前記記憶部２８は、前述した建物２の複数（望ましくは略全て）の鍵データ（認証リストＩＤ：鍵データ１、鍵データ２、鍵データ３…鍵データｎ）を、いわば「商家の台帳」の如く格納する鍵データの現場台帳（一覧表）２８ａと、受信アプリケーション２４ｂがサーバ１７から受信した鍵データの変化点情報に関するログ情報２８ｂをそれぞれ格納している。
【００３０】
上記構成に於いて、権原端末装置１８は、通信回線（例えばインターネット）１６を介して鍵管理制御装置１５にアクセスし、権原（パスワード等）を入力してログインし、かつ、鍵データの現場台帳の一部を変更（更新等）することができる。
【００３１】
そして、権原端末装置１８が現場台帳の一部を変更した場合に於いて、実施形態では、（ａ）鍵管理制御装置１５が自動的に、自己のプログラム２４に基づいてサーバ１７に変化点情報を送信する場合と、（ｂ）権原端末装置１８が鍵管理制御装置１５に代って、該鍵管理制御装置と同様のプログラム（送信側アプリ）２４Ａを有するサーバ１７に変化点情報を送信する場合とがある。すなわち、サーバ１７は、少なくとも権原端末装置１８又は鍵管理制御装置１５のいずれから変更した鍵データを、通信回線１６を介して受付け、かつ受付けた変化点情報を記憶部（３６ａ、３６）に保存する。
【００３２】
さらに、付言すると、権原端末装置１８又は鍵管理制御装置１５は、送信アプリケーション２４ａに基づいて、当該変更した鍵データを「変化点情報（Ｐ）」としてサーバ１７に任意に送信する。その際のデータ構造は図４に示す通り、「鍵管理制御装置の識別子ａ」、「変化点情報（更新した鍵データ）の識別子ｂ」、「変化点情報の送信時間ｃ」、「通信パス（ソケットの指定）ｄ」、「その他ｅ」等である。
【００３３】
なお、特に図示しないが、所定範囲１に複数個（例えば８棟）の建物２が存在し、各建物２に対応して複数個（例えば８台）の鍵管理制御装置１５がそれぞれ適宜に配設されている場合には、各鍵管理制御装置１５はスイッチングハブを介して集中管理装置に接続している。
【００３４】
次に、図５を参照にして本発明の要部としての変化点情報を説明する。図５は権原端末装置１８（１８ａ、１８ｂ、１８ｃ…１８ｎ）が、ある物権情報の部屋情報の鍵データ（ＩＤ情報）を「修正する前」及び「修正した後」の状態を示し（図面左）、一方、鍵データの現場台帳２８ａの一部を変更した権原端末装置１８から送信される変化点情報Ｐと、通信回線１６を介して前記変化点情報Ｐを受信したサーバ１７の受信側アプリケーション（以下、「受信側アプリ」という）の前記部屋情報の鍵データ（ＩＤ情報）の内容を示す。
【００３５】
この図５から明らかなように、権原端末装置１８は現場台帳の一部、例えばＩＤ３の識別子（１００００００３）を弄（いじ）り、今仮に「ＩＤ３（１０００００１３）」に変更（更新）し、その他の識別子ＩＤ１、ＩＤ２、ＩＤｎを弄（いじ）らない場合には、前記変化点情報の「ＩＤ３（１０００００１３）」のみを送信し、その他のＩＤ１、ＩＤ２、ＩＤｎに関する情報は送信しない。
【００３６】
したがって、鍵管理制御装置１５は現場台帳２８ａを有するものの、サーバ１７の受信側アプリは各権原端末装置１８（１８ａ、１８ｂ、１８ｃ…１８ｎ）からそれぞれ変化点情報のみを受信するだけなので、図面右で示すように、変化点情報Ｐのみを、後述するキューイング手段を介して管理し、該変化点情報Ｐは「変更台帳（変更表）３６ａ」として保持される。付言すると、サーバ１７は鍵管理制御装置１５と同様の現場台帳２８ａを有しない。
【００３７】
次に、図６を参照にしてサーバ１７の構成について簡単に説明する。図６に於いて、３１は制御部で、この制御部３１は、特に図示しないが、鍵管理制御装置１５と同様の送受信制御部と、変化点情報制御部とを有する。３２はプログラムで、このプログラムには、鍵管理制御装置１５と同様の受信アプリケーション３２ａと、送信アプリケーション３２ｂが含まれる。ここでは受信アプリケーション３２ａ及び送信アプリケーション３２ｂを、説明の便宜上「受信側アプリ」という。
【００３８】
実施形態のプログラム３２は、両方のアプリケーション３２ａ、３２ｂを有しているが、変化点情報Ｐを受信する受信アプリケーション３２ａのみでも良い。このような実施形態の場合には、当然のことながら、権原端末装置１８又は／及び管理制御装置１５は、サーバ１７の変化点情報に関する変更台帳３６ａを参照（閲覧）するだけである。
【００３９】
しかしながら、望ましくは、権原端末装置１８又は／及び管理制御装置１５から変化点情報の要求があった場合には、通信回線１６を介して変化点情報に関する変更台帳の一部又は全部を「変化点情報に関するログ情報」として送信すれば便利なので、サーバ１７から受信済み変化点情報を送信する送信アプリケーション３２ｂを有する。この場合、権原端末装置１８又は／及び管理制御装置１５は、所定時間或いは所定期間（例えば１週間）を定めて変化点情報に関するログ情報を要求することができる。
【００４０】
ところで、３３はミドルウェア（いわば変化点情報を運ぶ運搬者或いは運搬車）３３ａを備えた変化点情報キューブ（いわば倉庫或いは受付場所）である。変化点情報キューブ３３には、多数の変化点情報Ｐ１、Ｐ２、Ｐ３…Ｐｎが一時的に保管される。そして、３４は受付時間等を設定するため、或いはミドルウェア３３ａが作動するためのタイマ、３５は前述した受信側アプリ３２の作動状況及び変化点情報制御部の制御状態（プロセスの生成、異常、終了等）を監視するプロセス監視部、３６は記憶部である。前記記憶部３６は、前述したように、変化点情報に関する「変更台帳３６ａ」を格納している。
【００４１】
ここで、図７及び図８を参照して、実施形態のキューイング手段（３３、３３ａ、３７）について説明する。なお、「先入れ先出しか」、それとも「後入れ先出しか」によってメモリー領域の呼び方が異なるものの、入力メッセージのキューイング手段は周知事項なので、ここでは便宜上、スタック領域３７或いはキュー部領域３７をそれぞれ概念的に図示する。
【００４２】
実施形態のキューイング手段は、変化点情報キュー３３に複数の変化点情報（経時的に先・後する変更鍵データ）が発生した場合、最も新しい鍵データを、例えば後入れ先出しリスト構造を持つスタック領域３７に「最新の変化点情報」として保有することができる。もちろん、図１０で示すようにキュー部領域３７に「最新の変化点情報」として保有することもできる。
【００４３】
図７は、例えばスタック領域３７（いわば倉庫からスタック３３ａを介して運ばれた最新情報を保持している場所）の基本的な概念図を示したものであり、一方、図８は受信側アプリ３２が変化点情報を受信した場合におけるＩＤ情報の変化点情報の流れを概略的に示したものである。
【００４４】
図７に於いて、スタック領域３７の中では、プッシュ（ｐｕｓｈ）された値が下から積み上げられている。ポップ（ｐｏｐ）をする時は、一番上に載っている値から取出される。したがって、今仮に、スタック領域３７に変化点情報Ｐ１とＰ２が保持されている場合に於いてポップ（ｐｏｐ）をする時は、「変化点情報Ｐ２」が、順次、又はタイマ３４が起動してから所定時間（例えば３０秒後、１分後、５分後など）に先入れ後出しとなり（左から３番目の図）、また今仮にスタック領域３７に「変化点情報Ｐ１」のみが保持されている場合に於いてポップ（ｐｏｐ）をする時は、「変化点情報Ｐ１」が出され、スタック領域３７はヌルデータ（ＮＵＬＬ）となる。スタック領域３７がヌルデータ（データがない状態）となれば、ミドルウェア３３ａは、変化点情報キュー３３から最新の変化点情報ｎを運びだし、スタック領域３７に入れる。
【００４５】
図８は変化点情報Ｐｎ（ＩＤ３、１０００００１３）が一番新しい最新の変化点情報であることを意味し、該変化点情報Ｐｎが、スタック（例えば運搬車）により、変化点情報キューブ（例えば保管庫）３３からスタック領域３７（最新情報を維持する場）に運ばれたことを示す。そして、実施形態では、最新情報として反映された変化点情報Ｐ１〜Ｐｎは、所定時間経過後に記憶部３６の変化点情報に関する「変更台帳（変更表）３６ａ」に記録される。
【００４６】
しかして、サーバ１７は、変化点情報Ｐを記憶部３６に格納する変更台帳３６ａを有するので、少なくとも権原端末装置１８又は鍵管理制御装置１５のいずれかは、所定時間経過後に通信回線１６を介してリアルタイムにサーバ１７が管理する変更台帳３６ａを参照し、最新の変化点情報が正しく反映されているか否かを確認或いは問い合わせすることができる。
【００４７】
最後に図９は、権原端末装置１８等の動作の具体例を示す説明図である。図９に於いて、左側がサーバ１７、右側が鍵管理制御装置１５、真中が権原端末装置１８である。例えば特定の建物の現場台帳と同じ情報も持っている業者（例えばＳＤ店）が前記権原端末装置１８を所持しているものとする。業者は、例えば建物の居住者（顧客）から鍵データを変更して欲しい旨の依頼があった場合、前記建物の鍵データを変更する権原を有する。
【００４８】
そこで、居住者（顧客）の前記建物の鍵データを変更し、これを変化点情報として鍵管理制御装置１５に通信回線を介して送信する（Ｓｔｅｐ１）。この実施形態では、他の業者（ＳＤ店）の権原端末装置１８との同期を回避するために、前記建物の鍵データを含む現場台帳を引出し、それを変更した後、鍵管理制御装置１５の現場台帳に戻す（いわゆる上書きする）ことはしない。したがって、管理制御装置１５は前記変化点情報のみを受信する（Ｓｔｅｐ２）。管理制御装置１５は変化点情報を受信した後、該変化点情報を現場台帳に登録する（Ｓｔｅｐ３）。そして、登録後、自動的に登録した旨（例えばテキストを含む）を、通信回線を介して業者（ＳＤ店）の権原端末装置１８に送信する。権原端末装置１８は前記登録した旨を受信することにより、変化点情報を確認することができる（Ｓｔｅｐ４）。
【００４９】
次に、権原端末装置１８は変化点情報を、通信回線を介してサーバ１７に送信（Ｓｔｅｐ５）し、サーバ１７は該変化点情報を受信する（Ｓｔｅｐ６）。この時、サーバ１７は鍵管理制御装置１５から通信回線を介して変化点情報を受信しても良い。変化点情報を受信したサーバ１７は、図８で示すキューイング手段（３３、３３ａ、３７）の動作を介して、最終的に記憶部の変更台帳３６ａに変化点情報を登録する（Ｓｔｅｐ７）。したがって、変更台帳３６ａは変化点情報のみを保存する。そこで、権原端末装置１８は所定時間（例えば１分）経過後に、通信回線を介してサーバ１７にアクセスし、変更台帳３６ａを参照（閲覧）することができる（Ｓｔｅｐ８）。また鍵管理制御装置１５も、所定時間経過後又は定期的に変更台帳に保存されている更新情報を問い合わせることができる（Ｓｔｅｐ９）。
【実施例】
【００５０】
本発明の実施形態は、特定の建物の複数の鍵データを、例えば業者（ＳＤ店）が所持している権原端末装置を用い、いわゆるメンテナンスする実施形態であるが、メンテナンス対象の情報は、住宅向け鍵管理システム、オフィス向け鍵管理システム、権原端末装置を用いる業者向け鍵管理システム、複数の部屋情報と共に該部屋情報用の鍵データを有する宿泊施設向け鍵管理システム、さらには、介護施設向け鍵管理システム等に適用することができる。
【産業上の利用可能性】
【００５１】
本発明は、例えば住宅向け鍵管理システムやオフィス向け鍵管理システムとして利用することができる。
【符号の説明】
【００５２】
Ｘ…通信回線における鍵データ制御システム、
１…所定範囲（区画された土地）、
２…建物、
３…ドア、４…電気錠、
５…電気錠制御装置、
６…電気錠制御装置の記憶部（ドアの鍵データを有する）、
１１…質問器、１２…応答器、
１５…鍵管理制御装置、
１６…通信回線、
１７…サーバ、
１８…権原端末装置、
Ｐ…変化点情報、
２１…鍵管理制御装置の制御部、
２４、２４Ａ…プログラム（送信側アプリケーション）、
２５…送受信部（インターフェイス）、
２６…タイマ、２７…プロセス監視部、
２８…鍵管理制御装置の記憶部、
２８ａ…現場台帳（一覧表）、
２８ｂ…鍵データの変化点情報に関するログ情報、
ａ…鍵管理制御装置の識別子、
ｂ…変化点情報（更新した鍵データ）の識別子、
ｃ…変化点情報の送信時間、
ｄ…通信パス（ソケットの指定）、
３１…サーバの制御部、
３２…プログラム（受信側アプリ）、
３３…変化点情報キューブ、３３ａ…ミドルウェア、
３４…タイマ、３５…プロセス監視部、
３６…記憶部、３６ａ…変更台帳（変更表）
３７…スタック領域又はキュー部領域。
【図１】
2016056635.tif 000003
【図２】
2016056635.tif 000004
【図３】
2016056635.tif 000005
【図４】
2016056635.tif 000006
【図５】
2016056635.tif 000007
【図６】
2016056635.tif 000008
【図７】
2016056635.tif 000009
【図８】
2016056635.tif 000010
【図９】
2016056635.tif 000011
【図１０】
2016056635.tif 000012