特開 2024-6055 情報処理方法、プログラム、情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024006055

(43)【公開日】2024-01-17

(54)【発明の名称】情報処理方法、プログラム、情報処理装置

(51)【国際特許分類】

   G06Q 10/109 20230101AFI20240110BHJP

   G06Q 10/0631 20230101ALI20240110BHJP

   G06Q 10/02 20120101ALI20240110BHJP

【ＦＩ】

G06Q10/10 340

G06Q10/06 302

G06Q10/02

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022106597

(22)【出願日】2022-06-30

(71)【出願人】

【識別番号】517060834

【氏名又は名称】株式会社コミュニティコム

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】星野 邦敏

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA03

5L049AA13

5L049AA20

(57)【要約】

【課題】予約時間にもかかわらず予約された部屋の利用がない場合に、他のユーザが空室となった貸室を安心して利用することができる情報処理方法等を提供すること。
【解決手段】情報処理方法は、媒体により開閉可能なスマートロックがドアに設けられた部屋の予約を受付け、前記スマートロックの動作に関する動作情報、および、前記部屋に対応して設けられたセンサ６０から得られるセンサ情報に基づき、予約時間にもかかわらず予約された前記部屋の利用がないと判断した場合に、前記部屋の新規予約が可能であることを示す通知を出力する処理をコンピュータに実行させる。
【選択図】図１

【特許請求の範囲】

【請求項1】

媒体により開閉可能なスマートロックがドアに設けられた部屋の予約を受付け、
前記スマートロックの動作に関する動作情報、および、前記部屋に対応して設けられたセンサから得られるセンサ情報に基づき、予約時間にもかかわらず予約された前記部屋の利用がないと判断した場合に、前記部屋の新規予約が可能であることを示す通知を出力する
情報処理方法。

【請求項2】

前記動作情報および前記センサ情報に基づき、予約開始時刻の一定時間経過後までに、前記部屋の利用がないと判断した場合に、通知を出力する
請求項１に記載の情報処理方法。

【請求項3】

前記動作情報および前記センサ情報に基づき、予約開始時刻の一定時間経過後までに、前記部屋の利用がないと判断した場合に、前記部屋に対する予約を受付ける
請求項１または請求項２に記載の情報処理方法。

【請求項4】

予約されている部屋へのキャンセル待ちを行った第１ユーザを登録し、
予約時間にもかかわらず予約された部屋への利用がなかった場合に新規予約を希望する第２ユーザを登録し、
予約が事前にキャンセルされた場合に、前記第１ユーザにキャンセル通知を出力し、
前記通知を第２ユーザに出力する
請求項１または請求項２に記載の情報処理方法。

【請求項5】

前記センサは、前記出入り口が面する通路に設置された撮像装置であり、
前記撮像装置により撮像された画像に基づき、前記部屋に入室する入室人数及び退室する退室人数を計数し、
計数した入室人数および退室人数に基づき室内の人数がゼロであり、かつ、前記予約開始時刻の一定時間経過後までに予約したユーザの前記スマートロックに対する開を示す動作情報を受付けていない場合に、利用がないと判断する
請求項１または請求項２に記載の情報処理方法。

【請求項6】

ユーザにより予約された部屋の予約時間に関する予約情報を取得し、
前記予約情報に基づいて、前記ユーザの部屋利用時間を算出し、
前記部屋利用時間に基づいて算出した利用料金を、前記ユーザのクレジットカードを介して請求する
請求項１または請求項２に記載の情報処理方法。

【請求項7】

ユーザにより予約された部屋の予約時間に関する予約情報を取得し、
前記予約情報に基づいて、前記部屋の予約が行われていない空時間を検出し、
前記空時間に対する新たな予約を受付ける
請求項１または請求項２に記載の情報処理方法。

【請求項8】

前記動作情報および前記センサ情報に基づき、予約終了時間経過後に退室が確認できない場合に、予約終了時間が経過した旨を示す通知を出力する
請求項１に記載の情報処理方法。

【請求項9】

前記センサは、前記出入り口が面する通路に設置された撮像装置であり、すべての部屋における一日の最後の予約時間経過後に、複数の前記出入口が面する通路に設置された前記撮像装置により撮像された画像に基づき、前記部屋に入室する入室人数及び退室する退室人数を計数し、
前記すべての部屋において、計数した入室人数及び退室人数に基づき室内の人数がゼロであると判断した場合に、すべての部屋においてユーザが退室した旨を示す通知を施設の管理者に出力する
請求項１に記載の情報処理方法。

【請求項10】

