JP6594285B2 - ロッカー管理システム及びロッカー管理方法 - Google Patents

Description

本発明は、ロッカー管理システム及びロッカー管理方法に関する。

従来、駅、商業施設及びアミューズメントパーク等には、コインを投入すると使用できるコインロッカー（以下単に「ロッカー」という場合もある。）が設置される。そして、ロッカーを管理する方法は、例えば、以下のような方法がある。

例えば、コインロッカーが、複数の管理者によって運営される場合がある。まず、ロッカーネットワークシステムでは、ロッカーを識別するロッカーＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と、ロッカーコーナーＩＤと、ロッカーを施錠する鍵を識別する鍵ＩＤとが関連付けされて保持される。次に、これらのＩＤが、無線タグによる非接触通信によって送受信される。このようにして、グループごとに、ロッカーコーナーの稼働状況を示すロッカー情報が収集される。これにより、複数の管理者間で、シームレスな連携を行う方法が知られている（例えば、特許文献１等）。

また、施錠可能な複数の納品庫を有するストッカをストッカ管理装置が管理する方法が知られている。具体的には、まず、ストッカに対応して配置されるビーコン装置が、ビーコン信号を発信する。次に、ビーコン信号が受信されると、携帯端末は、位置情報を計算する。そして、親装置は、携帯端末から会員ＩＤを受信すると、会員ＩＤを判定して、納品庫を開錠する。このようにして、ユーザの利便性を向上させる方法が知られている（例えば、特許文献２等）。

他にも、インターネット網に接続されるロッカー管理サーバによって、複数のロッカー装置を管理する方法が知られている。具体的には、まず、所定タイミングで空きロッカー情報が生成される。さらに、金銭情報が、空きロッカー情報とは別に生成される。このようにして、広域におけるロッカーの空き情報を効率的に管理する方法が知られている（例えば、特許文献３等）。

特開２００６−２８５６５８号公報 特開２０１６−１３４１３８号公報 特許第５９１７８９１号公報

しかしながら、従来の方法では、管理対象となっているロッカーを改修又は入れ替え等する場合には、鍵を用いるロッカーの運用を停止させなければならない場合がある。

本発明の１つの側面は、このような問題に鑑みてなされたものであり、既設鍵式ロッカーを閉鎖、改修又は機種変更をすることなく、空き数等の情報を収集する電子化に対応させることを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一実施形態における、鍵に付帯される送信器と、前記送信器による送信を受信する受信器と、前記受信器とネットワークを介して接続される１以上の情報処理装置とを有するロッカー管理システムでは、
前記送信器は、
前記鍵を識別できる鍵データを前記受信器に送信する送信部を有し、
前記受信器は、
前記鍵データを受信する受信部と、
前記鍵データを受信した受信強度を取得する取得部とを有し、
前記情報処理装置は、
前記鍵データと、前記受信強度とを対応させた受信データを入力する入力部と、
前記鍵が所定範囲に存在すると判断する前記受信強度の閾値を含み、前記鍵と対応するロッカーを識別するロッカーデータを記憶する記憶部と、
前記受信データの前記受信強度と、前記ロッカーデータが示す前記閾値とを比較し、前記鍵データに基づいて識別される全てのロッカーの空き状態を判定し、空きロッカーの数を算出する算出部と、
外部装置に空きロッカー数を含む空きロッカー情報を出力する出力部と
を含む。

本発明によれば、管理対象となっているロッカーを閉鎖、改修又は機種変更をすることなく、空き数等の情報を収集する電子化に対応させることができる。

本発明の実施形態におけるロッカー管理システムが管理対象とするロッカーの例を示す図である。 本発明の実施形態において使用される鍵の構成例を示す外観図である。 本発明の実施形態におけるロッカー管理システムが有する受信器等の配置例を示す図である。 本発明の実施形態におけるロッカー管理システムが有する情報処理装置のハードウェア構成の一例を示すブロック図である。 本発明の実施形態におけるロッカー管理システムによる全体処理の一例を示すシーケンス図である。 本発明の実施形態におけるロッカー管理システムが有する情報処理装置による処理の一例を示すフローチャートである。 本発明の実施形態におけるロッカー管理システムが記憶するロッカーデータの一例を示す表である。 本発明の実施形態におけるロッカー管理システムが入力する受信データの一例を示す表である。 本発明の実施形態におけるロッカー管理システムがロッカーの空き状態を判定した結果の一例を示す表である。 本発明の実施形態におけるロッカー管理システムがサイズごと及びグループごとにロッカーの空き状態を算出した結果の一例を示す表である。 本発明の実施形態におけるロッカー管理システムの機能構成の一例を示す機能ブロック図である。

本発明の実施形態を以下の順序で説明する。

１．ロッカー管理システムの全体構成例
２．ロッカー管理システムによる全体処理例
３．ロッカー管理システムの機能構成例

≪ １．ロッカー管理システムの全体構成例 ≫
図１は、本発明の実施形態におけるロッカー管理システムが管理対象とするロッカーの例を示す図である。例えば、本発明の実施形態におけるロッカー管理システムは、図示するような複数のロッカーを管理する。具体的には、図示するように、第１ロッカーＬＣＫ１乃至第９ロッカーＬＣＫ９のような、９つのロッカーがあるとする。そして、図示する第１ロッカーＬＣＫ１乃至第９ロッカーＬＣＫ９が、１つのグループＧＲであるとする。

