JP7185337B2

JP7185337B2 - 情報処理装置、プログラム及び情報処理方法

Info

Publication number: JP7185337B2
Application number: JP2021043061A
Authority: JP
Inventors: 清志篠原
Original assignee: Vacan Inc
Current assignee: Vacan Inc
Priority date: 2021-03-17
Filing date: 2021-03-17
Publication date: 2022-12-07
Anticipated expiration: 2041-03-17
Also published as: JP2023022103A; JP2022142836A

Description

本開示は、情報処理装置、プログラム及び情報処理方法に関する。

店舗の空き情報をユーザがオンラインで確認できるようにするための技術は、例えば飲食店などの空き情報を提供するために用いられている。特許文献１には、「来店予約を行う前に、店舗の混雑状況を利用者に提供する」ことを課題として、「情報管理システムは、店舗に設置され店舗の混雑状況を示す混雑情報を送信する店舗端末４０と、店舗端末が設置された店舗に関する混雑情報を含んだ店舗データを管理するサーバ装置１０と、を有する。サーバ装置は、店舗端末から送信される混雑情報を受信し、店舗データに含まれる混雑情報のステータスを、受信した混雑情報のステータスに更新する。店舗を利用する利用者からの、店舗の混雑状況を確認したい旨の要求を受け付け、記憶された店舗データに基づき、店舗の混雑状況を示す画面データを生成し、利用者が所持するユーザ端末２０に送信する。サーバ装置は、送信した画面データに対する利用者の操作に応じて、店舗への来店予約を行う。」という技術を開示している（同文献の要約参照）。

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

しかしながら、上記特許文献１の技術においては、例えば空き情報の更新漏れがあった場合や、空き情報の入力ミスがあった場合などに、ユーザ端末に配信される空き情報が、現時点での店舗の実際の空き状況と異なってしまうことがある。

そこで、本開示は、正確性の高い空き情報を配信する技術を提供する。

上記課題を解決するために、本開示の情報処理装置は、施設の空き状況を示す空き情報を配信する情報処理装置であって、施設に関する施設情報を記憶する記憶手段と、第１のユーザ端末から送信された前記施設の空き情報を取得する取得手段と、前記施設情報に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を、第２のユーザ端末に送信するか、前記施設に対応する施設端末に送信するかを決定する決定手段と、前記決定手段による決定に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を前記第２のユーザ端末に送信する送信手段と、を備える。

本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではない。

本開示の技術によれば、正確性の高い空き情報を配信することができる。

第１の実施形態に係る空席管理システムの構成図である。空席管理サーバのハードウェア構成図である。空席管理サーバの機能ブロック図である。データベースに格納されているデータ例を示す図である。データベースに格納されているデータ例を示す図である。データベースに格納されているデータ例を示す図である。入力端末のハードウェア構成図である。入力端末の機能ブロック図である。ユーザ端末のハードウェア構成図である。ユーザ端末の機能ブロック図である。空席管理サーバにおける空き情報の配信処理手順を示すフローチャートである。空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。ユーザ端末における空き情報の表示処理手順を示すフローチャートである。第１の実施形態に係るユーザ端末の表示画面の例である。ユーザ端末における投稿画面の表示手順を示すフローチャートである。第１の実施形態に係る空き情報の投稿画面の一例を示す図である。第２の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。第３の実施形態に係る入力端末の固定情報設定画面の一例を示す図である。第３の実施形態に係るデータベースに格納されているデータ例を示す図である。第３の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。

以下、本開示の実施形態について、図面を参照して説明する。同一の構成については、同じ符号を付して説明する。尚、以下の実施形態は本開示の技術を限定するものではなく、また、実施形態で説明されている特徴の組み合わせの全てが上記課題の解決手段に必須のものとは限らない。

［第１の実施形態］
＜空席管理システム１の構成例＞
第１の実施形態では、席やテーブルが設置され飲食が提供される店舗に新たな利用客が利用可能な空席（又は空きテーブル）があるか否かを示す空き状況（例えば、空席、やや混雑、満席：「混雑状況」ということもでき、本実施形態では両者は同意である）を、ユーザ端末に配信する空席管理システムについて説明する。

図１は、第１の実施形態に係る空席管理システム１を示す構成図である。空席管理システム１は、店舗の空き状況を示す情報（空き情報）を管理するシステムであり、空席管理サーバ１０、入力端末２０及びユーザ端末３０を備える。入力端末２０は、例えば、店舗４０内で操作されるスマートフォン又はタブレットなどのコンピュータデバイスであり、店舗４０の店員が目視で確認した空き状況を示す空き情報を入力できるように構成されている。入力端末２０は、店舗４０に対応する端末として事前に設定されている。ユーザ端末３０は、例えば、スマートフォン又はタブレットなどのコンピュータデバイスであり、当該空席管理システム１が提供するサービスのユーザの端末である。ユーザ端末３０は、店舗４０の空き状況を示す空き情報を入力し空席管理サーバ１０に送信できるように構成されている。空席管理サーバ１０は、店舗４０外に設置されており、入力端末２０及びユーザ端末３０から受信する空き状況を示すデータを管理するサーバである。空席管理サーバ１０、入力端末２０及びユーザ端末３０は、例えばインターネットなどのネットワーク５０を介して相互接続されている。図１においては、入力端末２０を保有する店舗４０が１店舗のみ示されているが、店舗４０の数は複数であってもよい。ただし本実施形態では、いずれの店舗４０の空き情報も、「空きあり」、「やや混雑」、「満席」のいずれかが取りうる選択肢であるとする。

空席管理サーバ１０は、入力端末２０から受信した店舗４０の空き状況を示すデータと、ユーザ端末３０から受信した店舗４０の空き状況を示すデータと、をデータベースに格納する。空席管理サーバ１０は、入力端末２０から受け取ったデータにしたがってデータベースを更新することにより、店舗４０ごとの最新の空き状況をデータベース上で管理する。なお、ここで「最新」とは、入力端末２０による送信日時を基準とすることができる。また、空席管理サーバ１０は、ユーザ端末３０から受け取ったデータにしたがってデータベースを更新することにより、店舗４０ごとの空き状況をデータベース上で管理する。

いずれかの店舗４０を訪れようとしているユーザは、ユーザ端末３０を介して、店舗４０の空き情報を空席管理サーバ１０に対して照会することができる。空席管理サーバ１０はその照会に応答し、ユーザ端末３０の現在位置又はユーザによる地図上の指定位置に応じてデータベースの店舗４０に関するレコードを検索することにより、ユーザ端末３０に空き情報を送信する店舗群を特定し、当該店舗群に含まれる各店舗の空き情報を取得する。ここで、空席管理サーバ１０は、各店舗の空き情報を、空き情報を含む店舗情報（施設情報）に応じて、入力端末２０から送信された空き情報とするか、ユーザ端末３０から送信された空き情報とするかを決定する。空席管理サーバ１０は、取得した空き情報を、照会に対するレスポンスとしてユーザ端末３０へ返信する。ユーザ端末３０は、空席管理サーバ１０から受信した空き情報を地図上に表示（例えば、ピン表示）する。

＜空席管理サーバ１０の構成例＞
図２Ａは、空席管理サーバ１０のハードウェア構成図である。空席管理サーバ１０は、ＣＰＵ（Central Processing Unit）１１（情報処理装置）、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、記憶装置１４及び通信装置１５を備える。ＣＰＵ１１は、後述するプログラムを実行することにより、空席管理サーバ１０が提供する機能を実現する。ＲＯＭ１２及びＲＡＭ１３は、ＣＰＵ１１が用いるデータを保持する。記憶装置１４は、後述するプログラム及びデータベースを格納する。通信装置１５は、ネットワーク５０を介して入力端末２０及びユーザ端末３０と通信する。

図２Ｂは、空席管理サーバ１０の機能ブロック図である。空席管理サーバ１０は、ＣＰＵ１１が実行するソフトウェアモジュール（各種プログラムがＣＰＵ１１の内部メモリに展開されて構成される機能）として、受信部１１１（取得手段）、更新部１１２（管理手段）、判定部１１３（決定手段）及び出力部１１４（送信手段）を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはＣＰＵ１１であるため、ＣＰＵ１１を動作主体とすることもできる。