媒体により開閉可能なスマートロックがドアに設けられた部屋の予約を受付け、
前記スマートロックの動作に関する動作情報、および、前記部屋に対応して設けられたセンサから得られるセンサ情報に基づき、予約時間にもかかわらず予約された前記部屋の利用がないと判断した場合に、前記部屋の新規予約が可能であることを示す通知を出力する
処理をコンピュータに実行させるプログラム。

【請求項11】

制御部を備える情報処理装置であって、
前記制御部は、
媒体により開閉可能なスマートロックがドアに設けられた部屋の予約を受付け、
前記スマートロックの動作に関する動作情報、および、前記部屋に対応して設けられたセンサから得られるセンサ情報に基づき、予約時間にもかかわらず予約された前記部屋の利用がないと判断した場合に、前記部屋の新規予約が可能であることを示す通知を出力する
情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理方法、プログラム、情報処理装置に関する。

【背景技術】

【0002】

予約したにもかかわらず利用されない会議室の有効活用を図る方法が提案されている（特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１８－１８１２２３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１の管理方法では、室内にカメラを設置する必要があり、ユーザのプライバシーや、内密な情報を扱う会議に利用する場合等に問題がある。

【0005】

一つの側面では、予約時間にもかかわらず予約された部屋の利用がない場合に、他のユーザが空室となった貸室を安心して利用することができる情報処理方法等を提供することを目的とする。

【課題を解決するための手段】

【0006】

情報処理方法は、媒体により開閉可能なスマートロックがドアに設けられた部屋の予約を受付け、前記スマートロックの動作に関する動作情報、および、前記部屋に対応して設けられたセンサから得られるセンサ情報に基づき、予約時間にもかかわらず予約された前記部屋の利用がないと判断した場合に、前記部屋の新規予約が可能であることを示す通知を出力する処理をコンピュータに実行させる。

【発明の効果】

【0007】

一つの側面では、予約時間にもかかわらず予約された部屋の利用がない場合に、他のユーザが空室となった貸室を安心して利用することができる情報処理方法等を提供することができる。

【図面の簡単な説明】

【0008】

【図1】情報処理システムの構成を説明する説明図である。

【図2】情報処理装置、ユーザ端末の構成を説明する説明図である。

【図3】センサの構成を説明する説明図である。

【図4】センサの設置例を説明する説明図である。

【図5】入退室ＤＢのレコードレイアウトを説明する説明図である。

【図6】予約情報ＤＢのレコードレイアウトを説明する説明図である。

【図7】社員ＤＢのレコードレイアウトを説明する説明図である。

【図8】センサＤＢのレコードレイアウトを説明する説明図である。

【図9】人物の在否を判定するプログラムの処理の流れを説明するフローチャートである。

【図10】認証サーバが実行するプログラムの処理の流れを説明するフローチャートである。

【図11】予約したユーザが予約開始時刻を経過しても入室しなかった場合のプログラムの処理の流れを説明するフローチャートである。

【図12】部屋の利用状況を表示する画面例である。

【図13】予約時のプログラムの処理の流れを説明するフローチャートである。

【図14】予約受付画面の画面例である。

【図15】予約内容確認画面の画面例である。

【図16】予約終了時刻経過後に、ユーザが退室しない場合のプログラムの処理の流れを説明するフローチャートである。

【図17】退室すべき旨を表示する画面の画面例である。

【図18】実施の形態２の情報処理装置の構成を説明する説明図である。

【図19】第１グループＤＢのレコードレイアウトを説明する説明図である。

【図20】第２グループＤＢのレコードレイアウトを説明する説明図である。

【図21】実施の形態２のプログラムの処理の流れを説明するフローチャートである。

【図22】実施の形態３のプログラムの処理の流れを説明するフローチャートである。

【図23】管理画面の画面例である。

【図24】実施の形態４の情報処理装置の構成を説明する説明図である。

【図25】実施の形態４の社員ＤＢのレコードレイアウトを説明する説明図である。

【図26】請求ＤＢのレコードレイアウトを説明する説明図である。

【図27】実施の形態４の予約情報ＤＢのレコードレイアウトを説明する説明図である。

【図28】料金を請求する処理を実行するプログラムの処理の流れを説明するフローチャートである。

【図29】日料金算出のサブルーチンの処理の流れを説明するフローチャートである。

【発明を実施するための形態】

【0009】

