JP2018206145A - 予約システム - Google Patents

Abstract

【課題】利用者が希望するマッチング対象に加えて関連する別マッチング対象の情報をリアルタイムに生成して提供する。【解決手段】予約システムは、ホスト装置１の予約画面生成処理部１２により、利用者端末３からのマッチング対象の利用希望に応じて、第２記憶部ＤＢ２に保存されたマッチング対象の状態から該マッチング対象の予約画面を生成すると共に、第２記憶部ＤＢ２に保存された該マッチング対象に関連する別マッチング対象の状態から該別マッチング対象の予約画面を生成することを特徴とする。【選択図】図１

Description

本発明は、マッチング対象を時間貸しする提供者側に設けられた提供者端末と、該マッチング対象を時間借りする利用者側に設けられた利用者端末と、該提供者端末と該利用者端末との間で該マッチング対象の情報を仲介して該マッチング対象の予約をあっせんするホスト装置とを備える予約システムに関する。

従来、この種の予約システムとしては、下記特許文献１に示すように、本願出願人および発明者による、ホテルや旅館等の宿泊施設等におけるフロントコンピュータの画面から、その客室の状態（『在室』，『空室』，『清掃』等）のステータスを判定するシステムがある。

特許第５８１８０５０号公報

新規予約システムのパイオニアである本願出願人および発明者は、鋭意の試験・研究を繰り返す中で、従来の予約システムを応用する際に、利用者が希望するマッチング対象に加えて関連する別マッチング対象の情報をリアルタイムに生成して提供することで、予約の概念を変える画期的な予約が実現できるとの知見に至った。

本発明は、かかる知見に基づくものであり、利用者が希望するマッチング対象に加えて関連する別マッチング対象の情報をリアルタイムに生成して提供することを目的とする。

第１発明の予約システムは、マッチング対象を時間貸しする提供者側に設けられた提供者端末と、該マッチング対象を時間借りする利用者側に設けられた利用者端末と、該提供者端末と該利用者端末との間で該マッチング対象の情報を仲介して該マッチング対象の予約をあっせんするホスト装置とを備える予約システムにおいて、
前記提供者端末は、
前記マッチング対象の状態を取得するマッチング対象情報取得部と、
前記マッチング対象情報取得部により取得した前記マッチング対象の状態を前記ホスト装置に送信するマッチング対象情報送信部と、
前記利用者端末から送信された予約情報に基づいて予約を実行する予約実行部と
を備え、
前記ホスト装置は、
前記提供者端末から送信された前記マッチング対象の状態を保存するマッチング対象状態保存部と、
前記マッチング対象状態保存部に保存された前記マッチング対象の状態から、該マッチング対象の予約画面を生成する予約画面生成処理部を備え、
前記利用者端末は、
ホスト装置からダウンロードした予約プログラムに従って予約処理を実行する予約処理部を備え、
前記ホスト装置は、前記利用者端末からの前記マッチング対象の利用希望に応じて、前記マッチング対象状態保存部に保存された前記マッチング対象の状態から該マッチング対象の予約画面を生成すると共に、前記マッチング対象状態保存部に保存された該マッチング対象に関連する別マッチング対象の状態から該別マッチング対象の予約画面を生成し、
前記予約処理部は、前記ホスト装置の前記予約画面生成処理部により生成された前記予約画面から、前記利用者の前記マッチング対象の予約に応じた予約情報を前記提供者端末に送信する、
予約システムであって、
前記ホスト装置は、前記利用者端末からの前記マッチング対象の利用希望に際して、該マッチング対象に関連する別マッチング対象として、該利用希望の条件を満たす別マッチング対象の予約画面を生成すると共に、該利用者端末から特定される該利用者の特性情報が予約可能条件を満たす場合に、生成した該予約画面上において該マッチング対象および該別マッチング対象の予約を可能にすることを特徴とする。

第１発明の予約システムによれば、提供者端末側でマッチング対象の予約画面を個別に生成する場合には、利用者端末からのマッチング対象の利用希望に際して、該マッチング対象に関連する別マッチング対象の情報を一括してホスト装置から利用者端末に情報提供することが困難であるところ、本発明の予約システムでは、利用者端末からのマッチング対象の利用希望の時点で、マッチング対象の予約画面を生成すると共に、該マッチング対象に関連する別マッチング対象の予約画面を生成することで、利用者が希望するマッチング対象に加えて関連する別マッチング対象の情報をリアルタイムに生成して提供することができる。

ここで、マッチング対象は、空間（仮想空間含む）のほか、人や物（移動体含む）やサービスであってもよい。例えば、マッチング対象の利用希望の条件を満たす別マッチング対象として、これらの空間、人、物又はサービスの料金マッチング（利用者の予算、利用希望時間、利用可能人数）、設備マッチング（設備内容、種類（洋食・和食））、人材マッチング（サービス内容、保有資格）などに基づいて、マッチング度合いの高い別マッチング対象の予約画面を生成する。

このとき、生成されたマッチング対象の予約画面および別マッチング対象の予約画面は、利用者端末側に提供され確実に利用者に紹介されるところ、その一方で、予約可能条件を満たす場合にのみ、マッチング対象および別マッチング対象の予約を予約可能とする。例えば、予約可能条件としては、利用者の特性情報としての利用者端末の位置情報から、該位置情報とマッチング対象および別マッチング対象との距離を算出し、算出した該距離が所定の判定閾値（距離の判定閾値または、距離と利用時間組み合せによる判定閾値）の範囲内である場合に、予約可能とする場合のほか、利用者の特性情報としての個人情報（課員資格、性別、年齢、利用状況、利用金額）を利用可能条件として、予約可能としてもよい。

このように、第１発明の予約システムによれば、当該マッチング対象および関連する別マッチング対象の確実な紹介と、利用可能条件による適切な予約受付とを両立させることができ、利用者が希望するマッチング対象に加えて関連する別マッチング対象の情報をリアルタイムに生成して提供することができる。

なお、本予約システムを構成する提供者端末と、利用者端末と、ホスト装置とは、分散していてもよく、これらの一部または全部が一体に構成されてもよい。例えば、提供者端末とホスト装置とが一体に構成されてもよい。

また、ホスト装置から利用者端末への予約プログラムのダウンロードは、ホスト装置から利用者端末に直接ダウンロードされる場合のほか、アプリケーションを提供するサーバー等を介して間接的にダウンロードされてもよい。

第２発明の予約システムは、第１発明において、
前記予約処理部は、
前記ホスト装置の前記予約画面生成処理部により生成された前記マッチング対象の予約画面と、前記別マッチング対象の予約画面とを切り替え可能に表示することを特徴とする。

第２発明の予約システムによれば、ホスト装置からリアルタイムに提供された、利用者が希望するマッチング対象およびこれに関連する別マッチング対象の情報を、利用者端末の予約処理部がこれらの予約画面を切り替え可能に表示することで、利用者に当該マッチング対象および別マッチング対象の情報を具体的に提供することができる。

このように第２発明の予約システムによれば、利用者が希望するマッチング対象およびこれに関連する別マッチング対象の情報を利用者に具体的にリアルタイムに提供することができる。