記憶装置１４は、記憶部（記憶手段）としてのデータベース１４１を格納している。データベース１４１は、事前に登録された店舗情報を含む店舗情報データベース１４２と、入力端末２０から送信された店舗４０の空き情報（第１の空き情報）を含む空き情報データベース１４３と、ユーザ端末３０から送信された店舗４０の空き情報（以下、「ユーザ投稿」という場合がある）を含むユーザ投稿データベース１４４とを管理する。データベース１４１の構成については後述する。受信部１１１は、通信装置１５を介して、店舗４０の空き状況を示すデータを入力端末２０及びユーザ端末３０から受信する。また、受信部１１１は、通信装置１５を介して、ユーザ端末３０からの空き情報の検索リクエストを受信する。更新部１１２は、受信部１１１が受信した空き状況を示すデータに含まれる店舗ＩＤ（識別情報）に基づいて店舗を特定し、データベース１４１における空き情報を更新する。判定部１１３は、ユーザ端末３０から、店舗の空き情報の検索リクエストと、現在の位置情報（基準位置）とを受信すると、位置情報に応じて、ユーザ端末３０に空き情報を送信すべき店舗群を特定し、空き情報データベース１４３に格納された空き情報（第１の空き情報）、又は、ユーザ投稿データベース１４４に格納されたユーザ投稿による空き情報（第２の空き情報）のいずれをユーザ端末３０に配信するかを決定する。

検索リクエストとしては、ユーザ端末３０の現在位置に基づくリクエストの他、特定の指定場所（例えば、ユーザは東京駅周辺にいるが、渋谷駅周辺）にある店舗の検索リクエスト、特定の種類（例えば、和食やフランス料理などの料理ジャンル、価格帯）を指定した検索リクエスト、特定の店舗を指定した検索リクエスト（この場合、ユーザは、特定の店舗の空き情報が知りたいケース）などの形態とすることもできる。

出力部１１４は、通信装置１５を介して、判定部１１３で特定された店舗群の各店舗の空き情報をユーザ端末３０に送信する。空き情報を受信したユーザ端末３０は、表示用ＵＩを構築し、そこに当該空き情報のステータスを表示する。

図３Ａは、データベース１４１に格納されている店舗情報データベース１４２を示す図である。店舗情報データベース１４２は、ユーザが店舗を検索するときに用いる属性情報を含む店舗情報を管理するデータテーブルであり、例えば、店舗ＩＤ１４２１、店舗の名称１４２２、ジャンル１４２３（属性情報）、店舗紹介１４２４、住所１４２５、緯度経度１４２６、電話番号１４２７、営業時間１４２８及びユーザ投稿の公開可否フラグ１４２９（上書き可否情報）を構成項目として有している。店舗情報データベース１４２の１つのレコードは、１つの店舗の店舗情報を管理する。入力端末２０を保有する店舗４０の店舗情報は、例えば、入力端末２０に入力された情報を基に店舗情報データベース１４２に登録することもできるし、空席管理システム１のサービスの提供者が、電話帳や地図情報などに記載の情報に基づいて予め登録することもできる。

店舗ＩＤ１４２１は、データベース１４１内で各店舗を識別するためのＩＤである。緯度経度１４２６は、店舗の位置を緯度経度によって示すデータであり、同じ施設の同じフロアであっても、店舗の位置が異なる場合は異なる緯度経度の値が登録されている場合もある。ユーザ投稿の公開可否フラグ１４２９は、あるユーザ端末３０から店舗４０の空き情報が空席管理サーバ１０に送信されている場合に、そのユーザ端末３０からの空き情報を、他のユーザ端末３０に公開するか否かを示すデータである。すなわち、公開可否フラグ１４２９は、入力端末２０から送信された第１の空き情報がデフォルトの配信すべき空き情報のステータスとなっているのに対し、この配信すべき空き情報のステータスを、ユーザ端末３０からの投稿（第２の空き情報）によって上書き可能であるか否かを示すデータである。図３Ａにおいては、公開可否フラグ１４２９は、「可」又は「不可」で示されている。別の形態では、公開可否フラグ１４２９は、公開可の場合に「０」、公開不可の場合に「１」のように数字で示されていてもよい。

図３Ｂは、データベース１４１に格納されている空き情報データベース１４３を示す図である。空き情報データベース１４３は、店舗ごとの最新の空き状況を管理するデータテーブルであり、例えば、店舗ＩＤ１４３１、第１の空き情報１４３２、入力端末ＩＤ１４３３及び受信日時１４３４を構成項目として有している。空き情報データベース１４３の１つのレコードは、１つの店舗の空き状況を管理する。

店舗ＩＤ１４３１は、店舗情報データベース１４２の店舗ＩＤ１４２１と対応するデータであり、ある店舗の店舗ＩＤ１４２１と店舗ＩＤ１４３１とは同一である。第１の空き情報１４３２は、店舗４０内の入力端末２０から送信されてきた最新の空き状況を示すデータである。図３Ｂの例においては、第１の空き情報１４３２は、「空あり」、「やや混雑」又は「満席」のうちいずれかにより示されている。別の形態として、第１の空き情報１４３２は、空席がある場合は「０」、混雑している場合は「１」、満席の場合は「２」のように数字で示されていてもよい。また、別の形態として、第１の空き情報１４３２は、空席の数又は空きテーブルの数を示す数値であってもよい。

入力端末ＩＤ１４３３は、入力端末２０の識別子であり、例えば入力端末２０のＭＡＣアドレスを用いることができる。なお、入力端末ＩＤ１４３３は、店舗ＩＤ１４３１に対応する入力端末として事前に設定された識別情報であり、本実施形態においては第１の空き情報１４３２が更新されても入力端末ＩＤ１４３３は基本的には変わらない。受信日時１４３４は、空席管理サーバ１０が入力端末２０から第１の空き情報１４３２を受信した日時を示すデータである。別の形態では、受信日時の代わりに、入力端末２０が空き状況を送信した送信日時としてもよい。

図３Ｃは、データベース１４１に格納されているユーザ投稿データベース１４４を示す図である。ユーザ投稿データベース１４４は、ユーザ端末３０から送信された店舗４０ごとの空き状況を管理するデータテーブルであり、例えば、店舗ＩＤ１４４１、ユーザ投稿１４４２、ユーザ端末ＩＤ１４４３及び受信日時１４４４を構成項目として有している。ユーザ投稿データベース１４４の１つのレコードは、１つのユーザ投稿を管理する。

店舗ＩＤ１４４１は、店舗情報データベース１４２の店舗ＩＤ１４２１と対応するデータであり、ある店舗の店舗ＩＤ１４２１と店舗ＩＤ１４４１とは同一である。ユーザ投稿１４４２は、店舗４０を訪れた（あるいは、店舗４０付近にいる）ユーザのユーザ端末３０から送信されてきた空き状況を示すデータである。ユーザ端末ＩＤ１４４３は、ユーザ端末３０の識別子であり、例えばユーザ端末３０のＭＡＣアドレスを用いることができる。受信日時１４４４は、空席管理サーバ１０がユーザ端末３０からユーザ投稿１４４２を受信した日時を示すデータである。別の形態では、受信日時の代わりに、ユーザ端末３０が空き状況を送信した送信日時としてもよい。

データベース１４１は、例えばレコードの内容を記述したデータを記憶装置１４内に格納することによって構成できる。なお、本実施形態では店舗情報データベース１４２、空き情報データベース１４３及びユーザ投稿データベース１４４はテーブル形式で表されているが、この形式に限らず、各データが紐付けされていればどのような形式で構築してもよい。したがって、単に、空席管理データあるいは空席管理情報と称することも可能である。

＜入力端末２０の構成例＞
図４Ａは、入力端末２０のハードウェア構成図である。入力端末２０は、ＣＰＵ２１、表示装置２２、入力装置２３及び通信装置２４を備える。ＣＰＵ２１は、入力端末２０が備える各部を制御する。通信装置２４は、ネットワーク５０を介して空席管理サーバ１０と通信し、空席管理サーバ１０から、空き情報及び店舗情報を入力するためのＧＵＩ画面を受信する。表示装置２２は、空席管理サーバ１０から受信したＧＵＩ画面を表示する。入力装置２３は、店員が入力端末２０に対する操作指示を入力するために用いるインターフェースである。例えばタッチパネルなどによって、表示装置２２及び入力装置２３を一体的に構成することもできる。

図４Ｂは、入力端末２０の機能ブロック図である。入力端末２０は、ＣＰＵ２１が実行するソフトウェアモジュール（各種プログラムがＣＰＵ２１の内部メモリに展開されて構成される機能）として、記憶部２１１、通信制御部２１２、設定部２１３及び表示制御部２１４を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはＣＰＵ２１であるため、ＣＰＵ２１を動作主体とすることもできる。