また、各ロッカーは、サイズが３種類であるとする。具体的には、図示するように、上段に設置される第１ロッカーＬＣＫ１、第４ロッカーＬＣＫ４及び第７ロッカーＬＣＫ７は、３種類のうち、最も小さいサイズとなる「小」サイズであるとする。さらに、図示するように、中段に設置される第２ロッカーＬＣＫ２、第５ロッカーＬＣＫ５及び第８ロッカーＬＣＫ８は、「小」サイズより大きいサイズであり、かつ、「大」サイズより小さいサイズとなる「中」サイズであるとする。また、図示するように、下段に設置される第３ロッカーＬＣＫ３、第６ロッカーＬＣＫ６及び第９ロッカーＬＣＫ９は、３種類のうち、最も大きいサイズとなる「大」サイズであるとする。

そして、各ロッカーには、それぞれのロッカーが有する扉を施錠及び解錠できる鍵が存在する。具体的には、第１ロッカーＬＣＫ１に対して、第１鍵ＫＥＹ１が対応する。すなわち、第１鍵ＫＥＹ１を用いると、ユーザは、第１ロッカーＬＣＫ１が有する扉を解錠して、第１ロッカーＬＣＫ１に荷物を収納したり、又は、第１ロッカーＬＣＫ１から荷物を取り出したりすることができる。さらに、第１鍵ＫＥＹ１を用いると、ユーザは、第１ロッカーＬＣＫ１に荷物を収納した後、施錠し、荷物を第１ロッカーＬＣＫ１に預けることができる。

一方で、第１ロッカーＬＣＫ１に対して、第１鍵ＫＥＹ１でない鍵、例えば、第２ロッカーＬＣＫ２用の鍵等を用いても、ユーザは、第１ロッカーＬＣＫ１が有する扉を施錠及び解錠することはできない。このようにして、各ロッカーが有する扉と、対応する鍵とが一対となる。

また、鍵は、例えば、以下のような構成で使用される。

図２は、本発明の実施形態において使用される鍵の構成例を示す外観図である。例えば、鍵ＫＥＹは、図２（Ａ）に図示するように、鍵本体と、鍵本体にリング等によって取り付けられる送信器ＴＲとで構成される。

そして、送信器ＴＲは、あらかじめ設置される受信器ＲＥに、鍵ＫＥＹを識別できる鍵ＩＤを示すデータ（以下「鍵データ」という。）を送信する。

また、鍵ＫＥＹは、以下のような構成でもよい。例えば、鍵ＫＥＹは、図２（Ｂ）に図示するように、送信器ＴＲとなる電子回路基板が鍵本体に埋め込まれる構成等でもよい。このような構成でも、図２（Ａ）と同様に、送信器ＴＲは、鍵データを受信器ＲＥに送信することができる。

図示するように、リング又は埋め込みによって、送信器ＴＲを鍵本体に付帯させると、運用中であっても、鍵に送信器ＴＲを取り付けやすい。

すなわち、送信器ＴＲ及び受信器ＲＥによって、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｅｒ）等の無線通信が実現される。例えば、無線通信の方式は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の規格に準ずる方式等である。

具体的には、鍵ＫＥＹに、鍵データを送信するＲＦタグ、すなわち、送信器ＴＲが付帯される。そして、受信器ＲＥは、送信器ＴＲから送信される鍵データを受信する。このようにして、送信器ＴＲは、いわゆるビーコン（ｂｅａｃｏｎ）によって、受信器ＲＥに鍵データ等のデータを送信する。

なお、送信器ＴＲは、電池等が内蔵され、送信を能動的に行うのが望ましい。すなわち、送信器ＴＲは、いわゆるアクティブタグであるのが望ましい。このように、送信器ＴＲがアクティブタグであると、パッシブタグと比較して、通信可能な距離を長くすることができる。そのため、受信器を設置する数を少なくできる場合もある。また、送信器ＴＲがアクティブタグであると、パッシブタグと比較して、大きさを小さくすることができる。

さらに、送信器ＴＲは、定期的に送信を行うのが望ましい。例えば、送信器ＴＲは、１０秒に１度程度の間隔で、鍵データを定期的に送信する。なお、送信する周期は、例えば、電池の寿命等に基づいて、設定されてもよい。

また、受信器ＲＥは、送信器ＴＲからの送信を受信する際に、受信強度（ＲＳＳＩ、Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）を計測して、受信強度を取得することができる。

以上のような送信器ＴＲを付帯した鍵ＫＥＹ及び受信器ＲＥは、例えば、以下のように配置して用いられる。

図３は、本発明の実施形態におけるロッカー管理システムが有する受信器等の配置例を示す図である。例えば、図示するように、２台の受信器を配置する例で以下説明する。

具体的には、第１受信器ＲＥ１（図示する例では、左側に配置された受信器である。）と、第２受信器ＲＥ２（図示する例では、右側に配置された受信器である。）とが、図示するように配置されたとする。なお、ロッカー管理システムが有する受信器の数は、１台でも、３台以上でもよい。

第１受信器ＲＥ１は、第１範囲ＲＡ１内にある送信器から、それぞれの鍵データを受信する。そして、第１受信器ＲＥ１は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークＮＷを介して、情報処理装置の例であるサーバ１０に、データを送信する。

同様に、第２受信器ＲＥ２は、第２範囲ＲＡ２内にある送信器から、それぞれの鍵データを受信する。そして、第２受信器ＲＥ２も、ネットワークＮＷを介して、サーバ１０に、データを送信する。

