JP7121375B2 - 情報処理方法、プログラムおよび情報処理装置 - Google Patents

Description

特許法第３０条第２項適用 令和 ２年１０月１６日に、ＡＢＢＯＣＣのウェブサイトにて公開（ｈｔｔｐｓ：／／ａｂｂｏｃｃ．ｗｏｒｋ／） 令和 ２年１０月２５日に、青山ブックセンター本店にてパンフレットを配布して公開 令和 ２年１１月 ９日に、ＡＢＢＯＣＣをオープンして公開（ｈｔｔｐｓ：／／ｗｗｗ．ｂｏｏｋｏｆｆｇｒｏｕｐ．ｃｏ．ｊｐ／ｒｅｎｔ／ｔｏｐｉｃｓ／２０２０．ｈｔｍｌ＃ｓｈｏｐ＿２０２０１１０９）

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

ユーザが保有する携帯端末と、レンタルスペースに設置した通信装置との間で信号を送受信して、レンタルスペースの利用時間を管理するレンタルスペースの管理方法が提案されている（特許文献１）。

複数の利用者が使用するシェアハウス、シェアオフィスおよびコワーキングスペース等において、それぞれの利用者の利用実績に応じて課金する管理装置が提案されている（特許文献２）。

特開２０２０－０２１１９２号公報 特開２０１７－２２８２７４号公報

特許文献１の管理方法および特許文献２の管理装置では、ユーザの入退室が正確に記録されない場合には、それぞれのユーザに対する適切な料金を定められない。

一つの態様では、ユーザの入退室の記録に漏れが生じた場合であっても、それぞれのユーザに対して適切な料金を請求できる情報処理方法等を提供することを目的とする。

情報処理方法は、部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得し、部屋の内側から前記スマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得し、各日付について、前記ユーザＩＤごとに、複数の入室時刻または退室時刻を取得した場合、一日の最初の前記入室時刻から同じ日の最後の前記退室時刻までの時間である利用時間を算出し、前記ユーザＩＤおよび前記利用時間に基づいて算出したそれぞれのユーザの利用料金を前記ユーザのクレジットカードを介して請求する処理をコンピュータが実行する。

一つの態様では、ユーザの入退室の記録に漏れが生じた場合であっても、それぞれのユーザに対して適切な料金を定められる情報処理方法等を提供できる。

情報処理システムの構成を説明する説明図である。 情報処理システムの構成を説明する説明図である。 入退室ＤＢのレコードレイアウトを説明する説明図である。 有効ＤＢのレコードレイアウトを説明する説明図である。 会員ＤＢのレコードレイアウトを説明する説明図である。 請求ＤＢのレコードレイアウトを説明する説明図である。 利用時間の算出ルールを説明する説明図である。 混雑状況を表示する画面例である。 管理画面の画面例である。 管理画面の画面例である。 認証サーバが実行するプログラムの処理の流れを説明するフローチャートである。 混雑状況を判定するプログラムの処理の流れを説明するフローチャートである。 料金を請求する処理を実行するプログラムの処理の流れを説明するフローチャートである。 日料金算出のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態２のプログラムの処理の流れを説明するフローチャートである。 実施の形態３の情報処理装置の機能ブロック図である。 実施の形態４の情報処理装置の構成を説明する説明図である。 実施の形態５のコワーキングスペースのマップである。 予約鍵ＤＢのレコードレイアウトを説明する説明図である。 予約ＤＢのレコードレイアウトを説明する説明図である。 実施の形態５の予約時のプログラムの処理の流れを説明するフローチャートである。 実施の形態５の解錠時のプログラムの処理の流れを説明するフローチャートである。 実施の形態５の画面である。 実施の形態５の画面である。 変形例５－１のコワーキングスペースのマップである。 実施の形態６のプログラムの処理の流れを説明するフローチャートである。 実施の形態７の会員ＤＢのレコードレイアウトを説明する説明図である。 実施の形態７のプログラムの処理の流れを説明するフローチャートである。 実施の形態８の会員ＤＢのレコードレイアウトを説明する説明図である。 実施の形態８のプログラムの処理の流れを説明するフローチャートである。 実施の形態９のプログラムの処理の流れを説明するフローチャートである。 変形例９－１の画面例である。 変形例９－１の画面例である。 実施の形態１０の商品ロッカーを説明する説明図である。 商品ＤＢのレコードレイアウトを説明する説明図である。 実施の形態１０のプログラムの処理の流れを説明するフローチャートである。 実施の形態１０の画面例である。

［実施の形態１］
図１は、情報処理システム１０の構成を説明する説明図である。本実施の形態では、いわゆるコワーキングスペースを管理する情報処理システム１０を例にして説明する。本実施の形態のコワーキングスペースは部屋の例示である。本実施の形態のコワーキングスペースは、仕事、学習または読書等のデスクワークに適した部屋であり、複数のユーザが着席して利用できる机および椅子が室内に設置されている。コワーキングスペースは、有償でユーザに提供される。

情報処理システム１０は、情報処理装置２０、携帯機器３０、認証サーバ４０、ゲート部１１および会員証１５を備える。会員証１５は、コワーキングスペースを利用するそれぞれのユーザが所持する。

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

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

第１リーダ１４１は、コワーキングスペースの外側から出入口１２を開けて入室したユーザに関する情報を取得する入室情報取得部の例示である。第２リーダ１４２は、コワーキングスペースの内側から出入口１２を開けて退室したユーザに関する情報を取得する退室情報取得部の例示である。

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

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

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

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

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

所定時間の経過後、または、図示を省略するセンサによりユーザの通過を検知した後に、制御部４１は、鍵機構１３を制御して自動的に出入口１２をロックする。鍵機構１３は、所定時間の経過後、または、ユーザの通過を検知した後に自律的に出入口１２をロックしてもよい。

図２は、情報処理システム１０の構成を説明する説明図である。図２を使用して、情報処理装置２０および携帯機器３０の構成を説明する。

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

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

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

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

情報処理装置２０は、コワーキングスペースの運営事業者が使用する汎用のパソコン、スマートフォン、タブレット、大型計算機、または、大型計算機上で動作する仮想マシンである。情報処理装置２０は、分散処理を行なう複数のパソコン、または大型計算機等のハードウェアにより構成されても良い。情報処理装置２０は、クラウドコンピューティングシステムにより構成されても良い。情報処理装置２０は、本実施の形態の編集支援処理専用のハードウェアであってもよい。

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

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

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

携帯機器３０は、コワーキングスペースを利用するそれぞれのユーザが利用する汎用のスマートフォン、タブレット、パソコン等である。ユーザが自宅または職場等から情報処理システム１０にアクセスする場合には、携帯機器３０はデスクトップ型のパソコンであってもよい。

図３は、入退室ＤＢ５１のレコードレイアウトを説明する説明図である。入退室ＤＢ５１は、コワーキングスペースの場所と、リーダ１４が会員証１５を読み取った日時と、会員証１５に対応するユーザＩＤと、入退室の区別とを関連づけて記録したＤＢである。

入退室ＤＢ５１は、場所フィールド、日時フィールド、ユーザＩＤフィールドおよび出入りフィールドを有する。日時フィールドは、日付フィールドおよび時刻サブフィールドを有する。場所フィールドには、コワーキングスペースの名称が記録されている。日付フィールドには、リーダ１４が会員証１５を読み取った日付が記録されている。時刻フィールドには、リーダ１４が会員証１５を読み取った時刻が記録されている。

ユーザＩＤフィールドには、読み取った会員証１５に対応するユーザＩＤが記録されている。出入フィールドには、ユーザの出入りの別が記録されている。出入りの区別は、第１リーダ１４１と第２リーダ１４２のどちらが会員証１５を読み取ったかにより判定される。

具体的には、「入」はユーザがコワーキングスペースの外部から第１リーダ１４１に会員証１５を読み取らせて、コワーキングスペースに入ったことを、「出」は、ユーザがコワーキングスペースの内部から第２リーダ１４２に会員証１５を読み取らせて、コワーキングスペースから出たことを示す。入退室ＤＢ５１は、一回の会員証１５の読み取りに対して、一つのレコードを有する。

ドアを開いたユーザに加えて、他のユーザも一緒に出入りする、いわゆる共連れが行なわれる場合がある。後続の人が通りやすいようにドアを開いた状態でおさえておくというマナーが存在するため、一般的なドアを使用する場合には、共連れを防止することは難しい。共連れにより入退室したユーザに関する情報は、入退室ＤＢ５１に記録されない。

すなわち、本実施の形態の情報処理システム１０においては、ユーザの入退室が正確に記録されない場合がある。具体的には、同一のユーザＩＤに対して、入室が連続して複数回記録される場合、退室が連続して複数回記録される場合、一日の最初に退室が記録される場合、および、一日の最後に入室が記録される場合がある。

入退室ＤＢ５１に記録された各レコードは、レプリケーション処理により入退室ＤＢ５６に随時複写される。したがって、入退室ＤＢ５６は入退室ＤＢ５１と同一のレコードレイアウトを有する。レプリケーション処理は従来から使用されているため、詳細については説明を省略する。

コワーキングスペースの運営事業者は、たとえば地域ごとに情報処理装置２０を設置して、コワーキングスペースを運営してもよい。複数の運営事業者が、それぞれ情報処理装置２０を設置してもよい。そのようにする場合には、レプリケーション処理時においては管理対象のコワーキングスペースに関するレコードが抽出されて、入退室ＤＢ５６に複写される。

図４は、有効ＤＢ５２のレコードレイアウトを説明する説明図である。有効ＤＢ５２は、会員証１５に固有に付与された会員証ＩＤと、ユーザに固有に付与されたユーザＩＤと、会員証１５の有効または無効の別とを関連づけて記録したＤＢである。

有効ＤＢ５２は、会員証ＩＤフィールド、ユーザＩＤフィールドおよび状態フィールドを有する。会員証ＩＤフィールドには、会員証１５に固有に付与された会員証ＩＤが記録されている。会員証ＩＤは、会員証１５に搭載されたＩＤチップに書き込まれている。

ユーザＩＤフィールドには、コワーキングスペースを利用するユーザに固有に付与されたユーザＩＤが記録されている。状態フィールドには、会員証１５が有効であるか、無効であるかが記録されている。会員証１５が無効である場合とは、たとえばユーザが退会手続きを行なった場合、または、ユーザが所定の会費を支払わなかった場合等である。

有効ＤＢ５２は、一枚の会員証１５に対して一つのレコードを有する。制御部４１は、情報処理装置２０から送信される会員証１５の登録情報に基づいて、有効ＤＢ５２を適宜更新する。

図５は、会員ＤＢ５７のレコードレイアウトを説明する説明図である。会員ＤＢ５７は、ユーザＩＤと、会員証ＩＤと、氏名と、会員種別と、請求先と、登録日と、オプションとを関連づけて記録したＤＢである。会員ＤＢ５７は、ユーザＩＤフィールド、会員証ＩＤフィールド、氏名フィールド、会員種別フィールド、請求先フィールド、登録日フィールド、および、オプションフィールドを有する。

ユーザＩＤフィールドには、ユーザに固有に付与されたユーザＩＤが記録されている。会員証ＩＤフィールドには、ユーザが所持する会員証１５に記録された会員証ＩＤが記録されている。

氏名フィールドには、ユーザの氏名が登録されている。会員種別フィールドには、会員種別が登録されている。「従量」は、コワーキングスペースを利用した時間に応じて利用料金を支払う従量制会員を示す。「固定」は、コワーキングスペースを利用した時間に関わらず、一定額の利用料金をたとえば毎月支払う固定料金制会員を示す。