記憶部２１１は、ＣＰＵ２１の内部メモリとして機能する。通信制御部２１２は、通信装置２４を介して、空席管理サーバ１０との通信を行う。具体的には、通信制御部２１２は、空席管理サーバ１０からＧＵＩ画面を受信する。ＧＵＩ画面上では、店舗名、所在地、電話番号、ユーザによる空き情報の公開を許可するか否かを入力する画面や、「空席」、「やや混雑」、「満席」などの空き情報を選択し入力する画面が表示される。なおここで入力できる空き情報として表示される選択肢は、店舗４０の入力端末２０から送信されうる空き情報と同じ空き情報とする。設定部２１３は、店舗４０の店員が入力装置２３及びＧＵＩ画面を介して入力した空き情報及び店舗情報（公開可否フラグを含む）を受け付ける。通信制御部２１２は、入力された空き情報及び店舗情報と、入力端末ＩＤと、公開可否フラグとを、空席管理サーバ１０に送信する。表示制御部２１４は、表示装置２２の表示を制御する。具体的には、表示制御部２１４は、空席管理サーバ１０から受信したＧＵＩ画面（店舗情報の設定画面及び空き状況の投稿画面）を表示装置２２に表示する。

＜ユーザ端末３０の構成例＞
図５Ａは、ユーザ端末３０のハードウェア構成図である。ユーザ端末３０は、ＣＰＵ３１（情報処理装置）、表示装置３２、入力装置３３及び通信装置３４を備える。ＣＰＵ３１は、ユーザ端末３０が備える各部を制御する。通信装置３４は、ネットワーク５０を介して空席管理サーバ１０と通信し、店舗の空き情報の検索リクエストを送信して、空席管理サーバ１０から空き情報を受信する。表示装置３２は、空席管理サーバ１０から受信した店舗の空き情報や、空き情報を入力するためのＧＵＩ画面（投稿画面）を画面表示する。入力装置３３は、ユーザがユーザ端末３０に対する操作指示を入力するために用いるインターフェースである。例えばタッチパネルなどによって、表示装置３２及び入力装置３３を一体的に構成することもできる。

図５Ｂは、ユーザ端末３０の機能ブロック図である。ユーザ端末３０は、ＣＰＵ３１が実行するソフトウェアモジュール（各種プログラムがＣＰＵ３１の内部メモリに展開されて構成される機能）として、記憶部３１１、通信制御部３１２、生成部３１３及び表示制御部３１４を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはＣＰＵ３１であるため、ＣＰＵ３１を動作主体とすることもできる。

記憶部３１１は、ＣＰＵ３１の内部メモリとして機能する。通信制御部３１２（取得手段）は、通信装置３４を介して、空席管理サーバ１０との通信を行う。具体的には、通信制御部３１２は、ユーザが入力装置３３を介して空き情報の照会の指示を入力すると、空席管理サーバ１０に検索リクエストを送信する。また、通信制御部３１２は、空席管理サーバ１０から店舗情報及び空き情報を受信する。

生成部３１３（地図データ読み込み部）は、ユーザ端末３０の位置情報及びユーザによって指定された地図の拡大率に応じて、記憶部３１１から地図情報（地図データ）を読み込む。また、生成部３１３は、空席管理サーバ１０から受信した空き情報に対応するテキストデータあるいはマークデータ（空席「０」に対応するテキスト／マーク、やや混雑「１」に対応するテキスト／マーク、満席「２」に対応するテキスト／マーク）を記憶部３１１から読み出し、地図上に重畳表示するためのＵＩデータ（表示用ＵＩデータ：ピン表示など）を生成する。さらに、生成部３１３は、空席管理サーバ１０から受信した店舗情報に基づき、空き状況の投稿画面を生成する。生成部３１３における空き情報の処理方法の詳細については後述する。

表示制御部３１４（表示制御手段）は、表示装置３２の表示を制御する。具体的には、表示制御部３１４は、生成部３１３が読み込んだ地図、並びに生成部３１３が生成したピン及び空き状況の投稿画面を表示装置３２に表示する。通信制御部３１２は、空き状況の投稿画面を介してユーザが入力した店舗４０の空き情報と、店舗ＩＤと、ユーザ端末ＩＤとを、空席管理サーバ１０に送信する。

＜空席管理サーバ１０の空き情報処理＞
図６は、空席管理サーバ１０が実行する空き情報の配信処理手順を示すフローチャートである。空席管理サーバ１０は、図６に示すフローチャートを実現するプログラムを実行する。

（ステップＳ１０１）
判定部１１３は、受信部１１１がユーザ端末３０から空き情報の検索リクエストを受信したか否かを判断する。空き情報の検索リクエストを受信した場合（Ｙｅｓ）、処理はステップＳ１０２に移行する。なお、検索リクエストには、ユーザ端末３０の現在の位置情報（例えば、ＧＰＳから取得した緯度経度情報）が含まれている。

（ステップＳ１０２）
判定部１１３は、検索リクエストに含まれている位置情報を取得し、ＲＡＭ１３又は記憶装置１４に格納する。

（ステップＳ１０３）
判定部１１３は、ユーザ端末３０の位置情報からユーザ端末３０の現在位置を特定し、店舗情報データベース１４２の緯度経度１４２６を参照して、上記位置情報に応じて、ユーザ端末３０に空き情報を送信すべき店舗群を特定し、当該店舗群の情報をＲＡＭ１３又は記憶装置１４に一時的に格納する。具体的には、判定部１１３は、ユーザ端末３０の現在位置から所定距離範囲（例えば、現在位置から半径５ｋｍの範囲）内にある店舗群を特定（決定）する。

（ステップＳ１０４）
判定部１１３は、店舗情報データベース１４２及び空き情報データベース１４３を参照して、特定された店舗群に含まれる各店舗の店舗情報及び空き情報を抽出し、ＲＡＭ１３又は記憶装置１４に格納する。このとき、判定部１１３は、公開可否フラグ１４２９、受信日時１４３４及び受信日時１４４４を参照して、空き情報データベース１４３に格納された第１の空き情報１４３２、又は、ユーザ投稿データベース１４４に格納されたユーザ投稿１４４２による空き情報のいずれをユーザ端末３０に配信するかを決定する。この配信すべき空き情報の決定方法については、後述する。

（ステップＳ１０５）
出力部１１４は、通信装置１５を介して、ステップＳ１０３で特定した店舗群の情報と、ステップＳ１０４で取得した各店舗の店舗情報及び空き情報を、リクエストを送信してきたユーザ端末３０に送信する。

なお、図示は省略しているが、空席管理サーバ１０は、以上の空き情報の配信処理と並行して、空き情報データベース１４３及びユーザ投稿データベース１４４の更新処理を実行する。空き情報データベース１４３及びユーザ投稿データベース１４４の更新処理では、受信部１１１により、入力端末２０及びユーザ端末３０から、少なくとも店舗ＩＤ、空き状況を示すデータ及び端末ＩＤを受信し、更新部１１２により、空き情報データベース１４３及びユーザ投稿データベース１４４を更新する。空き情報データベース１４３及びユーザ投稿データベース１４４の更新は、入力端末２０又はユーザ端末３０から空き状況を示すデータを受信するたびに実行する。

＜配信すべき空き情報の決定方法＞
図７は、ステップＳ１０４における、空席管理サーバ１０が実行する、配信すべき空き情報の決定方法のフローチャートである。

（ステップＳ２０１）
判定部１１３は、ステップＳ１０３において特定された店舗群の中から、任意の１つの店舗を処理対象店舗として選択する。

（ステップＳ２０２）
判定部１１３は、空き情報データベース１４３を参照して、処理対象店舗の入力端末２０から送信された処理対象店舗の第１の空き情報を取得し、ＲＡＭ１３又は記憶装置１４に格納する。

（ステップＳ２０３）
判定部１１３は、ユーザ投稿データベース１４４を参照して、現在時刻から所定時間（例えば、３０分）以内に更新されたユーザ投稿があるか否かを判断する。所定時間以内に更新されたユーザ投稿がある場合（Ｙｅｓ）、処理はステップＳ２０４に移行する。所定時間以内に更新されたユーザ投稿がない場合（Ｎｏ）、処理はステップＳ２１１に移行する。

（ステップＳ２０４）
判定部１１３は、所定時間以内に更新されたユーザ投稿をすべて取得し、ＲＡＭ１３又は記憶装置１４に格納する。

（ステップＳ２０５）
判定部１１３は、ステップＳ２０４において取得したユーザ投稿のうち、最多の空き情報を第２の空き情報として設定し、ＲＡＭ１３又は記憶装置１４に格納する。例えば、ステップＳ２０４において取得したユーザ投稿が５つあり、うち４つが「空きあり」、残りの１つが「やや混雑」である場合、第２の空き情報として「空きあり」が設定されることになる。また、判定部１１３は、最多の空き情報を示すユーザ投稿のうち、最新の（最も現在時刻に近い）受信日時を、第２の空き情報の受信日時として設定する。

