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

Description

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

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

例えば、まず、ロッカーの利用開始予定日より前に予約があると、利用者には、ロッカー群から特定のロッカーが割り当てられる。そして、メール等の通知によって、利用者に、割り当てられたロッカーに関する情報が通知される。次に、制御部は、空きロッカー数と予約数の差を計算して、差がマージン値未満であると、新規預入を不可と判断する。このようにして、フレキシブルな対応を可能とし、予約をせずに利用する利用者の利便性を確保する方法が知られている（例えば、特許文献１等）。

また、ロッカー予約システムにおいて、予約管理装置が、まず、予約情報を記憶する。そして、予約情報は、予約者の識別コードと関連付けされて記憶される。このように、予約情報及び識別コードを関連付けした状態で、制御端末が識別コードを予約管理装置に送ると、予約管理装置は、識別コードに基づいて予約情報を判定して予約状況を制御端末に送ることができる。このような構成であると、予約をしてあるロッカーをキャンセルする指示を制御端末が予約管理装置に送ることができる。このようにして、ユーザが容易にロッカーの予約をキャンセルすることができるようにする方法が知られている（例えば、特許文献２等）。

特開２０１８－１６５８５３号公報 特開２０１６－２２４８６１号公報

しかしながら、従来の方法では、ロッカーを管理する装置との通信状況及びロッカーが使用されている状況等が考慮されていない場合がある。そのため、ユーザが事前に予約をしても、予約したロッカーが他人による使用で使えない場合がある。

本発明の１つの側面は、このような問題に鑑みてなされたものであり、ユーザの利便性を向上させることを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一実施形態におけるロッカー管理システムは、
ユーザによるロッカーの第１予約又は使用申込を入力する第１情報処理装置と、
前記第１情報処理装置と通信を行い、かつ、前記ロッカーを管理する第２情報処理装置とを有するロッカー管理システムであって、
前記第１情報処理装置は、
前記ロッカーの開始時刻及び終了時刻を示す前記第１予約を記憶する記憶部と、
前記第２情報処理装置から、前記ロッカーの使用状況を示す検出結果に基づいて生成される使用情報、及び、前記ロッカーを開閉するのに用いる鍵情報を取得する取得部と、
前記使用申込を受け付ける受付部と、
所定条件を満たし、かつ、前記使用情報に基づいて空きロッカーがあると判断されると、前記第１予約に基づいて第２予約を行う、又は、前記使用情報に基づいて空きロッカーがあると判断され、かつ、前記使用申込を受け付けると、前記第２予約を行う予約部と、
前記第２予約が行われると、前記ロッカーのうち、前記開始時刻から前記終了時刻の間、使用できるロッカーを特定するロッカー情報、及び、前記ロッカー情報で特定されるロッカーを開閉するのに用いる前記鍵情報を前記ユーザに通知する通知部と
を含み、
前記第２情報処理装置は、
前記ロッカーのうち、使用中である使用中ロッカーを検出して、前記検出結果を出力する検出部と、
前記鍵情報を生成する鍵情報生成部と、
前記使用情報及び前記鍵情報を前記第１情報処理装置に送信する送信部とを含む。

本発明によれば、ユーザの利便性を向上できる。

ロッカー管理システムが管理対象とするロッカーの例を示す図である。 ロッカー管理システムの全体構成例を示す概念図である。 情報処理装置のハードウェア構成例を示す図である。 全体処理例を示す図である。 使用情報の例を示す図である。 鍵情報の管理例を示す図である。 予約台帳の例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 第２予約が不成立の通知例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 全体処理例を示す図である。 機能構成例を示す図である。 算出結果データの例を示す図である。 ロッカーデータの例を示す図である。

以下、発明を実施するための最適かつ最小限な形態について、図面を参照して説明する。なお、図面において、同一の符号を付す場合には、同様の構成であることを示し、重複する説明を省略する。また、図示する具体例は、例示であり、図示する以外の構成が更に含まれる構成であってもよい。

＜ロッカーの例＞
例えば、ロッカー管理システムによって管理の対象となるロッカーは、駅又は商業施設等に設置され、以下のようなロッカーである。

図１は、ロッカー管理システムが管理対象とするロッカーの例を示す図である。例えば、ロッカーＬＣＫは、図示するように、３種類のサイズがあって、９つのロッカーがあるとする。具体的には、図示するように、上段に設置される「８００１」、「８００４」及び「８００７」のロッカーは、３種類のうち、最も小さいサイズとなる「小」サイズであるとする。さらに、図示するように、「８００２」、「８００５」及び「８００８」のロッカーは、「小」サイズより大きいサイズであり、かつ、「大」サイズより小さいサイズとなる「中」サイズであるとする。また、図示するように、下段に設置される「８００３」、「８００６」及び「８００９」のロッカーは、３種類のうち、最も大きいサイズとなる「大」サイズであるとする。以下、図示するように、各ロッカーに記載される番号を「間口Ｎｏ．」とし、それぞれの間口を識別する識別情報とする。

また、それぞれの間口は、例えば、図示するように、近くに配置される操作端末ＣＴＬ等に、番号又は文字等で構成される鍵（いわゆる暗証番号等である。以下、鍵となる情報を「鍵情報」という。）を入力すると、ユーザは、各間口を施錠又は解錠できる。

なお、鍵を入力するための構成は、図示するような操作端末ＣＴＬでなくともよい。すなわち、操作端末ＣＴＬとなる装置が各間口に、それぞれの操作端末があってもよい。又は、操作端末ＣＴＬは、ユーザが有する情報処理装置等が入力用の端末となってもよい。

また、各間口には、センサが設置され、扉の開閉又は各間口に荷物等が入っているか否か等が検出される。さらに、各間口には、施錠及び解錠を行うアクチュエータ等が設置され、それぞれのアクチュエータを制御する制御器があってもよい。したがって、各間口を管理する装置等は、遠隔操作等により、各間口を施錠又は解錠してもよい。

図２は、ロッカー管理システムの全体構成例を示す概念図である。例えば、ロッカー管理システムＬＳは、図示するように、第１情報処理装置の例である第１サーバＳＶ１と、第２情報処理装置の例である第２サーバＳＶ２とを少なくとも有する構成である。

図示するように、第１サーバＳＶ１は、ネットワークＮＷを介して、ユーザＵＲがスマートフォン等の端末（以下「ユーザ端末ＳＭ」という。）に対して行う操作を受け付ける。

具体的には、第１サーバＳＶ１は、ネットワークＮＷを介して、ロッカーＬＣＫを利用するためのサイト（以下「予約サイト」という。）等を公開する。したがって、ユーザ端末ＳＭは、予約サイトに対してアクセスすると、ロッカーの使用情報を取得及びロッカーの予約等を行う操作が可能となる。以下、ユーザＵＲによる操作は、ユーザ端末ＳＭ及び予約サイトを介する例で説明するが、ユーザＵＲによる操作は、他の情報処理装置又は第１サーバＳＶ１に直接入力される等でもよい。

第２サーバＳＶ２は、ロッカーＬＣＫを管理する。具体的には、図示するように、第２サーバＳＶ２は、各ロッカーＬＣＫが使用されているか否か等を検出して、情報を第１サーバＳＶ１に送信する。以下、情報は、第１サーバＳＶ１が管理する場合を例に説明する。ただし、情報は、第１サーバＳＶ１以外の情報処理装置が管理又は分散して管理してもよい。

また、第２サーバＳＶ２は、図示するように、複数あってもよい。そして、図示するように、それぞれの第２サーバＳＶ２は、複数のロッカーＬＣＫを管理してもよい。