なお、マッチング対象および別マッチング対象の予約画面の切り替えには、一覧表示された予約画面を頁区切りし、前頁と後頁とを切り替え可能にする場合のほか、タブ切り替え等の場合を含む。

本実施形態の予約システムの概要を示すシステム構成図。 図１の予約システムにおける処理内容を示すフローチャート。 図１の予約システムにおける処理内容を示すフローチャート。 図２の空間（マッチング対象）情報送信における処理内容を示すフローチャート。 図３の予約画面生成における処理内容を示すフローチャート。 図３の予約画面生成における付随的な処理内容を示すフローチャート。 図３の予約画面生成における処理内容を示す説明図。 図３の予約画面生成における処理内容を示す説明図。 図１の予約システムにおける処理内容を示すフローチャート。 図１の提供者端末の変形例を示す説明図。 図１０の提供者端末における処理内容を示すフローチャート。 図１０の提供者端末における処理内容を示す説明図。

図１に示すように、本実施形態の予約システムは、ホスト装置１と、提供者端末２と、利用者端末３とを備え、これらは、インターネット等のネットワークＮＷで接続されている。

ホスト装置１は、空間（マッチング対象）を時間貸しする提供者側に設けられた提供者端末２と、空間（マッチング対象）を時間借りする利用者側に設けられた利用者端末３との間で空間（マッチング対象）の利用をあっせんする。

ここで、空間（マッチング対象）としては、例えば、ホテルの客室、飲食店の個室や座席、興行における客席のほか、美容院や英会話教室などにおける予約等など、予約により一定の空間（マッチング対象）を一定時間占有するものをすべて包含する概念である。

まず、ホスト装置１は、第１記憶部ＤＢ１と、第２記憶部ＤＢ２と、第３記憶部ＤＢ３と、認証コード生成部１１と、予約画面生成処理部１２とを備える。

第１記憶部ＤＢ１は、利用者端末３にダウンロード可能とする予約プログラムを記憶するデータベースである。

第２記憶部ＤＢ２は、提供者端末２から送信された、空間（マッチング対象）の状態を含む空間（マッチング対象）情報を記憶するデータベースであり、本発明の空間（マッチング対象）状態保存部に相当する。

第３記憶部ＤＢ３は、認証済み利用者端末３のＩＤを記憶するデータベースであり、本発明の利用者端末ＩＤ保存処理部に相当する。

認証コード生成部１１は、利用者端末３との間で、利用者端末３のＩＤの認証と併せて、認証コードを発行する。これにより、ＩＤが認証済みの利用者端末３からのアクセスであるか否かを判定可能とする。

予約画面生成処理部１２は、第２記憶部ＤＢ２に記憶された空間（マッチング対象）情報に基づいて、該空間（マッチング対象）の予約画面を生成する。

提供者端末２は、例えば、ホテルなどの宿泊施設のおけるフロントコンピュータ２０に接続され、その客室（部屋番号により管理される客室）である空間（マッチング対象）を管理する端末装置であって、空間（マッチング対象）情報取得部２１と、空間（マッチング対象）情報送信部２２と、予約実行部２３と、管理部２４とを備える。

なお、提供者端末２とフロントコンピュータ２０とは、客室である空間（マッチング対象）の情報（例えば、各客室の『在室』，『空室』，『清掃』，『予約』等の情報）のデータが直接やり取りされることが好ましいが、データの外部出力のない旧式のフロントコンピュータ２０では、詳細を図１０〜図１２で後述するように、ビデオキャプチャーボード等を介して、フロントコンピュータ２０の画面を提供者端末２に取り込むことにより、その画面上の『在室』，『空室』，『清掃』，『予約』等の色分けされた領域の色彩情報をステータス情報に変換して、客室である空間（マッチング対象）の情報を提供者端末が取得するようにしてもよい。

空間（マッチング対象）情報取得部２１は、例えば、フロントコンピュータ２０から、客室である空間（マッチング対象）の現在の情報（例えば、各客室の『在室』，『空室』，『清掃』，『予約』等の情報）を取得する。

空間（マッチング対象）情報送信部２２は、空間（マッチング対象）情報取得部２１により取得された空間（マッチング対象）の状態の変更および空間（マッチング対象）に付随する情報の変化をホスト装置１に送信する。

予約実行部２３は、利用者端末から送信された予約情報に基づいて予約を実行する。

管理部２４は、詳細は後述するが、空間（マッチング対象）情報取得部により取得した空間（マッチング対象）の状態の変化を監視することにより、予約の状況を管理する。

利用者端末３は、例えば、ホテルなどの客室である空間（マッチング対象）を利用するユーザのスマートフォンやタブレット等のユーザ端末であって、予約処理部３１と、認証部３２とを備える。

予約処理部３１は、ホスト装置１からダウンロードした予約プログラムに従って予約処理を実行する。

認証部３２は、予約処理部３１による予約処理の実行に際して、利用者端末３との間で、利用者端末３のＩＤによる認証および認証コード生成部１１により生成された認証コードによる認証を行う。

以上が本実施形態の予約システムの構成である。なお、以上の構成において、予約システムのホスト装置１、提供者端末２および利用者端末３は、それぞれ例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only memory）、ＲＡＭ（Random Access Memory）等のハードウェアにより構成され、各処理部１１〜１２、２１〜２４，３１，３２による処理を実行するプログラムをメモリ（不図示）に記憶保持し、そのプログラムを実行することにより、上記制御処理を実行するための演算装置（シーケンサ）として機能する。

次に、図２〜図９を参照して、以上のように構成された予約システムの予約処理内容について説明する。

図２に示すように、まず、提供者端末２において、空間（マッチング対象）情報取得部２１が客室である空間（マッチング対象）の現在の状態（例えば、各客室の『在室』，『空室』，『清掃』，『予約』等の情報）を取得する（ＳＴＥＰ２１／図２）。

次に、提供者端末２の空間（マッチング対象）情報送信部２２が、ＳＴＥＰ２１で取得した空間（マッチング対象）の情報の変更および空間（マッチング対象）に付随する情報の変化をホスト装置１に送信する（ＳＴＥＰ２２／図２）。

図４に、ＳＴＥＰ２２の空間（マッチング対象）情報送信処理の具体的な処理内容を示す。

まず、空間（マッチング対象）情報送信部２２は、ＳＴＥＰ２１で取得した空間（マッチング対象）の現在の状態に変更があるか判定する（ＳＴＥＰ２２１／図４）。

そして、空間（マッチング対象）の現在の状態に変更がある場合には（ＳＴＥＰ２２１でＹＥＳ／図４）、変更がある状態パラメータをホスト装置１に送信する（ＳＴＥＰ２２２／図４）。

なお、ここでは、空間（マッチング対象）情報取得部２１により取得された空間（マッチング対象）の情報（各客室の『在室』，『空室』，『清掃』，『予約』等の情報）を適宜、変更した上で、状態パラメータをホスト装置１に送信する。例えば、『清掃』を『在室』に変更した上で、予約画面を生成することで、利用者にとって予約に不要な情報を削除することができる。