（ステップＳ２０６）
判定部１１３は、第１の空き情報と第２の空き情報とが同じであるか否かを判断する。第１の空き情報と第２の空き情報とが同じである場合（Ｙｅｓ）、処理はステップＳ２１１に移行する。ここで、第１の空き情報と第２の空き情報とが同じであり、第２の空き情報の受信日時が第１の空き情報の受信日時より新しい場合、更新部１１２は、空き情報データベース１４３の第１の空き情報の受信日時１４３４を第２の空き情報の受信日時と同じになるように更新してもよい。店舗４０の店員が更新された日時に第１の空き情報を送信したわけではないが、第１の空き情報は更新された日時の時点でも有効（実際の店舗４０内の空き状況と同じである）といえるので、第１の空き情報の受信日時をより現在時刻に近い日時にも送信されたものとみなすことができる。これにより、次回の決定フロー（図７の一連の処理）におけるステップＳ２０７の判断の際に、より最新の第１の空き情報の受信日時を用いた判断ができる。第１の空き情報と第２の空き情報とが同じでない場合（Ｎｏ）、処理はステップＳ２０７に移行する。

（ステップＳ２０７）
判定部１１３は、空き情報データベース１４３及びユーザ投稿データベース１４４を参照して、第１の空き情報の受信日時が、第２の空き情報の受信日時よりも後であるか否かを判断する。第１の空き情報の受信日時が、第２の空き情報よりも後である場合（Ｙｅｓ）、処理はステップＳ２１１に移行する。第１の空き情報の受信日時が、第２の空き情報よりも後でない場合（Ｎｏ）、処理はステップＳ２０８に移行する。

（ステップＳ２０８）
判定部１１３は、店舗情報データベース１４２の公開可否フラグ１４２９を参照して、ユーザ投稿の公開が許可されているか否かを判断する。ユーザ投稿の公開が許可されている場合（Ｙｅｓ）、処理はステップＳ２０９に移行する。ユーザ投稿が公開不可の場合（Ｎｏ）、処理はステップＳ２１０に移行する。

（ステップＳ２０９）
判定部１１３は、第１の空き情報と第２の空き情報とが異なり（ステップＳ２０６）、第２の空き情報（ユーザ投稿）の方が第１の空き情報よりも最新であり（ステップＳ２０７）、ユーザ投稿の公開が許可されている（ステップＳ２０８）場合、第２の空き情報を、照会リクエストを送信したユーザ端末３０に配信すると決定する。換言すれば、配信すべき空き情報のステータスを、第２の空き情報で上書きする。

（ステップＳ２１０）
判定部１１３は、ユーザ投稿が公開不可である場合、ステップＳ２０５において第２の空き情報として設定した空き情報を、出力部１１４を介して入力端末２０に送信する。これにより、ユーザ投稿を店舗４０の店員に通知（フィードバック）する。ユーザ投稿のフィードバックに際し、判定部１１３は、例えば、入力端末２０に「ユーザから「空きあり」が空き情報として投稿されています。「空きあり」に更新しますか？」とプッシュ通知することができる。別の形態では、判定部１１３は、入力端末２０に「ユーザから「空きあり」が空き情報として投稿されています」といったテキストを含むメールを送信することができる。別の形態では、店舗４０の店員が、任意のタイミングで、第２の空き情報として設定された空き情報を閲覧できるようにしてもよい。

（ステップＳ２１１）
判定部１１３は、所定時間以内のユーザ投稿がないか（ステップＳ２０３）、第１の空き情報と第２の空き情報とが同じであるか（ステップＳ２０６）、第１の空き情報の方が第２の空き情報（ユーザ投稿）よりも最新であるか（ステップＳ２０７）、又は、ユーザ投稿が公開不可である（ステップＳ２０８）場合、第１の空き情報を、照会リクエストを送信したユーザ端末３０に配信すると決定する。すなわち、配信すべき空き情報のステータスを、デフォルトの第１の空き情報のままとする。

（ステップＳ２１２）
判定部１１３は、ステップＳ１０３において特定された店舗群のうち、未処理の店舗があるか否かを判断する。このとき、判定部１１３は、ステップＳ２０１において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合（Ｙｅｓ）、処理はステップＳ２０１に戻り、ステップＳ２０１～Ｓ２１１が上記と同様に実行される。未処理の店舗がない場合（Ｎｏ）、配信すべき空き情報の決定処理は終了し、上述のステップＳ１０５に移行する。

店舗４０からの空き情報の送信が漏れていたり、誤っていたりすることで、正確な空き情報がユーザに配信されない場合がある。これに対し、本実施形態のように、店舗４０がユーザ投稿を公開可能な店舗である（公開可否フラグを「可」にしている）場合には、ユーザ投稿を用いて空き情報を配信することで、より正確な空き情報を配信することができる。つまり、第１のユーザ端末から送信された第１の店舗の空き情報が、第２のユーザ端末上に、第１の店舗の空き情報として表示されることがある。その一方で、第２の店舗の空き情報に関しては、第１のユーザ端末から空き情報が送信されても、第２のユーザ端末には第２の空き情報として表示されないことがある。ユーザ投稿を公開できない場合には、ユーザ投稿を店舗の入力端末２０にフィードバックすることで、店舗４０に空き情報の更新を促すことができる。

以上のように、店舗４０付近にいるユーザに空き情報を投稿してもらい、ユーザ端末３０への配信又は入力端末２０へのフィードバックに用いることで、ユーザからの情報を有効利用することができる。別の形態では、上述のステップＳ２０９の後にも、第２の空き情報を送信すると決定したことを示す通知を、出力部１１４を介して入力端末２０に送信してもよい。

別の形態では、判定部１１３は、ステップＳ２０４において取得したユーザ投稿の数や同じ空き情報のユーザ投稿の数が、所定数以上である場合に、ステップＳ２０５において最多のユーザ投稿の空き情報を第２の空き情報として設定するようにしてもよい。具体的には、判定部１１３は、ステップＳ２０４の後、所定時間以内にユーザ投稿が所定数（例えば１０）以上ある場合にはステップＳ２０５の処理を実行することができる。別の形態では、判定部１１３は、ステップＳ２０５の処理において第２の空き情報として設定された空き情報を投稿したユーザ数が所定数以上ある場合にはステップＳ２０６に進み、所定数未満である場合には、ステップＳ２１１に進むようにすることができる。これにより、店舗４０に関する空き情報として上書きされうる第２の空き情報を、より信頼度の高い情報で設定することができ、特定のユーザによるいたずらで本来の空き状況とは異なる空き情報が配信されてしまうことを防ぐことができる。

＜ユーザ端末３０の空き情報表示処理＞
図８は、ユーザ端末３０における空き情報の表示処理手順を示すフローチャートである。ユーザ端末３０は、図８に示すフローチャートを実現するプログラムを実行する。

（ステップＳ３０１）
生成部３１３は、通信制御部３１２を介して、ユーザ端末３０の現在位置を示す位置情報（ＧＰＳデータ）を取得する。生成部３１３は、取得した位置情報を記憶部３１１に格納する。

（ステップＳ３０２）
生成部３１３は、記憶部３１１からユーザ端末３０の位置情報を取得し、当該位置情報を含む検索リクエストを生成し、通信制御部３１２を介して検索リクエストを空席管理サーバ１０に送信する。空席管理サーバ１０は、検索リクエストを受信すると、図６及び図７に示した上述の処理を実行する。

（ステップＳ３０３）
生成部３１３は、ステップＳ３０１で取得した位置情報及びユーザによって指定された地図の拡大率に応じて、記憶部３１１から地図情報（地図データ）を読み込み、表示制御部３１４を介して表示装置３２の表示画面上に所望の地図を表示する。なお、地図の拡大率は事前に設定された固定値としてもよい。

（ステップＳ３０４）
生成部３１３は、通信制御部３１２を介して、空席管理サーバ１０から、ユーザ端末３０の位置情報に応じた店舗群の店舗情報及び空き情報を取得して、記憶部３１１に格納する。

（ステップＳ３０５）
生成部３１３は、空席管理サーバ１０から受信した店舗群のうち、任意の１つの店舗を処理対象店舗として選択する。ここで選択される処理対象店舗は、例えば、緯度経度がユーザ端末３０の位置情報に最も近い店舗とすることができる。別の形態では、店舗ＩＤ１４２１が最も若い店舗を処理対象店舗として選択することもできる。

