JP2014109859A - 予約支援装置のプログラム、予約支援システム、予約支援装置の制御方法、及び、予約支援装置 - Google Patents

Abstract

【課題】１人予約の際のユーザの作業負担を軽減するとともに、ユーザの希望に合った１人予約情報を提示可能な機能を提供する。
【解決手段】ユーザの使用に係る端末装置と通信可能な予約支援装置において、端末装置における入力の内容を解析する。その解析結果に応じて所定の内容を応答する。所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断し、予約に必要な情報が充足されていないと判断された場合には、必要な情報の入力を促す内容を応答する。一のユーザの予約として、予約人数が１人の予約が登録された場合には、少なくとも予約に係る場所と日付が同じで、予約人数が１人である他のユーザの予約の登録を検出し、他のユーザの予約の登録が検出された場合には、他のユーザの登録された予約の内容を端末装置に応答可能とする。
【選択図】図１

Description

本発明は、予約処理の支援を行う技術に関する。

従来、ゴルフ場等の予約システムは、特定のフォームにユーザが必要事項をすべて入力し、サーバに送信することで予約の申込みを行っていた。例えばゴルフ場予約の場合、各ゴルフ場の予約情報を参照してプランや空き枠情報を自ら確認し、そのうえで所定のフォームに移行して予約申し込みを行うことになる。また、近年においては、空き時間を有効に利用したい、あるいは、ゴルフ仲間とのスケジュール調整が困難等の理由から、プレーヤーが１人の場合でもゴルフ場の予約が可能な、いわゆる１人予約の申込みが行われることがある。１人予約の場合には、特定のフォームにユーザが必要事項をすべて入力すると共に、同組ラウンドのプレーヤーが異性であることの可否、スコアが同レベル、上レベル、下レベルのいずれと組むのを希望するか、年齢は同輩、年配、若輩のいずれを希望するか等の希望条件を予約入力する。そして、ゴルフ場の予約システムは、他の当日プレーヤーのデータと比較判定して同組のスタート時間を決定するようにしている（例えば、特許文献１）。

特開２００３−２４８７７１号公報

しかし、例えばあるゴルフ場の空き枠情報を参照して気に入ったプランや空き枠がなかった場合、ユーザはサイトのページに戻って別のゴルフ場の空き枠情報を参照しなければならず、操作が煩雑となっていた。
また、一旦別のページに遷移しなければ他のゴルフ場の空き枠情報が見られなかったため、比較を行い難いという問題もあった。
特に、１人予約が可能なゴルフ場はまだ少ないため、希望に合った空き枠情報を探し出すのは困難であった。
さらに、特許文献１の方法では、ゴルフ場の予約システムが同組のプレーヤーやスタート時間を決めてしまうため、ユーザの希望に合わないこともあった。
本発明は、この点に鑑みてなされたものであり、１人予約の際のユーザの作業負担を軽減するとともに、ユーザの希望に合った１人予約情報を提示可能な機能を提供することなどを解決課題とする。

以上の課題を解決するために本発明が採用する手段を以下に説明する。なお、本発明の理解を容易にするために以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。

上述した課題を解決するため、本発明に係る予約支援装置のプログラムは、ユーザの使用に係る端末装置（２）と通信可能で、コンピュータを備える予約支援装置（１）のプログラムであって、前記コンピュータを、
所定のアクティビティに関する予約に必要な情報の前記端末装置（２）における入力を促す問合わせ部（１０）と、前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部（１２）と、前記判断部（１２）により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部（１５）と、前記空き枠検索部（１５）による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置に応答可能な応答部（１１）と、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け可能な受付部（１３）と、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部（１４）として機能させることを特徴とする。

この発明において、１人での予約が可能な空き枠は、定員が１人で未予約の枠のほか、定員が２人以上であって１人ずつの予約が認められている枠において定員に達していない場合を含む概念である。当該空き枠を示す情報としては、例えば、空き枠フラグが用いられる。空き枠の提示は、一つだけの提示、リストのような複数の提示、一つ一つの順次の提示を含む概念である。登録には、コナミサーバでの仮登録、予約サーバへの登録要求を含む概念である。

上述した予約支援装置のプログラムにおいて、ユーザの使用に係る端末装置（２）と通信可能で、コンピュータを備える予約支援装置（１）のプログラムであって、前記コンピュータを、所定のアクティビティに関する予約に必要な情報の前記端末装置（２）における入力を促す問合わせ部（１０）と、前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部（１２）と、前記判断部（１２）により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部（１５）と、前記空き枠検索部（１５）による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザの予約の内容を検出する予約検出部（１８）と、前記予約検出部（１８）により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置（２）に応答可能な応答部（１１）と、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け可能な受付部（１３）と、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部（１４）として機能させることを特徴とする。

この発明において、１人での予約が可能な空き枠は、定員が１人で未予約の枠のほか、定員が２人以上であって１人ずつの予約が認められている枠において定員に達していない場合を含む概念である。当該空き枠を示す情報としては、例えば、空き枠フラグが用いられる。空き枠の提示は、一つだけの提示、リストのような複数の提示、一つ一つの順次の提示を含む概念である。登録には、コナミサーバでの仮登録、予約サーバへの登録要求を含む概念である。他のユーザの登録された予約の内容は、性別、年齢等を含む概念である。空き枠の内容は、場所、日時、プラン、既に予約済みの人数等を含む概念である。
なお、「枠」とは、予めゴルフ場によって設定された、ゴルフを行うプレーヤーが登録をすることができる概念的な位置を指し、１つのゴルフ場の、１つのスタート日時且つ１つのスタートホールにおいては、一般的には４つの枠が存在する。但し４つの枠に限らなくともよい。また空き枠とは、プレーヤーの登録がされていない枠を指す。

上述した予約支援装置のプログラムにおいて、前記コンピュータを、前記空き枠検索部（１５）による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザについての情報を抽出する情報抽出部（１７）として更に機能させ、前記応答部（１１）は、前記他のユーザの登録された予約の内容と共に、前記抽出した前記他のユーザについての情報を前記端末装置（２）に応答可能であるようにしてもよい。この発明において、ユーザについての情報は、ユーザにより任意に入力されるメッセージを含む概念である。

上述した予約支援装置のプログラムにおいて、前記コンピュータを、過去に登録された予約の内容の中に、前記ユーザの住所に関する情報を検索する住所検索部（１９）として更に機能させ、前記空き枠検索部（１９）は、前記住所検索部（１９）による検索結果として前記ユーザの住所に関する情報が抽出された場合には、当該抽出された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置のプログラムにおいて、前記問合わせ部（１０）は、前記住所検索部（１９）による検索結果として前記ユーザの住所に関する情報が抽出されなかった場合には、前記ユーザの住所に関する情報の前記端末装置（２）における入力を促し、前記空き枠検索部（１５）は、前記端末装置（２）において入力された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置のプログラムにおいて、前記コンピュータを、過去に登録された予約の内容の中に、前記ユーザによる過去の予約の内容を検索する予約検出部（１８）として更に機能させ、前記空き枠検索部（１５）は、前記予約検出部（１８）による検索結果として前記ユーザによる過去の予約の内容が抽出された場合には、当該抽出された過去の予約の内容に含まれる会場についての空き枠の中から、前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置のプログラムにおいて、前記空き枠検索部（１５）は、検索を行う日を基準として予め設定された規則に基づいて日程的条件を設定し、当該設定した日程的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置のプログラムにおいて、前記受付部（１３）は、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における非承認の入力についても受け付け、前記問合わせ部（１０）は、前記受付部（１３）により前記非承認の入力を受け付けた場合には、前記ユーザに対して前記予約に必要な情報の前記端末装置（２）における入力を促し、前記空き枠検索部（１５）は、前記端末装置（２）において入力された情報に基づいて、１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置のプログラムにおいて、前記問合わせ部（１０）は、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、他のユーザ宛ての情報の前記端末装置（２）における入力を促すようにしてもよい。

上記プログラムは、コンピュータが読み取り可能な記録媒体に記憶させても良い。この記録媒体を用いれば、例えば上記コンピュータに上記プログラムをインストールすることができる。ここで、上記プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であっても良い。

上述した課題を解決するため、本発明に係る予約支援システムは、ユーザの使用に係る端末装置（２）と、当該端末装置（２）と通信可能な予約支援装置（１）とを備える予約支援システムであって、前記端末装置（２）は、所定のアクティビティに関する予約に必要な情報の入力を行う情報入力部（２７）と、前記予約の申込みの入力を行う申込み入力部（２８）とを備え、前記予約支援装置（１）は、前記所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部（１０）と、前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部（１２）と、前記判断部（１２）により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部（１５）と、前記空き枠検索部（１５）による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置（２）に応答可能な応答部（１１）と、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け可能な受付部（１３）と、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部（１４）とを備えることを特徴とする。

上述した課題を解決するため、本発明に係る予約支援装置の制御方法は、ユーザの使用に係る端末装置（２）と通信可能な予約支援装置（１）の制御方法であって、所定のアクティビティに関する予約に必要な情報の前記端末装置（２）における入力を促し、前記予約に必要な情報のうち予約人数が１人かどうかを判断し、予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索し、前記検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置（２）に提示し、前記提示した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け、前記予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行うことを特徴とする。

上述した課題を解決するため、本発明に係る予約支援装置は、ユーザの使用に係る端末装置（２）と通信可能な予約支援装置（１）であって、所定のアクティビティに関する予約に必要な情報の前記端末装置（２）における入力を促す問合わせ部（１０）と、前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部（１２）と、前記判断部（１２）により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部（１５）と、前記空き枠検索部（１５）による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置（２）に応答可能な応答部（１１）と、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け可能な受付部（１３）と、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部（１４）とを備えることを特徴とする。

上述した課題を解決するため、本発明に係る予約支援装置は、ユーザの使用に係る端末装置（２）と通信可能な予約支援装置（１）であって、所定のアクティビティに関する予約に必要な情報の前記端末装置（２）における入力を促す問合わせ部（１０）と、前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部（１２）と、前記判断部（１２）により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部（１５）と、前記空き枠検索部（１５）による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザの予約の内容を検出する予約検出部（１８）と、前記予約検出部（１８）により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置（２）に応答可能な応答部（１１）と、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における予約の申込みの入力を受け付け可能な受付部（１３）と、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部（１４）と、前記予約検出部（１８）により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置（２）に応答可能な応答部（１１）とを備えることを特徴とする

上述した予約支援装置において、前記空き枠検索部（１５）による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザについての情報を抽出する情報抽出部（１７）を更に備え、前記応答部（１１）は、前記他のユーザの登録された予約の内容と共に、前記抽出した前記他のユーザについての情報を前記端末装置（２）に応答可能であるようにしてもよい。

上述した予約支援装置において、過去に登録された予約の内容の中に、前記ユーザの住所に関する情報を検索する住所検索部（１９）を更に備え、前記空き枠検索部（１５）は、前記住所検索部（１９）による検索結果として前記ユーザの住所に関する情報が抽出された場合には、当該抽出された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置において、前記問合わせ部（１０）は、前記住所検索部（１９）による検索結果として前記ユーザの住所に関する情報が抽出されなかった場合には、前記ユーザの住所に関する情報の前記端末装置（２）における入力を促し、前記空き枠検索部（１５）は、前記端末装置（２）において入力された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置において、過去に登録された予約の内容の中に、前記ユーザによる過去の予約の内容を検索する予約検出部（１８）を更に備え、前記空き枠検索部（１５）は、前記予約検出部（１８）による検索結果として前記ユーザによる過去の予約の内容が抽出された場合には、当該抽出された過去の予約の内容に含まれる会場についての空き枠の中から、前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置において、前記空き枠検索部（１５）は、検索を行う日を基準として予め設定された規則に基づいて日程的条件を設定し、当該設定した日程的条件に基づいて前記１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置において、前記受付部（１３）は、前記応答部（１１）により応答した前記空き枠に対する前記端末装置（２）における非承認の入力についても受け付け、
前記問合わせ部（１０）は、前記受付部（１３）により前記非承認の入力を受け付けた場合には、前記ユーザに対して前記予約に必要な情報の前記端末装置（２）における入力を促し、前記空き枠検索部（１５）は、前記端末装置（２）において入力された情報に基づいて、１人での予約が可能な空き枠を検索するようにしてもよい。

上述した予約支援装置において、前記問合わせ部（１０）は、前記受付部（１３）により予約の申込みの入力を受け付けた場合には、他のユーザ宛ての情報の前記端末装置（２）における入力を促すようにしてもよい。

本発明の第１実施形態に係る予約支援装置が使用される環境を説明するためのブロック図である。 本発明の第１実施形態の予約支援装置の構成を示すブロック図である。 本発明の第１実施形態の端末装置の構成を示すブロック図である。 予約サーバに記憶されるプラン情報のテーブルの一例を示す図である。 予約サーバに記憶される空き枠情報のテーブルの一例を示す図である。 予約サーバに記憶される予約情報のテーブルの一例を示す図である。 予約サーバに記憶されるコメント情報のテーブルの一例を示す図である。 外部サーバに記憶されるユーザ情報のテーブルの一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 予約支援装置の動作の一例を示すフローチャートである。 予約支援装置の動作の一例を示すフローチャートである。 予約支援装置の動作の一例を示すフローチャートである。 予約支援装置の動作の一例を示すフローチャートである。 本発明の第２実施形態における予約支援装置の動作の一例を示すフローチャートである。 第２実施形態の端末装置における表示画面の一例を示す図である。 本発明の第３実施形態における予約支援装置の動作の一例を示すフローチャートである。 本発明の第４実施形態の端末装置における表示画面の一例を示す図である。 第４実施形態の端末装置における表示画面の一例を示す図である。 第４実施形態に係る予約支援装置が使用される環境を説明するためのブロック図である。 第４実施形態における端末装置の動作の一例を示すフローチャートである。 変形例の予約支援装置の動作の一例を示すフローチャートである。 変形例の端末装置における表示画面の一例を示す図である。 変形例の予約支援装置の動作の一例を示すフローチャートである。

以下、実施形態として、本発明に係る予約支援装置について、図面を参照しつつ説明する。
＜第１実施形態＞
＜１．予約支援装置の概要＞
図１は、本発明の第１実施形態に係る予約支援装置の一例としての予約支援サーバ１が用いられる環境を説明するためのブロック図である。本実施形態においては、一例として、予約支援サーバ１がユーザとの対応を通じてゴルフ場の予約を行う場合について説明する。
予約支援サーバ１の詳細については後述する。図１に示すように、予約支援サーバ１は、インターネットなどの通信網ＮＥＴを介して、外部管理サーバ３、マップサーバ４、予約サーバ５のそれぞれに対して通信可能になっている。また、予約支援サーバ１と端末装置２は、通信網ＮＥＴ及び外部管理サーバ３を介して通信可能になっている。

予約サーバ５は、プラン情報テーブル５ａ、空き枠情報テーブル５ｂ、予約情報テーブル５ｃ、及びコメント情報テーブル５ｄとを備えている。予約サーバ５は、各ゴルフ場に対応するゴルフ場端末（図示せず）と通信可能であり、プラン情報テーブル５ａ、空き枠情報テーブル５ｂ、予約情報テーブル５ｃ、及びコメント情報テーブル５ｄには、各ゴルフ情報ごとに区別されたプラン情報、空き枠情報、予約情報及びコメント情報がそれぞれ記憶されている。

図４にプラン情報テーブル５ａの一例を示す。図４に示すように、プラン情報テーブル５ａには、プラン名、条件、料金、曜日設定が記録されている。例えば、条件の一例としては、図４に示すように、２サムが保証されているか否か、即ち、２人で予約した場合、他の１人や２人と組み合わせにならないことを保証されているか否かが含まれる。その他にも、料金に昼食代が含まれているか、カート使用が可能か否か、及び、キャディ付きか否かが含まれている。曜日設定は、そのプランが平日用なのか土日祝日用なのかを示している。図４に示す例では、平日用のフィールドと、土日祝日用のフィールドが設けられており、フラグによって管理されている。つまり、平日用のフィールドのフラグが１の場合には、そのプランが平日用であり、土日祝日用のフィールドのフラグが１の場合には、そのプランが土日祝日用であることを示している。但し、上記のように２つのフィールドを設けなくても、１つのフィールドにおいて、フラグが０の場合にそのプランが平日用で、フラグが１の場合にそのプランが土日祝日用であると判断することとしてもよい。さらに、プランが平日用なのか土日祝日用なのかを区別する方法はフラグに限定されるものではなく、どのような方法でもよい。

図５に空き枠情報テーブル５ｂの一例を示す。空き枠情報テーブル５ｂには、図５に示すように、スタートＩＤごとに、日付、スタート時間、スタートコース、空き枠フラグ、及び１人予約枠フラグが関連付けられて記憶されている。空き枠フラグの値が１の場合には、空き枠があることを示しており、空き枠フラグの値が０の場合には、予約が入っていることを示している。

スタートコースのフィールドに示される「ＯＵＴ」とは、ホール番号１のホールからラウンドが開始されることを示し、「ＩＮ」とは、ホール番号１０のホールからラウンドが開始されることを示している。但し、ゴルフ場によっては、東コース（１〜９番）、西コース（１〜９番）、南コース（１〜９番）等となっていることもあり、この場合には空き枠情報テーブル５ｂのスタートホールのフィールドには、「東」、「西」、「南」、若しくはこれらを意味する記号等が記憶されることになる。一般的に、コースによって回る順番は決まっており、例えば東コースからスタートすれば後半は西コース、西コースからスタートすれば後半は南コース、南コースからスタートすれば後半は東コース等と決まっているため、スタートコースが特定されれば足りる。

なお、本実施形態では、図４に示すプラン情報と、図５に示す空き枠情報とは一対一で対応している訳ではなく、例えば、９月６日（平日）で空き枠フラグが１の枠を選択した場合には、図４に示すプラン情報のうち、曜日設定フラグが１のプランであれば、いずれのプランも選択が可能になっている。
１人予約枠フラグは、各空き枠が１人予約に対応しているかどうかを示すフラグである。本実施形態では、１人予約枠フラグが１であれば、その空き枠は１人予約に対応しており、１人予約枠フラグが０であれば、その空き枠は１人予約に対応していないことを示している。

図６に予約情報テーブル５ｃの一例を示す。予約情報テーブル５ｃには、図６に示すように、予約ＩＤ、予約者名、予約者ＵＩＤ、連絡先、スタートＩＤ、人数、同伴者名が記憶される。なお、これ以外の情報を記憶するようにしてもよい。図６において、同伴者名のフィールドに「null」となっているのは、まだ同伴者の名前が登録されていないことを示している。同伴者名は予約と同時に登録しても良いし、後から追加的に登録・変更してもよい。

予約情報テーブル５ｃにおいて予約ＩＤが記憶されると、その予約ＩＤとして記憶されたスタートＩＤに対応する空き枠情報テーブル５ｂの空き枠フラグは１から０に変更される。