次に、部屋番号であるＲＯＯＭパラメータに変化があるか判定する（ＳＴＥＰ２２３／図４）。

そして、例えば、改装等で部屋番号が変更されるなど、ＲＯＯＭパラメータに変化がある場合には（ＳＴＥＰ２２３でＹＥＳ／図４）、ＲＯＯＭパラメータをホスト装置１に送信する（ＳＴＥＰ２２４／図４）。

次に、料金パラメータに変化があるか判定する（ＳＴＥＰ２２５／図４）。

そして、例えば、料金改定等で利用料金が変更されるなど、料金パラメータに変化がある場合には（ＳＴＥＰ２２５でＹＥＳ／図４）、料金パラメータをホスト装置１に送信する（ＳＴＥＰ２２６／図４）。

次に、店舗（ホテル）の登録情報（名称・住所・電話番号、緯度・経度等）である店舗パラメータに変化があるか判定する（ＳＴＥＰ２２７／図４）。

そして、店舗パラメータに変化がある場合には（ＳＴＥＰ２２７でＹＥＳ／図４）、店舗パラメータをホスト装置１に送信する（ＳＴＥＰ２２８／図４）。

以上の空間（マッチング対象）情報送信処理の詳細であり、空間（マッチング対象）情報送信部２２は、以上の一連の処理を一定の処理周期で繰り返し実行する。

次に、図２に戻って、ホスト装置１は、提供者端末２から送信された空間（マッチング対象）情報（付随情報を含む）を取得する（ＳＴＥＰ１０１／図２）。

そして、ホスト装置１は、取得した空間（マッチング対象）情報（付随情報を含む）を第２記憶部ＤＢ２に記憶し保存する（ＳＴＥＰ１０２／図２）。

ここで、利用者が空間（マッチング対象）の利用のためにホスト装置１にアクセス等して、空間（マッチング対象）の利用（予約）を希望すると（ＳＴＥＰ３０／図２）、予約に先だって、ホスト装置１の第１記憶部ＤＢ１に記憶された予約プログラムが当該利用者端末３に送信される（ＳＴＥＰ１００／図２）。

次いで、当該利用者端末３により予約プログラムが実行されることにより、利用者端末３に予約処理部３１が生成されると共に、予約処理部３１により当該予約プログラムに従った予約処理が開始される（ＳＴＥＰ３１／図２）。

次に、図３を参照して、予約処理部３１による予約処理の詳細について説明する。

まず、予約処理部３１は、予約処理の実行に先だって、利用者端末３のＩＤである電話番号の認証を行う（ＳＴＥＰ３１０／図３）。

ＩＤである電話番号の認証は、利用者端末３とホスト装置１との間で、第３記憶部ＤＢ３に記憶された認証済みＩＤ（電話番号）であるか否かにより判定される。

すなわち、まず、発信者である利用者端末３のＩＤが第３記憶部ＤＢ３に記憶された認証済みＩＤ（電話番号）と整合するか否かに加えて、利用者端末３からのＩＤ（電話番号）の入力が認証済みＩＤ（電話番号）と整合するかに否かにより、いずれも整合する場合に認証が完了する。

次いで、ＳＴＥＰ３１０の認証が完了すると、ホスト装置１の認証コード生成部１１により、認証コードが当該利用者端末３に発行される（ＳＴＥＰ１１０／図３）。

ここで、認証コードは、例えば、４桁の数字等で構成され、かかる認証コードは、音声ガイダンスによる読み上げやＳＭＳによる送信により利用者端末へ向けて発行される。

次に、認証コードの発行を受けた利用者端末３は、認証コードの認証を行う（ＳＴＥＰ３２０／図３）。具体的に、認証コードの発行を受けた利用者端末３は、認証コードの入力待ち状態となり、利用者が認証コードを入力することにより、認証コードとの整合は判定される。

次いで、ＩＤ（電話番号）に加えて、認証コードが整合することを条件として、予約処理部３１による予約処理が具体的に実行される（ＳＴＥＰ３３０／図３）。

ここでは、まず、利用者が希望する希望利用店舗、すなわち、希望する空間（マッチング対象）のリクエストが、利用者端末３からホスト装置１へ送信される。なお、ここでの利用希望（リクエスト）の送信では、利用者が希望する店舗（正確には店舗コード）のほか、利用者端末３の位置情報（ＧＰＳ情報）が併せて、ホスト装置１へ送信される。

なお、ここでの利用希望は、ＳＴＥＰ３０の利用者が空間（マッチング対象）の利用のためにホスト装置１にアクセス等して空間（マッチング対象）の利用（予約）の希望を行う処理と同一として、省略してもよい。

次に、利用者からの利用希望に基づいて、ホスト装置１の予約画面生成処理部１２が予約画面の生成処理を行う（ＳＴＥＰ１２０／図３）。

図５に、ＳＴＥＰ１２０の予約画面生成処理の具体的処理内容を示す。

まず、予約画面生成処理部１２は、利用者端末３から送信された利用希望を取得する（ＳＴＥＰ１２１／図５）。

次に、予約画面生成処理部１２は、取得した利用希望情報（店舗コード）から、利用者が利用を希望する店舗を特定する（ＳＴＥＰ１２２／図５）。

ここでは、利用を希望する店舗の登録情報（名称・住所・電話番号、緯度・経度、系列店舗関係情報等）を取得する。

次に、予約画面生成処理部１２は、ＳＴＥＰ１２２で特定した店舗に関連する店舗（本発明の別空間（マッチング対象）に相当する）の特定を行う（ＳＴＥＰ１２３／図５）。

ここで、関連する店舗としては、登録情報の緯度・経度に基づいて、ＳＴＥＰ１２２で特定した店舗よりも距離的に利用者端末３の位置に近い店舗を特定する。

また、関連する店舗として、登録情報の系列店舗情報に基づいて、例えば、同一オーナーや資本関係があるなどの系列店舗を特定する。

次に、予約画面生成処理部１２は、ＳＴＥＰ１２２で特定した店舗およびＳＴＥＰ１２３で特定した関連店舗の予約画面を生成する（ＳＴＥＰ１２４／図５）。

ここで、予約画面生成処理部１２は、予約画面の生成と併せて、図６に示す、予約可能可否判定を行う。

具体的には、図６に示すように、予約画面生成処理部１２は、まず、利用者端末３の位置情報（ＬＡ，ＬＯ）を取得する（ＳＴＥＰ１３１／図６）。なお、ここで取得する位置情報は、利用者端末３に内蔵されたＧＰＳにより特定される緯度，経度による位置情報である。

次いで、予約画面生成処理部１２は、ＳＴＥＰ１３１で取得した利用者端末３の位置と、ＳＴＥＰ１２２およびＳＴＥＰ１２３で特定した店舗および関連店舗（空間（マッチング対象）および別区間）の位置（ＨｏＬＡ，ＨｏＬＯ）との２点間距離を算出する（ＳＴＥＰ１３２／図６）。

なお、ここでの２点間の距離の算出方法は、種々の算出方法が採用され得るが、例えば、球面三角形に余弦法則した換算式を適用することができる。