（ステップＳ３０６）
生成部３１３は、記憶部３１１に格納されている処理対象店舗の空き情報を参照し、表示ピンのオブジェクトデータの中から空き情報に対応するものを選択して、空き情報に基づいたピンデータを生成する。表示ピンのオブジェクトデータは、空き情報に応じて色分けすることができる。例えば、表示ピンのオブジェクトデータは、空き情報が「空きあり」である場合は青色、「やや混雑」である場合は黄色、「満席」である場合は赤色とすることができる。また、表示ピンのオブジェクトデータに、空き情報に対応するテキストデータを重畳することにより各店舗のピンデータが生成される。すなわち、地図に表示されるピンには、１つの店舗の空き情報を示すテキストが含まれる。例えば、処理対象店舗の空き情報が「空きあり」であった場合は、ピンの中に「空きあり」というテキストを表示する。空き情報が「満席」であった場合は、「満席」というテキストを表示する。ピンデータに含まれるテキストは、例えば黒文字又は白文字とすることができる。

（ステップＳ３０７）
生成部３１３は、処理対象店舗の緯度経度にしたがって、ステップＳ３０６で生成したピンデータを地図上に配置する。なお、このとき、生成部３１３は、空き情報が「やや混雑」又は「満席」の店舗についてはピンデータを削除して配置せず、空き情報が「空き」を示す店舗のピンデータのみを配置するようにしてもよい。

（ステップＳ３０８）
生成部３１３は、空席管理サーバ１０から受信した店舗群のうち、未処理の店舗があるか否かを判断する。このとき、生成部３１３は、ステップＳ３０５において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合（Ｙｅｓ）、処理はステップＳ３０５に戻り、ステップＳ３０５～Ｓ３０７が上記と同様に実行される。未処理の店舗がない場合（Ｎｏ）、処理はステップＳ３０９に移行する。

（ステップＳ３０９）
表示制御部３１４は、ステップＳ３０７において生成部３１３により地図上に配置されたピンデータにしたがって、表示用ピンを表示装置３２の表示画面に表示する。

一旦空き情報を照会したユーザ端末３０は、所定時間ごと（例えば、１０秒ごと）に最新の空き情報を取得するためのリクエスト（再リクエスト）を空席管理サーバ１０に送信する。空席管理サーバ１０は、当該再リクエストに応答して、最新の空き情報をデータベース１４１から取得し、ユーザ端末３０に送信する。最新の空き情報を受信すると、ユーザ端末３０は、最初のリクエストに対応して取得して地図上に表示した店舗群の空き情報を更新して表示画面上にピン表示する。

以上、ユーザ端末３０においてピンデータを生成することを説明したが、空席管理サーバ１０側で、又は、表示用データを生成するための他の装置等において、ピンデータを生成してユーザ端末３０に送信し、ユーザ端末３０は表示する処理のみを行うようにしてもよい。

＜地図上でのＵＩ表示例＞
第１の実施形態による、ユーザ端末３０の表示装置３２の表示画面に表示されるＵＩ表示の例を説明する。

図９は、第１の実施形態における地図上に表示されるＵＩ表示（ピン表示）の例を示す図である。図９に示す例において、ピンの色が空き情報に応じて色分けされており、ピンに空き情報を示すテキストが表示されている。ピンの色分けやテキストの色については、空き情報がいずれであるかをユーザが認識することができればよく、図示したものに限定されない。また、地図上には、ユーザの現在位置１００が示されている。

以上の通り、本実施形態において、店舗によって管理された店舗の空き情報に加えて、店舗の店員ではないユーザ（一般客）からも店舗の空き情報の投稿を受け付け、店舗の空き情報として利用する。例えば、第１のユーザが投稿した店舗Ｂの空き情報に関して、店舗Ｂがユーザ投稿の公開を許可しており、所定の条件を満たす場合には、第１のユーザとは異なる第２のユーザに対して、第１のユーザが投稿した店舗Ｂの空き情報を提供することができる。これにより、店舗による空き情報の更新が漏れていたり、店舗が入力した空き情報が誤っていたりしても、ユーザは、より正確な空き情報を参考にすることができる。

＜ユーザ端末３０の投稿画面の表示処理＞
図１０は、ユーザ端末３０における空き情報の投稿画面の表示手順を示すフローチャートである。ユーザ端末３０は、図１０に示すフローチャートを実現するプログラムを実行する。

（ステップＳ４０１）
生成部３１３は、ユーザによる地図上のピン（店舗）の選択を受け付ける。

（ステップＳ４０２）
生成部３１３は、記憶部３１１からユーザ端末３０の位置情報を取得する。

（ステップＳ４０３）
生成部３１３は、記憶部３１１に格納された店舗情報のうち営業時間を参照し、現在時刻が、選択されたピンに対応する店舗４０の営業時間内であるか否かを判断する。営業時間内である場合（Ｙｅｓ）、処理はステップＳ４０４に移行する。営業時間外である場合（Ｎｏ）、処理はステップＳ４０７に移行する。なお、店舗４０が２４時間営業の場合は、本ステップＳ４０３を省略してステップＳ４０７に移行するようにしてもよい。

（ステップＳ４０４）
生成部３１３は、記憶部３１１に格納された店舗情報のうち緯度経度を参照し、ステップＳ４０２で取得したユーザ端末３０の位置情報と、店舗４０との距離を算出する。

（ステップＳ４０５）
生成部３１３は、ユーザ端末３０と店舗４０との距離が、所定の距離以下であるか否かを判断する。この所定の距離は、例えば、ユーザが店舗４０にいてもＧＰＳのずれにより生じる範囲として設定することができる。ＧＰＳのずれが最大３００ｍ発生し得る場合は、所定の距離は、店舗４０の広さも加味して、例えば３５０ｍに設定することができる。所定の距離以下である場合（Ｙｅｓ）、処理はステップＳ４０６に移行する。所定の距離より大きい場合（Ｎｏ）、処理はステップＳ４０７に移行する。

（ステップＳ４０６）
生成部３１３は、ユーザが空き情報を投稿するための各ボタンがアクティブとなっている投稿画面を生成する。ここで、現在時刻が営業時間内であり、ユーザ端末３０と店舗４０との距離が近い（所定の距離以下）である場合は、ユーザが店舗４０内にいる可能性が高いとみなすことができる。このように、所定の条件を満たす場合にのみユーザが空き情報を投稿できるようにすることで、高い信頼性の空き情報の投稿を受け付けることができる。

（ステップＳ４０７）
ステップＳ４０３において営業時間外であると判断された場合、又は、ステップＳ４０５において所定の距離より大きいと判断された場合、生成部３１３は、各ボタンが非アクティブとなっている投稿画面を生成する。このように、所定の条件が満たされない場合には、空き情報の投稿が受け付けられない。ただし、投稿画面を生成しないのではなく、各ボタンが非アクティブとなっている投稿画面を生成することで、条件を満たせば空き情報を投稿できる場合があることを、ユーザに暗に示すことができる。

（ステップＳ４０８）
表示制御部３１４は、ステップＳ４０６又はステップＳ４０７で生成された投稿画面を表示装置３２の表示画面に表示する。

以上の通り、ユーザ端末３０から店舗の空き情報を送信する場合、店舗４０との距離が近い場合にのみ受け付ける。これにより、ユーザ端末３０からいたずら目的や不正確な空き情報が送信されてしまうことを抑制する。なお、店舗４０の入力端末２０から店舗４０の空き情報が送信される場合は、ステップＳ４０５のように距離が近いか否かを判定することなく、常に空き情報の投稿を受け付ける。店舗４０の入力端末２０の場合は、事前に店舗４０自身からの空き情報であることがわかるように店舗４０に対応する入力端末ＩＤ１４３３が登録されているため、距離に応じた判定をすることなく信頼性の高い空き情報であるとみなせる。さらには、入力端末２０自体が店舗４０内にない場合でも、店舗４０を運営する管理者が店舗４０内で勤務する店員からの連絡を受けて空き情報を送信する場合もあり、距離に関わらず店舗４０の空き情報としてみなすことができる。