なお、会員種別は「従量」と「固定」の２通りに限定しない。たとえば、利用時間を昼間に限定した会員、平日の昼間と夜とで料金が異なる会員、利用回数に上限を設けた会員、学生料金の会員、団体割引料金の会員等、種々の会員種別を適宜設定できる。

請求先フィールドには、たとえばクレジットカード番号、クレジットカードの名義人、およびクレジットカードの有効期限等、ユーザが保有するクレジットカードを介して料金を請求する際に必要な情報が記録されている。請求先フィールドには、決済代行サービスを介して会員から料金を徴収する際に必要な、識別ＩＤが記録されてもよい。決済代行サービスを利用することにより、クレジットカード番号等の重要な情報を情報処理システム１０で管理することを避けられる。

登録日フィールドには、会員登録を行なった日付が記録されている。オプションフィールドには、オプション契約が記録されている。たとえば「ロッカー」は、個人用ロッカーに関するオプション契約が締結されていることを示す。すなわち、会員ＤＢ５７には、ユーザＩＤと当該ユーザの契約条件とが関連づけて記録されている。オプション契約は、たとえば郵便受取サービスの契約、住所利用サービスの契約等であってもよい。

なお料金の請求方法はクレジットカードに限定しない。たとえば請求先フィールドには、銀行口座の番号および口座名義人等、銀行口座を介した料金の請求に必要な情報が記録されていてもよい。請求先フィールドには、電子マネーの認証情報等、電子マネーを介した料金の請求に必要な情報が記録されていてもよい。

図示を省略するが、会員ＤＢ５７はユーザの住所、電話番号、メールアドレス、電話番号、ＳＮＳ（Social Network Service）のアカウント、職業または生年月日等の情報を記録したフィールドを有してもよい。会員ＤＢ５７は、一つのユーザＩＤについて、一つのレコードを有する。

図６は、請求ＤＢ５８のレコードレイアウトを説明する説明図である。請求ＤＢ５８は、請求月とユーザＩＤと、請求額と決済状況とを関連づけて記録したＤＢである。請求ＤＢ５８は、請求月フィールド、ユーザＩＤフィールド、請求額フィールドおよび決済フィールドを有する。

請求月フィールドには、請求月が記録されている。ユーザＩＤフィールドには、ユーザＩＤが記録されている。請求額フィールドには、それぞれのユーザの会員種別および利用実績に基づいて算出された請求額が記録されている。決済フィールドには、決済状況が記録されている。「済」は、決済が完了して入金が行なわれたことを示す。「未」は決済が未完了であることを示す。たとえば、事前に登録されたクレジットカードが無効になっていて請求が行なえない等の問題が発生した場合には、「エラー」が記録される。

会員登録の概要を説明する。制御部２１は、たとえばＷＥＢ（World Wide Web）サイトを介してユーザに入会申し込みフォームを提示して、ユーザが記入した情報を受け付ける。制御部２１は、チャットシステムを用いて、入会に必要な情報を取得してもよい。

制御部２１は、会員ＤＢ５７に新規レコードを作成して、ユーザが記入した情報をそれぞれのフィールドに記録する。制御部２１は、ユーザに固有のユーザＩＤを割り当てて、ユーザに通知する。

コワーキングスペースを初めて利用するユーザは、受付に立ち寄って登録時に通知されたユーザＩＤを提示する。受付の担当者は、受付窓口に設置されたパソコン等を操作して、未使用の会員証１５に記録された会員証ＩＤを、ユーザＩＤと関連づけて会員ＤＢ５７に記録させる。担当者は、ユーザに会員証１５を渡す。以上により、会員登録が完了する。

制御部２１は、会員ＤＢ５７に新規ユーザに関するレコードを記録する際に、未使用の会員証１５に記録された会員証ＩＤを記録してもよい。そのようにする場合、受付の担当者は会員ＤＢ５７を参照して会員証ＩＤを確認し、対応する会員証１５をユーザに手渡す。

受付の近傍に、会員登録受付用のパソコンまたはタブレットが設置されていてもよい。会員登録の申し込みを紙の申込書で受け付けてもよい。そのようにする場合、受付の担当者が会員ＤＢ５７に情報を入力するか、ＯＣＲにより自動的に読み取って会員ＤＢ５７に記録する。

会員証１５を保有しているユーザは、受付に立ち寄ることなくコワーキングスペースを利用できる。具体的にはユーザは、第１リーダ１４１に会員証１５を読み取らせることにより、鍵機構１３を解除してコワーキングスペースに入室できる。同様にユーザは、第２リーダ１４２に会員証１５を読み取らせることにより、鍵機構１３を解除してコワーキングスペースから退室できる。

したがって、コワーキングスペースには受付手続および入退室の管理等の作業を行なう担当者が常駐する必要はない。たとえば隣接する店舗の従業員がコワーキングスペースの担当者を兼ねてもよい。

ユーザは、会員証１５を用いて簡単に入退室できるため、たとえばトイレおよび自動販売機等をコワーキングスペース内に設置する必要がない。運営事業者は、大規模商業施設、または、オフィスビル等の一部を区切って、有償のコワーキングスペースを容易に設置できる。したがって運営事業者は、比較的安価な初期投資で、遊休スペースを有償のコワーキングスペースに利用して、収益化を図れる。

コワーキングスペースを囲む壁は、ユーザが簡単に乗り越えたり、すり抜けたりできない程度のものであれば良い。たとえば１メートル強程度の高さの連結型パーティション等を壁に使用してもよい。コワーキングスペースの外から内部の状況がわかるため、初めてのユーザであっても安心して利用できるコワーキングスペースを提供できる。

天井高よりも低い壁を用いて天井と壁との間に空間を設けることにより、コワーキングスペース内に専用の空調設備、照明設備および火災報知器等を設置する必要がないため、コワーキングスペースの初期投資を低減できる。

遊園地等の大規模な施設で使用される、一度に通行できる人を一人に制限して共連れを防止するゲートを設置せず、一般的なドアを使用できるため、コワーキングスペースの初期投資を低減できる。

図７は、利用時間の算出ルールを説明する説明図である。図７は、ＩＤ０１０からＩＤ０５０までの５人のユーザそれぞれのコワーキングスペースの利用状況を示す。縦軸は、それぞれのユーザを示し、横軸はコワーキングスペースの開店から閉店までの時間を示す。

三角形は入室時刻、すなわちユーザの持つ会員証１５が第１リーダ１４１に読み取られた時刻を示す。逆三角形は退室時刻、すなわちユーザの持つ会員証１５が第２リーダ１４２に読み取られた時刻を示す。太線は、当該ユーザの利用時間であると判定される時間を示す。

具体例を挙げて説明する。「ＩＤ０１０」のユーザは、時刻ｔ１１に入室し、時刻ｔ１２に退出した。利用時間は、ｔ１１からｔ１２までである。「ＩＤ０２０」のユーザは、時刻ｔ２１に入室し、時刻ｔ２２に退出し、時刻ｔ２３に入室し、時刻ｔ２４に退出した。利用時間はｔ２１からｔ２４までである。

「ＩＤ０３０」のユーザは、時刻ｔ３１に入室し、時刻ｔ３２に入室し、時刻ｔ３３に退出した。このユーザは、時刻ｔ３１から時刻ｔ３２までの間に、共連れにより退室したものと推定される。利用時間はｔ３１からｔ３３までである。

「ＩＤ０４０」のユーザは、時刻ｔ４１に入室し、退室時刻は記録されていない。このユーザは、共連れにより退室したものと推定される。利用時間は、ｔ４１から閉店時刻までである。

「ＩＤ０５０」のユーザは、時刻ｔ５１に退室した。入室時刻は記録されていない。このユーザは、共連れにより入室したものと推定される。利用時間は、開店時刻からｔ５１までである。

最初の入室時に会員証１５を第１リーダ１４１に読み取らせずに共連れした場合、および、最後の退室時に会員証１５を第２リーダ１４２に読み取らせずに共連れした場合、ユーザの利用時間は長く判定される。この算定方式をユーザに周知することにより、ユーザは少なくとも最初の入室時および最後の退室時には会員証１５の読み取り操作を行なうように促される。

一方、トイレ休憩等、利用中に入退室する際には共連れしても差支えない。したがって、ユーザが気軽な雰囲気で利用できるコワーキングスペースを提供できる。

図８は、混雑状況を表示する画面例である。図８は、たとえばコワーキングスペースを紹介するＷＥＢサイト内のＷＥＢページである。画面中央の混雑状況欄６１に、混雑状況が表示されている。

ユーザは、携帯機器３０を操作して当該ページを閲覧し、混雑状況を確認できる。複数のコワーキングスペースそれぞれの混雑情報が、画面に一覧表示されてもよい。ユーザは、移動に要する時間等の利便性と、混雑状況とを検討して、利用するコワーキングスペースを選択できる。

図９および図１０は、管理画面の画面例である。図９および図１０は、コワーキングスペース運営事業者の担当者が操作および閲覧する画面である。画面の左側に、メニュー欄６２が表示されている。

図９はメニュー欄６２において「トップ」が表示された状態の画面例を示す。メニュー欄６２の右側に表示されたトップ欄６３に、固定料金制の会員数、従量制の会員数、現在の利用者数、前月の請求金額、前月の入金金額、および前月の返金金額が、それぞれアイコンで表示されている。なお、返金は、たとえばユーザが月の途中で退会した場合、または、前の月に誤請求があった場合等、イレギュラーな状況があった場合に発生する。

トップ画面により、ユーザはコワーキングスペースの運営状況の概要を把握できる。なお、トップ画面には、たとえば前月の運営経費、および、前月に１回でも利用実績のあるアクティブ会員の数等を表示してもよい。

図１０は、メニュー欄６２において「会員一覧」が表示された状態の画面例を示す。メニュー欄６２の右側に表示された会員一覧欄６４に会員のユーザＩＤ，氏名および会員種別が表形式で一覧表示されている。

担当者は、画面上部に配置された検索欄６４１を使用して、一覧表示させるユーザを絞り込める。担当者が、「ＣＳＶ（Comma Separated Value）ダウンロード」ボタンを選択した場合、制御部２１は会員一覧のリストをＣＳＶ形式で生成する。

図示を省略するが、担当者が「詳細」ボタンを選択した場合、制御部２１は会員ＤＢ５７に記録された当該会員に関する詳細情報を表示する。同様に担当者が「履歴」ボタンを選択した場合、制御部２１は入退室ＤＢ５６に記録された当該会員の入退室履歴を表示する。

図示を省略するが、担当者がメニュー欄６２の「利用履歴」を選択した場合、制御部２１は、各ユーザの利用日および利用時間を一覧表示する。担当者がメニュー欄６２の「日別利用履歴」を選択した場合、制御部２１は、ユーザにより指定された日付におけるユーザの利用時間を一覧表示する。

担当者がメニュー欄６２の「請求情報」を選択した場合、制御部２１は、各ユーザへの請求額を一覧表示する。担当者がメニュー欄６２の「入金情報」を選択した場合、制御部２１は、各ユーザからの入金額を一覧表示する。担当者がメニュー欄６２の「返金情報」を選択した場合、制御部２１は、各ユーザへの返金額を一覧表示する。

なお、制御部２１が表示する画面は、上記に例示した画面に限定しない。ユーザは、入力部２５２を適宜操作して、閲覧したい情報を指定できる。制御部２１は、ユーザによる操作に応じて、表示部２５１に情報を表示する。

図１１は、認証サーバ４０が実行するプログラムの処理の流れを説明するフローチャートである。図１１のプログラムは、コワーキングシステムの営業時間中に実行される。