［実施の形態１］
図１は、情報処理システム１０の構成を説明する説明図である。本実施の形態では部屋の提供を管理する情報処理システム１０を例にして説明する。本実施の形態の部屋は、たとえば、企業内の会議室等である。部屋は有償または無償でユーザに提供される。部屋は、企業内の会議室でなくてもよく、たとえば貸会議室、コワーキングスペース、ランニングマシン等の運動器具が設置された運動ジム、または、コミックおよび書籍等が配置された読書スペース等であってもよい。

【0010】

情報処理システム１０は、情報処理装置２０、ユーザ端末３０、認証サーバ４０、センサ６０、ゲート部１１、社員証１５を備える。社員証１５は、部屋を利用するそれぞれのユーザが所持する。部屋の提供が、会社等のオフィス内で行われない場合等には、社員証１５は、会員証であってもよく、社員証１５を固有に識別する社員証ＩＤは、会員証ＩＤであってもよい。

【0011】

ゲート部１１は、部屋を囲む壁の一部分に設けられている。ゲート部１１は、ドア等の出入り口１２、出入り口１２のロックおよびロック解除を行う鍵機構１３、壁の外側に配置された第１リーダ１４１、壁の内側に配置された第２リーダ１４２を含む。以下の説明では、第１リーダ１４１と第２リーダ１４２とを区別する必要がない場合には、リーダ１４と記載する場合がある。

【0012】

リーダ１４および鍵機構１３は、ネットワークに接続して使用される、いわゆるＩｏＴ（Internet of Things）機器である。鍵機構１３と、リーダ１４と、社員証１５と、認証サーバ４０とは、ネットワークを介して施錠および解錠の操作が可能な、いわゆるスマートロックを構成する。

【0013】

第１リーダ１４１は、部屋の外側から出入り口１２を開けて入室したユーザに関する情報を取得する。第２リーダ１４２は、部屋の内側から出入り口１２を開けて退室したユーザに関する情報を取得する。

【0014】

認証サーバ４０は、ネットワークを介してリーダ１４および鍵機構１３を制御するサーバである。認証サーバ４０は、制御部４１、主記憶部４２、補助記憶部４３、通信部４４およびバスを備える。制御部４１は、本実施の形態のプログラムを実行する演算制御装置である。制御部４１には、一または複数のＣＰＵ（Central Processing Unit）またはマルチコアＣＰＵ等が使用される。制御部４１は、バスを介して認証サーバ４０を構成するハードウェア各部と接続されている。

【0015】

主記憶部４２は、ＳＲＡＭ（Static Random Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の記憶装置である。主記憶部４２には、制御部４１が行う処理の途中で必要な情報および制御部４１で実行中のプログラムが一時的に保存される。

【0016】

補助記憶部４３は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶部４３には、入退室ＤＢ５１と予約情報ＤＢ５２、制御部４１に実行させるプログラムおよびプログラムの実行に必要な各種データが保存される。通信部４４は、認証サーバ４０とネットワークとの間の通信を行うインターフェイスである。

【0017】

リーダ１４は、たとえばＮＦＣ（Near field Communication）を用いて社員証１５に記録された社員証ＩＤを読み取り、認証サーバ４０に送信する。第１リーダ１４１および第２リーダ１４２は、バーコードリーダであり、社員証１５の表面にバーコードで表示された社員証ＩＤを読み取ってもよい。

【0018】

社員証ＩＤは、ＩＣカードに記録されていてもよく、また、スマートフォン等のユーザ端末３０を介して表示できるものとしてもよい。

【0019】

制御部４１は、社員証１５が有効であるか否かを判定する。社員証１５が有効であると判定した場合、制御部４１は鍵機構１３を制御して出入り口１２のロックを解除する。以上により、社員証１５をリーダ１４に読み取らせたユーザは、出入り口１２を通過できる。

【0020】

所定時間の経過後、またはセンサ６０によりユーザの通過を検知した後に、制御部４１は、鍵機構１３を制御して自動的に出入り口１２をロックする。鍵機構１３は、所定時間の経過後、またはユーザの通過を検知した後に自律的に出入り口１２をロックしてもよい。制御部４１により行われる処理は、情報処理装置２０により行われてもよい。

【0021】

図２は、情報処理装置２０、ユーザ端末３０の構成を説明する説明図である。図２を使用して、情報処理２０、ユーザ端末３０の構成を説明する。

【0022】

情報処理装置２０は、制御部２１、主記憶部２２、補助記憶部２３、通信部２４、表示部２５１、入力部２５２およびバスを備える。制御部２１は、プログラムを実行する演算処理装置である。制御部２１は、バスを介して情報処理装置２０を構成するハードウェア各部と接続されている。

【0023】

主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶部２２には、制御部２１が行う処理の途中で必要な情報および制御部２１で実行中のプログラムが一時的に保存される。

