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

Description

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

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

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

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

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

上記課題を解決するために、本開示の情報処理装置は、施設のリアルタイムな空き状況を示す空き情報を配信する情報処理装置であって、ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報が所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

店舗ＩＤ１４２１は、データベース１４１内で各店舗を識別するためのＩＤである。緯度経度１４２６は、店舗の位置を緯度経度によって示すデータであり、同じ施設の同じフロアであっても、店舗の位置が異なる場合は異なる緯度経度の値が登録されている場合もある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（ステップＳ２０５）
判定部１１３は、ステップＳ２０４において取得したユーザ投稿に基づいて、第２の空き情報を設定するか否かを判断する。具体的には、判定部１１３は、取得したユーザ投稿のうち最多の空き情報の数が所定数（例えば、５つ）以上であるか否かを判断し、所定数以上である場合、最多の空き情報を第２の空き情報として設定し、ＲＡＭ１３又は記憶装置１４に格納する。また、判定部１１３は、最多の空き情報を示すユーザ投稿のうち、最新の（最も現在時刻に近い）受信日時を、第２の空き情報の受信日時として設定する。判定部１１３は、最多の空き情報の数が所定数未満である場合、第２の空き情報を設定せずに、処理はステップＳ２０８に移行する。

ここで、最多の空き情報が複数あり、それらの数が所定数以上である場合（例えば、「空きあり」が５つであり「やや混雑」も５つである場合）には、いずれか一方の空き情報を第２の空き情報として設定することができる。この場合、いずれの空き情報を第２の空き情報として設定するかは、ランダムで決定してもよいし、所定の優先度にしたがって決定してもよい。例えば、より空席が多い方の空き情報を第２の空き情報として設定すれば、よりユーザが店舗４０を訪れやすくなる。一方、より混雑度が高い方の空き情報を第２の空き情報として設定すれば、ユーザがより空いている店舗に訪れるための参考にすることができる。

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

（ステップＳ２０７）
判定部１１３は、最多のユーザ投稿の数が所定数以上であるため第２の空き情報が設定され（ステップＳ２０５）、第２の空き情報（ユーザ投稿）の方が第１の空き情報よりも最新である（ステップＳ２０６）場合、第２の空き情報は店舗のリアルタイムな空き情報として信頼できるため、第２の空き情報を、照会リクエストを送信したユーザ端末３０に配信すると決定する。換言すれば、配信すべき空き情報のステータスを、第２の空き情報で上書きする。

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

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

店舗４０からの空き情報の送信が漏れていたり、誤っていたりすることで、正確な空き情報がユーザに配信されない場合がある。これに対し、本実施形態のように、現在時刻から所定時間以内に投稿されたユーザ投稿の数が所定数以上であり、当該ユーザ投稿の方が第１の空き情報よりも最新であるとみなせる場合には、ユーザ投稿を用いて空き情報を配信することで、より正確な空き情報を配信することができる。つまり、第１のユーザ端末から送信された第１の店舗の空き情報が、第２のユーザ端末上に、第１の店舗の空き情報として表示されることがある。その一方で、第２の店舗の空き情報に関しては、第１のユーザ端末から空き情報が送信されても、第２のユーザ端末には第２の空き情報として表示されないことがある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜第１の実施形態のまとめ＞
第１の実施形態に係る空席管理システム１において、ユーザ端末３０から空き情報の検索リクエストを空席管理サーバ１０に送信すると、空席管理サーバ１０は、検索リクエストに応答してユーザ端末３０の位置に基づいて店舗群（ユーザが入力した検索条件に合致する店舗の集合）を特定し、それらの空き情報を店舗情報と共にユーザ端末３０に送信する。このとき、空席管理サーバ１０は、現在時刻から所定時間以内に所定数以上のユーザ端末３０から同じ空き情報が送信されている場合に、当該空き情報を第２の空き情報として設定し、第２の空き情報が所定の条件を満たす場合は、第２の空き情報をユーザ端末３０に配信すべき空き情報として決定する。これにより、店舗４０の入力端末２０から最後に送信された空き情報が現状とは異なっていたとしても、より信頼性が高いユーザ投稿が配信されるため、ユーザは、正確な空き情報を参照することができる。