制御部４１は、リーダ１４を介して会員証１５に記録された会員証ＩＤを読み取る（ステップＳ５０１）。制御部４１は、会員証ＩＤをキーとして有効ＤＢ５２を検索して、レコードを抽出する。制御部４１は、抽出したレコードの状態フィールドを参照して、会員証１５が有効であるか否かを判定する（ステップＳ５０２）。なお制御部４１は会員証ＩＤをキーとして有効ＤＢ５２からレコードを抽出できない場合には、会員証１５が有効ではないと判定する。

有効ではないと判定した場合（ステップＳ５０２でＮＯ）、制御部４１はエラー通知を出力する（ステップＳ５０３）。具体的には制御部４１は、たとえば図示を省略するスピーカからビープ音または「エラーです」等の音声を出力する。

制御部４１は、リーダ１４に設けられた図示を省略するＬＥＤ（Light Emitting Diode）を点滅させてエラー通知を出力しても良い。制御部４１は、リーダ１４に設けられた図示を省略する表示パネルにエラー通知を表示してもよい。制御部４１は、コワーキングスペースの担当者にエラーを通知してもよい。

有効であると判定した場合（ステップＳ５０２でＹＥＳ）、制御部４１は鍵機構１３を制御してゲート部１１のロックを解除する（ステップＳ５０４）。ロックの解除により、ユーザが出入口１２を通過可能な状態になる。制御部４１は、ユーザの入退室を記録する（ステップＳ５０５）。具体的には制御部４１は、入退室ＤＢ５１に新規レコードを作成する。制御部４１は、日時フィールドにリーダ１４が会員証１５を読み取った日時を記録する。

制御部４１は、ユーザＩＤフィールドにステップＳ５０２で抽出したユーザＩＤを記録する。第１リーダ１４１から会員証１５を読み取った場合、制御部４１は出入フィールドに「入」を記録する。第２リーダ１４２から会員証１５を読み取った場合、制御部４１は出入フィールドに「出」を記録する。したがって出入フィールドには、「入」と「出」のいずれか一方が記録される。

ステップＳ５０３またはステップＳ５０５の終了後、制御部４１は処理を終了するか否かを判定する（ステップＳ５０６）。たとえばコワーキングスペースの閉店時刻を過ぎた場合に、制御部４１は処理を終了すると判定する。

処理を終了しないと判定した場合（ステップＳ５０６でＮＯ）、制御部４１はステップＳ５０１に戻る。処理を終了すると判定した場合（ステップＳ５０６でＹＥＳ）、制御部４１は処理を終了する。

なおステップＳ５０３において、制御部４１は、有効ではない会員証１５を使おうとしたユーザの存在を記録して、担当者が後日参照できるようにしてもよい。担当者は、たとえば再契約の方法を案内するダイレクトメールをユーザに送付する等の対処を行なえる。

図１２は、混雑状況を判定するプログラムの処理の流れを説明するフローチャートである。図１２のプログラムは、コワーキングスペースの営業開始前に起動して、営業時間中に実行される。

制御部２１は、変数「人数」を初期値であるゼロに設定する（ステップＳ６０１）。制御部２１は、入退室ＤＢ５１とのレプリケーション処理により、入退室ＤＢ５６に追加された新規レコードを１個取得する（ステップＳ６０２）。制御部２１は、取得したレコードの出入フィールドに「入」が記録されているか否かを判定する（ステップＳ６０３）。

「入」が記録されていると判定した場合（ステップＳ６０３でＹＥＳ）、制御部２１は変数「人数」に１を加算する（ステップＳ６０４）。「入」が記録されていないと判定した場合（ステップＳ６０３でＮＯ）、制御部２１は変数「人数」から１を減算する（ステップＳ６０５）。なお、「人数」がゼロである場合には、制御部２１は減算を行なわず「人数」をゼロのままに保つ。

制御部２１は、変数「人数」と所定の第１閾値および第２閾値とをそれぞれ比較して判定を行なう（ステップＳ６０６）。第１閾値は、たとえばコワーキングスペースの定員の７５パーセント程度の値である。第２閾値は、たとえばコワーキングスペースの定員の９０パーセント程度の値である。

変数「人数」が第１閾値未満である場合（ステップＳ６０６で第１閾値未満）、制御部２１はコワーキングスペースの混雑状況は「余裕あり」であると判定する（ステップＳ６０７）。変数「人数」が第１閾値以上第２閾値未満である場合（ステップＳ６０６で第１閾値以上第２閾値未満）、制御部２１はコワーキングスペースの混雑状況は「やや混雑」であると判定する（ステップＳ６０８）。変数「人数」が第２閾値以上である場合（ステップＳ６０６で第２閾値以上）、制御部２１はコワーキングスペースの混雑状況は「満席」であると判定する（ステップＳ６０９）。

ステップＳ６０７、ステップＳ６０８またはステップＳ６０９の終了後、制御部２１は図示を省略するＷＥＢサーバに対して混雑状況を送信する（ステップＳ６１０）。ＷＥＢサーバは受信した混雑状況をＷＥＢページに反映させる。たとえば図８は、ステップＳ６０６で変数「人数」は第１閾値未満であると制御部２１が判定した場合のＷＥＢページの例である。

制御部２１は、処理を終了するか否かを判定する（ステップＳ６１１）。たとえばコワーキングスペースの閉店時刻を過ぎた場合に、制御部２１は処理を終了すると判定する。処理を終了しないと判定した場合（ステップＳ６１１でＮＯ）、制御部２１はステップＳ６０２に戻る。処理を終了すると判定した場合（ステップＳ６１１でＹＥＳ）、制御部２１は処理を終了する。

図１３は、料金を請求する処理を実行するプログラムの処理の流れを説明するフローチャートである。図１３のプログラムは、たとえば月次の請求処理時に実行される。図１３のプログラムは、運営事業者の担当者が指定したときに実行されてもよい。

制御部２１は、料金を請求する会員のユーザＩＤを選択する（ステップＳ６２１）。制御部２１は、管理担当者によるユーザＩＤの入力を受け付けてもよい。制御部２１は、ユーザＩＤをキーとして会員ＤＢ５７を検索してレコードを抽出する。制御部２１は、抽出したレコードの会員種別フィールドに基づいて当該会員が従量制の会員であるか否かを判定する（ステップＳ６２２）。

従量制の会員ではない、すなわち固定料金制の会員であると判定した場合（ステップＳ６２２でＮＯ）、制御部２１は請求ＤＢ５８に新規レコードを作成する。制御部２１は、請求月フィールドに計算中の請求月を、ユーザＩＤフィールドにステップＳ６２１で選択したユーザＩＤを、請求額フィールドに所定の固定料金を、決済フィールドに「未」をそれぞれ記録する（ステップＳ６２３）。なお、請求額フィールドに記録する固定料金には、ユーザが契約した有償オプションの料金も含む。

従量制の会員であると判定した場合（ステップＳ６２２でＹＥＳ）、制御部２１は日料金算出のサブルーチンを起動する（ステップＳ６２４）。日料金算出のサブルーチンは、入退室ＤＢ５６に記録されたデータに基づいて一日分の利用料金を算出するサブルーチンである。日料金算出のサブルーチンの処理の流れは後述する。

制御部２１は、請求対象期間の処理を終了したか否かを判定する（ステップＳ６２５）。終了していないと判定した場合（ステップＳ６２５でＮＯ）、制御部２１はステップＳ６２４に戻る。終了したと判定した場合（ステップＳ６２５でＹＥＳ）、制御部２１は日料金算出のサブルーチンで算出した各日の利用料金と、ユーザが契約している有償オプションの料金とを合算してユーザに請求する料金を算出する（ステップＳ６２６）。

制御部２１は、制御部２１は請求ＤＢ５８に新規レコードを作成する。制御部２１は、請求月フィールドに計算中の請求月を、ユーザＩＤフィールドにステップＳ６２１で選択したユーザＩＤを、請求額フィールドにステップＳ６２６で算出した利用料金を、決済フィールドに「未」をそれぞれ記録する（ステップＳ６２７）。

ステップＳ６２３またはステップＳ６２７の終了後、制御部２１は請求処理を行なう（ステップＳ６２８）。具体的には、制御部２１はステップＳ６２１で取得したユーザＩＤをキーとして会員ＤＢ５７を検索してレコードを抽出する。制御部２１は、抽出したレコードの請求先フィールドに記録された情報に基づいて、クレジットカード会社に料金の請求に関するデータを送信する。

なお、請求した料金の入金が行なわれた場合、制御部２１は請求ＤＢ５８から対応するレコードを抽出し、決済フィールドに「済」を記録する。以上により、制御部２１は本実施の形態の決済処理部の機能を実現する。

制御部２１は、固定料金制のユーザの固定料金と、有償オプションの料金とを合算せずに個々に請求処理してもよい。制御部２１は、従量料金制のユーザの利用料金と、有償オプションの料金とを合算せずに個々に請求処理してもよい。

制御部２１は、処理を終了するか否かを判定する（ステップＳ６２９）。たとえば、すべての会員の処理を終了した場合、または管理担当者が指定した会員の処理を終了した場合に、制御部２１は処理を終了すると判定する。

終了しないと判定した場合（ステップＳ６２９でＮＯ）、制御部２１はステップＳ６２１に戻る。終了すると判定した場合（ステップＳ６２９でＹＥＳ）、制御部２１は処理を終了する。

図１４は、日料金算出のサブルーチンの処理の流れを説明するフローチャートである。日料金算出のサブルーチンは、入退室ＤＢ５６に記録されたデータに基づいて一日分の料金を算出するサブルーチンである。

制御部２１は、ユーザＩＤおよび日付をキーとして、入退室ＤＢ５６から一人のユーザの一日分のレコードを抽出する（ステップＳ６４１）。制御部２１は、抽出したレコードのうち最も時刻が早いレコードが入室を意味するか否か、すなわち出入フィールドに「入」が記録されているか否かを判定する（ステップＳ６４２）。

入室を意味すると判定した場合（ステップＳ６４２でＹＥＳ）、制御部２１は当日の入室時刻は最も時刻が早いレコードの時刻フィールドに記録された時刻であると判定する（ステップＳ６４３）。入室を意味しないと判定した場合（ステップＳ６４２でＮＯ）、制御部２１は当日の入室時刻はコワーキングスペースの開店時刻であると判定する（ステップＳ６４４）。

ステップＳ６４３またはステップＳ６４４の終了後、制御部２１は、抽出したレコードのうち最も時刻が遅いレコードが退室を意味するか否か、すなわち出入フィールドに「出」が記録されているか否かを判定する（ステップＳ６４５）。

退室を意味すると判定した場合（ステップＳ６４５でＹＥＳ）、制御部２１は当日の退室時刻は最も時刻が遅いレコードの時刻フィールドに記録された時刻であると判定する（ステップＳ６４６）。退室を意味しないと判定した場合（ステップＳ６４５でＮＯ）、制御部２１は当日の退室時刻はコワーキングスペースの閉店時刻であると判定する（ステップＳ６４７）。

ステップＳ６４６またはステップＳ６４７の終了後、制御部２１はユーザの滞在時間、すなわち入室時刻から退出時刻までの時間を算出する（ステップＳ６４８）。ステップＳ６４８により、制御部２１はユーザの利用時間を算出する利用時間算出部の機能を実現する。

制御部２１は、滞在時間に基づいて一日分の料金を算出する（ステップＳ６４９）。料金は、たとえば一時間あたりの料金と滞在時間とを積算して算出する。一日の上限料金が定められていてもよい。

制御部２１は、ユーザＩＤと、日付と、一日分の料金とを関連づけて、補助記憶装置２３または主記憶装置２２に一時的に記録する（ステップＳ６５０）。制御部２１は、日付ごとの料金を所定のデータベースに記録してもよい。その後、制御部２１は処理を終了する。