【0024】

補助記憶部２３は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶部２３には、入退室ＤＢ５６、予約情報ＤＢ５７、社員ＤＢ５８、センサＤＢ５９、制御部２１に実行させるプログラムおよびプログラムの実行に必要な各種データが保存される。通信部２４は、情報処理装置２０とネットワークとの間の通信を行うインターフェイスである。

【0025】

表示部２５１は、液晶表示パネルまたは有機ＥＬ表示パネル等である。入力部２５２は、キーボード、マウスおよびマイク等である。表示部２５１と入力部２５２とは、積層されてタッチパネルを構成していてもよい。

【0026】

情報処理装置２０は、部屋が設置されている施設の管理者が使用する汎用のパソコン、スマートフォン、タブレット、大型計算機、または大型計算機上で動作する仮想マシンである。情報処理装置２０は、分散処理を行う複数のコンピュータ、または大型計算機等のハードウェアにより構成されていてもよい。情報処理装置２０は、クラウドコンピューティングシステムにより構成されていてもよい。

【0027】

ユーザ端末３０は、制御部３１、主記憶部３２、補助記憶部３３、通信部３４、タッチパネル３５およびバスを備える。制御部３１は、本実施の形態のプログラムを実行する演算制御装置である。制御部３１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。制御部３１は、バスを介してユーザ端末３０を構成するハードウェア各部と接続されている。

【0028】

主記憶部３２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶部３２には、制御部３１が行う処理の途中で必要な情報および制御部３１で実行中のプログラムが一時的に保存される。

【0029】

補助記憶部３３は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶部３３には、制御部３１に実行させるプログラムおよびプログラムの実行に必要な各種データが保存される。通信部３４は、ユーザ端末３０とネットワークとの間の通信を行うインターフェイスである。タッチパネル３５は、液晶表示パネルまたは有機ＥＬ表示パネル等の表示部３５１と入力部３５２とが積層された構成を有する。

【0030】

ユーザ端末３０は、部屋を利用するそれぞれのユーザが利用する汎用のスマートフォン、タブレット、パソコン等である。

【0031】

図３は、センサ６０の構成を説明する説明図である。図３を使用して、センサ６０の構成を説明する。本実施の形態におけるセンサ６０は、部屋の出入り口１２が面する通路に設置された防犯カメラを例に説明する。センサ６０は、ＴｏＦ（Time of Flight）方式のセンサ、赤外線センサ、ＬｉＤＡＲ（Light Detection And Ranging）、またはサーモグラフィ等であってもよい。センサ６０は、部屋の出入り口１２を通過する人物を検出し、それぞれの人物の通過する方向によって、入室か退室かを判定する。

【0032】

判定は、ＹＯＬＯ（You Only Look Once）、ＳＳＤ（Single Shot Multi-Box Detector）、ＳｅｇＮｅｔ、ＦＣＮ（Fully Convolutional Network）等の学習モデルまたはオプティカルフロー等により行われる。すなわち、センサ６０により得られる、対象エリアの複数の時点の撮像画像のそれぞれから、人物を検出し、検出結果に基づき人物の進む方向によって、入室か退室かを判定する。

【0033】

センサ６０は、制御部６１、主記憶部６２、補助記憶部６３、通信部６４、検知部６５を備える。制御部６１は、本実施の形態のプログラムを実行する演算制御装置である。制御部６１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。制御部６１は、バスを介してセンサ６０を構成するハードウェア各部と接続されている。

【0034】

主記憶部６２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶部６２には、制御部６１が行う処理の途中で必要な情報および制御部６１で実行中のプログラムが一時的に保存される。

【0035】

補助記憶部６３は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶部６３には、制御部６１に実行させるプログラムおよびプログラムの実行に必要な各種データが保存される。通信部６４は、センサ６０とネットワークとの間の通信を行うインターフェイスである。検知部６５は、撮像素子またはセンサ素子である。検知部６５により取得した画像は、通信部６４を介して、情報処理装置２０へ出力される。

【0036】

図４は、センサ６０の設置例を説明する説明図である。図４Ａは、複数の出入り口１２が面した廊下の天井付近にセンサ６０が設置されている。一のセンサ６０は、複数の出入り口１２を一括して撮像する。センサ６０は各出入り口１２付近の対象エリアごとに、出入り口１２を通過する人物を撮像する。
本実施の形態におけるセンサ６０の設置例は、図４Ａとして説明する。

【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】

