JP2011208397A - 解錠システム、解錠制御方法およびプログラム - Google Patents
解錠システム、解錠制御方法およびプログラム Download PDFInfo
- Publication number
- JP2011208397A JP2011208397A JP2010075914A JP2010075914A JP2011208397A JP 2011208397 A JP2011208397 A JP 2011208397A JP 2010075914 A JP2010075914 A JP 2010075914A JP 2010075914 A JP2010075914 A JP 2010075914A JP 2011208397 A JP2011208397 A JP 2011208397A
- Authority
- JP
- Japan
- Prior art keywords
- card
- information
- uid
- guest
- room
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】 クレジットカードを使用せずに複数のカードキー発行と同等の効果を発揮し得る技術を提供する。
【解決手段】 複数の部屋の鍵を、それぞれカードキー4を使用して解錠する解錠システムにおいて、前記複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段5と、カードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段11と、ユニークなIDコードが書き込まれたIDカード6の情報を登録可能なID登録手段7と、ID登録手段によって登録されたIDカードの情報を第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段11と、カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段12と、情報読み取り手段によって読み取られた情報と第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段9とを備える解錠システム。
【選択図】 図1
【解決手段】 複数の部屋の鍵を、それぞれカードキー4を使用して解錠する解錠システムにおいて、前記複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段5と、カードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段11と、ユニークなIDコードが書き込まれたIDカード6の情報を登録可能なID登録手段7と、ID登録手段によって登録されたIDカードの情報を第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段11と、カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段12と、情報読み取り手段によって読み取られた情報と第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段9とを備える解錠システム。
【選択図】 図1
Description
本発明は、解錠システム、解錠制御方法およびプログラムに関し、たとえば、ホテル等の宿泊施設に設置されているカード式の客室ドア解錠システムに用いて好適な解錠システム、解錠制御方法およびプログラムに関する。
ホテル等の宿泊施設(以下、単にホテルという。)の客室ドアは、その多くがオートロックであり、宿泊客は解錠操作(鍵を開ける操作)だけを行えばよいようになっている。また、ドアの「鍵」は、旧来の機械式に開閉できる式から、電気(電子)的に開閉することができる、いわゆる電気錠方式に移行しており、とりわけ不特定多数の客が出入りするホテル、旅館等の宿泊施設等においては、「カードキー」と呼ばれるカード型の電子キーが多用されている。これは、機械式施・解錠手段(例えば合鍵)に比べて単価が安いことに加え、紛失したり、客が持ち帰ったりした場合もデータを無効にするだけでよくからである。
このように固有の識別情報を持たせるカードキーに関する従来技術としては、たとえば、下記の特許文献1に記載のもの(以下、第1の従来技術という。)や下記の特許文献2に記載のもの(以下、第2の従来技術という。)が知られている。
第1の従来技術は、カードキー(特許文献1ではゲスト用キーカード20)の使用状況に応じて逐次に変化する特定のデータ(特許文献1ではキー使用状況コードKI)を用いてカードの有効/無効を判定するというものである。これによれば、仮に、カードキーを不正にコピーした複製カードが使用されたとしても、正規のカードと複製カードの「特定のデータ(キー使用状況コードKI)」は異なるので、入室の際に複製カードを判定して使用を禁止することができる。
ところで、この第1の従来技術にあっては、「カードキーの使用状況に応じて逐次に変化する特定のデータを用いてカードの有効/無効を判定する」という仕組みになっているので、1つの客室あたり1枚のカードしか発行できない。その理由について付言すると、複数のカードを発行した場合、入室を繰り返すたびに各カードの「特定のデータ(キー使用状況コードKI)」が相違することになり、その結果、あるカードでは入室できるが、他のカードでは入室できなくなる(不正な複製カードとみなされてしまう)という不都合を招くからである。
こうした複数枚のカード発行要求は、1つの客室を複数人で利用する際にしばしば発生する。例えば家族でホテルに泊まったとき、メインのゲストカードが1枚しかないない場合は、そのカードを誰か一人が持ったまま出かけてしまったとき、他の客(例えば子供、友人等)は部屋に入ることができなくなるからである。
この点において、第2の従来技術は、カードキーの代わりに「クレジットカード」を使用できるようにしているので、各人のクレジットカードを登録しておけば、すくなくとも前記の不都合(他の客は部屋に入ることができなくなる)を解消することができる。
しかしながら、第2の従来技術にあっては、「クレジットカードの情報(カード番号等)」を登録しなければならず、情報保全性の点で実用的でないという問題点がある。
しかしながら、第2の従来技術にあっては、「クレジットカードの情報(カード番号等)」を登録しなければならず、情報保全性の点で実用的でないという問題点がある。
これは、クレジットカードの番号はネット決済でも使われる大切な情報だからである。このため、たとえ、チェックインの際にホテル側から「クレジットカードをカードキーの代わりに登録しますか?」と問われても、大概の人は躊躇し、とりわけクレジットカードの取り扱いに慎重な人はおそらく拒否する筈だからである。
本願発明の所期の目的は、前述した第1及び第2の問題点に鑑み、例えば従来技術のクレジットカードを使用せずに、当該宿泊施設から受け取ったメインのゲストカードさえあれば、このゲストカードを利用して「複数のサブカード(ここではメインのゲストカードと同等の効果を発揮し得るIDを有する記憶媒体)」を作成できる技術を提供することである。
本発明の解錠システムは、複数の部屋の鍵を、それぞれカードキーを使用して解錠する解錠システムにおいて、前記複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段と、前記カードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段と、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録手段と、前記ID登録手段によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段と、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段と、前記情報読み取り手段によって読み取られた情報と前記第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段とを備えたことを特徴とする。
上記構成に於いて、第2の記憶手段は、ID登録手段によって登録された複数のIDカードの各々の情報またはそのIDカードと同等の機能が搭載された複数の携帯電子機器の各々の情報を第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶することを特徴とする。
また、一つの部屋に使用するカードキーの発行希望数を入力する第1の入力手段と、前記IDカードの登録予定数またはそのIDカードと同等の機能が搭載された携帯電子機器の登録予定数を入力する第2の入力手段とを備え、カードキー発行手段は、複数の部屋のうちの一つの部屋に関する情報を、第1の入力手段に入力された発行希望数から第2の入力手段に入力された登録予定数を減じた数に相当する枚数のカードキーに書き込んで発行することを特徴とする。
また、本発明の解錠制御方法は、複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行工程と、前記カードキー発行工程によって発行されたカードキーの情報を記憶する第1の記憶工程と、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録工程と、前記ID登録工程によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶工程で記憶されたカードキーの情報に紐付けして記憶する第2の記憶工程と、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り工程と、前記情報読み取り工程によって読み取られた情報と前記第1または第2の記憶工程で記憶された情報とを照合して部屋の鍵を開けるか否かを判定する判定工程とを含むことを特徴とする。
さらに、本発明のプログラムは、コンピュータに、複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段、前記カードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録手段、前記ID登録手段によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段、および、前記情報読み取り手段によって読み取られた情報と前記第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段としての機能を実現させるためのものである。
(a)本発明によれば、クレジットカードを使用せずに、複数のカードキー発行と同等の効果を発揮し得る技術を提供することができる。
(b)付言すると、ホテル、旅館等の宿泊施設の電気錠を備えた開閉体に対して、ゲストカードの他に、サブカードを増やしたい場合に、本発明の解錠システム、解錠制御方法およびプログラムを利用すると、複数のカードキー発行と同等の効果を発揮し得るサブカードを作成することができるので、例えば大人以外に一緒に宿泊する子供や友人に固有の情報を持ったサブカードを所持させることができる。
(b)付言すると、ホテル、旅館等の宿泊施設の電気錠を備えた開閉体に対して、ゲストカードの他に、サブカードを増やしたい場合に、本発明の解錠システム、解錠制御方法およびプログラムを利用すると、複数のカードキー発行と同等の効果を発揮し得るサブカードを作成することができるので、例えば大人以外に一緒に宿泊する子供や友人に固有の情報を持ったサブカードを所持させることができる。
以下、本発明の実施形態をホテルへの適用を例にして、図面を参照しながら説明する。図1は実施形態に係る解錠システムの全体構成図である。この図において、ホテルのフロント1には、キーボードやマウス等の操作部2および液晶ディスプレイ等の表示部3が設置されているとともに、カード型の電子キー(この実施形態ではゲストカード4と称する。)を発行するためのゲストカード発行部5と、UIDカード6の情報を読み取るためのUIDカード読み取り部7とが設けられている。
ここで、UIDカード6とは、UID(Unique Identification)コードやIDmコードと呼ばれる、全地球規模のユニーク性(唯一無二であること。)が保証されたIDコードが書き込まれたICチップ内蔵カード(単にIDカードということもある。)のことをいう。たとえば、我が国におけるFelica(フェリカ)カードやTaspo(タスポ)カードおよび一部のポイントカード、または、諸外国におけるMifare(マイフェア)カードなどがそのIDカードの実例である。
なお、これらの名称(Felica/Taspo/Mifare)は指定商品や指定役務によっては各社の登録商標である。
ICチップに書き込まれたIDコードはカードリーダ(実施形態ではUIDカード読み取り部7)で容易に読み取ることができるが、編集は不可である。
フロント1に設置されている前記各部(操作部2、表示部3、ゲストカード発行部5、UIDカード読み取り部7)は、フロント1またはホテル内の任意場所(たとえば、事務室等)に設置されたセンター処理部8に接続されている。
このセンター処理部8は、コンピュータ(以下、CPU9)を含むとともに、少なくとも、このCPU9で実行する制御プログラムを記憶したプログラム記憶部10と、後述のデータテーブル(図3参照)を記憶したデータテーブル記憶部11とを有して構成されており、プログラム記憶部10に記憶された制御プログラムをCPU9で実行することにより、前記フロント1に設置されている各部(操作部2、表示部3、ゲストカード発行部5、UIDカード読み取り部7)の動作を制御し、また、次に説明する客室側の動作を制御する。
複数の客室(ここでは説明の便宜上、101号室、102号室、‥‥‥、999号室とする。)の各々には、ゲストカード4やUIDカード6の情報を読み取ってその読み取り情報をセンター処理部8に出力できるカード読み取り部12と、図示しない客室ドアを自動で施錠し、また、センター処理部8からの制御信号に応答して解錠するドア施解錠部13とが設けられている。なお、図では101号室の構成しか示していないが、他の室も同様の構成を有している。
次に、作用を説明する。実施形態における作用の流れとその考え方の概略は、以下のとおりである。まず、ホテル側では、宿泊客のチェックインに際してゲストカード4を発行する。ゲースカード4の発行枚数は通常1枚であるが、宿泊客の同室人数によっては複数枚とすることもできる。
すなわち、1名(宿泊客Aのみ)の場合は当然ながら1枚のゲストカード4を発行すればよいが、もし、2名同室(宿泊客A、B)や3名同室(宿泊客A、B、C)などの場合は、同室全員分のゲストカード4を発行することが可能である。ただし、このような複数枚のゲストカード4の発行はコスト面からできれば避けたい。
実施形態のポイントの一つは、ゲストカード4を複数枚発行する必要に迫られたときに、所要枚数分のゲストカード4を発行するか(第一の選択肢)、または、複数のゲストカード4の発行と同等の効果を発揮し得る「他の方法(サブのカード)」を採用するか(第二の選択肢)をホテル側で任意に選択できるようにしたことにある。
ここで、「他の方法」とは、UIDカード6を利用した方法のことをいう。具体的には、同室宿泊客数をN人としたとき、そのN人全員にUIDカード6の所持を訪ね、たとえば、N人のうちのM人がUIDカード6を所持していると回答したとすると、N−M人分のゲストカード4を発行するとともに、残りのM人については、各々が所持しているUIDカード6をゲストカード4の代わりに使用できるように手続きすることをいう。
たとえば、図示の例では、3名の同室宿泊客A、B、CであるのでN=3となり、うち2名の宿泊客はUIDカード6を所持しているのでM=2となる。したがって、ホテル側で上記の「第二の選択肢」を選んだ場合、ゲストカード4は宿泊客Aの1枚(N−M枚)だけ発行すればよく、しかも、他の宿泊客B、Cについては各自のUIDカード6をゲストカード4の代わりに使用できるので、前記の第一の選択肢を選んだときと同等の効果(全員分のゲストカード4を発行したのと同等の効果)を得ることができるから、宿泊客に対しては利便性を、また、ホテル側に対してはコストメリットを与えることができる。
図2は、ゲストカード4とUIDカード6に書き込まれているデータを示す図である。ゲストカード4にはカードID、ホテルコード、部屋番号、使用期間、発行日などの情報が書き込まれおり、また、UIDカード6には少なくとも前述のUIDコードが書き込まれている。
ゲストカード4に書き込まれている情報は、チェックインの際にゲストカード発行部5によって書き込まれたものであり、カードIDはカードの固有識別情報、ホテルコードはホテルの固有識別情報、部屋番号は各部屋の識別情報、使用期間はその部屋の利用期間(宿泊期間)、発行日は当該カードの発行日の情報である。また、UIDカード6に書き込まれているUIDコードは、そのカードの製造時に編集不可の形で書き込まれたものである。
なお、ゲストカード4やUIDカード6の情報保持の仕組みについては特に限定しない。たとえば、カードに埋め込まれたICチップに情報を書き込む態様であってもよく、または、磁気的やその他の方法で情報を保持する態様であってもよい。要は、ゲストカード4およびUIDカード6のいずれも、各部屋のカード読み取り部12で情報を読み出すことができ、また、ゲストカード4についてはフロント1のゲストカード発行部5で所定の情報を書き込むことができ、さらに、UIDカード6についてはフロント1のUIDカード読み取り部7でその情報を読み出すことができる態様になっていればよい。
図3は、データテーブル記憶部11に記憶されているデータテーブルの概念構造図である。この図において、ゲストカードデータテーブル14は行列方式のデータベーステーブルであり、各行(レコード)を複数のフィールド、すなわち、カードIDフィールド14a、ホテルコードフィールド14b、部屋番号フィールド14c、使用期間フィールド14d、発行日フィールド14eなどに分けている。これらの各フィールドはゲストカード4に記憶された各情報(カードID、ホテルコード、部屋番号、使用期間、発行日)に対応しており、ゲストカード4を1枚発行するたびに新規レコードを追加し、そのレコードの各フィールド14a〜14eに、発行されたゲストカード4の情報(カードID、ホテルコード、部屋番号、使用期間、発行日)を格納するようになっている。
なお、ここでは、ゲストカード4を発行した後に、ゲストカードデータテーブル14に新規レコードを追加し、そのレコードにゲストカード4の情報を格納するとしているが、逆であってもかまわない。すなわち、ゲストカードデータテーブル14に新規レコードを追加し、そのレコードに情報(カードID、ホテルコード、部屋番号、使用期間、発行日)を格納した後、それらの情報をゲストカード4に書き込んでもよい。
UIDカードデータテーブル15も行列方式のデータベーステーブルであり、各行(レコード)を複数のフィールド、すなわち、UIDコードフィールド15a、部屋番号フィールド15b、使用期間フィールド15c、カードIDフィールド15dなどに分けている。先頭のUIDコードフィールド15aにはUIDカード6のUIDコードが格納され、また、末尾のカードIDフィールド15dには、そのUIDカード6に「紐付け」されたゲストカード4のカードIDが格納される。
ここで、「紐付け(ひもづけ)」とは、ある情報と他の情報とを関連付けすることをいう。たとえば、ゲストカードデータテーブル14の第1レコード(R1)から第3レコード(R2)の各々のカードIDフィールド14aに“0001”、“0002”、“0003”というカードIDが格納されていたと仮定し、UIDカードデータテーブル15の第1レコード(R1)のカードIDフィールド15dに“0001”というカードIDを格納した場合は、このカードID(“0001”)と同じ情報がゲストカードデータテーブル14の第1レコード(R1)に格納されているので、この場合、UIDカードデータテーブル15の第1レコード(R1)と、ゲストカードデータテーブル14の第1レコード(R1)とが「紐付け(関連づけ)」されたという。
また、UIDカードデータテーブル15の部屋番号フィールド15bと使用期間フィールド15cに、紐付け先レコードの同一情報(部屋番号と使用期間)が転記されるようになっている。
図4は、フロント1に設置された表示部3のインターフェース画面例を示す図である。この図において、第1のインターフェース画面16には、部屋番号を入力するためのテキストボックス17、同室利用人数を入力するためのテキストボックス18、利用期間の始まりと終わりをそれぞれ入力するためのテキストボックス19、20、および、次画面(第2のインターフェース画面22)への移動ボタン21などが適切なレイアウトで表示されている。フロント1の担当者は宿泊客のチェックインの際に、操作部2を用いて部屋番号や同室利用人数および利用期間を各テキストボックス17〜20入力した後、マウスを使用して次画面への移動ボタン21をクリックする。
次画面である第2のインターフェース画面22には、UIDカード登録操作エリア23、ゲストカード発行ボタン24および第1のインターフェース画面16に戻るための移動ボタン25などが適切なレイアウトで表示されている。
ここで、UIDカード登録操作エリア23には、UIDカード登録チェックボックス26と、UIDカード6の所有人数を入力するためのテキストボックス27と、UIDカード登録ボタン28とが設けられている。
これらの各部(UIDカード登録チェックボックス26、テキストボックス27、UIDカード登録ボタン28)は、通常、そのすべてが使用不可の状態(ダーク色で選択できない状態)になっているが、第1のインターフェース画面16の同室利用人数を入力するためのテキストボックス18に“2”以上の数が入力されたとき、すなわち、1室を複数人で利用するときに、UIDカード登録チェックボックス26が使用可能な状態(チェックを入れることができる状態)になり、さらに、UIDカード登録チェックボックス26にチェックが入れられたときに、UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28とがともに使用可能な状態になる。
すなわち、同室利用人数が“1名”のときは、第2のインターフェース画面22のUIDカード登録操作エリア23のすべてが使用不可状態となっており、この場合、第2のインターフェース画面22においては、ゲストカード発行ボタン24と移動ボタン25の二つしか操作できない。
これに対して、同室利用人数が“2名”以上のときは、ゲストカード発行ボタン24と移動ボタン25に加えて、UIDカード登録チェックボックス26も使用可能な状態になり、さらに、このUIDカード登録チェックボックス26にチェックを入れることによって、UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28も使用可能な状態になる。
したがって、このようなインターフェースにより、フロント1の担当者は、以下の選択的操作を行うことができるようになる。
<同室宿泊人数が1名のとき>
UIDカード登録操作エリア23のすべてが使用不可状態で、ゲストカード発行ボタン24が使用可能状態にある。このため、担当者は迷うことなくゲストカード発行ボタン24を操作してゲストカード4を発行することができる。この場合、ゲストカード4の発行数は1枚である。
UIDカード登録操作エリア23のすべてが使用不可状態で、ゲストカード発行ボタン24が使用可能状態にある。このため、担当者は迷うことなくゲストカード発行ボタン24を操作してゲストカード4を発行することができる。この場合、ゲストカード4の発行数は1枚である。
<同室宿泊人数が2名以上のとき>
UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28は使用不可状態にあるが、UIDカード登録チェックボックス26とゲストカード発行ボタン24は使用可能な状態にある。
UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28は使用不可状態にあるが、UIDカード登録チェックボックス26とゲストカード発行ボタン24は使用可能な状態にある。
このため、担当者は、同一宿泊者全員にゲストカード4を発行するのであれば、直ちにゲストカード発行ボタン24を操作して人数分のゲストカード4を発行すればよく、一方、ゲストカード4の代わりにUIDカード6を使用するのであれば、まず、UIDカード登録チェックボックス26にチェックを入れて、UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28とを使用可能状態にし、次いで、宿泊客から聞き取ったUIDカード6の所有人数をテキストボックス27に入力し、さらに、UIDカード登録ボタン28を押して所有人数分のUIDカード6の読み取り操作を行い、その後、ゲストカード発行ボタン24を操作すればよい。この場合、所要枚数(同室宿泊人数からUIDカード6の所有者数を引いた枚数)のゲストカード4が発行される。
このように、実施形態においては、必要に応じ、UIDカード6の情報を登録するとともに、そのUIDカード6の情報とゲストカード4の情報とを紐付けして管理するので、UIDカード6にゲストカード4と同等の解錠機能を与えることができ、宿泊者の利便性を向上しつつ、ホテル側のコスト削減も図ることができるという優れた効果が得られる。加えて、ケースバイケースで、同室宿泊者全員にゲストカード4を発行したり、同室宿泊者のうちUIDカード6を所有しない者だけにゲストカード4を発行したりできるから、ホテル側の接客対応を柔軟にできるという効果も得られる。
図5は、センター処理部8のCPU9で実行する制御プログラムのうち「チェックイン処理」に関する部分の動作フロー図である。このチェックイン処理では、まず、フロント1に設置されている表示部3に、図4の第1のインターフェース画面16を表示する(ステップS10)。そして、フロント1の担当者によって第1のインターフェース画面16に入力された情報(部屋番号や同室利用人数および利用期間)を取り込み、それらの情報に基づいて以下の処理を実行する。
まず、1室の利用人数Nが2名以上であるか否かを判定し(ステップS11)、2名以上でなければ、すなわち、1室1名の利用の場合は、ゲストカード発行部5を制御して1枚のゲストカード4を発行するとともに、その発行情報をゲストカードデータテーブル14に登録してプログラムを終了する。このとき、表示部3の第2のインターフェース画面22では前述のとおり、同室利用人数=1に対応してゲストカード発行ボタン24と移動ボタン25だけが使用可能になっているので、担当者は迷うことなくゲストカード発行ボタン24を押すことができ、誤操作を招かない。
一方、1室の利用人数Nが2名以上の場合は、次に、サブカードを発行するか否かを判定する(ステップS13)。ここで、“サブカード”とは、1室につき複数枚のゲストカード4を発行する場合の2枚目以降のゲストカード4のことをいい、または、ゲストカード4に紐付けして登録されたUIDカード6のことをいう。サブカードの枚数はケースバイケースで異なる。
表示部3に表示された第2のインターフェース画面22のUIDカード登録チェックボックス26は、1室の利用人数Nが2名以上の時に使用可能な状態になり、そして、フロント1の担当者によって、UIDカード登録チェックボックス26にチェックが入れられたときに、UIDカード6の所有人数を入力するためのテキストボックス27とUIDカード登録ボタン28とがともに使用可能な状態になる。したがって、ステップS13の判定結果がYESとなるのは、UIDカード登録チェックボックス26にチェックが入れられたとき、つまり、担当者によってサブカードの発行が選択されたときである。
ステップS13の判定結果がNOのとき、すなわち、UIDカード登録チェックボックス26にチェックが入れられなかったとき(サブカードを発行しないとき)は、担当者によるゲストカード発行ボタン24の操作に応答してゲストカード発行部5を制御し、1枚のゲストカード4を発行するとともに、その発行情報をゲストカードデータテーブル14に登録してプログラムを終了する。この場合、1室の利用人数Nは2名以上であるが、発行した1枚のゲストカード4は、N人のうちの代表者等に手渡すことになる。
一方、ステップS13の判定結果がYESのとき、すなわち、UIDカード登録チェックボックス26にチェックが入れられていたとき(サブカードを発行するとき)は、まず、第2のインターフェース画面22のテキストボックス27の情報(UIDカード所有人数M)を取り込み(ステップS14)、UIDカード所有人数Mが“0”であるか否かを判定する(ステップS15)。
そして、M=0の場合、すなわち、同室利用者全員がUIDカード6を所持していない場合は、担当者によるゲストカード発行ボタン24の操作に応答してゲストカード発行部5を制御し、同室利用者全員に行き渡るだけのN枚のゲストカード4を発行(ステップS16)するとともに、その発行情報をゲストカードデータテーブル14に登録してプログラムを終了する。
一方、M=0でない場合、すなわち、同室利用者(N人)のうちM人がUIDカード6を所持していた場合は、まず、担当者によるゲストカード発行ボタン24の操作に応答してゲストカード発行部5を制御し、同室利用者(N人)のうちUIDカード6の所持者(M人)を除く全員に行き渡るだけのN−M枚のゲストカード4を発行するとともに、その発行情報をゲストカードデータテーブル14に登録する(ステップS17)。次いで、UIDカード読み取り部7を制御してM枚のUIDカード6の情報(UIDコード)を読み取り(ステップS18)、その読み取った情報をUIDカードデータテーブル15に登録し、さらに、そのUIDカードデータテーブル15への登録情報と、ステップS17でゲストカードデータテーブル14に登録したゲストカード4の登録情報とを紐付け(ステップS19)してプログラムを終了する。
このように、このチェックイン処理によれば、1室1名利用の場合は1枚のゲストカード4を発行し、また、1室複数名の利用の場合は、全員分のゲストカード4を発行するか、あるいは、一部の者について代替カード(UIDカード6)を登録するとともに、残りの者についてゲストカード4を発行するか、を適宜に選択することができるから、ホテル側の対応を柔軟にすることができる。
図6は、センター処理部8のCPU9で実行する制御プログラムのうち「入室処理」に関する部分の動作フロー図である。この入室処理では、まず、客室ドアに設けられているカード読み取り部12でカード(ゲストカード4またはUIDカード6)を読み取る(ステップS21)。
次いで、そのカードがゲストカード4であるかUIDカード6であるかを判定し(ステップS22、ステップS28)、いずれのカードでもなければ、使用不可の間違った種類のカードであると判断してプログラムを終了する。
一方、ステップS22でゲストカード4が判定された場合は、ゲストカード有効/無効判定処理(ステップS23)を実行し、ステップS28でUIDカード6が判定された場合は、UIDカード有効/無効判定処理(ステップS29)を実行する。
なお、ゲストカード4であるかUIDカード6であるかの判定は、たとえば、カードのデータフォーマットから判定することが可能である。一般的に実施形態のゲストカード4のような宿泊施設用カードキーはシステム特有のデータフォーマットを有しているからであり、同様に、UIDカード6のようなフェリカカードやタスポカードまたはプリペイカードあるいはポイントカードにおいても同様にそのシステム特有のデータフォーマットを有しているからであり、両者のデータフォーマットは多くの場合、異なっているからである。ただし、実施形態の技術思想は、このような特定の判定方法(データフォーマットに基づくもの)に限定されない。カードの種類を区別できる方法であればいかなるものであってもかまわない。また、その判定の信頼性も多少不十分であってもよい。正規に使用できるカードであるか否かの最終判定は、後述するように、図7のゲストカード有効/無効判定処理や、図8のUIDカード有効/無効判定処理で確実に行っている(ゲストカードデータテーブル14やUIDカードデータテーブル15の登録情報との照合で行っている)からである。なお、ゲストカード有効/無効判定処理やUIDカード有効/無効判定処理の説明は後述する。
このようにして、ゲストカード有効/無効判定処理やUIDカード有効/無効判定処理を実行すると、次に、その判定結果に基づき、先にステップS21で読み取ったカードが使用可能な有効なカードであるか否かを判定する(ステップS24)。そして、有効なカードであると判定された場合は、ドア施解錠部13を駆動して客室ドアを解錠し(ステップS25)、入室するのに十分な時間(所定時間)を経過した後に(ステップS26のYES)、客室ドアを施錠(ステップS27)してプログラムを終了する。
図7は、ゲストカード有効/無効判定処理の動作フロー図である。このゲストカード有効/無効判定処理では、カードID一致判定(ステップS31)、ホテルコード一致判定(ステップS32)、部屋番号一致判定(ステップS33)、使用期間一致判定(ステップS34)、使用期間内判定(ステップS35)を順次に行い、すべての判定結果がYESの場合にカードの有効を最終判定(ステップS36)する一方、いずれか一つでもNOが判定された場合はカードの無効を判定する(ステップS37)。
ここで、「カードID一致判定」とは、図6のステップS21で読み取られたゲストカード4のカードIDと一致するデータが、図3のゲストカードデータテーブル14のカードIDフィールド14aに登録されているか否かを判定することをいう。
また、「ホテルコード一致判定」とは、図6のステップS21で読み取られたゲストカード4のホテルコードと一致するデータが、図3のゲストカードデータテーブル14の特定レコード(ステップS31でカードIDの一致が判定されたレコード)のホテルコードフィールド14bに登録されているか否かを判定することをいう。
同様に、「部屋番号一致判定」とは、図6のステップS21で読み取られたゲストカード4の部屋番号と一致するデータが、図3のゲストカードデータテーブル14の特定レコード(ステップS31でカードIDの一致が判定されたレコード)の部屋番号フィールド14cに登録されているか否かを判定すること、および、入室しようとする実際の部屋番号(カード読み取り部12ごとに設定されている)との一致を判定することをいう。
同様に、「使用期間一致判定」とは、図6のステップS21で読み取られたゲストカード4の使用期間と一致するデータが、図3のゲストカードデータテーブル14の特定レコード(ステップS31でカードIDの一致が判定されたレコード)の使用期間フィールド14cに登録されているか否かを判定することをいう。
また、「使用期間内判定」とは、図6のステップS21で読み取られたゲストカード4の使用期間内に現在日時が含まれているか否かを判定することをいう。
これらの判定により、カードIDが異なるゲストカード4(たとえば、データが存在しない使用済みのゲストカード4)を無効と判定でき、また、ホテルコードが異なる他ホテルのゲストカード4を無効と判定でき、また、間違った部屋への入室を回避でき、さらには、使用期間の過ぎたゲストカード4の使用を回避することができる。
図8は、UIDカード有効/無効判定処理の動作フロー図である。このUIDカード有効/無効判定処理では、まず、図3のUIDカードデータテーブル15を参照して、一致するUIDコードが登録されているか否かを判定する(ステップS41)。そして、一致するUIDコードが登録されていない場合は、使用できない未登録のUIDカード6(無効カード)であると判定(ステップS47)する一方、一致するUIDコードが登録されていた場合は、次に、そのUIDカード6に紐付けされたゲストカード4が存在するか否かを判定する(ステップS42)。
すなわち、図3のUIDカードデータテーブル15の該当レコードのカードIDフィールド15dに格納されているカードIDと同じデータが、図3のゲストカードデータテーブル14のカードIDフィールド14aに格納されているかを調べ、格納されていれば「紐付けされている」と判定し、格納されていなければ「紐付けされていない」と判定する。
そして、紐付けされていない場合は、使用できない未登録のUIDカード6(無効カード)であると判定し(ステップS47)、一方、紐付けされていた場合は、次に、UIDカード6の部屋番号および有効期間と、その紐付け先のゲストカード4の部屋番号および有効期間との一致を判定する(ステップS43)。
この一致判定は、図3のUIDカードデータテーブル15の該当レコードの部屋番号フィールド15bおよび使用期間フィールド15cに格納されているデータ(部屋番号および使用期間)と同じデータが、図3のゲストカードデータテーブル14の紐付け先レコードの部屋番号フィールド14cおよび使用期間フィールド14dに格納されているかどうかを調べることによって行う。
すなわち、同じデータが格納されていればステップS43の判定結果がYESとなり、そうでなければステップS43の判定結果がNOとなる。ステップS43の判定結果がNOの場合は、使用できないUIDカード6(無効カード)であると判定する(ステップS47)。
UIDコードが一致し、紐付けされたゲストカード4が存在し、且つ、そのゲストカード4の部屋番号と使用期間が一致していた場合は、次に、これから入室しようとする実際の部屋番号と、図3のUIDカードデータテーブル15の該当レコードの部屋番号フィールド15bに格納されている部屋番号とが一致するか否かを判定するとともに(ステップS44)、ステップS21で読み取られたUIDカード6の使用期間内に現在日時が含まれているか否かを判定し(ステップS45)、いずれかの判定結果がNOであれば使用できないUIDカード6(無効カード)であると判定する(ステップS47)一方、そうでなければ、使用可能なUIDカード6(有効カード)であると最終判定する(ステップS46)。
これらの処理により、UIDカードの有効/無効判定、すなわち、チェックインの際にゲストカード4の発行と一緒に登録されたUIDカード6であるか否かを判定することができ、有効と判定されたUIDカード6を用いてドアの解錠を行うことができる。
本発明では、上記構成を採用したので、以下の効果を得ることができる。図9は、実施形態の効果の説明図である。この図は、(a)1室1人利用のケース、(b)1室2人の利用でともにUIDカード6を所持しないケース、(c)は1室2人の利用で1人がUIDカード6を所持しているケース、(d)は1室α+β人利用でうちβ人がUIDカード6を所持しているケースをそれぞれ例示している。
まず、(a)のケースの場合、フロント1の担当者は、図4の第1のインターフェース画面16の同室利用人数に“1”を入力するとともに、その他の所要事項を入力してから移動ボタン21を押し、第2のインターフェース画面22を表示させる。この第2のインターフェース画面22では、上記の同室利用人数“1”に対応して、UIDカード登録操作エリア23が使用不可状態のままになっているため、担当者は迷わず使用可能状態のゲストカード発行ボタン24を押すこととなり、これにより、1人分のゲストカード4を発行することができる。
次に、(b)のケースの場合は、宿泊客に聞いたところ、いずれもUIDカード6を所持していないことがわかり、且つ、複数カードの発行を希望していたので、担当者は次の操作を行う。すなわち、第1のインターフェース画面16の同室利用人数に“2”を入力するとともに、その他の所要事項を入力してから移動ボタン21を押し、第2のインターフェース画面22を表示させる。この第2のインターフェース画面22では、上記の同室利用人数“2”に対応して、UIDカード登録操作エリア23のUIDカード登録チェックボックス26が使用可能状態になっているが、宿泊客のいずれもUIDカード6を所持していないので、UIDカードの登録は行わず、担当者は上記の(a)と同様にゲストカード発行ボタン24を押すことになる。(a)との違いは、同室利用人数(2人)分のゲストカード4を発行する点にある。
次に、(c)のケースの場合は、同室利用者2人のうち1人がUIDカード6を所持しており、且つ、複数カードの発行を希望していたので、担当者は次の操作を行う。すなわち、第1のインターフェース画面16の同室利用人数に“2”を入力するとともに、その他の所要事項を入力してから移動ボタン21を押し、第2のインターフェース画面22を表示させる。この第2のインターフェース画面22では、上記の同室利用人数“2”に対応して、UIDカード登録操作エリア23のUIDカード登録チェックボックス26が使用可能状態になっているので、担当者はUIDカード登録チェックボックス26にチェックを入れる。これにより、UIDカード所有人数入力用のテキストボックス27と、UIDカード登録ボタン28が使用可能状態になるので、担当者はUIDカード所有人数として“1”を入力した後、UIDカード登録ボタン28を押してUIDカード6の登録を行い、ゲストカード発行ボタン24を押して残り1人分のゲストカード4を発行する。
次に、(d)のケースの場合は、同室利用者α+βのうちβ人がUIDカード6を所持しており、且つ、複数カードの発行を希望していたので、担当者は次の操作を行う。すなわち、第1のインターフェース画面16の同室利用人数に“β”(ただし、ベータは任意の整数)を入力するとともに、その他の所要事項を入力してから移動ボタン21を押し、第2のインターフェース画面22を表示させる。この第2のインターフェース画面22では、上記の同室利用人数“α+β”に対応して、UIDカード登録操作エリア23のUIDカード登録チェックボックス26が使用可能状態になっているので、担当者はUIDカード登録チェックボックス26にチェックを入れる。これにより、UIDカード所有人数入力用のテキストボックス27と、UIDカード登録ボタン28が使用可能状態になるので、担当者はUIDカード所有人数として“β”を入力した後、UIDカード登録ボタン28を押してUIDカード6の登録を行い、ゲストカード発行ボタン24を押して残りα人分のゲストカード4を発行する。
このように、実施形態では、ゲストカード4と同等の解錠機能を有する代替カードとしてUIDカード6を登録することができるので、仮にゲストカード4を持ったまま誰かが出かけてしまっても、他の同室者は自分または他の同室者のUIDカード6を使用して部屋に入ることができるから、複数の宿泊者で1室を利用する際の不都合を回避することができ、同室利用者の利便性を向上することができる。
また、1室複数人宿泊の場合で、且つ、宿泊者から複数カードの発行を求められた場合は、全員にゲストカード4を発行する、UIDカード6の所有者以外の宿泊者分だけゲストカード4を発行する、といった柔軟な対応が可能となるから、ホテル側の対処幅を広げることができる。
また、今日ではフェリカカードやタスポカードのようなUIDカード6が広く普及していることから、老若男女問わず、かなりの確率でUIDカード6を所持しているといえる。このため、宿泊者から複数カードの発行を求められた場合には、UIDカード6の所有人数分だけゲストカード4の発行枚数を減らすことができ、ホテル側にコストメリットを与えることができる。
ここで、クレジットカードは、IDコードに相当する情報(カード番号)を持つ点で実施形態のUIDカード6と類似しているが、このクレジットカードは、特定の者(つまり、口座所有者)しか所持しないうえ、カード番号だけでネット決済できる大切なカードである点で、フェリカカードやタスポカードまたは特定のポイントカードのようなUIDカード6と相違する。
したがって、UIDカード6は、クレジットカードに比べて取り扱いにそれほどの慎重さを要する必要がないから、ホテル側から「お持ちのUIDカード6を登録しますか?」と聞かれた場合に誰でも躊躇なく手軽に差し出すので、実用上、何の不都合も生じない。
なお、以上の実施形態では、UIDカードデータテーブル15にUIDカード6の情報を登録しているが、使用期間を過ぎた情報の保持は個人情報保護の観点から好ましくない。
図10は、情報削除の動作フロー図である。この動作フローは、たとえば、1日に一回定期的に実行されるバッチ処理になっており、ゲストカードデータテーブル14を参照(ステップS51)して有効期間を過ぎた(使用期間を超過した)レコードをすべて削除(ステップS52)するとともに、同様に、UIDカードデータテーブル15を参照(ステップS53)して有効期間を過ぎた(使用期間を超過した)レコードをすべて削除(ステップS54)するというものであり、これにより、不要になったゲストカード4とUIDカード6のデータを一括削除するというものである。
このようにすると、無用な個人情報がシステムに残らないので、データ漏出等の事故発生を未然に防止することができる。
また、実施形態では、UIDカード6の登録をチェックイン時にフロント1で行っているが、この態様に限定されない。たとえば、チェックインの際に行わず、部屋に入室する際に行うようにしてもよい。
図11は、図6の入室処理の変形例を示す図である。この図において、図6の入室処理との相違は、ステップS26のNO判定の後に、新たなステップS61〜ステップS64を追加したことにある。
これらのステップS61〜ステップS64の内容は図示のとおりであるが、ステップS61〜ステップS64の全体の意味は、以下のとおりである。
まず、これらのステップS61〜ステップS64におけるポイントは、UIDカード6の読み取り判定(ステップS62)と、その読み取ったデータの紐付け処理(ステップS63)にあり、要するに、部屋のカード読み取り部12で読み取ったUIDカード6のデータを、チェックイン時に発行されたゲストカード4のデータに紐付けする点がポイントである。
少なくとも、これらの処理(ステップS62とステップS63)を行うだけで、前記の実施形態と同様に、図3のUIDカードデータテーブル15とゲストカードデータテーブル14との関連づけ(紐付け)を行うことができ、したがって、チェックインの際ではなく部屋に入室する際にUIDカード6の登録を行うことができるから、フロント1の担当者の手を煩わす必要がない。
また、ステップS61の条件(ドア開?)は安全のための対策である。すなわち、このステップS61がない場合は、たとえば、正規のゲストカード4を使って部屋に入ってドアを閉めた直後に、悪意を持った第三者に廊下側からカード読み取り部12にUIDカード6を差し込まれる可能性を否定できないからである。
これに対処するには、ドアを開いている状態の時だけに、UIDカード6の読み取りを許容すればよい。ステップS61はそのための付加条件である。なお、ドアの“開”検出は、たとえば、ドア施解錠部13にドア開センサを設けて行ってもよく、あるいは、ドアの蝶番等に同様のセンサを設けて行ってもよい。
また、ステップS64の「所定時間を延長する」という処理は、UIDカード6を登録する際の操作時間を考慮したものであり、「所定時間」は、ステップS26における判定時間(施錠するまでの待ち時間)のことである。このステップS64を入れることにより、UIDカード6の登録中にステップS26の判定時間(施錠するまでの待ち時間)を延長することができ、登録途中でドアが不本意に施錠されるという不都合を回避できる。
また、実施形態では、発行済みのゲストカード4や登録済みのUIDカード6のデータ管理をセンター処理部8で集中して行っているが、これに限定されない。たとえば、以下のように部屋ごとに分散して行ってもよい。
図12は、他の実施形態の要部構成図である。この図は各部屋の構成を示しており、前記実施形態との相違はカード読み取り部12およびドア施解錠部13のほかに、部屋端末処理部29とデータ記憶部30とを有する点にある。部屋端末処理部29は、たとえば、マイクロコンピュータで構成されており、この部屋端末処理部29は、センター処理部8から適宜に送られてくる、その部屋専用のゲストカード4の情報(カードID、ホテルコード、部屋番号、使用期間、発行日)と同じくその部屋専用のGUIカード4の登録情報(UIDコード)とをデータ記憶部30に記憶するとともに、宿泊客によるカード読み取り操作(ゲストカード4またはUIDカード6のデータをカード読み取り部12に読み取らせる操作)に応答して、前記図6の「入出処理」と類似の入室処理を実行することにより、読み取らせたカード(ゲストカード4またはUIDカード6)の有効/無効を判定し、有効と判定されたときにドア施解錠部13を制御してドアの解錠を行うというものである。
“類似の入室処理”とは、図6の「入室処理」のステップS23およびステップS29の代わりに、以下の処理を実行することを意味する。
<ステップS23の置き換え>
宿泊客の使用カードがゲストカード4の場合に、データ記憶部30からゲストカード4の情報(カードID、ホテルコード、部屋番号、使用期間、発行日)を読み出し、それらの情報と、宿泊客が使用したゲストカード4の情報との照合をとり、一致した場合に有効カードと判定する。
宿泊客の使用カードがゲストカード4の場合に、データ記憶部30からゲストカード4の情報(カードID、ホテルコード、部屋番号、使用期間、発行日)を読み出し、それらの情報と、宿泊客が使用したゲストカード4の情報との照合をとり、一致した場合に有効カードと判定する。
<ステップS28の置き換え>
宿泊客の使用カードがUIDカード6の場合に、データ記憶部30からUIDカード6の情報(UIDコード)を読み出し、その情報と、宿泊客が使用したUIDカード6の情報との照合をとり、一致した場合に有効カードと判定する。
宿泊客の使用カードがUIDカード6の場合に、データ記憶部30からUIDカード6の情報(UIDコード)を読み出し、その情報と、宿泊客が使用したUIDカード6の情報との照合をとり、一致した場合に有効カードと判定する。
このようにしても、前記実施形態と同様に有効カードと無効カードの判定を行うことができる。
ところで、図12の例では、ゲストカードデータテーブル14やGUIカードデータテーブル15を使用しないので、これらのテーブルのレコード同士の関連づけ(“紐付け”)という概念はない。しかしながら、この図12の例では、「部屋端末処理部29は、センター処理部8から適宜に送られてくる、その部屋専用のゲストカード4の情報(カードID、ホテルコード、部屋番号、使用期間、発行日)と同じくその部屋専用のGUIカード4の登録情報(UIDコード)とをデータ記憶部30に記憶する」という仕組みを有しているので、ホテル全体でみた場合、全ての部屋のデータ記憶部30には、各部屋専用の二つの情報(ゲストカード4の情報とGUIカード4の情報)が記憶されることとなり、それら各部屋専用の二つの情報は、部屋番号をキーにして関連づけられているから、やはり、前記実施形態と同様に情報の紐付けという概念を有している。
本実施例ではホテル等の宿泊施設への適用を例にしたが、これに限らない。少なくとも、カード型の電子キーを使用して部屋の鍵を開けるとともに、一つの部屋に複数の電子キーを割り当てる(または貸し出す)可能性がある様々な用途に適用できる。また、UIDカード6を例にしたが、これに限らない。UIDカード6と同等の機能(たとえば、フェリカ機能など)を搭載した携帯電話機等の携帯電子機器をUIDカード6の代わりに用いてもよい。
錠前や建具の技術分野、特に、ホテル、旅館等の宿泊施設の開閉体に電気錠を備えた管理システムに利用される。
4…ゲストカード(カードキー)、5…ゲストカード発行部(カードキー発行手段)、6…UIDカード(IDカード)、7…UIDカード読み取り部(ID登録手段)、9…CPU(判定手段、コンピュータ)、10…データテーブル記憶部(第1の記憶手段、第2の記憶手段)、12…カード読み取り部(情報読み取り手段)、18…テキストボックス(第1の入力手段)、27…テキストボックス(第2の入力手段)、29…部屋端末処理部(判定手段、コンピュータ)、30…データ記憶部(第1の記憶手段、第2の記憶手段)。
Claims (5)
- 複数の部屋の鍵を、それぞれカードキーを使用して解錠する解錠システムにおいて、前記複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段と、前記カードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段と、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録手段と、前記ID登録手段によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段と、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段と、前記情報読み取り手段によって読み取られた情報と前記第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段とを備えたことを特徴とする解錠システム。
- 請求項1に於いて、第2の記憶手段は、ID登録手段によって登録された複数のIDカードの各々の情報またはそのIDカードと同等の機能が搭載された複数の携帯電子機器の各々の情報を第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶することを特徴とする解錠システム。
- 請求項1に於いて、一つの部屋に使用するカードキーの発行希望数を入力する第1の入力手段と、IDカードの登録予定数またはそのIDカードと同等の機能が搭載された携帯電子機器の登録予定数を入力する第2の入力手段とを備え、カードキー発行手段は、複数の部屋のうちの一つの部屋に関する情報を、前記第1の入力手段に入力された発行希望数から第2の入力手段に入力された登録予定数を減じた数に相当する枚数のカードキーに書き込んで発行することを特徴とする解錠システム。
- 複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行工程と、このカードキー発行工程によって発行されたカードキーの情報を記憶する第1の記憶工程と、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録工程と、このID登録工程によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶工程で記憶されたカードキーの情報に紐付けして記憶する第2の記憶工程と、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り工程と、この情報読み取り工程によって読み取られた情報と前記第1または第2の記憶工程で記憶された情報とを照合して部屋の鍵を開けるか否かを判定する判定工程とを含むことを特徴とする解錠制御方法。
- コンピュータに、複数の部屋のうちの一つの部屋に関する情報をカードキーに書き込んで発行するカードキー発行手段、このカードキー発行手段によって発行されたカードキーの情報を記憶する第1の記憶手段、ユニークなIDコードが書き込まれたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を登録可能なID登録手段、このID登録手段によって登録されたIDカードの情報またはそのIDカードと同等の機能が搭載された携帯電子機器の情報を前記第1の記憶手段に記憶されているカードキーの情報に紐付けして記憶する第2の記憶手段、前記カードキーの情報または前記IDカードの情報もしくはそのIDカードと同等の機能が搭載された携帯電子機器の情報を読み取る情報読み取り手段及び該情報読み取り手段によって読み取られた情報と前記第1または第2の記憶手段に記憶されている情報とを照合して部屋の鍵を開けるか否かを判定する判定手段としての機能を実現させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010075914A JP2011208397A (ja) | 2010-03-29 | 2010-03-29 | 解錠システム、解錠制御方法およびプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010075914A JP2011208397A (ja) | 2010-03-29 | 2010-03-29 | 解錠システム、解錠制御方法およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011208397A true JP2011208397A (ja) | 2011-10-20 |
Family
ID=44939723
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010075914A Pending JP2011208397A (ja) | 2010-03-29 | 2010-03-29 | 解錠システム、解錠制御方法およびプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011208397A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105869238A (zh) * | 2016-03-24 | 2016-08-17 | 深圳市前海铂智科技有限公司 | 一种基于微信平台的门禁系统及微信控制方法 |
CN108288317A (zh) * | 2018-01-17 | 2018-07-17 | 北京锐拓时代科技有限公司 | 通过云端解码实现身份认证的无人值守酒店管理系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0666058A (ja) * | 1992-08-17 | 1994-03-08 | Toppan Printing Co Ltd | ホテル客室のロックシステム |
JP2005048534A (ja) * | 2003-07-31 | 2005-02-24 | Nippon Conlux Co Ltd | ドア開錠方法および装置 |
-
2010
- 2010-03-29 JP JP2010075914A patent/JP2011208397A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0666058A (ja) * | 1992-08-17 | 1994-03-08 | Toppan Printing Co Ltd | ホテル客室のロックシステム |
JP2005048534A (ja) * | 2003-07-31 | 2005-02-24 | Nippon Conlux Co Ltd | ドア開錠方法および装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105869238A (zh) * | 2016-03-24 | 2016-08-17 | 深圳市前海铂智科技有限公司 | 一种基于微信平台的门禁系统及微信控制方法 |
CN108288317A (zh) * | 2018-01-17 | 2018-07-17 | 北京锐拓时代科技有限公司 | 通过云端解码实现身份认证的无人值守酒店管理系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9430892B2 (en) | Locker rental system using external codes | |
AU2021215295A1 (en) | Electronic locker right acquisition via an external system | |
US20040021552A1 (en) | Method, device, and system for door lock | |
TWI414669B (zh) | Out of the room management system and out of the room management methods | |
TWI386870B (zh) | Out of the room management system, out of room management methods, and reception device | |
WO2011033839A1 (ja) | 資産管理システム | |
JP5369364B2 (ja) | Id管理装置、id管理システム、id管理方法 | |
CN112714928A (zh) | 受理终端机 | |
JP2011208397A (ja) | 解錠システム、解錠制御方法およびプログラム | |
JP4660097B2 (ja) | 保管ケース管理システム | |
JPH07225879A (ja) | 暗証番号入力式貸しロッカーシステム及び装置 | |
JP2002211717A (ja) | 図書館システム | |
JP6825742B1 (ja) | 施設利用管理システム、施設利用管理方法、及びプログラム | |
JP7364223B2 (ja) | 電子錠システム、電子錠システムで実行される方法、携帯端末、携帯端末で実行される方法、並びにコンピュータプログラム | |
JP4669693B2 (ja) | 入場管理システムおよび入場管理方法 | |
JP6943307B2 (ja) | 施設利用管理システム、施設利用管理方法、及び施設利用管理プログラム | |
US20200380424A1 (en) | Information processing apparatus, reservation system, and non-transitory computer readable medium storing program | |
JP6175755B2 (ja) | 管理装置、プログラム及びカード管理システム | |
JPH0562393B2 (ja) | ||
JP4532962B2 (ja) | 出入管理システム | |
JP2004092057A (ja) | 入退出管理システム | |
JP2012077590A (ja) | エフイー・ロック鍵管理システム | |
JP5272352B2 (ja) | 部屋予約管理システム、入出管理装置、及び装置プログラム | |
JP7230583B2 (ja) | 記憶装置管理システム | |
JP2010144396A (ja) | 入退室管理システム、入退室管理方法、および受付装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130327 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140610 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20141021 |