一方で、ロッカーが施錠され、ユーザが鍵を持って移動すると、送信器と、受信器との距離は、長くなり、受信強度が下がる。そして、鍵が第１範囲ＲＡ１範囲外に移動すると、第１受信器ＲＥ１は、ユーザが持って行った鍵に付帯される送信器からはデータが受信できなくなる。そのため、第１受信器ＲＥ１は、第１範囲ＲＡ１内からデータが受信できないと、ロッカーに鍵がついてなく、ロッカーが使用中であることが判定できる。

なお、サーバ１０は、例えば、以下のようなハードウェア構成の装置である。

図４は、本発明の実施形態におけるロッカー管理システムが有する情報処理装置のハードウェア構成の一例を示すブロック図である。具体的には、サーバ１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１と、記憶装置１０２と、ネットワークＩ／Ｆ（ｉｎｔｅｒｆａｃｅ）１０３と、入力Ｉ／Ｆ１０４と、出力Ｉ／Ｆ１０５とを有する。つまり、サーバ１０は、あらかじめインストールされるプログラムに基づいて所定の手順を実行するコンピュータである。

ＣＰＵ１０１は、各種処理及び各種制御を実現するための演算と、各種データの加工とを行う演算装置である。さらに、ＣＰＵ１０１は、サーバ１０が有するハードウェアを制御する制御装置である。

記憶装置１０２は、データ、プログラム及び設定値等を記憶する。また、記憶装置１０２は、いわゆるメモリ（ｍｅｍｏｒｙ）等である。なお、記憶装置１０２は、ハードディスク（ｈａｒｄｄｉｓｋ）等の補助記憶装置等を有してもよい。

ネットワークＩ／Ｆ１０３は、ネットワークを介して接続される装置と各種データ等を送受信する。例えば、ネットワークＩ／Ｆ１０３は、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）及びＬＡＮケーブルを接続させるコネクタ等である。なお、ネットワークＩ／Ｆ１０３は、ネットワークを利用するＩ／Ｆに限られず、ケーブル、無線又はコネクタ等によって外部装置と送受信するＩ／Ｆであってもよい。

入力Ｉ／Ｆ１０４は、ユーザ等との入力インタフェースである。具体的には、入力Ｉ／Ｆ１０４は、ユーザ等が行う各種操作を入力する。例えば、入力Ｉ／Ｆ１０４は、キーボード等の入力装置及び入力装置を接続させるコネクタ等によって構成される。

出力Ｉ／Ｆ１０５は、ユーザ等との出力インタフェースである。具体的には、出力Ｉ／Ｆ１０５は、各種処理の処理結果等をユーザ等に出力する。例えば、出力Ｉ／Ｆ１０５は、ディスプレイ等の出力装置及び出力装置を接続させるコネクタ等である。なお、出力Ｉ／Ｆ１０５は、処理結果等を示すデータを生成し、データを外部装置に出力してもよい。

また、サーバ１０は、各ハードウェア資源による処理等を補助する補助装置を更に有する構成でもよい。さらに、サーバ１０は、各種処理及び制御を並列、冗長又は分散して処理するため、装置を内部又は外部に更に有してもよい。

さらにまた、ロッカー管理システムは、複数の情報処理装置を有してもよい。例えば、情報処理装置は、サーバ１０とは別に、複数の受信器からデータを受信する情報処理装置がある構成でもよい。つまり、ロッカー管理システムは、各送信器から、それぞれのデータを収集する装置（以下「収集端末」という。）と、収集端末からデータを受信するサーバ１０とを有する構成でもよい。

収集端末は、複数の受信器に、接続される。すなわち、収集端末は、ゲートウェイとなる装置である。そして、収集端末は、所定の間隔で、収集したそれぞれのデータを集計した結果等に基づいて、サーバ１０にデータを送信する。例えば、所定の間隔は、２分間隔である。このように、収集端末があると、ロッカー又は受信器を増減させることが簡易にできる。より望ましくは、収集端末は、ＬＡＮポート以外の種類のポートを有するのが望ましい。このように、複数の種類のポートがあると、収集端末は、様々な種類のケーブルを接続させることができる。

また、収集端末は、各受信器から、それぞれのデータを受信した後、各データを集計する処理等を行う場合が多い。そこで、所定の間隔は、それぞれのデータを集計する時間等を考慮した時間が設定されるのが望ましい。以下、情報処理装置がサーバ１０のみで構成される例で説明する。

≪ ２．ロッカー管理システムによる全体処理例 ≫
図５は、本発明の実施形態におけるロッカー管理システムによる全体処理の一例を示すシーケンス図である。例えば、ロッカー管理システム１は、図示する処理を所定の間隔ごとに行う。また、以下の例では、送信器が５台、すなわち、鍵が５つあり、かつ、図３等のように２台の受信器があるとする。なお、以下の説明において、同様の処理には、同一の符号を付し、説明を省略する。

≪ 鍵データの送信例（ステップＳ１０１） ≫
ステップＳ１０１では、それぞれの送信器は、鍵データを受信器に送信する。図示する例では、第１送信器ＴＲ１及び第２送信器ＴＲ２は、第１受信器ＲＥ１に、それぞれの鍵データを送信する。同様に、第３送信器ＴＲ３、第４送信器ＴＲ４及び第５送信器ＴＲ５は、第２受信器ＲＥ２に、それぞれの鍵データを送信する。