例えば、第２サーバＳＶ２とそれぞれのロッカーＬＣＫの間は、主に有線による通信であるのが望ましい。すなわち、第２サーバＳＶ２は、図示するように、ロッカーＬＣＫに近い位置に設置されるのが望ましい。このような配置であると、例えば、ロッカーＬＣＫ及び第２サーバＳＶ２の間における通信を専用にしやすい。そのため、ロッカーＬＣＫ及び第２サーバＳＶ２の間で行われる通信において、セキュリティを確保しやすくでき、かつ、通信遅延等の通信障害を少なくできる。

一方で、第１サーバＳＶ１と第２サーバＳＶ２の間は、主に無線による通信であるのが望ましい。このような構成であると、第２サーバＳＶ２の位置及び数等を柔軟に変更することが容易にできる。すなわち、第２サーバＳＶ２は、ロッカーＬＣＫの増設、撤去又は変更により、一緒に増設、撤去又は移動する場合がある。したがって、無線による通信とすると、有線を用いる構成より、ケーブル等の増設、撤去及び変更等の作業が減り、作業負担の軽減ができる。

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

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

また、収集端末は、各受信器から、それぞれのデータを受信した後、各データを集計する処理等を行う場合が多い。そこで、所定の間隔は、それぞれのデータを集計する時間等を考慮した時間が設定されるのが望ましい。

以下、図示するような通信の構成である場合を例に説明する。

ただし、上記の無線又は有線における通信は、すべて有線及び無線による通信でなくともよい。例えば、通信の構成は、一部に有線又は無線の通信回路が混在する構成でもよい。

第１サーバＳＶ１及び第２サーバＳＶ２等は、例えば、以下のようなハードウェア構成の装置である。以下、第１サーバＳＶ１、第２サーバＳＶ２等、及び、ユーザ端末ＳＭ等の情報処理装置が同一のハードウェア構成である場合を例に説明し、重複する説明を省略する。ただし、それぞれの情報処理装置は、同一のハードウェア構成でなくともよい。

＜ハードウェア構成例＞
図３は、情報処理装置のハードウェア構成例を示す図である。具体的には、情報処理装置は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、以下「ＣＰＵＨＷ１」という。）と、記憶装置ＨＷ２と、ネットワークインタフェースＨＷ３と、入力装置ＨＷ４と、出力装置ＨＷ５と、インタフェースＨＷ６を有するハードウェア構成である。つまり、情報処理装置は、あらかじめインストールされるアプリケーションソフトウェア、ミドルウェア及びファームウェア等のプログラムに基づいて所定の手順を実行するコンピュータである。例えば、情報処理装置は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、サーバ、スマートフォン又はこれらの組み合わせ等である。

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

記憶装置ＨＷ２は、データ、プログラム及び設定値等を記憶する。例えば、記憶装置ＨＷ２は、いわゆるメモリ（ｍｅｍｏｒｙ）等の主記憶装置である。なお、記憶装置ＨＷ２は、ハードディスク（ｈａｒｄｄｉｓｋ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の補助記憶装置等を更に有してもよい。

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

入力装置ＨＷ４は、ユーザによる操作の受け付け又は外部装置からの入力等を行う装置である。例えば、入力装置ＨＷ４は、キーボード、マウス又はコネクタ等である。

出力装置ＨＷ５は、ユーザに対しての表示又は外部装置への出力等を行う装置である。例えば、出力装置ＨＷ５は、ディスプレイ又はコネクタ等である。

インタフェースＨＷ６は、外部装置を接続させてデータを送受信する装置である。例えば、インタフェースＨＷ６は、コネクタ等である。

また、情報処理装置は、各ハードウェア資源による処理等を補助する補助装置を更に有する構成でもよい。さらに、情報処理装置は、各種処理及び制御を並列、冗長又は分散して処理するため、演算装置、制御装置、記憶装置、入力装置又は出力装置等を内部又は外部に更に有してもよい。そして、情報処理装置及び情報処理装置が有するハードウェアは、複数の装置で構成されてもよい。

このようにして、情報処理装置は、プログラム等に基づいて演算装置と記憶装置を協働して動作させることで様々な処理及び制御を実行する。

＜全体処理例＞
以下、ロッカー管理システムが行うロッカー管理方法の実行例を分けて説明する。ただし、それぞれの実行例は、組み合わせて実行されてもよい。

＜第１例＞
図４は、全体処理例を示す図である。

ステップＳ１０１では、ロッカー管理システムＬＳは、ロッカーＬＣＫの使用状況等を検出する。具体的には、例えば、使用中（例えば、ロッカー内に荷物が入れられ、施錠されている状態等である。図では、このような状態のロッカーを「使用中」と示す。また、以下の説明では、使用中のロッカーを「使用中ロッカー」という場合がある。）であるロッカーＬＣＫから荷物等が取り出されたとする。このように、荷物が取り出されると、ロッカーＬＣＫは、以降、別の荷物を入れることが可能な状態となり、他の人等が使用可能なロッカー（いわゆる空きロッカーとなる。図では、このような状態のロッカーを「空きロッカー」と示す。）となる。このように、ロッカー管理システムは、ロッカーＬＣＫの状態が変化するのを検出する。したがって、ロッカーＬＣＫには、各間口に荷物の有無、扉の開閉、又は、人の有無等を検出するセンサが設置される。例えば、センサは、光学センサ、重量センサ、タッチセンサ又はこれらの組み合わせ等である。

以下、このように、ロッカーの状態を検出した結果を「使用情報Ｄ１」という。例えば、使用情報Ｄ１は、検出結果をまとめた情報等である。例えば、使用情報Ｄ１は、以下のような情報である。

図５は、使用情報の例を示す図である。例えば、使用情報Ｄ１は、各間口の使用状況を検出した結果をまとめて図示するように管理される。なお、使用情報Ｄ１は、図示するような形式に限られない。すなわち、使用情報Ｄ１は、図示する以外の項目を用いる構成でもよい。

「グループＮｏ．」は、管理対象となるロッカーが属するグループを特定する識別情報の例である。

「ロッカー間口Ｎｏ．」は、各間口を識別する識別情報の例である。

「使用状況」は、各間口が「使用中ロッカー」であるか、又は、「空きロッカー」であるかを検出した結果を示す。

なお、使用情報Ｄ１は、検出結果を受信するごとに更新されてもよい。例えば、ロッカーの状態は、一定時間が経過する、センサの検出結果が変化、又は、扉の開閉等があると、その都度検出される。したがって、第１サーバＳＶ１は、第２サーバＳＶ２から取得する検出結果を「使用状況」に反映させて使用情報Ｄ１を生成する。なお、それぞれの検出結果は、例えば、「ロッカー間口Ｎｏ．」に相当する識別情報と一緒に取得される。すなわち、第２サーバＳＶ２から取得される検出結果は、どの間口の使用状況を指すかが識別情報に基づいて判断される。

なお、使用情報Ｄ１は、第１サーバＳＶ１に図示するような一覧等がある場合には、１つの検出結果だけの情報でもよい。このように、検出結果だけが使用情報として送られてきた場合には、第１サーバＳＶ１は、新しく取得した検出結果に基づいて、取得した使用情報と同一の間口についてのみ使用状況を更新し、他の間口については使用状況を維持する。このようにして、変化のあった使用状況だけを検出結果として送受信する、いわゆる差分だけを送受信する構成等でもよい。

そして、空きロッカーが発生したと検出されると（図における「空きロッカー発生」の場合である。）、ロッカー管理システムＬＳは、ステップＳ１０２に進む。

ステップＳ１０２では、ロッカー管理システムＬＳは、空きロッカーとなったロッカーを施錠及び解錠するのに用いる鍵情報を生成する。