＜投稿画面の表示例＞
図１１は、ユーザ端末３０の表示装置３２の表示画面に表示される投稿画面６０の一例を示す図である。図１１においては、ユーザが店舗Ｂ（キッチンＢ）のピンを選択した場合に表示される画面を示している。投稿画面６０では、ユーザが店舗Ｂの空き状況を選択するためのボタン６１～６３（「空きあり」ボタン６１、「やや混雑」ボタン６２及び「満席」ボタン６３）と、選択した空き状況を空席管理サーバ１０に送信するための投稿ボタン６４とが表示されている。ユーザがボタン６１～６３のいずれかを選択して、投稿ボタン６４をタップすると、選択された空き状況と、店舗Ｂの店舗ＩＤと、ユーザ情報とが、空席管理サーバ１０に送信される。そして、空席管理サーバ１０は、ユーザ端末３０から受信した情報にしたがって、ユーザ投稿データベース１４４を更新する（ユーザ投稿１４４２、ユーザ端末ＩＤ１４４３及び受信日時１４４４を含む新たなレコードを作成する）。

＜第１の実施形態のまとめ＞
第１の実施形態に係る空席管理システム１において、ユーザ端末３０から空き情報の検索リクエストを空席管理サーバ１０に送信すると、空席管理サーバ１０は、検索リクエストに応答してユーザ端末３０の位置に基づいて店舗群（ユーザが入力した検索条件に合致する店舗の集合）を特定し、それらの空き情報を店舗情報と共にユーザ端末３０に送信する。このとき、空席管理サーバ１０は、ユーザ投稿の公開可否フラグ（施設情報）に応じて、ユーザ投稿を配信するか、入力端末２０に送信するかを決定する。具体的には、ユーザ投稿の公開が許可されている場合、所定時間以内に投稿されたユーザ投稿のうち最も多いものを店舗の空き情報として、ユーザ端末３０に送信する。これにより、店舗４０の入力端末２０から最後に送信された第１の空き情報が現状とは異なっていたとしても、正確な空き情報を配信することができる。また、ユーザ投稿の公開が許可されていない場合は、ユーザ投稿を入力端末２０に送信することで、店舗４０の店員に空き情報の更新を促すことができるため、結果として、リアルタイムで正確な空き情報の配信につながる。

＜第１の実施形態の変形例＞
第１の実施形態では、店舗４０の店員が店内の空き状況を目視で確認して、入力端末２０に空き情報を入力することで、空席管理サーバ１０に第１の空き情報を送信することとしたが、入力端末２０は、カメラや人感センサなどを用いて空き状況を自動で検出する装置であってもよい。例えば、店舗内を撮像可能な位置に設置されたカメラで店内を撮影し、カメラに接続された情報処理装置で撮像画像を解析し、店舗４０の空き状況を判定し、空席管理サーバ１０に店内の空き情報を送信する。

第１の実施形態では、空席管理サーバ１０が、事前に店舗４０から設定された公開可否フラグに基づいて、ユーザ端末３０に配信すべき空き情報を決定することを説明したが、この方法に限らない。例えば、ユーザ端末３０に配信すべき空き情報は、店舗の入力端末の種別に応じて決定してもよい。この場合、例えば、入力端末２０が、店員がＧＵＩ画面を介して空き状況を入力するスマートフォンなどのコンピュータデバイスである場合、若しくは、入力端末２０が、空き状況に対応するボタン有し、店員がボタンを押下することにより空き状況を送信する端末である場合には、第２の空き情報による上書きを実行する。一方、入力端末２０が、カメラ（スマートフォンなどのコンピュータデバイスに搭載されたカメラを含む）又は人感センサなどの、空き状況を自動で検出する装置である場合には、第２の空き情報を店舗４０の空き情報としてはユーザ端末３０には配信（公開）せずに、店舗４０のみにフィードバックする。これは、空き状況を自動で検出する装置の場合は、空き状況の入力忘れがないため、より信頼性の高い空き状況を入力できるためである。ただし、自動で検出した空き状況が実際の空き状況とズレが生じている場合もあるため、店舗４０にはフィードバックすることで、自動で空き状況を検出する入力端末２０の調整を促すことができる。

別の形態では、公開可否フラグの代わりに、店舗（施設）のジャンルに応じて、第２の空き情報を配信するか、店舗に通知するかを判断するようにしてもよい。この場合、例えば、飲食店はユーザ投稿の公開を許可するが、避難所や投票所などの公的施設はユーザ投稿を公開しないようにすることができる。

第１の実施形態では、店舗４０が公開可否フラグを設定することを説明した。公開可否フラグの代わりに、店舗４０が上書き可否フラグを設定するようにしてもよい。上書き可否フラグは、空き情報データベース１４３の第１の空き情報１４３２を、ユーザ投稿データベース１４４のユーザ投稿１４４２で上書きすることを許可するか否かを示すデータである。この場合、上述のステップＳ２０８において、空席管理サーバ１０の判定部１１３は、第１の空き情報を第２の空き情報で上書き可能であるか否かを判断する。上書き可能である場合、ステップＳ２０９において、判定部１１３は、第２の空き情報を配信すべき空き情報と決定するとともに、更新部１１２は、空き情報データベース１４３の第１の空き情報１４３２を、第２の空き情報に更新する。一方、上書き不可である場合は、判定部１１３は、上述のステップＳ２１０及びＳ２１１を実行する。

空席管理サーバ１０がユーザ端末３０からの検索リクエストに対する応答として、店舗群の店舗情報と空き情報を送信する際（ステップＳ１０５）、空席管理サーバ１０は、現在時刻が各店舗の営業時間内であるかを判断して、営業時間内の店舗の店舗情報と空き情報のみをユーザ端末３０に送信するようにしてもよい。この場合、ユーザ端末３０は、上述のステップＳ４０３における営業時間内であるか否かの判断を行わなくてもよい。

また、空席管理サーバ１０はユーザ端末３０からユーザ投稿を受信すると、ユーザ投稿データベース１４４のレコードを追加して、ステップＳ２０３～Ｓ２０４において受信日時が所定時間以内のユーザ投稿を抽出するようにした。しかしながら例えば、空席管理サーバ１０は、定期的にユーザ投稿データベース１４４を監視し、受信日時から所定時間を超えたユーザ投稿をキャンセルするようにしてもよい。この場合、現在時刻から所定時間を超えた古いユーザ投稿は存在しなくなるので、空席管理サーバ１０が、ユーザ投稿の受信日時が所定時間以内のものがあるか否かを判定するステップ（Ｓ２０３）は不要となる。

また、店舗４０の入力端末２０について、空席管理サーバ１０は入力端末ＩＤ１４３３を事前に店舗４０の入力端末２０として設定しておくこととし、第１の空き情報１４３２と連動して入力端末ＩＤ１４３３も更新されることはないとした。例えば、店舗の店員がＧＵＩ画面を介して空き情報を入力する前に、店舗４０のアカウント情報を用いたログインをした場合に限り、入力端末２０から空き情報を送信できるようにしてもよい。この場合、空席管理サーバ１０は、店舗４０に対応するアカウント情報（例えば、メールアドレスとパスワードなど）を管理し、入力端末ＩＤ１４３３を事前に設定する必要はない。この場合は、店舗４０に対応するアカウントから送信された空き情報を第１の空き情報として利用することになる。また、複数の入力端末２０を用いて空き情報を送信した場合には、店舗４０に対応する入力端末ＩＤ１４３３がその都度更新されることになる。

空席管理サーバ１０が入力端末２０に提供するＧＵＩ画面と、ユーザ端末３０に提供する投稿画面は異なる画像であり、ＧＵＩ画面に対する操作により送信された空き情報と、投稿画面に対する操作により送信された空き情報それぞれを識別可能なように、空席管理サーバ１０に送信すればよい。この場合、例えば店員自身が個人利用を目的として保有する端末を、入力端末２０とユーザ端末３０それぞれとして併用することも可能である。同じ端末から送信された空き情報でも、店舗４０からの空き情報を受け付けるＧＵＩ画面を介して送信された場合には、空席管理サーバ１０は、第１の空き情報として受け付け、ユーザによる空き情報の投稿のための投稿画面を介して送信された場合には、空席管理サーバ１０は、ユーザ投稿として受け付ける。

［第２の実施形態］
上述の第１の実施形態では、公開可否フラグに基づいて、配信すべき空き情報を入力端末２０からの第１の空き情報とするか、ユーザ投稿とするかを決定することを説明した。しかしながら、「やや混雑」していると判断する程度は、人（ユーザ）によって異なるため、「やや混雑」のユーザ投稿を配信せずに、店舗が送信した第１の空き情報を優先して配信するようにしてもよい。このように、第１の空き情報と第２の空き情報とが何であるかによって、優先して配信する空き情報を決定することができる。そこで、第２の実施形態では、第１の空き情報と第２の空き情報との組み合わせに基づいて、配信すべき空き情報を決定する技術を提案する。

＜配信すべき空き情報の決定方法＞
図１２は、空席管理サーバ１０が実行する、第２の実施形態における配信すべき空き情報の決定方法のフローチャートである。ステップＳ２０１～Ｓ２０７については第１の実施形態と同じであるため、説明を省略する。