なお、ステップＳ１０１が定期的に行われ、それぞれの鍵データがあらかじめ設定される周期ごとに、送信されるのが望ましい。

≪ 鍵データの受信及び受信強度の取得例（ステップＳ１０２） ≫
ステップＳ１０２では、それぞれの受信器は、各送信器が送信する鍵データを受信する。また、ステップＳ１０２では、それぞれの受信器は、それぞれの鍵データを受信する際に、鍵データが送信された電波のそれぞれの受信強度を計測し、受信強度を取得する。他にも、それぞれの受信器は、受信した日時等を記録してもよい。

≪ ロッカーデータの記憶例（ステップＳ１０３） ≫
ステップＳ１０３では、サーバ１０は、鍵と対応するロッカーが識別できるデータ（以下「ロッカーデータ」という。）を記憶する。なお、記憶手順及びロッカーデータの詳細は、後述する。

≪ 受信データの入力例（ステップＳ１０４） ≫
ステップＳ１０４では、サーバ１０は、鍵データと、受信強度とを対応させたデータ（以下「受信データ」という。）を入力する。すなわち、ステップＳ１０４では、サーバ１０は、各受信器から、ステップＳ１０２で受信及び取得したそれぞれの結果を入力する。例えば、受信データは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）等によって生成される。また、受信データの入力は、Ｈｔｔｐ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）におけるリクエスト及びレスポンス等によって実現される。なお、入力手順及び受信データの詳細は、後述する。

≪ 空きロッカーの数の算出例（ステップＳ１０５） ≫
ステップＳ１０５では、サーバ１０は、空きロッカーの数を算出する。例えば、サーバ１０は、受信データ及びロッカーデータに基づいて、各ロッカーのそれぞれの空き状態を判定する。次に、判定結果に基づいて、サーバ１０は、空き状態と判定されたロッカーの数を数えて、空きロッカーの数を算出する。このようにすると、ロッカー管理システム１は、空きロッカーの数を把握することができる。なお、算出手順の詳細は、後述する。

≪ 空きロッカーの数に基づく出力例（ステップＳ１０６） ≫
ステップＳ１０６では、サーバ１０は、例えば、外部装置に、算出された空きロッカーの数等を出力させてもよい。例えば、図示するように、ロッカー管理システム１には、出力端末ＯＴが接続されるとする。なお、出力端末ＯＴは、例えば、ディスプレイ等の表示端末又はスマートフォン等の携帯端末等である。

サーバ１０は、出力端末ＯＴに、例えば、判定結果に基づいて、空きロッカーの数を数字又はアイコン等で表示させる。また、出力端末ＯＴは、例えば、マップ等を用いて、空きロッカーと判定されたロッカーの設置場所等を表示してもよい。他にも、出力端末ＯＴは、サイズごとに、空きロッカーの数を表示してもよい。

サーバ１０によって行われる処理、すなわち、ステップＳ１０３乃至ステップＳ１０５は、以下のような処理である。

図６は、本発明の実施形態におけるロッカー管理システムが有する情報処理装置による処理の一例を示すフローチャートである。なお、以下の説明では、図５と同様の処理には、同一の符号を付して説明する。

≪ ロッカーデータの記憶例（ステップＳ１０３） ≫
ステップＳ１０３では、サーバ１０（図４参照）は、ロッカーデータを記憶する。ロッカーデータは、例えば、各項目がユーザによってあらかじめ入力されるデータである。ロッカーデータは、例えば、以下のようなデータである。

図７は、本発明の実施形態におけるロッカー管理システムが記憶するロッカーデータの一例を示す表である。図示する例では、ロッカーデータＤＬＣＫは、「グループＮｏ．」と、「ロッカー間口Ｎｏ．」と、「サイズ」と、「鍵ＩＤ」とを対応させるデータである。

「グループＮｏ．」は、各ロッカーが属するグループを識別できるロッカーグループデータの例である。図示する例では、ロッカーデータＤＬＣＫは、「ロッカー間口Ｎｏ．」が「８００１」乃至「８００４」であるロッカーが、「グループＮｏ．」が「Ｌ２００１」のグループに属することを示す。また、「グループＮｏ．」がわかると、サーバ１０は、ロッカーが設置されている場所等が特定できる。

「ロッカー間口Ｎｏ．」は、各ロッカーを特定できる番号等を示すロッカー識別データの例である。例えば、「ロッカー間口Ｎｏ．」は、各ロッカーのシリアル番号又は管理番号等である。

「サイズ」は、各ロッカーのサイズを示すロッカーサイズデータの例である。図示する例では、ロッカーデータＤＬＣＫは、「ロッカー間口Ｎｏ．」が「８００１」であるロッカーが、「小口」であることを示す。例えば、「小口」のロッカーは、小さな鞄等が入る収納スペースである。一方で、図示する例では、ロッカーデータＤＬＣＫは、「ロッカー間口Ｎｏ．」が「８００３」であるロッカーが、「大口」であることを示す。例えば、「大口」のロッカーは、キャリーバック又はスーツケース等の大きな鞄が入れられる収納スペースである。

なお、「サイズ」は、「小口」、「中口」及び「大口」の３種類に限られない。すなわち、種類の数は、２種類以下又は４種類以上であってもよい。また、「サイズ」は、数値等で入力されてもよい。