ステップＳ１０３では、ロッカー管理システムＬＳは、鍵情報により、空きロッカーを施錠する。以下、空きロッカーが施錠の状態となるため、空きロッカーが確保される。このように、施錠されている状態のロッカーを図では「施錠中」と示す。

ステップＳ１０４では、ロッカー管理システムＬＳは、第１サーバＳＶ１が第２サーバＳＶ２から鍵情報を取得する。例えば、鍵情報は、以下のように第１サーバＳＶ１でまとめて鍵情報一覧Ｄ２等で管理される。

図６は、鍵情報の管理例を示す図である。例えば、鍵情報は、図示する鍵情報一覧Ｄ２のように、「ロッカー間口Ｎｏ．」、すなわち、間口ごとに対応付けして管理される。

「グループＮｏ．」及び「ロッカー間口Ｎｏ．」は、使用情報Ｄ１と同様の情報である。

「鍵情報」は、例えば、図示するように、数字、文字、記号又はこれらの組み合わせ等である。この「鍵情報」と同様の情報が、各ロッカーを制御する制御器等にも送信される。したがって、ロッカーを利用しようとするユーザには、鍵情報を入力するように要求がされる。そして、ユーザが入力する入力値と、あらかじめ設定される鍵情報とが一致すれば、正式なユーザ等であると判断されて、ユーザはロッカーを使用できるようになる。

鍵情報は、例えば、ユーザがロッカーを使用し終わり、荷物が取り出されると生成される。すなわち、前のユーザによる使用が終了して、空きロッカーになると、鍵情報は、作り直される。このようにすると、前のユーザが使用した際に用いた鍵情報等が終了後には使用できなくなるため、セキュリティを確保したり、ロッカーが不正に使用されるのを防げたりする。

なお、鍵情報は、図示するような形式で管理されなくともよい。例えば、鍵情報は、他の情報等と一緒に管理されてもよい。

また、鍵情報は、例えば、乱数を発生させる関数等によって生成される。なお、鍵情報の生成方法は、例えば、いわゆるワンタイムパスワード等を生成する方法等であってもよい。さらに、鍵情報は、第２サーバＳＶ２が生成せず、他の情報処理装置が生成してもよい。すなわち、鍵情報の生成及び管理は、第１サーバＳＶ１及び第２サーバＳＶ２に限られず、他の情報処理装置等によって分散して行われてもよい。

以上のような処理が、定期的又は取り出しがあるタイミング等に行われる。そして、以上のような処理があらかじめ行われた後に、例えば、以下のような処理が行われる。すなわち、ロッカー管理システムＬＳは、以下のような処理を行う前に、空きロッカーの位置等と、空きロッカーを使用するのに用いられる鍵情報とを把握している状態で以下のような処理を行う（図における「仮予約」の場合である）。このように、仮予約があると、ロッカー管理システムＬＳは、ステップＳ１０５に進む。

ステップＳ１０５では、ロッカー管理システムＬＳは、ロッカーＬＣＫの予約を受け付ける。例えば、予約には、ロッカーの使用を開始する予定の時刻（以下「開始時刻」という。）、及び、ロッカーの使用を終了する予定の時刻（以下「終了時刻」という。ただし、終了時刻は、終了の日付及び時刻等を特定する情報であればよく、例えば、開始時刻から「３時間」のように、相対的な時間の経過を示す形式で入力されてもよい。）等が入力される。

なお、予約には、例えば、使用を希望するロッカーのサイズ等が入力されるのが望ましい。具体的には、図１に示すようなロッカーＬＣＫには、「大」、「中」及び「小」というサイズがある。したがって、このようなロッカーＬＣＫを予約の対象とする場合には、予約には、小さい荷物をロッカーに入れるため、「小」のサイズのロッカーを使用するように希望する入力があるのが望ましい。

なお、ユーザ端末ＳＭは、ログイン等の処理で識別されるため、どのユーザが入力した予約であるかは、識別情報等に基づいてユーザ等と対応付けできるとする。また、ロッカーが複数の場所に設置される場合には（例えば、複数の駅又は１つの駅でも、何か所にも設置される場合等である。）、使用したいロッカーの場所等を特定する情報（例えば、駅名等である。以下単に「場所」という。）が更に入力されてもよい。

以下、予約には、場所、開始時刻、終了時刻及びサイズが項目として入力されるとする。

以下、ステップＳ１０５のように、開始時刻より、所定時間以上前に入力される予約等を「第１予約」という場合がある。第１予約は、いわゆる「事前予約」又は「仮予約」である。所定時間は、例えば、１５分等である。なお、所定時間は、設定でき、例えば、１日等でもよい。

第１予約は、予約がステップＳ１０５等によって受け付けられても、荷物等をまだロッカーには入れて使用することができない予約である。

例えば、仮予約は、予約サイトに、場所、開始時刻、終了時刻及びサイズ等の項目を入力すると、第１サーバＳＶ１に入力される。そして、仮予約の内容は、例えば、台帳等のデータ形式（以下「第１予約台帳Ｄ３」という。）で記憶される。

なお、仮予約よって希望する場所、開始時刻、終了時刻及びサイズのロッカーが、既に別のユーザ等の予定で使用が不可能と見込まれる場合等には、仮予約を第１予約台帳Ｄ３に記憶せずに、ユーザ端末ＳＭに使用が不可能なことを知らせる通知を行ってもよい。

このように、仮予約を行った結果がユーザ端末ＳＭには、返信される。なお、返信には、仮予約を識別する仮予約番号等が通知されてもよい。以下、仮予約が成立した場合を例に説明する。

第１予約がされた後、すなわち、ステップＳ１０５が行われた後、第１予約が所定条件を満たすと（図では「第１予約が所定条件を満たした場合」である。）、ロッカー管理システムＬＳは、ステップＳ１０６に進む。

ステップＳ１０６では、ロッカー管理システムＬＳは、使用情報Ｄ１及び第１予約に基づいて、第２予約を行う。

所定条件は、例えば、開始時刻から現在時刻が所定の時間内になった場合等である。具体的には、開始時刻の１５分前になると、使用情報Ｄ１及び第１予約に基づいて、第１サーバＳＶ１は、予約を行う。以下、このように、使用情報Ｄ１及び第１予約に基づいて、第１予約とは別に行われる予約を「第２予約」という場合がある。

第２予約は、いわゆる「本予約」である。つまり、第２予約が成立すると、ユーザは、第２予約に基づいて、荷物等をロッカーに入れて使用することができる。このように、予約は、第１予約及び第２予約のように段階的に行われるのが望ましい。

また、図示するように、第２予約は、第２予約台帳Ｄ４で管理される。例えば、管理台帳は、以下のようなデータである。

図７は、予約台帳の例を示す図である。例えば、まず、図７（Ａ）に示すように、仮予約がされると、仮予約は、予約の際に入力される項目に基づいて、例えば、図示するように記憶される。

「第１予約ＩＤ」は、仮予約番号の入力例である。

「ユーザＩＤ」は、予約を入力したユーザの識別情報の入力例である。

「開始時刻」は、予約の際に入力される開始時刻の入力例である。

「終了時刻」は、予約の際に入力される終了時刻の入力例である。

「場所」は、予約の際に入力される場所の入力例である。

「サイズ」は、予約の際に入力されるユーザが希望するサイズの入力例である。

以上のように、第１予約及び使用申込は、少なくとも終了時刻が設定されてロッカーが使用される。したがって、終了時刻が分かる状態であるため、ロッカー管理システムは、終了時刻が入力されない場合と異なり、仮予約の入力等でも、終了時刻に基づくスケジュール等により、今後の使用状況を推測できる。

例えば、図示するように、第１予約は、図７（Ａ）に示すような形式で管理され、第２予約も、図７（Ｂ）に示すように、第１予約と同様の形式等で管理される。