＜第１の実施形態の変形例＞
第１の実施形態では、現在時刻から所定時間以内に投稿されたユーザ投稿の数が所定数以上である場合には、ユーザ投稿を第２の空き情報として設定することを説明した。追加的に又は代替的に、現在時刻から所定時間以内に投稿されたユーザ投稿の割合が、所定の割合（例えば、５０％）以上である場合に、ユーザ投稿を第２の空き情報として設定するようにしてもよい。例えば、現在時刻から所定時間以内のユーザ投稿が１０個あり、そのうち「空きあり」が４つ、「やや混雑」が３つ、「満席」が３つといったように、投稿された空き情報にばらつきがあることもある。そこで、ある店舗の空き情報の投稿として、所定数以上に加えて、所定時間以内のユーザ投稿の数に占める最多の空き情報の投稿数が所定の割合以上であることを条件とする。この場合、上記例では最多の空き情報の数が４であり、所定時間以内の投稿が１０個なので、割合は４０％となり、５０％以上という条件を満たさない。したがって、ユーザ投稿による第２の空き情報は設定されないことになる。このように、ユーザ投稿のばらつきが小さい場合にのみ店舗の空き情報として配信できるようにすることで、より正確な空き情報を配信することができる。

別の形態では、本実施形態の技術は、入力端末２０を有しない（第１の空き情報が送信されない）店舗の空き情報についても、適用することができる。この場合、判定部１１３は、図７のステップＳ２０１、Ｓ２０３～Ｓ２０５、Ｓ２０７及びＳ２０９のみを実行すればよい。つまり、店舗４０自身から空き情報が送信されることがない場合においても、事前に店舗情報のみ店舗情報データベース１４２に登録しておく。そして、現在時刻から所定時間以内に所定数のユーザから同じ空き情報が送信された場合には、その店舗の配信すべき空き情報としてユーザから送信された情報を採用し、他のユーザに配信する。一方、第２の空き情報が設定されない（所定数以上の空き情報を示すユーザ投稿がなかった）場合、空き情報を配信しないか、又は、空き情報の代わりに、店舗名やジャンルなどの店舗情報や、営業中か否かを示すテキストを地図上に表示するようにすればよい。これにより、ユーザは、入力端末２０を有しない店舗の空き情報についても参照することができる。

別の形態では、判定部１１３は、ユーザ端末３０に公開される店舗の空き情報としてはあくまで第１の空き情報を用いることを基本としつつ、第２の空き情報が設定されたら、第２の空き情報が第１の空き情報とは異なる場合にのみ、店舗４０の入力端末２０に空き情報の更新を促す通知を送信するようにしてもよい。また、第２の空き情報が第１の空き情報と同じで第２の空き情報の受信日時の方が第１の受信日時よりも新しい場合には、更新部１１２により、第１の空き情報の受信日時を第２の空き情報の受信日時に更新するようにしてもよい。

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

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

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

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

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

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

［第２の実施形態］
上述の第１の実施形態では、ステップＳ２０３において、店舗のジャンルにかかわらず、同じ所定時間以内のユーザ投稿を取得することを説明した。しかしながら、店舗のジャンルに応じて顧客の回転率が異なるため、空き状況の変動のしやすさも異なる。そこで、第２の実施形態では、店舗のジャンルに応じて異なる所定時間を設定する技術を提案する。

＜データベースの構成例＞
図１２は、空席管理サーバ１０が実行する、第２の実施形態に係る店舗情報データベース２４２を示す図である。図１２に示すように、店舗情報データベース２４２は、所定時間２４２１をさらに構成項目として有している点で、第１の実施形態の店舗情報データベース１４２と異なっている。所定時間２４２１は、入力端末２０の設定画面から店員が入力し空席管理サーバ１０に送信するようにしてもよいし、空席管理システム１の提供者が店舗のジャンルに応じた値（デフォルト値）を予め店舗情報データベース２４２に入力するようにしてもよい。

