JP7253170B2 - 施設状況管理装置、及び施設状況管理方法 - Google Patents

Description

本開示は、施設状況管理装置、及び施設状況管理方法に関する。

飲食店などの施設の混雑状況の情報を、ユーザがオンラインで確認できるようにするための技術が、例えば特許文献１により知られている。

しかし、特許文献１等の従来のシステムは、単に施設の混雑状況に関する情報を提供するに止まり、所望の施設が許容可能な待ち時間で利用できるのか否かを判断するのに十分な情報をユーザに対しタイミング良く提供するものではない。このため、従来のシステムにおいては、ユーザは、何度もシステムを閲覧するなどする必要があり、また、所望の施設を利用するタイミングを逸することがあった。

特開２０１９－７０９０３号公報

本開示は、このような状況に鑑みてなされ、ユーザに施設が所望の混雑状況になったことを適切に通知することを可能とした施設状況管理装置、施設状況管理方法を提供することを目的とする。

上記課題を解決するために、本開示に係る施設状況管理装置は、ユーザ端末から、施設が指定の混雑状況になった場合に通知を希望する旨の通知リクエストを受信すると共に、施設用端末から、前記施設の混雑状況を示すステータス情報を受信する受信部と、前記通知リクエストに従い、前記通知をする条件を、前記施設及び前記ユーザ端末を特定する情報と共に管理する施設状況管理部と、前記施設の最新の前記ステータス情報が、前記条件と合致した場合に、前記ユーザ端末に対し前記施設に関する情報を通知する通知部とを備え、前記通知リクエストは、前記施設に関して配信されうるステータス情報を選択肢として前記ユーザ端末に表示された設定画面を介して選択された、前記施設に関して配信され得るステータス情報のうち、少なくとも１つのステータス情報の指定を含む。

本開示の技術によれば、ユーザが所望する混雑状況になったことを適切にユーザに通知することが可能になる。

第１の実施の形態に係る施設状況管理装置１０の構成を説明する概略図である。 施設状況管理サーバ２００のハードウェア構成例を示す図である。 施設状況管理サーバ２００の機能構成例を示すブロック図である。 施設状況管理サーバ２００により生成される通知テーブルの一例を示す。 施設管理用情報端末５００のハードウェア構成例を示す図である。 施設管理用情報端末５００の機能構成例を示すブロック図である。 データベース２４１に格納され管理されている施設状況管理テーブルの構成例を示す図である。 第１の実施の形態に係る施設状況管理装置１０の動作を説明するフローチャートである。 ユーザ端末３００における、検索結果の表示画面の一例を示す。 ユーザ端末３００において通知リクエストを設定するための設定画面の一例を示す。 ステップＳ５の通知の要否判定の詳細な手順の一例を示すフローチャートである。 ユーザ端末３００に通知リクエストに基づく通知がされた場合における表示画面の一例を示す。 第１の実施の形態の変形例の動作を説明するフローチャートである。 第２の実施の形態に係る施設状況管理装置１０の構成を説明する概略図である。 第２の実施の形態における、施設設置端末７００の外観構成の一例と、動作の概要を説明する概略図である。 施設状況管理サーバ２００において管理される行列テーブルの一例である。 第２の実施の形態における、ユーザ端末３００のディスプレイに表示される通知リクエスト設定画面の一例である。 第２の実施の形態における、通知リクエスト設定画面の別の表示例である。 第２の実施の形態における、施設状況管理サーバ２００により生成される通知テーブルの一例を示す。 第２の実施の形態における、ユーザ端末３００に通知リクエストに基づく通知がされた場合における表示画面の一例を示す。 第２の実施の形態における、施設管理用情報端末５００で生成される施設状況管理テーブルの一例を示す。 第２の実施の形態における、ステップＳ５（図６）の通知の要否判定の詳細な手順の一例を示すフローチャートである。 第３の実施の形態に係る施設状況管理装置１０を説明する表示画面の一例である。 第３の実施の形態に係る施設状況管理装置１０を説明する表示画面の一例である。

以下、添付図面を参照して本実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本開示の原理に則った実施形態を示しているが、これらは本開示の理解のためのものであり、決して本開示を限定的に解釈するために用いられるものではない。本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味においても限定するものではない。

本実施形態では、当業者が本開示を実施するのに十分詳細にその説明がなされているが、他の形態も可能で、本開示の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

［第１の実施の形態］
図１の概略図を参照して、第１の実施の形態に係る施設状況管理装置の構成を説明する。第１の実施の形態の装置は、施設の混雑状況を管理し、その情報を配信する装置である。ここで施設とは、カフェやレストランなどの飲食店、スーパーマーケットや薬局などの小売店、自治体や銀行の窓口、図書館や美術館など、利用者の数によって混雑している状況が変化するような施設である。また、混雑状況とは、人の多さや席の利用率を示し、空き状態や空き状況と言い換えることもできる。以下の形態では、施設として飲食店などの店舗を例とする。

施設状況管理装置１０は、施設の混雑状況（空席の有無、席の利用率、利用者の数などその他）に関する情報（ステータス情報）を管理する装置であり、一例として、施設状況管理サーバ２００（情報処理装置）と、ユーザ端末３００と、施設４００と、カメラ６００を備える。図１では、図示の簡単化のため、一のユーザ端末３００、及び一の施設４００のみが図示されているが、複数のユーザ端末、複数の施設があっても良い。施設４００には、施設４００の混雑状況その他を管理するための施設管理用情報端末５００（例えばタブレット、スマートフォンなど）が設置される。施設状況管理サーバ２００、ユーザ端末３００、及び施設管理用情報端末５００は、ネットワークＮＷを介してデータを送受信可能に構成されている。

施設状況管理サーバ２００は、施設４００の外、例えば本装置を運営する管理会社に設置され、施設４００（店舗等）の混雑状況に関する情報（ステータス情報）を管理する。また、施設状況管理サーバ２００は、ユーザ端末３００から、ある施設の混雑状況が所定の状況（例えば、待ちなしの状態）になったら通知が欲しい旨の要求(通知リクエスト)を受信し、通知テーブルを用いて管理する。そして、施設状況管理サーバ２００は、ステータス情報を管理するテーブルと通知リクエストを管理する通知テーブルとを照合し、施設４００がユーザの所望する混雑状況になったと判定された場合に、その旨の通知をユーザ端末３００に対し送付する。