制御部４１は、リーダ１４に設けられた図示を省略するＬＥＤ（Light Emitted Diode）を点滅させてエラー通知を出力してもよい。制御部４１は、リーダ１４に設けられた図示を省略する表示パネルにエラー通知を表示してもよい。制御部４１は、表示部２５１を介して、施設の管理者にエラーを通知してもよい。

【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】

予約開始時刻までに、事前キャンセルされなかったと判定した場合（ステップＳ８１１でＮＯ）、予約開始時刻経過後、一定時間経過するまでに、予約したユーザが入室したか否かを判定する（ステップＳ８１３）。判定は、図１１に示すプログラムの処理により行われる。
予約したユーザが入室しなかったと判定した場合（ステップＳ８１３でＮＯ）、制御部２１は、第２ユーザを特定する（ステップＳ８１４）。具体的には、場所、予約日、予約開始時刻、および予約終了時刻をキーとして第２グループＤＢ７５を検索し、該当するレコードの社員証ＩＤを特定する。また、制御部２１は、社員証ＩＤの代わりに、図示を省略する通知先フィールドに記録されたメールアドレスや電話番号等を特定してもよい。

【0136】

ステップＳ８１２またはステップＳ８１４の終了後、制御部２１は、ステップＳ８１２で特定した第１ユーザ、またはステップＳ８１４で特定した第２ユーザに通知を出力する（ステップＳ８１５）。予約したユーザが入室したと判定した場合（ステップＳ８１３でＹＥＳ）、またはステップＳ８１５の終了後、制御部２１は、処理を終了する。ステップＳ８１５における通知は、たとえばメール、ＳＭＳ等によって第１ユーザまたは第２ユーザへ送信される。したがって、第１グループＤＢおよび第２グループＤＢには、通知先フィールドを設け、メールアドレスや電話番号を記録してもよい。

【0137】

通知を受信した第１ユーザおよび第２ユーザのユーザ端末３０の表示部３５１には、部屋の利用状況を表示する画面６６２（図１２参照）が表示され、これにより第１ユーザおよび第２ユーザは空室となった部屋の予約が可能となる。メールで通知される場合は、たとえば「あなたがキャンセル待ちをしていた会議室が予約できるようになりました」等の文面が送信される。

【0138】

本実施の形態によれば、ユーザのニーズに沿って空室をより有効に活用できる情報処理システム１０を提供できる。

【0139】

［実施の形態３］
本実施の形態は、施設における一日の最後の予約終了時刻を経過時に、すべての部屋の内部に人物がいないことを確認し、施設の管理者に通知を行う情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

【0140】

図２２は、実施の形態３のプログラムの処理の流れを説明するフローチャートである。図２２の処理は、たとえば管理の担当者が指定したときに行われる。図２２の処理は、指定の時刻に行われるようにしてもよい。

【0141】

制御部２１は、一日の最後の予約終了時刻を検出する（ステップＳ９０１）。具体的には、制御部２１は、該当する予約日および状態フィールドに「有効」が記録されていることをキーとして予約情報ＤＢ５７を検索してレコードを抽出する。制御部２１は、抽出したレコードのうち、予約終了時刻フィールドの時刻が最も遅いレコードを抽出する。抽出した、最も遅い予約終了時刻を、制御部２１は、一日の最後の予約終了時刻として検出する。

【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】

１０ 情報処理システム
１１ ゲート部
１２ 出入り口
１３ 鍵機構
１４ リーダ
１４１ 第１リーダ
１４２ 第２リーダ
１５ 社員証
２０ 情報処理装置
２１ 制御部
２２ 主記憶部
２３ 補助記憶部
２４ 通信部
２５１ 表示部
２５２ 入力部
３０ ユーザ端末
３１ 制御部
３２ 主記憶部
３３ 補助記憶部
３４ 通信部
３５１ 表示部
３５２ 入力部
４０ 認証サーバ
４１ 制御部
４２ 主記憶部
４３ 補助記憶部
４４ 通信部
５１ 入退室ＤＢ
５２ 予約情報ＤＢ
５６ 入退室ＤＢ
５７ 予約情報ＤＢ
５８ 社員ＤＢ
５９ センサＤＢ
６０ センサ
６１ 制御部
６２ 主記憶部
６３ 補助記憶部
６４ 通信部
６５ 検知部
６６ 利用状況欄
６６１ 利用状況欄
６６２ 利用状況欄
６７ 予約受付画面
６８ 予約内容確認画面
６９ 退室通知画面
７０ 退室確認画面
７１ 設置例
７２ 設置例
７３ 設置例
７４ 第１グループＤＢ
７５ 第２グループＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】