例えば、店舗のジャンルが飲食店である場合には、所定時間を３０分とすることができ、店舗のジャンルが博物館、美術館、観光施設、美容院などの場合には、所定時間を１時間とすることができる。また、飲食店の中でもさらにジャンル分けすることがでる。例えば居酒屋、レストラン、カフェなど、回転率が低い飲食店の場合、所定時間を３０分とし、ファーストフード店、ラーメン屋、回転寿司店など、回転率が高い飲食店の場合、所定時間を１５分とすることができる。また、例えば、複数窓口のある自治体や銀行など、回転率が高い施設においても、所定時間を１５分とすることができる。別の形態では、ジャンルが同じであっても、店舗の住所に応じて所定時間を異ならせてもよい。例えば、人通りの多い駅前のカフェの場合には空き状況が変わりやすいため所定時間を短く設定し、人通りの少ない駅から離れたカフェは空き状況が急に変動することは少ないため所定時間を長く設定することができる。このように、店舗ごとの回転率や店舗付近の人通りの多さ等に応じて所定時間を設定することができる。

別の形態では、同じ店舗４０においても、異なる時間帯で異なる所定時間を設定できるようにしてもよい。例えば、ランチタイムにおいて回転率が高く、ディナータイムにおいて回転率が低い場合には、所定時間を、ランチタイムについては短く設定し、ディナータイムについては長く設定することができる。

＜配信すべき空き情報の決定方法＞
図１３は、第２の実施形態における配信すべき空き情報の決定方法のフローチャートである。本実施形態では、ステップＳ２０２とＳ２０３の間に、判定部１１３によりステップＳ５０１が実行される点で、第１の実施形態と異なっている。ステップＳ２０１～Ｓ２０９については第１の実施形態と同じであるため、説明を省略する。

（ステップＳ５０１）
ステップＳ２０２の後、判定部１１３は、店舗情報データベース２４２を参照して、処理対象店舗の所定時間２４２１を取得し、ＲＡＭ１３又は記憶装置１４に格納する。そして、判定部１１３は、ステップＳ２０３において、ステップＳ２０２で取得した所定時間２４２１以内のユーザ投稿があるか否かを判断する。なお、所定時間２４２１を取得する本ステップ５０１は、処理対象店舗についてのユーザ投稿を取得するステップＳ２０４より前に実行されればよく、ステップＳ２０１の後に実行されてもよい。

＜第２の実施形態のまとめ＞
回転率が高い施設について、ユーザ投稿を抽出するための所定時間が長いと、抽出したユーザ投稿の空き情報にばらつきが大きくなってしまうこともある。これに対し、第２の実施形態のように、施設の回転率に応じて、ユーザ投稿を抽出するための所定時間を変動させることにより、抽出されるユーザ投稿の空き情報のばらつきを小さくすることができるため、より信頼性の高いリアルタイムの空き情報を配信することができる。

［第３の実施形態］
第１の実施形態においては、ステップＳ２０５において、店舗４０の規模にかかわらず、所定数とユーザ投稿の数とを比較することを説明した。しかしながら、店舗４０の収容キャパシティや店舗４０の立地によっては、ユーザ投稿を利用する効果が得られにくくなる場合がある。例えば、人通りの多い地域にある店舗は付近にいるユーザも多い分、所定数を比較的高く設定した方がより正確に空き情報を決定できる。一方で、人の少ない地域にある店舗は付近にいるユーザが少ないので、所定数を高く設定するとユーザ投稿を第２の空き情報と設定することができず、ユーザに配信することができなくなる。あるいは、店舗内のキャパシティが多く待機中の人が多い場合は、その分、空き状況を投稿するユーザが増えるが、店舗内のキャパシティが少ない場合は、店舗の空き状況を投稿してくれるユーザは少ない傾向にある。そこで、第３の実施形態では、店舗ごとに所定数を設定する技術を提案する。

＜データベースの構成例＞
図１４は、第３の実施形態に係る店舗情報データベース３４２を示す図である。図１４に示すように、店舗情報データベース３４２は、店舗４０のキャパシティ３４２１をさらに構成項目として有している点で、第１の実施形態の店舗情報データベース１４２と異なっている。キャパシティ３４２１は、入力端末２０の設定画面から店員が入力し空席管理サーバ１０に送信するようにしてもよいし、空席管理システム１の提供者が店舗の規模に応じた値（デフォルト値）を予め店舗情報データベース３４２に入力するようにしてもよい。