ユーザ端末３００は、例えば、スマートフォン、タブレット、パーソナルコンピュータなどを含む、ネットワークＮＷと通信可能なデバイスであり、当該施設状況管理装置１０が運営する情報提供サービス事業のサービス享受者が使用する端末である。ユーザは、ユーザ端末３００を介して、通知リクエストの設定のための情報を入力するとともに、施設状況管理サーバ２００から施設４００に関する各種情報の提供を受ける。

施設管理用情報端末５００は、施設４００に設置され、施設４００の混雑状況に関する情報（ステータス情報）に関する各種情報を入力するための端末である。施設管理用情報端末５００は、例えば公知のタブレット、スマートフォン、パーソナルコンピュータの他、専用のＩｏＴ機器によっても構成することができる。施設管理用情報端末５００の操作者（施設４００の管理者等）は、目視で施設４００の混雑状況を確認し、またはカメラ６００で撮像された映像に基づいて店内の様子を確認する。そして、その確認の結果に従い、施設４００の混雑情報を施設管理用情報端末５００に入力する。施設管理用情報端末５００は、入力されたステータス情報と、施設管理用情報端末５００の情報端末ＩＤ（識別情報）とを含むデータを施設状況管理サーバ２０に送信する。

図２Ａは、施設状況管理サーバ２００のハードウェア構成例を示す図である。施設状況管理サーバ２００は、一例として、ＣＰＵ（Central Processing Unit）２１０、ＲＯＭ（Read Only Memory）２２０、ＲＡＭ（Random Access Memory）２３０、記憶装置２４０、及び通信装置２５０を備える。

ＣＰＵ２１０は、本装置を実現するコンピュータプログラムを実行することにより、施設状況管理サーバ２００が提供する機能を実現する。ＲＯＭ２２０とＲＡＭ２３０は、ＣＰＵ２１０が用いるデータを保持する。記憶装置２４０は、本装置を実現するコンピュータプログラムを格納する。通信装置２５０は、ネットワークＮＷを介してユーザ端末３００及び施設管理用情報端末５００と通信する。

図２Ｂは、施設状況管理サーバ２００の機能構成例を示すブロック図である。施設状況管理サーバ２００は、ＣＰＵ２１０が実行するソフトウェアモジュール（各種プログラムがＣＰＵ２１０の内部メモリに展開されて構成される機能）として、表示制御部２０１、」受信部２１１、施設状況管理部２１２、検知部２１３、判定部２１４、及び通知部２１５を備える。以下では記載の便宜上、これらモジュールを動作主体として記載する場合があるが、実際にこれらモジュールを実行するのはＣＰＵ２１０であるため、ＣＰＵ２１０を動作主体とすることもできる。記憶装置２４０は、データベース２４１を格納している。データベース２４１は、施設４００のステータス情報を管理する。データベース２４１の構成については後述する。

表示制御部２０１は、ユーザ端末３００のディスプレイに表示される各種画面の表示を、取得されたデータ等に基づいて制御する機能を有する。また、受信部２１１は、通信装置２５０を介して、施設４００のステータス情報を含むデータを施設管理用情報端末５００から受信する。また受信部２１１は、通信装置２５０を介して、ユーザ端末３００から施設４００の検索要求、施設４００の利用申し込み、及び施設４００の通知リクエストを受信する。

施設状況管理部２１２は、受信部２１１がステータス情報とともに受信した情報端末ＩＤ（識別情報）に基づいて施設４００を特定し、データベース２４１における施設４００のステータス情報を更新する。また、施設状況管理部２１２は、ユーザ端末３００から受信した通知リクエストに従い、ユーザに対し通知をする条件を、施設４００を特定する施設ＩＤ、及びユーザを特定するユーザＩＤ（及び／又はユーザ端末３００を特定する端末ＩＤ）と共に管理する通知テーブルを生成する。図３は、通知テーブルの一例を示す図である。通知テーブルは、一例として、複数の通知リクエストの各々に基づき、通知を受領する条件（通知条件）を、受付日時、ユーザＩＤ、端末ＩＤ、施設ＩＤ、時間帯と関連付けて記憶するデータベースである。すなわち、この通知テーブルは、どのユーザが、どの施設を、どのような混雑状況であれば利用したいと考えているかに関する情報を含むデータベースである。

検知部２１３は、例えば、営業中に施設管理用情報端末５００からデータを所定時間（例えば２時間）受信していない場合に、施設管理用情報端末５００が電源ＯＦＦ状態である可能性、通信不能、又は故障の可能性があることを検知する。

判定部２１４は、前述のステータス情報と通知リクエスト（通知テーブル）とを照合し、施設４００のステータス情報が、各通知リクエストに示される条件に合致するか否かを判定する。施設４００のステータス情報が通知リクエストに示される条件に合致していると判定される場合、通知部２１５は、表示用ＵＩデータと共に対象のユーザ端末３００にその旨の情報を送信する。これらのデータを受信したユーザ端末３００は、表示用ＵＩを構築し、そこに当該ステータスを表示する。

図４Ａは、施設管理用情報端末５００のハードウェア構成例を示す図である。施設管理用情報端末５００は、一例として、ＣＰＵ（Central Processing Unit）５１０、ＲＯＭ（Read Only Memory）５２０、ＲＡＭ（Random Access Memory）５３０、記憶装置５４０、通信装置５５０、入力装置５６０、及び出力装置５７０を備える。

ＣＰＵ５１０は、施設管理用情報端末５００に含まれる各構成（５２０～５７０）の動作を制御する。ＲＯＭ５２０とＲＡＭ５３０は、ＣＰＵ５１０が用いるデータを保持する。記憶装置５４０は、施設管理用情報端末５００を動作させるためのプログラムを格納する。

通信装置５５０は、ネットワークＮＷを介して施設状況管理サーバ２００と通信する。入力装置５６０は、キーボード、テンキー、マウス、タッチパネルなどによって構成され、施設４００の管理者がデータや指示、及び設定情報を入力するために用いられる。一例として、入力装置５６０は、施設の混雑状況を示す施設状況データを入力するのに用いられる。出力装置５７０は、プリンタ、ディスプレイ、スピーカなどによって構成され、ＣＰＵ５１０が生成した画面やデータを出力（表示）する。

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