次に、予約画面生成処理部１２は、ＳＴＥＰ１３２で算出した２点間距離が、距離判定閾値である予約可能範囲以内であるか判定する（ＳＴＥＰ１３３／図６）。

予約可能範囲は、任意設定することができるが、遠方など距離的に予約を実現することが不可能な利用を排除するように設定される。

そして、予約画面生成処理部１２は、２点間距離が、距離判定閾値である予約可能範囲以内でない場合には（ＳＴＥＰ１３３でＮＯ／図６）、当該予約可能可否の判定処理を終了する。

一方、予約画面生成処理部１２は、２点間距離が、距離判定閾値である予約可能範囲以内である場合には（ＳＴＥＰ１３３でＹＥＳ／図６）、ＳＴＥＰ１３２で算出した２点間距離が、距離判定閾値である敷地範囲以上であるか判定する（ＳＴＥＰ１３４／図６）。

ここでの敷地範囲も任意に設定することができるが、既に、空間（マッチング対象）である宿泊施設を利用している場合を排除するように設定される。

そして、予約画面生成処理部１２は、２点間距離が、距離判定閾値である敷地範囲以上でない場合には（ＳＴＥＰ１３４でＮＯ／図６）、当該予約可能可否の判定処理を終了する。

一方、予約画面生成処理部１２は、２点間距離が、距離判定閾値である敷地範囲以上である場合に（ＳＴＥＰ１３４でＹＥＳ／図６）、図７および図８で後述するように、当該空間（マッチング対象）である宿泊施設の空室に対して予約ボタンを表示し、当該宿泊施設の予約を可能とする（ＳＴＥＰ１３５／図６）。

このように本実施形態の予約システムにおける予約方法によれば、利用者端末３と空間（マッチング対象）との距離に応じて予約の可否を決定することで、遠方など距離的に予約を実現することが不可能な利用を排除して、利用者端末３から簡易かつ確実に予約を行うことができる。

さらに、遠方の場合を排除するように、利用者と空間（マッチング対象）との距離判定閾値を一定の距離範囲内に制限する場合のほか、既に、空間（マッチング対象）を利用している場合を排除するように、利用者と空間（マッチング対象）との距離判定閾値を一定の距離範囲外に制限することもできる。

このように、利用者と空間（マッチング対象）との距離に着目することにより利用者端末から予約の可否を簡易かつ確実に判断することができる。

なお、距離に応じた予約の制限については、本実施形態のように、予約ボタンの表示の有無による場合のほか、予約ボタンを表示した上で、ボタンを押せない状態とする場合や予約ボタンを表示したままで、ボタンを押した際に、警報を発する等の制限により、予約の可否を実現するようにしてもよい。

次に、図５戻って、予約画面生成処理部１２は、ＳＴＥＰ１２４で生成した特定店舗およびその関連店舗の予約画面の並べ替えを行い（ＳＴＥＰ１２５／図５）、並べ替えられた予約画面は、利用者端末３に送信される（ＳＴＥＰ１２６／図５）。

予約画面の並べ替えは、初期設定にもよるが、ＳＴＥＰ１２３で特定した距離的に利用者端末３に近い複数の関連店舗を、（ＳＴＥＰ１２２で特定した特定店舗も含めて）利用者端末３に近い順番に並べ替えを行う。

このほか、予約画面の並べ替えは、ＳＴＥＰ１２３で関連店舗として特定した系列店舗を、ＳＴＥＰ１２２で特定した店舗から近い順に並べ替えるようにしてもよい。

図７および図８に、ＳＴＥＰ１２４で生成した予約画面およびＳＴＥＰ１２５で並び変えを行った予約画面の例を示す。

図７では、上述のように、ＳＴＥＰ１２２で特定した店舗およびＳＴＥＰ１２３で特定した関連店舗の予約画面を、利用者端末３に近い順番に並べ替えた場合である。

図７では、上から１頁目に利用者端末３にもっとも近い店舗の予約画面が表示され、２頁目に次に近い店舗の予約画面が表示されている。以下、利用者端末からの距離の近い順に頁が構成されている。

図８では、ＳＴＥＰ１２３で関連店舗として特定した系列店舗を、ＳＴＥＰ１２２で特定した店舗から近い順に並べ替えたものである。

図８Ａでは、上から１頁目にＳＴＥＰ１２２で特定された店舗（Ａホテル）の予約画面が表示され、２頁目にＡホテルに近い系列店舗（Ｂホテル）の予約画面が表示される。

そして、図８Ｂに示すように、ＡホテルとＢホテルとは、表示が相互に切り替え可能となっている。

なお、補足説明すると、図８Ａおよび図８Ｂでは、一覧表示された予約画面を頁区切りし、前頁と後頁とを切り替え可能にしているが、これに限定されるものではなく、各頁の下にタブを表示し、タブを介して切り替え可能に構成してもよい。

ここで、図７および図８では、利用者端末３との店舗と距離に基づく予約可能可否判定の結果により、空室に対して予約ボタンが表示され、当該宿泊施設の予約が可能となっている。

以上が、予約画面生成処理部１２による予約画面の生成処理の詳細である。

次に、図３に戻って、予約画面生成処理部１２により生成された予約画面が利用者端末３に送信されると、予約処理部３１により予約画面が利用者端末３に表示される。

かかる予約画面に従って、利用者がかかる予約ボタンによる予約を行うと、予約リクエストが提供者端末２に送信され、当該予約リクエストを提供者端末２が受信する（ＳＴＥＰ２３／図３）。

予約リクエストには、少なくとも、利用者端末３のＩＤである電話番号のほか、予約ボタンが操作された部屋番号が含まれる。

次いで、ＳＴＥＰ２３で予約リクエストを提供者端末２が受信すると、提供者端末２の予約実行部２３により、予約実行処理が開始される。

具体的に、予約実行部２３は、（必要に応じて、ホスト装置１のサーバを介したアクセスであるかを認証した上で）、予約リクエストに含まれる利用者端末３のＩＤである電話番号の認証をホスト装置１との間で行う（ＳＴＥＰ２４／図３）。

ここでの認証は、予約リクエストに含まれるＩＤが、ホスト装置１の第３記憶部ＤＢ３に記憶された認証済みＩＤ（電話番号）と整合するか否かにより判定される。

次に、ＳＴＥＰ２４の認証がされると、予約実行部２３は、空間（マッチング対象）情報を再取得する（ＳＴＥＰ２５／図３）。

ここで、予約実行部２３が、空間（マッチング対象）情報を再取得するのは、利用者端末３による予約処理（ＳＴＥＰ３１（ＳＴＥＰ３１０〜３３０））の実行中に、当該空間（マッチング対象）が利用不可能となっている場合に予約登録がされることを防止するためである。

そして、予約実行部２３は、ＳＴＥＰ２５による再取得後の空間（マッチング対象）情報でも予約可能な場合には、予約リクエストに基づく予約情報を当該提供者端末２に登録する（ＳＴＥＰ２６）。

次に、予約実行部２３は、予約操作の実行を行う（ＳＴＥＰ２７）。具体的に、予約操作の実行は、例えば、自動対応可能である場合には、フロントコンピュータ２０に対して、予約を実行する。一方、自動対応となっていない場合には、フロント担当者に対して、音声ガイダンスまたは画面アシストにより、フロントコンピュータ２０に予約の操作を促す。