なお、出入口１２は自動扉であってもよい。そのようにする場合は、鍵機構１３はロックおよびロック解除を行なう代わりに、自動扉の開閉制御を行なう。一つのコワーキングスペースに複数の出入口１２が設置されていてもよい。それぞれの出入口１２に、第１リーダ１４１と第２リーダ１４２とが配置されていてもよい。第１リーダ１４１が配置された入室専用の出入口１２と、第２リーダ１４２が配置された退室専用の出入口１２とが設けられていてもよい。

会員証１５に、ユーザＩＤが記録されていてもよい。第１リーダ１４１および第２リーダ１４２は、会員証１５に記録されたユーザＩＤを読み取るとともに、ユーザＩＤと有効性とを関連づけて記録した有効ＤＢ５２を検索して、読み取ったユーザＩＤが有効であるか否かを判定する。

ユーザが保有する携帯機器３０が会員証１５を兼ねてもよい。たとえば、ユーザが保有する携帯機器３０に内蔵された近距離無線通信用チップに登録されたシリアル番号を会員証ＩＤに使用できる。ユーザは、携帯機器３０をリーダ１４に読み取らせることで、コワーキングスペースに入場できる。

ユーザが保有する携帯機器３０に、近距離無線通信用チップからユーザＩＤを送信する認証用のアプリケーションソフトウエアがインストールされてもよい。ユーザが保有する携帯機器３０に、ユーザＩＤを示すバーコードを表示する認証用のアプリケーションソフトウエアがインストールされてもよい。

図１２を使用して説明したプログラムは、管理担当者がユーザの人数の修正を指示する機能を有してもよい。たとえば、管理担当者が清掃等のために入室した際に在室中のユーザの人数を数え、変数「人数」を修正する。共連れにより生じた誤差を修正して、適切な混雑状況を表示するプログラムを実現できる。

図１２を使用して説明したプログラムを使用する代わりに、コワーキングスペース内に設置したカメラにより撮影した画像に基づいて、混雑状況を判定してもよい。画像から撮影されている人の数を判定する技術は公知であるため、説明を省略する。コワーキングスペース内にカメラを設置することにより、ユーザによる不適切な行為を抑制する効果も期待できる。

本実施の形態によると、共連れが生じた場合であっても、それぞれのユーザに対して適切な料金を請求する情報処理システム１０を提供できる。本実施の形態によると、比較的安価な初期投資で、遊休スペースを有償のコワーキングスペースに利用して、収益化を図る情報処理システム１０を提供できる。

ユーザは、最初の入室時、および、最後の退室時以外は共連れを気にする必要がない。したがって、出入りの際にドアを押さえておく等のマナーを守っても差支えが生じない、和やかな雰囲気のコワーキングスペースを提供できる。

なお、前述のとおりコワーキングスペースは部屋の例示である。ゲート部１１が設置される部屋は、たとえばランニングマシン等の運動器具が設置された運動ジム、幼児向けの遊具等が配置されたキッズスペース、ゲーム機が設置されたゲームコーナー、または、コミックおよび書籍等が配置された読書スペース等であってもよい。

［変形例１－１］
図１３を使用して説明したステップＳ６２８において、制御部２１はクレジットカード会社に料金の請求に関するデータを送信する代わりに、所定の宛先に請求書を発行する。制御部２１は、複数のユーザＩＤに関する請求を１通にまとめた請求書を発行してもよい。請求書を使用することにより、企業等がたとえば福利厚生施策またはテレワーク対策の一環として、従業員の利用料を経費処理できる。

制御部２１は、請求書の代わりに見積書を発行してもよい。見積書に基づいた社内決裁の後に支払いを行なう企業等であっても、社内ルールに沿った形で従業員の利用料を経費処理できる。

制御部２１は、請求に対する支払いが行なわれた後に、自動的に領収書を発行してもよい。銀行口座またはクラウドサービス等を介した請求および支払いの自動確認は従来から行なわれているため、詳細については説明を省略する。

［変形例１－２］
従量課金制のユーザの料金は、入室した時間帯毎に変動してもよい。たとえば制御部２１は、図１４を使用して説明した日料金算出のサブルーチンにおいて、ステップＳ６４３で判定した入室時刻に基づいて、１時間あたりの料金を設定する。たとえば制御部２１は、ステップＳ６４３で判定した入室時刻が午前中であるユーザの料金をステップＳ６４６で判定した退室時刻に関わらず１時間あたり２００円に、ステップＳ６４３で判定した入室時刻が１８時から２０時であるユーザの料金はステップＳ６４６で判定した退室時刻に関わらず１時間あたり３００円に設定する。

制御部２１は、日付ごと、曜日ごと、または月ごとに異なる利用料金を使用しても良い。これらの利用料金は、たとえばコワーキングスペースの混雑状況または混雑予測等に基づいて設定される。制御部２１は、たとえばゲート部１１近傍に配置したデジタルサイネージ用ディスプレイおよびコワーキングスペースを紹介するＷＥＢサイト等に、当日の利用料金を表示する。

従量課金制のユーザは、入室時に確認した利用料金が終日適用されるため、安心してコワーキングスペースを利用できる。利用者が比較的少ない時間帯に入室したユーザの料金を安く、比較的多い時間帯に入室したユーザの料金を高く定めることにより、コワーキングスペースの利用状況を平準化できる。

制御部２１は、ユーザが滞在した時間帯のそれぞれについて、異なる料金を使用してもよい。具体例を挙げて説明する。午前中の利用料金は１時間あたり２００円、午後の利用料金は１時間あたり２５０円、１８時以降の夜間の利用料金は１時間あたり３００円と設定した場合を例にする。

ステップＳ６４３で判定した入室時刻が１０時であり、ステップＳ６４６で判定した退室時刻が１５時である場合、当該ユーザは２００円の時間帯に２時間、２５０円の時間帯に３時間滞在している。したがってステップＳ６４９において制御部２１は、２００×２＋２５０×３＝１１５０円の料金を算出する。

［実施の形態２］
本実施の形態は、従量制会員であるユーザの料金が閾値を超える場合に、通知を行なう情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図１５は、実施の形態２のプログラムの処理の流れを説明するフローチャートである。図１５のプログラムは、ユーザが退室する都度、または、ユーザがコワーキングスペースを利用した日の夜間等に実行される。

制御部２１は、料金を計算するする会員のユーザＩＤを選択する（ステップＳ６６１）。制御部２１は、ユーザＩＤをキーとして会員ＤＢ５７を検索してレコードを抽出する。制御部２１は、抽出したレコードの会員種別フィールドに基づいて当該会員が従量制の会員であるか否かを判定する（ステップＳ６６２）。

従量制の会員であると判定した場合（ステップＳ６６２でＹＥＳ）、制御部２１は日料金算出のサブルーチンを起動する（ステップＳ６６３）。日料金算出のサブルーチンは、図１４を使用して説明したサブルーチンと同一である。

制御部２１は、請求対象期間の処理を終了したか否かを判定する（ステップＳ６６４）。終了していないと判定した場合（ステップＳ６６４でＮＯ）、制御部２１はステップＳ６６３に戻る。終了したと判定した場合（ステップＳ６６４でＹＥＳ）、制御部２１は日料金算出のサブルーチンで算出した各日の料金を合算して、累計料金を算出する（ステップＳ６６５）。

制御部２１は、累計料金が所定の閾値以上であるか否かを判定する（ステップＳ６６６）。閾値は、たとえば固定料金制の料金である。閾値は、あらかじめユーザが設定した料金であってもよい。閾値以上であると判定した場合（ステップＳ６６６でＹＥＳ）、制御部２１は電子メールまたはＳＭＳ（Short Message Service）等を介して携帯機器３０に対して通知を送信する（ステップＳ６６７）。

制御部３１は通知を受信する（ステップＳ７０１）。制御部３１は受信した通知を表示部３５１に出力する（ステップＳ７０２）。通知は、たとえば「今月の従量制料金が２００００円を超えました。月末までに固定料金制会員に変更すると、１８０００円で利用できます」等の内容である。会員種別変更手続き用のＵＲＬ（Uniform Resource Locator）が通知に含まれてもよい。

通知は、それぞれのユーザがパスワード認証等を経てアクセス可能なＷＥＢサイトに掲載されてもよい。通知は、携帯機器３０にインストールされたアプリケーションプログラムの画面に表示されてもよい。

従量制の会員ではない、すなわち固定料金制の会員であると判定した場合（ステップＳ６６２でＮＯ）、閾値以上ではないと判定した場合（ステップＳ６６６でＮＯ）、またはステップＳ６６７の終了後、制御部２１は、処理を終了するか否かを判定する（ステップＳ６６８）。終了しないと判定した場合（ステップＳ６６８でＮＯ）、制御部２１はステップＳ６６１に戻る。終了すると判定した場合（ステップＳ６６８でＹＥＳ）、制御部２１は処理を終了する。

なお、制御部２１はステップＳ６６７で通知を送信する代わりに、自動的に固定料金制への切り替えを行なってもよい。そのようにする場合、制御部２１は、翌月は自動的に従量制に設定を戻してもよい。

本実施の形態によると、従量制会員であるユーザの料金が固定料金を超える場合に、通知を行なう情報処理システム１０を提供できる。ユーザが、予想外の料金を請求されることを防ぐことにより、顧客満足度を向上させる情報処理システム１０を提供できる。

［実施の形態３］
図１６は、実施の形態３の情報処理装置２０の機能ブロック図である。情報処理装置２０は、入室情報取得部８１、退室情報取得部８２、利用時間算出部８３および請求処理部８４を備える。

入室情報取得部８１は、部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得する。退室情報取得部８２は、部屋の内側からスマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得する。利用時間算出部８３は、ユーザＩＤ、入室時刻および退室時刻に基づいて、それぞれのユーザの利用時間を算出する。請求処理部８４は、ユーザＩＤおよび利用時間に基づいて算出したそれぞれのユーザの利用料金を当該ユーザのクレジットカードを介して請求する。

［実施の形態４］
図１７は、実施の形態４の情報処理システム１０の構成を説明する説明図である。本実施の形態は、汎用のコンピュータ９０と、プログラム９７とを組み合わせて動作させることにより、本実施の形態の情報処理装置２０を実現する形態に関する。実施の形態１と共通する部分については、説明を省略する。

コンピュータ９０は、前述の制御部２１、主記憶装置２２、補助記憶装置２３、通信部２４、表示部２５１、入力部２５２およびバスに加えて読取部２９を備える。

プログラム９７は、可搬型記録媒体９６に記録されている。制御部２１は、読取部２９を介してプログラム９７を読み込み、補助記憶装置２３に保存する。また制御部２１は、コンピュータ９０内に実装されたフラッシュメモリ等の半導体メモリ９８に記憶されたプログラム９７を読出してもよい。さらに、制御部２１は、通信部２４および図示しないネットワークを介して接続される図示しない他のサーバコンピュータからプログラム９７をダウンロードして補助記憶装置２３に保存してもよい。

プログラム９７は、コンピュータ９０に制御プログラムとしてインストールされ、主記憶装置２２にロードして実行される。以上により、実施の形態１で説明した情報処理装置２０が実現される。

［実施の形態５］
本実施の形態は予約対象エリア１９２を含むコワーキングスペースを管理する情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図１８は、実施の形態５のコワーキングスペースのマップである。本実施の形態のコワーキングスペースは、四方を壁またはパーティションで囲まれており、一か所にゲート部１１が配置されている。部屋の内部に、２つの予約対象エリア１９２が配置されている。予約対象エリア１９２は、四方を壁またはパーティションで囲まれており、一か所に予約ゲート部１１１が配置されている。

予約ゲート部１１１は、たとえばドア等の出入口と、鍵機構１３とにより構成される。予約ゲート部１１１の鍵機構１３は、ゲート部１１の鍵機構１３と同様に、ネットワークを介して施錠および解錠される、いわゆるスマートロックである。予約ゲート部１１１は、ゲート部１１と同様にリーダ１４を備えてもよい。