制御部５１１は、例えば、記憶装置５４０から施設管理用情報端末５００の管理画面構成データを読み出し、後述する管理画面を生成して入出力部５１４を介して出力装置５７０のディスプレイに出力（表示）する。また、制御部５１１は、施設４００の管理者が入力装置５６０を用いて入力した指示を、入出力部５１４を介して取得し、それに応答して、ディスプレイ上の管理画面に入力された情報を表示させる。

さらに、制御部５１１は、施設管理用情報端末５００から入力装置５６０を介して施設４００のステータス情報が入力されると、記憶部５１２を介してＲＡＭ５３０及び記憶装置５４０に、当該ステータス情報を入力日時のデータとともに格納する。そして、制御部５１１は、通信部５１３を介して、当該ステータス情報及び施設管理用情報端末５００の識別情報ＩＤ（シリアルＩＤ：例えばＭＡＣアドレス）を施設状況管理サーバ２００に送信する。

記憶装置５４０に混雑状態を示すデータ（ステータス情報）が格納されている場合において、管理者によってステータス情報の更新が所定時間無かったときには、制御部５１１は、記憶部５１２を介して記憶装置５４０から最新のステータス情報を取得して、施設状況管理サーバ２００に再度送信することができる。

管理画面は、施設管理者が施設状況管理サーバ２００に対して指示を与えるために用いる画面であり、例えばＷｅｂアプリケーションの形式で提供することができる。Ｗｅｂアプリケーションは、施設状況管理サーバ２００によって生成され、施設管理用情報端末５００に送信され、出力装置５７０の表示画面上に表示される。

また、施設状況管理サーバ２００から情報が通知されると、制御部５１１は、通信部５１３及び入出力部５１４を介して当該情報を取得し、出力装置５７０の表示部に情報を出力（表示）する。

図５は、データベース２４１に格納され管理されている施設状況管理テーブルの構成例を示す図である。なお、本実施形態では、データベース２４１はテーブル形式で表されているが、この形式に限らず、各データが紐付けされていればどのような形式で構築してもよい。

施設状況管理データベース（施設状況管理テーブル）２４１０は、ユーザが施設４００を検索するとき用いる属性情報と施設ごとの最新のステータス（空席の有無、その他）を管理するデータテーブルである。施設状況管理データベース２４１０は、施設ごとに、例えば、施設ＩＤ２４１１と、情報端末ＩＤ２４１２と、名称２４１４と、ジャンル２４１５と、施設紹介２４１６と、所在地２４１７と、連絡先（電話番号など）２４１８と、最新空席情報２４１９とを構成項目として有している。施設状況管理テーブルの１つのレコードは、１つの施設４００の状態を示したものであり、施設状況管理データベース２４１０は、施設の各々の状態をレコードとして管理する。なお、施設状況管理データベース２４１０の構成項目は、図示の例には限定されない。図示の例以外にも、例えば施設の緯度／経度、営業時間、価格帯などの項目を含むことができる。

施設ＩＤ２４１１は、データベース２４１内で各施設を識別するためのＩＤである。情報端末ＩＤ２４１２は、施設ＩＤ２４１１に対応する施設の施設管理用情報端末５００を識別するためのＩＤであり、例えば通信部（通信モジュール）５１３のＭＡＣアドレスである。最新空席情報２４１９は、施設ＩＤ２４１１に対応する施設の最新の混雑状態（空席状態とも言える）を示す。

施設状況管理部２１２は、施設管理用情報端末５００から受け取った、施設４００ステータス情報を最新空席情報２４１９として格納する。施設管理用情報端末５００の管理画面に何もステータス情報が入力されていない場合には、空席情報２４１９はその旨を示す値（例えば空欄、ＮＵＬＬなど）とされる。

次に、ユーザがユーザ端末３００において施設を検索し、その混雑情報を閲覧した際に、ユーザ希望のステータスではない施設に対してユーザが通知希望をリクエストし、さらに施設の混雑情報が所望のステータスに変更された場合に通知をするまでの本装置１０の動作を説明する。図６は、シーケンス図である。また、動作の説明においては、図７～図１０も参照して説明する。なお、以下では各工程（ステップ）を「Ｓ」と表記することとする。

まずステップＳ１において、ユーザ端末３００が、施設状況管理サーバ２００に対して、混雑情報を閲覧する検索要求を送信する。検索要求は、一例として、施設の所在地、ジャンル、価格帯、利用日時等の検索条件や位置情報を含む。なお位置情報は、ユーザ端末３００に搭載されたＧＰＳ機能により取得可能な現在位置でも良いし、指定されたエリアなどでも良い。

ステップＳ２において、施設状況管理サーバ２００は、検索要求に含まれる検索条件や位置情報に基づいて施設状況管理テーブル２４１０から必要な情報を取得し、検索結果を示す表示画面に生成する。図７は、ステップＳ１の検索結果を、ユーザ端末３００において表示した検索結果表示画面の一例を示す。この表示画面では、検索された施設の付近の地図３０１により、その施設４００の位置がマップ形式で表示される。地図３０１においては、検索された施設４００の位置を示す記号（黒丸）３０２と、その施設４００の混雑状況を示す吹き出し３０３とが表示される。

地図３０１において、吹き出し３０３のいずれかが選択（タップ）されると、地図３０１の左側において、その吹き出し３０３に対応する施設４００に関する施設紹介カード３０４が表示される。既に表示済みの施設紹介カード３０４よりも、新たに選択した施設４００に関する施設紹介カード３０４を大きく表示することが可能である。また、図７に示すように、新たに選択した施設に関する施設紹介カード３０４には、星印マークを表示するなどして、選択がされたことを明示することができる。施設紹介カード３０４は、当該施設４００に関する情報（例えば所在地、現在の混雑状況など）の他、その施設４００に関して通知リクエストを設定するための通知リクエスト設定ボタン３０５を含む。ステップＳ３においてユーザ端末３００は、施設状況管理サーバ２００から受信した検索結果を表示する。