なお、第１予約台帳Ｄ３及び第２予約台帳Ｄ４は、別のデータでなくともよい。すなわち、第１予約台帳Ｄ３及び第２予約台帳Ｄ４は、一体でもよいし、分散して管理されてもよい。

図示するように、所定条件を満たす、すなわち、開始時刻の１５分前になると、第１予約に基づいて、第２予約が行われる。図示するように、第２予約は、「第２予約ＩＤ」及び「ロッカー間口Ｎｏ．」以外は、第１予約と同様の内容である。なお、予約ＩＤ等は、同一でもよい。また、予約台帳は、図示するような形式に限られず、項目の省略又は追加があってもよい。

図示するように、仮予約の段階では、どの間口をユーザに使用させるかは特定させず、本予約の際に間口まで決める形式であるのが望ましい。例えば、第１予約では、「小」が希望されている場合であっても、第２予約を行う際に、使用状況により、「小」がすべて使用不可能であっても、「中」又は「大」のロッカーには、空きロッカーがある場合等がある。このような場合には、第２予約では、「中」又は「大」のロッカーを割り立てるように予約を成立させてもよい。

このような構成であると、ユーザが仮予約で希望する場所及びサイズであれば、希望する条件に合う空きロッカーがあると、ロッカー管理システムＬＳは、柔軟に間口を割り当てることができる。

なお、所定条件は、現在時刻が所定時間より前になる場合に限られない。例えば、ユーザ端末ＳＭが位置情報又は近距離無線通信用の電波等を出力する場合には、ユーザ端末ＳＭが所定の距離以内になると、所定条件を満たすと判断してもよい。すなわち、ユーザが仮予約を行った場所に近づくと、ロッカー管理システムＬＳは、本予約を行うようにしてもよい。このようにすると、仮予約で設定した開始時刻より、ユーザが早く着いた場合等にも対応できる。

このように、所定条件は、あらかじめ設定される距離又は時間等である。

ステップＳ１０７では、ロッカー管理システムＬＳは、ロッカー情報及び鍵情報を通知する。

ロッカー情報は、仮予約で設定した開始時刻から終了時刻の間、使用するロッカーを特定できる情報である。具体的には、ロッカー情報は、第２予約台帳Ｄ４にある、「ロッカー間口Ｎｏ．」等である。なお、ロッカー情報は、ユーザがロッカーを特定できればよいため、「場所」、「サイズ」、「何段目の右から何番目のロッカー」、地図、画像又はこれらの組み合わせ等の情報であってもよい。

また、鍵情報がユーザ端末ＳＭに通知される。したがって、通知がされると、以降、ユーザは、鍵情報を入力して、ロッカーを解錠及び荷物の預け入れが可能となる。

したがって、図示するように、ロッカー情報及び鍵情報が通知された後、荷物がロッカーに入れられると（図では、「預け入れ」と示す。）、ロッカー管理システムＬＳは、ステップＳ１０８に進む。

一方で、仮予約された後であっても、ステップＳ１０６を行う段階で、ロッカーが延長して使用されている等の場合には、本予約が成立しない。このような場合には、ステップＳ１０７では、本予約が不可能である通知が行われる。

ステップＳ１０８では、ロッカー管理システムＬＳは、荷物が入れられたのを検出する。この検出結果が、使用情報Ｄ１に反映される。このように、使用情報Ｄ１において、「使用中」となった時間が課金の基準となってもよい。

以降、取り出しがあると、ステップＳ１０１が行われる。

＜第２例＞
図８は、全体処理例を示す図である。第１例と異なる点は、第２例では、仮予約を行った後であって、かつ、第１予約が所定条件が満たされる前に、仮予約をキャンセルする操作が行われる場合である。

まず、図示するように、全体処理において、第１例とステップＳ１０５までの処理、すなわち、仮予約の入力までは、第２例でも同様であるとし、説明を省略する。次に、第１予約が所定条件が満たされる前、すなわち、第１例においてステップＳ１０６が実行される所定条件が満たされる前に、ステップＳ１０５で入力された第１予約に対してキャンセルする操作が行われたとする（図では、「キャンセルの入力があった場合」である）。このような場合には、ロッカー管理システムＬＳは、ステップＳ２０１に進む。

ステップＳ２０１では、ロッカー管理システムＬＳは、キャンセルを入力する。

ステップＳ２０２では、ロッカー管理システムＬＳは、キャンセルに基づいて、第１予約を第１予約台帳Ｄ３から削除する。

ステップＳ２０３では、ロッカー管理システムＬＳは、キャンセルの結果を通知する。

このように、仮予約の段階であって、本予約が行われる前では、鍵情報がユーザにまだ通知されていない。そのため、ユーザは、まだロッカーを使用できる状態でない。このような状態では、仮予約を削除すると、第２予約が行われるのを中止できる。

このように、仮予約を一度しても、キャンセルできる構成であるのが望ましい。このように、キャンセルが可能であると、ユーザは、予定の変更等に合わせて柔軟にロッカーを使用する予約を柔軟に変更できるため、利便性が向上する。

＜第３例＞
図９は、全体処理例を示す図である。第１例及び第２例と異なる点は、第３例では、仮予約を行った後であって、かつ、第１予約が所定条件が満たされ後に、予約をキャンセルする操作が行われる場合である。

したがって、まず、ステップＳ１０７までの処理、すなわち、本予約を行い、鍵情報及びロッカー情報が通知されるまでは、第１例でも同様であるとし、説明を省略する。

次に、ステップＳ１０７の後に、第２例と同様に、キャンセルの入力がされ、ステップＳ２０１が行われるとする。図示するように、キャンセルの入力が、ステップＳ１０７より後である点が第２例と異なる点である。このようなタイミングでキャンセルが入力されると、ロッカー管理システムＬＳは、ステップＳ３０１に進む。

ステップＳ３０１では、ロッカー管理システムＬＳは、キャンセルに基づいて、第２予約を第２予約台帳Ｄ４から削除する。また、図示するように、ロッカー管理システムＬＳは、キャンセルに基づいて、第１予約も第１予約台帳Ｄ３から削除、すなわち、ステップＳ２０２を行ってもよい。さらに、第２例と同様に、キャンセルの結果がステップＳ２０３によって通知されてもよい。

ステップＳ３０２では、ロッカー管理システムＬＳは、鍵情報、すなわち、ステップＳ１０７で通知された鍵情報を無効化させる。例えば、無効化は、鍵情報を更新する等である。他にも、無効化は、ステップＳ１０７で通知された鍵情報が入力されても解錠しないように制御する等でもよい。したがって、ステップＳ３０２以降は、ステップＳ１０７で通知された鍵情報で解錠しようとしても無効であり、ロッカーを使用することができない状態となる。

第３例は、第２例と異なり、鍵情報が通知された後にキャンセルがされた場合である。したがって、ロッカー管理システムＬＳは、キャンセルの入力に基づいて、通知された鍵情報を使用できないようにする。このような処理が行われると、本予約が成立した後でもユーザがキャンセルを行うことができ、利便性が向上する。

＜第４例＞
図１０は、全体処理例を示す図である。第３例と異なる点は、第３例と同様のタイミングでキャンセルがあったが、何らかの理由で無効化が行えない状態であった場合である。例えば、第１サーバＳＶ１及び第２サーバＳＶ２の間に通信障害等が起きると、キャンセルが入力されても、第３例のように、無効化を行うステップＳ３０２を実現するための通信ができない。そして、無効化を実行する前に、解錠がされた場合には（図では、「解錠された場合」である。）、ロッカー管理システムＬＳは、ステップＳ１０８に進む。