（ステップＳ５０１）
ステップＳ２０７の後、判定部１１３は、第１の空き情報と第２の空き情報との組み合わせに基づいて、配信すべき空き情報を決定する。以下の表１は、第１の空き情報と第２の空き情報との組み合わせと、第１の空き情報と第２の空き情報のいずれを配信するかを示す。データベース１４１には予め以下の表１が格納されており、判定部１１３は、ステップＳ５０１において表１を参照して、配信すべき空き情報を決定する。

表１に示すように、第１の空き情報が「やや混雑」であり、第２の空き情報が「やや混雑」とは異なっている場合、第１の空き情報を配信する。第１の空き情報が「満席」であり第２の空き情報が「やや混雑」である場合は、空席があっても予約席や店舗の事情で使用しない席である可能性があるため、第１の空き情報を配信する。また、第２の空き情報が、第１の空き情報と２段階異なっている場合（第１の空き情報が「空きあり」に対して、第２の空き情報が「満席」である場合、又は、第１の空き情報が「満席」に対して、第２の空き情報が「空きあり」である場合）は、第２の空き情報を配信する。このように、実際の空き状況と、店舗からの第１の空き情報とが異なっている可能性が高い場合に、第２の空き情報を配信するようにすることで、正確な空き情報をユーザに提供することができる。

なお、別の形態では、判定部１１３は、第１の実施形態と同様に公開可否フラグによりユーザ投稿の公開可否を判断して、ユーザ投稿の公開を許可している店舗の空き情報についてのみ、第１の空き情報と第２の空き情報との組み合わせ（表１）に基づいて、配信すべき空き情報を決定するようにしてもよい。

（ステップＳ５０２）
判定部１１３は、ステップＳ５０１で決定した空き情報を、出力部１１４を介して入力端末２０に通知する。例えば、第２の空き情報を配信すると決定された場合には、その旨をテキスト表示したり、第１の空き情報を第２の空き情報と同じに変更するよう促すテキストを表示したりすることができる。

＜第２の実施形態のまとめ＞
第２の実施形態においては、空席管理サーバ１０は、第１の空き情報と第２の空き情報（施設情報）に応じて、ユーザ投稿を配信するか、第１の空き情報を配信するかを決定する。具体的には、第１の空き情報と第２の空き情報とが異なっており、第２の空き情報が第１の空き情報よりも最新である場合に、第１の空き情報と第２の空き情報との組み合わせに基づいて、配信すべき空き情報をユーザ投稿（第２の空き情報）とするか、入力端末２０からの第１の空き情報とするかを決定する。これにより、空き状況の判断は人によって異なることもあるが、ユーザ投稿の方が第１の空き情報よりもより正確な空き状況を反映していると思われる場合に、当該ユーザ投稿を配信することができる。また、例えば、店舗４０を訪れているユーザにとっては空き状況が「やや混雑」に見えても、空いている席が予約席であったり、店舗４０の外で行列ができていたりした場合に、店舗４０の店員は空き情報を「満席」としておきたいことがある。このような場合には、店舗４０からの第１の空き情報を優先することで、店舗４０の意図を反映した正確な空き情報を配信することができる。

［第３の実施形態］
第１の実施形態においては、日時にかかわらず、所定の条件を満たす場合は、第１のユーザ端末３０から送信されたユーザ投稿（第２の空き情報）を、第２のユーザ端末３０に配信することを説明した。しかしながら、店舗４０によっては、必ず混雑する日時には空き情報を「やや混雑」又は「満席」としておき、ユーザ投稿によって「空きあり」の空き情報が配信されないようにしたい場合がある。そこで、第３の実施形態では、配信される空き情報を固定する日時を設定でき、空き情報を固定する日時を参照してユーザ投稿の配信をするか否かを判定する技術を提案する。

＜入力端末の画面表示例＞
図１３は、入力端末２０の表示装置２２の表示画面に表示される固定情報設定画面８０の一例を示す図である。固定情報設定画面７０は、空き情報を固定にする曜日及び時間帯、並びに固定にする空き情報を設定するための選択箇所と、送信ボタン７１とを有している。店員が固定情報（上書き可否情報）を入力後、送信ボタン７１を押すことにより、固定情報が通信装置２４を介して空席管理サーバ１０に送信される。図１３の固定情報設定画面７０においては、曜日を選択できるように構成されているが、別の形態では、カレンダー表示から日付を選択できるようにしてもよい。また、図１３の固定情報設定画面７０においては、固定時間帯を１つのみ選択できるように構成されているが、別の形態では、複数の固定時間帯を設定できるようにしてもよい。この場合、複数の固定時間帯のそれぞれについて、固定空き情報を設定できるようにする。

＜データベースの構成例＞
図１４は、第３の実施形態に係る店舗情報データベース２４２を示す図である。図１４に示すように、店舗情報データベース２４２は、固定曜日２４２１、固定時間帯２４２２及び固定空き情報２４２３をさらに構成項目として有している点で、第１の実施形態の店舗情報データベース１４２と異なっている。固定曜日２４２１、固定時間帯２４２２及び固定空き情報２４２３は、固定情報設定画面７０に入力された固定情報に対応する。

＜配信すべき空き情報の決定方法＞
図１５は、第３の実施形態における配信すべき空き情報の決定方法のフローチャートである。

（ステップＳ６０１）
判定部１１３は、第１の実施形態と同様にステップＳ２０１を実施した後、店舗情報データベース２４２を参照して、処理対象店舗の固定空き情報２４２３が設定されているか否かを判断する。固定空き情報２４２３が設定されている場合（Ｙｅｓ）、処理はステップＳ６０２に移行する。固定空き情報２４２３が設定されていない場合（Ｎｏ）、第１の実施形態と同様に、ステップＳ２０２～Ｓ２１２が実行される。

（ステップＳ６０２）
判定部１１３は、当日が固定曜日２４２１であり、かつ現在時刻が固定時間帯２４２２内にあるか否かを判断する。固定曜日２４２１であり、かつ現在時刻が固定時間帯２４２２内である場合（Ｙｅｓ）、処理はステップＳ６０３に移行する。固定曜日２４２１でないか、又は現在時刻が固定時間帯２４２２内でない場合（Ｎｏ）、第１の実施形態と同様に、ステップＳ２０２～Ｓ２１２が実行される。

ただし、現在時刻が固定時間帯２４２２の後であり、配信すべき空き情報のステータスが固定空き情報２４２３のままである場合は、更新部１１２により、空き情報データベース１４３の第１の空き情報１４３２の受信日時１４３４を固定時間帯の終了時刻として、固定空き情報２４２３を第１の空き情報１４３２として更新する。

また、固定時間帯２４２２の後、空き情報のステータスが固定空き情報２４２３のままであり、第２の空き情報が所定の条件を満たす場合、第１の実施形態と同様に、公開可否フラグや店舗４０のジャンルといった店舗情報に応じて、固定空き情報２４２３が第２の空き情報で上書きされうる。別の形態では、固定時間帯２４２２の後、空き情報のステータスが固定空き情報２４２３のままであり、第２の空き情報が所定の条件を満たす場合、第２の実施形態と同様に、固定空き情報２４２３と第２の空き情報との組み合わせに応じて、固定空き情報２４２３が第２の空き情報で上書きされうる。

（ステップＳ６０３）
判定部１１３は、固定空き情報２４２３を配信すべき空き情報として決定する。その後、処理はステップＳ２１２に移行する。すなわち、固定空き情報２４２３を配信する際は、店舗４０の入力端末２０に、空き情報の更新を促す通知は送信されない。

＜第３の実施形態のまとめ＞
以上のように、第３の実施形態においては、空席管理サーバ１０は、空き情報が固定された日時に関する固定情報（施設情報）に応じて、ユーザ投稿（第２の空き情報）を配信するか、入力端末２０に送信するかを決定する。具体的には、現在時刻において空き情報が固定されている場合には、配信すべき空き情報を固定空き情報とする。一方、現在時刻が、空き情報が固定されていない日時である場合は、第１の実施形態と同様に、所定の条件を満たす場合に配信すべき空き情報をユーザ投稿（第２の空き情報）とする。このように、空き情報が固定されている場合、店舗４０の入力端末２０がどのような空き情報を空席管理サーバ１０に送信しているか、入力端末２０がどのような種類の装置であるか（店舗が空き状況を入力する装置か、空き状況を自動で検出する装置か）によらず、固定空き情報を優先して配信する。これにより、店舗を訪れたユーザから見た空き状況が固定空き情報と異なっていたとしても、ユーザ投稿は配信されず、店舗の意図が反映された空き情報を配信することができる。