「鍵ＩＤ」は、各ロッカーに対応する鍵を特定できるデータである。図示する例では、ロッカーデータＤＬＣＫは、「ロッカー間口Ｎｏ．」が「８００１」であるロッカーには、「鍵ＩＤ」が「Ａ０００１」である鍵が対応することを示す。

具体的には、サーバ１０が図示するロッカーデータＤＬＣＫを記憶すると、サーバ１０は、図１に示すグループＧＲに属するロッカーが「グループＮｏ．」及び「ロッカー間口Ｎｏ．」から判定できる。また、グループＧＲがどこに設置されているか等が特定できると、サーバ１０は、「グループＮｏ．」及び「ロッカー間口Ｎｏ．」に基づいて、各ロッカーの場所等を特定できる。

さらに、サーバ１０が図示するロッカーデータＤＬＣＫを記憶すると、サーバ１０は、「ロッカー間口Ｎｏ．」及び「鍵ＩＤ」に基づいて、各ロッカーに対応する鍵を特定できる。例えば、「鍵ＩＤ」が「Ａ０００１」となる鍵は、図１に示す第１鍵ＫＥＹ１であるとする。すなわち、ロッカーデータＤＬＣＫには、第１ロッカーＬＣＫ１に、第１鍵ＫＥＹ１が対応することが入力される。

また、図示するロッカーデータＤＬＣＫでは、「小口」、「中口」及び「大口」は、図１に示す「小」、「中」及び「大」のサイズに対応する。

≪ 受信データの入力例（ステップＳ１０４） ≫
図６に戻り、ステップＳ１０４では、サーバ１０は、受信データを入力する。受信データは、例えば、以下のようなデータである。

図８は、本発明の実施形態におけるロッカー管理システムが入力する受信データの一例を示す表である。図示する例では、受信データは、「鍵ＩＤ」と、「受信強度」とを対応させるデータである。なお、図示するように、受信データは、「最終受信時刻」等を記録したデータでもよい。

「鍵ＩＤ」は、受信した鍵データが示す鍵ＩＤである。

「最終受信時刻」は、鍵データを受信した日時等を示す。

「受信強度」は、各鍵データを受信した受信強度を示す。また、以下の説明では、受信強度に基づいて、受信器と、送信器との距離が、計算できるとする。

なお、受信データは、同一の鍵ＩＤとなる鍵データが受信された場合には、過去のデータが削除され、最新の受信結果が残るように処理される、すなわち、更新されてもよい。

≪ 空きロッカーの数の算出例（ステップＳ１０５） ≫
図６に戻り、ステップＳ１０５では、サーバ１０は、空きロッカーの数を算出する。まず、図７に示すようなロッカーデータＤＬＣＫがあると、サーバ１０は、各ロッカーに対応するそれぞれの鍵がある距離を受信強度に基づいて計算できる。そして、受信強度と、あらかじめ設定される閾値とを比較すると、サーバ１０は、各ロッカーの空き状態を判定できる。

以下、図１に示す第１ロッカーＬＣＫ１を例に説明する。まず、サーバ１０は、ロッカーデータＤＬＣＫに基づいて、対応する鍵が「Ａ０００１」の鍵であると特定できる。したがって、サーバ１０は、「Ａ０００１」の鍵データを受信した受信強度に基づいて、第１ロッカーＬＣＫ１の空き状態を判定する。

なお、閾値は、ロッカーごとに、それぞれ設定されてもよい。受信強度は、例えば、ロッカーが設置される場所が、ロッカールームのような閉鎖的な空間であるか、又は、駅等のような開放的な空間であるかによって影響を受ける。他にも、受信強度は、ロッカーと受信器との距離及びロッカーと受信器との間に遮蔽物があるか否か等によっても影響を受ける場合が多い。

そこで、閾値は、ロッカーの設置される場所ごと、ロッカーごと又はグループごとに、それぞれの鍵がロッカーについた状態等で計測された値等が望ましい。なお、グループは、例えば、図７に示す「グループＮｏ．」である。このようにして、閾値は、各ロッカーの使用環境等を考慮して、それぞれの使用環境を考慮した値が設定されてもよい。なお、閾値には、誤差等の影響を考慮して、安全率等を含む値が設定されてもよい。

すなわち、受信強度は、図１に示す第１ロッカーＬＣＫ１のように、ロッカーに鍵がついた状態では、あらかじめ鍵がロッカーについた状態等で計測された強度に近い強度となる。つまり、ロッカーが「空き」の状態では、受信強度は、所定の強度に近い強度となる。

一方で、受信強度は、図１に示す第２ロッカーＬＣＫ２のように、ロッカーから鍵が離された状態では、あらかじめ鍵がロッカーについた状態等で計測された強度より、強度が弱くなる。また、鍵が所定の範囲を超えて離れると、受信器は、鍵データを受信できなくなる。つまり、ロッカーが「使用中」の状態では、受信強度が所定の強度より弱い強度となるか、又は、受信器が鍵データを受信できなくなる。

したがって、例えば、それぞれの閾値と、受信データが示すそれぞれの受信強度とを比較して、受信強度が閾値を上回る値であると、サーバ１０は、ロッカーの空き状態は、「空き」であると判定する。一方で、それぞれの閾値と、受信データが示すそれぞれの受信強度とを比較して、受信強度が閾値を上回る値でない、又は、対象となる鍵データが受信データにないと、サーバ１０は、ロッカーの空き状態は、「使用中」であると判定する。このように、サーバ１０は、受信データに基づいて、各鍵に係る受信強度と、閾値とを比較し、判定する。そして、サーバ１０は、ロッカーデータに基づいて、各鍵に対応するロッカーの空き状態を判定する。例えば、判定結果は、以下のようになる。