図７にコメント情報テーブル５ｄの一例を示す。コメント情報テーブル５ｄには、図７に示すように、予約ＩＤ、プレーヤー１ＩＤ、プレーヤー１のコメント、プレーヤー２ＩＤ、プレーヤー２のコメント、プレーヤー３ＩＤ、プレーヤー３のコメント、プレーヤー４ＩＤ、プレーヤー４のコメントが記憶される。なお、これ以外の情報を記憶するようにしてもよい。

後述するように、１人予約を行うプレーヤーは、同じ枠に予約を行い、一緒にプレーすることになる他の１人予約を行うプレーヤーに対してコメントを残すことができる。そこで、本実施形態では、１人予約を行ったプレーヤーのＩＤと、そのコメントとを関連付けてコメント情報テーブル５ｄに記憶させるようにしている。なお、図７において、プレーヤーＩＤのフィールドに「null」となっているのは、プレーヤーの予約登録がまだ行われていないことを示している。また、図７において、コメントのフィールドに「null」となっているのは、コメントが残されていないことを示している。
なお、図７のコメント情報テーブル５ｄに記憶される予約ＩＤは、予約情報テーブル５ｃに記憶される予約ＩＤと同一の予約ＩＤである。

本実施形態における予約サーバ５は、各ゴルフ場のゴルフ場端末（図示せず）からアクセスが可能となっており、各ゴルフ場のゴルフ場ＩＤと関連付けてプラン情報テーブル５ａ、空き枠情報テーブル５ｂ、予約情報テーブル５ｃ、及びコメント情報テーブル５ｄが記憶されている。

ユーザは、予約サーバ５に直接アクセスすることによってプラン情報や空き枠情報を参照し、予約を行うことが可能であるが、本実施形態では、後述するように、チャットサービスを介して予約を行うようになっている。詳しくは後述する。

なお、ゴルフ場端末（図示せず）は、各ゴルフ場に設けられており、各ゴルフ場においてゴルフ場の管理者等がゴルフ場端末を操作して設定されたプラン情報や枠情報などの内容が記憶されるようになっている。また、ゴルフ場端末は予約サーバ５と通信可能になっている。

ゴルフ場端末は、予約サーバ５に定期的にアクセスし、予約サーバ５に記憶された自分のゴルフ場の予約情報、空き枠情報を取得し、ゴルフ場端末に記憶された空き枠情報テーブル、及び予約情報テーブルを更新する。

外部管理サーバ３は、インターネットなどの通信網ＮＥＴを介した音声通話、チャット、及び、メール等の、メッセージの送受信が可能なメッセージ送受信サービスを提供する。本実施形態において説明するチャットサービスは、端末装置２のユーザ本人と、他の１名以上のユーザとで、リアルタイムでテキストメッセージや音声メッセージを送受信するチャットサービスを想定している。
外部管理サーバ３には、ユーザ情報テーブル３ａが備えられており、本実施形態におけるユーザ情報テーブル３ａには、図８に示すように、ユーザアカウント、ユーザにより登録されたユーザ名、認証された電話番号情報、登録されたＥメールアドレス、プロフィール画像が関連付けて記憶されている。また、ユーザ自身が設定したユーザＩＤがあれば、そのユーザＩＤも関連付けて記憶されている。なお、ユーザアカウントは当該チャットサービスにユーザが登録したときに、外部管理サーバ３がユーザ毎に割り当てる識別子である。図８においては「ＵＩＤ」がユーザアカウントに該当する。また、電話番号またはメールアドレスが「null」となっているものは、該当する項目はユーザ情報テーブル３ａに登録されていないことを示す。また、プロフィール画像は画像データへのリンク情報が記憶されている。

本実施形態では、後述する予約支援サーバ１が、チャットサービスにおける専用アカウントとして登録されており、チャットサービスにおいて他のユーザとの対話が可能になっている。つまり、あるユーザが前記専用アカウントと友達になると、外部管理サーバ３は当該ユーザと前記専用アカウントとの関連付けを行い、当該ユーザが端末装置２から送信したメッセージは、外部管理サーバ３を介して前記専用アカウントである予約支援サーバ１にて受信され、また、前記専用アカウントである予約支援サーバ１から送信したメッセージは、外部管理サーバ３を介して当該ユーザの端末装置２にて受信される。詳しくは後述する。

また同様に、一のユーザが他のユーザと友達になると、外部管理サーバ３は当該一のユーザと他のユーザとの関連付けを行い、当該一のユーザが端末装置２から送信したメッセージは、外部管理サーバ３を介して前記他のユーザの端末装置２にて受信され、また、前記他のユーザの端末装置２から送信したメッセージは、外部管理サーバ３を介して前記一のユーザの端末装置２にて受信される。詳しくは後述する。

マップサーバ４は、地図情報テーブル４ａと施設情報テーブル４ｂとを備えている。地図情報テーブル４ａには、位置情報（緯度経度情報）と関連付けて地図情報が記憶されている。施設情報テーブル４ｂには、位置情報（緯度経度情報）と関連付けて施設名称等の情報が関連付けて記憶されている。

マップサーバ４は、予約支援サーバ１から所定の要求を受信すると、この要求に関する処理を行うと共に、結果を予約支援サーバ１に送信する。所定の要求とは、上述のように住所情報から位置情報を特定する要求や、位置情報から所定範囲内の距離にあるゴルフ場を検索してリストを提示する要求である。これらの要求は、例えば所定のＡＰＩ（Application Program Interface）を用いて実行される。

端末装置２は、通信網ＮＥＴを介した通信が可能であり、例えば、パーソナルコンピュータ、携帯電話機、スマートフォン、タブレット端末などが該当する。端末装置２には、通信網ＮＥＴ上で公開されているウェブページを表示可能なブラウザソフトウェアがインストールされており、ブラウザソフトウェアを用いることにより、ＨＴＭＬデータ等を端末装置２上にウェブページとして表示させることができる。また、端末装置２には、外部管理サーバ３によって提供されるメッセージ送受信サービス用のアプリケーションソフトウェアが予めインストールされており、このアプリケーションソフトウェアを用いることにより、上述したチャットサービスを利用することが可能になっている。

端末装置２にはキーボード、あるいはタッチパネル等の情報入力部２７が備えられており、この情報入力部２７を利用して、ウェブページや前記メッセージ送受信サービス用のアプリケーションソフトウェアの入力欄等に文字データ等を入力することができる。また、この情報入力部２７を利用して、予約に必要な情報の入力を行うことができる。端末装置２には、キーボード、あるいはタッチパネル等の申込み入力部２８が備えられている。この申込み入力部２８を利用して予約の申込みの入力を行うことが可能となっている。なお、図１においては、一つの端末装置２のみを示しているが、複数の端末装置２が通信網ＮＥＴに接続されている。

予約支援サーバ１は、上述したように外部管理サーバ３によって提供されるメッセージ送受信サービスにおける専用アカウントとして登録されており、ユーザが端末装置２にインストールされたメッセージ送受信サービス用のアプリケーションソフトウェアを利用して前記専用アカウントと友達になり、当該アプリケーションソフトウェアを利用して前記専用アカウントにメッセージを送信した場合には、前記専用アカウントである予約支援サーバ１は、当該メッセージに応答することができる。

予約支援サーバ１は、問合わせ部１０、応答部１１、判断部１２、受付部１３、登録部１４、空き枠検索部１５、記憶部１６、情報抽出部１７、予約検出部１８、及び住所検索部１９とを備えている。問合わせ部１０、応答部１１、判断部１２、受付部１３、登録部１４、空き枠検索部１５、情報抽出部１７、予約検出部１８、及び住所検索部１９は、予約支援サーバ１が予約支援サーバのプログラムを実行することにより発揮される機能ブロックである。

問合わせ部１０は、ゴルフ場の予約に必要な情報の端末装置２における入力を促す。具体的には、後述するように端末装置２における予約人数の入力を促す。また、問合わせ部１０は、後述する住所検索部１９による検索結果としてユーザの住所に関する情報が抽出されなかった場合には、ユーザの住所に関する情報の端末装置２における入力を促す。さらに、問合わせ部１０は、後述する受付部１３により予約の申込みの入力を受け付けた場合には、他のユーザ宛ての情報の端末装置２における入力を促す。

応答部１１は、端末装置２における入力の内容を解析し、解析結果に応じて所定の内容を応答したり、解析結果として、一のユーザから送信されたメッセージの宛先として自身（予約支援サーバ１）以外の他のユーザが含まれていることが検出された場合、登録部１４において仮登録された情報を当該一のユーザ及び当該他のユーザに対して応答したりする。この場合、応答部１１は応答する内容（報告文）を作成する機能も有する。また、応答部１１は、後述する空き枠検索部１５による検索結果として空き枠が抽出された場合には、空き枠の内容を端末装置２に対して応答するようになっている。さらに、応答部１１は、予約に必要な情報の項目について候補を提示する。また、後述する予約検出部１８により他のユーザの予約の内容が検出された場合に、空き枠の内容として、他のユーザの登録された予約の内容を端末装置２に応答可能となっている。また、応答部１１は、他のユーザの登録された予約の内容と共に、後述する情報抽出部１７により抽出された他のユーザについての情報を端末装置２に応答可能となっている。

判断部１２は、一例として、ゴルフ場の予約に必要な情報が充足されたか否かを判断する。また、判断部１２は、予約に必要な情報が充足されていないと判断した場合には、必要な情報の入力を促す内容を応答部１１により応答させる。さらに、判断部１２は、予約に必要な情報のうち予約人数が１人かどうかを判断する。

受付部１３は、応答部１１により応答した空き枠に対する端末装置２における予約の申込みの入力を受け付ける。また、受付部１３は、応答部１１により応答した空き枠に対する非承認の入力についても受け付ける。

登録部１４は、判断部１２により予約に必要な情報が充足されたと判断され、受付部１３により予約の申込みの入力を受け付けた場合には、予約に必要な情報を予約支援サーバ１において仮登録し、または、予約サーバ５に登録する。また、応答部１１により、仮登録されている情報が否定されたと判断された場合には、登録部１４は当該仮登録された情報を削除する。

空き枠検索部１５は、判断部１２により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する。また、空き枠検索部１５は、後述する住所検索部１９による検索結果としてユーザの住所に関する情報が抽出された場合、あるいは、端末装置２においてユーザの住所に関する情報が入力された場合には、ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、設定した地域的条件に基づいて１人での予約が可能な空き枠を検索する。さらに、空き枠検索部１５は、検索を行う日を基準として予め設定された規則に基づいて日程的条件（例えば、直近の土曜日等）を設定し、設定した日程的条件に基づいて１人での予約が可能な空き枠を検索する。また、空き枠検索部１５は、後述する予約検出部１８による検索結果としてユーザによる過去の予約の内容が抽出された場合には、抽出された過去の予約の内容に含まれる会場についての空き枠の中から、１人での予約が可能な空き枠を検索する。

記憶部１６には、予約支援サーバ１を制御するプログラムが記憶され、さらに、上述した応答のための文例等が記憶されている。

情報抽出部１７は、空き枠検索部１５による検索結果として抽出された空き枠の中に、空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、その空き枠について既に予約の登録を行っている他のユーザについての情報を抽出する。

予約検出部１８は、所定の場合に予約サーバ５の予約情報テーブル５ｃに記憶されている予約情報を検索し、特定の予約情報を検出する。例えば、一のユーザがゴルフを１人でプレーするための予約（すなわち１人予約）を行う場合、所定の範囲、例えば一のユーザの予約における場所と日付が同じ範囲、において、１人予約をしている他のユーザの予約情報を検索する。また、予約検出部１８は、過去に登録された予約の内容の中に、前記ユーザによる過去の予約の内容を検索する。

住所検索部１９は、ユーザの住所に関する情報を検索する。

図２に予約支援サーバ１の構成を示す。この図に示すように、予約支援サーバ１は、装置全体を制御するＣＰＵ（Central Processing Unit）３０、ＣＰＵ３０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）３２、各種のプログラムやデータを記憶するハードディスクドライブ（ＨＤＤ）３３、キーボードやマウスなどを含む入力部３４、画像を表示するディスプレイ３５、通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース３６、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置３７を備える。ＨＤＤ３３は、上述した記憶部１６の一例である。
本実施形態において、ＣＰＵ３０は問合わせ部１０、応答部１１、判断部１２、受付部１３、登録部１４、空き枠検索部１５、情報抽出部１７、予約検出部１８、及び住所検索部１９として動作し得る。
また、外部管理サーバ３、予約サーバ５も予約支援サーバ１と同様の構成である。

図３に端末装置２の構成を示す。この図に示すように、端末装置２は、装置全体を制御するＣＰＵ（Central Processing Unit）４０、ＣＰＵ４０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）４２、各種のプログラムやデータを記憶する記憶装置４３、キーボード、マウス、タッチパネルなどを含む入力部４４、画像を表示する液晶ディスプレイ等のディスプレイ４５、及び通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース４６を備える。

＜２：メッセージ送受信アプリケーション＞
次に、外部管理サーバ３によって提供されるメッセージ送受信サービス用のメッセージ送受信アプリケーションについて説明する。メッセージ送受信アプリケーションは、端末装置２にインストールされる。メッセージ送受信アプリケーションを端末装置２上で起動すると、図９に示すようなフレンド表示画面Ｐ１が表示される。本実施形態においては、メッセージ送受信アプリケーションの起動時のデフォルト選択メニューがフレンド表示画面Ｐ１に設定されている。

フレンド表示画面Ｐ１は、タイトル表示領域Ａ１、フレンド表示領域Ａ２、プロフィール画像表示領域Ａ３、ニックネーム表示領域Ａ４、メニューバーＡ５を備えている。
タイトル表示領域Ａ１には、そのページのタイトルが表示される。図９に示すフレンド表示画面Ｐ１は、メッセージ送受信アプリケーションにおいてフレンド登録しているフレンドを一覧表示する画面であり、タイトル表示領域Ａ１には、現在選択中のメニューのタイトルが表示されるようになっており、図９の例では「フレンド」と表示される。
フレンド表示領域Ａ２には、メッセージ送受信アプリケーションにおいてフレンド登録しているフレンドが、プロフィール画像とニックネームにより一覧表示される。図９に示す例では、一部のフレンドが表示されており、画面をスクロールすることにより、残りのフレンドも表示される。

また、外部管理サーバ３によって提供されるメッセージ送受信サービスの専用アカウントとして登録されているゴルフ予約Ａ１０もフレンドとして登録されている。このゴルフ予約Ａ１０を選択してメッセージを送信すると、予約支援サーバ１からの応答が行われることになる。

プロフィール画像表示領域Ａ３には、フレンドが登録したプロフィール画像が表示される。ニックネーム表示領域Ａ４には、フレンドが登録したニックネームが表示される。
メニューバーＡ５には、フレンドアイコンＡ６、チャットアイコンＡ７、お知らせアイコンＡ８、設定アイコンＡ９が表示される。それぞれのアイコンが押下されることにより、それぞれのアイコンに対応するページにジャンプするようになっている。フレンドアイコンＡ６が押下されると、図９に示すフレンド表示画面Ｐ１が表示され、チャットアイコンＡ７が押下されると、後述するチャット画面が表示される。お知らせアイコンＡ８が押下されると、メッセージ送受信アプリケーションの提供企業等からのお知らせを表示するページ（図示せず）にジャンプする。設定アイコンＡ９が押下されると、プロフィール画像やニックネーム等の各種設定が可能な設定ページ（図示せず）にジャンプする。

＜３：チャット処理＞
次に、本実施形態のメッセージ送受信アプリケーションにおけるチャット処理について説明する。図９に示すメニューバーＡ５のチャットアイコンＡ７が押下されると、図１０に示すチャット画面Ｐ２が表示される。
チャット画面Ｐ２は、タイトル表示領域Ｂ１、フレンド表示領域Ｂ２、プロフィール画像表示領域Ｂ３、ニックネーム表示領域Ｂ４、前回メッセージ表示領域Ｂ５、前回メッセージ投稿日時表示領域Ｂ６、フレンド表示画面Ｐ１と共通のメニューバーＡ５を備えている。

タイトル表示領域Ｂ１には、そのページのタイトルが表示される。図１０に示すチャット画面Ｐ２は、メッセージ送受信アプリケーションにおいてチャットを行う相手のフレンドを一覧表示する画面であり、タイトル表示領域Ｂ１には、「チャット」と表示される。
フレンド表示領域Ｂ２には、本実施形態では、ユーザのフレンドであって且つユーザとのチャットの記録が端末装置２から削除されていないフレンドが一覧表示される。一方、図９に示すフレンド表示画面Ｐ１はチャット履歴をユーザ別に一覧表示する画面である。
図１０に示す例では、一部のフレンドが表示されており、画面をスクロールすることにより、残りのフレンドも表示される。表示の順序は、最後にチャットを行った日時が新しい順になっている。

プロフィール画像表示領域Ｂ３には、フレンドが登録したプロフィール画像が表示される。ニックネーム表示領域Ｂ４には、フレンドが登録したニックネームが表示される。
前回メッセージ表示領域Ｂ５には、表示されているフレンドとのチャットにおいて、当該フレンドまたは自身が最後に投稿したメッセージが表示される。但し、表示可能な字数が限られているので、表示可能な字数を超える部分の表示は省略される。
前回メッセージ投稿日時表示領域Ｂ６には、表示されているフレンドとのチャットにおいて、当該フレンドまたは自身が最後にメッセージ投稿した日時が表示される。但し、チャット画面Ｐ２を表示している日とメッセージの投稿日が同日の場合には、投稿時間のみが表示される。また、チャット画面Ｐ２を表示している日から１週間以内であれば曜日が表示される。チャット画面Ｐ２を表示している日から１週間よりも前の投稿の場合には、月日が表示される。
メニューバーＡ５は、フレンド表示画面Ｐ１と共通なので説明を省略する。

チャット画面Ｐ２に表示されるフレンドに対してメッセージを送信する場合には、メッセージを送信したいフレンドのプロフィール画像及びニックネーム等の表示枠内の部分を押下する。このプロフィール画像及びニックネーム等の表示枠内の部分が押下されると、図１１に示すメッセージ表示画面Ｐ３が表示される。
メッセージ表示画面Ｐ３は、タイトル表示領域Ｃ１、メッセージ表示領域Ｃ２、相手側プロフィール画像Ｃ３、相手側メッセージ表示枠Ｃ４、本人側メッセージ表示枠Ｃ５、コマンドバーＣ６、及び機能ボタンＣ１１を備えている。

タイトル表示領域Ｃ１には、そのページのタイトルが表示される。図１１に示すメッセージ表示画面Ｐ３は、本人と相手側とで投稿されたメッセージを表示する画面であるが、図１１の例では、チャット画面Ｐ２と同様に、タイトル表示領域Ｃ１には「チャット」と表示される。