なお、予約ゲート部１１１はロック状態であっても、予約対象エリア１９２内のユーザが予約対象エリア１９２の外に出ることは妨げない構造であることが望ましい。それにより、予約対象エリア１９２内にユーザが閉じ込められる事故を防止できる。

予約対象エリア１９２は、たとえば集中して作業を行ないたいユーザが使用する個室タイプの作業ブースである。予約対象エリア１９２は、複数のユーザが集まれる会議室であってもよい。予約対象エリア１９２は、ＷＥＢ会議用の会議ブースであってもよい。予約対象エリア１９２は、ユーザがゲームまたは運動等を行なえるレクリエーションエリアであってもよい。二つの予約対象エリア１９２の用途および設備は異なっていてもよい。

予約対象エリア１９２以外の部分は、ゲート部１１を通ったユーザが適宜使用できる共用エリア１９１である。共用エリア１９１には、図示を省略する机、椅子、コーヒーサーバ等が設置されたドリンクコーナー、複合機およびロッカー等が配置されている。

なお、図１８に示すマップは例示である。部屋全体の形状、ゲート部１１の位置、予約対象エリア１９２の数および配置等は、図１８に限定しない。

本実施の形態においては、ユーザは携帯機器３０を使用して予約対象エリア１９２の予約を行なう。予約が成立した場合、たとえば電子メールまたはＳＭＳにより、予約した時間に予約対象エリア１９２の予約ゲート部１１１を解錠する鍵情報がユーザ宛てに送信される。以下の説明では鍵情報はアクセスすることで制御部４１に解錠要求を送信可能な解錠用ＵＲＬである場合を例にして説明する。

予約した時間にユーザは携帯機器３０を使用して解錠用ＵＲＬにアクセスする。タッチパネル３５に、解錠ボタンが表示される。ユーザが解錠ボタンをタップした場合、解錠ボタンを表示したＷＥＢサーバから認証サーバ４０に対して、予約ゲート部１１１を解錠する解錠信号が送信される。

認証サーバ４０は、解錠信号に従い指定された予約ゲート部１１１を解錠する。ユーザは、予約対象エリア１９２に入室できる。仮に、ユーザが予約した時間を経過しても予約対象エリア１９２から退出しない場合、予約対象エリア１９２内に設置されたディスプレイまたは、携帯機器３０のプッシュ通知等により、予約時間が経過したことがユーザに通知される。

図１９は、予約鍵ＤＢ５３のレコードレイアウトを説明する説明図である。予約鍵ＤＢ５３は、場所ＩＤと、予約時間と、鍵情報とを関連づけて記録したデータベースである。ここで場所ＩＤは、予約対象エリア１９２に固有に付与されたＩＤであり、場所ＩＤが特定されることにより、予約対象エリア１９２の予約ゲート部１１１も特定される。

予約鍵ＤＢ５３は、場所ＩＤフィールド、予約時間フィールドおよび鍵情報フィールドを有する。予約時間フィールドは開始フィールドおよび終了フィールドを有する。場所ＩＤフィールドには、場所ＩＤが記録されている。開始フィールドおよび終了フィールドには、予約の開始時刻および終了時刻がそれぞれ記録されている。鍵情報フィールドには、制御部４１により発行された鍵情報が記録されている。

予約鍵ＤＢ５３は、１件の予約について、一つのレコードを有する。予約鍵ＤＢ５３は、補助記憶装置４３または認証サーバ４０に接続された外部の大容量記憶装置に記録されている。

図２０は、予約ＤＢ５９のレコードレイアウトを説明する説明図である。予約ＤＢ５９は、場所ＩＤと、予約時間と、ユーザＩＤと、鍵情報とを関連づけて記録したデータベースである。予約ＤＢ５９は、場所ＩＤフィールド、予約時間フィールド、ユーザＩＤフィールドおよび鍵情報フィールドを有する。予約時間フィールドは開始フィールドおよび終了フィールドを有する。

場所ＩＤフィールドには、場所ＩＤが記録されている。開始フィールドおよび終了フィールドには、予約の開始時刻および終了時刻がそれぞれ記録されている。ユーザＩＤフィールドには予約したユーザのユーザＩＤが記録されている。鍵情報フィールドには、制御部４１により発行された鍵情報が記録されている。

予約ＤＢ５９は、１件の予約について、一つのレコードを有する。予約ＤＢ５９は、補助記憶装置２３または情報処理装置２０に接続された外部の大容量記憶装置に記録されている。制御部２１と制御部４１とは、レプリケーション処理により予約鍵ＤＢ５３に記録された各レコードと、予約ＤＢ５９に記録されたユーザＩＤフィールドを除く各レコードとを同期する。レプリケーション処理は従来から使用されているため、詳細については説明を省略する。

図２１は、実施の形態５の予約時のプログラムの処理の流れを説明するフローチャートである。図２１のプログラムは、予約対象エリア１９２の予約を行なう際に、ユーザが携帯機器３０を操作して起動する。

制御部３１は、ネットワークを介して情報処理装置２０から予約ＤＢ５９に記録された予約情報を取得する（ステップＳ７１１）。制御部３１は、表示部３５１に予約受付画面６５（図２３参照）を表示する（ステップＳ７１２）。後述するように、予約受付画面６５には既に予約が入っている時間帯が表示される。

ユーザは、入力部３５２を操作して、予約要求を入力する。予約要求には、ユーザが予約したい予約対象エリア１９２および時間帯に関する情報が含まれる。制御部３１は入力された予約要求を受け付ける（ステップＳ７１３）。制御部３１は、予約要求を情報処理装置２０に送信する（ステップＳ７１４）。

制御部２１は、ユーザＩＤおよび予約に関する情報を受信する（ステップＳ６７１）。制御部２１は、認証サーバ４０に対してステップＳ６７１で受信した予約対象エリア１９２に対応する予約ゲート部１１１を、予約対象時間帯に解錠する鍵情報の発行を要求する（ステップＳ６７２）。

制御部４１は、要求を受信する（ステップＳ５１１）。制御部４１は、受信した要求に応じた鍵情報を生成する（ステップＳ５１２）。ここで、鍵情報は特定の予約ゲート部１１１を特定の時間帯に解錠させる際に使用されるデータであり、本実施の形態の予約解錠情報の例示である。前述の通り、鍵情報はアクセスすることで制御部４１に解錠要求を送信可能な解錠用ＵＲＬである場合を例にして説明する。

制御部４１は、生成した鍵情報を情報処理装置２０に送信する（ステップＳ５１３）。制御部４１は、予約鍵ＤＢ５３に新規レコードを作成し、予約対象エリア１９２に対応する場所ＩＤ、予約時間および生成した鍵情報を記録する（ステップＳ５１４）。

制御部２１は、鍵を受信する（ステップＳ６７３）。制御部２１は、予約ＤＢ５９に新規レコードを作成し、ステップＳ６７１で受信した予約対象エリア１９２に対応する場所ＩＤと、ユーザＩＤ、および、ステップＳ６７３で受信した鍵情報を記録する（ステップＳ６７４）。

制御部２１は、鍵情報をたとえば電子メールまたはＳＭＳ等を介して携帯機器３０に送信する（ステップＳ６７５）。制御部３１は、鍵情報を受信する（ステップＳ７１５）。制御部３１は、鍵情報を受信した旨をユーザに通知する（ステップＳ７１６）。その後、携帯機器３０は処理を終了する。

図２２は、実施の形態５の解錠時のプログラムの処理の流れを説明するフローチャートである。図２１のプログラムは、予約対象エリア１９２の解錠を行なう際に、ユーザが携帯機器３０を操作して起動する。

制御部３１は、図２１を使用して説明したフローチャートのステップＳ７１５で受信した鍵情報をタッチパネル３５に表示する（ステップＳ７２１）。前述のとおり、鍵情報は解錠用ＵＲＬである場合を例にして説明する。

ユーザは、入力部３５２を操作して、解錠用ＵＲＬにアクセスする。予約時間帯内であれば、タッチパネル３５に、解錠ボタンが表示される。予約時間帯よりも前であれば、解錠可能時間を示すメッセージ、または、単なるエラーメッセージがタッチパネル３５に表示される。予約時間帯よりも後であれば、予約した時間が過ぎている旨を示すメッセージ、または、単なるエラーメッセージがタッチパネル３５に表示される。図２２のフローチャートでは、タッチパネル３５に解錠ボタンが表示される場合の処理を示す。

ユーザは、入力部３５２を操作して解錠ボタンをタップする。制御部３１は、ユーザによる操作を受け付ける（ステップＳ７２２）。解錠ボタンを表示したＷＥＢサーバを介して認証サーバ４０に対して、ステップＳ７２１で表示した鍵情報が送信される。

制御部４１は、鍵情報を受信する（ステップＳ５２１）。制御部４１は、受信した鍵情報に基づく認証が成功したか否かを判定する（ステップＳ５２２）。具体的には制御部４１は、鍵情報をキーとして予約鍵ＤＢ５３を検索して、レコードを抽出する。現在時刻が、抽出したレコードの予約時間フィールドに記録された予約時間帯内である場合、制御部４１は認証に成功したと判定する。レコードを抽出できない場合、または予約時間帯内ではない場合、制御部４１は認証に成功していないと判定する。

認証に成功したと判定した場合（ステップＳ５２２でＹＥＳ）、制御部４１は鍵機構１３を制御して予約ゲート部１１１のロックを解除する（ステップＳ５２３）。以上により、ユーザは予約した予約対象エリア１９２に入場できる。

所定時間の経過後、または、図示を省略するセンサによりユーザの通過を検知した後に、制御部４１は、鍵機構１３を制御して自動的に予約ゲート部１１１をロックする。鍵機構１３は、所定時間の経過後、または、ユーザの通過を検知した後に自律的に予約ゲート部１１１をロックしてもよい。

認証に成功していないと判定した場合（ステップＳ５２２でＮＯ）、または、ステップＳ５２３の終了後、制御部４１は携帯機器３０からの鍵情報を待機する状態に戻る。なお、制御部４１は、予約ゲート部１１１に取り付けられたディスプレイ等に、認証に成功していない旨を表示しても良い。制御部４１は、コワーキングスペースの管理者等に、不正な要求があった旨を通知してもよい。

制御部３１は、予約終了時間が近づくまで待つ（ステップＳ７２３）。たとえば予約終了時間の２分前に制御部３１は、アラーム音、バイブレータの振動、または表示部３５１への表示等により、予約終了時間が近づいたことをユーザに通知する（ステップＳ７２４）。その後、制御部３１は処理を終了する。

図２３は、実施の形態５の画面である。制御部３１は、図２１を使用して説明したフローチャートのステップＳ７１２で、図２３に示す予約受付画面６５を表示する。予約受付画面６５は、画面の中央に表示されたスケジュール欄６５８と、スケジュール欄６５８の上側に表示された利用施設欄６５１および利用日欄６５３と、スケジュール欄６５８の下側に表示された利用時間欄６５４、利用エリア欄６５２および決定ボタン６５９を含む。

ユーザは、利用日欄６５３を操作して日付を指定する。ユーザは、利用施設欄６５１を操作して利用する施設を指定する。なお、ユーザが使用できる施設が１か所だけである場合、利用施設欄６５１は表示されなくてもよい。制御部３１は、利用施設欄６５１に設置されている予約対象エリア１９２について、利用日欄６５３で指定された日付における予約状況をスケジュール欄６５８に表示する。図２３における「ブース１」および「ブース２」は、それぞれの予約対象エリア１９２につけられた名称を示す。スケジュール欄６５８の横軸は、コワーキングスペースの営業時間を示す。ハッチングは、既に予約が埋まっている時間帯を示す。