ステップＳ４において、通知リクエスト設定ボタン３０５がタップされることで、ユーザ端末３００は施設状況管理サーバ２００に対して通知リクエスト設定を指定した旨を送信する。この時ユーザ端末３００は、選択中の施設（通知リクエストの対象となる施設）の施設ＩＤも施設状況管理サーバ２００に向けて送信する。なお、来店ボタン３２０を押すことで、通知リクエストを設定することなく、来店の申し込みを行うことも可能である。来店ボタン３２０を押した場合、ユーザは、遅滞なく施設４００に向かい、施設４００の利用待ちの行列に並ぶ。「ビストロＡ」を利用したいが、現在は６０分待ちであり、もう少し混雑が少ないときに改めて利用したいと考え、そのような混雑が少な目になった場合に通知をもらいたいと考えるユーザは、通知リクエスト設定ボタン３０５を押して、通知リクエストを設定する。

ステップＳ５において施設状況管理サーバ２００の表示制御部２０１は、受信した施設ＩＤに基づいて対象の施設を特定し、施設状況管理テーブル２４１０を参照して設定画面を生成する。図８は、ユーザ端末３００において通知リクエストを設定するための設定画面の一例を示している。この設定画面は、図７の通知リクエスト設定ボタン３０５が押されることにより表示される。例えば、「ビストロＡ」の通知リクエスト設定ボタン３０５が押されると、図８の設定画面に移行する。この設定画面は、一例として、施設名表示領域３１１と、ステータス選択領域３１２と、時間帯設定領域３１３と、時刻指定ボタン３１４と、設定ボタン３１５とを備えている。

施設名表示領域３１１は、押された通知リクエスト設定ボタン３０５に対応する施設４００の名称（この場合は、「ビストロＡ」）を表示する表示領域である。また、ステータス選択領域３１２は、指定した施設４００がどのような混雑状況になった場合に施設状況管理サーバ２００からの通知を希望するかを選択するための選択肢を表示している。「ここでは一例として、「空き」、「やや混雑」、「混雑」、「満席」、「１０分待ち」、「３０分待ち」が表示され、少なくとも１つが選択可能（複数選択することも可能）とされている。このステータス選択領域３１２に表示されるステータス情報は、施設４００の混雑状態を示す情報として表示され得るステータス情報が選択肢となる。すなわち本実施形態では、施設４００は、「空き」、「やや混雑」、「混雑」、「満席」、「１０分待ち」、「３０分待ち」のいずれかを施設管理用情報端末５００から入力することができ、施設状況管理サーバ２００は、施設４００の混雑状態として「空き」、「やや混雑」、「混雑」、「満席」、「１０分待ち」、「３０分待ち」のいずれかを配信できる。以上の通り、ステータス選択領域３１２は、施設４００によって選択肢が異なる。ユーザは例えば、選択した施設４００が空いている（利用者が少ない）ときのみ訪問したい場合には、「空き」のみを選択する。また、施設４００が利用可能であれば訪問したいという場合には、「空き」「やや混雑」「混雑」を選択する。一方、「１０分程度は待っても良い」と考える場合には、「空き」、「やや混雑」、「混雑」、「満席」、「１０分待ち」の全てを選択することが可能である。

時間帯設定領域３１３は、当該施設４００を訪問したい時間帯を設定するための選択肢を表示する領域である。時間帯設定領域３１３は、施設４００に関する情報に基づいて生成された選択肢が表示されている。ここでは、訪問したい時間帯があれば、その時間帯を時間帯設定領域３１３において選択することができ、特になければ「指定なし」を選択することができる。時間帯を設定することで、設定された時間帯においてのみ、通知を受領することができる。なお、時間帯設定領域３１３における複数の選択肢は、１つだけでなく、複数通り選択することが可能である。更に、訪問時刻を具体的に指定したい場合には、時刻指定ボタン３１４を押すことができる。時刻指定ボタン３１４が押されると、時間帯設定領域３１３の時間表示が空欄とプロンプト表示に切り替わり、具体的な数字の入力が促される。なお、時間帯設定領域３１３は省略することもできる。また、施設管理用情報端末５００での設定により、施設毎に、時間帯設定領域３１３を表示するか否かを選択可能とすることもできる。

ステップＳ６においてユーザ端末３００は、設定画面に対するユーザの操作を受け付け、通知リクエストを設定する。図８の設定画面により、ユーザにより通知リクエストが設定されると、ユーザ端末３００は設定された情報（以下、設定情報と呼ぶ）を施設状況管理サーバ２００に送信する。

ステップＳ７において施設状況管理サーバ２００の施設状況管理部２１２は、設定された通知リクエストに関する設定情報を、図３のような通知テーブルに格納する。本実施形態では、施設状況管理部２１２は、通知リクエスト設定ボタン３０５を押された施設４００の施設ＩＤ、ステータス選択領域３１２において選択されたステータス情報、時間帯設定領域３１３において指定された時間帯、通知リクエストを受信した日時、通知リクエストに含まれるユーザＩＤ、通知リクエストを送信したユーザ端末の端末ＩＤを通知テーブルに追加する。

ステップＳ８において、施設４００の施設管理用情報端末５００からは、施設４００の混雑状況を示すステータス情報が入力される。また、ステップＳ９において施設管理用情報端末５００は、入力されたステータス情報を施設状況管理サーバ２００に送信する。

ステップＳ１０において施設状況管理サーバ２００の受信部２１１が受信したステータス情報を用いて、施設状況管理テーブル２４１０のステータス情報を更新する。このとき、ユーザ端末３００がステップＳ４において通知リクエスト設定した対象施設のステータス情報が、通知リクエストに含まれる通知希望のステータス情報に更新されたものとする。ステップＳ１１において施設状況管理サーバ２００の判定部２１４は、ステータス情報を通知すべき対象の通知リクエストがあるか否かを判定する。なお通知の要否判定処理の詳細は、後述する。なお、施設状況管理サーバ２００における通知判定処理は、毎分置きに実行するようにしても良いし、ステータス情報が変更された場合に実行するようにしても良い。

ステップＳ１１において判定部２１４がユーザ端末３００に対する通知が必要と判定した場合には、ステップＳ１２において施設状況管理サーバ２００は、ユーザ端末３００に対し、ユーザが利用を希望する施設４００についての混雑状況を通知する。

図９は、Ｓ１１において判定部２１４が実行する通知の要否判定の詳細な手順の一例を示すフローチャートである。ここでは、施設４００に関して毎分、通知の要否判定処理を実行するものとする。

判定部２１４は、現在の時刻が、その施設４００の営業時間内であるか否かを判定する（ステップＳ１１１）。ＹｅｓであればステップＳ１１２に移行し、Ｎｏであれば、ステップＳ１１は終了する（当該施設に関する通知は不要と判定され、通知は行われない）。