ステップＳ１０８では、ロッカー管理システムＬＳは、第１例と同様に、荷物が入れられたのを検出する。この検出結果が、使用情報Ｄ１に反映される。このように、使用情報Ｄ１において、「使用中」となった時間が課金の基準となってもよい。

すなわち、無効化が実行される前であり、鍵情報及びロッカー情報がユーザに通知された後であると、ユーザは、ロッカーを解錠してロッカーを使用できる。したがって、無効化が実行される前にロッカーの使用が開始された場合には、第１例と同様に、予約されたとおりにロッカーが使用されると判断して、以降、例えば、第１例と同様の処理を行う。

この場合には、キャンセル及び無効化が中止される。

第１サーバＳＶ１及び第２サーバＳＶ２の間に通信障害等が起きると、鍵情報等を無効化ができない、又は、鍵情報の無効化が遅れる場合がある。このように、鍵情報の無効化がされる前に、ロッカーが使用された場合には、予約がされたとおりに使用させる。したがって、キャンセルによって第１予約及び第２予約等を削除した場合には、削除した第１予約及び第２予約を回復させてもよい。

通信障害は、無線による通信等で起きやすい。例えば、携帯電話用の無線等を利用する通信は、携帯電話が近くに多くいる、すなわち、多くの携帯電話が同じような位置で同じ通信帯域を利用すると、通信回線が狭くなり、通信が遅れたり、通信が不可能になったりする場合がある。

第４例は、第３例と異なり、鍵情報の無効化が遅延又は不可能な場合である。したがって、ロッカー管理システムＬＳは、キャンセル及び無効化を中止して、ロッカーを使用できるようにする。このような処理が行われると、通信障害等があっても、ロッカーの管理に支障が少なく、利便性が向上する。

＜第５例＞
図１１は、全体処理例を示す図である。第１例と比較すると、ステップＳ１０７、すなわち、ロッカー情報及び鍵情報が通知されるまでは、第１例と同様である。そして、第２例乃至第４例とは異なり、第５例では、キャンセルの入力はない場合である。

第１例と異なるのは、第５例は、本予約が成立していても、キャンセルもなく、ユーザが荷物をロッカーへ入れない点である。例えば、開始時刻となると（図では、「開始時刻になった場合」である。）、ロッカー管理システムＬＳは、ステップＳ５０１に進む。

ステップＳ５０１では、ロッカー管理システムＬＳは、本予約の対象となるロッカーを「使用中」とみなす。なお、「使用中」とみなされるため、実際には荷物が入っていないため、実際に荷物が入っている「使用中」と、「使用中」とみなされている「使用中」とは、別の状態で使用情報Ｄ１に記録されてもよい。

なお、ステップＳ５０１で「使用中」とみなされている場合であっても、ユーザが遅れてきて使用を開始した場合には、ロッカーを解錠、すなわち、ロッカーを実際に使用させるようにしてもよい。

このように、本予約が行われ、かつ、開始時刻が経過した場合には、実際の使用がなくとも使用されているとみなし、課金等が行われてもよい。

図示するように、使用中とみなされている間は、ステップＳ１０７で通知した鍵情報等は有効であるため、ユーザは遅れてもロッカーを利用できる。また、ユーザが遅れても、予約した開始時刻乃至終了時刻の間では、鍵情報は有効であり、施錠されているため、他の人によって使用されることが少ない。

第５例は、第１例等と異なり、実際にロッカーが使用されない又は使用が遅れて開始される場合である。このような場合には、予約された開始時刻からロッカーが使用されているとみなすように処理を行うのが望ましい。したがって、ユーザが遅れて使用を開始しようとしても、ロッカーが確保されているため、ユーザは、ロッカーを使用できるようにする。このような処理が行われると、ユーザが遅れる等があっても、ユーザはロッカーを利用でき、利便性が向上する。

＜第６例＞
図１２は、全体処理例を示す図である。第１例と比較すると、第６例は、第１サーバＳＶ１及び第２サーバＳＶ２の間に通信障害が発生した場合である点が異なる。このように、通信障害等で通信が阻害されると、ステップＳ１０１によって検出結果が取得できなかったり、ステップＳ１０４によって、生成された鍵情報が取得できなかったりして、第１サーバＳＶ１及び第２サーバＳＶ２の間で情報が送受信できない、又は、送受信が遅れる。したがって、ロッカー管理システムＬＳは、使用情報Ｄ１及び鍵情報一覧Ｄ２等を速やかに更新できない場合がある。

このように、通信障害等の阻害がある場合には、第１予約が所定条件を満たす場合には（図では、「第１予約が所定条件を満たした場合」）、ロッカー管理システムＬＳは、ステップＳ６０１に進む。

ステップＳ６０１では、ロッカー管理システムＬＳは、本予約が成立しないのを通知する。すなわち、ロッカー管理システムＬＳは、本予約を中断する。したがって、ロッカー管理システムＬＳは、図１におけるステップＳ１０６以降の処理を実行させるのを待機させる等でもよい。

なお、ロッカー管理システムＬＳは、通信障害が回復し、使用情報Ｄ１及び鍵情報一覧Ｄ２が更新されたと判断すると、ステップＳ１０６等を行うように再開してもよい。

通信障害等により、使用情報Ｄ１及び鍵情報一覧Ｄ２等が取得できない場合には、本予約を成立させると、使用できない鍵情報をユーザに通知してしまったり、使用中のロッカーを割り当てる可能性があったりする。そこで、通信障害等が収まり、使用情報Ｄ１及び鍵情報一覧Ｄ２等が取得できる状態になるまで、ロッカー管理システムＬＳは、第２予約を行うのを中断するのが望ましい。

第６例は、第１例等と異なり、第１サーバＳＶ１及び第２サーバＳＶ２の間等が通信できない場合等である。このような場合には、使用情報及び鍵情報が正確でない場合がある。したがって、ロッカーの検出結果及び鍵情報の取得が阻害され、情報が不明確な場合には、ロッカー管理システムＬＳは、本予約を成立させないようにする。このような処理が行われると、ユーザに誤った情報等が通知されたり、ユーザが予約をしたのにロッカーを利用できないといった事態が発生するのを少なくしたりでき、利便性が向上する。

＜第７例＞
図１３は、全体処理例を示す図である。第７例は、第１例等と比較すると、前のユーザが予定していた終了時刻を経過しても使用し続けている、いわゆる「延滞」が起きている点が異なる。なお、この例では、延滞されている以外のロッカーもすべて埋まっているとする。

まず、仮予約、すなわち、ステップＳ１０５までは、第７例でも、第１例と同様の処理であるため、説明を省略する。

次に、判断時点ＪＴになっても、延滞により、空きロッカーがない場合には（図において「判断時点になった場合」である。）、ロッカー管理システムＬＳは、ステップＳ７０１に進む。

ステップＳ７０１では、ロッカー管理システムＬＳは、本予約が成立しないのを通知する。すなわち、ロッカー管理システムＬＳは、所定条件等が満たされても、本予約を中止する。

判断時点ＪＴは、例えば、所定条件を満たした場合の時点等である。すなわち、本予約を開始時刻より１５分前に行う場合には、判断時点ＪＴを同じとして、ロッカー管理システムＬＳは、１５分前になっても空きロッカーがない場合には、本予約が成立しないと判断する。したがって、どのタイミングで本予約を行わないようにするか、すなわち、判断時点ＪＴは、あらかじめ設定できるのが望ましい。

第７例は、第１例等と異なり、延滞等により、空きロッカーがなく、判断時点ＪＴにおいて、ロッカーの使用が不可能の場合等である。このような場合には、ユーザがロッカーを使用できないため、ロッカー管理システムＬＳは、本予約を成立させないようにする。このような処理が行われると、ロッカーが利用できないのを知ることができ、利便性が向上する。