図１５は、第３の実施形態に係る住所データベース３４５を示す図である。住所データベース３４５は、データベース１４１に格納される。図１５に示すように、住所データベース３４５は、住所３４５１及び人通りの分類３４５２を構成項目として有している。住所３４５１は、例えば、都道府県、市区町村、区画（字）を含む。人通りの分類３４５２は、人通りの多いと見込まれる地域を「地域Ａ」とし、人通りが平均的な地域を「地域Ｂ」とし、人通りが少ないと見込まれる地域を「地域Ｃ」とする。人通りの分類３４５２は、空席管理システム１の提供者が予め住所３４５１ごとに人通りの多さを分類し、住所データベース３４５に記憶させることができる。

＜配信すべき空き情報の決定方法＞
図１６は、第３の実施形態における配信すべき空き情報の決定方法のフローチャートである。本実施形態では、ステップＳ２０３とＳ２０４の間に、ステップＳ６０１が実行される点で、第１の実施形態と異なっている。ステップＳ２０１～Ｓ２０９については第１の実施形態と同じであるため、説明を省略する。

（ステップＳ６０１）
判定部１１３は、店舗情報データベース３４２及び住所データベース３４５を参照して、ステップＳ２０５で用いる所定数を設定し、ＲＡＭ１３又は記憶装置１４に格納する。

＜所定数の決定方法＞
図１７は、第３の実施形態のステップＳ６０１における所定数の決定方法のフローチャートである。

（ステップＳ７０１）
判定部１１３は、店舗情報データベース３４２を参照して、処理対象店舗の住所１４２５と、キャパシティ３４２１とを取得し、ＲＡＭ１３又は記憶装置１４に格納する。

（ステップＳ７０２）
判定部１１３は、処理対象店舗のキャパシティが１００人以上であるか否かを判断する。キャパシティが１００人以上である場合（Ｙｅｓ）、処理はステップＳ７０８に移行する。キャパシティが１００人未満である場合（Ｎｏ）、処理はステップＳ７０３に移行する。

（ステップＳ７０３）
判定部１１３は、住所データベース３４５を参照して、処理対象店舗のキャパシティが５０人以上であり、かつ、処理対象店舗の住所が地域Ａであるか否かを判断する。キャパシティが５０人以上であり、かつ地域Ａである場合（Ｙｅｓ）、処理はステップＳ７０８に移行する。キャパシティが５０人未満であるか、又は地域Ａでない場合（Ｎｏ）、処理はステップＳ７０４に移行する。

（ステップＳ７０４）
判定部１１３は、処理対象店舗のキャパシティが５０人以上であり、かつ、処理対象店舗の住所が地域Ｂ又はＣであるか否かを判断する。キャパシティが５０人以上であり、かつ地域Ｂ又はＣである場合（Ｙｅｓ）、処理はステップＳ７０７に移行する。キャパシティが５０人未満であるか、又は地域Ｂ又はＣでない場合（Ｎｏ）、処理はステップＳ７０５に移行する。

（ステップＳ７０５）
判定部１１３は、処理対象店舗のキャパシティが１０～５０人であり、かつ、処理対象店舗の住所が地域Ａであるか否かを判断する。キャパシティが１０～５０人であり、かつ地域Ａである場合（Ｙｅｓ）、処理はステップＳ７０７に移行する。キャパシティが１０～５０人未満であるか、又は地域Ａでない場合（Ｎｏ）、処理はステップＳ７０６に移行する。

（ステップＳ７０６）
判定部１１３は、所定数を最小値（例えば３）に設定する。その後、所定数の設定処理は終了し、処理は上述のステップＳ２０５（図１６）に移行する。

（ステップＳ７０７）
判定部１１３は、所定数を中間値（例えば５）に設定する。その後、所定数の設定処理は終了し、処理は上述のステップＳ２０５（図１６）に移行する。

（ステップＳ７０８）
判定部１１３は、所定数を最大値（例えば１０）に設定する。その後、所定数の設定処理は終了し、処理は上述のステップＳ２０５（図１６）に移行する。