ステップＳ１１２では、通知テーブルに、当該施設４００に関する通知リクエストが含まれているか否かを判定する。具体的には、図３の通知テーブルに、当該施設４００の施設ＩＤを含むレコードが存在するか否かが判断される。ＹｅｓであればステップＳ１１３に移行し、Ｎｏであれば、ステップＳ１１は終了する（当該施設に関する通知は行われない）。なお、ステップＳ１１１とＳ１１２の順序は逆でも良いし、並行して実行されてもよい。

ステップＳ１１３では、現在時刻が指定時間帯に含まれる通知リクエストが少なくとも１つ存在するか否かが判定される。例えば、現在時刻が午前１１時の場合、午前１１時が指定時間帯に含まれる指定リクエストが少なくとも１つ存在するか否かが判断される。ＹｅｓであればステップＳ１１４に移行し、Ｎｏであれば、ステップＳ１１は終了する（当該施設に関する通知は行われない）。なお、ステップＳ１１３の実行の順序は、図９の順序には限定されず、例えば、後述するステップＳ１１５の後に実行してもよい。

ステップＳ１１４では、ステップＳ１１３でＹｅｓとの判定がされた通知リクエストを抽出し、抽出された通知リクエストの集合としての通知リクエスト群を生成する。

ステップＳ１１５では、当該施設４００の現在のステータス情報が、通知リクエスト群に含まれる一の通知リクエストが指定する通知条件と一致するか否かが判定される。例えば、当該施設４００の現在のステータス情報が「やや混雑」である場合、通知条件に「やや混雑」があるか否かが判定される。ＹｅｓであればステップＳ１１６に移行し、Ｎｏであれば、ステップＳ１１６をスキップしてステップＳ１１７へ移行する

ステップＳ１１６では、ステップＳ１１５でＹｅｓの判定がなされた通知リクエストを、通知リストに追加する。続くステップＳ１１７では、通知リクエスト群の中に、未処理の（ステップＳ１１５の判定を実行していない）通知リクエストがあるか否かが判定される。未処理の通知リクエストがあれば（Ｙｅｓ）ステップＳ１１５に戻り、なければステップＳ１１は終了する。続くステップＳ６では、通知リストに追加された通知リクエストに係るユーザ端末３００に対し、所望の施設４００が所望の混雑状態となった旨の通知が送付される。

図１０は、ユーザ端末３００に通知リクエストに基づく通知がされた場合における表示画面の一例を示す。なお、この通知は、電子メールやＳＭＳ（Short Message Service）の形式で送付され、電子メール等の本文に記載されたハイパーリンクがタップされることで表示されるようにすることができる。または、本装置１０を利用するためにスマートフォン等にダウンロードされるアプリケーションソフトウエアに本通知がプッシュ通知により送付されるようにしてもよい。

ユーザ端末３００では、通知リクエストに基づく通知として、例えば図１０の左側に示すように、「現在、ビストロＡの待ち時間が１０分程度です。来店されますか？」のような表示がなされる。来訪を希望する場合、ユーザは、表示画面中の「Ｙｅｓ」をタップし、来訪を希望する旨のデータを送信する。続いて、ユーザ端末３００は、来訪者の人数、席の希望などを入力する。施設状況管理サーバ２００は、これらの情報の入力が完了した場合、受付の完了を示す情報を、例えば受付番号や３次元コードとともに画面に表示する。なお、通知リクエストに基づく通知は、ユーザ端末３００に対し行われるのが基本であるが、例えば、施設４００の近傍に配置されたデジタルサイネージ（図示せず）に通知を送付し、受付番号とともにデジタルサイネージに表示することも可能である。

以上説明したように、第１の実施の形態によれば、ユーザが利用を希望する施設に関し、所望の混雑状態になったら通知されるように通知リクエストにより指定される。施設状況管理サーバ２００は、この通知リクエストと、現在の当該施設４００のステータス情報とを照合し、両者が合致する場合にユーザ端末３００に向けて通知を送付する。従って、本実施の形態によれば、ユーザが許容可能な待ち時間での施設４００の利用が容易になる。ユーザは、指定した施設が所望の混雑状態になったことを、通知を受領することで知ることができるので、サーバに対し何度も検索要求をする必要が無く、タイミングを逸することなく施設４００を利用することが可能になる。また、施設４００の運営者にとっては、所望のステータスとなったらすぐに施設を利用したいというユーザに対し、好適なタイミングで通知を行うことができるため、効果的な集客を行うことができ、施設の利益の増加を図ることができる。

なお、本実施の形態では、施設４００の配信可能なステータス情報の種類として、「空き」、「やや混雑」、「混雑」、「満席」、「１０分待ち」、「３０分待ち」の６種類を例に説明したがこれに限らない。５種類以下でも良いし、待ち時間を含まないステータス情報のみを配信する施設があっても良い。例えば、「空き」、「やや混雑」、「満席」のみのステータス情報を配信する施設に関しては、当然ステータス選択領域３１２に表示される選択肢も「空き」、「やや混雑」、「満席」の３種類となる。

ここで、第１の実施の形態の変形例を説明する。図１１は、第１の実施の形態の変形例に係るフローチャートを説明する。この変形例は、ステップＳ１１５の後において、別の手順（ステップＳ１１８）が追加されている。その他の手順は、図９の手順と同一であるので、重複する説明は省略する。

この変形例では、施設状況管理サーバ２００は、ＧＰＳ位置情報などに基づいて各ユーザ端末３００の現在位置に関する情報を取得している。そして、ステップＳ１１８において、判定部２１４は、ユーザ端末３００の現在位置が、判定対象の施設４００から所定距離以内に存在しているか否かが判定される（ユーザ端末３００の現在位置と、施設４００の位置とが比較される）。所定距離以内（Ｙｅｓ）であれば、当該ユーザ端末３００に係る通知リクエストを通知の対象として通知リストに含め（ステップＳ１１６）、所定距離より遠い位置にある場合には、通知の対象とはされない。この変形例によれば、当該施設４００のステータスが、通知リクエストが指定する通知条件と合致したとしても、通知を回避することができる。ユーザ端末３００を所持するユーザが、待ち時間の間には到着できないような遠い位置にいる場合には、指定された条件が満たされていたとしても、その指定された時間内に当該ユーザが施設４００に到着することが不可能であるため、通知が無駄になる虞がある。この変形例では、無用な通知が回避されることで、装置の負荷が軽減されると共に、ユーザにおいても、無用な通知の受領を回避することができる。

