IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社バカンの特許一覧

特開2022-142842情報処理装置、プログラム及び情報処理方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022142842
(43)【公開日】2022-10-03
(54)【発明の名称】情報処理装置、プログラム及び情報処理方法
(51)【国際特許分類】
   G06Q 10/02 20120101AFI20220926BHJP
   G06Q 50/10 20120101ALI20220926BHJP
   G16Y 10/45 20200101ALI20220926BHJP
   G16Y 20/10 20200101ALI20220926BHJP
   G16Y 40/10 20200101ALI20220926BHJP
【FI】
G06Q10/02
G06Q50/10
G16Y10/45
G16Y20/10
G16Y40/10
【審査請求】有
【請求項の数】11
【出願形態】OL
(21)【出願番号】P 2021043069
(22)【出願日】2021-03-17
(71)【出願人】
【識別番号】516329543
【氏名又は名称】株式会社バカン
(74)【代理人】
【識別番号】110002572
【氏名又は名称】特許業務法人平木国際特許事務所
(72)【発明者】
【氏名】篠原 清志
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA03
5L049CC11
(57)【要約】
【課題】正確性の高い空き情報を配信する技術を提供する。
【解決手段】本開示の情報処理装置は、施設の空き状況を示す空き情報を配信する情報処理装置であって、ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、現在時刻から所定時間以内に所定数以上の前記ユーザ端末から同じ空き情報が送信されている場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える。
【選択図】図7
【特許請求の範囲】
【請求項1】
施設の空き状況を示す空き情報を配信する情報処理装置であって、
ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、
現在時刻から所定時間以内に所定数以上の前記ユーザ端末から同じ空き情報が送信されている場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える情報処理装置。
【請求項2】
前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に含まれる空き情報のうち最大数の空き情報を前記所定数と比較する、請求項1に記載の情報処理装置。
【請求項3】
前記取得手段は、前記施設に対応する施設端末から送信された前記施設の前記空き情報を第1の空き情報として取得し、
前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に基づいて第2の空き情報を決定し、前記第1の空き情報及び前記第2の空き情報のいずれかを、前記配信すべき前記空き情報として決定する、請求項1に記載の情報処理装置。
【請求項4】
前記決定手段は、前記取得手段が前記ユーザ端末から前記空き情報を取得していても、前記所定時間内に前記所定数以上の同じ前記空き情報を取得していない場合には、前記第1の空き情報を前記配信すべき前記空き情報として決定する、請求項3に記載の情報処理装置。
【請求項5】
施設に関する施設情報を記憶する記憶手段と、
前記施設情報に基づいて前記所定時間を設定する第1の設定手段と、をさらに備える請求項1~4のいずれか1項に記載の情報処理装置。
【請求項6】
前記第1の設定手段は、前記施設のジャンル情報に基づいて前記所定時間を設定する、請求項5に記載の情報処理装置。
【請求項7】
施設に関する施設情報を記憶する記憶手段と、
前記施設情報に基づいて前記所定数を設定する第2の設定手段と、をさらに備える請求項1~6のいずれか1項に記載の情報処理装置。
【請求項8】
前記第2の設定手段は、前記施設が収容可能な人数を示すキャパシティ情報に基づいて前記所定数を設定する、請求項7に記載の情報処理装置。
【請求項9】
前記第2の設定手段は、前記施設の位置に関する情報に基づいて前記所定数を設定する、請求項7に記載の情報処理装置。
【請求項10】
コンピュータを、請求項1~9のいずれか1項に記載の情報処理装置として機能させるプログラム。
【請求項11】
情報処理装置により実行される情報処理方法であって、
ユーザ端末から送信された、施設の空き状況を示す空き情報を取得することと、
現在時刻から所定時間以内に所定数以上の前記ユーザ端末から同じ空き情報が送信されている場合に、配信すべき前記空き情報として決定することと、を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理装置、プログラム及び情報処理方法に関する。
【背景技術】
【0002】
店舗の空き情報をユーザがオンラインで確認できるようにするための技術は、例えば飲食店などの空き情報を提供するために用いられている。特許文献1には、「来店予約を行う前に、店舗の混雑状況を利用者に提供する」ことを課題として、「情報管理システムは、店舗に設置され店舗の混雑状況を示す混雑情報を送信する店舗端末40と、店舗端末が設置された店舗に関する混雑情報を含んだ店舗データを管理するサーバ装置10と、を有する。サーバ装置は、店舗端末から送信される混雑情報を受信し、店舗データに含まれる混雑情報のステータスを、受信した混雑情報のステータスに更新する。店舗を利用する利用者からの、店舗の混雑状況を確認したい旨の要求を受け付け、記憶された店舗データに基づき、店舗の混雑状況を示す画面データを生成し、利用者が所持するユーザ端末20に送信する。サーバ装置は、送信した画面データに対する利用者の操作に応じて、店舗への来店予約を行う。」という技術を開示している(同文献の要約参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2019-82946号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記特許文献1の技術においては、例えば空き情報の更新漏れがあった場合や、空き情報の入力ミスがあった場合などに、ユーザ端末に配信される空き情報が、現時点での店舗の実際の空き状況と異なってしまうことがある。
【0005】
そこで、本開示は、正確性の高い空き情報を配信する技術を提供する。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本開示の情報処理装置は、施設の空き状況を示す空き情報を配信する情報処理装置であって、ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、現在時刻から所定時間以内に所定数以上の前記ユーザ端末から同じ空き情報が送信されている場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える。
【0007】
本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではない。
【発明の効果】
【0008】
本開示の技術によれば、正確性の高い空き情報を配信することができる。
【図面の簡単な説明】
【0009】
図1】第1の実施形態に係る空席管理システムの構成図である。
図2A】空席管理サーバのハードウェア構成図である。
図2B】空席管理サーバの機能ブロック図である。
図3A】データベースに格納されているデータ例を示す図である。
図3B】データベースに格納されているデータ例を示す図である。
図3C】データベースに格納されているデータ例を示す図である。
図4A】入力端末のハードウェア構成図である。
図4B】入力端末の機能ブロック図である。
図5A】ユーザ端末のハードウェア構成図である。
図5B】ユーザ端末の機能ブロック図である。
図6】空席管理サーバにおける空き情報の配信処理手順を示すフローチャートである。
図7】空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
図8】ユーザ端末における空き情報の表示処理手順を示すフローチャートである。
図9】第1の実施形態に係るユーザ端末の表示画面の例である。
図10】ユーザ端末における投稿画面の表示手順を示すフローチャートである。
図11】第1の実施形態に係る空き情報の投稿画面の一例を示す図である。
図12】第2の実施形態に係るデータベースに格納されているデータ例を示す図である。
図13】第2の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
図14】第3の実施形態に係るデータベースに格納されているデータ例を示す図である。
図15】第3の実施形態に係るデータベースに格納されているデータ例を示す図である。
図16】第3の実施形態に係る空席管理サーバにおける配信すべき空き情報の決定手順を示すフローチャートである。
図17】第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は、ユーザが店舗を検索するときに用いる属性情報を含む店舗情報を管理するデータテーブルであり、例えば、店舗ID1421、店舗の名称1422、ジャンル1423(属性情報)、店舗紹介1424、住所1425、緯度経度1426、電話番号1427、営業時間1428を構成項目として有している。店舗情報データベース142の1つのレコードは、1つの店舗の店舗情報を管理する。入力端末20を保有する店舗40の店舗情報は、例えば、入力端末20に入力された情報を基に店舗情報データベース142に登録することもできるし、空席管理システム1のサービスの提供者が、電話帳や地図情報などに記載の情報に基づいて予め登録することもできる。
【0021】
店舗ID1421は、データベース141内で各店舗を識別するためのIDである。緯度経度1426は、店舗の位置を緯度経度によって示すデータであり、同じ施設の同じフロアであっても、店舗の位置が異なる場合は異なる緯度経度の値が登録されている場合もある。
【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は、受信日時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の空き情報を設定するか否かを判断する。具体的には、判定部113は、取得したユーザ投稿のうち最多の空き情報の数が所定数(例えば、5つ)以上であるか否かを判断し、所定数以上である場合、最多の空き情報を第2の空き情報として設定し、RAM13又は記憶装置14に格納する。また、判定部113は、最多の空き情報を示すユーザ投稿のうち、最新の(最も現在時刻に近い)受信日時を、第2の空き情報の受信日時として設定する。判定部113は、最多の空き情報の数が所定数未満である場合、第2の空き情報を設定せずに、処理はステップS208に移行する。
【0049】
ここで、最多の空き情報が複数あり、それらの数が所定数以上である場合(例えば、「空きあり」が5つであり「やや混雑」も5つである場合)には、いずれか一方の空き情報を第2の空き情報として設定することができる。この場合、いずれの空き情報を第2の空き情報として設定するかは、ランダムで決定してもよいし、所定の優先度にしたがって決定してもよい。例えば、より空席が多い方の空き情報を第2の空き情報として設定すれば、よりユーザが店舗40を訪れやすくなる。一方、より混雑度が高い方の空き情報を第2の空き情報として設定すれば、ユーザがより空いている店舗に訪れるための参考にすることができる。
【0050】
(ステップS206)
判定部113は、空き情報データベース143及びユーザ投稿データベース144を参照して、第1の空き情報の受信日時が、第2の空き情報の受信日時よりも後であるか否かを判断する。第1の空き情報の受信日時が、第2の空き情報よりも後である場合(Yes)、処理はステップS208に移行する。第1の空き情報の受信日時が、第2の空き情報よりも後でない場合(No)、処理はステップS207に移行する。
【0051】
(ステップS207)
判定部113は、最多のユーザ投稿の数が所定数以上であるため第2の空き情報が設定され(ステップS205)、第2の空き情報(ユーザ投稿)の方が第1の空き情報よりも最新である(ステップS206)場合、第2の空き情報は店舗のリアルタイムな空き情報として信頼できるため、第2の空き情報を、照会リクエストを送信したユーザ端末30に配信すると決定する。換言すれば、配信すべき空き情報のステータスを、第2の空き情報で上書きする。
【0052】
(ステップS208)
判定部113は、所定時間以内のユーザ投稿がないか(ステップS203)、最多のユーザ投稿の数が所定数未満であるため第2の空き情報が設定されないか(ステップS205)、又は、第1の空き情報の方が第2の空き情報(ユーザ投稿)よりも最新である(ステップS206)場合、第1の空き情報を、照会リクエストを送信したユーザ端末30に配信すると決定する。すなわち、配信すべき空き情報のステータスを、デフォルトの第1の空き情報のままとする。
【0053】
(ステップS209)
判定部113は、ステップS103において特定された店舗群のうち、未処理の店舗があるか否かを判断する。このとき、判定部113は、ステップS201において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合(Yes)、処理はステップS201に戻り、ステップS201~S208が上記と同様に実行される。未処理の店舗がない場合(No)、配信すべき空き情報の決定処理は終了し、上述のステップS105に移行する。
【0054】
店舗40からの空き情報の送信が漏れていたり、誤っていたりすることで、正確な空き情報がユーザに配信されない場合がある。これに対し、本実施形態のように、現在時刻から所定時間以内に投稿されたユーザ投稿の数が所定数以上であり、当該ユーザ投稿の方が第1の空き情報よりも最新であるとみなせる場合には、ユーザ投稿を用いて空き情報を配信することで、より正確な空き情報を配信することができる。つまり、第1のユーザ端末から送信された第1の店舗の空き情報が、第2のユーザ端末上に、第1の店舗の空き情報として表示されることがある。その一方で、第2の店舗の空き情報に関しては、第1のユーザ端末から空き情報が送信されても、第2のユーザ端末には第2の空き情報として表示されないことがある。
【0055】
<ユーザ端末30の空き情報表示処理>
図8は、ユーザ端末30における空き情報の表示処理手順を示すフローチャートである。ユーザ端末30は、図8に示すフローチャートを実現するプログラムを実行する。
【0056】
(ステップS301)
生成部313は、通信制御部312を介して、ユーザ端末30の現在位置を示す位置情報(GPSデータ)を取得する。生成部313は、取得した位置情報を記憶部311に格納する。
【0057】
(ステップS302)
生成部313は、記憶部311からユーザ端末30の位置情報を取得し、当該位置情報を含む検索リクエストを生成し、通信制御部312を介して検索リクエストを空席管理サーバ10に送信する。空席管理サーバ10は、検索リクエストを受信すると、図6及び図7に示した上述の処理を実行する。
【0058】
(ステップS303)
生成部313は、ステップS301で取得した位置情報及びユーザによって指定された地図の拡大率に応じて、記憶部311から地図情報(地図データ)を読み込み、表示制御部314を介して表示装置32の表示画面上に所望の地図を表示する。なお、地図の拡大率は事前に設定された固定値としてもよい。
【0059】
(ステップS304)
生成部313は、通信制御部312を介して、空席管理サーバ10から、ユーザ端末30の位置情報に応じた店舗群の店舗情報及び空き情報を取得して、記憶部311に格納する。
【0060】
(ステップS305)
生成部313は、空席管理サーバ10から受信した店舗群のうち、任意の1つの店舗を処理対象店舗として選択する。ここで選択される処理対象店舗は、例えば、緯度経度がユーザ端末30の位置情報に最も近い店舗とすることができる。別の形態では、店舗ID1421が最も若い店舗を処理対象店舗として選択することもできる。
【0061】
(ステップS306)
生成部313は、記憶部311に格納されている処理対象店舗の空き情報を参照し、表示ピンのオブジェクトデータの中から空き情報に対応するものを選択して、空き情報に基づいたピンデータを生成する。表示ピンのオブジェクトデータは、空き情報に応じて色分けすることができる。例えば、表示ピンのオブジェクトデータは、空き情報が「空きあり」である場合は青色、「やや混雑」である場合は黄色、「満席」である場合は赤色とすることができる。また、表示ピンのオブジェクトデータに、空き情報に対応するテキストデータを重畳することにより各店舗のピンデータが生成される。すなわち、地図に表示されるピンには、1つの店舗の空き情報を示すテキストが含まれる。例えば、処理対象店舗の空き情報が「空きあり」であった場合は、ピンの中に「空きあり」というテキストを表示する。空き情報が「満席」であった場合は、「満席」というテキストを表示する。ピンデータに含まれるテキストは、例えば黒文字又は白文字とすることができる。
【0062】
(ステップS307)
生成部313は、処理対象店舗の緯度経度にしたがって、ステップS306で生成したピンデータを地図上に配置する。なお、このとき、生成部313は、空き情報が「やや混雑」又は「満席」の店舗についてはピンデータを削除して配置せず、空き情報が「空き」を示す店舗のピンデータのみを配置するようにしてもよい。
【0063】
(ステップS308)
生成部313は、空席管理サーバ10から受信した店舗群のうち、未処理の店舗があるか否かを判断する。このとき、生成部313は、ステップS305において選択された店舗以外の店舗について、未処理であると判断する。未処理の店舗がある場合(Yes)、処理はステップS305に戻り、ステップS305~S307が上記と同様に実行される。未処理の店舗がない場合(No)、処理はステップS309に移行する。
【0064】
(ステップS309)
表示制御部314は、ステップS307において生成部313により地図上に配置されたピンデータにしたがって、表示用ピンを表示装置32の表示画面に表示する。
【0065】
一旦空き情報を照会したユーザ端末30は、所定時間ごと(例えば、10秒ごと)に最新の空き情報を取得するためのリクエスト(再リクエスト)を空席管理サーバ10に送信する。空席管理サーバ10は、当該再リクエストに応答して、最新の空き情報をデータベース141から取得し、ユーザ端末30に送信する。最新の空き情報を受信すると、ユーザ端末30は、最初のリクエストに対応して取得して地図上に表示した店舗群の空き情報を更新して表示画面上にピン表示する。
【0066】
以上、ユーザ端末30においてピンデータを生成することを説明したが、空席管理サーバ10側で、又は、表示用データを生成するための他の装置等において、ピンデータを生成してユーザ端末30に送信し、ユーザ端末30は表示する処理のみを行うようにしてもよい。
【0067】
<地図上でのUI表示例>
第1の実施形態による、ユーザ端末30の表示装置32の表示画面に表示されるUI表示の例を説明する。
【0068】
図9は、第1の実施形態における地図上に表示されるUI表示(ピン表示)の例を示す図である。図9に示す例において、ピンの色が空き情報に応じて色分けされており、ピンに空き情報を示すテキストが表示されている。ピンの色分けやテキストの色については、空き情報がいずれであるかをユーザが認識することができればよく、図示したものに限定されない。また、地図上には、ユーザの現在位置100が示されている。
【0069】
以上の通り、本実施形態において、店舗によって管理された店舗の空き情報に加えて、店舗の店員ではないユーザ(一般客)からも店舗の空き情報の投稿を受け付け、店舗の空き情報として利用する。例えば、第1のユーザが投稿した店舗Bの空き情報に関して、所定の条件を満たす場合には、第1のユーザとは異なる第2のユーザに対して、第1のユーザが投稿した店舗Bの空き情報を提供することができる。これにより、店舗による空き情報の更新が漏れていたり、店舗が入力した空き情報が誤っていたりしても、ユーザは、より正確な空き情報を参考にすることができる。
【0070】
<ユーザ端末30の投稿画面の表示処理>
図10は、ユーザ端末30における空き情報の投稿画面の表示手順を示すフローチャートである。ユーザ端末30は、図10に示すフローチャートを実現するプログラムを実行する。
【0071】
(ステップS401)
生成部313は、ユーザによる地図上のピン(店舗)の選択を受け付ける。
【0072】
(ステップS402)
生成部313は、記憶部311からユーザ端末30の位置情報を取得する。
【0073】
(ステップS403)
生成部313は、記憶部311に格納された店舗情報のうち営業時間を参照し、現在時刻が、選択されたピンに対応する店舗40の営業時間内であるか否かを判断する。営業時間内である場合(Yes)、処理はステップS404に移行する。営業時間外である場合(No)、処理はステップS407に移行する。なお、店舗40が24時間営業の場合は、本ステップS403を省略してステップS407に移行するようにしてもよい。
【0074】
(ステップS404)
生成部313は、記憶部311に格納された店舗情報のうち緯度経度を参照し、ステップS402で取得したユーザ端末30の位置情報と、店舗40との距離を算出する。
【0075】
(ステップS405)
生成部313は、ユーザ端末30と店舗40との距離が、所定の距離以下であるか否かを判断する。この所定の距離は、例えば、ユーザが店舗40にいてもGPSのずれにより生じる範囲として設定することができる。GPSのずれが最大300m発生し得る場合は、所定の距離は、店舗40の広さも加味して、例えば350mに設定することができる。所定の距離以下である場合(Yes)、処理はステップS406に移行する。所定の距離より大きい場合(No)、処理はステップS407に移行する。
【0076】
(ステップS406)
生成部313は、ユーザが空き情報を投稿するための各ボタンがアクティブとなっている投稿画面を生成する。ここで、現在時刻が営業時間内であり、ユーザ端末30と店舗40との距離が近い(所定の距離以下)である場合は、ユーザが店舗40内にいる可能性が高いとみなすことができる。このように、所定の条件を満たす場合にのみユーザが空き情報を投稿できるようにすることで、高い信頼性の空き情報の投稿を受け付けることができる。
【0077】
(ステップS407)
ステップS403において営業時間外であると判断された場合、又は、ステップS405において所定の距離より大きいと判断された場合、生成部313は、各ボタンが非アクティブとなっている投稿画面を生成する。このように、所定の条件が満たされない場合には、空き情報の投稿が受け付けられない。ただし、投稿画面を生成しないのではなく、各ボタンが非アクティブとなっている投稿画面を生成することで、条件を満たせば空き情報を投稿できる場合があることを、ユーザに暗に示すことができる。
【0078】
(ステップS408)
表示制御部314は、ステップS406又はステップS407で生成された投稿画面を表示装置32の表示画面に表示する。
【0079】
以上の通り、ユーザ端末30から店舗の空き情報を送信する場合、店舗40との距離が近い場合にのみ受け付ける。これにより、ユーザ端末30からいたずら目的や不正確な空き情報が送信されてしまうことを抑制する。なお、店舗40の入力端末20から店舗40の空き情報が送信される場合は、ステップS405のように距離が近いか否かを判定することなく、常に空き情報の投稿を受け付ける。店舗40の入力端末20の場合は、事前に店舗40自身からの空き情報であることがわかるように店舗40に対応する入力端末ID1433が登録されているため、距離に応じた判定をすることなく信頼性の高い空き情報であるとみなせる。さらには、入力端末20自体が店舗40内にない場合でも、店舗40を運営する管理者が店舗40内で勤務する店員からの連絡を受けて空き情報を送信する場合もあり、距離に関わらず店舗40の空き情報としてみなすことができる。
【0080】
<投稿画面の表示例>
図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を含む新たなレコードを作成する)。
【0081】
<第1の実施形態のまとめ>
第1の実施形態に係る空席管理システム1において、ユーザ端末30から空き情報の検索リクエストを空席管理サーバ10に送信すると、空席管理サーバ10は、検索リクエストに応答してユーザ端末30の位置に基づいて店舗群(ユーザが入力した検索条件に合致する店舗の集合)を特定し、それらの空き情報を店舗情報と共にユーザ端末30に送信する。このとき、空席管理サーバ10は、現在時刻から所定時間以内に所定数以上のユーザ端末30から同じ空き情報が送信されている場合に、当該空き情報を第2の空き情報として設定し、第2の空き情報が所定の条件を満たす場合は、第2の空き情報をユーザ端末30に配信すべき空き情報として決定する。これにより、店舗40の入力端末20から最後に送信された空き情報が現状とは異なっていたとしても、より信頼性が高いユーザ投稿が配信されるため、ユーザは、正確な空き情報を参照することができる。
【0082】
<第1の実施形態の変形例>
第1の実施形態では、現在時刻から所定時間以内に投稿されたユーザ投稿の数が所定数以上である場合には、ユーザ投稿を第2の空き情報として設定することを説明した。追加的に又は代替的に、現在時刻から所定時間以内に投稿されたユーザ投稿の割合が、所定の割合(例えば、50%)以上である場合に、ユーザ投稿を第2の空き情報として設定するようにしてもよい。例えば、現在時刻から所定時間以内のユーザ投稿が10個あり、そのうち「空きあり」が4つ、「やや混雑」が3つ、「満席」が3つといったように、投稿された空き情報にばらつきがあることもある。そこで、ある店舗の空き情報の投稿として、所定数以上に加えて、所定時間以内のユーザ投稿の数に占める最多の空き情報の投稿数が所定の割合以上であることを条件とする。この場合、上記例では最多の空き情報の数が4であり、所定時間以内の投稿が10個なので、割合は40%となり、50%以上という条件を満たさない。したがって、ユーザ投稿による第2の空き情報は設定されないことになる。このように、ユーザ投稿のばらつきが小さい場合にのみ店舗の空き情報として配信できるようにすることで、より正確な空き情報を配信することができる。
【0083】
別の形態では、本実施形態の技術は、入力端末20を有しない(第1の空き情報が送信されない)店舗の空き情報についても、適用することができる。この場合、判定部113は、図7のステップS201、S203~S205、S207及びS209のみを実行すればよい。つまり、店舗40自身から空き情報が送信されることがない場合においても、事前に店舗情報のみ店舗情報データベース142に登録しておく。そして、現在時刻から所定時間以内に所定数のユーザから同じ空き情報が送信された場合には、その店舗の配信すべき空き情報としてユーザから送信された情報を採用し、他のユーザに配信する。一方、第2の空き情報が設定されない(所定数以上の空き情報を示すユーザ投稿がなかった)場合、空き情報を配信しないか、又は、空き情報の代わりに、店舗名やジャンルなどの店舗情報や、営業中か否かを示すテキストを地図上に表示するようにすればよい。これにより、ユーザは、入力端末20を有しない店舗の空き情報についても参照することができる。
【0084】
別の形態では、判定部113は、ユーザ端末30に公開される店舗の空き情報としてはあくまで第1の空き情報を用いることを基本としつつ、第2の空き情報が設定されたら、第2の空き情報が第1の空き情報とは異なる場合にのみ、店舗40の入力端末20に空き情報の更新を促す通知を送信するようにしてもよい。また、第2の空き情報が第1の空き情報と同じで第2の空き情報の受信日時の方が第1の受信日時よりも新しい場合には、更新部112により、第1の空き情報の受信日時を第2の空き情報の受信日時に更新するようにしてもよい。
【0085】
空席管理サーバ10がユーザ端末30からの検索リクエストに対する応答として、店舗群の店舗情報と空き情報を送信する際(ステップS105)、空席管理サーバ10は、現在時刻が各店舗の営業時間内であるかを判断して、営業時間内の店舗の店舗情報と空き情報のみをユーザ端末30に送信するようにしてもよい。この場合、ユーザ端末30は、上述のステップS403における営業時間内であるか否かの判断を行わなくてもよい。
【0086】
また、空席管理サーバ10はユーザ端末30からユーザ投稿を受信すると、ユーザ投稿データベース144のレコードを追加して、ステップS203~S204において受信日時が所定時間以内のユーザ投稿を抽出するようにした。しかしながら例えば、空席管理サーバ10は、定期的にユーザ投稿データベース144を監視し、受信日時から所定時間を超えたユーザ投稿をキャンセルするようにしてもよい。この場合、現在時刻から所定時間を超えた古いユーザ投稿は存在しなくなるので、空席管理サーバ10が、ユーザ投稿の受信日時が所定時間以内のものがあるか否かを判定するステップ(S203)は不要となる。
【0087】
また、店舗40の入力端末20について、空席管理サーバ10は入力端末ID1433を事前に店舗40の入力端末20として設定しておくこととし、第1の空き情報1432と連動して入力端末ID1433も更新されることはないとした。例えば、店舗の店員がGUI画面を介して空き情報を入力する前に、店舗40のアカウント情報を用いたログインをした場合に限り、入力端末20から空き情報を送信できるようにしてもよい。この場合、空席管理サーバ10は、店舗40に対応するアカウント情報(例えば、メールアドレスとパスワードなど)を管理し、入力端末ID1433を事前に設定する必要はない。この場合は、店舗40に対応するアカウントから送信された空き情報を第1の空き情報として利用することになる。また、複数の入力端末20を用いて空き情報を送信した場合には、店舗40に対応する入力端末ID1433がその都度更新されることになる。
【0088】
空席管理サーバ10が入力端末20に提供するGUI画面と、ユーザ端末30に提供する投稿画面は異なる画像であり、GUI画面に対する操作により送信された空き情報と、投稿画面に対する操作により送信された空き情報それぞれを識別可能なように、空席管理サーバ10に送信すればよい。この場合、例えば店員自身が個人利用を目的として保有する端末を、入力端末20とユーザ端末30それぞれとして併用することも可能である。同じ端末から送信された空き情報でも、店舗40からの空き情報を受け付けるGUI画面を介して送信された場合には、空席管理サーバ10は、第1の空き情報として受け付け、ユーザによる空き情報の投稿のための投稿画面を介して送信された場合には、空席管理サーバ10は、ユーザ投稿として受け付ける。
【0089】
第1の実施形態では、飲食店の空き情報を例に説明したが、これに限らない。例えば、飲食店以外にも映画館やスポーツスタジアム、駐車場、バス停などの施設の空き情報にも、本実施形態の技術を適用できる。また、本実施形態の空席管理システム1は、席を提供されないが人の多さが変動するような施設における利用者の空き状況を管理してもよい。具体的には、例えばスーパーマーケット、薬局、スポーツジム、自治体若しくは銀行の窓口、温泉施設などの空き状況を示す情報を管理してもよい。この場合、例えば、空席管理サーバ10は、「空いている」「やや混雑」「混雑」のいずれかによって表される混雑情報を管理し、配信する。このことは、以下で説明する各実施形態でも同様である。
【0090】
また、ジャンルや施設によって空き情報として選択されうる選択肢が異なる場合がある。このような場合、ユーザ端末30に表示される店舗ごとの空き情報の投稿画面は、店舗40自身が配信可能な空き情報に応じて生成される方が望ましい。例えば、店舗40からの配信が「空きあり」、「やや混雑」、「満席」のうちいずれかである場合には、投稿画面にも「空きあり」、「やや混雑」、「満席」が選択肢として表示され、店舗40からの配信が「空いている」、「やや混雑」、「混雑」のうちいずれかである場合には、投稿画面にも「空いている」、「やや混雑」、「混雑」が選択肢として表示される。また、必ずしも店舗40から送信されうる空き情報の種類の全てを、ユーザ端末30の表示画面にも表示しなくてもよい。例えば、店舗40からの送信されうる空き情報の種類が「空きあり」、「やや混雑」、「満席」に加えて、「N分待ち」や「順番待ちN組」(Nには任意の数字を選択可能)などもあるとする。この場合、ユーザ端末30の空き情報の投稿画面に表示される選択肢は、店舗40からの送信されうる空き情報のうち「空きあり」、「やや混雑」、「満席」のみであってもよい。つまり、ユーザ端末30に表示される投稿画面上の空き情報の選択肢は、少なくとも店舗40からも送信されうる選択肢であることが望ましいが、全てではなくてもよい。
【0091】
[第2の実施形態]
上述の第1の実施形態では、ステップS203において、店舗のジャンルにかかわらず、同じ所定時間以内のユーザ投稿を取得することを説明した。しかしながら、店舗のジャンルに応じて顧客の回転率が異なるため、空き状況の変動のしやすさも異なる。そこで、第2の実施形態では、店舗のジャンルに応じて異なる所定時間を設定する技術を提案する。
【0092】
<データベースの構成例>
図12は、空席管理サーバ10が実行する、第2の実施形態に係る店舗情報データベース242を示す図である。図12に示すように、店舗情報データベース242は、所定時間2421をさらに構成項目として有している点で、第1の実施形態の店舗情報データベース142と異なっている。所定時間2421は、入力端末20の設定画面から店員が入力し空席管理サーバ10に送信するようにしてもよいし、空席管理システム1の提供者が店舗のジャンルに応じた値(デフォルト値)を予め店舗情報データベース242に入力するようにしてもよい。
【0093】
例えば、店舗のジャンルが飲食店である場合には、所定時間を30分とすることができ、店舗のジャンルが博物館、美術館、観光施設、美容院などの場合には、所定時間を1時間とすることができる。また、飲食店の中でもさらにジャンル分けすることがでる。例えば居酒屋、レストラン、カフェなど、回転率が低い飲食店の場合、所定時間を30分とし、ファーストフード店、ラーメン屋、回転寿司店など、回転率が高い飲食店の場合、所定時間を15分とすることができる。また、例えば、複数窓口のある自治体や銀行など、回転率が高い施設においても、所定時間を15分とすることができる。別の形態では、ジャンルが同じであっても、店舗の住所に応じて所定時間を異ならせてもよい。例えば、人通りの多い駅前のカフェの場合には空き状況が変わりやすいため所定時間を短く設定し、人通りの少ない駅から離れたカフェは空き状況が急に変動することは少ないため所定時間を長く設定することができる。このように、店舗ごとの回転率や店舗付近の人通りの多さ等に応じて所定時間を設定することができる。
【0094】
別の形態では、同じ店舗40においても、異なる時間帯で異なる所定時間を設定できるようにしてもよい。例えば、ランチタイムにおいて回転率が高く、ディナータイムにおいて回転率が低い場合には、所定時間を、ランチタイムについては短く設定し、ディナータイムについては長く設定することができる。
【0095】
<配信すべき空き情報の決定方法>
図13は、第2の実施形態における配信すべき空き情報の決定方法のフローチャートである。本実施形態では、ステップS202とS203の間に、判定部113によりステップS501が実行される点で、第1の実施形態と異なっている。ステップS201~S209については第1の実施形態と同じであるため、説明を省略する。
【0096】
(ステップS501)
ステップS202の後、判定部113は、店舗情報データベース242を参照して、処理対象店舗の所定時間2421を取得し、RAM13又は記憶装置14に格納する。そして、判定部113は、ステップS203において、ステップS202で取得した所定時間2421以内のユーザ投稿があるか否かを判断する。なお、所定時間2421を取得する本ステップ501は、処理対象店舗についてのユーザ投稿を取得するステップS204より前に実行されればよく、ステップS201の後に実行されてもよい。
【0097】
<第2の実施形態のまとめ>
回転率が高い施設について、ユーザ投稿を抽出するための所定時間が長いと、抽出したユーザ投稿の空き情報にばらつきが大きくなってしまうこともある。これに対し、第2の実施形態のように、施設の回転率に応じて、ユーザ投稿を抽出するための所定時間を変動させることにより、抽出されるユーザ投稿の空き情報のばらつきを小さくすることができるため、より信頼性の高いリアルタイムの空き情報を配信することができる。
【0098】
[第3の実施形態]
第1の実施形態においては、ステップS205において、店舗40の規模にかかわらず、所定数とユーザ投稿の数とを比較することを説明した。しかしながら、店舗40の収容キャパシティや店舗40の立地によっては、ユーザ投稿を利用する効果が得られにくくなる場合がある。例えば、人通りの多い地域にある店舗は付近にいるユーザも多い分、所定数を比較的高く設定した方がより正確に空き情報を決定できる。一方で、人の少ない地域にある店舗は付近にいるユーザが少ないので、所定数を高く設定するとユーザ投稿を第2の空き情報と設定することができず、ユーザに配信することができなくなる。あるいは、店舗内のキャパシティが多く待機中の人が多い場合は、その分、空き状況を投稿するユーザが増えるが、店舗内のキャパシティが少ない場合は、店舗の空き状況を投稿してくれるユーザは少ない傾向にある。そこで、第3の実施形態では、店舗ごとに所定数を設定する技術を提案する。
【0099】
<データベースの構成例>
図14は、第3の実施形態に係る店舗情報データベース342を示す図である。図14に示すように、店舗情報データベース342は、店舗40のキャパシティ3421をさらに構成項目として有している点で、第1の実施形態の店舗情報データベース142と異なっている。キャパシティ3421は、入力端末20の設定画面から店員が入力し空席管理サーバ10に送信するようにしてもよいし、空席管理システム1の提供者が店舗の規模に応じた値(デフォルト値)を予め店舗情報データベース342に入力するようにしてもよい。
【0100】
図15は、第3の実施形態に係る住所データベース345を示す図である。住所データベース345は、データベース141に格納される。図15に示すように、住所データベース345は、住所3451及び人通りの分類3452を構成項目として有している。住所3451は、例えば、都道府県、市区町村、区画(字)を含む。人通りの分類3452は、人通りの多いと見込まれる地域を「地域A」とし、人通りが平均的な地域を「地域B」とし、人通りが少ないと見込まれる地域を「地域C」とする。人通りの分類3452は、空席管理システム1の提供者が予め住所3451ごとに人通りの多さを分類し、住所データベース345に記憶させることができる。
【0101】
<配信すべき空き情報の決定方法>
図16は、第3の実施形態における配信すべき空き情報の決定方法のフローチャートである。本実施形態では、ステップS203とS204の間に、ステップS601が実行される点で、第1の実施形態と異なっている。ステップS201~S209については第1の実施形態と同じであるため、説明を省略する。
【0102】
(ステップS601)
判定部113は、店舗情報データベース342及び住所データベース345を参照して、ステップS205で用いる所定数を設定し、RAM13又は記憶装置14に格納する。
【0103】
<所定数の決定方法>
図17は、第3の実施形態のステップS601における所定数の決定方法のフローチャートである。
【0104】
(ステップS701)
判定部113は、店舗情報データベース342を参照して、処理対象店舗の住所1425と、キャパシティ3421とを取得し、RAM13又は記憶装置14に格納する。
【0105】
(ステップS702)
判定部113は、処理対象店舗のキャパシティが100人以上であるか否かを判断する。キャパシティが100人以上である場合(Yes)、処理はステップS708に移行する。キャパシティが100人未満である場合(No)、処理はステップS703に移行する。
【0106】
(ステップS703)
判定部113は、住所データベース345を参照して、処理対象店舗のキャパシティが50人以上であり、かつ、処理対象店舗の住所が地域Aであるか否かを判断する。キャパシティが50人以上であり、かつ地域Aである場合(Yes)、処理はステップS708に移行する。キャパシティが50人未満であるか、又は地域Aでない場合(No)、処理はステップS704に移行する。
【0107】
(ステップS704)
判定部113は、処理対象店舗のキャパシティが50人以上であり、かつ、処理対象店舗の住所が地域B又はCであるか否かを判断する。キャパシティが50人以上であり、かつ地域B又はCである場合(Yes)、処理はステップS707に移行する。キャパシティが50人未満であるか、又は地域B又はCでない場合(No)、処理はステップS705に移行する。
【0108】
(ステップS705)
判定部113は、処理対象店舗のキャパシティが10~50人であり、かつ、処理対象店舗の住所が地域Aであるか否かを判断する。キャパシティが10~50人であり、かつ地域Aである場合(Yes)、処理はステップS707に移行する。キャパシティが10~50人未満であるか、又は地域Aでない場合(No)、処理はステップS706に移行する。
【0109】
(ステップS706)
判定部113は、所定数を最小値(例えば3)に設定する。その後、所定数の設定処理は終了し、処理は上述のステップS205(図16)に移行する。
【0110】
(ステップS707)
判定部113は、所定数を中間値(例えば5)に設定する。その後、所定数の設定処理は終了し、処理は上述のステップS205(図16)に移行する。
【0111】
(ステップS708)
判定部113は、所定数を最大値(例えば10)に設定する。その後、所定数の設定処理は終了し、処理は上述のステップS205(図16)に移行する。
【0112】
<第3の実施形態のまとめ>
以上のように、第3の実施形態においては、判定部113は、処理対象店舗のそれぞれの住所及びキャパシティに応じて、所定数を設定する(ステップS601(ステップS701~S708))。このとき、キャパシティが大きい(100人以上)店舗の場合、地域性にかかわらず、所定数は大きく設定される(最大値)。キャパシティが小さい(10人未満)店舗の場合、地域性にかかわらず、所定数は小さく設定される(最小値)。それ以外の場合、キャパシティと地域性に応じて、所定数が設定される。設定された所定数は、ステップS205において、現在時刻から所定時間以内のユーザ投稿の数と比較され、ユーザ投稿が所定数以上であれば、ユーザ投稿が第2の空き情報として設定される。これにより、ユーザ投稿が多数見込める店舗に関しては、所定数を比較的大きくすることでユーザ投稿による空き情報の決定の精度を高くすることができる。ユーザ投稿が多数見込めない店舗であっても、所定時間内に複数のユーザから空き情報(ユーザの位置が近い場合にのみ投稿ができる)が投稿されている場合に限り、店舗の空き情報として採用されるので、ユーザ端末30に配信される空き情報の信頼性を保つことができる。
【0113】
<第3の実施形態の変形例>
第3の実施形態では、店舗のキャパシティ及び住所(地域性)に応じて、所定数を設定することを説明した。別の形態では、店舗ごとに、店舗に対応する所定数を予め設定し、店舗情報データベース142に記憶しておくようにすることができる。さらに別の形態では、各店舗に対応する所定数は、店舗に対応する変数に応じて、その都度(ステップS601)算出するようにしてもよい。さらにまた別の形態では、店舗のキャパシティ及び住所だけでなく、日時に応じても、所定数を設定することができる。例えば、郊外にあるスタジアムでイベントがある日は、イベントの終了後、スタジアム付近の飲食店の混雑が予想される。また、例えば、普段は人通りの少ない川沿いで花火大会が開催される場合、花火大会に出店する屋台についても、混雑が予想される。このような場合、店舗や施設のキャパシティと住所だけに基づいて所定数を設定すると、適切な空き情報を配信できなくなる可能性がある。そこで、イベントのある日時には所定数を大きく設定し、イベントのない日時には所定数を小さく設定することで、より適切な空き情報を配信することができる。
【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…ネットワーク
図1
図2A
図2B
図3A
図3B
図3C
図4A
図4B
図5A
図5B
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
【手続補正書】
【提出日】2022-08-03
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
施設のリアルタイムな空き状況を示す空き情報を配信する情報処理装置であって、
ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、
前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える情報処理装置。
【請求項2】
前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に含まれる空き情報のうち最大数の空き情報の数を前記所定数と比較する、請求項1に記載の情報処理装置。
【請求項3】
前記取得手段は、前記施設に対応する施設端末から送信された前記施設の前記空き情報を第1の空き情報として取得し、
前記決定手段は、前記所定時間以内に前記ユーザ端末から送信された空き情報群を取得し、前記空き情報群に基づいて第2の空き情報を決定し、前記第1の空き情報及び前記第2の空き情報のいずれかを、前記配信すべき前記空き情報として決定する、請求項1に記載の情報処理装置。
【請求項4】
前記決定手段は、前記取得手段が前記ユーザ端末から前記空き情報を取得していても、前記所定時間内に前記所定数以上の同じ前記空き情報を取得していない場合には、前記第1の空き情報を前記配信すべき前記空き情報として決定する、請求項3に記載の情報処理装置。
【請求項5】
施設に関する施設情報を記憶する記憶手段と、
前記施設情報に基づいて前記所定時間を設定する第1の設定手段と、をさらに備える請求項1~4のいずれか1項に記載の情報処理装置。
【請求項6】
前記第1の設定手段は、前記施設のジャンル情報に基づいて前記所定時間を設定する、請求項5に記載の情報処理装置。
【請求項7】
施設に関する施設情報を記憶する記憶手段と、
前記施設情報に基づいて前記所定数を設定する第2の設定手段と、をさらに備える請求項1~6のいずれか1項に記載の情報処理装置。
【請求項8】
前記第2の設定手段は、前記施設が収容可能な人数を示すキャパシティ情報に基づいて前記所定数を設定する、請求項7に記載の情報処理装置。
【請求項9】
前記第2の設定手段は、前記施設の位置に関する情報に基づいて前記所定数を設定する、請求項7に記載の情報処理装置。
【請求項10】
コンピュータを、請求項1~9のいずれか1項に記載の情報処理装置として機能させるプログラム。
【請求項11】
情報処理装置により実行される情報処理方法であって、
ユーザ端末から送信された、施設の空き状況を示す空き情報を取得することと、
前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定することと、を含む情報処理方法。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0006
【補正方法】変更
【補正の内容】
【0006】
上記課題を解決するために、本開示の情報処理装置は、施設のリアルタイムな空き状況を示す空き情報を配信する情報処理装置であって、ユーザ端末から送信された前記施設の空き情報を取得する取得手段と、前記施設の営業時間内、且つ、現在時刻から所定時間以内に前記ユーザ端末から送信された空き情報のうち、同じ空き状況を示す空き情報所定数以上である場合に、当該空き情報を、配信すべき前記空き情報として決定する決定手段と、を備える。