例えば、ステップＳ７０１は、以下のような通知を行う。

図１４は、第２予約が不成立の通知例を示す図である。例えば、ステップＳ７０１では、図示するようなメッセージＭＥＳをメール等でユーザ端末に通知する。

図示するように、ロッカー管理システムは、第２予約が不成立であることを通知する。

なお、メッセージＭＥＳには、例えば、図示するように、代案ＡＬＴ等が更に通知されるのが望ましい。具体的には、代案ＡＬＴは、近くのロッカー等に、空きがないかを確認できるサイトへ誘導する通知又は他のロッカーにおける空きロッカーの有無等を示す通知の例である。

また、代案ＡＬＴは、図示するような通知でなくともよい。例えば、代案ＡＬＴは、予約等がなくとも使用できるロッカーが併設又は近くに設置されているような場合には、「一般ロッカー」を使うように案内する表示でもよい。

他にも、代案ＡＬＴは、近くにある別のロッカーを案内する地図等を示してもよい。さらに、代案ＡＬＴは、別の使用時間等を案内してもよい。例えば、「１５分後」であれば、第２予約台帳等における終了時刻に基づいて、空きロッカーが発生する可能性がある場合等には、代案ＡＬＴは、「１５分後」であれば使用が可能であると通知をしてもよい。

このように、代案が示されると、ユーザは、他のロッカー等へスムーズに移動できるため、利便性が向上する。

＜第８例＞
図１５は、全体処理例を示す図である。第８例は、第１例等と比較すると、設備の異常を検出する点が異なる。以下、ロッカーＬＣＫが何らかの理由等により、故障又は工事等であるとする。

ステップＳ８０１では、ロッカー管理システムＬＳは、ロッカーＬＣＫの異常を検出する。例えば、ロッカーＬＣＫの異常を検出した結果は、使用情報Ｄ１等で管理する。

このような場合には、ロッカー管理システムＬＳは、異常が検出されたロッカーＬＣＫを仮予約及び本予約の対象から外す。すなわち、ロッカー管理システムＬＳは、異常が検出されたロッカーＬＣＫを回避するように本予約を成立させる。

なお、回避は、異常が検出されたロッカーを「使用中」とみなす等でもよい。他にも、同じサイズがすべて異常であれば、仮予約において、空きロッカーがないため、仮予約を成立させないようにさせてもよい。

このように、異常と判断されたロッカーを回避して予約が行われると、ユーザに使用できないロッカーが割り当てられることが少なくなり、ロッカーを利用できないといった事態が発生するのを少なくでき、利便性が向上する。

＜第９例＞
図１６は、全体処理例を示す図である。第９例は、第８例等と比較すると、第２サーバＳＶ２に関する設備で異常を検出する点が異なる。以下、第２サーバＳＶ２が何らかの理由等により、故障又は工事等であるとする（以下「故障」が原因とする例で説明する）。また、異常と判断された第２サーバＳＶ２又は第２サーバＳＶ２の周辺機器等は、入れ替えられて復旧させるとする。

この例では、故障ＡＣＤが起きる前に、ステップＳ９０１を定期的又は手動のタイミング等で、ロッカーＬＣＫ及びロッカー管理システムＬＳは、ステップＳ９０１を行う。

ステップＳ９０１では、ロッカーＬＣＫ、第２サーバＳＶ２及び第１サーバＳＶ１は、情報を同期させる。例えば、鍵情報等が同期化される情報である。例えば、ステップＳ９０１は、１日１回等のように、あらかじめ設定された頻度で実行される。

なお、同期は、３装置の間で行わなくともよい。例えば、鍵情報は、第２サーバＳＶ２が生成しても、情報として記憶しない場合等には、第２サーバＳＶ２とは同期化が不要である。このような場合には、同期化は、第１サーバＳＶ１が鍵情報一覧Ｄ２に記憶するそれぞれの鍵情報が、それぞれのロッカーＬＣＫで使用できるようにすればよい。ただし、同期化において、ロッカーＬＣＫに鍵情報を送るのに、第２サーバＳＶ２を介する経路で、鍵情報の同期化がされてもよい。

他にも、同期化には、更に別の情報処理装置が加わってもよい。

そして、故障ＡＣＤが起きた後、第２サーバＳＶ２が復旧した場合（図では、「第２サーバの復旧後」である。）には、ロッカーＬＣＫ及びロッカー管理システムＬＳは、ステップＳ９０２を行い、鍵情報等を同期化させるのが望ましい。

ステップＳ９０２では、ロッカーＬＣＫ、第２サーバＳＶ２及び第１サーバＳＶ１は、情報を同期させる。すなわち、ロッカーＬＣＫ、第２サーバＳＶ２及び第１サーバＳＶ１の間で、あらかじめステップＳ９０１でバックアップさせてあった情報を復旧させる。

このように、故障ＡＣＤ前に同期化によりバックアップがされると、復旧後に鍵情報等の情報が、第１サーバＳＶ１等にバックアップできる。このようなバックアップ等があると、ロッカー管理システムＬＳは、故障等により、第２サーバＳＶ２等が入れ替えとなっても、復旧後、速やかにロッカーの管理を再開できる。

なお、故障ＡＣＤからステップＳ９０２が完了するまでは、ロッカー管理システムは、第１予約及び第２予約を中止してもよい。

＜第１０例＞
図１７は、全体処理例を示す図である。例えば、ロッカー管理システムＬＳは、図示するようにもロッカーの使用を受け付ける。以下、このような入力を「使用申込」という。

例えば、使用申込は、仮予約と同じ項目を入力して行われる。なお、使用申込と仮予約は、異なる項目で入力をしてもよい。以下、使用申込と仮予約の入力が同じ項目であるとする。以下、ステップＳ１０４までの処理は、第１例と同様に処理されるとし、重複する説明を省略する。

使用申込があると（図では、「使用申込」の入力があった場合）である。）、ロッカー管理システムＬＳは、ステップＳ１００１に進む。

ステップＳ１００１では、ロッカー管理システムＬＳは、使用申込を受け付ける。例えば、ロッカー管理システムＬＳは、ステップＳ１０５と同様に使用申込の際に入力される項目を受け付ける。

以下、使用申込が受け付けられると、例えば、第１例と同様に、ステップＳ１０６以降の処理等によって第２予約が行われるとする。

第１例と異なるのは、使用申込は、第１予約が行われずに、第２予約が行われる点が異なる。

使用申込は、いわゆる即時予約である。例えば、使用申込は、所定条件が既に満たされている状態等で行われる操作となる。具体的には、ユーザが速やかにロッカーを使用したいと希望するような場合である。したがって、使用申込では、開始時刻を入力しない、現在時刻を入力する、「今から使用する」等の選択肢が設定される、又は、「即時予約」と「仮予約」が選べる形式等でもよい。一方で、使用申込であっても、終了時刻は入力されるのが望ましい。なお、終了時刻は、例えば、第１予約と同様の方法で入力される。

したがって、使用申込が入力された場合には、本予約が成立する、すなわち、空きロッカーがある等の条件を満たせば、鍵情報等が速やかにユーザ端末ＳＭに送信される（ステップＳ１０７）。

このように、予約と使用申込の２通りの方法があると、ユーザが速やかにロッカーを使用したい場合でも、あらかじめに予約してロッカーを使用したい場合でもロッカー管理システムは対応することができる。そのため、ユーザの利便性を向上できる。

＜第１１例＞
図１８は、全体処理例を示す図である。使用申込もキャンセルできる構成であるのが望ましい。例えば、使用申込のキャンセルは、第３例と同様に行われる。

まず、使用申込に基づいて、第２予約が行われる処理は、第１０例と同様であるため、説明を省略する。次に、ステップＳ１０７の後に、キャンセルの入力がされると、ステップＳ１１０１が行われる。