ユーザは、利用時間欄６５４を操作して予約開始時刻および予約終了時刻を設定する。ユーザは利用エリア欄６５２を操作して予約する予約対象エリア１９２を指定する。なお、制御部３１は、先約のある時間帯が指定された場合には、決定ボタン６５９を選択不可の状態に設定する。入力終了後、ユーザは６５９を選択する。以上により、ユーザによる予約の入力が完了し、制御部３１は予約に関する情報を受け付ける（ステップＳ７１３）。

図２４は、実施の形態５の画面である。制御部３１は、ユーザが画面左側のメニュー欄６２から「予約情報」を選択した場合に、図２４に示す予約情報画面を表示する。予約情報画面は、予約情報欄６６を含む。ユーザは、予約情報欄６６を見て、自分が予約済のスケジュールを確認できる。制御部３１は、ユーザが詳細ボタン６５５を選択した場合に、当該予約に対応する鍵情報を表示してもよい。ユーザは、予約情報欄６６の上側に表示された検索欄を用いて、自分が予約済のスケジュールの検索を行なえる。

本実施の形態によると、予約対象エリア１９２を管理する情報処理システム１０を提供できる。ユーザは、予約することにより、所望の設備等を備える予約対象エリア１９２を確実に使用できる。

予約対象エリア１９２に予約ゲート部１１１が設けられていることにより、部外者が不用意に予約対象エリア１９２に入ることを防止できる。したがって、機密事項に関する会議またはビデオ会議等にも利用可能な予約対象エリア１９２を提供できる。なお、鍵情報が電子メールまたはＳＭＳによりユーザに送信されることにより、ユーザは会議への参加者に対して適宜鍵情報を配布できる。

予約対象エリア１９２の利用に関しては、従量制会員だけでなく、固定額会員に対しても追加料金が定められていてもよい。図２４の「利用料金」の列は、各予約に対して発生する追加料金の金額を示す。追加料金は、予約時期または利用時期により変動してもよい。たとえば、利用直前に予約したユーザに対しては、割安の料金が提示されても良い。

なお、固定額会員に対しては、たとえば毎月１０００円分までの利用は無料にする等の条件が定められていてもよい。制御部２１は、実施の形態１で説明した料金に追加料金を加算して、ユーザに請求する。

予約対象エリア１９２は、ユーザがゲート部１１を通過せずに到達できる場所に配置されていてもよい。ユーザは、コワーキングスペースのユーザ登録がない人物であっても、予約対象エリア１９２で開催する会議に容易に招待できる。

ユーザは、招待したゲストに対して鍵情報を渡す代わりに自分の電話番号等を教えてもよい。予約ゲート部１１１の前に到達したゲストは、招待元のユーザに電話をかけて到着した旨を伝える。ユーザは、携帯機器３０を操作して鍵情報を使用し、予約ゲート部１１１のロックを解除する。本実施の形態では予約ゲート部１１１の前に行かなくても鍵情報を使用してロックを解除できるため、ゲストに対して予約ゲート部１１１の解除方法等の説明を行なう必要はない。

制御部２１は、鍵情報に加えて携帯機器３０の位置情報を取得し、予約ゲート部１１１の前に携帯機器３０が存在する場合にのみロックを解除してもよい。予約した本人以外による予約対象エリア１９２を防止する情報処理システム１０を提供できる。

予約ゲート部１１１に、ＮＦＣまたはバーコードを用いた電子マネーの決裁端末が設置されていてもよい。制御部４１は、ステップＳ５２２で認証に成功した後、決済端末を介して予約対象エリア１９２の利用料金を請求する。決裁完了後に、制御部４１はステップＳ５２３に進み、予約ゲート部１１１のロックを解除する。以上により、予約対象エリア１９２の使用の都度、料金を精算する情報処理システム１０を提供できる。

なお、鍵情報は、予約ゲート部１１１に取り付けられたカメラに読み取らせることで予約ゲート部１１１を解錠させる二次元または一次元のバーコードであってもよい。鍵情報にバーコードを使用する場合、制御部３１はステップＳ７２１でタッチパネル３５に当該バーコードを表示する。ステップＳ７２２は省略される。ユーザは、バーコードを予約ゲート部１１１に取り付けられたカメラに翳す。ステップＳ５２１において、制御部４１はネットワークを介してバーコードを取得する。

鍵情報は、ユーザが予約ゲート部１１１に取り付けられたテンキーを使用して入力することで、予約ゲート部１１１を解錠させるキーコードであってもよい。鍵情報にキーコードを使用する場合、制御部３１はステップＳ７２１でタッチパネル３５に当該キーコードを表示する。ステップＳ７２２は省略される。ユーザは、キーコードを予約ゲート部１１１に取り付けられたテンキーに入力する。ステップＳ５２１において、制御部４１はネットワークを介して入力されたキーコードを取得する。

［変形例５－１］
図２５は、変形例５－１のコワーキングスペースのマップである。本変形例においては、個々の予約対象エリア１９２には予約ゲート部１１１が設けられていない。ユーザは、予約した時間に、解錠等の操作を行なうことなく予約対象エリア１９２を使用できる。仮に、予約したユーザが予約対象エリア１９２に行ったときに、他のユーザが使用していた場合には、たとえば図２４を使用して説明した予約情報画面を互いに確認する。

なお、予約ゲート部１１１が設けられた予約対象エリア１９２と、予約ゲート部１１１が設けられていない予約対象エリア１９２とが混在していてもよい。

［実施の形態６］
本実施の形態は、直前まで予約が入っていない予約対象エリア１９２を追加料金なしに提供する情報処理システム１０に関する。実施の形態５と共通する部分については、説明を省略する。

図２６は、実施の形態６のプログラムの処理の流れを説明するフローチャートである。制御部２１は、営業時間の間、それぞれの予約対象エリア１９２に関して、図２６のプログラムを並行して実行し続ける。

制御部２１は、予約ＤＢ５９を検索してたとえば５分後から予約対象エリア１９２が予約の入っていない、いわゆる空き状態になっているか否かを判定する（ステップＳ６８１）。空き状態になっていると判定した場合（ステップＳ６８１でＹＥＳ）、制御部２１はたとえばコワーキングスペースに配置されたディスプレイ、および、コワーキングスペースに関するＷＥＢページ等に、通知を表示する（ステップＳ６８２）。

通知は、たとえば「１５時から１６時まで、Ｗｅｂ会議ブースＡを追加料金なしで使用できます。ご利用は先着順です。Ｗｅｂ会議ブースＡまで直接おいでください」といったメッセージである。

制御部２１は、予約の入っていない時間に到達するまで待つ（ステップＳ６８３）。具体的には、たとえば上記のメッセージを表示した場合、制御部２１は１５時になるまで待つ。制御部２１は、認証サーバ４０に対して空き状態である予約対象エリア１９２に関する予約ゲート部１１１の解錠要求を送信する（ステップＳ６８４）。

制御部４１は、解錠要求を受信する（ステップＳ５３１）。制御部４１は、解錠要求を送信した情報処理装置２０が、予約対象エリア１９２を管理しているサーバであることを確認する（ステップＳ５３２）。なお、確認できない場合、制御部４１はステップＳ５３１で受信した解錠要求を無視する。

制御部４１は、鍵機構１３を制御して予約ゲート部１１１のロックを解除する（ステップＳ５３３）。本実施の形態においては、予約ゲート部１１１をユーザが通過した後でも、制御部４１は予約ゲート部１１１のロックを解錠したままの状態に維持する。

制御部２１は、空き時間の終了が近づくまで待つ（ステップＳ６８５）。たとえば空き時間終了の２分前に、制御部２１はたとえば予約対象エリア１９２内に設置されたディスプレイ等に、通知を表示する（ステップＳ６８６）。

通知は、たとえば「本Ｗｅｂ会議ブースＡを追加料金なしで使用できる時間はまもなく終了します。お客様は速やかに退出下さい」といったメッセージである。空き時間が終了後、制御部２１は、認証サーバ４０に対して予約対象エリア１９２に関する予約ゲート部１１１の施錠要求を送信する（ステップＳ６８７）。

制御部４１は、施錠要求を受信する（ステップＳ５３４）。制御部４１は、施錠要求を送信した情報処理装置２０が、予約対象エリア１９２を管理しているサーバであることを確認する（ステップＳ５３５）。なお、確認できない場合、制御部４１はステップＳ５３４で受信した解錠要求を無視する。確認後、制御部４１は、鍵機構１３を制御して予約ゲート部１１１をロックする（ステップＳ５３６）。

空き状態になっていないと判定した場合（ステップＳ６８１でＮＯ）、またはステップＳ６８７の終了後、制御部２１は、処理を終了するか否かを判定する（ステップＳ６８９）。たとえば、コワーキングスペースの営業終了時間が近づいた場合、制御部２１は処理を終了すると判定する。

終了しないと判定した場合（ステップＳ６８９でＮＯ）、制御部２１はステップＳ６８１に戻る。終了すると判定した場合（ステップＳ６８９でＹＥＳ）、制御部２１は処理を終了する。

本実施の形態によると、予約が入っていない予約対象エリア１９２を有効活用できる情報処理システム１０を提供できる。ユーザに対して、追加料金なしで予約対象エリア１９２の利用を体験することにより、予約対象エリア１９２のメリットを体験させて、将来の利用を促す情報処理システム１０を提供できる。

［実施の形態７］
本実施の形態は、前述の固定料金制および従量制に加えて、必要に応じてチケットを購入して利用するチケット制での利用が可能な情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２７は、実施の形態７の会員ＤＢ５７のレコードレイアウトを説明する説明図である。本実施の形態の会員ＤＢ５７は、図５を使用して説明した実施の形態１の会員ＤＢ５７に、チケットフィールドが追加された構成である。チケットフィールドには、それぞれのユーザが保有するチケットの数が記録されている。

会員種別フィールドの「チケット」は、チケット制の会員種別を示す。チケット制の会員は、携帯機器３０を操作してチケットをオンライン購入する。制御部２１は、ユーザが購入したチケットの数をチケットフィールドに加算する。なお、たとえば１０回分の値段で１１回分のチケットが購入できる、いわゆる回数券型のチケットが提供されていてもよい。

図２８は、実施の形態７のプログラムの処理の流れを説明するフローチャートである。図２８のプログラムは、図１１を使用して説明したプログラムの代わりに実行される。

制御部４１は、リーダ１４を介して会員証１５に記録された会員証ＩＤを読み取る（ステップＳ５０１）。制御部４１は、会員証ＩＤをキーとして有効ＤＢ５２を検索して、レコードを抽出する。制御部４１は、抽出したレコードの状態フィールドを参照して、会員証１５が有効であるか否かを判定する（ステップＳ５０２）。なお制御部４１は会員証ＩＤをキーとして有効ＤＢ５２からレコードを抽出できない場合には、会員証１５が有効ではないと判定する。

有効であると判定した場合（ステップＳ５０２でＹＥＳ）、制御部４１はステップＳ５０１で読み取った会員証ＩＤを情報処理装置２０に送信する（ステップＳ５４１）。制御部２１は、会員証ＩＤを受信する（ステップＳ６９１）。制御部２１は、ユーザの会員種別がチケット制であるか否かを判定する（ステップＳ６９２）。

具体的には、制御部２１は会員証ＩＤをキーとして会員ＤＢ５７を検索し、レコードを抽出する。抽出したレコードの会員種別フィールドに「チケット」が記録されている場合、制御部２１は当該ユーザの会員種別はチケット制であると判定する。

チケット制の会員ではない、すなわち従量制または固定制の会員であると判定した場合（ステップＳ６９２でＮＯ）、制御部２１はゲート部１１のロックを解除する旨を認証サーバ４０に送信する（ステップＳ６９３）。