［第２の実施の形態］
図１２を参照して、第２の実施の形態に係る施設状況管理装置１０の構成を説明する。この第２の実施の形態の装置１０では、第１の実施の形態と同様に、利用を希望する施設４００に関する通知リクエストが、ユーザ端末３００から施設状況管理サーバ２００に送付され、施設状況管理サーバ２００は、指定した混雑状況になった場合、その旨をユーザ端末３００に通知する。第２の実施の形態では、これに加えて、施設４００の入り口付近等に施設設置端末７００が設置され、利用の希望に関する情報を入力可能とされている。

図１３に、施設設置端末７００の外観構成の一例と、動作の概要を説明する。施設設置端末７００は、一例として、タッチパネルディスプレイ７０１と、プリンタ７０２と、支持台７０３を備えている。タッチパネルディスプレイ７０１は、支持台７０３の支柱の頂部に保持され、来訪者がタッチパネルを操作し、表示画面を閲覧可能な高さに保持される。プリンタ７０２は、タッチパネルディスプレイ７０１の下方において支持台７０３により支持され、タッチパネルディスプレイ７０１で実行された受付処理の結果を印刷して出力可能に構成される。

タッチパネルディスプレイ７０１の初期表示画面Ｄ１には、例えば、施設名（例：ビストロＡ）が表示されると共に、当該施設の状況を示す文字（例えば、「現在３０分待ち」）と、来訪の受付を開始するための受付ボタンとが表示される。受付ボタンが、来訪者の指又はタッチペン等でタッチされると、表示画面は初期表示画面Ｄ１から人数入力画面Ｄ２に移行する。人数入力画面Ｄ２では、来訪する人数がテンキー等により入力される。人数入力画面Ｄ２において「次へ」ボタンが押されると、表示画面は人数入力画面Ｄ２から座席希望入力画面Ｄ３に移行する。座席希望入力画面Ｄ３では、例えば、希望する座席の形態として「テーブル」、「カウンター」、「どちらでも可」が表示される。入力が終了すると、最終確認画面Ｄ４に移行し、ＯＫボタンが押されたら、施設設置端末７００での受付処理は終了する。受付が終了すると、プリンタ７０２から受付票Ｐ１が印刷・出力される。受付票Ｐ１は、施設の担当者から呼出があった場合に、担当者に対し提示される。また、受付データ（受付日時、受付番号、人数、座席希望など）は、施設状況管理サーバ２００に送信され、行列テーブルにおいて管理される。

このように、第２の実施の形態では、ユーザ端末３００を用いたＷｅｂサイト経由の来訪の受付が可能とされることに加え、施設設置端末７００による来訪の受付が可能とされている。これに加え、施設４００の管理者は、電話による来訪の受付も可能とされている。電話での来訪の受付を行った施設４００の管理者は、施設管理用情報端末５００を操作して、その電話での受付内容に関する情報を入力することが出来る。電話での来訪受付に従い、施設管理用情報端末５００から入力された受付情報は、施設設置端末７００での受付情報と同様に、施設状況管理サーバ２００に送信され、行列テーブルにおいて管理される。ユーザ端末３００を用いたＷｅｂサイト経由の来訪の受付データも、同様に施設状況管理サーバ２００において、行列テーブルにおいて管理される。

図１４は、施設状況管理サーバ２００において管理される行列テーブルの一例である。行列テーブルは、来訪の受付に関する情報を、受付日時、受付番号、人数、座席希望、顧客ステータス情報を１レコードとして記憶する。受付日時のブロックには、受付がなされた日時の他、受付がなされた手法（店頭／電話／Ｗｅｂ）に関する情報が含まれる。また、顧客ステータス情報は、来訪受付をした顧客の状態を示す情報（完了、呼出中、待ち中、キャンセルなど）を示す。

ユーザ端末３００を用いたＷｅｂサイト経由の来訪受付は、第１の実施の形態と同様の手順（図６）で実行することができる。図７のような検索結果表示画面において、所望の施設４００の施設紹介カード３０４中の通知リクエスト設定ボタン３０５を押すと、図１５に示すような通知リクエスト設定画面がユーザ端末３００のディスプレイに表示される。

この通知リクエスト設定画面は、施設名表示領域３１１と、時間帯設定領域３１３と、時刻指定ボタン３１４と、設定ボタン３１５に関しては、第１の実施の形態（図８）と同一である。ただし、この図１５の通知リクエスト設定画面では、通知希望ステータス選択領域３１２に表示された選択肢が、選択した施設でのステータス情報の表記方法に合わせて変化するようにされている。施設状況管理サーバ２００の表示制御部２０１は、施設４００の施設管理用情報端末５００におけるステータス情報の分類方法を参照し、その分類方法に従って、通知希望ステータス選択領域３１２における選択肢を変化させる。一例として、対象施設が、ステータス情報として、「待ちなし」「１０分待ち」、「２０分待ち」、「３０分待ち」、「４０分待ち」のように、待ち時間により混雑状況を表現している場合には、表示制御部２０１は、これに従い、通知希望ステータス選択部３１２に、「待ちなしになったら知らせる」、「…分待ちになったら知らせる」のような選択肢を表示可能とし、「…分」の数値を、数字アイコンをクリックすることで適宜選択可能とされる。

通知リクエスト設定画面の別の表記例を図１６に示す。対象施設が、ステータス情報として「待ちなし」「２分待ち」、「４組待ち」、「６組待ち」、「８組待ち」のように、待機中の顧客の組の数により混雑状況を表現している場合には、表示制御部２０１は、これに従い、通知希望ステータス選択部３１２に、「待ちなしになったら知らせる」、「…組待ちになったら知らせる」のような選択肢を表示可能とし、「…組」の数値を、数字アイコンをクリックすることで適宜選択可能とされる。このように、本実施の形態では、通知希望ステータス選択部３１２の表記を、対象施設のステータス情報の分類方法に従って変更可能とされている。図１５、図１６のような通知リクエスト設定画面により、通知リクエストが設定されると、図１７に示すような通知テーブルが生成される。