＜第３の実施形態のまとめ＞
以上のように、第３の実施形態においては、判定部１１３は、処理対象店舗のそれぞれの住所及びキャパシティに応じて、所定数を設定する（ステップＳ６０１（ステップＳ７０１～Ｓ７０８））。このとき、キャパシティが大きい（１００人以上）店舗の場合、地域性にかかわらず、所定数は大きく設定される（最大値）。キャパシティが小さい（１０人未満）店舗の場合、地域性にかかわらず、所定数は小さく設定される（最小値）。それ以外の場合、キャパシティと地域性に応じて、所定数が設定される。設定された所定数は、ステップＳ２０５において、現在時刻から所定時間以内のユーザ投稿の数と比較され、ユーザ投稿が所定数以上であれば、ユーザ投稿が第２の空き情報として設定される。これにより、ユーザ投稿が多数見込める店舗に関しては、所定数を比較的大きくすることでユーザ投稿による空き情報の決定の精度を高くすることができる。ユーザ投稿が多数見込めない店舗であっても、所定時間内に複数のユーザから空き情報（ユーザの位置が近い場合にのみ投稿ができる）が投稿されている場合に限り、店舗の空き情報として採用されるので、ユーザ端末３０に配信される空き情報の信頼性を保つことができる。

＜第３の実施形態の変形例＞
第３の実施形態では、店舗のキャパシティ及び住所（地域性）に応じて、所定数を設定することを説明した。別の形態では、店舗ごとに、店舗に対応する所定数を予め設定し、店舗情報データベース１４２に記憶しておくようにすることができる。さらに別の形態では、各店舗に対応する所定数は、店舗に対応する変数に応じて、その都度（ステップＳ６０１）算出するようにしてもよい。さらにまた別の形態では、店舗のキャパシティ及び住所だけでなく、日時に応じても、所定数を設定することができる。例えば、郊外にあるスタジアムでイベントがある日は、イベントの終了後、スタジアム付近の飲食店の混雑が予想される。また、例えば、普段は人通りの少ない川沿いで花火大会が開催される場合、花火大会に出店する屋台についても、混雑が予想される。このような場合、店舗や施設のキャパシティと住所だけに基づいて所定数を設定すると、適切な空き情報を配信できなくなる可能性がある。そこで、イベントのある日時には所定数を大きく設定し、イベントのない日時には所定数を小さく設定することで、より適切な空き情報を配信することができる。

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

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

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

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

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

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

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

Claims (11)

1. 施設のリアルタイムな空き状況を示す空き情報を配信する情報処理装置であって、
   ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、
   前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報が所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える情報処理装置。
2. 前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に含まれる空き情報のうち最大数の空き情報の数を前記所定数と比較する、請求項１に記載の情報処理装置。
3. 前記取得手段は、前記施設に対応する施設端末から送信された前記施設の前記空き情報を第１の空き情報として取得し、
   前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に基づいて第２の空き情報を決定し、前記第１の空き情報及び前記第２の空き情報のいずれかを、前記配信すべき前記空き情報として決定する、請求項１に記載の情報処理装置。
4. 前記決定手段は、前記取得手段が前記ユーザ端末から前記空き情報を取得していても、前記所定時間内に前記所定数以上の同じ前記空き情報を取得していない場合には、前記第１の空き情報を前記配信すべき前記空き情報として決定する、請求項３に記載の情報処理装置。
5. 施設に関する施設情報を記憶する記憶手段と、
   前記施設情報に基づいて前記所定時間を設定する第１の設定手段と、をさらに備える請求項１～４のいずれか１項に記載の情報処理装置。
6. 前記第１の設定手段は、前記施設のジャンル情報に基づいて前記所定時間を設定する、請求項５に記載の情報処理装置。
7. 施設に関する施設情報を記憶する記憶手段と、
   前記施設情報に基づいて前記所定数を設定する第２の設定手段と、をさらに備える請求項１～６のいずれか１項に記載の情報処理装置。
8. 前記第２の設定手段は、前記施設が収容可能な人数を示すキャパシティ情報に基づいて前記所定数を設定する、請求項７に記載の情報処理装置。
9. 前記第２の設定手段は、前記施設の位置に関する情報に基づいて前記所定数を設定する、請求項７に記載の情報処理装置。
10. コンピュータを、請求項１～９のいずれか１項に記載の情報処理装置として機能させるプログラム。
11. 情報処理装置により実行される情報処理方法であって、
    ユーザ端末から送信された、施設の空き状況を示す空き情報を取得することと、
    前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報が所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定することと、を含む情報処理方法。

Images