メッセージ表示領域Ｃ２には、相手側プロフィール画像Ｃ３と、相手側メッセージ表示枠Ｃ４と、本人側メッセージ表示枠Ｃ５とが表示される。相手側プロフィール画像Ｃ３はチャットを行っている相手のプロフィール画像であり、相手側メッセージ表示枠Ｃ４には相手が投稿したメッセージが表示される。本人側メッセージ表示枠Ｃ５には、本人が投稿したメッセージが表示される。また、各メッセージには送信された時刻が表示されるとともに、本人側メッセージについては、送信したメッセージが送信相手に読まれた場合（少なくとも本人側メッセージを送信相手が表示した場合）を示す「既読」の文言が表示される。

メッセージ表示領域Ｃ２は、上から下に向かって、時系列に沿って投稿されたメッセージが表示される。すなわち、新しいメッセージが投稿されると、メッセージ表示領域Ｃ２の一番下の部分に当該新しく投稿されたメッセージが表示される。したがって、それまで表示されていた相手側プロフィール画像Ｃ３、相手側メッセージ表示枠Ｃ４及び本人側メッセージ表示枠Ｃ５は、順次上側にシフトして表示される。メッセージ表示領域Ｃ２の一番上の部分に表示されていた相手側プロフィール画像Ｃ３及び相手側メッセージ表示枠Ｃ４、または、本人側メッセージ表示枠Ｃ５は、シフトによってメッセージ表示領域Ｃ２から見えなくなる。しかし、画面をスクロールすることにより、それまでの投稿メッセージを全て確認することができるようになっている。

コマンドバーＣ６には、設定アイコンＣ７、絵文字アイコンＣ８、メッセージ書き込み枠Ｃ９、送信ボタンＣ１０が表示される。
設定アイコンＣ７が押下されると、写真や動画の添付、あるいは、音声メッセージの添付等が可能になっている。絵文字アイコンＣ８が押下されると、絵文字を選択する画面（図示せず）が表示され、メッセージ内に挿入する絵文字を選択することができる。
メッセージ書き込み枠Ｃ９が押下されると、文字入力等を行うためのキーボード画面（図示せず）が表示され、キーボード画面を操作することによりメッセージ書き込み枠Ｃ９内にメッセージを書き込むことができる。
メッセージ書き込み枠Ｃ９内にメッセージを書き込んだ状態で送信ボタンＣ１０が押下されると、メッセージ書き込み枠Ｃ９内に書き込んだメッセージが、メッセージ表示領域Ｃ２の一番下の部分の本人側メッセージ表示枠Ｃ５に表示され、端末装置２から外部管理サーバ３に送信され、当該メッセージが外部管理サーバ３を経由して相手側の端末装置２に送信される。
機能ボタンＣ１１が押下されると、チャットに招待するに友達を選択することが可能となっている。詳しくは後述する。

＜４．予約支援サーバの動作＞
次に、図１２乃至図２４を参照して、以上のようなメッセージ送受信アプリケーションにおけるチャット処理を利用した本実施形態の予約支援サーバ１による予約支援動作について説明する。なお、図１２乃至図２０に示す例では、メッセージが投稿された日付や時間、「既読」の文言の記載を省略している。

＜４−１：予約支援サーバの開始１＞
まず、図２１のフローチャートを参照して、予約支援サーバの開始処理について説明する。メッセージ送受信アプリケーションにおいて、専用アカウントであるゴルフ予約Ａ１０をフレンド登録した直後においては、図１２に示すように、予約支援サーバ１側から、フレンド登録へのお礼メッセージＣ１９と人数入力要求メッセージＣ２０が送信される。図１２の例では、メッセージ表示領域Ｃ２に、「フレンド登録ありがとう！どんどん活用してくださいね。」というメッセージと、「ゴルフの予約をする人数を教えてくださいね。」というメッセージが表示される。このメッセージは、記憶部１６の文例テーブルに予め記憶されており、状況に応じて適切な文例を文例テーブルから読み取って、応答部１１が送信するようになっている。

ゴルフ場の予約を希望するユーザが、この人数入力要求メッセージＣ２０に対して、図１３に示すように「１人で行く」というメッセージＣ８０、あるいは、「１人予約」等のようなメッセージを送信し、このメッセージを予約支援サーバ１のＣＰＵ３０が受信した場合には、予約支援サーバ１のＣＰＵ３０は、ユーザから予約したい旨のメッセージを受信したと判断し（Ｓ１３００）、ユーザに対して人数の入力を要求するメッセージを送信する（Ｓ１３０１）。但し、図１３に示す例では、最初に人数の入力が行われているので、このような場合には、ステップＳ１３０１の人数の入力を要求するメッセージの送信処理は省略する。

しかし、最初に人数の入力が行われず、例えば、「予約したい！」というメッセージが送信された場合、あるいは、「予約」と送信された場合、もしくは、「ｔｔ」等の意味のないメッセージが送信され、予約支援サーバ１のＣＰＵ３０において受信した場合は、予約支援サーバ１のＣＰＵ３０は、予約したい旨のメッセージを受信したと判断し（Ｓ１３００）、「ゴルフの予約をする人数を教えてください。」のようなメッセージをユーザに対して送信する（Ｓ１３０１）。

「ゴルフの予約をする人数を教えてください。」のようなメッセージに対して、図１３のようにユーザから「１人で行く」等のメッセージを受信した場合には、予約支援サーバ１のＣＰＵ３０は、受信した人数が１人かどうかを判断する（Ｓ１３０２）。なお、「ゴルフの予約をする人数を教えてください。」のようなメッセージに対しては、図１３のように「１人で行く」等の文章の形で答えてもよいし、単に「１」のように数字で答えてもよい。このような場合でも、予約支援サーバ１のＣＰＵ３０は、人数についての入力があったものとして処理を行うようになっている。

予約支援サーバ１のＣＰＵ３０は、入力された人数が１人ではないと判断した場合には（Ｓ１３０２：ＮＯ）、図２２乃至図２４に示す処理に移行するが、これらの処理については後述する。
一方、予約支援サーバ１のＣＰＵ３０は、入力された人数が１人であると判断した場合には（Ｓ１３０２：ＹＥＳ）、１人予約フラグをオン状態にする（Ｓ１３０３）。１人予約フラグは、図２２に示す空き枠抽出処理において、１人予約枠に限定して空き枠を抽出するか、あるいは、１人予約枠を除外して空き枠を抽出するかの判断に用いられる。詳しくは後述する。

１人予約フラグをオン状態にした後は、予約支援サーバ１のＣＰＵ３０は、このユーザが過去に住所を入力したことがあるかどうか、つまり、住所履歴があるかどうかを判断する（Ｓ１３０４）。この住所履歴は、予約支援サーバ１の記憶部１６にユーザＩＤと関連付けて記憶されていてもよいし、予約サーバ５の予約情報テーブル５ｃに予約ＩＤと関連付けて記憶されていてもよい。また、外部管理サーバ３に記憶されていてもよい。

予約支援サーバ１のＣＰＵ３０は、住所履歴がないと判断した場合には（Ｓ１３０４：ＮＯ）、図１３に示すように、住所入力を要求するメッセージＣ８１を表示させる（Ｓ１３０５）。住所入力を要求するメッセージＣ８１は、図１３に示すように、住所を直接入力させる内容でもよいし、また、ＧＰＳの位置情報を入力させる内容でもよい。

予約支援サーバ１のＣＰＵ３０は、図１３に示すように、ユーザにより住所に関する入力が行われたと判断した場合には、入力された住所に基づいて、当該住所に近いゴルフ場の検索を行う（Ｓ１３０６）。また、予約支援サーバ１のＣＰＵ３０は、ステップＳ１３０４において、住所履歴があると判断した場合には（Ｓ１３０４：ＹＥＳ）、図１４に示すように、メッセージＣ９２のように、ユーザに対して住所の入力を要求することなく、以前に予約した際の住所に基づいて、当該住所に近いゴルフ場の検索を行う旨のメッセージＣ９２を表示させ、以前に予約した際の住所に近いゴルフ場の検索を行う（Ｓ１３０６）。

予約支援サーバ１のＣＰＵ３０は、予め記憶しておいた優先都市（地域）のうち、ユーザの住所に近い優先都市（地域）を基準にゴルフ場を検索する。具体的には、予約支援サーバ１のＣＰＵ３０は、ＡＰＩを用いてマップサーバ４にアクセスし、マップサーバ４の施設情報テーブル４ｂから、当該優先都市（地域）内で位置登録されているゴルフ場を検索し、そのうちからお勧めのゴルフ場を抽出する。この優先都市（地域）は、例えばユーザの住所から所定距離内にある都市（地域）であって、予め優先順位が設定された都市（地域）としたり、ユーザの住所から所定距離内になる都市（地域）であって、当該都市（地域）内に存在するゴルフ場の数が最も多い都市（地域）順に優先都市（地域）を決定したりしてもよい。所定の法則に従って優先都市（地域）が決定されれば、その方法は問わないものである。

マップサーバ４のＣＰＵは、条件に合致するゴルフ場が抽出された場合には、これらのゴルフ場リストにして予約支援サーバ１に送信する。このリストには、例えば、ゴルフ場名と、各ゴルフ場の前記住所からの距離等の情報が含まれている。
予約支援サーバ１のＣＰＵ３０は、マップサーバ４からゴルフ場のリストを受信すると、前記住所に最も近いゴルフ場から順に、１人予約者がいる空き枠、つまり、１人予約が可能な枠で、まだ定員に達していない枠の検索を行う（Ｓ１３０７）。予約支援サーバ１のＣＰＵ３０は、１人予約者がいる空き枠の検索を行う際、日程的条件を予め設定された規則に基づいて設定する（Ｓ１３０７）。予め設定された規則とは、例えば、検索を行う日を基準として、直近の土曜日とする。但し、本発明はこのような例に限定されるものではなく、直近の日曜日等、他の曜日であってもよい。

予約支援サーバ１のＣＰＵ３０は、まず、前記住所に最も近いゴルフ場、上述のように設定された日程的条件、及び、１人予約可能なことを検索条件として、予約サーバ５に対して検索要求を送信する。なお、前記住所に最も近いゴルフ場は、本実施形態では前記住所から最も所要時間が短いゴルフ場とするが、前記住所から最も距離が近いゴルフ場としてもよい。

予約サーバ５のＣＰＵは、検索要求及び検索条件を受信すると、検索条件として指定されたゴルフ場の空き枠情報テーブル５ｂを参照し、前記日程的条件に合致し、空き枠フラグが１で、１人予約枠フラグが１の枠を検索する。空き枠フラグが１の場合とは、当該枠がまだ定員に達しておらず、予約が可能な場合である。１人予約枠フラグが１の場合とは、１人予約が可能な枠である場合である。

予約サーバ５のＣＰＵは、前記検索の結果、条件に合致する空き枠があった場合には、スタートＩＤを含む当該空き枠の情報を読み取る。次に、予約サーバ５のＣＰＵは、予約情報テーブル５ｃを参照し、読み取ったスタートＩＤを含む予約情報の予約者名の項目に予約者の氏名が登録されているかどうかを判断する。判断の結果、予約者名の項目に予約者の氏名が登録されている場合には、予約サーバ５のＣＰＵは、１人予約者がいる空き枠があったと判断し、当該予約者の識別情報ＵＩＤを前記予約情報から読み取る。さらに、予約サーバ５のＣＰＵは、当該予約情報に同伴者名が登録されているかどうかを判断し、同伴者名が登録されている場合には、当該同伴者の識別情報ＵＩＤを前記予約情報から読み取る。なお、同伴者の識別情報ＵＩＤについても、予約情報テーブル５ｃに記憶されているものとする。また、１人予約者がいるか否かは識別情報ＵＩＤの登録の有無により判断してもよい。

そして、予約サーバ５のＣＰＵは、コメント情報テーブル５ｄを参照し、読み取った予約者または同伴者のコメントが登録されているかどうかを判断する。コメントが登録されていた場合には、コメントの内容を読み取る。

また、予約サーバ５のＣＰＵは、前記予約情報からプランＩＤを読み取り、プラン情報テーブル５ａを参照して、当該プランＩＤに対応するプラン情報を読み取る。
予約サーバ５のＣＰＵは、以上のように読み取った種々の情報を、予約支援サーバ１に送信する。

予約支援サーバ１のＣＰＵ３０は、予約サーバ５から前記情報を受信した場合には、前記条件に合致する１人予約者がいる空き枠があったと判断する（Ｓ１３０７：ＹＥＳ）。

そして、予約支援サーバ１のＣＰＵ３０は、受信した情報に基づいて、図１３に示す空き枠メッセージＣ８３のように、お勧めの空き枠の内容を表示させるための情報を端末装置２に送信する（Ｓ１３０８）。この空き枠に、既に他の１人予約者の予約が行われているので、予約支援サーバ１のＣＰＵ３０は、当該他の１人予約者の情報を、メッセージＣ８４のように提示する。他の１人予約者の情報には、性別、年齢を含んでもよいし、他の１人予約者がコメントを残している場合には、メッセージＣ８４のようにコメントを表示させる情報を端末装置２に送信してもよい。また、メッセージＣ８４のように、この空き枠に参加するかどうかを問い合わせるメッセージを含ませてもよい。また、性別及び年齢の情報、コメント、及び参加するかどうかを問い合わせるメッセージを、それぞれ別のメッセージとして表示させる情報を端末装置２に送信してもよい

予約支援サーバ１のＣＰＵ３０は、提示した空き枠に対して、図１３に示すようにユーザから参加の承認メッセージＣ８５（肯定的なメッセージ）を入力したと判断した場合には（Ｓ１３０９：ＹＥＳ）、このユーザを当該空き枠に登録する予約登録の処理を行い（Ｓ１３１０）、図１３に示すように、予約完了メッセージＣ８６を表示させる情報を端末装置２に送信する。しかし、予約支援サーバ１のＣＰＵ３０は、ユーザが、図１５に示すように、「いいえ。」等の前記空き枠に対する参加を承認しないメッセージＣ９３を入力したと判断した場合には（Ｓ１３０９：ＮＯ）、図２２に示す処理に移行して、日程の入力要求のメッセージＣ９４を表示させて、他の空き枠の検索を行う。詳しくは後述する。

次に、予約支援サーバ１のＣＰＵ３０は、図１３に示すように、ユーザ対して、他の１人予約者に対してコメントを残すかどうかを問い合わせる確認メッセージＣ８７を表示させる情報を端末装置２に送信する。その結果、予約支援サーバ１のＣＰＵ３０は、図１３に示すように、ユーザがコメントを残す旨のメッセージＣ８８を入力したと判断した場合には（Ｓ１３１１：ＹＥＳ）、コメントの入力を要求するメッセージＣ８９を表示させる情報を端末装置２に送信する。そして、図１３に示すように、ユーザがコメントＣ９０を入力した場合には、予約支援サーバ１のＣＰＵ３０は、入力されたコメントをコメント情報テーブル５ｄに記憶させる（Ｓ１３１２）。そして、予約支援サーバ１のＣＰＵ３０は、図１３に示すように、コメントの登録が完了した旨のメッセージと共に、ユーザが予約情報を確認することができるように、予約情報のリンク先を貼り付けたメッセージＣ９１を表示させて処理を終了する。

しかし、予約支援サーバ１のＣＰＵ３０は、ユーザが、図１６に示すように、コメントを残さない旨のメッセージＣ９５を入力したと判断した場合には（Ｓ１３１１：ＮＯ）、図１６に示すように、予約の登録が完了した旨のメッセージと共に、ユーザが予約情報を確認することができるように、予約情報のリンク先を貼り付けたメッセージＣ９６を表示させる情報を端末装置２に送信して処理を終了する。

予約支援サーバ１のＣＰＵ３０は、前記ステップＳ１３０７において、予約サーバ５から条件に合致する空き枠がない旨の回答を受信した場合には、前記住所に最も近いゴルフ場においては、条件に合致する１人予約者がいる空き枠がないと判断し（Ｓ１３０７：ＮＯ）、前記マップサーバ４から受信したリストにある全てのゴルフ場について、条件に合致する１人予約者がいる空き枠の検索を行ったかどうかを判断する（Ｓ１３１３）。
予約支援サーバ１のＣＰＵ３０は、まだ検索を行っていないゴルフ場があると判断した場合には（Ｓ１３１３：ＮＯ）、リストのうち、次に前記住所に近いゴルフ場を選択する（Ｓ１３１４）。そして、予約支援サーバ１のＣＰＵ３０は、当該ゴルフ場について、上述と同様の１人予約者がいる空き枠の検索要求を、予約サーバ５に対して送信する。その結果、上述と同様の検索処理が行われ、条件に合致する空き枠があった場合には、ステップＳ１３０８〜Ｓ１３１２の処理を行う。

しかし、予約支援サーバ１のＣＰＵ３０は、前記マップサーバ４から受信したリストにある全てのゴルフ場について、条件に合致する１人予約者がいる空き枠の検索を行ったと判断した場合には（Ｓ１３１３：ＹＥＳ）、次に、前記住所に最も近いゴルフ場から順に、１人予約枠の空き枠があるかどうかを判断する（Ｓ１３１５）。つまり、１人予約が可能な空き枠であるが、まだ予約者のいない空き枠があるかどうかを判断する。具体的には、予約支援サーバ１のＣＰＵ３０は、前記ゴルフ場、前記日程的条件、及び、１人予約が可能な空き枠でまだ予約者のいない空き枠を検索条件として、予約サーバ５に対して検索要求を送信する。

予約サーバ５は、上述と同様に、空き枠情報テーブル５ｂ、及び、予約情報テーブル５ｃを参照し、１人予約が可能な空き枠で、予約情報テーブル５ｃの予約者名の項目がnullとなっている予約情報を検索する。検索の結果、条件に合致した空き枠があった場合には、予約サーバ５は、プラン情報テーブル５ａ、空き枠情報テーブル５ｂ、及び、予約情報テーブル５ｃから読み取った情報を予約支援サーバ１に送信する。
予約支援サーバ１のＣＰＵ３０は、これらの情報を予約サーバ５から受信すると、１人予約枠があったと判断し（Ｓ１３１５：ＹＥＳ）、受信した情報に基づいて、当該１人予約枠の内容を端末表示２に表示させる情報を端末装置２に送信して、予約を行うかどうかの問合わせを行う（Ｓ１３１６）。

予約支援サーバ１のＣＰＵ３０は、提示した空き枠に対して、ユーザが予約の承認メッセージ（肯定的なメッセージ）を入力したと判断した場合には（Ｓ１３１６：ＹＥＳ）、このユーザを当該空き枠に登録する予約登録の処理を行い（Ｓ１３１０）、予約完了メッセージＣ８６を表示させる。また、予約支援サーバ１のＣＰＵ３０は、コメントを残すかどうかの問合わせを行い（Ｓ１３１１）、ユーザが肯定的なメッセージを入力したと判断した場合には（Ｓ１３１１：ＹＥＳ）、当該コメントを登録する（Ｓ１３１２）。また、予約支援サーバ１のＣＰＵ３０は、ユーザが否定的なメッセージを入力したと判断した場合には（Ｓ１３１１：ＮＯ）、コメントを登録せずに処理を終了する。
また、予約支援サーバ１のＣＰＵ３０は、ステップＳ１３１６において、ユーザが、「いいえ。」等の前記空き枠に対する予約を承認しないメッセージを入力したと判断した場合には（Ｓ１３１６：ＮＯ）、図２２に示す処理に移行して、日程の入力要求のメッセージＣ９４を表示させて、他の空き枠の検索を行う。詳しくは後述する。