図９は、本発明の実施形態におけるロッカー管理システムがロッカーの空き状態を判定した結果の一例を示す表である。図示する空き状態データＤＳＴが示す例において、「グループＮｏ．」及び「ロッカー間口Ｎｏ．」は、図７に示すロッカーデータＤＬＣＫと同様の項目である。また、「空き状態」は、図６に示すステップＳ１０５において判定された各ロッカーのそれぞれの空き状態である。

図示する空き状態データＤＳＴの例では、「ロッカー間口Ｎｏ．」が「８００１」、「８００３」、「９００１」及び「９００２」のロッカーに対応する鍵について、それぞれの受信強度が閾値を上回る値であり、「空き」状態と判定された場合である。つまり、「ロッカー間口Ｎｏ．」が「８００１」、「８００３」、「９００１」及び「９００２」のロッカーは、ユーザがそれぞれのロッカーへ荷物等を収納できる状態である。

一方で、図示する空き状態データＤＳＴの例では、「ロッカー間口Ｎｏ．」が「８００２」、「８００４」及び「９００３」のロッカーに対応する鍵について、それぞれの受信強度が閾値を上回る値でなく、「使用中」状態と判定された場合である。つまり、「ロッカー間口Ｎｏ．」が「８００２」、「８００４」及び「９００３」のロッカーは、それぞれのロッカー内に、荷物等が既に収納されている状態である。

そして、サーバ１０は、空き状態が「空き」となったロッカーの数を数えると、空きロッカーの数を算出することができる。

なお、空きロッカーの数は、サイズごと、又は、グループごと算出されるのが望ましい。例えば、空きロッカーの数は、以下のように算出されるのが望ましい。

図１０は、本発明の実施形態におけるロッカー管理システムがサイズごと及びグループごとにロッカーの空き状態を算出した結果の一例を示す表である。図示する算出結果データＤＣＬが示す例において、「グループＮｏ．」及び「サイズ」は、図７に示すロッカーデータＤＬＣＫと同様の項目である。また、「空きロッカーの数」は、各グループにおいて、サイズごと、それぞれの空きロッカーの数を示す。

サーバ１０は、図７に示すロッカーデータＤＬＣＫがあらかじめ記憶されるため、各鍵に対応するロッカーのサイズ及びグループを特定することができる。したがって、サーバ１０は、例えば、図９に示す空き状態データＤＳＴによって、「空き」の状態であるロッカーがどのようなサイズであるかを特定できる。

具体的には、空き状態データＤＳＴの例では、例えば、「Ｌ２００１」のグループにおいて、「小口」のサイズで「空き」の状態であるロッカーは、「ロッカー間口Ｎｏ．」が「８００１」のロッカーのみである。そのため、空きロッカーの数は、「１」である。したがって、算出結果データＤＣＬでは、「Ｌ２００１」における「小口」の「空きロッカーの数」は、「１」となる。

同様に、「Ｌ２００１」のグループにおいて、「中口」のサイズで「空き」の状態であるロッカーは、「ロッカー間口Ｎｏ．」が「８００２」のロッカーが「使用中」であるため、「空き」状態のロッカーは、無い状態である。そのため、空きロッカーの数は、「０」である。したがって、算出結果データＤＣＬでは、「Ｌ２００１」における「中口」の「空きロッカーの数」は、「０」となる。

以上のように算出すると、サーバ１０は、グループごと、及び、サイズごと、空きロッカーの数を算出できる。

≪ 空きロッカーの数に基づく出力例（ステップＳ１０６） ≫
図６に戻り、ステップＳ１０６では、サーバ１０は、例えば、出力端末ＯＴ（図５参照）等の外部装置に、算出された空きロッカーの数等を出力させてもよい。例えば、ステップＳ１０６では、サーバ１０は、ステップＳ１０５で算出された空きロッカーの数を示すデータを出力端末ＯＴに送信する。そして、出力端末ＯＴは、受信したデータに基づいて、空きロッカーの数等を表示する。このようにして、サーバ１０は、外部装置に、算出結果等を表示させるようにしてもよい。

≪ ３．ロッカー管理システムの機能構成例 ≫
図１１は、本発明の実施形態におけるロッカー管理システムの機能構成の一例を示す機能ブロック図である。例えば、ロッカー管理システム１は、送信部ＦＮ１と、受信部ＦＮ２と、取得部ＦＮ３と、入力部ＦＮ４と、記憶部ＦＮ５と、算出部ＦＮ６とを含む機能構成である。

送信部ＦＮ１は、鍵データＤＫＥＹを受信器ＲＥに送信する。例えば、送信部ＦＮ１は、送信器ＴＲが有するアンテナ及びＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）チップ等によって実現される。

受信部ＦＮ２は、鍵データＤＫＥＹを受信する。例えば、受信部ＦＮ２は、受信器ＲＥが有するアンテナ及びＩＣチップ等によって実現される。

取得部ＦＮ３は、鍵データＤＫＥＹを受信した受信強度を取得する。例えば、取得部ＦＮ３は、受信器ＲＥが有するアンテナ及びＩＣチップ等によって実現される。