このようにして通知テーブルが生成された状況において、施設４００からステータス情報が受信されると、その施設４００に関する通知リクエストがあるか否かが、第１の実施の形態と同様にして判定される（図６のステップＳ１１）。現在のステータス情報と、通知リクエスト中の通知条件とが一致した場合、対応するユーザ端末３００には、図１８左側に示すように、例えば「現在ビストロＡの待ち時間が３０分程度です。来店されますか？」のような通知が送付される。その画面においてＹＥＳがタップされると、来訪の人数、席の希望などが入力されることにより、ユーザ端末３００には受付完了の連絡（受付番号等を含む）が送付される。

以上のようにして、施設設置端末７００を介した来訪受付、電話での来訪受付、Ｗｅｂサイトを経由したユーザ端末３００での来訪受付がなされることで、施設状況管理サーバ２００においては行列テーブル（図１４）が生成され、施設管理用情報端末５００では、この行列テーブルに対応して、施設状況管理テーブルが生成される（図１９参照）。施設状況管理テーブルは、行列テーブルに対応しており、施設の管理者がテーブルに含まれるデータを操作可能なように施設管理用情報端末５００のディスプレイに表記される。

施設状況管理テーブルには、１のレコードごとに操作ボタン３１４が表示されている。この操作ボタン３１４を押すことで、例えば、１のレコードを「待ち中」から、別の状態（例えば、完了、呼出中、キャンセル、人数変更）に変更することができる。人数変更が選択された場合には、図示を省略する人数変更画面に移行し、人数の変更操作が実行され得る。

また、施設管理用情報端末５００のディスプレイには、行列テーブルに対応して生成される空き状況テーブルが表示される。空き状況テーブルは、施設の混雑状況を、行列中の顧客の組の数（ｎ組）、及び待ち時間（ｎ分）で示したテーブルである。空き状況テーブルは、行列テーブルに従って施設状況管理サーバ２００において生成されて施設管理用情報端末５００に送信されてもよいし、施設管理用情報端末５００が、行列テーブルを参照して生成してもよい。

図２０は、第２の実施の形態における、ステップＳ１１（図６）の通知の要否判定の詳細な手順の一例を示すフローチャートである。ステップＳ１５’が第１の実施の形態のステップＳ１１５（図１１）と異なるが、その他のステップ（Ｓ１１～Ｓ１４、Ｓ１６～Ｓ１７）は第１の実施の形態（図９、Ｓ１１１～Ｓ１１４、Ｓ１１６～Ｓ１１７）と同一であるので、重複する説明は省略する。

ステップＳ１５’では、当該施設の現在の待ち時間Ｎｔ（又は現在の待ち組数Ｎｐ）が、通知リクエスト群に含まれる一の通知リクエストが指定する待ち時間Ｎｔｘ（又は指定の待ち組数Ｎｐｘ）以下であるか否かが判定される。ＹｅｓであればステップＳ１６に移行し、Ｎｏであれば、ステップＳ１６をスキップしてステップＳ１７へ移行する

以上説明したように、第２の実施の形態によれば、第１の実施の形態と同等の効果を得ることができる。加えて、この第２の実施の形態によれば、施設４００の入り口付近等に配置される施設設置端末７００や電話によっても来訪の受付がなされ、施設設置端末７００による来訪受付、電話による来訪受付、及びユーザ端末３００による来訪受付を一の行列テーブルにおいて管理することができる。

［第３の実施の形態］
図２１～図２２を参照して、第３の実施の形態に係る施設状況管理装置１０を説明する。この第３の実施の形態の装置１０は、全体構成としては第１又は第２の実施の形態と同一であり、重複する説明は省略する。また、装置１０の全体の動作も、第１及び第２の実施の形態と同様である（図６参照）。ただし、この第３の実施の形態では、ユーザへの通知の送付の可否を、施設管理用情報端末５００において設定可能とされており、この点において前述の実施の形態とは異なっている。本実施の形態において、施設状況管理サーバ２００は、図２Ｂに示す機能構成に加えて、設定部２１６を有する（図示略）。

図２１に、第３の実施の形態において、施設管理用情報端末５００において表示される施設状況管理テーブル及び空き状況テーブルの表示画面例を示す。施設状況管理テーブル及び空き状況テーブル自体は、第２の実施の形態（図１９）と同一である。ただし、この表示画面では、施設状況管理テーブル及び空き状況テーブルと共に、ユーザへの通知可否の設定を行うための指示画面３１８が表示される。指示画面３１８には、例えば、チェックボックスとともに「ユーザへの通知可否の設定」という文字が表示されており、このチェックボックスをタップすると、設定部２１６によるユーザへの通知の可否の設定動作が開始される。

チェックボックスがタップされると、指示画面３１８の画面は、例えば図２２のように変更される。この画面例では、選択肢として、
（１）通知を終日停止
（２）指定された時間帯の通知を停止
（３）今から指定された時間内の通知を停止
が表示され、いずれかが施設管理用情報端末５００の操作者により選択可能とされる。いずれかの選択肢が選択され、ＯＫボタンが押されることにより、設定部２１６は通知の送付の可否を設定する。

このような第３の実施の形態の構成では、施設の管理者は、任意のタイミングで、通知リクエストに基づくユーザへの通知の可否を変更することができる。例えば、平日のランチタイムにおいては、混雑情報の配信によらず施設周辺に行列ができやすいような場合には、施設として積極的な集客を望まないことがある。このような場合、図２２に示す２番目の選択肢において、「平日」の「１１時３０分」～「１３時３０分」と設定することで、平日のランチタイムの間、通知リクエストに応答する通知を停止することができる。また、３番目の選択肢において、「今から「２時間」停止」のように設定すると、現在から２時間、ユーザ端末３００への通知を不許可とすることができる。このように、第３の実施の形態によれば、適宜通知リクエストに対応する通知の送付を停止することができ、施設の状況に柔軟に対応した顧客の勧誘を行うことができる。
本実施の形態においては、図９に示すステップＳ１１１の処理を実行した後、さらに、ユーザへの通知が許可されているか（通知の停止が設定されていないか）を判定する処理を実行する。通知の停止が設定されている場合は、施設に関する通知をしないとして終了（ＥＮＤ）に進む。停止が設定されていない場合には、ステップＳ１１２以降の処理に進む。

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