そして、予約実行部２３は、ＳＴＥＰ２６の予約操作の実行が完了すると、予約結果を利用者端末３に送信する。

これにより、利用者端末３は、予約結果を受信し、予約結果を利用者に報知する（ＳＴＥＰ３５０／図３）。

なお、ここでの予約結果は、ＳＴＥＰ２６で予約操作の実行が完了した場合のほか、ＳＴＥＰ２４〜２６でエラーが発生して予約が失敗した場合の予約失敗通知の場合もあり得る。

以上が、本実施形態の予約システムにおける予約処理の内容である。

かかる本実施形態の予約システムによれば、例えば、宿泊施設等の店舗である提供者端末２側で客室（空間（マッチング対象））の予約画面を個別に生成する場合には、利用者端末３からの利用希望に際して、関連する店舗の別客室（別空間（マッチング対象））の情報を一括してホスト装置１から利用者端末３に一括して情報提供することが困難であるところ、本予約システムでは、利用者端末３からの客室（空間（マッチング対象））の利用希望の時点で、客室（空間（マッチング対象））の予約画面を生成すると共に、その店舗に関連する店舗の別客室（別空間（マッチング対象））の予約画面を生成することで、利用者が希望する客室（空間（マッチング対象））に加えて関連する店舗の別客室（別空間（マッチング対象））の情報をリアルタイムに生成して提供することができる。

次に、図９を参照して、かかる予約処理に付随して、提供者端末２の管理部２４により実行される空間（マッチング対象）である客室の管理方法について説明する。なお、管理部２４は、一定の処理周期で、以下の処理を繰り返し実行する。

まず、管理部２４は、利用者端末３から提供者端末２に送信された予約リクエストが受信後に、未処理になっているかチェックする（ＳＴＥＰ４０／図９）。

かかる予約リクエストの未処理は、空間（マッチング対象）情報取得部２１により取得される空間（マッチング対象）である客室の状態を監視することにより、例えば、空室から予約済みへの変更が一定時間内に完了しないことにより判定してもよく、一定時間内に予約結果を提供者端末２から利用者端末３に送信が完了しているか否かにより判定されてもよい。

そして、予約リクエストが未処理の場合には（ＳＴＥＰ４０でＹＥＳ／図９）、提供者端末２から警報発信する（ＳＴＥＰ４１／図９）。

これにより、例えば、予約操作の実行（ＳＴＥＰ２７／図３）が、手動の場合に、フロント担当者に対して、フロントコンピュータ２０に予約の操作を促すことができる。また、万一、提供者端末２に不具合が生じている場合にもこれをフロント担当者に早期に報知することができる。

一方、予約リクエストが未処理でない場合には（ＳＴＥＰ４０でＮＯ／図９）、来店待ち時間を経過したかチェックする（ＳＴＥＰ４２／図９）。

かかる来店待ち時間の経過の有無は、予約処理（ＳＴＥＰ３４０で予約操作／図３）から、予め設定または指定された来店までの時間（例えば４０分）の経過により判定される。

そして、来店待ち時間が経過している場合には（ＳＴＥＰ４２でＹＥＳ／図９）、警報を発信して（ＳＴＥＰ４３／図９）、フロント担当者に来店待ち時間が経過していることを報知すると共に、予約の取り消しを行うかをフロント担当者に選択させる（ＳＴＥＰ４４／図９）。

ここで、予約の取り消しをフロント担当者が選択すると（ＳＴＥＰ４４でＹＥＳ／図９）、取消通知を提供者端末２から利用者端末３に送信して（ＳＴＥＰ４７／図９）、予約をクリアして初期化する（ＳＴＥＰ５０／図９）。

一方、予約の取り消しをフロント担当者が選択しない場合には（ＳＴＥＰ４４でＮＯ／図９）、来店待ち時間を延長する（ＳＴＥＰ４５／図９）。

次に、（ＳＴＥＰ４５で来店待ち時間が延長された場合を含めて）来店待ち時間が経過していない場合には（ＳＴＥＰ４２でＮＯ／図９）、管理部２４は、来店確認のチェックを行う（ＳＴＥＰ４６／図９）。

来店確認は、空間（マッチング対象）情報取得部２１により取得される空間（マッチング対象）である客室の状態を監視することにより、例えば、利用者が来店して入室することにより状態が予約済みから在室に変更されたか否かにより判定される。

そして、来店確認のチェックにより来店が確認されない場合には（ＳＴＥＰ４６でＮＯ／図９）、来店が確認されるまで、上記処理ＳＴＥＰ４０にリターンしてＳＴＥＰ４０〜４６の処理を繰り返し実行する。

一方、来店確認のチェックにより来店が確認されると（ＳＴＥＰ４６でＹＥＳ／図９）、来店済みフラグを立てた上で（ＳＴＥＰ４８／図９）、退出確認のチェックを行う（ＳＴＥＰ４９／図９）。

退出確認は、空間（マッチング対象）情報取得部２１により取得される空間（マッチング対象）である客室の状態を監視することにより、例えば、利用者が来店して在室になっている状態から清掃中に変更された否かにより判定される。

そして、退出確認のチェックにより退出が確認されない場合には（ＳＴＥＰ４９でＮＯ／図９）、退出が確認されるまで、当該処理を繰り返し実行する。

一方、退出確認のチェックにより退出が確認された場合には（ＳＴＥＰ４９でＹＥＳ／図９）、当該予約による空間（マッチング対象）である客室の利用が終了したものとして、予約をクリアする（ＳＴＥＰ５０／図９）。

以上が、予約処理に付随して、提供者端末２の管理部２４により実行される空間（マッチング対象）である客室の管理方法の詳細である。

かかる管理部２４により、提供者端末２の空間（マッチング対象）情報取得部２１により取得した空間（マッチング対象）の状態を監視することで、予約実行が完了したかにより予約の実行を監視することができる。さらに、予約通りに空間（マッチング対象）が利用されているか監視することで、予約に基づく利用状況を監視することができる。

これにより、利用者の特定により利用者端末３から簡易かつ確実に空間（マッチング対象）の予約を行うことができるにとどまらず、確実な予約の実行および予約に基づく適切な利用を実現することができる予約システムを提供することができる。

以上詳しく説明したように、本実施形態の予約システムによれば、当該空間（マッチング対象）および関連する別空間（別マッチング対象）の確実な紹介と、利用可能条件による適切な予約受付とを両立させることができる。