入力部ＦＮ４は、受信データＤＲＥを入力する。例えば、入力部ＦＮ４は、ネットワークＩ／Ｆ１０３（図４参照）及びＣＰＵ１０１（図４参照）等によって実現される。

記憶部ＦＮ５は、ロッカーデータＤＬＣＫを記憶する。例えば、記憶部ＦＮ５は、記憶装置１０２（図４参照）等によって実現される。

算出部ＦＮ６は、受信データＤＲＥ及びロッカーデータＤＬＣＫに基づいて、空きロッカーの数を算出する。例えば、算出部ＦＮ６は、ＣＰＵ１０１（図４参照）等によって実現される。

まず、例えば、図２に示すように、鍵ＫＥＹには、送信器ＴＲが付帯される。そして、送信器ＴＲには、鍵を識別できる鍵ＩＤ等が設定される。そのため、送信器ＴＲは、送信部ＦＮ１によって、鍵ＩＤ等を示す鍵データＤＫＥＹを送信することができる。

次に、例えば、図３に示す第１受信器ＲＥ１及び第２受信器ＲＥ２のように、受信器ＲＥが、あらかじめロッカーの設置場所等に設置される。このようにすると、受信器ＲＥは、受信部ＦＮ２によって、送信器ＴＲが送信する鍵データＤＫＥＹを受信することができる。

また、受信器ＲＥは、鍵データＤＫＥＹを受信する際に、受信強度を計測すると、取得部ＦＮ３によって受信強度を取得することができる。そのため、受信部ＦＮ２が受信した鍵データＤＫＥＹと、鍵データＤＫＥＹを受信した際に取得部ＦＮ３が取得した受信強度とを対応させると、受信器ＲＥは、例えば、図８に示すような受信データＤＲＥを生成することができる。

そして、受信器ＲＥと、サーバ１０とは、例えば、図３に示すように、ネットワークＮＷを介して接続される。したがって、ネットワークＮＷを介して、受信器ＲＥからサーバ１０に、受信データＤＲＥが送られると、サーバ１０は、入力部ＦＮ４によって、受信データＤＲＥを入力することができる。

また、サーバ１０は、記憶部ＦＮ５によって、例えば、図７に示すようなロッカーデータＤＬＣＫを記憶する。また、図７に示すロッカーデータＤＬＣＫには、各ロッカーを識別できる「ロッカー間口Ｎｏ．」のようなロッカー識別データに対応して、鍵ＩＤが入力される。

さらに、ロッカーデータＤＬＣＫには、各ロッカーが属するグループを示す「グループＮｏ．」等のようなロッカーグループデータが入力される。このように、ロッカーグループデータがあると、サーバ１０は、各ロッカーが属するグループを特定できる。

他にも、ロッカーデータＤＬＣＫには、各ロッカーのそれぞれのサイズを示す「サイズ」等のようなロッカーサイズデータが入力される。このように、ロッカーサイズデータがあると、サーバ１０は、各ロッカーのそれぞれのサイズを特定できる。

サーバ１０には、あらかじめ比較に用いる閾値が設定される。そして、サーバ１０は、閾値と、受信データＤＲＥが示す受信強度とを比較する。次に、比較の結果に基づいて、各ロッカーのそれぞれの空き状態が、判定される。

サーバ１０は、鍵ＩＤと、ロッカーとを、ロッカーデータＤＬＣＫによって、対応付けできる。そして、鍵ＩＤと、受信強度とは、受信データＤＲＥによって、対応付けできる。したがって、受信強度に基づく判定結果は、各ロッカーに対応付けでき、サーバ１０による判定結果は、例えば、図９に示す空き状態データＤＳＴのようになる。

続いて、空き状態データＤＳＴに基づいて、サーバ１０は、算出部ＦＮ６によって、「空き」の状態となっているロッカーの数を数えると、空きロッカーの数を算出することができる。

なお、空きロッカーの数は、図１０に示すように、サイズごと算出されるのが望ましい。例えば、ユーザがキャリーバックのような大きな荷物をロッカーに収納しようとする場合には、ユーザは、サイズが「大口」であり、かつ、「空き」状態であるロッカーを探す。したがって、図１０に示すように、「大口」サイズの空きロッカーの数がわかると、ロッカー管理システム１は、ユーザが探しているサイズの空きロッカーの数を表示することができる。

また、空きロッカーの数は、図１０に示すように、グループごとに算出されるのが望ましい。グループが特定できると、ロッカー管理システム１は、空きロッカーの設置場所等が特定できる。したがって、グループごとに、空きロッカーの数が算出できると、ロッカー管理システム１は、「空き」の状態であるロッカーの設置場所等をユーザに表示することができる。

さらに、図２に示すように、鍵に送信器を後から取り付けるような構成とすると、ロッカーの改修又は入れ替え等があっても、ロッカーの管理がしやすい。具体的には、本発明に係るロッカー管理システムでは、図２に示すような鍵を用いるロッカーと、電子錠等を用いるロッカーとが混在する等であっても、管理がしやすい構成である。例えば、鍵を用いるロッカーを入れ替える場合であっても、本発明に係るロッカー管理システムでは、入れ替えの際にも、鍵を用いるロッカーの運用が停止してしまうのを少なくすることができる。

すなわち、本発明に係るロッカー管理システムでは、ロッカーを変更する必要が少ない。つまり、本発明に係るロッカー管理システムでは、鍵に送信器を付帯させ、かつ、受信器を設置すれば、ロッカーの管理者は、管理用に、ロッカーに新しく装置を取り付けたり、又は、ロッカーを他の機種に入れ替えたりする手間が少なくできる。