ステップＳ１１０１では、ロッカー管理システムＬＳは、使用申込のキャンセルを受け付ける。以降、使用申込のキャンセルが入力されると、ロッカー管理システムＬＳは、例えば、第３例と同様に、ステップＳ３０１に進む。以下、第３例と同様に、キャンセルに基づいて、鍵情報等を無効化する。なお、無効化は、例えば、第３例と同様である。

また、第３例と同様に、キャンセルの結果がステップＳ２０３によって通知されてもよい。

使用申込は、鍵情報が通知された後にキャンセルがされた場合、すなわち、第３例と同様の方法でキャンセルが行われるのが望ましい。したがって、ロッカー管理システムＬＳは、キャンセルの入力に基づいて、通知された鍵情報を使用できないようにする。このような処理が行われると、使用申込があってもユーザがキャンセルを行うことができ、利便性が向上する。

＜機能構成例＞
図１９は、機能構成例を示す図である。例えば、第１情報処理装置の例である、第１サーバＳＶ１は、記憶部ＦＮ１１と、取得部ＦＮ１２と、受付部ＦＮ１３と、予約部ＦＮ１４と、通知部ＦＮ１５とを含む機能構成である。また、第２サーバＳＶ２は、例えば、検出部ＦＮ２１と、送信部ＦＮ２２と、鍵情報生成部ＦＮ２３とを含む機能構成である。

図示するように、ロッカー管理システムＬＳは、キャンセル部ＦＮ１６と、無効化部ＦＮ２４とを更に含む機能構成であるのが望ましい。以下、図示する機能構成を例に説明する。

まず、図示するように、第１サーバＳＶ１は、第１予約ＲＶ１及び使用申込ＵＡを入力する。また、第１サーバＳＶ１には、あらかじめ所定条件ＰＲが設定される。

記憶部ＦＮ１１は、予約の際に入力されるロッカーの開始時刻及び終了時刻を示す第１予約を記憶する記憶手順を行う。例えば、記憶部ＦＮ１１は、記憶装置ＨＷ２等で実現する。

取得部ＦＮ１２は、第２サーバＳＶ２から、使用情報Ｄ１及び鍵情報ＤＫを取得する取得手順を行う。例えば、取得部ＦＮ１２は、ネットワークインタフェースＨＷ３等で実現する。

受付部ＦＮ１３は、使用申込ＵＡを受け付ける受付手順を行う。例えば、受付部ＦＮ１３は、ネットワークインタフェースＨＷ３等で実現する。

予約部ＦＮ１４は、所定条件ＰＲを満たし、かつ、使用情報Ｄ１に基づいて、空きロッカーがあると判断されると、第１予約ＲＶ１に基づいて第２予約ＲＶ２を行う、又は、使用申込ＵＡを受け付けると、第２予約ＲＶ２を行う予約手順を行う。例えば、予約部ＦＮ１４は、ＣＰＵＨＷ１等で実現する。

通知部ＦＮ１５は、第２予約ＲＶ２が行われると、ロッカー情報ＤＬ、及び、鍵情報ＤＫをユーザＵＲに通知する通知手順を行う。例えば、通知部ＦＮ１５は、ネットワークインタフェースＨＷ３等で実現する。

キャンセル部ＦＮ１６は、第１予約ＲＶ１に対するキャンセルＣＬ、又は、使用申込に対するキャンセルＣＬを入力するキャンセル手順を行う。例えば、キャンセル部ＦＮ１６は、ネットワークインタフェースＨＷ３等で実現する。

検出部ＦＮ２１は、ロッカーＬＣＫのうち、使用中である使用中ロッカーを検出して、検出結果ＲＳを出力する検出手順を行う。例えば、検出部ＦＮ２１は、インタフェースＨＷ６等で実現する。

送信部ＦＮ２２は、使用情報Ｄ１及び鍵情報ＤＫを第１サーバＳＶ１に送信する送信手順を行う。例えば、送信部ＦＮ２２は、ネットワークインタフェースＨＷ３等で実現する。

鍵情報生成部ＦＮ２３は、鍵情報ＤＫを生成する鍵情報生成手順を行う。例えば、鍵情報生成部ＦＮ２３は、ＣＰＵＨＷ１等で実現する。

無効化部ＦＮ２４は、キャンセルＣＬの対象となる鍵情報ＤＫを無効化させる無効化手順を行う。例えば、無効化部ＦＮ２４は、ＣＰＵＨＷ１等で実現する。

＜まとめ＞
以上のように、第１予約が入力できる構成であると、ロッカー管理システムは、いわゆる「仮予約」が可能となる。そして、ロッカー管理システムは、所定条件を満たし、かつ、空きロッカーがある等の条件を満たすと、第１予約に基づいて第２予約、すなわち、「本予約」を行う。このように、第２予約がされると、ユーザは、ロッカーを事前に予約して使用できる。一方で、ロッカー管理システムは、速やかにロッカーを使用したい場合等のため、使用申込を入力できる構成である。このように、使用申込が入力された場合には、ロッカー管理システムは、空きロッカーがある等の条件を満たしていれば、「本予約」を速やかに行う。

このように、第１予約又は使用申込のいずれもが入力できる構成であると、ユーザの状況に応じて、ロッカーを確保しようとするため、ユーザは、事前にロッカーを予約して使用したり、速やかにロッカーを使用したりできる。このように、ロッカー管理システムは、ユーザがロッカーを使用する上での利便性を向上させることができる。

＜変形例＞
例えば、ロッカー管理システムは、以下のような情報を生成、又は、あらかじめ入力して用いてもよい。

図２０は、算出結果データの例を示す図である。図示する算出結果データＤＣＬが示す例において、「グループＮｏ．」及び「サイズ」は、図６及び図７等と同様の項目である。また、「空きロッカーの数」は、各グループにおいて、サイズごと、それぞれの空きロッカーの数を示す。

第１サーバＳＶ１等には、ロッカーデータＤＬＣＫがあらかじめ記憶されると、各間口に対応するロッカーのサイズ及びグループを特定することができる。したがって、各情報処理装置は、例えば、検出結果によって、「空き」の状態であるロッカーがどのようなサイズであるかを特定できる。

具体的には、図示する算出結果データＤＣＬの例では、例えば、「Ｌ２００１」のグループにおいて、「小」のサイズで「空き」の状態であるロッカーが１つであれば、空きロッカーの数は、「１」である。したがって、算出結果データＤＣＬでは、「Ｌ２００１」における「小」の「空きロッカーの数」は、「１」となる。

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

以上のように算出すると、第１サーバＳＶ１等は、グループごと、及び、サイズごと、空きロッカーの数を算出できる。なお、空きロッカーの数に限られず、「使用中」のロッカー又は「使用中」と「空き」の両方を算出する構成等でもよい。

図２１は、ロッカーデータの例を示す図である。図示する例では、ロッカーデータＤＬＣＫは、「グループＮｏ．」と、「ロッカー間口Ｎｏ．」と、「サイズ」とを対応させるデータである。したがって、図示するようなロッカーデータＤＬＣＫ等があると、ロッカー情報等が生成できる。

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

「ロッカー間口Ｎｏ．」は、図５等の同様である。すなわち、「ロッカー間口Ｎｏ．」は、例えば、シリアル番号又は管理番号等である。

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

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

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

＜他の実施形態＞
ロッカーは、図示するように、予約又は使用申込が行われて使用されるロッカーとは別に、予約等を行わなくとも使用可能なロッカーが混在又は併設されているのが望ましい。また、ロッカー管理システムは、他のロッカーの場所及び他のロッカーの使用情報等を把握又は他のロッカー管理システム等と共有してもよい。

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

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