すなわち、利用者が希望する空間（マッチング対象）に加えて関連する別空間（別マッチング対象）の情報をリアルタイムに生成して提供する場合には、空間的、物理的、属性的に明らかに利用が不可能な場合にも予約ができてしまうとの不都合が生じ得るところ、利用可能条件に基づいて利用が可能な場合に、予約画面上において予約可能とすることで、その空間および別空間の利用を必要とする利用者にのみ、予約を実行可能にすることができると共に、利用可能条件から利用が不可能な場合でも予約画面の作成が行われるため、当該空間（マッチング対象）に加えて関連する別空間（別マッチング対象）の紹介を確実に行うことができる。 なお、本実施形態では、マッチング対象が空間の場合について説明したが、マッチング対象は空間に限定されるものではなく、仮想空間のほか、人や物（移動体含む）やサービスであってもよい。例えば、マッチング対象の利用希望の条件を満たす別マッチング対象として、これらの空間、人、物又はサービスの料金マッチング（利用者の予算、利用希望時間、利用可能人数）、設備マッチング（設備内容、種類（洋食・和食））、人材マッチング（サービス内容、保有資格）などに基づいて、マッチング度合いの高い別マッチング対象の予約画面を生成してもよい。

また、本実施形態では、予約可能条件として、利用者の特性情報としての利用者端末の位置情報から、該位置情報とマッチング対象および別マッチング対象との距離を算出し、算出した該距離が所定の判定閾値（距離の判定閾値）の範囲内である場合に、利用可能とする場合について説明したが、これに限定されるものではなく、距離と利用時間組み合せによる判定閾値（例えば、サービス開始時間に到着可能か）のほか、利用者の特性情報としての個人情報（課員資格、性別、年齢、利用状況、利用金額）を利用可能条件として、予約可能としてもよい。

最後に、図１０〜図１２を参照して、説明を後回しにした、データの外部出力のない旧式のフロントコンピュータ２０に対して、提供者端末２が備えるステータス判定システムとしての機能について説明する。

モニタ画面上のステータス情報を取得するステータス判定システムは、
前記モニタ画面をキャプチャして画像として連続的に取得する画像取得手段と、
前記画像取得手段により取得された前記画像に対して、該画像がステータス情報を取得すべき画像であるか判定する画像判定手段と、
前記画像判定手段により前記画像がステータス情報を取得すべき画像と判定された場合に、該画像の特定ポイントの色彩情報を取得する色彩情報取得手段と、
前記色彩情報取得手段により取得された前記特定ポイントの色彩情報をステータス情報に変換するステータス変換手段と
を備え、
前記ステータス変換手段は、前記特定ポイントの色彩情報が前記連続的に取得した画像間で同一の場合に、前記色彩情報取得手段により取得された前記特定ポイントの色彩情報をステータス情報に変換する。

具体的には、図１０に示すように、ステータス判定システムは、モニタ２０Ｘ画面上のステータス情報を取得するシステムであって、画像取得手段２１０と、画像処理手段２１５と、画像判定手段２２０と、色彩情報取得手段２３０と、ステータス変換手段２４０と、ステータス情報送信手段２５０とを備える。

なお、ステータス情報送信手段２５０は、外部サーバ等にステータス情報を送信する場合に使用されるが、提供者端末２自体が備える通信機能によりこれを省略してもよい。

判定対象となるモニタ２０Ｘの画面は、例えば、宿泊施設におけるフロントコンピュータ２０Ｙの画面であって、例えば、画面上には、部屋毎に区画された領域に『在室』，『空室』，『清掃』，『予約』等が色分けして表示される（図１２参照）。

画像取得手段２１０は、アダプタ装置２０Ｗを介して、モニタ２０Ｘ上の画面をキャプチャして取得する。アダプタ装置２０Ｗは、フロントコンピュータ２０Ｙとそのモニタ２０Ｘとを接続するモニタケーブル（ＶＧＡケーブル）２０Ｚのアナログ画像信号を一定の周期でサンプリングした画像データとしてステータス判定システムに出力する。

アダプタ装置２０Ｗは、例えば、ＶＧＡビデオキャプチャーボードのほか、ビデオキャプチャーボートと併せてＶＧＡ分配ケーブルとしての機能を備えていてもよい。また、アダプタ装置２０Ｗは、ＶＧＡケーブルからのビデオキャプチャーに限られるものではなく、ビデオ（Ｓ-Video方式またはcomposite方式）入出力ケーブルからキャプチャを行うビデオキャプチャーボード、デジタルディスプレイ用のＤＶＩキャプチャーボード、業務用ビデオや防犯カメラ用のＳＤＩキャプチャーボード、映像機器一般のＨＤＭＩ（登録商標）キャプチャーボード等であってもよい。

画像処理手段２１５は、アダプタ装置２０Ｗを介して取得したキャプチャ画像（実際には、所定の周期で出力される各キャプチャ画像）に対して、フィルタ処理を施す。

フィルタ処理は、例えば、ＲＧＢＡ変換であって、キャプチャ画像を特定の色数による画像に変換する。なお、フィルタ処理は、ＲＧＢＡ変換の他、色数の少ないＰＮＧ変換等であってもよい。

画像判定手段２２０は、画像処理手段２１５によりフィルタ処理が施されたキャプチャ画像がステータス情報を取得すべき画面であるか判定する。

具体的に、画像判定手段２２０は、フィルタ処理が施されたキャプチャ画像上の特定除外ポイントの色彩情報に基づいて、当該キャプチャ画像がステータス情報を取得すべき画像であるかを判定する。

なお、特定除外ポイントは、画像上の座標位置（Ｘ，Ｙ）として予め設定可能であって、かかる座標位置の色彩情報（ＲＧＢデータ）を画像判定手段２２０が取得し、かかる色彩情報（ＲＧＢデータ）が除外色（特定範囲のＲＧＢ成分）である場合には、ステータス情報を取得すべき画像でないと判定される。

色彩情報取得手段２３０は、画像判定手段２２０によりキャプチャ画像がステータス情報を取得すべき画像と判定された場合に、当該キャプチャ画像の特定ポイントの色彩情報を取得する。

なお、色彩情報取得手段２３０による（キャプチャ画像上の）特定ポイントの色彩情報の取得手法については、詳細を後述する。

ステータス変換手段２４０は、色彩情報取得手段２３０により取得された特定ポイントの色彩情報（ＲＧＢデータ）を変換テーブル等によりステータス情報（『在室』，『空室』，『清掃』，『予約』等）に変換する。

なお、ステータス変換手段２４０による色彩データからステータス情報への変換は、ステータスのコード情報への変換であってもよい。

ステータス情報送信手段２５０は、ステータス変換手段２４０により変換されたステータス情報（『在室』，『空室』，『清掃』，『予約』等）をインターネット等のネットワークＮＷを介して外部サーバ等に送信する。

以上の構成において、ステータス判定システムは、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only memory）、ＲＡＭ（Random Access Memory）等のハードウェアにより構成され、上記処理手段２１０〜２５０による処理を実行するプログラムをメモリ（不図示）に記憶保持し、そのプログラムを実行することにより、上記制御処理を実行するための演算装置（シーケンサ）として機能する。

次に、図１１を参照して、以上のように構成されたステータス判定システムによるステータス情報の取得処理方法について説明する。

まず、ステータス判定システムは、画像取得手段２１０により、アダプタ装置２０Ｗを介して、モニタ２０Ｘ上の画面をキャプチャした画像（実際には、一定周期でキャプチャした連続画像）として取得する（ＳＴＥＰ２１０／図１１）。