一方で、本発明に係るロッカー管理システムのように受信強度を用いずに、ロッカーの「空き状態」を判定するには、例えば、タッチセンサ等のセンサをロッカーに設置し、センサが扉の開閉を検出しないと、「空き状態」が判定できない場合がある。又は、電子錠の方式等では、扉を開けるためのパスワード等が入力されたのを受けて判定を行う処理等を実行しないと、「空き状態」が判定できない場合がある。したがって、これらの比較例と比較すると、本発明に係るロッカー管理システムでは、ロッカーに情報処理装置等を設置する必要が少なくなる。

（他の実施形態）
なお、本発明の一実施形態に係る各処理の全部又は一部は、低水準言語、高水準言語又はこれらを組み合わせて記述されるコンピュータに、ロッカー管理方法を実行させるためのプログラムによって実現されてもよい。すなわち、プログラムは、情報処理装置等のコンピュータに、各処理の全部又は一部を実行させるためのコンピュータプログラムである。

また、プログラムは、コンピュータが読み取り可能な記録媒体に格納して頒布することができる。なお、記録媒体は、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ若しくはブルーレイディスク等の光ディスク、ＳＤ（登録商標）カード、補助記憶装置又はＭＯ等でもよい。さらにまた、プログラムは、電気通信回線を通じて頒布することができる。

また、本発明の一実施形態に係る各処理は、図示した手順に限られない。例えば、各処理の一部又は全部は、異なる順序、並行、分散又は省略されて処理されてもよい。

以上、本発明の好ましい実施例について詳述したが、本発明は、上述の実施形態に限定されず、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形又は変更が可能である。

１ ロッカー管理システム
ＫＥＹ 鍵
ＴＲ 送信器
ＴＲ１ 第１送信器
ＴＲ２ 第２送信器
ＴＲ３ 第３送信器
ＴＲ４ 第４送信器
ＴＲ５ 第５送信器
ＲＥ 受信器
ＲＥ１ 第１受信器
ＲＥ２ 第２受信器
１０ サーバ
ＦＮ１ 送信部
ＦＮ２ 受信部
ＦＮ３ 取得部
ＦＮ４ 入力部
ＦＮ５ 記憶部
ＦＮ６ 算出部
ＤＫＥＹ 鍵データ
ＤＬＣＫ ロッカーデータ
ＤＲＥ 受信データ

Claims (5)

1. 鍵に付帯される送信器と、前記送信器による送信を受信する受信器と、前記受信器とネットワークを介して接続される１以上の情報処理装置とを有するロッカー管理システムであって、
   前記送信器は、
   前記鍵を識別できる鍵データを前記受信器に送信する送信部を有し、
   前記受信器は、
   前記鍵データを受信する受信部と、
   前記鍵データを受信した受信強度を取得する取得部とを有し、
   前記情報処理装置は、
   前記鍵データと、前記受信強度とを対応させた受信データを入力する入力部と、
   前記鍵が所定範囲に存在すると判断する前記受信強度の閾値を含み、前記鍵と対応するロッカーを識別するロッカーデータを記憶する記憶部と、
   前記受信データの前記受信強度と、前記ロッカーデータが示す前記閾値とを比較し、前記鍵データに基づいて識別される全てのロッカーの空き状態を判定し、空きロッカーの数を算出する算出部と、
   外部装置に空きロッカー数を含む空きロッカー情報を出力する出力部と
   を含むロッカー管理システム。
2. 前記ロッカーデータは、
   前記ロッカーのサイズを示すロッカーサイズデータと
   を少なくとも有し、
   前記算出部は、
   前記ロッカーサイズデータに基づいて、前記サイズごとに、それぞれの前記空きロッカーの数を算出する請求項１に記載のロッカー管理システム。
3. 前記ロッカーデータは、
   前記ロッカーが属するグループを示すロッカーグループデータを有し、
   前記算出部は、
   前記ロッカーグループデータに基づいて、前記グループごとに、それぞれの前記空きロッカーの数を算出する請求項１又は２に記載のロッカー管理システム。
4. 前記送信器は、アクティブタグである請求項１乃至３のいずれか１項に記載のロッカー管理システム。
5. 鍵に付帯される送信器と、前記送信器による送信を受信する受信器と、前記受信器とネットワークを介して接続される１以上の情報処理装置とを有するロッカー管理システムが行うロッカー管理方法であって、
   前記送信器が、前記鍵を識別できる鍵データを前記受信器に送信する送信手順と、
   前記受信器が、前記鍵データを受信する受信手順と、
   前記受信器が、前記鍵データを受信した受信強度を取得する取得手順と、
   前記情報処理装置が、前記鍵データと、前記受信強度とを対応させた受信データを入力する入力手順と、
   前記情報処理装置が、前記鍵が所定範囲に存在すると判断する前記受信強度の閾値を含み、前記鍵と対応するロッカーを識別するロッカーデータを記憶する記憶手順と、
   前記情報処理装置が、前記受信データの前記受信強度と、前記ロッカーデータが示す前記閾値とを比較し、前記鍵データに基づいて識別される全てのロッカーの空き状態を判定し、空きロッカーの数を算出する算出手順と、
   前記情報処理装置が、外部装置に空きロッカー数を含む空きロッカー情報を出力する出力手順と
   を含むロッカー管理方法。

Images