(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023022103
(43)【公開日】2023-02-14
(54)【発明の名称】情報処理装置、プログラム及び情報処理方法
(51)【国際特許分類】
G06Q 50/10 20120101AFI20230207BHJP
【FI】
G06Q50/10
【審査請求】未請求
【請求項の数】6
【出願形態】OL
(21)【出願番号】P 2022182761
(22)【出願日】2022-11-15
(62)【分割の表示】P 2021043061の分割
【原出願日】2021-03-17
(71)【出願人】
【識別番号】516329543
【氏名又は名称】株式会社バカン
(72)【発明者】
【氏名】篠原 清志
(57)【要約】 (修正有)
【課題】正確性の高い空き情報を配信する情報処理装置、プログラム及び情報処理方法を提供する。
【解決手段】空席管理サーバ10、入力端末20及び複数のユーザ端末30が、インターネットなどのネットワーク50を介して相互接続されている空席管理システム1において、空席管理サーバ10は、施設の空き状況を示す空き情報を配信する情報処理装置であって、施設に関する施設情報を記憶する記憶手段と、第1のユーザ端末から送信される施設の第1の空き情報及び施設から送信される施設の第2の空き情報を取得する取得手段と、第1の空き情報及び第2の空き情報に基づいて、第2のユーザ端末に送信する空き情報を決定する決定手段と、決定手段が決定した空き情報を第2のユーザに送信する送信手段と、を有する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
施設の空き状況を示す空き情報を配信する情報処理装置であって、 施設に関する施設情報を記憶する記憶手段と、 第1のユーザ端末から送信される前記施設の第1の空き情報、および、前記施設から送信される前記施設の第2の空き情報を取得する取得手段と、 前記第1の空き情報および前記第2の空き情報に基づいて、第2のユーザ端末に送信する空き情報を決定する決定手段と、 前記決定手段が決定した空き情報を前記第2のユーザに送信する送信手段と、を有する情報処理装置。
【請求項2】
前記決定手段は、前記第1の空き情報および前記第2の空き情報との組み合わせに基づいて、前記第2のユーザ端末に送信する空き情報を決定する、請求項1に記載の情報処理装置。
【請求項3】
前記決定手段は、前記第1の空き情報と前記第2の空き情報それぞれの受信日時に基づいて、前記第2のユーザ端末に送信する空き情報を決定する、請求項2に記載の情報処理装置。
【請求項4】
前記空き情報は、前記施設に空きがあることを示す第1のステータスと、前記施設に空きがないことを示す第2のステータスと、前記第1のステータスと前記第2のステータスの中間の空き状況を示す第3のステータスを含む選択肢から選択された情報であり、 前記決定手段は、前記第1の空き情報が前記第3のステータスである場合には、前記第1の空き情報ではなく、前記第2の空き情報を前記第2のユーザ端末に送信する、請求項2に記載の情報処理装置。
【請求項5】
コンピュータを、請求項1~4のいずれか1項に記載の情報処理装置として機能させるプログラム。
【請求項6】
情報処理装置により実行される情報処理方法であって、 施設に関する施設情報を記憶することと、 第1のユーザ端末から送信される前記施設の第1の空き情報、および、前記施設から送信される前記施設の第2の空き情報を取得することと、前記第1の空き情報および前記第2の空き情報に基づいて、第2のユーザ端末に送信する空き情報を決定することと、 前記決定した空き情報を前記第2のユーザに送信することと、を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理装置、プログラム及び情報処理方法に関する。
【背景技術】
【0002】
店舗の空き情報をユーザがオンラインで確認できるようにするための技術は、例えば飲食店などの空き情報を提供するために用いられている。特許文献1には、「来店予約を行う前に、店舗の混雑状況を利用者に提供する」ことを課題として、「情報管理システムは、店舗に設置され店舗の混雑状況を示す混雑情報を送信する店舗端末40と、店舗端末が設置された店舗に関する混雑情報を含んだ店舗データを管理するサーバ装置10と、を有する。サーバ装置は、店舗端末から送信される混雑情報を受信し、店舗データに含まれる混雑情報のステータスを、受信した混雑情報のステータスに更新する。店舗を利用する利用者からの、店舗の混雑状況を確認したい旨の要求を受け付け、記憶された店舗データに基づき、店舗の混雑状況を示す画面データを生成し、利用者が所持するユーザ端末20に送信する。サーバ装置は、送信した画面データに対する利用者の操作に応じて、店舗への来店予約を行う。」という技術を開示している(同文献の要約参照)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記特許文献1の技術においては、例えば空き情報の更新漏れがあった場合や、空き情報の入力ミスがあった場合などに、ユーザ端末に配信される空き情報が、現時点での店舗の実際の空き状況と異なってしまうことがある。
【0005】
そこで、本開示は、正確性の高い空き情報を配信する技術を提供する。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本開示の情報処理装置は、第1のユーザ端末から送信される前記施設の第1の空き情報、および、前記施設から送信される前記施設の第2の空き情報を取得する取得手段と、前記第1の空き情報および前記第2の空き情報に基づいて、第2のユーザ端末に送信する空き情報を決定する決定手段と、前記決定手段が決定した空き情報を前記第2のユーザに送信する送信手段と、を有する。
【0007】
本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではない。
【発明の効果】
【0008】
本開示の技術によれば、正確性の高い空き情報を配信することができる。
【図面の簡単な説明】
【0009】
【
図1】第1の実施形態に係る空席管理システムの構成図である。
【
図2A】空席管理サーバのハードウェア構成図である。
【
図3A】データベースに格納されているデータ例を示す図である。
【
図3B】データベースに格納されているデータ例を示す図である。
【
図3C】データベースに格納されているデータ例を示す図である。
【
図6】空席管理サーバにおける空き情報の配信処理手順を示すフローチャートである。
【
図7】空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
【
図8】ユーザ端末における空き情報の表示処理手順を示すフローチャートである。
【
図9】第1の実施形態に係るユーザ端末の表示画面の例である。
【
図10】ユーザ端末における投稿画面の表示手順を示すフローチャートである。
【
図11】第1の実施形態に係る空き情報の投稿画面の一例を示す図である。
【
図12】第2の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
【
図13】第3の実施形態に係る入力端末の固定情報設定画面の一例を示す図である。
【
図14】第3の実施形態に係るデータベースに格納されているデータ例を示す図である。
【
図15】第3の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
【発明を実施するための形態】
【0010】
以下、本開示の実施形態について、図面を参照して説明する。同一の構成については、同じ符号を付して説明する。尚、以下の実施形態は本開示の技術を限定するものではなく、また、実施形態で説明されている特徴の組み合わせの全てが上記課題の解決手段に必須のものとは限らない。
【0011】
[第1の実施形態]<空席管理システム1の構成例> 第1の実施形態では、席やテーブルが設置され飲食が提供される店舗に新たな利用客が利用可能な空席(又は空きテーブル)があるか否かを示す空き状況(例えば、空席、やや混雑、満席:「混雑状況」ということもでき、本実施形態では両者は同意である)を、ユーザ端末に配信する空席管理システムについて説明する。
【0012】
図1は、第1の実施形態に係る空席管理システム1を示す構成図である。空席管理システム1は、店舗の空き状況を示す情報(空き情報)を管理するシステムであり、空席管理サーバ10、入力端末20及びユーザ端末30を備える。入力端末20は、例えば、店舗40内で操作されるスマートフォン又はタブレットなどのコンピュータデバイスであり、店舗40の店員が目視で確認した空き状況を示す空き情報を入力できるように構成されている。入力端末20は、店舗40に対応する端末として事前に設定されている。ユーザ端末30は、例えば、スマートフォン又はタブレットなどのコンピュータデバイスであり、当該空席管理システム1が提供するサービスのユーザの端末である。ユーザ端末30は、店舗40の空き状況を示す空き情報を入力し空席管理サーバ10に送信できるように構成されている。空席管理サーバ10は、店舗40外に設置されており、入力端末20及びユーザ端末30から受信する空き状況を示すデータを管理するサーバである。空席管理サーバ10、入力端末20及びユーザ端末30は、例えばインターネットなどのネットワーク50を介して相互接続されている。
図1においては、入力端末20を保有する店舗40が1店舗のみ示されているが、店舗40の数は複数であってもよい。ただし本実施形態では、いずれの店舗40の空き情報も、「空きあり」、「やや混雑」、「満席」のいずれかが取りうる選択肢であるとする。
【0013】
空席管理サーバ10は、入力端末20から受信した店舗40の空き状況を示すデータと、ユーザ端末30から受信した店舗40の空き状況を示すデータと、をデータベースに格納する。空席管理サーバ10は、入力端末20から受け取ったデータにしたがってデータベースを更新することにより、店舗40ごとの最新の空き状況をデータベース上で管理する。なお、ここで「最新」とは、入力端末20による送信日時を基準とすることができる。また、空席管理サーバ10は、ユーザ端末30から受け取ったデータにしたがってデータベースを更新することにより、店舗40ごとの空き状況をデータベース上で管理する。
【0014】
いずれかの店舗40を訪れようとしているユーザは、ユーザ端末30を介して、店舗40の空き情報を空席管理サーバ10に対して照会することができる。空席管理サーバ10はその照会に応答し、ユーザ端末30の現在位置又はユーザによる地図上の指定位置に応じてデータベースの店舗40に関するレコードを検索することにより、ユーザ端末30に空き情報を送信する店舗群を特定し、当該店舗群に含まれる各店舗の空き情報を取得する。ここで、空席管理サーバ10は、各店舗の空き情報を、空き情報を含む店舗情報(施設情報)に応じて、入力端末20から送信された空き情報とするか、ユーザ端末30から送信された空き情報とするかを決定する。空席管理サーバ10は、取得した空き情報を、照会に対するレスポンスとしてユーザ端末30へ返信する。ユーザ端末30は、空席管理サーバ10から受信した空き情報を地図上に表示(例えば、ピン表示)する。
【0015】
<空席管理サーバ10の構成例>
図2Aは、空席管理サーバ10のハードウェア構成図である。空席管理サーバ10は、CPU(Central Processing Unit)11(情報処理装置)、ROM(Read Only Memory)12、RAM(Random Access Memory)13、記憶装置14及び通信装置15を備える。CPU11は、後述するプログラムを実行することにより、空席管理サーバ10が提供する機能を実現する。ROM12及びRAM13は、CPU11が用いるデータを保持する。記憶装置14は、後述するプログラム及びデータベースを格納する。通信装置15は、ネットワーク50を介して入力端末20及びユーザ端末30と通信する。
【0016】
図2Bは、空席管理サーバ10の機能ブロック図である。空席管理サーバ10は、CPU11が実行するソフトウェアモジュール(各種プログラムがCPU11の内部メモリに展開されて構成される機能)として、受信部111(取得手段)、更新部112(管理手段)、判定部113(決定手段)及び出力部114(送信手段)を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはCPU11であるため、CPU11を動作主体とすることもできる。
【0017】
記憶装置14は、記憶部(記憶手段)としてのデータベース141を格納している。データベース141は、事前に登録された店舗情報を含む店舗情報データベース142と、入力端末20から送信された店舗40の空き情報(第1の空き情報)を含む空き情報データベース143と、ユーザ端末30から送信された店舗40の空き情報(以下、「ユーザ投稿」という場合がある)を含むユーザ投稿データベース144とを管理する。データベース141の構成については後述する。受信部111は、通信装置15を介して、店舗40の空き状況を示すデータを入力端末20及びユーザ端末30から受信する。また、受信部111は、通信装置15を介して、ユーザ端末30からの空き情報の検索リクエストを受信する。更新部112は、受信部111が受信した空き状況を示すデータに含まれる店舗ID(識別情報)に基づいて店舗を特定し、データベース141における空き情報を更新する。判定部113は、ユーザ端末30から、店舗の空き情報の検索リクエストと、現在の位置情報(基準位置)とを受信すると、位置情報に応じて、ユーザ端末30に空き情報を送信すべき店舗群を特定し、空き情報データベース143に格納された空き情報(第1の空き情報)、又は、ユーザ投稿データベース144に格納されたユーザ投稿による空き情報(第2の空き情報)のいずれをユーザ端末30に配信するかを決定する。
【0018】
検索リクエストとしては、ユーザ端末30の現在位置に基づくリクエストの他、特定の指定場所(例えば、ユーザは東京駅周辺にいるが、渋谷駅周辺)にある店舗の検索リクエスト、特定の種類(例えば、和食やフランス料理などの料理ジャンル、価格帯)を指定した検索リクエスト、特定の店舗を指定した検索リクエスト(この場合、ユーザは、特定の店舗の空き情報が知りたいケース)などの形態とすることもできる。
【0019】
出力部114は、通信装置15を介して、判定部113で特定された店舗群の各店舗の空き情報をユーザ端末30に送信する。空き情報を受信したユーザ端末30は、表示用UIを構築し、そこに当該空き情報のステータスを表示する。
【0020】
図3Aは、データベース141に格納されている店舗情報データベース142を示す図である。店舗情報データベース142は、ユーザが店舗を検索するときに用いる属性情報を含む店舗情報を管理するデータテーブルであり、例えば、店舗ID1
421、店舗の名称1422、ジャンル1423(属性情報)、店舗紹介1424、住所1425、緯度経度1426、電話番号1427、営業時間1428及びユーザ投稿の公開可否フラグ1429(上書き可否情報)を構成項目として有している。店舗情報データベース142の1つのレコードは、1つの店舗の店舗情報を管理する。入力端末20を保有する店舗40の店舗情報は、例えば、入力端末20に入力された情報を基に店舗情報データベース142に登録することもできるし、空席管理システム1のサービスの提供者が、電話帳や地図情報などに記載の情報に基づいて予め登録することもできる。
【0021】
店舗ID1421は、データベース141内で各店舗を識別するためのIDである。緯度経度1426は、店舗の位置を緯度経度によって示すデータであり、同じ施設の同じフロアであっても、店舗の位置が異なる場合は異なる緯度経度の値が登録されている場合もある。ユーザ投稿の公開可否フラグ1429は、あるユーザ端末30から店舗40の空き情報が空席管理サーバ10に送信されている場合に、そのユーザ端末30からの空き情報を、他のユーザ端末30に公開するか否かを示すデータである。すなわち、公開可否フラグ1429は、入力端末20から送信された第1の空き情報がデフォルトの配信すべき空き情報のステータスとなっているのに対し、この配信すべき空き情報のステータスを、ユーザ端末30からの投稿(第2の空き情報)によって上書き可能であるか否かを示すデータである。
図3Aにおいては、公開可否フラグ1429は、「可」又は「不可」で示されている。別の形態では、公開可否フラグ1429は、公開可の場合に「0」、公開不可の場合に「1」のように数字で示されていてもよい。
【0022】
図3Bは、データベース141に格納されている空き情報データベース143を示す図である。空き情報データベース143は、店舗ごとの最新の空き状況を管理するデータテーブルであり、例えば、店舗ID1431、第1の空き情報1432、入力端末ID1433及び受信日時1434を構成項目として有している。空き情報データベース143の1つのレコードは、1つの店舗の空き状況を管理する。
【0023】
店舗ID1431は、店舗情報データベース142の店舗ID1421と対応するデータであり、ある店舗の店舗ID1421と店舗ID1431とは同一である。第1の空き情報1432は、店舗40内の入力端末20から送信されてきた最新の空き状況を示すデータである。
図3Bの例においては、第1の空き情報1432は、「空あり」、「やや混雑」又は「満席」のうちいずれかにより示されている。別の形態として、第1の空き情報1432は、空席がある場合は「0」、混雑している場合は「1」、満席の場合は「2」のように数字で示されていてもよい。また、別の形態として、第1の空き情報1432は、空席の数又は空きテーブルの数を示す数値であってもよい。
【0024】
入力端末ID1433は、入力端末20の識別子であり、例えば入力端末20のMACアドレスを用いることができる。なお、入力端末ID1433は、店舗ID1431に対応する入力端末として事前に設定された識別情報であり、本実施形態においては第1の空き情報1432が更新されても入力端末ID1433は基本的には変わらない。受信日時1434は、空席管理サーバ10が入力端末20から第1の空き情報1432を受信した日時を示すデータである。別の形態では、受信日時の代わりに、入力端末20が空き状況を送信した送信日時としてもよい。
【0025】
図3Cは、データベース141に格納されているユーザ投稿データベース144を示す図である。ユーザ投稿データベース144は、ユーザ端末30から送信された店舗40ごとの空き状況を管理するデータテーブルであり、例えば、店舗ID1441、ユーザ投稿1442、ユーザ端末ID1443及び受信日時1444を構成項目として有している。ユーザ投稿データベース144の1つのレコードは、1つのユーザ投稿を管理する。
【0026】
店舗ID1441は、店舗情報データベース142の店舗ID1421と対応するデータであり、ある店舗の店舗ID1421と店舗ID1441とは同一である。ユーザ投稿1442は、店舗40を訪れた(あるいは、店舗40付近にいる)ユーザのユーザ端末30から送信されてきた空き状況を示すデータである。ユーザ端末ID1443は、ユーザ端末30の識別子であり、例えばユーザ端末30のMACアドレスを用いることができる。受信日時1444は、空席管理サーバ10がユーザ端末30からユーザ投稿1442を受信した日時を示すデータである。別の形態では、受信日時の代わりに、ユーザ端末30が空き状況を送信した送信日時としてもよい。
【0027】
データベース141は、例えばレコードの内容を記述したデータを記憶装置14内に格納することによって構成できる。なお、本実施形態では店舗情報データベース142、空き情報データベース143及びユーザ投稿データベース144はテーブル形式で表されているが、この形式に限らず、各データが紐付けされていればどのような形式で構築してもよい。したがって、単に、空席管理データあるいは空席管理情報と称することも可能である。
【0028】
<入力端末20の構成例>
図4Aは、入力端末20のハードウェア構成図である。入力端末20は、CPU21、表示装置22、入力装置23及び通信装置24を備える。CPU21は、入力端末20が備える各部を制御する。通信装置24は、ネットワーク50を介して空席管理サーバ10と通信し、空席管理サーバ10から、空き情報及び店舗情報を入力するためのGUI画面を受信する。表示装置22は、空席管理サーバ10から受信したGUI画面を表示する。入力装置23は、店員が入力端末20に対する操作指示を入力するために用いるインターフェースである。例えばタッチパネルなどによって、表示装置22及び入力装置23を一体的に構成することもできる。
【0029】
図4Bは、入力端末20の機能ブロック図である。入力端末20は、CPU21が実行するソフトウェアモジュール(各種プログラムがCPU21の内部メモリに展開されて構成される機能)として、記憶部211、通信制御部212、設定部213及び表示制御部214を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはCPU21であるため、CPU21を動作主体とすることもできる。
【0030】
記憶部211は、CPU21の内部メモリとして機能する。通信制御部212は、通信装置24を介して、空席管理サーバ10との通信を行う。具体的には、通信制御部212は、空席管理サーバ10からGUI画面を受信する。GUI画面上では、店舗名、所在地、電話番号、ユーザによる空き情報の公開を許可するか否かを入力する画面や、「空席」、「やや混雑」、「満席」などの空き情報を選択し入力する画面が表示される。なおここで入力できる空き情報として表示される選択肢は、店舗40の入力端末20から送信されうる空き情報と同じ空き情報とする。設定部213は、店舗40の店員が入力装置23及びGUI画面を介して入力した空き情報及び店舗情報(公開可否フラグを含む)を受け付ける。通信制御部212は、入力された空き情報及び店舗情報と、入力端末IDと、公開可否フラグとを、空席管理サーバ10に送信する。表示制御部214は、表示装置22の表示を制御する。具体的には、表示制御部214は、空席管理サーバ10から受信したGUI画面(店舗情報の設定画面及び空き状況の投稿画面)を表示装置22に表示する。
【0031】
<ユーザ端末30の構成例>
図5Aは、ユーザ端末30のハードウェア構成図である。ユーザ端末30は、CPU31(情報処理装置)、表示装置32、入力装置33及び通信装置34を備える。CPU31は、ユーザ端末30が備える各部を制御する。通信装置34は、ネットワーク50を介して空席管理サーバ10と通信し、店舗の空き情報の検索リクエストを送信して、空席管理サーバ10から空き情報を受信する。表示装置32は、空席管理サーバ10から受信した店舗の空き情報や、空き情報を入力するためのGUI画面(投稿画面)を画面表示する。入力装置33は、ユーザがユーザ端末30に対する操作指示を入力するために用いるインターフェースである。例えばタッチパネルなどによって、表示装置32及び入力装置33を一体的に構成することもできる。
【0032】
図5Bは、ユーザ端末30の機能ブロック図である。ユーザ端末30は、CPU31が実行するソフトウェアモジュール(各種プログラムがCPU31の内部メモリに展開されて構成される機能)として、記憶部311、通信制御部312、生成部313及び表示制御部314を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはCPU31であるため、CPU31を動作主体とすることもできる。
【0033】
記憶部311は、CPU31の内部メモリとして機能する。通信制御部312(取得手段)は、通信装置34を介して、空席管理サーバ10との通信を行う。具体的には、通信制御部312は、ユーザが入力装置33を介して空き情報の照会の指示を入力すると、空席管理サーバ10に検索リクエストを送信する。また、通信制御部312は、空席管理サーバ10から店舗情報及び空き情報を受信する。
【0034】
生成部313(地図データ読み込み部)は、ユーザ端末30の位置情報及びユーザによって指定された地図の拡大率に応じて、記憶部311から地図情報(地図データ)を読み込む。また、生成部313は、空席管理サーバ10から受信した空き情報に対応するテキストデータあるいはマークデータ(空席「0」に対応するテキスト/マーク、やや混雑「1」に対応するテキスト/マーク、満席「2」に対応するテキスト/マーク)を記憶部311から読み出し、地図上に重畳表示するためのUIデータ(表示用UIデータ:ピン表示など)を生成する。さらに、生成部313は、空席管理サーバ10から受信した店舗情報に基づき、空き状況の投稿画面を生成する。生成部313における空き情報の処理方法の詳細については後述する。
【0035】
表示制御部314(表示制御手段)は、表示装置32の表示を制御する。具体的には、表示制御部314は、生成部313が読み込んだ地図、並びに生成部313が生成したピン及び空き状況の投稿画面を表示装置32に表示する。通信制御部312は、空き状況の投稿画面を介してユーザが入力した店舗40の空き情報と、店舗IDと、ユーザ端末IDとを、空席管理サーバ10に送信する。
【0036】
<空席管理サーバ10の空き情報処理>
図6は、空席管理サーバ10が実行する空き情報の配信処理手順を示すフローチャートである。空席管理サーバ10は、
図6に示すフローチャートを実現するプログラムを実行する。
【0037】
(ステップS101) 判定部113は、受信部111がユーザ端末30から空き情報の検索リクエストを受信したか否かを判断する。空き情報の検索リクエストを受信した場合(Yes)、処理はステップS102に移行する。なお、検索リクエストには、ユーザ端末30の現在の位置情報(例えば、GPSから取得した緯度経度情報)が含まれている。
【0038】
(ステップS102) 判定部113は、検索リクエストに含まれている位置情報を取得し、RAM13又は記憶装置14に格納する。
【0039】
(ステップS103) 判定部113は、ユーザ端末30の位置情報からユーザ端末30の現在位置を特定し、店舗情報データベース142の緯度経度1426を参照して、上記位置情報に応じて、ユーザ端末30に空き情報を送信すべき店舗群を特定し、当該店舗群の情報をRAM13又は記憶装置14に一時的に格納する。具体的には、判定部113は、ユーザ端末30の現在位置から所定距離範囲(例えば、現在位置から半径5kmの範囲)内にある店舗群を特定(決定)する。
【0040】
(ステップS104) 判定部113は、店舗情報データベース142及び空き情報データベース143を参照して、特定された店舗群に含まれる各店舗の店舗情報及び空き情報を抽出し、RAM13又は記憶装置14に格納する。このとき、判定部113は、公開可否フラグ1429、受信日時1434及び受信日時1444を参照して、空き情報データベース143に格納された第1の空き情報1432、又は、ユーザ投稿データベース144に格納されたユーザ投稿1442による空き情報のいずれをユーザ端末30に配信するかを決定する。この配信すべき空き情報の決定方法については、後述する。
【0041】
(ステップS105) 出力部114は、通信装置15を介して、ステップS103で特定した店舗群の情報と、ステップS104で取得した各店舗の店舗情報及び空き情報を、リクエストを送信してきたユーザ端末30に送信する。
【0042】
なお、図示は省略しているが、空席管理サーバ10は、以上の空き情報の配信処理と並行して、空き情報データベース143及びユーザ投稿データベース144の更新処理を実行する。空き情報データベース143及びユーザ投稿データベース144の更新処理では、受信部111により、入力端末20及びユーザ端末30から、少なくとも店舗ID、空き状況を示すデータ及び端末IDを受信し、更新部112により、空き情報データベース143及びユーザ投稿データベース144を更新する。空き情報データベース143及びユーザ投稿データベース144の更新は、入力端末20又はユーザ端末30から空き状況を示すデータを受信するたびに実行する。
【0043】
<配信すべき空き情報の決定方法>
図7は、ステップS104における、空席管理サーバ10が実行する、配信すべき空き情報の決定方法のフローチャートである。
【0044】
(ステップS201) 判定部113は、ステップS103において特定された店舗群の中から、任意の1つの店舗を処理対象店舗として選択する。
【0045】
(ステップS202) 判定部113は、空き情報データベース143を参照して、処理対象店舗の入力端末20から送信された処理対象店舗の第1の空き情報を取得し、RAM13又は記憶装置14に格納する。
【0046】
(ステップS203) 判定部113は、ユーザ投稿データベース144を参照して、現在時刻から所定時間(例えば、30分)以内に更新されたユーザ投稿があるか否かを判断する。所定時間以内に更新されたユーザ投稿がある場合(Yes)、処理はステップS204に移行する。所定時間以内に更新されたユーザ投稿がない場合(No)、処理はステップS211に移行する。
【0047】
(ステップS204) 判定部113は、所定時間以内に更新されたユーザ投稿をすべて取得し、RAM13又は記憶装置14に格納する。
【0048】
(ステップS205) 判定部113は、ステップS204において取得したユーザ投稿のうち、最多の空き情報を第2の空き情報として設定し、RAM13又は記憶装置14に格納する。例えば、ステップS204において取得したユーザ投稿が5つあり、うち4つが「空きあり」、残りの1つが「やや混雑」である場合、第2の空き情報として「空きあり」が設定されることになる。また、判定部113は、最多の空き情報を示すユーザ投稿のうち、最新の(最も現在時刻に近い)受信日時を、第2の空き情報の受信日時として設定する。
【0049】
(ステップS206) 判定部113は、第1の空き情報と第2の空き情報とが同じであるか否かを判断する。第1の空き情報と第2の空き情報とが同じである場合(Yes)、処理はステップS211に移行する。ここで、第1の空き情報と第2の空き情報とが同じであり、第2の空き情報の受信日時が第1の空き情報の受信日時より新しい場合、更新部112は、空き情報データベース143の第1の空き情報の受信日時1434を第2の空き情報の受信日時と同じになるように更新してもよい。店舗40の店員が更新された日時に第1の空き情報を送信したわけではないが、第1の空き情報は更新された日時の時点でも有効(実際の店舗40内の空き状況と同じである)といえるので、第1の空き情報の受信日時をより現在時刻に近い日時にも送信されたものとみなすことができる。これにより、次回の決定フロー(
図7の一連の処理)におけるステップS207の判断の際に、より最新の第1の空き情報の受信日時を用いた判断ができる。第1の空き情報と第2の空き情報とが同じでない場合(No)、処理はステップS207に移行する。
【0050】
(ステップS207) 判定部113は、空き情報データベース143及びユーザ投稿データベース144を参照して、第1の空き情報の受信日時が、第2の空き情報の受信日時よりも後であるか否かを判断する。第1の空き情報の受信日時が、第2の空き情報よりも後である場合(Yes)、処理はステップS211に移行する。第1の空き情報の受信日時が、第2の空き情報よりも後でない場合(No)、処理はステップS208に移行する。
【0051】
(ステップS208) 判定部113は、店舗情報データベース142の公開可否フラグ1429を参照して、ユーザ投稿の公開が許可されているか否かを判断する。ユーザ投稿の公開が許可されている場合(Yes)、処理はステップS209に移行する。ユーザ投稿が公開不可の場合(No)、処理はステップS210に移行する。
【0052】
(ステップS209) 判定部113は、第1の空き情報と第2の空き情報とが異なり(ステップS206)、第2の空き情報(ユーザ投稿)の方が第1の空き情報よりも最新であり(ステップS207)、ユーザ投稿の公開が許可されている(ステップS208)場合、第2の空き情報を、照会リクエストを送信したユーザ端末30に配信すると決定する。換言すれば、配信すべき空き情報のステータスを、第2の空き情報で上書きする。
【0053】
(ステップS210) 判定部113は、ユーザ投稿が公開不可である場合、ステップS205において第2の空き情報として設定した空き情報を、出力部114を介して入力端末20に送信する。これにより、ユーザ投稿を店舗40の店員に通知(フィードバック)する。ユーザ投稿のフィードバックに際し、判定部113は、例えば、入力端末20に「ユーザから「空きあり」が空き情報として投稿されています。「空きあり」に更新しますか?」とプッシュ通知することができる。別の形態では、判定部113は、入力端末20に「ユーザから「空きあり」が空き情報として投稿されています」といったテキストを含むメールを送信することができる。別の形態では、店舗40の店員が、任意のタイミングで、第2の空き情報として設定された空き情報を閲覧できるようにしてもよい。
【0054】
(ステップS211) 判定部113は、所定時間以内のユーザ投稿がないか(ステップS203)、第1の空き情報と第2の空き情報とが同じであるか(ステップS206)、第1の空き情報の方が第2の空き情報(ユーザ投稿)よりも最新であるか(ステップS207)、又は、ユーザ投稿が公開不可である(ステップS208)場合、第1の空き情報を、照会リクエストを送信したユーザ端末30に配信すると決定する。すなわち、配信すべき空き情報のステータスを、デフォルトの第1の空き情報のままとする。
【0055】
(ステップS212) 判定部113は、ステップS103において特定された店舗群のうち、未処理の店舗があるか否かを判断する。このとき、判定部113は、ステップS201において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合(Yes)、処理はステップS201に戻り、ステップS201~S211が上記と同様に実行される。未処理の店舗がない場合(No)、配信すべき空き情報の決定処理は終了し、上述のステップS105に移行する。
【0056】
店舗40からの空き情報の送信が漏れていたり、誤っていたりすることで、正確な空き情報がユーザに配信されない場合がある。これに対し、本実施形態のように、店舗40がユーザ投稿を公開可能な店舗である(公開可否フラグを「可」にしている)場合には、ユーザ投稿を用いて空き情報を配信することで、より正確な空き情報を配信することができる。つまり、第1のユーザ端末から送信された第1の店舗の空き情報が、第2のユーザ端末上に、第1の店舗の空き情報として表示されることがある。その一方で、第2の店舗の空き情報に関しては、第1のユーザ端末から空き情報が送信されても、第2のユーザ端末には第2の空き情報として表示されないことがある。ユーザ投稿を公開できない場合には、ユーザ投稿を店舗の入力端末20にフィードバックすることで、店舗40に空き情報の更新を促すことができる。
【0057】
以上のように、店舗40付近にいるユーザに空き情報を投稿してもらい、ユーザ端末30への配信又は入力端末20へのフィードバックに用いることで、ユーザからの情報を有効利用することができる。別の形態では、上述のステップS209の後にも、第2の空き情報を送信すると決定したことを示す通知を、出力部114を介して入力端末20に送信してもよい。
【0058】
別の形態では、判定部113は、ステップS204において取得したユーザ投稿の数や同じ空き情報のユーザ投稿の数が、所定数以上である場合に、ステップS205において最多のユーザ投稿の空き情報を第2の空き情報として設定するようにしてもよい。具体的には、判定部113は、ステップS204の後、所定時間以内にユーザ投稿が所定数(例えば10)以上ある場合にはステップS205の処理を実行することができる。別の形態では、判定部113は、ステップS205の処理において第2の空き情報として設定された空き情報を投稿したユーザ数が所定数以上ある場合にはステップS206に進み、所定数未満である場合には、ステップS211に進むようにすることができる。これにより、店舗40に関する空き情報として上書きされうる第2の空き情報を、より信頼度の高い情報で設定することができ、特定のユーザによるいたずらで本来の空き状況とは異なる空き情報が配信されてしまうことを防ぐことができる。
【0059】
<ユーザ端末30の空き情報表示処理>
図8は、ユーザ端末30における空き情報の表示処理手順を示すフローチャートである。ユーザ端末30は、
図8に示すフローチャートを実現するプログラムを実行する。
【0060】
(ステップS301) 生成部313は、通信制御部312を介して、ユーザ端末30の現在位置を示す位置情報(GPSデータ)を取得する。生成部313は、取得した位置情報を記憶部311に格納する。
【0061】
(ステップS302) 生成部313は、記憶部311からユーザ端末30の位置情報を取得し、当該位置情報を含む検索リクエストを生成し、通信制御部312を介して検索リクエストを空席管理サーバ10に送信する。空席管理サーバ10は、検索リクエストを受信すると、
図6及び
図7に示した上述の処理を実行する。
【0062】
(ステップS303) 生成部313は、ステップS301で取得した位置情報及びユーザによって指定された地図の拡大率に応じて、記憶部311から地図情報(地図データ)を読み込み、表示制御部314を介して表示装置32の表示画面上に所望の地図を表示する。なお、地図の拡大率は事前に設定された固定値としてもよい。
【0063】
(ステップS304) 生成部313は、通信制御部312を介して、空席管理サーバ10から、ユーザ端末30の位置情報に応じた店舗群の店舗情報及び空き情報を取得して、記憶部311に格納する。
【0064】
(ステップS305) 生成部313は、空席管理サーバ10から受信した店舗群のうち、任意の1つの店舗を処理対象店舗として選択する。ここで選択される処理対象店舗は、例えば、緯度経度がユーザ端末30の位置情報に最も近い店舗とすることができる。別の形態では、店舗ID1421が最も若い店舗を処理対象店舗として選択することもできる。
【0065】
(ステップS3
06) 生成部313は、記憶部311に格納されている処理対象店舗の空き情報を参照し、表示ピンのオブジェクトデータの中から空き情報に対応するものを選択して、空き情報に基づいたピンデータを生成する。表示ピンのオブジェクトデータは、空き情報に応じて色分けすることができる。例えば、表示ピンのオブジェクトデータは、空き情報が「空きあり」である場合は青色、「やや混雑」である場合は黄色、「満席」である場合は赤色とすることができる。また、表示ピンのオブジェクトデータに、空き情報に対応するテキストデータを重畳することにより各店舗のピンデータが生成される。すなわち、地図に表示されるピンには、1つの店舗の空き情報を示すテキストが含まれる。例えば、処理対象店舗の空き情報が「空きあり」であった場合は、ピンの中に「空きあり」というテキストを表示する。空き情報が「満席」であった場合は、「満席」というテキストを表示する。ピンデータに含まれるテキストは、例えば黒文字又は白文字とすることができる。
【0066】
(ステップS307) 生成部313は、処理対象店舗の緯度経度にしたがって、ステップS306で生成したピンデータを地図上に配置する。なお、このとき、生成部313は、空き情報が「やや混雑」又は「満席」の店舗についてはピンデータを削除して配置せず、空き情報が「空き」を示す店舗のピンデータのみを配置するようにしてもよい。
【0067】
(ステップS308) 生成部313は、空席管理サーバ10から受信した店舗群のうち、未処理の店舗があるか否かを判断する。このとき、生成部313は、ステップS305において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合(Yes)、処理はステップS305に戻り、ステップS305~S307が上記と同様に実行される。未処理の店舗がない場合(No)、処理はステップS309に移行する。
【0068】
(ステップS309) 表示制御部314は、ステップS307において生成部313により地図上に配置されたピンデータにしたがって、表示用ピンを表示装置32の表示画面に表示する。
【0069】
一旦空き情報を照会したユーザ端末30は、所定時間ごと(例えば、10秒ごと)に最新の空き情報を取得するためのリクエスト(再リクエスト)を空席管理サーバ10に送信する。空席管理サーバ10は、当該再リクエストに応答して、最新の空き情報をデータベース141から取得し、ユーザ端末30に送信する。最新の空き情報を受信すると、ユーザ端末30は、最初のリクエストに対応して取得して地図上に表示した店舗群の空き情報を更新して表示画面上にピン表示する。
【0070】
以上、ユーザ端末30においてピンデータを生成することを説明したが、空席管理サーバ10側で、又は、表示用データを生成するための他の装置等において、ピンデータを生成してユーザ端末30に送信し、ユーザ端末30は表示する処理のみを行うようにしてもよい。
【0071】
<地図上でのUI表示例> 第1の実施形態による、ユーザ端末30の表示装置32の表示画面に表示されるUI表示の例を説明する。
【0072】
図9は、第1の実施形態における地図上に表示されるUI表示(ピン表示)の例を示す図である。
図9に示す例において、ピンの色が空き情報に応じて色分けされており、ピンに空き情報を示すテキストが表示されている。ピンの色分けやテキストの色については、空き情報がいずれであるかをユーザが認識することができればよく、図示したものに限定されない。また、地図上には、ユーザの現在位置100が示されている。
【0073】
以上の通り、本実施形態において、店舗によって管理された店舗の空き情報に加えて、店舗の店員ではないユーザ(一般客)からも店舗の空き情報の投稿を受け付け、店舗の空き情報として利用する。例えば、第1のユーザが投稿した店舗Bの空き情報に関して、店舗Bがユーザ投稿の公開を許可しており、所定の条件を満たす場合には、第1のユーザとは異なる第2のユーザに対して、第1のユーザが投稿した店舗Bの空き情報を提供することができる。これにより、店舗による空き情報の更新が漏れていたり、店舗が入力した空き情報が誤っていたりしても、ユーザは、より正確な空き情報を参考にすることができる。
【0074】
<ユーザ端末30の投稿画面の表示処理>
図10は、ユーザ端末30における空き情報の投稿画面の表示手順を示すフローチャートである。ユーザ端末30は、
図10に示すフローチャートを実現するプログラムを実行する。
【0075】
(ステップS401) 生成部313は、ユーザによる地図上のピン(店舗)の選択を受け付ける。
【0076】
(ステップS402) 生成部313は、記憶部311からユーザ端末30の位置情報を取得する。
【0077】
(ステップS403) 生成部313は、記憶部311に格納された店舗情報のうち営業時間を参照し、現在時刻が、選択されたピンに対応する店舗40の営業時間内であるか否かを判断する。営業時間内である場合(Yes)、処理はステップS404に移行する。営業時間外である場合(No)、処理はステップS407に移行する。なお、店舗40が24時間営業の場合は、本ステップS403を省略してステップS407に移行するようにしてもよい。
【0078】
(ステップS404) 生成部313は、記憶部311に格納された店舗情報のうち緯度経度を参照し、ステップS402で取得したユーザ端末30の位置情報と、店舗40との距離を算出する。
【0079】
(ステップS405) 生成部313は、ユーザ端末30と店舗40との距離が、所定の距離以下であるか否かを判断する。この所定の距離は、例えば、ユーザが店舗40にいてもGPSのずれにより生じる範囲として設定することができる。GPSのずれが最大300m発生し得る場合は、所定の距離は、店舗40の広さも加味して、例えば350mに設定することができる。所定の距離以下である場合(Yes)、処理はステップS406に移行する。所定の距離より大きい場合(No)、処理はステップS407に移行する。
【0080】
(ステップS406) 生成部313は、ユーザが空き情報を投稿するための各ボタンがアクティブとなっている投稿画面を生成する。ここで、現在時刻が営業時間内であり、ユーザ端末30と店舗40との距離が近い(所定の距離以下)である場合は、ユーザが店舗40内にいる可能性が高いとみなすことができる。このように、所定の条件を満たす場合にのみユーザが空き情報を投稿できるようにすることで、高い信頼性の空き情報の投稿を受け付けることができる。
【0081】
(ステップS407) ステップS403において営業時間外であると判断された場合、又は、ステップS405において所定の距離より大きいと判断された場合、生成部313は、各ボタンが非アクティブとなっている投稿画面を生成する。このように、所定の条件が満たされない場合には、空き情報の投稿が受け付けられない。ただし、投稿画面を生成しないのではなく、各ボタンが非アクティブとなっている投稿画面を生成することで、条件を満たせば空き情報を投稿できる場合があることを、ユーザに暗に示すことができる。
【0082】
(ステップS408) 表示制御部314は、ステップS406又はステップS407で生成された投稿画面を表示装置32の表示画面に表示する。
【0083】
以上の通り、ユーザ端末30から店舗の空き情報を送信する場合、店舗40との距離が近い場合にのみ受け付ける。これにより、ユーザ端末30からいたずら目的や不正確な空き情報が送信されてしまうことを抑制する。なお、店舗40の入力端末20から店舗40の空き情報が送信される場合は、ステップS405のように距離が近いか否かを判定することなく、常に空き情報の投稿を受け付ける。店舗40の入力端末20の場合は、事前に店舗40自身からの空き情報であることがわかるように店舗40に対応する入力端末ID1433が登録されているため、距離に応じた判定をすることなく信頼性の高い空き情報であるとみなせる。さらには、入力端末20自体が店舗40内にない場合でも、店舗40を運営する管理者が店舗40内で勤務する店員からの連絡を受けて空き情報を送信する場合もあり、距離に関わらず店舗40の空き情報としてみなすことができる。
【0084】
<投稿画面の表示例>
図11は、ユーザ端末30の表示装置32の表示画面に表示される投稿画面60の一例を示す図である。
図11においては、ユーザが店舗B(キッチンB)のピンを選択した場合に表示される画面を示している。投稿画面60では、ユーザが店舗Bの空き状況を選択するためのボタン61~63(「空きあり」ボタン61、「やや混雑」ボタン62及び「満席」ボタン63)と、選択した空き状況を空席管理サーバ10に送信するための投稿ボタン64とが表示されている。ユーザがボタン61~63のいずれかを選択して、投稿ボタン64をタップすると、選択された空き状況と、店舗Bの店舗IDと、ユーザ情報とが、空席管理サーバ10に送信される。そして、空席管理サーバ10は、ユーザ端末30から受信した情報にしたがって、ユーザ投稿データベース144を更新する(ユーザ投稿1442、ユーザ端末ID1443及び受信日時1444を含む新たなレコードを作成する)。
【0085】
<第1の実施形態のまとめ> 第1の実施形態に係る空席管理システム1において、ユーザ端末30から空き情報の検索リクエストを空席管理サーバ10に送信すると、空席管理サーバ10は、検索リクエストに応答してユーザ端末30の位置に基づいて店舗群(ユーザが入力した検索条件に合致する店舗の集合)を特定し、それらの空き情報を店舗情報と共にユーザ端末30に送信する。このとき、空席管理サーバ10は、ユーザ投稿の公開可否フラグ(施設情報)に応じて、ユーザ投稿を配信するか、入力端末20に送信するかを決定する。具体的には、ユーザ投稿の公開が許可されている場合、所定時間以内に投稿されたユーザ投稿のうち最も多いものを店舗の空き情報として、ユーザ端末30に送信する。これにより、店舗40の入力端末20から最後に送信された第1の空き情報が現状とは異なっていたとしても、正確な空き情報を配信することができる。また、ユーザ投稿の公開が許可されていない場合は、ユーザ投稿を入力端末20に送信することで、店舗40の店員に空き情報の更新を促すことができるため、結果として、リアルタイムで正確な空き情報の配信につながる。
【0086】
<第1の実施形態の変形例> 第1の実施形態では、店舗40の店員が店内の空き状況を目視で確認して、入力端末20に空き情報を入力することで、空席管理サーバ10に第1の空き情報を送信することとしたが、入力端末20は、カメラや人感センサなどを用いて空き状況を自動で検出する装置であってもよい。例えば、店舗内を撮像可能な位置に設置されたカメラで店内を撮影し、カメラに接続された情報処理装置で撮像画像を解析し、店舗40の空き状況を判定し、空席管理サーバ10に店内の空き情報を送信する。
【0087】
第1の実施形態では、空席管理サーバ10が、事前に店舗40から設定された公開可否フラグに基づいて、ユーザ端末30に配信すべき空き情報を決定することを説明したが、この方法に限らない。例えば、ユーザ端末30に配信すべき空き情報は、店舗の入力端末の種別に応じて決定してもよい。この場合、例えば、入力端末20が、店員がGUI画面を介して空き状況を入力するスマートフォンなどのコンピュータデバイスである場合、若しくは、入力端末20が、空き状況に対応するボタン有し、店員がボタンを押下することにより空き状況を送信する端末である場合には、第2の空き情報による上書きを実行する。一方、入力端末20が、カメラ(スマートフォンなどのコンピュータデバイスに搭載されたカメラを含む)又は人感センサなどの、空き状況を自動で検出する装置である場合には、第2の空き情報を店舗40の空き情報としてはユーザ端末30には配信(公開)せずに、店舗40のみにフィードバックする。これは、空き状況を自
動で検出する装置の場合は、空き状況の入力忘れがないため、より信頼性の高い空き状況を入力できるためである。ただし、自動で検出した空き状況が実際の空き状況とズレが生じている場合もあるため、店舗40にはフィードバックすることで、自動で空き状況を検出する入力端末20の調整を促すことができる。
【0088】
別の形態では、公開可否フラグの代わりに、店舗(施設)のジャンルに応じて、第2の空き情報を配信するか、店舗に通知するかを判断するようにしてもよい。この場合、例えば、飲食店はユーザ投稿の公開を許可するが、避難所や投票所などの公的施設はユーザ投稿を公開しないようにすることができる。
【0089】
第1の実施形態では、店舗40が公開可否フラグを設定することを説明した。公開可否フラグの代わりに、店舗40が上書き可否フラグを設定するようにしてもよい。上書き可否フラグは、空き情報データベース143の第1の空き情報1432を、ユーザ投稿データベース144のユーザ投稿1442で上書きすることを許可するか否かを示すデータである。この場合、上述のステップS208において、空席管理サーバ10の判定部113は、第1の空き情報を第2の空き情報で上書き可能であるか否かを判断する。上書き可能である場合、ステップS209において、判定部113は、第2の空き情報を配信すべき空き情報と決定するとともに、更新部112は、空き情報データベース143の第1の空き情報1432を、第2の空き情報に更新する。一方、上書き不可である場合は、判定部113は、上述のステップS210及びS211を実行する。
【0090】
空席管理サーバ10がユーザ端末30からの検索リクエストに対する応答として、店舗群の店舗情報と空き情報を送信する際(ステップS105)、空席管理サーバ10は、現在時刻が各店舗の営業時間内であるかを判断して、営業時間内の店舗の店舗情報と空き情報のみをユーザ端末30に送信するようにしてもよい。この場合、ユーザ端末30は、上述のステップS403における営業時間内であるか否かの判断を行わなくてもよい。
【0091】
また、空席管理サーバ10はユーザ端末30からユーザ投稿を受信すると、ユーザ投稿データベース144のレコードを追加して、ステップS203~S204において受信日時が所定時間以内のユーザ投稿を抽出するようにした。しかしながら例えば、空席管理サーバ10は、定期的にユーザ投稿データベース144を監視し、受信日時から所定時間を超えたユーザ投稿をキャンセルするようにしてもよい。この場合、現在時刻から所定時間を超えた古いユーザ投稿は存在しなくなるので、空席管理サーバ10が、ユーザ投稿の受信日時が所定時間以内のものがあるか否かを判定するステップ(S203)は不要となる。
【0092】
また、店舗40の入力端末20について、空席管理サーバ10は入力端末ID1433を事前に店舗40の入力端末20として設定しておくこととし、第1の空き情報1432と連動して入力端末ID1433も更新されることはないとした。例えば、店舗の店員がGUI画面を介して空き情報を入力する前に、店舗40のアカウント情報を用いたログインをした場合に限り、入力端末20から空き情報を送信できるようにしてもよい。この場合、空席管理サーバ10は、店舗40に対応するアカウント情報(例えば、メールアドレスとパスワードなど)を管理し、入力端末ID1433を事前に設定する必要はない。この場合は、店舗40に対応するアカウントから送信された空き情報を第1の空き情報として利用することになる。また、複数の入力端末20を用いて空き情報を送信した場合には、店舗40に対応する入力端末ID1433がその都度更新されることになる。
【0093】
空席管理サーバ10が入力端末20に提供するGUI画面と、ユーザ端末30に提供する投稿画面は異なる画像であり、GUI画面に対する操作により送信された空き情報と、投稿画面に対する操作により送信された空き情報それぞれを識別可能なように、空席管理サーバ10に送信すればよい。この場合、例えば店員自身が個人利用を目的として保有する端末を、入力端末20とユーザ端末30それぞれとして併用することも可能である。同じ端末から送信された空き情報でも、店舗40からの空き情報を受け付けるGUI画面を介して送信された場合には、空席管理サーバ10は、第1の空き情報として受け付け、ユーザによる空き情報の投稿のための投稿画面を介して送信された場合には、空席管理サーバ10は、ユーザ投稿として受け付ける。
【0094】
[第2の実施形態] 上述の第1の実施形態では、公開可否フラグに基づいて、配信すべき空き情報を入力端末20からの第1の空き情報とするか、ユーザ投稿とするかを決定することを説明した。しかしながら、「やや混雑」していると判断する程度は、人(ユーザ)によって異なるため、「やや混雑」のユーザ投稿を配信せずに、店舗が送信した第1の空き情報を優先して配信するようにしてもよい。このように、第1の空き情報と第2の空き情報とが何であるかによって、優先して配信する空き情報を決定することができる。そこで、第2の実施形態では、第1の空き情報と第2の空き情報との組み合わせに基づいて、配信すべき空き情報を決定する技術を提案する。
【0095】
<配信すべき空き情報の決定方法>
図12は、空席管理サーバ10が実行する、第2の実施形態における配信すべき空き情報の決定方法のフローチャートである。ステップS201~S207については第1の実施形態と同じであるため、説明を省略する。
【0096】
(ステップS501) ステップS207の後、判定部113は、第1の空き情報と第2の空き情報との組み合わせに基づいて、配信すべき空き情報を決定する。以下の表1は、第1の空き情報と第2の空き情報との組み合わせと、第1の空き情報と第2の空き情報のいずれを配信するかを示す。データベース141には予め以下の表1が格納されており、判定部113は、ステップS501において表1を参照して、配信すべき空き情報を決定する。
【0097】
【0098】
表1に示すように、第1の空き情報が「やや混雑」であり、第2の空き情報が「やや混雑」とは異なっている場合、第1の空き情報を配信する。第1の空き情報が「満席」であり第2の空き情報が「やや混雑」である場合は、空席があっても予約席や店舗の事情で使用しない席である可能性があるため、第1の空き情報を配信する。また、第2の空き情報が、第1の空き情報と2段階異なっている場合(第1の空き情報が「空きあり」に対して、第2の空き情報が「満席」である場合、又は、第1の空き情報が「満席」に対して、第2の空き情報が「空きあり」である場合)は、第2の空き情報を配信する。このように、実際の空き状況と、店舗からの第1の空き情報とが異なっている可能性が高い場合に、第2の空き情報を配信するようにすることで、正確な空き情報をユーザに提供することができる。
【0099】
なお、別の形態では、判定部113は、第1の実施形態と同様に公開可否フラグによりユーザ投稿の公開可否を判断して、ユーザ投稿の公開を許可している店舗の空き情報についてのみ、第1の空き情報と第2の空き情報との組み合わせ(表1)に基づいて、配信すべき空き情報を決定するようにしてもよい。
【0100】
(ステップS502) 判定部113は、ステップS501で決定した空き情報を、出力部114を介して入力端末20に通知する。例えば、第2の空き情報を配信すると決定された場合には、その旨をテキスト表示したり、第1の空き情報を第2の空き情報と同じに変更するよう促すテキストを表示したりすることができる。
【0101】
<第2の実施形態のまとめ> 第2の実施形態においては、空席管理サーバ10は、第1の空き情報と第2の空き情報(施設情報)に応じて、ユーザ投稿を配信するか、第1の空き情報を配信するかを決定する。具体的には、第1の空き情報と第2の空き情報とが異なっており、第2の空き情報が第1の空き情報よりも最新である場合に、第1の空き情報と第2の空き情報との組み合わせに基づいて、配信すべき空き情報をユーザ投稿(第2の空き情報)とするか、入力端末20からの第1の空き情報とするかを決定する。これにより、空き状況の判断は人によって異なることもあるが、ユーザ投稿の方が第1の空き情報よりもより正確な空き状況を反映していると思われる場合に、当該ユーザ投稿を配信することができる。また、例えば、店舗40を訪れているユーザにとっては空き状況が「やや混雑」に見えても、空いている席が予約席であったり、店舗40の外で行列ができていたりした場合に、店舗40の店員は空き情報を「満席」としておきたいことがある。このような場合には、店舗40からの第1の空き情報を優先することで、店舗40の意図を反映した正確な空き情報を配信することができる。
【0102】
[第3の実施形態] 第1の実施形態においては、日時にかかわらず、所定の条件を満たす場合は、第1のユーザ端末30から送信されたユーザ投稿(第2の空き情報)を、第2のユーザ端末30に配信することを説明した。しかしながら、店舗40によっては、必ず混雑する日時には空き情報を「やや混雑」又は「満席」としておき、ユーザ投稿によって「空きあり」の空き情報が配信されないようにしたい場合がある。そこで、第3の実施形態では、配信される空き情報を固定する日時を設定でき、空き情報を固定する日時を参照してユーザ投稿の配信をするか否かを判定する技術を提案する。
【0103】
<入力端末の画面表示例>
図13は、入力端末20の表示装置22の表示画面に表示される固定情報設定画面80の一例を示す図である。固定情報設定画面70は、空き情報を固定にする曜日及び時間帯、並びに固定にする空き情報を設定するための選択箇所と、送信ボタン71とを有している。店員が固定情報(上書き可否情報)を入力後、送信ボタン71を押すことにより、固定情報が通信装置24を介して空席管理サーバ10に送信される。
図13の固定情報設定画面70においては、曜日を選択できるように構成されているが、別の形態では、カレンダー表示から日付を選択できるようにしてもよい。また、
図13の固定情報設定画面70においては、固定時間帯を1つのみ選択できるように構成されているが、別の形態では、複数の固定時間帯を設定できるようにしてもよい。この場合、複数の固定時間帯のそれぞれについて、固定空き情報を設定できるようにする。
【0104】
<データベースの構成例>
図14は、第3の実施形態に係る店舗情報データベース242を示す図である。
図14に示すように、店舗情報データベース242は、固定曜日2421、固定時間帯2422及び固定空き情報2423をさらに構成項目として有している点で、第1の実施形態の店舗情報データベース142と異なっている。固定曜日2421、固定時間帯2422及び固定空き情報2423は、固定情報設定画面70に入力された固定情報に対応する。
【0105】
<配信すべき空き情報の決定方法>
図15は、第3の実施形態における配信すべき空き情報の決定方法のフローチャートである。
【0106】
(ステップS601) 判定部113は、第1の実施形態と同様にステップS201を実施した後、店舗情報データベース242を参照して、処理対象店舗の固定空き情報2423が設定されているか否かを判断する。固定空き情報2423が設定されている場合(Yes)、処理はステップS602に移行する。固定空き情報2423が設定されていない場合(No)、第1の実施形態と同様に、ステップS202~S212が実行される。
【0107】
(ステップS602) 判定部113は、当日が固定曜日2421であり、かつ現在時刻が固定時間帯2422内にあるか否かを判断する。固定曜日2421であり、かつ現在時刻が固定時間帯2422内である場合(Yes)、処理はステップS603に移行する。固定曜日2421でないか、又は現在時刻が固定時間帯2422内でない場合(No)、第1の実施形
態と同様に、ステップS202~S212が実行される。
【0108】
ただし、現在時刻が固定時間帯2422の後であり、配信すべき空き情報のステータスが固定空き情報2423のままである場合は、更新部112により、空き情報データベース143の第1の空き情報1432の受信日時1434を固定時間帯の終了時刻として、固定空き情報2423を第1の空き情報1432として更新する。
【0109】
また、固定時間帯2422の後、空き情報のステータスが固定空き情報2423のままであり、第2の空き情報が所定の条件を満たす場合、第1の実施形態と同様に、公開可否フラグや店舗40のジャンルといった店舗情報に応じて、固定空き情報2423が第2の空き情報で上書きされうる。別の形態では、固定時間帯2422の後、空き情報のステータスが固定空き情報2423のままであり、第2の空き情報が所定の条件を満たす場合、第2の実施形態と同様に、固定空き情報2423と第2の空き情報との組み合わせに応じて、固定空き情報2423が第2の空き情報で上書きされうる。
【0110】
(ステップS603) 判定部113は、固定空き情報2423を配信すべき空き情報として決定する。その後、処理はステップS212に移行する。すなわち、固定空き情報2423を配信する際は、店舗40の入力端末20に、空き情報の更新を促す通知は送信されない。
【0111】
<第3の実施形態のまとめ> 以上のように、第3の実施形態においては、空席管理サーバ10は、空き情報が固定された日時に関する固定情報(施設情報)に応じて、ユーザ投稿(第2の空き情報)を配信するか、入力端末20に送信するかを決定する。具体的には、現在時刻において空き情報が固定されている場合には、配信すべき空き情報を固定空き情報とする。一方、現在時刻が、空き情報が固定されていない日時である場合は、第1の実施形態と同様に、所定の条件を満たす場合に配信すべき空き情報をユーザ投稿(第2の空き情報)とする。このように、空き情報が固定されている場合、店舗40の入力端末20がどのような空き情報を空席管理サーバ10に送信しているか、入力端末20がどのような種類の装置であるか(店舗が空き状況を入力する装置か、空き状況を自動で検出する装置か)によらず、固定空き情報を優先して配信する。これにより、店舗を訪れたユーザから見た空き状況が固定空き情報と異なっていたとしても、ユーザ投稿は配信されず、店舗の意図が反映された空き情報を配信することができる。
【0112】
[変形例] 以上の実施形態では、飲食店の空き情報を例に説明したが、これに限らない。例えば、飲食店以外にも映画館やスポーツスタジアム、駐車場、バス停などの施設の空き情報にも、本実施形態の技術を適用できる。また、本実施形態の空席管理システム1は、席を提供されないが人の多さが変動するような施設における利用者の空き状況を管理してもよい。具体的には、例えばスーパーマーケット、薬局、スポーツジム、自治体若しくは銀行の窓口、温泉施設などの空き状況を示す情報を管理してもよい。この場合、例えば、空席管理サーバ10は、「空いている」「やや混雑」「混雑」のいずれかによって表される混雑情報を管理し、配信する。
【0113】
また、ジャンルや施設によって空き情報として選択されうる選択肢が異なる場合がある。このような場合、ユーザ端末30に表示される店舗ごとの空き情報の投稿画面は、店舗40自身が配信可能な空き情報に応じて生成される方が望ましい。例えば、店舗40からの配信が「空きあり」、「やや混雑」、「満席」のうちいずれかである場合には、投稿画面にも「空きあり」、「やや混雑」、「満席」が選択肢として表示され、店舗40からの配信が「空いている」、「やや混雑」、「混雑」のうちいずれかである場合には、投稿画面にも「空いている」、「やや混雑」、「混雑」が選択肢として表示される。また、必ずしも店舗40から送信されうる空き情報の種類の全てを、ユーザ端末30の表示画面にも表示しなくてもよい。例えば、店舗40からの送信されうる空き情報の種類が「空きあり」、「やや混雑」、「満席」に加えて、「N分待ち」や「順番待ちN組」(Nには任意の数字を選択可能)などもあるとする。この場合、ユーザ端末30の空き情報の投稿画面に表示される選択肢は、店舗40からの送信されうる空き情報のうち「空きあり」、「やや混雑」、「満席」のみであってもよい。つまり、ユーザ端末30に表示される投稿画面上の空き情報の選択肢は、少なくとも店舗40からも送信されうる選択肢であることが望ましいが、全てではなくてもよい。
【0114】
以上の実施形態において、ユーザ端末30の位置を位置情報として取得し、ユーザ端末30の位置を基準として店舗群を特定する方法を説明したが、位置情報はこれに限らない。例えばユーザ端末30における表示装置32がタッチパネルディスプレイであり、入力部としても機能する場合に、表示装置32に表示された地図上の位置をユーザがタップすることにより、ユーザが位置情報を指定し、指定した位置情報(基準位置)を空席管理サーバ10に送信するようにしても良い。この場合、空席管理サーバ10は、指定された位置情報に応じて店舗群を特定する。
【0115】
以上の実施形態において、入力端末20としてコンピュータデバイスを用いる場合について説明したが、入力端末20としては、例えばカメラ又は人感センサなどの、店舗40の空き状況をリアルタイムに検出するセンサを用いることもできる。入力端末20がカメラである場合、カメラは、店舗40内や待機列にいる人を検出して、空き状況を判断し、空席管理サーバ10に送信するように構成される。別の形態では、カメラの映像データを用いて、空席管理サーバ10が空き状況を判断するようにしてもよい。入力端末20が人感センサである場合、人感センサは、例えば座席ごとに設置され、すべての人感センサの検出結果を空席管理サーバ10に送信するように構成される。
【0116】
以上の実施形態において、ユーザ端末30は周辺店舗の空き状況を画面表示する例を説明したが、これに代えて常に特定の店舗の空き状況のみを空席管理サーバ10へ照会するようにしてもよい。さらにユーザ端末30は、空き状況を照会する店舗の属性(例:ジャンル1423などの店舗のカテゴリ情報)を指定してもよい。この場合、出力部114は、その指定された属性に合致する店舗の空き情報のみをユーザ端末30に対して返信する。
【0117】
以上の実施形態において、ユーザ端末30は必ずしもユーザが携帯する端末でなくともよい。例えば特定場所に設置されているコンピュータなどの通信デバイスをユーザ端末30として用いてもよい。例えば人通りが多い場所に固定設置されているデジタルサイネージ端末をユーザ端末30として構成してもよい。この場合は必ずしもデジタルサイネージ端末の周辺店舗に関する空き情報を表示する必要はなく、端末設置者が所望する場所の店舗に関する空き情報を表示することもできる。
【0118】
以上の通り、本開示の技術は、上述の実施形態の1つ以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサがプログラムを読み出し作動させる処理によって実現することができる。また、1以上の機能を実現する回路によって実現しても良い。
【0119】
本開示は、上述した実施形態に限定されるものでなく、様々な変形例を含んでいる。例えば、上述した実施形態は、本開示を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備える必要はない。また、ある実施形態の一部を他の実施形態の構成に置き換えることができる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の実施形態の構成の一部を追加、削除又は置換することもできる。
【符号の説明】
【0120】
1…空席管理システム10…空席管理サーバ(情報処理装置)20…入力端末(施設端末)30…ユーザ端末40…店舗(施設)50…ネットワーク