予約支援サーバ１のＣＰＵ３０は、前記ステップＳ１３１５において、予約サーバ５から条件に合致する空き枠がない旨の回答を受信した場合には、前記住所に最も近いゴルフ場においては、条件に合致する１人予約枠がないと判断し（Ｓ１３１５：ＮＯ）、前記マップサーバ４から受信したリストにある全てのゴルフ場について、条件に合致する１人予約枠の検索を行ったかどうかを判断する（Ｓ１３１７）。
予約支援サーバ１のＣＰＵ３０は、まだ検索を行っていないゴルフ場があると判断した場合には（Ｓ１３１７：ＮＯ）、リストのうち、次に前記住所に近いゴルフ場を選択する（Ｓ１３１８）。そして、予約支援サーバ１のＣＰＵ３０は、当該ゴルフ場について、上述と同様の１人予約枠の検索要求を、予約サーバ５に対して送信する。その結果、上述と同様の検索処理が行われ、条件に合致する空き枠があった場合には、ステップＳ１３１６〜Ｓ１３１２の処理を行う。

しかし、予約支援サーバ１のＣＰＵ３０は、前記マップサーバ４から受信したリストにある全てのゴルフ場について、条件に合致する１人予約枠の検索を行ったと判断した場合には（Ｓ１３１７：ＹＥＳ）、図２２に示す処理に移行して、日程の入力要求のメッセージＣ９４を表示させて、他の空き枠の検索を行う。詳しくは後述する。

以上のように、本実施形態によれば、チャットアプリにおいてコンピュータとの対話形式で容易に１人予約を行うことができる。

＜４−２：予約支援サーバの開始２＞
次に、図２２を参照して、予約支援サーバにおける次の段階の処理について説明する。予約支援サーバ１のＣＰＵ３０は、図１７に示すように、予約の人数が１人ではない旨のメッセージＣ９７の入力が行われたと判断した場合（Ｓ１３０２：ＮＯ）、あるいは、図１５に示すように、提示された空き枠に参加しない旨のメッセージＣ９３の入力が行われたと判断した場合（Ｓ１３０９：ＮＯ）には、予約支援サーバ１のＣＰＵ３０は、図２２に示すように、日程の入力を要求するメッセージ（図１７に示すメッセージＣ２２、または、図１５に示すメッセージＣ９４）を表示させる（Ｓ１００）。

予約支援サーバ１のＣＰＵ３０は、入力内容を受信して、解析する処理を行う（Ｓ１０１）。図２２乃至図２４においては、ラベルＬＢ１〜ＬＢ１０が示されており、応答部１１により解析した結果がこれらのラベルＬＢ１〜ＬＢ１０のいずれかの内容に合致する場合には、合致した内容のラベルに続いて記載された処理が行われるようになっている。
例えば、応答部１１により入力の内容が日付または期間に関するものであると判断された場合には、ラベルＬＢ１、ＬＢ２、ＬＢ３のいずれかのラベルに続いて記載された処理が行われる。また、メッセージの内容が場所等に関するものである判断された場合には、ラベルＬＢ４、ＬＢ５、ＬＢ６のいずれかのラベルに続いて記載された処理が行われる。さらに、友達招待と判断された場合にはラベルＬＢ７に続いて記載された処理が行われ、提示情報の拒否等と判断された場合にはラベルＬＢ８に続いて記載された処理が行われる。そして、おまかせ要求と判断された場合にはラベルＬＢ９に続いて記載された処理が行われ、提示情報に対する承認と判断された場合にはラベルＬＢ１０に続いて記載された処理が行われる。しかし、上述したいずれでもない場合は、「認識できません」等の応答を行ってもよい。

＜４−３：日付判断処理＞
受信したメッセージの内容が、図１７に示すように数字４ケタのメッセージＣ２３であった場合には、予約支援サーバ１のＣＰＵ３０は、メッセージの内容を解析し（Ｓ１０１）、解析の結果、ゴルフ場を予約する日付が送信されたと判断する。そして、日付が送信されたと判断した場合には、ラベルＬＢ１に続いて記載された処理が行われる。まず、「８月２５日ですね。」等の確認のメッセージＣ２４を送信して、受信したメッセージの内容である日付を仮登録する（Ｓ２０１）。なお、本実施形態において仮登録とは、受信したメッセージの内容を一時的に予約支援サーバ１の記憶部１６に記憶させておくことをいう。

次に、予約支援サーバ１のＣＰＵ３０は、ゴルフ場の仮登録が行われたかどうかを判断し（Ｓ２０２）、まだゴルフ場の仮登録が行われていない場合には（Ｓ２０２：ＮＯ）、ユーザの住所が入力済みであるかどうかを判断する（Ｓ２０７）。住所が入力済みではない場合には（Ｓ２０７：ＮＯ）、住所の入力を要求するメッセージを送信する（Ｓ２０８）。図１７に示す例では、「８月２５日ですね。」という確認のメッセージＣ２４を送信した後に、「おすすめのゴルフ場を探してみます。位置情報をおしえてくださいね。」というメッセージＣ２５を送信する。

一方、予約支援サーバ１のＣＰＵ３０は、ゴルフ場の仮登録が行われていると判断した場合には（Ｓ２０２：ＹＥＳ）、つまり、先にゴルフ場の仮登録が行われた後に、日付の仮登録（Ｓ２０１）が行われた場合には、１人予約フラグがオン状態かどうかを判断する（Ｓ２０３）。予約支援サーバ１のＣＰＵ３０は、１人予約フラグがオン状態であると判断した場合には（Ｓ２０３：ＹＥＳ）、空き枠情報テーブル５ｂを参照して、仮登録されたゴルフ場の空き枠のうち、１人予約が可能な枠限定で、空き枠を検索する。そして、予約支援サーバ１のＣＰＵ３０は、このような空き枠があると判断した場合には（Ｓ２０５：ＹＥＳ）、仮登録したゴルフ場及び日付に該当し、かつ、１人予約可能な空き枠情報を抽出し、承認を要求するメッセージを送信する（Ｓ２０６）。しかし、予約支援サーバ１のＣＰＵ３０は、提示可能な空き枠がないと判断した場合には（Ｓ２０５：ＮＯ）、住所入力済みかどうかを判断する（Ｓ２０７）。そして、予約支援サーバ１のＣＰＵ３０は、住所入力が行われていないと判断した場合には（Ｓ２０７：ＮＯ）、住所入力を要求し（Ｓ２０８）、住所入力済みであると判断した場合には（Ｓ２０７：ＹＥＳ）、図２３に示すゴルフ場検索処理に移行する（Ｓ８０２）。

また、予約支援サーバ１のＣＰＵ３０は、１人予約フラグがオン状態ではないと判断した場合には（Ｓ２０３：ＮＯ）、空き枠情報テーブル５ｂを参照して、仮登録されたゴルフ場の空き枠のうち、１人予約枠を除外して、空き枠を検索する。そして、予約支援サーバ１のＣＰＵ３０は、このような空き枠があると判断した場合には（Ｓ２０４：ＹＥＳ）、仮登録したゴルフ場及び日付に該当し、かつ、１人予約可能な空き枠情報を抽出し、承認を要求するメッセージを送信する（Ｓ２０６）。しかし、予約支援サーバ１のＣＰＵ３０は、提示可能な空き枠がないと判断した場合には（Ｓ２０４：ＮＯ）、住所入力済みかどうかを判断する（Ｓ２０７）。そして、予約支援サーバ１のＣＰＵ３０は、住所入力が行われていないと判断した場合には（Ｓ２０７：ＮＯ）、住所入力を要求し（Ｓ２０８）、住所入力済みであると判断した場合には（Ｓ２０７：ＹＥＳ）、図２３に示すゴルフ場検索処理に移行する（Ｓ８０２）。

空き枠情報を抽出する際には、例えば次のような優先順位のつけ方を採用した抽出を行う。
１．特定の時間帯（例えば８時）を最初に、次に９時台というように時間帯の優先順位を付けて空き枠を抽出するパターン
２．住所がわかっている場合は、ゴルフ場までの理論的所要時間を算出し、所定の時間（例えば朝６時）に出発したとして到着予想時刻を算出して、そこから所定時間（例えば３０分）経過後の時間帯の空き枠を抽出するパターン
３．空き枠の中からランダムで一つ抽出するパターン
但し、以上のようなパターン以外のパターンを採用してもよい。本実施形態では、上記「１．」のパターンを採用する。
図１７に示す例では、「では赤坂ゴルフ倶楽部はどうでしょう？車で１時間４０分くらいです。」というメッセージＣ２７が送信された後に、「８月２５日も空いています。４人で7:43スタート、食事つきで12,000円です。予約しますか？」というメッセージＣ２８が送信される。

以上のように、日付の仮登録（Ｓ２０１）を行った後は、空き枠情報の表示と承認の要求メッセージ、あるいは、住所入力の要求メッセージが送信される。

図１８に示すように、日付の確認メッセージＣ５２の送信の直後に別の日付のメッセージＣ５３が送信された場合には、予約支援サーバ１のＣＰＵ３０は、再び日付の送信があったと判断し、ラベルＬＢ１に続いて記載された処理を行う。つまり、新たな日付を仮登録し（Ｓ２０１）、確認のメッセージを送信する。図１８に示す例では、「９月１日もＯＫですね。わかりました。」という確認メッセージＣ５４が表示される。

また、図１８に示すように、確認メッセージＣ５４の送信の直後に、仮登録した日付を取り消すメッセージＣ５５が送信された場合には、予約支援サーバ１のＣＰＵ３０は、日付を否定する内容を受信したと判断し、図２３に示すラベルＬＢ８に続いて記載されたステップＳ１００１以下の処理を行う。ステップＳ１００１では、他の候補があるかどうかが判断されるが、この場合には他に候補はないので（Ｓ１００１：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、仮登録済情報を削除して（Ｓ１００３）、確認のメッセージを送信する。図１８の例では、「０８２５ムリ」という日付を否定するメッセージＣ５５を受信した後に、８月２５日の日付の仮登録済情報を削除して、「８月２５日はＮＧになったんですね。わかりました。」という確認のメッセージＣ５６を表示させる。なお、確認メッセージＣ５４の送信の直後とは、例えば、確認メッセージＣ５４を送信してから３０分等の所定時間以内、または後述の予約情報の本登録がなされたとき、のいずれかの条件が満たされるまで、とすることができる。但し、いずれか一方のみの条件としても良いし、他の条件としてもよい。
仮登録済情報の削除の結果、日付の仮登録済情報が無くなってしまった場合には、新たな日程の入力を要求するメッセージを表示させる（Ｓ１００４）。しかし、この例では、８月２５日以外の日付が仮登録されているので、新たな日程の入力を要求するメッセージは表示させない。

さらに、図１８に示すように、日付をカンマ等で区切り、複数の日付を示すメッセージＣ５７が送信された場合には、予約支援サーバ１のＣＰＵ３０は、複数の日付について入力が行われたと判断する。複数の日付について入力が行われたと判断した場合には、ラベルＬＢ２に続いて記載されたステップＳ３０１以降の処理が行われる。まず、複数の日付を仮登録する（Ｓ３０１）。また、２つの日付をハイフンで結ぶメッセージＣ５７が送信された場合には、予約支援サーバ１のＣＰＵ３０は、期間について入力が行われたと判断する。期間について入力が行われたと判断した場合には、ラベルＬＢ３に続いて記載された処理が行われる。つまり、つまり、予約支援サーバ１のＣＰＵ３０は、期間の仮登録を行う（Ｓ４０１）。図１８の例では、「０９０８，０９１５−０９２２」というメッセージＣ５７が送信されたので、予約支援サーバ１のＣＰＵ３０は、日付として９月８日と、９月１５日から９月２２日の期間とを仮登録する。そして、「９月８日、９月１５日から９月２２日もＯＫですね。わかりました。」という確認メッセージＣ５８を送信して表示させる。

複数日付の仮登録（Ｓ３０１）、または、期間の仮登録（Ｓ４０１）が行われた後は、優先順位に基づいて選択した１日で空き枠検索の準備が行われる（Ｓ３０２）。本実施形態では、以下のような優先順位に従って特定の１日を決定する。

順位１：仮登録した日付に該当する日であって、予約を行っている現時点から最も近い土曜日（あるいは翌日が休日である日）
順位２：仮登録した日付に該当する日であって、予約を行っている現時点から最も近い日曜日
順位３：仮登録した日付に該当する日であって、予約を行っている現時点から次に近い土曜日（あるいは翌日が休日である日）
順位４：仮登録した日付に該当する日であって、予約を行っている現時点から次に近い日曜日
順位５：仮登録した日付に該当する日であって、予約を行っている現時点から最も近い平日

本実施形態では、前記順位１から順に該当する日を探すこととしているが、これは一例であって、特定の１日が決定できればどのような方法を採用してもよい。例えば、仮登録した日付に該当する日が２以上ある場合、その中からランダムで特定の１日を決定することとしてもよい。

なお、本実施形態では、ユーザから日程に関するメッセージを受信した場合、図１８に示すように「８月２５日ですね。」等と応答しているが、例えば「８月２５日ですね。わかりました。ではゴルフ場を検索しますので住所を入力してください。ＧＰＳの位置情報でも構いません。」等と応答するところを、「ではゴルフ場を検索しますので住所を入力してください。ＧＰＳの位置情報でも構いません。」等の、住所入力の要求等の他の部分の記載を省略したものである。

また、日程の入力を要求するメッセージを送信したにも拘わらず、例えば、「東京都」等のように日程とは無関係の送信が行われることも考えられる。この場合には、エラーとして判断するようにしてもよいが、本実施形態では、受信したメッセージの内容を解析し、例えば都道府県についての内容であると判断した場合には、ゴルフ場の検索処理を行うようになっている。本実施形態では、このように、どのような問い掛けを行ったかどうかに拘わらず、ユーザが送信したメッセージの内容を解析して適切な処理を行う。すなわち本実施形態においては、受信したメッセージの内容が、応答部１１からの問いかけに対する予め想定された回答とは異なるが、解析部１０による解析の結果、他の問いかけに対する予め想定された回答に相当する場合は、当該他の問いかけに対する回答であると解析することとしている。従って、日程からでも、また、場所からでも、予約に必要な情報を決定していくことができる。

＜４−４：ゴルフ場検索処理＞
受信したメッセージの内容が、都道府県名、あるいは、都市名と判断した場合には、都道府県別、あるいは都市別のお勧めのゴルフ場の検索を行う。なお、ユーザの住所の入力と、ゴルフ場検索のための都道府県名、あるいは、都市名の入力との区別は次のように行う。送信された内容が、都道府県名のみ、あるいは、都市名のみ、もしくは都道府県名と都市名との組み合わせである場合には、ゴルフ場検索のための都道府県名、あるいは、都市名の入力があったと判断する。しかし、都市名以降の詳しい地区名、番地等が含まれている場合には、ユーザの住所の入力があったと判断する。

受信したメッセージの内容が、都道府県名、あるいは、都市名と判断した場合には、ラベルＬＢ５に続いて記載された処理が行われる。まず、予約支援サーバ１のＣＰＵ３０は、予め記憶しておいて優先都市（地域）を基準にゴルフ場を検索する旨の応答を行う（Ｓ５０１）。例えば、ユーザのメッセージが「栃木県」であった場合には、「那須地区でゴルフ場を探してみます。」というような応答を行う。そして、予約支援サーバ１のＣＰＵ３０は、マップサーバ４にアクセスし、マップサーバ４の施設情報テーブル４ｂから、当該優先都市（地域）内で位置登録されているゴルフ場を検索し（Ｓ５０２）、そのうちの一つのゴルフ場をお勧めのゴルフ場として表示して、ユーザの承認を要求するメッセージを表示する（Ｓ５０３）。

ここで、検索したゴルフ場の中から一つのゴルフ場を選択する際には、ランダムに一つのゴルフ場を選択してもよいし、予め設けておいた優先順位に基づいて一つのゴルフ場を選択するようにしてもよい。優先順位は、予約支援サーバ１において予め設定しておいてもよいし、例えば予約後に実際にラウンドしたゴルフ場の評価をユーザに行ってもらい、これらの評価を集積して評価値の平均値が高い順としてもよい。また、平均値が同じである場合には、５０音順としてもよい。本実施形態では、予約支援サーバ１において予め優先順位を設定している。

予約支援サーバ１のＣＰＵ３０は、図１９に示すメッセージＣ６５のように、受信したメッセージの内容が、ゴルフ場名自体であると判断した場合には、ラベルＬＢ５に続いて記載された処理が行われる。まず、ゴルフ場名の仮登録を行う（Ｓ６０１）。ゴルフ場名の仮登録を行うには、そのゴルフ場名のテキストデータを解析して、記憶部１６に記憶されているゴルフ場情報を参照する。ゴルフ場情報には、ゴルフ場名とゴルフ場ＩＤとが関連付けて記憶されており、ゴルフ場情報を参照することにより、そのゴルフ場に対応するゴルフ場ＩＤを特定することができる。ゴルフ場ＩＤが特定できた場合には、そのゴルフ場名とゴルフ場ＩＤとを仮登録する（Ｓ６０１）。そして、図１９に示すメッセージＣ６６のような確認メッセージを送信する。図１９の例では、メッセージＣ６５が「西麻布ゴルフクラブ」とゴルフ場名を表しているので、メッセージＣ６６のように「西麻布ゴルフですね。２ヶ月前にもプレーされています。車で１．５時間くらいですね。」という確認メッセージを送信する。このメッセージＣ６６では、過去のラウンド履歴、及び当該ゴルフ場までの所要時間を表示しているが、このようなメッセージを送信するためには、予約支援サーバ１の記憶部１６に、各ユーザの過去のラウンド履歴、及びゴルフ場に関する情報等を記憶させておけばよい。

ゴルフ場名の仮登録が行われた後は、予約支援サーバ１のＣＰＵ３０は、日程についての仮登録が既に行われたかどうかを判断する（Ｓ６０２）。日程の仮登録が未だ行われていない場合には（Ｓ６０２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、日程の入力を要求するメッセージを送信する（Ｓ６０３）。例えば、「日程を数字４ケタで入力してください。」のようなメッセージを送信する。また、日程の仮登録が既に行われている場合には（Ｓ６０２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、１人予約フラグがオン状態かどうかを判断した後（Ｓ２０３）、予約サーバ５を参照して、空き枠情報を抽出し、ユーザに対して承認要求のメッセージを送信する（Ｓ２０４、Ｓ２０５、Ｓ２０６）。例えば、「西麻布ゴルフクラブで９月２５日ですね。○時○分アウトスタートの△プランはいかがでしょうか。料金は×××円です。」というようなメッセージを送信する。