チケット制の会員であると判定した場合（ステップＳ６９２でＹＥＳ）、制御部２１は抽出したレコードのチケットフィールドから、ユーザが保有しているチケットの数を取得する。ユーザが必要な数のチケットを保有している場合、制御部２１は必要数のチケットを減算した値にチケットフィールドのデータを更新する（ステップＳ６９４）。

なお、一度正規に入場したユーザに対して、当日中のゲート部１１の出入りを自由に認める場合、制御部２１は当日１回目の入場である場合にのみ、チケットフィールドのデータを更新する。

制御部２１は、ゲート部１１のロックの解除有無に関する情報を認証サーバ４０に送信する（ステップＳ６９５）。具体的には、ステップＳ６９４においてユーザが必要な数のチケットを保有していた場合、制御部２１はゲート部１１のロックを解除する旨を認証サーバ４０に送信する。チケットの数が不足していた場合、制御部２１はロックを解除しない旨を認証サーバ４０に送信する。

制御部４１は、ステップＳ６９３またはステップＳ６９５で送信された情報を受信する（ステップＳ５４２）。制御部４１は、受信した情報がロックを解除する旨を示すか否かを判定する（ステップＳ５４３）。解除する旨を示すと判定した場合（ステップＳ５４３でＹＥＳ）、制御部４１は、鍵機構１３を制御してゲート部１１のロックを解除する（ステップＳ５０４）。制御部４１は、入退室ＤＢ５１にユーザの入退室を記録する（ステップＳ５０５）。

有効ではないと判定した場合（ステップＳ５０２でＮＯ）、または、解除しない旨を示すと判定した場合（ステップＳ５４３でＮＯ）、制御部４１はエラー通知を出力する（ステップＳ５０３）。具体的には制御部４１は、たとえば図示を省略するスピーカからビープ音または「エラーです」等の音声を出力する。

ステップＳ５０３またはステップＳ５０５の終了後、制御部４１は処理を終了するか否かを判定する（ステップＳ５０６）。たとえばコワーキングスペースの閉店時刻を過ぎた場合に、制御部４１は処理を終了すると判定する。

処理を終了しないと判定した場合（ステップＳ５０６でＮＯ）、制御部４１はステップＳ５０１に戻る。処理を終了すると判定した場合（ステップＳ５０６でＹＥＳ）、制御部４１は処理を終了する。

ステップＳ６９５の終了後、制御部２１は、ユーザが保有しているチケットの数を携帯機器３０に送信する（ステップＳ６９６）。携帯機器３０は、チケットの数を受信する（ステップＳ７３１）。携帯機器３０は、チケットの数に応じたメッセージをタッチパネル３５に表示する（ステップＳ７３２）。

たとえば、残りのチケットの数が２枚である場合、制御部３１は「チケットは、残り２枚です。」と表示する。残りのチケットの数が１枚である場合、制御部３１は「チケットが無くなりました。次回の御利用前に、チケットを購入してください」と表示する。チケットが不足しており、ゲート部１１のロックを解除しない場合、制御部３１は「チケットが不足しているため、入場できません。必要なチケットを購入してください」と表示する。

制御部３１は、チケットをオンライン購入するためのボタンをタッチパネル３５に表示してもよい。制御部３１は、たとえば回数券を購入するためのボタンと、１回券を購入するためのボタンとを並べてタッチパネル３５に表示してもよい。

チケットが不足していたユーザは、携帯機器３０を操作してチケットをオンライン購入した後に、リーダ１４に会員証１５を再度読み取らせることにより、ゲート部１１のロックを解除して入場できる。

本実施の形態によると、使用した分だけ料金を支払いたいユーザに対応できる情報処理システム１０を提供できる。たとえば、新規登録したユーザに対して、３回分のチケットをプレゼントするような施策により、販促を行なえる情報処理システム１０を提供できる。

なお、使用する施設に応じて、一回の利用に必要なチケットの数が異なるように設定されても良い。従量制または固定制のユーザが、実施の形態５で説明した予約対象エリア１９２を使用する際に、本実施の形態で説明したチケットを利用できてもよい。

［実施の形態８］
本実施の形態は、ユーザの利用回数を制限できる情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２９は、実施の形態８の会員ＤＢ５７のレコードレイアウトを説明する説明図である。本実施の形態の会員ＤＢ５７は、図５を使用して説明した実施の形態１の会員ＤＢ５７に、残回数フィールドが追加された構成である。残回数フィールドには、それぞれのユーザが施設を利用可能な残り回数が記録されている。「無制限」は、利用回数に制限が設けられていないことを示す。

ユーザが施設を利用するたびに、制御部２１は残回数フィールドの値を一つ減少させる。残回数フィールドの値がゼロになった場合、当該ユーザの会員証１５では施設のゲート部１１のロックが解除されない。制御部２１は、たとえば１日に１回、または、１週間に１回等、所定の頻度で残回数フィールドを初期値に設定する。なお、初期値の値は、ユーザごとに異なる値が定められていてもよい。

図３０は、実施の形態８のプログラムの処理の流れを説明するフローチャートである。ステップＳ６９１までの処理は、図２８を使用して説明した実施の形態７の処理の流れと同一であるため説明を省略する。制御部２１は、ユーザの残回数がゼロであるか否かを判定する（ステップＳ８０１）。

具体的には、制御部２１は会員証ＩＤをキーとして会員ＤＢ５７を検索し、レコードを抽出する。抽出したレコードの残回数フィールドに「０」が記録されている場合、制御部２１は当該ユーザの残回数はゼロであるあると判定する。

ゼロではない、すなわち施設を利用できる会員であると判定した場合（ステップＳ８０１でＮＯ）、制御部２１は抽出したレコードを更新して残回数を一つ減少させる（ステップＳ８０２）。制御部２１は、ゲート部１１のロックを解除する旨を認証サーバ４０に送信する（ステップＳ８０３）。残回数がゼロであると判定した場合（ステップＳ８０１でＹＥＳ）、制御部２１はゲート部１１のロックを解除しない旨を認証サーバ４０に送信する（ステップＳ８０４）。

制御部４１は、ステップＳ８０３またはステップＳ８０４で送信された情報を受信する（ステップＳ５４２）。以後の処理は、図２８を使用して説明した実施の形態７の処理の流れと同一であるため説明を省略する。

制御部２１は、残回数がゼロである旨を携帯機器３０に送信する（ステップＳ８０５）。携帯機器３０は、残回数がゼロである旨を受信する（ステップＳ７４１）。携帯機器３０は、以下に説明するメッセージをタッチパネル３５に表示する（ステップＳ７４２）。

たとえば、一日に一回残回数を初期化する場合、制御部３１は「本日分の利用回数を超過しました。本日は再度ご利用することはできません」と表示する。同様に、一週間に一回残回数を初期化する場合、制御部３１は「今週分の利用回数を超過しました。次の月曜日までお待ちください」と表示する。

会員種別を変更することにより利用可能になるユーザに対しては、制御部３１は「本日分の利用回数を超過しました。再度ご利用したい場合には、固定制会員への変更手続きを行なって下さい」というメッセージと共に、会員種別の変更申し込み用のボタンを表示してもよい。

制御部３１は、「本日分の利用回数を超過しました。２００円／回の追加チケットを購入すれば利用可能です」というメッセージとともに、チケットをオンライン購入するためのボタンを表示してもよい。ユーザがチケットを購入した場合、制御部２１は購入された数を残回数フィールドに加算する。

規約等により、ユーザが追加料金の支払いに同意している場合、ステップＳ８０４で制御部２１はゲート部１１のロックを解除する旨を認証サーバ４０に送信し、ステップＳ７４２で制御部３１は「本日分の利用回数を超過しました。以後の御利用には、１０円／分の追加料金が掛かります」というメッセージを表示してもよい。制御部２１は、通常の料金に加えて追加料金をユーザに請求する。

本実施の形態によると、利用頻度が高い特定のユーザに対して利用制限または追加料金の請求を行なうことにより、ユーザ間の利用状況を平準化し、多くのユーザが利用しやすい状態に管理する情報処理システム１０を提供できる。

［実施の形態９］
本実施の形態は、無人で会員証１５を発行できる情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

本実施の形態においては、共用エリア１９１内に会員証１５の自動登録機が設置されている。未登録のユーザは、オンラインで発行されたゲストユーザ用の鍵情報を使用して共用エリア１９１に入り、自動登録機を自分で操作する。

本実施の形態においては、部屋の入口には、実施の形態５で説明した予約ゲート部１１１が設置されている。ユーザは、オンラインで実施の形態５で説明した鍵情報を受け取る。鍵情報の発行は、図２１を使用して説明した実施の形態５の処理と同様であるため、説明を省略する。

図３１は、実施の形態９のプログラムの処理の流れを説明するフローチャートである。ステップＳ５２３までの処理は、図２２を使用して説明した実施の形態５のプログラムの処理の流れと同様であるため、説明を省略する。

ステップＳ５２３でゲート部１１が解除された後、ユーザはゲート部１１を通過して室内に入り、自動登録機を操作する。自動登録機は、ネットワークを介して情報処理装置２０に接続されており、制御部２１により制御される。

制御部２１は、ユーザから会員登録に必要な情報の入力を受け付ける（ステップＳ８１１）。なお、制御部２１はユーザが鍵情報を申し込んだ際に入力した情報を表示して、ユーザによる追加または修正を受け付けてもよい。

ユーザは、自動登録機に付属するカードリーダに、手持ちのＩＣカードまたはスマートフォン等を翳す。制御部２１は、カードリーダを介して、ＩＣカードまたはスマートフォンに内蔵されたＩＣチップに固有に付与されたＩＤ情報を取得する（ステップＳ８１２）。制御部２１は、会員ＤＢ５７に新規レコードを作成する。

制御部２１は、ユーザに固有のユーザＩＤを発行して、ユーザＩＤフィールドに記録する。制御部２１は、ステップＳ８１２で取得したＩＤ情報を会員証ＩＤフィールドに記録する。制御部２１は、氏名フィールド以降のフィールドにも、適宜情報を記録する（ステップＳ８１３）。

以上により、ユーザが既に保有しているＩＣカードまたはスマートフォン等が会員ＤＢ５７に登録されて、会員証１５の機能を果たすようになる。なお、既に保有しているＩＣカード等の利用を希望しないユーザに対しては、制御部２１は自動登録機内に保持されているブランクのＩＣカードを利用して、会員証１５を発行してもよい。

本実施の形態によると、人手を介さずに会員証１５を発行できる情報処理システム１０を提供できる。

［変形例９－１］
本変形例は、親ユーザに紐づけられた子ユーザ用の会員証１５を発行する情報処理システム１０に関する。実施の形態９と共通する部分については、説明を省略する。

本実施の形態においては、たとえば企業または学校等の団体が親ユーザになり、社員または学生等の子ユーザを管理する。図３２および図３３は、変形例９－１の画面例である。図３２は、たとえば企業の総務部門の担当者が、社員を登録する際に使用するパソコンの画面例である。

担当者は、図３２に示す画面を使用して、社員の氏名、メールアドレスおよびパスワード等を情報処理装置２０に送信して、鍵情報の発行要求を行なう。情報処理装置２０は、認証サーバ４０から各社員用の鍵情報を取得して、担当者に送信する。担当者は鍵情報を社員に転送する。なお、情報処理装置２０から各社員に対して鍵情報が直接送信されてもよい。

図３３は、総務部門の担当者が、自社の社員の登録情報を管理する画面の例である。担当者は、図３３に示す画面を使用して、登録済の社員の検索、登録情報の変更および登録情報の削除等を行なえる。