１０…施設状況管理装置、 ２００…施設状況管理サーバ、 ２０１…表示制御部、 ２１１…受信部、 ２１２…施設状況管理部、 ２１３…検知部、 ２１４…判定部、 ２１５…通知部、 ２４０…記憶装置、 ２４１…データベース、 ２５０…通信装置、 ３００…ユーザ端末、 ３０１…地図、 ３０２…記号（黒丸）、 ３０４…施設紹介カード、 ３０５…通知リクエスト設定ボタン、 ３１１…施設名表示領域、 ３１２…通知希望ステータス選択部、 ３１３…時間帯設定領域、 ３１４…時刻指定ボタン、 ３１５…設定ボタン、 ５００…施設管理用情報端末、 ５１１…制御部、 ５１２…記憶部、 ５１３…通信部（通信モジュール）、 ５１４…入出力部、 ５４０…記憶装置、 ５５０…通信装置、 ５６０…入力装置、 ５７０…出力装置、 ６００…カメラ、 ７００…施設設置端末、 ７０１…タッチパネルディスプレイ、 ７０２…プリンタ、 ７０３…支持台。

Claims (9)

1. ユーザ端末から、施設が指定の混雑状況になった場合に通知を希望する旨の通知リクエストを受信すると共に、施設用端末から、前記施設の混雑状況を示すステータス情報を受信する受信部と、
   前記通知リクエストに従い、前記通知をする条件を、前記施設及び前記ユーザ端末を特定する情報と共に管理する施設状況管理部と、
   前記施設の最新の前記ステータス情報が、前記条件と合致した場合に、前記ユーザ端末に対し前記施設に関する情報を通知する通知部と、
   前記施設に関して、配信され得るステータス情報の種類を保持する保持部と
   を備え、
   前記通知リクエストは、前記施設に関して配信されうるステータス情報を選択肢として前記ユーザ端末に表示された設定画面を介して選択された、前記施設に関して配信され得るステータス情報のうち、少なくとも１つのステータス情報の指定を含み、
   前記設定画面は、前記施設に対応する前記配信され得るステータス情報の種類に応じた選択肢が表示される、施設状況管理装置。
2. ユーザ端末から、施設が指定の混雑状況になった場合に通知を希望する旨の通知リクエストを受信すると共に、施設用端末から、前記施設の混雑状況を示すステータス情報を受信する受信部と、
   前記通知リクエストに従い、前記通知をする条件を、前記施設及び前記ユーザ端末を特定する情報と共に管理する施設状況管理部と、
   前記施設の最新の前記ステータス情報が、前記条件と合致した場合に、前記ユーザ端末に対し前記施設に関する情報を通知する通知部と
   を備え、
   前記通知リクエストは、前記施設に関して配信されうるステータス情報を選択肢として前記ユーザ端末に表示された設定画面を介して選択された、前記施設に関して配信され得るステータス情報のうち、少なくとも１つのステータス情報の指定を含み、
   前記受信部は、前記通知リクエストとして、前記設定画面を介して、複数のステータス情報の選択を受け付け可能である施設状況管理装置。
3. 前記通知リクエストは、前記ユーザ端末が前記施設の利用を希望する時間帯の指定を含み、前記通知部は、現在の時刻が、指定された前記時間帯に含まれるか否かを判定するよう構成された、請求項１又は２に記載の施設状況管理装置。
4. 前記通知部は、前記ユーザ端末の現在位置と、前記施設の位置情報とを比較し、その比較結果に従って、前記ユーザ端末に対し前記通知を行うか否かを判断する、請求項１又は２に記載の施設状況管理装置。
5. 前記通知部による前記通知の送付の可否を設定する設定部を更に備える、請求項１～４のいずれか１項に記載の施設状況管理装置。
6. ユーザ端末から、施設が指定の混雑状況になった場合に通知を希望する旨の通知リクエストを受信すると共に、施設用端末から、前記施設の混雑状況を示すステータス情報を受信する受信部と、
   前記通知リクエストに従い、前記通知をする条件を、前記施設及び前記ユーザ端末を特定する情報と共に管理する施設状況管理部と、
   前記施設の最新の前記ステータス情報が、前記条件と合致した場合に、前記ユーザ端末に対し前記施設に関する情報を通知する通知部と、
   前記通知部による前記通知の送付の可否を設定する設定部と
   を備え、
   前記通知リクエストは、前記施設に関して配信されうるステータス情報を選択肢として前記ユーザ端末に表示された設定画面を介して選択された、前記施設に関して配信され得るステータス情報のうち、少なくとも１つのステータス情報の指定を含み、
   前記設定部は、前記通知部による前記通知の送付を停止する時間帯を指定することが可能に構成された施設状況管理装置。
7. 前記受信部は、前記ユーザ端末から来訪受付を受信し、
   さらに、前記施設に設置され、前記施設への来訪者を受け付ける施設設置端末からも来訪受付を受信可能であり、
   前記施設状況管理部は、前記施設設置端末での来訪受付と、前記ユーザ端末からの来訪受付とを一の行列テーブルで管理可能とされた、請求項１又は２に記載の施設状況管理装置。
8. コンピュータを請求項１乃至７のいずれか１項に記載の施設状況管理装置として機能させるためのプログラム。
9. 施設の混雑状況に関するステータス情報を管理する管理方法であって、
   ユーザ端末から、施設が指定の混雑状況になった場合に通知を希望する旨の通知リクエストをサーバが受信するステップと、
   前記通知リクエストに従い、前記通知をする条件を、前記施設及び前記ユーザ端末を特定する情報と共に前記サーバが管理するステップと、
   前記ステータス情報が、前記条件と合致した場合に、前記サーバが前記ユーザ端末に対し前記施設に関する情報を通知するステップと、
   前記施設の最新の前記ステータス情報が、前記条件と合致した場合に、前記サーバが前記ユーザ端末に対し前記施設に関する情報を通知するステップと、
   前記施設に関して、配信され得るステータス情報の種類を記憶部に保持するステップと、を備え、
   前記通知リクエストは、前記施設に関して配信されうるステータス情報を選択肢として前記ユーザ端末に表示された設定画面を介して選択された、前記施設に関して配信され得るステータス情報のうち、少なくとも１つのステータス情報の指定を含み、
   前記設定画面は、前記施設に対応する前記配信され得るステータス情報の種類に応じた選択肢が表示される、施設状況管理方法。

Images