図１９に示すメッセージＣ６２のようにお勧めとして提示したゴルフ場に対して、メッセージＣ６３のように「遠いなー」と入力された場合、あるいは、「他のところ」等の同意しない旨の入力が行われた場合には、予約支援サーバ１のＣＰＵ３０は、提示した情報が拒否されたと判断し、図２３のラベルＬＢ８に続いて記載された処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、仮登録情報がある場合には仮登録情報を削除する（Ｓ１００１）。図１５に示すメッセージＣ６２を送信した段階では仮登録情報は存在しないので、ステップＳ１００１の処理は行わず、次の処理に移行する。つまり、予約支援サーバ１のＣＰＵ３０は、他に候補があるかどうかを判断し（Ｓ１００２）、他に候補がある場合には（Ｓ１００２：ＹＥＳ）、お勧めゴルフ場の再検索を行い、他の候補を表示して承認を要求するメッセージを表示する（Ｓ１００３）。最初の検索時に複数のゴルフ場が抽出されている場合には、予約支援サーバ１において予め設定した優先順位の次の順位のゴルフ情報を次の候補としてもよい。
しかし、他に候補がない場合には（Ｓ１００２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、新たなお勧めゴルフ場の提示を行うために、位置情報の入力を要求する（Ｓ１００４）。

図１９に示すメッセージＣ６１のように、ユーザが入力した情報が場所に関する情報で、都市名以降の詳しい地区名、番地等が含まれている場合には、予約支援サーバ１のＣＰＵ３０は、ユーザの住所の入力があったと判断する。この場合には、図２３のラベルＬＢ６に続いて記載された処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、日程の仮登録が既に行われているかどうかを判断し（Ｓ８０１）、日程の仮登録がまだ行われていない場合には（Ｓ８０１：ＮＯ）、日程の入力を要求するメッセージを送信する（Ｓ８０４）。しかし、予約支援サーバ１のＣＰＵ３０は、日程の仮登録が既に行われている場合には（Ｓ８０１：ＹＥＳ）、お勧めのゴルフ場の検索を行う（Ｓ８０２）。お勧めのゴルフ場の検索は次のように行われる。まず、予約支援サーバ１のＣＰＵ３０は、受信した住所をマップサーバ４に送信し、当該住所に対応する位置情報（緯度経度情報）を取得する。次に、予約支援サーバ１のＣＰＵ３０は、取得した位置情報をマップサーバ４に送信し、当該位置情報に相当する位置から所定範囲内、例えば、車で所要時間２時間以内にあるゴルフ場のリストと、各ゴルフ場までの所要時間の情報を取得する。そして、予約支援サーバ１のＣＰＵ３０は、所要時間の最も短いゴルフ場をお勧めゴルフ場として提示し、ユーザに承認を要求するメッセージを送信する（Ｓ８０３）。図１９の例では、「六本木カントリーはどうでしょう？車で２時間くらいです。」というメッセージＣ６２を送信している。

なお、位置情報（緯度経度情報）がユーザから送信されてきた場合も、予約支援サーバ１のＣＰＵ３０は、住所が入力されたと判断する。従って、図２３のラベルＬＢ６に続いて記載された処理を行う。つまり、予約支援サーバ１のＣＰＵ３０は、日程の仮登録が既に行われているかどうかを判断し（Ｓ８０１）、日程の仮登録がまだ行われていない場合には（Ｓ８０１：ＮＯ）、日程の入力を要求するメッセージを送信する（Ｓ８０４）。しかし、予約支援サーバ１のＣＰＵ３０は、日程の仮登録が既に行われている場合には（Ｓ８０１：ＹＥＳ）、お勧めのゴルフ場の検索を行う（Ｓ８０２）。この場合のお勧めのゴルフ場の検索は次のように行われる。まず、予約支援サーバ１のＣＰＵ３０は、受信した位置情報（緯度経度情報）をマップサーバ４に送信し、当該位置情報に相当する位置から所定範囲内、例えば、車で所要時間２時間以内にあるゴルフ場のリストと、各ゴルフ場までの所要時間の情報を取得する。そして、予約支援サーバ１のＣＰＵ３０は、所要時間の最も短いゴルフ場をお勧めゴルフ場として提示し、ユーザに承認を要求するメッセージを送信する（Ｓ８０３）。

＜４−５：友達招待処理＞
次に、友達を招待した場合の予約支援処理について説明する。外部管理サーバ３によって提供されるメッセージ送受信サービスにおけるチャット処理では、友達を招待して複数人でチャットを行うことができる。予め招待する友達を選択してチャットを開始することもできるし、誰かとチャットを行っている状態で、新たな友達を招待することもできる。本実施形態では、専用アカウントであるゴルフ予約Ａ１０と上述したようなチャット形式で予約に必要な情報を入力している状態で、新たな友達を招待する例について説明する。

図２０に示す機能ボタンＣ１１を押下すると、「友達を招待する」というボタンが表示され、このボタンを押すと招待する友達を選択する画面が表示される。この画面において友達を選択すると、図２０に示すように、「ゴルフ予約さん、美希さんが参加しました。」というメッセージＣ７０が表示され、招待された友達もメッセージを送信できるようになる。

但し、この状態では、招待された友達と専用アカウントであるゴルフ予約Ａ１０は、招待されたことを検知することはできない。
図２０のメッセージＣ７１のように、招待したユーザが何等かのメッセージを送信した場合には、招待したユーザの端末装置２に予め記憶されている、招待したユーザ自身及び友達のＩＤ情報に基づいて、招待したユーザのＩＤと招待された友達のＩＤが予約支援サーバ１に送信される。予約支援サーバ１のＣＰＵ３０は、これらのＩＤを検知することにより、招待したユーザが専用アカウントであるゴルフ予約Ａ１０と招待された友達宛にメッセージを発信したと判断することができる。そして、検知したＩＤの中に、仮登録を行っていたユーザ以外のユーザのＩＤが含まれている場合には、仮登録を行っていたユーザが友達を招待したと判断する。友達を招待したと判断した場合には、図２３のラベルＬＢ７に続いて記載された処理が行われる。

まず、予約支援サーバ１のＣＰＵ３０は、それまでに仮登録されている仮登録情報を抽出する（Ｓ９０１）。そして、予約支援サーバ１のＣＰＵ３０は、日程が既に仮登録されているかどうかを判断し（Ｓ９０２）、日程については未だ仮登録されていない場合には（Ｓ９０２：ＮＯ）、それまでに仮登録してある情報を提示すると共に、日程の入力を要求するメッセージを送信する（Ｓ９０３）。本実施形態では、仮登録される情報は、日程の情報とゴルフ場の情報なので、この場合に仮登録されている情報はゴルフ場の情報ということになる。したがって、例えば、図２０の例のように、「ゴルフ場の候補は、○○カントリーです。このゴルフ場でプレーする日を数字４ケタで入力してください。」というメッセージＣ７３を送信する。このような日程の入力を要求するメッセージに対して、友達を招待したユーザ、あるいは、招待された友達から数字４ケタを含む入力が行われた場合には、予約支援サーバ１のＣＰＵ３０は、ラベルＬＢ１、ＬＢ２、ＬＢ３に続いて記載された日付判断処理を行う。

図２０の例では、友達を招待したユーザは「０９０１」というメッセージＣ７４を送信し、招待された友達は「０９０８」というメッセージＣ７５を送信している。この場合には、１人のユーザが複数の日付を入力した場合と同様に取り扱われる。したがって、メッセージＣ７６のように９月１日と９月８日の両方が候補日となったことの確認が行われる。本実施形態では、例えば、「０９０１ムリ」のように、送信された内容を否定する入力が行われない限りは、送信された内容は有効な内容として取り扱われるようになっている。

また、日程については既に仮登録が行われている場合には（Ｓ９０２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、ゴルフ場についての仮登録が既に行われているかどうかを判断する（Ｓ９０４）。ゴルフ場については未だ仮登録されていない場合には（Ｓ９０４：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、それまでに仮登録してある情報を提示すると共に、ゴルフ場の入力を要求するメッセージを送信する（Ｓ９０５）。この場合に仮登録されている情報は日程の情報なので、予約支援サーバ１のＣＰＵ３０は、例えば、「これまでに、日程の候補として９月１日が挙がっています。お勧めのゴルフ場を検索しますので、位置情報をおしえてください。」のようなメッセージを送信する。このような日程の入力を要求するメッセージに対して、友達を招待したユーザ、あるいは、招待された友達から、都道府県の入力、ゴルフ場名の入力、あるいは住所の入力が行われた場合には、予約支援サーバ１のＣＰＵ３０は、ラベルＬＢ４、ＬＢ５に続いて記載された処理、または、ラベルＬＢ６に続いて記載された処理が行われることになる。