鍵情報を受け取った社員は、実施の形態９で説明したように、指定された場所に行って自動登録機を操作して、会員証１５を登録する。なお、自動登録機は社内に設置されていてもよい。制御部２１は、それぞれの社員のユーザＩＤを、企業が保有する親ＩＤに紐づけて記録し、それぞれの社員の利用料金を、親ユーザである企業に一括して請求する。

本変形例によると、企業はテレワーク用の仕事場所を社員に提供できる。福利厚生の一環として、希望する社員に対して子ＩＤが発行されてもよい。

［実施の形態１０］
本実施の形態は、ユーザＩＤを利用して種々の物品の販売を行なう情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図３４は、実施の形態１０の商品ロッカー１８を説明する説明図である。商品ロッカー１８は、たとえば共用エリア１９１に設置される。図３４に示す例では、商品ロッカー１８は大中小の３種類のサイズの合計５個のロッカーと、中央に設置された１個のディスプレイとを備える。それぞれのロッカーの扉には鍵機構１３が取り付けられており、認証サーバ４０により遠隔操作される。

ディスプレイには、それぞれのロッカー内に収容された商品の一覧が表示されている。図３４に示す例では、１番のロッカーには栄養ドリンクが、３番のロッカーにはひざ掛けが、４番のロッカーにはハンドタオルが収容されている。２番と５番のロッカーには、商品が収容されていない。ユーザは、所望の商品を選択し、扉を開けて中の商品を取り出せる。制御部２１は、コワーキングスペースの利用料と共に商品の代金を請求する。

図３５は、商品ＤＢ５５のレコードレイアウトを説明する説明図である。商品ＤＢ５５は、設置場所フィールド、ロッカーＩＤフィールド、商品フィールドおよび価格フィールドを有する。設置場所フィールドには、商品ロッカー１８が設置された場所が記録されている。

ロッカーＩＤフィールドには、個々のロッカーに固有に付与されたロッカーＩＤが記録されている。商品フィールドには、ロッカーに収容された商品が記録されている。価格フィールドには、商品の価格が記録されている。

商品ＤＢ５５は、一つのロッカーについて一つのレコードを有する。商品ＤＢ５５は、補助記憶装置２３または情報処理装置２０に接続された外部の大容量記憶装置に記録されている。

図３６は、実施の形態１０のプログラムの処理の流れを説明するフローチャートである。図３６のプログラムは、商品ロッカー１８内の商品を購入したい場合に、ユーザが携帯機器３０を操作して起動する。

制御部３１は、ユーザＩＤを情報処理装置２０に送信する（ステップＳ７５１）。制御部２１は、ユーザＩＤを受信する（ステップＳ８２１）。制御部２１は、受信したユーザＩＤをキーとして入退室ＤＢ５６を検索し、ユーザが最近出入りしたゲート部１１に近い場所に設置された商品ロッカー１８の設置場所を判定する（ステップＳ８２２）。

制御部２１は、商品ロッカー１８の設置場所をキーとして商品ＤＢ５５を検索し、当該商品ロッカー１８で販売されている商品の一覧を抽出する（ステップＳ８２３）。制御部２１は、抽出した情報を携帯機器３０に送信する（ステップＳ８２４）。

制御部３１は、商品の一覧を受信する（ステップＳ７５２）。制御部３１は、タッチパネル３５に図３７に例示する商品選択画面を表示する（ステップＳ７５３）。制御部３１は、ユーザによる商品の選択を受け付ける（ステップＳ７５４）。制御部３１は、選択された商品に関する情報またはロッカー番号に関する情報を情報処理装置２０に送信する（ステップＳ７５５）。制御部３１は処理を終了する。

制御部２１は、情報を受信する（ステップＳ８２５）。制御部２１は、ユーザが選択した商品が収容されたロッカーの扉に関する解錠要求を認証サーバ４０に送信する（ステップＳ８２６）。制御部４１は、解錠要求を受信する（ステップＳ５５１）。制御部４１は、鍵機構１３を制御してロッカーの扉のロックを解除する（ステップＳ５５２）。ユーザは、扉を開けて商品を取り出す。制御部２１は、商品ＤＢ５５にユーザが選択した商品が無くなった旨を記録する（ステップＳ８２７）。

図３７は、実施の形態１０の画面例である。図３７を使用して、ステップＳ７５３で制御部３１がタッチパネル３５に表示する商品購入画面の例を説明する。商品購入画面の中央部に、商品選択欄６８１が表示されている。商品選択欄６８１は、プルダウンメニュー形式である。ユーザは商品選択欄６８１を操作して所望の商品を選択した後に、商品選択欄６８１に下側に配置された購入ボタン６８２をタップする。以上により、商品の選択が完了し、制御部４１により扉のロックが解除される。

本実施の形態によると、一般の自動販売機では取り扱いが困難な様々な形状および寸法の商品の無人販売を行なる情報処理システム１０を提供できる。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 情報処理システム
１１ ゲート部
１１１ 予約ゲート部
１２ 出入口
１３ 鍵機構
１４ リーダ
１４１ 第１リーダ
１４２ 第２リーダ
１５ 会員証
１８ 商品ロッカー
１９１ 共用エリア
１９２ 予約対象エリア
２０ 情報処理装置
２１ 制御部
２２ 主記憶装置
２３ 補助記憶装置
２４ 通信部
２５１ 表示部
２５２ 入力部
２９ 読取部
３０ 携帯機器
３１ 制御部
３２ 主記憶装置
３３ 補助記憶装置
３４ 通信部
３５ タッチパネル
３５１ 表示部
３５２ 入力部
４０ 認証サーバ
４１ 制御部
４２ 主記憶装置
４３ 補助記憶装置
４４ 通信部
５１ 入退室ＤＢ
５２ 有効ＤＢ
５３ 予約鍵ＤＢ
５５ 商品ＤＢ
５６ 入退室ＤＢ
５７ 会員ＤＢ
５８ 請求ＤＢ
５９ 予約ＤＢ
６１ 混雑状況欄
６２ メニュー欄
６３ トップ欄
６４ 会員一覧欄
６４１ 検索欄
６５ 予約受付画面
６５１ 利用施設欄
６５２ 利用エリア欄
６５３ 利用日欄
６５４ 利用時間欄
６５５ 詳細ボタン
６５８ スケジュール欄
６５９ 決定ボタン
６６ 予約情報欄
６８１ 商品選択欄
６８２ 購入ボタン
８１ 入室情報取得部
８２ 退室情報取得部
８３ 利用時間算出部
８４ 請求処理部
９０ コンピュータ
９６ 可搬型記録媒体
９７ プログラム
９８ 半導体メモリ

Claims (14)

1. 部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得し、
   部屋の内側から前記スマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得し、
   各日付について、前記ユーザＩＤごとに、複数の入室時刻または複数の退室時刻を取得した場合、一日の最初の入室時刻から同じ日の最後の退室時刻までの時間である利用時間を算出し、
   前記ユーザＩＤおよび前記利用時間に基づいて算出したそれぞれのユーザの利用料金を前記ユーザのクレジットカードを介して請求する
   処理をコンピュータが実行する情報処理方法。
2. 前記部屋の外側に、ユーザが所持する会員証から前記会員証に固有に付与された会員証ＩＤを読み取る第１リーダが配置されており、
   前記部屋の内側に、前記会員証から前記会員証ＩＤを読み取る第２リーダが配置されており、
   会員証ＩＤと、有効なユーザＩＤとを関連づけて記録したデータベースを検索して前記第１リーダまたは前記第２リーダが読み取った前記会員証ＩＤが有効なユーザＩＤと関連づけられていると判定した場合に、前記スマートロックを解錠する
   請求項１に記載の情報処理方法。
3. 前記スマートロックの鍵情報をゲストユーザに対して送信し、
   前記鍵情報を受け付けた場合に、前記スマートロックを解錠し、
   前記部屋の内部に設置された登録機を介して前記ゲストユーザの会員登録を行なう
   請求項２に記載の情報処理方法。
4. 前記登録機を介して、前記ゲストユーザが保有するＩＣカードまたはスマートフォンに搭載されたＩＣチップのＩＤを読み取り、
   会員証ＩＤと、有効なユーザＩＤとを関連づけて記録したデータベースに、読み取ったＩＤを会員証ＩＤに使用して、会員証ＩＤと前記ゲストユーザに付与したユーザＩＤとを関連づけて記録する
   請求項３に記載の情報処理方法。
5. 登録済の親ユーザから、前記鍵情報の発行要求を受け付け
   前記鍵情報を使用して会員登録を行なった子ユーザの料金を前記親ユーザに請求する
   請求項３または請求項４に記載の情報処理方法。
6. 複数のユーザの前記ユーザＩＤ、前記入室時刻および前記退室時刻に基づいて、前記部屋の混雑情報を出力する
   請求項１から請求項５のいずれか一つに記載の情報処理方法。
7. 前記ユーザＩＤと契約条件とを関連づけて記録したデータベースから取得した、前記ユーザＩＤに対応するユーザの契約条件が固定料金制である場合、
   前記ユーザのクレジットカードを介して前記契約条件に基づく固定料金を請求する
   請求項１から請求項６のいずれか一つに記載の情報処理方法。
8. 前記契約条件がロッカーの契約を含む場合、前記ユーザのクレジットカードを介して前記ロッカーの料金を請求する
   請求項７に記載の情報処理方法。
9. 予約対象エリアの指定と、予約時間とを含む予約要求を受け付け、
   前記予約要求に対応する予約解錠情報を送信し、
   前記予約解錠情報を受け付けた場合に、前記予約時間内であるか否かを判定し、
   前記予約時間内であると判定した場合、前記予約対象エリアに設置されたスマートロックを解錠する
   請求項１から請求項８のいずれか一つに記載の情報処理方法。
10. 前記予約対象エリアは、前記部屋の内部に配置されている
    請求項９に記載の情報処理方法。
11. 前記予約対象エリアは、前記部屋の全体である
    請求項９に記載の情報処理方法。
12. 部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得し、
    部屋の内側から前記スマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得し、
    前記ユーザＩＤ、前記入室時刻および前記退室時刻に基づいて、それぞれのユーザの利用時間を算出し、
    前記ユーザＩＤおよび前記利用時間に基づいて算出したそれぞれのユーザの利用料金を前記ユーザのクレジットカードを介して請求し、
    前記スマートロックの鍵情報をゲストユーザに対して送信し、
    前記鍵情報を受け付けた場合に、前記スマートロックを解錠し、
    前記部屋の内部に設置された登録機を介して前記ゲストユーザの会員登録を行なう
    処理をコンピュータが実行する情報処理方法。
13. 部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得し、
    部屋の内側から前記スマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得し、
    各日付について、前記ユーザＩＤごとに、複数の入室時刻または退室時刻を取得した場合、一日の最初の前記入室時刻から同じ日の最後の前記退室時刻までの時間である利用時間を算出し、
    前記ユーザＩＤおよび前記利用時間に基づいて算出したそれぞれのユーザの利用料金を前記ユーザのクレジットカードを介して請求する
    処理をコンピュータに実行させるプログラム。
14. 部屋の外側からスマートロックを解錠したユーザのユーザＩＤおよび入室時刻を取得する入室情報取得部と、
    部屋の内側から前記スマートロックを解錠したユーザのユーザＩＤおよび退室時刻を取得する退室情報取得部と、
    各日付について、前記ユーザＩＤごとに、複数の入室時刻または退室時刻を取得した場合、一日の最初の前記入室時刻から同じ日の最後の前記退室時刻までの時間である利用時間を算出する利用時間算出部と、
    前記ユーザＩＤおよび前記利用時間に基づいて算出したそれぞれのユーザの利用料金を前記ユーザのクレジットカードを介して請求する請求処理部と
    を備える情報処理装置。

Images