［変形例］
以上の実施形態では、飲食店の空き情報を例に説明したが、これに限らない。例えば、飲食店以外にも映画館やスポーツスタジアム、駐車場、バス停などの施設の空き情報にも、本実施形態の技術を適用できる。また、本実施形態の空席管理システム１は、席を提供されないが人の多さが変動するような施設における利用者の空き状況を管理してもよい。具体的には、例えばスーパーマーケット、薬局、スポーツジム、自治体若しくは銀行の窓口、温泉施設などの空き状況を示す情報を管理してもよい。この場合、例えば、空席管理サーバ１０は、「空いている」「やや混雑」「混雑」のいずれかによって表される混雑情報を管理し、配信する。

また、ジャンルや施設によって空き情報として選択されうる選択肢が異なる場合がある。このような場合、ユーザ端末３０に表示される店舗ごとの空き情報の投稿画面は、店舗４０自身が配信可能な空き情報に応じて生成される方が望ましい。例えば、店舗４０からの配信が「空きあり」、「やや混雑」、「満席」のうちいずれかである場合には、投稿画面にも「空きあり」、「やや混雑」、「満席」が選択肢として表示され、店舗４０からの配信が「空いている」、「やや混雑」、「混雑」のうちいずれかである場合には、投稿画面にも「空いている」、「やや混雑」、「混雑」が選択肢として表示される。また、必ずしも店舗４０から送信されうる空き情報の種類の全てを、ユーザ端末３０の表示画面にも表示しなくてもよい。例えば、店舗４０からの送信されうる空き情報の種類が「空きあり」、「やや混雑」、「満席」に加えて、「Ｎ分待ち」や「順番待ちＮ組」（Ｎには任意の数字を選択可能）などもあるとする。この場合、ユーザ端末３０の空き情報の投稿画面に表示される選択肢は、店舗４０からの送信されうる空き情報のうち「空きあり」、「やや混雑」、「満席」のみであってもよい。つまり、ユーザ端末３０に表示される投稿画面上の空き情報の選択肢は、少なくとも店舗４０からも送信されうる選択肢であることが望ましいが、全てではなくてもよい。

以上の実施形態において、ユーザ端末３０の位置を位置情報として取得し、ユーザ端末３０の位置を基準として店舗群を特定する方法を説明したが、位置情報はこれに限らない。例えばユーザ端末３０における表示装置３２がタッチパネルディスプレイであり、入力部としても機能する場合に、表示装置３２に表示された地図上の位置をユーザがタップすることにより、ユーザが位置情報を指定し、指定した位置情報（基準位置）を空席管理サーバ１０に送信するようにしても良い。この場合、空席管理サーバ１０は、指定された位置情報に応じて店舗群を特定する。

以上の実施形態において、入力端末２０としてコンピュータデバイスを用いる場合について説明したが、入力端末２０としては、例えばカメラ又は人感センサなどの、店舗４０の空き状況をリアルタイムに検出するセンサを用いることもできる。入力端末２０がカメラである場合、カメラは、店舗４０内や待機列にいる人を検出して、空き状況を判断し、空席管理サーバ１０に送信するように構成される。別の形態では、カメラの映像データを用いて、空席管理サーバ１０が空き状況を判断するようにしてもよい。入力端末２０が人感センサである場合、人感センサは、例えば座席ごとに設置され、すべての人感センサの検出結果を空席管理サーバ１０に送信するように構成される。

以上の実施形態において、ユーザ端末３０は周辺店舗の空き状況を画面表示する例を説明したが、これに代えて常に特定の店舗の空き状況のみを空席管理サーバ１０へ照会するようにしてもよい。さらにユーザ端末３０は、空き状況を照会する店舗の属性（例：ジャンル１４２３などの店舗のカテゴリ情報）を指定してもよい。この場合、出力部１１４は、その指定された属性に合致する店舗の空き情報のみをユーザ端末３０に対して返信する。

以上の実施形態において、ユーザ端末３０は必ずしもユーザが携帯する端末でなくともよい。例えば特定場所に設置されているコンピュータなどの通信デバイスをユーザ端末３０として用いてもよい。例えば人通りが多い場所に固定設置されているデジタルサイネージ端末をユーザ端末３０として構成してもよい。この場合は必ずしもデジタルサイネージ端末の周辺店舗に関する空き情報を表示する必要はなく、端末設置者が所望する場所の店舗に関する空き情報を表示することもできる。

以上の通り、本開示の技術は、上述の実施形態の１つ以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し作動させる処理によって実現することができる。また、１以上の機能を実現する回路によって実現しても良い。

本開示は、上述した実施形態に限定されるものでなく、様々な変形例を含んでいる。例えば、上述した実施形態は、本開示を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備える必要はない。また、ある実施形態の一部を他の実施形態の構成に置き換えることができる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の実施形態の構成の一部を追加、削除又は置換することもできる。

１…空席管理システム
１０…空席管理サーバ（情報処理装置）
２０…入力端末（施設端末）
３０…ユーザ端末
４０…店舗（施設）
５０…ネットワーク

Claims

施設の空き状況を示す空き情報を配信する情報処理装置であって、
施設に関する施設情報を記憶する記憶手段と、
第１のユーザ端末から送信された前記施設の空き情報を取得する取得手段と、
前記施設情報に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を、第２のユーザ端末に送信するか、前記施設に対応する施設端末に送信するかを決定する決定手段と、
前記決定手段による決定に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を前記第２のユーザ端末に送信する送信手段と、を備える情報処理装置。
前記記憶手段は、前記施設情報として、前記施設ごとに設定された、前記第１のユーザ端末から送信された前記空き情報による上書きの可否に関する上書き可否情報を記憶し、
前記決定手段は、前記上書き可否情報に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を、前記第２のユーザ端末に送信するか、前記施設端末に送信するかを決定する、請求項１に記載の情報処理装置。
前記取得手段は、前記施設端末から前記施設に対応する空き情報を取得し、
前記決定手段は、前記施設端末の種別に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を、前記第２のユーザ端末に送信するか、前記施設端末に送信するかを決定する、請求項１又は２に記載の情報処理装置。
前記決定手段は、前記施設端末から送信された前記空き情報を第１の空き情報とし、前記第１のユーザ端末から送信された空き情報を第２の空き情報とし、前記施設情報が前記第２の空き情報による上書きを受け付けられることを示し、かつ、前記第１の空き情報の受信日時よりも前記第２の空き情報の受信日時の方が現在時刻に近い場合には、前記第２の空き情報を前記施設の空き情報として前記第２のユーザ端末に送信すると決定する、請求項１に記載の情報処理装置。
前記決定手段は、前記第１の空き情報と前記第２の空き情報との組み合わせに基づいて、前記第２の空き情報を前記施設の空き情報とするか否かを決定する、請求項４に記載の情報処理装置。
前記決定手段は、前記第１の空き情報と前記第２の空き情報とが２段階以上異なる場合に、前記第２の空き情報を前記施設の空き情報として前記第２のユーザ端末に送信すると決定する、請求項５に記載の情報処理装置。
前記記憶手段は、前記施設ごとに設定された固定時間と、前記固定時間に対応する固定空き情報とを含む固定情報を記憶し、
前記決定手段は、現在時刻が前記固定時間に含まれる場合には、前記固定空き情報を前記施設の空き情報として前記第２のユーザ端末に送信し、前記第２の空き情報を前記施設の空き情報として前記第２のユーザ端末に送信しない、請求項４～６のいずれか１項に記載の情報処理装置。
前記決定手段は、前記施設端末が、前記施設に所属する者が手動で前記空き状況を入力する入力端末である場合、前記第１のユーザ端末から送信された前記施設の空き情報を前記第２のユーザ端末に送信し、
前記施設端末が、前記施設に設置され、前記施設の前記空き状況を自動で検出する装置である場合、前記第１のユーザ端末から送信された前記施設の空き情報を前記施設端末に送信する、請求項３に記載の情報処理装置。
コンピュータを、請求項１～８のいずれか１項に記載の情報処理装置として機能させるプログラム。
情報処理装置により実行される情報処理方法であって、
施設に関する施設情報を記憶することと、
第１のユーザ端末から送信された、前記施設の空き状況を示す空き情報を取得することと、
前記施設情報に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を、第２のユーザ端末に送信するか、前記施設に対応する施設端末に送信するかを決定することと、
前記決定に応じて、前記第１のユーザ端末から送信された前記施設の空き情報を前記第２のユーザ端末に送信することと、を含む情報処理方法。