次に、ステータス判定システムは、画像処理手段２１５により、ＳＴＥＰ２１０で取得したキャプチャ画像に対してフィルタ処理を施し、キャプチャ画像を特定色数のＲＧＢデータへ変換する（ＳＴＥＰ２１５／図１１）。

次いで、ステータス判定システムは、画像判定手段２２０により、ＳＴＥＰ２１５でフィルタ処理を施したキャプチャ画像（ＲＧＢＡデータ変換済み）に対して、そのキャプチャ画像（正確には、連続するキャプチャ画像の１つのフレーム画像）がステータス情報を取得すべき画面であるか判定する（ＳＴＥＰ２２０／図１１）。

具体的に、画像判定手段２２０は、図１２Ａおよび図１２Ｂに示す、特定除外ポイント（ＩＩＩ）の色彩情報を取得し、取得した色彩情報（ＲＧＢデータ）が、除外色（特定範囲のＲＧＢ成分）であるか判定し、除外色（特定範囲のＲＧＢ成分）でない場合には、ステータス情報を取得すべき画面であると判定する（ＳＴＥＰ２２０でＹＥＳ／図１１）。

例えば、図１２Ａの場合には、特定除外ポイント（ＩＩＩ）の色彩情報には、他の操作画面等に特徴的な除外色がないため、ステータス情報を取得すべき画面であると判定される。

一方、画像判定手段２２０は、特定除外ポイント（ＩＩＩ）の色彩情報（ＲＧＢデータ）が、除外色（特定範囲のＲＧＢ成分）である場合には、ステータス情報を取得すべき画像ではないと判定する（ＳＴＥＰ２２０でＮＯ／図１１）。

例えば、図１２Ｂの場合には、特定除外ポイント（ＩＩＩ）の色彩情報には、他の操作画面等に特徴的な除外色が含まれるため、ステータス情報を取得すべき画像でないと判定される。

このように、特定除外ポイントの色彩情報に基づいて、当該モニタ画面の画像がステータス情報を取得すべき画像であるか判定することで、ステータス判定を行うべき画像を簡易かつ確実に特定することができる。

なお、特定除外ポイントは、画像上の座標位置（Ｘ，Ｙ）として予め設定可能であるが、特定除外ポイントは、１点であってもよいが、判定精度を向上させるためには、複数の特定除外ポイントを設定し、複数の特定除外ポイントに色彩情報に基づいて、ステータス情報を取得すべき画像であるか判定することが好ましい。

これにより、例えば、複数の特定ポイントの色彩情報の１部に除外色が含まれていればこれをステータス情報を取得すべき画像ではないと判定することができ、他の操作画面が画像上の一部に重畳的に表示されている場合にも、これを確実に除外することができる。

次に、画像判定手段２２０により、キャプチャ画像がステータス情報を取得すべき画面であると判定された場合には（ＳＴＥＰ２２０でＹＥＳ／図１１）、色彩情報取得手段２３０により、キャプチャ画像の特定ポイントの色彩情報を取得する（ＳＴＥＰ２３０／図１１）。例えば、図１２Ａの場合には、特定ポイント（Ｉ），（ＩＩ）の色彩情報を取得する。

一方で、画像判定手段２２０により、キャプチャ画像がステータス情報を取得すべき画面でないと判定された場合には（ＳＴＥＰ２２０でＮＯ／図１１）、ＳＴＥＰ２１０にリターンする。

ここで、色彩情報取得手段２３０は、予め２０１号室および２０２号室に対応する特定ポイント（Ｉ）および（ＩＩ）として設定された画像上の座標位置（Ｘ，Ｙ）の画素（ピクセル）の色彩情報（ＲＧＢデータ）に加えて、その周囲の画素の色彩情報（ＲＧＢデータ）を取得する。

例えば、色彩情報取得手段２３０は、特定ポイントの座標位置（Ｘｎ，Ｙｎ）の色彩情報に加えて、これを取り囲む（Ｘｎ−１，Ｙｎ−１）、（Ｘｎ，Ｙｎ−１）、（Ｘｎ＋１，Ｙｎ−1），（Ｘｎ−１，Ｙｎ），（Ｘｎ＋１，Ｙｎ）、（Ｘｎ−１，Ｙｎ＋１）、（Ｘｎ，Ｙｎ＋１）、（Ｘｎ＋１，Ｙｎ＋１）の８点の画素の色彩情報（ＲＧＢデータ）も取得する。

次に、色彩情報取得手段２３０は、取得した特定ポイントおよびその周囲の色彩情報（ＲＧＢデータ）に対して、色彩情報処理を施す（ＳＴＥＰ２３５／図１１）。

ここでの色彩情報処理は、取得した特定ポイントおよびその周囲の色彩情報（ＲＧＢデータ）から、その特定ポイントの色彩（ＲＧＢ）を総合的に決定するものである。

例えば、ＳＴＥＰ２３０で、特定ポイントの座標位置（Ｘｎ，Ｙｎ）の色彩情報に加えて、これを取り囲む（Ｘｎ−１，Ｙｎ−１）、（Ｘｎ，Ｙｎ−１）、（Ｘｎ＋１，Ｙｎ−1），（Ｘｎ−１，Ｙｎ），（Ｘｎ＋１，Ｙｎ）、（Ｘｎ−１，Ｙｎ＋１）、（Ｘｎ，Ｙｎ＋１）、（Ｘｎ＋１，Ｙｎ＋１）の８点の画素の周辺色彩情報（ＲＧＢデータ）を取得している場合には、これら９点の色彩情報（ＲＧＢデータ）を平均化した平均色（ＲＧＢ）を算出する。

このように、予め設定した特定ポイントの座標位置の特定色彩情報のみならず、これを取り囲む周辺座標の周辺色彩情報を取得して、特定色彩情報と周辺色彩情報とに基づいて次のステータス情報への変換を行うことで、例えばアナログ画面等で生じる色にじみがあっても、周辺色彩情報で補完して確実にステータス情報への変換を行うことができる。

次に、ステータス変換手段２４０は、ＳＴＥＰ２３５で色彩情報処理が施された特定ポイントの色彩情報（ＲＧＢデータ）をステータス情報（『在室』，『空室』，『清掃』，『予約』等）に変換する（ＳＴＥＰ２４０／図１１）。

具体的に色彩情報（ＲＧＢデータ）からステータス情報への変換は、変換テーブルにより実行される。

例えば、変換テーブルは、色彩情報（ＲＧＢデータ）に応じて、赤色の場合には宿泊、黄色の場合には休憩、青色の場合には空室、緑色の場合には清掃中、水色の場合には清掃待ち、桃色の場合は誘導・会計のように対応関係が形成されている。

さらに、変換テーブルは、上述のように１段階の変換テーブルでもよいが、一旦変換したステータスを２段階で再変換するようにしてもよい。例えば、２段階の再変換テーブルは、宿泊と休憩との場合は併せて在室、清掃中と清掃待ちとの場合は併せて清掃中のように対応関係が形成される。

これにより、ステータスの種類を少なくすることができ、外部送信する際にその種類を限定することができる。