また、本発明の一実施形態に係る各処理は、図示した手順に限られない。例えば、各処理の一部又は全部は、異なる順序、並行、分散又は省略されて処理されてもよい。すなわち、ロッカー管理システムは、上記に説明した以外の情報処理装置を更に有する又はネットワーク等を介して他の情報処理装置と接続してもよい。このようにして、処理を分散、並列、若しくは、冗長して実行、又は、データを分散、若しくは、冗長して記憶してもよい。

さらに、各情報処理装置は、機械学習等によって学習処理を行ってもよい。すなわち、各情報処理装置は、いわゆるＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）等を利用する構成でもよい。

また、各情報処理装置は、いわゆるＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）を利用する、すなわち、ネットワーク等を介して接続されるセンサ等からデータを取得してもよい。

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

ＡＣＤ 故障
ＡＬＴ 代案
ＣＬ キャンセル
ＣＴＬ 操作端末
Ｄ１ 使用情報
Ｄ２ 鍵情報一覧
Ｄ３ 第１予約台帳
Ｄ４ 第２予約台帳
ＤＣＬ 算出結果データ
ＤＫ 鍵情報
ＤＬ ロッカー情報
ＤＬＣＫ ロッカーデータ
ＦＮ１１ 記憶部
ＦＮ１２ 取得部
ＦＮ１３ 受付部
ＦＮ１４ 予約部
ＦＮ１５ 通知部
ＦＮ１６ キャンセル部
ＦＮ２１ 検出部
ＦＮ２２ 送信部
ＦＮ２３ 鍵情報生成部
ＦＮ２４ 無効化部
ＪＴ 判断時点
ＬＣＫ ロッカー
ＬＳ ロッカー管理システム
ＭＥＳ メッセージ
ＰＲ 所定条件
ＲＳ 検出結果
ＳＭ ユーザ端末
ＳＶ１ 第１サーバ
ＳＶ２ 第２サーバ
ＵＡ 使用申込
ＵＲ ユーザ

Claims (11)

1. ユーザによるロッカーの第１予約又は使用申込を入力する第１情報処理装置と、
   前記第１情報処理装置と通信を行い、かつ、前記ロッカーを管理する第２情報処理装置とを有するロッカー管理システムであって、
   前記第１情報処理装置は、
   前記ロッカーの開始時刻及び終了時刻を示す前記第１予約を記憶する記憶部と、
   前記第２情報処理装置から、前記ロッカーの使用状況を示す検出結果に基づいて生成される使用情報、及び、前記ロッカーを開閉するのに用いる鍵情報を取得する取得部と、
   前記使用申込を受け付ける受付部と、
   所定条件を満たし、かつ、前記使用情報に基づいて空きロッカーがあると判断されると、前記第１予約に基づいて第２予約を行う、又は、前記使用情報に基づいて空きロッカーがあると判断され、かつ、前記使用申込を受け付けると、前記第２予約を行う予約部と、
   前記第２予約が行われると、前記ロッカーのうち、前記開始時刻から前記終了時刻の間、使用できるロッカーを特定するロッカー情報、及び、前記ロッカー情報で特定されるロッカーを開閉するのに用いる前記鍵情報を前記ユーザに通知する通知部と
   を含み、
   前記第２情報処理装置は、
   前記ロッカーのうち、使用中である使用中ロッカーを検出して、前記検出結果を出力する検出部と、
   前記鍵情報を生成する鍵情報生成部と、
   前記使用情報及び前記鍵情報を前記第１情報処理装置に送信する送信部とを含む
   ロッカー管理システム。
2. 前記第１情報処理装置は、
   前記第１予約に対するキャンセルを入力するキャンセル部と更に含み、
   前記第１予約を行った後であって、かつ、前記第１予約が所定条件を満たす前に、前記キャンセルが入力されると、
   前記キャンセルの対象となる前記第１予約を削除し、
   前記予約部は、前記第２予約を中止する
   請求項１に記載のロッカー管理システム。
3. 前記第１情報処理装置は、
   前記第１予約に対するキャンセルを入力するキャンセル部を更に含み、
   前記第２情報処理装置は、
   前記第１予約を行った後であって、かつ、前記第１予約が所定条件を満たした後に、前記キャンセルが入力されると、前記キャンセルの対象となる前記鍵情報を無効化させる無効化部を更に含む
   請求項１に記載のロッカー管理システム。
4. 前記キャンセルが入力され、かつ、前記鍵情報が無効化される前に、前記ロッカーが使用されると、
   前記キャンセル及び前記鍵情報の無効化を中止する
   請求項３に記載のロッカー管理システム。
5. 前記第２予約が行われ、かつ、前記開始時刻が経過すると、
   前記第２予約が行われた前記ロッカーが使用されているとみなす
   請求項１乃至４のいずれか１項に記載のロッカー管理システム。
6. 前記取得部による前記ロッカーの検出結果、前記鍵情報又はこれらのいずれか一方の取得が阻害されると、
   前記予約部は、前記第２予約を中断する
   請求項１乃至５のいずれか１項に記載のロッカー管理システム。
7. 判断時点において、前記ロッカーの使用が不可能であると、
   前記予約部は、前記第２予約を中断する
   請求項１乃至６のいずれか１項に記載のロッカー管理システム。
8. 前記通知部は、
   前記ロッカーの使用が不可能である通知を行い、かつ、代案を示す
   請求項７に記載のロッカー管理システム。
9. 前記ロッカーの異常を検出し、
   前記予約部は、
   異常であると判断された前記ロッカーを回避して前記第２予約を行う
   請求項１乃至８のいずれか１項に記載のロッカー管理システム。
10. 前記第１情報処理装置は、
    前記使用申込に対するキャンセルを入力するキャンセル部を更に含み、
    前記第２情報処理装置は、
    前記使用申込に対するキャンセルが入力されると、前記キャンセルの対象となる前記鍵情報を無効化させる無効化部を更に含む
    請求項１乃至９のいずれか１項に記載のロッカー管理システム。
11. ユーザによるロッカーの第１予約又は使用申込を入力する第１情報処理装置と、
    前記第１情報処理装置と通信を行い、かつ、前記ロッカーを管理する第２情報処理装置とを有するロッカー管理システムが行うロッカー管理方法であって、
    前記第１情報処理装置が、前記ロッカーの開始時刻及び終了時刻を示す前記第１予約を記憶する記憶手順と、
    前記第１情報処理装置が、前記第２情報処理装置から、前記ロッカーの使用状況を示す検出結果に基づいて生成される使用情報、及び、前記ロッカーを開閉するのに用いる鍵情報を取得する取得手順と、
    前記第１情報処理装置が、前記使用申込を受け付ける受付手順と、
    前記第１情報処理装置が、所定条件を満たし、かつ、前記使用情報に基づいて空きロッカーがあると判断されると、前記第１予約に基づいて第２予約を行う、又は、前記使用情報に基づいて空きロッカーがあると判断され、かつ、前記使用申込を受け付けると、前記第２予約を行う予約手順と、
    前記第１情報処理装置が、前記第２予約が行われると、前記ロッカーのうち、前記開始時刻から前記終了時刻の間、使用できるロッカーを特定するロッカー情報、及び、前記ロッカー情報で特定されるロッカーを開閉するのに用いる前記鍵情報を前記ユーザに通知する通知手順と、
    前記第２情報処理装置が、前記ロッカーのうち、使用中である使用中ロッカーを検出して、前記検出結果を出力する検出手順と、
    前記第２情報処理装置が、前記鍵情報を生成する鍵情報生成手順と、
    前記第２情報処理装置が、前記使用情報及び前記鍵情報を前記第１情報処理装置に送信する送信手順とを含む
    ロッカー管理方法。

Images