そして、日程についても既に仮登録が行われ（Ｓ９０２：ＹＥＳ）、さらに場所についても既に仮登録が行われている場合には（Ｓ９０４：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、抽出された空き枠情報が提示されて承認の入力を要求するメッセージを送信する（Ｓ９０６）。このメッセージは、例えば、予約支援サーバ１の記憶部１６に文例データベースを構築しておき、仮登録されている情報を文例データベースの文例に当て嵌めて報告文を作成する形式で作成される。図２０の例では、招待された友達に対して、日程の入力を要求するメッセージＣ７３が最初に送信されているが、このメッセージＣ７３は、「ゴルフ場の候補は、[#ゴルフ場名]です。このゴルフ場でプレーする日を数字４ケタで入力してください。」という文例に、[#ゴルフ場名]として仮登録されている「西麻布カントリー」を当て嵌めて報告文として作成される。日程と場所の両方の仮登録が行われている場合には、メッセージＣ７３の代わりに、メッセージＣ７７のような空き枠を確認するメッセージが、最初に送信されることになる。このメッセージＣ７７は、「[#日程]に[#ゴルフ場名]、[#プラン]に空きがありました。[#料金]です。これでいいですか？」という文例に、[#日程]、[#ゴルフ場名]、[#プラン]、[#料金]として仮登録されている「９月１日」、「西麻布カントリー」、「４人で7:00スタート」、「キャディ付きで10,000円」を当て嵌めて報告文として作成すればよい。本実施形態では、承認は、招待者（招待されたユーザ）と招待したユーザの両方が承認する旨のメッセージを送信した場合に、承認されたものと判断し、予約サーバ５の予約情報テーブル５ｃに本登録する。この場合、ユーザからはメッセージと関連付けて送信者のＩＤが送信されるため、このＩＤを管理することによって招待者と招待したユーザの両方が承認したかどうかを判断する。

図２０の例のように、「えー、早いなー」のような否定的なメッセージＣ７８が送信された場合には、予約支援サーバ１のＣＰＵ３０は、図２３のＬＢ８に続く処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、仮登録情報を削除し（Ｓ１００１）、他に候補があるかどうかを判断する（Ｓ１００２）。予約支援サーバ１のＣＰＵ３０は、他に候補があると判断した場合には（Ｓ１００２：ＹＥＳ）、他の候補を表示して、承認を要求するメッセージを送信する（Ｓ１００３）。図２０の例では、「８：００スタートも空いていました。これでいいですか？」というメッセージＣ７９が表示される。

また、予約支援サーバ１のＣＰＵ３０は、他に候補がないと判断した場合には（Ｓ１００２：ＮＯ）、新たに日程の入力を要求するメッセージを送信する（Ｓ１００４）。

同様に、ゴルフ場の候補の提示に対して、否定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、他に候補があるかどうかを判断し（Ｓ１００２）、他に候補がある場合には（Ｓ１００１：ＹＥＳ）、他の候補を表示して、承認を要求するメッセージを送信する（Ｓ１００３）。しかし、予約支援サーバ１のＣＰＵ３０は、他に候補がないと判断した場合には（Ｓ１００２：ＮＯ）、住所の入力を要求するメッセージを送信する（Ｓ１００４）。
なお、友達を招待した場合には、招待したユーザと招待された友達との間での会話と、予約のための入力とを区別するために、４ケタの数字のみの入力、あるいは、「９月１５日」のように日付のみの入力があった場合に日程の入力があったものとして処理を行う。しかし、「９月１５日？」のように日付や４ケタの数字以外の言葉等、この場合のように「？」のマークが含まれている場合には、招待したユーザと招待された友達との間での会話と考えられるので、日程についての入力として処理しないようにしてもよい。また、日程を否定する場合にも、４ケタの数字や日付に「ムリ」等の否定する言葉が付け加えられた場合に、その日程を否定する入力が行われたとして処理を行うようにしてもよい。同様に、都道府県名または地域、あるいはゴルフ場名のような場所のみの入力があった場合には、場所についての入力があったものとして処理を行い、都道府県名または地域、あるいはゴルフ場名のような場所に、「ムリ」等の否定する言葉が付け加えられた場合に、その場所を否定する入力が行われたとして処理を行うようにしてもよい。

本実施形態では、友達を招待した場合には、招待したユーザ、あるいは、招待された友達から否定的なメッセージが送信されない限りは、提示した情報が承認されたものとして処理を進めるが、例えば、「はい。」あるいは「いいよ。」等のように積極的に肯定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、提示した情報が承認されたものと判断して、図２４のＬＢ９に続く処理を行う。そして、予約支援サーバ１のＣＰＵ３０は、承認された情報を仮登録し（Ｓ１２０１）、日程について仮登録済みかどうかを判断する（Ｓ１２０２）。日程について仮登録済みではない場合には（Ｓ１２０２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、日付の入力を要求するメッセージを送信する（Ｓ１２０３）。

日程について仮登録済みの場合には（Ｓ１２０２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、ゴルフ場について仮登録済みかどうかを判断する（Ｓ１２０４）。ゴルフ場について仮登録済みではない場合には（Ｓ１２０４：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、住所の入力を要求するメッセージを送信する（Ｓ１２０５）。

ゴルフ場について仮登録済みの場合には（Ｓ１２０４：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、空き枠について仮登録済みかどうかを判断する（Ｓ１２０６）。空き枠について仮登録済みではない場合には（Ｓ１２０６：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、空き枠を抽出して承認を要求するメッセージを送信する（Ｓ１２０７）。

そして、予約支援サーバ１のＣＰＵ３０は、日程、ゴルフ場、空き枠の全ての情報について仮登録が行われていると判断した場合には、（Ｓ１２０６：ＹＥＳ）、予約サーバ５に対する予約情報の本登録処理を行い（Ｓ１２０８）、予約が完了した旨の表示を行う（Ｓ１２０９）。但し、友達が招待されている状態においては、特に空き枠情報については、招待したユーザと、招待された友達の全員の承認が必要であると考えられる。招待された友達が複数である場合には、招待したユーザと、招待された複数の友達の全員の承認が必要であると考えられる。そこで、本実施形態では、予約サーバ５に対する予約情報の本登録処理を行う前に、空き枠情報について、否定的なメッセージが送信されていないかどうか、あるいは、招待したユーザと、招待された友達の全員の肯定的なメッセージが送信されているかどうかが判断される。空き枠情報について、否定的なメッセージが送信されておらず、あるいは、招待したユーザと、招待された友達の全員の肯定的なメッセージが送信されている場合には、予約支援サーバ１のＣＰＵ３０は、予約サーバ５に対する予約情報の本登録処理を行い（Ｓ１２０８）、予約が完了した旨の表示を行う（Ｓ１２０９）。

以上のように、本実施形態によれば、友達が途中から招待された場合でも、それまでに仮登録されている内容を提示して、招待された友達に対して承認を求めるので、適切かつ簡易に複数人によるゴルフ場の予約が行われることになる。

＜４−６：拒否または否定に対する処理＞
次に、提示情報が拒否され、または、日付が否定された場合の処理について説明する。上述のように、友達を招待した場合の処理の一部として、提示情報が拒否され、または、日付が否定された場合の処理を説明したが、この拒否または否定に対する処理は、本実施形態における予約支援処理の全体について共通の処理なので、改めて説明する。

図２２に示すステップＳ２０１、Ｓ３０１、Ｓ４０１の日付の仮登録処理が行われた後、例えば「０９０１ムリ」のような否定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、仮登録された日付が否定されたと判断する。この場合には、図２３のラベルＬＢ９に続いて記載された処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、仮登録情報を削除する処理を行う（Ｓ１００１）。複数の日程のうちの一つが否定された場合には、予約支援サーバ１のＣＰＵ３０は、その否定された日程の仮登録情報を削除する。次に、予約支援サーバ１のＣＰＵ３０は、他に候補があるかどうかを判断する（Ｓ１００２）。本実施形態においては、日程の仮登録の際には日程の候補を予約支援サーバ１のＣＰＵ３０から提示することはないので（Ｓ１００２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、新たに日程の入力を要求するメッセージを送信する（Ｓ１００４）。

同様に、図２２に示すステップＳ５０３、図２３に示すＳ８０３のお勧めゴルフ場の表示と承認を要求するメッセージの送信に対して、「遠い」等の否定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、提示した情報が否定されたと判断し、図２３のラベルＬＢ８に続いて記載された処理が行われる。まず、予約支援サーバ１のＣＰＵ３０は、仮登録情報を削除する（Ｓ１００１）。そして、予約支援サーバ１のＣＰＵ３０は、他に候補があるかどうかを判断する（Ｓ１００２）。他に候補がある場合には（Ｓ１００２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、他の候補を表示して、承認を要求するメッセージを送信する（Ｓ１００３）。しかし、他に候補がない場合には（Ｓ１００２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、新たなお勧めのゴルフ場を検索するために、住所の入力を要求するメッセージを送信する（Ｓ１００４）。

また、図２２に示すステップＳ２０３の空き枠情報の提示と承認を要求するメッセージ対して、「早い」、あるいは、「高い」等の否定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、提示した空き枠情報が否定されたと判断し、この場合にも図２３のラベルＬＢ９に続いて記載された処理が行われる。まず、予約支援サーバ１のＣＰＵ３０は、空き枠についての仮登録情報を削除し（Ｓ１００１）、次に、予約支援サーバ１のＣＰＵ３０は、他に候補があるかどうかを判断する（Ｓ１００２）。空き枠について他に候補がある場合には（Ｓ１００２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、他の空き枠の候補を表示して、承認を要求するメッセージを送信する（Ｓ１００３）。しかし、他に空き枠の候補がない場合には（Ｓ１００２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、新たな空き枠の提示を行うために再び日付の入力を要求するメッセージを送信する（Ｓ１００４）。

＜４−７：承認に対する処理＞
次に、提示情報が承認された場合の処理について説明する。上述のように、友達を招待した場合の処理の一部として、提示情報が承認された場合の処理を説明したが、この承認に対する処理は、本実施形態における予約支援処理の全体について共通の処理なので、改めて説明する。

図２２に示すステップＳ５０３、図２３に示すＳ８０３のお勧めゴルフ場の表示と承認を要求するメッセージの送信に対して、「はい。」あるいは「いいよ。」等の肯定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、提示したゴルフ場が承認否定されたと判断し、図２４のラベルＬＢ１１に続いて記載された処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、承認されたゴルフ場の情報を仮登録する（Ｓ１２０１）、そして、予約支援サーバ１のＣＰＵ３０は、日程について仮登録済みかどうかを判断する（Ｓ１２０２）。予約支援サーバ１のＣＰＵ３０は、日程について仮登録済みではないと判断した場合には（Ｓ１２０２：ＮＯ）、日付の入力を要求するメッセージを送信する（Ｓ１２０３）。このような処理が行われるのは、まず都道府県名等を入力することによってゴルフ場を決定し、その後に日程を決める場合が該当する。

予約支援サーバ１のＣＰＵ３０は、日程について仮登録済みと判断した場合には（Ｓ１２０２：ＹＥＳ）、ゴルフ場について仮登録済みかどうかを判断する（Ｓ１２０４）。予約支援サーバ１のＣＰＵ３０は、ゴルフ場について仮登録済みではないと判断した場合には（Ｓ１２０４：ＮＯ）、住所の入力を要求するメッセージを送信する（Ｓ１２０５）。このような処理が行われるのは、まず日程を入力することによって日程を決定し、その後に場所を決める場合が該当する。一方、予約支援サーバ１のＣＰＵ３０は、ゴルフ場について仮登録済みであると判断した場合には（Ｓ１２０４：ＹＥＳ）、空き枠について仮登録済みかどうかを判断する（Ｓ１２０６）。予約支援サーバ１のＣＰＵ３０は、空き枠について仮登録済みではないと判断場合には（Ｓ１２０６：ＮＯ）、空き枠を抽出して承認を要求するメッセージを送信する（Ｓ１２０７）。

しかし、図２２に示すステップＳ２０３の空き枠情報の提示と承認を要求するメッセージ対して、「はい。」あるいは「いいよ。」等の肯定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、提示した空き枠情報が承認されたと判断し、承認された空き枠情報を仮登録する（Ｓ１２０１）。この場合には、日程、ゴルフ場、空き枠情報の全てについて仮登録済みとなるので（Ｓ１２０２：ＹＥＳ、Ｓ１２０４：ＹＥＳ、Ｓ１２０６：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、予約サーバ５に対して予約情報の本登録処理を行い（Ｓ１２０８）、予約が完了した旨の表示を行う（Ｓ１２０９）。この処理により、予約サーバ５の予約情報テーブル５ｃにおいて、予約情報の更新が行われることになる。

なお、予約情報の本登録処理（Ｓ１２０８）以降に同伴者を追加したり、プランを変更したり、あるいはキャンセルを行う場合には、所定の予約サイトにアクセスすることによって直接行う。したがって、予約が完了した旨の表示は、例えば、図１７のメッセージＣ３０のように、「詳細はこちらです。」のように予約サイトへのリンク情報を貼り付けたり、予約サイトのＵＲＬを表示するようにする。

＜４−８：おまかせ処理＞
次に、おまかせ処理について説明する。ユーザから「おまかせ」等のメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、おまかせ要求があった判断し、図２４のラベルＬＢ９に続いて記載された処理を行う。まず、予約支援サーバ１のＣＰＵ３０は、所定の日程を設定して仮登録する（Ｓ１１０１）。例えば、おまかせ要求の入力が行われた日から２週間経過した後に最初に到来する土曜日を日程として設定し、仮登録する。

次に、予約支援サーバ１のＣＰＵ３０は、予約支援サーバ１の記憶部１６にラウンド履歴情報が記憶されているかどうかを判断する（Ｓ１１０２）。初めて使用する場合等、ラウンド履歴情報が存在しない場合には（Ｓ１１０２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、位置情報が仮登録されているかどうかを判断する（Ｓ１１０６）。位置情報が仮登録されている場合には（Ｓ１１０６：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、図２３に示すステップＳ８０３にジャンプし、位置情報に基づいてお勧めのゴルフ場を検索し、検索したお勧めのゴルフ場を表示して承認を要求するメッセージを送信する（Ｓ８０３）。

位置情報が仮登録されていない場合には（Ｓ１１０６：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、住所の入力を要求する（Ｓ１１０７）。この場合、住所は、ＧＰＳ等による位置情報であってもよいことは上述した通りである。以下、住所が入力されると、図２３に示すステップＳ８００以降のお勧めゴルフ場検索処理が行われることになる。

一方、ラウンド履歴情報が存在する場合には（Ｓ１１０２：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、一番新しいラウンド履歴情報に含まれるゴルフ場を特定する（Ｓ１１０３）。そして、予約支援サーバ１のＣＰＵ３０は、ラウンド履歴情報と最も近いスタート時間の空き枠を特定する（Ｓ１１０４）。予約支援サーバ１のＣＰＵ３０は、例えば、まず、このラウンド履歴情報と同じ時間を基準の時刻として、空き枠の検索を行う。この基準の時刻では空き枠がない場合には、基準の時刻の１０分後までの空き枠を検索する。それでも空き枠がない場合には、基準の時刻の１０分前までの空き枠を検索する。それでも空き枠がない場合には、基準時刻の１０分後から基準時刻の２０分後までの空き枠を検索する。このような検索を繰り返す。それでも空き枠がない場合には、基準時刻の１０分前から基準時刻の２０分前までの空き枠を検索する。このように所定時間ごとに、例えば１０分間ごとに時間をずらして空き枠の検索を行う。なお、検索時間の範囲を予め設定しておき、例えば基準時刻の９０分前から基準時刻の９０分後までの範囲で空き枠が見つからない場合、他のラウンド履歴情報に含まれるゴルフ場について同様の処理を行うようにしてもよい。

空き枠が見つかった場合には、例えば、その時刻の空き枠を仮登録し、料金プランと共にユーザに提示して承認を要求するメッセージを送信する（Ｓ１１０５）。料金プランは、例えば、当該日程の当該スタート時刻が適用されるプランの中で最も安価なもの抽出するようにすればよい。

空き枠が見つからなかった場合には、ラウンド履歴情報に含まれるゴルフ場について、順次同様の処理を行う。それでも空き枠が見つからなかった場合には、ラウンド履歴情報に含まれるゴルフ場に比較的に近いゴルフ場について同様の処理を行うようにすればよい。

＜５：予約処理の例＞
次に、本実施形態における予約処理の例を図１３及び図１７に示す端末装置２における表示例と、図２１乃至図２４に示すフローチャートに基づいて説明する。

＜５−１：１人予約＞
図１３は、１人予約を行う際の端末装置２における表示例を示す図である。
まず、ユーザが、専用アカウントであるゴルフ予約Ａ１０を会話の相手として選択すると、図１３に示すメッセージ表示画面Ｐ３が表示される。そして、ユーザが「１人で行く」というメッセージＣ８０を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する。解析の結果、予約要求が送信されたと判断し（Ｓ１３００）、さらに、人数についての入力があったと判断する（Ｓ１３０１）。そして、予約支援サーバ１のＣＰＵ３０は、人数が１人であると判断した場合には（Ｓ１３０１：ＹＥＳ）、１人予約フラグをオン状態とし（Ｓ１３０３）。次に、予約支援サーバ１のＣＰＵ３０は、住所履歴があるかどうかを判断する。予約支援サーバ１のＣＰＵ３０は、住所履歴がないと判断した場合には（Ｓ１３０４：ＮＯ）、住所の入力を要求するメッセージを送信する（Ｓ１３０５）。ユーザの端末装置２においては、図１３に示すように、「１人予約ですね。おすすめのゴルフ場を探してみます。あなたの住所をおしえてくださいね。ＧＰＳの位置情報でも構いません。」というメッセージＣ８１が表示される。

次に、ユーザが「位置情報 日本 埼玉県○○市××町５」というメッセージＣ８２を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する。解析の結果、予約支援サーバ１のＣＰＵ３０は、住所についての内容であると判断し、この住所に近いお勧めのゴルフ場の検索を行う（Ｓ１３０６）。そして、予約支援サーバ１のＣＰＵ３０は、直近の土曜日等の日程的条件を設定し、前記住所に最も近いゴルフ場から順に、１人予約者がいる空き枠の検索を行う（Ｓ１３０７）。そして、予約支援サーバ１のＣＰＵ３０は、おすすめの空き枠が抽出できた場合には（Ｓ１３０７：ＹＥＳ）、確認のメッセージを送信し（Ｓ１３０８）、ユーザの端末装置２においては、「８月２５日の１人予約、六本木ＧＣで７：００スタート、７，０００円の枠が空いています。既に１人分の予約が入っています。メッセージを表示します。」という空き枠メッセージＣ８３が表示される。

この例では、提示した空き枠に他の１人予約者がいる場合なので、予約支援サーバ１のＣＰＵ３０は、当該他の１人予約者の情報を提示する（Ｓ１３０８）。ユーザの端末装置２においては、「「２０代女性です。初心者ですけど、月イチくらいで気軽に楽しめるゴルフ友達を探してます。」・・・とのことです。一緒に行きますか？」というメッセージＣ８４が表示される。

このメッセージＣ８４に対して、「はい」という肯定的なメッセージＣ８５が入力された場合には、予約支援サーバ１のＣＰＵ３０は、ユーザがその空き枠への参加を承認したと判断し（Ｓ１３０９：ＹＥＳ）、そのユーザを当該空き枠に登録する予約登録処理を行う（Ｓ１３１０）。

そして、予約支援サーバ１のＣＰＵ３０は、「予約完了しました。」という予約完了メッセージＣ８６を表示させ、ユーザに対して、コメントを残すかどうかを問い合わせるメッセージを表示させる（Ｓ１３１１）。ユーザの端末装置２においては、「メッセージを残しますか？」という確認メッセージＣ８７が表示される。

確認メッセージＣ８７に対して、「はい」という肯定的なメッセージＣ８８が入力された場合には（Ｓ１３１１：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、コメントの入力を求めるメッセージを表示させる。ユーザの端末装置２には、「では、コメントをお願いします。」という要求メッセージＣ８９が表示させる。

要求メッセージＣ８９に対して、「２０代女性です。初心者です。楽しくゴルフがしたいです。」というようなコメントＣ９０が入力されると、予約支援サーバ１のＣＰＵ３０は、このコメントをコメント情報テーブル５ｄに登録して（Ｓ１３１２）、「コメントを登録しました。予定表に入れておきますね。詳細はこちらです。」というメッセージＣ９１を表示させて処理を終了する。

このように本実施形態によれば、１人予約についてもチャットを利用して簡単かつ迅速にゴルフ場の予約を行うことができ、しかも、他に１人予約したユーザがいる場合には、そのユーザの情報（本実施形態ではメッセージ）を表示することにより、ユーザ同士をマッチングすることが可能となる。なお、他の１人予約者についての情報としては、氏名、性別、年代などであってもよい。

＜５−２：複数人予約＞
図１７は、複数人での予約処理を行う際の端末装置２における表示例を示す図である。
まず、ユーザが、専用アカウントであるゴルフ予約Ａ１０を会話の相手として選択すると、図１３に示すメッセージ表示画面Ｐ３が表示される。そして、ユーザが「予約したい」というメッセージ（図示せず）を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する。解析の結果、予約支援サーバ１のＣＰＵ３０は、予約要求が送信されたと判断し（Ｓ１３００）、人数の入力を要求するメッセージを送信する（Ｓ１３０１）。ユーザの端末装置２においては、図１７に示すように、「ゴルフの予約をする人数を教えてくださいね。」という人数入力要求メッセージＣ２０が表示される。

この人数入力要求メッセージＣ２０に対して、「４人」という人数を示すメッセージが入力されると、予約支援サーバ１のＣＰＵ３０は、入力された人数が１人ではないと判断し（Ｓ１３０２：ＮＯ）、日程の入力を要求するメッセージを表示させる（Ｓ１００）。ユーザの端末装置２においては、図１７に示すように、「ゴルフに行きたい日を数字４ケタで教えてください。」というメッセージＣ２２が表示される。

次に、ユーザが「０８２５」というメッセージＣ２３を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する（Ｓ１０１）。解析の結果、予約支援サーバ１のＣＰＵ３０は、日付についての内容であると判断し、その日付を記憶部１６に記憶させて仮登録する（Ｓ２０１）。また、予約支援サーバ１のＣＰＵ３０は、確認のメッセージを送信し、ユーザの端末装置２においては、「８月２５日ですね。」というメッセージＣ２２が表示される。

予約支援サーバ１のＣＰＵ３０は、次に、ゴルフ場の仮登録が行われているかどうかを判断し（Ｓ２０２）、まだ仮登録されていないと判断した場合には（Ｓ２０２：ＮＯ）、住所が入力済みかどうかを判断する（Ｓ２０７）。予約支援サーバ１のＣＰＵ３０は、住所についても入力が行われていないと判断した場合には（Ｓ２０７：ＮＯ）、ユーザに対して住所の入力を要求するメッセージを送信する（Ｓ２０８）。ユーザの端末装置２においては、図１７に示すように「おすすめのゴルフ場を探してみます。位置情報をおしえてくださいね。」というメッセージＣ２３が表示される。

ユーザから、「位置情報、日本、埼玉県○○市××町５」というメッセージＣ２４が送信されると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する（Ｓ１００）。解析の結果、予約支援サーバ１のＣＰＵ３０は、住所についての内容であると判断し、日程について仮登録済みであるかどうかを判断する（Ｓ８０１）。日程については仮登録済みなので（Ｓ８０１：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、マップサーバ４にアクセスし、受信した住所の情報に基づいて、当該住所から所定時間内のゴルフ場を検索する（Ｓ８０２）。そして、ユーザに対してお勧めのゴルフ場を表示し、承認を要求するメッセージを送信する（Ｓ８０３）。ユーザの端末装置２には、図１７に示すように、「では赤坂ゴルフ倶楽部はどうでしょう？車で１時間４０分くらいです。」というメッセージＣ２５が表示される。

このメッセージＣ２５に対して、ユーザが「いいね」という肯定的なメッセージを送信したり、あるいは、一定時間内に否定的なメッセージを送信しない場合には、予約支援サーバ１のＣＰＵ３０は、提示したゴルフ場が承認されたと判断する。そして、予約支援サーバ１のＣＰＵ３０は、ゴルフ場を記憶部１６に記憶させて仮登録を行う（Ｓ１２０１）。次に、予約支援サーバ１のＣＰＵ３０は、日程が仮登録済みであり（Ｓ１２０２：ＹＥＳ）、ゴルフ場も仮登録済みであると判断し（Ｓ１２０４：ＹＥＳ）、空き枠情報が仮登録済みであるかどうかの判断を行う（Ｓ１２０６）。空き枠情報は未だ仮登録が行われていないので（Ｓ１２０６：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、予約サーバ５にアクセスして、空き枠情報を抽出して、ユーザに対して承認を要求するメッセージを送信する（Ｓ１２０７）。ユーザの端末装置２には、図１７に示すように、「８月２５日も空いています。４人で7:43スタート、食事つきで12,000円です。どうでしょう、予約しておきましょうか？」というメッセージＣ２６が表示される。

ユーザが「はい」という肯定的なメッセージＣ２７を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する（Ｓ１０１）。解析の結果、予約支援サーバ１のＣＰＵ３０は、提示した空き枠が承認されたと判断し、この枠を記憶部１６に記憶させて仮登録を行う（Ｓ１２０１）。次に、予約支援サーバ１のＣＰＵ３０は、日程が仮登録済みであり（Ｓ１２０２：ＹＥＳ）、ゴルフ場も仮登録済みであり（Ｓ１２０４：ＹＥＳ）、さらに空き枠情報も仮登録済みであると判断し（Ｓ１２０６：ＹＥＳ）、予約サーバ５に対して予約情報の本登録処理を行う（Ｓ１２０８）。ユーザに対しては、予約が完了した旨の表示を行う（Ｓ１２０９）。ユーザの端末装置２には、図１３に示すように、「予約しました。予定表に入れておきますね。詳細はこちらです。」というリンク付きのメッセージＣ２８が表示される。

このように、本実施形態によれば、チャットを利用して簡単かつ迅速にゴルフ場の予約を行うことができる。なお、同伴者の登録については、予約完了時に表示されるメッセージＣ４１に含まれるリンクをクリックする等して行う。ただしこれに限られるものではなく、例えば予約完了時に予約支援サーバ１のＣＰＵ３０が、「同伴者も登録しますか？」等のメッセージを送信することにより、ユーザに同伴者名の登録を促すこととしてもよい。

＜第２実施形態＞
次に、図２５及び図２６を参照して、本発明の第２実施形態について説明する。第１実施形態においては、１人予約の場合に、空き枠検索を行う前に住所履歴の有無を判断する例について説明した。しかし、本実施形態においては、１人予約の場合に、空き枠検索を行う前にラウンド履歴の有無の判断を行う構成が第１実施形態と異なっている。

ラウンド履歴とは、１人予約であるか否かを問わずに、外部管理サーバ３によって提供されるメッセージ送受信サービスにおけるチャットを利用して、本発明の予約支援サーバによるゴルフ場の予約支援サービスにおいてゴルフ場の予約を行った履歴をいう。

図２５は本実施形態の予約支援サーバの開始処理を示すフローチャートである。図２５に示すように、本実施形態においては、予約支援サーバ１のＣＰＵ３０は、１人予約フラグをオン状態にした後に（Ｓ１３０３）、ラウンド履歴があるかどうかを判断する（Ｓ１３２０）。具体的には、予約支援サーバ１のＣＰＵ３０は、予約サーバ５に対してラウンド履歴の検索要求を送信する。予約サーバ５のＣＰＵは、ラウンド履歴の検索要求を受信すると、予約情報テーブル５ｃにアクセスし、今回１人予約を行おうとするユーザのＵＩＤを含む過去の予約情報が予約情報テーブル５ｃに記憶されているかどうかを判断する。

その結果、当該過去の予約情報が予約情報テーブル５ｃに記憶されていた場合には、予約サーバ５のＣＰＵは、その旨を予約支援サーバ１に回答する。この回答を受信した予約支援サーバ１のＣＰＵ３０は、ラウンド履歴ありと判断し（Ｓ１３２０：ＹＥＳ）、当該予約情報として記憶されたゴルフ場において１人予約者のいる空き枠を検索する（Ｓ１３０７）。この際、予約支援サーバ１のＣＰＵ３０は、ユーザの端末装置２に、ラウンド履歴に基づく空き枠の検索を行う旨のメッセージを表示させる。図２６に示す例では、「１人予約ですね。以前に利用した六本木ＧＣはどうでしょうか。空き枠を探してみます。」というメッセージＣ９７が表示される。これ以降の処理は、第１実施形態と同様なので説明を省略する。

一方、前記ユーザによる過去の予約情報が予約情報テーブル５ｃに記憶されていなかった場合には、予約支援サーバ１のＣＰＵ３０は、ラウンド履歴なしと判断し（Ｓ１３２０：ＮＯ）、第１実施形態と同様に住所履歴の有無について判断する（Ｓ１３０４）。これ以降の処理は、第１実施形態と同様なので説明を省略する。

以上のように本実施形態によれば、ラウンド履歴がある場合には、ラウンド履歴に基づくゴルフ場について１人予約の空き枠を検索するので、ユーザによって馴染みのあるゴルフ場において、簡易に１人予約を行うことが可能となる。

なお、ラウンド履歴に基づいて１人予約の空き枠の検索を行い、抽出された空き枠を提示した後に、あるいは、当該空き枠における他の１人予約情報を提示した後に、ユーザが当該空き枠への参加を拒否した場合には（Ｓ１３０９：ＮＯ）、図２５に示すフローチャートにおいては、図２２に示す処理に移行するようになっている。

しかしながら、本発明はこのような処理の例に限定される必要はなく、抽出された空き枠を提示した後に、あるいは、当該空き枠における他の１人予約情報を提示した後に、ユーザが当該空き枠への参加を拒否した場合には（Ｓ１３０９：ＮＯ）、住所履歴に基づく検索（Ｓ１３０４）に移行するようにしてもよい。

以上のように、１人予約の空き枠を検索する際には、ラウンド履歴の判断と住所履歴の判断はどちらか一方を行う構成でもよく、また、本実施形態のように、ラウンド履歴の判断と住所履歴の判断とを組み合わせる構成でもよい。さらに、ラウンド履歴の判断と住所履歴の判断のいずれも使用せずに、住所またはゴルフ場名入力を要求することにより、１人予約の空き枠を検索する構成としてもよい。

ラウンド履歴または住所履歴がないと判断される場合には、ゴルフ場をランダムで一つ抽出する構成にしてもよい。すなわち、ランダムでゴルフ場を特定して１人予約の可能な空き枠を検索し、当該空き枠がなければ再度ランダムで別のゴルフ場について検索する。これを見つかるまで行い、１人予約の可能空き枠が見つかった場合には、当該空き枠を提示するようにしてもよい。ユーザが、提示された空き枠への参加を拒否した場合には、ユーザに対して住所またはゴルフ場名の入力を要求してもよい。

＜第３実施形態＞
次に、図２７を参照して、本発明の第３実施形態について説明する。第１実施形態においては、予約人数の入力要求が行われた後に、入力された人数が１人かどうかが判断される構成となっている。しかし、本実施形態においては、予約人数の入力要求が行われた後に、入力された人数が２人から４人の範囲内であるかどうかが判断される構成となっている。

図２７は本実施形態の予約支援サーバの開始処理を示すフローチャートである。図２７に示すように、本実施形態においては、予約支援サーバ１のＣＰＵ３０は、予約人数の入力要求を行い（Ｓ１３０１）、その後に入力された人数が、２人から１００人の範囲内であるかどうかを判断する（Ｓ１３３０）。予約支援サーバ１のＣＰＵ３０は、入力された人数が、２人から１００人の範囲内であると判断した場合には（Ｓ１３３０：ＹＥＳ）、図２２に示す処理に移行する。なお、本実施形態では一例として上限を１００人としているが、一般的に考えられるコンペ予約の人数の範囲内等で上限人数を設定すればよい。

一方、予約支援サーバ１のＣＰＵ３０は、入力された人数が、２人から１００人の範囲内ではないと判断した場合には（Ｓ１３３０：ＮＯ）、入力された人数が１人かどうかを判断する（Ｓ１３３１）。予約支援サーバ１のＣＰＵ３０は、入力された人数が１人であると判断した場合には（Ｓ１３３１：ＹＥＳ）、第１実施形態と同様に、ステップＳ１３０３以降の処理を行う。

しかしながら、予約支援サーバ１のＣＰＵ３０は、入力された人数が１人ではないと判断した場合には（Ｓ１３３１：ＮＯ）、ユーザの端末装置２において、エラーが生じた旨の表示をさせると共に、予約人数の再入力を要求するメッセージを表示させる（Ｓ１３３２）。

本実施形態によれば、誤った予約人数または人数として認識できない文字や記号が入力された場合には、エラーが生じたことを示して、予約人数の再入力を要求するので、適切な予約人数に基づく空き枠の検索を行うことができる。

なお、本実施形態においても、予約人数が１人であると判断された場合には、第２実施形態と同様に、ラウンド履歴の判断を行って、１人予約可能な空き枠を検索するようにしてもよい。

＜第４実施形態＞
次に、図２８乃至図３１を参照して、本発明の第４実施形態について説明する。第１実施形態においては、外部管理サーバ３によって提供されるメッセージ送受信サービスにおけるチャットを利用して、本発明の予約支援サーバによるゴルフ場の予約を行う例について説明した。しかし、第４実施形態では、ゴルフ予約用の専用のアプリケーションソフトウェアを用いる。外部管理サーバ３によって提供されるメッセージ送受信サービスにおいては、ゴルフ予約用の専用のアプリケーションソフトウェアを用いた場合には、ゴルフ予約の専用アカウントとメッセージ送受信サービスにおけるチャットが可能になっている。また、友達を招待した場合には、ゴルフ予約の専用アカウントと、招待した友達を含めてメッセージ送受信サービスにおけるチャットが可能になっている。

つまり、ユーザは、第１実施形態で説明したチャット画面を表示させることにより、友達同士でのチャットを行うことができるだけでなく、ゴルフ予約用の専用のアプリケーションソフトウェアを端末装置２ａにインストールしていた場合には、ゴルフ予約用の専用のアプリケーションソフトウェアを起動させることにより、ゴルフ予約の専用アカウントとチャットを行うことができる。したがって、ゴルフ予約用の専用のアプリケーションソフトウェアを用いてゴルフ場の予約が可能になっている。

但し、第１実施形態で説明したチャットにおいては、文字情報と一部の画像情報、あるいは、音声情報の再生ボタン等しか表示させることができないが、ゴルフ予約用の専用のアプリケーションソフトウェアにおいては、画像の選択によって情報の入力が可能な機能が付加された画像を表示させることができる。第４実施形態では、このような画像の選択によって情報の入力が可能な機能が付加された画像を、ゴルフ予約用の専用のアプリケーションソフトウェアの画面において表示させ、日程の入力や、ゴルフ場の場所の入力を行うようにした例である。

第４実施形態における外部管理サーバ３、マップサーバ４、予約サーバ５の構成は、第１実施形態と同様であるので説明を省略する。
本実施形態における予約支援サーバ１ａにおいては、記憶部１６にはさらに、ゴルフ予約用の専用のアプリケーションソフトウェアおよびこれに付随するカレンダー情報、地図情報が記憶されている。その他の構成については、第１実施形態の予約支援サーバ１と同様なので説明を省略する。

また、本実施形態における端末装置２ａは、図３０に示すように、取得部２１、入力部２２、表示制御部２３、変換部２４、表示部２５、記憶部２６を備える。本実施形態における記憶部２６は、ゴルフ予約用の専用のアプリケーションソフトウェアデータ、カレンダー情報、地図情報を少なくとも記憶している。取得部２１は、記憶部２６に記憶されているカレンダー情報、地図情報を所定のタイミングで取得する。入力部２２は、ユーザの操作に応じて情報を入力可能としている。入力部２２は例えばボタンやタッチパネルで構成される。表示制御部２３は、入力部２２により入力された内容や、取得部２１が取得した、画像の選択によって情報の入力が可能な機能が付加された画像であるカレンダー情報や地図情報、予約支援サーバ１ａ等から受信したメッセージの内容を、後述の表示部２５に表示させる制御を行う。変換部２４は、表示部２５に表示されたカレンダー情報や地図情報の一部が選択されると、当該選択された部分に相当する情報を、予約支援サーバ１ａが処理可能な情報に変換する。本実施形態では、予約支援サーバ１ａが処理可能なように、テキストデータに変換する。

本実施形態のゴルフ予約用の専用のアプリケーションソフトウェアは、所定のアプリケーション提供サイトにおいて提供されており、ユーザが選択することにより、当該アプリケーション提供サイトを介して、予約支援サーバ１ａからダウンロードし、ユーザの端末装置２ａにインストールすることができる。本実施形態のゴルフ予約用の専用のアプリケーションソフトウェアにはカレンダー情報や地図情報が含まれており、ユーザが端末装置２ａにゴルフ予約用の専用のアプリケーションソフトウェアをインストールしたときに、同時にカレンダー情報、地図情報が端末装置２ａに記憶されるようになっている。

ゴルフ予約用の専用のアプリケーションソフトウェアを端末装置２ａにインストールし、ゴルフ予約用の専用のアプリケーションソフトウェアを起動させると、図２８に示すようなアプリケーション画面Ｐ４が表示される。アプリケーション画面Ｐ４は、タイトル表示欄Ｄ１、メッセージ表示欄Ｄ２、日程ボタンＤ３、場所ボタンＤ４、参加者ボタンＤ５、及び機能ボタンＤ６を備えている。

タイトル表示欄Ｄ１には、例えば、「予約アプリ」と表示され、メッセージ表示欄Ｄ２には第１実施形態のチャット画面と同様に、ユーザが送信したメッセージが表示される。日程ボタンＤ３が押下されると、メッセージ表示欄Ｄ２に、日付の選択によって日付情報の入力が可能な機能が付加されたカレンダー画像が表示される。場所ボタンＤ４が押下されると、メッセージ表示欄Ｄ２に、地域の選択によって地域情報の入力が可能な機能が付加された地図画像が表示される。参加者ボタンＤ５が押下されると、友達リストが表示され、チャットに招待する友達を選択できるようになっている。そして、機能ボタンＤ６が押下されると、他の諸機能の選択が可能になり、例えば、メッセージの入力画面を表示させることができる。

次に、図２８、図２９、及び図３１を参照して、第４実施形態における動作について説明する。
図３１は第４実施形態の端末装置２ａにおける処理の流れを示すフローチャートである。端末装置２ａのＣＰＵ４０は、何等かの入力があると、その入力内容を解析する（Ｓ２０００）。入力された内容が、メッセージの入力画面に入力されたテキストであると判断した場合には（Ｓ２００１）、そのテキストデータを予約支援サーバ１ａに対して送信する（Ｓ２００２）。但し、入力された内容に「地図」の文字が含まれている場合には、後述するように地図の表示要求であると判断されるので、予約支援サーバ１ａには送信されない。

また、日程ボタンＤ３が押下された場合には、端末装置２ａのＣＰＵ４０は、カレンダーの表示要求があったと判断し（Ｓ２００３）、図２９に示すようなカレンダー画像Ｃ２１０を表示させる。このカレンダー画像Ｃ２１０は、例えばjavascript等を用いて表示されており、日の部分の画像が押下されると、その日に対応する情報が出力されるようになっている。

カレンダー画像Ｃ２１０のいずれかの日の部分の画像が押下されると、端末装置２ａのＣＰＵ４０は、カレンダーの日付の選択が行われた判断し（Ｓ２００５）、選択の結果として出力される日付の情報を、テキストデータに変換する（Ｓ２００６）。そして、このテキストデータを予約支援サーバ１ａに送信する（Ｓ２００７）。つまり、図２８に示すようにカレンダー画像Ｃ２１０を表示させ、いずれかの日付の画像を押下して選択することにより、選択した日付の情報が予約支援サーバ１ａに送信されることになる。このように、第２実施形態においては、カレンダー画像Ｃ２１０を用いて日程の入力が可能になっている。

場所ボタンＤ４が押下された場合には、端末装置２ａのＣＰＵ４０は、地図の表示要求があったと判断し（Ｓ２００８）、図２８に示すような地図画像Ｃ２０４を表示させる。この地図画像は、例えばjavascrip等を用いて表示されており、地域の部分の画像が押下されると、その地域に対応する情報が端末装置２ａから出力されるようになっている。

地図画像Ｃ２０４のいずれかの地域の部分の画像が押下されると、端末装置２ａのＣＰＵ４０は、地域の選択が行われたと判断し（Ｓ２０１０）、選択の結果として出力される地域の情報を、テキストデータに変換する（Ｓ２０１１）。そして、このテキストデータを予約支援サーバ１ａに送信する（Ｓ２０１２）。つまり、図２８に示すように地図画像Ｃ２０４を表示させ、いずれかの地域の画像を押下して選択することにより、選択した地域の情報が予約支援サーバ１ａに送信されることになる。このように、第２実施形態においては、地図画像Ｃ２０４を用いて都道府県あるいは住所の入力が可能になっている。

参加者ボタンＤ５が押下された場合には、端末装置２ａのＣＰＵ４０は、友達の招待要求があったと判断し（Ｓ２０１３）、メッセージ送受信システム上の友達リストを表示させる（Ｓ２０１４）。そして、いずれかの友達が選択された場合には、選択された友達を、チャットに招待する処理を行い、アプリケーション画面Ｐ４のメッセージ表示欄Ｄ２に、その友達のアイコン画像を表示させる（Ｓ２０１５）。

以上のように、第４実施形態においては、画像の選択によって情報の入力が可能な機能が付加されたカレンダー画像と地図画像を表示させることが可能であるが、カレンダー画像または地図画像の一部が押下された選択された場合には、テキストデータに変換して予約支援サーバ１ａに送信するので、予約支援サーバ１ａは、第１実施形態で説明したチャット機能を利用して送信されたデータと、第２実施形態の専用のアプリケーションソフトウェアを利用して送信されたデータとを区別することなく取り扱うことが可能になっている。従って、図２１から図２４のフローチャートに示した処理は、第４実施形態においても共通に実行される。また、チャット機能においてもカレンダー画像や地図画像からの選択が可能となり、ユーザの入力作業の負担が軽減されている。

図２８及び図２９の表示例を用いて、第４実施形態の動作例について説明する。まず、ユーザがゴルフ予約用の専用のアプリケーションソフトウェアを起動させると、図２８に示すアプリケーション画面Ｐ４が表示される。最初に起動した場合には、図２８に示すように、「ゴルフの予約をする人数を教えてくださいね。」というメッセージＣ２００が表示されている。

この状態で、ユーザが「１人」という人数を示すメッセージＣ２００を入力した場合には、端末装置２ａのＣＰＵ４０は、テキスト入力が行われたと判断し（Ｓ２００１）、「１人」というテキストデータを予約支援サーバ１ａに送信する（Ｓ２００２）。このテキストデータを受信した予約支援サーバ１ａのＣＰＵ３０は、図２１に示すように、予約人数が１人であると判断し（Ｓ１３０２：ＹＥＳ）、１人予約フラグをオン状態にする（Ｓ１３０３）。予約支援サーバ１ａのＣＰＵ３０は、住所履歴の有無を判断し（Ｓ１３０４）、例えば、住所履歴なしと判断した場合には（Ｓ１３０４：ＮＯ）、住所入力を要求するメッセージを端末装置２ａに送信する（Ｓ１３０５）。

端末装置２ａのＣＰＵ４０は、予約支援サーバ１ａから住所入力を要求するメッセージを受信すると、そのメッセージをメッセージ表示欄Ｄ２に表示させる。図２８の例では、端末装置２ａには、「おすすめのゴルフ場を探してみます。位置情報をおしえてください。」という住所入力要求メッセージＣ２０２が表示される。

ここで、ユーザが場所ボタンＤ４を押下し、あるいは、図２８に示すように「とちぎの地図」というメッセージＣ２０３を入力した場合には、端末装置２ａのＣＰＵ４０は、地図の表示要求があったと判断し（Ｓ２００８）、図２８に示すように地図画像Ｃ２０４を表示させる（Ｓ２００９）。図２８の例のように、特定の場所の地図が指定された場合には、その場所の地図を表示させるようにすればよく、場所ボタンＤ４を押下された場合には、例えば、日本地図の画像を表示させるようにすればよい。地図画像は、拡大することが可能であり、詳細な場所の特定が可能になっている。

そして、地図画像Ｃ２０４において特定の地域が押下された選択された場合には、端末装置２ａのＣＰＵ４０は、地域が選択されたと判断し（Ｓ２０１０）、選択された地域をテキストデータに変換し（Ｓ２０１１）、そのデータを予約支援サーバ１ａに送信する（Ｓ２０１２）。図２８の例では、那須地区が押下されたので、「那須地区」という情報が予約支援サーバ１ａに送信されることになる。

予約支援サーバ１ａのＣＰＵ３０は、図２１に示すように、当該地域におけるお勧めのゴルフ場を検索する旨の確認メッセージを送信すると共にお勧めのゴルフ場の検索を行う（Ｓ１３０６、Ｓ１３０７）。図２８の例では、ユーザの端末装置２ａの表示部２５には、「那須地区で探してみます。」というメッセージＣ２０５が表示される。

予約支援サーバ１ａにおいては、地図画像において選択可能な地域のそれぞれについて、ユーザに対して提示可能なお勧めのゴルフ場の情報が推奨施設情報として予め記憶されており、端末装置２ａから、例えば「那須地区」等の情報が送信された場合には、当該地区の１人予約可能なお勧めのゴルフ場の情報を抽出する。

ゴルフ場を抽出すると、予約支援サーバ１ａのＣＰＵ３０は、直近の土曜日の日程で、１人予約者のいる空き枠を検索する。そして、空き枠を抽出すると、予約支援サーバ１ａのＣＰＵ３０は、端末装置２ａに当該空き枠の内容を表示させる（Ｓ１３０８）。さらに、予約支援サーバ１ａのＣＰＵ３０は、当該空き枠における他の１人予約者の情報を端末装置２ａに対して提示する（Ｓ１３０８）。

図２８の例では、端末装置２ａにおいて、「１０月２２日の１人予約、○○ＧＣで７：００スタート、７，０００円の枠が空いています。既に１人分の予約が入っています。メッセージを表示します」というメッセージＣ２０６が表示される。さらに、「「２０代女性です。初心者ですけど、月イチくらいで気軽に楽しめるゴルフ友達探してます。」・・・とのことです。一緒に行きますか？」というメッセージＣ２０７が表示される。

このような情報の提示に対して、図２８に示すように、ユーザが「いいえ」のような否定的なメッセージＣ２０８を入力した場合には、予約支援サーバ１ａのＣＰＵ３０は、提示した空き枠に対する参加が拒否されたと判断し（Ｓ１３０９：ＮＯ）、図２２に示すように日程の入力を要求するメッセージを端末装置２ａに表示させる（Ｓ１００）。

図２９は、図２８に示す表示例以降の端末装置２ａにおける表示例を示す図である。図２９の例では、端末装置２ａには、「行きたい日を教えてください。」という日程入力要求メッセージＣ２０９が表示される。

この状態で、ユーザが日程ボタンＤ３を押下すると、端末装置２ａのＣＰＵ４０は、カレンダーの表示要求があったと判断し（Ｓ２００３）、図２９に示すようにカレンダー画像Ｃ２１０を表示させる。ユーザがカレンダーの例えば２７日の部分を押下すると、端末装置２ａのＣＰＵ４０は、カレンダーの日付が選択されたと判断し（Ｓ２００５）、選択された日付をテキストデータに変換する。図２９の例では、１０月２７日が選択されているので、１０月２７日のテキストデータが予約支援サーバ１ａに送信されることになる。

この日付の情報を受信した予約支援サーバ１ａのＣＰＵ３０は、図２２に示すように、メッセージ内容の解析の結果（Ｓ１０１）、日付の入力があったと判断し、ラベルＬＢ１に続く処理を行う。つまり、予約支援サーバ１ａのＣＰＵ３０は、日付を仮登録する（図Ｓ２０１）。この場合、図２９の例では、「１０月２７日ですね。」という確認メッセージが表示される。そして、予約支援サーバ１ａのＣＰＵ３０は、ゴルフ場が仮登録済みかどうかを判断し（Ｓ２０２）、ゴルフ場が仮登録されていない場合には（Ｓ２０２：ＮＯ）、住所入力済みかどうかを判断する（Ｓ２０４）。図２８及び図２９の例では、既に住所が入力されているので（Ｓ２０４：ＹＥＳ）、図２３に示すように、お勧めのゴルフ場の検索を行う（Ｓ８０２）。

以下、第１実施形態と同様に、提示された情報に対して承認または拒否を示すメッセージをユーザの端末装置２ａから送信することにより、第１実施形態と同様に、１人予約であっても、また、複数人数の予約であっても、簡易にゴルフ場の予約を行うことができる。

なお、第４実施形態においては、１人予約用の機能ボタンを設け、この機能ボタンが押下された時に、１人予約を指定できるようにしてもよいし、あるいは、１人予約用のボタンをアプリケーション画面Ｐ４に表示させるようにしてもよい。１人予約用の機能ボタンの押下により１人予約が指定された場合には、例えば、「１人予約」というテキストメッセージに変換して予約支援サーバ１ａに送信すればよい。その結果、上述した場合と同様に、１人予約処理が行われることになる。

なお、図２８及び図２９に示す例では、メッセージが投稿された日付や時間、「既読」の文言の記載を省略している。

＜変形例＞
本発明は、上述した実施形態に限定されるものではなく、以下に述べる各種の変形が可能である。また、各変形例及び実施形態は、適宜、組み合わせてもよいことは勿論である。

＜変形例１＞
また、上述した第４実施形態では、専用アプリケーションソフトウェアのアプリケーションの端末装置２ａへのインストール時に、カレンダー画像及び地図画像を端末装置２ａに記憶させる例について説明したが、カレンダー画像及び地図画像については、予約支援サーバ１ａからその都度端末装置２ａに送信するようにしてもよい。この場合には、例えば、端末装置２ａは、カレンダー画像または地図画像の表示を求める操作がユーザからなされた場合や、ユーザの入力内容に応じて端末装置２ａが自動的にカレンダー画像または地図画像を取得する場合に、カレンダー画像または地図画像の送信要求を予約支援サーバ１ａに対して行う。カレンダー画像または地図画像の送信要求を受信した予約支援サーバ１ａは、予め記憶部１６に記憶しているカレンダー画像または地図画像を、当該端末装置２ａに対して送信する。

＜変形例２＞
上述した第１実施形態においては、１人予約の際に、他の１人予約者にコメントを残す場合と残さない場合を選択可能な例について説明したが、他の１人予約者のコメントを表示する場合と表示しない場合を選択可能に設定するようにしてもよい。

図３２にこの変形例２における１人予約処理のフローチャートを示す。図３２は、第１実施形態の図２１に示すフローチャートに対応するフローチャートである。図３２の場合には、予約支援サーバ１のＣＰＵ３０は、お勧めの空き枠の抽出処理を終えると（Ｓ１３０７：ＹＥＳ）、他の１人予約者の情報を表示させるかどうかの確認メッセージを端末装置２に表示させる（Ｓ１３４０）。例えば、「既に他の１人予約者がいます。情報を表示させますか？」のような確認メッセージを端末装置２に表示させる。

この確認メッセージに対して、ユーザが肯定的なメッセージを入力した場合には、予約支援サーバ１のＣＰＵ３０は、ユーザが情報の表示を希望していると判断して（Ｓ１３４０：ＹＥＳ）、第１の実施形態と同様に他の１人予約者の性別、年齢等の情報を端末装置２に提示する（Ｓ１３０８）。

しかし、確認メッセージに対して、ユーザが否定的なメッセージを入力した場合には、予約支援サーバ１のＣＰＵ３０は、ユーザが情報の表示を希望していないと判断して（Ｓ１３４０：ＮＯ）、他の１人予約者の情報の提示は行わずに、提示した空き枠に参加するかどうかの確認メッセージを端末装置２に表示させる。例えば、「一緒に行きますか？」のようなメッセージを端末装置２に表示させる。
これ以降の処理は第１実施形態と同様なので説明を省略する。

＜変形例３＞
さらに、上述した各実施形態では、１人予約の際に、他の１人予約者にコメントを残す場合と残さない場合を選択可能な例について説明したが、さらに詳細に公開範囲を設定するようにしてもよい。この変形例３においては、登録部１４は公開設定に関する情報を登録する処理部としての機能をも有する。図３４は、この変形例における１人予約処理のフローチャートを示す。図２１と異なる部分を中心に説明する。図３４に示すように、この変形例３では、予約支援サーバ１のＣＰＵ３０は、１人予約の本登録を行った後に（Ｓ１３１０）、コメントを残すかどうかを判断し（Ｓ１３１１）、コメントを残す場合には（Ｓ１３１１：ＹＥＳ）、コメントの登録を行う（Ｓ１３１２）。そして、予約支援サーバ１のＣＰＵ３０は、その後に個人情報の公開設定を行う（Ｓ１３５０）。

公開設定は、例えば、図３３に示すように、「公開設定をします。次の中から番号を入力してください。１．個人情報は公開しない、２．プロフィール公開、３．メッセージ公開、４．プロフィールとメッセージを公開」というメッセージＣ３０３を送信する。そして、例えば、図３３に示すように、ユーザが「３」というメッセージＣ３０４を送信した場合には、メッセージを残すと判断し、図示しないが、例えば「ではメッセージをどうぞ。」等のメッセージを送信する。公開設定において「４」が選択された場合も、メッセージを残す旨が選択されたと判断する。そしてメッセージを受信すると、先に受信した公開設定とともに、予約ＩＤ及び予約者ＵＩＤと関連付けて記憶する（Ｓ１３５０）。

一方、公開設定において「１」または「２」が選択された場合、その旨を予約ＩＤ及び予約者ＵＩＤと関連付けて記憶する（Ｓ１３５０）。

なお、公開設定の記憶方法は任意であり、受信した「３」という番号自体を記憶させてもよいし、フラグを用いてもよい。

以上のような公開範囲の設定を行った後においては、予約支援サーバ１のＣＰＵ３０は、お勧めの空き枠の抽出後（Ｓ１３０７）、他の１人予約者の情報を提示する際に（Ｓ１３０８）、前記設定した公開範囲を参照する。
具体的には、他の１人予約者が、公開設定において「１．個人情報は公開しない」を選択していた場合、ＣＰＵ３０は当該予約情報の書誌的事項、例えばスタート時間、スタートホール、料金、のみを端末装置２に送信する。「２．プロフィール公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項に加えて、当該他の１人予約者のプロフィール、例えば氏名、性別や「３０歳台」等の年齢を、端末装置２に送信する。「３．メッセージ公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項に加えて、当該他の１人予約者の残したメッセージを、端末装置２に送信する。「４．プロフィールとメッセージを公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項、プロフィール情報、メッセージを、端末装置２に送信する。これ以降の処理は第１実施形態と同様なので説明を省略する。

なお、図３３に示す例では、メッセージが投稿された日付や時間、「既読」の文言の記載を省略している。

＜変形例４＞
上述した各実施形態及び各変形例においては、メッセージ送受信サービスにおけるチャット機能や、専用のアプリケーションソフトウェアを用いて１人予約者の残したメッセージ等を確認するようにしたが、本発明はこのような例に限定されるものではない。例えば、所定の予約サイトに「１人予約」のボタンを設けておき、このボタンが押下されたことと、ゴルフ場が選択されたことを予約サイトのサーバが認識した場合に、当該ゴルフ場で他の１人予約者の情報を検索し、画面の全部または一部に表示するようにしてもよい。この場合、１人だけ抽出するようにしてもよい、リスト状に表示するようにしてもよい。

＜変形例５＞
上述した各実施形態および各変形例では、ゴルフ場の予約に予約支援サーバを用いる例について説明したが、本発明はこのような例に限定されるものではなく、他のスポーツの予約、映画や劇場等の予約、宿泊施設の予約等にも応用することが可能である。

＜変形例６＞
上述した各実施形態においては、メッセージ送受信サービスにおけるチャット機能や、専用のアプリケーションソフトウェアを用いて、予約支援サーバ１と対話形式でゴルフ場の予約を行う例について説明したが、本発明は、掲示板や一般的なメールも利用することが可能である。

＜変形例７＞
上述した各実施形態においては、予約支援装置の一例として予約支援サーバ１を用いる構成を説明したが、本発明の機能が実現できるならば、複数のサーバを用いて本発明の機能を実現させる構成や、例えば予約支援サーバ１に組み込まれた機能と予約サーバ５に組み込まれた機能とが１つのサーバに組み込まれた構成であってもよい。すなわち、サーバ構成や機能の集約、分散は自在である。

＜変形例８＞
上述した各実施形態及び各変形例においては、１人予約フラグを用いたが、本発明はこのような例に限定されるものではなく、１人予約であることを識別できる方法であればどのような方法も用いることができる。

＜その他＞
なお、本発明における機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することとしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。また、本発明における機能またはその一部を実現するためのプログラムを配信する配信サーバ及び当該配信サーバによる配信に用いるために使用される、当該プログラムが記憶された備えられた記憶媒体についても、本発明の範囲に含まれる。

また、上述した機能の一部または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

なお、本発明は上述の実施形態及び変形例に限定されるものではなく、本発明の趣旨の範囲内での変更は本発明に含まれるものである。

ＮＥＴ……通信網、１，１ａ……予約支援サーバ、２，２ａ……端末装置、３……外部管理サーバ、４……マップサーバ、５……予約サーバ、１０……問合わせ部、１１……応答部、１２……判断部、１３……受付部、１４……登録部、１５……空き枠検索部、１６……記憶部、１７……情報抽出部、１８……予約検出部、１９……住所検索部、２１……取得部、２２……入力部、２３……表示制御部、２４……変換部、２５……表示部、２６……記憶部、２７……情報入力部、２８……申込み入力部。

Claims (20)

1. ユーザの使用に係る端末装置と通信可能で、コンピュータを備える予約支援装置のプログラムであって、
   前記コンピュータを、
   所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部と、
   前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部と、
   前記判断部により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部と、
   前記空き枠検索部による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置に応答可能な応答部と、
   前記応答部により応答した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け可能な受付部と、
   前記受付部により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部として機能させる、
   ことを特徴とする予約支援装置のプログラム。
2. ユーザの使用に係る端末装置と通信可能で、コンピュータを備える予約支援装置のプログラムであって、
   前記コンピュータを、
   所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部と、
   前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部と、
   前記判断部により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部と、
   前記空き枠検索部による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザの予約の内容を検出する予約検出部と、
   前記予約検出部により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置に応答可能な応答部と、
   前記応答部により応答した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け可能な受付部と、
   前記受付部により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部として機能させる、
   ことを特徴とする予約支援装置のプログラム。
3. 前記コンピュータを、
   前記空き枠検索部による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザについての情報を抽出する情報抽出部として更に機能させ、
   前記応答部は、前記他のユーザの登録された予約の内容と共に、前記抽出した前記他のユーザについての情報を前記端末装置に応答可能である、
   ことを特徴とする請求項２に記載の予約支援装置のプログラム。
4. 前記コンピュータを、
   過去に登録された予約の内容の中に、前記ユーザの住所に関する情報を検索する住所検索部として更に機能させ、
   前記空き枠検索部は、前記住所検索部による検索結果として前記ユーザの住所に関する情報が抽出された場合には、当該抽出された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索する、
   ことを特徴とする請求項１乃至請求項３のいずれか一に記載の予約支援装置のプログラム。
5. 前記問合わせ部は、前記住所検索部による検索結果として前記ユーザの住所に関する情報が抽出されなかった場合には、前記ユーザの住所に関する情報の前記端末装置における入力を促し、
   前記空き枠検索部は、前記端末装置において入力された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索する、
   ことを特徴とする請求項４に記載の予約支援装置のプログラム。
6. 前記コンピュータを、
   過去に登録された予約の内容の中に、前記ユーザによる過去の予約の内容を検索する予約検出部として更に機能させ、
   前記空き枠検索部は、前記予約検出部による検索結果として前記ユーザによる過去の予約の内容が抽出された場合には、当該抽出された過去の予約の内容に含まれる会場についての空き枠の中から、前記１人での予約が可能な空き枠を検索する、
   ことを特徴とする請求項１乃至請求項５のいずれか一に記載の予約支援装置のプログラム。
7. 前記空き枠検索部は、検索を行う日を基準として予め設定された規則に基づいて日程的条件を設定し、当該設定した日程的条件に基づいて前記１人での予約が可能な空き枠を検索する、
   ことを特徴とする請求項１乃至請求項６のいずれか一に記載の予約支援装置のプログラム。
8. 前記受付部は、前記応答部により応答した前記空き枠に対する前記端末装置における非承認の入力についても受け付け、
   前記問合わせ部は、前記受付部により前記非承認の入力を受け付けた場合には、前記ユーザに対して前記予約に必要な情報の前記端末装置における入力を促し、
   前記空き枠検索部は、前記端末装置において入力された情報に基づいて、１人での予約が可能な空き枠を検索する、
   ことを特徴とする請求項１乃至請求項７のいずれか一に記載の予約支援装置のプログラム。
9. 前記問合わせ部は、前記受付部により予約の申込みの入力を受け付けた場合には、他のユーザ宛ての情報の前記端末装置における入力を促す、
   ことを特徴とする請求項１乃至請求項８のいずれか一に記載の予約支援装置のプログラム。
10. ユーザの使用に係る端末装置と、当該端末装置と通信可能な予約支援装置とを備える予約支援システムであって、
    前記端末装置は、
    所定のアクティビティに関する予約に必要な情報の入力を行う情報入力部と、
    前記予約の申込みの入力を行う申込み入力部と、を備え、
    前記予約支援装置は、
    前記所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部と、
    前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部と、
    前記判断部により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部と、
    前記空き枠検索部による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置に応答可能な応答部と、
    前記応答部により応答した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け可能な受付部と、
    前記受付部により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部とを備える、
    ことを特徴とする予約支援システム。
11. ユーザの使用に係る端末装置と通信可能な予約支援装置の制御方法であって、
    所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促し、前記予約に必要な情報のうち予約人数が１人かどうかを判断し、
    予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索し、
    前記検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置に提示し、
    前記提示した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け、
    前記予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う、
    ことを特徴とする予約支援装置の制御方法。
12. ユーザの使用に係る端末装置と通信可能な予約支援装置であって、
    所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部と、
    前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部と、
    前記判断部により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部と、
    前記空き枠検索部による検索結果として前記空き枠が抽出された場合には、前記空き枠の内容を前記端末装置に応答可能な応答部と、
    前記応答部により応答した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け可能な受付部と、
    前記受付部により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部と、
    を備えることを特徴とする予約支援装置。
13. ユーザの使用に係る端末装置と通信可能な予約支援装置であって、
    所定のアクティビティに関する予約に必要な情報の前記端末装置における入力を促す問合わせ部と、
    前記予約に必要な情報のうち予約人数が１人かどうかを判断する判断部と、
    前記判断部により予約人数が１人であると判断された場合には、１人での予約が可能な空き枠を検索する空き枠検索部と、
    前記空き枠検索部による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザの予約の内容を検出する予約検出部と、
    前記予約検出部により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置に応答可能な応答部と、
    前記応答部により応答した前記空き枠に対する前記端末装置における予約の申込みの入力を受け付け可能な受付部と、
    前記受付部により予約の申込みの入力を受け付けた場合には、当該予約の内容の登録を行う登録部と、
    前記予約検出部により前記他のユーザの予約の内容が検出された場合に、前記空き枠の内容として、前記他のユーザの登録された予約の内容を前記端末装置に応答可能な応答部と、
    を備えることを特徴とする予約支援装置
14. 前記空き枠検索部による検索結果として抽出された前記空き枠の中に、当該空き枠の定員に満たない１人での予約が可能な空き枠が存在する場合には、当該空き枠について既に予約の登録を行っている他のユーザについての情報を抽出する情報抽出部を更に備え、
    前記応答部は、前記他のユーザの登録された予約の内容と共に、前記抽出した前記他のユーザについての情報を前記端末装置に応答可能である、
    ことを特徴とする請求項１３に記載の予約支援装置
15. 過去に登録された予約の内容の中に、前記ユーザの住所に関する情報を検索する住所検索部を更に備え、
    前記空き枠検索部は、前記住所検索部による検索結果として前記ユーザの住所に関する情報が抽出された場合には、当該抽出された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索する、
    ことを特徴とする請求項１２乃至請求項１４に記載の予約支援装置。
16. 前記問合わせ部は、前記住所検索部による検索結果として前記ユーザの住所に関する情報が抽出されなかった場合には、前記ユーザの住所に関する情報の前記端末装置における入力を促し、
    前記空き枠検索部は、前記端末装置において入力された前記ユーザの住所に関する情報に基づいて、予約における地域的条件を設定し、当該設定した地域的条件に基づいて前記１人での予約が可能な空き枠を検索する、
    ことを特徴とする請求項１５に記載の予約支援装置。
17. 過去に登録された予約の内容の中に、前記ユーザによる過去の予約の内容を検索する予約検出部を更に備え、
    前記空き枠検索部は、前記予約検出部による検索結果として前記ユーザによる過去の予約の内容が抽出された場合には、当該抽出された過去の予約の内容に含まれる会場についての空き枠の中から、前記１人での予約が可能な空き枠を検索する、
    ことを特徴とする請求項１２乃至請求項１６のいずれか一に記載の予約支援装置。
18. 前記空き枠検索部は、検索を行う日を基準として予め設定された規則に基づいて日程的条件を設定し、当該設定した日程的条件に基づいて前記１人での予約が可能な空き枠を検索する、
    ことを特徴とする請求項１２乃至請求項１７のいずれか一に記載の予約支援装置。
19. 前記受付部は、前記応答部により応答した前記空き枠に対する前記端末装置における非承認の入力についても受け付け、
    前記問合わせ部は、前記受付部により前記非承認の入力を受け付けた場合には、前記ユーザに対して前記予約に必要な情報の前記端末装置における入力を促し、
    前記空き枠検索部は、前記端末装置において入力された情報に基づいて、１人での予約が可能な空き枠を検索する、
    ことを特徴とする請求項１２乃至請求項１８のいずれか一に記載の予約支援装置。
20. 前記問合わせ部は、前記受付部により予約の申込みの入力を受け付けた場合には、他のユーザ宛ての情報の前記端末装置における入力を促す、
    ことを特徴とする請求項１２乃至請求項１９のいずれか一に記載の予約支援装置。
    

Images