例えば、図１２Ａの場合には、かかる変換テーブルにより、２０１号室に対応する特定ポイント（Ｉ）については、（画像上緑色の領域であり）、対応するステータスとして『清掃』またはそのコード情報に変換される。同様に、２０２号室に対応する特定ポイント（ＩＩ）については、（画像上赤色の領域であり）、対応するステータスとして『在室』またはそのコード情報に変換される。

なお、ステータス変換手段２４０は、そのキャプチャ画像（正確には、連続するキャプチャ画像の１つのフレーム画像）に対してステータス情報への変換を行ってもよいが、ステータス情報がフレーム周期で生成されることから、連続するキャプチャ画像（例えば１０フレーム）の特定ポイント（Ｉ），（ＩＩ）が同一の場合にのみ、ステータス変換処理を実行するようにすることが好ましい。

また、本実施形態では、特定色彩（赤色、黄色、青色、・・）から変換テーブルにより対応するステータスへ変換を行ったが、これに限定されるものではなく、色値の差による比較検査方法を適用してよい。

この場合、色のバラツキ成分（２５５段階）で認める閾値をAとし、判定用テーブルのRGBの各成分をRC・RG・RBとし、取得したRGB値の各成分をR・G・Bとする。

そして、
(R+A) < RC
(R-A) > RC
(G+A) < GC
(G-A) > GC
(B+A) < BC
(B-A) > BC
の６個の条件がすべて真の場合に、取得したRGBは判定用テーブルRGBに一致すると判定して変換を行うようにしてもよい。これにより、論理式の演算のみであるため、処理を高速化させることができる。

最後に、ステータス情報送信手段２５０は、ＳＴＥＰ２４０により変換されたステータス情報（『在室』，『空室』，『清掃』，『予約』等）またはそのコード情報を特定ポイント（２０１号室、２０２号室）と関連付けてインターネット等のネットワークＮＷを介して外部サーバ等に送信し（ＳＴＥＰ２５０／図１１）、ＳＴＥＰ２１０にリターンする。

以上がステータス判定システムによるステータス情報の取得処理方法の詳細であり、かかるステータス判定システムによれば、モニタ２０Ｘ画面からその画面上のステータス情報を簡易かつ確実に取得することができる。

なお、本実施形態では、予約画面生成処理部１２により、予約画面の生成と併せて、図６に示す予約可能可否判定を行う場合について説明したが、これに限定されるものではなく、利用者端末３の予約処理部３１により、ホスト装置１から利用者端末３に送信された予約画面を利用者端末３に表示する際に、予約処理部３１が予約可能可否の判定処理を行い、予約ボタンの表示の可否を決定するようにしてもよい。

さらに、本実施形態では、予約プログラムは、予約システムのホスト装置１の第１記憶部ＤＢ１に記憶され、ホスト装置１からダウンロードする場合について説明したがこれに限定されるものではなく、提供者端末２にデータベースを設け、提供者端末２からダウンロード可能に構成してもよい。

また、本実施形態において、利用者端末３のＩＤが電話番号である場合について説明したが、これに限定されるものではなく、利用者端末３の個体識別番号であれば、利用者端末（スマートフォン等の情報端末）に割り当てられた個別ビーコン識別番号等であってもよい。

さらに、本実施形態では、判定対象となるモニタ２０Ｘの画面として、宿泊施設におけるフロントコンピュータ２０Ｙの画面の例について説明したが、これに限定されるものではない。

例えば、各種制御システムにおけるモニタ画面や、駐車場の駐車区画やホール内の座席を撮影したカメラの撮像画像等に適用することができる。

また、本実施形態では、ＳＴＥＰ２３５で特定ポイントおよびその周囲の色彩情報（ＲＧＢデータ）に対して色彩情報処理を施す場合について説明したが、これに限定されるものではなく、画像処理手段２１５により、（１）ＳＴＥＰ２１５のフィルタ処理を施すと共に、（２）フィルタ処理後の画像に対して、予め（ｉ）特定ポイントおよびその周囲の色彩情報に加えて、（ｉｉ）特定除外ポイントおよびその周囲の色彩情報を取得し、それぞれについて色彩情報処理を施すようにしてもよい。

この場合、ＳＴＥＰ２３５の色彩情報処理を画像処理手段２１５によるフィルタ処理と併せて一括して行うことになり、処理効率を向上させることができると共に、特定除外ポイントによるＳＴＥＰ２２０のステータス情報を取得すべき画面であるか否かの判定精度を向上させることができる。

１…ホスト装置、２…提供者端末、３…利用者端末、１１…認証コード生成部、１２…予約画面生成処理部、２１…空間（マッチング対象）情報取得部、２２…空間（マッチング対象）情報送信部、２３…予約実行部、２４…管理部、３１…予約処理部、３２…認証部、ＤＢ１…第１記憶部、ＤＢ２…第２記憶部、ＤＢ３…第３記憶部、ＮＷ…ネットワーク。

Claims (2)

1. マッチング対象を時間貸しする提供者側に設けられた提供者端末と、該マッチング対象を時間借りする利用者側に設けられた利用者端末と、該提供者端末と該利用者端末との間で該マッチング対象の情報を仲介して該マッチング対象の予約をあっせんするホスト装置とを備える予約システムにおいて、
   前記提供者端末は、
   前記マッチング対象の状態を取得するマッチング対象情報取得部と、
   前記マッチング対象情報取得部により取得した前記マッチング対象の状態を前記ホスト装置に送信するマッチング対象情報送信部と、
   前記利用者端末から送信された予約情報に基づいて予約を実行する予約実行部と
   を備え、
   前記ホスト装置は、
   前記提供者端末から送信された前記マッチング対象の状態を保存するマッチング対象状態保存部と、
   前記マッチング対象状態保存部に保存された前記マッチング対象の状態から、該マッチング対象の予約画面を生成する予約画面生成処理部を備え、
   前記利用者端末は、
   ホスト装置からダウンロードした予約プログラムに従って予約処理を実行する予約処理部を備え、
   前記ホスト装置は、前記利用者端末からの前記マッチング対象の利用希望に応じて、前記マッチング対象状態保存部に保存された前記マッチング対象の状態から該マッチング対象の予約画面を生成すると共に、前記マッチング対象状態保存部に保存された該マッチング対象に関連する別マッチング対象の状態から該別マッチング対象の予約画面を生成し、
   前記予約処理部は、前記ホスト装置の前記予約画面生成処理部により生成された前記予約画面から、前記利用者の前記マッチング対象の予約に応じた予約情報を前記提供者端末に送信する、
   予約システムであって、
   前記ホスト装置は、前記利用者端末からの前記マッチング対象の利用希望に際して、該マッチング対象に関連する別マッチング対象として、該利用希望の条件を満たす別マッチング対象の予約画面を生成すると共に、該利用者端末から特定される該利用者の特性情報が予約可能条件を満たす場合に、生成した該予約画面上において該マッチング対象および該別マッチング対象の予約を可能にすることを特徴とする予約システム。
2. 請求項１記載の予約システムにおいて、
   前記予約処理部は、
   前記ホスト装置の前記予約画面生成処理部により生成された前記マッチング対象の予約画面と、前記別マッチング対象の予約画面とを切り替え可能に表示することを特徴とする予約システム。